BT客户端源码分析之：总述

概述：

相对于 tracker 服务器来说，BT客户端要复杂的多，Bram Cohen 花了一年 full time 的时间来完成 BT，我估计其中大部

分时间是用在 BT 客户端的实现和调试上了。

由于 BT 客户端涉及的代码比较多，我不能再象分析 tracker 服务器那样，走上来就深入到细节之中去，那样的话，我写的

晕晕糊糊，大家看起来也不知所云。所以第一篇文章先来谈谈客户端的功能、相关协议，以及客户端的总体架构和相关的类

的层次结构。这样，从整体上把握之后，大家在自己分析代码的过程中，就能做到胸有成竹。

客户端的功能：

不看代码，只根据 BT 的相关原理，大致可以推测，客户端需要完成以下功能：

1、解析 torrent 文件，获取要下载的文件的详细信息，并在磁盘上创建空文件。

2、与 tracker服务器 建立连接，并交互消息。

3、根据从 tracker 得到的信息，跟其它 peers 建立连接，并下载需要的文件片断

4、监听某端口，等待其它peers 的连接，并提供文件片断的上传。

相关协议：

对客户端来说，它需要处理两种协议：

1、与 tracker 服务器交互的 track HTTP协议。

2、与其它 peers 交互的 BT 对等协议。

总体架构：:

从总体上来看，BT客户端实际是以一个服务器的形式在运行。这一点似乎有些难以理解，但确实是这样。

为什么是一个服务器了？

客户端的主要功能是下载文件，但作为一种P2P软件，同时它必须提供上传服务，也就是它必须守候在某一个端口上，等待其

它peers 的连接请求。从这一点上来说，它必须以一个服务器的形式运行。我们在后面实际分析代码的时候，可以看到，客

户端复用了 RawServer 类用来实现网络服务器。

客户端的代码，是从 download.py 开始的，首先完成功能1，之后就进入服务器循环，在每一次循环过程中，完成功能 2、3

、4。其中，Rerequester 类负责完成功能2，它通过 RawServer::add_task()，向 RawServer 添加自己的任务函数，这个任

务函数，每隔一段时间与 tracker 服务器进行通信。而Encoder、Connecter 等多个类组合在一起，完成功能3和4。

类层次结构：

BT 客户端涉及的类比较多，我首先大致描述一下这些类的功能，然后给出它们的一个层次结构。

1、RawServer：负责实现网络服务器

2、Rerequester：负责和 tracker 通信。它调用 RawServer::add_task() ，向 RawServer 添加自己的任务函数

Rerequester::c()。

3、Encoder：一种 Handler类（在分析 tracker 服务器时候提到），负责处理与其它peers建立连接和以及对读取的数据按

照BT对等协议进行分析。

Encoder 类在Encrypter.py中，该文件中，还有一个 Connection 类，而在 Connecter.py 文件中，也有一个 Connection

类，这两个同名的 Connection 类有些蹊跷，为了区分，我把它们重新命名为 E-Connection 和 C-Connection。

3.1、E-Connection：负责 TCP 层次上的连接工作

这两个 Connection 是有区别的，这是因为BT对等协议需要在两个层次上建立连接。首先是 TCP 层次上的连接，也就是经过

TCP 的三次握手之后，建立连接，这个连接由 E-Connection 来管理。在 Encoder:: external_connection_made() 函数中

可以看到，一旦有外部连接到来，则创建一个 E-Connection 类。

3.2、C-Connection：管理对等协议层次上的连接。

在 TCP 连接之上，是 BT对等协议的连接，它需要经过BT对等协议的两次“握手”，握手的细节大家去看BT对等协议。过程

是这样的：

为了便于述说，我们假设一个BT客户端为 A，另一个客户端为 X。

如果是X主动向A发起连接，那么在TCP连接建立之后，A立刻利用这个连接向X发送BT对等协议的“握手”消息。同样，X在连

接一旦建立之后，向 A发送BT对等协议的“握手”消息。A一旦接收到X的“握手”消息，那么它就认为“握手”成功，建立

了BT对等协议层次上的连接。我把它叫做“对等连接”。A 发送了一个消息，同时接收了一个消息，所以这个握手过程是两

次“握手”。

同样，对X 来说，因为连接是它主动发起的，所以它在发送完“握手”消息之后，就等待A的“握手”消息，如果收到，那么

它也认为“对等连接”建立了。

一旦“对等连接”建立之后，双方就可以通过这个连接传递消息了。

这样，原来我所疑惑的一个问题也就有了答案。就是：如果 X 需要从 A 这里下载数据，那么它会同 A 建立一个连接。假如

A 又希望从 X 那里下载数据，它需不需要重新向 X 发起另外一个连接了？答案显然是不用，它会利用已有的一条连接。

也就是说，不管是X主动向A发起的连接，还是 A 主动向 X发起的连接，一旦建立之后，它们的效果是一样的。这个同我们平

时做 C/S结构的网络开发是有区别的。

我们可以看到在 E-Connection的初始化函数中，会主动连接的另一方发送“握手”消息，在 E-Connection::data_came_in

() 中，会首先对对方的“握手”消息进行处理。这正是我上面所描述的情形。

在 E-Connection::read_peer_id() 中，是对“握手”消息的最后一项 peer id进行处理，一旦正确无误，那么就认为“对

等连接”完成，

self.encoder.connecter.connection_made(self)

在 Connecter::connection_made() 函数中，就创建了管理“对等连接”的 C-Connectinon类。所以，更高一层的“对等连

接”是由 C-Connection 来管理的。

3.3、Connecter：连接器，管理下载、上传、阻塞、片断选择、读写磁盘等等。

下载和上传不是孤立的，它们之间相互影响。下载需要有片断选择算法，上传的时候要考虑阻塞，片断下载之后，要写到磁

盘上。上传的时候，也需要从磁盘读取。v
这些任务，是由 Connecter 来统一调度的。

类层次结构，我用缩进来表示一种包含关系。

Encoder:
  E-Connection
      C-Connection
          Upload
          SingleDownloader
      Connecter
          Choker：负责阻塞的管理
          Downloader：
              SingleDownloader
              Picker：片断选择策略
              StorageWrapper：

先写这些吧，有什么我再补充进来。


源代码分析2~8 (Word文档压缩)

Tracker 服务器源码分析之一：总述

tracker服务器是BT下载中必须的角色。一个BT client 在下载开始以及下载进行的过程中，要不停的与 tracker 服务器进

行通信，以报告自己的信息，并获取其它下载client的信息。这种通信是通过 HTTP 协议进行的，又被称为 tracker  HTTP

协议，它的过程是这样的：

client 向 tracker 发一个HTTP 的GET请求，并把它自己的信息放在GET的参数中；这个请求的大致意思是：我是xxx（一个

唯一的id），我想下载yyy文件，我的ip是aaa，我用的端口是bbb。。。

tracker 对所有下载者的信息进行维护，当它收到一个请求后，首先把对方的信息记录下来（如果已经记录在案，那么就检

查是否需要更新），然后将一部分（并非全部，根据设置的参数以及下载者的请求）参与下载同一个文件（一个tracker服务

器可能同时维护多个文件的下载）的下载者的信息返回给对方。

Client在收到tracker的响应后，就能获取其它下载者的信息，那么它就可以根据这些信息，与其它下载者建立连接，从它们

那里下载文件片断（BT把一个文件切分成多个片断）。

关于client和tracker之间通信协议的细节，在“BT协议规范”中已经给出，这里不再重复。下面我们具体分析 tracker服务

器的实现细节。

从哪里开始？

要建立一个 tracker服务器，只要运行 bttrack.py 程序就行了，它最少需要一个参数，就是 –dfile，这个参数指定了保

存下载信息的文件。Bttrack.py 调用 track.py 中的 track()函数。因此，我们跟踪到 track.py 中去看track() 函数。

Track.py：track()

这个函数首先对命令行的参数进行检查；然后将这些参数保存到 config 字典中。在BT中所有的工具程序，都有类似的处理

方式。

接下来的代码：

  r = RawServer(Event(), config['timeout_check_interval'], config['socket_timeout'])

  t = Tracker(config, r)

  r.bind(config['port'], config['bind'], True)

  r.listen_forever(HTTPHandler(t.get, config['min_time_between_log_flushes']))

  t.save_dfile()

首先是创建一个 RawServer 对象，这是一个服务器对象，它将实现一个网络服务器的一些细节封装起来。不仅tracker服务

器用到了 RawServer，我们以后还可以看到，由于每个 client端也需要给其它 client 提供下载服务，因此也同时是一个服

务器，client的实现中，也用到了RawServer，这样，RawServer的代码得到了重用。关于 RawServer的详细实现，在后面的

小节中进行分析。

接着是创建一个 Tracker对象。

然后让RawServer绑定在指定的端口上（通过命令行传递进来）。

最后，调用 RawServer::listen_forever() 函数，使得服务器投入运行。

最后，在服务器因某些原因结束运行以后，调用 Tracker::save_dfile() 保存下载信息。这样，一旦服务器再次投入运行，

可以恢复当前的状态。

其它参考信息：

1、BT源码的分布：

把BT的源码展开之后，可以看到有一些python程序，还有一些说明文件等等，此外还有一个BitTorrent目录。这些 python程

序，实际是一些小工具，比如制作 metafile的btmakemetafile.py、运行tracker服务器的bttrack.py、运行BT client端的

btdownloadheadless.py 等等。而这些程序中，用到的一些 python 类的实现，都放在子目录 BitTorrent 下面。我们的分

析工作，通常是从工具程序入手，比如 bttrack.py，而随着分析的展开，则重点是看 BitTorrenet子目录下的代码。

BT作者 Bram Cohen 在谈到如何开发可维护的代码的一篇文章中（http://www.advogato.org/article/258.html），其中提

到的一条就是开发一些小工具以简化工作，我想BT的这种源码结构，也正是作者思想的一种体现吧。

2、我们看到，python和我们以前接触的 c/c++ 不一样的第一个地方就是它的函数在定义的时候，不用指定参数类型。既然

这样，那么，在调用函数的时候，你可以传递任意类型的参数进来。例如这样的函数：

def foo(arg):

  print type(arg)

你可以这样来调用：

a = 100
b = “hello world”
foo(a)
foo(b)

输出结果是：0
type ‘int’
type ‘str’

这是因为，第一次调用 foo()的时候，传递的是一个整数类型，而第二次调用的时候，传递的是一个字符串类型。

这种参数具有动态类型的特性，是 c/c++等传统的语言是所不具备的。这也是 python 被称为动态语言的一个原因吧。C++的

高级特性模板，虽然也使得参数类型可以动态化，但使用起来，远没有python这么简单方便。