[發明專利]實時協議流遷移

無效

• 申請號: 200780053537.2
• 申請日: 2007-06-26
• 公開（公告）號: CN101690136A
• 公開（公告）日: 2010-03-31
• 發明（設計）人: 阿什萬·S·凱史亞普
• 申請（專利權）人: 湯姆遜許可證公司
• 主分類號: H04L29/14
• 分類號: H04L29/14
• 代理公司: 北京東方億思知識產權代理有限責任公司
• 代理人: 宋 鶴;南 霆

技術領域

本原理總地涉及數據流傳輸通信，并且更具體地涉及用于提供實時流傳輸通信的故障轉移(fail?over)能力的系統和方法。

背景技術

各種豐富的媒體網站通過因特網向消費者越來越多地提供大量音頻和視頻數據。結果，流傳輸數據以日益增加的量通過因特網被發送。

然而，音頻和視頻流傳輸的性質需要到流傳輸服務器的恒定連接以供音頻/視頻回放。在2003年7月的因特網工作組文檔RFC?3550中所描述的實時流傳輸協議(RTSP)一般地規定了必須按相對順序被遞送給客戶端的數據在離散分組(discrete?packet)中傳輸。另外，如果流傳輸服務器遇到了阻止服務器進一步發送流數據的故障，則客戶端體驗將經受惡化、時斷時續或者完全的顯示故障。

已提出了用于修理出故障的基于流傳輸服務器的連接的若干方法。例如，使用連接遷移(migration)的細粒度故障轉移描述了一種用于提供通過通過代理因特網協議地址來路由各個流傳輸連接的TCP故障轉移能力的方法。(Alex?C.Snoeren，David?G.Andersen和Hari?Balakrishnan的Fine-grained?failover?using?connection?migration，學報the?3rd?USENIX?Symposiumon?Internet?Technologies?and?Systems，第221-232頁，USENIX，2001)。該方法提出，如果數據服務器出現故障，則副服務器將接替主服務器的角色。然而，這種傳輸不知應用層協議，并且取決于應用，可能需要頻繁的狀態同步。

一種流遷移的當前實現方式可在RealNetwork^TM的Helix^TM服務器中見到。Helix^TM流遷移包括：如果初始服務器出現故障，則使得客戶端媒體播放器應用連接到備用服務器。Helix^TM實現了一些基本故障轉移機制。然而，這些故障轉移機制未解決服務器在直播流傳輸期間出現故障的問題。其工作的方式是給予客戶端備用服務器的列表，并且在服務器出現故障的情況中，客戶端自己必須從備用服務器請求新的連接。因此，如果主服務器不工作，則對信息進行處理是客戶端的責任。然而，由于用戶可以感知到服務器出現故障，因此用戶體驗質量受到影響，并且在建立新的流之前，可能由于對通過諸如因特網之類的通信網絡接收到的信息的緩沖以及時延而花費不可接受的時間。

發明內容

本原理提出了一種用于獨立于客戶端而相對于客戶端透明地監視并遷移RTSP傳輸并且允許不必在客戶端處完成故障轉移處理來實現故障轉移的系統和方法。

根據一個方面，通過用于監視發送實時協議(RTP)分組的RTSP流并將其遷移到備用服務器的系統和方法實現了實時流傳輸協議(RTSP)監視以及故障轉移處理的原理，包括：打開流傳輸會話并且開始從主服務器到客戶端的數據傳送流；由至少一個備用服務器來ping主服務器；并且判斷主服務器是活動的還是不活動的。當判定主服務器是不活動的時，該方法還可以包括：由備用服務器接管主服務器的因特網協議(IP)地址；循環經過主服務器的打開的流傳輸會話；將傳輸控制協議(TCP)連接從主服務器遷移到備用服務器；得到每個打開的流傳輸會話的RTP會話流狀態；并且利用所得到的RTSP會話流狀態恢復從備用服務器到客戶端的RTSP會話流傳輸。當判定主服務器是活動的時，該方法還可以包括以下步驟：等待預定時間；并且返回所述由至少一個備用服務器ping所述主服務器的步驟。

在考慮到將結合附圖詳細描述的說明性實施方式后，將更全面地了解本原理的優點、性質以及各種其它特征。

附圖說明

在附圖中，相似的標號表示附圖中的類似組件，其中：

圖1是現有技術中公知的實時流傳輸網絡系統的示圖。

圖2是根據本原理的實時流傳輸網絡系統的示圖。

圖3是根據本原理用于在主服務器出現故障時將實時流遷移到備用服務器的方法的框圖。

應當明白，附圖是用于圖示說明本原理的概念的目的的，而不一定是用于圖示說明本原理的僅有的可能配置。

具體實施方式