JP4806203B2 - ピアツーピアネットワークにおけるルーティング - Google Patents

Description

本発明は、全体としてはピアツーピアネットワークに関し、より詳細には、ピアツーピアネットワークにおけるルーティングに関する。

ピアツーピアネットワークは、適応性、自己組織化、負荷平衡、耐障害性、低コスト、高可用性、拡張性、および大量の共用リソースを提供する能力など、多くの望ましい特徴のため、その人気を高め続けている。例えば、ピアツーピアネットワークは、大量のデータを共用するための人気の高い方法として出現し、ピアはダウンロード可能なように参照される歌を、ピアツーピアネットワークの別のピアからダウンロードすることなどができる。

しかし、ピアツーピアネットワークを実現するために利用される従来のアーキテクチャは、システムを形成するメンバー、すなわちノードの数の絶えざる増加に対処していない。例えば、現行例のピアツーピアネットワークは、２億３千万超のダウンロードを４百万超のユーザに提供している。しかし、メンバー数は増加を続け、１兆を超えるノードを有する超大規模システムがいずれ出現することが予想される。したがって、現行のアーキテクチャは、多数のノードを有するシステムには対処できたとしても、超大規模システムで利用された場合に、まだ力不足であると判明するかもしれない。

ピアツーピアネットワークにおいて特定のリソースを見つけるため、例えば、ネットワークの各ノードは、ネットワークの１つまたは複数の他のノードを参照して、その特定のリソース、例えば、特定のデータ項目を有するノードを見つけることができる。したがって、特定の項目が見つかるまで、リクエストを１つのノードから別のノードへと転送していく際に、一連の「ホップ（hop）」を利用することができる。ホップの回数が増加するにつれて、ノードのハードウェアリソースおよびソフトウェアリソースの使用、ならびにシステムのネットワークリソースの使用も増加する。したがって、ホップの回数が増加すると、その結果、システムリソースの使用が非効率になるとともに、特定の項目を見つけるのに利用される時間も増加する。

I. Clarke, B. Wiley, O. Sanberg, and T. Hong, "Freenet: A Distributed Anonymous Information Storage and Retrieval System," Proc. Int. Workshop on Design Issues in Anonymity and Unobservability, Springer Verlag, LNCS 2009, 2001 I. Stoica, R. Morris, D. Karger, M. F. Kaashoek, H. Balakrishnan, "Chord A Scalable Peer-to-peer Lookup Service for Internet Application," Proc. ACM SIGCOMM'01, San Diego, California, USA, 2001 S. Ratnasamy, P. Francis, M. Handley, R. Karp, and S. Shenker, "A Scalable Content-Addressable Network," Proc. ACM SIGCOMM'01, San Diego, California, USA, 2001 A. Rowstron and P. Druschel, "Pastry: Scalable, Descentralized Object Location and Routing for Large-Scale Peer-to-Peer Systems," IFIP/ACM Int. Conf. Distributed Systems Platforms (Middleware), 2001 B. Y. Zhao, J. Kubiatowicz, and A. D. Joseph, "Tapestry: An Infrastructure for Fault-tolerant Wide-Area Location and Routing," Technical Report No. UCB/CSD-01-1141, Univ. of California, Berkeley

したがって、ピアツーピアネットワークにおける改良されたルーティングが引き続き必要とされている。

ピアツーピアネットワークにおいてルーティングテーブルを利用してメッセージ（例えば、特定のリソースを求めるリクエストや、そのリクエストに対する応答など）を転送するルーティングについて説明する。ルーティングテーブルはブロードキャストによって更新され、ピアツーピアネットワーク内のノードを参照するルーティングテーブル内のエントリを更新することができる。一実装では、各ノードのルーティングテーブルをメンテナンスするのに利用されるメンテナンス予算は、各セグメント用に稠密なルーティングテーブルエントリ（dense routing table entry）を作成することによって、ピアツーピアネットワークのリソース空間の複数のセグメントに分散される。その結果、ルーティングテーブルのメンテナンスのための全体的なメンテナンス予算を削減することができ、ピアツーピアネットワークのハードウェア、ソフトウェア、およびネットワークリソースを解放して、望ましいメッセージルーティング機能を提供する。

一実装では、本発明の方法は、ピアツーピアネットワーク内の複数のノードのうち１つのノードにおいて、ピアツーピアネットワーク内の別のノードからの、ピアツーピアネットワークにおけるメンバーシップ変更（a change in membership）の通知（an indication）を受信するステップを含む。変更を記述するレポートがブロードキャストされる。レポートは、上記１つのノードに含まれるルーティングテーブル内で参照される各ノードによって受信される。

別の実装では、本発明の方法は、ピアツーピアネットワーク内に含まれるノードにおいて、ピアツーピアネットワーク内で通信を行うためにノードが利用可能なリソースを判定するステップを含む。ピアツーピアネットワーク内でリクエストを転送するため、上記決定に基づいて、ノード上でルーティングテーブルが形成される。

さらに別の実装では、本発明の方法は、ピアツーピアネットワークの複数のノードのうち１つのノードで反復ブルームフィルタ（iterative bloom filter）を利用して、ルーティングテーブルのエントリを表すデータを圧縮するステップを含む。圧縮データを別のノードに送るために通信が行われる。

本開示および図面では、同じ構成要素および機能を参照する際は同じ番号を使用する。

概要（Overview）
ピアツーピアネットワークにおけるルーティングについて説明する。上述したように、利用する転送ノードを少なくして、全体的な帯域消費（bandwidth consumption）を減らすことができるように、ホップ数は少ないほうが望ましい。超大規模システム（すなわち、１兆ノード）においてリソースを見つけるために利用されるホップの回数を減少させながら、低くて管理可能なノード当たりのメンテナンス予算のルーティング技法について説明する。

ピアツーピアネットワークにおいてノードによって他のノードを参照するために、ルーティングテーブルが利用される。しかし、超大規模システムにおいてルーティングテーブルを従来通りにメンテナンスすると、許容量を超える大量のハードウェア、ソフトウェア、およびネットワークリソースが利用されることになり得る。例えば、従来のメンテナンス技法は、リクエストを送信し、そのリクエストに対する応答を受信して、テーブルによって参照されるノードが現在もシステムで利用可能かどうかを判定することによって、ルーティングテーブルのエントリを更新するなど、プロービング（probing）を利用する。各プロービングで利用されるハードウェア、ソフトウェア、およびネットワークリソースの量は比較的少量であるが、個々のリソース利用量をシステム全体で累計すると、膨大な量になり得る。したがって、超大規模システムにおいて、これらの従来のメンテナンス技法を使用すると、機能面で著しい損失を招くことになりかねない。本明細書で説明するメンテナンス技法では、各セグメント用に稠密なルーティングテーブルエントリを作成することによって、ルーティングテーブルをメンテナンスするのに利用されるメンテナンス予算をピアツーピアネットワークのリソース空間の複数のセグメントに分散させることができる。その結果、ルーティングテーブルのメンテナンスにかかる全体的なメンテナンス予算を削減でき、ピアツーピアネットワークのハードウェア、ソフトウェア、およびネットワークリソースを解放して、リクエストおよびリクエストに対する応答の転送に関する望ましい機能を提供するために利用することができる。このように、超大規模システムにおいて利用されるホップの回数を少なくしながら、メンテナンス予算が許容限度を超えないようにして、ルーティングテーブルをメンテナンスすることができる。ルーティングテーブルの稠密なルーティングエントリおよびメンテナンスについては、図３に関連させてさらに説明する。

さらに、これまで利用されてきたＯ（ｌｏｇＮ）ルーティング技法は、現行のシステムでは成功しているが、従来の技法の現在容認されている小さな底（すなわち、Ｏ（ｌｏｇ_ｂＮ）のパラメータｂ）は、超大規模システム用にはもはや十分とはいえない。例えば、システム内のノード数「Ｎ」が１兆になると、従来のＯ（ｌｏｇＮ）ルーティング技法を利用した場合、最悪時のホップ回数は２０になる（ｂが４で、エントリが約６０の場合）。「ルーティングパフォーマンス（Routing Performance）」セクションでより詳細に説明される実施形態では、１兆ノードを有するシステムにおいて本明細書で説明するルーティング技法を利用した場合の平均ルーティングは、５．５ホップまで減少する。

例示的な環境（Exemplary Environment）
図１は、ピアツーピアネットワークを提供するように構成されたシステム１００の例示的な実施形態の図である。システム１００は、複数のコンピューティングデバイス１０４（１）〜１０４（Ｂ）にネットワーク１０６を介して通信可能に結合される、複数のクライアント１０２（ａ）を含む（「ａ」は１から「Ａ」までの任意の整数とする）。この実施形態では、複数のクライアント１０２（ａ）と複数のコンピューティングデバイス１０４（１）〜１０４（Ｂ）はそれぞれ、ネットワーク１０６のノードを表す。ノードは、データの送信先および／または送信元である他のノードおよび／またはエンドポイントにデータを供給する再分配ポイントなど、データを送信するための接続ポイントと考えることができる。

複数のクライアント１０２（ａ）と複数のコンピューティングデバイス１０４（１）〜１０４（Ｂ）は、様々な方法で構成することができる。例えば、クライアント１０２（ａ）とコンピューティングデバイス１０４（１）〜１０４（Ｂ）は、ワイヤレスフォン（例えば、コンピューティングデバイス１０４（１））、タブレットコンピュータ（例えば、コンピューティングデバイス１０４（２））、ノートブックコンピュータ（例えば、コンピューティングデバイス１０４（３））、デスクトップコンピュータ（例えば、コンピューティングデバイス１０４（４））、サーバ（例えば、コンピューティングデバイス１０４（５）〜１０４（６））、メインフレームコンピュータ（例えば、コンピューティングデバイス１０４（Ｂ））、ならびに移動局、ゲーム機器、およびセットトップボックスなどのその他のコンピューティングデバイスなど、ネットワーク１０６を介して通信可能なコンピュータとして構成することができる。例示的なコンピューティングデバイスについては、図１０に関連させてさらに説明する。したがって、複数のクライアント１０２（ａ）とコンピューティングデバイス１０４（１）〜１０４（Ｂ）には、メモリリソースおよびプロセッサリソースを十分に備えたフルリソースデバイス（例えば、パーソナルコンピュータ、ハードディスクを備えたテレビ録画装置）から、限られたメモリリソースおよび／またはプロセッサリソースしか備えていない低リソースデバイス（例えば、従来のセットトップボックス）まで様々なものがあり得る。クライアント１０２（ａ）はまた、クライアントを操作する人間および／または操作主体に結びつけることもできる。言い換えると、クライアント１０２（ａ）は、ユーザおよび／またはマシンを含む論理クライアントとすることができる。

ネットワーク１０６は、ピアツーピアネットワークとして構成される。ピアツーピアネットワークは、ネットワーク１０６のノードが、各々のノード、すなわち、複数のクライアント１０２（ａ）および複数のコンピューティングデバイス１０４（１）〜１０４（Ｂ）に存在する共用リソースにアクセスすることを可能にする。従来から知られており、使用されてきたピアツーピアネットワークの例として、以下に示すネットワークがある。
・Ｆｒｅｅｎｅｔ（例えば、非特許文献１参照）。
・Ｃｈｏｒｄ（例えば、非特許文献２参照）。
・ＣＡＮ（例えば、非特許文献３参照）。
・Ｐａｓｔｒｙ（例えば、非特許文献４参照）。
・Ｔａｐｅｓｔｒｙ（例えば、非特許文献５参照）。

ピアツーピアネットワークは、冗長性や耐障害性（fault tolerance）など様々な特徴を提供する。例えば、ピアツーピアネットワークに保存されたデータは、ピアツーピアネットワークのノードによって複製されながら徐々に拡散することができる。そのため、ピアツーピアネットワークでは、データが何重にも重複することがあり、データの信頼性および可用性を高めることができる。

データ、処理サイクル、およびデータストレージなど様々なリソースを、ピアツーピアネットワークを使用して交換することができる。したがって、ピアツーピアネットワークは、複数のクライアント１０２（ａ）と複数のコンピューティングデバイス１０４（１）〜１０４（Ｂ）の集団的能力を活用するために利用することができる。ピアツーピアは、各ノード、すなわち「メンバー（member）」が、別のメンバーと直接、かつ／または仲介コンピューティングデバイスを介して通信することができる通信モデルである。クライアント１０２（ａ）およびコンピューティングデバイス１０４（１）〜１０４（Ｂ）は、リクエストおよび応答などのメッセージを使用することによって、ネットワーク１０６を介して通信することができる。図１には７つのコンピューティングデバイス１０４（１）〜１０４（Ｂ）が示されているが、この環境で多種多様なコンピューティングデバイスを実施することができる。さらに、複数のクライアント１０２（ａ）も、ピアツーピアネットワークの「ピア（peers）」、すなわちメンバーとして構成することができる。

ネットワーク１０６は、クライアント１０２（ａ）と複数のコンピューティングデバイス１０４（１）〜１０４（Ｂ）の間でメッセージを転送するためのインタフェースとして動作する分散ハッシュテーブル（ＤＨＴ：distributed hash table）１０８を含む。ＤＨＴ１０８は、（キー，値）ペアを保存するハッシュテーブルデータ構造の分散形と考えることができる。例えば、キーをファイル名に対応させ、値をファイル内容に対応させることができる。ネットワーク１０６の各ピア、例えば、コンピューティングデバイス１０４（１）〜１０４（Ｂ）は、（キー，値）ペアのサブセットを保存する。したがって、ＤＨＴ１０８は、対応するキーを担当するノードを見つけるのに利用される。言い換えると、ＤＨＴ１０８は、クライアント１０２（ａ）と複数のコンピューティングデバイス１０４（１）〜１０４（Ｂ）の間でメッセージを転送するため、キーをノードにマッピングする。ファイル共用サービス、アーカイブ保存サービス（例えば、ウェブアーカイビング）、データベース、名前システム、サービスディスカバリ（service discovery）、アプリケーションレイヤマルチキャスト（application-layer multicast）、イベント通知、チャットサービス、ランデブーベース通信（rendezvous-based communication）、クエリとインデックスづけ、データの出版／購読など、様々なサービスをＤＨＴ１０８の「上に（on-top）」構築することができる。

ＤＨＴ１０８は、複数のコンピューティングデバイス１０４（１）〜１０４（Ｂ）によって提供されるリソースを、複数のゾーン１１０（１）〜１１０（８）、すなわち「バケット（bucket）」に区分けする。複数のゾーン１１０（１）〜１１０（８）の各々は、システム１００において共用されるリソース全体の一部と考えることができる。例えば、上述したように、ＤＨＴ１０８は、リソースをキーに関連づける。ＤＨＴ１０８を使用して複数のゾーン１１０（１）〜１１０（８）から特定の１ゾーンを見つけるため、キーはハッシュされる。複数のゾーン１１０（１）〜１１０（８）は、様々な方法で提供することができる。例えば、図１のイラストでは、ゾーン１１０（１）は、コンピューティングデバイス１０４（１）によって提供されるように描かれている。同様に、ゾーン１１０（２）、ゾーン１１０（３）、ゾーン１１０（４）、ゾーン１１０（５）、およびゾーン１１０（６）の各々は、それぞれ、コンピューティングデバイス１０４（２）、コンピューティングデバイス１０４（３）、コンピューティングデバイス１０４（４）、コンピューティングデバイス１０４（５）、およびコンピューティングデバイス１０４（６）によって提供される。さらに、コンピューティングデバイスは、２以上のゾーンを提供することができ、図１のイラストでは、ゾーン１１０（７）およびゾーン１１０（８）が、コンピューティングデバイス１０４（Ｂ）によって提供されるように描かれている。

ＤＨＴ１０８は、リーフセット（leafset）１１２、フィンガテーブル（finger table）１１４、およびソフトステートルーティングテーブル（ＳＳＲＴ:soft-state routing table）１１６を含む３層アーキテクチャを利用するように示されている。リーフセット１１２は、キー空間（key space）の完全性（integrity）を保証するために利用される。例えば、リーフセット１１２は、リソース空間およびノードの応答空間を上述したように１つまたは複数のゾーン１１０（１）〜１１０（８）に分割するため、整合的なハッシングを利用する。

中間層であるフィンガテーブル１１４は、Ｏ（ｌｏｇＮ）プレフィックスルーティングアルゴリズム（prefix routing algorithm）（Ｎはノードの総数）など、プレフィックスベースのルーティングアルゴリズムを実施するために利用される。例えば、各ノードは、システム１００の他のノードを指し示すエントリであるフィンガを有するフィンガテーブル１１４を含むことができる。フィンガテーブル１１４のエントリは、システム１００の「さらなる（further）」ノードを連続的に参照するため、対数関数に従うことができる。フィンガテーブル１１４のエントリは、対応するノードのＩＤの１ビットを反転させ、結果のキーを保持するノードを指し示すことによって構成することができる。プロービング機構（probing mechanism）を使用するなど、リーフセット１１２およびフィンガテーブル１１４を更新するために、定期的なビーコニング（beaconing）を利用することができる。したがって、リーフセット１１２およびフィンガテーブル１１４は、Ｏ（ｌｏｇＮ）パフォーマンスをＤＨＴ１０８に提供することができる。

ＳＳＲＴ１１６は、（例えば、ノードがシステム１００に加入またはシステム１００を離脱する場合の）チャーンレート（churn rate）μが小さい場合、システム１００のメンバーであるノードの一覧を提供する。したがって、ＳＳＲＴ１１６は、所望のノードの所在を素早く見つけるために利用することができる。ＳＳＲＴ１１６は、適切な冗長性を有するブロードキャストグラフを形成するシステム１００のすべてのノードのフィンガを利用することによって構成することができる。この説明におけるブロードキャストとは、発信者（originator）と呼ばれる１つの頂点（vertex）が、グラフのエッジに沿って一連の発信を行うことによって、その他のすべての頂点にデータを配布する、グラフ内でのデータの配布のことである。情報を受け取ると、他の頂点も発信者を助けてメッセージを配布する。ブロードキャストグラフは、ブロードキャストを“［ｌｏｇ_２ｎ］”時間単位で達成できるグラフである。

図２は、ピアツーピアネットワークの複数のノード２０２（ｘ）（ｘは１から「Ｘ」までの任意の整数）をより詳細に示した、例示的な実施形態によるシステム２００の図である。ノード２０２（ｘ）は、図１のシステム１００のノード、例えば、コンピューティングデバイス１０４（１）〜１０４（Ｂ）およびクライアント１０２（ａ）と同じあってもよく、異なっていてもよい。ノード２０２（ｘ）は、リーフセット１１２（ｘ）、フィンガテーブル１１４（ｘ）、およびＳＳＲＴ１１６（ｘ）を有する対応するＤＨＴ１０８（ｘ）を含むように示されているが、参照番号は、これらのテーブルが、特定のノード２０２（ｘ）用のＤＨＴ１０８、リーフセット１１２、フィンガテーブル１１４、およびＳＳＲＴ１１６であることが分かるように付されている。

ノード２０２（ｘ）は、「加入（join）」または「離脱（leave）」イベントなど、メンバーシップ変更を知らせる１つまたは複数のイベントを個々のノードから受信することによって、リーフセット１１２（ｘ）に属する他のノードのメンバーシップを監視することができる。ノード２０２（ｘ）は、メンバーシップの変化を観察した場合、例えば、加入または離脱イベントなど、１つまたは複数のイベント２０４（ｃ）をレポート２０６（ｘ）に挿入する。レポート２０６（ｘ）は、フィンガテーブル１１４（ｘ）によって示されるノード２０２（ｘ）の各フィンガを介して、事前定義されたブロードキャスト間隔で並列にブロードキャストされる。複数のノード２０２（ｘ）は各々、ノードが観察したイベントと、システム２００の他のノードから大量に送られてきたイベントから、ノード２０２（ｘ）が通知済のイベントを差し引いたイベントを通知するレポートを作成するという同じ動作を実行する。したがって、信頼できるブロードキャストを高い伝播速度（平均でＯ（ｌｏｇＮ））で送り届けるための適切な冗長度（Ｏ（ｌｏｇＮ））を提供するフラッディングアルゴリズム（flooding algorithm）が提供される。

メンテナンスコストを規制するため、割当量（quota）を超過した場合、イベントを内部的にキュー２０８（ｘ）にバッファすることができる。さらに、ＤＨＴ１０８は、１つまたは複数のルールを使用することによって、堅牢性に適応的に対処することができる。例えば、ＳＳＲＴ１１６（ｘ）のエントリが高品質であること（例えば、ＳＳＲＴ１１６（ｘ）のエントリが、図１のシステム１００の現在のメンバーシップを表すこと）を保証するため、特定のノードがシステム１００を離脱したことを示す「離脱」イベントは、例えば、「加入」イベントなどの他のイベントより先に送出される。このように、システム１００は、システムを離脱した特定のノードからのリソースが利用できなくなったときについて常にそのことを認識するようになっており、システム１００の平衡を回復するのに利用される別のノードがシステム１００に加入した場合は、その後で通知されるようになっている。システム平衡については「適応（Adaptation）」セクションでさらに説明する。

定常状態で、ＳＳＲＴ１１６（ｘ）の有効エントリの数Ｍは、以下の式を解くことによって知ることができる。
Ｑ＝４μ・Ｅ・Ｍ・ｌｏｇＮ

ただし、Ｅはイベントのサイズとする。本発明の一実施形態では、イベントは３４バイトであり、イベントタイプ、タイムスタンプ、ＩＰアドレス、およびノードＩＤを示すデータを含む。式中の定数「４」は、送信時および受信時、ならびにセッション毎に１回の加入動作時および１回の離脱動作時に帯域コスト（bandwidth cost）が生じることから説明される。

したがって、ＤＨＴ１０８（ｘ）は、（例えば、イベントをレポートにまとめるなど）時間ドメインと（例えば、Ｏ（ｌｏｇ_２Ｎ）のノードと対話するなど）空間ドメインとで行われる集約（aggregation）を大いに利用することができる。さらに、メンバーシップ変更を伝えるのにブロードキャストを利用することによって、フルクラスタ（full cluster）を維持したとしても、伝えるイベントが存在しない場合は、ネットワークにわずかのトラフィックしか発生せず、結果として、ネットワーク効率が向上する。

ＤＨＴ
このセクションでは、超大規模システムの動的環境における、ＤＨＴ１０８アーキテクチャの使用について説明する。ＤＨＴ１０８は、ｂが非常に大きな（例えば、約４０００に等しいｂ）Ｏ（ｌｏｇ_ｂＮ）ルーティングの効果を提供し、各エントリの能動プロービングを必要としない。上述したように、ＤＨＴ１０８のエントリを更新するために行われるプローブの送信および／またはプローブへの応答に要する帯域消費は少ないとしても、大量のプローブの送信および応答は、図１のシステム１００の全体または部分にわたって集約された（aggregated）場合に、著しいオーバヘッドを招くことにもなり得る。さらに、ミスは検出するのにコストがかかり、例えば、ミスがあるとシステム内で所望のリソースを見つける際にでたらめなＩＰホップが生じるので、プロービング頻度を減らすことが望ましいとは限らない。

以下の実施形態では、Ｎを１兆に等しいとした場合の、ｂ＝４０００のプレフィックスベースのルーティングのパフォーマンスが繰り返される。以下の説明では、ブロードキャストコストＱを５ｋｂ／ｓとし、チャーンレートμを１／（３時間）と仮定する。これらのパラメータは、ＤＨＴ１０８を利用して、サイズ４Ｋのフルクラスタを構築することを可能にする。本明細書で説明するルーティング技法が、様々なブロードキャストコストおよびチャーンレートに対応し得ることは明らかであろう。

このようなパフォーマンスを実現するのに利用されるルーティング技法の一例は、２つのコンポーネントを含む。第１のコンポーネントは、ブロードキャストコストの４分の１、すなわちＱ／４を使用して、リソース空間全体の代わりに、サブ領域用のクロスバー（crossbar）を作成することに関する。第２のコンポーネントは、ルーティングを行うときに、４つのそのようなクロスバーを使用して、４０ビットを循環させるためのメカニズムの設計に関する。これらのコンポーネントの各々について、以下のセクションで順番に説明する。

サブ領域クロスバーの作成（Building a Sub-Region Crossbar）
全リソース空間Ｔは、「ｉ」を一定の整数として、ｔ／２^ｉ個の領域に分割することができる。例えば、各領域Ｍが平均約１千ノードを含むように、分割を行うことができる。任意のノードｘについて、Ｒ（ｘ）をｘが属する領域とし、ｂｅａｍｅｒｓ（ｘ）をＲの範囲内にあるｘのフィンガのサブセット、すなわち、領域Ｒ内の他のノードを指し示すｘのフィンガのサブセットとする。したがって、同じＲを共有するすべてのノードについて、対応するｂｅａｍｅｒｓは、Ｒをカバーする極めて冗長度が高いブロードキャストグラフを集団で形成する。ＤＨＴ１０８において同じブロードキャストプロトコルをｂｅａｍｅｒｓを介して適用することによって、これらのノードの各々に、対応する領域Ｒをカバーする対応するＳＳＲＴを供給することができる。帯域コストは、４μ・Ｅ・Ｍ・ｌｏｇＭとして計算することができる。したがって、この実施形態では、Ｅ＝３４Ｂ、μ＝１／（３時間）とした場合、帯域コストは約１ｋｂ／ｓとなる。このように、第１のコンポーネントは、１ホップで最短の２を底とする１０（shortest 10 base-2）のフィンガ範囲を解決する（resolve）ことのできるクラスタを構築するのにＱ／４未満のコストを使用することにより達成される。基本的に、サブ領域クラスタは、１Ｋノードのリーフセットと見なすことができる。例えば、ルックアップキー（lookup key）がこの範囲にあるならば、所望のリソースを見つけるのに１ホップで十分である。

Ｒを様々な方法で推定することができる。例えば、各ノードは、対応するリーフセットの情報を使用して、平均ゾーンサイズ

を計算することができる。次のノードは、

より１０ビット大きく領域Ｒを推定することができる。上述したように、ｂｅａｍｅｒｓは、領域推定内のフィンガである。領域推定の外部にあるノードによって送信された加入イベント（join-events）をドロップすることによって、さらに境界を強化することができる。したがって、ノードのＳＳＲＴは、隣接領域からのエントリによって汚染されることはない。

図３は、ピアツーピアネットワークで実施されるシステムにおける複数のノードのＳＳＲＴを表す１次元論理キー空間３００の図である。１次元論理キー空間３００の第１の領域３０２は、図２の複数のノード２０２（ｘ）のうちの第１のノードのＳＳＲＴによって表すことができ、１次元論理キー空間３００の第２の領域３０４は、図２の複数のノード２０２（ｘ）のうちの第２のノードのＳＳＲＴによって表すことができ、それ以降も同様である。図３に示す破線は、論理的な領域分割線を表す。したがって、図３に示すように、ＳＳＲＴは、対応するノードの対応する領域をカバーするエントリによって占められる。

複数ブロックの解決（Resolving Multiple Blocks）
以下の説明では、各ノードのＩＤ長を１６０ビットとし、ＩＤの１０ビット長セグメントを「ブロック（block）」と呼ぶことにする。上述したように、ＩＤは、ピアツーピアネットワークのノードのアドレスと考えることができる。ｂ＝４Ｋとするプレフィックスベースのルーティングは、一度に１ブロックずつ検索を解決する。この例に用いている１兆ノードを有するシステムでは、解決すべき１０ビット長ブロックが全部で４つ存在する。

ルーティングは、送信先が最短の１０フィンガによってカバーされる範囲に存在するようになるまで、フィンガを介して一度にアドレスの１ビットをマッチングすることによって、領域クラスタ内で続けられる。この時点で、ＳＳＲＴは、１ホップでのリソースへのアクセスを達成する。効果的には、これらの最後の１０フィンガは、このアクセスを伸ばすために、２^１０のＳＳＲＴエントリに拡張することができる。言い換えると、他の先行ブロックに位置するフィンガは、同じプレフィックス範囲に含めるため、ＳＳＲＴエントリに拡張される。

１兆ノードのシステムでは、各ノードは、平均４０フィンガを有する。以下の説明では、基本リング（ring）を表すのに、Ｒｉｎｇ_０を使用する。さらに、以下の説明では、ノードのＩＤを、図４に示すようにアルファベットの名前をつけた１０ビット長ブロックに分割する。１０ビット長ブロックが示されているが、ブロックに異なるビット長を利用することもできる。例えば、各ブロックは、２以上のビット、５以上のビットなどを有することができる。

例えば、図４のブロックＡ４０２について考える。ブロックＡ４０２のＳＳＲＴエントリを作成するため、ＩＤ４０４を右方向に循環させて、ブロックＡ４０２’が第４ブロックにある新しいＩＤ_Ａ４０６を取得する。各ノードは、Ｒｉｎｇ_Ａで表される別のリングに加わるのにＩＤ_Ａ４０６を使用する。Ｒｉｎｇ_Ａは、独自のリーフセットとＯ（ｌｏｇ_２Ｎ）を用い、Ｒｉｎｇ_０と同じ方法で作成される。それに加えて、サブ領域クラスタアルゴリズムが同じように適用される。したがって、ノードは、Ｒｉｎｇ_Ａにおいて１ＫサイズのＳＳＲＴ_Ａ４０８を獲得し、そのエントリは、ＩＤ_Ａが先頭の３ブロック（すなわち、Ｎ｜Ｏ｜Ｐ）を上記ノードと共有するが、第４ブロック、すなわちブロックＡ４０２’が異なるノードである。

ＩＤ４０４とＩＤ_Ａ４０６の関係は、これらの４つのノードが順々に、ＩＤの最後の３つのブロックを共有するが、Ｒｉｎｇ_０のブロックＡが異なるノードであることを意味する。したがって、ブロックＡの２を底とする１０（10 base-2）のフィンガを、２^１０のＳＳＲＴエントリに拡張する作業が達成される。ブロックＢ、Ｃ、およびＤ（例えば、ＳＳＲＴ_Ｄ４１０）に対しても、同様の構成を実行することができる。各リングは、対応するブロックをカバーするＳＳＲＴエントリを作成するのに役立つ。

要するに、この例では、４つのリングが作成される。以下の説明では、ブロックＡのＳＳＲＴをＳＳＲＴ_Ａで表し、ブロックＢのＳＳＲＴをＳＳＲＴ_Ｂで表し、その他も同様とする。最終的なＳＳＲＴは、４つのより小さなＳＳＲＴ（例えば、ＳＳＲＴ_Ａ、ＳＳＲＴ_Ｂ、ＳＳＲＴ_Ｃ、ＳＳＲＴ_Ｄ）の組み合わせであり、サイズは約４Ｋである。中間のホップを介した進行のためにできるだけ積極的にビットをマッチさせる、ＤＨＴを使用するルーティングが進行し得る。

ルーティング（Routing）
図５は、図１のシステム１００の各ノードに配置されたＳＳＲＴテーブルを使用することによって実行されるルーティングを示した例示的な実施形態５００である。特定のアドレス５０６を有するノードを見つけるために、ルックアップキー５０２が、ＳＳＲＴと併せて利用される。前のセクションで述べたように、ＳＳＲＴ５０４は、レベルが変化する類似性を備えたアドレスを有するノードを参照するエントリを含む。

ＳＳＲＴ５０４は、例えば、個々のＳＳＲＴ５１６、５１８、５２０、５２２エントリを有する複数の部分５０８、５１０、５１２、５１４から構成することができる。第１の部分５０８は、ブロックＡ５２４内で表すことができる異なるアドレスを有する各ノードを参照するＳＳＲＴ_Ａ５１６エントリを含む。第２の部分５１０は、アドレスブロックＡについて互いにマッチするアドレスを有する各ノードを参照するＳＳＲＴ_Ｂ５１８エントリを含む。しかし、第２の部分５１０は、ブロックＢ５２６内で表すことができるそれぞれ異なるアドレスを有する各ノードを参照する。言い換えると、ＳＳＲＴ_Ｂ５１８のすべてのエントリは、互いにマッチするブロックＡをそれぞれ有するが、ブロックＢは異なっている。同様に、第３の部分５１２は、互いにマッチするアドレスブロックＡおよびＢをそれぞれ有する各ノードを参照するＳＳＲＴ_Ｃ５２０エントリを含む。しかし、第３の部分５１２は、ブロックＣ内で表すことができる異なるアドレスの各々を有する各ノードを参照する。したがって、ＳＳＲＴ_Ｃ５２０のすべてのエントリは、マッチするブロックＡおよびＢをそれぞれ有するが、ブロックＣは異なっている。最後に、第４の部分５１４は、マッチングアドレスブロックＡ、Ｂ、およびＣを有する各ノードを参照するＳＳＲＴ_Ｄ５２２エントリを含む。しかし、第４の部分５１４は、ブロックＤ内で表すことができる異なるアドレスの１つを有する各ノードを参照する。したがって、ＳＳＲＴ_Ｄ５２２のすべてのエントリは、マッチするブロックＡ、Ｂ、およびＣをそれぞれ有するが、ブロックＤは異なっており、個々のノードへの「１ホップ（one hop）」ルーティングを提供する。このように、個々のノードによって維持される各ＳＳＲＴは、ピアツーピアネットワークにおける効率的なルーティングを提供するため、類似アドレスを有するノードからなる異なる階層を表すことを可能にすることができる。

例えば、ＳＳＲＴ５０４は、ルックアップキー５０２を使用してＳＳＲＴ５０４を調査することによって特定のリソースを見つけるために利用することができる。ルックアップキー５０２のブロックＡ５２４、Ｂ５２６、Ｃ５２８、およびＤ５３０が、ＳＳＲＴ５０４テーブルのＳＳＲＴ_Ｄ５２２エントリ内に示される対応するブロックＡ、Ｂ、Ｃ、およびＤとマッチするならば、リクエストを対応するソースノード５０６に直接、すなわち１ホップで転送するために、ＳＳＲＴ５０４を利用することができる。

別の例では、ルックアップキー５０２がＳＳＲＴ５０４のブロックＡおよびＢとはマッチするが、ブロックＣとはマッチしない場合、マッチングブロックＡ、Ｂ、およびＣを有するノードを示す対応するノードにホップするため、ルックアップキー５０２はＳＳＲＴ_Ｃと比較される。対応するノードは、１ホップでソースノード５０６を見つけるために利用することができる第４の部分を有するＳＳＲＴを有することができる。ルックアップキーのどれだけがＳＳＲＴ５０４のエントリとマッチするかに基づいて、第１および第２の部分５０８、５１０を使用して、同様の検索を実行することができる。したがって、各ノードは、超大規模システムのノードを素早く見つけるために利用することができるＳＳＲＴを含む。

図６は、図１のシステム１００の各ノードに配置される図６のＳＳＲＴテーブルを使用することによって実行されるルーティングを示した例示的な実施形態６００の図である。上で図４に関連させて述べたように、ＳＳＲＴは、各ノードのＩＤを循環させることによって、ピアツーピアネットワークにおける各ノードのロケーションを参照する複数のリングから構成することができる。例えば、ｒｉｎｇ_Ａ６０２は、複数のエントリを有するＳＳＲＴ_Ａ６０４を有することができる。この例では、ＳＳＲＴ_Ａ６０４の各エントリは、（図６では「Ｎ｜Ｏ｜Ｐ」として示される）互いにマッチする最初の３ブロックを有する。ＳＳＲＴ_Ａ６０４の第４のブロック「Ａ」は、その第４のブロックについて対応するアドレスを有するシステム内の各ロケーションを表す。ＳＳＲＴ_Ａ６０４のエントリを作成するため、ピアツーピアネットワークのノードのＩＤ、すなわちアドレスを「循環（rotated）」させる。例えば、アドレス６０６「１１０｜…Ｎ｜Ｏ｜Ｐ」を循環６０８させて、ＳＳＲＴ_Ａ６０４に含まれるＩＤ６１０「Ｎ｜Ｏ｜Ｐ｜１１０…」を形成する。このように、超大規模システムにおいて所望のリソースを見つけるために実行されるホップ回数を減らすＳＳＲＴを構成することができる。

ルーティングパフォーマンス（Routing Performance）
上述した実施形態において、より高位のブロックにおけるルーティング解決は、送信先が最短の１０フィンガによってカバーされる範囲内に存在する場合を除いて、各ブロックについて、１ホップより僅かに大きいホップ数が必要となる。例えば、図５に示すような１兆ノードのシステムについて考える。ノードｘが検索を開始したとき、送信先キーｋはランダムである。ａｄｄｒ_Ａ（ｋ）をｋのＡブロック（すなわち、最高位の１０ビット）とすると、ａｄｄｒ_Ａ（ｋ）は、２^１０の可能な値を有する。上述したように、１ＫのＳＳＲＴ_Ａ（ｘ）エントリは、ＩＤがＩＤ（ｘ）の最後の３ブロックを共有するが、ブロックＡが異なるノードである。ノードＩＤはランダムなので、ＳＳＲＴ_Ａ（ｘ）エントリのブロック「Ａ」もａｄｄｒ_Ａ（ｋ）の２^１０の可能な値を含むことは保証されない。

上記の問題は、完全なリソース空間を約１千のビン（bins）に分割し、ＳＳＲＴ_Ａ（ｘ）のノードおよびｘ自体をそれらのビン内にランダムに落とされるボールと見なすことと等価である。ブロックＡでの検索は、図６に示すように、ａｄｄｒ_Ａ（ｋ）によって索引づけされるビンが空でない場合に限って、１ホップで解決することができる。同様に、空間が５１２のビンに分割され、ａｄｄｒ_Ａ（ｋ）が空でないビンを指し示す場合、別のノードのＳＳＲＴ_Ｂを使用し始める前にフィンガテーブルの通常の「フィンガ（finger）」を使用して解決するためのさらなる１ホップを残して、最高位の９ビットをＳＳＲＴ_Ａ（ｘ）を使用して解決することができる。

少なくともｉビットが解決される確率をＰ_ｉとする。Ｐ_ｂを計算するため、空間を２^ｉのビンに分割し、その空間内で２^１０のボールを落下させる。したがって、１−Ｐ_ｉは（１−２^―ｉ）^１０２４であり、言い換えると、ボールが見つからないビンをランダムに選ぶことができ、それは近似的にｅ^{−２＾（１０−ｉ）}とすることができるので、Ｐ_ｉ＝１−ｅ^{−２＾（１０−ｉ）}となる。

この時点で、ホップの期待数を計算することができる。ｉ≦９として、ｐ_ｉ＝Ｐ_ｉ−Ｐ_ｉ＋１とする。ここで、ｐ_ｉはＳＳＲＴ_Ａを使用して正確にｉビットが解決される確率である。次式が成り立つことが分かる。
Ｈ＝１・ｐ_９＋２・ｐ_８＋３・ｐ_７…
＝１・（ｐ_９−ｐ_１０）＋２・（ｐ_８−ｐ_９）＋３・（ｐ_７−ｐ_８）…
＝ｅ^−１＋ｅ^−２＋ｅ^−４…
＝０．５２

したがって、ブロックＡ（１ホップしか必要としない最終ブロック以外の他の任意のブロック）を解決するには、平均で１・５２ホップを必要とする。したがって、Ｎが１兆に等しいとする場合、平均的なルーティングは、約５．５ホップを必要とする。

１兆ノードのシステムに関してパフォーマンスを説明した。一般に、平均パフォーマンスは、（［ｌｏｇ_１０２４Ｎ−１］）・１．５２＋１の限度内に抑えられる。したがって、Ｎ＝２５６０００の場合、最悪時のパフォーマンスは、高い確率で、２．５２ではなく２．０２となる。例えば、ＳＳＲＴ_Ａは、１．０２の期待ホップ数で、８ビットを解決できるだけである。この時点で、残りの１０フィンガを用いて作成されたフルクロスバー（full crossbar）が、最後のホップを実行する。同様に、Ｎ＝２億５６００万の場合、パフォーマンスは高い確率で３．５４ホップの限度内に抑えられる。

メンテナンスコストおよび堅牢性（Maintenance Cost and Robustness）
上述したように、１つのリングで１千ノードの領域クラスタをメンテナンスするのにかかる全体コストは、チャーンレートμ＝１／（３時間）とした場合、約１ｋｂ／ｓである。４つのリングからなるＳＳＲＴをメンテナンスするには、上記コストの約４倍かかる。したがって、各ノードは、ＳＳＲＴのメンテナンスに全部で４ｋｂ／ｓを消費する。その他のコストには、リーフセットメンバーおよび４つのリングすべてのフィンガの間での定期的プロービングなどがあるが、メンテナンスに比べれば相対的に僅かなコストしかかからない。これが、１兆ノードのシステムの平均ルーティングパフォーマンスである５．５ホップを与えることに留意されたい。

適応（Adaptation）
先の例示的なルーティング技法で表される帯域消費が帯域予算（bandwidth budget）Ｑに一致する場合であっても、帯域消費（bandwidth consumption）のピークに遭遇することがあり得る。したがって、先に図２に関連させて述べたように、追加の帯域が利用可能になるまで、イベントを図２のキュー２０８（ｘ）に内部的にバッファすることができる。様々なその他の適応技法も、システムに動的変化が生じた場合にＳＳＲＴの品質を制御するために利用することができる。例えば、ストレス下で適切にルーティングパフォーマンスを低下させて、後で通常のルーティングパフォーマンスに戻す、適応技法を利用することができる。

そのような適応技法のうちの例示的な第１の技法は、高いチャーンレートμに対処して、システムを定常状態下での平衡に安定させもする。この適応技法は、ブロードキャストトラフィックを適応的に制御するため、レポートに含まれる冗長なイベントの「取り除き（pruning）」を含む。最終的な結果として、高品質のＳＳＲＴが、良好に維持される。冗長なイベントを含まないようにするレポートの構成については、図８に関連させてさらに説明する。

そのような適応技法のうちの例示的な第２の技法は、第１の適応技法の上に構築され、ＳＳＲＴは、図３に関連して示されるような全リソース空間の部分をカバーするクロスバーとなる。第１および第２の適応技法は、各ノードに含まれるＳＳＲＴを形成するために組み合わせることができ、各ノードのＳＳＲＴを組み合わせた場合、２つの最適化を組み合わせたことによって、マルチレベルのアーキテクチャが得られる。例えば、第１のレベルは全リソース空間にわたり、第２のレベルは領域クロスバーを提供する、２レベルのアーキテクチャを利用することができる。別の例では、図５に関連して説明したような、４レベルのアーキテクチャを利用することができる。このハイブリッド手法によって、多数のノードを有するシステムで、帯域予算（bandwidth budget）Ｑを超えることなく、Ｏ（１）を達成することができる。

一実施形態において、状態が「オンライン（online）」であるＳＳＲＴエントリのサブセットを、「ｅＳＳＲＴ」で表すものとする。状態ができるだけ正確であることを保証するため、ｅＳＳＲＴサイズを犠牲にしてフィルタリングを利用することができる。すなわち、低いフォールスポジティブ（false-positive）率が、より多くのフォールスネガティブ（false-negative）エントリによって達成される。論理的根拠は、「ミス（miss）」は一般に「ヒット（hit）」よりもコストが高いという点にある。

この目標を達成するため、フィルタリングは、様々な規則を利用することができ、以下にその例を示す。
１．低いフォールスポジティブ率を保証するため、離脱イベントをより高い優先度で送信する。
２．イベントが状態を変化させるものではない場合、そのイベントは伝播させない。

第２の規則は、ステートマシン（state machine）を使用することによって実施することができる。例えば、イベントタイプがステートマシンによって指示される現在の状態と一致する場合は、現在の状態への変更は行われずにタイムスタンプが更新され、一致しない場合は、状態がネゲートされる。後者の場合、送信済（has-sent）フィールドもネゲートされる。例えば、エントリの状態が「オンライン」で、送信済が偽（false）である場合に、「離脱」イベントを受信すると、状態は「オフライン（offline）」に変更され、送信済には真（true）がセットされる。言い換えると、この特定のイベントは、さらに伝播させる必要がない。したがって、冗長なメッセージは、イベントのバッファリングを用いて取り除かれる。

バッファされたイベントは、将来受信するそのようなイベントを取り除くのに役立つので、これらの技法を利用することによって、システムは自動的に平衡に達する。チャーンレートμが高い場合、適応の初期には、離脱イベント（leave events）が帯域の割当量の大部分を占有することがあり、その場合、「オーバフロー（overflow）」加入イベントはバッファされる。後の時点で、バッファされた加入イベントは、離脱イベントを受信したときに取り消し、それによって、加入イベントを解放するための割当てを与える。チャーンレートμが安定した場合、加入イベントと離脱イベントを送信するのに使用されるネットワークおよびノードリソースは、最終的にそれぞれほぼ等しく分配される。したがって、チャーンレートが高いほど、ピアツーピアネットワークにおけるネットワークリソースの全体的使用を削減する上で、この手法は効果的となる。第２に、バッファされたイベントは、帯域の割当量が再び利用可能になったときに解放され、システムがイベントのストーム（例えば、特定の時点で伝達される複数のイベントを生じさせるメンバーシップの目まぐるしい変更）を切り抜け、後で速やかに通常のパフォーマンスレベルに戻ることを可能にする。このようにして、堅牢なルーティング技法が提供される。

設定調整（Set-Reconciliation）
大きなルーティングテーブルを利用するＤＨＴルーティング技法にとっての１つの実際的な問題は、復帰ピアのルーティングテーブルをいかにして最新にするかということであり、「設定調整」と呼ばれる。例えば、先に説明したルーティング技法では、復帰ノードのリーフセットとフィンガテーブルは、ノードがピアツーピアネットワークに加入するたびに新しく作成されることがあるので、ピアツーピアネットワークに加入するときに、いかにして最新のＳＳＲＴを取得するかという形で問題が生じる。

ＳＳＲＴは、例えば、安定したバックグラウンドのストレージに保持することができ、そのメンバーシップリスト（例えば、他のすべてのノードの＜ＩＤ，ＩＰ＞ペアを有するエントリ）は、ノードがその過去の履歴から習得したあらゆることを含む。システムにとって完全に新しいノードは、初めて加入したときに、ＳＳＲＴをコピーすることができる。したがって、システムが十分な期間動作したとき、ＳＳＲＴにセットされるメンバーシップリストは、一般にシステム全体にわたって一致している。

しかし、離脱したノードがピアツーピアネットワークに復帰（例えば、ピアツーピアネットワークに加入）する場合、加入ノードは、対応するＳＳＲＴに記録されたピアの状態について知らないことがある。したがって、加入ノードは、ＳＳＲＴの各エントリをオフライン状態にリセットし、ピアツーピアネットワークの１つまたは複数の既存ノードから知ろうと試みることがある。例えば、２つのノードのＳＳＲＴが互いに同期している場合、既存ノードは、既存ノードのＳＳＲＴから、各ビットで他のピアの状態を表すようにしたベクトルを送信することができる。チャーンレートμが高く、オンラインエントリの数が少ない場合は、例えば、ｅＳＳＲＴをコピーするのが現実的である。例えば、１２８ｋｂ／ｓのリンクを介して、３２バイトのエントリを約４Ｋほど転送するのに、約８秒かかることがある。しかし、チャーンレートμが低かったり、または超大規模システムである場合は、これは堅牢な解決策とはなり得ない。

ＳＳＲＴエントリを表すデータをより効率的に伝達するため、ブルームフィルタを用いてデータを圧縮し、ＳＳＲＴを更新するのに利用される帯域量を削減することができる。このように、超大規模システムにおいて、効率的な通信を提供することができる。ブルームフィルタは、単一のビット配列への複数のハッシュ関数を使用することによって、大きな集合における帰属関係をテストするのに使用される確率的アルゴリズムである。ブルームフィルタは、例えば、空間／帯域が問題とされており、僅かな誤りなら許容できる場合に効果的に機能し得る。

ブルームフィルタでは、例えば、ｎ個の項目からなるリストをｍビットに、すなわち、項目当たりｂ＝ｍ／ｎに圧縮することができ、「ｂ」は「フィルタパラメータ（filter parameter）」を表す。各項目について、値域が［０．．ｍ］の１組のハッシュ関数が適用され、ｍビットベクトルの対応するビットを設定する。ブルームフィルタの副作用は、フォールスポジティブが生じ得ること、すなわち、受信ノードが元のリストには存在しないいくつかの要素を誤って含む場合があることである。そのような確率は、（０．６１８５）^ｂで示され、ｍ＝８ｎの場合、確率は０．０２を僅かに超える。

項目のサイズがＥバイトである場合、ｎＥバイトのリストを送信する代わりに、フィルタのサイズを、ｂ＝８の８ｎビット（すなわち、ｎバイト）とすると、１／Ｅの圧縮率が得られる。例えば、ノードＩＤとＩＰアドレスは伝送するが、タイムスタンプは伝送しない場合、Ｅは約３２バイトとなり、結果の１／３２の圧縮率はかなり良い率である。一実施形態では、第１のプロトコルは、オンラインではないエントリに対してブルームフィルタを適用する。ブルームフィルタのフォールスポジティブのため、受信側でオンラインノードの２％がオフラインとして記録されることになる。

別の実施形態では、「反復ブルームフィルタ（iterative bloom filter）」を使用することによって、精度をさらに高めることができる。例えば、送信ノード、すなわち、受信ノードのＳＳＲＴを更新するためのデータを送信するノードは、最初に、より小さなフィルタパラメータａを用いて、オンラインノードＰ（存在）のフィルタを計算する。送信ノードは、次に、フォールスポジティブノードの組Ａ⊂Ｐを識別し、フィルタパラメータｂを持つ補足フィルタを適用する。その後、両フィルタが、受信ノード、すなわち、ＳＳＲＴを更新するためのデータを要求するノードに送信される。定性的に言えば、いくつかのオンラインノードが見落とされるので、この手法も従来のものと同じである。定量的に言えば、ブルームフィルタの誤り率はフィルタパラメータだけに依存するので、そのようなエントリの数は、シングルレベルのブルームフィルタと同じである。

図７に、例示的な反復ブルームフィルタ７００を示す。反復ブルームフィルタ７００は、３つで１組のブルームフィルタ７０２（１）〜７０２（３）を含むように示されている。Ｐ７０４およびＡ７０６は、各フィルタのフォールスポジティブエントリの組である。

反復手法が帯域の節約を可能にするかどうかを計算するため、オフラインノードおよびオンラインノードの数を、それぞれＮ_ａ、Ｎ_ｐとする。シングルレベルのｂビットブルームフィルタの場合、メッセージ全体のサイズはｂＮ_ａビットである。反復方法の第１のフィルタは、ａＮ_ｐのメッセージサイズを持つ。Ａのサイズ、すなわち、フォールスポジティブエントリの数は、Ｎ_ａ（０．６１８５）^ａである。したがって、補足フィルタは、Ｎ_ａｂ（０．６１８５）^ａのサイズをもち、その結果、メッセージ全体のサイズＳは次式で表すことができる。

Ｓ＝Ｎ_ａｂ（０．６１８５）^ａ＋ａＮ_ｐ
最小のメッセージサイズを得るため、次式を観察する。

「ａ」は負でない整数なので、上記の式は、以下の２つのケースに分けることができる。

上記の例示的な実施形態では、フィルタパラメータｂが８に等しく、Ｎ_ａがＮ_ｐの２５％より小さい場合に、シングルレベルのブルームフィルタを採用することができる。これのための例示的な疑似コードを以下に示す。
OnSetReconcileRequest()
N_p = SSRT.OnlineSet.Size
N_a = SSRT.OfflineSet.Size
if (N_p < 0.4805 * N_a * b)
a = log(N_p / (0.4805 * N_a * b)) / log(0.6185)
F1 = BloomFilterPack(SSRT.OnlineSet, a)
P = BloomFilterUnpack(SSRT, F1)
A = P - SSRT.OnlineSet
F2 = BloomFilterPack(A, b)
Send(F1, F2)
else
F1 = BloomFilterPack(SSRT.OfflineSet, b)
Send(F1, 0)
OnSetReconcileAck(F1, F2)
foreach(entry ∈ SSRT)
if InBloomFilter(entry, F1)
if F2 == 0 or not InBloomFilter(entry, F2)
entry.status = online

上記の設定調整の疑似コードにおいて、ｂは（例えば、８に）事前定義されており、受信側でのＳＳＲＴエントリはすべて、最初はオフライン状態にあるとする。

例示的な手順（Exemplary Procedures）
先に説明したシステムおよびデバイスを利用して実施できるＳＳＲＴの更新および構成について以下で説明する。各手順の態様は、ハードウェア、ファームウェア、ソフトウェア、またはそれらの組み合わせで実施することができる。手順は、１つまたは複数のデバイスによって実行される動作を詳述するブロックの組として示されている。手順は、個々のブロックによる動作を実行する図示された順番に必ずしも限定されるものではない。

図８は、ノードが、当該ノードによって受信されたピアツーピアネットワークにおけるメンバーシップ変更を通知するイベントを示すレポートを形成し、伝達する例示的な実施形態における手順８００を示したフローチャートである。ブロック８０２で、ノードが、ピアツーピアネットワークにおけるメンバーシップ変更を通知するイベントを受信する。例えば、第１のノードは、ランダムな識別子ＩＤを選択し、その識別子がすでにピアツーピアネットワークに含まれているかどうかを決定するために検索を実行することができる。識別子は、ピアツーピアネットワークにおける第１のノードのアドレスと考えることができる。識別子ＩＤがまだピアツーピアネットワークに含まれていない場合、第１のノードは、ＩＤ’で表される次に最も高い識別子を有する「後続（successor）」ノードを見つけ、第１のノードがピアツーピアネットワークに加入したことを後続ノードに通知することができる。通知は、後続ノードに「加入」イベントを送ることによって実行することができる。

判断ブロック８０４で、ノードが以前にそのイベントを受信したかどうかについて判定が行われる。ノードが以前にそのイベントを受信している場合（ブロック８０４）、そのイベントは削除される（ブロック８０６）。したがって、この例では、イベントは、ノードによって２回以上伝達されることはない。別の例では、イベントを所定の回数伝達するための閾値を利用して、ピアツーピアネットワークを実施するシステムにおいて所望の冗長性を提供することができる。

ノードが以前にそのイベントを受信していない場合は（ブロック８０４）、判断ブロック８０８で、他のノードにイベントを伝達するための閾値が超えられたかどうかについて判定が行われる。閾値が超えられた場合（ブロック８０８）、そのイベントはキュー（queue）に追加される（ブロック８１０）。このように、手順８００は、所定の期間に所定数以下のイベントを伝達することによって、ピアツーピアネットワークにおけるメンテナンスコストを管理することができる。

閾値が超えられていない場合（ブロック８０８）、またはイベントをキューに追加した後、判断ブロック８１２で、所定のブロードキャスト時間がきたかどうかについて判定が行われる。例えば、ピアツーピアネットワークの各ノードは、そのノードによって受信されたイベントを異なる所定の間隔でブロードキャストして、そのイベントを伝達するのに利用されるネットワークリソースにコストを「拡散（spread-out）」させることができる。所定のブロードキャスト時間がきていない場合（ブロック８１２）、手順８００は、ブロック８０２に復帰し、追加のイベントがあれば、そのイベントを受信する。

そのノードにとっての所定のブロードキャスト時間がきた場合（ブロック８１２）、そのイベントを含んだレポートが形成される。例えば、ノードは、複数のノードから受信したイベントを集約して、それらのイベントを有する単一の情報を送信することができる。イベントは、ブロック８１０で保存されたイベントのキューから、および／またはノードで受信されたイベントを保存するのに利用されたその他の記憶デバイスから取得することができる。

ブロック８１６で、レポートをどこにブロードキャストするかを決定するため、ルーティングテーブルが調査される。ブロック８１８で、レポートが、ルーティングテーブル内で参照される各ノードに並列にブロードキャストされる。個々のブロック８１６、８１８でのルーティングテーブルおよびブロードキャストは、様々な方法で実行することができる。例えば、ルーティングテーブルは、複数の他のノードを表すのに対数関数を利用する図１のフィンガテーブル１１４として構成することができる。フィンガテーブル１１４は、エントリに対応するノードをプロービング（probe）することによって更新することができる。先に説明したように、図１のフィンガテーブル１１４の「フィンガ」は、当該ノードが存在する領域内のノードにレポートが配布されるように、適切な冗長性を有するブロードキャストグラフを形成する。別の実施形態では、領域の外部に存在する他のノードにレポートをブロードキャストするため、フィンガを利用することもできる。

レポートを受信した各ノードは、レポートに示されたイベントが、各後続ノードに含まれるフィンガテーブル内で参照されるノードにブロードキャストされるように、手順８００を実行することができる。したがって、イベントは、個々のフィンガテーブルのフィンガによって定義されるブロードキャストグラフを介して、イベントを伝達することによって、発信元ノードからその他のすべてのノードに広められる。イベントが他のノードで受信されると、他のノードは、イベントの配布に関して発信元ノードを支援する。

レポートに示されるイベントは、各ノードに含まれる個々のＳＳＲＴを更新するため、各ノードによって利用することができる。したがって、ＳＳＲＴは、所望のデータを見つけるのに必要なホップ回数を減らし、ルーティングテーブルをメンテナンスするのに利用されるネットワーク帯域量を減らすために利用することができる。

図９は、ノードの利用可能なリソースに基づいてルーティングテーブルのサイズが動的に決定される例示的な実施形態における手順９００を示したフローチャートである。ピアツーピアネットワークのいくつかの実施形態では、ネットワークの各々のノードは、等しいハードウェア、ソフトウェア、および／またはネットワークリソースにアクセスできないことがある。例えば、図１に示すように、コンピューティングデバイス１０４（Ｂ）は、大量のハードウェアリソースおよびソフトウェアリソースを持つことができるが、コンピューティングデバイス１０４（１）は、携帯可能に設計されているため、限られたハードウェアリソースおよびソフトウェアリソースしか持つことができない。さらに、１つのノードはダイアルアップ接続を利用でき、別のノードはデジタル加入者線（ＤＳＬ）を利用できるなど、ネットワークに接続するための帯域が、ノードによって異なることがある。これら各ノードのルーティングテーブルは、利用可能なリソースと合致する方法でピアツーピアネットワークにおけるルーティングを扱えるようにノードが構成されるよう、ノードの利用可能なリソースに基づいて動的に構成することができる。

ブロック９０２で、例えば、ノードがピアツーピアネットワークに加入する。例えば、ノードは、先に説明したように、ランダムな識別子を生成することができる。ブロック９０４で、ノードは、利用可能なハードウェア、ソフトウェア、および／またはネットワークリソースを判定する。例えば、ノードは、ノードの処理能力および記憶能力を判定するソフトウェアモジュールを実行することができる。ソフトウェアモジュールは、実行されたときに、既知のネットワーク送信先から応答を受信するのにかかる時間量を判定することなどによって、ネットワーク接続の利用可能な帯域も判定することができる。

ブロック９０６で、リソースの判定（ブロック９０４）に基づいて、ノードのルーティングテーブルを構成する。一例では、ソフトウェアモジュールは、ネットワーク接続の帯域に基づいて、ルーティングテーブルに含めることのできるエントリの量を示す様々な閾値を保存することができる。例えば、ノードがダイアルアップ接続を介して接続される場合、ノードがケーブルモデムを介して接続される場合より少ないエントリを持つように、ルーティングテーブルを構成することができる。

別の例では、ソフトウェアモジュールは、ルーティングテーブルのサイズが、ピアツーピアネットワークの他のルーティングテーブルのサイズと調整のとれたものになるように、ノードの利用可能なハードウェア、ソフトウェア、および／またはネットワークリソースを、ネットワークの他のノードのものと比較することができる。例えば、ノードがピアツーピアネットワークに加入したとき、ノードは、先に説明したように、後続ノードを見つけることができる。見つかった場合、ノードは、後続ノードのハードウェア、ソフトウェア、および／またはネットワークリソースに基づいて構成されたルーティングテーブルサイズを判定するため、後続ノードに問い合せを行うことができる。ノードはその後、利用可能なリソースを後続ノードの利用可能なリソースと比較することができ、比較に基づいたエントリ数を持つルーティングテーブルを構成することができる。例えば、ノードが後続ノードよりも多くのリソースを持つ場合、ノードは、後続ノードのルーティングテーブルよりも多くのエントリを有するルーティングテーブルを構成することができる。リソースを比較し、しかるべくルーティングテーブルを構成するため、様々なアルゴリズムを利用することができる。

さらに、ノードがピアツーピアネットワークのメンバーである場合、定期的な間隔でルーティングテーブルを再構成することができる。例えば、ノードがピアツーピアネットワークのメンバーである間、ノードはリソースの定期的な判定を行うことができる。したがって、ノードがピアツーピアネットワークのメンバーである間、ピアツーピアネットワークの対応するノードの利用可能なリソースを反映するようにルーティングテーブルを構成することができ、ノードの現在利用可能なリソースを反映するようにルーティングテーブルをメンテナンスすることができる。

例示的なコンピューティングデバイス（Exemplary Computing Device）
本明細書で説明した様々なコンポーネントおよび機能は、複数の個別のコンピュータによって実施することができる。図１０に、ピアツーピアネットワークでノードを供給するのに適した、参照番号１００２で参照されるコンピュータを含む、コンピュータ環境１０００の典型例のコンポーネントを示す。コンピュータ１００２は、図１の複数のクライアント１０２（ａ）および複数のコンピューティングデバイス１０４（１）〜１０４（Ｂ）と同じであってもよく、異なっていてもよい。図１０に示すコンポーネントは例に過ぎず、本発明の機能の範囲について何らかの限定を暗示するよう意図したものではない。本発明は、図１０に示す特徴に必ずしも依存しない。

一般に、様々な異なる汎用または専用コンピューティングシステム構成を使用することができる。本発明で使用するのに適した周知のコンピューティングシステム、環境、および／または構成の例として、パーソナルコンピュータ、サーバコンピュータ、ハンドヘルドまたはラップトップデバイス、マルチプロセッサシステム、マイクロプロセッサベースシステム、セットトップボックス、プログラム可能な家電、ネットワークＰＣ、ネットワーク対応デバイス、ミニコンピュータ、メインフレームコンピュータ、および上記のシステムまたはデバイスのいずれかを含む分散コンピューティング環境などを挙げることができるが、これらに限定されるものではない。

コンピュータの機能は、多くの場合、コンピュータによって実行される、ソフトウェアコンポーネントなどのコンピュータ実行可能命令によって実施される。一般に、ソフトウェアコンポーネントには、特定のタスクを実行し、または特定の抽象データ型を実装するルーチン、プログラム、オブジェクト、コンポーネント、およびデータ構造などが含まれる。タスクは、通信ネットワークを介して接続されたリモート処理デバイスによっても実行することができる。分散コンピューティング環境では、ソフトウェアコンポーネントは、ローカルおよびリモートコンピュータ記憶媒体に配置することができる。

命令および／またはソフトウェアコンポーネントは、コンピュータの一部であるか、またはコンピュータによって読むことができる様々なコンピュータ可読媒体に異なる時点で保存される。プログラムは一般に、例えば、フロッピディスク、ＣＤ−ＲＯＭ、ＤＶＤ、または変調信号など何らかの形態の通信メディアによって配布される。そこから、プログラムは、コンピュータの２次メモリにインストールまたはロードされる。実行時、プログラムは、コンピュータの１次電子メモリに少なくとも部分的にロードされる。

説明のため、プログラム、およびオペレーティングシステムなどのその他の実行可能プログラムコンポーネントは、図１０では別個のブロックとして示されているが、そのようなプログラムおよびコンポーネントは、コンピュータの異なる記憶コンポーネントに様々な時点に存在し、コンピュータのデータプロセッサによって実行されることを理解されたい。

図１０を参照すると、コンピュータ１００２のコンポーネントには、プロセッシングユニット１００４、システムメモリ１００６、およびシステムメモリを含む様々なシステムコンポーネントをプロセッシングユニット１００４に結合するシステムバス１００８が含まれるが、これらに限定されるものではない。システムバス１００８は、様々なバスアーキテクチャのいずれかを使用する、メモリバスまたはメモリコントローラ、周辺バス、およびローカルバスを含む複数のタイプのバス構造のいずれであってもよい。

コンピュータ１００２は一般に、様々なコンピュータ可読媒体を含む。コンピュータ可読媒体は、コンピュータ１００２によってアクセス可能な任意の利用可能媒体とすることができ、揮発性および不揮発性媒体、着脱可能および着脱不能媒体が含まれる。例えば、コンピュータ可読媒体として、コンピュータ記憶媒体と通信メディアを挙げることができるが、これらに限定されるものではない。「コンピュータ記憶媒体」には、コンピュータ可読命令、データ構造、プログラムモジュール、またはその他のデータといった情報を記憶するための任意の方法または技法で実施される、揮発性および不揮発性媒体と、着脱可能および着脱不能媒体がある。コンピュータ記憶媒体として、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリ、もしくはその他のメモリ技術、ＣＤ−ＲＯＭ、ＤＶＤ（デジタルビデオディスク）、もしくはその他の光ディスク記憶、磁気カセット、磁気テープ、磁気ディスク記憶、もしくはその他の磁気記憶デバイス、または所望の情報を記憶するのに使用でき、コンピュータ１００２によってアクセスできる、その他の任意の媒体を挙げることができるが、これらに限定されるものではない。通信メディアは一般に、搬送波またはその他の移送機構などの変調データ信号によって、コンピュータ可読命令、プログラムモジュール、データ構造、またはその他のデータを表すものであり、任意の情報送達媒体を含む。「変調データ信号」という語は、信号中に情報を符号化するようにその特性の１つまたは複数が設定または変更された信号を意味する。例えば、通信メディアとして、有線ネットワークまたは直接線接続などの有線媒体、および音響、ＲＦ、赤外線、その他のワイアレス媒体などのワイアレス媒体を挙げることができるが、これらに限定されるものではない。上記の媒体のどのような組み合わせも、コンピュータ可読媒体の範囲に含まれるものとする。

システムメモリ１００６は、ＲＯＭ（読み取り専用メモリ）１０１０および／またはＲＡＭ（ランダムアクセスメモリ）１０１２などの、揮発性および／または不揮発性メモリの形態をとるコンピュータ記憶媒体を含む。基本入出力システム（ＢＩＯＳ）１０１４は、起動中などにコンピュータ１００２内の要素間の情報伝送を助ける基本ルーチンを含み、一般にＲＯＭ１０１０に記憶しておかれる。ＲＡＭ１０１２は一般に、プロセッシングユニット１００４が直ちにアクセス可能であり、かつ／または現在それに基づいて動作している、データおよび／またはソフトウェアコンポーネントを含む。例えば、図１０には、オペレーティングシステム１０１６、アプリケーションプログラム１０１８、ソフトウェアコンポーネント１０２０、およびプログラムデータ１０２２が示されているが、これらに限定されるものではない。

コンピュータ１００２はまた、その他の着脱可能／着脱不能、揮発性／不揮発性コンピュータ記憶媒体も含む。図１０には、着脱不能な不揮発性の磁気媒体に対して読み書きを行うハードディスクドライブ１０２４、着脱可能な不揮発性の磁気ディスク１０２８に対して読み書きを行う磁気ディスクドライブ１０２６、およびＣＤ−ＲＯＭやその他の光媒体など着脱可能な不揮発性の光ディスク１０３２に対して読み書きを行う光ディスクドライブ１０３０が、例としてのみ示されている。例示的な動作環境で使用可能なその他の着脱可能／着脱不能、揮発性／不揮発性コンピュータ記憶媒体として、磁気テープカセット、フラッシュメモリカード、デジタル多用途ディスク、デジタルビデオテープ、ソリッドステートＲＡＭ、およびソリッドステートＲＯＭなどを挙げることができるが、これらに限定されるものではない。ハードディスクドライブ１０２４は一般に、データ媒体インタフェース１０３４などの着脱不能メモリインタフェースを介してシステムバス１００８に接続され、磁気ディスクドライブ１０２６および光ディスクドライブ１０３０は一般に、着脱可能メモリインタフェースによってシステムバス１００８に接続される。

上で説明し、図１０に示すドライブおよびそれに関連するコンピュータ記憶媒体は、コンピュータ可読命令、データ構造、ソフトウェアコンポーネント、およびその他のデータの記憶保持をコンピュータ１００２に提供する。図１０には、例えば、オペレーティングシステム１０１６’、アプリケーション１０１８’、ソフトウェアコンポーネント１０２０’、およびプログラムデータ１０２２’を記憶するハードディスクドライブ１０２４が示されている。これらのコンポーネントは、オペレーティングシステム１０１６、アプリケーション１０１８、ソフトウェアコンポーネント１０２０、およびプログラムデータ１０２２と同じであってもよく、異なっていてもよいことに留意されたい。オペレーティングシステム１０１６’、アプリケーション１０１８’、ソフトウェアコンポーネント１０２０’、およびプログラムデータ１０２２’には、少なくともそれらが異なるコピーであることを示すため、図１０では異なる番号が振られている。ユーザは、キーボード、およびマウス、トラックボール、またはタッチパッドなどと一般に呼ばれるポインティングデバイス（図示せず）などの入力デバイスを介して、コンピュータ１００２にコマンドおよび情報を入力することができる。その他の入力デバイスとして、（ストリームデータを提供するマイクロフォン１０３８やカメラ１０４０などの）ソースデバイス、ジョイスティック、ゲームパッド、衛星パラボラアンテナ、またはスキャナなどを挙げることができる。上記およびその他の入力デバイスは、システムバスに結合された入出力（Ｉ／Ｏ）インタフェース１０４２を介して、しばしばプロセッシングユニット１００２に接続されるが、パラレルポート、ゲームポート、またはＵＳＢ（ユニバーサルシリアルバス）など、その他のインタフェースおよびバス構造によって接続することもできる。モニタ１０４４またはその他のタイプのディスプレイデバイスも、ビデオアダプタ１０４６などのインタフェースを介して、システムバス１００８に接続される。モニタ１０４４に加えて、コンピュータは、Ｉ／Ｏインタフェース１０４２を介して接続できる、その他の再生デバイス（例えば、スピーカ）、および１つまたは複数のプリンタも含むことができる。

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

ＬＡＮネットワーク環境で使用する場合、コンピュータ１００２は、ネットワークインタフェースまたはアダプタ１０５６を介してＬＡＮ１０５２に接続される。ＷＡＮネットワーク環境で使用する場合、コンピュータ１００２は、一般に、インターネット１０５４を介して通信を確立するためのモデム１０５８またはその他の手段を含む。モデム１０５８は、内蔵型であっても外付け型であっても良く、Ｉ／Ｏインタフェース１０４２またはその他の適切な機構を介して、システムバス１００８に接続することができる。ネットワーク接続環境では、コンピュータ１００２に関して示したプログラムモジュールまたはその部分は、リモートデバイス１０５０に記憶することができる。例えば、図１０には、リモートデバイス１０５０に存在するリモートソフトウェアコンポーネント１０６０が示されているが、これに限定されるものではない。図示のネットワーク接続は例示的なものであり、コンピュータ間の通信リンクを確立するその他の手段も使用できることが理解できよう。

むすび（Conclusion）
本発明を構造的機能および／または方法的工程に特有の言葉で説明してきたが、特許請求の範囲で確定される本発明が、説明された特定の機能または工程に必ずしも限定されるものではないことを理解されたい。むしろ、特定の機能および工程は、特許請求される発明を実施する例示的な形態として開示されたものである。

ピアツーピアネットワークを提供するように構成された環境の例示的な実施形態を示す図である。 ピアツーピアネットワークの複数のノードをより詳細に示した、例示的な実施形態によるシステムを示す図である １次元論理キー空間におけるシステムの複数のノードの複数のソフトステートルーティングテーブルのスナップショットを示した例示的な実施形態を示す図である。 識別子を循環させ、別のリングを作成することによる、与えられたブロックについてのソフトステートルーティングテーブルのエントリの作成を示した例示的な実施形態を示す図である。 図４に関連させて説明したリングのソフトステートルーティングテーブルを使用するルーティングを示した例示的な実施形態を示す図である。 ソフトステートルーティングテーブルの一部と、ソフトステートルーティングテーブルのエントリの生成を示した例示的な実施形態を示す図である。 反復ブルームフィルタを示した例示的な実施形態を示す図である。 ノードが当該ノードによって受信されたピアツーピアネットワークにおけるメンバーシップ変更を通知するイベントを示すレポートを形成し、伝達する例示的な実施形態における手順を示したフローチャートである。 ノードの利用可能なリソースに基づいてルーティングテーブルのサイズが動的に決定される例示的な実施形態における手順を示したフローチャートである。 ピアツーピアネットワークにおいてノードを提供するのに利用できる例示的なコンピューティングデバイスを示す図である。

符号の説明

１００ システム
１０２（ａ） クライアント
１０６ ネットワーク（ピアツーピアネットワーク）
１０８ ＤＨＴ
１１０（１）〜１１０（８） ゾーン
１１２ リーフセット
１１４ フィンガテーブル
１１６ ソフトステートルーティングテーブル（ＳＳＲＴ）
１１６ ＳＳＲＴ（ｘ）
２０２（ｘ） ノード
２０４（ｃ） イベント
２０６（ｘ） レポート
２０８（ｘ） キュー
５０２ ルックアップキー
５０６ ソースノード
５０８ 第１の部分
５１０ 第２の部分
５１２ 第３の部分
５１４ 第４の部分
１００４ プロセッサユニット
１００６ システムメモリ
１００８ システムバス
１０１０ ＲＯＭ
１０１２ ＲＡＭ
１０１４ ＢＩＯＳ
１０１６，１０１６’ オペレーティングシステム
１０１８，１０１８’ アプリケーション
１０２０，１０２０’ ソフトウェアコンポーネント
１０２２，１０２２’ プログラムデータ
１０３４ データ媒体インタフェース
１０３６ キーボード
１０４２ Ｉ／Ｏインタフェース
１０４４ モニタ
１０４６ ビデオアダプタ
１０５０ リモートデバイス
１０５２ ＬＡＮ
１０５４ インターネット
１０５６ ネットワークアダプタ
１０５８ モデム
１０６０ リモートソフトウェアコンポーネント

Claims (17)

1. プロセッサと通信可能に結合されたメモリにストアされたプロセッサ実行可能な命令に従って実行される方法であって、該プロセッサ上で実行される該命令に従って、
   ピアツーピアネットワーク内の複数のノードのうち少なくとも１つのノードにおいて、該ピアツーピアネットワーク内の別のノードによるメンバーシップ変更の通知を受信するステップ、
   該通知の受信に応答して、複数のソフトステートルーティングテーブルエントリであって該エントリの夫々が前記複数のノードのうちの対応するノードを参照する複数のソフトステートルーティングテーブルエントリを有するソフトステートルーティングテーブル（ＳＳＲＴ）中の少なくとも１つのソフトステートルーティングテーブルエントリを更新するステップ、ここで、前記複数のソフトステートルーティングテーブルエントリは、前記ピアツーピアネットワークの現在のメンバーシップを記述しており、及び、該ソフトステートルーティングテーブルエントリを表すデータが反復ブルームフィルタを利用して圧縮され、次いで該圧縮データを別のノードに送るために通信が行われる、
   前記メンバーシップ変更を記述したレポートを、前記１つのノードが使用するソフトステートルーティングテーブル内で参照される各ノードにブロードキャストするステップ、ここで、該レポートは、２つまたはそれよりも多いノードにおけるメンバーシップ変更を通知する２つまたはそれよりも多いノードから受信した複数の該通知を集約した後にだけ作成される、
   複数のフィンガテーブルエントリを有するフィンガテーブルをメンテナンスするステップ、ここで、該それぞれのフィンガテーブルエントリは、前記ピアツーピアネットワーク内のノードの総数がＮであるときにｌｏｇ（Ｎ）の形のプレフィックスルーチングアルゴリズムである対数関数に従うことで連続してさらなるノードを参照する、
   該ノードについてハッシュ空間を定義するリーフセットテーブルを更新するステップ、ここで、該ハッシュ空間は前記ピアツーピアネットワーク内で提供されるリソースについての情報を有する、及び、
   ノード加入通知より高い優先度をノード離脱通知に付与するステップを含むことを特徴とする方法。
2. 請求項１に記載の方法において、
   前記通知は前記ピアツーピアネットワーク内の前記別のノードに関する加入イベントまたは離脱イベントであり、及び、前記レポートは予め定められたブロードキャスト間隔で前記ソフトステートルーティングテーブル内のすべてのノードに並行してブロードキャストされることを特徴とする方法。
3. 請求項１に記載の方法において、さらに、
   前記通知が前記１つのノードによって以前に受信されたかどうかを判定し、受信されていない場合は前記レポートに前記通知を含めることによって、前記レポートを形成するステップを含み、
   ノード識別子のビットを反転して該反転の結果を利用して別のノードのアドレスを取得して該別のノードを指し示すことを特徴とする方法。
4. 請求項１に記載の方法において、
   前記ルーティングテーブルは、前記複数のノードのうち前記別のノードの少なくとも１つを参照しない、並びに、各ノードが複数のルーティングテーブルをメンテナンスし、該ルーティングテーブルの各々に異なるノードの階層が含まれ、及び、該階層の各々はアドレスが類似する別のセットとは異なるノードのセットであることを特徴とする方法。
5. 請求項１に記載の方法において、
   前記ブロードキャストするステップは所定のブロードキャスト時間がきたときに実行され、前記レポートはLog _b (Ｎ)個(ただし、Ｎは前記ピアツーピアネットワーク内のノードの総数であり、bは任意の数である)のノードにブロードキャストされることを特徴とする方法。
6. 請求項１に記載の方法において、
   前記各ノードはコンピューティングデバイスによって提供され、前記リーフセットテーブルは複数のゾーンを定義し、リソースが鍵に関連し、該複数のゾーンのうち特定のゾーンを見つけるために鍵がハッシュされ、各ゾーンが前記ピアツーピアネットワーク内で共有されるすべての鍵の一部を表し、及び、分散ハッシュテーブルに鍵の値のペアがストアされることを特徴とする方法。
7. 複数のノードを含むピアツーピアネットワークに含まれるために構成されたノードにおいて、プロセッサと通信可能に結合されたメモリにストアされたプロセッサ実行可能な命令に従って実行される方法であって、該プロセッサ上で実行される該命令に従って、
   前記ノードにおいて、前記ピアツーピアネットワーク内の別のノードによってブロードキャストされた通知を受信するステップ、
   該通知の受信に応答して、複数のソフトステートルーティングテーブルエントリであって該エントリの夫々が対応するノードを参照する複数のソフトステートルーティングテーブルエントリを有するソフトステートルーティングテーブル（ＳＳＲＴ）中の少なくとも１つのソフトステートルーティングテーブルエントリを更新するステップ、ここで、前記複数のソフトステートルーティングテーブルエントリは、前記ピアツーピアネットワークの現在のメンバーシップを記述しており、及び、該ソフトステートルーティングテーブルエントリを表すデータが反復ブルームフィルタを利用して圧縮され、次いで該圧縮データを別のノードに送るために通信が行われる、
   前記ノードについてハッシュ空間を定義するリーフセットテーブルを更新するステップ、ここで、該ハッシュ空間は前記ピアツーピアネットワーク内で提供されるリソースについての情報を有する、
   少なくとも１つの前記別のノードを定期的にプロービングすることで、前記リーフセットテーブルをメンテナンスするステップ、並びに、
   複数のフィンガテーブルエントリを有するフィンガテーブルをメンテナンスするステップを含み、
   該フィンガテーブルエントリの各々は、対応するノードの位置を記述し、該フィンガテーブルエントリの各々は、前記ピアツーピアネットワーク内のノードの総数がＮであるときにｌｏｇ（Ｎ）の形のプレフィックスルーチングアルゴリズムである対数関数に従うことで連続するノードを参照し、該フィンガテーブルは、該フィンガテーブルの該フィンガテーブルエントリにおいて参照される、前記対応するノードの各々をプロービングすることでメンテナンスされ、及び、ノード加入通知より高い優先度がノード離脱通知に付与されることを特徴とする方法。
8. 請求項７に記載の方法において、
   前記通知は加入イベントまたは離脱イベントであることを特徴とする方法。
9. 請求項７に記載の方法において、
   前記通知はフィンガテーブルを調査した後で前記別のノードによってブロードキャストされ、前記通知は冗長性を提供するための一回目に加えて一定の回数だけブロードキャストされ、及び、所定数よりも少ないイベントを所定の期間に伝達することを特徴とする方法。
10. 請求項９に記載の方法において、さらに、
    前記通知が前記ノードによって以前に受信されたかどうかを判定し、受信されていない場合は前記更新を実施するステップ、
    前記所定数のイベントが前記所定の期間に既に伝達されていれば前記通知をキューに追加するステップ、及び、
    前記所定の期間が終了した後で該追加された前記通知を送信するステップを含むことを特徴とする方法。
11. プロセッサと通信可能に結合されたメモリにストアされたプロセッサ実行可能な命令に従って実行される方法であって、該プロセッサ上で実行される該命令に従って、
    ピアツーピアネットワークに含まれるためのノードについて、該ノードが該ピアツーピアネットワークに加入した場合に該ピアツーピアネットワークにおける通信のために利用可能な該ノードのリソースを判定するステップ、ここで、該リソースは、該ノードのハードウエアリソース、ソフトウエアリソース、ネットワークリソースの少なくとも１つである、
    前記ピアツーピアネットワークにおける少なくとも１つの別のノードの利用可能なリソースを定期的な間隔で判定するステップ、
    前記ノード上で、前記ノード及び前記少なくとも１つの別のノードについての利用可能なリソースの判定に基づいて、前記ピアツーピアネットワークにおけるルーチング要求のためのルーティングテーブルを作るステップ、ここで、該ステップは、該ルーティングテーブル内のエントリの数を前記判定に基づいて導出することを含み、該エントリの数は、前記ノードの前記リソースに基づいており、該エントリを表すデータが反復ブルームフィルタを利用して圧縮され、次いで該圧縮データを別のノードに送るために通信が行われる、
    前記ノードについてハッシュ空間を定義するリーフセットテーブルを更新するステップ、ここで、該ハッシュ空間は前記ピアツーピアネットワーク内で提供されるリソースについての情報を有する、
    少なくとも１つの前記別のノードを定期的にプロービングすることで、前記リーフセットテーブルをメンテナンスするステップ、並びに、
    複数のフィンガテーブルエントリを有するフィンガテーブルをメンテナンスするステップを含み、
    該フィンガテーブルエントリの各々は、対応するノードの位置を記述し、該フィンガテーブルエントリの各々は、前記ピアツーピアネットワーク内のノードの総数がＮであるときにｌｏｇ（Ｎ）の形のプレフィックスルーチングアルゴリズムである対数関数に従うことで連続するノードを参照し、及び、ノード加入通知より高い優先度をノード離脱通知に付与することを特徴とする方法。
12. 請求項１１に記載の方法において、
    前記ルーティングテーブルの前記エントリの数は、前記少なくとも１つの別のノードのリソースに基づいて決定されることを特徴とする方法。
13. コンピュータ実行可能な命令を有するコンピュータ読み取り可能な記憶媒体であって、該命令がコンピュータにより実行されると該命令が該コンピュータに方法を実行させるコンピュータ読み取り可能な媒体において、該方法が、
    ピアツーピアネットワークにおけるメンバーシップ変更が、複数のノードのうち１つまたはそれよりも多いノードに関して、いつ発生したかを判定するステップ、ここで、前記ピアツーピアネットワーク内の前記複数のノードは、該複数のノードが提供するリソース空間を複数のゾーンに分割するために分散ハッシュテーブルを用いる、
    前記変更が発生した場合に、該変更を記述したレポートを前記複数のノードのサブセットにブロードキャストするステップ、ここで、該サブセットは該サブセット内の前記ノードの各々を参照するルーティングテーブルを調べることによって確立され、該ルーティングテーブルは複数のフィンガテーブルエントリを有するフィンガテーブルとして構成され、該フィンガテーブルエントリの各々は、対応する連続するさらなるノードの位置を、前記ピアツーピアネットワーク内のノードの総数がＮであるときにｌｏｇ（Ｎ）の形のプレフィックスルーチングアルゴリズムである対数関数に従うことで記述し、及び、ノード加入通知より高い優先度をノード離脱通知に付与し、前記ルーティングテーブルのエントリを表すデータが反復ブルームフィルタを利用して圧縮され、次いで該圧縮データを送るために通信が行われる、
    前記ノードについてハッシュ空間を定義するリーフセットテーブルを更新するステップ、ここで、該ハッシュ空間は前記ピアツーピアネットワーク内で提供されるリソースについての情報を有する、並びに、
    少なくとも１つの別のノードを定期的にプロービングすることで、前記リーフセットテーブルをメンテナンスするステップを含むことを特徴とするコンピュータ読み取り可能な記憶媒体。
14. 請求項１３に記載のコンピュータ読み取り可能な記憶媒体において、
    前記テーブルは前記サブセット内で参照される各ノードをプロービングすることによってメンテナンスされることを特徴とするコンピュータ読み取り可能な記憶媒体。
15. ピアツーピアネットワークに備えられた複数のノードを有するシステムであって、該ノードの各々がコンピュータ命令を実行するためのプロセッサを有しているシステムにおいて、
    前記複数のノードの各々におけるソフトステートルーティングテーブル（ＳＳＲＴ）であって、該テーブルの各々が前記複数のノードのセットを参照する複数のＳＳＲＴエントリを有しているソフトステートルーティングテーブル（ＳＳＲＴ）、ここで、該ＳＳＲＴエントリを表すデータが反復ブルームフィルタを利用して圧縮され、次いで該圧縮データを送るために通信が行われる、
    前記ピアツーピアネットワーク内で提供されるリソースについてのハッシュ空間を定義するリーフセットテーブル、ここで、該リーフセットテーブルは前記ノードについてハッシュ空間を定義し、該ハッシュ空間は前記ピアツーピアネットワーク内で提供されるリソースについての情報を有し、及び、前記リーフセットテーブルは少なくとも１つの別のノードを定期的にプロービングすることでメンテナンスされる、
    複数のフィンガテーブルエントリを有するフィンガテーブル、ここで、該フィンガテーブルエントリの各々は、前記ピアツーピアネットワーク内のノードの総数がＮであるときにｌｏｇ（Ｎ）の形のプレフィックスルーチングアルゴリズムである対数関数に従うことで連続してさらなるノードを参照し、該さらなるノードは、ノード識別子のビットを反転して連続するノード識別子を見つけること及び次いで該連続するノード識別子を有する連続するノードを指し示すことによって見つれられ、及び、ノード加入通知より高い優先度がノード離脱通知に付与される、
    前記セットが含む各々の前記ノードへの、前記ＳＳＲＴエントリ上での参照、並びに、
    前記セットが含む少なくとも１つの前記ノードからブロードキャストされた通知を受信したときの、該ＳＳＲＴエントリの各々に対応する更新を有することを特徴とするシステム。
16. 請求項１５に記載のシステムにおいて、
    前記通知は加入イベントまたは離脱イベントであることを特徴とするシステム。
17. 請求項１５に記載のシステムにおいて、
    前記通知は、前記少なくとも１つの前記ノードのフィンガテーブルを調査することによって、該ノードによるブロードキャストのために構成されることを特徴とするシステム。

Images