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

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

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

eMule協(xié)議建立連接

在準(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ù)器崩潰或者不可連接。

圖1 高ID連接的信息順序

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

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

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

圖3 被拒絕的會(huì)話順序

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