一种流媒体组播结构及其数据流发送和接收方法

文档序号:7824216阅读:142来源:国知局
一种流媒体组播结构及其数据流发送和接收方法
【专利摘要】本发明公开了一种流媒体组播结构及其数据流发送和接收方法,采用C/S模式,以流媒体发送源为服务器端,以流媒体接收设备为客户端,能够不借助于交换机或者路由器在IGMP协议的支持和配置下使组播数据包能够跨越大中小型局域网内的各个不同网段,从而实现流媒体IP组播技术的应用。本发明在跨网段的环境下,无需修改路由器配置和组播路由协议的环境下,实现了组播业务流的单向传输,非常适合在音视频组播业务流单向推送的应用系统中实施。
【专利说明】一种流媒体组播结构及其数据流发送和接收方法

【技术领域】
[0001]本发明属于多媒体和网络【技术领域】,尤其涉及一种流媒体组播结构及其数据流发送和接收方法。

【背景技术】
[0002]目前流媒体技术广泛应用于网上的新闻发布、在线直播、网络广告、远程教育等领域。如果采用传统的点到点的单播通信方式来实现这种I到多的业务,会消耗大量的网络带宽并且扩展性和部署性都比较差。而IP组播(也称作多址广播或者多播)技术则可以发送单一数据包到特定的组播组,从而使得加入该组播组的主机都能收到该数据包。由于这种方式能够节省大量的网络带宽,使得IP组播技术被广泛应用于网络音视频广播,多媒体远程教育等方面。
[0003]而在数据网络中,虽然容许组播存在,但是其被通常限制在本地子网范围内,如果没有路由器和三层交换机的支持,组播数据会被禁止穿越路由器,从而防止组播数据影响大面积的网路。
[0004]在实际应用中,采用传统的方法来全面部署跨网段组播服务也是一个复杂的系统工程,其复杂性包括:
[0005]1.组播服务涉及网络的各个层面:MAC地址层,IP层,应用层,需要在主机-接入L2交换-L3交换机甚至路由器的每个层次配置相应的组播协议;
[0006]2.网络中的网络交换设备难以保持一致性,品牌较多,不同网络设备对组播的支持水平也参差不齐,有的甚至不支持网管和相关协议,防止交换机端口“泛洪”关机技术“IGMP Snooping”难以在整网中保持一致;
[0007]3.组播应用对网络管理的技术水平相对要求较高,专业性非常强。
[0008]一种跨网段组播数据系统及其方法(专利号:CN 101707526)提出了一种无需修改路由器配置和组播路由协议的环境下,在应用层实现跨网段组播的方法。该方法较好地实现了在应用中简单,快速地部署组播应用,但也存在以下局限性:
[0009]1.针对每个子网,仍需部署额外的coaster节点。
[0010]2.Coaster为每个子网的关键节点,所有的组播流均需要通过coaster传送到子网中,当系统中存在多个组播业务流时,coaster的负载将加大,且一旦coaster节点失效,将会照成整个子网的业务中断。
[0011]目前一般是通过在路由器上配置IGMP协议来实现跨网段组播,但由于IGMP协议发复杂性,在实际工程应用对现场的施工人员和用户均有着较高的技术要求。


【发明内容】

[0012]本发明的目的在于提供一种流媒体组播结构及其数据流发送和接收方法,旨在解决现有通过在路由器上配置IGMP协议来实现跨网段组播,由于IGMP协议发复杂性,在实际工程应用对现场的施工人员和用户均有着较高的问题。
[0013]本发明是这样实现的,一种流媒体组播结构及其数据流发送和接收方法,该流媒体组播结构及其数据流发送和接收方法包括以下步骤:
[0014]步骤一,在业务节点上固定设置服务器的IP地址,业务节点启动后,直接向组播源发送心跳报文;
[0015]步骤二,组播源根据子网信息生成设备查找报文的组播转发表,并发送设备查找报文,报文中包含服务器的IP地址,业务节点接收到此报文后确定当前组播源的IP地址;
[0016]步骤三,组播源在发送设备查找报文时,子网内尚未包含在线的业务节点,则以该子网的默认转发节点为转发节点,有节点上线后,则采用动态调度的方式,始终以最后更新状态的节点来进行转发;
[0017]步骤四,组播源接收到业务节点的心跳报文后,标识为该节点为上线状态,并根据IP地址确定该设备的子网号,节点上线后,组播源启动超时定时器,超时未接收到新的心跳报文,则标识该节点已下线;
[0018]步骤五,组播源发起一路组播业务时,首先通过单播的方式向所有接收该业务的业务节点发送广播启动命令,该命令中包含了用于接收此路流媒体数据的组播地址和端P ;
[0019]步骤六,业务节点接收到广播启动命令后,打开目的端口的UDP接收socket,并加入接收目的组播地址,此时,业务节点同时接收目的端口相同的组播和单播报文,然后,立即向组播源发送状态更新报文;
[0020]步骤七,组播源接每次收到心跳报文,检查当前业务节点的状态是否正确,不正确,重发广播启动命令,广播接收节点的状态正确,则将此节点插入到组播转发表对应子网的队首;
[0021]步骤八,组播源启动广播会话后,随即开始进行流媒体数据的发送;组播源进行流媒体数据转发时,均按照时间戳的要求定时发送;
[0022]步骤九,业务节点接收到广播启动命令后,打开相应UDP端口的SOCKET,并加入该组播业务流的组播地址;
[0023]步骤十,业务节点是以组播方式接收到业务数据后,只进行音频或者视频流的解码回放;是以单播的方式接收到数据,在进行解码回放的同时,将此数据向本子网内进行组播转发;
[0024]步骤十一,同一子网内的不同的业务节点可以同时接收不同的广播业务流,业务流的转发均由参与此业务流的节点完成。
[0025]进一步,在步骤二中,发送设备查找报文和步骤八组播源进行流媒体数据转发时定时发送的具体步骤如下:
[0026]首先读取首个子网阵列,然后判断子网阵列是否为空,为空则结束;子网阵列不为空,则判断阵列成员是否为空,为空,则读取下一个阵列,阵列成员不为空,则判断组播源是否为本地子网,不为本地子网,则单播发送到队列的首个节点,在读取下一个队列,重新读取首个子网阵列;为本地子网,则组播发送到本地子网,在读取下一个队列,重新读取首个子网阵列。
[0027]进一步,在步骤十中,业务节点以组播方式接收到业务数据的具体步骤如下:
[0028]首先打开命令接收socket,等待接收服务器数据,之后判断数据类型,数据类型为广播启动命令,则打开业务流接收socket,加入组播地址,以发送状态更新报文,返回打开命令接收socket ;数据类型为广播停止命令,则关闭业务流接收socket,则退出组播地址,以发送状态更新报文,返回打开命令接收socket ;数据类型为业务流,则判断是否为组播报文,是组播报文,则进行音视频解码回放,返回等待接收服务器数据;是单播报文,则向目的组播地址和端口转发报文,则进行音视频解码回放,返回等待接收服务器数据。
[0029]进一步,在步骤十一中,组播源进行业务流发送时,始终选取各网段内参与此业务的最后更新状态的业务节点作为转发节点,当业务节点退出此业务流时,组播源将立即切换到队列中下一个节点作为转发节点;
[0030]正在进行转发业务节点因各种原因失效后,将不再发送心跳报文,当组播源接收收到参与相同业务的其它节点的心跳报文时,自动切换至该节点进行转发。
[0031]本发明提供的流媒体组播结构及其数据流发送和接收方法,采用C/S模式,以流媒体发送源为服务器端,以流媒体接收设备为客户端,能够不借助于交换机或者路由器在IGMP协议的支持和配置下使组播数据包能够跨越大中小型局域网内的各个不同网段,从而实现流媒体IP组播技术的应用。本发明在跨网段的环境下,无需修改路由器配置和组播路由协议的环境下,实现了组播业务流的单向传输,非常适合在音视频组播业务流单向推送的应用系统中实施。
[0032]本发明与现有技术相比:
[0033]1.在实际工程应该中,无需更改路由器设置的,可以快速,简单地部署跨网段组播。
[0034]2.在进行组播业务转发的过程中,由于采用了动态调整各个子网内业务转发节点的策略,避免了单个节点失效导致大面积业务中断的状况,增强跨网段组播传输系统的健壮性。
[0035]3.由于组播业务转发均由参与业务流的业务节点完成,有效地实现跨网段组播传输的负载均担和流量平衡,提高了组播业务系统的并发性。

【专利附图】

【附图说明】
[0036]图1是本发明实施例提供的流媒体组播结构及其数据流发送和接收方法流程图;
[0037]图2是本发明实施例提供的网络拓扑示意图;
[0038]图3是本发明实施例提供的组播转发表的逻辑结构示意图;
[0039]图4是本发明实施例提供的组播源在发送组播业务流时流程图;
[0040]图5是本发明实施例提供的业务节点的组播业务流的接收和转发流程图。

【具体实施方式】
[0041]为了使本发明的目的、技术方案及优点更加清楚明白,以下结合实施例,对本发明进行进一步详细说明。应当理解,此处所描述的具体实施例仅仅用以解释本发明,并不用于限定本发明。
[0042]下面结合附图及具体实施例对本发明的应用原理作进一步描述。
[0043]如图1所示,本发明实施例的流媒体组播结构及其数据流发送和接收方法包括以下步骤:
[0044]SlOl:在业务节点上固定设置服务器的IP地址,业务节点启动后,可直接向组播源发“送心跳报文”;
[0045]S102:组播源根据子网信息生成“设备查找报文”的组播转发表,并发送“设备查找报文”,该报文中包含服务器的IP地址,业务节点接收到此报文后可确定当前组播源的IP地址;
[0046]S103:组播源在发送“设备查找报文”时,若子网内尚未包含在线的业务节点,则以该子网的默认转发节点为转发节点,一旦有节点上线后,则采用动态调度的方式,始终以最后更新状态的节点来进行转发;
[0047]S104:组播源接收到业务节点的“心跳报文”后,标识为该节点为上线状态,并根据IP地址确定该设备的子网号,节点上线后,组播源启动超时定时器,若超时未接收到新的心跳报文,则标识该节点已下线;
[0048]S105:组播源发起一路组播业务时,首先通过单播的方式向所有接收该业务的业务节点发送“广播启动命令”,该命令中包含了用于接收此路流媒体数据的组播地址和端P ;
[0049]S106:业务节点接收到广播启动命令后,打开目的端口的UDP接收socket,并加入接收目的组播地址。此时,业务节点可同时接收目的端口相同的组播和单播报文。然后,立即向组播源发送状态更新报文;
[0050]S107:组播源接每次收到“心跳报文”,均需要检查当前业务节点的状态是否正确,若不正确,需重发“广播启动命令”。如果广播接收节点的状态正确,则将此节点插入到组播转发表对应子网的队首;
[0051]S108:组播源启动广播会话后,随即开始进行流媒体数据的发送。流媒体数据源可以是预先上传的音视频文件,也可以是其它采集设备通过单播发送过来的实时数据;组播源进行流媒体数据转发时,均按照时间戳的要求定时发送;
[0052]S109:业务节点接收到“广播启动命令”后,打开相应UDP端口的SOCKET,并加入该组播业务流的组播地址;
[0053]SllO:业务节点如果是以组播方式接收到业务数据后,只进行音频或者视频流的解码回放;如果是以单播的方式接收到数据,在进行解码回放的同时,还需将此数据向本子网内进行组播转发;
[0054]Slll:同一子网内的不同的业务节点可以同时接收不同的广播业务流,业务流的转发均由参与此业务流的节点完成。
[0055]在步骤S102中,发送“设备查找报文”和步骤S108组播源进行流媒体数据转发时定时发送的具体步骤如下:
[0056]首先读取首个子网阵列,然后判断子网阵列是否为空,若为空则结束;若子网阵列不为空,则判断阵列成员是否为空,若为空,则读取下一个阵列,阵列成员不为空,则判断组播源是否为本地子网,不为本地子网,则单播发送到队列的首个节点,在读取下一个队列,重新读取首个子网阵列;若为本地子网,则组播发送到本地子网,在读取下一个队列,重新读取首个子网阵列;
[0057]在步骤SllO中,业务节点以组播方式接收到业务数据的具体步骤如下:
[0058]首先打开命令接收socket,等待接收服务器数据,之后判断数据类型,数据类型为广播启动命令,则打开业务流接收socket,加入组播地址,以发送状态更新报文,返回打开命令接收socket ;若数据类型为广播停止命令,则关闭业务流接收socket,则退出组播地址,以发送状态更新报文,返回打开命令接收socket ;若数据类型为业务流,则判断是否为组播报文,是组播报文,则进行音视频解码回放,返回等待接收服务器数据;是单播报文,则向目的组播地址和端口转发报文,则进行音视频解码回放,返回等待接收服务器数据。
[0059]在步骤Slll中,一旦业务节点退出此业务流,将不再参与此业务流的转发。组播源进行业务流发送时,始终选取各网段内参与此业务的最后更新状态的业务节点作为转发节点。当业务节点退出此业务流时,组播源将立即切换到队列中下一个节点作为转发节点。
[0060]如果正在进行转发业务节点因各种原因失效后,将不再发送“心跳报文”。当组播源接收收到参与相同业务的其它节点的“心跳报文”时,自动切换至该节点进行转发,从而实现业务的快速恢复。
[0061]本发明的具体步骤:
[0062]1、设备发现:
[0063]静态配置方式,即在业务节点上固定设置服务器的IP地址,业务节点启动后,可直接向组播源发“送心跳报文”。
[0064]动态发现方式,组播源根据子网信息生成“设备查找报文”的组播转发表,并按照图4所示的流程发送“设备查找报文”,该报文中包含服务器的IP地址,业务节点接收到此报文后可确定当前组播源的IP地址。
[0065]组播源在发送“设备查找报文”时,若子网内尚未包含在线的业务节点,则以该子网的默认转发节点为转发节点,一旦有节点上线后,则采用动态调度的方式,始终以最后更新状态的节点来进行转发。
[0066]组播源接收到业务节点的“心跳报文”后,标识为该节点为上线状态,并根据IP地址确定该设备的子网号。节点上线后,组播源启动超时定时器,若超时未接收到新的心跳报文,则标识该节点已下线。
[0067]2、组播业务流程(音视频广播):
[0068]组播源发起一路组播业务时,首先通过单播的方式向所有接收该业务的业务节点发送“广播启动命令”,该命令中包含了用于接收此路流媒体数据的组播地址和端口。
[0069]业务节点接收到广播启动命令后,打开目的端口的UDP接收socket,并加入接收目的组播地址。此时,业务节点可同时接收目的端口相同的组播和单播报文。然后,立即向组播源发送状态更新报文。
[0070]由于“广播启动命令”是UDP报文,为保证系统的健壮性,业务节点还需定时向组播源报告当前的业务状态。组播源接每次收到“心跳报文”,均需要检查当前业务节点的状态是否正确,若不正确,需重发“广播启动命令”。如果广播接收节点的状态正确,则将此节点插入到组播转发表对应子网的队首。
[0071]组播源启动广播会话后,随即开始进行流媒体数据的发送。流媒体数据源可以是预先上传的音视频文件,也可以是其它采集设备通过单播发送过来的实时数据。
[0072]组播源进行流媒体数据转发时,均按照时间戳的要求定时发送。发送方式采用图4所示的流程进行发送。
[0073]业务节点接收到“广播启动命令”后,打开相应UDP端口的SOCKET,并加入该组播业务流的组播地址。
[0074]业务节点如果是以组播方式接收到业务数据后,只进行音频或者视频流的解码回放;如果是以单播的方式接收到数据,在进行解码回放的同时,还需将此数据向本子网内进行组播转发。具体流程如图5所示。
[0075]3、负载均衡和容错:
[0076]同一子网内的不同的业务节点可以同时接收不同的广播业务流,业务流的转发均由参与此业务流的节点完成。
[0077]—旦业务节点退出此业务流,将不再参与此业务流的转发。组播源进行业务流发送时,始终选取各网段内参与此业务的最后更新状态的业务节点作为转发节点。当业务节点退出此业务流时,组播源将立即切换到队列中下一个节点作为转发节点。
[0078]如果正在进行转发业务节点因各种原因失效后,将不再发送“心跳报文”。当组播源接收收到参与相同业务的其它节点的“心跳报文”时,自动切换至该节点进行转发,从而实现业务的快速恢复。
[0079]本发明的工作原理:
[0080]本发明的目的在于提供一种基于C/S模式的流媒体跨网段IP组播支持技术。使得流媒体组播数据能够在不依赖于路由器和交换机的支持在局域网的各个子网段进行穿越和分发。
[0081]在应用本技术的多媒体音视频可寻址分组广播系统中,流媒体服务器实现了组播源的功能,业务节点为各个独立的音视频广播接收节点。
[0082]组播源上采用静态方式配置部署业务节点的子网信息(子网号和子网掩码),并为每个子网上设置一个默认的“转发设备查找报文”的业务节点。
[0083]本发明的具体实施例:
[0084]本发明适合在音视频组播业务流单向推送的应用系统中实施;
[0085]应用系统由组播源和业务节点组成,网络拓扑如图2所示;业务节点可以部署在组播源的同网段中,也可以分布在各个不同的子网中;
[0086]组播源的技术特征为:
[0087]负责构建,维护系统中的网络拓扑结构和所有节点的在线状态;
[0088]组播源可主动并行发起多路内容为音视频广播的组播业务,并通过单播命令相关的业务节点进入业务接收状态,随后采用UDP方式发送组播业务流至相关的业务节点;
[0089]组播源为系统的组播业务(音视频广播)的发起者和组播业务流的数据源.组播业务流通常为实时的音频或者视频数据流,在本系统中采用UDP组播方式传送;
[0090]组播源通过接收业务节点的“心跳报文”和“状态更新报文”实时更新当前所有业务节点的在线状态和当前的业务流状态,并动态维护所有组播业务流的组播转发表;
[0091]组播转发表的逻辑结构如图3所示;每个业务流的组播转发表由多个子网队列构成,每个子网队列包含了当前子网中所有接收此组播业务流的业务节点;组播源根据业务节点的状态上报信息动态更新转发表,各子网队列通过业务节点的状态更新时间进行排序,即最后上报状态的节点始终排在队列的首位;
[0092]组播源在发送组播业务流时,需遍历当前组播业务转发表的子网队列不为空的队列,如果是组播源所处子网,则以组播的方式发送报文,否则,向子网队列中排在首位的业务节点以单播的方式发送业务流数据,具体流程如图4所示;
[0093]为避免业务节点失效导致大面积业务中断,组播源还为每个业务节点设置的超时机制,如果长时间未接收到业务节点的“心跳报文”或者“状态更新报文”,则判断此节点失效,并从转发表中删除此节点;
[0094]业务节点的技术特征:
[0095]业务节点将定期(间隔5秒)将本机的状态通过“心跳报文”以单播UDP的方式上报给组播源;
[0096]组播源的IP地址可通过静态配置或者动态查找的方式获得;
[0097]接收到组播业务(音视频广播)启动命令后,打开相应Μ)Ρ端口的SOCKET,并加入该组播业务流的组播地址;
[0098]接收到组播业务(音视频广播)停止命令后,关闭相应UDP端口的SOCKET,并退出该组播业务流的组播地址;
[0099]业务节点如果是以组播方式接收到业务流数据后,只进行音频或者视频流的解码回放;如果是以单播的方式接收到数据报文,在进行解码回放的同时,还需将此数据报文向本子网内进行组播转发;
[0100]业务节点可动态地加入或者退出某个组播业务,当退出组播业务后停止接收该组播业务流;
[0101]业务节点的接收状态改变后,需通过“状态更新报文”立即向组播源上报状态;
[0102]业务节点的组播业务流的接收和转发流程如图5所示。
[0103]本发明采用C/S模式,以流媒体发送源为服务器端,以流媒体接收设备为客户端,能够不借助于交换机或者路由器在IGMP协议的支持和配置下使组播数据包能够跨越大中小型局域网内的各个不同网段,从而实现流媒体IP组播技术的应用。
[0104]以上所述仅为本发明的较佳实施例而已,并不用以限制本发明,凡在本发明的精神和原则之内所作的任何修改、等同替换和改进等,均应包含在本发明的保护范围之内。
【权利要求】
1.一种流媒体组播结构及其数据流发送和接收方法,其特征在于,该流媒体组播结构及其数据流发送和接收方法包括以下步骤: 步骤一,在业务节点上固定设置服务器的IP地址,业务节点启动后,直接向组播源发送心跳报文; 步骤二,组播源根据子网信息生成设备查找报文的组播转发表,并发送设备查找报文,报文中包含服务器的IP地址,业务节点接收到此报文后确定当前组播源的IP地址; 步骤三,组播源在发送设备查找报文时,子网内尚未包含在线的业务节点,则以该子网的默认转发节点为转发节点,有节点上线后,则采用动态调度的方式,始终以最后更新状态的节点来进行转发; 步骤四,组播源接收到业务节点的心跳报文后,标识为该节点为上线状态,并根据IP地址确定该设备的子网号,节点上线后,组播源启动超时定时器,超时未接收到新的心跳报文,则标识该节点已下线; 步骤五,组播源发起一路组播业务时,首先通过单播的方式向所有接收该业务的业务节点发送广播启动命令,该命令中包含了用于接收此路流媒体数据的组播地址和端口 ; 步骤六,业务节点接收到广播启动命令后,打开目的端口的m)P接收socket,并加入接收目的组播地址,此时,业务节点同时接收目的端口相同的组播和单播报文,然后,立即向组播源发送状态更新报文; 步骤七,组播源接每次收到心跳报文,检查当前业务节点的状态是否正确,不正确,重发广播启动命令,广播接收节点的状态正确,则将此节点插入到组播转发表对应子网的队首; 步骤八,组播源启动广播会话后,随即开始进行流媒体数据的发送;组播源进行流媒体数据转发时,均按照时间戳的要求定时发送; 步骤九,业务节点接收到广播启动命令后,打开相应m)P端口的socket,并加入该组播业务流的组播地址; 步骤十,业务节点是以组播方式接收到业务数据后,只进行音频或者视频流的解码回放;是以单播的方式接收到数据,在进行解码回放的同时,将此数据向本子网内进行组播转发; 步骤十一,同一子网内的不同的业务节点同时接收不同的广播业务流,业务流的转发均由参与此业务流的节点完成。
2.如权利要求1所述的流媒体组播结构及其数据流发送和接收方法,其特征在于,在步骤二中,发送设备查找报文和步骤八组播源进行流媒体数据转发时定时发送的具体步骤如下: 首先读取首个子网阵列,然后判断子网阵列是否为空,为空则结束;子网阵列不为空,则判断阵列成员是否为空,为空,则读取下一个阵列,阵列成员不为空,则判断组播源是否为本地子网,不为本地子网,则单播发送到队列的首个节点,在读取下一个队列,重新读取首个子网阵列;为本地子网,则组播发送到本地子网,在读取下一个队列,重新读取首个子网阵列。
3.如权利要求1所述的流媒体组播结构及其数据流发送和接收方法,其特征在于,在步骤十中,业务节点以组播方式接收到业务数据的具体步骤如下: 首先打开命令接收socket,等待接收服务器数据,之后判断数据类型,数据类型为广播启动命令,则打开业务流接收socket,加入组播地址,以发送状态更新报文,返回打开命令接收socket ;数据类型为广播停止命令,则关闭业务流接收socket,则退出组播地址,以发送状态更新报文,返回打开命令接收socket ;数据类型为业务流,则判断是否为组播报文,是组播报文,则进行音视频解码回放,返回等待接收服务器数据;是单播报文,则向目的组播地址和端口转发报文,则进行音视频解码回放,返回等待接收服务器数据。
4.如权利要求1所述的流媒体组播结构及其数据流发送和接收方法,其特征在于,在步骤十一中,组播源进行业务流发送时,始终选取各网段内参与此业务的最后更新状态的业务节点作为转发节点,当业务节点退出此业务流时,组播源将立即切换到队列中下一个节点作为转发节点; 正在进行转发业务节点因各种原因失效后,将不再发送心跳报文,当组播源接收收到参与相同业务的其它节点的心跳报文时,自动切换至该节点进行转发。
【文档编号】H04L12/741GK104506441SQ201410837610
【公开日】2015年4月8日 申请日期:2014年12月30日 优先权日:2014年12月30日
【发明者】湛辉来, 钟仁文 申请人:深圳市艾迪思特信息技术有限公司
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1