emule客户端与客户端通信协议详解.docx

客户端-客户端 1初始化握手 握手会话是对称的,客户端-客户端连接的两者都向对方发送相同的信息.两个客户端交换诸如识别,版本号和性能等信息.在这个过程中,有两种报文参与.其一,是Hello报文,它是eDonkey协议的一部分并与eDonkey客户端兼容;另一个报文是eMule信息报文,它属于eMule扩展协议.下图描述了两个eMule客户端之间的握手会话过程.在扩展信息中,包括有UDP报文交换,安全认证和源交换. 客户端初始化握手 2用户身份认证 用户身份认证是eMule协议的一个扩展内容,只要客户端支持这种用户身份认证,它会在初始化握手之后立即完成.整个验证过程按如下步骤进行: 1.在初始化握手过程中,客户端B表示它支持用户身份验证并期望使用此功能. 2.客户端A对B的报文进行回应,它发送身份验证报文,并表明是否需要B的公钥.这个报文还包含了一个等待B回应的4字节挑战. 3.如果A需要B的公钥,B将这个公钥发送给A. 4.客户端B根据A发送的挑战和一个附加双字生成签名,并按照签名报文发送给A.此处的附加双字是根据B或A的IP产生的,当B是LowID时,这个双字为A的IP地址,当B为HighID时,这个双字为B的ID值.下图描述了身份验证过程. 身份验证过程 3文件请求 客户端发送一些请求报文,请求下载它期望获得的文件.一个典型的成功的文件请求过程如图所示. 文件请求过程 3.1基本报文交换 基本报文交换由四组报文组成,客户端A首先发送一个文件请求报文,紧接着发送一个请求文件ID报文.随后,客户端B发送文件请求应答和文件状态报文. eMule扩展协议在这个过程中还加入了一对源请求和源请求应答报文.这对扩展的报文交换可以将客户端B的源信息传给A.为了加强客户端的协作功能,客户端B可以在尚未完成下载的时候就将它已经完成的文件部分传给客户端A,即便客户端B仅仅下载了这个文件的一小部分. 3.2未找到文件报文交换过程 当客户端A向客户端B请求一个文件时,若B的共享文件列表中并没有这个文件,B将不发送文件请求应答报文,而是在客户端A发送文件ID请求后,立即发送一个未找到文件报文.详见下图. 文件请求失败-未找到文件 3.3加入上传队列 当A和B完成文件请求的握手对话后,B客户端也有A客户端所需要的文件,然而此时B的上传队列并非为空（有其他客户端正在下载B的文件）.在这种情况下,B会先将A添加在它的上传列队中,并发送给A一个队列排名报文,这个报文包含了A在队列中的位置以及B的上传队列的相关信息.详见下图. 文件请求等待队列 3.4达到队列顶端报文交换过程 当客户端A到达客户端B的上传队列顶端,B将向A发出连接,进行初始化握手会话.接着,B向A发送一个接受上传请求报文.此时,若A选择继续并下载文件,它会向B发送一个请求文件部分报文;若A已经获得了这部分文件,则它会向B发送一个取消传输报文.下图详细描述了这两种报文传递过程. 达到队列顶端报文交换过程 4.数据传输 文件传输报文交换在文件请求应答后立即开始,此时待下载客户端A发送一个启动上传请求,目标客户端会回复一个接受上传请求报文.紧接着,客户端A开始请求文件部分,随后客户端B向其发送被请求的文件部分.此处的文件部分请求可以请求最多3个文件部分,所以,这样的情况下,一个文件部分请求报文最多会导致3个文件部分的传输过程.当上传下载客户端都支持eMule扩展协议时,文件部分可以压缩传输,同时,扩展协议还支持文件信息报文,这个报文会在接受上传请求前发送.文件传输报文交换过程详见下图. 文件传输报文交换过程 客户端-客户端UDP 通信 eMule 客户端周期性的使用UDP 发送报文. UDP 报文仅用来查询客户端在其他上传客户端的队列中的位置.这是一个简单的查询-应答机制,首先由客户端发送一个询问文件报文.如下图所示,一共有三种不同的应答: 1. 队列等级 – 客户端在上传队列重的等级. 2. 队列已满 – 上传客户端的队列已满. 3. 未找到文件 – 上传客户端并没有这个文件. 这个询问报文约每20 分钟向每一个将其加入上传队列的客户端发送一次.  附录： 信用体制 本段简述客户端的信用机制,如前所述,这种信用机制的主要目的在于鼓励上传.当一个上传客户端向一个下载客户端上传文件时,这个下载客户端会根据所收到的数据量增加对上传客户端的信用评价.此处的上传客户端信用并不是全局范围之内的,它的信用的增加只体现在当它下载此时这个下载客户端的某些文件时.也就是说,一个客户端的信用分别建立再各个它曾经上传过的客户端上.信用等级的计算如下: 1.(总上传量*2)/总下载量. 这个计算式的最大值取10,当总下载量为0时,此值默认为10. 2.Sqrt(总上传量+2). 当总上传量小于1Mb时,这个表达式最小值取