eMule协议Word文件下载.docx

eMule协议Word文件下载.docx

《eMule协议Word文件下载.docx》由会员分享，可在线阅读，更多相关《eMule协议Word文件下载.docx（63页珍藏版）》请在冰豆网上搜索。

Figure1.1:

eMulehighlevelnetworkdiagram

中，通常这些数据库包含了成百上千的共享文件清单和有效的客户端。

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连接中获得，有时该客户端端可能是HighID但是直到它的IP地址改变之前对于所有的服务器他将赋予同一个ID。

客户端ID被分为lowIDs和highIDs。

当客户端不能接受连入连接请求时eMule服务端将把它们标示为lowID。

拥有lowID的用户将被限制使用eMule网络并且可能导致服务器拒绝客户端的连接.想下面描述的一样一个highID的计算以这个客户端的IP地址为基础。

本章从eMule协议的角度上来描述客户ID的任务和意义[3]。

一个被给与highID的客户端允许其他的客户端自由的连接到他主机的eMule的TCP端口（默认的端口号是4662）。

拥有highID的客户端可以无限制的使用eMule网络。

当服务端不能够与客户端的eMule端口建立TCP连接，该客户端奖杯给予lowID。

只主要是由于客户端在他们的机器上设立的防火墙阻止引入的连接。

由于下面的情况客户端同样也有可能获得lowID:

•当客户端是通过NAT或者代理服务器连接的

•当服务端过于繁忙（导致服务端的重接计时器到时间）

HifhID是通过下面的方法计算的：

假设主机的IP是X.Y.Z.W这个ID将是X+28*Y+216*Z+224*W（’big-endian表示法）。

一个lowID总是小于16777216（0x1000000），我找不到过于他是如何计算的线索，注意不同的服务器中你拥有的lowID是不同的。

一个lowID没有允许其他客户端客户连入的公共IP，所以所有的信息必须通过eMule服务器。

这增加了服务器的计算负担并且直接导致了服务器不愿意接受lowID客户。

同样这也意味着不同服务器之间的lowID用户之间不能够建立连接，因为eMule不支持服务器之间的请求通道。

为了支持lowID用户复查机制被引入了。

通过这个机制一个highID客户可以邀请（通过eMule服务器）lowID用户和它建立连接来交换文件。

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.6eMule协议的扩展

尽管eMule完全的兼容了eDonkey,但是他还实现了几个扩展来允许两个客户端之间向他们的使用提供附加的功能。

这些扩展主要用于客户端与客户端之间的信息交换尤其是安全领域和UDP协议的利用。

在本文当中所有eMule扩展部分的流程图制定消息都是灰色的。

1.7软界限和硬界限

服务器的配置包含两种界限，这取决于使用中用户的数目-软界限和硬界限。

硬界限比软界限提供更大的平衡。

当使用中的用户的数目达到软界限时服务器停止接受新的lowID用户的连接，当使用者数目达到硬界限的时候服务器就满了并且不再接受任何连接。

2客户服务器TCP信息

每一个客户端使用TCP连接连接到唯一一个制定的服务器。

这个服务器将分配给这个客户端一个ID，这个ID将在该客户与其他服务器会话的过程中唯一的标示自己（一个highID用户总是依据其IP地址进行分配的）。

为了使一个eMule图形用户界面客户端运作起来首先要和服务器建立一个连接。

客户端既不能同时连接多个客户端也不能再没有用户的干涉下自动改变客户端的连接。

2.1连接的建立

在建立与服务器的连接时客户端尝试着向许多平行服务器建立连接，成功登陆序列之外的将全部被放弃。

图2.1:

HighID登录序列

有许多可能成功建立连接的情况：

1．HighID连接-服务器分配给连入的客户端一个highID

2．LowID连接-服务器分配给连如客户端一个lowID

3．拒绝会话–服务器拒绝该客户端

当还还有少数情况例如:

服务器崩溃了或者服务器是不可到达的。

图2.1描述了建立一个highID连接的消息顺序。

在这种情况下客户端先和服务器建立一个TCP连接然后向服务器发送登入请求消息。

服务器使用另外一个TCP连接连接客户端，这个连接扮演了一个client-to-client的握手过程，通过这个连接服务器来确定该客户端是否有接受其他客户端连入连接的能力。

完全完成客户端握手之后服务器关闭第二个连接并且向客户端发送一个ID变换消息然后结束客户-服务器的握手会话。

你或许注意到了eMule-info消息是灰色的。

这是因为这个消息是eMule扩展协议（1.6章节）的一部分。

图2.2:

LowID登录序列

图2.2描述了建立一个lowID连接的消息顺序。

这种情况发生在服务端尝试与客户端建立连接失败并分配各该客户端lowID。

这样的服务器消息通常包含警告信息，例如：

”Warning[serverdetails]-Youhavealowid.Pleasereviewyournetworkconfigand/oryoursettings.”Low和highID握手都是以ID变更消息作为结束的,这个消息分配了该客户端今后它与其他服务器会话时所使用的客户ID。

图2.3描述了拒绝连接的消息顺序.由于客户端拥有的是lowID或者当服务器达到了他们的硬界限时它们会拒绝客户端的连接。

服务器消息将报还关于拒绝原因的简单描述。

图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复查机制

复查机制的引入是为了克服lowID用户不能够接受引入的连接因此不能与其它的客户分享它们的文件。

这个机制很简单：

比如A,B连个客户端连接到同一个eMule服务器，A需要一个B所拥有的文件但是B是一个lowID，A可以向服务器提交一个复查请求（见6.2.13章节），请求服务器让B来主动请求A。

与B已将建立一个开放的TCP连接的的服务器将向B发送一个复查请求消息（6.2.14章节）,向B提供A的IP地址和端口号。

B就可以不借助服务器向A发送文件了。

很明显的，只有拥有highID的客户端可以向拥有lowID的客户端请求复查（一个lowID的客户端不能够接受连入连接请求）。

图2.6将描述复查机制的消息交换。

依靠服务器作为中介我们也可以进一步来实现两个lowID的用户之间的文件交换。

但是由于大多数服务器的负载能力有限，他们不再支持这项功能。

图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章节中描述）与TCPcounter部分的格式很相似。

注意与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是lowID的情况下是A的IP地址，在B是highID的情况下是B的ID号。

图4.2将描述这个序列。

图4.2:

用户安全识别过程

4.2.1荣誉系统

这一章节简单的描述了客户端的荣誉系统。

这个荣誉系统的目的是鼓励用户们共享文件。

在客户端向它的peer上传文件的时候，正在下载的客户端根据下载数据的总量来更新它的荣誉度。

注意荣誉系统不是全球性的-荣誉度被存储在下载中的客户端的本地磁盘并且仅当上传客户端（获得荣誉值）想要从明确的客户端下载文件是时才会被转化为数值。

荣誉值取决于下面几种情况的最小值：

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

当下载总数是0的时候表达式的值为10

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上传队列管理

客户端对于每一个上传的文件都有一个上传优先权队列。

队列中的每一个优先权是基于队列中等待的时间和一个优先权参数计算出来了。

在队列头部的客户有有罪该的分数。

这个得分的计算公式如下：

得分=（优先级*在队列中等待的时间）/100或者在下载客户端是好友时这个结果时1。

初始的优先级数值是100，当又不被禁止的时候优先级数值为0（为了防止被禁止客户到达队列的顶端）。

这个优先级数值将会通过下载用户的荣誉值

图4.5:

文件请求等待队列

（大小是1-10）和上传客户端设置的上传冲互设定得上传文件优先级（0.2-1.8）来修正。

所有等待队列中得分最高的客户端进行文件的下载。

在以下情况发生时客户将中止下载：

1．上传客户端被用户关闭了。

2．现在客户端完全下载完成了。

3．现在中的客户端被逼他用的优先级