电驴协议中文版

前几天研究了一下电驴的协议，由于电驴协议是英文版看起来比较费事，所以看的时候顺便翻译了中文版，希望对想了解电驴的朋友有所帮助。

                           目录

1简介--2

1.1 目的和范围--2

1.2 概述--2

1.2.1客户端到服务器的连接--3

1.2.2客户端到客户端的连接--3

1.3 客户ID-4

1.4用户ID-4

1.5文件ID-4

1.5.1文件哈希--5

1.5.2  根哈希--5

1.6 eMule协议扩展--5

1.7 软件和硬件限制--5

2 客户端服务器的TCP交流--5

2.1 建立连接--5

2.2连接启动时消息交换--7

2.3文件搜索--8

2.4回调机制--9

3客户端服务器的UDP交流--10

3.1服务器保持连接和状态信息--10

3.2增强文件搜索--11

3.3增强文件源搜索--11

4.客户端和客户端的交流--11

4.1初始的握手--11

4.2可靠的用户辨认--12

4.2.1信誉系统--13

4.3 请求文件--13

4.3.1基本的信息交互--13

4.3.2请求的文件没有找到--14

4.3.3上传队列--14

4.3.4上传队列的管理--14

4.3.5达到上传队列的顶部--15

4.4数据传输--15

4.4.1数据包--15

4.4.2数据传输顺序--16

 

 

 

 

 

 

 

1简介

1.1 目的和范围

eMule是流行的文件共享程序，基于eDonkey协议。这份报告描述了eMule的网络行为和解释了理解该协议所需的基本术语。本报告也给出了eMule网络协议的完整规范，包括一个附录，它提供了消息格式。这份文档的信息是基于开源的eMule客户端。接下来的简介目的是提供基本的背景知识，让读者阅读和理解这份文档。关于eMule的更多消息在这里找到。

1.2 概述

eMule网络是由上百个eMule服务器和几百万个eMule客户端组成。客户端必须连接到一个服务器来取得网络服务，只要该客户端在系统中，服务器连接保持打开状态。这些服务器主要执行集聚索引服务（好像在Napster），相互间不联系。

每个eMule客户端都预配置了一个服务器列表和当地文件系统的共享文件列表。客户端用单独的TCP连接到一个eMule服务器登录到网络中，获得想得到的文件信息和客户端。eMule客户端也用几百个TCP连接到其他客户端进行上传和下载文件。每个eMule客户端对它的每个共享文件都维护着一个上传队列。要下载的客户端先加入到队列的底部，然后逐渐前进直到到达队列的顶部并开始下载它的文件。一个客户端可以从几个不同的eMule客户端中下载同一个文件的不同的文件块。客户端也可以上传它还没有完成的文件的文件块。最后，eMule扩展了eDonkey的能力，允许客户端之间交换关于服务器、其他客户端和文件的信息。注意，客户端和服务器的交流都是基于TCP的。

服务器使用了一个内部数据库，用来存储关于客户端和文件的信息。一个eMule服务器不存储任何文件，它为关于文件位置的存储信息作集聚索引。服务器的另一个功能，开始变得被抗议，是连接由于通过防火墙连接而无法接收到连接的两个客户端。这个连接功能增加了服务器的负载。相对于服务器和其他客户端，eMule使用UDP来增强客户端的能力。客户端发送和接收UDP信息的能力在日常使用中不是强制使用的，当有防火墙阻止它收发UDP信息时也能无瑕疵的运行。

1.2.1客户端到服务器的连接

在开始启动时，客户端用TCP连接到一个eMule服务器。服务器提供一个客户ID给客户端，在整个客户端-服务器连接的生命周期里，它是有效的（注意，如果客户端有一个高ID，它会从所有的服务器中接收到相同的ID，直到它的IP地址改变）。在连接建立之后，客户端发送它的共享文件列表到服务器中。服务器把这个列表存储到它的内部数据库中，这个数据库通常包含了成百上千有效的文件和活动的客户端。eMule客户端也发送它的下载列表，包含着它想下载的文件。第二章提供了eMule客户端和服务器TCP信息交换的详细描述。

建立连接之后，eMule服务器给客户端发送用有它想下载的文件的其他客户端列表（这些客户端称作“源”）。从这点起，eMule客户端开始与其他客户端建立连接，如1.2.2所述。

注意，在整个客户端会话期间，客户/服务TCP连接一直保持连接状态。初次握手后主要是用户活动激发事务：有时，客户端发送文件搜索需求，由搜索结果回应，一个搜索事务一般在对源中指定文件查询之后，用源（IP和端口）列表来回答这个查询，查询者可以从这列表中下载文件。

客户端和它没有连接的服务器的交流是用UDP。UDP信息的目的是增强文件搜索，增强源搜索，最后保持连接状态（确保客户端服务器列表中的eMule服务器有效）。在第三章中可找到更多的关于客户-服务UDP信息交换的细节。

1.2.2客户端到客户端的连接

一个eMule客户端连接到另一个eMuel客户端（源）是为了下载文件。一个文件分成很多部分，进一步的碎片。客户端可以从几个（不同的）客户端中下载同一个文件来分别获得不同的文件碎片。

当两个客户端连接时，它们交换容量信息，然后协商一个下载（或者上传，根据看法）的开始。每个客户端有一个下载列表，记住一列等待下载文件的客户端。当eMule客户端下载队列空的时候，一个下载请求很可能会导致一个下载开始（除非，比如这个请求者被禁止）。当下载队列不是空的时候，就会将这个请求的客户端加入到队列中。在给定的时间内,不能为几个以上客户端各自提供最小带宽2.4k/s。一个下载的客户端可能被一个比它较高队列等级的等待的客户端抢占，在下载会话的最初15分钟内，正在下载的eMule客户端的队列等级会增加直到能防止被击溃。

当下载的客户端到达下载队列的头部时，上传的客户端初始化一个连接来给它发送需要的文件块。eMule客户端可以在几个其他客户端的等待队列中，都注册下载相同文件的块。当一个等待的客户端实际上完成了（从它们中的一个）下载文件块，它不会通知其他客户端在其队列中删除它，当它到达它们的队列头时只是简单的拒绝它们的上传意图。

EMuley用一个信用系统来鼓励上传，为了防止假冒用RSA公匙密码系统来保护信用系统。

客户端连接可能用一套eDonkey协议没有定义的信息，这信息称作扩展协议。扩展协议用来实施信用系统，一般信息的交换（像服务器和源列表的更新），通过收发压缩的文件块来改善性能。

当EMule客户端在等待开始下载文件时，有限地用UDP周期性检查在它对等的客户端上的上传队列客户端状态。

1.3 客户ID

客户ID是服务器在它们连接握手时提供的一个4字节标识符。客户ID只在客户-服务器TCP连接的生命期中有效，尽管万一客户端有一个高ID，所有的服务器都会分配它同样的ID直到IP地址改变。客户端ID分为低ID和高ID。当一个客户端不能接收一个输入连接时，eMule服务器将特有地分配给客户端一个低ID。拥有一个低ID会限制客户端对eMule网络的使用，和可能导致服务器拒绝一个客户端连接。高ID的计算是以客户端IP地址为基础的，如下所述。本节从eMule协议观点描述了客户ID的分配和重要性。允许其它客户端自由地连接到其本机上的eMule的TCP端口（默认端口号是4662）的客户端会分配给一个高ID。有高ID的客户端没限制使用eMule网络。当服务器无法打开一个TCP连接到客户端的eMule端口时，会分配一个低ID给该客户端。这主要发生在机器上装有防火墙的客户端，阻止了输入连接。当出现下面情况时，客户端也会接收到一个低ID：

Ø        当客户端通过NAT或代理服务器连接

Ø        当服务器繁忙（导致服务器重连接计时器超时）

高ID用下面的方法计算：假设主机IP是X.Y.Z.W，ID就是X+2^8*Y+2^16*Z+2^24*W。低ID总是小于16777216（0x1000000），关于它是怎样计算的，我找不到任何线索，在不同的服务器中得到不同的低ID。

低ID客户端没有其他客户端可以连接到的公网IP，这样所有的交流必须通过eMule服务器完成。这增加了服务器计算能力的负担，并且导致服务器勉强接收低ID客户端。这也意味着低ID客户端不能连接到不在同一个服务器上的其他低ID客户端，因为eMule不支持在服务器间管道连接。

为了支持低ID客户端，引入了回调机制。使用这机制，高ID客户端请求（通过eMule服务器）低ID客户端连接它来交换文件。

1.4用户ID

eMule支持信用系统来鼓励用户共享文件。用户上传越多的文件给其他客户端，它接收的信用越多，它在它们的等待队列中前进得越快。

用户ID是128位（16字节）、连接随机数字创建的GUID，第6和第15字节不是随机产生的，它们的值分别是14和111。在整个客户端和指定的服务器会话中，客户ID是有效的，然而用户ID（也叫用户哈希）是唯一的并且跨越会话时用来识别客户端（用户ID识别工作站）。用户ID在信用系统中扮演重要角色，这为“黑客”假冒其他用户来获得他们信用赋予的优先权提供了动机。Emule提供加密方案设计来阻止欺骗和冒名顶替。这个实施是简单的应答交换，依靠RSA公有/私有钥匙加密。

1.5文件ID

文件ID用来惟一的标识网络中的文件和文件损坏侦测和修复。注意，eMule不依靠文件名来惟一标识和编目文件，通过哈希文件内容计算出的GUID标识文件。有两种类型文件ID-一种主要用来产生惟一的文件ID，另一种是用来损坏侦测和修复。

1.5.1文件哈希

文件是用由客户端和基于文件内容计算出来的128位GUID哈希来标识的。GUID是应用MD4算法到文件数据中计算而来。当计算文件ID时，文件被分成每段9.28MB长的部分。每部分单独计算出一个GUID，然后所有的哈希组合成一个惟一的文件ID。当下载的客户端完成一个文件部分下载时，它计算这部分哈希，然后和发送过来的这部分哈希对比，如果这部分发现损坏了，客户端尝试通过逐渐替换这部分中的位（每个180kb）来修复损坏部分，直到哈希计算OK。

1.5.2  根哈希

用SHA1算法来为每部分计算根哈希，基于每块180kb大小。它提供了更高等级的可靠性和可修复性，更多信息可在eMule官方网站得到。

1.6 eMule协议扩展

尽管eMule完全兼容eDonkey，它还是实行了几种扩展，允许eMule两个客户端为用户提供另外的功能。扩展只要集中在客户端与客户端的交流，特别是在安全和UDP使用领域上。在本文档中，所有信息流图标明的信息，是eMule扩展部分的，用灰色表示。

1.7 软件和硬件限制

在活动用户数量的服务器配置中有两种限制-软件和硬件。硬件限制远大于软件限制。当活动用户的数量达到软件限制时，服务器停止接收新的低ID客户连接。当用户数量达到硬件限制时，服务器满了，不再接收任何客户端连接。

层次遍历二叉树。
大致算法：
采用一个队列q，先将二叉树根结点入队列，然后退队列，输出该结点；若它有左子树，便将左子树根结点入队列；若它有右子树，便将右子树根结点入队列，如此直到队列空为止。

2 客户端服务器的TCP交流

每个客户端用TCP精确地连接到一个服务器。服务器分配给客户端一个ID,在与服务器其余的会话中标识该客户端（高ID客户端总是根据它的IP地址分配）。eMule GUI客户端需要建立一个服务器连接来用于操作。客户端不能同时与几个服务器连接，也不能在没有用户干涉的情况下动态更换服务器。

2.1 建立连接

在准备建立与服务器的连接时，客户端会尝试并行地连接到几个服务器，根据成功的登陆顺序放弃其他的。

                                            图2.1

有下面几个可能的连接建立个案：

Ø        高ID连接-服务器分配一个高ID给正在连接的客户端

Ø        低ID连接-服务器分配一个低ID给正在连接的客户端

Ø        拒绝会话-服务器拒绝客户端

当然，也有不重要的个案-服务器崩溃或者不可连接。

图2.1描述了导致高ID连接的信息顺序。在这种情况下，客户端建立一个TCP连接到服务器，然后发送一个登录信息到服务器。服务器用另一个TCP连接到客户端，执行一个客户端-客户端的握手来保证连接的客户端有能力接收来自其他eMule客户端的连接。在完成客户端握手后，服务器关闭第二个连接，通过发送ID更改信息来完成客户端-服务器的握手。你可能注意到eMule信息消息是灰色的。这是因为这个消息是eMule协议扩展的一个部分（1.6节）

                                 图2.2

图2.2描述了导致低ID连接的信息顺序。在这种情况下，服务器不能连接到发送请求的客户端，分配一个低ID给客户端。服务器消息一般包含警告信息，就像“警告[服务器细节] - 你是低ID。请察看你的网络配置和/或你的设置”低ID和高ID握手都是通过随着ID更改消息完成的，这个ID更改消息分配客户端一个客户端ID，用在与服务器的下一个会话。

                                      图2.3

图2.3描述了被拒绝的会话顺序。因为客户端拥有一个低ID或者到达了服务器硬件的容量限制，服务器就可能拒绝会话。服务器消息会包含一个短字符串描述拒绝的理由。

2.2连接启动时消息交换

在建立成功的连接后，客户端和服务器交换几个设置消息。这些消息的目的是根据双方状态来双方更新。客户端通过提供它的共享文件列表（见6.2.4节）给服务器来开始，然后要求更新它的服务器列表。服务器发送它的状态和版本（6.2.6节和6.2.2节），然后发送它所知的eMule服务器列表和提供更多一些自我认定的细节。最后客户端要求源（可以访问下载它下载列表中的文件的其它客户端）和服务器回应一系列的消息，客户端下载列表中的每个文件，直到下载所有的源列表到客户端。图2.4图解了这个顺序。

                                            图2.4

2.3文件搜索

文件搜索是由用户发起的。这个操作简单，一个搜索要求（见6.2.9节）发送到服务器，然后服务器用一个搜索结果回应。当有很多结果时，搜索结果消息就会被压缩。接着，用户选择下载一个或多个文件，客户端就要求源为选中的文件和服务器返回每个要求文件的源队列（见6.2.12节）。就在回应发现的源之前，可以发送一个可选的服务器状态消息。这个状态消息（6.2.6节）包含关于当前用户数量和服务器支持的文件等信息。重要注意的是，UDP消息有个补充顺序事件，用来增强客户端为它搜索的文件定位源的能力，详细的细节见第3章。在检验出源是新的之后，eMule客户端开始尝试连接和把它们加入到它的源列表。源联系的顺序就是eMule客户端接收到它们的顺序。图2.5描述了文件搜索顺序。

                                      图2.5

eMule客户端根据源加入到它的列表中的顺序来连接源。没有优先机制来决定连接那个源。当可以要求同一个源来下载客户端下载列表中的几个文件时，有一种复杂的机制来解决这个局面（注意，载客户端之间eMule只允许一个单独的上传连接）。选择算法是基于用户优先规则，当没有指定优先时，默认是字母顺序。关于处理可以上传多于一个文件的源的详细描述，可以在网站中找到。

2.4回调机制

回调机制是设计来克服低ID客户端不能接收输入的连接的，这样客户端之间就能共享它们的文件。机制很简单：假如客户端A和B都连接到同一个eMule服务器，A需要的文件在B上，但B是低ID的，A可以向服务器发送一个回调请求（见6.2.13节），请求服务器叫B呼叫回它。服务器，已经有一个与B的打开的TCP连接，发送一个回调请求消息（见6.2.14节）到B，为它提供A的IP和端口。B就能连接到A并发送文件，没有给服务器增加负担。很明显，只有高ID客户端可以要求低ID客户端回调（低ID客户端是没有接收输入连接的能力的）。图2.6图解了回调消息交换。

                                      图2.6

也有允许两个低ID客户端交换文件的能力，通过它们的服务器连接，用服务器接力。大部分服务器不再提供这个选项，因为它招致服务器的负担。

3客户端服务器的UDP交流

eMule客户端和服务器用不可靠的UDP服务来保持连接和增强搜索。eMule客户端产生UDP包的总量可以达到它发送包的总数目的5% - 这些根据客户端服务器列表中服务器的数目，客户端下载列表中每个文件的源数目和用户执行的搜索数目而定。UDP包通过计时器触发，计时器每100ms过期，有一个单独的线程负责发送UDP输送结果，以每秒10个UDP的最大速率。

3.1服务器保持连接和状态信息

客户端周期性验证它服务器列表中的服务器状态。验证是通过发送UDP服务器状态请求（见6.3.3节）和UDP服务器描述请求（见6.3.7节）消息完成的。这里描述的简单保持连接计划每小时产生不超过几打包。任何情况下，包的最大速率是每秒0.2个包（或每5秒一个包）。当检查服务器的状态时，客户端会首先发送一个服务器状态请求消息，接着，每两次试图（发送一个服务器状态请求）中就发送一次服务器描述请求，见图3.1。

                                            图3.1

客户端发送的服务器状态请求中包括一个随机数字，在服务器回应中返回。在服务器返回的数字与客户端发送的要求中数字不同的情况下，回应的信息就会被丢弃。每次发送到服务器的包是状态请求，客户端就移动尝试计数器。任何来自服务器的消息（包括搜索结果）都重置尝试计数器。当尝试计数器达到一个可配置的限制时，服务器就认为是死机，从客户端的服务器列表中删除。服务器回应包括几个数据项：服务器状态回应（见6.3.4）包括服务器中当前用户数目和文件数目，也包括服务器的软件和硬件限制（见1.7节）。服务器描述回应（见6.3.8节）包括服务器名称和一个短的描述字符串。图3.2演示了客户端和活动服务器中满连接序列的消息流。

                                      图3.2

3.2增强文件搜索

eMule客户端可以设置用UDP来增强它的文件搜索。UDP搜索结果格式几乎与？？节描述的TCP搜索请求一样。服务器只在有了搜索结果才回应。UDP搜索结果消息有两种不同的opcdes，我也无法说清它们之间的不同。UDP搜索包发送到客户端服务器列表中的服务器上。更多信息见6.3.5节和6.3.6节。

3.3增强文件源搜索

当客户端下载列表中的特定文件的源数目小于配置限制（100）时，客户端就周期性地发送获取源的UDP包到它的服务器列表中的服务器中为该文件寻找更多的源。可能每秒发送一个包，使得源搜索在客户端产生的UDP输送中成为可观的部分。消息的格式（6.3.1节描述）非常相似它的TCP计数器部分。注意，与TCP源搜索相反，UDP源搜索在文件搜索中减弱，对于指定的文件，只是依靠客户端拥有的源数目。

4.客户端和客户端的交流

     当客户端在服务器上注册、查询文件和当源客户端需要从其他终端下载文件的时候，每个【文件，客户端】对都会建立一个专门的TCP连接，当在一个确定的时间段(默认40秒)没有活动的Socket，或者对等端的Socked已经关闭，这个连接才会被关闭。

     为了提供合理的下载速度，eMule不允许客户端开始下载直到能够提供它达到最小的允许码流（通常设置为2.4K/S）。

4.1初始的握手

      初始的握手是对称的，双方都互相发送相同的信息。互相交换信息进行身份辨认（包括版本和性能信息）。有两种类型的消息发送—Hello消息（6.4.1节）和eMule信息消息（6.5.1节）第一部分是eDonkey的一部分，他是和eDonkey客户端兼容的，第二部分是eMule独有的客户端扩展协议。如图4.1所示两个eMule客户端之间的握手。在所有这些扩展的信息里的内容是UDP信息交互，可靠性和源的性能。

                                                       图4.1

4.2可靠的用户辨认

      在1.4节简单的说了以下用户ID和其他使用者模拟真正用户的动机。可靠的用户辨认是eMule扩展的一部分。如果客户端支持可靠的用户辨认，在初始的握手之后就立即启动用户辨认。可靠辨认的目的是防止恶意的用户的模仿一个真正的用户，当一个可靠的辨认被用应时，它遵循以下步骤：

1.        在初始的握手阶段，B指出它支持和希望使用可靠的辨认。

2.        A响应发送一个可靠的辨认消息（6.5.8节），包括是否需要B的公共密钥，同样也包含一个4字节的有符号的标记。

3.        如果A指出需要B的公共密钥，B就发送它的密钥给A（6.5.9节）。

4.        B发送一个确认信息（6.5.10），这个信息包含A发送的4字节的标记，附加两个字节（A的IP和B的ID，B可能低ID或是高ID）。如图4.2所示

                                                              图4.2

4.2.1信誉系统

      这节简要的描述了一下客户端的信誉系统。信誉系统的目的是要鼓励用户分享自己的文件。当客户端上传文件时，下载的客户端依据传输数据的数量更新被下载客户端的信誉指数。注意这个信誉系统不是全局的，它被下载客户端保持在本地，只有在上传客户端请求从特定的客户端下载时才被重视，信誉按照很少几个规则被计算：

1.        上传总数*2/下载总数

      当下载的总是0时，等式的值是10。

2.        （上传总数+ 2）开方

      当上传总数小于1M是，等式的值是1。

上传/下载数量在数百万兆字节中被计算出来，无论如何信誉指数都不会超过10或小于1。

4.3 请求文件

      根据之前提到的为每一个【文件、客户端】对创建一个单独的TCP连接，在连接确认之后客户端立即发送几个查询消息（它想下载的文件）。一个典型的成功的过程如图4.3所示。

                                  图4.3

4.3.1基本的信息交互

      基本的信息交互包含4个消息：A发送一个文件请求消息（6.4.18节），紧跟着立即发送一个被请求的文件ID消息(6.4.17节)。B用一个文件请求回答消息（6.4.15节）答复文件请求消息，用文件状态消息（6.4.18）答复被请求文件ID消息。我是在找不到任何理由打这些发送信息分为4个消息，实际上更容易用两个消息来标示（请求和答复）。

      扩展的协议添加了两个消息到这个序列中，一个源的请求（6.5.6）和一个源的回答（6.5.7）。扩充过去习惯从B的源(如果B当前正在下载的文件)到A。详细的描述，B下载的文件没有下载完，它就可以向其他客户端发送文件的其他部分。B可以向A发送它已经下完的文件的部分，尽管这些片段只是整个文件很小的一部分。

4.3.2请求的文件没有找到

      当A向B请求一个文件，但B在它的共享的队列里没有找到这个文件。B跳过请求答复消息，在被请求的文件ID消息之后，立即发送一个文件没有发现的消息（6.4.16节）。如图4.4所示。

                    

                                                       图4.4

4.3.3上传队列

      如果B有被请求下载的文件并且它的上传队列不是空的，这说明有其他的客户端正在下载它的的文件，或许在上传队列中的客户端A和B完成了如图4.3所示的完整的握手，当A请求B开始上传它的文件时，B把A加到自己的上传队列里，并用一个队列类型消息答复A（6.5.4节），消息包括（A在B的上传队列中的位置。如图4.5所示的序列

                                  图4.5

4.3.4上传队列的管理

      每一个上传的文件客户端都为它维护一个具有优先权的队列。对于队列中的每一个客户端的优先权是根据每个客户端在队列中的时间和一个优先权的描述。位于队列头部的是具有最高优先权的客户端。优先权的值使用以下公式计算：值=（等级/在队列中的时间）/100或者是无穷大（如果下载的客户端被定义为被下载客户端的朋友）。除了被禁止的用户是0级别（从而阻止该客户端达到队列的顶部）以外，其他的原始值都是100。这个优先级别不是根据下载客户端的信誉度（取值在1—10之间）就是根据下载的文件的优先级（0.2—1.8），这个优先级是由上载的客户端设定的。当客户端的优先级的值高于其他客户端的优先值时，它就开始下载文件。A将继续下载这个文件直到以下的情况发生：

1.        上载的客户端被用户终止。

2.        下载的客户端已经下载完文件的所有部分。

3.        下载的客户端被其他比它优先级高的客户端抢占。

      为了下载的客户端在刚开始下载和被抢占以前能有机会下载到少许兆的数据，在最初的15分钟eMule推进下载客户端的优先级值到200。

4.3.5达到上传队列的顶部

      当A达到B的上传队列的顶部的时候，B连接A执行最初的握手同时发送一个接收上传请求消息（6.4.11节）。A现在可以选择继续和下载文件文件发送一个请求文件部分的消息，或者A可以取消下载（如果A已经下载完所请求文件的所有部分）发送一个取消传输的消息（6.4.12节）。如图4.6所示。

                                                              图4.6

4.4数据传输

4.4.1数据包

      发送和接收文件片是eMule主要的网络活动。有预言eMule将会使FTP时代终止，在文件片的传输和数据的处理有其余的eMule掌控。一个被发送的文件片的大小可以在5000和15000字节（依赖于压缩）。为了防止被分片，一个文件片消息被发送都在一个文件片之内，每个被发送的文件块都是一个单独的TCP包。在eMule V0.3最大的发送文件块的大小是1300字节（注意这个数指的是TCP的有效载荷）。为了双方的协商，每个控制消息都被以一个单独的TCP包发送，有时分派其他的消息，数据消息被分到几个TCP数据包中。第一个数据包包含发送文件的头（6.4.3节），其余的只包含数据。如果文件片在按照1300字节被分开时有残余，那么这部分残余就和第一个数据包一起被发送。如图4.7所示

                    

                                                                     图4.7

4.4.2数据传输顺序

      在一个文件请求答复以后，一个文件片的传输序列就立即开始。下载客户端A根据B的上传请求答复消息（6.4.11节）发送一个开始上传请求消息（6.4.10节）。之后A立即发送请求的文件片（6.4.4节），B用被请求的文件片答复A（6.4.3节）。注意单一的文件片请求可以请求直到3部分，所以每一个文件请求可以被答复直到3个发送的队列。

当所有的客户单都支持扩展的客户端协议时文件片被压缩发送（6.5.3）。扩展的协议同样也支持一个可选的文件信息消息（6.5.5）它仅仅在接收上传请求消息之前被发送。文件片的传输细细次序如图4.8所示：

                           图4.8

4.4.3选择那个文件下载

      eMule有选择的选择文件片的下载次序，为了最大限度的使用当前的网络资源。每个文件被分成9.28M的文件片，每个文件片又被分成180K的文件块。被下载的文件片的顺序有发送请求文件片请求消息（6.4.4节）的客户端决定。下载的客户端可能从不同源上特定的时间里下载同一个分片，所有被请求的分块可以来自同一个源的同一个分片。一下的规则来规定下载片的等级：

1.        大块的频率（可用的），非常突出的大块应给尽快的被下载，使成为一个可用的源块。

2.        对文件信息预览有用的块（文件头和文件结尾），预览文件信息和检查文件类型（.MP3）等。

3.        请求的状态，向另一个文件块设法请求每个源，在所有的源之间传播请求。

4.        完成（最短的完成的），块的部分得到将会下载完在开始下载其他人的资源之前。

频率定义了3个层次的标准：非常稀有、稀有和普通。在每一个层次内，标准有特殊的砝码，用来计算片的等级。有较低等级的片先被下载，