JP2008140388A - 階層型ピアツーピアシステムにおける負荷バランシング機能を有するスーパーピア及び該スーパーピアを動作させる方法 - Google Patents

Abstract

【課題】 階層型ピアツーピアシステムにおける効率的な負荷バランシングのための装置及び方法を提供する。
【解決手段】 １つ又は複数の他のスーパーピア（Ｓ０、Ｓ１、Ｓ３、Ｓ４、Ｓ５、Ｓ６、Ｓ７）を含む階層型オーバーレイピアツーピアネットワーク（Ｎ１）に参加するためのものであって、リーフノード（ＬＮ）がリーフノードオーバーレイリンク（Ｎ２）を通して前記スーパーピア（Ｓ０−Ｓ７）のうちのいずれかへアタッチできるようにするスーパーピア（１００、Ｓ２）を開示する。前記スーパーピア（１００、Ｓ２）は、アタッチ要求メッセージ（１１２）を受信する受信機（１１０）と、アタッチ確認メッセージ（１２４）を送信する送信機（１２０）と、所定の場合に前記アタッチ確認メッセージ（１２４）を送信させるべく前記送信機を制御（１３１）する処理ユニット（１３０）とを備える。
【選択図】図１

Description

本発明はピアツーピアオーバーレイシステムの分野に関し、具体的には階層型オーバーレイピアツーピアシステムにおける負荷バランシングに関する。

オーバーレイネットワークとは、別のネットワーク上、すなわち、下層にある（underlying）物理ネットワーク上に構築されるネットワークである。オーバーレイ内のノードは、それぞれがパスに対応していて、下層にあるネットワークの１つ又は多数の物理リンクを有する仮想リンクすなわち論理リンクによって接続されていると考えられる。例えば多数のピアツーピアネットワークはインターネット上で動作するので、該多数のピアツーピアネットワークはオーバーレイネットワークである。ダイアルアップインターネットは、電話ネットワーク上のオーバーレイの一例である。オーバーレイネットワークは、通常のルーティングプロトコル、例えばＩＰ（インターネットプロトコル）ルーティングによってサポートされていない、ファイル又は任意のタイプのデータなどのアプリケーションレベルの概念のルックアップを可能にするために構築することができる。

ピアツーピア（Ｐ２Ｐ）ネットワークは、比較的少数のサーバーに集中するというよりむしろ、ネットワーク内のピア又はピアノードと呼ばれるパーティシパントの計算パワー及び帯域幅に主として依存するネットワークである。したがって、ピアツーピアネットワークにはクライアント又はサーバーという概念がなく、ネットワーク上の他のノード又はピアに対して、「クライアント」及び「サーバー」の両方として同時に機能する対等なピアノードだけを有する。ピアツーピアネットワークは、一般的に、例えばオーディオ、ビデオ、データ若しくはデジタルフォーマットであればどのようなものでも収容するコンテンツファイルを共有するため、又は、電話トラフィックのようなリアルタイムデータを伝送するために使用される。ピアツーピアネットワークの重要な目的は、全てのクライアントが帯域幅、記憶スペース及び計算パワーを含めてリソースを提供することである。したがって、ノードの到着及びシステムへの要求が増加すると、システムの総容量も増加する。

上述したようにピアツーピアオーバーレイネットワークは、オーバーレイネットワークノードとして参加している全てのピアからなる。互いを認識しているいずれの２つのノードの間にもオーバーレイリンクが存在し、すなわち、参加しているピアがピアツーピアネットワーク内の別のピアのロケーションを認識しているならば、オーバーレイネットワーク内の前者のノードから後者のノードへの有向エッジが存在する。オーバーレイネットワーク内のノードが互いにどのようにリンクされているかに基づいて、ピアツーピアネットワークが構造化されていないか又は構造化されているかが区別される。

非構造化ピアツーピアネットワークは、オーバーレイリンクが任意に確立されるときに形成される。このようなネットワークは、ネットワークへの参加を希望する新たなピアが別のノードの既存リンクをコピーすることができ、独自のリンクを形成するのにつれて、容易に構築される。非構造化ピアツーピアネットワークでは、ピアがネットワーク内で所望のコンテンツを見つけることを望む場合に、コンテンツを共有するできるだけ多数のピアが見つけられるようにキャリアがネットワークの至る所にフラッドさせられていなければならない。このようなネットワークの主な欠点は、クエリが常に解決できるとは限らないことである。人気のあるコンテンツは、おそらく複数のピアで利用でき、人気のあるコンテンツを探索しているピアは同一のものをおそらく見つけるが、少数の他のピアだけによって共有されている希少な、又はそれほど人気のないコンテンツをピアが探しているならば、探索が成功する見込みは非常に少ない。ピアとピアによって管理されているコンテンツとの間には相関が無いので、フラッディングが所望のデータを有するピアを見つけるという保証はない。さらにフラッディングは、ネットワーク内に大量のシグナリングトラフィックを生じさせる原因にもなるので、このようなネットワークの探索効率は非常に悪い。

構造化ピアツーピアネットワークは、分散ハッシュテーブル（DHT: distributed hash table）を保持し、各ピアがネットワーク内のコンテンツの特定の部分を担うことを許可することにより、非構造化ネットワークの制限を解決する。これらのネットワークは、値すなわちハッシュ値をネットワーク内のあらゆるコンテンツ及びあらゆるピアへ割り当てるためにハッシュ関数を使用し、その後に、どのピアがどのコンテンツを担当するかを決定する際にグローバルプロトコルに従う。このようにして、ピアがあるデータの探索を希望するときにはいつでも、ピアはデータを担当するピアを決定し、その後に担当するピアに向けて探索を命令するためにグローバルプロトコルを使用できる。ハッシュ値という用語は、特に分散コンテンツを管理するコンテキストでは、キー又はインデックスと呼ばれることもある。これに対応してキー空間という用語は、考えられるキーの全体集合を定めるため使用される。既知の構造化ピアネットワークには、Ｃｈｏｒｄ、Ｐａｓｔｒｙ、Ｔａｐｅｓｔｒｙ、ＣＡＮ及びＴｕｌｉｐがある。

ハッシュ関数又はハッシュアルゴリズムは、一般的に、データ、典型的にはドキュメント又はファイルを、コンピュータ若しくはその他の装置によって取り扱われるのに適した値に変化させる再現可能な方法である。これらの関数は、あらゆる種類のデータから小さいデジタル「フィンガープリント」を生成する方法を提供する。ハッシュ値は、結果として得られる「フィンガープリント」である。上記のハッシュテーブルは、ハッシュ関数の主な用途であり、ハッシュ値で与えられたデータレコードの高速なルックアップ又は検索を可能にする。

例えば、１６０ビット文字列の集合のような抽象的なキー空間の周りに構築された分散ハッシュテーブルについて説明すると、キー空間の所有権はキー空間パーティショニングスキームに応じて、参加しているノードの間で分割され、オーバーレイネットワークはノードを接続し、ノードがキー空間内で所与のキーの所有元を見つけることを可能にさせる。これらのコンポーネントが適切であるならば、記憶及び検索のための典型的な分散ハッシュテーブルの利用は以下の通りである。所与のファイル名ｆ１を有するファイルを分散ハッシュテーブルに記憶するため、ｆ１のハッシュ値が決定され、１６０ビットキーｋ１が生成される。次に、ｄ１が物理アドレス、例えばファイル所有元のＩＰアドレスであるとき、メッセージｐｕｔ（ｋ１，ｄ１）が分散ハッシュテーブルにある参加している任意のノードへ送信される。メッセージは、ペア（ｋ１，ｄ１）が格納されているキー空間パーティショニングによって特定されるようなキーｋ１を担当する単一のノードに到着するまで、オーバーレイネットワークの中をノード間で転送される。他のクライアントは、その後にキーｋ１を生成するためにファイル名ｆ１を再びハッシュ化し、ｋ１、例えばメッセージｇｅｔ（ｋ１）と関連付けられたデータを見つけることを任意の分散ハッシュテーブルノードに要求することにより、ファイルの内容を取得できる。メッセージは、キーｋ１を担当し記憶されたデータｄ１で応答するノードに向けて、オーバーレイネットワークの中を再びルーティングされる。データｄ１自体は、ｇｅｔメッセージと同じルートを使用してルーティングされるが、典型的に、下層にある物理ネットワークが提供する異なる物理ルートに基づく異なるルートを使用して伝送される。

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

Ｃｈｏｒｄ型ＤＨＴは、キーを円上の点として扱う特定の一貫性のある分散ハッシュテーブルであり、ｄ（ｋ１、ｋ２）はｋ１からｋ２まで円の周りに時計回り方向へ進んだ距離である。したがって、円形のキー空間は、端点がノード識別子である連続セグメントに分割されている。ｉ１とｉ２が隣接する２つのノード識別子であるならば、識別子ｉ２を有するノードはｉ１とｉ２との間に入る全てのキーを所有する。

各ピアは他のピアへのリンクの集合を保持し、リンクは一体となってオーバーレイネットワークを形成し、ネットワークのトポロジーと呼ばれる構造化された方法で選ばれる。リンクは、距離関数を参照して、遠くにあるピアの小さい集合に向けて、及び、最も近接する複数のピアに向けて確立されている。すべての分散ハッシュテーブルトポロジーは、最も本質的な特性のある変化を共有しており、あらゆるキーｋに対してノードはｋを所有するか、又は、上述したキー空間距離に関してｋにより近いピアへのリンクを有する。次に、以下のグリーディ（greedy）アルゴリズムを使用してメッセージをキーｋの所有者へ容易にルーティングでき、グリーディアルゴリズムでは各ステップにおいてｋに最も近接している識別子を有する近傍へメッセージを転送する。このような近傍が存在しないとき、現在のノードが、上述したｋの所有元である最近接ノードに違いない。このタイプのルーティングは、キーベースルーティングとも呼ばれる。

図７は、下層物理ネットワーク７１０と、下層物理ネットワーク７１０の上にあるピアツーピアネットワークの仮想的又は論理的なオーバーレイネットワーク７２０と、オーバーレイネットワーク７２０のノード又はピアによって管理されているキー空間７３０とを含むピアツーピアオーバーレイネットワークの階層構造を表している。例えば、上述したようなＣｈｏｒｄ型リングＤＨＴシステムでは、キー空間７３０のキーパーティションは時計回りにピアへ割り当てられる。これは、ルーティングのため、オーバーレイネットワーク自体が、ノード毎に２個のオーバーレイリンク、すなわち後述するようにＣｈｏｒｄ型リング構造に基づいて直前の近傍ノード及び直後の近傍ノードへの２つのリンクだけを備えるということを意味していないことに留意されたい。

通常、キーは、ピアのＩＰアドレス及びランダムに選択された文字列をハッシュ値にハッシュ化することによりピアへ割り当てられる。ソースキーをピアへマップするためにハッシュ関数を使用する付随的な目的は、負荷分散をバランシングすることであり、各ピアはほぼ同数のキーを担当することになる。

要約すると、特定のＤＨＴの設計は、キー空間と、距離関数と、キーパーティショニングと、リンクストラテジーとの選択に依存している。しかし、ルーティングの効率に関連した優れた特性が、何もせずにもたらされるというわけではない。ＤＨＴを構築し保持するため、ピアは特にノードの参加と障害の問題を取り扱わなければならない。構造化Ｐ２Ｐネットワークにおいて近傍選択の自由は制限されているので、保持アルゴリズムはネットワークダイナミクスの存在下で、ルーティングテーブルの一貫性を再確立することが要求される。ネットワークによって与えられる保証のタイプに依存して、決定的で確率的な様々な保持ストラテジーが開発されている。保持は、定期的なノード参加及びノード離脱、又は一貫性のないルーティングテーブルに起因するルーティング障害などの種々のイベントによりトリガされる。様々な保持ストラテジーは、保持コストと、一貫性の程度、したがって、ネットワークの障害回復力とをトレードオフする。

しかし、現行のＤＨＴ解決策は、ターゲット環境として固定的なインターネットだけに重点を置き、モバイルコンピューティング環境に適していない。現行のＤＨＴ解決策は、モバイル機器の低コンピューティング能力及び低通信能力、又は高通信コストのような主な限界を考慮していないだけでなく、セルラアドホックネットワーク又はモバイルアドホックネットワークのその他の詳細を考慮していない。この問題は、参加しているピアが２つのグループに分割されて、図８から分かるように強力な機器がスーパーピアＵ₁〜Ｕ₅として区別され、携帯電話機のような弱い機器がリーフノードＬ₁〜Ｌ₃と呼ばれる、ＤＨＴアーキテクチャを提供することにより解決される。図８による分散ハッシュテーブルでは、スーパーピアは非特許文献１に記載されているようにＣｈｏｒｄ型リングに編成され、スーパーピアへアタッチされていてリングに参加していないリーフノードへのプロキシとしての役割を果たす。

以下、階層型ピアツーピアオーバーレイネットワークについて図８に基づいてより詳細に説明する。上述したように、図８による階層型システムアーキテクチャは、ピアの２つの異なるクラス又は階層レベルであるスーパーピア及びリーフノードを定める。図８に示したようにスーパーピアは、Ｃｈｏｒｄ型リングの形をした構造化ＤＨＴベースのオーバーレイを確立し、各スーパーピアはさらに自己のリーフノードのプロキシとしての役割を果たし、すなわちリーフノードは、ピアツーピアネットワーク内で例えばピアツーピアオーバーレイネットワーク内のドキュメントをクエリするため、自己のスーパーピアを介することによってのみ通信する。したがって、リーフノードは自己のスーパーピアへのオーバーレイ接続だけを保持する。自己のスーパーピアの障害を認識して対処できるように、リーフノードは、簡単なピンポンアルゴリズムを定期的に実行する。さらにリーフノードは、スーパーピアの障害の後にオーバーレイネットワークへ再参加できるようにするため、システム内で利用可能な他のスーパーピアを格納するリストを記憶している。

これに対して、スーパーピアはその他の複数のタスクを実行する。１つの典型的な実施例では、ネットワークに参加しているリーフノードは、自己が共有しているオブジェクトへのポインタのリストを対応するスーパーピアへ転送する。その後スーパーピアは、これらのリファレンスをオーバーレイネットワークへ挿入し、リーフノードの所有元としての機能を果たす。リーフノードがルックアップを実行するとき、例えばオブジェクトをクエリするとき、Ｃｈｏｒｄ型オーバーレイの検索機能を使用してルックアップを解決するために、リーフノードが接続されているスーパーピアは、オブジェクトのキーに基づいて担当のスーパーピアを決定し、結果をリーフノードへ送る。異なる実施例では、検索されたオブジェクト又はドキュメントを担当しているスーパーピアは、リーフノードのために動作しているスーパーピアへ応答することなく、ドキュメントを要求したリーフノードへ要求されたドキュメントを直接送信することにより応答する。

さらにスーパーピアは従来のＣｈｏｒｄ型リングを確立するので、スーパーピアは、Ｃｈｏｒｄの保持アルゴリズムを定期的に実行し、リファレンスを最新の状態に保つために保持している全リファレンスを定期的に更新する。

非特許文献２では、従来のフラット型ＤＨＴ編成を上回るこのような階層型システムの以下の２つの明らかな利点が実証されている。

第一に、保持トラフィックが実質的に削減される。このトラフィックは、上述したようにルーティングテーブルを一貫性のある状態に保つために、ノードがシステムに参加又は離脱するときに必要である。非特許文献２に記載のアーキテクチャでは、リーフノードがシステムを離脱するとき、保持トラフィックは殆ど必要がない。同時に、スーパーピアはより多いオンライン回数を伴うノードから選択されるので、Ｃｈｏｒｄ型リング自体を保持するために必要とされるトラフィックも削減される。

第二に、非特許文献２に記載されているように、通信コストがより高いノード又はピアは少ないトラフィックしか実行しないので、ネットワークの総運用コストは削減される。

近年、ＤＨＴにおいて生じる負荷を、参加しているピアの間で一様にバランシングすることを目的とする多数のアルゴリズムが提案されている。通常と同じように「負荷」という用語は、ここでは、ピアに記憶されているデータ項目の量を意味している。このような負荷バランシングアルゴリズムの目標は常に、ＤＨＴに記憶されている識別子（ＩＤ）空間又はドキュメントの個数のいずれかについて均等なサイズのパーティションを、参加しているあらゆるピアへ割り当てることである。非特許文献３に記載の仮想サーバーの概念は、参加しているあらゆるピアにおけるＩＤ空間の複数のパーティションの管理に基づいている。その結果、１つのピアは複数の「仮想サーバー」を表し、各仮想サーバーはＤＨＴ内で独立したピアとして機能する。その後、これらの仮想サーバーは、ＤＨＴ内の１回のＬＥＡＶＥイベント及び１回のＪＯＩＮイベントに対応して、負荷の重いピアから負荷の軽いピアへと移される。著者は、自己のアルゴリズムが最適値に対して９５％の範囲内で負荷をバランシングさせることを明らかにしている。

非特許文献４に記載のアルゴリズムは、非特許文献５で提案されている「power of two choices」パラダイムに基づいている。ドキュメントがＤＨＴへ挿入されるときは常に、共有ドキュメントの異なるｄ個のＩＤを計算するためにｄ個のハッシュ関数が使用される。ここでｄ≧２である。その後、計算されたｄ個のＩＤを担当するピアと同時に通信し、現在最も負荷が軽いピアにドキュメントが記憶される。その上、著者は、最も負荷が低いピアへのいわゆるリダイレクションポインタをその他のあらゆる担当ピアに記憶させることを提案している。この手続により、ｄ個のハッシュ関数のうちのいずれかが、要求されたドキュメントを記憶しているピアへクエリの宛先を書き換える担当ピアを見つけ、通信するために使用できるので、ドキュメントのルックアップ中のシグナリングオーバーヘッドを削減する。

非特許文献６において、Ｒｉｅｃｈｅらは、ＤＨＴ内の負荷をバランシングする、熱分散（heat dispersion）のプロセスに似たアルゴリズムを提案している。ここで、最小でｆ個、最大で２ｆ個のピアによるＩＤ空間のすべての間隔の管理が必要となる。各ピアは、その間隔に割り当てられている全ドキュメントを記憶する。ここでの負荷バランシングは３つの異なる方法で実行される。第一に、ある間隔が２ｆ個のピアによって管理されていて、それらのピアの負荷が重い場合、間隔は半分となる。その後、半分となった間隔は、ピア（１，．．．，ｆ）とピア（ｆ＋１，．．．，２ｆ）とへそれぞれ割り当てられる。その結果、関連しているピアは自己のデータ負荷の半分を失う。第二に、ｆ個より多く、２ｆ個より少ない数のピアが間隔を管理しているならば、その間隔のピアは負荷の重い他の間隔へ移されて、次に、負荷の重い間隔は上記の手順に従って分割できる。第三に、ｆ個以下のピアが間隔を管理しているならば、近傍の間隔にあるピアの間で負荷をバランシングできるように、間隔の境界をシフトできる。著者は、このアルゴリズムが、上述したアルゴリズム、すなわち「仮想サーバー」（非特許文献３）及び「power of two choices」（非特許文献４）よりも良好に機能することを明らかにしている。

非特許文献７は、Ｃｈｏｒｄ型オーバーレイにおいて、ＩＤ空間の分散をバランシングするアルゴリズムと、共有ドキュメントの分散をバランシングするアルゴリズムという２つのアルゴリズムを提案している。ＩＤ空間バランシングでは、ＩＤ空間の複数の位置、いわゆる「仮想ノード」があらゆるピアへ割り当てられるが、一度にこれらの仮想ノードのうちの１つだけがアクティブ状態になるように選択される。時々、各ピアは、ＩＤ空間の最小のパーティションを管理する自己の仮想ノードを決定し、その仮想ノードをアクティブ化する。ドキュメントバランシングの場合、ピアｐ_iの負荷が、ランダムに選択されたピアｐ_jである別のピアの負荷と時折比較される。ｐ_iとｐ_jとの間の負荷バランシングが必要な場合、ｐ_jは、ｐ_iとｐ_iの前のピアとの間に位置し、ｐ_iの項目のうちの半分を捉えることができるようにＩＤ空間内での自己の位置を変化させる。

Ｋｅｎｔｈａｐａｄｉ及びＭａｎｋｕは非特許文献８において、ＩＤ空間を均等なサイズのパーティションに分割することにより、ＤＨＴ内の負荷をバランシングしようとしている。彼らの目標は、パーティションの最大サイズと最小サイズとの間の比σを最小限に抑えることである。したがって、参加中のピアに重点が置かれ、あらゆる参加に関して、ＤＨＴ内のｒ個のランダム点が選択され、各ランダム点に隣接したｖ個のパーティションのサイズが調べられる。その後、参加中のピアは見つかった最大のパーティションを半分に分割する。著者は、ｃが小さい定数であり、第ｋ番目のピアが参加する前のＤＨＴ内のピアの個数がｋ−１である場合に、ｒ・ｖ≧ｃ ｌｏｇ₂ ｋを満たす任意のｒ及びｖに対して比σは高い確率で高々８であることを示している。

上記のアルゴリズムの全ては、いわゆるフラットなＤＨＴ設計、すなわち全ノードが機能的に同一であるＤＨＴ設計に重点を置いている。その結果として、これらのアルゴリズムは全て、ピアが担当しているドキュメントの個数を選択することにより、負荷をバランシングすることを選ぶ。この決定は、ドキュメント挿入フェーズ、又はシステムの通常動作中（クエリフェーズ）のいずれかにおいて行われる。しかしながら、異質のネットワークのために提案されたシステムアーキテクチャはフラットではない。それどころか、このシステムアーキテクチャは、トップレベルのスーパーピアと、それらへアタッチされているリーフノードとを含んでいて階層的である。

I. Stoica, R. Morris, D. Karger, M. Kaashoek, and H. Balakrishnan., "Chord: A Scalable Peer-to-Peer Lookup Service for Internet Applications", ACM SIG-COMM Conference, 2001 Zoels S., Despotovic Z., Kellerer W., Cost-Based Analysis of Hierarchical DHT Design, Sixth IEEE International Conference on P2P Computing, Cambridge, UK, 2006 Rao A., Lakshminarayanan K., Surana S., Karp R. and Stoica I., "Load Balancinig Structured P2P Systems", International Workshop on Peer-to-Peer Systems (IPTPS '03, Berkely, USA, 2003 Byers J., Considine J., and Mitzenmacher M., "Simple Load Balancing for DHTs", International Workshop on Peer-to-Peer Systems (IPTPS '03), Berkeley, USA, 2003 Mitzenmacher et. al in "The Power of Two Random Choices": A Survey of Techniques and Results, Kluwer Academic Publish-ers, Norwell, 2001, pages 255-312 "A Thermal-Dissipation-based Approach for Balancing Data Load in Distributed Hash Tables", IEEE Conference on Local Computer Networks (LCN 2004), Tampa, USA, 2004 Karger and Ruhl "Simple Efficient Load Balancing Algorithms for Peer-to-Peer Systems", International Workshop on Peer-to-Peer Systems (IPTPS '04), San Diego, USA, 2004 Kenthapadi and Manku try in "Decentralized Algorithms using both Local and Random Probes for P2P Load Balancing", ACM Symposium on Parallelism in Algorithms and Architectures (SPAA05), Las Vegas, USA, 2005

本発明の目的は、階層型ピアツーピアシステムにおける効率的な負荷バランシングのための装置及び方法を提供することである。

上記目的は、請求項１に記載の階層型ピアツーピアシステムにおいて負荷バランシングをサポートすることができるスーパーピアと、請求項１０に記載の階層型ピアツーピアシステムにおいて負荷バランシングをサポートすることができるスーパーピアを動作させる方法と、請求項１１に記載のコンピュータプログラムとによって達成される。

本発明は、階層型ピアツーピアシステムにおいて負荷バランシングをサポートすることができ、リーフノードオーバーレイリンクを通してリーフノードがアタッチすることができる１つ又は複数の他のスーパーピアを含む階層型ピアツーピアシステムのスーパーピアオーバーレイネットワーク（Ｎ１）をセットアップするスーパーピアであって、前記リーフノードが前記階層型ピアツーピアシステムへのアタッチを要求していることを表すアタッチ要求メッセージを受信する受信機と、アタッチ確認メッセージを送信する送信機と、アタッチ要求メッセージを受信したという通知を前記受信機から受けて、前記スーパーピアのトラフィック負荷値を、前記他のスーパーピアに関連付けられているトラフィック負荷値、又は負荷トラフィック値が関連付けられている複数のスーパーピアのトラフィック負荷値と比較し、前記スーパーピアのトラフィック負荷値が前記他のスーパーピアのトラフィック負荷値以下であるか、又は複数の前記スーパーピアに関連付けられているトラフィック負荷値のうちの最小トラフィック負荷値以下である場合は、前記スーパーピアとのリーフノードオーバーレイリンクを通して前記リーフノードが前記階層型ピアツーピアシステムへアタッチされることを通知するために、前記アタッチ確認メッセージを送信させるべく前記送信機を制御する処理ユニットとを備えるスーパーピアを提供する。

本発明は、リーフノードオーバーレイリンクを通してリーフノードがアタッチすることができる１つ又は複数の他のスーパーピアを含む階層型ピアツーピアシステムのスーパーピアオーバーレイネットワークをセットアップするスーパーピアを動作させる方法であって、前記リーフノードが前記階層型ピアツーピアシステムへのアタッチを要求していることを表すアタッチ要求メッセージを受信するステップと、前記スーパーピアのトラフィック負荷値を、前記他のスーパーピアに関連付けられているトラフィック負荷値、又は負荷トラフィック値が関連付けられている複数のスーパーピアのトラフィック負荷値と比較するステップと、前記スーパーピアのトラフィック負荷値が前記他のスーパーピアのトラフィック負荷値以下であるか、又は前記複数のスーパーピアに関連付けられているトラフィック負荷値のうちの最小トラフィック負荷値以下である場合は、前記スーパーピアとのリーフノードオーバーレイリンクを通して前記リーフノードが前記階層型ピアツーピアシステムへアタッチされることを通知するためにアタッチ確認メッセージを送信するステップとを含む方法をさらに提供する。

最後に、本発明は、本発明に係る方法をコンピュータに実行させるプログラムコードを有するコンピュータプログラムを提供する。

本発明は、リーフノードがネットワークへ参加するときに、スーパーピアの間で生じた負荷をバランスシングできるようにリーフノードが異なるスーパーピアへ割り当てられるという、階層型ピアツーピアネットワークが負荷バランシングのもう１つの可能性を提供するという見地に基づいている。これが、本発明による解決策と、フラット型ピアツーピアシステムに対してこれまでに記載した負荷バランシングスキームとの間の重大な相違点である。本発明による解決策の実施形態は後述するように、既存の実施形態と競合することなく、既存の実施形態のうちのいずれとも一緒に機能するため、既存の実施形態と直交性がある（orthogonal）ことをさらに強調する。

本発明は、フラット型ピアツーピアシステムに対してこれまでに説明した負荷バランシングスキームによって定められている負荷の定義が、全てのスキームにおいてある程度の誤解があるという見地にさらに基づいている。これまでの定義では、ピアが担当するドキュメントの数は、ピアの負荷を定義するために用いられている。しかしこの定義は、例えばある特定のドキュメントが要求される回数を考慮していないので、この種の負荷分散を考慮できないだけでなく、この定義は、階層型ピアツーピアシステムにおいてリーフノードからの全クエリ及びリーフノードへの全クエリが、これらのリーフノードを担当しているスーパーピアを通してルーティングされるということを考慮していない。これはそれぞれのスーパーピアの負荷をさらに増加させ、ドキュメント又はキーの数のみに基づいて負荷を決定することにより考慮されていない。したがって、本発明によれば負荷は、ネットワーク動作中にピアが転送したメッセージの数、すなわちトラフィック負荷として定義される。パケットのサイズが異なる可能性があるということを考慮するために、パケットの個数と等価的にビット毎秒のような他のトラフィック指標もトラフィック負荷のメトリックとして使用できる。

負荷バランシングのためのこの新しいトラフィック指向型のメトリックは、フラット型ピアツーピアシステムに関して説明した負荷バランシングの解決策に対しても使用できる。ピアが記憶できるドキュメントの数を保持するのではなく、あらゆるピアは自己のトラフィックに関する情報を保持していればよい。その後この情報は、上記のアルゴリズムに基づいて決定を行うために使用される。

スーパーピアは、ピアツーピアシステムの第１の階層レベルに属しているので、第１レベルのピアと呼ばれることもある。リーフノードは、階層型ピアツーピアシステムの第２の階層レベルに属しているので、第２レベルのピアと呼ばれることもある。したがって、「ノード」という用語にかかわらず、リーフノードは、階層型オーバーレイピアツーピアシステムのピアでもあるが、リーフノード自体はスーパーピアのようにキー空間パーティション又はルーティングを担当しない。

上述したように、負荷バランシングはピアツーピアシステムにおける重要な課題である。ピアの間で均等にバランスの取れた負荷は、ピアの故障確率を低下させ、ネットワーク安定性を増大させることにより、ネットワークのより良好な動作を可能にする。この問題に対する現在の解決策の殆どは、上述したようにドキュメントをシステムに挿入するときの負荷バランシング、及び／又は、負荷が歪んでいるときの負荷シフトを重点的に取り扱っている。階層型システムアーキテクチャは、本発明の実施形態が利用する別の可能性を提供する。階層型アーキテクチャは、スーパーピアとリーフノードという２つのピアのクラスを有する。本発明の実施形態によって使用される負荷バランシングの解決策は、スーパーピア間でトラフィック負荷をバランシングするため、リーフノードを様々なスーパーピアへ動的に割り当てる。動的な割り当ては次の通り行われる。例えば、あるリーフノードからジョインリクエストを受信したスーパーピアは、自己のルーティングテーブルに基づいて現在最も負荷の軽いスーパーピアへこのジョインリクエストを転送する。好ましい実施形態では、ジョインリクエストは、近傍のスーパーピアであるフィンガーの全部より負荷の軽いスーパーピアが見つかるか、又は転送の最大回数に達するまで転送される。

同じ原理は、リーフノードが参加を希望するときの負荷バランシングのため使用されるだけでなく、保持アクティビティとして負荷バランシングを実行するために、あるスーパーピアへ既にアタッチされているリーフノードを別のスーパーピアへ移すためにも使用できる。

シミュレーションの結果は、ピア全体の負荷の標準偏差が、広範囲のパラメータ設定値に対して数パーセントの範囲内にとどまることを明らかにしている。同時に、このアプローチが負担する付加的なコストは非常に小さい。安定かつ低コストのネットワーク動作、並びに高い障害回復率は、提案された負荷バランシングの解決策の実施形態の主要な利点として既に記載したとおりである。具体的には、スーパーピアの安定性を改善し、スーパーピアの障害確率を低下させるために、スーパーピア間で負荷のバランスを取ることが重要である。なぜならば、負荷のバランスが取れていないとき、過負荷状態のスーパーピアが通信容量の限界に達する場合があり、このことがネットワークの一貫性のない動作を招き、すなわち、メッセージが頻繁に送られることがあるためである。より厳しい結果は、オーバーレイノードの障害、特に、階層型ピアツーピアシステム内のスーパーピアの障害である。この場合、ネットワークを再編成するために保持アルゴリズムを実行しなければならないので、ネットワーク全体の性能は劣化する。極端な場合、ネットワーク全体が崩壊する。このような問題を回避するため、本発明のスーパーピアの実施形態は、できるだけ均等に負荷を分担する。上述したように、解決策の主な考え方は、リーフノードがスーパーピアの負荷レベルに応じて様々なスーパーピアへアタッチされるということである。

本発明の好ましい実施形態について、図面を参照しながら詳細に説明する。

図１は、階層型ピアツーピアシステムにおいて負荷バランシングをサポートすることができるスーパーピアであって、１つ又は複数の他のスーパーピアを含む階層型ピアツーピアシステムのスーパーピアオーバーレイネットワークをセットアップして、リーフノードがいずれかのスーパーピアとのリーフノードオーバーレイを通してアタッチすることのできるスーパーピアの実施形態を示している。スーパーピアオーバーレイネットワークはスーパーピアによって形成され、少なくとも２つのスーパーピアを備えている。そうでなければ、スーパーピア間の負荷バランシングは実行できない。リーフノードは、スーパーピアのうちの１つだけを通してピアツーピアシステムへ接続されている。したがって、「プロキシ」という用語もスーパーピアに対して使用できる。スーパーピア１００は、受信機１１０と送信機１２０と処理ユニット１３０と記憶ユニット１４０とを備えている。受信機１１０は、リーフノードがスーパーピアのうちの１つを通して階層型ピアツーピアシステムへアタッチされることを要求していることを表すアタッチ要求メッセージ１１２を受信する。「アタッチ」という用語は「接続」という意味で使用している。

アタッチ要求メッセージは、例えばスーパーピアが、リーフノードが直接通信するスーパーピアである場合にはリーフノード自体によって送信されていることがあり、あるいは別のスーパーピアによって送信されていることもある。

一実施形態では、処理ユニット１３０は、アタッチ要求メッセージ１１２を受信したという通知１１４を受信機１１０から受信すると、スーパーピア１００のトラフィック負荷値を他のスーパーピアのトラフィック負荷値と比較する。具体的には、階層型ピアツーピアシステムの実施形態は２つ以上のスーパーピアを備えており、それに応じてスーパーピア１００の処理ユニット１３０は、スーパーピアが２つの場合は自己のトラフィック負荷値をもう一方のスーパーピアに関連付けられているトラフィック負荷値と比較し、ピアツーピアシステムがスーパーピア１００以外に複数のスーパーピアを含む場合はいくつかのスーパーピアのトラフィック負荷値と比較する。

送信機１２０は、アタッチ確認メッセージ１２４を送信する。

処理ユニット１３０は、アタッチ要求メッセージ１１２を受信したという通知１１４を受信機１１０から受信すると、リーフノードをアタッチすべきか、又は要求を別のスーパーピアへ転送すべきかを決定する。決定のプロセスは図２Ａ及び２Ｂに基づいてより詳細に説明する。一実施形態では処理ユニット１３０は、スーパーピア１００のトラフィック負荷値を、他のスーパーピアに関連付けられているトラフィック負荷値、又はいくつかのスーパーピアのトラフィック負荷値と比較する。ここで、いくつかのスーパーピアのそれぞれは、ある負荷トラフィック値に関連付けられており、それぞれスーパーピアが指定されている。処理ユニット１３０はさらに、スーパーピア１００のトラフィック負荷が、他のスーパーピアのトラフィック負荷以下であるか、又はいくつかのスーパーピアに関連付けられているトラフィック負荷のうち最小のトラフィック負荷以下である場合に、あるリーフノードがスーパーピア１００とのリーフノードオーバーレイリンクを通して階層型ピアツーピアシステムへアタッチされることを通知するために、転送アタッチ確認メッセージ１２２を送信させるべく送信機１２０を制御する。

トラフィック負荷は、トラフィック負荷値、例えば時間当たりのパケット数または１秒当たりのビット数によって表すことができる。この場合、処理ユニットの実施形態は、スーパーピア１００のトラフィック負荷値が他のスーパーピアのトラフィック負荷値以下であるか、又は複数のスーパーピアに関連付けられているトラフィック負荷値のうち最小のトラフィック負荷値以下であるならば、転送アタッチ確認メッセージ１２２を送信させるべく送信機１２０を制御する。

代替的な実施形態では、処理ユニットは、例えば上記のトラフィック負荷値の逆数をトラフィック負荷値として使用する。これに応じて、この場合、処理ユニットの実施形態として、スーパーピア１００のトラフィック負荷値が他のスーパーピアのトラフィック負荷値以上であるか、又はいくつかのスーパーピアに関連付けられているトラフィック負荷値のうち最大のトラフィック負荷値以上である場合に、転送アタッチ確認メッセージ１２２を送信させるべく送信機１２０を制御する。

以下に、典型的なトラフィック負荷値として時間当たりのパケット数を用いる実施形態について説明する。これは、本発明の範囲を限定するものではない。

したがって、さらなる実施形態では、スーパーピア１００は、スーパーピア１００の負荷トラフィック値が他のスーパーピアの負荷トラフィック値より大きいか、又はいくつかの他のスーパーピアのうち最小の負荷トラフィック値より大きい場合に、他のスーパーピア、又はいくつかのスーパーピアのうちの最小の負荷トラフィック値が関連付けられているスーパーピアへ転送アタッチ要求メッセージ１２２を送信すなわち転送させるべく送信機１２０を制御１３１する。

図２Ａに基づいてより詳細に説明すれば、好ましい実施形態では、スーパーピア１００は、アタッチ要求メッセージに関連付けられているコネクション転送カウンタをさらにチェックして、コネクション転送カウンタがある転送カウンタスレショルドに達している場合にはアタッチ要求メッセージをそれ以上転送しない。転送カウンタは、ループ、すなわちアタッチ要求メッセージの「エンドレスな」転送を回避するために使用される。

別の好ましい実施形態では、スーパーピアは、もう一つのスーパーピア、又はいくつかのスーパーピアのそれぞれのためのオーバーレイネットワーク識別子を含むルーティングテーブルを記憶する記憶ユニット１４０をさらに備えている。ここで、各スーパーピアにはユニークなオーバーレイネットワーク識別子が割り当てられ、もう一つのスーパーピアに関連付けられるトラフィック負荷値、又はそれぞれのトラフィック負荷値は、１つのスーパーピア又はいくつかのスーパーピアへそれぞれ関連付けられる。上記処理ユニットは、トラフィック負荷値の比較及びアタッチ要求メッセージの転送のためにルーティングテーブルを使用する。

他のスーパーピアのトラフィック負荷値は、例えば明示的な保持メッセージを通して受信できるか、又は他のメッセージ１１６にピギーバックすることができる。代替的な実施形態では、スーパーピアは、アタッチ要求メッセージを受信するたびに、特定のスーパーピアのトラフィック負荷値を要求する。

ルーティングテーブルは、全てのスーパーピアのそれぞれに関連付けられている各トラフィック負荷値を含めてピアツーピアシステムの全てのスーパーピアを含むことができるが、典型的には、保持のコスト及び関連したトラフィックを許容可能な大きさに維持するために、全てのスーパーピアの部分集合、例えばフィンガーとも呼ばれる近傍ノード及びそれらに関連付けられているトラフィック負荷値だけを含んでいる。

さらなる実施形態では、スーパーピア１００の好ましい実施形態の処理ユニット１３０は、自己のトラフィック負荷を監視して測定し、トラフィック負荷値を所与のトラフィック負荷スレショルドと比較して、アタッチされているリーフノードが複数のスーパーピアのうちの異なるスーパーピアへアタッチされるように、既にスーパーピア１００へアタッチされているリーフノードの移動を開始すべく移動アタッチ要求メッセージ１３２を別のスーパーピアへ送信させるために送信機１２０を制御１３１する。したがって、これらのリーフノードを他のスーパーピアへ移動させるか、又は、これらのリーフノードを他のスーパーピアへ再アタッチすることにより、スーパーピアが、既にピアツーピアネットワークへアタッチされているリーフノードにより生じる負荷についてスーパーピア間で能動的にバランスを取ることも可能である。

この監視は継続して実行することができ、さらにアタッチ休止メッセージを受信したときは常に付加的に実行することができ、定期的に実行することもでき、あるいは所定の内部イベント若しくは外部イベントにより実行することもできる。

したがって、図１をもう一度参照すると、以下のケース、すなわちアタッチ要求メッセージのタイプを区別することができる。ａ）として、リーフノードがジョインアタッチ要求メッセージをスーパーピアへ直接送信する、すなわちジョイン要求を開始する。ｂ）として、スーパーピアが移動アタッチ要求メッセージ１３２を別のスーパーピアへ送信する、すなわち移動要求を開始する。ｃ）として、スーパーピアが転送アタッチ要求メッセージ１２２を送信する、すなわち上述の要求のうちの１つを転送する。

メッセージの原因、すなわちジョイン要求又は移動要求、及びメッセージのタイプに関わらず、個別のメッセージの生成、及び受信メッセージの取り扱い又は処理は、例えば転送カウンタのインクリメントとチェックの有無、又は負荷トラフィック値の比較とリーフノードをアタッチすべきかどうかの決定の有無に関係なく、同じ方法又は少なくとも類似した方法で実行できる。すなわち、アタッチ確認メッセージ１２４を生成し、あるいは要求、すなわちアタッチ要求メッセージ１２２を生成し、次のスーパーピアへ転送する。スーパーピアが、転送アタッチ要求メッセージを送信する次のスーパーピアをどのようにして決定するかに関しても同じである。

したがって、例えばスーパーピアの実施形態では、処理ユニット１３０は、移動要求の場合も、他のスーパーピアのトラフィック値を比較し、アタッチ要求メッセージ１２４を複数のスーパーピアの中でも最小のトラフィック負荷値を有するスーパーピアへ送信させるべく送信機１２０を制御１３１する。

他の実施形態では、これらのメッセージタイプは区別することができ、様々な方法で処理される。

転送アタッチ要求メッセージ１２２を用いない実施に基づくと、ピアツーピアネットワークへの参加を要求しているリーフノード、又は自己へアタッチしているリーフノードのうちの１つの移動を要求している別のスーパーピアは、スーパーピアのうちの１つがアタッチ確認メッセージ１２４により要求を確認するまで、それ自体がさらなるアタッチ要求メッセージ、すなわちジョインアタッチ要求メッセージ又は移動アタッチ要求メッセージを送信しなければならない。

転送アタッチ要求メッセージを用いる実施の場合、転送アタッチ要求メッセージは「転送」されるので、参加を要求しているリーフノードも移動を要求しているスーパーピアも、スーパーピアの転送機能を用いない上記の実施形態では必要となるそれぞれのアタッチ要求メッセージの送信を繰り返す必要がない。

送信される転送アタッチ要求メッセージ１２２は、受信したアタッチ要求メッセージ１１２と同じフォーマットを有することができる。例えば、転送カウンタが適用されない場合にはルーティング情報だけが変更され、又は転送カウンタが適用される場合には転送カウンタがさらにインクリメントされることもある。しかし、受信したアタッチ要求メッセージ１１２と異なることもある。別のスーパーピアからの要求の受信に起因する送信も、要求の「転送」と呼ばれる。

以下、階層型ピアツーピアネットワークにおける負荷バランシングの方法の実施形態についてより詳細に説明する。第一に、スーパーピアの負荷レベルは、バランスを取るべき量又はメトリックとして定められている。スーパーピアの負荷レベルλは、いかなる時点においてもそのスーパーピアが現在担っている負荷の大きさを以下のように定めるものである。
λ_i（ｔ）＝（時間ｔにおけるスーパーピアｉの送信メッセージの数）／ｔ

スーパーピアは、自己の現在の負荷レベルλを常に計算する。さらにスーパーピアは、Ｃｈｏｒｄ型オーバーレイにおいて、あらゆるルーティングテーブル更新メッセージ、例えばフィックスフィンガーメッセージ内のピギーバック情報としてこの情報を交換する。その結果、スーパーピアは、さらなるネットワークトラフィックを発生させることなく、自己のルーティングテーブル内のｌｏｇ₂Ｎ_sp個（Ｎ_SPはＤＨＴ内のスーパーピアの数である）の全エントリーの負荷レベルを常に認識している。負荷バランシングアルゴリズムの問題は、最小限の努力でシステム内の全スーパーピアに対して等しい負荷レベルを供給することである。

以下により詳細に説明する負荷バランシングアルゴリズムは、オーバーレイネットワークに参加しているリーフノードを重点的に取り扱う。しかし、既にあるスーパーノードへアタッチされているリーフノードが、このリーフノードが現在アタッチされている特定のスーパーノードの負荷を低減させるために別のスーパーピアへ移動する場合にも同じノードバランシングアルゴリズムが適用できることは、当業者には明らかである。相違点は基本的にはアタッチ要求メッセージ送信の原因又は理由のみにある。受信したスーパーピアによるアタッチ要求メッセージの取り扱いは、同じように実施できる。

リーフノードがオーバーレイネットワークに参加しているときは常に、最初に通信したスーパーピアは、自己のルーティングテーブル内で負荷レベルλが最も小さいスーパーピアへジョイン要求を転送する。このジョイン要求の転送は、スーパーピアｉのルーティングテーブル内の全ての負荷レベルエントリーよりも小さい負荷レベルλ_iを有するスーパーピアｉが見つかるか、又は最大転送カウントに達するまで続く。したがって、参加中のリーフノードはスーパーピアｉへ接続される。

アルゴリズムの実施形態は、擬似コードの形式で図２Ａに示されている。ここで、ｎは参加中のリーフノードであり、Ｓ_iはリーフノードｎが第ｉ番目に通信したスーパーピアである。

第１行では、コネクション転送カウンタＣＦＣ（connection forward counter）が０にセットされる。第２行で、アルゴリズムが開始する。第３行で、リーフノードｎがＳ_CFCと通信する。すなわち、ＣＦＣ＝０の場合、リーフノードは最初のスーパーピアと通信し、ＣＦＣ＞０の場合、一巡して第３行へ戻ることを定めている第１０行から分かるように、第３行はアタッチ要求メッセージが次のスーパーピアへ転送されていることを示している。第４行で、コネクション転送カウンタ値ＣＦＣを、コネクション転送カウンタスレショルドとも呼ばれる最大コネクション転送カウンタ値ＣＦＣ_maxと比較し、アタッチ要求メッセージを受信したスーパーピアのトラフィック負荷値λ（ＳＦＣ）が、ルーティングテーブルに記憶されている他のスーパーピアのトラフィック負荷値と比較される。コネクション転送カウンタＣＦＣがコネクション転送カウンタスレショルドＣＦＣ_maxに等しいか、又はスーパーピアのトラフィック負荷値λ（Ｓ_CFC）がルーティングテーブルに格納されているトラフィック負荷値のうちの最小のトラフィック負荷値λ_min以下である場合に、リーフノードｎが第５行に記載されているように現在のスーパーピアＳ_CFCに接続すなわちアタッチされて、第６行に記載されているようにこのアルゴリズムが終了する。２つの条件がいずれもが満たされない場合、アルゴリズムは第７行及び第８行へジャンプし、現在のスーパーピアＳ_CFCのルーティングテーブル内で最小のトラフィック負荷値λを有するスーパーピアが次のスーパーピアＳ_CFC+1として選ばれて、アタッチ要求メッセージが選ばれた次のスーパーピアへルーティングされる。第９行でコネクション転送カウンタＣＦＣがインクリメントされ、その後第１０行でアルゴリズムは第３行へ戻る。

要約すると、このアルゴリズムは、自己の全フィンガーすなわち近傍よりも小さな負荷を有するスーパーピアが見つけられるか、又は最大転送カウントに達するまで、リーフノードのジョイン要求を転送すると説明することができる。

図２Ｂは、スーパーピアを動作させる方法の好ましい実施形態をフローチャートとして示している。ステップ２１０において、スーパーピア１００はアタッチ要求メッセージを受信する。ステップ２２０においてスーパーノード１００は、コネクション転送カウンタＣＦＣをコネクション転送カウンタスレショルドＣＦＣ_maxと比較して、コネクション転送カウンタＣＦＣがコネクション転送カウンタＣＦＣ_maxに等しい場合、リーフノードがスーパーノード１００へアタッチされることを確認するために、スーパーノード１００はアタッチ確認メッセージ１２４を送信する。コネクション転送カウンタＣＦＣがコネクション転送カウンタＣＦＣ_maxに等しくない場合、すなわちコネクション転送カウンタＣＦＣ_max未満である場合、この方法はステップ２４０へ進み、トラフィック負荷値λ（Ｓ_CFC）はスーパーピア１００のルーティングテーブル内のトラフィック負荷値と比較される。スーパーピア１００のトラフィック負荷値λ（Ｓ_CFC）が、ルーティングテーブルに格納されている全トラフィック負荷値のうちの最小トラフィック負荷値λ_min以下であるならば、この方法はステップ２３０へ進み、アタッチ確認メッセージを送信する。負荷トラフィック値λ（Ｓ_CFC）が最小負荷トラフィック値λ_minより大きいならば、この方法はステップ２５０へ進み、コネクション転送カウンタＣＦＣをインクリメントし、アタッチ要求メッセージ１２２を、最小スレショルド値λ_minが関連付けられている次のスーパーピアへ送信すなわち転送する。

図３Ａは、８つのスーパーピアＳ０〜Ｓ７がＤＨＴ Ｃｈｏｒｄ型リングを形成している階層型ピアツーピアシステムの典型的な実施形態を示している。図３Ａは、スーパーピアＳ０に対して１つのリーフノードＬ０−１がアタッチされており、スーパーピアＳ１に対して２つのリーフノードＬ１−１及びＬ１−２がアタッチされており、スーパーピアＳ２にはリーフノードがアタッチされておらず、スーパーピアＳ３にリーフノードＬ３−１がアタッチされており、スーパーピアＳ４にリーフノードＬ４−１がアタッチされており、スーパーピアＳ５にリーフノードＬ５−１がアタッチされており、スーパーピアＳ６にリーフノードＬ６−１がアタッチされており、スーパーピアＳ７に対してリーフノードＬ７−１及びＬ７−２がアタッチされているシナリオを示している。Ｎ１は、スーパーピアによって形成されたスーパーピアオーバーレイネットワーク又は第１階層レベルのオーバーレイネットワークを表している。Ｎ２は、リーフノードを各スーパーピアへアタッチするためのリーフノードオーバーレイリンク又は第２階層レベルのオーバーレイリンクのサンプルを表している。図３Ａに示した実施形態に関して、キー空間は０から７９９まで定義され、キー空間はスーパーピアの間で等距離になるようにパーティショニングされ、８つのスーパーピアのオーバーレイネットワーク識別子はキー値に対応することをさらに仮定する。換言すると、Ｃｈｏｒｄ型リング構造によれば、スーパーピアＳ０は、上述したように、同時にキー値０に対応しているオーバーレイネットワーク識別子０を有し、スーパーピアＳ１はオーバーレイネットワーク識別子１００を有し、スーパーリクエスト２はオーバーレイネットワーク識別子２００を有し、スーパーピアＳ３はオーバーレイネットワーク識別子３００を有し、スーパーピアＳ４はオーバーレイネットワーク識別子４００を有し、スーパーピアＳ５はオーバーレイネットワーク識別子５００を有し、スーパーピアＳ６はオーバーレイネットワーク識別子６００を有し、スーパーピアＳ７はオーバーレイネットワーク識別子７００を有する。Ｃｈｏｒｄ型リング構造によれば、スーパーピアＳ１はキー区分１〜９９を担当し、スーパーピアＳ２はキー区分１００〜１９９を担当し、以下同様である。したがって、図３Ａに示したＣｈｏｒｄ型リングは、Ｃｈｏｒｄ型リングシステムのブロック的な区分を表しており、かつ、同様に、一般的には、時計回りのルーティング概念を表している。しかし、図７をもう一度参照すると、ルーティング自体は様々な方法で実行され、必ずしも図３Ａに示されているようなリング構造に限定されないことに留意されたい。一実施形態では、ルーティングは、各スーパーピアが自己の時計回り又は反時計回りの直ぐ隣のスーパーピアへのルートだけを選定するように限定することができ、例えば、スーパーピアＳ２はスーパーピアＳ１又はスーパーピアＳ３へのルートだけを選定することになる。しかし、好ましい実施形態では、スーパーピアＳ２のルーティングテーブルはその他のスーパーピアも有している。１つの典型的な例では、スーパーピアＳ２のルーティングテーブルは、回復力の理由から、例えば直ぐ隣のスーパーピアＳ１又はスーパーピアＳ３の一方が障害又は離脱した場合に、自己の直ぐ隣のスーパーピアの直ぐ隣のスーパーピアとして、スーパーピアＳ０及びスーパーピアＳ４のオーバーレイネットワーク識別子をさらに含む。他の実施形態では、スーパーピアＳ２のルーティングテーブルは、スーパーピアＳ７のネットワーク識別子をさらに含むことができる。ルーティングテーブルをセットアップするための様々な可能性は当業者にとって既知なので、これ以上詳細には説明しない。

図３Ａは、特に、新しいリーフノードＬＮがピアツーピアネットワークへ参加することを望む状況を示している。

新しいリーフノードＬＮがピアツーピアネットワークへの参加を望むとき、新しいリーフノードＬＮは、図２Ａ及び図２Ｂに基づいて説明したように、ジョイン要求メッセージという形でアタッチ要求メッセージを例えばスーパーピアＳ２へ送信する。

その後、スーパーピアＳ２は、自己のトラフィック負荷値を、例えば近傍のスーパーピアＳ０、Ｓ１、Ｓ３及びＳ４のトラフィック負荷値を含む自己のルーティングテーブルの中のトラフィック負荷値と比較する。その後、この比較に基づいてスーパーピアＳ２は、新しいリーフノードＬＮを自己へアタッチすべきか、又は最小トラフィック負荷値が関連付けられているスーパーピアへアタッチ要求メッセージを送信すべきかを決定する。

スーパーピアＳ２の自己のトラフィック負荷値が、スーパーピアＳ０、Ｓ１、Ｓ３及びＳ４のそれぞれの負荷トラフィック値以下である場合、新しいリーフノードＬＮはスーパーピアＳ２へアタッチされることになる。

例えば、スーパーピアＳ３がスーパーピアＳ０、Ｓ１、Ｓ３、Ｓ４のうちの最小トラフィック負荷値を有していて、スーパーピアＳ２のトラフィック負荷値がスーパーピアＳ３に関連付けられている最小トラフィック負荷値より大きい場合、スーパーピアＳ２は新しいリーフノードＬＮのアタッチ要求メッセージをスーパーピアＳ３へ転送する。

スーパーピアはスーパーピアＳ２と同じステップを実行する。例えば、スーパーピアＳ３の自己のトラフィック負荷値がスーパーピアＳ１、Ｓ２、Ｓ４、Ｓ５のトラフィック負荷値以下であるならば、図３Ｂに示したように新しいリーフノードを自己へアタッチし、これに応じて、アタッチ確認メッセージをリーフノードＬＮへ送信することを決定する。

典型的に、モバイルピアツーピアネットワークは、様々な性能すなわち様々な処理パワー又は帯域幅を有するピアを備えている。したがって、好ましい実施形態では、各スーパーピアは、自己の実際の絶対負荷トラフィック値を測定するだけでなく、図２Ａ及び図２Ｂに基づいて説明した負荷トラフィック値の比較のため、相対負荷トラフィック値も決定する。このため、各ピアの個別の能力に依存して、最大負荷トラフィック値が各ピアに関連付けられる。よって、相対負荷トラフィック値は、例えば、実際の絶対トラフィック負荷値と最大トラフィック負荷値との間の比として決定される。よって、ピアの様々な個別の能力が負荷を分散させるときに考慮される。

例えば、スーパーピアＳ２がスーパーピアＳ３と同数のクエリを受信するが、スーパーピアＳ３と同じ性能ではない場合、すなわち、スーパーピアＳ２の方が小さい最大トラフィック負荷値を有する場合、スーパーピアＳ２の相対負荷トラフィック値はスーパーピアＳ３の相対トラフィック負荷値より大きいので、スーパーピアＳ２は新しいリーフノードＬＮのアタッチ要求メッセージをスーパーピアＳ３へルーティングする（スーパーピアＳ３がスーパーピアＳ０〜Ｓ４の中で最小の相対トラフィック負荷値を有する場合）。負荷バランシングスキームの実施は、絶対負荷トラフィック値と相対負荷トラフィック値とのいずれが使用されるかとは無関係である。

図３Ｂは、新しいリーフノードＬＮがリーフノードＬ３−２としてスーパーピアＳ３へアタッチされた後の、図３Ａの階層型ピアツーピアオーバーレイネットワークを示している。

スーパーピアの間でリーフノードの数を均等に分散させることを目的とする負荷バランシングスキームとは異なり、本発明による負荷バランシングの実施形態は、トラフィック負荷値に基づいて決定する。よって、本発明の実施形態は、例えば全リーフノード及び全スーパーピアが同数のクエリ及びルーティングを開始するか、又は取り扱わなければならないかなり理論的な事例において、リーフノードのスーパーピアへの均等な分散をもたらすことができる。しかし、現実のネットワーク環境では、これは通常は事実とは異なるので、本発明の実施形態は、通常、リーフノードの数が各スーパーピアへ均等に分散されているようなピアツーピアシステムをもたらさない。

以下に、本アプローチの質を測定するために行った一連のシミュレーションの結果を示す。シミュレータは、ソフトウェアパッケージＭａｔｈｅｍａｔｉｃａにおいて実施した。これはイベント駆動型シミュレータである。ネットワーク動作中に発生したイベントはグローバルに保持されているイベントキューに記録され、イベントハンドラがイベントの発生時刻に処理する。あらゆるイベントは、例えば単純なルーティングメッセージ、クエリ、リーフ参加などのようなタイプと、ターゲットすなわちイベントを取り扱うノードとを有する。イベント発生時刻は、ノード間のレイテンシーによって駆動される。例えばあるノードが、対象のノードのイベント処理の結果としてメッセージを近傍ノードへルーティングするとき、近傍ノードのための新しいイベントが発生する。このイベントの時刻は現在時刻と２つのノード間のレイテンシーとの合計に等しい。

典型的なシミュレーションの実行は、初期化フェーズとクエリフェーズとの２つのフェーズからなる。初期化フェーズではＣｈｏｒｄ型ネットワークが（リーフ無しで）セットアップされ、クエリフェーズにおいてクエリされる複数のキーが挿入される。キー長（key length）は、シミュレーションを通して２０ビットに一定に保つ。ネットワークは完全には密集することがなく、すなわちピアの数は常に２²⁰よりずっと小さい。ピアのオーバーレイネットワーク識別子（ＩＤ）は２つの方法で発生させる。１つ目は、ＤＨＴにおいて通常と同じようにランダムに発生するという方法である。２つ目は、均等に拡散させ、すなわちネットワーク内にＮ個のピアがあると仮定すると、第ｋ番目のピアのＩＤはｋ／Ｎ＊２²⁰に最も近い整数であるという方法である。Ｃｈｏｒｄ型ネットワーク内のルーティングテーブルは２つの方法で構築できる。第一に、ｋというＩＤを有するノードのルーティングテーブル内の第ｉ番目のエントリーは、ｋ＋２ⁱに最も近いＩＤを有するノードを指し示す。第二に、第ｉ番目のエントリーは、区間（ｋ＋２ⁱ，ｋ＋２ⁱ⁺¹）内でランダムに選択されたノードを指し示す。

ネットワークを構築するために第二のストラテジーを選ぶ。その理由は、ルーティングテーブルに格納されるノードがより明確に区別でき、このことが提案された負荷バランシングアルゴリズムの質に影響を与えるからである。

クエリフェーズは、リーフノードの参加と、種々のノードからのクエリという、交互に行われる２つのサブフェーズからなる。リーフの到着はある特定のレートのポアソン過程として生じる。いかなる到着時においても、ネットワークへ参加するピアは、その時点での一連の全てのオフラインのリーフからランダムに選択される。リーフオンライン時間（ピアがネットワークに参加してから離脱するまでの時間）は、［５，１０］分間という区間からランダムに導かれる。クエリ回数は、この場合も選択されたレートを有するポアソン過程としてノード毎に別々に生じる。よって、あらゆるリーフは、自己のクエリ回数及び自己のオンライン時間によって特徴付けられている。クエリされるキーは、ネットワークに記憶されている一連の全てのキーからランダムかつ一様に引き出される。これは、歪んだクエリ分散がシミュレーションでは考慮されなかったことを意味する。リーフに対し、クエリレートは、あるシミュレーションセットでは区間［１／６０，１／２０］（毎分１回から３回のクエリ）の間で一様に分散し、別のシミュレーションセットでは［１／１２０，１／８０］の間で一様に分散している。

ノードの負荷を保持するために、送信メッセージのリストがノード毎に保持される。ノードがメッセージを送信したときは常に、メッセージが送信された時刻がノードのトラフィックリストに付け加えられる。如何なる時点の如何なるノードの負荷も、時間によって分割されたこのノードのトラフィックリストの長さとして取得される。このように、負荷の測定を正確に維持することができる。品質の尺度として、ピア全体にわたる負荷の標準偏差を測定する。具体的には、絶対尺度で扱うために、負荷は最大負荷で正規化する。よって、区間［０，１］において正規化された一連の負荷が得られる。

図４は、スーパーピアキーがランダムに選択され、リーフノードの異なる２つのクエリレートを用いる上述のアルゴリズムと、（リーフノードをスーパーピアへランダムにアタッチさせる）というアルゴリズムの適用なしの３通りの場合の、リーフノード参加の総数（ｘ軸）に対する負荷の標準偏差のグラフである。スーパーピアの数は１０００個で一定である。このようにして、スーパーピアに対するリーフノードの比についての負荷バランシングの質の依存も測定した。より正確には、図４は、リーフノードの十分に大きなプールから５０００個の参加（ｘ軸）が順次発生し、これらの参加の２５％、５０％、７５％及び１００％が実行された後の負荷の標準偏差（ｙ軸）を測定するというシナリオの結果を示している。グラフ４１０は区間［１／１２０，１／８０］内のクエリレートに対する標準偏差の変化を示し、グラフ４２０は区間［１／６０，１／２０］内のクエリレートに対するスーパーピアトラフィック負荷値の標準偏差の変化を示し、プロット４３０は、提案されたアルゴリズムの性能のベンチマークとして、アルゴリズムを用いない場合のスーパーピアの低トラフィック値に対する標準偏差の変化を示している。偏差は、スーパーピアの総数が与えられた場合に、リーフノードの集団の大きさの減少関数であり、リーフノードの数が多くなるほど、負荷をより良好にバランシングできることは明らかである。

図５は、スーパーピアキーの一様な分散が仮定されているという点のみが異なり他は同じセッティングにおける結果を示している。

図４及び図５の結果は、ノードが自己のフィンガーすなわち自己の近傍の負荷を瞬時に監視できる場合に成り立つ。しかし、これは現実的ではない。その理由は、ノードが自己のフィンガーの負荷について知ることができる唯一の方法は、この情報を自己のフィンガーと定期的に交換することであるからである。

図６は、この周期の長さすなわちフィックスフィンガー周期長（秒単位）に標準偏差がどのように依存するかを示している。フィックスフィンガー周期は０から２００秒まで変化している（ｘ軸）。スーパーピアの数は１０００個である。５０００個の参加がシステム内で観察された後に結果を得た。グラフは、標準偏差がフィックスフィンガー周期の増加と共に僅かに増加することを明らかに示している。

以上の説明をまとめると、ピアツーピア（Ｐ２Ｐ）ネットワークは、一連のリソースを高速に見つけることができる自己組織性の分散型オーバーレイネットワークである。ピアツーピアネットワークは、どのようなものであっても参加しているノード間の物理的な接続性に依存するアプリケーション層オーバーレイネットワークとして実現される。Ｐ２Ｐネットワークによって対処できる基本的な問題は、自己の後続の高速ルックアップを可能にするピアの集合の間での一連のリソースの自己組織型分散である。

この問題を解決する有望なアプローチは、分散型ハッシュテーブル（ＤＨＴ）としても知られている構造型Ｐ２Ｐネットワークの概念である。ＤＨＴでは、ピアは、キー空間からのキーにより特定される特定のリソースの部分集合を協働して管理する。これは以下の方法で行われる。各ピアはキー空間から取得されたキーと関連付けられる。ピアの集合が与えられると、ピアが関連付けられたパーティションのキーによって特定される全リソースを管理するように、各ピアのキーがキー空間のパーティションと関連付けられる。典型的には、キーパーティションは、適切なメトリックにおいてピアキーに最も近い全てのキーからなる。キーの近さは距離関数によって測定される。リソース要求を転送するため、ピアは、ピアとキーパーティションとの関連性についての情報を考慮して、ルーティングネットワークを形成する。ピアは、典型的には、近傍キーを有する全ピアへの短距離リンクと、さらに、一部の選択された遠いピアまでの少数の長距離リンクとを維持している。このようにして確立されたルーティングネットワークを使用して、ピアは、ルックアップするキーまでの距離を徹底的に削減しようとして、指示された通りに自己のルーティングテーブルにある他のピアへリソース要求を転送する。ＤＨＴの大半は、この構成及びルーティングアルゴリズムによって、ネットワークのサイズの対数（logarithmic）であるルーティングテーブルを使用することにより、ネットワークのサイズの対数である複数のメッセージのルックアップを達成する。

対象のピアツーピアアーキテクチャは、参加しているピアを２つのグループに分ける。１つは、分散型ハッシュテーブル（ＤＨＴ）に編成されて第２のグループへのプロキシとしての役割を果たすスーパーピアである。もう１つは、スーパーピアへアタッチされてＤＨＴに参加しないリーフノードである。

システムアーキテクチャを説明した後に、本発明の実施形態によって解決された問題を説明した。あらゆるスーパーピアが、ネットワーク動作によって発生したトラフィックのうちのおおよそ均一な部分を占めるようにするために、スーパーピアの間の負荷はどのように分散されるか？このことがとにかく重要である理由について最初に詳しく説明した。このことが重要である理由は、不均衡な負荷により過負荷状態のピアが故障する可能性があるからである。当然ながら、これにより保守及び障害回復のアルゴリズムを実行する必要があるので、システムに新たなオーバーヘッドを取り込む。最も極端なシナリオでは、ピア障害は累積的な影響を及ぼすことがあるので、システム全体が崩壊する。負荷が非常に歪む可能性があるので、負荷を平坦化させるために独立したアルゴリズムが必要であるという意味で、関連する問題があるか？通常、ピアキーは、ピア起動フェーズでキー空間からランダムに選択される。システム内に存在するドキュメントにインデックスを付けるために同じキー空間が使用され、ドキュメントの数はピアの数よりはるかに多いので、システムサイズは常にキー空間サイズより小さい。したがって、キー空間はピアの間でパーティショニングされなければならない。これらの区分のサイズは実質的に異なることがわかる。より大きなパーティションを対象とするピアは、他のピアのフィンガーである可能性がより高い。よって、より大きなパーティションを対象とするピアは、メッセージをルーティングするより高い確率を有する。したがって、負荷分散の歪みと、システム動作フェーズにおいてこの歪みを取り除くために別のアルゴリズムを利用する必要がある。

一般に、本発明は、どのようなピアツーピア通信システムにおいても役に立つ。このことは、特にモバイルピアツーピアアプリケーションにおいて通常期待されているように、性能が非常に異なるデバイスからできているハイブリッドシステムについて成り立つ。

上述したように階層型ピアツーピアシステムは、モバイルピアツーピア環境に特に適している。したがって、本発明の実施形態は、特にモバイルピアツーピア環境における負荷バランシングを改善することができる。

上述した実施形態はＤＨＴシステムのようなＣｈｏｒｄ型システムを使用しているが、その他のいかなる構造のピアツーピアプロトコルも同じ利点を達成するために使用することができる。

本発明の実施形態は、より安定していてかつより低コストのネットワーク動作をもたらすだけでなく、より高い障害回復力が得られる。よって、本発明の実施形態は、全体としてネットワークに強力な経済的効果がある。

さらに、本発明に係る方法のある実施要件に依存して、本発明に係る方法は、ハードウェアでもソフトウェアでも実施できる。デジタル記憶媒体、特に電子的に読み取り可能な制御信号が記憶されていて、本発明に係る方法が実行できるようにプログラマブルコンピュータシステムと協働できるディスク又はＣＤを使用して実施できる。したがって、一般には、本発明は、本発明に係る方法のうちの少なくとも１つをコンピュータに実行させるために構成されたプログラムコードが機械読み取り可能な担体に記憶されている、コンピュータプログラムプロダクトである。したがって、換言すると、本発明に係る方法は、本発明に係る方法をコンピュータに実行させるプログラムコードを有するコンピュータプログラムである。

階層型ピアツーピアシステムにおいてノードバランシングをサポートすることができる、本発明に係るスーパーピアの実施形態のブロック図である。 階層型ピアツーピアシステムにおける負荷バランシング方法の好ましい実施形態を擬似コードの形式で示す説明図である。 階層型ピアツーピアシステムにおいて負荷バランシングをサポートすることができるスーパーピアを動作させる方法の好ましい実施形態のフローチャートである。 スーパーピアがＣｈｏｒｄ型リングを形成する、典型的な階層型分散ハッシュテーブルシステムを示す説明図である。 スーパーピアがＣｈｏｒｄ型リングを形成する、典型的な階層型分散ハッシュテーブルシステムを示す説明図である。 スーパーピアキーがランダムに選択されたものであるときに、リーフノード参加の総数に対するトラフィック負荷の標準偏差の依存関係を示すグラフである。 スーパーピアキーが均等に拡散しているときに、リーフノード参加の総数に対するトラフィック負荷の標準偏差の依存関係を示すグラフである。 フィックスフィンガー周期長に対するトラフィック負荷の標準偏差の依存関係を示すグラフである。 ピアツーピアオーバーレイネットワークの典型的な階層構造と下層物理ネットワークを示す説明図である。 割当毎のスーパーピアと同数のリーフノードとを有し、各ノードが各スーパーピアへアタッチされている、階層型ピアツーピアシステムを示す説明図である。

符号の説明

１００ スーパーピア
１１０ 受信機
１１２ アタッチ要求メッセージ
１１６ 他のメッセージ
１２０ 送信機
１２２ 転送アタッチ確認メッセージ
１２４ アタッチ確認メッセージ
１３０ 処理ユニット
１３１ 制御
１３２ 移動アタッチ要求メッセージ
１４０ 記憶ユニット

Claims (11)

1. １つ又は複数の他のスーパーピア（Ｓ０、Ｓ１、Ｓ３、Ｓ４、Ｓ５、Ｓ６、Ｓ７）を含む階層型オーバーレイピアツーピアネットワーク（Ｎ１）に参加するためのものであって、リーフノードオーバーレイリンク（Ｎ２）を通して前記スーパーピア（Ｓ０−Ｓ７）のうちのいずれかへリーフノード（ＬＮ）をアタッチさせることができるスーパーピア（１００、Ｓ２）であって、
   前記リーフノード（ＬＮ）が前記階層型ピアツーピアネットワーク（Ｎ１）へのアタッチを要求していることを表すアタッチ要求メッセージ（１１２）を受信する受信機（１１０）と、
   前記リーフノード（ＬＮ）が前記スーパーピア（１００）へアタッチされることを表すアタッチ確認メッセージ（１２４）を送信する送信機（１２０）と、
   前記アタッチ要求メッセージ（１１２）を受信したという通知（１１４）を前記受信機から受けて、前記スーパーピア（１００、Ｓ２）のトラフィック負荷を表すトラフィック負荷値を、１つ又は複数の前記他のスーパーピア（Ｓ０、Ｓ１、Ｓ３、Ｓ４）のうちの少なくとも１つに関連付けられていてそのトラフィック負荷を表すトラフィック負荷値と比較し、前記スーパーピアのトラフィック負荷が前記他のスーパーピアのトラフィック負荷より小さいか、又は複数の前記他のスーパーピアのトラフィック負荷より小さいことが前記比較により判明した場合は、前記リーフノードが前記スーパーピア（１００）とのリーフノードオーバーレイリンクを通して前記階層型ピアツーピアネットワークへアタッチされることを通知するために、前記送信機を制御（１３１）して前記アタッチ確認メッセージ（１２４）を送信させる処理ユニット（１３０）と
   を備えるスーパーピア（１００、Ｓ２）。
2. 前記スーパーピア（１００、Ｓ２）のトラフィック負荷が前記他のスーパーピアのトラフィック負荷より大きいか、又は複数の前記他のスーパーピアのトラフィック負荷の最小値より大きいことが前記比較により判明した場合は、前記処理ユニット（１３０）が、前記他のスーパーピア又は複数の前記他のスーパーピア（Ｓ０、Ｓ１、Ｓ３、Ｓ４）のうちの１つへ転送アタッチ要求メッセージ（１２２）を送信させるために前記送信機（１２０）を制御（１３１）するものである、請求項１に記載のスーパーピア。
3. 前記スーパーピア（１００、Ｓ２）のトラフィック負荷が前記他のスーパーピアのトラフィック負荷より大きいか、又は複数の前記他のスーパーピアのトラフィック負荷の最小値より大きいことが前記比較により判明した場合は、前記処理ユニット（１３０）が、前記他のスーパーピア又は複数の前記他のスーパーピアのうち最小負荷トラフィック値（λ_min）が関連付けられているスーパーピア（Ｓ３）へ前記転送アタッチ要求メッセージ（１２２）を送信させるために前記送信機（１２０）を制御（１３１）するものである、請求項１又は２に記載のスーパーピア。
4. 前記処理ユニット（１３０）が、
   前記通知（１１４）を受けて、前記アタッチ要求メッセージ（１１２）に関連付けられている転送カウント（ＣＦＣ）をチェックして、
   前記転送カウント（ＣＦＣ）がある最大転送カウント（ＣＦＣ_max）に等しいことが前記チェックにより判明した場合、又は前記スーパーピアのトラフィック負荷が前記他のスーパーピアのトラフィック負荷より小さいか、若しくは複数の前記他のスーパーピア（Ｓ０、Ｓ１、Ｓ３、Ｓ４）のトラフィック負荷より小さいことが前記比較により判明した場合は、前記送信機（１２０）を制御（１３１）して前記アタッチ確認メッセージ（１２４）を送信させ、
   さもなければ、前記送信機（１２０）が送信する前記転送アタッチ要求メッセージ（１２２）を得るために、前記アタッチ要求メッセージに関連付けられている前記転送カウント（ＣＦＣ）をインクリメントするものである、
   請求項２に記載のスーパーピア。
5. １つ又は複数の前記他のスーパーピア（Ｓ０、Ｓ１、Ｓ３、Ｓ４）のうちの少なくとも１つのためのユニークなオーバーレイネットワーク識別子と、ＩＰアドレスと、トラフィック負荷値とを有するルーティングテーブルを記憶する記憶ユニット（１４０）をさらに備え、
   ここで前記処理ユニット（１３０）が、トラフィック負荷値の前記比較と前記転送アタッチ要求メッセージ（１２２）の送信の制御とのために前記ルーティングテーブルを使用するものである、請求項２〜４のいずれか一項に記載のスーパーピア。
6. 前記処理ユニット（１３０）が、前記スーパーピア（１００）のトラフィック負荷を測定し、前記スーパーピア（１００）の前記トラフィック負荷値をあるトラフィック負荷スレショルドと比較し、前記スーパーピア（１００）へ現在アタッチされているリーフノードが複数の前記他のスーパーピアのうちのあるスーパーピアへとアタッチされるように前記リーフノードのアタッチの移動を開始するために、前記他のスーパーピア又は複数の前記他のスーパーピア（Ｓ０、Ｓ１、Ｓ３、Ｓ４）のうち最小トラフィック負荷値（λ_min）が関連付けられているスーパーピアへ移動アタッチ要求メッセージ（１３２）を送信させるべく前記送信機（１２０）を制御するものである、請求項１〜５のいずれか一項に記載のスーパーピア。
7. 前記トラフィック負荷値が、測定された絶対トラフィック負荷値をあるスーパーピア特有の最大トラフィック負荷値で除算することにより得られる相対トラフィック負荷値である、請求項１〜６のいずれか一項に記載のスーパーピア。
8. 前記スーパーピアオーバーレイネットワーク（Ｎ１）が動的ハッシュテーブル（ＤＨＴ）オーバーレイネットワークである、請求項１〜７のいずれか一項に記載のスーパーピア。
9. 前記スーパーピアオーバーレイネットワーク（Ｎ１）が動的ハッシュテーブルＣｈｏｒｄ型オーバーレイネットワークである、請求項１〜８のいずれか一項に記載のスーパーピア。
10. １つ又は複数の他のスーパーピア（Ｓ０、Ｓ１、Ｓ３、Ｓ４、Ｓ５、Ｓ６、Ｓ７）を含む階層型オーバーレイピアツーピアネットワーク（Ｎ１）に参加するためのものであって、リーフノードオーバーレイリンク（Ｎ２）を通して前記スーパーピア（Ｓ０−Ｓ７）のうちのいずれかへリーフノード（ＬＮ）をアタッチさせることができるスーパーピア（１００、Ｓ２）を動作させる方法であって、
    前記リーフノード（ＬＮ）が前記階層型ピアツーピアネットワーク（Ｎ１）へのアタッチを要求していることを表すアタッチ要求メッセージ（１１２）を受信するステップと、
    前記スーパーピア（１００、Ｓ２）のトラフィック負荷値を、１つ又は複数の前記他のスーパーピア（Ｓ０、Ｓ１、Ｓ３、Ｓ４）のうちの少なくとも１つに関連付けられていてそのトラフィック負荷を表すトラフィック負荷値と比較するステップと、
    前記スーパーピアのトラフィック負荷が前記他のスーパーピアのトラフィック負荷より小さいか、又は複数の前記他のスーパーピア（Ｓ０、Ｓ１、Ｓ３、Ｓ４）のトラフィック負荷より小さいことが前記比較により判明した場合は、前記リーフノードが前記スーパーピア（１００）とのリーフノードオーバーレイリンク（Ｎ２）を通して前記階層型ピアツーピアネットワークへアタッチされることを通知するために、アタッチ確認メッセージ（１２４）を送信するステップと
    を含む方法。
11. 請求項１０に記載の方法をコンピュータに実行させるプログラムコードを有するコンピュータプログラム。

Images