bt 与 ed2k 区别

eDonkey / eMule 协议的简单介绍


电骡(eMule)的前身,是一个叫做eDonkey的软件,它是由Jed McCaleb在2000年创立,是国外一家商业公司开发的商业软件(具体请看:电驴3000万与唱片商和解 eDonkey软件被停售以及电驴掌门人辛酸访谈:放弃斗争 转型在线音乐)。采用“多源文件传输协议”(MFTPthe Multisource File Transfer Protocol)来散布文件。eDonkey中的索引服务器并不集中在一起的,而是各人私有的,遍布全世界,每一个人都可以运行电骡服务器(客户端和服务器端于一身),同时共享的文件索引为被称为“ed2k-quicklink”的连接,文件前缀“ED2K://”。每个文件都用md5-hash的超级链接标示,这使得该文件独一无二,并且在整个网络上都可以追踪得到。EDonkey可以通过检索分段从多个用户那里下载文件,最终将下载的文件片断拼成整个文件。

2002年05月3日Merkur不满意eDonkey 2000客户端并且坚信自己能做出更出色的P2P软件,于是便着手开发。凝聚一批原本在其他领域有出色发挥的程序员,eMule工程就此诞生,目标是将eDonkey的优点及精华保留下来,并加入新的功能以及使图形界面变得更好。eMule的最新版本获得来源是其官方网站:www.emule-project.net

跨平台的eMule:amule

 

emuleeDonkey的升级版,它的独到之处在于开源。其基本原理和运作方式,也是基于eDonkey,能够直接登录eDonkey的各类服务器。eMule同时也提供了很多eDonkey所没有的功能,比如可以自动搜索网络中的服务器、保留搜索结果、与连接用户交换服务器地址和文件、优先下载便于预览的文件头尾部分等等,这些都使得eMule使用起来更加便利,也让它得到了电骡的美誉。

 

BT软件和协议的简介

支持BT协议的P2P应用程序很多,如μTorrent、BitBuddy、FlashBT、BitCometBitSpirit等,当然中国特色的吸血类型的迅雷、FLASHGET等也算是。

通常BT协议的文件分发,是用torrent 种子文件作基础分享的,种子提供站点、目录服务器和内容发布者/下载者。torrent文件是一个文本文件,包含了tracker信息和文件信息两部分。tracker 信息则是客户通讯需要用到的tracker服务器的地址和针对tracker服务器的设置;

BT的主要原理是把提供下载的文件虚拟分成小相等的块,块小必须为2Kbyte的整数次方(由于是虚拟分块,硬盘上并不产生各个块文件),并把每个块的索引信息和Hash验证码写入.torrent文件中,所以.torrent文件就是被下载文件的“索引”。早期的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用于对块的完整性测试。新版的emule会用一种叫AICH的技术,就是说将文件分成80K小的块然后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消息,取消对这些子片断的请求,以避免带宽的浪费。实际上,用这种方法并没有浪费多少带宽,而文件的结束部分也一直下载的非常快。


6.阻塞(choking)算法

BT并不集中分配资源。每个peer自己有责任来尽可能的提高它的下载速率。Peers从它可以连接的peers处下载文件,并根据对方提供的下载速率给予同等的上传回报(你敬我一尺,我敬你一丈)。对于合作者,提供上传服务,对于不合作的,就阻塞对方。所以说,阻塞是一种临时的拒绝上传策略,虽然上传停止了,但是下载仍然继续。在阻塞停止的时候,连接并不需要重新建立。阻塞算法并不属于BT对等协议(指peers之间交互的协议)的技术部分,但是对提高性能是必要的。一个好的阻塞算法应该利用所有可用的资源,为所有下载者提供一致可靠的下载速率,并适当惩罚那些只下载而不上传的peers。

BT帕累托有效是指任何重新改变资源配置的方式,都不可能使一部分人在没有其他人受损的情况下受益。这一资源配置的状态,被称为“帕累托最优”(Pareto optimum)状态,或称为“帕累托有效”(Pareto efficient)。在计算机领域,寻求帕累托有效是一种本地优化算法BitTorrent的阻塞算法,用一种针锋相对(tit-for-tat)的方式来试图达到帕累托最优。

 

但是算法存在以下问题

最后一个片断的问题被夸大,且随机的第一个片断问题则被低估了。BitTorrent的最少优先策略在使得一个拥有了部分文件片断的节点快速找到缺少的片断的效率并不好

 

eMule协议和文件片段选择及搜索算法

为了优化整个网络的吞吐量和共享,eMule仔细挑选选择块的下载顺序。基本的选择策略和分片信息是这样的:每个文件被分成9.28M的块,每部分分成80KB的片。块下载的顺序是由发送请求文件块消息(.4节)的下载客户端决定。下载客户端可以在任何给定时刻从各个源中下载一个单独的文件块,所有从相同源中请求的片都在同一个块中。下面的原理(以这个顺序)应用于下载块等级:

1.(可获得的)片的频率,尽可能快的下载非常稀少的片来形成一个新的源。
2. 用来预览的块(最初+最后的片),预览或检查文件(比如,电影、mp3)
3. 请求状态(过程中下载),尝试向每个源询问其它的片。在所有源之间扩散请求。
4. 完成(未到某种程度的完成),在开始下载另一个时应该完成获得部分的片

频率标准定义了三个区域:非常稀少、稀少和一般。在每个区域里,标准有特定的权重,用来计算块等级。较低等级的块先下载。下面的列表根据上面的原理指定文件等级范围:

l0-9999 - 不请求和请求非常稀少的块
l0000-9999 - 不请求稀少和预览块
l20000-29999 - 不请求部分完成的一般的块
l30000-39999 - 请求的稀少和预览的块
l40000-49999 - 请求的没有完成的一般的块

这个算法通常选择第一个最稀少的块。然而,部分完成的块,接近完成的,也可能被选中。对于一般的块,在不同的源之间扩散下载。


注:上述资料来源于eMule协议规范 

 

eMule和BT中DHT算法

DHT的全称是Distributed Hash Table,即分布式哈希表技术,是一种分布式存储方法。这种网络不需要中心节点服务器,而是每个客户端负责一个小范围的路由,并负责存储一小部分数据,从而实现整个DHT网络的寻址和存储。和中心节点服务器不同,DHT网络中的各节点并不需要维护整个网络的信息,而是只在节点中存储其临近的后继节点信息,幅减少了带宽的占用和资源的消耗。DHT网络还在与关键字最接近的节点上复制备份冗余信息,避免了单一节点失效问题。我们可以把整个DHT网络想象成一个城市,那么每个客户端,就好比城市里各个角落的地图,上面绘制了附近区域的地形情况,把这些地图一汇总,城市的全貌就出来了。

而DHT所采用的算法中最出名的是Kademlia,eMule最早开始使用,Bitcomet、Azureus和BitTorrent只是步其后尘,同样使用Kademlia算法的DHT。不过它们各自的实现协议不尽相同,因此不能相互兼容(BitComet与BitTorrent兼容,Azureus更像eMule,但与其它都不兼容)。

在2005年5月著名的BiTtorrent在4.0版实现基于Kademlia协议的DHT技术后,很快国内的BitComet和BitSpirit也实现了和BitTorrent兼容的DHT技术,实现trackerless下载方式。emule实现的基于Kademlia类似的技术(BT中叫DHT,emule中叫Kad),和BT软件使用的Kd技术的区别在于key、value和node ID的计算方法不同。

对于BT协议,目前国内用户使用最多的BT客户端就是Bitcomet和讯雷,默认情况下,无须做任何设置这些BT软件即可自动连接并使用DHT网络。启动软件,它会使用和TCP端口号相同的UDP端口进行DHT网络连接。任何P2P技术的改进都与版权的博奕脱不了干系,DHT网络能够引起如此注目亦是如此。

确实,BT采用DHT网络后,反[Dao版]将变得更加困难。因为在此之前,用户进行交换数据时,必需首先连接上Tracker服务器,根据所获得的正在进行下载和上传的用户列表,才能够进行正常的文件交换。这样的话,只需封禁掉提供Tracker服务的网站,便可以截断[Dao版]传播的途径。DHT网络则不同,由于此时互联网中任何一个运行BT客户端的用户都可以作为DHT网络中的节点,因此即使封禁掉那些提供Tracker服务的网站,用户还是能够通过全球范围的逻辑DHT网络分享文件,反[Dao版]就无从谈起。除非让上的人都不上网,或宣布使用BT软件为重罪。但技术从来都是一把双刃剑。在批判BT助长[Dao版]气焰的同时,我们也应该看到,BT也正在日渐成为合法作品传播的途径。由于无法承受超量流量的访问,一些免费和共享软件(如Foobar2000等)开始采用BT方式分发型的合法软件——Linux系统,更是将BT作为主要的分发渠道。

在eMule中也有使用,常把它叫做KAD,只不过具体实现的协议有所不同。Kad网络的主要的目标是做到不需要服务器和改善可量测性。相对于传统的ed2k服务器只能处理一定数量的使用者(我们在服务器列表也都看到了,每个服务器都有最多人数限制),而且如果服务器连接人数过多,还会严重的的拖垮网络。传统的ed2k网络需要服务器支持作为中转和存储hash列表信息,kad可以不通过服务器同样完成ed2k网络的一切功能。Kad需要UDP端口的支持,之后Emule会自动按照客户端的要求,来判断它能否自由连线,然后同样也会分配一个id,这个过程和ed2k的高id和低id检查很像,不过这个id所代表的意义不同于ed2k网络,它代表一个是否“ly”的状态。

Kad能够自我组织,并且自我调节最佳的使用者数量以及他们的连接效果。因此,它更能使网络的损失达到最小。由于具备了以上所叙述的功能,Kad也被称之为Serverless network(无服务器网络)。虽然目前一直处于开发阶段(alpha stage) 。通过进行Kad关键字搜寻,任何人可以在文件分享网络中寻找资料。没有任何中央服务器储存文件索引,这项工作是平均由所有客户端担当:拥有要分享的文件的枝节点,会先处理文件的内容,并从内容计算出一组杂凑Hash值,这组值将会在分享网络中辨识这个文件。kad网络首先给每个客户分配一个唯一的ID值,然后对不同的ID值进行异或来得到两个客户之间的“距离”,kad会维护一个桶,“距离”越近的用户桶里的数量会越多,kad定期对桶里的用户进行清理,以保持其有效性。

对于文件和用户emule会有两个这样的结构,可以通过kad来查找文件和文件相关的用户信息;同样为了考虑冗余的问题,kad会将其自身的信息复制一份给“距离”它最近的一定数量的用户,这样就算在它下线后,这些信息也不会丢失。Kad本身有一个nodes.dat文件,也叫做节点文件,这里面存放了我们在Kad网络中的邻居节点,我们都是通过这些节点来进入Kad网络的,相当于客户通讯中通过router来加入DHT网络。


注:在eMule具体的实现过程中,采用的ID是28bit。例如:找到用户小则是通过将用户id异或的方式,两个id的二进位异或值决定他们之间的逻辑距离,如00距离0要比距离00近。那么当一个用户加入kad后,首先通过一个已知的用户找到一批用户的id和ip地址和端口。当该用户要寻找一个特定用户A的时候,该用户先询问几个已知的逻辑距离较A较近的用户,如B用户,C用户,D用户,B,C,D会告诉该用户他们知道的更加近的用户的id和ip地址和端口,同理类推,这个用户最终就能找到A。所以寻找的次数会在logN数量级,这里N代表询问的人数。

 

最令人遗憾的是BT和eMule中的DHT算法无法互通和兼容!

 


注:在Kad网络中,系统存储的数据以对形式存放。在BT的DHT实现中,其key值为torrent文件的info_hash串,其value值则和torrent文件有密切关系。

 

 

DHT技术的缺点和发展存在的问题

 

1.节点频繁加入和离开引起网络波动

网络波动的程度严重影响发现算法的效率。网络波动(Churn、fluctuation of network)包括结点的加入、退出、失败、迁移、并发加入过程、网络分割等。DHT的发现算法如Chord、CAN、Koorde等都是考虑网络波动的最差情况下的设计与实现。由于每个结点的度数尽量保持最小,这样需要响应的成员关系变化的维护可以比较小,从而可以快速恢复网络波动造成的影响。但是每个结点仅有少量路由状态的代价是发现算法的高延时,因为每一次查找需要联系多个结点。

 

2.DHT算法由于采用分布式散列函数,只适合于准确的查找,如要支持目前Web搜索引擎具有的多关键字查找功能,还需引入新的方法

原因在于DHT工作方式,基于DHT的P2P系统采用相容散列函数根据精确关键词进行对象的定位与发现。散列函数总是试图保证生成的散列值均匀随机分布,结果两个内容相似度很高但不完全相同的对象被生成了完全不同的散列值,存放到了完全随机的两个节点上。因此,DHT可以提供精确匹配查询,但是支持语义是非常困难的。目前在DHT基础上开展带有语义的资源管理技术的研究还非常少。由于DHT的精确关键词映射的特性决定了无法和信息检索等领域的研究成果,阻碍了基于DHT的P2P系统的规模应用。作为一种资源组织与发现技术必然要支持复杂的查询,如关键词、内容查询等。尽管信息检索和数据挖掘领域提供了量成熟的语义查询技术,由于DHT精确关键词映射的特性阻碍了DHT在复杂查询方面的应用。


3.DHT的安全性:比如节点之间通迅和查找分工没有适当安全认证机制,存在很多安全隐患

当前下载软件的发展趋势就是集成各种协议,打通各种协议的下载(BT、ED2K(eMule)、HTTP、FTP、MMS、RTSP协议),脱兔、迅雷已经做了一部分这样的工作,但是实际效果并不好。资源下载工具的用户并不关心资源是以什么协议方式在网络上发布的,用户的期望在于拥有相应的权限都可以下载,所有协议之间的隔阂被打通。下载工具成为向互联网获取资源、同时也是向互联网提供资源的平台。

 

文章来源:

注:很多资料来源于互联网,再次向原作者表示感谢。

posted on 2018-11-20 05:58 wpjamer 阅读(...) 评论(...) 编辑 收藏

导航

统计