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客戶連接。當用戶數量達到硬件 限制時，服務器滿了，不再接收任何客戶端連接。