JP2006025408A - ピアツーピアコンピュータネットワーク内の効率的な一対多コンテンツ配信 - Google Patents

Abstract

【課題】 ネットワークの完全な潜在的スループットが達成されるようにピアツーピアネットワーク上でコンテンツを配信する。
【解決手段】 このコンテンツ配信方法では、配信されるコンテンツを多数の小さなブロックに分割する。コンテンツブロックのそれぞれを、１つのノードに割り当てて、それぞれコンテンツ要求ノード、非コンテンツ要求ノード、または送信元ノードとすることができる。コンテンツは、ノードのキャパシティに基づいて割り当てられ、大きなキャパシティを持つノードは多数のコンテンツブロックを割り当てられ、小さなキャパシティを持つノードは少ないコンテンツブロックを割り当てられる。キャパシティは、一般的に、ノードのアップロード帯域幅として定義される。再配信キューは、配信のスループットを制御するために採用される。
【選択図】 図６

Description

本発明は、一般的に、コンピュータネットワーキングに関し、より詳細には、配送スループットが最大化されるようにピアツーピアネットワークでコンテンツを配信する効率のよい方法およびシステムに関する。

コンピュータネットワーク内の１台のコンピュータがネットワーク上の他の複数のコンピュータにコンテンツを送信する、一対多のコンテンツ配信を必要とするアプリケーションが多数ある。このようなアプリケーションの一実施例として、ソフトウェア配信、インターネットＴＶ／ビデオストリーミング、ビデオ会議、パーソナルメディアの配信、ピアツーピア（Ｐ２Ｐ）Ｗｅｂコンテンツの複製(duplication)がある。Ｐ２Ｐネットワークとは、それぞれのコンピュータが同等の能力および果たすべき役割を有しているネットワークの一種である。

図１は、一対多コンテンツ配信の問題を例示するブロック図である。ネットワーク１００は、配信されるコンテンツを保持する送信元ノードｓ、およびそれぞれコンテンツのコピーを要求する場合もしない場合もある複数のピアノードｔ_ｉ、ｉ＝１，２，．．．，Ｎを含む。送信元ノードとピアノードとは、両方とも、エンドユーザノードである。これらは、通常、ＡＤＳＬ（Asymmetric Digital Subscriber Line）、ケーブルモデム、キャンパス、または企業ネットワークリンクを使用し、ＩＳＰ（Internet Service Provider）を通じて、インターネットに接続されているコンピュータである。図１に示されている設定で送信元ノードがコンテンツを配信する最も単純なアプローチにより、送信元ノードは、コンテンツを直接、送信先ノードに送信することができる。単純ではあるが、コンテンツ配信のスループットは、送信元ノードのアップロード帯域幅に制約され、通常は、かなり制限されている。

図１に示されているようなコンテンツ配信問題を解消する１つのネットワークレベルの解決策がＩＰ（Internet Protocol）マルチキャストである。ＩＰマルチキャストでは、送信元から送信された単一パケットは、送信元をルートとする配信ツリーに沿って配置されているルータに複製される。この方法では、コンテンツは、受信機の数に関係なく、受信機に配送される。ＩＰマルチキャストは効率的な解決策であるが、ドメイン間の経路選択プロトコル、ＩＳＰ、ビジネスモデル、配信ツリーに沿った輻輳制御などの課題および問題があるため、現実世界ではその普及は遅々として進んでいない。ネットワークレベルのマルチキャストサービスを配備することに対して、こうした問題があるため、今日のインターネットのトラフィックの大部分は、２台のコンピュータが直接やり取りする、ユニキャストベースである。

ネットワークレベルの解決策は、こうした理由があるため一般的には実現可能でないので、ルータの代わりにＰ２Ｐコンピュータが送信元からコンテンツを配信できるようにする、さまざまな異なるアプローチがとられた。一般に、最も有望なアプローチは、ＡＬＭ（Application-Level Multicast）である。ＡＬＭでは、マルチキャスト配信ツリーが形成され、既存のネットワーク上にオーバーレイされる。マルチキャストプロトコルを使用する代わりに、配信ツリー内のそれぞれのピアコンピュータは、ユニキャストプロトコルを使用して、パケット複製(replication)、メンバシップ管理、およびオーバーレイされたネットワーク上のコンテンツ配送をはじめとする、すべてのマルチキャスト関連機能を実装する。

ＡＬＭシステムの実施例として、スキャッターキャスト（Scattercast：例えば、非特許文献１参照）およびオーバーキャスト（Overcast：例えば、非特許文献２参照）がある。スキャッターキャストおよびオーバーキャストでは、単一ツリーを使用してコンテンツを配信する。

図２は、スキャッターキャストおよびオーバーキャストで使用されているような、単一配信ツリー２００を使用するコンテンツ配信手法を示すブロック図である。この構成では、送信元ノードｓは、データをノードｔ_２およびｔ_３に転送するノードｔ_１にデータを送信する。ＡＬＭ発信ツリー２００では、中間ノードｔ_１のアップロード帯域幅を利用するが、リーフノードｔ_２およびｔ_３のアップロード帯域幅は利用されない。送信元ノードにそのコンテンツの他のすべてのクライアントへの直接送信を行わせることと比べると、図２に示されている配信ツリーアプローチでは、送信元のネットワーク負荷が軽減され、そのため、コンテンツ配信の効率がよくなる。

しかし、スキャッターキャストおよびオーバーキャストの問題の１つは、コンテンツ配信の不効率さにある。特に、配信ツリーでは、中間ノードはコンテンツを再配信するが、リーフノードはコンテンツを受信するだけである。つまり、リーフノードのアップロード帯域幅は、コンテンツ配信に利用されないということである。

このような不効率さを改善する試みがいくつかなされている。これらの手法としては、ＣｏｏｐＮｅｔ（例えば、非特許文献３、４参照）と呼ばれる手法およびＳｐｌｉｔＳｔｒｅａｍ（例えば、非特許文献５参照）と呼ばれる手法がある。これらの手法はそれぞれ、コンテンツを複数のストライプに分割し、それらのストライプを、互いに素である内部ノードを持つ別々のマルチキャストツリーに分配する。ピアコンピュータは、マルチキャストツリーの１つに含まれる内部ノードとすることができ、またコンテンツの転送に関わることができる。

ＣｏｏｐＮｅｔは、集中ツリー管理方式を使用するが、ＳｐｌｉｔＳｔｒｅａｍは、配信ツリーを保持するためペイストリー（Pastry：例えば、非特許文献６参照）に依存する。ＣｏｏｐＮｅｔでは、さらに、多重記述符号化（ＭＤＣ：multiple description coding）および前方誤り訂正（ＦＥＣ：Forward Error Correction）を使用して、パケット損失およびノード障害を防止する。

図３は、ＣｏｏｐＮｅｔおよびＳｐｌｉｔＳｔｒｅａｍで使用されているような、２アプリケーションレベルのマルチキャストツリー構成３００を例示するブロック図である。コンテンツは、２つの等しいストライプに分割される。第１のストライプ３１０は、ストライプをノードｔ_２およびｔ_３に転送するノードｔ_１に送られる。第２のストライプ３２０は、ストライプをノードｔ_１およびｔ_３に転送するノードｔ_２に送られる。図３では、第１のストライプの配信経路は実線で示されており、第２のストライプの配信経路は破線で示されていることに留意されたい。これは、それらのリンクで配信されるコンテンツが異なることを意味している。この構成の問題の１つは、システム３００がノードｔ_１およびｔ_２のアップロード帯域幅を使用するが、ノードｔ_３のアップロード帯域幅を使用できない、従って効率が低下するという点である。

このような不効率を改善しようと試みた手法としては他に、に書かれたＦａｓｔＲｅｐｌｉｃａ（例えば、非特許文献７参照）およびＢｕｌｌｅｔ（例えば、非特許文献８参照）と呼ばれる手法がある。この両方の手法では、大きなファイルを効率よく、しかも高い信頼性を保持しながら複製するという問題を評価した。ｎ個のノードがあった場合、ＦａｓｔＲｅｐｌｉｃａは、最初に、ファイルをサイズの等しいｎ個のサブファイルに分割する。その後、それぞれのサブファイルは、グループ内の異なるピアに転送され、その後、複製され、他のピアに転送される。Ｂｕｌｌｅｔにおいて、ピアノードは、オーバーレイツリーにまとめられる。それぞれのノードは、親ノードから受け取ったコンテンツを互いに素のブロックの集合に分割し、それぞれの集合を異なる子ノードに送信する。その後、子ノードは、欠損ブロックおよび欠損ブロックを保持しているノードを発見し、欠損ブロックを回復する要求を送信する。

ＦａｓｔＲｅｐｌｉｃａ手法をよく調べると、この手法は、ファイルダウンロード用に特に設計されていることがわかるであろう。ＮノードのＰ２Ｐネットワークにおいて、ＦａｓｔＲｅｐｌｉｃａは、中間次数Ｎ−１のＮ個の高さ（height）２のマルチキャストツリーを持つファイルを配信する。図４は、３つのピアノードのＦａｓｔＲｅｐｌｉｃａ構成例４００を示すブロック図である。ＦａｓｔＲｅｐｌｉｃａは、配信ステップと収集ステップの２つのステップでファイルを配信する。配信ステップでは、ファイルは３つのサブファイルに分割され、ノードｔ_１、ｔ_２、およびｔ_３にそれぞれ送信される（実線、破線、および点線に沿って）。特に、３つのサブファイルは、第１のストライプ４１０、第２のストライプ４２０、および第３のストライプ４３０に沿って送信される。配信ステップの後、収集ステップが実行される。それぞれピアノードは、そのサブファイルを他のピアノードに転送する。図４に示されているように、ピアノードのそれぞれは、ＦａｓｔＲｅｐｌｉｃａのコンテンツ配信に関わる。

実際のＰ２Ｐコンテンツ配信システムは、ＢｉｔＴｏｒｒｅｎｔ（例えば、非特許文献９、１０参照）と呼ばれる手法を使用して実装されている。ＢｉｔＴｏｒｒｅｎｔは、インセンティブの共有を含み、従って、アップロードするコンテンツが多いほど、ピアからダウンロードできるコンテンツも多いため、ピアは進んでコンテンツを配信する。これらは、アプリケーションレベルのマルチキャストに対する多くの最近のスキームのごく少数の例にすぎない。

Y. Chawathe "Scattercast: an architecture for internet broadcast distribution as an Infrastructure service", a PhD thesis for the University of California, Berkeley, August 2000 J. Jannotti, D. K. Gifford, K. L. Johnson, M. F. Kaashoek, and J. W. O'Toole Jr. "Overcast: reliable multicasting with an overlay network" in Proc. of the Fourth Symposium on Operating System Design and Implementation (OSDI), October 2000 V. N. Padmanabhan and K. Sripanidkulchai "The Case for Cooperative Networking", in Proc. of the First International Workshop on Peer-to-Peer Systems (IPTPS), Cambridge, MA, USA, March 2002 V. N. Padmanabhan, H. J. Wang, and P. A. Chou, "Resilient Peer-to-Peer Streaming," in Proc. IEEE International Conference on Network Protocols (ICNP), Atlanta, GA, USA, November 2003 M. Castro, P. Druschel, A-M. Kermarrec, A. Nandi, A. Rowstron and A. Singh "SplitStream: High-bandwidth content distribution in a cooperative environment", In Proc. of the International Workshop on Peer-to-Peer Systems, Berkeley, CA, February, 2003 A. Rowstron and P. Druschel "Pastry: scalable, distributed object location and routing for large-scale peer-to-peer systems" in Proc. of IFIP/ACM International Conference on Distributed Systems Platforms (Middleware), Heidelberg, Germany, pages 329-350, November, 2001 L. Cherkasova and J. Lee "FastReplica: Efficient Large File Distribution within Content Delivery Networks" in Proc. of the 4-th USENIX Symposium on Internet Technologies and Systems, Seattle, Washington, March 26-28, 2003 D. Kostic, A. Rodriguez, J, Albrecht, A. Vahdat "Bullet: High Bandwidth Data Dissemination Using an Overlay Mesh" in Proc. 19th ACM Symposium on Operating Systems Principles, October 19-22, 2003, the Sagamore, New York B. Cohen 的ncentives build robustness in BitTorrent http://bitconjurer.org/BitTorrent/bittorrentecon.pdf

上記のＡＬＭ配信戦略は、送信元からピアへコンテンツを直接送信するよりも効率が高いが、ネットワーク内の最も効率的なコンテンツ配信を実現することはできない。特に、上記の手法はどれも、ピアノード間の帯域幅の違いを十分に考慮していない。それぞれの手法は、さらに、コンテンツを配信するためにすべてのピアノードの帯域幅のリソースを完全に従事させることもできない。

上記の一対多のコンテンツ配信アプローチはすべて、好適なネットワークトポロジを確立することによりピアノードの能力（ピアノードのアップロード／ダウンロード帯域幅）に適合する。高い帯域幅を持つノードは、配信ネットワークの中心に置かれ、さらに多くのコンテンツ配信を受け持つ。ネットワークトポロジが確立された後、コンテンツは、確立されたネットワークを通じて固定ストライプで配信される。これらの配信戦略の問題は、配信ネットワークが、ネットワーク状態（特定のノード／リンクの輻輳など）の変化に合わせられるほど柔軟でないという点である。これは、コンテンツ配信の効率を著しく低減させる場合がある。従って、必要なのは、コンピュータネットワークから最大の潜在能力を引き出すために可能な最も効率のよい方法でコンテンツを配信する一対多コンテンツ配信手法である。

本明細書で開示されている発明は、配送スループットが最大化されるようにピアツーピアネットワーク上でコンテンツを効率よく配信するコンテンツ配信方法およびシステムを含む。このコンテンツ配信方法およびシステムは、現行の一対多配信手法の上述の欠点を克服するものである。既存のアプローチとは対照的に、このコンテンツ配信方法およびシステムは、コンテンツを配信するために可能な限り多くのノードを従事させ、それぞれのノードの利用可能なアップロード帯域幅を完全利用することによりそのコンテンツに対する可能な最大のスループットを達成する。さらに、このコンテンツ配信方法およびシステムは、優勢なネットワーク状態の下で最大スループットに合わせてコンテンツ送信速度を動的に調整することができる。

このコンテンツ配信方法およびシステムは、少なくとも３つの異なる特徴を持つ。第１に、コンテンツ配信方法およびシステムは、配信するコンテンツを、それがファイルであろうと媒体ストリームであろうと、多数の小さなブロックに分割する。特定の１つのノードにより再配信されるブロックの個数は、従って、そのノードのリソース（アップロード帯域幅など）に比例すると考えられる。大きなアップロード帯域幅を持つノードほど、多くのブロックを再配信することができ、小さなアップロード帯域幅を持つノードほど、少ないブロックを再配信することができる。第２に、このコンテンツ配信方法およびシステムでは、それぞれのコンテンツブロックは、再配送のため単一ノードに割り当てられる。再配送を受け持つノードは、コンテンツ要求ピアノード、非コンテンツ要求ピアノードとすることができ、さらには送信元ノード自体であってもよい。第３に、ノード間で再配信キューを使用することにより、このコンテンツ配信方法およびシステムは、ネットワーク状態の動的変化を効果的に処理することができる。これにより、コンテンツ配信方法およびシステムで、進行中にネットワーク内のそれぞれのノードのアップロード帯域幅の変動、パケット損失、およびパケットジッタに効果的に対処することができる。

このコンテンツ配信方法は、コンテンツを複数のブロックに分割し、複数のブロックのそれぞれをノードのキャパシティに比例してノードに割り当てて、キャパシティの大きなノードに多くのブロックを割り当て、キャパシティの小さなノードに少ないブロックを割り当てるようにする。ノードのキャパシティは、ノードの帯域幅、またはノードのアップロード帯域幅に関して定義することができる。代替として、ノードのキャパシティは、他の尺度、例えば、限界遅延、キャパシティからパケット損失を引いた値などを使用して定義することができる。ネットワークは、ピアツーピアコンピュータネットワークとすることができる。

コンテンツブロックのサイズは、コンピュータネットワークのＭＴＵ（Maximum Transmission Unit）よりも小さくすることができ、場合によっては、約１キロバイト（ＫＢ）である。コンテンツブロックサイズは、配信の精度とブロックを識別するのに要するオーバーヘッドとの間の妥協で決まる。

この方法では、ノードのキャパシティの変化に基づいてブロックの動的再配信を有効にするため帯域幅制御戦略を使用する。帯域幅制御戦略では、ネットワーク内のノードのそれぞれの間に再配信キューを採用する。キューは、ＴＣＰ（Transport Control Protocol）の送信および受信バッファとすることができるが、またはＵＤＰ（User Datagram Protocol）の上に実装されたアプリケーションバッファとすることもできる。ＵＤＰは、ＴＣＰと異なり、バッファを持たない。つまり、ＵＤＰが使用される場合、ユーザは再配信キューとして使用される追加バッファを実装する必要がある。この方法は、さらに、ノード間の接続を含み、転送リンクがさらに配信されるべきコンテンツブロックを持つ接続として定義される。同様に、配送リンクは、さらに再配信されないコンテンツブロックを持つ接続として定義される。

本発明は、本発明の態様を例示する以下の図面および添付図面を参照することにより理解を深めることができる。他の特徴および利点は、本発明の原理を例により説明している、付属の図面とともに、以下の詳細な説明を読むと明らかになる。

そこで、全体として類似の参照番号が対応するパーツを表す図面を参照することにする。

本発明の以下の説明では、本発明の一部をなし、本発明を実施できる具体的実施形態が図示されている、付属の図面を参照する。本発明の範囲および精神から逸脱することなく他の実施形態を利用し、構造上の変更を加えることができることは理解されるであろう。

(Ｉ．はじめに)
ピアツーピア（Ｐ２Ｐ）コンピュータネットワークにおける現行の一対多配信手法は、送信元ノードからピアノードにコンテンツを直接送信するよりも効率がよいが、これらの手法だと、ネットワーク内で最も効率のよいコンテンツ配信を達成することはできない。さまざまな要因があるからである。要因の１つは、これらの現行の手法はいずれも、ピアノード間の帯域幅の違いを十分に説明することもそれに適合することもしないという点である。他の要因は、これらの手法はコンテンツを配信する際にネットワーク上のピアノードのすべての帯域幅能力を完全利用できないというものである。

本明細書で開示されているコンテンツ配信方法およびシステムは、特にピアツーピア（Ｐ２Ｐ）ネットワークにおいて、一対多コンテンツ配信のための新しいタイプの配送メカニズムである。従来の一対多コンテンツ配信アプローチと比較すると、本明細書で開示されているコンテンツ配信方法およびシステムでは、配信すべきコンテンツを多数の小さなブロックに分割する。このため、大きなキャパシティ（アップロード帯域幅など）を持つノードほど多くのブロックを再配信し、小さなキャパシティを持つノードほど少ないブロックを再配信することができる。それぞれのコンテンツブロックは、配信のため単一ノードに割り当てられ、受け持ちのノードは、コンテンツ要求ピアノード、非コンテンツ要求ピアノードとすることができ、さらには送信元ノードとすることもできる。

配信のスループットは、送信元ノードとピアノードとの間の再配信キューにより制御される。このコンテンツ配信方法およびシステムは、すべてのピアノードのアップロード帯域幅を完全利用し、それによって、配送スループットを最大化する。さらに、コンテンツ配信方法およびシステムは、単純であり、また柔軟性もある。これは、Ｐ２Ｐネットワーク内で、ファイル／ソフトウェアダウンロード、メディアストリーミング、および消去符号化ファイル配信（erasure coded file distribution）に適用することができる。

(ＩＩ．概要)
図５は、本明細書で開示されているコンテンツ配信システムおよび方法の実施例を示すブロック図である。図５は、単に、コンテンツ配信システムおよび方法を実装し、使用できるようにする複数の方法のうちの１つにすぎないことに留意されたい。

図５を参照すると、この実施例では、ピアツーピア（Ｐ２Ｐ）ネットワーク５００が示されている。ネットワーク５００は、１つの送信元ノードｓと４つのピアノードｔ_１、ｔ_２、ｔ_３、およびｔ_４を含む。ピアノードのうち、ノードｔ_１、ｔ_２、およびｔ_３は、送信元ノードｓにコンテンツのコピーを要求するので、これらのノードはコンテンツ要求ピアノードと呼ばれる。ノードｔ_４は、コンテンツのコピーを要求しないので、非コンテンツ要求ピアノードと呼ばれる。本明細書に開示されているコンテンツ配信システムおよび方法によれば、ピアノードｔ_４は、コンテンツを要求しなくても、そのアップロード帯域幅に関わり、コンテンツを他のピアノードに配布するのを手助けすることに留意されたい。

配信されるコンテンツは、送信元ノードｓに格納され、多数の小さなブロックに分割または分離される。コンテンツは、ファイルまたはメディアストリームを含むことができる。次に、それぞれのブロックは、再配送のためノードの１つに割り当てられる。それぞれのブロックは、単一のノードにのみ割り当てられる。図５に示されているブロック１、２、３、および４など、ブロックが再配信のためコンテンツ受信ピアノードｔ_１、ｔ_２、およびｔ_３に割り当てられる場合、そのブロックは、最初に、送信元ノードｓにより、割り当て済みのピアノード（または再配送を受け持つピアノード）に送信される。割り当てられたピアノードは、次に、ブロックを他の２つのピアノードに転送する。例えば、図５に示されているブロック１がピアノードｔ_１に割り当てられた場合、ブロック１は、送信元ノードｓにより、ピアノードｔ_１に送信され、その後、ピアノードがブロック１をピアノードｔ_２およびｔ_３に転送する。

図５に示されているブロック５、６、および７などのブロックが再配信のため非コンテンツ受信ピアノードｔ_４に割り当てられた場合、そのブロックは、最初に、送信元ノードｓにより、ピアノードｔ_４に送信される。次に、非コンテンツ受信ピアノードｔ_４は、そのブロックをネットワーク５００上の他の３つのピアノードｔ_１、ｔ_２、およびｔ_３に転送する。例えば、図５に示されているブロック５が非コンテンツ受信ピアノードｔ_４に割り当てられた場合、ブロック５は、送信元ノードｓにより、ピアノードｔ_４に送信され、ピアノードｔ_４はブロック５をピアノードｔ_１、ｔ_２、およびｔ_３に転送する。

送信元ノードｓは、さらに、ブロックを直接配信することを選択することもできる。例えば、図５に示されているように、ブロック８は、送信元ノードｓにより、コンテンツ要求ピアノードｔ_１、ｔ_２、およびｔ_３に配信される。この状況では、ブロック８は、送信元ノードｓにより、直接、コンテンツ要求ピアノードｔ_１、ｔ_２、およびｔ_３に送信される。

本明細書で開示されているコンテンツ配信システムおよび方法では、ネットワーク５００内のノードの各ペア間に再配信キューを設定する。以下で詳しく説明するが、これらの再配信キューを使用すると、コンテンツ配信システムおよび方法で、帯域幅の変更、パケット損失、およびパケットジッタなどのネットワーク５００の状態の動的変化を取り扱うことができる。再配信キューは、図５に、実線と破線とで示されている。ノード間の実線は、転送リンクを示すが、ノード間の破線は、配送リンクを示す。転送リンクは、再配信される接続搬送ブロックである。配送リンクは、それ以上再配信されないブロックを搬送する接続である。

（ＩＩＩ．オペレーションの概要）
図５に示されているコンテンツ配信システムおよび方法のオペレーションについて説明する。図６は、図５に示されているコンテンツ配信システムおよび方法の一般的なオペレーションを例示する一般的な流れ図である。コンテンツ配信方法は、配信するコンテンツを入力する（ボックス６００）ことから始まる。上述のように、このコンテンツは、ファイルまたはメディアストリームを含むことができる。次に、コンテンツは、複数のさらに小さなブロックに分割または分離される（ボックス６１０）。コンテンツを小さなブロックに分割すると、異なるノードで異なる数のブロックを再配信することができる。従って、特定の１つのノードにより再配信されるブロックの個数は、そのノードのキャパシティ（アップロード帯域幅など）に比例するようにできる。例えば、大きなアップロード帯域幅を持つノードほど、多くのブロックを再配信するが、小さなアップロード帯域幅を持つノードほど少ないブロックを再配信することができる。

次に、コンテンツの各ブロックは、再配送のため単一ノードに割り当てられる（ボックス６２０）。上述のように、再配送を受け持つノードは、コンテンツ要求ピアノード、非コンテンツ要求ピアノードとすることができ、さらには送信元ノード自体であってもよい。次に、ネットワークの動的変化を扱うために、ノード間の再配信キューが使用される（ボックス６３０）。このコンテンツ配信方法では、ノード間で再配信キューを使用することにより、ネットワーク状態の動的変化を効果的に処理することができる。例えば、ネットワーク内の各ノードのアップロード帯域幅の変動、パケット損失、およびパケットジッタなどのネットワークの変化は、実行中に処理されるため、ノードにキャパシティ低下が生じると、それに比例して再配送のためそのノードに割り当てられたコンテンツブロックの個数が減少する。

（ＩＶ．オペレーションの詳細および動作例）
次に図６に示されているコンテンツ配信方法のオペレーションの詳細について説明する。コンテンツ配信方法の基本配信フレームワークは以下のとおりである。配信されるコンテンツは、ブロックＢ_ｊ、ｊ＝１，２，．．．，Ｍに分割される。各ブロックＢ_ｊについて、コンテンツブロックをピアノードの残りに配信するために１つの一意的なノードが割り当てられる。この一意的なノードは、そのブロックの再配信を受け持つノードである。ブロックＢ_ｊを再配信することを受け持つノードは、ピアノードｔ_ｊであることが多い。このような場合、送信元ノードは、ブロックＢ_ｊの１つのコピーをピアノードｔ_ｊに送信し、その後、そのブロックをピアノードの残りに送信することによりブロックＢ_ｊを再配信する。しかし、送信元ノードの帯域幅リソースが十分あれば、ブロックＢ_ｊを再配信することを受け持つノードは、送信元ノードｓ自体であってもよい。その場合、送信元ノードは、ブロックＢ_ｊの１つのコピーをそれぞれのピアノードｔ_ｊに直接送信する。

（コンテンツ分割）
図６に関して上で述べたように、このコンテンツ配信方法では、最初に、配信すべきコンテンツを多数の小さなブロックに分割する。そのため、１つのノードにより再配信されるブロックの個数は、そのノードのキャパシティ（またはリソース）に比例しうる。好ましい実装では、このキャパシティは、ノードのアップロード帯域幅に関して評価または定義される。アップロード帯域幅の大きいノードほど、再配信のため多くのコンテンツブロックが与えられる可能性がある。同様に、アップロード帯域幅の小さいノードほど、再配信のため少数のコンテンツブロックが与えられる可能性がある。

このコンテンツ配信方法では、配信のためコンテンツを多数の小さなブロックに分割する。コンテンツブロックのサイズは、配信の精度とブロックを識別するのに要するオーバーヘッドとの間の妥協で決まる。テストした実装では、コンテンツブロックの好ましいサイズは、ネットワークのＭＴＵよりもわずかに小さい。このため、コンテンツブロックは、ネットワーク上で単一パケットとして送信することができる。テストされた実装では、コンテンツブロックサイズは、１キロバイト（ＫＢ）に設定された。

（配信経路）
コンテンツ配信中、それぞれのコンテンツブロックは再配信のため特定のノードに割り当てられる。ピアノードに割り当てられるコンテンツブロックの個数は、テスト実装では、アップロード帯域幅により評価されるそれのキャパシティに比例する。アップロード帯域幅が使用されるのは、ネットワークに対するピアノードの関与に関して、問題になるのがピアノードのアップロード帯域幅だからである。従って、Ｐ２Ｐネットワークでコンテンツを効率よく配信するためには、コンテンツ配信方法で、できる限りピアノードのアップロード帯域幅を使用すべきである。

さらに、コンテンツブロック配信のために、配信速度を左右する一次パラメータは、ネットワークリンクのスループットであることに留意されたい。クライアントがファイルを受信する際の送り元の複数のサーバを選択することができる場合、それら２つのうちで最高速のネットワークスループットを実現するサーバを選択すべきである。往復遅延時間（ＲＴＴ）、パケット損失率、ネットワークジッタなどのネットワークパラメータは、ネットワークリンクのスループットと比べてあまり関連性はない。エンドユーザノードからなるネットワークでは、ネットワークは、各ノード上のアップロード帯域幅制御条件、各ノード上のダウンロード帯域幅制約条件、および２つのノードまたはノードの２つのグループの間のリンク帯域幅制約条件を割り当てることにより特徴付けることができる。しかし、ボトルネックは、通常、ノードのアップロード帯域幅である。

本明細書で説明されているコンテンツ配信方法では、ピアノードは、コンテンツを複数の送信先に送信する。そこで、ピアノードの出力は分割され、複数の受信機に分配される。その結果、２つのピアノード間に必要なリンク帯域幅は、通常であればボトルネックとならない、送信側ノードのアップロード帯域幅の数分の一にすぎない。ノードがコンテンツを受信するために必要とするダウンロード帯域幅は、常に、ネットワーク内の全ノードの利用可能アップロード帯域幅の合計を受信側ノードの総数により割った値よりも小さい。次第に一般的になってきたネットワークでは、エンドユーザノードの総アップロード帯域幅の合計は、総ダウンロード帯域幅に比べてかなり小さい。これは、アップロードとダウンロードのバランスが、大きなダウンロード帯域幅により非対称的に歪んでいる、ケーブルモデムおよびＡＤＳＬ上のエンドユーザノードに特に当てはまる。キャンパスネットワークまたは企業ネットワーク上のユーザノードであっても、ダウンロード帯域幅は、利用可能なアップロード帯域幅に比べてかなり大きいが、それは、ユーザがアップロード帯域幅に上限を設定し、Ｐ２Ｐネットワーク活動への参加を制限することができるからである。以下の説明では、受信側ノードは、コンテンツ配信方法からコンテンツを受信できる十分なダウンロードおよびリンク帯域幅を持つと仮定する。

図５を再び参照し、ピアノードｔ_１およびｔ_２のアップロード帯域幅はＢ、ピアノードｔ_３のアップロード帯域幅は２Ｂ、ピアノードｔ_４のアップロード帯域幅は３Ｂ、送信元ノードのアップロード帯域幅は４Ｂであり、ただし、Ｂは帯域幅の単位であると仮定する。送信元ノードおよびピアノードのアップロード帯域幅を完全利用する最適な戦略が表１に示されている。

ネットワークに送信元ノード、Ｎ_１コンテンツ要求ピアノード（他の場合には問題は自明なのでＮ_１＞１）およびＮ_２非コンテンツ要求（ただし参加する意志あり）ピアノードが含まれる場合、このコンテンツ配信方法を使用するネットワークは、すべて送信元ノードをルートとする、中間次数Ｎ_１−１のＮ_１高さ２のツリー（中間ノードがコンテンツ要求ノードの１つである）、中間次数Ｎ_１のＮ_２高さ２のツリー（中間ノードが非コンテンツ要求ノードの１つである）、および次数Ｎ_１の１つの高さ１のツリーを通じてコンテンツを配信する。

このコンテンツ配信方法およびシステムにより採用されているこのネットワークトポロジは、上述のＦａｓｔＲｅｐｌｉｃａ手法から区別される多数の特徴を備えることに留意されたい。第１に、このコンテンツ配信方法およびシステムは、配信ステップと収集ステップとを分離しない。その代わりに、送信元ノードおよびピアノードによりコンテンツブロックが連続配信される。第２に、このコンテンツ配信方法では、特定のピアにより再配信されるコンテンツの量は一定でなく、ピアノードの能力（アップロード帯域幅など）により変化する。最後に、このコンテンツ配信方法およびシステムは、コンテンツの再配信において送信元ノードおよび非コンテンツ要求ピアノードを伴うことができる。

このコンテンツ配信方法では、１）コンテンツ要求ピアノードを通る経路、２）非コンテンツ要求ピアノードを通る経路、および３）直接送信元ノードからの経路の３つの経路を経由してコンテンツを配信する。それぞれの配信方法は、参加ノードとは異なるネットワークリソースの量を要求する。また、主に注目しているネットワークリソースは、消費されるアップロード帯域幅である。このコンテンツ配信方法を使用してＮ_１個のコンテンツ要求ピアノードのネットワーク内で帯域幅Ｂを持つコンテンツの一部を配信するには、最初の配信経路は、送信元ノードにアップロード帯域幅Ｂを要求し、それぞれのコンテンツ要求ピアノードにアップロード帯域幅（Ｎ_１−１）Ｂを要求する。第２の配信経路は、アップロード帯域幅Ｂを送信ノードに、アップロード帯域幅Ｎ_１・Ｂをそれぞれの非コンテンツ要求ピアノードに要求する。第３の配信経路は、アップロード帯域幅Ｎ_１・Ｂを送信元ノードに要求する。従って、このコンテンツ配信方法では、ピアノード（コンテンツ要求ピアノードおよび非コンテンツ要求ピアノードを含む）のアップロード帯域幅を使用して、送信元ノードにかかるアップロード帯域幅の負担を軽減する。これは、最大コンテンツ配信速度をスピードアップする効果を持つ。

同じ経路について、消費されるネットワークリソースの量は、それぞれのピアノードの個別アップロード帯域幅とは無関係であることに留意されたい。そのため、帯域幅割り当て問題は、それぞれのピアノードではなく、それぞれの経路カテゴリに関して考慮することができる。

（帯域幅割り当て）
このコンテンツ配信方法およびシステムを使用するネットワークにおいて、最も貴重なリソースは、コンテンツが発信される送信元ノードのアップロード帯域幅である。送信元ノードのアップロード帯域幅が使い切られると、利用可能なアップロード帯域幅を持つピアノードがあってもそれ以上コンテンツ配信をスピードアップすることはできない。送信元ノードがすべてのＮ_１コンテンツ要求ピアノードへの配送リンクを通じて速度Ｂでコンテンツブロックを送信できる場合に、その送信元のアップロード帯域幅のうちＮ_１・Ｂを消費することになることは明らかである。他方、送信元ノードがコンテンツブロックを速度Ｂでピアノードｔ_ｉに送信する場合、これは次に、ブロックをコンテンツ要求ピアノードの残りに配信するが、送信元ノードのアップロード帯域幅の量Ｂだけが必要である。明らかに、複数のコンテンツ要求ピアノードがある限り、送信元ノードは再配送のためできる限り多くのコンテンツブロックをピアノードに転送しなければならない。コンテンツ要求ピアノードと非コンテンツ要求ピアノードとの間で、コンテンツ要求ピアノードは、少し効率がよく、転送リンク内のノードに送信されるコンテンツブロックは無駄にならない。その結果、上記の３つの配信経路内で、最も好ましい経路は経路１（コンテンツ要求ピアノードを通じて）であり、続いて、経路２（非コンテンツ要求ピアノードを通じて）である。送信元ノードがまだアップロード帯域幅を残している場合のみ、コンテンツを直接ピアノードに配信するため経路３を選択することができる。

このコンテンツ配信方法およびシステムを使用するネットワークは、アップロード帯域幅Ｂｓ、Ｎ_１（Ｎ_１＞１）を持つ送信元ノード、平均帯域幅がＢ_１であるコンテンツ要求ピアノード、および平均帯域幅がＢ_２である非コンテンツ要求ピアノードを備える。上述の配信経路選択の戦略を適用する場合、１秒当たりのコンテンツマルチキャストの量対コンテンツ要求ピアノードの量として定義される、コンテンツ配信方法およびシステムの配信スループットは、以下のとおりである。

式（１）は、すべてのピアノードのアップロード帯域幅が使い切られる前に、配信スループットが送信元ノードのアップロード帯域幅によってのみ制限されていることを示している。Ｎ_１個のコンテンツ要求ピアノードはすべて、送信元ノードのアップロード帯域幅の転送速度でコンテンツを受信する。すべてのピアノードのアップロード帯域幅が使い切られた後、配信スループットは、ネットワークのアップロード帯域幅の総和（Ｎ_１Ｂ_１＋Ｎ_２Ｂ_２＋Ｂｓ）の１／Ｎ_１から非コンテンツ要求ピアノードを通る配信で浪費されるわずかな部分（Ｎ_２Ｂ_２／Ｎ_１）を引いた値となる。

（再配信キューを通じての配信経路選択）
配信経路優先度が上述のように設定されている場合に、送信元ノードおよびすべてのピアノードの利用可能なアップロード帯域幅が知られており、それにより、２つのピアノード間で割り当てられた帯域幅を明示的に計算できると仮定する。これにより、それに応じてコンテンツブロックを配信できるように方向が決まる。しかし、分散方式で動作するさらに簡単な方法がある。キューを使用して、任意の接続リンクに対する帯域幅を推定し、キューのステータスに基づいてコンテンツブロックの配信経路の選択を決定することができる。これにより、ネットワークの帯域幅が不明な場合も暗黙の帯域幅割り当てを実行できる。

このコンテンツ配信方法の帯域幅制御の戦略は、一方のノードから他方のノードへ配送されるコンテンツをバッファリングするキューを設定することを含む。このキューは、２つのノードの間の配信速度を制御するために使用される。コンテンツ配信方法のテストされた実装では、ノード間のリンクは、ＴＣＰ接続を介して確立される。従って、再配信キューはＴＣＰ送信および受信バッファである。ＴＣＰを使用する利点としては、さらに、フロー制御、信頼できるデータ配送、およびノードを離れたイベントは、すべてＴＣＰにより自動的に処理されることがあげられる。

再配信されるブロックを搬送するＴＣＰ接続は、転送リンクと呼ばれ、さらに配信されないブロックを搬送するＴＣＰ接続は、配送リンクと呼ばれる。それぞれのピアノードから他のすべてのコンテンツ要求ピアノードへ１つのＴＣＰ接続（配送リンク）が確立される。さらに、送信元ノードからすべての非コンテンツ要求ピアノードへ１つのＴＣＰ接続（転送リンク）が確立され、送信元ノードからすべてのコンテンツ要求ピアノードヘの２つのＴＣＰ接続（転送リンクおよび配送リンク）が確立される。その後、配信経路の選択は、ＴＣＰ接続内の利用可能なスロットを見つけることになる。

次に、再配送のプロセスを、送信元ノードおよびピアノードに関して詳細に説明することにする。それぞれのコンテンツ要求ピアノードは、少なくとも２つのスレッドを含む。第１のスレッド（「配送リンク」スレッド）は、配送リンクからコンテンツブロックを受信するが、第２のスレッド（「転送リンク」スレッド）は、転送リンクからコンテンツブロックを受信し、それらを、配送リンクを介して、コンテンツ要求ピアノードの残りに再配信する。非コンテンツ要求ピアノードでは、転送リンクスレッドのみが動作する。

図７は、ピアノード（コンテンツ要求と非コンテンツ要求の両方）の転送リンクスレッドのオペレーションを例示する詳細流れ図である。転送リンクスレッドのそれぞれの反復で、着信転送リンクキューが空であるかどうかが判定される（ボックス７００）。空であれば、このプロセスは待機する（ボックス７１０）。空でなければ、ピアノードは、着信転送リンクキューからコンテンツブロックを１つ取り出す（ブロック７２０）。次に、ノードは、コンテンツブロックを他のすべてのコンテンツ要求ピアノードへの送出配信リンクキュー上にコピーする（ボックス７３０）。その後、コンテンツブロックがすべてのピアノードヘのキューに正常に置かれたかどうかが判定される（ボックス７４０）。そうでなければ、プロセスは待機し（ボックス７５０）、その後、失敗したコンテンツ要求ノードを再試行する。そうでなければ、反復が再び開始する。

転送リンクスレッドは、最後のコンテンツブロックをすべての送出配送リンクキューに正常にコピーするまで着信転送リンクキューから他のコンテンツブロックを取り出さないことに留意されたい。そのようにして、送出配送リンクが、場合によってはピアノードのアップロード帯域幅に対する制限に達した結果、ブロックされると、ピアノードは、着信転送リンクキューからコンテンツブロックを取り出すのを停止する。これにより、転送リンクの受信速度をピアノードのアップロード帯域幅の１／Ｍになるように効果的に調整する。ここで、Ｍは、コンテンツブロックの再配信先のノードの個数であり、コンテンツ要求ピアノードではＮ_１−１、非コンテンツ要求ピアノードではＮ_１である。

図８は、コンテンツ受信ピアノードの配送リンクスレッドのオペレーションを例示する詳細流れ図である。最初に、到着したコンテンツブックが送信元ノードからか否かの判定が行われる（ボックス８００）。コンテンツブロックが送信元ノードと異なるノードから配送リンクに到着した場合、到着するやいなや着信配送リンクキューからコンテンツブロックを取り出すオペレーションが実行される。第１に、着信配送リンクキューが空かどうかの判定が行われる（ボックス８１０）。空でなければ、着信配送リンクキューからコンテンツブロックが取り出される（ボックス８２０）。空であれば、次のノードからのコンテンツが調べられる（ボックス８３０）。

コンテンツブロックが送信元ノードから配送リンクで到着した場合、転送リンクの受信バッファを調べる（ボックス８４０）。さらに、同じ送信元ノードからの転送リンクの受信バッファ長があるしきい値を超えた場合にのみ、配送リンクキューからコンテンツブロックが取り出されるという制約条件がある（ボックス８５０）。従って、バッファ長がしきい値を超えない場合、送信元ノードから配送リンクに到着したコンテンツブロックは取り出されない。その代わりに、次のノードの配送リンクを調べる（ボックス８３０）。そうでなければ、配送リンクが空かどうかの判定が行われ（ボックス８１０）、空でなければ、配送リンクからコンテンツブロックが取り出される（ボックス８２０）。

その根拠は、配送リンクおよび転送リンクは、送信元ノードからピアノードへの同じネットワーク経路を共有する２つの別々のＴＣＰ接続であることである。転送リンクを通じて送信されるコンテンツブロックは、他のコンテンツ受信ピアに再配送されるので、高い優先度を持つ。受信バッファ長ポリシーは、送信元ノードからピアノードへの配送リンクが活性化される前に、転送リンクの帯域幅がアップロード帯域幅の少なくとも１／Ｍとなることを保証する。

図９は、本明細書で開示されているコンテンツ配信方法による送信元ノードのオペレーションを例示する詳細流れ図である。一般に、送信元ノードは、コンテンツブロック毎に、再配信キューのステータスに基づき配信経路の１つを選択する。経路選択は、以下の優先度の順序に基づく。コンテンツ要求ピアノードによる再配信は、最高優先度を持つ。非コンテンツ要求ピアノードによる再配信は、２番目に高い優先度を持つ。送信元ノードからすべてのコンテンツ要求ピアノードへの直接的な配信は、最低優先度である。

特に、図９に示されているように、このプロセスは、次のコンテンツブロック（ボックス９００）および次のコンテンツ要求ピアノード（ボックス９０５）から始まる。その後、ピアノードの転送リンクが調べられる（ボックス９１０）。送信元ノードは、送信元ノードからコンテンツ要求ピアノードへの転送リンクの任意のＴＣＰ接続でコンテンツブロックに対し利用可能な領域があるかどうかチェックして判定する（ボックス９１５）。ＴＣＰ接続のうちの１つの送信バッファが満杯でなく、コンテンツブロック全体を保持できる場合、対応するコンテンツ要求ピアノードに送信されるコンテンツブロックは、ＴＣＰバッファ内に置かれ、その後、そのコンテンツ要求ピアノードは、コンテンツブロックを対応する配送リンクを通じて他のコンテンツ要求ピアノードに再配信する（ボックス９２０）。コンテンツ要求ピアノードヘの転送リンク上に空き領域が見つからない場合、送信元ノードは、すべてのコンテンツ要求ピアが調べられたかどうかを判定し（ボックス９２５）、その後、非コンテンツ要求ピアノードをチェックし（ボックス９３０）、さらにその転送リンクをチェックする（ボックス９３５）。

リンク上で利用可能な空き領域が見つかった場合（ボックス９４０）、コンテンツブロックは、対応するリンクに対するＴＣＰバッファ内に置かれる（ボックス９４５）。すべてのピアが調べられ（ボックス９５０）、非コンテンツ要求ピアノードへのリンク上にすら利用可能な空き領域がない場合、送信元ノードは、最終配信経路を追う。この最終配信経路では、すべてのコンテンツ要求ピアノードへの配送リンクを調べ（ボックス９５５）、すべてのコンテンツ要求ピアノード内に１ブロック分の領域があるかどうかを判別する（ボックス９６０）。これは、図８に示されている受信バッファ長ポリシーと組み合わせることで、転送リンクの帯域幅が転送リンクのトラフィックにより潰されないようにできる。領域が見つかった場合、コンテンツブロックは複製され、各コンテンツ要求ピアノードへの配送リンク内に置かれる（ボックス９６５）。配信経路のどれにも空き領域がない場合、送信元ノードは、少しの時間待ってから、コンテンツブロックの利用可能な経路を再び探そうと再試行する（ボックス９７０）。

（再配信キューの役割）
このコンテンツ配信方法では、再配信キューおよびピアノードおよび送信元ノードの上述の運用戦略を使用して、送信元ノードおよびピアノードのアップロード帯域幅リソースを完全利用することにより、最大のコンテンツ配信スループットを達成するようにノードのアップロード帯域幅を調整してパケット損失およびネットワーク輻輳などの異常を処理する。次に、このコンテンツ配信方法およびシステムが最適であることについて詳細に説明する。

２つのノード間のコンテンツブロックは、再配信キューを通じて配信され、これはテストされた実装では、あるサイズの送信および受信バッファとのＴＣＰ接続である。上の「再配信キューを通じての配信経路選択」のセクションで指摘したように、このコンテンツ配信方法およびシステムの送信元ノードおよびピアノードは、ＴＣＰ送信バッファが満杯になるまで、可能な限り多くのコンテンツブロックをＴＣＰ接続に押し込む。ＴＣＰ接続の送信バッファ内で保留になっているコンテンツブロックは、２つのピアノード間のネットワーク経路が、さらにはパケット損失およびネットワーク輻輳などのネットワーク異常を考慮して、完全利用されるようにする。パケット損失がない場合、新しいコンテンツブロックが、ＴＣＰ接続を介して送信先ピアノードに送信される。パケット損失またはその他のネットワーク異常がある場合、ＴＣＰは、再配送を通じてネットワークエラーからの回復を試み、ＴＣＰ送信バッファ内に保留されているコンテンツブロックは送出されない。転送リンクのＴＣＰ受信バッファ内に保留されているコンテンツブロックでは、対応するピアノードのアップロード帯域幅が完全に利用されるようにできる。ピアノードは、最後のコンテンツブロックを配送リンクのＴＣＰ送信バッファ内にプッシュした後、ＴＣＰ受信バッファ内に保留中のコンテンツブロックを取り出すことができる。こうして、配送リンク内にブロックをプッシュする動きは、アップロード帯域幅が浪費されないように継続することができる。

さらに、図７〜図９に示されているように、このコンテンツ配信方法を使用すると、送信元ノードおよびピアノードのアップロード帯域幅が完全に利用されるようにできる。これは、コンテンツ要求ピアノードを介した配信、非コンテンツ要求ピアノードを介した配信、および最後に、送信元ノードからの直接配信に有利になるようにコンテンツ配信経路が選択されることを保証する。

このコンテンツ配信方法を使用して、コンテンツをＮ_１個のコンテンツ要求ピアノードに配信するときに、送信元ノードのアップロード帯域幅が低く、送信元ノードからピアノードへの配送リンクが活性化されていない場合、このコンテンツ配信方法のコンテンツ配信スループットは、送信元ノードのアップロード帯域幅Ｂｓとなる。この場合、コンテンツは、速度Ｂｓで送信元ノードから送出され、そこで、ピアノードはすべてのコンテンツ要求ピアノードにコンテンツを送信するのに十分なアップロード帯域幅を持つ。それぞれのコンテンツ要求ピアノードは、送信元ノードがそのコンテンツをそのピアノードだけに送信しているかのように、速度Ｂｓでコンテンツを受信している。送信元ノードのアップロード帯域幅が高く、送信元ノードからコンテンツ要求ピアノードへの配送リンクが活性化された場合、このコンテンツ配信方法のコンテンツ配信スループットは、送信元ノードおよびピアノードのアップロード帯域幅の総和から、再配送のためコンテンツブロックを非コンテンツ要求ピアに送信することにより浪費される帯域幅のわずかな部分を引き、すべてコンテンツ要求ノードの個数Ｎ_１で除算した値となる。その結果、このコンテンツ配信方法では、ネットワークのリソースまたはキャパシティ（アップロード帯域幅など）がネットワークのどのような構成であろうと、式（１）で計算して求めた最大コンテンツ配信スループットが達成される。このコンテンツ配信方法は、さらに、ＴＣＰリンクの再配信キューを通じてネットワーク帯域幅の変化に容易に適合できる。特定のピアノードの速度が低下した場合、配送リンク内のコンテンツブロックは、ゆっくりと移動し、転送リンクからそれより少ないコンテンツブロックを取り出すようにピアノードに要求する。すると、これにより、送信元ノードは、より少ないコンテンツブロックをこの速度の低下したピアノードに送信し、そのコンテンツブロックを他のより高速なピアノードにリダイレクトする。代替として、特定のピアノードが速度上昇した場合（例えば、アップロード帯域幅が増大した場合）、このコンテンツ配信方法は、そのピアノードにより多くのコンテンツブロックを送信することにより同様に調整することができる。

（実施例）
本明細書で開示されているコンテンツ配信方法およびシステムをより完全に理解できるようにするため、実施例の動作詳細を説明する。この実施例は、コンテンツ配信方法およびシステムを実装できる唯一の方法であることに留意されたい。

この実装のコンテンツ配信方法およびシステムは、送信元ノードにより実行される送信機モジュールおよびピアノードのそれぞれにより実行される受信機モジュールを備えている。このコンテンツ配信方法およびシステムのパフォーマンスを検証するために、１つの送信元ノードと４つのコンテンツ受信ピアノードを持つコンテンツ配送Ｐ２Ｐネットワークを構築する。１ＭＢ程度のサイズのメディアファイルを、送信元ノードからすべてのピアノードに配信する。実際のスループットは、配信ファイルサイズを、コンテンツ配信方法およびシステムがファイルを配信するのにかかった時間で除算することにより求める。その後、これとネットワークの理論上のブロードキャストキャパシティとを、送信元ノードとピアノードのさまざまなアップロード帯域幅構成の下でコンテンツ配信方法と実際のスループットとの対比を使用して比較する。その結果を表２に示すが、理論上のブロードキャストキャパシティについては、以下で述べる。

図７〜図９に示されているコンテンツ配信方法およびシステムの送信機および受信機コンポーネントの実装を使用すると、このコンテンツ受信方法およびシステムを使用するネットワークの実際のスループットは、ピアツーピアネットワークの分析に基づくブロードキャストキャパシティに著しく近いことがわかる。

（Ｖ．動作環境例）
このコンテンツ配信方法およびシステムは、コンピューティング環境およびコンピューティングデバイスで動作するように設計されている。次に、このコンテンツ配信方法およびシステムが動作するコンピューティング環境について説明する。以下の説明は、このコンテンツ配信方法およびシステムを実装できる好適なコンピューティング環境について簡潔に述べた一般的な説明となるようこころがけた。

図１０は、図５に示されているコンテンツ配信方法およびシステムが実装可能な好適なコンピューティングシステム環境の実施例の図である。コンピューティングシステム環境１０００は、好適なコンピューティング環境の一例にすぎず、本発明の用途または機能性の範囲に関する制限を示唆する意図はない。コンピューティング環境１０００は、動作環境例１０００に例示されている１つのコンポーネントまたはその組み合わせに関係する何らかの依存関係または要求条件がその環境にあるものと解釈すべきでない。

このコンテンツ配信方法およびシステムは、他の数多くの汎用または専用コンピューティングシステム環境または構成で動作する。勾配補正された線形補間の方法およびシステムとともに使用するのに好適と思われるよく知られているコンピューティングシステム、環境、および／または構成の実施例として、限定はしないが、パーソナルコンピュータ、サーバコンピュータ、ハンドヘルド、携帯電話およびＰＤＡなどのラップトップまたはモバイルコンピュータまたは通信デバイス、マルチプロセッサシステム、マイクロプロセッサベースのシステム、セットトップボックス、プログラム可能な家電製品、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータ、上記システムまたはデバイスを含む分散コンピューティング環境などがある。

このコンテンツ配信方法およびシステムは、コンピュータによって実行される、プログラムモジュールなどのコンピュータ実行可能命令の一般的文脈において説明することができる。一般に、プログラムモジュールは、特定のタスクを実行する、または特定の抽象データ型を実装するルーチン、プログラム、オブジェクト、コンポーネント、データ構造などを含む。また、このコンテンツ配信方法およびシステムは、通信ネットワークを通じてリンクされているリモート処理デバイスによりタスクが実行される分散コンピューティング環境で実施することもできる。分散コンピューティング環境では、プログラムモジュールをメモリ記憶デバイスなどのローカルとリモートの両方のコンピュータ記憶媒体に配置できる。図１０を参照すると、このコンテンツ配信方法およびシステムを実装するシステムの実施例は、汎用コンピューティングデバイスをコンピュータ１０１０の形態で備えている。

コンピュータ１０１０のコンポーネントは、限定はしないが、処理ユニット１０２０、システムメモリ１０３０、およびシステムメモリを含むさまざまなシステムコンポーネントを処理ユニット１０２０に結合するシステムバス１０２１などを備えることができる。システムバス１０２１は、メモリバスまたはメモリコントローラ、周辺機器バス、およびさまざまなバスアーキテクチャを使用するローカルバスを含む数種類のバス構造のうちのいずれでもよい。例えば、限定はしないが、このようなアーキテクチャとしては、ＩＳＡ（Industry Standard Architecture）バス、ＭＣＡ（Micro Channel Architecture）バス、ＥＩＳＡ（Enhanced ISA）バス、ＶＥＳＡ（Video Electronics Standards Association）ローカルバス、およびメザニンバスとも呼ばれるＰＣＩ（Peripheral Component Interconnect）バスがある。

コンピュータ１０１０は、通常、さまざまなコンピュータ読取り可能媒体を含む。コンピュータ読取り可能媒体は、コンピュータ１０１０によってアクセスできる媒体であればどのような媒体でもよく、揮発性および不揮発性媒体、取り外し可能および取り外し不可能媒体を含む。例えば、限定はしないが、コンピュータ読取り可能媒体は、コンピュータ記憶媒体および通信媒体を含むことができる。コンピュータ記憶媒体は、コンピュータ読取り可能命令、データ構造体、プログラムモジュール、またはその他のデータなどの情報を格納する方法または技術で実装される揮発性および不揮発性、取り外し可能および取り外し不可能媒体を含む。

コンピュータ記憶媒体としては、限定はしないが、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリまたはその他のメモリ技術、ＣＤ−ＲＯＭ、デジタル多目的ディスク（ＤＶＤ）またはその他の光ディスク記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置またはその他の磁気記憶デバイス、または目的の情報を格納するために使用することができコンピュータ１０１０によりアクセスできるその他の媒体がある。通信媒体は、通常、コンピュータ読取り可能命令、データ構造体、プログラムモジュール、または搬送波もしくはその他のトランスポートメカニズムなどの変調データ信号によるその他のデータを具現するものであり、任意の情報配信媒体を含む。

「変調データ信号」という用語は、信号内の情報を符号化する方法によりその特性のうち１または複数が設定または変更された信号を意味することに注意されたい。例えば、限定はしないが、通信媒体としては、有線ネットワークまたは直接配線接続などの有線媒体、ならびに、音響、ＲＦ、赤外線、およびその他の無線媒体などの無線媒体がある。上記のいずれの組み合わせもコンピュータ読取り可能媒体の範囲に収まらなければならない。

システムメモリ１０３０は、読み取り専用メモリ（ＲＯＭ）１０３１およびランダムアクセスメモリ（ＲＡＭ）１０３２などの揮発性および／または不揮発性メモリの形態のコンピュータ記憶媒体を備える。起動時などにコンピュータ１０１０内の要素間の情報転送を助ける基本ルーチンを含む基本入出力システム１０３３（ＢＩＯＳ）は、通常、ＲＯＭ１０３１に格納される。通常、ＲＡＭ１０３２は、処理ユニット１０２０に直接アクセス可能な、および／または処理ユニット１０２０によって現在操作されているデータおよび／またはプログラムモジュールを格納する。例えば、限定はしないが、図１０は、オペレーティングシステム１０３４、アプリケーションプログラム１０３５、その他のプログラムモジュール１０３６、およびプログラムデータ１０３７を例示している。

コンピュータ１０１０は、さらに、その他の取り外し可能／取り外し不可能な揮発性／不揮発性コンピュータ記憶媒体を備えることもできる。例えば、図１０は、取り外し不可能な不揮発性磁気媒体の読み書きを行うハードディスクドライブ１０４１、取り外し可能な不揮発性磁気ディスク１０５２の読み書きを行う磁気ディスクドライブ１０５１、およびＣＤ−ＲＯＭまたはその他の光媒体などの取り外し可能な不揮発性光ディスク１０５６の読み書きを行う光ディスクドライブ１０５５を例示している。

動作環境の実施例で使用できる他の取り外し可能／取り外し不可能な揮発性／不揮発性コンピュータ記憶媒体としては、限定はしないが、磁気テープカセット、フラッシュメモリカード、デジタル多目的ディスク、デジタルビデオテープ、ソリッドステートＲＡＭ、ソリッドステートＲＯＭなどがある。ハードディスクドライブ１０４１は、通常、インタフェース１０４０などの取り外し不可能なメモリインタフェースを介してシステムバス１０２１に接続され、磁気ディスクドライブ１０５１および光ディスクドライブ１０５５は、通常、インタフェース１０５０などの取り外し可能なメモリインタフェースによりシステムバス１０２１に接続される。

図１０に例示されている上記のドライブおよび関連コンピュータ記憶媒体は、コンピュータ１０１０用のコンピュータ読取り可能命令、データ構造体、プログラムモジュール、およびその他のデータを格納する機能を備える。例えば、図１０では、ハードディスクドライブ１０４１は、オペレーティングシステム１０４４、アプリケーションプログラム１０４５、その他のプログラムモジュール１０４６、およびプログラムデータ１０４７を格納するとして例示されている。これらのコンポーネントは、オペレーティングシステム１０３４、アプリケーションプログラム１０３５、その他のプログラムモジュール１０３６、およびプログラムデータ１０３７と同じである場合もあれば異なる場合もあることに留意されたい。オペレーティングシステム１０４４、アプリケーションプログラム１０４５、その他のプログラムモジュール１０４６、およびプログラムデータ１０４７に対しては、ここで、異なる番号を割り当てて、最低でも、それらが異なるコピーであることを示している。ユーザは、キーボード１０６２、およびマウス、トラックボール、またはタッチパッドと一般に呼ばれるポインティングデバイス１０６１などの入力デバイスを介してコンピュータ１０１０にコマンドおよび情報を入力できる。

他の入力デバイス（図に示されていない）としては、マイク、ジョイスティック、ゲームパッド、衛星放送受信アンテナ、スキャナ、ラジオ受信機、またはテレビまたは放送ビデオ受信機などがある。これらの入力デバイスおよびその他の入力デバイスは、システムバス１０２１に結合されているユーザ入力インタフェース１０６０を介して処理ユニット１０２０に接続されることが多いが、例えば、パラレルポート、ゲームポート、またはユニバーサルシリアルバス（ＵＳＢ）などの他のインタフェースおよびバス構造により接続されることもできる。モニタ１０９１またはその他の種類の表示デバイスも、ビデオインタフェース１０９０などのインタフェースを介してシステムバス１０２１に接続される。モニタのほかに、コンピュータはさらにスピーカ１０９７およびプリンタ１０９６などの他の周辺出力デバイスも備えることができ、これらは出力周辺機器インタフェース１０９５を介して接続することができる。

コンピュータ１０１０は、リモートコンピュータ１０８０などの１つまたは複数のリモートコンピュータへの論理接続を使用してネットワーク接続環境で動作することができる。リモートコンピュータ１０８０は、パーソナルコンピュータ、サーバ、ルータ、ネットワークＰＣ、ピアデバイス、またはその他の共通ネットワークノードでもよく、通常は、コンピュータ１０１０に関係する上述の要素の多くまたはすべてを含むが、メモリ記憶デバイス１０８１だけが図１０に例示されている。図１０に示されている論理接続は、ローカルエリアネットワーク（ＬＡＮ）１０７１およびワイドエリアネットワーク（ＷＡＮ）１０７３を含むが、他のネットワークを含むこともできる。このようなネットワーキング環境は、オフィス、企業全体にわたるコンピュータネットワーク、イントラネット、およびインターネットでは一般的である。

ＬＡＮネットワーキング環境で使用される場合、コンピュータ１０１０は、ネットワークインタフェースまたはアダプタ１０７０を介してＬＡＮ１０７１に接続される。ＷＡＮネットワーキング環境で使用される場合、コンピュータ１０１０は、通常、インターネットなどのＷＡＮ１０７３上で通信を確立するためモデム１０７２またはその他の手段を備える。モデム１０７２は、内蔵でも外付けでもよいが、ユーザ入力インタフェース１０６０またはその他の適切なメカニズムを介してシステムバス１０２１に接続されうる。ネットワーク接続環境では、コンピュータ１０１０またはその一部に関して示されているプログラムモジュールは、リモートメモリ記憶デバイスに格納されうる。例えば、限定はしないが、図１０には、リモートアプリケーションプログラム１０８５がメモリデバイス１０８１に置かれているように例示されている。図に示されているネットワーク接続は実施例であり、コンピュータ間の通信リンクを確立するのに他の手段が使用可能であることは理解されるであろう。

（ＶＩ．コンテンツ配信効率の最大化の理論的分析）
このセクションでは、コンテンツ配信方法およびシステムが制約アップロード帯域幅のピアツーピアネットワークに対して最適であることを証明する。このコンテンツ配信方法およびシステムは、このようなネットワークでは可能な最大のスループットを達成しており、他のシステムではこれ以上よくならないことを以下で証明する。

Ｖをノードの集合、Ｅをリンク（有向辺）の集合とし、グラフ（Ｖ，Ｅ）でネットワークを表すものとする。Ｖ内のｓは送信元ノードを、Ｔはコンテンツ要求ノードのＥ内の部分集合を表すものとする。残りのノードは、非コンテンツ要求ノードとする。２種類のキャパシティを考察する。ｃ（ｅ）をＥ内の各辺ｅのキャパシティとし、ｃ_ｏｕｔ（ｖ）はＶ内の各ノードｖのアップロード帯域幅（出力キャパシティ）を表し、各ノードｖについて、ｖを始点とする辺のキャパシティの総和は、高々ｃ_ｏｕｔ（ｖ）であるとする。

Ｖ内の２つのノードｖ_１、ｖ_２の間の切断（Cut）は、ｖ_ｉがＶ_ｉ、ｉ＝１，２に含まれるようにＶを２つの集合Ｖ_１、Ｖ_２に分ける分割である。切断の値は、Ｖ_１からＶ_２への辺ｅ上のキャパシティｃ（ｅ）の総和である。

ｓとＴ内の任意のシンク（sink）ｔとの間の最大フローがｓとｔとの間のすべての切断にわたって最小値をとることはよく知られている。Ｃ_ｔをｓとｔとの間の最大フローの値（ｍａｘｆｌｏｗ）とする。Ｃ_ｔ＝Ｃ_ｔ（ｃ）は、辺キャパシティ関数ｃ：Ｅ→［０，∞］に依存することに注意されたい。

定義：ｓとＴとの間のブロードキャストキャパシティは、ｓとＴ内の任意のｔとの間の最小ｍａｘｆｌｏｗである、つまりＣ＝ｍｉｎ_ｔＣ_ｔである。Ｃ_ｔと同様に、Ｃ＝Ｃ（ｃ）は、辺キャパシティ関数ｃに依存することに注意されたい。

明らかに、ブロードキャストキャパシティＣは、共通の情報をｓからＴ内のすべてのノードにブロードキャストできる最大転送速度に対する上限である。残念なことに、Ｃはマルチキャスト経路選択を使用したのでは、一般的に達成可能でない。図１１は、マルチキャスト経路選択１１００を使用したのではブロードキャストキャパシティＣは達成可能でないことを示すブロック図である。Ｃは、ネットワーク符号化を使用すれば常に達成可能であるけれども、この場合、中間ノードは、出力パケットを生成するために入力パケットを、単に経路指定（route）するのではなく、符号化(code)する必要がある。経路選択のみが使用される場合、複数のマルチキャストツリーを介したｓからＴへの最大スループットＣ_０は、Ｃより小さい１／ｌｏｇＮになりうる。さらに、マルチキャストツリーの最適な集合を決定すること（Ｃ_０を達成すること）はＮＰ困難であるが、Ｃ_０と多項式時間内に達成可能なスループットＣ_００≦Ｃ_０との間のギャップについて知られている最もきつい上限は比較的緩い。その一方で、ネットワーク内にステイナー（Steiner）ノードがない場合（ステイナーノードとは、Ｃ_ｖ＜Ｃとなるノードｖのことである）、ブロードキャストキャパシティＣは、エドモンドの定理によって暗に示されているように、複数のマルチキャストツリーの貪欲アルゴリズムによる充填により単純に達成することができる。

複数のマルチキャストツリーの特に構造化された集合であるコンテンツ配信方法およびシステムでは、ある辺のキャパシティ関数ｃ（ｅ）についてブロードキャストキャパシティＣ＝Ｃ（ｃ）を達成する。さらに、これは、以下の定理が示すように、そのような最大のブロードキャストキャパシティを達成する。

定理：コンテンツ配信方法およびシステムスループットθは、ノード出力キャパシティ制約条件に従って、可能な最大ブロードキャストキャパシティをとる。つまり、すべてのノードｖについて、ｖを始点とするすべての辺にわたるｃ（ｅ）の総和が高々ｃ_ｏｕｔ（ｖ）となるような、すべての辺キャパシティ関数ｃ：Ｅ→［０，∞）にわたって、θ＝ｍａｘ_ｃＣ（ｃ）が成り立つ。

証明：以下では、Ｂ_ｓ≦Ｂ_ｓ１＋Ｂ_ｓ２が成り立つネットワークとＢ_ｓ≧Ｂ_ｓ１＋Ｂ_ｓ２が成り立つネットワークとで別々の証明を示す。前者は、Ｖ−ｓからｓを分離する切断で証明し、後者は、ｔからＶ−ｔを分離する切断で証明する。

まず、Ｂ_ｓ≦Ｂ_ｓ１＋Ｂ_ｓ２と仮定する。任意の辺キャパシティ関数ｃについて、ブロードキャストキャパシティＣ（ｃ）は、Ｖ−ｓからｓを分離する切断の値に高々等しい。これは高々Ｂ_ｓ≡ｃ_ｏｕｔ（ｓ）なので、これからｍａｘ_ｃＣ（ｘ）≦Ｂ_ｓが出る。もちろん、スループットθはθ≦ｍａｘ_ｃＣ（ｃ）を満たしていなければならない。その一方で、式（１）により、コンテンツ配信方法およびシステムはスループットθ＝Ｂ_ｓを達成する。故に、θ＝ｍａｘ_ｃＣ（ｃ）＝Ｂ_ｓとなる。

次に、Ｂ_ｓ≧Ｂ_ｓ１＋Ｂ_ｓ２と仮定する。任意の辺キャパシティ関数ｃについて、Ｔに含まれるノードを終点とするすべての辺にわたるｃ（ｅ）の総和は、少なくとも、ブロードキャストキャパシティＣ（ｃ）のＮ_１倍でなければならない。そこで、Ｕ＝Ｖ−Ｔ−ｓを非コンテンツ受信ノードの集合として表すと、以下の式が得られる。

一方、式（１）から以下の式が得られる（Ｂ_ｖ＝ｃ_ｏｕｔ（ｖ）と表す）。

故に、以下の式が得られる。

もちろん、θ≦ｍａｘ_ｃＣ（ｃ）が成り立つので、ｃ^＊を最適化キャパシティ関数とすると、Ｎ_１θ≦Ｎ_１ｍａｘ_ｃＣ（ｃ）＝Ｎ_１Ｃ（ｃ^＊）である。そこで、以下の式が得られる。

この不等式の等号が成り立つことを示すことができれば、証明は完了する。確かに、Ｕが空であれば、これは成り立つ。Ｕが空でない場合について証明するために、Ｕに含まれる各ｕについて、以下が成り立つことを主張する。

もし成り立たなければ、ｕを通りＮ_１個のコンテンツ受信ノードに向かう任意のフローは、アップロード帯域幅Ｂ_ｕを使い尽くすのには不十分であろう。ｓとＴとの間の辺からｓとＵとの間の辺に、あるキャパシティを再度割り当てることで、より高いスループットを達成することが可能であろう。

推論：ファイルダウンロードシナリオでは、このコンテンツ配信方法およびシステムは、コンテンツ受信ピアノードで生じる最大ダウンロード時間を最小にする。ストリーミングメディアシナリオでは、このコンテンツ配信方法およびシステムは、コンテンツ受信ピアノードで生じる最小品質を最大にする。従って、このコンテンツ配信方法およびシステムは、分散している友人グループが同じ品質で同じ時間にダウンロードコンテンツまたはストリーミングコンテンツを鑑賞したいという状況において理想的である。

（ダウンロード帯域幅またはリンク帯域幅制約条件の下でのスループット）
上記の説明では、このコンテンツ配信方法およびシステムの唯一のボトルネックは、ピアノードのアップロード帯域幅であると仮定している。このセクションでは、リンク帯域幅またはダウンロード帯域幅制約条件の下でのこのコンテンツ配信方法およびシステムのスループットについて簡単に説明する。

アップロード帯域幅Ｂ^ｕ _ｉを持つピアノードｉを考える。コンテンツ受信ピアノードｊへのそのリンク帯域幅をＢ^ｌ _ｉｊ、ｊ＝０，．．．，Ｍ−１とし、Ｍをそれ自体とは別のコンテンツ受信ノードの個数とする。ノードｉとｊとの間のリンク帯域幅は、以下の式が成り立つ限りボトルネックとならない。
Ｂ^ｌ _ｉｊ≧Ｂ^ｕ _ｉ／Ｍ

上記の不等式が満たされていない場合、ノードｉのアップロード帯域幅はこのコンテンツ配信方法では完全に利用することはできない。ノードｉの実効アップロード帯域幅は以下の式で表される。

この実効アップロード帯域幅を式（１）の中で使用して、このコンテンツ配信方法およびシステムの新しいスループットを得ることができる。

コンテンツ受信ピアノードが式（１）で与えられたスループットよりも小さいダウンロード帯域幅を持つ場合（アップロード帯域幅にのみ基づく）、そのようなノードはこのコンテンツ配信方法およびシステムのボトルネックにもなる。このようなシナリオでは、総スループットは、すべてのコンテンツ受信ピアノードの最小ダウンロード帯域幅となる。これは、すべてのノードが配送を再開できるようになるまで最も遅いノードの完了を待たなければならないからである。

このコンテンツ配信方法およびシステムのこの実装に対する代替戦略は、低速のピアノードにいくつかの特定のコンテンツブロックをスキップさせることで、残りのピアノードの受信動作速度の低下を抑えることである。これにより、ピアノードはそのまま転送速度を落とすことなく動作を続けることができる。ファイルダウンロードシナリオでは、低速のピアノードは、残りすべてのノードがダウンロードを完了した後に、スキップされたコンテンツを受信することができる。ストリーミングメディアシナリオでは、低速のピアノードは、層化された媒体符号化が使用される場合に、低品質のコンテンツを受信することができる。この代替アプローチと比較すると、このコンテンツ配信方法およびシステムのテストされた実装により、すべてのコンテンツ受信ピアノードに対する共通情報のスループットが最大化される。これは、ストリーミングメディアシナリオにおいてコンテンツ受信ピアノードで発生する最低品質を最大化するか、またはファイルダウンロードシナリオにおいてコンテンツ受信ピアノードで発生する最大ダウンロード時間を最小化する（例えば、分散している友人グループが同じ品質で同じ時間にアンロードコンテンツまたはストリーミングコンテンツを鑑賞したい場合）。これが目的でなく、むしろ、高速なノードに低速ノードよりも高いスループットを持たせることが許容される場合、代替実装が、テストされた実装よりも望ましいことがある。

本発明の前記の説明は、例示および説明を目的として提示された。この説明は網羅的であることを意図しておらず、また本発明を開示した正確な形態だけに限る意図もない。上記の教示に照らして、多数の修正形態および変更形態が可能である。本発明の範囲は、本発明のこの詳細な説明によってではなく、むしろ付属の請求項によって制限されるものとする。

一対多コンテンツ配信の問題を例示するブロック図である。 単一配信ツリーを使用するコンテンツ配信手法を例示するブロック図である。 ２アプリケーションレベルマルチキャストツリー構成を例示するブロック図である。 ３つのピアノードの構成例を示すブロック図である。 本明細書で開示されているコンテンツ配信システムおよび方法の実施例を示すブロック図である。 図５に示されているコンテンツ配信システムおよび方法の一般的なオペレーションを例示する一般的な流れ図である。 ピアノード（コンテンツ要求と非コンテンツ要求の両方）の転送リンクスレッドのオペレーションを例示する詳細流れ図である。 コンテンツ受信ピアノードの配送リンクスレッドのオペレーションを例示する詳細流れ図である。 本明細書で開示されているコンテンツ配信方法による送信元ノードのオペレーションを例示する詳細流れ図である。 図５に示されているコンテンツ配信方法およびシステムが実装可能な好適なコンピューティングシステム環境の実施例の図である。 マルチキャスト経路選択を使用してでは最大ブロードキャストキャパシティが達成できないことを示すブロック図である。

符号の説明

ｓ 送信元ノード
ｔ_ｉ、i=1,2,...,N ピアノード

Claims (40)

1. コンピュータネットワーク上の複数のノードにコンテンツを配信する方法であって、
   前記コンテンツを複数のブロックに分割すること、
   ノードのキャパシティに比例して、前記ノードに前記複数のブロックのそれぞれを割り当て、より大きなキャパシティを持つノードは、より多くのブロックが割り当てられ、より小さなキャパシティを持つノードは、より少ないブロックが割り当てられること、
   前記割り当てられたノードが送信元ノードでなければ、前記送信元ノードから配送のために前記送信元ノードの割り当てたノードに、前記複数のブロックのそれぞれを送信すること、および、
   前記割り当てられたノードにより残りのコンテンツ要求ノードに前記ブロックを再配送すること
   を備えたことを特徴とする方法。
2. 前記ノードの帯域幅に関して前記ノードの前記キャパシティを定義することをさらに備えたことを特徴とする請求項１に記載の方法。
3. 前記帯域幅は、前記ノードの前記アップロード帯域幅であることを特徴とする請求項２に記載の方法。
4. 前記複数のブロックのそれぞれのサイズは、コンピュータネットワークの最大転送単位（ＭＴＵ）よりも小さいことを特徴とする請求項１に記載の方法。
5. 前記コンテンツブロックサイズは、約１キロバイトであることを特徴とする請求項４に記載の方法。
6. 前記複数のブロックのそれぞれのサイズは、配信の精度と前記ブロックを識別するのにかかるオーバーヘッドとの間の妥協値であることを特徴とする請求項１に記載の方法。
7. 前記割り当てられたノードは、前記コンテンツのコピーを要求するコンテンツ要求ピアノードであることを特徴とする請求項１に記載の方法。
8. 前記割り当てられたノードは、前記コンテンツのコピーを要求しない非コンテンツ要求ピアノードであることを特徴とする請求項１に記載の方法。
9. 前記割り当てられたノードは、送信元ノードであることを特徴とする請求項１に記載の方法。
10. 前記ノードのキャパシティの変化に基づいてブロックの動的再配信を有効にするため帯域幅制御戦略を使用することをさらに備えたことを特徴とする請求項１に記載の方法。
11. 前記帯域幅制御戦略は、前記ネットワーク内の前記ノードのそれぞれのペアの間で再配信キューを使用することをさらに備えたことを特徴とする請求項１０に記載の方法。
12. ＴＣＰを使用して再配信キューを構成することをさらに備えたことを特徴とする請求項１１に記載の方法。
13. 前記再配信キューは、ＴＣＰ送信および受信バッファであることを特徴とする請求項１２に記載の方法。
14. ＵＤＰの上に実装されたアプリケーションバッファを使用して再配信キューを構成することをさらに備えたことを特徴とする請求項１１に記載の方法。
15. 転送リンクを前記送信元ノードと前記割り当てられたノードとの間の接続として定義し、前記接続で送信された前記コンテンツブロックは、さらに再配信されることをさらに備えた特徴とする請求項１に記載の方法。
16. 配送リンクを前記割り当てられたノードと他のコンテンツ要求ピアノードとの間の接続として定義し、前記接続で送信された前記コンテンツブロックは、さらに再配信されないことをさらに備えた特徴とする請求項１に記載の方法。
17. 前記コンピュータネットワークは、ピアツーピアネットワークであることを特徴とする請求項１に記載の方法。
18. 請求項１に記載のコンピュータにより実装される方法を実行するためのコンピュータ実行可能命令を格納することを特徴とするコンピュータ読取り可能媒体。
19. コンピュータネットワーク上の送信元ノードから複数のコンテンツ要求ノードにコンテンツを配送するためのコンピュータにより実装される方法であって、
    配送される前記コンテンツを複数のさらに小さなコンテンツブロックに分割すること、
    ノードに再配送のための前記コンテンツブロックのそれぞれを割り当てること、
    前記割り当てられたノードが前記送信元ノードでなければ、前記送信元ノードからその割り当てられたノードに、前記コンテンツブロックのそれぞれを送信すること、および、
    前記割り当てられたノードから前記残りのコンテンツ要求ピアノードに前記コンテンツブロックを再配信すること
    を備えたことを特徴とするコンピュータにより実装される方法。
20. 前記コンピュータネットワークの複数のノード間で再配信キューを使用して、前記コンピュータネットワークの動的変化を効果的に管理することをさらに備えたことを特徴とする請求項１９に記載のコンピュータにより実装される方法。
21. 前記コンピュータネットワークは、ピアツーピアネットワークであることを特徴とする請求項１９に記載のコンピュータにより実装される方法。
22. 前記割り当てられたノードは、前記コンテンツ要求ピアノードであることを特徴とする請求項２１に記載のコンピュータにより実装される方法。
23. 前記割り当てられたノードは、前記コンテンツを要求しない非コンテンツ要求ピアノードであることを特徴とする請求項２１に記載のコンピュータにより実装される方法。
24. 前記ノードに割り当てられたコンテンツブロックの個数を変化させて、ノードにより再配信されるコンテンツの量が可変となるようにすることをさらに備えたことを特徴とする請求項１９に記載のコンピュータにより実装される方法。
25. 前記ノードのキャパシティに基づき前記ノードに割り当てられたコンテンツブロックの前記個数を変化させることをさらに備えたことを特徴とする請求項２４に記載のコンピュータにより実装される方法。
26. 前記ノードのアップロード帯域幅に関して前記ノードの前記キャパシティを定義することをさらに備えたことを特徴とする請求項２５に記載のコンピュータにより実装される方法。
27. 請求項１９に記載のコンピュータにより実装される方法を実行するためのコンピュータ実行可能命令を格納することを特徴とするコンピュータ読取り可能媒体。
28. ピアツーピアコンピュータネットワーク内の複数のノード間にコンテンツを配信する方法であって、
    前記コンテンツを複数のより小さなコンテンツブロックに分離すること、
    前記コンテンツブロックのそれぞれを再配送のため前記ノードの１つに割り当て、割り当てられたコンテンツブロックの個数を、前記割り当てられたノードの前記アップロード帯域幅に応じて変更できるようにすること、
    前記ノード間で再配信キューを使用すること、および、
    前記再配信キューを使用して前記コンテンツブロックを再度割り当て、前記割り当てられたノードの前記アップロード帯域幅が変わると、再配信のためそのノードに割り当てられているブロックの個数に変化が生じるようにすること
    を備えたことを特徴とする方法。
29. 前記再配信キューは、ＴＣＰ送信および受信バッファであることを特徴とする請求項２８に記載の方法。
30. ＵＤＰの上に実装されたアプリケーションバッファを使用して前記再配信キューを生成することをさらに備えたことを特徴とする請求項２８に記載の方法。
31. 転送リンクを、さらに再配信すべきコンテンツブロックを持つノード間の接続として定義することをさらに備えたことを特徴とする請求項２８に記載の方法。
32. 着信転送リンクから１つのコンテンツブロックを取り出して、現在のコンテンツブロックとして定義すること、および、
    前記現在のコンテンツブロックをすべてのコンテンツ要求ピアノードの送出配送リンクにコピーすること
    をさらに備えたことを特徴とする請求項３１に記載の方法。
33. 前記現在のコンテンツブロックが送出配送リンクのそれぞれにコピーされるまで、着信転送リンクから他のコンテンツブロックを取り出すのを待つことをさらに備えたことを特徴とする請求項３２に記載の方法。
34. 配送リンクを、さらに再配信されないコンテンツブロックを持つノード間の接続として定義することをさらに備えたことを特徴とする請求項３１に記載の方法。
35. 到着コンテンツブロックが（ａ）コンテンツ要求ノード、（ｂ）非コンテンツ要求ノードのうちの１つにより送信されたことを判別すること、および、
    前記ブロックが到着すると直ちに前記配送リンクから前記到着コンテンツブロックを取り出すこと
    をさらに備えたことを特徴とする請求項３４に記載の方法。
36. 到着コンテンツブロックが送信元ノードにより送信されたことを判別すること、および、
    前記送信元ノードからの前記転送リンクの受信バッファ長がしきい値よりも大きい場合にのみ、前記配送リンクから到着コンテンツブロックを取り出すこと
    をさらに備えたことを特徴とする請求項３４に記載の方法。
37. 前記送信元ノードから前記コンテンツ要求ノードへの前記転送リンク内にコンテンツブロック１つ分の空き領域があるかどうかを判別すること、
    前記コンテンツブロックを、対応するコンテンツ要求ノードに送信するためにバッファ内に置くこと、および、
    前記コンテンツブロックを対応する配送リンクを通じて他のコンテンツ要求ピアノードに再配信すること
    をさらに備えたことを特徴とする請求項３４に記載の方法。
38. 前記送信元ノードから前記コンテンツ要求ノードへの前記転送リンク内にコンテンツブロック１つ分の空き領域がないことを判定すること、
    前記非コンテンツ要求ピアノードへの転送リンク内に空き領域があるかどうかを判定すること、
    空き領域がある場合に、前記コンテンツブロックを、対応する非コンテンツ要求ノードに送信するためにバッファ内に置くこと、および、
    前記コンテンツブロックを対応する配送リンクを通じて他のコンテンツ要求ピアノードに再配信すること
    をさらに備えたことを特徴とする請求項３７に記載の方法。
39. 前記送信元ノードから前記コンテンツ要求ノードおよび非コンテンツ要求ノードへの前記転送リンク内にコンテンツブロック１つ分の空き領域がないことを判定すること、
    前記送信元ノードから前記非コンテンツ要求ピアノードへのすべての配送リンク内に空き領域があるかどうかを判定すること、および、
    空き領域がある場合に、前記コンテンツブロックを、前記送信元ノードからすべてのコンテンツ要求ピアノードへのすべての配送リンクのバッファ内に置くこと
    をさらに備えたことを特徴とする請求項３８に記載の方法。
40. 前記送信元ノードから前記コンテンツ要求ノードおよび非コンテンツ要求ノードへの前記転送リンク内にコンテンツブロック１つ分の空き領域がない、および前記送信元ノードからコンテンツ要求ピアノードへの前記配送リンクのどれにも空き領域がないことを判定すること、および、
    空き領域がない場合、少しの間待ってから再試行すること
    をさらに備えたことを特徴とする請求項３９に記載の方法。
    

Images