CN1697354B - 用组播和单播协议可靠传输数据的方法及接收数据的主机 - Google Patents

Abstract

本发明公开了一种综合运用组播和单播协议可靠传输数据的方法。其传输过程是：由发送或转发组播数据的主机向接收数据的主机发送至少一条组播数据流；接收数据的主机在接收组播数据流的过程中不断监测是否有错包和丢包数据，并在发现并接收到错包和丢包的数据后，以单播协议向约定地址的补包主机发出补包请求；约定地址的补包主机使用至少一个约定的单播地址接收该补包请求，并以单播协议向请求补包的接收数据的主机发送补包数据；接收数据的主机将接收到的有丢包的组播数据与单播补包数据整合，使其成为完整或部分完整的数据流。本发明解决了数据网络中组播协议传输数据可靠性差的问题，适用于所有具有单播和组播通讯模式的网络和网络协议。

Description

用组播和单播协议可靠传输数据的方法及接收数据的主机

技术领域

本发明属于通信技术领域，涉及网络中的数据传输，特别是一种在数据网络中用单播协议传输补充组播协议的数据传输方法，适用于所有具有单播和组播通讯模式的网络和网络协议。

背景技术

目前在数据网络中传输数据分为三大模式，第一种是单播(unicast)模式，它是一对一的通讯模式，例如，Internet就是以这种通信模式为主；第二种是广播broadcast模式，它是一对所有的模式，所有在网上的主机无论其是否需要都收到广播，广播信息在网络上进行无条件复制，由于其浪费资源所以广播方式被限制在小型局域网的范围内；第三种模式是组播模式(multicast，国内也有将其翻译成多目传送模式、多点传送模式、多播的模式)，组波模式是兼具上述两种模式优点的通讯方式，是一对多的通讯方式，这里的多指的是有需要的多个主机，信息在网络中由路由器或三层交换机进行按条件按需要的复制，所有有需要的主机通过发送请求获得复制的信息，唯一的缺点就是在传输过程中发生的丢包难以补充修复。

目前的宽带网的结构特点是主干网络带宽远小于所有用户接入带宽之和，在这种网络结构中，如果只用单播协议传输数据、为客户提供宽的服务必然会存在客户带宽无法得到满足的情况。单播传输协议提供宽带服务需要两个等式，一个是：网络主干总带宽＝所有客户接入带宽之和；另一个是：所有服务器总带宽＝所有客户机总带宽之和。要在宏观上实现这两个等式几乎是不可能完成的任务，虽然BT技术运用P2P的原理绕过了服务器的压力问题，但是它无法绕过网络主干的压力，对目前宽带网主干造成了极大的压力，以至于有ISP封了BT端口。CDN技术能稍微缓解这一状况，但其众多服务器的高昂的成本注定其不可能解决根本问题。

解决上述问题的方法是大规模推广使用组播协议，现行的组播协议用网络中的路由器按需对信息进行即时复制，具有能节省网络和服务器资源的优点，但是组播协议存在一个致命的缺陷就是可靠性差，由于其在传输过程中，对于丢包没有重传机制，所以利用组播协议传输的数据是不可靠的，这种不可靠传输特性严重阻碍了组播协议的推广使用，而且在但短期内似乎无法解决。目前正在讨论的可靠组播协议试图通过原来的组播地址进行补包重传，虽说在小规模范围内其技术可行，但在大规模的组播范围内由于其技术的复杂性和实现过程可靠性问题一直阻碍了其应用，所以在大规模的组播范围内这种方式明显是不现实和不划算的。

发明的内容

本发明的目的之一是提供一种在数据网络中综合运用组播和单播协议传输数据的方法，以解决组播协议传输数据可靠性差的问题；目的之二是提供一种接收数据的接收主机，以实现对传送数据的接收。

本发明的技术方案是这样实现的：

本发明适用于所有具有单播和组播通讯模式的网络和网络协议，由于现行的网络协议基本上都是用TCP/IP协议，为了便于理解就以IP组播和IP单播为例来说明，但并不表示本发明局限于IP网络。

本发明提出的在数据网络中综合运用组播和单播协议可靠传送数据的方法方法是一种完全采用单播协议对组播数据流的丢包进行补包的方式，这种补包方式可以完全独立于组播协议，使用现有的组播协议传输，对于传输过程中的丢包由单播协议完成补包工作，此补包流程也可以嵌入将来的IP协议中。该数据传输的过程包括发送和接收，其中，

所述的发送数据过程如下：

a.发送或转发组播数据的主机发送至少一条组播数据流；

b.约定地址的补包主机使用至少一个约定的单播地址接收来自接收数据的主机的补包请求；

c.约定地址的补包主机接收并识别补包请求，并按照请求的标尺刻度从存储器中定位并找到相应的数据；

d.约定地址的补包主机找到相应的数据后，以单播协议向请求补包的接收数据的主机发送补包数据；

所述的接收数据过程如下：

a.接收数据的主机加入至少一个组播组，接收组播数据流的数据；

b.接收数据的主机在接收组播数据流的过程中不断监测是否有错包和丢包数据；

c.接收数据的主机发现错包和丢包后，以单播协议向约定地址的补包主机发出补包请求；

d.接收数据的主机将接收到的有丢包的组播数据与单播补包数据进行整合。

实现本发明接收数据方法的主机包括如下几个功能模块：

存储模块，用于存储接收到的数据；

组播接收模块，用于接收组播数据流的数据，并

将接收到的这些数据存储到存储模块中；

丢包判断及补包控制模块，用于判断所收到的组播数据流的数据是否发生丢包，并控制单播收发模块进行补包；

单波收发模块，用于以单播协议向补包服务器发送补包请求，并接收补包服务器发来的补包数据；再将收到的补包数据交给丢包判断及补包控制模块与存储模块中的丢包数据进行整合。

本发明中有关技术术语的含义及内容进一步解释如下：

1.转发设备

是指在数据网络中转发、复制数据信息的设备，该转发设备可以是三层交换机、二层交换机、CDN结点服务器等设备。

2.快速存储器

是指能够快速存取数据的存储器.在当前的技术条件下，内存属于快速存储器；硬盘、光盘属于慢速存储器，闪存的速度介于两者之间，既可以当快速存储器用，也可以当慢速存储器用.不排除将来技术的发展会有新型的存储器成为快速存储器或慢速存储器.例如，现在正在研究的铁电存储器和全息存储器等.

3.主机

是指网络中的那些有能力对数据信息进行处理、复制和转发的设备，例如服务器、客户机、网络路由器、交换机等设备都可以统称为主机。

4.发送或转发组播数据的主机

在网络中提供组播数据源的主机就是发送组播的主机，例如服务器。在网路中向下一级网络路由器或客户机转发转播数据的主机就称为转发组播的主机，例如网络路由器或三层交换机。转发组播数据的代理服务器或CDN网络边缘服务器既可以称之为发送组播数据的主机，也可以称之为转发组播数据的主机。

5.约定地址的补包主机

补包主机是指在本发明中完成对接收数据的主机补包工作的主机，由于现行的组播协议没有规定对于丢包如何处理，更没有定义在哪里补包，所以在本发明中需要约定针对每个组播数据流的丢包要到哪里寻求补包数据。它可以约定是发送组播流的源服务器本身；可以约定是网络中的路由器或交换机；可以约定是CDN的边缘服务器，或是约定另外一台客户机；也不排除将来出现的某种新型硬件设备，只要它能完成响应补包请求都可以成为补包主机。

约定地址，是指对上述客户机、服务器和交换机可以固定约定或用某种规则约定用某些单播地址进行补包。由于客户机要求发送组播流的服务器或转发组播流的交换机路由器在原来的组播数据流当中对丢包错包进行补包容易造成混乱且比较困难，所以在本发明中客户机、服务器和交换机可以固定约定或用某种规则约定用某些单播地址进行补包。该地址约定包括但不限于：可以约定用某个或某些单播地址对一个或一些组播地址补包；可以约定使用服务器和客户机原有的单播地址，也可以另外约定补包地址；还可以在传输过程中根据负载临时约定补包地址；也可以约定由另外一个正在接收此数据流或已经接收到此数据的客户机给自己补包，而此提供补包服务的客户机的单播地址也就成为了补包地址。

为上述客户机、服务器和交换机提供约定地址的方式主要包括但不仅限于以下几种：

(1)在接收数据的主机内部进行设置，在接收数据端约定固定的补包地址，或按固定规则约定的补包地址，如图1a所示，一旦发现丢包，接收数据的主机直接寻找约定地址的补包主机请求补包。

(2)在动态访问网络的过程中从某负责指引的服务器动态地取得访问补包主机的地址，在实际应用中此指引服务器还可以同时指引组播地址，如图1b所示，在后面叙述的利用CDN边缘服务器补包的方式就可以使用这种补包方式。

(3)将以上两种结合，即接收数据的主机先访问固定或固定规则约定的地址的主机，从其获得所需的补包主机的地址等相关指引信息，然后再根据指引找到补包主机进行补包；

6.接收数据的主机

是指用本发明方式中接收数据的主机，它主要指的是客户机；网络中的路由器和CDN边缘服务器，如果既使用本发明方式接收数据又采用本发明的方式转发数据，则其身份既是接收数据的主机又是转发数据的主机；如果用网络中的客户机兼职完成向其他客户机补包的工作，则其身份既是接收数据的主机又是补包主机.

7.客户机

是指处于使用数据的客户一端的接收的计算机，是相对于专门提供服务的服务器计算机而言的。客户机主要包括但不仅限于台式计算机、笔记本电脑、PDA、机顶盒等设备

机顶盒因其放置于电视机的顶部而得名，但从技术角度讲其本质就是一台比较简单的计算机，但又与一般的计算机有所不同，其主要区别有两点：一是其显示接口输出不是一般的计算机显示器而是电视机；二是操作输入接口不是键盘鼠标而是遥控器。在本发明中机顶盒完全可以成为一台客户机。

8.定位标尺

是指在本发明中为了使补包主机准确地知道接收数据的主机需要哪些数据，而采用的一种能够定位和衡量数据的准确度量。该度量方式主要包括但不仅限于以下两种方式，一种是基于数据的存储方式，例如，以文件的起始点为原点，以存储的长度或偏移量为单位度量其位置和长度。另一种是直接用数据包为标尺的度量单位，数据包的标号可以借用IP包头中的序号，也可以由程序在数据包的内部数据中进行编号。如果是采用数据包作为标尺刻度，则此刻度可能是不定长的，因为，根据需要服务器可能发送不定长的数据包，例如，许多流媒体的传输其数据包就是不定长的。

本发明提出的方法可以方便地解决组播协议传输数据的可靠性的问题，这一技术的推广使用可以使组播协议可以广泛应用于网络中传输各种数据，从根本上解决困扰宽带网的“宽带无内容”问题。

附图说明

图1是本发明的数据传输过程示意图，其中图1a是在接收数据的主机内设定了补包主机的地址的数据传输过程示意图；图1b是在动态访问网络的过程中从某负责指引的服务器动态地取得访问补包主机地址的数据传输过程示意图。

图2是本发明的第一种实施例图，其中发送组播的服务器和补包服务器是同一个物理服务器。

图3是本发明的第二种实施例图，其中补包服务器位于网络边缘，专门为某一区域的客户机补包。

图4是本发明的第三种实施例图其中部分补包工作由客户机完成，每个客户机同时兼职为其他客户机补包。

图5是本发明中的第四种实施例图，其中某一级或每一级路由器都可以发现丢包并向上一级请求补包。

图6是本发明判断丢包的简化逻辑框图。

图7是本发明判断丢包的智能逻辑框图。

图8是本发明接收数据主机的功能模块图。

具体实施方式

以下结合附图对本发明作进一步详细描述。

本发明的方法如同电视系统一样分为发送方式和接收方式，两者可以分别构成独立的系统由不同的个体来分部实施，但为了便于描述和理解两者的配合，将发送方和接收方两者放到一起来描述其运作过程。

参照图1a，本发明的数据传输过程为：

(1)由发送或转发组播数据的主机向接收数据的主机发送至少一条组播数据流；

(2)在接收数据的主机内部中设定了补包主机的地址，接收组播数据流的数据，

(3)接收数据的主机在接收组播数据流的过程中不断监测是否有错包和丢包数据，在发现并接收到错包和丢包的数据后，以单播协议向补包主机发出补包请求；

(4)补包主机使用至少一个约定的单播地址，接收该补包请求，并按照该补包请求的定位标尺从存储器中找到相应的数据，以单播协议向请求补包的接收数据的主机发送补包数据；

(5)接收数据的主机将接收到的有丢包的组播数据与单播补包数据整合，使之成为完整或部分完整的数据流。

参照图1b，本发明的补包主机的地址是在动态访问网络的过程中，从某负责指引的服务器动态地取得访问补包主机地址的数据，其数据传输过程为：

(1)由接收数据的主机向指引服务器请求指引；

(2)指引服务器接收到指引请求后，向接收数据的主机发出指引信息；

(3)接收数据的主机指引服务器发送的指引信息，请求加入组播并接收组播数据流；

(4)接收数据的主机在接收组播数据流的过程中，按照图6或图7的过程不断监测是否有错包和丢包数据，在发现并接收到错包和丢包的数据后，以单播协议向补包主机发出补包请求；

(5)补包主机使用至少一个约定的单播地址，接收该补包请求，并按照该补包请求的定位标尺从存储器中找到相应的数据，以单播协议向请求补包的接收数据的主机发送补包数据；

(6)接收数据的主机将接收到的有丢包的组播数据与单播补包数据整合，使之成为完整或部分完整的数据流。

本方法主要用于传输流媒体，但由于其解决了传输的可靠性也可以用来传输其他数据。实现本发明的方法可以有多种变化形式，以下给出四种实施例，且丛最直接简单的方式逐步描述其他提高的变化方式。

实施例1

本发明的第一实施例是在数据网络中实现数据传输的基本方法，如图2所示。图2中，包括一台服务器、数台客户机和网络，其中网络包括数台路由器和交换机。服务器A向数个组播地址分别发送数个组播数据流，客户机A申请加入其中地址为224.2.2.1的组播，网络路由器应答客户机发送的请求，向客户机复制组播1中的数据流。在一般情况下如果在复制传输过程中出现丢包错包是无法修复的，客户机甚至难以发现丢包。在本方法中，客户机或路由器采用特有方式发现丢包，如果发生丢包，客户机将以单播协议向服务器发送请求数据包，请求服务器重发一个或几个数据包。服务器按客户机的请求以单播协议向客户机发送一个或几个数据包，以弥补组播丢包所丧失的数据。

接收数据的主机既可以采用像客户机这样的通用计算机的结构；也可以是向路由器这样的根据其专门功能专门设计的设备，甚至其中的模块可以是特定应用集成线路(ASCI)。但在本发明中他们必须具备这样几个模块来完成其功能：存储模块，用于存储接收到的数据；组播接收模块，用于接收组播数据；丢包判断及补包控制模块，用于判断所收到的数据是否产生丢包，并控制单播收发模块进行补包；单波收发模块，用于以单播协议向补包服务器发送补包请求并接收补包服务器发来的补包数据。在专用设备中这些功能模块可以是专门设计的模块，在通用计算机结构当中这些模块是程序通过控制通用CPU、存储器和数据传输接口来实现的，其中组播接收模块是由程序通过CPU控制网卡来构成的；存储模块是由程序通过CPU控制存储器来构成的；丢包判断及补包控制模块是由程序通过CPU控制存储器来构成的；单波收发模块是由程序通过CPU控制网卡来构成的；各功能模块执行接收数据的过程如图8所示。组播接收模块将接收到的数据存储到存储模块当中；丢包判断及补包控制模块对所接收到的数据进行判断，其中丢包判断及补包控制模块的具体操作过程可以是如图6所示的简捷的方式或图7所示的智能方式，其主要功能是能根据数据包的序号判断出丢包，能判断出数据包序号的重计及在此情况下的丢包，进一步的智能功能是在上一级传来的组播数据的数据包序号非正常排列的情况下也能准确判断出丢包，如果丢包判断及补包控制模块发现丢包则使用标尺度量丢包的位置和长度，并利用这些信息控制单播收发模块进行补包；单播收发模块向约定地址的补包主机请求补包，并在收到补包数据后将其交给丢包判断及补包控制模块；丢包判断及补包控制模块根据丢包的记录及标尺将补包数据与存于存储模块中的以组播协议收到的有丢包的数据进行整合，使之成为完整或是部分完整的数据。

这一过程看似比较简单，在单播协议传输的数据流很容易实现补包，但对于组播传输的数据流实现补包需要解决一系列问题，这也就是为什么组播协议在实际使用中一直未能实现可靠传输的原因。

本发明对于用组播传输的数据流实现补包所解决的关键技术如下：

(1)如何发现丢包？

在单播TCP协议的传输过程中是通过ACK和NACK等复杂的往复应答来实现发现丢包并补包的，但在目前的组播协议中并没有这一过程，也很难实现这一过程，所以目前的组播协议本身是不能自动发现丢包的，客户端程序或下一级路由器只是接收组播数据，但并不知道此数据是否完整。

为了解决这一问题，本发明采用在每个数据包中加入一个按升序或降续排列的序号信息，也可以考虑使用IP包头中的包序号，根据数据包顺序发现丢包，如图6所示的简化过程，当发现数据包的顺序是2、3、6时，就认为4、5号数据包被丢失。但这样在复杂的网络环境中有可能将数据在传输过程中的意外导致的数据包顺序混乱误认为丢包，在此例中，有可能在2、3、6号数据包之后5、4、7、8号数据包就传来了。所以可以作较为智能的判断，如图7所示智能过程，先将丢包计入丢包列表，等7、8号数据包甚至更多数据包传来以后，还未发现4、5号数据包时，才判定4、5号数据包被丢失。该等待时间的判断条件可以采用多种不同方式，在图7中的推迟条件是从第一个丢包开始向后推迟4个数据包，在实际应用中也可以从最后一个丢包开始计算推迟数个数据包，或其他更复杂的算法，这种智能判断对于多级传输多级补包的复杂网络来说是很重要的。

另外一个问题是数据包序号不是无限大的，所以存在一个问题就是当序号用尽时需要从头开始使用序号，即数据包序号重新开始，这时有可能产生判断的混乱，这时就需要复杂的条件判断。例如：如图7所示假设最大数据包序号是65535，客户端接到数据包的顺序是65532、65533、3、4，发现后面的数据包序号小于前面的数据包，这时就需要请求补包服务器发送从65534到最大序号65535以及从最小序号0到2，共五个数据包的数据。

还有一种技术实现方式会将上述情况变得更加复杂，如在循环重复传输数据的方法中，可能一段数据长度较短，还不到最大序号的时候就到此段的末尾了，服务器需要从头循环传输数据，此时如果不理会数据的结构，序号继续增加，则用上面的处理方法就可以解决。但如果考虑到数据的结构，希望数据与序号有所对应，则数据从头开始再次循环时需要将数据包序号也从头开始。在这种情况下客户机需要预先知道此段循环传输数据的长度，并以此判断。如果此段数据的长度较长，超出了序号范围，则需要同时结合数据包序号和此段数据的长度进行综合的判断。

另有一种特殊情况就是网络的第二层如果发现错包可能会直接将其丢弃，Ethernet网的数据链路层会对每一个数据包进行CRC效验，发现错误会将其丢弃，这种情况也被视为丢包。

(2)如何定位丢包？

对丢包数据进行定位是本发明方法需要解决的重要问题。在单播协议中，数据包在服务器和路由器当中以数据包的形式缓存部分刚发送过的数据，任何一级发现丢包都可以立刻向上一级要求补包，这是TCP/IP协议栈中已经定义的功能，这些功能都是网络中的路由器和计算机的底层IP协议栈自动来完成的。但是在本实施例中补包功能需要由客户机和服务器的软件功能来实现，这就存在一个定位的问题，即对于传输的数据需要有一种标尺的机制对其进行定位和度量，以保证服务器发给客户机的补包数据是其需要补充的，并将其与原数据整合。

一种度量方式是基于数据的存储方式，例如，以文件的起始点为原点，以存储的长度或偏移量为单位度量其位置和长度。

另一种度量方式是直接用数据包定位，即由服务器的程序控制一块缓冲区，这块缓冲区可以在硬盘上，也可以在内存中，在缓冲区中，数据的存储方式是以将要发送的数据包的形式来存储的。例如，发送组播的时候是以每1k字节内容为一个数据包的，则存储方式就是以1k字节为一个存储单元，并配合排列序号，则每个数据包的存储单元就是度量标尺的一个刻度。此存储单元也可以是不定长的，例如，以流媒体的一帧或几帧作为存储单元和度量标尺，其表尺的刻度就是不定长的。但这并不影响标尺的使用，因为这个标尺并不是用来度量数据的绝对长度，而是用来定位丢包和补包数据的，所以只要他能正确的找到补包数据就可以了。

(3)何时请求补包？

客户机发现丢包后可以立刻请求补包，也可以等一段时间，将在此时间段中发现的所有丢包一并请求补包。第一种方式适合用于对数据的及时性要求较高的情况，例如IPTV、VOD等；第二种方式适合用于对数据的及时性要求较低的情况例如下载。

(4)向谁请求补包？

在现有的单播系统中，可以直接向上一级的路由器或三层交换机请求补包，上一级路由器或交换机将丢包重传，但现有的组播协议无法完成这样的过程.为了实现数据的可靠传输，在本实施例中可以由发送组播数据流的源服务器完成补包工作.在客户端发现丢包后立刻向源服务器发送一个请求，此请求描述所丢数据包的序号，或直接根据数据的度量表尺对丢失的数据进行描述，从而使服务器知道哪台客户机缺少那些数据.

在现有的IP组播协议当中，服务器发送组播的网卡必定有一个单播地址，而且其发送的组播数据包中携带此单播地址，可以约定客户机使用此单播地址作为目标地址直接向补包服务器发送补包请求，当然也可以另外约定一个地址，甚至是另外一个主机的地址。

(5)如何识别补包请求？

在一般情况下，服务器的一块网卡可以分别向多个组播地址发送多个组播数据流，而在本发明中客户机请求补包并不是向发生了丢包的组播数据流的组播地址发送，而是向一个单播地址发送补包请求，简单的方法是每一个组播地址对应一个单播补包地址，但这样的方式要消耗很多单播地址。比较划算的方式是多个组播地址对应一个单播地址，这样就存在一个如何识别客户机到底是需要补的是哪一个组播数据流的数据，在实际应用当中可以考虑约定服务器发送组播数据流时使用不同的端口号，服务器补包服务也是约定用单播地址的不同端口，这些端口与组播数据流的端口一一对应，服务器就可以识别客户需要补包的数据流了。例如：服务器发送三个组播数据流，地址分别是224.2.2.1:4001、224.2.2.2:4002、224.2.2.3:4003，服务器网卡的单播地址是192.168.2.2，这样就可以“约定”凡是客户机在接收组播地址224.2.2.3:4003的数据流的过程中发现的丢包，一律向服务器的单播地址192.168.2.2:4003发送补包请求。而服务器根据约定，一旦从4003号端口收到补包请求，就理解为客户机需要对224.2.2.3的数据流进行补包。

另外一种更安全的方式是客户机的补包请求中直接按照某种格式描述要补某个组播地址的数据流的某几个数据包，这样服务器不用开多个端口对应多个组播地址，其优点是服务器所开的端口少，从而使服务器更安全。

(6)如何发送补包？

服务器响应客户机请求向其发送补包可以直接根据客户机请求补包的数据包的源地址向其发送补包数据。当然如果客户机具有多个单播地址，并且其要求服务器向客户机的另一个地址发送补包数据，也可以按其要求发送。

(7)如何应对大量丢包的情况？

在网络中可能会存在个别线路状况极差的情况，其接收端有可能发现丢失大量的数据包需要重发，这样可能会对发送补包数据的一端产生极大的压力。对于这种状况数据发送端可以对于这样的接收端拒绝服务；也可以在接收端的软件中设置一个极限值，如果丢包率超过某一值便不再请求补包。

通过采用以上技术关键，就可以在现行的网络环境和组播协议的条件下顺利地实现对组播数据流进行补包，实现数据的可靠传输。但是如果只用上述的基本方式，在大规模网络的环境下还不够完美，处理效率还不够高，所以还可以采用或综合运用如下几种改进方式来提高效率。

由于在本发明当中规定对组播数据进行补包，所以对于服务器的内存缓冲可以进行与一般组播方式不同的处理来提高补包的效率和速度。现行的组播协议由于不存在补包，所以现行的程序和操作系统将发送过的组播数据立即将其清除出内存缓冲区。

在本发明中，服务器可以建立一个共用的快速存储器缓冲区，在目前的技术条件下，快速存储器主要是指内存RAM，主要包括DDR RAM、ECC RAM等，将来可能会有更好的快速存储器而且可以在网卡上建立专门的存储硬件用于缓冲，在本实施例中，为了便于理解我们暂时仍然称其为内存缓冲或缓冲区。通常的组播程序将一个组播数据包发送出去以后立即将其清除，但在本发明中此共用的内存缓冲区既用于发送组播流也用于单播补包，所以此内存缓冲区中的数据在通过组播发送出去以后并不立即清除，而是在内存缓冲区保持一段时间，如果在此期间客户机请求补包，服务器立刻从内存缓冲当中读取相应的数据并以单播形式发送给发请求的客户机。

有一种情况可能导致缓冲区补包失败，由于缓存不可能无限大，需要不断用新数据替代旧数据，所以当发生一长段连续丢包时，有可能会出现的一种特殊情况，就是接收数据的主机发送的补包请求到达服务器时，这一长段丢包数据的前面部分已经被新数据更新了，解决方式包括但不仅限于以下两种方式：

1.在服务器端进行判断，当出现这种超长补包请求时，对于其中的全部或部分数据定向到慢速存储器既硬盘中读取

2.当组播数据流是比较稳定带宽的码流时可以在接收数据的主机一端进行丢包推测，例如正常情况下每100毫秒会传来10个数据包，但发现已经连续200毫秒没有收到数据包了，这时虽然后续数据包没有传来无法断定丢包，但可以推测发生丢包了，接收数据的主机就可以认为是发现丢包并请求补包。这样可以避免当后续数据包传来、可以判定丢包时，实际上已经丢失了大量的数据包的情况发生。

这种改进方式的优点是提高了补包的效率，同时也提高了服务器的补包能力。现行的流媒体服务器系统的瓶颈在于其磁盘或磁盘阵列的读取速度，而CPU处理能力和内存空间往往有富裕，所以通过这一改进减少了磁盘的负担，提高了服务器的整体能力，使得一个服务器或服务器群组能够至少为一个目前的宽带城域网提供补包服务，保障城域网范围内利用组播传输可靠数据。

实施例2

本发明的第二实施例是对上述实施例1的改进，如图3所示。由于在客户数量巨大的网络环境下，用单播协议的补包服务器的负载往往是很重的，在此例中虽然单播只是用于补包，而绝大部分数据流都是由组播传输的，但这也是一个巨大的负载，特别是当网络环境比较差丢包比较严重的时候。为了解决这个问题可以让补包服务专门由一个或几个服务器来完成，这几台服务器甚至可以分布在网络的不同位置。单播补包服务器的布放位置可以借鉴现在常用的CDN(Content distribution network或Content deliverynetwork的缩写)和任播的方式，将补包的负载分散到网络的边缘，由那些较靠近客户机的服务器完成，其优点是补包反应快，对网络主干的压力小。这种方式就需要改进客户机和网络的寻找、定位补包服务器的方式。

一种方式是任播方式，客户机还是按照组播源服务器的单播地址寻求补包，但是由网络设备自动将某一区域的请求重定位到另一个距离客户较近的服务器，“约定”哪些区域的请求重定位发送到哪个服务器是在网络设备当中进行设置的。

另一种方式是直接让客户机向另外一个“约定地址”的服务器寻求补包服务，可以用多种技术来实现这种方式，可以规定客户机的程序必须先向主服务器询问可以向哪一个或那些服务器寻求补包，服务器可以根据客户机的地址所属区域指示其向哪一个或那些服务器寻求补包，或者给客户机发送一个列表，由客户机自主判断向哪一个或那些服务器寻求补包；

也可以在客户机与源服务器建立连接或要求补包时服务器指示客户机到某个约定的服务器补包；还可以借鉴DNS的方式，在每个区域设置一个指示服务器，各地区的客户机软件都需要手工或自动设置本地区指引务器的地址，向此服务器要求补包或询问可以向哪一个或哪些服务器寻求补包。

在这种方式中，在物理上是多台服务器组成一个服务器群组共同协作完成组播的发送和补包，但可以在逻辑上将他们视为一个服务器。

实施例3

本发明的第三实施例是对实施1的另一种改进，如图4所示。本例是在补包方式上借鉴P2P的方式，现行的P2P传输的方式是将所有的信息都由客户机之间相互传输，服务器只提供一些指引，例如BT。这样做的结果就是每个客户机都要向一个或多个客户服务，有时向别人提供服务的带宽比自己接收数据的带宽还要大，这对网络主干和客户机来说负载太大。在本发明的此改进方式中，主要数据还是通过服务器发送的组播来传输的，只有部分缺失的数据才通过客户机之间的相互服务来补充。要实现这种方式，需要在服务器中维护一个列表，此列表表明哪些客户机正在或已经接收过哪些组播数据，当一个客户机开始接收某个组播时通知服务器，服务器将几个同样接收此组播数据的客户机“伙伴”的单播地址通告此客户机，同时也会将它作为一个伙伴记录通知其他伙伴。当此客户机发现丢包或数据缺失时可以向其“伙伴”请求补充数据，由另一个或几个作为其伙伴的客户机向其发送缺失的数据，也就是说由另一台客户机兼职完成原本应由补包服务器来完成的工作。同样的，此客户机也能向其他客户机提供补包服务。

在此方式中，如果是网络的核心交换机丢包，将会导致大面积的的客户丢失相同的数据包，客户机将难以相互补包。但是在实际网络环境当中，网络主干的服务质量比较容易保障，网络的客户接入端特别是“最后一公里”的服务质量难以保障，所以此方式在实际环境当中还是有实用价值的。对于个别的大面积客户丢失相同数据包的情况可以用服务器或网络交换机另行补包。

在这种方式中，在物理上是服务器和多台客户机组成一个服务器群组共同协作完成组播的发送和补包，但可以在逻辑上将客户机中兼职为别人服务的那部分视为服务器的一部分。

实施例4

本发明的第四实施例是对上述实施例1、实施例2、实施例3的改进。由于以上几种实施例的方式无论是用服务器还是用客户机兼职，都是用计算机进行补包的，这种补包方式容易实施，但靠计算机的软件来实现的结果就是效率比较低，而且反应速度都比较慢。在单播TCP协议中，补包的工作是由上一级的路由器来实现的，其处理效率和反应速度都很快。所以可以考虑将补包的工作交由路由器或三层交换机来实现，如图5所示。此方式可以在多级路由的大型网络中实现类似单播协议的逐级补包，但如果要路由器或三层交换机来实现此功能，需要对其内置软件、操作系统甚至是硬件作较大的改动。

较为简单的实现方式是直接将上述的由服务器完成的工作交由路由器来实现，但这就要求路由器不仅具有OSI七层协议的三层以内的功能，还必须具有第四层甚至更高层的功能，因为它不仅需要查看IP包头的信息还必须打开IP数据包，查看其中的内容才能得知客户机的丢包情况，幸好现在的技术实现四层交换，甚至更高层的功能并不困难.

比较复杂但处理效率更高的处理方法是直接在IP包头中体现客户机的补包要求，这需要对现有的IP协议栈进行一定的修改，首先在IP数据包头中要有标志位表示客户机的此数据包是一个请求补包的请求数据包，路由器通过此标志位区分补包请求和其他信息数据包，然后路由器就可以将此信息提出来另做处理了，至于客户机或下一级路由器需要针对哪一个组播流进行补包、需要补多少则可以在包头中描述也可以在数据包内进行描述。对于客户机需要对哪一个组播流进行补包还可以采用前面所述的用端口号对应的方式来识别。

如果每一级路由器能用此改进方式所述传输组播，在网络中就可以实现逐级补包，在网络中的每一级路由器都实行对组播的可靠传输，而不是像前三种改进方式那样需要组播数据一直传到接收数据的客户端以后才能发现丢包。但在这种方式中，每一台路由器既是接收数据的主机又是发送数据的主机，这就涉及到它如何处理已经收到的组播和补包数据并向下一级主机传输。该传输包括但不局限于以下方式：

1.将那些用单播协议补到的数据包重新加入到组播数据流中向下一级主机复制转发。但这样有可能会打乱原来的数据包顺序，无论下一级主机是客户机还是另一台路由器，混乱的数据包顺序都会对下一级主机的丢包判断和补包造成困扰。对于这样的情况可以有两种处理方式：

a.不管数据包的顺序，将补到的数据包不顾其原有顺序直接整合到原来的组播数据流当中向下一级传输，由于上一级的补包需要一个时间过程，这样在本级主机发向下一级主机的组播数据流中通过补包补回来的数据包就会落后于正常的数据包顺序，下一级主机有可能在此落后于正常顺序的数据包还未到达时就误判此数据包丢失。这样就需要各级主机对于丢包的判断采用较为灵活智能的方式，例如，像前面“如何发现丢包”所述的那样。

b.每一级主机收到组播后并不立即复制转发，而是等待一定时间，这段时间足够本主机发现丢保、请求补包、并得到上一级主机的补包，将补到的数据包按原有顺序整合到原来的组播数据流当中向下一级传输。

2.本级主机将那些用单播协议从上一级主机补到的数据包放到缓存中，而不将其补充到原来的组播数据流中，但是其面临的一个问题就是其下一级主机也会发现这些数据包丢失了，当然也会发现一些在本级主机向下一级传输中新增的丢包，这时本级主机可以对于这两种情况的丢包都用单播协议对下一级主机进行补包。

通过运用上述的几种方式就可以在一个中小规模的城域网范围内利用组播向大量用户提供可靠的数据，如果再综合运用基本方式和几种改进方式，就有条件在几乎整个Internet上全网运用组播协议传输可靠数据。

本发明的效果可以通过仿真测试予以证明。

仿真环境1

网络环境是华为的S3526三层交换机和S2026Z二层交换机，测试期间有其他正常的单播网络通讯，服务器为P4 2.8G/1G RAM，客户机为P3 1G/256 RAM笔记本。

本仿真作出了在两组不同环境下的传输效果测试统计，其中第一组是在正常校园网环境下的传输效果统计，如表1所示.第二组是专门使用很差但单播能Ping通的网线模拟恶劣环境下的传输效果统计，如表2所示.

表1正常校园网环境下传输效果统计表

组播流带宽	700K	1M	1.5M	2M	6M
						组播流丢包率(1/10000)	0.281	0.249	0.316	0.292	1.429
单播补包成功率	100％	100％	100％	100％	99.98％

表2模拟恶劣的实际环境下传输效果统计表

组播流带宽	700K	1M	1.5M	2M	6M
						组播流丢包率(1/10000)	12.5	31.7	18.5	27.3	183.8
单播补包成功率	100％	100％	100％	100％	98.21％

说明：在表1、2中的6M码流时，组播丢包率骤升及补包率未能达到100％是因为客户机的配置较低。

仿真环境2

网络环境：港湾的BIG HAMMER6808三层交换机和Hammer24E二层交换机，测试期间有其他正常的单播网络通讯，服务器为P42.8G/1G RAM，客户机为P42.8G/256 RAM台式机。

本仿真也作出了在两组不同环境下的传输效果测试统计，其中第一组是在正常校园网环境下的传输效果统计，如表3所示。第二组是专门使用很差但单播能Ping通的网线模拟恶劣环境下的传输效果统计，如表4所示。

表3正常校园网环境下传输效果统计表：

组播流带宽	700K	1M	1.5M	2M	6M
						组播流丢包率(1/10000)	0.319	0.592	0.427	0.491	2.112
单播补包成功率	100％	100％	100％	100％	100％

表4模拟恶劣的实际环境下传输效果统计表

组播流带宽	700K	1M	1.5M	2M	6M
						组播流丢包率(1/10000)	21.4	41.6	29.7	126.7	44.8

组播流带宽	700K	1M	1.5M	2M	6M
						单播补包成功率	100％	100％	100％	100％	100％

从上述表1、表2、表3、表4的几组测试数据可得出以下结论：

1.网络环境恶劣会导致组播丢包率上升。

2.网络环境恶劣不会导致单播补包成功率下降，几乎对单播补包毫无影响。

3.本方法对于组播丢包的识别和补包率几乎达到100％。

4.在大流量的情况下，客户机性能对补包成功率有影响。

5.补包服务器负载很低，一台服务器可以轻易承担向数万台客户机补包的工作。

Claims (9)

1.一种用组播和单播协议可靠传送数据的方法，采用单播协议对组播数据流的丢包进行补包，其过程如下：

(1)由发送组播数据的主机发送至少一条组播数据流；

(2)约定地址的补包主机使用至少一个约定的单播地址接收来自接收数据的主机的补包请求；所述的约定地址的补包主机是专门负责补包的服务器、或另外一个正在接收此数据流或已经接收到此数据流的客户机；

(3)约定地址的补包主机识别补包请求所要求的补包所在的组播流，并按照请求的定位标尺从存储器中找到相应的数据；

(4)约定地址的补包主机找到相应的数据后，以单播协议向请求补包的接收数据的主机发送补包数据。

2.根据权利要求1所述的传送数据的方法，约定该补包主机的地址的方式有以下几种：

a.在接收数据的主机内部按固定规则约定补包地址；

b.在动态访问网络的过程中从某负责指引的服务器动态地取得访问补包主机的地址；

c.接收数据的主机先访问按固定规则约定的地址的主机，获得所需的补包主机的地址的相关指引信息，再根据指引信息找到补包主机进行补包。

3.根据权利要求2所述的传送数据的方法，固定规则是约定固定地址。

4.根据权利要求1-3中任一项所述传送数据的方法，其中由一台客户机兼职作为所述补包主机来完成补包任务，且需要在发送组播数据的服务器中维护一个列表，该列表记载有客户机正在或已经接收过的组播数据，当一个客户机A开始接收某个组播时通知发送组播数据的服务器，发送组播数据的服务器将一个或几个正接收或已经接收过相同组播数据的客户机“伙伴”的单播地址通告此客户机A，并将客户机A作为一个伙伴记录通知其他伙伴，当此客户机A发现数据缺失时向客户机A的客户机“伙伴”请求补充数据，由另一个或几个作为客户机A的伙伴的客户机向其发送缺失的数据。

5.根据权利要求1所述的传送数据的方法，其中所述的定位标尺主要有两种度量方式：一种是基于数据的存储方式，是以文件的起始点为原点，以存储的长度或偏移量为单位度量其位置和长度；另一种是直接用数据包作为标尺的度量单位，是将每个数据包的存储单元作为度量标尺的一个刻度，数据包的标号借用IP包头中的序号，或由程序在数据包的内部数据中进行编号。

6.一种与权利要求1所述的可靠传送数据的方法相对应的接收数据方法，其过程如下：

(1)接收数据的主机加入至少一个组播组，接收组播数据流的数据；

(2)接收数据的主机在接收组播数据流的过程中，不断监测是否有丢包；

(3)接收数据的主机发现丢包后，以单播协议向约定地址的补包主机发出补包请求；所述的约定地址的补包主机是专门负责补包的主机、或另外一个正在接收此组播数据流或已经接收到此组播数据流的客户机；

(4)接收数据的主机将接收到的有丢包的组播数据与单播补包数据进行整合，形成完整或部分完整的数据。

7.根据权利要求6所述的接收数据的方法，其中所述的接收数据的主机是专门负责补包的约定地址的补包主机，该补包主机将接收到的数据用于向其他客户机提供补包数据。

8.根据权利要求6或7所述的接收数据的方法，其中所述的接收数据的主机在接收组播数据流的过程中不断监测是否有丢包，其监测方式有如下几种：

(1)接收数据的主机不断监测位于数据包头或数据包中的数据包序号，按数据包顺序判断是否丢包，一旦发现丢包立刻请求补包；

(2)接收数据的主机不断监测位于数据包头或数据包中的数据包序号，按数据包顺序判断是否丢包，一旦发现丢包立刻计入丢包列表，按照某种延迟规则等待后再请求补包，在延迟等待过程中不断监测后续传来的数据包，如果发现有丢包列表中记录的数据包，则将此记录删除。

9.一种实现用组播和单播协议可靠接收数据的接收主机，包括：

存储模块，用于存储接收到的数据；

组播接收模块，用于接收组播数据流的数据，并将接收到的这些数据存储到存储模块中；

丢包判断及补包控制模块，用于根据所接收到的组播数据包的顺序判断所收到的组播数据流的数据是否产生丢包，并控制单播收发模块进行补包；

单播收发模块，用于在丢包判断及补包控制模块发现有丢包情况的发生后，以单播协议向约定地址的补包主机发送补包请求，并接收约定地址的补包主机发来的补包数据；再将收到的补包数据交给丢包判断及补包控制模块，丢包判断及补包控制模块将收到的补包数据与存储模块中的有丢包的数据进行整合，所述的约定地址的补包主机是专门负责补包的一个或几个服务器、或另外一个正在接收此数据流或已经接收到此数据流的客户机。

Images