一种数据下载方法

暂无

一种数据下载方法\n技术领域\n[0001] 本发明涉及网络数据传输技术，特别是涉及一种数据下载方法。\n背景技术\n[0002] 目前，提出了一种对等网络(P2P)技术，可以达到资源共享和即时通讯的目的。图\n1是一个典型的基于P2P技术的网络结构示意图。如图1所示，该网络包括信息索引服务器和N个用户端。其中，信息索引服务器用于记录用户端的基本信息，如：在线或离线信息、ID号等。每一个用户端都有一个好友用户群，该用户端与好友用户群中的每一个用户端之间都建立了好友连接关系，可以进行交互，比如：聊天、发布通知、传输文件或小文件集合等。\n[0003] 其中，小文件集合是一种由多个数据量比较小的文件组成的集合。比如：由大量图像文件组成的数字相册，或由大量MP3文件组成的CD。一个图像文件或一个MP3文件一般比较小，一般为几K字节～几M字节，但数字相册或CD的数据总量却比较大，可以为几十个G字节，甚至上百个G字节。\n[0004] 当某用户端要将小文件集合共享给好友用户群的用户端时，一般是直接将所述小文件集合依次发送给好友用户群的所有用户端。这里所述的提供小文件集合的用户端也称为下载端，好友用户群的用户端则称为好友用户端。如果好友用户端比较多，小文件集合总的数据量比较大时，下载端的下载负荷就比较大，而且需要花费较长的时间才能将小文件集合下载给好友用户端。\n[0005] 由此可见，在现有技术中，还没有一种数据下载方法，不但可以将小文件集合快速地下载给好友用户端，而且可以减少下载端的下载负荷。发明内容\n[0006] 有鉴于此，本发明的主要目的在于提供一种数据下载方法，不但可以将小文件集合快速地下载给好友用户端，而且可以减少下载端的下载负荷。为了达到上述目的，本发明提出的技术方案为：\n[0007] 一种数据下载方法，设置种子节点表，用于记录文件编号和对应的拥有该文件的好友用户端ID号，该方法包括以下步骤：\n[0008] a、原下载端将种子节点表发送给接收端，接收端创建用于记录文件接收状态的接收状态表；\n[0009] b、接收端根据接收状态表确定欲下载文件编号，并根据欲下载文件编号和种子节点表发起下载流程，获得所述欲下载文件编号对应的文件；\n[0010] c、接收端更新接收状态表，并返回步骤b，直至获得小文件集合的所有文件。\n[0011] 较佳地，步骤b所述下载流程为：\n[0012] X1、接收端向本次下载端发送携带有欲下载文件编号的文件下载请求消息；\n[0013] X2、本次下载端根据自身的下载任务队列表和种子节点表判断是否需要重定向，如果需要，则根据自身种子节点表确定重定向端，并执行步骤X3；否则，执行步骤X4；\n[0014] X3、接收端向重定向端发送携带有欲下载文件编号的文件下载请求消息，重定向端判断自身是否存在所述欲下载文件编号对应的文件，如果存在，则将所述欲下载文件编号对应的文件排列在自身下载队列中，发送给接收端，再执行步骤c；否则，执行步骤X5；\n[0015] X4、本次下载端将所述欲下载文件编号对应的文件排列在自身下载队列中，发送给接收端，再执行步骤c；\n[0016] X5、重定向端向接收端返回无下载文件响应消息，接收端再向原下载端发送携带有欲下载文件编号的文件下载请求消息，并接收所述欲下载文件编号对应的文件，再执行步骤c。\n[0017] 较佳地，当最初提供小文件集合的发布端在线时，\n[0018] 步骤a和步骤b下载流程中所述原下载端为发布端；\n[0019] 确定步骤b下载流程中所述本次下载端的方法为：接收端将种子节点表中欲下载文件编号对应的好友用户端ID号发送给信息索引服务器进行在线过滤，获得在线的好友用户端ID号，接收端再从所述在线好友用户端中确定一个本次下载用户端。\n[0020] 较佳地，所述接收端从在线好友用户端中确定一个本次下载端的方法为：\n[0021] 接收端从在线好友用户端中随机确定一个本次下载用户端；或者，[0022] 接收端将数据传输速度最快的在线好友用户端作为本次下载端。\n[0023] 较佳地，所述步骤a之前进一步包括：发布端向接收端发送共享通知消息，接收端再向发布端发送下载请求消息。\n[0024] 较佳地，步骤X5所述接收端向发布端发送文件下载请求消息和接收文件之间进一步包括：\n[0025] 发布端根据自身下载任务队列表和种子节点表判断是否需要重定向，如果需要，则根据自身种子节点表确定重定向端，接收端向重定向用户端发送携带有欲下载文件编号的文件下载请求消息，重定向用户端判断自身是否存在所述欲下载文件编号对应的文件，如果存在，则将所述欲下载文件编号对应的文件排列在自身下载队列中；否则，发布端将所述欲下载文件编号对应的文件排列在自身下载队列中。\n[0026] 较佳地，步骤c所述接收端更新接收状态表和返回步骤b之间进一步包括：\n[0027] 接收端将已下载文件编号上报给发布端，发布端根据已下载文件编号更新种子节点表；\n[0028] 步骤X5所述重定向端向接收端返回无下载文件响应消息和接收端向发布端发送文件下载请求消息之间进一步包括：\n[0029] 重定向端将未下载文件的文件编号上报给发布端，发布端根据未下载文件编号更新种子节点表。\n[0030] 较佳地，当最初提供小文件集合的发布端离线时，\n[0031] 步骤a所述原下载端、步骤b所述下载流程中的本次下载端和原下载端都为伪发布端；\n[0032] 所述步骤a之前进一步包括：\n[0033] 接收端从信息索引服务器获取发布端事先保存的好友用户端ID号，接收端再根据好友用户端ID号确定一个伪发布端，再向伪发布端发送下载请求消息。\n[0034] 较佳地，步骤X5所述重定向端向接收端返回无下载文件响应消息和接收端向伪发布端发送文件下载请求消息之间进一步包括：\n[0035] 接收端将未下载文件的文件编号上报给伪发布端，伪发布端根据未下载文件编号更新种子节点表；\n[0036] 步骤c所述接收端更新接收状态表和返回步骤b之间进一步包括：\n[0037] 接收端将已下载文件编号上报给伪发布端，伪发布端根据已下载文件编号更新种子节点表。\n[0038] 较佳地，所述判断是否需要重定向的方法为：\n[0039] 根据自身下载任务队列表中的下载任务个数判断自身是否忙，如果忙，再根据种子节点表判断是否存在重定向用户端，如果存在重定向端，则判断为需要重定向；否则，判断为无需重定向。\n[0040] 综上所述，本发明提出的一种数据下载方法，其优点在于：\n[0041] (1)当接收端向本次下载端请求下载欲下载文件编号对应的文件时，本次下载端可以直接将该文件发送给接收端，也可以通过重定向端将文件发送给接收端，这可以减少本次下载端的负荷，充分利用已经下载了文件的重定向端，提高下载速度。\n[0042] (2)发布端将包括好友用户端ID号的信息发布到信息索引服务器上，当发布端离线时，接收端可以从信息索引服务器上获取好友用户端ID号，并将已经下载了文件的好友用户端作为伪发布端进行下载，从而可以保证发布端离线时，接收端仍然可以下载发布端共享的小文件集合。\n[0043] (3)由于将小文件集合中的所有文件独立地进行编号，当接收端接收到某一个文件时，就可以应用该文件，不必等到下载完整个小文件集合才开始应用，这可以满足用户及时体验的需求。\n附图说明\n[0044] 图1是典型的基于P2P技术的网络结构示意图；\n[0045] 图2是本发明方案流程图；\n[0046] 图3是实施例一的网络结构示意图；\n[0047] 图4是应用本发明方案的实施例一的流程图；\n[0048] 图5是实施例二的网络结构示意图；\n[0049] 图6是应用本发明方案的实施例二的流程图。\n具体实施方式\n[0050] 为使本发明的目的、技术方案和优点更加清楚，下面将结合附图及具体实施例对本发明作进一步地详细描述。\n[0051] 本发明的基本思想是：将所有小数据文件进行编号，并利用重定向技术将文件下载给接收端。\n[0052] 图2是本发明的流程图。本发明中，最初提供小文件集合的用户端为发布端，与发布端有好友连接关系的为好友用户端，好友用户端可以下载由发布端共享的小文件集合。\n当某一个好友用户端需要下载文件时，该好友用户端为接收端，而提供文件的则为原下载端。当发布端在线时，这里所述的原下载端为发布端；当发布端离线时，所述的原下载端为伪发布端。也就是说，当发布端离线时，已经下载了小文件集合的好友用户端就可以充当发布端，向请求下载的接收端提供所述的小文件集合。\n[0053] 如图2所示，本发明中接收端实现下载小文件集合的方法包括以下步骤：\n[0054] 步骤201：原下载端将种子节点表发送给接收端。\n[0055] 本发明中，发布端在将小文件集合共享给好友用户端之前，首先需要将小文件集合中的所有文件进行编号，并创建种子节点表，即记录文件编号和拥有该文件的好友用户端ID号。本步骤所述的原下载端是已经拥有种子节点表的原下载端。\n[0056] 步骤202：接收端创建用于记录文件接收状态的接收状态表。\n[0057] 步骤203：接收端根据接收状态表确定欲下载文件编号，并根据欲下载文件编号和种子节点表发起下载流程，获得所述欲下载文件编号对应的文件。\n[0058] 步骤204～步骤205：接收端更新接收状态表，并判断是否下载完小文件集合中的所有文件，如果是，则退出本流程；否则，返回步骤203。\n[0059] 本发明中，小文件集合中有多个文件，不一定全部由原下载端向接收端进行下载，也可以由已经拥有该文件的好友用户端向接收端下载。也就是说，当接收端开始下载某文件时，可以先从多个拥有该文件的好友用户端中确定一个下载当前文件的用户端，即本次下载端，再由本次下载端向接收端下载文件。当然，实际应用中，也可以不从好友用户端中确定本次下载端，而直接将某个用户端作为本次下载端。比如，发布端离线时，可以直接将伪发布端作为本次下载端。\n[0060] 本发明中所述的下载流程是采用重定向技术的下载流程，即：当接收端向本次下载端请求下载欲下载文件编号对应的文件时，本次下载端可以根据自身下载情况和种子节点表记录情况进行重定向，接收端可以在重定向之后获得文件。采用重定向技术的下载流程很多，本发明的下载流程可以表示为：\n[0061] X1、接收端向本次下载端发送携带有欲下载文件编号的文件下载请求消息；\n[0062] X2、本次下载端根据自身下载任务队列表和种子节点表判断是否需要重定向，如果需要，则根据自身种子节点表确定重定向端，并执行步骤X3；否则，执行步骤X4；\n[0063] 本发明中，为了控制用户端的下载负荷，承担下载任务的用户端将创建一个下载任务队列表，用来记录下载的情况。当作为本次下载端的某用户端接收到下载请求时，可以根据下载任务队列表中下载任务个数和种子节点表来确定是否需要重定向，如果需要重定向，则本次下载端不承担此次下载任务，而由重定向端承担。这里所述的重定向端就是也拥有所述欲下载文件编号对应的文件的好友用户端。\n[0064] X3、接收端向重定向端发送携带有欲下载文件编号的文件下载请求消息，重定向端判断自身是否存在所述欲下载文件编号对应的文件，如果存在，则将所述欲下载文件编号对应的文件排列在自身下载队列中，发送给接收端，再退出本流程；否则，执行步骤X5；\n[0065] 本发明中，如果重定向端有所述欲下载文件编号的文件，则需承担此次下载任务；\n如果没有所述欲下载文件编号的文件，则向接收端返回无下载文件响应消息。也就是说，重定向端不会再进行第二次重定向。\n[0066] 实际应用中，也可以规定重定向端再进行有限次重定向。当然，当重定向端再次进行重定向时，需要避免导致循环重定向的情况发生。比如：当重定向端根据自身下载任务队列表和种子节点表判断是否需要再次重定向，如果需要，则根据自身种子节点表确定第二次重定向端，再判断第二次重定向端是否为上次重定向给自身的用户端，如果是，则重新确定一个第二次重定向端，直至不与上次重定向给自身的用户端相同为止。\n[0067] X4、本次下载端将所述欲下载文件编号对应的文件排列在自身下载队列中，发送给接收端，再退出本流程；\n[0068] X5、重定向端向接收端返回无下载文件响应消息，接收端再向原下载端发送携带有欲下载文件编号的文件下载请求消息，并接收所述欲下载文件编号对应的文件，再退出本流程。\n[0069] 为了更好地说明本发明方案，下面用两个较佳实施例来说明实现小文件集合下载的方法。\n[0070] 实施例一\n[0071] 图3显示了本实施例的网络结构示意图。图3与图1的结构和功能完全相同，只是为了叙述方便，将提供小文件集合的用户端称为发布端，将发布端好友用户群中的用户端称为好友用户端，并且将其中一个将要下载文件的好友用户端称为接收端。\n[0072] 本实施例中，发布端处于在线状态，并且有100个好友用户端；小文件集合中有\n1000个文件。发布端先将1000个文件进行编号，并创建种子节点表，包括文件编号和拥有该文件的好友用户端ID号列表。发布端创建种子节点表之后，种子节点表中拥有该文件的好友用户端ID号列表为空。当某好友用户端下载完某一个文件之后，发布端就可以将该好友用户端记录在种子节点表中。假设本实施例中接收端向发布端发送下载请求消息之前，发布端种子节点表如表一所示。\n[0073] \n[0074] 表一\n[0075] 图4是本实施例的流程图。如图4所示，本实施例实现数据下载的方法包括以下步骤：\n[0076] 步骤401：发布端向接收端发送共享通知消息，接收端再向发布端发送下载请求消息。\n[0077] 步骤402：发布端将种子节点表发送给接收端，接收端创建用于记录文件接收状态的接收状态表。\n[0078] 接收端创建接收状态表，并设置所有文件编号对应的接收状态初始值为“未接收”。本实施例中的接收状态表如表二所示。\n[0079] \n 文件编号 接收状态\n 1 未接收\n 2 未接收\n 未接收\n 1000 未接收\n[0080] 表二\n[0081] 步骤403：接收端根据接收状态表确定欲下载文件编号。\n[0082] 实际应用中，接收端可以同时承担一个或一个以上的下载任务，所以当接收端第一次请求下载时，可以同时确定一个或一个以上欲下载文件编号。比如：将1～5的文件编号确定为欲下载文件编号。此后，接收端可以根据自身正在进行下载个数来确定欲下载文件编号。比如：接收端成功接收到文件编号为1的文件，而文件编号为2～5的文件正在下载过程中，就将文件编号为6的文件确定为欲下载文件编号，并依次类推。\n[0083] 步骤404：接收端将欲下载文件编号对应的好友用户端ID号发送给信息索引服务器进行在线过滤，获得在线的好友用户端ID号。\n[0084] 实际应用中，某些好友用户端在下载完小文件集合之后可能离线，并在信息索引服务器上进行登记。信息索引服务器接收到发送的好友用户端ID号之后，就可以根据登记情况判断哪些好友用户端处于在线状态，哪些好友用户端处于离线状态，并且将处于在线状态的好友用户端ID号返回给接收端，即进行在线过滤。\n[0085] 步骤405：接收端将数据传输速度最快的在线好友用户端作为本次下载端。\n[0086] 实际应用中，当接收端刚开始下载小文件集合中的文件时，还没有与任何一个好友用户端进行交互，即好友用户端向接收端传输数据的速度都为0，可以随机选择一个在线好友用户端作为本次下载端。但是，当接收端成功下载完一个文件之后，准备下载其它未下载文件时，由于已经与在线好友用户端进行了交互，可以检测传输数据的速度，并将传输数据速度最快的在线好友用户端作为本次下载端。\n[0087] 步骤406：接收端向本次下载端发送携带有欲下载文件编号的文件下载请求消息。\n[0088] 步骤407～步骤408：本次下载端根据自身下载任务队列表和种子节点表判断是否需要重定向，如果需要，则根据自身种子节点表确定重定向端，并将重定向端的ID号发送给接收端，再执行步骤409；否则，执行步骤411。\n[0089] 本步骤中，本次下载端判断是否需要重定向的方法为：本次下载端根据自身下载任务队列表中的下载任务个数判断自身是否忙，如果忙，再根据种子节点表判断是否存在重定向用户端，如果存在重定向端，则判断为需要重定向；否则，判断为无需重定向。\n[0090] 实际应用中，为了避免承担过大的下载负荷，影响下载速度，一般需要规定本次下载端承担下载任务个数的最大值。如果本次下载端下载任务队列表中的下载任务个数已经达到规定的最大值，则本次下载端判断自身为忙状态，不适合继续承载更多的下载任务，需要将此次下载任务重定向给其它的好友用户端。本次下载端再根据种子节点表确定是否存在重定向端，即查询种子节点表欲下载文件编号对应的好友用户端列表中是否还存在其它的拥有该文件的好友用户端ID号，如果存在，则确定一个好友用户端作为重定向端，并通知接收端。\n[0091] 步骤409：接收端根据重定向端ID号向重定向端发送携带有欲下载文件编号的文件下载请求消息。\n[0092] 步骤410～步骤411：重定向端判断自身是否存在所述欲下载文件编号对应的文件，如果存在，则将所述欲下载文件编号对应的文件排列在自身下载队列中，发送给接收端，再执行步骤415；否则，执行步骤413。\n[0093] 步骤412：本次下载端将所述欲下载文件编号对应的文件排列在自身下载队列中，发送给接收端，再执行步骤415。\n[0094] 步骤413：重定向端向接收端返回无下载文件响应消息，并将无下载文件的文件编号上报给发布端，发布端根据未下载文件编号更新种子节点表。\n[0095] 由于重定向端没有欲下载文件编号对应的文件，本步骤所述未下载文件编号就是所述欲下载文件编号。当发布端接收到重定向端上报的未下载文件编号时，将更新种子节点表，即：将未下载文件编号对应的重定向端ID号从拥有该文件的好友用户端ID号列表中删除。\n[0096] 步骤414：接收端再向发布端发送携带有欲下载文件编号的文件下载请求消息，并接收所述欲下载文件编号对应的文件。\n[0097] 实际应用中，由于发布端存在小文件集合中所有的文件，可以直接将欲下载文件编号对应的文件下载给接收端。为了避免发布端承载过大的下载任务，发布端也可以再次将此次下载任务重定向给其它的好友用户端，即：\n[0098] 当发布端接收到文件下载请求消息时，发布端根据自身下载任务队列表和种子节点表判断是否需要重定向，如果需要，则根据自身种子节点表确定重定向端，接收端向重定向用户端发送携带有欲下载文件编号的文件下载请求消息，重定向用户端判断自身是否存在所述欲下载文件编号对应的文件，如果存在，则将所述欲下载文件编号对应的文件排列在自身下载队列中；否则，发布端将所述欲下载文件编号对应的文件排列在自身下载队列中。\n[0099] 这里所述发布端判断是否需要重定向的方法与步骤407～步骤408中所述的重定向方法相似，此处不再赘述。\n[0100] 步骤415：接收端更新接收状态表，将自身接收状态表中欲下载文件编号对应的接收状态更改为已下载。\n[0101] 步骤416：接收端将已下载文件的文件编号上报给发布端，发布端根据已下载文件编号更新种子节点表。\n[0102] 本步骤所述的已下载文件的文件编号其实就是所述欲下载文件编号，由于该欲下载文件编号已经成功下载，并在接收状态表更改为已下载，所以，接收端上报给发布端的为已下载文件的文件编号。\n[0103] 当发布端接收到上报的已下载文件编号时，将更新种子节点表，即：将接收端的ID号添加到已下载文件编号对应的拥有该文件的好友用户端ID号列表中。\n[0104] 步骤417：接收端判断是否下载小文件集合中所有的文件，如果是，则退出本流程；否则，返回步骤403。\n[0105] 本实施例只描述了一个好友用户端作为接收端时下载小文件集合的方法。实际应用中，可能有多个好友用户端同时下载小文件集合，则当某一个接收端成功接收到一个或一个以上的文件之后，就可以作为本次下载端向其它接收端提供已经接收到的文件，从而可以大大提高下载速度。\n[0106] 实施例二\n[0107] 图5是本实施例的网络结构示意图。图5与图1的结构和功能也完全相同，只是为了叙述方便，将处于在线状态且存在小文件集合的用户端称为伪发布端，将处于离线状态的原发布端的好友用户群中的用户端称为好友用户端，并且将其中一个将要下载文件的好友用户端称为接收端。当然，这里所述的伪发布端也是原发布端的好友用户端。\n[0108] 本实施例中，当发布端离线之前，已经在信息索引服务器上发布了信息，所述发布信息包括好友用户端的ID号。本实施例中，伪发布端不但有小文件集合中的所有文件，还有记录文件分布情况的种子节点表。\n[0109] 图6是本实施例的流程图。如图6所示，本实施例实现数据下载的方法包括以下步骤：\n[0110] 步骤601：接收端从信息索引服务器获取发布端事先保存的好友用户端ID号，再根据好友用户端ID号确定一个伪发布端，并向伪发布端发送下载请求消息。\n[0111] 实际应用中，由于发布端在离线之前已经将包括好友用户端ID号的信息发布到信息索引服务器，不管发布端离线之前接收端是否在线，当发布端离线之后，接收端都可以在信息索引服务器中查询发布端发布的信息，并获得好友用户端ID号。然后，接收端再从所述的好友用户端的ID号中确定一个伪发布端。\n[0112] 确定伪发布端的方法可以为：接收端先将获得的所有好友用户端的ID发送给信息索引服务器进行在线过滤，获得在线的好友用户端；接收端再依次向在线的好友用户端发送种子查询请求消息，直到某个在线好友用户端存在种子节点表，即已经下载过小数据文件，那么，接收端就将该好友用户端作为伪发布端。这里所述的在线过滤的方法与实施例一中的在线过滤方法相同，此处不再赘述。\n[0113] 步骤602：伪发布端将种子节点表发送给接收端，接收端创建用于记录文件接收状态的接收状态表。\n[0114] 步骤603：接收端根据接收状态表确定欲下载文件编号，并向伪发布端发送携带有欲下载文件编号的文件下载请求消息。\n[0115] 步骤604～步骤605：伪发布端根据自身下载任务队列表和种子节点表判断是否需要重定向，如果需要，则根据自身种子节点表确定重定向端，并将重定向端的ID号发送给接收端，再执行步骤606；否则，执行步骤609。\n[0116] 这里所述的步骤604～步骤605与实施例中的步骤407～步骤408相似，其区别仅仅在于本实施例直接由伪发布端判断，此处不再赘述。\n[0117] 步骤606：接收端根据重定向端ID号向重定向端发送携带有欲下载文件编号的文件下载请求消息。\n[0118] 步骤607～步骤608：重定向端判断自身是否存在所述欲下载文件编号对应的文件，如果存在，则将所述欲下载文件编号对应的文件排列在自身下载队列中，发送给接收端，再执行步骤612；否则，执行步骤610。\n[0119] 步骤609：伪发布端将所述欲下载文件编号对应的文件排列在自身下载队列中，发送给接收端，再执行步骤612。\n[0120] 步骤610：重定向端向接收端返回无下载文件响应消息，接收端再将无下载文件的文件编号上报给伪发布端，伪发布端根据未下载文件编号更新种子节点表。\n[0121] 步骤611：接收端再向伪发布端发送携带有欲下载文件编号的文件下载请求消息，并接收所述欲下载文件编号对应的文件。\n[0122] 步骤612：接收端更新接收状态表，将自身接收状态表中欲下载文件编号对应的接收状态更改为已下载。\n[0123] 步骤613：接收端将已下载文件的文件编号上报给伪发布端，伪发布端根据已下载文件编号更新种子节点表。\n[0124] 步骤614：接收端判断是否下载完小文件集合中所有的文件，如果是，则退出本流程；否则，返回步骤603。\n[0125] 实际应用中，如果伪发布端自身没有下载完小文件集合中的全部文件，则接收端可以重新从在线好友用户端中确定新的伪发布端，并采用本实施例的方法进行下载，直到小文件集合中的文件全部下载。\n[0126] 应用本实施例方案，接收端可以在发布端离线的情况下，可以从信息索引服务器中获得好友用户端ID，并将已经下载有小文件集合的在线好友用户端作为伪发布端，通过伪发布端下载文件，从而达到在发布端离线情况下，接收端仍然可以获得发布端提供的小文件集合的目的。\n[0127] 综上所述，以上仅为本发明的较佳实施例而已，并非用于限定本发明的保护范围。\n凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。