JP2009089369A - 階層的ピアツーピア・ネットワークの最適運用 - Google Patents

Abstract

【課題】階層的ピアツーピア・オーバーレイ・システムに関し、リーフノードに対するスーパーピアの比に関して、そのようなシステムの最適な運用点を決定する手法を提供する。
【解決手段】ネットワーク機能を有するエンティティ１０は、階層的ピアツーピア・ネットワークにおいて要求されるスーパーピアの、実際のネットワーク状況Ｌに依存する必要スーパーピア数Ｎ^＊ _ｓｐ、及び階層的ピアツーピア・ネットワークにおいて実際に存在するスーパーピアの現存スーパーピア数Ｎ_ｓｐを推定するための推定器１４及びコントローラ１６は、必要スーパーピア数Ｎ^＊ _ｓｐが現存スーパーピア数Ｎ_ｓｐよりも大きい場合に、ネットワーク機能を有する他のエンティティを昇格させてスーパーピアにするためのコントローラ１６を備える。
【選択図】図１

Description

本発明は、階層的ピアツーピア・オーバーレイ・システムに関し、より詳細には、リーフノードに対するスーパーピアの比に関して、そのようなシステムの最適な運用点を決定する手法に関する。

オーバーレイ・ネットワークは、下層にある他の物理ネットワークの上に築かれるネットワークである。オーバーレイの中にあるノードは、下層ネットワークの１つ又は多数の物理リンクを備える仮想又は論理リンクによって接続されると考えることができ、各々の仮想又は論理リンクはパスに対応する。一例を挙げれば、多くのピアツーピア・ネットワークは、インターネットにおいて実行されるため、オーバーレイ・ネットワークであるといえる。ダイアルアップ・インターネットは、電話網の上にあるオーバーレイの例である。オーバーレイ・ネットワークは、通常のルーティングプロトコル、例えば、ＩＰ（インターネット・プロトコル）ルーティングによってサポートされないようなアプリケーション・レベルのコンセプト、例えば、ファイル又はデータを任意のタイプとしたときにルックアップできるようにするために構築され得る。

ピアツーピア（Ｐ２Ｐ）ネットワークは、比較的少数のサーバに集結するのではなく、ネットワークにおいて、ピア又はピア・ノードと呼ばれる参加者の計算機能力及び帯域幅に主として依存するネットワークである。このようにして、ピアツーピア・ネットワークは、クライアント又はサーバの概念を有さず、ネットワーク上の他のノード又はピアに対して「クライアント」及び「サーバ」の双方として同時に機能する同等ピア・ノードの概念のみを有する。ピアツーピア・ネットワークは、典型的には、例えば、ディジタル形式のオーディオ、ビデオ、データなどを含むコンテンツ・ファイルを共有するため、又はリアルタイム・データ、例えば、電話トラフィックを伝送するために使用される。ピアツーピア・ネットワークの重要な目的は、全てのクライアントが、帯域幅、記憶空間、及び計算機能力を含むリソースを提供することである。このようにして、多くのノードが用いられシステム上の要望が増すにつれて、システムの全容量も増加する。

前述したように、ピアツーピア・オーバーレイ・ネットワークは、オーバーレイ・ネットワーク・ノードとして参加中の全ピアからなり立っている。相互に知られている２つのノードの間には、オーバーレイ・リンクが存在する。即ち、参加中のピアが、ピアツーピア・ネットワークにおいて他のピアの場所を知っているならば、前者のノードから後者のノードへの有向辺がオーバーレイ・ネットワーク内に存在する。オーバーレイ・ネットワーク内のノードが、互いに対してどのようにリンクされるかに基づいて、ピアツーピア・ネットワークは、非構造化又は構造化として分類される。

非構造化ピアツーピア・ネットワークは、オーバーレイ・リンクが恣意的に確立されるときに形成される。そのようなネットワークは容易に構成され得る。なぜなら、ネットワークに加入したい新しいピアは、他のノードの現存するリンクを複写し、時間の経過と共にそれ自体のリンクを形成できるからである。非構造化ピアツーピア・ネットワークにおいて、ピアがネットワークにおいて所望のコンテンツを発見したいならば、コンテンツを共有するピアをできるだけ多く発見するために、ネットワーク中がリクエストであふれているようにしなければならない。そのようなネットワークの主な欠点は、クエリーのアドレス解決（resolve）が必ずしも実行可能とは限らないことである。人気のあるコンテンツは、いくつかのピアにおいて入手できる可能性があり、そのようなコンテンツを探索しているピアは、それを発見する可能性があるが、ピアが、少数の他のピアのみによって共有される稀少又はそれほど人気のないコンテンツを探しているならば、探索が成功することはめったに起こらない。ピアと、ピアによって管理されるコンテンツとの間に相関が存在しないので、あふれさせたとしても所望のデータを有するピアが発見できるという保証はない。その上、あふれさせることによって、ネットワーク内に大量の信号トラフィックが更に発生し、従って、そのようなネットワークの探索効率が非常に悪くなる。

構造化ピアツーピア・ネットワークは、分散ハッシュ・テーブル（ＤＨＴ）を保守することによって、及び、各々のピアがネットワーク内のコンテンツの特定部分を担当することを許すことによって、非構造化ネットワークの制限を克服する。これらのネットワークはハッシュ関数を使用して、値、即ち、ハッシュ値を、ネットワーク内の全コンテンツ及び全ピアに割り当て、グローバルなプロトコルに従って、どのピアがどのコンテンツを担当するかを決定する。このようにして、ピアがあるデータを探索したいとき、常に、このピアはそのグローバルなプロトコルを使用して、データを担当するピアを決定し、担当するピアの方へ探索を向けることができる。ハッシュ値の用語は、特に、分散コンテンツを管理する文脈において鍵又は索引も指す。対応的に、鍵空間の用語は、可能な鍵の全集合を定義するために使用される。いくつかの公知の構造化ピア・ネットワークは、コード（Chord）、ペストリ（Pastry）、タペストリ（Tapestry）、キャン（CAN）、及びチューリップ（Tulip）を含む。

ハッシュ関数又はハッシュ・アルゴリズムは、データ、典型的には、ドキュメント、すなわち一般にはファイルを、コンピュータ又は他のデバイスによって処理されるのに適した値へ転換する再現可能な方法である。これらの機能は、任意の種類のデータから小さなディジタル「指紋」を作成する方法を提供する。ハッシュ値は、結果として生じる「指紋」である。前述したハッシュ・テーブルは、ハッシュ関数の大きな応用であり、ハッシュ値を与えられたデータ・レコードの高速ルックアップ又は探索を可能にする。

１６０ビット・ストリングの集合の周りに築かれた分散ハッシュ・テーブルといった抽象鍵空間を例として考えると、鍵空間の所有権は鍵空間区画スキームに従って参加中のノードの間で分割されてオーバーレイ・ネットワークがノードを接続するので、これらのノードが鍵空間における所与の鍵の所有者を発見することができるようになる。一度、これらの要素が整えられると、記憶及び検索のための分散ハッシュ・テーブルの典型的使用は、次のように進行する。所与のファイル名ｆ１を有するファイルを分散ハッシュ・テーブルの中に記憶するため、ｆ１のハッシュ値が決定され、１６０ビットの鍵ｋ１が生成される。その後で、メッセージｐｕｔ（ｋ１，ｄ１）が、分散ハッシュ・テーブルに参加しているノードへ送られる。ｄ１は物理アドレス、例えば、ファイル所有者のＩＰアドレスである。メッセージはオーバーレイ・ネットワークを通してノードからノードへと回送され、この回送は、ペア（ｋ１，ｄ１）が記憶されている鍵空間区画によって指定されたように、鍵ｋ１を担当する単一のノードに到達するまで続く。次に、他のクライアントは、ファイル名ｆ１を再びハッシュして鍵ｋ１を生成し、例えば、メッセージｇｅｔ（ｋ１）を用いて、ｋ１に関連付けられたデータを発見するように分散ハッシュ・テーブル・ノードに求めることによって、ファイルのコンテンツを検索することができる。メッセージは、再び、オーバーレイ・ネットワークを通して鍵ｋ１を担当するノードへルーティングされ、このノードは記憶されたデータｄ１によって返答する。データｄ１自体は、ｇｅｔメッセージと同じ経路を使用してルーティングされ得るが、典型的には、下層の物理ネットワークが提供するような異なった物理経路に基づいて、異なった経路を使用して伝送される。

上記の動作を可能にするため、分散ハッシュ・テーブルは距離関数ｄ（ｋ１，ｋ２）を採用する。この距離関数は、鍵ｋ１から鍵ｋ２までの距離の抽象概念を定義する。各ノードには単一の鍵が割り当てられる。この鍵は、ルーティングの文脈では、オーバーレイ・ネットワーク識別子とも呼ばれる。識別子ｉを有するノードは、ｉが、距離関数ｄに従って測定されたとき最も近い識別子である全ての鍵を所有する。言い換えれば、識別子ｉを有するノードは、ｉが、ｄ（ｉ，ｋ）に従って測定されたときの最も近い識別子である鍵ｋを有する全てのレコード又はドキュメントを担当する。

コードＤＨＴは、特に首尾一貫した（consistent）分散ハッシュ・テーブルである。このテーブルは鍵を円の上の点として扱い、ｄ（ｋ１，ｋ２）はｋ１からｋ２まで円の周りを時計回りに移動する距離である。このようにして、円形の鍵空間は連なっている切片へ分けられ、切片の端点がノード識別子にされる。ｉ１及びｉ２が２つの隣接したノード識別子であれば、識別子ｉ２を有するノードは、ｉ１とｉ２との間に含まれる全ての鍵を所有する。

各々のピアは他のピアへのリンクの集合を保守し、これらは一緒になってオーバーレイ・ネットワークを形成し、ネットワーク・トポロジと呼ばれる構造化された態様になるように選定される。リンクは、遠隔ピアの小さな集合に向けて、及び多数の最も近いピアへ確立される。距離関数を参照。全ての分散ハッシュ・テーブル・トポロジは、最も本質的な性質のいくつかの変形を共有する。即ち、任意の鍵ｋについて、ノードはｋを所有するか、上記で定義された鍵空間距離に関してｋへ近いピアへのリンクを有する。従って、次の欲張りアルゴリズムを使用して、鍵ｋの所有者へメッセージをルーティングすることは容易である。即ち、各々のステップで、ｋに最も近い識別子を有する近隣ノードへメッセージを回送する。そのような近隣ノードが存在しないとき、現在のノードは最も近いノードでなければならない。最も近いノードは、上記で定義されたようなｋの所有者である。この型のルーティングは、時には鍵ベースルーティングとも呼ばれる。

図６は、下層の物理ネットワーク７１０、下層の物理ネットワーク７１０の上にあるピアツーピア・ネットワークの仮想又は論理オーバーレイ・ネットワーク７２０、及びオーバーレイ・ネットワーク７２０のノード又はピアによって管理される鍵空間７３０を有するピアツーピア・オーバーレイ・ネットワークの層構造を示す。注意すべきこととして、例えば、前述したコード・リングＤＨＴシステムの場合、鍵空間７３０の鍵区画は時計回りでピアへ割り当てられるが、これは後で説明されるように、ルーティングを目的として、オーバーレイ・ネットワーク自体が、各々のノードのために２つのオーバーレイ・リンク、即ち、コード・リング構造に従って、直接に先行する近隣ノード及び直接に後続する近隣ノードへの２つのリンクだけを備えることを意味しない。

通常、鍵は、ピアのＩＰアドレス及び無作為に選ばれた文字列をハッシュ値へハッシュすることによって、ピアへ割り当てられる。ハッシュ関数を使用してソース鍵をピアへマップする副次的な目的は、負荷配分を平衡させることである。即ち、各ピアは、近似的に同数の鍵を担当するべきである。

要するに、ＤＨＴの具体的設計は、鍵空間、距離関数、鍵区画、及びリンク戦略の選択に依存する。しかしながら、ルーティングの効率に関連した良好な性質は、無料では実現されない。ＤＨＴを構造化及び保守するため、ピアは特にノードの加入と故障の問題を処置しなければならない。構造化Ｐ２Ｐネットワークにおいて近隣ノードを選ぶ自由は制限されるので、ネットワークに動的な性質を残しつつルーティングテーブルの首尾一貫性を再確立するためには、保守アルゴリズムが必要である。ネットワークによって与えられる保証の型に依存して、異なる決定論的及び確率論的保守戦略が開発された。保守行動は、様々な事象、例えば、ノードの定期的加入及び離脱、又は首尾一貫しないルーティングテーブルに起因するルーティングの失敗によってトリガされ得る。異なる保守戦略は、保守コストと、首尾一貫性の程度、従ってネットワークの失敗回復力とのトレードオフである。

しかしながら、現在のＤＨＴソリューションは、標的環境としての固定インターネットにのみ焦点を当て、モバイル・コンピューティング環境には適切でない。それらのソリューションでは、モバイル機器の主な制限、例えば、モバイル機器の低いコンピューティング及び通信能力又は高い通信コストが考慮されず、セルラ又はモバイル・アドホック・ネットワークの他の細目も考慮されない。この問題は、参加中のピアが２つのグループへ分割されるＤＨＴアーキテクチャを提供することによって対処され得る。図７を参照すると、強力なデバイスはスーパーピアＵ_１〜Ｕ_５として分類され、弱いデバイス、例えば、携帯電話はリーフノードＬ_１〜Ｌ_３と呼ばれる。図７に従った分散ハッシュ・テーブルにおいて、スーパーピアは、Ｉ．Ｓｔｏｉｃａ，Ｒ．Ｍｏｒｒｉｓ，Ｄ．Ｋａｒｇｅｒ，Ｍ．Ｋａａｓｈｏｅｋ，ａｎｄ Ｈ．Ｂａｌａｋｒｉｓｈｎａｎ， “Ｃｈｏｒｄ：Ａ Ｓｃａｌａｂｌｅ Ｐｅｅｒ−ｔｏ−Ｐｅｅｒ Ｌｏｏｋｕｐ Ｓｅｒｖｉｃｅ ｆｏｒ Ｉｎｔｅｒｎｅｔ Ａｐｐｌｉｃａｔｉｏｎｓ”， ＡＣＭ ＳＩＧＣＯＭＭ Ｃｏｎｆｅｒｅｎｃｅ，２００１で説明されるようなコード・リングに組織され、リーフノードへのプロキシとして役立つ。リーフノードはプロキシに付加され、リングに参加しない。

下記では、図７に基づいて、階層的ピアツーピア・オーバーレイ・ネットワークが詳細に説明される。前述したように、図７に従った階層システム・アーキテクチャは、ピアの２つの異なる級又は階層レベル、即ち、スーパーピア及びリーフノードを定義する。スーパーピアは、図７に示されるように、コード・リング形式によって構造化ＤＨＴベース・オーバーレイを確立する。その場合、各々のスーパーピアは、更にそのリーフノードのためにプロキシとして働く。即ち、リーフノードは、そのスーパーピアを経由してのみピアツーピア・ネットワークにおいて通信し、例えば、ピアツーピア・オーバーレイ・ネットワークにおいてドキュメントをクエリーする。このようにして、リーフノードは、そのスーパーピアへのオーバーレイ接続のみを保守する。そのスーパーピアの故障を認識すること及びそれに対応することができるように、リーフノードは簡単なＰＩＮＧ−ＰＯＮＧアルゴリズムを定期的に実行する。更に、リーフノードはシステム内の他の利用可能なスーパーピアを含むリストを記憶し、スーパーピアの故障の後でオーバーレイ・ネットワークに再加入することができる。

対照的に、スーパーピアは、複数の他のタスクを遂行する。１つの例示的実現において、ネットワークに加入しているリーフノードは、それが共有するオブジェクトへのポインタのリストを、その対応スーパーピアへ転送する。次に、スーパーピアはこれらの参照をオーバーレイ・ネットワークの中へ挿入し、それら参照の所有者として行動する。リーフノードがルックアップ、例えば、オブジェクトへのクエリーを遂行するとき、リーフノードが接続されるスーパーピアは、コード・オーバーレイの探索機能を使用することによってそのルックアップに関するアドレス解決を実行し、オブジェクトの鍵に基づいて担当のスーパーピアを決定し、結果をリーフノードへ回送する。異なる実現において、探索されるオブジェクト又はドキュメントを担当するスーパーピアは、要求されたドキュメントを、ドキュメントを要求したリーフノードへ直接伝送することによって応答し、リーフノードのために行動しているスーパーピアへ応答を提供しない。

追加的に、スーパーピアは従来のコード・リングを確立するので、それらのスーパーピアはコード保守アルゴリズムを定期的に実行し、それらスーパーピアが保守する全ての参照を定期的に新しくして、それらの参照を最新に保つ。

今後は［１］として参照されるＺｏｅｌｓ Ｓ．，Ｄｅｓｐｏｔｏｖｉｃ ｚ．，Ｋｅｌｌｅｒｅｒ Ｗ．，Ｃｏｓｔ−Ｂａｓｅｄ Ａｎａｌｙｓｉｓ ｏｆ Ｈｉｅｒａｒｃｈｉｃａｌ ＤＨＴ Ｄｅｓｉｇｎ，Ｓｉｘｔｈ ＩＥＥＥ Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｃｏｎｆｅｒｅｎｃｅ ｏｎ Ｐ２Ｐ Ｃｏｍｐｕｔｉｎｇ，Ｃａｍｂｒｉｄｇｅ，ＵＫ，２００６において、そのような階層システムが従来の平坦ＤＨＴ組織よりも勝っている次の２つの明確な利点が説明された。

第一に、保守トラフィックが実質的に低減される。このトラフィックは、前述したように、ノードがシステムに加入及び離脱するとき、ルーティングテーブルを首尾一貫性があるように保つために必要である。［１］で説明されるアーキテクチャにおいて、リーフノードがシステムから離脱するとき、ほとんど保守トラフィックは必要でない。同時に、コード・リング自体を保守するために必要なトラフィックも低減される。なぜなら、スーパーピアは、より高いオンライン時間を有するノードから選択されるためである。

第二に、［１］で説明されるように、ネットワークの全運用コストが低減される。なぜなら、通信のコストが大きいノード又はピアが少ないトラフィックを遂行するためである。

［１］において、コスト・モデルは、水平階層分散ハッシュ・テーブル（ＨＤＨＴ）の最適性のみを判断するために導入された（平坦ＤＨＴは、特殊な場合として、モデルに含められる）。最適ＨＤＨＴ構成は、［１］において、オーバーレイ・ネットワークにおいて生成された全トラフィック（「コスト」と呼ばれる）及びピアの個々の負荷の関数として定義される。更に具体的には、システムにおいて生成された全てのメッセージが計算される。メッセージの中には、クエリーに関連したトラフィック及び保守トラフィックが含まれ、スーパーピア割合α、即ち、ピアの総数Ｎによって割られた上部レベル・ピアの数Ｎ_ｓｐの関数として表される。スーパーピア割合αは、唯一の考慮されるパラメータである。

図８において、コスト曲線９０は１つの例を示す。図８は、固定数のピアＮを有する仮説シナリオに対応する。即ち、ピアの母集団は不変である。１つの極端な場合、スーパーピア割合α＝１／Ｎであるとき、全ネットワーク・トラフィックを最小化する古典的クライアント・サーバ・システムが存在する。スーパーピアの割合αが増加するにつれて、ネットワーク・トラフィック、即ち、コスト曲線９０も増加する。他の極端な場合、α＝１であるとき（リーフは存在せず、全てのピアはスーパーピアである）、平坦ＤＨＴが存在する。この場合、全ネットワーク・トラフィックは最大である。

スーパーピアの割合αの最適値を決定するため、ピアの個々のコストが考慮される。本目的のため、全ての参加中のピアｎ（ｎ＝１，２，．．．，Ｎ）について負荷因子ＬＦ_ｎが定義される。ピアｎ（ｎ＝１，２，．．．，Ｎ）の負荷因子ＬＦ_ｎは、所与の時点におけるピアｎ（ｎ＝１，２，．．．，Ｎ）のコストＣ_ｎ（ｎ＝１，２，．．．，Ｎ）と、ピアｎ（ｎ＝１，２，．．．，Ｎ）が受け入れようとしている最大コスト値（コスト限度）Ｃ^ｎ _ｍａｘとの間の比、即ち、ＬＦ_ｎ＝Ｃ_ｎ／Ｃ^ｎ _ｍａｘ（ｎ＝１，２，．．．，Ｎ）である。１つの例として、アップリンク帯域幅の消費を、考慮されるコストとして考えることができる。他の解釈、例えば、ディスク空間を考えることもできる。

最高負荷因子（ＨＬＦ）と呼ばれる数量は、最適システム構成がどのように決定されるかについて、重要な役割を演じる。ＨＬＦは、全ての参加中のピアを横切って観察され得る最大負荷因子、即ち、ＨＬＦ＝ｍａｘ_ｎ（ＬＦ_ｎ）（ｎ＝１，２，．．．，Ｎ）として定義される。再び図８において、ＨＬＦ曲線９２は１つの例を示す。スーパーピアの割合αが大きくなるにつれて、ＨＬＦが小さくなる。背後に含まれる直感的理解はきわめて明瞭といえる。すなわち、スーパーピアになるピアが多くなるにつれて、それらのピアはシステム内の負荷を共有し、最も重い負荷がかけられるピアの負荷が小さくなる。これと反対に、スーパーピアの比αが所定値よりも小さくなると、１００％を超えるＨＬＦが観察可能となる。その結果、１つ又は複数のピアが過負荷になる。なぜなら、それらのピアは、受け入れ可能なコストよりも高いコストを担うためである。一般的に、１００％よりも高いＨＬＦは、システムの安定性を確保するために回避されるべきである。

図８のシナリオにおいて、システムは均質であり、Ｎ個の全ピアはＣ^ｎ _ｍａｘについて同じ値を設定するものと仮定される。この場合、ピア間の負荷が平衡されると仮定して、図８の最高負荷曲線９２は任意のスーパーピアの負荷曲線である。システムが異質であるとき、ＨＬＦは、存在するスーパーピアの数だけでなく、どのピアがスーパーピアであるかに依存する。この場合、最高負荷曲線９２は、図８に示されるように滑らかな形状ではなく、急激に増加することとなる。

システムの最適な運用点Ａは、過負荷のピアが存在せず、同時に全ネットワーク・コストができるだけ低い点として定義される。即ち、全ネットワーク・コストは、システム内のピアを過負荷にすることなく最小化される。言い換えれば、この最適性規準は、ノード当たりの負荷は比較的に低いが全コストは高い完全非集中化システムと、ネットワークの運用部分は少ないがシステム・サーバは負荷の大部分を担う集中化システムとの間の、トレードオフを表す。

多くの階層ＤＨＴアーキテクチャが文献で提案されているが、階層Ｐ２Ｐネットワークを構築及び構成する問題を特に標的とする労作の大部分は、非構造化ネットワークを扱っている。Ｂ．Ｙａｎｇ ａｎｄ Ｈ．Ｇａｒｃｉａ−Ｍｏｌｉｎａ， “Ｄｅｓｉｇｎｉｎｇ ａ Ｓｕｐｅｒ−Ｐｅｅｒ Ｎｅｔｗｏｒｋ，” ｉｎ Ｐｒｏｃｅｅｄｉｎｇｓ ｏｆ ｔｈｅ １９ｔｈ Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｃｏｎｆｅｒｅｎｃｅ ｏｎ Ｄａｔａ Ｅｎｇｉｎｅｅｒｉｎｇ （ＩＣＤＥ０３），ｖｏｌ．１０６３，ｎｏ．６３８２／０３，２００３は、スーパーピア・ベース非構造化Ｐ２Ｐネットワークの徹底的な研究を呈示する。

Ａ．Ｍｏｎｔｒｅｓｏｒ， “Ａ ｒｏｂｕｓｔ ｐｒｏｔｏｃｏｌ ｆｏｒ ｂｕｉｌｄｉｎｇ ｓｕｐｅｒｐｅｅｒ ｏｖｅｒｌａｙ ｔｏｐｏｌｏｇｉｅｓ，” ｉｎ Ｐｒｏｃｅｅｄｉｎｇｓ ｏｆ ｔｈｅ Ｆｏｕｒｔｈ Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｃｏｎｆｅｒｅｎｃｅ ｏｎ Ｐｅｅｒ−ｔｏ−Ｐｅｅｒ Ｃｏｍｐｕｔｉｎｇ，２００４．，２００４，ｐｐ．２０２−２０９も、非構造化Ｐ２Ｐネットワークに焦点を当てている。筆者の目的は、可能な最小数のスーパーピアを有するスーパーピア・ベースＰ２Ｐネットワークを構築することである。筆者は、ノードがゴシップ・プロトコルを介してそれらノードの容量に関する情報を他の無作為選択ノードと交換し、続いて、それらノードのリーフノードを、発見された最強スーパーピアの方へ押し出そうとするアルゴリズム（ＳＧ−１と呼ばれる）を提案する。この戦略は、最終的に、スーパーピアの最小集合へ導き、この最終集合は、ネットワーク内の残りのノードをリーフとしてカバーするのに十分である。

Ｇ．Ｊｅｓｉ，Ａ．Ｍｏｎｔｒｅｓｏｒ，ａｎｄ Ｏ．Ｂａｂａｏｇｌｕ， “Ｐｒｏｘｉｍｉｔｙ−Ａｗａｒｅ Ｓｕｐｅｒｐｅｅｒ Ｏｖｅｒｌａｙ Ｔｏｐｏｌｏｇｉｅｓ，” ｉｎ Ｐｒｏｃｅｅｄｉｎｇｓ ｏｆ ｔｈｅ ２ｎｄ ＩＥＥＥ Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｗｏｒｋｓｈｏｐ ｏｎ ＳｅｌｆＭａｎ，２００６，ｐｐ．４３−５７で提案されるＳＧ−２アルゴリズムは、リーフノードとスーパーピアとの間の潜時を最小にする近接認識スーパーピア・トポロジに焦点を当てている。往復時間（ＲＴＴ）は直接に測定されるか、全てのノードを仮想空間内の位置に関連づける仮想座標サービスを介して近似される。スーパーピアはその利用可能性を仮想座標空間のそのエリア内において放送し、加入リーフノードがその近接内の最も強力なノードへ接続できるようにする。再び、ノードの容量は、特定のピアが処置できるリーフノードの最大数によって表され、これらのリーフノードはシミュレーションのために範囲［１；５００］の中に均一に分布される。先駆者ＳＧ−１と同じく、アルゴリズムは追加のシグナリング・トラフィックを必要とするが、低いＲＴＴを必要とする応用においては相当の利点をもたらす。

ピア間の区別が行われるが、ピア間に明白な階層分割を有さないＰ２Ｐアーキテクチャが、いくらか関連している。典型的には、それらのアーキテクチャは、ノード間の異質性を標的にする。背後にある理由としては、より強力なノード（又は、更に、システムへの参加から、より高い利用性を引き出すノード）は、より強力でないノードよりもオーバーレイ内において多くの働きを遂行すべきであるということである。

Ｍ．Ｃａｓｔｒｏ，Ｍ．Ｃｏｓｔａ，ａｎｄ Ａ．Ｒｏｗｓｔｒｏｎ，“Ｄｅｂｕｎｋｉｎｇ ｓｏｍｅ ｍｙｔｈｓ ａｂｏｕｔ ｓｔｒｕｃｔｕｒｅｄ ａｎｄ ｕｎｓｔｒｕｃｔｕｒｅｄ ｏｖｅｒｌａｙｓ，” ｉｎ ＮＳＤＩ’０５，Ｂｏｓｔｏｎ，ＭＡ，ＵＳＡ，２００５は、ノードの線度差をノード能力だけ偏向させることによって異質性に対処するＡ．Ｒｏｗｓｔｒｏｎ ａｎｄ Ｐ．Ｄｒｕｓｃｈｅｌ， “Ｐａｓｔｒｙ：Ｓｃａｌａｂｌｅ，ｄｉｓｔｒｉｂｕｔｅｄ ｏｂｊｅｃｔ ｌｏｃａｔｉｏｎ ａｎｄ ｒｏｕｔｉｎｇ ｆｏｒ ｌａｒｇｅ−ｓｃａｌｅ ｐｅｅｒ−ｔｏ−ｐｅｅｒ ｓｙｓｔｅｍｓ，” ｉｎ ＩＦＩＰ／ＡＣＭ Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｃｏｎｆｅｒｅｎｃｅ ｏｎ Ｄｉｓｔｒｉｂｕｔｅｄ Ｓｙｓｔｅｍｓ Ｐｌａｔｆｏｒｍｓ（Ｍｉｄｄｌｅｗａｒｅ），２００１，ｐｐ．３２９−３５０の修正を呈示する。Ｊ．Ｓａｃｈａ，Ｊ．Ｄｏｗｌｉｎｇ，Ｒ．Ｃｕｎｎｉｎｇｈａｍ，ａｎｄ Ｒ．Ｍｅｉｅｒ， “Ｄｉｓｃｏｖｅｒｙ ｏｆ ｓｔａｂｌｅ ｐｅｅｒｓ ｉｎ ａ ｓｅｌｆ−ｏｒｇａｎｉｓｉｎｇ ｐｅｅｒ−ｔｏ−ｐｅｅｒ ｇｒａｄｉｅｎｔ ｔｏｐｏｌｏｇｙ，” ｉｎ Ｐｒｏｃｅｅｄｉｎｇｓ ｏｆ ｔｈｅ ６ｔｈ ＩＦＩＰ Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｃｏｎｆｅｒｅｎｃｅ ｏｎ Ｄｉｓｔｒｉｂｕｔｅｄ Ａｐｐｌｉｃａｔｉｏｎｓ ａｎｄ Ｉｎｔｅｒｏｐｅｒａｂｌｅ Ｓｙｓｔｅｍｓ，２００６，ｐｐ．７０−８３は、最高利用度ピアをシステムの「コア」へ接続するため、いわゆる傾斜トポロジを提案する。ピアは、ゴシップを介して他のピアの利用度値Ｕに関する情報を獲得し、続いてそれに類似した値を有するノードを近隣ノードとして選択する。これは、トポロジの傾斜構造を導く。即ち、Ｕの低い値を有するピアは、コアから遠くに配置される。

［１］では、ＤＨＴシステムに対する全体的な観察を利用して、全てのシステム・パラメータ、例えば、ピアの数Ｎ、ピアの容量Ｃ、負荷、及び共有オブジェクトの数Ｆから最適な運用点Ａをどのように計算するかが示された。しかしながら、実用的Ｐ２Ｐシステム環境において、システムの状況に対する全体的な知識は入手できない。その代わりに、システムにおける単独ピアの部分的観察に頼ることだけが可能である。

従って、本発明の目的は、２層階層ＤＨＴのコスト最適な運用を実現し及び保守するアルゴリズムを提供することである。

本発明の目的は、請求項１に従ったネットワーク機能を有するエンティティ、請求項１８に従ったネットワーク機能を有するエンティティ、請求項１９に従った方法、請求事項２０に従った方法、及び請求項２１に従ったコンピュータ・プログラムによって実現される。

本発明は、ネットワーク能力を有するエンティティ、例えば、（ピアになることのできる）スーパーピアを提供することによって、階層Ｐ２Ｐネットワークのコスト最適な運用を達成及び保守することができるという知見に基づく。スーパーピアは、現在のシステムの状況を記述するシステム幅パラメータの集合に対するそれらスーパーピアの部分的見解に基づいて、システム内の現存スーパーピア数Ｎ_ｓｐを増加又は減少する必要があるかどうかを判定するアルゴリズムを実行する。

本発明は、現存スーパーピア数Ｎ_ｓｐを推定し、及び、推定された実際のネットワーク状況及びスーパーピアの現存数Ｎ_ｓｐに基づいて、階層的ピアツーピア・ネットワークで要求される必要スーパーピア数Ｎ^＊ _ｓｐを推定する推定器を備える。実施形態によれば、実際のネットワーク状況はシステム負荷因子Ｌに対応する。更に、ネットワーク機能を有するエンティティは、必要スーパーピア数Ｎ^＊ _ｓｐが現存スーパーピア数Ｎ_ｓｐよりも大きい場合に、即ち、Ｎ^＊ _ｓｐ＞Ｎ_ｓｐである場合に、ネットワーク機能を有する他のエンティティを昇格させてスーパーピアにするコントローラを備える。

本発明は、更に、スーパーピアの現存数Ｎ_ｓｐを推定し、推定された実際のネットワーク状況及びスーパーピアの現存数Ｎ_ｓｐに基づいて、階層的ピアツーピア・ネットワークにおいて要求される必要スーパーピア数Ｎ^＊ _ｓｐを推定する推定器を備えるネットワーク機能を有するエンティティを提供する。更に、ネットワーク機能を有するエンティティは、必要スーパーピア数Ｎ^＊ _ｓｐが現存スーパーピア数Ｎ_ｓｐよりも小さい場合に、即ち、Ｎ^＊ _ｓｐ＜Ｎ_ｓｐの場合に、ネットワーク機能を有するエンティティの特性としてのスーパーピアを停止させるコントローラを備える。

本発明は、更に、ネットワーク機能を有するエンティティを動作させる方法を提供する。本方法は、次のステップを備える。即ち、階層的ピアツーピア・ネットワーク内において実際に存在しているスーパーピアの数である現存スーパーピア数を推定するステップ、推定された現存スーパーピア数（Ｎ_ｓｐ）に基づいて実際のネットワーク状況を推定するステップ、推定された実際のネットワーク状況に基づいて階層的ピアツーピア・ネットワークにおいて要求されるスーパーピアの必要スーパーピア数を推定するステップ、及び必要スーパーピア数Ｎ^＊ _ｓｐが現存スーパーピア数Ｎ_ｓｐよりも大きい場合に、即ち、Ｎ^＊ _ｓｐ＞Ｎ_ｓｐである場合に、ネットワーク機能を有する他のエンティティを昇格させてスーパーピアにするステップである。

更に、本発明は、ネットワーク機能を有するエンティティを動作させる方法を提供する。本方法は、次のステップを備える。即ち、階層的ピアツーピア・ネットワーク内において実際に存在するスーパーピアの数である現存スーパーピア数を推定するステップ、推定された現存スーパーピア数（Ｎ_ｓｐ）に基づいて実際のネットワーク状況を推定するステップ、推定された実際のネットワーク状況に基づいて階層的ピアツーピア・ネットワーク内において要求されるスーパーピアの必要スーパーピア数を推定するステップ、及び必要スーパーピア数Ｎ^＊ _ｓｐが現存スーパーピア数Ｎ_ｓｐよりも小さい場合に、即ち、Ｎ^＊ _ｓｐ＜Ｎ_ｓｐである場合に、ネットワーク機能を有するエンティティの特性としてのスーパーピアを停止させるステップである。

最後に、本発明は、プログラム・コードを有するコンピュータ・プログラムを提供する。プログラム・コードは、コンピュータ・プログラムがコンピュータ及び／又はマイクロコントローラにおいて実行するとき、本発明の方法の少なくとも１つを遂行する。

本発明は、ＤＨＴの中において生成される負荷を参加中のピア上に均一に平衡させるため、バックグラウンドにおいて実行しているロードバランス・アルゴリズムが存在するという仮定に基づく。コード・ベースのピアツーピア・システムにおけるロードバランス・アルゴリズムは、システム内の全てのスーパーピアが、スーパーピアの個々の負荷限度Ｃ^ｎ _ｍａｘとは独立に、近似的に同じ負荷因子を示すことを確保すべきである。更に、全てのスーパーピアの負荷因子ＬＦ_ｎは、任意の時点で１００％に近くなければならない。それは、スーパーピアをできるだけ少なくして、全ネットワーク・トラフィックを最小にするためである。

階層的ピアツーピア・ネットワークのための、そのようなロードバランス・アルゴリズムは、例えば、欧州特許出願第０６０２４３１７．７号において説明されている。このロードバランス・アルゴリズムは、リーフノードが到着する時点において、負荷が最小にされたスーパーピアへリーフノードを割り当てることに基づく。これを可能にするため、スーパーピアは相互の負荷を認識しなければならない。これは、各スーパーピアが、近隣のスーパーピアと交換されるメッセージの中にその負荷レベルを相乗りさせる（piggyback）ことが、各スーパーピアに要求することによって実現される。これらのメッセージは、ルーティングテーブル内の項目の通常のプローブ及びクエリーメッセージを含む。負荷レベルに関する情報は、ＤＨＴグラフ内の直接の近隣へのみ通信される。即ち、それはグラフを介して更に拡散されることはない。ノードがネットワークに加入するとき、このノードは、無作為に選ばれたスーパーピアとコンタクトすることが仮定される。コンタクトされたスーパーピアは、近隣スーパーピアの負荷レベルを知ると、最低の負荷を有する近隣スーパーピアを選択し、この近隣スーパーピアに要求を回送する。この近隣スーパーピアは更に要求を処置する。あるスーパーピアが、全ての近隣の負荷レベルよりも低い負荷レベルを有することが判ると、このスーパーピアは加入ノードをリーフとして受け入れる。可能なループを回避するため、有効期間が加入メッセージへ導入される。このロードバランス・アルゴリズムにおいて、相乗りされた負荷レベルは、前述した負荷因子ＬＦ_ｎ（ｎ＝１，２，．．．，Ｎ）を意味することが想定される。このようにして、ロードバランス・アルゴリズムは、負荷因子ＬＦ_ｎ（ｎ＝１，２，．．．，Ｎ）を近似的に同じレベルにする。このようにして、全てのスーパーピアは、それ自体の負荷、従ってシステム負荷因子Ｌと呼ばれる近似（仮説）数量を追跡することができる。

本発明の実施形態は、ネットワーク機能を有するエンティティ、例えば、スーパーピアが、それ自体の負荷を調節して、できるだけシステム負荷因子Ｌの所定の閾値Ｌ_ｄｅｓへ近づけることを可能にする。必要な調節数ΔＮ_ｓｐを決定するため、全てのスーパーピアは、図８を参照して前に説明された最高負荷曲線が、スーパーピア割合αにどのように依存するかを計算する必要がある。一度、あるスーパーピアがスーパーピア調節数ΔＮ_ｓｐを計算すると、このスーパーピアは次のことを行う。即ち、新しいスーパーピアが必要とされる場合、即ち、ΔＮ_ｓｐ＞０であれば、このスーパーピアは平均して｜ΔＮ_ｓｐ｜／Ｎ_ｓｐ個のリーフノードを昇格させてスーパーピアにする。システム内にあまりに多くのスーパーピアが存在する場合、即ち、ΔＮ_ｓｐ＜０であれば、各々のスーパーピアは、確率｜ΔＮ_ｓｐ｜／Ｎ_ｓｐに従ってシステムを離脱し、リーフとして再加入する。

本発明の実施形態に従った、そのような動的コスト最適化は、前述した階層的ピアツーピア・システムの一般的利点に加えて多数の利点を提供する。そのような階層的ピアツーピア・オーバーレイ・ネットワークを主催している通信ネットワークのネットワーク運用者にとって、コストは、現在のネットワーク状況、即ち、現在のシステム負荷因子Ｌへ動的に適応する最小値へ低減され得る。注意すべきは、ネットワーク運用者の視点から全運用コストの上に焦点が置かれることである。ネットワーク運用者は、オーバーレイ・ネットワークを安定した運用モードに保ちながら、費用を最小にすることを厭わない。これは、モバイル・ネットワークにおいても現在出現しているように、ネットワーク・トラフィックがデータの消費によってはもはや請求されず、定額料金ベースで請求されるとき、特に必要である。他のアプローチも存在する。例えば、Ｊ．Ｌｉ，Ｊ．Ｓｔｒｉｂｌｉｎｇ，Ｒ．Ｍｏｒｒｉｓ，ａｎｄ Ｍ．Ｆ．Ｋａａｓｈｏｅｋ， “Ｂａｎｄｗｉｄｔｈ−ｅｆｆｉｃｉｅｎｔ ｍａｎａｇｅｍｅｎｔ ｏｆ ＤＨＴ ｒｏｕｔｉｎｇ ｔａｂｌｅｓ，” ｉｎ ＮＳＤＩ，Ｂｏｓｔｏｎ，ＵＳＡ，２００５は、全ピアツーピア・オーバーレイ間接費の低減に焦点を当てず、各ピアにおけるある利用可能なデータ転送レートを想定する。このデータ転送レートは都合のよい事態において使用可能であり、追加の保守間接費のコストでオーバーレイルーティングテーブルを適応させ、各ピアにおける利用可能データ転送レートを充足することによって、より高速な探索を可能にする。

本発明の実施形態は、運用者にとって有利であるだけでなく、ユーザは高品質のＤＨＴを呈示される。なぜなら、本発明の実施形態に従った動的保守アルゴリズムは、必要な数の高層スーパーピアをシステム内に配置して、クリティカルな、つまり、過負荷となるような事態を回避するためである。

運用者及びユーザの更なる利点は、本発明の実施形態によって実現される自己組織パラダイムである。運用者は、余分の保守間接費を有さないで、オーバーレイを安定な運用モードに保つことができ、同時にコストを節減することができる。これはユーザに対しても当てはまり、スーパーピアになろうとしているそのコンピュータが、過負荷のために機能を停止することを心配する必要はない。追加の間接費は導入されない。なぜなら、ピア間において交換される全ての追加パラメータは、定期的ＤＨＴ保守メッセージ及び探索要求と一緒に相乗りされるからである。

本発明の好ましい実施形態は、下記の図面に関して詳細に説明される。

本発明の実施形態に従ったネットワーク機能を有するエンティティ１０のブロック図は、図１に描かれる。

ネットワーク機能を有するエンティティ１０はＩ／Ｏ端末（Ｉ／Ｏ＝入力／出力）１２−ｋ（ｋ＝１，２，．．．，Ｋ）を備え、これらのＩ／Ｏ端末は、ネットワーク機能を有するエンティティ１０を、階層的ピアツーピア・ネットワーク・システムの他のネットワーク機能を有するエンティティへ接続する。ネットワーク機能を有するエンティティ１０は、更に、コントローラ１６へ結合された推定器１４を備える。

ネットワーク機能を有するエンティティ１０がスーパーピアとして機能する場合、推定器１４は、本発明の実施形態に従って、階層的ピアツーピア・システム内において要求されるスーパーピアの必要スーパーピア数Ｎ^＊ _ｓｐを推定するようになっている。ここで、要求されるスーパーピアの必要数Ｎ^＊ _ｓｐは、実際又は現在のネットワーク状況に依存する。必要スーパーピア数Ｎ^＊ _ｓｐを推定できるようにするため、推定器１４は、更に、階層的ピアツーピア・ネットワークで実際又は現在、現存しているスーパーピアの数である現存スーパーピア数Ｎ_ｓｐを推定するようになっている。現存スーパーピア数Ｎ_ｓｐは、今後は［２］として参照されるＡ．Ｂｉｎｚｅｎｈｏｆｅｒ，Ｄ．Ｓｔａｅｈｌｅ，ａｎｄ Ｒ．Ｈｅｎｊｅｓ， “Ｏｎ ｔｈｅ Ｆｌｙ Ｅｓｔｉｍａｔｉｏｎ ｏｆ ｔｈｅ Ｐｅｅｒ Ｐｏｐｕｌａｔｉｏｎ ｉｎ ａ Ｃｈｏｒｄ−ｂａｓｅｄ ｐｅｅｒ−ｔｏ−ｐｅｅｒ Ｓｙｓｔｅｍ，” ｉｎ １９ｔｈ Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｔｅｌｅｔｒａｆｆｉｃ Ｃｏｎｇｒｅｓｓ （ＩＴＣ１９），Ｂｅｉｊｉｎｇ，Ｃｈｉｎａ，２００５からのアルゴリズムに基づき、推定器１４によって推定される。［２］は、ネットワークのサイズを推定するコード特定アルゴリズムを提案している。

コード・ベースＰ２Ｐネットワークにおける現存スーパーピア数Ｎ_ｓｐの推定は、大体において、局所スーパーピアの近隣のスーパーピア密度を測定し、これをコード・リング全体のＩＤ空間へ外挿することに依存する。［２］において、スーパーピアｚ＋１がスーパーピアｚに続く確率は、次式によって示される。

式中、２^ｍはＩＤ空間のサイズであり、Ｎ_ｓｐはリング内の現存スーパーピア数である。［２］において、スーパーピアと次の近隣スーパーピアとの間の区間Ｉ（ｚ）は、近似的に幾何学的Ｉ（ｚ）とパラメータｐ＝Ｎ_ｓｐ／２^ｍを有する幾何学的（ｐ）とは準同型であることが結論される。最大尤度推定（ＭＬＥ）を使用することによって、幾何分布のパラメータｐを近似することが可能であり、結果としてスーパーピア数Ｎ_ｓｐ＝ｐ・２^ｍである。

ネットワーク内の全てのスーパーピアは、その直接後継者をそのルーティングテーブル内に保守するだけでなく、直接の近隣となっているものに到達できない場合の失敗を迂回するため後継者の全リストを保守する。このリストは確率変数Ｉの実現を提供し、パラメータｐの推定を可能にする。

［２］において呈示されたアルゴリズムのシミュレーション結果は、０．５Ｎ_ｓｐから２Ｎ_ｓｐまでの範囲で、推定された現存スーパーピア数の比較的高い分散を示す。

推定の分散を縮小するため、本発明の実施形態に従って、近隣スーパーピアの推定が考慮される。これは、推定された現存スーパーピア数を交換保守メッセージ（例えば、ＦＩＮＧＥＲ＿ＰＩＮＧ又はＳＴＡＢＩＬＩＺＥメッセージ）の上に相乗りさせることによって行われる。これらの交換保守メッセージは、いずれにせよ送られる必要があり、従って高いコストを導入することなく使用され得る。

本発明の実施形態によれば、全てのスーパーピアは、最後のｘ個の推定された現存スーパーピア数のＦＩＦＯリスト（ＦＩＦＯ＝先入れ先出し）のために、ＦＩＦＯバッファを備え、１秒当たり１つのメッセージの最大レートで、推定された現存スーパーピア数の最新版を送る。この制限は、高いトラフィック量を有するスーパーピアが、スーパーピアの推定を改ざんすることを防止するために導入される。さもなければ、高いトラフィックを有するスーパーピアは、低トラフィックのスーパーピアよりも多くの推定値を送出する。このようにして、高トラフィックのスーパーピアの推定値は、それがかつて有しており大きく低下させてしまった推定と比べても、近隣スーパーピアの推定においてより一層の重要性を備えることとなる。

本発明の現存スーパーピア数推定アルゴリズムの結果は、全く良好な性能を示し、＋１％から＋３％までのシナリオ依存の偏差を有する。実際の現存スーパーピア数Ｎ_ｓｐと推定現存スーパーピア数との間には、１３から６０秒までの時間差が観察される。この時間差は、推定器１４が働く方法によって引き起こされる。即ち、推定器１４の働きはスーパーピアの後継者リストに基づくために、ネットワーク・サイズの変化は、後継者リストが更新されるときに考慮される。ネットワーク構造のこの変化は、伝搬にいくらかの時間を取り、従って推定に時間差が存在することになる。

推定器１４によって考慮される現在のネットワーク状況のために、本発明の実施形態に従って、前もって決定された前述の所望のシステム負荷因子Ｌ_ｄｅｓが考慮される。それによって、Ｌ_ｄｅｓは８０％から１２０％までの値へ設定可能である。本発明の好ましい実施形態において、所望のシステム負荷因子Ｌ_ｄｅｓは、１００％よりも小さい値、例えば、Ｌ_ｄｅｓ＝９０％に設定される。１００％よりも少し下の所望のシステム負荷因子Ｌ_ｄｅｓを選択する２つの理由が存在する。第一に、上部レベルＤＨＴの激動（ｃｈｕｒｎ）及びロードバランスによって生成されたスーパーピアの追加のトラフィック負荷は、下層の理論モデルでは考慮されない。第二に、スーパーピアのトラフィック負荷の期待されない増加のために、バッファが提供される。期待されない増加は、例えば、バースト状ルックアップ・トラフィックによって引き起こされる。

コントローラ１６は、本発明の実施形態によれば、推定器１４によって推定された必要スーパーピア数Ｎ^＊ _ｓｐが現存スーパーピア数Ｎ_ｓｐよりも大きい場合に、Ｉ／Ｏ端末１２−ｋ（ｋ＝１，２，．．．，Ｋ）の１つを経由してネットワーク機能を有するエンティティ１０へ接続されたネットワーク機能を有する他のエンティティを昇格させてスーパーピアにするようになっている。言い換えれば、この場合のネットワーク機能を有するエンティティ１０は、現在利用可能なスーパーピアよりも多くのスーパーピアの必要性が存在する場合に、ある一定の確率に従って、それに付加されたピアの１つを昇格させて階層的ピアツーピア・システム内の新しいスーパーピアにするようなスーパーピアとして考慮されてよい。

本発明の更なる実施形態によれば、コントローラ１６は、必要スーパーピア数Ｎ^＊ _ｓｐが現存スーパーピア数Ｎ_ｓｐよりも小さい場合に、ネットワーク機能を有する当該エンティティ１０の特性としてのスーパーピアを停止させるようになっている。言い換えれば、本実施形態において、コントローラ１６は、現存スーパーピア数Ｎ_ｓｐが、階層的ピアツーピア・システム内において目的とされた所望のシステム負荷レベルＬ_ｄｅｓに関して、要求されるスーパーピア数Ｎ^＊ _ｓｐを超過する場合に、スーパーピアをスーパーピアの地位から通常のピアへ降格させることができる。

推定器１４は、更に、ＤＨＴシステム内のスーパーピアによって平均的に生成されたルックアップ・メッセージの平均数λを推定するようになっている。リーフノードがルックアップを遂行するとき、リーフノードはクエリーメッセージをその付加されたスーパーピアへ送る。付加されたスーパーピアは、スーパーピアのコード・オーバーレイの中においてそのルックアップのアドレス解決を実行し、結果をリーフノードへ返却する。１つのスーパーピアによって平均的に生成されたルックアップ・メッセージの平均数λを推定するために、推定器１４は現存スーパーピア数Ｎ_ｓｐ及び平均システム・ルックアップ又はクエリーレートＲの知識を有している必要がある。

システム・ルックアップ又はクエリーレートＲは、システムによって時間単位当たりにアドレス解決されなければならないクエリーの数である。階層的ピアツーピア・システム全体の平均ルックアップレートＲを推定する簡単な方法は、ネットワーク機能を有するエンティティ１０のそのルックアップレートＲ_ｎ（ｎ＝１，２，．．．，Ｎ_ｓｐ）を単純に平均することである。全てのスーパーピアは、それが答えなければならない時間単位当たりの到着クエリー（ＱＵＥＲＹ）メッセージをカウントすることによって、それが観察する局所クエリーレートＲ_ｎ（ｎ＝１，２，．．．，Ｎ_ｓｐ）を測定し、Ｒ＝Ｎ_ｓｐ・Ｒ_ｎを評価することによって、システムのグローバルなクエリーレートＲを推定する。Ｒの推定値は、相乗りを介して近隣スーパーピアからそれぞれの値を取得し、それ自体及び近隣のものから受け取られた値Ｒ_ｎ（ｎ＝１，２，．．．，Ｎ_ｓｐ）について平均値Ｒ’を計算することによって、更に改善され得る。本発明の実施形態によれば、この理由によって、全てのネットワーク機能を有するエンティティ１０は、最後のｘ個の推定されたルックアップレートのＦＩＦＯリストのためにＦＩＦＯバッファを備え、推定されたルックアップレートの最新版を近隣スーパーピアへ送ることができる。

結果の推定は、システムを全体として観察することによって、観察されたクエリーレートＲと比較して、約３％から５％までの偏差を示す。

ＤＨＴシステムのようなコード・システムの場合、システム・ルックアップ・メッセージの平均量又はルックアップ・トラフィックλは、システム・ルックアップレートＲに、ルックアップ当たりに生成されたメッセージの平均数を掛けることによって与えられる。コード・システムにおけるルックアップ要求のアドレス解決（resolution）は、次の３つのステップへ分割できる。第一に、スーパーピアのコード・リングにおいて、担当となるスーパーピアがアドレス解決（resolve）される。これは平均でｌｏｇ_２Ｎ_ｓｐ個のメッセージを生成する（平均して、担当となるピアをアドレス解決するために１／２ｌｏｇ_２Ｎ_ｓｐ個のホップが要求され、反復ルーティングスキームを仮定すると、全てのホップが２つのメッセージを必要とする）。次に、ルックアップ要求が、担当のスーパーピアへ回送され（１メッセージ）、最後に、結果がクエリーしているピアへ伝送される（１メッセージ）。結果として、スーパーピア又はネットワーク機能を有するエンティティ１０の推定器１４は、次の式によって、スーパーピア当たりの現在のシステム・ルックアップ・トラフィックを計算することができる。

更に、推定器１４は、スーパーピアが下層のＤＨＴシステムによって生成した保守トラフィック・メッセージの平均数を推定する必要がある。下層のＤＨＴシステムがコード・システムである場合、保守トラフィックは、リーフノードとスーパーピアとの間のＰＩＮＧ−ＰＯＮＧアルゴリズム、ＳＴＡＢＩＬＩＺＥアルゴリズム、ＦＩＸＦＩＮＧＥＲアルゴリズム、及びスーパーピア・コード・オーバーレイにおけるＲＥＰＵＢＬＩＳＨアルゴリズムによって生成される。このようにして、スーパーピアの全トラフィック負荷は、ルックアップ・トラフィックλ、ＰＩＮＧ−ＰＯＮＧトラフィック、ＳＴＡＢＩＬＩＺＥトラフィック、及びＦＩＸＦＩＮＧＥＲトラフィックを備える保守トラフィックμ、及びＲＥＰＵＢＬＩＳＨトラフィックρから成る。

スーパーピアの保守トラフィックμは、スーパーピアのコードＤＨＴを保守するＳＴＡＢＩＬＩＺＥ及びＦＩＸＦＩＮＧＥＲアルゴリズム、及びリーフノードの故障を検出するためのリーフノード確認によって生成される。これは定期的ＰＩＮＧ−ＰＯＮＧアルゴリズムによって行われる。全てのリーフノードはＴ_ｐｉｎｇ秒ごとＰＩＮＧ−ＰＯＮＧアルゴリズムを定期的に実行する。リーフノードはピン（ＰＩＮＧ）メッセージをそのスーパーピアへ送り、スーパーピアはポン（ＰＯＮＧ）メッセージによって答える。全てのリーフノードをスーパーピアの上に均一に拡散させる適切なノードのバランスアルゴリズムが仮定されるので、これは平均してスーパーピア当たり次式の数のＰＩＮＧ−ＰＯＮＧメッセージを生成する。

なぜなら、

は、スーパーピアへ付加されたリーフノードの平均数であるからである。このようにして、Ｍは、現存スーパーピア数Ｎ_ｓｐに対して、階層的ピアツーピア・ネットワーク内において参加するノードの総数Ｎの比を表す。ノードの総数Ｎは、現存スーパーピア数Ｎ_ｓｐとネットワーク内のリーフノードの数との合計である。Ｍはグループ・サイズと考えられる。従って、グループ・サイズＭは、スーパーピアが管理しなければならないリーフの数に１を加えたもの（１はスーパーピア自体を示す）である。ＰＩＮＧ−ＰＯＮＧメッセージの数ｍ_{ｐｉｎｇｐｏｎｇ}を推定できるようにするため、推定器１４はグループ・サイズＭを推定するようになっている。システム平均値に近いＭの推定値を獲得するため、図１の点線１８、１９によって示されるように、ネットワーク機能を有するエンティティの近隣のものによって受け取られるＭの推定値のために、再び、ＦＩＦＯリストがネットワーク機能を有するエンティティ１０の中に導入される。これは有利である。なぜなら、システムのロードバランス・アルゴリズムに起因して、スーパーピア当たりのリーフノードの数は、スーパーピアの能力に従って異なるためである。

シミュレーションの結果は、加入段階においては非常に正確な推定を示し、激動及び離脱段階においては、推定は、約３％というやや過大なものとなる。これは、スーパーピア数が過大に推定されることから生じる。

本発明の更なる実施形態によれば、ネットワーク機能を有するエンティティ１０のそのグループ・サイズＭを単純に決定することによって、即ち、ネットワーク機能を有するエンティティ又はスーパーピア１０へ付加されたリーフノードの数を決定することによって、Ｍの簡単な推定値を取得することができる。

推定器１４によって推定されるべき保守メッセージの平均量の更なる部分は、ＳＴＡＢＩＬＩＺＥアルゴリズムによって引き起こされるメッセージである。ＳＴＡＢＩＬＩＺＥアルゴリズムは、Ｔ_ｓｔａｂ秒ごとに定期的に実行される。ＳＴＡＢＩＬＩＺＥは３つのメッセージを要求する。ＲＥＱＵＥＳＴＰＲＥＤＥＣＥＳＳＯＲメッセージ、対応するＲＥＳＰＯＮＳＥＰＲＥＤＥＣＥＳＳＯＲメッセージ、及び最後にＮＯＴＩＦＹメッセージである。開始スーパーピアは、ＲＥＱＵＥＳＴＰＲＥＤＥＣＥＳＳＯＲメッセージをその後継者に送り、後継者はＲＥＳＰＯＮＳＥＰＲＥＤＥＣＥＳＳＯＲメッセージによって応答し、最後に開始ピアはＮＯＴＩＦＹメッセージを送る。従って、任意のスーパーピアｎ（ｎ＝１，２，．．．，Ｎ_ｓｐ）について送受信されるＳＴＡＢＩＬＩＺＥメッセージの数は、次式によって与えられる。

更に、コード・システム内の全てのスーパーピアは、そのｌｏｇ_２Ｎ_ｓｐ個のフィンガ（ｆｉｎｇｅｒ）の各々のために、Ｔ_ｆｉｘ秒ごとにＦＩＸＦＩＮＧＥＲアルゴリズムを定期的に実行する（完全に占拠されたＩＤ空間を仮定する）。しかしながら、本発明の実施形態において、各々のスーパーピアが平均で２ｌｏｇ_２Ｎ_ｓｐ個のメッセージを生成するような改善されたＦＩＸＦＩＮＧＥＲアルゴリズムが使用される。このアルゴリズムは、ＰＩＮＧメッセージをフィンガ・ピアへ送り、ＰＯＮＧメッセージが受け取られないか、フィンガ・ピアがこのフィンガＩＤを担当する新しいピアを表示するときにのみ、フィンガ・ルックアップを開始する。結果として、システムが定常状態にあるとき、フィンガ・ルックアップを回避することができ、任意のスーパーピアｎ（ｎ＝１，２，．．．，Ｎ_ｓｐ）について送受信されるＦＩＸＦＩＮＧＥＲメッセージの数は、次式によって与えられる。

式（３）、（５）、及び（６）をまとめると、次式が得られる。

前述したように、保守トラフィックの他の態様は、ＤＨＴシステムがコード・システムに編成される場合の、ＲＥＰＵＢＬＩＳＨアルゴリズムに起因する。全てのスーパーピアは、スーパーピア自体及びそのリーフノードの全共有オブジェクトについて、Ｔ_ｒｅｐ秒ごとにＲＥＰＵＢＬＩＳＨアルゴリズムを定期的に実行する。共有オブジェクトを再発行（republish）することは、オブジェクトのＩＤのコード・ルックアップに対応する。従って、それは平均してｌｏｇ_２Ｎ_ｓｐ個のメッセージを生成する。ここで、全てのスーパーピアは、それ自体とそのリーフノードによって共有される同数のオブジェクトを管理するものと仮定される。即ち、

式（８）において、Ｆは階層的ピアツーピア・システム全体の共有アイテムの数を表す。Ｆ_ａｖ＝Ｆ／Ｎ_ｓｐは、１つのスーパーピアによって管理される共有オブジェクトの平均数を表す。

共有オブジェクト又はオブジェクト参照の数は、更に、各々のネットワーク機能を有するエンティティ１０によって局所的に決定され、近隣のネットワーク機能を有するエンティティへ配布される。共有オブジェクトの数の平均値Ｆ_ａｖを構築することによって、システムの平均値の推定が、Ｆ＝Ｎ_ｓｐ・Ｆ_ａｖに従って取得される。

シミュレーションにおいては、Ｆが約５％から６％過大に推定される。この過大推定が生じるのは、主に、現存スーパーピア数Ｎ_ｓｐが過大推定されたためである。

ＲＥＰＵＢＬＩＳＨトラフィックρは、スーパーピアのＤＨＴ内の共有アイテムに関する情報を定期的に更新するために必要である。なぜなら、ピアは故障するかも知れず、従って参照が失われるかもしれないためである。共有アイテムの再発行は、共有アイテムのルックアップと同じである。その結果、ルックアップ・トラフィックの上記の解析を使用することによって、及び、Ｔ_ｒｅｐ秒ごとに再発行される共有アイテムの総数Ｆによってシステム・ルックアップレートＲを置換することによって、再発行トラフィックを簡単に計算することができる。その結果、スーパーピアは、次式によって、システムにおける現在のＲＥＰＵＢＬＩＳＨトラフィックρを推定することができる。

再び、推定器１４によって、値Ｆが推定されなければならない。前述したように、ネットワーク機能を有するエンティティ１０の共有オブジェクトの自己数ｆ_ｎ（ｎ＝１，２，．．．，Ｎ_ｓｐ）を考慮されることによって、これを行うことができる。ロードバランス・アルゴリズムはバックグラウンドで実行することが仮定されるので、それ自体の値を考慮するそのような推定値は、全体的システム・パラメータについて既に良好な推定値を産出することが考えられる。共有アイテム数の推定値を更に改善するため、ネットワーク機能を有するエンティティ１０は、本発明の実施形態に従って、更に、それ自体の値、及び相乗りによって近隣スーパーピアから取得された値について、平均値を計算する。

現在のシステム負荷因子Ｌの推定値を計算するため、推定器１４は、更に、階層的ピアツーピア・システムのスーパーピア当たりの平均容量Ｃについて推定値を必要とする。平均スーパーピア容量Ｃは、前述したように、相乗りによって局所スーパーピア容量を配布し、最後のｘ個の受け取られた容量について平均値を構築することによって決定される。結果の値は非常に正確であり、偏差は０．１％よりも小さい。これは、結果の分散を増加した他の推定からの独立性から生じる（前の値はＮ_ｓｐを使用して計算されなければならなかった）。再び、ネットワーク機能を有するエンティティ１０のそれ自体の値だけを考慮することによって、簡単な推定値を取得することができる。

λ、μ、ρ、及びＣの推定値を推定すると、推定器１４は次式に従ってシステム負荷因子Ｌの推定値を計算してよい。

次に、式（１０）に従って計算された現在のシステム負荷因子Ｌの推定値は、所望のネットワーク状況、即ち、所望のシステム負荷因子Ｌ_ｄｅｓと比較される。Ｎ_ｓｐ、Ｍ、Ｒ、Ｆ、Ｃ、及びＬとＬ_ｄｅｓとの比較結果に基づいて、推定器１４は必要スーパーピア数Ｎ^＊ _ｓｐを計算し、Ｌが範囲内にあるように、又はＬ_ｄｅｓに等しくなるようにする。即ち、Ｌ_ｄｅｓ＝９０％である。差ΔＮ_ｓｐ＝（Ｎ^＊ _ｓｐ−Ｎ_ｓｐ）は、スーパーピアの調節数を表す。ΔＮ_ｓｐ＞０の場合、新しいスーパーピアが必要であり、ネットワーク機能を有するエンティティ１０のコントローラ１６は、平均｜ΔＮ_ｓｐ｜／Ｎ_ｓｐでリーフノードを昇格させてスーパーピアにする。ΔＮ_ｓｐ＜０であれば、コントローラ１６は、システムを離脱してリーフノードとして再加入するため、確率｜ΔＮ_ｓｐ｜／Ｎ_ｓｐでネットワーク機能を有するエンティティ１０の特性としてのスーパーピアを停止させる。

タイマーＴ_ｓｔａｂ、Ｔ_ｆｉｘ、Ｔ_ｒｅｐ、及びＴ_ＰｉｎｇはＤＨＴ設計パラメータであることが仮定される。なぜなら、これらのタイマーはそのようなものとして事前に公知であるからである。これらのパラメータの他に、システムの現在の状態を特徴づけする多数の他のパラメータ（Ｎ_ｓｐ、Ｍ、Ｒ、Ｆ、Ｃ）がアルゴリズムの中に存在する。それらのパラメータは前もって与えられず、推定器１４によって推定される必要がある。現存スーパーピア数Ｎ_ｓｐは、［２］で説明されたアルゴリズムの改善版を使用して推定される。グループ・サイズＭ、システム・ルックアップレートＲ、共有オブジェクトの平均数Ｆ、及び平均容量Ｃは、それ自体の値及び／又は相乗りで近隣スーパーピアから取得された値の平均値を計算することによって、スーパーピアによって全て推定される。

現存スーパーピア数Ｎ_ｓｐの推定は、後継体リストの正確度に依存する。直感的に、定期的保守メッセージを制御するタイマー値Ｔ_ｓｔａｂ、Ｔ_ｆｉｘ、Ｔ_ｒｅｐ、及びＴ_Ｐｉｎｇの変更が、推定の偏差に影響すると仮定することができる。この仮定を証明するため、異なるタイマー値を有するいくつかのシナリオがシミュレートされ、例えば、ＳＴＡＢＩＬＩＺＥタイマー値Ｔ_ｓｔａｂを１０秒から５秒へ変更すると、偏差は約３．５％から０．６％へ減少することが発見された。もちろん、この変更は、増加する保守トラフィックをもたらす。

システムの外部影響としてのクエリーレートＲも、推定の正確度にインパクトを与える。なぜなら、クエリーレートＲが高くなると、各ノードにおいて他のピアからの新鮮な情報が利用可能になるためである。各ノードで、ルックアップレートを１分当たり１つのクエリーから１分当たり２つのクエリーへ２倍にすると、偏差は約２．５％から約０．５％へ減少する。

ルックアップ・メッセージの平均数λ、保守メッセージの平均数μ、及びスーパーピア当たりのＲＥＰＵＰＬＩＳＨメッセージの平均数ρを推定する代わりに、推定器１４は、更に、それぞれの全体的システム・パラメータ、即ち、推定された現存スーパーピア数Ｎ_ｓｐを乗じた値λ、μ、及びρを推定するように構成されてよい。しかしながら、これはシステム負荷因子Ｌの推定値を計算するときに考慮されなければならない。

ここで、図２を参照すると、本発明の実施形態に従ってネットワーク機能を有するエンティティ１０を動作させる方法が説明される。

本方法は、階層的ピアツーピア・ネットワーク内において要求されるスーパーピアの必要スーパーピア数Ｎ^＊ _ｓｐ、実際のネットワーク状況に依存するスーパーピアの必要数を推定し、及び、階層的ピアツーピア・ネットワーク内に実際に存在するスーパーピアの数である現存スーパーピア数Ｎ_ｓｐを推定するステップＳ１を備える。

本方法は、更に、必要スーパーピア数Ｎ^＊ _ｓｐがスーパーピア数Ｎ_ｓｐよりも大きい場合に、異なるネットワーク能力を昇格させてスーパーピアにするステップＳ２１、及び、必要スーパーピア数Ｎ^＊ _ｓｐが現存スーパーピア数Ｎ_ｓｐよりも小さい場合に、ネットワーク機能を有するエンティティ１０の特性としてのスーパーピアを停止させるステップＳ２２を備える。

推定ステップＳ１は、更に、サブステップへ分割される。第一のサブステップＳ１１においては、現存スーパーピア数Ｎ_ｓｐ、グループ・サイズＭ、システム・ルックアップレートＲ、共有オブジェクトの平均数Ｆ、及び平均容量Ｃが、前述したように、それ自体の値の平均値、及び／又は相乗りによって近隣スーパーピアから取得された値の平均値を計算することによって全て推定される。要求スーパーピア数Ｎ^＊ _ｓｐは、最初にステップＳ１１において現存スーパーピア数Ｎ_ｓｐへ等しく設定される。次のサブステップＳ１２では、サブステップＳ１１からの推定システム・パラメータ（Ｎ_ｓｐ、Ｍ、Ｒ、Ｆ）を使用して、値λ、μ、及びρが式（２）、（７）、及び（９）に従って計算される。次のサブステップＳ１３においては、サブステップＳ１２からの値λ、μ、ρ、及びＣを使用して、現在のシステム負荷因子Ｌが式（１０）に従って計算される。

現在のシステム負荷因子Ｌを計算すると、更なるサブステップＳ１４で、Ｌを所望のシステム負荷因子Ｌ_ｄｅｓと比較することができる。現在のシステム負荷因子Ｌが所望のシステム負荷因子Ｌ_ｄｅｓの許容範囲、例えば、０．９Ｌ_ｄｅｓ＜Ｌ＜１．１Ｌ_ｄｅｓにない場合、スーパーピアの調節を起こさなければならない。言い換えると、例えば、Ｌ＜０．９Ｌ_ｄｅｓ又はＬ＞１．１Ｌ_ｄｅｓの場合に、スーパーピアの調節が必要である。Ｌ_ｄｅｓは、例えば、９０％である。Ｌ＜０．９Ｌ_ｄｅｓであれば、新しいスーパーピア数はＮ_ｓｐよりも低くなければならない。Ｌ＞１．１Ｌ_ｄｅｓであれば、新しいスーパーピア数はＮ_ｓｐよりも大きくなければならない。双方の場合、要求されるスーパーピア数は、サブステップＳ１５でＮ^＊ _ｓｐを徐々に増加（Ｌ＞Ｌ_ｄｅｓの場合）又は減少（Ｌ＜Ｌ_ｄｅｓの場合）することによって取得される。全ての反復において、それぞれの結果のシステム負荷は、式（１０）に基づいてサブステップＳ１２及びＳ１３で再び計算される。これは、推定されたシステム負荷因子Ｌが、所望の負荷因子Ｌ_ｄｅｓの指定された許容範囲、即ち、０．９Ｌ_ｄｅｓ＜Ｌ＜１．１Ｌ_ｄｅｓの中に入るまで行われる。範囲の中に入ると、Ｎ^＊ _ｓｐは要求スーパーピア数を表す。ステップＳ１７においては、スーパーピアの調節数ΔＮ_ｓｐ＝Ｎ^＊ _ｓｐ−Ｎ_ｓｐが、０よりも大きいかどうかが決定される。大きければ、階層的ピアツーピア・システムにおいて新しい追加のスーパーピアの必要性が存在する。従って、ステップＳ２１においては、ネットワーク機能を有するエンティティ１０によって、ネットワーク機能を有する他のエンティティが確率｜ΔＮ_ｓｐ｜／Ｎ_ｓｐで昇格されてスーパーピアにされ、ピアツーピア・ネットワーク・システム全体の中でΔＮ_ｓｐ個のピアが昇格されてスーパーピアにされる。スーパーピアの調節数ΔＮ_ｓｐが０よりも小さいことをサブステップＳ１７が産出する場合、ネットワーク機能を有するエンティティ１０の特性としてのスーパーピアは確率｜ΔＮ_ｓｐ｜／Ｎ_ｓｐで停止され、ΔＮ_ｓｐ個のスーパーピアがピアツーピア・システム全体に関して普通のピアへ降格される。

現在のシステム負荷因子Ｌが、所望のシステム負荷因子Ｌ_ｄｅｓの許容範囲の中にない場合、スーパーピア調節を遂行する代わりに、本発明の実施形態に従って、現在のシステム負荷因子Ｌが所望のシステム負荷因子Ｌ_ｄｅｓの許容範囲の中にあるか否かに関わらず、Ｎ_ｓｐ又はＮ^＊ _ｓｐを徐々に増分するか（Ｌ＞Ｌ_ｄｅｓの場合）または減分する（Ｌ＜Ｌ_ｄｅｓの場合）ことによってスーパーピア調節数ΔＮ_ｓｐを常に計算し、｜ΔＮ_ｓｐ｜が所定の閾値よりも大きい場合にのみ、スーパーピアへ昇格させるか終了することも可能である。この閾値は、システム・サイズ、即ち、Ｎ又はＮ_ｓｐに依存する。

図２を参照して説明された方法は、定期的に実行され得る。ここで、方法を応用するための期間は、階層的ピアツーピア・システムの力学に依存する。

このアルゴリズムを適切に運用する前提条件は、リーフノードをスーパーピアへ昇格させるとき、高コスト限度Ｃ_ｎ ^ｍａｘを有するリーフノードが選ばれることである。再び、この情報は相乗りによってスーパーピアの間で配布される。もっと正確には、全てのスーパーピアは、その送るメッセージをその最も有能なリーフノードのアドレス及びコスト限度で拡張し、リーフノードの昇格を決定するとき、スーパーピアはこの情報を使用して、スーパーピアが知っている現在最も有能なリーフノードを昇格させる。

本発明の実施形態が図１及び図２を参照して詳細に説明された後、いくつかの実験的結果が下記のようにして呈示される。この実験結果は、Ｎ＝１，０００からＮ＝２５０００までの数のピアを有する複数の独立シナリオをシミュレートして取得された。

各々のピアは、セッション持続時間ｔ_{ｏｎｌｉｎｅ}、ルックアップレートｒ_ｎ、及び共有オブジェクトの数ｆ_ｎ（ｎ＝１，２，．．．，Ｎ）について異なる値を割り当てることによってモデル化される。これらの値は、特定の平均値の周りで指数分布となる。ｔ_{ｏｎｌｉｎｅ}のテストされた平均値は、それぞれ５分、１５分、３０分、及び１時間である。ｒ_ｎについては、１２分、２分、１分、及び１５分の平均値がそれぞれ仮定される。ｆ_ｎの平均値は２０へ設定される。

１秒当たりにアップロードされるメッセージに関する全ピアのコスト限度は、次の仮定に基づいて指定される。
（１）アップロード・ビットレートは、５０ｋビット／秒（モデム）から５００ｋビット／秒（ＤＳＬ）までの範囲である。
（２）平均メッセージ・サイズは５００バイトである。
（３）ピアは、オーバーレイ参加のために、ピアのアップロード容量の１０％を費やす。

このようにして、均一に分布されたアップロード限度は、全てのピアへ１秒当たり１から１３までのメッセージを割り当てられる。注意すべきは、仮定３）が、他のネットワーク・タスク、例えば、ファイル転送のために、十分な残りの帯域幅を確保することである。また、オーバーレイ参加のためにアップロード容量の１０％を使用することは、影響されるピアを過負荷にすることなく、１００％よりも多い（一時的に）増加される負荷レベルを許す。そのような一時的に増加される負荷レベルは、例えば、バースト状ルックアップ・トラフィックに起因して時々起こり得る。

次のシステム幅パラメータは、シミュレーションを通して使用された。

シミュレーション・シナリオは３つの段階に分割される。第１の段階は「加入段階」と呼ばれる。この段階において、ピアが所望数に達するまで、ピアはシステムに加入する。次に、「激動段階」がある。この段階では、ピアがシステムへ同時に加入及び離脱する。ピアの到着レートは、「激動段階」のピアの数が比較的一定レベルに止まるように選ばれる。最後に、「離脱段階」において、ピアの到着レートは０へ設定され、システム内のピアは、ピアの負の指数分布セッション持続時間に従ってオフラインになる。シミュレーションの間に、現存スーパーピア数Ｎ_ｓｐが継続的に測定され、最適数Ｎ_ｏｐｔと比較される。Ｎ_ｏｐｔはシステムを全体として観察して計算され、Ｎ_ｏｐｔ個の最も有能なピアが上部レベルのオーバーレイを構築し、残りのピアはリーフノードとして付加される。前述したように、最適のスーパーピア比は、９０％と１００％の間のシステム負荷を導くべきである。これを評価するため、現在のシステム負荷因子Ｌ、即ち、全スーパーピアの平均負荷因子が定期的に記録される。得られた結果を統計的に有効にするため、各々のシナリオは、乱数発生器への異なる種を用いて複数回シミュレートされた。しかしながら、各シナリオの異なるシミュレーション実行において、有意の変化は検出されなかった。

評価の結果は、１つの特定シミュレーション・シナリオに関して説明される。しかしながら、強調されることとして、評価の結果は全ての他のシミュレートされるシナリオについても有効である。考慮されたシナリオにおいて、ピアの総数は１，０００であり、ｔ_{ｏｎｌｉｎｅ}の平均値は３０分であり、ｒ_ｎの平均値は１分当たり１ルックアップへ設定される。

図３は、システム内に現在現存するスーパーピアの数Ｎ_ｓｐの曲線３０を示す。注意すべきは、本システムが、オンラインである８つのスーパーピアと共にスタートすることである。加入段階（０〜１８００秒）の間、スーパーピア数Ｎ_ｓｐは増加する。なぜなら、システムにおいて増加するＮ個のピアによって生成されるトラフィックを処理し、必要なスーパーピアがますます多くなるためである。激動段階（１８００〜５４００秒）において、スーパーピア数Ｎ_ｓｐは比較的一定である。

いくつかのスーパーピアはそのセッション持続時間の終了に起因してシステムを離脱し、他のスーパーピアはその（時には、間違った）推定に基づいてシステムを離脱するかリーフノードを昇格させるので、この一定のスーパーピアの数Ｎ_ｓｐの辺りには、継続的に小さいゆらぎが認知される。「離脱段階」（５４００〜７２００秒）の間に、スーパーピアの数Ｎ_ｓｐは減少する。なぜなら、システム内の減少するトラフィックを処理するため、必要とされるスーパーピアは少なくなるからである。

全てのシミュレーション段階において、スーパーピアの測定された数は、常に最適数（点線３２）に近いことが分かる。

図４は、シミュレーションの間に測定されたシステム負荷Ｌを描写する。期待されるように、それは９０％のあたりで変動し、システム内において生成されるがこの理論モデル（激動、ロードバランス）で考慮されないトラフィックが、有意の影響を有さないことを表示する。図４はシステムにおける全スーパーピアの平均負荷レベルＬを示すが、単一ピアの負荷レベルＬＦ_ｎの典型的曲線は図５に見られる。ｔ_０において、ピアはリーフノードとしてシステムに加入する。このピアは十分なアップロード容量を提供するので、それはｔ_１においてスーパーピアへ昇格され、従ってその負荷レベルＬＦ_ｎを継続的に測定し始める。ｔ_２においては、必要数より多いスーパーピアがシステム内に存在することを仮定するので、ピアは上部レベルＤＨＴを離脱してリーフノードとして再加入する。後のｔ_３において、ピアは再びスーパーピアへ昇格される。最後に、ピアはｔ_４においてシステムを離脱する。（ピアがスーパーピアであるときの）負荷レベルＬＦ_ｎは、時間と共に変動することが分かるが、期待されるように、一時的に１００％を超えるだけである。

上記の図面に示されない更に興味深いシミュレーション結果が存在する。第一に、階層システムは、Ｎ個の全ピアがコード・リングの一部分である平坦ＤＨＴよりも、少ないネットワーク・トラフィックを生成する。上記の例において、階層システム内のメッセージの総数は７，１７４，９４１個であり、平坦コード・システムは全部で７，８８３，２０１個のメッセージを生成する。これは９％のトラフィック低減に対応する。これらのメッセージの大部分は強力なスーパーピアによって処理されるという追加利益を階層システムが提案することに注意すべきである。第二に、ほんの５分の非常に低い平均セッション持続時間が見出される。これは低すぎる数のスーパーピア、従って１００％を超えるシステム負荷を生じる。この理由は、アルゴリズムはスーパーピアの必要数を計算し、調節するが、それらのスーパーピアの多くは、オンライン時間が短いために、その後すぐに離脱するからである。結果として、システム内で継続的に存在するスーパーピアの数が少なくなりすぎる。しかしながら、平均セッション持続時間が１５分へ上昇するとき（これは依然として低い値であるが）、アルゴリズムは、上記で示される良好な性能を再び示す。

最後に、ピアの平均ルックアップレートが、５秒ごとに１ルックアップという極端に高い値へ指定されるとき、システム内のスーパーピアの数は理論的値よりも相当に高くなる。この理由は、理論的には、（全てのリーフノードの中で最高容量を有する）次の最良リーフノードを常に選んで、次のスーパーピアにするためである。このシナリオでは、負荷を処理するための非常に高いスーパーピア比が必要なので、アルゴリズムは必ずしも現在の最良リーフノードを見出すことができず、より低い容量を有する他のリーフノードを選択する。このようにして、全スーパーピアの平均容量は理論値よりも低くなるので、膨大なルックアップ・トラフィックを処理するために必要なスーパーピアは多くなる。それにも関わらず、この極端なシナリオにおいて、本発明のアルゴリズムは約９０％の所望のシステム負荷を提供することが分かる。

これまでの説明を要約すると、ピアツーピア・ネットワークは、リソースの集合の高速位置決めを可能にする自己組織化分散オーバーレイ・ネットワークである。これらのネットワークは、参加中のノード間の物理接続に依存するアプリケーション層オーバーレイ・ネットワークとして実現される。ピアツーピア・ネットワークによって対処される基本問題は、リソースの集合の自己組織化分散であり、ピアの集合は後続の高速ルックアップを可能にする。

この問題を解決する有望なアプローチは、分散ハッシュ・テーブル（ＤＨＴ）としても知られる構造化ピアツーピア・ネットワークの概念である。ＤＨＴにおいて、ピアは鍵空間からの鍵によって識別されるリソースの具体的部分集合を協力して管理する。これは次のようにして行われる。各々のピアは、鍵空間から取られた鍵に関連づけられる。ピアの集合が与えられたと仮定すると、各ピアの鍵は鍵空間の区画に関連づけられ、ピアは関連区画からの鍵によって識別される全ての鍵リソースを管理する担当になることになる。典型的には、鍵区画は、ピア鍵からみて、適切な尺度で最も近くにある全ての鍵から構成される。鍵の近さは距離関数によって測定される。リソース要求を回送するため、ピアは、ピアと鍵区画との関連付けに関する知識を考慮して、ルーティングネットワークを形成する。ピアは、典型的には、近隣鍵を有する全ピアへの短距離リンク、及び追加的に、いくつかの選択された遠いピアへの少数の長距離リンクを保守する。このように確立されたルーティングネットワークを使用して、ピアは、指図された態様によって、そのルーティングテーブルからの他のピアへリソース要求を回送し、ルックアップされている鍵への距離を大幅に低減しようと試みる。ＤＨＴの大部分は、この構成及びルーティングアルゴリズムにより、ネットワークのサイズにおいて対数的なルーティングテーブルを使用することによって、ネットワークのサイズにおいて同様に対数的な多数のメッセージの中でルックアップを実現する。

考慮されたピアツーピア・アーキテクチャは、参加中のピアを２つのグループに分割する。即ち、分散ハッシュ・テーブルの中に組織され、第２のグループのプロキシとして役立つスーパーピアのグループと、これらのスーパーピアへ付加され、ＤＨＴに参加しないリーフノードのグループである。

階層ＤＨＴは、スケーラビリティ、ネットワークの局所性、及び順方向隔離に関して、平坦ＤＨＴよりも性能が勝ることが発見された。［１］において、これらの発見は、他の観点から階層及び平坦ＤＨＴを評価することによって深められた。即ち、ＤＨＴ構成の最適性の判断を可能にする一般コスト・ベース・フレームワークの観点である。スーパーピア及びこれらスーパーピアに付加されるリーフノードの注意深く選ばれた集合からなる簡単な階層ＤＨＴ組織は、これがネットワーク・リソースの使用を最小化する意味で、最適であることが発見された。

本発明の実施形態は、そのような階層的ピアツーピア・システムを構築及び保守するアルゴリズムの完全な集合を提供する。具体的には、本発明の実施形態は、スーパーピア対リーフノードの比に関して、階層的ピアツーピア・システムの最適な運用点を動的に決定する。本発明のアルゴリズムは十分に分散されて確率的であり、ピアによって取られる全ての判定は、システム幅パラメータの集合に対するそれらピアの部分的見解に基づいている。このようにして、本発明の実施形態は、自己組織化の主な原理を説明する。システムの振る舞いは、局所的対話から出現する。現実的設定の範囲の中にある呈示されたシミュレーションは、本発明のアルゴリズムの良好な性能を裏付ける。

検討された実施形態は、ＤＨＴとしてコード・システムを使用するが、他の構造化ピアツーピア・プロトコルも、同様の利点を実現するために使用され得る。

本発明の実施形態は、より安定した少コストのネットワーク動作、及び高い順方向弾力性を使用する。このようにして、本発明は全体としてのネットワークへ強い経済的インパクトを与える。

更に、本発明の方法のある一定の実現要件に依存して、本発明の方法は、ハードウェア又はソフトウェアによって実現され得る。実現は、ディジタル記憶メディア、具体的には、電子的に読み取り可能な制御信号を記憶したディスク又はＣＤを使用して遂行され得る。ディジタル記憶メディアは、プログラム可能なコンピュータ・システムと協力して、本発明の方法が遂行されるようにする。一般的に、本発明はコンピュータ・プログラムプロダクトである。コンピュータ・プログラムプロダクトは、機械読み取り可能担体の上に記憶されたプログラム・コードを有する。プログラム・コードは、コンピュータ・プログラムプロダクトがコンピュータで実行するとき、本発明の方法の少なくとも１つを遂行するようになっている。言い換えれば、本発明の方法は、コンピュータ・プログラムがコンピュータ及び／又はマイクロコントローラで実行する間に本発明の方法を遂行するプログラム・コードを有するコンピュータ・プログラムである。

本発明の実施形態に従ったネットワーク機能を有するエンティティのブロック図を示す。 本発明の実施形態に従ったネットワーク機能を有するエンティティを動作させる方法のフローチャートを示す。 本発明の実施形態に従ったアルゴリズムを用いて時間の経過と共に取得されたスーパーピア数のシミュレーション結果を示す。 本発明の実施形態に従ったアルゴリズムを用いて時間の経過と共に取得されたシステム負荷を描写するシミュレーション結果を示す。 本発明の実施形態に従ったアルゴリズムを用いて取得された単一ピアの負荷レベルの典型的負荷曲線を示す。 ピアツーピア・オーバーレイ・ネットワーク、及びこの下層の物理ネットワークの例示的層構造を示す。 コード・リングを形成するスーパーピア及び各スーパーピアに付加されたノードを有する可能な階層的ピアツーピア・システムを示す。 スーパーピア割合αに対する最高負荷因子曲線及びコスト曲線を示す。

Claims (21)

1. 階層的ピアツーピア・ネットワークにおいて要求されるスーパーピアの数であり、実際のネットワーク状況（Ｌ）に依存する数である必要スーパーピア数（Ｎ^＊ _ｓｐ）を推定し、階層的ピアツーピア・ネットワークに実際に存在しているスーパーピアの数である現存スーパーピア数（Ｎ_ｓｐ）を推定する推定器（１４）と、
   必要スーパーピア数（Ｎ^＊ _ｓｐ）が現存スーパーピア数（Ｎ_ｓｐ）よりも大きい場合に、ネットワーク機能を有する他のエンティティを昇格させてスーパーピアにするコントローラ（１６）と
   を備えるネットワーク機能を有するエンティティ（１０）。
2. 階層的ピアツーピア・システムにおいて生成された負荷を参加中のスーパーピアの間において均一にバランスさせるロードバランス処理を行う階層的ピアツーピア・システムの一部分となっている、請求項１に記載のネットワーク機能を有するエンティティ。
3. 階層的ピアツーピア・システムのスーパーピアがコード・ネットワークとなるように編成される、請求項１又は２に記載のネットワーク機能を有するエンティティ。
4. 推定器（１４）が、ネットワーク機能を有するエンティティ（１０）のＩＤとネットワーク機能を有するエンティティ（１０）の直接後継体のＩＤとの間の区間の長さを有する幾何分布パラメータｐに基づいて、現存スーパーピア数（Ｎ_ｓｐ）を推定するようになっている、請求項１〜３のいずれかに記載のネットワーク機能を有するエンティティ。
5. 推定器（１４）がシステム負荷因子（Ｌ）を実際のネットワーク状況として使用するようになっており、システム負荷因子（Ｌ）がロードバランスされている階層的ピアツーピア・システムにおける平均ピア・コストと最大ピア・コストとの間の比を表す、請求項１〜４のいずれかに記載のネットワーク機能を有するエンティティ。
6. 推定器（１４）が、スーパーピアによって生成されたルックアップ・メッセージの平均数（λ）を推定し、スーパーピアによって生成された保守メッセージの平均数（μ）を推定し、スーパーピア当たりのＲＥＰＵＰＬＩＳＨメッセージの平均数（ρ）を推定するようになっている、請求項１〜５のいずれかに記載のネットワーク機能を有するエンティティ。
7. 推定器（１４）が、推定された現存スーパーピア数（Ｎ_ｓｐ）と推定されたルックアップレート（Ｒ）とに基づいて、スーパーピア当たりの生成ルックアップ・メッセージの平均数（λ）を推定するようになっている、請求項６に記載のネットワーク機能を有するエンティティ。
8. 推定器（１４）が、次の式、
   

   

   に従って、スーパーピア当たりの生成ルックアップ・メッセージの平均数（λ）を推定するようになっている、請求項７に記載のネットワーク機能を有するエンティティ。
9. 推定器（１４）が、推定された現存スーパーピア数（Ｎ_ｓｐ）とスーパーピアに接続されたピアの平均比を意味する推定されたグループ・サイズＭとに基づいて、スーパーピア当たりの保守メッセージの平均数（μ）を推定するようになっている、請求項６に記載のネットワーク機能を有するエンティティ。
10. 推定器（１４）が、次の式、
    

    

    に従って保守メッセージの平均数（μ）を推定するようになっており、
    式中、Ｔ_ｓｔａｂはコードのＳＴＡＢＩＬＩＺＥアルゴリズムの期間を表し、Ｔ_ｆｉｘはコードのＦＩＸＦＩＮＧＥＲアルゴリズムの期間を表し、Ｔ_ｐｉｎｇはコードのＰＩＮＧ−ＰＯＮＧアルゴリズムの期間を表す、請求項９に記載のネットワーク機能を有するエンティティ。
11. 推定器（１４）が、階層的ピアツーピア・ネットワークにおける共有オブジェクトの数（Ｆ）と現存スーパーピア数（Ｎ_ｓｐ）の推定値とに基づいて、スーパーピア当たりのＲＥＰＵＰＬＩＳＨメッセージの平均数（ρ）を推定するようになっている、請求項６に記載のネットワーク機能を有するエンティティ。
12. 推定器（１４）が、次の式、
    

    

    に従って、ＲＥＰＵＰＬＩＳＨメッセージの数（ρ）を推定するようになっている、請求項１１に記載のネットワーク機能を有するエンティティ。
13. 推定器（１４）が、階層的ピアツーピア・ネットワークのスーパーピア当たりの平均容量（Ｃ）を推定し、スーパーピア当たりの生成ルックアップ・メッセージの推定された平均数（λ）と、スーパーピア当たりの保守メッセージの推定された平均数（μ）と、スーパーピア当たりのＲＥＰＵＰＬＩＳＨメッセージの推定された平均数（ρ）と、推定された平均容量（Ｃ）とに基づいて、実際のネットワーク状況（Ｌ）を推定するようになっている、請求項１〜１２のいずれかに記載のネットワーク機能を有するエンティティ。
14. 推定器（１４）が、次の式、
    

    

    に従って実際のネットワーク状況（Ｌ）を推定するようになっている、請求項１３に記載のネットワーク機能を有するエンティティ。
15. コントローラ（１６）は、実際のネットワーク状況に依存するシステム負荷因子（Ｌ）を所望のシステム負荷因子（Ｌ_ｄｅｓ）と比較して、現在のシステム負荷因子（Ｌ）が所望のシステム負荷因子（Ｌ_ｄｅｓ）よりも大きい場合に現存スーパーピア数（Ｎ_ｓｐ）と比較される必要スーパーピア数（Ｎ^＊ _ｓｐ）を増加させ、現在のシステム負荷因子（Ｌ）が所望のシステム負荷因子（Ｌ_ｄｅｓ）よりも小さい場合に現存スーパーピア数（Ｎ_ｓｐ）と比較される必要スーパーピア数（Ｎ^＊ _ｓｐ）を減少させるようになっている、請求項１〜１４のいずれかに記載のネットワーク機能を有するエンティティ。
16. 推定器（１４）が、前記ネットワーク機能を有するエンティティ（１０）に特定された値に基づいて、平均ルックアップレート（Ｒ）と、平均グループ・サイズ（Ｍ）と、共有アイテムの平均数（Ｆ）と、スーパーピアの平均容量（Ｃ）との値を推定するようになっている、請求項１〜１５のいずれかに記載のネットワーク機能を有するエンティティ。
17. 推定器（１４）が、前記値について平均値を決定するためそれ自体の値のほかに、スーパーピアである近隣ネットワーク機能を有するエンティティの関連した値を使用して、平均ルックアップレート（Ｒ）と、平均グループ・サイズ（Ｍ）と、共有アイテムの平均数（Ｆ）と、スーパーピアの平均容量（Ｃ）とを推定するようになっている、請求項１〜１６のいずれかに記載のネットワーク機能を有するエンティティ。
18. 階層的ピアツーピア・ネットワークにおいて要求されるスーパーピアの数であり、実際のネットワーク状況（Ｌ）に依存する数である必要スーパーピア数（Ｎ^＊ _ｓｐ）を推定し、階層的ピアツーピア・ネットワークで実際に存在しているスーパーピアの数である現存スーパーピア数（Ｎ_ｓｐ）を推定する推定器（１４）と、
    必要スーパーピア数（Ｎ^＊ _ｓｐ）が現存スーパーピア数（Ｎ_ｓｐ）よりも小さい場合に、ネットワーク機能を有するエンティティ（１０）の特性としてのスーパーピアを停止させるコントローラ（１６）と
    を備えるネットワーク機能を有するエンティティ（１０）。
19. 階層的ピアツーピア・ネットワークにおいて実際に存在しているスーパーピアの数である現存スーパーピア数を推定するステップ（Ｓ１１）と、
    推定された現存スーパーピア数（Ｎ_ｓｐ）に基づいて、実際のネットワーク状況を推定するステップ（Ｓ１３）と、
    推定された実際のネットワーク状況（Ｌ）に基づいて、階層的ピアツーピア・ネットワークにおいて要求されるスーパーピアの数である必要スーパーピア数を推定するステップ（Ｓ１５）と、
    必要スーパーピア数（Ｎ^＊ _ｓｐ）が現存スーパーピア数（Ｎ_ｓｐ）よりも大きい場合に、ネットワーク機能を有する他のエンティティを昇格させてスーパーピアにするステップ（Ｓ２１）と
    を含むネットワーク機能を有するエンティティを動作させる方法。
20. 階層的ピアツーピア・ネットワークにおいて実際に存在しているスーパーピアの数である現存スーパーピア数を推定するステップ（Ｓ１１）と、
    推定された現存スーパーピア数（Ｎ_ｓｐ）に基づいて、実際のネットワーク状況を推定するステップ（Ｓ１３）と、
    推定された実際のネットワーク状況（Ｌ）に基づいて、階層的ピアツーピア・ネットワークにおいて要求されるスーパーピアの数である必要スーパーピア数を推定するステップ（Ｓ１５）と、
    必要スーパーピア数（Ｎ^＊ _ｓｐ）が現存スーパーピア数（Ｎ_ｓｐ）よりも小さい場合に、ネットワーク機能を有するエンティティの特性としてのスーパーピアを停止させるステップ（Ｓ２２）と
    を含むネットワーク機能を有するエンティティを動作させる方法。
21. コンピュータ・プログラムがコンピュータ及び／又はマイクロコントローラにおいて実行するとき、請求項１９又は２０に記載の方法の１つを遂行するコンピュータ・プログラム。

Images