王照旗，王志謙，李 青

（北京郵電大學 a.信息光子與光通信研究院；b.教育信息化辦公室，北京 100876）

HFC網絡雙向改造以來，數(shù)字電視事業(yè)蓬勃發(fā)展，尤其是交互式視頻點播系統(tǒng)。這種技術，使用戶可以選擇他們需求的媒體資源[1]。隨著交互式技術的不斷發(fā)展、業(yè)務的不斷推廣、客戶群體的不斷增加，服務器上固有的媒體資源已經難以滿足用戶的需求，通過一種方式向服務器里增加更多的媒體資源是十分必要的。因此選擇一種資產注入方式顯得比較重要。資產注入的方式有兩種[2]，文件形式的分發(fā)和流形式的分發(fā)。

文件形式的分發(fā)，是基于傳統(tǒng)的FTP（File Transfer Protocol）分發(fā)技術。在分發(fā)實現(xiàn)中，要求SS（Stream Server）流媒體服務器要具有FTP客戶端的功能，可以從一個FTP服務器上獲取媒體資源，又要具有FTP服務端的功能，向FTP客戶端提供媒體資源服務。

流形式的分發(fā)，是基于組播技術，是將媒體資源從實時源（Real Time Source）以流的方式組播到一組或多組流媒體服務器。流形式的分發(fā)是對資產進行實時編碼，分發(fā)速率和媒體加密速率相同。這種分發(fā)技術把一個資產組播到多個流媒體服務器，流分發(fā)的速率比文件編碼的速率更高。

FTP是常用的文件傳輸協(xié)議，它分別適用于點對點的文件傳輸和點對多點文件傳輸。在針對多用戶傳輸大文件時，會造成FTP服務器以及網絡負載過重。FTP技術傳輸安全性高、支持斷點續(xù)傳，并不受IP地址限制。組播適用于點對多點傳輸，針對多用戶傳輸大文件時，組播相比FTP傳輸具有優(yōu)勢，但組播沒有糾錯機制，丟包后難以彌補。FTP技術和組播技術各有優(yōu)缺點。

本文主要介紹了NGOD2.0架構下運用組播技術進行資產注入。

1 NGOD架構

20世紀90年代后期，美國時代華納公司制定了以VOD代表交互式服務的ISA網絡架構。21世紀初，美國康卡斯特公司汲取ISA架構的經驗，提出了自己的標準：下一代視頻點播服務標準——NGOD（Next Generation On Demand Video Architecture）架構[3]。

美國康卡斯特公司是集多業(yè)務（廣播、電視、寬帶及IP電話）于一體的有線運營商，先后發(fā)布了NGOD1.0，NGOD2.0以及NGOD3.0標準和接口協(xié)議。架構中所涉及到的業(yè)務組件，可以由一個或多個不同的模塊組成，組件功能劃分的更細更具體，與之前的ISA架構相比，NGOD架構所規(guī)定的組件允許一個物理模塊中實現(xiàn)一個或多個組件。

NGOD架構中，提出了控制和管理資產注入組件、RTM（Real Time Management）組件。RTM可以簡單有效的方式控制對資產文件的注入和更改處理。RTM定義了2個接口：A4和A5接口。A4接口位于RTM與AMS（Asset Management System）之間用于資產元數(shù)據(jù)的發(fā)布[4]，A5接口位于RTM與RTS之間用于控制資產注入。NGOD框架中與資產注入相關的組件如圖1所示。

2 RTM組件

RTM是NGOD架構中的一個組件，通過A5接口對RTS進行控制和管理。當管理員要組播一個節(jié)目時，首先會通過RTM通知相應的SS去準備接收媒體資源。RTM向RTS發(fā)送一條捕獲命令的消息，RTS收到捕獲命令消息后，進行組播。當?shù)谝粋€包組播完成后，RTS會向RTM發(fā)送媒體資源當前的狀態(tài)。當完成組播后，RTS向RTM發(fā)送媒體資源組播完成的狀態(tài)信息，說明整個媒體資源已經組播完成[5]。

2.1 RTM與RTS之間的socket連接方式

RTM與RTS之間的socket連接方式有兩種：短連接（圖2所示）和長連接（圖3所示）。

在短連接中，RTM向RTS發(fā)送請求消息，RTS會根據(jù)請求的消息給出相應的響應，之后客戶端就關閉連接，之后每次RTM與RTS進行通信都要事先建立連接。在長連接中，RTM向RTS發(fā)送請求消息，RTS響應之后，不會關閉連接，而是一直保持連接。如RTM和RTS之間建立了一條通道，該通道建立之后，就一直存在。

這兩種連接方式各有優(yōu)缺點，如RTM與RTS兩個組件：RTM為客戶端，RTS為服務端。

當用短連接實現(xiàn)客戶端與服務端之間的連接時，客戶端會用socket與服務端之間建立一個連接，然后發(fā)送一個請求，服務端接收到請求之后會根據(jù)客戶端請求的內容返回一個響應，客戶端接收到響應后，就斷開這個socket連接。如果客戶端發(fā)現(xiàn)接收到的響應消息是錯誤的，那么它會再建立一個socket連接，繼續(xù)向服務端發(fā)送請求，直到接收到正確的響應消息。當然，如果客戶端和服務端長時間進行信息來往，每次客戶端發(fā)送消息的時候都要建立socket連接，這樣會造成時間上的延遲和不必要的麻煩。

當用長連接實現(xiàn)時，客戶端與服務端之間建立的socket會一直保持連接狀態(tài)，比如：當客戶端向服務端發(fā)送請求時，會先建立一個socket連接，這個socket是客戶端與服務端唯一標識的通道。客戶端發(fā)送請求，服務端收到以后響應相應的消息，客戶端接收到服務端發(fā)送的請求消息響應以后，不會馬上關閉socket，而是一直保持連接。當客戶端再次發(fā)送請求或消息時，不用再次建立socket連接，而是用以前已建立好的socket進行通信。當然，如果在長連接中運用心跳Keep Live，則會根據(jù)客戶端和服務端之間socket空閑時間長短來決定是否關閉socket，這樣可以使資源得到合理的利用。

2.2 RTM的主要接口和業(yè)務處理流程[6]

2.2.1 A4接口簡介

A4接口主要用于RTM和AMS之間進行資產元數(shù)據(jù)發(fā)布的信息交互。此接口基于HTTP協(xié)議，POST方法進行交互，在消息處理過程中，消息的交互是通過XML文本進行傳送內容實體，請求頭中必須包含請求內容類型（content-type）和請求內容長度（content-length）。

RTM要發(fā)布資產的時候，通過A4接口把媒體資源信息發(fā)布到應用服務器和資產傳播服務器上，以便對媒體列表進行更新。

業(yè)務處理主要如下：

1）RTM在組播之前會通過HTTP協(xié)議發(fā)送資產的元數(shù)據(jù)信息包給AMS，AMS響應此消息。

2）RTM在組播完成之后也通過HTTP協(xié)議發(fā)送資產的內容信息給AMS，AMS響應此消息。

2.2.2 A5接口及其業(yè)務處理流程

A5接口主要用于RTM與RTS之間進行組播消息的交互。此接口也基于HTTP協(xié)議，同樣使用POST方法進行交互，在組播消息的交互過程中，消息的交互是通過XML文本進行傳送的，請求頭中必須包含請求內容類型（content-type）、請求內容長度（content-length）和請求序列號（CSEQ）。

當SS已經準備好接收流媒體資源的情況下，RTM會向RTS發(fā)送組播請求，之后RTS開始組播。

RTM表現(xiàn)為HTTP客戶端和服務器（具體交互方式如下）。

1）組播流程

（1）RTM向RTS發(fā)送組播消息，該消息中包括有關這個資產特有的資產ID、源ID、組播的開始時間、截止時間和組播的URL地址。

（2）當RTS收到這個組播消息時，會從這個組播消息中解析出資產ID、源ID以及組播地址等信息，根據(jù)源ID和組播地址等信息選擇此源ID所對應的資產，根據(jù)組播地址將媒體資源組播。

（3）當媒體資源組播完成一個包之后，RTS向RTM發(fā)送媒體資源組播的狀態(tài)消息，該消息包括該媒體的源ID、組播時間、組播的狀態(tài)以及組播包的大小等信息。

（4）RTM接收到RTS發(fā)送來的狀態(tài)信息后，可供客戶查看媒體資源組播的狀態(tài)。

（5）當媒體資源組播完后，RTS再次向RTM發(fā)送媒體資源組播完成的狀態(tài)消息，說明該媒體資源組播已經完成。交互流程如圖4所示。

2）取消組播請求

圖4 組播交互流程

圖5 取消組播交互流程

（1）當RTS接收到組播消息之后，在RTS組播開始之前，到組播結束的這段時間內，如果RTM要取消組播該資產，則會向RTS發(fā)送一條取消組播的消息，該消息包括媒體的源ID（Source ID）、組播的開始時間（Capture Start）以及原因碼（Reason Code）。

（2）RTS收到取消組播的請求消息后，RTS會根據(jù)消息中媒體的源ID和組播開始時間來斷定當前組播的媒體資源，并取消該媒體資源的組播，響應該媒體的狀態(tài)。交互流程如圖5所示。

3）更改組播信息

（1）組播參數(shù)的更改。組播參數(shù)的更改必須在RTS收到組播消息之后、準備開始組播之前。當RTM改變了組播的節(jié)目或改變組播的地址信息時，會向RTS發(fā)送更改參數(shù)的請求消息，RTS收到該消息進行相應修改后，進行組播。

（2）組播開始時間的更改。組播開始時間也必須在組播開始之前進行更改，RTM向RTS發(fā)送組播更改消息。

（3）截止時間的更改。截止時間的更改是從組播開始前到組播完成前的時間段內，如果因其他原因造成組播的延遲，則RTM會向RTS發(fā)送組播更改消息，該消息與組播消息里的內容相同，僅僅是對組播的截止時間進行了更改。RTS收到消息后，會根據(jù)組播消息的截止時間，對要組播的媒體資源進行相應的延遲。

3 存在的問題[5]

3.1 資產狀態(tài)遷移

在組播過程中，流媒體服務器對接收媒體資源的狀態(tài)是否反饋到RTM，以確定媒體資源是否完整的接收未做詳細介紹。在RTM與RTS交互過程中，組播開始后，當RTS組播一個包后，RTS會返回一個當前媒體資源的狀態(tài)信息，流媒體服務器接收到媒體文件的一個包之后，反饋該媒體資源的接收狀態(tài)信息到AMS之后再反饋到RTM，以便RTM方便查看媒體資源是否完整的組播和完整的接收。在組播的過程中以及組播結束后，任何有關媒體資源狀態(tài)的遷移都應該及時地反饋到RTM，以方便RTM對媒體文件的管理。

3.2 實時源RTS的選擇

在資產的注入過程中可能涉及到中心地區(qū)和邊緣地區(qū)之分，實時源的選擇可根據(jù)地域的不同而選擇，比如中心向邊緣進行資產的注入過程中，可能有多個實時源，這些實時源分布在不同的位置，因此選擇相應的實時源是比較重要的?？梢圆扇≈行呐c邊緣相結合的方式進行資產注入，具有地區(qū)性的資產可采取該地區(qū)的實時源進行資產注入，具有普遍性的資產可采取中心集體注入。

4 結束語

NGOD架構中利用組播技術進行資產注入，不僅有效地減少了資產注入所占用的網絡流量，而且還減輕了服務器負載，因而運用組播技術進行資產的注入是很有效的。但是運用組播技術進行資產注入也有缺點，如沒有糾錯機制，發(fā)生丟包后難以彌補，但可以通過一定的容錯機制和QoS加以彌補。這些缺陷理論上都有成熟的解決方案，只是需要逐步應用到現(xiàn)實網絡中。

[1]吳暢渠.淺談VOD系統(tǒng)[J].赤峰學院學報，2009，25（6）：25-26.

[2]Comcast Corp.ASSET architecture version 2.0[Z].[S.l.]：Comcast Corp,2006.

[3]Comcast Corp.NGOD Overall Architecture Version 2.0[Z].[S.l.]：Comcast Corp,2006.

[4]Comcast Corp.ASSET A6 AMS Version2.0[Z].[S.l.]：Comcast Corp,2006.

[5]Comcast Corp.ASSET A5 RTS Version2.0[Z].[S.l.]：Comcast Corp,2006.

[6]Comcast Corp.ASSET A4 RTM Version2.0[Z].[S.l.]：Comcast Corp,2006.