在注冊服務器以后以及查詢文件和源之后，電騾客戶端需要聯(lián)系其他客戶端來下載文件。一個專一
TCP
連接為每文件和客戶端對創(chuàng)建。當沒有
SOCKET
活動持續(xù)一個階段（默認的
40
秒）或?qū)Χ岁P閉了連接的時候連接會被關閉。
為了提供合理的下載速率，電騾并不允許一個客戶端下載文件，直到電騾能夠提供（所有其他下載客戶端）最少允許的速率時（這是一個硬編碼，當前設置為
2.4KB/s
）。
1.1
??????????????????????
初始化握手
初始化握手是對稱的，雙方都發(fā)送給彼此發(fā)送同樣的信息。客戶端交互彼此包含的標示、版本和容量信息。參與的消息有兩種類型
-Hello
消息（
6.4.1
節(jié)）和電騾信息消息（
6.5.1
），第一個是
eDonkey
的一部分，并且和
eDonkey
客戶端兼容；第二個是電騾擴展協(xié)議的一部分。圖
4.1
描述了兩個電騾客戶端之間的握手過程。擴展信息中包含的是
UDP
報文交換、安全標示和源交換能力。
圖
4.1
：電騾客戶端初始化握手過程
1.2
??????????????????????
安全用戶標示
1.4
節(jié)簡短的解釋了用戶
ID
和假裝其他用戶的動機
[3]
。安全用戶表示是電騾擴展協(xié)議的一部分。如果客戶端支持安全標示，它在初始化握手之后立即執(zhí)行。安全標示的目的是防止用戶偽裝。使用安全標示時，執(zhí)行下面的步驟：
1．?
在初始化握手的時候，
B
只是它支持并期望使用安全標示
2．?
A
以發(fā)送安全標示報文來響應（
6.5.8
節(jié)），這個報文指出是否
A
需要
B
的公鑰，并且包含一個
4
個字節(jié)口令由
B
簽名是使用。
3．?
如果
A
指出她需要
B
的公鑰，那么
B
將它的
KEY
發(fā)給
A
（
6.5.9
節(jié)）
4．?
B
發(fā)送簽名的報文（
6.5.10
），其使用
A
發(fā)送的口令來創(chuàng)建的，另外雙字是
A
的
IP
地址，如果
B
是低
ID
或高
ID
。圖
4.2
描述這個序列。
?
圖
4.2
：安全標示流程
1.2.1
??????????????????????????????????????????
信用系統(tǒng)
本節(jié)簡單介紹客戶端的信譽系統(tǒng)。信譽系統(tǒng)的目的是鼓勵用戶共享文件。當客戶端上傳文件給其他端時，下載的客戶端根據(jù)傳輸數(shù)據(jù)庫的數(shù)量更新其信譽值。注意，信譽系統(tǒng)不是全局的，一個傳輸?shù)男抛u值被正在下載的客戶端保存在本地并且僅僅當上傳客戶端（獲得信譽的）從這個指定客戶端請求下載時候才被重新考慮。信譽這樣計算的：
1．?
總共上傳
*2/
總共下載的
當總下載數(shù)是
0
的時候這個表達式是
10
2．?
總共上傳
+2
的平方根
當總上傳小于
1MB
時候，表達式為
1
上傳
/
下載數(shù)量以
MB
計算。無論什么情況信譽值不能大于
10
或小于
1
。
1.3
??????????????????????
請求文件
就如前面提到的為每個
[
客戶端、文件
]
對創(chuàng)建一個單獨的連接。在連接建立之后，客戶端理解發(fā)送幾個查詢關于其期望下載文件的報文。典型的，這里描述成功的場景。見圖
4
。
3
。
1.3.1
??????????????????????????????????????????
基本報文交換
基本報文交換由四個報文組成：
A
發(fā)送一個文件請求報文（
6.4.18
節(jié)），緊接著一個請求文件
ID
的報文（
6.4.17
節(jié)）。
B
響應這個文件請求是一個文件請求的響應（
6.4.15
節(jié)），以文件狀態(tài)報文（
6.4.18
節(jié)）響應請求的文件
ID
報文。我不能找到任何原因來在這四個報文中發(fā)送的分割信息；僅僅以兩個報文來處理
(
請求和響應
)
。
擴展協(xié)議對這個序列添加了兩個報文，一個是源請求（
6.5.6
節(jié)），一個是源響應（
6.5.7
節(jié)）。這個擴展用來傳遞
B
的源（如果
B
當前正在下載文件）到
A
。沒有要求
B
在發(fā)送文件片給其他客戶端的之前需要完成下載，
B
可以將其完全下載的任何小部分發(fā)送給
A
，即使只有一個文件的分片下載完成。
圖
4.3
：文件請求
1.3.2
????????
文件沒有找到的場景
當
A
從
B
請求文件，但
B
的共享文件列表中沒有這個文件的時候，
B
忽略這個文件請求回答報文，并且立即在請求文件
ID
報文后面發(fā)送一個文件未找到報文（
6.4.16
節(jié)），如圖
4.4
所示：
圖
4.4
，文件請求失敗
-
文件沒有找到
1.3.3
??????????????????????????????????????????
獲得上傳隊列
B
有請求文件，但它的上傳隊列沒有空間了，也就是有客戶端正在下載文件，并且有可能
A
和
B
上傳隊列的客戶端執(zhí)行圖
4.3
的完全握手時
A
請求
B
開始上傳文件，
B
將
A
添加到
A
的上傳隊列中，并且回應排行報文（
6.5.4
節(jié)），這個報文中包含了
A
在
B
的上傳隊列中的位置。圖
4.5
描述這個序列。
1.3.4
??????????????????????????????????????????
上傳隊列管理
對于每個上傳的文件，客戶端都維護一個上傳優(yōu)先級隊列。在隊列中的每個客戶端的優(yōu)先級是按照客戶在隊列中的時間和優(yōu)先級修飾符號來確定。在隊列的頭部是那些擁有最高分的客戶。分值的計算按照下面的公式：分
=
（
rating*
在隊列中的秒）
/100
，或無窮大（對于那些被定義為朋友的下載客戶）。起初的
rating
值是
100
，除非被禁止的用戶，他的
rating
是
0
（并且也不可能得到隊列的頂端）。
Rating
會被下載客戶端的信譽值修改（變化范圍是
1-10
）或者通過上傳文件優(yōu)先級（
0.2-1.8
），這個是由上傳客戶端來設置的。當一個客戶端的分比其他客戶端分高的時候，它就開始下載文件。一個客戶端會一直下載文件，只有下面情況發(fā)生的時候不同：
1．?
上傳的客戶端被用戶終止了
2．?
下載客戶端得到所有他需要的文件片
3．?
被另一個比當前下載客戶端優(yōu)先級高的客戶端搶先了。
為了允許一個剛開始下載的客戶端在被搶先之前能夠下載一些
MB
，
eMule
將正在下載客戶端在起初的
15
分鐘內(nèi)設置
rating
設置到
200
。
1.3.5
????????
到達上載隊列的頂部
當
A
達到
B
上傳隊列的頂部的時候，
B
連接到
A
，執(zhí)行初始化握手以及發(fā)送一個接受上傳請求的報文（
6.4.11
節(jié)）。
A
現(xiàn)在可以選擇繼續(xù)下載請求命令中指定的文件，或者發(fā)送一個取消傳輸?shù)膱笪模?/span>
6.4.12
節(jié)）來取消下載（如果它已經(jīng)從另外一個源得到這個部分）。圖
4.6
解釋這些選項。
圖
4.6
：文件請求繼續(xù)下載
1.4
??????????????????????
數(shù)據(jù)傳輸
1.4.1
????????
數(shù)據(jù)包
發(fā)送和接收文件片是主要的
eMule
網(wǎng)絡活動的主要部分。當所有剩下的
eMule
是控制的時，
eMule
到
FTP
將得到發(fā)送文件和數(shù)據(jù)事物匹配。一個文件片可以是
5000
到
15000
字節(jié)，（依賴于壓縮）。為了避免分片，一個文件片報文在一片中發(fā)送，每個
TCP
的片是單獨的包。在
eMule0.30e
中，最大片大小是
1300
字節(jié)（注意，這僅僅和
TCP
負載有關）。換句話，當每個控制報文在一個單個
TCP
包發(fā)送的時候，有時和其他報文一起，數(shù)據(jù)報文被分割為幾個
TCP
包。第一個包包含發(fā)送文件的信息頭（
6.4.3
節(jié)），其余的包都是數(shù)據(jù)。如果被發(fā)送的文件片不是
1300
的整數(shù)倍，那么這些多余的部分和第一個包一起發(fā)送（攜帶頭的包）。圖
4.7
描述了文件片報文。
圖
4.7
，文件片報文細節(jié)
1.4.2
????????
數(shù)據(jù)傳輸序列
在文件請求響應之后，一部分傳輸序列可以理解開始。下載客戶端
A
發(fā)送一個起始的上傳請求（
6.4.10
節(jié)），
B
以一個接受上傳請求的報文（
6.4.11
節(jié)）響應該報文。在這之后，
A
開始請求文件片（
6.4.4
節(jié)），
B
響應請求的文件片（
6.4.3
節(jié)），注意，單個文件片請求可能請求
3
片，因此每個文件片請求可能有
3
個發(fā)送部分序列來響應。
當兩個支持擴展客戶端協(xié)議的客戶端時，文件片可能是壓縮之后發(fā)送的（
6.5.3
節(jié)）。擴展的文件協(xié)議也支持一個可選文件信息報文（
6.5.5
節(jié)），這個可能在接受上傳請求報文之前發(fā)送。片傳輸報文序列如
4.8
圖所示：
圖
4.8
：文件片交互
1.4.3
????????
選擇下載那一片
eMule
選擇性的選擇片的下載順序，目的是最大化整個網(wǎng)絡的吞吐量和共享。每個文件被分成
9.28MB
字節(jié)片，并且每片被分成
180KB
快。片下載的順序是由請求文件分片的下載客戶端決定。下載客戶端可以在任何給定瞬間從每個源下載一個單個片，以及駐留在同一個片中來自同一個源的所有請求塊。下面原則在下載片時使用（以這個順序）：
1．?
數(shù)據(jù)的可用頻率，非常少的快應該盡量快下載，從而成為新的可用源
2．?
用于預覽的片（第一個
+
最后一個塊），預覽或檢查一個文件（例如：電影、
MP3
）。
3．?
請求狀態(tài)（正在下載中），試著想向每個源詢問另一個塊，在所有源之間廣播請求。
4．?
完成（最短
-
到完成），應該在開始下載另一個塊之前局部地得到塊。
頻繁標準定義
3
個
0
：非常少、少和通常。標準為每個
0
注定權(quán)重，其用來計算片速率。較低速率片首先下載。根據(jù)上面的原則下面的列表指出了文件速率變化的范圍。
l????????
0-9999
未請求和請求的非常稀少的片
l????????
10000-19999
未請求的稀少的和預覽片
l????????
20000-29999
未請求的最完成通用片
l????????
30000-39999
請求的稀少預覽片
l????????
40000-49999
請求的未完成通用片
這個算法通常首先選擇最稀少的片，然而，部分完成的片且接近完成的片可能也會被選擇。對于通用的片，下載會在不同源之間廣播。
1.5
??????????????????????
瀏覽共享文件和文件夾
處理瀏覽對端共享文件和文件夾的有兩個報文流程。第一個是查看共享文件報文（
6.4.21
節(jié)），在握手之后理解發(fā)送。這個報文以查看共享文件答復來響應（
6.4.22
節(jié)）。當響應的客戶端期望隱藏它的共享文件鏈表時，答復包含
0
個文件（而不是發(fā)送一個報文說不能訪問），圖
4.9
描述報文序列。
圖
4.9
：查看文件
第二個報文流程以查看共享文件夾列表的報文開始（
6.4.23
節(jié)），該報文以共享文件夾列表響應（
6.4.24
節(jié)），對于響應中的每個文件夾都會發(fā)送一個瀏覽共享文件夾內(nèi)容的報文（
6.4.25
）。這樣的報文以內(nèi)容列表回復（
6.4.26
節(jié)）。圖
4.10
描述這個報文序列。
一旦接收客戶端被配置為塊共享文件或文件夾請求，它恢復一個詢問共享拒絕的報文，如圖
4.11
所示。
圖
4.10
：查看共享文件或文件夾
圖
4.11
：查看共享拒絕
1.6
??????????????????????
交換片的
hashset
為了能夠片哈希值，
hashset
請求被發(fā)送（
6.4.8
節(jié)），這個請求以一個
hashset
來響應（節(jié)
6.4.9
），其中包含了文件中每個片的
hashset
。圖
4.12
描述這個過程：
圖
4.12
：
hashset
請求
1.7
??????????????????????
得到文件的預覽
客戶端可以請求他的對端來得到一個下載文件的預覽。預覽是程序獨立的，并且根據(jù)文件的類型不同而變化。
eMule0 0.30e
僅僅支持圖像預覽。這個報文交換過程在圖
4.13
中描述，包含兩個報文：預覽請求（
6.5.11
節(jié)）和預覽回復（
6.5.12
節(jié)）。
圖
4.13
：得到文件預覽