下載是從服務器到客戶端的一個交流。這也就要用到TCP協議的交流了。那么在eMule協議中是如何規定這樣的交流呢？那么它整個的協議建立流程優勢如何呢？其實并不難于理解，下面我們就來詳細介紹一下。

客戶端服務器的TCP交流

每個客戶端用TCP精確地連接到一個服務器。服務器分配給客戶端一個ID,在與服務器其余 的會話中標識該客戶端（高ID客戶端總是根據它的IP地 址分 配）。eMule GUI客戶端需要建立 一個服務器連接來用于操作。客戶端不能同時與幾個服務器連接，也不能在沒有用戶干涉的 情況下動態更換服務器。

eMule協議建立連接

在準備建立與服務器的連接時，客戶端會嘗試并行地連接到幾個服務器，根據成功的登陸順 序放棄其他的。

有下面幾個可能的連接建立個案：

1、高ID連接-服務器分配一個高ID給正在連接的客戶端

2、低ID連接-服務器分配一個低ID給正在連接的客戶端

3、拒絕會話-服務器拒絕客戶端

當然，也有不重要的個案-服務器崩潰或者不可連接。

圖1 高ID連接的信息順序

圖1描述了導致高ID連接的信息順序。在這種情況下，客戶端建立一個TCP連接到服務器，然后發送一個登錄信息到服務器。服務器用另一個TCP連接到客戶端，執行一個客戶端-客戶端的握手來保證連接的客戶端有能力接收來自其他eMule協議客戶端的連接。在完成客戶端握 手后，服務器關閉第二個連接，通過發送ID更改信息來完成客戶端-服務器的握手。你可能 注意到eMule信息消息是灰色的。這是因為這個消息是eMule協議擴展的一個部分。

圖2 導致低ID連接的信息順序#p#

圖2描述了導致低ID連接的信息順序。在這種情況下，服務器不能連接到發送請求的客戶 端，分配一個低ID給客戶端。服務器消息一般包含警告信息，就像“警告[服務器細節] -  你是低ID。請察看你的網絡配置和/或你的設置”低ID和高ID握手都是通過隨著ID更改消息完成 的，這個ID更改消息分配客戶端一個客戶端ID，用在與服務器的下一個會話。

圖3 被拒絕的會話順序

圖3描述了被拒絕的會話順序。因為eMule協議的客戶端擁有一個低ID或者到達了服務器硬件的容量限制，服務器就可能拒絕會話。服務器消息會包含一個短字符串描述拒絕的理由。