eMule协议简要分析[三]

eMule协议专题
eMule协议简要分析[一]
eMule协议简要分析[二]
eMule协议简要分析[三]

客户端服务器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客户端通过服务器交换文件的方法，服务器作为中转。但是因为这样对服务器负担太重，目前大部分的服务器已经不在支持中转了。