軟考網(wǎng)絡(luò)技術(shù)：關(guān)于eMule協(xié)議地址問題的討論

　　eMule協(xié)議的有關(guān)內(nèi)容我們講述了不少。這里我們主要講解一下它的ID的有關(guān)問題。我們知道，對(duì)于下載協(xié)議來說，這個(gè)地址問題是非常關(guān)鍵的。所以這里我們來詳細(xì)討論一下。

　　客戶ID

　　客戶ID是服務(wù)器在它們連接握手時(shí)提供的一個(gè)4字節(jié)標(biāo)識(shí)符�？蛻鬒D只在客戶-服務(wù)器TCP 連 接的生命期中有效，盡管萬一客戶端有一個(gè)高ID，所有的服務(wù)器都會(huì)分配它同樣的ID直到IP 地址改變�？蛻舳薎D分為低ID和高ID。當(dāng)一個(gè)客戶端不能接收一個(gè)輸入連接時(shí)，eMule服務(wù)器將特有地分配給客戶端一個(gè)低ID。擁有一個(gè)低ID會(huì)限制客戶端對(duì)eMule網(wǎng)絡(luò)的使用，和可 能導(dǎo)致服務(wù)器拒絕一個(gè)客戶端連接。高ID的計(jì)算是以客戶端IP地址為基礎(chǔ)的，如下所述。從eMule協(xié)議觀點(diǎn)描述了客戶ID的分配和重要性。允許其它客戶端自由地連接到其本機(jī)上的eMule的TCP端口(默認(rèn)端口號(hào)是4662)的客戶端會(huì)分配給一個(gè)高ID。有高ID的客戶端沒限制使用eMule網(wǎng)絡(luò)。當(dāng)服務(wù)器無法打開一個(gè)TCP連接到客戶端的eMule端口時(shí)，會(huì)分配一個(gè) 低ID給該客戶端。這主要發(fā)生在機(jī)器上裝有防火墻的客戶端，阻止了輸入連接。當(dāng)出現(xiàn)下面情況時(shí)，客戶端也會(huì)接收到一個(gè)低ID：l當(dāng)客戶端通過NAT或代理服務(wù)器連接，l當(dāng)服務(wù)器繁忙(導(dǎo)致服務(wù)器重連接計(jì)時(shí)器超時(shí))高ID用下面的方法計(jì)算：假設(shè)主機(jī)IP是X.Y.Z.W，ID就是X+2^8*Y+2^16*Z+2^24*W。低ID總是小于16777216 (0x1000000)，關(guān)于它是怎樣計(jì)算的，我找不到任何線索，在不同的服務(wù)中得到不同的低ID。

　　低ID客戶端沒有其他客戶端可以連接到的公網(wǎng)IP，這樣所有的交流必須通過eMule服務(wù)器完成。這增加了服務(wù)器計(jì)算能力的負(fù)擔(dān)，并且導(dǎo)致服務(wù)器勉強(qiáng)接收低ID客戶端。這也意味著低ID客戶端不能連接到不在同一個(gè)服務(wù)器上的其他低ID客戶端，因?yàn)閑Mule協(xié)議不支持在服務(wù)器間管道連接。為了支持低ID客戶端，引入了回調(diào)機(jī)制。使用這機(jī)制，高ID客戶端請(qǐng)求(通過eMule服務(wù)器 ) 低ID客戶端連接它來交換文件。

　　用戶ID

　　eMule支持信用系統(tǒng)來鼓勵(lì)用戶共享文件。用戶上傳越多的文件給其他客戶端，它接收的信用越多，它在它們的等待隊(duì)列中前進(jìn)得越快。用戶ID是128位(16字節(jié))、連接隨機(jī)數(shù)字創(chuàng)建的GUID，第6和第15字節(jié)不是隨機(jī)產(chǎn)生的，它們的值分別是14和111。在整個(gè)客戶端和指定的服務(wù)器會(huì)話中，客戶ID是有效的，然而用戶 ID(也叫用戶哈希)是唯一的并且跨越會(huì)話時(shí)用來識(shí)別客戶端(用戶ID識(shí)別工作站)。用戶 ID在信用系統(tǒng)中扮演重要角色，這為“黑客”假冒其他用戶來獲得他們信用賦予的優(yōu)先權(quán)提供了動(dòng)機(jī)。Emule提供加密方案設(shè)計(jì)來阻止欺騙和冒名頂替。這個(gè)實(shí)施是簡(jiǎn)單的應(yīng)答交換，依 靠RSA公有/私有鑰匙加密。

　　文件ID

　　文件ID用來惟一的標(biāo)識(shí)網(wǎng)絡(luò)中的文件和文件損壞偵測(cè)和修復(fù)。注意，eMule協(xié)議不依靠文件名來 惟一標(biāo)識(shí)和編目文件，通過哈希文件內(nèi)容計(jì)算出的GUID標(biāo)識(shí)文件。有兩種類型文件ID-一種 主要用來產(chǎn)生惟一的文件ID，另一種是用來損壞偵測(cè)和修復(fù)。

　　文件哈希

　　文件是用由客戶端和基于文件內(nèi)容計(jì)算出來的128位GUID哈希來標(biāo)識(shí)的。GUID是應(yīng)用MD4 算法到文件數(shù)據(jù)中計(jì)算而來。當(dāng)計(jì)算文件ID時(shí)，文件被分成每段9.28MB長(zhǎng)的部分。每部分 單獨(dú)計(jì)算出一個(gè)GUID，然后所有的哈希組合成一個(gè)惟一的文件ID。當(dāng)下載的客戶端完成一 個(gè)文件部分下載時(shí)，它計(jì)算這部分哈希，然后和發(fā)送過來的這部分哈希對(duì)比，如果這部分發(fā) 現(xiàn)損壞了，客戶端嘗試通過逐漸替換這部分中的位(每個(gè)180kb)來修復(fù)損壞部分，直到哈 希計(jì)算OK。

　　根哈希

　　用SHA1算法來為每部分計(jì)算根哈希，基于每塊180kb大小。它提供了更高等級(jí)的可靠性和可 修復(fù)性，更多信息可在eMule官方網(wǎng)站得到。

　　eMule協(xié)議擴(kuò)展

　　盡管eMule完全兼容eDonkey，它還是實(shí)行了幾種擴(kuò)展，允許eMule兩個(gè)客戶端為用戶提供另 外的功能。擴(kuò)展只要集中在客戶端與客戶端的交流，特別是在安全和UDP使用領(lǐng)域上。在本 文檔中，所有信息流圖標(biāo)明的信息，是eMule擴(kuò)展部分的，用灰色表示。

　　軟件和硬件限制

　　在活動(dòng)用戶數(shù)量的服務(wù)器配置中有兩種限制-軟件和硬件。硬件限制遠(yuǎn)大于軟件限制。當(dāng)活 動(dòng)用戶的數(shù)量達(dá)到軟件限制時(shí)，服務(wù)器停止接收新的低ID客戶連接。當(dāng)用戶數(shù)量達(dá)到硬件 限制時(shí)，服務(wù)器滿了，不再接收任何客戶端連接。