可靠IP组播论文

可靠IP组播论文（精选6篇）

可靠IP组播论文 第1篇

关键词：视频组播,网络快速收敛,MTBF,MTRR,马尔科夫

0 引言

基于IP组播技术的网络应用正在不断普及, 其中, IP视频网络是此类组播应用中最为常见的技术之一, 如在平安城市、交通监控和机场港口等关键部门的应用等。近几年随着视频编码技术的发展和视频节点规模的扩大, 对组建一个不仅高速而且可靠的IP组播网络提出了更高的要求。其所依赖的网络基础设施, 不仅要求快速和互联互通, 而且要求网络有很好的高可靠度, 特别一些关键部门对IP视频的连续性有很高的要求, 以及对断网的零容忍度, 故视频网络的高可靠度已经成为此类组播应用的核心议题。可靠性可通过平均无故障时间MTBF (Mean Time Between Failures) 和平均修复时间MTTR的计算作为预估的量化值。在MTBF数值固定的情况下, 如何降低MTRR成为了提高视频组播网络可靠性的关键手段。

一个未经合理优化的组播网络在发生故障切换时, 其所需的收敛时间要远远长于常见OA办公自动化网络的单播环境, 并大大低于一般预期值, 表现在视频网络应用时, 视频画面轻则产生马赛克现象, 重则黑屏。

结合作者曾主持设计实现的机场和公安等视频网络重大国内项目建设、优化和排错经验, 系统性地提出了如何降低IP视频组播网的MTRR的多种方法, 并得到更高预期的可靠度值。

1 网络快速收敛理论研究

网络快速收敛技术是指在网络发生故障时, 网络设备能自动快速恢复原有的路由表项并使数据正常转发。MTBF和MT-TR是该领域通常关注的可靠性量化指标;同时, 由于马尔科夫链 (Markov) 模型反应了系统变化的过程, 因此, 也常被用于网络高可靠性研究。

1.1 网络快速收敛概述

根据采用的技术不同, 其性能在秒级乃至亚秒级。

本文考虑的网络收敛时间可以用一个集合C表示, C={C1, C2, , Cn}, 其中元素Ci表示各类影响网络收敛的因素。目前i可以为1~3, 即C1表示物理层因素, C2表示协议层因素, C3表示设备层。而各个元素又可以定义成一个子集合。C1={T1, T2, , Tn}, 其中子元素Tj表示物理层类的因素, 目前j可以为1~2, 即T1表示故障检测, T2表示光电转换, 网络传输。C2={t1, t2, , tn}, 其中子元素ts表示物理量类的因素, 目前s可以为1~5, 即t1表示产生新的LSP/LSA, t2表示到最远的路由器距离, t3表示的是网络泛洪过程, t4表示网络泛洪到最远路由器, t5表示的是采用最短路径树算法计算路由表。C3={D1, D2, , Dn}, 其中子元素Dn表示设备类的因素, 目前n可以为1-2, 即D1表示设备更新路由表和转发表, D2表示把转发表下发到线卡上。

据此, 得到网络收敛时间如下:

具体可表示为:

其中, Tc:全网收敛时间, Tlink:故障检测所需时间, Ttrans:网络传输所需时间, Tlsp:产生新的LSP/LSA所需时间, Thop:到最远的路由器距离跳数, Tflood:网络泛洪到最远路由器所需时间, Tspf:最短路径树计算所需时间, Trib:设备更新路由表和转发表所需时间, Tlc:转发表下发到线卡上所需时间[1]。

整个过程的时序可以如图1所示[2]。

图1中从左到右, 可以看到在每个时间节点上所对应的收敛操作细节和其所需时间。

1.2 高可靠性分析

高可靠性研究领域常见的量化因子是MTBF和MTTR。设备故障次数少, 恢复时间快是高可靠性的特点。结合统计学概念, 可以用“可靠性 (Availability) ”这个参数来进行量化度量:

从上述公式可以看出, 如果要提高可靠性, 可以通过提高MTBF, 或者降低MTTR来实现。

对于用户体验, 一般常用每百万单位缺陷数DPM (Defects Per Million) 表示, 通俗的说法就是4个9 (99.99%) 或者5个9 (99.999%) 的可靠性。不同数量的9意味着不同的可靠度。4个9意味着1年宕机1小时, 5个9意味着1年宕机5分钟。DPM如下式所示:

设备的MTBF值可以采用基于设备元器件的预知可靠性的Telcorida (即原来的Bellcore) 部件计算法[3], 来获得预估值或者根据现实设备故障率来获得实际值, 为达到更加精确的MTBF值也可以将二者结合起来。

设备元器件可以是系统元件 (如电路板等) , 也可以是网络元件 (如交换机, 路由器等) 。所以高可靠性的计算可以计算设备单体, 也可以计算由若干设备单体所搭建的网络整体。

如果任何元器件是必须运行的, 而且任何一个元器件的失效会导致整个系统发生故障, 则这种连接方式称之为串联方式。其计算公式如下:

如果是多个元器件结合起来, 只要有一个元器件能工作, 即使其他元器件失效, 系统也能正常工作, 则这种连接方式称之为并联方式。其计算公式如下:

在现实中, 系统都是复杂的, 不是那么单纯的, 一般会是串联和并联结合的混合系统, 其可靠度为:

其中, A为总可用性, n是设备数量。

一般对于网络可靠性的预测分析计算正是基于上述理论, 但操作起来会比较繁杂, 为便于实际工程使用计算, 根据式 (7) , 采用Excel宏命令编制的面向单机可靠度计算的SHARC工具 (System HW (and SW) Availability and Reliability Calculator) 和面向整体网络可靠度计算的NARC工具 (Network Availability&Reliability Calculator) 会有较强的实用性。这2个工具在使用时, 只需要输入关键参数, 如相应产品的MTBF值等, 就可以得到最终计算值。

由于MTBF取决于设备本身的质量, 这在出厂时就已经确定, 当系统本身的MTBF到达极限时, 就无法纯粹依靠通过提高MTBF数值来获得更高的可靠性, 那么通过减小MT-TR数值来实现高可靠性, 便成为可为人所控制调整的因素的方法。

1.3 马尔科夫链模型讨论

马尔科夫链模型研究了系统不同状态变化的过程, 这和可靠性研究的领域非常类似, 所以马尔科夫链模型被广泛应用于可靠性模型研究中[4]。常见的1:N备份 (1个设备做专用备份, 保护N个主用设备, 平时不使用) 采用马尔科夫链模型的表述, 如图2所示。

其中, N代表所有激活的设备, λ代表单体设备的失效率, μ代表失效设备维修率, β代表从失效设备切换到备份设备的成功率, C代表切换率。

该模型下的5个不同状态分别是, 状态1:正常工作;状态2:检测到1个设备发生故障;状态3:备份设备接替工作;状态4:在第1个设备被修好前第2个设备发生故障;状态5:激活设备失效, 无法切换到备份设备。

可以看出1:N备份可靠度不高。作为对上述的改进, N+1主备方式 (指N台主用, 1台作为备份, 并同时使用) 如图3所示。

在这改进模型中的5个不同状态分别是, 状态1:正常工作;状态2:检测到1个设备发生故障;状态3:N个备份设备接替工作;状态4:在第1个设备被修好前第2个设备发生故障;状态5:可以切换到备份设备。

假设F0是备份系统正常时的概率, F1是主系统故障, 备份系统正常时的概率, F2是主备系统都故障时的概率, 按照马尔科夫链原理, 其状态转移方程为:

对上述方程组求解:

故系统的正常概率是F0+F1, 即系统的可靠度为:

对于IP视频网, 通常要求可靠度是99.99%, 则λ是0.01%。所以从上述公式可以看出, 和纯粹的单机相比, 存在冗余的系统的可靠度会大大提高。从上述理论计算上看, 一般有冗余度的情况下, 可以提高约一个数量级, 也就是说如果单机的可靠度是90%, 那么冗余系统就可达到99%;如果单机达到99%, 那么冗余系统可以达到99.9%。因此为达到更高的可靠度, 多采用N+1冗余系统。这里的N+1包括单机内部的N+1冗余, 也就是多引擎, 多电源等;还包括系统整体的N+1, 也就是多机冗余等。同时也要采取其他各种措施降低MTRR才能达到理论上的10%的性能提高。

2 网络快速收敛技术应用

网络快速收敛技术包括单播和组播2种应用场景。其目的是从各个收敛的层面, 减少等待时间, 并加速收敛过程。但值得注意的是, 由于减少等待时间, 一般都会加快设备CPU检测的轮询时间, 所以要在轮询频度和CPU负荷之间找到平衡点, 避免由于过度频繁地检测网络状态而造成的设备负担, 但又能及时感应并响应状态的变化。

2.1 单播路由MTRR优化

从MTTR的角度看, 要想减小其数值主要有2种手段, 一是以最快的速度感知故障;二是以最快的速度从故障状态中恢复出来。因此构建高可靠性网络的基础就是要实现快速故障检测和快速故障恢复。

由于IP组播网在路由寻路的时候, 要进行反向路径检查RPF (Reverse Path Forwarding) , 而这又是建立在传统IP单播网络的基础上的, 所以IP组播网在网络路由表项恢复时, 也就是收敛时, 需要经历IP单播网络内部网关协议IGP (Interior Gateway Protocol) 的收敛, 然后再是IP组播网络的收敛, 故其复杂度和时间敏感度都较高。加快单播路由收敛的主要手段如下[5,6,7]:

加快线路检测:当物理端口发生状态改变后, 系统加速将此状态通知后续进程。

端口事件处理:当物理端口不稳定, 反复发生状态改变, 将该端口关闭不可用。

端口多种自适应功能:将端口的多种自适应功能处于强制设置状态。

端口汇聚:将端口汇聚时采用的负载均衡哈希算法设置为网络第4层。

快速生成树:设置快速生成树功能。

基于状态的引擎切换:在主备引擎切换过程中, 将主引擎的路由表项复制到备份引擎上。

开放式最短路径优先OSPF (Open Shortest Path First) 时间参数优化:降低OSPF标准的hello时间参数。

OSPF运算优化:降低OSPF标准的链路状态通告LSA (Link-state advertisement) 计算的延迟时间和采用增量的最短路径优先SPF (Shortest Path First) 计算方法。

路由协议被动端口:减少不必要的冗余的OSPF邻居关系。

NSF (Non Stop Forwarding) 不间断转发:在主备引擎切换过程中, 通过采用GR (graceful restart) 方式。

上述加速单播路由收敛的方法, 是从物理层, 链路层和网络层这3个层面进行的。物理层实现感知链路变化, 链路层对2层协议进行收敛, 网络层对3层协议进行收敛。3者关系是顺序执行的。只有前者加速完成了, 才能进入到后一个层面运行。所以他们之间的关系是相辅相成的。

2.2 组播路由MTRR优化

在完成了上述单播路由快速收敛, 组播协议进行了反向路径检查后, 组播协议开始其路由恢复收敛进程。

提高组播本身收敛速度, 可从以下组播环节入手:

组播邻居轮询速度:加快因特网组管理协议IGMP (Internet Group Management Protocol) 组播邻居轮询的时间, 及时触发更新组播表项。

组播路由表项缓存:清除组播路由表项缓存, 避免使组播数据流继续使用无效的缓存表项。

组播路由表项复制:在主备引擎倒备过程中, 将主引擎的组播表项同步到备份引擎, 从而减少备份引擎启动后需要对相关组播表项进行重新计算而消耗的时间。

3 组播高可靠网络的实现

运用上文所述的单播快速收敛原理和相关的组播快速收敛理论, 从组播性能、可达性和可靠性角度指导了一些现实且重大的IP视频网项目的整体设计;并在项目实施中, 取得了良好的效果。

3.1 IP视频网实例

在国内某亚太枢纽机场的IP视频网项目中, 笔者采用上述理论和方法, 对该网络进行了整体设计、建设和优化等工作。

该项目在单一园区中部署了2 100多个IP摄像头, 采用MPEG2编码, 码流6~8 M, 网络有十多台核心交换机和约上百台接入交换机。采用中央集中网络录像存储方式。全网采用组播。大屏总控室所连接的核心交换机组播表项约600多个。

在项目设计阶段, 搭建了测试实验环境, 使用和项目部署完全一致的设备, 全面仿真了该IP视频网的核心节点拓扑, 并采用专业测试仪取得量化测试数据。

为实现客户提出的高可靠度要求, 组合使用了上文提及的多种网络快速收敛手段, 反复测试验证, 最终大幅降低了MTRR值, 并为后续实际部署取得了最佳实践配置参数。由此客户在项目实施前, 就对最终结果值的数量级有了量化了解, 从而为科学设定系统可靠度值提供了真实而有效的依据。

在项目实施阶段, 采用上述验证测试得到的最佳实践参数值, 一次统调成功。在测试科目设置的多项故障切换预案演练中, 其在真实网络流量环境下的测试值和验证测试数值接近吻合。同时由于网络设备本身具有丰富且可靠的调试检测能力, 反而作为验证其他配套设备, 如IP视频编码器的组播功能指标的工具。

正是由于设备具有上述丰富的组播参数调整能力, 在实际调试运行阶段, 针对真实环境, 对其他配套产品本身, 如IP视频编码器的网络参数优化调整过程中, 进行了验证。

该项目自正式投产后, IP视频效果的用户体验非常良好, 而且可靠性非常高, 在历经了多个国内国际重大活动时高客流量期间, 均未发生意外, 达到了客户预期的可靠度目标, 得到好评。

整个项目拓扑如图4所示。

在后续的国内特大新型交通枢纽项目中, 其IP视频监控网, 以此项目为蓝本, 采用了类似的IP视频网高可靠设计, 并再次获得成功。

3.2 IP视频网设计

对于该IP视频网设计, 从多个角度着手。

首先是如何保证IP视频的性能, 也就是画面的流畅性。为得到网络设备能支持的组播流的理论数量值, 尤其是上下联端口可以支持的IP视频组播流的数量, 进行了以下量化计算:

假定码流6 M, 其吞吐量pps (packet per second) 为6 000000 (pps) /1 338 byte (视频流数据报文的字节长度) /8 (byte到bit转换) =560 pps。

已知该测试模块, 24GE线卡在1 510字节下组播的吞吐量为1.3 Mpps, 则其可以支持的码流数量, 近似为1 300 000 (pps) /560 (pps) =2 321个码流, 平均每个端口2 321/24=97个流。所以在设计时, 需要考虑到, 核心或者汇集层下联端口, 不应超过97个组播流, 或者说就是97个IP摄像头。也就是说该光纤端口下面无论是单台还是级联的交换机所连接的摄像头数量不宜超过97个。在具体实施时, 也的确是按照这个量化原则进行部署的, 得到了实际验证, 达到了最佳性能。

其次是如何保证IP视频的可达性, 也就是组播网的大小。组播和单播不同, 一般来说, 硬件产品支持的单播表项会很大, 往往可以达到几百K的规模, 而组播却很小, 从几K到十几K不等。而在网络监控中心, 由于采用对摄像头轮询显示的方式, 故监控中心所属的核心网络设备的组播表项会很大。由于组播表项建立过程中会生成 (*, G) 和 (A, G) 2个表项, 所以1个摄像头会占用2个组播表项。实际工程表明, 摄像头和组播组对应关系会有1∶4, 而且一般不会让设备的表项等超过最大值的50%, 所以经验法则是组播表大小至少是摄像头的8倍。

最后, 最重要的就是本文所讨论的组播高可靠性。

3.3 验证测试

在该IP视频监控网设计阶段, 为获得最佳可靠度, 在优化MTRR过程中, 事先搭建了全真模拟测试环境如下:

网络设备:Cisco6509系列交换机共4台, 成口字型通过千兆模块网状L3/L2连接, 2端L2连接2960交换机。2960连接到测试仪上。

连接方式:Cisco6509之间采用4组交叉连接, 每组4条GE组成的多端口绑定网状互相连接。

测试仪表:Sprient Test Center 2000带16个GE端口, 8发8收。

流量:测试仪模拟320台服务器和320个客户端, 均为不同IP地址, 加入到不同的组播组 (320组) , 速率为每个流6-8M带宽, 数据流字节数从256 Byte开始随机产生。

测试模块:Sup720-3BXL, 6748模块, Native IOS 12.2.18SXF4 (IP service) 。

每个测试科目至少运行10次, 记录10次。测试拓扑如图5所示。

本文进行了引擎切换, 链路切换和节点切换测试, 每个科目均有若干不同参数的配置测试[8,9]。由于单机的故障率最高, 代表性较强, 同时也为减少篇幅, 本文只提供了单机的引擎切换的测试结果, 但其优化方法在其他的测试中都得到验证, 这些结果均对降低MTRR有帮助。

4 组播网络的可靠性分析

根据上文的原理分析, 在搭建完全真实的网络环境中, 对快速收敛技术进行了比较验证测试, 取得了一手的最佳实践结果。同时关注了快速收敛和CPU负荷的平衡问题。最后对实验数据进行了高可靠度分析对比计算, 验证了上文的理论分析。

4.1 测试结果

4.1.1 未优化测试

测试仪8个发送端模拟产生311个不同的服务器加入到311个不同的组, 8个接收端模拟产生320个不同的客户端加入到各个不同的组, (其中一个组为组播复制10个客户端) 关闭6509#2和6509#4, 确定流量只在6509#1上。6509#1上有2个引擎, 配置SSO/NSF, 进行引擎切换。采用默认组播轮询时间30s。分数据源在6509#1端 (组播上游) , 或在6509#3端 (组播下游) , 共2种情况, 结果如图6所示。

图6显示了未经优化的组播收敛时间约在1.5至3 s (10次测试) 。这个时间对于连续视频效果体验来说, 由于中断时间较长是很不理想的。

4.1.2 优化测试1

降低组播轮询时间为10 ms, 重复上述测试, 结果如图7所示。

图7显示了经组播轮询时间优化的组播收敛时间约在0.4至1.4 s (10次测试) , 这个时间对于连续视频效果体验来说, 中断时间减少了, 相比前者有了一定进步。

4.1.3 优化测试2

在降低组播轮询时间为10 ms基础上, 同时关闭组播路由表的cache, 重复上述测试, 结果如图8所示。

图8显示了经二次优化的组播收敛时间约在0.22至0.65 s (10次测试) , 这个时间, 相比前二者, 有了很大的进步, 由于比较接近人眼视觉暂留时间 (0.2~0.4 s) , 所以较为理想。

4.1.4 轮询时间和CPU负荷平衡点

加快组播轮询频率, 会导致CPU的负荷增加, 经过实验研究, 选取了合适的组播轮询时间, 但也不会过高增加CPU负荷, 可以看到轮询时间小于10 ms时, 会造成CPU负荷极具上升, 而低于10 ms时, CPU的变化不明显。结果如图9所示。

图9显示了组播时间轮询和CPU的对应关系。反应出如果轮询频率过高的话, 设备的CPU就会忙于应付轮询工作, 导致CPU负荷过高。

测试小结:

由于采用了尽可能多的手段, 大幅降低了MTRR。

4.2 可靠性计算分析

4.2.1 未优化前结果

1) 单体的可用性

采用前文提及的SHARC工具 (根据公式7编写) 进行理论计算, 得出本项目所采用的Cisco6509单机的MTBF约为99.9%, 如表1所示。

表1是Cat6509交换机的各个部件在数据库中的MTBF值, 注意, 随着时间的推移, 产品使用时间的增加, 故障率会增加, 该数值会降低。

其中Part是指单机元器件, n是指元器件数量, HA是指冗余方式, N是指没有冗余, A是指主备热备份, L是指负载均衡, Part MTBF是指预测的元器件MTBF值, Part MTTR是指预测的元器件MTTR。SHARC只支持无备份方式。

根据式 (7) 可以计算出:

系统可靠性=99.98862415%

系统不可用性=0.01137585%

年均宕机时间 (min) =59.83

系统MTBF (hrs) =8 790

2) 系统的可用性

采用NARC工具 (根据式 (7) 编写) , 进行理论计算, 得出其所采用的整体网络环境的MTBF约为99.6%, 如表2所示。

表2是整个网络系统中各个设备的MTBF。其中System是指系统各单机, n是指单机数量, Redundancy是指冗余方式, N是指没有冗余, A是指主备热备份, L是指负载均衡, System MT-BF是指预测的系统MTBF值, System MTTR是指预测的系统MTTR。NARC只支持无备份方式。该表中各个单体设备的MTBF值由SHARC工具计算得出。根据式 (7) 可以计算出:

网络可靠性=99.65452372%

网络不可用性=0.34547628%

年均宕机时间 (min) =1 817

网络MTBF (hrs) =964

该整体网络预测值和客户的高可靠性要求是有一定差距的。

4.2.2 优化后结果

在采用带有元器件冗余方式和MTTR参数优化的改进的SHARC+工具 (根据式 (7) 编写) , 并结合上述MTRR值后, 理论计算出其所采用的Cisco6509单机的MTBF约为99.99%, 如表3所示:

系统可靠性=99.99191404%

系统不可用性=0.00808596%

年均宕机时间 (min) =42.53

系统MTBF (hrs) =10 277

该工具和SHARC相比, 冗余参数全部可用。

采用带有系统设备和MTRR参数优化的改进的NARC+工具 (根据式 (7) 编写) , 并结合上述MTTR值后, 理论计算出其所采用的整体网络环境的MTBF约为99.99%, 如表4所示。

网络可靠性=99.99603660%

网络不可用性=0.00396340%

年均宕机时间 (min) =20.85

网络MTBF (hrs) =1 275

该工具和NARC相比, 冗余参数全部可用。

从上述预测的计算值可以看到, 通过增加冗余度和多种手段降低MTRR, 无论是单体设备还是整个系统的可靠性都提高约10%, 和马尔科夫理论计算值较为吻合。经客户运行, 和实际情况也较为接近。

5 结语

高可靠性和MTBF与MTTR有直接关系。在系统已经开发完毕, 不能再改变系统本身的MTBF值的情况下, 要获得更好的可靠性, 只有通过降低MTRR来实现[10]。

本文以降低网络设备MTTR为提高网络MTBF的切入点, 系统地将和IP组播快速收敛各主要关键环节相关的配置参数进行调优, 并搭建了真实测试环境进行验证实验。此外, 该研究成果在多个重大IP视频网项目中得以采用, 取得了良好的效果。

参考文献

[1]Francois P, Filsfils C, Evans J, et al.Achieving sub-second IGP convergence in large IP Networks[J].ACM SIGCOMM Computer Communication Review 2005, 35 (3) :35-44.

[2]郭宋.毫秒级IGP网络路由快速收敛的研究[EB/OL].[2008-09-03].中国科技论文在线.www.paper.edu.cn/download/downPaper/200809=-66.

[3]Bellcore.Reliability Prediction Procedure for Electronic Equipment[R].Technical Reference TR-332, Issue 6, December 1997.Bellcore, 1997.

[4]Haihong Zhu.Reliability and availability analysis for large networking system:Reliability and Maintainability Symposium (RAMS) , 2012 Proceedings-Annual[C].IEEE.2012 (1) :23-26.

[5]张志华, 于群.IP承载网的高可靠性技术与实现[J].邮电设计技术, 2011 (8) :60-64.

[6]李园花, 李健, 赵凯.基于链路状态路由快速收敛技术的研究[J].网络安全技术与应用, 2009 (3) :9-11.

[7]姚林燕.IGP_OSPF路由协议网络优化技术[J].电脑与电信, 2012 (Z1) :39-41.

[8]陈晶.多业务网络可靠性关键技术探讨[J].中国新通信, 2007 (1) :83-85.

[9]李昕.IP网络生存性技术研究[J].电信科学, 2009 (10) :42-46.

可靠IP组播论文 第2篇

传统监控系统通过流媒体服务器进行视频的转发来解决多路查看, 但是每次视频流分发通过流媒体服务器之后, 都会增加几百毫秒的延时。大系统需要的流媒体服务器也就越大, 这就出现了设备管理、均衡负载等问题, 同时流媒体服务器巨大的视频分发压力使其性能大打折扣[2]。在存储方面, 传统监控系统采用DVR的PC级硬盘进行数据存储, 大码流的视频数据不间断读写会导致硬盘故障率变高, 可靠性差; 而且硬盘可扩展性能差不利于数据备份和数据量扩容[3]。数据管理方面, 传统监控方案在编解码、传输、存储、网络至少需要集成三到四个厂家的产品, 很难做到统一管理, 一旦丢失摄像头信号故障定位非常困难[3]。

当前, 城域范围内的监控规模不断扩大, 对视频监控系统的要求也在不断提高[4]。本文将IP网络、IP视频应用及IP SAN存储技术与视频监控系统进行了融合, 并提出了一种IP智能监控系统 ( IP Video Surveillance) , 依靠成熟的IP技术, 能弥补传统系统的上述不足, 更能迎合市场的性能需求, 特别是大范围的监控系统。

1 IP网络智能监控系统的构成

1. 1 系统组网

该系统主要由以下部分组成: 视频监控管理服务器VM Server、数据管理服务器DM Server、监控终端、客户端软件VC、IP-SAN网络存储设备和EPON无源光网络设备等[5]; 各个部分之间可以实现分散部署和统一管理, 系统组成如图1所示。

从图中可以看出系统组成在分布上和传统视频监控类似, 监控终端进行数据采集, 将数据通过IP网进行传输给控制管理服务器进行处理转换, 通过IP网的SAN进行储存, 在现实终端进行视频显示。

1. 2 工作原理

系统各个组成部分通过IP网络有机地融合为一体, 实现了更有效更快捷的视频监控效果。首先视频源完成视频和音频信号的采集工作, 视频源的类型很多, 有球形摄像机、枪型摄像机、高速智能球机等。视频信号被传输给监控终端进行数据信号的编码, 比传统系统优化的地方是在这里还可以进行i SCSI存储和网络接入[6]。信号被打包成IP数据包传送给IP网中, 在这里不仅能传输数据还能进行视频流的交换。本文对传输部分进行了组播支持优化和安全策略的设计, 使信号能够完整快速地传递给控制管理中心服务器, 实现了视频交换的流畅性和安全性。

数据流到达控制管理中心服务器后就相当于数据进入了大脑, 通过VM服务器可以实现对任何一个终端的管理、调度、控制及编码解码控制, 通过DM服务器可以实现对大量数据的存储管理、动态分配、查询资源、存储状态报警等功能。

本文设计的智能监控系统的数据存储是通过IP SAN存储, 可以实现视频数据的点播和下载, 所有功能都能通过DM服务器管理。系统最后的部分是显示, 不仅能像传统系统那样通过电视墙等媒体终端显示, 还能通过IP组播的形式进行数字化解码在调音台等设备上输出。图2 为该IP智能监控系统的组网拓扑结构图。

2 基于IP网络智能监控系统的实现

基于IP网络智能监控系统利用了NGN控制与交换互相分离的思想, 将IP网络、视频传输及SAN存储技术进行了有机的综合。系统不仅能完成传统系统的视频监控的功能, 还能实现视频回放、SAN存储等智能化功能, 使视频监控系统技术更能满足用户的需要。主要功能实现流图如图3所示。

系统实现视频监控实时监控, 要在VC终端上进行视频监控实时监控的命令下达, EC接收到经过VM服务器的控制指令后, 进行视频流的传输。本系统中视频流传输是以IP组播的形式进行的区别于传统系统。用户将输出终端加到想要监控的组中就可以实时地查看该组播的监控画面了。通过IP组播可以节省整个系统中的网络带宽。同时, 视频监控数据的存储可以在DM服务器中事先设定, 并将设定的计划发放给SAN存储器, 通过TCP/IP i SCSI就可以实现将需要存储的数据进行自动快速地存储。

3 IP智能监控系统的评价

IP智能监控系统将传统的视频切换矩阵变成了IP网络, 简化了系统构造, 将指令控制和视频流处理互相分离, 使视频服务器性能瓶颈得到了有效地回避, 使系统更稳当、更可靠; 融入了组播等优化设计, 系统进行编码的同时可以实现全网络终端数据的交换, 使视频监控画面质量更高、实时性更强、响应时间更短; SAN存储技术使视频监控数据的存储更快、管理更集中并且存储性能可扩展; 更能适应当前市场对视频监控系统的视频画面质量高、实时性好、查询历史视频速度快等性能的需求。

传统系统虽然也能完成实时监控画面的显示等功能, 但是每次查看用户的数量有限, 监控画面模糊、质量差, 没有起到视频监控拍摄有利信息的效果, 而且查询历史记录时间较长, 往往耽搁了最佳查询时间[7]。

本系统与传统视频监控系统功能和性能比较如表1所示。

4 结论

本文将视频设备、IP网络及监控视频软件有机地整合为一体, 设计了基于IP网络的组播智能监控系统, 引入了IP组播进行视频分发, 解决多路查看的问题, 提高了编码效率。该系统应用了最新的网络传输与存储技术, 采用IP网中的分布式概念和组播管理方式来实现IP监控的控制和管理, 优化了数据管理模式。系统试运行效果良好, 能够保证监控图像的跨域查看响应时间在300 ms以内, 并且存储速度快, 视频监控画面清晰质量高, 能够满足专业监控的需求。

摘要：将视频设备、IP网络及监控视频软件有机地整合为一体, 设计了基于IP网络的组播智能监控系统, 引入了IP组播方式进行视频分发, 解决多路查看的问题, 提高了编码效率。该系统应用了最新的网络传输与存储技术, 采用IP网中的分布式概念来实现IP监控的控制和管理, 优化了数据管理模式。

关键词：IP网络,视频监控,数据传输

参考文献

[1]李威, 田联房, 李向阳.嵌入式网络视频监控系统的硬件设计与实现[J].微计算机信息, 2012 (8) :69-70.

[2]蒋玉峰.安防企业进入IP视频监控时代[J].中国公共安全 (综合版) , 2014 (8) :70-72.

[3]余梦璐.安防视频监控系统概述[J].长江大学学报 (自然科学版) 理工卷, 2013 (2) :296-297.

[4]RAO Yuan, WANG Ruchuan.Qo S Routing Based on Mobile Agent for LEO Satellite IP Networks[J].The Journal of China Universities of Posts and Telecommunications, 2012 (6) :57-63.

[5]李刚健.基于IP网络远程监控系统的设计与实现[J].微计算机信息, 2014 (14) :57-59.

[6]吴静, 郭成城, 晏蒲柳.IP网络生存性研究综述[J].计算机科学, 2013 (5) :8-13.

可靠IP组播论文 第3篇

随着信息技术的不断发展,IP网络视频监控系统已经在智能化交通、交通监控等领域得到了充分的应用。IP网络视频监控系统是随着计算机技术、多媒体技术、监控技术有机结合起来的一种全新的监控系统。语音和视频数据在IP网络中传输如果都采用点对点的单播,由于单播技术自身的特点,将产生大量的冗余数据在网络中传输。而且服务器也将由于处理大量的用户访问信息,造成处理能力下降甚至宕机。IP组播技术的出现,解决了这些问题。

2 IP组播

2.1 IP组播技术的产生

传统的IP通信有两种方式:第一种是在一台源IP主机和一台目的IP主机之间进行,即单播(Unicast);第二种是在一台源IP主机和网络中所有其它的IP主机之间进行,即广播(Broadcast)。传统情况下,如果要将数据发送给网络中的多个主机而非所有主机,则要么采用广播方式,要么由源主机分别向网络中的多台目标主机以单播方式发送IP包。采用广播方式实现时,不仅会将数据发送给不需要的主机而浪费带宽,也可能由于路由回环引起严重的广播风暴;采用单播方式实现时,由于IP包的重复发送会白白浪费掉大量带宽,也增加了服务器的负载。所以,传统的单播和广播通信方式不能有效地解决单点发送多点接收的问题。IP组播技术能够很好的解决单点对多点传输数据的问题。

2.2 IP组播及其优缺点

IP组播是指在IP网络中将数据包以尽力传送(Best-Effort)的形式发送到一个构成组播群组的主机集合,这个主机集合是网络中的某个确定节点子集,这个子集称为组播组(MulticastGroup)。组播组的各个成员可以分布于各个独立的物理网络上。IP组播的基本思想是源主机只发送一份数据,这份数据中的目的地址为组播组地址;组播组中的所有接收者都可接收到同样的数据拷贝,并且只有组播组内的主机(目标主机)可以接收该数据,网络中其它主机不能收到。IP组播群组中成员的关系是动态的,主机可以随时加入和退出群组,群组的成员关系决定了主机是否接收送给该群组的组播数据包,不是某群组的成员主机也能向该群组发送组播数据包。

由于网络用户的增多、涉及面扩大,大量的用户经常要在大致相同的时间里访问相同的信息。这种情况下,组播的优势就显现出来了。构建一种具有组播能力的IP网络,允许中间路由器将数据包复制到几个输出接口上,这样一个服务器只需向一组终端用户发送单一流,并利用网络层提供的组播路由功能将数据包传递到每一个加入该组播组的接收者,从本质上减少整个网络带宽的需求,减轻服务器的负担。另外,组播传送的数据能同时到达用户端,延时小,而且网络中的服务器不需要知道每个客户机的地址。所有的接收者使用一个网络组播地址,可实现匿名服务。

与IP组播系统执行程序相关联的主要缺点包括不可靠的数据包交付、数据包复制以及网络阻塞。由于IP组播假定一对多的通信方式,它不使用TCP的端到端的机制。IP组播数据包使用用户数据报协议(UDP)作为传输层协议,不同于TCP,UDP不提供可靠性、流控和错误恢复功能。因此,一个使用IP组播的应用一定会遇到偶然的数据包丢失。组播的可靠性由接收方和网络中的Qos负责管理。

单播和组播之间的关键差别是路由器主动地发送组播数据包的拷贝到多个接口。这增加了多个拷贝的组播数据包到达某一接收点的可能性。如果设计不当,可能会导致关键的控制命令在IP组播数据包被执行多次。就TCP单播来说,标准TCP补偿和慢开启窗口机制自动地调整数据传送的速度,因此在一定程度上避免了网络阻塞。因为IP组播不使用TCP,所以没有内建的阻塞避免机制防止组播流耗尽链路带宽或者其他关键的路由器资源。

2.3 IP组播通信

在组播中,用户按不同的应用分为不同的用户组,组成员要向组播服务器(一般为路由器)注册,用户主机发出请求报文,表明所要加入的组。每个组播群组有惟一的D类地址。其地址范围从224.0.0.0到239.255.255.255。IP最多可提供多达228个同步组播群组的地址,因此,实际群组数受路由表的大小而不是编址的约束。

转发IP组播需要特殊的组播路由器(Multicast Router)。通常是给常规路由器添加这种能力。组播路由器会周期性地对该组进行查询,检查组内的成员是否还参与其中,只要还有一个主机仍在参与,组播路由器就继续接收数据。当所有的主机都离开了组后,组播路由器会收到一个Internet组管理协议(InternetGroupManageProtocol,IGMP)的“离开”消息报文,组播路由器就会马上查询组中是否还有活动的组成员。如果有活动的组成员,组播路由器就继续转发数据;如果没有,就不再转发数据。

2.4 IP组播路由协议

在路由式网络中,对于传递组播信息流,一个至关重要的问题是IP组播路由协议,它克服了利用单播通信模型传递组播信息带来的带宽瓶颈,减少了发送相同数据信息到多个接收者的通信费用,这也是IP组播应用得到发展的主要原因。组播网内数据的流动必须根据组播路由协议建立生成树,使发送源和组播组成员之间形成一条单独的转发路径,确保每个数据包都能转发到目的地。

IP组播路由协议分为域内协议和域间协议。域内协议包括PIM-SM、PIM-DM、DVMRP、CBT等。域间协议包括MBGP、MSDP、BGMP等。

根据网络中主机的分布,IP组播域内路由协议一般可以分为三类。第一类称为密集型模式,这种模式指组播成员在网络中密集分布,有足够的带宽,所以密集协议通过扩散技术传播信息至整个网络,它包括DVMRP、MOSPF和PIM-DM,属于数据驱动型。第二类称为松散型模式,这种模式指组播成员在网络中分散分布,没有足够的带宽,例如广域网或用户使用ISDN线上网,但松散型模式并不意味群组有很少的成员,只不过它们是分散分布的,它包括CBT和PIM-SM。此时,使用扩散技术将浪费带宽,通过发出加入请求申请,在含有集中点或核心点的空生成树上添加树枝形成组播生成树,属于接收者驱动型。第三类成为稀疏-密集型模式,这种模式可以同时对某些多播组采用密集运行模式,而对其他多播组采用稀疏运行模式。稀疏-密集型模式允许根据是否有RP信息来选择对多播组使用稀疏模式还是密集模式。如果路由器获悉了多播的RP信息,则对其使用稀疏模式,否则对其使用密集模式。

使用DVMRP、MOSPF组播路由协议时,单播路由协议相应必须使用RIP、OSPF,这就造成了一定的局限性,DVMRP使用距离向量路由协议建立生成树,MOSPF使用链路状态数据库建立生成树;PIM和CBT独立于单播路由协议,但依赖于单播路由表,其中PIM-SM和CBT有一个集中点或核心,连接源和接收者之间的各个路由器而形成路由。

3 IP组播在视频监控系统中的应用

如果要将组播通信应用在视频网络中,网络里的发送和接收主机、网络路由器以及它们之间的网络结构必须支持组播,防火墙设置成允许组播通过。

每个节点主机需有一个网络接口卡(NIC)要能支持组播,能有效滤出由网络层IP组播地址被映射成的数据链路层地址;需装有加入组播组请求的IGMP的软件和路由器通信,加入组播群;需有支持IP组播传送和接收的TCP/IP协议栈;再装上如视频会议这样的组播应用软件,主机就可以进入组播组进行组播通信。若发送音频,主机需要一个麦克风和相应的音频软件;若发送视频,主机需要帧控制卡和摄相机。

在视频网络中IP组播通信的过程如图1所示。

(1)主机发出一条IGMP加入消息到相邻路由器,主机的MAC地址映射为将要加入的D类组地址,并包含在IGMP数据报中,路由器知道主机想加入组播组。

(2)相邻路由器接收加入消息后,动态跟踪这些组播组,使用组播路由协议,在源端和接收端各个路由器之间建立组播生成树,从每个发送者伸展到所有接收者。

(3)在源端和接收端建立组播路由后,源就开始沿着组播路由发送数据给各个接收者。

主机接收到了源发送来的数据,网络接口卡滤出组播群组的MAC地址,网络驱动器对此地址做出反应后,把数据传递到TCP/IP协议栈,进入用户的应用层,就可以进行视频通信了。

4 结束语

IP组播技术有效地解决了单点发送到多点、多点发送到多点的问题,实现了IP网络中点到多点的高效数据传送,能够有效地节约网络带宽、降低网络负载,基于IP组播技术可以很好地开展流媒体、视频等各种宽带增值业务。随着下一代互联网技术的广泛应用,IP组播技术会拥有更广大的应用空间。

摘要：对IP组播技术和其在视频监控系统中的应用作了介绍,采用IP组播技术实现监控视频的多点传输,可以大大节省网络带宽资源,提高数据传送的效率。

IP组播技术在流媒体传输中的应用 第4篇

以前人们在网络上观看电影或收听音乐时，必须先将整个影音文件下载并存储在本地计算机上，然后才能收看。与传统的播放方式不同，流媒体在播放前并不下载整个文件，只将部分内容缓存，使流媒体数据边传送边播放，这样就节省了下载等待时间和存储空间。常见的流媒体的应用主要有：视频点播（VOD）、视频广播、视频监控、视频会议、远程教学、交互游戏等。丰富的流媒体应用对用户有很强的吸引力。

语音和视频数据在网络中如果都采用点对点的单播，将产生大量的冗余数据，而且路由器、服务器也由于要处理大量的信息，造成处理能力下降甚至无法处理。IP组播技术的出现，很好地克服了这些问题。

1、IP组播技术介绍

1.1 IP数据包传输类型

IPv4定义了3种IP数据包的传输：单播（unicast）、广播（broadcast）和组播（multicast）ㄢ

单播传输：在发送者和每一接收者之间实现点对点的网络连接。如果一个发送者同时给多个接收者传输相同的数据，则必须相应地将数据包复制成多份后再分别投递。如果有大量主机希望获得数据包的同一份拷贝，将导致发送者负担沉重、延时长、网络拥塞，为保证一定的服务质量需要增加硬件和带宽。这种传输是最常见的IP传输，使用的非常广泛。

广播传输：是指在IP子网内广播数据包，所有在子网内部的主机都将收到这些数据包，不管它们是否乐于接收。广播的使用范围非常小，只在本地子网内有效，因为路由器通常会封锁广播通信。广播传输会增加非接收者的开销。由于使用的场合受到了限制，较少使用。

组播传输：在发送者和每一接收者之间实现一点对多点的网络连接。如果一个发送者同时给多个接收者传输相同的数据，只需投递一份数据包就可以了。组播提高了数据的传输效率，减少了骨干网络出现的拥塞的可能性。组播可以大大节省网络带宽，因为无论有多少个目标地址，在整个网络的任何一条链路上只传送单一的数据包。

同单播或广播相比，组播效率非常高，因为任何给定的链路至多用一次，可以节省网络带宽和资源。单播和组播数据传送过程的区别如图：

如图1所示，建立一个视频服务器和远程客户端的通信。假设网络中有N个用户，一个视频信息流需要占用1.5Mbps的带宽。

一个单播环境里，服务器依次送出N个信息流，由网络中的用户接收，共需要1.5M*Nbps的带宽；如果服务器处于10M的以太网内，6-7个信息流就占满了带宽；若在一个高速的以太网里，最多只能容纳250-300个1.5Mbps的视频流，所以服务器与主机接口间的容量是一个巨大的瓶颈。

在一个组播环境里，不论网络中的用户数目有多少，服务器只发出一个视频流，由网络中的路由器或交换器同时复制出N个视频流，广播到每个用户，仅需1.5Mbps的带宽。

1.2 IP组播原理

IP组播是对硬件组播的抽象，是对标准IP网络层协议的扩展。它通过使用特定的IP组播地址，按照最大投递的原则，将IP数据报传输到一个组播群组的主机集合。它的基本方法是：当某一个人向一组人发送数据时，它不必将数据向每一个人都发送数据，只需将数据发送到一个特定的预约的组地址，所有加入该组的人均可以收到这份数据。这样对发送者而言，数据只需发送一次就可以发送到所有接收者，大大减轻了网络的负载和发送者的负担。

组播报文的目的地址使用D类IP地址，范围是从224.0.00到239.255.255.255。D类地址不能出现在IP报文的源IP地址字段。单播数据传输过程中，一个数据包传输的路径是从源地址路由到目的地址，利用"逐跳"（hop-by-hop）的原理在IP网络中传输。然而在IP组播环中，数据包的目的地址不是一个，而是一组，形成组地址。所有的信息接收者都加入到一个组内，并且一旦加入之后，流向组地址的数据立即开始向接收者传输，组中的所有成员都能接收到数据包。组播组中的成员是动态的，主机可以在任何时刻加入和离开组播组；每一台主机都可以同时加入到多个组中，每一个组播地址可以在不同的端口或者不同的Socket上有多个数据流，同时许多实际应用可以共享一个组地址。

D类地址划分为局部链接组播地址、预留组播地址、管理权限组播地址等，分配如下：

·局部链接组播地址：224.0.0.0～224.0.0.255，用于局域网，路由器不转发此范围内的IP包。

·预留组播地址：224.0.1.0～238.0.0.255，用于全球范围或网络协议。

·管理权限地址：239.0.0.0～239.255.255.255，组织内部使用，用于限制组播范围。

2、IP组播技术在流媒体传输中的应用

如果要使组播通信流媒体传输中得以应用，网络里的发送和接收主机、网络路由器以及它们之间的网络结构必须支持组播，放火墙设置成允许组播通过。这是IP组播技术在流媒体传输中的应用的前提条件。

流媒体传输实际上牵涉到两方面的技术。其一就是服务器与客户端的通信技术，包括多媒体数据的传输、命令控制等；其二就是客户端对接收到的多媒体流实时解码后播放的技术。显然，网络通信可以使用Windows Socket技术，多媒体流的解码播放可以使用Directshow技术。本文重点讨论Windows Socket网络传输技术。

2.1 系统架构

流媒体在网络中的应用一般采用服务器/客户端的架构。这样只需要对有限的服务器进行更改、设置，即可满足所有客户端的要求。

一个IP组播的源主机一般都是音频、视频、金融等各种各样类型的流数据进入网络的多媒体服务器。应用程序会根据事先的设置自动分配一个D类多路广播地址给服务器以及它的所有成员。当一个客户端想要加入组播时，可以通过发送一条IGMP报文给它的本地子网开始，这条报文包含它想加入的组的D类地址。在与源主机建立连接后，本地有组播能力的路由器，就把所有的给目标主机组的组播数据传送到本客户端的子网。

2.2 IP组播技术的实现

服务器和客户端之间有一个Socket通信协议的问题。由于流媒体传输需要注意实时性，媒体数据的实时性比正确性更重要。因此服务程序使用套接字编程和多线程完成。它利用TCP套接字作为控制通道实现控制信息的传递及其客户端的交互。利用UDP实现流媒体数据的传输通道。

在具体实现时，采用多线程技术。首先服务器在指定的端口上进行监听。当发现有客户端请求时，建立一个线程使用UDP协议专门负责组播数据的发送。本线程只需要建立一次，在第一个客户请求时建立，后续客户请求则不用新建。同时，服务器也需要和每个客户端建立一个TCP连接，这样能够随时接受客户端的控制信息。此操作需要在每个客户请求时，建立一个线程来完成TCP的连接。这样，在服务器正常工作时，大部分时间运行的是一个监听线程，来响应新的客户的请求；一个UDP传输的线程，实现组播数据的发送；多个TCP连接的线程，完成服务器和客户端控制信息的交互。

与单播协议相比，组播没有补包机制，因为流媒体数据采用的是UDP的传输方式，并且不是针对一个接受者，所以无法有针对的进行补包。所以直接用组播协议传输的数据是不可靠的。在需要时，我们可以在应用层上适当增加质量控制。

3、结语

我们可以看出，IP组播技术有效地解决了单点发送到多点、多点发送到多点的问题，实现了IP网络中点到多点的高效数据传送，它能够有效地节约网络带宽、降低网络负载。基于IP组播技术我们可以更好地开展流媒体、视频等各种宽带增值业务。

参考文献

[1]陆其明.DirectShow实务精选[M].科学出版社北京科海电子出版社, 2004.

[2]于海生.组播在视频监控系统中的应用[J].吉林交通科技, 2008年第2期.

可靠IP组播论文 第5篇

关键词：IP组播,XML技术,分布式监测诊断系统

0 引 言

随着科学技术的进步和工业生产水平的提高, 汽轮机不断向大容量、多机互联方向发展。为了保证汽轮机组的安全、可靠和经济运行, 设计并实现了汽轮机组分布式监测与故障诊断系统。然而分布式系统各应用终端之间数据的大量交互及高实时性的要求, 使得对分布式监测和故障诊断系统的数据通讯性能的要求也越来越高[1]。目前广泛应用的分布式监测系统数据流方式为:先将从传感器采集到的数据发送到现场计算机, 再由该计算机把数据存到数据库, 而需要处理数据的计算机则通过计算机网络连接到数据库。在数据量大、实时性要求高的情况下, 普通企业网络由于受到通讯速率的限制, 很难实现高效数据传输。在TCP和UDP协议中, 网络层提供了3种IP数据包传送方式:单播方式、广播方式和组播方式。如果用单播传输技术来实现机组数据的多点传输, 则需要通过在发送者和每个接收者之间占用单独的数据信道来传输数据量巨大的机组实时数据, 这将导致发送者负担沉重、延时长、网络拥塞。而采用广播又极易造成网络带宽的大幅占用, 影响整个网络的通信效率[2]。正因为单播和广播方式存在的问题, 而且由于XML的重要特征为被标记的各个数据保持其含义, 系统间交换数据能力极大提高。这个重要特征可以提高各个分布式应用平台之间的交互性。

因此本研究尝试结合XML技术和IP组播技术, 设计和实现分布式监测和故障诊断系统的通讯机制。

1 系统总体设计

1.1 系统构架设计

分布式监测和故障诊断系统包括数据采集、状态监测、故障诊断以及通过Internet进行远程故障诊断等几个主要技术。系统采用模块化分布式构架, 主要包括分布式机组群信号监测系统 (快变信号、慢变信号、开关信号监测系统) 、本地故障诊断系统 (多级流诊断和数据分析) 、数据服务器系统和远程故障诊断系统。通过先进的模块化可组网络技术可以方便地实现各系统的组合拼接以适应测量对象和测量用户对产品丰富度和灵活性的要求, 同时可以借助各地专家为用户提供远程技术支持。

系统的构架如图1所示, 数据服务器通过IP组播技术将数据包发送到多级流诊断、远程诊断中心、数据分析等系统, 实现本地故障诊断, 并且在出现故障而本地无法诊断时, 异地相关技术人员及专家可以通过Internet与远程诊断中心连接进行故障诊断并反馈, 有利于故障的及时排除。

1.2 系统数据流设计

分布式监测和故障诊断软件系统数据流程如图2所示, 分布式系统工作时, 将通过不同传感器采集上来的数据保存到数据服务器之后, 在数据服务器中将现场数据转换成XML报文, 然后通过IP组播技术将报文发送到各个工作计算机中, 在各个计算机中进行XML解析, 可以实现现场故障诊断。异地相关技术人员及专家可以通过Internet进入远程诊断中心进行远程诊断。

2 系统传输层和表示层设计

2.1 系统传输层的设计

系统在Windows2000系统下开发, 采用的是C++语言。C++语言拥有高效性、灵活性、便于移植、易于扩充等特点, 又支持面向对象编程, 具有强大的编程功能。在系统数据传输中, 使用了WinSock规范, 它提供了与WinSock相关的API, 使系统可以很方便地编写出自己的网络通信和资源共享程序。本研究尝试使用IP组播技术。IP组播技术与单播 (Unicast) 和广播 (Broadcast) 相比, 有以下3个优点:

(1) 相同数据流的客户加入相同的组且共享一条数据流, 节省了服务器的负载。具备广播 (Broadcast) 所具备的优点。

(2) 由于组播协议是根据接收者的需要对数据流进行复制转发, 服务器的服务总带宽不受客户接入端带宽的限制。IP协议允许有2.6108个以上 (268 435 456) 组播, 所以其提供的服务非常丰富。

(3) 此协议和单播协议一样允许在Internet宽带网上传输。

如上所述, 因为IP组播具有带宽利用率高、服务器负载低等应用优势, 本系统采用IP组播技术进行通讯。下面介绍组播通讯在系统中的具体应用, 以创建Client socket为例, 详细介绍IP组播技术:

(1) 调用win32的socket连接库。

(2) 创建UDP协议的Client socket套接口。

(3) 设置Socket属性。

设置允许程序的多个实例运行在同一台机器上:

ret=setsockopt (client, SOL_SOCKET, SO_REUSEADDR, (char*) &client_on, sizeof (client_on) ) ;

设置数据报生存时间, 选项类名用IP_MULTICAST_TTL:

int client_routenum=10;//可以通过10路通道发送数据报

ret=setsockopt (client, IPPROTO_IP, IP_MULTICAST_TTL, (char*) &client_routenum, sizeof (client_routenum) ) ;

设置数据回馈, 1表示可回馈到本机:

int server_loopback=0;

ret=setsockopt (client, IPPROTO_IP, IP_MULTICAST_LOOP, (char*) &server_loopback, sizeof (server_loopback) ) ;

设置本地地址, 端口与多播端口一致, 绑定到本地端口:

设置多播组结构:

多播地址client_mreq.imr_multiaddr.S_un.S_addr=inet_addr (239.255.255.200) ;

本地地址client_mreq.imr_interface.S_un.S_addr=htonl (INADDR_ANY) ;

加入一个多播组:

ret=setsockopt (client, IPPROTO_IP, IP_ADD_MEMBERSHIP, (char*) &client_mreq, sizeof (client_mreq) ) ;

2.2 系统表示层的设计

如引言所述, 系统采用IP组播机制来传输XML报文。XML (eXtensible Markup Language) 是由W3C制定的新标准标记语言, 由SGML (Standard Generalized Markup Language) 和HTML (Hypertext Markup Language) 二者派生而成。其最大的特点是将信息的描述和信息的处理分开, 使得数据具有自我描述能力。XML具有很好的扩展性、开放性, 而且具有可验证的特性等。目前有十几种XML模式描述语言, 包括DTD, XDR, SOX, XML-Schematic, Schematron, DSD等等。其中DTD, XML-Schema, XDR和SOX属于语法模式, Schematron属于类型模式, DSD则介于二者之间。这些模式中, 对DTD和XML-Schema的语义研究较多。DTD作为XML标准的一部分, 是目前使用最广泛的一种XML模式。但是DTD不能很好地实现应用程序不同模块的相互协调, 缺乏对文档结构、属性、数据类型约束的足够描述等缺陷。W3C于2001年5月正式推荐XML-Schema作为XML标准模式。本系统采用XML-Schema作为系统的标记语言。与DTD相比, XML-Schema具有以下优点:

(1) XML-Schema提供更多的数据类型:它内置40多种数据类型, 如long, int, short, double等常用数据类型, 并通过将数据类型表示为由value space、lexical space和facet 3部分组成的三元组而获得更大的灵活性。

(2) 元素顺序的支持:XML-Schema提供了<all>标记来描述无顺序出现情况, 而DTD必须采用穷举元素各种可能出现的排列顺序的方法来实现。

(3) 命名空间:与DTD相比, XML-Schema能很好地满足“不产生语义上的冲突”要求, 并且XML-Schema还提供了include和import两种引用命名空间的方法。

(4) 对于API的支持:XML-Schema本身就是一个XML文档, 可以通过使用DOM、SAX等XML API简易地解析XML-Schema, 实现XML文档与其描述模式处理方式的一致性, 利于传输和交换。

因此, 系统采用XML Schema来构建系统的数据模型, 如图3所示。其中结点表示图中的元素、类型或者元素属性, 边表示图中结点之间的关系。图中的每个结点包含结点的名字、结点的类型等信息。

对图3作如下说明:在出现工作采集卡故障时, 备用采集卡就接替工作采集卡工作;本系统采用的快变采集卡拥有4路通道;FrameID和Time结点相结合表示着在Time时间下采集的第FrameID个数据包SPEED通过转换键相信号得到。shuju是一个644的二维数组, 因此它包含着64个Array节点, 每个Array节点又包含着4个data节点。在快变数据包中, 每个节点都只有惟一的值。

QuickPacket是从底层快变信号采集卡发送上来的快变数据包;Pflag结点表示采集卡卡号;Pflag1结点表示备用采集卡卡号;SubNo结点表示采集卡通道的通道号;Time结点表示采集数据包的时间;FrameID结点表示帧号;SPEED结点表示转子的转动速度;shuju结点表示采集上来的数据

3 实验分析

现有系统的通讯机制一般都采用单播, 因此笔者将结合XML技术的IP组播与单播进行对比, 在实验室中做了如下实验。

实验环境如下:3台计算机, 其配置为AMD4400+CPU、1 G金士顿内存、Windows 2000操作系统。实验网络构架如图4所示, 3台计算机中1台为数据库服务器, 另外2台为应用终端。它们通过华盖SR-550路由器连接, 连接它们的网线长度都为3 m。与此同时路由器与外网断开, 其IP地址分配如下:服务器为10.11.112.250, 终端分别为:10.11.112.69和10.11.112.70。

在上述实验环境下, 实验过程如下:数据库服务器分别采用单播和IP组播机制向两个应用终端各发送0.5 K大小的XML数据包。上述实验过程, 重复做了10组, 每组1 000次。实验结果如表1所示, 表中数据为数据库服务器分别通过单播和IP组播技术向两个应用终端各发送0.5 K XML数据包的平均时间。

对表1中的数据进行整体分析后显示, 在相同环境下, 传输等量数据, IP组播方式所花费的时间仅为单播的34%。实验结果表明, 采用IP组播技术能大大提高分布式监测和故障诊断系统的数据通讯效率, 保证系统实现及时、高效的诊断。

4 结束语

分布式监测和故障诊断系统是集数据采集、状态监测、故障诊断等技术于一体的综合信息处理系统。系统通过实验环境下的实验表明, 采用结合XML技术和IP组播技术能大大提高系统的效率。本系统的研究成果, 对于建立和应用分布式监测和故障诊断系统, 解决复杂分布式设备的故障诊断问题, 保证这些机组安全、高效、可靠、连续地运行具有重要的科技意义和应用前景。

参考文献

[1]田质广, 孟宪尧, 张慧芬.分布式汽轮发电机在线监测与故障诊断系统设计与实现[J].汽轮机技术, 2005, 47 (6) :401-403.

[2]徐进.基于IP组播的分布式数字视频监控系统[J].计算机工程, 2003, 29 (11) :134-136.

[3]李幼仪, 甘志.C++Builder高级应用开发指南[M].北京:清华大学出版社, 2002.

[4]郑力明, 张会汀, 刘伟平, 等.基于IP组播技术的分布式视频会议系统的设计与实现[J].计算机工程与应用, 2003, 39 (2) :153-155.

[5]李亚楠, 刘连忠, 贾焱星.数据交换研究[J].计算机技术与发展, 2008, 18 (2) :5-8.

[6]MANI M, LEE D, MUNTZ R R.Semantic Data Modelingusing XML Schemas[M].Springer-Verlag Berlin Heidel-berg, 2001:149-163.

[7]STURM J.微软XML解决方案[M].北京:机械工业出版社, 2001.

一种高可靠性的组播树恢复方法 第6篇

应用层组播ALM(Application Layer Multicast)将组成员组织成覆盖网络为数据传输提供服务,复杂的组播功能完全由终端系统在应用层实现,摆脱了IP组播对网络中间设备的依赖,从而具有良好的伸缩性和高效的数据传输效率,并且易于大规模部署和实现,便于针对特定应用优化,因此作为分布式仿真应用开发的一种新途径被广泛应用。

ALM服务主要分成两大类:高可靠性的服务和可容忍部分丢失的服务[1]。在高可靠性服务中,数据从源到客户端的所有丢失都需要被恢复,数据的丢失率必须在指定的阈值范围之内,如分布式仿真服务、分布式文件系统和在线游戏等。对于可容忍部分丢失的服务,少量的数据丢失是可以接受的,类似的服务有流媒体服务等。

随着组播规模的扩大,组播成员本身或者所在的计算机出现异常的概率也随之增加,每个成员节点都是可以离开或可能失效的终端主机,如果节点离开组播树,它的下游节点都将受到影响。因此在节点离开或者失效后如何快速完成组播树的重构以保证数据的传输是节点失效后组播树恢复的主要问题。如何处理应用层组播失效节点的问题已经成为一个新的关注点[2,3,4,5,6]。

1 现行组播树恢复方法分析

ALM恢复机制分成两种:预先式恢复和响应式恢复[1]。在预先式方法中,通过在主机发送端发送冗余的恢复数据报来保证如果有数据报在网络传输中丢失,接收端依然可以通过冗余的恢复数据报来重构原数据。在响应式方法中,丢失包的重传发生在节点失效或者接收端确认丢失发生以后,它依赖于接收端向发送端主机发送的重新获得丢失数据报的请求。

1.1 预先式恢复方法

预先式恢复方法[2,3,4,6,7]采用同步地发送冗余的恢复数据报,因此它的恢复延迟比较低。文献[2]采用基于弹性恢复编码ERC(Erasure-resilient coding)的方法生成冗余数据并将其与源数据共同发送,这种方法在处理部分数据报丢失时有效,但无法应对节点失效的情况。文献[3]采用概率恢复组播PRM(Probabilistic resilient multicast)方法,即在现有的组播树生成算法的基础上,利用某种计算方法在某些节点之间额外地连接一些边,这样虽然传输的数据会有冗余,但健壮性较单源组播树有明显增强,PRM虽然可以通过其中的计算方法(Randomized Forwarding)保证节点失效后组播树中数据传输的正确性,但对于需要满足高可靠性的ALM服务来说,其对数据传输完整性的保证还是不够。文献[4]利用多路传输MPT(Multiple-path transmission)来放置数据丢失,建立两颗不同的组播树同时发送数据的方法,虽然可以保证数据传输的完整性,但随之带来的管理代价和传输的冗余数据太大,因此不适合大规模的网络情况复杂的组播通信。文献[6,7]提出基于度受限的预构备用父节点组播树重构方法,预先给每个节点计算一个备用父节点,以此达到高可靠、低延迟、易恢复的目的,但是现有的基于预构备用父节点的方法(如Proactive Tree Recovery, PTR方法[6])都无法满足重构的完整性,即当无法找出合适的备用父节点时只能依赖别的恢复方法,否则无法完成组播树的重构。

1.2 响应式恢复方法

响应式恢复方法[5]是一种在接收端探测到已有节点失效或者数据丢失之后,通过发送重新获得数据的请求来保持数据完整性的一种方法。在节点失效后,响应式恢复方法可以通过源节点或祖先节点进行恢复。然而在度受限的组播树中,该方法必然会导致源节点和祖先节点成为传输过程中的瓶颈,此外这种方法的恢复时间也相对较长[5]。

1.3 恢复方法总结

一个有效的组播失效恢复方法应该从以下四个方面评价[1]:

(1) 恢复损失率,这是对恢复完整性的评价;

(2) 恢复延迟;

(3) 恢复管理代价;

(4) 部署代价。

由表1可以看出,ERC和PRM方法因为不能提供对所有数据传输完整性的保证,因此不适应于要求高可靠性的组播应用,其中MPT方法对带宽要求太高,不适应于网络环境比较复杂的情况;预构备用父节点方法能将寻找备用父节点的代价放到构建组播树的同时,因此在恢复延迟方面会有很大改善,恢复完整性也比较高,但在特殊的度约束环境下还是不能满足高可靠性的要求。响应式算法中源/祖先恢复方法会大大增加源节点或者祖先节点的带宽和管理负担,且不满足度约束环境。因此,本文提出了一种能够满足高可靠性组播应用的组播树混合恢复方法。

2 组播树混合恢复

在借鉴了上面所列的一系列方法的基础上,为了达到组播树应用高可靠性、低延迟的目标,本文提出了一种基于度约束的组播树的混合恢复方法,根据对节点剩余度的计算在RTR方法合适的地方采用经过分析改进的PTR方法,并在PTR方法不适合的地方加以完整性保证形成一种新的恢复方法。通过这个方法,可以在推论1的验证下保证组播树重构的完整性。

2.1 基于度约束的组播树问题

在应用层组播中,所有的主机节点是全连通的。可以通过下列建模来描述基于度约束的最小生成树问题。

建立模型1:

GIVEN:

(1) 所有节点构成一个无向完全图G=(V,E),同时每条边都有一定的权值,定义权值函数ω:ER+,这里R+是一个正实数集合,这样,对任意一条边e∈E,ω(e)表示任何边的权值(即ALM中的节点之间延迟)。

(2) 对于每个节点cj,它的总度、已用度和剩余度分别用Dt(cj)、Du(cj)和Dr(cj)表示,根据定义有Dt(cj)=Du(cj)+Dr(cj),这里的度包括节点的入度和出度。

FIND: 最小生成树T=(V,E′),使得:

(1) E′⊆E。

(2) T满足度约束条件,即对任何节点cj,它在T中的度小于或等于Dt(cj)。

(3) 总的权值∑e∈Eω(e)最小。

定理1 以上问题的有解的充要条件是∀ki∈V,有Dt(ki)≥1且∑ki∈VDt(ki)≥2m-2,其中m=|V|[6]。

推论1 若 ∀ki∈V,有Dt(ki)≥2,则除根节点外的其余任意节点失效后组播树都能重构。

证明:由∀ki∈V,有Dt(ki)≥2可知∑ki∈VDt(ki)≥2m-2,因此节点在这种状态下能组建成一棵组播树,又假设ks失效,则剩余的节点k都满足Dt(k)≥2,则有∑ki∈V/ksDt(ki)≥2(m-1)-2,即可知此时可以重构成另外一棵组播树,证毕。

因为基于度约束的最小生成树问题是一个NP完全问题,可以采用启发式的Prim算法来解决[8]。

2.2 传输故障检测

传输故障主要从以下两个方面来检测:

(1) 对于传输数据完整性的检测: 通过对每个数据包加上对源文件的分割成的顺序序列值来保证,任何接受方接到间断的序列号的数据包,都被认为数据接收故障;

(2) 对于节点失效的检测: 通过定期监听每个节点与相邻节点直接传输的Heartbeat消息来判断节点是否失效。节点的主动退出也需要进行对组播树的恢复。

2.3 组播树混合恢复方法

2.3.1 问题描述

在一棵已经构造好的基于度约束的组播生成树中,如图1所示,图中节点ai有n个孩子节点,组成集合{c0,c1,,cn-1},这n个孩子节点中的任何一个都可能有孩子节点。当ai节点失效或者主动退出时,需要对组播树进行重构来保持组播树的结构,并保持数据传输。混合恢复方法利用给每个节点找到一个备用父节点的方法来保持组播树结构。

2.3.2 PTR方法

定理2 如果失效节点ai的所有子节点c0,c1,,cn-1的剩余度之和满足条件∑${}_{j=0}^{n-1}$Dr(cj)n-1,则可以在ai的父亲节点ai-1和ai的所有子节点之间构建一颗树,从而将分裂的树枝连接到组播树上[6]。

在PTR方法中,利用定理2,运用2.1节中提到的基于度的Prim方法直接生成新的生成树,从而为每个节点计算备用父节点。当∑${}_{j=0}^{n-1}$Dr(cj)>n-1时,因为ai-1与ai的孩子节点c0,c1,,cn-1之间不能直接构造组播树,这时需要从c0,c1,,cn-1的子节点中选择有剩余度的节点,设cj的子节点为sj1,sj2,,sjm,且满足∑${}_{j=0}^{n-1}$Dr(cj)+∑${}_{m=0}^{d{}_j}$sjm>n-1,此时在这些所有的节点之间构成组播树,这个做法很大程度上增加组播树的深度。这种方法不能保证重构组播树的完整性,且重构后会有组播树深度过大问题。

2.3.3 混合恢复方法

根据节点剩余度的差异,以优化延迟和提高恢复组播树的完整性为目标,将组播树恢复分成两类:若失效节点的子节点有足够的剩余度,利用经过分析改进的PTR方法,利用定理2可以保证此时组播树恢复的完整性;否则,将从候选节点队列中寻找合适的节点定为备用父节点,此时的组播恢复完整性通过推论1来保证。

2.3.3.1 改进的PTR方法建模

如图1,当∑${}_{j=0}^{n-1}$Dr(cj)n-1时,建立模型2:

GIVEN:

(1) 节点ai,它的父亲节点ai-1和它的孩子节点c0,c1,,cn-1构成一个无向完全图G=(V,E),以及每条边的权值ω(e);

(2) T节点ai,它的父亲节点ai-1和它的孩子节点c0,c1,,cn-1的剩余度Dr;

(3) ∑${}_{j=0}^{n-1}$Dr(cj)n-1。

FIND: 最小生成树T=(V,E′),使得:

(1) E′⊆E;

(2) 满足度约束条件,即对任何节点cj,它在T中的度小于或等于Dr(cj);

(3) 总的权值∑e∈Eω(e)最小。

根据定理2,可以在ai-1,c0,c1,,cn-1之间构建一颗最小延迟树。从而求解模型2的1、2条件,但涉及到条件3的问题为NP完全问题,因此不能通过多项式算法来求解。生成的延迟树中c0,c1,,cn-1的父节点即为各自的备用父节点。在求解模型的算法中组播树恢复进行分析采用。

2.3.3.2 候选节点队列选择方法建模

当∑${}_{j=0}^{n-1}$Dr(cj)>n-1,建立模型3:

GIVEN:

(1) 节点ai,它的父亲节点ai-1和它的孩子节点c0,c1,,cn-1;

(2) 所有节点构成一个无向完全图G=(V,E),及每条边的权值ω(e);

(3) 所有节点的剩余度Dr;

(4) ∑${}_{j=0}^{n-1}$Dr(cj)>n-1。

FIND:c0,c1,,cn-1的备用父节点,使得利用此父节点进行重构后的组播树比所有其余方式重构的组播树的总权值小。

根据推论1,只要组播树的节点满足度大于等于2,则可以完成组播树重构,利用这个性质,将所有的有剩余度的节点归为一个集合,让c0,c1,,cn-1从中选择合适的节点成为自己的备用父节点。

2.3.3.3 求解模型

根据上述两个模型,将算法分成两个部分:

1) 改进的PTR方法

对于模型1,我们考虑以下问题对PTR方法进行算法上的改进:如图1点cj剩余度Dr(cj)越大,应该优先考虑放在离根近的位置,这样能够降低重构组播树的深度,从而降低重构组播树根到叶子节点的延迟;而节点cj到根节点ai-1的延迟ω(e(cj,ai-1))越小,应该优先考虑放在离根近的位置,这样能够降低重构组播树根到叶子节点的延迟。因此,考虑rat(cj)=Dr(cj)/ω(e(cj,ai-1)) (其中ai-1为重构组播树的根节点,见模型2),首先考虑ai的所有孩子节点中rat值最大的节点,将其分配为ai-1的子节点,然后依次考虑,完成组播树。

算法1 具体步骤:

(1) 根据上述公式计算出所有孩子节点的rat值;

(2) 将所有的孩子节点根据rat值排序;

(3) 依次将这些孩子节点插入到以ai-1为根的树中;

(4) 此树中任意孩子节点的父亲节点即为备用父节点。

算法结束。

2) 候选节点队列选择方法

对于模型2,将所有剩余度Dr>0且不为模型2中为失效节点子孙的节点构成一个集合S,此集合必不为空,否则,因为所有的叶节点k也有Dr(k)>1,则Dr(k)>0,则有所有的叶节点都在模型2的孩子节点为根的子树中,则根不再有别的子树;又对根节点r有Dt(r)>1,因此根的子树必然大于1,与假设矛盾。依次为所有模型2的孩子节点找到离根最近的备用父节点并将此孩子节点为根的子树计算并归入集合中,更新集合。

在这个过程中,根据推论1,可以一直保证集合S非空,为每个节点找到备用父节点(根节点的孩子节点除外,若根节点失效,则整个组播树失效,所以不必考虑为根节点的孩子节点找到备用父节点)。因此该方法可以保证组播树恢复的完整性。

算法2 具体步骤:

(1) 计算集合S(所有剩余度Dr>0且不为模型2中为失效节点子孙的节点构成一个集合)和T(所有失效节点的孩子节点构成的结合);

(2) while(|T|≠Ø) 循环处理(3)和(4);

(3) 从T中取出节点a,从S中找到节点t,使得ω(e(a,t))+ω(e(t,r))最小,其中r为根节点,将节点t置为a的备用父节点;

(4) 将a从T中删除,并将a及a的子树满足Dr>0的节点加入到S中。

算法结束。

整体算法即为考虑组播树上的所有除开根节点和叶节点以外的节点构成的集合,遍历这个集合中所有的节点,根据模型1和模型2的条件的不同选择算法1或算法2来为节点的孩子节点寻找备用父节点。

3 实验和分析

本文采用模拟网络环境NS2搭建组播实验,假设终端主机数量为20～200,链路传输数据时间为10ms～100ms,主机度为2～8。在实验中主要从恢复延迟、管理代价(包括恢复管理代价和部署代价)和恢复完整性三个方面分析了本文算法在组播中的影响。

从图2、图3可以看出,本文中的算法在节点修复时间(恢复延迟)和管理代价上都比PTR算法要小,而相较于响应式算法更是有很大的提高。从图4可以看出本文中的算法在重构后对组播树的整体组播延迟比PTR算法有较好的改进。对于恢复完整性,通过图4和以上的分析,重构算法在保持组播树完整性的前提下降低了最大延迟,对于组播重构完整性,本文通过推论1来保持。

4 结 语

本文通过对评价组播树恢复方法的几个方面进行分析,针对高可靠性的服务不能容忍丢失的要求,提出了一种新的基于度受限的预先式恢复方法的方案。通过仿真实验,从恢复延迟、管理代价和恢复完整性几个方面与目前常用的几种方法进行了比较,验证了此方案的正确性和有效性。

摘要：应用层组播树中某个非叶子节点失效后,需要重新构建组播树保证失效节点的子孙节点能够正确接收数据。针对这一问题,考虑满足高可靠性环境中保证恢复完整性的情况,提出一种基于备用父节点的组播树预先式恢复方法,即为每个非根节点找到一个备用父节点,使得当某一非叶节点失效时可以迅速的恢复组播树。首先建立模型并对其求解构造恢复方法,然后论证此方法保证组播树恢复的完整性,最后通过仿真实验验证了此方法的有效性以及其在恢复延迟和管理代价上的改进。

关键词：应用层组播,组播树重构,备用父节点

参考文献

[1]X ing Jin,Ken Y iu W P,Gray Chan S H.Loss Recovery in Application-LayerMulticast[J].IEEE Computer Society,2008,31(3):18-27.

[2]Nonnenmacher J,B iersack E,Towsly D.Parity-Based Loss Recoveryfor Reliab le Mu lticast Transm ission[J].IEEE/ACM Trans.Networ-k ing,1998,6(4):349-361.

[3]Banerjee S,et al.ResilientMu lticastUsing Overlays[J].IEEE/ACMTrans.Network ing,2006,14(2):237-248.

[4]Goyal V.Mu ltiple D escription Cod ing:Compression M eets the Network[J].IEEE S ignal ProcessingMag,200118(5):74-93.

[5]D eshpandeH,BawaM,Garcia-MolinaH.Stream ing live m ed ia over apeer-to-peer network[R].Techn ical Report CS-2001-31,CS dept.Stanford Un iversity:149-155.

[6]YangM engkun,Fei Zongm ing.A proactive approach to reconstructingoverlay mu lticast trees[C]//Proc.of the 23 rd Annual Joint Confer-ence of the IEEE Computer and Commun ications Societies.New York,USA:IEEE Press,2004:2743-2753.

[7]朱誉东,黄东军,杨珊.度受限的应用层组播树预先式重构方法[J].计算机工程,2009,35(13):93-98.