本文详细解析了eMule的架构和技术实现，包括文件共享、Kademlia网络、搜索机制等核心功能。介绍了eMule如何通过合理的代码设计实现高效的文件传输。
eMule的官方首页上写着：2002年05月13日 一个叫做 Merkur 的人，他不满意原始eDonkey2000客户端并且坚信他能够做的更好，所以他开始制作。他聚集了其它开发人员在他的周围，并且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的支持。Kad协议的原始paper可 以在我们实验室的机器上下到：
http://bigpc.net.pku.edu.cn:8080/paper/new/by%20conference/IPTPS/IPTPS02/Kademlia%20A%20Peer-to-Peer%20Information%20System%20Based%20on%20the%20XOR%20Metric%28IPTPS02%29.pdf
eMule的代码结构非常合理。虽然代码量比较大，但是各个功能模块之间的划分都很合理。从它的工程文件里面就可以看出这一点。eMule 把表示功能的代码文件和表示界面的代码文件分开了，Source Files和Header Files是实现功能的代码的源文件和头文件，而Interface Source和Interface Header是实现图形界面的源文件和头文件。由于eMule的代码量太大，本系列将跳过图形界面的实现，着重分析eMule的功能实现部分的代码，而且 功能实现方面也主要挑主要的部分分析。本节将从emule.cpp开始分析，引出eMule中使用到的几个主要的功能实现的类，并大体描述它们的作用。最 后介绍一下如何在VS2003下编译eMule。emule中还有不少模块实现的功能挺有用，我说的是在其它的程序里很有用，可以考虑在其它程序中进行复 用。
emule.cpp为类CemuleApp的实现。因此在运行时，首先会运行InitInstance进行一些初始化的工作。从这个函数里面我们也可以第一次看出那些即将在整个程序中发挥作用的类了。
最 开始的时候是计算出程序常用的一些目录，如配置文件，日志文件等。接下来是ProcessCommandline，它的作用有两方面，第一是确认该 eMule的运行方式，即命令行后面有没有参数，第二是确认目前eMule是不是只有一个实例在运行。在一般的情况下，双击eMule可执行文件是不会带 参数的。但是通过点击链接或者打开关联文件的方式打开eMule则相当于带参数运行eMule。通过在注册表里添加一些项目可以让一个程序和某种链接或者 某个后缀的文件产生关联。具体办法可以参见OtherFunctions.cpp中的Ask4RegFix，BackupReg，RevertReg三个 函数的功能。ProcessCommandline中通过创建带有名称的互斥信号量来确认是否有其它的eMule实例在运行。对于一个确定的名 称，CreateMutex只能创建一个互斥信号量。因此通过该信号量是否创建成功就可以知道是否有其它eMule实例运行。如果有的话，而且又是带参数 的那种模式，那么直接把这个参数使用Windows的消息机制发给那个窗口即可，接下来的代码无非就是如何找到另外一个叫"eMule"的家伙以及给它发 个什么消息。pstrPendingLink是一个全局变量，表示将要被处理的命令行参数。它将会在初始化完成后一段时间后被处理。
下面 两个比较重要的类是CPreferences和CStatistics。前者掌握着程序的大部分配置数据，后者则进行各种统计。它们的特点都是有很多的成 员变量，而且还是静态的，这种方式可以保证它们的唯一性，而且把这些变量统一到一个类管理。但是实际上并不需要了解每个变量的含义。thePrefs和 theStats是这两个类的唯一的实例。
在处理完其它一些事情，包括创建图形界面对象CemuleDlg后，接下来可以看到一排一排的创建新对象的语句。这些类将会实现eMule程序运行的主要功能，后面的系列将详细分析。
最 后描述一下如何在VS2003里编译eMule，由于eMule中用到了一些其它的库，因此官方在提供eMule的源代码下载的同时如果也提供这些库的下 载会使源码包变得很大。因此eMule选择了让开发者去那些库的官方网站下载它们的方式。一般来说，编译这种工程文件，很重要的地方是要保持各个库和主程 序编译参数的一致性。这些编译参数中，最主要的参数有三个，字符集(多字节/Unicode)，调试/发行，单线程/多线程，这样排列组合一下就有八个版 本了。因此编译的时候如果不注意，就会出现和程序设计无关的错误。
eMule0.47a解压后自带id3lib库，还需要下载以下的库：
zlib:
http://www.gzip.org/zlib/
ResizableLib:
http://sourceforge.net/projects/resizablelib/
Crypto++:
http://www.eskimo.com/~weidai/cryptlib.html
pnglib:
http://www.libpng.org/pub/png/libpng.html
下 载它们，解压它们，编译它们。编译的时候注意要和eMule的工程的参数一致：字符集为Unicode，支持多线程安全，调试版或者是发行版可以根据需要 选择，但是也要和eMule的工程参数一致。这些库的解压包里通常都能找到VC的工程文件，但是版本低一些，直接转化就可以了。另外建议编译这些库的时候 都选择生成静态库，不要生成动态的库，这样最后生成的可执行文件就可以自己运行了。编译完这些库，包括从其它地方下载的和eMule自带的id3lib库 和CxImage库后，就可以开始编译emule了。而编译emule也无非就是注意让它能够在编译的时候找到所有的头文件，以及在链接的时候能够找到所 有的库。在链接的时候能够找到所有的库可以通过修改工程文件里面的属性 ->配置属性 ->链接器 ->输入->附加依赖项来完成。但是能够找到所有的头文件反而需要一些技巧了。由于emule的代码中对于这些库的头文件的包含，在一定程度 上限定了那些库的路径和emule的工程的路径的相对位置，因此需要把那些解压过的库的目录移到一些合适的地方，有时还需要给这些目录改个名称。
eMule中要读取的配置文件数量较多，每种配置文件都是自己定义的格式，为了方便读取和存储这些文件，eMule中有一个很重要的基础设 施类来复制这些文件操作，它能够很方便得处理一些常用数据类型的读写，并且带有一定的安全保护机制。这项基础设施在SafeFile.cpp和 SafeFile.h中实现。在kademlia/io目录下有这项功能的另外一项实现。它们实现的功能基本上相似，但是kademlia/io目录下的 版本实现的时候多了一个以Tag作为单位进行读写的功能。这些实现中和另外一项基础设施，那就是字符串转化密切相关。 StringConversion.cpp和StringConversion.h是eMule中专门复制各类字符串转化的基础设施，什么Unicode 啊，多字节流啊，或者是UTF-8之类的，在这里转化全部都不是问题。关于字符串转化，个人推荐尽量使用Unicode的宽字符，这样可以最大程度得避免 乱码。
SafeFile.cpp或者kademlia/io目录下的实现都有这样的特点，那就是把数据操作的行为和数据操作的对象分割开 来。它们都定义了一个抽象的数据操作的基类(在SafeFile.cpp中是CFileDataIO，在kademlia目录下是DataIO.cpp实 现的Kademlia::CDataIO)，这个类中只负责实现在逻辑上操作一项数据的行为，例如，要读取出一个32位的整型，那么就是读出四个字节到一 个整型数值的地址中，要读取或者写入其它类型的数据用的是类似的方法。但是这个类把物理上进行数据操作的方法全部都声明为纯虚函数，即读出多少个字节，写 入多少个字节这样的。有了这样一个基类，就可以非常方便得在它上面进行重载，把这些纯虚函数定义为向某块内存中进行读写的操作，就能很方便得将较为复杂的 数据序列化到一块连续的内存，而如果这些纯虚函数是向文件读写的操作，那么自然就可以很方便得用来读写各种格式比较奇怪的自己定义的配置文件了。
这 些类要读取的数据对象通常有这些，各种整型，字符串，以及Tag类型。整型读写起来比较简单，从1个字节的，2个字节的到4个，8个或者16个字节类型的 数据读写方法都比较类似。这里要稍微提一下16个字节的那种，16个字节是128位，是eMule中的Kad网的随机生成的ID的长度，也是eMule中 常用的MD4的hash算法生成的结果的长度。通常用来直接存取整个的这样的一个ID。在kademlia/utils目录下的UInt128.cpp实 现了一个表示128位的整数的类，功能十分完善，可以进行一些算术操作，并且可以进行比较，这样为它以后作为key出现在hash表中打下了基础。仔细学 习UInt128.cpp中的代码实现可以学到很多在编写这种自定义的数据对象类型时应该注意的问题。
数据操作中另外一项很重要的操作是 字符串，总的原则是先写一个长度，再写内容。但是到具体的操作的时候就需要注意这些细节了，如长度是写4个字节还是两个字节，字符串的内容要不要用 UTF-8进行编码。这些操作就需要和StringConversion.cpp紧密合作了。其实后者的字符串转化函数很多也是调用ATL的相关函数，只 是在外面再包上一层MFC的CString。
在kademlia/io/DataIO.cpp中实现的CDataIO中，还另外实现了按 照Tag进行读写的功能。这在网络上交换共享文件的元信息非常重要，通常一个文件的元信息就可以分解成很多的Tag，如"文件名=xxx"，"文件长 度=xxx"等等。也就是说，一个Tag就是表示某项属性等于某个值这样一个事实。在Opcodes.h这个文件中定义了很多的代码，其中就有很多常见的 Tag的属性名称。CDataIO类中存储Tag的属性名都是先存一个字节的类型，再存名称，最后按照类型存值。
eMule中的这几项基 础设施都是编写得比较好的，可以很方便得拿出来复用。像字符串编码的处理和具有一定数据结构的文件IO操作在很多地方都会很有用。eMule中这些类的实 现基本上复制到其它的工程文件中只要稍微修改一下很快就能使用。以后我们还将看到eMule中很多其它很有用的基础设施。
emule作为一个文件共享方面的程序，首先要对自己共享的所有的文件的信息都十分清楚，类CKnownFileList的作用就是这样的，它在emule.cpp中随着cmuleapp类创建的时候被创建。
CKnownFileList 类使用了MFC的CMap类来维护内部的hash表，这也可以看出emule和MFC的关系确实非常紧密。这里如果用STL的map其实也是可以的。它内 部维护了一个已知的文件的列表和取消了的文件列表。这些hash表的关键字都是文件的hash值。这样能够判断出文件名不同而内容相同的文件，而一般要让 不同内容的文件有相同的hash值是非常困难的，这也是hash函数它设计的初衷。因此除非是碰上王小云教授这样的牛人，我们基本上可以认为，两个文件 hash值相同就代表了它们内容相同。再来看CKnownFileList.cpp，这个文件其实并不长，因为管理一个列表确实不需要太多种类的操作，如 果对于每个具体的文件有一个很强大的类来处理它的话。而这里确实有，它就是CKnownFile。有了这么一个类，我们就可以看 到，CKnownFileList类所需要做的工作就是能够根据一些信息查找到对应的CKnownFile类，能够复制其它的列表中的信息，能够把所有的 这些信息存成文件，然后下次emule运行的时候能够把这些信息快速恢复出来，最重要的是能够在完成以上工作的情况下不造成内存泄漏。
CKnownFile 类就是一个专门关注某个特定文件的信息的类，它仍然有其基类CAbstractFile。但是它和CAbstractFile类的主要区别就是 CAbstractFile类只有基本的信息存取的功能，而CKnownFile能够主动的生成这些信息，例如，给一个文件的路径给 CKnownFile，它能够主动地去获取和这个文件有关的一切信息，并且把它保存在自己的成员变量里(CreateFromFile)。 CKnownFile.cpp文件看上去比较长，是因为它做的工作比较多，现在版本的emule中，除了对某个文件进行全文hash以外，还采用了BT的 方式，进行分块hash，这样在传输文件的时候，即使发生出错的情况，也可以不必重传整个文件，而只是重传有错误的那块，这种机制叫做高级智能损坏处理 (AICH,Advanced Intelligent Corruption Handling)，这个机制以后再继续分析。
CKnownFile 把读到的文件信息都保存成一个一个的Tag。它在运行中会尽量得获取更多的文件信息，例如，对于媒体类型的文件，它能够调用id3lib库来获取诸如作 者，唱片发行年代，风格等tag信息。如果是视频媒体文件，它还会去抓图(功能实现：CFrameGrabThread)。
CKnownFile 还能够随时掌握目前该文件的下载情况(内部有个CUpDownClient的列表)，当然，还会根据要求序列化和反序列化自己，LoadFromFile 和WriteToFile都以CFileDataIO为参数，这样方便CKnownFileList保存和读取它的列表中的所有文件的信息
| |
|
分块机制--正确传输资源的保证 为了加快内容分发的速度，分块处理是一种简单有效的方法。emule中对每个文件都进行了分块处理。另外分块还有一个好处就是如果保留了每 一分块的hash值，就能在只下载到文件的一部分时判断出下载内容的有效性。emule在获取每个共享文件的信息时，就对它进行了分块处理，因此如果要知 道emule中的分块处理和恢复机制，看CKnownFile::CreateFromFile函数的实现就行了。 网络基础设施--网络基础设施的基础设施 MFC中已经有一些网络基础设施类，如CAsyncSocket等。但是emule在设计中，为了能够更加高效得开发网络相关的代码，构建了另外的一些类作为基础设施，这些基础设施类的代码也有很高的复用价值。 网络基础设施--全局限速器UploadBandwidthThrottler UploadBandwidthThrottler是emule中使用的全局的上传限速器。它继承了CWinThread类，且在该类被创 建的时候，就新创建一个线程开始单独运行。在该类被析构时也会自动停止相应的线程。这个线程的目标函数就是RunProc，然后为了避免在RunProc 函数不能使用this指针的情况，它使用了RunInternal来实际完成工作线程的工作。在emule中，还有另外一个类 LastCommonRouteFinder有类似的结构。 网络基础设施--emule套接字CEMSocket CEMSocket是CAsyncSocketEx和ThrottledFileSocket的子类，它把若干功能整合到了一起，因此可以 作为emule使用起来比较方便的套接字。例如它可以很方便得指定代理，把CAsyncSocketEx中的创建一个新的代理层并且添加到列表中的功能对 外屏蔽了。另外它可以分出状态，如当前是否在发送控制信息等。 |
|
搜索信息集－CSearchList CSearchList是emule中的搜索列表，掌管emule中所有的搜索请求。CSearchFile是这个列表中的元素，代表了一 次搜索的相关信息。它们的关系和之前描述的已知文件和已知文件列表有一些类似的地方。CSearchList的主要任务就是对其一个叫做list的类型为 CSearchFile列表的内部变量进行维护，提供很方便得往这个列表中添加，删除，查询，变更等操作的接口。另外，每一个搜索都有一个ID，是一个 32位的整数。CSearchList中记录了每个搜索目前搜到的文件个数和源的个数(m_foundFilesCount和 m_foundSourcesCount)。 服务器信息集－CServerL 尽管目前有了Kad网络，但是使用服务器来获取各个emule用户的共享文件列表仍然是emule中主要的资源获取方式。 CServerList就是emule中负责管理服务器列表的类。和前面若干列表类结构类似，CServerList需要对外提供列表的增加，删除，查 找，修改等接口。在CServerList中，每个服务器的信息是一个CServer类。和搜索信息不一样，但是和已知文件列表一样，服务器的信息列表是 需要长期保留的，因此CServerList和CKnownFileList类一样提供了把它所包含的所有信息保存到一个文件中，以及从这个文件中读回其 信息的功能。 emule的通信协议－一些基本的约定 接下来将不可避免得要碰到emule的协议。emule的通信协议格式设计成一种便于扩充的格式。对于TCP连接来说，连接中的数据流都能 够划分成为一个一个的Packet，CEMSocket类中就完成了把接收到的数据划分成Packet这一工作。但是具体的对于每个Packet进行处理 的工作被转移到它的子类中进行。CEMSocket类的两个子类CServerSocket和CClientReqSocket所代表的TCP连接就分别 是客户端和服务器之间的TCP连接以及客户端之间的TCP连接。在数据流中的第一个字节代表的是通信的协议簇代码，如0xE3为标准的edonkey协 议，0xE4为kademlia协议等等。接下来的四个字节代表包内容的长度，所有的包都用这种方式发送到TCP流中，就可以区分出来了。另外每个包内容 中的第一个字节为opcode，即在确定了某个具体协议后，这个opcode确定了这个包的具体含义。 emule的通信协议－客户端和服务器之间的通信概述 客户端和服务器之间的所有通信由类CServerConnect掌握。CServerConnect本身不是套接字的子类，但是它的成员变 量CServerSocket类型的connectedsocket是。CServerConnect内部有一列表，可以保存若干 CServerSocket类型的指针。但是这并不说明它平时连接到很多服务器上。它只是可以同时试图连接到若干个服务器上，这只是因为连接到服务器上的 行为不一定能成功。 emule的通信协议－客户端和客户端之间的通信概述 客户端和客户端之间的TCP通信由CListenSocket和CClientReqSocket完成。这也是提供网络服务的应用程序的典 型写法。其中CListenSocket只是CAsyncSocketEx的子类，只负责监听某个TCP端口。它只是内部有一个 CClientReqSocket类的列表。而CClientReqSocket是CEMSocket的子类，因此它能够自动完成emule的 packet识别工作。它有ProcessPacket和ProcessExtPacket来处理客户端和客户端之间的包，其中前者是经典的 eDonkey协议的包，后者是emule扩展协议的包。 |
|
eMule中的信誉机制 信誉机制在P2P系统中有非常重要的作用。为了使用户更加愿意共享自己的资源，需要有一些机制能够让对整个P2P系统贡献更大的用户有更多 的激励。在emule中，激励机制的设计方案是tit-for-tat这种最直观的方案。这种方案的意义就是最简单的如果别人对你好，那么你也对别人好。 下载任务即部分文件的表示 CPartFile类是emule中用来表示一个下载任务的类。从它的名字也可以看出来，这就是一个还没有完成的文件。当一个下载任务被创 建时，emule会在下载目录中创建两个文件，以三位数字加后缀part的文件，例如001.part，002.part等。还有一个以同样的数字加 上.part.met的文件，表示的是对应文件的元信息。part文件会创建得和原始文件大小一样，当下载完成后，文件名会修改成它本来的名称。而事实 上，诸如这个文件原来叫什么名称，修改日期等等信息都在对应的.part.met元文件中。.part.met中还包含了该文件中那些部分已经下载完成的 信息。 下载任务队列 CDownloadQueue是下载队列类。这个队列中的项目是CPartFile指针。因此和emule中出现的很多其它的列表类一样， 它需要能够提供对这个列表中的元素进行增加，查询，删除的功能。例如查询的时候能够根据该文件的hashID或者索引来进行查询。 CDownloadQueue同时还要完成一些统计工作。 上传任务队列 CUploadQueue是上传队列类。这个列表类中只有以CUpDownClient为元素的列表，它和其它列表类还有一个很大的不同就 是它所保存的信息都不需要持久化，即不需要在当前的emule退出后还记住自己正在给谁上传文件，然后下次上线的时候再继续给他们传，这在大部分情况下是 没有意义的。 emule中代码量最大的类CUpDownClient CUpDownClient类的作用是从逻辑上表示一个其它的客户端的各种信息，它是emule中代码量最大的类。我们注意到，定义它的头 文件是UpDownClient.h，但是却没有对应的CUpDownClient.cpp，而它的实现，都分散到 BaseClient.cpp，DownloadClient.cpp，PeerCacheClient.cpp，UploadClient.cpp和 URLClient.cpp中。 emule常规部分小结 emule中还有其它的很多类，它们使得emule的功能更加的强大和完善。有很多类在前面没有提到，但是不代表它没有作用。而且即时是前 面提到的类也只是大体的介绍，它们之间互相配合的一些细节没有体现。但是这些细节应该已经可以通过对它们的大体的功能的了解而更加容易被把握。至于GUI 的设计，它也最终是要对应到某个功能实现类的数据的。 |
eMule中的Kademlia代码总体描述
当emule中开始使用Kademlia网络后，便不再会有中心服务器失效这样的问题了，因为在这个网络中，没有中心服务器，或者说，所有 的用户都是服务器，所有的用户也是客户端，从而完完全全得实现了P2P。接下来讲针对emule中的Kademlia网络进行分析，会有一节进行原理方面 的分析。另外的几节将会根据emule中实现Kademlia所使用的不同的类分别进行讲述。其中：
CKademlia是整个Kademlia网络的主控类，可以直接开始或者停止Kademlia网，并且含有Process方法来处理日常事务。
CPrefs负责处理自身的Kademlia相关信息，如自身的ID等。
CRoutingZone，CRoutingBin和CContact三个类组成了每个节点所了解的联系信息以及由这些联系信息所组成的数据结构。
CKademliaUDPListener负责处理网络信息。
CIndexed负责处理本地存储的索引信息。
CSearch，CSearchManager负责处理和搜索有关的操作，其中前者表示的是一个单一的搜索任务，后者负责对所有搜索任务进行处理。
CUInt128负责处理一个128位的长整数，并且内置其各种运算。前面已经提到过。
emule中的Kademlia的基本原理
Kademlia是一种结构化的覆盖网络(Structured Overlay Network)，所谓的覆盖网络，就是一种在物理的Internet上面再次构建的虚拟网络，所有参与的节点都知道一部分其它节点的IP地址，这些节点 称为它的邻居，如果需要查找什么东西，它先在本地寻找，如果找不到，就把这个查询转发到它的邻居处，希望能够有可能查找到相应的结果。覆盖网络里面分成了 结构化和非结构化的两种情况，它们的区别在于每个节点知道哪些其它节点的信息是否有特定的规律。在非结构化的覆盖网中，每个节点的邻居状况没有特定的规 律。因此在非结构化网络中，如果要进行查询，会采取一种叫做泛洪(flooding)的方法，每个节点如果在本地没有查找到想要的结果，会把查找请求转发 到它的邻居中，然后再通过邻居的邻居这种方式来进行一步步的查找。但是这种方法如果处理不好，会造成整个网络的消息负载过大。已经有不少文章对于优化非结 构化覆盖网络中的查询进行了很深入的探讨。
对于结构化的覆盖网络，它的特点是每个节点它会选择和哪些节点做邻居是有一定的规律的，从而在 进行搜索的时候，节点把搜索请求进行转发的时候它能够通过一定的规律进行选择把请求转发到哪些邻居节点上。这样同时也能减少搜索代价。结构化的覆盖网络通 常要求每一个节点随机生成一个ID，用以判断各个节点之间的关系。这个ID和它所在的物理网络必须是没有关系的。
对于Kademlia网 络来说，这个ID是一个128位的数值，所有的节点都用这个ID来衡量自己与其它节点的逻辑距离。而逻辑距离的计算方法就是将两个节点进行异或(XOR) 操作。在Kademlia网络的形成过程中，每个节点选择邻居的原则是离自己逻辑距离越近的节点越有可能被加入到自己的邻居节点列表中，具体来说就是在每 次新得到一个节点的信息的时候，是否把它加入到自己的邻居节点列表是根据距离的远近来处理的。后面分析具体程序的代码时会有说明。
结构化 的网络的好处就是如果我们要寻找一个距离某个ID逻辑距离足够近的节点，我们可以保证在O(logn)级别的跳数找到。只要先寻找自己已知的离目标ID逻 辑距离足够断的节点，然后再问它知不知道更近的，然后就这样下去。因此在搜索的时候也是这样，当需要发布资源的时候，把文件进行hash，这样就能够计算 出一个128位的ID，或者把关键字进行hash。然后寻找到离这个结果逻辑距离最近的节点，把文件或者关键字的信息发送给它，让它存起来。当有人要搜索 同样的东西的时候，由于它用的是同一个hash算法，因此能够计算出对应的ID，并且去搜索那些和这个ID逻辑距离相近的节点，因为它知道，如果网络中真 有这些资源的话，这些节点是最有可能知道这些信息的。由此我们可以看出，结构化的网络的资源查找效率是很高的，但是它和非结构化的覆盖网络比起来，缺点是 不能进行复杂查询，即只能通过简单的关键字或者文件的hash值进行查找。非结构化的网络的查找本身就是随意转发的，每个收到的查询请求的节点都对本地的 资源掌握的很清楚，因此自然可以支持复杂查询，但是显然非结构化的网络支持的复杂查询不太可能动员所有的节点都来做这一动作。目前还没有方法能够把两种覆 盖网络的优点结合起来，我也非常想知道这样的一种方法。
emule中的Kademlia的基础设施类
Kademlia的主控类是CKademlia，它负责启动和关闭整个Kademlia网的相关代码。在它的Process函数中，会处理 和Kademlia网相关的事务，例如隔一段时间检查某个区间的节点数是否过少，如果是则寻找一些新的节点。另外经常对自己的邻居进行检查等，这些都是属 于需要进行日常安排的工作。所有搜索任务的日常处理也需要它来调度。它还作为Kademlia网的代表，向emule其它部分的代码返回Kademlia 网的一些统计信息。
另一个基础设施类是CPrefs，它和emule普通代码中的CPreferences作用类似，但是CPrefs只保留和Kademlia网相关的，需要长期保存的本地信息。具体到这个版本来说，主要就是本地的ID。
还有一个很重要的基础设施就是CUInt128，实现对128位的ID的各种处理，前面的部分已经提到。
emule中的Kademlia的联系人列表管理
CRoutingZone，CRoutingBin和CContact三个类组成了联系人列表数据结构。它要达到我们搜索的要求，即搜索到目标的时间要能够接受，而且所占用的空间也要能够接受。
首先CContact类包含的是一个联系人的信息，主要包括对方的IP地址，ID，TCP端口，UDP端口，kad版本号和其健康程度 (m_byType)。其中健康程度有0-4五个等级。刚刚加入的联系人，也就是健康状况未知的，这个数值设置为3。系统会经常通过与各个联系人进行联系 的方式对其进行健康状况检查，经常能够联系上的联系人，这个数值会慢慢减少到0。而很就没有联系的，这个数值会慢慢增加，如果增加到4后再过一段时间未能 成功联系上的，则将会被从联系人列表中删除。
CRoutingBin类包含一个CContact的列表。这里要注意的是要访问联系人的信 息必须通过某个CRoutingBin，CRoutingZone内部是不直接包含联系人信息的。可以把新的联系人信息往一个特定的 CRoutingBin中加，当然也可以进行联系人查找。它也提供方法能够寻找出离某个ID距离最近的联系人，并给出这样的一个列表。这是相当重要的。最 后，一个CRoutingBin类中能够包含的CContact的数量也是有限制的。
CRoutingZone类处于联系人数据结构的最 上层，直接为Kademlia网提供操作接口。该类的结构为一个二叉树，内含两个CRoutingZone指向它的左子树和右子树，另外也包含一个 CRoutingBin类型的指针。但是只有在当前的CRoutingZone类为整个二叉树的叶节点时，这个指向CRoutingBin类型的指针才有 意义。这个二叉树的特点是，每个节点以下的所有联系人的ID都包含一个共同前缀，节点的层数越深，这个共同前缀越长。例如，根节点的左子树的所有的节点的 ID一定有一个前缀"0"，而右子树的所有节点一定有前缀"1"。同样，根节点的左子树的右子树下的所有节点的ID一定有前缀"01"，等等，依此类推。 我们设想一下节点不断得往这个二叉树添加的过程。刚开始只有一个根节点，它也就是叶节点，这时它内部的CRoutingBin是有意义的，当联系人信息不 断得被添加进去以后，这个CRoutingBin的容量满了，这时要进行的就是一个分裂的操作。这时，会添加两个左子节点和右子节点，然后把自身的 CRoutingBin中的联系人信息按照它们的前缀特点分别复制往左节点和右节点，最后把自身的CRoutingBin废除掉，这样这个分裂过程就完 了。当分裂完成后，就会再次试图添加该联系人信息，此时会试图按照它的ID，把它添加到对应的子树中。但是并不是所有的这种情况节点都会发生分裂，因为如 果允许任意分裂的话，本地所需存储的节点信息数量就会急剧上升。这里，自身ID的作用就体现了。只有当自身ID和当前准备分裂的节点有共同前缀时，这个节 点才会分裂，而如果判断到一个节点不能分裂，而它的CRoutingBin又满掉了，那么就会拒绝添加联系人信息。
我们可以看出，在以上 政策的进行下，离自身ID逻辑距离越近(也就是共同前缀越长)的联系人信息越有可能被加入，因为它所对应的节点越有可能因为分裂而获得更多的子节点，也就 对应了更多的容量。这样，在Kademlia网中，每一个参与者知道的其它参与者信息中，离自己逻辑距离越近的参与者比例越高。由于在搜索的时候也只需要 不断得寻找更近的ID，而且每一步都一定会有进展，所以寻找到目标ID所需要的时间上的代价是O(logn)，从这个二叉树的结构来看，我们也可以看到， 由于只有部分节点会分裂，所以实质上存储所需要的空间代价也是O(logn)。
实际上CRoutingZone在实现时和理论上的Kademlia有一些区别，如从根节点开始，有一个最低分裂层数，也就是说，如果层数过低的话，是永远允许分裂的，这样它知道的其它地区的联系人信息就能够稍微多一些。
eMule中的Kademlia网络消息处理
CKademliaUDPListener 负责处理所有和Kademlia网相关的消息。前面已经对emule的通信协议的基本情况做了一个大概的描述，我们就可以知 道，CKademliaUDPListener处理的消息一定是只和Kademlia网相关的，分拣工作已经在emule的普通UDP客户端处理代码那里 处理好了。具体的消息格式前面也有一些介绍，下面会就一些具体的消息分类做说明。
首先是健康检查方面的消息，这样的消息就是一般的 ping-pong机制。对应的消息有KADEMLIA_HELLO_REQ和KADEMLIA_HELLO_RES。当对本地联系人信息列表进行检查 时，会对它们发出KADEMLIA_HELLO_REQ消息，然后处理收到的KADEMLIA_HELLO_RES消息。
最常用的消息是 节点搜索消息，在Kademlia网络中，进行节点搜索是日常应用所需要传输的主要消息，它的实现方式是迭代式的搜索。这种方式就是说当开始搜索某个ID 时，在本地联系人信息列表中查找到距离最近的联系人，然后向它们发出搜索请求，这样通常都能够得到一些距离更近的联系人信息，然后再向它们发送搜索请求， 通过不断得进行这样的搜索查询，就能够得到距离目标ID最近的那些联系人信息。这里对应的消息代码是KADEMLIA_REQ和 KADEMLIA_RES。
接下来就是对内容进行发布或者搜索。这一点结合后面的CIndexed类的分析可以知道得更加清楚。 emule中存储在Kademlia网中的信息主要有三类：文件源，关键字信息和文件的评论。文件源对应的是每一个具体的文件，每个文件都用它的内容的 hash值作为该文件的唯一标示，一条文件源信息就是一条关于某人拥有某个特定的文件的这样一个事实。一条关键字信息则是该关键字对应了某个文件这样一个 事实。很显然，一个关键字可能会对应多个文件，而一个特定的文件的文件源也很有可能不止一个。但是它们的索引都以固定的hash算法作为依据，这样使得搜 索和发布都变得很简单。
我们来看发布过程。每个emule客户端把自己的共享文件的底细已经摸清楚了，在传统的有中心索引服务器的场景 里，它把自己的所有文件的信息都上传到中心索引服务器里。但是在Kademlia网里，它就需要分散传播了，它首先做的事情是把文件名进行切词，即从文件 名中分解出一个一个的关键词出来，它切词的方法非常简单，就是在文件名中寻找那些有分割符含义的字符，如下划线等，然后把文件名切开。计算出这些关键字的 hash值后，它把这些关键字信息发布到对应的联系人那里。并且把文件信息也发布到和文件内容hash值接近的联系人那里。对应的消息是 KADEMLIA_PUBLISH_REQ和KADEMLIA_PUBLISH_RES。另外emule允许用户对某个文件发表评论，评论的信息单独保 存，但是原理也是一样的。
当用户使用Kademlia网络来进行搜索并且下载文件的时候，首先是对一个关键词进行搜索，由于使用的是同样 的hash算法，这样它只要找到ID值和计算出来的hash值结果相近的联系人信息后，它就可以直接向它们发送搜索特定关键词的请求了。如果得到了返回信 息，那么搜索者就知道了这个关键词对应了多少文件，然后把这些文件的信息都列出来。当用户决定下载某个文件的时候，针对这一特定文件的搜索过程就开始了， 这一次如果搜索成功，那么返回的就是这个文件的文件源信息。这样emule接下来就只需要按照这些信息去连接相应的地址，并且使用传统的emule协议去 和它们协商下载文件了。这里对应的消息是KADEMLIA_SEARCH_REQ和KADEMLIA_SEARCH_RES。
实际的实现 中有Kademlia2这种协议，它的原理是一样的，只有协议代码和具体的消息格式不一样，例如KADEMLIA_REQ和KADEMLIA_RES对应 了KADEMLIA2_HELLO_REQ和KADEMLIA2_HELLO_RES，但是后者在具体的消息中包含了比前者丰富一些的信息。在实现的时候 0.47c更加倾向于使用Kademlia2，而0.47a更加倾向于使用Kademlia。当然，它们两种协议都能够处理。另外，0.47c增加了一个 对于已发出的请求的追踪的特性，就是一个包含TrackPackets_Struct类型的列表，这里面详细纪录了什么时间曾经对哪个IP发出过那种 opcode对应的请求。为什么要这样呢？这是为了防止针对DHT的一种路由污染攻击，因为在搜索联系人的时候，如果搜索到了一些联系人信息，也会试图把 它先加入到本地的联系人信息列表中。这样如果有人想恶意攻击的话，它只要不断得往它想攻击的emule客户端发送KADEMLIA_RES，并且在消息的 内容中包含大量的虚假联系人信息，就可以使对方的联系人信息列表中充满垃圾。这样，由于缺少正确有效的联系人信息，它的Kademlia网功能基本上就废 了。而在0.47c里面增加的这个特性，就会对那种还没有发出请求就收到回应的情况直接无视，从而避免被愚弄。
emule中的Kademlia的分布式索引管理
Kademlia 网络的最大的好处是把原来需要存储到中心索引服务器中的信息分散存储到各个客户端当中，如果要说得更加准确一点，那我们就可以说它把这些信息分散得存储到 各个emule客户端的CIndexed类当中。我们可以具体开始看CIndexed的设计，看它是如何完成这一工作的。在这之前我们要稍微详细得说一下 emule发布到Kademlia网络中的信息的各种类型。
一个文件源信息是一个文件内容的hash值和拥有这个文件的客户端的IP地 址，各种端口号以及其它信息之间的对应关系。而一个关键词信息则是该关键词和它对应的文件之间的关系。在关键词信息中，它对应的文件信息要更加详细，通常 包括这个文件的文件名，文件大小，文件内容的hash值，如果是MP3或者其它媒体文件，还会包含包括作者，生产时间，文件长度(这个长度是用时间来衡量 的媒体文件的播放长度)，流派等等tag信息。其中文件内容的hash值用来区分该关键词对应的不同文件。
CIndexed中利用了一系 列的Map来存储这些对应信息，CMap是MFC中实现标准STL中的map的模板类，CIndexed中包含了四个这样的类，分别用来存储文件源信息， 关键词信息，文件评论信息以及负载信息。其中文件评论信息是不长久保存的，而其它的信息都会在退出的时候写到文件中，下次重新启动emule时再重新调 入。另外负载信息不是等其它联系人来发布的，而是根据文件源信息和关键词信息的发布情况自行进行动态调整的。每一次收到发布信息时，对应的ID的负载会增 大，这一事实会在回应消息(KADEMLIA_PUBLISH_RES)中体现。
CIndexed中的信息会经常进行检查，每隔三十分钟 它会把自己存储的所有信息中太老的信息清除掉。其中文件源信息的保存时间为五小时，关键词信息为二十四小时，文件评论的信息保存时间也为二十四小时。因此 文件的发布和关键词也要周期性得反复进行。其实这对于整个Kademlia网络的稳定性也是有好处的，因为每一次联系都会试图把对方添加到自己的联系人列 表中，或者在联系人列表中标注上一次见到对方的时间。
CIndexed为其它部分的代码提供了它们所需要的增加信息和搜索信息的接口，这样在从网络中获取到相关的搜索或者发布请求，并且CKademliaUDPListener完成消息的解释后，就可以交给CIndexed来进行处理了。
emule中的Kademlia搜索任务管理
CSearch 和CSearchManager是完成具体搜索任务的。CSearch对应的是一个具体的搜索任务，它包括了一个搜索任务从发起到结束的全部过程，要注意 的是搜索任务并不只是指搜索文件源或者关键词的任务，一次发布任务它也需要创建一个CSearch对象，并且让它开始执行。CSearchManager 则掌握所有的搜索任务，它包含了一个包含所有CSearch指针对象的CMap，使用CMap的原因是因为所有的CSearch都一定对应一个ID，那个 ID就是该CSearch所对应的目标，不管是要查找节点，还是要搜索或者发布信息，一定都要找到和目标ID相近的联系人。因此 CSearchManager可以使用CMap来表示所有的搜索任务。
我们注意到CSearch在创建的时候就把自己加入到 CSearchManager当中。另外CSearch在创建的时候需要说明它的类型，例如是只是为了搜索节点还是要搜索关键词信息或者文件源信息，当然 也有可能是发布文件源信息或者关键词信息。我们介绍一下CSearch的几个方法的作用就可以大概了解CSearch的工作过程。Go是它的启动过程，它 会开始第一次从本地的联系人列表中寻找候选的联系人，然后开始发动搜索。SendFindValue的功能就是向某个联系人发送一个搜索某ID的联系人信 息这样一个请求。JumpStart则是在搜索进行到一定地步的时候，如得到了一些中间结果，开始进行下一步的行动，下一步的行动仍然可能是 SendFindValue，也有可能认为搜索到的联系人离目标已经足够近了，于是就可以开始实质性的请求。StorePacket就是这样一个实质性的 请求，例如在一个以发布文件源为任务的CSearch中，StorePacket会向目标联系人发送 KADEMLIA2_PUBLISH_SOURCE_REQ(如果不支持Kademlia2，那么是KADEMLIA_PUBLISH_REQ)。最 后，CSearch能够处理各种搜索结果，然后向调用它的代码返回处理好的结果。
CSearchManager直接和Kademlia网 的其它部分代码接触，例如，如果CKademliaUDPListener搜索到了一些结果，它会把这些结果交给CSearchManager，然后 CSearchManager再去寻找这个结果是属于那个搜索任务的，并且进行转交。另外CSearchManager对外提供创建各种新的搜索任务的接 口，作用类似于设计模式中的Factory，其它部分的代码只需要说明需要开始一个什么样的搜索任务即可，CSearchManager来完成相应的创建 CSearch的任务。
扫一扫
4795
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
