概述：相对于 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：

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