在注冊(cè)服務(wù)器以后以及查詢文件和源之后，電騾客戶端需要聯(lián)系其他客戶端來下載文件。一個(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)文來響應(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ā)送的口令來創(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ù)庫的數(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ì)算。無論什么情況信譽(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)文。我不能找到任何原因來在這四個(gè)報(bào)文中發(fā)送的分割信息；僅僅以兩個(gè)報(bào)文來處理
(
請(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ò)展用來傳遞
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)來確定。在隊(duì)列的頭部是那些擁有最高分的客戶。分值的計(jì)算按照下面的公式：分
=
（
rating*
在隊(duì)列中的秒）
/100
，或無窮大（對(duì)于那些被定義為朋友的下載客戶）。起初的
rating
值是
100
，除非被禁止的用戶，他的
rating
是
0
（并且也不可能得到隊(duì)列的頂端）。
Rating
會(huì)被下載客戶端的信譽(yù)值修改（變化范圍是
1-10
）或者通過上傳文件優(yōu)先級(jí)（
0.2-1.8
），這個(gè)是由上傳客戶端來設(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é)）來取消下載（如果它已經(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ā)送部分序列來響應(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è)片中來自同一個(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)重，其用來計(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ù)來響應(yīng)（
6.4.22
節(jié)）。當(dāng)響應(yīng)的客戶端期望隱藏它的共享文件鏈表時(shí)，答復(fù)包含
0
個(gè)文件（而不是發(fā)送一個(gè)報(bào)文說不能訪問），圖
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
來響應(yīng)（節(jié)
6.4.9
），其中包含了文件中每個(gè)片的
hashset
。圖
4.12
描述這個(gè)過程：
圖
4.12
：
hashset
請(qǐng)求
1.7
??????????????????????
得到文件的預(yù)覽
客戶端可以請(qǐng)求他的對(duì)端來得到一個(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ù)覽