一種基于節(jié)點(diǎn)帶寬的自適應(yīng)數(shù)據(jù)調(diào)度策略在PPVoD系統(tǒng)中的應(yīng)用研究

黃志艷

(泰山職業(yè)技術(shù)學(xué)院，山東泰安 271000)

隨著互聯(lián)網(wǎng)寬帶的普及和發(fā)展，網(wǎng)絡(luò)音頻和視頻已經(jīng)成為網(wǎng)絡(luò)多媒體主流應(yīng)用，流媒體的誕生，更是促進(jìn)了這些應(yīng)用的規(guī)?；仙?。流媒體是一種包含數(shù)據(jù)采集、壓縮、存儲(chǔ)和傳輸?shù)榷囗?xiàng)技術(shù)的一種網(wǎng)絡(luò)應(yīng)用工具。在傳統(tǒng)應(yīng)用過程中，流媒體通常采用的系統(tǒng)架構(gòu)是C/S模式，隨著網(wǎng)絡(luò)用戶的快速增加，該模式易受到服務(wù)器帶寬、并發(fā)進(jìn)程等服務(wù)能力的約束，成為流媒體發(fā)展的瓶頸。為了解決該問題，在許多計(jì)算機(jī)學(xué)者的努力下，引入了P2P技術(shù)，該技術(shù)的目的是使網(wǎng)絡(luò)中的用戶分享?yè)碛械馁Y源，以無中介、對(duì)等的傳輸方式進(jìn)行資源交換。

在國(guó)外，基于P2P技術(shù)的流媒體發(fā)展迅速，得到十分廣泛的應(yīng)用，其在世界著名的各大高校，比如斯坦福大學(xué)［1］、中弗羅里達(dá)大學(xué)［2］、馬里蘭大學(xué)［3］、香港大學(xué)［4］等擁有 P2P 技術(shù)研究機(jī)構(gòu)，微軟研究院［5］專門成立了的P2P技術(shù)研究組，經(jīng)過諸多學(xué)者的努力，P2P技術(shù)研究成果顯著，已經(jīng)涌現(xiàn)了SkyPe［6］、Split-stream和PeerCast［7］等諸多經(jīng)典的系統(tǒng)。在國(guó)內(nèi)，基于P2P的流媒體技術(shù)也在高速發(fā)展著，已經(jīng)誕生了PPLive［8］、AnySee［9］，PPStream、QQLive［10］等流媒體點(diǎn)播平臺(tái)，截至 2012 年6 月，我國(guó) P2P 市場(chǎng)經(jīng)濟(jì)產(chǎn)值已經(jīng)高達(dá)6.83億元，隨著P2P技術(shù)的改進(jìn)和發(fā)展，基于該技術(shù)的流媒體應(yīng)用前景廣闊。

1 PPVoD系統(tǒng)中數(shù)據(jù)傳輸模式

在采用P2P技術(shù)的流媒體系統(tǒng)中，數(shù)據(jù)傳輸模式主要有三種:推模式、拉模式以及推拉結(jié)合的模式。

1.1 推模式

推模式(Push)是指數(shù)據(jù)的擁有者按照既定路徑把自身?yè)碛械臄?shù)據(jù)向外發(fā)布。推模式的實(shí)現(xiàn)方式主要是組播樹，其要求節(jié)點(diǎn)之間必須存在父子關(guān)系。該模式的基本思想是主動(dòng)將數(shù)據(jù)文件“推”給需要數(shù)據(jù)的節(jié)點(diǎn)，其實(shí)質(zhì)是假設(shè)代理節(jié)點(diǎn)具有很大的存儲(chǔ)功能和長(zhǎng)時(shí)間在線，以便將服務(wù)器的功能轉(zhuǎn)嫁于代理節(jié)點(diǎn)，其缺陷是一般與系統(tǒng)的動(dòng)態(tài)性和已勾選互相矛盾，很難實(shí)現(xiàn)。

1.2 拉模式

拉模式(Pull)是通過接收節(jié)點(diǎn)的主動(dòng)請(qǐng)求以獲得數(shù)據(jù)，是指接收節(jié)點(diǎn)的驅(qū)動(dòng)模式［11］。在基于P2P技術(shù)的Cool Streaming直播系統(tǒng)中，基于數(shù)據(jù)驅(qū)動(dòng)的方式，在覆蓋網(wǎng)中采用了拉模式獲取節(jié)點(diǎn)所缺少的數(shù)據(jù)片段，交換BM信息是每隔一定周期進(jìn)行一次，這樣以便確認(rèn)數(shù)據(jù)是否可以使用。該策略在系統(tǒng)運(yùn)行過程中會(huì)產(chǎn)生一定的延遲，并且這些延遲將會(huì)隨著節(jié)點(diǎn)的增多不斷地?cái)U(kuò)散，因此，基于拉模式的數(shù)據(jù)傳輸系統(tǒng)會(huì)降低系統(tǒng)的實(shí)時(shí)性。

1.3 推拉結(jié)合模式

由于單純的推模式和拉模式具有不可抗拒的缺點(diǎn)，為了彌補(bǔ)他們的缺點(diǎn)，人們將推拉(Push-Pull)傳輸模式的優(yōu)點(diǎn)進(jìn)行結(jié)合，產(chǎn)生了推拉結(jié)合模式。在使用該模式的流媒體系統(tǒng)中，時(shí)間被分成連續(xù)的時(shí)間片，根據(jù)每個(gè)時(shí)間片的相關(guān)情況，數(shù)據(jù)傳輸模式采取推模式或拉模式。當(dāng)系統(tǒng)進(jìn)入穩(wěn)定播放階段時(shí)，對(duì)上個(gè)時(shí)間片內(nèi)服務(wù)節(jié)點(diǎn)的性能進(jìn)行評(píng)估，依據(jù)評(píng)估結(jié)果向每個(gè)服務(wù)節(jié)點(diǎn)制定自身所需數(shù)據(jù)，之后，采用推模式進(jìn)行數(shù)據(jù)傳輸。但是，在推拉結(jié)合的模式中，由于推拉數(shù)據(jù)的閥值不夠明顯，推的數(shù)據(jù)可能會(huì)被重復(fù)下載，導(dǎo)致數(shù)據(jù)冗余和帶寬資源的浪費(fèi)。

2 PPVoD系統(tǒng)中數(shù)據(jù)調(diào)度策略

基于P2P技術(shù)的流媒體系統(tǒng)建立在Gossip協(xié)議基礎(chǔ)上，系統(tǒng)中的所有的合作節(jié)點(diǎn)能夠自動(dòng)有機(jī)構(gòu)成一張網(wǎng)狀拓?fù)浣Y(jié)構(gòu)，因此，某個(gè)應(yīng)用節(jié)點(diǎn)可以從多個(gè)合作節(jié)點(diǎn)中獲得所需數(shù)據(jù)，同時(shí)，該節(jié)點(diǎn)也必須分享其擁有的數(shù)據(jù)，因此，基于P2P技術(shù)的流媒體系統(tǒng)的性能和服務(wù)質(zhì)量受流媒體數(shù)據(jù)調(diào)度的效率的直接影響。在P2P流媒體系統(tǒng)中，數(shù)據(jù)調(diào)度策略主要有三種，分別是最少優(yōu)先策略、隨機(jī)調(diào)度策略、最急優(yōu)先策略［12］。

隨機(jī)調(diào)度策略是三種策略中較為簡(jiǎn)單的，該算法在眾多的服務(wù)節(jié)點(diǎn)中隨機(jī)選擇一個(gè)擁有所需數(shù)據(jù)片段的節(jié)點(diǎn)作為服務(wù)節(jié)點(diǎn)，向其發(fā)送數(shù)據(jù)請(qǐng)求，獲得所需數(shù)據(jù)。該算法具有復(fù)雜度較低，便于維護(hù)節(jié)點(diǎn)之間的負(fù)載均衡的特點(diǎn)，但是，該算法由于過于簡(jiǎn)單，其忽略了系統(tǒng)間存在的異構(gòu)性、節(jié)點(diǎn)的帶寬、服務(wù)質(zhì)量等特性，因此，其效率低下。

最少優(yōu)先策略是一種使用較為廣泛的調(diào)度策略，它是以數(shù)據(jù)片段冗余度優(yōu)先的策略。最少優(yōu)先策略的基本思想是記錄擁有該節(jié)點(diǎn)缺少數(shù)據(jù)片段的節(jié)點(diǎn)數(shù)量，節(jié)點(diǎn)數(shù)目用冗余度表示，冗余度比較小的節(jié)點(diǎn)在請(qǐng)求數(shù)據(jù)時(shí)優(yōu)先被選擇，冗余度較大的節(jié)點(diǎn)實(shí)施在請(qǐng)求數(shù)據(jù)時(shí)，可以實(shí)行任務(wù)分配，優(yōu)先選擇節(jié)點(diǎn)帶寬較高的服務(wù)節(jié)點(diǎn)相應(yīng)節(jié)點(diǎn)請(qǐng)求，因此，該節(jié)點(diǎn)能夠動(dòng)態(tài)的實(shí)現(xiàn)良好的負(fù)載均衡，提高了帶寬利用率。但是，由于即將播放的數(shù)據(jù)不能及時(shí)獲得系統(tǒng)剛剛發(fā)布的冗余度較小的數(shù)據(jù)，忽略了直播系統(tǒng)的實(shí)時(shí)性需求，不適于對(duì)延遲要求較高的系統(tǒng)。

最急優(yōu)先策略又被稱為貪婪策略，基于該策略的系統(tǒng)中，缺少數(shù)據(jù)片段的節(jié)點(diǎn)優(yōu)先選擇距離其最近的服務(wù)節(jié)點(diǎn)下載數(shù)據(jù)，這樣就可以充分的播放節(jié)點(diǎn)的實(shí)時(shí)性需求，優(yōu)先選擇緊迫性較高的數(shù)據(jù)片段，提高了播放的連續(xù)性，有效彌補(bǔ)了最少優(yōu)先策略的缺點(diǎn)。但是該策略忽視了整個(gè)系統(tǒng)，只考慮了單個(gè)節(jié)點(diǎn)，雖然看似對(duì)每個(gè)節(jié)點(diǎn)都有利，實(shí)際上降低了數(shù)據(jù)塊的共享幾率，不能有效調(diào)動(dòng)每個(gè)伙伴節(jié)點(diǎn)的數(shù)據(jù)傳輸能力，從而造成系統(tǒng)整體性能的下降。

3 基于節(jié)點(diǎn)帶寬的自適應(yīng)數(shù)據(jù)調(diào)度策略

3.1 數(shù)據(jù)緩沖區(qū)

在P2P系統(tǒng)中，數(shù)據(jù)調(diào)度是一個(gè)NP-Hard問題，因此，尋找一個(gè)次優(yōu)的調(diào)度方案，成為人們研究的熱點(diǎn)。本文在保證服務(wù)質(zhì)量的條件下，采用自適應(yīng)多級(jí)反饋隊(duì)列，推拉結(jié)合，高效利用節(jié)點(diǎn)帶寬，緩解媒體服務(wù)器的負(fù)載，基于功能劃分，數(shù)據(jù)緩沖區(qū)分為Extra Buffer、Pushing Buffer和Pulling Buffer三個(gè)部分，如圖1所示。

圖1 數(shù)據(jù)緩沖區(qū)結(jié)構(gòu)Fig.1 Data buffer structure

已播緩沖區(qū)(Extra Buffer):該緩沖區(qū)存放播放點(diǎn)之前的數(shù)據(jù)，其基本的功能是杜絕產(chǎn)生無效的數(shù)據(jù)請(qǐng)求，以便能夠?yàn)楹献鞴?jié)點(diǎn)提供高效的服務(wù)，該緩沖區(qū)的大小主要取決于數(shù)據(jù)傳輸時(shí)延和節(jié)點(diǎn)間數(shù)據(jù)調(diào)度的周期。

拉緩沖區(qū)(Pulling Buffer):該緩沖區(qū)存放彈性時(shí)間較短的數(shù)據(jù)。為了保證視頻播放的流暢度，該部分所缺少的數(shù)據(jù)片段具有較高的優(yōu)先級(jí)，系統(tǒng)采用拉模式從合作節(jié)點(diǎn)處獲得。該緩沖區(qū)的大小主要取決于拉模式造成的數(shù)據(jù)時(shí)延。

推緩沖區(qū)(Pushing Buffer):該緩沖區(qū)存放緩沖時(shí)間較長(zhǎng)的數(shù)據(jù)。其既可以采用拉模式獲得數(shù)據(jù)片段，也可以采用推模式獲得數(shù)據(jù)片段，其大小主要取決于該緩沖區(qū)需要滿足的服務(wù)能力，同時(shí)還取決于直播中節(jié)點(diǎn)和數(shù)據(jù)源的播放點(diǎn)之間的差值。

推拉兩緩沖區(qū)的大小與系統(tǒng)性能密切相關(guān)，影響節(jié)點(diǎn)的帶寬利用率、傳輸延遲和播放流暢度，因此，本文基于P2P自身的動(dòng)態(tài)性特征進(jìn)行適應(yīng)性調(diào)整，能夠獲得較好的系統(tǒng)性能。

3.2 服務(wù)節(jié)點(diǎn)集、鄰居節(jié)點(diǎn)集和備用節(jié)點(diǎn)集

備用節(jié)點(diǎn)集、鄰居節(jié)點(diǎn)集和服務(wù)節(jié)點(diǎn)集在基于P2P技術(shù)的流媒體系統(tǒng)中需要覆蓋網(wǎng)進(jìn)行維護(hù)的三個(gè)節(jié)點(diǎn)集合。(1)備用節(jié)點(diǎn)集是指選擇部分節(jié)點(diǎn)放在一起，其可能轉(zhuǎn)化為鄰居節(jié)點(diǎn);(2)鄰居節(jié)點(diǎn)集是指在系統(tǒng)運(yùn)行過程中，與本節(jié)點(diǎn)播放統(tǒng)一頻道的其他正在播放的節(jié)點(diǎn)的集合，鄰居節(jié)點(diǎn)在運(yùn)行過程中可能轉(zhuǎn)化為合作節(jié)點(diǎn);(3)服務(wù)節(jié)點(diǎn)集指為缺少數(shù)據(jù)片段的節(jié)點(diǎn)提供視頻服務(wù)的節(jié)點(diǎn)的集合。

圖2 節(jié)點(diǎn)集角色轉(zhuǎn)換流程Fig.2 Node set role conversion process

基于P2P技術(shù)的流媒體系統(tǒng)在運(yùn)行過程中根據(jù)數(shù)據(jù)片段的需要可以動(dòng)態(tài)調(diào)整鄰居節(jié)點(diǎn)、服務(wù)節(jié)點(diǎn)和備用節(jié)點(diǎn)之間轉(zhuǎn)換，如圖2所示，轉(zhuǎn)換過程分為四個(gè)步驟:(1)系統(tǒng)初始時(shí)，一個(gè)節(jié)點(diǎn)P加入系統(tǒng)后，此時(shí)該節(jié)點(diǎn)無法獲得備用節(jié)點(diǎn)的緩沖區(qū)狀態(tài)，因此可以通過覆蓋網(wǎng)中包含的節(jié)點(diǎn)信息，收集到近鄰節(jié)點(diǎn)并將其存放到備用節(jié)點(diǎn)列表中;(2)節(jié)點(diǎn)P可以向備用節(jié)點(diǎn)請(qǐng)求其擁有的緩沖區(qū)狀態(tài)，并且節(jié)點(diǎn)P和備用節(jié)點(diǎn)之間存在同時(shí)播放同一頻道，緩沖區(qū)重合的現(xiàn)象，那么，節(jié)點(diǎn)P可以將該類備用節(jié)點(diǎn)轉(zhuǎn)換為鄰居節(jié)點(diǎn)并將其降入鄰居節(jié)點(diǎn)集中;(3)節(jié)點(diǎn)P會(huì)與鄰居節(jié)點(diǎn)按照設(shè)定周期交換各自的緩沖區(qū)狀態(tài)，以便高效的進(jìn)行數(shù)據(jù)調(diào)度;(4)當(dāng)節(jié)點(diǎn)P的鄰居節(jié)點(diǎn)由于服務(wù)能力過載，無法為節(jié)點(diǎn)P提供服務(wù)時(shí)，其將會(huì)被重新納入備用節(jié)點(diǎn)集中。

3.3 多層反饋隊(duì)列

在本文提出的數(shù)據(jù)調(diào)度策略中，引入了多層反饋隊(duì)列機(jī)制，該機(jī)制可以根據(jù)數(shù)據(jù)片段彈性時(shí)間的大小，設(shè)置反饋隊(duì)列的層次級(jí)別，進(jìn)而估測(cè)合作節(jié)點(diǎn)服務(wù)能力，高效率的進(jìn)行數(shù)據(jù)調(diào)度。根據(jù)合作節(jié)點(diǎn)反饋的數(shù)據(jù)片段的信息，動(dòng)態(tài)更新反饋隊(duì)列，本文的多層反饋隊(duì)列如圖3所示。

圖3 多層反饋隊(duì)列Fig.3 Multi-layer feedback queue

推隊(duì)列(Pushing Queue):該隊(duì)列存放的數(shù)據(jù)片段是推緩沖區(qū)中所缺少的數(shù)據(jù)片段，如果這些數(shù)據(jù)片段存放于其合作節(jié)點(diǎn)的緩沖區(qū)中，此時(shí)可以采用稀有片段優(yōu)先的選擇策略和拉模式獲取隊(duì)列中缺少的數(shù)據(jù)片段;如果這些數(shù)據(jù)片段在合作節(jié)點(diǎn)緩沖區(qū)中不存在，則采用隨機(jī)策略和推模式獲取該隊(duì)列中缺少的數(shù)據(jù)片段。

拉隊(duì)列(Pulling Queue):該隊(duì)列存放拉緩沖區(qū)中缺少的數(shù)據(jù)片段，采用序號(hào)優(yōu)先的數(shù)據(jù)片段選擇策略以拉模式從合作節(jié)點(diǎn)中獲得數(shù)據(jù)片段;

已發(fā)請(qǐng)求隊(duì)列(Sent Queue):該隊(duì)列存放使用拉模式請(qǐng)求的、但未到達(dá)的數(shù)據(jù)片段。

3.4 數(shù)據(jù)調(diào)度策略分析

基于前面內(nèi)容所述，本文提出了基于節(jié)點(diǎn)帶寬的自適應(yīng)數(shù)據(jù)調(diào)度策略，經(jīng)過分析，該策略具有以下三個(gè)優(yōu)勢(shì):

(1)保證對(duì)等節(jié)點(diǎn)流媒體點(diǎn)播的流暢度。播放點(diǎn)增長(zhǎng)到數(shù)據(jù)片段的序號(hào)的時(shí)間間隔為數(shù)據(jù)片度的彈性時(shí)間，本文提出的策略可以在每個(gè)數(shù)據(jù)片段的彈性時(shí)間內(nèi)，將所需數(shù)據(jù)片段放入緩沖區(qū)內(nèi)，彈性時(shí)間較低的數(shù)據(jù)片段采用拉模式，直接從視頻源服務(wù)器獲取或者優(yōu)先從有較強(qiáng)服務(wù)能力的合作節(jié)點(diǎn)處獲取。

(2)提高帶寬利用率。本文提出的策略能夠準(zhǔn)確的評(píng)估合作節(jié)點(diǎn)服務(wù)能力，根據(jù)合作節(jié)點(diǎn)的處理能力、服務(wù)帶寬等服務(wù)能力指標(biāo)自適應(yīng)調(diào)整視頻獲取節(jié)點(diǎn)，避免數(shù)據(jù)片段丟棄率上升，提高了節(jié)點(diǎn)帶寬利用率。

(3)拉模式和推模式優(yōu)勢(shì)相連，降低系統(tǒng)延遲。在數(shù)據(jù)傳輸過程中，拉模式根據(jù)接收節(jié)點(diǎn)的需求，主動(dòng)進(jìn)行數(shù)據(jù)請(qǐng)求，調(diào)度到的數(shù)據(jù)具有很高的精確度，但產(chǎn)生了附加的延遲;推模式的結(jié)果很難預(yù)計(jì)，但是其延遲較低，因此，將二者的優(yōu)勢(shì)相互結(jié)合，在保證播放流暢度前提下，盡量降低系統(tǒng)傳輸延遲?；诠?jié)點(diǎn)帶寬的自適應(yīng)數(shù)據(jù)調(diào)度策略流程如表1所示:

表1 基于節(jié)點(diǎn)帶寬的自適應(yīng)數(shù)據(jù)調(diào)度策略流程Table 1 Based on the node bandwidth adaptive data scheduling strategy process

為了簡(jiǎn)化實(shí)驗(yàn)，本文將推隊(duì)列和拉隊(duì)列中需要調(diào)度的數(shù)據(jù)片段按照傳輸模式分為兩種類型:

(1)在所有合作節(jié)點(diǎn)都不存在的數(shù)據(jù)片段，本文數(shù)據(jù)調(diào)度策略可以采用推模式獲取;

(2)部分已知的合作節(jié)點(diǎn)擁有某數(shù)據(jù)片段，本文數(shù)據(jù)調(diào)度策略使用拉模式獲取;

拉隊(duì)列中的數(shù)據(jù)片段采用序號(hào)優(yōu)先的策略，推隊(duì)列中的數(shù)據(jù)調(diào)度策略采用最少優(yōu)先策略，同時(shí)規(guī)定，拉隊(duì)列中的數(shù)據(jù)片段的優(yōu)先級(jí)高于推隊(duì)列中的數(shù)據(jù)片段的優(yōu)先級(jí)。

4 實(shí)驗(yàn)及其分析

4.1 實(shí)驗(yàn)環(huán)境及評(píng)比方法

本文采用實(shí)驗(yàn)環(huán)境是PeerSim模擬器。在該模擬器中，本文對(duì)P2P流媒體系統(tǒng)進(jìn)行仿真，網(wǎng)絡(luò)節(jié)點(diǎn)的動(dòng)態(tài)特性實(shí)現(xiàn)方法是按照18%的比例增減覆蓋網(wǎng)中合作節(jié)點(diǎn)數(shù)量，實(shí)驗(yàn)過程中保持覆蓋網(wǎng)的擁有最多1200個(gè)合作節(jié)點(diǎn)即可，同時(shí)，本文將覆蓋網(wǎng)劃分為16個(gè)AS，流媒體直播的流速率1Mbps，其最小位速率256Kbps。

本文評(píng)比算法優(yōu)劣的標(biāo)準(zhǔn)采用源端時(shí)延。因?yàn)楣?jié)點(diǎn)數(shù)目對(duì)源端時(shí)延的具有重要的影響。源端時(shí)延是指用戶執(zhí)行點(diǎn)播操作，數(shù)據(jù)從源端傳輸?shù)娇蛻舳耍曨l正常播放之時(shí)的客戶需要等待的時(shí)間。由于數(shù)據(jù)片段的時(shí)延和丟失取決于數(shù)據(jù)調(diào)度算法，因此數(shù)據(jù)調(diào)度算法大大的影響流媒體的服務(wù)質(zhì)量考核的一個(gè)重要指標(biāo)——時(shí)延，節(jié)點(diǎn)的源端時(shí)延是考核數(shù)據(jù)調(diào)度算法的重要指標(biāo)。

4.2 實(shí)驗(yàn)結(jié)果分析

為了比較自適應(yīng)數(shù)據(jù)調(diào)度算法的效果，實(shí)驗(yàn)過程中，本文選擇兩個(gè)經(jīng)典的數(shù)據(jù)調(diào)度算法Coolstreaming、Tree。其研究結(jié)果如圖4所示。

圖4 節(jié)點(diǎn)數(shù)目對(duì)源端時(shí)延造成的影響Fig.4 The number of nodes on the impact of source end delay

由圖4可知，隨著節(jié)點(diǎn)數(shù)目的增多，Coolstreaming和Tree算法導(dǎo)致系統(tǒng)時(shí)延大大增加，嚴(yán)重的阻礙了流媒體的擴(kuò)展性。由于播放初始時(shí)，客戶端需要從源服務(wù)器獲得數(shù)據(jù)，初始啟動(dòng)時(shí)，數(shù)據(jù)調(diào)度時(shí)延幾乎是相等的，但是，隨著動(dòng)態(tài)調(diào)整覆蓋網(wǎng)中的節(jié)點(diǎn)數(shù)量，節(jié)點(diǎn)逐漸增加，因此，節(jié)點(diǎn)可以從其他鄰居節(jié)點(diǎn)獲得所缺少的數(shù)據(jù)片段，此時(shí)，自適應(yīng)算法就可以使用多層反饋隊(duì)列動(dòng)態(tài)調(diào)整數(shù)據(jù)調(diào)度，充分的考慮節(jié)點(diǎn)服務(wù)性能，降低流媒體系統(tǒng)的源端時(shí)延，直至趨于平緩，實(shí)驗(yàn)結(jié)果表明，基于節(jié)點(diǎn)帶寬自適應(yīng)數(shù)據(jù)調(diào)度算法能夠降低系統(tǒng)的源端時(shí)延，優(yōu)于Coolstreaming和Tree算法。

5 未來工作總結(jié)

本文詳細(xì)的分析了現(xiàn)有數(shù)據(jù)調(diào)度策略，提出了基于節(jié)點(diǎn)帶寬的自適應(yīng)數(shù)據(jù)調(diào)度策略，實(shí)驗(yàn)表明該策略有效的降低了數(shù)據(jù)傳輸時(shí)延。該策略研究過程過中，發(fā)現(xiàn)未來工作的重點(diǎn)是尋找維護(hù)多層反饋隊(duì)列和備用節(jié)點(diǎn)集的方法，以便更好的降低系統(tǒng)消耗。

［1］ Deshpande H，Hrishikesh and Bawa，Garcia Molina H.streaming live media over a P2P network［R］.In Work at CS – Stanford 2002

［2］ Tran D，Hua K，D.T.Zigzag.an efficient P2P scheme for media streaming［J］.Proc.of IEEE INFOCOM'03，2003，4-6

［3］ Suman Banerjee，Bobby Bhattacharjee，Christopher Kommareddy，etal.Scalable application layer multicast［J］，Proc.Of SIGCOMM'02，2002:205-220.

［4］ Lee，J.Y.B.，Leung，R.W.T.Study of a Server-less Architecture for VoD Applications［J］.Proc IEEE ICME，2002，8:233-236

［5］ N.Venkata Padmanabhan，Helen J.Wang，Philip A.Chou，etal.distributing streaming media content using cooperative networking［J］.Proc.Of ACM/IEEE NOSSDAV.2002，5:12-14

［6］ Deshpande H，Hrishikesh and Bawa，Garcia Molina H.Streaming Live Media over Peers［R］.Stanford University，2001

［7］ Salman A.Baset，Henning Schulzrinne.An analysis of the Skype P2P internet telephony protocol［J］.In Proc.of IEEE INFOCOM 2006，4

［8］ PPLive［DB］.2005，http://www.pplive.com

［9］ Xiaofei Liao，Hai Jin，Yunhao Liu，etal.Scalable Live Streaming Service Based Inter-Overlay Optimization［J］.IEEE Transactions on Parallel and Distribute Systems，2007，18(12):1663-1674

［10］ QQlive［DB］.2009，http://live.qq.com

［11］ Bo Liu，Yansheng Lu，Yi Cui，etal.A measurement study on AS-aware P2P streaming strategies［C］.Proc.of 3rd ICCN.China.2008:564568.

［12］ X.Hei，Y.Liu，and K.W.Ross.IPTV over P2P streaming networks:the mesh-pull approach［J］.IEEE Communications Magazine，2008:8692.