CN101119249A - 一种数据下载方法及系统 - Google Patents

Abstract

本发明公开一种数据下载方法及系统。所述方法为：服务端向客户端下发组播地址及客户信息列表；客户端通过组播地址从服务端下载数据；客户端向客户信息列表内的其他客户端请求获取未成功接收到的数据，被请求的客户端若含有所述请求的数据，则发送给请求的客户端。所述系统包括：服务端，用于向客户端下发组播地址及客户信息列表，向客户端下发数据；客户端，用于接收服务端下发的组播地址及客户信息列表，通过组播地址从服务端下载数据，向客户信息列表内的其他客户端请求获取未成功接收到的数据或向其他请求获取数据的客户端发送请求的数据。本发明能增强数据下载的可靠性和解决数据下载过程中的网络带宽浪费问题。

Description

一种数据下载方法及系统

技术领域

本发明涉及互联网技术领域，具体涉及在互联网中的一种数据下载方法及系统。

背景技术

目前，在互联网中，有很多种方法可以将远程数据下载到本地存储系统。针对于不同的应用场景，数据下载有单播方式也有组播方式。所谓单播，是指在网络传送时，通信的双方采用一对一的方式发送数据包。所谓组播，是指在网络传送时，通信的双方采用一对多的方式发送数据包，其IP地址属特定的范围，只有加入这个IP地址的接收端才能收到数据包，而发送端只要发送到这个IP地址就可以了。单播方式的典型代表是点对点技术P2P(peer-to-peer)数据下载。组播方式的典型代表是采用数据轮播技术，即在一个组播组内循环发送要下载的数据。

现有技术中可以利用P2P技术进行远程数据下载，例如采用BitTorrent下载。BitTorrent是一种分发数据的协议，它通过统一资源定位符URL(UniformResource Locator)来识别内容，并且可以无缝地和网页web进行交互。它基于互联网HTTP协议，它的优势是：如果有多个下载者并发地下载同一数据，那么，每个下载者也同时为其它下载者上传数据，这样，数据源可以支持大量的用户进行下载。

但此种方法的缺陷是可能会造成网络堵塞。现在的网络是“上下非对称”的金字塔结构，也就是网络主干的带宽远远小于所有用户带宽之和，但现在网络使用的单播通讯协议却要求网络主干的带宽等于或接近所有用户带宽之和。现在的状况是一个城市或省的网络出口主干的带宽大约相当于其所有客户带宽之和的5％，也就是说假如有5％的客户用BT软件通过网络全速传输数据，那其余95％的客户就没有办法使用网络了。另外，当前的网络是非对称网络，采用P2P进行数据下载，当用户数据量达到一定程度，会造成骨干网的堵塞，这是运营商所不愿看到的。

第二种现有技术是采用组播方式中的数据轮播方法，即在一个组播组内循环发送要下载的数据。具体请参阅图1，包括步骤：

A1、服务端准备数据并创建组播组，通知客户端进行数据下载；

A2、客户端加入组播组，准备数据接收；

A3、服务端通过组播把数据循环推送下去，客户端接收并保存数据，本次没有接收到或者丢失的数据等到下一轮组播时接收。

此种方法虽然避免了造成网络堵塞等问题，但仍具有以下不足：

1、由于是采用组播方式，决定了它是一种不可靠的下载方式；

当前，支持组播的标准传输层协议只有用户数据报协议UDP，因而组播报文的传输是不可靠的。IP层的组播通信只提供“尽力型”服务，不保证组播数据报文的可靠传输。

2、客户端在本次错过某些数据信息接收或者接收到损坏的数据时，必须等到下一轮组播时才能重新接收该段数据，这导致了比较大的接收延迟；

3、由于数据是循环的轮播，虽然在一定程度上弥补了传输过程中的数据丢失，但大量的客户端已经拥有的数据也会被一遍又一遍地重复轮播下来，从而造成网络带宽不必要的浪费。

发明内容

本发明要解决的技术问题是提供一种数据下载方法及系统，本发明能够增强数据下载的可靠性和解决数据下载过程中的网络带宽浪费问题。

本发明的目的是通过以下技术方案实现：

本发明提供一种数据下载方法，包括：服务端向客户端下发组播地址及客户信息列表；客户端通过组播地址从服务端下载数据；客户端向客户信息列表内的其他客户端请求获取未成功接收到的数据，被请求的客户端若含有所述请求的数据，则发送给请求的客户端。

进一步的，所述方法还包括客户端向服务端汇报数据接收情况，服务端根据所述数据接收情况向客户端下发未成功接收到的数据。

所述服务端向客户端下发未成功接收到的数据通过原有组播地址或新建的组播地址下发。

进一步的，客户端从服务端下载数据过程中正常或异常退出后，服务端从客户信息列表删除所述客户端的信息，并将更新后的客户信息列表下发给其他客户端。

进一步的，服务端接收到客户端的数据下载请求后，将客户端信息加入客户信息列表。

进一步的，服务端确认客户端属授权用户后将客户端信息加入客户信息列表，以及，客户端确认其他请求获取未成功接收到的数据的客户端在客户信息列表内再发送请求的数据到请求的客户端。

进一步的，客户端从服务端下载数据前，服务端将客户端请求下载的数据分块和打包，并注明标识后发送，以及，客户端从服务端下载数据过程中，客户端根据所述标识向其他客户端请求获取未成功接收到的数据或向其他请求获取未成功接收到的数据的客户端发送请求的数据。

其中，所述发送的数据包括经过前向纠错处理的数据。

相应地，本发明提供一种数据下载系统：包括服务端和客户端；服务端，用于向客户端下发组播地址及客户信息列表，并向客户端下发数据；客户端，用于接收服务端下发的组播地址及客户信息列表，通过组播地址从服务端下载数据，向客户信息列表内的其他客户端请求获取未成功接收到的数据或向其他请求获取未成功接收到的数据的客户端发送请求的数据。

客户端进一步包括用于向服务端汇报数据接收情况；以及，服务端进一步包括用于根据所述数据接收情况向客户端下发未成功接收到的数据。

本发明还提供一种用于数据下载的服务端：包括数据单元、第一打包单元、第一数据下载处理单元和第一网络收发单元；数据单元，用于存储下发的数据，将数据传递给第一打包单元进行打包；第一打包单元，用于将数据进行打包和注明标识；第一数据下载处理单元，用于控制数据的下发流程；第一网络收发单元，用于接收和下发数据，向客户端下发数据，接收客户端返回的关于数据接收情况的信息。

服务端进一步包括第一前向纠错处理单元，用于将数据单元传递的数据进行前向纠错处理，并传递给第一打包单元进行打包。

本发明还提供一种用于数据下载的客户端：包括第二网络收发单元、第二数据下载处理单元、解包单元和本地存储系统单元；第二网络收发单元，用于下载和发送数据，从服务端下载数据，向服务端返回关于数据接收情况的信息，向其他客户端发送获取未成功接收到的数据的请求或向其他请求获取未成功接收到的数据的客户端发送请求的数据；第二数据下载处理单元，用于控制客户端的数据下载过程；解包单元，用于将第二网络收发单元下载的数据包解包后传递到本地存储系统单元进行存储；本地存储系统单元，用于存储解包单元传递的数据。

客户端进一步包括第二打包单元，用于将本地存储系统单元存储的其他客户端请求获取的未成功接收到的数据进行打包，并通过第二网络收发单元发送给请求的其他客户端。

客户端进一步包括第二前向纠错处理单元，用于将解包单元传递的数据进行前向纠错恢复处理，并传递到本地存储系统单元进行存储，还包括用于将本地存储系统单元存储的其他客户端请求获取的未成功接收到的数据进行前向纠错处理，并传递给第二打包单元进行打包。

以上技术方案可以看出：

首先，前述现有技术中采用组播方法，不能保证数据下载的可靠性，可能出现数据丢失，但没有相应的修复机制来恢复丢失的数据，必须等到下一轮组播时再接收丢失的数据，而本发明采用的数据下载的方法，在从服务端下载数据过程中出现数据丢失、损坏或错过部分数据时，客户端向向客户信息列表内的其他客户端请求获取未成功接收到的数据，被请求的客户端若含有所述请求的数据，则发送给请求的客户端，达到了对丢失的数据进行修复，增强了数据下载的可靠性，一定程度上克服了普通组播技术传输数据不可靠的缺点，并且本发明使得客户端不必等到下一轮服务端下发数据才可以继续接收需要的数据，也避免了比较大的接收延迟；

进一步的，前述现有技术中每次轮播都是全部数据，大量的客户端已经拥有的数据也会被一遍又一遍地重复轮播下来，造成网络带宽不必要的浪费，而本发明中，客户端向服务端汇报数据接收情况，服务端根据所述数据接收情况，在一轮数据组播完成后向客户端下发未成功接收到的数据，也就是只需要下发部分数据即可，从而避免浪费带宽。

附图说明

图1是现有技术中采用轮播方法流程图；

图2是本发明方法总括流程图；

图3是本发明方法具体流程图；

图4是本发明方法中客户端间通信流程图；

图5是本发明系统结构示意图；

图6是本发明中服务端结构示意图；

图7是本发明中客户端结构示意图。

具体实施方式

本发明提供一种数据下载方法，其核心思想是：客户端通过组播地址从服务端下载数据时，如果错过、丢失部分数据或接收到损坏的数据，则可以向属于同一客户信息列表内的其他客户端请求获取未成功接收到的数据，被请求的客户端接到请求后，若含有所述请求的数据，则发送给请求的客户端，这样客户端不必等到下一轮服务端下发数据才可以继续接收需要的数据。另外，客户端向服务端汇报未成功接收的数据情况，服务端对所有客户端的数据接收情况进行统计，并在下一轮组播时向客户端下发未成功接收到的数据，而不必下发所有数据。

需要说明的是，本发明以在交互式网络电视IPTV系统应用为例进行说明但不局限于此，本发明也适用其他在互联网中的数据下载业务。

本发明系统包括服务端和客户端，客户端向服务端请求下载数据，服务端通过承载网将数据以组播的方式推送下去，在数据推送的过程中，如果有其它客户端请求下载的是同一份数据，在条件允许范围内，该客户端一方面加入组播组接收组播数据，另一方面，向其它客户端请求错过、丢失或者损坏的下载数据，被请求的客户端若含有所述请求的数据，则发送给请求的客户端。客户端会向服务端汇报数据接收情况，服务端根据客户端的数据接收情况进行统计，并在一轮组播完成后，组播所有客户端未成功接收到的数据，未成功接收到的数据包括错过、丢失或损坏的数据。请参阅图2，是本发明方法总括流程图，包括步骤：

B1、服务端准备数据并创建组播组；

B2、客户端加入组播组，准备接收数据；

服务端向客户端下发组播地址及客户信息列表，客户端收到这些信息后，加入组播组，准备接收数据。

B3、服务端组播数据；

服务端开始组播，客户端通过服务端下发的组播地址从服务端下载数据。

B4、客户端间传递从服务端未成功接收到的数据；

客户端向服务端下发的客户信息列表内的其他客户端请求获取从服务端未成功接收到的数据，被请求的客户端若含有所述请求的数据，则发送给请求的客户端。

B5、客户端向服务端汇报数据接收情况，服务端根据所述数据接收情况重新组播所有客户端未成功接收到的数据。此时可以通过原有组播地址组播数据，也可以通过新建的组播地址组播数据，若新建组播地址，则客户端需要加入到新组播组，通过新的组播地址接收服务端下发的数据。

请参阅图3，是本发明方法的具体流程图，包括步骤：

C1、服务端进行数据准备，创建组播组；

服务端在数据发布过程中，需要将要下载的数据进行分块发送。在IPTV数据下载系统(CDS)内，客户端通过宽带内容向导BCG(Broadband ContentGuide)获取服务端地址和数据的基本信息。BCG规范是由DVB-IPI组织负责制定，主要应用于新的宽带业务上。服务端将数据准备好后，创建组播组。

服务端准备的数据基本信息主要包括如下部分：

a、数据基本信息描述，比如数据名称，总长度，基本信息描述，前向纠错处理FEC(Forward Error Correction)参数等，其中FEC为可选项；

b、数据分块大小以及子块大小，为了便于网络传输，一个分块可以分成若干子块；

服务端将用户要下载的数据分隔成大小一样的块，每一块的大小为2的指数次方，然后在分块上划分子块，子块大小也是2的指数次方。每一个子快加上包头作为网络上发送的数据包单元，每一个数据包都按规则进行编号，客户端根据编号可以判断数据包在数据中的具体位置以及哪些数据包没有收到。

需要说明的是，本发明以此分块方法为例但并不局限于此，也可以按其他方式进行划分。

c、数据传输协议；

数据传输协议指明数据在网络上传输的数据包采用什么样的格式，可以采用实时传输协议RTP(Real Time Transport Protocol)，或者直接采用用户数据报文协议UDP(User Datagram Protocol)和自定义的数据包头。客户端根据数据传输协议，进行相应的解包，同时，也可以支持重新打包，同一数据，经过客户端重新打的包必需保证和服务端完全一致。

d、数据和数据组播地址信息。

C2、客户端请求下载数据，并加入到组播组；

根据客户端请求下载的时机，可以分为下面四种情况：

1、客户端请求下载时，数据下载组播组还没有建立；

客户端在请求下载时，服务端还没有准备好组播数据，接收到客户端的请求后，服务端记录客户信息，创建组播组。同时，根据下载条件，比如规定上午8:00开始推送数据，或者当请求者达到10人以上等，决定数据推送时间。

服务端将客户信息加入到客户信息列表内，然后将客户信息列表和数据组播地址下发到客户信息列表内的每个客户端，客户端收到这些信息后，加入到数据下载的组播组，准备接收数据。

2、客户端请求下载时，数据下载组播组已经建立，但还没有下发数据；

客户端在请求下载时，服务端已经创建了组播组，接收到客户端的请求后，记录客户信息，同时，根据下载条件，比如规定上午8:00开始推送数据，或者当请求者达到10人以上等，决定数据推送时间。

服务端将客户信息加入到客户信息列表内，然后将客户信息列表和数据组播地址下发到客户信息列表内的每个客户端，客户端收到这些信息后，加入到数据下载的组播组，准备接收数据。

3、客户端请求下载时，数据下载组播组已经建立并正在下发数据，并且客户端在下载条件允许范围内；

客户端在请求下载时，服务端已经创建了组播组并且正在下发数据，接收到客户端的请求后，记录客户信息。服务端将客户信息加入到客户信息列表内，然后将客户信息列表和数据组播地址下发到客户信息列表内的每个客户端，客户端收到这些信息后，加入到数据下载的组播组，开始接收数据。同时，如果客户端的带宽和性能足够，客户端向客户信息列表内的其它客户端请求获取错过、丢失或损坏的数据，如果其它客户端的带宽和性能足够，则向该客户端提供其请求的错过、丢失或损坏的数据。

4、客户端请求下载时，数据下载组播组已经建立并正在下发数据，但客户端不在下载条件允许范围内。

客户端在请求下载时，服务端已经创建了组播组并且正在下发数据，由于客户端的请求不在下载条件允许范围内，比如下载条件为：本次组播只接收8:00～8:30请求下载的用户请求，而客户端在8:50提出下载请求，或者本次数据下载最多允许5000用户下载，而该客户端是第5001个请求数据下载者等，服务端在接收到客户端的请求后，记录客户信息，将客户端加入到下一轮次组播客户信息列表内。

需要说明的是，客户端向服务端请求下载文件，服务端将根据安全机制验证客户端身份，例如可以根据客户端的网络地址等进行，若是授权用户则通过验证，否则拒绝，通过验证后服务端将记录客户端信息，并允许其加入组播组。

C3、服务端组播数据，客户端接收数据；

在指定条件满足后，服务端将数据推到指定的组播组向客户信息列表内的客户端进行组播，客户端加入组播组后即可以进行相关数据下载。

这里所说的指定条件是服务端根据自身策略而定，例如该条件可以这样制定：规定上午8:00开始推送数据，或者当请求者达到10人以上进行推送数据等。

C4、客户端向其他客户端请求获取未成功接收到的数据；

客户端在接收组播数据的同时，如果错过了某些数据的下载，或者出现了丢包或者数据包损坏的情况，可以通过端到端的方式从其它客户端请求错过的、丢失的或者损坏的数据，而其他客户端收到请求后，还可以判断请求的客户端是否在客户信息列表内，只有确认请求所需数据的客户端在组播组的客户信息列表内才发送数据到请求的客户端。

客户端下载的主要数据是通过组播的方式获取的，少量的数据需要从其它客户端获取，这部分所占用的带宽相对较少。

由于数据需要进行分块传输，每一个分块又由多个数据包所组成，两个客户端之间交换分块数据与交换单个数据包数据相比，前者占有的控制信息带宽与处理明显就要小得多。因此，客户端应该尽量向其它客户端请求重传整个分块，而不是单个数据包。考虑到在数据下载过程中，数据丢包率一般不会太高，可以采用如下策略进行客户端之间的数据重传：

客户端在下载的过程中，如果错过、丢失或者损坏了某个数据包。如果该数据包所在的分块内所有的数据包都没有收到，则向其它客户端请求该分块数据，如果只是某分块内一部分数据错过、丢失或者损坏，可以向其它客户端请求错过、丢失或者损坏的数据包。

当客户端发现有数据丢失时，它首先根据当前客户信息列表，向其它客户端发送查询包，查询包可以包括本客户端基本信息，丢失的数据包序号，是否支持FEC等信息。其基本流程请参阅图4本发明方法中客户端间通信流程图。

如图4所示，包括步骤：

D1、客户端1发现有数据错过、丢失或者损坏；

D2、客户端1向客户端2和3同时发送查询包，询问是否含有客户端1所错过、丢失或者损坏的数据；

D3、客户端2告知客户端1含有所需数据；

D4、客户端1取消向客户端3的查询请求；

D5、客户端2向客户端1发送所需的数据包；

客户端2判断客户端1是否支持FEC解码，如果客户端1支持FEC解码，客户端2检查是否有客户端1所需要的数据包所对应的FEC包，若有，则将该FEC包发送给客户端1，若无，则直接把客户端1所需要的数据包发送过去；如果客户端1不支持FEC解码，则客户端2直接把客户端1所需要的数据包发送过去。

需要说明的是，客户端2提供的数据包可以来自本地缓冲区，也可以在本地利用传输协议重新打包，但是重新打的数据包必需和服务端提供的数据包内容完全一致；客户端2的FEC包可以来自本地缓冲区，也可以在本地利用FEC算法产生。

FEC包可以看成是冗余数据包，采用相应的FEC算法，将某个普通数据包进行FEC处理，可以获得相应的FEC数据包。数据下载时，一般是同时发送普通数据包和FEC包。另外，选用某种FEC算法，也可以不传送普通数据包而只发送FEC包，当然，也可以选择只发送普通数据包。FEC是可选项，服务端可以支持或不支持，客户端也可以支持或不支持，或者服务端选用FEC，但客户端可以不支持FEC，此时客户端如果不支持FEC，则它只需要选择接收普通数据包即可，不需要接收FEC数据包。通过FEC数据包可以恢复丢失的普通数据包，在数据下载时采用FEC包可以节省数据包丢失时重新请求数据包带来的额外交互开销，但同时采用FEC技术也可能会给网络额外带来一些带宽开销。另外，采用FEC技术时，服务端准备的数据基本信息中还可以包括FEC数据组播地址信息。

需要说明的是，在客户端接收服务端组播数据的过程中，如果客户端完成下载，并且没有其他客户端连接请求获取数据，则可以退出下载，如果还有其他客户端连接请求获取数据，则继续提供数据给其他客户端。

C5、服务端更新客户信息；

在下载过程中，服务端周期性的检测客户端状态，更新本地客户信息列表，并将更新后的客户信息列表下发给客户端。在IPTV的数据下载系统(CDS)内，服务端通过业务发现与选择SD&S(Service Discovery and Selection)将客户信息推送到客户端，客户端收到信息后，更新本地客户信息列表。客户端保存下载客户信息，主要用于数据错过、丢失或损坏时，根据当前下载客户信息，向其它客户端发送查询包，也用于确认请求所需数据的客户端是否在组播组的客户信息列表内，只有确认后才发送数据到请求的客户端。收到查询包的客户端，如果有该客户端需要的数据包，就将其发送给该客户端。

C6、客户端向服务端汇报数据接收情况；

当客户端不能从其它客户端获取到所需要的数据，则该客户端通过数据接收报告通知服务端。

C7、服务端统计客户下载信息，组播所有客户端不能通过客户端间端到端方式获得的数据；

在服务端组播完数据后，根据当前所有客户端发送的数据接收报告，统计客户的下载信息，然后将所有客户端不能通过端到端请求获得的数据通过组播的方式推送下来。此时可以通过原有组播地址组播数据，也可以通过新建的组播地址组播数据，若新建组播地址，则客户端需要加入到新组播组，通过新的组播地址接收服务端下发的数据。

正常情况下，服务端只需要统计一两次数据下载信息就可以完成整个网络的数据下载。也就是说只需要组播一两次数据，第一次组播所有数据，以后组播网络上客户端缺失的数据，而不必象以前那样重新组播所有数据。

C8、所有客户端完成组播数据下载后，服务端关闭组播组。

为便于更好地理解本发明方法，下面举一个具体应用实施例。

在上午7:55～8:00之间，有200个客户向服务端请求下载文件“a.dat”，上午8:00服务端开始组播文件数据，组播时间为8:00～9:00，在该时间又有500个客户加入下载。在8:00～9:00期间，客户一边接收组播数据，一边从其它客户那里下载其错过、丢失或者损坏的数据。9:00之后，服务端统计所有在线的下载客户数据信息，将所有客户错过、丢失或者损坏的数据，通过组播重新下发。

具体实施步骤包括：

1、服务端准备文件“a.dat”，文件大小为256M，设置文件分块大小为256K，共1000个分块，网络发送的数据包大小为1K，则每个分块256个包。每个分块都有一个分块号，从0开始编号，范围是0～999，每一个数据包都有一个分块内包号，从0开始编号，范围是0～255，在网络上发送的数据包序号由两部分组成，包括分块号和分块内包号，由每个数据包号序号可以定位其在文件中的具体位置；

2、客户端向服务端请求下载文件，服务端验证客户端身份，若是授权用户则通过验证，否则拒绝，通过验证后服务端将记录客户端信息；

3、服务端将文件信息、文件源网络组播地址/端口信息、组内成员列表发送到组内各客户端，并创建组播组，客户端收到服务端发送的信息，加入到组播组；

4、在上午8:00，服务端开始组播数据，客户端接收并统计接收到的数据；

在下载过程中，如果客户端在下载组播数据时有数据错过、丢失或损坏，该错过、丢失或损坏的数据如果其它客户端拥有，则可以从其它客户端请求获取，否则，客户端记下数据包的信息，最后由服务端统计，再重新组播，统一下发给客户端；如果是向其它客户端下载数据的过程中出现数据丢失，则重传该数据包所在的分块数据。

在8:00～8:30加入下载的客户端，一方面加入组播组下载数据，同时，假定该客户端错过了分块0～50、分块51内的数据包254和255，则向其它客户端请求传送分块0～50内的数据包，以及分块51内的数据包254和255。

在下载过程中，如果带宽不够，将优先满足组播数据下载，其次才是和其它客户端之间的数据下载。

5、服务端周期地向客户端获取信息状态，更新客户信息；

在下载过程中，服务端将周期性地检测客户端状态，更新本地客户信息列表，并将更新后的客户信息列表下发给客户端。

当客户端下载完成，客户端连接的其他请求客户端都断开连接，则可以退出组播组，向服务端发送要退出下载的消息，服务端将该客户端从组内成员信息列表内删除，同时，将新的组内成员客户信息列表下发给列表内的其它客户端，但客户端下载完成时如果还有其它客户端和它连接并从其下载数据，则继续提供数据给其它客户端。需要说明的是，客户端根据自身需要，随时可以退出组播组，服务端通过客户端发送的退出消息或周期性地检测，可以知道客户端的状态，并更新客户信息列表。

6、客户端向服务端汇报数据接收情况；

当客户端不能从其它客户端获取到所需要的未成功接收到的数据，则该客户端通过数据接收报告通知服务端。

7、一次组播完成后，服务端统计客户下载信息，并组播所有客户端不能通过客户端间端到端方式获得的错过、丢失或损坏的数据；

此时服务端可以通过原有组播地址组播数据，也可以通过新建的组播地址组播数据，若新建组播地址，则客户端需要加入到新组播组，通过新的组播地址接收服务端下发的数据。

8、所有客户端都完成下载，服务端关闭组播组，数据下载完成。

相应的，本发明提供一种数据下载系统。请参阅图5，是本发明系统结构示意图。

本系统500包括服务端501和客户端502。

服务端501，用于向客户端502下发组播地址及客户信息列表，接收客户端502加入组播组，并向客户端502下发数据；客户端502，用于接收服务端501下发的组播地址及客户信息列表，通过组播地址从服务端501下载数据，向客户信息列表内的其他客户端请求获取未成功接收到的数据或向其他请求获取未成功接收到的数据的客户端发送请求的数据。

本发明中客户端502向服务端501请求数据下载，服务端501通过承载网将数据以组播的方式推送下去，在数据推送的过程中，如果有其它客户端请求下载的是同一数据，在条件允许范围内，客户端502一方面加入组播组接收组播数据，另一方面，向其它客户端请求获取错过、丢失或者损坏的下载数据，被请求的客户端若含有所述请求的数据，则发送给请求的客户端502。客户端502会向服务端501汇报数据接收情况，服务端501根据所有客户端数据接收情况进行统计，并在一次组播完成后，组播所有客户端未成功接收到的数据。此时服务端501可以通过原有组播地址组播数据，也可以通过新建的组播地址组播数据，若新建组播地址，则客户端502需要加入到新组播组，通过新的组播地址接收服务端501下发的数据。

请参阅图6，是本发明中服务端501结构示意图。服务端501包括数据单元601、第一打包单元602、第一数据下载处理单元603和第一网络收发单元604。

数据单元601，用于存储下发的数据，将下发数据传递给第一打包单元602进行打包；第一打包单元602，用于将数据进行打包和注明标识；第一数据下载处理单元603，用于控制数据的下发流程，例如控制是否采用FEC处理，采用什么打包方式，何时打包，采用什么打包格式，处理数据下载请求，以及网络数据发送/接收控制等；第一网络收发单元604，用于接收和下发数据，向客户端502下发数据，接收客户端502返回的关于接收情况的信息。

服务端501进一步包括第一前向纠错FEC处理单元605，用于将数据单元601传递的数据进行前向纠错处理，并传递给第一打包单元602进行打包。第一前向纠错处理单元605在服务端501中为可选单元。如果有第一前向纠错FEC处理单元605，则数据先送给第一前向纠错FEC处理单元605处理，否则，直接送给第一打包单元602打包。前向纠错FEC处理，是将原始数据通过FEC算法获得FEC包，而通过FEC包可以还原数据，即如果原始数据包丢失，通过该包的FEC数据包，可以重新生成原始数据。

请参阅图7，是本发明中客户端502结构示意图。客户端包括第二网络收发单元701、第二数据下载处理单元702、解包单元703和本地存储系统单元704。

第二网络收发单元701，用于下载和发送数据，从服务端501下载数据，向服务端501返回关于数据接收情况的信息，向其他客户端发送获取未成功接收到的数据的请求或向其他请求获取未成功接收到的数据的客户端发送请求的数据；第二数据下载处理单元702，用于控制客户端502的数据下载过程；解包单元703，用于将第二网络收发单元701下载的数据包解包后传递到本地存储系统单元704进行存储，即将网络上接收到的数据包去掉网络封装的包头，并保存在本地存储系统单元704；本地存储系统单元704，用于存储解包单元703传递的数据。

客户端502进一步包括第二前向纠错FEC处理单元705和第二打包单元706；第二前向纠错FEC处理单元705，用于将解包单元703传递的数据进行前向纠错恢复处理，并传递到本地存储系统单元704进行存储，还包括用于将本地存储系统单元704存储的其他客户端请求获取的未成功接收到的数据进行前向纠错处理，并传递给第二打包单元706进行打包。也就是说，如果有数据包丢失并且接收到该数据包对应的FEC数据包，则第二前向纠错FEC处理单元705将解包单元703解出来的FEC数据包还原数据，并保存到本地存储系统单元704；或者直接利用本地数据重新生成FEC数据包，送给第二打包单元706，发送到对应的网络。第二打包单元706，用于将经过或未经过第二前向纠错FEC处理单元705进行前向纠错处理的本地存储系统单元704存储的其他客户端请求获取的未成功接收到的数据进行打包，封装为网络上发送的数据包格式，并通过第二网络收发单元701发送给请求的其他客户端。第二前向纠错FEC处理单元705和第二打包单元706在客户端中为可选单元。

本发明中客户端502的第二网络收发单元701一方面接受下载的数据，另一方面也给其它客户端提供数据。当向其它客户端提供数据时，如果其它客户端请求的数据在缓冲区内，则可以直接转发，如果当前缓冲区内没有所需要的数据包，则需要判断所请求的客户端是否支持传输数据打包，如果支持，则从本地存储系统单元704获取数据打包发送给请求的客户端，如果所请求的客户端是支持FEC编码，也可以重新生成FEC包发送。

以上对本发明所提供的一种数据下载方法及系统进行了详细介绍，本文中应用了具体个例对本发明的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本发明的方法及其核心思想；同时，对于本领域的一般技术人员，依据本发明的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本发明的限制。

Claims (15)

1.一种数据下载方法，其特征在于，包括：

服务端向客户端下发组播地址及客户信息列表；

客户端通过组播地址从服务端下载数据；

客户端向客户信息列表内的其他客户端请求获取未成功接收到的数据，被请求的客户端若含有所述请求的数据，则发送给请求的客户端。

2.根据权利要求1所述的数据下载方法，其特征在于：

还包括客户端向服务端汇报数据接收情况，服务端根据所述数据接收情况向客户端下发未成功接收到的数据。

3.根据权利要求2所述的数据下载方法，其特征在于：

所述服务端向客户端下发未成功接收到的数据通过原有组播地址或新建的组播地址下发。

4.根据权利要求1、2或3所述的数据下载方法，其特征在于：

客户端从服务端下载数据过程中正常或异常退出后，服务端从客户信息列表删除所述客户端的信息，并将更新后的客户信息列表下发给其他客户端。

5.根据权利要求1所述的数据下载方法，其特征在于：

服务端接收到客户端的数据下载请求后，将客户端信息加入客户信息列表。

6.根据权利要求5所述的数据下载方法，其特征在于：

服务端确认客户端属授权用户后将客户端信息加入客户信息列表，以及，客户端确认其他请求获取未成功接收到的数据的客户端在客户信息列表内再发送请求的数据到请求的客户端。

7.根据权利要求1所述的数据下载方法，其特征在于：

客户端从服务端下载数据前，服务端将客户端请求下载的数据分块和打包，并注明标识后发送，以及，客户端从服务端下载数据过程中，客户端根据所述标识向其他客户端请求获取未成功接收到的数据或向其他请求获取未成功接收到的数据的客户端发送请求的数据。

8.根据权利要求7所述的数据下载方法，其特征在于：

所述发送的数据包括经过前向纠错处理的数据。

9.一种数据下载系统，其特征在于：

包括服务端和客户端；

服务端，用于向客户端下发组播地址及客户信息列表，并向客户端下发数据；

客户端，用于接收服务端下发的组播地址及客户信息列表，通过组播地址从服务端下载数据，向客户信息列表内的其他客户端请求获取未成功接收到的数据或向其他请求获取未成功接收到的数据的客户端发送请求的数据。

10.根据权利要求9所述的数据下载系统，其特征在于：

客户端进一步包括用于向服务端汇报数据接收情况；以及，服务端进一步包括用于根据所述数据接收情况向客户端下发未成功接收到的数据。

11.一种用于数据下载的服务端，其特征在于：

包括数据单元、第一打包单元、第一数据下载处理单元和第一网络收发单元；

数据单元，用于存储下发的数据，将数据传递给第一打包单元进行打包；

第一打包单元，用于将数据进行打包和注明标识；

第一数据下载处理单元，用于控制数据的下发流程；

第一网络收发单元，用于接收和下发数据，向客户端下发数据，接收客户端返回的关于数据接收情况的信息。

12.根据权利要求11所述的用于数据下载的服务端，其特征在于：

服务端进一步包括第一前向纠错处理单元，用于将数据单元传递的数据进行前向纠错处理，并传递给第一打包单元进行打包。

13.一种用于数据下载的客户端，其特征在于：

包括第二网络收发单元、第二数据下载处理单元、解包单元和本地存储系统单元；

第二网络收发单元，用于下载和发送数据，从服务端下载数据，向服务端返回关于数据接收情况的信息，向其他客户端发送获取未成功接收到的数据的请求或向其他请求获取未成功接收到的数据的客户端发送请求的数据；

第二数据下载处理单元，用于控制客户端的数据下载过程；

解包单元，用于将第二网络收发单元下载的数据包解包后传递到本地存储系统单元进行存储；

本地存储系统单元，用于存储解包单元传递的数据。

14.根据权利要求13所述的用于数据下载的客户端，其特征在于：

客户端进一步包括第二打包单元，用于将本地存储系统单元存储的其他客户端请求获取的未成功接收到的数据进行打包，并通过第二网络收发单元发送给请求的其他客户端。

15.根据权利要求14所述的用于数据下载的客户端，其特征在于：

客户端进一步包括第二前向纠错处理单元，用于将解包单元传递的数据进行前向纠错恢复处理，并传递到本地存储系统单元进行存储，还包括用于将本地存储系统单元存储的其他客户端请求获取的未成功接收到的数据进行前向纠错处理，并传递给第二打包单元进行打包。

Images