(57)【要約】本発明は、スケーラブルピアツーピアネットワークにおけるディレクトリサービス形成方法に関し、ここで少なくとも１つのピアを有するグループにこのディレクトリサービスを分割して複数の部分集合にし、資源を公開および／または資源を検索問い合わせするため、割り当てルールを介し、上記資源に依存して、あらかじめ定めたアドレス空間から割り当て値を形成し、各割り当て値をただ１つのグループによって管轄し、上記の資源の公開または資源の検索問い合わせを前記の管轄グループだけに伝達する。
2005502289.tif 000002
【特許請求の範囲】
【請求項１】
スケーラブルピアツーピアネットワークにおけるディレクトリサービス形成方法において、
少なくとも１つのピアを有するグループに該ディレクトリサービスを分割して複数の部分集合にし、
資源を公開および／または資源を検索問い合わせするため、割り当てルールを介し、前記資源に依存して、あらかじめ定めたアドレス空間から割り当て値を形成し、
各割り当て値をただ１つのグループによって管轄し、
前記の資源の公開または資源の検索問い合わせを前記の管轄グループだけに伝達することを特徴とする、
ディレクトリサービス形成方法。
【請求項２】
前記の管轄グループだけに宛てられる前記の資源の公開または資源の検索問い合わせをＩＰマルチキャスティングによって行う、
請求項１に記載の方法。
【請求項３】
１グループに１つのマルチキャストＩＰアドレスを割り当てる、
請求項２に記載の方法。
【請求項４】
割り当てルールとしてハッシュ法を使用し、
該ハッシュ法を用いて、割り当て値としてハッシュ値を計算する、
請求項１から３までのいずれか１項に記載の方法。
【請求項５】
前記のマルチキャストＩＰアドレスへのハッシュ値の一意的な割り当てを、有利にはアドレステーブルによって行う、
請求項４に記載の方法。
【請求項６】
複数のピアを有するグループ内に、公開された資源および所属のピアについての情報を冗長に設ける、
請求項１から５までのいずれか１項に記載の方法。
【請求項７】
前記の管轄グループ内では選択されたただ１つのピア、有利には最初のピア、またはホップカウントを介して決定される隣のピアだけが応答する、
請求項１から６までのいずれか１項に記載の方法。
【請求項８】
資源を公開する際に、存在する管轄グループの負荷に依存してピアを当該グループに能動的に加えるか、またはピアを受動的に待ちリストに設定する、
請求項１から７までのいずれか１項に記載の方法。
【請求項９】
ピアをその負荷に依存して、グループの能動的なメンバから受動的なメンバに変更する、
請求項８に記載の方法。
【請求項１０】
コンピュータプログラム製品において、
該コンピュータプログラム製品は、計算装置の作業用メモリにロードされ、
前記コンピュータプログラム製品が計算装置にて動作する場合、請求項１から９までのいずれか１項に記載の方法を実行するためのソフトウェアコードを有することを特徴とする
コンピュータプログラム製品。
【請求項１１】
データ担体において、
請求項１０に記載のコンピュータプログラム製品を有することを特徴とする、
データ担体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、請求項１の上位概念に記載された、スケーラブルピアツーピアネットワークにおけるディレクトリサービス形成方法に関する。
【０００２】
例えばNapster，Gnutella，Freenetなどの公知のスケーラブルピアツーピアネットワーク、すなわちペアの個数が制限されていないピアツーピアネットワークにおいて、ピアすなわち計算機は、使用登録し、使用登録した全ピア内でファイルを検索したり、および／または別のピアによるアクセスに対してそれ自体でファイルを公開する（いわゆるファイル共有）ことが可能である。
【０００３】
ここで集中形のピアツーピアネットワークにおいて、複数のピアは１つまたは複数の中央のサーバにおいて使用登録され、またこれらのピアによって公開されたファイルは、１サーバで動作するディレクトリサービスによって登録される。
【０００４】
所定のファイルの検索に対してピアは、相応する検索問い合わせをサーバに行い、これに基づきこのサーバは、このファイルを公開しているピアのリストをこのピアに送信する（ディレクトリサービス）。つぎに検索しているピアは、これらのピアのうちの１つを選択して、このピアにファイルを直接要求するか、ないしはこれから直接ダウンロードするのである。
【０００５】
例えばNapster，iMesh，Audiogalaxy，Songspyなどの集中形のピアツーピアネットワークにおいて欠点であるのは、中央のサーバの利用可能性に依存することであり、この中央のサーバがなければ、ディレクトリサービスは機能せず、ひいては使用登録も、登録も、公開されたファイルの検索も共に機能しないのである。
【０００６】
さらにディレクトリサービスに対して、中央のサーバがない非集中形のピアツーピアネットワークもある。ここではピアは、ネットワークの別のピアを動的に見つけてこれと通信して、データおよび情報を交換する。このような非集中形のネットワークの機能および利用可能性は有利にも、中央のサーバの機能および利用可能性に依存しない。しかしながらピアは、それ自体で行き着かなければならない。これは通例、局所的であり所定の近さの内側だけでしか行われないか（例えば最大のホップカウントを有するＩＰマルチキャスティングによる）、または前もって分かっているピアのリストを介してしか行われない。ここでこのリストは、手で作成されるかまたは専用のサーバに要求される。
【０００７】
このため、非集中形のピアツーピアネットワークには独立したルーティングプロトコルが必要であり、このプロトコルによってデータを種々異なるピアを介してルーティングするのである。ファイルの検索に対してピアは、検索問い合わせをそのピアに既知のピアに伝達し、このピアはピアで同じようにする。このようにして、ネットワーク全体（すべてのピア）は検索問い合わせで満たされ、この検索問い合わせに相応するファイルを公開していた各ピアは、この検索を開始したピアにこのことを通知するのである。これに基づき、検索したピアは、これらのピアの１つを選択して、ファイルをこのピアに要求することができるのである。
【０００８】
例えばGnutella，KaZaA，Freenet，MojoNation，Edonkey2000などのこのような非集中形のピアツーピアネットワークではディレクトリサービスは提供されない。すなわち、公開されたファイルについての情報を有する呼出可能なリストはネットワークに存在しないのである。このような非集中形のピアツーピアネットワークにおける検索は、ネットワーク全体が満たされる必要があることにより、比較的時間を多用しまた効率も悪い。
【０００９】
したがって本発明の課題は、ピアツーピアネットワークにおけるディレクトリサービス形成方法を提供して、公開された資源の高速かつ効率的な検索を可能にし、またピアツーピアネットワークの高い利用可能性および動作を保証することである。
【００１０】
この課題は、本発明により、請求項１，１０および１１の特徴的構成を有する方法、コンピュータプログラム製品およびこのようなコンピュータプログラム製品を有するデータ担体によりそれぞれ解決される。
【００１１】
ディレクトリサービスを複数のグループに分けることによって、検索問い合わせを高速かつ効率的に相応するグループに伝達し、応答をもらうことができ、その際にネットワーク全体の利用可能性および動作が中央の１サーバに依存することがない。
【００１２】
ここでは資源の公開または資源の検索のための問い合わせは、ピアツーピアネットワークの一部のピアだけに伝達するだけでよいため、ネットワーク全体が満たされるのに比して、検索または公開の効率および速度が有利にも増大する。しかしながら同時に（極めて確率の低い）１グループまるごとのダウンにより、ピアツーピアネットワーク全体が動作不能になってしまうこともない。
【００１３】
１グループまるごとのダウンは本発明により防止することでき、ここでこれは複数のグループメンバーが同じ情報を記憶することによって行われる。このようにグループを構成することにより、有利にも１グループ内で情報の冗長性が得られるため、１グループの個々の計算機のダウンにより、公開されたファイルについて情報（ディレクトリ）が失われてしまうことがない。
【００１４】
本発明の有利な実施形態において、１グループへの資源の割り当ては、割り当てルール、例えばハッシュ法を介して行われ、このルールを用いて、割り当て値、例えばハッシュ値が、所定の制限された値域から、資源ないしはその既知のパラメタに依存して計算される。
【００１５】
ここでパラメタとして例えば、資源の種類、資源の名称などを使用可能である。例えば、公開すべき資源としてのファイルに対して（ファイル共有アプリケーション）１６ビット幅（すなわち０〜６５５３５の値域ないしはアドレス空間から）のハッシュ値をファイル名ないし名前の部分から計算することが考えられる。
【００１６】
このような割り当ては必ずしも一意的である必要はなく、ちょうど１つの割り当て値、例えばハッシュ値を１つのグループが一意的に管轄する場合であっても、１つのグループはふつう複数の資源を管轄する。
【００１７】
本発明の有利な実施形態では、上記のように計算される割り当て値は、例えばアドレステーブルによって、一意的にただ１つのマルチキャストＩＰアドレスにマッピングされ、ここで１グループは１マルチキャストＩＰアドレスだけを管轄し、各問い合わせは、管轄の１つまたは複数のグループにそれぞれ伝達される。
【００１８】
しかしながらつぎようにすることも当然考えられる。すなわち複数のマルチキャストＩＰアドレスまたは所定の既知のアドレス空間からなる全領域を１グループに割り当てることも当然考えられる。この際に相応にあらかじめ定めた限界値ないしは閾値を介して、これらのグループの大きさおよび効率をそれ自体で管理することもできる。例えば考えられるのは、ピアの１グループが、最大の大きさ（ピアの個数）に達した際に２つのグループに分割され、各グループが、同様に分割された（例えば半分にされた）アドレス領域を管轄することである。この場合、このような新たな分割を付加情報として各対話（検索問い合わせ、使用登録および資源の公開）の際に伝達することができ、これにより、ここでも各問い合わせが１つまたは複数の管轄のグループだけにそれぞれ伝達されるのである。
【００１９】
問い合わせの伝達（公開または検索）は、本発明によれば、有利にはＩＰマルチキャスティングを用いて、例えばＩＰベースの比較的大きなネットワーク内で、有利にはインターネット上で行われる。これにより有利にも検索は、公知のピアツーピアルーティングに比べて高速かつ効率的に行われる（アプリケーションレベルでのルーティングはもはや行われない）。
【００２０】
本発明の有利な実施形態では、（公開された資源、対応するピアないしはそれらのＩＰアドレスなどについての）情報は、１グループ内で複数のピアの冗長に設けられる。これにより、１グループ内の個々のピアまたは複数のピアがダウンした際にもこのグループの動作は維持され有利である。
【００２１】
本発明の別の実施形態では、管轄のグループ内で、選択された１つのピアだけが問い合わせ（検索または公開）に応答する。このため、全グループメンバと対話するのに比べて問い合わせまたは結果の速度を増大させることができ有利である。応答するないしは対話を行うピアの選択は、例えば、距離の測定基準を介して（例えば最も小さなホップカウントまたは類似のもの）またはあらかじめ定めた物のルール、例えばグループの最初のメンバ（最初に使用登録したメンバ）によって行われる。
【００２２】
本発明の別の実施形態において、資源の通知ないしは公開の際に新たなピアに通知されるのは、ＩＰマルチキャストによって問い合わせを伝達した１つまたは複数のグループの能動的なメンバまたは受動的なメンバのいずれにこのピアがなるべきであるかである。この際に能動的または受動的なメンバについての判断は、有利にはグループの負荷ないしは最大負荷に依存し、これは、通例のメカニズムを介して個々のパラメタ（検索問い合わせの数、伝送速度）からまたはこれらの任意の組み合わせから得られるものである。あらかじめ定めた負荷の所定の閾値を上回る場合、使用登録の際に新たなピアに通知されるのは、このピアがこのグループの能動的なメンバになるべきであり、このピアがこのグループの情報を伝送することである。
【００２３】
上記の閾値と同じとすることができるが必ずしもそのようにする必要のない所定の閾値を負荷が下回る場合、使用登録の際に新たなピアに通知されるのは、このピアがこのグループの受動的なメンバにだけなれることである。このような受動的なメンバは、例えば、（例えば問い合わせ時点または別の判定基準にしたがってソートされる）待ちリストに導かれ、グループの負荷の閾値を上回った場合、順番に能動化される。
【００２４】
本発明の別の実施形態では、個々の能動的なグループメンバ（ピア）は、その固有の（ピアの）負荷の限界値に達した場合または動作障害の場合にこのグループの受動的なメンバにされ、場合によっては別の受動的なメンバによって置き変えられることがある。例えば、それはこのグループの最大負荷の限界値がこれによって上回ってしまったか、または基本的な交換ルールが存在するからである。
【００２５】
本発明の別の有利な実施形態は従属請求項に記載されている。
【００２６】
本発明を以下、図面に示した実施例に基づいて詳しく説明する。図面において、
図１は、本発明による分散形ディレクトリサービスを有するピアツーピアネットワークにおいて、新たなピアの資源を登録および公開するための流れ図（資源登録およびグループ形成）を示しており、
図２は、本発明による分散形ディレクトリサービスを有するピアツーピアネットワークにおいて、資源を検索するための流れ図（資源検索および伝送）を示している。
【００２７】
この実施例に示されているのは本発明の方法であり、これはファイル共用の適用、すなわちファイルを共同で理由できるようにすることにも基づいている。ここでハッシュ値は、例えば１６ビット幅であり、ファイル名の個々の語から生成される（例えば、Javaのストリングクラスの標準アルゴリズムのような標準アルゴリズムによる）。マルチキャストＩＰアドレス領域として、この実施例では239.192.0.0〜239.192.255.255が選択され、これはIANAより組織内部の適用に対してリザーブされており（RFC2365）、例えば任意の会社は自由に使用可能である。
【００２８】
以下では、ピアがネットワークにどうのようにして入れられるか、ピアがその公開したファイルをこのネットワークにどのように登録するか（図１）、このネットワーク内で検索がどのように行われる（図２）かの過程を図１および図２に記載した流れ図にしたがって詳しく説明する。
【００２９】
図１に記載のファイルの登録ないしは公開
ファイルを利用可能にするため、ピアはそのハッシュ値を計算し（すなわち、例えば、"Killer Queen"なる名前に基づいて、ないしは空白文字またはあらかじめ定めた別の分離文字によって分離される名前の構成部分"Killer"および"Queen"に基づいて、Javaのストリングクラスのハッシュ関数を用いて計算し）、登録問い合わせ"Multicast Register Resource(Killer Queen)"を、対応するマルチキャストアドレスに送信する。ここでこのマルチキャストアドレスは、このピアにより、このピアに存在するアドレステーブルから一意的に求められる。
【００３０】
ここで新しいピアには、マッピングルール（資源に依存してハッシュ値を求め、相応するマルチキャストＩＰアドレスにマッピングすること）だけでなく、ハッシュ値の値域も、マルチキャストＩＰアドレスのアドレス空間も（例えば、このピアで動作するクライアントソフトウェアの形態で）既知である。
【００３１】
ここでは上記の登録問い合わせにより、公開する資源の名称、例えばファイル"Killer Queen"およびこのピアの固有のＩＰアドレス、例えば138.24.67.88に付加的に、一意の識別情報、例えば、パケット（登録パケット）におけるいわゆるＵＵＩＤ（Universal Unique Identifier）を伝達することも可能である。
【００３２】
別のピアがこのマルチキャストＩＰアドレスをまだ管轄していないか、ないしは担当していない場合、（この別のピアに対してタイムアウト（Timeout）、例えば"Timer ＞ 1min"に基づいて識別されるか、ないしは相応する応答パケットがなく、場合によって失敗の繰り返し（あらかじめ定めた試行回数）の後はじめて）、当該のピアは以降、このマルチキャストＩＰアドレスへの検索および登録問い合わせをそれ自体で管理する。
【００３３】
このためにこのピアはＩＰマルチキャスト"Join Group"パケットを送信して、このマルチキャストアドレスに当てられるパケットを受け取り、ないしは公開する自身の資源（上に挙げた付加情報、すなわちＩＰアドレス、名称などを含ｄ）をその（グループ）資源テーブルに記入する。
【００３４】
上記とは異なる場合、このピアは、このグループの少なくとも１つのピアによるその登録問い合わせの確認"Unicast Register Response"を受け取り、これによってこのピアが能動的または受動的なグループメンバのどちらになるか、すなわちこのピアが、以降、このマルチキャストＩＰアドレス宛の問い合わせを処理すべきであるのか、または待ちリストに記入されて、場合によってはのちに、このマルチキャストＩＰアドレスに対応付けられた情報の能動的な管理者のグループに入れられるのいずれであるかという通知を受け取るのである。能動的または受動的なメンバ資格についての判定は、ここでこのグループの負荷（ＣＰＵ負荷、記憶容量など）に依存して行われる。
【００３５】
ピアが能動的な管理者になる場合、このピアは、このグループへの"Multicast Group Join Request"の後、登録された資源についての目下の情報"Unicast Resource List Update"と、少なくとも１つのグループメンバとについての目下の情報を受け取る（例えば、ftpを介した別のグループメンバの資源テーブルのダウンロードおよびユニキャストによる資源テーブルの更新）。ここで上記の少なくとも１つのグループメンバは、あらかじめ定めた選択方式によって求めた別の能動的なグループメンバである。
【００３６】
ピアのネットワークコネクションまたはシステム資源が、１つまたは複数のグループに所属することによって、例えばＣＰＵの高負荷、記憶容量が少なすぎることなどによって過負荷になると、このピアはトリガを行って、受動的なグループメンバになることが可能である。
【００３７】
上で（図１の上半分で）説明した問い合わせたピアの問い合わせに対するこのグループないしは１グループの少なくとも１つのピアのアクションないしはリアクションが、わかりやすくするため図１の下半分に流れ図として示されている。これによると、（登録）問い合わせをしたピアは、管轄でありかつグループが過負荷でない場合だけ、応答"Unicast Register Response"により、能動的なメンバになる（Join = true）という応答を受け取る。そうでなければ、問い合わせたピアは、図示のように待ちリストに記入される。
【００３８】
例：
ピア「ｘｙｚ」はファイル"Killer Queen"を公開したい、とする。このピアは、２つの語に対してハッシュ値を生成する。"Killer"に対してはハッシュ値を12345とし、"Queen"に対してはこれを42424とする。ここでこのピアは、登録情報をマルチキャストＩＰアドレス(12345-＞)239.192.48.57および(42424-＞239.192.165.184)に送信する。このピアがその元々の情報に対して得た応答ならびにその負荷状態に基づき、このピアは、これらのマルチキャストＩＰアドレスに割り当てられた２つのグループにおいて能動的または受動的なメンバになるのである。
【００３９】
図２に記載のファイル検索
ピアはファイルをその「キーワード」、例えば"Killer"または"Queen"に基づいて探すことができる。ピアが例えばファイル名に"Queen"を有するファイルを検索する場合、このピアはこの語に対するハッシュ値（42424）を生成し、例えばアドレステーブルを用いてこのハッシュ値に対するマルチキャストＩＰアドレス（239.192.165.184）を求め、ファイル名に"Queen"またはこの実施例のように"Killer Queen"を有するファイルを求める問い合わせ"Multicast Query Resource (Killer Queen)"を、ＩＰベースのネットワークを介して上記のマルチキャストＩＰアドレスに送信し、応答（Unicast Query Response）を待つ。ここで上記の送信は、例えば、固有のＩＰアドレス，ＵＵＩＤなどの別の情報を有するパケットとして行われる。
【００４０】
該当するグループ内では（例えば、ラウンドロビン方式またはこれと類似の所定の選択ルールにしたがって）１つまたは複数のピアが選択され、これらのピアは、検索問い合わせ"Multicast Query Resource (Killer Queen)"に"Unicast Query Reponse"で応答し、問い合わせたピアにピアのリストを与える。これらのピアからこのピアはファイル名に"Queen"を有するファイルを直接受け取ることができる。
【００４１】
応答"Unicast Query Response"に例えばグループがないか、またはあらかじめ定めた時間インターバル内に、例えばTimer ＜ 1minに到着しない失敗の伝送エラーの場合、問い合わせたピアでは、場合によっては所定の回数、繰り返しを試行した後、結果として「該当するものが見つからない」が出力される。
【００４２】
図２の下半分に示したように、問い合わせたピアは、これらのピアの１つまたは複数に直接の問い合わせ"Unicast Resource Request"（ＩＰユニキャスティング）を開始して、あらかじめ定めた制限時間"Timer = 30 sec"内にコネクションが成功した際には、検索した資源、例えばファイル"Killer Queen"を有する応答"Unicast Resource Response"を受け取ることができる。
【００４３】
例えば、検索したピアがオフラインであるかまたは別のコネクションエラーのため、タイマを用いて監視される制限時間を超過した場合、問い合わせたピアは、これらのピアまたは伝達されたリストの別のピアに、別途または後に状況が変わった場合にコネクション問い合わせ"Unicast Resource Request"を行うことできる。
【００４４】
以下では、この実施例で使用した方法を詳しく説明する。
【００４５】
ハッシュ法
ピアが公開したい資源毎に１つまたは複数のハッシュ値が（決まった範囲ないしはアドレス空間で、例えば１６ビットのハッシュ値では０〜６５５３５で）生成される。これはすべてのピアに既知であるハッシュ関数によって行われる。資源は例えばファイルとすることが可能であり、ハッシュ値はこの場合にファイル名から（より有利には名前の個々の「語」から）生成される。しかしながらハッシュ値は、資源を特徴付ける別のパラメタからなる組み合わせまたはこれらを個々に使用することによって形成することも可能であり、これらのパラメタは、例えば、分散形サービスに対するサービス名（Jini，.NETなど）、ファイルの種類ないしは拡張子（.doc，.mp3，.jpg，.mpgなど）その他である。これにより、本発明の方法はファイル共用の適用に限定されず、任意のサービス（プリンタ共用、モデム共用など）に使用可能である。
【００４６】
ハッシュ値毎にピアのグループがちょうど１つ存在し、このグループがこのハッシュ値を管轄する。
【００４７】
所定のハッシュ値を有する資源は、このハッシュ値に割り当てられているピアのグループにおいて登録される。ここでは１グループは、この実施例におけるのと同様に１つのハッシュ値だけを管轄する。しかしながら上述のように本発明の別の実施形態を考えることができ、ここでは１グループが、所定の範囲（例えば32768〜65535）の複数のハッシュ値を管轄する。
【００４８】
ピアは、資源のハッシュ値毎にこの資源をグループにおいて登録する。ここでグループはこのハッシュ値を管轄するグループである。
【００４９】
検索問い合わせに対しても同様にハッシュ値が生成される。このハッシュ値に対して、管轄のグループが求められ、これに対して検索問い合わせが行われる。グループないしは相応するルール（ランクリスト、問い合わせを行ったピアに最も近いないしホップカウントの最も小さい）によって選択されたこのグループのピアは、検索したピアに検索の結果を直接伝達する。
【００５０】
この実施例では割り当てルールとしてハッシュ法を選択したが、ハッシュ法について上述したステップを転用することができる任意の割り当て方法を使用することも当然考えられる。このため本発明はハッシュ法の使用には制限されない。
【００５１】
グループ形成
ピアの各グループには所定の範囲の１マルチキャストＩＰアドレスが割り当てられる。この範囲の大きさは、使用するハッシュ値（例えば１６ビットのハッシュ値ではマルチキャストＩＰアドレスはx.y.0.0〜x.y.255.255の範囲が必要である）から得られる。
【００５２】
ピアが資源を利用可能にしたい場合、このピアはこの資源のハッシュ値を求め、所属のマルチキャストＩＰアドレスにこの資源の位置を発表する。このマルチキャストＩＰアドレスへのメッセージを管轄する受信者が存在しない場合、このピアそれ自体がこのアドレスを管轄し、以降、到来する登録メッセージおよび検索問い合わせを処理する。このマルチキャストグループに資源を登録する別のピアは、このグループにおける資源の管理をサポートする。新たな資源をグループに登録するピアは、すでに十分な管理者がこのグループの資源を管轄するようになった後では、待ちリストにおいて管理され、過負荷の際にはこのグループをサポートしてダウンしたグループメンバを置き換えることができる。
【００５３】
最も簡単なケースでは、マルチキャストグループへの検索問い合わせにグループの全メンバが応答する。有利な（例えば距離の）測定基準を用いて、応答するグループメンバを決定することにより、処理の効率を向上させることができる。使用する測定基準を考慮して、問い合わせの負荷に（待機しているピアのプールから）グループのメンバの数を適合させることにより、個々のピアの過負荷が回避されそれ自体で管理を行うバランスのとれたシステムが得られ有利である。
【００５４】
ピアをブートストラップする際にも資源を検索する際にも共に必要となる、与えられたハッシュ値を管轄するマルチキャストグループの探索のため、種々の方法が考えられる。範囲およびマルチキャストＩＰアドレスを適切に設定すると、対数的な繁雑さを有する力ずく（"Brute-Force"）メカニズムが可能である。場合によってはバックボーンにおいてＩＰルータにより直接支援して、"Valid Address Table"を複製することにより、この繁雑さをただ１つの要求にまで低減することが可能である。
【００５５】
上に説明した本発明の方法により、ディレクトリサービスはいずれの場合（すべての実施例）にも、複数のピアに基本的に自動的に分散され有利である。ここでこれらのピアは、このネットワークにおいて使用登録するピアである。この際にディレクトリは、公開される資源が増加すると（このネットワークのピアが増大すると、通例それだけより多くのファイルが登録される）、同時に個数が増えた所要のピアに分割されるのである。これにより、非集中形のネットワークとは異なり、検索問い合わせは全ピアツーピアネットワークに満たされることはなく、該当するファイルについての情報を有するピアに所期のように宛てられる。ここではシステムは、利用可能な資源（ピア、公開されるファイル）に自動的に適合化される。
【図面の簡単な説明】
【００５６】
【図１】本発明による分散形ディレクトリサービスを有するピアツーピアネットワークにおいて、新たなピアの資源を登録および公開するための流れ図である。
【図２】本発明による分散形ディレクトリサービスを有するピアツーピアネットワークにおいて資源を検索するための流れ図である。
【図１】
2005502289.tif 000003
【図２】
2005502289.tif 000004
【国際公開パンフレット】
2005502289.tif 000005
2005502289.tif 000006
2005502289.tif 000007
2005502289.tif 000008
2005502289.tif 000009
2005502289.tif 000010
2005502289.tif 000011
2005502289.tif 000012
2005502289.tif 000013
2005502289.tif 000014
2005502289.tif 000015
2005502289.tif 000016
2005502289.tif 000017
2005502289.tif 000018
2005502289.tif 000019
2005502289.tif 000020
2005502289.tif 000021
2005502289.tif 000022
2005502289.tif 000023
2005502289.tif 000024
【国際公開パンフレット（コレクトバージョン）】
2005502289.tif 000025
2005502289.tif 000026
【国際調査報告】
2005502289.tif 000027
2005502289.tif 000028
2005502289.tif 000029
2005502289.tif 000030
2005502289.tif 000031
2005502289.tif 000032