专利名称：一种bt下载方法、装置及系统的制作方法
技术领域：
本发明涉及通信技术领域，尤其涉及一种BT下载方法、装置及系统。
背景技术：
点对点技术(peer-to-peer，简称P2P)又称对等互联网络技术，是相对于客户端/ 服务器(C/S)模式来说的一种网络信息交换方式。在P2P网络中，每个节点既可以作为客 户端从其他节点得到服务，也可以充当服务器向其他节点提供服务。由于P2P网络能够极 大缓解传统C/S网络架构中服务器端的压力过大、易出现单一失效点等问题，又能充分利 用终端的丰富资源，所以P2P技术被广泛应用于计算机网络的各个应用领域，如分布式科 学计算、文件共享、流媒体直播与点播、语音通信及在线游戏支撑平台等方面。BT是比特洪流BitTorrent的简称，是一种依赖P2P方式将文件在大量互联网 用户之间进行共享与传输的协议，由于其实现简单、使用方便，在中国用户之间被广泛使 用。BT中的节点在共享一个文件时，首先将文件分片并将文件和分片信息保存在一个流 (Torrent)类型文件(即.torrent文件)，该Torrent文件通常被称为种子文件，拥有种子 文件的节点被形象地称作种子节点。种子文件本质上是文本文件，包含Tracker信息和文 件信息两部分。Tracker信息主要是BT下载中需要用到的索引服务器(即Tracker服务 器)的地址和针对Tracker服务器的设置，文件信息是根据对目标文件的计算生成的，计 算结果根据BitTorrent协议内的B编码规则进行编码。它的主要原理是需要把提供下载 的文件虚拟分成大小相等的分片，分片大小必须为2k的整数次方(由于是虚拟分片，硬盘 上并不产生各个分片文件)，并把每个分片的索引信息和Hash验证码写入种子文件中。当 用户在下载该文件时，可以根据种子文件的信息，将文件的部分分片下载下来，然后在其他 下载该文件的节点之间共享自己已经下载的分片，互通有无，从而实现文件的快速分发。由 于每个节点在下载文件的同时也在为其他用户上传该文件的分片，所以整体来看，不会随 着用户数的增加而降低下载速度，反而下载的人越多，速度越快。发明人在实现本发明的过程中，发现现有的BT下载过程中客户端必须先在网络 中搜索获取待下载资源的种子文件，然后根据种子文件才能从其他对等节点处下载BT资 源，然而，由于拥有BT种子文件的网站经常变动等原因，导致部分BT种子文件难以获取，因 而存在大量因无法找到种子文件从而无法下载BT资源的情况。
发明内容
本发明目的在于提供一种BT下载方法、装置及系统，能够在找不到种子文件的情 况下实现BT资源下载。根据本发明实施例的一方面，提供一种BT下载方法，包括获取网络中向索引服务器发送的第一请求数据包；根据解析所述第一请求数据包获得的待下载资源信息向所述索引服务器发送第 二请求数据包，所述第二请求数据包用于向索引服务器请求拥有所述待下载资源的客户端
4列表信息；接收所述索引服务器返回的客户端列表信息；从所述客户端列表中的至少一个客户端获得所述待下载资源的分片信息，所述分 片信息包括分片大小信息；根据所述分片信息从所述至少一个客户端下载所述待下载资源。根据本发明实施例的另一方面，提供一种BT下载装置，包括数据包获取单元，用于获取网络中向索引服务器发送的第一请求数据包；请求单元，用于根据根据解析所述第一请求数据包获得的所述待下载资源信息向 所述索引服务器发送第二请求数据包，所述第二请求数据包用于向索引服务器请求拥有所 述待下载资源的客户端列表信息；接收单元，用于接收所述索引服务器返回的客户端列表信息；处理单元，用于从所述客户端列表中的至少一个客户端获得所述待下载资源的分 片信息，所述待下载资源的分片信息包括分片大小信息；下载单元，用于根据所述待下载资源的分片信息从所述至少一个客户端下载所述 待下载资源。根据本发明实施例的再一方面，提供一种BT下载系统，包括索引服务器以及至少 两个上述BT下载装置。本发明实施例提供的下载方法、装置及系统可以通过抓取网络中其他客户端或服 务器向索引服务器发送的第一请求数据包，并解析获得索引服务器的地址、待下载资源标 识以及所述待下载资源的大小信息等待下载资源信息，根据获得的待下载资源信息构造并 向索引服务器发送第二请求数据包，从而获得索引服务器返回的拥有待下载资源的客户端 列表信息，并通过与客户端列表中至少一个客户端交互获得待下载资源的分片信息，从而 根据待下载资源的分片信息向至少一个客户端下载分片数据，使得在没有获得种子文件的 请况下也能够进行BT下载，提升了 BT资源下载的可靠性，更好的实现了 BT资源的共享。
为了更清楚地说明本发明实施例中的技术方案，下面将对实施例描述中所需要使 用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于 本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其 他的附图。图1为本发明实施例提供的一种BT下载方法的流程示意图；图2为本发明实施例提供的另一种BT下载方法的流程示意图；图3为本发明实施例提供的一种客户端的结构示意图；图4为本发明实施例提供的另一种客户端的结构示意图。
具体实施例方式下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完 整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于 本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。需要说明的是，本发明实施例提供的BT下载方法是一种有别于传统下载方法中 必须要获得种子文件才能进行BT资源下载的新的下载方式，本发明实施例提供的BT下载 方法在无法获得种子文件的情况下也能进行BT资源的下载。下面将对本发明实施例的方 案进行详细描述。图1为本发明实施例提供的一种BT下载方法的流程示意图，如图所示，该方法包 括步骤100，获取网络中向索引服务器发送的第一请求数据包；具体的，可以抓取网络中的对等节点Peer向索引服务器(即Tracker服务器)发 送的第一请求数据包，该第一请求数据包为网络中其他客户端或服务器请求索引服务器返 回拥有相同待下载资源的客户端列表信息的请求数据包，具体的，该第一请求数据包可以 是Get类型的请求数据包，该数据包中可以包括Tracker服务器的地址、待下载资源标识以 及待下载资源的大小信息，其中待下载资源标识用于唯一标识待下载资源。其中，Tracker服务器是BT下载中必须的角色。一个BT客户端client在下载开 始以及下载进行的过程中，要不停的与Tracker服务器进行通信，以报告自己的信息，并获 取其它下载客户端client的信息。这种通信是通过HTTP协议进行的，它的过程是这样的client向Tracker服务器发一个HTTP的GET请求，并把它自己的信息放在GET的 参数中，这个GET请求的大致意思可以是我是XXX( —个唯一的id)，我想下载yyy文件， 我的ip是aaa，我用的端口是bbb...。Tracker服务器对所有下载者的信息进行维护，当它收到一个请求后，首先把对方 的信息记录下来(如果已经记录在案，那么就检查是否需要更新)，然后将一部分(并非全 部，根据设置的参数已经下载者的请求)参与下载同一个文件(一个Tracker服务器可能 同时维护多个文件的下载)的下载者的信息返回给对方。Client在收到Tracker服务器 的响应后，就能获取其它下载者的信息，那么它就可以根据这些信息，与其它下载者建立连 接，从它们那里下载文件片断。步骤105，根据解析所述第一请求数据包获得的待下载资源信息向所述索引服务 器发送第二请求数据包，所述第二请求数据包用于向索引服务器请求拥有所述待下载资源 的客户端列表信息；具体的，可以通过解析抓包获得的第一请求数据包获得Tracker地址、待下载资 源标识以及待下载资源的大小信息等待下载资源信息，根据获得的待下载资源信息构造第 二请求数据包，以向索引服务器请求返回拥有所述待下载资源的客户端列表信息，具体的， 该第二请求数据包也可以是Get类型的请求数据包。步骤110，接收所述索引服务器返回的客户端列表信息；具体的，当索引服务器接收到第二请求数据包后，可以根据第二请求数据包中的 待下载资源信息返回拥有该待下载资源的客户端列表信息。需要说明的是，索引服务器返 回的客户端列表信息中可以包含拥有该待下载资源的客户端信息，也可以包含拥有该待下 载资源的服务器的信息，其中，拥有待下载资源的客户端和服务器都是拥有该待下载资源 的对等节点Peer。为了描述方便，本发明实施例以客户端为例进行说明。步骤115，从所述客户端列表中的至少一个客户端获得所述待下载资源的分片信息，所述分片信息包括分片大小信息； 具体的，当接收到所述索引服务器返回的客户端列表信息后，可以通过与该客户 端列表中的至少一个客户端进行BT握手交互，接收至少一个客户端在BT握手后返回的 待下载资源的分片信息，并根据接收到的待下载资源的分片信息确定待下载资源的分片大步骤120，根据所述分片信息从所述至少一个客户端下载待下载资源。具体的，可以根据确定的待下载资源的分片大小向所述至少一个客户端发送下载 请求，从所述至少一个客户端下载待下载资源。通过本发明实施例一所述的BT下载方法，可以通过抓取网络中其他客户端或服 务器向索引服务器发送的第一请求数据包，并解析第一请求数据包获得索引服务器的地 址、待下载资源标识以及所述待下载资源的大小信息等待下载资源信息，构造并向索引服 务器发送第二请求数据包，从而获得索引服务器返回的拥有待下载资源的客户端列表信 息，并通过与客户端列表中至少一个客户端交互获得待下载资源的分片信息，从而根据待 下载资源的分片信息向至少一个客户端下载分片数据，使得在没有获得种子文件的请况下 也能够进行BT下载，提升了 BT资源下载的可靠性，更好的实现了 BT资源的共享。图2为本发明实施例提供的另一种BT下载方法的流程示意图，本发明实施例二以 客户端A下载F文件为例进行描述，若客户端A没有在网络中找到F文件的种子文件，则客 户端A可以通过本实施例所述的方法下载F文件。如图所示，该方法包括步骤200，客户端A从网络中抓取第一请求数据包；具体的，当客户端A要下载待下载资源F时，若其在网络中没有获得F文件的种子 文件，可以通过抓包获得网络中下载资源F的其他客户端(例如客户端B)向Tracker服务 器发送的第一请求数据包，在本实施例中，该第一请求数据包可以是Get类型的请求数据 包，该第一请求数据包的目的是向Tracker服务器获取拥有待下载资源的其它peer的信 息，以便与其它peer通讯下载BT资源。例如，客户端B要下载的资源是与客户端A要下载的资源相同，都是要下载文件 F，且B在网络中获得了 F文件的种子，当B获得种子文件后，会根据获得的种子文件中的相 关信息向Tracker服务器发送Get请求数据包，以从Tracker服务器处获得拥有F文件的 其他peer的信息，以便与其它peer通讯下载F文件，当客户端A没有获得F文件的种子 文件时，可以在网络中通过抓包的方式获得客户端B发送给Tracker服务器的Get请求数 据包，本实施例以Get请求数据包为Get announce请求数据包为例进行说明，需要说明的 是，Get announce请求是标准的HTTP Get请求，其中，Get announce请求数据包中的参数 info_hash用于唯一标识待下载文件，因此，客户端A抓包时，可以根据Get announce请求 数据包中的参数值info_hash确定其要获得的Getarmounce请求数据包。步骤205，客户端A解析第一请求数据包；具体的，可以解析客户端B向Tracker服务器发送的Get announce请求数据 包，获得Tracker服务器地址、待下载资源的标识以及待下载资源的大小信息。其中，Get announce请求的格式可以为GET announce ？ info_hash = xxx&download = m&left = η&· · ·其中，可以从该Get announce请求数据包的包头中提取Tracker的地址信息及端口号，根据Get announce参数直接得到待下载资源的标识infojiash，并通过将Get announce参数中的download与left相加得到待下载资源的大小。步骤210，客户端A向Tracker服务器发送第二请求数据包；具体的，客户端根据步骤205中解析第一请求数据包获得的信息(包括=Tracker 服务器的地址信息及端口号、待下载资源的标识infojiash、待下载资源的大小)构造第 二请求数据包，并向Tracker服务器发送构造的第二请求数据包，以向Tracker服务器请 求获得拥有待下载资源F的peer list信息。其中，本实施例中，第二请求数据包也为Get announce请求数据包。步骤215，客户端A接收Tracker服务器返回的客户端列表peer list信息；具体的，Tracker服务器接收到客户端A发送的第二请求数据包后，会向客户端A 返回参与下载同一个文件例如F的其他下载者的信息peer list。其中返回的peer list 信息中包含有各peer的IP地址和端口号。需要说明的是，索引服务器返回的客户端列表信息中可以包含拥有该待下载资源 的客户端信息，也可以包含拥有该待下载资源的服务器的信息，其中，拥有待下载资源的客 户端和服务器都是拥有该待下载资源的对等节点Peer。为了描述方便，本发明实施例以客 户端为例进行说明。步骤220，客户端A根据peer list信息向至少一个peer发送BT握手请求消息；具体的，客户端A可以根据Tracker服务器返回的下载同一个文件的peer的IP 地址和端口号，向其中至少一个peer (例如客户端C)发送握手请求消息，以与其建立连接。 通常，客户端A会向所有peer发送BT握手请求消息。步骤225，客户端A接收至少一个peer返回的BT握手应答消息，与至少一个peer 建立通信连接；步骤230，客户端A接收至少一个peer在建立通信连接后发送的待下载资源的位 域bitfield消息；根据BT协议要求，当下载客户端与其他peer通过握手建立连接后，会立即向对 方发送bitfield消息，通报各自拥有的待下载资源的分片情况，如果peer没有待下载资 源的分片，则该peer可以不发送bitfield消息。其中，bitfield消息中包含有三个部 分消息长度Message Length、消息类型Message Type、数据负载Payload，其中，消息长 度Message Length为消息类型Message Type的长度及数据负载Payload的长度之和； bitfield消息中Message Type的值为5，其长度为1字节；数据负载Payload部分实际是 一个位图，如果该Peer有待下载资源的某个分片，那么对应的位置置1，否则置O。步骤235，客户端A根据待下载资源的大小以及bitfield消息分析确定待下载资 源的分片大小；根据BT协议要求，当客户端A接收到peer (例如客户端C)在BT握手后发送的待 下载资源的bitf ie 1 d消息后，可以根据该bitf ie 1 d消息中携带的Message Length减去消 息类型Message Type的长度(1字节)获得该peer (例如客户端C)返回的数据Payload 的长度。SP Payload的长度=Message Length-I0由于Payload中的每一位(bit)标识一 个分片，且1个字节等于8位(bit)，因此，通过Payload的长度可以确定该peer拥有的待 下载资源的分片数在一个首尾相距7个bit的区间内。例如某个待下载资源共分为9片，需要2个字节来表示(第二个字节只用到一位)，而另一个BT资源分为16片，也只需要2 个字节来表示，则若解析bitfield消息获得的Payload的长度为2，可以判断出该待下载资 源的分片数在9-16片之间。由于在步骤205中已经通过解析第一请求数据包获得待下载资源的大小，在本步 骤中，可以根据获得的bitfield消息中的Payload的长度推算出该待下载资源的总分片 数，并且，由于BT资源的各分片大小一般为2的η次方，例如32K、64k、128K、256k、512K、 1M、2M、4M、8M，因此，在本步骤中可以进一步根据待下载资源的大小以及待下载资源的分 片数获得待下载资源的分片大小，具体的，可以用待下载资源大小分别除以分片数区间的 两个端值，获得分片大小的一个区间，在分片大小的区间内取2的N次方的值则为该待下 载资源的分片大小。例如若客户端A通过抓取第一请求数据包获得待下载资源F的大 小为330K，通过解析peer (例如客户端C)发送的bitfield消息获得Payload的长度为 2个字节，并可以推算出该待下载资源F的分片数为9-16片之间，则该待下载资源F的分 片大小为在[330K/16，330K/9](即20. 6Κ-36. 67Κ)的区间内的2的N次方的值，则可以在 20. 6Κ-36. 67Κ区间取32Κ为该待下载资源的分片大小。步骤240，客户端A根据分析获得的待下载资源的分片大小向至少一个peer发送 下载请求；具体的，当客户端A获得了待下载资源分片的大小后，可以与所述至少一个peer 交互并发送下载请求，实际应用中，当客户端A要从客户端C下载待下载资源分片时，客户 端A首先必须将它与客户端C之间的连接设置为interested，其实就是发一个interested 消息过去，而客户端C要检查其是否应该给客户端A发送数据，如果客户端C对客户端A 是imchoke，那么就可以给客户端A发送imchoke消息，当客户端A接收到客户端C发送的 unchoke消息后，可以向客户端C发送一个Request类型的消息以请求下载具体的分片数 据，该Request类型的消息中包括待下载资源分片的索引Piece Index、待下载数据的偏移 地址Block Offset以及待下载数据长度Block Length。本领域人员可以知道，客户端A可 以将一个分片中的数据分批次进行下载，一次只下载某个分片的部分数据块，也可以一次 下载该分片的所有数据。实际应用中，通常客户端在向peer请求资源时，一般不会一次将 整个分片一次下载，而是将一个分片分成几个数据块Block来进行下载，一般一个Block为 16K，当知道待下载资源的分片大小后，客户端可以根据分片大小划分为多个数据块。其中， Block Offset是数据块在待下载资源的分片内的偏移地址。例如若某个待下载资源的分片 大小为32K，以16K为一个数据块对所述待下载资源的分片进行划分，则第一个数据块的偏 移地址Block Offset为0，Block Length为16k，第二个数据块的偏移地址Block Offset 为 16*1024，Block Length 也是 16K。步骤245，客户端A接收至少一个peer根据所述下载请求返回的分片数据。具体的，当至少一个peer (例如客户端C)接收到客户端A的Request消息后，可以 向客户端A返回一个Piece消息，该Piece消息包含有客户端A请求的待下载资源的分片 索引Piece Index、待下载的数据的偏移地址Block Offset以及待下载数据Block Data, 其中，所述待下载的数据的偏移地址Block Offset是指待下载的数据块在该分片中的偏移 地址。从而使客户端A完成对该待下载资源的下载。通过本发明实施例提供的BT下载方法，客户端A在未获得待下载资源的种子文件的情况下，可以通过在网络中抓取下载相同资源的其他客户端发送给Tracker服务器的 Get announce请求数据包，并根据解析获得的信息构造并向Tracker服务器发送第二 Get announce请求，以获得Tracker服务器返回的拥有待下载资源的peer list信息，通过与至 少一个peer交互，获得待下载资源的分片大小，再根据该获得的分片大小向至少一个peer 下载待下载资源。从而实现了客户端在没有获得待下载资源的种子文件的情况下也能够进 行BT下载，提升了 BT资源下载的可靠性，更好的实现了资源的共享。图3为本发明实施例提供的一种BT下载装置的结构示意图，如图3所示，所述BT 下载装置包括数据包获取单元300，用于获取网络中向索引服务器发送的第一请求数据包；具体的，数据包获取单元300可以抓取网络中的其他客户端向索引服务器(即 Tracker服务器)发送的第一请求数据包，该第一请求数据包为网络中其他客户端请求索 引服务器返回拥有相同待下载资源的客户端列表信息的请求数据包，具体的，该第一请求 数据包可以是Get类型的请求数据包，该数据包中可以包括Tracker地址、待下载资源标识 以及待下载资源的大小信息，其中待下载资源标识用于唯一标识待下载资源。请求单元305，用于根据根据解析所述第一请求数据包获得的所述待下载资源信 息向所述索引服务器发送第二请求数据包，所述第二请求数据包用于向索引服务器请求拥 有所述待下载资源的客户端列表信息；具体的，请求单元305可以通过解析数据包获取单元300获得的第一请求数据包 获得Tracker服务器地址、待下载资源标识以及待下载资源的大小信息等待下载资源信 息，根据获得的待下载资源信息构造第二请求数据包，以向索引服务器请求返回拥有所述 待下载资源的客户端列表信息，具体的，该第二请求数据包也可以是Get类型的请求数据 包。接收单元310，用于接收所述索引服务器返回的客户端列表信息；具体的，当索引服务器接收到第二请求数据包后，可以根据第二请求数据包中的 待下载资源信息返回拥有该待下载资源的客户端列表信息。接收单元310即用于接收所述 索引服务器返回的客户端列表信息。处理单元315，用于从所述客户端列表中的至少一个客户端获得所述待下载资源 的分片信息，所述待下载资源的分片信息包括分片大小信息；具体的，当接收单元310接收到所述索引服务器返回的客户端列表信息后，处理 单元315可以通过与该客户端列表中的至少一个客户端进行BT握手交互，接收至少一个客 户端在BT握手后返回的待下载资源的分片信息，并根据获得的待下载资源的分片信息确 定该待下载资源的分片大小。下载单元320，用于根据所述待下载资源的分片信息从所述至少一个客户端下载 所述待下载资源。具体的，下载单元320可以根据处理单元315确定的待下载资源的分片大小向所 述至少一个客户端发送下载请求，从所述至少一个客户端下载待下载资源。本发明实施例提供的BT下载装置可以通过抓取网络中其他客户端向索引服务器 发送的请求数据包，并解析获得索引服务器的地址、待下载资源标识以及所述待下载资源 的大小信息等待下载资源信息，并构造第二请求数据包，从而获得索引服务器返回的拥有待下载资源的客户端列表信息，并通过与客户端列表中至少一个客户端交互获得待下载资 源的分片信息，从而根据待下载资源的分片信息向至少一个客户端下载分片数据，使得在 没有获得种子文件的请况下也能够进行BT下载，提升了 BT资源下载的可靠性，更好的实现 了 BT资源的共享。图4为本发明实施例提供的另一种BT下载装置的结构示意图，如图4所示，该下 载装置包括数据包获取单元300，用于获取网络中向索引服务器发送的第一请求数据包；具体的，当下载装置要下载待下载资源F时，若其在网络中没有获得F文件的种 子文件，可以通过抓包获得网络中下载资源F的其他客户端(例如客户端B)向索引服务 器(即Tracker服务器)发送的第一请求数据包，在本实施例中，该第一请求数据包可以是 Get类型的请求数据包，该第一请求数据包的目的是向Tracker服务器获取拥有待下载资 源的其它peer的信息，以便与其它peer通讯下载BT资源。请求单元305，用于根据根据解析所述第一请求数据包获得的所述待下载资源信 息向所述索引服务器发送第二请求数据包，所述第二请求数据包用于向索引服务器请求拥 有所述待下载资源的客户端列表信息；具体的，所述请求单元305可以包括解析子单元3051，用于解析所述数据包获取单元300获得的第一请求数据包获得 待下载资源信息；其中，所述待下载资源信息包括索引服务器的地址、待下载资源标识以及所述待 下载资源的大小信息。请求子单元3052，用于根据所述解析子单元3051解析获得的待下载资源信息向 所述索引服务器发送第二请求数据包，所述第二请求数据包用于向索引服务器请求拥有所 述待下载资源的客户端列表信息。接收单元310，用于接收所述索引服务器返回的客户端列表信息；具体的，Tracker服务器接收到请求子单元3052发送的第二请求数据包后，会向 客户端返回参与下载同一个文件例如F的其他下载者的信息peer list。其中返回的peer list信息中包含有各peer的IP地址和端口号，接收单元310用于接收Tracker返回的 peer list 信息。处理单元315，用于从所述客户端列表中的至少一个客户端获得所述待下载资源 的分片信息，所述待下载资源的分片信息包括分片大小信息；下载单元320，用于根据所述待下载资源的分片信息从所述至少一个客户端下载 所述待下载资源。具体的，下载单元320可以根据分析处理单元315分析确定待下载资源的分片大 小信息向所述客户端列表中的至少一个peer发送下载请求，并接收所述至少一个peer在 接收到下载请求后返回的分片数据。其中，该下载请求具体可以为Request类型的请求消 息，Request类型的消息中包括待下载资源分片的索引Piece Index、待下载数据的偏移地 址Block Offset以及待下载数据长度Block Length。所述至少一个peer在接收到下载请 求后返回的分片数据可以包含在Piece消息中，其中，所述Piece消息包含有客户端A请求 的待下载资源的分片索引Piece Index、待下载的数据的偏移地址Block Offset以及待下载数据 Block Data。本领域人员可以知道，下载单元320可以将一个分片中的数据分批次进行下载， 一次只下载某个分片的部分数据，也可以一次下载该分片的所有数据。实际应用中，通常客 户端在向peer请求资源时，一般不会一次将整个分片一次下载，而是将一个分片分成几个 数据块Block来进行下载，一般一个Block为16K，当知道待下载资源的分片大小后，客户 端可以根据分片大小划分为多个数据块。其中，Block Offset是数据块在待下载资源的分 片内的偏移地址。例如若某个待下载资源的分片大小为32K，以16K为一个数据块对所述待 下载资源的分片进行划分，则第一个数据块的偏移地址Block Offset为0，Block Length 为16k，第二个数据块的偏移地址Block Offset为16*1024，Block Length也是16K。进一步的，在本发明又一个实施例提供的BT下载装置中，包括数据包获取单元 300、请求单元305、接收单元310、处理单元315以及下载单元320，其中，所述数据包获取单 元300、请求单元305、接收单元310以及下载单元320可以参见前述实施例的描述，如图4 所示，所述处理单元315可以包括连接建立子单元3151，用于与所述客户端列表中的至少一个客户端建立通信连 接；具体的，可以根据peer list信息向至少一个peer发送BT握手请求消息，并接收 至少一个peer返回的BT握手应答消息，与至少一个peer建立通信连接。通常，客户端A 会向所有peer发送BT握手请求消息。接收子单元3152，用于接收至少一个peer在建立通信连接后发送的待下载资源 的位域bitfield消息；具体的，根据BT协议要求，当下载客户端与其他peer通过握手建立连接后，会立 即向对方发送bitfield消息，通报各自拥有的待下载资源的分片情况，如果peer没有待 下载资源的分片，则该peer可以不发送bitfield消息。其中，bitfield消息中包含有三 个部分消息长度Message Length、消息类型Message Type、数据负载Payload，其中，消息 长度Message Length为消息类型Message Type的长度及数据负载Payload的长度之和； bitfield消息中Message Type的值为5，其长度为1字节；数据负载Payload部分实际是 一个位图，如果该Peer有待下载资源的某个分片，那么对应的位置置1，否则置0。分析处理子单元3153，用于根据待下载资源的大小以及位域bitfield消息分析 确定待下载资源的分片大小。具体的，当接收子单元3152接收到peer list中至少一个peer发送的位域 bitfield消息后，分析处理子单元3153可以根据获得的bitfield消息以及解析子单元 3051解析获得的待下载资源的大小信息分析获得所述待下载资源的分片大小等分片信息。具体的，由于根据BT协议要求，根据该bitfield消息中携带的Message Length 减去消息类型Message Type的长度(1字节)获得该peer (例如客户端C)返回的数据 Payload 的长度，艮Payload 的长度=Message Length-I0 由于 Payload 中的每一位(bit) 标识一个分片，且1个字节等于8位(bit)，因此，分析处理子单元3153可以根据获得的 bitfield消息确定出该bitfield消息中携带的Payload的长度，并根据确定的Payload的 长度进一步确定该peer拥有的待下载资源的分片数区间。例如某个待下载资源共分为9 片，需要2个字节来表示(第二个字节只用到一位)，而另一个BT资源分为16片，也只需要2个字节来表示，则若解析bitfield消息获得的Payload的长度为2，可以判断出该待下载 资源的分片数在9-16片之间。进一步的，当分析处理子单元3153可以根据解析子单元3051解析获得的待下载 资源的大小信息以及前述分析获得的待下载资源的分片数区间确定所述待下载资源的分 片大小，具体的，由于BT资源的各分片大小一般为2的η次方，例如32K、64k、128K、256k、 512K、1M、2M、4M、8M，因此，分析处理子单元3153可以用待下载资源大小分别除以分片数区 间的两个端值，获得分片大小的一个区间，在分片大小的区间内取2的N次方的值则为该待 下载资源的分片大小。例如若解析子单元3051解析所述数据包获取单元300抓取的第一 请求数据包获得待下载资源F的大小为330K，分析处理子单元3153通过解析peer (例如客 户端C)发送的bitfield消息获得Payload的长度为2个字节，则可以推算出该待下载资 源F的分片数为9-16片之间，且该分片大小为在[330K/16，330K/9](即20. 6Κ-36. 67Κ)的 区间内的2的N次方的值，则可以在20. 6Κ-36. 67Κ区间取32Κ为该待下载资源的大小。本发明实施例提供的BT下载装置在未获得待下载资源的种子文件的情况下，可 以通过在网络中抓取下载相同资源的其他客户端发送给索引服务器的第一请求数据包，并 根据解析获得的待下载资源信息构造第二请求数据包，并向索引服务器发送第二请求数据 包，以获得索引服务器返回的拥有待下载资源的peer list信息，通过与peer list信息 中至少一个peer交互，获得待下载资源的分片大小，再根据该获得的分片大小向至少一个 peer下载待下载资源。从而实现了在没有获得待下载资源的种子文件的情况下也能够进行 BT下载，提升了 BT资源下载的可靠性，更好的实现了资源的共享。需要说明的是，上述实施例中的BT下载装置可以是指客户端，也可以是指服务 器，也可以只是应用于客户端或服务器中的一个模块，只要是能够实现下载BT资源的装置 即可。在实际应用中，上述实施例提供的BT下载方法及BT下载装置可以应用于下载系 统中，进一步的，本发明实施例也提供一种BT下载系统，可以包括索引服务器(Tracker服 务器)以及至少两个如前述实施例所述BT下载装置。此外，在实际应用中，上述实施例提供的BT下载方法及BT下载装置可以应用于缓 存系统中，具体的，可以将缓存系统不只在运营端的骨干网上，通过抓取网络上的数据包， 并对抓取的数据包进行分析，找出热门的BT资源，通过本发明实施例所述的下载方法或下 载装置从外网中进行下载该热点的BT资源并进行缓存，以供内网用户下载使用。当内网用 户下载缓存的热点BT资源时，缓存系统可以通过重定向将内网用户的下载请求重定向到 缓存系统的Tracker服务器上，由缓存系统的Tracker服务器向内网用户返回所述热点BT 资源的客户端或服务器列表。从而使缓存系统能够字段发现网络中的热点资源，并通过上 述下载方法在无法从外网中获取热点资源的种子文件时也能下载并缓存热点资源，并为内 网用户提供下载服务。从而减轻了网间流量，节省了出口带宽，提高了用户下载速度及下载 体验。需要说明的是，对于前述的各方法实施例，为了简单描述，故将其都表述为一系列 的动作组合，但是本领域技术人员应该知悉，本发明并不受所描述的动作顺序的限制，因为 依据本发明，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知 悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作和模块并不一定是本发明所必须的。在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部 分，可以参见其他实施例的相关描述。本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以 通过计算机程序来指令相关的硬件来完成，所述的程序可存储于计算机可读取存储介质 中，该程序在执行时，可包括如上述各方法的实施例的流程。其中，所述的存储介质可为磁 碟、光盘、只读存储记忆体(Read-Only Memory, ROM)或随机存储记忆体(Random Access Memory, RAM)等。以上所述仅为本发明的几个实施例，可以理解的是，对本领域普通技术人员来说， 可以根据本发明实施例的技术方案及其发明构思加以等同替换或改变，而所有这些改变或 替换都应属于本发明所附的权利要求的保护范围。
权利要求
一种比特洪流BT下载方法，其特征在于，包括获取网络中向索引服务器发送的第一请求数据包；根据解析所述第一请求数据包获得的待下载资源信息，向所述索引服务器发送第二请求数据包，所述第二请求数据包用于向索引服务器请求拥有所述待下载资源的客户端列表信息；接收所述索引服务器返回的客户端列表信息；从所述客户端列表中的至少一个客户端获得所述待下载资源的分片信息，所述分片信息包括分片大小信息；根据所述分片信息从所述至少一个客户端下载所述待下载资源。
2.根据1所述的方法，其特征在于，所述待下载资源信息包括索引服务器的地址、待下载资源标识以及所述待下载资源的大小信息。
3.根据权利要求2所述的方法，其特征在于，所述从所述客户端列表中的至少一个客 户端获得所述待下载资源的分片信息包括从所述客户端列表中的至少一个客户端获得所述待下载资源的分片数量信息； 根据所述待下载资源分片数量信息以及所述待下载资源大小信息确定所述待下载资 源的分片大小。
4.根据权利要求2所述的方法，其特征在于，所述从所述客户端列表中的至少一个客 户端获得所述待下载资源的分片信息包括与所述至少一个客户端进行建立通信连接；接收至少一个客户端在建立通信连接后发送的位域bitfield消息；根据所述bitfield消息中的数据负载Payload长度获得待下载资源的分片数量信息；根据所述待下载资源的大小以及所述待下载资源的分片数量获得所述待下载资源的 分片大小。
5.一种BT下载装置，其特征在于，包括数据包获取单元，用于获取网络中向索引服务器发送的第一请求数据包； 请求单元，用于根据根据解析所述第一请求数据包获得的待下载资源信息，向所述索 引服务器发送第二请求数据包，所述第二请求数据包用于向索引服务器请求拥有所述待下 载资源的客户端列表信息；接收单元，用于接收所述索引服务器返回的客户端列表信息； 处理单元，用于从所述客户端列表中的至少一个客户端获得所述待下载资源的分片信 息，所述分片信息包括分片大小信息；下载单元，用于根据所述分片信息从所述至少一个客户端下载所述待下载资源。
6.根据权利要求5所述的下载装置，其特征在于所述待下载资源信息包括索引服务 器的地址、待下载资源标识以及所述待下载资源的大小信息。
7.根据权利要求6所述的下载装置，其特征在于，所述处理单元包括连接建立子单元，用于与所述客户端列表中的至少一个客户端建立通信连接； 接收子单元，用于接收至少一个客户端在建立通信连接后发送的待下载资源的位域 bitfield 消息；分析处理子单元，用于根据待下载资源的大小以及bitfield消息分析确定待下载资 源的分片大小。
8.根据权利要求7所述的下载装置，其特征在于所述分析处理子单元用于根据所述bitfield消息的数据负载Payload长度获得所述 待下载资源的分片数量信息，并根据所述待下载资源的大小以及所述待下载资源的分片数 量获得所述待下载资源的分片大小信息。
9.一种BT下载系统，其特征在于，包括索引服务器以及至少两个如权利要求5-8任意 一项所述的下载装置。
全文摘要
本发明实施例公开了一种BT下载方法，包括获取网络中向索引服务器发送的第一请求数据包；根据解析所述第一请求数据包获得的待下载资源信息向所述索引服务器发送第二请求数据包，所述第二请求数据包用于向索引服务器请求拥有所述待下载资源的客户端列表信息；接收所述索引服务器返回的客户端列表信息；与所述客户端列表中的至少一个客户端交互，获得所述待下载资源的分片信息，所述待下载资源的分片信息包括分片大小信息；根据所述待下载资源的分片信息从所述至少一个客户端下载所述待下载资源。该下载方法可以在找不到种子文件的情况下实现BT资源的下载，提升了BT资源下载的可靠性。
文档编号H04L29/06GK101917488SQ20101026449
公开日2010年12月15日 申请日期2010年8月20日 优先权日2010年8月20日
发明者张勇 申请人:成都市华为赛门铁克科技有限公司