eMule協(xié)議專題

• eMule協(xié)議簡要分析[一]
• eMule協(xié)議簡要分析[二]
• eMule協(xié)議簡要分析[三]

客戶端到客戶端之間的連接

電騾客戶端一般是為了下載某個文件才會連接到其他的客戶端（也就是源）的。一個文件會被分為很多塊。客戶端會從多個客戶端（源）那里下載同一個文件，從不同的源下載文件的不同部分（這樣不同的部分就可以同時被下載，如果源多，下載的效率就會極高）。

當(dāng)兩個客戶端連接后，他們會交換容量信息，然后協(xié)商開始下載(或者說是上傳,這取決于視角)的時間。每個客戶端有一個下載隊列，用來保存正在等待下載的客 戶端的列表。當(dāng)電騾客戶端的下載對列為空的時候，下載請求會被馬上接受（除非這個請求者已經(jīng)被屏蔽）。如果下載對列不為空，那么新的下載請求就會放在隊列 之中。不會努力服務(wù)更多的客戶端，對每個下載客戶端至少保持不少于2.k字節(jié)/每秒。一個正在下載的客戶端的下載地位可能被一個對列等級（queue ranking）比他高的等待客戶端搶占，在下載進程中的前15分鐘正在下載的客戶端的隊列等級會增長用來避免產(chǎn)生顛簸（這里說的顛簸就是說，一個客戶端頻繁的從下載地位切換到等待狀態(tài)，然后再切換回去。這種頻繁的切換叫做顛簸，這對資源是種浪費，所以要避免。）。

當(dāng)正在下載的客戶端到達(dá)了下載隊列的頂部，提供上傳的客戶端初始化一個連接用于把它需要的文件片斷傳送給它。一個電騾客戶端可能會在多個源客戶端的等待隊 列中，在每個客戶端上注冊要求同一個文件片斷。當(dāng)這個等待客戶端實際上完成了這個文件片斷的下載，他不會通知那些源客戶端刪除它的請求，而僅僅是在它在那 些源客戶端的隊列中排到頂端的時候拒絕上傳請求而已。

電騾使用一個聲望系統(tǒng)來鼓勵上傳，為了防止假冒，電騾用RSA公鑰加密技術(shù)來保護聲望系統(tǒng)。

客戶端連接中會使用很多電驢協(xié)議（eDonkey protocol）沒有定義的消息，這些消息叫做擴展協(xié)議。擴展協(xié)議用來實現(xiàn)信用系統(tǒng)，用來進行信息交換（例如，服務(wù)器列表的更新和源的更新），通過對文 件塊進行壓縮提升發(fā)送和接收的效率。電騾客戶端連接中有限地使用UDP去周期其他客戶端的狀態(tài)。

客戶端ID

客戶端是一個4字節(jié)的標(biāo)識符，在跟服務(wù)器連接握手的時候由服務(wù)器提供的?？蛻舳薎D僅在客戶端服務(wù)器TCP連接的生命期內(nèi)可用，雖然如果客戶端是高ID （High ID），它在任何服務(wù)器分配的客戶端ID都一樣，除非IP變化了?？蛻舳薎D分為低ID（low ID）和高ID。電騾服務(wù)器通常會給不能接受連接的客戶端分配低ID。擁有低ID會限制客戶端在電騾網(wǎng)絡(luò)中的使用，甚至?xí)斐煞?wù)器拒絕連接。高ID是由 客戶端的IP地址為基礎(chǔ)算出的。這里從電騾協(xié)議的觀點來看客戶端ID的分配和表示。得到高ID的客戶端允許其他的客戶端自由地連接他的電騾TCP端口（默 認(rèn)為4662）。得到高ID的客戶端在電騾網(wǎng)絡(luò)內(nèi)不受任何限制。當(dāng)服務(wù)器不能打開一個連往客戶端的電騾端口的連接時，服務(wù)器給客戶端一個低ID。這主要是 客戶端安裝了防火墻組織外來連接造成的。以下情況下，客戶端會得到低ID：

• 當(dāng)客戶端通過NAT或者代理服務(wù)器上網(wǎng)。
• 當(dāng)服務(wù)器正在忙（造成服務(wù)器的連接計數(shù)器超時，從而認(rèn)為客戶端無法連接）。

高ID通過下面的方法計算：假設(shè)機器IP地址為X.Y.Z.W，客戶端ID應(yīng)該為 X+2⁸*Y+2¹⁶*Z+2²⁴*W（big endian高位在前）。低ID總是小于15777216(0x1000000)我不知道它是怎么計算的（協(xié)議原文如此，看來低ID的算法并不重要，只要滿足條件即可。），注意從不同的服務(wù)器得到的低ID是不一樣的。

低ID的客戶端沒有公開的IP地址供其他的客戶端連接，所以所有的通信必須通過電騾服務(wù)器。這會造成服務(wù)器的負(fù)載提升，所以服務(wù)器不愿意接受低ID的客戶端。同樣，這說明低ID的客戶端不能跟其他服務(wù)器上面的低ID客戶端連接，因為電騾不支持服務(wù)器間的橋接。

為了支持低ID客戶端電騾協(xié)議引入了回調(diào)機制。使用這種機制，一個高ID客戶段可以要求（通過服務(wù)器）低ID客戶端連接它來交換文件。

（現(xiàn)在大部分服務(wù)器不會拒絕低ID的客戶端連接，因為他們基本上都不幫助客戶端傳輸文件了。由此，低ID的客戶端之間也無法傳輸了。）

用戶ID

電騾支持聲望系統(tǒng)為了增加用戶的文件共享。一個用戶上傳給其他客戶端越多東西，它就得到越多的聲望，這樣它在他們的等待隊列中前進就會越快。用戶ID是一 個128位（16字節(jié)）GUID，通過連接隨機數(shù)而產(chǎn)生，第6和第15位不是隨機生成的，他們分別是14和111。用戶ID僅在客戶端和服務(wù)器會話中有 效，用戶ID是唯一的用來標(biāo)識客戶端。用戶ID在聲望系統(tǒng)里面起了很大的作用，攻擊者冒充其他用戶就是為了得到它們聲望對應(yīng)的權(quán)利。電騾提供了加密方案用 來用戶欺詐。實現(xiàn)方式是用RSA方法來加密方法來加密信息交換。

文件ID

文件ID用于網(wǎng)絡(luò)中文件的唯一標(biāo)識，以及文件損壞的檢測和修復(fù)。注意電騾對文件進行唯一標(biāo)識和編目不依賴于文件名，文件由其內(nèi)容哈希計算出來的全局唯一ID來標(biāo)識。文件ID有兩種，一種用來生成唯一標(biāo)識，一種用于文件損壞的檢測和修復(fù)。

文件哈希

文件是用一個128位的GUID來標(biāo)識的，這個GUID是由客戶端用文件內(nèi)容哈希計算出來的。GUID使用MD4算法計算。計算文件ID的時候文件被分成 9.28MB的大小。一個GUID是分別計算每個文件塊的哈希，然后把它們合成為一個唯一文件ID。下載客戶端完成文件塊的下載后，會計算塊的哈希和文件 上傳端發(fā)送來的文件塊哈希做比較，如果不同，就說明文件塊損壞了，客戶端將逐塊的覆蓋（一次180kb）知道哈希計算表明文件塊已經(jīng)修復(fù)為止。

根哈希

根哈希是每個文件塊用SHA1算法計算出來的，每個計算單元尺寸為180kb。它提供了更高級別的可靠性和錯誤恢復(fù)。

電騾協(xié)議拓展

雖然電騾（eMule）完全兼容電驢（eDonkey），但是它還是實現(xiàn)了一些擴展，用于增強它的功能。擴展關(guān)注于客戶端和客戶端之間的通信，特別是安全領(lǐng)域和UDP工具。

軟件和硬件限制

服務(wù)器設(shè)定包括兩種對活躍用戶數(shù)目的限制，軟件的和硬件的。硬件限制大于等于軟件限制。當(dāng)活躍用戶數(shù)目到達(dá)了軟件限制，服務(wù)器停止接受新的低ID客戶端連接，當(dāng)用戶數(shù)目達(dá)到了硬件限制，服務(wù)器不會接受任何連接。