emule协议分析

admin管理员组

文章数量:1530518

2023年12月17日发(作者：)

最主要的参考文本是eMule协议1.0版，原文地址。分析的流程是简要翻译加上我的思考，我的目标不在于完整的翻译，想看完整翻译的可以关注下p2p分发引擎研究这个Blog，他正在翻译协议文本。我的思考和点评会用红色标出。

--------

电骡eMule是基于电驴eDonkey协议的。电骡网络是由数百个电骡服务器和数百万的电骡客户端组成的。客户端必须连接到服务器来获得网络服务，这个连接要一直保持直到客户端关闭。服务器提供集中的索引服务（类同Napster），不同的服务器之间没有通讯。

每个电骡客户端都预先设置好了一个服务器列表和一个本地共享文件列表。客户端通过一个单一的TCP连接到电骡服务器进行网络登陆，得到想要的文件的信息和可用客户端的信息。（这样造成了电骡和电驴都不能完全去中心化，虽然文件存储在客户端上。）电骡客户端用几百个TCP连接与其他的客户端连接进行文件的上传和下载。每个电骡客户端为它的共享文件维护一个上传队列。正在下载的客户端加入这个队列的底部，然后逐渐的前进，直到他们达到队列的顶端开始下载文件。一个客户端可能从多个其他的电骡客户端下载同一个文件，从不同的客户端取得不同的部分。客户端也可以上传一个没有完全下载的文件的部分数据。（文件可以分块传输大大提高了效率，但是也造成了一些问题，比如源提前退出以后，所有的客户端都是不完全数据的情况。）最终，电骡扩展了电驴的能力允许客户端交换关于服务器、其他客户端和文件的信息。（这个能力又开始把中心的意义淡化。）注意，客户端和服务器的通信都是基于TCP的。

服务器使用一个内部数据库来保存客户端和文件的信息。电骡服务器不保存任何文件，它是文件位置信息的中心索引。服务器的另一个功能，正在受到质疑，他将作为通过防火墙连接的客户端之间的桥梁，这样的客户端不能接受引入的连接。桥接功能大大的增加了服务器的负载。（这个功能让服务器承担了过分的负担，大大降低了服务器的能力，在设计中应该摒弃，目前应用中大部分的服务器已经关闭了这个功能，也就是说两个Low id的客户端是不能传输数据的。）电骡使用UDP增强客户端跟服务器和其他客户端的通信能力。但是客户端收发UDP信息的能力不是客户端日常操作强制要求的，即使防火墙阻止客户端收发UDP信息，客户端仍能完美的工作。

客户端到服务器的连接

图一 电骡网络图

客户端一启动就会用TCP连接到一个电骡服务器。服务器给客户端提供一个客户端ID，这个ID仅在客户端服务器连接的生命周期内有效（注意如果客户端是高 ID，那么他在所有的服务器得到的ID都是一样的，直到他的IP地址变化为止）。连接建立后，客户端把它共享的文件列表发送给服务器。服务器把这个列表保存在它的内部数据库内，这个数据库通常包括了数十万可用文件和活动客户端。电骡客户端也会发送它的下载列表，包含了他想要下载的文件。后面将给出电骡客户端和服务器间的TCP信息交换格式细节。

连接建立以后，电骡服务器给客户端发送一个列表，这个列表包括了那些有客户端需要的文件的客户端（这些客户端叫做源）。然后，客户端就去跟那些有所需文件的客户端建立连接。

注意客户端服务器的TCP连接在整个客户端会话过程中都会保持。初始化握手之后，事务主要是由用户活动触发的：有时客户端发送一个文件查找请求给服务器，服务器会返回一个查找结果，一个查找事务之后通常是一个对指定文件的源查询，这个查询的结果是一个可以提供该文件下载的源的列表。

电骡客户端用UDP来跟登录服务器以外的服务器进行通信。UDP信息的用途是增加文件搜索能力，源搜索能力，保持连接。

客户端到客户端之间的连接

电骡客户端一般是为了下载某个文件才会连接到其他的客户端（也就是源）的。一个文件会被分为很多块。客户端会从多个客户端（源）那里下载同一个文件，从不同的源下载文件的不同部分（这样不同的部分就可以同时被下载，如果源多，下载的效率就会极高）。

当两个客户端连接后，他们会交换容量信息，然后协商开始下载(或者说是上传,这取决于视角)的时间。每

个客户端有一个下载队列，用来保存正在等待下载的客户端的列表。当电骡客户端的下载对列为空的时候，下载请求会被马上接受（除非这个请求者已经被屏蔽）。如果下载对列不为空，那么新的下载请求就会放在队列之中。不会努力服务更多的客户端，对每个下载客户端至少保持不少于2.k字节/每秒。一个正在下载的客户端的下载地位可能被一个对列等级（queue ranking）比他高的等待客户端抢占，在下载进程中的前15分钟正在下载的客户端的队列等级会增长用来避免产生颠簸（这里说的颠簸就是说，一个客户端频繁的从下载地位切换到等待状态，然后再切换回去。这种频繁的切换叫做颠簸，这对资源是种浪费，所以要避免。）。

当正在下载的客户端到达了下载队列的顶部，提供上传的客户端初始化一个连接用于把它需要的文件片断传送给它。一个电骡客户端可能会在多个源客户端的等待队列中，在每个客户端上注册要求同一个文件片断。当这个等待客户端实际上完成了这个文件片断的下载，他不会通知那些源客户端删除它的请求，而仅仅是在它在那些源客户端的队列中排到顶端的时候拒绝上传请求而已。

电骡使用一个声望系统来鼓励上传，为了防止假冒，电骡用RSA公钥加密技术来保护声望系统。

客户端连接中会使用很多电驴协议（eDonkey protocol）没有定义的消息，这些消息叫做扩展协议。扩展协议用来实现信用系统，用来进行信息交换（例如，服务器列表的更新和源的更新），通过对文件块进行压缩提升发送和接收的效率。电骡客户端连接中有限地使用UDP去周期其他客户端的状态。

客户端ID

客户端是一个4字节的标识符，在跟服务器连接握手的时候由服务器提供的。客户端ID仅在客户端服务器TCP连接的生命期内可用，虽然如果客户端是高ID （High ID），它在任何服务器分配的客户端ID都一样，除非IP变化了。客户端ID分为低ID（low ID）和高ID。电骡服务器通常会给不能接受连接的客户端分配低ID。拥有低ID会限制客户端在电骡网络中的使用，甚至会造成服务器拒绝连接。高ID是由客户端的IP地址为基础算出的。这里从电骡协议的观点来看客户端ID的分配和表示。得到高ID的客户端允许其他的客户端自由地连接他的电骡TCP端口（默认为4662）。得到高ID的客户端在电骡网络内不受任何限制。当服务器不能打开一个连往客户端的电骡端口的连接时，服务器给客户端一个低ID。这主要是客户端安装了防火墙组织外来连接造成的。以下情况下，客户端会得到低ID：





当客户端通过NAT或者代理服务器上网。

当服务器正在忙（造成服务器的连接计数器超时，从而认为客户端无法连接）。

高ID通过下面的方法计算：假设机器IP地址为X.Y.Z.W，客户端ID应该为 X+28*Y+216*Z+224*W（big endian高位在前）。低ID总是小于15777216(0x1000000)我不知道它是怎么计算的（协议原文如此，看来低ID的算法并不重要，只要满足条件即可。），注意从不同的服务器得到的低ID是不一样的。

低ID的客户端没有公开的IP地址供其他的客户端连接，所以所有的通信必须通过电骡服务器。这会造成服务器的负载提升，所以服务器不愿意接受低ID的客户端。同样，这说明低ID的客户端不能跟其他服务器上面的低ID客户端连接，因为电骡不支持服务器间的桥接。

为了支持低ID客户端电骡协议引入了回调机制。使用这种机制，一个高ID客户段可以要求（通过服务器）低ID客户端连接它来交换文件。

（现在大部分服务器不会拒绝低ID的客户端连接，因为他们基本上都不帮助客户端传输文件了。由此，低ID的客户端之间也无法传输了。）

用户ID

电骡支持声望系统为了增加用户的文件共享。一个用户上传给其他客户端越多东西，它就得到越多的声望，这样它在他们的等待队列中前进就会越快。用户ID是一个128位（16字节）GUID，通过连接随机数而产生，第6和第15位不是随机生成的，他们分别是14和111。用户ID仅在客户端和服务器会话中有效，用户ID是唯一的用来标识客户端。用户ID在声望系统里面起了很大的作用，攻击者冒充其他用户就是为了得到它们声望对应的权利。电骡提供了加密方案用来用户欺诈。实现方式是用RSA方法来加密方法来加密信息交换。

文件ID

文件ID用于网络中文件的唯一标识，以及文件损坏的检测和修复。注意电骡对文件进行唯一标识和编目不依赖于文件名，文件由其内容哈希计算出来的全局唯一ID来标识。文件ID有两种，一种用来生成唯一标识，一种用于文件损坏的检测和修复。

文件哈希

文件是用一个128位的GUID来标识的，这个GUID是由客户端用文件内容哈希计算出来的。GUID使用MD4算法计算。计算文件ID的时候文件被分成 9.28MB的大小。一个GUID是分别计算每个文件块的哈希，然后把它们合成为一个唯一文件ID。下载客户端完成文件块的下载后，会计算块的哈希和文件上传端发送来的文件块哈希做比较，如果不同，就说明文件块损坏了，客户端将逐块的覆盖（一次180kb）知道哈希计算表明文件块已经修复为止。

根哈希

根哈希是每个文件块用SHA1算法计算出来的，每个计算单元尺寸为180kb。它提供了更高级别的可靠性和错误恢复。

电骡协议拓展

虽然电骡（eMule）完全兼容电驴（eDonkey），但是它还是实现了一些扩展，用于增强它的功能。扩展关注于客户端和客户端之间的通信，特别是安全领域和UDP工具。

软件和硬件限制

服务器设定包括两种对活跃用户数目的限制，软件的和硬件的。硬件限制大于等于软件限制。当活跃用户数目到达了软件限制，服务器停止接受新的低ID客户端连接，当用户数目达到了硬件限制，服务器不会接受任何连接。

2 客户端服务器的TCP交流

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

2.1 建立连接

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

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

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

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

3、拒绝会话-服务器拒绝客户端

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

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

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

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

2.2 连接启动时消息交换

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

2.3文件搜索

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

也有允许两个低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。

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

在eMule客户端注册到服务器和向服务器查询文件和源之后，为了下载文件，eMule客户端需要联系其它客户端。为每对[文件，客户端]创建一个专用的TCP连接。当特定的周期内（默认40秒）没有任何socket活动或者对方已经关闭了这个连接，那么这个连接就会关闭。

为了提供合理的下载速率，直到可能提供给它（和所有其它下载的客户端）至少最小允许速率（当前的硬编码常量设置为2.4k/s），eMule才允许客户端开始下载文件。

4.1 初始的握手

初始的握手是对称的 - 双方都相互发送相同的信息给对方。客户端交换双方的信息，信息包括身份认证、版本和容量等。参与的有两种类型消息 - Hello消息（6.4.1节）和eMule信息消息（6.5.1节），第一种是eDonkey的一部分，兼容eDonkey客户端，第二种是eMule独有的扩展客户端协议的一部分。图4.1图解了两个eMule客户端之间的握手。在扩展信息中包含的有UDP消息交换、安全身份证明和源交换能力。

4.2 安全的用户身份认证

1.4节简单解释了关于用户ID和用户假冒其它用户的动机。安全用户认证是eMule扩展的一部分。如果客户端支持安全认证，就会在初始化握手之后立即执行。安全认证的目的是防止用户冒名顶替。当实施安全认证时，执行以下步骤：

1.在初始化握手中，B客户端指明它支持和希望使用安全认证。

2.通过发送安全认证消息（见6.5.8）来回应，指明A是否需要B的公匙，也包含了B发出的4字节的询问。

3.如果A指明它需要B的公匙，B就将它的公匙发送给A（6.5.9节）。

4.B发送一个签名消息（6.5.10节），签名消息是用发送过来的询问和额外的双字节创建的，双字节要么是A的IP地址如果B是低ID，要么是B的ID如果它有高ID。图4.2演示了这个顺序。

4.2.1 信用系统

本节简要地描述了客户端的信用系统。信用系统的目的是鼓励用户共享文件。当客户端上传文件给它的对方，下载的客户端就根据数据传输的数量来更新它的信用。注意，信用系统不是全局的 - 传输的信用被下载的客户端局部保存，只有当上传的客户端（获得信用的那个）要求从这个特定的客户端下载时，信用才会被考虑。信用是用下面最小值计算的：

1. 上传的总量 * 2 / 下载的总量

当下载的总量是零时，这个表达式估值是10

2. 上传的总量 + 2 的和开方

当上传的总量小于1MB，这个表达式估值是1

上传/下载数量是以M为单位计算。任何情况下，信用不会高过10或者低于1。

4.3 请求文件

正如已经提到的一样，每对[客户端，文件]都创建一个独立的连接。在连接建立之后，客户端立即发送几个关于它希望下载的文件的请求消息。4.3节描述了一个典型的、成功的情景。

4.3.1 基本消息交换

基本消息交换是由四个消息构成：A发送一个文件请求消息，立即跟着的是请求文件ID消息（6.4.17节）。B用文件请求回答回应文件请求，用文件状态（6.4.18节）来回应请求文件的ID消息。我找不到任何理由来把这些发送过来的消息中的信息分成四个消息，它可以容易地用两个消息（请求和回应）来处理。

扩展协议增加两个消息到这个顺序中，源请求消息（6.5.6节）和源回应消息（6.5.7节）。用这个扩展来传递B的源（假定B当前下载着文件）到A中。详细阐述就是，在它能发送文件块给其它客户端之前B完成下载一个文件是没有任何要求的，B可以发送任何它已经完成下载的文件块，甚至当它只是用文件的一小块。

4.3.2 没找到文件的情景

当A向B请求一个文件，但是B的共享文件列表中没有这个文件。B忽略这个文件请求回应消息，在请求文件ID消息之后立即发送一个没有文件消息（6.4.16节），如图4.4所演示。

4.3.3 加入上传队列

当B有被请求的文件但是它上传队列不为空，意味着有正在下载文件的客户端，也可能有客户端在上传列表中，在这种情况下，A和B执行满握手，如图4.3所述，但是当A请求B开始下载文件时，B把A加入到它的上传队列中，回应一个队列等级消息，这个消息包含A在B地上传队列中的位置。图4.5演示了这个顺序。

4.3.4 上传对列管理

对每个上传的文件，客户端维护着一个上传优先级队列。队列中的每个客户端的优先级是以客户端在队列中的时间和优先级修正为基础计算的。位于队列头部的客户端有一个最高级别的分数。分数是用以下的方程式计算的：分数 = （等级 * 队列中的秒数）/100或者无穷大，如果下载的客户端被定义为朋友。初始化的等级值是100，除开禁止的用户是0等级（这样阻止达到队列的前面）外。等级可以被下载客户端的信用（范围1-10）或上传文件优先级（0.2-1.8）修改，上传文件优先级是由上传客户端设置的。当一个客户端的分数比其它的客户端高时，它就开始下载文件。客户端可以继续下载文件直到产生以下任一个条件：

1.用户关闭了上传客户端。

2.下载的客户端得到了它所需文件的所有部分。

3.下载的客户端给其它拥有比它更高优先级的客户端抢占。

为了允许一个刚刚开始的客户端在它被抢占之前可以得到几M的数据，eMule在客户端下载的前15钟内增加初始等级到200。

4.3.5 到达上传队列的顶部

当A到达B上传队列的顶部时，B连接A，执行初始握手，然后发送一个接收上传请求消息（6.4.11节）。A现在可以选择要么发送请求块消息来继续下载文件，要么发送取消传输消息来取消（如果它已经从别的源得到了这一块）。图4.6演示了这些选择。

4.4 数据传输

4.4.1 数据包

发送和接收文件块是eMule网络活动的主要部分。用FTP解释eMule可以推论出，当所有其它eMule可以控制，发送的文件块适合数据传输。发送的文件块大小可以是在5000到15000位（也根据压缩）范围内。为了避免出错，文件块消息在碎片中发送，每碎片在一个独立的TCP包中。在eMule 0.30e版中，最大的碎片大小是1300位（注意，这个数字只与TCP有效负载有关）。换句话说，当每个控制消息在单独的TCP包中发送，有时和其它消息共享，数据消息被分成几个TCP包。第一个包包含发送文件块消息头部（6.4.3节）。剩下的包值包含数据。当被分成1300，如果发送块的大小有剩余，和第一个包（这个包带有头部）一起发送。图4.7演示了文件块消息。

4.4.2 数据传输顺序

在文件请求回应之后立即开始块传输顺序。下载客户端A发送一个开始上传请求（6.4.10节），然后一个接收上传请求消息（6.4.11节）回应这个请求。A在这之后立即开始请求文件块（6.4.4节），B通过发送被请求块（6.4.3节）来回应。注意，单独的文件块请求可能请求可达3块之多，所以每个文件块请求可能被可达3个发送的块顺序回应。

当两个客户端都支持扩展的客户端协议，文件块可能压缩发送。扩展协议也支持可选的文件信息消息（6.5.5节），该消息就在接收上传请求消息之前发送。图4.8演示了块传输消息顺序。

4.4.3 选择块下载

为了最大化整个网络的吞吐量和共享，eMule仔细挑选选择块的下载顺序。每个文件被分成9.28M的块，每部分分成180KB的片。

块下载的顺序是由发送请求文件块消息（6.4.4节）的下载客户端决定。下载客户端可以在任何给定时刻

从各个源中下载一个单独的文件块，所有从相同源中请求的片都在同一个块中。下面的原理（以这个顺序）应用于下载块等级：

1.（可获得的）大片的频率，尽可能快的下载非常稀少的大片来形成一个新的源。

2.用来预览的块（最初+最后的大片），预览或检查文件（比如，电影、mp3）

3.请求状态（过程中下载），尝试向每个源询问其它的大片。在所有源之间扩散请求。

4.完成（未到某种程度的完成），在开始下载另一个时应该完成获得部分的大片

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

l

0-9999 - 不请求和请求非常稀少的块

l

10000-19999 - 不请求稀少和预览块

l

20000-29999 - 不请求大部分完成的一般的块

l

30000-39999 - 请求的稀少和预览的块

l

40000-49999 - 请求的没有完成的一般的块

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

4.5 浏览共享的文件和文件夹

有两个消息流程来处理每对客户端之间的共享文件和文件夹的浏览。第一个是浏览共享文件消息（6.4.21节），该消息在初始握手后立即发送。通常由一个浏览共享文件回应消息（6.4.22）来回应这个消息。当回应的客户端想隐藏它的共享文件列表时，回应就包含零个文件（而不是发送一个指示访问拒绝的消息）。图4.9演示了这个消息顺序。

第二个消息流程随着一个浏览共享的文件夹列（6.4.23节）表请求开始，通过共享文件夹列表来回应这个消息，然后，对于回应中的每个文件夹，发送浏览共享文件夹内容的消息。当消息到达时，回应的每个消息带有内容列表。图4.10演示了这个消息顺序。

如果接收的客户端设置了阻塞共享文件/文件夹请求，它用请求共享拒绝消息回应，如图4.11所示。

4.6 交换片哈希集

为了取得片的哈希，发送一个哈希集请求，这个请求通过一个包含文件中每块的哈希集回应来回答。图4.12演示了这个。

4.7 取得文件预览

客户端可以请求对方来获得下载文件的预览。预览是种独立的、随着文件类型不同而不同的应用。eMule

0.30e只支持图像预览。这个消息交换如图4.13描述，只包含两种消息：预览请求（6.5.11节）和预览回应（6.5.12节）。

5 客户端到客户端的UDP连接

eMule客户端周期性地用UDP协议发送消息。在eMule0.30e中，使用的UDP消息只是询问客户端在对方下载队列中的位置。这个简单的请求-应答方案是随着重复要求文件消息(6.6.1节)而开始的。对于这个请求，有三种可能的回应，如图5.1所示。

1. 队列等级 - 客户端在发送者队列中的等级

2. 队列满 - 发送者队列已满

3. 找不到文件 - 发送者在它的列表中没有被请求的文件

重复要求文件消息大约每20分钟的间歇发送到每个客户端，这些客户端把发送者加入到它的下载队列中。

本文标签： 客户端文件服务器消息连接