JP2012514278A - インデックスサーバとその方法 - Google Patents

Abstract

ピアツーピア・ネットワークのインデックスサーバとその方法を提供する。
ピアツーピア・ネットワークのインデックスサーバは、データファイルと関連するエントリであって、該データファイルを提供するサーバと該サーバの位置を示す複数の情報項目を含む１以上のエントリを格納するメタデータ記憶ユニットと、メタデータ記憶ユニットを監視して情報項目の数がしきい値を越える、メタデータ記憶ユニット内に格納されたエントリを識別し、識別されたエントリ内に含まれる情報項目の一部分であって、その位置が互いに接近しているノードを示すノード情報項目を可能な限り多く含む一部分を他のサーバに転送するノード情報管理ユニットとを含む。

Description

本発明は、一般にピアツーピア（Ｐ２Ｐ）ネットワークに関し、特に、Ｐ２Ｐネットワークのインデックスサーバとその方法に関する。

Ｐ２Ｐネットワークは、アドホック方式で複数のユーザによって形成される分散型ネットワークである。これらのユーザは「ノード」と称される。ノードは、データファイル、計算能力、記憶性能および帯域幅などの様々なリソースを共有することが可能である。データファイル（以下、データあるいはファイルとも称される）は、画像ファイル、オーディオファイル、ビデオファイルなどを含んでいる。ノードがファイルをダウンロードしたい場合、Ｐ２Ｐネットワーク内のどのノードがそのファイルを有するか、すなわち、どのノードがそのファイルを提供できるかを知らなければならない。既存のＰ２Ｐシステムは、通常、ファイルのメタデータを格納するために集中型のインデックスサーバを用いる。ファイルのメタデータは、ファイルの属性、例えばそのファイルのサイズやそのファイルを提供可能なノードを記述する。このメタデータはファイルを提供可能なノードによってインデックスサーバに報告される。ファイルをダウンロードしたいノード（要求側ノード）から要求を受信すると、インデックスサーバは、情報のメタデータを参照することにより、ファイルを提供可能なノードのサブセット（部分集合）を要求側ノードに通知する。その後、要求側ノードとノードのサブセットの間でファイルの送信が発生する。

通常、既存のインデックスサーバは、要求側ノードに通知するそのようなサブセットをランダムに選択する。そのようなランダムな応答は、重大な「クロスＩＳＰトラフィック（ｃｒｏｓｓ−ＩＳＰ ｔｒａｆｆｉｃ）」問題を引き起こす。すなわち、第１のインターネット・サービス・プロバイダ（ＩＳＰ）ＩＳＰ１によって提供されるノード、言いかえればＩＳＰ１内のノードは、たとえＩＳＰ１内の他のノードがダウンロード可能なデータを有しても、ＩＳＰ２内のノードからデータをダウンロードしてしまう。

クロスＩＳＰトラフィックを減少するため、位置認識記憶構造（ｌｏｃａｔｉｏｎ−ａｗａｒｅ ｓｔｏｒａｇｅ ｓｔｒｕｃｔｕｒｅ）が、大規模Ｐ２Ｐネットワークシステムにおいてメタデータを格納するために提案されている。

大規模Ｐ２Ｐネットワークにおけるメタデータ情報の記憶と検索の問題について、以下に説明する。

サイズＯ（Ｎ×Ｄ）のメタデータ・テーブルを仮定する。ここで、ＤはＰ２Ｐネットワークにおいて共有されるファイルの合計数であり、ＮはＰ２Ｐネットワーク内のノードの合計数である。メタデータ・テーブルは、Ｄ個のファイルにそれぞれ関連するＤ個のメタデータを含んでいる。
以下、１つのファイルに関連する１つのメタデータを、例えば、「ファイルのメタデータ」あるいは「ファイルに関連するメタデータ・エントリ」と称する。メタデータ・エントリは、１以上のノード情報項目を含んでいる。各ノード情報項目はファイルを提供する１つのノードについて記述する。

１．複数のインデクシングサーバにそれぞれのファイルのメタデータ・エントリを拡張的な方法でどのように分配するか。

２．要求Ｒｅｑ（Ｍ、Ｄｉ、Ｔ）が要求側ノードから受信されるとき（ここで、Ｍは要求側ノードの標識（例えば、ＩＰアドレス）、Ｄｉは希望するファイルの標識、ＴはノードＭが取得することを望むファイルＤｉに関連するノード情報項目（例えば、ノードのアドレス）の数である）、応答は以下のように作成すべきである。
ｉ）メタデータ・テーブルにおけるファイルＤｉに関連するノード情報項目の数がＴより小さいか或いはＴと等しい場合、要求側ノードＭにできるだけ多くのノード情報項目を返す。
ｉｉ）メタデータ・テーブルにおけるファイルＤｉに関連するノード情報項目の数がＴより大きい場合、ファイルＤに関連するノード情報項目からＴ個のノード情報項目を選択する。選択されたＴ個のノード情報項目は、要求側ノードにできるだけ接近しているノードを示すべきである。

ここで、ノードの位置は、例えば、（ＩＳＰ，Ｒｅｇｉｏｎ）として定義され、ノードを提供するインターネット・サービス・プロバイダとノードの地理的エリアを示す。ノードと要求側ノードの間の「接近度」は以下のように定義される。２つのノードＡとＢについて、ノードＡが要求側ノードと同一のＩＳＰ内にあり、ノードＢがそうでなければ、ノードＡはノードＢより要求側ノードに接近している。
ノードＡとＢの両方が要求側ノードと同一のＩＳＰ内にあるか、或いはＡもＢも要求側ノードと同一のＩＳＰ内にない場合、およびノードＡが要求側ノードと同一のエリア内にあり、ノードＢがそうでなければ、ノードＡはノードＢより要求側ノードに接近している。
さらに、両方のノードＡとＢが、要求側ノードと同一のＩＳＰ及び同一のエリア内にある場合、あるいは、ノードＡとＢの両方が要求側ノードと異なるＩＳＰ及び異なるエリア内にある場合、ノードＡとＢは、要求側ノードへの「接近度」に関して任意に順序付けられる。

中国特許出願公開１０１３５５５９１(A)「Ｐ２Ｐネットワークとその調整方法」（特許文献１）においては、メタデータ・テーブルがファイル次元に分配される。
具体的には、複数のインデックスサーバがＤＨＴネットワークを形成する。各ファイルのメタデータは、ファイルのＩＤに従って対応するインデックスサーバ内に格納される。要求側ノードがデータファイルを要求している時、さらに具体的にはデータファイルを提供可能なノードに関する情報を要求している時、要求側ノードは自身のホームインデックスサーバ（ｈｏｍｅ ｉｎｄｅｘｉｎｇ ｓｅｒｖｅｒ）に要求を送信する。その要求は、ＤＨＴネットワーク内を経由して、ファイルのＩＤに基づいてファイルのメタデータを格納するために割り当てられている目的インデックスサーバ（ｄｅｓｔｉｎａｔｉｏｎ ｉｎｄｅｘｉｎｇ ｓｅｒｖｅｒ）に到着する。
目的インデックスサーバは、ホームインデックスサーバにファイルのメタデータを送信し、そして、ホームインデックスサーバは、要求側ノードに対する「接近度」に従ってメタデータによって示されるノードをソートし、Ｎ個の最も近いノードを要求側ノードに通知する。

具体的には、各インデックスサーバはローカルのフィンガーテーブル（Ｆｉｎｇｅｒ Ｔａｂｌｅ）を保持している。要求を受信すると、インデックスサーバは、フィンガーテーブル上でＤＨＴ探索（ＤＨＴ ｌｏｏｋｕｐ）を実行する。インデックスサーバが要求されたファイルのメタデータを格納していれば、ヒットが生じる。そうでなければ、フィンガーテーブルが、その要求を送る次のホップインデックスサーバ（ｈｏｐ ｉｎｄｅｘｉｎｇ ｓｅｒｖｅｒ）を示す。ＤＨＴアルゴリズムは、要求が経由するホップ数が、Ｏ（ｌｏｇ（ｎ））であることを保証する。ここで、ｎはＤＨＴネットワーク内のインデックスサーバの数である。
ＤＨＴアルゴリズムの実施詳細については、Ｉ． Ｓｔｏｉｃａ， Ｒ． Ｍｏｒｒｉｓ， Ｄ． Ｋａｒｇｅｒ， Ｍ． Ｆ． Ｋａａｓｈｏｅｋ， ａｎｄ Ｈ． Ｂａｌａｋｒｉｓｈｎａｎ， Ｃｈｏｒｄ： Ａ Ｓｃａｌａｂｌｅ Ｐｅｅｒ−ｔｏ−ｐｅｅｒ Ｌｏｏｋｕｐ Ｓｅｒｖｉｃｅ ｆｏｒ Ｉｎｔｅｒｎｅｔ Ａｐｐｌｉｃａｔｉｏｎｓ， Ｉｎ Ｐｒｏｃｅｅｄｉｎｇｓ ｏｆ ＳＩＧＣＯＭＭ ２００１， Ｓａｎ Ｄｅｉｇｏ， ＣＡ， Ａｕｇｕｓｔ ２００１（非特許文献１）に記載されている。

中国特許出願公開１０１３５５５９１(A)

Ｉ． Ｓｔｏｉｃａ， Ｒ． Ｍｏｒｒｉｓ， Ｄ． Ｋａｒｇｅｒ， Ｍ． Ｆ． Ｋａａｓｈｏｅｋ， ａｎｄ Ｈ． Ｂａｌａｋｒｉｓｈｎａｎ， Ｃｈｏｒｄ： Ａ Ｓｃａｌａｂｌｅ Ｐｅｅｒ−ｔｏ−ｐｅｅｒ Ｌｏｏｋｕｐ Ｓｅｒｖｉｃｅ ｆｏｒ Ｉｎｔｅｒｎｅｔ Ａｐｐｌｉｃａｔｉｏｎｓ， Ｉｎ Ｐｒｏｃｅｅｄｉｎｇｓ ｏｆ ＳＩＧＣＯＭＭ ２００１， Ｓａｎ Ｄｅｉｇｏ， ＣＡ， Ａｕｇｕｓｔ ２００１

以上から分かるように、データファイルを提供するＰ２Ｐネットワーク内のノードの数がますます多くなるに従い、対応するインデックスサーバ内に格納されるデータファイルに関連するメタデータ・エントリのサイズがそれに応じて増大する。
例えば、ＰＰＬｉｖｅ（Ｇａｌｅ Ｈｕａｎｇ， ＰＰＬｉｖｅ − Ａ Ｐｒａｃｔｉｃａｌ Ｐ２Ｐ Ｌｉｖｅ Ｓｙｓｔｅｍ ｗｉｔｈ Ｈｕｇｅ Ａｍｏｕｎｔ ｏｆ Ｕｓｅｒｓ）の運用データによる報告によれば、２００５年に人気のテレビ番組「Ｓｕｐｅｒ Ｇｉｒｌ」のオンライン生中継ビデオを観たユーザはピーク時に２５万人以上であった。
よって、「Ｓｕｐｅｒ Ｇｉｒｌ」生中継ビデオのデータファイルのノード情報を格納するのに割り当てられている１つのサーバ内にこれらのすべてのユーザ（ノード）に関する情報を格納することは非常に難しい。
それと同時に、データファイルに関連するノード情報についての要求を要求側ノードから受信した時、サーバは、データファイルを提供する全てのノードを位置に応じてソートするのに多くの時間を費やさなければならず、このことが、要求側ノードに対する応答において許容し難い遅延を引き起こす。

そのため、効率的な方法でＰ２Ｐネットワークのメタデータを格納し検索することができるインデックスサーバとそれを動作させる方法が必要となる。

本発明は、上記の課題を解決するインデックスサーバとその方法を提供することを目的とする。

本発明の好ましい形態による、ピアツーピア・ネットワークのインデックスサーバは、データファイルと関連するエントリであって、該データファイルを提供するサーバと該サーバの位置を示す複数の情報項目を含む１以上のエントリを格納するメタデータ記憶ユニットと、メタデータ記憶ユニットを監視して情報項目の数がしきい値を越える、メタデータ記憶ユニット内に格納されたエントリを識別し、識別されたエントリ内に含まれる情報項目の一部分であって、その位置が互いに接近しているノードを示すノード情報項目を可能な限り多く含む一部分を他のサーバに転送するノード情報管理ユニットとを備える。

本発明のこの好ましい形態による、データファイルと関連するエントリであって、該データファイルを提供するサーバと該サーバの位置を示す複数の情報項目を含む１以上のエントリを格納するメタデータ記憶ユニットを含む、ピアツーピア・ネットワークのインデックスサーバによる方法は、情報項目の数がしきい値を越える、メタデータ記憶ユニット内に格納されたエントリを識別するために、メタデータ記憶ユニットを監視するステップと、識別されたエントリ内に含まれる情報項目の一部分であって、その位置が互いに接近しているノードを示すノード情報項目を可能な限り多く含む一部分を他のサーバに転送するステップとを含む。

本発明によれば、効率的な方法でＰ２Ｐネットワークのメタデータを格納し検索することができるインデックスサーバを提供することができる。

本発明の上記および他の特徴、並びに効果は、図面を参照して説明された下記の好適な実施例からさらに明らかになるであろう。添付図面において、同一の又は類似する参照符号は、同一又は類似する構成要素を示している。
本発明の第１の実施の形態によるインデックスサーバを示すブロック図である。 第１の実施の形態のインデックスサーバのノード情報管理ユニットの動作を示すフローチャートである。 第１の実施の形態によるインデックスサーバのメッセージ処理ユニット、ノード情報検索ユニット、および他の構成要素の動作を示すフローチャートである。 第１の実施の形態のインデックスサーバのノード情報検索ユニットによる動作の詳細を説明するフローチャートである。 本発明の第２の実施の形態によるインデックスサーバを示すブロック図である。 第２の実施の形態によるインデックスサーバのメッセージ処理ユニット、ノード情報検索ユニット、ＤＨＴ探索ユニット、および他の構成要素の動作を示すフローチャートである。 本発明の第３の実施の形態によるインデックスサーバを示すブロック図である。 第３の実施の形態によるインデックスサーバのメッセージ処理ユニットと他の構成要素の動作を示すフローチャートである。

以下、本発明の実施の形態について、図面を参照して詳細に説明する。

図１は、本発明の第１の実施の形態によるインデックスサーバ１００を示すブロック図である。図２は、第１の実施の形態のインデックスサーバ１００のノード情報管理ユニット１０２の動作を示すフローチャートである。図３は、第１の実施の形態によるインデックスサーバ１００のメッセージ処理ユニット１０４、ノード情報検索ユニット１０５及び他の構成要素の動作を示すフローチャートである。図４は、第１の実施の形態のインデックスサーバ１００のノード情報検索ユニット１０５の動作をさらに詳細に説明するフローチャートである。以下、インデックスサーバ１００の構成と動作について、図１〜図４と関連して説明する。

インデックスサーバ１００は、メタデータ記憶ユニット１０１、ノード情報管理ユニット１０２、転送ログ記憶ユニット１０３、メッセージ処理ユニット１０４およびノード情報検索ユニット１０５を含んでいる。

メタデータ記憶ユニット１０１は、Ｐ２Ｐネットワークについてのメタデータを格納する。特に、インデックスサーバ１００は、Ｐ２Ｐネットワークにおいて共有される１以上のデータファイルと関連付するメタデータを格納するために配置される。当業者であれば、データファイルと関連するメタデータを格納するためのインデックスサーバを配置する種々の方法を十分に理解するであろう。その１つは、上記背景技術と次に述べる第２の実施の形態において説明するように、ＤＨＴネットワークにおけるようにデータファイルのＩＤに基づいてデータファイルを格納するためのインデックスサーバを決定することである。しかし、本発明は、特定のデータファイルのメタデータを格納するためのインデックスサーバを割り当て、指定し、決定する何れの特定の方法にも限定されない。

より具体的には、メタデータ記憶ユニット１０１は、１以上のメタデータ・エントリを格納する。各メタデータ・エントリは、１以上のデータファイル内の異なるデータファイルの１つと関連している。各エントリは、１以上のノード情報項目を含んでいる。各ノード情報項目は、関連するデータファイルを提供することが知られているノードとそのノードの位置を示している。
例えば、メタデータ記憶ユニット１０１に格納されるエントリは、以下ようなの形式をとる。
ｄａｔａ＿ｉｄ： ｎｏｄｅ＿ｉｄ１（ｉｐ１， ｐｏｒｔ１， ｌｏｃａｔｉｏｎ１）， ｎｏｄｅ＿ｉｄ２（ｉｐ２， ｐｏｒｔ２， ｌｏｃａｔｉｏｎ２）， …，
ここで、ｄａｔａ＿ｉｄは、エントリと関連するデータファイルの識別子（ＩＤ）である。ｎｏｄｅ＿ｉｄ１（ｉｐ１、ｐｏｒｔ１、ｌｏｃａｔｉｏｎ１）は、データファイルを提供するノードを示すノード情報項目である。ノードのＩＤがｎｏｄｅ＿ｉｄ１である場合、ノードのアドレスは（ｉｐ１、ｐｏｒｔ１）であり、ノードの位置はｌｏｃａｔｉｏｎ１である。
上述のように、ノードの位置は、（ＩＳＰ，Ｒｅｇｉｏｎ）として定義される。

当業者であれば、データファイルのメタデータがファイルの他の属性についての情報（例えば、ファイルのサイズ）を含むことを十分に理解するであろう。これらの属性については、説明を分かり易くするためにここでは省略する。

ノード情報管理ユニット１０２は、ノード情報項目の数がしきい値を越えるエントリがメタデータ記憶ユニットに格納されているかどうかを判定するためにメタデータ記憶ユニット１０を監視し、肯定的な判定に応じて、ノード情報項目の一部分を他のサーバに転送する。この転送される一部分は、その位置が互いに接近しているノードを示すノード情報項目を可能な限り多く含んでいる。

図２において、ノード情報管理ユニット１０２の動作を詳細に説明する。図２に示すように、ステップＳ１０１において、ノード情報管理ユニット１０２は、常時あるいは周期的に、メタデータ記憶ユニット１０１を監視し、ノード情報項目の数がしきい値を越えるエントリがメタデータ記憶ユニットに格納されているかどうかを判定する。言い換えれば、メタデータの記憶をインデックスサーバ１００に割り当てているデータファイルを提供するサーバの数が閾値を越えているかどうかを判定する。

判定の結果が否定的ならば、処理はステップＳ１０１に戻り、ノード情報管理ユニット１０２がメタデータ記憶ユニット１０１の監視を継続する。そうでなければ、処理はステップＳ１０３に進む。

例えば、データファイルＤ１と関連するメタデータ・エントリを格納するために、インデックスサーバ１００が割り当てられると仮定する。データファイルＤ１を提供することが可能なＰ２Ｐネットワーク内のノードの数が次第に多くなると、メタデータ記憶ユニット１０１に格納されたデータファイルＤ１に関連するエントリのノード情報項目の数が、しきい値（例えば、ＴＨ１）を超える。

この場合、ステップＳ１０３において、ノード情報管理ユニット１０２は、転送処理を開始する。この処理において、ノード情報項目の数が多くなりすぎたエントリのノード情報項目の一部分あるいは全てが、他の負荷の小さなサーバに転送される。
この転送される一部分は、その位置が互いに接近しているノードを示すノード情報項目を可能な限り多く含んでいる。

例えば、ノード情報管理ユニット１０２は、各グループが異なるＩＳＰ内のノードを示すノード情報項目を含むように、エントリに含まれるノード情報項目を、ＩＳＰに基づいて１以上のグループに分割する。
次いで、ノード情報管理ユニット１０２は、それぞれのグループ内のノード情報項目の数を確定し、１以上のグループ中でノード情報項目の数が最大のグループ（以下、最大グループと称する）を識別する。
その後、ノード情報管理ユニット１０２は、最大グループ内のノード情報項目の数がしきい値（例えば、しきい値ＴＨ１）より大きいかどうかを判定する。
判定結果が否定的ならば、ノード情報管理ユニット１０２は、そのグループのノード情報項目をインデックスサーバ１００から負荷が小さいと判定される他のインデックスサーバ（言いかえれば、現時点で、余り多くのノード情報を格納していない他のインデックスサーバ）へ転送する。
当業者であれば、そのような負荷の小さなサーバを判定するのに様々な方法があることを理解するであろう。本発明はどのような特定な方法にも限定されない。
簡単でかつ効果的な方法の例として、インデックスサーバ１００が、インデックスサーバ１００と同一のＰ２Ｐネットワーク上で動作するインデックスサーバのリストから２つの他のインデックスサーバをランダムに選択し、負荷のより小さい方をノード情報転送の宛先として選択する方法がある。

他方、最大グループ内のノード情報項目の数がしきい値より大きければ、ノード情報管理ユニット１０２は、さらに、最大グループに含まれるノード情報項目を、エリアに応じて１以上のサブグループに分割する（各サブグループが異なるエリアのノードを示すノード情報項目を含むように）。
その後、ノード情報管理ユニット１０２は、１以上のサブグループのうちノード情報項目の数が最大のサブグループを負荷の小さいサーバに転送する。
さらに、ノード情報管理ユニット１０２は、１以上の他の負荷の小さなサーバに他のサブグループを転送する。

最大のグループ内のノード情報項目が１以上の他のインデックスサーバに転送された後、エントリ中の残りのノード情報項目の数が、しきい値よりまだ大きければ、ノード情報管理ユニット１０２は、エントリ内の残りのノード情報項目の数がしきい値より小さくなるまで、残りのノード情報項目について上記の処理を繰り返す。

ノード情報管理ユニット１０２は、ノード情報項目の数がしきい値を越える、メタデータ記憶ユニット１０１内の他のエントリについて上記の処理を繰り返す。

図１へ戻ると、そこに示されるように、インデックスサーバ１００は、さらに、転送ログ記憶ユニット１０３を備えている。この転送ログ記憶ユニット１０３は、転送ログのテーブルを格納する。
これにより、ステップＳ１０３においてエントリのノード情報項目の一部分あるいは全てを他のサーバに転送する時、ステップＳ１０４において、ノード情報管理ユニット１０２は、転送ログ記憶ユニット１０３を更新する。

特に、ノード情報管理ユニット１０２は、転送ログが、転送された一部分と関連するデータファイル、その一部分が転送される他のサーバ、転送された一部分によって示されるノードの位置範囲（例えば、（ＩＳＰ，Ｒｅｇｉｏｎ））を反映するように、転送ログ記憶ユニット１０３内の転送ログを生成し又は更新する。

例えば、このテーブルとしては以下ような形式を用いる。

テーブル１は、データファイルＤ１を提供し、（ＩＳＰ１、Ｒ１）に位置する２０個のノードに関する情報がインデックスサーバＩＳ−Ｉに転送されていること、データファイルＤ１を提供し、（ＩＳＰ１、Ｒ２）に位置する１０個のノードに関する情報がインデックスサーバＩＳ−ＩＩに転送されていること、データファイルＤ１を提供し、（ＩＳＰ２、Ｒ１）に位置する５個のノードに関する情報がインデックスサーバＩＳ−ＩＩＩに転送されていること、データファイルＤ１を提供し、ＩＳＰ３に位置する１５個のノードに関する情報がインデックスサーバＩＳ−ＩＶに転送されていることを示している。
テーブル内の「ＭＲ」は、インデックスサーバＩＳ−ＩＶに転送された情報が、ＩＳＰ３と１以上のエリアにあるノードと関連していることを示している。

加えて、いくつかのノード情報項目が別のサーバに転送された後、転送されたノード情報項目と関連するデータファイルを提供し、その位置が転送されたノード情報項目によって示されるノードに接近しているノードを示すノード情報項目が将来的に受信されると、ノード情報管理ユニット１０２は、受信したノード情報項目をさらに別のサーバに転送し、それにより転送ログテーブルを更新する。
例えば、将来、インデックスサーバ１００が、（ＩＳＰ１、Ｒ１）にあるノードがデータファイルＤ１を提供することができることを示す情報（そのノードによって報告される）を受信すると、その情報は、インデックスサーバＩＳ−Ｉに転送され、そこに格納される。そして、例えば、テーブル１の第１行の数「２０」が「２１」に更新される。

更に、インデックスサーバ１００から転送されたノード情報を受信するインデックスサーバも、インデックスサーバ１００と同様、自身のメタデータ記憶ユニットを監視し転送処理を開始する。
上記の例を続けると、インデックスサーバ１００から転送されたノード情報を受信した後、インデックスサーバＩＳ−Ｉは、それらをデータファイルＤ１と関連するエントリとして自身のメタデータ記憶ユニットに格納する。
次いで、インデックスサーバＩＳ−Ｉは、常時あるいは周期的に自身のメタデータ記憶ユニットを監視する。そして、インデックスサーバＩＳ−Ｉは、自身のメタデータ記憶ユニットに格納される、Ｄ１と関連するエントリと、そのノード情報の格納がインデックスサーバＩＳ−Ｉに割り当てられているデータファイルと関連するエントリを含むエントリのうち、何れのエントリが非常に多くのノード情報項目を含んでいるかどうかを判定し、そのエントリ内のノード情報項目の負荷の小さなサーバへの転送を開始し、続いて自身の転送ログテーブルを更新する。

図１へ戻ると、インデックスサーバ１００は、さらにメッセージ処理ユニット１０４を含んでいる。メッセージ処理ユニット１０４は、インデックスサーバ１００の外部の装置から受信し、或いは外部の装置に送信するメッセージを処理する。例えば、受信したメッセージは、ノード情報に対する外部装置からの要求である可能性がある。この場合、メッセージ処理ユニット１０４は、要求を調べ、受信した要求のタイプを決定する。また、メッセージ処理ユニット１０４は、インデックスサーバ１００の他の構成要素に、受信したメッセージのタイプに基づいて対応した動作を実行させる。メッセージ処理ユニット１０４は、さらに、インデックスサーバ１００の他の構成要素によって指示される通りメッセージを作成し外部装置に送信する。この場合におけるメッセージ処理ユニット１０４と他の構成要素の動作について、図３を参照して以下に詳細に説明する。

図３に示すように、ステップＳ２０１において、メッセージ処理ユニット１０４は、外部装置から要求を受信するのを待ち、ステップＳ２０２において、メッセージ処理ユニット１０４は、要求を受信したかどうかを判定する。受信していなければ、ステップＳ２０１に戻り、受信していれば、ステップＳ２０３において、メッセージ処理ユニット１０４は、要求のタイプを決定する処理を行う。

具体的には、外部装置は、Ｐ２Ｐネットワーク内の、以下のようなノード（要求側ノード）である。Ｐ２Ｐネットワークにおいて他のノード（要求側ノードのピア）からデータファイルをダウンロードすることを希望し、どのノードがそのデータファイルを提供可能であるかを知る必要のあるノード。

外部装置が要求ノードである場合、その要求は、指定されたデータファイルを提供するノードの数Ｔに関する情報を対象として要求側ノードによってなされ、要求側ノードから直接的にあるいは他の中間の装置を介して間接的にインデックスサーバ１００によって受信されるノード情報要求である。
以下、図３に示すように、そのようなノード情報要求を「タイプ１のノード情報要求」と称する。

あるいは、外部装置が、別のサーバが先の監視と転送処理期間中に、インデックスサーバ１００について説明したと同様の方法でデータファイルに関連するノード情報項目の一部分をインデックスサーバ１００に転送した後、そこで実行されるノード情報検索の処理中に、インデックスサーバ１００からのデータファイルに関連するノード情報を取得することを決定する他のインデックスサーバである場合がある。他のインデックスサーバを要求側サーバと呼ばれる。この場合、要求側サーバから受信した要求は、例えば、指定されたデータファイルを提供するＮ個のノードに関する情報についてなされたノード情報要求である。
以下、図３に示すように、そのノード情報要求を「タイプ２のノード情報要求」と称する。

ステップＳ２０３において、受信した要求がタイプ１のノード情報要求であると決定されると、メッセージ処理ユニット１０４は、ステップＳ２０４において、ノード情報検索ユニット１０５に要求されたノード情報の検索と取得を実行させ、ステップＳ２０５において、取得したノード情報を要求側ノードに返す。

一方、ステップＳ２０３において、受信した要求がタイプ２のノード情報要求であると決定されると、メッセージ処理ユニット１０４は、ステップＳ２０６において、ノード情報検索ユニット１０５に要求されたノード情報の検索と取得を実行させ、ステップＳ２０７において、獲得したノード情報を要求側サーバに返す。

上記したような２つのタイプの要求以外に、メッセージ処理ユニット１０４は、もちろん、他のメッセージ、信号、データ、情報等を処理することが可能であることに留意すべきである。例えば、外部装置は、インデックスサーバ１００に対してノード情報を転送することを決定する転送元サーバとなり得る。そして、この場合、受信されるメッセージは、転送元サーバによってノード情報の転送が開始されることを示す、転送すべきノード情報項目と一緒或いは別個のメッセージである。この場合、メッセージ処理ユニット１０４は、メタデータ記憶ユニット１０１に、転送元サーバから転送されたノード情報項目を関連データファイルと関連して格納させる。

図１に示すように、インデックスサーバ１００はさらにノード情報検索ユニット１０５を備えている。
ノード情報検索ユニット１０５は、要求側ノードからの指定されたデータファイルを提供するノードに関する情報についての要求に従って、メタデータ記憶ユニット１０１と指定されたデータファイルに関連するノード情報項目の一部分が転送された他のサーバの少なくとも１つから、指定されたデータファイルを提供し要求側ノードにできるだけ近接して位置するノードを示すノード情報項目を取得するために、メタデータ記憶ユニット１０１と転送ログ記憶ユニット１０３におけるノード情報検索を実行する。
以下、ノード情報検索ユニット１０５の動作について、図４に示すフローチャートを参照して詳細に説明する。

要求が、ＩＳＰ１によって提供されエリアＲ１に位置する要求側ノードがデータファイルＤ１を取得することが可能なＴ個のノードを示す情報についての要求であると仮定する。
ノード情報検索ユニット１０５はそのような要求に従ってノード情報検索処理を実行する。

ステップＳ３０１から処理が開始する。ノード情報検索ユニット１０５は、Ｄ１を提供可能でＩＳＰ１とＲ１に位置するノードを示す、できるだけ多くの（ただし、Ｔより多くない）ノード情報項目を検索しセット１として取得する。
例えば、ノード情報検索ユニット１０５は、まず、Ｄ１と（ＩＳＰ１、Ｒ１）に関連する転送ログが存在するかどうかを判定するために、転送ログ記憶ユニット１０３に格納された転送ログテーブルを検索する。
転送ログが存在すれば、ノード情報検索ユニット１０５は、そのログにおいて示される転送されたノード情報項目の数が、Ｔより大きいか或いは等しいかを判定する。
ノード情報項目の数がＴより大きいか或いは等しければ、ノード情報検索ユニット１０５は、Ｄ１を提供し、（ＩＳＰ１、Ｒ１）に位置するＴ個のノードを要求するタイプ２のノード情報要求を、ログにおいて示されるインデックスサーバ（例えば、ＩＳ−Ｉ）に送信するようメッセージ処理ユニット１０４に指示する。
インデックスサーバＩＳ−Ｉからのノード情報応答を受信した後、ノード情報検索ユニット１０５は、応答に含まれるノード情報項目をセット１として用いる。
しかし、ログに示される数がＴより小さければ、同様の方法でインデックスサーバＩＳ−Ｉから指示された数のノード情報項目を取得した後、ノード情報検索ユニット１０５は、自身のメタデータ記憶ユニット１０１から必要なノード情報項目を見つけ出そうと試みる。
しかしながら、上述したように、（ＩＳＰ１、Ｒ１）におけるＤ１提供ノードに関する情報の最初の転送が実行された後に受信されたＤ１を提供し（ＩＳＰ１、Ｒ１）に位置するノードに関する全ての情報もインデックスサーバＩＳ−Ｉに転送されていれば、その後、ノード情報検索ユニット１０５が、自身のメタデータ記憶ユニット１０１において（ＩＳＰ、Ｒ１）に位置するＤ１提供ノードに関する必要なノード情報項目を見つけ出す確率は非常に低くなる。
一実施例において、ノード情報検索ユニット１０５は、この場合、時間を節約するために自身のメタデータ記憶ユニット１０１を検索するのをスキップすることが可能である。

しかしながら、（ＩＳＰ１、Ｒ１）に位置するＤ１提供ノードに関する情報が他のサーバに転送されていないことを転送ログテーブルが示せば、ノード情報検索ユニット１０５は、自身のメタデータ記憶ユニット１０１を検索し、セット１として用いるできるだけ多くの（ただし、Ｔより多くない）ノード情報項目を見つけ出す。

ステップＳ３０２において、ノード情報検索ユニット１０５は、セット１に含まれるノード情報項目の数（以降、｜Ｓｅｔ１｜と表し、これを他の集合にも適用する）がＴより大きいか或いは等しいかを判定する。
数がＴより大きいか或いは等しい場合、ステップＳ３０３において、ノード情報検索ユニット１０５は、要求側ノード（タイプ１のノード情報要求の場合）あるいは要求側サーバ（タイプ２のノード情報要求の場合）に対してノード情報応答としてセット１を返却するようにメッセージ処理ユニット１０４に指示する。

他方、｜Ｓｅｔ１｜がＴより小さければ、検索処理はステップＳ３０４へ進む。
そこで、ノード情報検索ユニット１０５は、ステップＳ３０１におけると同様の方法で、Ｄ１を提供可能でＩＳＰ１に位置するがＲ１に位置しないノードを示すできるだけ多くの（ただし、（Ｔ − ｜Ｓｅｔ １｜）より多くない）ノード情報項目を、セット２として検索し取得する。
ステップＳ３０５において、ノード情報検索ユニット１０５は、（｜Ｓｅｔ１｜＋｜Ｓｅｔ２｜）の和がＴより大きいか或いは等しいかを判定する。
そうであれば、ステップＳ３０６において、ノード情報検索ユニット１０５は、セット１とセット２の和集合を、要求側ノードあるいは要求側サーバに対してノード情報応答として返却するようにメッセージ処理ユニット１０４に指示する。

和がＴより小さければ、検索処理はステップＳ３０７へ進む。そこで、ノード情報検索ユニット１０５は、ステップＳ３０１におけると同様の方法で、Ｄ１を提供可能でＩＳＰ１に位置しないがＲ１に位置するノードを示すできるだけ多くの（ただし、（Ｔ−｜Ｓｅｔ１｜−｜Ｓｅｔ２｜）より多くない）ノード情報項目を、セット３として検索し取得する。
ステップＳ３０８において、ノード情報検索ユニット１０５は、（｜Ｓｅｔ１｜＋｜Ｓｅｔ２｜＋｜Ｓｅｔ ３｜）の和がＴより大きいか或いは等しいかを判定する。
そうであれば、ステップＳ３０９において、ノード情報検索ユニット１０５は、セット１とセット２とセット３の和集合を、要求側ノードあるいは要求側サーバに対してノード情報応答として返すようにメッセージ処理ユニット１０４に指示する。

そうでなければ、検索処理はステップＳ３１０へ進む。そこで、ノード情報検索ユニット１０５は、Ｄ１を提供可能でＩＳＰ１に位置せずかつＲ１にも位置しないノードを示すできるだけ多くの（ただし、（Ｔ−｜Ｓｅｔ１｜−｜Ｓｅｔ２｜−｜Ｓｅｔ３｜）より多くない）ノード情報項目を、セット４として検索し取得する。
このステップにおいて、ノード情報検索ユニット１０５は、転送ログテーブルを検索し、他のサーバからノード情報項目を取得する必要がなく、単に自身のメタデータ記憶ユニット１０１からＤ１に関連する（Ｔ−｜Ｓｅｔ１｜−｜Ｓｅｔ２｜−｜Ｓｅｔ３｜）個のノード情報項目の数をランダムに検索することが可能であることに留意すべきである。
最後に、ステップＳ３１１において、ノード情報検索ユニット１０５は、セット１とセット２とセット３及びセット４の和集合を、要求側ノードあるいは要求側サーバに対してノード情報応答として返却するようにメッセージ処理ユニット１０４に指示する。

図５は、本発明の第２の実施の形態によるインデックスサーバ１００Ａを示すブロック図である。
図６は、第２の実施の形態によるインデックスサーバ１００Ａのメッセージ処理ユニット１０４Ａ、ノード情報検索ユニット１０５、ＤＨＴ探索ユニット１０６、および他の構成要素の動作を示すフローチャートである。第１の実施の形態と同一或いは類似の要素は、同一或いは類似の参照符号を付して表わし、その詳細な説明は省略する。

図５に示すように、インデックスサーバ１００Ａは、メタデータ記憶ユニット１０１と、ノード情報管理ユニット１０２と、転送ログ記憶ユニット１０３と、メッセージ処理ユニット１０４Ａと、転送ログ記憶ユニット１０３およびＤＨＴ探索ユニット１０６を備えている。

第２の実施の形態は、分散ハッシュテーブル（Ｄｉｓｔｒｉｂｕｔｅｄ Ｈａｓｈ Ｔａｂｌｅ：ＤＨＴ）ネットワークにおける本発明の適用を示している。本実施の形態において、インデックスサーバ１００Ａは、ＤＨＴネットワーク内にある。
この場合、インデックスサーバ１００Ａが受信することができるノード情報要求は、上記説明したようなタイプ１のノード情報要求とタイプ２のノード情報要求を含んでいる。
タイプ１のノード情報要求は、要求側ノードから直接送信された要求（インデックスサーバ１００Ａが要求側ノードのホームインデックスサーバ（ｈｏｍｅ ｉｎｄｅｘｉｎｇ ｓｅｒｖｅｒ）である場合）、あるいは要求側ノードによって発行され、ＤＨＴネットワーク内の他のインデックスサーバを経由してインデックスサーバ１００Ａに到着した要求である。
タイプ１のノード情報要求は、インデックスサーバ１００Ａを目的インデックスサーバとして明示的に指定しない。そのような要求を受信すると、ＤＨＴ探索ユニット１０６はＤＨＴ探索（ＤＨＴ ｌｏｏｋｕｐ）を実行し、それに応じてインデックスサーバ１００Ａが動作する。
第１の実施の形態と同様、第２の実施の形態におけるタイプ２のノード情報要求は、他のサーバがノード情報検索を実行しており、インデックスサーバ１００Ａから必要なノード情報を取得可能であることを見つけ出した場合に、その他のサーバから送信されたノード情報要求である。タイプ２のノード情報要求は、インデックスサーバ１００Ａを目的インデックスサーバとして明示的に指定する。
そのような要求を受信すると、ノード情報検索ユニット１０５は直接ノード情報検索を実行し、インデックスサーバ１００Ａがそれに応じて動作する。

インデックスサーバ１００Ａの動作について図６を参照して説明する。

ステップＳ２０１、Ｓ２０２において要求を受信すると、メッセージ処理ユニット１０４Ａは、ステップＳ２０３Ａにおいて、要求のタイプを判定する。
要求がタイプ１のノード情報要求であれば、処理はステップＳ２０８へ進むみ、そこで、ＤＨＴ探索ユニット１０６は、インデックスサーバ１００Ａによって保持されるローカルのフィンガーテーブル（Ｆｉｎｇｅｒ Ｔａｂｌｅ）（図示しない）を用いることにより、ＤＨＴ探索を実行する。ステップＳ２０９において、ＤＨＴ探索ユニット１０６は、ローカルのフィンガーテーブル（Ｆｉｎｇｅｒ Ｔａｂｌｅ）上の探索がヒットしたかどうかを判定する。
ヒットしていれば、処理はステップＳ２０４へ進み、そこで、ノード情報検索ユニット１０５に要求に従ってノード情報の検索と取得を実行させ、その後、ステップＳ２０５において、取得したノード情報は、要求側ノードに応答として送信される。
インデックスサーバ１００Ａが要求側ノードのホームインデックスサーバでなければ、インデックスサーバ１００Ａは、ホームインデックスサーバを介して取得したノード情報を要求側ノードに送信することに留意されたい。

他方、ステップＳ２０９においてヒットしなければ、処理はステップＳ２１０へ進み、そこで、ＤＨＴ探索ユニット１０６は、フィンガーテーブル（Ｆｉｎｇｅｒ Ｔａｂｌｅ）によって示される次のホップサーバ（ｈｏｐ ｓｅｒｖｅｒ）のもとにノード情報要求を送信するようメッセージ処理ユニット１０４Ａに指示する。

ステップＳ２０３Ａにおいて要求がタイプ２のノード情報要求と判定されると、処理はステップＳ２０６に進み、そこで、ノード情報検索ユニット１０５は、要求に従ってノード情報を検索し取得し、その後、ステップＳ２０７において、取得したノード情報が、要求側サーバのもとに応答として送信される。

図７は、本発明の第３の実施の形態によるインデックスサーバ１００Ｂを示すブロック図である。図８は、第３の実施の形態に従ってインデックスサーバ１００Ｂのメッセージ処理ユニット１０４Ｂと他の構成要素の動作を示すフローチャートである。第２の実施の形態と同一或いは類似の要素は、同一或いは類似の参照符号を付して表わし、その詳細な説明は省略する。

図７に示すように、第３の実施の形態は、要求側ノードに対して修正を加えている。
第２の実施の形態において、要求側ノードによって発行されたデータファイルに関連する要求は、ホームインデックスサーバにまず送信され、それが目的インデックスサーバに到着するまで、すなわち、フィンガーテーブルにおいてヒットすることを見出すサーバに到着するまで、ＤＨＴネットワーク内を経由する。
データファイルと関連する後続の要求を直接目的インデックスサーバに送信することができれば、応答の遅延はより一層減少する。
要求側ノードによって送信され、目的インデックスサーバを明示的に指定するそのような後続の要求を、ここで、タイプ３のノード情報要求と称する。

この目的のために、図７に示す要求側ノード２００は、ノード情報要求ユニット２０１と、探索ユニット２０２およびキャッシュユニット２０３を備えている。
特定のデータファイルに関連しかつそのデータファイルに対する目的インデックスサーバを示すノード情報応答を受信した後、そのデータファイルと目的インデックスサーバの間の関連付けが、キャッシュユニット２０３内に格納される。
その後、ノード情報要求ユニット２０１がそのデータファイルに関連する別のノード情報要求を送信しようとする時、探索ユニット２０２は、キャッシュユニット２０３内を調べ、そのデータファイルに関連付けられている目的インデックスサーバを決定する。
その後、ノード情報要求ユニット２０１は、その目的インデックスサーバに対してタイプ３のノード情報要求を直接送信する。

目的インデックスサーバがインデックスサーバ１００Ｂであると仮定する。インデックスサーバ１００Ｂは、そのメッセージ処理ユニット１０４Ｂがさらにタイプ３のノード情報要求を判別可能であるという点で、第２の実施の形態によるインデックスサーバ１００Ａと相違する。

具体的には、図８に示すように、要求を受信した後、メッセージ処理ユニット１０４Ｂは、ステップＳ２０３Ｂにおいて、そのタイプを判定する。
タイプ３のノード情報要求であれば、処理はステップＳ２０８とＳ２０９をスキップし、直接ステップＳ２０４へ進み、そこで、ノード情報検索ユニット１０５は、要求に従ってノード情報を検索して取得し、その後、ステップＳ２０５において、ノード情報応答が要求側ノード２００に直接送信される。

以上、本発明についてその好適な実施例を参照して説明したが、当該技術に精通した当業者には、本発明の精神と範囲から逸脱することなく他の様々な修正、変更、追加を行うことが可能なことは明らかであろう。したがって、本発明の範囲は上記の具体的な実施例に限定されず、付記した請求項によってのみ限定される。

さらに、上記実施形態の一部分又は全部は、以下の付記のようにも記載されうるが、これに限定されない。

（付記１）
ピアツーピア・ネットワークのインデックスサーバであって、
データファイルと関連するエントリであって、該データファイルを提供するサーバと該サーバの位置を示す複数の情報項目を含む１以上のエントリを格納するメタデータ記憶ユニットと、
前記メタデータ記憶ユニットを監視して前記情報項目の数がしきい値を越える、前記メタデータ記憶ユニット内に格納されたエントリを識別し、識別されたエントリ内に含まれる情報項目の一部分であって、その位置が互いに接近しているノードを示すノード情報項目を可能な限り多く含む一部分を他のサーバに転送するノード情報管理ユニットと
を備えることを特徴とするインデックスサーバ。

（付記２）
転送ログ記憶ユニットをさらに備え、
前記ノード情報管理ユニットは、転送ログが、転送された一部分と関連するデータファイル、該一部分が転送される他のサーバ、転送された一部分によって示されるノードの位置範囲を反映するように、前記転送ログ記憶ユニット内の転送ログを生成し又は更新することを特徴とする付記１に記載のインデックスサーバ。

（付記３）
他のサーバが、負荷が小さいと判定されたサーバであることを特徴とする付記１に記載のインデックスサーバ。

（付記４）
前記ノード情報管理ユニットは、各グループが異なるインターネット・サービス・プロバイダ（ＩＳＰ）内のノードを示すノード情報項目を含むように、前記識別されたエントリに含まれるノード情報項目を、１以上のグループに分割し、１以上のグループ中で最大数のノード情報項目を含むグループを、他のサーバに転送することにより、転送を実行することを特徴とする付記１に記載のインデックスサーバ。

（付記５）
前記ノード情報管理ユニットは、各グループが異なるインターネット・サービス・プロバイダ（ＩＳＰ）内のノードを示すノード情報項目を含むように、前記識別されたエントリに含まれるノード情報項目を、１以上のグループに分割し、１以上のグループ中でノード情報項目の数が最大のグループを識別し、最大数が前記しきい値を越えるかどうか判定し、最大数が前記しきい値を越えなければ、識別されたグループを他のサーバに対して転送し、最大数がしきい値より大きければ、識別したグループに含まれるノード情報項目を、各サブグループが異なるエリアのノードを示すノード情報項目を含むように、１以上のサブグループに分割し、１以上のサブグループのうちノード情報項目の数が最大のサブグループを他のサーバに転送することにより、転送を実行することを特徴とする付記１に記載のインデックスサーバ。

（付記６）
第１のノード情報項目が他のサーバに転送された後、第１のノード情報項目と関連するデータファイルを提供し、その位置が第１のノード情報項目によって示されるノードに接近しているノードを示す第２のノード情報項目が受信されると、ノード情報管理ユニットが、前記第２のノード情報項目を他のサーバに転送することを特徴とする付記１に記載のインデックスサーバ。

（付記７）
要求側ノードからの指定されたデータファイルを提供するノードに関する情報についての要求に従って、メタデータ記憶ユニットと指定されたデータファイルに関連するノード情報項目の一部分が転送された他のサーバの少なくとも１つから、指定されたデータファイルを提供し要求側ノードにできるだけ近接して位置するノードを示すノード情報項目を取得するために、前記メタデータ記憶ユニットと転送ログ記憶ユニットにおけるノード情報検索を実行するノード情報検索ユニット１０５をさらに備えることを特徴とする付記２に記載のインデックスサーバ。

（付記８）
前記要求が、目的インデックスサーバとしてのインデックスサーバを指定することを特徴とする付記７に記載のインデックスサーバ。

（付記９）
要求に応答して、指定されたデータファイルの標識を用いてＤＨＴ探索を実行し、インデックスサーバ上でヒットが生じるかどうかを判定し、ヒットが生じなければ、インデックスサーバが属するＤＨＴネットワーク内で要求を経由させ、ヒットが生じれば、ノード情報検索ユニットに前記検索を実行させる分散ハッシュテーブル探索ユニットをさらに備えることを特徴とする付記７に記載のインデックスサーバ。

（付記１０）
前記要求が、目的インデックスサーバとしてのインデックスサーバを指定しないことを特徴とする付記９に記載のインデックスサーバ。

（付記１１）
データファイルと関連するエントリであって、該データファイルを提供するサーバと該サーバの位置を示す複数の情報項目を含む１以上のエントリを格納するメタデータ記憶ユニットを含む、ピアツーピア・ネットワークのインデックスサーバによる方法であって、
前記情報項目の数がしきい値を越える、前記メタデータ記憶ユニット内に格納されたエントリを識別するために、前記メタデータ記憶ユニットを監視するステップと、
識別されたエントリ内に含まれる情報項目の一部分であって、その位置が互いに接近しているノードを示すノード情報項目を可能な限り多く含む一部分を他のサーバに転送するステップと
を含むことを特徴とする方法。

（付記１２）
前記インデックスサーバが転送ログ記憶ユニットをさらに含み、
前記一部分が他のサーバに転送される時、転送ログが、転送された一部分と関連するデータファイル、該一部分が転送される他のサーバ、転送された一部分によって示されるノードの位置範囲を反映するように、前記転送ログ記憶ユニット内の転送ログを生成し又は更新することを特徴とする付記１１に記載の方法。

（付記１３）
他のサーバが、負荷が小さいと判定されたサーバであることを特徴とする付記１１に記載の方法。

（付記１４）
前記転送ステップが、
各グループが異なるインターネット・サービス・プロバイダ（ＩＳＰ）内のノードを示すノード情報項目を含むように、前記識別されたエントリに含まれるノード情報項目を、１以上のグループに分割するステップと、
１以上のグループ中で最大数のノード情報項目を含むグループを、他のサーバに転送するステップを含むことを特徴とする付記１１に記載の方法。

（付記１５）
前記転送ステップが、
各グループが異なるインターネット・サービス・プロバイダ（ＩＳＰ）内のノードを示すノード情報項目を含むように、前記識別されたエントリに含まれるノード情報項目を、１以上のグループに分割するステップと、
１以上のグループ中でノード情報項目の数が最大のグループを識別するステップと、
最大数が前記しきい値を越えるかどうかを判定するステップと、
最大数が前記しきい値を越えなければ、識別されたグループを他のサーバに対して転送するステップと、
最大数がしきい値より大きければ、識別したグループに含まれるノード情報項目を、各サブグループが異なるエリアのノードを示すノード情報項目を含むように、１以上のサブグループに分割し、１以上のサブグループのうちノード情報項目の数が最大のサブグループを他のサーバに転送するステップを含むことを特徴とする付記１１に記載の方法。

（付記１６）
第１のノード情報項目が他のサーバに転送された後、第１のノード情報項目と関連するデータファイルを提供し、その位置が第１のノード情報項目によって示されるノードに接近しているノードを示す第２のノード情報項目が受信されると、前記第２のノード情報項目を他のサーバに転送することを特徴とする付記１１に記載の方法。

（付記１７）
要求側ノードからの指定されたデータファイルを提供するノードに関する情報についての要求に従って、メタデータ記憶ユニットと指定されたデータファイルに関連するノード情報項目の一部分が転送された他のサーバの少なくとも１つから、指定されたデータファイルを提供し要求側ノードにできるだけ近接して位置するノードを示すノード情報項目を取得するために、前記メタデータ記憶ユニットと転送ログ記憶ユニットにおけるノード情報検索を実行するステップをさらに含むことを特徴とする付記１２に記載の方法。

（付記１８）
前記要求が、目的インデックスサーバとしてのインデックスサーバを指定することを特徴とする付記１７に記載の方法。

（付記１９）
要求に応答して、指定されたデータファイルの標識を用いてＤＨＴ探索を実行し、インデックスサーバ上でヒットが生じるかどうかを判定し、ヒットが生じなければ、インデックスサーバが属するＤＨＴネットワーク内で要求を経由させ、ヒットが生じれば、前記検索を実行するステップをさらに含むことを特徴とする付記１７に記載の方法。

（付記２０）
前記要求が、目的インデックスサーバとしてのインデックスサーバを指定しないことを特徴とする付記１９に記載の方法。

１００：インデックスサーバ
１０１：メタデータ記憶ユニット
１０２：ノード情報管理ユニット
１０３：転送ログ記憶ユニット
１０４：メッセージ処理ユニット
１０５：ノード情報検索ユニット
１０６：ＤＨＴ探索ユニット
２００：要求側ノード
２０１：ノード情報要求ユニット
２０２：探索ユニット
２０３：キャッシュユニット

Claims (10)

1. ピアツーピア・ネットワークのインデックスサーバであって、
   データファイルと関連するエントリであって、該データファイルを提供するサーバと該サーバの位置を示す複数の情報項目を含む１以上のエントリを格納するメタデータ記憶ユニットと、
   前記メタデータ記憶ユニットを監視して前記情報項目の数がしきい値を越える、前記メタデータ記憶ユニット内に格納されたエントリを識別し、識別されたエントリ内に含まれる情報項目の一部分であって、その位置が互いに接近しているノードを示すノード情報項目を可能な限り多く含む一部分を他のサーバに転送するノード情報管理ユニットと
   を備えることを特徴とするインデックスサーバ。
2. 転送ログ記憶ユニットをさらに備え、
   前記ノード情報管理ユニットは、転送ログが、転送された一部分と関連するデータファイル、該一部分が転送される他のサーバ、転送された一部分によって示されるノードの位置範囲を反映するように、前記転送ログ記憶ユニット内の転送ログを生成し又は更新することを特徴とする請求項１に記載のインデックスサーバ。
3. 他のサーバが、負荷が小さいと判定されたサーバであることを特徴とする請求項１に記載のインデックスサーバ。
4. 前記ノード情報管理ユニットは、各グループが異なるインターネット・サービス・プロバイダ（ＩＳＰ）内のノードを示すノード情報項目を含むように、前記識別されたエントリに含まれるノード情報項目を、１以上のグループに分割し、１以上のグループ中で最大数のノード情報項目を含むグループを、他のサーバに転送することにより、転送を実行することを特徴とする請求項１に記載のインデックスサーバ。
5. 前記ノード情報管理ユニットは、各グループが異なるインターネット・サービス・プロバイダ（ＩＳＰ）内のノードを示すノード情報項目を含むように、前記識別されたエントリに含まれるノード情報項目を、１以上のグループに分割し、１以上のグループ中でノード情報項目の数が最大のグループを識別し、最大数が前記しきい値を越えるかどうか判定し、最大数が前記しきい値を越えなければ、識別されたグループを他のサーバに対して転送し、最大数がしきい値より大きければ、識別したグループに含まれるノード情報項目を、各サブグループが異なるエリアのノードを示すノード情報項目を含むように、１以上のサブグループに分割し、１以上のサブグループのうちノード情報項目の数が最大のサブグループを他のサーバに転送することにより、転送を実行することを特徴とする請求項１に記載のインデックスサーバ。
6. 第１のノード情報項目が他のサーバに転送された後、第１のノード情報項目と関連するデータファイルを提供し、その位置が第１のノード情報項目によって示されるノードに接近しているノードを示す第２のノード情報項目が受信されると、ノード情報管理ユニットが、前記第２のノード情報項目を他のサーバに転送することを特徴とする請求項１に記載のインデックスサーバ。
7. 要求側ノードからの指定されたデータファイルを提供するノードに関する情報についての要求に従って、メタデータ記憶ユニットと指定されたデータファイルに関連するノード情報項目の一部分が転送された他のサーバの少なくとも１つから、指定されたデータファイルを提供し要求側ノードにできるだけ近接して位置するノードを示すノード情報項目を取得するために、前記メタデータ記憶ユニットと転送ログ記憶ユニットにおけるノード情報検索を実行するノード情報検索ユニット１０５をさらに備えることを特徴とする請求項２に記載のインデックスサーバ。
8. 要求に応答して、指定されたデータファイルの標識を用いてＤＨＴ探索を実行し、インデックスサーバ上でヒットが生じるかどうかを判定し、ヒットが生じなければ、インデックスサーバが属するＤＨＴネットワーク内で要求を経由させ、ヒットが生じれば、ノード情報検索ユニットに前記検索を実行させる分散ハッシュテーブル探索ユニットをさらに備えることを特徴とする請求項７に記載のインデックスサーバ。
9. データファイルと関連するエントリであって、該データファイルを提供するサーバと該サーバの位置を示す複数の情報項目を含む１以上のエントリを格納するメタデータ記憶ユニットを含む、ピアツーピア・ネットワークのインデックスサーバによる方法であって、
   前記情報項目の数がしきい値を越える、前記メタデータ記憶ユニット内に格納されたエントリを識別するために、前記メタデータ記憶ユニットを監視するステップと、
   識別されたエントリ内に含まれる情報項目の一部分であって、その位置が互いに接近しているノードを示すノード情報項目を可能な限り多く含む一部分を他のサーバに転送するステップと
   を含むことを特徴とする方法。
10. 前記インデックスサーバが転送ログ記憶ユニットをさらに含み、
    前記一部分が他のサーバに転送される時、転送ログが、転送された一部分と関連するデータファイル、該一部分が転送される他のサーバ、転送された一部分によって示されるノードの位置範囲を反映するように、前記転送ログ記憶ユニット内の転送ログを生成し又は更新することを特徴とする請求項９に記載の方法。
    

Images