China Open source community
站内导航:
站内排行前50热点文章

精华文章  GDB调试精粹及使用实例
普通文章  STL中map用法详解
精华文章  负载均衡软件比较(Hapr...
普通文章  头文件的重复引用
普通文章  递归函数的调用过程
普通文章  TCP三次握手/四次挥手详解
普通文章  epoll的实现原理
普通文章  贪心策略的理论基础——...
普通文章  BMH算法原理与实现(模...
普通文章  http请求的详细过程
普通文章  DP动态规划
普通文章  GNU LD用法
普通文章  排列组合与回溯算法
普通文章  Linux内核中的红黑树
精华文章  linux下使用minicom的几...
普通文章  Linux socket编程之套接字
精华文章  Android线程模型
精华文章  enum类型的本质
普通文章  Java开源Html解析类库
普通文章  linux源代码包(.tar.g...
普通文章  L.A.M.P配置过程
普通文章  linux设置环境变量的方法
普通文章  python的memcache和jso...
普通文章  应用程序二进制接口---ABI
普通文章  memcached server LRU ...
普通文章  gcc编译过程概述
普通文章  Java多线程实现简单实例
普通文章  android核心模块及相关...
普通文章  linux内核编译问题
普通文章  brk和sbrk详述
普通文章  Python程序员常用的IDE...
普通文章  C/C++程序员常见面试题...
普通文章  优化C语言代码(程序员必...
普通文章  Unix操作系统的历史演变
普通文章  发行版发布:CentOS 5.4
普通文章  模版函数指针,C++委托...
普通文章  在windows中构建gtk开发...
普通文章  在ubuntu9.10下安装QT4...
普通文章  关于Qvariant类--万能的...
普通文章  Debian sudo 设置
普通文章  i++循环与i--循环的执行...
普通文章  busybox1.15.x 交叉编译
普通文章  python非贪婪,多行匹配...
普通文章  cscope使用简介
普通文章  关于僵死进程zombie
普通文章  [翻译]Django初窥
普通文章  函数指针传递和全局指针...
普通文章  Android Porting Exper...
普通文章  判断链表是否存在环并找...
普通文章  递归思想的妙用

 
 
 
当前位置: 首页 >> 网络协议与安全 >> BT和eMule下载协议的比较和分析
 
 

BT和eMule下载协议的比较和分析

作者:      来源:zz     发表时间:2008-04-20     浏览次数:      字号:    

BT和eMule下载协议的比较和分析
     由于从事P2P下载引擎开发得原因,对BT和eMule协议有了一些想法,总结如下,供参考。很多资料来源于互联网,再次向原作者表示感谢。 在当前的下载领域BT和eMule协议应用得是最广泛得,他们各自有自己强大得用户阵迎得支持。
    eDonkey由Jed McCaleb在2000年创立。采用“多源文件传输协议”(MFTP,the Multisource FileTransfer Protocol)。eDonkey索引服务器并不集中在一起的,而是各人私有的,遍布全世界,每一个人都可以运行电驴服务器,同时共享的文件索引为被称为“ed2k-quicklink”的连接,文件前缀“ED2K://”。每个文件都用md5-hash的超级链接标示,这使得该文件独一无二,并且在整个网络上都可以追踪得到。EDonkey可以通过检索分段从多个用户那里下载文件,最终将下载的文件片断拼成整个文件。2002年05月13日 Merkur不满意eDonkey 2000客户端并且坚信自己能做出更出色的P2P软件,于是便着手开发。凝聚一批原本在其他领域有出色发挥的程序员,eMule工程就此诞生,目标是将 eDonkey的优点及精华保留下来,并加入新的功能以及使图形界面变得更好。现在eMule的最新版本是0.48a(2007年5月20号发布)。
  emule是eDonkey的升级版,它的独到之处在于开源。其基本原理和运作方式,也是基于eDonkey, 能够直接登录eDonkey的各类服务器。eMule同时也提供了很多eDonkey所没有的功能,比如可以自动搜索网络中的服务器、保留搜索结果、与连接用户交换服务器地址和文件、优先下载便于预览的文件头尾部分等等,这些都使得eMule使用起来更加便利,也让它得到了电骡的美誉。
   支持BT协议的P2P应用程序很多,如BitBuddy、FlashBT、BitComet和BitSpirit等,这里以应用程序BT为例来分析BT协议。 BT由如下几部分组成:.torrent文件、种子提供站点、目录服务器和内容发布者/下载者。.torrent文件是一个文本文件,包含了 tracker信息和文件信息两部分。tracker信息主要是BT下载中需要用到的tracker服务器的地址和针对tracker服务器的设置;文件信息是指将目标文件计算处理后再根据BT协议的B编码规则网编码后得到的信息。BT的主要原理是把提供下载的文件虚拟分成大小相等的块,块大小必须为2 Kbyte的整数次方(由于是虚拟分块,硬盘上并不产生各个块文件),并把每个块的索引信息和Hash验证码写入.torrent文件中,所以. torrent文件就是被下载文件的“索引”。种子提供站点也就是.torrent文件的提供站点,为下载者提供.torrent文件下载服务。目录服务器记录被下载的文件的索引信息及下载该文件的用户的信息(主要是IP地址及端口号)。早期的BT协议只支持tracker服务器,这种目录服务器是集中式目录与分布式查询的混合型;在BT协议的升级版本中,增加了对DHT(分布式Hash表)网络的支持。

BT和eMule协议的宏观比较和分析

    emule从技术层面上说是比BT好很多的,可是由于各种各样的原因,似乎在互联网上emule并不是很流行。
1.传统连接方式:
    BT使用统一的torrent文件先作一个原下载文件的信息记录,然后客户下载后通过torrent的信息与服务器连接并下载, emule仅有一个文件ID,客户自行与服务器连接再下载;eMule的资源发布更便捷,同时资源更丰富,BT中不同种子之间的用户是分隔的,即使种子中包含的文件是相同的,BT用户之间也无法互通连接。

2.底层传输协议比较:
    BT只使用TCP协议进行下载,协议简单有效,但是功能比较单一,有的功能不完整, emule使用TCP和UDP两种协议进行通信,更加有效的利用了网络资源,功能完整强大,但这也同时使主机的负荷加大;

3.文件组织方式和数据验证方式: 
  BT会在开始前对文件进行一次完全的HASH,就是将文件首尾相联然后按固定块取SHA值,这些值最终被放入torrent文件编码中,客户从网上一次下载完全,高效简单,一般情况下BT软件会在每小块下载完成后就对其进行HASH测试,检查其正确性 。 emule 在链接字符串中只存放了整体文件的HASH值,通过将这个HASH到服务器上取出文件的相关信息, 实际的操作中,会将文件分解成9.28M大小的块并进行HASH用于对块的完整性测试.新版的emul会用一种叫AICH的技术,就是说将文件分成 180K大小的块然后HASH再将HASH值进行二进迭代式(具体的看emule协议)的HASH最终组成一个HASH二叉树。好处:可以在链接中只加入根结节的HASH值而不用加入叶子节点, 减小了链接字符串大小,如果在最终文件下载完毕后,测试出的根节点HASH与得到的根节点的HASH值不同,则可以通过协议与网络上的其它主机的树进行比较快速得出错误的块.

  4.流量控制方式: 
    BT采用针锋相对的方式处理上传下载平衡的控制,这种方式会记录短期内与客户连接的所有节点的上传下载流量,通过在固定时间内对下载流量的比较,得出允许上传的客户;为防止新客户长时间得不到其它客户的认同,BT会在一断时间停止他的上传作为对他的警告;对于已经下载完毕的客户,BT会简单的使上传流量最大的客户得到更多的时间完成上传;为了防止在文件的最后阶段下载速度下降,BT会在最后时向所有连接的客户发送请求迅速完成下载;下载过程中,BT会对文件块在整个网络中的存在复本的多少进行跟踪,比较少的复本总是会得到优先的下载权,以使整个网络的文件冗余度提高.  简单的说BT使用的是针对文件的流量控制方式
   Emule采用的是客户积分的方式,就是对所有用户的上传和下载量进行一个运算,从而得出一个客户的积分值,那些积分比较高的用户总是可以得到优先的下载权,甚至可以不进行排队直接下载,结果就是:在一个比较长的时间内对一个用户对其它用户的整体贡献有了一个评估.简单的说emule采用的是针对用户的流量控制方式

5.功能与性能:
   emule具有查找功能,而这在BT 只能通过网站来实现. BT的方式更注重于简单高效的快速传输,而emule更注重于整个网络状态的变化及用户体验.单从下载效率上说BT占优,而从网络状态及完整强大的协议支持上说,emule作了更多的事情.从性能上考虑,在相同网络状态下,BT下载单文件的能力比较强, emule比较适合于长时间的多文件下载,对机器的使用和影响比较小,这源于两者对网络均衡及p2p模式的不同理解.

  
 
BT片选择策略 


1.片断选择
选择一个好的顺序来下载片断,对提高性能非常重要。一个差的片断选择算法可能导致所有的片断都处于下载中,或者另一种情况,没有任何片断被上载给其它 peers。
2.严格的优先级
片断选择的第一个策略是:一旦请求了某个片断的子片断,那么该片断剩下的子片断优先被请求。这样,可以尽可能快的获得一个完整的片断

3。最少的优先
对一个下载者来说,在选择下一个被下载的片断时,通常选择的是它的peers们所拥有的最少的那个片断,也就是所谓的“最少优先”。这种技术,确保了每个下载者都拥有它的peers们最希望得到的那些片断,从而一旦有需要,上载就可以开始。这也确保了那些越普通的片断越放在最后下载,从而减少了这样一种可能性,即某个peer当前正提供上载,而随后却没有任何的被别人感兴趣的片断了。每个peer都优先选择整个系统中最少的那些片断去下载,而那些在系统中相对较多的片断,放在后面下载,这样,整个系统就趋向于一种更优的状态。如果不用这种算法,大家都去下载最多的那些片断,那么这些片断就会在系统中分布的越来越多,而那些在系统中相对较少的片断仍然很少,最后,某些 peer 就不再拥有其它 peer 感兴趣的片断了,那么系统的参与者越来越少,整个系统的性能就下降。在BT系统中,充分考虑了经济学的概念,处处从整个系统的性能出发,参与者越多,系统越优化。

4。随机的第一个片断
   “最少优先”的一个例外是在下载刚开始的时候。此时,下载者没有任何片断可供上传,所以,需要尽快的获取一个完整的片断。而最少的片断,通常只有某一个 peer拥有,所以,它可能比多个peers都拥有的那些片断下载的要慢。因此,第一个片断是随机选择的,直到第一个片断下载完成,才切换到“最少优先” 的策略。

5。最后阶段模式
有时候,从一个速率很慢的peer那里请求一个片断。在下载的中间阶段,这不是什么问题,但是却可能潜在的延迟下载的完成。为了防止这种情况,在最后阶段,peer向它的所有的peers们都发送某片断的子片断的请求,一旦某些子片断到了,那么就会向其它 peer发送cancel 消息,取消对这些子片断的请求,以避免带宽的浪费。实际上,用这种方法并没有浪费多少带宽,而文件的结束部分也一直下载的非常快。

[1] [2]

编辑 webmaster

 
 
 
评论
 
 
发表
 
姓名: QQ:
性别: MSN:
E-mail: 主页:
评分: 1 2 3 4 5
评论内容:
验证码:
  
  • 请遵守《互联网电子公告服务管理规定》及中华人民共和国其他各项有关法律法规。
  • 严禁发表危害国家安全、损害国家利益、破坏民族团结、破坏国家宗教政策、破坏社会稳定、侮辱、诽谤、教唆、淫秽等内容的评论 。
  • 用户需对自己在使用本站服务过程中的行为承担法律责任(直接或间接导致的)。
  • 本站管理员有权保留或删除评论内容。
  • 评论内容只代表网友个人观点,与本网站立场无关。
  •  
    中国源码网 - www.YuanMa.org - 中国 开放源代码+编程 社区