eMule
协议
离婚协议模板下载合伙人协议 下载渠道分销协议免费下载敬业协议下载授课协议下载
指南
作者: Yoram Kulbak and Danny Bickson
译者: Flakever (flake.sun@gmail.com)
0 译者序
0.1 使用指南
文中出现蓝色字体,如 2.1,则意为见 2.1 节.绿色字体为参考文献编号,原作者提供了 1-5 个参
考文献,其后为译者添加.此处取消了
原文
少年中国说原文俱舍论原文大医精诚原文注音大学原文和译文对照归藏易原文
中的这两种格式的连接功能,避免打断阅读过程.
请自行使用书签.
0.2 版权声明
原文版权由原文作者 Yoram Kulbak and Danny Bickson 所有,译文版权由 flakever 所有.
该译文可在非商业目的下任意传播和复制.
对译文的修改或将其用于任何商业目的的行为需获得译者同意.
0.3 版本
本文为<
> 1e
0.4 鸣谢
感谢父母给予的关怀.
特别感谢女友 Snow 的支持,祝你 GMAT800+6,^_^.
1 前言
1.1 文章简介
eMule 是一款基于 eDonkey 协议的流行文件共享应用程序,本文主要描述 eMule 的网络行为,
并解释了理解 eMule 协议所需要了解的相关术语.与此同时,本文给出了完整的 eMule 协议指
南,并在附录中表述了具体的报文编码格式.本文讨论基于一款开源的 eMule 客户端[2].前言
向读者提供理解文本所需的背景知识.如果需要获取更多关于 eMule 的信息,可以参考[3].
1.2 概览
在 eMule 网络世界中,全球范围内数以百计的 eMule 服务器和成百上千万的 eMule 客户端[1]
导演着eMule的繁荣.客户端(Clients)为了得到eMule网络服务,需要与至少一个服务器(Server)
建立连接,这个与服务器的连接会在客户端整个生命周期内长期保持.在这个体系内,服务器
提供集中的索引服务(如同 Napster),值得注意的是,服务器之间并不进行通信.
每个 eMule 客户端都中预设置有两个列表,其一包括服务器地址,另一个列表则包含了其
本地文件系统中的共享文件.客户端与一个 eMule服务器建立一个对应的TCP连接,从而登录
网络并获取关于所需文件的信息,并获取用于找寻其他可联络的客户端的信息.于此相对
应,eMule 客户端为了实现与其他客户端间进行文件上传与下载,与这些客户端建立了数以百
计的TCP连接.每个 eMule客户端为它的每个共享文件都独立得维护一个上传有限队列.一个
待下载的客户端将会从这个队列底部加入,并逐步提升其在队列中的位置,直到这个它达到队
列顶部,就开始下载文件.一个客户端可以从多个不同客户端下载同一个文件,从每一个客户
端中下载文件的不同部分.同理,上传客户端也可以给待下载客户端上传文件的部分块,即便
上传客户端没有完成整个文件的下载.eMule 还扩展了 eDonkey 的性能,允许客户端之间交换
服务器信息和共享文件及其他客户端的相关信息.值得注意的是,客户端-客户端通信和客户
端-服务器通信都是基于 TCP 的.
服务器通过其数据库保存文件和客户端的信息,它并不保存任何共享文件,它只是为共享文件
的位置提供一个集中索引.服务器还有一个已经逐渐被放弃的功能,即为因有防火墙阻碍或其
他原因造成的无法接受进入连接的客户端(俗称 LowID 客户端)提供桥接服务.但是这种桥接
功能极大地增加了服务器的载荷.eMule 还使用 UDP 来提升客户端-服务器及客户端-客户端
连接的性能.但是,对于一个客户端是否能正确的传输和接受 UDP 报文并无强制性要求,也不
会影响到常规功能,即便防火墙禁止了 UDP 传输也可以无故障的运行 eMule.
1.2.1 客户端-服务器连接
客户端启动时,首先与一个 eMule 服务器建立 TCP 连接,服务器向其提供一个客户端 ID(详见
1.3节).客户端 ID的生命周期等于其客户端-服务器连接的生命周期,对于HighID而言,所有的
服务器都会根据其 IP 计算一个固定的客户端 ID,这点与 LowID 不同.随着连接建立,客户端向
服务器上传它的共享文件列表,服务器将这个列表储存在数据库中,同时,客户端向服务器上
传一个下载文件列表,其中包含了客户端需要下载的文件信息.本文第 2 部分详细分析了
eMule 的客户端-服务器 TCP 连接的报文交换机制.
连接建立完毕后, eMule 服务器向这个客户端发送一个源列表,这个列表包含了拥有这个客户
端待下载文件的其他客户端的信息.这种拥有别的客户端所需求的资源或文件的客户端就称
作源.从这时起,这个客户端就开始与其他客户端建立连接(见 1.2.2).
这个客户端-服务器 TCP 连接在整个客户端会话过程中一直保持开启.在初始的握手会话后,
客户端-服务器会话往往由客户端的某些活动所引起,比如客户端的文件搜索请求会引起服
务器的文件搜索结果应答,在搜索会话之后,客户端会发起一个对特定文件的源查询请求,此
时,服务器会返回一个源列表(包括 IP 地址和端口号),客户端就可以使用这个列表上的信息下
载所查询的文件.
客户端-服务器 UDP 连接是客户端用于和其他未建立 TCP 连接服务器间建立通讯的.这种
UDP 通信的目的在于加强文件搜索和源搜索功能,并更高效的使用客户端所拥有的服务器信
息. 本文第 3 部分详细分析了 eMule 的客户端-服务器 UDP 连接的报文交换机制.
图1.1 : eMule网络概观
1.2.2 客户端-客户端连接
eMule的客户端-客户端连接实现文件的共享,在共享过程中,文件被分为不同部分,每部分并
被细分为不同的块,一个客户端可以同时从多个不同的客户端处下载一个文件的不同部分.
当客户端-客户端连接建立后,两个客户端会进行传输性能信息交换,随后对上传或下载的开
始时间进行协调.每个客户端都会对发出下载请求的待下载客户端建立一个下载队列.当一个
eMule客户端的下载队列为空时,新的下载请求会立即开始下载会话,除非这个请求客户端被
源禁止.当这个下载队列非空时,新的下载请求就将请求客户端添加到下载队列底部.如果将
传输带宽最小值定为2.4kbytes/秒,一个客户端可同时进行的上传数通常不超过几个.在下载
队列中,允许一个正在等待的客户端取代正在下载的客户端,这取决于他们的队列优先级别,
在一个客户端开始下载会话的十五分钟之内,它在下载队列中的优先级别会提高到最高水平,
以防止频繁的下载竞争.
当一个待下载客户端到达下载队列顶部,上传客户端会在这两个客户端之间启动一个用于文
件传输的连接.一个eMule客户端可出现在多个源的待下载队列中,等待按部分从每个目标源
中下载文件.当客户端从其中一个源下载到文件的某些部分,这个下载客户端并不会告知所有
它在下载队列出现的源,并让它们删除这个下载客户端的请求.而是当其到达某个源的下载队
列顶部时,拒绝源的上传会话.
eMule使用了一种鼓励上传的信用机制(见1.4节),为了防止针对这种机制的冒名欺诈,eMule使
用RSA公钥算法.
客户端-客户端连接会用到一组不同于eDonkey协议中定义的报文,被称为扩展协议.扩展协议
提供一些增强服务,如信用机制的具体实现,增加的服务器和源列表更新功能,以及通过压缩
传输增强文件块传输的性能.
eMule的客户端-客户端连接中的UDP使用较为局限,主要用于客户端在对列中等待开始下载
时,周期性地查询其在队列中的状态.
1.3 客户端 ID
客户端ID是在客户端-服务器连接握手时由服务器提供的一组4字节辨识码.对于LowID而言,
这个客户端ID只在整个客户端-服务器TCP连接周期中有效;而对于HighID,客户端ID是由其
IP地址计算而来,只随IP的改变而改变.因此,客户端ID有HighID和LowID之分.典型的,eMule
服务器会给一个无法接收进入连接的客户端分配LowID.当一个客户端被分配LowID,将会在
eMule网络受到限制,并可能会因此引起服务器拒绝其连接.对于HighID而言,其ID是经下文中
描述的方法由IP计算而得.此处的计算和重要性判断是基于一个eMule具体实现[3]的.被授予
HighID的客户端需要具备如下条件,即其他客户端可以自由地连接到这台主机的eMuleTCP
端口(默认为4662端口). 被授予HighID的客户端在整个eMule网络中不受限制.然而,只要服务
器无法在客户端的eMule的TCP端口建立连接,就会给其赋予一个LowID.所以,一个客户端会
因如下情况被赋予一个LowID:
* 主机防火墙阻止了连入连接.
* 客户端使用NAT[5]或代理服务器连入网络.
* 服务器太忙(造成再连接计时器计时结束).
HighID按如下方法计算而得:
假设 IP 地址为 X.Y.Z.W,则客户端 ID 按公式 X+28*Y+216*Z+24*W (Big Endian[6])计算.而
LowID 总是一个小于 16777216(0x1000000)的值.作者并没有找到一个确定的 LowID 计算公
式,但是值得注意的是,LowID 的分配因服务器而异.
因为 LowID 没有相应的 IP 地址来建立客户端-客户端连接,所以,所有的通信需要 eMule 服务
器参与,这增加了服务器的负载同时也导致了服务器接收 LowID 客户端请求延迟.同时,这意
味着一个 LowID 客户端无法和在其他服务器上的另一个 LowID 客户端建立连接.因为 eMule
不支持服务器间的通道连接.为了支持 LowID 客户端, eMule 引入了一种回叫机制.通过运用
这种机制,HighID 客户端可以通过服务器询问一个 LowID 客户端,从而发起一个连接,并实现
文件交换.
1.4 用户 ID
eMule 支持一个鼓励上传的信用体系,当一个用户向其他客户端上传的文件量越大,它就会在
其他客户端的等待队列中享有更高的优先级别和更快的上升速度[3].用户 ID 是一组由随机
连接数字组成的 128 位(16 字节)GUID[7],其中,第 6 位和第 15 位是固定的,分别为 14 和 111.
与客户端 ID 只在和特定服务器的连接会话生命周期中有效不同,用户 ID(也叫做用户 Hash)
是独一无二的,它在每次的会话中都保持不变.因为用户 ID 在整个信用体系中扮演重要角色,
这也成了驱使一些所谓的”黑客”冒名替代信誉等级高的用户 ID的原因.因此,eMule使用了一
种加密机制来防止用户欺骗和冒名替代.这个加密机制的实现依赖于一种给予RSA公钥加密
系统的挑战-应答机制.
1.5 文件 ID
文件 ID被用于网络中文件识别和文件损坏检测及修复.需要注意的是,eMule并不是依靠文件
名对文件进行唯一性辨认和分类,而是使用一个通过文件内容散列出的全局唯一 ID 进行标
识和分类的.文件 ID 分为两种,其一主要用于产生唯一的文件 ID,第二种则用于文件损坏检测
与修复.
1.5.1 文件 Hash
GUID是客户端基于对文件内容进行 MD4 算法散列得出的一个 128 位标识符.计算时,文件被
分为以9.28MB为大小的块,通过结合每块的独立计算结果,最终得出文件 ID.当一个客户端结
束一个文件部分的下载,它会计算其Hash值,并与上传者提供的Hash值进行比较.一旦发现这
两个值出现不同,则检测到文件损坏.此时,客户端会按 180KB 大小逐渐替代这个文件部分的
块,直到最终的 Hash 值相符为止.
1.5.2 根 Hash
根 Hash 基于 SHA1 算法,它以 180KB 为大小对每个文件块进行运算.这样,提供了更强的可靠
性和错误修复能力.具体内容请访问 eMule 网站.
1.6 eMule 协议扩展
eMule 协议与 eDonkey 协议完全兼容的同时,还加入了一些扩展实现,从而使得 eMule 客户端
可以为用户提供一些附加功能.扩展协议主要在于客户端-客户端通信,尤其在于安全方面和
UDP 应用.本文中,所有 eMule 协议扩展部分的信息流都用灰色注明.
1.7 服务器容量限制
eMule 服务器有两种关于活动用户数的容量限制-硬限制和软限制.其中硬限制大于等于软限
制数.当服务器活动用户数超过软限制数,它将不再接受来自 LowID 的新连接;当达到硬限制
数,服务器饱和,不再接受任何客户端的连接.
2 客户端-服务器 TCP 通信
每个客户端仅与一个服务器建立 TCP 连接.这时,服务器会向客户端分配一个用于识别此客
户端的 ID,这个 ID 在整个客户端-服务器会话中有效(HighID 则根据其 IP 地址分配客户端
ID).eMule 的可视化界面客户端需要以建立一个客户端-服务器连接为前提,完成其他操作.客
户端不能同时与多个服务器建立 TCP 连接,除非用户干涉,客户端也不会自动地动态改变服
务器.
2.1 建立连接
当客户端试图建立客户端-服务器 TCP 连接时,它会并行地向几个服务器发送相关请求,然而,
当与其中一个服务器首先完成登录程序之后,将会排他地放弃向其他服务器发出的请求.
连接建立的过程有如下几种情况:
1.HighID 连接 – 服务器向
申请
关于撤销行政处分的申请关于工程延期监理费的申请报告关于减免管理费的申请关于减租申请书的范文关于解除警告处分的申请
连接的客户端授予一个 HighID.
2.LowID 连接 – 服务器向申请连接的客户端授予一个 LowID.
3.拒绝会话 – 服务器拒绝客户端请求.
当然,还存在一些其他的具体情况,如服务器停机或不可连接的情况等.
如下图 2.1 所示为 HighID建立连接的报文传输过程.在这种情况下,客户端建立一个到服
务器的 TCP 连接并向服务器发出登录(login)请求.之后,服务器建立另一个到该客户端的 TCP
连接,同时,服务器会发起一个由此客户端参与的客户端-客户端握手会话,并由此判断该客户
端是否具有接受由其他 eMule 客户端发起的连接的能力.再次之后,服务器将关闭这个会话连
接,传送一个改变 ID报文,以此完成客户端-服务器握手.图中的 eMule-info报文是灰色的,这代
表了这个报文是由 eMule 扩展协议(见 1.6 节)定义的.
图 2.1 : HighID 建立连接的报文传输过程
如下图 2.2所示,为LowID建立连接的报文传输过程,在这种情况下,服务器无法与请求连
接的客户端连接,所以,它将授予此客户端以 LowID.同时,服务器会发送一条诸如此的报文:”
注意,现在为 LowID 状态,请检查您的网络或客户端设置”.
无论是 LowID 还是 HighID,初次握手会话都将以接受一个 ID 变更报文为结束,这个变更报文
最终定义了客户端的 ID,为下次与服务器的会话做好准备.
图 2.2 : LowID 建立连接的报文传输过程
下图 2.3 所示是当服务器拒绝客户端的登录请求时的报文会话过程.服务器拒绝此会话
可能是因为达到其软限制且客户端为 LowID 或者达到了服务器的硬限制.在服务器返回的报
文中,将会有一个段简短的字符串描述拒绝会话的原因.
图 2.3 : 拒绝会话报文传输过程
2.2 连接启动的报文交换
当客户端-服务器连接成功建立之后,两者将进行一系列的报文交换,从而完成状态更新.起初,
客户端会向服务器提供它自由的共享文件列表(见 6.2.4),随后要求更新客户端所有的服务器
信息列表.这时,服务器会向此客户端发送关于其状态和版本的报文(见 6.2.6 和 6.2.2),此后,服
务器还会向此客户端发送更多关于其他 eMule 服务器的信息并提供更详细的自身信息.最终,
客户端向服务器发送源请求,服务器接受此报文后,对于该客户端的待下载文件列表中的每个
文件分别的发送相关的源列表,直到完成这一系列报文通信为止.整个连接启动报文交换过程
见下图 2.4.
图 2.4 : 连接启动的报文交换过程
2.3 文件搜索
文件搜索会话总是由用户操作引起的,整个操作过程可以简单地概述为一个文件搜索请求
(见 6.2.9)和对此请求的文件搜索请求应答(见 6.2.10).当搜索结果较多时,服务器返回的报文
会被压缩传输.随后,用户选择下载其中的一个或多个文件,客户端会为每个选择下载的文件
向服务器发起源请求.服务器会为每个请求返回一个源列表(见 6.2.12).在服务器发送源请求
回复之前,可能会先向客户端发送一个服务器状态报文.这个服务器状态报文(见 6.2.6)包含了
服务器关于目前服务器上用户和文件数量.值得指出的是,此处可能会使用 UDP 报文交换过
程从而加强客户端定位源的能力,详情请见第 3 部分.此时,eMule 客户端会确认源是可用的,
并按照它们添加到源列表中的顺序,启动与源的连接.图 2.5 描述了文件搜索报文交换过程.
虽然 eMule 客户端按照添加顺序与源进行连接,而没有源连接的优先级机制,但是 eMule 客户
端设计了一种解决从单一客户端获取超过一个待下载文件的机制.请注意, eMule 协议是只允
许客户端-客户端连接间存在一路上传.
选择算法基于用户的优先等级,当优先级想当时,则默认按照字母排序进行.解决从一个源客
户端下载多个文件的具体描述见 eMule 网站.
图 2.5 : 文件搜索报文交换过程
2.4 回叫机制
回叫机制用于解决 LowID 客户端无法接受进入连接而无法与其他客户端共享文件的问题.回
叫机制简述如下:加入有客户端 A 与 B,两者共在同一个 eMule 服务器之下,A 请求下载 B 上
的文件,然而 B 为 LowID 客户端.此时,为了能够共享文件,A 向服务器发送一个回叫请求(见
6.2.13),让服务器要求 B 回叫 A.因为服务器与 A 之间建立着一个 TCP 连接,服务器可以直接
传送给B一个回叫要求报文(见6.2.14),在这个报文中,提供了A的 IP地址和端口.这样, LowID
客户端 B 就可以直接不经过服务器与客户端 A 建立连接.显而易见,只有 HighID 客户端能要
求LowID客户端回叫.图 2.6表述了回叫报文交换过程.两个LowID客户端之间交换文件只能
依靠服务器当作中继,绝大多数服务器不支持这种方式,因为这样会给服务器带来很大负荷.
图 2.6 : 回叫报文交换过程
3 客户端-服务器 UDP 通信
eMule 客户端-服务器之间使用不可靠的 UDP 连接增强搜索功能并增加更新能力.在 eMule
客户端所生成的数据包中,UDP 数据包占到约 5%的数量.这个百分比值因客户端的服务器列
表中可用服务器数,下载文件可用源数,以及用户进行搜索的次数而变化.UDP 发包由一个以
100 毫秒为耗尽周期的计时器所控制,这也表明为何 eMule 客户端的相关专用线程会以最大
10 包/秒的速度发送 UDP 包.
3.1 服务器状态更新
eMule 客户端会周期性的对其服务器列表中的服务器状态进行更新.这个更新过程通过发送
UDP 服务器状态请求(见 6.3.3)和 UDP 服务器描述请求(见 6.3.7)完成.这里描述的服务器更新
机制每小时不过生成几十个UDP数据包,它的最大限度为0.2包/秒.每当客户端查询服务器状
态时,先发送一个服务器状态查询报文,服务器对每两次这样的查询报文响应一次,返回服务
器状态描述.整个过程见下图 3.1.
图 3.1 : UDP 服务器更新报文交换循环
在客户端发送的服务器状态更新请求中包含了一个随机生成数,这个数会包含在服务器响应
的报文中.如果返回的这个随机数与发送时不同,则抛弃这个服务器响应报文.每发送一条服
务器更新请求,客户端都会在一个叫做”尝试计数器”的计数器增加一.服务器的任何响应都会
将这个计数器的值置零.一旦这个计数器的值达到一个设置的限度,客户端认为这个服务器无
法响应,将其从服务器列表中去除.服务器应答包括如下一些数据项:服务器状态应答(见 6.3.4)
包括服务器用户数和文件数,服务器软限制和硬限制数.服务器描述应答(见 6.3.8)包含服务器
名称和一个简短的描述字符串.下图 3.2 描述了客户端-服务器间的更新报文交换过程.
图 3.2 : UDP 服务器更新报文交换过程
3.2 文件搜索增强
eMule 客户端可以通过 UDP 增强文件搜索功能.UDP 搜索请求的报文格式与 TCP 搜索请求
的报文格式(见 2.3)基本相同.服务器只有在它有搜索结果的时候才会应答.UDP 文件搜索请
求包会发送给所有在客户端的服务器列表中的服务器.详见 6.3.5 和 6.3.6.
3.3 源搜索增强
当客户端的某个待下载文件的源列表中的可用源数量少于某设定值(通常为100)时,客户端会
周期性的发送UDP源搜索请求包,这些源搜索请求包发给搜索在这个客户端的服务器列表中
的服务器.这些包通常每秒发送一次.从数量上讲,这是客户端 UDP 包发送流量的主要部分.源
搜索报文(见6.3.1)格式与TCP的源搜索格式几乎相同.一个需要注意的不同点在于,UDP源搜
索是独立于文件搜索的,它仅取决于某个待下载文件现有的源数量.
4 客户端-客户端 TCP 通信
eMule 客户端完成了在服务器上的初始会话,查询所需的文件和源后,此时,客户端需要和其他
客户端建立连接以下载文件.每对文件-客户端都会建立一个 TCP 连接.当对方客户端终止连
接或在一定时间内(默认为 40 秒)无活跃网络 Socket 时,TCP 连接会断开.
为了达到一定的下载速度,eMule 直到两个客户端之间的连接速度大于一个速度下限时才允
许开始文件传输,这个值目前被设置为 2.4kbytes/秒.
4.1 初始化握手
握手会话是对称的,客户端-客户端连接的两者都向对方发送相同的信息.两个客户端交换诸
如识别,版本号和性能等信息.在这个过程中,有两种报文参与.其一,是 Hello 报文(见 6.4.1),它
是 eDonkey 协议的一部分并与 eDonkey 客户端兼容;另一个报文是 eMule 信息报文(见 6.5.1),
它属于 eMule 扩展协议.下图 4.1 描述了两个 eMule 客户端之间的握手会话过程.在扩展信息
中,包括有 UDP 报文交换,安全认证和源交换.
图 4.1 : 客户端初始化握手
4.2 用户身份认证
第 1.4 节简要的介绍了用户 ID 和信用体系,也提到了由此产生的用户 ID 冒名威胁.用户身份
认证是 eMule 协议的一个扩展内容,只要客户端支持这种用户身份认证,它会在初始化握手之
后立即完成.所以,使用用户身份验证正是为了防止用户 ID 顶替,整个验证过程按如下步骤进
行:
1. 在初始化握手过程中,客户端 B 表示它支持用户身份验证并期望使用此功能.
2. 客户端 A 对 B 的报文进行回应,它发送身份验证报文(见 6.5.8),并表明是否需要 B 的公钥.
这个报文还包含了一个等待 B 回应的 4 字节挑战.
3. 如果 A 需要 B 的公钥,B 将这个公钥发送给 A(见 6.5.9).
4. 客户端 B 根据 A 发送的挑战和一个附加双字生成签名,并按照签名报文(见 6.5.10)发送给
A.此处的附加双字是根据 B 或 A 的 IP 产生的,当 B 是 LowID 时,这个双字为 A 的 IP 地址,当
B 为 HighID 时,这个双字为 B 的 ID 值.下图 4.2 描述了身份验证过程.
图 4.2 : 身份验证过程
4.2.1 信用体制
本段简述客户端的信用机制,如前所述,这种信用机制的主要目的在于鼓励上传.当一个上传
客户端向一个下载客户端上传文件时,这个下载客户端会根据所收到的数据量增加对上传客
户端的信用评价.此处的上传客户端信用并不是全局范围之内的,它的信用的增加只体现在当
它下载此时这个下载客户端的某些文件时.也就是说,一个客户端的信用分别建立再各个它曾
经上传过的客户端上.信用等级的计算如下:
1. (总上传量*2)/总下载量.
这个计算式的最大值取 10,当总下载量为 0 时,此值默认为 10.
2. Sqrt(总上传量+2).
当总上传量小于 1Mb 时,这个表达式最小值取 1.
总下载/上传量都以 Mb 为单位进行计算,按上边的公式,一个客户端的信用等级为一个取值范
围为 1 到 10 的数.
4.3 文件请求
如前所述,按照 eMule 协议,会为每个客户端-文件对建立一个 TCP 连接.当连接建立以后,客户
端立即发送一些请求报文,请求下载它期望获得的文件.一个典型的成功的文件请求过程如图
4.3 所示.
图 4.3 : 文件请求过程
4.3.1 基本报文交换
基本报文交换由四组报文组成,客户端 A 首先发送一个文件请求报文(见 6.4.18),紧接着发送
一个请求文件 ID 报文(见 6.4.17).随后,客户端 B 发送文件请求应答(见 6.4.15)和文件状态(见
6.4.18)报文.这个过程可以看作是 A 和 B 两个客户端进行的一问一答的报文交换过程.
eMule扩展协议在这个过程中还加入了一对源请求(见6.5.6)和源请求应答(见6.5.7)报文.这对
扩展的报文交换可以将客户端 B 的源信息传给 A.为了加强客户端的协作功能,客户端 B 可以
在尚未完成下载的时候就将它已经完成的文件部分传给客户端 A,即便客户端 B 仅仅下载了
这个文件的一小部分.
4.3.2 未找到文件报文交换过程
当客户端 A 向客户端 B 请求一个文件时,若 B 的共享文件列表中并没有这个文件,B 将不发送
文件请求应答报文,而是在客户端 A 发送文件 ID 请求后,立即发送一个未找到文件报文(见
6.4.16).详见下图.
图 4.4 : 文件请求失败-未找到文件
4.3.3 加入上传队列
当 A 和 B 按照图 4.3 完成文件请求的握手对话后,B 客户端也有 A 客户端所需要的文件,然而
此时B的上传队列并非为空,亦即是说有其他客户端正在下载B的文件.在这种情况下,B会先
将 A 添加在它的上传列队中,并发送给 A 一个队列排名报文(见 6.5.4),这个报文包含了 A 在
队列中的位置以及 B 的上传队列的相关信息.详见下图.
图 4.5 : 文件请求等待队列
4.3.4 上传队列管理
客户端为每个上传文件维护一个上传优先级队列,在这个上传队列中,待下载客户端的优先级
是根据它在这个队列中的时间以及一个优先级参数共同计算的.在队列的顶端是优先级得分
最高的客户端.具体的优先级计算公式为:优先级=(等级*在队列中时间)/100.此处的等级值有
如下几个情况,若对方客户端为好友,则此值为无穷大,即表明好友的优先级为无穷大,直接到
达队列顶端开始下载.若客户端为普通待下载客户端,等级的初始值为 100.若对方为被禁止的
客户端,则此值为 0,使其永远无法到达队列顶端,拒绝其下载要求.对于普通用户而言,这个等
级值随后根据客户端信用和下载文件本身的优先级变化,下载文件优先级取值范围为 0.2-1.8,
上传用户可以对此进行调整.当一个待下载客户端比队列里的其他客户端具有更高的优先级
时,它便开始下载.它将保持下载直到发生以下情况:
1. 上传客户端退出.
2. 下载客户端下载完毕.
3. 待下载队列中有其他客户端优先级超过了正在下载的客户端优先级.
为了可以让正在下载客户端完成至少一定量的下载,eMule 上传客户端会在下载开始前十五
分钟将下载的等级调到 200 以防止频繁的下载竞争.
4.3.5 达到队列顶端报文交换过程
当客户端 A 到达客户端 B 的上传队列顶端,B 将向 A 发出连接,进行初始化握手会话.接着,B
向 A 发送一个接受上传请求报文(见 6.4.11).此时,若 A 选择继续并下载文件,它会向 B 发送一
个请求文件部分报文;若 A 已经获得了这部分文件,则它会向 B 发送一个取消传输报文(见
6.4.12).下图详细描述了这两种报文传递过程.
图 4.6 : 达到队列顶端报文交换过程
4.4 数据传输
4.4.1 数据包
eMule 网络活动主要在于发送和接受文件部分.一个文件部分的大小由 5000 到 15000 字节.
为了防止产生文件碎片,一个文件部分报文被分开在一个 TCP 数据包的许多片断内.以
eMule0.30e 客户端为例,其最大片断大小为 1300 字节.这又就是说,尽管控制类的报文都在一
个 TCP 数据包中完全包含,而有的时候数据报文是被分在几个 TCP 包中的.其中,第一个包中
包含了传送部分的报文头(见6.4.3),其后的包中就只包含数据.如果当文件被1300字节整除而
有余数时,不足一个包的数据将和报文头一起放在第一个包中.详情见下图 4.7.
图 4.7 : 文件包传输过程
4.4.2 文件传输报文交换过程
文件传输报文交换在文件请求应答后立即开始,此时待下载客户端 A 发送一个启动上传请求
(见 6.4.10),目标客户端会回复一个接受上传请求报文(见 6.4.11).紧接着,客户端 A 开始请求
文件部分(见 6.4.4),随后客户端 B 向其发送被请求的文件部分(见 6.4.3).此处的文件部分请求
可以请求最多 3 个文件部分,所以,这样的情况下,一个文件部分请求报文最多会导致 3 个文件
部分的传输过程.
当上传下载客户端都支持 eMule 扩展协议时,文件部分可以压缩传输(见 6.5.3),同时,扩展协议
还支持文件信息报文(见 6.5.5),这个报文会在接受上传请求前发送.文件传输报文交换过程详
见下图.
图 4.8 : 文件传输报文交换过程
4.4.3 下载选择
eMule 客户端会按照一定规则选择下载文件各部分的顺序,通过这样的机制,试图达到整个网
络共享的优化.如前所述,共享的文件都按照 9.28Mb 为单位分割为文件部分,每个部分又被细
分为 180Kb的文件块.文件部分的下载顺序由下载客户端所决定,它在下载时发送文件部分下
载请求报文(见 6.4.4).下载客户端可以在任意已知的源处下载任意未获得的文件部分,一个部
分内的各个文件块则从同一个源处获得.文件部分的下载顺序依照如下原则进行选择:
1. 按可获得文件块选择:极稀缺文件块应以最快速度下载,从而未其他客户端做源.
2. 用于预览和检查的文件块先下载.
3. 按请求要求:从不同源出按请求顺序下载.
4. 按完成速度:即将完成的文件块优先下载.
在衡量文件部分下载顺序时,引入频率参数.它可被划分为极稀缺,稀缺和普通.在这三种情况
下,计算文件部分等级时,频率分别有不同的影响加权.文件部分的下载等级值越低则越先被
下载.这个值的计算方法如下:
•0-9999 – 被请求或未被请求的极稀缺文件部分.
•10000-19999 – 未被请求的稀缺文件部分和预览文件部分.
•20000-29999 – 未被请求的即将完成文件.
•30000-39999 – 被请求的稀缺文件部分和预览文件部分.
•40000-49999 – 被请求的普通文件部分.
这个算法总是选择最稀缺的文件部分进行优先下载,即将下载完成的文件部分也会被优先选
择.对于普通文件部分而言,会在许多不同的源处下载.
4.5 查看共享文件
有两种报文流用于查看其他客户端的共享文件和文件夹.其一,查看共享文件报文(见 6.4.21)
会在初始化握手后立即发送,随后,对方会发送查看共享文件应答报文(见 6.4.22).如果应答的
客户端想要隐藏共享文件列表,则返回的应答中不包含任何文件(并不告知对方请求被拒绝).
下图描述了查看共享文件报文交换过程:
图 4.9 : 查看共享文件报文交换过程
第二种情况,报文流开始于一个查看共享文件夹列表请求(见 6.4.23),对方客户端将以共享文
件夹列表(见 6.4.24)作为应答.随后,客户端发送查看共享文件夹内容报文(见 6.4.25),对方客户
端则发送共享文件夹内容列表(见 6.4.26).下图 4.10 描述了这样的报文传递过程.
图 4.10 : 查看共享文件夹报文传递过程
如果对方客户端阻止查看共享文件和文件夹,则将返回一个查询被拒绝报文,见下图 4.11.
图 4.11 : 拒绝查看共享文件夹
4.6 交换文件 Hash
为了获得一个已下载文件部分的 Hash 值,客户端会向上传客户端发送一个 Hash 请求报文(见
6.4.8),上传客户端会发送一个 Hash 值回复(见 6.4.9).这个报文中包含了每个文件部分的 Hash
的集合.详见下图.
图 4.12 : Hash 值请求报文
4.7 预览文件
客户端可以向其他客户端请求预览一个共享文件.总的来说,预览因不同的文件种类的差别和
应用程序的不同而各有不同.eMule0.30e 版本仅支持图像预览.正如下图 4.13 所示,整个过程
包含了文件预览请求(见 6.5.11)和文件预览应答(见 6.5.12).
图 4.13 : 文件预览过程
5 客户端-客户端 UDP 通信
eMule 客户端周期性的使用 UDP 发送报文.在 eMule0.30e 中,UDP 报文仅用来查询客户端在
其他上传客户端的队列中的位置.这是一个简单的查询-应答机制,首先由客户端发送一个询
问文件报文(见 6.6.1).如下图所示,一共有三种不同的应答:
1. 队列等级 – 客户端在上传队列重的等级.
2. 队列已满 – 上传客户端的队列已满.
3. 未找到文件 – 上传客户端并没有这个文件.
这个询问报文约每 20 分钟向每一个将其加入上传队列的客户端发送一次.
图 5.1 : 查询文件报文交换过程
参考文献
[1] D. Bickson and D. Malkhi. A study of privacy in file sharing networks. In Technical Report
TR-2003-67 Leibniz
Research Center, the Hebrew University of Jerusalem, Israel, 2003.
[2] eMule at source force. http://sourceforge.net/projects/emule/
[3] eMule project. http://www.emule-project.net/
[4] MD4 hash function specification. http://www.ietf.org/rfc/rfc1320.txt
[5] NAT. http://baike.baidu.com/view/16102.html?wtp=tt
[6] Little Endian & Big Endian. http://dev.csdn.net/article/39/39864.shtm
[7] GUID. http://baike.baidu.com/view/185358.html?wtp=tt
6 附录 – 报文编码
6.1 报文编码
这节将讨论关于在 TCP/UDP 连接中报文编码的广义实现.
6.1.1 大尾 or 小尾
在 eMule 协议中用到的所有报文都以小尾(Little-Endian)形式而非大尾(Big-Endian)形式出现,
这是网络上字节的习惯顺序.这也是因为客户端-服务器大多是基于使用 Windows 系统和
Intel 处理器的机器.
6.1.2 报文头
所有报文都包含一个 6 字节报文头,其结构由一下几个内容构成:
1. 协议 – 表示客户端使用的协议 - 0xE3 表示使用 eDonkey 协议 ,0xC5 表示使用 eMule
协议.
2. 大小 – 4 字节的报文大小描述 – 报文大小(不包含报文头),例如一个报文(见 6.4.11)除了
报文头之外没有内容,则其大小为 0.
3. 类型 – 占 1 字节 –
记录
混凝土 养护记录下载土方回填监理旁站记录免费下载集备记录下载集备记录下载集备记录下载
一个独一无二的报文 ID.
6.1.3 报文标志
报文标志是和上边描述的协议,类型,大小结构类似的一种结构,它主要用于将可选数据添加
在报文之后.报文标志分为几类,本节将罗列出每一个类型.文中描述报文标志时,只会提及其
标志类型,读者应将本节视同一个参考,用来查询每种标志类型的结构.
每个报文标志有 4 个域,并不是所有的报文都使用这 4 个域.
1. 类型 – 1 字节整型
2. 名称 – 1 字节整型或可变长度字符串.
3. 值 – 4 字节整型或 4 字节浮点型或可变长度字符串.
4. 特殊标志 – 1 字节整型,用于特殊用途
按照类型,报文标志可以分为字符型标志, 整型标志和浮点型标志,分别编号为 2,3,4.当标记
进行编码时,按照先类型再名称再值的次序进行编码,类型编码为一个字节,名称按照值方式
编码为一个 2 字节的值.例如,一个整型名称 0x15 将会被编码为 0x01 0x00 0x15 的序列.对于
值的编码而言,整型和浮点型值会按照他们本身的值编码,而字符型值会按照与名称相同的方
式进行编码.
注意:这里的标志名称并不是协议意义上的名称,仅仅是为了方便描述后文协议中的报文而提
出的.
6.2 客户端-服务器 TCP 报文编码
本节将具体介绍客户端-服务器之间传输的 TCP 报文.
6.2.1 登录
登录报文是在客户端-服务器之间建立了 TCP 连接后第一个被发送的报文.这个报文的长度
依用户的信息而变化,比如用户昵称的长度就会影响这个登录报文的长度.
名称 大小(字节) 默认值 注释
协议类型 1 0xE3
大小 4 以字节计的报文大小,不计报文头和大小域本身
类型 1 0x01 操作码 OP LOGINREQUEST 的值
用户 Hash 16 详见 1.4 节
客户端 ID 4 0 第一次连接此值通常为 0,详见 1.3 节
TCP 端口 2 4662 客户端默认的 TCP 端口
标签数 4 4 此报文中的标签数
名称标签 可变 NA 用户昵称.此标签为字符串标签,名称为整型值 0x1
版本标签 8 0x3C 客户端版本号,整型标签,名称为整型值 0x11
端口标签 8 4662 客户端使用 TCP 端口号,整型标签,名称为整型值
0x0F
标识标签 8 0x01 整型标签,名称为整型值 0x20
6.2.2 服务器报文
服务器报文是一种变长报文,它在不同情况下由服务器发送给客户端.这个报文第一次发送发
生在客户端登录请求之后.一个服务器报文通常由多个报文组成,它们由分行符分隔开.有一
些特殊的服务器报文以”服务器版本”,”警告”,”错误”或”emDynIP”开头,这中报文对客户端有
着特殊用途.而其他普通的服务器报文则仅仅简单的显示给用户.
名称 大小(字节) 默认值 注释
协议类型 1 0xE3
大小 4 不包含报文头和大小域的报文大小
类型 1 0x38 操作码 OP SERVERMESSAGE 的值
大小 2 NA 报文剩余部分的大小
报文 可变 NA 由分行符分隔的服务器报文列表
特殊报文:
1.版本 – 通常用于成功的握手连接.
2.错误
3.警告 – 用于服务器拒绝连接或客户端为 LowID.
4. emDynIP.
6.2.3ID 更改报文
ID 更改报文是服务器发出的客户端登录报文的响应,表明服务器接受了客户端的连接.此报
文大小为 14 或 10 字节,具体的大小取决于可选 TCP 连接位图.
名称 大小(字节) 默认值 注释
协议类型 1 0xE3
大小 4 不包含报文头和大小域的报文大小
类型 1 0x40 操作码 OP IDCHANGE 的值
客户端 ID 4 NA 详见 1.3 节
TCP 连接位
图
4 0x00000001 目前为止,只有一个位有具体含义,这位为 1 时,表
示服务器支持压缩传输
6.2.4 提供文件报文
这个报文是客户端用来描述本地可供下载的共享文件的报文.如果客户端有可以提供共享的
文件,则这个报文在建立连接后会立刻传输.当客户端的共享文件列表发生变化时,也会传输
这个报文.这个报文也用作更新,会周期性地发送给服务器.如果服务器支持压缩,这个报文会
被压缩传输,但如果是用于更新用途,则不会压缩处理.
名称 大小(字节) 默认值 注释
协议类型 1 0xE3
大小 4 不包含报文头和大小域的报文大小
类型 1 0x15 操作码 OP OFFERFILES 的值
文件数 4 NA 共享列表中的文件数,这个数不超过 200,服务器也
能设置一个更小的上限数
文件 可变 NA 可选的文件列表,单个项的描述见下
单个文件项格式:
下表描述的是单个文件项的格式,多个文件项会集中在一个提供文件报文中.
名称 大小(字节) 默认值 注释
Hash 码 16 NA 对文件内容的 Hash 结果,用于唯一的标志文件而独
立于不同客户端的不同命名
客户端 ID 4 NA 客户端 ID 为 HighID 时的值
客户端端口 2 0x15 客户端的 TCP 端口,为 LowID 时此值为 0
标志数 4 NA 此域后的标志数
文件名标志 可变 NA 强制标志,整型,标志名为 0x1 的整型值
文件大小标
志
8 NA 强制标志,整型,标志名为 0x2 的整型值
文件类型标
志
可变 NA 可选,类型可为” Audio”, ”Video”, ”Image”, ”Pro”
或”Doc”. 字符串型,标志名为 0x3 的整型值
文件格式标 可变 NA 可选,扩展类型,可为”zip”,”exe”等类型, 字符串型,
志 标志名为 0x4 的整型值
媒体长度标
志
可变 NA 当文件类型为 mp3 时,记录声音长度. 字符串型,标
志名为”长度”
媒体比特率
标志
TBD NA 当文件类型为 mp3 时,记录比特率. 字符串型,标志
名为”比特率”
媒体解码标
志
可变 NA 当文件类型为电影相关类型时,记录解码信息. 字
符串型,标志名为”解码”
6.2.5 获取服务器列表报文
此报文会在服务器-客户端初始化握手后由客户端发送,或者在客户端需要更多的服务器时
由其发送.报文长度为 6 字节.
名称 大小(字节) 默认值 注释
协议类型 1 0xE3
大小 4 不包含报文头和大小域的报文大小
类型 1 0x14 操作码 OP SERVERSTATUS 的值
6.2.6 服务器状态报文
此报文有服务器发送给客户端,包含了服务器上的用户和文件数量.这些信息由客户端保存,
并显示给用户.报文大小为 14 字节.
名称 大小(字节) 默认值 注释
协议类型 1 0xE3
大小 4 不包含报文头和大小域的报文大小
类型 1 0x34 操作码 OP OFFERFILES 的值
用户数 4 NA 目前登录此服务器的用户数量
文件数 4 NA 服务器获取信息的文件数量
6.2.7 服务器列表报文
此报文由服务器发送给客户端,告知客户端其他可用于扩展功能的服务器.报文大小因服务器
列表中服务器数量而变化.
名称 大小(字节) 默认值 注释
协议类型 1 0xE3
大小 4 不包含报文头和大小域的报文大小
类型 1 0x32 操作码 OP SERVERLIST 的值
服务器数量 1 NA 服务器列表中服务器数量
服务器信息 服务器数
量*6
NA 服务器的地址信息,每个服务器为 6 字节,4 字节 IP
地址,2 字节为 TCP 端口信息
6.2.8 服务器识别报文
此报文由服务器发送给客户端,包含了服务器的 hash(TBD),服务器 IP 地址,TCP 端口(这个端
口号在实用协议连接时有用)以及服务器描述信息.报文的大小可变.
名称 大小(字节) 默认值 注释
协议类型 1 0xE3
大小 4 0x41 不包含报文头和大小域的报文大小
类型 1 NA 操作码 OP SERVERIDENT 的值
Hash 16 NA 服务器的 GUID,用于调试
服务器 IP 4 NA 服务器的 IP 地址
服务器端口 4 NA 服务器监听的 TCP 端口
标志数 4 NA 报文之后的标志数
服务器名称
标志
可变 NA 服务器名称, 字符串型, 标志名为 0x1 的整型值
服务器描述
标志
可变 NA 服务器描述字符串, 字符串型, 标志名为 0xB 的整
型值
6.2.9 搜索请求报文
此报文由客户端发送给服务器,用于搜索由用户提供的一个字符串所对应的文件.报文大小可
变.在搜索字符串中可能会包含’AND’’OR’或 ’NOT’等布尔型字符.用户也许会为搜索进行定
制,限定文件的类型,大小或者为文件搜索提供其他前提.
名称 大小(字节) 默认值 注释
协议类型 1 0xE3
大小 4 0x16 不包含报文头和大小域的报文大小
类型 1 NA 操作码 OP SEARCHREQUEST 的值
搜索字符串
文法
可变 NA 搜索字符串的文法在此声明
文件类型限
制
可变 NA 可选,字符串类型的限制,可选的格式
为”Audio”, ”Video”, ”Pro” 或”Image” 共包含 3 字
节: 0x1 0x0 0x3
最小限制 可变 NA 可选,整型限制,以Mb描述,包含 4字节: 0x1 0x1 0x0
0x2
最大限制 可变 NA 可选,整型限制,以Mb描述,包含 4字节: 0x2 0x1 0x0
0x2
附加限制 可变 NA 可选,整型限制,设定一个拥有此文件的客户
浙公网安备 33021202002483