電騾協(xié)議規(guī)范（四）：客戶端到客戶端的TCP連接

在注冊(cè)服務(wù)器以后以及查詢文件和源之后，電騾客戶端需要聯(lián)系其他客戶端來(lái)下載文件。一個(gè)專一 TCP 連接為每文件和客戶端對(duì)創(chuàng)建。當(dāng)沒有 SOCKET 活動(dòng)持續(xù)一個(gè)階段（默認(rèn)的 40 秒）或?qū)Χ岁P(guān)閉了連接的時(shí)候連接會(huì)被關(guān)閉。

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

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

初始化握手是對(duì)稱的，雙方都發(fā)送給彼此發(fā)送同樣的信息。客戶端交互彼此包含的標(biāo)示、版本和容量信息。參與的消息有兩種類型 -Hello 消息（ 6.4.1 節(jié)）和電騾信息消息（ 6.5.1 ），第一個(gè)是 eDonkey 的一部分，并且和 eDonkey 客戶端兼容；第二個(gè)是電騾擴(kuò)展協(xié)議的一部分。圖 4.1 描述了兩個(gè)電騾客戶端之間的握手過程。擴(kuò)展信息中包含的是 UDP 報(bào)文交換、安全標(biāo)示和源交換能力。

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

1.2 ?????????????????????? 安全用戶標(biāo)示

1.4 節(jié)簡(jiǎn)短的解釋了用戶 ID 和假裝其他用戶的動(dòng)機(jī) [3] 。安全用戶表示是電騾擴(kuò)展協(xié)議的一部分。如果客戶端支持安全標(biāo)示，它在初始化握手之后立即執(zhí)行。安全標(biāo)示的目的是防止用戶偽裝。使用安全標(biāo)示時(shí)，執(zhí)行下面的步驟：

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

2．? A 以發(fā)送安全標(biāo)示報(bào)文來(lái)響應(yīng)（ 6.5.8 節(jié)），這個(gè)報(bào)文指出是否 A 需要 B 的公鑰，并且包含一個(gè) 4 個(gè)字節(jié)口令由 B 簽名是使用。

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

4．? B 發(fā)送簽名的報(bào)文（ 6.5.10 ），其使用 A 發(fā)送的口令來(lái)創(chuàng)建的，另外雙字是 A 的 IP 地址，如果 B 是低 ID 或高 ID 。圖 4.2 描述這個(gè)序列。

?

圖 4.2 ：安全標(biāo)示流程

1.2.1 ?????????????????????????????????????????? 信用系統(tǒng)

本節(jié)簡(jiǎn)單介紹客戶端的信譽(yù)系統(tǒng)。信譽(yù)系統(tǒng)的目的是鼓勵(lì)用戶共享文件。當(dāng)客戶端上傳文件給其他端時(shí)，下載的客戶端根據(jù)傳輸數(shù)據(jù)庫(kù)的數(shù)量更新其信譽(yù)值。注意，信譽(yù)系統(tǒng)不是全局的，一個(gè)傳輸?shù)男抛u(yù)值被正在下載的客戶端保存在本地并且僅僅當(dāng)上傳客戶端（獲得信譽(yù)的）從這個(gè)指定客戶端請(qǐng)求下載時(shí)候才被重新考慮。信譽(yù)這樣計(jì)算的：

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

當(dāng)總下載數(shù)是 0 的時(shí)候這個(gè)表達(dá)式是 10

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

當(dāng)總上傳小于 1MB 時(shí)候，表達(dá)式為 1

上傳 / 下載數(shù)量以 MB 計(jì)算。無(wú)論什么情況信譽(yù)值不能大于 10 或小于 1 。

1.3 ?????????????????????? 請(qǐng)求文件

就如前面提到的為每個(gè) [ 客戶端、文件 ] 對(duì)創(chuàng)建一個(gè)單獨(dú)的連接。在連接建立之后，客戶端理解發(fā)送幾個(gè)查詢關(guān)于其期望下載文件的報(bào)文。典型的，這里描述成功的場(chǎng)景。見圖 4 。 3 。

1.3.1 ?????????????????????????????????????????? 基本報(bào)文交換

基本報(bào)文交換由四個(gè)報(bào)文組成： A 發(fā)送一個(gè)文件請(qǐng)求報(bào)文（ 6.4.18 節(jié)），緊接著一個(gè)請(qǐng)求文件 ID 的報(bào)文（ 6.4.17 節(jié)）。 B 響應(yīng)這個(gè)文件請(qǐng)求是一個(gè)文件請(qǐng)求的響應(yīng)（ 6.4.15 節(jié)），以文件狀態(tài)報(bào)文（ 6.4.18 節(jié)）響應(yīng)請(qǐng)求的文件 ID 報(bào)文。我不能找到任何原因來(lái)在這四個(gè)報(bào)文中發(fā)送的分割信息；僅僅以兩個(gè)報(bào)文來(lái)處理 ( 請(qǐng)求和響應(yīng) ) 。

擴(kuò)展協(xié)議對(duì)這個(gè)序列添加了兩個(gè)報(bào)文，一個(gè)是源請(qǐng)求（ 6.5.6 節(jié)），一個(gè)是源響應(yīng)（ 6.5.7 節(jié)）。這個(gè)擴(kuò)展用來(lái)傳遞 B 的源（如果 B 當(dāng)前正在下載文件）到 A 。沒有要求 B 在發(fā)送文件片給其他客戶端的之前需要完成下載， B 可以將其完全下載的任何小部分發(fā)送給 A ，即使只有一個(gè)文件的分片下載完成。

圖 4.3 ：文件請(qǐng)求

1.3.2 ???????? 文件沒有找到的場(chǎng)景

當(dāng) A 從 B 請(qǐng)求文件，但 B 的共享文件列表中沒有這個(gè)文件的時(shí)候， B 忽略這個(gè)文件請(qǐng)求回答報(bào)文，并且立即在請(qǐng)求文件 ID 報(bào)文后面發(fā)送一個(gè)文件未找到報(bào)文（ 6.4.16 節(jié)），如圖 4.4 所示：

圖 4.4 ，文件請(qǐng)求失敗 - 文件沒有找到

1.3.3 ?????????????????????????????????????????? 獲得上傳隊(duì)列

B 有請(qǐng)求文件，但它的上傳隊(duì)列沒有空間了，也就是有客戶端正在下載文件，并且有可能 A 和 B 上傳隊(duì)列的客戶端執(zhí)行圖 4.3 的完全握手時(shí) A 請(qǐng)求 B 開始上傳文件， B 將 A 添加到 A 的上傳隊(duì)列中，并且回應(yīng)排行報(bào)文（ 6.5.4 節(jié)），這個(gè)報(bào)文中包含了 A 在 B 的上傳隊(duì)列中的位置。圖 4.5 描述這個(gè)序列。

1.3.4 ?????????????????????????????????????????? 上傳隊(duì)列管理

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

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

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

3．? 被另一個(gè)比當(dāng)前下載客戶端優(yōu)先級(jí)高的客戶端搶先了。

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

1.3.5 ???????? 到達(dá)上載隊(duì)列的頂部

當(dāng) A 達(dá)到 B 上傳隊(duì)列的頂部的時(shí)候， B 連接到 A ，執(zhí)行初始化握手以及發(fā)送一個(gè)接受上傳請(qǐng)求的報(bào)文（ 6.4.11 節(jié)）。 A 現(xiàn)在可以選擇繼續(xù)下載請(qǐng)求命令中指定的文件，或者發(fā)送一個(gè)取消傳輸?shù)膱?bào)文（ 6.4.12 節(jié)）來(lái)取消下載（如果它已經(jīng)從另外一個(gè)源得到這個(gè)部分）。圖 4.6 解釋這些選項(xiàng)。

圖 4.6 ：文件請(qǐng)求繼續(xù)下載

1.4 ?????????????????????? 數(shù)據(jù)傳輸

1.4.1 ???????? 數(shù)據(jù)包

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

圖 4.7 ，文件片報(bào)文細(xì)節(jié)

1.4.2 ???????? 數(shù)據(jù)傳輸序列

在文件請(qǐng)求響應(yīng)之后，一部分傳輸序列可以理解開始。下載客戶端 A 發(fā)送一個(gè)起始的上傳請(qǐng)求（ 6.4.10 節(jié)）， B 以一個(gè)接受上傳請(qǐng)求的報(bào)文（ 6.4.11 節(jié)）響應(yīng)該報(bào)文。在這之后， A 開始請(qǐng)求文件片（ 6.4.4 節(jié)）， B 響應(yīng)請(qǐng)求的文件片（ 6.4.3 節(jié)），注意，單個(gè)文件片請(qǐng)求可能請(qǐng)求 3 片，因此每個(gè)文件片請(qǐng)求可能有 3 個(gè)發(fā)送部分序列來(lái)響應(yīng)。

當(dāng)兩個(gè)支持?jǐn)U展客戶端協(xié)議的客戶端時(shí)，文件片可能是壓縮之后發(fā)送的（ 6.5.3 節(jié)）。擴(kuò)展的文件協(xié)議也支持一個(gè)可選文件信息報(bào)文（ 6.5.5 節(jié)），這個(gè)可能在接受上傳請(qǐng)求報(bào)文之前發(fā)送。片傳輸報(bào)文序列如 4.8 圖所示：

圖 4.8 ：文件片交互

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

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

1．? 數(shù)據(jù)的可用頻率，非常少的快應(yīng)該盡量快下載，從而成為新的可用源

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

3．? 請(qǐng)求狀態(tài)（正在下載中），試著想向每個(gè)源詢問另一個(gè)塊，在所有源之間廣播請(qǐng)求。

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

頻繁標(biāo)準(zhǔn)定義 3 個(gè) 0 ：非常少、少和通常。標(biāo)準(zhǔn)為每個(gè) 0 注定權(quán)重，其用來(lái)計(jì)算片速率。較低速率片首先下載。根據(jù)上面的原則下面的列表指出了文件速率變化的范圍。

l???????? 0-9999 未請(qǐng)求和請(qǐng)求的非常稀少的片

l???????? 10000-19999 未請(qǐng)求的稀少的和預(yù)覽片

l???????? 20000-29999 未請(qǐng)求的最完成通用片

l???????? 30000-39999 請(qǐng)求的稀少預(yù)覽片

l???????? 40000-49999 請(qǐng)求的未完成通用片

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

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

處理瀏覽對(duì)端共享文件和文件夾的有兩個(gè)報(bào)文流程。第一個(gè)是查看共享文件報(bào)文（ 6.4.21 節(jié)），在握手之后理解發(fā)送。這個(gè)報(bào)文以查看共享文件答復(fù)來(lái)響應(yīng)（ 6.4.22 節(jié)）。當(dāng)響應(yīng)的客戶端期望隱藏它的共享文件鏈表時(shí)，答復(fù)包含 0 個(gè)文件（而不是發(fā)送一個(gè)報(bào)文說(shuō)不能訪問），圖 4.9 描述報(bào)文序列。

圖 4.9 ：查看文件

第二個(gè)報(bào)文流程以查看共享文件夾列表的報(bào)文開始（ 6.4.23 節(jié)），該報(bào)文以共享文件夾列表響應(yīng)（ 6.4.24 節(jié)），對(duì)于響應(yīng)中的每個(gè)文件夾都會(huì)發(fā)送一個(gè)瀏覽共享文件夾內(nèi)容的報(bào)文（ 6.4.25 ）。這樣的報(bào)文以內(nèi)容列表回復(fù)（ 6.4.26 節(jié)）。圖 4.10 描述這個(gè)報(bào)文序列。

一旦接收客戶端被配置為塊共享文件或文件夾請(qǐng)求，它恢復(fù)一個(gè)詢問共享拒絕的報(bào)文，如圖 4.11 所示。

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

圖 4.11 ：查看共享拒絕

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

為了能夠片哈希值， hashset 請(qǐng)求被發(fā)送（ 6.4.8 節(jié)），這個(gè)請(qǐng)求以一個(gè) hashset 來(lái)響應(yīng)（節(jié) 6.4.9 ），其中包含了文件中每個(gè)片的 hashset 。圖 4.12 描述這個(gè)過程：

圖 4.12 ： hashset 請(qǐng)求

1.7 ?????????????????????? 得到文件的預(yù)覽

客戶端可以請(qǐng)求他的對(duì)端來(lái)得到一個(gè)下載文件的預(yù)覽。預(yù)覽是程序獨(dú)立的，并且根據(jù)文件的類型不同而變化。 eMule0 0.30e 僅僅支持圖像預(yù)覽。這個(gè)報(bào)文交換過程在圖 4.13 中描述，包含兩個(gè)報(bào)文：預(yù)覽請(qǐng)求（ 6.5.11 節(jié)）和預(yù)覽回復(fù)（ 6.5.12 節(jié)）。

圖

4.13 ：得到文件預(yù)覽

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