Mar
客户端服务器TCP连接
每个客户端用TCP连接一个服务器。服务器给客户端分配一个ID，用于在会话中唯一标识这个客户端（高ID总是跟据它的ID地址来分配）。电骡客户端需要一个服务器连接才能操作。客户端不能连接到多个服务器，没有用户干预情况下客户端不能动态改变服务器。
连接建立
客户端创建连接的时候，可能会同时连接到多个服务器，仅仅使用成功的登陆流程，其他的连接直接放弃。
这里有两种连接建立的情况：
- 高ID??服务器分配一个高ID给客户端。
- 低ID??服务器分配一个低ID给客户端。
- 拒绝??服务器拒绝客户端的连接。
当然不用说，还有服务器死机和无法连接的情况。
高ID登陆流程
高ID登录流程
上 图描述了高ID登录的消息交换流程。在这种情况下，客户端创建一个到服务器的连接，传送他的登录消息给服务器。服务器用另外的TCP连接去 连接客户端，进行一次客户端到客户端的握手，用来确认客户端有能力接受其他的电骡客户端的连接。在完成了客户端到客户端握手之后，服务器关闭第二个连接， 并发给客户端他的ID作为客户端服务器握手的终结。 你可能注意到上图中的eMule info是灰色的。这是因为这个消息属于eMule协议的扩展。
低ID登陆流程
低ID登录流程
上 图描述了产生低ID连接的流程。在这种情况下，服务器无法连接到客户端（客户端到客户端的握手），所以给客户端分配了一个低ID。通常服务器消息会包括 这样的一个警告“Warning [server details] - You have a lowid. Please review your network config and/or your settings.”。不管高ID还是低ID，握手都是由id change消息结束的，这个消息给客户端在下面的跟服务器的会话提供了一个客户端ID。
登录被拒绝流程
登录被拒绝流程
上图描述了登录被拒绝的流程。当客户端是低ID或者服务器已经到达了硬件能力极限，服务器都有可能拒绝登录。服务器消息里面会包含拒绝理由的简单描述。
连接开始的信息交换
客 户端和服务器成功建立连接之后会交换一些设置消息。这些消息的用途是更新两端的状态信息。客户端首先把它的共享文件列表发送给服务器，然后它要求更新它 的服务器列表。服务器发送它的状态和版本，然后发送它知道的eMule服务器列表，并提供一些自识别的细节。最后客户端询问源（可以用来下载它的下载文件 列表中的文件的客户端），服务器返回一系列消息，知道所有的源列表都被客户端得到为止。
文件搜索
文件搜索是由用户触发的。这个操作是简单的，一个搜索请求发给服务器后，服务器会返回一个搜索结果。当结果有很多的时候，搜索结果消息会被压缩。然后，用 户选择下载其中的一个或多个文件，客户端会请求所选文件的源，服务器返回一个所请求文件的源的列表。一个可选的服务器状态信息可能会在发现源的消息之前发 送给客户端。这个状态信息包含了服务器支持的当前用户和文件数量。注意，这是一个UDP补充消息，用来增强客户端定位源的能力的。确定这些源是新的以后， eMule客户端进行连接，并把他们加到他的源列表内。根据客户端收到源先后顺序连接这些源。没有任何优先级机制来决定先连接哪个源。但是当一个源同时被 下载列表中的多个文件需要的时候，有一个补充机制可以解决问题（注意，eMule只允许两个客户端间建立一个传输连接）。这个选择算法寄予用户指定的文件 优先级，如果没有优先级就根据字母顺序。
回调机制
回调机制是设计用来克服低ID客户端无法接受连入连接的问题的，这样他们也可以跟其他的客户端共享文件。这个机制很简单：如果客户端A和B都连接到同一个 eMule服务器，A需要的一个文件在B上，而B是一个低ID，A可以给服务器发送一个回调请求，请求服务器要求B反过来连接A。服务器已经跟B有了一个 TCp连接，发送给B回调请求消息，把A的IP和端口提供给B。B就可以连接到A，把文件发送给A，而不需要服务器更多的参与。很明显，只有高ID客户端 可以要求低ID客户端回调（低ID没有能力接受连入的连接）（这就是为什么高ID可以跟任何的源连接，而低ID只能跟高ID连接的原因）。这也是允许两个低ID客户端通过服务器交换文件的方法，服务器作为中转。但是因为这样对服务器负担太重，目前大部分的服务器已经不在支持中转了。