eMule中文協(xié)議

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

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

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

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

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

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

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

8、好像在Napster,相互間不聯(lián)系。每個(gè)eMule客戶端都預(yù)配置了一個(gè)服務(wù)器列表和當(dāng)?shù)匚募到y(tǒng)的共享文件列表。客戶端用單獨(dú)的TCP連接到一個(gè)eMule服務(wù)器登錄到網(wǎng)絡(luò)中,獲得想得到的文件信息和客戶端。eMule 客戶端也用幾百個(gè)TCP連接到其他客戶端進(jìn)行上傳和下載文件。每個(gè)eMule客戶端對(duì)它的每個(gè)共享文件都維護(hù)著一個(gè)上傳隊(duì)列。要下載的客戶端先加入到隊(duì)列的底部,然后逐漸前進(jìn)直到到達(dá)隊(duì)列的頂部并開(kāi)始下載它的文件。一個(gè)客戶端可以從幾個(gè)不同的eMule客戶端中下載同一個(gè)文件的不同的文件塊?？蛻舳艘部梢陨蟼魉€沒(méi)有完成的文件的文件塊。最后,eMule 擴(kuò)展了eDonkey的能力,允許客戶端之間交換關(guān)于

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

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

11、述。 注意,在整個(gè)客戶端會(huì)話期間,客戶/服務(wù)TCP連接一直保持連接狀態(tài)。初次握手后主要是用戶活動(dòng)激發(fā)事務(wù):有時(shí),客戶端發(fā)送文件搜索需求,由搜索結(jié)果回應(yīng),一個(gè)搜索事務(wù)一般在對(duì)源中指定文件查詢之后,用源(IP和端口列表來(lái)回答這個(gè)查詢,查詢者可以從這列表中下載文件。客戶端和它沒(méi)有連接的服務(wù)器的交流是用UDP。UDP信息的目的是增強(qiáng)文件搜索,增強(qiáng)源搜索,最后保持連接狀態(tài)(確保客戶端服務(wù)器列表中的eMule服務(wù)器有效。在第三章中可找到更多的關(guān)于客戶-服務(wù)UDP信息交換的細(xì)節(jié)。1.2.2客戶端到客戶端的連接一個(gè)eMule客戶端連接到另一個(gè)eMuel客戶端(源是為了下載文件。一個(gè)文件分成很多部分,進(jìn)一步的碎

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

13、客戶端到達(dá)下載隊(duì)列的頭部時(shí),上傳的客戶端初始化一個(gè)連接來(lái)給它發(fā)送需要的文件塊。eMule客戶端可以在幾個(gè)其他客戶端的等待隊(duì)列中,都注冊(cè)下載相同文件的塊。當(dāng)一個(gè)等待的客戶端實(shí)際上完成了(從它們中的一個(gè)下載文件塊,它不會(huì)通知其他客戶端在其隊(duì)列中刪除它,當(dāng)它到達(dá)它們的隊(duì)列頭時(shí)只是簡(jiǎn)單的拒絕它們的上傳意圖。EMuley用一個(gè)信用系統(tǒng)來(lái)鼓勵(lì)上傳,為了防止假冒用RSA公匙密碼系統(tǒng)來(lái)保護(hù)信用系統(tǒng)。客戶端連接可能用一套eDonkey協(xié)議沒(méi)有定義的信息,這信息稱作擴(kuò)展協(xié)議。擴(kuò)展協(xié)議用來(lái)實(shí)施信用系統(tǒng),一般信息的交換(像服務(wù)器和源列表的更新,通過(guò)收發(fā)壓縮的文件塊來(lái)改善性能。當(dāng)EMule客戶端在等待開(kāi)始下載文件時(shí),有

14、限地用UDP周期性檢查在它對(duì)等的客戶端上的上傳隊(duì)列客戶端狀態(tài)。1.3客戶ID客戶ID是服務(wù)器在它們連接握手時(shí)提供的一個(gè)4字節(jié)標(biāo)識(shí)符?？蛻鬒D只在客戶-服務(wù)器TCP連接的生命期中有效,盡管萬(wàn)一客戶端有一個(gè)高ID,所有的服務(wù)器都會(huì)分配它同樣的ID直到IP 地址改變。客戶端ID分為低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ǔ)的,如下所述。本節(jié)從eMule協(xié)議觀點(diǎn)描述了客戶ID的分配和重要性。允許其它客戶端自由地連接到其本機(jī)上

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

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

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

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

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

20、客戶端一個(gè)ID,在與服務(wù)器其余的會(huì)話中標(biāo)識(shí)該客戶端(高ID客戶端總是根據(jù)它的IP地址分配。eMule GUI客戶端需要建立一個(gè)服務(wù)器連接來(lái)用于操作。客戶端不能同時(shí)與幾個(gè)服務(wù)器連接,也不能在沒(méi)有用戶干涉的情況下動(dòng)態(tài)更換服務(wù)器。2.1建立連接在準(zhǔn)備建立與服務(wù)器的連接時(shí),客戶端會(huì)嘗試并行地連接到幾個(gè)服務(wù)器,根據(jù)成功的登陸順序放棄其他的。有下面幾個(gè)可能的連接建立個(gè)案:1、高ID連接-服務(wù)器分配一個(gè)高ID給正在連接的客戶端2、低ID連接-服務(wù)器分配一個(gè)低ID給正在連接的客戶端3、拒絕會(huì)話-服務(wù)器拒絕客戶端當(dāng)然,也有不重要的個(gè)案-服務(wù)器崩潰或者不可連接。 圖2.1高ID連接的信息順序圖2.1描述了導(dǎo)致高I

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

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

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

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

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

26、息交換。 也有允許兩個(gè)低ID客戶端交換文件的能力,通過(guò)它們的服務(wù)器連接,用服務(wù)器接力。大部分服務(wù)器不再提供這個(gè)選項(xiàng),因?yàn)樗兄路?wù)器的負(fù)擔(dān)。3客戶端服務(wù)器的UDP交流eMule客戶端和服務(wù)器用不可靠的UDP服務(wù)來(lái)保持連接和增強(qiáng)搜索。eMule客戶端產(chǎn)生UDP 包的總量可以達(dá)到它發(fā)送包的總數(shù)目的5%-這些根據(jù)客戶端服務(wù)器列表中服務(wù)器的數(shù)目,客戶端下載列表中每個(gè)文件的源數(shù)目和用戶執(zhí)行的搜索數(shù)目而定。UDP包通過(guò)計(jì)時(shí)器觸發(fā),計(jì)時(shí)器每100ms過(guò)期,有一個(gè)單獨(dú)的線程負(fù)責(zé)發(fā)送UDP輸送結(jié)果,以每秒10個(gè)UDP的最大速率。3.1服務(wù)器保持連接和狀態(tài)信息客戶端周期性驗(yàn)證它服務(wù)器列表中的服務(wù)器狀態(tài)。驗(yàn)證是通過(guò)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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