JP2010250799A - リソースの位置情報の要求方法、当該方法のためのユーザノードおよびサーバ - Google Patents

Abstract

【課題】ユーザがネットワークリソースを迅速に取得することを可能にする、Ｐ２Ｐネットワーク上のリソースの位置情報の要求方法、当該方法のためのユーザノードおよびサーバを提供する。
【解決手段】人気ファイルのメタデータは個々の領域に基づいて複数のＳＮ内に格納され、不人気ファイルのメタデータは中央集中的に格納されクエリされる。ＳＮには、ユーザにＳＮ−Ｒの存在を通知するための、要求メッセージのリダイレクト機能が追加され、ユーザノードには、クエリ効率を高め、メッセージの反復的なリダイレクトを避けられるよう、ダウンロードすべきファイル、及びファイルの供給のために要求すべきサーバを示すサーバルーティングテーブルが備えられる。人気ファイルと不人気ファイルは別個に格納され、すべての不人気ファイルは中央集中的に格納され、ユーザはＰ２Ｐネットワーク内の不人気ファイルを要求したときに不人気ファイルを取得できる。
【選択図】図６

Description

本願はネットワークリソースの配置場所の特定に関し、特に、ユーザが所望のリソースを迅速に取得するための、Ｐ２Ｐネットワーク内におけるリソースの位置情報の要求方法、ユーザノードおよびそのサーバに関する。

Ｐ２Ｐネットワークとは、コンテンツ、ＣＰＵサイクル、ストレージ、帯域等のリソースの共有を目的とした自己組織化能力を有する、相互接続されたマシンで構成される分散ネットワークシステムである。Ｐ２Ｐネットワークの主要な問題は「データ検索」、すなわち、ユーザがファイルをダウンロードしたいときに、そのファイルを所有しているユーザをいかにして見つけるか、という問題である。単純に考えれば、ネットワーク全体に大量なクエリを発信すればよいということになるが、これを行うとコンピュータの待ち時間（レイテンシー）が長くなり、トラフィックコストも膨大となってしまう。そのため、現在のＰ２Ｐシステムでは、データ−ピア情報（「メタデータ」（ファイルのサイズ、ファイルの提供者等の属性の記述）とも呼ばれる）を格納することにより、ユーザが対応する提供者を迅速に見つけられるようにする、インデキシングサーバを使用するのが主流となっている。

既存のＰ２Ｐインデキシングサーバの多くは、既知のユーザ集合からランダムサブセットを返す方法を採っているが、これによりネットワーク運用者は深刻なＩＳＰ（インターネットサービスプロバイダ）間のトラフィック問題に直面している。図１に示すように、ＩＳＰ＃１のユーザは、ＩＳＰ＃１にローカルコピーがある場合でも、ＩＳＰ＃２のユーザからファイルをダウンロードすることができる。このようなＩＳＰ間のトラフィックを削減するため、大規模Ｐ２Ｐシステム向けの新たな位置認識アーキテクチャが提案されている。

非特許文献１（「Ａ Ｍａｎａｇｅａｂｌｅ Ｃａｒｒｉｅｒ−Ｌｅｖｅｌ Ｐ２Ｐ Ｎｅｔｗｏｒｋ Ａｒｃｈｉｔｅｃｔｕｒｅ」（管理可能な通信事業者レベルのＰ２Ｐネットワーク）、ＣＣＳＡ ＴＣ１ ＷＧ４会議草案、２００８年１０月３０日）では、メタデータテーブルが「スーパーノード」と呼ばれる複数のサーバに格納され、各サーバが自サーバの領域におけるメタデータの格納とクエリを担当する、分散スーパーノードのための方法が提案されている。領域の分割は柔軟に行われ、１つのＩＳＰを１領域とすることも可能である。例えば、中国国内のインターネットでは、１つのスーパーノードが中国郵電電信総局（チャイナ・テレコム）のすべてのユーザおよびファイル情報を管理することができる。管理する情報量が膨大過ぎる場合には、複数のサブノードを使用して、あるサブノードに北京電気通信支局内のピアを担当させ、別のサブノードには上海電気通信支局内のピアを担当させる、といったことが可能である。

図２は、スーパーノードＩ（ＳＮ−Ｉ）がＩＳＰ１内のピアを管理し、スーパーノードＩＩ（ＳＮ−ＩＩ）がＩＳＰ２内のピアを管理する場合を示す。ＩＳＰ１内のユーザＡ、Ｂ、Ｃは、共有ファイルＤ１を格納する際に、共有ファイルＤ１のファイルＩＤやアドレス等で構成されるピア情報をＳＮ−Ｉに通知する。この共有ファイルＤ１は、ＳＮ−Ｉのピア情報テーブルに、「Ｄ１：Ａ，Ｂ，Ｃ」（ユーザＡ、Ｂ、ＣがファイルＤ１を所有することを示す）の形式で格納される。

同様に、ＩＳＰ２内のユーザＥ、Ｆ、Ｇ、Ｈは、共有ファイルＤ１のピア情報をＳＮ−ＩＩに通知する。その一方で、ユーザＧはさらに別のファイルであるファイルＤ２のピア情報をＳＮ−ＩＩに通知する。図２から明らかなように、ファイルＤ１は人気ファイルとみなすことができ、ファイルＤ２は不人気ファイルとみなすことができる。

図３は、既存技術におけるメタデータ情報の要求および検索処理を概略的に示したものである。図２の格納手順では、ファイルＤ１を要求するステップＳ１１において、ユーザＤはファイルＤ１が人気ファイルなのか不人気ファイルなのかを認識していないので、ファイルを取得するための要求メッセージをＳＮ−Ｉを送信する。ステップＳ１２において、ＳＮ−ＩはファイルＤ１の位置を自ノード上に格納しているかどうかを判断する。この例では、ＳＮ−Ｉのピア情報テーブル（サブテーブル）に十分なユーザ情報が含まれているので、ＳＮ−ＩはステップＳ１３において、ユーザＤからの要求に対する応答メッセージを送信する。ユーザＡ、Ｂ、Ｃ、Ｄは同じＩＳＰに存在するため、ユーザＤがファイルＤ１をダウンロードしてもＩＳＰ間のトラフィックは発生しない。各ピアのステータスは動的（オンラインまたは非オンライン）なので、ユーザＤは、上記に加えて、ＳＮ−Ｉに要求メッセージを定期的に送信して関連のユーザ情報を更新する必要がある。

一方、ユーザＤが要求するファイルがファイルＤ２の場合には、ＳＮ−ＩはファイルＤ２に関して十分なユーザ情報を持たないため、ステップＳ１４において他のＳＮ上にあるユーザ情報を（例えば、ＳＮ−ＩＩにクエリ要求を送信する等により）クエリする必要がある。ステップＳ１５において、ＳＮ−ＩＩはファイルＤ２の位置情報を自ノード上に格納しているかどうかを判断する。ＳＮ−ＩＩがファイルＤ２の位置情報を自ノード上に格納している場合は、ステップＳ１６において、ＳＮ−ＩＩはクエリ結果をＳＮ−Ｉに返し、ＳＮ−ＩはそれをユーザＤに返す。

ステップＳ１５における判断の結果がＮＯの場合、すなわち、ＳＮ−ＩＩもファイルＤ２の位置情報（ピア情報）を格納していない場合には、ＳＮ−ＩＩはステップ１７において、要求メッセージを例えばＳＮ−ＩＩＩに送信する。その後、ステップＳ１８において、ＳＮ−ＩＩＩはファイルＤ１の位置情報を自ノード上に格納しているかどうかを判断する。ステップＳ１８の判断結果がＹＥＳの場合、ＳＮ−ＩＩＩはステップＳ１９においてこのクエリ結果をＳＮ−ＩＩに返し、ＳＮ−ＩＩはそれをＳＮ−Ｉに返し、ＳＮ−ＩはそれをユーザＤに返す。ステップＳ１８の判断結果がＮＯの場合、ＳＮ−ＩＩＩはステップＳ２０において、要求メッセージを他のＳＮに送信する。その後の処理は上記と同様である。

「Ａ Ｍａｎａｇｅａｂｌｅ Ｃａｒｒｉｅｒ−Ｌｅｖｅｌ Ｐ２Ｐ Ｎｅｔｗｏｒｋ Ａｒｃｈｉｔｅｃｔｕｒｅ」（管理可能な通信事業者レベルのＰ２Ｐネットワーク）、ＣＣＳＡ ＴＣ１ ＷＧ４会議草案、２００８年１０月３０日

上記から明らかなように、上述の関連技術による方法には不人気ファイルの場合の検索に拡張性がないため、複数のスーパーノードに繰り返しクエリを行う必要が生じる。これにより、ユーザ側にユーザ要求への応答が届くまでに大幅な遅延が生じる。この応答遅延が利用上の快適性を減じることは言うまでもない。例えば、Ｐ２Ｐ ＶｏＤシステムでは、要求した映画がさほど人気の高いものでない場合には、ユーザは映画を再生できるまでに長い時間待たなければならない。

本発明の目的は、ユーザが所望のリソースを迅速に取得することのできる、Ｐ２Ｐネットワーク内におけるリソースの位置情報の要求方法、当該方法のためのユーザノードおよびサーバを提供することである。

本発明の第１の態様によれば、Ｐ２Ｐネットワーク上におけるリソースの位置情報の要求方法であって、２Ｐネットワークが、各ドメインにおける第１の人気度を有するリソースの位置情報と第２の人気度を有するリソースの位置情報の格納アドレスとを格納する１つ以上の第１サーバと、第２の人気度を有するリソースの位置情報を各々格納する１つ以上の第２サーバとを備え、当該方法は、ユーザノードが自ドメイン内の第１サーバにリソースの要求を送信するステップと、当該第１サーバが当該リソースの位置情報を格納していない場合に、当該第１サーバから当該ユーザノードに、どの第２サーバが当該リソースの位置情報を格納するかを示すメッセージを送信するステップと、当該メッセージに基づいて、当該ユーザノードから当該第２サーバに位置情報の要求を送信するステップとを備えることを特徴とする要求方法が提供される。

本発明の第２の態様によれば、Ｐ２Ｐネットワーク上におけるリソースの位置情報のアップロード方法であって、２Ｐネットワークが、各ドメインにおける第１の人気度を有するリソースの位置情報と第２の人気度を有するリソースの位置情報の格納アドレスとを格納する１つ以上の第１サーバと、第２の人気度を有するリソースの位置情報を各々格納する１つ以上の第２サーバとを備え、当該方法は、ユーザノードが自ドメイン内の第１サーバにリソースの識別情報とユーザノードのアドレスとを通知するステップと、リソースが第１の人気度を有する場合に、当該第１サーバにリソースの識別情報とユーザノードのアドレスとを格納するステップと、リソースが第２の人気度を有する場合に、当該第１サーバから当該ユーザノードに、どの第２サーバがリソースの位置を格納しているかを示すメッセージを送信するステップと、当該ユーザノードからメッセージで示された第２サーバにリソースの識別情報とユーザノードのアドレスとを送信するステップとを備えることを特徴とするアップロード方法が提供される。

本発明の第３の態様によれば、Ｐ２Ｐネットワーク上におけるリソースの位置情報を要求するユーザノードであって、２Ｐネットワークが、各ドメインにおける第１の人気度を有するリソースの位置情報と第２の人気度を有するリソースの位置情報の格納アドレスとを格納する１つ以上の第１サーバと、第２の人気度を有するリソースの位置情報を各々格納する１つ以上の第２サーバとを備え、当該ユーザノードは、要求された位置情報がすでに登録されまた今後も登録されるテーブルを格納する格納手段と、当該テーブル内に要求位置情報が登録されていない場合には、自ドメイン内の第１サーバにリソースの要求を送信し、どの第２サーバが当該位置情報を格納するかを示すメッセージが受信された場合には、当該メッセージに基づいて第２サーバに当該位置情報の要求を送信するクエリ手段とを備えることを特徴とするユーザノードが提供される。

本発明の第４の態様によれば、Ｐ２Ｐネットワーク内のサーバであって、 各ドメインにおける第１の人気度を有するリソースの位置情報と第２の人気度を有するリソースの位置情報の格納アドレスを格納する格納手段と、ユーザノードからリソースの位置情報の要求を受信するクエリメッセージ処理手段と、当該格納手段が位置情報を格納していない場合に、要求された位置情報がネットワーク上のどの位置に格納されているかを示すメッセージをユーザノードに送信して、ユーザノードが当該メッセージに示される位置から位置情報を取得できるようにするリダイレクトメッセージ生成手段とを備えることを特徴とするサーバが提供される。

本発明の第５の態様によれば、Ｐ２Ｐネットワーク内のサーバであって、当該サーバは、リソースの位置情報を格納する格納手段と、当該リソースの当該ネットワーク上における人気度の変動を監視する監視手段と、当該リソースの人気度が当該人気度よりも高い他の人気度に変動した場合に、リソースの識別情報と位置情報とを他のノードに転送する情報転送手段とを備えることを特徴とするサーバが提供される。

上述した方法と構成においては、人気ファイルと不人気ファイルとが別個に格納され、すべての不人気ファイルが中央集中的に格納されるため、ユーザは、Ｐ２Ｐネットワーク内における所望のファイルの人気度が低い場合でも、当該所望のファイルを迅速に取得することができる。

また、本発明の各実施例によれば、ユーザノードに位置情報テーブルが備えられる。これにより、ユーザが所望のリソースを再度要求したときのネットワークリソースを取得するまでの待ち時間がさらに短縮される。

さらに、本発明の各実施例によれば、ファイルの人気度が変動した場合には、位置情報を異なるスーパーノード間で転送できるため、所望のファイルを取得するまでの待ち時間がさらに短縮される。

本発明の上記およびその他の目的、特徴、および利点は、図面を参照しながらその好適な実施例について述べた以下の説明により明らかになるであろう。

既存技術におけるＩＳＰ間トラフィックの発生を示す概略図である。 既存技術における分散スーパーノード内でのピア情報の管理を示す概略図である。 既存技術において分散スーパーノード間で実行されるピアデータの要求および検索処理を説明するフローチャートである。 本発明の一実施例によるネットワーク構成を示す説明図である。 本発明の一実施例による、ネットワーク内のユーザノードとネットワークサーバを示すブロック図である。 本発明の一実施例による、共有ファイルの通知処理を説明するフローチャートである。 本発明の一実施例による、ファイルの位置情報の要求処理を説明するフローチャートである。 本発明の一実施例による、ネットワーク内のネットワークサーバのブロック図である。

以下では、図面を参照して本発明の好適な実施例を説明する。この説明においては、本発明に対する誤解を回避するため、詳細や説明の不要な機能を一部省略している。

本発明の一実施例によれば、人気ファイルと不人気ファイルはそれぞれ別個に管理される。人気ファイルのメタデータは対応する領域に基づいて複数のＳＮ内に格納され、不人気ファイルのメタデータは中央集中的に格納され検索される。以下では、不人気ファイルを格納し検索するサーバ（スーパーノード）を「ＳＮ−Ｒ」と称する。

ここで言う人気ファイルと不人気ファイルとは、相対的な概念に基づく分類である。当該技術に精通した当業者であれば、これらのファイルを、ファイルの人気度に基づいてより詳細なカテゴリーに分類することも可能であろう。

本発明の一実施例によれば、不人気ファイルの量が多すぎる場合には、複数のＳＮ−Ｒ（例：ＳＮ−Ｒ１、ＳＮ−Ｒ２）を使用して格納できる。ただし、１つの不人気ファイルのすべてのメタデータは同じＳＮ−Ｒ内に格納しなければならない。

ユーザはファイルの位置情報を要求する際には、要求したファイルが人気ファイルなのか不人気ファイルなのかを認識していないため、該当のＩＳＰを担当する既定のＳＮに要求メッセージを送信する。これを実行するため、ＳＮには、ユーザにＳＮ−Ｒの存在を通知するメッセージをリダイレクトするためのリダイレクト機能が備えられる。また、検索効率を高め、メッセージの反復的なリダイレクトを避けられるよう、ファイルのダウンロード時に要求メッセージの宛先とすべきサーバを示すサーバルーティングテーブルがユーザノードに備えられる。このルーティングテーブルにより、人気ファイルのダウンロードを所望するユーザは、ユーザと同じＩＳＰ内にあるＳＮに対して要求メッセージを送信することが可能になる。ダウンロードを所望するファイルが不人気ファイルの場合には、ユーザは対応するＳＮ−Ｒに要求メッセージを送信する。これにより、異なるサーバにまたがる不人気ファイルの検索処理が不要となるため、不人気ファイルを検索する際の応答時間も短縮される。その一方で、人気ファイルに対する検索の拡張性と位置認識機能も確保することができる。

図４は、本発明の一実施例によるネットワーク構成を示す説明図である。図４に示すように、ファイルＤ２の提供者情報（Ｇ）はＳＮ−Ｒ１に格納され、ＳＮ−ＩおよびＳＮ−ＩＩのメタデータテーブル（サブテーブル）には、ノードＳＮ−Ｒ１がファイルＤ２に対応するノードとして示される。ユーザがＳＮ−ＩとＳＮ−ＩＩに対してファイルＤ２を要求すると、リダイレクトメッセージによって、当該要求がＳＮ−ＩとＳＮ−ＩＩはファイルＤ２のプロバイダに通知される。ファイルＤ２に関連するリダイレクトメッセージの受信後、ファイルＤ２の所有者であるユーザＤ（提供者）は、ＳＮ−ルーティングテーブルにファイルＤ２の位置情報を示す項目を追加することができる。ユーザが再度ファイルＤ２を要求した場合、当該要求は直接ＳＮ−Ｒ１に送信される。

図５は、本発明の一実施例による、ネットワーク内のユーザノードとネットワークサーバを示すブロック図である。図５に示すように、本実施例によるユーザノードは、通知メッセージ生成手段１１と、ストレージ手段１２と、リダイレクトメッセージ処理手段１３と、クエリメッセージ生成手段１３と、応答メッセージ生成手段１５と、通信手段１６とを含む。

図５に示すように、ユーザが他のユーザとファイルを共有する際には、通知メッセージ生成手段１１がメタデータ通知メッセージを作成し、通信手段１６を介してそのメッセージを該当するサーバＳＮに送信する。通知メッセージには、例えば、ｉ）共有するファイルのファイル情報（データＩＤ）や、ｉｉ）ユーザ（提供者）のアドレス（ＩＰアドレス、ポート番号、プロトコルなど）を含めることができる。

ストレージ手段１２は、ファイル（データＩＤで識別）と管理サーバ（アドレスＩＤで識別）との間の対応関係が示されるルーティングテーブルを含む。通知メッセージ生成手段１１は、通信手段１６を介して通知メッセージを送信する際にはその都度事前にルーティングテーブル内の当該ファイルに関する提供者情報を検索し、当該メッセージを該当するサーバ（ＳＮまたはＳＮ−Ｒ）に送信する必要がある。

リダイレクトメッセージ処理手段１３は、ＳＮから送信されたリダイレクトメッセージなどのリダイレクトメッセージをネットワークから受信し、サーバのデータＩＤとアドレス情報を抽出し、ストレージ手段１２に格納されるルーティングテーブルを更新する。

クエリメッセージ生成手段１４は、ファイル要求メッセージを作成し、通信手段を介してそれをサーバに送信する。要求メッセージには、例えば、ｉ）ダウンロードするファイルのデータＩＤ、ｉｉ）当該ユーザ（ファイルの要求者）のアドレス情報、ｉｉｉ）取得するユーザ情報（ファイルの提供者に関する情報）の量などを含めることができる。クエリメッセージ生成手段１４は、クエリメッセージを送信する前に、データＩＤをストレージ手段１２に格納されるテーブルの項目と対照して、要求されたファイルのアドレス情報がテーブルに格納されているかどうかを判定する。格納されていない場合、メッセージは自ドメインのＳＮに送信される。格納されている場合、メッセージは判定により特定されたアドレスもしくはサーバに送信される。

応答メッセージ処理手段１５は、サーバからファイル要求への応答メッセージを取得し、当該メッセージからファイルのユーザアドレス情報を抽出し、抽出した情報をダウンロード手段（図示せず）に転送する。ダウンロード手段は、ファイルのユーザ（提供者）のアドレスからファイルをダウンロードする。

図５に示すように、本発明の本実施例によるＳＮは、通知メッセージ処理手段２１と、ストレージ手段２２と、リダイレクトメッセージ生成手段２３と、クエリメッセージ処理手段２４と、応答メッセージ生成手段２５と、通信手段２６とを含む。ＳＮとＳＮ−Ｒは同じ構成であるため、以下の説明はＳＮとＳＮ−Ｒの両方に該当する。

図５に示すように、通知メッセージ処理手段２１は、通信手段２６を介してユーザからメタデータ通知メッセージを取得し、データＩＤとユーザアドレスとを抽出し、そのデータＩＤを使用してストレージ手段２２に格納されるユーザ情報を検索する。検索結果がＳＮ−Ｒの場合、リダイレクトメッセージ生成手段２３は、どのスーパーノード（すなわち、どのＳＮ−Ｒ）が要求されたファイルの位置情報を格納しているかを示すリダイレクトメッセージを作成する。検索結果がＳＮ−Ｒではない場合、通知メッセージ処理手段２１はストレージ手段２２に新たな項目を追加する。

前述したように、ストレージ手段２２は、各ファイル（データＩＤで識別）と、ユーザ情報（アドレスで識別）またはＳＮ−Ｒとの間の対応情報が格納されるメタデータテーブルを含む。

リダイレクトメッセージ生成手段２３は、リダイレクトメッセージを作成し、それを該当する要求者に送信する。作成されたメッセージには、例えば、ｉ）データＩＤとｉｉ）ＳＮ−Ｒのアドレスとを含めることができる。

クエリメッセージ処理手段２４は、通信手段２６を介してユーザからファイル要求メッセージを取得し、ストレージ手段２２に格納されるメタデータテーブルに対して検索を実行する。検索結果がユーザ情報の場合、要求者に最も近い各ユーザの情報が選択され、応答メッセージ生成手段２５に転送される。検索結果がＳＮ−Ｒ情報の場合、リダイレクトメッセージ生成手段２３はリダイレクトメッセージを作成する。

応答メッセージ生成手段２５は、応答メッセージを作成し、それを要求者に送信する。応答メッセージには、例えば、ｉ）データＩＤとｉｉ）ファイル提供者のアドレスのテーブルとを含めることができる。

次に、図６と図７を参照して、本発明の本実施例によるユーザノードおよびサーバの詳細な構成と処理について説明する。図６は、本発明の一実施例による、共有ファイルの通知処理を説明するフローチャートである。

図６に示すように、ステップ６１においてユーザが他のユーザと映像ファイル等のリソースを共有することを所望する場合、通知メッセージ生成手段１１がステップＳ６２において、ストレージ手段１１に格納されるサーバルーティングテーブルに対して検索を実行し、当該ファイルのＩＤと当該ファイルの位置情報が当該テーブルに格納されているかどうかを判定する。

ステップＳ６２の判定結果がＹＥＳの場合、通知メッセージ生成手段１１はステップＳ６３において、判定により特定されたユーザに対し、共有するファイルのＩＤとユーザのアドレス（ＩＰアドレス、ポート番号、プロトコルなど）とを送信する。

ステップＳ６２の判定結果がＮＯの場合、通知メッセージ生成手段１１はステップＳ６４において、通知メッセージの送信により、当該ユーザと同じドメインのＳＮにファイルのＩＤとユーザ（提供者）のアドレスとを通知する。

ステップＳ６５において、当該ドメイン内のＳＮの通知メッセージ処理手段２１は、通知メッセージの受信後に、共有するファイルが人気ファイルなのかあるいは不人気ファイルなのかを判断する。共有するファイルが人気ファイルの場合、ステップＳ６６において、当該ファイルに関する情報がＳＮのストレージ手段に格納される。共有するファイルが不人気ファイルの場合、ステップＳ６７において、当該ファイルに関する情報がＳＮ−Ｒ１のストレージ手段に格納される。

図７は、本発明の一実施例による、ファイルの位置情報の要求処理を説明するフローチャートである。図７に示すように、ステップＳ７１において、ユーザノードが映像ファイル等のリソースに関するクエリの実行を所望する場合、ユーザノードのクエリメッセージ生成手段１４はまずステップＳ７２において、リソースのＩＤと、リソースの位置情報を格納するサーバの名前とが、ストレージ手段１２に格納されるサーバルーティングテーブルに格納されているかどうか判定する。

ステップＳ７２の判定結果がＹＥＳの場合、ステップ７３において、クエリメッセージ生成手段１４がクエリメッセージを作成し、判定対象のサーバにリソースの位置情報を要求し、続くステップＳ７４において、サーバがユーザノードにリソースの位置情報を送信する。

ステップＳ７２の判定結果がＮＯの場合、ユーザノードのクエリメッセージ生成手段１４はステップＳ７５において、同じドメイン内のＳＮに当該リソースの位置情報を要求するメッセージを送信する。続くステップＳ７６において、当該ＳＮ内のクエリメッセージ処理手段２４はストレージ手段２２に格納されるユーザ情報テーブルを検索して、当該テーブルにファイルの位置情報が格納されているかどうか判定する。当該テーブルに格納されている場合、ステップＳ７４において、応答メッセージ生成手段２５が通信手段２６を介してファイルの位置情報を当該ユーザノードに送信する。当該テーブルに当該ファイルの位置情報が格納されておらず、それがＳＮ−Ｒ１に格納されていることだけが示されている場合には、ステップＳ７７において、ＳＮ内のリダイレクトメッセージ生成手段２４が、位置情報がＳＮ−Ｒ１に格納されていることを示すリダイレクトメッセージを生成し、通信手段２６を介してそれをユーザノードに送信する。

その後、ステップＳ７８において、リダイレクトメッセージの受信後、ユーザノードのリダイレクトメッセージ処理手段１３がストレージ手段１２に格納されるテーブルを更新し、クエリメッセージ生成手段１４がクエリメッセージをＳＮ−Ｒ１に送信する。

その後、ステップＳ７４において、ＳＮ−Ｒ１がユーザノードに当該リソースの位置を返す。

したがって、本発明の一実施例によれば、ユーザ（例えば、ユーザＤ）は人気ファイル（例えば、図４のＤ１）をクエリする際に、当該ファイルと同じドメイン内のサーバ（図４のＳＮ−Ｉ）に要求を送信でき、当該サーバは当該ユーザにファイルの提供者情報を直接返すことができる。

本発明の一実施例によれば、ファイルの人気度はそのコンテンツによって決まる。しかし、特定の状況下においては、ファイルの人気度が時間の経過と共に変動することがある。一例としては、夜間にはＰ２Ｐネットワーク内のほとんどのユーザがオフライン状態になり、各ＳＮに格納される人気ファイルのユーザ情報の変動量が減少して不人気ファイルに変わる、というような状況が挙げられる。このような場合には、ユーザ情報を同じＳＮ−Ｒに格納することができれば、システムの性能が向上する可能性がある。これを実現するには、人気度が変動したファイルの位置情報を転送することが必要となる。

図８は、本発明の一実施例による、ネットワーク内のネットワークサーバのブロック図である。図８に示すように、本発明の一実施例によるスーパーノードは、図５に示すのと同じ手段に加えて、情報監視手段２７と、転送メッセージ生成手段２８と、転送メッセージ処理手段２９とをさらに備える。本実施例によれば、上記のＳＮは、ファイルの人気度（例えば、所定の期間中におけるファイルへのアクセス回数など）を監視するための情報監視手段２７と、ファイルの位置情報を転送するための転送メッセージ生成手段２８と、他のＳＮから送られてきた転送メッセージを処理するための転送メッセージ処理手段２９を備える。ファイルの人気度が「人気」から「不人気」に変わると、転送メッセージ生成手段２９が、ストレージ手段２２内のローカルメタデータテーブルに格納されるユーザ情報を対応するＳＮ−Ｒに転送し、当該ＳＮ−Ｒのアドレスをローカルメタデータテーブルに設定する。これにより、ユーザがこのファイルを再度要求することを所望する場合には、ＳＮのリダイレクトメッセージ生成手段２３がリダイレクトメッセージを生成してユーザに通知し、またその逆を行うことが可能となる。

図８に示すように、情報監視手段２７はファイルの人気度を監視することができる。本発明の一実施例によれば、ファイルの人気度が変動したかどうかの判定は以下の手順で実行される。すなわち、ＳＮにおいて、所定の期間中におけるファイルにアクセスするユーザ数またはファイルを処理するユーザ数が所定のしきい値を下回る場合、そのファイルは不人気ファイルに変わったと判定される。ＳＮ−Ｒにおいて、所定の期間中にファイルにアクセスするユーザ数またはファイルを処理するユーザ数が所定のしきい値を上回る場合、そのファイルは人気ファイルに変わったと判定される。

転送メッセージ生成手段２８は、転送メッセージを作成し、それをＳＮ−Ｒに送信する。本発明の一実施例によれば、ＳＮ−Ｒの選択はファイルのデータＩＤのハッシュ値に基づいて行われる。このハッシュアルゴリズムとしては、例えばコンシステントハッシュ（Ｃｏｎｓｉｓｔｅｎｔ Ｈａｓｈ）を使用することができる。当該アルゴリズムは、ｎ個の不人気ファイルとｋ個のＳＮ−Ｒを対象に、各ＳＮ−Ｒがｎ／ｋ個のファイルを扱うように調整して、ＳＮ−Ｒ間の負荷の平衡を保つ。ＳＮ−Ｒ内のコンポーネントは、名前がバッファリング手段（図示せず）に格納されるすべてのＳＮにメッセージを送信する。

転送メッセージ処理手段２９は、ネットワークから転送メッセージを取得し、転送するリソースの位置情報を抽出し、それをストレージ手段２２内のローカルメタデータテーブルに挿入する。一方、ＳＮ−Ｒのコンポーネントは、ＳＮのアドレスをバッファリングする。

上記の説明では好適な実施例の詳細を示したが、本発明はこれに限定されず、当該技術に精通する当業者が本発明の開示の範囲内において考案可能な変更や置換をも内包する。したがって、本発明の範囲は付記した請求項によって定義される。

１１：通知メッセージ生成手段
１２：ストレージ手段
１３：リダイレクトメッセージ処理手段
１４：クエリメッセージ生成手段
１５：応答メッセージ処理手段
１６：通信手段
２１：通知メッセージ処理手段
２２：ストレージ手段
２３：リダイレクトメッセージ生成手段
２４：クエリメッセージ処理手段
２５：応答メッセージ生成手段
２６：通信手段
２７：情報監視手段
２８：転送メッセージ生成手段
２９：転送メッセージ処理手段

Claims (18)

1. Ｐ２Ｐネットワーク上におけるリソースの位置情報の要求方法であって、
   ２Ｐネットワークが、各ドメインにおける第１の人気度を有するリソースの位置情報と第２の人気度を有するリソースの位置情報の格納アドレスとを格納する１つ以上の第１サーバと、第２の人気度を有するリソースの位置情報を各々格納する１つ以上の第２サーバとを備え、
   ユーザノードが自ドメイン内の前記第１サーバにリソースの要求を送信するステップと、
   前記第１サーバが当該リソースの位置情報を格納していない場合に、前記第１サーバから前記ユーザノードに、どの第２サーバが当該リソースの位置情報を格納するかを示すメッセージを送信するステップと、
   前記メッセージに基づいて、前記ユーザノードから前記第２サーバに位置情報の要求を送信するステップと
   を含むことを特徴とするリソースの位置情報の要求方法。
2. 前記ユーザノードが、要求された位置情報を有するサーバのアドレスが既に登録され或いは以後に登録されるテーブルを備え、
   リソースの位置情報の格納アドレスが前記テーブルに格納されているかどうかを判断するステップを含み、
   リソースの位置情報の格納アドレスが前記テーブルに登録されていない場合、前記ユーザノードが、前記第１サーバに対してリソースの位置情報の要求を送信することを特徴とする請求項１に記載のリソースの位置情報の要求方法。
3. 前記第１サーバから受信したメッセージに基づいて前記テーブルを更新するステップを含むことを特徴とする請求項２に記載のリソースの位置情報の要求方法。
4. 前記第２の人気度が前記第１の人気度より低く、
   リソースの人気度が、前記第１の人気度から第２の人気度へ変動した場合、前記第１サーバから前記第２サーバへ、リソースの識別情報と位置情報を送信するステップと、
   リソースの人気度が、前記第２の人気度から第１の人気度へ変動した場合、前記第２サーバから前記第１サーバへ、リソースの識別情報と位置情報を送信するステップを含むことを特徴とする請求項１に記載のリソースの位置情報の要求方法。
5. 所定の期間中に、リソースのアクセス数またはリソースを処理するユーザ数が所定のしきい値を下回る場合、当該リソースの人気度を第２の人気度とし、
   所定の期間中に、リソースのアクセス数またはリソースを処理するユーザ数が所定のしきい値を上回る場合、当該リソースの人気度を第１の人気度とすることを特徴とする請求項４に記載のリソースの位置情報の要求方法。
6. 前記第２サーバの負荷の平衡を保つために、異なるリソースの識別情報と位置情報を、それぞれ第２サーバへ送信するステップを含むことを特徴とする請求項４に記載のリソースの位置情報の要求方法。
7. Ｐ２Ｐネットワーク上におけるリソースの位置情報のアップロード方法であって、
   ２Ｐネットワークが、各ドメインにおける第１の人気度を有するリソースの位置情報と第２の人気度を有するリソースの位置情報の格納アドレスとを格納する１つ以上の第１サーバと、第２の人気度を有するリソースの位置情報を各々格納する１つ以上の第２サーバとを備え、
   ユーザノードが自ドメイン内の前記第１サーバにリソースの識別情報とユーザノードのアドレスとを通知するステップと、
   リソースが第１の人気度を有する場合に、前記第１サーバにリソースの識別情報とユーザノードのアドレスとを格納するステップと、
   リソースが第２の人気度を有する場合に、前記第１サーバから前記ユーザノードに、どの第２サーバがリソースの位置情報を格納しているかを示すメッセージを送信するステップと、
   メッセージで示された第２サーバに対して、前記ユーザノードからリソースの識別情報とユーザノードのアドレスとを送信するステップと
   を含むことを特徴とするアップロード方法。
8. 前記第２の人気度が前記第１の人気度より低く、
   所定の期間中に、リソースのアクセス数またはリソースを処理するユーザ数が所定のしきい値を下回る場合、当該リソースの人気度を第２の人気度とし、
   所定の期間中に、リソースのアクセス数またはリソースを処理するユーザ数が所定のしきい値を上回る場合、当該リソースの人気度を第１の人気度とすることを特徴とする請求項７に記載のアップロード方法。
9. 前記第２サーバの負荷の平衡を保つように、リソースの識別情報と位置情報を、少なくとも１つの前記第２サーバへ送信するステップを含むことを特徴とする請求項４に記載のアップロード方法。
10. Ｐ２Ｐネットワーク上におけるリソースの位置情報を要求するユーザノードであって、
    ２Ｐネットワークが、各ドメインにおける第１の人気度を有するリソースの位置情報と第２の人気度を有するリソースの位置情報の格納アドレスとを格納する１つ以上の第１サーバと、第２の人気度を有するリソースの位置情報を各々格納する１つ以上の第２サーバとを備え、
    前記ユーザノードが、
    要求された位置情報がすでに登録されまた以後登録されるテーブルを格納する格納手段と、
    前記テーブル内に要求位置情報が登録されていない場合に、自ドメイン内の前記第１サーバにリソースの要求を送信し、どの第２サーバが当該位置情報を格納するかを示すメッセージを受信した場合に、前記メッセージに基づいて前記第２サーバに当該位置情報の要求を送信するクエリ手段と
    を備えることを特徴とするユーザノード。
11. 前記第１サーバから送信されたメッセージに基づいて前記テーブルを更新する手段をさらに備えることを特徴とする請求項１０に記載のユーザノード。
12. 前記第２の人気度が前記第１の人気度より低く、
    自ドメイン内の前記第１サーバに対して、共有するリソースの識別情報とユーザノードのアドレスを通知し、どの第２サーバが識別情報とアドレスを格納すべきかを示すメッセージを受信した場合に、当該第２サーバに対してリソースの識別情報と前記ユーザノードのアドレスを通知する通知手段を備えることを特徴とする請求項１０に記載のユーザノード。
13. Ｐ２Ｐネットワーク内のサーバであって、
    各ドメインにおける第１の人気度を有するリソースの位置情報と第２の人気度を有するリソースの位置情報の格納アドレスを格納する格納手段と、
    ユーザノードからリソースの位置情報の要求を受信するクエリメッセージ処理手段と、
    前記格納手段が位置情報を格納していない場合に、要求された位置情報がネットワーク上のどの位置に格納されているかを示すメッセージを前記ユーザノードに送信して、前記ユーザノードが当該メッセージに示される位置から位置情報を取得できるようにするリダイレクトメッセージ生成手段と
    を備えることを特徴とするサーバ。
14. 共有するリソースの識別情報とユーザノードのアドレスを前記ユーザノードから受信する通報処理手段を備え、
    前記第２の人気度が前記第１の人気度より低く、
    リソースが第１の人気度を有する場合、前記通知処理手段はリソースの識別情報およびユーザノードのアドレスを前記格納手段に格納し、
    リソースが第２の人気度を有する場合、前記リダイレクトメッセージ生成手段はリソースが格納される位置を示すメッセージを前記ユーザノードに送信し、前記ユーザノードがメッセージに示される位置から位置情報を取得できるようにすることを特徴とする請求項１３に記載のノード。
15. ネットワーク上のリソースの人気度の変動を監視する人気度監視手段と、
    リソースの人気度が第１の人気度から第２の人気度へ変動した場合、他のノードにリソースの識別情報と位置情報を転送する情報転送手段とを備えることを特徴とする請求項１４に記載のノード。
16. 所定の期間中に、リソースのアクセス数またはリソースを処理するユーザ数が所定のしきい値を下回る場合、当該リソースの人気度を第２の人気度とし、
    所定の期間中に、リソースのアクセス数またはリソースを処理するユーザ数が所定のしきい値を上回る場合、当該リソースの人気度を第１の人気度とすることを特徴とする請求項１５に記載のノード。
17. 前記情報転送手段は、他のノードの負荷の平衡を保つように、他のノードの１つにリソースの識別情報とリソースの位置情報を送信することを特徴する請求項１５に記載のノード。
18. Ｐ２Ｐネットワーク内のサーバであって、
    リソースの位置情報を格納する格納手段と、
    前記リソースのネットワーク上における人気度の変動を監視する監視手段と、
    前記リソースの人気度がその人気度よりも高い他の人気度に変動した場合に、リソースの識別情報と位置情報とを他のノードに転送する情報転送手段と
    を備えることを特徴とするサーバ。
    

Images