瑞星卡卡安全论坛

首页 » 技术交流区 » 系统软件 » 【分享】BT客户端源码分析之:总述
tianxunmycool - 2007-1-5 19:45:00
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这么简单方便。
1
查看完整版本: 【分享】BT客户端源码分析之:总述