eMule 协议中的一些基本概念

上篇博客中介绍了ed2k协议的一些背景记忆eMule的整体架构，这里主要说明几个

基本概念以便于以后的分析，后面一篇博客就会涉及具体的源代码了。

客户端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客户端连接，当用户数目达到了硬件限制，服务器不会接受任何连接。

这是eMule 的开源代码，笔者在这里把链接先给大家，可以先下载熟悉下代码结构，看下篇博客时最好已经下了源代码。

http://download.csdn.net/detail/huang_rong12/9506732