CN101626397A - 基于Bittorrent协议下载文件的系统 - Google Patents
基于Bittorrent协议下载文件的系统 Download PDFInfo
- Publication number
- CN101626397A CN101626397A CN200910000243A CN200910000243A CN101626397A CN 101626397 A CN101626397 A CN 101626397A CN 200910000243 A CN200910000243 A CN 200910000243A CN 200910000243 A CN200910000243 A CN 200910000243A CN 101626397 A CN101626397 A CN 101626397A
- Authority
- CN
- China
- Prior art keywords
- file
- node
- download
- server
- module
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Abstract
为了实现将FTP或HTTP服务器等服务器资源引入到Bittorrent协议模式中的目的,本发明提供了一种基于Bittorrent协议下载文件的系统,包括按照Bittorrent协议设置的网络,还包括连接于所述网络中的网络节点,网络节点包括普通节点、分布设置于网络中的DHT节点、服务器节点,服务器节点执行以下步骤:接收普通节点发来的下载请求并向该普通节点传递所请求下载的文件分块单位;普通节点上设置有普通上传模块,普通上传模块用于接收其他普通节点发来的下载请求并向该普通节点传递所请求下载的文件分块单位;DHT节点上设置信息保存模块记录网络节点具有的可供下载的文件的信息。
Description
技术领域
本发明涉及在网络中进行文件传输的技术。
背景技术
随着计算机和网络技术的发展,人们越来越多地从网络中获取需要的信息文件,这种便利的获取信息的方式极大地提高了人们生活、工作的效率。从网络中获取信息文件的方式常采用客户端/服务器(C/S)模式,例如从网站上下载所需要的信息文件。现在的信息文件,特别是多媒体文件日益庞大,这使得在C/S模式下获得信息文件的效率越来越低,主要原因在于客户端发出下载请求都集中于服务器,使得服务器的处理能力和网络带宽随着客户端数量的增加很快被消耗殆尽。这导致客户端下载速度变得缓慢,一个比较大的文件需要下载几个甚至几十个小时。
以目前的硬件技术还不能在低成本的前提下大幅度提高服务器的处理能力和网络带宽,这就需要人们寻求其他方法来提高文件传输速度。基于Bittorrent(简称为BT)协议或电驴协议等以对等网为基础的P2P(Peer to Peer)模式是解决上述问题的一种方式。在P2P(Peer to Peer)模式中,用户之间是对等关系,每个用户既为他人提供资源,也从他人那里下载需要的资源,每个用户端既是服务器也是客户端。P2P能更好的充分利用每个客户端的资源,能够解决FTP或HTTP等C/S模式下由于资源集中且承担了客户端过多的服务而引起的服务器带宽和处理请求能力方面的瓶颈问题,从而下载速度得以大大提高。
目前,网络中大量文件存储在FTP或HTTP服务器上,造成这种状况的主要原因在于FTP协议和HTTP协议具有更长的历史,但现阶段Bittorrent协议模式并不能直接支持FTP或HTTP协议下的文件的下载,这就使得在Bittorrent协议下网络中很大一部分资源不能够被利用。因此需要采取措施将FTP或HTTP服务器等服务器资源引入到Bittorrent协议模式中。
发明内容
为了实现将FTP或HTTP服务器等服务器资源引入到Bittorrent协议模式中的目的,本发明提供了一种基于Bittorrent协议下载文件的系统。
本发明的技术方案如下:
基于Bittorrent协议下载文件的系统,包括按照Bittorrent协议设置的网络,还包括连接于所述网络中的网络节点,网络节点包括普通节点、分布设置于网络中的DHT节点,普通节点上设置有下载请求模块和普通上传模块,下载请求模块用于向所述网络节点发出下载文件分块单位的请求,普通上传模块用于接收其他普通节点发来的下载请求并向该普通节点传递所请求下载的文件分块单位,网络节点还包括服务器节点,服务器节点上设置有服务器上传模块,服务器上传模块执行以下步骤:接收普通节点发来的下载请求并向该普通节点传递所请求下载的文件分块单位;DHT节点上设置信息保存模块记录普通节点具有的可供下载的文件,所述网络中至少有部分DHT节点的信息保存模块记录服务器节点具有的可供下载的文件的信息,信息保存模块响应普通节点的查询请求向发出查询请求的普通节点传递记录的信息。
所述服务器节点为FTP服务器或HTTP服务器。
普通节点上还设置有分块验证模块,分块验证模块对下载到的文件分块单位进行验证,执行如下功能:如果文件分块单位来自服务器节点,则对此文件分块单位进行哈希运算,得到的值为文件分块单位验证码;如果文件分块单位来自普通节点,则同时请求得到该文件分块单位的文件分块单位验证码,若对文件分块单位进行哈希运算得到的结果与该文件分块单位的文件分块单位验证码一致则保留该文件分块单位和文件分块单位验证码。
普通节点在向其他普通节点发出的Bittorent握手包中设置一对Bittorent消息以传输所述验证码:
请求验证码:<len=5><id=140><piece index>;
回复验证码:<len=25><id=141><piece index><hash value>。
分块验证模块还执行如下功能:如果对来自普通节点的文件分块单位进行哈希运算的结果与该文件分块单位的文件分块单位验证码不一致,则记录发送该文件分块单位的普通节点发生一次错误,如果某个普通节点累计发生错误数达到预定值,则不再向该普通节点发出下载文件分块单位的请求。
下载请求模块从服务器节点获取要下载文件的大小,特征码为文件在网络中唯一标识,根据该特征码向DHT节点查询获取所记录的信息,根据获取到的所述记录的信息向具有或部分具有该下载文件的网络节点发出下载请求,所述特征码为以下两者之一:如果在服务器节点的URL地址中提供了文件哈希值,则使用此文件哈希值作为特征码;否则,文件在服务器节点上的URL地址经哈希运算得到的哈希值作为特征码。
DHT节点可以在物理上与普通节点合并设置在同一设备上,即信息保存模块设置于普通节点上,这样可以不必为DHT节点单独设置硬件设备,DHT节点与普通节点共享硬件资源,节约了成本。
信息保存模块以一定周期更新所记录的信息。
信息保存模块还对应所述特征码保存文件哈希值;信息保存模块应普通节点的请求提供记录的信息。
信息保存模块还对应文件哈希值记录具有该文件的服务器节点地址,普通节点可以根据特征码查询到文件哈希值,进而查询到具有该文件的服务器节点地址和普通节点列表;对应特征码没有文件哈希值时,普通节点下载完文件后计算出文件哈希值并传给信息保存模块,信息保存模块将该特征码与该文件哈希值对应记录。
本发明的技术效果:
本发明的基于Bittorrent协议下载文件的系统将具有丰富文件内容的FTP、HTTP等服务器作为网络中特殊的节点(主要供普通节点下载内容),从而将FTP或HTTP服务器等服务器资源引入到Bittorrent协议模式中,一方面使得在Bittorrent协议模式下可以充分利用现有网络中的资源,另一方面,加快了普通节点从FTP、HTTP等服务器上下载文件的速度,并减轻了服务器的压力。对现有的FTP、HTTP等服务器不需要进行改造即可以实现本发明的目的,因此成本低廉。
附图说明
图1是本发明基于Bittorrent协议下载文件的系统的网络结构图;
图2是普通节点下载请求模块的流程图;
图3是普通节点上分块验证模块流程图;
图4是获得一个错误文件分块单位受普通节点上分块验证模块的处理流程。
图中标记列示如下:
1、服务器节点;2、普通节点;3、DHT节点。
具体实施方式
下面结合附图对本发明的技术方案进行详细说明。
如图1所示,基于BT协议下载文件的系统的网络节点(服务器节点1、普通节点2和DHT节点3)通过网络连接,连接而成的网络符合BT协议规范。服务器节点1上设置有服务器上传模块,服务器上传模块的主要作用在于响应网络中普通节点的下载请求并向该普通节点传递(上传)请求的文件(具体的是文件的分块单位,即将一个文件分割成大小均等的文件块,以利于在网络传输速度有限的条件下可以有效传递这些文件块,再将文件块合并成文件,获得文件的整体)。服务器节点1可以是FTP服务器或HTTP服务器等可以响应下载文件请求的服务器。由于现有的网络中FTP服务器和HTTP服务器保有量大,其上存有大量的文件,是内容丰富的下载源,本发明将BT协议和客户端/服务器模式的优点结合,可以使普通节点2获得更多的文件。
DHT节点3采用分布式哈希表(Distributed Hash Table,DHT)技术分布式的存储具有特定文件的网络节点信息,即文件的信息(如文件的特征码)、正在下载此文件的网络节点列表等都分布式的存储在DHT节点3上,当普通节点2需要查找具有某文件的网络节点列表,则通过向DHT节点构成的DHT网络发起查询(具体查询的规则可以依据现有的分布式哈希表技术规范),DHT网络返回上述列表等记录的信息后,根据获得的上述列表,普通节点2与列表中所列的网络节点建立连接并进行下载文件。DHT节点3上设置的信息保存模块记录正在下载特定文件的普通节点、具有该特定文件的服务器节点和文件的哈希值,将这些信息形成所述列表。信息保存模块周期性地更新记录的信息,也可以在记录的信息发生变化时即时更新。普通节点2向DHT节点发3出请求后,DHT节点3将相应的列表内容反馈给该普通节点2。采用DHT技术可以避免列表信息集中于有限的几个节点,当网络受到攻击时当这几个节点失效后就会导致整个网络不能工作。DHT技术将列表分散于网络中,承受攻击的能力强。另外,由于不必将列表集中设置于服务器,因此避免增加服务器的相关成本。
普通节点2是下载和使用文件的主体,能够向其他网络节点发出请求下载文件,也能够响应其他网络节点的请求提供文件。在普通节点2上设置有下载请求模块和普通上传模块。下载请求模块向其他网络节点发出下载文件的请求并获得文件,普通上传模块响应其他普通节点的下载请求上传(提供)相应文件。在本发明的系统中识别特定文件的标识为特征码,特征码有以下两种产生方法:如果在URL地址中提供了文件哈希值(如ED2K地址,ED2K链接是一个特别的链接格式,包含文件名、文件大小、文件哈希值等),则使用此文件哈希值作为特征码;否则,将文件在服务器节点上的URL地址经哈希运算得到的哈希值作为特征码。DHT节点3可以在物理上与普通节点2合并设置,即信息保存模块设置于普通节点2上,这样可以不必为DHT节点3单独设置硬件设备,DHT节点3与普通节点2共享硬件资源,节约了成本。
图2是普通节点上设置的下载请求模块的工作流程。普通节点首先向服务器节点发出请求,获得需要下载文件的大小,计算或提取该文件的特征码。对于FTP服务器使用Size Filepath可以得到文件大小;而HTTP协议中有content-length字段,可以直接得到文件大小。特征码根据该文件在服务器节点上的地址获得:如果URL地址中提供了文件哈希值,则直接取出其中的文件哈希值作为特征码;否则则对该URL地址进行Hash运算,得到的哈希(Hash)值作为该文件的特征码。
其次,普通节点得到上述的特征码后,依据DHT网络的查询规则向DHT节点(即信息保存模块)发出查询请求,获得可以提供此文件或此文件的分块单位的网络节点列表。如果DHT网络中存在正在下载此文件的用户,则DHT网络返回用户列表,如果DHT网络返回普通节点列表,则根据已有的特征码信息生成握手包,向普通节点列表中的普通节点发出Bittorrent连接握手包,使用特征码作为Bittorrent握手包中的哈希值,握手时必须对特征码进行比对,完全匹配才允许握手成功。如握手成功,对方即返回它拥有的已下载和未下载的文件分块单位的信息,根据此信息可以向对方发出数据请求。不断尝试连接其他普通节点,则可以得到网络中所有能连接到的普通节点的具有的文件分块单位信息,对所有的这些信息进行“或”运算,可以得到所有普通节点具有的文件分块单位的合集,据此可以判断,所需下载的文件是否已经完整地存在于网络的普通节点中。如不完整,则向服务器节点发出请求。
如果网络中不存在任何正在下载此文件普通节点,则DHT网络不能返回普通节点列表。此意味着本普通节点为下载此文件的第一个用户。将特征码和本普通节点的IP地址信息等保存在DHT网络中(即信息保存程序模块),再从服务器节点下载该文件数据。
在实际应用中可能会发生这样的情况:如果特征码是根据文件的链接地址确定的,在网络中如果文件相同,只是链接地址不同,仅根据特征码发出下载请求的话,只能下载一个源头的文件(即只能下载同一个服务器节点作为源头提供的文件),即使其他服务器节点具有该文件,也不能发出下载请求,这无形中浪费了资源。为了解决这一问题,在DHT节点上的信息保存模块保存如下两种格式的数据:
1)、以由链接地址计算得到的特征码作为关键字,保存文件哈希值、普通节点列表,即保存该特征码对应的文件的哈希值和已经下载该特征码代表的特定地址的文件的普通节点列表。文件的哈希值是指对整个文件进行哈希运算后得到的结果。
2)、以文件哈希值作为关键字,保存具有该哈希值代表的文件的普通节点列表、服务器节点列表。
普通节点在得到经链接地址计算得到的特征码后,向DHT节点(即信息保存模块,适用于独立设置DHT节点和DHT节点与普通节点物理上合并设置两种情况,以下同)发出查询,查询结果可能返回上述列表和文件哈希值,将返回的网络节点列表加入到自己可以连接的网络节点列表中。如果返回了文件哈希值,再以文件哈希值作为特征码向DHT节点发出查询,返回得到普通节点和服务器节点加入到自己可以连接的网络节点列表中。
普通节点下载完该文件后计算出文件哈希值,并按上述格式上传给信息保存模块保留,这样当下次再有普通节点下载此文件时,就可以根据链接地址查询到文件哈希值,并根据文件哈希值查询到具有此相同文件的所有普通节点和服务器节点,使得整个文件下载系统的效率更高。这样信息保存模块就可以不断增加信息,类似于通过学习不断增加知识。
第三,根据返回的网络节点列表,与这些网络节点建立连接,发出下载请求。如果反馈的结果表明没有普通节点正在下载该文件,则向服务器节点发出下载请求,获取文件,同时在DHT的信息保存模块中记录该文件的文件哈希值及自身普通节点的IP地址信息。
普通节点上还设置有分块验证模块,用于对获得的文件分块单位进行验证,避免获得错误的文件分块单位。图3为分块验证模块的流程图。
每个文件分块单位都有对应的验证码,普通节点获得验证码的来源有如下三种方式:
1、如果下载的文件分块单位来自服务器节点,则得到全部文件分块单位后对其进行哈希运算,得到的哈希值作为该文件分块单位的验证码;
2、如果存在相应的种子文件,则从种子文件中获得该文件分块单位的验证码。
3、如果不存在相应的种子文件,且下载的文件分块单位来自在DHT上查询到的普通节点,则向普通节点请求验证码。在向其他普通节点发出的Bittorent握手包中设置一对Bittorent消息以传输所述验证码:
请求验证码:<len=5><id=140><piece index>;
回复验证码:<len=25><id=141><piece index><hash value>。
在上述格式中,第一个字段len为4个字节的整型,指明本消息的长度,它等于以字节为单位,除len之外的其它字段的长度和。对于请求哈希验证码,它的值为1+4=5,对于回复哈希验证码,它的值为1+4+20=25。第二个字段为1个字节,指明本消息的类型,值分别为140和141。第三个字段均为本次消息的所使用的分块序号。对于回复哈希验证码消息,第四个字段为分块序号对应的验证码。
分块验证模块执行如下步骤:
首先判断获得的文件分块单位是否来自于服务器节点,如果是来自于服务器节点,则对该文件分块单位进行哈希运算得到验证码,对于从服务器节点获得的文件分块单位认为是正确的,直接保存文件分块单位和验证码,无须对该文件分块单位进行验证。
其次,如果文件分块单位来自于其他普通节点,则从该普通节点或种子文件获得其验证码,对该文件分块单位进行哈希运算,得到的哈希值与验证码进行对比,如果一致,则该文件分块单位是正确的;如果不一致则该文件分块单位是错误的。
如果文件分块单位是正确的,保存文件分块单位及验证码。
如果文件分块单位是错误的,重新发出对该文件分块单位的下载请求。重新发出下载请求按如下方式进行:
对于每个文件分块单位,均记录该文件分块单位由哪个普通节点提供的。在普通节点上设置有错误计数器,记录得到错误文件分块单位的次数及对应的普通节点。
如果记录的某个普通节点发送错误文件分块单位的次数累计达到预定的值,即可认为该普通节点为非正常节点,通知下载模块不再向该普通节点发送下载请求,即列入黑名单,这样能有效防止他人通过不断地发错误数据来对系统进行攻击。
在本实施例中需要考虑文件分块单位分级的情况,这种情况在BT协议中有规定,如每个文件分块单位大小为256K,每个块由16个分片组成,每个分片的大小为16K。下载单位为分片,即可以以16K大小的分片为单位进行下载;验证单位为文件分块单位,一旦开始对一个新的文件分块单位的请求,则必须将整个文件分块单位的数据全部下载完成,以方便向连接自己的其他网络节点报告“拥有”了此文件分块单位。文件分块单位大小也可以根据BT协议规范中的种子文件规定。针对这种情况,分块验证模块执行的步骤进一步细化如下(见图4所示流程图):
在下载时记录下每个文件分块单位的每个分片分别来自哪个普通节点,当验证文件分块单位为错误时,此时并不立即丢弃此错误数据分块。如果服务器节点具有该正在下载的文件,则向服务器节点请求并下载该文件分块单位,保存文件分块单位和验证码。将从服务器节点得到的文件分块单位与刚被验证发生错误的文件分块单位对比,得知哪一个或哪几个分片发生错误,在错误计数器中为提供该分片的普通节点累计一次或几次错误,一个错误分片对应累计一次错误。
如果服务器节点不具有该正在下载的文件,则选择一个下载速度较快并拥有该文件分块单位分片的普通节点(以下简称为选择节点)下载。为了节省网络资源,避免重复下载正确的分片,在向选择节点发出下载请求前需要进行如下步骤:
查询在提供了错误文件分块单位的普通节点中,是否有错误计数记录,如果有,向选择节点请求下载该普通节点提供的那一个分片。重新下载的分片对原错误文件分块单位中队应的分片进行替换构成完整的文件分块单位,然后对其进行验证,如果验证为正确,则保留文件分块单位,并比较错误文件分块单位与正确文件分块单位确定有哪些分片是错误的,为提供1个错误分片的普通节点累计1次错误计数。如果替换后的文件分块单位被验证为错误,则向选择节点请求下载其他有错误记录普通节点提供的分片,重复上述过程,直到所有有错误记录的普通节点提供的分片均被替换。如果所有有错误记录普通节点提供的分片已经全被替换,文件分块单位仍然是错误的,则向选择节点请求下载文件分块单位的全部剩余分片,对从选择节点得到的该文件分块单位进行验证,如果文件分块单位正确,则保留文件分块单位,对提供错误分片的普通节点累计错误数;如果文件分块单位错误,则累计选择节点的错误数,重新确定选择节点并向其发出下载请求,重复进行上述步骤,直到得到正确的文件分块单位。
如果选择节点的出错率较高,可以直接选择服务器节点进行下载并保存数据和验证信息,这样可以节省时间和带宽。
需要指出的是,上述哈希运算的算法在普通节点之间应当是同一的,这样才能起到验证的作用。
以下对本发明的下载文件的系统的工作过程进行描述:
普通节点向服务器节点发起连接请求,并获知所要下载的文件的大小,对于FTP服务器使用Size Filepath可以得到文件大小;而HTTP协议中有content-length字段,可以直接得到文件大小。对FTP或HTTP服务器上的文件以块大小为256K进行分块,并计算分片数量,生成分块信息表,所有分块初始状态都置为0,表示还未获得该分块。分块信息表可以表明文件的下载进度。
获得要下载文件的特征码。
根据特征码向DHT节点构成的DHT网络发起查询。向DHT网络发送get_peers消息,查询正在下载该特征码的文件的普通节点列表,并发送announce_peer将自己的IP地址、端口存储在信息保存程序模块(在本实施例中信息保存程序模块设置在普通节点上)中。如果DHT网络中存在正在下载此文件的用户,则DHT网络返回用户列表,如果网络中不存在任何正在下载此文件普通节点,则DHT网络不能返回普通节点列表。此意味着本普通节点为下载此文件的第一个用户。将特征码和本普通节点的IP地址信息等保存在DHT网络中(即信息保存程序模块),再从服务器节点下载该文件数据,每获取一个文件分块,都将分块信息表中对应的比特位置为1,以表明此块下载完成。如果网络中存在其他正在下载此文件的普通节点,则DHT网络会返回一个普通节点列表,该列表记载正在下载此文件的普通节点。如果DHT网络返回普通节点列表,则根据已有的特征码信息生成握手包,向普通节点列表中的普通节点发出Bittorrent连接握手包,使用特征码作为Bittorrent握手包中的哈希值,握手时必须对特征码进行比对,完全匹配才允许握手成功。如握手成功,对方即返回它拥有的已下载和未下载的分块信息表,根据此分块信息表可以向对方发出数据请求。不断尝试连接其它普通节点,则可以得到网络中所有能连接到的普通节点的分块信息表,对所有的分块信息表进行“或”运算,可以得到所有普通节点的分块信息的合集,据此可以判断,所需下载的文件是否已经完整地存在于网络的普通节点中。如不完整,则向服务器节点发出请求。
如果分块是从服务器节点下载的,则在一个分块下载完成时(从服务器节点只能下载分块的全部分片,不能以分片为单位进行下载),对它进行哈希运算,得到此分块的哈希值作为该分块的验证码保存,以备其他普通节点对此验证码的请求。
如果分块来自其他普通节点,则在普通节点上增加一对Bittorrent消息,以传输分块的验证码。
在得到分块和对应的验证码后进行验证,并根据验证结果保存正确的分块和验证码,放弃错误的分块。每成功下载一个分块,将自己的分块信息表的对应位置为1,并给所有连接上本普通节点的网络节点发送HAVE消息,表明自己拥有此分片,以便其他普通节点请求。
Claims (10)
1、基于Bittorrent协议下载文件的系统,包括按照Bittorrent协议设置的网络,还包括连接于所述网络中的网络节点,网络节点包括普通节点、分布设置于所述网络中的DHT节点,普通节点上设置有下载请求模块和普通上传模块,下载请求模块用于向所述网络节点发出下载文件分块单位的请求,普通上传模块用于接收其他普通节点发来的下载请求并向该普通节点传递所请求下载的文件分块单位,其特征在于网络节点还包括服务器节点,服务器节点上设置有服务器上传模块,服务器上传模块执行以下步骤:接收普通节点发来的下载请求并向该普通节点传递所请求下载的文件分块单位;DHT节点上设置信息保存模块记录普通节点具有的可供下载的文件,所述网络中至少有部分DHT节点的信息保存模块记录服务器节点具有的可供下载的文件的信息,信息保存模块响应普通节点的查询请求向发出查询请求的普通节点传递记录的信息。
2、根据权利要求1所述下载文件的系统,其特征在于所述服务器节点为FTP服务器或HTTP服务器。
3、根据权利要求1所述下载文件的系统,其特征在于所述DHT节点和普通节点设置在同一物理设备上。
4、根据权利要求1至3之一所述下载文件的系统,其特征在于信息保存模块以一定周期更新所记录的信息。
5、根据权利要求1至3之一所述下载文件的系统,其特征在于普通节点上还设置有分块验证模块,分块验证模块对下载到的文件分块单位进行验证,执行如下功能:如果文件分块单位来自服务器节点,则对此文件分块单位进行哈希运算,得到的值为文件分块单位验证码;如果文件分块单位来自普通节点,则同时请求得到该文件分块单位的文件分块单位验证码,若对文件分块单位进行哈希运算得到的结果与该文件分块单位的文件分块单位验证码一致则保留该文件分块单位和文件分块单位验证码。
6、根据权利要求5所述下载文件的系统,其特征在于普通节点在向其他普通节点发出的Bittorent握手包中设置一对Bittorent消息以传输所述验证码:
请求验证码:<len=5><id=140><piece index>;
回复验证码:<len=25><id=141><piece index><hash value>。
7、根据权利要求5所述下载文件的系统,其特征在于分块验证序模块还执行如下功能:如果对来自普通节点的文件分块单位进行哈希运算的结果与该文件分块单位的文件分块单位验证码不一致,则记录发送该文件分块单位的普通节点发生一次错误,如果某个普通节点累计发生错误数达到预定值,则不再向该普通节点发出下载文件分块单位的请求。
8、根据权利要求1至3之一所述下载文件的系统,其特征在于下载请求模块从服务器节点获取要下载文件的大小和特征码,特征码为文件在网络中唯一标识,根据该特征码向DHT节点查询获取所记录的信息,根据获取到的所述记录的信息向具有或部分具有该下载文件的网络节点发出下载请求,所述特征码为以下两者之一:如果在服务器节点的URL地址中提供了文件哈希值,则使用此文件哈希值作为特征码;否则,文件在服务器节点上的URL地址经哈希运算得到的哈希值作为特征码。
9、根据权利要求8所述下载文件的系统,其特征在于信息保存模块还对应所述特征码保存文件哈希值;信息保存模块应普通节点的请求提供记录的信息。
10、根据权利要求9所述下载文件的系统,其特征在于信息保存模块还对应文件哈希值记录具有该文件的服务器节点地址,普通节点可以根据特征码查询到文件哈希值,进而查询到具有该文件的服务器节点地址和普通节点列表;对应特征码没有文件哈希值时,普通节点下载完文件后计算出文件哈希值并传给信息保存模块,信息保存模块将该特征码与该文件哈希值对应记录。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN200910000243A CN101626397A (zh) | 2008-07-11 | 2009-01-14 | 基于Bittorrent协议下载文件的系统 |
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN200810132759.X | 2008-07-11 | ||
CN200810132759 | 2008-07-11 | ||
CN200910000243A CN101626397A (zh) | 2008-07-11 | 2009-01-14 | 基于Bittorrent协议下载文件的系统 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN101626397A true CN101626397A (zh) | 2010-01-13 |
Family
ID=41522001
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN200910000243A Pending CN101626397A (zh) | 2008-07-11 | 2009-01-14 | 基于Bittorrent协议下载文件的系统 |
CN200910000242A Pending CN101626304A (zh) | 2008-07-11 | 2009-01-14 | P2p协议下实现多媒体即时播放的方法及装置 |
Family Applications After (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN200910000242A Pending CN101626304A (zh) | 2008-07-11 | 2009-01-14 | P2p协议下实现多媒体即时播放的方法及装置 |
Country Status (1)
Country | Link |
---|---|
CN (2) | CN101626397A (zh) |
Cited By (10)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN102148835A (zh) * | 2011-04-27 | 2011-08-10 | 许式伟 | 一种电子文档传递和分享的方法和系统 |
CN102546634A (zh) * | 2012-01-10 | 2012-07-04 | 北京邮电大学 | 匿名获取文件的方法和节点 |
CN102594901A (zh) * | 2012-02-29 | 2012-07-18 | 深圳创维-Rgb电子有限公司 | 一种电视机数据下载的方法、系统、电视机及服务器 |
CN103986747A (zh) * | 2014-04-14 | 2014-08-13 | 曦威胜科技开发(深圳)有限公司 | P2p协议中文件共享下载方法 |
CN106550015A (zh) * | 2016-10-12 | 2017-03-29 | 中国农业大学 | 一种对等网络下的节点文件传输方法、索引服务器及系统 |
CN109688204A (zh) * | 2018-12-05 | 2019-04-26 | 量子云未来(北京)信息科技有限公司 | 基于ndn网络的文件下载方法、装置、节点、终端 |
CN109784965A (zh) * | 2018-11-17 | 2019-05-21 | 程昔恩 | 一种存储关键数据的区块链方法 |
CN110909737A (zh) * | 2019-11-14 | 2020-03-24 | 武汉虹旭信息技术有限责任公司 | 图片文字识别方法及系统 |
CN112468330A (zh) * | 2020-11-13 | 2021-03-09 | 苏州浪潮智能科技有限公司 | 一种故障节点的设置方法、系统、设备以及介质 |
CN116546009A (zh) * | 2023-07-06 | 2023-08-04 | 北京华云安信息技术有限公司 | 资产发现的方法、装置、电子设备和存储介质 |
Families Citing this family (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101834904A (zh) * | 2010-05-14 | 2010-09-15 | 杭州华三通信技术有限公司 | 一种数据备份方法和设备 |
CN102447974B (zh) * | 2011-11-03 | 2014-04-09 | 苏州大学 | 一种p2p视频点播系统合作数据预取方法 |
CN104767814B (zh) * | 2015-04-13 | 2018-09-25 | 天脉聚源(北京)教育科技有限公司 | 一种局域网中文件传输的方法和装置 |
CN106454553A (zh) * | 2016-11-15 | 2017-02-22 | 深圳市视维科技有限公司 | 精准时延直播视频网络传输控制方法 |
CN108271063A (zh) * | 2016-12-30 | 2018-07-10 | 北京优朋普乐科技有限公司 | 一种基于p2p网络的直播数据处理方法、装置和系统 |
CN110366008B (zh) * | 2018-03-26 | 2021-10-08 | 阿里巴巴(中国)有限公司 | 多媒体资源请求识别方法、装置及存储介质 |
CN113573079B (zh) * | 2021-09-23 | 2021-12-24 | 北京全心数字技术有限公司 | 一种自由视角直播方式的实现方法 |
Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101030873A (zh) * | 2007-02-15 | 2007-09-05 | 深圳市迅雷网络技术有限公司 | 一种下载数据的方法及系统 |
CN101079709A (zh) * | 2006-06-15 | 2007-11-28 | 腾讯科技(深圳)有限公司 | 单点对多节点并发下载系统和方法 |
CN101141459A (zh) * | 2007-10-25 | 2008-03-12 | 南京远古科技有限公司 | 使用http与p2p相结合实现数据传输或流媒体传输的方法 |
-
2009
- 2009-01-14 CN CN200910000243A patent/CN101626397A/zh active Pending
- 2009-01-14 CN CN200910000242A patent/CN101626304A/zh active Pending
Patent Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101079709A (zh) * | 2006-06-15 | 2007-11-28 | 腾讯科技(深圳)有限公司 | 单点对多节点并发下载系统和方法 |
CN101030873A (zh) * | 2007-02-15 | 2007-09-05 | 深圳市迅雷网络技术有限公司 | 一种下载数据的方法及系统 |
CN101141459A (zh) * | 2007-10-25 | 2008-03-12 | 南京远古科技有限公司 | 使用http与p2p相结合实现数据传输或流媒体传输的方法 |
Cited By (13)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN102148835A (zh) * | 2011-04-27 | 2011-08-10 | 许式伟 | 一种电子文档传递和分享的方法和系统 |
CN102546634A (zh) * | 2012-01-10 | 2012-07-04 | 北京邮电大学 | 匿名获取文件的方法和节点 |
CN102594901A (zh) * | 2012-02-29 | 2012-07-18 | 深圳创维-Rgb电子有限公司 | 一种电视机数据下载的方法、系统、电视机及服务器 |
CN103986747A (zh) * | 2014-04-14 | 2014-08-13 | 曦威胜科技开发(深圳)有限公司 | P2p协议中文件共享下载方法 |
CN106550015A (zh) * | 2016-10-12 | 2017-03-29 | 中国农业大学 | 一种对等网络下的节点文件传输方法、索引服务器及系统 |
CN109784965A (zh) * | 2018-11-17 | 2019-05-21 | 程昔恩 | 一种存储关键数据的区块链方法 |
CN109688204A (zh) * | 2018-12-05 | 2019-04-26 | 量子云未来(北京)信息科技有限公司 | 基于ndn网络的文件下载方法、装置、节点、终端 |
CN109688204B (zh) * | 2018-12-05 | 2022-01-04 | 量子云未来(北京)信息科技有限公司 | 基于ndn网络的文件下载方法、节点、终端 |
CN110909737A (zh) * | 2019-11-14 | 2020-03-24 | 武汉虹旭信息技术有限责任公司 | 图片文字识别方法及系统 |
CN112468330A (zh) * | 2020-11-13 | 2021-03-09 | 苏州浪潮智能科技有限公司 | 一种故障节点的设置方法、系统、设备以及介质 |
CN112468330B (zh) * | 2020-11-13 | 2022-12-06 | 苏州浪潮智能科技有限公司 | 一种故障节点的设置方法、系统、设备以及介质 |
CN116546009A (zh) * | 2023-07-06 | 2023-08-04 | 北京华云安信息技术有限公司 | 资产发现的方法、装置、电子设备和存储介质 |
CN116546009B (zh) * | 2023-07-06 | 2023-09-22 | 北京华云安信息技术有限公司 | 资产发现的方法、装置、电子设备和存储介质 |
Also Published As
Publication number | Publication date |
---|---|
CN101626304A (zh) | 2010-01-13 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN101626397A (zh) | 基于Bittorrent协议下载文件的系统 | |
CN102355426B (zh) | 实现离线文件传输的方法和系统 | |
US9282141B2 (en) | Method and system for loading file in webgame | |
US20140280859A1 (en) | Sharing control system and method for network resources download information | |
US9277006B2 (en) | Peer-to-peer communication of non-common data | |
CN109491758A (zh) | docker镜像分发方法、系统、数据网关及计算机可读存储介质 | |
CN101217431A (zh) | 同步移动终端、网络电视、网络相册的图片的方法及系统 | |
CN103973475A (zh) | 差异补丁包生成方法及下载方法、服务器、客户端 | |
WO2006081663A1 (en) | Method, apparatus and system for interfering with distribution of protected content | |
US20140143339A1 (en) | Method, apparatus, and system for resource sharing | |
CN103369002B (zh) | 一种资源下载的方法及系统 | |
CN103220308B (zh) | 一种文件下载方法、装置及系统 | |
CN110855760A (zh) | 一种基于区块链的分布式安全存储系统部署方法 | |
CN103248666A (zh) | 一种离线下载资源的系统、方法及装置 | |
SE531820C2 (sv) | Förfarande och system för legal fildelning | |
CN101409727B (zh) | 一种文件传输方法及装置 | |
CN110597922A (zh) | 数据处理方法、装置、终端及存储介质 | |
CN102194014A (zh) | 文档存储方法和文档恢复方法 | |
CN111046065A (zh) | 可扩展的高性能分布式查询处理方法及装置 | |
CN110866046A (zh) | 一种可扩展的分布式查询方法及装置 | |
CN101753572B (zh) | 基于抗黑名单机制的BitTorrent文件污染方法 | |
CN107613016A (zh) | 文件批量下载方法、客户端、分发服务器及系统 | |
CN101098268A (zh) | 网络教学的p2p服务方法 | |
CN102739701A (zh) | 媒体流访问控制方法与对等流媒体系统 | |
KR101436406B1 (ko) | P2p기반 업데이트 클라이언트, 서버 장치, 시스템 및 방법 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
C02 | Deemed withdrawal of patent application after publication (patent law 2001) | ||
WD01 | Invention patent application deemed withdrawn after publication |
Application publication date: 20100113 |