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

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

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

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

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

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

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

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

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

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

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

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

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

3 實(shí)現(xiàn)方案與測(cè)試驗(yàn)證

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

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

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

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

accept(客戶請(qǐng)求)

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

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

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

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

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

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