logo资料库

eMule1.0协议（ed2k协议）中文版.doc

发布时间：2022-06-14 发布人：admin 分类：说明书 资料大小：1.92M 资料格式：doc 举报 版权申诉
第1页 / 共40页
第2页 / 共40页
第3页 / 共40页
第4页 / 共40页
第5页 / 共40页
第6页 / 共40页
第7页 / 共40页
第8页 / 共40页
资料共40页，剩余部分请下载后查看
    eMule 协议说明书 1 简介 1.1 目的 eMule 是一个如今非常流行的基于eDonkey协议的文件共享程序。 本文描述了eMule的 网络行为并且解释了一些我们理解这个协议所需要的基本学术用语。 并且本文也是 eMule网络协议的一个详尽的说明书，内容包括传送的消息的结构， 本文中所有的信息 是基于一个开源的eMule的客户端[2]。下文的目的是让读者有一个整体的概念去阅读和 理解这些文档.一个关于eMule的巨大信息. [3]。 1.2 概述 eMule网络是由数百台eMule服务器和数百万的eMule客户端组成的[1]。为了进行网络通 信客户端将连接到一个服务器，只要这个客户端还在这个系统当中这个服务器连接就一 直存在。这些服务器集中执行这索引服务(就像在Napster中一样)并且不与其它的服务器 进行交流。每一个eMule客户端都在其本体文件系统中预先配置了一个服务器列表和共 享文件列表文件。客户端只使用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 +224 *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中例证的请求。
    分享到：
    赞 收藏

    相关推荐

    资料库

    开发技术

    共收录19306份资料，累计14个分类，关注成员有19位，主要包括：Actionscript,Javascript,PHP,VB,Perl,Delphi,Python,C#,C,Java,C++,Web开发,硬件开发,其它

    热门标签

    Actionscript Javascript PHP VB Perl Delphi Python C# C Java C++ Web开发 硬件开发 其它

    最新资料