eMule 协议分析翻译
（The eMule Protocol Specification）
| 作 者：starshift 版 本：.v1.0 开始时间：200.6.10.15 结束时间：未知 备 注：本文可以自由转载，引用，但请注明原作者和出处。 |
| 原 文：The eMule Protocol Specification Yoram Kulbak and Danny Bickson Email: {yorkol,daniel51}@cs.huji.ac.il Academic supervisor: Prof. Scott Kirkpatrick DANSS (Distributed Algorithms, Networking and Secure Systems) Lab School of Computer Science and Engineering The Hebrew University of Jerusalem , Israel January 20, 2005
|
写在前面
这是一篇在我下面的工作中不得不读的文档，因为没有看见翻译稿，又特别需要弄通熟悉，我决定自己翻译。
但是，我不会完全按照作者的意思，我只是看懂了之后再说出来，以便借机锻炼自己。如果有误，请参照原文。
一， 简介
1.1 Purpose & Scope 略
1.2 Overview
eMule 网络由几百个eMule服务器和数十万的eMule客户端组成，客户端需要连接到一个服务器以获得相应的网络服务，并且连接贯穿客户端存在于ed2k的始终。服务器（象Napster一样）提供资源的索引服务，但是相互之间并不交互。
每个eMule客户端都维持者一个一定数目的服务器和其上共享资源的列表。并通过TCP连接登陆到服务器上加入到ed2k网络，以便检索需要的文件信息和连接到可连接的主机。然后，再发起一定数目的TCP连接连接到其他主机以便进行必要的上传和下载。同时，在每个eMule的客户端上面也维护着一个上传队列，下载者需要在队列中排队，只有在他们排队排到队列的顶端的时候才可以下载数据。eMule支持多源传输，下载者可以在多个源处同时下载文件的不同分片。同时也支持客户端在下载未完成时上传已经得到的分片。最后，eMule还扩展了eDonkey的功能，允许用户之间交换服务器，文件索引等信息。但是这些交互都是基于TCP的。
服务器端采用一个可以交互的数据库存储文件和客户端的信息，但不存储任何文件，只是作为一个中心化的资源检索和定位引擎。服务器的另外一个角色，就想下面将要描述的，是作为在防火墙后面或者彼此之间不能直接建立连接的客户端之间的通信桥梁。同时，emule也采用了UDP协议来加强客户端和服务器以及客户端和客户端之间的联系。客户端之间发送和接受UDP数据包在emule的正常工作模式下不是托管的。同时，当防火墙对UDP数据包的通过限制时也将造成程序功能的缺陷。
1.2.1客户端与服务器之间的通信
在成功的和客户端建立了TCP连接之后，服务器为客户端分配一个仅在本次连接的生命周期范围之内有效的客户端ID（详见1.3节）（注意：如果客户端的ID使high ID那么，它在所有服务武器的ID都将不变，当且仅当它的IP变化时，它的ID才变化。）。在连接建立之后客户端上传给服务器其上共享资源的列表。服务器把这些信息存储在它的数据库中，其中包含数十万可用的文件和客户端信息。客户端同时也将上传包含其需要下载的文件信息的下载列表。在第2节我们将讨论客户端与服务器TCP连接的细节。
在连接建立之后，服务器向客户端发送一个包含其请求的文件的接点列表（这些接点被叫做源）。由此，接点建立和其他接点的连接。
注意到客户端和服务其之间的连接将一直保持在整个会话期间，在初始的握手之后，传输活动主要由客户端的活动来触发。有时，由客户端发起一个文件搜索请求，然后由服务器响应。在对一个特定文件的搜索请求之后就时搜索传输了。客户端将收到一个节点的列表作为这个请求的应答。
UDP数据包用来与客户端连接到的服务器之外的服务器通信。其作用是加强文件和源搜索。最重要的是保证在客户端服务器列表中的服务器都是可用的。我们将在第3章详细的讨论这个问题。
1.2.2 客户端之间的通信
一个emule客户端连接到另外一个emule客户端以便下载文件。每个文件被分割成小部分，并进一步分割成小片。客护短可以重若干个（不同的）客护短下载同一文件的不同小片。
当两个客护短建立了连接，他们交换彼此的能力信息，然后开始下载（或上传）。每个客户端都有一个由下载者构成的下载队列。当一个下载请求到达时，如果下载队列为空，那么请求就可以马上得到满足。如果下载队列不为空，那么下载者就要在队列中等待，直至排到队列的顶端。当某一特定时刻所有下载者的平均带宽小于2.4KB/S的时候，客户端将不再供其他客户端下载。正在下载的客户机也可能被其他排在队列顶端的客户机抢占，当下载进行15分钟后，下载队列将自动推进一位以预防死锁。（应该是这样）
当一个下载者到达下载队列的顶端时，客户机就会发起一个TCP连接到下载者，并提供其所需的文件分片。一个emule客户端可能在若干不同的其他客户端排队下载同一个文件分片，当他下载完成后，他不会通告每个上传者，而是在到达队列顶端时简单的拒绝上传者的上传请求，并退出队列。
Emule采用了一种信用机制来鼓励上传者，并采用RSA 进行加密。
同时，emule 也采用了一些edongkey协议中没有规定的扩展协议.这些协议用做执行信用机制,交换特定信息（比如更新服务器和源信息）或者是通过压缩文件分片来提高传输的效率。
1.3 客户端ID
客户端ID由服务器在初始握手时创建的4byte标志符，虽然high ID 用户在IP地址改变之前在所有服务器上ID 都不变，客户端ID只在客户与服务器的TCP连接期间有效。当客户端不能接受外部发起的连接的时候，它将会被服务器分配一个low ID，这将限制客户端连接到emule网络，甚至有些服务器拒绝low ID连接。High ID 是根据下面将要介绍的方法用客户端的IP地址计算出来的。这段文档我们介绍emlue协议是如何委派客户端ID的。允许其他客户端自由连接到其端口（一般为4662）的客户端将被分配一个high ID。high ID 的用户不受任何限制。当服务器不能打开一个到客户端的直接连接的时候它分配给客户端一个low ID。这一般是由于客户端的防火墙阻断了来自外部的连接。或者是由于：
（1） 客户端是通过NAT或者其他代理接入的。
（2） 服务器过于忙碌（导致服务器计时器超时）
High ID由如下方法计算得到：设，主机IP地址为X.Y.Z.W，那么Hight ID 为X+28 *Y +216 *Z+224 *W. Low ID 通常小于1677216(0x1000000). 目前并不知道low ID是如何计算的，但是在不同服务器取得的low ID是不同的。
Low ID 客户端没有公共的IP地址，所以所有的通信都依赖于服务器的中转。这造成了服务器的负担，一些服务器不愿意接受low ID 的连接。同时，Low ID 用户也不能连接到不同服务器的其他的low ID用户，因为emule不支持服务器之间的通信。
1230
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
