一.概述

Emule是建立在p2p技術上的文件共享軟件。它與傳統文件共享的區別是：

共享文件不是在集中的服務器上等待用戶端來下載，而是分散在所有參與者的硬盤上。所有參與者組成一個虛擬網絡，每個用戶端都可以從這個虛擬網絡里的任何一個客戶端的機器里下載文件。同時每個客戶也可以把自己的文件共享給任何其他客戶。 在Emule體系里有一些服務器，不過這些服務器不再存放文件，而是存放這些共享文件的目錄或地址。每個用戶端從服務器處得到或搜索到共享文件的地址，然后自動從別的客戶端處進行下載，參與的客戶端越多，下載的速度越快。Emule建立于多點文件傳輸協議之上。一個Emule網絡由服務器端和客戶端兩部分組成。服務器端是客戶端連接的、為了搜索和查找可以下載用戶的橋梁。服務器列表像電話本一樣排列，客戶通過瀏覽它而獲取它需要的文件所有者的客戶端信息。在真正的文件下載過程中，沒有下載文件通過服務器端。其體系結構如下圖所示：

圖1 Emule體系結構

Searching：每一個客戶端連接到一個服務器作為他的主服務器。在連接時，由客戶端告訴主服務器他share了那些文件，以及IP地址等其他信息。所以每一個服務器會記錄所有登陸到他服務器上的以上信息。在本服務器搜索時，它會通過匹配記錄的已知以上信息把查找結果反饋給搜索的客戶端。當一個客戶在搜索列表中選取了所需要的文件并開始下載后，Emule會記錄下這個文件的大小，文件名以及另一個根據文件內容hash出的一個特殊值。Emule得到了這個信息后，會向所有添加的服務器發出請求，要求得到有相同hash值的文件。而服務器則返回持有這個文件的用戶信息。

Downloading：當客戶端選擇了一個文件下載時，它首先收集一個擁有該文檔的客戶端的列表。它會先行查詢主服務器所有登陸用戶他們是否擁有該文件。然后再連接和查選其他服務器的登陸用戶所擁有該文件的客戶端列表。一旦它找到擁有該文件的其他客戶端，它將請求每個客戶端發送這個文件的不同片。直至最后文件由這個不同的片組裝成一個完整的文件。 在查找到下載源(其他客戶端)后，下載就是客戶端和客戶端通過P2P進行直接對話了。期間沒有數據流通過服務器。一個emule client可能會使用很多的tcp連接與其他client連接來彼此上傳或下載數據.當下載一個文件時,client可能同時連接上許多不同的client,從它們那里獲得該文件的不同片段.即使一個client沒有下載完一個文件,他也能在下載的同時將已下載部分的片斷upload給其他client.emule中的server使用一個內置的數據庫來存儲clients及其擁有文件的信息,它本身并不存放要下載或上傳的文件,而是對clients擁有的眾多文件起一個中央索引定位的作用.

二 .Client/Server TCP communication

2．1 Connection establishment

在Emule體系結構中，一個client只能和一臺server建立連接,建立之后server賦予client一個client id,用于在以后的會話期間唯一的標識這個client. Client/server的這一tcp連接在client的整個會話期間始終存在.Client id分high id 和low id兩種。當一個client不能接受外來連接時,它就被賦予一個low id.一種可能是client在NAT或者proxy server后面.如果一臺機器能讓其他client自由連接它本機的tcp port(default is 4662),那么它就被賦予一個high id.

High id的計算公式：

假設ip為x.y.z.w,

Id=x 2^8*y 2^16*z 2^24*w

而Low id 總是小于16777216(0x1000000)。

下面分別闡述High id和low id的client與server的連接過程：

High id連接過程:

Client建立一個和server的tcp連接,發送login message過去,server使用第二個tcp連接與client進行handshake,其目的是為了檢驗client是否有能力接受其他clients發起的連接.當完成client-to-client握手之后,server關閉第二個連接,再發送個client一個id change 消息來完成client-server handshake.其過程如下圖所示：

圖2 high id login sequence

Low id連接過程：Client同樣與server建立連接,但是當server與client建立連接時將失敗,通常發回給client一個消息,形如”Waring you have a lowed.Please review your network config”.最后server仍舊發送一個id change message.如下圖所示：

圖3 low id login sequence

注意，Emule中的server配置有兩個限制:hard limit和soft limit;

其中Hard limit >= soft limit.當連接一個server的clients 數達到soft limit時,server停止接受low id client的連接;當達到hard limits時,server停止對任何client的連接.此時的連接過程如下圖所示：

圖 4 Reject Session sequence

2.2Connection starup message exchange：

當cs連接成功建立之后,client與server彼此交換一些setup message.client向server提供一個list,記錄了自己shared的文件,然后要求更新server list.于是server發回它的狀態和版本信息,以及自己維護的眾所周知的server list.最后client就會要求下載某些文件,此時server就會查找哪些其他的clients擁有這個被請求的文件,然后將這些clients的列表發回給請求的client.如下圖：

圖3 Connection starup sequence

Callback 機制：

設計這一機制的目的在于克服low id client不能接受外來連接的缺點。其實現原理很簡單：假設a和b連接上同一個server,a需要一個文件,這個文件存放在b上,但b擁有一個low id.于是a發送一個callback request給server,要求server通知b主動連接a..server于是給b發送一個callback request,為其提供了a的ip和port,之后b就能與a建立連接,而不需要server的干預了.

圖4 callback sequence

三. Client/Server UDP communication

3.1 Server keep alive and status information

Client周期性的對自己server list上的server進行狀態檢查.這是通過client發送UDP server status request消息和UDP server description request這兩個消息來完成的. 其中server status request中包括一個隨機數.這個數在server的reply中被回射.倘若回射值與原來的不一致,則server的reply中的信息被丟棄.client維護一個計數器,每次status request發送出去時計數器加一,從server收到的任何消息都重置這個計數器.當這個計數器的值達到一個預先配置的上限時,server被認為不可用,從client的server list中刪除. Server statusrequest的reply包括當前用戶數和server中索引的文件以及server的soft/hard

Limits.而Server description reply包括server name和一個短的描述性字符串。整個過程如下圖所示：

.

圖5 UDP keep alive sequence

3．2 Enhanced File search

Emule的client能使用UDP服務來增強其文件搜索功能。當一個client試圖下載一個文件,但是他得到的sources數目小于一個可配置的值（默認是100）的時候,它就會周期性的向自己server list里的所有server發送UDP get sources packet來試圖找到更多的擁有此文件的sources。

四.Client To Client TCP Communication

在client與server成功建立連接,并且從server那里取得擁有自己想要的文件的sources信息之后,clinet就需要與source列表中其他的client交互，即分別與這些source都建立起一個tcp 連接.當一個連接上在某個時間段內(默認是40秒)之內套接字沒有事件到來(沒有讀或寫)或者任何一個client端關閉了連接時,該tcp連接就失效.

4．1 Initial handshake

這種握手是對稱的:兩端都向對方發送同樣的信息.信息中包括identification,version和capabilities information.發送的信息有兩種類型，一種是hello message，這實際上是eDonkey協議的一部分，另外一種是Emule info message,這部分是Emule協議自己特有的部分。握手過程如圖：

圖6 eMule client initial handshake

4．2 The Credit System

設計Credit system的目的是為了鼓勵用戶彼此共享更多的文件。當一個client為他的peer上傳文件時,正在下載的peer根據接收到的數據量來更新credit值.這個credit并不是全局的.一個特定的傳輸過程對應一個特定的credit值,這個值被正在下載的client保存,只有當為這個client提供上傳的peer轉而要求從client上面下載文件的時候,這個credit才起作用.

Credit取下列值的最小值:

1. uploaded_total*2/downloaded_total

當downloaded_total為0時,整個表達式設為10.

2. sqrt(uploaded_total 2):

當uploaded_total< 1 MB 時,這個表達式設為1.

注意，credit的取值范圍：1<=credit<=10.

4.3 Requesting files

Client A 發送一個file request message,其后緊跟一個requested file id message.Client B

對于這兩個消息的回復如下:前者以一個file request answer消息回復,后者以一個file status message作為應答.該協議還可被擴展為：在這個消息序列中增添兩條新的消息：source request和source answer。通過這兩條消息，就能把B的sources列表發送給A，同時，B也能把自己已經下載了的文件片斷發送給A。如果B并沒有A所請求的文件，B就不發送file request answer消息，取而代之的是file not found message。

圖7 File request failure

4．4 Queue Management

假如Client A向Client B請求一個文件,B擁有,但是其上傳隊列非空,這意味著當前存在其他client已經與Client B握手完畢并正在下載文件,于是B將A加入到它的upload隊列,并返回一個queue ranking message,這條消息內包含了A在B的upload隊列中的位置.

對于upload文件的client B來說,它自己維護一個upload隊列.在隊列中每個client的優先級以client在隊列中的逗留時間及一個優先級變量來決定.在隊列頭的client具有最高的score.score的計算公式：

Score=rating*seconds_in_the_queue/100.

假如該client被定義為friend,則socre為無窮大.Rating一般被初始化為100.

Rating的變動取決于下列情況:

1. 正在下載用戶的 credit值(1~10);

2. 上傳文件的優先級(0.2~1.8)

當隊列中一個client的score超過了某個正在下載的client時，正在下載文件

的client就被搶占。為了避免一個client剛剛開始下載就被別的client所搶占,emule將一個剛開始下載的client的rating設置為200,并維持15分鐘. 當a到達b的upload隊列隊首時,b連接a,進行handshake等初始化工作,然后發送一個accept upload request message.此時a有兩種選擇:或者發送一個request parts message來開始下載文件,或者選擇取消(此時它可能已經在其他sources處下載到了想要的文件片斷).

4．5 Data Transfer

當一個File request answer消息被發送之后，文件塊的傳輸就開始了。試圖下載的Client A發送一個start upload request，而Client B以accept upload request回復。然后A就開始逐一請求文件塊，而B開始發送A所請求的塊。

圖 8 文件傳輸

4．6 塊的選擇策略

在Emule中，每個文件被分成大小為9.28MB的一系列塊，每個塊又被分成180kb大小的子片斷。下載時使用下面的片斷選擇策略：

1．Sources之間擁有的最少的片斷應該盡可能快的下載，這樣一旦下載結束，該client就能成為一個新的可用的source。

2．那些用來預覽的子片斷（比如first，last塊），或者用于文件校驗的塊（如movie，

mp3）。

3．一個塊中如果有部分子片斷被下載,那么其他的子片斷應該盡可能快的被下載,而不是又去挑選一個新的塊來下載

4．7 查看共享文件及文件夾

兩個client之間通過消息傳遞來查看彼此共享的文件和文件夾。對于查看文件，使用view shared files和view shared files answer這對消息來完成。當一個client試圖隱藏自己共享的文件列表時，它發送的view shared file answer消息中包含0個文件，而不是采取發送一個denied消息通知對方這種方式。如圖所示：

圖 9 View shared files

而對于查看文件夾來說，client向另一端發請求以查看共享的文件夾列表，然后收到另一端回復過來的共享文件夾列表。然后對于該回復消息包含的列表中的每一個文件夾，都發送一個view shared folder content消息過去。這個消息的回復是一個content list。

圖10 View shared folders

五．Client To Client UDP Communication

在Emule中，client使用UDP協議周期性地查詢自己在另一端的client的隊列中的位置。其實現方法是用一種簡單的“請求－回復”機制，以一個Re-ask file 消息來初始化。對于這一消息，有三種可能的回復：

1． Queue rank：表明該client在其sender隊列中的位置；

2． Queue Full：表明sender的隊列已滿；

3． File not found：sender并沒有該client請求的文件；

Re-ask消息以20分鐘一次的間隔發送往那些已經將它加入到下載隊列的所有sender去。

圖 11 Re-ask file message

六．Message Encoding

所有的消息都是以little-endian方式編碼.

所有的消息都具有一個6字節的頭部:

頭部結構如下:

1字節的協議id:edonkey為0xe3,emule為0xc5;

4字節的消息大小,該大小不包含頭部,假如消息內不含任何負荷(payload),則該字段為0;

1字節的消息類型字段,是一個獨一無二的消息id.

Message tag:

Tags是一種形如（Type，length，value）的結構，用于給emule 中的各種消息追加一些可選的額外信息.

每個tag有4個域:

1. type:1個字節的整數

2. name:可以是變長的字符串或者1個字節的整數;

3. value:可以是4字節整數或者4字節浮點數或者是可變長的字符串

4. 特別字段域:1字節的整數

希望看了這些介紹之后，大家能對Emul的工作原理有最基本的認識，謝謝。