JP4750457B2 - データオーバーレイ、自己編成メタデータオーバーレイおよびアプリケーションレベルマルチキャスティング - Google Patents

Description

本発明は、分散データ構造、および、データ構造を利用してピアツーピアシステムと対話するための技術、ならびに、アプリケーションレベルマルチキャスティングを有する技術を使用することに関する。

ピアツーピア（Ｐ２Ｐ）システムは、等しいまたは類似の能力および責任を有する参加マシンを接続するネットワークを使用する。これらのシステムは、従来のサーバの調整なしに（または、サーバによる最小限のセットアップ調整を有して）タスクを実行する。例えば、図１は、Ｐ２Ｐシステム１００の高レベルの図である。システム１００には、等しいまたは類似の能力および責任を有するピアエンティティ（１０２〜１１２）の集まりが含まれる。一例では、ピアエンティティ（１０２〜１１２）は、インターネットまたはイントラネットを介して共に結合された、独立したパーソナルコンピュータデバイスに対応する場合がある。ピアエンティティ（１０２〜１１２）は、ファイルまたは他の情報をそれらの間で直接（例示的通信パス１１４によって示すように）、サーバの助けなしに転送することができる。Ｐ２Ｐシステムの概略紹介を見つけることができる（例えば、非特許文献１参照）。

Ｐ２Ｐシステムは一般に分散ハッシュテーブル（ＤＨＴ）を使用して、システム内で参加するピアエンティティからのオブジェクトの格納および検索を実施する。その名が示唆するように、分散ハッシュテーブル（ＤＨＴ）は、異なるコンピュータデバイスに関連付けられた複数のストアに渡って分散されるなど、複数のロケーションに渡って分散されるハッシュテーブルを指す。分散ハッシュテーブルは、それぞれ割り当てられたＩＤを有する複数のＤＨＴノードを規定する。ＤＨＴノードは集合的に、抽象ＤＨＴ論理空間を定義する。オブジェクトにハッシング関数を受けさせてキーを作成することによって、オブジェクトをこのＤＨＴ論理空間に挿入し、そこから検索することができる。次いで、このキーが使用されて、ＤＨＴ論理空間内でオブジェクトを受信するようになるか、あるいはそこからオブジェクトを検索することができる、特定のターゲットノードＩＤが探し出される。すなわち、各ＤＨＴノードはキーの範囲に関連付けられ、オブジェクトのキーが特定のＤＨＴノードに関連付けられたキーの範囲内に入るかどうかに応じて、オブジェクトはその特定のＤＨＴノードに追加され、あるいはその特定のＤＨＴノードから検索される。非分散ハッシュテーブルの実施とは異なり、ＤＨＴノードは自由にＤＨＴ論理空間に結合し、そこから離れることができ（例えば、コンピュータデバイスがＰ２Ｐシステムに結合すること、およびそこから離れることにそれぞれ対応する）、そのため、これらのイベントに対処するための機能性が提供されなければならない。

様々なＤＨＴ方法が、Ｐ２Ｐシステム内のオブジェクトの格納および検索を管理するために開発されている。図２は、Ｃｏｎｔｅｎｔ Ａｄｄｒｅｓｓａｂｌｅ Ｎｅｔｗｏｒｋ（ＣＡＮ）方法を示し、例えば説明されている（例えば、非特許文献２参照）。この方法はＤＨＴ論理空間をＤ次元デカルト空間２００としてモデリングする。ＣＡＮ方法は、ノードがＤＨＴ空間２００に結合する場合、空間２００をパーティション化する。例えば、ノードｎ１が結合する場合、ＣＡＮ方法は空間２００全体をこのノードに割り振る。ノードｎ２が結合する場合、ＣＡＮ方法は空間２００を半分に分割し、各半分をノードｎ１およびｎ２にそれぞれ割り振る。ノードｎ３が結合する場合、ＣＡＮ方法は右半分を上下の４分の１に分割し、上の４分の１をノードｎ２へ、下の４分の１をｎ３に割り当てる。ノードｎ４が結合する場合、ＣＡＮ方法は右下の４分の１を、左の８分の１（ノードｎ３に割り当てられる）および右の８分の１（ノードｎ４に割り当てられる）に分割する。この手順は、ノードが追加および除去されることを動的に計上するために必要な回数で繰り返される。結果して生じるパーティションは、オブジェクトを分散ハッシュテーブルに挿入し、そこから検索するために使用される論理空間を定義する。ノードはその空間にマップするオブジェクトを「所有」する、ということができる。

図３は、ＣＨＯＲＤ（例えば、非特許文献３参照）と呼ばれるもう１つの方法を示す。この方法では、ＤＨＴ論理空間は円形空間３００として構築される。ＤＨＴノードにはＩＤが割り当てられ、それらの割り当てられたＩＤに基づいて、円形のＤＨＴ論理空間３００に追加される。例えば、図３に示す例示的ＤＨＴノードｎ１、ｎ２、ｎ３、ｎ４およびｎ５には、円形ＤＨＴ論理空間３００上のそれらの「配置」を管理するＩＤが割り当てられている。図２の場合のように、ＤＨＴノードは、追加される場合にＤＨＴ論理空間３００をパーティション化し、複数の部分空間またはゾーンを定義する。これらのゾーンは、各ノードが「所有」するオブジェクトを定義する。例えば、オブジェクトを、図３に示すＤＨＴ方法によって管理される分散ハッシュテーブルに挿入するために、オブジェクトはハッシング関数を受けてキーが作成される。オブジェクトは次いで、そのキーに割り当てられたゾーンを有するＤＨＴノードで（例えば、オブジェクトのキーを含むキーの範囲を包含するＤＨＴノードで）格納される。図２および図３の場合の両方で、様々なルックアップ方法を使用して、Ｐ２Ｐシステム内で特定のノードを高速に発見することができる。一般に、ルックアップ方法は、所望のターゲットＤＨＴノードに狭めるために、いくつかの「ホップ」をＤＨＴ論理空間内で作成することを含む。この探索を促進するために、様々なメカニズムが一般に提供される。例えば、ＣＨＯＲＤ方法内の各ＤＨＴノードは、他のＤＨＴノードのセットのＩＤを格納する。これらの他のＩＤは指数関数的な方法で増す可能性があり、論理空間３００を精査する、いわゆる「フィンガー」を確立する可能性がある。これにより、ルックアップ手順は、少数のホップにより所望のＤＨＴノードを高速に探し出すことができる。

図２および３は単に、２つの例示的な知られているＤＨＴルーティング方法の高レベルの概観を提供する。多数の他の方法がある。例えば、別のよく知られているルーティング方法はＰＡＳＴＲＹルーティング方法であり、説明されている（例えば、非特許文献４参照）。

D. S. Milojicic, V. Kalogeraki, R. Lukose, K. Nagaraja, J. Pruyne, B. Richard, S. Rollins, and Z. Xu., "Peer-To-Peer Computing," Technical Report HPL-2002-57, HP Lab, 2002 S. Ratnasamy, P. Francis, M. Handley, R. Karp, and S. Shenker, "A Scalable Content-Addressable Network," ACM SigComm 2001, San Diego, CA, USA, Aug. 2001 I. Stoica, R. Morris, D. Karger, M. F. Kaashoek, and H. Balakrishnan, "Chord: a Scalable Peer-To-Peer Lookup Service for Internet Applications," ACM SigComm 2001, San Diego, CA, USA, Aug. 2001 A. Rowstron and P. Druschel, "Pastry: Scalable, Distributed Object Location and Routing for Large-Scale Peer-To-Peer Systems," 18th FIFP/ACM International Conference on Distributed Systems Platforms (Middleware), Heidelberg, Germany, Nov. 2001

Ｐ２Ｐシステムは、従来のクライアント−サーバ方法に勝る多数の利点を提供する。例えば、Ｐ２Ｐシステムは、中央の調整なしに自動的および自由に拡張および縮小する能力を有する。しかし、この監視的調整の欠如はまた様々な課題をもたらす。例えば、Ｐ２Ｐシステムを、あるグローバル関数を実行するために一斉に動作させることが望ましい場合がある。様々な場合に、Ｐ２Ｐシステムの参加者からデータを収集することが望ましい場合がある。または、情報をＰ２Ｐシステム内の参加者に配布することが望ましい場合がある。サーバ−クライアントの手法では、サーバは単にそのクライアントをポーリングして、そのクライアントから情報を収集することができ、あるいは、情報をそのクライアントにブロードキャストして、情報をそのクライアントに配布することができる。しかし、データの収集および配布はＰ２Ｐシステムにおいてより問題になり、これは、Ｐ２Ｐシステムが、自由に出入りすることができる相互接続されたピアの緩い連合によって形成されるからである。集中型の従来のレポーティング機能の追加は、Ｐ２Ｐシステムを複雑にし、したがってその柔軟性および有用性を低減する影響を有する場合がある。

したがって、当技術分野では、例えば、その参加者からのデータの収集、および、その参加者への情報の配布を可能にする、Ｐ２Ｐ ＤＨＴと対話するための効率的な方法のための例示的必要性がある。また、Ｐ２Ｐ ＤＨＴを効率的に編成し、アプリケーションレベルマルチキャスティングオペレーションにおけるように、その効率から利益を得るようになるオペレーションにおいてＰ２Ｐ ＤＨＴと対話することが望ましい。

１つの例示的実施態様によれば、データオーバーレイを構築するための方法が説明される。

この方法は、分散ハッシュテーブル（ＤＨＴ）を提供することを含み、分散ハッシュテーブルは、ピアツーピアシステムへのオブジェクトの挿入、およびピアツーピアシステムからのオブジェクトの検索を管理し、分散ハッシュテーブルは、関連付けられた複数のＤＨＴゾーンを有する複数のＤＨＴノードを含む、論理空間を含む。この方法はまた、データオーバーレイをデータ構造として分散ハッシュテーブルの論理空間の上に構築することをも含み、この構築は、データ構造内のオブジェクトをＤＨＴノードに関連付けることによって、および、データ構造内のオブジェクトの間でリンクを確立することによって行う。データオーバーレイはツリーのトポロジを有し、ツリーは、各ＤＨＴノードに関連付けられたツリーノードを有する。各ツリーノードは、それに関連付けられた各ツリーノードゾーンを有し、各ツリーノードゾーンは、分散ハッシュテーブルの論理空間の一部に対応する。

マシンはＤＨＴの論理空間にマップされる。各マシンは、１つまたは複数のツリーノードゾーンに対応する。各マシンはその代表ノードとして、それに対応する１つまたは複数のツリーノードゾーンから、最大サイズのツリーノードゾーンに対応するツリーノードを選択する。各代表ノードはその親ノードとして、より大きいサイズを有する隣接ツリーノードゾーンのための代表ノードである、もう１つの代表ノードを選択する。

マシンがＤＨＴの論理空間にマップされた後、メタデータを、各マシンでのメタデータの収集にすることができる。収集されたメタデータを各マシンからその代表ノードに送信することができ、それらの代表ノードは、そのように受信されたメタデータをそれらの各親ノードに送信することができる。ツリー内の最高ノード（例えば、ルートノード）で受信されたメタデータを処理して、各親および代表ノードを介して各マシンに送信することができる。メタデータを、例えば、各マシンのオペレーションに関する情報にすることができ、処理されたメタデータを、各マシンのオペレーションを管理することができる命令にすることができる。

追加の実施態様および特徴を以下で説明する。

実施態様のより完全な理解は、以下の詳細な説明が添付の図面と共に解釈される場合、これを参照することによって有することができる。

同じ番号は、本開示および図面の全体に渡って、類似のコンポーネントまたは特徴を参照するために使用される。１００からの一連の番号は、最初に図１で発見される特徴を指し、２００からの一連の番号は、最初に図２で発見される特徴を指し、３００からの一連の番号は、最初に図３で発見される特徴を指す、などとなる。

本明細書で説明する方法は、ピアツーピア（Ｐ２Ｐ）システムで使用される分散ハッシュテーブル（ＤＨＴ）の「上に」構築されたデータ構造に関する。ピアツーピア（Ｐ２Ｐ）システムという用語は、図１の相互接続ネットワーク１００など、参加者が他者と直接対話することができる、参加者のいかなる相互接続をも表すことができる。一実施態様では、Ｐ２Ｐシステムは、いかなるサーバタイプのエンティティの支援をも必要としない。参加者にはいかなる種類のエンティティもが含まれる可能性があり、パーソナルコンピュータ、ラップトップコンピュータ、携帯情報端末、アプリケーションに特化したコンピューティングデバイスなどが含まれる。参加者は、ハードワイヤードおよび／または無線通信ルーティングメカニズム、様々なルータ、ゲートウェイなど、いずれかの組合せのルーティングインフラストラクチャを介して互いに通信することができる。さらに、参加者は、ＴＣＰ／ＩＰ（例えば、インターネットまたはイントラネットによって提供される）など、いずれかの組合せのネットワークプロトコルを通じて互いに通信することができる。

より一般には、本明細書で説明するファンクションのいずれも、ソフトウェア、ファームウェア（例えば、固定ロジック回路）、手動処理、またはこれらの実施態様の組合せを使用して実施することができる。「ロジック」または「モジュール」という用語は、本明細書で使用される場合、一般に、ソフトウェア、ファームウェア、または、ソフトウェアおよびファームウェアの組合せを表す。例えば、ソフトウェア実施態様の場合、「ロジック」または「モジュール」という用語は、処理デバイス（例えば、ＣＰＵ）上で実行される場合に、規定されたタスクを実行するプログラムコードを表す。プログラムコードを、１つまたは複数のコンピュータ可読メモリデバイス内に格納することができる。

本開示は以下を含み、すなわち、セクションＡは、Ｐ２Ｐ ＤＨＴの「上に」構築することができる汎用データオーバーレイ構造を説明し、セクションＢは、自己編成メタデータオーバーレイまたは「ＳＯＭＯ」を説明し、セクションＣは、Ｐ２Ｐシステム内の情報の収集および配布のためのＳＯＭＯの適用を説明し、セクションＤは、Ｐ２Ｐ ＤＨＴを使用したアプリケーションレベルマルチキャスティング（ＡＬＭ）を説明し、セクションＥは、セクションＡ〜Ｄで説明するＡＬＭによるＰ２Ｐ ＤＨＴシステムのタイプで使用することができる例示的Ｐ２Ｐ参加者の使用を説明する。

Ａ．Ｐ２Ｐ ＤＨＴ上のデータオーバーレイ
データオーバーレイは、オブジェクトからなるデータ構造である。データ構造は、分散ハッシュテーブルの「上に」実装される。背景として、ＤＨＴは、Ｐ２Ｐシステムによって提供された分散ストアにオブジェクトを挿入するため、およびそこからオブジェクトを検索するための技術を提供する。ＤＨＴはこのタスクを、論理ＤＨＴ空間内でＤＨＴノードの集まりを定義することによって実行する。すなわち、ＤＨＴ技術は各ＤＨＴノードをＤＨＴ論理空間の所定の部分に割り当て、この部分をＤＨＴノードの「ゾーン」と称する。例えば、ＣＨＯＲＤ技術では、特定のＤＨＴノードのゾーンを、円形のＤＨＴ論理空間（例えば、図３に示す）内のその特定のＤＨＴノードとその隣接ノードの間で定義された範囲として解釈することができる。オブジェクトは、オブジェクトをハッシングしてキーを作成すること、および、次いでこのキーを使用してこのオブジェクトをＤＨＴ論理空間内の特定のノードＩＤに関連付けることによって、格納される。オブジェクトはＤＨＴ論理空間から、関連した方法で検索される。関連付けられたゾーンは最終的に実際のマシン（例えば、コンピューティングデバイスおよび関連付けられたファイルストレージシステム）にマップするが、ノードとマシンの間で１対１の関係がある必要はない。

そのオブジェクトがＤＨＴ論理空間内のノードに関連付けられるという意味で、データオーバーレイはＤＨＴの「上に」実装される。さらに、アプリケーションは、データオーバーレイのデータ構造内であるオブジェクトから別のオブジェクトへ、Ｐ２Ｐ ＤＨＴの基礎となるプロトコルおよびサービスを使用してトラバース（またはルーティング）する。具体的には、参照のフレームについては、図４の単一マシン環境４０２の従来の場合を考察されたい。この環境４０２では、データ構造には２つのオブジェクト、ａ４０４およびｂ４０６が含まれ、これらのオブジェクトは、単一のマシンによって提供されたストレージ内で実装される。オブジェクトは、従来の場合、いかなるタイプの情報のいかなる単位をも幅広く表し、例えば、オブジェクトはデータベースレコード、例えばドキュメントに対応する場合がある。図４の例では、オブジェクトａ４０４は、オブジェクトｂ４０６を参照するポインタ４０８を含む。

対照的に、図５は、Ｐ２Ｐ ＤＨＴ環境５０２のコンテキストにおけるデータオーバーレイの実装を示す。この環境５０２では、オブジェクトは、ＤＨＴによってすでに提供されたＤＨＴノードフレームワークの「上に」構築されるので、ＤＨＴ論理空間内の個々のノードはデータオーバーレイ内のオブジェクトを「ホスト」する。例えば、ＤＨＴノードｘ５０４はオブジェクトａ５０６をホストし、ＤＨＴノードｙ５０８はオブジェクトｂ５１０をホストする。この例では、オブジェクトａ５０６はオブジェクトｂ５１０を参照する。一般に、オブジェクトａ５０６はオブジェクトｂ５１０に、オブジェクトｂ５１０にアクセスするために使用されるキーを格納することによって、リンクすることができる。このキーは、オブジェクトｂ５１０が作成される場合に確立される。しかし、図５の場合、参照スキームには２つのフィールドが含まれる。第１のフィールド５１２は、オブジェクトａ５０６からオブジェクトｂ５１０へポイントするハードワイヤードアドレスを含む。このフィールドはａ．ｆｏｏ．ｋｅｙと呼ばれる。第２のフィールド５１４は、オブジェクトｂ５１０をホストする最新の既知のＤＨＴノード（例えば、ノードｙ５０８）を識別する、ソフトステート参照を含む。このフィールドはａ．ｆｏｏ．ｈｏｓｔと呼ばれる。第２のフィールド５１４はこのように、オブジェクトｂ５１０にアクセスするためのルーティングショートカットとしての機能を果たす。

データオーバーレイのノードを複数のＤＨＴノードに渡って分散させることができるので、データオーバーレイ自体を分散データ構造と見なすことができる。データ構造は分散されるが、そのオブジェクトが過度に幅広く地理的に分散されないような方法で、データ構造を格納することが望ましい場合がある。これは、ａ５０６およびｂ５１０のキーを、互いに近くなるように生成することによって、達成することができる。これにより、Ｐ２Ｐ ＤＨＴシステムはこれらのキーをＰ２Ｐシステム内の同じノードに関連付けるようになり、あるいは、Ｐ２Ｐ ＤＨＴシステム内で密接に関係付けられたノード内で関連付けるようになる可能性がより高くなる。

データオーバーレイはまた、そのデータ構造内のポインタおよびオブジェクトを操作するために使用されたプリミティブの集まりをも提供する。具体的には、これらのプリミティブには、オブジェクトａから別のオブジェクトｂへの参照を確立するためのプロシージャ（ｓｅｔｒｅｆ）、オブジェクトａによってポイントされたオブジェクトを戻すためのプロシージャ（ｄｅｒｅｆ）、および、オブジェクトａによってポイントされたオブジェクトを削除するためのプロシージャ（ｄｅｌｅｔｅ）が含まれる。

データオーバーレイはＤＨＴシステムの上に実装されるので、そのプリミティブはＤＨＴのサービスを使用する。例えば、プリミティブは、オブジェクトをＤＨＴ論理空間に挿入するためのＤＨＴ＿ｉｎｓｅｒｔサービスを使用することができる。プリミティブは、所定のＤＨＴルーティングプロシージャを使用して、ＤＨＴ論理空間内のそのキーに基づいてオブジェクトを発見するためのＤＨＴ＿ｌｏｏｋｕｐサービスを使用することができる（ＣＨＯＲＤによって使用された指数関数的フィンガー（ｅｘｐｏｎｅｎｔｉａｌ ｆｉｎｇｅｒ）ルックアップ構造など）。プリミティブはまた、オブジェクトを格納するＤＨＴノードが前もって知られている場合にオブジェクトに直接アクセスするための、ＤＨＴ＿ｄｉｒｅｃｔプロシージャをも使用することができる。すなわち、ＤＨＴ＿ｄｉｒｅｃｔは、通常のＤＨＴ＿ｌｏｏｋｕｐルーティンブプロシージャをバイパスし、そのキーが与えられたオブジェクトをホストするノードを直接シークする。ＤＨＴ＿ｌｏｏｋｕｐおよびＤＨＴ＿ｉｎｓｅｒｔは、副次的効果として、ＤＨＴ内でターゲットオブジェクトを現在ホストするＤＨＴノードを戻す。

データオーバーレイを、その基礎となるＤＨＴサービスを使用して実装することができ、この実装は、それらのルーチンもまた上述のポインタをオブジェクトの属性として確立するようにオブジェクトを作成するために、何のライブラリルーチンが使用されるかを修正することによって行われる。ライブラリルーチンはまた、参照を設定するため、参照によってポイントされたオブジェクトを戻すため、および、参照によってポイントされたオブジェクトを削除するための、上述のプリミティブを収容するように修正されるべきでもある。

データオーバーレイをＤＨＴの上に構築することで、いくつかの利点がある。例えば、ＤＨＴは、ＤＨＴノードがＤＨＴ論理空間に追加され、そこから削除される（実際のマシンがＰ２Ｐシステムに結合すること、およびそこから離れることにそれぞれ関する）場合に、自己編成するように設計される。ＤＨＴはまた、ＤＨＴノードがＤＨＴ論理空間に追加され、そこから削除されることに応答して、それ自体を自動的に「修復」するようにも設計される（複数のノードの間でリンクを再確立すること、オブジェクトを複数のノードの間で転送することなどによるなど）。ＤＨＴの上に実装されるおかげで、データオーバーレイはまた、自己編成および自己修復の機能を採用することもできる。具体的には、データオーバーレイを、基礎となるＤＨＴと同じスケールで自己編成および自己修復するように構成することができる。

さらに、様々なアプリケーションをＰ２Ｐ ＤＨＴの上で実行するように移植し、これらのアプリケーションに、無限のストレージ空間の錯覚を与えることができる（例えば、ＤＨＴ論理空間のノードを包含する大きいサイズを有する、単一のリソースプールの印象を与える）。このストレージ空間は、Ｐ２Ｐ ＤＨＴシステム内で参加中のマシンのメモリヒープを幅広く含むことができる。ホストルーティングショートカット（例えば、ａ．ｆｏｏ．ｈｏｓｔ）は、データオーバーレイを利用するアプリケーションのパフォーマンスを、基礎となるＤＨＴシステムから独立させる。

ＤＨＴでは、大変大きい論理空間（例えば、１６０ビット）が仮定される。ノードはこの空間にランダムＩＤにより結合し、したがって、この空間を一様にパーティション化する。ＩＤを、例えば、ノードのＩＰアドレス上のＭＤ５ハッシュにすることができる。ノードの順序付きセットにより、ノードが担うゾーンを厳密に定義することができる。ｐおよびｑを、それぞれノードｘの先行物および後続物とする。ノードのゾーンの１つの定義は単に、その直接の先行ＩＤ（非包含的）のＩＤとそれ自体のＩＤの間の空間である。すなわち、ｚｏｎｅ（ｘ）＝（ＩＤ（ｐ），ＩＤ（ｘ））である。

図６は、ＤＨＴを論理空間として見る方法を示し、各ノードは論理空間内の論理位置を占有し、論理空間は分割される。したがって、各ノードは、論理空間をコヒーレントにするために、その隣接する近隣物の少数を覚えている必要がある。新しいマシンはランダムＩＤを選択し、ＤＨＴに結合する。新しいマシンは、ノードのいずれかに接触し、シークして位置を発見し、次いで論理空間をそれ自体のためにパーティション化し、ツリーが自己編成および自己修復するようにする。自己修復の態様は、マシンが離脱する場合に発生し、これは、マシンが離れることがその隣接した近隣マシンによって監視されるからであり、その離脱は、離脱するマシンがもはやその存在を示すための「ハートビート」通信を送信しない場合に検出される。新しい近隣マシンを次いで受け入れることができる。

図６をまた、ハッシングがどの程度一貫してゾーンをＤＨＴノードに割り当てるかを本質的に示す物として見なすこともでき、リング、ゾーンおよび基本ルーティングテーブルが使用される。リングをシステムのダイナミズムに対して強健にするために、各ノードは、一般にリーフセットとして知られる基礎的ルーティングテーブル内の両側に、ｒ個の近隣物を記録する。近隣物は、周期的通信を交換してそれらの存在を示し（例えば「ハートビート」）、ならびに、ノードが結合／離脱する場合、またはイベントが発生する場合にそれらのルーティングテーブルを更新する。図６で見られるこのベースリンクは、単純なＰ２Ｐ ＤＨＴである。ゾーンが通常のハッシュテーブル内のハッシュバケットであると想像する場合、リングはＤＨＴである。キーが空間内に与えられると、どのノードが担っているかを常に解決することができる。ルックアップパフォーマンスは、この単純なリング構造ではＯ（Ｎ）であり、Ｎはシステム内のノードの数である。

上記の概念に基づいて構築されたアルゴリズムは、いずれかのＯ（ｌｏｇＮ）または一定状態（すなわち、ルーティングテーブルエントリ）にもより、Ｏ（ｌｏｇＮ）パフォーマンスを達成する。代表的なシステムには、ＣＡＮパーティション化スキーム、ＣＨＯＲＤパーティション化スキームなどが含まれる。ＤＨＴのシステム全体は、通常はほぼＯ（ｌｏｇＮ）程度のオーバーヘッドにより自己編成する。また、ＤＨＴは、リソースおよび他のエンティティ（ＤＨＴ内に格納されたドキュメントなど）が共に存在する空間の視覚化でもある。

Ｂ．ＳＯＭＯツリー構造、データオーバーレイのインスタンス
上述のデータオーバーレイは、任意のデータ構造をＤＨＴの上に構築するためのフレームワークを提供する。データ構造には、ノードをデータ構造内で構成する複数のオブジェクトが含まれる。このデータ構造は、複数のノードを異なる方法で共にリンクすることによって、いかなる種類のトポロジを仮定することもできる。さらに、データ構造は、その個々のノードに割り当てられたオペレーションに応じて、異なるファンクションを実装することができる。以下のセクションでは、自己編成メタデータオーバーレイ、または略して「ＳＯＭＯ」と呼ばれるデータオーバーレイの例示的な例を説明した。

ＳＯＭＯデータ構造は、ツリー構造のトポロジを仮定するように構築される。ＳＯＭＯツリー構造はルートノードを有する。ルートノードは１つまたは複数の子を有することができ、これらの子は、それら自体のそれぞれの子を有することができる。ＳＯＭＯツリー構造の終端ノードは、リーフノードと呼ばれる。リーフノードは、Ｐ２Ｐ ＤＨＴシステムのＤＨＴ論理空間内の各ＤＨＴノードに関連付けられる。

以下でより詳細に説明するように、ＳＯＭＯツリー構造の１つのファンクションは、メタデータをＤＨＴノードから抽出すること（最終的には、Ｐ２Ｐシステムを実装するマシンからデータを抽出することを含む）、および、このメタデータを、ＳＯＭＯツリーを通じてＳＯＭＯツリー構造のルートノードへ渡すことである。アプリケーションは次いでこのメタデータを読み取り、あるアクションを、このメタデータに基づいて実行することができる。（メタデータは一般に、Ｐ２Ｐシステムを備えるマシンのパフォーマンスに関する情報など、オペレーションがＰ２Ｐシステム内で実行されることに関連付けられたいかなる種類の情報をも指す）。ＳＯＭＯツリー構造を使用して、情報をＳＯＭＯツリー構造のルートノードからＤＨＴノード、およびＰ２Ｐシステム内の関連付けられたマシンへと配布することもできる。したがって、一般的に言えば、ＳＯＭＯツリー構造は、データ収集（例えば、集約）およびデータのブロードキャストの役割を果たすことができる。

図７は、基礎となるＤＨＴ論理空間７０４の上に構築される、例示的ＳＯＭＯツリー構造７０２を例示する。ＤＨＴ論理空間７０４は、例示的ゾーン７０６および例示的ゾーン７０８など、いくつかのゾーンにパーティション化される。各ゾーンには、例示的ＤＨＴノード７１０など、そのゾーンに関連付けられたＤＨＴノードが含まれる。ＤＨＴは、ＣＡＮパーティション化スキーム、ＣＨＯＲＤパーティション化スキーム、ＰＡＳＴＲＹパーティション化スキーム、または他のいかなる種類のＤＨＴパーティション化スキームによっても提供される例示的技術など、いずれかの技術に従ってＤＨＴ論理空間７０４をゾーンにパーティション化することができる。例えば、ＣＨＯＲＤパーティション化スキームを使用して、ＤＨＴ論理空間７０４を、その周囲の様々なロケーションに分散された複数のノードを有するリングとして定義することができ、ゾーンは、リング上の近隣の隣接ＤＨＴノードを分離する範囲に対応することができる。

ＳＯＭＯツリー構造７０２には１つまたは複数のノードが含まれ、これらのノードはここで「ＳＯＭＯノード」と称されて、ＤＨＴノードとは区別される。各ＳＯＭＯノードは記号ｓによって表される。図７の例示的ＳＯＭＯツリー構造７０２には、ＳＯＭＯノードｓ７１２〜７２６が含まれる。ノードｓ７１２〜７２６は、逆のツリー形状を形成する。すなわち、ルートノード７１２は子ノード７１４および子ノード７１６に分岐する。これらの子ノードはそれら自体のそれぞれの子ノードを有することができ、例えば、子ノード７１４は子ノード７１８および子ノード７２０を含む。例示および考察を実施するために、例示的ＳＯＭＯツリー構造７０２の構造全体を図７で簡略するが、ＳＯＭＯツリー構造７０２は最終的には、ＤＨＴ論理空間７０４内で対応するＤＨＴノード内に置かれたリーフノード（例えば、リーフノード７２２、７２４、７２６）で終端する。一般に、ＳＯＭＯツリー構造７０２内の複数のＳＯＭＯノードの間のリンクを図７で、ＳＯＭＯノードを共に接続する点線によって例示し、これらのリンクを、上記の「データオーバーレイ」のセクションで説明した参照スキームを使用して実施することができる。

各ＳＯＭＯノードｓは、それに関連付けられたゾーンを有する。例えば、ルートのＳＯＭＯノード７１２には、ＤＨＴ論理空間７０４全体に及ぶゾーン７２８が含まれる。子ノード７１６には、ルートノード７１２のゾーン７２８の半分に及ぶゾーン７３０が含まれる。ＳＯＭＯツリー構造７０２内でより深いもう１つの子ノード７２０は、ルートノード７１２のゾーン７２８の４分の１であるゾーン７３２を有する。したがって、ＳＯＭＯツリー構造７０２の階層に追加された連続するノードｓは結果として、ルートノード７１２のゾーン７２８の進行的なより細かいパーティション化を生じる。また、ＳＯＭＯツリー構造７０２の階層は、空間７０４のより細かい（すなわち、より密度の高い）パーティション化を示す、ＤＨＴ論理空間７０４のこれらの領域について「より高く」増大する。一般に、図７は、ＳＯＭＯノードの各ゾーンの長さに及ぶ水平の矢印によって、個々のＳＯＭＯノードに関連付けられたゾーンを表す。特定のＳＯＭＯノードｓをホストするＤＨＴノードは、ＤＨＴ＿ｈｏｓｔ（ｓ）と表現される。

上述のように、Ｐ２Ｐリソースプールを完成するために、ＤＨＴはシステム内モニタリングインフラストラクチャにより増補されるべきであり、これは、大規模システムでは外部モニタリングサービスに依拠することが非実用的であるからである。このようなインフラストラクチャは少数の重要なプロパティを満たさなければならず、すなわち、（１）ホスト側ＤＨＴと同じスケールで自己編成であること、（２）完全に分散され、自己修復であること、および（３）収集および配布されたメタデータに関して可能な限り正確であることである。本明細書で提案するＳＯＭＯは、後述のようにボトムアップから構築される。

モニタリングインフラストラクチャは、いくつかのトポロジを取ることができる。リソースプールのために、最も重要な機能性の１つは集約である。したがって、ＳＯＭＯは、そのリーフが各ＤＨＴノード内に置かれるｋの次数（ｄｅｇｒｅｅ）のツリーである。情報は底部から収集され、ルートに向かって伝搬する。したがって、ＳＯＭＯを、リーフからルートへの「収束キャスト（ｃｏｎｖｅｒｇｅ ｃａｓｔ）」を行うこと、および次いで（オプショナルで）リーフに再度戻るように下がってブロードキャストすることとして考えることができる。収集および配布段階は、Ｏ（ｌｏｇ_ｋＮ）が境界であり、Ｎはオブジェクトの総数である。ＳＯＭＯの各オペレーションはわずかｋ＋１個の対話を含み、これを完全に分散させる。ソフトステートの原理を使用することによって、データをＯ（ｌｏｇ_ｋＮ）時間内で再生成することができる。ＳＯＭＯツリーは、同じ時間境界内で自己編成および自己修復する。ある意味では、ＳＯＭＯを、反応的な「ニュース放送」と考えることができ、その構成および処理はすべてのノードによって共有される。オンラインのグローバルな「ニュース」は、リソースプールの錯覚を作成する物である。

Ｂ．１ ＳＯＭＯの構築
ＳＯＭＯの中心の考えは、複数の個々のマシンの各々と連携してそれらを階層に構成するのではなく、ツリーが論理空間内で最初に「描かれ」、次いで論理ツリーから実際のマシンへのマップが作成されることである。

上述のように、データオーバーレイは、基礎となるＤＨＴで行われた動的で監視されていない修正に応じて増大および縮小することができる。ＳＯＭＯツリー構造７０２はデータオーバーレイのインスタンスであるので、これは、ＳＯＭＯツリー構造７０２もまた、基礎となるＤＨＴに行われた修正に応答して増大および縮小する能力を有することを意味する。また、ＳＯＭＯツリー構造は、その基礎となるＤＨＴと同様に、基礎となるＤＨＴの修正に対抗するようにそれ自体を修復する能力を有する。以下のサブセクションでは、ＳＯＭＯツリー構造７０２がその基礎となるＤＨＴにおける変更に応答して発展する方法を説明する。

Ｂ．２ 論理ツリーの構築
論理ツリーは、Ｐ２Ｐプール内のすべてのマシンが完全に分散および自動の方法で階層に編成することを助ける、参照フレームワークの機能を果たす。論理ツリーは仮想ノードのセットから構成され、各仮想ノードは図８ａのようなキーを有し、これもまた、１次元のＤＨＴ論理空間内のその位置を決定する。

ツリーを構築する第１の不変条件は、各仮想ノードが空間の一部を所有することであり、仮想ノードのキーは、それが所有する部分空間の中心である。ＤＨＴ論理空間が［０，１］であると仮定すると、ルート仮想ノードのキーは０．５である。次いで、ルート仮想ノードの空間（この時点で論理空間全体）はｋ個の部分空間に均等に分割され、各部分空間はレベル１で仮想ノードによってカバーされる。この分割プロセスを再帰的に適用して、論理ツリーが構築される。したがって、レベルｉは合計ｋ^ｉ個の仮想ノードを含み、各仮想ノードは１／ｋ^ｉのサイズの部分空間を所有する。具体的には、レベルｉのｊ番目（０≦ｊ＜２^ｉ）の仮想ノードは、［ｊ／ｋ^ｉ，（ｊ＋１）／ｋ^ｉ］の空間を所有し、（２ｊ＋１）／２ｋ^ｉでキーとされ／位置付けられ、「ｋ」は次数であり、「ｉ」はレベルである。したがって、ボトムアップＳＯＭＯツリー構造を構築するための例示的プロシージャが図８ａ〜８ｃで見られる。

Ｂ．３ 物理ツリーへのマッピング
物理ツリーは、Ｐ２Ｐ環境内の各マシンがその親マシンを発見する場合に構築される。これを、上記で構築された論理ツリーを活用することによって、完全に分散された方法で実施することができる。すべてのマシンが論理ツリーの知識全体を有するので、レベル順ツリートラバーサルアルゴリズムを使用して、各マシンはそのゾーンに入る最高の仮想ノードを選択する。この仮想ノードは、最終物理ツリー内でこのマシンを表現し、したがってこの仮想ノードを、マシンｘのための代表ノードまたはｒｅｐｒｅ（ｘ）と呼ぶことができる。論理ツリーの決定性は、ｘがｒｅｐｒｅ（ｘ）の親仮想ノードのキーを計算することができることを意味する。ＤＨＴルックアップを使用して、ｘは、図８ｂに示すように、そのキーをホストするマシンｙを発見し、ｙへの接続を確立する。あらゆるマシンは同じプロシージャを、純粋にローカルの知識（ゾーンおよび決定論的論理ツリートポロジ）により実行する。すべての子と親の接続は、論理キーのペアによって識別され、すなわち、子マシンに位置する代表仮想ノード、および、親マシンに位置する対応する親仮想ノードである。この接続はハートビートを使用して維持され、上記の不変条件は常に保たれる。例えば、新しい近隣物が結合するためにｘのゾーンが分割する場合、ｘは、その親側のポイントがもはやそのゾーンに属さないすべての接続を切るようになる。このポイントで、接続の他方の側のマシンは、以前に概説した同じプロシージャの実行によってそれらの親マシンを再確立するようになり、それによりトポロジは自己修復し、この一実施例は、図９ａ〜９ｃに示す例示的プロシージャによって見られる。

前述のプロシージャを、ＤＨＴの論理空間へのマシンのマッピングとして理解することができる。各マシンは、１つまたは複数のツリーノードゾーンに対応する。各マシンはその代表ノードとして、それに対応する１つまたは複数のツリーノードゾーンから、最大サイズのツリーノードゾーンに対応するツリーノードを選択する。各代表ノードはその親ノードとして、より大きいサイズを有する隣接ツリーノードゾーンのための代表ノードである、もう１つの代表ノードを選択する。ルートノードを含む、代表および親ノードの選択のための例示的プロシージャは、図８ａ〜８ｃで見られる。図７のように、ツリーノードゾーンのサイズは、ツリーのレベルが増すことにより減少し、第１のレベルは、ＤＨＴの論理空間の全体の範囲に対応するツリーノードゾーンを有するルートノードのレベルである。

前述のプロシージャは、完全に分散された方法で、物理マシンをツリーに編成する。さらに、高い確率で、ツリーはｋ次数および平衡である。代表仮想ノードの定義は、マシンのゾーンに入る最高仮想ノードであることである。親仮想ノードがある他のマシン上に存在するので、あらゆるマシンが接続される。結果として生じるグラフはいかなるループも有しておらず、これは、ループが代表仮想ノードの定義に違反するようになるからである。したがって、このグラフはツリーでなければならない。論理ツリートポロジは決定論的であり、マシンが必要とする他の入力は、ＤＨＴ空間内のそれ自体のゾーンのみである。このように、ツリー構築は完全に分散される。論理ツリーはｋ次数の平衡ツリーである。物理ツリーもまたｋ次数および平衡であるかどうかは、主として、ゾーン分布によって決定される。ＤＨＴ内のマシンのＩＤはランダムに生成されるので、高い確率で、結果として生じるツリーはｋ次数および平衡である。

ＳＯＭＯはメンバシップの変化に自動的に、最小限のオーバーヘッドにより対処することができ、これは、各接続が論理ポイントのペア、すなわち、代表仮想ノードでありそのＤＨＴゾーンによって決定される第１のポイント、および、第１のポイントが与えられると同じく決定的である第２のポイントによって、決定されるからである。したがって、この不変条件が保たれる限り、メンバシップ変更がある場合は常にトポロジを再確立することができる。結果として、図９ａ〜９ｃのように、ＳＯＭＯツリーは、新しいメンバがプールに結合する場合に増大し、ピアが離脱する場合に縮小する。したがって、図９ａ〜９ｃでは、ボトムアップＳＯＭＯツリー構造を修復するための例示的プロシージャが見られる。

大部分の機能を有するマシンを論理ツリーの上に配置することが望ましい場合、ノードＩＤを、ランダムに生成される以外となるように変更することができる。次いで、上向きのマージ−ソートがＳＯＭＯを通じて行われて、最も能力のあるノードが識別される。このノードは次いでそのＩＤを、ＳＯＭＯのルート論理ポイント（すなわち、空間全体［０，１］の０．５）を現在所有するノードと交換し、これは効果的に、他のいかなるピアをも妨げることなく、ルートの機能を果たすマシンを変更する。この自己最適化プロパティは、論理空間内で最初に動作することによって可能にされる。

Ｃ．メタデータ集約および配布
ＳＯＭＯは、インフラストラクチャとして、どのデータが収集されるべきであるかにおいて強要せず、収集されたデータを処理するために呼び出されるオペレーションにおいても強要しない。リソースプールを構築するために、各マシンは単にそのリソースメトリックスを収集し、そのリソースメトリックスを、その子ノードから受信した物と組み合わせ、次いでこれらをその親ノードにマージする。渡されるデータはソフトステートであるべきである。また、最適化として、レポートを連続レポートの「差分」の方法にすることができる。

ＳＯＭＯのパフォーマンスは物理ツリーの高さによって決定され、物理ツリーの高さは、論理ツリーのパラメータ（すなわち、ｋ）および論理空間内のＤＨＴノードの分散によって決定される。ノードＩＤはランダムなので、物理ツリーの高さはＯ（ｌｏｇ_ｋ／Ｎ）である。したがって、データレポート間隔Ｔが与えられると、情報はＳＯＭＯから収集され、ｌｏｇ_ｋＮ・Ｔの最大遅延により、そのルートを離れ、そのルートへ流れる。この境界は、ＳＯＭＯの階層の間の流れが完全に非同期である場合に導出される。上方のＳＯＭＯノードによるレポートのためのコールが即時に、それらの子の類似のアクションをトリガする場合、レイテンシをＴ＋ｔ_ｈｏｐ・ｌｏｇ_ｋＮに低減することができ、ｔ_ｈｏｐは、ホスト側ＤＨＴ内のトリップの平均レイテンシである。非同期の流れはｌｏｇ_ｋＮ・Ｔのレイテンシ境界を有するのに対して、同期バージョンは実際にはＴ（例えば、５分）によって境界されるようになる。Ｏ（ｔ_ｈｏｐ・ｌｏｇ_ｋＮ）は、絶対下界であることに留意されたい。２Ｍ個のノードおよびｋ＝８およびＤＨＴホップにつき２００ｍｓの通常レイテンシでは、ＳＯＭＯルートは、１．６ｓのラグを有するグローバルビューを有するようになる。

Ｃ．１ ＳＯＭＯツリー構造の適用
上述のように、ＳＯＭＯツリー構造７０２の１つの例示的使用は、Ｐ２Ｐシステム内で、ＤＨＴ論理空間７０４によって表現される物理マシンから情報を収集することである。ＳＯＭＯツリー構造７０２のもう１つの例示的使用は、情報をこれらの物理マシンに配布することである。集められた情報はメタデータである可能性がある。メタデータは、その物理マシンのビヘイビアを反映する情報など、Ｐ２Ｐシステムのオペレーションに関する情報を記述する。物理マシンに配布される情報は、物理マシンのオペレーションを管理することができる命令を表すことができる。したがって、ＳＯＭＯメカニズムを、ＳＯＭＯリーフノードからＳＯＭＯルートノードへの収束キャストを実行して、データ収集を提供し、次いで、マルチキャストをＳＯＭＯリーフノードかへ戻るように下がって実行して、データ配布を提供することとして解釈することができる。

図１０ａは、リソースをプールするＤＨＴの能力をＳＯＭＯと組み合わせることにより、集合的に、ＤＨＴおよびＳＯＭＯからなるＰ２Ｐリソースプールを作成することを示す。要約として、ＤＨＴは、コンテンツを共有する意味で使用されないが、管理オーバーヘッドがほとんどまたはまったくなく、スケーラビリティのボトルネックもなく、大量のリソースを共にプールする効率的な方法として使用される。ＳＯＭＯは、ＤＨＴ上で階層化された自己編成「ニュース放送」階層である。Ｏ（ｌｏｇＮ）時間におけるリソース状況の集約は次いで、単一のリソースプールの錯覚を作成する。図１０ａで見られるプロシージャは、リソースペアワイズの登録、統計の収集、収集された統計をスナップショットに集約すること、および、結果として生じる動的データベースをアプリケーションによってクエリすることができることを保証することを示す。Ｐ２Ｐリソースのスケールおよび構成は、あらゆる層が完全に自己編成、自己スケーリングおよび自己修復であり、管理オーバーヘッドがほとんどなくなるようにすることを必要とする。

例えば、図１０ｂは、ＳＯＭＯツリー構造１００４が、Ｐ２Ｐシステム内の物理マシン１００６から、ＤＨＴ論理空間１００８を介して情報を収集するために使用されている、シナリオ１００２を表す。具体的には、リーフＳＯＭＯノードは、必要とされた情報をそれらのホスト側ＤＨＴノードから検索する。（副次的効果として、このプロシージャはまた、そのホスト側ＤＨＴノードがクラッシュしているために子ＳＯＭＯノードが消えている場合、子ＳＯＭＯノードを再起動することもできる）。１つまたは複数のアプリケーション１０１０は、この収集オペレーションを、いずれかの定義された目的のために（パフォーマンスのモニタリング、すなわちＰ２Ｐシステムを備える物理インフラストラクチャの様々な負荷および能力に関する情報を収集するためなど）呼び出すことができる。

具体的には、図１０ｂは、情報を収集するためのＳＯＭＯツリー構造１００４の構成を、各ＳＯＭＯノードからその対応する親ＳＯＭＯノードへと上方を指す矢印を有する線を示すことによって示す。このように、情報は、ＳＯＭＯツリー構造１００４をそのリーフＳＯＭＯノードからそのルートＳＯＭＯノードへと上に向かって通り抜ける。アプリケーション１０１０は、Ｐ２Ｐシステム全体からの情報を選び取る、ルートＳＯＭＯノードからの完全レポートを抽出することができる。このレポートは、生の編成されていないデータを含むことができる。代替として、ＳＯＭＯノードがそれらの対応する親ＳＯＭＯノード上へ収集する情報を渡す前にこのファンクションを実行するように構成されているならば、このレポートは、マージおよびソートされたデータを含むことができる。マージおよびソートを実行するように「ｏｐ」メンバを構成することによって、このタスクを実行するように、ＳＯＭＯノードを構成することができる。例えば、メンバｏｐは、特定のＳＯＭＯノードが（データ収集またはデータ配布モードのいずれかで）それを通過する情報において実行することができる、オペレーションを定義することができる。例えば図７を参照することにより、ｏｐは、マージ−ソートオペレーションが、ＳＯＭＯツリー構造７０２を使用して情報を収集する過程で実行されるべきであると、規定することができる。ｏｐメンバの包含に基づいて、ＳＯＭＯツリー構造７０２はいかなる機能性をも分散および並列の方法で実行することができる。したがって、ＳＯＭＯツリー構造７０２をまた、分散並列処理フレームワークを提供していかなる種類の機能性をも実装するためのメカニズムと見なすこともできる。これは単に１つの例示的実施例である。ＳＯＭＯノードは、様々な算術演算など、他のオペレーションを、情報がルートＳＯＭＯノードに行く途中でＳＯＭＯノードを通過する場合にこの情報において実行することができる。

以下の擬似コードは、ＳＯＭＯツリー構造１００４を使用して情報を収集するための１つの技術、すなわち、擬似コード：ＳＯＭＯ収集プロシージャを提供する。

システムメタデータを収集するために、ＳＯＭＯノードは、それらの各子からのレポートを要求することによって、周期的に上記のプロシージャを実行することができる。収集プロシージャを、ＳＯＭＯツリー構造１００４から特定の情報を抽出するように調整することができる。具体的には、ＳＯＭＯツリー構造１００４の階層的特性は、所与の論理ＤＨＴ空間領域に関連する情報を発見するために複合範囲クエリの使用を実施する。例えば、ｋが２であり、ＤＨＴ論理空間の最初の４分の１の状況レポートを検索することが望まれる場合、アプリケーション１０１０は、第２のレベルのＳＯＭＯツリー構造１００４の左の子ＳＯＭＯノード１０１２からレポートを得ることのみが必要である。もう１つの有用な実施態様は、ＳＯＭＯノードでクエリを登録することを含み、これはＳＯＭＯメカニズムをパブリッシュ−サブスクライブ（「ｐｕｂ−ｓｕｂ」）インフラストラクチャに本質的に変換する。

図１０ｂはまた、ＳＯＭＯツリー構造１００４が、Ｐ２Ｐシステム内の物理マシン１００６へ、ＤＨＴ論理空間１００８を介して情報を配布するために使用されている、シナリオ１００２をも示す。１つまたは複数のアプリケーション１０１０は、この配布オペレーションを、いかなる定義された目的のため（命令を物理マシン１００６に配布するためなど）にも呼び出すことができる。情報を配布するためのＳＯＭＯツリー構造１００４の構成は、図１０ｂにおいて、親ＳＯＭＯノードからそれらの各子ＳＯＭＯノードへと下方を指す矢印を有する線を示すことによって表される。このように、情報は、ＳＯＭＯツリー構造１００４をそのルートＳＯＭＯノードからそのリーフＳＯＭＯノードへと下に伝搬する。情報は、ＳＯＭＯノードによる修正なしに、ＳＯＭＯツリー構造１００４のブランチを通じて伝播されることが可能である。代替として、それらのｏｐメンバに基づいて、ＳＯＭＯノードは、情報がそれらの関連付けられた子ＳＯＭＯノードに渡される前に、いかなる種類のオペレーションをもその情報において実行することができる。また、データ収集の場合について説明したように、ＳＯＭＯツリー構造１００４の選択されたブランチのみを含むことによって、ＤＨＴ論理空間１００８の部分のみに情報を配布することが可能である。

Ｄ．アプリケーションレベルマルチキャスティング（ＡＬＭ）
データオーバーレイおよびＳＯＭＯツリー構造の追加の応用例および変形形態を実施することができる。例えば、１つの例示的実施態様では、ＳＯＭＯツリー構造から収集されるメタデータに作用するアルゴリズム、または、ＳＯＭＯツリー構造を通じて下方に伝搬される情報を生成するアルゴリズムを提供することによって、ＳＯＭＯメカニズムをアプリケーションレベルマルチキャスティング（ＡＬＭ）と共に使用することができる。適切な機能性を、図１０ｂに示すアプリケーション１０１０において提供することによって、ＡＬＭ技術を実施することができる。例として、図１１ａ〜１１ｂは、ＡＬＭのための概略的配置を示す。

Ｐ２Ｐリソースプールの可用性は、最適化の可能性を提供する。図１１ａ〜１１ｂに示すように、そうでない場合はアイドルであるが適切なヘルプ側ピアが識別される場合、最適化を行うことができる。適切なピアが識別された後、このピアを、よりよいパフォーマンスを有するトポロジに統合することができる。このように、図１１ｂは、図１１ａで見られた配置の改良を示す。改良は、ヘルパーノードをリソースプールで使用することによって行われる。図１１ａ〜１１ｂでは、円は、アプリケーションレベルマルチキャスティングセッションのオリジナルメンバを表し、四角は、大きい次数を有する使用可能なピアを表す。最適化をマーケット需要システムに向けて、最もリソースを必要とするタスクが、ピアツーピアシステム内で最もリソースを利用可能なマシンによって実行されるようにすることができる。

Ｄ．１ ＡＬＭのためのリソースメトリックスの生成
多数のＰ２Ｐアプリケーションでは、リソース統計には、ＣＰＵ負荷およびネットワークアクティビティのみではなく、マシンからローカルで導出することができないより複雑なリソース統計もが含まれる。その一例は、ＡＬＭである。セッションをスケジュールすることが望ましく、潜在的なヘルプ側ピアの大きいリストが、ＳＯＭＯをクエリすることによって獲得されていると仮定すると、すぐ近くであり、適切な帯域幅をも有する、１つのピアが選択されなければならない。ピアのＩＰアドレスのみが与えられる場合、これらに渡ってｐｉｎｇしてそれらの近接を発見するプロセスは、時間がかかり、間違いが発生しやすい。以下の考察では、この問題を緩和する物として、ＩＰアドレスおよび帯域幅のメトリックスに焦点を合わせる。論理空間の完全性を維持する複数のＤＨＴノードの間の対話を活用することによって、これらの属性をどのように生成することができるかを説明する。

Ｄ．２ ノード座標推定
座標ベースのレイテンシ推定値ｌａｔｅｎｃｙ（ｘ，ｙ）を発見するために、ｄｉｓｔａｎｃｅ（ｃｏｏｒｄ（ｘ），ｃｏｏｒｄ（ｙ））を計算することは十分であり、ｃｏｏｒｄはｄ次元のユークリッド空間内のネットワーク座標である。各ノードは、ＤＨＴ空間を集合的に維持するために、そのリーフセットノードとのそのハートビートを提供しなければならない。各ノードがランダムに、そのリーフセット内のノードからのハートビートメッセージに肯定応答することを選択する場合、経時的に各ノードは、そのリーフセット近隣物への測定遅延ベクトルｄ_ｍを有するようになる。ハートビートメッセージでは、各ノードはまたその現在座標をもレポートする。したがって、予測遅延ベクトルｄ_ｐもローカルで入手可能である。ノードｘはそれ自体の座標を、滑降シンプレックスアルゴリズムを実行すること、および、関数

を最小化することによって、更新する。この最適化はローカルで行われ、ｘ自体の座標を更新するだけであり、これは後続のハートビートにおいてｘのリーフセット近隣物に分散されるようになる。このプロシージャはすべてのノードによって周期的に実行され、ノード座標、ならびに測定および予測遅延ベクトルは、継続的に更新されている。

Ｄ．３ ボトルネック帯域幅推定
ピアのネットワーク帯域幅は、ボトルネック帯域幅とスループットの間に相関がある点において、Ｐ２Ｐリソースプールの上で実行する多数のアプリケーションにとってもう１つの重要なメトリックである。したがって、ボトルネック帯域幅は、スループットのための予測子としての機能を果たすことができる。ボトルネックリンクが最後のホップ内にあると仮定することができる。各ノードについて、そのアップストリームボトルネック帯域幅は、ノードからそのリーフセットメンバへの測定ボトルネック帯域幅の最大値として推定され、ノードのアップリンク帯域幅、およびリーフセットノードのダウンリンク帯域幅によって制限される。基本的な考えは、ノードのアップリンク帯域幅より大きいダウンリンク帯域幅を有する１つの近隣物がある場合、この推定値は正確であるということである。そのため、より多くのリーフセットノードでは、正確な推定値を得る可能性はよりよくなる。同じ理由のため、ノードのダウンストリームボトルネック帯域幅は、そのリーフセットノードからノード自体への測定ボトルネック帯域幅の最大値として推定される。

ボトルネック帯域幅の測定は、よく理解されている。例えば、パケットペア技術では、サイズＳの２つのパケットが連続してソースノードから送信される。受信側は、中間における時間分散Ｔを測定し、ソースからのボトルネック帯域幅をＳ／Ｔとして推定する。

ハートビートを介したリーフセットノードの協調は、パケットペア技術が自然に配置されることを可能にする。周期的に、ノードｘは、近隣物ｙに２つの連続ハートビートメッセージを連続して送信して、それらのサイズが十分に大きい（例えば１．５ＫＢ）であるように各々を埋め込むように選択する。「ｙ」はここで、ｘからｙ自体へのパス上のボトルネック帯域幅の推定値を有する。この値は、次のハートビートにおいてｘに結合されるようになる。同様に、ｙはｘと同じプロービングを行う。ｘが十分な測定帯域幅をそのリーフセットメンバから収集した後、ｘはここでそれ自体のボトルネック帯域幅を上記のように推定することができる。

Ｄ．４ Ｐ２Ｐリソースプール内のＡＬＭセッションのスケジューリング
ここで、Ｐ２Ｐリソースプールを複数の同時ＡＬＭセッションのために最適に利用する方法を明示する。最終目標は、アクティブセッションが、リソースプール内のすべての使用可能で適切なピアにより最適なパフォーマンスを達成することである。セッションのパフォーマンスメトリックスは、あるＱｏＳ定義によって決定される。また、より高い優先順位のセッションは比例的に、プールされたリソースのより大きいシェアを獲得するべきである。ここで、ＱｏＳがしばしば要件（例えば、ビデオ会議）であると考えられる、小規模から中規模のセッションサイズに重要性が置かれる。また、静的なメンバシップがあり、参加者の元のセットが所与のセッション「ｓ」についてＭとして示されるとも仮定されるが、アルゴリズムを、動的なメンバシップにも対処するように拡張することができる。

セッションのタスクマネージャは、ＡＬＭのトポロジをプランニングするための、修正された発見的アルゴリズムを実行することを担う。プール内の予備リソースを利用するために、タスクマネージャはＳＯＭＯをクエリして、候補のリストを得る。このリストの項目には、リソース可用性のみが含まれるのではなく、そのネットワーク座標およびその帯域幅もが含まれる。プランが出される場合、タスクマネージャは外部に出て、ヘルプ側ピアに接触してそれらの使用を予約する。競合するタスクは、純粋にそれらの各プロパティによってそれらの競合を解決するようになる。

ＡＬＭでは、帯域幅ボトルネック、最大レイテンシ、またはレイテンシの変化のような、最適化のためのいくつかの異なる基準が存在する。すべてのメンバの最大レイテンシは本明細書で、ツリー構築アルゴリズムの主な目的として使用され、これは、最大レイテンシがエンドユーザの知覚に大きく影響を与える可能性があるからである。各ノードは、処理することができる通信セッションの数における境界を有し、この境界は本明細書で「次数」と呼ばれる。これは、エンドシステムの制限されたアクセス帯域幅または作業負荷による可能性がある。最適化は、最もリソースを必要とするタスクがピアツーピアシステム内で最もリソースを利用可能なマシンによってサービスされるように、実行される。

１つの所与のセッションのためのＱｏＳのための定義を、以下のように形式的に述べることができる。

定義１．次数有界最小高ツリー問題（Ｄｅｇｒｅｅ−ｂｏｕｎｄｅｄ，ｍｉｎｉｍａｌ ｈｅｉｇｈｔ ｔｒｅｅ ｐｒｏｂｌｅｍ）（ＤＢ−ＭＨＴ）。無向完全グラフＧ（Ｖ，Ｅ）、各ｖ∈Ｖについての次数境界ｄ_{ｂｏｕｎｄ}（ｖ）、各エッジｅ∈Ｅについてのレイテンシ関数ｌ（ｅ）が与えられる。各ｖ∈Ｔについてｖの次数がｄ（ｖ）≦ｄ_{ｂｏｕｎｄ}（ｖ）を満たし、Ｔの高さ（ルートからの集約されたレイテンシとして測定される）が最小化されるように、ＧのスパニングツリーＴを発見する。

リソースプールを使用すると、ＱｏＳのための上記の定義を拡張することができる。ヘルパーノードＨの拡張セットがグラフに追加され、この目的は、最小量のヘルパーノードを追加することによって、Ｈを使用することなく導出された最適のプランに対して最適な解を達成することである。

Ｄ．５ 単一のＡＬＭセッションのスケジューリング
単一のＡＬＭセッションをスケジューリングするための方法を、リソースプールを利用する場合に単一のＡＬＭセッションを最適化するためのアルゴリズムとして考察する。このアルゴリズムはＯ（Ｎ^３）パフォーマンス境界を有し、何百ものノードのための解を１秒未満で生成することができる。例として、破線のボックス内のコードなしで、以下の表Ａを参照されたい。このアルゴリズムは本明細書で「ＡＭＣａｓｔ」と呼ばれ、最初にルートで開始して、これを現在の解のセットに追加する。次に、ノードの残りの最小高が、次数制約を受ける、解のセット内でそれらの最も近い潜在的な親を発見することによって、計算される。これは、最低高を有するノードを解に吸収することによって、ループバックする。すべてのノードが最終的に、結果として生じるツリーに含まれるまで、このプロセスは継続する。それにより開始するべき最良の可能なツリーが得られることを保証するために、アルゴリズムを、さらなる調節または調整手段のセットにより増補することができる。例えば、グローバルに最適なアルゴリズムに近づけるための調節または調整手段には、発見的移動（ｈｅｕｒｉｓｔｉｃ ｍｏｖｅｓ）のセットによりツリーを調節することが含まれる場合がある。これらの移動には、（ａ）最高ノードのための新しい親を発見すること、（ｂ）別のリーフノードを有する最高ノードをスワップすること、および（ｃ）そのルートが別のサブツリーを有する最高ノードの親である、サブツリーをスワップすることが含まれる。

有益なヘルパーノードの探索において、アルゴリズムには２つの考慮事項が含まれ、すなわち、（１）探索をトリガするための時間、および（２）追加を判断するための基準である。全体的なメカニズムは、以下の表Ａにおいて「Ｓｅｃｔｉｏｎ Ａ」のラベルが付けられたボックス内の擬似コードによって記述される。

表Ａ：

ｕを、ＡＭＣａｓｔアルゴリズムがまさに解に追加しようとしているノードとし、ｐａｒｅｎｔ（ｕ）をその親とする。ｐａｒｅｎｔ（ｕ）の空き次数が１に減らされる場合、追加のノードｈについての探索がトリガされる。このようなｈがリソースプール内に存在する場合、ｈはその代わりにｕの親となり、ｕを、元のｐａｒｅｎｔ（ｕ）の子になるように置き換える。異なるバージョンは、ｈの選択基準によってのみ変わるが、このクラスの最適化をクリティカルノードアルゴリズムと称することができる。「クリティカル」はここで、特定のノードについて、これが元のアルゴリズムを改良するための最後の機会であることを意味する。

異なるアルゴリズムを使用してｈを探索することができる。アルゴリズムの最初の変形形態は、親ノードに最も近く、適切な次数（例えば、「４」を使用することができる）を有する追加のノードを発見することである。ｌ（ａ，ｂ）を、２つの任意のノードａおよびｂの間のレイテンシとする。以下のヒューリスティックは、表Ｂに示すようなさらによい結果を生じる。

表Ｂ：

ここで、ｖをｕの兄弟の１つにすることができる。この考えは、すべてのこのようなｖが潜在的にｈの将来の子となるので、ｌ（ｈ，ｐａｒｅｎｔ（ｕ））＋ｍａｘ（ｌ（ｈ，ｖ））は、ｈの結合の後に潜在的なツリーの高さに影響を及ぼす可能性が最も高いということである（条件１）。このようなヘルパーノードは適切な次数を有するべきである（条件２）。最後に、それらの次数が高いとしても遠く離れている「ジャンク」ノードを回避するために、半径Ｒを課し、ｈはｐａｒｅｎｔ（ｕ）から離れてＲ以内に位置しなければならない（条件３）。このプロシージャを実行するために必要な入力パラメータには、任意のペアの間のレイテンシ、ならびに各ノードの次数を計算することができるようなネットワーク座標が含まれる。これは、図１２のように、各ノードにそれらのネットワーク座標ならびに帯域幅制約をそれらのレポートにおいてＳＯＭＯにパブリッシュさせることによって、使用可能にされ、これは、スケジューラが使用中であるＳＯＭＯレポートの視覚化である。このように、各ノードは特定の負荷（使用可能なＣＰＵサイクル）、特定のメモリ能力（ＲＡＭ、ディスクスペース、キャッシュ）を有し、また、ノードがどこにあるか（ＩＰアドレス）、および、ノードが有する使用可能な帯域幅の量のような、あるネットワーク情報をも有する。図１０ａは、図１２のようなレポートなど、ＳＯＭＯレポートにおいて使用するためのデータの集まりを示す。

Ｄ．６ 複数のＡＬＭセッションの最適化
前のセクションでは、１つのＡＬＭセッションのためのスタンドアロンのスケジューリングアルゴリズムを説明したが、このセクションでは、複数のアクティブセッションにどのように対処するかを論じ、より高い優先順位のセッションに比例的により多いリソースが割り当てられ、リソースプールの利用は全体として最大化される。

すべてのセッションは、ランダムな時間に開始および終了する可能性がある。各セッションは、１と３の間の整数値の優先順位を有する。優先順位１のセッションは最高のクラスである。最大同時セッションの数は１０から６０までで変わり、各セッションは、サイズ２０の非重複メンバセットを有する。したがって、６０ものアクティブセッションがある場合、すべてのノードは少なくとも１つのセッションに属するようになる。すなわち、アクティブセッションの元のメンバの部分は、１７％から１００％に変わる。ヘルパーノードを考慮すると、セッションは通常、元のメンバより多くを使用する。また、より大きい次数を有するノードを、複数のセッションに含めることができる。

複数のＡＬＭセッションを最適化するためのこの手法の基礎となる原理は、よく組織化された社会に多少類似しており、グローバルでオンタイムの信頼された知識が使用可能である限り、それら自体のクレデンシャル（すなわち、それらの各優先順位）によりリソースを争うための各タスクから離れることが最善である場合がある。この純粋にマーケット主導型のモデルにより、いかなる種類のグローバルスケジューラの必要性もなしに、目的を実施することができる。

セッション内に含まれたノードで適切な優先順位を設定することは、特別な考慮事項を取る。協調Ｐ２Ｐ環境では、ノードが、それ自体をメンバとして含むジョブを実行する必要がある場合、そのジョブをそのノード内の最高優先順位にすることが公正である。したがって、優先順位Ｌを有するセッションｓでは、Ｍ内のノードのための最高優先順位（すなわち、１番目の優先順位）を有し、Ｌは他の場所にある（すなわち、Ｍの外側に位置するいずれかのヘルパーノードのため）。これは、各セッションを、ＡＭＣａｓｔ＋ａｄｊｕアルゴリズムに対応する下界を有して、実行することができることを保証する。上界は、ｓがシステム内の唯一のセッションであると仮定して得られる（すなわち、Ｌｅａｆｓｅｔ＋ａｄｊｕ）。

前述のように、ＡＬＭセッションのルートはタスクマネージャであり、ツリートポロジのプランニングおよびスケジューリングを実行する。各セッションはＬｅａｆｓｅｔ−ａｄｊｕｓｔｍｅｎｔアルゴリズムを使用して、それ自体で、ＳＯＭＯによって提供されたシステムリソース情報に基づいて、完全にスケジューリングする。優先順位Ｌを有するセッションでは、Ｌより低い優先順位を有するタスクによって占有されるいかなるリソースも、使用可能と見なされる。同様に、アクティブセッションがその現在のプランにおいてリソースを失う場合、スケジューリングを再度実行することが必要となる。各セッションはまた、スケジューリングを周期的に再実行して、最近解放されたリソースを使用したよりよいプランが現在のプランよりよいかどうかを検討し、そうである場合はよりよいプランに切り替えるようになる。

ＳＯＭＯがリソース情報を収集および配布して、各タスクマネージャのプランニングを助けるようにすることを実施するために、前述のように各ノードは、ネットワーク座標など、その情報をそのレポートにおいてＳＯＭＯにパブリッシュする。しかし、その次数は、アクティブセッションによって取られる優先順位に分割される。これは、以下の次数表Ｃにおける２つの例において要約される。

次数表Ｃ：

次数表Ｃで、２つのノードの次数表が示される。ｘの合計次数は４であり、セッションｓ４によって２つの次数が取られ、ｓ１２はもう１つの次数を取り、ｘには１つの空き次数が残る。他方ではｙは２つの次数のみを有し、その両方がセッションｓ５によって取られる。次数表は、ノードの次数のパーティションに影響を及ぼすスケジューリングが発生する場合は常に更新される。次数表は、前述のように、ＳＯＭＯを通じて収集され、いかなる実行中タスクにとってもクエリするために使用可能にされる。次数表Ｃは、マシンがそれ自体をＡＬＭセッションの異なるストリームの間でパーティション化して、帯域幅を分割することによっていくつかのことを同時に実行できるようにすることが、可能であることを示す。したがって、次数表Ｃは、いくつの合計次数を有することが可能であるか、および、異なるジョブの間で機能を分割して、異なる優先順位セッションとしてスケジュールすることができるようにすることによって、いくつの合計機能を有する場合があるかを示す。

アプリケーションレベルマルチキャスティング内により多くのセッションがあり、全体的なリソースが乏しくなる場合、パフォーマンスが低下する。しかし、より高い優先順位のタスクは、より低い優先順位のタスクよりもはるかによいパフォーマンスを維持することができる。また、より低い優先順位のタスクは、リソースが激しい競争下にある場合、より多くのヘルパーノードを失う。

Ｄ．７ ＡＬＭセッションを有するリソースプール
リソースプールを作成するために、適時の集約を保証するように階層構造が採用されることは必然的である。例えば、２レベルのアーキテクチャでは、ＩＰレベルのマルチキャスティングが使用されて１つのロケーション内で統計が収集され、次いで結果を中央サイトに集約することができる。本明細書で、ワイドエリアリソースプールを実現可能にするための要素を論じ、すなわち、（１）Ｐ２Ｐ ＤＨＴの自己編成能力の組合せ、および（２）システム内の自己スケーリングモニタリングインフラストラクチャである。

Ｄ．８ リソースプールを使用したＡＬＭの最適化
ＡＬＭは、Ｐ２Ｐ ＤＨＴのための有利なアプリケーションである。しかし、ＡＬＭを最適化するには、リソースプールが利用されるべきである。リソースプールが与えられると、最適化は、１つの単一のＡＬＭセッション、ならびに、無干渉のマーケット主導型の手法においては複数の同時ＡＬＭセッションの最適化からなることができる。しかし、ＡＬＭは、Ｐ２Ｐリソースプールのためのアプリケーションの１つでしかないことに留意されたい。それにもかかわらず、集中マッチメイキングメカニズムよりも分散される方法では、２ステップの手法が支持され、すなわち、（１）アプリケーションに特化したタスク毎のスケジューリング、および（２）複数のタスクの間で調整することによってマーケット主導型の公正競争と結合されることである。

Ｅ．１つのＰ２Ｐ参加者を実装するための例示的コンピュータ環境
上記のセクションＡで説明したデータオーバーレイは、複数のマシンに渡って、また場合によってはＰ２Ｐシステム内の他のインフラストラクチャに渡って広げることができる、データ構造である。したがって、Ｐ２Ｐシステム内の各参加者を、データオーバーレイの一部を実装することと見なすことができる。この効果を達成するために、各参加者は、データオーバーレイを作成するため、および、データオーバーレイと対話するために必要なコードおよびデータを格納することができる。このコードおよびデータを、各参加者の揮発性および／または不揮発性メモリ内に格納することができる（以下で説明する）。

例えば、図１３は、コンピュータ１３４２としての１つの例示的Ｐ２Ｐ参加者の高レベル図を示す。このコンピュータ１３４２は、汎用コンピュータまたはサーバタイプのコンピュータ、および関連付けられた表示デバイス１３８４に対応する。しかし、コンピュータ１３４２を、他の種類のコンピューティング機器を使用して実施することができる。例えば、図示しないが、コンピュータ１３４２には、ハンドヘルドまたはラップトップデバイス、セットトップボックス、メインフレームコンピュータなどが含まれる場合がある。

例示的コンピュータ１３４２を使用して、本明細書で説明したプロセスを実施することができる。コンピュータ１３４２には、１つまたは複数のプロセッサまたは処理装置１３４４、システムメモリ１３４６、および、システムメモリ１３４６を含む様々なシステムコンポーネントをプロセッサ１３４４に結合するバス１３４８が含まれる。コンピュータ１３４２内の１つまたは複数のストアを使用して、ＳＯＭＯツリー構造の一部など、データオーバーレイの一部を実装するために使用される、コードおよびデータを格納することができる。

バス１３４８は、いくつかのタイプのバス構造のいずれかの１つまたは複数を表し、これらのバス構造には、様々なバスアーキテクチャのいずれかを使用する、メモリバスまたはメモリコントローラ、周辺バス、ＡＧＰ、およびプロセッサまたはローカルバスが含まれる。システムメモリ１３４６には、読み取り専用メモリ（ＲＯＭ）１３５０およびランダムアクセスメモリ（ＲＡＭ）１３５２が含まれる。基本入出力システム（ＢＩＯＳ）１３５４は、起動中など、コンピュータ１３４２内の複数の要素の間で情報を転送する助けとなる基本ルーチンを含み、ＲＯＭ１３５０に格納される。

コンピュータ１３４２にはさらに、ハードディスク（図示せず）に対する読み書きを行うためのハードディスクドライブ１３５６、リムーバブル磁気ディスク１３６０に対する読み書きを行うための磁気ディスクドライブ１３５８、および、ＣＤ−ＲＯＭまたは他の光メディアなど、リムーバブル光ディスク１３６４に対する読み書きを行うための光ディスクドライブ１３６２が含まれる。ハードディスクドライブ１３５６、磁気ディスクドライブ１３５８、および光ディスクドライブ１３６２はバス１３４８に、ＳＣＳＩインターフェース１３６６またはある他の適切なインターフェースによって接続される。これらのドライブおよびそれらの関連付けられたコンピュータ可読メディアは、コンピュータ１３４２のためのコンピュータ可読命令、データ構造、プログラムモジュールおよび他のデータの不揮発性ストレージを提供する。本明細書で説明した例示的環境は、ハードディスク、リムーバブル磁気ディスク１３６０およびリムーバブル光ディスク１３６４を使用するが、磁気カセット、フラッシュメモリカード、デジタルビデオディスク、ランダムアクセスメモリ（ＲＡＭ）、読み取り専用メモリ（ＲＯＭ）など、コンピュータによってアクセス可能であるデータを格納することができる他のタイプのコンピュータ可読メディアもまた例示的オペレーティング環境内で使用することができることは、当業者には理解されよう。

いくつかのプログラムモジュールをハードディスク１３５６、磁気ディスク１３６０、光ディスク１３６４、ＲＯＭ１３５０またはＲＡＭ１３５２上で格納することができ、これらのプログラムモジュールには、オペレーティングシステム１３７０、１つまたは複数のアプリケーションプログラム１３７２（ウェブ要求トレースアプリケーション１４０など）、キャッシュ／他のプログラムモジュール１３７４およびプログラムデータ１３７６が含まれる。オペレーティングシステム１３７０には、本明細書で説明したウェブ要求イベントトレーシングツール（トレースインフラストラクチャ１４４など）が含まれる可能性がある。ユーザはコマンドおよび情報をコンピュータ１３４２へ、キーボード１３７８およびポインティングデバイス１３８０など、入力デバイスを通じて入力することができる。他の入力デバイス（図示せず）には、マイクロフォン、ジョイスティック、ゲームパッド、衛星放送受信アンテナ、スキャナなどが含まれる可能性がある。これらおよび他の入力デバイスは処理装置１３４４へ、バス１３４８に結合されるインターフェース１３８２を通じて接続される。モニタ１３８４または他のタイプの表示デバイスもまたバス１３４８へ、ビデオアダプタ１３８６などのインターフェースを介して接続される。モニタに加えて、パーソナルコンピュータには通常、スピーカおよびプリンタなど、他の周辺出力デバイス（図示せず）が含まれる。

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

ＬＡＮネットワーキング環境において使用する場合、コンピュータ１３４２はローカルネットワークへ、ネットワークインターフェースまたはアダプタ１３９４を通じて接続される。ＷＡＮネットワーキング環境において使用する場合、コンピュータ１３４２には通常、モデム１３９６、または、インターネットなどのワイドエリアネットワーク１３９２を介して通信を確立するための他の手段が含まれる。モデム１３９６は内部であっても外部であってもよく、バス１３４８へ、シリアルポートインターフェース１３６８を介して接続される。ネットワーク環境では、パーソナルコンピュータ１３４２に関連して示したプログラムモジュールまたはその一部を、リモートメモリストレージデバイスに格納することができる。図示のネットワーク接続は例示的であり、複数のコンピュータの間で通信リンクを確立する他の手段を使用することができることは理解されよう。

一般に、コンピュータ１３４２のデータプロセッサは、コンピュータの様々なコンピュータ可読ストレージメディア内で異なる時間に格納された命令を用いてプログラムされる。プログラムおよびオペレーティングシステムは通常、例えばフロッピー（登録商標）ディスクまたはＣＤ−ＲＯＭ上に分散される。そこから、プログラムおよびオペレーティングシステムは、コンピュータの２次メモリにインストールまたはロードされる。実行において、プログラムおよびオペレーティングシステムは、少なくとも部分的にはコンピュータの１次電子メモリにロードされる。本明細書で説明した本発明には、これらおよび他の様々なタイプのコンピュータ可読ストレージメディアが、マイクロプロセッサまたは他のデータプロセッサと共に後述のブロックを実装するための命令またはプログラムを含む場合、このようなメディアが含まれる。本発明にはまた、本明細書で説明した方法および技術に従ってプログラムされる場合、コンピュータ自体もが含まれる。

例示のため、オペレーティングシステムなど、プログラムおよび他の実行可能プログラムコンポーネントを本明細書で離散ブロックとして例示するが、このようなプログラムおよびコンポーネントは様々な時間にコンピュータの異なるストレージコンポーネント内に存在し、コンピュータのデータプロセッサによって実行されることは理解されよう。本明細書で説明したファンクションのいずれも、ソフトウェア、ファームウェア（例えば、固定ロジック回路）、手動処理、またはこれらの実施態様の組合せを使用して実施することができる。「ロジック」または「モジュール」という用語は、本明細書で使用される場合、一般に、ソフトウェア、ファームウェア、または、ソフトウェアおよびファームウェアの組合せを表す。例えば、ソフトウェア実施態様の場合、「ロジック」または「モジュール」という用語は、処理デバイス（例えば、ＣＰＵ）上で実行される場合に、規定されたタスクを実行するプログラムコードを表す。プログラムコードを、１つまたは複数のコンピュータ可読メモリデバイス内に格納することができる。例示した、異なるユニットへのロジックおよびモジュールの分離は、このようなソフトウェアおよび／またはハードウェアの実際の物理的グループ化および割振りを反映する場合があり、または、単一のソフトウェアプログラムおよび／またはハードウェアユニットによって実行される異なるタスクの概念的割振りに対応することが可能である。例示のロジックおよびモジュールを単一のサイトに位置付けることができ（単一の処理デバイスによって実装されるなど）、または、複数のロケーションに渡って分散させることができる。

Ｈ．結論
Ｐ２Ｐリソースプールを作成するために、Ｐ２Ｐ ＤＨＴの自己編成能力は、自己スケーリングで階層的なシステム内モニタリングインフラストラクチャと組み合わせられる。自己スケーリングおよび頑強性を達成するため、このインフラストラクチャは、ＤＨＴによって作成された仮想空間内で確立され、次いで参加者上にマップされた、論理階層でなければならない。本明細書で、ＤＨＴと効果的に組み合わせられたＳＯＭＯがどのようにリソースプールを作成するかを説明した。

リソースプールの力を利用して、ＳＯＭＯを介したオンタイムの正確なニュース放送をうまく利用し、アプリケーションに特化したスケジューラをタスク毎にインストールし、次いで、公正競争によりタスクの間で調整するための無干渉のマーケット主導型の手法を取ることができる。

Ｐ２Ｐシステム内でＤＨＴの上にデータ構造を構築するための実施態様を説明した。情報をＰ２Ｐシステムに配布するため、および、情報をＰ２Ｐシステムから収集するための、特定の階層ツリー構造を具体的に説明した。

あるオペレーションを、ある順序で実行される異なるステップを構成することとして説明した。このような実施態様は例示的であり、非限定的である。本明細書で説明したあるステップを共にグループ化し、単一のオペレーション内で実行することができ、また、あるステップを、本開示で示した実施例で使用した順序とは異なる順序で実行することができる。

さらに、いくつかの実施例は、本開示で代替物において提示される（例えば、Ａの場合またはＢの場合）。加えて、本開示は、代替物を単一の実施態様内で結合する場合（例えば、Ａの場合およびＢの場合）を、本開示があらゆる場合にこれらの接続的場合について明示的に述べない場合があるとしても、包含する。

本発明を、その精神または本質的特性から逸脱することなく、他の特定の形態で実施することができる。上述の実施形態は、あらゆる点で限定的ではなく例示的としてのみ見なされるべきである。本発明の範囲は、したがって、前述の説明によってではなく、付属の特許請求の範囲によって示される。特許請求の範囲の等価の意味および範囲内に入るすべての変更は、それらの範囲内に包含されるべきである。

従来のピアツーピア（Ｐ２Ｐ）システムを示す図である。 従来のＣＡＮルーティング方法を示す図である。 従来のＣＨＯＲＤルーティング方法を示す図である。 ローカルマシン環境のコンテキストにおいてデータ構造の２つのオブジェクトをリンクするための従来の技術を示す図である。 Ｐ２Ｐ分散ハッシュテーブル（ＤＨＴ）環境内のデータ構造の２つのオブジェクトをリンクするための例示的技術を示し、２つのオブジェクトはＰ２Ｐ ＤＨＴ環境内の２つの異なるノードに関連付けられ、リンクする技術は、ＤＨＴの「上に」配置されたデータオーバーレイの基礎を形成する図である。 リング、ゾーン、および、両側にｒ個の近隣物を記録する基本ルーティングテーブルを含む、単純なＰ２Ｐ ＤＨＴを示し、ハッシングはゾーンをＤＨＴノードに割り当てる図である。 図５に示すデータオーバーレイの概念を使用して構築された例示的ツリー構造を示し、ツリー構造は自己編成メタデータオーバーレイ（ＳＯＭＯ）と呼ばれる図である。 （ａ）は、ＳＯＭＯをボトムアップから構築するためのプロセスの進行概略図を示し、参照のフレームとしての論理ツリーの構築を示す図である。（ｂ）は、ＳＯＭＯをボトムアップから構築するためのプロセスの進行概略図を示し、代表仮想ノードの発見を示す図である。（ｃ）は、ＳＯＭＯをボトムアップから構築するためのプロセスの進行概略図を示し、物理マシンへの論理ツリーのマッピングを示す図である。 （ａ）は、図８ｃに示すボトムアップＳＯＭＯを修復するための自己スケーリングプロセスの進行概略図を示し、図８ｃに示すボトムアップＳＯＭＯを示す図である。（ｂ）は、図８ｃに示すボトムアップＳＯＭＯを修復するための自己スケーリングプロセスの進行概略図を示し、物理マシンの追加を示し、そのための対応する代表仮想ノードが論理ツリー内で発見される図である。（ｃ）は、図８ｃに示すボトムアップＳＯＭＯを修復するための自己スケーリングプロセスの進行概略図を示し、物理マシンのすべてへの、訂正された論理ツリーのマッピングを示す図である。 集合的にリソースプールを作成するための、リソースをプールするためのＤＨＴの能力およびボトムアップＳＯＭＯの組合せを示す図である。 Ｐ２Ｐシステムの参加者からの情報の収集、および、Ｐ２Ｐシステムの参加者への情報の配布への、図７のＳＯＭＯツリー構造の例示的応用例を示す図である。 アプリケーションレベルマルチキャスティングのための概略的配置を示し、円はアプリケーションレベルマルチキャスティングセッションの元のメンバを表し、四角は大きい次数を有する使用可能なピアを表す図である。 リソースプール内のヘルパーノードの使用による、図１１ａで見られた配置の改良を示し、円はアプリケーションレベルマルチキャスティングセッションの元のメンバを表し、四角は大きい次数を有する使用可能なピアを表す図である。 単一のアプリケーションレベルマルチキャスティングセッションをスケジューリングするためのＳＯＭＯレポート構造を示し、各ノードは、それらのネットワーク座標ならびに帯域幅制約を、それらのレポートにおいてＳＯＭＯにパブリッシュする図である。 Ｐ２Ｐシステムの参加者を実装するために使用される例示的コンピュータを示し、Ｐ２ＰはそのＤＨＴの上に構築されたデータオーバーレイを含む図である。

符号の説明

１０２〜１１２ ピア
４０２ ローカルマシン環境
５０２ Ｐ２Ｐ ＤＨＴ環境
５０４ ノードｘ
５０８ ノードｙ
１３４４ 処理装置
１３４６ システムメモリ
１３４８ バス
１３６６ ＳＣＳＩインターフェース
１３６８ シリアルポート
１３７０ オペレーティングシステム
１３７２ アプリケーションプログラム
１３７４ キャッシュ
１３７４ 他のモジュール
１３７６ プログラムデータ
１３７８ キーボード
１３８２ キーボード／マウスインターフェース
１３８６ ビデオアダプタ
１３９０ ローカルエリアネットワーク
１３９２ ワイドエリアネットワーク
１３９４ ネットワークインターフェース
１３９６ モデム

Claims (42)

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. データを前記ツリーノード中に通過させることによって、前記データオーバーレイを通じて前記データをルーティングする手段をさらに備えることを特徴とする請求項３３に記載の装置。
41. 前記ルーティングする手段は、データをＤＨＴノードから収集すること、および、前記データを前記ツリーの前記ルートノードへと前記ツリーノード中に通過させることによって、前記データオーバーレイを通じて前記データをルーティングする手段を含むことを特徴とする請求項４０に記載の装置。
42. 前記ルーティングする手段は、前記ツリーの前記ルートノードから、前記ツリーノードを通じて、前記ＤＨＴノードへデータを配布することによって、前記データオーバーレイを通じてデータをルーティングする手段を含むことを特徴とする請求項４０に記載の装置。

Images