BT客户端源码分析之一：总述
作者：小马哥
日期：2004-6-24

概述：
相对于 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：连接器，管理下载、上传、阻塞、片断选择、读写磁盘等等。

下载和上传不是孤立的，它们之间相互影响。下载需要有片断选择算法，上传的时候要考虑阻塞，片断下载之后，要写到磁盘上。上传的时候，也需要从磁盘读取。
这些任务，是由 Connecter 来统一调度的。

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

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

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