电驴协议中文版
前幾天研究了一下電驢的協(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函数用法