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

階層的ピアツーピア・ネットワークの最適運用 Download PDF

Info

Publication number
JP4652435B2
JP4652435B2 JP2008217608A JP2008217608A JP4652435B2 JP 4652435 B2 JP4652435 B2 JP 4652435B2 JP 2008217608 A JP2008217608 A JP 2008217608A JP 2008217608 A JP2008217608 A JP 2008217608A JP 4652435 B2 JP4652435 B2 JP 4652435B2
Authority
JP
Japan
Prior art keywords
peer
superpeer
network
superpeers
entity
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
JP2008217608A
Other languages
English (en)
Other versions
JP2009089369A (ja
Inventor
ゾラン・デスポトヴィッチ
ヴォルフガンク・ケレラー
シュテファン・ツェルス
キラン・ホフシュテッター
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
NTT Docomo Inc
Original Assignee
NTT Docomo Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by NTT Docomo Inc filed Critical NTT Docomo Inc
Publication of JP2009089369A publication Critical patent/JP2009089369A/ja
Application granted granted Critical
Publication of JP4652435B2 publication Critical patent/JP4652435B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/10Protocols in which an application is distributed across nodes in the network
    • H04L67/104Peer-to-peer [P2P] networks
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/10Protocols in which an application is distributed across nodes in the network
    • H04L67/1001Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/1004Server selection for load balancing
    • H04L67/1023Server selection for load balancing based on a hash applied to IP addresses or costs
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/10Protocols in which an application is distributed across nodes in the network
    • H04L67/104Peer-to-peer [P2P] networks
    • H04L67/1044Group management mechanisms 
    • H04L67/1048Departure or maintenance mechanisms
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/10Protocols in which an application is distributed across nodes in the network
    • H04L67/104Peer-to-peer [P2P] networks
    • H04L67/1044Group management mechanisms 
    • H04L67/1051Group master selection mechanisms
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/10Protocols in which an application is distributed across nodes in the network
    • H04L67/104Peer-to-peer [P2P] networks
    • H04L67/1061Peer-to-peer [P2P] networks using node-based peer discovery mechanisms
    • H04L67/1065Discovery involving distributed pre-established resource-based relationships among peers, e.g. based on distributed hash tables [DHT] 
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/10Protocols in which an application is distributed across nodes in the network
    • H04L67/1001Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Physics & Mathematics (AREA)
  • Computing Systems (AREA)
  • Mathematical Physics (AREA)
  • Theoretical Computer Science (AREA)
  • Computer And Data Communications (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Description

本発明は、階層的ピアツーピア・オーバーレイ・システムに関し、より詳細には、リーフノードに対するスーパーピアの比に関して、そのようなシステムの最適な運用点を決定する手法に関する。
オーバーレイ・ネットワークは、下層にある他の物理ネットワークの上に築かれるネットワークである。オーバーレイの中にあるノードは、下層ネットワークの1つ又は多数の物理リンクを備える仮想又は論理リンクによって接続されると考えることができ、各々の仮想又は論理リンクはパスに対応する。一例を挙げれば、多くのピアツーピア・ネットワークは、インターネットにおいて実行されるため、オーバーレイ・ネットワークであるといえる。ダイアルアップ・インターネットは、電話網の上にあるオーバーレイの例である。オーバーレイ・ネットワークは、通常のルーティングプロトコル、例えば、IP(インターネット・プロトコル)ルーティングによってサポートされないようなアプリケーション・レベルのコンセプト、例えば、ファイル又はデータを任意のタイプとしたときにルックアップできるようにするために構築され得る。
ピアツーピア(P2P)ネットワークは、比較的少数のサーバに集結するのではなく、ネットワークにおいて、ピア又はピア・ノードと呼ばれる参加者の計算機能力及び帯域幅に主として依存するネットワークである。このようにして、ピアツーピア・ネットワークは、クライアント又はサーバの概念を有さず、ネットワーク上の他のノード又はピアに対して「クライアント」及び「サーバ」の双方として同時に機能する同等ピア・ノードの概念のみを有する。ピアツーピア・ネットワークは、典型的には、例えば、ディジタル形式のオーディオ、ビデオ、データなどを含むコンテンツ・ファイルを共有するため、又はリアルタイム・データ、例えば、電話トラフィックを伝送するために使用される。ピアツーピア・ネットワークの重要な目的は、全てのクライアントが、帯域幅、記憶空間、及び計算機能力を含むリソースを提供することである。このようにして、多くのノードが用いられシステム上の要望が増すにつれて、システムの全容量も増加する。
前述したように、ピアツーピア・オーバーレイ・ネットワークは、オーバーレイ・ネットワーク・ノードとして参加中の全ピアからなり立っている。相互に知られている2つのノードの間には、オーバーレイ・リンクが存在する。即ち、参加中のピアが、ピアツーピア・ネットワークにおいて他のピアの場所を知っているならば、前者のノードから後者のノードへの有向辺がオーバーレイ・ネットワーク内に存在する。オーバーレイ・ネットワーク内のノードが、互いに対してどのようにリンクされるかに基づいて、ピアツーピア・ネットワークは、非構造化又は構造化として分類される。
非構造化ピアツーピア・ネットワークは、オーバーレイ・リンクが恣意的に確立されるときに形成される。そのようなネットワークは容易に構成され得る。なぜなら、ネットワークに加入したい新しいピアは、他のノードの現存するリンクを複写し、時間の経過と共にそれ自体のリンクを形成できるからである。非構造化ピアツーピア・ネットワークにおいて、ピアがネットワークにおいて所望のコンテンツを発見したいならば、コンテンツを共有するピアをできるだけ多く発見するために、ネットワーク中がリクエストであふれているようにしなければならない。そのようなネットワークの主な欠点は、クエリーのアドレス解決(resolve)が必ずしも実行可能とは限らないことである。人気のあるコンテンツは、いくつかのピアにおいて入手できる可能性があり、そのようなコンテンツを探索しているピアは、それを発見する可能性があるが、ピアが、少数の他のピアのみによって共有される稀少又はそれほど人気のないコンテンツを探しているならば、探索が成功することはめったに起こらない。ピアと、ピアによって管理されるコンテンツとの間に相関が存在しないので、あふれさせたとしても所望のデータを有するピアが発見できるという保証はない。その上、あふれさせることによって、ネットワーク内に大量の信号トラフィックが更に発生し、従って、そのようなネットワークの探索効率が非常に悪くなる。
構造化ピアツーピア・ネットワークは、分散ハッシュ・テーブル(DHT)を保守することによって、及び、各々のピアがネットワーク内のコンテンツの特定部分を担当することを許すことによって、非構造化ネットワークの制限を克服する。これらのネットワークはハッシュ関数を使用して、値、即ち、ハッシュ値を、ネットワーク内の全コンテンツ及び全ピアに割り当て、グローバルなプロトコルに従って、どのピアがどのコンテンツを担当するかを決定する。このようにして、ピアがあるデータを探索したいとき、常に、このピアはそのグローバルなプロトコルを使用して、データを担当するピアを決定し、担当するピアの方へ探索を向けることができる。ハッシュ値の用語は、特に、分散コンテンツを管理する文脈において鍵又は索引も指す。対応的に、鍵空間の用語は、可能な鍵の全集合を定義するために使用される。いくつかの公知の構造化ピア・ネットワークは、コード(Chord)、ペストリ(Pastry)、タペストリ(Tapestry)、キャン(CAN)、及びチューリップ(Tulip)を含む。
ハッシュ関数又はハッシュ・アルゴリズムは、データ、典型的には、ドキュメント、すなわち一般にはファイルを、コンピュータ又は他のデバイスによって処理されるのに適した値へ転換する再現可能な方法である。これらの機能は、任意の種類のデータから小さなディジタル「指紋」を作成する方法を提供する。ハッシュ値は、結果として生じる「指紋」である。前述したハッシュ・テーブルは、ハッシュ関数の大きな応用であり、ハッシュ値を与えられたデータ・レコードの高速ルックアップ又は探索を可能にする。
160ビット・ストリングの集合の周りに築かれた分散ハッシュ・テーブルといった抽象鍵空間を例として考えると、鍵空間の所有権は鍵空間区画スキームに従って参加中のノードの間で分割されてオーバーレイ・ネットワークがノードを接続するので、これらのノードが鍵空間における所与の鍵の所有者を発見することができるようになる。一度、これらの要素が整えられると、記憶及び検索のための分散ハッシュ・テーブルの典型的使用は、次のように進行する。所与のファイル名f1を有するファイルを分散ハッシュ・テーブルの中に記憶するため、f1のハッシュ値が決定され、160ビットの鍵k1が生成される。その後で、メッセージput(k1,d1)が、分散ハッシュ・テーブルに参加しているノードへ送られる。d1は物理アドレス、例えば、ファイル所有者のIPアドレスである。メッセージはオーバーレイ・ネットワークを通してノードからノードへと回送され、この回送は、ペア(k1,d1)が記憶されている鍵空間区画によって指定されたように、鍵k1を担当する単一のノードに到達するまで続く。次に、他のクライアントは、ファイル名f1を再びハッシュして鍵k1を生成し、例えば、メッセージget(k1)を用いて、k1に関連付けられたデータを発見するように分散ハッシュ・テーブル・ノードに求めることによって、ファイルのコンテンツを検索することができる。メッセージは、再び、オーバーレイ・ネットワークを通して鍵k1を担当するノードへルーティングされ、このノードは記憶されたデータd1によって返答する。データd1自体は、getメッセージと同じ経路を使用してルーティングされ得るが、典型的には、下層の物理ネットワークが提供するような異なった物理経路に基づいて、異なった経路を使用して伝送される。
上記の動作を可能にするため、分散ハッシュ・テーブルは距離関数d(k1,k2)を採用する。この距離関数は、鍵k1から鍵k2までの距離の抽象概念を定義する。各ノードには単一の鍵が割り当てられる。この鍵は、ルーティングの文脈では、オーバーレイ・ネットワーク識別子とも呼ばれる。識別子iを有するノードは、iが、距離関数dに従って測定されたとき最も近い識別子である全ての鍵を所有する。言い換えれば、識別子iを有するノードは、iが、d(i,k)に従って測定されたときの最も近い識別子である鍵kを有する全てのレコード又はドキュメントを担当する。
コードDHTは、特に首尾一貫した(consistent)分散ハッシュ・テーブルである。このテーブルは鍵を円の上の点として扱い、d(k1,k2)はk1からk2まで円の周りを時計回りに移動する距離である。このようにして、円形の鍵空間は連なっている切片へ分けられ、切片の端点がノード識別子にされる。i1及びi2が2つの隣接したノード識別子であれば、識別子i2を有するノードは、i1とi2との間に含まれる全ての鍵を所有する。
各々のピアは他のピアへのリンクの集合を保守し、これらは一緒になってオーバーレイ・ネットワークを形成し、ネットワーク・トポロジと呼ばれる構造化された態様になるように選定される。リンクは、遠隔ピアの小さな集合に向けて、及び多数の最も近いピアへ確立される。距離関数を参照。全ての分散ハッシュ・テーブル・トポロジは、最も本質的な性質のいくつかの変形を共有する。即ち、任意の鍵kについて、ノードはkを所有するか、上記で定義された鍵空間距離に関してkへ近いピアへのリンクを有する。従って、次の欲張りアルゴリズムを使用して、鍵kの所有者へメッセージをルーティングすることは容易である。即ち、各々のステップで、kに最も近い識別子を有する近隣ノードへメッセージを回送する。そのような近隣ノードが存在しないとき、現在のノードは最も近いノードでなければならない。最も近いノードは、上記で定義されたようなkの所有者である。この型のルーティングは、時には鍵ベースルーティングとも呼ばれる。
図6は、下層の物理ネットワーク710、下層の物理ネットワーク710の上にあるピアツーピア・ネットワークの仮想又は論理オーバーレイ・ネットワーク720、及びオーバーレイ・ネットワーク720のノード又はピアによって管理される鍵空間730を有するピアツーピア・オーバーレイ・ネットワークの層構造を示す。注意すべきこととして、例えば、前述したコード・リングDHTシステムの場合、鍵空間730の鍵区画は時計回りでピアへ割り当てられるが、これは後で説明されるように、ルーティングを目的として、オーバーレイ・ネットワーク自体が、各々のノードのために2つのオーバーレイ・リンク、即ち、コード・リング構造に従って、直接に先行する近隣ノード及び直接に後続する近隣ノードへの2つのリンクだけを備えることを意味しない。
通常、鍵は、ピアのIPアドレス及び無作為に選ばれた文字列をハッシュ値へハッシュすることによって、ピアへ割り当てられる。ハッシュ関数を使用してソース鍵をピアへマップする副次的な目的は、負荷配分を平衡させることである。即ち、各ピアは、近似的に同数の鍵を担当するべきである。
要するに、DHTの具体的設計は、鍵空間、距離関数、鍵区画、及びリンク戦略の選択に依存する。しかしながら、ルーティングの効率に関連した良好な性質は、無料では実現されない。DHTを構造化及び保守するため、ピアは特にノードの加入と故障の問題を処置しなければならない。構造化P2Pネットワークにおいて近隣ノードを選ぶ自由は制限されるので、ネットワークに動的な性質を残しつつルーティングテーブルの首尾一貫性を再確立するためには、保守アルゴリズムが必要である。ネットワークによって与えられる保証の型に依存して、異なる決定論的及び確率論的保守戦略が開発された。保守行動は、様々な事象、例えば、ノードの定期的加入及び離脱、又は首尾一貫しないルーティングテーブルに起因するルーティングの失敗によってトリガされ得る。異なる保守戦略は、保守コストと、首尾一貫性の程度、従ってネットワークの失敗回復力とのトレードオフである。
しかしながら、現在のDHTソリューションは、標的環境としての固定インターネットにのみ焦点を当て、モバイル・コンピューティング環境には適切でない。それらのソリューションでは、モバイル機器の主な制限、例えば、モバイル機器の低いコンピューティング及び通信能力又は高い通信コストが考慮されず、セルラ又はモバイル・アドホック・ネットワークの他の細目も考慮されない。この問題は、参加中のピアが2つのグループへ分割されるDHTアーキテクチャを提供することによって対処され得る。図7を参照すると、強力なデバイスはスーパーピアU〜Uとして分類され、弱いデバイス、例えば、携帯電話はリーフノードL〜Lと呼ばれる。図7に従った分散ハッシュ・テーブルにおいて、スーパーピアは、I.Stoica,R.Morris,D.Karger,M.Kaashoek,and H.Balakrishnan, “Chord:A Scalable Peer−to−Peer Lookup Service for Internet Applications”, ACM SIGCOMM Conference,2001で説明されるようなコード・リングに組織され、リーフノードへのプロキシとして役立つ。リーフノードはプロキシに付加され、リングに参加しない。
下記では、図7に基づいて、階層的ピアツーピア・オーバーレイ・ネットワークが詳細に説明される。前述したように、図7に従った階層システム・アーキテクチャは、ピアの2つの異なる級又は階層レベル、即ち、スーパーピア及びリーフノードを定義する。スーパーピアは、図7に示されるように、コード・リング形式によって構造化DHTベース・オーバーレイを確立する。その場合、各々のスーパーピアは、更にそのリーフノードのためにプロキシとして働く。即ち、リーフノードは、そのスーパーピアを経由してのみピアツーピア・ネットワークにおいて通信し、例えば、ピアツーピア・オーバーレイ・ネットワークにおいてドキュメントをクエリーする。このようにして、リーフノードは、そのスーパーピアへのオーバーレイ接続のみを保守する。そのスーパーピアの故障を認識すること及びそれに対応することができるように、リーフノードは簡単なPING−PONGアルゴリズムを定期的に実行する。更に、リーフノードはシステム内の他の利用可能なスーパーピアを含むリストを記憶し、スーパーピアの故障の後でオーバーレイ・ネットワークに再加入することができる。
対照的に、スーパーピアは、複数の他のタスクを遂行する。1つの例示的実現において、ネットワークに加入しているリーフノードは、それが共有するオブジェクトへのポインタのリストを、その対応スーパーピアへ転送する。次に、スーパーピアはこれらの参照をオーバーレイ・ネットワークの中へ挿入し、それら参照の所有者として行動する。リーフノードがルックアップ、例えば、オブジェクトへのクエリーを遂行するとき、リーフノードが接続されるスーパーピアは、コード・オーバーレイの探索機能を使用することによってそのルックアップに関するアドレス解決を実行し、オブジェクトの鍵に基づいて担当のスーパーピアを決定し、結果をリーフノードへ回送する。異なる実現において、探索されるオブジェクト又はドキュメントを担当するスーパーピアは、要求されたドキュメントを、ドキュメントを要求したリーフノードへ直接伝送することによって応答し、リーフノードのために行動しているスーパーピアへ応答を提供しない。
追加的に、スーパーピアは従来のコード・リングを確立するので、それらのスーパーピアはコード保守アルゴリズムを定期的に実行し、それらスーパーピアが保守する全ての参照を定期的に新しくして、それらの参照を最新に保つ。
今後は[1]として参照されるZoels S.,Despotovic z.,Kellerer W.,Cost−Based Analysis of Hierarchical DHT Design,Sixth IEEE International Conference on P2P Computing,Cambridge,UK,2006において、そのような階層システムが従来の平坦DHT組織よりも勝っている次の2つの明確な利点が説明された。
第一に、保守トラフィックが実質的に低減される。このトラフィックは、前述したように、ノードがシステムに加入及び離脱するとき、ルーティングテーブルを首尾一貫性があるように保つために必要である。[1]で説明されるアーキテクチャにおいて、リーフノードがシステムから離脱するとき、ほとんど保守トラフィックは必要でない。同時に、コード・リング自体を保守するために必要なトラフィックも低減される。なぜなら、スーパーピアは、より高いオンライン時間を有するノードから選択されるためである。
第二に、[1]で説明されるように、ネットワークの全運用コストが低減される。なぜなら、通信のコストが大きいノード又はピアが少ないトラフィックを遂行するためである。
[1]において、コスト・モデルは、水平階層分散ハッシュ・テーブル(HDHT)の最適性のみを判断するために導入された(平坦DHTは、特殊な場合として、モデルに含められる)。最適HDHT構成は、[1]において、オーバーレイ・ネットワークにおいて生成された全トラフィック(「コスト」と呼ばれる)及びピアの個々の負荷の関数として定義される。更に具体的には、システムにおいて生成された全てのメッセージが計算される。メッセージの中には、クエリーに関連したトラフィック及び保守トラフィックが含まれ、スーパーピア割合α、即ち、ピアの総数Nによって割られた上部レベル・ピアの数Nspの関数として表される。スーパーピア割合αは、唯一の考慮されるパラメータである。
図8において、コスト曲線90は1つの例を示す。図8は、固定数のピアNを有する仮説シナリオに対応する。即ち、ピアの母集団は不変である。1つの極端な場合、スーパーピア割合α=1/Nであるとき、全ネットワーク・トラフィックを最小化する古典的クライアント・サーバ・システムが存在する。スーパーピアの割合αが増加するにつれて、ネットワーク・トラフィック、即ち、コスト曲線90も増加する。他の極端な場合、α=1であるとき(リーフは存在せず、全てのピアはスーパーピアである)、平坦DHTが存在する。この場合、全ネットワーク・トラフィックは最大である。
スーパーピアの割合αの最適値を決定するため、ピアの個々のコストが考慮される。本目的のため、全ての参加中のピアn(n=1,2,...,N)について負荷因子LFが定義される。ピアn(n=1,2,...,N)の負荷因子LFは、所与の時点におけるピアn(n=1,2,...,N)のコストC(n=1,2,...,N)と、ピアn(n=1,2,...,N)が受け入れようとしている最大コスト値(コスト限度)C maxとの間の比、即ち、LF=C/C max(n=1,2,...,N)である。1つの例として、アップリンク帯域幅の消費を、考慮されるコストとして考えることができる。他の解釈、例えば、ディスク空間を考えることもできる。
最高負荷因子(HLF)と呼ばれる数量は、最適システム構成がどのように決定されるかについて、重要な役割を演じる。HLFは、全ての参加中のピアを横切って観察され得る最大負荷因子、即ち、HLF=max(LF)(n=1,2,...,N)として定義される。再び図8において、HLF曲線92は1つの例を示す。スーパーピアの割合αが大きくなるにつれて、HLFが小さくなる。背後に含まれる直感的理解はきわめて明瞭といえる。すなわち、スーパーピアになるピアが多くなるにつれて、それらのピアはシステム内の負荷を共有し、最も重い負荷がかけられるピアの負荷が小さくなる。これと反対に、スーパーピアの比αが所定値よりも小さくなると、100%を超えるHLFが観察可能となる。その結果、1つ又は複数のピアが過負荷になる。なぜなら、それらのピアは、受け入れ可能なコストよりも高いコストを担うためである。一般的に、100%よりも高いHLFは、システムの安定性を確保するために回避されるべきである。
図8のシナリオにおいて、システムは均質であり、N個の全ピアはC maxについて同じ値を設定するものと仮定される。この場合、ピア間の負荷が平衡されると仮定して、図8の最高負荷曲線92は任意のスーパーピアの負荷曲線である。システムが異質であるとき、HLFは、存在するスーパーピアの数だけでなく、どのピアがスーパーピアであるかに依存する。この場合、最高負荷曲線92は、図8に示されるように滑らかな形状ではなく、急激に増加することとなる。
システムの最適な運用点Aは、過負荷のピアが存在せず、同時に全ネットワーク・コストができるだけ低い点として定義される。即ち、全ネットワーク・コストは、システム内のピアを過負荷にすることなく最小化される。言い換えれば、この最適性規準は、ノード当たりの負荷は比較的に低いが全コストは高い完全非集中化システムと、ネットワークの運用部分は少ないがシステム・サーバは負荷の大部分を担う集中化システムとの間の、トレードオフを表す。
多くの階層DHTアーキテクチャが文献で提案されているが、階層P2Pネットワークを構築及び構成する問題を特に標的とする労作の大部分は、非構造化ネットワークを扱っている。B.Yang and H.Garcia−Molina, “Designing a Super−Peer Network,” in Proceedings of the 19th International Conference on Data Engineering (ICDE03),vol.1063,no.6382/03,2003は、スーパーピア・ベース非構造化P2Pネットワークの徹底的な研究を呈示する。
A.Montresor, “A robust protocol for building superpeer overlay topologies,” in Proceedings of the Fourth International Conference on Peer−to−Peer Computing,2004.,2004,pp.202−209も、非構造化P2Pネットワークに焦点を当てている。筆者の目的は、可能な最小数のスーパーピアを有するスーパーピア・ベースP2Pネットワークを構築することである。筆者は、ノードがゴシップ・プロトコルを介してそれらノードの容量に関する情報を他の無作為選択ノードと交換し、続いて、それらノードのリーフノードを、発見された最強スーパーピアの方へ押し出そうとするアルゴリズム(SG−1と呼ばれる)を提案する。この戦略は、最終的に、スーパーピアの最小集合へ導き、この最終集合は、ネットワーク内の残りのノードをリーフとしてカバーするのに十分である。
G.Jesi,A.Montresor,and O.Babaoglu, “Proximity−Aware Superpeer Overlay Topologies,” in Proceedings of the 2nd IEEE International Workshop on SelfMan,2006,pp.43−57で提案されるSG−2アルゴリズムは、リーフノードとスーパーピアとの間の潜時を最小にする近接認識スーパーピア・トポロジに焦点を当てている。往復時間(RTT)は直接に測定されるか、全てのノードを仮想空間内の位置に関連づける仮想座標サービスを介して近似される。スーパーピアはその利用可能性を仮想座標空間のそのエリア内において放送し、加入リーフノードがその近接内の最も強力なノードへ接続できるようにする。再び、ノードの容量は、特定のピアが処置できるリーフノードの最大数によって表され、これらのリーフノードはシミュレーションのために範囲[1;500]の中に均一に分布される。先駆者SG−1と同じく、アルゴリズムは追加のシグナリング・トラフィックを必要とするが、低いRTTを必要とする応用においては相当の利点をもたらす。
ピア間の区別が行われるが、ピア間に明白な階層分割を有さないP2Pアーキテクチャが、いくらか関連している。典型的には、それらのアーキテクチャは、ノード間の異質性を標的にする。背後にある理由としては、より強力なノード(又は、更に、システムへの参加から、より高い利用性を引き出すノード)は、より強力でないノードよりもオーバーレイ内において多くの働きを遂行すべきであるということである。
M.Castro,M.Costa,and A.Rowstron,“Debunking some myths about structured and unstructured overlays,” in NSDI’05,Boston,MA,USA,2005は、ノードの線度差をノード能力だけ偏向させることによって異質性に対処するA.Rowstron and P.Druschel, “Pastry:Scalable,distributed object location and routing for large−scale peer−to−peer systems,” in IFIP/ACM International Conference on Distributed Systems Platforms(Middleware),2001,pp.329−350の修正を呈示する。J.Sacha,J.Dowling,R.Cunningham,and R.Meier, “Discovery of stable peers in a self−organising peer−to−peer gradient topology,” in Proceedings of the 6th IFIP International Conference on Distributed Applications and Interoperable Systems,2006,pp.70−83は、最高利用度ピアをシステムの「コア」へ接続するため、いわゆる傾斜トポロジを提案する。ピアは、ゴシップを介して他のピアの利用度値Uに関する情報を獲得し、続いてそれに類似した値を有するノードを近隣ノードとして選択する。これは、トポロジの傾斜構造を導く。即ち、Uの低い値を有するピアは、コアから遠くに配置される。
[1]では、DHTシステムに対する全体的な観察を利用して、全てのシステム・パラメータ、例えば、ピアの数N、ピアの容量C、負荷、及び共有オブジェクトの数Fから最適な運用点Aをどのように計算するかが示された。しかしながら、実用的P2Pシステム環境において、システムの状況に対する全体的な知識は入手できない。その代わりに、システムにおける単独ピアの部分的観察に頼ることだけが可能である。
従って、本発明の目的は、2層階層DHTのコスト最適な運用を実現し及び保守するアルゴリズムを提供することである。
本発明の目的は、請求項1に従ったネットワーク機能を有するエンティティ、請求項17に従ったネットワーク機能を有するエンティティ、請求項18に従った方法、請求事項19に従った方法、及び請求項20に従ったコンピュータ・プログラムによって実現される。
本発明は、ネットワーク能力を有するエンティティ、例えば、(ピアになることのできる)スーパーピアを提供することによって、階層P2Pネットワークのコスト最適な運用を達成及び保守することができるという知見に基づく。スーパーピアは、現在のシステムの状況を記述するシステム幅パラメータの集合に対するそれらスーパーピアの部分的見解に基づいて、システム内の現存スーパーピア数Nspを増加又は減少する必要があるかどうかを判定するアルゴリズムを実行する。
本発明は、現存スーパーピア数Nspを推定し、及び、推定された実際のネットワーク状況及びスーパーピアの現存数Nspに基づいて、階層的ピアツーピア・ネットワークで要求される必要スーパーピア数N spを推定する推定器を備える。実施形態によれば、実際のネットワーク状況はシステム負荷因子Lに対応する。更に、ネットワーク機能を有するエンティティは、必要スーパーピア数N spが現存スーパーピア数Nspよりも大きい場合に、即ち、N sp>Nspである場合に、ネットワーク機能を有する他のエンティティを昇格させてスーパーピアにするコントローラを備える。
本発明は、更に、スーパーピアの現存数Nspを推定し、推定された実際のネットワーク状況及びスーパーピアの現存数Nspに基づいて、階層的ピアツーピア・ネットワークにおいて要求される必要スーパーピア数N spを推定する推定器を備えるネットワーク機能を有するエンティティを提供する。更に、ネットワーク機能を有するエンティティは、必要スーパーピア数N spが現存スーパーピア数Nspよりも小さい場合に、即ち、N sp<Nspの場合に、ネットワーク機能を有するエンティティの特性としてのスーパーピアを停止させるコントローラを備える。
本発明は、更に、ネットワーク機能を有するエンティティを動作させる方法を提供する。本方法は、次のステップを備える。即ち、階層的ピアツーピア・ネットワーク内において実際に存在しているスーパーピアの数である現存スーパーピア数を推定するステップ、推定された現存スーパーピア数(Nsp)に基づいて実際のネットワーク状況を推定するステップ、推定された実際のネットワーク状況に基づいて階層的ピアツーピア・ネットワークにおいて要求されるスーパーピアの必要スーパーピア数を推定するステップ、及び必要スーパーピア数N spが現存スーパーピア数Nspよりも大きい場合に、即ち、N sp>Nspである場合に、ネットワーク機能を有する他のエンティティを昇格させてスーパーピアにするステップである。
更に、本発明は、ネットワーク機能を有するエンティティを動作させる方法を提供する。本方法は、次のステップを備える。即ち、階層的ピアツーピア・ネットワーク内において実際に存在するスーパーピアの数である現存スーパーピア数を推定するステップ、推定された現存スーパーピア数(Nsp)に基づいて実際のネットワーク状況を推定するステップ、推定された実際のネットワーク状況に基づいて階層的ピアツーピア・ネットワーク内において要求されるスーパーピアの必要スーパーピア数を推定するステップ、及び必要スーパーピア数N spが現存スーパーピア数Nspよりも小さい場合に、即ち、N sp<Nspである場合に、ネットワーク機能を有するエンティティの特性としてのスーパーピアを停止させるステップである。
最後に、本発明は、プログラム・コードを有するコンピュータ・プログラムを提供する。プログラム・コードは、コンピュータ・プログラムがコンピュータ及び/又はマイクロコントローラにおいて実行するとき、本発明の方法の少なくとも1つを遂行する。
本発明は、DHTの中において生成される負荷を参加中のピア上に均一に平衡させるため、バックグラウンドにおいて実行しているロードバランス・アルゴリズムが存在するという仮定に基づく。コード・ベースのピアツーピア・システムにおけるロードバランス・アルゴリズムは、システム内の全てのスーパーピアが、スーパーピアの個々の負荷限度C maxとは独立に、近似的に同じ負荷因子を示すことを確保すべきである。更に、全てのスーパーピアの負荷因子LFは、任意の時点で100%に近くなければならない。それは、スーパーピアをできるだけ少なくして、全ネットワーク・トラフィックを最小にするためである。
階層的ピアツーピア・ネットワークのための、そのようなロードバランス・アルゴリズムは、例えば、欧州特許出願第06024317.7号において説明されている。このロードバランス・アルゴリズムは、リーフノードが到着する時点において、負荷が最小にされたスーパーピアへリーフノードを割り当てることに基づく。これを可能にするため、スーパーピアは相互の負荷を認識しなければならない。これは、各スーパーピアが、近隣のスーパーピアと交換されるメッセージの中にその負荷レベルを相乗りさせる(piggyback)ことが、各スーパーピアに要求することによって実現される。これらのメッセージは、ルーティングテーブル内の項目の通常のプローブ及びクエリーメッセージを含む。負荷レベルに関する情報は、DHTグラフ内の直接の近隣へのみ通信される。即ち、それはグラフを介して更に拡散されることはない。ノードがネットワークに加入するとき、このノードは、無作為に選ばれたスーパーピアとコンタクトすることが仮定される。コンタクトされたスーパーピアは、近隣スーパーピアの負荷レベルを知ると、最低の負荷を有する近隣スーパーピアを選択し、この近隣スーパーピアに要求を回送する。この近隣スーパーピアは更に要求を処置する。あるスーパーピアが、全ての近隣の負荷レベルよりも低い負荷レベルを有することが判ると、このスーパーピアは加入ノードをリーフとして受け入れる。可能なループを回避するため、有効期間が加入メッセージへ導入される。このロードバランス・アルゴリズムにおいて、相乗りされた負荷レベルは、前述した負荷因子LF(n=1,2,...,N)を意味することが想定される。このようにして、ロードバランス・アルゴリズムは、負荷因子LF(n=1,2,...,N)を近似的に同じレベルにする。このようにして、全てのスーパーピアは、それ自体の負荷、従ってシステム負荷因子Lと呼ばれる近似(仮説)数量を追跡することができる。
本発明の実施形態は、ネットワーク機能を有するエンティティ、例えば、スーパーピアが、それ自体の負荷を調節して、できるだけシステム負荷因子Lの所定の閾値Ldesへ近づけることを可能にする。必要な調節数ΔNspを決定するため、全てのスーパーピアは、図8を参照して前に説明された最高負荷曲線が、スーパーピア割合αにどのように依存するかを計算する必要がある。一度、あるスーパーピアがスーパーピア調節数ΔNspを計算すると、このスーパーピアは次のことを行う。即ち、新しいスーパーピアが必要とされる場合、即ち、ΔNsp>0であれば、このスーパーピアは平均して|ΔNsp|/Nsp個のリーフノードを昇格させてスーパーピアにする。システム内にあまりに多くのスーパーピアが存在する場合、即ち、ΔNsp<0であれば、各々のスーパーピアは、確率|ΔNsp|/Nspに従ってシステムを離脱し、リーフとして再加入する。
本発明の実施形態に従った、そのような動的コスト最適化は、前述した階層的ピアツーピア・システムの一般的利点に加えて多数の利点を提供する。そのような階層的ピアツーピア・オーバーレイ・ネットワークを主催している通信ネットワークのネットワーク運用者にとって、コストは、現在のネットワーク状況、即ち、現在のシステム負荷因子Lへ動的に適応する最小値へ低減され得る。注意すべきは、ネットワーク運用者の視点から全運用コストの上に焦点が置かれることである。ネットワーク運用者は、オーバーレイ・ネットワークを安定した運用モードに保ちながら、費用を最小にすることを厭わない。これは、モバイル・ネットワークにおいても現在出現しているように、ネットワーク・トラフィックがデータの消費によってはもはや請求されず、定額料金ベースで請求されるとき、特に必要である。他のアプローチも存在する。例えば、J.Li,J.Stribling,R.Morris,and M.F.Kaashoek, “Bandwidth−efficient management of DHT routing tables,” in NSDI,Boston,USA,2005は、全ピアツーピア・オーバーレイ間接費の低減に焦点を当てず、各ピアにおけるある利用可能なデータ転送レートを想定する。このデータ転送レートは都合のよい事態において使用可能であり、追加の保守間接費のコストでオーバーレイルーティングテーブルを適応させ、各ピアにおける利用可能データ転送レートを充足することによって、より高速な探索を可能にする。
本発明の実施形態は、運用者にとって有利であるだけでなく、ユーザは高品質のDHTを呈示される。なぜなら、本発明の実施形態に従った動的保守アルゴリズムは、必要な数の高層スーパーピアをシステム内に配置して、クリティカルな、つまり、過負荷となるような事態を回避するためである。
運用者及びユーザの更なる利点は、本発明の実施形態によって実現される自己組織パラダイムである。運用者は、余分の保守間接費を有さないで、オーバーレイを安定な運用モードに保つことができ、同時にコストを節減することができる。これはユーザに対しても当てはまり、スーパーピアになろうとしているそのコンピュータが、過負荷のために機能を停止することを心配する必要はない。追加の間接費は導入されない。なぜなら、ピア間において交換される全ての追加パラメータは、定期的DHT保守メッセージ及び探索要求と一緒に相乗りされるからである。
本発明の好ましい実施形態は、下記の図面に関して詳細に説明される。
本発明の実施形態に従ったネットワーク機能を有するエンティティ10のブロック図は、図1に描かれる。
ネットワーク機能を有するエンティティ10はI/O端末(I/O=入力/出力)12−k(k=1,2,...,K)を備え、これらのI/O端末は、ネットワーク機能を有するエンティティ10を、階層的ピアツーピア・ネットワーク・システムの他のネットワーク機能を有するエンティティへ接続する。ネットワーク機能を有するエンティティ10は、更に、コントローラ16へ結合された推定器14を備える。
ネットワーク機能を有するエンティティ10がスーパーピアとして機能する場合、推定器14は、本発明の実施形態に従って、階層的ピアツーピア・システム内において要求されるスーパーピアの必要スーパーピア数N spを推定するようになっている。ここで、要求されるスーパーピアの必要数N spは、実際又は現在のネットワーク状況に依存する。必要スーパーピア数N spを推定できるようにするため、推定器14は、更に、階層的ピアツーピア・ネットワークで実際又は現在、現存しているスーパーピアの数である現存スーパーピア数Nspを推定するようになっている。現存スーパーピア数Nspは、今後は[2]として参照されるA.Binzenhofer,D.Staehle,and R.Henjes, “On the Fly Estimation of the Peer Population in a Chord−based peer−to−peer System,” in 19th International Teletraffic Congress (ITC19),Beijing,China,2005からのアルゴリズムに基づき、推定器14によって推定される。[2]は、ネットワークのサイズを推定するコード特定アルゴリズムを提案している。
コード・ベースP2Pネットワークにおける現存スーパーピア数Nspの推定は、大体において、局所スーパーピアの近隣のスーパーピア密度を測定し、これをコード・リング全体のID空間へ外挿することに依存する。[2]において、スーパーピアz+1がスーパーピアzに続く確率が、示されている。
ネットワーク内の全てのスーパーピアは、その直接後継者をそのルーティングテーブル内に保守するだけでなく、直接の近隣となっているものに到達できない場合の失敗を迂回するため後継者の全リストを保守する。このリストは確率変数Iの実現を提供する。

[2]において呈示されたアルゴリズムのシミュレーション結果は、0.5Nspから2Nspまでの範囲で、推定された現存スーパーピア数の比較的高い分散を示す。
推定の分散を縮小するため、本発明の実施形態に従って、近隣スーパーピアの推定が考慮される。これは、推定された現存スーパーピア数を交換保守メッセージ(例えば、FINGER_PING又はSTABILIZEメッセージ)の上に相乗りさせることによって行われる。これらの交換保守メッセージは、いずれにせよ送られる必要があり、従って高いコストを導入することなく使用され得る。
本発明の実施形態によれば、全てのスーパーピアは、最後のx個の推定された現存スーパーピア数のFIFOリスト(FIFO=先入れ先出し)のために、FIFOバッファを備え、1秒当たり1つのメッセージの最大レートで、推定された現存スーパーピア数の最新版を送る。この制限は、高いトラフィック量を有するスーパーピアが、スーパーピアの推定を改ざんすることを防止するために導入される。さもなければ、高いトラフィックを有するスーパーピアは、低トラフィックのスーパーピアよりも多くの推定値を送出する。このようにして、高トラフィックのスーパーピアの推定値は、それがかつて有しており大きく低下させてしまった推定と比べても、近隣スーパーピアの推定においてより一層の重要性を備えることとなる。
本発明の現存スーパーピア数推定アルゴリズムの結果は、全く良好な性能を示し、+1%から+3%までのシナリオ依存の偏差を有する。実際の現存スーパーピア数Nspと推定現存スーパーピア数との間には、13から60秒までの時間差が観察される。この時間差は、推定器14が働く方法によって引き起こされる。即ち、推定器14の働きはスーパーピアの後継者リストに基づくために、ネットワーク・サイズの変化は、後継者リストが更新されるときに考慮される。ネットワーク構造のこの変化は、伝搬にいくらかの時間を取り、従って推定に時間差が存在することになる。
推定器14によって考慮される現在のネットワーク状況のために、本発明の実施形態に従って、前もって決定された前述の所望のシステム負荷因子Ldesが考慮される。それによって、Ldesは80%から120%までの値へ設定可能である。本発明の好ましい実施形態において、所望のシステム負荷因子Ldesは、100%よりも小さい値、例えば、Ldes=90%に設定される。100%よりも少し下の所望のシステム負荷因子Ldesを選択する2つの理由が存在する。第一に、上部レベルDHTの激動(churn)及びロードバランスによって生成されたスーパーピアの追加のトラフィック負荷は、下層の理論モデルでは考慮されない。第二に、スーパーピアのトラフィック負荷の期待されない増加のために、バッファが提供される。期待されない増加は、例えば、バースト状ルックアップ・トラフィックによって引き起こされる。
コントローラ16は、本発明の実施形態によれば、推定器14によって推定された必要スーパーピア数N spが現存スーパーピア数Nspよりも大きい場合に、I/O端末12−k(k=1,2,...,K)の1つを経由してネットワーク機能を有するエンティティ10へ接続されたネットワーク機能を有する他のエンティティを昇格させてスーパーピアにするようになっている。言い換えれば、この場合のネットワーク機能を有するエンティティ10は、現在利用可能なスーパーピアよりも多くのスーパーピアの必要性が存在する場合に、ある一定の確率に従って、それに付加されたピアの1つを昇格させて階層的ピアツーピア・システム内の新しいスーパーピアにするようなスーパーピアとして考慮されてよい。
本発明の更なる実施形態によれば、コントローラ16は、必要スーパーピア数N spが現存スーパーピア数Nspよりも小さい場合に、ネットワーク機能を有する当該エンティティ10の特性としてのスーパーピアを停止させるようになっている。言い換えれば、本実施形態において、コントローラ16は、現存スーパーピア数Nspが、階層的ピアツーピア・システム内において目的とされた所望のシステム負荷レベルLdesに関して、要求されるスーパーピア数N spを超過する場合に、スーパーピアをスーパーピアの地位から通常のピアへ降格させることができる。
推定器14は、更に、DHTシステム内のスーパーピアによって平均的に生成されたルックアップ・メッセージの平均数λを推定するようになっている。リーフノードがルックアップを遂行するとき、リーフノードはクエリーメッセージをその付加されたスーパーピアへ送る。付加されたスーパーピアは、スーパーピアのコード・オーバーレイの中においてそのルックアップのアドレス解決を実行し、結果をリーフノードへ返却する。1つのスーパーピアによって平均的に生成されたルックアップ・メッセージの平均数λを推定するために、推定器14は現存スーパーピア数Nsp及び平均システム・ルックアップ又はクエリーレートRの知識を有している必要がある。
システム・ルックアップ又はクエリーレートRは、システムによって時間単位当たりにアドレス解決されなければならないクエリーの数である。階層的ピアツーピア・システム全体の平均ルックアップレートRを推定する簡単な方法は、ネットワーク機能を有するエンティティ10のそのルックアップレートR(n=1,2,...,Nsp)を単純に平均することである。全てのスーパーピアは、それが答えなければならない時間単位当たりの到着クエリー(QUERY)メッセージをカウントすることによって、それが観察する局所クエリーレートR(n=1,2,...,Nsp)を測定し、R=Nsp・Rを評価することによって、システムのグローバルなクエリーレートRを推定する。Rの推定値は、相乗りを介して近隣スーパーピアからそれぞれの値を取得し、それ自体及び近隣のものから受け取られた値R(n=1,2,...,Nsp)について平均値R’を計算することによって、更に改善され得る。本発明の実施形態によれば、この理由によって、全てのネットワーク機能を有するエンティティ10は、最後のx個の推定されたルックアップレートのFIFOリストのためにFIFOバッファを備え、推定されたルックアップレートの最新版を近隣スーパーピアへ送ることができる。
結果の推定は、システムを全体として観察することによって、観察されたクエリーレートRと比較して、約3%から5%までの偏差を示す。
DHTシステムのようなコード・システムの場合、システム・ルックアップ・メッセージの平均量又はルックアップ・トラフィックλは、システム・ルックアップレートRに、ルックアップ当たりに生成されたメッセージの平均数を掛けることによって与えられる。コード・システムにおけるルックアップ要求のアドレス解決(resolution)は、次の3つのステップへ分割できる。第一に、スーパーピアのコード・リングにおいて、担当となるスーパーピアがアドレス解決(resolve)される。これは平均でlogsp個のメッセージを生成する(平均して、担当となるピアをアドレス解決するために1/2logsp個のホップが要求され、反復ルーティングスキームを仮定すると、全てのホップが2つのメッセージを必要とする)。次に、ルックアップ要求が、担当のスーパーピアへ回送され(1メッセージ)、最後に、結果がクエリーしているピアへ伝送される(1メッセージ)。結果として、スーパーピア又はネットワーク機能を有するエンティティ10の推定器14は、次の式によって、スーパーピア当たりの現在のシステム・ルックアップ・トラフィックを計算することができる。
Figure 0004652435
更に、推定器14は、スーパーピアが下層のDHTシステムによって生成した保守トラフィック・メッセージの平均数を推定する必要がある。下層のDHTシステムがコード・システムである場合、保守トラフィックは、リーフノードとスーパーピアとの間のPING−PONGアルゴリズム、STABILIZEアルゴリズム、FIXFINGERアルゴリズム、及びスーパーピア・コード・オーバーレイにおけるREPUBLISHアルゴリズムによって生成される。このようにして、スーパーピアの全トラフィック負荷は、ルックアップ・トラフィックλ、PING−PONGトラフィック、STABILIZEトラフィック、及びFIXFINGERトラフィックを備える保守トラフィックμ、及びREPUBLISHトラフィックρから成る。
スーパーピアの保守トラフィックμは、スーパーピアのコードDHTを保守するSTABILIZE及びFIXFINGERアルゴリズム、及びリーフノードの故障を検出するためのリーフノード確認によって生成される。これは定期的PING−PONGアルゴリズムによって行われる。全てのリーフノードはTping秒ごとPING−PONGアルゴリズムを定期的に実行する。リーフノードはピン(PING)メッセージをそのスーパーピアへ送り、スーパーピアはポン(PONG)メッセージによって答える。全てのリーフノードをスーパーピアの上に均一に拡散させる適切なノードのバランスアルゴリズムが仮定されるので、これは平均してスーパーピア当たり次式の数のPING−PONGメッセージを生成する。
Figure 0004652435
なぜなら、
Figure 0004652435
は、スーパーピアへ付加されたリーフノードの平均数であるからである。このようにして、Mは、現存スーパーピア数Nspに対して、階層的ピアツーピア・ネットワーク内において参加するノードの総数Nの比を表す。ノードの総数Nは、現存スーパーピア数Nspとネットワーク内のリーフノードの数との合計である。Mはグループ・サイズと考えられる。従って、グループ・サイズMは、スーパーピアが管理しなければならないリーフの数に1を加えたもの(1はスーパーピア自体を示す)である。PING−PONGメッセージの数mpingpongを推定できるようにするため、推定器14はグループ・サイズMを推定するようになっている。システム平均値に近いMの推定値を獲得するため、図1の点線18、19によって示されるように、ネットワーク機能を有するエンティティの近隣のものによって受け取られるMの推定値のために、再び、FIFOリストがネットワーク機能を有するエンティティ10の中に導入される。これは有利である。なぜなら、システムのロードバランス・アルゴリズムに起因して、スーパーピア当たりのリーフノードの数は、スーパーピアの能力に従って異なるためである。
シミュレーションの結果は、加入段階においては非常に正確な推定を示し、激動及び離脱段階においては、推定は、約3%というやや過大なものとなる。これは、スーパーピア数が過大に推定されることから生じる。
本発明の更なる実施形態によれば、ネットワーク機能を有するエンティティ10のそのグループ・サイズMを単純に決定することによって、即ち、ネットワーク機能を有するエンティティ又はスーパーピア10へ付加されたリーフノードの数を決定することによって、Mの簡単な推定値を取得することができる。
推定器14によって推定されるべき保守メッセージの平均量の更なる部分は、STABILIZEアルゴリズムによって引き起こされるメッセージである。STABILIZEアルゴリズムは、Tstab秒ごとに定期的に実行される。STABILIZEは3つのメッセージを要求する。REQUESTPREDECESSORメッセージ、対応するRESPONSEPREDECESSORメッセージ、及び最後にNOTIFYメッセージである。開始スーパーピアは、REQUESTPREDECESSORメッセージをその後継者に送り、後継者はRESPONSEPREDECESSORメッセージによって応答し、最後に開始ピアはNOTIFYメッセージを送る。従って、任意のスーパーピアn(n=1,2,...,Nsp)について送受信されるSTABILIZEメッセージの数は、次式によって与えられる。
Figure 0004652435
更に、コード・システム内の全てのスーパーピアは、そのlogsp個のフィンガ(finger)の各々のために、Tfix秒ごとにFIXFINGERアルゴリズムを定期的に実行する(完全に占拠されたID空間を仮定する)。しかしながら、本発明の実施形態において、各々のスーパーピアが平均で2logsp個のメッセージを生成するような改善されたFIXFINGERアルゴリズムが使用される。このアルゴリズムは、PINGメッセージをフィンガ・ピアへ送り、PONGメッセージが受け取られないか、フィンガ・ピアがこのフィンガIDを担当する新しいピアを表示するときにのみ、フィンガ・ルックアップを開始する。結果として、システムが定常状態にあるとき、フィンガ・ルックアップを回避することができ、任意のスーパーピアn(n=1,2,...,Nsp)について送受信されるFIXFINGERメッセージの数は、次式によって与えられる。
Figure 0004652435
式(3)、(5)、及び(6)をまとめると、次式が得られる。
Figure 0004652435
前述したように、保守トラフィックの他の態様は、DHTシステムがコード・システムに編成される場合の、REPUBLISHアルゴリズムに起因する。全てのスーパーピアは、スーパーピア自体及びそのリーフノードの全共有オブジェクトについて、Trep秒ごとにREPUBLISHアルゴリズムを定期的に実行する。共有オブジェクトを再発行(republish)することは、オブジェクトのIDのコード・ルックアップに対応する。従って、それは平均してlogsp個のメッセージを生成する。ここで、全てのスーパーピアは、それ自体とそのリーフノードによって共有される同数のオブジェクトを管理するものと仮定される。即ち、
Figure 0004652435
式(8)において、Fは階層的ピアツーピア・システム全体の共有アイテムの数を表す。Fav=F/Nspは、1つのスーパーピアによって管理される共有オブジェクトの平均数を表す。
共有オブジェクト又はオブジェクト参照の数は、更に、各々のネットワーク機能を有するエンティティ10によって局所的に決定され、近隣のネットワーク機能を有するエンティティへ配布される。共有オブジェクトの数の平均値Favを構築することによって、システムの平均値の推定が、F=Nsp・Favに従って取得される。
シミュレーションにおいては、Fが約5%から6%過大に推定される。この過大推定が生じるのは、主に、現存スーパーピア数Nspが過大推定されたためである。
REPUBLISHトラフィックρは、スーパーピアのDHT内の共有アイテムに関する情報を定期的に更新するために必要である。なぜなら、ピアは故障するかも知れず、従って参照が失われるかもしれないためである。共有アイテムの再発行は、共有アイテムのルックアップと同じである。その結果、ルックアップ・トラフィックの上記の解析を使用することによって、及び、Trep秒ごとに再発行される共有アイテムの総数Fによってシステム・ルックアップレートRを置換することによって、再発行トラフィックを簡単に計算することができる。その結果、スーパーピアは、次式によって、システムにおける現在のREPUBLISHトラフィックρを推定することができる。
Figure 0004652435
再び、推定器14によって、値Fが推定されなければならない。前述したように、ネットワーク機能を有するエンティティ10の共有オブジェクトの自己数f(n=1,2,...,Nsp)を考慮されることによって、これを行うことができる。ロードバランス・アルゴリズムはバックグラウンドで実行することが仮定されるので、それ自体の値を考慮するそのような推定値は、全体的システム・パラメータについて既に良好な推定値を産出することが考えられる。共有アイテム数の推定値を更に改善するため、ネットワーク機能を有するエンティティ10は、本発明の実施形態に従って、更に、それ自体の値、及び相乗りによって近隣スーパーピアから取得された値について、平均値を計算する。
現在のシステム負荷因子Lの推定値を計算するため、推定器14は、更に、階層的ピアツーピア・システムのスーパーピア当たりの平均容量Cについて推定値を必要とする。平均スーパーピア容量Cは、前述したように、相乗りによって局所スーパーピア容量を配布し、最後のx個の受け取られた容量について平均値を構築することによって決定される。結果の値は非常に正確であり、偏差は0.1%よりも小さい。これは、結果の分散を増加した他の推定からの独立性から生じる(前の値はNspを使用して計算されなければならなかった)。再び、ネットワーク機能を有するエンティティ10のそれ自体の値だけを考慮することによって、簡単な推定値を取得することができる。
λ、μ、ρ、及びCの推定値を推定すると、推定器14は次式に従ってシステム負荷因子Lの推定値を計算してよい。
Figure 0004652435
次に、式(10)に従って計算された現在のシステム負荷因子Lの推定値は、所望のネットワーク状況、即ち、所望のシステム負荷因子Ldesと比較される。Nsp、M、R、F、C、及びLとLdesとの比較結果に基づいて、推定器14は必要スーパーピア数N spを計算し、Lが範囲内にあるように、又はLdesに等しくなるようにする。即ち、Ldes=90%である。差ΔNsp=(N sp−Nsp)は、スーパーピアの調節数を表す。ΔNsp>0の場合、新しいスーパーピアが必要であり、ネットワーク機能を有するエンティティ10のコントローラ16は、平均|ΔNsp|/Nspでリーフノードを昇格させてスーパーピアにする。ΔNsp<0であれば、コントローラ16は、システムを離脱してリーフノードとして再加入するため、確率|ΔNsp|/Nspでネットワーク機能を有するエンティティ10の特性としてのスーパーピアを停止させる。
タイマーTstab、Tfix、Trep、及びTPingはDHT設計パラメータであることが仮定される。なぜなら、これらのタイマーはそのようなものとして事前に公知であるからである。これらのパラメータの他に、システムの現在の状態を特徴づけする多数の他のパラメータ(Nsp、M、R、F、C)がアルゴリズムの中に存在する。それらのパラメータは前もって与えられず、推定器14によって推定される必要がある。現存スーパーピア数Nspは、[2]で説明されたアルゴリズムの改善版を使用して推定される。グループ・サイズM、システム・ルックアップレートR、共有オブジェクトの平均数F、及び平均容量Cは、それ自体の値及び/又は相乗りで近隣スーパーピアから取得された値の平均値を計算することによって、スーパーピアによって全て推定される。
現存スーパーピア数Nspの推定は、後継体リストの正確度に依存する。直感的に、定期的保守メッセージを制御するタイマー値Tstab、Tfix、Trep、及びTPingの変更が、推定の偏差に影響すると仮定することができる。この仮定を証明するため、異なるタイマー値を有するいくつかのシナリオがシミュレートされ、例えば、STABILIZEタイマー値Tstabを10秒から5秒へ変更すると、偏差は約3.5%から0.6%へ減少することが発見された。もちろん、この変更は、増加する保守トラフィックをもたらす。
システムの外部影響としてのクエリーレートRも、推定の正確度にインパクトを与える。なぜなら、クエリーレートRが高くなると、各ノードにおいて他のピアからの新鮮な情報が利用可能になるためである。各ノードで、ルックアップレートを1分当たり1つのクエリーから1分当たり2つのクエリーへ2倍にすると、偏差は約2.5%から約0.5%へ減少する。
ルックアップ・メッセージの平均数λ、保守メッセージの平均数μ、及びスーパーピア当たりのREPUBLISHメッセージの平均数ρを推定する代わりに、推定器14は、更に、それぞれの全体的システム・パラメータ、即ち、推定された現存スーパーピア数Nspを乗じた値λ、μ、及びρを推定するように構成されてよい。しかしながら、これはシステム負荷因子Lの推定値を計算するときに考慮されなければならない。
ここで、図2を参照すると、本発明の実施形態に従ってネットワーク機能を有するエンティティ10を動作させる方法が説明される。
本方法は、階層的ピアツーピア・ネットワーク内において要求されるスーパーピアの必要スーパーピア数N sp、実際のネットワーク状況に依存するスーパーピアの必要数を推定し、及び、階層的ピアツーピア・ネットワーク内に実際に存在するスーパーピアの数である現存スーパーピア数Nspを推定するステップS1を備える。
本方法は、更に、必要スーパーピア数N spがスーパーピア数Nspよりも大きい場合に、異なるネットワーク能力を昇格させてスーパーピアにするステップS21、及び、必要スーパーピア数N spが現存スーパーピア数Nspよりも小さい場合に、ネットワーク機能を有するエンティティ10の特性としてのスーパーピアを停止させるステップS22を備える。
推定ステップS1は、更に、サブステップへ分割される。第一のサブステップS11においては、現存スーパーピア数Nsp、グループ・サイズM、システム・ルックアップレートR、共有オブジェクトの平均数F、及び平均容量Cが、前述したように、それ自体の値の平均値、及び/又は相乗りによって近隣スーパーピアから取得された値の平均値を計算することによって全て推定される。要求スーパーピア数N spは、最初にステップS11において現存スーパーピア数Nspへ等しく設定される。次のサブステップS12では、サブステップS11からの推定システム・パラメータ(Nsp、M、R、F)を使用して、値λ、μ、及びρが式(2)、(7)、及び(9)に従って計算される。次のサブステップS13においては、サブステップS12からの値λ、μ、ρ、及びCを使用して、現在のシステム負荷因子Lが式(10)に従って計算される。
現在のシステム負荷因子Lを計算すると、更なるサブステップS14で、Lを所望のシステム負荷因子Ldesと比較することができる。現在のシステム負荷因子Lが所望のシステム負荷因子Ldesの許容範囲、例えば、0.9Ldes<L<1.1Ldesにない場合、スーパーピアの調節を起こさなければならない。言い換えると、例えば、L<0.9Ldes又はL>1.1Ldesの場合に、スーパーピアの調節が必要である。Ldesは、例えば、90%である。L<0.9Ldesであれば、新しいスーパーピア数はNspよりも低くなければならない。L>1.1Ldesであれば、新しいスーパーピア数はNspよりも大きくなければならない。双方の場合、要求されるスーパーピア数は、サブステップS15でN spを徐々に増加(L>Ldesの場合)又は減少(L<Ldesの場合)することによって取得される。全ての反復において、それぞれの結果のシステム負荷は、式(10)に基づいてサブステップS12及びS13で再び計算される。これは、推定されたシステム負荷因子Lが、所望の負荷因子Ldesの指定された許容範囲、即ち、0.9Ldes<L<1.1Ldesの中に入るまで行われる。範囲の中に入ると、N spは要求スーパーピア数を表す。ステップS17においては、スーパーピアの調節数ΔNsp=N sp−Nspが、0よりも大きいかどうかが決定される。大きければ、階層的ピアツーピア・システムにおいて新しい追加のスーパーピアの必要性が存在する。従って、ステップS21においては、ネットワーク機能を有するエンティティ10によって、ネットワーク機能を有する他のエンティティが確率|ΔNsp|/Nspで昇格されてスーパーピアにされ、ピアツーピア・ネットワーク・システム全体の中でΔNsp個のピアが昇格されてスーパーピアにされる。スーパーピアの調節数ΔNspが0よりも小さいことをサブステップS17が産出する場合、ネットワーク機能を有するエンティティ10の特性としてのスーパーピアは確率|ΔNsp|/Nspで停止され、ΔNsp個のスーパーピアがピアツーピア・システム全体に関して普通のピアへ降格される。
現在のシステム負荷因子Lが、所望のシステム負荷因子Ldesの許容範囲の中にない場合、スーパーピア調節を遂行する代わりに、本発明の実施形態に従って、現在のシステム負荷因子Lが所望のシステム負荷因子Ldesの許容範囲の中にあるか否かに関わらず、Nsp又はN spを徐々に増分するか(L>Ldesの場合)または減分する(L<Ldesの場合)ことによってスーパーピア調節数ΔNspを常に計算し、|ΔNsp|が所定の閾値よりも大きい場合にのみ、スーパーピアへ昇格させるか終了することも可能である。この閾値は、システム・サイズ、即ち、N又はNspに依存する。
図2を参照して説明された方法は、定期的に実行され得る。ここで、方法を応用するための期間は、階層的ピアツーピア・システムの力学に依存する。
このアルゴリズムを適切に運用する前提条件は、リーフノードをスーパーピアへ昇格させるとき、高コスト限度C maxを有するリーフノードが選ばれることである。再び、この情報は相乗りによってスーパーピアの間で配布される。もっと正確には、全てのスーパーピアは、その送るメッセージをその最も有能なリーフノードのアドレス及びコスト限度で拡張し、リーフノードの昇格を決定するとき、スーパーピアはこの情報を使用して、スーパーピアが知っている現在最も有能なリーフノードを昇格させる。
本発明の実施形態が図1及び図2を参照して詳細に説明された後、いくつかの実験的結果が下記のようにして呈示される。この実験結果は、N=1,000からN=25000までの数のピアを有する複数の独立シナリオをシミュレートして取得された。
各々のピアは、セッション持続時間tonline、ルックアップレートr、及び共有オブジェクトの数f(n=1,2,...,N)について異なる値を割り当てることによってモデル化される。これらの値は、特定の平均値の周りで指数分布となる。tonlineのテストされた平均値は、それぞれ5分、15分、30分、及び1時間である。rについては、12分、2分、1分、及び15分の平均値がそれぞれ仮定される。fの平均値は20へ設定される。
1秒当たりにアップロードされるメッセージに関する全ピアのコスト限度は、次の仮定に基づいて指定される。
(1)アップロード・ビットレートは、50kビット/秒(モデム)から500kビット/秒(DSL)までの範囲である。
(2)平均メッセージ・サイズは500バイトである。
(3)ピアは、オーバーレイ参加のために、ピアのアップロード容量の10%を費やす。
このようにして、均一に分布されたアップロード限度は、全てのピアへ1秒当たり1から13までのメッセージを割り当てられる。注意すべきは、仮定3)が、他のネットワーク・タスク、例えば、ファイル転送のために、十分な残りの帯域幅を確保することである。また、オーバーレイ参加のためにアップロード容量の10%を使用することは、影響されるピアを過負荷にすることなく、100%よりも多い(一時的に)増加される負荷レベルを許す。そのような一時的に増加される負荷レベルは、例えば、バースト状ルックアップ・トラフィックに起因して時々起こり得る。
次のシステム幅パラメータは、シミュレーションを通して使用された。
Figure 0004652435
シミュレーション・シナリオは3つの段階に分割される。第1の段階は「加入段階」と呼ばれる。この段階において、ピアが所望数に達するまで、ピアはシステムに加入する。次に、「激動段階」がある。この段階では、ピアがシステムへ同時に加入及び離脱する。ピアの到着レートは、「激動段階」のピアの数が比較的一定レベルに止まるように選ばれる。最後に、「離脱段階」において、ピアの到着レートは0へ設定され、システム内のピアは、ピアの負の指数分布セッション持続時間に従ってオフラインになる。シミュレーションの間に、現存スーパーピア数Nspが継続的に測定され、最適数Noptと比較される。Noptはシステムを全体として観察して計算され、Nopt個の最も有能なピアが上部レベルのオーバーレイを構築し、残りのピアはリーフノードとして付加される。前述したように、最適のスーパーピア比は、90%と100%の間のシステム負荷を導くべきである。これを評価するため、現在のシステム負荷因子L、即ち、全スーパーピアの平均負荷因子が定期的に記録される。得られた結果を統計的に有効にするため、各々のシナリオは、乱数発生器への異なる種を用いて複数回シミュレートされた。しかしながら、各シナリオの異なるシミュレーション実行において、有意の変化は検出されなかった。
評価の結果は、1つの特定シミュレーション・シナリオに関して説明される。しかしながら、強調されることとして、評価の結果は全ての他のシミュレートされるシナリオについても有効である。考慮されたシナリオにおいて、ピアの総数は1,000であり、tonlineの平均値は30分であり、rの平均値は1分当たり1ルックアップへ設定される。
図3は、システム内に現在現存するスーパーピアの数Nspの曲線30を示す。注意すべきは、本システムが、オンラインである8つのスーパーピアと共にスタートすることである。加入段階(0〜1800秒)の間、スーパーピア数Nspは増加する。なぜなら、システムにおいて増加するN個のピアによって生成されるトラフィックを処理し、必要なスーパーピアがますます多くなるためである。激動段階(1800〜5400秒)において、スーパーピア数Nspは比較的一定である。
いくつかのスーパーピアはそのセッション持続時間の終了に起因してシステムを離脱し、他のスーパーピアはその(時には、間違った)推定に基づいてシステムを離脱するかリーフノードを昇格させるので、この一定のスーパーピアの数Nspの辺りには、継続的に小さいゆらぎが認知される。「離脱段階」(5400〜7200秒)の間に、スーパーピアの数Nspは減少する。なぜなら、システム内の減少するトラフィックを処理するため、必要とされるスーパーピアは少なくなるからである。
全てのシミュレーション段階において、スーパーピアの測定された数は、常に最適数(点線32)に近いことが分かる。
図4は、シミュレーションの間に測定されたシステム負荷Lを描写する。期待されるように、それは90%のあたりで変動し、システム内において生成されるがこの理論モデル(激動、ロードバランス)で考慮されないトラフィックが、有意の影響を有さないことを表示する。図4はシステムにおける全スーパーピアの平均負荷レベルLを示すが、単一ピアの負荷レベルLFの典型的曲線は図5に見られる。tにおいて、ピアはリーフノードとしてシステムに加入する。このピアは十分なアップロード容量を提供するので、それはtにおいてスーパーピアへ昇格され、従ってその負荷レベルLFを継続的に測定し始める。tにおいては、必要数より多いスーパーピアがシステム内に存在することを仮定するので、ピアは上部レベルDHTを離脱してリーフノードとして再加入する。後のtにおいて、ピアは再びスーパーピアへ昇格される。最後に、ピアはtにおいてシステムを離脱する。(ピアがスーパーピアであるときの)負荷レベルLFは、時間と共に変動することが分かるが、期待されるように、一時的に100%を超えるだけである。
上記の図面に示されない更に興味深いシミュレーション結果が存在する。第一に、階層システムは、N個の全ピアがコード・リングの一部分である平坦DHTよりも、少ないネットワーク・トラフィックを生成する。上記の例において、階層システム内のメッセージの総数は7,174,941個であり、平坦コード・システムは全部で7,883,201個のメッセージを生成する。これは9%のトラフィック低減に対応する。これらのメッセージの大部分は強力なスーパーピアによって処理されるという追加利益を階層システムが提案することに注意すべきである。第二に、ほんの5分の非常に低い平均セッション持続時間が見出される。これは低すぎる数のスーパーピア、従って100%を超えるシステム負荷を生じる。この理由は、アルゴリズムはスーパーピアの必要数を計算し、調節するが、それらのスーパーピアの多くは、オンライン時間が短いために、その後すぐに離脱するからである。結果として、システム内で継続的に存在するスーパーピアの数が少なくなりすぎる。しかしながら、平均セッション持続時間が15分へ上昇するとき(これは依然として低い値であるが)、アルゴリズムは、上記で示される良好な性能を再び示す。
最後に、ピアの平均ルックアップレートが、5秒ごとに1ルックアップという極端に高い値へ指定されるとき、システム内のスーパーピアの数は理論的値よりも相当に高くなる。この理由は、理論的には、(全てのリーフノードの中で最高容量を有する)次の最良リーフノードを常に選んで、次のスーパーピアにするためである。このシナリオでは、負荷を処理するための非常に高いスーパーピア比が必要なので、アルゴリズムは必ずしも現在の最良リーフノードを見出すことができず、より低い容量を有する他のリーフノードを選択する。このようにして、全スーパーピアの平均容量は理論値よりも低くなるので、膨大なルックアップ・トラフィックを処理するために必要なスーパーピアは多くなる。それにも関わらず、この極端なシナリオにおいて、本発明のアルゴリズムは約90%の所望のシステム負荷を提供することが分かる。
これまでの説明を要約すると、ピアツーピア・ネットワークは、リソースの集合の高速位置決めを可能にする自己組織化分散オーバーレイ・ネットワークである。これらのネットワークは、参加中のノード間の物理接続に依存するアプリケーション層オーバーレイ・ネットワークとして実現される。ピアツーピア・ネットワークによって対処される基本問題は、リソースの集合の自己組織化分散であり、ピアの集合は後続の高速ルックアップを可能にする。
この問題を解決する有望なアプローチは、分散ハッシュ・テーブル(DHT)としても知られる構造化ピアツーピア・ネットワークの概念である。DHTにおいて、ピアは鍵空間からの鍵によって識別されるリソースの具体的部分集合を協力して管理する。これは次のようにして行われる。各々のピアは、鍵空間から取られた鍵に関連づけられる。ピアの集合が与えられたと仮定すると、各ピアの鍵は鍵空間の区画に関連づけられ、ピアは関連区画からの鍵によって識別される全ての鍵リソースを管理する担当になることになる。典型的には、鍵区画は、ピア鍵からみて、適切な尺度で最も近くにある全ての鍵から構成される。鍵の近さは距離関数によって測定される。リソース要求を回送するため、ピアは、ピアと鍵区画との関連付けに関する知識を考慮して、ルーティングネットワークを形成する。ピアは、典型的には、近隣鍵を有する全ピアへの短距離リンク、及び追加的に、いくつかの選択された遠いピアへの少数の長距離リンクを保守する。このように確立されたルーティングネットワークを使用して、ピアは、指図された態様によって、そのルーティングテーブルからの他のピアへリソース要求を回送し、ルックアップされている鍵への距離を大幅に低減しようと試みる。DHTの大部分は、この構成及びルーティングアルゴリズムにより、ネットワークのサイズにおいて対数的なルーティングテーブルを使用することによって、ネットワークのサイズにおいて同様に対数的な多数のメッセージの中でルックアップを実現する。
考慮されたピアツーピア・アーキテクチャは、参加中のピアを2つのグループに分割する。即ち、分散ハッシュ・テーブルの中に組織され、第2のグループのプロキシとして役立つスーパーピアのグループと、これらのスーパーピアへ付加され、DHTに参加しないリーフノードのグループである。
階層DHTは、スケーラビリティ、ネットワークの局所性、及び順方向隔離に関して、平坦DHTよりも性能が勝ることが発見された。[1]において、これらの発見は、他の観点から階層及び平坦DHTを評価することによって深められた。即ち、DHT構成の最適性の判断を可能にする一般コスト・ベース・フレームワークの観点である。スーパーピア及びこれらスーパーピアに付加されるリーフノードの注意深く選ばれた集合からなる簡単な階層DHT組織は、これがネットワーク・リソースの使用を最小化する意味で、最適であることが発見された。
本発明の実施形態は、そのような階層的ピアツーピア・システムを構築及び保守するアルゴリズムの完全な集合を提供する。具体的には、本発明の実施形態は、スーパーピア対リーフノードの比に関して、階層的ピアツーピア・システムの最適な運用点を動的に決定する。本発明のアルゴリズムは十分に分散されて確率的であり、ピアによって取られる全ての判定は、システム幅パラメータの集合に対するそれらピアの部分的見解に基づいている。このようにして、本発明の実施形態は、自己組織化の主な原理を説明する。システムの振る舞いは、局所的対話から出現する。現実的設定の範囲の中にある呈示されたシミュレーションは、本発明のアルゴリズムの良好な性能を裏付ける。
検討された実施形態は、DHTとしてコード・システムを使用するが、他の構造化ピアツーピア・プロトコルも、同様の利点を実現するために使用され得る。
本発明の実施形態は、より安定した少コストのネットワーク動作、及び高い順方向弾力性を使用する。このようにして、本発明は全体としてのネットワークへ強い経済的インパクトを与える。
更に、本発明の方法のある一定の実現要件に依存して、本発明の方法は、ハードウェア又はソフトウェアによって実現され得る。実現は、ディジタル記憶メディア、具体的には、電子的に読み取り可能な制御信号を記憶したディスク又はCDを使用して遂行され得る。ディジタル記憶メディアは、プログラム可能なコンピュータ・システムと協力して、本発明の方法が遂行されるようにする。一般的に、本発明はコンピュータ・プログラムプロダクトである。コンピュータ・プログラムプロダクトは、機械読み取り可能担体の上に記憶されたプログラム・コードを有する。プログラム・コードは、コンピュータ・プログラムプロダクトがコンピュータで実行するとき、本発明の方法の少なくとも1つを遂行するようになっている。言い換えれば、本発明の方法は、コンピュータ・プログラムがコンピュータ及び/又はマイクロコントローラで実行する間に本発明の方法を遂行するプログラム・コードを有するコンピュータ・プログラムである。
本発明の実施形態に従ったネットワーク機能を有するエンティティのブロック図を示す。 本発明の実施形態に従ったネットワーク機能を有するエンティティを動作させる方法のフローチャートを示す。 本発明の実施形態に従ったアルゴリズムを用いて時間の経過と共に取得されたスーパーピア数のシミュレーション結果を示す。 本発明の実施形態に従ったアルゴリズムを用いて時間の経過と共に取得されたシステム負荷を描写するシミュレーション結果を示す。 本発明の実施形態に従ったアルゴリズムを用いて取得された単一ピアの負荷レベルの典型的負荷曲線を示す。 ピアツーピア・オーバーレイ・ネットワーク、及びこの下層の物理ネットワークの例示的層構造を示す。 コード・リングを形成するスーパーピア及び各スーパーピアに付加されたノードを有する可能な階層的ピアツーピア・システムを示す。 スーパーピア割合αに対する最高負荷因子曲線及びコスト曲線を示す。

Claims (20)

  1. 階層的ピアツーピア・ネットワークにおいて、現存スーパーピア数から要求されるスーパーピアの数へのスーパーピアの調節を推定する推定器(14)であって、前記スーパーピアの調節は実際のシステム負荷因子(L)の推定と所望のシステム負荷因子(L des )との比較の結果に依存し、前記所望のシステム負荷因子(L des )は100%よりも小さい値に設定され、前記実際のシステム負荷因子(L)の前記推定は、前記階層的ピアツーピア・ネットワークに実際に存在しているスーパーピアの数である現存スーパーピア数(N sp )の推定に依存する、推定器と、
    前記必要スーパーピア数(N sp)が前記現存スーパーピア数(Nspの前記推定よりも大きい場合に、ネットワーク機能を有する他のエンティティを昇格させてスーパーピアにするコントローラ(16)と
    を備えるネットワーク機能を有するエンティティ(10)。
  2. 前記階層的ピアツーピア・システムにおいて生成された負荷を参加中のスーパーピアの間において均一にバランスさせるロードバランス処理を行う階層的ピアツーピア・システムの一部分となっている、請求項1に記載のネットワーク機能を有するエンティティ。
  3. 前記階層的ピアツーピア・システムのスーパーピアがコード・ネットワークとなるように編成される、請求項1又は2に記載のネットワーク機能を有するエンティティ。
  4. 前記推定器(14)がシステム負荷因子(L)を前記実際のネットワーク状況として使用するようになっており、前記システム負荷因子(L)がロードバランスされている階層的ピアツーピア・システムにおける平均ピア・コストと最大ピア・コストとの間の比を表す、請求項1〜のいずれかに記載のネットワーク機能を有するエンティティ。
  5. 前記推定器(14)が、スーパーピアによって生成されたルックアップ・メッセージの平均数(λ)を推定し、スーパーピアによって生成された保守メッセージの平均数(μ)を推定し、スーパーピア当たりのREPUBLISHメッセージの平均数(ρ)を推定するようになっている、請求項1〜のいずれかに記載のネットワーク機能を有するエンティティ。
  6. 前記推定器(14)が、前記推定された現存スーパーピア数(Nsp)と推定されたルックアップレート(R)とに基づいて、スーパーピア当たりの生成ルックアップ・メッセージの前記平均数(λ)を推定するようになっている、請求項に記載のネットワーク機能を有するエンティティ。
  7. 前記推定器(14)が、次の式、
    Figure 0004652435

    に従って、スーパーピア当たりの生成ルックアップ・メッセージの前記平均数(λ)を推定するようになっている、請求項に記載のネットワーク機能を有するエンティティ。
  8. 前記推定器(14)が、前記推定された現存スーパーピア数(Nsp)とスーパーピアに接続されたピアの平均比を意味する推定されたグループ・サイズMとに基づいて、スーパーピア当たりの保守メッセージの前記平均数(μ)を推定するようになっている、請求項に記載のネットワーク機能を有するエンティティ。
  9. 前記推定器(14)が、次の式、
    Figure 0004652435

    に従って保守メッセージの前記平均数(μ)を推定するようになっており、式中、TstabはコードのSTABILIZEアルゴリズムの期間を表し、TfixはコードのFIXFINGERアルゴリズムの期間を表し、TpingはコードのPING−PONGアルゴリズムの期間を表す、請求項に記載のネットワーク機能を有するエンティティ。
  10. 前記推定器(14)が、前記階層的ピアツーピア・ネットワークにおける共有オブジェクトの数(F)と前記現存スーパーピア数(Nsp)の推定値とに基づいて、スーパーピア当たりのREPUBLISHメッセージの前記平均数(ρ)を推定するようになっている、請求項に記載のネットワーク機能を有するエンティティ。
  11. 前記推定器(14)が、次の式、
    Figure 0004652435

    に従って、REPUBLISHメッセージの前記数(ρ)を推定するようになっている、請求項1に記載のネットワーク機能を有するエンティティ。
  12. 前記推定器(14)が、前記階層的ピアツーピア・ネットワークのスーパーピア当たりの平均容量(C)を推定し、スーパーピア当たりの生成ルックアップ・メッセージの前記推定された平均数(λ)と、スーパーピア当たりの保守メッセージの前記推定された平均数(μ)と、スーパーピア当たりのREPUBLISHメッセージの前記推定された平均数(ρ)と、前記推定された平均容量(C)とに基づいて、前記実際のネットワーク状況(L)を推定するようになっている、請求項1〜1のいずれかに記載のネットワーク機能を有するエンティティ。
  13. 前記推定器(14)が、次の式、
    Figure 0004652435

    に従って前記実際のネットワーク状況(L)を推定するようになっている、請求項1に記載のネットワーク機能を有するエンティティ。
  14. コントローラ(16)は、前記実際のネットワーク状況に依存するシステム負荷因子(L)を所望のシステム負荷因子(Ldes)と比較して、前記現在のシステム負荷因子(L)が前記所望のシステム負荷因子(Ldes)よりも大きい場合に前記現存スーパーピア数(Nsp)と比較される前記必要スーパーピア数(N sp)を増加させ、前記現在のシステム負荷因子(L)が前記所望のシステム負荷因子(Ldes)よりも小さい場合に前記現存スーパーピア数(Nsp)と比較される前記必要スーパーピア数(N sp)を減少させるようになっている、請求項1〜1のいずれかに記載のネットワーク機能を有するエンティティ。
  15. 前記推定器(14)が、前記ネットワーク機能を有するエンティティ(10)に特定された値に基づいて、平均ルックアップレート(R)と、平均グループ・サイズ(M)と、共有アイテムの平均数(F)と、スーパーピアの平均容量(C)との値を推定するようになっている、請求項1〜1のいずれかに記載のネットワーク機能を有するエンティティ。
  16. 前記推定器(14)が、前記値について平均値を決定するためそれ自体の値のほかに、スーパーピアである近隣ネットワーク機能を有するエンティティの関連した値を使用して、平均ルックアップレート(R)と、平均グループ・サイズ(M)と、共有アイテムの平均数(F)と、スーパーピアの平均容量(C)とを推定するようになっている、請求項1〜1のいずれかに記載のネットワーク機能を有するエンティティ。
  17. 階層的ピアツーピア・ネットワークにおいて、現存スーパーピア数から要求されるスーパーピアの数へのスーパーピアの調節を推定する推定器(14)であって、前記スーパーピアの調節は実際のシステム負荷因子(L)の推定と所望のシステム負荷因子(L des )との比較の結果に依存し、ここで、前記所望のシステム負荷因子(L des )は100%よりも小さい値に設定され、前記実際のシステム負荷因子(L)の前記推定は、前記階層的ピアツーピア・ネットワークに実際に存在しているスーパーピアの数である現存スーパーピア数(N sp )の推定に依存する、推定器と、
    前記必要スーパーピア数(N sp)が前記現存スーパーピア数(Nspの前記推定よりも小さい場合に、ネットワーク機能を有するエンティティ(10)の特性としてのスーパーピアを停止させるコントローラ(16)と
    を備えるネットワーク機能を有するエンティティ(10)。
  18. 階層的ピアツーピア・ネットワークにおいて実際に存在しているスーパーピアの数である現存スーパーピア数を推定するステップ(S11)と、
    前記推定された現存スーパーピア数(Nsp)に基づいて、実際のシステム負荷因子(L)を推定するステップ(S13)と、
    前記実際のシステム負荷因子(L)の前記推定を所望のシステム負荷因子(L des )に比較するステップであって、前記所望のシステム負荷因子(L des )は100%よりも小さい値に設定された、比較するステップと、
    前記比較の結果に基づいて、現存スーパーピア数から、前記階層的ピアツーピア・ネットワークにおいて要求される必要スーパーピア数へのスーパーピアの調節を推定するステップ(S15)と、
    前記必要スーパーピア数(N sp)が、前記現存スーパーピア数(Nspの前記推定よりも大きい場合に、前記ネットワーク機能を有する他のエンティティを昇格させてスーパーピアにするステップ(S21)と
    を含むネットワーク機能を有するエンティティを動作させる方法。
  19. 階層的ピアツーピア・ネットワークにおいて実際に存在しているスーパーピアの数である現存スーパーピア数を推定するステップ(S11)と、
    前記推定された現存スーパーピア数(Nsp)に基づいて、実際のシステム負荷因子(L)を推定するステップ(S13)と、
    前記実際のシステム負荷因子(L)の前記推定を所望のシステム負荷因子(L des )に比較するステップであって、前記所望のシステム負荷因子(L des )は100%よりも小さい値に設定された、比較するステップと、
    前記比較の結果に基づいて、現存スーパーピア数から、前記階層的ピアツーピア・ネットワークにおいて要求される必要スーパーピア数へのスーパーピアの調節を推定するステップ(S15)と、
    前記必要スーパーピア数(N sp)が、前記現存スーパーピア数(Nspの前記推定よりも小さい場合に、前記ネットワーク機能を有するエンティティの特性としてのスーパーピアを停止させるステップ(S22)と
    を含むネットワーク機能を有するエンティティを動作させる方法。
  20. コンピュータ・プログラムがコンピュータ及び/又はマイクロコントローラにおいて実行するとき、請求項1又は19に記載の方法の1つを遂行するコンピュータ・プログラム。
JP2008217608A 2007-08-29 2008-08-27 階層的ピアツーピア・ネットワークの最適運用 Expired - Fee Related JP4652435B2 (ja)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
EP07016954A EP2031816B1 (en) 2007-08-29 2007-08-29 Optimal operation of hierarchical peer-to-peer networks

Publications (2)

Publication Number Publication Date
JP2009089369A JP2009089369A (ja) 2009-04-23
JP4652435B2 true JP4652435B2 (ja) 2011-03-16

Family

ID=38653565

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2008217608A Expired - Fee Related JP4652435B2 (ja) 2007-08-29 2008-08-27 階層的ピアツーピア・ネットワークの最適運用

Country Status (4)

Country Link
US (1) US20090234917A1 (ja)
EP (1) EP2031816B1 (ja)
JP (1) JP4652435B2 (ja)
CN (1) CN101378409B (ja)

Families Citing this family (46)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7603464B2 (en) * 2003-06-04 2009-10-13 Sony Computer Entertainment Inc. Method and system for identifying available resources in a peer-to-peer network
US8782654B2 (en) 2004-03-13 2014-07-15 Adaptive Computing Enterprises, Inc. Co-allocating a reservation spanning different compute resources types
WO2005089241A2 (en) 2004-03-13 2005-09-29 Cluster Resources, Inc. System and method for providing object triggers
US20070266388A1 (en) 2004-06-18 2007-11-15 Cluster Resources, Inc. System and method for providing advanced reservations in a compute environment
US8176490B1 (en) 2004-08-20 2012-05-08 Adaptive Computing Enterprises, Inc. System and method of interfacing a workload manager and scheduler with an identity manager
US8271980B2 (en) 2004-11-08 2012-09-18 Adaptive Computing Enterprises, Inc. System and method of providing system jobs within a compute environment
US8863143B2 (en) 2006-03-16 2014-10-14 Adaptive Computing Enterprises, Inc. System and method for managing a hybrid compute environment
US8631130B2 (en) 2005-03-16 2014-01-14 Adaptive Computing Enterprises, Inc. Reserving resources in an on-demand compute environment from a local compute environment
US9231886B2 (en) 2005-03-16 2016-01-05 Adaptive Computing Enterprises, Inc. Simple integration of an on-demand compute environment
CA2603577A1 (en) 2005-04-07 2006-10-12 Cluster Resources, Inc. On-demand access to compute resources
US8300798B1 (en) 2006-04-03 2012-10-30 Wai Wu Intelligent communication routing system and method
US8041773B2 (en) 2007-09-24 2011-10-18 The Research Foundation Of State University Of New York Automatic clustering for self-organizing grids
KR101422213B1 (ko) * 2007-11-23 2014-07-22 삼성전자 주식회사 단말의 능력을 기초로 역할을 설정하는 장치 및 그 방법
US8228822B2 (en) * 2009-03-03 2012-07-24 Cisco Technology, Inc. Hierarchical flooding among peering overlay networks
EP2234375A1 (en) * 2009-03-24 2010-09-29 Thomson Licensing device and method for controlling dissemination of content data between peers in a P2P mode, by using a two-level randomized peer overlay and a dynamic unchoke mechanism
US8082331B2 (en) * 2009-04-07 2011-12-20 International Business Machines Corporation Optimized multicasting using an interest-aware membership service
US8769055B2 (en) * 2009-04-24 2014-07-01 Microsoft Corporation Distributed backup and versioning
US8560639B2 (en) * 2009-04-24 2013-10-15 Microsoft Corporation Dynamic placement of replica data
US8769049B2 (en) 2009-04-24 2014-07-01 Microsoft Corporation Intelligent tiers of backup data
US8935366B2 (en) * 2009-04-24 2015-01-13 Microsoft Corporation Hybrid distributed and cloud backup architecture
US20100293223A1 (en) * 2009-05-18 2010-11-18 Cisco Technology, Inc. Limiting storage messages in peer to peer network
US9325787B2 (en) * 2009-05-18 2016-04-26 Cisco Technology, Inc. Limited broadcast, peering among DHTs, broadcast put of limited content only
EP2264954B1 (en) * 2009-06-18 2012-02-01 Alcatel Lucent Method and apparatus for congestion control
US11720290B2 (en) 2009-10-30 2023-08-08 Iii Holdings 2, Llc Memcached server functionality in a cluster of data processing nodes
US10877695B2 (en) 2009-10-30 2020-12-29 Iii Holdings 2, Llc Memcached server functionality in a cluster of data processing nodes
CN102577241B (zh) * 2009-12-31 2014-07-30 华为技术有限公司 分布式缓存资源调度的方法、装置及系统
EP2545693A1 (en) * 2010-03-12 2013-01-16 Telefonaktiebolaget LM Ericsson (publ) Load balancing method and system for peer-to-peer networks
CN102378409B (zh) * 2010-08-26 2013-03-27 中国人民解放军国防科学技术大学 一种物联网中的层次式Chord分组网络及其组织方法
US8806049B2 (en) * 2011-02-15 2014-08-12 Peerialism AB P2P-engine
JP5477325B2 (ja) * 2011-04-05 2014-04-23 ブラザー工業株式会社 情報処理装置、プログラム、配信システム、及び情報提供方法
EP2697951B1 (en) * 2011-04-13 2016-03-02 Telefonaktiebolaget LM Ericsson (publ) Load balancing mechanism for service discovery mechanism in structured peer-to-peer overlay networks and method
US8762534B1 (en) * 2011-05-11 2014-06-24 Juniper Networks, Inc. Server load balancing using a fair weighted hashing technique
US8898327B2 (en) 2011-10-05 2014-11-25 Peerialism AB Method and device for arranging peers in a live streaming P2P network
US8713194B2 (en) 2011-11-18 2014-04-29 Peerialism AB Method and device for peer arrangement in single substream upload P2P overlay networks
US8799498B2 (en) 2011-11-18 2014-08-05 Peerialism AB Method and device for peer arrangement in streaming-constrained P2P overlay networks
US8977660B1 (en) * 2011-12-30 2015-03-10 Emc Corporation Multi-level distributed hash table for data storage in a hierarchically arranged network
US9659105B2 (en) * 2012-03-15 2017-05-23 The Nielsen Company (Us), Llc Methods and apparatus to track web browsing sessions
US9680926B2 (en) * 2012-12-19 2017-06-13 Hive Streaming Ab Nearest peer download request policy in a live streaming P2P network
US9591070B2 (en) 2012-12-19 2017-03-07 Hive Streaming Ab Multiple requests for content download in a live streaming P2P network
US9544366B2 (en) 2012-12-19 2017-01-10 Hive Streaming Ab Highest bandwidth download request policy in a live streaming P2P network
US20140189082A1 (en) * 2012-12-28 2014-07-03 Futurewei Technologies, Inc. Local Partitioning in a Distributed Communication System
US9294563B2 (en) * 2013-02-27 2016-03-22 Omnivision Technologies, Inc. Apparatus and method for level-based self-adjusting peer-to-peer media streaming
US10165047B2 (en) * 2013-03-15 2018-12-25 Google Technology Holdings LLC Methods and apparatus for transmitting service information in a neighborhood of peer-to-peer communication groups
US9392054B1 (en) * 2013-05-31 2016-07-12 Jisto Inc. Distributed cloud computing platform and content delivery network
US10148748B2 (en) * 2015-02-26 2018-12-04 Microsoft Technology Licensing, Llc Co-locating peer devices for peer matching
CN108599975A (zh) * 2018-01-31 2018-09-28 宋星 一种智能楼宇管理系统

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH0991254A (ja) * 1995-09-20 1997-04-04 Nec Corp 消費電力低減制御システム及びその方法
JP2005309530A (ja) * 2004-04-16 2005-11-04 Ntt Docomo Inc 役割割当システム及び役割割当方法並びにノード
JP2006101277A (ja) * 2004-09-30 2006-04-13 Brother Ind Ltd 情報通信システム、ノード装置、及びオーバーレイネットワーク形成方法等
JP2006246225A (ja) * 2005-03-04 2006-09-14 Nippon Telegr & Teleph Corp <Ntt> P2pネットワークシステムにおける分散ハッシュ管理方法および装置
JP2007174672A (ja) * 2005-12-21 2007-07-05 Ntt Docomo Inc ピアツーピアルックアップシステムに対するモビリティチャーン処理のための方法および装置

Family Cites Families (39)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5001628A (en) * 1987-02-13 1991-03-19 International Business Machines Corporation Single system image uniquely defining an environment for each user in a data processing system
US5131041A (en) * 1989-11-30 1992-07-14 At&T Bell Laboratories Fault tolerant interconnection networks
US5611049A (en) * 1992-06-03 1997-03-11 Pitts; William M. System for accessing distributed data cache channel at each network node to pass requests and data
US6026452A (en) * 1997-02-26 2000-02-15 Pitts; William Michael Network distributed site cache RAM claimed as up/down stream request/reply channel for storing anticipated data and meta data
JP2501771B2 (ja) * 1993-01-19 1996-05-29 インターナショナル・ビジネス・マシーンズ・コーポレイション 不所望のソフトウェア・エンティティの複数の有効なシグネチャを得る方法及び装置
US5394526A (en) * 1993-02-01 1995-02-28 Lsc, Inc. Data server for transferring selected blocks of remote file to a distributed computer network involving only single data transfer operation
US5493728A (en) * 1993-02-19 1996-02-20 Borland International, Inc. System and methods for optimized access in a multi-user environment
US5737536A (en) * 1993-02-19 1998-04-07 Borland International, Inc. System and methods for optimized access in a multi-user environment
JP3415914B2 (ja) * 1993-10-12 2003-06-09 富士通株式会社 並列マージソート処理方法
US5491810A (en) * 1994-03-01 1996-02-13 International Business Machines Corporation Method and system for automated data storage system space allocation utilizing prioritized data set parameters
JPH08107462A (ja) * 1994-08-11 1996-04-23 Shosaku Kawai 通信ネットワーク構造及びそれを基礎とした通信ネットワークシステム並びにその通信方法
US5713017A (en) * 1995-06-07 1998-01-27 International Business Machines Corporation Dual counter consistency control for fault tolerant network file servers
US5623600A (en) * 1995-09-26 1997-04-22 Trend Micro, Incorporated Virus detection and removal apparatus for computer networks
US6311265B1 (en) * 1996-03-25 2001-10-30 Torrent Systems, Inc. Apparatuses and methods for programming parallel computers
US5909681A (en) * 1996-03-25 1999-06-01 Torrent Systems, Inc. Computer system and computerized method for partitioning data for parallel processing
US5831975A (en) * 1996-04-04 1998-11-03 Lucent Technologies Inc. System and method for hierarchical multicast routing in ATM networks
US6128647A (en) * 1996-04-05 2000-10-03 Haury; Harry R. Self configuring peer to peer inter process messaging system
US6014686A (en) * 1996-06-21 2000-01-11 Telcordia Technologies, Inc. Apparatus and methods for highly available directory services in the distributed computing environment
US5862346A (en) * 1996-06-28 1999-01-19 Metadigm Distributed group activity data network system and corresponding method
US5920697A (en) * 1996-07-11 1999-07-06 Microsoft Corporation Method of automatic updating and use of routing information by programmable and manual routing information configuration based on least lost routing
GB9614927D0 (en) * 1996-07-16 1996-09-04 British Telecomm Arranging data signals defining a network
US5884046A (en) * 1996-10-23 1999-03-16 Pluris, Inc. Apparatus and method for sharing data and routing messages between a plurality of workstations in a local area network
JP3222086B2 (ja) * 1997-04-07 2001-10-22 矢崎総業株式会社 ツリー構造のアドレス設定方法及びそのシステム
US6119165A (en) * 1997-11-17 2000-09-12 Trend Micro, Inc. Controlled distribution of application programs in a computer network
US6023586A (en) * 1998-02-10 2000-02-08 Novell, Inc. Integrity verifying and correcting software
US6108703A (en) * 1998-07-14 2000-08-22 Massachusetts Institute Of Technology Global hosting system
US6311206B1 (en) * 1999-01-13 2001-10-30 International Business Machines Corporation Method and apparatus for providing awareness-triggered push
GB2350449A (en) * 1999-05-27 2000-11-29 Ibm Detecting replication of a computer virus using a counter virus
US6891802B1 (en) * 2000-03-30 2005-05-10 United Devices, Inc. Network site testing method and associated system
AU2002236435A1 (en) * 2000-10-26 2002-05-21 Prismedia Networks, Inc. Method and apparatus for real-time parallel delivery of segments of a large payload file
US7003767B2 (en) * 2001-10-02 2006-02-21 International Business Machines Corp. System and method for remotely updating software applications
US6986050B2 (en) * 2001-10-12 2006-01-10 F-Secure Oyj Computer security method and apparatus
US6966059B1 (en) * 2002-03-11 2005-11-15 Mcafee, Inc. System and method for providing automated low bandwidth updates of computer anti-virus application components
JP2005523640A (ja) * 2002-04-19 2005-08-04 コンピュータ アソシエイツ シンク,インコーポレイテッド エンタプライズにおけるワイヤレス装置を管理するシステム及び方法
US20050064859A1 (en) * 2003-09-23 2005-03-24 Motorola, Inc. Server-based system for backing up memory of a wireless subscriber device
US20050273853A1 (en) * 2004-05-24 2005-12-08 Toshiba America Research, Inc. Quarantine networking
US7540013B2 (en) * 2004-06-07 2009-05-26 Check Point Software Technologies, Inc. System and methodology for protecting new computers by applying a preconfigured security update policy
US7577721B1 (en) * 2004-06-08 2009-08-18 Trend Micro Incorporated Structured peer-to-peer push distribution network
CN100364281C (zh) * 2006-03-24 2008-01-23 南京邮电大学 基于对等网络的分布式流量管理方法

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH0991254A (ja) * 1995-09-20 1997-04-04 Nec Corp 消費電力低減制御システム及びその方法
JP2005309530A (ja) * 2004-04-16 2005-11-04 Ntt Docomo Inc 役割割当システム及び役割割当方法並びにノード
JP2006101277A (ja) * 2004-09-30 2006-04-13 Brother Ind Ltd 情報通信システム、ノード装置、及びオーバーレイネットワーク形成方法等
JP2006246225A (ja) * 2005-03-04 2006-09-14 Nippon Telegr & Teleph Corp <Ntt> P2pネットワークシステムにおける分散ハッシュ管理方法および装置
JP2007174672A (ja) * 2005-12-21 2007-07-05 Ntt Docomo Inc ピアツーピアルックアップシステムに対するモビリティチャーン処理のための方法および装置

Also Published As

Publication number Publication date
EP2031816A1 (en) 2009-03-04
CN101378409A (zh) 2009-03-04
US20090234917A1 (en) 2009-09-17
JP2009089369A (ja) 2009-04-23
CN101378409B (zh) 2012-04-25
EP2031816B1 (en) 2012-02-22

Similar Documents

Publication Publication Date Title
JP4652435B2 (ja) 階層的ピアツーピア・ネットワークの最適運用
US7174382B2 (en) Interest-based connections in peer-to-peer networks
Mirkovic et al. A survey of round trip time prediction systems
CN111046065B (zh) 可扩展的高性能分布式查询处理方法及装置
Zöls et al. On hierarchical DHT systems–An analytical approach for optimal designs
KR101422213B1 (ko) 단말의 능력을 기초로 역할을 설정하는 장치 및 그 방법
WO2010127618A1 (zh) 一种实现流媒体内容服务的系统和方法
CN110866046B (zh) 一种可扩展的分布式查询方法及装置
WO2007014745A1 (en) A communication network, a method of routing data packets in such communication network and a method of locating and securing data of a desired resource in such communication network
Zhong et al. The convergence-guaranteed random walk and its applications in peer-to-peer networks
Sacha et al. Discovery of stable peers in a self-organising peer-to-peer gradient topology
Sacha et al. Decentralising a service-oriented architecture
Shen et al. A proximity-aware interest-clustered P2P file sharing system
JP4533923B2 (ja) 階層型ピアツーピアシステムにおける負荷バランシング機能を有するスーパーピア及び該スーパーピアを動作させる方法
Graffi et al. Skyeye. kom: An information management over-overlay for getting the oracle view on structured p2p systems
Kanemitsu et al. KadRTT: Routing with network proximity and uniform ID arrangement in Kademlia
Graffi et al. SkyEye: A tree-based peer-to-peer monitoring approach
Jin et al. Novel approaches to efficient flooding search in peer-to-peer networks
Zhang et al. Capacity-aware multicast algorithms on heterogeneous overlay networks
Shi et al. Popularity adaptive search in hybrid P2P systems
Chung et al. Direction-aware resource discovery service in large-scale grid and cloud computing
Högqvist et al. Passive/active load balancing with informed node placement in dhts
SEQUEIRA GENERAL PURPOSE SEARCH IN LARGE-SCALE UNSTRUCTRED OVERLAY NETWORKS
Abdeljaouad et al. A game-theoretic approach for dynamic and adaptive managers selection in service specific overlay networks
Li et al. A construction of SIP based peer-to-peer network and performance analysis

Legal Events

Date Code Title Description
A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20100712

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20100721

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20100921

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20101203

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20101215

R150 Certificate of patent or registration of utility model

Free format text: JAPANESE INTERMEDIATE CODE: R150

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20131224

Year of fee payment: 3

LAPS Cancellation because of no payment of annual fees