eMule 通讯协议

eMule 协议说明 书 关于书的成语关于读书的排比句社区图书漂流公约怎么写关于读书的小报汉书pdf 1 简介 1.1 目的 eMule 是一个如今非常流行的基于eDonkey协议的文件共享程序。 本文描述了eMule的 网络行为并且解释了一些我们理解这个协议所需要的基本学术用语。 并且本文也是 eMule网络协议的一个详尽的说明书，内容包括传送的消息的结构， 本文中所有的信息 是基于一个开源的eMule的客户端[2]。下文的目的是让读者有一个整体的概念去阅读和 理解这些文档.一个关于eMule的巨大信息. [3]。 1.2 概述 eMule网络是由数百台eMule服务器和数百万的eMule客户端组成的[1]。为了进行网络通 信客户端将连接到一个服务器，只要这个客户端还在这个系统当中这个服务器连接就一 直存在。这些服务器集中执行这索引服务(就像在Napster中一样)并且不与其它的服务器 进行交流。每一个eMule客户端都在其本体文件系统中预先配置了一个服务器列 表 关于同志近三年现实表现材料材料类招标技术评分表图表与交易pdf视力表打印pdf用图表说话 pdf 和共 享文件列表文件。客户端只使用TCP来连接服务端来加入网络,获得想要的信息和可以连 接的客户。同时eMule的客户端也使用成百的TCP连接到其它的客户端来上传和下载文 件。每一个eMule客户端为它的每一个共享文件维持一个上传队列。下载者刚加入队列 的时候在队列的底部并且组建的前进,直到他们到达顶部才开始下载他们需要的文件。一 个客户端可以从其它的几个客户端那里同时下载，取得他们所拥有的不同的文件片段。 客户端同时也上传那些还没完全下载的文件。 最重要的是eMule对eDonkey 进行了扩 充，允许客户端之间交换服务器信息，其它的客户端和文件信息.注意客户端与服务端的 通信都是以TCP协议为基础的。服务器使用本身的数据库来存储用户和文件信息。一个 eMule服务器不保存任何文件，它充当了文件位置索引表的功能.服务器的另外一个值得 争议功能是透过防火墙连接两个客户端，并且不能够引入连接。桥连接函数急剧的增加 了服务器的负载。eMule在客户端和服务端都使用UDP协议来提高客户的接受能力.客户 端接收和发送UDP数据的能力不取决于客户的正确操作并且即使防火墙阻止发送和接 受UDP数据也可以无差错的工作。 1.2.1 客户到服务器的连接 在启动客户端之前先使用TCP协议连接到一个eMule服务器。服务器提供给客户端一个 客户端ID (1.3章节)这个ID在整个客户端服务端连接的生命周期都有效 (注意:拥有high ID的客户端在IP地址改变之前将从所有的服务端获得同等级的ID)。连接确立之后客户 将自己的共享文件列表发送给服务器.服务器将这些列表存在它本身的的数据库 Figure 1.1: eMule high level network diagram 中，通常这些数据库包含了成百上千的共享文件清单和有效的客户端。eMule客户端同 时也下载它想获得的文件的文件列表.第二章节详细的描述了eMule的客户端和服务端 的TCP信息交换。在连接确立之后，eMule服务器将发送给个客户端一份客户端列表,这 个列表中的客户端中有下载者想下载的文件（这些客户端叫做“源”）。从此刻开始， eMule客户端像下面的1.2.2章节中描述的一样开始建立和他客户端的连接 注意客户端/服务端得TCP连接在整个客户端会话过程中持续开放。在初次握手协议之后 的就主要是用户活动:客户端为了获得新的搜索结果不时地发送搜索请求，一个搜索通 常紧跟着是一个对于特殊文件资源的查询，回复查询的清单是由能下载到该文件的资源 (IP和端口)组成。UDP是用来与服务器端之间的信息交换而不是服务器端与它相连的客 户端之间交流。UDP消息的目的是增加文件搜索,增加资源搜索，最终保持活跃性(确保 客户端中的服务器列表中的服务器都是有效的)。您可以再第3章节中找到更多关于客户 端-服务端UDP信息交换的详细资料. 1.2.2 客户端和客户端的连接 一个eMule客户端为了下载文件而连接到其他的eMule客户端(一个资源)。文件被分割为 几个部分每个部分又是由更多的片段组成。一个客户端可以从许多(不同的)客户端下载 同一个文件的获得不同的片断。当两个客户端连接时他们交换接受能力信息，然后商议 开始下载(或者上传,取决于需求)。每一个客户端拥有一个下载队列来保存等待下载文件 的客户端。当一个eMule客户端清空下载队列通常是由于要开始一个下载(例外,例如：这 个请求着被禁止)。当下载队列不清空时将导致队列中请求客户的增加。在给定的时间 内即便是每个客户用最小的带宽2.4kb/s也只能服务极少数的客户。如果在15分钟的下载 过程队列中中有比正在下载的用户更高级的用户，该用户将抢占下载中的用户进行下 载，这样做来防止长期等待。当一个下载中的客户端到达下在队列的最顶端,上传客户端 就会发起一个连接来传输下在端需要的部分。一个eMule客户端或许同时在许多许多其 它的客户端的等待队列中,去下载一个文件的同一部分。当等待中的客户端实际上已经下 载完成了该部分(从他们其中的一个)它并不通知其他剩下的所有客户端可以从等待队列 中将其清除,她仅仅是在他到达等待队列的顶端是时拒绝那些客户端的上传请求。eMule 采用了一个荣誉系统(看1.4章节)来鼓励上传，采用RSA公开密钥加密算法来保护eMule 荣誉系统的安全性。客户的连接使用的是eDonkey协议中没定义的一组消息，这些消息 被叫做扩展协议。这个扩展协议用来实现荣誉系统，用来说明信息交换(例如更新服务 器和资源列表)和提高传送和接受压缩数据块的性能。eMule客户端仅在他要开始下载文 件时使用UDP去检查他的上传队列中的每一个客户端的状态。 1.3 客户 ID 客户端在与服务端进行握手连接时,服务端给客户端一个4字节的标示符作为客户端 ID。一个客户端的有效ID仅在客户-服务器的TCP连接中获得，有时该客户端端可能是 High ID 但是直到它的IP地址改变之前对于所有的服务器他将赋予同一个ID。客户端ID 被分为low IDs和high IDs。当客户端不能接受连入连接请求时eMule服务端将把它们标示 为low ID。拥有low ID的用户将被限制使用eMule网络并且可能导致服务器拒绝客户端的 连接.想下面描述的一样一个high ID的计算以这个客户端的IP地址为基础。本章从eMule 协议的角度上来描述客户ID的任务和意义[3]。一个被给与high ID的客户端允许其他的 客户端自由的连接到他主机的eMule的TCP端口(默认的端口号是4662)。拥有high ID的客 户端可以无限制的使用eMule网络。当服务端不能够与客户端的eMule端口建立TCP连 接，该客户端奖杯给予low ID。只主要是由于客户端在他们的机器上设立的防火墙阻止 引入的连接。由于下面的情况客户端同样也有可能获得low ID: •当客户端是通过NAT或者代理服务器连接的 •当服务端过于繁忙(导致服务端的重接计时器到时间) Hifh ID是通过下面的方法计算的：假设主机的IP是X.Y.Z.W 这个ID将是 X+2 8*Y +216*Z +2 24 *W(’big-endian 表示法)。一个low ID总是小于16777216 (0x1000000)，我找不到过 于他是如何计算的线索，注意不同的服务器中你拥有的lowID是不同的。一个low ID没 有允许其他客户端客户连入的公共IP，所以所有的信息必须通过eMule服务器。这增加 了服务器的计算负担并且直接导致了服务器不愿意接受low ID客户。同样这也意味着不 同服务器之间的low ID用户之间不能够建立连接，因为eMule不支持服务器之间的请求 通道。为了支持low ID用户复查机制被引入了。通过这个机制一个high ID客户可以邀请 (通过eMule服务器)low ID用户和它建立连接来交换文件。 1.4 用户 ID eMule支持一个荣誉系统来鼓励使用者共享文件。用户上传给其他用户的文件越多,他就 能获得更多的荣誉同时它们在等待队列中前进的就越快[3]。用户ID是由连接随机数创造 的一个128位(16字节)的GUID，第6字节和第15字节不是随即产生的，它们的值分别是14 和111。当客户端与特殊的服务端绘画取得有效的客户ID时用户ID(也叫做用户哈西数) 是唯一的并且通过会话识别客户(用户ID识别工作站)。用户ID在荣誉系统中扮演了重要 角色，这也为’hackers’模仿其他的用户利用它们的荣誉度获得特权提供了动机。eMule 支持一种加密方案来阻止欺骗和用户扮演。执行一个简单的依靠RSA公开/私有密钥加密 算法的挑战相应交换。 1.5 文件 ID 文件ID即使用网络中文件的识别也用在文件的正确性检测和修复上面。注意eMule不是 依靠文件名来唯一的识别和记录一个文件，一个文件通过对其进行哈西算法而得出来的 全球唯一的ID来标示。有两种文件ID-第一种主要用来产生唯一的文件ID，第二中用来 进行正确性检测和修复[3]。 1.5.1 文件哈西 文件通过根据其内容计算出来的的唯一的一个128位GUID哈西数来标示出来。这个 GUID是根据文件内容适用MD4运算规则[4]计算出来的。当计算文件ID时该文件备分割 为许多份每一分大小为9.28MB。每一部分独立的算出一个GUID,然后所有的哈西数载结 合起来组成一个文件ID。当一个下载客户下载万文件的一部分时特就会计算该部份文件 的哈西数并且将它与源文件的哈西数进行比较，如果这部份文件有错误，客户端将尝试 着修复错误处，具体做法是每次替代错误处一定位数(每次180kb)的数据直到计算出来的 哈西数是正确的。 1.5.2 跟哈西 跟哈西是通过SHA1运算法则来计算文件的每一部分，每一部分的大小是180kb。它提供 了一个极高的可靠性和错误修复能力，详细的细节在eMule的官方网页上。 1.6 eMule 协议的扩展 尽管eMule完全的兼容了eDonkey,但是他还实现了几个扩展来允许两个客户端之间向他 们的使用提供附加的功能。这些扩展主要用于客户端与客户端之间的信息交换尤其是安 全领域和UDP协议的利用。在本文当中所有eMule扩展部分的流程图制定消息都是灰色 的。 1.7 软界限和硬界限 服务器的配置包含两种界限，这取决于使用中用户的数目-软界限和硬界限。硬界限比 软界限提供更大的平衡。当使用中的用户的数目达到软界限时服务器停止接受新的low ID用户的连接，当使用者数目达到硬界限的时候服务器就满了并且不再接受任何连接。 2 客户服务器TCP信息 每一个客户端使用TCP连接连接到唯一一个制定的服务器。这个服务器将分配给这个客 户端一个ID，这个ID将在该客户与其他服务器会话的过程中唯一的标示自己(一个high ID用户总是依据其IP地址进行分配的)。为了使一个eMule图形用户界面客户端运作起来 首先要和服务器建立一个连接。客户端既不能同时连接多个客户端也不能再没有用户的 干涉下自动改变客户端的连接。 2.1 连接的建立 在建立与服务器的连接时客户端尝试着向许多平行服务器建立连接，成功登陆序列之外 的将全部被放弃。 图 2.1: High ID 登录序列 有许多可能成功建立连接的情况： 1．High ID连接 - 服务器分配给连入的客户端一个 high ID 2．Low ID连接 - 服务器分配给连如客户端一个 low ID 3．拒绝会话 – 服务器拒绝该客户端 当还还有少数情况例如:服务器崩溃了或者服务器是不可到达的。图2.1描述了建立一个 high ID连接的消息顺序。在这种情况下客户端先和服务器建立一个TCP连接然后向服务 器发送登入请求消息。服务器使用另外一个TCP连接连接客户端，这个连接扮演了一个 client-to-client的握手过程，通过这个连接服务器来确定该客户端是否有接受其他客户端 连入连接的能力。完全完成客户端握手之后服务器关闭第二个连接并且向客户端发送一 个ID变换消息然后结束客户-服务器的握手会话。你或许注意到了eMule-info消息是灰色 的。这是因为这个消息是eMule扩展协议(1.6章节)的一部分。 图 2.2: Low ID登录序列 图2.2描述了建立一个low ID连接的消息顺序。这种情况发生在服务端尝试与客户端建立 连接失败并分配各该客户端low ID。这样的服务器消息通常包含警告信息，例 如：”Warning [server details] - You have a lowid. Please review your network config and/or your settings.” Low和high ID握手都是以ID变更消息作为结束的,这个消息分配了该客户 端今后它与其他服务器会话时所使用的客户ID。 图2.3描述了拒绝连接的消息顺序. 由于客户端拥有的是low ID或者当服务器达到了他 们的硬界限时它们会拒绝客户端的连接。服务器消息将报还关于拒绝原因的简单描述。 图2.3: 拒绝会话序列 2.2连接启动信息交换 在成功建立连接之后客户与服务器交换几个设置消息。这些消息是为了更新与他们同层 的peer的状态。开始客户端现象服务端提过一个共享文件信息列表(见6.2.4章节)，然后 他请求更新它的服务器列表。服务器发送有关自己的版本和状态信息(6.2.6和6.2.2章节)， 然后发送一个已知eMule服务器列表，并提供更多一些有关自我识别的细节。最后客户 端请求资源(在服务器下在列表中能下载到该文件的客户端)并且服务端恢复一连串消 息，每一个文件提供一个客户端得下在列表，直到客户端下载完成了所有的资源列表。 图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.4: 连接启动消息序列 图 2.5: 文件检索消息序列 这个选择算法是基于我们的优先权机制，当没有指定优先权时磨人的规则是按照字母的 顺序。让一个资源可以上传多个文件的详细描述在eMule的网页上。 2.4 复查机制 复查机制的引入是为了克服low ID用户不能够接受引入的连接因此不能与其它的客户 分享它们的文件。这个机制很简单：比如A,B连个客户端连接到同一个eMule服务器，A 需要一个B所拥有的文件但是B是一个low ID，A可以向服务器提交一个复查请求(见 6.2.13章节)，请求服务器让B来主动请求A。与B已将建立一个开放的TCP连接的的服务 器将向B发送一个复查请求消息(6.2.14章节),向B提供A的IP地址和端口号。B就可以不借 助服务器向A发送文件了。很明显的，只有拥有high ID的客户端可以向拥有low ID的客 户端请求复查(一个low ID的客户端不能够接受连入连接请求)。图2.6将描述复查机制的 消息交换。依靠服务器作为中介我们也可以进一步来实现两个low ID的用户之间的文件 交换。但是由于大多数服务器的负载能力有限，他们不再支持这项功能。 图 2.6:复查消息序列 3 客户端服务段UDP信息 eMule客户端和服务端采用不可靠的UDP服务来保持联系和增进搜索。产生的UDP封包 (注意,封包不识字节)的可以达到eMule客户端所产生封包总数量的5%-这取决于客户端 服务器列表中服务器的数量，客户端下载列表中每一个要下载文件的资源数量和客户搜 索查询的次数。有一个100毫秒为周期的计时器来触发UDO封包，并且有单独一个线程 来处理UDP相关的事情，因此UDP封包的树木可以达到最多每秒10个。 3.1 服务器持续运行和状态信息 客户不时地改变他服务清单上的服务器状态。这种改变是通过使用UDP服务器状态请求 (见6.3.3章节)和UDP服务器描述请求(见6.3.7章节)来完成的。这里描述的简单服务器持 续运行计划每小时不会产生太多的数据包，这些数据包无论如何也不会超过0.2个/秒（每 5秒一个数据包）。客户在检查服务器的时候首先会发送一个服务器状态请求信息并且 在每两次的服务器描述尝试中需要像特征3.1中例证的请求。 图3.1: UDP 周期循环 客户端发送的服务器状态请求包含了服务器回复中回应的随机数。在服务器回应的数字 与客户端发送的口令不一致时，在回复当中的信息将被丢弃。每有一个状态请求数据包 发送至服务器，客户端都会预先准备一个attempt-counter.任何来自服务器的信息(包括搜 索结果等等)都将重置这个 attempt-counter。当它达到一个可控制的极限，服务器就被认 为是死亡的并从客户端的服务器清单中清除。 服务端回执的几个数据项目：服务器状 态回执(6.3.4章节)包括用户当前的数字和服务器中的文件还有服务器软件硬件的极限限 制(1.7章节)。服务器描述回执(6.3.8章节)包括服务器的名字和一个短的描述字符串。特 征3.2例证了在客户端和活动服务端中完整的 keep-alive序列中的信息流。 图3.2: UDP 保持运行序列 3.2 增强文件搜索 eMule可以使用UDP来增强它的文件搜索能力。UDP搜索请求的格式基本上和TCP搜索 请求的格式一样。服务器只在有搜索结果时才做出回应。UDP搜索信息有两种不同的 opcodes，我找不出它们之间的不同。UDP搜索分包被发送到客户端服务器列表中的服 务器中去。更多的信息请看6.3.5 和 6.3.6章节。 3.3 增强文件资源搜索 当一个客户端的下载列表中的某一个文件的资源数少于一个配置好的下限(100)时,客户 端将会周期性的向服务器列表中服务器发送UDP封包去获得该文件的更多的资源。每秒 钟都要发送封包，因此这些封包占客户端产生的封包中相当可观的一部分。消息的格式 (在6.3.1章节中描述)与TCP counter部分的格式很相似。注意与TCP资源搜索不懂得是 UDP资源搜索与文件搜索无关，它只取决于一个给定文件所拥有的资源数。 4 客户端到客户端的TCP信息 客户端在完成他在服务段的注册和查询它所要的文件和资源后，它将试着与其它的客户 端进行连接来下载文件。我们将为每一对[文件,客户]建立一个单独的TCP连接。当在一 个确定的时间内(默认是40秒)没有活跃的socket或者peer主动断开连接时连接将被终止。 为了提供满意的下载速度，在能够向下载客户端提供最小的允许速度(硬性规定是2.4kb/s) 之前eMule不会让客户端开始下载。 4.1 初次握手 初次握手的时候双方向对方发送同样的消息。两个客户端之间交换彼此的标示，版本和 接受能力信息。这里有两种消息-欢迎消息(6.4.1章节)和eMule信息消息(6.5.1章节)，第一 个是eDonkey的一部分和eDonkey客户端该消息时一样的，第二个是客户端扩展协议的一 部分只针对eMule。图4.1描述了两个eMule客户端之间的握手。这之中包含了一些额外 的信息如：UDP消息交换，安全识别和资源交换能力。 图4.1: eMule 客户端初次握手 4.2 安全用户识别 在1.4章节中我们简单的介绍了用户ID和用户扮演其他用户的可能性[3]。安全用户识别 是eMule扩展协议的一部分。在初次握手完成后就会进行用户安全识别。如果要使用安 全用户识别我们通过下面几个步骤来实现： 1．在初次握手时，B提出它支持并且想使用安全用户识别。 2．A回复安全识别消息(6.5.8章节)该消息指明了A是否需要B的公钥并且包括一个已经 由B确定的4字节的标记。 3．如果A指出需要B的公钥那么B将它的公钥发送给A(6.5.9章节)。 4．B发送一个由标记产生的签名消息(6.5.10章节)额外还有一个双字节在B是low ID的 情况下是A的IP地址，在B是high ID的情况下是B的ID号。图4.2将描述这个序列。 图4.2: 用户安全识别过程 4.2.1 荣誉系统 这一章节简单的描述了客户端的荣誉系统。这个荣誉系统的目的是鼓励用户们共享文 件。在客户端向它的peer上传文件的时候，正在下载的客户端根据下载数据的总量来更 新它的荣誉度。注意荣誉系统不是全球性的-荣誉度被存储在下载中的客户端的本地磁 盘并且仅当上传客户端(获得荣誉值)想要从明确的客户端下载文件是时才会被转化为数 值。荣誉值取决于下面几种情况的最小值： 1．上传总数*2/下载总数 当下载总数是0的时候表达式的值为10 2． 上传总数+2 当上传的总数小于1MB时表达式的值为1 上传/下载的数量以兆字节为单位。任何情况下荣誉度一定不能大于10或者小于1。 4.3文件请求 就像前面提及道德每一对[客户端,文件]都建立一个单独的连接。连接建立之后客户端立 及发送一些关于他向下载的文件的查询信息。图4.3描述了一个典型的成功过程。 图4.3: 文件请求 4.3.1 基本信息交换 四个消息组成了基本的信息交换：A在发送一个文件请求信息(6.4.18章节)之后立即发送 一个请求文件ID信息(6.4.17章节)。B回复这个请求一个文件请求应答(6.4.15章节)和一个 根据文件ID信息的文件状态信息(6.4.18章节)。我找不到任何理由将发送的信息分为四个 消息，我可以通过简单的两个消息来实现(一个请求消息和一个回复消息)。扩展协议在 资源请求(6.5.6章节)中增加了两个消息和一个资源应答(6.5.7章节)。这些扩展使用来将B 的资源(在B正在下载文件的时候)传送给A.。B没有必要在完全下载完成部分文件之后才 将它传送给其他的客户，B可以传送给A他完全下载任何一部分即使只是文件的一个很 小的的片断。。 4.3.2 没有找到文件时的情况 当A向B请求一个文件但是B的共享文件列表中没有这个文件。在接收到请求文件ID消息 后B将忽略这个文件请求信息并恢复一个文件无法找到消息(6.4.16章节)，就像图4.4中描 述的一样。 图 4.4: 文件请求失败-文件没有找到 4.3.3 争取到上传队列 优势B被请求上传文件但是他的上传队列这时并不为空，这就意味着有客户正在下载文 件同时上传队列中还有等待中的客户。A与B就像图4.3中描述的那样建立一个完整的握 手，但是当A向B请求下载文件的时候，B将A加入到他的上传队列中然后恢复一个包含 A在B的下载队列中的位置的队列消息。图4.5将详细说明这个过程。 4.3.4 上传队列管理 客户端对于每一个上传的文件都有一个上传优先权队列。队列中的每一个优先权是基于 队列中等待的时间和一个优先权 参数 转速和进给参数表a氧化沟运行参数高温蒸汽处理医疗废物pid参数自整定算法口腔医院集中消毒供应 计算出来了。在队列头部的客户有有罪该的分数。 这个得分的计算公式如下：得分=(优先级*在队列中等待的时间)/100或者在下载客户端 是好友时这个结果时1。初始的优先级数值是100，当又不被禁止的时候优先级数值为 0(为了防止被禁止客户到达队列的顶端)。这个优先级数值将会通过下载用户的荣誉值 图4.5: 文件请求等待队列 (大小是1-10)和上传客户端设置的上传冲互设定得上传文件优先级(0.2 - 1.8)来修正。所 有等待队列中得分最高的客户端进行文件的下载。在以下情况发生时客户将中止下载： 1．上传客户端被用户关闭了。 2．现在客户端完全下载完成了。 3．现在中的客户端被逼他用的优先级更高的客户抢占了。 为了使刚开始进行下载的客户端不被马上被队列中优先级比它高的客户抢占，eMule规 定将该开始下载的前15分钟里将下载客户的优先级设定为200。 4.3.5 到达上传队列的最顶端 当A到达B得上传队列的最顶端，B和A进行连接，完成初次握手然后发送同意下在请求 消息(6.4.11章节)。此时A可以发送一个请求部分消息来开始下载文件也可以发送一个取 消传送消息(6.4.12章节)来中止(在已经从其他的资源取得了这部份文件时)。图4.6将详细 描述这个过程。 图4.6: 文件请求开始下载 4.4 数据传输 4.4.1 数据包 发送和接收文件时eMule网络活动的主要部分。由FTP传输我们可以推断出eMule在发送 文件匹配数据传输中起到控制作用。一次发送的数据量可以在5000到15000字节之间(取 决于压缩程度)。为了避免文件破碎，一个文件被分割文很多部分来传输，每一部分放 在一个独立的TCP封包当中。在eMule 0.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个发送部分序列。当两个客户端都支持扩展协议 的时候文件数据将会被压缩(6.5.3章节)。扩展协议也支持一个可选择的文件信息消息 (6.5.5章节)，这个消息在接受到同一上传请求消息之后立即发送。图4.8将会详细描述数 据传输序列。 图 4.8: 数据部分交换 4.4.3 选择哪一部分要被下载 eMule有选择性的选择一个文件各部分的下载顺序来达到最大的网络吞吐量和共享性。 每一个文件被分割为很多部分，每一部分9大小为.28MB，每一部分又被分割为很多大 小为180k的块。文件块的下载顺序由正在下载的客户端的文件块请求消息(6.4.4章节)决 定。下载中的客户可以在任何一个给定的时间内下载文件的一个部分和从这个资源下在 这个文件部分的所有块。 下面是下载优先的规则: 1．文件块(可用的)出现的频率，稀少的文件块必须备尽快的下载来成为新的可获得的资 源。 2．用来预览文件块(第一和最后一块)，预览或者检查文件(比如电影，mp3) 3．请求状态(正在下载中的)，试着向每一个资源请求另外一块文件块。请求被发送到所 有的资源。 4.完成(最短的先完成)。在开始另外一个下载之前要先完成所有为完成的块。 文件出现的频率被分为三个等级：非常细又，稀有和普通。在每一个等级都有一个 标准 excel标准偏差excel标准偏差函数exl标准差函数国标检验抽样标准表免费下载红头文件格式标准下载 来计算每一个部分的等级。低等级的部分被先下在。下面的标详细的说明了文件的级别 信息： • 0-9999 – 请求的和未被请求得非常稀有的部分 • 10000-19999 – 未被请求的稀有部分和预览部分 • 20000-29999 – 未被请求的完成最多的部分 • 30000-39999 – 请求非常多的和预览部分 • 40000-49999 – 未完成的普通部分 这个优先法则通常选择第一个最稀有的部分。然而接近完成的部分被下载的文件块也将 被选择，这回从一些不同的资源下在。 4.5 浏览共享文件和文件夹 eMule有两个消息来浏览peer客户的共享文件和文件夹。第一个是浏览共享文件消息 (6.4.21章节)，他将在建立完第一次握手之后立即被发送。总是有一个共享文件应答消息 (6.4.22章节)来回复这个消息。当应答客户端想隐藏他的共享文件时应答消息文件中包含 0个文件(而不是否认这条消息)。4.9将详细地描述这个过程。第二个消息是请求共享文 件夹列表(6.4.23章节)，然后再为每一个共享文件夹发送一个共享文件夹消息(6.4.24章节) 请求信息(6.4.25章节)。每一个这种消息将会收到一个文件夹信息(章节6.4.26)作应答。 图4.9: 浏览共享文件 图4.10 将详细说明这个过程 有时在接收客户端想阻止浏览共享文件/文件夹请求时,它将回复一个拒绝消息，想图 4.11中描述的那样。 图 4.10: 浏览共享文件和共享文件夹 图 4.11: 浏览被拒绝 4.6 交换部分哈西组 通过发送一个哈希组请求来得到部分哈西，这个请求被哈西组回执回复，其中包括文件 中每个部分中的哈西组。图4.12对其进行了说明。 图4.12: 哈西组请求 4.7 得到一个文件的预览 客户端可以要求他们的peer来得到一个下载完毕文件的预览。预览是依靠应用程序的并 且有不同的文件种类。EMULE 0.30E 只支持图像预览。信息交换在 图4.13中描述并仅 包含2个信息： 预览请求(6.5.11章节)和预览应答(6.5.12章节)。 图4.13: 得到文件的预览 5 Client to Client UDP Communication emule客户端不时地发送实用UDP协议的信息。在EMULE 0.30e UDP信息仅在询问客户 端在它的PEER下载序列中的位置时使用。简单的请求-回应计划时有一个re-ask文件信息 (6.6.1章节)初始化的。在图5.1有3种可能的向这种以上解释过的消息回复： 1． 队列等级- 客户端在发送者队列种的等级头衔 2．队列已满- 发送者队列已满 3． 没找到文件- 发送者没有它清单中的请求文件 re-ask文件信息大约每隔20分钟发送给每个客户端，这些客户端在他的下载队列中添加 了发送者。 图5.1: re-ask文件信息 参考条目 [1] D. Bickson 和 D.Malkhi. 研究独立的文件共享网络. Leibniz 研究中心的TR-2003-67研究报告,耶路撒冷的Hebrew 大 学, 以色列, 2003. [2] eMule 在 source force. http://sourceforge.net/projects/emule/. [3] eMule 项目. http://www.emule-project.net/. [4] MD4 哈西函数说明书. http://www.ietf.org/rfc/rfc1320.txt. 6 附录A – 消息编码 6.1 常规消息编码说明 这部分主要描述了建立在TCP/UDP基础上的常规消息编码说明 6.1.1 Endianity 所有的消息都是以little-endian规则进行编码的不是传统网络上的以big-endian顺序进行 编码。这可以很容易的解释为什么基于Microsoft Windows的客户端/服务器程序用在Intel 处理器上。 6.1.2 消息头 所有的消息都包含有一个6字节的消息头，结构如下： 1. 协议- 一个1字节的标示符 - eDonkey是0xE3 ， eMule是0xC5 2. 大小- 消息大小为4字节 - 不包括标题和size字段的信息大小。例如有时像6.4.11章节中 所表述的那样消息中不包含任何有效内容他的长度就为0。 3. 种类- 一个一位字节 – 一个唯一的消息 ID 6.1.3 消息标记 标记是一个TLV-like(种类，长度，内容)结构，用来传输可选择的数据。有好几种标记， 他们将在本章中被一一列出。当读者想要一些有特别用途的特定标记时，可以以本章中 精确定义的一些结构作为参考。一个标记拥有4部分，他们在消息中并不是连续的： 1．type– 1字节的整型 2．name –可以是下面中的任意一种 • 可变长的string类型 • 1字节的整型 3．value -可以是下面中的任意一种 • 4字节的整型 • 4字节的浮点型 •可变长的string类型 4．Special- 1字节的整型，特殊标记制定位 整型的我们叫做整型标记，对于浮点型和字符串型也一样。字符串标记有两种，一种是 3位的整型另外一种是4位的浮点型。他们按照上面定下来的顺序进行编码比如第一个是 type，然后是name，最后是value。Type占一个字节。Name占一个两个字节的结构及可 以是String的 也可以是 Integer的。例如Integer名字是0x15将被编码为0x01 0x00 0x15。 定值域(比如整型和浮点型数字)按照规定的填写，string值按一样的长度编码，但是治还 是不变的。注意name没有特别的意义只是为了将来更容易的描述消息。 6.2 客户服务器的TCP信息 这个章节描述了服务器与客户端之间使用 TCP port传递的信息。 6.2.1 登入 登入信息是 TCP连接完成后由客户端向服务端发出的首个信息。信息的长度的变化取决于 如用户昵称的用户设置。为什么应该发送客户端 TCP传输还不清楚，在 TCP标题中也会发 生。 名称 字节数 默认值 注释 Protocol 1 0xE3 Size 4 不包括标题和 size 字段的信息大小 Type 1 0x01 OP_LOGINREQUEST opcode Client Hash 16 详细的信息兼 section 1.4 Client ID 4 0 发送第一次连接的 Client ID 通常为 0.详见 section 1.3 TCP port 2 4662 TCP port是客户端使用的，是可以配置的 Tag Count 4 4 紧跟着信息的标签数 Name Tag 不定 N/A 用户的昵称（是可以在软件中配置的）。 Tag 是一个标签串并且标签的名字是值为 0x1 的整数。 Version Tag 8 0x3C 由客户端支持的 eDonkey 版本。 Tag 是一个整数标签并且标签的名字是一个值 为 0x11的整数。 Port tag 8 4662 TCP port是由客户端使用的。 Tag 是一个整数标签并且标签的名字是一个值 为 0x0F的整数。 Flags Tag 8 0x01 Tag 是一个整数标签并且标签的名字是一个值 为 0x20的整数。 6.2.2服务器消息 服务器消息是在不同情况下由服务器发向客户端的长度可变的消息，首要的情况是客户端 马上发送登录请求后。一个简单的服务器信息可能包括几个由新分隔符分开的一些信息 。 （‘\r’,’\n’,或者两者都有）。由“server version”,”warning”,”error”和”[emDynIP:”的信息对客 户端来说有特殊的含义。 其它信息简单得显示给用户即可。 名称 字节数 默认值 注释 Protocol 1 0xE3 Size 4 不包括标题和 size 字段的信息大小 Type 1 0x01 OP_LOGINREQUEST opcode Size 2 N/A 不包括到现在为止描述过的领域中的信息剩余 的字节数 Messages 不定 N/A 由 new lines 分割的服务器信息清单 特别信息 1. version- 经常在一个成功的同步交换连接中返送 2. error- 3. warning- 经常在服务器拒绝连接或者客户端中有 low ID的时候发送 4. emDynIP 6.2.3 ID 改变 服务器发送的ID改变消息，作为登入请求的应答并且意味着服务器允许连接。消息大小 是14或16字节取决于发送的TCP连接。 名称 字节数 默认值 注释 Protocol 1 0xE3 Size 4 不包括标题和 size 字段的信息大小 Type 1 0x40 OP_ IDCHANGE opcode Client ID 4 NA 客户ID的详细内容请看1.3章节 TCP connection bitmap 4 0x00000001 通常只有 1bit 有意义(LSB)，将其设置为以表 明服务器支持压缩 6.2.4 提供文件 这个消息是客户用来描述它所拥有的可以提供其他客户下载的文件。当用户有文件请求 时，文件请求消息在连接被建立后立即发送。当客户的共享文件发生变更时也发送这条 消息。这个消息的另外一个作用是保持激活，周期性的发送给服务段。当服务器支持压 缩文件请求时将被压缩。当用来保持激活时(没有文件压缩消息大小小)这个消息不被压 缩。 名称 字节数 默认值 注释 Protocol 1 0xE3 Size 4 不包括标题和 size 字段的信息大小 Type 1 0x15 OP_ OFFERFILES opcode File Count 4 NA 消息中文件描述的数量。任何情况下不超过 200。服务企业能设置这个限制。 Files 可变 NA 可选择的文件列表，格式是下面描述的一个片 断。 一个文件片段的格式 下面的表格描述了一个文件片断。一个文件请求消息中有几个连续的文件片断。 名称 字节数 默认值 注释 Hash Code 16 NA 文件内容的哈西值(详细的 TBD)。这个哈西值 用来唯一的识别一个文件。避免不同客户的文 件名不同。 Client ID 4 NA 当用户是 high ID时是 high ID值 否则是 0 Client Port 2 0x15 客户的 TCP端口当是 low id 时是 0 TagCount 4 NA 下面的标记的数量 File Name Tag 可变 NA 文件名，这是一个字符串标记，标记是一个整 型值 0x1 File Size Tag 8 NA 文件大小，单位是字节。这是一个整型标记， 标记是一个整型值 0x2 File Type Tag 不定 NA 文 件 类 型 ( 可 选 择 的 ) ， 下 面 中 的 一 种 ： ”Audio”, ”Video”, ”Image”, ”Pro” 或 ”Doc” 这是一个字符串标记，标记是一个 整型值 0x3 File Format Tag 不定 NA 文件的格式(可选择的)。例如- ”zip”, ”exe”。这 是一个字符串标记，标记是一个整型值 0x4 Media Length Tag 不定 NA 如果是 mp3 文件，歌曲的长度(可选)。这是一 个字符串标记，标记是一个字符串值”length” Media Bitrate Tag TBD NA 如果是 mp3文件 编码的比特率(可选)。这是一 个字符串标记，标记是一个字符串值” bitrate” Media Codec Tag 不定 NA 如果文件是个电影，编码器的类型(可选，不乏 送)。这是一个字符串标记，标记是一个字符串 值” codec” 6.2.5 获得服务器列表 这个消息在初次握手完成后客户立即发送给服务器。当客户通过向它正连接着的客户寻 求服务器列表时发送这个消息。消息大小是6字节。 名称 字节数 默认值 注释 Protocol 1 0xE3 Size 4 不包括标题和 size 字段的信息大小 Type 1 0x14 OP_ SERVERSTATUS opcode 6.2.6 服务器状态 服务器发送给客户的。消息包括服务器的当前连接数和文件数。这个消息被客户储存并 显示。消息的大小是14字节。 名称 字节数 默认值 注释 Protocol 1 0xE3 Size 4 不包括标题和 size 字段的信息大小 Type 1 0x34 OP_ SERVERSTATUS opcode User Count 4 NA 服务器当前登陆用户数 File Count 4 NA 服务器纪录的文件数 6.2.7 服务器列表 服务器发送给客户的。这个消息包含了客户服务器列表重要增加的服务器的消息。消息 大小不定(取决于传送服务器的个数)。 名称 字节数 默认值 注释 Protocol 1 0xE3 Size 4 不包括标题和 size 字段的信息大小 Type 1 0x32 OP_ SERVERLIST opcode Entry Count 1 NA 消息中描述的服务器的个数 Server entries (Entry Count)*6 NA 服务器描述，每一个描述 6 个子节 4 字节 IP 地址 2字节端口 6.2.8 服务器认证 服务器发送给客户的。饱含一个服务器哈西(TBD)，服务器IP地址和TCP端口(当通过代 理连接时有用)并且也有服务器的信息。消息大小不定。 名称 字节数 默认值 注释 Protocol 1 0xE3 Size 4 不包括标题和 size 字段的信息大小 Type 1 0x41 OP_ SERVERIDENT opcode Hash 16 NA 服务器的 GUID(好像是用来 debug 的) Server IP 4 NA 服务器 IP地址 Server Port 4 NA 服务器监听的 TCP端口 TagCount 4 NA 消息末尾的标记数 Server Name Tag 不定 NA 服务器的名字。是一个字符串标记，标记名是 一个整型值是0x1 Server Description Tag 不定 NA 服务器的描述。是一个字符串标记，标记名是 一个整型值是0xB 6.2.9 搜索请求 客户发送给服务器的。消息使用用户的一个搜索字符串搜索一个文件。消息大小是可变 的。搜索字符串包括布尔运算符’AND’,’OR’, ’NOT’。用户可以详细设置文件的类型大 小也可以设置开始位置(例如：展示给我至少5个其他客户端的结果)。 名称 占用字节数 默认值 说明 Protocol 1 0xE3 Size 4 不包括标题和size字段的信息大小 Type 1 0x16 OP_SEARCHRESULT opcode Parsed search string 不定 NA 下面所描述的搜索字符串结构 Result list 不定 NA 搜索结果列表 Parsed search string 不定 NA 解析搜索字符串，格式如下 File Type Constraint 不定 NA 可选的。一个字符串约束。字符串值是 Audio”, ”Video”, ”Pro” or ”Image”三者 之一。类型域分别对应0x1 0x0 0x3 Min Size Constraint 不定 NA 可选择的，一个整型约束。以兆字节计 算的文件大小。类型域有4位：0x1 0x1 0x0 0x2 Max Size constraint 不定 NA 可选择的，一个整型约束。以兆字节计 算的文件大小。类型域有4位：0x2 0x1 0x0 0x2 Availability Constraint 不定 NA 可选择的，一个整型约束。搜索文件客 户数量的最小上限，类型域有4位：0x1 0x10x0 0x15 Filename Extension constrain 不定 NA 可选择的，一个整型约束。类型域有3 位：0x1 0x0 0x3 解析搜索字符串格式 解析字符串编码是通过二差树和’AND’,’OR’ ,’NOT’布尔运算符以及字符串操作数。二 差树是按照先序编码进行的。操作是编码两位字节值是 The tree is encoded in pre-order . The operators0x0, 0x100, 0x200分别代表了’AND’, ’OR’ 和’NOT’。字符串按照TLV格式进行编码是一个以字节的值和一个两字节的长度。注意 当字符串是以各自的时候它代表字符串操作(没有运算符)。以后的eMule 编码版本中指 通过单独的字符串’AND’来编码搜索表达式，由空格代替’AND’。由’AND’运算符将连 续的单词分开来组成一个句子。 可选择的约束格式 约束数列条目。每一个条目有’AND’描述符开始(2-byte0x00)紧跟着是编码约束。因此一 个完整的搜索行格式是：<’search-string’ AND constraint1 ANDconstraint2 etc>就想下面 图例中描述的一样。编码被分成三部分。 1．类型-一个字节的描述，表明是字符串(0x2)还是整型约束(0x3)。 2．值-一个定长字符串编码或者一个4字节的整型值 3．类型-一个3或4字节的约束类型描述(看上面的主要表) 图 6.1: 查找字符串编码实例 6.2.10 搜索结果 服务器发送给客户的搜索请求应答消息。这个消息通常是压缩的。大小不固定。 名称 占用字节数 默认值 说明 Protocol 1 0xE3 Size 4 不包括标题和size字段的信息大小 Type 1 0x16 OP_SEARCHRESULT opcode Result Count 4 NA 这个消息中搜索结果的个数 Result list 不定 NA 搜索结果列表 搜索结果列表项目的格式 下面的表格描述了一个搜索结果列表项目的格式。每一个搜索结果包含了一个唯一表示 这个文件的哈西数和两外一个又有该文件的客户。还有几个描述文件属性的标记。这些 标记将在下面描述： 名称 占用字节数 默认值 说明 File Hash 16 NA 一个哈西值，唯一的标示了一个文件 Client ID 4 NA 一个拥有该文件的peer的客户ID Client Port 2 0x16 拥有文的客户端得端口号 TagCount 4 NA 后面的描述标记的个数 Tag list 不定 NA 描述标记列表 注意大多数标记的位置是可以变动的，并不是固定的。标记编码的规则在本章开始处已 经详细描述了。 名称 标记名称 标记类型 说明 File name Integer 0x01 String File size Integer 0x02 Integer File type Integer 0x03 String File format Integer 0x04 String Sources Integer 0x15 Integer 这个文件可获得的资源数 Artist String ”Artist” String Album String ”Album” String Title String ”Title” String Length String ”length” Integer Bitrate String ”bitrate” Intege Codec String ”codec” Integer 表6.1: 搜索结果标记列表 6.2.11 获得资源 客户向服务器发送一个请求来获得文件资源(其他的客户)。消息的大小是22字节。 名称 占用字节数 默认值 说明 Protocol 1 0xE3 Size 4 不包括标题和size字段的信息大小 Type 1 0x19 OP_ GETSOURCES opcode File hash 16 NA 请求的文件哈西数 6.2.12 建立资源 服务器发送给客户端一个包含客户端所请求的文件资源(其他的客户)的消息。消息大小 是不定的。 名称 占用字节数 默认值 说明 Protocol 1 0xE3 Size 4 不包括标题和size字段的信息大小 Type 1 0x42 OP_ FOUNDSOURCES opcode File hash 16 NA 请求的文件哈西