emule架构分析

eMule是一个典型的MFC程序，它的图形界面等，已经和MFC紧紧融合到了一起。因此通常情况下它只能在windows平台下运行。有一些其它的工程，如aMule等，把它进行了移植，因此跨平台的功能要强些。

其实还有另外一个叫做xMule的工程，不过现在已经人气快不行了。在aMule的主页上可以看到eMule移植到linux平台下的一些历史，最早是有个叫做lMule的工程，他使用wxwidgets来进行eMule的跨平台的移植，这个工程2003年就不再更新了，后来转变成为xMule工程，它一度是linux平台下eMule的事实上的替代品。但是他们的程序员之间由于理念不同，发生了内讧，导致aMule分裂出来，他们后来矛盾严重的时候曾经一度从理念问题上升到互相对对方进行人身攻击，并且曾经对对方的网站发动过DDos。后来aMule和xMule就是两个完全不同的工程，xMule现在只有HopeSeekr一个人在维护，基本上也没有什么更新了。这一点不仅让人感慨。今年寒假的时候我曾经和HopeSeekr进行过一些交流，感觉他非常自信，经常拿着aMule的一部分代码来给我看，说你看看他们的代码这么这么写，这简直就是一陀xx嘛，这种代码在某些情况下肯定会Crash掉嘛，相反，你看看我们xMule的代码，这里是这样这样，肯定就不会有这种问题了。

eMule从0.42版开始支持Kad技术，这是一个非常重要的里程碑。Kad是一种DHT的协议，它可以使节点之间互相保留一些其它节点的联系信息，并且利用这样一个“关系网”寻找到整个网络中的任何一个节点以及上面的资源，整个过程不需要任何中心服务器。因此向当年搞napster那样直接端掉中心服务器就搞跨napster网络一样来对付eMule的Kad网就毫无作用了。0.42版是2004年2月27日放出的，比eDonkey2000的OverNet晚了将近一年，但是它的Kad网络的规模却在迅速扩大。Overnet和eMule中的Kad使用的都是Kademlia结构，但是具体的消息报文的格式有区别，因此两个DHT网络并不能互相兼容。OverNet直到现在，用户也仍然维持在十万左右，这是比较近的一篇文章写的。但是eMule的Kad网的规模有多大，目前却没有一个很准确的说法。由此也可以看出开源软件的力量。目前aMule的Kad网和eMule的Kad网是兼容的，xMule中还没有Kad的支持

Emule框架

Emule的概述

(1) emule_p2p：主要处理两个客户端之间的交互。

(2) emule_data_manage：主要处理数据输入输出，数据验证，数据纠错，数据保存。 (3) emule_hub：主要处理与迅雷服务器（hub、tracker）的交互。

(4) emule_cs：主要处理与ed2k服务器的交互。

(5) emule_kad：主要处理DHT协议，在DHT网络中寻源。

(6) emule_nat_traverse：用于与veryCD emule版本进行内网穿透。

emule_p2p

每个文件的下载需构造一个task，提供该文件的源是称为resource，与该resource的每个连接是一个pipe，对于同一个pipe实现了两个逻辑——上传和下载。Emule目前的resource上只开启一个连接。因此task、resource和pipe的关系为：

emule_download_pipe/emule_upload_pipe Task Resource A Pipe Resource B …… Resource N

任务的组成：

Pipe …… Pipe emule_download_pipe/emule_upload_pipe …… emule_download_pipe/emule_upload_pipe emule_download_taskemule_download_logicemule_source_listemule_tracker_logicdispatcher_bridgeemule_data_manager

任务主要有以下元素组成：

（1） emule_download_logic: 该类对任务中的一些关键事件进行监听，并对这些事件

进行处理。任务中的关键事件包括文件创建、文件完成、服务器连接成功、服务器连接失败、连接握手成功、数据管理器出现异常等事件。

（2） emule_data_manager: 该类对数据进行管理，自动处理数据的输入输出，数据纠

错，状态保存等。任务通过其监听接口对该类进行管理。

（3） emule_source_list: 备份当前的所有下载资源。

（4） dispatcher_bridge: 每一个新到达的下载资源都会加入到该类中，该类对所有的

下载资源进行操作，包括建立连接、重连、断开连接等。

（5） emule_tracker_logic: 处理与后台服务器打交道的逻辑。包括tracker查源，向hub

报告下载完成信息，向hub查询文件信息等。

每个任务有一个调度器，调度器通过获取resource的信息来决定创建pipe的个数，对于emule，每个resource从头至尾只创建一个pipe，通过pipe的信息和当前文件的信息，调度每个pipe的下载范围。每个resource有一个实现读写数据的对象emule_p2p_tcp_handler。该对象对socket进行封装，实现异步的读写。

Emule_peer类结构如下：

emule_source_listresource0..ndata_pipechoke_pipeemule_peeremule_download_pipeemule_upload_pipeasyn_socket_deviceemule_p2p_tcp_handleremule_p2p_listeneremule_socket_wrapperverycd_connectionasyn_socket_device_imp

任务接口实现详看IEmule.doc

emule_data_manage

数据管理器主要功能为数据写磁盘emule_data_output和数据读磁盘emule_data_input，读写磁盘操作有文件io系统xl_file_io_system实现。在写磁盘过程中对数据进行验证emule_part_check，验证失败将对数据进行纠错处理。纠错分aich和ich修复。 确认正确的数据或是纠错成功的数据，将计算它们的bcid，提供给迅雷p2p使用。

emule_data_manageremule_io_transferemule_cfg_info_manageremule_file_manageremule_data_input_impemule_verify_manageremule_data_output_impemule_cfg_infoemule_part_checkxl_file_io_systememule_cfg_fileemule_aich_recoveryemule_ich_recoveryemule_id_calculator

纠错实现：

数据管理器通过监听接口向emule_download_logic报告当前出错的块，调度器通过error_correct_interface获取错误块的信息，从新下载该块，并避免从错误的源获取。error_correct_interface接口为：

struct correct_process_info { };

range_queue complete_range_queue; std::string resource_id;

virtual void error_ranges( std::vector& result ) = 0; // 报告错误块

virtual bool can_correct( const range& r, IDataPipe* pipe_ptr ) =0; // 判断该块是否能从制定pipe

上下到非错误的数据。

virtual void get_correct_process_info( const range& r, std::vector& result ) = 0; // 获取纠错进程信息

emule_hub

迅雷的hub服务器主要管理已经完成下载的资源，tracker服务器提供正在下载过程中的资源。Emule在启动前要分别到hub和tracker上查询迅雷服务器保存的该文件的emule资源。

emule_cs

emule有提供源信息的服务器，称为ed2k服务器，该服务器不是迅雷公司维护，主要为国外的服务器。

emule_kad

emule实现的DHT网络，用于分布式寻源，以实现无服务器情况下依然能找到源。

emule_nat_traverse

VeryCD emule版本的emule自己设计了一套内网穿透的协议，主要用于veryCD版本的emule之间，为了实现与其穿透连接，thunder也根据其协议实现与其穿透的功能。

本文来源：https://www.bwwdw.com/article/sfhv.html