CN102215174A - 自适应多媒体流链路传输方法 - Google Patents
自适应多媒体流链路传输方法 Download PDFInfo
- Publication number
- CN102215174A CN102215174A CN2011101970976A CN201110197097A CN102215174A CN 102215174 A CN102215174 A CN 102215174A CN 2011101970976 A CN2011101970976 A CN 2011101970976A CN 201110197097 A CN201110197097 A CN 201110197097A CN 102215174 A CN102215174 A CN 102215174A
- Authority
- CN
- China
- Prior art keywords
- data
- network
- server node
- client node
- less
- 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.)
- Pending
Links
Images
Landscapes
- Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
本发明涉及一种自适应多媒体流链路传输方法,服务器节点根据实测的网络流量情况自动选择单播/多播方式向客户机节点传输数据,网络流量较大/较小时分别采用多播/单播方式,网络流量大小的确定方法为:通过数据传输前周期性传送控制信息来实时监测服务链接数和数据从服务器节点到客户机节点的往返时间RTT,还结合了对客户机节点请求的带宽与服务器节点剩余的带宽的大小关系的判断,另外还设定了数据包大小和相应的重传、丢包控制机制。本发明的方法能够根据网络流量情况自适应选择单播或多播方式进行数据传输,既能在网络流量较大时不影响用户基本的服务需求,且方便多播用户加入多播组;还能在网络流量较小时,充分利用网络中的资源。
Description
技术领域
本发明涉及一种多媒体流链路传输方法,尤其是一种可以根据网络流量情况自适应地采用单播或多播作为数据传输方式的方法。
背景技术
随着网络技术的发展,单播和多播技术相继得到了极大的发展,尤其是随着多媒体技术的发展,流媒体技术的应用范围越来越广,如网络视频会议、网络现场音乐会、网络远程教学、网络实时直播等。
通常来说,在网络带宽环境能够无限满足流媒体传输需求的前提下,单播和多播技术在传送性能上并无本质差别,但是对于如今庞大的网络用户群而言这种理想情况基本是不会出现的。当只有一个或两个客户机向同一个服务器发出请求时,二者之间可能没有明显的性能差异;但当有三至五个客户机向同一个服务器提出请求时,二者的差异就会变得比较显著,此时,采用单播方式传送数据的服务器将明显力不从心,丢包和延迟现象比较严重,接收端的视频明显滞后、不连续;当有五个以上的客户机同时提出服务请求时,就可能造成广播风暴,整个网络系统处于崩溃的边缘。
虽然网络流量较大时多播方式的传输速度较快,且不会导致网络中流量的迅速增加,但是,由于UDP是一种无连接不可靠的传输层协议,没有拥塞控制、流量控制和重传机制,并且,即使降低传输速率也不能改善其丢包率,因此,其可靠性有时不能满足要求。
可见,单播和多播各有优缺点,如何能够在不浪费网络中带宽资源的前提下,充分利用单播和多播各自的优点,从而提供符合更高要求的服务成为目前的研究重点。
发明内容
为了克服现有技术的上述缺陷,本发明提供了一种自适应多媒体流链路传输方法,能够根据网络流量情况自适应选择单播或多播方式进行数据传输,当网络流量较大时能不影响用户基本的服务需求,并且方便多播用户加入多播组;当网络流量较小时,能充分利用网络中的资源。
本发明所采用的技术方案是:
一种自适应多媒体流链路传输方法,用于改进所述多媒体流链路中的源节点(包括服务器节点)到目的节点(包括客户机节点)间的数据传输,服务器节点根据实测的网络有效流量和向所述服务器节点请求相同数据的客户机节点或进程数自动选择采用单播还是多播方式向客户机节点传输数据,若网络有效流量较大或向所述服务器节点请求相同数据的客户机节点和/或进程数较多,则采用多播方式传输数据,若网络有效流量较小且向所述服务器节点请求相同数据的客户机节点和/或进程数较少,则采用单播方式传输数据。
优选为,所述网络有效流量的大小由所述服务器节点的服务链接数以及客户机节点所请求的服务带宽和网络所能提供的总带宽来确定,如果所述服务器节点的服务链接数较少且所述客户机节点所请求的服务带宽和网络所能提供的总带宽的比值较小,则确定所述网络有效流量较小。
较优地,所述网络有效流量的确定可以通过数据传输前的控制信息的周期性传送来实现,所述客户机节点所请求的服务带宽和网络所能提供的总带宽的比值可以由所述控制信息中的数据从服务器节点到客户机节点的往返时间RTT来反映,若RTT较大,表示所述客户机节点所请求的服务带宽和网络所能提供的总带宽的比值较大,若RTT较小,表示所述客户机节点所请求的服务带宽和网络所能提供的总带宽的比值较小。
所述RTT大小的确定方法可以为:参考网络有效流量很小时数据从服务器节点到客户机节点的往返时间设定一个数据传输标准时间,将控制信息传输实际时间与所述数据传输标准时间进行比较,如果控制信息传输实际时间小于所述数据传输标准时间,则确定所述RTT较小;
所述服务器节点的服务链接数多少的确定方法可以为:设定一个服务链接数的经验值作为服务链接数标准值或者参考网络有效流量很小时服务器节点的服务链接数设定一个经验公式,再将该经验公式的结果数值作为服务链接数标准值,将控制信息传输时的服务链接数实际值与所述服务链接数标准值进行比较,如果所述控制信息传输时的服务链接数实际值小于所示服务链接数标准值,则确定所述服务链接数较少。
较优地,所述数据传输标准时间tstd=t0/2+αT,所述服务链接数标准值Nstd=N0+βn,其中,t0为所述的网络有效流量很小时数据从服务器节点到客户机节点的往返时间,T为网络拥塞时时间波动容限,N0为所述的网络有效流量很小时服务器节点的服务链接数,n为链接数波动容限,α、β分别为往返时间和链接数权值,0≤α≤1,0≤β≤1。
较优地,所述网络有流量的确定还可以包括判断客户机节点所请求的带宽与服务器节点剩余的带宽的大小关系,将所述客户机节点所请求的带宽小于服务器节点剩余的带宽作为将所述网络有效流量判定为较小的必要条件。
上述任一项技术方案中,较优地,还可以设定一个向所述服务器节点请求相同数据的客户机节点数标准值或进程数标准值,当实测到向所述服务器节点请求相同数据的客户机节点数或进程数的实际值小于相应的标准值,则判定为向所述服务器节点请求相同数据的客户机节点或进程数较少,如判定应该采用的数据传输方式不同于实际采用的数据传输方式,则由所述服务器节点对数据传输方式做出调整。
较优地,向所述服务器节点请求相同数据的客户机节点数标准值或进程数标准值为2或3,所述单播方式基于TCP协议传输数据,所述多播方式基于UDP协议传输数据。
较优地,当采用UDP多播方式传输数据时,根据所述服务器节点的系统性能和多媒体链路的网络性能在应用层设定UDP数据包的大小,若上述性能较好,则将UDP数据包分得大些,否则,分得小些,且数据包中报文段(即净载数据)的大小上限值为1472字节或者所述UDP数据包的大小为小于或等于通过所述控制信息获取的网络中各路由器的MTU值的最小值。
较优地,当选择UDP多播方式传输数据时,在应用层实现以下重传和/或丢包:(1)重传:当数据丢包导致达不到基本的服务质量时要求重传;或当单向传输时间远低于播放所允许的延迟时间时,根据序列号控制实现选择性的重传;(2)丢包:采用下列任一种丢包机制或两种丢包机制的组合;(a)如果重传时间长于播放所允许的延迟时间则将重传的包丢掉;(b)当网络拥挤时,采用间隔几个连续的包丢掉一个包的丢包控制方式。
本发明的有益效果是:
采用本发明的方法能够根据网络流量情况自适应地选择单播或多播方式传输数据,还能够根据网络流量情况以及请求相同数据的客户机或进程的数量的变化随时调整数据传输方式,因此实现在网络流量不大时采用单播方式传输数据,既提高了数据传输的可靠性,保证了服务的质量,又避免了网络流量的浪费;在网络较繁忙时采用多播方式传输数据,既可以保证基本的数据传输质量,同时降低服务器端的负担,以不影响用户基本的服务需求,又方便多播用户加入多播组,避免因单播引起的对网络资源的过度占用而导致网络系统崩溃,有利于网络系统的稳定。
附图说明
图1是本发明的系统结构示意图;
图2是本发明的一个实施例中数据传输标准时间与网络拥塞时的时间波动容限之间的关系示意图;
图3是本发明的一个实施例中标准链接数与链接数波动容限之间的关系示意图;
图4是本发明的一个实施例的流程图;
图5是本发明的t1、t2以及数据传输标准时间之间关系示意图。
具体实施方式
为了更好地解释本发明,以便更好理解,下面结合附图通过具体实施方式对本发明作更详细地描述,但是不构成对本发明保护范围的限制。
参见图1至图5,本发明提供了一种自适应多媒体流链路传输方法,用于改进所述多媒体流链路(如图1所示)中的源节点到目的节点间的数据传输速率和质量等(以服务器节点作为源节点、客户机节点作为目的节点的实施例进行说明),服务器节点根据实测的网络有效流量和向所述服务器节点请求相同数据的客户机节点或进程数自动选择采用单播还是多播方式向客户机节点传输数据,若网络有效流量较大或向所述服务器节点请求相同数据的客户机节点和/或进程数较多,则采用多播方式传输数据,既可以方便其他客户机节点或同一客户机节点的不同进程请求相同数据时加入多播组,又不影响当前的数据传输,不增加服务器节点的流量负载,保证用户的基本服务需求;若网络有效流量较小且向所述服务器节点请求相同数据的客户机节点和/或进程数较少,则采用单播方式传输数据,可以充分利用网络中的资源,提高多媒体流的传输效率。
本发明通过确定所述服务器节点的服务链接数以及客户机节点所请求的服务带宽和网络所能提供的总带宽来确定所述网络有效流量的大小。如果所述服务器节点的服务链接数较少且所述客户机节点所请求的服务带宽和网络所能提供的总带宽的比值较小,则确定为所述网络有效流量较小,此外,则认为所述网络有效流量较大。
具体地,可以在开始传输数据前通过控制报文信息的传送来确定所述网络有效流量,其中,所述客户机节点所请求的服务带宽和网络所能提供的总带宽的比值可以由所述控制报文信息中的数据从服务器节点到客户机节点的往返时间RTT来反映,若RTT较大,表示所述客户机节点所请求的服务带宽和网络所能提供的总带宽的比值较大,若RTT较小,表示所述客户机节点所请求的服务带宽和网络所能提供的总带宽的比值较小。
所述RTT大小的确定方法可以为:参考网络有效流量很小时数据从服务器节点到客户机节点的往返时间设定一个数据传输标准时间,将控制信息传输实际时间与所述数据传输标准时间进行比较,如果控制信息传输实际时间小于所述数据传输标准时间,则确定所述RTT较小;反之,则确定所述RTT较大。所谓网络有效流量很小,可以是人为选定的一种极佳的网络状态下的网络有效流量,可以依据经验确定。
所述服务器节点的服务链接数多少的确定方法可以为:设定一个服务链接数的经验值作为服务链接数标准值或者参考网络有效流量很小时服务器节点的服务链接数设定一个经验公式,再将该经验公式的结果数值作为服务链接数标准值,将控制信息传输时的服务链接数实际值与所述服务链接数标准值进行比较,如果所述控制信息传输时的服务链接数实际值小于所述服务链接数标准值,则确定所述服务链接数较少;反之,则确定所述服务链接数较大。
通常,所述服务器节点通过周期性地发送控制报文信息获取实时的RTT信息和服务器节点的服务链接数信息,并实时与相应的标准值进行对比以实时判断所述网络有效流量的大小,所述服务器节点的服务链接数为向其请求服务的所有客户机节点的总数,包括向其请求同一服务的客户机节点的总数量和向其请求不同服务的客户机节点的总数量。
其中,所述控制报文信息的发送周期应根据实际情况确定,既不能太长也不能太短。如果太长则不能及时获取网络有效流量情况,导致算法性能的下降;如果太短,虽然能很好的即时地得到反应,获知网络有效流量情况,但是同时将导致控制信息(包括控制报文信息和ACK应答信息)的大量增多,对网络是一种额外的负担。
优选为,设定所述数据传输标准时间tstd=t0/2+αT,所述服务链接数标准值Nstd=N0+βn,其中,t0为所述网络有效流量很小时数据从服务器节点到客户机节点的往返时间,T为网络拥塞时时间波动容限,N0为所述网络有效流量很小时服务器节点的服务链接数,n为链接数波动容限,当网络中节点处理能力强时,n的取值可以相应大一点。α、β分别为往返时间和链接数权值,0≤α≤1,0≤β≤1。权值α可根据所述服务器节点到所述客户机节点的跳数确定,跳数越大应选取的α值就越大,权值β可根据所述服务器节点的处理能力确定,处理能力越强应选取的β值就越大。
参见图2和图3,图2示出了当t0=200ms、α=0.9时,T取不同值时的数据传输标准时间;图3示出了当N0=70时,网络有效流量小时n取不同值时所允许的最大链接数(即所述服务链接数标准值),其中,β1~β5分别表示β取不同的值。
实践中,所述网络有效流量的确定最好还要结合比较所述客户机节点所请求的带宽Bi与所述服务器节点剩余的带宽B的大小关系,优选为将所述客户机节点所请求的带宽小于服务器节点剩余的带宽作为将所述网络有效流量判定为较小的必要条件。即当tci<t0/2+αT、Ni<N0+βn和Bi<B同时成立时,才判定为网络有效流量较小,其他情况均可以判定为网络有效流量较大,其中,i表示第i个客户机节点,tci表示第i个客户机节点的控制信息传输时的RTT实际值,Ni表示第i个客户机节点的控制信息传输时的服务链接数实际值,Bi表示第i个客户机节点所请求的带宽,B表示服务器节点剩余的带宽。
当继续有客户机节点请求数据传输时,将或多或少地影响到多媒体链路上原有数据传输的速率和质量,因此更优地,还可以在上述各个技术方案中根据服务器节点的实际处理能力以及向该同一服务器节点请求相同数据的客户机节点数或进程数的多少动态调整数据传输方式,以适应多变的网络传输环境。由于网络流量的检测和判断是周期性进行的,因此从整个网络传输过程来看,请求相同数据的客户机节点数或进程数多少的判断与网络流量大小的判断是交织、交替进行的。
下面仅以先进行客户机节点数或进程数多少的判断,再进行网络流量大小的判断为例,旨在具体说明二者相结合的判断过程和原理。如图4所示,可以设定一个向所述服务器节点请求相同数据的客户机节点数标准值或进程数标准值,当实测到向所述服务器节点请求相同数据的客户机节点数或进程数的实际值小于相应的标准值,则判定为向所述服务器节点请求相同数据的客户机节点或进程数较少,若同时网络有效流量较小,则采用单播方式传输数据,否则采用多播方式传输数据,如判定应该采用的数据传输方式不同于实际采用的数据传输方式不同,则由所述服务器节点对数据传输方式做出调整。
例如,当前的数据传输方式为单播,此时,如果继续有客户机节点请求传输数据,经判断向所述服务器节点请求相同数据的客户机节点数的实际值小于相应的标准值,继续进行网络流量大小的判断,如果网络有效流量较小,则继续采用单播方式,如果网络有效流量较大,则应调整为多播方式;如果经判断向所述服务器节点请求相同数据的客户机节点数的实际值大于或等于相应的标准值,则应直接调整为多播方式。
事实上,也可以设定小于或等于相应的标准值时,采用单播方式,而大于相应的标准值时,采用多播方式。
体现在程序控制上,可以采用下列语句进行上述的两种判断并确定采用单播还是多播的数据传输方式:
if ((t2-t1<t0/2+αT)&&(Ni<N0+βn)&&(Bi<B))
{
if (请求相同数据的客户机节点数和/或进程数>=客户机节点数和/或进程数的标准值)
{
多播;
}
else
{
单播
};
}
else
{多播;
}
如图5所示,上述程序段中t1为服务器节点发出控制报文信息的时间点,t2为客户机节点收到该控制报文信息的时间点,t2-t1即为控制报文信息从服务器节点发送开始,到所述客户机节点接收到该控制报文信息所经历的时延,或者为控制报文信息从服务器节点发送开始到服务器节点端收到来自客户机节点的确认总共经历的时延的一半。
请求相同数据的客户机节点数或进程数多少的判断所采用的标准值可以依据经验确定,优选地,向所述服务器节点请求相同数据的客户机节点数标准值或进程数标准值为2或3。
所述多播方式优选基于UDP协议传输数据。所述单播方式优选基于TCP协议传输数据,以保证数据传输的可靠性,同时,也有利于充分利用网络中的资源(主要是带宽资源)。由于此时网络中的有效流量较小,TCP的窗口机制可以将自身的发送窗口增大,使得TCP报文的大小变大,报文长度增加,由于同一个TCP报文只有一个IP头,这样,在IP层分包时产生的报头就少,同时控制信息也较少,产生的ACK应答信息也较少,这样可以在一定程度上提高多媒体流链路传输在时间上的效率。
经过前述的两种判断,如果当前的服务器节点采用TCP单播方式向客户机节点发送数据时,如果通过控制报文信息获取的网络中的数据流量(有效流量)变得足够大时(RTT足够大和/或服务器节点的服务链接数足够多),数据传输方式将变为UDP多播;如果当前的数据传输方式是UDP多播,且请求同一服务的客户机节点小于或等于2(或3)个时,如果通过控制报文信息获取网络的数据流量变得足够小时(没有时间延时或RTT足够小,且客户机节点所请求的带宽服务器节点能够提供),数据传输方式变为TCP单播,若请求同一服务的客户机节点多于2(或3)个时,则仍保持UDP多播不需进行调整。整个过程循环反复,以保证多媒体流的传输速度和质量。适时地将单播调整为多播,可以保证传输的速率,避免对网络带宽资源的过多占用,还可以避免单播方式下的以下两个方面的缺陷:
(1)服务器节点因必须始终保持监听状态以了解每一个动态加入的客户机节点的服务请求,而创建套接字以及为套接字的侦听而消耗系统的CPU资源,过于频繁的侦听可能造成系统的不稳定以及破坏多媒体流传输的实时性。
(2)服务器节点面对不同客户机节点的同一服务请求,需要进行重复转发,几个客户机节点就需要占用几倍的网络带宽资源,对网络带宽资源造成了极大地浪费,且容易造成丢包、延迟等,当客户机节点的数量达到一定数量(如五个以上)时,还容易造成广播风暴,造成网络系统的崩溃。
适时地将多播调整为单播,可以实现可靠性较高的高速传输,还能够使整个网络的带宽资源得到充分利用,避免浪费。
由于UDP传输方式是面向报文的,发送方(服务器节点)的传输层将应用层产生的报文添加首部后就向下交付给IP层,如果交付的UDP报文的长度超过IP层的MTU值(最大传输单元),就需要在IP层进行拆分,如果交付的UDP报文没有超过IP层的MTU值,就不作处理,并且保留这些报文的边界,因此,发送数据的应用程序需要选择合适的报文大小。
较优地,当采用UDP多播方式传输数据时,可以根据所述服务器节点的系统性能和多媒体链路的网络性能在应用层设定UDP数据包的大小,尤其是多媒体链路的网络性能,如,若网络状态好(通常指网络有效流量小),则将UDP数据包分得大些,以提高系统性能(尤其是速度),否则,分得小些,以降低丢包率。
在局域网的环境下,由于以太网链路层的MTU值一般为1500字节,减去包头数据(IP包头20字节和UDP包头8字节)后的MSS值一般默认为1472字节,因此,数据包中报文段的大小优选为不大于1472字节,以避免分片重组,尤其是以UDP多播方式传输数据时。在广域网络的环境下,网络中的各个路由器可能会有配置成不同的值(如小于默认值),UDP数据包如果大于设定的MTU值时,UDP数据包就需要在IP层进行分片,此时会产生很多数据包的碎片,当网络有效流量大时,一旦分片之后的数据包发生丢包时,分片之前的UDP数据包就会被整个丢掉,由此会对多媒体流的数据传输的可靠性造成较大的影响。在UDP传输的实际应用时,数据包的大小较小时传输速率也较高,通常可以获得较好的性能,但是数据包越小,数据报头的开销也就越大,当数据包过小时反而会对传输性能带来负面影响,因此,需要选取适当的数据包的大小,如所述控制报文信息中还可以包括获取网络中各路由器的MTU值的信息,以通过控制报文信息获取网络中各个路由器的MTU值,选取其中的最小值来确定UDP数据包的大小,确保数据包的大小不大于所述各路由器中的最小MTU值,以避免UDP数据包通过各路由器时还需要进行分片,进而避免由于分片而导致的一系列负面影响。
较优地,当网络有效流量小时所述数据包应尽量大,当所述网络有效流量大时所述数据包不应超过网络有效流量小时的大小。
由于UDP是一种无连接不可靠的传输层协议,没有拥塞控制、流量控制和重传机制,因此,为了保证数据传输的可靠性,上述任意一项技术方案中,当选择多播方式传输数据时,可以通过应用层来保证数据传输的可靠性,例如可以采用包括定时、重传、丢包和/或序列号等机制,具体方式包括:(1)重传:当数据丢包导致达不到基本的或人为要求的服务质量时要求重传;或当单向传输时间远低于播放所允许的延迟时间时,采用重传作为控制机制,并根据序列号进行选择性的重传;(2)丢包:采用下列一种或两种丢包机制的组合,(a)如果重传时间长于播放所允许的延迟则将重传的包丢掉;(b)当网络拥挤时,通过间隔x个连续的包丢掉y个包的丢包控制方式保证服务质量。
较优地,所述方式(b)中,所述x、y值为预设可调的,在一定时长内x值固定或不固定,通常x值大于y值,通常y值取1;包的大小也为预设可调的,在一定时长内包的大小为相同或不同的,在一定时长内包的大小为固定或不固定的。例如可以每隔四个包丢掉一个包。
序列号能够保证接收的数据包能够有序排列,当数据丢包达不到基本的服务质量时可以要求重传。一般流媒体对播放时间有严格的限制,通常不采用重传机制进行丢包恢复,但是如果单向传输时间远低于播放所允许的延迟,则可以采用重传作为控制机制。为最大限度的保证服务质量和传输速度,可以根据序列号进行选择性的重传,既不破坏数据流的平滑性,又能够确保数据包的传输不产生过大的时延抖动,如果重传时间长于播放所允许的延迟还可以将重传的包丢掉,以保证在不影响数据传输质量的基础上最大化利用网络资源。
在流媒体传输中(如多媒体视频流),通常对数据传输的可靠性要求不高,相对于可靠性来说,UDP的应用更加注重实际性能(尤其是流畅度、平滑性等),所以为了获得更好的使用效果(如更高的画面刷新速率)往往可以牺牲一定的可靠性(如画面质量),因此适当的数据丢失不会过多的影响视频播出的效果。另外,由于UDP传输在网络拥挤的情况下丢包是正常现象,因此,在网络有效流量较大(网络拥挤时)可以通过控制丢包的方式丢掉一定数量的数据包来保证服务(传输速度)。如果连续丢包将会导致视频不清楚,无法保证基本的服务,因此在控制丢包时应该实现在间隔连续的几个数据包丢掉一个数据包,这种丢包方式可以有效避免多媒体流多播中,某个链路上的网络拥塞影响整个多播会话,还能够避免被动的连续丢包现象的发生,并且能够不影响基本的视频传输质量,同时降低服务器节点的负担,保证一定的服务质量。
在整个网络系统中,单播和多播往往是同时存在的,当网络有效流量比较大而且多播长时间存在的情况下,当有其他客户机节点(如其他目的主机或同一主机的不同进程)有相同服务请求时,如果选择以UDP多播方式传输数据,该客户机节点可以通过IGMP报文加入相应的多播组而不会影响当前多播组的数据传输,并且相对于TCP而言其数据报头开销较小,传输速度也更快,还避免了网络中流量的迅速增加,且UDP数据包在链路中传输的速率不会退避,同时会迫使已有的TCP连接根据窗口机制将本身的数据速率退避,即UDP数据包优先占用空闲网络带宽资源,而TCP只占用剩余的网络带宽资源,因此,选用UDP多播方式时其数据传输速率不会受限制,能够以最大的速度进行传输,保证了服务质量。
本发明的方法能够根据网络流量情况自适应选择TCP单播/UDP多播方式传输数据,既能够在网络流量小时保证数据传输的高可靠性,避免带宽资源的浪费,还能够在网络流量大时保证数据传输的高速率,保证服务质量。
Claims (10)
1.一种自适应多媒体流链路传输方法,其特征在于服务器节点根据实测的网络有效流量和向所述服务器节点请求相同数据的客户机节点或进程数自动选择采用单播还是多播方式向客户机节点传输数据,若网络有效流量较大或向所述服务器节点请求相同数据的客户机节点和/或进程数较多,则采用多播方式传输数据,若网络有效流量较小且向所述服务器节点请求相同数据的客户机节点和/或进程数较少,则采用单播方式传输数据。
2.根据权利要求1所述的自适应多媒体流链路传输方法,其特征在于所述网络有效流量的大小由所述服务器节点的服务链接数以及客户机节点所请求的服务带宽和网络所能提供的总带宽来确定,如果所述服务器节点的服务链接数较少且所述客户机节点所请求的服务带宽和网络所能提供的总带宽的比值较小,则确定所述网络有效流量较小。
3.根据权利要求2所述的自适应多媒体流链路传输方法,其特征在于所述网络有效流量的确定通过数据传输前的控制信息的周期性传送来实现,所述客户机节点所请求的服务带宽和网络所能提供的总带宽的比值由所述控制信息中的数据从服务器节点到客户机节点的往返时间RTT来反映,若RTT较大,表示所述客户机节点所请求的服务带宽和网络所能提供的总带宽的比值较大,若RTT较小,表示所述客户机节点所请求的服务带宽和网络所能提供的总带宽的比值较小。
4.根据权利要求3所述的自适应多媒体流链路传输方法,其特征在于:
所述RTT大小的确定方法为:参考网络有效流量很小时数据从服务器节点到客户机节点的往返时间设定一个数据传输标准时间,将控制信息传输实际时间与所述数据传输标准时间进行比较,如果控制信息传输实际时间小于所述数据传输标准时间,则确定所述RTT较小;
所述服务器节点的服务链接数多少的确定方法为:设定一个服务链接数的经验值作为服务链接数标准值或者参考网络有效流量很小时服务器节点的服务链接数设定一个经验公式,再将该经验公式的结果数值作为服务链接数标准值,将控制信息传输时的服务链接数实际值与所述服务链接数标准值进行比较,如果所述控制信息传输时的服务链接数实际值小于所述服务链接数标准值,则确定所述服务链接数较少。
5.根据权利要求4所述的自适应多媒体流链路传输方法,其特征在于所述数据传输标准时间tstd=t0/2+αT,所述服务链接数标准值Nstd=N0+βn,其中,t0为所述的网络有效流量很小时数据从服务器节点到客户机节点的往返时间,T为网络拥塞时时间波动容限,N0为所述的网络有效流量很小时服务器节点的服务链接数,n为链接数波动容限,α、β分别为往返时间和链接数权值,0≤α≤1,0≤β≤1。
6.根据权利要求5所述的自适应多媒体流链路传输方法,其特征在于所述网络有效流量的确定还包括判断客户机节点所请求的带宽与服务器节点剩余的带宽的大小关系,将所述客户机节点所请求的带宽小于服务器节点剩余的带宽作为将所述网络有效流量判断为较小的必要条件。
7.根据权利要求1-6中任一项权利要求所述的自适应多媒体流链路传输方法,其特征在于还设定一个向所述服务器节点请求相同数据的客户机节点数标准值或进程数标准值,当实测到向所述服务器节点请求相同数据的客户机节点数或进程数的实际值小于相应的标准值,则判定为向所述服务器节点请求相同数据的客户机节点或进程数较少,如判定应该采用的数据传输方式不同于实际采用的数据传输方式,则由所述服务器节点对数据传输方式做出调整。
8.根据权利要求7所述的自适应多媒体流链路传输方法,其特征在于向所述服务器节点请求相同数据的客户机节点数标准值或进程数标准值为2或3,所述单播方式基于TCP协议传输数据,所述多播方式基于UDP协议传输数据。
9.根据权利要求8所述的自适应多媒体流链路传输方法,其特征在于当采用UDP多播方式传输数据时,根据所述服务器节点的系统性能和多媒体链路的网络性能在应用层设定UDP数据包的大小,若上述性能较好,则将UDP数据包分得大些,否则,分得小些,且UDP数据包的大小为小于或等于通过所述控制信息获取的网络中各路由器的MTU值的最小值。
10.根据权利要求9所述的自适应多媒体流链路传输方法,其特征在于当选择UDP多播方式传输数据时,在应用层实现以下重传和/或丢包:(1)重传:当数据丢包导致达不到基本的服务质量时要求重传;或当单向传输时间远低于播放所允许的延迟时间时,根据序列号控制实现选择性的重传;(2)丢包:采用下列一种或两种丢包机制的组合;(a)如果重传时间长于播放所允许的延迟则将重传的包丢掉;(b)当网络拥挤时,采用间隔几个连续的包丢掉一个包的丢包控制方式。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN2011101970976A CN102215174A (zh) | 2011-07-14 | 2011-07-14 | 自适应多媒体流链路传输方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN2011101970976A CN102215174A (zh) | 2011-07-14 | 2011-07-14 | 自适应多媒体流链路传输方法 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN102215174A true CN102215174A (zh) | 2011-10-12 |
Family
ID=44746310
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN2011101970976A Pending CN102215174A (zh) | 2011-07-14 | 2011-07-14 | 自适应多媒体流链路传输方法 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN102215174A (zh) |
Cited By (14)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN103607595A (zh) * | 2013-11-07 | 2014-02-26 | 北京邮电大学 | 基于时间窗口的单播与多播混合传输方法和设备 |
CN104348781A (zh) * | 2013-07-26 | 2015-02-11 | 中兴通讯股份有限公司 | 一种多媒体业务传输方法及终端设备 |
CN104756587A (zh) * | 2012-06-29 | 2015-07-01 | 阿尔卡特朗讯 | 用于在多播/广播与单播服务之间进行切换的方法和装置 |
WO2015123878A1 (zh) * | 2014-02-22 | 2015-08-27 | 华为技术有限公司 | 一种视频数据传输的方法以及相关设备 |
CN105450541A (zh) * | 2014-08-29 | 2016-03-30 | 阿尔卡特朗讯 | 基于服务链路由应用数据包的方法与设备 |
CN105656744A (zh) * | 2014-11-10 | 2016-06-08 | 华为数字技术(苏州)有限公司 | 服务链路径的标识方法、设备和服务链 |
CN106899605A (zh) * | 2017-03-15 | 2017-06-27 | 东软集团股份有限公司 | 基于stomp协议的通信方法和装置 |
CN106973315A (zh) * | 2017-04-07 | 2017-07-21 | 广西广播电视信息网络股份有限公司 | 基于用户需求的广电网络多通道智能调度传输系统及方法 |
CN107431704A (zh) * | 2015-03-13 | 2017-12-01 | 瑞典爱立信有限公司 | 用于使用多播机制的直播自适应比特率(abr)媒体的优化传递的系统和方法 |
WO2017220023A1 (en) * | 2016-06-23 | 2017-12-28 | Huawei Technologies Co., Ltd. | System and method for delivering unicastand broadcast traffic in a communication network |
CN111526169A (zh) * | 2019-02-01 | 2020-08-11 | 阿里巴巴集团控股有限公司 | 通过网络发送数据的方法、介质、服务器和计算机设备 |
CN113315945A (zh) * | 2021-07-29 | 2021-08-27 | 江苏怀业信息技术股份有限公司 | 分布式视频会议系统的终端接入方法 |
CN116132727A (zh) * | 2023-02-07 | 2023-05-16 | 深圳市创凯智能股份有限公司 | 一种数据传输类型确定方法、装置、设备和存储介质 |
CN116708134A (zh) * | 2023-07-12 | 2023-09-05 | 韩山师范学院 | 基于流量控制的点对点网络传输系统 |
Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101035054A (zh) * | 2006-03-08 | 2007-09-12 | 三星电子株式会社 | 流传输内容的客户机设备和方法及其计算机可读介质 |
CN101616077A (zh) * | 2009-07-29 | 2009-12-30 | 武汉大学 | 互联网大文件的快速传输方法 |
CN101764816A (zh) * | 2009-12-25 | 2010-06-30 | 杭州华三通信技术有限公司 | 一种数据的传输方法及装置 |
CN102017516A (zh) * | 2008-04-24 | 2011-04-13 | 爱立信电话股份有限公司 | 媒体分发的系统和方法 |
-
2011
- 2011-07-14 CN CN2011101970976A patent/CN102215174A/zh active Pending
Patent Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101035054A (zh) * | 2006-03-08 | 2007-09-12 | 三星电子株式会社 | 流传输内容的客户机设备和方法及其计算机可读介质 |
CN102017516A (zh) * | 2008-04-24 | 2011-04-13 | 爱立信电话股份有限公司 | 媒体分发的系统和方法 |
CN101616077A (zh) * | 2009-07-29 | 2009-12-30 | 武汉大学 | 互联网大文件的快速传输方法 |
CN101764816A (zh) * | 2009-12-25 | 2010-06-30 | 杭州华三通信技术有限公司 | 一种数据的传输方法及装置 |
Cited By (23)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN104756587B (zh) * | 2012-06-29 | 2018-07-27 | 阿尔卡特朗讯 | 用于在多播/广播与单播服务之间进行切换的方法和装置 |
CN104756587A (zh) * | 2012-06-29 | 2015-07-01 | 阿尔卡特朗讯 | 用于在多播/广播与单播服务之间进行切换的方法和装置 |
CN104348781A (zh) * | 2013-07-26 | 2015-02-11 | 中兴通讯股份有限公司 | 一种多媒体业务传输方法及终端设备 |
CN103607595A (zh) * | 2013-11-07 | 2014-02-26 | 北京邮电大学 | 基于时间窗口的单播与多播混合传输方法和设备 |
WO2015123878A1 (zh) * | 2014-02-22 | 2015-08-27 | 华为技术有限公司 | 一种视频数据传输的方法以及相关设备 |
US10205668B2 (en) | 2014-02-22 | 2019-02-12 | Huawei Technologies Co., Ltd. | Video data transmission method and related device |
CN105450541A (zh) * | 2014-08-29 | 2016-03-30 | 阿尔卡特朗讯 | 基于服务链路由应用数据包的方法与设备 |
CN105450541B (zh) * | 2014-08-29 | 2018-10-02 | 阿尔卡特朗讯 | 基于服务链路由应用数据包的方法与设备 |
CN105656744A (zh) * | 2014-11-10 | 2016-06-08 | 华为数字技术(苏州)有限公司 | 服务链路径的标识方法、设备和服务链 |
CN105656744B (zh) * | 2014-11-10 | 2019-08-27 | 华为数字技术(苏州)有限公司 | 服务链路径的标识方法、设备和服务链 |
CN107431704A (zh) * | 2015-03-13 | 2017-12-01 | 瑞典爱立信有限公司 | 用于使用多播机制的直播自适应比特率(abr)媒体的优化传递的系统和方法 |
CN107431704B (zh) * | 2015-03-13 | 2021-02-23 | 瑞典爱立信有限公司 | 用于使用多播机制的直播自适应比特率(abr)媒体的优化传递的系统和方法 |
WO2017220023A1 (en) * | 2016-06-23 | 2017-12-28 | Huawei Technologies Co., Ltd. | System and method for delivering unicastand broadcast traffic in a communication network |
CN106899605A (zh) * | 2017-03-15 | 2017-06-27 | 东软集团股份有限公司 | 基于stomp协议的通信方法和装置 |
CN106973315A (zh) * | 2017-04-07 | 2017-07-21 | 广西广播电视信息网络股份有限公司 | 基于用户需求的广电网络多通道智能调度传输系统及方法 |
CN106973315B (zh) * | 2017-04-07 | 2023-11-21 | 广西广播电视信息网络股份有限公司 | 基于用户需求的广电网络多通道智能调度传输系统及方法 |
CN111526169A (zh) * | 2019-02-01 | 2020-08-11 | 阿里巴巴集团控股有限公司 | 通过网络发送数据的方法、介质、服务器和计算机设备 |
CN111526169B (zh) * | 2019-02-01 | 2022-06-14 | 阿里巴巴集团控股有限公司 | 通过网络发送数据的方法、介质、服务器和计算机设备 |
CN113315945A (zh) * | 2021-07-29 | 2021-08-27 | 江苏怀业信息技术股份有限公司 | 分布式视频会议系统的终端接入方法 |
CN113315945B (zh) * | 2021-07-29 | 2021-11-09 | 江苏怀业信息技术股份有限公司 | 分布式视频会议系统的终端接入方法 |
CN116132727A (zh) * | 2023-02-07 | 2023-05-16 | 深圳市创凯智能股份有限公司 | 一种数据传输类型确定方法、装置、设备和存储介质 |
CN116708134A (zh) * | 2023-07-12 | 2023-09-05 | 韩山师范学院 | 基于流量控制的点对点网络传输系统 |
CN116708134B (zh) * | 2023-07-12 | 2024-05-14 | 韩山师范学院 | 基于流量控制的点对点网络传输系统 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN102215174A (zh) | 自适应多媒体流链路传输方法 | |
US6507562B1 (en) | Dynamic optimization for receivers using distance between a repair head and a member station in a repair group for receivers having a closely knit topological arrangement to locate repair heads near the member stations which they serve in tree based repair in reliable multicast protocol | |
US5905871A (en) | Method of multicasting | |
CN103944834B (zh) | 一种音视频转发控制方法及系统 | |
Badrinath et al. | Gathercast: The design and implementation of a programmable aggregation mechanism for the Internet | |
CN104486690A (zh) | 一种基于tcp协议的移动视频传输优化方法 | |
US10250499B2 (en) | Multicast transmission using programmable network | |
Hsiao et al. | Streaming video over TCP with receiver-based delay control | |
Yadav et al. | A review of congestion control mechanisms for wireless networks | |
Mulabegovic et al. | Lightweight streaming protocol (LSP) | |
Puangpronpitag et al. | Explicit rate adjustment: An efficient congestion control protocol for layered multicast | |
Kumar et al. | A review on congestion control approaches for real-time streaming application on the internet | |
Xiong et al. | Delay Prediction for Real-Time Video Adaptive Transmisson over TCP. | |
Liwen et al. | Research on multicast congestion control | |
Constantinescu et al. | Congestion and error control in overlay networks | |
Li et al. | A reliable message multicast transport protocol for virtual circuits | |
Chung et al. | Mtp a streaming friendly transport protocol | |
Ghazali et al. | Scaleable round trip time estimation for layered multicast protocol | |
Natu et al. | GSC: a generic source-based congestion control algorithm for reliable multicast | |
Brennan et al. | Split-layer video multicast protocol: A new receiver-based rate-adaptation protocol | |
El-Marakby et al. | Evaluation of the Real-Time Transport Protocol (RTP) for Continuous Media Communications | |
Sze et al. | Network-Driven Layered Multicast with IPv6 | |
Prins et al. | Fast rtp retransmission for iptv-implementation and evaluation | |
Appala et al. | An evaluation of reliable multicast protocols | |
Puangpronpitag et al. | Explicit rate adjustment for multirate multicast congestion control using TCP throughput equation and packet-pair probe |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
C12 | Rejection of a patent application after its publication | ||
RJ01 | Rejection of invention patent application after publication |
Application publication date: 20111012 |