專利名稱：用于對等網(wǎng)絡中的接收器驅動流傳送的系統(tǒng)和方法
技術領域：
本發(fā)明涉及用于松耦合對等(P2P)網(wǎng)絡的接收器驅動P2P媒體流，尤其涉及用于在實時協(xié)調和客戶機控制下將媒體從多個對等體流傳送到客戶機，而無需提供對等協(xié)作的系統(tǒng)和方法。
背景技術：
最近的市場研究指出，在2004年，美國有一半以上的因特網(wǎng)用戶訪問了某種形式的流媒體。訪問流音樂是一種很流行的活動，而流視頻的普及程度正在迅速增高。
不幸的是，與典型的網(wǎng)頁不同，流媒體文件的尺寸通常極其大。例如，取決于所使用的編解碼器，按2兆比特/秒(Mbps)來編碼的3分鐘的電影宣傳片會產生45兆字節(jié)(MB)的媒體文件。流媒體必須解決的另一個問題是數(shù)據(jù)包傳遞的嚴格定時。因此，流媒體文件的大尺寸和數(shù)據(jù)包傳遞定時要求使典型的流媒體服務器設立和運行起來相對較昂貴。例如，一個當前的估算將用于流傳送媒體的現(xiàn)行率定為每1GB的服務通信量是10美元。通過使用45MB文件大小的例子，這會導致被分發(fā)的每一電影宣傳片有0.45美元的帶寬成本。顯而易見，隨著媒體流量的增加，該成本會迅速上升。
對于媒體流的相對較高的成本的一個解決方案是使用“對等”(P2P)網(wǎng)絡來將媒體流提供給個別的客戶機。一般而言，P2P網(wǎng)絡的基本理念是允許每個對等節(jié)點協(xié)助媒體服務器分發(fā)流媒體。用于流媒體的P2P網(wǎng)絡的成功得到了用于實現(xiàn)P2P網(wǎng)絡的大量常規(guī)途徑。
例如，被稱作“終端系統(tǒng)多點傳送”和“PeerCast”的常規(guī)P2P方案使用用于媒體流的應用程序級多點傳送(ALM)。具體地，利用ESM和PeerCast，這些對等節(jié)點被自我組織到現(xiàn)有IP網(wǎng)絡上的覆蓋樹中。然后，沿該覆蓋樹來分發(fā)流數(shù)據(jù)。隨后，在這些對等節(jié)點之間共享提供帶寬的成本，從而減輕運行媒體服務器的帶寬負擔(因此減少美元成本)。然而，利用ESM和PeerCast，該分發(fā)樹的葉節(jié)點只接收流媒體，而不促成內容分發(fā)。
兩個其它的常規(guī)方案“CoopNet”和“SplitStream”通過使用跨越來源和對等節(jié)點的多個分發(fā)樹，解決了諸如ESM和PeerCast等方案的內容分發(fā)局限。然后，CoopNet和SplitStream中的每個樹可以發(fā)送流媒體的單獨片斷。結果，所有對等節(jié)點都可以涉及內容分發(fā)。
常規(guī)P2P媒體流解決方案的另一例子包括被稱作“OStream”的流傳送方案。OStream使用“高速緩存和中繼站”方法，使得對等節(jié)點可以向客戶機提供先前從其高速緩存分發(fā)的媒體。另一個常規(guī)系統(tǒng)“GnuStream”提供構建在公知的“Gnutella”系統(tǒng)之上的接收器驅動P2P媒體流系統(tǒng)。而被稱作“CollectCast”的另一個常規(guī)方案積極地尋找最有可能實現(xiàn)最佳流傳送質量的服務對等體，同時動態(tài)地自適應網(wǎng)絡波動和對等體故障。
另一種類型的常規(guī)方案提供一種類型分布式文件共享，其中，文件的各個片斷跨越許多對等體而被廣泛的分發(fā)。然后，只要客戶機請求下載該文件，就從多個對等體(而不是直接從服務器)服務該請求。例如，被稱作“Swarmcast”的一個這樣的方案通過將文件分成小得多的各個片斷，來散布施加在提供流行的可下載內容的網(wǎng)站上的負載。一旦用戶安裝了該Swarmcast客戶機程序，其計算機就通過分發(fā)(即供應)它們已下載的各個數(shù)據(jù)片斷來自動與其它用戶的計算機進行合作，從而減少中央服務器上的總服務負載。被稱作“BitTorrent”的類似方案按照很類似的原則來運作。特別是，當在低負載情況時，使用BitTorrent方案來供應大型文件的網(wǎng)站將表現(xiàn)得很象典型的http服務器，因為它執(zhí)行供應本身的大部分。然而，當服務器負載達到某個相對較高的水平時，BitTorrent將轉變?yōu)榇蟛糠稚蟼髫摀捎糜诠渌螺d客戶機的下載客戶機本身來承受的狀態(tài)。
不幸的是，盡管諸如Swarmcast和BitTorrent等方案對于根據(jù)P2P網(wǎng)絡規(guī)模分發(fā)各個文件片斷以顯著地增加服務器容量而言很有用，但這些系統(tǒng)不適用于有效率地流傳送媒體。特別是，諸如Swarmcast和BitTorrent等方案不關心構成正被下載的一個或多個文件的數(shù)據(jù)包的傳遞的順序或定時。這些文件僅僅逐段地從各對等體廣播到客戶機，然后僅僅按正確順序在本地重新組裝，以便在客戶機計算機上重建原始文件。但是，在流媒體的情況下，必須仔細地考慮和控制數(shù)據(jù)包的定時和順序，以便提供媒體的有效的流傳送。
所以，需要一種系統(tǒng)和方法，用于從松散耦合的對等體集合到客戶機的媒體流的接收器驅動控制。這種系統(tǒng)不應該要求各個對等體之間的通信或協(xié)作。另外，這種系統(tǒng)和方法應該通過要求客戶機執(zhí)行任何必要的計算操作的大部分，來將施加于對等體上的計算要求最小化。

發(fā)明內容
如這里所描述的“PeerStreamer(對等流傳送器)”提供用于松散耦合P2P網(wǎng)絡的接收器驅動對等(P2P)媒體流。網(wǎng)絡中的對等體只執(zhí)行簡單的操作、可以高速緩存流媒體的全部或一部分、不與其它對等體協(xié)作、可以是不可靠的、并可以在任何給定的流傳送會話期間脫機或聯(lián)機。網(wǎng)絡中的客戶機(或接收器)進行實時操作，以便協(xié)調對等體、從多個對等體流傳送媒體、執(zhí)行負載平衡、處理對等體的聯(lián)機/脫機狀態(tài)、以及執(zhí)行對流媒體的解碼和呈現(xiàn)。
注意，這里所描述的PeerStreamer系統(tǒng)適用于具有多個客戶機和對等體的大型P2P網(wǎng)絡，但出于解釋清楚的目的，下文將一般涉及個別客戶機。本領域的技術人員將會理解，所描述的由PeerStreamer提供的系統(tǒng)和方法適用于多個客戶機。此外，由于這里所描述的對等體用來將媒體供應給接收器或客戶機，因此，P2P網(wǎng)絡中的對等體群集在這里通常被稱作“對等體”或“服務對等體”。也應該注意，如這里所描述的，這些“服務對等體”不應該與特定的流媒體文件最初所起源的“媒體服務器”混淆。
一般而言，PeerStreamer提供接收器驅動媒體流傳送。PeerStreamer操作始于每個接收客戶機檢索保持所請求的流媒體的全部或一部分的附近的對等體的列表。注意，在該上下文中，媒體服務器也可以擔當這些服務對等體之一。該列表包括IP地址、以及保持該服務媒體的完整或部分副本的一組一個或多個相鄰服務對等體的監(jiān)聽端口。用于檢索該列表的方法包括1)直接從媒體服務器中檢索該列表；2)從已知的服務對等體中檢索該列表；以及3)使用用于標識這些服務對等體的分布式散列表(DHT)方法。
一旦客戶機檢索了可用服務對等體列表，該客戶機就連接到每個服務對等體，并獲得其“可用性向量”。一般而言，每個服務對等體的可用性向量是該服務對等體所保持的媒體的確切部分的緊縮描述。然后，這些可用性向量由客戶機用來確切地確定各個服務對等體保持該編碼媒體的什么塊。
例如，在特定的服務對等體保持全部服務媒體的情況下，該對等體的可用性向量可以是指出該服務對等體保持完整的媒體副本的單個標志。同樣，如果服務對等體只保持服務媒體的一部分，那么該服務對等體的可用性向量將用信號通知客戶機，服務對等體保持媒體的什么部分，例如，由服務對等體保持的每個數(shù)據(jù)包的塊數(shù)以及塊索引。
另外，在使用附加編碼，例如以下所描述的各種擦除編碼(erasure coding)技術的情況下，可用性向量將包括分配給服務對等體的媒體擦除編碼關鍵字、以及由該服務對等體保持的擦除塊的數(shù)目。此外，如果服務對等體使用擦除編碼，并且，該媒體也被嵌入編碼，那么，可用性向量將包括所分配的媒體擦除編碼關鍵字、以及該嵌入編碼所使用的不同的比特率水平處的每個數(shù)據(jù)包的擦除塊的數(shù)目。
一般而言，已編碼的媒體文件通常包括“媒體頭部”，隨后是表示所編碼的媒體的多個媒體數(shù)據(jù)包(即“媒體主體”)。給定該可用性向量，下一步是讓客戶機檢索媒體頭部和“媒體結構”的長度，該媒體結構可從將要從對等體群集流傳送的已編碼媒體文件中導出。一組數(shù)據(jù)包的媒體結構僅僅是數(shù)據(jù)包頭部加上數(shù)據(jù)包比特流長度。在檢索了這些長度之后，客戶機計算該媒體頭部和媒體結構的“數(shù)據(jù)單元ID”，并按協(xié)作方式從該對等體群集中的一個或多個對等體中檢索它們。
一旦媒體頭部到達，客戶機就分析該媒體頭部，然后配置或初始化解碼和呈現(xiàn)或回放正被流傳送的特定類型的媒體(即MPEG 1/2/4、WMA、WMV等)所需要的任何音頻/視頻解碼器和呈現(xiàn)設備。一旦完成了這個初始設置階段，客戶機隨后就開始如下所述地協(xié)調正在進行的從對等體群集的媒體主體流傳送。
具體地，給定特定流媒體的前述媒體結構，客戶機計算流媒體(即媒體主體)的數(shù)據(jù)包的數(shù)據(jù)單元ID，然后逐個地檢索那些數(shù)據(jù)包。在一個相關的實施例中，PeerStreamer使用嵌入編碼媒體，然后，流傳送比特率根據(jù)可用服務帶寬和客戶機隊列狀態(tài)而改變。在此情況下，媒體主體的媒體數(shù)據(jù)包的正在進行的檢索對應于將基于可用帶寬來提供最小的速率失真的那些數(shù)據(jù)包。
在任何一種情況下，客戶機周期性地更新服務對等體列表，并連接到潛在的新服務對等體。在一個測試實施例中，客戶機通過發(fā)出對于每個潛在的服務對等體的周期性常規(guī)TCP連接函數(shù)調用，來核對潛在的新服務對等體。在客戶機建立與新服務對等體的連接之后，它首先檢索前述可用性向量。然后，在接收器/客戶機的方向上，該新對等體可以加入該群集中的其它活動對等體。然后，客戶機協(xié)調這些對等體、根據(jù)其服務帶寬和內容可用性來平衡這些對等體的服務負載、并將斷開的或超時的對等體的無法履行的請求重定向到其它活動對等體中的一個或多個。然后，流傳送操作按這個方式繼續(xù)進行，直到全部流媒體被接收，或者流傳送操作被用戶停止。
在一個實施例中，PeerStreamer使用高速率擦除彈性編碼，以允許多個服務對等體保持部分媒體而無沖突，以便客戶機僅僅檢索固定數(shù)目的擦除編碼塊，而不管在哪里檢索和檢索什么特定塊。在此情況下，將所接收的擦除編碼塊放入客戶機的分級隊列，其中，媒體數(shù)據(jù)包隨后被組裝。然后，向下游發(fā)送被完全組裝的媒體數(shù)據(jù)包，以便使用已為解碼和呈現(xiàn)或回放正被流傳送的特定類型的媒體而配置或初始化的任何音頻/視頻解碼器和呈現(xiàn)設備來對它們進行解碼和回放。在此情況下，通過控制分級隊列的長度、請求隊列的長度和壓縮的音頻/視頻緩沖區(qū)的長度，客戶機維持某段所需時期(在一個測試實施例中是4秒的數(shù)量級)的流緩沖區(qū)。然后，使用組合的緩沖區(qū)來防止網(wǎng)絡數(shù)據(jù)包丟失和抖動。
鑒于以上概述，顯而易見，這里所描述的PeerStreamer提供一種用于在P2P網(wǎng)絡中提供接收器驅動媒體流傳送的獨特的系統(tǒng)和方法。除了剛剛描述的這些好處以外，通過下文中的詳細描述并結合附圖，PeerStreamer的其它優(yōu)點也將會變得一目了然。


通過以下說明、所附權利要求書和附圖，本發(fā)明的這些具體特征、方面和優(yōu)點將得到更好的理解，附圖中圖1是描繪構成實現(xiàn)如這里所描述的“PeerStreamer”的示例性系統(tǒng)的通用計算設備的通用系統(tǒng)框圖。
圖2示出了用于如這里所描述的接收器驅動媒體流傳送的示例性對等(P2P)網(wǎng)絡。
圖3提供示出用于實現(xiàn)如這里所描述的PeerStreamer的程序模塊的示例性體系結構流程圖。
圖4示出了如這里所描述的流媒體文件的文件格式。
圖5示出了如這里所描述的PeerStreamer的測試實施例中所使用的“數(shù)據(jù)單元”。
圖6示出了如這里所描述的已被分成8個數(shù)據(jù)單元的嵌入編碼媒體數(shù)據(jù)包的部分高速緩存。
圖7提供了客戶機PeerStreamer媒體流傳送會話的示例DirectShowTM過濾器圖表。
圖8提供了表示如這里所描述的PeerStreamer請求和分級隊列以及流媒體解碼、呈現(xiàn)和回放的體系結構系統(tǒng)圖，其系統(tǒng)緩沖區(qū)由虛線來示出。
圖9提供了用于到達的數(shù)據(jù)單元的PeerStreamer客戶機分級隊列，以及用于每個服務對等體的PeerStreamer客戶機請求隊列的框解。
圖10提供了示出如這里所描述的PeerStreamer的一個實施例的通用操作的操作流程圖。
具體實施例方式
在本發(fā)明較佳實施例的以下描述中，參考附圖，這些附圖構成本發(fā)明的一部分，并且在這些附圖中，通過舉例說明，示出可以在其中實踐本發(fā)明的特定實施例?？衫斫?，在不脫離本發(fā)明的范圍的前提下，可以利用其它實施例，并且可以進行結構上的更改。
1.0示例性操作環(huán)境圖1示出了可以在其上實現(xiàn)本發(fā)明的合適的計算系統(tǒng)環(huán)境100的例子。計算系統(tǒng)環(huán)境100只是合適的計算環(huán)境的一個例子，它并不意在對本發(fā)明的使用范圍或功能提出任何限制。也不應該將計算環(huán)境100解釋為對示例性操作環(huán)境100中所示的任何一個組件或組件組合具有任何依賴性或要求。
本發(fā)明可用于眾多其它的通用或專用計算系統(tǒng)環(huán)境或配置。可適用于本發(fā)明的眾所周知的計算系統(tǒng)、環(huán)境和/或配置的例子包括，但不限于個人計算機、服務器計算機、手持式、膝上型或可移動計算機或通信設備(例如，蜂窩電話和PDA)、多處理器系統(tǒng)、基于微處理器的系統(tǒng)、機頂盒、可編程消費者電子設備、網(wǎng)絡PC、小型計算機、大型計算機、包括以上任何系統(tǒng)或設備的分布式計算環(huán)境等等。
本發(fā)明可以在諸如程序模塊等由計算機結合硬件模塊(包括話筒陣列198的各個組件)而執(zhí)行的計算機可執(zhí)行指令的一般上下文中描述。通常，程序模塊包括執(zhí)行特定任務或實現(xiàn)特定抽象數(shù)據(jù)類型的例程、程序、對象、組件、數(shù)據(jù)結構等。本發(fā)明也可以在分布式計算環(huán)境中實踐，其中，任務由通過通信網(wǎng)絡連接的遠程處理設備來執(zhí)行。在分布式計算環(huán)境中，程序模塊可以位于包括存儲器存儲設備的本地和遠程計算機存儲介質中。參照圖1，用于實現(xiàn)本發(fā)明的示例性系統(tǒng)包括計算機110形式的通用計算設備。
計算機110的組件可以包括，但不限于，處理單元120、系統(tǒng)存儲器130和將包括系統(tǒng)存儲器的各種系統(tǒng)組件耦合到處理單元120的系統(tǒng)總線121。系統(tǒng)總線121可以是幾種類型的總線結構中的任一種，包括存儲總線或存儲控制器、外圍總線、以及使用各種總線體系結構中的任一種的局部總線。作為示例而非局限，這類體系結構包括工業(yè)標準體系結構(ISA)總線、微通道體系結構(MCA)總線、增強型ISA(EISA)總線、視頻電子技術標準協(xié)會(VESA)局部總線和外圍部件互連(PCI)總線，也被稱作Mezzanine總線。
計算機110通常包括各種計算機可讀介質。計算機可讀介質可以是可由計算機110訪問的任何可用介質，它包括易失性和非易失性介質、可移動和不可移動介質。作為示例而非局限，計算機可讀介質可以包括計算機存儲介質和通信介質。計算機存儲介質包括以用于諸如計算機可讀指令、數(shù)據(jù)結構、程序模塊或其它數(shù)據(jù)等信息的存儲的任何方法或技術來實現(xiàn)的易失性性和非易失性、可移動和不可移動介質。
計算機存儲介質包括，但不限于RAM、ROM、PROM、EPROM、EEPROM、閃存或其它存儲器技術；CD-ROM、數(shù)字多功能盤(DVD)、或其它光盤存儲器；盒式磁帶、磁帶、磁盤存儲器、或其它磁性存儲設備；或可以用來存儲所需信息并可以由計算機110訪問的其它任何介質。通信介質通常具體表現(xiàn)為諸如載波或其它傳輸機制等已調制數(shù)據(jù)信號中的計算機可讀指令、數(shù)據(jù)結構、程序模塊或其它數(shù)據(jù)，它包括任何信息傳遞介質。術語“已調制數(shù)據(jù)信號”指其一個或多個特征按為信號中的信息編碼的方式來加以設置或更改的信號。作為示例而非局限，通信介質包括有線介質，例如，有線網(wǎng)絡或直線連接，和無線介質，例如，聲學、RF、紅外線和其它無線介質。以上任何內容的組合也應該被包括在計算機可讀介質的范圍以內。
系統(tǒng)存儲器130包括易失性和/或非易失性存儲器形式的計算機存儲介質，例如只讀存儲器(ROM)131和隨機存取存儲器(RAM)132?；据斎?輸出系統(tǒng)133(BIOS)通常存儲在ROM 131中，它包含例如在啟動期間有助于在計算機110內的各個元件之間傳送信息的基本例程。RAM 132通常包含可立即由處理單元120訪問和/或目前正由處理單元120操作的數(shù)據(jù)和/或程序模塊。作為示例而非局限，圖1示出了操作系統(tǒng)134、應用程序135、其它程序模塊136和程序數(shù)據(jù)137。
計算機110也可以包括其它可移動/不可移動、易失性/非易失性計算機存儲介質。僅作為示例，圖1示出了從不可移動非易失性磁性介質讀取或對其寫入的硬盤驅動器141、從可移動非易失性磁盤152讀取或對其寫入的磁盤驅動器151，以及從可移動非易失性光盤156(例如，CD ROM或其它光學介質)讀取或對其寫入的光盤驅動器155?？梢杂糜谑纠圆僮鳝h(huán)境中的其它可移動/不可移動、易失性/非易失性計算機存儲介質包括，但不限于，盒式磁帶、閃存卡、數(shù)字多功能盤、數(shù)字錄像帶、固態(tài)RAM、固態(tài)ROM等。硬盤驅動器141通常通過不可移動存儲器接口，如接口140連接到系統(tǒng)總線121，磁盤驅動器151和光盤驅動器155通常由可移動存儲器接口，如接口150連接到系統(tǒng)總線121。
以上所討論的和圖1中所示出的這些驅動器及其相關聯(lián)的計算機存儲介質為計算機110提供計算機可讀指令、數(shù)據(jù)結構、程序模塊和其它數(shù)據(jù)的存儲。例如，在圖1中，硬盤驅動器141被示為存儲操作系統(tǒng)144、應用程序145、其它程序模塊146和程序數(shù)據(jù)147。注意，這些組件可以與操作系統(tǒng)134、應用程序135、其它程序模塊136和程序數(shù)據(jù)137相同或不同。這里為操作系統(tǒng)144、應用程序145、其它程序模塊146和程序數(shù)據(jù)147提供不同的標號，以說明它們至少是不同的副本。用戶可以通過輸入設備，例如鍵盤162和定點設備161(通常指鼠標、跟蹤球或觸摸墊)，來將命令和信息輸入到計算機110。
其它輸入設備(未示出)可以包括操縱桿、游戲墊、圓盤式衛(wèi)星天線、掃描儀、無線電接收器、以及電視或廣播視頻接收器、或類似的輸入設備。這些和其它輸入設備經常通過耦合到系統(tǒng)總線121的有線或無線用戶輸入接口160連接到處理單元120，但也可以由其它常規(guī)接口和總線結構連接，例如，并行端口、游戲端口、通用串行總線(USB)、IEEE 1394接口、BluetoothTM(藍牙)無線接口、IEEE 802.11無線接口等。另外，計算機110也可以包括經由音頻接口199連接的語音或音頻輸入設備，例如話筒或話筒陣列198，以及擴音器197或其它聲音輸出設備，音頻接口199也包括常規(guī)的有線或無線接口，例如并行、串行、USB、IEEE 1394、BluetoothTM等。
監(jiān)視器191或其它類型的顯示設備也經由接口，如視頻接口190連接到系統(tǒng)總線121。除監(jiān)視器以外，計算機也可以包括其它外圍輸出設備，如打印機196，它們可以通過輸出外圍接口195來連接。
計算機110可以使用與一臺或多臺遠程計算機，如遠程計算機180的邏輯連接而在聯(lián)網(wǎng)環(huán)境中操作。遠程計算機180可以是個人計算機、服務器、路由器、網(wǎng)絡PC、對等設備或其它普通網(wǎng)絡節(jié)點，它通常包括以上相對于計算機110而描述的許多或所有元件，盡管圖1中只示出了存儲器存儲設備181。圖1中所描繪的邏輯連接包括局域網(wǎng)(LAN)171和廣域網(wǎng)(WAN)173，但也可以包括其它網(wǎng)絡。這類聯(lián)網(wǎng)環(huán)境在辦公室、企業(yè)范圍計算機網(wǎng)絡、內聯(lián)網(wǎng)和因特網(wǎng)中很普遍。
當用于LAN聯(lián)網(wǎng)環(huán)境中時，計算機110通過網(wǎng)絡接口或適配器170連接到LAN 171。當用于WAN聯(lián)網(wǎng)環(huán)境中時，計算機110通常包括調制解調器172或用于通過WAN 173(例如，因特網(wǎng))建立通信的其它裝置。調制解調器172可以是內置或外置的，它可以經由用戶輸入接口160或其它適當?shù)臋C制連接到系統(tǒng)總線121。在聯(lián)網(wǎng)環(huán)境中，相對于計算機110而描繪的程序模塊或其各個部分可以被存儲在遠程存儲器存儲設備中。作為示例而非局限，圖1將遠程應用程序185示為駐留在存儲器設備181上。將會理解，所示的網(wǎng)絡連接起示例性的作用，可以使用在計算機之間建立通信鏈路的其它裝置。
現(xiàn)在已討論了示例性操作環(huán)境，本描述的剩余部分將致力于討論實施“PeerStreamer”的程序模塊和過程，該“PeerStreamer”提供對用于分布式媒體流傳送的接收器驅動對等(P2P)網(wǎng)絡中的一個或多個對等體的群集的動態(tài)實時客戶機控制。
2.0引言如這里所描述的“PeerStreamer”提供用于松散耦合P2P網(wǎng)絡的接收器驅動對等(P2P)媒體流傳送。該網(wǎng)絡中的對等體只執(zhí)行簡單的操作、可以高速緩存流媒體的全部或一部分、不與其它對等體協(xié)作、可以是不可靠的、并可以在任何給定的流傳送會話期間脫機或聯(lián)機。該網(wǎng)絡中的客戶機進行實時操作，以便協(xié)調對等體、從多個對等體流傳送媒體、執(zhí)行負載平衡、處理對等體的聯(lián)機/脫機狀態(tài)、以及執(zhí)行對流媒體的解碼和呈現(xiàn)。
注意，這里所描述的PeerStreamer系統(tǒng)適用于具有多個客戶機和對等體的大型P2P網(wǎng)絡，但出于解釋清楚的目的，下文將通常涉及個別的客戶機。本領域的技術人員將會理解，由PeerStreamer提供的所描述的系統(tǒng)和方法適用于多個客戶機。此外，由于這里所描述的對等體用來將媒體供應給接收器或客戶機，因此，P2P網(wǎng)絡中的對等體群集在這里通常被稱作“對等體”或“服務對等體”。也應該注意，如這里所描述的，“服務對等體”不應該與特定流媒體文件最初所起源的“媒體服務器”混淆。
一般而言，PeerStreamer在諸如圖2所示的網(wǎng)絡等P2P網(wǎng)絡中操作。對于特定的流傳送會話，“服務器”200被定義為P2P網(wǎng)絡中最初發(fā)起流媒體的節(jié)點；“客戶機”(或接收器)210被定義為當前請求流媒體的節(jié)點；并且，“服務對等體”220被定義為向客戶機供應流媒體的完整或部分副本的節(jié)點。
一般而言，服務器200、客戶機210和服務對等體220都是與諸如因特網(wǎng)等網(wǎng)絡連接的最終用戶節(jié)點。由于服務器200總是能夠供應流媒體，因此，服務器節(jié)點也擔當服務對等體220。服務器節(jié)點200也可以執(zhí)行無法由服務對等體220執(zhí)行的媒體管理功能，例如，維持可用服務對等體的列表、執(zhí)行數(shù)字權限管理(DRM)功能等等。此外，對于常規(guī)的P2P方案，當部署越來越多的流對等體節(jié)點220時，這里所描述的PeerStreamer會得益于效率的提高。特別是，隨著流對等體節(jié)點220的數(shù)目的增加，媒體服務器200上的負載將會減少，從而運行起來費用不會太大，同時，每個客戶機節(jié)點210將能夠在特定媒體流傳送會話期間接收好得多的媒體質量。
此外，應該顯而易見，對于許多其它P2P類型的網(wǎng)絡，特定節(jié)點的角色可能會改變。例如，特定節(jié)點可以在一個特定的流傳送會話中擔當客戶機210，同時，在另一個會話中擔當服務對等體220。另外，特定節(jié)點可以同時擔當客戶機節(jié)點210和服務器200或服務對等體220，以便同時流傳送一個或多個媒體文件或媒體文件的各個部分，同時，從一個或多個其它服務對等體接收其它流媒體。
在流傳送會話期間，客戶機200首先定位保持部分或全部所需媒體的多個靠近的對等體220，然后從這多個對等體(可以包括服務器200)流傳送媒體。因此，每個服務對等體220通過服務客戶機210的下載請求的一個部分，來協(xié)助服務器200減輕總上傳負擔。結果，尤其在有許多客戶機的情況下，客戶機210經常可以接收好得多的流媒體質量，因為當有許多流對等體220來協(xié)助服務器200時，有大得多的服務帶寬可用。
對于任何P2P網(wǎng)絡，每一個別的對等體220不直接得益于服務一個或多個客戶機210。但是，在一個實施例中，常規(guī)的P2P“公平機制”用來確保，與在擔當服務對等體的過程中還沒有平等地合作的另一個對等體相比較，合作對等體220在供應隨后的流請求方面接收更高的優(yōu)先級。因此，當利用PeerStreamer來實現(xiàn)這種公平機制時，合作對等體220通常可以期待在下一次它變成客戶機210時會有更好的媒體質量。
因此，認識到每個服務對等體220在任何特定的流傳送會話期間有效地支持客戶機210和服務器200的事實，良好的設計原理是確保服務對等體是輕量級的，且P2P網(wǎng)絡是松散耦合的。換言之，服務對等體220應該只需要執(zhí)行具有低CPU負載的最簡單的操作。另外，在一個實施例中，服務對等體220也可以選擇只高速緩存媒體的一部分，以便將本質上由每個服務對等體貢獻的存儲空間減到最小。此外，為了降低各個對等體220之間的通信的任何帶寬成本，不應該要求每個服務對等體與其它對等體協(xié)作。最后，運行于任何特定的服務對等體220上的其它程序可以對在任何特定的時刻在要求CPU和網(wǎng)絡資源方面具有更高的優(yōu)先級，或者，特定的對等體可以在任何時候只是簡單地被打開或關閉。結果，特定的服務對等體200可以是不可靠的，可用的服務帶寬方面有波動。實際上，在流傳送會話期間的任何時候，特定的服務對等體可以簡單地脫機或聯(lián)機。
相反，在客戶機210上增加負擔，以便將資源投入于流傳送會話是公平合理的。具體地，客戶機210需要從多個對等體220接收該流媒體，所以，它被連接到這些對等體。另外，客戶機210有動力來有效地協(xié)調或管理對等體200，以便改善其自己的流傳送體驗。因此，這里所描述的PeerStreamer系統(tǒng)和方法利用對松散耦合的P2P網(wǎng)絡中的服務對等體的接收器驅動控制，其中，客戶機負責在各個流對等體之中發(fā)送和協(xié)調數(shù)據(jù)包請求。
2.1系統(tǒng)縱覽如上所述，這里所描述的PeerStreamer提供一種用于松散耦合的P2P網(wǎng)絡的接收器驅動對等(P2P)媒體流傳送系統(tǒng)和方法。該網(wǎng)絡中的對等體只執(zhí)行簡單的操作、可以高速緩存流媒體的全部或一部分、不與其它對等體協(xié)作、可以是不可靠的、以及可以在任何給定的流傳送會話期間脫機或聯(lián)機。該網(wǎng)絡中的客戶機(或接收器)進行實時操作以便協(xié)調對等體、從多個對等體流傳送媒體、執(zhí)行負載平衡、處理對等體的聯(lián)機/脫機狀態(tài)、以及執(zhí)行對流媒體的解碼和呈現(xiàn)。
一般而言，PeerStreamer提供接收器驅動媒體流傳送。PeerStreamer操作始于每個接收客戶機檢索保持有所請求的流媒體的全部或一部分的附近的服務對等體的列表。注意，在該上下文中，媒體服務器也可以擔當服務對等體之一。該列表包括保持服務媒體的完整或部分副本的一組一個或多個相鄰服務對等體的IP地址以及監(jiān)聽端口。用于檢索這個列表的方法包括1)直接從媒體服務器中檢索該列表；2)從已知的服務對等體中檢索該列表；以及3)使用用于識別服務對等體的分布式散列表(DHT)方法。
一旦客戶機檢索到可用服務對等體列表，該客戶機就連接到每個服務對等體，并獲得其“可用性向量”。一般而言，每個服務對等體的可用性向量是每個服務對等體所保持的媒體的確切部分的緊縮描述。然后，該可用性向量被客戶機用來確切地確定服務對等體保持已編碼媒體的什么塊。
例如，在特定服務對等體保持全部服務媒體的情況下，該對等體的可用性向量可以是指出該服務對等體保持完整的媒體副本的單個標志。同樣，如果服務對等體只保持服務媒體的一部分，那么，該服務對等體的可用性向量將用信號通知客戶機，該服務對等體保持媒體的什么部分，例如，由該服務對等體保持的每個數(shù)據(jù)包的塊數(shù)以及塊索引。
另外，在使用諸如以下所描述的各種擦除編碼技術等附加編碼的情況下，可用性向量將包括分配給服務對等體的媒體擦除編碼關鍵字、以及由服務對等體保持的擦除塊的數(shù)目。此外，如果服務對等體使用擦除編碼，并且該媒體也被嵌入編碼，則可用性向量將包括所分配的媒體擦除編碼關鍵字、以及該嵌入編碼所使用的不同比特率級別處的每個數(shù)據(jù)包的擦除塊的數(shù)目。
給定可用性向量，下一步是讓客戶機檢索將要從對等體集群流傳送的媒體的“媒體頭部”和“媒體結構”的長度。在檢索了這些長度之后，客戶機計算媒體頭部和媒體結構的“數(shù)據(jù)單元ID”，并且，作為已分析了每個服務對等體的可用性向量的結果，根據(jù)對于什么對等體具有什么數(shù)據(jù)包ID的了解，來從對等體集群內的一個或多個對等體中檢索它們。
一旦媒體頭部到達，客戶機就分析該媒體頭部，然后配置或初始化解碼和呈現(xiàn)或回放正被流傳送的特定類型媒體(即MPEG 1/2/4、WMA、WMV等)所需要的任何音頻/視頻解碼器和呈現(xiàn)設備。一旦完成了該初始設置階段，客戶機隨后就開始協(xié)調從如下所述的對等體群集的正在進行的媒體主體的流傳送。特別是，給定特定流媒體的前述媒體結構，客戶機計算該流媒體的數(shù)據(jù)包的數(shù)據(jù)單元ID，然后從各個對等體中逐個檢索那些數(shù)據(jù)包。
然后，客戶機周期性地更新服務對等體列表(使用用于識別服務對等體的前述方法之一)，并連接到潛在的新服務對等體。在一個測試實施例中，客戶機通過發(fā)出對于每個潛在的服務對等體的周期性常規(guī)TCP連接函數(shù)的調用，來核對潛在的新服務對等體。在客戶機建立與新服務對等體的連接之后，它首先檢索前述可用性向量。然后，在接收器/客戶機的方向上，該新對等體可以加入群集中的其它活動對等體。然后，客戶機協(xié)調這些對等體、根據(jù)其服務帶寬和內容可用性來平衡這些對等體的服務負載、并將對斷開的或超時的對等體的無法履行的請求重定向到其它活動對等體中的一個或多個。然后，流傳送操作按這個方式繼續(xù)進行，直到全部流媒體被接收，或者該流傳送操作被用戶停止。
2.2系統(tǒng)體系結構縱覽以上概述的過程由圖3中的通用系統(tǒng)框圖來示出。具體地，如這里所描述的，圖3中的系統(tǒng)框圖示出了用于實現(xiàn)PeerStreamer的程序模塊之間的相互關系。應該注意，由圖3中的折線或虛線來表示的任何方框以及方框之間的互連表示這里所描述的PeerStreamer的替換實施例；并且，如下所述，可以結合在這整個文檔中描述的其它替換實施例來使用任何或所有這些替換實施例。
一般而言，通過讓客戶機使用對等體位置模塊305來檢索或識別保持所請求的流媒體的全部或一部分的附近的服務對等體220的列表310，PeerStreamer開始對于每個客戶機210的操作。注意，在該上下文中，媒體服務器200也可以擔當服務對等體220之一。對等體位置模塊305使用各種方法來檢索對等體列表310。例如，在一個實施例中，直接從服務器200提供對等體列表310。在另一個實施例中，從已知的服務對等體220中檢索對等體列表310。最后，在又一個實施例中，對等體位置模塊305使用常規(guī)的分布式散列表(DHT)來識別服務對等體220。如上所述，對等體列表305包括保持服務媒體的完整或部分副本的一個或多個相鄰服務對等體220的IP地址以及監(jiān)聽端口。
服務媒體本身由存在于服務器200上的媒體編碼模塊300通過使用多種常規(guī)編解碼器(包括例如MPEG 1/2/4、WMA、WMV等)中的任何一個來進行編碼。注意，如這里進一步詳細描述的，用來為媒體編碼的編解碼器可以是嵌入的或非嵌入的。另外，在一個實施例中，如以下進一步詳細描述的“高速率擦除彈性編碼”結合任何編解碼器來使用，以提供對本質上不可靠的服務對等體220的提高的健壯性。
最初，所編碼的媒體只存在于最初在其上為該媒體編碼的服務器上。然后，它全部或部分地被分發(fā)給服務對等體220中的一個或多個(再一次，服務器200也可以擔當用于媒體流傳送用途的服務對等體)。對服務對等體220的分發(fā)要么是媒體流的數(shù)據(jù)包對對等體的直接分發(fā)的結果；要么作為當媒體最初被流傳送到該服務對等體時令已流傳送該媒體的一個或多個對等體(當擔當客戶機210時)僅僅高速緩存該媒體的全部或一部分的結果。在任何情況下，出于解釋的目的，假設有多個已知的對等體(如對等體列表310所定義的)，并且，每個對等體保持將要流傳送的已編碼媒體的全部或一部分。
一旦客戶機210檢索了可用服務對等體的列表310，該客戶機就經由從每個對等體中檢索前述可用性向量的可用性向量檢索模塊320連接到每個服務對等體220。接下來，給定每個對等體320的可用性向量的信息，客戶機210隨后使用媒體頭部/媒體結構分析模塊325來檢索關于將要從對等體群集220流傳送的媒體頭部和媒體結構的“媒體頭部”和“媒體結構”的長度。在檢索了這些長度之后，客戶機210分析該媒體頭部，然后使用客戶機配置模塊330來配置或初始化解碼和呈現(xiàn)或回放正被流傳送的特定類型媒體(即MPEG 1/2/4、WMA、WMV等)所需要的任何音頻/視頻解碼器和呈現(xiàn)設備。
此外，媒體頭部/媒體結構分析模塊325也根據(jù)該媒體結構和媒體頭部的分析來確定，在對將要流傳送的媒體進行編碼的過程中，是否已使用嵌入編碼媒體或高速率擦除彈性編碼中的任何一項或兩項。
然后，數(shù)據(jù)單元ID計算模塊335用于基于媒體頭部和媒體結構中所包括的信息來計算流媒體的數(shù)據(jù)包的“數(shù)據(jù)單元ID”。然后，數(shù)據(jù)單元請求模塊340使用所計算的數(shù)據(jù)單元ID向對等體群集220中的各個對等體請求流媒體的特定數(shù)據(jù)包或數(shù)據(jù)塊。
在PeerStreamer使用嵌入編碼媒體的情況下，如以下進一步詳細描述的，流傳送比特率根據(jù)可用的服務帶寬和客戶機隊列狀態(tài)而改變。在此情況下，由數(shù)據(jù)單元請求模塊340提出的對于媒體數(shù)據(jù)包或數(shù)據(jù)單元的檢索的正在進行的請求對應于將基于可用帶寬來提供最小的速率失真的那些數(shù)據(jù)包(或數(shù)據(jù)塊)。另外，在使用高速率擦除彈性編碼的另一情況下，多個服務對等體保持部分媒體而無沖突，以便客戶機僅僅檢索固定數(shù)量的擦除編碼塊，而不管在哪里檢索和檢索什么特定的塊。
在任何情況下，當客戶機210經由數(shù)據(jù)單元處理模塊345來檢索媒體的流傳送塊時，該客戶機將會要么如下所述那樣傳遞將要被解碼的那些數(shù)據(jù)包，要么數(shù)據(jù)單元處理模塊將首先從數(shù)據(jù)塊重建該媒體流的數(shù)據(jù)包(見以下關于高速率擦除編碼的討論)。此外，客戶機210將周期性地更新服務對等體列表310(使用用于識別服務對等體的前述方法之一)。無論何時或按某個所需的頻率更新了列表310，客戶機210將連接到潛在的新服務對等體，以檢索前述可用性向量。然后，在接收器/客戶機210的方向上，該新對等體可以加入群集220中的其它活動對等體。
然后，客戶機210協(xié)調對等體320、根據(jù)其服務帶寬和內容可用性來平衡這些對等體的服務負載、并將斷開的或超時的對等體的無法履行的請求重定向到其它活動對等體中的一個或多個。然后，流傳送操作按這個方式繼續(xù)進行，直到全部流媒體經由解碼/呈現(xiàn)/回放模塊350而被接收、解碼、呈現(xiàn)和回放。注意，經由常規(guī)的顯示設備355和/或揚聲器360來提供已解碼媒體的回放，向這些顯示設備355和/或揚聲器360提供其來自解碼/呈現(xiàn)/回放模塊350的輸入。
3.0操作縱覽上述程序模塊用于實現(xiàn)PeerStreamer。如以上概述，PeerStreamer提供用于松散耦合的P2P網(wǎng)絡的接收器驅動對等(P2P)媒體流傳送。以下各個章節(jié)詳細討論PeerStreamer的操作、以及用于實現(xiàn)根據(jù)圖2而在章節(jié)2中描述的程序模塊的示例性方法。特別地，在詳細描述以下在章節(jié)3.1和3.2中所提供的PeerStreamer操作之后，在圖10中呈現(xiàn)操作流程圖，它鑒于該詳細描述來概述PeerStreamer的總操作。
3.1PeerStreamer的操作細節(jié)以下各段詳述這里所描述的PeerStreamer的特定操作實施例和替換實施例。具體地，以下各段描述PeerStreamer所使用的“流媒體模型”；所請求的流媒體的“媒體結構”(基本上是定義計算用于檢索媒體數(shù)據(jù)包或“數(shù)據(jù)單元”的數(shù)據(jù)ID所需要的流媒體的特征的“伴隨文件”)；表示用于流傳送的媒體數(shù)據(jù)包的固定尺寸部分的PeerStreamer數(shù)據(jù)單元；用于降低存儲要求的媒體的局部高速緩存；用于提高PeerStreamer系統(tǒng)對本質上不可靠的服務對等體的健壯性的媒體的高速率擦除編碼。
3.1.1流媒體模型一般而言，流媒體包括當?shù)竭_時被解碼和呈現(xiàn)的數(shù)據(jù)包流(因此具有名稱流傳送)。若無流傳送，在可以使用它之前，必須以一個大塊下載全部媒體。在圖4中，示出了PeerStreamer所使用的流媒體文件的通用結構。
具體地，如圖4所示的，媒體由“媒體頭部”來引導，它包含描述該媒體的全局信息，例如，該媒體中的通道數(shù)目、每個通道的屬性和特征(音頻采樣率、視頻分辨率/幀速率)、所使用的編解碼器、該媒體的作者/版權持有者等。通常在流傳送會話開始之前下載媒體頭部，以便客戶機可以設立這些必要的工具來對隨后接收的數(shù)據(jù)包進行解碼和呈現(xiàn)。注意，流媒體可以包括幾個通道，其中每個通道是可以被獨立地選擇和解碼的單獨的媒體分量，例如，英語音軌、西班牙語音軌、4∶3視頻、16∶9視頻等。
媒體頭部后面是媒體數(shù)據(jù)包序列，其中每個媒體數(shù)據(jù)包包含跨越短時期的某個通道的壓縮比特流。每個媒體數(shù)據(jù)包由數(shù)據(jù)包頭部來引導，它包含諸如通道索引、數(shù)據(jù)包的起始時間標記、數(shù)據(jù)包的持續(xù)時間、以及標志數(shù)量等信息，例如，該數(shù)據(jù)包是否是關鍵幀(例如，MPEG I幀)、該數(shù)據(jù)包是否是嵌入編碼的數(shù)據(jù)包(具有可截斷的比特流)等等。然后是數(shù)據(jù)包的壓縮比特流。
如今大多數(shù)的常規(guī)壓縮媒體編解碼器(例如，MPEG1/2/4音頻/視頻、WMA/WMV、RealAudio/Realvideo等)生成非嵌入的編碼媒體數(shù)據(jù)包。因此，無法更改這類系統(tǒng)所生成的媒體數(shù)據(jù)包的大小。而且，只要這一比特流中的媒體數(shù)據(jù)包之一被丟失或被過度延遲，結果都是，要么該媒體不是可解碼的，要么該回放變得紊亂或間斷，從而降低流媒體的回放質量。為了保持與這些常規(guī)編解碼器相兼容，在一個實施例中，PeerStreamer系統(tǒng)和方法允許媒體數(shù)據(jù)包是非嵌入編碼的(不可縮放)。但是，除了支持傳統(tǒng)的壓縮媒體格式以外，PeerStreamer在一個實施例中也支持嵌入的編碼媒體。
利用嵌入的編碼媒體，每個媒體數(shù)據(jù)包按可以被獨立地向后截斷的方法來編碼。一般而言，兩種類型的嵌入編碼得到PeerStreamer的支持——位平面編碼和增強層編碼。注意，對本領域的技術人而言，這兩種類型的嵌入編碼都是公知的。因此，在以下各段中，將只概括地描述這些編碼。
例如，利用位平面編碼，通常通過逐個位平面地(從最高位平面(MSB)到最低位平面(LSB))對音頻/視頻變換系數(shù)塊進行編碼，來實現(xiàn)媒體塊的可縮放編碼。如果在編碼之后截斷比特流，那么，為所有這些系數(shù)的最高位平面中的幾個保留該信息。而且，被截斷的比特流對應于較低比特率的壓縮比特流，它可以被認為是嵌入在較高比特率壓縮的比特流中，因而是具有名稱嵌入編碼。結果，可以截斷該嵌入編碼器所生成的媒體數(shù)據(jù)包，具有適度的速率-失真折衷。
利用增強層編碼，媒體內容被壓縮成基層以及一個或多個增強層，其中每個層通常占據(jù)單獨的通道。具體地，這類編碼允許將要接收的最低質量媒體流預訂該基層。隨著每個接連的增強層的添加，解碼的媒體質量得到改善。因此，利用這類系統(tǒng)，取決于可用帶寬，并通過預訂基層和盡可能多的增強層，接收器或客戶機通常可優(yōu)化所接收的信息的質量。
3.1.2PeerStreamer媒體結構為了在接收器驅動模式中進行操作，PeerStreamer客戶機需要知道將要被請求的媒體數(shù)據(jù)包的結構，以便它可以知道向每個對等體請求什么數(shù)據(jù)包和每個數(shù)據(jù)包的什么部分。該信息在一“伴隨文件”中提供，該“伴隨文件”包括將要被請求的流媒體的結構的定義。一般而言，該媒體結構為PeerStreamer客戶機提供整個媒體的概觀(例如，每個數(shù)據(jù)包的起始時間標記、每個數(shù)據(jù)包的持續(xù)時間等)，以便它可以智能地計劃P2P流傳送會話，并確保特定的媒體數(shù)據(jù)包及時到達以供解碼和呈現(xiàn)。注意，在原先為媒體文件編碼時，最初生成包含媒體結構信息的伴隨文件；然后，該伴隨文件在每個流傳送會話的起始處請求時，連同該媒體頭部的初始請求一起被流傳送到客戶機。注意，在由常規(guī)編解碼器為該媒體編碼之后，通過分析該媒體頭部和數(shù)據(jù)包頭部，也可以生成伴隨文件中的信息。
具體地，一組數(shù)據(jù)包的媒體結構由數(shù)據(jù)包頭部加上數(shù)據(jù)包比特流長度組成。因此，該信息可以由客戶機用來確定應該請求哪些特定的數(shù)據(jù)包、應該請求那些數(shù)據(jù)包的時間、以及應該向其請求那些數(shù)據(jù)包的對等體。因此，PeerStreamer在流“設置”階段首先檢索全部媒體的媒體結構。通過在實際上流傳送媒體之前檢索信息，可引起流設置中的小延遲。但是，通過在媒體流傳送之前首先檢索信息，在帶寬方面沒有用于將媒體結構信息供應給客戶機的額外成本(在媒體流傳送期間)。
注意，相對于流媒體的總長度而言，起始流中的前述延遲通常很小。例如，在PeerStreamer的一個測試實施例中，大小范圍從31兆字節(jié)(MB)到49MB的五個測試影片剪輯具有在大約37千字節(jié)(KB)至大約53KB的范圍內的媒體結構伴隨文件。所以，觀察到，該媒體結構大小是總媒體主體的大約0.10-0.15％的數(shù)量級。所以，假設服務帶寬大于或等于媒體比特率，并且媒體結構是媒體主體的0.15％，那么，下載10分鐘剪輯的媒體結構會引起少于0.9s的額外的延遲。
在一個相關實施例中，為某個預定長度(即10秒、30秒、1分鐘等)的順序媒體段生成局部媒體結構。然后，在對應的媒體段將要在不遠的將來被流傳送之前，只檢索每個局部媒體結構。這略微增加帶寬要求，因為媒體結構請求和傳輸可以與媒體數(shù)據(jù)包請求和傳輸共存。但是，由于媒體結構的大小在此情況下是如此小，因此，通?？梢院雎詫θ繋捯蟮挠绊憽?br> 3.1.3PeerStreamer數(shù)據(jù)單元在一個實施例中，PeerStreamer將媒體數(shù)據(jù)包、媒體頭部和媒體結構分成長度為L的各個固定大小數(shù)據(jù)單元。使用固定大小數(shù)據(jù)單元的原因是，PeerStreamer客戶機和服務對等體隨后可以預先分配大小為L的存儲器塊，從而在流過程期間避免費用昂貴的存儲器分配操作。另外，通過將媒體數(shù)據(jù)包(潛在地說，很大)分成小的固定大小數(shù)據(jù)單元，也可允許PeerStreamer客戶機將服務負載分配給具有較小粒度的對等體，從而在這些對等體之中實現(xiàn)更好的帶寬負載平衡。
一般而言，通過將每個數(shù)據(jù)包分成 個數(shù)據(jù)單元，來將長度為P的數(shù)據(jù)包(可以是媒體數(shù)據(jù)包、媒體頭部或媒體結構)分成大小為L的塊，其中， 是返回大于或等于x的最小整數(shù)的常規(guī)天棚函數(shù)。于是，所有數(shù)據(jù)單元具有固定長度L，潛在地除每個數(shù)據(jù)包的最后一個的數(shù)據(jù)單元以外(其長度是P mod L)。
在使用媒體的非嵌入編碼的情況下，在網(wǎng)絡傳輸期間，不能丟棄構成每個媒體數(shù)據(jù)包的數(shù)據(jù)單元而不降低媒體回放質量。所以，這些數(shù)據(jù)包被指定為“必要數(shù)據(jù)單元”，因為它們都必須加以接收。
相反，當嵌入編碼媒體數(shù)據(jù)包被分成各個數(shù)據(jù)單元時，只有基層數(shù)據(jù)單元必須被傳遞，并且，如果服務帶寬不足夠，那么，可以隨意地丟棄剩余的數(shù)據(jù)單元。這些可任選的數(shù)據(jù)單元被指定為“非必要數(shù)據(jù)單元”。這些非必要數(shù)據(jù)單元的服務所要求的帶寬可以被計算如下。例如，在嵌入編碼的情況下，媒體數(shù)據(jù)包將持續(xù)T秒。假設媒體數(shù)據(jù)包被分成多個數(shù)據(jù)單元，那么，為了將層i處的數(shù)據(jù)單元供應給客戶機，也必須將層i以下的所有數(shù)據(jù)單元供應給客戶機。結果，供應層i處的數(shù)據(jù)單元所要求的服務帶寬是Ri＝(i+1)L/T 公式1所以，公式1提供當考慮到嵌入編碼媒體時數(shù)據(jù)單元的比特率R。然后，通過丟棄可能會導致可用服務帶寬超過的比特率的非必要數(shù)據(jù)單元，PeerStreamer客戶機可調整成更改服務帶寬。
在任何情況下，無論媒體被非嵌入編碼還是被嵌入編碼，特定媒體流的所有數(shù)據(jù)單元，包括媒體數(shù)據(jù)包、媒體頭部和媒體結構的據(jù)單元，都被映射到唯一的ID空間。例如，在一個測試實施例中，媒體數(shù)據(jù)包的數(shù)據(jù)單元從0x00000000到0xfdffffff(十六進制)索引，媒體頭部的數(shù)據(jù)單元從0xfe000000-0xfeffffff編入索引，媒體結構的數(shù)據(jù)單元從0xff000000-0xffffffff編入索引。這個測試實施例中所使用的數(shù)據(jù)單元是關于圖5中所示的PeerStreamer。
注意，為了獲得媒體頭部和媒體結構的數(shù)據(jù)單元ID，首先需要媒體頭部和媒體結構的長度。這些被稱作它們的“兆結構(mega-structure)”。為了獲得媒體數(shù)據(jù)包的數(shù)據(jù)單元ID，需要媒體數(shù)據(jù)包比特流的長度。該信息被包括在媒體結構中。
3.1.4媒體的局部高速緩存出于服務目的，每個服務對等體只需要保持與其服務帶寬成比例的媒體的一部分。與因特網(wǎng)連接的大多數(shù)計算機的服務(或上傳帶寬)常常實質上小于其下載帶寬(規(guī)定每個特定節(jié)點可以接收的最高流傳送比特率)。因此，因特網(wǎng)上的每個最終用戶節(jié)點往往在其上傳帶寬與其下載帶寬之間具有不平衡。例如，給定家庭用戶可以獲得的典型商業(yè)ADSL/電纜調制解調器網(wǎng)絡上的節(jié)點，那么，下載帶寬比其上傳帶寬高一個數(shù)量級并非是不平常的。同樣，校園/企業(yè)網(wǎng)上的節(jié)點通常已改進了服務帶寬，以便任何給定節(jié)點參與P2P類型活動都不會影響其它任務關鍵功能。
因此，由于每個服務對等體通常不能夠個別地將全部媒體流供應給客戶機，因此，不需要將全部媒體流高速緩存在任何一個服務對等體上。所以，用于減少服務對等體中的任一個所要求的存儲資源數(shù)量的有效方法是允許每個服務對等體只保持將要被流傳送的媒體的一部分。例如，如果流傳送非嵌入編碼媒體所需要的比特率是R，并且，流傳送會話中的對等體所提供的最大服務帶寬是B，那么，每個對等體節(jié)點只需要在其高速緩存中保持該流媒體的p部分，其中的值p由公式2來表示p＝max(1.0，B/R) 公式2例如，假設媒體比特率是服務帶寬的兩倍，即，R＝2B。然后，服務對等體只需要在其存儲器中保持該流媒體的一半，因為該對等體無法獨自按完全的流傳送比特率來服務于客戶機。實際上，給定這個例子的前述限制，該對等體所能夠做得最好的是至多提供該媒體的一半。因此，該對等體只需要在其高速緩存中保持該媒體的一半。然后，將要被流傳送的媒體的其余部分必須由其它服務對等體來提供。
另外，然后應該注意，公式1和2的組合隨后允許確定為使用嵌入編碼媒體的情況而保持的媒體量。如以上章節(jié)3.1.3中所討論的，嵌入編碼媒體的媒體數(shù)據(jù)包被分成具有不同的比特率的多個數(shù)據(jù)單元。所以，R是特定層L的數(shù)據(jù)單元的比特率，公式2現(xiàn)在給出將要為該數(shù)據(jù)單元而保持的媒體的部分。例如，如圖6所示，嵌入媒體數(shù)據(jù)包可以被分成多個數(shù)據(jù)單元(在這個例子中是8個)。如圖6所示，需要為每個數(shù)據(jù)單元(具有L/T＝0.5B)高速緩存的媒體量被示出為然后根據(jù)公式2來確定。
但是，在一個實施例中，在特定服務對等體的存儲資源足夠大的情況下，該服務對等體可以通過僅僅使用公式2中的較高的“潛在服務帶寬”B′，來選擇高速緩存該媒體的一個較大的部分。然后，被高速緩存的媒體的該額外部分允許按不連貫的、但高質量的方式來供應該媒體。例如，假設每個服務對等體選擇使用其實際服務帶寬兩倍的潛在服務帶寬B′(即，B′＝2B)，那么，該P2P網(wǎng)絡中的所得的媒體量將足夠客戶機按流傳送速率的一半來檢索該媒體。換言之，假設所有這些可用對等體的合計服務帶寬大于R/2，那么，客戶機應該能夠首先下載該媒體的一半，然后連續(xù)不斷地流傳送剩余的一半傳送并對其進行回放。同樣，客戶機也可以選擇下載該媒體的Ts/2片段(具有時間Ts)、連續(xù)不斷地流傳送另一個Ts/2片段并回放該片段、然后下載另一個片段并流傳送它。這樣，該流媒體可以按速率R來回放(縱使按不連貫的方式)。
3.1.5媒體的高速率擦除編碼如上所述，對等體可能本質上是不可靠的。因此，有利的是提供用于在PeerStreamer系統(tǒng)和方法中提供增加的冗余度的某個手段，以便有效地處理服務對等體的本質上不可靠的服務行為。對這個問題的處理提出了必須解決的許多關注問題。例如，確定該媒體的哪個部分p應該由每個對等體來保持是所關注的。另外，由于媒體最終被分成前述數(shù)據(jù)單元，因此，確定每個對等體應該保持這些數(shù)據(jù)單元的哪個部分p也是所關注的。
解渙這些問顥的一個簧略星僅僅將每個數(shù)據(jù)單元分成k個塊。保持該媒體的p部分的對等體隨后可以隨機地保持 個塊， 是前述天棚函數(shù)。但是，對于這個方案的隨機性的一個問題是即使對等體群集中存在比k個塊多得多的塊，該群集作為一個整體也可能會缺乏特定的塊j，從而致使整個數(shù)據(jù)單元無法恢復。另外，在這種方案中，客戶機仍然負責定位來自這些對等體的每個截然不同的塊，這使客戶機與對等體之間的協(xié)議設計復雜化。
因此，更好的策略是，使用“高速率擦除彈性代碼”來確保對等體中的一個或多個將具有重建特定的數(shù)據(jù)單元所必要的數(shù)據(jù)塊，同時簡化客戶機上識別對等體中的哪個對等體包含該必要數(shù)據(jù)的要求。一般而言，擦除彈性代碼是具有參數(shù)(n，k)的塊糾錯碼，其中，k是原始消息的數(shù)目，n是編碼消的息的數(shù)目。高速率擦除彈性代碼滿足n比k大得多的屬性；這樣，k個原始消息被擴大為n個消息的大得多的編碼消息空間。盡管擦除編碼技術一般被公認為用于為數(shù)據(jù)編碼，但如這里所描述的，該技術在P2P網(wǎng)絡環(huán)境中流傳送媒體的應用是未知的。
作為分組糾錯碼，可以通過伽羅瓦域(Galois Field)GF(p)上的矩陣乘法來描述高速率擦除彈性代碼的操作c0c1······cn-1=Gx0x1···xk-1,]]>公式3其中，p是伽羅瓦域的階，{x0，x1，…，xk-1}是原始消息，{c0，c1，…，cn-1}是編碼的消息，G是生成矩陣。注意，公式3不用來立即生成所有編碼的消息。而是生成矩陣G定義已編碼消息空間。所以，當客戶機接收k個編碼的消息{c′0，c′1，…，c′k-1}時，它們可以被公式4表示為c′0c′1···c′k-1=Gkx0x1···xk-1,]]>公式4其中，Gk是對應于已編碼消息的、生成矩陣G的k行所形成的子生成矩陣。另外，如果子生成矩陣Gk具有滿秩k，那么，矩陣Gk可以被求逆，從而可以為原始消息解碼。
可以使用幾種眾所周知的擦除編碼技術，包括(例如)Reed-Solomon擦除碼、tornado碼和LPDC碼。但是，在一個實施例中，PeerStreamer基于伽羅瓦域GF(216)上的修改Reed-Solomon碼來提供一種新的高速率擦除彈性代碼。在這個例子中，原始消息的數(shù)目k是16。已編碼消息空間的大小n是216＝65536。Reed-Solomon碼是最大距離可分(MDS)碼。因此，生成矩陣G的任何16行形成具有滿秩16的子生成矩陣。換言之，可以從任何16個已編碼消息中恢復原始消息。應該注意，也可以使用其它域大小p；并且，PeerStreamer不局限于這里所描述的特定域大小的運用。另外，對于使用非MDS擦除編碼的實施例，取決于所使用的特定擦除編碼，可能有必要檢索k′≥k個塊，以恢復原始消息。使用基于Reed-Solomon的擦除代碼部分是因為它們是MDS碼，并且，它們可以被有效地編碼和解碼，同時，只將很少的計算額外開銷施加于大多數(shù)常規(guī)計算機的CPU上。
利用高速率(n，k)擦除彈性代碼，為每個對等體節(jié)點分配n的已編碼消息空間中的k個關鍵字，每個關鍵字是生成矩陣G的行索引。關鍵字分配可以由服務器來執(zhí)行。另外，如果高速緩存該媒體的對等體的數(shù)目小于n/k，那么，可以為每個對等體分配一組唯一的關鍵字。結果，可以保證每個對等體保持與眾不同的已編碼消息。這個策略提供許多好處，但它仍然要求中心協(xié)調節(jié)點(例如，服務器)。
因此，在另一個實施例中，通過允許每個對等體選擇k個隨機關鍵字，來消除中心協(xié)調節(jié)點的這個角色。如果對等體節(jié)點的數(shù)目大于n/k，或者沒有利用中心協(xié)調節(jié)點來分配關鍵字，那么，某些對等體節(jié)點可以保持相同的關鍵字。然而，在其中客戶機被連接到m個對等體的大多數(shù)媒體流傳送會話中，m通常比n/k小得多。所以，兩個服務對等體碰巧保持相同的關鍵字，并且因此這些對等體之一的一個關鍵字無用的概率很小。但是，即使有關鍵字沖突，當客戶機首先連接到對等體時，它也可以容易地識別這類沖突。在識別這種沖突的情況下，該客戶機僅僅在流傳送會話的剩余部分內使這些重復的關鍵字中的一個無效。因此，客戶機不需要實際上在流過程期間處理關鍵字沖突。
例如，假設S1和S2分別是服務對等體1和服務對等體2的擦除編碼關鍵字空間，并且S1＝{1，7，23，43，48)，S2＝{3，7，28，49，99)。顯而易見，關鍵字空間S1和S2是不同的。但是，關鍵字7由這兩個關鍵字空間來共享，所以，服務對等體1和服務對等體2可以保持共享同一關鍵字(即關鍵字“7”)的擦除編碼塊。所以，在請求特定編碼塊之前，根據(jù)服務對等體之一來使關鍵字“7”無效，以便只從這些對等體之一中檢索由關鍵字“7”編碼的那個塊，從而避免由重復關鍵字引起的任何解碼沖突。但是，應該注意，在一個服務對等體在媒體流傳送操作期間脫機的情況下，如果作為使用一個或多個重復關鍵字的結果該脫機服務對等體以前處于沖突狀態(tài)，那么，可以使另一個服務對等體的特定的已無效編碼關鍵字重新生效。
利用(65536，16)Reed-Solomon碼，每個數(shù)據(jù)單元被分割成16個塊。通過使用一組預先分配的關鍵字，該對等體選擇高速緩存 個擦除編碼塊，其中，p是從公式1和2中計算的參數(shù)。被分配給該對等體的關鍵字、以及其最大服務帶寬B組成該對等體的前述可用性向量，因為客戶機可以通過使用該對等體可用性向量所提供的信息來確定該對等體保持多少和什么擦除編碼塊(按數(shù)據(jù)單元/塊ID)。再一次，在最初連接每個對等體的時候，客戶機解決任何關鍵字沖突。在流傳送會話期間，客戶機隨后可以從任何服務對等體節(jié)點中檢索任何k個已編碼消息，并對相關聯(lián)的數(shù)據(jù)單元進行解碼。
另外，沒有必要將用于為特定數(shù)據(jù)單元解碼的編碼塊的整個集合存儲在任何一個服務對等體上。換言之，對于任何特定數(shù)據(jù)單元的任何特定服務對等體所保持的塊的數(shù)目可能小于k。所以，在一個實施例中，只生成實際上正被傳遞到特定對等體的那些編碼塊，而不是浪費計算能力來計算每個編碼關鍵字的每個已編碼塊。換言之，如果j＜k個塊被存儲在特定的服務對等體上，那么，只應該為特定數(shù)據(jù)單元生成j個塊。
3.2P2P網(wǎng)絡中的PeerStreamer操作的實現(xiàn)在以下各段中，鑒于前面對PeerStreamer的操作細節(jié)的討論，來描述PeerStreamer操作的實現(xiàn)。具體地，以下各段描述客戶機對服務對等體的定位；基于所檢索的媒體結構的客戶機解碼和呈現(xiàn)的設置；PeerStreamer網(wǎng)絡連接；流傳送比特率控制；PeerStreamer客戶機請求和對等體答復；以及，最后是PeerStreamer請求和分級隊列。
3.2.1定位服務對等體如上所述，客戶機所執(zhí)行的第一項任務是獲得保持服務媒體的完整或部分副本的相鄰服務對等體的列表的IP地址以及監(jiān)聽端口。另外，該列表也在媒體流傳送會話期間被更新。如以上所解釋的，用于獲得該列表的一般方法包括1)從服務器中檢索該列表；2)從已知的服務對等體中檢索該列表；以及3)在預先既不知道媒體服務器，也不知道服務對等體的情況下，使用用于識別服務對等體的分布式散列表(DHT)方法。
3.2.2解碼和呈現(xiàn)設置在獲得服務對等體列表之后，客戶機試圖連接到這些服務對等體中的每一個。如上所述，一旦被連接，客戶機就檢索每個對等體的可用性向量，并解決任何關鍵字沖突。然后該客戶機從這些對等體之一中檢索媒體頭部和媒體結構的長度。在檢索了這兩個長度之后，構造媒體頭部和媒體結構的數(shù)據(jù)單元的ID。然后，按如章節(jié)3.2.6中進一步詳細描述的P2P方式來檢索媒體頭部和媒體結構。一旦檢索了媒體頭部，客戶機就確定應該對哪些解碼器和呈現(xiàn)器進行初始化，以便在將媒體流傳送到客戶機時對它進行解碼和呈現(xiàn)。
在使用DirectXTM來實現(xiàn)的一個測試實施例中，該設置通過首先根據(jù)媒體頭部中所提供的信息來構造DirectShowTM過濾器圖來實現(xiàn)。應該注意，這里所描述的PeerStreamer不局限于使用DirectXTM功能的實現(xiàn)，并且，只出于解釋的目的來提供DirectXTM的運用及其相對于測試實施例的討論，用于描述在為客戶機回放而解碼和呈現(xiàn)流媒體的過程中客戶機計算機的設置。
所以，假設客戶機設置的DirectXTM實現(xiàn)，客戶機的網(wǎng)絡組件由DirectShowTM網(wǎng)絡源過濾器來表示，其輸出被饋入正確的音頻/視頻解碼器DirectXTM媒體對象(DMO)。然后，該DMO被進一步連接到適當?shù)囊纛l/視頻呈現(xiàn)設備。例如，圖7示出了客戶機PeerStreamer媒體流傳送會話的示例DirectShowTM過濾器圖。在這個例子中，流媒體被非嵌入編碼。音頻比特流按WMA壓縮，視頻比特流按MPEG-4壓縮。
經由DirectShowTM框架來使用和執(zhí)行PeerStreamer客戶機設置的一個優(yōu)點是，它可以使用在DirectShowTM之下開發(fā)的巨大的現(xiàn)有音頻/視頻編碼器/解碼器庫。例如，利用DirectShowTM，PeerStreamer客戶機能夠解碼和呈現(xiàn)由各種編解碼器(包括例如MPEG 1/2/4、WMA/WMV、Indeo Video等)或具有DirectShowTM解碼器DMO組件的任何其它編解碼器來編碼的媒體。DirectShowTM也提供附加的音頻/視頻處理模塊，例如，分辨率/色彩空間轉換和解除交錯，以便所解碼的音頻/視頻可以自動與客戶機的音頻/視頻呈現(xiàn)設備的性能相匹配。
另外，DirectShowTM自動處理音頻/視頻軌道的同步。例如，在音頻流保持全部流的參考時鐘的情況下，當播放流視頻時，DirectShowTM確保該視頻流的系統(tǒng)定時時鐘盡可能接近于用于解決諸如嘴唇同步等問題的音頻流時鐘。最后，DirectShow應用程序本質上是多線程的。因此，在多處理器PC(或啟用了超線程的PC)上，客戶機的各個組件(例如，網(wǎng)絡組件、音頻解碼器、視頻解碼器和音頻/視頻呈現(xiàn)引擎等)的計算負載可以被分發(fā)到多個處理器上。這大大加速了客戶機的執(zhí)行，并允許使用更復雜的音頻/視頻解碼器。
最后，也應該注意，這里所描述的PeerStreamer不局限于使用DirectXTM功能的實現(xiàn)；并且，出于解釋的目的，提供了DirectXTM的運用及其相對于測試實施例的討論，只用于描述在為客戶機回放而解碼和呈現(xiàn)流媒體的過程中客戶機計算機的設置。
3.2.3PeerStreamer網(wǎng)絡鏈路和數(shù)據(jù)包丟失管理大多數(shù)媒體流客戶機，例如，Windows媒體播放器或RealPlayer，使用在UDP之上所攜帶的公知的實時傳送協(xié)議(RTP)。通常為媒體流應用程序選擇UDP/RTP，這是因為1)UDP協(xié)議支持IP多點傳送，它在將媒體發(fā)送到啟用了IP多點傳送的網(wǎng)絡上的一組節(jié)點的過程中會是有效率的；以及2)UDP協(xié)議不具有任何重發(fā)或數(shù)據(jù)速率管理功能。因此，流傳送服務器和客戶機可以實現(xiàn)諸如前向糾錯(FEC)等高級數(shù)據(jù)包傳遞功能，以確保媒體數(shù)據(jù)包的及時傳遞。
但是，與以上所標識的公知的媒體流傳送方案對比而言，PeerStreamer將TCP連接用作客戶機與服務對等體之間的網(wǎng)絡鏈路。選擇TCP連接而不是常規(guī)的UDP/RTP協(xié)議的一個原因是，由于諸如域內路由協(xié)議、ISP商業(yè)模型(收費模型)、沿分布樹的擁塞控制等問題，在現(xiàn)實世界中，沒有廣泛地采用IP多點傳送。
此外，與許多商業(yè)媒體播放器一樣，PeerStreamer客戶機并入流媒體緩沖區(qū)(在測試實施例中是4s)，以防止諸如抖動和擁塞等網(wǎng)絡異常。實際上，給定比客戶機與服務對等體之間的往返時間(RTT)大許多倍的流媒體緩沖區(qū)，那么，TCP ARQ(自動化重復請求)機制對于媒體數(shù)據(jù)包在充分的時間內的傳遞而言足夠好，以便提供流媒體的流暢的回放。
一般而言，有三種公知的機制(具有大量公知的變體)用于解決媒體數(shù)據(jù)包丟失。例如，這些機制通常包括FEC、選擇性數(shù)據(jù)包重發(fā)、以及自動重復請求(ARQ)。PeerStreamer可以使用所有這些數(shù)據(jù)包丟失機制中的任一種。但是，如以下所解釋的，使用特定的機制有勝過其它機制的各種優(yōu)點。
具體地，對于可以被認為是具有變化的特征和未知的數(shù)據(jù)包丟失率的擦除通道的因特網(wǎng)信道，固定的FEC方案要么浪費帶寬(具有太多的保護)，要么無法恢復丟失的數(shù)據(jù)包(具有太少的保護)。這樣，它未能有效地利用客戶機與對等體之間的帶寬資源。所以，利用比RTT大許多倍的流傳送緩沖區(qū)、以及因而關于重發(fā)的許多機會，基于重發(fā)的出錯防止(例如，選擇性重發(fā)和ARQ)比FEC更可取。
考慮到ARQ和選擇性重發(fā)，可見到，在使用TCP協(xié)議的因特網(wǎng)信道中，只有當許多數(shù)據(jù)包沒有被選擇來重發(fā)的時候，選擇性重發(fā)將比ARQ強。對于非嵌入編碼媒體，丟失的數(shù)據(jù)包通常會導致嚴重的回放降級，包括無法解碼和提供特定數(shù)據(jù)包的回放。所以，丟失的數(shù)據(jù)包幾乎總是被重發(fā)。相反，利用嵌入編碼媒體，丟失的數(shù)據(jù)包可能不會妨礙媒體回放。但是，隨機數(shù)據(jù)包的丟失仍然會使許多導出的數(shù)據(jù)包變得不可用。結果，只有最高增強層數(shù)據(jù)包可能不會被選擇來重發(fā)。
與選擇性重發(fā)相比較，一旦請求數(shù)據(jù)包，ARQ總是重發(fā)它們；即使它們屬于最高增強層。然而，ARQ方案可以選擇不請求隨后媒體數(shù)據(jù)包的最高增強層數(shù)據(jù)包，從而利用選擇性傳輸方案來實現(xiàn)相同的帶寬使用率和察覺到的媒體回放質量。因此，除非網(wǎng)絡條件變化非常迅速，否則，TCP協(xié)議所使用的ARQ機制足以處理媒體流傳送中的數(shù)據(jù)包丟失。
將TCP用作網(wǎng)絡協(xié)議也可提供勝過諸如以上所標識的常規(guī)媒體流傳送方案的幾個額外的好處。例如，利用TCP，不需要明確地處理流量控制、吞吐量估算、擁塞控制和避免、?；?keep alive)等等。所有這些問題由TCP協(xié)議來自動處理。TCP協(xié)議也可以檢測脫機的對等體，并適度地處理該對等體與客戶機之間的連接鏈路的關閉。
3.2.4具有嵌入編碼的PeerStreamer流傳送比特率控制非嵌入編碼的媒體較佳地總是按該媒體的比特率來流傳送，以避免在客戶機處的媒體回放降級。但是，嵌入編碼媒體的流傳送比特率可以在流傳送會話期間變化。
所以，在一個實施例中，每個嵌入編碼媒體數(shù)據(jù)包的流傳送比特率Rrecv首先由公式5、6和7來計算，如下所示Rraw＝Th·(1+Trft-Tstaging)+Bstaging-Boutstanding公式5Rfilter＝(1-α)Rfilter+αRraw公式6Rrecv＝min(Rmin，Rinst) 公式7其中，Th是多個服務對等體的總計的服務帶寬，Tstaging是目標分級緩沖區(qū)大小(在測試實施例中具有默認值2.5s)，Trft是所需的請求履行時間(在測試實施例中具有默認值1.0s)，Bstaging是分級隊列中所接收的數(shù)據(jù)包的長度，Boutstanding是將要被接收的未完成答復的長度，Rmin是基層比特率(只具有必要數(shù)據(jù)單元)，α是低通控制參數(shù)。
然后，使用公式5-7的結果來通過以下總計的服務帶寬Th、以及各個分級和請求隊列狀態(tài)而控制流傳送比特率Rrecv，這些分級和請求隊列狀態(tài)在以下章節(jié)3.2.6中進一步詳細描述。一旦確定該流傳送比特率，客戶機就只發(fā)出對具有低于流傳送比特率Rrecv的比特率的數(shù)據(jù)單元的請求。
在一個相關實施例中，通過也考慮數(shù)據(jù)單元的失真作用，使用更高級的策略來控制比特率Rrecv。但是，這要求客戶機獲得對數(shù)據(jù)單元的失真(或碼率失真斜率)的訪問，它必須被包括在媒體結構中并被發(fā)送到客戶機。但是，與媒體結構中的現(xiàn)有信息不同，數(shù)據(jù)單元的失真在解碼的過程中是不需要的，因而被認為是額外開銷。因此，它是將要被發(fā)送到客戶機的額外開銷量與速率控制準確度之間的折衷。
3.2.5PeerStreamer數(shù)據(jù)塊請求和答復圖8概括地示出了客戶機數(shù)據(jù)塊請求及其對對等體的答復的使用期限。具體地，如圖8所示，客戶機生成該請求，并通過出站TCP連接來將它發(fā)送到特定的服務對等體。另外，在網(wǎng)絡傳遞中，TCP可以將該請求與發(fā)給同一對等體的原先的請求捆綁在一起。如果原先的請求在傳輸過程中丟失，那么，TCP也處理該請求的重發(fā)。
在數(shù)據(jù)包請求被傳遞到對等體之后，它被存儲在該服務對等體的TCP接收緩沖區(qū)中。然后，該對等體處理這些請求，每次處理一個請求。對于每個請求，對等體從其磁盤或記憶存儲中讀取所請求的塊(可能被或可能不被擦除編碼，取決于所使用的編碼)，并將所請求的內容發(fā)回到客戶機。倘若從服務對等體到客戶機的TCP套接字被阻斷(即，不再有帶寬可用)，那么，服務對等體將阻斷進一步的客戶機請求，直到TCP連接打開為止。
客戶機發(fā)出請求的時間與客戶機接收其答復的時間之間的間隔被定義為請求履行時間(RFT)。請求通常比其答復小得多，并且，與用來發(fā)回內容的網(wǎng)絡傳遞時間相比，處理請求的過程中所涉及的操作(例如，磁盤讀取)通常是不重要的。所以，請求的RFT-Trft由公式8來計算，如下所示Trft′＝(Bi，outstanding+Bcur)/Thi公式8其中，Thi是對等體i的服務帶寬，Bi，outstanding是在該請求之前的未被接收的答復的長度，Bcur是所請求的內容的長度。所以，RFT是根據(jù)對等體的服務帶寬、請求的大小、以及來自該對等體的未被接收的內容的大小來確定的。
一旦所請求的內容數(shù)據(jù)包到達客戶機處，它就被立即移動到分級隊列。在該分級隊列中，來自多個對等體的數(shù)據(jù)塊(可以包括擦除編碼塊)被組合和解碼為數(shù)據(jù)單元，這些數(shù)據(jù)單元被進一步組合成媒體數(shù)據(jù)包。客戶機周期性地從分級隊列中除去所傳遞的媒體數(shù)據(jù)包，并將它們壓入對應的音頻/視頻解碼器。在媒體數(shù)據(jù)包被解碼器解壓之后，未壓縮的音頻/視頻數(shù)據(jù)流被發(fā)送到音頻/視頻呈現(xiàn)單元，用于客戶機回放設備(監(jiān)視器、揚聲器等)上的流回放。
在一個實施例中，圖8中所示的緩沖區(qū)用來防止網(wǎng)絡異常(例如，數(shù)據(jù)包丟失和抖動)。
(但是，當使用DirectShowTM實現(xiàn)時，未壓縮的音頻/視頻緩沖區(qū)在DirectShow過濾器圖的控制之下，并且是不可編程的。)在PeerStreamer的一個測試實施例中，分級緩沖區(qū)的大小被設為Tstaging＝2.5s，所需的RFT被設為Trft＝1.0s，并且，所壓縮的音頻/視頻緩沖區(qū)被設為0.5s。因此，在這個測試實施例中，PeerStreamer客戶機的總緩沖區(qū)因而大約是4s。
在其中使用擦除編碼的實施例中，每個數(shù)據(jù)塊請求被明確地表達為某個數(shù)據(jù)單元的一組擦除編碼塊的請求。可以利用起始塊索引和所請求的塊的數(shù)量來標識該擦除編碼塊組?？梢酝ㄟ^32位ID來標識該數(shù)據(jù)單元。該請求因而采取以下形式Data_Unit_ID[32]，Start_Index[4]，Number_of_Blocks[4]公式9其中，括號中的數(shù)字是每個分量的比特數(shù)。
所以，如公式9所示，在擦除編碼塊的情況下，每個請求是5字節(jié)長。另一方面，所請求的內容在大小方面的范圍是128～2048個字節(jié)(數(shù)據(jù)單元長度L＝2048，k＝16)。結果，請求的大小只是答復的大約0.24％～3.91％。所以，客戶機用于發(fā)送請求的上傳帶寬的量相對于請求的內容而言非常小。
3.2.6PeerStreamer請求和分級隊列如上所述，PeerStreamer客戶機維持單個分級隊列，以保持所接收的數(shù)據(jù)塊(可以被擦除編碼)；并且，從其中，數(shù)據(jù)塊被組裝成數(shù)據(jù)單元，然后被組裝成媒體數(shù)據(jù)包?？蛻魴C也保持用于服務對等體中的每一個的單獨的請求隊列，以保持被發(fā)送到每個對等體的無法履行的請求。圖9示出了請求隊列和分級隊列的一個例子。
分級隊列是PeerStreamer客戶機的主要流緩沖區(qū)。所有接收到的內容首先被放入該分級隊列。這些請求隊列用于三個目的1)用于執(zhí)行吞吐量控制和負載平衡；2)用于識別由每個服務對等體發(fā)回的答復；以及3)用于處理斷開的對等體。
請求隊列的第一個功能是平衡服務對等體之中的負載。在媒體被擦除編碼的情況下，對數(shù)據(jù)單元的請求被分成多個擦除編碼塊組的請求，每個組被定向到一個對等體。通過以下操作來生成這些請求。一當請求數(shù)據(jù)單元，客戶機就首先檢驗對等體的可用性向量，并對該數(shù)據(jù)單元計算每個對等體所保持的擦除編碼塊的數(shù)量(ai)。如果所有聯(lián)機對等體所保持的塊的總數(shù)小于k，那么，該數(shù)據(jù)單元不可檢索。如果不可檢索的數(shù)據(jù)單元是非必要的(即嵌入編碼媒體的非基層)，那么，客戶機只需跳過該數(shù)據(jù)單元。
相反，如果不可檢索的數(shù)據(jù)單元是必要的(即，屬于非嵌入編碼媒體數(shù)據(jù)包、或嵌入編碼媒體數(shù)據(jù)包的基層)，那么，客戶機無法繼續(xù)進行流媒體的下載和回放。所以，在一個實施例中，它將等待更多的對等體聯(lián)機，以提供這些缺少的塊。在一個替換實施例中，客戶機將跳過整個媒體數(shù)據(jù)包，并向以后的音頻/視頻解碼器將它標記為“缺少的”。其結果將是所呈現(xiàn)的媒體中的間隙或跳躍。但是，如果無法從對等體群集中重新獲得一個必要的數(shù)據(jù)單元，那么，以后更多的必要數(shù)據(jù)單元將很可能也是不可檢索的。因此，通常更好的做法是讓客戶機等待，直到數(shù)據(jù)可用為止，以便為用戶提供更好的回放體驗。
在確保特定數(shù)據(jù)單元是可重新檢索的之后，即，Σiai≥k 公式10客戶機檢驗每個對等體的請求隊列中的可用空間。需要將每個對等體的RFT保持在系統(tǒng)常數(shù)Trft左右。在一個測試實施例中，1.0s數(shù)量級的Trfr提供較好結果。(注意，使用太短的請求隊列可能不會有效地利用從客戶機到對等體的帶寬。)具體地，如果客戶機所發(fā)送的請求數(shù)據(jù)包被丟失或被延遲，那么，服務對等體可能沒有什么東西要發(fā)送，這會浪費其服務帶寬。相反，使用過長的請求隊列可以防止客戶機迅速適應變化，例如，對等體之一的斷開。另外，如果請求隊列對于所有的對等體在RFT方面都是相同的長度，該請求隊列的容量變得與其服務帶寬Thi·Trft成比例。
例如，假設Trft是1.0s，那么，具有服務帶寬16kbps的對等體允許其請求隊列中有2KB的無法履行的請求待決，而具有服務帶寬1Mbps的對等體允許128KB的無法履行的請求待決。因此，可以向特定對等體請求的擦除編碼塊的數(shù)量由其請求隊列中留出的空間來定上限ei＝min(ai，(Thi·Trft-Bi，outstanding)/bk) 公式11其中，ei是可以向對等體i請求的擦除編碼塊的數(shù)量，bk是擦除編碼塊的大小。
公式11保證客戶機從不發(fā)出具有大于Trft的預期的RFT的請求。如果客戶機無法找到足夠的當前可用的擦除編碼塊，即，∑iei＜k 公式12它將等待，直到服務對等體的請求隊列清除為止。當∑iei≥k時，數(shù)據(jù)單元請求只是被形成并被發(fā)送到對等體。向某個對等體請求的塊的實際數(shù)目(bi)被計算如下Σibi=k,bi=min(ei,c·Thi),]]>公式13其中，c是滿足∑ibi＝k的常數(shù)。
一般而言，以上略述的過程與其服務帶寬Thi成比例地將服務負載分配給每個對等體(公式13)。它也確?？蛻魴C不會向特定服務對等體請求比該服務對等體實際上所高速緩存或存儲的更多的塊。最后，如公式11所示的，該過程也確保請求的RFT不超過Trft。
請求隊列的第二個功能是識別由每個服務對等體發(fā)回的內容。如上所述，PeerStreamer客戶機和對等體通過TCP來進行通信，它保存數(shù)據(jù)傳輸?shù)捻樞?，并保證數(shù)據(jù)包傳遞。而且，每個對等體依次處理傳入的請求。結果，不需要明確地識別被發(fā)回的內容，因為它必須贊成每個對等體的請求隊列中待決的第一個請求。
對于上述的請求隊列的第三個功能，該請求隊列也用來使斷開的對等體的各個請求重定向。例如，只要特定的服務對等體與客戶機斷開，該斷開事件都由TCP協(xié)議來獲得，TCP協(xié)議隨后將該斷開報告給客戶機。然后，客戶機將斷開的對等體的隊列中待決的所有無法履行的請求再分配給剩余的對等體中的一個或多個。用于再分配請求的過程十分類似于用于分配第一個地方的請求的過程。唯一的例外是，在請求再分配時，必須考慮已經向斷開的對等體請求的塊的數(shù)目。
最后，只要擦除編碼塊到達客戶機處，它們都立即離開TCP套接字。在將到達的內容與待決的請求配對之后，從請求隊列中除去已履行的請求。然后，所識別的擦除編碼塊被放入分級隊列。結果，分級隊列的大小增加。如果分級隊列達到預定大小Tstaging，那么，不發(fā)送媒體數(shù)據(jù)包/數(shù)據(jù)單元的更多請求。一旦已接收某個數(shù)據(jù)單元的所有擦除編碼塊，該數(shù)據(jù)單元就被擦除解碼，并被標記為“就緒”。如果所有其所請求的數(shù)據(jù)單元就緒，那么，媒體數(shù)據(jù)包變成就緒。音頻/視頻解碼器周期性地從分級隊列中除去“就緒”的媒體數(shù)據(jù)包。這減小分級隊列的大小，并可能會觸發(fā)新媒體數(shù)據(jù)包請求的生成。
以上所述的媒體流傳送操作隨后繼續(xù)進行，直到完成媒體文件的回放，或直到諸如沒有足夠的對等體可用來流傳送媒體等時刻，或用戶終止流傳送會話。
3.3PeerStreamer操作以上根據(jù)圖2至圖9描述的過程由圖10中的通用操作流程圖來示出。一般而言，圖10展示了示出PeerStreamer的幾個操作實施例的示例性操作流程圖。應該注意，由圖10中的虛線來表示的任何方框和方框之間的互連表示這里所描述的PeerStreamer的替換實施例；并且，如下所述，可以結合在整個文檔中描述的其它替換實施例來使用任何或所有這些替換實施例。
具體地，如圖10所示，在媒體流傳送操作之前，服務器200(也可能是對等體220之一)對將要流傳送的媒體進行編碼(1000)。如上所述，PeerStreamer能夠利用許多常規(guī)編解碼器(例如，MPEG 1/2/4、WMA、WMV等)中的任何一種來進行操作。此外，在編碼過程1000期間，服務器200也生成前述的媒體頭部和包含媒體結構的伴隨文件。
如上所述，在一個實施例中，一旦媒體被編碼(1000)，所編碼的媒體數(shù)據(jù)包就被分成(1005)多個固定大小的數(shù)據(jù)單元。另外，對于所編碼的媒體，媒體頭部和媒體結構也被分成(1005)多個與用來分割已編碼媒體數(shù)據(jù)包的相同的固定大小的數(shù)據(jù)單元。如以上所解釋的，通過將信息分成(1005)固定長度數(shù)據(jù)單元，來允許客戶機和服務對等體在媒體流傳送操作之前預先分配存儲塊，從而在流傳送過程期間避免計算上昂貴的存儲器分配操作。另外，較小的數(shù)據(jù)單元的運用允許客戶機對每個服務對等體所消耗的確切的帶寬數(shù)量的較精細的控制，以便在流傳送操作期間滿足客戶機數(shù)據(jù)單元請求。
除了將已編碼媒體、媒體頭部和媒體結構分成(1005)較小的數(shù)據(jù)單元以外，在一個實施例中，附加編碼層還用來在服務對等體本質上不可靠的典型P2P環(huán)境中提供增加的冗余度。具體地，如上所述，在一個實施例中，使用基于關鍵字的高速率擦除彈性編碼過程1010，來將這些數(shù)據(jù)單元進一步分成多個數(shù)據(jù)塊。
這類編碼1010的運用確保對等體中的一個或多個將具有重建特定的數(shù)據(jù)單元所必要數(shù)據(jù)塊，同時，簡化客戶機上識別對等體中的哪一個包含必要數(shù)據(jù)的要求。另外，如上所述，在一個實施例中，每個服務對等體220所使用的擦除彈性編碼關鍵字被服務器200自動分配給每個對等體。但是，在另一個實施例中，每個服務對等體220僅僅隨機地選擇擦除彈性編碼關鍵字。然后，當每個對等體220最初由客戶機來聯(lián)系時，這些關鍵字連同前述的可用性向量一起被包括在內對等體客戶機，可用性向量由客戶機210來檢索。在隨機關鍵字實施例中，在對給定數(shù)據(jù)單元存在關鍵字沖突的情況下，客戶機隨后使一個或多個對等體的關鍵字無效。
一旦媒體最初已被編碼(1000)、被分成數(shù)據(jù)單元(1005)并可能進一步被擦除編碼(1010)，最后得到的數(shù)據(jù)單元或數(shù)據(jù)塊隨后就被分發(fā)(1015)給各個服務對等體220。該分發(fā)(1015)會是深思熟慮的，這體現(xiàn)在已編碼媒體的塊或數(shù)據(jù)包僅僅被全部或部分地提供給多個對等體，它隨后被高速緩存或存儲在那里，用于當被與P2P網(wǎng)絡連接的客戶機調用時的進一步的流傳送操作。
或者，如上所述，只要客戶機210流傳送特定的媒體文件，恢復的媒體數(shù)據(jù)包都只是編碼操作1000之后的媒體數(shù)據(jù)包。它們可以被分成數(shù)據(jù)單元(1005)，并可被進一步擦除編碼(1010)；并且，客戶機可能在本地存儲器或存儲單元內維持流傳送到它那里的內容的至少一部分。然后，客戶機被識別為服務對等體220(在前述對等體列表310中)，用于將來的流傳送操作。這個實施例的一個優(yōu)點是包含特定媒體文件的各個部分的對等體的數(shù)目最初很低，從而增加對服務器本身的要求，以滿足服務請求，但隨著時間的流逝并且更多客戶機流傳送該媒體，那些客戶機隨后將能夠擔當用于以后的流傳送請求的對等體。因此，不需要明確地選擇服務對等體220，以保持將要被流傳送的媒體的全部或一部分的初始高速緩存。結果，對于試圖識別愿意接受將要被流傳送的媒體的初始高速緩存的對等體，進一步減少服務器上的任何要求。
在任何情況下，一旦媒體已被分發(fā)(1015)給服務對等體220，客戶機210隨后就準備好開始將請求流傳送到那些服務對等體。另外，如上所述，出于流傳送到客戶機210的目的，服務器200也可以擔當服務對等體220。再有，鑒于以上討論，應該清楚，隨著時間的流逝，特定媒體文件的初始流傳送可以要求更大的服務器200牽涉，并且，更多客戶機210流傳送該媒體(并且隨后可用于擔當服務對等體)，對對等體服務器的實際上擔當服務對等體的各個要求被減少或甚至被消除。
這時，客戶機210通過首先檢索可用服務對等體220的列表310，來開始流傳送會話。如上所述，該列表310直接從服務器200中、從對等體220之一中、或通過使用用于識別潛在服務對等體的常規(guī)DHT方法315來檢索。一旦客戶機210檢索了對等體列表310，該客戶機隨后就連接到每個服務對等體220，并從每個對等體中檢索(1025)可用性向量。另外，在一個實施例中，客戶機210在正在進行的流傳送操作期間周期性核對對于對等體列表310的更新(1030)。執(zhí)行這類周期性核對(1030)的一個優(yōu)點是在大型P2P網(wǎng)絡中，多個服務對等體任何給定的時刻正在聯(lián)機和脫機是可能的。因此，確?？蛻魴C210具有已更新的對等體列表310將允許該客戶機響應于當前正將媒體流傳送到該客戶機的對等體220的丟失或降級。只要列表310的周期性核對(1030)指出對該列表添加新的對等體220，客戶機210就再次連接到該新的對等體，并檢索(1025)該新的對等體的可用性向量。
一旦客戶機210檢索(1025)了每個對等體220的可用性向量，該客戶機隨后就通過經由該客戶機與那些對等體之間的網(wǎng)絡連接而請求對應于來自這些對等體中的一個或多個的信息的數(shù)據(jù)單元，來檢索(1035)將要從這些服務對等體中的一個或多個流傳送的媒體的媒體頭部和媒體結構。
如上所述，媒體頭部通常包含描述該媒體的全局信息，例如，媒體中的通道數(shù)目、每個通道的屬性和特征(音頻采樣率、視頻分辨率/幀速率)、所使用的編解碼器、媒體的作者/版權持有者、等等。因此，媒體流傳送會話的起始處的媒體頭部的檢索允許客戶機220對這些必要的工具進行設置或初始化(1040)，以便在該流傳送會話期間接收那些數(shù)據(jù)包之前對隨后接收的數(shù)據(jù)包進行解碼(1070)和呈現(xiàn)(1075)。
另外，在檢索(1035)特定流媒體的媒體結構之后，客戶機分析該媒體結構，并計算在流傳送過程期間將需要被請求的流媒體的數(shù)據(jù)單元的數(shù)據(jù)單元ID(1045)。然后，客戶機210向服務對等體220中的一個或多個逐個地請求那些數(shù)據(jù)單元(1050)。
另外，如上所述，在結合編碼關鍵字的隨機對等體選擇來使用擦除編碼的實施例中，客戶機210將使對等體一個或多個對等體220上的重復關鍵字無效，以便管理關鍵字沖突(1055)。在一個相關實施例中，PeerStreamer使用嵌入編碼媒體，并且，隨后根據(jù)可用的服務帶寬和客戶機210隊列狀態(tài)來管理(1060)每個對等體220的數(shù)據(jù)請求(和流傳送比特率)。在此情況下，數(shù)據(jù)單元的正在進行的請求(1050)對應于將基于各個服務對等體的可用帶寬來提供最小碼率失真的那些數(shù)據(jù)包。在任何情況下，如上所述，根據(jù)已使用嵌入還是非嵌入編碼、對等體的連接狀態(tài)、以及剩下來用于請求和接收缺少的或后來的數(shù)據(jù)單元的時間，來再次向同一或另一對等體220請求(1050)缺少的或后來的數(shù)據(jù)單元。
最后，一旦根據(jù)客戶機220請求(1050)檢索了構成特定媒體數(shù)據(jù)包的所有數(shù)據(jù)單元，那些數(shù)據(jù)包就被重新組裝(1065)成原始媒體數(shù)據(jù)包。然后，重新組裝的媒體數(shù)據(jù)包被解碼(1070)、被呈現(xiàn)(1075)和被提供，用于常規(guī)的顯示設備355或揚聲器260中的任何一個或兩者上的回放。
已出于舉例說明和描述的目的來呈現(xiàn)對PeerStreamer的前述描述。它并不意在做到詳盡或將本發(fā)明局限于所揭示的精確形式。按照以上的教導，許多修改和變更是可能的。另外，應該注意，可以在形成PeerStreamer的其它混合式實施例所需要的任何組合中使用任何或所有這些上述的替換實施例。本發(fā)明的范圍意在不受到本詳細描述的限制，而是受到所附權利要求書的限制。
權利要求
1.一種具有計算機可執(zhí)行指令的計算機可讀介質，所述指令用于提供對等(P2P)網(wǎng)絡中多媒體數(shù)據(jù)包的客戶機驅動流傳送，所述計算機可執(zhí)行指令包括在客戶機計算機上維護多個客戶機請求隊列，每個客戶機請求隊列對應于服務對等體群集中的多個服務對等體之一；將一個或多個數(shù)據(jù)包的客戶機請求發(fā)送給多個服務對等體；當每一數(shù)據(jù)包請求從所述客戶機發(fā)送到所述服務對等體之一時，將所述每一數(shù)據(jù)包請求添加到所述對應的請求隊列；當所述對應的數(shù)據(jù)包由所述客戶機從所述服務對等體接收時，從所述對應的請求隊列中移除每個數(shù)據(jù)包請求；將每個接收到的數(shù)據(jù)包提供給由所述客戶機維護的公用分級隊列；以及將所述公用分級隊列中的數(shù)據(jù)包組裝成對應的多媒體數(shù)據(jù)包。
2.如權利要求1所述的計算機可讀介質，其特征在于，在客戶機計算機上維護多個客戶機請求隊列還包括創(chuàng)建和維護對應于加入所述服務對等體群集的任一服務對等體的的附加客戶機請求隊列。
3.如權利要求1所述的計算機可讀介質，其特征在于，在客戶機計算機上維護多個客戶機請求隊列還包括將遺留在對應于從所述服務對等體群集中丟棄的服務對等體的請求隊列中的任何數(shù)據(jù)包請求移動到一個或多個其它客戶機請求隊列。
4.如權利要求1所述的計算機可讀介質，其特征在于，負載平衡是通過提供對跨越所述服務對等體群集中的每個服務對等體維護近似一致的請求履行時間(RFT)的數(shù)據(jù)包請求的客戶機管理，跨越所述服務對等體群集中的每個服務對等體維護的。
5.如權利要求1所述的計算機可讀介質，其特征在于，對任一服務對等體的所述客戶機數(shù)據(jù)包請求是通過到所述服務對等體的可靠且保持次序的鏈接來提供的，使得所述服務對等體不必標識在對所述客戶機請求的回復中發(fā)送的數(shù)據(jù)包。
6.如權利要求5所述的計算機可讀介質，其特征在于，到所述服務對等體的可靠且保持次序的鏈接是TCP通信協(xié)議。
7.如權利要求5所述的計算機可讀介質，其特征在于，由所述客戶機從服務對等體接收的任一傳入數(shù)據(jù)包與對應于從從其中接收所述數(shù)據(jù)包的服務對等體的請求隊列中的第一個數(shù)據(jù)包請求相對應于。
8.如權利要求1所述的計算機可讀介質，其特征在于，對特定服務對等體的特定數(shù)據(jù)包的客戶機請求是基于從每個所述服務對等體檢索的可用性向量的客戶機分析而做出的，并且其中，從每個服務對等體接收的所述可用性向量至少定義了存儲在每個對應的服務對等體上的可用性數(shù)據(jù)包。
9.如權利要求1所述的計算機可讀介質，其特征在于，還包括在所述客戶機計算機上解碼和呈現(xiàn)所組裝的多媒體數(shù)據(jù)包，以在所述客戶機計算機上提供流媒體回放。
10.如權利要求1所述的計算機可讀介質，其特征在于，所述數(shù)據(jù)包是嵌入編碼的數(shù)據(jù)包。
11.如權利要求10所述的計算機可讀介質，其特征在于，還包括根據(jù)下列，通過將一個或多個數(shù)據(jù)包的所述客戶機請求自動限制到多個服務對等體，來維護對每個嵌入編碼數(shù)據(jù)包的流傳送比特率的客戶機控制所述服務對等體的總計服務帶寬；所述公用分級隊列的大?。黄谕恼埱舐男袝r間；在所述公用分級隊列中接收的數(shù)據(jù)包的長度；每個請求隊列中的待決回復的長度；以及所述嵌入編碼的數(shù)據(jù)包的基層比特率。
12.一種用于提供對等體(P2P)網(wǎng)絡中的客戶機控制的媒體文件流傳送的方法，包括使用計算設備，以便在可用服務對等體群集中的一個或多個服務對等體上存儲已編碼的媒體文件的一個或多個數(shù)據(jù)包，所述已編碼的媒體文件包括媒體頭部和媒體主體，使得所述已編碼的媒體文件的每一數(shù)據(jù)包高速緩存在至少一個所述服務對等體中；使用所述客戶機以檢索對所述客戶機可用的服務對等體的列表；為每個可用的服務對等體初始化所述客戶機上的單獨的數(shù)據(jù)包請求隊列；將對一個或多個特定數(shù)據(jù)包的一個或多個客戶機請求發(fā)送到一個或多個特定服務對等體，以及將每個請求添加到對應的數(shù)據(jù)包請求隊列；當所述對應的數(shù)據(jù)包由所述客戶機接收時，從所述對應的數(shù)據(jù)包請求隊列中移除每個請求；以及解碼和呈現(xiàn)所接收的數(shù)據(jù)包，以在所述客戶機上提供流媒體回放。
13.如權利要求12所述的方法，其特征在于，還包括將每個可用服務對等體的可用性向量下載到所述客戶機，其中，每個可用性向量描述了存儲在每個對應的服務對等體上的可用數(shù)據(jù)包，并且其中，對一個或多個特定數(shù)據(jù)包的客戶機請求基于所下載的可用性向量。
14.如權利要求12所述的方法，其特征在于，解碼和呈現(xiàn)所接收的數(shù)據(jù)包還包括在所述客戶機上回放之前，至少部分地緩沖所解碼和呈現(xiàn)的數(shù)據(jù)包。
15.如權利要求12所述的方法，其特征在于，為每個可用的服務對等體初始化所述客戶機上的單獨的數(shù)據(jù)包請求隊列還包括創(chuàng)建和維護對應于加入所述服務對等體群集的任一服務對等體的附加客戶機數(shù)據(jù)包請求隊列。
16.如權利要求12所述的方法，其特征在于，還包括將遺留在對應于對所述客戶機不可用的服務對等體的數(shù)據(jù)包請求隊列中的任何數(shù)據(jù)包請求移到一個或多個其它數(shù)據(jù)包請求隊列，以及向所述對應的服務對等體請求所述的數(shù)據(jù)包。
17.如權利要求12所述的方法，其特征在于，還包括通過提供對跨越每一所述可用服務對等體上維護期望的請求履行時間(RTF)的數(shù)據(jù)包請求的動態(tài)客戶機管理，在每個所述可用服務對等體之間執(zhí)行帶寬負載平衡。
18.如權利要求12所述的方法，其特征在于，對任一服務對等體的所述客戶機數(shù)據(jù)包請求是通過TCP通信協(xié)議提供的，，其中，所述服務對等體不標識在對每個特定客戶機請求的回復中發(fā)送的數(shù)據(jù)包，并且其中，由所述客戶機從服務對等體接收的任何傳入數(shù)據(jù)包與對應于從其中接收所述數(shù)據(jù)包的服務對等體的請求隊列中的第一個數(shù)據(jù)包請求相對應。
19.如權利要求12所述的方法，其特征在于，所述數(shù)據(jù)包是嵌入編碼的數(shù)據(jù)包，并且其中，通過將對一個或多個特定數(shù)據(jù)包的客戶機請求自動限制到一個或多個特定服務對等體，維護對每個嵌入編碼數(shù)據(jù)包的流傳送比特率的客戶機控制。
20.如權利要求19所述的方法，其特征在于，根據(jù)下列自動限制所述客戶機請求所述服務對等體的總計服務帶寬；客戶機分級緩沖區(qū)大??；期望的請求履行時間(RFT)；所述客戶機分級緩沖區(qū)中接收到的數(shù)據(jù)包的長度每個數(shù)據(jù)包請求隊列的長度；以及嵌入編碼的數(shù)據(jù)包的基層比特率。
21.一種協(xié)調從一個或多個非協(xié)作對等體的群集的客戶機驅動媒體流傳送的系統(tǒng)，包括跨越可用于與客戶機通信的服務對等體群集中的一個或多個服務對等體分發(fā)已編碼的媒體文件的所有數(shù)據(jù)包；響應于客戶機請求，將所述群集中的服務對等體的列表提供給所述客戶機；提供對應于所述群集中的每個服務對等體的客戶機上的單獨的數(shù)據(jù)包請求隊列；將對一個或多個特定數(shù)據(jù)包的一個或多個客戶機請求發(fā)送給所述群集中一個或多個特定服務對等體，并且將每個請求添加到所述對應的數(shù)據(jù)包請求隊列；當所述客戶機接收到所述對應的數(shù)據(jù)包時，從所述對應的數(shù)據(jù)包請求隊列中移除每個請求；在客戶機分級隊列中高速緩存每個所接收的數(shù)據(jù)包；以及解碼和呈現(xiàn)所接收的數(shù)據(jù)包，以在所述客戶機上提供流媒體回放。
22.如權利要求21所述的系統(tǒng)，其特征在于，還包括響應于客戶機請求，提供所述群集中的每個服務對等體的可用性向量，并且其中，每個可用性向量描述了存儲在每個對應的服務對等體上的可用數(shù)據(jù)包。
23.如權利要求22所述的系統(tǒng)，其特征在于，將對一個或多個特定數(shù)據(jù)包的一個或多個客戶機請求發(fā)送給所述群集中的一個或多個特定服務對等體是基于對應于所述群集中的每個服務對等體的可用性向量的客戶機分析。
24.如權利要求21所述的系統(tǒng)，其特征在于，所述客戶機分級隊列的長度是不同的，以在解碼和呈現(xiàn)所接收的數(shù)據(jù)包之前提供所請求的數(shù)據(jù)包的期望數(shù)量的緩沖。
25.如權利要求21所述的系統(tǒng)，其特征在于，提供對應于所述群集中的每個服務對等體的客戶機上的單獨的數(shù)據(jù)包請求隊列還包括響應于任何服務對等體加入和離開所述群集，分別動態(tài)地添加和移除客戶機請求隊列中的任一個。
26.如權利要求21所述的系統(tǒng)，其特征在于，響應于任何服務對等體離開所述群集移除客戶機請求隊列還包括將遺留在任何移除的客戶機請求隊列中的任何數(shù)據(jù)包請求移到一個或多個其它客戶機請求隊列，以及向所述對應的服務對等體請求所述對應的數(shù)據(jù)包。
27.如權利要求21所述的系統(tǒng)，其特征在于，還包括通過動態(tài)地平衡客戶機數(shù)據(jù)包請求在所述群集中的每個服務對等體之間執(zhí)行帶寬負載平衡，以對所述群集中的每個服務對等體維護期望的請求履行時間(RFT)。
28.如權利要求21所述的系統(tǒng)，其特征在于，所述客戶機數(shù)據(jù)包請求是通過TCP通信協(xié)議發(fā)送給各個服務對等體的，并且其中，由所述客戶機從特定服務對等體接收的任何傳入數(shù)據(jù)包對應于所述對應的客戶機請求隊列中的第一個數(shù)據(jù)包請求。
全文摘要
“PeerStreamer”提供用于松散耦合的P2P網(wǎng)絡的接收器驅動對等(P2P)媒體流傳送。該網(wǎng)絡中的對等體只執(zhí)行簡單的操作、可以高速緩存流媒體的全部或一部分、不與其他對等體協(xié)作、可以是不可靠的、以及可以在任何給定的流傳送會話期間脫機或聯(lián)機。該網(wǎng)絡中的客戶機進行實時操作，以便協(xié)調對等體、從多個對等體流傳送媒體、執(zhí)行負載平衡、處理對等體的聯(lián)機/脫機狀態(tài)、以及執(zhí)行對該流媒體的解碼和呈現(xiàn)。在一個實施例中，PeerStreamer使用高速率擦除彈性編碼來允許多個服務對等體保持部分媒體而無沖突，以便客戶機僅僅檢索固定數(shù)量的擦除編碼塊，而不管在哪里檢索和檢索什么特定塊。在另一個實施例中，PeerStreamer使用嵌入編碼媒體來根據(jù)可用的服務帶寬和客戶機隊列狀態(tài)而改變流傳送比特率。
文檔編號H04L29/02GK1758646SQ200510099119
公開日2006年4月12日 申請日期2005年8月31日 優(yōu)先權日2004年9月3日
發(fā)明者李勁 申請人:微軟公司