电骡协议规范-第一章：概述

1       介绍

1.1                        目的和范围

电骡是基于电驴协议的流行的文件共享程序。本报告描述电骡的网络行为，并解释需要理解协议的基本技术。本报告提供一个完整电骡网络协议规范，包含一个附录，其中提供信息格式。本文档中的信息是基于开源的电骡客户端。下面介绍的目介绍通用的背景，方便读者理解本文档，在 [3] 中可以找到其他的电骡信息源。

1.2                        概述

电骡网络是由几百个电骡服务器和上百万的电骡客户端 [1] 组成。客户端应该连接到服务器而获得网络服务，只要客户端在系统中，服务器连接一直打开。服务器执行集中式的索引服务（和在 Napster 的一样），它不会和其他服务器通讯。

每个电骡客户端预配置一个服务器链表和本地文件系统中的共享文件列表。客户端登录到网络是使用单一 TCP 连接到电骡服务器，从服务器得到所要的文件和在线的客户端。同时电骡客户端和其他客户端之间有几百个 TCP 连接来上传和下载文件。每个电骡客户端维护一个上载的共享队列。正在下载的客户端首先加入到队列的底部，逐渐的向前，直到到达队列的定部才开始下载该文件。客户端可以从几个其他的电骡客户端下载同一个文件，从每个客户端取不同的分片。客户端也可以上传没有完全下载的文件块；最后，电骡扩展了电驴的能力，允许客户端交换服务器、其他客户端和文件的信息。注意客户和服务器通讯都是基于 TCP 的。

服务器使用一个内部数据库，数据库中存储客户端和文件的信息。一个电骡服务器并不存储任何文件，它仅仅扮演文件位置信息的集中索引；另一个功能是作为穿过防火墙的客户端连接以及不能接受输入连接的客户端之间桥梁。桥梁的功能明显增加了服务器的负载。电骡使用 UDP 来增强客户端不依赖服务器和客户端的能力。客户端发送和接收 UDP 消息的行为对于客户端日常操作来说不是强制的，并且在防火墙阻止其放松和接受 UDP 消息时有点问题。

1.2.1                                            客户端到服务器的连接

客户端启动的时候使用 TCP 连接到某个电骡服务器，服务器提供一个客户端 ID 给该客户端（ 1.3 节），这个 ID 仅仅在客户端和服务器连接的生命周期内有效（注意，在客户端有高 ID 是，直到他 IP 地址改变的时候，它才会从所有的服务器受到相同的 ID ）。在客户端连接建立之后其发送共享的文件给服务器，服务器存储这些信息到内部数据库中，数据库中通常包含几万个可用文件或活动的客户端。电骡的客户端也将其他想下载的文件列表发送给服务器。第 2 节提供详细的电骡客户端和服务器之间 TCP 报文交互的描述。

在连接建立之后，电骡服务器将包含当前客户端需要下载的文件信息的其他客户端拥有的文件发送给当前客户端（这些客户端叫做源）；从这时开始，电骡客户端将和其他客户端之间建立连接， 1.2.2 介绍。

注意， TCP 连接的 C/S 在所有客户端会话过程中事情打开，在大部分由用户活动触发的起初握手事务之后，有时客户端发送文件查询请求，其以搜索结果响应，一个搜索事务后面通常是一个到源指定文件的查询，这个查询通常返回源（ IP 地址和端口）的列表，请求者可以从他们那里下载请求的文件。

UDP 用来和当前客户端连接的服务器之外的服务器通讯。 UDP 报文的目的是增强文件查找、源搜索增强和保活（保证电骡服务器列表中的所有服务器是有效的）。更多的客户端和服务器之间的报文交互在第 3 章介绍。

1.2.2                                            客户端到客户端的连接

电骡的客户端连接其他客户端的目的是下载文件；一个文件被分割成小块。客户端可以从几个不同的客户端下载同一个文件，当然从每一个得到的分片是不一样的。

两个客户端连接好之后，他们交换性能信息，并且协商一个下载（上传）开始。每个客户端都有一个下载队列，这里面保存了正在等待下载文件的客户端列表。当电骡客户端的下载队列是空的时候，一个下载请求可能立即导致一个下载的开始（除非，例如，请求者是被禁止的）。当下载队列不是空的，一个下载请求的结果是在客户端请求队列中添加一个新的记录；没有尝试过在一个给定时间内为每个客户端提供最小 2.4KB/s 的最小带宽而同时服务多个客户端。一个下载客户端可能被在等待队列先于他前面的客户端占先，在下载会话开始的 15 分钟内，电骡客户端下载队列排行被增加来阻止击溃（ thrashing ）。

当下载客户端到达下载队列的开始的时候，上传客户端初始化一个连接来将其需要的文件片发送给它。电骡客户端可能正在几个其他客户端的等待队列中并注册了下载同一个文件片。当从他们中的一个下载了一个完整的部分时，它不会通知剩下的客户端来让他们将自己删除，它只是将当它自己到达他们等待队列头的时候他们发送来的连接拒绝掉。

电骡客户端使用信用系统（见 1.4 节），目的是鼓励上传、并阻止外挂（假装电骡），电骡使用 RAS 公钥加密来保护信用系统的安全。

客户端连接可能使用一些电驴协议中没有定义的报文，这些报文叫做扩展协议。扩展协议用来实现信用系统、通常的信息交互（例如，更新服务器和源的列表）并且提高发送和接收压缩的文件分片的性能。

电骡客户端连接使用 UDP 仅仅在有限情况下，周期性的检查上传队列中对端客户端的状态，这些客户端正在等待下载文件。

1.3                        客户端 ID

客户端 ID 是在客户端和服务器之间建立连接握手的时候右服务器分配的 4 个字节标示。一个客户端 ID 在该服务器和客户端 TCP 连接的生命周期内有效，虽然万一客户端有一个高 ID 直到 IP 地址改变的时候被所有服务器分配同一个 ID 。客户端 ID 分成低 ID 和高 ID 。电骡服务器给那些不能接收输入连接的客户端通常分配一个低 ID ；由于低 ID 限制了客户端使用电骡网络，并且可能导致服务器拒绝客户端的连接。一个高 ID 是计算出来了的，基于客户端的 IP 地址按照下面的方式。本节从电骡协议的观点来描述客户端 ID 分配和意义 [3] 。一个高 ID 分配给一个客户端，其允许客户端自由的连接电骡他们主机 TCP 端口（默认的是 4662 ）。高 ID 的客户端使用电骡网络是没有限制的。当服务器不能打开到电骡客户端端口的 TCP 连接时，客户端将得到一个低 ID 。这通常是该客户端安装了一个防火墙其拒绝了输入连接。一个客户端在下面情况下可能也会被分配一个低的 ID ：

1．  当客户端通过 NAT 和代理服务器连接的时候

2．  当服务器忙的时候（导致服务器的重连接定时器溢出）。

高 ID 是按照下面的方式来计算的：假定主机 IP 是 X.Y.Z.W ， ID 将是 X+2 ⁸ *Y+2 ¹⁶ *Z+2 ²⁴ *W( 大序表示方式 ) 。低 ID 始终小于 16777216(0X1000000) ，我没有找到他是如何计算的线索，注意当你有一个低 ID 的时候，不同 SERVER 是不同的。

低 ID 的客户端没有公网 IP 地址，其他的客户端不能直接连接，因此所有的通讯必须通过电骡服务器；这增加了服务器计算负荷，导致服务器不愿意接受低 ID 的客户端。另外，这表明低 ID 的客户端不能连接到另外一个低 ID 的客户端（如果该客户端不是在同一个服务器上），因为电骡不支持跨服务器的通道。

为了支持低 ID 客户端，引进一种回调机制，使用这种机制，高 ID 的客户端可以邀请（通过电骡服务器）低 ID 的客户端连接到它来交换文件。

1.4                        用户 ID

电骡支持信用系统目的是鼓励用户共享文件。用户上传的文件越多，信誉值就或高，它在等待队列中前进的速度就越快。

用户 ID 是一个 128 位（ 16 字节） GUID ，由串联的随机数组成，第 6 和 15 字节不是随即产生的，他们的值是 14 和 111 。客户端 ID 仅仅在客户端和指定服务器会话的过程中是有效的，而用户 ID （也叫做用户 hash ）是唯一的且用来表示会话中的客户端（用户 ID 表示工作站）。用户 ID 在信誉系统中扮演重要的角色，这给黑客们假装其他用户来得到他们权限提供了动机。电骡支持一种加密模式，其设计为防止欺骗和假装用户。这个实现是一个简单挑战响应，依赖于 RSA 公钥 / 私钥加密。

1.5                        文件 ID

文件 ID 用来唯一的标示网络上的文件以及文件损坏检查和恢复。注意，电骡并不依赖于文件名称，目的是唯一标示和索引。一个文件通过全局唯一的 ID 来标示，通过哈希文件的内容来计算。有两种文件 ID ：第一种主要用来产生唯一文件 ID ，第二中用于损坏检查和恢复 [3] 。

1.5.1                                            文件哈希

文件通过 128 位 GUID 哈希来唯一标示，通过客户端和基于文件的内容来计算。 GUID 使用 MD4 算法 [4] 来基于文件的数据计算。当计算文件 ID 时，文件被分成 9.28MB 长的段。一个 GUID 是为每个单独的段来计算的，然后将所有的哈希合并到一起形成一个唯一的文件 ID 。当一个下载客户端完全下载一个文件的所有部分时，他计算部分的哈希并和对端发送的哈希部分比较，如果发现那部分损坏，客户端尝试从损坏的部分渐进替换位（ 180kb 每次）然后直到哈希计算是正确的为止。

1.5.2                                            根哈希

根哈希使用 SHA1 算法来为每个部分计算，基于 180kb 的块大小。这提供较高级别的可靠性和错误恢复。官方的电骡网站有更详细的信息。

1.6                        电骡协议扩展

尽管电骡完全兼容电驴，它还另外实现几个扩展，这允许电骡客户端为他们的用户提供更好的功能。扩展关注于客户端和客户之间的通讯，特别是安全和 UDP 的实现。本文的所有消息流程图中扩展部分都是灰色的。

1.7                        软硬限制

服务器配置包括良种限制基于活动的用户数 - 软和硬。硬限制大于等于软限制。当活动用户数量达到软限制时，服务器停止接受新的低 ID 客户端连接，当用户数达到硬限制时，服务器是满负荷的，不能接受任何客户端连接了。

posted on 2006-07-23 12:31 笨笨 阅读(1734) 评论(1)  编辑 收藏 引用 所属分类: P2P技术