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

客戶端服務(wù)器的TCP交流

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

eMule協(xié)議建立連接

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

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

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

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

3、拒絕會話-服務(wù)器拒絕客戶端

當(dāng)然，也有不重要的個案-服務(wù)器崩潰或者不可連接。

圖1 高ID連接的信息順序

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

圖2 導(dǎo)致低ID連接的信息順序#p#

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

圖3 被拒絕的會話順序

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