关闭

BT客户端源码分析之一:总述

821人阅读 评论(0) 收藏 举报

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

0
0

查看评论
* 以上用户言论只代表其个人观点,不代表CSDN网站的观点或立场
    个人资料
    • 访问:10458次
    • 积分:139
    • 等级:
    • 排名:千里之外
    • 原创:1篇
    • 转载:11篇
    • 译文:0篇
    • 评论:1条
    文章分类
    文章存档
    最新评论