VC实例学习（4）：BT拓展开发文档

                                             BT拓展开发文档

 

 一、BT 的原理

 

    众所周知，一般下载对同时下载的人数和速度读有很大的限制，因为一般来讲，下载是把文件由服务器端传送到客户端，例如FTP，HTTP，PUB等等。但是这样就出现了一个问题，随着用户的增多，对带宽的要求也随之增多，用户过多就会造成瓶颈，而且搞不好还会把服务器挂掉，所以很多的服务器会都有用户人数的限制，下载速度的限制，这样就给用户造成了诸多的不便。

 

    但BT就不同，用BT下载反而是用户越多，下载越快，这是为什么呢？因为BT用的是一种传销的方式来达到共享的，工作原理如下：

 

    BT首先在上传者端把一个文件分成了Z个部分，甲在服务器随机下载了第N各部分，乙在服务器随机下载了第M个部分，这样甲的BT就会根据情况到乙的电脑上去拿乙已经下载好的M部分，乙的BT就会根据情况去到甲的电脑上去拿甲已经下载好的N部分，这样就不但减轻了服务器端得负荷，也加快了用户方（甲乙）的下载速度，效率也提高了，更同样减少了地域之间的限制。比如说丙要连到服务器去下载的话可能才几K，但是要是到甲和乙的电脑上去拿就快得多了。所以说用的人越多，下载的人越多，大家也就越快，BT的优越性就在这里。而且，在你下载的同时，你也在上传（别人从你的电脑上拿那个文件的某个部分），所以说在享受别人提供的下载的同时，你也在贡献。

 

    由于原理的不同，BT的服务器上放的下载文件都是非常小的，其实这些文件并不是你要下载的文件，这些文件是软件提供者 发布 文件时制作的记录了 所发布文件相关信息的文件，一般都是以.Torrent结尾的，大小非常小的文件。 而一般的下载则是把下的文件放到服务器上，这样就必须要服务器提供大量的空间，真因为这样，我们可以自豪的说：“BT的速度，无限的容量”！

 

 二、BT 的缺陷

 

    BT下载也是一种P2P的共享下载方式，因此它的发展前景也可以从一个方面反映出P2P的发展前景！作为P2P的共享下载方式，它有着无数的BTFans，无限的容量，巨大的带宽，最新最全的资源，这是任何一个 传统的下载方式所不能比的。但是，他也存在着缺陷：

 

    首先、P2P下载方式所带来的网络安全隐患：IP地址很容易被他人获取，防火墙的设置相对比较难。

 

    其次、BT下载对一些通过内网的一些有网关上网的用户的支持还是不太理想。因此内网下载的速度会比较慢。

 

 三、BT 的前景

 

    由于 BT 有着比传统下载方式无法比拟的优势，所以我们萌发了一个借由 BT 下载原理结合传统下载方式开发一个新的下载系统的想法。

 

    我们认为 BT 的下载方式还可以做如下改进：

 

    （1）首先从安全来看：IP容易被截取。分析 BT协议 可以清楚的发现，BT 下载是基于IP等连接信息公开的基础开发的，用户必须每隔一个时间段想 Tracker 服务器报告一些必须信息，其中就包括了 下载者的IP等信息。这个保存在 Tracker 服务器的数据库里面，以便其他下载者获取，然后通过解析这些信息，与之建立连接以传送数据。由此可见：BT 的下载方式要避免IP等信息不被他人获取 几乎是不可能的。

 

    但是，我们认为即使不能彻底的消除 IP 泄漏的隐患，我们也应该尽可能的降低由于IP明文显示带来的安全隐患，于是我们看看目前网络上流行的各个BT下载软件，不难发现 这些BT 的客户端软件都把当前下载用户的IP、端口等信息明文显示出来了，我们认为这个是没有必要的，而且给本来就难以消除的IP信息泄漏隐患雪上加霜。

 

    于是我们认为，BT 的客户端软件应该去掉显示当前下载者IP 这一功能，尽量保护下载者的IP等信息。

 

    （2）其次BT下载的方式目前拓展的用处还很小，我们认为BT 下载的这种新颖方式可以用于其他的方面，比如大型文件的发布：在很多应用领域，特别是一些每天需要分发大量数据的应用领域：网络会议、网络电台等，这些应用领域需要一个或者少数的数据提供者提供源数据，然后其他的数据接受者则需要获取这些数据，如果按照传统的下载方式，网络要求明显比较高，而且为了缓解网络的压力，必须采用各种各样的压缩算法，牺牲我们宝贵的时间来获取最佳平衡。

 

    这个时候，我们想到了BT 的这种下载方式，BT 的下载方式是多台终端彼此之间都连接起来，同时传送同一个文件。这样的话，可以明显的降低网络的压力，同时也可以减少压缩造成的时间浪费。

 

 四、BT 的开发

 

    我们研究了目前所有开源的BT客户端 和 服务端，对BT 的原理有了比较深刻的认识，下面简单说说BT功能分析：

 

    （一）服务端

 

    由于服务端负责的功能比较单一，可以概括为：Torrent 文件的WEB发布，Tracker的交换保留下载信息服务。

 

    Torrent 文件的发布，目前大部分的服务端都交给了WEB发布页面来做，这个页面和Tracker共享着同一个数据库，Torrent 的WEB发布系统负责Torrent的上传，下载，管理等，以及从数据库里面读取相应的Tracker运行状态数据，显示当前该Torrent文件的下载情况。

 

    Tracker 服务器，这个服务器做的工作就是：在一个或者多个端口监听，当接受到一个连接请求的时候，选择一个空闲端口建立连接，把他所需下载的文件的下载状态数据发给客户端并且同时把这个客户端的一些信息记录到数据库，然后在这个连接上，每隔一段时间与这个客户端的交流下载状态信息。

 

    （二）客户端

 

    客户端的功能相对服务端要复杂，客户端要做的可以分为这几个部分：解析Torrent文件，连接Tracker服务器，连接其他客户端，接收数据，发送数据，维护下载文件等。

 

    解析Torrent文件，这个功能主要是获取要下载文件的信息，得到Tracker的地址和端口，以及下载文件的维护信息。

 

    连接Tracker服务器，这个部分主要是得到最新的下载状态信息，以及报告下载状态。

 

    连接其他客户端，为了得到数据，必须与其他的客户端连接起来，下载自己没有获取数据，并为发送自己下载的数据给其他下载者做准备。

 

    维护下载文件，该部分是维护所下载数据的完整以及整个文件的完整等。

 

    上面就是我们目前研究源代码分析所的到的，由于目前BT的开源软件大部分都是由Python语言开发的，这个语言虽然有很多有点，但是也存在者他固有的不足，于是我们绝对，在读懂BT用Python开发的源代码之后，用C++语言重新开发。

 

    （三）下面介绍原BitTorrent的源代码分析：

 

    由于我们现在要开发的是大部分工作在客户端，所以我们这里忽略服务端的研究，直接切入客户端的研究：

 

    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。

 

    具体的分析需要根据源代码来看（这里忽略）。

 

    以上就是我们目前认识到的BT发展前景，我们觉得这样的思路应该可以走出一个全新的数据传输领域。

 

 五、目前的研究进度：

 

    源代码的分析已经结束了总体分析，现正处于具体模块的代码分析。今后接着要做的就是对每一个类进行C++重写。

 

 

 

                                                             【过程工作室】  王君  撰写
                                                              2004 年 11 月 27 日  凌晨