eMule中文協議

1、eMule協議規(guī)范本文檔翻譯自:Yoram Kulbak and Danny BicksonThe eMule Protocol SpecificationAuthor:劉剛ganghust MSN:ganghust博客:部分翻譯和內容材料來源于網絡,一并向原作者表示感謝。eMule協議規(guī)范 (11簡介 (31.1目的和范圍 (31.2概述 (41.2.1客戶端到服務器的連接 (41.2.2客戶端到客戶端的連接 (51.3客戶ID (61.4用戶ID (71.5文件ID (71.5.1文件哈希 (71.5.2根哈希 (71.6eMule協議擴展 (81.7軟件和硬件限制 (82客戶端服務器的T

2、CP交流 (82.1建立連接 (82.2連接啟動時消息交換 (102.3文件搜索 (122.4回調機制 (123客戶端服務器的UDP交流 (133.1服務器保持連接和狀態(tài)信息 (133.2增強文件搜索 (153.3增強文件源搜索 (154客戶端到客戶端的TCP交流 (164.1初始的握手 (164.2安全的用戶身份認證 (174.2.1信用系統 (174.3請求文件 (184.3.1基本消息交換 (184.3.2沒找到文件的情景 (194.3.3加入上傳隊列 (194.3.4上傳對列管理 (204.3.5到達上傳隊列的頂部 (204.4數據傳輸 (214.4.1數據包 (214.4.3選擇塊下

3、載 (234.5瀏覽共享的文件和文件夾 (244.6交換片哈希集 (254.7取得文件預覽 (265客戶端到客戶端的UDP連接 (266附錄詳細的消息編碼格式 (286.1一般消息編碼要點 (286.1.1字節(jié)序 (286.1.2消息頭 (286.1.3消息標簽 (286.2客戶端服務器TCP消息 (296.2.1登錄 (296.2.2服務器消息 (306.2.3ID改變 (316.2.4文件提供 (316.2.5獲得服務器列表 (336.2.6服務器狀態(tài) (336.2.7服務器列表 (346.2.8服務器身份證明 (346.2.9搜索請求 (356.2.10搜索結果 (376.2.11獲得源

4、 (386.2.12已找到的源 (396.2.13回調請求 (396.2.14被請求回調 (406.2.15回調失敗 (406.2.16消息被拒絕 (416.3客戶端服務器UDP消息 (416.3.1獲取源 (416.3.2發(fā)現的源 (426.3.3狀態(tài)請求 (426.3.4狀態(tài)回應 (436.3.5搜索請求 (446.3.6搜索回應 (446.3.7服務器描述請求 (456.3.8服務器描述回應 (456.4客戶端到客戶端TCP消息 (456.4.1Hello (466.4.2Hello回應 (476.4.3發(fā)送文件塊 (476.4.4請求文件塊 (486.4.5下載結束 (496.4.6改

5、變客戶ID (496.4.8塊hashset請求 (516.4.9塊hashset回應 (516.4.10開始上傳請求 (526.4.11接受上傳請求 (526.4.12取消傳送 (536.4.13Out of part requests (536.4.14文件請求 (536.4.15文件請求回答 (546.4.16找不到文件 (556.4.17被請求的文件ID (556.4.18文件狀態(tài) (566.4.19Change slot (566.4.20隊列等級 (576.4.21查看共享文件 (576.4.22查看共享文件回答 (586.4.23查看共享文件夾 (586.4.24查看共享文件夾回

6、答 (596.4.25查看共享文件夾內容 (596.4.26查看共享文件夾內容回答 (606.4.27查看共享文件夾或內容拒絕 (616.5客戶端到客戶端TCP擴充消息 (616.5.1eMule信息 (616.5.2eMule信息回答 (636.5.3發(fā)送壓縮的文件塊 (636.5.4隊列等級 (646.5.5文件信息 (656.5.6源請求 (656.5.7源回答 (666.5.8安全身份認證 (676.5.9公匙 (676.5.10簽名 (686.5.11預覽請求 (696.5.12預覽回答 (696.6客戶端到客戶端UDP消息 (706.6.1重復詢問文件 (706.6.2重復詢問回應

7、 (706.6.3隊列滿 (711簡介1.1目的和范圍eMule是流行的文件共享程序,基于eDonkey協議。這份報告描述了eMule的網絡行為和解釋了理解該協議所需的基本術語。本報告也給出了eMule網絡協議的完整規(guī)范,包括一個附錄,它提供了消息格式。這份文檔的信息是基于開源的eMule客戶端。接下來的簡介目的是提供基本的背景知識,讓讀者閱讀和理解這份文檔。關于eMule的更多消息在這里找到。1.2概述eMule網絡是由上百個eMule服務器和幾百萬個eMule客戶端組成?？蛻舳吮仨氝B接到一個服務器來取得網絡服務,只要該客戶端在系統中,服務器連接保持打開狀態(tài)。這些服務器主要執(zhí)行集聚索引服務(

8、好像在Napster,相互間不聯系。每個eMule客戶端都預配置了一個服務器列表和當地文件系統的共享文件列表?？蛻舳擞脝为毜腡CP連接到一個eMule服務器登錄到網絡中,獲得想得到的文件信息和客戶端。eMule 客戶端也用幾百個TCP連接到其他客戶端進行上傳和下載文件。每個eMule客戶端對它的每個共享文件都維護著一個上傳隊列。要下載的客戶端先加入到隊列的底部,然后逐漸前進直到到達隊列的頂部并開始下載它的文件。一個客戶端可以從幾個不同的eMule客戶端中下載同一個文件的不同的文件塊。客戶端也可以上傳它還沒有完成的文件的文件塊。最后,eMule 擴展了eDonkey的能力,允許客戶端之間交換關于

9、服務器、其他客戶端和文件的信息。注意,客戶端和服務器的交流都是基于TCP的。服務器使用了一個內部數據庫,用來存儲關于客戶端和文件的信息。一個eMule服務器不存儲任何文件,它為關于文件位置的存儲信息作集聚索引。服務器的另一個功能,開始變得被抗議,是連接由于通過防火墻連接而無法接收到連接的兩個客戶端。這個連接功能增加了服務器的負載。相對于服務器和其他客戶端,eMule使用UDP來增強客戶端的能力?？蛻舳税l(fā)送和接收UDP信息的能力在日常使用中不是強制使用的,當有防火墻阻止它收發(fā)UDP信息時也能無瑕疵的運行。1.2.1客戶端到服務器的連接在開始啟動時,客戶端用TCP連接到一個eMule服務器。服務器

10、提供一個客戶ID給客戶端,在整個客戶端-服務器連接的生命周期里,它是有效的(注意,如果客戶端有一個高ID,它會從所有的服務器中接收到相同的ID,直到它的IP地址改變。在連接建立之后,客戶端發(fā)送它的共享文件列表到服務器中。服務器把這個列表存儲到它的內部數據庫中,這個數據庫通常包含了成百上千有效的文件和活動的客戶端。eMule客戶端也發(fā)送它的下載列表,包含著它想下載的文件。第二章提供了eMule客戶端和服務器TCP信息交換的詳細描述。建立連接之后,eMule服務器給客戶端發(fā)送用有它想下載的文件的其他客戶端列表(這些客戶端稱作“源”。從這點起,eMule客戶端開始與其他客戶端建立連接,如1.2.2所

11、述。 注意,在整個客戶端會話期間,客戶/服務TCP連接一直保持連接狀態(tài)。初次握手后主要是用戶活動激發(fā)事務:有時,客戶端發(fā)送文件搜索需求,由搜索結果回應,一個搜索事務一般在對源中指定文件查詢之后,用源(IP和端口列表來回答這個查詢,查詢者可以從這列表中下載文件。客戶端和它沒有連接的服務器的交流是用UDP。UDP信息的目的是增強文件搜索,增強源搜索,最后保持連接狀態(tài)(確?？蛻舳朔掌髁斜碇械膃Mule服務器有效。在第三章中可找到更多的關于客戶-服務UDP信息交換的細節(jié)。1.2.2客戶端到客戶端的連接一個eMule客戶端連接到另一個eMuel客戶端(源是為了下載文件。一個文件分成很多部分,進一步的碎

12、片?？蛻舳丝梢詮膸讉€(不同的客戶端中下載同一個文件來分別獲得不同的文件碎片。當兩個客戶端連接時,它們交換容量信息,然后協商一個下載(或者上傳,根據看法的開始。每個客戶端有一個下載列表,記住一列等待下載文件的客戶端。當eMule客戶端下載隊列空的時候,一個下載請求很可能會導致一個下載開始(除非,比如這個請求者被禁止。當下載隊列不是空的時候,就會將這個請求的客戶端加入到隊列中。在給定的時間內,不能為幾個以上客戶端各自提供最小帶寬2.4k/s。一個下載的客戶端可能被一個比它較高隊列等級的等待的客戶端搶占,在下載會話的最初15分鐘內,正在下載的eMule客戶端的隊列等級會增加直到能防止被擊潰。當下載的

13、客戶端到達下載隊列的頭部時,上傳的客戶端初始化一個連接來給它發(fā)送需要的文件塊。eMule客戶端可以在幾個其他客戶端的等待隊列中,都注冊下載相同文件的塊。當一個等待的客戶端實際上完成了(從它們中的一個下載文件塊,它不會通知其他客戶端在其隊列中刪除它,當它到達它們的隊列頭時只是簡單的拒絕它們的上傳意圖。EMuley用一個信用系統來鼓勵上傳,為了防止假冒用RSA公匙密碼系統來保護信用系統?？蛻舳诉B接可能用一套eDonkey協議沒有定義的信息,這信息稱作擴展協議。擴展協議用來實施信用系統,一般信息的交換(像服務器和源列表的更新,通過收發(fā)壓縮的文件塊來改善性能。當EMule客戶端在等待開始下載文件時,有

14、限地用UDP周期性檢查在它對等的客戶端上的上傳隊列客戶端狀態(tài)。1.3客戶ID客戶ID是服務器在它們連接握手時提供的一個4字節(jié)標識符。客戶ID只在客戶-服務器TCP連接的生命期中有效,盡管萬一客戶端有一個高ID,所有的服務器都會分配它同樣的ID直到IP 地址改變?？蛻舳薎D分為低ID和高ID。當一個客戶端不能接收一個輸入連接時,eMule服務器將特有地分配給客戶端一個低ID。擁有一個低ID會限制客戶端對eMule網絡的使用,和可能導致服務器拒絕一個客戶端連接。高ID的計算是以客戶端IP地址為基礎的,如下所述。本節(jié)從eMule協議觀點描述了客戶ID的分配和重要性。允許其它客戶端自由地連接到其本機上

15、的eMule的TCP端口(默認端口號是4662的客戶端會分配給一個高ID。有高ID的客戶端沒限制使用eMule網絡。當服務器無法打開一個TCP連接到客戶端的eMule端口時,會分配一個低ID給該客戶端。這主要發(fā)生在機器上裝有防火墻的客戶端,阻止了輸入連接。當出現下面情況時,客戶端也會接收到一個低ID:l當客戶端通過NAT或代理服務器連接l當服務器繁忙(導致服務器重連接計時器超時高ID用下面的方法計算:假設主機IP是X.Y.Z.W,ID就是X+28*Y+216*Z+224*W。低ID 總是小于16777216(0x1000000,關于它是怎樣計算的,我找不到任何線索,在不同的服務器中得到不同的低

16、ID。低ID客戶端沒有其他客戶端可以連接到的公網IP,這樣所有的交流必須通過eMule服務器完成。這增加了服務器計算能力的負擔,并且導致服務器勉強接收低ID客戶端。這也意味著低ID客戶端不能連接到不在同一個服務器上的其他低ID客戶端,因為eMule不支持在服務器間管道連接。為了支持低ID客戶端,引入了回調機制。使用這機制,高ID客戶端請求(通過eMule服務器低ID客戶端連接它來交換文件。1.4用戶IDeMule支持信用系統來鼓勵用戶共享文件。用戶上傳越多的文件給其他客戶端,它接收的信用越多,它在它們的等待隊列中前進得越快。用戶ID是128位(16字節(jié)、連接隨機數字創(chuàng)建的GUID,第6和第15

17、字節(jié)不是隨機產生的,它們的值分別是14和111。在整個客戶端和指定的服務器會話中,客戶ID是有效的,然而用戶ID(也叫用戶哈希是唯一的并且跨越會話時用來識別客戶端(用戶ID識別工作站。用戶ID在信用系統中扮演重要角色,這為“黑客”假冒其他用戶來獲得他們信用賦予的優(yōu)先權提供了動機。Emule提供加密方案設計來阻止欺騙和冒名頂替。這個實施是簡單的應答交換,依靠RSA公有/私有鑰匙加密。1.5文件ID文件ID用來惟一的標識網絡中的文件和文件損壞偵測和修復。注意,eMule不依靠文件名來惟一標識和編目文件,通過哈希文件內容計算出的GUID標識文件。有兩種類型文件ID-一種主要用來產生惟一的文件ID,另

18、一種是用來損壞偵測和修復。1.5.1文件哈希文件是用由客戶端和基于文件內容計算出來的128位GUID哈希來標識的。GUID是應用MD4算法到文件數據中計算而來。當計算文件ID時,文件被分成每段9.28MB長的部分。每部分單獨計算出一個GUID,然后所有的哈希組合成一個惟一的文件ID。當下載的客戶端完成一個文件部分下載時,它計算這部分哈希,然后和發(fā)送過來的這部分哈希對比,如果這部分發(fā)現損壞了,客戶端嘗試通過逐漸替換這部分中的位(每個180kb來修復損壞部分,直到哈希計算OK。1.5.2根哈希用SHA1算法來為每部分計算根哈希,基于每塊180kb大小。它提供了更高等級的可靠性和可修復性,更多信息可

19、在eMule官方網站得到。1.6eMule協議擴展盡管eMule完全兼容eDonkey,它還是實行了幾種擴展,允許eMule兩個客戶端為用戶提供另外的功能。擴展只要集中在客戶端與客戶端的交流,特別是在安全和UDP使用領域上。在本文檔中,所有信息流圖標明的信息,是eMule擴展部分的,用灰色表示。1.7軟件和硬件限制在活動用戶數量的服務器配置中有兩種限制-軟件和硬件。硬件限制遠大于軟件限制。當活動用戶的數量達到軟件限制時,服務器停止接收新的低ID客戶連接。當用戶數量達到硬件限制時,服務器滿了,不再接收任何客戶端連接。2客戶端服務器的TCP交流每個客戶端用TCP精確地連接到一個服務器。服務器分配給

20、客戶端一個ID,在與服務器其余的會話中標識該客戶端(高ID客戶端總是根據它的IP地址分配。eMule GUI客戶端需要建立一個服務器連接來用于操作?？蛻舳瞬荒芡瑫r與幾個服務器連接,也不能在沒有用戶干涉的情況下動態(tài)更換服務器。2.1建立連接在準備建立與服務器的連接時,客戶端會嘗試并行地連接到幾個服務器,根據成功的登陸順序放棄其他的。有下面幾個可能的連接建立個案:1、高ID連接-服務器分配一個高ID給正在連接的客戶端2、低ID連接-服務器分配一個低ID給正在連接的客戶端3、拒絕會話-服務器拒絕客戶端當然,也有不重要的個案-服務器崩潰或者不可連接。 圖2.1高ID連接的信息順序圖2.1描述了導致高I

21、D連接的信息順序。在這種情況下,客戶端建立一個TCP連接到服務器,然后發(fā)送一個登錄信息到服務器。服務器用另一個TCP連接到客戶端,執(zhí)行一個客戶端-客戶端的握手來保證連接的客戶端有能力接收來自其他eMule客戶端的連接。在完成客戶端握手后,服務器關閉第二個連接,通過發(fā)送ID更改信息來完成客戶端-服務器的握手。你可能注意到eMule信息消息是灰色的。這是因為這個消息是eMule協議擴展的一個部分(1.6節(jié) 圖2.2描述了導致低ID連接的信息順序圖2.2描述了導致低ID連接的信息順序。在這種情況下,服務器不能連接到發(fā)送請求的客戶端,分配一個低ID給客戶端。服務器消息一般包含警告信息,就像“警告服務器

22、細節(jié)-你是低ID。請察看你的網絡配置和/或你的設置”低ID和高ID握手都是通過隨著ID更改消息完成的,這個ID更改消息分配客戶端一個客戶端ID,用在與服務器的下一個會話。 圖2.3描述了被拒絕的會話順序。因為客戶端擁有一個低ID或者到達了服務器硬件的容量限制,服務器就可能拒絕會話。服務器消息會包含一個短字符串描述拒絕的理由。2.2連接啟動時消息交換在建立成功的連接后,客戶端和服務器交換幾個設置消息。這些消息的目的是根據雙方狀態(tài)來雙方更新?？蛻舳送ㄟ^提供它的共享文件列表(見6.2.4節(jié)給服務器來開始,然后要求更新它的服務器列表。服務器發(fā)送它的狀態(tài)和版本(6.2.6節(jié)和6.2.2節(jié),然后發(fā)送它所知

23、的eMule 服務器列表和提供更多一些自我認定的細節(jié)。最后客戶端要求源(可以訪問下載它下載列表中的文件的其它客戶端和服務器回應一系列的消息,客戶端下載列表中的每個文件,直到下載所有的源列表到客戶端。圖2.4圖解了這個順序。 2.3文件搜索圖2.5描述了文件搜索順序文件搜索是由用戶發(fā)起的。這個操作簡單,一個搜索要求(見6.2.9節(jié)發(fā)送到服務器,然后服務器用一個搜索結果回應。當有很多結果時,搜索結果消息就會被壓縮。接著,用戶選擇下載一個或多個文件,客戶端就要求源為選中的文件和服務器返回每個要求文件的源隊列(見6.2.12節(jié)。就在回應發(fā)現的源之前,可以發(fā)送一個可選的服務器狀態(tài)消息。這個狀態(tài)消息(6.

24、2.6節(jié)包含關于當前用戶數量和服務器支持的文件等信息。重要注意的是,UDP消息有個補充順序事件,用來增強客戶端為它搜索的文件定位源的能力,詳細的細節(jié)見第3章。在檢驗出源是新的之后,eMule客戶端開始嘗試連接和把它們加入到它的源列表。源聯系的順序就是eMule客戶端接收到它們的順序。圖2.5描述了文件搜索順序。eMule客戶端根據源加入到它的列表中的順序來連接源。沒有優(yōu)先機制來決定連接那個源。當可以要求同一個源來下載客戶端下載列表中的幾個文件時,有一種復雜的機制來解決這個局面(注意,載客戶端之間eMule只允許一個單獨的上傳連接。選擇算法是基于用戶優(yōu)先規(guī)則,當沒有指定優(yōu)先時,默認是字母順序。關

25、于處理可以上傳多于一個文件的源的詳細描述,可以在網站中找到。2.4回調機制回調機制是設計來克服低ID客戶端不能接收輸入的連接的,這樣客戶端之間就能共享它們的文件。機制很簡單:假如客戶端A和B都連接到同一個eMule服務器,A需要的文件在B上,但B是低ID的,A可以向服務器發(fā)送一個回調請求(見6.2.13節(jié),請求服務器叫B呼叫回它。服務器,已經有一個與B的打開的TCP連接,發(fā)送一個回調請求消息(見6.2.14節(jié)到B,為它提供A的IP和端口。B就能連接到A并發(fā)送文件,沒有給服務器增加負擔。很明顯,只有高ID客戶端可以要求低ID客戶端回調(低ID客戶端是沒有接收輸入連接的能力的。圖2.6圖解了回調消

26、息交換。 也有允許兩個低ID客戶端交換文件的能力,通過它們的服務器連接,用服務器接力。大部分服務器不再提供這個選項,因為它招致服務器的負擔。3客戶端服務器的UDP交流eMule客戶端和服務器用不可靠的UDP服務來保持連接和增強搜索。eMule客戶端產生UDP 包的總量可以達到它發(fā)送包的總數目的5%-這些根據客戶端服務器列表中服務器的數目,客戶端下載列表中每個文件的源數目和用戶執(zhí)行的搜索數目而定。UDP包通過計時器觸發(fā),計時器每100ms過期,有一個單獨的線程負責發(fā)送UDP輸送結果,以每秒10個UDP的最大速率。3.1服務器保持連接和狀態(tài)信息客戶端周期性驗證它服務器列表中的服務器狀態(tài)。驗證是通過

27、發(fā)送UDP服務器狀態(tài)請求(見6.3.3節(jié)和UDP服務器描述請求(見6.3.7節(jié)消息完成的。這里描述的簡單保持連接計劃每小時產生不超過幾打包。任何情況下,包的最大速率是每秒0.2個包(或每5秒一個包。當檢查服務器的狀態(tài)時,客戶端會首先發(fā)送一個服務器狀態(tài)請求消息,接著,每兩次試圖(發(fā)送一個服務器狀態(tài)請求中就發(fā)送一次服務器描述請求,見圖3.1。 客戶端發(fā)送的服務器狀態(tài)請求中包括一個隨機數字,在服務器回應中返回。在服務器返回的數字與客戶端發(fā)送的要求中數字不同的情況下,回應的信息就會被丟棄。每次發(fā)送到服務器的包是狀態(tài)請求,客戶端就移動嘗試計數器。任何來自服務器的消息(包括搜索結果都重置嘗試計數器。當嘗試

28、計數器達到一個可配置的限制時,服務器就認為是死機,從客戶端的服務器列表中刪除。服務器回應包括幾個數據項:服務器狀態(tài)回應(見6.3.4包括服務器中當前用戶數目和文件數目,也包括服務器的軟件和硬件限制(見1.7節(jié)。服務器描述回應(見6.3.8節(jié)包括服務器名稱和一個短的描述字符串。圖3.2演示了客戶端和活動服務器中滿連接序列的消息流。 3.2增強文件搜索eMule客戶端可以設置用UDP來增強它的文件搜索。UDP搜索結果格式幾乎與?節(jié)描述的TCP搜索請求一樣。服務器只在有了搜索結果才回應。UDP搜索結果消息有兩種不同的opcdes,我也無法說清它們之間的不同。UDP搜索包發(fā)送到客戶端服務器列表中的服務

29、器上。更多信息見6.3.5節(jié)和6.3.6節(jié)。3.3增強文件源搜索當客戶端下載列表中的特定文件的源數目小于配置限制(100時,客戶端就周期性地發(fā)送獲取源的UDP包到它的服務器列表中的服務器中為該文件尋找更多的源?？赡苊棵氚l(fā)送一個包,使得源搜索在客戶端產生的UDP輸送中成為可觀的部分。消息的格式(6.3.1節(jié)描述非常相似它的TCP計數器部分。注意,與TCP源搜索相反,UDP源搜索在文件搜索中減弱,對于指定的文件,只是依靠客戶端擁有的源數目。4客戶端到客戶端的TCP交流在eMule客戶端注冊到服務器和向服務器查詢文件和源之后,為了下載文件,eMule客戶端需要聯系其它客戶端。為每對文件,客戶端創(chuàng)建一

30、個專用的TCP連接。當特定的周期內(默認40秒沒有任何socket活動或者對方已經關閉了這個連接,那么這個連接就會關閉。為了提供合理的下載速率,直到可能提供給它(和所有其它下載的客戶端至少最小允許速率(當前的硬編碼常量設置為2.4k/s,eMule才允許客戶端開始下載文件。4.1初始的握手初始的握手是對稱的-雙方都相互發(fā)送相同的信息給對方。客戶端交換雙方的信息,信息包括身份認證、版本和容量等。參與的有兩種類型消息-Hello消息(6.4.1節(jié)和eMule信息消息(6.5.1節(jié),第一種是eDonkey的一部分,兼容eDonkey客戶端,第二種是eMule獨有的擴展客戶端協議的一部分。圖4.1圖解

31、了兩個eMule客戶端之間的握手。在擴展信息中包含的有UDP消息交換、安全身份證明和源交換能力。 4.2安全的用戶身份認證1.4節(jié)簡單解釋了關于用戶ID和用戶假冒其它用戶的動機。安全用戶認證是eMule擴展的一部分。如果客戶端支持安全認證,就會在初始化握手之后立即執(zhí)行。安全認證的目的是防止用戶冒名頂替。當實施安全認證時,執(zhí)行以下步驟:1.在初始化握手中,B客戶端指明它支持和希望使用安全認證。2.通過發(fā)送安全認證消息(見6.5.8來回應,指明A是否需要B的公匙,也包含了B發(fā)出的4字節(jié)的詢問。3.如果A指明它需要B的公匙,B就將它的公匙發(fā)送給A(6.5.9節(jié)。4.B發(fā)送一個簽名消息(6.5.10節(jié)

32、,簽名消息是用發(fā)送過來的詢問和額外的雙字節(jié)創(chuàng)建的,雙字節(jié)要么是A的IP地址如果B是低ID,要么是B的ID如果它有高ID。圖4.2演示了這個順序。 4.2.1信用系統本節(jié)簡要地描述了客戶端的信用系統。信用系統的目的是鼓勵用戶共享文件。當客戶端上傳文件給它的對方,下載的客戶端就根據數據傳輸的數量來更新它的信用。注意,信用系統不是全局的-傳輸的信用被下載的客戶端局部保存,只有當上傳的客戶端(獲得信用的那個要求從這個特定的客戶端下載時,信用才會被考慮。信用是用下面最小值計算的:1.上傳的總量*2/下載的總量當下載的總量是零時,這個表達式估值是102.上傳的總量+2的和開方當上傳的總量小于1MB,這個表

33、達式估值是1上傳/下載數量是以M為單位計算。任何情況下,信用不會高過10或者低于1。4.3請求文件正如已經提到的一樣,每對客戶端,文件都創(chuàng)建一個獨立的連接。在連接建立之后,客戶端立即發(fā)送幾個關于它希望下載的文件的請求消息。4.3節(jié)描述了一個典型的、成功的情景。 4.3.1基本消息交換基本消息交換是由四個消息構成:A發(fā)送一個文件請求消息,立即跟著的是請求文件ID消息(6.4.17節(jié)。B用文件請求回答回應文件請求,用文件狀態(tài)(6.4.18節(jié)來回應請求文件的ID 消息。我找不到任何理由來把這些發(fā)送過來的消息中的信息分成四個消息,它可以容易地用兩個消息(請求和回應來處理。擴展協議增加兩個消息到這個順序

34、中,源請求消息(6.5.6節(jié)和源回應消息(6.5.7節(jié)。用這個擴展來傳遞B的源(假定B當前下載著文件到A中。詳細闡述就是,在它能發(fā)送文件塊給其它客戶端之前B完成下載一個文件是沒有任何要求的,B可以發(fā)送任何它已經完成下載的文件塊,甚至當它只是用文件的一小塊。4.3.2沒找到文件的情景當A向B請求一個文件,但是B的共享文件列表中沒有這個文件。B忽略這個文件請求回應消息,在請求文件ID消息之后立即發(fā)送一個沒有文件消息(6.4.16節(jié),如圖4.4所演示。 4.3.3加入上傳隊列當B有被請求的文件但是它上傳隊列不為空,意味著有正在下載文件的客戶端,也可能有客戶端在上傳列表中,在這種情況下,A和B執(zhí)行滿握

35、手,如圖4.3所述,但是當A請求B開始下載文件時,B把A加入到它的上傳隊列中,回應一個隊列等級消息,這個消息包含A在B地上傳隊列中的位置。圖4.5演示了這個順序。 4.3.4上傳對列管理對每個上傳的文件,客戶端維護著一個上傳優(yōu)先級隊列。隊列中的每個客戶端的優(yōu)先級是以客戶端在隊列中的時間和優(yōu)先級修正為基礎計算的。位于隊列頭部的客戶端有一個最高級別的分數。分數是用以下的方程式計算的:分數=(等級*隊列中的秒數/100或者無窮大,如果下載的客戶端被定義為朋友。初始化的等級值是100,除開禁止的用戶是0等級(這樣阻止達到隊列的前面外。等級可以被下載客戶端的信用(范圍1-10或上傳文件優(yōu)先級(0.2-1

36、.8修改,上傳文件優(yōu)先級是由上傳客戶端設置的。當一個客戶端的分數比其它的客戶端高時,它就開始下載文件?？蛻舳丝梢岳^續(xù)下載文件直到產生以下任一個條件:1.用戶關閉了上傳客戶端。2.下載的客戶端得到了它所需文件的所有部分。3.下載的客戶端給其它擁有比它更高優(yōu)先級的客戶端搶占。為了允許一個剛剛開始的客戶端在它被搶占之前可以得到幾M的數據,eMule在客戶端下載的前15鐘內增加初始等級到200。4.3.5到達上傳隊列的頂部當A到達B上傳隊列的頂部時,B連接A,執(zhí)行初始握手,然后發(fā)送一個接收上傳請求消息(6.4.11節(jié)。A現在可以選擇要么發(fā)送請求塊消息來繼續(xù)下載文件,要么發(fā)送取消傳輸消息來取消(如果它已

37、經從別的源得到了這一塊。圖4.6演示了這些選擇。 4.4數據傳輸4.4.1數據包發(fā)送和接收文件塊是eMule網絡活動的主要部分。用FTP解釋eMule可以推論出,當所有其它eMule可以控制,發(fā)送的文件塊適合數據傳輸。發(fā)送的文件塊大小可以是在5000到15000位(也根據壓縮范圍內。為了避免出錯,文件塊消息在碎片中發(fā)送,每碎片在一個獨立的TCP 包中。在eMule0.30e版中,最大的碎片大小是1300位(注意,這個數字只與TCP有效負載有關。換句話說,當每個控制消息在單獨的TCP包中發(fā)送,有時和其它消息共享,數據消息被分成幾個TCP包。第一個包包含發(fā)送文件塊消息頭部(6.4.3節(jié)。剩下的包值

38、包含數據。當被分成1300,如果發(fā)送塊的大小有剩余,和第一個包(這個包帶有頭部一起發(fā)送。圖4.7演示了文件塊消息。 4.4.2數據傳輸順序在文件請求回應之后立即開始塊傳輸順序。下載客戶端A發(fā)送一個開始上傳請求(6.4.10節(jié),然后一個接收上傳請求消息(6.4.11節(jié)回應這個請求。A在這之后立即開始請求文件塊(6.4.4節(jié),B通過發(fā)送被請求塊(6.4.3節(jié)來回應。注意,單獨的文件塊請求可能請求可達3塊之多,所以每個文件塊請求可能被可達3個發(fā)送的塊順序回應。當兩個客戶端都支持擴展的客戶端協議,文件塊可能壓縮發(fā)送。擴展協議也支持可選的文件信息消息(6.5.5節(jié),該消息就在接收上傳請求消息之前發(fā)送。圖

39、4.8演示了塊傳輸消息順序。 4.4.3選擇塊下載為了最大化整個網絡的吞吐量和共享,eMule仔細挑選選擇塊的下載順序。每個文件被分成9.28M的塊,每部分分成180KB的片。塊下載的順序是由發(fā)送請求文件塊消息(6.4.4節(jié)的下載客戶端決定。下載客戶端可以在任何給定時刻從各個源中下載一個單獨的文件塊,所有從相同源中請求的片都在同一個塊中。下面的原理(以這個順序應用于下載塊等級:1.(可獲得的大片的頻率,盡可能快的下載非常稀少的大片來形成一個新的源。2.用來預覽的塊(最初+最后的大片,預覽或檢查文件(比如,電影、mp33.請求狀態(tài)(過程中下載,嘗試向每個源詢問其它的大片。在所有源之間擴散請求。4

40、.完成(未到某種程度的完成,在開始下載另一個時應該完成獲得部分的大片頻率標準定義了三個區(qū)域:非常稀少、稀少和一般。在每個區(qū)域里,標準有特定的權重,用來計算塊等級。較低等級的塊先下載。下面的列表根據上面的原理指定文件等級范圍:l0-9999-不請求和請求非常稀少的塊l10000-19999-不請求稀少和預覽塊l20000-29999-不請求大部分完成的一般的塊l30000-39999-請求的稀少和預覽的塊l40000-49999-請求的沒有完成的一般的塊這個算法通常選擇第一個最稀少的塊。然而,部分完成的塊,接近完成的,也可能被選中。對于一般的塊,在不同的源之間擴散下載。4.5瀏覽共享的文件和文件

41、夾有兩個消息流程來處理每對客戶端之間的共享文件和文件夾的瀏覽。第一個是瀏覽共享文件消息(6.4.21節(jié),該消息在初始握手后立即發(fā)送。通常由一個瀏覽共享文件回應消息(6.4.22來回應這個消息。當回應的客戶端想隱藏它的共享文件列表時,回應就包含零個文件(而不是發(fā)送一個指示訪問拒絕的消息。圖4.9演示了這個消息順序。 第二個消息流程隨著一個瀏覽共享的文件夾列(6.4.23節(jié)表請求開始,通過共享文件夾列表來回應這個消息,然后,對于回應中的每個文件夾,發(fā)送瀏覽共享文件夾內容的消息。當消息到達時,回應的每個消息帶有內容列表。圖4.10演示了這個消息順序。 如果接收的客戶端設置了阻塞共享文件/文件夾請求,

42、它用請求共享拒絕消息回應,如圖4.11所示。 4.6交換片哈希集為了取得片的哈希,發(fā)送一個哈希集請求,這個請求通過一個包含文件中每塊的哈希集回應來回答。圖4.12演示了這個。 4.7取得文件預覽客戶端可以請求對方來獲得下載文件的預覽。預覽是種獨立的、隨著文件類型不同而不同的應用。eMule0.30e只支持圖像預覽。這個消息交換如圖4.13描述,只包含兩種消息:預覽請求(6.5.11節(jié)和預覽回應(6.5.12節(jié)。 5客戶端到客戶端的UDP連接eMule客戶端周期性地用UDP協議發(fā)送消息。在eMule0.30e中,使用的UDP消息只是詢問客戶端在對方下載隊列中的位置。這個簡單的請求-應答方案是隨著

43、重復要求文件消息(6.6.1節(jié)而開始的。對于這個請求,有三種可能的回應,如圖5.1所示。1.隊列等級-客戶端在發(fā)送者隊列中的等級2.隊列滿-發(fā)送者隊列已滿3.找不到文件-發(fā)送者在它的列表中沒有被請求的文件重復要求文件消息大約每20分鐘的間歇發(fā)送到每個客戶端,這些客戶端把發(fā)送者加入到它的下載隊列中。 6附錄詳細的消息編碼格式6.1一般消息編碼要點本章描述了在TCP/UDP有效負載中消息編碼的一般方法。6.1.1字節(jié)序所有消息都是用little-endian編碼,而不是big-endian,big-endian是約定的網絡字節(jié)序。這個很容易解釋,事實上客戶端/服務器都是基于微軟窗口的應用程式,運行

44、在Intel處理器上。6.1.2消息頭所有的消息有一個6字節(jié)的頭,頭有著下面的結構:1.協議-一個字節(jié),協議ID-0xE3是eDonkey,0xC5是eMule2.大小-4字節(jié)消息大小-消息大小,以字節(jié)為單位,不包含頭,例如,如果消息不包含任何有效負載,如6.4.11節(jié)中,則消息長度是零。3.類型-一個字節(jié),類型-獨一無二的消息ID6.1.3消息標簽標簽類似TLV(類型,長度,值結構,用來增加可選的數據到eMule消息中。有幾種類型的標簽,本章中列出了所有的標簽。當提及到協議消息里特定的標簽時,只有標簽類型是指定的,讀者應該把本章作為一個參考來確定協議消息的準確的結構。每個標簽擁有4個域,在消

45、息中它們并不都是連續(xù)的:1.類型-1字節(jié)整型2.名稱-可以是以下之一l可變長度字符串l1字節(jié)整型3.值-可以是以下之一l4字節(jié)整型l4字節(jié)浮點數l可變長度字符串4.專用的-1字節(jié)整型,專用的標簽指定者帶有整型值的標簽叫做整型標簽,類似的我們有字符串標簽和浮點數標簽。字符串標簽的類型值是2,整型標簽的類型值是3和浮點數標簽的類型值是4。當標簽被編碼來發(fā)送時,是按照上面的次序編碼,例如,類型,然后名稱,最后是值。類型被編碼成一個字節(jié)。名稱被編碼成2個字節(jié)長度值,可以是字符串名稱和整型名稱。例如,整型名稱0x15編碼順序是0x010x000x15。固定的值域(好像整型和浮點數字正如它們這樣寫入,字符

46、串值就以相同的長度值方式編碼。注意:標簽給出的名稱是沒有特定的協議意義的,只是易于在以后的協議消息描述中引用。6.2客戶端服務器TCP消息本章描述了在服務器和客戶端之間用TCP傳送的消息。6.2.1登錄在TCP連接建立之后,客戶端發(fā)送到服務器的第一個消息是登錄消息。這個消息的長度可變的,因為它是依據用戶的配置的,例如用戶昵稱。為什么客戶端的TCP端口出現在TCP的頭部,還是再發(fā)送(2次,這不是很清楚。名稱字節(jié)大小默認值注釋Protocol(協議10xE3Size(大小4消息大小是以字節(jié)為單位,不包括頭部和大小的域Type(類型10x01OP_LOGINREQUEST操作碼的值User Hash

47、(用戶哈希16關于用戶哈希的細節(jié)可以在1.4節(jié)找到Client ID (用戶ID40在第一次連接中發(fā)送的用戶ID通常是零。關于用戶ID的細節(jié)可以在1.3節(jié)找到TCP Port24662客戶端使用的TCP端口,可配置的Tag Count44消息中跟隨的標簽數目Name Tag可變的NA用戶的昵稱(在軟件中可配置。這個標簽是字符串標簽,標簽名稱是值為0x1的整數Version Tag80x3C客戶端支持的eDonkey版本。這個標簽是整型標簽,標簽名稱是值為0x11的整數Port Tag84662客戶端使用的TCP端口。這個標簽是整型標簽,標簽名稱是值為0x0F的整數Flags Tag80x01這

48、個標簽是整型標簽,標簽名稱是值為0x20的整數6.2.2服務器消息服務器消息是可變長度的消息,在不同的場合中,第一次客戶端登錄請求之后立即由服務器發(fā)送到客戶端。一個服務器消息可以包含幾個的消息,用換行操作符(r,n或兩者分隔。用”server version”,”warning”,”error”和”emDynIP:”開頭的消息對客戶端有特定的意義。其它的消息簡單地顯示給用戶。名稱字節(jié)大小默認值注釋Protocol10xE3Size4消息大小是以字節(jié)為單位,不包括頭部和大小的域Type10x38OP_SERVERMESSAGE操作碼的值Size2NA消息剩余字節(jié)的數目,不包括目前描述的域Mess

49、age可變的NA一列服務器消息,用換行分隔特別的消息1、版本通常在成功的連接我手中發(fā)送2、錯誤3、警告通常在服務器拒絕連接或者客戶端是低ID 時發(fā)送4、emDynIP 6.2.3ID 改變服務器發(fā)送ID 改變的消息,作為對登錄請求消息的回應和表示服務器已經接收客戶端的連接。消息大小為14或10字節(jié),依賴于發(fā)送的可選TCP 連接位圖(TCP connection bitmap 。6.2.4文件提供該消息被客戶端用來描述可獲得的當地文件,讓其它客戶端下載。如果客戶端有文件提供,文件提供消息立即在連接建立之后發(fā)送。當客戶端共享文件列表發(fā)生改變時,該消息也會發(fā)送。該消息的另一用法是周期地發(fā)送到服務器,

50、保持活動狀態(tài)。如果服務器支持壓縮,文件提供(消息會被壓縮。當用作保持活動狀態(tài)(沒有文件壓縮和消息大小很小時,該消息名稱字節(jié)大小默認值注釋Protocol10xE3Size4消息大小是以字節(jié)為單位,不包括頭部和大小的域Type10x40OP_IDCHANGE 操作碼的值Client ID4NA 關于客戶端ID 的描述可在1.3節(jié)找到TCPconnectionbitmap 40x000000001當前只有1位(LSB 有意義,設置它為1來標識服務器支持壓縮不被壓縮。單個文件條目格式下面的表格描述了單個文件條目。在一個文件提供消息中可以有一系列的多個條目。名稱字節(jié)大小默認值注釋Protocol 10

51、xE3Size 4消息大小是以字節(jié)為單位,不包括頭部和大小的域Type 10x15OP_OFFERFILES 操作碼的值File Count 4NA 里面描述的文件數目。無論如何不超過200。服務器也可以為這個數目設置一個相對較低的限制Files 可變的NA 可選的文件列表,單個條目格式如下所述名稱字節(jié)大小默認值注釋Hash Code 16NA 執(zhí)行在文件內容上的哈希結果(TBD 規(guī)范。這個哈希用來唯一的標識文件,忽略不同客戶端之間的名稱差別Client ID 4NA 客戶端ID ,如果客戶端有高ID ,否則為零Client Port 20x15客戶端TCP 端口號,如果客戶端是低ID 則為零

52、Tag Count 4NA 該域以下的標簽的數目FileName Tag 可變的NA (必選的文件名稱。這個標簽是字符串標簽,標簽名稱是值為0x1的整數File Size Tag 8NA (必選的文件大小,字節(jié)單位。這個標簽是整型標簽,標簽名稱是值為0x2的整數File Type Ta 可變的NA (可選的文件類型。以下之一:“Audio ”、“Video ”、“Image ”、“Pro ”或“Doc ”。6.2.5獲得服務器列表該消息在成功握手完成之后立即從客戶端發(fā)送到服務器。當客戶端被配置通過請求它當前服務器來擴大它的eMule 服務器列表時,發(fā)送該消息。消息大小是6字節(jié)。6.2.6服務器

53、狀態(tài)從服務器發(fā)送到客戶端。該消息包含關于服務器上用戶和文件的當前數目的信息。消息中的信息不但存儲在客戶端也表現出給用戶看。該消息大小14字節(jié)。g 這個標簽是字符串標簽,標簽名稱是值為0x3的整數File Format Tag可變的NA (可選的文件擴展名,小寫。例如,“zip ”、“exe ”。這個標簽是字符串標簽,標簽名稱是值為0x4的整數MediaLength Tag可變的NA (可選的如果文件是mp3,歌曲播放時間。該標簽是字符串標簽,標簽名稱是“l(fā)ength ”的字符串MediaBitrate TagTBD NA (可選的如果文件是mp3,編碼位率。該標簽是整型標簽,標簽名稱是“bit

54、rate ”字符串MediaCodec Tag可變的NA (可選的,從不發(fā)送如果文件是影片,編碼解碼器。該標簽是字符串標簽,標簽名稱是“codec ”的字符串名稱字節(jié)大小默認值注釋Protocol10xE3Size4消息大小是以字節(jié)為單位,不包括頭部和大小的域Type10x14OP_SERVERSTATUS 操作碼的值名稱字節(jié)大小默認值注釋Protocol 10xE36.2.7服務器列表從服務器發(fā)送到客戶端。該消息包含關于用另外的eMule 服務器來擴展客戶端服務器列表的信息。消息大小可變的(根據發(fā)送的服務器數目。6.2.8服務器身份證明從服務器發(fā)送到客戶端。包含服務器哈希(TBD ,服務器I

55、P 地址和TCP 端口(當通過代理連接時很有用處,還有服務器描述信息。消息大小可變的。Size 4消息大小是以字節(jié)為單位,不包括頭部和大小的域Type 10x34User Count 4NA 當前登錄到服務器的用戶數目File Count 4NA 服務器知道的文件數目名稱字節(jié)大小默認值注釋Protocol 10xE3Size 4消息大小是以字節(jié)為單位,不包括頭部和大小的域Type 10x32OP_SERVERLIST 操作碼的值Entry Count 1NA 該消息中描述的服務器數目Server entries (EntryCount*6NA 服務器描述符條目,每個條目大小是6字節(jié),包含4字節(jié)

56、IP 地址和2字節(jié)TCP 端口名稱字節(jié)大小默認值注釋6.2.9搜索請求從客戶端發(fā)送到服務器。該消息用來通過用戶的搜索字符串搜索文件。消息大小是可變的。搜索字符串可以包含布爾條件”AND ”、”O(jiān)R ”、”NOT ”。用戶可以指定需要的文件的類型和大小,也可以設置一個有效的閾值(例如顯示至少來自5個其它客戶端的有效結果。Protocol 10xE3Size 4消息大小是以字節(jié)為單位,不包括頭部和大小的域Type 10x41OP_SERVERIDENT 操作碼的值Hash 16NA 服務器的GUID (好像用來調試用Server IP 4NA 服務器IP 地址Server Port 4NA 服務器監(jiān)聽的TCP 端口Tag Count 4NA 在消息末處標簽的數目ServerName Tag 可變的NA 服務器名稱。該標簽是字符串標簽,標簽名稱是值為0x1的整數ServerDescription Tag 可變的NA 服務器描述字符串。該標簽是字符串標簽,標簽名稱是值為0xB 的整數名稱字節(jié)大小默認值注釋Protocol 10xE3Size 4消息大小是以字節(jié)為單位,不包括頭部和大小的域Type 10x16OP_SEARCHREQUEST 操作碼的值Parsed search strin 可變