面向并發(fā)服務(wù)的流媒體訪問控制技術(shù)研究

采用單播、廣播和組播可以減輕服務(wù)器負(fù)擔(dān)，也能提高并發(fā)數(shù)。組播的多點投遞方式，使所有機器能夠接收每個分組的同一拷貝減少了資源浪費。而常規(guī)的點對點通信方式下，N個視頻站點的視頻傳輸至少要重復(fù)發(fā)送N-1次相同的數(shù)據(jù)包，發(fā)送時延大，而且隨著播放站點數(shù)量增長，時延就會迅速增長，這樣就不能適應(yīng)要求短時延的多點視頻傳輸。

1.3 基于實時傳輸?shù)膮f(xié)議機制

由于TCP需要較多的開銷，它的重傳機制和擁塞控制機制（Congestion Control Mechanism）不可避免地產(chǎn)生了傳輸延時和占用了較多的網(wǎng)絡(luò)帶寬，故不適合傳輸實時視頻音頻。在視音頻的流式傳輸實現(xiàn)方案中，一般采用HTTP/TCP來傳輸控制信息，用RTP/UDP來傳輸實時聲音數(shù)據(jù)。

實時傳輸協(xié)議RTP（Real-time transport protocol）[4]是用于internet上針對多媒體數(shù)據(jù)流的一種傳輸協(xié)議。RTP被定義為在一對一或一對多的傳輸情況下工作，其目的是提供時間信息和實現(xiàn)流同步。通常利用低層的UDP協(xié)議對實時視音頻數(shù)據(jù)進(jìn)行組播（Multicast）或單播（Unicast）,從而實現(xiàn)多點或單點視音頻數(shù)據(jù)的傳輸，當(dāng)然RTP也可以在TCP或ATM等其他協(xié)議之上工作。RTP本身并不能為按順序傳送數(shù)據(jù)包提供可靠的傳送機制，也不提供流量控制或擁塞控制，而是依靠RTCP提供這些服務(wù)保證實時傳輸?shù)牟僮鳌?p>實時傳輸控制協(xié)議RTCP(Real-time transport control protocol)和RTP一起提供流量控制和擁塞控制服務(wù)。在RTP會話期間，各參與者周期性地傳送RTCP包。RTCP包中含有已發(fā)送的數(shù)據(jù)包的數(shù)量、丟失的數(shù)據(jù)包的數(shù)量等統(tǒng)計資料，因此，服務(wù)器可以利用這些信息動態(tài)地改變傳輸速率，甚至改變有效載荷類型。RTCP是RTP的控制協(xié)議，RTP和RTCP配合使用能以有效的反饋和最小的開銷使傳輸效率最佳化，因而特別適合傳送網(wǎng)上的實時數(shù)據(jù)。

RTCP單獨運行在底層協(xié)議上監(jiān)視服務(wù)質(zhì)量并與會話者傳遞信息，RTCP是由接收方向發(fā)送的報文，它負(fù)責(zé)監(jiān)視網(wǎng)絡(luò)的服務(wù)質(zhì)量、通信帶寬以及網(wǎng)上傳送的信息，并將這些信息反饋給發(fā)送端，并提供QoS的檢測，提供不同媒體間的同步信息和會話參與者的標(biāo)識信息。

基于事件處理的多線程多緩沖區(qū)機制顯得更勝一籌。但是當(dāng)在廣域網(wǎng)中進(jìn)行視頻數(shù)據(jù)傳輸時，此時的傳輸性能極大地取決于可用的帶寬，由于TCP是面向連接的傳輸層協(xié)議，它的重傳機制和擁塞控制機制，將使網(wǎng)絡(luò)狀況進(jìn)一步惡化，從而帶來災(zāi)難性的延時。同時，在這種網(wǎng)絡(luò)環(huán)境下，通過TCP傳輸?shù)囊曨l數(shù)據(jù)，在接收端重建、回放時，斷點非常明顯，體現(xiàn)為明顯的斷斷續(xù)續(xù)，傳輸?shù)膶崟r性和傳輸質(zhì)量都無法保障。相對而言，采用RTP傳輸?shù)囊曨l數(shù)據(jù)的實時性和傳輸質(zhì)量就要好得多。

2 并發(fā)服務(wù)的任務(wù)調(diào)度策略

面對越來越巨大的流應(yīng)用需求，系統(tǒng)必須擁有良好的可伸縮性。隨著業(yè)務(wù)的增加和用戶的增多，系統(tǒng)需要靈活地增加現(xiàn)場直播流的數(shù)量，并通過增加帶寬集群和接近最終用戶端的邊緣流媒體服務(wù)器的數(shù)量，增加并發(fā)用戶的數(shù)量，不斷滿足用戶對系統(tǒng)的擴展要求。

通常情況下一個視頻流的播放準(zhǔn)備需要的準(zhǔn)備時間是比較長的。按照進(jìn)程方式提供服務(wù)的話，如果不斷接收到客戶的請求，同時又不斷地創(chuàng)建子進(jìn)程處理，必然會影響客戶的接收，其服務(wù)器并發(fā)數(shù)也大打折扣。因此，采用“預(yù)創(chuàng)建（prefork）”技術(shù)可以緩解這種情況的產(chǎn)生。服務(wù)器事先創(chuàng)建一定數(shù)目的子進(jìn)程，每個子進(jìn)程分別接受連接隊列中已建立連接的客戶連接。這樣，就由子進(jìn)程快速響應(yīng)并處理客戶請求。

并發(fā)與調(diào)度密切相關(guān)，如何分配任務(wù)給 CPU、如何調(diào)度任務(wù)直接影響到效率和可行性。效率較高的并發(fā)方法之一是“多線程”，也就是“線程化”。但線程化并不是唯一的并發(fā)構(gòu)造，它的實現(xiàn)依賴于資源的可用情況并有一定的局限性。文獻(xiàn)[5]中提到了多種可行的并發(fā)應(yīng)用模型，除線程化外，還有多處理、協(xié)同例程和基于事件的編程，以及連續(xù)（continuation）、生成器和其它一些構(gòu)造。

調(diào)度的任務(wù)就是合理劃分時間片和循環(huán)執(zhí)行各個線程，并能有效地監(jiān)測線程阻塞和消除。每個線程都占用一部分CPU時間片，每個時間片上一個線程運行，另一個時間片又可能是另外的線程在工作。

根據(jù)視頻流的傳送要求，并發(fā)服務(wù)的優(yōu)先級調(diào)度方式不適合專用于視頻服務(wù)的工作，這會造成優(yōu)先級高的視頻流強占低優(yōu)先級的視頻流服務(wù)。因此，為了達(dá)到每個視頻流服務(wù)的公平性，采用帶有可變加權(quán)的循環(huán)調(diào)度。其循環(huán)順序由申請服務(wù)的先后次序決定，以服務(wù)的時延最小進(jìn)行調(diào)整控制，實現(xiàn)各個服務(wù)的最小允許延遲保證優(yōu)質(zhì)服務(wù)。

3 實現(xiàn)方案與測試驗證

并發(fā)操作在同一時刻能夠處理多個客戶請求，從RTP/RTCP協(xié)議使用的角度來說，其實現(xiàn)方法也有多種，如服務(wù)器對每個接收到的客戶連接創(chuàng)建一個線程處理；或者預(yù)先創(chuàng)建多個線程，由這些線程處理請求。

當(dāng)然，使用多處理硬件更能較好地實現(xiàn)多任務(wù)的并發(fā)操作，特別是對于Linux使用多個處理器處理不同的線程時，并發(fā)效果要好的多。值得注意的是防止多個線程在單個處理器上造成瓶頸，而其它處理器卻處于空閑狀態(tài)，當(dāng)然其它并發(fā)方法有時也會造成類似的問題。這方面有賴于操作系統(tǒng)的性能，對Linux 2.4來說其缺省的“內(nèi)核線程”可以很好地調(diào)度線程，并將這些線程分配給不同的CPU。

3.1 實時傳輸?shù)男畔⒖刂?p>線程建立通信連接關(guān)系后，根據(jù)RTP提供的時間信息實現(xiàn)流同步，通過RTCP反饋的信息進(jìn)行數(shù)據(jù)流控制并動態(tài)調(diào)整傳輸率，保證數(shù)據(jù)延遲符合預(yù)定要求。

服務(wù)器監(jiān)聽端口，根據(jù)實際客戶請求量確定請求隊列的允許最大連接數(shù)目。

accept(客戶請求)

｛ 提取并分析請求隊列中的某一任務(wù)；

尋找具有相同視頻信號標(biāo)志的任務(wù)，使用組播技術(shù)設(shè)置ip地址由子進(jìn)程處理播放；否則后置單位時間St。處理時間St的任務(wù)(Proc_Client())。｝

while(客戶機與服務(wù)器成功連接——成功返回通信文件描述符)

{ CreateThread() //創(chuàng)建線程

{ 讀出當(dāng)前時間，并將當(dāng)前時間寫入通信文件描述符；

比較RTCP中資源信息與現(xiàn)有資源的差異，調(diào)整數(shù)據(jù)包發(fā)送大小和發(fā)送速度；如果子進(jìn)程的數(shù)據(jù)傳送完，則關(guān)閉通信文件描述符；反之，繼續(xù)傳送。}}