eMule协议简要分析[一]
最近我对P2p方面很有兴趣。实际上P2p并不仅仅能用于盗版的传播，在很多合理合法的需求中，P2p也有很广泛的前景，至少包括了信息的冗余存储，内容分发，突破信息监管等等方面。Google文件系统（GoogleFileSystem）文档中
就提到，当在Google网络内分发一个新版本的应用程序的时候，有巨大数量的客户端需要连接到服务器去下载新版本，造成了数据传输热点严重影响系统的运
行，他们计划利用P2p类型的技术来解决这个问题。一段时间以来，网络游戏客户端升级都在采用或者部分采用P2p方案。这些都是在软件分发领域P2p的应
用。
eMule是我用的最多的P2p应用，所以研究也从eMule开始。
最主要的参考文本是eMule协议1.0版，原文地址。分析的流程是简要翻译加上我的思考，我的目标不在于完整的翻译，想看完整翻译的可以关注下p2p分发引擎研究这个Blog，他正在翻译协议文本。我的思考和点评会用红色标出。
--------
电骡eMule是基于电驴eDonkey协议的。电骡网络是由数百个电骡服务器和数百万的电骡客户端组成的。客户端必须连接到服务器来获得网络服务，这个连接要一直保持知道客户端关闭。服务器提供其中的索引服务（类同Napster），不同的服务器之间没有通讯。
每个电骡客户端都预先设置好了一个服务器列表和一个本地共享文件列表。客户端通过一个单一的TCP连接到电骡服务器进行网络登陆，得到想要的文件的信息和可用客户端的信息。（这样造成了电骡和电驴都不能完全去中心化，虽然文件存储在客户端上。）
电骡客户端用几百个TCP连接与其他的客户端连接进行文件的上传和下载。每个电骡客户端为它的共享文件维护一个上传队列。正在下载的客户端加入这个队列的
底部，然后逐渐的前进，直到他们达到队列的顶端开始下载文件。一个客户端可能从多个其他的电骡客户端下载同一个文件，从不同的客户端取得不同的部分。客户
端也可以上传一个没有完全下载的文件的部分数据。（文件可以分块传输大大提高了效率，但是也造成了一些问题，比如源提前退出以后，所有的客户端都是不完全数据的情况。）最终，电骡扩展了电驴的能力允许客户端交换关于服务器、其他客户端和文件的信息。（这个能力又开始把中心的意义淡化。）注意，客户端和服务器的通信都是基于TCP的。
服务器使用一个内部数据库来保存客户端和文件的信息。电骡服务器不保存任何文件，它是文件位置信息的中心索引。服务器的另一个功能，正在受到质疑，他将作为通过防火墙连接的客户端之间的桥梁，这样的客户端不能接受引入的连接。桥接功能大大的增加了服务器的负载。（这个功能让服务器承担了过分的负担，大大降低了服务器的能力，在设计中应该摒弃。）电骡使用UDP增强客户端跟服务器和其他客户端的通信能力。但是客户端收发UDP信息的能力不是客户端日常操作强制要求的，即使防火墙阻止客户端收发UDP信息，客户端仍能完美的工作。
客户端到服务器的连接
图一 电骡网络图
客户端一起动就会用TCP连接到一个电骡服务器。服务器给客户端提供一个客户端ID，这个ID仅在客户端服务器连接的生命周期内有效（注意如果客户端是高
ID，那么他在所有的服务器得到的ID都是一样的，直到他的IP地址变化为止）。连接建立后，客户端把它共享的文件列表发送给服务器。服务器把这个列表保
存在它的内部数据库内，这个数据库通常包括了数十万可用文件和活动客户端。电骡客户端也会发送它的下载列表，包含了他想要下载的文件。后面将给出电骡客户
端和服务器间的TCP信息交换格式细节。
连接建立以后，电骡服务器给客户端发送一个列表，这个列表包括了那些有客户端需要的文件的客户端（这些客户端叫做源）。然后，客户端就去跟那些有所需文件的客户端建立连接。
注意客户端服务器的TCP连接在整个客户端会话过程中都会保持。
