基于CORBA的自适应流媒体中间件系统的设计与实现

传统的流媒体应用开发是面向过程并建立在网络底层协议的基础上的，在系统设计和实现过程中涉及大量底层通信协议细节。因此，开发复杂冗长、效率低下，难以实现软件复用[1]。同时，分布式多媒体系统的多平台、分布式的特点，带来了系统的异构性，也导致了多媒体应用开发的复杂化。传统的中间件（CORBA,DCOM和Java RMI）在一定程度上很好地解决了这些问题。然而，在自适应能力上却受到很大的限制。另外，目前的Internet提供的是尽力而为(Best-effort)的服务，不能够为流媒体实时传输提供服务质量保证。

在此背景下,本文参考了OMG音/视频流规范，设计了一个基本CORBA的流媒体中间件，命名为MOStream，它提供了下面的几个关键的功能：

● 流连接管理器分离了数据通道和控制通道，对单元流提供了有效的控制。

● QOS管理器抽象了流终端系统间QoS协商，监视和重新配置QoS的实现细节。

● 自适应协议栈抽象了在流建立开始和传输过程中自动配置协议栈的实现细节。

MOStream系统框图如图1所示：

图1 MOStream系统结构

MOStream框架中提供的主要模块有：

流连接管理器：MOStream框架的核心，流的建立过程和控制过程在流连接管理器中进行设计。主要设计内容包括：(1)流建立初期，对媒体设备的绑定，创建流节点,流控制对象和媒体控制对象 (2)流传输过程中，流节点间的远程控制，包括停止，播放，回放和暂停等操作，这是通过CORBA中的对象请求代理(ORB)来实现的，ORB已经提供了远程调用机制，因此只需要利用已开发的ORB来进行设计。

QOS管理器：MOStream框架的服务组件，设计的目标是对流的质量提供一个可接受的QOS保证。主要的设计内容：(1)QOS监视，当某个媒体流的QOS不能满足，QOS监视器负责判断和发送通知给QOS协商接口进行处理。在这里需要反馈协议的支持，例如RTP/RTCP，这些协议被加入自适应协议栈的协议实现库。发送方发送媒体数据时，使用这层的协议，加入反馈信息(包序列号和时间戳)到媒体数据，在接收方得到并解释了这个信息后就发送QOS报文给QOS监视模块进行判断和相关的处理。(2)QOS协商,为了获得统一的协商结果，接收方和发送方需要交换QOS参数协商一个双方可接收的QOS水平。在QOS管理器都建立了一个在自适应协议栈的协议库中存在的协议模块的名字列表，流双方可以通过这个列表来协商得到可接收的QOS配置结果，然后发送通知消息给QOS策略模块处理。(3)QOS策略，在收到QOS协商发来的协商结果信息后，QOS策略动态重配置媒体流的自适应协议栈的协议栈，这样新的流数据将以新的协议栈进行封装并发送。

自适应协议栈：设计的目标是在流传输过程中能对流的传输协议和压缩格式等进行动态地选择。主要设计的内容有：(1)协议发现和选择，主机应用开始一个流会话，并不知道存在的协议模块，这些协议模块通过它们所提供服务的名字能被知道和选择。根据流所需要的服务，这些协议模块能被动态地发现和选择，构建一个协议栈。(2)协议的依赖性配置，协议和服务之间存在一定的依赖性，在协议栈构建的过程中，我们肯定会碰到这样的问题，例如，TCP模块需要底层IP模块的支持，MPEG编码提供的视频输出需要一个MPEG的视频过滤器。(3)运行中的重配置，自适应协议栈提供在运行中对协议栈和协议模块的重配置。这个特性使数据流在不受干扰的情况下重配置协议模块来满足对QOS需求的改变。

流连接管理的实现是参考的CORBA A/V流规范，在本文中不做详细描述。

QOS管理器支持实时流的QoS的自适应控制。在媒体流的传输过程中，我们可以使用实时流传输协议RTP保持实时数据的同步和实时流控制协议RTCP来监视流数据的QoS质量。在发现QoS违反的时候，需要一种机制动态地配置流来尽量满足流的QoS的服务质量。QoS管理器就是为了这个目的而设计的。QoS管理器在接收到参数loss和delay的时候，需要对这些参数作出判断是否有QoS违反，例如,delay超出QoS属性delay_Max(可接收的最大延迟)时，就认为是一个QoS违反。在QoS违反时，可以选择新的协议替换以前的协议来满足QoS要求，新的协议必须在流的双方都需要支持。在QoS管理器的设计中，每个单元流(Flow)都有一个关联的协议栈，在发生违反时，需要重新配置的单元流的协议栈，这个协议栈是可以动态进行配置。在配置完后，需要对单元流(Flow)的设备参数和网络参数进行设置，这可以通过属性服务的set_property_value()来处理。

QOS管理器设计的主要接口有：

QoSMonitor： QoS监视接口 QoSconfig： QoS协商接口 QoSpolicy： Qos策略接口