專(zhuān)利名稱(chēng)：用于傳輸基于媒體的文件的系統(tǒng)和方法
技術(shù)領(lǐng)域：
本發(fā)明涉及一種數(shù)字音頻和視頻文件的傳輸，具體的涉及通過(guò)網(wǎng)絡(luò)傳輸媒體對(duì)象。
背景技術(shù)：
隨著在衛(wèi)星和有線產(chǎn)業(yè)中的增長(zhǎng)，已經(jīng)有明顯的需求來(lái)開(kāi)發(fā)用于將完整長(zhǎng)度的電影輸送到家庭多媒體用戶(hù)的架構(gòu)。一種所謂視頻點(diǎn)播(VOD)的輸送概念根據(jù)用戶(hù)所做的選擇來(lái)將電影提供給用戶(hù)。用戶(hù)可以經(jīng)由電子節(jié)目向?qū)?EPG)來(lái)選擇節(jié)目，EPG列出了可以經(jīng)過(guò)廣播服務(wù)接收的可獲得的媒體。一旦選擇了電影，廣播系統(tǒng)會(huì)將電影傳輸給家庭用戶(hù)，該傳輸可以經(jīng)過(guò)有線裝置(諸如MPEG 2數(shù)字有線傳輸)、衛(wèi)星廣播(如DBS，DIRECTVTM，DISHNETWORKTM等)、地面廣播(UHF，VHF，或用于接收標(biāo)準(zhǔn)清晰度/高清晰度節(jié)目的廣播頻道，等)、或雙絞線連接(諸如DSL等)而發(fā)生。
傳輸數(shù)字視頻(音頻)文件，之前稱(chēng)為媒體對(duì)象，的復(fù)雜性需要傳輸架構(gòu)能夠處理大尺寸的數(shù)字視頻文件。例如，作為顯示格式，要求將媒體對(duì)象以“接近于運(yùn)動(dòng)圖像質(zhì)量”(如高清晰度電視)來(lái)進(jìn)行顯示就需要傳輸架構(gòu)要求網(wǎng)絡(luò)支持大約20Mbit/sec的吞吐量。傳輸架構(gòu)還必須具有低傳輸錯(cuò)誤率，以便不破壞視頻/音頻傳輸?shù)囊?。例如，DBS衛(wèi)星系統(tǒng)必須具有從10^-9到10^-11比特范圍內(nèi)的誤碼率以提供可以接受的服務(wù)質(zhì)量(QOS)。
如果將媒體對(duì)象分成分立的片段，則可以降低破壞媒體對(duì)象傳輸?shù)腻e(cuò)誤的概率。被稱(chēng)為數(shù)據(jù)包的這種片段將媒體對(duì)象分成可以在傳輸架構(gòu)的接收端被重建的獨(dú)立部分。用于打包數(shù)據(jù)文件的一種已用技術(shù)符合MPEG-2數(shù)據(jù)編碼標(biāo)準(zhǔn)以創(chuàng)建數(shù)據(jù)流(見(jiàn)MPEG-2規(guī)定ISO-13818-1)從而編碼和傳輸分離的數(shù)據(jù)包。
但是用于傳輸媒體對(duì)象的這種技術(shù)沒(méi)有有效的使用帶寬。諸如文件傳輸協(xié)議(FTP)的用于傳輸媒體對(duì)象的其他已知技術(shù)也受限于物理限制條件，其中不論基礎(chǔ)連接的可獲得鏈路速度是多少，每秒只可以傳輸300千字節(jié)。此外，一些媒體對(duì)象傳輸技術(shù)能夠利用連接的可獲得帶寬。盡管這樣的技術(shù)在媒體對(duì)象的傳輸中使用冗余數(shù)據(jù)包，其可能要求編碼開(kāi)銷(xiāo)是原始媒體對(duì)象的大小的兩倍。因此，這種媒體對(duì)象傳輸?shù)托У厥褂靡话氲目色@得帶寬用于錯(cuò)誤修正。

發(fā)明內(nèi)容
一種通過(guò)網(wǎng)絡(luò)根據(jù)這種網(wǎng)絡(luò)的物理能力來(lái)分派傳輸媒體對(duì)象的系統(tǒng)和方法。將媒體對(duì)象解析為多個(gè)被分段的分區(qū)，并根據(jù)在客戶(hù)端的資源和接入點(diǎn)的可獲得性以及在這樣的接入點(diǎn)與傳輸這樣的媒體對(duì)象的服務(wù)器之間的網(wǎng)絡(luò)連接，而將其傳輸?shù)娇蛻?hù)。


根據(jù)結(jié)合附圖而提供的、本發(fā)明的優(yōu)選實(shí)施例的下面詳細(xì)說(shuō)明，本發(fā)明的上述和其他的優(yōu)點(diǎn)和特點(diǎn)將能夠被更好地理解。附圖的各種特征可能不成比例。在所述附圖中包括下面的圖圖1示出了根據(jù)本發(fā)明的示例實(shí)施例的系統(tǒng)示意圖；圖2示出了根據(jù)本發(fā)明的示例實(shí)施例將被分區(qū)的媒體對(duì)象發(fā)送到單個(gè)客戶(hù)的系統(tǒng)的示意圖；圖3示出了根據(jù)本發(fā)明示例實(shí)施例將被分段的媒體對(duì)象經(jīng)由多播操作進(jìn)行傳輸?shù)南到y(tǒng)的示意圖；圖4示出了根據(jù)本發(fā)明示例實(shí)施例將媒體對(duì)象分段為多個(gè)分區(qū)的傳輸處理的流程圖；圖5示出了分區(qū)的媒體對(duì)象的文件片段的示例實(shí)施例；和圖6示出了根據(jù)本發(fā)明示例實(shí)施例，在分區(qū)的媒體對(duì)象的多播傳輸期間指示數(shù)據(jù)包丟失的兩維陣列。
具體實(shí)施例方式
雖然通過(guò)示例實(shí)施例來(lái)說(shuō)明了本發(fā)明，但是其并不限于此。反而，應(yīng)該從廣義上理解所附的權(quán)利要求，以包括本發(fā)明的實(shí)施例和其他變形，只要它們是在不偏離本發(fā)明的等效物的范圍而由本領(lǐng)域的技術(shù)人員做出的。
本發(fā)明是一種系統(tǒng)和方法，用于傳輸和接收音頻、視頻、或兩種媒體類(lèi)型的結(jié)合作為媒體文件或“媒體對(duì)象”。如在這里所使用的，術(shù)語(yǔ)“媒體對(duì)象”包括音頻、視頻、文本、多媒體數(shù)據(jù)文件、和流媒體文件。多媒體對(duì)象包括文字、圖像、視頻、和音頻數(shù)據(jù)的任何組合。流媒體包括可以經(jīng)由因特網(wǎng)、衛(wèi)星或其他通訊網(wǎng)絡(luò)環(huán)境被傳送給用戶(hù)并且在整個(gè)文件的發(fā)送完成之前就開(kāi)始在用戶(hù)的計(jì)算機(jī)/設(shè)備上播放的音頻、視頻、多媒體、文本、和互動(dòng)數(shù)據(jù)文件。可以在包括經(jīng)由因特網(wǎng)、衛(wèi)星(DSS，DVB-S)、電纜、DSL、T1線路、無(wú)線網(wǎng)絡(luò)、或其他能夠發(fā)送媒體對(duì)象的發(fā)送系統(tǒng)的任何通訊網(wǎng)絡(luò)上傳輸媒體對(duì)象。
媒體對(duì)象的內(nèi)容的例子包括歌曲、政治演講、新聞廣播、電影預(yù)告片、電影、電視節(jié)目廣播、無(wú)線電廣播、金融電話會(huì)議、現(xiàn)場(chǎng)音樂(lè)會(huì)、網(wǎng)絡(luò)攝像電影膠片(footage)，和其他具體事件。可以以各種格式將媒體對(duì)象進(jìn)行編碼，包括REALAUDIO，REALVIDEO，REALMEDIA，APPLE QUICKTIME，MCIROSOFT WINDOWSMEDIA FORMAT，QUICKTIME，MPEG-2 VIDEOCOMPRESSION，MPEG-4 VIDEO AND/OR AUDIO COMPRESSION，JOINTVIDEO TEAM COMPRESSION FORMAT(MPEG-4 part 10 AVC，H.264)，MPEG-2 LAYER III AUDIO，MP3。通常，用指示與具體格式的兼容性的擴(kuò)展名(后綴)來(lái)指示媒體對(duì)象。例如，以擴(kuò)展名.ram、.rm、.rpm之一結(jié)尾的媒體對(duì)象(例如視頻和音頻文件)與REALMEDIA格式兼容。在表一中列出了文件擴(kuò)展名的和它們的兼容格式一些例子。在http//www.bower.cc/extentions2.htm處可以發(fā)現(xiàn)更加詳盡的媒體類(lèi)型、擴(kuò)展名和兼容格式的列表。


表1本發(fā)明的優(yōu)選實(shí)施例對(duì)包括用于代表“接近于運(yùn)動(dòng)圖像質(zhì)量”的視頻表示的視頻數(shù)據(jù)的媒體對(duì)象進(jìn)行操作?？梢杂弥T如MPEG-2(運(yùn)動(dòng)圖像標(biāo)準(zhǔn)組標(biāo)準(zhǔn)ISO/IEC 13818-12000)和ITU-TH.264/MPEG AVC(ISO/IEC 14496-10)的各種格式將這種媒體對(duì)象進(jìn)行編碼，或?qū)⑵浣鈮嚎s。而且，還可以在諸如電影或電視節(jié)目的后期制作的應(yīng)用、和需要大媒體對(duì)象的傳輸?shù)膽?yīng)用的專(zhuān)業(yè)領(lǐng)域中使用本發(fā)明的所述實(shí)施例。
在圖1中，示出了根據(jù)本發(fā)明的傳輸系統(tǒng)。系統(tǒng)100顯示了用于將大媒體對(duì)象傳輸給客戶(hù)140的傳輸系統(tǒng)的實(shí)施例。文件服務(wù)器110是諸如硬盤(pán)驅(qū)動(dòng)器的矩陣的存儲(chǔ)設(shè)備，其具有能夠存儲(chǔ)多個(gè)媒體對(duì)象的千兆字節(jié)容量和/或兆兆字節(jié)容量。通過(guò)局域網(wǎng)將文件服務(wù)器110耦合到容納諸如主控制器120的控制元件的服務(wù)器115，并且耦合到文件分區(qū)處理器130。最好服務(wù)器115包括能夠傳輸通過(guò)網(wǎng)絡(luò)170傳輸?shù)拿襟w對(duì)象的主機(jī)計(jì)算機(jī)或系列的計(jì)算機(jī)。注意根據(jù)本發(fā)明的原則，可以將任何公開(kāi)的主控制器和文件分區(qū)處理器實(shí)現(xiàn)為硬件、軟件、或硬件和軟件的組合。
主控制器120對(duì)于將分區(qū)的媒體對(duì)象經(jīng)過(guò)網(wǎng)絡(luò)170向客戶(hù)140的傳輸進(jìn)行管理。主控制器120還諧調(diào)文件服務(wù)器110和文件分區(qū)處理器130的操作，以將媒體對(duì)象分段為多個(gè)分區(qū)。文件分段的根據(jù)是在請(qǐng)求媒體對(duì)象的客戶(hù)端的、影響媒體文件分段和這種傳輸?shù)姆侄蔚腻e(cuò)誤恢復(fù)兩者的資源的可獲得性。最好通過(guò)符合TCP/IP的網(wǎng)絡(luò)連接來(lái)處理主控制器120和客戶(hù)140之間的控制通訊。
文件分區(qū)處理器130負(fù)責(zé)根據(jù)從主控制器120發(fā)布的指令來(lái)檢索和傳輸媒體對(duì)象的適當(dāng)?shù)钠?。最好文件分區(qū)處理器130在如Postel，J.“UserDatagram Protocol”，Request for Comments 768，USC/Information ScienceInstitute，August 1980中所述的網(wǎng)絡(luò)連接上，使用基于UDP的協(xié)議將其關(guān)聯(lián)的文件片段傳輸給客戶(hù)140。一組文件分區(qū)處理器130理想地以同時(shí)或平行的方式將它們的各個(gè)片段或數(shù)據(jù)包進(jìn)行傳輸，所以以同時(shí)的方式在客戶(hù)140處接收所傳輸?shù)臄?shù)據(jù)。
網(wǎng)絡(luò)170可以是在現(xiàn)有技術(shù)中已知的任何類(lèi)型的網(wǎng)絡(luò)。最好，這種網(wǎng)絡(luò)能夠在服務(wù)器的服務(wù)器側(cè)的資源和在客戶(hù)的客戶(hù)側(cè)的資源之間提供多個(gè)連接，這種連接可以是基于UDP的、基于TCP/IP的、或兩者的混合。由網(wǎng)絡(luò)150提供的帶寬最好是大帶寬連接，如T1連接(1.5兆比特每秒，Mbps)、T3連接(45Mbps)、DS3連接(45Mbps)、OC3連接(155Mbps)、OC12(248000Mbps)等。
客戶(hù)140最好包括能夠接收通過(guò)網(wǎng)絡(luò)170傳輸?shù)拿襟w對(duì)象的系列計(jì)算機(jī)或主機(jī)計(jì)算機(jī)。最好，每個(gè)客戶(hù)140都具有與IP地址和端口地址相關(guān)聯(lián)的系列接入點(diǎn)或節(jié)點(diǎn)。示出這種接入點(diǎn)作為在客戶(hù)側(cè)的主控制器150和文件分區(qū)處理器160。
由文件分區(qū)處理器130將分區(qū)的媒體對(duì)象的片段經(jīng)由UDP傳輸?shù)娇蛻?hù)140的接入點(diǎn)的端口和IP地址，如上所述?？梢杂膳c客戶(hù)140關(guān)聯(lián)的接入點(diǎn)所關(guān)聯(lián)的對(duì)應(yīng)的網(wǎng)絡(luò)接口卡地址(NIC地址)或媒體訪問(wèn)控制地址(MAC)地址，來(lái)識(shí)別接入點(diǎn)，在這種情況中客戶(hù)140可以是文件分區(qū)處理器160，雖然客戶(hù)140可能沒(méi)有這種元件。然后當(dāng)完全接收時(shí)，將由客戶(hù)140的接入點(diǎn)接收的媒體對(duì)象的片段重建為媒體對(duì)象。使用在本說(shuō)明書(shū)的后面部分所描述的技術(shù)，代替媒體對(duì)象的丟失的片段。應(yīng)該注意對(duì)于本發(fā)明的操作，主控制器120和文件分區(qū)處理器130可能占據(jù)相同的服務(wù)器115，或可能占據(jù)幾個(gè)服務(wù)器115。因此，根據(jù)所需要的傳輸系統(tǒng)的要求，主控制器150和文件分區(qū)處理器160可以占據(jù)相同的客戶(hù)140，或占據(jù)幾個(gè)客戶(hù)140?？梢詫⒈景l(fā)明的原則應(yīng)用于其他分布的網(wǎng)絡(luò)環(huán)境，其中使用多個(gè)服務(wù)器115或客戶(hù)140來(lái)傳輸和/或接收相同的媒體對(duì)象。
圖2示出了用于將分段的媒體對(duì)象發(fā)送到單個(gè)客戶(hù)240的本發(fā)明的實(shí)施例。在本發(fā)明的這個(gè)實(shí)施例中，系統(tǒng)200具有通過(guò)網(wǎng)絡(luò)250向服務(wù)器215請(qǐng)求媒體對(duì)象的客戶(hù)240，其中媒體對(duì)象存儲(chǔ)在文件服務(wù)器210中。在這個(gè)實(shí)施例中，客戶(hù)240具有主控制器220，用于發(fā)布對(duì)媒體對(duì)象的請(qǐng)求和用于配置可以獲得來(lái)接收分段的媒體對(duì)象的文件分區(qū)處理器230。通過(guò)使用基于TCP/IP的傳輸，主控制器220向服務(wù)器215指示文件分區(qū)處理器230的哪個(gè)對(duì)應(yīng)的UDP端口將接收對(duì)應(yīng)的文件片段，并且將所請(qǐng)求的媒體對(duì)象進(jìn)行分段。當(dāng)通過(guò)網(wǎng)絡(luò)250在它們對(duì)應(yīng)的UPD連接上從文件分區(qū)處理器230成功地取回所有的片段時(shí)，主控制器220將所接收的片段進(jìn)行連接。
圖3示出了本本發(fā)明的實(shí)施例，用于使用在Thaler，D.，“InteroperabilityRules for Multicast Routing Protocols，”Request For Comments 2715，Microsoft，October，1999中所述的IP多播架構(gòu)將分段的媒體對(duì)象傳輸?shù)蕉鄠€(gè)客戶(hù)350。
在這個(gè)實(shí)施例中，存在至少兩個(gè)客戶(hù)340，其中每個(gè)客戶(hù)340都具有對(duì)應(yīng)的主控制器350用于發(fā)布對(duì)存儲(chǔ)在文件服務(wù)器310中的媒體對(duì)象的請(qǐng)求。雖然每個(gè)主控制器350必須計(jì)算同步請(qǐng)求媒體對(duì)象的所有客戶(hù)340所需的延遲。由每個(gè)主控制器350建立到服務(wù)器315的、對(duì)媒體對(duì)象的請(qǐng)求，服務(wù)器315然后將分段的媒體對(duì)象多播到客戶(hù)340的對(duì)應(yīng)的文件分區(qū)處理器360，或者單個(gè)主控制器360將IP地址指定給應(yīng)該通過(guò)多播網(wǎng)絡(luò)370經(jīng)由IP多播將媒體對(duì)象的片段傳輸?shù)降牡胤?。將文件片段傳輸?shù)轿募謪^(qū)處理器360和在客戶(hù)340將這樣接收的文件片段重建為媒體對(duì)象，與參照?qǐng)D1和2在本說(shuō)明書(shū)中所描述的類(lèi)似。
或者，主控制器350結(jié)合服務(wù)器315的主控制器320來(lái)操作以接收分區(qū)的媒體對(duì)象。主控制器320通知主控制器350將會(huì)使用那些多播地址來(lái)傳輸分區(qū)的媒體對(duì)象的片段。對(duì)應(yīng)的主控制器350將命令它們對(duì)應(yīng)的文件分區(qū)處理器來(lái)通過(guò)多播網(wǎng)絡(luò)370接收這樣的片段。
圖4示出了根據(jù)本發(fā)明的實(shí)施例，用于傳輸媒體對(duì)象的方法400的流程圖。參考圖1表示了該流程圖表示的步驟。在步驟405，客戶(hù)140經(jīng)由網(wǎng)絡(luò)170連接到與服務(wù)器115關(guān)聯(lián)的主控制器120。通過(guò)TCP/IP套接字建立連接，其中客戶(hù)140識(shí)別將被傳輸?shù)拿襟w對(duì)象。在這個(gè)步驟期間，客戶(hù)140還指定用于媒體對(duì)象傳輸?shù)耐ㄓ嵥俾省?br> 在步驟415，主控制器120確定為了滿(mǎn)足由客戶(hù)140所設(shè)置的需要的通訊速率而必須的文件分區(qū)處理器130的數(shù)量。這個(gè)步驟可能還包括參與分段的媒體對(duì)象的傳輸?shù)亩鄠€(gè)服務(wù)器。步驟420使得主控制器120指令每個(gè)分區(qū)處理器130關(guān)于使用哪個(gè)UPD端口將媒體對(duì)象的哪個(gè)片段傳輸?shù)娇蛻?hù)140。
步驟425涉及主控制器120指令客戶(hù)140關(guān)于下載將被最終傳輸?shù)拿襟w對(duì)象的片段所需要的UDP端口。而且，控制信息由主控制器120傳輸?shù)娇蛻?hù)140，該控制信息指示對(duì)于分割的媒體對(duì)象的具體片段，將從UDP端口進(jìn)入多少數(shù)據(jù)包。步驟430使得每個(gè)文件分區(qū)處理器130將頭部塊放在將在其指派的UDP端口上被傳輸?shù)钠渖?。最好，以?shù)字順序來(lái)順序產(chǎn)生頭部塊。然后將數(shù)據(jù)包傳輸?shù)娇蛻?hù)140數(shù)據(jù)包。
然后客戶(hù)140確定在步驟435中將使用哪些基于客戶(hù)的文件分區(qū)處理器160，以及激活哪些服務(wù)器來(lái)接收所傳輸?shù)奈募?。在步驟440，作為接入點(diǎn)，基于客戶(hù)的文件分區(qū)處理器160在對(duì)應(yīng)的UDP端口上，接收代表傳輸?shù)拿襟w對(duì)象片段的數(shù)據(jù)包。在所接收的數(shù)據(jù)包的頭塊中的順序識(shí)別符確定如何重建所接收的媒體對(duì)象片段。
如果對(duì)于具體的文件分區(qū)處理器160丟失了任何的數(shù)據(jù)包，則步驟445使得客戶(hù)140通過(guò)TCP/IP連接通知主控制器120關(guān)于哪些數(shù)據(jù)包丟失了以及需要通過(guò)對(duì)應(yīng)的文件分區(qū)處理器130進(jìn)行重新傳輸。最好，客戶(hù)140具有客戶(hù)側(cè)主處理器150，用于同在服務(wù)器側(cè)的主控制器120進(jìn)行通訊。在步驟450，客戶(hù)140指示主控制器120關(guān)于已經(jīng)完全接收的媒體對(duì)象的具體片段。如果沒(méi)有完成媒體對(duì)象的完全下載，則客戶(hù)140還指令主控制器120來(lái)使用新參數(shù)進(jìn)行傳輸并且傳輸媒體對(duì)象的附加片段(如在步驟420至445中所做的)。
步驟460使得主控制器120通知客戶(hù)140關(guān)于已經(jīng)傳輸了分區(qū)的媒體對(duì)象的所有片段。然后客戶(hù)140使用所接收的媒體對(duì)象的片段來(lái)重建媒體對(duì)象。
圖5示出了分區(qū)的媒體對(duì)象的文件片段的示例實(shí)施例。如在圖中所示，文件片段包括主片段510和次片段520。客戶(hù)140和服務(wù)器115使用主片段510作為主片段邊界，其中主片段510是用于發(fā)送文件片段的大“塊”。次片段520是被用于構(gòu)造主片段510的較小“塊”。在本發(fā)明的優(yōu)選實(shí)施例中，在傳輸?shù)诙髌?10之前客戶(hù)140必須完全接收主片段510。如果沒(méi)有完全接收主片段510，則客戶(hù)140告訴主控制器將重新傳輸所述主片段510的哪個(gè)次片段520，其中每個(gè)次片段520對(duì)應(yīng)于服務(wù)器115的具體文件分區(qū)處理器130。
在單播(unicast)傳輸中，主控制器120指定主片段510給一組文件分區(qū)處理器130。然后每個(gè)文件分區(qū)處理器130被分派主片段510的一部分作為要作為UDP數(shù)據(jù)包傳輸?shù)拇纹?20。一旦將用于構(gòu)建主片段510的次片段520成功傳輸，則每個(gè)文件分區(qū)處理器130通知主控制器120關(guān)于主片段的傳輸已經(jīng)完成。然后主控制器將發(fā)布要被分割的、并且要被文件分區(qū)處理器130傳輸?shù)牡诙髌?20給客戶(hù)140，如上所述。
最好，可以配置主控制器120以建造主片段510的流水線(pipeline)，從而消除在主控制器處理來(lái)自客戶(hù)140的、指示網(wǎng)絡(luò)情況變化的消息時(shí)對(duì)于空閑時(shí)間的需要。還可以響應(yīng)于網(wǎng)絡(luò)條件而改進(jìn)主片段510的大小。例如，主片段510可以包括十個(gè)側(cè)片段520。在數(shù)據(jù)包丟失較少的情況下，將主片段510的大小增加到12個(gè)次片段520?；蛘撸跀?shù)據(jù)包丟失較多的情況下，將主片段510的大小減少到8個(gè)次片段520?？梢愿鶕?jù)本發(fā)明的原理來(lái)修改次片段的數(shù)量中的調(diào)整。
還可以設(shè)想如果在主片段510中的次片段520的數(shù)量保持相同；根據(jù)網(wǎng)絡(luò)條件來(lái)修改主片段520的物理尺寸(千字節(jié))。最好由客戶(hù)140的主控制145做出這種確定。或者，主控制器120還可以消除主片段510的使用，并且依賴(lài)作為數(shù)據(jù)的連續(xù)塊而產(chǎn)生的次片段520的使用。然后文件分區(qū)處理器130將這些次片段520傳輸給客戶(hù)140，其中每個(gè)文件分區(qū)處理器130通知主控制器關(guān)于每個(gè)次片段520的成功傳輸。然后主控制器120將要被傳輸?shù)男麓纹?20分派給文件分區(qū)處理器130，并且重復(fù)這個(gè)過(guò)程直到將分區(qū)的媒體對(duì)象的片段的所有次片段520都成功地傳輸為止。
在單播(或一個(gè)客戶(hù))傳輸?shù)那闆r中，本發(fā)明提供在諸如傳輸期間丟失數(shù)據(jù)包的情況中的幾種恢復(fù)方案。在一個(gè)實(shí)施例中，主控制器120能將附加的文件分區(qū)處理器130加到傳輸數(shù)據(jù)包中?；蛘撸骺刂破?20將重新發(fā)送數(shù)據(jù)包的任務(wù)分派給預(yù)先存在的文件分區(qū)處理器130。
用于數(shù)據(jù)包丟失保護(hù)的第二方案使用主控制器120來(lái)保持丟失的數(shù)據(jù)包的鏈接的列表。在這個(gè)實(shí)施例中，服務(wù)器115的文件分區(qū)處理器130和主控制器120傳輸分區(qū)的媒體對(duì)象的所有主片段510和次片段520，這種傳輸被稱(chēng)為“第一發(fā)送”。由主控制器120使用鏈接的列表的內(nèi)容，以指示在“第一發(fā)送”傳輸期間丟失的數(shù)據(jù)包。然后服務(wù)器主控制器120將“第二發(fā)送”傳輸與文件分區(qū)處理器130和客戶(hù)140進(jìn)行諧調(diào)，以在重新廣播在“第一發(fā)送”傳輸期間沒(méi)有被成功接收的主片段510和次片段520的數(shù)據(jù)包。重復(fù)這種過(guò)程直到達(dá)到由客戶(hù)140成功接收數(shù)據(jù)包的閾值。
其他的數(shù)據(jù)包丟失技術(shù)包括服務(wù)器側(cè)主控制器120或客戶(hù)側(cè)主控制器150在它們各自側(cè)監(jiān)測(cè)對(duì)應(yīng)的資源。例如，如果在客戶(hù)側(cè)的具體文件分區(qū)處理器130繼續(xù)超時(shí)或者如果客戶(hù)140停止響應(yīng)，則主控制器120可以取消分派給文件分區(qū)處理器130的工作，并且重新分派(傳輸數(shù)據(jù)的)工作給第二文件分區(qū)處理器130，或重新將主片段510分派給一組文件分區(qū)處理器130。主處理器120通知用戶(hù)關(guān)于這種超時(shí)錯(cuò)誤。
或者，通過(guò)跟蹤在客戶(hù)側(cè)的統(tǒng)計(jì)，主控制器150可以發(fā)現(xiàn)UDP地址連續(xù)地丟失數(shù)據(jù)包。然后主控制器150通知服務(wù)器側(cè)主控制器120關(guān)于UDP地址中有問(wèn)題，指示在系統(tǒng)的服務(wù)器側(cè)或客戶(hù)側(cè)有錯(cuò)誤的文件分區(qū)處理器。然后主控制器120和150協(xié)調(diào)數(shù)據(jù)包的傳輸?shù)叫耈DP地址，其可以涉及使用新文件分區(qū)處理器。這些實(shí)施例還考慮可以使用主控制器120或150來(lái)實(shí)現(xiàn)所述的超時(shí)或UDP錯(cuò)誤數(shù)據(jù)包丟失方案，如上所述。
用于多播傳輸?shù)臄?shù)據(jù)包丟失技術(shù)要求服務(wù)器的主控制器準(zhǔn)備利用不同的方法來(lái)防止傳輸?shù)臄?shù)據(jù)包的丟失。參照?qǐng)D3，服務(wù)器主控制器320保持在分段的媒體對(duì)象的主片段510和次片段520的傳輸期間所丟失的數(shù)據(jù)包的鏈接列表，其與用于單播傳輸?shù)逆溄恿斜眍?lèi)似。如在圖6中所示，對(duì)這種鏈接列表的改進(jìn)占據(jù)兩維的陣列，其中所丟失的數(shù)據(jù)包(次片段)是相對(duì)于所有客戶(hù)340丟失的。當(dāng)傳輸了媒體對(duì)象的所有主片段510時(shí)，完成了分區(qū)的媒體對(duì)象的“第一發(fā)送”傳輸。當(dāng)傳輸每個(gè)主片段510完成時(shí)，主控制器320更新鏈接的列表。
然后主控制器320使用鏈接的列表的內(nèi)容來(lái)重新廣播在“第一發(fā)送”期間沒(méi)有被客戶(hù)340成功接收的數(shù)據(jù)包。這種“第二發(fā)送”傳輸具有與“丟失數(shù)據(jù)包”信息一同傳輸?shù)闹髌?10和次片段520。重復(fù)這種過(guò)程直到所有客戶(hù)340接收分區(qū)的媒體對(duì)象的所有片段為止。注意多播傳輸模型還允許主控制器320來(lái)利用結(jié)合上述的單播傳輸模型描述的超時(shí)和UDP數(shù)據(jù)包丟失方案。
可選地，本發(fā)明提供了另外的實(shí)施例，使用控制處理方案來(lái)使得用于傳輸分區(qū)的媒體對(duì)象的傳輸技術(shù)受益。具體地說(shuō)，本發(fā)明提供了操作，其中根據(jù)為這種文件所做出的請(qǐng)求，可以改變用于傳輸媒體對(duì)象的傳輸技術(shù)。
例如，使用上述的單播技術(shù)，現(xiàn)在來(lái)傳輸媒體對(duì)象作為UDP傳輸。在這種傳輸過(guò)程期間，對(duì)于相同文件的第二請(qǐng)求進(jìn)來(lái)到服務(wù)器。參照?qǐng)D3，客戶(hù)340的客戶(hù)側(cè)文件分區(qū)處理器330完成接收分區(qū)的媒體對(duì)象的片段。然后文件分區(qū)處理器330等待關(guān)于如何進(jìn)行接收分區(qū)的媒體對(duì)象的新片段的進(jìn)一步指令。(接收片段的客戶(hù)的)客戶(hù)主控制器350向服務(wù)器主控制器320通知所述客戶(hù)340已經(jīng)成功地接收所述發(fā)送的片段。最好，在主片段510的邊界發(fā)生這種通訊，雖然系統(tǒng)可能還具有對(duì)于次片段520發(fā)生的通訊。
主控制器320通知客戶(hù)主控制器350關(guān)于將要從新地址，特別地是多播地址，來(lái)的媒體對(duì)象的下一個(gè)片段。然后客戶(hù)主控制器350指令文件分區(qū)處理器330來(lái)從指定的多播地址接收媒體對(duì)象的下一個(gè)片段。在中間，主控制器320指定文件分區(qū)處理器330從指定的多播地址以多播數(shù)據(jù)包的形式開(kāi)始傳輸媒體對(duì)象的這個(gè)下一個(gè)片段。將指令所有請(qǐng)求媒體對(duì)象的其他新增加的客戶(hù)340來(lái)同樣從這個(gè)多播地址接收媒體對(duì)象的片段。
主控制器320將分區(qū)的媒體對(duì)象的所有片段傳輸?shù)娇蛻?hù)340，直到已經(jīng)接收了所有片段為止。可以使用如上所述的數(shù)據(jù)包丟失技術(shù)來(lái)支持?jǐn)?shù)據(jù)的傳輸。
在客戶(hù)340或一組客戶(hù)340在正在進(jìn)行多播傳輸?shù)倪^(guò)程期間請(qǐng)求相同的媒體對(duì)象的情況下，主控制器320通知所有的新客戶(hù)340在下一個(gè)主片段510的邊界來(lái)加入在進(jìn)行中的多播。通過(guò)使得主控制器320傳輸正在傳輸請(qǐng)求的媒體對(duì)象的片段的對(duì)應(yīng)文件分區(qū)處理器330的多播地址來(lái)執(zhí)行這個(gè)操作。最好在主控制器320和350之間通過(guò)TCP/IP套接字來(lái)發(fā)送所有的同步和控制通訊。此外，最好也通過(guò)TCP/IP接口來(lái)執(zhí)行多播片段的重新廣播。應(yīng)該注意根據(jù)本發(fā)明的原理，可以使用其他控制通訊。
本發(fā)明的所述系統(tǒng)提供能夠重新配置資源(具體是文件分區(qū)處理器)使用的客戶(hù)側(cè)或服務(wù)器側(cè)主控制器。為了速率控制操作，客戶(hù)可以請(qǐng)求服務(wù)器以所需要的通訊速率來(lái)傳輸分區(qū)的媒體對(duì)象。然后服務(wù)器的主控制器響應(yīng)于這種請(qǐng)求，確定如何利用服務(wù)器的文件分區(qū)處理器。此外，客戶(hù)可以請(qǐng)求使用優(yōu)先級(jí)機(jī)制或諸如“從08:00到17:00使用20％的可獲得帶寬，否則使用90％的可獲得帶寬”的規(guī)則來(lái)傳輸媒體對(duì)象。服務(wù)器的主控制器會(huì)通知文件分區(qū)處理器的使用，而且響應(yīng)于這種請(qǐng)求。類(lèi)似地，服務(wù)器可以自己?jiǎn)?dòng)來(lái)指定用于傳輸分區(qū)的媒體對(duì)象的帶寬限制。在本發(fā)明的優(yōu)選實(shí)施例中，服務(wù)器和客戶(hù)將試圖利用所有可獲得的傳輸資源來(lái)達(dá)到最高的可能傳輸速率。
將本發(fā)明配置為對(duì)于系統(tǒng)性能自我調(diào)節(jié)，從而可以為將來(lái)分區(qū)的媒體對(duì)象的傳輸做出關(guān)于資源分配的更好決定。對(duì)于中央處理單元(CPU)利用、NIC吞吐量、傳輸錯(cuò)誤率、和端到端的傳輸速度收集統(tǒng)計(jì)數(shù)據(jù)。在經(jīng)由操作系統(tǒng)和其他第三方監(jiān)測(cè)工具在文件傳輸期間收集統(tǒng)計(jì)數(shù)據(jù)。在客戶(hù)側(cè)或服務(wù)器側(cè)的主控制器通過(guò)測(cè)量客戶(hù)使用多長(zhǎng)時(shí)間來(lái)處理片段而得出網(wǎng)絡(luò)吞吐量。
用關(guān)于系統(tǒng)性能的信息，客戶(hù)和服務(wù)器的主控制器可能調(diào)整它們關(guān)于應(yīng)該如何分區(qū)媒體對(duì)象、應(yīng)該如何使用文件分區(qū)處理器、和應(yīng)該如何考慮用于具體客戶(hù)或服務(wù)器的網(wǎng)絡(luò)等待時(shí)間和錯(cuò)誤率的假設(shè)。
在下面的表2-8中說(shuō)明了在服務(wù)器和客戶(hù)之間發(fā)送的命令。表2公開(kāi)了傳輸請(qǐng)求命令的示例實(shí)施例，客戶(hù)發(fā)布該命令給服務(wù)器以啟動(dòng)所請(qǐng)求的媒體對(duì)象的傳輸。

表2表3公開(kāi)了示例數(shù)據(jù)控制命令的格式，該命令被服務(wù)器的文件分區(qū)處理器使用來(lái)通知客戶(hù)關(guān)于對(duì)于分區(qū)的媒體對(duì)象的特定片段的傳輸應(yīng)該得到的數(shù)據(jù)包的數(shù)量。而且這種命令還用于識(shí)別所接收的片段(主或次)應(yīng)該被放置在最后文件拷貝的那個(gè)位置。

表3表4公開(kāi)了用于將數(shù)據(jù)從服務(wù)器傳輸?shù)娇蛻?hù)的示例數(shù)據(jù)包的格式。具體地說(shuō)，使用這種數(shù)據(jù)包格式來(lái)形成分區(qū)的媒體對(duì)象的主和次片段。

表4
表5公開(kāi)了示例的重新傳輸命令的格式，客戶(hù)使用該命令來(lái)請(qǐng)求沒(méi)有被成功接收的識(shí)別的數(shù)據(jù)包的重新傳輸。將這種命令傳輸?shù)截?fù)責(zé)傳輸丟失數(shù)據(jù)包的服務(wù)器。

表5表6公開(kāi)了從服務(wù)器傳輸?shù)娇蛻?hù)的、指示文件傳輸?shù)拈_(kāi)始的示例配置命令的格式。這種命令具體指示給客戶(hù)使用什么樣的IP地址或端口來(lái)從服務(wù)器接收數(shù)據(jù)。

表6表7公開(kāi)了示例的分區(qū)命令的格式，服務(wù)器的主控制器使用該命令并且將該命令發(fā)送到用于傳輸主/次片段的文件分區(qū)處理器。這種命令指示在文件分區(qū)處理器之間如何將媒體對(duì)象進(jìn)行分區(qū)。

表6
表8公開(kāi)了片段完成命令的格式，當(dāng)文件分區(qū)處理器指示其已經(jīng)完成處理片段時(shí)，客戶(hù)側(cè)的主控制器將該命令發(fā)送到服務(wù)器。將要處理的分區(qū)的媒體對(duì)象的下一個(gè)片段通知給處理完成的片段的服務(wù)器的文件分區(qū)處理器。然后根據(jù)在表3中所示的命令，文件分區(qū)處理器將發(fā)布數(shù)據(jù)控制命令給客戶(hù)。

表8
權(quán)利要求
1.一種將媒體對(duì)象進(jìn)行分段以在網(wǎng)絡(luò)(170)上傳輸?shù)姆椒?，包括步驟將媒體對(duì)象分區(qū)為至少兩個(gè)片段；將至少一個(gè)所述片段分派給文件分區(qū)處理器(130，160)；和使用所分派的用戶(hù)數(shù)據(jù)報(bào)協(xié)議(UDP)端口來(lái)傳輸至少一個(gè)片段。
2.根據(jù)權(quán)利要求1所述的方法，包括步驟通知主控制器關(guān)于文件分區(qū)處理器已經(jīng)傳輸了至少一個(gè)片段；和將所述分區(qū)的媒體對(duì)象的附加片段分派給所述文件分區(qū)處理器以進(jìn)行傳輸。
3.根據(jù)權(quán)利要求2所述的方法，其中所述主處理器操作至少兩個(gè)文件分區(qū)處理器，其中構(gòu)成主片段的、所述分區(qū)的媒體對(duì)象的至少一個(gè)片段被分割為多個(gè)次片段，每個(gè)次片段被所述主控制器分派給文件分區(qū)處理器。
4.根據(jù)權(quán)利要求3所述的方法，其中在將第二主片段分割為次片段并且被所述文件分區(qū)處理器傳輸之前，由所述至少兩個(gè)文件分區(qū)處理器成功地傳輸所述次片段。
5.根據(jù)權(quán)利要求2所述的方法，其中所述主控制器和文件分區(qū)處理器是用于傳輸所述媒體對(duì)象的服務(wù)器的部分。
6.根據(jù)權(quán)利要求2所述的方法，其中所述主控制器使用基于傳輸控制協(xié)議和因特網(wǎng)協(xié)議(TCP/IP)的傳輸方案和第二主控制器進(jìn)行通訊，并且所述文件分區(qū)處理器使用UDP端口與服務(wù)器通訊。
7.根據(jù)權(quán)利要求2所述的方法，其中所述主控制器跟蹤在鏈接列表中沒(méi)有被成功傳輸?shù)膩G失片段，其中所述主控制器使得負(fù)責(zé)所述丟失片段的所述文件分區(qū)處理器重新傳輸所述丟失的片段。
8.根據(jù)權(quán)利要求2所述的方法，其中當(dāng)所述文件分區(qū)處理器沒(méi)能發(fā)送所述片段時(shí)，作為響應(yīng)所述主控制器重新將所述分區(qū)的媒體對(duì)象的所述片段重新分派給第二文件分區(qū)處理器。
9.根據(jù)權(quán)利要求1所述的方法，其中使用符合多播的傳輸方案將所述片段傳輸以由多個(gè)客戶(hù)接收。
10.一種經(jīng)過(guò)網(wǎng)絡(luò)接收用于傳輸?shù)姆侄蔚拿襟w對(duì)象的方法，包括步驟請(qǐng)求經(jīng)過(guò)網(wǎng)絡(luò)(170)傳輸?shù)拿襟w對(duì)象；接收指示用戶(hù)數(shù)據(jù)報(bào)協(xié)議(UDP)端口用于接收所述媒體對(duì)象的片段的指令，其中將所述媒體對(duì)象分區(qū)為至少兩個(gè)片段；和在所述UDP端口上接收所述片段。
11.根據(jù)權(quán)利要求10所述的方法，其中由客戶(hù)的主控制器來(lái)提出對(duì)所述媒體對(duì)象的所述請(qǐng)求，并且由操作所述客戶(hù)的文件分區(qū)處理器的所述主控制器來(lái)協(xié)調(diào)接收片段的所述步驟。
12.根據(jù)權(quán)利要求11所述的方法，其中在所述媒體對(duì)象的所述步驟期間，所述主控制器指示接收所述媒體對(duì)象的期望速率和在所述客戶(hù)處的資源可獲得性。
13.根據(jù)權(quán)利要求10所述的方法，其中客戶(hù)接收所述片段作為由多個(gè)客戶(hù)接收的、符合多播的傳輸方案的部分。
14.根據(jù)權(quán)利要求11所述的方法，其中所述主控制器使用基于傳輸控制協(xié)議和因特網(wǎng)協(xié)議(TCP/IP)的傳輸方案與第二主控制器進(jìn)行通訊，并且所述文件分區(qū)處理器使用UDP端口與服務(wù)器通訊。
15.一種用于傳輸媒體對(duì)象的設(shè)備，包括主控制器(120，150)，用于分區(qū)所述媒體對(duì)象；多個(gè)文件分區(qū)處理器(130，160)，用于傳輸所述分區(qū)的媒體對(duì)象的片段，其中所述主控制器(120，150)根據(jù)可獲得的文件分區(qū)處理器(130，160)來(lái)確定如何分區(qū)所述媒體對(duì)象，并且所述主控制器(120，150)將所述分區(qū)的媒體對(duì)象的片段分派給從多個(gè)文件分區(qū)處理器中選擇的文件分區(qū)處理器(130，160)。
16.根據(jù)權(quán)利要求15所述的設(shè)備，其中所述文件分區(qū)處理器經(jīng)由用戶(hù)數(shù)據(jù)報(bào)協(xié)議(UDP)端口來(lái)傳輸所述片段。
17.一種用于接收媒體對(duì)象的設(shè)備，包括主控制器(120，150)；和多個(gè)文件分區(qū)處理器(130，160)，用于接收分區(qū)的媒體對(duì)象的片段，其中所述主控制器(120，150)確定如何重新構(gòu)建所述分區(qū)的媒體對(duì)象的所述片段。
18.根據(jù)權(quán)利要求17所述的設(shè)備，其中所述文件分區(qū)處理器經(jīng)由用戶(hù)數(shù)據(jù)報(bào)協(xié)議(UDP)端口來(lái)接收所述片段。
全文摘要
公開(kāi)了一種通過(guò)網(wǎng)絡(luò)(170)傳輸所請(qǐng)求的媒體文件的方法和系統(tǒng)。服務(wù)器(115)的主控制器(120)將媒體對(duì)象分區(qū)。然后服務(wù)器的主控制器(120)將所述分區(qū)的媒體對(duì)象的片段分派給文件分區(qū)處理器(130)，以通過(guò)網(wǎng)絡(luò)(170)傳輸給請(qǐng)求該媒體對(duì)象的客戶(hù)(140)。文件分區(qū)處理器(130)通過(guò)網(wǎng)絡(luò)在用戶(hù)數(shù)據(jù)報(bào)協(xié)議(UDP)端口上將片段傳輸給客戶(hù)。然后當(dāng)將原始的片段成功地傳輸給客戶(hù)(140)時(shí)，主控制器(120)將所述分區(qū)的媒體對(duì)象的第二片段分派給文件分區(qū)處理器(130)。響應(yīng)于文件分區(qū)處理器(130，160)的可獲得性和客戶(hù)(140)指定的條件，來(lái)確定媒體對(duì)象的分段。
文檔編號(hào)G06F15/16GK1764897SQ200480007923
公開(kāi)日2006年4月26日 申請(qǐng)日期2004年3月29日 優(yōu)先權(quán)日2003年3月28日
發(fā)明者托馬斯·P·紐伯里, 克里·W·卡爾弗特 申請(qǐng)人:湯姆森特許公司