專利名稱：一種實現(xiàn)實時流媒體節(jié)目可靠傳輸?shù)姆椒?br> 技術(shù)領(lǐng)域：
本發(fā)明涉及一種實現(xiàn)流媒體節(jié)目傳輸?shù)姆椒?，尤其涉及一種實現(xiàn)實時流媒體節(jié)目可靠傳輸?shù)姆椒ā?br> 背景技術(shù)：
隨著寬頻時代的到來，與其密切相關(guān)的流媒體技術(shù)也成為人們談?wù)摰臒衢T話題，所述流媒體就是指通過網(wǎng)絡(luò)傳輸，能夠在本地終端實時回放并具有實時特征的媒體內(nèi)容編碼數(shù)據(jù)流。利用流媒體技術(shù)把實時節(jié)目(例如現(xiàn)場直播的新聞、體育節(jié)目)傳送到客戶端，由客戶通過電腦或附加有機頂盒的電視收看是流媒體的一種重要應(yīng)用。
目前，流媒體節(jié)目在服務(wù)器端和網(wǎng)絡(luò)上的傳輸方式主要有兩種單播和主播。單播傳輸時，需要在客戶端與服務(wù)器之間建立一個單獨的數(shù)據(jù)通道(見圖1)，對服務(wù)器和網(wǎng)絡(luò)資源的要求較高，所以在多個用戶同時收看同一實時節(jié)目的情況下，采用組播傳輸更加適宜。
組播傳輸時，作為發(fā)送者的組播源服務(wù)器與作為接收者的多臺客戶端設(shè)備之間建立起點對多點的網(wǎng)絡(luò)連接。組播傳輸方式不僅提高了數(shù)據(jù)傳送效率，同時也減少了骨干網(wǎng)絡(luò)出現(xiàn)擁塞的可能性。隨著組播傳輸方式的逐漸成熟，它已經(jīng)被廣泛的應(yīng)用在網(wǎng)絡(luò)音頻/視頻廣播、網(wǎng)絡(luò)視頻會議、遠程教育等各個領(lǐng)域。
雖然采用組播傳輸可以減輕服務(wù)器的負擔(dān)，而且也減少了骨干網(wǎng)的網(wǎng)絡(luò)流量，可是，組播的缺陷也是顯而易見的。因為組播使用的傳輸層協(xié)議-用戶數(shù)據(jù)報協(xié)議UDP-沒有錯誤重傳機制，當(dāng)出現(xiàn)丟失數(shù)據(jù)包的現(xiàn)象時，客戶端的播放質(zhì)量無法得到有效保證。
為了克服組播的上述缺點，又出現(xiàn)了一種“可靠組播”技術(shù)，并取得了一定的進展?，F(xiàn)有的這些“可靠組播”技術(shù)主要用于傳輸大容量的文件，而并不用于對實時性要求高的流媒體節(jié)目的傳輸。因此，如何利用組播實現(xiàn)實時流媒體節(jié)目的可靠傳輸就成為業(yè)內(nèi)一個新的研究課題。

發(fā)明內(nèi)容
本發(fā)明所要解決的技術(shù)問題就是提供一種實現(xiàn)實時流媒體節(jié)目可靠傳輸?shù)姆椒?，在不增加或盡量少增加服務(wù)器負載和減少骨干網(wǎng)網(wǎng)絡(luò)流量的前提下，利用分布式系統(tǒng)對丟失的組播數(shù)據(jù)包進行重新發(fā)送的方法來保證流媒體的傳輸質(zhì)量，一方面實現(xiàn)了流媒體實時節(jié)目的分發(fā)，另一方面又較好的解決了組播傳輸?shù)姆?wù)質(zhì)量得不到保證的問題。
針對上述技術(shù)問題，本發(fā)明提供一種實現(xiàn)實時流媒體節(jié)目可靠傳輸?shù)姆椒ǎㄈ缦虏襟E(1)用戶通過客戶端瀏覽系統(tǒng)的內(nèi)容發(fā)布服務(wù)頁面，查找到所需觀看的節(jié)目，點擊該節(jié)目鏈接；(2)內(nèi)容發(fā)布服務(wù)器把用戶請求發(fā)送給內(nèi)容資源管理服務(wù)器，內(nèi)容資源管理服務(wù)器把該客戶端記錄在該節(jié)目所對應(yīng)的內(nèi)容節(jié)點資源列表中，同時根據(jù)調(diào)度策略為該客戶端建立用于組播重傳的組播群，及決定其應(yīng)加入哪一個組播服務(wù)器，并把該節(jié)目的組播服務(wù)器地址返回給客戶端；(3)客戶端通過互聯(lián)網(wǎng)組管理協(xié)議請求加入組播組，并在和組播群內(nèi)其他客戶端建立連接后，對從組播組接收到的用戶數(shù)據(jù)報協(xié)議UDP數(shù)據(jù)包進行緩存處理，用于播放；(4)客戶端在緩存區(qū)中檢查節(jié)目數(shù)據(jù)包的序號，如果發(fā)現(xiàn)缺少某個數(shù)據(jù)包，且等待一定時間后仍然沒有收到該數(shù)據(jù)包，啟動組播重傳機制，請求組播服務(wù)器重傳該數(shù)據(jù)包；如果接收到組播服務(wù)器重新發(fā)送的數(shù)據(jù)包，該客戶端就將接收到的數(shù)據(jù)包進行緩存處理，用于播放；如果在設(shè)定時間內(nèi)沒有接收到數(shù)據(jù)包，執(zhí)行后續(xù)操作；(5)如果該客戶端認為前述步驟中建立的組播群已經(jīng)失效，就向內(nèi)容資源管理服務(wù)器發(fā)送建立新組播群的請求，并在接收到返回信息后，重新啟動組播重傳機制，和新的組播服務(wù)器建立連接并發(fā)送重傳請求，直至其緩存區(qū)中數(shù)據(jù)包齊全后，用于播放；(6)該客戶端對接收到的完整數(shù)據(jù)包信息進行播放；(7)播放結(jié)束后，該客戶端離開組播組，內(nèi)容資源管理服務(wù)器在相應(yīng)的內(nèi)容節(jié)點資源列表中刪去該客戶端，整個流程結(jié)束。
本發(fā)明是一種實現(xiàn)實時流媒體節(jié)目可靠傳輸?shù)姆椒?，?yīng)用本發(fā)明所述方法，可以有效解決和克服組播傳輸使用的傳輸層協(xié)議-用戶數(shù)據(jù)報協(xié)議UDP-沒有錯誤的重傳機制，而無法實現(xiàn)數(shù)據(jù)包丟失重傳的缺點，提高了組播傳輸?shù)目煽啃院头?wù)質(zhì)量，使得客戶端流媒體節(jié)目的播放質(zhì)量能夠得到有效的保證。


圖1是現(xiàn)有流媒體服務(wù)系統(tǒng)的結(jié)構(gòu)組成示意圖；圖2是根據(jù)本發(fā)明實施例所述的分布式流媒體服務(wù)系統(tǒng)結(jié)構(gòu)組成示意圖；圖3是根據(jù)本發(fā)明實施例所述的分布式流媒體服務(wù)系統(tǒng)中實現(xiàn)可靠傳輸?shù)姆椒鞒虉D；圖4是根據(jù)本發(fā)明實施例所述的分布式流媒體服務(wù)系統(tǒng)中客戶端所處組播群的交叉式分布示意圖；圖5是根據(jù)本發(fā)明實施例所述的分布式流媒體服務(wù)系統(tǒng)中的客戶端中兩個緩存裝置結(jié)構(gòu)及其工作狀態(tài)之間關(guān)系的示意圖。
具體實施例方式
下面結(jié)合附圖對本發(fā)明作進一步的詳細描述參見圖2，為本發(fā)明實施例所述的分布式流媒體服務(wù)系統(tǒng)結(jié)構(gòu)組成示意圖。該系統(tǒng)的最大特點是把客戶端納入到為用戶提供服務(wù)的體系中，從而改變了現(xiàn)有的C/S結(jié)構(gòu)模式的流媒體服務(wù)系統(tǒng)結(jié)構(gòu)。該系統(tǒng)可以包括三個模塊由內(nèi)容發(fā)布服務(wù)器與內(nèi)容資源管理服務(wù)器構(gòu)成的內(nèi)容控制模塊，用于實現(xiàn)客戶端和流媒體內(nèi)容的管理調(diào)度；由寬帶網(wǎng)絡(luò)構(gòu)成的網(wǎng)絡(luò)傳輸模塊，負責(zé)實現(xiàn)系統(tǒng)中各個服務(wù)器和客戶端之間的控制信息和內(nèi)容服務(wù)信息的傳遞；由多個客戶端建立的組播群和組播服務(wù)器構(gòu)成的內(nèi)容服務(wù)模塊，負責(zé)提供流媒體內(nèi)容的存儲和服務(wù)，并實現(xiàn)最終的流媒體服務(wù)。
圖3為本發(fā)明實施例所述的分布式流媒體服務(wù)系統(tǒng)中實現(xiàn)可靠傳輸?shù)姆椒鞒虉D，具體過程如下步驟301用戶通過客戶端瀏覽系統(tǒng)的內(nèi)容發(fā)布服務(wù)頁面，查找到所需觀看的節(jié)目，點擊該節(jié)目鏈接。
步驟302內(nèi)容發(fā)布服務(wù)器把用戶請求發(fā)送給內(nèi)容資源管理服務(wù)器，內(nèi)容資源管理服務(wù)器把該客戶端記錄在該節(jié)目所對應(yīng)的內(nèi)容節(jié)點資源列表中，同時根據(jù)調(diào)度策略為該客戶端建立用于組播重傳的組播群，及決定其應(yīng)加入哪一個組播服務(wù)器，并把該節(jié)目的組播服務(wù)器地址返回給客戶端。
所述組播群是彼此建立連接關(guān)系的一組客戶端，組播群的所有客戶端都能接收到組播服務(wù)器發(fā)送的數(shù)據(jù)包，當(dāng)然，也只有加入該組播群的客戶端才能接收到發(fā)送給該組播群的數(shù)據(jù)包。建立群的目的就是為了實現(xiàn)組播重傳當(dāng)群中的一個客戶端丟失某個數(shù)據(jù)包時，它將向組播服務(wù)器發(fā)送重傳請求，組播服務(wù)器則為此客戶端提供相應(yīng)的數(shù)據(jù)包。組播群的建立由資源管理服務(wù)器統(tǒng)一調(diào)度，其調(diào)度策略包含地域優(yōu)先和穩(wěn)定性優(yōu)先等原則，考慮到組播丟包的原因可能是數(shù)據(jù)網(wǎng)的某個設(shè)備或節(jié)點出現(xiàn)問題，因此群內(nèi)的客戶端分布地點應(yīng)跨越城域網(wǎng)，避免因為城域內(nèi)某個設(shè)備或節(jié)點出現(xiàn)故障而影響用戶使用組播重傳。另外，群的調(diào)度策略還包括采用交叉分布方式，即每個客戶端應(yīng)屬于兩個或兩個以上的群，以保證實現(xiàn)可靠傳輸。參見圖4，為本發(fā)明實施例所述的分布式流媒體服務(wù)系統(tǒng)中客戶端所處組播群的交叉式分布示意圖，圖中的客戶端A、B同時屬于組播群1和組播群2。
步驟303客戶端通過互聯(lián)網(wǎng)組管理協(xié)議請求加入組播組，并在和組播群內(nèi)其他客戶端建立連接后，對從組播組接收到的用戶數(shù)據(jù)報協(xié)議UDP數(shù)據(jù)包進行緩存處理，準(zhǔn)備播放。
本實施例系統(tǒng)中的客戶端都有兩個緩存區(qū)，接收數(shù)據(jù)包并進行排序的接收緩存區(qū)，以及將接收緩存區(qū)中已經(jīng)排序好的數(shù)據(jù)包復(fù)制過來并進行解包合成節(jié)目內(nèi)容的播放緩存區(qū)。其中接收緩存區(qū)的存儲空間要大于播放緩存區(qū)，該接收緩存區(qū)中存儲的數(shù)據(jù)包有兩種等待進入播放緩存區(qū)的數(shù)據(jù)包，以及在播放緩存區(qū)中已經(jīng)播放過而要被刪除的數(shù)據(jù)包。這是考慮在分布式系統(tǒng)中，各個客戶端的時延不同，可能有別的用戶需要重傳該部分數(shù)據(jù)。參見圖5，為本發(fā)明實施例所述的分布式流媒體服務(wù)系統(tǒng)中的客戶端中兩個緩存裝置結(jié)構(gòu)及其工作狀態(tài)之間關(guān)系的示意圖，此圖展示了該兩個緩存裝置的結(jié)構(gòu)及其工作狀態(tài)之間的關(guān)系。上述步驟中的緩存處理具體操作是對接收到的數(shù)據(jù)包先不拆分，保留該數(shù)據(jù)包的序號，直接緩存在接收緩存區(qū)中，并將數(shù)據(jù)包按照序號順序排列，以便在設(shè)定的緩存時間內(nèi)將序號齊全的數(shù)據(jù)包復(fù)制到播放緩存區(qū)，解包合成圖像和播放。數(shù)據(jù)包在接收緩存區(qū)和播放緩存區(qū)中的緩存時間均取決于網(wǎng)絡(luò)狀況和群內(nèi)各個客戶端的分布狀況，例如接收緩存區(qū)緩存時間在4～12秒之間，播放緩存區(qū)的緩存時間在1～5秒之間。
步驟304客戶端在緩存區(qū)中檢查節(jié)目數(shù)據(jù)包的序號，可以知道是否缺失數(shù)據(jù)包，如果發(fā)現(xiàn)缺少某個數(shù)據(jù)包，且等待一定時間后仍然沒有收到該數(shù)據(jù)包，啟動組播重傳機制，請求組播服務(wù)器重傳該數(shù)據(jù)包；如果接收到組播服務(wù)器重新發(fā)送的數(shù)據(jù)包，該客戶端就將接收到的數(shù)據(jù)包進行緩存處理，用于播放；如果在設(shè)定時間內(nèi)沒有接收到數(shù)據(jù)包，執(zhí)行后續(xù)步驟；步驟305如果該客戶端認為前述步驟中建立的組播群已經(jīng)失效，就向內(nèi)容資源管理服務(wù)器發(fā)送建立新組播群的請求，并在接收到返回信息后，重新啟動組播重傳機制，和新的組播服務(wù)器建立連接并發(fā)送重傳請求，直至其緩存區(qū)中數(shù)據(jù)包齊全后，用于播放；步驟306該客戶端對接收到的完整數(shù)據(jù)包信息進行播放；步驟307播放結(jié)束后，該客戶端離開組播組，內(nèi)容資源管理服務(wù)器在相應(yīng)的內(nèi)容節(jié)點資源列表中刪去該客戶端，結(jié)束整個流程。
本實施例所述的在分布式流媒體服務(wù)系統(tǒng)中，通過對丟失數(shù)據(jù)包的組播重傳機制保證了流媒體節(jié)目的播放質(zhì)量。該重傳機制的具體過程如下(A)該客戶端向組播服務(wù)器發(fā)送請求包，請求組播服務(wù)器為其發(fā)送該丟失的數(shù)據(jù)包，請求包中至少包括該丟失數(shù)據(jù)包的序號；(B)組播服務(wù)器接收到請求包后，把包括該丟失數(shù)據(jù)包包頭的整個UDP數(shù)據(jù)包作為重傳數(shù)據(jù)包的凈荷進行傳送；(C)請求重傳的客戶端將接收到的重傳數(shù)據(jù)包放入接收緩存區(qū)的相應(yīng)隊列中，而沒有請求重傳的其他客戶端將收到的重傳數(shù)據(jù)包作丟棄處理。
權(quán)利要求
1.一種實現(xiàn)實時流媒體節(jié)目可靠傳輸?shù)姆椒?，其特征在于，包括以下步驟(1)用戶通過客戶端瀏覽系統(tǒng)的內(nèi)容發(fā)布服務(wù)頁面，查找到所需觀看的節(jié)目，點擊該節(jié)目鏈接；(2)內(nèi)容發(fā)布服務(wù)器把用戶請求發(fā)送給內(nèi)容資源管理服務(wù)器，內(nèi)容資源管理服務(wù)器把該客戶端記錄在該節(jié)目所對應(yīng)的內(nèi)容節(jié)點資源列表中，同時根據(jù)調(diào)度策略為該客戶端建立用于組播重傳的組播群，及決定其應(yīng)加入哪一個組播服務(wù)器，并把該節(jié)目的組播服務(wù)器地址返回給客戶端；(3)客戶端通過互聯(lián)網(wǎng)組管理協(xié)議請求加入組播組，并在和組播群內(nèi)其他客戶端建立連接后，對從組播組接收到的用戶數(shù)據(jù)報協(xié)議UDP數(shù)據(jù)包進行緩存處理，用于播放；(4)客戶端在緩存區(qū)中檢查節(jié)目數(shù)據(jù)包的序號，如果發(fā)現(xiàn)缺少某個數(shù)據(jù)包，且等待一定時間后仍然沒有收到該數(shù)據(jù)包，啟動組播重傳機制，請求組播服務(wù)器重傳該數(shù)據(jù)包；如果接收到組播服務(wù)器重新發(fā)送的數(shù)據(jù)包，該客戶端就將接收到的數(shù)據(jù)包進行緩存處理，用于播放；如果在設(shè)定時間內(nèi)沒有接收到數(shù)據(jù)包，執(zhí)行后續(xù)操作；(5)如果該客戶端認為前述步驟中建立的組播群已經(jīng)失效，就向內(nèi)容資源管理服務(wù)器發(fā)送建立新組播群的請求，并在接收到返回信息后，重新啟動組播重傳機制，和新的組播服務(wù)器建立連接并發(fā)送重傳請求，直至其緩存區(qū)中數(shù)據(jù)包齊全后，用于播放；(6)該客戶端對接收到的完整數(shù)據(jù)包信息進行播放；(7)播放結(jié)束后，該客戶端離開組播組，內(nèi)容資源管理服務(wù)器在相應(yīng)的內(nèi)容節(jié)點資源列表中刪去該客戶端，整個流程結(jié)束。
2.如權(quán)利要求1所述的方法，其特征在于，所述步驟(2)中組播群的建立由內(nèi)容資源管理服務(wù)器統(tǒng)一調(diào)度，其調(diào)度策略包括地域和穩(wěn)定性的優(yōu)先，以及群內(nèi)客戶端的分布應(yīng)跨越城域網(wǎng)。
3.如權(quán)利要求2所述的方法，其特征在于，所述組播群的調(diào)度策略進一步包括，客戶端的分布采用交叉分布方式。
4.如權(quán)利要求1所述的方法，其特征在于，所述步驟(3)或(4)中客戶端對接收到的數(shù)據(jù)包進行的緩存處理進一步包括對接收到的數(shù)據(jù)包進行序號保留后，直接緩存在接收緩存區(qū)中，并將數(shù)據(jù)包按照序號順序排列，以便在設(shè)定的緩存時間內(nèi)將序號齊全的數(shù)據(jù)包復(fù)制到播放緩存區(qū)，緩存后，解包合成圖像并播放。
5.如權(quán)利要求4所述的方法，其特征在于，所述數(shù)據(jù)包在接收緩存區(qū)和播放緩存區(qū)中的緩存時間取決于網(wǎng)絡(luò)狀況和群內(nèi)各個客戶端的分布狀況。
6.如權(quán)利要求4或5所述的方法，其特征在于，所述接收緩存區(qū)的存儲空間大于播放緩存區(qū)，該接收緩存區(qū)中存儲的數(shù)據(jù)包有兩種等待進入播放緩存區(qū)的數(shù)據(jù)包，以及在播放緩存區(qū)中已經(jīng)播放過而要被刪除的數(shù)據(jù)包。
7.如權(quán)利要求1所述的方法，其特征在于，所述步驟(4)或(5)中啟動的組播重傳機制進一步包括下列步驟(A)該客戶端向組播服務(wù)器發(fā)送請求包，請求組播服務(wù)器為其發(fā)送該丟失的數(shù)據(jù)包，請求包中至少包括該丟失數(shù)據(jù)包的序號；(B)組播服務(wù)器接收到請求包后，把包括該丟失數(shù)據(jù)包包頭的整個UDP數(shù)據(jù)包作為重傳數(shù)據(jù)包的凈荷進行傳送；(C)請求重傳的客戶端將接收到的重傳數(shù)據(jù)包放入接收緩存區(qū)的相應(yīng)隊列中，而沒有請求重傳的其他客戶端將收到的重傳數(shù)據(jù)包作丟棄處理。
全文摘要
一種實現(xiàn)實時流媒體節(jié)目可靠傳輸?shù)姆椒?，在用戶點擊節(jié)目鏈接后，內(nèi)容資源管理服務(wù)器把客戶端記錄在該節(jié)目所對應(yīng)的內(nèi)容節(jié)點資源列表中，并為該客戶端建立用于組播重傳的組播群，及決定其應(yīng)加入哪一個組播服務(wù)器；客戶端加入組播組并和組內(nèi)其他客戶端建立連接后，對接收到的數(shù)據(jù)包進行緩存處理檢查節(jié)目數(shù)據(jù)包的序號，如果發(fā)現(xiàn)缺少某個數(shù)據(jù)包，且等待一定時間仍然沒有收到，就啟動組播重傳機制，請求組播服務(wù)器重傳該數(shù)據(jù)包，如果在設(shè)定時間內(nèi)一直沒有接收到該數(shù)據(jù)包，則向內(nèi)容資源管理服務(wù)器請求建立新群，并重新啟動組播重傳機制，直至數(shù)據(jù)包齊全后，用于播放。應(yīng)用本發(fā)明所述方法，實現(xiàn)了利用重傳機制保證流媒體節(jié)目的服務(wù)質(zhì)量。
文檔編號H04L29/06GK101075948SQ20061008054
公開日2007年11月21日 申請日期2006年5月15日 優(yōu)先權(quán)日2006年5月15日
發(fā)明者沈燦 申請人:中興通訊股份有限公司