電驢協(xié)議的具體分析

1、最主要的參考文本是eMule協(xié)議1.0版，原文地址。分析的流程是簡(jiǎn)要翻譯加上我的思考，我的目標(biāo)不在 于完整的翻譯，想看完整翻譯的可以關(guān)注下p2p分發(fā)引擎研究這個(gè)Blog，他正在翻譯協(xié)議文本。我的思、 考和點(diǎn)評(píng)會(huì)用紅色標(biāo)出。電騾eMule是基于電驢eDonkey協(xié)議的。電騾網(wǎng)絡(luò)是由數(shù)百個(gè)電騾服務(wù)器和數(shù)百萬的電騾客戶端組成的。 客戶端必須連接到服務(wù)器來獲得網(wǎng)絡(luò)服務(wù)，這個(gè)連接要一直保持直到客戶端關(guān)閉。服務(wù)器提供集中的索引 服務(wù)（類同Napster），不同的服務(wù)器之間沒有通訊。每個(gè)電騾客戶端都預(yù)先設(shè)置好了一個(gè)服務(wù)器列表和一個(gè)本地共享文件列表。客戶端通過一個(gè)單一的TCP連 接到電騾服務(wù)器進(jìn)行網(wǎng)絡(luò)登陸，得

2、到想要的文件的信息和可用客戶端的信息。（這樣造成了電騾和電驢都不 能完全去中心化，雖然文件存儲(chǔ)在客戶端上。）電騾客戶端用幾百個(gè)TCP連接與其他的客戶端連接進(jìn)行文 件的上傳和下載。每個(gè)電騾客戶端為它的共享文件維護(hù)一個(gè)上傳隊(duì)列。正在下載的客戶端加入這個(gè)隊(duì)列的 底部，然后逐漸的前進(jìn)，直到他們達(dá)到隊(duì)列的頂端開始下載文件。一個(gè)客戶端可能從多個(gè)其他的電騾客戶 端下載同一個(gè)文件，從不同的客戶端取得不同的部分?？蛻舳艘部梢陨蟼饕粋€(gè)沒有完全下載的文件的部分 數(shù)據(jù)。（文件可以分塊傳輸大大提高了效率，但是也造成了一些問題，比如源提前退出以后，所有的客戶端 都是不完全數(shù)據(jù)的情況。）最終，電騾擴(kuò)展了電驢的能力允許客戶端

3、交換關(guān)于服務(wù)器、其他客戶端和文件的 信息。（這個(gè)能力又開始把中心的意義淡化。）注意，客戶端和服務(wù)器的通信都是基于TCP的。服務(wù)器使用一個(gè)內(nèi)部數(shù)據(jù)庫來保存客戶端和文件的信息。電騾服務(wù)器不保存任何文件，它是文件位置信息 的中心索引。服務(wù)器的另一個(gè)功能，正在受到質(zhì)疑，他將作為通過防火墻連接的客戶端之間的橋梁，這樣 的客戶端不能接受引入的連接。橋接功能大大的增加了服務(wù)器的負(fù)載。（這個(gè)功能讓服務(wù)器承擔(dān)了過分的負(fù) 擔(dān)，大大降低了服務(wù)器的能力，在設(shè)計(jì)中應(yīng)該摒棄，目前應(yīng)用中大部分的服務(wù)器已經(jīng)關(guān)閉了這個(gè)功能，也 就是說兩個(gè)Low id的客戶端是不能傳輸數(shù)據(jù)的。）電騾使用UDP增強(qiáng)客戶端跟服務(wù)器和其他客戶端的通

4、信能力。但是客戶端收發(fā)UDP信息的能力不是客戶端日常操作強(qiáng)制要求的，即使防火墻阻止客戶端收發(fā) UDP信息，客戶端仍能完美的工作。客戶端到服務(wù)器的連接eMule Server圖一電騾網(wǎng)絡(luò)圖客戶端一啟動(dòng)就會(huì)用TCP連接到一個(gè)電騾服務(wù)器。服務(wù)器給客戶端提供一個(gè)客戶端ID,這個(gè)ID僅在客戶 端服務(wù)器連接的生命周期內(nèi)有效（注意如果客戶端是高ID，那么他在所有的服務(wù)器得到的ID都是一樣的， 直到他的IP地址變化為止）。連接建立后，客戶端把它共享的文件列表發(fā)送給服務(wù)器。服務(wù)器把這個(gè)列表 保存在它的內(nèi)部數(shù)據(jù)庫內(nèi)，這個(gè)數(shù)據(jù)庫通常包括了數(shù)十萬可用文件和活動(dòng)客戶端。電騾客戶端也會(huì)發(fā)送它 的下載列表，包含了他想要下載

5、的文件。后面將給出電騾客戶端和服務(wù)器間的TCP信息交換格式細(xì)節(jié)。連接建立以后，電騾服務(wù)器給客戶端發(fā)送一個(gè)列表，這個(gè)列表包括了那些有客戶端需要的文件的客戶端（這 些客戶端叫做源九然后，客戶端就去跟那些有所需文件的客戶端建立連接。注意客戶端服務(wù)器的TCP連接在整個(gè)客戶端會(huì)話過程中都會(huì)保持。初始化握手之后，事務(wù)主要是由用戶活 動(dòng)觸發(fā)的：有時(shí)客戶端發(fā)送一個(gè)文件查找請(qǐng)求給服務(wù)器，服務(wù)器會(huì)返回一個(gè)查找結(jié)果，一個(gè)查找事務(wù)之后 通常是一個(gè)對(duì)指定文件的源查詢，這個(gè)查詢的結(jié)果是一個(gè)可以提供該文件下載的源的列表。電騾客戶端用UDP來跟登錄服務(wù)器以外的服務(wù)器進(jìn)行通信。UDP信息的用途是增加文件搜索能力，源搜 索能力，

6、保持連接?？蛻舳说娇蛻舳酥g的連接電騾客戶端一般是為了下載某個(gè)文件才會(huì)連接到其他的客戶端（也就是源）的。一個(gè)文件會(huì)被分為很多塊。 客戶端會(huì)從多個(gè)客戶端（源）那里下載同一個(gè)文件，從不同的源下載文件的不同部分（這樣不同的部分就 可以同時(shí)被下載，如果源多，下載的效率就會(huì)極高）。當(dāng)兩個(gè)客戶端連接后，他們會(huì)交換容量信息，然后協(xié)商開始下載（或者說是上傳，這取決于視角）的時(shí)間。每 個(gè)客戶端有一個(gè)下載隊(duì)列，用來保存正在等待下載的客戶端的列表。當(dāng)電騾客戶端的下載對(duì)列為空的時(shí)候， 下載請(qǐng)求會(huì)被馬上接受（除非這個(gè)請(qǐng)求者已經(jīng)被屏蔽九如果下載對(duì)列不為空，那么新的下載請(qǐng)求就會(huì)放在 隊(duì)列之中。不會(huì)努力服務(wù)更多的客戶端，對(duì)每

7、個(gè)下載客戶端至少保持不少于2.k字節(jié)/每秒。一個(gè)正在下載 的客戶端的下載地位可能被一個(gè)對(duì)列等級(jí)（queue ranking）比他高的等待客戶端搶占，在下載進(jìn)程中的 前15分鐘正在下載的客戶端的隊(duì)列等級(jí)會(huì)增長(zhǎng)用來避免產(chǎn)生顛簸（這里說的顛簸就是說，一個(gè)客戶端頻 繁的從下載地位切換到等待狀態(tài)，然后再切換回去。這種頻繁的切換叫做顛簸，這對(duì)資源是種浪費(fèi)，所以 要避免。九當(dāng)正在下載的客戶端到達(dá)了下載隊(duì)列的頂部，提供上傳的客戶端初始化一個(gè)連接用于把它需要的文件片斷 傳送給它。一個(gè)電騾客戶端可能會(huì)在多個(gè)源客戶端的等待隊(duì)列中，在每個(gè)客戶端上注冊(cè)要求同一個(gè)文件片 斷。當(dāng)這個(gè)等待客戶端實(shí)際上完成了這個(gè)文件片斷的下載

8、，他不會(huì)通知那些源客戶端刪除它的請(qǐng)求，而僅 僅是在它在那些源客戶端的隊(duì)列中排到頂端的時(shí)候拒絕上傳請(qǐng)求而已。電騾使用一個(gè)聲望系統(tǒng)來鼓勵(lì)上傳，為了防止假冒，電騾用RSA公鑰加密技術(shù)來保護(hù)聲望系統(tǒng)?？蛻舳诉B接中會(huì)使用很多電驢協(xié)議（eDonkey protocol）沒有定義的消息，這些消息叫做擴(kuò)展協(xié)議。擴(kuò) 展協(xié)議用來實(shí)現(xiàn)信用系統(tǒng)，用來進(jìn)行信息交換（例如，服務(wù)器列表的更新和源的更新）通過對(duì)文件塊進(jìn)行 壓縮提升發(fā)送和接收的效率。電騾客戶端連接中有限地使用UDP去周期其他客戶端的狀態(tài)。客戶端ID客戶端是一個(gè)4字節(jié)的標(biāo)識(shí)符，在跟服務(wù)器連接握手的時(shí)候由服務(wù)器提供的?？蛻舳薎D僅在客戶端服務(wù) 器TCP連接的生命期

9、內(nèi)可用，雖然如果客戶端是高ID （High ID），它在任何服務(wù)器分配的客戶端ID都 一樣，除非IP變化了?？蛻舳薎D分為低ID（low ID）和高ID。電騾服務(wù)器通常會(huì)給不能接受連接的客 戶端分配低ID。擁有低ID會(huì)限制客戶端在電騾網(wǎng)絡(luò)中的使用，甚至?xí)斐煞?wù)器拒絕連接。高ID是由 客戶端的IP地址為基礎(chǔ)算出的。這里從電騾協(xié)議的觀點(diǎn)來看客戶端ID的分配和表示。得到高ID的客戶 端允許其他的客戶端自由地連接他的電騾TCP端口（默認(rèn)為4662）。得到高ID的客戶端在電騾網(wǎng)絡(luò)內(nèi)不 受任何限制。當(dāng)服務(wù)器不能打開一個(gè)連往客戶端的電騾端口的連接時(shí)，服務(wù)器給客戶端一個(gè)低ID。這主要 是客戶端安裝了防火墻組

10、織外來連接造成的。以下情況下，客戶端會(huì)得到低ID：當(dāng)客戶端通過NAT或者代理服務(wù)器上網(wǎng)。當(dāng)服務(wù)器正在忙（造成服務(wù)器的連接計(jì)數(shù)器超時(shí)，從而認(rèn)為客戶端無法連接）。高ID通過下面的方法計(jì)算：假設(shè)機(jī)器IP地址為X.Y.Z.W，客戶端ID應(yīng)該為X+28*Y+216*Z+224*W （big endian高位在前）。低ID總是小于15777216（0 x1000000）我不知道它是怎么計(jì)算的（協(xié)議原文 如此，看來低ID的算法并不重要，只要滿足條件即可。），注意從不同的服務(wù)器得到的低ID是不一樣的。低ID的客戶端沒有公開的IP地址供其他的客戶端連接，所以所有的通信必須通過電騾服務(wù)器。這會(huì)造成 服務(wù)器的負(fù)載提

11、升，所以服務(wù)器不愿意接受低ID的客戶端。同樣，這說明低ID的客戶端不能跟其他服務(wù) 器上面的低ID客戶端連接，因?yàn)殡婒叢恢С址?wù)器間的橋接。為了支持低ID客戶端電騾協(xié)議引入了回調(diào)機(jī)制。使用這種機(jī)制，一個(gè)高ID客戶段可以要求（通過服務(wù)器） 低ID客戶端連接它來交換文件?，F(xiàn)在大部分服務(wù)器不會(huì)拒絕低ID的客戶端連接，因?yàn)樗麄兓旧隙疾粠椭蛻舳藗鬏斘募?。由此?低ID的客戶端之間也無法傳輸了。用戶ID電騾支持聲望系統(tǒng)為了增加用戶的文件共享。一個(gè)用戶上傳給其他客戶端越多東西，它就得到越多的聲望， 這樣它在他們的等待隊(duì)列中前進(jìn)就會(huì)越快。用戶ID是一個(gè)128位（16字節(jié)）GUID，通過連接隨機(jī)數(shù)而 產(chǎn)生，

12、第6和第15位不是隨機(jī)生成的，他們分別是14和111。用戶ID僅在客戶端和服務(wù)器會(huì)話中有效， 用戶ID是唯一的用來標(biāo)識(shí)客戶端。用戶ID在聲望系統(tǒng)里面起了很大的作用，攻擊者冒充其他用戶就是為 了得到它們聲望對(duì)應(yīng)的權(quán)利。電騾提供了加密方案用來用戶欺詐。實(shí)現(xiàn)方式是用RSA方法來加密方法來加 密信息交換。文件ID文件ID用于網(wǎng)絡(luò)中文件的唯一標(biāo)識(shí)，以及文件損壞的檢測(cè)和修復(fù)。注意電騾對(duì)文件進(jìn)行唯一標(biāo)識(shí)和編目 不依賴于文件名，文件由其內(nèi)容哈希計(jì)算出來的全局唯一 ID來標(biāo)識(shí)。文件ID有兩種，一種用來生成唯一 標(biāo)識(shí)，一種用于文件損壞的檢測(cè)和修復(fù)。文件哈希文件是用一個(gè)128位的GUID來標(biāo)識(shí)的，這個(gè)GUID是由客

13、戶端用文件內(nèi)容哈希計(jì)算出來的。GUID使 用MD4算法計(jì)算。計(jì)算文件ID的時(shí)候文件被分成9.28MB的大小。一個(gè)GUID是分別計(jì)算每個(gè)文件塊 的哈希，然后把它們合成為一個(gè)唯一文件ID。下載客戶端完成文件塊的下載后，會(huì)計(jì)算塊的哈希和文件上 傳端發(fā)送來的文件塊哈希做比較，如果不同，就說明文件塊損壞了，客戶端將逐塊的覆蓋（一次180kb） 知道哈希計(jì)算表明文件塊已經(jīng)修復(fù)為止。根哈希根哈希是每個(gè)文件塊用SHA1算法計(jì)算出來的，每個(gè)計(jì)算單元尺寸為180kb。它提供了更高級(jí)別的可靠性 和錯(cuò)誤恢復(fù)。電騾協(xié)議拓展雖然電騾（eMule）完全兼容電驢（eDonkey），但是它還是實(shí)現(xiàn)了一些擴(kuò)展，用于增強(qiáng)它的功能。

14、擴(kuò)展 關(guān)注于客戶端和客戶端之間的通信，特別是安全領(lǐng)域和UDP工具。軟件和硬件限制服務(wù)器設(shè)定包括兩種對(duì)活躍用戶數(shù)目的限制，軟件的和硬件的。硬件限制大于等于軟件限制。當(dāng)活躍用戶 數(shù)目到達(dá)了軟件限制，服務(wù)器停止接受新的低ID客戶端連接，當(dāng)用戶數(shù)目達(dá)到了硬件限制，服務(wù)器不會(huì) 接受任何連接。2 客戶端服務(wù)器的TCP交流每個(gè)客戶端用TCP精確地連接到一個(gè)服務(wù)器。服務(wù)器分配給客戶端一個(gè)ID,在與服務(wù)器其余的會(huì)話中標(biāo)識(shí) 該客戶端（高ID客戶端總是根據(jù)它的IP地址分配）。eMule GUI客戶端需要建立一個(gè)服務(wù)器連接來用于 操作。客戶端不能同時(shí)與幾個(gè)服務(wù)器連接，也不能在沒有用戶干涉的情況下動(dòng)態(tài)更換服務(wù)器。2.1

15、 建立連接 在準(zhǔn)備建立與服務(wù)器的連接時(shí)，客戶端會(huì)嘗試并行地連接到幾個(gè)服務(wù)器，根據(jù)成功的登陸順序放棄其他的。有下面幾個(gè)可能的連接建立個(gè)案：1、高ID連接-服務(wù)器分配一個(gè)高ID給正在連接的客戶端2、低ID連接-服務(wù)器分配一個(gè)低ID給正在連接的客戶端3、拒絕會(huì)話-服務(wù)器拒絕客戶端當(dāng)然，也有不重要的個(gè)案-服務(wù)器崩潰或者不可連接。ClientServer城虹-owmecLac- .jaonneclg - -皿偵8 inrQ-Moanssr ._ Discoo01 -Endtime二 圖2.1描述了導(dǎo)致高ID連接的信息順序。在這種情況下，客戶端建立一個(gè)TCP連接到服務(wù)器，然后發(fā)送 一個(gè)登錄信息到服務(wù)器。服

16、務(wù)器用另一個(gè)TCP連接到客戶端，執(zhí)行一個(gè)客戶端-客戶端的握手來保證連接 的客戶端有能力接收來自其他eMule客戶端的連接。在完成客戶端握手后，服務(wù)器關(guān)閉第二個(gè)連接，通過 發(fā)送ID更改信息來完成客戶端-服務(wù)器的握手。你可能注意到eMule信息消息是灰色的。這是因?yàn)檫@個(gè)消 息是eMule協(xié)議擴(kuò)展的一個(gè)部分（1.6節(jié)）圖2.2描述了導(dǎo)致低ID連接的信息順序。在這種情況下，服務(wù)器不能連接到發(fā)送請(qǐng)求的客戶端，分配一 個(gè)低ID給客戶端。服務(wù)器消息一般包含警告信息，就像警告服務(wù)器細(xì)節(jié)-你是低ID。請(qǐng)察看你的網(wǎng) 絡(luò)配置和/或你的設(shè)置”低ID和高ID握手都是通過隨著ID更改消息完成的，這個(gè)ID更改消息分配客戶

17、端一個(gè)客戶端ID，用在與服務(wù)器的下一個(gè)會(huì)話。ClientServersurt - - Goonect （TCP）H-_,saver message -disconO*cUEnack sequence也有允許兩個(gè)低ID客戶端交換文件的能力，通過它們的服務(wù)器連接，用服務(wù)器接力。大部分服務(wù)器不再 提供這個(gè)選項(xiàng)，因?yàn)樗兄路?wù)器的負(fù)擔(dān)。3客戶端服務(wù)器的UDP交流eMule客戶端和服務(wù)器用不可靠的UDP服務(wù)來保持連接和增強(qiáng)搜索eMule客戶端產(chǎn)生UDP包的總量可 以達(dá)到它發(fā)送包的總數(shù)目的5%-這些根據(jù)客戶端服務(wù)器列表中服務(wù)器的數(shù)目，客戶端下載列表中每個(gè)文 件的源數(shù)目和用戶執(zhí)行的搜索數(shù)目而定。UDP包通過

18、計(jì)時(shí)器觸發(fā)，計(jì)時(shí)器每100ms過期，有一個(gè)單獨(dú)的 線程負(fù)責(zé)發(fā)送UDP輸送結(jié)果，以每秒10個(gè)UDP的最大速率。3.1服務(wù)器保持連接和狀態(tài)信息客戶端周期性驗(yàn)證它服務(wù)器列表中的服務(wù)器狀態(tài)。驗(yàn)證是通過發(fā)送UDP服務(wù)器狀態(tài)請(qǐng)求（見6.3.3節(jié)） 和UDP服務(wù)器描述請(qǐng)求（見6.3.7節(jié)）消息完成的。這里描述的簡(jiǎn)單保持連接計(jì)劃每小時(shí)產(chǎn)生不超過幾 打包。任何情況下，包的最大速率是每秒0.2個(gè)包（或每5秒一個(gè)包）。當(dāng)檢查服務(wù)器的狀態(tài)時(shí)，客戶端 會(huì)首先發(fā)送一個(gè)服務(wù)器狀態(tài)請(qǐng)求消息，接著，每?jī)纱卧噲D（發(fā)送一個(gè)服務(wù)器狀態(tài)請(qǐng)求）中就發(fā)送一次服務(wù) 器描述請(qǐng)求，見圖3.1。ClientServerClienthour 0ho

19、ur 0Figure 3.1: UDP Keep alive cycle客戶端發(fā)送的服務(wù)器狀態(tài)請(qǐng)求中包括一個(gè)隨機(jī)數(shù)字，在服務(wù)器回應(yīng)中返回。在服務(wù)器返回的數(shù)字與客戶端 發(fā)送的要求中數(shù)字不同的情況下，回應(yīng)的信息就會(huì)被丟棄。每次發(fā)送到服務(wù)器的包是狀態(tài)請(qǐng)求，客戶端就 移動(dòng)嘗試計(jì)數(shù)器。任何來自服務(wù)器的消息（包括搜索結(jié)果）都重置嘗試計(jì)數(shù)器。當(dāng)嘗試計(jì)數(shù)器達(dá)到一個(gè)可 配置的限制時(shí)，服務(wù)器就認(rèn)為是死機(jī)，從客戶端的服務(wù)器列表中刪除。服務(wù)器回應(yīng)包括幾個(gè)數(shù)據(jù)項(xiàng)：服務(wù) 器狀態(tài)回應(yīng)（見6.3.4）包括服務(wù)器中當(dāng)前用戶數(shù)目和文件數(shù)目，也包括服務(wù)器的軟件和硬件限制（見1.7 節(jié)九服務(wù)器描述回應(yīng)（見6.3.8節(jié)）包括服務(wù)器名稱

20、和一個(gè)短的描述字符串。圖3.2演示了客戶端和活 動(dòng)服務(wù)器中滿連接序列的消息流。3.2增強(qiáng)文件搜索eMule客戶端可以設(shè)置用UDP來增強(qiáng)它的文件搜索。UDP搜索結(jié)果格式幾乎與？節(jié)描述的TCP搜索請(qǐng) 求一樣。服務(wù)器只在有了搜索結(jié)果才回應(yīng)。UDP搜索結(jié)果消息有兩種不同的opcdes，我也無法說清它們 之間的不同。UDP搜索包發(fā)送到客戶端服務(wù)器列表中的服務(wù)器上。更多信息見6.3.5節(jié)和6.3.6節(jié)。3.3增強(qiáng)文件源搜索當(dāng)客戶端下載列表中的特定文件的源數(shù)目小于配置限制（100）時(shí)，客戶端就周期性地發(fā)送獲取源的UDP 包到它的服務(wù)器列表中的服務(wù)器中為該文件尋找更多的源。可能每秒發(fā)送一個(gè)包，使得源搜索在客戶

21、端產(chǎn) 生的UDP輸送中成為可觀的部分。消息的格式（6.3.1節(jié)描述）非常相似它的TCP計(jì)數(shù)器部分。注意， 與TCP源搜索相反，UDP源搜索在文件搜索中減弱，對(duì)于指定的文件，只是依靠客戶端擁有的源數(shù)目。4客戶端到客戶端的TCP交流在eMule客戶端注冊(cè)到服務(wù)器和向服務(wù)器查詢文件和源之后，為了下載文件，eMule客戶端需要聯(lián)系其它 客戶端。為每對(duì)文件，客戶端創(chuàng)建一個(gè)專用的TCP連接。當(dāng)特定的周期內(nèi)（默認(rèn)40秒）沒有任何socket 活動(dòng)或者對(duì)方已經(jīng)關(guān)閉了這個(gè)連接，那么這個(gè)連接就會(huì)關(guān)閉。為了提供合理的下載速率，直到可能提供給它（和所有其它下載的客戶端）至少最小允許速率（當(dāng)前的硬 編碼常量設(shè)置為2.4

22、k/s），eMule才允許客戶端開始下載文件。4.1初始的握手初始的握手是對(duì)稱的-雙方都相互發(fā)送相同的信息給對(duì)方。客戶端交換雙方的信息，信息包括身份認(rèn)證、 版本和容量等。參與的有兩種類型消息-Hello消息（6.4.1節(jié)）和eMule信息消息（6.5.1節(jié)），第一 種是eDonkey的一部分，兼容eDonkey客戶端，第二種是eMule獨(dú)有的擴(kuò)展客戶端協(xié)議的一部分。圖 4.1圖解了兩個(gè)eMule客戶端之間的握手。在擴(kuò)展信息中包含的有UDP消息交換、安全身份證明和源交換能力。4.2安全的用戶身份認(rèn)證1.4節(jié)簡(jiǎn)單解釋了關(guān)于用戶ID和用戶假冒其它用戶的動(dòng)機(jī)。安全用戶認(rèn)證是eMule擴(kuò)展的一部分。如果

23、 客戶端支持安全認(rèn)證，就會(huì)在初始化握手之后立即執(zhí)行。安全認(rèn)證的目的是防止用戶冒名頂替。當(dāng)實(shí)施安 全認(rèn)證時(shí)，執(zhí)行以下步驟：在初始化握手中，B客戶端指明它支持和希望使用安全認(rèn)證。通過發(fā)送安全認(rèn)證消息（見6.5.8）來回應(yīng)，指明A是否需要B的公匙，也包含了 B發(fā)出的4字節(jié)的詢 問。如果A指明它需要B的公匙，B就將它的公匙發(fā)送給A（6.5.9節(jié)）。B發(fā)送一個(gè)簽名消息（6.5.10節(jié)），簽名消息是用發(fā)送過來的詢問和額外的雙字節(jié)創(chuàng)建的，雙字節(jié)要么 是A的IP地址如果B是低ID，要么是B的ID如果它有高ID。圖4.2演示了這個(gè)順序。4.2.1信用系統(tǒng)本節(jié)簡(jiǎn)要地描述了客戶端的信用系統(tǒng)。信用系統(tǒng)的目的是鼓勵(lì)用戶

24、共享文件。當(dāng)客戶端上傳文件給它的對(duì) 方，下載的客戶端就根據(jù)數(shù)據(jù)傳輸?shù)臄?shù)量來更新它的信用。注意，信用系統(tǒng)不是全局的-傳輸?shù)男庞帽幌?載的客戶端局部保存，只有當(dāng)上傳的客戶端（獲得信用的那個(gè)）要求從這個(gè)特定的客戶端下載時(shí)，信用才 會(huì)被考慮。信用是用下面最小值計(jì)算的：上傳的總量* 2 /下載的總量當(dāng)下載的總量是零時(shí)，這個(gè)表達(dá)式估值是10上傳的總量+ 2的和開方當(dāng)上傳的總量小于1MB，這個(gè)表達(dá)式估值是1 上傳/下載數(shù)量是以M為單位計(jì)算。任何情況下，信用不會(huì)高過10或者低于1。4.3請(qǐng)求文件正如已經(jīng)提到的一樣，每對(duì)客戶端，文件都創(chuàng)建一個(gè)獨(dú)立的連接。在連接建立之后，客戶端立即發(fā)送幾 個(gè)關(guān)于它希望下載的文件的

25、請(qǐng)求消息。4.3節(jié)描述了一個(gè)典型的、成功的情景。4.3.1基本消息交換基本消息交換是由四個(gè)消息構(gòu)成：A發(fā)送一個(gè)文件請(qǐng)求消息，立即跟著的是請(qǐng)求文件ID消息（6.4.17節(jié)）。 B用文件請(qǐng)求回答回應(yīng)文件請(qǐng)求，用文件狀態(tài)（6.4.18節(jié)）來回應(yīng)請(qǐng)求文件的ID消息。我找不到任何理 由來把這些發(fā)送過來的消息中的信息分成四個(gè)消息，它可以容易地用兩個(gè)消息（請(qǐng)求和回應(yīng)）來處理。擴(kuò)展協(xié)議增加兩個(gè)消息到這個(gè)順序中，源請(qǐng)求消息（6.5.6節(jié)）和源回應(yīng)消息（6.5.7節(jié)九用這個(gè)擴(kuò)展來 傳遞B的源（假定B當(dāng)前下載著文件）到A中。詳細(xì)闡述就是，在它能發(fā)送文件塊給其它客戶端之前B 完成下載一個(gè)文件是沒有任何要求的，B可以發(fā)

26、送任何它已經(jīng)完成下載的文件塊，甚至當(dāng)它只是用文件的 一小塊。4.3.2沒找到文件的情景當(dāng)A向B請(qǐng)求一個(gè)文件，但是B的共享文件列表中沒有這個(gè)文件。B忽略這個(gè)文件請(qǐng)求回應(yīng)消息，在請(qǐng)求 文件ID消息之后立即發(fā)送一個(gè)沒有文件消息（6.4.16節(jié)），如圖4.4所演示。4.3.3加入上傳隊(duì)列當(dāng)B有被請(qǐng)求的文件但是它上傳隊(duì)列不為空，意味著有正在下載文件的客戶端，也可能有客戶端在上傳列 表中，在這種情況下，A和B執(zhí)行滿握手，如圖4.3所述，但是當(dāng)A請(qǐng)求B開始下載文件時(shí)，B把A加 入到它的上傳隊(duì)列中，回應(yīng)一個(gè)隊(duì)列等級(jí)消息，這個(gè)消息包含A在B地上傳隊(duì)列中的位置。圖4.5演示了 這個(gè)順序。Client BClien

27、t BStart timeFlie 伽 gg傍亦四 Connection doseEnd time ,Figure 4.5: File request waiting queue4.3.4上傳對(duì)列管理對(duì)每個(gè)上傳的文件，客戶端維護(hù)著一個(gè)上傳優(yōu)先級(jí)隊(duì)列。隊(duì)列中的每個(gè)客戶端的優(yōu)先級(jí)是以客戶端在隊(duì)列 中的時(shí)間和優(yōu)先級(jí)修正為基礎(chǔ)計(jì)算的。位于隊(duì)列頭部的客戶端有一個(gè)最高級(jí)別的分?jǐn)?shù)。分?jǐn)?shù)是用以下的方 程式計(jì)算的：分?jǐn)?shù)=（等級(jí)*隊(duì)列中的秒數(shù)）/100或者無窮大，如果下載的客戶端被定義為朋友。初 始化的等級(jí)值是100，除開禁止的用戶是0等級(jí)（這樣阻止達(dá)到隊(duì)列的前面）外。等級(jí)可以被下載客戶端 的信用（范圍1-10）

28、或上傳文件優(yōu)先級(jí)（0.2-1.8）修改，上傳文件優(yōu)先級(jí)是由上傳客戶端設(shè)置的。當(dāng)一 個(gè)客戶端的分?jǐn)?shù)比其它的客戶端高時(shí)，它就開始下載文件?？蛻舳丝梢岳^續(xù)下載文件直到產(chǎn)生以下任一個(gè) 條件：用戶關(guān)閉了上傳客戶端。下載的客戶端得到了它所需文件的所有部分。下載的客戶端給其它擁有比它更高優(yōu)先級(jí)的客戶端搶占。為了允許一個(gè)剛剛開始的客戶端在它被搶占之前可以得到幾M的數(shù)據(jù)，eMule在客戶端下載的前15鐘內(nèi) 增加初始等級(jí)到200。4.3.5到達(dá)上傳隊(duì)列的頂部當(dāng)A到達(dá)B上傳隊(duì)列的頂部時(shí)，B連接A，執(zhí)行初始握手，然后發(fā)送一個(gè)接收上傳請(qǐng)求消息（6.4.11節(jié)）。 A現(xiàn)在可以選擇要么發(fā)送請(qǐng)求塊消息來繼續(xù)下載文件，要么發(fā)送

29、取消傳輸消息來取消（如果它已經(jīng)從別的 源得到了這一塊九圖4.6演示了這些選擇。OMotACIntB CbMtACtentB_ Counts - -ConnecthMdsitake.IruM handshaka4Scur Idemupload B09、Secure Ident uploadQuastpaCancel tramihr1x4 tn* , Entftm ,Figure I 6 File request resume download4.4數(shù)據(jù)傳輸4.4.1數(shù)據(jù)包發(fā)送和接收文件塊是eMule網(wǎng)絡(luò)活動(dòng)的主要部分。用FTP解釋eMule可以推論出，當(dāng)所有其它eMule 可以控制，發(fā)送的文件塊

30、適合數(shù)據(jù)傳輸。發(fā)送的文件塊大小可以是在5000到15000位（也根據(jù)壓縮） 范圍內(nèi)。為了避免出錯(cuò)，文件塊消息在碎片中發(fā)送，每碎片在一個(gè)獨(dú)立的TCP包中。在eMule 0.30e版 中，最大的碎片大小是1300位（注意，這個(gè)數(shù)字只與TCP有效負(fù)載有關(guān)）。換句話說，當(dāng)每個(gè)控制消息 在單獨(dú)的TCP包中發(fā)送，有時(shí)和其它消息共享，數(shù)據(jù)消息被分成幾個(gè)TCP包。第一個(gè)包包含發(fā)送文件塊 消息頭部（6.4.3節(jié)）。剩下的包值包含數(shù)據(jù)。當(dāng)被分成1300，如果發(fā)送塊的大小有剩余，和第一個(gè)包（這 個(gè)包帶有頭部）一起發(fā)送。圖4.7演示了文件塊消息。4.4.2數(shù)據(jù)傳輸順序在文件請(qǐng)求回應(yīng)之后立即開始?jí)K傳輸順序。下載客戶端A

31、發(fā)送一個(gè)開始上傳請(qǐng)求（6.4.10節(jié)），然后一個(gè) 接收上傳請(qǐng)求消息（6.4.11節(jié)）回應(yīng)這個(gè)請(qǐng)求。A在這之后立即開始請(qǐng)求文件塊（6.4.4節(jié)），B通過發(fā) 送被請(qǐng)求塊（6.4.3節(jié)）來回應(yīng)。注意，單獨(dú)的文件塊請(qǐng)求可能請(qǐng)求可達(dá)3塊之多，所以每個(gè)文件塊請(qǐng)求 可能被可達(dá)3個(gè)發(fā)送的塊順序回應(yīng)。當(dāng)兩個(gè)客戶端都支持?jǐn)U展的客戶端協(xié)議，文件塊可能壓縮發(fā)送。擴(kuò)展協(xié)議也支持可選的文件信息消息（6.5.5 節(jié)），該消息就在接收上傳請(qǐng)求消息之前發(fā)送。圖4.8演示了塊傳輸消息順序。Clwnt ACiwnt BStart Im FrtB rSQM* 叩*1SerKUny W:Serunngpw1Mon*Figure 4 8

32、 Fite part exchange4.4.3選擇塊下載為了最大化整個(gè)網(wǎng)絡(luò)的吞吐量和共享，eMule仔細(xì)挑選選擇塊的下載順序。每個(gè)文件被分成9.28M的塊，每部分分成180KB的片。塊下載的順序是由發(fā)送請(qǐng)求文件塊消息（6.4.4節(jié)）的下載客戶端決定。下載客戶端可以在任何給定時(shí)刻從各個(gè)源中下載一個(gè)單獨(dú)的文件塊，所有從相同源中請(qǐng)求的片都在同一個(gè)塊中。下面的原理（以這個(gè)順序） 應(yīng)用于下載塊等級(jí)：（可獲得的）大片的頻率，盡可能快的下載非常稀少的大片來形成一個(gè)新的源。用來預(yù)覽的塊（最初+最后的大片），預(yù)覽或檢查文件（比如，電影、mp3）請(qǐng)求狀態(tài)（過程中下載），嘗試向每個(gè)源詢問其它的大片。在所有源之間擴(kuò)

33、散請(qǐng)求。完成（未到某種程度的完成），在開始下載另一個(gè)時(shí)應(yīng)該完成獲得部分的大片頻率標(biāo)準(zhǔn)定義了三個(gè)區(qū)域：非常稀少、稀少和一般。在每個(gè)區(qū)域里，標(biāo)準(zhǔn)有特定的權(quán)重，用來計(jì)算塊等級(jí)。較低等級(jí)的塊先下載。下面的列表根據(jù)上面的原理指定文件等級(jí)范圍：l 0-9999 -不請(qǐng)求和請(qǐng)求非常稀少的塊l10000-19999-不請(qǐng)求稀少和預(yù)覽塊l20000-29999-不請(qǐng)求大部分完成的一般的塊l30000-39999-請(qǐng)求的稀少和預(yù)覽的塊l40000-49999-請(qǐng)求的沒有完成的一般的塊這個(gè)算法通常選擇第一個(gè)最稀少的塊。然而，部分完成的塊，接近完成的，也可能被選中。對(duì)于一般的塊， 在不同的源之間擴(kuò)散下載。4.5瀏覽共享的文件和文件夾有兩個(gè)消息流程來處理每對(duì)客戶端之間的共享文件和文件夾的瀏覽。第一個(gè)是瀏覽共享文件消息（6.4.21 節(jié)），該消息在初始握手后立即發(fā)送。通常由一個(gè)瀏覽共享文件回應(yīng)消息（6.4.22）來回應(yīng)這個(gè)消息。當(dāng) 回應(yīng)的客戶端想隱藏它的共享文件列表時(shí)，回應(yīng)就包含零個(gè)文件（而不是發(fā)送一個(gè)指示訪問拒絕的消息）。 圖4.9演示了這個(gè)消息順序。Ghent ACIM BIfggadfiiej 射E，8*80*，F(xiàn)igiirr 4.9 Vbrw diMcwl Blm第二個(gè)消息流程隨著一個(gè)瀏覽共享的文件夾列（6.4.23節(jié)）表請(qǐng)求開始，通過共享