基于CORBA的自適應流媒體中間件系統(tǒng)的設計與實現(xiàn)

1、基于CORBA的自適應流媒體中間件系統(tǒng)的設計與實現(xiàn)    摘  要 CORBA是基于對象技術(shù)的中間件平臺的最流行的標準之一，本文參考了OMG A/V流規(guī)范,提出了一個基于CORBA的流媒體中間件框架，并設計了其中的流連接管理器，QoS管理器，自適應協(xié)議棧。該框架解決了現(xiàn)今流媒體中間件的設計缺少協(xié)議棧的自適應配置和QoS自適應控制的問題。        關(guān)鍵詞 CORBA；流媒體；中間件；自適應 1 引言&#

2、160;   傳統(tǒng)的流媒體應用開發(fā)是面向過程并建立在網(wǎng)絡底層協(xié)議的基礎上的，在系統(tǒng)設計和實現(xiàn)過程中涉及大量底層通信協(xié)議細節(jié)。因此，開發(fā)復雜冗長、效率低下，難以實現(xiàn)軟件復用1。同時，分布式多媒體系統(tǒng)的多平臺、分布式的特點，帶來了系統(tǒng)的異構(gòu)性，也導致了多媒體應用開發(fā)的復雜化。傳統(tǒng)的中間件2（CORBA3,DCOM和Java RMI）在一定程度上很好地解決了這些問題。然而，在自適應能力上卻受到很大的*。另外，目前的Internet提供的是盡力而為(Best-effort)的服務，不能夠為流媒體4實時傳輸提供服務質(zhì)量保證。   &#

3、160;在此背景下,本文參考了OMG音/視頻流規(guī)范5，設計了一個基本CORBA的流媒體中間件，命名為MOStream，它提供了下面的幾個關(guān)鍵的功能：     流連接管理器分離了數(shù)據(jù)通道和控制通道，對單元流提供了有效的控制。     QOS管理器抽象了流終端系統(tǒng)間QoS協(xié)商，監(jiān)視和重新配置QoS的實現(xiàn)細節(jié)。     自適應協(xié)議棧抽象了在流建立開始和傳輸過程中自動配置協(xié)議棧的實現(xiàn)細節(jié)。2  MOStream系統(tǒng)結(jié)構(gòu) &#

4、160;  MOStream系統(tǒng)框圖如圖1所示：             圖1  MOStream系統(tǒng)結(jié)構(gòu)    MOStream框架中提供的主要模塊有：    流連接管理器：MOStream框架的核心，流的建立過程和控制過程在流連接管理器中進行設計。主要設計內(nèi)容包括：(1)流建立初期，對媒體設備的綁定，創(chuàng)建流節(jié)點,流控制對象和媒體控制對象

5、0;(2)流傳輸過程中，流節(jié)點間的遠程控制，包括停止，播放，回放和暫停等操作，這是通過CORBA中的對象請求代理(ORB)來實現(xiàn)的，ORB已經(jīng)提供了遠程調(diào)用機制，因此只需要利用已開發(fā)的ORB來進行設計。    QOS管理器：MOStream框架的服務組件，設計的目標是對流的質(zhì)量提供一個可接受的QOS保證6。主要的設計內(nèi)容：(1)QOS監(jiān)視，當某個媒體流的QOS不能滿足，QOS監(jiān)視器負責判斷和發(fā)送通知給QOS協(xié)商接口進行處理。在這里需要反饋協(xié)議的支持，例如RTP/RTCP7，這些協(xié)議被加入自適應協(xié)議棧的協(xié)議實現(xiàn)庫。發(fā)送方發(fā)送媒體數(shù)據(jù)時，使用這層的協(xié)議，加入

6、反饋信息(包序列號和時間戳)到媒體數(shù)據(jù)，在接收方得到并解釋了這個信息后就發(fā)送QOS報文給QOS監(jiān)視模塊進行判斷和相關(guān)的處理。(2)QOS協(xié)商,為了獲得統(tǒng)一的協(xié)商結(jié)果，接收方和發(fā)送方需要交換QOS參數(shù)協(xié)商一個雙方可接收的QOS水平。在QOS管理器都建立了一個在自適應協(xié)議棧的協(xié)議庫中存在的協(xié)議模塊的名字列表，流雙方可以通過這個列表來協(xié)商得到可接收的QOS配置結(jié)果，然后發(fā)送通知消息給QOS策略模塊處理。(3)QOS策略，在收到QOS協(xié)商發(fā)來的協(xié)商結(jié)果信息后，QOS策略動態(tài)重配置媒體流的自適應協(xié)議棧的協(xié)議棧，這樣新的流數(shù)據(jù)將以新的協(xié)議棧進行封裝并發(fā)送。    自

7、適應協(xié)議棧：設計的目標是在流傳輸過程中能對流的傳輸協(xié)議和壓縮格式等進行動態(tài)地選擇。主要設計的內(nèi)容有：(1)協(xié)議發(fā)現(xiàn)和選擇，主機應用開始一個流會話，并不知道存在的協(xié)議模塊，這些協(xié)議模塊通過它們所提供服務的名字能被知道和選擇。根據(jù)流所需要的服務，這些協(xié)議模塊能被動態(tài)地發(fā)現(xiàn)和選擇，構(gòu)建一個協(xié)議棧。(2)協(xié)議的依賴性配置，協(xié)議和服務之間存在一定的依賴性，在協(xié)議棧構(gòu)建的過程中，我們肯定會碰到這樣的問題，例如，TCP模塊需要底層IP模塊的支持，MPEG編碼提供的視頻輸出需要一個MPEG的視頻過濾器。(3)運行中的重配置，自適應協(xié)議棧提供在運行中對協(xié)議棧和協(xié)議模塊的重配置。這個特性使數(shù)據(jù)流在不受干擾的情況下

8、重配置協(xié)議模塊來滿足對QOS需求的改變。3  MOStream子系統(tǒng)的實現(xiàn)3.1 流連接管理器的實現(xiàn)    流連接管理的實現(xiàn)是參考的CORBA A/V流規(guī)范，在本文中不做詳細描述。3.2  QoS管理器的實現(xiàn)    QOS管理器支持實時流的QoS的自適應控制。在媒體流的傳輸過程中，我們可以使用實時流傳輸協(xié)議RTP保持實時數(shù)據(jù)的同步和實時流控制協(xié)議RTCP來監(jiān)視流數(shù)據(jù)的QoS質(zhì)量。在發(fā)現(xiàn)QoS違反的時候，需要一種機制動態(tài)地配置流來盡量滿足流的QoS的服務質(zhì)量

9、。QoS管理器就是為了這個目的而設計的。QoS管理器在接收到參數(shù)loss和delay的時候，需要對這些參數(shù)作出判斷是否有QoS違反，例如,delay超出QoS屬性delay_Max(可接收的最大延遲)時，就認為是一個QoS違反。在QoS違反時，可以選擇新的協(xié)議替換以前的協(xié)議來滿足QoS要求，新的協(xié)議必須在流的雙方都需要支持。在QoS管理器的設計中，每個單元流(Flow)都有一個關(guān)聯(lián)的協(xié)議棧，在發(fā)生違反時，需要重新配置的單元流的協(xié)議棧，這個協(xié)議棧是可以動態(tài)進行配置。在配置完后，需要對單元流(Flow)的設備參數(shù)和網(wǎng)絡參數(shù)進行設置，這可以通過屬性服務的set_property_value()來處理

10、。    QOS管理器設計的主要接口有：    QoSMonitor： QoS監(jiān)視接口 QoSconfig： QoS協(xié)商接口 QoSpolicy： Qos策略接口    圖2顯示了QoS的控制過程：圖2  QoS控制過程    發(fā)生QoS違反時QoS控制的工作流程如下(假設A為發(fā)送方，B為接收方)：    (1)首先，接受方在收

11、到流數(shù)據(jù)后，它的協(xié)議配置接口會發(fā)送QoS報文給QoS監(jiān)視接口(bQoSMonitor),這時，監(jiān)視接口通過check_QoS(QoSReport)對QoS報文進行檢查， check_QoS()操作中QoS監(jiān)視接口會調(diào)用屬性服務操作得到以前協(xié)商好的流服務質(zhì)量參數(shù)列表，在此列表中包含了最大延遲等參數(shù)值，這樣就可以根據(jù)這些參數(shù)值進行判斷，如果發(fā)生QoS違反將返回一個QoS違反的參數(shù)列表結(jié)構(gòu)。監(jiān)視接口將使用違反的參數(shù)列表發(fā)送配置請求給協(xié)商接口(bQoSconfig)；    (2)bQoSconfig發(fā)送協(xié)商請求給發(fā)送方的aQoSconfig進行協(xié)商，

12、將得到一個協(xié)商好的協(xié)議列表,然后發(fā)送方的協(xié)商接口會使用這個協(xié)議列表發(fā)送協(xié)議重配置請求給自己的QoS策略接口。得到協(xié)商好的協(xié)議列表后，發(fā)送方的策略接口將做兩個動作：1)發(fā)送協(xié)議配置請求給自己的協(xié)議配置接口;2) 發(fā)送重配置請求給相關(guān)的流控制接口；    (3)StreamCtrl發(fā)送修改配置請求給雙方的Vdev，缺省情況下，Vdev將簡單的發(fā)送轉(zhuǎn)發(fā)這個請求給與雙方Vdev相聯(lián)系的流節(jié)點，它將調(diào)用set_property_value()操作設置屬性CurrFormat,CurrProtocol,然后重新加載新的協(xié)議棧。3.3自適應協(xié)議棧的實現(xiàn)

13、60;   自適應協(xié)議棧中定義了Protocols和ProtocolStack兩種結(jié)構(gòu)，如下所示：    Protocols是一個協(xié)議列表，可以包含協(xié)議棧支持的所有協(xié)議組件。其中，參數(shù)protocol-_name(協(xié)議的名字)和module_name(協(xié)議protocol_name的實現(xiàn)模塊)支持協(xié)議的發(fā)現(xiàn)和選擇,參數(shù)related_protocols(必須關(guān)聯(lián)的協(xié)議)支持協(xié)議的依賴性配置。protocolStack是一個協(xié)議棧結(jié)構(gòu),每個單元流都有一個協(xié)議棧結(jié)構(gòu)，在QoS改變時,單元流不需要停止目前的傳輸，只需把單元流節(jié)點的

14、protocolStack的值設置為新的協(xié)議棧，并釋放舊協(xié)議棧的資源，然后在下一個媒體數(shù)據(jù)發(fā)送時就可以使用新的協(xié)議棧,這樣就可以支持協(xié)議棧的動態(tài)配置。    自適應協(xié)議棧設計的接口有：    ProtocolConf：協(xié)議配置接口         ProtocolReg：協(xié)議注冊接口    以下是這些接口的詳細設計：     協(xié)議配置接口

15、(ProtocolConf)    協(xié)議配置接口主要負責為每個單元流(Flow)建立協(xié)議棧和動態(tài)配置。在流建立初期，接收方和發(fā)送方的虛擬多媒體設備和流節(jié)點(StreamEndpoint)之間有一個設備參數(shù)和網(wǎng)絡參數(shù)的協(xié)商過程，協(xié)商成功后，流節(jié)點會發(fā)送協(xié)議棧建立請求給協(xié)議配置接口,然后ProtocolConf為每個單元流(Flow)建立協(xié)議棧。如果單元流(Flow)發(fā)生QoS違反，ProtocolConf會收到來自QoS策略接口的協(xié)議重配置請求modify_QoS (new_protocol)，它將復制該單元流(Flow)的協(xié)議棧，然后對該協(xié)議棧

16、進行重新配置，配置成功后，發(fā)送協(xié)議棧重配置請求給單元流節(jié)點,這時單元流節(jié)點將加載新的協(xié)議棧，釋放舊協(xié)議棧的資源，這樣做可以不影響單元流當前的傳輸，在新的協(xié)議棧配置成功后，單元流節(jié)點將使用新的協(xié)議棧。     協(xié)議注冊接口(Protocolreg)    在Protocol結(jié)構(gòu)中，每個協(xié)議名protocol_name都對應可用的模塊名module_name，這樣只要提供所需的協(xié)議名，就可以找到協(xié)議的實現(xiàn)模塊。協(xié)議注冊接口(Protocolreg)允許增加新的實現(xiàn)模塊，因為協(xié)議棧是通過協(xié)議名來配置，在新的實現(xiàn)

17、模塊建立后，需要發(fā)送protocol_reg(module_name)注冊這個模塊來增加新的可用協(xié)議。4  結(jié)論    目前存在的流媒體中間件對QoS控制，協(xié)議選擇的自適應能力都缺乏足夠的支持。本文的主要出發(fā)點就是擴展這兩項功能，設計了一個基于CORBA的流媒體中間件的框架結(jié)構(gòu)，該框架具有QoS和協(xié)議棧自適應能力，并對各個模塊和接口進行了詳細地設計。這樣可以規(guī)范并大大簡化流媒體的開發(fā)。參考文獻    1廖泰安,安志遠,沈升源著.軟件復用技術(shù)：在系統(tǒng)開發(fā)過程中考慮復用. 工業(yè)出版社" target=_blank>機械工業(yè)出版社.2003    2谷和啟.中間件主流技術(shù)及其未來發(fā)展精解. 2005.01.17    3OMG.Minimum CORBA Specification.2002-8-1    4鐘玉琢，向哲，沈洪.流媒體和視頻服務器.北京:清華大學出版社，2003