11
2.3文件搜索
图2.5描述了文件搜索顺序
文件搜索是由用户发起的。这个操作简单，一个搜索要求（见6.2.9节）发送到服务器，然后服务器用一个搜索结果回应。当有很多结果时，搜索结果消息就会被压缩。接着，用户选择下载一个或多个文件，客户端就要求源为选中的文件和服务器返回每个要求文件的源队列（见6.2.12节）。就在回应发现的源之前，可以发送一个可选的服务器状态消息。这个状态消息（6.2.6节）包含关于当前用户数量和服务器支持的文件等信息。重要注意的是，UDP消息有个补充顺序事件，用来增强客户端为它搜索的文件定位源的能力，详细的细节见第3章。在检验出源是新的之后，eMule客户端开始尝试连接和把它们加入到它的源列表。源联系的顺序就是eMule客户端接收到它们的顺序。图2.5描述了文件搜索顺序。
eMule客户端根据源加入到它的列表中的顺序来连接源。没有优先机制来决定连接那个源。当可以要求同一个源来下载客户端下载列表中的几个文件时，有一种复杂的机制来解决这个局面（注意，载客户端之间eMule只允许一个单独的上传连接）。选择算法是基于用户优先规则，当没有指定优先时，默认是字母顺序。关于处理可以上传多于一个文件的源的详细描述，可以在网站中找到。
2.4 回调机制
回调机制是设计来克服低ID客户端不能接收输入的连接的，这样客户端之间就能共享它们
12
的文件。机制很简单：假如客户端A和B都连接到同一个eMule服务器，A需要的文件在B上，但B是低ID的，A可以向服务器发送一个回调请求（见6.2.13节），请求服务器叫B呼叫回它。服务器，已经有一个与B的打开的TCP连接，发送一个回调请求消息（见6.2.14节）到B，为它提供A的IP和端口。B就能连接到A并发送文件，没有给服务器增加负担。很明显，只有高ID客户端可以要求低ID客户端回调（低ID客户端是没有接收输入连接的能力的）。图2.6图解了回调消息交换。
也有允许两个低ID客户端交换文件的能力，通过它们的服务器连接，用服务器接力。大部分服务器不再提供这个选项，因为它招致服务器的负担。
3 客户端服务器的UDP交流
eMule客户端和服务器用不可靠的UDP服务来保持连接和增强搜索。eMule客户端产生UDP包的总量可以达到它发送包的总数目的5% - 这些根据客户端服务器列表中服务器的数目，客户端下载列表中每个文件的源数目和用户执行的搜索数目而定。UDP包通过计时器触发，计时器每100ms过期，有一个单独的线程负责发送UDP输送结果，以每秒10个UDP的最大速率。
3.1 服务器保持连接和状态信息
客户端周期性验证它服务器列表中的服务器状态。验证是通过发送UDP服务器状态请求（见6.3.3节）和UDP服务器描述请求（见6.3.7节）消息完成的。这里描述的简单保持连接计划每小时产生不超过几打包。任何情况下，包的最大速率是每秒0.2个包（或每5秒一个包）。当检查服务器的状态时，客户端会首先发送一个服务器状态请求消息，接着，每两次试图（发
13
送一个服务器状态请求）中就发送一次服务器描述请求，见图3.1。
客户端发送的服务器状态请求中包括一个随机数字，在服务器回应中返回。在服务器返回的数字与客户端发送的要求中数字不同的情况下，回应的信息就会被丢弃。每次发送到服务器的包是状态请求，客户端就移动尝试计数器。任何来自服务器的消息（包括搜索结果）都重置尝试计数器。当尝试计数器达到一个可配置的限制时，服务器就认为是死机，从客户端的服务器列表中删除。服务器回应包括几个数据项：服务器状态回应（见6.3.4）包括服务器中当前用户数目和文件数目，也包括服务器的软件和硬件限制（见1.7节）。服务器描述回应（见6.3.8节）包括服务器名称和一个短的描述字符串。图3.2演示了客户端和活动服务器中满连接序列的消息流。
14
3.2 增强文件搜索
eMule客户端可以设置用UDP来增强它的文件搜索。UDP搜索结果格式几乎与？？节描述的TCP搜索请求一样。服务器只在有了搜索结果才回应。UDP搜索结果消息有两种不同的opcdes，我也无法说清它们之间的不同。UDP搜索包发送到客户端服务器列表中的服务器上。更多信息见6.3.5节和6.3.6节。
3.3 增强文件源搜索
当客户端下载列表中的特定文件的源数目小于配置限制（100）时，客户端就周期性地发送获取源的UDP包到它的服务器列表中的服务器中为该文件寻找更多的源。可能每秒发送一个包，使得源搜索在客户端产生的UDP输送中成为可观的部分。消息的格式（6.3.1节描述）非常相似它的TCP计数器部分。注意，与TCP源搜索相反，UDP源搜索在文件搜索中减弱，对于指定的文件，只是依靠客户端拥有的源数目。
15