CN101075879B - 一种数据下载方法 - Google Patents
一种数据下载方法 Download PDFInfo
- Publication number
- CN101075879B CN101075879B CN2006100828421A CN200610082842A CN101075879B CN 101075879 B CN101075879 B CN 101075879B CN 2006100828421 A CN2006100828421 A CN 2006100828421A CN 200610082842 A CN200610082842 A CN 200610082842A CN 101075879 B CN101075879 B CN 101075879B
- Authority
- CN
- China
- Prior art keywords
- file
- downloading
- downloaded
- receiving
- redirection
- 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.)
- Active
Links
- 238000000034 method Methods 0.000 title claims abstract description 57
- 230000008569 process Effects 0.000 claims abstract description 17
- 230000004044 response Effects 0.000 claims description 10
- 230000005540 biological transmission Effects 0.000 claims description 7
- 238000001914 filtration Methods 0.000 claims description 7
- 238000010586 diagram Methods 0.000 description 6
- 230000003993 interaction Effects 0.000 description 2
- 230000006872 improvement Effects 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
Images
Landscapes
- Information Transfer Between Computers (AREA)
Abstract
本发明提供一种数据下载方法,其关键在于,将小文件集合中的所有文件进行编号,生成种子节点表,并利用重定向技术进行下载。原下载端将种子节点表发送给接收端,接收端创建用于记录文件接收状态的接收状态表;接收端根据接收状态表确定欲下载文件编号,并根据欲下载文件编号和种子节点表发起下载流程,获得所述欲下载文件编号对应的文件;然后,接收端更新接收状态表,并重新确定欲下载文件编号对未下载的文件进行下载,直至获得小文件集合中的所有文件。应用本发明方案,原下载端可以通过重定向的方式将文件下载给接收端,接收端不但可以从原下载端接收到文件,而且可以从好友用户端接收到文件,可以提高下载速度,减少原下载端的下载负荷。
Description
技术领域
本发明涉及网络数据传输技术,特别是涉及一种数据下载方法。
背景技术
目前,提出了一种对等网络(P2P)技术,可以达到资源共享和即时通讯的目的。图1是一个典型的基于P2P技术的网络结构示意图。如图1所示,该网络包括信息索引服务器和N个用户端。其中,信息索引服务器用于记录用户端的基本信息,如:在线或离线信息、ID号等。每一个用户端都有一个好友用户群,该用户端与好友用户群中的每一个用户端之间都建立了好友连接关系,可以进行交互,比如:聊天、发布通知、传输文件或小文件集合等。
其中,小文件集合是一种由多个数据量比较小的文件组成的集合。比如:由大量图像文件组成的数字相册,或由大量MP3文件组成的CD。一个图像文件或一个MP3文件一般比较小,一般为几K字节~几M字节,但数字相册或CD的数据总量却比较大,可以为几十个G字节,甚至上百个G字节。
当某用户端要将小文件集合共享给好友用户群的用户端时,一般是直接将所述小文件集合依次发送给好友用户群的所有用户端。这里所述的提供小文件集合的用户端也称为下载端,好友用户群的用户端则称为好友用户端。如果好友用户端比较多,小文件集合总的数据量比较大时,下载端的下载负荷就比较大,而且需要花费较长的时间才能将小文件集合下载给好友用户端。
由此可见,在现有技术中,还没有一种数据下载方法,不但可以将小文件集合快速地下载给好友用户端,而且可以减少下载端的下载负荷。发明内容
有鉴于此,本发明的主要目的在于提供一种数据下载方法,不但可以将小文件集合快速地下载给好友用户端,而且可以减少下载端的下载负荷。为了达到上述目的,本发明提出的技术方案为:
一种数据下载方法,设置种子节点表,用于记录文件编号和对应的拥有该文件的好友用户端ID号,该方法包括以下步骤:
a、原下载端将种子节点表发送给接收端,接收端创建用于记录文件接收状态的接收状态表;
b、接收端根据接收状态表确定欲下载文件编号,并根据欲下载文件编号和种子节点表发起下载流程,获得所述欲下载文件编号对应的文件;
c、接收端更新接收状态表,并返回步骤b,直至获得小文件集合的所有文件。
较佳地,步骤b所述下载流程为:
X1、接收端向本次下载端发送携带有欲下载文件编号的文件下载请求消息;
X2、本次下载端根据自身的下载任务队列表和种子节点表判断是否需要重定向,如果需要,则根据自身种子节点表确定重定向端,并执行步骤X3;否则,执行步骤X4;
X3、接收端向重定向端发送携带有欲下载文件编号的文件下载请求消息,重定向端判断自身是否存在所述欲下载文件编号对应的文件,如果存在,则将所述欲下载文件编号对应的文件排列在自身下载队列中,发送给接收端,再执行步骤c;否则,执行步骤X5;
X4、本次下载端将所述欲下载文件编号对应的文件排列在自身下载队列中,发送给接收端,再执行步骤c;
X5、重定向端向接收端返回无下载文件响应消息,接收端再向原下载端发送携带有欲下载文件编号的文件下载请求消息,并接收所述欲下载文件编号对应的文件,再执行步骤c。
较佳地,当最初提供小文件集合的发布端在线时,
步骤a和步骤b下载流程中所述原下载端为发布端;
确定步骤b下载流程中所述本次下载端的方法为:接收端将种子节点表中欲下载文件编号对应的好友用户端ID号发送给信息索引服务器进行在线过滤,获得在线的好友用户端ID号,接收端再从所述在线好友用户端中确定一个本次下载用户端。
较佳地,所述接收端从在线好友用户端中确定一个本次下载端的方法为:
接收端从在线好友用户端中随机确定一个本次下载用户端;或者,
接收端将数据传输速度最快的在线好友用户端作为本次下载端。
较佳地,所述步骤a之前进一步包括:发布端向接收端发送共享通知消息,接收端再向发布端发送下载请求消息。
较佳地,步骤X5所述接收端向发布端发送文件下载请求消息和接收文件之间进一步包括:
发布端根据自身下载任务队列表和种子节点表判断是否需要重定向,如果需要,则根据自身种子节点表确定重定向端,接收端向重定向用户端发送携带有欲下载文件编号的文件下载请求消息,重定向用户端判断自身是否存在所述欲下载文件编号对应的文件,如果存在,则将所述欲下载文件编号对应的文件排列在自身下载队列中;否则,发布端将所述欲下载文件编号对应的文件排列在自身下载队列中。
较佳地,步骤c所述接收端更新接收状态表和返回步骤b之间进一步包括:
接收端将已下载文件编号上报给发布端,发布端根据已下载文件编号更新种子节点表;
步骤X5所述重定向端向接收端返回无下载文件响应消息和接收端向发布端发送文件下载请求消息之间进一步包括:
重定向端将未下载文件的文件编号上报给发布端,发布端根据未下载文件编号更新种子节点表。
较佳地,当最初提供小文件集合的发布端离线时,
步骤a所述原下载端、步骤b所述下载流程中的本次下载端和原下载端都为伪发布端;
所述步骤a之前进一步包括:
接收端从信息索引服务器获取发布端事先保存的好友用户端ID号,接收端再根据好友用户端ID号确定一个伪发布端,再向伪发布端发送下载请求消息。
较佳地,步骤X5所述重定向端向接收端返回无下载文件响应消息和接收端向伪发布端发送文件下载请求消息之间进一步包括:
接收端将未下载文件的文件编号上报给伪发布端,伪发布端根据未下载文件编号更新种子节点表;
步骤c所述接收端更新接收状态表和返回步骤b之间进一步包括:
接收端将已下载文件编号上报给伪发布端,伪发布端根据已下载文件编号更新种子节点表。
较佳地,所述判断是否需要重定向的方法为:
根据自身下载任务队列表中的下载任务个数判断自身是否忙,如果忙,再根据种子节点表判断是否存在重定向用户端,如果存在重定向端,则判断为需要重定向;否则,判断为无需重定向。
综上所述,本发明提出的一种数据下载方法,其优点在于:
(1)当接收端向本次下载端请求下载欲下载文件编号对应的文件时,本次下载端可以直接将该文件发送给接收端,也可以通过重定向端将文件发送给接收端,这可以减少本次下载端的负荷,充分利用已经下载了文件的重定向端,提高下载速度。
(2)发布端将包括好友用户端ID号的信息发布到信息索引服务器上,当发布端离线时,接收端可以从信息索引服务器上获取好友用户端ID号,并将已经下载了文件的好友用户端作为伪发布端进行下载,从而可以保证发布端离线时,接收端仍然可以下载发布端共享的小文件集合。
(3)由于将小文件集合中的所有文件独立地进行编号,当接收端接收到某一个文件时,就可以应用该文件,不必等到下载完整个小文件集合才开始应用,这可以满足用户及时体验的需求。
附图说明
图1是典型的基于P2P技术的网络结构示意图;
图2是本发明方案流程图;
图3是实施例一的网络结构示意图;
图4是应用本发明方案的实施例一的流程图;
图5是实施例二的网络结构示意图;
图6是应用本发明方案的实施例二的流程图。
具体实施方式
为使本发明的目的、技术方案和优点更加清楚,下面将结合附图及具体实施例对本发明作进一步地详细描述。
本发明的基本思想是:将所有小数据文件进行编号,并利用重定向技术将文件下载给接收端。
图2是本发明的流程图。本发明中,最初提供小文件集合的用户端为发布端,与发布端有好友连接关系的为好友用户端,好友用户端可以下载由发布端共享的小文件集合。当某一个好友用户端需要下载文件时,该好友用户端为接收端,而提供文件的则为原下载端。当发布端在线时,这里所述的原下载端为发布端;当发布端离线时,所述的原下载端为伪发布端。也就是说,当发布端离线时,已经下载了小文件集合的好友用户端就可以充当发布端,向请求下载的接收端提供所述的小文件集合。
如图2所示,本发明中接收端实现下载小文件集合的方法包括以下步骤:
步骤201:原下载端将种子节点表发送给接收端。
本发明中,发布端在将小文件集合共享给好友用户端之前,首先需要将小文件集合中的所有文件进行编号,并创建种子节点表,即记录文件编号和拥有该文件的好友用户端ID号。本步骤所述的原下载端是已经拥有种子节点表的原下载端。
步骤202:接收端创建用于记录文件接收状态的接收状态表。
步骤203:接收端根据接收状态表确定欲下载文件编号,并根据欲下载文件编号和种子节点表发起下载流程,获得所述欲下载文件编号对应的文件。
步骤204~步骤205:接收端更新接收状态表,并判断是否下载完小文件集合中的所有文件,如果是,则退出本流程;否则,返回步骤203。
本发明中,小文件集合中有多个文件,不一定全部由原下载端向接收端进行下载,也可以由已经拥有该文件的好友用户端向接收端下载。也就是说,当接收端开始下载某文件时,可以先从多个拥有该文件的好友用户端中确定一个下载当前文件的用户端,即本次下载端,再由本次下载端向接收端下载文件。当然,实际应用中,也可以不从好友用户端中确定本次下载端,而直接将某个用户端作为本次下载端。比如,发布端离线时,可以直接将伪发布端作为本次下载端。
本发明中所述的下载流程是采用重定向技术的下载流程,即:当接收端向本次下载端请求下载欲下载文件编号对应的文件时,本次下载端可以根据自身下载情况和种子节点表记录情况进行重定向,接收端可以在重定向之后获得文件。采用重定向技术的下载流程很多,本发明的下载流程可以表示为:
X1、接收端向本次下载端发送携带有欲下载文件编号的文件下载请求消息;
X2、本次下载端根据自身下载任务队列表和种子节点表判断是否需要重定向,如果需要,则根据自身种子节点表确定重定向端,并执行步骤X3;否则,执行步骤X4;
本发明中,为了控制用户端的下载负荷,承担下载任务的用户端将创建一个下载任务队列表,用来记录下载的情况。当作为本次下载端的某用户端接收到下载请求时,可以根据下载任务队列表中下载任务个数和种子节点表来确定是否需要重定向,如果需要重定向,则本次下载端不承担此次下载任务,而由重定向端承担。这里所述的重定向端就是也拥有所述欲下载文件编号对应的文件的好友用户端。
X3、接收端向重定向端发送携带有欲下载文件编号的文件下载请求消息,重定向端判断自身是否存在所述欲下载文件编号对应的文件,如果存在,则将所述欲下载文件编号对应的文件排列在自身下载队列中,发送给接收端,再退出本流程;否则,执行步骤X5;
本发明中,如果重定向端有所述欲下载文件编号的文件,则需承担此次下载任务;如果没有所述欲下载文件编号的文件,则向接收端返回无下载文件响应消息。也就是说,重定向端不会再进行第二次重定向。
实际应用中,也可以规定重定向端再进行有限次重定向。当然,当重定向端再次进行重定向时,需要避免导致循环重定向的情况发生。比如:当重定向端根据自身下载任务队列表和种子节点表判断是否需要再次重定向,如果需要,则根据自身种子节点表确定第二次重定向端,再判断第二次重定向端是否为上次重定向给自身的用户端,如果是,则重新确定一个第二次重定向端,直至不与上次重定向给自身的用户端相同为止。
X4、本次下载端将所述欲下载文件编号对应的文件排列在自身下载队列中,发送给接收端,再退出本流程;
X5、重定向端向接收端返回无下载文件响应消息,接收端再向原下载端发送携带有欲下载文件编号的文件下载请求消息,并接收所述欲下载文件编号对应的文件,再退出本流程。
为了更好地说明本发明方案,下面用两个较佳实施例来说明实现小文件集合下载的方法。
实施例一
图3显示了本实施例的网络结构示意图。图3与图1的结构和功能完全相同,只是为了叙述方便,将提供小文件集合的用户端称为发布端,将发布端好友用户群中的用户端称为好友用户端,并且将其中一个将要下载文件的好友用户端称为接收端。
本实施例中,发布端处于在线状态,并且有100个好友用户端;小文件集合中有1000个文件。发布端先将1000个文件进行编号,并创建种子节点表,包括文件编号和拥有该文件的好友用户端ID号列表。发布端创建种子节点表之后,种子节点表中拥有该文件的好友用户端ID号列表为空。当某好友用户端下载完某一个文件之后,发布端就可以将该好友用户端记录在种子节点表中。假设本实施例中接收端向发布端发送下载请求消息之前,发布端种子节点表如表一所示。
表一
图4是本实施例的流程图。如图4所示,本实施例实现数据下载的方法包括以下步骤:
步骤401:发布端向接收端发送共享通知消息,接收端再向发布端发送下载请求消息。
步骤402:发布端将种子节点表发送给接收端,接收端创建用于记录文件接收状态的接收状态表。
接收端创建接收状态表,并设置所有文件编号对应的接收状态初始值为“未接收”。本实施例中的接收状态表如表二所示。
文件编号 | 接收状态 |
1 | 未接收 |
2 | 未接收 |
未接收 | |
1000 | 未接收 |
表二
步骤403:接收端根据接收状态表确定欲下载文件编号。
实际应用中,接收端可以同时承担一个或一个以上的下载任务,所以当接收端第一次请求下载时,可以同时确定一个或一个以上欲下载文件编号。比如:将1~5的文件编号确定为欲下载文件编号。此后,接收端可以根据自身正在进行下载个数来确定欲下载文件编号。比如:接收端成功接收到文件编号为1的文件,而文件编号为2~5的文件正在下载过程中,就将文件编号为6的文件确定为欲下载文件编号,并依次类推。
步骤404:接收端将欲下载文件编号对应的好友用户端ID号发送给信息索引服务器进行在线过滤,获得在线的好友用户端ID号。
实际应用中,某些好友用户端在下载完小文件集合之后可能离线,并在信息索引服务器上进行登记。信息索引服务器接收到发送的好友用户端ID号之后,就可以根据登记情况判断哪些好友用户端处于在线状态,哪些好友用户端处于离线状态,并且将处于在线状态的好友用户端ID号返回给接收端,即进行在线过滤。
步骤405:接收端将数据传输速度最快的在线好友用户端作为本次下载端。
实际应用中,当接收端刚开始下载小文件集合中的文件时,还没有与任何一个好友用户端进行交互,即好友用户端向接收端传输数据的速度都为0,可以随机选择一个在线好友用户端作为本次下载端。但是,当接收端成功下载完一个文件之后,准备下载其它未下载文件时,由于已经与在线好友用户端进行了交互,可以检测传输数据的速度,并将传输数据速度最快的在线好友用户端作为本次下载端。
步骤406:接收端向本次下载端发送携带有欲下载文件编号的文件下载请求消息。
步骤407~步骤408:本次下载端根据自身下载任务队列表和种子节点表判断是否需要重定向,如果需要,则根据自身种子节点表确定重定向端,并将重定向端的ID号发送给接收端,再执行步骤409;否则,执行步骤411。
本步骤中,本次下载端判断是否需要重定向的方法为:本次下载端根据自身下载任务队列表中的下载任务个数判断自身是否忙,如果忙,再根据种子节点表判断是否存在重定向用户端,如果存在重定向端,则判断为需要重定向;否则,判断为无需重定向。
实际应用中,为了避免承担过大的下载负荷,影响下载速度,一般需要规定本次下载端承担下载任务个数的最大值。如果本次下载端下载任务队列表中的下载任务个数已经达到规定的最大值,则本次下载端判断自身为忙状态,不适合继续承载更多的下载任务,需要将此次下载任务重定向给其它的好友用户端。本次下载端再根据种子节点表确定是否存在重定向端,即查询种子节点表欲下载文件编号对应的好友用户端列表中是否还存在其它的拥有该文件的好友用户端ID号,如果存在,则确定一个好友用户端作为重定向端,并通知接收端。
步骤409:接收端根据重定向端ID号向重定向端发送携带有欲下载文件编号的文件下载请求消息。
步骤410~步骤411:重定向端判断自身是否存在所述欲下载文件编号对应的文件,如果存在,则将所述欲下载文件编号对应的文件排列在自身下载队列中,发送给接收端,再执行步骤415;否则,执行步骤413。
步骤412:本次下载端将所述欲下载文件编号对应的文件排列在自身下载队列中,发送给接收端,再执行步骤415。
步骤413:重定向端向接收端返回无下载文件响应消息,并将无下载文件的文件编号上报给发布端,发布端根据未下载文件编号更新种子节点表。
由于重定向端没有欲下载文件编号对应的文件,本步骤所述未下载文件编号就是所述欲下载文件编号。当发布端接收到重定向端上报的未下载文件编号时,将更新种子节点表,即:将未下载文件编号对应的重定向端ID号从拥有该文件的好友用户端ID号列表中删除。
步骤414:接收端再向发布端发送携带有欲下载文件编号的文件下载请求消息,并接收所述欲下载文件编号对应的文件。
实际应用中,由于发布端存在小文件集合中所有的文件,可以直接将欲下载文件编号对应的文件下载给接收端。为了避免发布端承载过大的下载任务,发布端也可以再次将此次下载任务重定向给其它的好友用户端,即:
当发布端接收到文件下载请求消息时,发布端根据自身下载任务队列表和种子节点表判断是否需要重定向,如果需要,则根据自身种子节点表确定重定向端,接收端向重定向用户端发送携带有欲下载文件编号的文件下载请求消息,重定向用户端判断自身是否存在所述欲下载文件编号对应的文件,如果存在,则将所述欲下载文件编号对应的文件排列在自身下载队列中;否则,发布端将所述欲下载文件编号对应的文件排列在自身下载队列中。
这里所述发布端判断是否需要重定向的方法与步骤407~步骤408中所述的重定向方法相似,此处不再赘述。
步骤415:接收端更新接收状态表,将自身接收状态表中欲下载文件编号对应的接收状态更改为已下载。
步骤416:接收端将已下载文件的文件编号上报给发布端,发布端根据已下载文件编号更新种子节点表。
本步骤所述的已下载文件的文件编号其实就是所述欲下载文件编号,由于该欲下载文件编号已经成功下载,并在接收状态表更改为已下载,所以,接收端上报给发布端的为已下载文件的文件编号。
当发布端接收到上报的已下载文件编号时,将更新种子节点表,即:将接收端的ID号添加到已下载文件编号对应的拥有该文件的好友用户端ID号列表中。
步骤417:接收端判断是否下载小文件集合中所有的文件,如果是,则退出本流程;否则,返回步骤403。
本实施例只描述了一个好友用户端作为接收端时下载小文件集合的方法。实际应用中,可能有多个好友用户端同时下载小文件集合,则当某一个接收端成功接收到一个或一个以上的文件之后,就可以作为本次下载端向其它接收端提供已经接收到的文件,从而可以大大提高下载速度。
实施例二
图5是本实施例的网络结构示意图。图5与图1的结构和功能也完全相同,只是为了叙述方便,将处于在线状态且存在小文件集合的用户端称为伪发布端,将处于离线状态的原发布端的好友用户群中的用户端称为好友用户端,并且将其中一个将要下载文件的好友用户端称为接收端。当然,这里所述的伪发布端也是原发布端的好友用户端。
本实施例中,当发布端离线之前,已经在信息索引服务器上发布了信息,所述发布信息包括好友用户端的ID号。本实施例中,伪发布端不但有小文件集合中的所有文件,还有记录文件分布情况的种子节点表。
图6是本实施例的流程图。如图6所示,本实施例实现数据下载的方法包括以下步骤:
步骤601:接收端从信息索引服务器获取发布端事先保存的好友用户端ID号,再根据好友用户端ID号确定一个伪发布端,并向伪发布端发送下载请求消息。
实际应用中,由于发布端在离线之前已经将包括好友用户端ID号的信息发布到信息索引服务器,不管发布端离线之前接收端是否在线,当发布端离线之后,接收端都可以在信息索引服务器中查询发布端发布的信息,并获得好友用户端ID号。然后,接收端再从所述的好友用户端的ID号中确定一个伪发布端。
确定伪发布端的方法可以为:接收端先将获得的所有好友用户端的ID发送给信息索引服务器进行在线过滤,获得在线的好友用户端;接收端再依次向在线的好友用户端发送种子查询请求消息,直到某个在线好友用户端存在种子节点表,即已经下载过小数据文件,那么,接收端就将该好友用户端作为伪发布端。这里所述的在线过滤的方法与实施例一中的在线过滤方法相同,此处不再赘述。
步骤602:伪发布端将种子节点表发送给接收端,接收端创建用于记录文件接收状态的接收状态表。
步骤603:接收端根据接收状态表确定欲下载文件编号,并向伪发布端发送携带有欲下载文件编号的文件下载请求消息。
步骤604~步骤605:伪发布端根据自身下载任务队列表和种子节点表判断是否需要重定向,如果需要,则根据自身种子节点表确定重定向端,并将重定向端的ID号发送给接收端,再执行步骤606;否则,执行步骤609。
这里所述的步骤604~步骤605与实施例中的步骤407~步骤408相似,其区别仅仅在于本实施例直接由伪发布端判断,此处不再赘述。
步骤606:接收端根据重定向端ID号向重定向端发送携带有欲下载文件编号的文件下载请求消息。
步骤607~步骤608:重定向端判断自身是否存在所述欲下载文件编号对应的文件,如果存在,则将所述欲下载文件编号对应的文件排列在自身下载队列中,发送给接收端,再执行步骤612;否则,执行步骤610。
步骤609:伪发布端将所述欲下载文件编号对应的文件排列在自身下载队列中,发送给接收端,再执行步骤612。
步骤610:重定向端向接收端返回无下载文件响应消息,接收端再将无下载文件的文件编号上报给伪发布端,伪发布端根据未下载文件编号更新种子节点表。
步骤611:接收端再向伪发布端发送携带有欲下载文件编号的文件下载请求消息,并接收所述欲下载文件编号对应的文件。
步骤612:接收端更新接收状态表,将自身接收状态表中欲下载文件编号对应的接收状态更改为已下载。
步骤613:接收端将已下载文件的文件编号上报给伪发布端,伪发布端根据已下载文件编号更新种子节点表。
步骤614:接收端判断是否下载完小文件集合中所有的文件,如果是,则退出本流程;否则,返回步骤603。
实际应用中,如果伪发布端自身没有下载完小文件集合中的全部文件,则接收端可以重新从在线好友用户端中确定新的伪发布端,并采用本实施例的方法进行下载,直到小文件集合中的文件全部下载。
应用本实施例方案,接收端可以在发布端离线的情况下,可以从信息索引服务器中获得好友用户端ID,并将已经下载有小文件集合的在线好友用户端作为伪发布端,通过伪发布端下载文件,从而达到在发布端离线情况下,接收端仍然可以获得发布端提供的小文件集合的目的。
综上所述,以上仅为本发明的较佳实施例而已,并非用于限定本发明的保护范围。凡在本发明的精神和原则之内,所作的任何修改、等同替换、改进等,均应包含在本发明的保护范围之内。
Claims (9)
1.一种数据下载方法,其特征在于,设置种子节点表,用于记录文件编号和对应的拥有该文件的好友用户端ID号,该方法包括以下步骤:
a、原下载端将种子节点表发送给接收端,接收端创建用于记录文件接收状态的接收状态表;
b、接收端根据接收状态表确定欲下载文件编号,并根据欲下载文件编号和种子节点表发起下载流程,获得所述欲下载文件编号对应的文件;
c、接收端更新接收状态表,并返回步骤b,直至获得小文件集合的所有文件;
步骤b所述下载流程为:
X1、接收端向本次下载端发送携带有欲下载文件编号的文件下载请求消息;
X2、本次下载端根据自身的下载任务队列表和种子节点表判断是否需要重定向,如果需要,则根据自身种子节点表确定重定向端,并执行步骤X3;否则,执行步骤X4;
X3、接收端向重定向端发送携带有欲下载文件编号的文件下载请求消息,重定向端判断自身是否存在所述欲下载文件编号对应的文件,如果存在,则将所述欲下载文件编号对应的文件排列在自身下载队列中,发送给接收端,再执行步骤c;否则,执行步骤X5;
X4、本次下载端将所述欲下载文件编号对应的文件排列在自身下载队列中,发送给接收端,再执行步骤c;
X5、重定向端向接收端返回无下载文件响应消息,接收端再向原下载端发送携带有欲下载文件编号的文件下载请求消息,并接收所述欲下载文件编号对应的文件,再执行步骤c。
2.根据权利要求1所述的方法,其特征在于,当最初提供小文件集合的发布端在线时,
步骤a和步骤b下载流程中所述原下载端为发布端;
确定步骤b下载流程中所述本次下载端的方法为:接收端将种子节点表中欲下载文件编号对应的好友用户端ID号发送给信息索引服务器进行在线过滤,获得在线的好友用户端ID号,接收端再从所述在线好友用户端中确定一个本次下载用户端。
3.根据权利要求2所述的方法,其特征在于,所述接收端从在线好友用户端中确定一个本次下载端的方法为:
接收端从在线好友用户端中随机确定一个本次下载用户端;或者,
接收端将数据传输速度最快的在线好友用户端作为本次下载端。
4.根据权利要求2所述的方法,其特征在于,所述步骤a之前进一步包括:发布端向接收端发送共享通知消息,接收端再向发布端发送下载请求消息。
5.根据权利要求2所述的方法,其特征在于,步骤X5所述接收端向发布端发送文件下载请求消息和接收文件之间进一步包括:
发布端根据自身下载任务队列表和种子节点表判断是否需要重定向,如果需要,则根据自身种子节点表确定重定向端,接收端向重定向用户端发送携带有欲下载文件编号的文件下载请求消息,重定向用户端判断自身是否存在所述欲下载文件编号对应的文件,如果存在,则将所述欲下载文件编号对应的文件排列在自身下载队列中;否则,发布端将所述欲下载文件编号对应的文件排列在自身下载队列中。
6.根据权利要求2所述的方法,其特征在于,步骤c所述接收端更新接收状态表和返回步骤b之间进一步包括:
接收端将已下载文件编号上报给发布端,发布端根据已下载文件编号更新种子节点表;
步骤X5所述重定向端向接收端返回无下载文件响应消息和接收端向发布端发送文件下载请求消息之间进一步包括:
重定向端将未下载文件的文件编号上报给发布端,发布端根据未下载文件编号更新种子节点表。
7.根据权利要求1所述的方法,其特征在于,当最初提供小文件集合的发布端离线时,
步骤a所述原下载端、步骤b所述下载流程中的本次下载端和原下载端都为伪发布端;
所述步骤a之前进一步包括:
接收端从信息索引服务器获取发布端事先保存的好友用户端ID号,接收端再根据好友用户端ID号确定一个伪发布端,再向伪发布端发送下载请求消息。
8.根据权利要求7所述的方法,其特征在于,步骤X5所述重定向端向接收端返回无下载文件响应消息和接收端向伪发布端发送文件下载请求消息之间进一步包括:
接收端将未下载文件的文件编号上报给伪发布端,伪发布端根据未下载文件编号更新种子节点表;
步骤c所述接收端更新接收状态表和返回步骤b之间进一步包括:
接收端将已下载文件编号上报给伪发布端,伪发布端根据已下载文件编号更新种子节点表。
9.根据权利要求1至8任一项所述的方法,其特征在于,所述判断是否需要重定向的方法为:
根据自身下载任务队列表中的下载任务个数判断自身是否忙,如果忙,再根据种子节点表判断是否存在重定向用户端,如果存在重定向端,则判断为需要重定向;否则,判断为无需重定向。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN2006100828421A CN101075879B (zh) | 2006-06-13 | 2006-06-13 | 一种数据下载方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN2006100828421A CN101075879B (zh) | 2006-06-13 | 2006-06-13 | 一种数据下载方法 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN101075879A CN101075879A (zh) | 2007-11-21 |
CN101075879B true CN101075879B (zh) | 2012-04-25 |
Family
ID=38976713
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN2006100828421A Active CN101075879B (zh) | 2006-06-13 | 2006-06-13 | 一种数据下载方法 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN101075879B (zh) |
Families Citing this family (12)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101170371B (zh) * | 2007-11-30 | 2010-12-29 | 中兴通讯股份有限公司 | 一种p2p点播中客户端数据请求优化方法及*** |
CN101459697B (zh) * | 2009-01-07 | 2012-01-04 | 清华大学 | 一种共享文件的访问方法和装置 |
CN102135872B (zh) * | 2010-01-22 | 2016-06-15 | 腾讯科技(深圳)有限公司 | 一种在登录区域配置图像的方法及装置 |
CN101931633B (zh) * | 2010-09-29 | 2013-11-06 | 山东大学 | 一种应用于智能手机终端的可增量同步方法 |
CN102469062B (zh) * | 2010-10-29 | 2014-05-07 | 北大方正集团有限公司 | 一种数据分发方法及装置 |
CN102857403B (zh) * | 2011-06-30 | 2015-04-22 | 北京神州泰岳软件股份有限公司 | 即时通信客户端数据共享方法和*** |
CN103970794B (zh) * | 2013-02-01 | 2017-11-28 | 联想(北京)有限公司 | 数据访问方法和数据访问装置 |
CN103678535A (zh) * | 2013-12-02 | 2014-03-26 | 北京奇虎科技有限公司 | 浏览器进行下载的方法和浏览器 |
CN105119816A (zh) * | 2015-09-16 | 2015-12-02 | 北京梅泰诺通信技术股份有限公司 | 消息发送状态的处理方法及装置 |
CN105791436A (zh) * | 2016-04-28 | 2016-07-20 | 杭州亿方云网络科技有限公司 | 一种文件同步***及其同步方法 |
CN113347218A (zh) * | 2020-02-18 | 2021-09-03 | 北京沃东天骏信息技术有限公司 | 模块下载方法和装置 |
CN111371878B (zh) * | 2020-02-28 | 2023-04-14 | 北京和利时***集成有限公司 | 一种信息发布方法、iscs、pis及装置 |
Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN1710857A (zh) * | 2004-06-18 | 2005-12-21 | 千橡寰宇科技发展(北京)有限公司 | 一种实现文件加速下载的***及方法 |
CN1731396A (zh) * | 2005-08-23 | 2006-02-08 | 萧学文 | 实现移动终端搜索网络资源的***及方法 |
-
2006
- 2006-06-13 CN CN2006100828421A patent/CN101075879B/zh active Active
Patent Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN1710857A (zh) * | 2004-06-18 | 2005-12-21 | 千橡寰宇科技发展(北京)有限公司 | 一种实现文件加速下载的***及方法 |
CN1731396A (zh) * | 2005-08-23 | 2006-02-08 | 萧学文 | 实现移动终端搜索网络资源的***及方法 |
Also Published As
Publication number | Publication date |
---|---|
CN101075879A (zh) | 2007-11-21 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN101075879B (zh) | 一种数据下载方法 | |
US10320899B2 (en) | Peer-to-peer communication of non-common data | |
JP5327852B2 (ja) | スケーラブルなピア・グループを使用して通信を最適化すること | |
CN100407627C (zh) | 一种实现端到端文件共享的***及方法 | |
JP5232876B2 (ja) | フィードをベースにした移動端末へのコンテンツの自動送信技術 | |
US20090265475A1 (en) | Content delivery method, content delivery server, communication terminal apparatus, and content delivery system | |
CN111163130B (zh) | 一种网络服务***及其数据传输方法 | |
KR20110050424A (ko) | 발명의 피어-투-피어 네트워크필드를 통해서 공유하는 인스톨된 게임 소프트웨어 | |
CN101821991B (zh) | 用于管理网络中的用户优选项简档的方法和*** | |
US20100250674A1 (en) | Content delivery apparatus, content delivery method, and content delivery program | |
CN110474917B (zh) | 消息中间件上、下线方法、装置、设备及可读存储介质 | |
CN108173774A (zh) | 一种客户端的升级方法及*** | |
JP2010538590A (ja) | 目標データ配信レートによる協同ファイル配布のための方法および装置 | |
CN101326493A (zh) | 用于多处理器服务器中的负载分配的方法和装置 | |
CN108377247A (zh) | 一种消息推送方法和装置 | |
JP5536900B2 (ja) | ピアツーピア・トラフィックの局所化 | |
CN109873855A (zh) | 一种基于区块链网络的资源获取方法和*** | |
US8755397B2 (en) | Asynchronous communication in an unstable network | |
CN105049463A (zh) | 分散数据库、数据共享方法、用于分散数据库的装置 | |
CN105847396A (zh) | 数据传输的方法及设备 | |
CN109417566B (zh) | 基于约束的受控制的种子传播 | |
JP2004064284A (ja) | P2pネットワークのトラヒック制御方法及び装置並びにプログラム及び記録媒体 | |
CN103731511A (zh) | 一种p2p***中数据获取方法和装置 | |
KR102020112B1 (ko) | 데이터 분산 서비스 기반 iec61850 요청-응답 통신 방법 및 플랫폼 | |
JP2009110165A (ja) | パブリッシュ/サブスクライブ通信における負荷分散処理方法及びその実施装置と処理プログラム |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
C14 | Grant of patent or utility model | ||
GR01 | Patent grant | ||
C41 | Transfer of patent application or patent right or utility model | ||
TR01 | Transfer of patent right |
Effective date of registration: 20151230 Address after: The South Road in Guangdong province Shenzhen city Fiyta building 518057 floor 5-10 Nanshan District high tech Zone Patentee after: Shenzhen Tencent Computer System Co., Ltd. Address before: Shenzhen Futian District City, Guangdong province 518044 Zhenxing Road, SEG Science Park 2 East Room 403 Patentee before: Tencent Technology (Shenzhen) Co., Ltd. |