具体实施方式
下面将结合本发明实施例中的附图,对本发明实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本发明一部分实施例,而不是全部的实施例。基于本发明中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都属于本发明保护的范围。
需要说明的是,本发明实施例提供的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确定其要获得的Getannounce请求数据包。
步骤205,客户端A解析第一请求数据包;
具体的,可以解析客户端B向Tracker服务器发送的Get announce请求数据包,获得Tracker服务器地址、待下载资源的标识以及待下载资源的大小信息。其中,Get announce请求的格式可以为:
GET announce?info_hash=xxx&download=m&left=n&...
其中,可以从该Get announce请求数据包的包头中提取Tracker的地址信 息及端口号,根据Get announce参数直接得到待下载资源的标识info_hash,并通过将Get announce参数中的download与left相加得到待下载资源的大小。
步骤210,客户端A向Tracker服务器发送第二请求数据包;
具体的,客户端根据步骤205中解析第一请求数据包获得的信息(包括:Tracker服务器的地址信息及端口号、待下载资源的标识info_hash、待下载资源的大小)构造第二请求数据包,并向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,否则置0。
步骤235,客户端A根据待下载资源的大小以及bitfield消息分析确定待下载资源的分片大小;
根据BT协议要求,当客户端A接收到peer(例如客户端C)在BT握手后发送的待下载资源的bitfield消息后,可以根据该bitfield消息中携带的Message Length减去消息类型Message Type的长度(1字节)获得该peer(例如客户端C)返回的数据Payload的长度。即Payload的长度=Message Length-1。由于Payload中的每一位(bit)标识一个分片,且1个字节等于8位(bit),因此,通过Payload的长度可以确定该peer拥有的待下载资源的分片数在一个首尾相距7个bit的区间内。例如:某个待下载资源共分为9片,需要2个字节来表示(第二个字节只用到一位),而另一个BT资源分为16片,也只需要2个字节来表示,则若解析bitfield消息获得的Payload的长度为2,可以判断出该待下载资源的分片数在9-16片之间。
由于在步骤205中已经通过解析第一请求数据包获得待下载资源的大小,在本步骤中,可以根据获得的bitfield消息中的Payload的长度推算出该待下载资源的总分片数,并且,由于BT资源的各分片大小一般为2的n次方,例如: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.6K-36.67K)的区间内的2的N次方的值,则可以在20.6K-36.67K区间取32K为该待下载资源的分片大小。
步骤240,客户端A根据分析获得的待下载资源的分片大小向至少一个peer发送下载请求;
具体的,当客户端A获得了待下载资源分片的大小后,可以与所述至少一个peer交互并发送下载请求,实际应用中,当客户端A要从客户端C下载待下载资源分片时,客户端A首先必须将它与客户端C之间的连接设置为interested,其实就是发一个interested消息过去,而客户端C要检查其是否应该给客户端A发送数据,如果客户端C对客户端A是unchoke,那么就可以给客户端A发送unchoke消息,当客户端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-1。由于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的n次方,例如: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.6K-36.67K)的区间内的2的N次方的值,则可以在20.6K-36.67K区间取32K为该待下载资源的大小。
本发明实施例提供的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)等。
以上所述仅为本发明的几个实施例,可以理解的是,对本领域普通技术人员来说,可以根据本发明实施例的技术方案及其发明构思加以等同替换或改变,而所有这些改变或替换都应属于本发明所附的权利要求的保护范围。