eMule协议地址问题
近日相继有考生来电询问，eMule协议的情况，我们从相关单位获悉eMule协议的相关消息。
eMule协议的有关内容我们讲述了不少。这里我们主要讲解一下它的ID的有关问题。我们知道，对于下载协议来说，这个地址问题是非常关键的。所以这里我们来详细讨论一下。
客户ID
客户ID是服务器在它们连接握手时提供的一个4字节标识符。客户ID只在客户-服务器TCP 连 接的生命期中有效，尽管万一客户端有一个高ID，所有的服务器都会分配它同样的ID直到IP 地址改变。客户端ID分为低ID和高ID。当一个客户端不能接收一个输入连接时，eMule服务器将特有地分配给客户端一个低ID。拥有一个低ID会限制客户端对eMule网络的使用，和可 能导致服务器拒绝一个客户端连接。高ID的计算是以客户端IP地址为基础的，如下所述。从eMule协议观点描述了客户ID的分配和重要性。允许其它客户端自由地连接到其本机上的eMule的TCP端口(默认端口号是4662)的客户端会分配给一个高ID。有高ID的客户端没限制使用eMule网络。当服务器无法打开一个TCP连接到客户端的eMule端口时，会分配一个 低ID给该客户端。这主要发生在机器上装有防火墙的客户端，阻止了输入连接。当出现下面情况时，客户端也会接收到一个低ID：l当客户端通过NAT或代理服务器连接，l当服务器繁忙(导致服务器重连接计时器超时)高ID用下面的方法计算：假设主机IP是X.Y.Z.W，ID就是X+2^8*Y+2^16*Z+2^24*W。低ID总是小于16777216 (0x1000000)，关于它是怎样计算的，我找不到任何线索，在不同的服务中得到不同的低ID。
低ID客户端没有其他客户端可以连接到的公网IP，这样所有的交流必须通过eMule服务器完成。这增加了服务器计算能力的负担，并且导致服务器勉强接收低ID客户端。这也意味着低ID客户端不能连接到不在同一个服务器上的其他低ID客户端，因为eMule协议不支持在服务器间管道连接。为了支持低ID客户端，引入了回调机制。使用这机制，高ID客户端请求(通过eMule服务器 ) 低ID客户端连接它来交换文件。
用户ID
eMule支持信用系统来鼓励用户共享文件。用户上传越多的文件给其他客户端，它接收的信用越多，它在它们的等待队列中前进得越快。用户ID是128位(16字节)、连接随机数字创建的GUID，第6和第15字节不是随机产生的，它们的值分别是14和111。在整个客户端和指定的服务器会话中，客户ID是有效的，然而用户 ID(也叫用户哈希)是唯一的并且跨越会话时用来识别客户端(用户ID识别工作站)。用户 ID在信用系统中扮演重要角色，这为“黑客”假冒其他用户来获得他们信用赋予的优先权提供了动机。Emule提供加密方案设计来阻止欺骗和冒名顶替。这个实施是简单的应答交换，依 靠RSA公有/私有钥匙加密。
文件ID
文件ID用来惟一的标识网络中的文件和文件损坏侦测和修复。注意，eMule协议不依靠文件名来 惟一标识和编目文件，通过哈希文件内容计算出的GUID标识文件。有两种类型文件ID-一种 主要用来产生惟一的文件ID，另一种是用来损坏侦测和修复。
文件哈希
文件是用由客户端和基于文件内容计算出来的128位GUID哈希来标识的。GUID是应用MD4 算法到文件数据中计算而来。当计算文件ID时，文件被分成每段9.28MB长的部分。每部分 单独计算出一个GUID，然后所有的哈希组合成一个惟一的文件ID。当下载的客户端完成一 个文件部分下载时，它计算这部分哈希，然后和发送过来的这部分哈希对比，如果这部分发 现损坏了，客户端尝试通过逐渐替换这部分中的位(每个180kb)来修复损坏部分，直到哈 希计算OK。
根哈希
用SHA1算法来为每部分计算根哈希，基于每块180kb大小。它提供了更高等级的可靠性和可 修复性，更多信息可在eMule官方网站得到。
eMule协议扩展
尽管eMule完全兼容eDonkey，它还是实行了几种扩展，允许eMule两个客户端为用户提供另 外的功能。扩展只要集中在客户端与客户端的交流，特别是在安全和UDP使用领域上。在本 文档中，所有信息流图标明的信息，是eMule扩展部分的，用灰色表示。
软件和硬件限制
在活动用户数量的服务器配置中有两种限制-软件和硬件。硬件限制远大于软件限制。当活 动用户的数量达到软件限制时，服务器停止接收新的低ID客户连接。当用户数量达到硬件 限制时，服务器满了，不再接收任何客户端连接。
http://m.kwkids.com/gongwuyuan/11960.html
推荐访问:emulex emule怎么下载