CN1314250C - 一种鲁棒的基于点对点的流调度方法 - Google Patents
一种鲁棒的基于点对点的流调度方法 Download PDFInfo
- Publication number
- CN1314250C CN1314250C CNB2004100867111A CN200410086711A CN1314250C CN 1314250 C CN1314250 C CN 1314250C CN B2004100867111 A CNB2004100867111 A CN B2004100867111A CN 200410086711 A CN200410086711 A CN 200410086711A CN 1314250 C CN1314250 C CN 1314250C
- Authority
- CN
- China
- Prior art keywords
- client node
- media stream
- multicast
- network
- client
- 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.)
- Expired - Fee Related
Links
Images
Landscapes
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
本发明属于信息传播技术领域，涉及一种鲁棒的基于点对点的流调度方法。该方法将调度服务器、流媒体服务器和客户端节点组成一个直播网络，根据每个客户端节点在网络中所实现功能的不同给予不同的定义，在网络中每个客户端节点被赋于不同的功能。新客户端节点的请求加入以及客户端节点的退出造成网络拓扑结构的改变，通过对网络拓扑表的动态更新和监控，以及改变部分客户端节点的功能实现流调度。该方法综合了P2P技术、IP多播技术和网络代理技术的优点，力图最大程度上节省网络带宽。在该方法中采用多数据源技术以增强组播网络的鲁棒性。同时，多数据源的低相关性，为重传等差错恢复提供了有利条件。
Description
技术领域
本发明属于信息传播技术领域，尤其涉及一种基于直播网络环境下的高鲁棒性的P2P流调度方法。
背景技术
随着Internet的发展，特别是宽带业务的迅速普及，人们已经不再满足于仅有文本、图像等简单信息。而对内容更丰富的视频，音频等媒体服务有了越来越多的需求。网络中的多媒体内容，尤其是连续媒体内容(视频和音频)，即流媒体内容正在迅速地增加。流媒体是多媒体和网络通信的交叉学科。在流媒体应用中，内容提供方将压缩后的视频数据分拆打包后以“流”的方式通过网络同时传输给接收方，接收方一边接收数据，一边将已经收到的数据包重组、解码、播放。这种传输模式与网络中其他的传输模式具有本质区别。
视频组播这个新型网络业务需要实现网络上一点对多点的通信。而当前，Internet上的各种服务都普遍采用客户/服务器结构，或者叫做IP单播。这种服务模型结构简单，易于实现，它在计算机网络普及过程中发挥了巨大的作用。但是，随着网络服务的规模日趋庞大，这种结构弊端也越来越明显：为了能够向更多的客户服务，它需要越来越强大的服务器，并对在服务器端的网络出口带宽要求越来越高。特别是在视频服务领域，由于视频流的码率往往都很高，一般至少在几百千比特每秒(kbits/s)，所以对服务器压力非常大，几乎不能满足日益扩大的用户需求。尤其在视频组播里面，服务器事实上在给大量的客户端发送相同的视频数据，这不但给服务器带来额外负担，而且对带宽资源是一个极大的浪费。也就是说服务器的计算性能和网络带宽成了最主要的瓶颈。
鉴于IP组播所存在的诸多问题，在应用层实现组播功能的想法随之被提出。这就是所谓的应用层组播，其基本思想就是将组播的功能放到应用层来完成。但是应用层组播大多采用在网络各个部分架设可靠的服务器来完成组播任务，而维护这些服务器需要大量的成本。
发明内容
本发明的目的是为克服已有技术的不足之处，提出一种鲁棒的基于点对点的流调度方法，该方法综合了P2P技术、IP多播技术和网络代理技术的优点，力图最大程度上节省了网络带宽。在该方法中采用多数据源技术以增强组播网络的鲁棒性。多数据源的低相关性，为重传等差错恢复提供了有利条件。
本发明提出的一种鲁棒的基于P2P的流调度方法，包括组网方法和调度方法，其中所述的组网方法包括以下步骤：
(1)在直播网络中，调度服务器(Trace Server)为客户端节点(Peer)找到其他的客户端节点，并通知流媒体服务器(Streaming Server)向客户端节点提供媒体流；
(2)流媒体服务器向客户端节点提供稳定的媒体流；
(3)客户端节点接收来自流媒体服务器或提供媒体流的客户端节点的媒体流，并缓存媒体流，在该客户端节点播放媒体流数据的同时，通过P2P(Peer-to-Peer)方式向其他客户端节点提供媒体流；
(4)步骤(3)中的客户端节点，若在P2P传输过程中，向其他客户端节点提供媒体流，则该客户端节点称为提供媒体流的客户端节点(supplying peer)，否则该客户端节点称为底层客户端节点(leaf peer)；
(5)步骤(3)中的客户端节点，若在P2P传输过程中，接收来自流媒体服务器或接收提供媒体流的客户端节点的媒体流，则该客户端节点称为接收媒体流的客户端节点(receiving peer)；
(6)步骤(3)中的客户端节点，若位于某一个子网内部，并且向其他客户端节点提供媒体流，则该客户端节点称为多播客户端节点(multicasting peer)；
(7)步骤(3)中的客户端节点，若位于某一个子网内部，且只接收来自同一子网内其他多播客户端节点的媒体流，同时不向子网外其他客户端提供媒体流，则该客户端节点称为多播接收客户端节点(multicasting receiver)；
(8)步骤(3)中的客户端节点，可同时是提供媒体流的客户端节点、接收媒体流的客户端节点和多播客户端节点，但只要它是提供媒体流的客户端节点、接收媒体流的客户端节点和多播客户端节点三者之一，它就不能是多播接收客户端节点；
(9)步骤(3)中的客户端节点，如果正在请求加入直播网络，则该客户端节点称为请求加入的客户端节点(requesting peer)；
(10)步骤(3)中的客户端节点，如果正在请求或已强行退出直播网络，则该客户端节点称为退出的客户端节点(quitting peer)；
(11)步骤(3)中的客户端节点，如果直接从流媒体服务器获得媒体流，则该客户端节点称为种子客户端节点(seed peer)；
(12)流媒体服务器位于该网络的第0层(layer)；种子客户端节点位于该网络的第1层；若某个客户端节点由若干个提供媒体流的客户端节点提供媒体流，则它位于网络的层次是所有提供媒体流的客户端节点中最大的层次加一；如果某个客户端节点是由某个多播客户端节点提供媒体流，则它的层次是多播客户端节点的层次加一；网络中层次序号是用来估计媒体流在网络中产生的延迟；
所述调度方法，包括如下步骤；
(13)当有新的客户端节点申请加入直播网络时，必须先与所述调度服务器连接，通过调度服务器分配提供媒体流的客户端节点或多播客户端节点为其提供媒体流(该调度服务器不可以将任一个多播接收客户端节点提供给请求加入的客户端节点，以免造成该子网的输出流量异常大)；
(14)当有某个客户端节点退出直播网络时，调度服务器要根据当前网络拓扑情况，选择一个多播接收客户端节点或底层客户端节点替代退出的客户端节点(调度服务器若选择底层客户端节点，则一般选择层数最大的，也可以兼顾距离、延迟等信息进行选择)；
(15)调度服务器保存一份详细记录该网络的拓扑结构网络拓扑表，当有客户端节点加入或退出该网络时(即网络拓扑结构发生变化)，该网络拓扑表也动态实时更新；
(16)在调度服务器的调度过程中，每个客户端节点的提供媒体流的客户端节点的层次数都比该客户端节点的层次数小(从而保证调度服务器在流调度过程中不产生环状网络结构，确保每个客户端节点都可以直接或间接地从流媒体服务器获取最新的媒体流数据)；
(19)在调度服务器的调度过程中，将每个不能对外提供媒体流的客户端节点分配到直播网络的最底端，使其成为底层客户端节点；
(20)直播环境下存在多个频道的处理，可以同时运行多个调度服务器，也可以在同一调度服务器上开启不同端口予以支持，每一个调度服务器或每一个端口均在逻辑上维护各自的网络。
在上述第(13)步骤中当有新的客户端节点申请加入直播网络时，调度服务器的调度方法，具体包括以下步骤：
(13.1)若请求加入的客户端节点所在子网内没有或只有一个其他的客户端节点时(可认为请求加入的客户端节点不在该子网内)，则调度服务器向请求加入的客户端节点分配该子网以外的若干个(数量可以比较多)客户端节点或流媒体服务器给请求加入的客户端节点作为提供媒体流的候选客户端节点(Supplying Candidates)，请求加入的客户端节点通过比较(如比较与它们之间的延迟、比较它们的历史信息等等)，选择若干个客户端节点作为提供媒体流的客户端节点，此时请求加入的客户端节点工作在P2P模式(Peer-to-Peer Mode)；
(13.2)如果请求加入的客户端节点所在子网内有2个或2个以上的客户端节点，则可以采用P2P模式(方法如步骤(13.1)所述)，也可以采用组播模式(MulticastingMode)加入到整个直播网络中；
(13.3)在步骤(13.2)中，若请求加入的客户端节点采用组播的方式加入直播网络，则根据原先该子网内是否存在其他多播接收客户端节点，确定新客户端节点加入的调度方法；
(13.4)在步骤(13.3)中，若原先该子网内存在其他多播接收客户端节点，则调度服务器将请求加入的客户端节点的地址和端口号告知该子网内的所有多播客户端节点，每个多播客户端节点将请求加入的客户端节点的信息加入到各自得组播列表中；
(13.5)在步骤(13.3)中，若原先该子网内不存在其他多播接收客户端节点，则调度服务器将告知该子网内所有的工作在P2P模式下的客户端节点，使它们进入组播状态，之后回步骤(13.4)。
在上述第(14)步骤中，当有某个客户端节点退出直播网络时，调度服务器的调度方法，具体包括以下步骤：
(14.1)如果退出的客户端节点所在的子网内部存在多播接收客户端节点，且退出的客户端节点本身是一个多播客户端节点，则将退出的客户端节点的工作全部转移到该子网内的一个多播接收客户端节点上，该多播接收客户端节点与退出的客户端节点的所有提供媒体流的客户端节点建立连接，从而获得所有的媒体流数据，同时接受退出的客户端节点的所有接收媒体流的客户端节点的请求；
(14.2)如果退出的客户端节点所在的子网内部存在多播接收客户端节点，且退出的客户端节点本身是一个多播接收客户端节点，则将该退出的客户端节点从该网络的拓扑表中删除；
(14.3)如果退出的客户端节点所在的子网内部不存在多播接收客户端节点(可认为请求加入的客户端节点不在该子网内)，则分配一个底层客户端节点来代替退出的客户端节点(分配的底层客户端节点一般是层次数较大的，这样可以使得整个组播网络的层次数保持在较小的水平上，有利于减小网络延迟，同时也应该兼顾距离、带宽等因素)；
(14.4)如果退出的客户端节点为底层客户端节点，则将该退出的客户端节点从该网络的拓扑表中删除；
在上述第(15)步骤中，拓扑表动态实时更新的方法，具体包括以下步骤：
(15.1)每个客户端节点都必须定期向调度服务器发送存活(Alive)信号，表示自己仍然处于网络中，并且还在工作，如果某个客户端节点在给定的时间阈值(Timeout)内没有发送存活信号，则认为该客户端节点已经退出直播网络，并将其从拓扑表中删除，之后按客户端节点退出的调度方法处理；
(15.2)在步骤(15.1)中，每个客户端节点向调度服务器发送存活信号的时间间隔在一个给定的范围内随机变化(根据缓存大小、延迟等信息设定时间间隔变化范围)；
(15.3)当组播网络的规模大于设定的规模阈值时，采用分级监听的方法动态更新拓扑表；该分级监听方法为：种子客户端节点是唯一直接向调度服务器发送存活信号的客户端节点；除种子客户端节点以外的所有客户端节点，直接向提供媒体流的客户端节点或多播客户端节点发送存活信号；若提供媒体流的客户端节点或多播客户端节点在该时间阈值内没有收到某个客户端节点的存活信号，直接通知调度服务器；调度服务器将在该时间阈值内没有发送存活信号的客户端节点从拓扑表中删除，之后按客户端节点退出的调度方法处理。
本发明的特点及技术效果：
本发明方法综合了P2P技术、IP多播技术和网络代理技术的优点，力图最大程度上节省网络带宽。在该方法中采用多数据源技术以增强组播网络的鲁棒性。多数据源的低相关性，为重传等差错恢复提供了有利条件。
附图说明
图1是本发明方法的组网结构实施例示意图；
图2是本实施例中在子网中的客户端节点退出直播网络时调度方法示意图；
图3是本实施例中在子网外的客户端节点退出直播网络时调度方法示意图。
具体实施方式
本发明提出的一种鲁棒的基于点对点的流调度方法结合附图及实施例详细说明如下：
本发明方法的组网结构实施例如图1所示，图中1至5均是客户端节点，其中1同时是种子客户端节点、提供媒体流的客户端节点和接收媒体流的客户端节点；2同时是种子客户端节点、多播客户端节点、提供媒体流的客户端节点和接收媒体流的客户端节点；3是多播接收客户端节点；4同时是提供媒体流的客户端节点和接收媒体流的客户端节点；5同时是接收媒体流的客户端节点和底层客户端节点；6是媒体流数据的提供路线；7是调度服务器对媒体流的调度。
本实施例的组网方法包括以下步骤：
(1)在本实施例网络中，调度服务器为客户端节点(如图1中的客户端节点1-5)找到其他的客户端节点，并通知流媒体服务器向客户端节点提供媒体流；
(2)流媒体服务器向客户端节点提供稳定的媒体流；
(3)客户端节点(如图1中的客户端节点1-5)接收来自流媒体服务器或提供媒体流的客户端节点的媒体流，并缓存媒体流，在该客户端节点播放媒体流数据的同时，通过P2P方式向其他客户端节点提供媒体流；
(4)步骤(3)中的客户端节点，若在P2P传输过程中，向其他客户端节点提供媒体流，则该客户端节点称为提供媒体流的客户端节点(如图1中的客户端节点1，2，4)，否则该客户端节点称为底层客户端节点(如图1中的客户端节点5)；
(5)步骤(3)中的客户端节点，若在P2P传输过程中，接收来自流媒体服务器或接收提供媒体流的客户端节点的媒体流，则该客户端节点称为接收媒体流的客户端节点(如图1中的客户端节点1，2，4，5)；
(6)步骤(3)中的客户端节点，若位于某一个子网内部，并且向其他客户端节点提供媒体流，则该客户端节点称为多播客户端节点(如图1中的客户端节点2)；
(7)步骤(3)中的客户端节点，若位于某一个子网内部，且只接收来自同一子网内其他多播客户端节点的媒体流，同时不向子网外其他客户端提供媒体流，则该客户端节点称为多播接收客户端节点(如图1中的客户端节点3)。
(8)步骤(3)中的客户端节点，可同时是提供媒体流的客户端节点、接收媒体流的客户端节点和多播客户端节点，但只要它是提供媒体流的客户端节点、接收媒体流的客户端节点和多播客户端节点三者之一，它就不能是多播接收客户端节点；
(9)步骤(3)中的客户端节点，如果正在请求加入直播网络，则该客户端节点称为请求加入的客户端节点(可以是如图1中的客户端节点5)；
(10)步骤(3)中的客户端节点，如果正在请求或已强行退出直播网络，则该客户端节点称为退出的客户端节点(可以是如图1中的客户端节点1-5)；
(11)步骤(3)中的客户端节点，如果直接从流媒体服务器获得媒体流，则该客户端节点称为种子客户端节点(如图1中的客户端节点1、2)；
(12)流媒体服务器位于该网络的第0层；种子客户端节点(如图1中的客户端节点1、2)位于该网络的第1层；若某个客户端节点由若干个提供媒体流的客户端节点提供媒体流，则它位于网络的层次是所有提供媒体流的客户端节点中最大的层次加一(如图1中的客户端节点3、4是第2层，客户端节点5是第3层)；如果某个客户端节点是由某个多播客户端节点提供媒体流，则它的层次是多播客户端节点(如图1中的客户端节点2)的层次加一。网络中层次序号是用来估计媒体流在网络中产生的延迟；
本实施例的调度方法结合图1、2、3所示，说明如下：
(13)当有新的客户端节点(可以是图1中的客户端节点3，5)申请加入直播网络时，必须先与所述调度服务器连接，通过调度服务器分配提供媒体流的客户端节点或多播客户端节点为其提供媒体流(该调度服务器不可以将任一个多播接收客户端节点提供给请求加入的客户端节点，以免造成该子网的输出流量异常大)；
(14)当有某个客户端节点(可以是图1中的客户端节点1-5)退出直播网络时，调度服务器要根据当前网络拓扑情况，选择一个多播接收客户端节点或底层客户端节点替代退出的客户端节点(调度服务器若选择底层客户端节点，则一般选择层数最大的，也可以兼顾距离、延迟等信息进行选择)；
(15)调度服务器保存一份详细记录该网络的拓扑结构网络拓扑表，当有客户端节点加入或退出该网络时(即网络拓扑结构发生变化)，该网络拓扑表也动态实时更新；
(16)在调度服务器的调度过程中，每个客户端节点的提供媒体流的客户端节点的层次数都比该客户端节点的层次数小(从而保证调度服务器在流调度过程中不产生环状网络结构，确保每个客户端节点都可以直接或间接地从流媒体服务器获取最新的媒体流数据)；
(19)在调度服务器的调度过程中，将每个不能对外提供媒体流的客户端节点分配到直播网络的最底端，使其成为底层客户端节点；
(20)直播环境下存在多个频道的处理，可以同时运行多个调度服务器，也可以在同一调度服务器上开启不同端口予以支持，每一个调度服务器或每一个端口均在逻辑上维护各自的网络。
在上述第(13)步骤中当有新的客户端节点申请加入直播网络时，调度服务器的调度方法，具体包括以下步骤：
(13.1)若请求加入的客户端节点(如图1中的客户端节点5)所在子网内没有或只有一个其他的客户端节点时(可认为请求加入的客户端节点不在该子网内)，则调度服务器向请求加入的客户端节点分配该子网以外的若干个(数量可以比较多)客户端节点或流媒体服务器给请求加入的客户端节点作为提供媒体流的候选客户端节点，请求加入的客户端节点通过比较(如比较与它们之间的延迟、比较它们的历史信息等等)，选择若干个客户端节点作为提供媒体流的客户端节点，此时请求加入的客户端节点工作在P2P模式；
(13.2)如果请求加入的客户端节点(如图1中的客户端节点3，5)所在子网内有2个或2个以上的客户端节点，则可以采用P2P模式(方法如步骤(13.1)所述)，也可以采用组播模式加入到整个直播网络中；
(13.3)在步骤(13.2)中，若请求加入的客户端节点(如图1中的客户端节点5)采用组播的方式加入直播网络，则根据原先该子网内是否存在其他多播接收客户端节点，确定新客户端节点加入的调度方法；
(13.4)在步骤(13.3)中，若原先该子网内存在其他多播接收客户端节点，则调度服务器将请求加入的客户端节点的地址和端口号告知该子网内的所有多播客户端节点，每个多播客户端节点将请求加入的客户端节点的信息加入到各自得组播列表中；
(13.5)在步骤(13.3)中，若原先该子网内不存在其他多播接收客户端节点，则调度服务器将告知该子网内所有的工作在P2P模式下的客户端节点，使它们进入组播状态，之后回步骤(13.4)。
在上述第(14)步骤中，当有某个客户端节点退出直播网络时，调度服务器的调度方法，具体包括以下步骤：
(14.1)如果退出的客户端节点(如图2中的客户端节点2)所在的子网内部存在多播接收客户端节点，且退出的客户端节点本身是一个多播客户端节点，则将退出的客户端节点的工作全部转移到该子网内的一个多播接收客户端节点上，该多播接收客户端节点与退出的客户端节点的所有提供媒体流的客户端节点建立连接，从而获得所有的媒体流数据，同时接受退出的客户端节点的所有接收媒体流的客户端节点的请求；
(14.2)如果退出的客户端节点(如图2中的客户端节点3)所在的子网内部存在多播接收客户端节点，且退出的客户端节点本身是一个多播接收客户端节点，则将该退出的客户端节点从该网络的拓扑表中删除；
(14.3)如果退出的客户端节点(如图3中的客户端节点4)所在的子网内部不存在多播接收客户端节点(可认为请求加入的客户端节点不在该子网内)，则分配一个底层客户端节点来代替退出的客户端节点(分配的底层客户端节点一般是层次数较大的，这样可以使得整个组播网络的层次数保持在较小的水平上，有利于减小网络延迟，同时也应该兼顾距离、带宽等因素)。
(14.4)如果退出的客户端节点为底层客户端节点(如图3中的客户端节点5)，则将该退出的客户端节点从该网络的拓扑表中删除；
在上述第(15)步骤中，拓扑表动态实时更新的方法，具体包括以下步骤：
(15.1)每个客户端节点都必须定期向调度服务器发送存活信号，表示自己仍然处于网络中，并且还在工作，如果某个客户端节点在给定的时间阈值(例如120秒)内没有发送存活信号，则认为该客户端节点已经退出直播网络，并将其从拓扑表中删除，之后按客户端节点退出的调度方法处理；
(15.2)在步骤(15.1)中，每个客户端节点向调度服务器发送存活信号的时间间隔在一个给定的范围内随机变化，以防止拥塞，要求该范围在服务器设置的超时阈值之内(例如，80～110秒，根据缓存大小、延迟等信息设定时间间隔变化范围)；
(15.3)当组播网络的规模大于设定的规模阈值(目前都是采用分级监听策略)时，采用分级监听的方法动态更新拓扑表，一般分级监听所设定的超时阈值在较服务器的超时阈值小(如20秒)；该分级监听的具体方法为：种子客户端节点(如图1中的客户端节点1，2)是唯一直接向调度服务器发送存活信号的客户端节点；除种子客户端节点以外的所有客户端节点(如图1中的客户端节点3-5)，直接向提供媒体流的客户端节点或多播客户端节点发送存活信号(如图1中的客户端节点3向客户端节点2发送存活信号，客户端节点4向客户端节点2或3发送存活信号，客户端节点5向客户端节点4发送存活信号)；若提供媒体流的客户端节点或多播客户端节点在该时间阈值内没有收到某个客户端节点的存活信号，直接通知调度服务器；调度服务器将在该时间阈值内没有发送存活信号的客户端节点从拓扑表中删除，之后按客户端节点退出的调度方法处理。
Claims (4)
1、一种鲁棒的基于点对点的流调度方法，包括组网方法和调度方法，其特征在于，所述的组网方法包括以下步骤：
(1)在直播网络中，调度服务器为客户端节点找到其他的客户端节点，并通知流媒体服务器向客户端节点提供媒体流；
(2)流媒体服务器向客户端节点提供稳定的媒体流；
(3)客户端节点接收来自流媒体服务器或提供媒体流的客户端节点的媒体流，并缓存媒体流，在该客户端节点播放媒体流的同时，通过点对点方式向其他客户端节点提供媒体流；
(4)在步骤(3)中的客户端节点中，若在点对点传输过程中，向其他客户端节点提供媒体流，则该客户端节点称为提供媒体流的客户端节点，否则该客户端节点称为底层客户端节点；
(5)在步骤(3)中的客户端节点中，若在点对点传输过程中，接收来自流媒体服务器或接收提供媒体流的客户端节点的媒体流，则该客户端节点称为接收媒体流的客户端节点；
(6)在步骤(3)中的客户端节点中，若位于某一个子网内部，并且向其他客户端节点提供媒体流，则该客户端节点称为多播客户端节点；
(7)在步骤(3)中的客户端节点中，若位于某一个子网内部，且只接收来自同一子网内其他多播客户端节点的媒体流，同时不向子网外其他客户端提供媒体流，则该客户端节点称为多播接收客户端节点；
(8)在步骤(3)中的客户端节点中，可同时是提供媒体流的客户端节点、接收媒体流的客户端节点和多播客户端节点，但只要它是提供媒体流的客户端节点、接收媒体流的客户端节点和多播客户端节点三者之一，它就不能是多播接收客户端节点；
(9)在步骤(3)中的客户端节点中，如果正在请求加入直播网络，则该客户端节点称为请求加入的客户端节点；
(10)在步骤(3)中的客户端节点中，如果正在请求或已强行退出直播网络，则该客户端节点称为退出的客户端节点；
(11)步骤(3)中的客户端节点，如果直接从流媒体服务器获得媒体流，则该客户端节点称为种子客户端节点；
(12)流媒体服务器位于该网络的第0层；种子客户端节点位于该网络的第1层；若某个客户端节点由若干个提供媒体流的客户端节点提供媒体流，则它位于网络的层次是所有提供媒体流的客户端节点中最大的层次加一；如果某个客户端节点是由某个多播客户端节点提供媒体流，则它的层次是多播客户端节点的层次加一；网络中层次序号是用来估计媒体流在网络中产生的延迟；
所述调度方法，包括如下步骤：
(13)当有新的客户端节点申请加入直播网络时，必须先与所述调度服务器连接，通过调度服务器分配提供媒体流的客户端节点或多播客户端节点为其提供媒体流；
(14)当有某个客户端节点退出直播网络时，调度服务器要根据当前网络拓扑情况，选择一个多播接收客户端节点或底层客户端节点替代退出的客户端节点；
(15)调度服务器保存一份详细记录该网络的拓扑结构网络拓扑表，当有客户端节点加入或退出该网络时，该网络拓扑表也动态实时更新；
(16)在调度服务器的调度过程中，每个客户端节点的提供媒体流的客户端节点的层次数都比该客户端节点的层次数小；
(19)在调度服务器的调度过程中，将每个不能对外提供媒体流的客户端节点分配到直播网络的最底端，使其成为底层客户端节点；
(20)直播环境下存在多个频道的处理，可以同时运行多个调度服务器，也可以在同一调度服务器上开启不同端口予以支持，每一个调度服务器或每一个端口均在逻辑上维护各自的网络；
所述第(14)步骤中，当有某个客户端节点退出直播网络时，调度服务器的调度方法，具体包括以下步骤：
(14.1)如果退出的客户端节点所在的子网内部存在多播接收客户端节点；且退出的客户端节点本身是一个多播客户端节点，则将退出的客户端节点的工作全部转移到该子网内的一个多播接收客户端节点上，该多播接收客户端节点与退出的客户端节点的所有提供媒体流的客户端节点建立连接，从而获得所有的媒体流数据，同时接受退出的客户端节点的所有接收媒体流的客户端节点的请求；
(14.2)如果退出的客户端节点所在的子网内部存在多播接收客户端节点，且退出的客户端节点本身是一个多播接收客户端节点，则将该退出的客户端节点从该网络的拓扑表中删除；
(14.3)如果退出的客户端节点所在的子网内部不存在多播接收客户端节点，则分配一个底层客户端节点来代替退出的客户端节点；
(14.4)如果退出的客户端节点为底层客户端节点，则将该退出的客户端节点从该网络的拓扑表中删除。
2、如权利要求1所述的方法，其特征在于，在所述第(13)步骤中当有新的客户端节点申请加入直播网络时，调度服务器的调度方法，具体包括以下步骤：
(13.1)若请求加入的客户端节点所在子网内没有或只有一个其他的客户端节点时，则调度服务器向请求加入的客户端节点分配该子网以外的若干个客户端节点或流媒体服务器给请求加入的客户端节点作为提供媒体流的候选客户端节点，请求加入的客户端节点通过比较，选择若干个客户端节点作为提供媒体流的客户端节点，此时请求加入的客户端节点工作在P2P模式；
(13.2)如果请求加入的客户端节点所在子网内有2个或2个以上的客户端节点，则可以采用P2P模式，也可以采用组播模式加入到整个直播网络中；
(13.3)在步骤(13.2)中，若请求加入的客户端节点采用组播的方式加入直播网络，则根据原先该子网内是否存在其他多播接收客户端节点，确定新客户端节点加入的调度方法；
(13.4)在步骤(13.3)中，若原先该子网内存在其他多播接收客户端节点，则调度服务器将请求加入的客户端节点的地址和端口号告知该子网内的所有多播客户端节点，每个多播客户端节点将请求加入的客户端节点的信息加入到各自得组播列表中；
(13.5)在步骤(13.3)中，若原先该子网内不存在其他多播接收客户端节点，则调度服务器将告知该子网内所有的工作在P2P模式下的客户端节点，使它们进入组播状态，之后回步骤(13.4)。
3、如权利要求1所述的方法，其特征在于，在所述第(15)步骤中，拓扑表动态实时更新的方法，具体包括以下步骤：
(15.1)每个客户端节点都必须定期向调度服务器发送存活信号，表示自己仍然处于网络中，并且还在工作，如果某个客户端节点在给定的时间阈值内没有发送存活信号，则认为该客户端节点已经退出直播网络，并将其从拓扑表中删除，之后按客户端节点退出的调度方法处理；
(15.2)在步骤(15.1)中，每个客户端节点向调度服务器发送存活信号的时间间隔在一个给定的范围内随机变化；
(15.3)当组播网络的规模大于设定的规模阈值时，采用分级监听的方法动态更新拓扑表。
4、如权利要求3所述的方法，其特征在于，该分级监听方法具体包括：种子客户端节点是唯一直接向调度服务器发送存活信号的客户端节点；除种子客户端节点以外的所有客户端节点，直接向提供媒体流的客户端节点或多播客户端节点发送存活信号；若提供媒体流的客户端节点或多播客户端节点在该时间阈值内没有收到某个客户端节点的存活信号，直接通知调度服务器；调度服务器将在该时间阈值内没有发送存活信号的客户端节点从拓扑表中删除，之后按客户端节点退出的调度方法处理。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CNB2004100867111A CN1314250C (zh) | 2004-10-29 | 2004-10-29 | 一种鲁棒的基于点对点的流调度方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CNB2004100867111A CN1314250C (zh) | 2004-10-29 | 2004-10-29 | 一种鲁棒的基于点对点的流调度方法 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN1604569A CN1604569A (zh) | 2005-04-06 |
| CN1314250C true CN1314250C (zh) | 2007-05-02 |
Family
ID=34667106
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CNB2004100867111A Expired - Fee Related CN1314250C (zh) | 2004-10-29 | 2004-10-29 | 一种鲁棒的基于点对点的流调度方法 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN1314250C (zh) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2009155801A1 (zh) * | 2008-06-27 | 2009-12-30 | 华为技术有限公司 | 提供媒体流服务的方法及其系统和装置 |
Families Citing this family (31)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| DE102005030073A1 (de) * | 2005-06-27 | 2006-12-28 | Airbus Deutschland Gmbh | Fehlertolerantes Datenübertragungssystem in einem Passagierflugzeug |
| US7742485B2 (en) * | 2005-07-29 | 2010-06-22 | Roxbeam Media Network Corporation | Distributed system for delivery of information via a digital network |
| CN100459520C (zh) * | 2005-12-23 | 2009-02-04 | 华为技术有限公司 | 一种多流服务器间共享内存Cache的系统和方法 |
| CN100452876C (zh) * | 2006-02-24 | 2009-01-14 | 清华大学 | 流媒体数据的并行传输调度方法 |
| CN1937553B (zh) * | 2006-05-11 | 2010-05-12 | 蓝汛网络科技（北京）有限公司 | 基于流媒体数据帧的对等网络数据调度方法 |
| CN101068173B (zh) * | 2006-06-08 | 2010-11-03 | 腾讯科技（深圳）有限公司 | 一种资源共享的方法、系统及服务器 |
| CN1897588B (zh) * | 2006-06-21 | 2010-06-16 | 北京北大方正电子有限公司 | 一种混合模式的网络文件传输方法及系统 |
| CN100405773C (zh) * | 2006-07-14 | 2008-07-23 | 北京时越网络技术有限公司 | 一种基于内容分发网络系统的点对点内容再分发方法 |
| CN101282281B (zh) * | 2007-04-03 | 2011-03-30 | 华为技术有限公司 | 一种媒体分发系统、装置及流媒体播放方法 |
| CN100461740C (zh) * | 2007-06-05 | 2009-02-11 | 华为技术有限公司 | 一种客户端节点网络拓扑构造方法及流媒体分发系统 |
| CN101102312B (zh) * | 2007-06-11 | 2010-06-02 | 华为技术有限公司 | 一种网络通信数据处理方法、网络通信系统及客户端 |
| CN101340359B (zh) * | 2007-07-04 | 2011-09-21 | 中兴通讯股份有限公司 | 多播广播业务调度方法 |
| CN101340556B (zh) * | 2007-07-05 | 2013-02-20 | 株式会社Ntt都科摩 | 现实世界直播系统及直播方法 |
| CN101355468B (zh) * | 2007-07-23 | 2011-03-16 | 中国科学院声学研究所 | 一种p2p流媒体信息发布的方法 |
| CN101090525B (zh) * | 2007-08-06 | 2012-05-23 | 中兴通讯股份有限公司 | 多播广播业务调度方法 |
| CN101365128A (zh) | 2007-08-10 | 2009-02-11 | 中兴通讯股份有限公司 | 综合视频业务对等网络系统 |
| CN101159676B (zh) * | 2007-11-06 | 2010-09-08 | 深圳市迅雷网络技术有限公司 | 一种数据传输的方法及系统 |
| CN101170506B (zh) * | 2007-12-06 | 2010-06-02 | 北京广视通达网络技术有限公司 | 一种基于应答驱动的p2p流媒体数据调度方法 |
| CN101262369B (zh) * | 2008-03-28 | 2011-05-11 | 华为技术有限公司 | 调度服务器的主备实现方法及调度服务器 |
| CN101304405B (zh) * | 2008-04-30 | 2012-02-01 | 中山大学 | 一种基于svc的p2p流媒体传输方法 |
| CN101588468B (zh) * | 2008-05-20 | 2013-08-07 | 华为技术有限公司 | 一种基于p2p的媒体播放方法、装置和系统 |
| CN101986611B (zh) * | 2010-11-30 | 2012-11-28 | 东南大学 | 基于两级缓存的快速组流方法 |
| CN102118310B (zh) * | 2011-01-19 | 2013-07-03 | 华中科技大学 | 基于网络编码分级流媒体多播的资源调度方法 |
| CN102740165B (zh) * | 2011-04-01 | 2015-07-15 | 中国电信股份有限公司 | 对等流媒体直播系统及其中的数据传输方法 |
| CN104468604A (zh) * | 2014-12-19 | 2015-03-25 | 北京奇虎科技有限公司 | 局域网中基于对等网络通信模式的数据访问方法及装置 |
| CN105812848B (zh) * | 2014-12-31 | 2019-08-16 | 深圳Tcl新技术有限公司 | 电视网络数据获取方法及服务器 |
| CN106210776A (zh) * | 2015-05-07 | 2016-12-07 | 南宁富桂精密工业有限公司 | 控制设备及其控制视频点播的方法 |
| CN104918065A (zh) * | 2015-05-25 | 2015-09-16 | 南京邮电大学 | 基于rtsp实现移动音视频直播的系统及方法 |
| CN105979284B (zh) * | 2016-05-10 | 2019-07-19 | 杨�远 | 移动终端视频共享方法 |
| CN108089934B (zh) * | 2016-11-22 | 2021-08-03 | 成都华为技术有限公司 | 集群管理方法及集群服务器 |
| CN110071942A (zh) * | 2019-05-20 | 2019-07-30 | 湖南康通电子股份有限公司 | 数字广播系统的组网直播流分发方法、装置及存储介质 |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2001099374A2 (en) * | 2000-06-22 | 2001-12-27 | Apple Computer, Inc. | Methods and apparatuses for transferring data |
| CN1406070A (zh) * | 2002-11-01 | 2003-03-26 | 清华大学 | 一种基于实时流媒体的现场点播方法 |
-
2004
- 2004-10-29 CN CNB2004100867111A patent/CN1314250C/zh not_active Expired - Fee Related
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2001099374A2 (en) * | 2000-06-22 | 2001-12-27 | Apple Computer, Inc. | Methods and apparatuses for transferring data |
| CN1406070A (zh) * | 2002-11-01 | 2003-03-26 | 清华大学 | 一种基于实时流媒体的现场点播方法 |
Non-Patent Citations (3)
| Title |
|---|
| 基于RTP/RTCP的流媒体服务器技术研究 赵进，叶梧，冯穗力，中国有线电视，第1卷 2004 * |
| 基于RTP/RTCP的流媒体服务器技术研究 赵进，叶梧，冯穗力，中国有线电视，第1卷 2004;流媒体技术概述 邸春红，于淑玲，杜勇，沈阳医学院学报，第6卷第1期 2004 * |
| 流媒体技术概述 邸春红，于淑玲，杜勇，沈阳医学院学报，第6卷第1期 2004 * |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2009155801A1 (zh) * | 2008-06-27 | 2009-12-30 | 华为技术有限公司 | 提供媒体流服务的方法及其系统和装置 |
| CN101616170B (zh) * | 2008-06-27 | 2012-09-19 | 华为技术有限公司 | 提供媒体流服务的方法及其系统 |
Also Published As
| Publication number | Publication date |
|---|---|
| CN1604569A (zh) | 2005-04-06 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN1314250C (zh) | 一种鲁棒的基于点对点的流调度方法 | |
| Liu et al. | Opportunities and challenges of peer-to-peer internet video broadcast | |
| CN101068236A (zh) | 流媒体码率控制方法、系统和设备 | |
| CN101068336A (zh) | 一种对等连接流媒体直播系统和装置 | |
| CN1475063A (zh) | 通信网络中的子组多播 | |
| CN1929638A (zh) | 一种无线局域网ip组播帧传输的组播成员管理方法 | |
| CN1645858A (zh) | 分布式对等流媒体的服务系统及其点播节目的实现方法 | |
| CN1575565A (zh) | 在通用移动电信系统网络中进行组播的方法和装置 | |
| EP1708506A3 (en) | Rapid media channel changing mechanism and access network node comprising same | |
| CN101034960A (zh) | 一种远程多人会议的实现方法及相应系统 | |
| CN1309211C (zh) | 一种分布式网络环境中异型网络设备的分布式集中管理方法 | |
| CN1315312C (zh) | 一种大规模多媒体接入网关的方法 | |
| CN1901504A (zh) | 一种流媒体点播系统的数据调度方法 | |
| CN1925403A (zh) | 实现文件下载的网络通信系统及方法 | |
| CN1328868C (zh) | 在分布式对等流媒体服务系统中实现可靠组播的方法 | |
| CN102883190A (zh) | 优化分配带宽的点播方法和装置 | |
| US9385877B2 (en) | Multicast systems, methods, and computer program products | |
| CN101272404A (zh) | 一种p2p视频直播系统数据调度中的链路选择方法 | |
| CN1933413A (zh) | 一种无线局域网ip组播帧传输的组播成员管理方法 | |
| CN1933460A (zh) | 无线局域网传输组播帧的设备、系统及实现方法 | |
| CN101035088A (zh) | 实现本地特定业务二层互通的方法、系统和接入设备 | |
| CN1592250A (zh) | 一种流媒体数据多点传输方法 | |
| KR101252947B1 (ko) | 비디오 청크 분포에 적응적인 푸쉬-풀 혼성 스트리밍 방법 및 장치 | |
| CN1859623A (zh) | 一种实现流媒体业务的方法 | |
| CN1859146A (zh) | 组播数据下发方法及实现该方法的数据下发装置和终端 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| C06 | Publication | ||
| PB01 | Publication | ||
| C10 | Entry into substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| C14 | Grant of patent or utility model | ||
| GR01 | Patent grant | ||
| CF01 | Termination of patent right due to non-payment of annual fee | ||
| CF01 | Termination of patent right due to non-payment of annual fee |
Granted publication date: 20070502 Termination date: 20211029 |