我在大四上学期时曾做过BT客户端的移植工作当时程序有.docx

1、我在大四上学期时曾做过BT客户端的移植工作当时程序有我在大四上学期时曾做过BT客户端的移植工作。当时程序有一些bug，需要查看源代码才能解决。然后便进入了先是痛苦万分然后茅塞顿开最后十分享受的代码阅读。互联网上讨论BT的的不少，但真正涉及底层协议细节和实现方案的不多。有感于当初资料匮乏的窘境，决心把自己的分析写出来，若此篇文档能够帮助到您，则是我万分的荣幸。这是文档的InitialDraft，想必是错误多多。我很愿和大家一起讨论，改进这份文档。虽然研究过底层代码，但自己并不是BT下载爱好者。以后也很有可能不会从事跟BT有关的工作。时间长了，一些东西难免会忘，若有力所不及的地方，请多见谅。姚旭晨

2、2006.4.161.1为什么要写这份文档BitTorrent点对点文件传输协议（以下简称BT协议）及其客户端应用大行其道的今天，各种各样的客户端不胜枚举（可以参看http:/wiki.theory.org/BitTorrentApplications），而各种各样的BT技术论坛讨论的却都是有关客户端软件如何使用的问题，有关底层协议细节和实现方案的讨论少之又少。我碰巧有机会研究过一阵BT协议的原理，也看过一部分源代码（CTorrent），虽然现在不再继续BT方面的研究了，但有感于当初看代码时遇到的资料的匮乏的窘境，便决心把自己的理解和心得写出来，算是自己的一份总结（这也是我的本科毕业论文），也

3、希望帮助对BT协议实现有兴趣的人尽快上手，少走弯路。有关BT协议的论述主要有三篇文章：1，BT官方网站上的协议解释：http:/www.bittorrent.org/protocol.html。2，BittorrentProtocolSpecification，http:/wiki.theory.org/BitTorrentSpecification。3，IncentivesBuildRobustnessinBitTorrent，这三篇文章从不同方面给出了BT协议从算法到实现的一个较为简略的描述。为了更深入地理解BT协议，自己动手写一个BT客户端或阅读一个BT客户端的源代码的工作是必不可少的。

4、1.2客户端的选择BramCohen是BT协议的创建者。根据这份协议，他写了BT的第一个客户端，也就是BitTorrent公司的产品：BitTorrent。可以说，BitTorrent的源码和BT协议是门当户对，要理解协议，先从BitTorrent的源码开始是最好不过的了。但BramCohen是用Python语言写的BitTorrent，这给很多不懂Python的人（我也在内）带来了很多麻烦：为了看懂一份源码而去新学一份计算机编程语言是不是有些不值得呢？好在BT客户端是如此之多，我们有很大的选择空间。除了Python，还有Java（主要是Azureus，国外非常流行的多平台的客户端）和C+（其

5、它大部分客户端）写成的程序。经过多方比较，我选择了CTorrent这个客户端。虽然CTorrent是用C+写成的，但仅仅算是一个轻量级（light-weighted）的C+软件。它的库函数依赖型很小，只用到了OpenSSL库用来计算哈希值，所以可以工作在Linux,FreeBSD和MacOS平台。CTorrent没有图形界面，工作在命令行模式。另外，libtorrent（1.3CTorrent简介CTorrent是由YuHong写的一个BT客户端。它的代码大部分都可以看作是C代码，只是用到了C+的类概念，还有一小部分构造函数，析构函数，函数和操作符重载的代码。不懂C+的人只需有一些C+的基本知

6、识就完全能看懂源代码了。CTorrent的主页是，它遵循GPL。作者在CTorrent主页上称自己为YuHong，这里有一篇他写完CTorrent后发的帖子：http:/www.freebsdchina.org/forum/viewtopic.php?p=39082，想必是中国人吧。用户在使用时发现CTorrent有一些bug，一个比较明显的例子是CTorrent下载完成后不会立即把缓存中的数据写入硬盘，这样如果按下Ctrl-C结束程序的话会造成数据的不完整。CTorrent的最新版本是1.3.4（2004年9月7日发布），作者后面就没有再发布新版本，软件的一些问题也没有得到修正。虽然有一些b

7、ug，但得益于CTorrent是开源项目，很快就有人为CTorrent写了一些补丁（Holmes的人贡献颇多，他为CTorrent打了很多patch，然后重新发布，取名为EnhancedCTorrent。EnhancedCTorrent的主页是Holmes用Perl写的一个CTorrentControlServer，可以实现对EnhancedCTorrent运行状况的监控。这篇CTorrent的源码分析是基于ctorrent-dhn1.2版本的，原因是由于我查看EnhancedCTorrent较早，那时还没有ctorrent-dhn2版本，再加上自己偷懒，没有赶在ctorrent-dhn2发布

8、之前把文章写完比较而言，dnh1.2版本已经是一个相对稳定的版本了，dnh2的改进主要是在性能方面，而非bugfix（容我再强词夺理一句，我简略看过dnh2版本的代码，在dnh1.2的基础上，看懂dnh2是没有问题的）。另外，DennisHolmes虽然重新发布了CTorrent，但他本人对原作者是极为尊敬的。在他的dnh版本中，原封不动地保留了原先代码的痕迹，自己的改动也加上了相应的注释。虽然CTorrent有一些bug，但正如DennisHolmes所言：谁又说其它客户端没有bug呢？我的这篇源码分析也统一称CTorrent和EnhancedCTorrent为CTorrent，只有在需要两

9、个版本比较时才区分开来。2.准备工作2.1知识储备要看懂CTorrent源码和本篇源码分析，读者需要具备如下知识：1，前面列举的BT协议的大致了解。2，网络socket编程方面的基本知识，主要是select()函数的使用。3，至少会C语言，了解C+的基本使用方法（主要是类，构造函数，析构函数和重载）。2.2我对本篇源码分析的说明1，源代码中如果出现一些乱码（特别是在终端中查看时），设置：$exportLANG=C即可看到原作者写的中文注释。2，源码解说一般采取流程图的形式，有一些函数的具体功能不是很集中，画流程图也表示不出前后联系来，就直接写了步骤分析。有些源码比较晦涩的，会直接分析源代码。3

10、，源代码中的全部变量都有分析。大部分函数都有说明，少数特别简单的函数和见名知意的函数没有说明。4，源代码中看似简单的表述实际蕴含着及其严格的操作要求（例如宏P_HANDSHAKE的意思是可以进行握手通信了，而不是正在进行握手通信或者已经完成握手通信了）。所以必须正确理解源代码各个宏，变量，函数的确切含义，才能真正理解程序的流程和作用。5，分析源码的最终目的是彻底理解BT协议的实现结构，以及BT通信性能卓越的原因。虽然程序中涉及BT协议算法的只有几个函数，但这几个函数是在其它大量代码的基础上构建的。一些有关种子文件的制作和解析的代码虽然看似和BT通信关系不大，但若前面的基础没有理解正确，会给后面

11、的算法分析带来很大的麻烦。6，原作者的C语言技巧相当高，enjoyit!7，本文中“函数”指的是当前正在分析的函数，而“程序”指的是整个CTorrent程序。8，本文中“消息”指的是peer发来的固定格式的消息，例如piece消息，bitfield消息等。“数据”指的是客户端要下载的东西，例如一个游戏，一段视频等。9，英文中种子文件有很多说法，如.torrentfile,metainfofile，本文中均用它们的中文名：种子文件。10，英文中关于BT协议的最小数据单元有很多说法，如slice,block,subpiece，本文中使用CTorrent源代码中的说法：slice。3.总述3.1CT

12、orrent的命令行参数的意义-h/-H：显示帮助命令-x：只解码并显示种子文件信息，不下载。-c：只检查已下载的数据，不下载。-v：打开debug调试输出。下载选项：-eint下载完毕后的做种时间（单位：小时），默认为72小时。-pport绑定端口，默认为2706。-ssave_as重命名下载的文件，若是下载的是多个文件，则sava_as是包含多文件的目录。-Ccache_size缓存大小，默认为16MB。-f强制做种模式，不进行SHA1HASH检查。-bbf_filenamepiece位图文件名，详见BitField:SetReferFile()。-Mmax_peers客户端最多与多少个p

13、eer通信。-mmin_peers客户端至少与多少个peer通信。-nfile_number多文件下，选择哪个文件去下载（例如第二个文件file_number就为2）。-Drate限制最大下载速率（单位：KB/s）。-Urate限制最大上传速率（单位：KB/s）。-Ppeer_id客户端通信的ID，默认为-CD0102-。下载数据文件示例：ctorrent-snew_filename-e12-C32-p6881eg.torrent制作种子文件示例：ctorrent-tfile_to_make.avi-sa.torrent-uprotocol:/address/announce3.2CTorrent的状态栏的意义CTorrent运行时输出格式如下：$/1/10/403/148/1482MB,1MB|48,20K/s|80,40KE:0,1各项意义为：/：表明客户端正在工作的符号，以”-|/”循环。1：种子数目。10：客户端正在通信的非种子的peer数目。40：tracker服务器知道的peer数，也是整个bt通信群的peer数。3：客户端已经下载的piece数目。148：数据文件全部的piece数目。148：客户端可以得到的piece数目，若此数小于全部piece数目则不会下载到完整的数据。2MB