CN101237339B - 基于分层点对点组播网络的流媒体传输方法 - Google Patents

Abstract

基于分层点对点组播网络的流媒体传输方法，涉及一种流媒体传输服务，尤其涉及一种使用分层点对点组播技术进行流媒体传输的装置及传输方法。本发明包括以下步骤：步骤1：服务器端利用改进型用户数据报协议发送媒体数据到网关/路由器，服务器端完成各客户端的组号分配工作；步骤2：网关/路由器将上述媒体数据转发到各个客户端；步骤3：各个客户端利用改进型用户数据报协议协议分别接收上述来自网关/路由器的媒体数据，各个客户端使用缓存机制完成本客户端的正常接收和解码以及同组客户端数据的弥补工作。本发明实现了传输性能好、传输数据可靠性高、受控性好的目的。

Description

基于分层点对点组播网络的流媒体传输方法

技术领域

本发明涉及一种流媒体传输服务，尤其涉及一种使用分层点对点组播技术进行流媒体传输的装置及传输方法。

背景技术

近年来，随着计算机技术、数据压缩技术以及网络技术的日益成熟，流媒体业务得到了迅猛的发展。在传统的条件下，用户如果需要收看一个节目或者是一个视频的话，可能的方法是先将需要的节目从网上下载下来并保存到本地计算机上，然后通过播放本地文件来欣赏节目。这样的处理流程使得用户不得不花费较长的时间等待节目下载完毕，事实上这段时间往往是很恼人的。流媒体技术提出了一个边下载边播放的模式，即如果网络速度够快的话，完全可以先期播放预先到达的节目而无需等待所有节目下载完毕。

随着整个技术体系的发展，流媒体领域将组播技术引入到了应用的范围，如此则大大减少了服务器端的负担，同时最大限度地节省了带宽。此外，一些新兴的网络传输技术比如说点对点也逐步进入到这个领域当中。

但是组播由于采用用户数据报协议(User Datagram Protocol，以下简称为UDP)进行传输，因此在数据可靠性方面表现得并不是非常出色，而点对点由于流量区分等相关技术的滞后，在受控性方面的表现则不是非常尽如人意。传统的UDP协议在网络拥塞时容易出现数据的丢失，这样就会影响到用户的视觉体验。

发明内容

技术问题：本发明目的是提供一种传输性能好、传输数据可靠性高、受控性好的基于分层点对点组播网络的流媒体传输方法。

技术方案：本发明的基于分层点对点组播网络的流媒体传输方法包括以下步骤：

步骤1：服务器端利用改进型用户数据报协议发送媒体数据到网关/路由器，并根据各个客户端资源能力的不同将客户端分配到不同的组当中去，同时服务器端完成各客户端的组号分配工作；

步骤2：网关/路由器将上述媒体数据转发到各个客户端；

步骤3：各个客户端利用改进型用户数据报协议协议分别接收上述来自网关/路由器的媒体数据，各个客户端使用缓存机制完成本客户端的正常接收和解码以及同组客户端数据的弥补工作，客户端在工作时使用接收缓存、净数据缓存、工作缓存和解码缓存完成正常接收和解码，并启用点对点数据发射缓存和点对点数据接收缓存；上述点对点数据发射缓存用于为同组用户保留弥补数据，上述点对点数据接收缓存用于接收同组用户提供的弥补数据；客户端如果发生数据的缺失就会向同组用户发送数据的请求，同组用户查询本地的点对点数据发射缓存，即同组用户保留的缓存，如果存在该份数据，将通过组号进行寻址并将缺失数据发送给该客户端以完成数据的弥补工作；

当其中一个客户端在接收上述媒体数据时，若发现其接收的数据丢失，则向同组用户发送点对点数据请求；若未发现其接收的数据丢失，则不向同组用户发送点对点数据请求；

当其中一个客户端在接收上述媒体数据时，若发现同组用户存在属于这个客户端的弥补数据，则予以接收；若未发现同组用户存在属于这个客户端的弥补数据，则继续监测；

当其中一个客户端在接收上述媒体数据时，若发现同组用户发送的点对点数据请求，则根据这个客户端接收弥补数据的能力自主决定是否发射弥补数据；若未发现同组用户发送的点对点数据请求，则继续监测。

比较好的是：上述步骤1中服务器端发送媒体数据到网关/路由器的具体工作过程如下：

步骤11：启动服务器；

步骤12：服务器向组播地址发送媒体数据；

步骤13：服务器对自身的媒体数据进行监测，若判断为不存在媒体数据则关闭服务器，若判断为存在媒体数据则侦测是否存在客户端连接；

步骤14：对上述步骤13的是否存在客户端连接的侦测结果进行判断，若判断为有则服务器端接受连接并为客户端分配组号，若判断为否则直接返回执行步骤13。

比较好的是：上述步骤3中的各个客户端分别接收上述来自网关/路由器的数据的具体工作过程如下：

步骤31：启动客户端；

步骤32：连接服务器并发送用户信息，同时获得本机组号，并在后台循环检测是否存在点对点数据请求，若判断存在点对点数据请求，则检测请求的数据号，此时存在上述数据号则发射点对点数据，不存在上述数据号则返回后台循环检测点对点数据请求；若判断不存在点对点数据请求，则返回后台循环检测点对点数据请求；

步骤33：接收服务器发送的媒体数据；

步骤34：将上述接收的媒体数据填充到本客户端的接收缓存，同时本客户端填充点对点数据发射缓存；所述接收缓存用于接收和暂存从服务器端通过网络组播传到客户端的数据，接收到的数据是按照主数据报文格式进行组织；

步骤35：本客户端填充净数据缓存，用于存放已经剥离主数据报文的纯应用层数据；

步骤36：对上述步骤35本客户端填充的净数据缓存判断是否缺失，若判断为是，则向同组用户发送点对点数据请求，并设置超时，本客户端等待超时或接收同组用户的点对点数据，当本客户接收到同组用户的点对点数据后，本客户端填充点对点数据发射缓存，执行步骤37；若判断为否，则返回步骤35；

步骤37：初始化本客户端的工作缓存；所述工作缓存是解码器直接接触的一个缓存，所述工作缓存设置在解码器和净数据缓存之间；

步骤38：通过解码器解码；将从工作缓存得到的数据输入解码器，利用解码器内部的缓存对解码器内部数据解码。

步骤39：判断本客户端是否需要填充工作缓存，若判断为是则进一步填充工作缓存，若判断为否则返回步骤38。

比较好的是：上述步骤36还包括：

步骤361：对客户端等待超时的结果进行判断，若判断为超时，则执行步骤35，若判断为否则返回继续对是否超时进行判断；

步骤362：对客户端接收到点对点数据的结果进行判断，若判断为接收到点对点数据后客户端再次填充点对点数据发射缓存，执行步骤35；若判断为否，则返回继续接收点对点数据。

比较好的是：上述改进型用户数据报协议采用两种报文格式：主数据报文和邻居互连报文；主数据报文主要用于客户端确认数据的丢失，以启动客户端的点对点弥补机制，主数据报文格式包括一个数据包号字段，代表本次数据报文的数据包号；邻居互连报文用于弥补数据寻址，使得弥补数据可以正确地寻址到发生数据丢失的客户端，邻居互连报文格式包括一个组号字段，用于数据的寻址，一个报文类型字段，用于区分命令和数据，一个可选字段，一个应用层数据字段，含有应用层数据；

有益效果：本发明采用上述技术方案，与现有技术相比具有如下优点：

(1)本发明的传输数据装置是通过对传统TCP/IP五层结构体系协议的改造，在应用层和传输层之间增加一个覆盖网络层，该层定义了一个虚拟的组网架构和一个用户数据报协议；在用户数据报协议的支持下，虚拟组网架构可通过点对点的机制来弥补组播过程中数据的损失。结构简单，节约在改造过程中的成本。

(2)本发明的服务器端和客户端之间、客户端和客户端之间数据的传递将分别按照改进型用户数据报协议(Modified User Datagram Protocol，以下简称为MUDP)定义的主数据报文(Main Data Protocol，以下简称为MDP)和邻居互连报文(Neighbor InterlinkProtocol，以下简称为NIP)的报文格式进行封装。提高了数据在传输时的可靠性。

(3)本发明在工作时，多次对数据是否存在缺失进行判断，使得缺失的数据能够及时得到补偿，增强了数据传输的可靠性和稳定性。

(4)本发明的客户端在启动之后首先会连接服务器并将自身的资源状况汇报给服务器，以便服务器为其分配一个合适的组；分配的原则在于将综合资源能力较强的客户端平均分配到各个点对点组当中，并通过“M+N”缓存机制进行数据的接收和弥补工作。增强了网络的适应性和健壮性。

附图说明

图1是本发明协议栈的体系结构示意图；

图2是本发明改进型用户数据报协议中主数据报文MDP的格式示意图；

图3是本发明改进型用户数据报协议中邻居互连报文NIP的格式示意图；

图4是本发明传输方法的流程图；

图5是本发明服务器端流程图；

图6是本发明客户端流程图；

图7是本发明缓存机制示意图。

具体实施方式

如图4，本发明的基于分层点对点组播网络的流媒体传输方法包括以下步骤：

步骤1：服务器端利用改进型用户数据报协议发送媒体数据到网关/路由器，并根据各个客户端资源能力的不同将客户端分配到不同的组当中去，同时服务器端完成各客户端的组号分配工作；

步骤2：网关/路由器将上述媒体数据转发到各个客户端；

步骤3：各个客户端利用改进型用户数据报协议协议分别接收上述来自网关/路由器的媒体数据，各个客户端使用缓存机制完成本客户端的正常接收和解码以及同组客户端数据的弥补工作，客户端在工作时使用接收缓存、净数据缓存、工作缓存和解码缓存完成正常接收和解码，并启用点对点数据发射缓存和点对点数据接收缓存；上述点对点数据发射缓存用于为同组用户保留弥补数据，上述点对点数据接收缓存用于接收同组用户提供的弥补数据；客户端如果发生数据的缺失就会向同组用户发送数据的请求，同组用户查询本地的点对点数据发射缓存，即同组用户保留的缓存，如果存在该份数据，将通过组号进行寻址并将缺失数据发送给该客户端以完成数据的弥补工作；

当其中一个客户端在接收上述媒体数据时，若发现其接收的数据丢失，则向同组用户发送点对点数据请求；若未发现其接收的数据丢失，则不向同组用户发送点对点数据请求；

当其中一个客户端在接收上述媒体数据时，若发现同组用户存在属于这个客户端的弥补数据，则予以接收；若未发现同组用户存在属于这个客户端的弥补数据，则继续监测；

当其中一个客户端在接收上述媒体数据时，若发现同组用户发送的点对点数据请求，则根据这个客户端接收弥补数据的能力自主决定是否发射弥补数据；若未发现同组用户发送的点对点数据请求，则继续监测。

比较好的是：上述步骤1冲服务器端发送媒体数据到网关/路由器的具体工作过程如下：

步骤11：启动服务器；

步骤12：服务器向组播地址发送媒体数据；

步骤13：服务器对自身的媒体数据进行监测，若判断为不存在媒体数据则关闭服务器，若判断为存在媒体数据则侦测是否存在客户端连接；

步骤14：对上述步骤13的是否存在客户端连接的侦测结果进行判断，若判断为有则服务器端接受连接并为客户端分配组号，若判断为否则直接返回执行步骤13。

比较好的是：上述步骤3中的各个客户端分别接收上述来自网关/路由器的数据的具体工作过程如下：

步骤31：启动客户端；

步骤32：连接服务器并发送用户信息，同时获得本机组号，并在后台循环检测是否存在点对点数据请求，若判断存在点对点数据请求，则检测请求的数据号，此时存在上述数据号则发射点对点数据，不存在上述数据号则返回后台循环检测点对点数据请求；若判断不存在点对点数据请求，则返回后台循环检测点对点数据请求；

步骤33：接收服务器发送的媒体数据；

步骤34：将上述接收的媒体数据填充到本客户端的接收缓存，同时本客户端填充点对点数据发射缓存；所述接收缓存用于接收和暂存从服务器端通过网络组播传到客户端的数据，接收到的数据是按照主数据报文格式进行组织；

步骤35：本客户端填充净数据缓存，用于存放已经剥离主数据报文的纯应用层数据；

步骤36：对上述步骤35本客户端填充的净数据缓存判断是否缺失，若判断为是，则向同组用户发送点对点数据请求，并设置超时，本客户端等待超时或接收同组用户的点对点数据，当本客户接收到同组用户的点对点数据后，本客户端填充点对点数据发射缓存，执行步骤37；若判断为否，则返回步骤35；

步骤37：初始化本客户端的工作缓存；所述工作缓存是解码器直接接触的一个缓存，所述工作缓存设置在解码器和净数据缓存之间；

步骤38：通过解码器解码；将从工作缓存得到的数据输入解码器，利用解码器内部的缓存对解码器内部数据解码。

步骤39：判断本客户端是否需要填充工作缓存，若判断为是则进一步填充工作缓存，若判断为否则返回步骤38。

比较好的是：上述步骤36还包括：

步骤361：对客户端等待超时的结果进行判断，若判断为超时，则执行步骤35，若判断为否则返回继续对是否超时进行判断；

步骤362：对客户端接收到点对点数据的结果进行判断，若判断为接收到点对点数据后客户端再次填充点对点数据发射缓存，执行步骤35；若判断为否，则返回继续接收点对点数据。

上述改进型用户数据报协议采用两种报文格式：主数据报文和邻居互连报文；主数据报文主要用于客户端确认数据的丢失，以启动客户端的点对点弥补机制，主数据报文格式包括一个数据包号字段，代表本次数据报文的数据包号；邻居互连报文用于弥补数据寻址，使得弥补数据可以正确地寻址到发生数据丢失的客户端，邻居互连报文格式包括一个组号字段，用于数据的寻址，一个报文类型字段，用于区分命令和数据，一个可选字段，一个应用层数据字段，含有应用层数据；

下面结合附图对本发明进行详细说明：本发明的实施首先基于对传统TCP/IP五层结构体系协议的改造，在应用层和传输层之间新增了一个覆盖网络层，如图1，覆盖网络层用于支持流媒体的传输，其间定义了一个虚拟的组网架构和一个用户数据报协议，如图2；其次在于服务器端和客户端两个部分，服务器端和客户端之间、客户端和客户端之间数据的传递将分别按照改进型用户数据报协议协议定义的MDP和NIP的报文格式进行封装。

如图2，主数据报文中含有一个数据包号字段，占16个比特，代表本次数据报文的数据包号。采用16比特意味着包号的起至范围为0～65535，而接下来的包号将又从0开始不断增加，换句话说包号是以65536为模不断累加的。事实上，包号范围的限定并不一定在于0～65535(数据报号字段的比特数不限定于16比特)，任何一个适当的范围只要不至于影响正常的接收均是可行的。而应用层数据主要是指服务器待传输的数据。

如图3，邻居互连报文中总计有4个字段，各字段的定义和具体解释如下：

组号：这个6比特的无符号二进制数代表发出点对点数据请求的那个客户端在整个点对点组中的组号；

报文类型：这两个比特代表邻居互连报文的类型，具体赋值如下：

00：代表点对点请求命令报文；

01：代表点对点数据报文；

10和11：保留。

可选字段：这个16或32比特无符号二进制数的格式将视报文的具体类型而定；

若报文类型为点对点请求命令报文，则该可选字段中将包含两个子字段，分别为起始包号字段和结束包号字段，各占16比特，总计32个比特。它们代表请求的点对点数据中第一个和最后一个包号，之间的数据包号是连续的；

若报文类型为点对点数据报文，则该可选字段仅含有一个子字段，即数据包号，占16比特，代表本次数据报文(弥补数据)的数据包号。

应用层数据：当报文类型为点对点请求命令报文时，应用层数据为空；当报文类型为点对点数据报文时，应用层数据即弥补数据。

使用分层点对点组播网络进行流媒体传输的具体实施方法在以下实施例中将予以具体解释。

(a)服务器端

如图3，服务器在启动之后会按照MDP报文的格式对服务器端数据进行封装并立刻发送组播数据，同时在后台循环侦测客户连接；如果接收到一个新的客户链接，服务器会把该客户分配到一个合适的点对点组当中，并为该客户分配一个本组唯一的组号。

(b)客户端

参看图6，客户端在启动之后首先会连接服务器并将自身的资源状况汇报给服务器，以便服务器为其分配一个合适的组；分配的原则在于将综合资源能力较强的客户端平均分配到各个点对点组当中，并通过“M+N”缓存机制进行数据的接收和弥补工作。在本实施例中，采用了“4+2”的缓存机制，但是本发明中，M和N的取值并不限定于4和2。参看图7，这里所使用的M个缓存分别为接收缓存、净数据缓存、工作缓存和解码缓存，所使用的N个缓存为点对点数据发射缓存和点对点数据接收缓存。

(1)接收缓存：用于接收和暂存从服务器端通过网络组播传到接收端的数据，接收到的数据是按照MDP报文格式进行组织的。

(2)净数据缓存：用于存放已经剥离MDP格式的纯应用层数据。

(3)工作缓存：它是解码器直接接触的一个缓存，由于在解码器解码的过程中，某一阶段需要多少的数据参与解码的过程完全是由解码器内部自行决定的，这也就意味着解码器的直接接触缓存必须能够提供任意大小的一段数据。考虑到净数据缓存为了可以动态存储尽可能多的数据而很有可能采用链表进行存储，结果是其每次提供的数据必然与链表每个节点的数据量有关。这样就不能满足解码器直接接触缓存的基本要求，因此必须在解码器和净数据缓存之间加置一个工作缓存。由于相对于接收缓存而言，工作缓存一般设计地较小，所以从净数据缓存提取数据的过程是完全受控于解码器的。

(4)解码缓存：解码器内部的缓存，用于解码器内部数据的解码。从工作缓存得到的数据将首先进入解码器的这一部件。

(5)点对点数据发射缓存：用于为同组节点提供点对点数据。考虑到接收缓存的易变性，必须提供一个缓存具有一定的稳定性，以为同组节点提供补偿数据。

(6)点对点数据接收缓存：用于从同组节点接收点对点数据，接收到的数据将马上进入净数据缓存进行重整，以备工作缓存调用。

接收端在接收到组播数据之后将其置入接收缓存中，此时的数据是按照MDP报文的格式进行封装的。接下来，接收端将通过MDP报文中的数据包号字段判断接收端是否出现了数据的丢失：

1、如果包号与上一个正确接收的包号连续，则意味着传输过程中没有出现数据包的丢失；接收端将把这份数据存入点对点数据发射缓存以备其他客户端使用，并且在净数据缓存中剥离MDP报文的报头，随后填充工作缓存；解码缓存将自主地从工作缓存中提取数据已被解码器使用和播放。

2、如果包号与上一个正确接收的包号不连续，则意味着传输过程中出现了数据包的丢失；接收端将按照NIP报文的格式将报文类型置为00，并向同组用户发送点对点请求命令报文。同组用户在接收到NIP报文之后将首先检测该报文的类型，如果报文类型为00(点对点请求命令报文)，则立刻检测该报文的起始包号字段和结束包号字段，并查询本地的点对点数据发射缓存，看是否存在请求的数据，如果不存在则不予理会，如果存在则按照NIP报文的格式将报文类型置为01，并将点对点请求命令报文中的组号字段复制到本次发送的点对点数据报文中的组号字段当中，填充数据包号后予以发送。如果同组用户在接收到NIP报文之后检测出报文的类型为01(点对点数据报文)，则意味着这是一个弥补数据，本地必须马上检测本报文的组号，以确定该报文是否是发给自己的。

此外，在实际部署的过程中，加入整个点对点组播网络的节点其性能差异可能较大，这些性能包括节点的计算能力，存储空间，内存大小等等，如果一味地强制要求所有的节点都参与到资源供给的行列中，将极有可能导致综合能力较差的节点无法正常运转，直接影响这部分用户的体验。在本发明中是通过引入分层机制来解决这一问题的。

本发明的分层点对点组播网络典型的组网架构。各个节点在加入到本网络结构体系的时候将首先确定自身的能力，以确定是否将自身定义为向其它客户端提供资源的节点。如果探测到自身资源是足够的，则定义自身为资源客户端，当收到同组用户的资源请求之后，就向同组用户发送请求的资源；反之，则定义自身为普通客户端，对同组用户的资源请求不作回应。

在最好的情况下，同组中的所有客户端均具有较强的能力，则系统可以正常运转；但是不可忽视的是，如果同组中的所有客户端其能力都无法满足提供资源的条件，则弥补机制将很有可能无法顺利实施。这就涉及到服务器的管理问题，服务器应该将资源较好的节点均匀地分配到各个点对点组当中，以实现机制的正常运转。因此，在各个客户节点加入到本网络体系结构中的时候，必须首先向服务器报告自身的资源情况，当然所报告的信息可能不止这些，或许还有位置等其他信息；而服务器将通过各个客户端的信息进行合理的调配。值得注意的是，节点的能力可能随着时间的变化而有所不同，所以节点会根据自身当前的实际情况动态地调整自身的等级。

值得注意的是，如果分层点对点组播网络中每一个节点的资源能力均较强，则覆盖网络层所定义的虚拟的分层网络将合二为一，这应该是整个系统最理想的运行情况，因为每一个客户端都将参与到资源供给的行列中，共同支持系统的正常运转。

Claims (5)

1.一种基于分层点对点组播网络的流媒体传输方法，其特征在于该传输方法包括以下步骤：

步骤1：服务器端利用改进型用户数据报协议发送媒体数据到网关/路由器，并根据各个客户端资源能力的不同将客户端分配到不同的组当中去，同时服务器端完成各客户端的组号分配工作；

步骤2：网关/路由器将上述媒体数据转发到各个客户端；

步骤3：各个客户端利用改进型用户数据报协议分别接收上述来自网关/路由器的媒体数据，各个客户端使用缓存机制完成本客户端的正常接收和解码以及同组客户端数据的弥补工作，客户端在工作时使用接收缓存、净数据缓存、工作缓存和解码缓存完成正常接收和解码，并启用点对点数据发射缓存和点对点数据接收缓存；上述点对点数据发射缓存用于为同组用户保留弥补数据，上述点对点数据接收缓存用于接收同组用户提供的弥补数据；客户端如果发生数据的缺失就会向同组用户发送数据的请求，同组用户查询本地的点对点数据发射缓存，即同组用户保留的缓存，如果存在该份数据，将通过组号进行寻址并将缺失数据发送给该客户端以完成数据的弥补工作；

当其中一个客户端在接收上述媒体数据时，若发现其接收的数据丢失，则向同组用户发送点对点数据请求；若未发现其接收的数据丢失，则不向同组用户发送点对点数据请求；

当其中一个客户端在接收上述媒体数据时，若发现同组用户存在属于这个客户端的弥补数据，则予以接收；若未发现同组用户存在属于这个客户端的弥补数据，则继续监测；

当其中一个客户端在接收上述媒体数据时，若发现同组用户发送的点对点数据请求，则根据这个接收媒体数据的客户端的能力自主决定是否发射弥补数据；若未发现同组用户发送的点对点数据请求，则继续监测。

2.根据权利要求1所述的基于分层点对点组播网络的流媒体传输方法，其特征在于：上述步骤1中服务器端发送媒体数据到网关/路由器的具体工作过程如下：

步骤11：启动服务器；

步骤12：服务器向组播地址发送媒体数据；

步骤13：服务器对自身的媒体数据进行监测，若判断为不存在媒体数据则关闭服务器，若判断为存在媒体数据则侦测是否存在客户端连接；

步骤14：对上述步骤13的是否存在客户端连接的侦测结果进行判断，若判断为有， 则服务器端接受连接并为客户端分配组号，若判断为否，则直接返回执行步骤13。

3.根据权利要求1所述的基于分层点对点组播网络的流媒体传输方法，其特征在于：上述步骤3中的各个客户端分别接收上述来自网关/路由器的数据的具体工作过程如下：

步骤31：启动客户端；

步骤32：连接服务器并发送用户信息，同时获得本机组号，并在后台循环检测是否存在点对点数据请求，若判断存在点对点数据请求，则检测请求的数据号，此时存在上述数据号则发射点对点数据，不存在上述数据号则返回后台循环检测点对点数据请求；若判断不存在点对点数据请求，则返回后台循环检测点对点数据请求；

步骤33：接收服务器发送的媒体数据；

步骤34：将上述接收的媒体数据填充到本客户端的接收缓存，同时本客户端填充点对点数据发射缓存；所述接收缓存用于接收和暂存从服务器端通过网络组播传到客户端的数据，接收到的数据是按照主数据报文格式进行组织；

步骤35：本客户端填充净数据缓存，用于存放已经剥离主数据报文的纯应用层数据；

步骤36：对上述步骤35本客户端填充的净数据缓存判断是否缺失，若判断为是，则向同组用户发送点对点数据请求，并设置超时，本客户端等待超时或接收同组用户的点对点数据，当本客户接收到同组用户的点对点数据后，本客户端填充点对点数据发射缓存，执行步骤37；若判断为否，则返回步骤35；

步骤37：初始化本客户端的工作缓存；所述工作缓存是解码器直接接触的一个缓存，所述工作缓存设置在解码器和净数据缓存之间；

步骤38：通过解码器解码；将从工作缓存得到的数据输入解码器，利用解码器内部的缓存对解码器内部数据解码；

步骤39：判断本客户端是否需要填充工作缓存，若判断为是则进一步填充工作缓存，若判断为否则返回步骤38。

4.根据权利要求3所述的基于分层点对点组播网络的流媒体传输方法，其特征在于：上述步骤36还包括：

步骤361：对客户端等待超时的结果进行判断，若判断为超时，则执行步骤35，若判断为否，则返回继续对是否超时进行判断；

步骤362：对客户端接收到点对点数据的结果进行判断，若判断为接收到点对点数据后客户端再次填充点对点数据发射缓存，执行步骤35；若判断为否，则返回继续接收点对点数据。 

5.根据权利要求1所述的基于分层点对点组播网络的流媒体传输方法，其特征在于：上述改进型用户数据报协议采用主数据报文和邻居互连报文两种报文格式；主数据报文主要用于客户端确认数据的丢失，以启动客户端的点对点弥补机制，主数据报文格式包括一个数据包号字段，代表本次数据报文的数据包号；邻居互连报文用于弥补数据寻址，使得弥补数据可以正确地寻址到发生数据丢失的客户端，邻居互连报文格式包括一个组号字段，用于数据的寻址，一个报文类型字段，用于区分命令和数据，一个可选字段，一个应用层数据字段，含有应用层数据。 

Images