下载本文示例代码
在注册服务器以后以及查询文件和源之后，电骡客户端需要联系其他客户端来下载文件。一个专一 TCP 连接为每文件和客户端对创建。当没有 SOCKET 活动持续一个阶段（默认的 40 秒）或对端关闭了连接的时候连接会被关闭。 为了提供合理的下载速率，电骡并不允许一个客户端下载文件，直到电骡能够提供（所有其他下载客户端）最少允许的速率时（这是一个硬编码，当前设置为 2.4KB/s ）。 1.1 初始化握手 初始化握手是对称的，双方都发送给彼此发送同样的信息。客户端交互彼此包含的标示、版本和容量信息。参与的消息有两种类型 -Hello 消息（ 6.4.1 节）和电骡信息消息（ 6.5.1 ），第一个是 eDonkey 的一部分，并且和 eDonkey 客户端兼容；第二个是电骡扩展协议的一部分。图 4.1 描述了两个电骡客户端之间的握手过程。扩展信息中包含的是 UDP 报文交换、安全标示和源交换能力。 图 4.1 ：电骡客户端初始化握手过程 1.2 安全用户标示 1.4 节简短的解释了用户 ID 和假装其他用户的动机。安全用户表示是电骡扩展协议的一部分。如果客户端支持安全标示，它在初始化握手之后立即执行。安全标示的目的是防止用户伪装。使用安全标示时，执行下面的步骤： 1． 在初始化握手的时候， B 只是它支持并期望使用安全标示 2． A 以发送安全标示报文来响应（ 6.5.8 节），这个报文指出是否 A 需要 B 的公钥，并且包含一个 4 个字节口令由 B 签名是使用。 3． 如果 A 指出她需要 B 的公钥，那么 B 将它的 KEY 发给 A （ 6.5.9 节） 4． B 发送签名的报文（ 6.5.10 ），其使用 A 发送的口令来创建的，另外双字是 A 的 IP 地址，如果 B 是低 ID 或高 ID 。图 4.2 描述这个序列。 图 4.2 ：安全标示流程 1.2.1 信用系统 本节简单介绍客户端的信誉系统。信誉系统的目的是鼓励用户共享文件。当客户端上传文件给其他端时，下载的客户端根据传输数据库的数量更新其信誉值。注意，信誉系统不是全局的，一个传输的信誉值被正在下载的客户端保存在本地并且仅仅当上传客户端（获得信誉的）从这个指定客户端请求下载时候才被重新考虑。信誉这样计算的： 1．总共上传 *2/ 总共下载的 当总下载数是 0 的时候这个表达式是 10 2．总共上传 2 的平方根 当总上传小于 1MB 时候，表达式为 1 上传/下载数量以 MB 计算。无论什么情况信誉值不能大于 10 或小于 1 。 1.3 请求文件 就如前面提到的为每个 [ 客户端、文件 ] 对创建一个单独的连接。在连接建立之后，客户端理解发送几个查询关于其期望下载文件的报文。典型的，这里描述成功的场景。见图 4 。 3 。 1.3.1 基本报文交换 基本报文交换由四个报文组成： A 发送一个文件请求报文（ 6.4.18 节），紧接着一个请求文件 ID 的报文（ 6.4.17 节）。 B 响应这个文件请求是一个文件请求的响应（ 6.4.15 节），以文件状态报文（ 6.4.18 节）响应请求的文件 ID 报文。我不能找到任何原因来在这四个报文中发送的分割信息；仅仅以两个报文来处理 ( 请求和响应 ) 。 扩展协议对这个序列添加了两个报文，一个是源请求（ 6.5.6 节），一个是源响应（ 6.5.7 节）。这个扩展用来传递 B 的源（如果 B 当前正在下载文件）到 A 。没有要求 B 在发送文件片给其他客户端的之前需要完成下载， B 可以将其完全下载的任何小部分发送给 A ，即使只有一个文件的分片下载完成。 图 4.3 ：文件请求 1.3.2 文件没有找到的场景 当 A 从 B 请求文件，但 B 的共享文件列表中没有这个文件的时候， B 忽略这个文件请求回答报文，并且立即在请求文件 ID 报文后面发送一个文件未找到报文（ 6.4.16 节），如图 4.4 所示： 图 4.4 ，文件请求失败 - 文件没有找到 1.3.3 获得上传队列 B有请求文件，但它的上传队列没有空间了，也就是有客户端正在下载文件，并且有可能 A 和 B 上传队列的客户端执行图 4.3 的完全握手时 A 请求 B 开始上传文件， B 将 A 添加到 A 的上传队列中，并且回应排行报文（ 6.5.4 节），这个报文中包含了 A 在 B 的上传队列中的位置。 1.3.4 上传队列管理 对于每个上传的文件，客户端都维护一个上传优先级队列。在队列中的每个客户端的优先级是按照客户在队列中的时间和优先级修饰符号来确定。在队列的头部是那些拥有最高分的客户。分值的计算按照下面的公式：分 = （ rating* 在队列中的秒） /100 ，或无穷大（对于那些被定义为朋友的下载客户）。起初的 rating 值是 100 ，除非被禁止的用户，他的 rating 是 0 （并且也不可能得到队列的顶端）。 Rating 会被下载客户端的信誉值修改（变化范围是 1-10 ）或者通过上传文件优先级（ 0.2-1.8 ），这个是由上传客户端来设置的。当一个客户端的分比其他客户端分高的时候，它就开始下载文件。一个客户端会一直下载文件，只有下面情况发生的时候不同： 1．上传的客户端被用户终止了 2．下载客户端得到所有他需要的文件片 3．被另一个比当前下载客户端优先级高的客户端抢先了。 为了允许一个刚开始下载的客户端在被抢先之前能够下载一些 MB ， eMule 将正在下载客户端在起初的 15 分钟内设置 rating 设置到 200 。 1.3.5 到达上载队列的顶部 当 A 达到 B 上传队列的顶部的时候， B 连接到 A ，执行初始化握手以及发送一个接受上传请求的报文（ 6.4.11 节）。 A 现在可以选择继续下载请求命令中指定的文件，或者发送一个取消传输的报文（ 6.4.12 节）来取消下载（如果它已经从另外一个源得到这个部分）。图 4.6 解释这些选项。 图 4.6 ：文件请求继续下载 1.4 数据传输 1.4.1 数据包 发送和接收文件片是主要的 eMule 网络活动的主要部分。当所有剩下的 eMule 是控制的时， eMule 到 FTP 将得到发送文件和数据事物匹配。一个文件片可以是 5000 到 15000 字节，（依赖于压缩）。为了避免分片，一个文件片报文在一片中发送，每个 TCP 的片是单独的包。在 eMule0.30e 中，最大片大小是 1300 字节（注意，这仅仅和 TCP 负载有关）。换句话，当每个控制报文在一个单个 TCP 包发送的时候，有时和其他报文一起，数据报文被分割为几个 TCP 包。第一个包包含发送文件的信息头（ 6.4.3 节），其余的包都是数据。如果被发送的文件片不是 1300 的整数倍，那么这些多余的部分和第一个包一起发送（携带头的包）。图 4.7 描述了文件片报文。 图 4.7 ，文件片报文细节 1.4.2 数据传输序列 在文件请求响应之后，一部分传输序列可以理解开始。下载客户端 A 发送一个起始的上传请求（ 6.4.10 节）， B 以一个接受上传请求的报文（ 6.4.11 节）响应该报文。在这之后， A 开始请求文件片（ 6.4.4 节）， B 响应请求的文件片（ 6.4.3 节），注意，单个文件片请求可能请求 3 片，因此每个文件片请求可能有 3 个发送部分序列来响应。 当两个支持扩展客户端协议的客户端时，文件片可能是压缩之后发送的（ 6.5.3 节）。扩展的文件协议也支持一个可选文件信息报文（ 6.5.5 节），这个可能在接受上传请求报文之前发送。片传输报文序列如 4.8 图所示： 图 4.8 ：文件片交互 1.4.3 选择下载那一片 eMule 选择性的选择片的下载顺序，目的是最大化整个网络的吞吐量和共享。每个文件被分成 9.28MB 字节片，并且每片被分成 180KB 快。片下载的顺序是由请求文件分片的下载客户端决定。下载客户端可以在任何给定瞬间从每个源下载一个单个片，以及驻留在同一个片中来自同一个源的所有请求块。下面原则在下载片时使用（以这个顺序）： 1．数据的可用频率，非常少的快应该尽量快下载，从而成为新的可用源 2．用于预览的片（第一个 最后一个块），预览或检查一个文件（例如：电影、 MP3 ）。 3．请求状态（正在下载中），试着想向每个源询问另一个块，在所有源之间广播请求。 4．完成（最短 - 到完成），应该在开始下载另一个块之前局部地得到块。 频繁标准定义 3 个 0 ：非常少、少和通常。标准为每个 0 注定权重，其用来计算片速率。较低速率片首先下载。根据上面的原则下面的列表指出了文件速率变化的范围。 ·0-9999 未请求和请求的非常稀少的片 ·10000-19999 未请求的稀少的和预览片 ·20000-29999 未请求的最完成通用片 ·30000-39999 请求的稀少预览片 ·40000-49999 请求的未完成通用片 这个算法通常首先选择最稀少的片，然而，部分完成的片且接近完成的片可能也会被选择。对于通用的片，下载会在不同源之间广播。 1.5 浏览共享文件和文件夹 处理浏览对端共享文件和文件夹的有两个报文流程。第一个是查看共享文件报文（ 6.4.21 节），在握手之后理解发送。这个报文以查看共享文件答复来响应（ 6.4.22 节）。当响应的客户端期望隐藏它的共享文件链表时，答复包含 0 个文件（而不是发送一个报文说不能访问），图 4.9 描述报文序列。 图 4.9 ：查看文件 第二个报文流程以查看共享文件夹列表的报文开始（ 6.4.23 节），该报文以共享文件夹列表响应（ 6.4.24 节），对于响应中的每个文件夹都会发送一个浏览共享文件夹内容的报文（ 6.4.25 ）。这样的报文以内容列表回复（ 6.4.26 节）。图 4.10 描述这个报文序列。 一旦接收客户端被配置为块共享文件或文件夹请求，它恢复一个询问共享拒绝的报文，如图 4.11 所示。 图 4.10 ：查看共享文件或文件夹 图 4.11 ：查看共享拒绝 1.6 交换片的 hashset 为了能够片哈希值， hashset 请求被发送（ 6.4.8 节），这个请求以一个 hashset 来响应（节 6.4.9 ），其中包含了文件中每个片的 hashset 。图 4.12 描述这个过程： 图 4.12 ： hashset 请求 1.7 得到文件的预览 客户端可以请求他的对端来得到一个下载文件的预览。预览是程序独立的，并且根据文件的类型不同而变化。 eMule0 0.30e 仅仅支持图像预览。这个报文交换过程在图 4.13 中描述，包含两个报文：预览请求（ 6.5.11 节）和预览回复（ 6.5.12 节）。 图4.13 ：得到文件预览
在注册服务器以后以及查询文件和源之后，电骡客户端需要联系其他客户端来下载文件。一个专一 TCP 连接为每文件和客户端对创建。当没有 SOCKET 活动持续一个阶段（默认的 40 秒）或对端关闭了连接的时候连接会被关闭。 为了提供合理的下载速率，电骡并不允许一个客户端下载文件，直到电骡能够提供（所有其他下载客户端）最少允许的速率时（这是一个硬编码，当前设置为 2.4KB/s ）。 1.1 初始化握手 初始化握手是对称的，双方都发送给彼此发送同样的信息。客户端交互彼此包含的标示、版本和容量信息。参与的消息有两种类型 -Hello 消息（ 6.4.1 节）和电骡信息消息（ 6.5.1 ），第一个是 eDonkey 的一部分，并且和 eDonkey 客户端兼容；第二个是电骡扩展协议的一部分。图 4.1 描述了两个电骡客户端之间的握手过程。扩展信息中包含的是 UDP 报文交换、安全标示和源交换能力。 图 4.1 ：电骡客户端初始化握手过程 1.2 安全用户标示 1.4 节简短的解释了用户 ID 和假装其他用户的动机。安全用户表示是电骡扩展协议的一部分。如果客户端支持安全标示，它在初始化握手之后立即执行。安全标示的目的是防止用户伪装。使用安全标示时，执行下面的步骤： 1． 在初始化握手的时候， B 只是它支持并期望使用安全标示 2． A 以发送安全标示报文来响应（ 6.5.8 节），这个报文指出是否 A 需要 B 的公钥，并且包含一个 4 个字节口令由 B 签名是使用。 3． 如果 A 指出她需要 B 的公钥，那么 B 将它的 KEY 发给 A （ 6.5.9 节） 4． B 发送签名的报文（ 6.5.10 ），其使用 A 发送的口令来创建的，另外双字是 A 的 IP 地址，如果 B 是低 ID 或高 ID 。图 4.2 描述这个序列。 图 4.2 ：安全标示流程 1.2.1 信用系统 本节简单介绍客户端的信誉系统。信誉系统的目的是鼓励用户共享文件。当客户端上传文件给其他端时，下载的客户端根据传输数据库的数量更新其信誉值。注意，信誉系统不是全局的，一个传输的信誉值被正在下载的客户端保存在本地并且仅仅当上传客户端（获得信誉的）从这个指定客户端请求下载时候才被重新考虑。信誉这样计算的： 1．总共上传 *2/ 总共下载的 当总下载数是 0 的时候这个表达式是 10 2．总共上传 2 的平方根 当总上传小于 1MB 时候，表达式为 1 上传/下载数量以 MB 计算。无论什么情况信誉值不能大于 10 或小于 1 。 1.3 请求文件 就如前面提到的为每个 [ 客户端、文件 ] 对创建一个单独的连接。在连接建立之后，客户端理解发送几个查询关于其期望下载文件的报文。典型的，这里描述成功的场景。见图 4 。 3 。 1.3.1 基本报文交换 基本报文交换由四个报文组成： A 发送一个文件请求报文（ 6.4.18 节），紧接着一个请求文件 ID 的报文（ 6.4.17 节）。 B 响应这个文件请求是一个文件请求的响应（ 6.4.15 节），以文件状态报文（ 6.4.18 节）响应请求的文件 ID 报文。我不能找到任何原因来在这四个报文中发送的分割信息；仅仅以两个报文来处理 ( 请求和响应 ) 。 扩展协议对这个序列添加了两个报文，一个是源请求（ 6.5.6 节），一个是源响应（ 6.5.7 节）。这个扩展用来传递 B 的源（如果 B 当前正在下载文件）到 A 。没有要求 B 在发送文件片给其他客户端的之前需要完成下载， B 可以将其完全下载的任何小部分发送给 A ，即使只有一个文件的分片下载完成。 图 4.3 ：文件请求 1.3.2 文件没有找到的场景 当 A 从 B 请求文件，但 B 的共享文件列表中没有这个文件的时候， B 忽略这个文件请求回答报文，并且立即在请求文件 ID 报文后面发送一个文件未找到报文（ 6.4.16 节），如图 4.4 所示： 图 4.4 ，文件请求失败 - 文件没有找到 1.3.3 获得上传队列 B有请求文件，但它的上传队列没有空间了，也就是有客户端正在下载文件，并且有可能 A 和 B 上传队列的客户端执行图 4.3 的完全握手时 A 请求 B 开始上传文件， B 将 A 添加到 A 的上传队列中，并且回应排行报文（ 6.5.4 节），这个报文中包含了 A 在 B 的上传队列中的位置。 1.3.4 上传队列管理 对于每个上传的文件，客户端都维护一个上传优先级队列。在队列中的每个客户端的优先级是按照客户在队列中的时间和优先级修饰符号来确定。在队列的头部是那些拥有最高分的客户。分值的计算按照下面的公式：分 = （ rating* 在队列中的秒） /100 ，或无穷大（对于那些被定义为朋友的下载客户）。起初的 rating 值是 100 ，除非被禁止的用户，他的 rating 是 0 （并且也不可能得到队列的顶端）。 Rating 会被下载客户端的信誉值修改（变化范围是 1-10 ）或者通过上传文件优先级（ 0.2-1.8 ），这个是由上传客户端来设置的。当一个客户端的分比其他客户端分高的时候，它就开始下载文件。一个客户端会一直下载文件，只有下面情况发生的时候不同： 1．上传的客户端被用户终止了 2．下载客户端得到所有他需要的文件片 3．被另一个比当前下载客户端优先级高的客户端抢先了。 为了允许一个刚开始下载的客户端在被抢先之前能够下载一些 MB ， eMule 将正在下载客户端在起初的 15 分钟内设置 rating 设置到 200 。 1.3.5 到达上载队列的顶部 当 A 达到 B 上传队列的顶部的时候， B 连接到 A ，执行初始化握手以及发送一个接受上传请求的报文（ 6.4.11 节）。 A 现在可以选择继续下载请求命令中指定的文件，或者发送一个取消传输的报文（ 6.4.12 节）来取消下载（如果它已经从另外一个源得到这个部分）。图 4.6 解释这些选项。 图 4.6 ：文件请求继续下载 1.4 数据传输 1.4.1 数据包 发送和接收文件片是主要的 eMule 网络活动的主要部分。当所有剩下的 eMule 是控制的时， eMule 到 FTP 将得到发送文件和数据事物匹配。一个文件片可以是 5000 到 15000 字节，（依赖于压缩）。为了避免分片，一个文件片报文在一片中发送，每个 TCP 的片是单独的包。在 eMule0.30e 中，最大片大小是 1300 字节（注意，这仅仅和 TCP 负载有关）。换句话，当每个控制报文在一个单个 TCP 包发送的时候，有时和其他报文一起，数据报文被分割为几个 TCP 包。第一个包包含发送文件的信息头（ 6.4.3 节），其余的包都是数据。如果被发送的文件片不是 1300 的整数倍，那么这些多余的部分和第一个包一起发送（携带头的包）。图 4.7 描述了文件片报文。 图 4.7 ，文件片报文细节 1.4.2 数据传输序列 在文件请求响应之后，一部分传输序列可以理解开始。下载客户端 A 发送一个起始的上传请求（ 6.4.10 节）， B 以一个接受上传请求的报文（ 6.4.11 节）响应该报文。在这之后， A 开始请求文件片（ 6.4.4 节）， B 响应请求的文件片（ 6.4.3 节），注意，单个文件片请求可能请求 3 片，因此每个文件片请求可能有 3 个发送部分序列来响应。 当两个支持扩展客户端协议的客户端时，文件片可能是压缩之后发送的（ 6.5.3 节）。扩展的文件协议也支持一个可选文件信息报文（ 6.5.5 节），这个可能在接受上传请求报文之前发送。片传输报文序列如 4.8 图所示： 图 4.8 ：文件片交互 1.4.3 选择下载那一片 eMule 选择性的选择片的下载顺序，目的是最大化整个网络的吞吐量和共享。每个文件被分成 9.28MB 字节片，并且每片被分成 180KB 快。片下载的顺序是由请求文件分片的下载客户端决定。下载客户端可以在任何给定瞬间从每个源下载一个单个片，以及驻留在同一个片中来自同一个源的所有请求块。下面原则在下载片时使用（以这个顺序）： 1．数据的可用频率，非常少的快应该尽量快下载，从而成为新的可用源 2．用于预览的片（第一个 最后一个块），预览或检查一个文件（例如：电影、 MP3 ）。 3．请求状态（正在下载中），试着想向每个源询问另一个块，在所有源之间广播请求。 4．完成（最短 - 到完成），应该在开始下载另一个块之前局部地得到块。 频繁标准定义 3 个 0 ：非常少、少和通常。标准为每个 0 注定权重，其用来计算片速率。较低速率片首先下载。根据上面的原则下面的列表指出了文件速率变化的范围。 ·0-9999 未请求和请求的非常稀少的片 ·10000-19999 未请求的稀少的和预览片 ·20000-29999 未请求的最完成通用片 ·30000-39999 请求的稀少预览片 ·40000-49999 请求的未完成通用片 这个算法通常首先选择最稀少的片，然而，部分完成的片且接近完成的片可能也会被选择。对于通用的片，下载会在不同源之间广播。 1.5 浏览共享文件和文件夹 处理浏览对端共享文件和文件夹的有两个报文流程。第一个是查看共享文件报文（ 6.4.21 节），在握手之后理解发送。这个报文以查看共享文件答复来响应（ 6.4.22 节）。当响应的客户端期望隐藏它的共享文件链表时，答复包含 0 个文件（而不是发送一个报文说不能访问），图 4.9 描述报文序列。 图 4.9 ：查看文件 第二个报文流程以查看共享文件夹列表的报文开始（ 6.4.23 节），该报文以共享文件夹列表响应（ 6.4.24 节），对于响应中的每个文件夹都会发送一个浏览共享文件夹内容的报文（ 6.4.25 ）。这样的报文以内容列表回复（ 6.4.26 节）。图 4.10 描述这个报文序列。 一旦接收客户端被配置为块共享文件或文件夹请求，它恢复一个询问共享拒绝的报文，如图 4.11 所示。 图 4.10 ：查看共享文件或文件夹 图 4.11 ：查看共享拒绝 1.6 交换片的 hashset 为了能够片哈希值， hashset 请求被发送（ 6.4.8 节），这个请求以一个 hashset 来响应（节 6.4.9 ），其中包含了文件中每个片的 hashset 。图 4.12 描述这个过程： 图 4.12 ： hashset 请求 1.7 得到文件的预览 客户端可以请求他的对端来得到一个下载文件的预览。预览是程序独立的，并且根据文件的类型不同而变化。 eMule0 0.30e 仅仅支持图像预览。这个报文交换过程在图 4.13 中描述，包含两个报文：预览请求（ 6.5.11 节）和预览回复（ 6.5.12 节）。 图4.13 ：得到文件预览
下载本文示例代码
电骡协议规范之客户端到客户端TCP连接电骡协议规范之客户端到客户端TCP连接电骡协议规范之客户端到客户端TCP连接电骡协议规范之客户端到客户端TCP连接电骡协议规范之客户端到客户端TCP连接电骡协议规范之客户端到客户端TCP连接电骡协议规范之客户端到客户端TCP连接电骡协议规范之客户端到客户端TCP连接电骡协议规范之客户端到客户端TCP连接电骡协议规范之客户端到客户端TCP连接电骡协议规范之客户端到客户端TCP连接电骡协议规范之客户端到客户端TCP连接电骡协议规范之客户端到客户端TCP连接电骡协议规范之客户端到客户端TCP连接电骡协议规范之客户端到客户端TCP连接
