マルチブロードキャストデータ伝送の信頼性を改善するシステム
マルチブロードキャストデータ伝送の信頼性を改善するシステム。データのソース（１０）と前記データに対する複数の顧客受信器（２０１、２０２、．．．、２０Ｎ）との間で電気通信網（１）を介してマルチブロードキャストデータを伝送する信頼性を改善するためのシステムは、少なくとも一つの他の受信器からなるリストを各顧客受信器に提供するよう適合された監視サーバ（３０）を含み、前記顧客受信器は、確実なピアツーピアの接続を介して前記他の顧客受信器から紛失データを受信するよう適合されることを特徴とする。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、データのソースと前記データに対する複数の受信器との間で電気通信網を介してマルチブロードキャストデータを伝送する信頼性を改善するためのシステムに関する。
【背景技術】
【０００２】
本発明は、“マルチキャスト”モードとしても知られる、マルチブロードキャストモードでデータを伝送する分野において、特に有利な用途を見出す。
【０００３】
用語“マルチブロードキャスト”及び“マルチキャスト”は、以下の説明では交互に使用され、用語“マルチキャスト”は、この分野で広く使用されている。
【０００４】
効率的に大量のデータを配信するための精密な制御は、インターネットサービスプロバイダ（ISPはInternet Service Providerの略）にとって重要である。現在の傾向は、ホームゲートウェイ及びセットトップボックス（ＳＴＢ）形式で家庭に設置されたネットワーク機器を遠隔で供給及び管理することである。家庭に設置された機器は、以下“受信器”又は“顧客”と称する。
【０００５】
従って、ＩＳＰが制御する一つ又は少数のポイントから管理される必要がある何百万個もの受信器が潜在的にある。また、ウイルスが拡散し続け、今は個人コンピュータに影響するだけでなく、個人デジタル機器（ＰＤＡ）、携帯電話、上記ホームゲートウェイ、及びＳＴＢのような機器を用いた電子データ処理に基づきアプリケーションを伝達することに関るあらゆるものに影響することが次第に明らかになっている。ウイルス及びその他破壊工作ソフトの作者は、自らの技術を次第に向上させ、セキュリティ欠陥が公衆上に生じる時とウイルスがセキュリティ欠陥の利用目的で開発される時との差が縮まってきている。
【０００６】
従って、オペレータが管理する全ての家庭用受信器を更新するための技術をかなり迅速にマスターすることが重要になってきている。機器の信頼性とサービス品質とは、上記更新技術に依存し、上記更新技術は、かなり多数の顧客からなる家庭において迅速かつ効率的な更新解決策によって実行されねばならない。
【０００７】
この問題を解決する第１の方法は、配信に関係なく、多数のコンテンツサーバを用いることである。その解決策は、サーバ数の多いリソースと多数のネットワークリソースとを必要とするため、かなりコストがかかるかもしれない。また、許容範囲の妥協策を達成するには、サーバ管理者は、所定の最大数の更新を毎日実行することにより適時にタスクを拡散するポリシーを頻繁に用いる。そのストラテジは、緊急電話（“ホットライン”）の発信がしばしばソフトウェアの更新時に増えないようにする点で有利だが、例えばセキュリティモジュールを迅速にデプロイするのに全く適さない。
【０００８】
第２の方法は、マルチブロードキャスト、即ち“マルチキャスト”方法であり、僅かな数から何百万もの任意の受信器グループにデータソースが素早く連絡できる、簡単かつ効率的な手段を構成するが、その解決策は、ＵＤＰ（ユーザデータグラムプロトコル）に基づくものであり、顧客に正しくデータが伝送される保証がなく、例えば一部のデータが接続又はルータレベルで喪失することがある。その欠点は、紛失データを回復できる帰路チャンネルがないことに起因して悪化する。かなり多くの受信器を備えた任意のそのようなシステムを監視することは問題がある。
【０００９】
しかし、ＩＥＴＦグループによるＲＭＴ（確実なマルチキャスト伝送）は、マルチキャスト伝送の信頼性を改善するという課題に着目し、主に２つのカテゴリに分類可能な一組の解決策を提案する。
【００１０】
・ＦＥＣ（前進型誤信号訂正）による解決策は、情報量が限定されている場合、喪失又は紛失情報を計算するために余分な情報を追加することに基づくものであり、冗長性に対する一つの特有の例は、顧客グループに向けられる全データにＦＥＣを行うことなく巡回ブロードキャストすることである。
・もう一つの解決策は、少なくとも一人のユーザにより喪失されたパケットを要求して後続的にグループ全体へ伝送するために、喪失時に顧客からフィードバックされた情報に対し精密な制御を行うことに基づくものであり、この場合、一組のサービスを妨げるリスクのあるＤＤｏＳ（分散型サービス）攻撃に関連しうる、端末からサーバ方向でのネットワーク負荷を回避する特定のメカニズムが必要である。
【００１１】
それら２つの技法を共に用いると、ネットワーク上の伝送を最適化するが、ファイルを正しく受信した受信器からなるリストをアプリケーションが必要とする場合、ＤＤｏＳ型の攻撃に関する問題は残る。
【００１２】
簡単に言うと、マルチキャストデータ伝送の信頼性を改善する方法は、以下の制限を有する。
【００１３】
多数のサーバを用いる方法によると、かなり多数の受信器が中央サイトによって管理されている場合、そのサイトは、サイトの内部リソースに依存して、限られた数の同時要求のみ受け入れできることが分かる。そのような要求は、ポイントツーポイントセッション、特にＴＣＰセッションに基づく。多数の受信器に対する同時管理を許可するには、データソースは、要求を配信する一組のマシンを組込まざるを得ない。それら解決策は、良好な負荷配分を行う管理者にとって通常コストが高く複雑である。
【００１４】
確実なマルチキャスト伝送に戻ると、
・ＦＥＣベースの解決策は、単一ソースから全受信器へ連絡できるが、エンドネットワークで主に遭遇する集中的な損失に対して受信器がかなり敏感であるので、データがいつも確実に受信されることを保証しない。また、全ての端末が同時にアクティブになるわけでなく、時々周期的にデータファイルを伝送する必要があること
・肯定応答の返信に基づく解決策は、かなり多数の受信器グループを管理できるが、それはソースへフィードバックされる情報量が限定されている場合のみ可能である。このポイントは、“ＮＡＫ集中”現象を制限することにより特徴付けられ、ここでＮＡＫは、データパケットの喪失の検出時のみ送信される否定応答を意味する。そのタイプからなる殆どの解決策は、ソースから受信器へのマルチキャスト伝送だけでなく、ソースと同一セッションに含まれる必要がある各受信器から全メッセージが送信されるマルチキャスト伝送にも依存する。それは、“１−＞Ｎ”マルチブロードキャストセッションから区別するために“Ｎ−＞Ｎ”モードと称されるマルチキャストモードである。その後、データ送信に関して受信器と競うソースは、以下の複数の理由で問題となる
ことが分かる
・データグラムモードでデータを送信すると、ＴＣＰとは対照的に、利用可能なビットレートを制御することができず、ＴＣＰにおける制御は不可能ではないが、異なる種類に組込まれた受信器ベースでアドレスを行うセッションにおいてかなり困難である。かなり多数の受信器による伝送は、受信器による追加の伝送をもたらす損失に反映されてネットワーク接続を飽和し、混雑状況を悪化させることがある。
・多数のネットワークは、“Ｎ−＞Ｎ”モードの動作に互換性がない。また、多数のオペレータは、意図的に“１−＞Ｎ”モードに自分のネットワークを限定し、制御を維持し、ＤＤｏＳ型の攻撃に関連しうる、無制御状態の混雑を防ぐ。
【発明の開示】
【発明が解決しようとする課題】
【００１５】
故に、本発明の主題により解決すべき技術的問題は、データのソースと前記データに対する複数の受信器との間で電気通信網を介してマルチブロードキャストデータを伝送する信頼性を改善するシステムを提案することにあり、それにより確実にデータを伝送できるようになり、即ち任意の喪失データを修復し、回復データのインテグリティを保証できるようになり、それは、ネットワークコスト及び配信サーバコストの観点から経済的であり、高パフォーマンス、即ち何百万もの顧客に迅速なデプロイを提供し、しかも任意の大規模なフィードバックメカニズムが不要である。
【課題を解決するための手段】
【００１６】
上記技術的問題に対する本発明の解決策によると、前記システムは、少なくとも一つの他の顧客受信器からなるリストを各顧客受信器に提供するよう適合される監視サーバを含み、前記顧客受信器は、確実なピアツーピアの接続を介して前記他の顧客受信器から紛失データを受信できる。
【００１７】
ここで、ピアツーピアの接続概念は、“ピアツーピア”（Ｐ２Ｐ）交信に基づき最近導入されたプロトコル群に属する。ピアツーピアネットワークの特徴によると、端末は、顧客と同時にリソースを利用し、サーバと同時にリソースを提供することである。例えば、Ｐ２Ｐプロトコルを共有する最良のデータファイルは、スウォーミング方法を使用し、それによりファイルは、複数部分に分割され、複数のソース端末からダウンロード可能になり、負荷分散、速度、及びロバスト性を最適化する。
【００１８】
故に、本発明は、従来のマルチブロードキャストメカニズムを使用し、マルチキャストソースは、オペレータがアドホックプロトコルを用いてネットワーク中の顧客受信器からなるグループにデータ、例えばファイルをブロードキャストすることに関与する。マルチキャストパケットが対応するトランスポート層の非信頼性を考えると（特にＵＤＰ）、データがネットワークで喪失する可能性がある。この問題を解決するために、本発明は、ピアツーピアのネットワーク手法の使用を提案する。各顧客受信器は、セッション中に維持されるＴＣＰ／ＩＰ接続のような確実な接続によって、顧客受信器からなるピアのうち特定のピアに接続される。データパケットの喪失を受信器が検出すると、受信器は、ピアに連絡し、対象のパケットを回復する。
【００１９】
言い換えると、本発明は、以下の２つの技法を組み合わせてデータ伝送を最適化する。マルチキャスト技法により、かなり多数の顧客に対するダウンロードを可能にする一方で、Ｐ２Ｐ接続は、かなり多くのエラーメッセージを顧客から単一ソースにフィードバックするのを避ける。
【００２０】
第２の局面において本発明は、電気通信網を介して前記データに対する複数の顧客受信器にマルチブロードキャストされるデータのソースを提供し、前記データのソースは、データの伝送前に前記顧客受信器に、前記データに対するMerkleハッシュ木のルートハッシュ値ＨＲを、前記電気通信網を介した確実なマルチブロードキャストにより伝送するよう適合され、前記データのソースは、前記ルートハッシュ値の伝送から前記データの伝送までに前記ルートハッシュ値ＨＲより低いレベルのハッシュ値を顧客受信器に伝送するよう適合され、顧客受信器は、確実なピアツーピアの接続を介して他の顧客受信器から紛失データを受信するよう適合される。
【００２１】
第３の局面において本発明は、データのソースと前記データに対する複数の顧客受信器との間で電気通信網を介してマルチキャストデータを伝送する信頼性を改善するためのシステムに監視サーバを提供し、前記監視サーバは、少なくとも一つの他の顧客受信器からなるリストを各顧客受信器に提供するよう適合され、前記リストは、前記顧客受信器と前記他の顧客受信器との間に確実なピアツーピアの接続を確立することを意図する。
【００２２】
第４の局面において本発明は、データのソースと前記データに対する複数の顧客受信器との間で電気通信網（１）を介してマルチキャストデータを伝送する信頼性を改善するためのシステムに参照ソースを提供し、前記参照ソース（４０）は、前記データを有し、少なくとも一つの顧客受信器に確実なピアツーピアの接続を確立するよう適合される。
【００２３】
故に、全受信器に対するデータパケットが喪失した場合、監視サーバによって供給されるリストに参照ソースを有するそれら受信器はその後、前記参照ソースにピアツーピアの接続を確立して前記喪失パケットを回復でき、そのような回復は、受信器間のピアツーピアの接続メカニズムによって、他の受信器に反映される。
【００２４】
第５の局面において本発明は、データのソースと前記データに対する複数の顧客受信器との間で電気通信網を介してマルチキャストデータを伝送する信頼性を改善するためのシステムに顧客受信器を提供し、前記顧客受信器は、ピアツーピアの接続中に前記他の顧客受信器が提供したデータのインテグリティを照合するための手段を含む。
【００２５】
故に、受信器が自ら有するリストにある他の受信器からデータを回復する時、受信データが所望のデータに相当するか確かめることができる。
【００２６】
好ましい非限定的な実施形態によると、本発明の第５の局面は、以下の追加の特徴を、単独又は組合せで有する。
【００２７】
照合手段は、少なくとも一つの他の顧客受信器から受信したデータのフラグメントに対するハッシュ値を計算するための手段と、前記データのソースから受信した前記フラグメントに対するハッシュ値と計算したハッシュ値とを比較するための手段とを含む。
【００２８】
顧客受信器は、ピアツーピアの接続中に前記他の顧客受信器が提供したハッシュ値のインテグリティを照合するための手段を含む。
【００２９】
ソースから受信したハッシュ値は、未だ確実でないマルチキャスト接続上で一般に伝送されるので喪失することがあり、その後他のデータと同様に受信器のリストからピアを介して受信器によって回復される。故に、ハッシュ値のインテグリティを照合する手段を用いて、他の顧客受信器が提供した情報を照合できる。
【００３０】
ハッシュ値のインテグリティを照合する手段は、Merkleハッシュ木を用いる。
【００３１】
第６の局面において本発明は、ソースと複数の顧客受信器との間で電気通信網を介してマルチキャストデータを伝送する方法を提供し、前記方法は、確実なピアツーピアの接続を介する一方の顧客受信器から他方の顧客受信器への紛失データの伝送を含む。
【００３２】
第７の局面において本発明は、ソースと複数の顧客受信器（２０１、２０２、．．．、２０Ｎ）との間で電気通信網を介してマルチキャストされるデータを受信する方法を提供し、確実なピアツーピアの接続を介して少なくとも一つの他の顧客受信器から顧客受信器により紛失データを受信することを含む。
【００３３】
第８の局面において本発明は、コンピュータの内部メモリに読み込めるコンピュータプログラムをデータ媒体上に提供し、前記プログラムは、本発明の第６の局面を構成する方法からなる段階を実行するためのコード部分を含む。
【００３４】
第９の局面において本発明は、コンピュータの内部メモリに読み込めるコンピュータプログラムをデータ媒体上に提供し、前記プログラムは、本発明の第７の局面を構成する方法からなる段階を実行するためのコード部分を含む。
【発明を実施するための最良の形態】
【００３５】
図１は、電気通信網１を介してマルチキャストソース１０とＮ個の顧客受信器２０１、２０２、．．．、２０Ｎとの間でマルチブロードキャストデータを伝送する信頼性を改善するためのシステムを示す。データは、例えばユーザデータグラムプロトコル（ＵＤＰ）を用いてネットワーク１で伝送され、そのプロトコルは、元々信頼性がないが上記言及した方法により信頼性を上げることができる。しかし、本発明は、それら方法が多数の受信器に対する多量のデータのマルチキャスト伝送にとって不利であることを鑑みて、それら方法に体系的に頼ることを避けるのが目的である。
【００３６】
図１のシステムは、監視サーバ３０を含み、そのサーバは特に、各種顧客受信器間に確実なピアツーピアの接続を目的として、それら受信器を接続することに関与する。このため、顧客が登録される時、監視サーバ３０は、既に登録されたピアであって、かつ確実なＴＣＰ／ＩＰ接続が紛失データを回復するセッションの間に確立できる、最大でＮ−１個の他のピアからなるリストを提供する。
【００３７】
前記監視サーバ３０及びマルチキャストソース１０は、同一のマシンを構成することができる。
【００３８】
第１の顧客は、Ｎ−１個のピアを取得しないが、当然それに問題は無く、というのもその顧客は、顧客数が増加する最中及び増加する時、新規顧客から連絡されるからである。
【００３９】
監視サーバ３０は、所定の受信器に関連付けられたピアを慎重に選択する必要がある点に留意することが重要である。トポロジー的意味で近いピアのみを選択することは、ネットワークコアによって、例えばリルーティングによって引起される問題が発生した場合、エラー回復を不可能にする。反対に、遠隔のピアのみを選択することは、利点がなく、ネットワークトラフィックに負担を与え、システムの効率を下げる。また、全ての関連ピアから任意にピアを選択することは、ロバスト性の観点から利点があるように見えるが、トラフィックの最適化の観点で効率を抑える。故に、最適化のためには、サーバ３０が、近隣及び遠隔のピアからなるリストを備えるのが好ましい。
【００４０】
図１に示す通り、本発明のシステムは、参照ソース４０も含み、それは、全伝送データを有し、サーバ３０が備える少なくとも一つのピアリストに現れるので、必要に応じて、紛失データを要求する関連ピアにそれを再伝送することができる。実際、参照ソース４０は、既に全てのファイルを有する顧客であり、故にマルチキャストセッションに参加していない。反対に、参照ソース４０は、参照ソース４０に接続する顧客に紛失パケットを供給することによって、さらに信頼性のあるデプロイメントに貢献する。これは、ソース１０に近いアップストリームエンドでパケット紛失が発生する場合にかなり役立ちうる。
【００４１】
また、参照ソース４０は、ソース１０及び監視サーバ３０と同一のマシン上に位置できる。
【００４２】
本発明の信頼性改善システムの説明を続ける前に、データファイルの構造を要約する必要がある。
【００４３】
データファイルは、アプリケーションの要件に依存する一つ以上のデータ“ブロック”からなる。ブロックは、アプリケーション自体によって管理され、プロトコルによって管理されない。
【００４４】
ブロックは、複数のフラグメントからなる。ピア間のコンテンツ交信のインテグリティは、これらフラグメントについて照合される。
【００４５】
フラグメントは、複数のセグメントからなり、セグメントは、例えばＵＤＰパケットでカプセル化される。
【００４６】
デプロイメントセッションの間、伝送ファイルは、ＵＤＰパケット内のセグメント形式でソース１０によって送信される。データ喪失が発生した場合、紛失セグメント又は各紛失セグメントは、Ｐ２Ｐモードで回復される。そこで、必ずしも信頼できるとはいえない第三者の顧客がダウンロードしたデータのインテグリティを保証できるメカニズムを提供し、これを比較的短期間で行うことが必要である。
【００４７】
この問題を解決する複数の方法がある。各方法は、顧客に権限を与える署名を予め安全に送信し、受信データを証明する。
【００４８】
一つの簡単な解決策は、ファイルのハッシュ値を供給することである。この方法は、ファイルが完全にダウンロードされた時だけファイルのインテグリティを照合するよう受信器に強いるので、限界がある。また、受信器が複数のピアのうち悪意のあるピアからデータセグメントを回復するよう強いられた場合、受信器それ自体は、悪意のあるピア及び怪しいデータセグメントを識別できない。
【００４９】
もう一つの解決策は、ファイルのフラグメント上のハッシュ値を計算することである。結果として、顧客が複数のセグメントからフラグメントをアセンブルするとすぐに、顧客は、そのインテグリティを照合できるので、悪意のある攻撃により迅速に反応することができる。これは、BitTorrent P2Pプロトコルで現在使用されている方法である（http://www.bittorrent.com）。この手法の欠点は、ファイルのフラグメントに対する全てのハッシュ値が安全な方法でソース１０によって供給されねばならない点にある。このデータは、フラグメントの選択サイズ（最大で数メガバイト）に依存して多少膨大になり、それを転送することは、何百万もの顧客に送信する場合に不利益を呈することがある。
【００５０】
本発明の好ましい解決策は、Merkleハッシュ木（1979, Stanford Univ, Dept of Electrical Engineering, R. Merkleの博士論文“Security, Authentication and Public Key Systems”）を用いる。図２に示すこの解決策は、ファイルのうち６つのフラグメントに関するレベル１のハッシュ値ＨＳ１１、ＨＳ１２、．．．、ＨＳ１６を計算し、先のハッシュ値ＨＳ１１等に関するレベル２のハッシュ値ＨＳ２１、ＨＳ２２、ＨＳ２３を帰納的に計算し、ルートハッシュ値ＨＲが得られるまで２つずつ取り入れる。この解決策は、先の解決策と比べて余計な計算をもたらすが、それによりソース１０は、ルートハッシュ値ＨＲのみ確実に伝送することができる。これは、デプロイメント前に完全に確実な方法で送信データ量を、例えば包括的に約１００バイトまで顕著に低減する。
【００５１】
伝送データファイルに対するMerkle木のルートハッシュ値ＨＲに関するこの情報は、データ伝送セッションに参加する必要がある全受信器２０１、．．．、２０Ｎに、信頼的、統合的、及び安全的方法でそれを配信するために、マルチキャストソース１０がメタファイルで全体的にグループ化せねばならならい一部の情報である。このメタファイルが顧客に供給される方法は、本発明の一部ではない。これは、例えば周期的に送信することによって、又はＨＴＴＰ、ＨＴＴＰＳ、ＦＴＰ、ＳＣＰプロトコルを用いることによって、容易に達成可能である。
【００５２】
Merkle木のルートハッシュ値ＨＲに加えて、前記メタファイルはさらに以下を含みうる。
・ソースのＩＰアドレス
・マルチキャストストリームのＩＰアドレス
・定期的な伝送日及びＧＭＴ時間
・データファイルの名前
・ファイルのサイズ
・Merkleハッシュ木の生成に用いるデータフラグメントのバイトサイズ
・随意的に、ブロックに関する全情報を含むリスト
・ブロック番号
・ブロックサイズ
・ファイルのブロック開始のオフセット
・随意的に、ピアと対話するために選択されたストラテジ
【００５３】
これは、データをデプロイする前に配信される数百バイトのメタファイルを生成する。証明書は、その信頼性を保証するためにメタファイルに関連付けることができる点に留意すべきである。
【００５４】
マルチキャストソース１０によって受信器へ送信される、メタファイル及びその他全てのデータ又は情報は、図３に示すフォーマットでパケット送信される。
【００５５】
最初の４バイト“Seq Num”は、パケットのシーケンス番号のために確保される。受信されたシーケンス番号を分析することにより、受信器は、一つ以上のパケットの喪失を検出できる。シーケンス番号は、データパケットが送信される順番のみに依存する。シーケンス番号は、マルチキャストパケットが送信される毎に増分される。
【００５６】
次のバイト“type”は、パケット送信された情報の種類を示す。
・値００は、そのようなデータパケットに相当し
・値０１は、レベル１のハッシュ値を含むパケットに相当し
・値０２は、レベル２のハッシュ値を含むパケットに相当し
・以下続く。
【００５７】
“type”フィールドに続くバイトは、ペイロードデータに相当し、それは、図４及び５に各々示す通り、送信ファイルからのハッシュ値又はデータで構成される。
【００５８】
データファイルに対するMerkle木のルートハッシュ値ＨＲを受信器へ確実に伝送してからそのようなデプロイメントまでに、マルチキャストソース１０は、パケットの喪失が発生した場合に後ほど回復可能なデータのインテグリティを照合するのに必要な全ハッシュ値を全ての顧客に送信する。ソースが送信するセグメント又はデータパケットは、完全に揃っている（integral）と顧客にみなされる点を覚えておく必要がある。
【００５９】
図４は、この送信に対応するパケットの一例を示す。ソース１０は、ルートハッシュ値ＨＲより低い直近のレベルであるハッシュ値を初めに送信する。例示において、ルートは、レベル７であるので、初めに送信されたパケットは、種類が０６であり、レベル６のハッシュ値、即ちＨＳ６１及びＨＳ６２を含む。２番目のパケットは、レベル５のハッシュ値を含み、以降レベルの１のハッシュ値まで続き、そのハッシュ値は、図２に示す通り、全てのファイルフラグメントに対するハッシュ値である。
【００６０】
このように、ハッシュ値からなるパケットが喪失した場合、パケットは、ピアから回復でき、そのインテグリティは、比較的高いレベルのハッシュ値に基づき照合できる。これは、照合がMerkle木のルートハッシュ値ＨＲによってその後達成されるので、初めのパケットの喪失が生じても有効であり、ルートハッシュ値は、予め確実かつ一体的に送信されたメタファイルに含まれる一部の情報である。それは、オフセットが帰納的に計算可能なので、種類が００である初めのデータパケットの喪失についても言える。
【００６１】
パケットは、パケット毎に最大で１つのレベルのみ送信するように、及び各パケットにある全ハッシュ値のみ送信するように構成される点に留意すべきである。これは、マルチキャストモードで送信されたパケットがいわゆる“パケットバウンダリ”を構成することにより可能であり、即ち顧客のソフトウェアは、ネットワーク上に送信される各パケットのサイズを監視することができる。従って、異なるサイズのハッシュ値からなるパケットを伝送することができる。
【００６２】
その後、マルチキャストソース１０は、図５に示すフォーマットのデータを含む、種類が００のパケットを送信する。この種類の、初めのパケットを用いて、シーケンス番号（Seq Num）とペイロードデータの位置との間のオフセットを計算する。このため、デプロイされるファイルの全データパケットは、最後のものを除いて同一のサイズでなければならない。この情報により、喪失した場合のファイルを再構成することができる。
【００６３】
故に、パケットのシーケンス番号により、受信器は、ソースが送信したデータの喪失を検出し、そのピアを介した修復をもたらすことができる。伝送中、又は伝送が任意の理由により妨害されている時、喪失を必ず検出することができる。多様な状況がありうるが、ソースにより伝送が中止されること、及び伝送ネットワークにおける喪失の間は区別されねばならない。
【００６４】
１．ファイル伝送の終わりに、ソースは、最後に送信したセグメントに対するシーケンス番号を示すフィールドを含むＥＮＤメッセージを送信する。このメッセージは、何回か送信され、ネットワークでの喪失が生じた場合にファイルが確実に受信できることを保証する。このメッセージの受信時、受信器は、パケットが喪失したかを容易に識別し、その後修復することができる。
【００６５】
２．ソースが伝送を一時的に中止する場合、ソースは、最後に送信したパケットに対するシーケンス番号を含むＰＡＵＳＥメッセージを送信する必要がある。受信器は、上記の状況と類似の方法で修復することができる。
【００６６】
３．ＥＮＤ又はＰＡＵＳＥメッセージ以外のデータ受信が長期に中止される場合、伝送の中断に達する前にタイムアウトが引起される。その後受信器は、ネットワークにおける中断の位置に依存して、そのピアと交信可能な場合に修復を始めるよう試みることができる。
【００６７】
４．受信したファイルのサイズを分析することにより伝送の検出を終了することもできる。伝送ファイルのサイズは実際、マルチキャストソースにより初めに供給された情報メタファイルのパラメータである。
【００６８】
受信器による紛失データの回復中にピア間で対話するメカニズムは、以下に詳述される。
【００６９】
ピアへの接続は、Merkleルートハッシュ値ＨＲを提供することにより常に要求され、それにより、デプロイメントの対象であるデータファイルを確実に識別する。しかし、ファイル名又はファイル識別子のような他の識別手段を想定することができる。識別子を供給することにより、受信器は、セッション間を区別及びセッションを識別することができる。
【００７０】
対象となるピアの環境が必ずしも協力的でないことを考えると、ピア間の接続に“しっぺ返し（tit-for-tat）”手法を設けるのが好ましいかもしれない。
【００７１】
この場合、各顧客のピアは、一方のピアから他方のピアへ同時に伝送する回数を制限し、他方のピアに向かう伝送のうち最も多量な伝送を優先せねばならない。選択基準は以下の通りである。
【００７２】
・最も高いビットレートでデータを伝送する過程にあるピアが最も優先され、
・そうでなければ、最も多くのデータを供給するピアを優先し、
・上記状況がいずれも適用されない場合、上記の通り、任意に、又はトポロジー的情報に応じて、（複数の）ピアを選択する。
【００７３】
しかし、マルチキャストモードでは、受信器は、修復の開始を決定する時にそのピアとの交信を検証していない。受信器は、どのピアが最良のピアなのか帰納的に識別していない。
【００７４】
受信器は、データの喪失を検出すると、修復過程の開始を決定する必要がある。動作における重要な局面は、ピアへの要求を最適化することである。マルチキャスト伝送の特徴は、ある状況において、全ての顧客が同時にフラグメント又はブロックの終わりを検出するので、顧客がデータの喪失を検出する場合、ある程度同時に回復手順を始めようとすることにある。その結果、交信過程において、これらイベントによって引起される多量のメッセージが回避され、トラフィックのバーストによるネットワークの混雑というリスクを軽減する。複数の状況が以下のように考えられる。
【００７５】
１．受信器は、ＰＡＵＳＥメッセージによって示される、ブロック、フラグメント、又はファイルの終わりを待ち、例えばそのピアを介して修復を開始する。要求は、喪失セグメントのリスト又はセグメントの喪失範囲のリストを含むことができる。各受信器は、メタファイルにおける追加のフィールドにすることができる所定の窓に疑似乱数の時間遅延を起こす。故に、要求は、ネットワーク負荷を平滑化するよう、限られた時間で配信される。補足データが受信されると直ちに、各受信器は、ハッシュ値による情報を用いてフラグメントのインテグリティを照合する。
【００７６】
２．受信器は、ＰＡＵＳＥメッセージを待つことなく、孤立パケットの喪失又はパケット範囲の喪失を検出するとすぐに修復を始める。受信器は、下記に定義された要求メッセージ（ＲＥＱＵＥＳＴ）を送信する前に、上記のように時間遅延を起こす。
【００７７】
これら解決策のどれか一方の選択は、アプリケーション、エラー率、及びエラー分布を要因とする。
【００７８】
以下の表１は、紛失データ回復プロトコルで使用されるピア間の信号伝達に関する全ての命令を定義する。
【００７９】
【表１】
【００８０】
図６は、表１による信号伝達メッセージを用いたピアＡ、Ｂ、Ｃ間の交信セッションに対する一例を示す。
【００８１】
ピア間のダウンロードを体系化するための２つのストラテジがある。
【００８２】
・第１の手法は、ピア自体が盲目（blind）であるかを問合せる。これは、送信メッセージ数を節約し、低い損失率のネットワーク、及び紛失パケットを迅速に到達させる必要がない点で最適である。各顧客は、自分のピアによってパケットが受信されたか分からないので、顧客が望むデータが得られるまで連続的にピアを問合せる。
・第２の手法は、フラグメントが受信されるとすぐ、顧客が利用可能なフラグメントをピアに通知する。このため、以下の表２に定義される、２つの新規メッセージを導入する必要がある。
【００８３】
【表２】
【００８４】
フラグメントが揃うと、顧客は、一部データがマルチキャストソースから来ない場合、Merkleハッシュ木を用いてフラグメントのインテグリティを照合する必要がある。その後マルチキャストソースは、その一部データをピアに供給することができる。
【００８５】
マルチキャスト（ＵＤＰ／ＩＰ）伝送は、通常一定である、ソースの出力ビットレートを調節する簡単な方法がないので、ネットワークの混雑にかなり敏感である。従って、ネットワークにおける任意の位置での再伝送がマルチキャストパケットの伝送を妨害しないことが重要である。この反応は、ＴＣＰトラフィックがＵＤＰの余地を残すので、ＩＰネットワークでは普通である。ＵＤＰビットレートがリンク上で許可されている最大ビットレートにかなり近い場合、唯一のリスクは修復が遅れることである。
【００８６】
再伝送が混雑を引起す場合、その後修復過程を開始するために伝送の終わりを待つ必要がある。上記手段は、不変である。
【００８７】
また、本発明は、データの前に受信器へ伝送されるMerkleハッシュ木のルートを提供する。
【００８８】
このルートは、任意の手段、好ましくは確実な手段によって伝送されうる。特に、データソースは、データを前記電気通信網へ確実にマルチブロードキャストする前に、受信器へ前記Merkleハッシュ木のルートを伝送するよう適合される。他の伝送手段は、ウェブページ又は電子メール等が当然に想定可能である。
【００８９】
同様に、本発明によると、前記データソースは、前記ルートの伝送からデータの伝送までの間、前記ルートより低いレベルのハッシュ値を受信器へ伝送するよう適合される。
【００９０】
また、本発明は、電気通信網を介して前記データを複数の受信器へマルチブロードキャストするデータソースに関し、特にデータソースが前記電気通信網へデータを確実にマルチブロードキャストする前に、データに対するMerkleハッシュ木のルートを受信器へ伝送できる点に注目すべきである。
【００９１】
また、前記データソースは、前記ルートの伝送から前記データの伝送までの間、前記ルートより低いレベルのハッシュ値を受信器に伝送できる。
【００９２】
また、本発明は、データのソースと前記データに対する複数の受信器との間で電気通信網を介してマルチブロードキャストデータを伝送する信頼性を改善するための、システムの監視サーバに関し、特に前記監視サーバは、少なくとも１つの他の受信器を含むリストを各受信器へ供給でき、前記リストは、前記受信器と前記他の受信器との間に確実なピアツーピアの接続を設定するのに使用されるのが特筆すべき点である。また、リストは、データを有する参照ソースを含む。
【００９３】
また、本発明は、データのソースと前記データに対する複数の受信器との間で電気通信網を介してマルチブロードキャストデータを伝送する信頼性を改善するための、システムの参照ソースに関し、特に前記参照ソースは、前記データを有し、少なくとも一つの受信器に対して確実なピアツーピアの接続を設定するよう適合されるのが特筆すべき点である。
【００９４】
また、本発明は、データのソースと前記データに対する複数の受信器との間で電気通信網を介してマルチブロードキャストデータを伝送する信頼性を改善するための、システムの受信器に関し、特に前記受信器は、ピアツーピアの接続中に前記他の受信器が供給したデータのインテグリティを照合するための手段を含むことが特筆すべき点である。
【００９５】
最後に、本発明は、データのソースと前記データに対する複数の受信器（２０１、２０２、．．．、２０Ｎ）との間で電気通信網を介してマルチブロードキャストデータを伝送する信頼性を改善するためのシステムに関し、前記システムは、少なくとも１つの他の受信器を含むリストを各受信器に提供するよう適合される監視サーバを含み、前記受信器は、確実なピアツーピアの接続を介して前記他の受信器から紛失データを受信できる。
【００９６】
また、システムは、参照ソースを含み、参照ソースは、前記データを有し、前記監視サーバが供給した少なくとも一つのリストに現れる。
【００９７】
システムでは、各受信器は、ピアツーピアの接続中に前記他の受信器が供給したデータのインテグリティを照合するための手段を含む。
【００９８】
システムでは、前記照合手段は、少なくとも一つの他の受信器から受信したデータのフラグメントに対するハッシュ値を計算するための手段と、前記データソースから受信した前記フラグメントに対するハッシュ値と前記計算したハッシュ値とを比較するための手段とを含む。
【００９９】
システムでは、各受信器は、ピアツーピアの接続中に前記他の受信器が供給したハッシュ値のインテグリティを照合するための手段を含む。
【０１００】
システムでは、前記ハッシュ値インテグリティ照合手段は、Merkleハッシュ木を用いる。
【０１０１】
システムでは、Merkleハッシュ木のルートは、前記データの伝送前に前記受信器に伝送される。
【０１０２】
システムでは、データソースは、前記電気通信網を介して前記データを確実にマルチブロードキャストする前に前記Merkleハッシュ木のルートを前記受信器に伝送することができる。
【０１０３】
システムでは、データソースは、前記ルートの伝送から前記データの伝送までに前記ルートより低いレベルのハッシュ値を前記受信器に伝送することができる。
【０１０４】
システムでは、確実なピアツーピアの接続がＴＣＰ接続を用いて設定される。
【図面の簡単な説明】
【０１０５】
【図１】図１は、マルチキャストデータ伝送の信頼性を改善するための、本発明のシステムに関する図である。
【図２】図２は、本発明で用いるMerkleハッシュ木を示す。
【図３】図３は、マルチキャストソースから受信器へデータを伝送するパケットフォーマットを示す。
【図４】図４は、マルチキャストソースによって受信器へ伝送されるハッシュ木の例を与える。
【図５】図５は、マルチキャストソースによって受信器へ伝送されるデータパケットの例を与える。
【図６】図６は、受信器と２つの受信器ピアとの間におけるデータ回復セッションの図である。
【符号の説明】
【０１０６】
１０ マルチキャストソース
２０ 顧客
３０ 監視サーバ
４０ Ｐ２Ｐソース
【技術分野】
【０００１】
本発明は、データのソースと前記データに対する複数の受信器との間で電気通信網を介してマルチブロードキャストデータを伝送する信頼性を改善するためのシステムに関する。
【背景技術】
【０００２】
本発明は、“マルチキャスト”モードとしても知られる、マルチブロードキャストモードでデータを伝送する分野において、特に有利な用途を見出す。
【０００３】
用語“マルチブロードキャスト”及び“マルチキャスト”は、以下の説明では交互に使用され、用語“マルチキャスト”は、この分野で広く使用されている。
【０００４】
効率的に大量のデータを配信するための精密な制御は、インターネットサービスプロバイダ（ISPはInternet Service Providerの略）にとって重要である。現在の傾向は、ホームゲートウェイ及びセットトップボックス（ＳＴＢ）形式で家庭に設置されたネットワーク機器を遠隔で供給及び管理することである。家庭に設置された機器は、以下“受信器”又は“顧客”と称する。
【０００５】
従って、ＩＳＰが制御する一つ又は少数のポイントから管理される必要がある何百万個もの受信器が潜在的にある。また、ウイルスが拡散し続け、今は個人コンピュータに影響するだけでなく、個人デジタル機器（ＰＤＡ）、携帯電話、上記ホームゲートウェイ、及びＳＴＢのような機器を用いた電子データ処理に基づきアプリケーションを伝達することに関るあらゆるものに影響することが次第に明らかになっている。ウイルス及びその他破壊工作ソフトの作者は、自らの技術を次第に向上させ、セキュリティ欠陥が公衆上に生じる時とウイルスがセキュリティ欠陥の利用目的で開発される時との差が縮まってきている。
【０００６】
従って、オペレータが管理する全ての家庭用受信器を更新するための技術をかなり迅速にマスターすることが重要になってきている。機器の信頼性とサービス品質とは、上記更新技術に依存し、上記更新技術は、かなり多数の顧客からなる家庭において迅速かつ効率的な更新解決策によって実行されねばならない。
【０００７】
この問題を解決する第１の方法は、配信に関係なく、多数のコンテンツサーバを用いることである。その解決策は、サーバ数の多いリソースと多数のネットワークリソースとを必要とするため、かなりコストがかかるかもしれない。また、許容範囲の妥協策を達成するには、サーバ管理者は、所定の最大数の更新を毎日実行することにより適時にタスクを拡散するポリシーを頻繁に用いる。そのストラテジは、緊急電話（“ホットライン”）の発信がしばしばソフトウェアの更新時に増えないようにする点で有利だが、例えばセキュリティモジュールを迅速にデプロイするのに全く適さない。
【０００８】
第２の方法は、マルチブロードキャスト、即ち“マルチキャスト”方法であり、僅かな数から何百万もの任意の受信器グループにデータソースが素早く連絡できる、簡単かつ効率的な手段を構成するが、その解決策は、ＵＤＰ（ユーザデータグラムプロトコル）に基づくものであり、顧客に正しくデータが伝送される保証がなく、例えば一部のデータが接続又はルータレベルで喪失することがある。その欠点は、紛失データを回復できる帰路チャンネルがないことに起因して悪化する。かなり多くの受信器を備えた任意のそのようなシステムを監視することは問題がある。
【０００９】
しかし、ＩＥＴＦグループによるＲＭＴ（確実なマルチキャスト伝送）は、マルチキャスト伝送の信頼性を改善するという課題に着目し、主に２つのカテゴリに分類可能な一組の解決策を提案する。
【００１０】
・ＦＥＣ（前進型誤信号訂正）による解決策は、情報量が限定されている場合、喪失又は紛失情報を計算するために余分な情報を追加することに基づくものであり、冗長性に対する一つの特有の例は、顧客グループに向けられる全データにＦＥＣを行うことなく巡回ブロードキャストすることである。
・もう一つの解決策は、少なくとも一人のユーザにより喪失されたパケットを要求して後続的にグループ全体へ伝送するために、喪失時に顧客からフィードバックされた情報に対し精密な制御を行うことに基づくものであり、この場合、一組のサービスを妨げるリスクのあるＤＤｏＳ（分散型サービス）攻撃に関連しうる、端末からサーバ方向でのネットワーク負荷を回避する特定のメカニズムが必要である。
【００１１】
それら２つの技法を共に用いると、ネットワーク上の伝送を最適化するが、ファイルを正しく受信した受信器からなるリストをアプリケーションが必要とする場合、ＤＤｏＳ型の攻撃に関する問題は残る。
【００１２】
簡単に言うと、マルチキャストデータ伝送の信頼性を改善する方法は、以下の制限を有する。
【００１３】
多数のサーバを用いる方法によると、かなり多数の受信器が中央サイトによって管理されている場合、そのサイトは、サイトの内部リソースに依存して、限られた数の同時要求のみ受け入れできることが分かる。そのような要求は、ポイントツーポイントセッション、特にＴＣＰセッションに基づく。多数の受信器に対する同時管理を許可するには、データソースは、要求を配信する一組のマシンを組込まざるを得ない。それら解決策は、良好な負荷配分を行う管理者にとって通常コストが高く複雑である。
【００１４】
確実なマルチキャスト伝送に戻ると、
・ＦＥＣベースの解決策は、単一ソースから全受信器へ連絡できるが、エンドネットワークで主に遭遇する集中的な損失に対して受信器がかなり敏感であるので、データがいつも確実に受信されることを保証しない。また、全ての端末が同時にアクティブになるわけでなく、時々周期的にデータファイルを伝送する必要があること
・肯定応答の返信に基づく解決策は、かなり多数の受信器グループを管理できるが、それはソースへフィードバックされる情報量が限定されている場合のみ可能である。このポイントは、“ＮＡＫ集中”現象を制限することにより特徴付けられ、ここでＮＡＫは、データパケットの喪失の検出時のみ送信される否定応答を意味する。そのタイプからなる殆どの解決策は、ソースから受信器へのマルチキャスト伝送だけでなく、ソースと同一セッションに含まれる必要がある各受信器から全メッセージが送信されるマルチキャスト伝送にも依存する。それは、“１−＞Ｎ”マルチブロードキャストセッションから区別するために“Ｎ−＞Ｎ”モードと称されるマルチキャストモードである。その後、データ送信に関して受信器と競うソースは、以下の複数の理由で問題となる
ことが分かる
・データグラムモードでデータを送信すると、ＴＣＰとは対照的に、利用可能なビットレートを制御することができず、ＴＣＰにおける制御は不可能ではないが、異なる種類に組込まれた受信器ベースでアドレスを行うセッションにおいてかなり困難である。かなり多数の受信器による伝送は、受信器による追加の伝送をもたらす損失に反映されてネットワーク接続を飽和し、混雑状況を悪化させることがある。
・多数のネットワークは、“Ｎ−＞Ｎ”モードの動作に互換性がない。また、多数のオペレータは、意図的に“１−＞Ｎ”モードに自分のネットワークを限定し、制御を維持し、ＤＤｏＳ型の攻撃に関連しうる、無制御状態の混雑を防ぐ。
【発明の開示】
【発明が解決しようとする課題】
【００１５】
故に、本発明の主題により解決すべき技術的問題は、データのソースと前記データに対する複数の受信器との間で電気通信網を介してマルチブロードキャストデータを伝送する信頼性を改善するシステムを提案することにあり、それにより確実にデータを伝送できるようになり、即ち任意の喪失データを修復し、回復データのインテグリティを保証できるようになり、それは、ネットワークコスト及び配信サーバコストの観点から経済的であり、高パフォーマンス、即ち何百万もの顧客に迅速なデプロイを提供し、しかも任意の大規模なフィードバックメカニズムが不要である。
【課題を解決するための手段】
【００１６】
上記技術的問題に対する本発明の解決策によると、前記システムは、少なくとも一つの他の顧客受信器からなるリストを各顧客受信器に提供するよう適合される監視サーバを含み、前記顧客受信器は、確実なピアツーピアの接続を介して前記他の顧客受信器から紛失データを受信できる。
【００１７】
ここで、ピアツーピアの接続概念は、“ピアツーピア”（Ｐ２Ｐ）交信に基づき最近導入されたプロトコル群に属する。ピアツーピアネットワークの特徴によると、端末は、顧客と同時にリソースを利用し、サーバと同時にリソースを提供することである。例えば、Ｐ２Ｐプロトコルを共有する最良のデータファイルは、スウォーミング方法を使用し、それによりファイルは、複数部分に分割され、複数のソース端末からダウンロード可能になり、負荷分散、速度、及びロバスト性を最適化する。
【００１８】
故に、本発明は、従来のマルチブロードキャストメカニズムを使用し、マルチキャストソースは、オペレータがアドホックプロトコルを用いてネットワーク中の顧客受信器からなるグループにデータ、例えばファイルをブロードキャストすることに関与する。マルチキャストパケットが対応するトランスポート層の非信頼性を考えると（特にＵＤＰ）、データがネットワークで喪失する可能性がある。この問題を解決するために、本発明は、ピアツーピアのネットワーク手法の使用を提案する。各顧客受信器は、セッション中に維持されるＴＣＰ／ＩＰ接続のような確実な接続によって、顧客受信器からなるピアのうち特定のピアに接続される。データパケットの喪失を受信器が検出すると、受信器は、ピアに連絡し、対象のパケットを回復する。
【００１９】
言い換えると、本発明は、以下の２つの技法を組み合わせてデータ伝送を最適化する。マルチキャスト技法により、かなり多数の顧客に対するダウンロードを可能にする一方で、Ｐ２Ｐ接続は、かなり多くのエラーメッセージを顧客から単一ソースにフィードバックするのを避ける。
【００２０】
第２の局面において本発明は、電気通信網を介して前記データに対する複数の顧客受信器にマルチブロードキャストされるデータのソースを提供し、前記データのソースは、データの伝送前に前記顧客受信器に、前記データに対するMerkleハッシュ木のルートハッシュ値ＨＲを、前記電気通信網を介した確実なマルチブロードキャストにより伝送するよう適合され、前記データのソースは、前記ルートハッシュ値の伝送から前記データの伝送までに前記ルートハッシュ値ＨＲより低いレベルのハッシュ値を顧客受信器に伝送するよう適合され、顧客受信器は、確実なピアツーピアの接続を介して他の顧客受信器から紛失データを受信するよう適合される。
【００２１】
第３の局面において本発明は、データのソースと前記データに対する複数の顧客受信器との間で電気通信網を介してマルチキャストデータを伝送する信頼性を改善するためのシステムに監視サーバを提供し、前記監視サーバは、少なくとも一つの他の顧客受信器からなるリストを各顧客受信器に提供するよう適合され、前記リストは、前記顧客受信器と前記他の顧客受信器との間に確実なピアツーピアの接続を確立することを意図する。
【００２２】
第４の局面において本発明は、データのソースと前記データに対する複数の顧客受信器との間で電気通信網（１）を介してマルチキャストデータを伝送する信頼性を改善するためのシステムに参照ソースを提供し、前記参照ソース（４０）は、前記データを有し、少なくとも一つの顧客受信器に確実なピアツーピアの接続を確立するよう適合される。
【００２３】
故に、全受信器に対するデータパケットが喪失した場合、監視サーバによって供給されるリストに参照ソースを有するそれら受信器はその後、前記参照ソースにピアツーピアの接続を確立して前記喪失パケットを回復でき、そのような回復は、受信器間のピアツーピアの接続メカニズムによって、他の受信器に反映される。
【００２４】
第５の局面において本発明は、データのソースと前記データに対する複数の顧客受信器との間で電気通信網を介してマルチキャストデータを伝送する信頼性を改善するためのシステムに顧客受信器を提供し、前記顧客受信器は、ピアツーピアの接続中に前記他の顧客受信器が提供したデータのインテグリティを照合するための手段を含む。
【００２５】
故に、受信器が自ら有するリストにある他の受信器からデータを回復する時、受信データが所望のデータに相当するか確かめることができる。
【００２６】
好ましい非限定的な実施形態によると、本発明の第５の局面は、以下の追加の特徴を、単独又は組合せで有する。
【００２７】
照合手段は、少なくとも一つの他の顧客受信器から受信したデータのフラグメントに対するハッシュ値を計算するための手段と、前記データのソースから受信した前記フラグメントに対するハッシュ値と計算したハッシュ値とを比較するための手段とを含む。
【００２８】
顧客受信器は、ピアツーピアの接続中に前記他の顧客受信器が提供したハッシュ値のインテグリティを照合するための手段を含む。
【００２９】
ソースから受信したハッシュ値は、未だ確実でないマルチキャスト接続上で一般に伝送されるので喪失することがあり、その後他のデータと同様に受信器のリストからピアを介して受信器によって回復される。故に、ハッシュ値のインテグリティを照合する手段を用いて、他の顧客受信器が提供した情報を照合できる。
【００３０】
ハッシュ値のインテグリティを照合する手段は、Merkleハッシュ木を用いる。
【００３１】
第６の局面において本発明は、ソースと複数の顧客受信器との間で電気通信網を介してマルチキャストデータを伝送する方法を提供し、前記方法は、確実なピアツーピアの接続を介する一方の顧客受信器から他方の顧客受信器への紛失データの伝送を含む。
【００３２】
第７の局面において本発明は、ソースと複数の顧客受信器（２０１、２０２、．．．、２０Ｎ）との間で電気通信網を介してマルチキャストされるデータを受信する方法を提供し、確実なピアツーピアの接続を介して少なくとも一つの他の顧客受信器から顧客受信器により紛失データを受信することを含む。
【００３３】
第８の局面において本発明は、コンピュータの内部メモリに読み込めるコンピュータプログラムをデータ媒体上に提供し、前記プログラムは、本発明の第６の局面を構成する方法からなる段階を実行するためのコード部分を含む。
【００３４】
第９の局面において本発明は、コンピュータの内部メモリに読み込めるコンピュータプログラムをデータ媒体上に提供し、前記プログラムは、本発明の第７の局面を構成する方法からなる段階を実行するためのコード部分を含む。
【発明を実施するための最良の形態】
【００３５】
図１は、電気通信網１を介してマルチキャストソース１０とＮ個の顧客受信器２０１、２０２、．．．、２０Ｎとの間でマルチブロードキャストデータを伝送する信頼性を改善するためのシステムを示す。データは、例えばユーザデータグラムプロトコル（ＵＤＰ）を用いてネットワーク１で伝送され、そのプロトコルは、元々信頼性がないが上記言及した方法により信頼性を上げることができる。しかし、本発明は、それら方法が多数の受信器に対する多量のデータのマルチキャスト伝送にとって不利であることを鑑みて、それら方法に体系的に頼ることを避けるのが目的である。
【００３６】
図１のシステムは、監視サーバ３０を含み、そのサーバは特に、各種顧客受信器間に確実なピアツーピアの接続を目的として、それら受信器を接続することに関与する。このため、顧客が登録される時、監視サーバ３０は、既に登録されたピアであって、かつ確実なＴＣＰ／ＩＰ接続が紛失データを回復するセッションの間に確立できる、最大でＮ−１個の他のピアからなるリストを提供する。
【００３７】
前記監視サーバ３０及びマルチキャストソース１０は、同一のマシンを構成することができる。
【００３８】
第１の顧客は、Ｎ−１個のピアを取得しないが、当然それに問題は無く、というのもその顧客は、顧客数が増加する最中及び増加する時、新規顧客から連絡されるからである。
【００３９】
監視サーバ３０は、所定の受信器に関連付けられたピアを慎重に選択する必要がある点に留意することが重要である。トポロジー的意味で近いピアのみを選択することは、ネットワークコアによって、例えばリルーティングによって引起される問題が発生した場合、エラー回復を不可能にする。反対に、遠隔のピアのみを選択することは、利点がなく、ネットワークトラフィックに負担を与え、システムの効率を下げる。また、全ての関連ピアから任意にピアを選択することは、ロバスト性の観点から利点があるように見えるが、トラフィックの最適化の観点で効率を抑える。故に、最適化のためには、サーバ３０が、近隣及び遠隔のピアからなるリストを備えるのが好ましい。
【００４０】
図１に示す通り、本発明のシステムは、参照ソース４０も含み、それは、全伝送データを有し、サーバ３０が備える少なくとも一つのピアリストに現れるので、必要に応じて、紛失データを要求する関連ピアにそれを再伝送することができる。実際、参照ソース４０は、既に全てのファイルを有する顧客であり、故にマルチキャストセッションに参加していない。反対に、参照ソース４０は、参照ソース４０に接続する顧客に紛失パケットを供給することによって、さらに信頼性のあるデプロイメントに貢献する。これは、ソース１０に近いアップストリームエンドでパケット紛失が発生する場合にかなり役立ちうる。
【００４１】
また、参照ソース４０は、ソース１０及び監視サーバ３０と同一のマシン上に位置できる。
【００４２】
本発明の信頼性改善システムの説明を続ける前に、データファイルの構造を要約する必要がある。
【００４３】
データファイルは、アプリケーションの要件に依存する一つ以上のデータ“ブロック”からなる。ブロックは、アプリケーション自体によって管理され、プロトコルによって管理されない。
【００４４】
ブロックは、複数のフラグメントからなる。ピア間のコンテンツ交信のインテグリティは、これらフラグメントについて照合される。
【００４５】
フラグメントは、複数のセグメントからなり、セグメントは、例えばＵＤＰパケットでカプセル化される。
【００４６】
デプロイメントセッションの間、伝送ファイルは、ＵＤＰパケット内のセグメント形式でソース１０によって送信される。データ喪失が発生した場合、紛失セグメント又は各紛失セグメントは、Ｐ２Ｐモードで回復される。そこで、必ずしも信頼できるとはいえない第三者の顧客がダウンロードしたデータのインテグリティを保証できるメカニズムを提供し、これを比較的短期間で行うことが必要である。
【００４７】
この問題を解決する複数の方法がある。各方法は、顧客に権限を与える署名を予め安全に送信し、受信データを証明する。
【００４８】
一つの簡単な解決策は、ファイルのハッシュ値を供給することである。この方法は、ファイルが完全にダウンロードされた時だけファイルのインテグリティを照合するよう受信器に強いるので、限界がある。また、受信器が複数のピアのうち悪意のあるピアからデータセグメントを回復するよう強いられた場合、受信器それ自体は、悪意のあるピア及び怪しいデータセグメントを識別できない。
【００４９】
もう一つの解決策は、ファイルのフラグメント上のハッシュ値を計算することである。結果として、顧客が複数のセグメントからフラグメントをアセンブルするとすぐに、顧客は、そのインテグリティを照合できるので、悪意のある攻撃により迅速に反応することができる。これは、BitTorrent P2Pプロトコルで現在使用されている方法である（http://www.bittorrent.com）。この手法の欠点は、ファイルのフラグメントに対する全てのハッシュ値が安全な方法でソース１０によって供給されねばならない点にある。このデータは、フラグメントの選択サイズ（最大で数メガバイト）に依存して多少膨大になり、それを転送することは、何百万もの顧客に送信する場合に不利益を呈することがある。
【００５０】
本発明の好ましい解決策は、Merkleハッシュ木（1979, Stanford Univ, Dept of Electrical Engineering, R. Merkleの博士論文“Security, Authentication and Public Key Systems”）を用いる。図２に示すこの解決策は、ファイルのうち６つのフラグメントに関するレベル１のハッシュ値ＨＳ１１、ＨＳ１２、．．．、ＨＳ１６を計算し、先のハッシュ値ＨＳ１１等に関するレベル２のハッシュ値ＨＳ２１、ＨＳ２２、ＨＳ２３を帰納的に計算し、ルートハッシュ値ＨＲが得られるまで２つずつ取り入れる。この解決策は、先の解決策と比べて余計な計算をもたらすが、それによりソース１０は、ルートハッシュ値ＨＲのみ確実に伝送することができる。これは、デプロイメント前に完全に確実な方法で送信データ量を、例えば包括的に約１００バイトまで顕著に低減する。
【００５１】
伝送データファイルに対するMerkle木のルートハッシュ値ＨＲに関するこの情報は、データ伝送セッションに参加する必要がある全受信器２０１、．．．、２０Ｎに、信頼的、統合的、及び安全的方法でそれを配信するために、マルチキャストソース１０がメタファイルで全体的にグループ化せねばならならい一部の情報である。このメタファイルが顧客に供給される方法は、本発明の一部ではない。これは、例えば周期的に送信することによって、又はＨＴＴＰ、ＨＴＴＰＳ、ＦＴＰ、ＳＣＰプロトコルを用いることによって、容易に達成可能である。
【００５２】
Merkle木のルートハッシュ値ＨＲに加えて、前記メタファイルはさらに以下を含みうる。
・ソースのＩＰアドレス
・マルチキャストストリームのＩＰアドレス
・定期的な伝送日及びＧＭＴ時間
・データファイルの名前
・ファイルのサイズ
・Merkleハッシュ木の生成に用いるデータフラグメントのバイトサイズ
・随意的に、ブロックに関する全情報を含むリスト
・ブロック番号
・ブロックサイズ
・ファイルのブロック開始のオフセット
・随意的に、ピアと対話するために選択されたストラテジ
【００５３】
これは、データをデプロイする前に配信される数百バイトのメタファイルを生成する。証明書は、その信頼性を保証するためにメタファイルに関連付けることができる点に留意すべきである。
【００５４】
マルチキャストソース１０によって受信器へ送信される、メタファイル及びその他全てのデータ又は情報は、図３に示すフォーマットでパケット送信される。
【００５５】
最初の４バイト“Seq Num”は、パケットのシーケンス番号のために確保される。受信されたシーケンス番号を分析することにより、受信器は、一つ以上のパケットの喪失を検出できる。シーケンス番号は、データパケットが送信される順番のみに依存する。シーケンス番号は、マルチキャストパケットが送信される毎に増分される。
【００５６】
次のバイト“type”は、パケット送信された情報の種類を示す。
・値００は、そのようなデータパケットに相当し
・値０１は、レベル１のハッシュ値を含むパケットに相当し
・値０２は、レベル２のハッシュ値を含むパケットに相当し
・以下続く。
【００５７】
“type”フィールドに続くバイトは、ペイロードデータに相当し、それは、図４及び５に各々示す通り、送信ファイルからのハッシュ値又はデータで構成される。
【００５８】
データファイルに対するMerkle木のルートハッシュ値ＨＲを受信器へ確実に伝送してからそのようなデプロイメントまでに、マルチキャストソース１０は、パケットの喪失が発生した場合に後ほど回復可能なデータのインテグリティを照合するのに必要な全ハッシュ値を全ての顧客に送信する。ソースが送信するセグメント又はデータパケットは、完全に揃っている（integral）と顧客にみなされる点を覚えておく必要がある。
【００５９】
図４は、この送信に対応するパケットの一例を示す。ソース１０は、ルートハッシュ値ＨＲより低い直近のレベルであるハッシュ値を初めに送信する。例示において、ルートは、レベル７であるので、初めに送信されたパケットは、種類が０６であり、レベル６のハッシュ値、即ちＨＳ６１及びＨＳ６２を含む。２番目のパケットは、レベル５のハッシュ値を含み、以降レベルの１のハッシュ値まで続き、そのハッシュ値は、図２に示す通り、全てのファイルフラグメントに対するハッシュ値である。
【００６０】
このように、ハッシュ値からなるパケットが喪失した場合、パケットは、ピアから回復でき、そのインテグリティは、比較的高いレベルのハッシュ値に基づき照合できる。これは、照合がMerkle木のルートハッシュ値ＨＲによってその後達成されるので、初めのパケットの喪失が生じても有効であり、ルートハッシュ値は、予め確実かつ一体的に送信されたメタファイルに含まれる一部の情報である。それは、オフセットが帰納的に計算可能なので、種類が００である初めのデータパケットの喪失についても言える。
【００６１】
パケットは、パケット毎に最大で１つのレベルのみ送信するように、及び各パケットにある全ハッシュ値のみ送信するように構成される点に留意すべきである。これは、マルチキャストモードで送信されたパケットがいわゆる“パケットバウンダリ”を構成することにより可能であり、即ち顧客のソフトウェアは、ネットワーク上に送信される各パケットのサイズを監視することができる。従って、異なるサイズのハッシュ値からなるパケットを伝送することができる。
【００６２】
その後、マルチキャストソース１０は、図５に示すフォーマットのデータを含む、種類が００のパケットを送信する。この種類の、初めのパケットを用いて、シーケンス番号（Seq Num）とペイロードデータの位置との間のオフセットを計算する。このため、デプロイされるファイルの全データパケットは、最後のものを除いて同一のサイズでなければならない。この情報により、喪失した場合のファイルを再構成することができる。
【００６３】
故に、パケットのシーケンス番号により、受信器は、ソースが送信したデータの喪失を検出し、そのピアを介した修復をもたらすことができる。伝送中、又は伝送が任意の理由により妨害されている時、喪失を必ず検出することができる。多様な状況がありうるが、ソースにより伝送が中止されること、及び伝送ネットワークにおける喪失の間は区別されねばならない。
【００６４】
１．ファイル伝送の終わりに、ソースは、最後に送信したセグメントに対するシーケンス番号を示すフィールドを含むＥＮＤメッセージを送信する。このメッセージは、何回か送信され、ネットワークでの喪失が生じた場合にファイルが確実に受信できることを保証する。このメッセージの受信時、受信器は、パケットが喪失したかを容易に識別し、その後修復することができる。
【００６５】
２．ソースが伝送を一時的に中止する場合、ソースは、最後に送信したパケットに対するシーケンス番号を含むＰＡＵＳＥメッセージを送信する必要がある。受信器は、上記の状況と類似の方法で修復することができる。
【００６６】
３．ＥＮＤ又はＰＡＵＳＥメッセージ以外のデータ受信が長期に中止される場合、伝送の中断に達する前にタイムアウトが引起される。その後受信器は、ネットワークにおける中断の位置に依存して、そのピアと交信可能な場合に修復を始めるよう試みることができる。
【００６７】
４．受信したファイルのサイズを分析することにより伝送の検出を終了することもできる。伝送ファイルのサイズは実際、マルチキャストソースにより初めに供給された情報メタファイルのパラメータである。
【００６８】
受信器による紛失データの回復中にピア間で対話するメカニズムは、以下に詳述される。
【００６９】
ピアへの接続は、Merkleルートハッシュ値ＨＲを提供することにより常に要求され、それにより、デプロイメントの対象であるデータファイルを確実に識別する。しかし、ファイル名又はファイル識別子のような他の識別手段を想定することができる。識別子を供給することにより、受信器は、セッション間を区別及びセッションを識別することができる。
【００７０】
対象となるピアの環境が必ずしも協力的でないことを考えると、ピア間の接続に“しっぺ返し（tit-for-tat）”手法を設けるのが好ましいかもしれない。
【００７１】
この場合、各顧客のピアは、一方のピアから他方のピアへ同時に伝送する回数を制限し、他方のピアに向かう伝送のうち最も多量な伝送を優先せねばならない。選択基準は以下の通りである。
【００７２】
・最も高いビットレートでデータを伝送する過程にあるピアが最も優先され、
・そうでなければ、最も多くのデータを供給するピアを優先し、
・上記状況がいずれも適用されない場合、上記の通り、任意に、又はトポロジー的情報に応じて、（複数の）ピアを選択する。
【００７３】
しかし、マルチキャストモードでは、受信器は、修復の開始を決定する時にそのピアとの交信を検証していない。受信器は、どのピアが最良のピアなのか帰納的に識別していない。
【００７４】
受信器は、データの喪失を検出すると、修復過程の開始を決定する必要がある。動作における重要な局面は、ピアへの要求を最適化することである。マルチキャスト伝送の特徴は、ある状況において、全ての顧客が同時にフラグメント又はブロックの終わりを検出するので、顧客がデータの喪失を検出する場合、ある程度同時に回復手順を始めようとすることにある。その結果、交信過程において、これらイベントによって引起される多量のメッセージが回避され、トラフィックのバーストによるネットワークの混雑というリスクを軽減する。複数の状況が以下のように考えられる。
【００７５】
１．受信器は、ＰＡＵＳＥメッセージによって示される、ブロック、フラグメント、又はファイルの終わりを待ち、例えばそのピアを介して修復を開始する。要求は、喪失セグメントのリスト又はセグメントの喪失範囲のリストを含むことができる。各受信器は、メタファイルにおける追加のフィールドにすることができる所定の窓に疑似乱数の時間遅延を起こす。故に、要求は、ネットワーク負荷を平滑化するよう、限られた時間で配信される。補足データが受信されると直ちに、各受信器は、ハッシュ値による情報を用いてフラグメントのインテグリティを照合する。
【００７６】
２．受信器は、ＰＡＵＳＥメッセージを待つことなく、孤立パケットの喪失又はパケット範囲の喪失を検出するとすぐに修復を始める。受信器は、下記に定義された要求メッセージ（ＲＥＱＵＥＳＴ）を送信する前に、上記のように時間遅延を起こす。
【００７７】
これら解決策のどれか一方の選択は、アプリケーション、エラー率、及びエラー分布を要因とする。
【００７８】
以下の表１は、紛失データ回復プロトコルで使用されるピア間の信号伝達に関する全ての命令を定義する。
【００７９】
【表１】
【００８０】
図６は、表１による信号伝達メッセージを用いたピアＡ、Ｂ、Ｃ間の交信セッションに対する一例を示す。
【００８１】
ピア間のダウンロードを体系化するための２つのストラテジがある。
【００８２】
・第１の手法は、ピア自体が盲目（blind）であるかを問合せる。これは、送信メッセージ数を節約し、低い損失率のネットワーク、及び紛失パケットを迅速に到達させる必要がない点で最適である。各顧客は、自分のピアによってパケットが受信されたか分からないので、顧客が望むデータが得られるまで連続的にピアを問合せる。
・第２の手法は、フラグメントが受信されるとすぐ、顧客が利用可能なフラグメントをピアに通知する。このため、以下の表２に定義される、２つの新規メッセージを導入する必要がある。
【００８３】
【表２】
【００８４】
フラグメントが揃うと、顧客は、一部データがマルチキャストソースから来ない場合、Merkleハッシュ木を用いてフラグメントのインテグリティを照合する必要がある。その後マルチキャストソースは、その一部データをピアに供給することができる。
【００８５】
マルチキャスト（ＵＤＰ／ＩＰ）伝送は、通常一定である、ソースの出力ビットレートを調節する簡単な方法がないので、ネットワークの混雑にかなり敏感である。従って、ネットワークにおける任意の位置での再伝送がマルチキャストパケットの伝送を妨害しないことが重要である。この反応は、ＴＣＰトラフィックがＵＤＰの余地を残すので、ＩＰネットワークでは普通である。ＵＤＰビットレートがリンク上で許可されている最大ビットレートにかなり近い場合、唯一のリスクは修復が遅れることである。
【００８６】
再伝送が混雑を引起す場合、その後修復過程を開始するために伝送の終わりを待つ必要がある。上記手段は、不変である。
【００８７】
また、本発明は、データの前に受信器へ伝送されるMerkleハッシュ木のルートを提供する。
【００８８】
このルートは、任意の手段、好ましくは確実な手段によって伝送されうる。特に、データソースは、データを前記電気通信網へ確実にマルチブロードキャストする前に、受信器へ前記Merkleハッシュ木のルートを伝送するよう適合される。他の伝送手段は、ウェブページ又は電子メール等が当然に想定可能である。
【００８９】
同様に、本発明によると、前記データソースは、前記ルートの伝送からデータの伝送までの間、前記ルートより低いレベルのハッシュ値を受信器へ伝送するよう適合される。
【００９０】
また、本発明は、電気通信網を介して前記データを複数の受信器へマルチブロードキャストするデータソースに関し、特にデータソースが前記電気通信網へデータを確実にマルチブロードキャストする前に、データに対するMerkleハッシュ木のルートを受信器へ伝送できる点に注目すべきである。
【００９１】
また、前記データソースは、前記ルートの伝送から前記データの伝送までの間、前記ルートより低いレベルのハッシュ値を受信器に伝送できる。
【００９２】
また、本発明は、データのソースと前記データに対する複数の受信器との間で電気通信網を介してマルチブロードキャストデータを伝送する信頼性を改善するための、システムの監視サーバに関し、特に前記監視サーバは、少なくとも１つの他の受信器を含むリストを各受信器へ供給でき、前記リストは、前記受信器と前記他の受信器との間に確実なピアツーピアの接続を設定するのに使用されるのが特筆すべき点である。また、リストは、データを有する参照ソースを含む。
【００９３】
また、本発明は、データのソースと前記データに対する複数の受信器との間で電気通信網を介してマルチブロードキャストデータを伝送する信頼性を改善するための、システムの参照ソースに関し、特に前記参照ソースは、前記データを有し、少なくとも一つの受信器に対して確実なピアツーピアの接続を設定するよう適合されるのが特筆すべき点である。
【００９４】
また、本発明は、データのソースと前記データに対する複数の受信器との間で電気通信網を介してマルチブロードキャストデータを伝送する信頼性を改善するための、システムの受信器に関し、特に前記受信器は、ピアツーピアの接続中に前記他の受信器が供給したデータのインテグリティを照合するための手段を含むことが特筆すべき点である。
【００９５】
最後に、本発明は、データのソースと前記データに対する複数の受信器（２０１、２０２、．．．、２０Ｎ）との間で電気通信網を介してマルチブロードキャストデータを伝送する信頼性を改善するためのシステムに関し、前記システムは、少なくとも１つの他の受信器を含むリストを各受信器に提供するよう適合される監視サーバを含み、前記受信器は、確実なピアツーピアの接続を介して前記他の受信器から紛失データを受信できる。
【００９６】
また、システムは、参照ソースを含み、参照ソースは、前記データを有し、前記監視サーバが供給した少なくとも一つのリストに現れる。
【００９７】
システムでは、各受信器は、ピアツーピアの接続中に前記他の受信器が供給したデータのインテグリティを照合するための手段を含む。
【００９８】
システムでは、前記照合手段は、少なくとも一つの他の受信器から受信したデータのフラグメントに対するハッシュ値を計算するための手段と、前記データソースから受信した前記フラグメントに対するハッシュ値と前記計算したハッシュ値とを比較するための手段とを含む。
【００９９】
システムでは、各受信器は、ピアツーピアの接続中に前記他の受信器が供給したハッシュ値のインテグリティを照合するための手段を含む。
【０１００】
システムでは、前記ハッシュ値インテグリティ照合手段は、Merkleハッシュ木を用いる。
【０１０１】
システムでは、Merkleハッシュ木のルートは、前記データの伝送前に前記受信器に伝送される。
【０１０２】
システムでは、データソースは、前記電気通信網を介して前記データを確実にマルチブロードキャストする前に前記Merkleハッシュ木のルートを前記受信器に伝送することができる。
【０１０３】
システムでは、データソースは、前記ルートの伝送から前記データの伝送までに前記ルートより低いレベルのハッシュ値を前記受信器に伝送することができる。
【０１０４】
システムでは、確実なピアツーピアの接続がＴＣＰ接続を用いて設定される。
【図面の簡単な説明】
【０１０５】
【図１】図１は、マルチキャストデータ伝送の信頼性を改善するための、本発明のシステムに関する図である。
【図２】図２は、本発明で用いるMerkleハッシュ木を示す。
【図３】図３は、マルチキャストソースから受信器へデータを伝送するパケットフォーマットを示す。
【図４】図４は、マルチキャストソースによって受信器へ伝送されるハッシュ木の例を与える。
【図５】図５は、マルチキャストソースによって受信器へ伝送されるデータパケットの例を与える。
【図６】図６は、受信器と２つの受信器ピアとの間におけるデータ回復セッションの図である。
【符号の説明】
【０１０６】
１０ マルチキャストソース
２０ 顧客
３０ 監視サーバ
４０ Ｐ２Ｐソース
【特許請求の範囲】
【請求項１】
データのソース（１０）と前記データに対する複数の顧客受信器（２０１、２０２、．．．、２０Ｎ）との間で電気通信網（１）を介してマルチブロードキャストデータを伝送する信頼性を改善するためのシステムであって、
前記システムは、少なくとも一つの他の受信器からなるリストを各顧客受信器に提供するよう適合される監視サーバ（３０）を含み、
前記顧客受信器は、確実なピアツーピアの接続を介して前記他の顧客受信器から紛失データを回復するよう適合されることを特徴とするシステム。
【請求項２】
電気通信網（１）を介してデータに対する複数の顧客受信器（２０１、２０２、．．．、２０Ｎ）に前記データをマルチブロードキャストするソースであって、
前記データのソース（１０）は、前記電気通信網を介して確実なマルチブロードキャストによって前記データに対するMerkleハッシュ木のルートハッシュ値ＨＲを、前記データを伝送する前に前記顧客受信器に伝送するよう適合され、
前記データのソース（１０）は、前記ルートハッシュ値の伝送から前記データの伝送までに、前記ルートハッシュ値ＨＲより低いレベルのハッシュ値を顧客受信器に伝送するよう適合され、
顧客受信器は、確実なピアツーピアの接続を介して他の顧客受信器から紛失データを受信するよう適合されることを特徴とするソース。
【請求項３】
データのソース（１０）と前記データに対する複数の顧客受信器（２０１、２０２、．．．、２０Ｎ）との間で電気通信網（１）を介してマルチキャストデータを伝送する信頼性を改善するためのシステムの監視サーバであって、
前記監視サーバ（３０）は、少なくとも一つの他の顧客受信器からなるリストを各顧客受信器に提供するよう適合され、
前記リストは、前記顧客受信器と前記他の顧客受信器との間に確実なピアツーピアの接続を確立する意図があることを特徴とするサーバ。
【請求項４】
データのソース（１０）と前記データに対する複数の顧客受信器（２０１、２０２、．．．、２０Ｎ）との間で電気通信網（１）を介してマルチキャストデータを伝送する信頼性を改善するためのシステムの参照ソースであって、
前記参照ソース（４０）は、前記データを有し、少なくとも一つの顧客受信器に確実なピアツーピアの接続を確立するよう適合されることを特徴とするソース。
【請求項５】
データのソース（１０）と前記データに対する複数の顧客受信器（２０１、２０２、．．．、２０Ｎ）との間で電気通信網を介してマルチキャストデータを伝送する信頼性を改善するためのシステムの顧客受信器であって、
前記顧客受信器（２０１、２０２、．．．、２０Ｎ）は、ピアツーピアの接続中に前記他の顧客受信器によって提供されるデータのインテグリティを照合するための手段を具備することを特徴とする受信器。
【請求項６】
前記照合手段は、少なくとも一つの他の顧客受信器から受信したデータのフラグメントに対するハッシュ値（ＨＳ１１、．．．）を計算する手段と、
前記データのソース（１０）から受信した前記フラグメントに対するハッシュ値と前記計算したハッシュ値とを比較する手段と
を具備することを特徴とする請求項５に記載の顧客受信器。
【請求項７】
前記受信器は、ピアツーピアの接続中に前記他の顧客受信器によって提供されるハッシュ値のインテグリティを照合する手段を含むことを特徴とする請求項６に記載の顧客受信器。
【請求項８】
前記ハッシュ値のインテグリティを照合する手段は、Merkleハッシュ木を用いることを特徴とする請求項７に記載の顧客受信器。
【請求項９】
ソースと複数の顧客受信器（２０１、２０２、．．．、２０Ｎ）との間で電気通信網を介してマルチキャストデータを伝送する方法であって、
確実なピアツーピアの接続を介して一方の顧客受信器からもう一方の顧客受信器に紛失データを伝送する過程を含むことを特徴とする方法。
【請求項１０】
ソースと複数の顧客受信器（２０１、２０２、．．．、２０Ｎ）との間で電気通信網を介してマルチキャストされるデータを受信する方法であって、
確実なピアツーピアの接続を介して少なくとも一方の顧客受信器から紛失データをもう一方の顧客受信器が受信する過程を含むことを特徴とする方法。
【請求項１１】
コンピュータの内部メモリに読み込めるデータ媒体上のコンピュータプログラムであって、
請求項９に記載の方法からなる段階を実行するコード部分を具備することを特徴とするプログラム。
【請求項１２】
コンピュータの内部メモリに読み込めるデータ媒体上のコンピュータプログラムであって、
請求項１０に記載の方法からなる段階を実行するコード部分を具備することを特徴とするプログラム。
【請求項１】
データのソース（１０）と前記データに対する複数の顧客受信器（２０１、２０２、．．．、２０Ｎ）との間で電気通信網（１）を介してマルチブロードキャストデータを伝送する信頼性を改善するためのシステムであって、
前記システムは、少なくとも一つの他の受信器からなるリストを各顧客受信器に提供するよう適合される監視サーバ（３０）を含み、
前記顧客受信器は、確実なピアツーピアの接続を介して前記他の顧客受信器から紛失データを回復するよう適合されることを特徴とするシステム。
【請求項２】
電気通信網（１）を介してデータに対する複数の顧客受信器（２０１、２０２、．．．、２０Ｎ）に前記データをマルチブロードキャストするソースであって、
前記データのソース（１０）は、前記電気通信網を介して確実なマルチブロードキャストによって前記データに対するMerkleハッシュ木のルートハッシュ値ＨＲを、前記データを伝送する前に前記顧客受信器に伝送するよう適合され、
前記データのソース（１０）は、前記ルートハッシュ値の伝送から前記データの伝送までに、前記ルートハッシュ値ＨＲより低いレベルのハッシュ値を顧客受信器に伝送するよう適合され、
顧客受信器は、確実なピアツーピアの接続を介して他の顧客受信器から紛失データを受信するよう適合されることを特徴とするソース。
【請求項３】
データのソース（１０）と前記データに対する複数の顧客受信器（２０１、２０２、．．．、２０Ｎ）との間で電気通信網（１）を介してマルチキャストデータを伝送する信頼性を改善するためのシステムの監視サーバであって、
前記監視サーバ（３０）は、少なくとも一つの他の顧客受信器からなるリストを各顧客受信器に提供するよう適合され、
前記リストは、前記顧客受信器と前記他の顧客受信器との間に確実なピアツーピアの接続を確立する意図があることを特徴とするサーバ。
【請求項４】
データのソース（１０）と前記データに対する複数の顧客受信器（２０１、２０２、．．．、２０Ｎ）との間で電気通信網（１）を介してマルチキャストデータを伝送する信頼性を改善するためのシステムの参照ソースであって、
前記参照ソース（４０）は、前記データを有し、少なくとも一つの顧客受信器に確実なピアツーピアの接続を確立するよう適合されることを特徴とするソース。
【請求項５】
データのソース（１０）と前記データに対する複数の顧客受信器（２０１、２０２、．．．、２０Ｎ）との間で電気通信網を介してマルチキャストデータを伝送する信頼性を改善するためのシステムの顧客受信器であって、
前記顧客受信器（２０１、２０２、．．．、２０Ｎ）は、ピアツーピアの接続中に前記他の顧客受信器によって提供されるデータのインテグリティを照合するための手段を具備することを特徴とする受信器。
【請求項６】
前記照合手段は、少なくとも一つの他の顧客受信器から受信したデータのフラグメントに対するハッシュ値（ＨＳ１１、．．．）を計算する手段と、
前記データのソース（１０）から受信した前記フラグメントに対するハッシュ値と前記計算したハッシュ値とを比較する手段と
を具備することを特徴とする請求項５に記載の顧客受信器。
【請求項７】
前記受信器は、ピアツーピアの接続中に前記他の顧客受信器によって提供されるハッシュ値のインテグリティを照合する手段を含むことを特徴とする請求項６に記載の顧客受信器。
【請求項８】
前記ハッシュ値のインテグリティを照合する手段は、Merkleハッシュ木を用いることを特徴とする請求項７に記載の顧客受信器。
【請求項９】
ソースと複数の顧客受信器（２０１、２０２、．．．、２０Ｎ）との間で電気通信網を介してマルチキャストデータを伝送する方法であって、
確実なピアツーピアの接続を介して一方の顧客受信器からもう一方の顧客受信器に紛失データを伝送する過程を含むことを特徴とする方法。
【請求項１０】
ソースと複数の顧客受信器（２０１、２０２、．．．、２０Ｎ）との間で電気通信網を介してマルチキャストされるデータを受信する方法であって、
確実なピアツーピアの接続を介して少なくとも一方の顧客受信器から紛失データをもう一方の顧客受信器が受信する過程を含むことを特徴とする方法。
【請求項１１】
コンピュータの内部メモリに読み込めるデータ媒体上のコンピュータプログラムであって、
請求項９に記載の方法からなる段階を実行するコード部分を具備することを特徴とするプログラム。
【請求項１２】
コンピュータの内部メモリに読み込めるデータ媒体上のコンピュータプログラムであって、
請求項１０に記載の方法からなる段階を実行するコード部分を具備することを特徴とするプログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図２】
【図３】
【図４】
【図５】
【図６】
【公表番号】特表２００９−５２４９６１（Ｐ２００９−５２４９６１Ａ）
【公表日】平成２１年７月２日（２００９．７．２）
【国際特許分類】
【出願番号】特願２００８−５５１８３７（Ｐ２００８−５５１８３７）
【出願日】平成１９年１月２４日（２００７．１．２４）
【国際出願番号】ＰＣＴ／ＦＲ２００７／０５０６８５
【国際公開番号】ＷＯ２００７／０８５７６３
【国際公開日】平成１９年８月２日（２００７．８．２）
【出願人】（５９１０３４１５４）フランス テレコム (290)
【Ｆターム（参考）】
【公表日】平成２１年７月２日（２００９．７．２）
【国際特許分類】
【出願日】平成１９年１月２４日（２００７．１．２４）
【国際出願番号】ＰＣＴ／ＦＲ２００７／０５０６８５
【国際公開番号】ＷＯ２００７／０８５７６３
【国際公開日】平成１９年８月２日（２００７．８．２）
【出願人】（５９１０３４１５４）フランス テレコム (290)
【Ｆターム（参考）】
[ Back to top ]