目錄
1 簡介
1.1 目的和範圍
eMule是一個在eDonkey協議基礎上建立起來的文件共享系統。這篇文檔描述了eMule的網絡行爲，對基本的術語進行了解釋，有助於大家理解協議。這篇文檔也提供了eMule網絡協議的完整的規格書，在附錄中包含了所有消息的格式。文檔中的信息來源於開放源代碼的eMule客戶端[2]。以下介紹文檔的目的是爲讀者提供一個整體的背景以便讀者閱讀和理解這篇文檔。有關eMule的更深入信息可以在這裏找到[3]。
1.2 概覽
eMule網絡由上百個eMule服務器和數以百萬計的eMule客戶端組成[1]。客戶端爲了得到網絡服務必須連接到一個服務器，只要客戶端在系統內，它到服務器的連接就一直打開。服務器提供一個集中的目錄服務(類似於Napster)，並且服務器不與其他服務器通訊。
每個eMule客戶端都預先配置了一張服務器列表，和一個本地文件系統上的共享文件的列表。客戶端用一條TCP連接連到eMule服務器，進行網絡註冊，獲取請求的文件和可用的客戶端的信息。eMule客戶端還會使用上百條TCP連接與其他的客戶端來上傳和下載文件。
eMule客戶端會爲他每個共享文件的維護一個上傳隊列。需要下載的客戶端加入到這個隊列的底部，然後逐漸向頂部移動，直到他到達隊列頂部，然後開始下載文件。一個客戶端可以從多個其它客戶端獲取不同的數據片來下載同一個文件。客戶端也可以上傳多一個文件的多個數據塊，即使這個文件還沒有下載完成。最終，eMule拓展了eDonkey的能力，eMule允許客戶端之間交換服務器，其他客戶端和共享文件的信息。注意客戶端以及服務器的通信都是基於TCP的。服務器用一個內部的數據庫儲存客戶端和共享文件的信息。eMule服務器不存儲任何文件，它只充當一個集中的索引來存儲文件的位置。服務器還有一個附加的功能，橋接那些在防火牆之後不能接受連接的客戶端，不過這個功能正被逐漸地淘汰掉，因爲橋接工給服務器增加了相當多的負載。eMule用UDP增強了客戶端對服務器和其他客戶端的連接能力。客戶端發送和接收UDP消息的能力對它正確的完成日常操作並不是必需的，它應該能夠正確的工作即使防火牆阻止UDP消息的發送和接收。
1.2.1 客戶端到服務器的連接
只要客戶端一啓動，就會和一臺eMule服務器建立TCP連接。服務器爲客戶端分配一個客戶ID, 這個ID只在客戶端-服務器連接的生命週期中有效（注意：如果客戶端獲得的是高ID,那麼無論它連接到任何服務器，都會獲得同樣的ID，除非它的IP地址變化了）。連接建立以後，客戶端向服務器發送它的共享文件列表。服務器將列表存放的他的內部數據庫中，通常這個數據庫會存儲數以百萬計的可用文件和客戶端信息。eMule客戶端還會發送它的下載列表，其中包含了他想要下載的文件信息。第二章對eMule客戶端和服務器間的TCP消息交換作了詳細的描述。
當連接建立以後，eMule服務器向客戶端發送一個列表，裏面包含了擁有它需要下載的文件的那些客戶端的信息（那些客戶端被稱爲”源”）。從這裏開始，eMule客戶端開始和其他客戶端建立連接，將會在1.2.2中介紹。
注意：在整個客戶端的會話中，客戶端與服務器的TCP連接一直保持打開。在初始的握手以後，大部分事務是由用戶事件(user activity)發起：時不時地客戶端會發送文件查找請求，然後接收到一個查找結果應答。一般來說在一個查找事務之後，會是一個針對某個特定文件
的”源”的查詢, 應答是一個源（IP和端口）的列表，發送請求客戶端就可以從中下載文件了。
UDP是客戶端用來與服務器通訊的，服務器無需向正與它連接的客戶端UDP通訊。UDP消息增強了文件查詢和源查詢的功能，同時提供保持在線（keep alive）功能（確保客戶端的服務器列表中的服務器是有效的）。關於客戶端與服務器的UDP消息交換的詳細描述可以在第3章找到。
1.2.2 客戶端到客戶端的連接
爲了下載某個文件，一個eMule客戶端連接到另一個eMule客戶端（一個源）。一個文件被分爲多個部分，而每個部分又被進一步分塊。一個客戶端在下載同一個文件時，會從多個不同的其他客戶端獲取不同的文件塊。
當兩個客戶端連接以後，它們交換能力信息，然後協商開始下載（另一方是上傳）。每個客戶端有一個下載隊列，存放着正在等待下載文件的客戶端列表。當eMule客戶端的下載列表爲空的時候，一個下載請求引起下載的開始（除非，舉例說，這個請求是被禁止的）。當下載列表不爲空的時候，一個下載請求使得請求的客戶端被加到下載隊列中去。客戶端至少爲每個下載者提供2.4kbytes/sec的下載服務，否則不會提供新服務。正在下載的客戶端可能會被比它的隊列優先級高的在等待的客戶端擠掉。在下載會話的最初15分鐘，正在下載的eMule客戶端的隊列優先級會提高，以阻止被擠掉。
