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

1、面向并發(fā)效勞的流媒體訪問控制技術(shù)研究摘要本文提出一種基于實時協(xié)議的多媒體數(shù)據(jù)流并發(fā)效勞控制模型，介紹了數(shù)據(jù)并發(fā)傳送的調(diào)度控制問題。由實時協(xié)議的反應(yīng)機制動態(tài)調(diào)整控制參數(shù)，到達平滑時延的目的。最后通過對時延參數(shù)的測試，說明這一數(shù)據(jù)流控制方式的合理性，同時該方法也適用于網(wǎng)絡(luò)視頻的多點實時傳輸、網(wǎng)絡(luò)多點實時監(jiān)控，有較高的應(yīng)用價值。關(guān)鍵詞并發(fā)調(diào)度動態(tài)調(diào)整實時模型實時數(shù)據(jù)傳輸對于視頻播放具有非常重要的意義，在各種網(wǎng)絡(luò)特性中時延參數(shù)占有相當?shù)姆萘?。通常認為視頻這類應(yīng)用其時延要求小于20毫秒s，抖動限制在4毫左?SUP13。盡管進步網(wǎng)絡(luò)帶寬可以改善網(wǎng)絡(luò)的吞吐量、傳輸延時等性能，由于視頻數(shù)據(jù)的高容量和視頻信源的

2、高比特率特性，對于客戶端的效勞質(zhì)量要求來說顯得微缺乏道。目前針對視頻效勞質(zhì)量，從傳送層協(xié)議的使用、數(shù)據(jù)的壓縮/解壓、協(xié)同計算到單播/組播等多方面提出了許多措施。考慮到網(wǎng)絡(luò)傳輸狀況的多樣性，本文重點討論效勞器端的數(shù)據(jù)傳送調(diào)度控制，和并發(fā)效勞的關(guān)鍵技術(shù)，盡可能地降低傳輸中的時延抖動問題，進步并發(fā)效勞質(zhì)量，文中最后給出了關(guān)鍵控制代碼和測試結(jié)果。1信源數(shù)據(jù)的并發(fā)傳輸模型并發(fā)連接對于網(wǎng)絡(luò)視頻應(yīng)用來說，有別于以往的EB頁面式效勞和FTP效勞，每個視頻數(shù)據(jù)流至少需要384kb/s的帶寬甚至更高。同時傳輸效勞還需要具有一定的余量，防止并發(fā)客戶懇求數(shù)到達峰值、或網(wǎng)絡(luò)短期過載現(xiàn)象。因此適宜的效勞模型、良好的效勞策

3、略是優(yōu)質(zhì)效勞的保障。對即時的影像流壓縮與傳輸要求來說，在效勞模型中還需要針對網(wǎng)絡(luò)系統(tǒng)的資源限制條件，即網(wǎng)絡(luò)帶寬采取適應(yīng)視頻傳輸?shù)牟呗?，以便處理突發(fā)性事件。另一個需要考慮的限制是效勞器提供的并發(fā)連接數(shù)量以及等候處理的發(fā)送調(diào)用。因為并發(fā)連接數(shù)量越多，所消耗的未分頁內(nèi)存池也越多；等候處理的發(fā)送調(diào)用越多，被鎖定的內(nèi)存頁面也越多，極易超過系統(tǒng)資源的極限。1.1效勞器的視頻傳輸效勞特點視頻傳輸需要較寬的網(wǎng)絡(luò)帶寬，其視頻的壓縮編碼、傳輸信道和網(wǎng)絡(luò)協(xié)議的選擇、IP組播技術(shù)對傳輸質(zhì)量具有重要的影響作用?；谟嬎銠C網(wǎng)絡(luò)連接的視頻點播系統(tǒng)，其關(guān)鍵就在于多個站點視頻的網(wǎng)絡(luò)通信問題，要求做到傳輸時延盡可能小，盡可能少地

4、占用現(xiàn)有的網(wǎng)絡(luò)帶寬，并具有較好的站點數(shù)量規(guī)?；匦?。視頻效勞器對于用戶的懇求，需要在較短的時間間隔內(nèi)響應(yīng)并傳送所要求的視頻數(shù)據(jù)，同時隨時準備響應(yīng)新的懇求。因此視頻效勞器的性能直接決定系統(tǒng)的總體性能，為了能同時響應(yīng)多個用戶的效勞懇求，視頻效勞器需要調(diào)度效勞。并具備接納控制、懇求處理、數(shù)據(jù)檢索、按流傳送等多種功能，提供實時、連續(xù)穩(wěn)定的視頻流，以確保用戶懇求獲得有效效勞。再者，視頻效勞器還需要提供交互效勞，如快進和快倒等功能，因此視頻效勞器必須滿足視頻流特性使用中的各種要求。1.2效勞器的并發(fā)效勞技術(shù)通?？蛻粜谄鏖g的通信過程首先是建立點到點的直接聯(lián)絡(luò)方式，因此效勞器的負載才能決定了視頻點播的并發(fā)容

5、量。在客戶機/效勞器傳輸方式中，在面向連接的通信形式下，效勞器需要翻開監(jiān)聽端口，監(jiān)聽網(wǎng)絡(luò)上其它客戶機向該效勞器發(fā)出的連接懇求，當收到一個懇求信號時與該客戶機建立一個連接，之后兩者進展交互式的通信。這在客戶端懇求較少，同時數(shù)據(jù)傳輸量不大的情況下傳輸延遲還可以忍受。對于實時性要求較高的視頻應(yīng)用，一般采用無連接的通信形式。如PEG-I按照1.5b/s傳輸在滿足觀看需要的情況下其幀數(shù)也要大于10幀以上。另外，當多個用戶同時申請效勞的時候，效勞器建立連接分配資源等都需要產(chǎn)生延遲，也就是說對于用戶的響應(yīng)經(jīng)過逐漸積累延遲會越來越大。假如懇求池缺乏的話，那么就會產(chǎn)生客戶的懇求喪失。因此，同一時刻只能處理一個客

6、戶懇求的循環(huán)效勞器方式不合適視頻點播。假如采用并發(fā)效勞方式2，在效勞器端用主進程去監(jiān)聽客戶機的連接懇求，當有客戶機的連接懇求時通過創(chuàng)立線程的方式獨立處理客戶機通信，進步視頻傳輸?shù)膶崟r性。視頻數(shù)據(jù)的并發(fā)傳輸，本質(zhì)依賴于效勞器中的傳輸線程，效勞器的操作以建立相應(yīng)的線程實現(xiàn)效勞為目的，這種效勞形式非常合適復(fù)雜的多任務(wù)懇求。從計算機操作系統(tǒng)運行的角度來說，在典型的單處理器主機上，任務(wù)實際上并不是同時執(zhí)行的。內(nèi)核中稱為調(diào)度程序的局部將工作換進換出，從而讓所有工作都獲得一輪執(zhí)行。在同一個時間間隔內(nèi)，并發(fā)模型常?；谑录木幊虒崿F(xiàn)。通常情況下，線程數(shù)量取決于應(yīng)用程序的特定需要，理想情況下線程數(shù)量與處理器數(shù)量

7、相當為好，雖然線程數(shù)量無法保證傳輸質(zhì)量，但線程太少又會造成傳輸效率低，特別是用戶數(shù)量較多的情況下更為明顯。從視頻應(yīng)用來說，影響視頻傳輸性能的根本原因在于視頻數(shù)據(jù)的連續(xù)傳送和用戶提交給效勞器的懇求無法及時響應(yīng)，超過了網(wǎng)絡(luò)資源節(jié)點容量或效勞器的處理才能。這樣就造成網(wǎng)絡(luò)系統(tǒng)的數(shù)據(jù)包時延增加、丟棄概率增大、上層應(yīng)用系統(tǒng)性能下降等。主要表如今以下幾方面：并發(fā)連接數(shù)決定系統(tǒng)內(nèi)存資源的消耗，并與PU的處理才能親密相關(guān)。視頻效勞要求效勞器盡快地把數(shù)據(jù)通過網(wǎng)絡(luò)發(fā)送，盡量減少對連接懇求的處理延遲，以免效勞懇求的重發(fā)和喪失。物理鏈路的實際承載才能也影響并發(fā)連接的處理才能。根據(jù)香農(nóng)信息理論，任何信道帶寬最大值即信道容

8、量:=Blg2(1+S/N)N為信道白噪聲的平均功率，S為信源節(jié)點的平均功率,B為信道帶寬。所有信源節(jié)點發(fā)送的速率R必須小于或等于信道容量。假如R，那么在理論上無過失傳輸就是不可能的，所以效勞器與網(wǎng)絡(luò)的聯(lián)結(jié)處會形成傳輸瓶頸。交換機或路由器的處理才能弱：假如路由器的PU在執(zhí)行排隊緩存、更新路由表等功能時，處理速度無法與高速鏈路匹配，就會造成效勞失效。隨著網(wǎng)絡(luò)規(guī)模的擴大和用戶數(shù)的激增，數(shù)據(jù)流傳輸更趨于頻繁，線程數(shù)量不可能無限制增加。假如效勞器和客戶之間沒有緩沖余地必然會出現(xiàn)丟棄數(shù)據(jù)包的情況。當數(shù)據(jù)包丟棄時，源節(jié)點端會超時、重傳該包。由于沒有得到確認，源節(jié)點端只能保存數(shù)據(jù)包，結(jié)果緩存會進一步消耗。因

9、此，采用合理的算法與機制,按需分配傳輸線程占用的網(wǎng)絡(luò)資源對于網(wǎng)絡(luò)傳輸至關(guān)重要。值得指出的是，帶寬保證是視頻實時傳輸?shù)母?，帶寬假如完全均分，每個站點都得到總帶寬的1/n設(shè)存在n個站點，顯然不能適應(yīng)實際的帶寬需求；因此，有必要根據(jù)重要性、實時性分配帶寬使用的優(yōu)先級，利用“流控技術(shù)到達帶寬管理的有效性、確保并發(fā)任務(wù)的順利施行。采用單播、播送和組播可以減輕效勞器負擔，也能進步并發(fā)數(shù)。組播的多點投遞方式，使所有機器可以接收每個分組的同一拷貝減少了資源浪費。而常規(guī)的點對點通信方式下，N個視頻站點的視頻傳輸至少要重復(fù)發(fā)送N-1次一樣的數(shù)據(jù)包，發(fā)送時延大，而且隨著播放站點數(shù)量增長，時延就會迅速增長，這樣就不

10、能適應(yīng)要求短時延的多點視頻傳輸。1.3基于實時傳輸?shù)膮f(xié)議機制由于TP需要較多的開銷，它的重傳機制和擁塞控制機制ngestinntrlehanis不可防止地產(chǎn)生了傳輸延時和占用了較多的網(wǎng)絡(luò)帶寬，故不合適傳輸實時視頻音頻。在視音頻的流式傳輸實現(xiàn)方案中，一般采用HTTP/TP來傳輸控制信息，用RTP/UDP來傳輸實時聲音數(shù)據(jù)。實時傳輸協(xié)議RTPReal-tietransprtprtl4是用于internet上針對多媒體數(shù)據(jù)流的一種傳輸協(xié)議。RTP被定義為在一對一或一對多的傳輸情況下工作，其目的是提供時間信息和實現(xiàn)流同步。通常利用低層的UDP協(xié)議對實時視音頻數(shù)據(jù)進展組播ultiast或單播Uniast

11、,從而實現(xiàn)多點或單點視音頻數(shù)據(jù)的傳輸，當然RTP也可以在TP或AT等其他協(xié)議之上工作。RTP本身并不能為按順序傳送數(shù)據(jù)包提供可靠的傳送機制，也不提供流量控制或擁塞控制，而是依靠RTP提供這些效勞保證實時傳輸?shù)牟僮?。實時傳輸控制協(xié)議RTP(Real-tietransprtntrlprtl)和RTP一起提供流量控制和擁塞控制效勞。在RTP會話期間，各參與者周期性地傳送RTP包。RTP包中含有已發(fā)送的數(shù)據(jù)包的數(shù)量、喪失的數(shù)據(jù)包的數(shù)量等統(tǒng)計資料，因此，效勞器可以利用這些信息動態(tài)地改變傳輸速率，甚至改變有效載荷類型。RTP是RTP的控制協(xié)議，RTP和RTP配合使用能以有效的反應(yīng)和最小的開銷使傳輸效率最正

12、確化，因此特別合適傳送網(wǎng)上的實時數(shù)據(jù)。RTP單獨運行在底層協(xié)議上監(jiān)視效勞質(zhì)量并與會話者傳遞信息，RTP是由接收方向發(fā)送的報文，它負責監(jiān)視網(wǎng)絡(luò)的效勞質(zhì)量、通信帶寬以及網(wǎng)上傳送的信息，并將這些信息反應(yīng)給發(fā)送端，并提供QS的檢測，提供不同媒體間的同步信息和會話參與者的標識信息?；谑录幚淼亩嗑€程多緩沖區(qū)機制顯得更勝一籌。但是當在廣域網(wǎng)中進展視頻數(shù)據(jù)傳輸時，此時的傳輸性能極大地取決于可用的帶寬，由于TP是面向連接的傳輸層協(xié)議，它的重傳機制和擁塞控制機制，將使網(wǎng)絡(luò)狀況進一步惡化，從而帶來災(zāi)難性的延時。同時，在這種網(wǎng)絡(luò)環(huán)境下，通過TP傳輸?shù)囊曨l數(shù)據(jù)，在接收端重建、回放時，斷點非常明顯，表達為明顯的斷斷續(xù)

13、續(xù)，傳輸?shù)膶崟r性和傳輸質(zhì)量都無法保障。相對而言，采用RTP傳輸?shù)囊曨l數(shù)據(jù)的實時性和傳輸質(zhì)量就要好得多。2并發(fā)效勞的任務(wù)調(diào)度策略面對越來越宏大的流應(yīng)用需求，系統(tǒng)必須擁有良好的可伸縮性。隨著業(yè)務(wù)的增加和用戶的增多，系統(tǒng)需要靈敏地增加現(xiàn)場直播流的數(shù)量，并通過增加帶寬集群和接近最終用戶端的邊緣流媒體效勞器的數(shù)量，增加并發(fā)用戶的數(shù)量，不斷滿足用戶對系統(tǒng)的擴展要求。通常情況下一個視頻流的播放準備需要的準備時間是比擬長的。按照進程方式提供效勞的話，假如不斷接收到客戶的懇求，同時又不斷地創(chuàng)立子進程處理，必然會影響客戶的接收，其效勞器并發(fā)數(shù)也大打折扣。因此，采用“預(yù)創(chuàng)立prefrk技術(shù)可以緩解這種情況的產(chǎn)生。效

14、勞器事先創(chuàng)立一定數(shù)目的子進程，每個子進程分別承受連接隊列中已建立連接的客戶連接。這樣，就由子進程快速響應(yīng)并處理客戶懇求。并發(fā)與調(diào)度親密相關(guān)，如何分配任務(wù)給PU、如何調(diào)度任務(wù)直接影響到效率和可行性。效率較高的并發(fā)方法之一是“多線程，也就是“線程化。但線程化并不是唯一的并發(fā)構(gòu)造，它的實現(xiàn)依賴于資源的可用情況并有一定的局限性。文獻5中提到了多種可行的并發(fā)應(yīng)用模型，除線程化外，還有多處理、協(xié)同例程和基于事件的編程，以及連續(xù)ntinuatin、生成器和其它一些構(gòu)造。調(diào)度的任務(wù)就是合理劃分時間片和循環(huán)執(zhí)行各個線程，并能有效地監(jiān)測線程阻塞和消除。每個線程都占用一局部PU時間片，每個時間片上一個線程運行，另一

15、個時間片又可能是另外的線程在工作。根據(jù)視頻流的傳送要求，并發(fā)效勞的優(yōu)先級調(diào)度方式不合適專用于視頻效勞的工作，這會造成優(yōu)先級高的視頻流侵占低優(yōu)先級的視頻流效勞。因此，為了到達每個視頻流效勞的公平性，采用帶有可變加權(quán)的循環(huán)調(diào)度。其循環(huán)順序由申請效勞的先后次序決定，以效勞的時延最小進展調(diào)整控制，實現(xiàn)各個效勞的最小允許延遲保證優(yōu)質(zhì)效勞。3實現(xiàn)方案與測試驗證并發(fā)操作在同一時刻可以處理多個客戶懇求，從RTP/RTP協(xié)議使用的角度來說，其實現(xiàn)方法也有多種，如效勞器對每個接收到的客戶連接創(chuàng)立一個線程處理；或者預(yù)先創(chuàng)立多個線程，由這些線程處理懇求。當然，使用多處理硬件更能較好地實現(xiàn)多任務(wù)的并發(fā)操作，特別是對于L

16、inux使用多個處理器處理不同的線程時，并發(fā)效果要好的多。值得注意的是防止多個線程在單個處理器上造成瓶頸，而其它處理器卻處于空閑狀態(tài)，當然其它并發(fā)方法有時也會造成類似的問題。這方面有賴于操作系統(tǒng)的性能，對Linux2.4來說其缺省的“內(nèi)核線程可以很好地調(diào)度線程，并將這些線程分配給不同的PU。3.1實時傳輸?shù)男畔⒖刂凭€程建立通信連接關(guān)系后，根據(jù)RTP提供的時間信息實現(xiàn)流同步，通過RTP反應(yīng)的信息進展數(shù)據(jù)流控制并動態(tài)調(diào)整傳輸率，保證數(shù)據(jù)延遲符合預(yù)定要求。效勞器監(jiān)聽端口，根據(jù)實際客戶懇求量確定懇求隊列的允許最大連接數(shù)目。aept(客戶懇求)提取并分析懇求隊列中的某一任務(wù)；尋找具有一樣視頻信號標志的任

17、務(wù)，使用組播技術(shù)設(shè)置ip地址由子進程處理播放；否那么后置單位時間t。處理時間t的任務(wù)(Pr_lient()。hile(客戶機與效勞器成功連接成功返回通信文件描繪符)reateThread()/創(chuàng)立線程讀出當前時間，并將當前時間寫入通信文件描繪符；比擬RTP中資源信息與現(xiàn)有資源的差異，調(diào)整數(shù)據(jù)包發(fā)送大小和發(fā)送速度；假如子進程的數(shù)據(jù)傳送完，那么關(guān)閉通信文件描繪符；反之，繼續(xù)傳送。UDP層檢查其目的端口假如其UDP套接口已連接，也可能檢查源端口，將數(shù)據(jù)報放到相應(yīng)套接口的接收隊列。假如需要，就喚醒線程，由線程讀取這個新接收的數(shù)據(jù)報。3.2線程的調(diào)度控制線程間通過互斥鎖，實現(xiàn)循環(huán)控制，即在線程處理視頻數(shù)

18、據(jù)前通過互斥變量、信號燈加鎖，主要代碼如下：se_ait();pthread_utex_lk();thread_next_flag=true;/設(shè)置下一個可執(zhí)行線程標志pthread_utex_unlk();se_pst();為了實現(xiàn)有效的效勞，需要保證視頻數(shù)據(jù)流的傳輸具有相對的數(shù)據(jù)完好性。接收端常根據(jù)數(shù)據(jù)的到達情況通過RTP/RTP協(xié)議的信息反應(yīng)，為效勞器提供數(shù)據(jù)包接收情況的質(zhì)量統(tǒng)計反應(yīng)信息和QS檢測的資料；對于接收端而言，數(shù)據(jù)的存放需要占用一定數(shù)量的緩存，以承受網(wǎng)絡(luò)帶寬波動，并在傳輸中增加一定冗余信息來重建喪失或受損的數(shù)據(jù)，減少數(shù)據(jù)重傳。按照上述策略，在Linux9.0系統(tǒng)下編程實現(xiàn)了數(shù)據(jù)的傳輸，效勞器的配置賽揚為2.0GHz,網(wǎng)卡為10/100自適應(yīng)。接收端為賽揚1.0GHz，網(wǎng)卡同樣為10/100，通過交換機互聯(lián)。效勞器預(yù)創(chuàng)立5個傳輸效勞線程，圖中為兩個接收端的數(shù)據(jù)接收延遲情況，均傳送2000個數(shù)據(jù)包，從統(tǒng)計的結(jié)果圖來看，除了起始端出現(xiàn)較大的延遲外，延遲抖動均沒有過大的變化。但在沒有使用本文提出的調(diào)度控制的情況下，常常出現(xiàn)時延的急劇變化，即某一數(shù)據(jù)流出現(xiàn)了較大時延。因此，本文的并發(fā)傳輸調(diào)度到達了使用要求，效果比擬令人滿意。圖1多線程數(shù)據(jù)傳送調(diào)度控制測試結(jié)果4結(jié)論由于視