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