下载是从服务器到客户端的一个交流。这也就要用到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或者到达了服务器硬件的容量限制，服务器就可能拒绝会话。服务器消息会包含一个短字符串描述拒绝的理由。
