電騾協議規范（四）：客戶端到客戶端的TCP連接

在注冊服務器以后以及查詢文件和源之后，電騾客戶端需要聯系其他客戶端來下載文件。一個專一 TCP 連接為每文件和客戶端對創建。當沒有 SOCKET 活動持續一個階段（默認的 40 秒）或對端關閉了連接的時候連接會被關閉。

為了提供合理的下載速率，電騾并不允許一個客戶端下載文件，直到電騾能夠提供（所有其他下載客戶端）最少允許的速率時（這是一個硬編碼，當前設置為 2.4KB/s ）。

1.1 ?????????????????????? 初始化握手

初始化握手是對稱的，雙方都發送給彼此發送同樣的信息?？蛻舳私换ケ舜税臉耸尽姹竞腿萘啃畔?。參與的消息有兩種類型 -Hello 消息（ 6.4.1 節）和電騾信息消息（ 6.5.1 ），第一個是 eDonkey 的一部分，并且和 eDonkey 客戶端兼容；第二個是電騾擴展協議的一部分。圖 4.1 描述了兩個電騾客戶端之間的握手過程。擴展信息中包含的是 UDP 報文交換、安全標示和源交換能力。

圖 4.1 ：電騾客戶端初始化握手過程

1.2 ?????????????????????? 安全用戶標示

1.4 節簡短的解釋了用戶 ID 和假裝其他用戶的動機 [3] 。安全用戶表示是電騾擴展協議的一部分。如果客戶端支持安全標示，它在初始化握手之后立即執行。安全標示的目的是防止用戶偽裝。使用安全標示時，執行下面的步驟：

1．? 在初始化握手的時候， B 只是它支持并期望使用安全標示

2．? A 以發送安全標示報文來響應（ 6.5.8 節），這個報文指出是否 A 需要 B 的公鑰，并且包含一個 4 個字節口令由 B 簽名是使用。

3．? 如果 A 指出她需要 B 的公鑰，那么 B 將它的 KEY 發給 A （ 6.5.9 節）

4．? B 發送簽名的報文（ 6.5.10 ），其使用 A 發送的口令來創建的，另外雙字是 A 的 IP 地址，如果 B 是低 ID 或高 ID 。圖 4.2 描述這個序列。

?

圖 4.2 ：安全標示流程

1.2.1 ?????????????????????????????????????????? 信用系統

本節簡單介紹客戶端的信譽系統。信譽系統的目的是鼓勵用戶共享文件。當客戶端上傳文件給其他端時，下載的客戶端根據傳輸數據庫的數量更新其信譽值。注意，信譽系統不是全局的，一個傳輸的信譽值被正在下載的客戶端保存在本地并且僅僅當上傳客戶端（獲得信譽的）從這個指定客戶端請求下載時候才被重新考慮。信譽這樣計算的：

1．? 總共上傳 *2/ 總共下載的

當總下載數是 0 的時候這個表達式是 10

2．? 總共上傳 +2 的平方根

當總上傳小于 1MB 時候，表達式為 1

上傳 / 下載數量以 MB 計算。無論什么情況信譽值不能大于 10 或小于 1 。

1.3 ?????????????????????? 請求文件

就如前面提到的為每個 [ 客戶端、文件 ] 對創建一個單獨的連接。在連接建立之后，客戶端理解發送幾個查詢關于其期望下載文件的報文。典型的，這里描述成功的場景。見圖 4 。 3 。

1.3.1 ?????????????????????????????????????????? 基本報文交換

基本報文交換由四個報文組成： A 發送一個文件請求報文（ 6.4.18 節），緊接著一個請求文件 ID 的報文（ 6.4.17 節）。 B 響應這個文件請求是一個文件請求的響應（ 6.4.15 節），以文件狀態報文（ 6.4.18 節）響應請求的文件 ID 報文。我不能找到任何原因來在這四個報文中發送的分割信息；僅僅以兩個報文來處理 ( 請求和響應 ) 。

擴展協議對這個序列添加了兩個報文，一個是源請求（ 6.5.6 節），一個是源響應（ 6.5.7 節）。這個擴展用來傳遞 B 的源（如果 B 當前正在下載文件）到 A 。沒有要求 B 在發送文件片給其他客戶端的之前需要完成下載， B 可以將其完全下載的任何小部分發送給 A ，即使只有一個文件的分片下載完成。

圖 4.3 ：文件請求

1.3.2 ???????? 文件沒有找到的場景

當 A 從 B 請求文件，但 B 的共享文件列表中沒有這個文件的時候， B 忽略這個文件請求回答報文，并且立即在請求文件 ID 報文后面發送一個文件未找到報文（ 6.4.16 節），如圖 4.4 所示：

圖 4.4 ，文件請求失敗 - 文件沒有找到

1.3.3 ?????????????????????????????????????????? 獲得上傳隊列

B 有請求文件，但它的上傳隊列沒有空間了，也就是有客戶端正在下載文件，并且有可能 A 和 B 上傳隊列的客戶端執行圖 4.3 的完全握手時 A 請求 B 開始上傳文件， B 將 A 添加到 A 的上傳隊列中，并且回應排行報文（ 6.5.4 節），這個報文中包含了 A 在 B 的上傳隊列中的位置。圖 4.5 描述這個序列。

1.3.4 ?????????????????????????????????????????? 上傳隊列管理

對于每個上傳的文件，客戶端都維護一個上傳優先級隊列。在隊列中的每個客戶端的優先級是按照客戶在隊列中的時間和優先級修飾符號來確定。在隊列的頭部是那些擁有最高分的客戶。分值的計算按照下面的公式：分 = （ rating* 在隊列中的秒） /100 ，或無窮大（對于那些被定義為朋友的下載客戶）。起初的 rating 值是 100 ，除非被禁止的用戶，他的 rating 是 0 （并且也不可能得到隊列的頂端）。 Rating 會被下載客戶端的信譽值修改（變化范圍是 1-10 ）或者通過上傳文件優先級（ 0.2-1.8 ），這個是由上傳客戶端來設置的。當一個客戶端的分比其他客戶端分高的時候，它就開始下載文件。一個客戶端會一直下載文件，只有下面情況發生的時候不同：

1．? 上傳的客戶端被用戶終止了

2．? 下載客戶端得到所有他需要的文件片

3．? 被另一個比當前下載客戶端優先級高的客戶端搶先了。

為了允許一個剛開始下載的客戶端在被搶先之前能夠下載一些 MB ， eMule 將正在下載客戶端在起初的 15 分鐘內設置 rating 設置到 200 。

1.3.5 ???????? 到達上載隊列的頂部

當 A 達到 B 上傳隊列的頂部的時候， B 連接到 A ，執行初始化握手以及發送一個接受上傳請求的報文（ 6.4.11 節）。 A 現在可以選擇繼續下載請求命令中指定的文件，或者發送一個取消傳輸的報文（ 6.4.12 節）來取消下載（如果它已經從另外一個源得到這個部分）。圖 4.6 解釋這些選項。

圖 4.6 ：文件請求繼續下載

1.4 ?????????????????????? 數據傳輸

1.4.1 ???????? 數據包

發送和接收文件片是主要的 eMule 網絡活動的主要部分。當所有剩下的 eMule 是控制的時， eMule 到 FTP 將得到發送文件和數據事物匹配。一個文件片可以是 5000 到 15000 字節，（依賴于壓縮）。為了避免分片，一個文件片報文在一片中發送，每個 TCP 的片是單獨的包。在 eMule0.30e 中，最大片大小是 1300 字節（注意，這僅僅和 TCP 負載有關）。換句話，當每個控制報文在一個單個 TCP 包發送的時候，有時和其他報文一起，數據報文被分割為幾個 TCP 包。第一個包包含發送文件的信息頭（ 6.4.3 節），其余的包都是數據。如果被發送的文件片不是 1300 的整數倍，那么這些多余的部分和第一個包一起發送（攜帶頭的包）。圖 4.7 描述了文件片報文。

圖 4.7 ，文件片報文細節

1.4.2 ???????? 數據傳輸序列

在文件請求響應之后，一部分傳輸序列可以理解開始。下載客戶端 A 發送一個起始的上傳請求（ 6.4.10 節）， B 以一個接受上傳請求的報文（ 6.4.11 節）響應該報文。在這之后， A 開始請求文件片（ 6.4.4 節）， B 響應請求的文件片（ 6.4.3 節），注意，單個文件片請求可能請求 3 片，因此每個文件片請求可能有 3 個發送部分序列來響應。

當兩個支持擴展客戶端協議的客戶端時，文件片可能是壓縮之后發送的（ 6.5.3 節）。擴展的文件協議也支持一個可選文件信息報文（ 6.5.5 節），這個可能在接受上傳請求報文之前發送。片傳輸報文序列如 4.8 圖所示：

圖 4.8 ：文件片交互

1.4.3 ???????? 選擇下載那一片

eMule 選擇性的選擇片的下載順序，目的是最大化整個網絡的吞吐量和共享。每個文件被分成 9.28MB 字節片，并且每片被分成 180KB 快。片下載的順序是由請求文件分片的下載客戶端決定。下載客戶端可以在任何給定瞬間從每個源下載一個單個片，以及駐留在同一個片中來自同一個源的所有請求塊。下面原則在下載片時使用（以這個順序）：

1．? 數據的可用頻率，非常少的快應該盡量快下載，從而成為新的可用源

2．? 用于預覽的片（第一個 + 最后一個塊），預覽或檢查一個文件（例如：電影、 MP3 ）。

3．? 請求狀態（正在下載中），試著想向每個源詢問另一個塊，在所有源之間廣播請求。

4．? 完成（最短 - 到完成），應該在開始下載另一個塊之前局部地得到塊。

頻繁標準定義 3 個 0 ：非常少、少和通常。標準為每個 0 注定權重，其用來計算片速率。較低速率片首先下載。根據上面的原則下面的列表指出了文件速率變化的范圍。

l???????? 0-9999 未請求和請求的非常稀少的片

l???????? 10000-19999 未請求的稀少的和預覽片

l???????? 20000-29999 未請求的最完成通用片

l???????? 30000-39999 請求的稀少預覽片

l???????? 40000-49999 請求的未完成通用片

這個算法通常首先選擇最稀少的片，然而，部分完成的片且接近完成的片可能也會被選擇。對于通用的片，下載會在不同源之間廣播。

1.5 ?????????????????????? 瀏覽共享文件和文件夾

處理瀏覽對端共享文件和文件夾的有兩個報文流程。第一個是查看共享文件報文（ 6.4.21 節），在握手之后理解發送。這個報文以查看共享文件答復來響應（ 6.4.22 節）。當響應的客戶端期望隱藏它的共享文件鏈表時，答復包含 0 個文件（而不是發送一個報文說不能訪問），圖 4.9 描述報文序列。

圖 4.9 ：查看文件

第二個報文流程以查看共享文件夾列表的報文開始（ 6.4.23 節），該報文以共享文件夾列表響應（ 6.4.24 節），對于響應中的每個文件夾都會發送一個瀏覽共享文件夾內容的報文（ 6.4.25 ）。這樣的報文以內容列表回復（ 6.4.26 節）。圖 4.10 描述這個報文序列。

一旦接收客戶端被配置為塊共享文件或文件夾請求，它恢復一個詢問共享拒絕的報文，如圖 4.11 所示。

圖 4.10 ：查看共享文件或文件夾

圖 4.11 ：查看共享拒絕

1.6 ?????????????????????? 交換片的 hashset

為了能夠片哈希值， hashset 請求被發送（ 6.4.8 節），這個請求以一個 hashset 來響應（節 6.4.9 ），其中包含了文件中每個片的 hashset 。圖 4.12 描述這個過程：

圖 4.12 ： hashset 請求

1.7 ?????????????????????? 得到文件的預覽

客戶端可以請求他的對端來得到一個下載文件的預覽。預覽是程序獨立的，并且根據文件的類型不同而變化。 eMule0 0.30e 僅僅支持圖像預覽。這個報文交換過程在圖 4.13 中描述，包含兩個報文：預覽請求（ 6.5.11 節）和預覽回復（ 6.5.12 節）。

圖

4.13 ：得到文件預覽

posted on 2006-08-03 20:56 笨笨 閱讀(1501) 評論(0)  編輯 收藏 引用 所屬分類: P2P技術