Ed2k协议背景介绍及eMule协议的整体架构

            笔者准备写几篇和ed2k ，eMule 源代码梳理以及 kad实现的博客。梳理源代码的目的在于让大家在看了一下原理后，想看下这些原理的具体实现（看eMule源代码）时轻松些，更有目标。所以在这里笔者也上传了eMule官方源码，若梳理的不好请见谅。这里是第一篇介绍的是ed2k的背景及eMule协议的整体架构。

ed2k全称叫“eDonkey2000 network”，是一种文件共享网络，最初用于共享音乐、电影和软件。与多数文件共享网络一样，它是分布式的；文件基于P2P原理存放于用户的电脑上而不是存储于一个中枢服务器。

eDonkey客户端程序连接到这个网络来共享文件。而eDonkey服务器作为一个通讯中心，使用户在ed2k网络内查找文件。它的客户端和服务端可以工作于Windows、Macintosh、Linux、UNIX操作系统。任何人都可以作为服务器加入这个网络。由于服务器经常变化，客户端会经常更新它的服务器列表。

 

eDonkey用混合MD4摘要算法检查来识别文件。这使ed2k网络可以将不同文件名的同一文件成功识别为一个文件，并使同一文件名的不同文件得以区分。eDonkeyd的另一特性是：对大于9.8MB的文件，它在下载完成前将其分割；这将加速大型文件的发送。为了便于文件搜索，一些Web站点对比较热门的文件建立 ed2k链接，这些网站通常也提供热门服务器列表便于用户更新。

 

应用最广泛的ed2k服务器软件是Lugdunum,最开始的ed2k客户端是 eDonkey。

eDonkey是由Jed McCaleb在2000年创立。采用“多源文件传输协议”(MFTP，the Multisource File Transfer Protocol)来散布文件。eDonkey中的索引服务器并不集中在一起的，而是各人私有的，遍布全世界，每一个人都可以运行电骡服务器（客户端和服务器端于一身），同时共享的文件索引为被称为“ed2k-quicklink”的连接，文件前缀“ED2K://”。每个文件都用md5-hash的超级链接标示，这使得该文件独一无二，并且在整个网络上都可以追踪得到。EDonkey可以通过检索分段从多个用户那里下载文件，最终将下载的文件片断拼成整个文件。

 

2002年05月3日Merkur不满意eDonkey 2000客户端并且坚信自己能做出更出色的P2P软件，于是便着手开发。凝聚一批原本在其他领域有出色发挥的程序员，eMule工程就此诞生,目标是将eDonkey的优点及精华保留下来，并加入新的功能以及使图形界面变得更好。eMule的最新版本获得来源是其官方网站：www.emule-project.net

 

emule是eDonkey的升级版，它的独到之处在于开源（eDonkey不开源）。其基本原理和运作方式，也是基于eDonkey,能够直接登录eDonkey的各类服务器。eMule同时也提供了很多eDonkey所没有的功能，比如可以自动搜索网络中的服务器、保留搜索结果、与连接用户交换服务器地址和文件、优先下载便于预览的文件头尾部分等等，这些都使得eMule使用起来更加便利，也让它得到了电骡的美誉。

综上，一般情况下对于ed2k 协议相关研究大多是直接往emule上处理，所以笔者在处理ed2k相关协议时，是以emule协议（具体是eMule协议1.0版）进行分析的（主要是从英文文档翻译而来，只截取了一部分（具体的报文结构暂时不考虑在博客中涉及。可能会提到，但是不会特别具体））。这里有emule 协议中文完整版地址是 http://download.csdn.net/detail/huang_rong12/9505837 

 

概述
电骡eMule是基于电驴eDonkey协议的。电骡网络是由数百个电骡服务器和数百万的电骡客户端组成的。客户端必须连接到服务器来获得网络服务，这个连接要一直保持直到客户端关闭。服务器提供集中的索引服务（类同Napster），不同的服务器之间没有通讯。

每个电骡客户端都预先设置好了一个服务器列表和一个本地共享文件列表。客户端通过一个单一的TCP连接到电骡服务器进行网络登陆，得到想要的文件的信息和可用客户端的信息。（这样造成了电骡和电驴都不能完全去中心化，虽然文件存储在客户端上。）电骡客户端用几百个TCP连接与其他的客户端连接进行文件的上传和下载。每个电骡客户端为它的共享文件维护一个上传队列。正在下载的客户端加入这个队列的底部，然后逐渐的前进，直到他们达到队列的顶端开始下载文件。一个客户端可能从多个其他的电骡客户端下载同一个文件，从不同的客户端取得不同的部分。客户端也可以上传一个没有完全下载的文件的部分数据。（文件可以分块传输大大提高了效率，但是也造成了一些问题，比如源提前退出以后，所有的客户端都是不完全数据的情况。）最终，电骡扩展了电驴的能力允许客户端交换关于服务器、其他客户端和文件的信息。（这个能力又开始把中心的意义淡化。）注意，客户端和服务器的通信都是基于TCP的。

服务器使用一个内部数据库来保存客户端和文件的信息。电骡服务器不保存任何文件，它是文件位置信息的中心索引。服务器的另一个功能，正在受到质疑，他将作为通过防火墙连接的客户端之间的桥梁，这样的客户端不能接受引入的连接。桥接功能大大的增加了服务器的负载。（这个功能让服务器承担了过分的负担，大大降低了服务器的能力，在设计中应该摒弃，目前应用中大部分的服务器已经关闭了这个功能，也就是说两个Low id的客户端是不能传输数据的。）电骡使用UDP增强客户端跟服务器和其他客户端的通信能力。但是客户端收发UDP信息的能力不是客户端日常操作强制要求的，即使防火墙阻止客户端收发UDP信息，客户端仍能完美的工作。

客户端到服务器的连接

 

 

图一电骡网络图

客户端一启动就会用TCP连接到一个电骡服务器。服务器给客户端提供一个客户端ID，这个ID仅在客户端服务器连接的生命周期内有效（注意如果客户端是高 ID，那么他在所有的服务器得到的ID都是一样的，直到他的IP地址变化为止）。连接建立后，客户端把它共享的文件列表发送给服务器。服务器把这个列表保存在它的内部数据库内，这个数据库通常包括了数十万可用文件和活动客户端。电骡客户端也会发送它的下载列表，包含了他想要下载的文件。后面将给出电骡客户端和服务器间的TCP信息交换格式细节。

连接建立以后，电骡服务器给客户端发送一个列表，这个列表包括了那些有客户端需要的文件的客户端（这些客户端叫做源）。然后，客户端就去跟那些有所需文件的客户端建立连接。

注意客户端服务器的TCP连接在整个客户端会话过程中都会保持。初始化握手之后，事务主要是由用户活动触发的：有时客户端发送一个文件查找请求给服务器，服务器会返回一个查找结果，一个查找事务之后通常是一个对指定文件的源查询，这个查询的结果是一个可以提供该文件下载的源的列表。

电骡客户端用UDP来跟登录服务器以外的服务器进行通信。UDP信息的用途是增加文件搜索能力，源搜索能力，保持连接。

 

客户端到客户端之间的连接

电骡客户端一般是为了下载某个文件才会连接到其他的客户端（也就是源）的。一个文件会被分为很多块。客户端会从多个客户端（源）那里下载同一个文件，从不同的源下载文件的不同部分（这样不同的部分就可以同时被下载，如果源多，下载的效率就会极高）。

当两个客户端连接后，他们会交换容量信息，然后协商开始下载(或者说是上传,这取决于视角)的时间。每个客户端有一个下载队列，用来保存正在等待下载的客户端的列表。当电骡客户端的下载对列为空的时候，下载请求会被马上接受（除非这个请求者已经被屏蔽）。如果下载对列不为空，那么新的下载请求就会放在队列之中。不会努力服务更多的客户端，对每个下载客户端至少保持不少于2.k字节/每秒。一个正在下载的客户端的下载地位可能被一个对列等级（queue ranking）比他高的等待客户端抢占，在下载进程中的前15分钟正在下载的客户端的队列等级会增长用来避免产生颠簸（这里说的颠簸就是说，一个客户端频繁的从下载地位切换到等待状态，然后再切换回去。这种频繁的切换叫做颠簸，这对资源是种浪费，所以要避免。）。

当正在下载的客户端到达了下载队列的顶部，提供上传的客户端初始化一个连接用于把它需要的文件片断传送给它。一个电骡客户端可能会在多个源客户端的等待队列中，在每个客户端上注册要求同一个文件片断。当这个等待客户端实际上完成了这个文件片断的下载，他不会通知那些源客户端删除它的请求，而仅仅是在它在那些源客户端的队列中排到顶端的时候拒绝上传请求而已。

电骡使用一个声望系统来鼓励上传，为了防止假冒，电骡用RSA公钥加密技术来保护声望系统。

客户端连接中会使用很多电驴协议（eDonkeyprotocol）没有定义的消息，这些消息叫做扩展协议。扩展协议用来实现信用系统，用来进行信息交换（例如，服务器列表的更新和源的更新），通过对文件块进行压缩提升发送和接收的效率。电骡客户端连接中有限地使用UDP去周期其他客户端的状态。