eMule协议简要分析[二]

[日期：2006-10-08]来源：  作者：[字体：大 中 小]

eMule协议简要分析[二]

eMule协议专题

• eMule协议简要分析[一]
• eMule协议简要分析[二]
• eMule协议简要分析[三]

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

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

当两个客户端连接后，他们会交换容量信息，然后协商开始下载(或者说是上传,这取决于视角)的时间。每个客户端有一个下载队列，用来保存正在等待下载的客 户端的列表。当电骡客户端的下载对列为空的时候，下载请求会被马上接受（除非这个请求者已经被屏蔽）。如果下载对列不为空，那么新的下载请求就会放在队列 之中。不会努力服务更多的客户端，对每个下载客户端至少保持不少于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+2⁸*Y+2¹⁶*Z+2²⁴*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客户端连接，当用户数目达到了硬件限制，服务器不会接受任何连接。
# posted by tiny @ 11/19/2005 12:37:00 下午   Comments: 3呢
# posted by Anonymous : 10:45 下午   最近很忙,还没写好
# posted by tiny : 10:54 下午   我没有看过电骡的协议
但是我有点疑问：现在一般的im都会使用到p2p协议，当然诸如bt\emule之类的p2p工具比Im使用到的p2p功能要复杂。

通常位于nat后的两个客户端要点对点通信的话，要使用到我们常说的p2p打洞技术，即通过服务器交换信息后，在通过udp协议，利用nat设备的一些特性在两个位于nat后的客户端之间建立连接。具体的Udp打洞方法可参看： http://midcom-p2p.sourceforge.net/draft-ford-midcom-p2p-01.txt

目前，对于大多数上网的pc机来说，都是位于nat后面的，所以，在你所说的描述中，似乎电骡更多的是依靠tcp，这样的话，岂不是很多上网用户就不能用电骡了
提出此疑问，欢迎讨论。
# posted by bluecrystal : 4:54 下午   你说的没错，这就是电驴/电骡为什么要分高ID和低ID的原因

高ID就是直接连接的，低ID就是通过Nat连接的。高ID和高ID可以连接，高ID和低ID可以连接，低ID之间不能连接。（除非有服务器作为中介）
# posted by tiny : 5:00 下午   http://blog.csdn.net/lzcx

也用emule翻译哦
# posted by Anonymous : 5:52 下午   到底客户端ID(Client ID)和用户ID(User ID)有什么区别？有区分的必要吗？
另外文件ID(File ID)好象不是由服务器而是由客户端分配的，那么它何以保证在网络上的唯一性，或者根本没有保证唯一性的必要？
请指教:)
# posted by @ : 11:09 下午   客户端ID(Client ID)是每次都要变化的，分高ID和低ID情况，高ID就是你的IP的一一对应，而低ID可以理解为本次客户端会话在服务器上面的流水号。就是说，这个是跟每次会话相关的，跟传输相关的。通过这个ID可以在这次会话里面对你的网络地址进行定位。

而用户ID(User ID)是为了声望系统设计的，它主要是为了保存你上传下载的数据，由此够成对你的声望的评估。

文件ID是根据内容哈希计算出来的，他是唯一的，唯一性是哈希算法保证的。
# posted by tiny : 2:38 上午   高ID仅跟你的IP相关，在不同的服务器连接里面，保持不变，低ID根服务器会话相关。
但是总之，得到了你的客户端ID(Client ID)我们就可以找到你，跟你建立起一个连接。
# posted by tiny : 2:40 上午   我知道了，客户端ID(Client ID)在每次发起和服务器的会话时由服务器分配；而用户ID(User ID)是你第一次使用时由服务器分配的，该值保存在本机的config文件中，在信誉制度中发挥作用。
尽管我知道文件hash的算法很强大，但是对保证文件在网络上的唯一性仍然存有疑虑，要知道hash值的空间通常远小于输入的空间，不同的输入可能会hash成相同的输出，而不可能从hash值来唯一的确定输入值。
有没有更多关于文件hash这方面的文章还请推荐一二。
# posted by @ : 3:01 下午   文件ID是用文件内容MD4计算出来的，应该说难以保证完全唯一，但是两个文件，同时有意义，同时ID相同的可能性极低。这个方面的问题你可以看看关于MD算法的碰撞方面的文章，就是说你知道一个文件一个md4哈希结果，你想构建一个跟这个文件MD4哈希结果相同的文件，也是非常复杂的。更不要说，本身两个有意义的文件的哈希结果完全相同了。

这里不是个真实的唯一性问题，是靠几率保证的唯一性问题