JP2010503906A - コンテンツ配信システムのためのファイル回復方法 - Google Patents

Abstract

【課題】
本発明は、受信ファイルを回復するファイル回復方法に関する。
【解決手段】
本発明は、複数のレシーバにコンテンツを配信するシステムにであって、第１のレシーバにおいてプッシュマルチキャスト方式でファイルのセットを受信するステップ、受信されたファイルのセットに欠落したファイルを保持している第２のレシーバの識別情報を取得するステップ、および、ピアツーピアメカニズムを使用してプルモードで欠落したファイルを第２のレシーバから回復するステップを有する、受信ファイルを回復するファイル回復方法である。本発明の別の対象は、サーバおよびピアデバイスのファイルの回復のための方法である。

Description

本発明はコンテンツを配信するシステムのファイル回復のための方法に関する。

サーバおよび多数のレシーバ間のコンテンツの配信は、サーバおよび各々のレシーバとのポイントツーポイント接続またはマルチポイント接続を確立することが必要である。ポイントツーポイント接続は、各々のレシーバのためのユニキャスト手段によってコンテンツを配信するために安定した配信を提供する。しかしながら多数のレシーバに対して、接続に関して重いマネージメントを必要とする。なお、それは、同様にネットワークの上の転送量を劇的に向上させる。これに対して、マルチキャスト配信は、より小さなネットワーク負荷を伴い、より安定でない配信を提供する。マルチキャスト配信が使われるときに解決しなければならない事項は、受信のエラーを回復する方策を用意しなければならないことである。例えば、これは再送信の要求により回復できる。例えば、コンテンツのマルチキャスト配信の例として、ＩＥＴＦ ＲＦＣ ３９２６は、Ｆｉｌｅ Ｄｅｌｉｖｅｒｙ Ｕｎｉｄｉｒｅｃｔｉｏｎａｌ Ｔｒａｎｓｐｏｒｔプロトコル（ＦＬＵＴＥ）を定義している。この標準において定められるプロトコルは、クライアント側のバンド幅に関する異質性およびクライアント数に関するスケーラビリティの課題に十分対応している。しかし、特に伝送が有限の持続時間を有するときに、ＦＬＵＴＥは完全には信頼性の高い配信サービスを提供しない。この種のコンテンツ配信メカニズムにおいては、定期的なコンテンツサブセットのアップデートのサポートが必要となる。このため、補完的に信頼性を高めるファイル回復メカニズムが、ＦＬＵＴＥプロトコル上に構築される。幾つか重要なレシーバが存在する場合には、エラー回復メカニズムは、ネットワーク上の伝送量を最適化する要求にも適合しなければならない。

特許文献１（ＳＯＴＯ ＪＵＡＮ ＣＡＲＬＯＳ［ＵＳ］ ＥＴ ＡＬ）は、２００３年９月２５日に公開されており、ピアツーピア方法を使用したエラー回復メカニズムを開示する。この文献において開示される方法は、分散化されている。

特許文献２（ＶＥＤＡＮＴＨＡＭ ＲＡＭＡＫＲＩＳＨＮＡ［ＵＳ］ ＥＴ ＡＬ）は、２００６年２月２日に公開されており、ユニキャストエラー回復メカニズムを開示している。

非特許文献１は、同様に、ユニキャストエラー回復メカニズムを開示している。

米国特許出願公開第２００３／１８２３７３号明細書 米国特許出願公開第２００６／０２３７３２号明細書

ＮＴＴ ＤＯＣＯＭＯ ＥＴ ＡＬ： "Ｐｏｉｎｔ−ｔｏ−ｐｏｉｎｔ 回復 ｍｅｃｈａｎｉｓｍ ｆｏｒ ＭＢＭＳ ｆｉｌｅ ｄｏｗｎｌｏａｄ ｓｅｒｖｉｃｅ，Ｔｄｏｃ Ｓ４−０４００３８" ＴＥＣＨＮＩＣＡＬ ＳＰＥＣＩＦＩＣＡＴＩＯＮ ＧＲＯＵＰ ＳＥＲＶＩＣＥＳ ＡＮＤ ＳＹＳＴＥＭ ＡＳＰＥＣＴＳ，ＸＸ，ＸＸ，２３ Ｆｅｂｒｕａｒｙ ２００４，ｐａｇｅｓ １−４，ＸＰ００２３７５８１９

本発明は、レシーバ、ピアレシーバおよびネットワーク上のトラフィック負荷を最適化するインデックスサーバのレベルでの効率的なファイル回復方法に関する。

この目的のために、本発明は、複数のレシーバにコンテンツを配信するシステムにおいて、ファイルを回復する方法であって、第１のレシーバにおいて、トランスミッタからプッシュマルチキャストでファイルのセットを受信するステップ、受信されたファイルのセットに含まれない欠落したファイルを保有する第２のレシーバの識別子を受信するステップ、ピアツーピアメカニズムを使用してプルモードで第２のレシーバから欠落したファイルを回復するステップを有する。

トランスミッタからレシーバへのファイル転送の信頼性が高くないため、一つ以上のファイルは正しく受信されないことがある。驚くべきことに、レシーバは、ファイルのセット中の欠落したファイルをトランスミッタから受信しない。それは、ピアツーピア方式によってダウンロードできる。欠落したファイルを保持する他のレシーバのアドレスを受信する。コンテンツのレシーバは、ファイル回復メカニズムに参加する。これによって、ネットワークのロードバランスを最適化して、サーバオーバーロードを減少させる。

第１の実施例において、第２のレシーバの識別子を受信するステップは、受信されたファイルをサーバに報告するステップ、およびサーバから第２のレシーバの識別子を受信するステップを有する。

レシーバは、サーバに、それが正しく受信したファイルを知らせる。このことによって、サーバは、各々のレシーバで欠落したファイルを知ることができる。そして、どのレシーバがどの欠落したファイルを要求するかについて知ることができる。それによって、加えてサーバは、ファイルを受信できなかったレシーバに、受信できなかった欠落ファイルを正しく受信したレシーバを、知らせることができる。

第２の実施形態によれば、第２のレシーバの識別子を受信するステップは、受信したファイルのセットの識別子を受信するステップ、受信されたファイルのセットの中の欠落したファイルを検出するステップ、欠落したファイルをサーバに報告するステップ、および、サーバから第２のレシーバの識別子を受信するステップ、を有する。

レシーバは、受信することになっているファイルリストを通知される。それは、欠落したファイルを検出することができ、サーバに欠落したファイルを示すことができる。これによって、ネットワークのアップリンク転送量を減らすことができる。実際、全てのファイルを受信したレシーバは、いかなる指示もサーバに送信することはない。欠落したファイルを検出したレシーバだけが、要求をサーバに送信する。

第三の実施態様によれば、第２のレシーバの識別子を受信するステップは、コンテンツの各々のレシーバの識別子を受信するステップ、受信されるファイルのセットの識別子を受信するステップ、受信されたファイルのセットの中の欠落したファイルを検出するステップ、欠落したファイルを回復するために、他のレシーバに要求をブロードキャストするステップ、および第２のレシーバから第２のレシーバの識別子を受信するステップ、を有する。

サーバは、ファイル回復メカニズムに関係していない。ファイルの回復は、レシーバの間で実行される。この分散モードは、サーバのロードを軽減する。

発明の別の対象は複数のレシーバにコンテンツを配信するシステムのファイルを回復する方法であって、サーバにおいて、全てのレシーバによって受信されるファイルのセットの識別情報を受信するステップ、各々のレシーバによって正しく受信されたファイルのリストを特定するステップ、および、正しくファイルを受信しなかった第１のレシーバに、前記ファイルを正しく受信した第２のレシーバの識別子を知らせるステップ、を有する。

サーバは、ファイル回復のための集中化した方法を管理する。それは、各々のレシーバによって受信されたファイルのリストを特定する。そして、各々のレシーバにおける欠落したファイルを推定することが可能である。さらに、正しくファイルを受信しなかった各々のレシーバのために、それは、ファイルを正しく受信したピアレシーバを知らせる。

本発明の別の対象は、複数のレシーバにコンテンツを配信するシステムのファイルを回復する方法であって、第１のレシーバにおいて、トランスミッタからプッシュマルチキャストでファイルのセットを受信するステップ、ファイルを回復するために、第２のレシーバから要求を受信するステップ、前記ファイルが前記ファイルのセットにおいて利用できる場合、前記第２のレシーバに前記ファイルを送るステップ、および、前記ファイルが前記ファイルのセットにおいて利用できない場合、他のレシーバに前記要求を転送するステップ、を有する。

各々のレシーバは、ファイル回復メカニズムに参加する。それは、回復メカニズムによって、他のレシーバに対して、受信されたファイルのセットを利用できるようにする。ファイルのセットは、ピアツーピアメカニズムを使用してプルモードでダウンロード可能である。

実施例によれば、ファイルのセットを受信した後に、それは、サーバに受信されたファイルのセットを示すステップを有する。

レシーバは、正しく受信し、かつ、他のレシーバに利用できるファイルのセットを明らかにする。これは、集中化したモードにおいて、誤った要求を除去する。

実施例によれば、コンテンツが一方向性トランスポートプロトコル（ＦＬＵＴＥプロトコル）によって、前記ファイル配信に従って配信され、当該ファイル回復方法が、現在のファイル配信セッションのみの間に受信されたファイルに提供される、
実施例によれば、コンテンツが一方向性トランスポートプロトコル（ＦＬＵＴＥプロトコル）によって、前記ファイル配信に従って配信され、当該ファイル回復方法が、現在のファイル配信セッションのみの間に受信されたファイルに提供される。

ファイルのセットは、各々のレシーバにおいて、現行ファイル配信セッションの間だけ利用できる。その期間の後においては、ファイルは、回復にもはや利用できない。通常のクライアントサーバベースのファイル回復メカニズムが、コンテンツサーバで利用できるであろう。

実施例によれば、欠落したファイルを検出するステップが前記ＦＬＵＴＥプロトコルにおいて定められるファイル配信表によって実行される。

本発明の別の対象は、プログラムがコンピュータで実行されるときに、本発明の方法のステップを実行するためのプログラムコード命令を有しているコンピュータプログラム製品である。「コンピュータプログラム製品」とは、コンピュータプログラムをサポートすることを意味する。そして、これは、プログラムを含んでいる保存スペース（例えばディスケットまたはカセット）ばかりでなく、同様に信号（例えば電気または光学信号）であってもよい。

本発明は、添付の図を参照することにより、実施実例に関してよりよく理解されるであろう。なお、添付の図は決して制限的に理解するためのものではない。

実施例のシステムに対応するブロック図である。 実施例に対応する装置のブロック図である。 実施例の配信方法のフローチャートである。 集中化したモードのファイル回復メカニズムのフローチャートである。 分散モードにおけるファイル回復メカニズムのフローチャートである。

図１および図２に示されたブロックは単に機能要素であり、これらが物理的に別々の要素に必ずしも対応するというわけではない。すなわち、それらは、ソフトウェアの形で開発されることができ、または一つまたは幾つかの集積回路において実行されることができる。

キオスクのデジタル加入者線高速広帯域網に基づくサービスは、小売業者の建物（例えばスーパーマーケット）において展開される。そこにおいて、顧客は、Ｄｉｇｉｔａｌ Ｖｉｄｅｏ Ｄｉｓｋｓ（ＤＶＤ）を購入してもよい。各々のキオスクには、平均数で約１０，０００のタイトルのＤＶＤコンテンツを保存するために、各々のキオスクは、ローカルに記憶装置を備えている。また、キオスクは、顧客がキオスクで閲覧して、コンテンツガイドによって、キオスクのコンテンツを選ぶことができるように、ユーザインターフェース手段を備えている。キオスク内で、直接ＤＶＤが焼かれる。定期的に、各々のキオスクのコンテンツは、増加する最新版を保存しているコンテンツサーバから部分的に更新される。このサービスは、オペレータによって管理される。現在のビデオレンタルシステムと比較すると、このシステムの利点は、顧客が、定期的に更新されるより多くのコンテンツにアクセスできることである。全てのこれらのコンテンツは、決して品切れしない。図１は、このサービスに関係する装置を表している。サーバ５は、ネットワーク４（好ましくはインターネット）によりいくつかのキオスク１、２、３に、コンテンツを送る。キオスクは、サーバ５のクライアントである。図１においては、３つのキオスクを表しているが、サービスは何千ものキオスクを有していてもよい。もちろん、このサービスは、複数のサーバの設置を必要としてもよい。いくつかのサーバは、キオスクにコンテンツのサブセットを各々提供することができる。インデックスサーバ６は、後述するようにファイルの回復を管理する。サーバ５およびインデックスサーバ６は、同じ装置に、または別の装置に、設置されてもよい。図２は、サーバ５および６およびキオスクの構成を表している。通信モジュール１．２は、インターネットによって、他の装置とデータを送受信する。処理モジュール１．３は、装置を作動させるための手段を備えている。装置は、データ、マネージメントファイルおよび装置を作動させるためのファームウェアを保存するための保存モジュール１．１を有する。全てのモジュールは、内部バス１．４によって相互接続されている。

サーバ５において、保存モジュールは、コンテンツリファレンスを有する。インデックスサーバ６において、保存モジュールは配信するファイルのリストを有する。このリストは、サーバ５から取得してもよい。各ファイルは、識別子によって特定される。キオスクにおいて、保存モジュールは、ＤＶＤに焼いてパッケージするコンテンツを含む。ＤＶＤを焼き、かつ包装するための手段は、図示されていない。サーバは、コンテンツ配信およびファイル回復手順を管理する。もちろん、コンテンツリファレンスはコンテンツ配信手順を管理する第１のサーバが保有するので、少なくとも、第２のサーバがファイル回復手順を管理してもよい。

全体の配信プロセスは、図３にまとめられる。

信号発信２．１は、ダウンロードフェーズを始動するのに必要なステップである。

マルチキャスト配信２．２は、サーバからレシーバの集合へのマルチキャストコンテンツ配信フェーズである。

ファイル回復２．３は、２つのステップに分割される。

マルチキャスト配信状況２．３．１は、ファイル回復サーバ（これが存在する場合）がダウンロードファイルに関してクライアントの状態を取得するステップである。

ファイルの回復２．３．２は、不足しているデータを、クライアントが回復するために必要なステップである。受信報告２．５は、クライアントがコンテンツの完全な受信をオペレータに報告するステップである。

接続を初期化する方法は、以下の通りである。クライアントが配信網に接続するときに、それはサーバのＩＰアドレスにアドレス解決プロトコル要求（ＡＲＰ：ａｄｄｒｅｓｓ ｒｅｓｏｌｕｔｉｏｎ ｐｒｏｔｏｃｏｌ要求）をブロードキャストする。サーバはユニキャストＡＲＰレスポンスをクライアントに送信する。そして、そのＭＡＣアドレスを示す。それから、クライアントは、ファイル転送プロトコル（ＦＴＰ）を使用して、ログインおよびパスワードによって自身をサーバに認識させる。最後に、認識がなされた場合、クライアントはサーバに接続し、コンテンツを受信することが可能である。新しいキオスクがネットワークに追加される場合、それはその接続情報（ＩＰアドレス、ポート等）を集中インデックスサーバに送信して、ピアとなってもよい。

キオスクにファイルを配信する方法は、以下の通りである。コンテンツ配信メカニズムは、ビデオオンデマンド（ＶＯＤ）、プッシュビデオオンデマンド（Ｐｕｓｈ ＶＯＤ）の方式に密接に関連する。実際、コンテンツプッシュ方法では、コンテンツは、オペレータのコントロール下でローカル記憶装置（例えばハードディスク）を有する装置に保存される。一旦ダウンロードされると、利用者は必要なときに、このコンテンツを再生することができる。コンテンツプッシュ方式は、リアルタイム配信が可能でないか、エラーが発生しがちな環境でのコンテンツの配信を可能とする。これは、少ないコストで、多数の同時サービスの配信を可能とする。なぜなら、ユニキャストプロトコル（例えばストリーミングモードＶＯＤまたはダウンロードモードＶＯＤ）に基づく有効なサービスまたはＶＯＤサービスと比較して、消費されるバンド幅が制限されていてもよいからである。

プッシュＶＯＤのコンテンツ配信メカニズムは、定期的に、クライアント装置に保存された全てのコンテンツおよびメタデータのサブセットだけを更新することを目的としている。このアップデート方式は、累積的なアップデートと呼ばれており、後述するステップに分割可能である。ダウンロードフェーズを起動させるために、オペレータによって管理される帯域外の信号が用いられて、コンテンツサブセットのアップデートをキオスクに行うようアナウンスする。この信号メカニズムは、ＤＶＢ−ＩＰ標準に基づいて使用される。これは、ＥＴＳＩ ＴＳ １０２ ０３４ ｖ１．１．１ （２００５−０３） Ｄｉｇｉｔａｌ Ｖｉｄｅｏ Ｂｒｏａｄｃａｓｔｉｎｇ（ＤＶＢ）：Ｔｒａｎｓｐｏｒｔ ｏｆ ＭＰＥＧ２ Ｂａｓｅｄ ＤＶＢ Ｓｅｒｖｉｃｅｓ ｏｖｅｒ ＩＰ Ｂａｓｅｄ Ｎｅｔｗｏｒｋｓに定義されている。

アナウンスを受信した後に、キオスクはダウンロードフェーズをスタートする。そして、ダウンロードされたデータは一時バッファに保存される。このダウンロードメカニズムは、マルチキャストコンテンツ配信プロトコルに基づく。ＩＥＴＦ ＲＦＣ ３９２６は、Ｆｉｌｅ Ｄｅｌｉｖｅｒｙ Ｕｎｉｄｉｒｅｃｔｉｏｎａｌ Ｔｒａｎｓｐｏｒｔ（ＦＬＵＴＥ）プロトコルに定められている。これは、キオスクの数に係るスケーラビリティと、キオスクにおけるバンド幅に係る異質性の課題に対して、非常によく適応できる。定期的なコンテンツサブセットのアップデートのサポートが必要なコンテンツ配信メカニズムにおいてよくあるように、転送が有限の時間である場合、ＦＬＵＴＥは完全には信頼性が高い配信サービスを提供しない。補完的な信頼性が高いファイル回復メカニズムが、ＦＬＵＴＥプロトコル上に構築される。このファイル回復は、２つのレベルのファイル回復メカニズムである。

第１のレベルは、現在の更新セッションのファイルを回復するために行われるファイル回復に関わる。このファイル回復ステップを、「現在の配信セッションの間のファイル回復」と呼ぶ。このファイル回復メカニズムは、ピアツーピアプロトコル（Ｐ２Ｐ）に基づく。Ｐ２Ｐは、単一のサーバからの集中した検索の代わりに、会員ノード間の情報の検索に依存するネットワークプロトコルである。Ｐ２Ｐモデルにおいては、各々の会員ノードは、配信が利用できる情報を持っていてもよく、情報をダウンロードするために、他のいかなる会員ノードに対しても直接的な接続を確立してもよい。実際、ＦＬＵＴＥコンテンツマルチキャスト配信セッションの後、コンテンツは、ほとんどのキオスクに分散される。コンテンツの一部の断片は各々のキオスクにおいて欠落していてもよい。しかし、その大部分の要素はダウンロードされるはずである。これに対応して、Ｐ２Ｐプロトコルに基づく効率的なファイル回復ソリューションが、開発された。このファイル回復を「プルＰ２Ｐダウンロード（ｐｕｌｌ Ｐ２Ｐ ｄｏｗｎｌｏａｄｉｎｇ）」と呼ぶ。コンテンツ（すなわちファイルのセット）は、セッションにおいて、レシーバによって受信され、現在のセッションの間に他のレシーバに利用できるようにされる。

第２のレベルは、前の更新セッションのファイルを回復するためのファイル回復に関わる。このファイル回復ステップは、「前の配信セッションの間のファイル回復（Ｆｉｌｅ Ｒｅｐａｉｒ ｆｏｒ ｔｈｅ ｐｒｅｖｉｏｕｓ ｕｐｄａｔｅ ｓｅｓｓｉｏｎ）」と呼ぶ。現在の更新セッションのために使用するファイル回復方式とは異なる。この場合、キオスクにおいて前のセッションで受信されたコンテンツは集約されて、保存されている。前のセッションにおけるように、もはやファイルの形では利用できない。したがって、もはや他のレシーバが利用できない。このため、それはネットワークトラフィックと親和性のあるＰ２Ｐを基にしたファイル回復メカニズムを利用できず、むしろ、より従来のクライアントサーバベースのファイル回復メカニズムのみが利用できる。この場合、このファイル回復レベルは、ＤＶＢ−Ｈ ＩＰ Ｄａｔａ−ｃａｓｔｉｎｇ標準に類似している（ＤＶＢ−Ｈ ＩＰ Ｄａｔａ−ｃａｓｔｉｎｇ ｓｔａｎｄａｒｄ， ＤＶＢ−ＣＢＭＳ，“ＩＰ Ｄａｔａｃａｓｔ ｏｖｅｒ ＤＶＢ−Ｈ； Ｃｏｎｔｅｎｔ Ｄｅｌｉｖｅｒｙ Ｐｒｏｔｏｃｏｌｓ （ＣＤＰ）” ＤＶＢ Ｄｏｃｕｍｅｎｔ Ａ１０１，２００５ Ｄｅｃｅｍｂｅｒ）。この、ＤＶＢ−Ｈ ＩＰ Ｄａｔａ−ｃａｓｔｉｎｇ標準に採用されているファイル回復方式は、一つのレベルだけのファイル回復方式であり、集中化したクライアントサーバファイル回復モードを採用している。それは、マルチキャストステップの後においてキオスクにコンテンツが分散している機会を利用するものではない。コンテンツおよびメタデータのサブセットがダウンロードされて、メモリバッファに保存される。バンド外（ｏｕｔ ｏｆ ｂａｎｄ）のアナウンスによってコンテンツに与えられたリリースタイムが経過した後は、旧データのサブセットは新しいダウンロードされたデータに置き換わる。キオスクが顧客のために使用されないときに、新旧のダウンロードされたデータ間のスワップステップが行われる。キオスクは、小売業者の建物において展開されており、夜間は営業していない。新旧のコンテンツ間のスワップの間、キオスクは、いくつかのコンテンツを消さなければならない。消すファイルまたはディレクトリのリストは、セッションの第１の配信ファイルに記載されている。これは、ＦＬＵＴＥ／ＴＯＩ＝１（Ｔｒａｎｓｐｏｒｔ Ｏｂｊｅｃｔ Ｉｄｅｎｔｉｆｉｅｒ）に対応している。このファイルは、それが空のときでも、常に配信される。この場合、コンテンツは消去されない。このファイルが空でなく、かつビデオファイルが配信されない場合、キオスクはコンテンツのダウンロードなしに消去動作を行う。スワップメカニズムは、もちろん、他の場合にも発生する。キオスクが、スワップメカニズムの間にサスペンドモードにセットされている間が該当する。一旦更新されて、交換されると、全く新しいコンテンツがユーザに利用できるようにされる。

以下、ファイル回復方法について説明する。

好ましい実施例によれば、集中化したモードが、用いられる。
インデックスサーバは、コンテンツサーバから送信されたファイルのリストを認識している。この情報は、コンテンツサーバから取得する。

「マルチキャスト配信状況ステップ」の間、各々のキオスクは、受信したファイルを集中化インデックスサーバに報告する。インデックスサーバは、各々のキオスクの本当に受信されたコンテンツにリンクするインデックステーブルを作成することが可能である。

そして、「ファイル回復ステップ」の間、サーバは、コンテンツが欠落している各々のキオスクを見つけるため、そのインデックステーブルを検索する。それは、各々のキオスクに、欠落したコンテンツを保持するキオスクのピアのリストを示す。そして、欠落しているコンテンツを必要とするキオスクは、欠落したファイルを保持している一つ以上のピアとの接続を確立して、それをダウンロードする。

集中化した方式は、図４に例示される。

ステップ１で、各々のキオスクは、リストのファイルのダウンロードのためにアクセスできるＴＣＰポート番号と共有するファイルのリストをインデックスサーバに送信する。

ステップ２で、インデックスサーバは、各々のキオスクにファイルのリストの受信を確認する。

ステップ３で、サーバは、欠落したファイルを各々のキオスクで見つけるために、受信されたファイルのリストを検査する。それは、欠落したファイルを保有するキオスクのリストの指示を各々のキオスクに送る。図４において、それは、キオスク１に指示を送る。このステップで、サーバは、キオスクに接続するための手段に関するいかなる情報も示さない。

ステップ４で、キオスク１は、要求したファイルをダウンロードするために、要求をサーバに送信する。

ステップ５で、サーバは、要求されたファイルを保持するキオスクに、ＡＲＰ要求をマルチキャストする。これは、キオスクの接続方法の収集を目的とする。

ステップ６において、キオスク、すなわちキオスク２が、キオスク１に接続しファイル転送する用意がある旨をサーバに返信した第１のキオスクである。

ステップ７で、サーバは、ファイルを保有するキオスクとして、キオスク２のＩＰアドレスを送る。

ステップ８で、キオスクは、キオスク２のＩＰアドレスを有するキオスクを特定するために、ＡＲＰ要求をブロードキャストする。

ステップ９で、キオスク２は、キオスク１に、そのＭＡＣアドレスの指示を有するレスポンスを送る。

ステップ１０で、キオスク１は、ファイルを得るために、キオスク２に接続する。

ステップ１１で、キオスク２は、キオスク１にファイルを送る。

集中化したモードの変形実施例によれば、各々のキオスクは、欠落したファイルを特定するために、ＦＬＵＴＥプロトコルに依存してもよい。実際、ＦＬＵＴＥプロトコルはファイル転送テーブル（ＦＤＴ）を定める。この転送テーブルは、現在のセッションにおいて送信されなければならないファイルの情報を含む。ＦＬＵＴＥプロトコルは、マルチキャストモードで、コンテンツサーバから、全てのキオスクまでＦＤＴを送信する。これは、転送エラーに依存するが、ＦＤＴファイル伝送の信頼性は、前向きエラー保護（ｆｏｒｗａｒｄ ｅｒｒｏｒ ｐｒｏｔｅｃｔｉｏｎ）や、セッションの内でのＦＤＴの再送のメカニズムによって、向上させることができる。これらは、よく知られた技術である。したがって、マルチキャストコンテンツ配信ステップの終了後、各々のキオスクは、セッションで送信されなければならないファイルおよび受信されたファイルを正確に知ることになる。各々のキオスクは、インデックスサーバに、欠落したファイルを示してもよい。サーバは、それからキオスクに、欠落したファイルを保有する他のキオスクのアドレスを示す。この変形実施例は、ネットワーク上の転送量を最小化することができる。あるキオスクが誤ったファイルを受信した場合にもこれは適用できる。

第二実施例においては、ファイル回復は分散する。インデックスサーバは、ファイルの回復ステップに関与しない。各々のキオスクは、「マルチキャストコンテンツ配信ステップ」の終了後コンテンツの受信を完了するのに必要なファイルのセットを決定することが可能である。分散モデルにおいて、キオスク間の「ファイル回復要求」メッセージを配信するために、フラッディング（ｆｌｏｏｄｉｎｇ）メカニズムが用いられる。

要求元キオスクのアルゴリズムは、以下の通りである：
キオスクは、ファイルが欠落していることを特定する。

それは、ピアキオスクに、ファイルの入手可能性についてのクエリを送る要求をブロードキャストする。

他のキオスクでファイルが特定されたことを示すメッセージを、キオスクが受信すると、ファイルを得るために、そのキオスクに対する直接接続を開始する。

この場合インデックスサーバのような中心となるコーディネーションがないため、ファイル回復ステップは特定の「マルチキャスト配信状況ステップ」ではなく、「ファイル回復ステップ」の初めから開始されてもよい。

キオスクでのアルゴリズムは、以下の通りである：
キオスクは、ファイルが欠落している他のキオスクから、要求を受信する。

キオスクが利用できるファイルを有しない場合、要求を転送する。

キオスクが利用できるファイルを有する場合、クエリが来たルートに沿って応答メッセージを送り返す。なぜなら、クエリそのものは、要求が来たキオスクを特定する情報を含まないからである。

ネットワークによるメッセージの拡散を制限するために、各々のメッセージは、存続時間（ＴＴＬ：ｔｉｍｅ−ｔｏ−ｌｉｖｅ）フィールドを含む。それは、要求がキオスクに着くたびに、各々のホップで減算される。ＴＴＬフィールドが無効なときに、メッセージは却下される。

新しいキオスクがネットワークに追加されたときには、それは、接続している他のキオスクにｐｉｎｇメッセージを送る。そして、自身の存在をアナウンスする。キオスクは、ｐｉｎｇメッセージを送り返して、更にそれらの周囲にｐｉｎｇメッセージを伝播させる。各々のメッセージは、独自にメッセージを特定するために、「ディスクリプタＩＤ」を含む。このｐｉｎｇメッセージは、何らのペイロードも含まない。その代わり、ｐｉｎｇメッセージは、例えば、ＩＰアドレスおよびポート、ファイル番号やサイズのような共用ファイルに関する情報などのコンタクト情報を含む。

分散モードは、図５に例示される。

二種類のメッセージが、分散モードにおいて使われる。すなわち、要求Ｒおよび成功応答Ｓである。要求は、欠落したファイルの取得可能性を周辺に求めるために送られる。要求メッセージＲは要請されたファイルの名前およびファイルのサイズを有する。キオスクは、二回以上、同じ「ディスクリプタＩＤ」を有する同じ要求メッセージを受信した場合には、メッセージを転送するのを中止する。これは、メッセージのループおよび伝送量を最小化するためである。要請されたファイルがキオスクにおいて特定された場合、成功応答Ｓが返される。成功メッセージＳは、コンタクト情報（ＩＰアドレス、ポート）および検索条件（名前、サイズ）に対応するファイルを含む。

図５において例示されるシナリオにおいて、キオスク１は、ファイルＦを受信しなかったとする。

ステップＡにおいて、キオスク１は、その周辺のキオスク３およびキオスク４に要求を送る。

ステップＢにおいて、キオスク３およびキオスク４はファイルＦを有しないため、それらは、それぞれの周辺に要求を転送する。キオスク３は、キオスク２およびキオスク４に転送し、キオスク４は、キオスク３およびキオスク５に転送する。

ステップＣにおいて、キオスク２は、ファイルＦを保有する。それは、キオスク３に成功メッセージを送る。キオスク５はキオスク２に要求メッセージを転送する。

ステップＤにおいて、キオスク３はキオスク１に成功メッセージを転送する。

キオスク１は、現在、欠落したファイルＦの位置を認識している。それは、ファイルＦをダウンロードするために、キオスク５との接続を確立する。

実際、要求メッセージは、複数の欠落したファイルのリストを有してもよい。キオスクがリストの一部のファイルを保有する場合、それはファイルを有する成功メッセージを送り、そして、全てのファイル有していないため、周辺に対して要求を転送する。要求の発信元は、ファイルをダウンロードするために、成功メッセージを送ったものの中のより一番都合のよいキオスクを選ぶ。

第三の実施態様において、ファイル回復は、部分的に集中される。これは、サーバがコンテンツ配信を管理する方式を使用する。そして、少なくとも、他のサーバがファイル回復を管理する。この他のサーバは、スーパーノードに設置される。スーパーノードは、キオスクネットワークの小さいサブパーツをサービスする作業を動的に割り当てられる。スーパーノードは、それらに接続されるキオスクによって共有されるファイルにインデックスを付け、キオスクに代わって検索要求を実行する。全ての要求は、サブパーツのスーパーノードに送られる。検索時間は、分散モデルと比較して短くなる。

Claims (8)

1. 複数のレシーバにコンテンツを配信するシステムに使用するための、ファイルを回復するファイル回復方法であって、第１のレシーバにおいて：
   トランスミッタからプッシュマルチキャストによってファイルのセットを受信するステップ；
   前記受信されたファイルをサーバに報告するステップ；
   前記サーバから前記受信されたファイルのセットに含まれない欠落したファイルを保有する第２のレシーバの識別子を受信するステップ；および
   ピアツーピアメカニズムを使用してプルモードで前記第２のレシーバから前記欠落したファイルを回復するステップ；
   を有する方法。
2. 複数のレシーバにコンテンツを配信するシステムに使用するための、ファイルを回復するファイル回復方法であって、第１のレシーバにおいて：
   受信するファイルのセットの識別子を受信するステップ；
   トランスミッタからプッシュマルチキャストでファイルのセットを受信するステップ；
   前記受信されたファイルのセットの中の欠落したファイルを検出するステップ；
   前記欠落したファイルをサーバに報告するステップ；
   前記サーバから前記受信されたファイルのセットに含まれない欠落したファイルを保有する第２のレシーバの識別子を受信するステップ；および
   ピアツーピアメカニズムを使用してプルモードで前記第２のレシーバから前記欠落したファイルを回復するステップ、
   を有する方法。
3. 前記第２のレシーバの識別子を受信するステップが：
   前記コンテンツの各々のレシーバの識別子を受信するステップ；
   受信されるファイルのセットの識別子を受信するステップ；
   前記受信されたファイルのセットの中の欠落したファイルを検出するステップ；
   前記欠落したファイルを回復するために、他のレシーバに要求をブロードキャストするステップ；および
   前記第２のレシーバからの前記第２のレシーバの前記識別子を受信するステップ；
   を有する請求項１記載の方法。
4. 複数のレシーバにコンテンツを配信するシステムのためのファイルを回復する方法であって、サーバにおいて：
   全てのレシーバによって受信されるファイルのセットの識別情報を受信するステップ；
   各々のレシーバによって正しく受審されたファイルのリストを特定するステップ；および
   正しくファイルを受信しなかった第１のレシーバに、前記ファイルを正しく受信した第２のレシーバの識別子を知らせるステップ；
   を有する方法。
5. 複数のレシーバにコンテンツを配信するシステムのためのファイルを回復する方法であって、第１のレシーバにおいて：
   トランスミッタからプッシュマルチキャストでファイルのセットを受信するステップ；
   ファイルを回復するために、第２のレシーバから要求を受信するステップ；
   前記ファイルが前記ファイルのセットにおいて利用できる場合、前記第２のレシーバに前記ファイルを送るステップ；および
   前記ファイルが前記ファイルのセットにおいて利用できない場合、他のレシーバに前記要求を転送するステップ；
   を有する方法。
6. 前記ファイルのセットが受信された後に、前記受信されたファイルのセットをサーバに知らせるステップ、を有する請求項５記載の方法。
7. 前記コンテンツが一方向性トランスポートプロトコル（ＦＬＵＴＥプロトコル）によって、前記ファイル配信に従って配信され、当該ファイル回復方法が、現在のファイル配信セッションのみの間に受信されたファイルに提供される、
   請求項１ないし６のいずれか１項記載の方法。
8. 前記欠落したファイルを検出するステップが前記ＦＬＵＴＥプロトコルにおいて定められる前記ファイル配信表によって実行される、
   請求項７、２または３のいずれか１項に記載の方法。

Images