專利名稱：：基于拉的并行視頻服務器中的負載均衡和接納調(diào)度的制作方法基于拉的并行視頻服務器中的負載均衡和接納調(diào)度相關(guān)申請的交叉引用不適用對在聯(lián)邦贊助的研究和開發(fā)下實現(xiàn)的本發(fā)明的權(quán)利的聲明不適用參照以光盤形式提交的“序列表”、表或計算機程序附錄不適用
背景技術(shù)：
：本發(fā)明涉及視頻數(shù)據(jù)服務器技術(shù)，更具體地涉及基于并行服務器架構(gòu)的視頻點播系統(tǒng)及其相關(guān)的實現(xiàn)方法。更特別地，本發(fā)明涉及基于拉的并行視頻服務器中的負載均衡和接納調(diào)度。例如，JackY.B.Lee在1998年6月的IEEE多媒體第5(2)卷、第20-28頁上發(fā)表的"ParallelVideoServers-ATutorial(并行視頻服務器-指南)”以及JackY.B.Lee和P.C.Wong在2000年12月的IEEE學報并行分布系統(tǒng)第11(12)卷、第217-231頁發(fā)表的"PerformanceAnalysisofaPull-BasedParallelVideoServer(基于拉的并行視步頁服務器的性能分析)”研究和描述了基于拉的并行視頻服務器配置。不要將這些配置與服務器推送服務模型混淆，例如W.J.Bolosky、J.S.Barrera,R.P.Draves、R.P.Fitzgerald、G.A.Gibson,M.B.Jones,S.P.Levi、N.P.Myhrvold和R.F.Rashid在關(guān)于支持數(shù)字音頻和視頻的網(wǎng)絡和操作系統(tǒng)的第六次國際研討會期間發(fā)表的“TheTigerVideoFileserver(觸發(fā)器視頻文件服務器)”描述了服務器推送服務模型。M.M.Buddhikot和G.M.Parulkar于1996年4月在日本Zushi召開的IEEE計算機科學上發(fā)表的“EfficientDataLayout,SchedulingandPlayoutControlinMARS(MARS的有效數(shù)據(jù)格式、調(diào)度和播放控制)”Proc.N0SSDAV95,1995；以及M.Wu和ff.Shu在1996年10月的關(guān)于大規(guī)模并行算法新領(lǐng)域的第六次學術(shù)會議第126-133頁上發(fā)表的“SchedulingforLarge-ScaleParallelVideoServers(用于大規(guī)模并行視頻服務器的調(diào)度)”。下面給出了表1，包括符號和用于下文評價的典型數(shù)值。<table>tableseeoriginaldocumentpage4</column></row><table><table>tableseeoriginaldocumentpage5</column></row><table><table>tableseeoriginaldocumentpage6</column></row><table>并行視頻服務器具有多個獨立的服務器，這些服務器通過互連網(wǎng)絡連接至客戶主機?；ミB網(wǎng)絡可通過分組交換機(例如，快速以太網(wǎng)或ATM交換機)實現(xiàn)。每個服務器具有單獨的CPU、存儲器、磁盤存儲器和網(wǎng)絡接口。所謂的無共享方案確保系統(tǒng)的可擴縮性不會受到資源競爭的限制。通過互連網(wǎng)絡(例如，分組交換機)，客戶從每個服務器逐塊地取得視頻數(shù)據(jù)，并且重新排列該視頻數(shù)據(jù)用于播放。系統(tǒng)中服務器的數(shù)量可由Ns表示，客戶的數(shù)量可由N。表示。并行視頻服務器架構(gòu)背后的原理是將視頻標題劃分到系統(tǒng)的所有服務器上。服務器的存儲空間可分為固定大小的條帶單元，每個條帶單元為Q個字節(jié)。然后，將每個視頻標題劃分為Q字節(jié)的塊并且通過輪詢方式存儲到服務器中，如圖2所示。固定大小的塊劃分算法在如上所述的JackY.B.Lee的"parallelVideoServers-ΑTutorial(并行視頻服務器_指南)，，被稱為“空間劃分”，相對地，以視頻幀的單元劃分被稱為“時間劃分”。由于空間劃分中的條帶單元顯著小于視頻標題(千字節(jié)vs兆字節(jié))，因此使得良好增益負載能夠在服務器間共享。在下文中，在空間劃分方面描述本發(fā)明。服務器級別的并行使用不僅打破了單個服務器的容量限制，而且通過冗余實現(xiàn)了服務器級別的容錯。不同于服務器復制和數(shù)據(jù)劃分，在并行方案中，將可得到的視頻標題分為小的單元，然后通過所謂的服務器劃分技術(shù)將其分布到并行視頻服務器中的服務器上。然后，根據(jù)劃分策略(空間和/或時間)從服務器取得視頻標題的視頻數(shù)據(jù)單元，經(jīng)由通信網(wǎng)絡傳遞至客戶。由于視頻標題分布在系統(tǒng)中的所有服務器上，因此首先必須從相應的服務器取得視頻塊，然后將它們合并成單個視頻流并提交給客戶用于播放。通常，視頻數(shù)據(jù)合并處理(稱為代理)可在服務器中實現(xiàn)(服務器端代理)，在單獨的計算機中實現(xiàn)(獨立的代理)，或者在客戶計算機處實現(xiàn)(客戶端代理)。在下文中，所描述的系統(tǒng)采用客戶端代理體系結(jié)構(gòu)。該選擇為兩方面(a)較低的成本-不需要附加的服務器間數(shù)據(jù)傳送(服務器端代理)或附加的硬件(獨立的代理)；以及(b)更好的容錯-代理的錯誤只影響在同一計算機上運行的客戶。術(shù)語“服務模型”指調(diào)度視頻數(shù)據(jù)并將其傳遞給客戶的方式。有兩種普通的服務模型客戶拉拽和服務器推送。在客戶拉拽模型中，客戶周期性地將請求發(fā)送至服務器以取得視頻數(shù)據(jù)。在這種模型中，由客戶驅(qū)動數(shù)據(jù)流。在服務器推送模型中，一旦視頻會話開始，服務器調(diào)度周期性的視頻數(shù)據(jù)取得和傳送。在客戶拉拽服務模型中，從客戶發(fā)送的每個請求在獨立于所有其它服務器的服務器處被服務。因此，這些服務器不需要時鐘同步，因為同步包含在客戶請求中。在下文中，假設使用客戶拉拽服務模型。在不失普遍性的情況下，假設客戶將請求i((i>0)發(fā)送至第mod(i，Ns)個服務器。每個請求將觸發(fā)服務器，以取得和傳送Q字節(jié)的視頻數(shù)據(jù)。在常規(guī)的單個服務器視頻點播系統(tǒng)中不存在而在并行視頻服務器視頻點播系統(tǒng)中存在的問題是已知的負載均衡。當服務器通過小的條帶尺寸在服務器上劃分視頻標題，以確保平均負載均衡時，服務器的瞬時負載可能因系統(tǒng)的隨機性而改變。這種瞬時負載不均衡能夠暫時降低服務器的性能，并且使客戶處的視頻播放中斷。為了更好地理解本發(fā)明，在基于拉式服務的系統(tǒng)內(nèi)考慮請求產(chǎn)生過程的分析模型是有用的。這個模型的一部分是由發(fā)明人之前所開發(fā)的并且如上所述命名為“PerformanceAnalysisofaPull-BasedParallelVideoServer(基于拉的并行視頻服務器的性能分析)”。假設系統(tǒng)使用基于信用的流控制算法來管理從服務器到客戶的數(shù)據(jù)流，客戶保持Lc個視頻數(shù)據(jù)緩沖器(每個緩沖器為Q字節(jié))，以容納系統(tǒng)延遲變化。在播放開始之前，客戶首先預取第一個(Le-I)緩沖器，然后，在頭一行視頻塊提交給視頻解碼器用于播放時，再請求一個視頻塊。假設視頻客戶產(chǎn)生平均請求間的時間間隔為Tavg秒的請求，那么考慮請求產(chǎn)生過程中的變化，假設Tdv為該過程中的最大偏移，從而任何k個連續(xù)請求之間的時間范圍的界限如下max{(k_l)Tavg_TDV)，0}≤t≤((k_l)Tavg+TDV)(1)由于客戶以輪詢的方式產(chǎn)生請求至Ns個服務器，因此發(fā)送至相同的服務器的任意k個連續(xù)請求之間的相應時間范圍可從下式獲得max{(k_l)NsTavg-Tnv)，0}≤t≤((k_l)NsTavg+TDV)(2)通過這種請求產(chǎn)生模型，可得到定理1假設η個客戶獨立產(chǎn)生請求和每個客戶以輪詢的方式將請求發(fā)送至系統(tǒng)中的Ns個服務器，然后服務器接收k個視頻數(shù)據(jù)請求的最小時間為<formula>formulaseeoriginaldocumentpage7</formula>不考慮系統(tǒng)中服務器的數(shù)量，定理1說明如果多個客戶同步，那么服務器能夠同時接收多達η個請求(7^(Α:，/0=0)。先前已經(jīng)說明了這個客戶同步問題嚴重限制了系統(tǒng)的可擴縮性。為了防止瞬時負載不均衡，使用接納調(diào)度器精確地調(diào)度新視頻會話的開始時間，以避免同步。以前，發(fā)明人和其他人提出了如圖3(現(xiàn)有技術(shù))第一行(a)所描繪的、用于在接納調(diào)度器中使用的交錯方案。調(diào)度器維持長度為Tramd秒的調(diào)度映射表，并且分成長度為Tsl。t的Nsltrt個時隙<formula>formulaseeoriginaldocumentpage7</formula>(4)每個時隙具有兩種狀態(tài)空閑和占用。當客戶想要開始新的視頻會話時，首先將請求發(fā)送至調(diào)度器。忽略處理延遲并且假設請求在t時刻到達調(diào)度器，如果只有時隙η空閑，那么該調(diào)度器接納新的會話，其中n由下式給出n=[mod(t,Tround)Tslot](5)這由圖3b(現(xiàn)有技術(shù))中的第二行(b)示出。為了接納新會話，調(diào)度器在時隙n開始時將響應發(fā)送回客戶，并且將相應的時隙標記為被占用，直到會話結(jié)束。相反，如果所請求的時隙已經(jīng)被占用，那么調(diào)度器將等待(有效地增加t)直到得到空閑的時隙，如圖3(現(xiàn)有技術(shù))的第三行(c)所示。通過設Tramd=NsTavg，得到下面定理2中最壞情況的負載。定理2如果通過參數(shù)Traund=NsTavg使用接納調(diào)度器并且有n個客戶，那么服務器接收k個視頻數(shù)據(jù)請求的最小時間為<formula>formulaseeoriginaldocumentpage8</formula>其它(6)其中u=[(k-l)/n]，以及v=mod(k-l，n)與定理1相比，請求是由接納調(diào)度器傳播的，從而基本上減少了最壞情況的負載?；诶腣oD系統(tǒng)的關(guān)鍵性能指標是視頻服務器處的服務延遲，由Dmax表示。服務延遲被定義為從服務器接收到客戶請求的時刻到全部發(fā)送完所請求的視頻塊的時刻。這個服務延遲確定了客戶所需的緩沖器的量，以確保視頻播放的連續(xù)性。由于服務延遲通常隨著同時發(fā)生的視頻會話的數(shù)量而增加，因此有效地利用對可由系統(tǒng)支持的同時發(fā)生的視頻會話的最大數(shù)量的限制。給定定理2中的磁盤模型、網(wǎng)絡模型和界限，可得到服務器延遲的上限。這個最大服務延遲用于評價不同參數(shù)下的系統(tǒng)性能。先前已經(jīng)說明接納調(diào)度器能夠有效地防止瞬時負載不均衡，并且使系統(tǒng)擴展至大量的服務器。然而，有兩個假設(a)沒有網(wǎng)絡延遲以及(b)在傳遞控制消息時不丟包。迄今為止所描述的且如上所述從本發(fā)明人之前的論文“PerformanceAnalysisofaPull-BasedParallelVideoServer(基于拉的并行視頻服務器的性能分析)，，的模型不并入網(wǎng)絡延遲和延遲抖動的影響，并且不考慮丟包。本發(fā)明人開發(fā)的現(xiàn)有模型中未考慮的問題是客戶-調(diào)度器鏈路和客戶-服務器鏈路中的丟包。盡管丟包在當今的高速網(wǎng)絡中相對較少發(fā)生，但是它仍然不能被忽略。首先，在客戶與調(diào)度器之間丟失控制包將使系統(tǒng)的狀態(tài)不一致。例如，如果從調(diào)度器發(fā)送至客戶的接納_接受請求丟失，那么客戶可能在發(fā)現(xiàn)包丟失之前需要等待NsTavg的完整調(diào)度周期，由于在最壞的情況中，接納調(diào)度器可能甚至因交錯要求而需要延遲接納新的會話。同時，即使客戶從未開始視頻會話，但是所分配的時隙將被占用相同的時間。結(jié)果，即使系統(tǒng)在容量之下運行，但是新的接納請求也可能被拒絕。第二，由于服務器只有在接收到客戶請求時發(fā)送視頻數(shù)據(jù)，因此在客戶-服務器鏈路中丟失控制包將導致丟失視頻塊。因此，用于客戶_調(diào)度器鏈路和客戶_服務器鏈路的控制路徑必須可靠。為了解決丟包問題，可使用可靠的傳輸協(xié)議來運送控制包。然而，不同于傳統(tǒng)的數(shù)據(jù)應用，傳輸協(xié)議的選擇會對系統(tǒng)性能有顯著影響。為了找到原因，將TCP作為客戶-調(diào)度器鏈路的傳輸協(xié)議。如果發(fā)生丟包，TCP協(xié)議將超時并且重發(fā)包，直到包被正確傳遞或者鏈路被認為已經(jīng)失敗。由于大多數(shù)傳輸協(xié)議(包括TCP)使用自適應算法，以動態(tài)地調(diào)整超時閾值，所以如果需要多次重發(fā)，那么實質(zhì)上增加了超時。在實踐中，由這種傳輸協(xié)議引起的最壞情況的延遲可能長達幾十秒。與平均網(wǎng)絡延遲(毫秒)相比，如果使用這種傳輸協(xié)議運送控制業(yè)務，那么將顯著增加服務器處的最壞情況的負載。已經(jīng)確定可能發(fā)生瞬時負載不均衡，該瞬時負載不均衡顯著妨礙拉式并行視頻系統(tǒng)的性能。接納調(diào)度器對保持系統(tǒng)中服務器上的瞬時負載均衡是至關(guān)重要的，其還可稱為整個系統(tǒng)的失敗單點。因此，需要一種體系結(jié)構(gòu)和支持處理來避免基于拉的體系結(jié)構(gòu)的失敗點和性能惡化。
發(fā)明內(nèi)容根據(jù)本發(fā)明，在點播視頻系統(tǒng)中有用的基于拉的并行視頻服務器系統(tǒng)及其實現(xiàn)方法包括多個從接納調(diào)度器，從接納調(diào)度器與主接納調(diào)度器并行操作，以支持主接納調(diào)度器，主接納調(diào)度器根據(jù)說明抖動和丟包的協(xié)議以及網(wǎng)絡延遲，控制對基于拉的視頻服務器陣列的訪問。提供在這種情況下提高視頻數(shù)據(jù)吞吐量的傳輸協(xié)議。為了確定冗余接納調(diào)度器的體系結(jié)構(gòu)和功能要求，開發(fā)了性能模型形式的分析工具，該分析工具并入了客戶、調(diào)度器和服務器之間通信鏈路的網(wǎng)絡延遲、延遲抖動和丟包。這個模型是本發(fā)明人之前開發(fā)且在上述的“PerformanceAnalysisofaPull-BasedParallelVideoServer(基于拉的并行視頻服務器的性能分析)”所提到的模型的擴展。參照下面結(jié)合附圖的詳細描述將能更好地理解本發(fā)明。圖1是根據(jù)本發(fā)明的系統(tǒng)框圖和根據(jù)本發(fā)明方法的操作；圖2是根據(jù)一個現(xiàn)有技術(shù)發(fā)明的基于五個服務器的并行視頻服務器系統(tǒng)的視頻劃分的圖解；圖3是圖示了基于現(xiàn)有技術(shù)的視頻調(diào)度器的三種操作的時隙圖，即，(a)具有周期^；—和Nsl。t個接納時隙的接納調(diào)度器布局；(b)如果所請求的時隙空閑，那么立即準許新的視頻會話；以及(c)延遲新的視頻會話，直到得到空閑的時隙；圖4是兩個接納調(diào)度器的時隙圖，圖示了可能在現(xiàn)有技術(shù)中發(fā)生的因時鐘抖動而引起的時隙分配不一致；圖5是在具有和沒有接納調(diào)度情況下比較最大服務延遲與平均網(wǎng)絡延遲的時間圖表。具體實施例方式圖1是根據(jù)本發(fā)明的視頻點播系統(tǒng)10的框圖和根據(jù)本發(fā)明方法的操作，并且圖示了復制的接納調(diào)度器。通常，大量的視頻客戶12、14、16經(jīng)由一個或多個通信鏈路18連接至接納調(diào)度器22、24、26的集合20，接納調(diào)度器22、24、26中的一個被指定為主接納調(diào)度器20，其它接納調(diào)度器被指定為從接納調(diào)度器24、26。主接納調(diào)度器20經(jīng)由通信鏈路30連接至并行視頻服務器28的集合，并且建立接納映射表(該接納映射表在從接納調(diào)度器24、26的每一個中被獨立復制)用于控制經(jīng)由通信鏈路32、34、36輸出至各自的視頻客戶12、14,16的流視頻。接納調(diào)度器彼此之間經(jīng)由通信鏈路38、40、42進行多點傳送，如下文所解釋的?；谌鐖D1所描繪的復制方案，NA個相同的接納調(diào)度器22、24、26同時工作。每個接納調(diào)度器22、24、26在單獨的計算節(jié)點內(nèi)運行，其目的是只要接納調(diào)度器22、24、26中的至少一個仍然起作用，就保持系統(tǒng)運轉(zhuǎn)。由于存在多于一個的接納調(diào)度器，因此客戶_調(diào)度器通信的協(xié)調(diào)是必要的。第一嘗試可能是讓客戶將請求同時發(fā)送至所有Na個調(diào)度器，一旦來自調(diào)度器中的任一個的應答返回，那么客戶開始會話。然而，如果客戶-調(diào)度器鏈路延遲不是恒定的或者調(diào)度器的時鐘不同步，那么這個方法會導致接納調(diào)度器之間的狀態(tài)不一致。圖4通過兩個接納調(diào)度器和三個客戶圖示了這個問題。請求的特定次序和調(diào)度器之間的時鐘抖動導致兩個調(diào)度器上不一致的時隙分配，因為接納請求產(chǎn)生了彼此相比無序的接納許可。為了解決這個問題，根據(jù)本發(fā)明，所采用的方案是在任一時間只有一個接納調(diào)度器處于活動控制。主接納調(diào)度器22負責通過經(jīng)由通信鏈路38、40周期性地多點傳送已更新的狀態(tài)信息(接納映射表)，從而更新其它從調(diào)度器24、26中的狀態(tài)。這個方案中存在三個關(guān)鍵部分(a)心跳協(xié)議，檢測調(diào)度器失??；(b)選舉程序，當當前的主調(diào)度器失敗時動態(tài)地選舉新的主調(diào)度器；以及(c)引導協(xié)議，用于用戶在客戶站初始化過程中定位主調(diào)度器。這些部分中的每一個將在下文討論。為了提高與前述定理相關(guān)聯(lián)且在之前的附圖中圖示的接納調(diào)度器模式的效用，公開了由定理支持的下面部分。為客戶與接納調(diào)度器之間的平均網(wǎng)絡延遲，以說明網(wǎng)絡延遲的變化，假設延遲抖動由DA+和Da_限制，從而保證由dA表示的實際延遲為(Da+D~a)<dA<(Da+D)(7)這個附加的延遲影響視頻會話的開始時間，這是因為來自調(diào)度器的接納應答在到達客戶之前受到這個延遲的影響。具體地，視頻客戶將在調(diào)度器許可接納之后的dA秒開始發(fā)送第一視頻請求。類似地，設Ds為客戶與視頻服務器之間的平均網(wǎng)絡延遲，以及Ds+、Ds_為相應的延遲抖動，那么保證由ds表示的實際延遲為(Ds+D~)<ds<(Ds+D+s)(8)這個額外的延遲增加了請求到達服務器的時間變化。實際上，如果網(wǎng)絡(例如，ATM)提供服務質(zhì)量保證，那么這些延遲和延遲抖動可先驗確定。否則，其可通過基準測試進行實驗性地評估。由于客戶_服務器鏈路延遲和延遲抖動，因此請求產(chǎn)生時間與請求到達服務器的時間不同。由于客戶-服務器鏈路延遲由抖動限制，因此說明了從同一客戶發(fā)送的k個請求到達服務器的時間由下式限制<formula>formulaseeoriginaldocumentpage10</formula>將其并入，并將因客戶-調(diào)度器鏈路延遲抖動引起的開始時間變化并入，下面的定理3擴展了定理2，以建立k個請求到達服務器的時間范圍的下限定理3假設網(wǎng)絡延遲抖動Da+、Da-、Ds+和Ds_，服務器接收來自n個客戶的k個視頻數(shù)據(jù)請求的最小時間由下式給出<formula>formulaseeoriginaldocumentpage11</formula>其中u=[(k-l)/n]，以及v=mod(k-l，n)已知服務器處的最壞情況下的負載，那么可得到各種性能質(zhì)量，包括服務器處的最大服務延遲和客戶處的客戶緩沖器要求。為了避免在丟包的過程中發(fā)生不必要的延遲，需要可靠且時間敏感的傳輸協(xié)議，從而所導致的延遲不會過長。由于延遲抖動有界限，因此超時限制實際上不需要為自適應的。代替使用復雜的自適應超時和重傳算法，使用簡單且有效的可靠數(shù)據(jù)報協(xié)議(RDP)，該RDP具有可編程的超時和重傳參數(shù)。特別地，該協(xié)議使用恒定不變的超時限制T。ut和最大的重傳次數(shù)Nretx，這兩參數(shù)在系統(tǒng)初始化過程中通過應用程序進行配置。超時閾值可根據(jù)客戶-調(diào)度器鏈路和客戶-服務器鏈路中的延遲和延遲抖動進行選擇其中，T。utA和T。uts分別為客戶_調(diào)度器鏈路和客戶_服務器鏈路的超時閾值。類似地，可根據(jù)希望的最大丟包概率3選擇最大的重傳次數(shù)<formula>formulaseeoriginaldocumentpage11</formula>其中，Ps分別為客戶-調(diào)度器鏈路和客戶-服務器鏈路的丟包概率。通過重新調(diào)整一個可獲得所需的參數(shù)<formula>formulaseeoriginaldocumentpage11</formula>在RDP下，由該協(xié)議引起的最大延遲(S卩，不包括網(wǎng)絡延遲)由T。ut(NMtx_l)限制。由于如果不發(fā)生重傳，那么RDP不會引起任何附加延遲，因此所引起的延遲可被合并作為除了Da+和Da_以外的附加延遲抖動<formula>formulaseeoriginaldocumentpage11</formula>因此，可將定理3擴展為并入新的延遲抖動。定理4給定(14)式中因丟包而引起的延遲抖動，那么服務器接收來自n個客戶的k個視頻數(shù)據(jù)請求的最小時間為<formula>formulaseeoriginaldocumentpage12</formula>其中u=[(k-l)/n]，以及v=mod(k-l，n)(15)根據(jù)本發(fā)明，實施心跳協(xié)議。每個復制的接納調(diào)度器經(jīng)由通信鏈路38、40、42、每隔Thb秒將心跳包多點傳送至所有其它的調(diào)度器。如果未從特定的調(diào)度器22接收到Nhb個連續(xù)心跳包，那么將被認為已經(jīng)失敗。忽略網(wǎng)絡延遲，所有其它調(diào)度器24、26在最大延遲之后將發(fā)現(xiàn)調(diào)度器失敗，該最大延遲如下式所示DF=ThbNhb(16)主調(diào)度器的心跳包在兩個方面不同于從調(diào)度器的心跳包。首先，它包含位矢量，該位矢量記錄了接納映射表的當前狀態(tài)。從調(diào)度器24、26在接收到這個位矢量時更新它們的接納映射表，以與主調(diào)度器22同步。其次，只要接納映射表發(fā)生狀態(tài)變化，就產(chǎn)生心跳包。因此，心跳間隔可小于Thb。每個調(diào)度器22、24、26維持起作用的接納調(diào)度器的列表。假設每個調(diào)度器在具有唯一IP地址的單獨計算機上運行，該列表可通過調(diào)度器的IP地址構(gòu)成，并且可通過將4字節(jié)的IP地址處理為無符號整數(shù)而對該列表分類?；谛奶鴧f(xié)議，將失敗的調(diào)度器從列表上刪除，并且將新的(和已修復的)調(diào)度器插入列表中。這個列表用于選舉新的主調(diào)度器，如下文所討論的。下面說明用于心跳協(xié)議的偽代碼。心跳協(xié)議的偽代碼狀態(tài)變量AdmissionMap-捕獲接納映射表的狀態(tài)的位矢量FunctionalSchedulers-起作用調(diào)度器的列表Procedure_Generate_Heartbeats(Thb)(程序_產(chǎn)生_心跳){0094]while(systemrunning)(當(系統(tǒng)運行)){0095]ifadmissionschedulerisMasterthen(如果接納調(diào)度器為主調(diào)度0096]器，那么)0097]MulticastsaheartbeatpacketcontainingAdmissionMap(0098]傳送包含AdmissionMap的心跳包)；0099]else(否則)0100]Multicastsaheartbeatpacketw/oAdmissionMap(多點傳送不0101]具有AdmissionMap的心跳包)0102]Sle印(Thb)(休眠)；0103]}0104]}0105]Procedure_Receive_Heartbeat(scheduleri)(禾呈;^__；^^(ijfjf0106]器i))0107]{0108]ifscheduleriisnotinFunctionalSchedulersthen(如果調(diào)度器i不0109]在FunctionalSchedulers內(nèi)，那么)addscheduleritoFunctionalSchedulers(將調(diào)度器i添力口至ljFunctionalSchedulers內(nèi))ifscheduleriisMasterthen(如果調(diào)度器i是主調(diào)度器，那么)UpdateAdmissionMap(更新AdmissionMap)；}Procedure_Detect_Scheduler_Failure()(程序_檢測_調(diào)度器){while(systemrunning)(當(系統(tǒng)運行)){foreachschedulerinFunctionalSchedulers(對于FunctionalSchedulers中的每個調(diào)度器){ifnoheartbeatsreceivedforDFsecondsthen(如果DF禾少內(nèi)未接收到心跳包，那么){removeschedulerfromFunctionalSchedulers(將調(diào)度器從FunctionalSchedulers中去除)；ifschedulerisMasterthenrunProcedure—Election()(如果調(diào)度器是主調(diào)度器，那么運行程序_選舉)0110]0111]0112]0113]0114]0115]0116]0117]0118]0119]0120]0121]0122]0123]0124]0125]0126]0127]}0128]}0129]}0130]}0131]如果從調(diào)度器失敗，那么不需要采取任何行動，因為只有主調(diào)度器22用于接納。所有起作用的調(diào)度器僅在未接收到來自失敗的調(diào)度器的Nhb個連續(xù)心跳包之后記錄該失敗。相反，如果主調(diào)度器22失敗，那么必須啟動選舉程序。由于每個從調(diào)度器維持起作用的調(diào)度器的列表，因此列表頂部的那個調(diào)度器將被選為新的主調(diào)度器。這個選舉程序不需要在調(diào)度器之間交換數(shù)據(jù)。接著，這個新的主調(diào)度器將消息廣播至所有調(diào)度器和所有客戶，以通知他們該選舉結(jié)果。選舉程序只有在檢測到主調(diào)度器失敗時才發(fā)生。因此，如果失敗的調(diào)度器回到聯(lián)機狀態(tài)，那么它將不會被重新選為主調(diào)度器，直到當前的主調(diào)度器失敗。下面說明選舉程序的偽代碼。選舉程序偽代碼狀態(tài)變量AdmissionMap-捕獲接納映射表的狀態(tài)的位矢量FunctionalSchedulers-起作用的調(diào)度器的列表Procedure_Election()(程序_選舉){New_master=scheduleratthetopofFunctionalSchedulers(新_主=位于FunctionalSchedulers頂部的調(diào)度器)；ifmyselfisNew_masterthen(如果自身為新_主，那么)MulticastelectionresultandAdmissionMaptoallschedulers(將選舉結(jié)果和AdmissionMap多點傳送至所有的調(diào)度器)}盡管活動的客戶12、14、16總是通過收聽調(diào)度器的廣播消息來得知哪個調(diào)度器為當前的主調(diào)度器，但是新初始化的客戶(例如，在上電或重啟之后)不知道哪個調(diào)度器為主調(diào)度器。在這種情況下，客戶使用引導協(xié)議來定位當前的主調(diào)度器。特別地，新啟動的客戶首先通過域名系統(tǒng)(DNS)獲得所有調(diào)度器22、24、26的IP地址列表。這個操作可通過將所有的調(diào)度器IP地址與單個主機名(例如，admission,xxx.com)相關(guān)聯(lián)來實現(xiàn)。然后，通過這個列表，客戶將詢問消息發(fā)送至列表頂部的調(diào)度器，以請求當前主調(diào)度器的地址。當應答返回到客戶時，該過程結(jié)束。否則，客戶嘗試列表中的第二調(diào)度器，直到應答返回。只要調(diào)度器中的至少一個起作用，客戶就能夠定位當前的主調(diào)度器并且初始化新的視頻會話。下面說明了這種弓I導協(xié)議的偽代碼。引導協(xié)議的偽代碼狀態(tài)變量AdmissionMap-捕獲接納映射表的狀態(tài)的位矢量FunctionalSchedulers-起作用的調(diào)度器的列表ListOfAllSchedulers-所有調(diào)度器(運轉(zhuǎn)或未運轉(zhuǎn))的列表Procedure_Bootstrap_Request()(程序_弓|導_請求){ObtainListOfAllSchedulersfromDNS(從DNS獲得ListOfAllSchedulers)；ForeachschedulerinListOfAllSchedulers(對于ListOfAllSchedulers中的每個調(diào)度器){}14SendquerytoschedulertorequestaddressofcurrentMaster(>|奪詢問發(fā)送至調(diào)度器，以請求當前主調(diào)度器的地址)；ifnoreplyfromschedulerafteratimeToutthennextscheduler(如果在Tout時間之后調(diào)度器沒有應答，那么到下一個調(diào)度器)；ifreceivedreplyfromschedulerthen(如果從調(diào)度器接收至lj應答，那么){updateAdmissionMapandFunctionalSchedulers(更新AdmissionMap禾口FunctionalSchedulers)；exit(退出)；}}Procedure_Bootstrap_Reply()(程序_弓|導_應答){While(systemrunning)(當(系統(tǒng)運行)){Waitforbootstraprequestmessage(等待弓|導請求消息)；ReplyaddressofMaster,AdmissionMap,andFunctionalSchedulers(以主調(diào)度器的地址、AdmissionMap禾口FunctionalSchedulers應答)；}}根據(jù)本發(fā)明的復制方案可以兩種方式影響系統(tǒng)的負載均衡。首先，由于每個調(diào)度器在單獨的計算機內(nèi)運行，所以它們的內(nèi)部時鐘未被精確同步。假設使用時鐘同步協(xié)議以將任意兩個調(diào)度器之間的時鐘抖動保持在最大值為De秒內(nèi)，那么當主調(diào)度器失敗并且新選舉的主調(diào)度器接管時，現(xiàn)有客戶的開始時間相對于新的主調(diào)度器的時鐘至多偏移De秒。如下所述可將這種抖動并入本發(fā)明的系統(tǒng)模型中定理5給定調(diào)度器的最大時鐘抖動De，那么服務器從n個客戶接收k個視頻數(shù)據(jù)請求的最小時間為<formula>formulaseeoriginaldocumentpage15</formula>盡管主調(diào)度器多點傳送用于對接納映射表的每次更新的心跳包，但是這個包仍然可能丟失。如果主調(diào)度器失敗，那么不能將更新傳播至一些從調(diào)度器。假設不多于(Nhb-1)個連續(xù)心跳包丟失，如果調(diào)度器起作用，那么主調(diào)度器和從調(diào)度器的接納映射表可至多相差(Nhb_l)個時隙。在主調(diào)度器失敗的情況下，可將這些時隙分配至兩個客戶。等式(17)可被擴展用于說明這種狀態(tài)不一致性<formula>formulaseeoriginaldocumentpage15</formula>等式(18)說明只有一個調(diào)度器失敗的情況-這對于大多數(shù)實際目的應該足夠了。如果不可忽視多個調(diào)度器失敗的可能性，那么等式(18)可通過類似的推導被擴展以說明多個調(diào)度器失敗。為了實現(xiàn)，與本發(fā)明相關(guān)聯(lián)的系統(tǒng)和技術(shù)不能具有最大服務延遲，該服務延遲太長使得系統(tǒng)不能有效地對終端用戶、視頻客戶做出響應。3秒被認為是可接受的最大服務延遲。基本參數(shù)在上面的表1中給出。圖5是評估結(jié)果的實施例，示出了最大服務延遲與抖動為+/_10%的網(wǎng)絡延遲的比較結(jié)果。為了比較目的，還繪出了在不存在接納調(diào)度器情況下的最大服務延遲?；诒?的參數(shù)，各種情況下的最大服務延遲與丟包、最大服務延遲與最大調(diào)度器時鐘抖動以及最大服務延遲與調(diào)度器失敗時鐘抖動的進一步評估已經(jīng)產(chǎn)生了不大于1.2秒的最大服務延遲。已經(jīng)參考具體實施方式解釋了本發(fā)明。其它實施方式對本領(lǐng)域的普通技術(shù)人員來說是顯而易見的。因此，本發(fā)明不受限于此，而是受限于所附權(quán)利要求的語言。權(quán)利要求一種具有多個基于拉的視頻服務器的基于拉的并行視頻服務器系統(tǒng)，被操作為在所述多個基于拉的視頻服務器上存儲視頻數(shù)據(jù)的條帶，以用于對多個客戶的視頻觀看請求提供服務，所述客戶不同時地產(chǎn)生所述視頻觀看請求，所述視頻服務器系統(tǒng)包括主接納調(diào)度器，以控制關(guān)系與所述視頻服務器連接；至少一個從接納調(diào)度器，其被連接，以從所述主接納調(diào)度器接收控制信號，所述主接納調(diào)度器被操作為協(xié)調(diào)所述從接納調(diào)度器，從而在時間和空間上對來自任何所述客戶的觀看請求進行調(diào)度，以使所述視頻服務器中的任一個的過載最小，并且使所述主接納調(diào)度器和所述從接納調(diào)度器中的任一個能夠在不中斷響應于所述觀看請求的服務的情況下被更換。2.根據(jù)權(quán)利要求1所述的視頻服務器系統(tǒng)，其中，所述主接納調(diào)度器被操作為周期性地多點傳送更新的狀態(tài)信息，以將所述從接納調(diào)度器中的狀態(tài)更新為接納映射表。3.根據(jù)權(quán)利要求2所述的視頻服務器系統(tǒng)，包括使用心跳協(xié)議檢測至少所述主接納調(diào)度器中的失敗的代碼；以及在所述主接納調(diào)度器失敗的情況下根據(jù)選舉協(xié)議動態(tài)選舉新的主接納調(diào)度器的代碼。4.根據(jù)權(quán)利要求3所述的視頻服務器系統(tǒng)，其中，所述心跳協(xié)議被操作為使用心跳包，所述心跳包在所述接納映射表發(fā)生狀態(tài)變化時產(chǎn)生，并且所述心跳包包含記錄所述接納映射表的當前狀態(tài)的位矢量，從而能夠使心跳包之間的間隔最小，以促進快速轉(zhuǎn)變。5.根據(jù)權(quán)利要求3所述的視頻服務器系統(tǒng)，其中，所述心跳協(xié)議被操作為當未從所述調(diào)度器接收到所選擇數(shù)量的連續(xù)心跳包時，建立任意所述調(diào)度器的失敗。6.根據(jù)權(quán)利要求1所述的視頻服務器系統(tǒng)，其中，使用可靠數(shù)據(jù)報協(xié)議(RDP)，所述可靠數(shù)據(jù)報協(xié)議具有能夠預先選擇的超時和重傳參數(shù)，所述協(xié)議利用恒定的超時限制T。ut和最大的重傳次數(shù)Nretx，其中，根據(jù)如下關(guān)系式，根據(jù)客戶-調(diào)度器鏈路A和客戶-服務器鏈路S中的延遲D和延遲抖動D+選擇超時閾值<formula>formulaseeoriginaldocumentpage2</formula>其中，T0UtA和T0Uts為所述客戶-調(diào)度器鏈路和所述客戶-服務器鏈路的超時閾值。7.根據(jù)權(quán)利要求6所述的視頻服務器系統(tǒng)，其中，預先選擇超時和重傳參數(shù)，以使得對于終端用戶的最大服務延遲不超過大約3秒。8.根據(jù)權(quán)利要求1所述的視頻服務器系統(tǒng)，其中，預先選擇超時和重傳參數(shù)，以使得對于終端用戶的最大服務延遲不超過大約3秒。9.根據(jù)權(quán)利要求2所述的視頻服務器系統(tǒng)，進一步包括在作為引導協(xié)議的一部分的客戶站初始化過程中，通過詢問所述調(diào)度器來定位所述主接納調(diào)度器的代碼。10.一種用于觀看請求的負載均衡和接納調(diào)度的方法，在具有多個基于拉的視頻服務器的基于拉的并行視頻服務器系統(tǒng)中，所述視頻服務器系統(tǒng)被操作為在所述多個基于拉的視頻服務器上存儲視頻數(shù)據(jù)的條帶，以用于對多個客戶的視頻觀看請求提供服務，所述客戶不同時地產(chǎn)生所述視頻觀看請求，所述方法包括在主接納調(diào)度器處接收所述觀看請求，所述主接納調(diào)度器以控制關(guān)系與所述視頻服務器連接；在至少一個從接納調(diào)度器處接收所述觀看請求的副本，所述從接納調(diào)度器被連接，以從所述主接納調(diào)度器接收控制信號；僅通過與所述從接納調(diào)度器協(xié)調(diào)的所述主接納調(diào)度器進行調(diào)度，從而在時間和空間上對來自任意所述客戶的觀看請求進行調(diào)度，以使所述視頻服務器中的任一個的過載最小，并且使所述主接納調(diào)度器和所述從接納調(diào)度器中的任一個能夠在不中斷響應于所述觀看請求的服務的情況下被更換。11.根據(jù)權(quán)利要求10所述的方法，其中，所述主接納調(diào)度器周期性地多點傳送更新的狀態(tài)信息，以將所述從接納調(diào)度器中的狀態(tài)更新為接納映射表。12.根據(jù)權(quán)利要求11所述的方法，其中，所述方法包括使用心跳協(xié)議檢測至少所述主接納調(diào)度器中的失?。灰约霸谒鲋鹘蛹{調(diào)度器失敗的情況下根據(jù)選舉協(xié)議動態(tài)選舉新的主接納調(diào)度器。13.根據(jù)權(quán)利要求12所述的方法，其中，所述心跳協(xié)議使用心跳包，所述心跳包在所述接納映射表發(fā)生狀態(tài)變化時產(chǎn)生，并且所述心跳包包含記錄所述接納映射表的當前狀態(tài)的位矢量，從而能夠使心跳包之間的間隔最小，以促進快速轉(zhuǎn)變。14.根據(jù)權(quán)利要求12所述的方法，其中，當未從所述調(diào)度器接收到所選擇數(shù)量的連續(xù)心跳包時，所述心跳協(xié)議建立任意所述調(diào)度器的失敗。15.根據(jù)權(quán)利要求10所述的方法，其中，使用可靠數(shù)據(jù)報協(xié)議(RDP)，所述可靠數(shù)據(jù)報協(xié)議具有能夠預先選擇的超時和重傳參數(shù)，所述協(xié)議利用恒定的超時限制T。ut和最大的重傳次數(shù)Nretx，其中，根據(jù)如下關(guān)系式，根據(jù)客戶_調(diào)度器鏈路A和客戶-服務器鏈路S中的延遲D和延遲抖動D+選擇超時閾值<formula>formulaseeoriginaldocumentpage3</formula>其中，T0UtA和T。uts為所述客戶-調(diào)度器鏈路和所述客戶-服務器鏈路的超時閾值。16.根據(jù)權(quán)利要求15所述的方法，其中，預先選擇超時和重傳參數(shù)，使得對于終端用戶的最大服務延遲不超過大約3秒。17.根據(jù)權(quán)利要求10所述的方法，其中，預先選擇超時和重傳參數(shù)，使得對于終端用戶的最大服務延遲不超過大約3秒。18.根據(jù)權(quán)利要求10所述的方法，進一步包括在作為引導協(xié)議的一部分的客戶站初始化過程中，通過詢問所述調(diào)度器來定位所述主接納調(diào)度器。全文摘要在視頻點播系統(tǒng)中有用的基于拉的并行視頻服務器系統(tǒng)及其實現(xiàn)方法，該基于拉的并行視頻服務器系統(tǒng)包括多個從接納調(diào)度器，所述從接納調(diào)度器與主接納調(diào)度器并行操作，以支持主接納調(diào)度器，該主接納調(diào)度器根據(jù)說明抖動和丟包以及網(wǎng)絡延遲的協(xié)議，控制對基于拉的視頻服務器的訪問。提供傳輸協(xié)議來提高這種條件下的視頻數(shù)據(jù)吞吐量。為了確定冗余接納調(diào)度器的體系結(jié)構(gòu)和功能要求，已經(jīng)開發(fā)了性能模式的分析工具，該分析工具合并了客戶、調(diào)度器和服務器之間的通信鏈路上的網(wǎng)絡延遲、延遲抖動和丟包。文檔編號H04L12/56GK101809949SQ200880107891公開日2010年8月18日申請日期2008年9月19日優(yōu)先權(quán)日2007年9月19日發(fā)明者李耀斌申請人:香港中文大學