电驴协议中文版
前幾天研究了一下電驢的協(xié)議,由于電驢協(xié)議是英文版看起來比較費(fèi)事,所以看的時候順便翻譯了中文版,希望對想了解電驢的朋友有所幫助。
??????????????????????????? 目錄
1簡介-- 2
1.1?目的和范圍-- 2
1.2?概述-- 2
1.2.1客戶端到服務(wù)器的連接-- 3
1.2.2客戶端到客戶端的連接-- 3
1.3?客戶ID- 4
1.4用戶ID- 4
1.5文件ID- 4
1.5.1文件哈希-- 5
1.5.2?? 根哈希-- 5
1.6?eMule協(xié)議擴(kuò)展-- 5
1.7?軟件和硬件限制-- 5
2?客戶端服務(wù)器的TCP交流-- 5
2.1?建立連接-- 5
2.2連接啟動時消息交換-- 7
2.3文件搜索-- 8
2.4回調(diào)機(jī)制-- 9
3客戶端服務(wù)器的UDP交流-- 10
3.1 服務(wù)器保持連接和狀態(tài)信息-- 10
3.2 增強(qiáng)文件搜索-- 11
3.3 增強(qiáng)文件源搜索-- 11
4.客戶端和客戶端的交流-- 11
4.1初始的握手-- 11
4.2可靠的用戶辨認(rèn)-- 12
4.2.1信譽(yù)系統(tǒng)-- 13
4.3?請求文件-- 13
4.3.1基本的信息交互-- 13
4.3.2請求的文件沒有找到-- 14
4.3.3上傳隊(duì)列-- 14
4.3.4上傳隊(duì)列的管理-- 14
4.3.5達(dá)到上傳隊(duì)列的頂部-- 15
4.4數(shù)據(jù)傳輸-- 15
4.4.1數(shù)據(jù)包-- 15
4.4.2數(shù)據(jù)傳輸順序-- 16
?
?
?
?
?
?
?
1簡介
1.1?目的和范圍
eMule是流行的文件共享程序,基于eDonkey協(xié)議。這份報(bào)告描述了eMule的網(wǎng)絡(luò)行為和解釋了理解該協(xié)議所需的基本術(shù)語。本報(bào)告也給出了eMule網(wǎng)絡(luò)協(xié)議的完整規(guī)范,包括一個附錄,它提供了消息格式。這份文檔的信息是基于開源的eMule客戶端。接下來的簡介目的是提供基本的背景知識,讓讀者閱讀和理解這份文檔。關(guān)于eMule的更多消息在這里找到。
1.2?概述
eMule網(wǎng)絡(luò)是由上百個eMule服務(wù)器和幾百萬個eMule客戶端組成。客戶端必須連接到一個服務(wù)器來取得網(wǎng)絡(luò)服務(wù),只要該客戶端在系統(tǒng)中,服務(wù)器連接保持打開狀態(tài)。這些服務(wù)器主要執(zhí)行集聚索引服務(wù)(好像在Napster),相互間不聯(lián)系。
每個eMule客戶端都預(yù)配置了一個服務(wù)器列表和當(dāng)?shù)匚募到y(tǒng)的共享文件列表。客戶端用單獨(dú)的TCP連接到一個eMule服務(wù)器登錄到網(wǎng)絡(luò)中,獲得想得到的文件信息和客戶端。eMule客戶端也用幾百個TCP連接到其他客戶端進(jìn)行上傳和下載文件。每個eMule客戶端對它的每個共享文件都維護(hù)著一個上傳隊(duì)列。要下載的客戶端先加入到隊(duì)列的底部,然后逐漸前進(jìn)直到到達(dá)隊(duì)列的頂部并開始下載它的文件。一個客戶端可以從幾個不同的eMule客戶端中下載同一個文件的不同的文件塊。客戶端也可以上傳它還沒有完成的文件的文件塊。最后,eMule擴(kuò)展了eDonkey的能力,允許客戶端之間交換關(guān)于服務(wù)器、其他客戶端和文件的信息。注意,客戶端和服務(wù)器的交流都是基于TCP的。
服務(wù)器使用了一個內(nèi)部數(shù)據(jù)庫,用來存儲關(guān)于客戶端和文件的信息。一個eMule服務(wù)器不存儲任何文件,它為關(guān)于文件位置的存儲信息作集聚索引。服務(wù)器的另一個功能,開始變得被抗議,是連接由于通過防火墻連接而無法接收到連接的兩個客戶端。這個連接功能增加了服務(wù)器的負(fù)載。相對于服務(wù)器和其他客戶端,eMule使用UDP來增強(qiáng)客戶端的能力。客戶端發(fā)送和接收UDP信息的能力在日常使用中不是強(qiáng)制使用的,當(dāng)有防火墻阻止它收發(fā)UDP信息時也能無瑕疵的運(yùn)行。
1.2.1客戶端到服務(wù)器的連接
在開始啟動時,客戶端用TCP連接到一個eMule服務(wù)器。服務(wù)器提供一個客戶ID給客戶端,在整個客戶端-服務(wù)器連接的生命周期里,它是有效的(注意,如果客戶端有一個高ID,它會從所有的服務(wù)器中接收到相同的ID,直到它的IP地址改變)。在連接建立之后,客戶端發(fā)送它的共享文件列表到服務(wù)器中。服務(wù)器把這個列表存儲到它的內(nèi)部數(shù)據(jù)庫中,這個數(shù)據(jù)庫通常包含了成百上千有效的文件和活動的客戶端。eMule客戶端也發(fā)送它的下載列表,包含著它想下載的文件。第二章提供了eMule客戶端和服務(wù)器TCP信息交換的詳細(xì)描述。
建立連接之后,eMule服務(wù)器給客戶端發(fā)送用有它想下載的文件的其他客戶端列表(這些客戶端稱作“源”)。從這點(diǎn)起,eMule客戶端開始與其他客戶端建立連接,如1.2.2所述。
注意,在整個客戶端會話期間,客戶/服務(wù)TCP連接一直保持連接狀態(tài)。初次握手后主要是 用戶活動激發(fā)事務(wù):有時,客戶端發(fā)送文件搜索需求,由搜索結(jié)果回應(yīng),一個搜索事務(wù)一般在對源中指定文件查詢之后,用源(IP和端口)列表來回答這個查詢,查詢者可以從這列表中下載文件。
客戶端和它沒有連接的服務(wù)器的交流是用UDP。UDP信息的目的是增強(qiáng)文件搜索,增強(qiáng)源搜索,最后保持連接狀態(tài)(確保客戶端服務(wù)器列表中的eMule服務(wù)器有效)。在第三章中可找到更多的關(guān)于客戶-服務(wù)UDP信息交換的細(xì)節(jié)。
1.2.2客戶端到客戶端的連接
一個eMule客戶端連接到另一個eMuel客戶端(源)是為了下載文件。一個文件分成很多部分,進(jìn)一步的碎片。客戶端可以從幾個(不同的)客戶端中下載同一個文件來分別獲得不同的文件碎片。
當(dāng)兩個客戶端連接時,它們交換容量信息,然后協(xié)商一個下載(或者上傳,根據(jù)看法)的開始。每個客戶端有一個下載列表,記住一列等待下載文件的客戶端。當(dāng)eMule客戶端下載隊(duì)列空的時候,一個下載請求很可能會導(dǎo)致一個下載開始(除非,比如這個請求者被禁止)。當(dāng)下載隊(duì)列不是空的時候,就會將這個請求的客戶端加入到隊(duì)列中。在給定的時間內(nèi),不能為幾個以上客戶端各自提供最小帶寬2.4k/s。一個下載的客戶端可能被一個比它較高隊(duì)列等級的等待的客戶端搶占,在下載會話的最初15分鐘內(nèi),正在下載的eMule客戶端的隊(duì)列等級會增加直到能防止被擊潰。
當(dāng)下載的客戶端到達(dá)下載隊(duì)列的頭部時,上傳的客戶端初始化一個連接來給它發(fā)送需要的文件塊。eMule客戶端可以在幾個其他客戶端的等待隊(duì)列中,都注冊下載相同文件的塊。當(dāng)一個等待的客戶端實(shí)際上完成了(從它們中的一個)下載文件塊,它不會通知其他客戶端在其隊(duì)列中刪除它,當(dāng)它到達(dá)它們的隊(duì)列頭時只是簡單的拒絕它們的上傳意圖。
EMuley用一個信用系統(tǒng)來鼓勵上傳,為了防止假冒用RSA公匙密碼系統(tǒng)來保護(hù)信用系統(tǒng)。
客戶端連接可能用一套eDonkey協(xié)議沒有定義的信息,這信息稱作擴(kuò)展協(xié)議。擴(kuò)展協(xié)議用來實(shí)施信用系統(tǒng),一般信息的交換(像服務(wù)器和源列表的更新),通過收發(fā)壓縮的文件塊來改善性能。
當(dāng)EMule客戶端在等待開始下載文件時,有限地用UDP周期性檢查在它對等的客戶端上的上傳隊(duì)列客戶端狀態(tài)。
1.3?客戶ID
客戶ID是服務(wù)器在它們連接握手時提供的一個4字節(jié)標(biāo)識符。客戶ID只在客戶-服務(wù)器TCP連接的生命期中有效,盡管萬一客戶端有一個高ID,所有的服務(wù)器都會分配它同樣的ID直到IP地址改變。客戶端ID分為低ID和高ID。當(dāng)一個客戶端不能接收一個輸入連接時,eMule服務(wù)器將特有地分配給客戶端一個低ID。擁有一個低ID會限制客戶端對eMule網(wǎng)絡(luò)的使用,和可能導(dǎo)致服務(wù)器拒絕一個客戶端連接。高ID的計(jì)算是以客戶端IP地址為基礎(chǔ)的,如下所述。本節(jié)從eMule協(xié)議觀點(diǎn)描述了客戶ID的分配和重要性。允許其它客戶端自由地連接到其本機(jī)上的eMule的TCP端口(默認(rèn)端口號是4662)的客戶端會分配給一個高ID。有高ID的客戶端沒限制使用eMule網(wǎng)絡(luò)。當(dāng)服務(wù)器無法打開一個TCP連接到客戶端的eMule端口時,會分配一個低ID給該客戶端。這主要發(fā)生在機(jī)器上裝有防火墻的客戶端,阻止了輸入連接。當(dāng)出現(xiàn)下面情況時,客戶端也會接收到一個低ID:
????????? 當(dāng)客戶端通過NAT或代理服務(wù)器連接
????????? 當(dāng)服務(wù)器繁忙(導(dǎo)致服務(wù)器重連接計(jì)時器超時)
高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客戶端不能連接到不在同一個服務(wù)器上的其他低ID客戶端,因?yàn)?/span>eMule不支持在服務(wù)器間管道連接。
為了支持低ID客戶端,引入了回調(diào)機(jī)制。使用這機(jī)制,高ID客戶端請求(通過eMule服務(wù)器)低ID客戶端連接它來交換文件。
1.4用戶ID
eMule支持信用系統(tǒng)來鼓勵用戶共享文件。用戶上傳越多的文件給其他客戶端,它接收的信用越多,它在它們的等待隊(duì)列中前進(jìn)得越快。
用戶ID是128位(16字節(jié))、連接隨機(jī)數(shù)字創(chuàng)建的GUID,第6和第15字節(jié)不是隨機(jī)產(chǎn)生的,它們的值分別是14和111。在整個客戶端和指定的服務(wù)器會話中,客戶ID是有效的,然而用戶ID(也叫用戶哈希)是唯一的并且跨越會話時用來識別客戶端(用戶ID識別工作站)。用戶ID在信用系統(tǒng)中扮演重要角色,這為“黑客”假冒其他用戶來獲得他們信用賦予的優(yōu)先權(quán)提供了動機(jī)。Emule提供加密方案設(shè)計(jì)來阻止欺騙和冒名頂替。這個實(shí)施是簡單的應(yīng)答交換,依靠RSA公有/私有鑰匙加密。
1.5文件ID
文件ID用來惟一的標(biāo)識網(wǎng)絡(luò)中的文件和文件損壞偵測和修復(fù)。注意,eMule不依靠文件名來惟一標(biāo)識和編目文件,通過哈希文件內(nèi)容計(jì)算出的GUID標(biāo)識文件。有兩種類型文件ID-一種主要用來產(chǎn)生惟一的文件ID,另一種是用來損壞偵測和修復(fù)。
1.5.1文件哈希
文件是用由客戶端和基于文件內(nèi)容計(jì)算出來的128位GUID哈希來標(biāo)識的。GUID是應(yīng)用MD4算法到文件數(shù)據(jù)中計(jì)算而來。當(dāng)計(jì)算文件ID時,文件被分成每段9.28MB長的部分。每部分單獨(dú)計(jì)算出一個GUID,然后所有的哈希組合成一個惟一的文件ID。當(dāng)下載的客戶端完成一個文件部分下載時,它計(jì)算這部分哈希,然后和發(fā)送過來的這部分哈希對比,如果這部分發(fā)現(xiàn)損壞了,客戶端嘗試通過逐漸替換這部分中的位(每個180kb)來修復(fù)損壞部分,直到哈希計(jì)算OK。
1.5.2?? 根哈希
用SHA1算法來為每部分計(jì)算根哈希,基于每塊180kb大小。它提供了更高等級的可靠性和可修復(fù)性,更多信息可在eMule官方網(wǎng)站得到。
1.6?eMule協(xié)議擴(kuò)展
盡管eMule完全兼容eDonkey,它還是實(shí)行了幾種擴(kuò)展,允許eMule兩個客戶端為用戶提供另外的功能。擴(kuò)展只要集中在客戶端與客戶端的交流,特別是在安全和UDP使用領(lǐng)域上。在本文檔中,所有信息流圖標(biāo)明的信息,是eMule擴(kuò)展部分的,用灰色表示。
1.7?軟件和硬件限制
在活動用戶數(shù)量的服務(wù)器配置中有兩種限制-軟件和硬件。硬件限制遠(yuǎn)大于軟件限制。當(dāng)活動用戶的數(shù)量達(dá)到軟件限制時,服務(wù)器停止接收新的低ID客戶連接。當(dāng)用戶數(shù)量達(dá)到硬件限制時,服務(wù)器滿了,不再接收任何客戶端連接。
層次遍歷二叉樹。
大致算法:
采用一個隊(duì)列q,先將二叉樹根結(jié)點(diǎn)入隊(duì)列,然后退隊(duì)列,輸出該結(jié)點(diǎn);若它有左子樹,便將左子樹根結(jié)點(diǎn)入隊(duì)列;若它有右子樹,便將右子樹根結(jié)點(diǎn)入隊(duì)列,如此直到隊(duì)列空為止。
2?客戶端服務(wù)器的TCP交流
每個客戶端用TCP精確地連接到一個服務(wù)器。服務(wù)器分配給客戶端一個ID,在與服務(wù)器其余的會話中標(biāo)識該客戶端(高ID客戶端總是根據(jù)它的IP地址分配)。eMule GUI客戶端需要建立一個服務(wù)器連接來用于操作。客戶端不能同時與幾個服務(wù)器連接,也不能在沒有用戶干涉的情況下動態(tài)更換服務(wù)器。
2.1?建立連接
在準(zhǔn)備建立與服務(wù)器的連接時,客戶端會嘗試并行地連接到幾個服務(wù)器,根據(jù)成功的登陸順序放棄其他的。
???????????????? ????????????????????? ????? 圖2.1
有下面幾個可能的連接建立個案:
????????? 高ID連接-服務(wù)器分配一個高ID給正在連接的客戶端
????????? 低ID連接-服務(wù)器分配一個低ID給正在連接的客戶端
????????? 拒絕會話-服務(wù)器拒絕客戶端
當(dāng)然,也有不重要的個案-服務(wù)器崩潰或者不可連接。
圖2.1描述了導(dǎo)致高ID連接的信息順序。在這種情況下,客戶端建立一個TCP連接到服務(wù)器,然后發(fā)送一個登錄信息到服務(wù)器。服務(wù)器用另一個TCP連接到客戶端,執(zhí)行一個客戶端-客戶端的握手來保證連接的客戶端有能力接收來自其他eMule客戶端的連接。在完成客戶端握手后,服務(wù)器關(guān)閉第二個連接,通過發(fā)送ID更改信息來完成客戶端-服務(wù)器的握手。你可能注意到eMule信息消息是灰色的。這是因?yàn)檫@個消息是eMule協(xié)議擴(kuò)展的一個部分(1.6節(jié))
???????????????? ???????????????? 圖2.2
圖2.2描述了導(dǎo)致低ID連接的信息順序。在這種情況下,服務(wù)器不能連接到發(fā)送請求的客戶端,分配一個低ID給客戶端。服務(wù)器消息一般包含警告信息,就像“警告[服務(wù)器細(xì)節(jié)] - 你是低ID。請察看你的網(wǎng)絡(luò)配置和/或你的設(shè)置”低ID和高ID握手都是通過隨著ID更改消息完成的,這個ID更改消息分配客戶端一個客戶端ID,用在與服務(wù)器的下一個會話。
?????????? ??????????????????????????? 圖2.3
圖2.3描述了被拒絕的會話順序。因?yàn)榭蛻舳藫碛幸粋€低ID或者到達(dá)了服務(wù)器硬件的容量限制,服務(wù)器就可能拒絕會話。服務(wù)器消息會包含一個短字符串描述拒絕的理由。
2.2連接啟動時消息交換
在建立成功的連接后,客戶端和服務(wù)器交換幾個設(shè)置消息。這些消息的目的是根據(jù)雙方狀態(tài)來雙方更新。客戶端通過提供它的共享文件列表(見6.2.4節(jié))給服務(wù)器來開始,然后要求更新它的服務(wù)器列表。服務(wù)器發(fā)送它的狀態(tài)和版本(6.2.6節(jié)和6.2.2節(jié)),然后發(fā)送它所知的eMule服務(wù)器列表和提供更多一些自我認(rèn)定的細(xì)節(jié)。最后客戶端要求源(可以訪問下載它下載列表中的文件的其它客戶端)和服務(wù)器回應(yīng)一系列的消息,客戶端下載列表中的每個文件,直到下載所有的源列表到客戶端。圖2.4圖解了這個順序。
???????????????? ??????????????????????????? 圖2.4
2.3文件搜索
文件搜索是由用戶發(fā)起的。這個操作簡單,一個搜索要求(見6.2.9節(jié))發(fā)送到服務(wù)器,然后服務(wù)器用一個搜索結(jié)果回應(yīng)。當(dāng)有很多結(jié)果時,搜索結(jié)果消息就會被壓縮。接著,用戶選擇下載一個或多個文件,客戶端就要求源為選中的文件和服務(wù)器返回每個要求文件的源隊(duì)列(見6.2.12節(jié))。就在回應(yīng)發(fā)現(xiàn)的源之前,可以發(fā)送一個可選的服務(wù)器狀態(tài)消息。這個狀態(tài)消息(6.2.6節(jié))包含關(guān)于當(dāng)前用戶數(shù)量和服務(wù)器支持的文件等信息。重要注意的是,UDP消息有個補(bǔ)充順序事件,用來增強(qiáng)客戶端為它搜索的文件定位源的能力,詳細(xì)的細(xì)節(jié)見第3章。在檢驗(yàn)出源是新的之后,eMule客戶端開始嘗試連接和把它們加入到它的源列表。源聯(lián)系的順序就是eMule客戶端接收到它們的順序。圖2.5描述了文件搜索順序。
?????????? ??????????????????????????? 圖2.5
eMule客戶端根據(jù)源加入到它的列表中的順序來連接源。沒有優(yōu)先機(jī)制來決定連接那個源。當(dāng)可以要求同一個源來下載客戶端下載列表中的幾個文件時,有一種復(fù)雜的機(jī)制來解決這個局面(注意,載客戶端之間eMule只允許一個單獨(dú)的上傳連接)。選擇算法是基于用戶優(yōu)先規(guī)則,當(dāng)沒有指定優(yōu)先時,默認(rèn)是字母順序。關(guān)于處理可以上傳多于一個文件的源的詳細(xì)描述,可以在網(wǎng)站中找到。
2.4回調(diào)機(jī)制
回調(diào)機(jī)制是設(shè)計(jì)來克服低ID客戶端不能接收輸入的連接的,這樣客戶端之間就能共享它們的文件。機(jī)制很簡單:假如客戶端A和B都連接到同一個eMule服務(wù)器,A需要的文件在B上,但B是低ID的,A可以向服務(wù)器發(fā)送一個回調(diào)請求(見6.2.13節(jié)),請求服務(wù)器叫B呼叫回它。服務(wù)器,已經(jīng)有一個與B的打開的TCP連接,發(fā)送一個回調(diào)請求消息(見6.2.14節(jié))到B,為它提供A的IP和端口。B就能連接到A并發(fā)送文件,沒有給服務(wù)器增加負(fù)擔(dān)。很明顯,只有高ID客戶端可以要求低ID客戶端回調(diào)(低ID客戶端是沒有接收輸入連接的能力的)。圖2.6圖解了回調(diào)消息交換。
??????????????????????????? ?????????? 圖2.6
也有允許兩個低ID客戶端交換文件的能力,通過它們的服務(wù)器連接,用服務(wù)器接力。大部分服務(wù)器不再提供這個選項(xiàng),因?yàn)樗兄路?wù)器的負(fù)擔(dān)。
3客戶端服務(wù)器的UDP交流
eMule客戶端和服務(wù)器用不可靠的UDP服務(wù)來保持連接和增強(qiáng)搜索。eMule客戶端產(chǎn)生UDP包的總量可以達(dá)到它發(fā)送包的總數(shù)目的5% - 這些根據(jù)客戶端服務(wù)器列表中服務(wù)器的數(shù)目,客戶端下載列表中每個文件的源數(shù)目和用戶執(zhí)行的搜索數(shù)目而定。UDP包通過計(jì)時器觸發(fā),計(jì)時器每100ms過期,有一個單獨(dú)的線程負(fù)責(zé)發(fā)送UDP輸送結(jié)果,以每秒10個UDP的最大速率。
3.1 服務(wù)器保持連接和狀態(tài)信息
客戶端周期性驗(yàn)證它服務(wù)器列表中的服務(wù)器狀態(tài)。驗(yàn)證是通過發(fā)送UDP服務(wù)器狀態(tài)請求(見6.3.3節(jié))和UDP服務(wù)器描述請求(見6.3.7節(jié))消息完成的。這里描述的簡單保持連接計(jì)劃每小時產(chǎn)生不超過幾打包。任何情況下,包的最大速率是每秒0.2個包(或每5秒一個包)。當(dāng)檢查服務(wù)器的狀態(tài)時,客戶端會首先發(fā)送一個服務(wù)器狀態(tài)請求消息,接著,每兩次試圖(發(fā)送一個服務(wù)器狀態(tài)請求)中就發(fā)送一次服務(wù)器描述請求,見圖3.1。
??????????????????????????? ???????????????? 圖3.1
客戶端發(fā)送的服務(wù)器狀態(tài)請求中包括一個隨機(jī)數(shù)字,在服務(wù)器回應(yīng)中返回。在服務(wù)器返回的數(shù)字與客戶端發(fā)送的要求中數(shù)字不同的情況下,回應(yīng)的信息就會被丟棄。每次發(fā)送到服務(wù)器的包是狀態(tài)請求,客戶端就移動嘗試計(jì)數(shù)器。任何來自服務(wù)器的消息(包括搜索結(jié)果)都重置嘗試計(jì)數(shù)器。當(dāng)嘗試計(jì)數(shù)器達(dá)到一個可配置的限制時,服務(wù)器就認(rèn)為是死機(jī),從客戶端的服務(wù)器列表中刪除。服務(wù)器回應(yīng)包括幾個數(shù)據(jù)項(xiàng):服務(wù)器狀態(tài)回應(yīng)(見6.3.4)包括服務(wù)器中當(dāng)前用戶數(shù)目和文件數(shù)目,也包括服務(wù)器的軟件和硬件限制(見1.7節(jié))。服務(wù)器描述回應(yīng)(見6.3.8節(jié))包括服務(wù)器名稱和一個短的描述字符串。圖3.2演示了客戶端和活動服務(wù)器中滿連接序列的消息流。
????????????????????? ???????????????? 圖3.2
3.2 增強(qiáng)文件搜索
eMule客戶端可以設(shè)置用UDP來增強(qiáng)它的文件搜索。UDP搜索結(jié)果格式幾乎與??節(jié)描述的TCP搜索請求一樣。服務(wù)器只在有了搜索結(jié)果才回應(yīng)。UDP搜索結(jié)果消息有兩種不同的opcdes,我也無法說清它們之間的不同。UDP搜索包發(fā)送到客戶端服務(wù)器列表中的服務(wù)器上。更多信息見6.3.5節(jié)和6.3.6節(jié)。
3.3 增強(qiáng)文件源搜索
當(dāng)客戶端下載列表中的特定文件的源數(shù)目小于配置限制(100)時,客戶端就周期性地發(fā)送獲取源的UDP包到它的服務(wù)器列表中的服務(wù)器中為該文件尋找更多的源。可能每秒發(fā)送一個包,使得源搜索在客戶端產(chǎn)生的UDP輸送中成為可觀的部分。消息的格式(6.3.1節(jié)描述)非常相似它的TCP計(jì)數(shù)器部分。注意,與TCP源搜索相反,UDP源搜索在文件搜索中減弱,對于指定的文件,只是依靠客戶端擁有的源數(shù)目。
4.客戶端和客戶端的交流
????? 當(dāng)客戶端在服務(wù)器上注冊、查詢文件和當(dāng)源客戶端需要從其他終端下載文件的時候,每個【文件,客戶端】對都會建立一個專門的TCP連接,當(dāng)在一個確定的時間段(默認(rèn)40秒)沒有活動的Socket,或者對等端的Socked已經(jīng)關(guān)閉,這個連接才會被關(guān)閉。
????? 為了提供合理的下載速度,eMule不允許客戶端開始下載直到能夠提供它達(dá)到最小的允許碼流(通常設(shè)置為2.4K/S)。
4.1初始的握手
?????? 初始的握手是對稱的,雙方都互相發(fā)送相同的信息。互相交換信息進(jìn)行身份辨認(rèn)(包括版本和性能信息)。有兩種類型的消息發(fā)送—Hello消息(6.4.1節(jié))和eMule信息消息(6.5.1節(jié))第一部分是eDonkey的一部分,他是和eDonkey客戶端兼容的,第二部分是eMule獨(dú)有的客戶端擴(kuò)展協(xié)議。如圖4.1所示兩個eMule客戶端之間的握手。在所有這些擴(kuò)展的信息里的內(nèi)容是UDP信息交互,可靠性和源的性能。
??????????????????????????? ??????????????????????????? 圖4.1
4.2可靠的用戶辨認(rèn)
?????? 在1.4節(jié)簡單的說了以下用戶ID和其他使用者模擬真正用戶的動機(jī)。可靠的用戶辨認(rèn)是eMule擴(kuò)展的一部分。如果客戶端支持可靠的用戶辨認(rèn),在初始的握手之后就立即啟動用戶辨認(rèn)。可靠辨認(rèn)的目的是防止惡意的用戶的模仿一個真正的用戶,當(dāng)一個可靠的辨認(rèn)被用應(yīng)時,它遵循以下步驟:
1.???????? 在初始的握手階段,B指出它支持和希望使用可靠的辨認(rèn)。
2.???????? A響應(yīng)發(fā)送一個可靠的辨認(rèn)消息(6.5.8節(jié)),包括是否需要B的公共密鑰,同樣也包含一個4字節(jié)的有符號的標(biāo)記。
3.???????? 如果A指出需要B的公共密鑰,B就發(fā)送它的密鑰給A(6.5.9節(jié))。
4.???????? B發(fā)送一個確認(rèn)信息(6.5.10),這個信息包含A發(fā)送的4字節(jié)的標(biāo)記,附加兩個字節(jié)(A的IP和B的ID,B可能低ID或是高ID)。如圖4.2所示
?????????????????????????????????????????????????????????????? 圖4.2
4.2.1信譽(yù)系統(tǒng)
?????? 這節(jié)簡要的描述了一下客戶端的信譽(yù)系統(tǒng)。信譽(yù)系統(tǒng)的目的是要鼓勵用戶分享自己的文件。當(dāng)客戶端上傳文件時,下載的客戶端依據(jù)傳輸數(shù)據(jù)的數(shù)量更新被下載客戶端的信譽(yù)指數(shù)。注意這個信譽(yù)系統(tǒng)不是全局的,它被下載客戶端保持在本地,只有在上傳客戶端請求從特定的客戶端下載時才被重視,信譽(yù)按照很少幾個規(guī)則被計(jì)算:
1.???????? 上傳總數(shù)*2/下載總數(shù)
?????? 當(dāng)下載的總是0時,等式的值是10。
2.???????? (上傳總數(shù) + 2) 開方
?????? 當(dāng)上傳總數(shù)小于1M是,等式的值是1。
上傳/下載數(shù)量在數(shù)百萬兆字節(jié)中被計(jì)算出來,無論如何信譽(yù)指數(shù)都不會超過10或小于1。
4.3?請求文件
?????? 根據(jù)之前提到的為每一個【文件、客戶端】對創(chuàng)建一個單獨(dú)的TCP連接,在連接確認(rèn)之后客戶端立即發(fā)送幾個查詢消息(它想下載的文件)。一個典型的成功的過程如圖4.3所示。
??????????????????????????? ?????? 圖4.3
4.3.1基本的信息交互
?????? 基本的信息交互包含4個消息:A發(fā)送一個文件請求消息(6.4.18節(jié)),緊跟著立即發(fā)送一個被請求的文件ID消息(6.4.17節(jié))。B用一個文件請求回答消息(6.4.15節(jié))答復(fù)文件請求消息,用文件狀態(tài)消息(6.4.18)答復(fù)被請求文件ID消息。我是在找不到任何理由打這些發(fā)送信息分為4個消息,實(shí)際上更容易用兩個消息來標(biāo)示(請求和答復(fù))。
?????? 擴(kuò)展的協(xié)議添加了兩個消息到這個序列中,一個源的請求(6.5.6)和一個源的回答(6.5.7)。擴(kuò)充過去習(xí)慣從B的源(如果B當(dāng)前正在下載的文件)到A。詳細(xì)的描述,B下載的文件沒有下載完,它就可以向其他客戶端發(fā)送文件的其他部分。B可以向A發(fā)送它已經(jīng)下完的文件的部分,盡管這些片段只是整個文件很小的一部分。
4.3.2請求的文件沒有找到
?????? 當(dāng)A向B請求一個文件,但B在它的共享的隊(duì)列里沒有找到這個文件。B跳過請求答復(fù)消息,在被請求的文件ID消息之后,立即發(fā)送一個文件沒有發(fā)現(xiàn)的消息(6.4.16節(jié))。如圖4.4所示。
????????????????????
????????????????????????????????????????? ????????????? 圖4.4
4.3.3上傳隊(duì)列
?????? 如果B有被請求下載的文件并且它的上傳隊(duì)列不是空的,這說明有其他的客戶端正在下載它的的文件,或許在上傳隊(duì)列中的客戶端A和B完成了如圖4.3所示的完整的握手,當(dāng)A請求B開始上傳它的文件時,B把A加到自己的上傳隊(duì)列里,并用一個隊(duì)列類型消息答復(fù)A(6.5.4節(jié)),消息包括(A在B的上傳隊(duì)列中的位置。如圖4.5所示的序列
?????????????????????????????????? 圖4.5
4.3.4上傳隊(duì)列的管理
?????? 每一個上傳的文件客戶端都為它維護(hù)一個具有優(yōu)先權(quán)的隊(duì)列。對于隊(duì)列中的每一個客戶端的優(yōu)先權(quán)是根據(jù)每個客戶端在隊(duì)列中的時間和一個優(yōu)先權(quán)的描述。位于隊(duì)列頭部的是具有最高優(yōu)先權(quán)的客戶端。優(yōu)先權(quán)的值使用以下公式計(jì)算:值=(等級/在隊(duì)列中的時間)/100或者是無窮大(如果下載的客戶端被定義為被下載客戶端的朋友)。除了被禁止的用戶是0級別(從而阻止該客戶端達(dá)到隊(duì)列的頂部)以外,其他的原始值都是100。這個優(yōu)先級別不是根據(jù)下載客戶端的信譽(yù)度(取值在1—10之間)就是根據(jù)下載的文件的優(yōu)先級(0.2—1.8),這個優(yōu)先級是由上載的客戶端設(shè)定的。當(dāng)客戶端的優(yōu)先級的值高于其他客戶端的優(yōu)先值時,它就開始下載文件。A將繼續(xù)下載這個文件直到以下的情況發(fā)生:
1.???????? 上載的客戶端被用戶終止。
2.???????? 下載的客戶端已經(jīng)下載完文件的所有部分。
3.???????? 下載的客戶端被其他比它優(yōu)先級高的客戶端搶占。
?????? 為了下載的客戶端在剛開始下載和被搶占以前能有機(jī)會下載到少許兆的數(shù)據(jù),在最初的15分鐘eMule推進(jìn)下載客戶端的優(yōu)先級值到200。
4.3.5達(dá)到上傳隊(duì)列的頂部
?????? 當(dāng)A達(dá)到B的上傳隊(duì)列的頂部的時候,B連接A執(zhí)行最初的握手同時發(fā)送一個接收上傳請求消息(6.4.11節(jié))。A現(xiàn)在可以選擇繼續(xù)和下載文件文件發(fā)送一個請求文件部分的消息,或者A可以取消下載(如果A已經(jīng)下載完所請求文件的所有部分)發(fā)送一個取消傳輸?shù)南?#xff08;6.4.12節(jié))。如圖4.6所示。
?????????????????????????????????????????????????????????????? 圖4.6
4.4數(shù)據(jù)傳輸
4.4.1數(shù)據(jù)包
?????? 發(fā)送和接收文件片是eMule主要的網(wǎng)絡(luò)活動。有預(yù)言eMule將會使FTP時代終止,在文件片的傳輸和數(shù)據(jù)的處理有其余的eMule掌控。一個被發(fā)送的文件片的大小可以在5000和15000字節(jié)(依賴于壓縮)。為了防止被分片,一個文件片消息被發(fā)送都在一個文件片之內(nèi),每個被發(fā)送的文件塊都是一個單獨(dú)的TCP包。在eMule V0.3最大的發(fā)送文件塊的大小是1300字節(jié)(注意這個數(shù)指的是TCP的有效載荷)。為了雙方的協(xié)商,每個控制消息都被以一個單獨(dú)的TCP包發(fā)送,有時分派其他的消息,數(shù)據(jù)消息被分到幾個TCP數(shù)據(jù)包中。第一個數(shù)據(jù)包包含發(fā)送文件的頭(6.4.3節(jié)),其余的只包含數(shù)據(jù)。如果文件片在按照1300字節(jié)被分開時有殘余,那么這部分殘余就和第一個數(shù)據(jù)包一起被發(fā)送。如圖4.7所示
????????????????????
????????????????????????????????????????????????????????????????????? 圖4.7
4.4.2數(shù)據(jù)傳輸順序
?????? 在一個文件請求答復(fù)以后,一個文件片的傳輸序列就立即開始。下載客戶端A根據(jù)B的上傳請求答復(fù)消息(6.4.11節(jié))發(fā)送一個開始上傳請求消息(6.4.10節(jié))。之后A立即發(fā)送請求的文件片(6.4.4節(jié)),B用被請求的文件片答復(fù)A(6.4.3節(jié))。注意單一的文件片請求可以請求直到3部分,所以每一個文件請求可以被答復(fù)直到3個發(fā)送的隊(duì)列。
當(dāng)所有的客戶單都支持?jǐn)U展的客戶端協(xié)議時文件片被壓縮發(fā)送(6.5.3)。擴(kuò)展的協(xié)議同樣也支持一個可選的文件信息消息(6.5.5)它僅僅在接收上傳請求消息之前被發(fā)送。文件片的傳輸細(xì)細(xì)次序如圖4.8所示:
??????????????????????????? 圖4.8
4.4.3選擇那個文件下載
?????? eMule有選擇的選擇文件片的下載次序,為了最大限度的使用當(dāng)前的網(wǎng)絡(luò)資源。每個文件被分成9.28M的文件片,每個文件片又被分成180K的文件塊。被下載的文件片的順序有發(fā)送請求文件片請求消息(6.4.4節(jié))的客戶端決定。下載的客戶端可能從不同源上特定的時間里下載同一個分片,所有被請求的分塊可以來自同一個源的同一個分片。一下的規(guī)則來規(guī)定下載片的等級:
1.???????? 大塊的頻率(可用的),非常突出的大塊應(yīng)給盡快的被下載,使成為一個可用的源塊。
2.???????? 對文件信息預(yù)覽有用的塊(文件頭和文件結(jié)尾),預(yù)覽文件信息和檢查文件類型(.MP3)等。
3.???????? 請求的狀態(tài),向另一個文件塊設(shè)法請求每個源,在所有的源之間傳播請求。
4.???????? 完成(最短的完成的),塊的部分得到將會下載完在開始下載其他人的資源之前。
頻率定義了3個層次的標(biāo)準(zhǔn):非常稀有、稀有和普通。在每一個層次內(nèi),標(biāo)準(zhǔn)有特殊的砝碼,用來計(jì)算片的等級。有較低等級的片先被下載,
總結(jié)
- 上一篇: ceph修复osd为down的情况
- 下一篇: group_concat函数用法