(57)【要約】【課題】ＧｎｕｔｅｌｌａなどのＰ２Ｐネットワークにおいて、ネットワーク内における検索パケットの数すなわちトラヒックをできるだけ削減できるとともに、目的情報は確実かつ効率よく探し出すことができるようにする。【解決手段】サーバント１は、そこを通過するヒット情報パケットからヒット情報を蓄積する（ステップ３１）。サーバントのユーザなどから目的情報の検索の要求があるかどうかを判別し（ステップ３２）、そのような要求がなければステップ３１に戻り、そのような要求があれば、ステップ３３において、直近のＮ種類のヒット情報に基づいてｍ１個のサーバントを選択し、その後、選択されたサーバントに対して検索パケットを送り（ステップ３４）、処理はステップ３１に戻る。検索パケットを送られたサーバントは、そのサーバントを起点として、Ｇｎｕｔｅｌｌａ型の検索を開始する。【選択図】    図３
2004341912.tif 000002
【特許請求の範囲】
【請求項１】
Ｐ２Ｐ型通信における、目的情報を保持するサーバントを検索する情報探索方法であって、
各サーバントは、通過するヒット情報パケットを解析して直近のヒット情報を収集し、
各サーバントが自分自身から検索要求を発出する場合における、検索パケットの送出先となるサーバントを選択する際に、
検索要求を発出するサーバントは、収集したヒット情報に基づいてサーバントを選択し、
選択したサーバントに検索パケットを直接送り、
該検索パケットが直接送られたサーバントにおいてヒットしなかった場合には、当該直接送られたサーバントを起点として、設定された方路を介して隣接サーバントに対して検索パケットを送ることを所定のホップ数の範囲内で繰り返すことによる検索を開始する、
経路選択方法。
【請求項２】
前記直近のヒット情報に基づいて、直近にヒットした所定数のサーバントを選択する、請求項１に記載の情報探索方法。
【請求項３】
所定の数の直近のヒット情報を収集し、収集されたヒット情報の中からランダムにサーバントを選択する、請求項１に記載の情報探索方法。
【請求項４】
Ｐ２Ｐ型通信における、目的情報を保持するサーバントを検索する情報探索方法であって、
検索要求を発出するサーバントを起点として、設定された方路を介して隣接サーバントに対して検索パケットを送ることを第１の所定数のホップ数の範囲内で繰り返すことによる第１の検索を開始し、
前記第１の検索でヒットしなかった場合には、前記第１の所定数より大きい第２の所定数だけホップ数が離れたサーバントを選択し、前記選択されたサーバントに対して検索パケットを直接送り、前記選択されたサーバントを起点として、設定された方路を介して隣接サーバントに対して検索パケットを送ることを第３の所定数のホップ数の範囲内で繰り返すことによる第２の検索を開始する、
情報探索方法。
【請求項５】
Ｐ２Ｐ型通信における、設定された方路を介して隣接サーバントに対して検索パケットを送ることを所定のホップ数の範囲内で繰り返すことにより、目的情報を保持するサーバントを検索する情報探索方法であって、
各サーバントは、通過するヒット情報パケットを解析して直近のヒット情報を収集し、
検索パケットを隣接サーバントに送信しようとするサーバントは、前記ヒット情報を参照して、当該サーバントに設定された方路の中から前記検索パケットを送信すべき方路を選択する、情報探索方法。
【請求項６】
前記サーバントがＷ種類の方路を有し、１≦Ｍ１≦Ｗとして、直近でヒットしたＭ１種類の方路に対してのみ前記検索パケットを送出する、請求項５に記載の情報探索方法。
【請求項７】
前記サーバントがＷ種類の方路を有し、１≦Ｍ２≦Ｗとして、直近でよりヒットしなかったＭ２種類の方路に対してのみ前記検索パケットを送出する、請求項５に記載の情報探索方法。
【請求項８】
Ｐ２Ｐ型通信における、設定された方路を介して隣接サーバントに対して検索パケットを送ることを所定のホップ数の範囲内で繰り返し、ヒットした検索パケットの伝搬経路の逆経路で目的情報を保持するサーバントからヒット情報パケットを受け取ることにより、当該目的情報を保持するサーバントを検索する情報探索方法であって、
前記伝搬経路上にあるサーバントに対し、前記ヒット情報パケットに基づくヒット情報を格納する、情報探索方法。
【請求項９】
Ｐ２Ｐ型通信において用いられるサーバントであって、
Ｐ２Ｐネットワークと接続し、検索パケット及びヒット情報パケットを送受信するパケット送受信部と、
通過した検索パケット及びヒット情報パケットに関して、直近に通過したＮ種類の内容を記憶するメモリと、
前記メモリの内容に基づいて、前記検索パケットの送出先を決定する情報解析部と、
を有する、サーバント。
【請求項１０】
コンピュータをＰ２Ｐ型通信におけるサーバントとして機能させるプログラムであって、前記コンピュータに、
通過するヒット情報パケットを解析して直近のヒット情報を収集する処理と、
検索要求を発出する場合において、前記収集したヒット情報に基づいてサーバントを選択する処理と、
選択したサーバントに検索パケットを直接送る処理と、
検索パケットが送られてきたときに、自サーバントでヒットしなかった場合には、設定された方路を介して隣接サーバントに対して検索パケットを送ることを所定のホップ数の範囲内で繰り返すことによる検索を開始する処理と、
を実行させるプログラム。
【請求項１１】
コンピュータをＰ２Ｐ型通信におけるサーバントとして機能させるプログラムであって、前記コンピュータに、
設定された方路を介して隣接サーバントに対して検索パケットを送ることを第１の所定数のホップ数の範囲内で繰り返すことによる第１の検索を開始する処理と、
前記第１の検索でヒットしなかった場合には、前記第１の所定数より大きい第２の所定数だけホップ数が離れたサーバントを選択し、前記選択されたサーバントに対して検索パケットを直接送る処理と、
を実行させるプログラム。
【請求項１２】
コンピュータをＰ２Ｐ型通信におけるサーバントとして機能させるプログラムであって、前記コンピュータに、
通過するヒット情報パケットを解析して直近のヒット情報を収集する処理と、
前記ヒット情報を参照して、予め設定されている方路の中から検索パケットを送信すべき方路を選択する処理と、
を実行させるプログラム。
【請求項１３】
コンピュータが読み取り可能な記録媒体であって、請求項１０乃至１２のいずれか１項に記載のプログラムを記録した記録媒体。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、Ｐ２Ｐ（ピア・ツー・ピア；Ｐｅｅｒ−ｔｏ−Ｐｅｅｒ）型の通信によりネットワーク内での目的情報の所在を検索する情報探索方法及び装置に関する。
【０００２】
【従来の技術】
Ｐ２Ｐネットワーク技術は、従来のクライアント・サーバ型のネットワークを構成とは異なり、ネットワークに接続した端末自体にサーバ機能を持たせ、端末間でコンピュータ資源やサービスを直接共有できるようにする技術である。このような端末は、サーバとクライアントの両方の機能を有するという意味から、サーバントと呼ばれている。Ｐ２Ｐネットワークは、例えば、ＩＰ（インターネットプロトコル；Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）網上に構築される。Ｐ２Ｐネットワークは、端末間でのファイルや情報の交換、あるいは、分散コンピューティングなどに使用されている（非特許文献１）。
【０００３】
Ｐ２Ｐネットワークの形態には、大別して、目的情報の所在を一括管理するための専用サーバを用いるハイブリッド型と、そのようなサーバを使用せずに、全てのコンピュータが完全に対等であるピュア型とがある。ハイブリッド型のＰ２Ｐ通信の典型例としては、Ｎａｐｓｔｅｒが挙げられる。Ｎａｐｓｔｅｒなどのハイブリッド型のＰ２Ｐ通信では、各サーバントからの検索要求パケットが、専用サーバに集中するため、サーバボトルネックとなりやすい。また、専用サーバを設けることは、専用サーバにおける障害の影響がネットワーク全体に拡大することとなり、Ｐ２Ｐネットワークが本来有する耐障害性があるなどの利点を阻害することにもなる。
【０００４】
また、ピュア型のＰ２Ｐ通信の典型例としては、Ｇｎｕｔｅｌｌａが挙げられる。ピュア型のＰ２Ｐネットワークシステムでは、目的情報の所在を管理するサーバが存在しないため、各サーバントは他のサーバントに対して目的情報の所在を問い合わせる必要があるが、その問合せのやり方として、Ｇｎｕｔｅｌｌａでは、目的情報の所在を伝言ゲーム方式で次々に問い合わせている。すなわち、Ｇｎｕｔｅｌｌａによるネットワークシステムでは、各サーバントは、ネットワーク内における隣接サーバントに対して方路（腕）を伸ばしており、検索パケット中のＴＴＬ（Ｔｉｍｅ  ｔｏ  Ｌｉｖｅ）に設定された値のホップ数の範囲まで、その全ての方路を用いて、目的の情報の有無を次々に隣接サーバントに対して問い合わせる。したがって、各サーバントでは、隣接サーバントへ伸ばしている方路の分だけ分岐されてパケットが送出されることになる。Ｇｎｕｔｅｌｌａでは、Ｐ２Ｐネットワークに極めて多数のサーバントが接続している場合であっても、ＴＴＬで規定されたホップ数で到達できるサーバントの範囲内で検索を行うことにより、問合せのための時間とトラヒックの量とを現実的な範囲内に留めるようにしている。それでも、Ｇｎｕｔｅｌｌａでは、このような情報検索パケットが多数のサーバントから並列に発信される場合には、網内のパケット数が爆発的に増加し、網内の広域にわたっての混雑が予想される。なお、目的情報を保持するサーバントの所在が明らかになったら、その目的情報のデータそのもの（ファイル実体など）は、検索要求を発出したサーバントが、ＩＰアドレスなどの情報に基づいて、その目的情報を保持するサーバントに直接接続して取得する。
【０００５】
ここでホップ数とは、伝言ゲーム形式でパケットがサーバント間が転送（フォワード）される場合に、あるパケットが何個のサーバントを経由してフォワードされたかを示し、ＴＴＬ（Ｔｉｍｅ  ｔｏ  Ｌｉｖｅ）値とは、何ホップ先までパケットをフォワードさせるかという最大値である。例えば、ＴＴＬ＝７とすることにより、７台（ホップ）先のサーバントまでフォワードされる。なお、この種の検索では、もしこの７台の手前でヒットすれば、そのパケットはその先には転送されないようになっている。以下に説明するように、ＴＴＬの値はパケットに書き込まれており、サーバントは、次のサーバントにパケットをフォワードする際に、そのパケットのＴＴＬ値を１だけ小さくする。
【０００６】
以下、Ｇｎｕｔｅｌｌａによる目的情報探索の手順について説明する。ここでは、ネットワーク内のサーバントから、そのネットワーク内にあって目的情報を保持している別のサーバントを探索する場合を説明する。Ｐ２ＰネットワークがＩＰネットワーク上に構築されるものとして、まず、各サーバントがＧｎｕｔｅｌｌａのＰ２Ｐネットワークに接続する手順を説明する。
（１）    他のサーバントヘ接続し、Ｐｉｎｇパケットを送信する。
（２）    Ｐｉｎｇパケットを受信したサーバントは、ＴＴＬ値が１より大きく、かつまだ受け取ったことがないＧＵＩＤ（Ｇｌｏｂａｌｌｙ  Ｕｎｉｑｕｅ  Ｉｄｅｎｔｉｆｉｅｒ）をもつパケットならば、ＴＴＬ値を１つ減らし（このとき、ホップ値を１つ増やす）、そのパケットをさらに別のサーバントへ転送する。
（３）    Ｐｉｎｇパケットを受信したサーバントは、まだ受け取ったことがないＧＵＩＤをもつパケットならば、ＩＰアドレス、接続を受け付けるためのＴＣＰポート番号、公開している目的情報（例えばファイル）の総数などの情報を記録したＰｏｎｇパケットを、そのＰｉｎｇパケットの送信元へ返す。
（４）    Ｐｏｎｇパケットを受信したサーバントは、対応するＰｉｎｇパケットの送信元へ、そのＰｏｎｇパケットを返す。
（５）    Ｐｉｎｇパケットを送信し、それに対応するＰｏｎｇパケットを受信したサーバントは、指定された数のサーバントの情報が得られたならば、それらのサーバントに接続し、指定された数のサーバントの情報が得られなければ、さらに別のサーバントを見つけて以上のシーケンスを繰り返す。
【０００７】
また、ＧｎｕｔｅｌｌａのＰ２Ｐネットワークにおける目的情報の探索の手順は次の通りである。
（１）    ファイル検索元のサーバントは、そのサーバントが直接接続しているサーバントに対して、検索パケット（Ｑｕｅｒｙ（問い合わせ））パケットを送信する。Ｑｕｅｒｙパケットのペイロードには、「この検索要求に応じるサーバントの最低通信速度」や「検索キーワード」などの検索条件が記録される。
（２）    Ｑｕｅｒｙパケットを受信したサーバントは、Ｑｕｅｒｙパケットのヘッダに記録されているＴＴＬ値を１つ減らし（このとき、ホップ値を１つ増やす）、ＴＴＬ値が１より大きければ、自サーバントに接続している全てのサーバント（ただし、Ｑｕｅｒｙパケットを送信したサーバントは除く）へ、Ｑｕｅｒｙパケットをそれぞれ転送する。
（３）    転送されたＱｕｅｒｙパケットの条件に合致する目的情報を保持しているサーバントは、ヒット情報パケット（ＱｕｅｒｙＨｉｔパケット）を返し、目的情報を保持していないサーバントは、Ｑｕｅｒｙパケットをさらに転送する。
（４）    ＱｕｅｒｙＨｉｔパケットは、Ｑｕｅｒｙパケットが転送されてきた経路を逆順にたどって発信元に戻っていく。ＱｕｅｒｙＨｉｔパケットのペイロードには、条件に合ったファイルの総数、ＱｕｅｒｙＨｉｔしたサーバント（目的情報を保持するサーバント）の各種情報（待ち受けＴＣＰポート番号，ＩＰアドレス，接続通信速度，条件に合った目的情報のファイルの名前とサイズとファイルインデックス（どのファイルであるかを示すためにサーバント側で付与している一連の番号），ＧＵＩＤ）が記録されている。すなわちＱｕｅｒｙＨｉｔパケットには、目的情報の所在情報が格納されている。
【０００８】
なお、本出願人は、既に、特願２００２−３５４９８８において、Ｇｎｕｔｅｌｌａ型のＰ２Ｐネットワークにおける時々刻々と変化するネットワークトポロジーを再現するために、ネットワークを構成する端末（サーバント）の接続先端末数の分布を効率よくかつ容易に推定できる方法を提案している。
【０００９】
【非特許文献１】
伊藤直樹：「Ｐ２Ｐコンピューティング  〜技術解説とアプリケーション」、ソフト・リサーチ・センター、２００１
【００１０】
【発明が解決しようとしている課題】
上述したように、ＩＰ網などのネットワークにおいてＰ２Ｐ型通信を行っている場合には、ネットワーク内あるいは目的情報を有するサーバント内において、輻輳が発生し得る。また、Ｇｎｕｔｅｌｌａ型のＰ２Ｐネットワークにおいては、ＴＴＬに設定されたホップ数の範囲内のサーバントのみを検索範囲として目的情報を検索するので、Ｐ２Ｐネットワーク全体としてみた場合には目的情報が存在していてもその検索範囲内に目的情報が存在しない場合には、検索失敗となるとという問題点もある。
【００１１】
そこで本発明の目的は、目的情報の所在を一括管理するためのサーバを用いないＰ２Ｐネットワークにおいて、ネットワーク内における検索パケット（目的情報の所在を問合せるためのパケット）の数すなわちトラヒックをできるだけ削減できるとともに、目的情報は確実かつ効率よく探し出すことができる方法及び装置を提供することにある。
【００１２】
【課題を解決するための手段】
Ｐ２Ｐ（Ｐｅｅｒ−ｔｏ−Ｐｅｅｒ）型通信においては、各サーバント（Ｓｅｒｖｅｎｔ）が対等な立場で通信を行うが、本発明では、このサーバントが有する情報を用いて、なるべく網内に送出される検索パケットの数を少なくしつつ、目的の検索をＧｎｕｔｅｌｌａ型と同程度あるいはそれ以上の確かさで実現させるようにしている。
【００１３】
すなわち本発明の第１の情報探索方法は、Ｐ２Ｐ型通信における、目的情報を保持するサーバントを検索する情報探索方法であって、各サーバントは、通過するヒット情報パケットを解析して直近のヒット情報を収集し、各サーバントが自分自身から検索要求を発出する場合における、検索パケットの送出先となるサーバントを選択する際に、検索要求を発出するサーバントは、収集したヒット情報に基づいてサーバントを選択し、選択したサーバントに検索パケットを直接送り、検索パケットが直接送られたサーバントにおいてヒットしなかった場合には、その直接送られたサーバントを起点として、Ｇｎｕｔｅｌｌａ型の検索を開始する。
【００１４】
本発明の第２の情報探索方法は、Ｐ２Ｐ型通信における、目的情報を保持するサーバントを検索する情報探索方法であって、検索要求を発出するサーバントを起点として、ＴＴＬをＤとしたＧｎｕｔｅｌｌａ型の検索である第１の検索を開始し、第１の検索でヒットしなかった場合には、Ｄより大きいＵだけホップ数が離れたサーバントを選択し（好ましくはＵ≫Ｄ）、選択されたサーバントに対して検索パケットを直接送り、この選択されたサーバントを起点として、Ｇｎｕｔｅｌｌａ型の検索である第２の検索を開始する。
【００１５】
本発明の第３の情報探索方法は、Ｐ２Ｐ型通信における、Ｇｎｕｔｅｌｌａ型の検索により目的情報を保持するサーバントを検索する情報探索方法であって、各サーバントは、通過するヒット情報パケットを解析して直近のヒット情報を収集し、検索パケットを隣接サーバントに送信しようとするサーバントは、ヒット情報を参照して、当該サーバントに設定された方路の中から検索パケットを送信すべき方路を選択する。
【００１６】
本発明におけるＧｎｕｔｅｌｌａ型の検索とは、本明細書の従来の技術に書かれたＧｎｕｔｅｌｌａによる目的情報探索と同義であり、端的に言えば、あるサーバントを起点として、設定された方路を介して各サーバントがその隣接サーバントに対して検索パケットを送ることを所定のホップ数の範囲内で繰り返すことにより、目的情報を保持するサーバントを見つけ出す検索のことである。
【００１７】
【発明の実施の形態】
次に、本発明の好ましい実施の形態について、図面を参照して説明する。
【００１８】
図１は、本発明が適用されるＰ２Ｐネットワークの構成の一例を示す図である。ここでは、インターネット（Ｉｎｔｅｒｎｅｔ）などのＩＰ網（プロトコルとしてＩＰを使用するネットワーク）上に、Ｐ２Ｐネットワークが構築されており、Ｐ２Ｐネットワークに対し、多数のサーバント（端末）１が自律分散的に接続している。なおこのＰ２Ｐネットワークでは、目的情報の所在を一括管理する専用サーバは設けられていない。ここでは、ＩＰ網上にＰ２Ｐネットワークが構築されているので、各サーバント１はＩＰアドレスによって識別されるようになっている。
【００１９】
ここでは、図１に示したようなＰ２Ｐネットワークにおいて、ネットワーク内における検索パケット（Ｑｕｅｒｙパケット）の数すなわちトラヒックをできるだけ削減できるとともに、目的情報は確実かつ効率よく探し出すことができる各種の手法を説明する。具体的には、Ｐ２Ｐネットワーク内のあるサーバント１が自ら検索要求を発する場合に、（１）どのサーバントを選択して検索パケットを送出するかを決めるサーバント選択法、（２）Ｇｎｕｔｅｌｌａ型のサーバントのように複数の方路（腕）が設定されている場合に、どの方路を用いて検索パケットを送出するかを決める方路選択法を説明する。さらに、（３）目的情報が一度見つかった場合に、再度の検索によるトラヒックの増大を避けるための方法として、目的情報の所在情報を経路上のサーバントに格納する方法についても説明する。
【００２０】
《第１の実施形態》
サーバント１は、Ｇｎｕｔｅｌｌａ型のサーバントと同様に、隣接サーバントに対して伸びる方路（腕）を備え、他のサーバントからの検索パケット（Ｑｕｅｒｙパケット）及びヒット情報パケット（ＱｕｅｒｙＨｉｔパケット）を中継する機能を有する。特に、他サーバントから検索パケットが送られてきた場合には、Ｇｎｕｔｅｌｌａ型の検索を実行する機能を備えている。上述した従来の場合と同様に、検索パケットは、ペイロードとして、「この検索要求に応じるサーバントの最低通信速度」や「検索キーワード」などの検索条件を含んでいる。ヒット情報パケットは、ペイロードとして、条件に合ったファイルの総数、ＱｕｅｒｙＨｉｔしたサーバント（目的情報を保持するサーバント）の各種情報（待ち受けＴＣＰポート番号，ＩＰアドレス，接続通信速度，条件に合った目的情報のファイルの名前とサイズとファイルインデックス（どのファイルであるかを示すためにサーバント側で付与している一連の番号），ＧＵＩＤ）を含んでいる。
【００２１】
さらに、サーバント１は、自身を経由するヒット情報パケットに関して、直近に通過したＮ種類についてそれぞれの内容（ヒット情報の集合）を記憶する機能を有する。すなわちサーバント１は、そこを経由するヒット情報パケットを解析し、それらのヒット情報パケットに記録されている、ＱｕｅｒｙＨｉｔしたサーバントのＩＰアドレスを取得し、そのＩＰアドレスなどの情報をヒット情報として記憶する機能を有する。ヒット情報の詳細については後述する。このようにヒット情報パケットにおいていずれかの目的情報を含むとされたサーバントのことをヒットサーバントと呼ぶことにする。
【００２２】
そして、サーバント１がそれ自身から検索要求を発出する場合（すなわち、他サーバントから送られてきた検索パケットによらずに検索を開始する場合）においては、直近に自サーバントを通過したＮ種類のヒット情報に基づいてｍ１（ただし１≦ｍ１≦Ｎ）個のヒットサーバントを選択し、その選択されたヒットサーバントに対して、直接に（すなわち他への分岐を行うことなしに）、検索パケット（Ｑｕｅｒｙパケット）をその選択されたヒットサーバントに対して送信する。これは、最近、いずれかの目的情報を持つものとしてヒットしたサーバントは、そのヒットした目的情報以外の目的情報も保持している可能性が高い、という仮定（推定）に基づくものである。
【００２３】
ｍ１個のヒットサーバントの選択方法としては、（ｉ）直近のｍ１種類のヒット情報に対応するサーバントを選択する方法や、（ｉｉ）Ｎ種類のヒット情報のうち、ランダムにｍ１（１≦ｍ１≦Ｎ）種類のサーバントを選択する方法などがある。
【００２４】
選択されたヒットサーバントが、目的とする情報を保持している場合には、ヒット情報パケットが、そのサーバントから、検索要求を発出したサーバントに直接返信される。また、選択されたヒットサーバントが、目的とする情報を保持していない場合には、その選択されたヒットサーバントから、新たにＧｎｕｔｅｌｌａ型の検索を開始させる。なお、選択されたヒットサーバントがＧｎｕｔｅｌｌａによる検索処理を行えるものであれば、そのサーバントに目的情報が存在しない限り、検索パケットを受信したことによって、その近傍のサーバントに対してＧｎｕｔｅｌｌａ型の検索を自律的に開始するはずである。
【００２５】
次に、サーバントに蓄積されるヒット情報について説明する。サーバント１は、そこを通過した直近のＮ種類のヒット情報を集合として保持するが、その集合は、
（Ｈ１（Ａ１，ｈ１，ａ１，Ｆ１），Ｈ２（Ａ２，ｈ２，ａ２，Ｆ２），…，ＨＮ（ＡＮ，ｈＮ，ａＮ，ＦＮ））
と記述される。ここで、Ｈｋは、現時点から遡ってｋ番目に新しくそのサーバントを通過したパケットに関するヒット情報であり、Ａｋは、ｋ番目に新しいヒット情報を持つサーバントのＩＰアドレスであり、ｈｋは、ｋ番目に新しいヒット情報を持つサーバントまでのホップ数であり、ａｋは、ｋ番目に新しくヒットしたサーバントの１ホップ前のサーバントの（ヒットしたサーバントまで伸ばした）腕の番号であり、Ｆｋは、ｋ番目に新しくヒットした検索情報（対象ファイル）の種別である。
【００２６】
図２は、検索要求を発出するサーバントにおいて蓄積されているヒット情報の一例を示す図である。ここでは、検索パケットの送出に必要な情報のみが示されている。サーバント１は、各ヒット情報を、ヒット時刻の順で並べ替えてＮ種類保持しており（図示したものでは、若い番号ほど直近のヒット情報に対応する）、ヒット情報ごとに、ヒット時刻、目的情報に対応するファイル名、ヒットサーバントのＩＰアドレスを保持している。そして、図示した例では、直近のｍ１種類のヒット情報に対応するヒットサーバントに対応して「○」印が付されており、これにより、そのサーバントが選択されたことが示されている。
【００２７】
図３は、この実施形態での処理をまとめたフローチャートである。サーバント１は、そこを通過するヒット情報パケットからヒット情報を蓄積している（ステップ３１）。サーバントのユーザなどから目的情報の検索の要求があるかどうかを判別し（ステップ３２）、そのような要求がなければステップ３１に戻り、そのような要求があれば、ステップ３３において、直近のＮ種類のヒット情報に基づいてｍ１個のサーバントを選択し、その後、選択されたサーバントに対して検索パケットを送り（ステップ３４）、処理はステップ３１に戻る。
【００２８】
《第２の実施形態》
従来、Ｇｎｕｔｅｌｌａ型のＰ２Ｐネットワークでは、目的情報の探索範囲は、自サーバントからＴＴＬで規定されたホップ数の範囲内までの領域に限定されている。そこでこの実施形態では、探索範囲を拡大することによって、より確実に目的情報を検索できるようにしている。
【００２９】
この実施形態では、図４に示すように、検索要求を発出するサーバントは、まず、ＴＴＬの値をＤに設定することによって、Ｇｎｕｔｅｌｌａ型の検索により、自サーバントからホップ数がＤの範囲内で目的情報を検索する。ここでもし目的情報が見つからない場合には、Ｕ≫Ｄとして、自サーバントからＵホップ離れたサーバントをランダムに選択して、その選択されたサーバントに対して検索パケットを直接に送信することによって、その選択されたサーバントを起点としてさらにＧｎｕｔｅｌｌａ型の検索を行うようにしている。サーバントとしては、第１の実施形態におけるサーバントと同様のものが使用できる。ここではヒット情報は使用しないので、サーバントは、ヒット情報を蓄積する機能は備えていなくてもよい。
【００３０】
本実施形態では、最初にＤホップ内でのＧｎｕｔｅｌｌａ型の検索を行い、そこで目的情報が見つからない場合には、最初の検索範囲からを遠く離れた場所を起点として、再度、Ｇｎｕｔｅｌｌａ型の検索を試みる。したがって、従来の検索方法に比べ、実質的に検索範囲が大きく広がるとともに、初期段階での検索範囲を小さく設定することによって（Ｄの値を通常よりも小さくすることによって）、検索パケットによるトラヒックの増大も防止することができる。
【００３１】
図５は、この実施形態での処理をまとめたフローチャートである。サーバント１は、ＴＴＬの値をＤに設定して、隣接サーバントに対して検索パケットを送信し、Ｇｎｕｔｅｌｌａ型の検索を開始する（ステップ５１）。この検索で目的情報が見つかったかどうか、すなわち検索パケットに対応するヒット情報パケットを受信したかどうかを判別し（ステップ５２）、目的情報が見つかった場合には、そこで検索処理を終了する。一方、ステップ５２で目的情報が見つからなかった場合には、Ｕホップ離れたサーバントをランダムに選択し（ステップ５３）、そのサーバントに対して検索パケットを直接送信する（ステップ５４）。
【００３２】
《第３の実施形態》
次に、本発明の第３の実施形態について説明する。Ｇｎｕｔｅｌｌａ型の検索では、各サーバントには、隣接サーバントに対して伸びる方路（腕）が設定されている。ここでは、サーバントが備える方路の数をＷで表わすこととする。従来の検索方法では、サーバントごとに、そのサーバントに設定された全ての方路（ただし、転送しようとする検索パケットを送ってきたサーバントへの方路を除く）に対し、検索パケットを転送するようにしている。しかしながら、方路ごとにその方路を経由して目的情報が見つかる確率は均一であるとは限らず、したがって、より目的情報が見つかりそうな方路のみを選択して検索パケットを転送することにより、目的情報の検索精度をほとんど損なうことなく、検索パケットの流通に伴うトラヒックを削減することができる。
【００３３】
このように方路を選択して検索パケットを送出するために、各サーバントは、第１の実施形態の場合と同様に、そこを通過するヒット情報パケットを監視して、ヒット情報を蓄積する。
【００３４】
ここで、方路の選択の方法としては、目的情報の推定される空間的配置に応じて、以下のものが考えられる。
【００３５】
第１の選択方法として、ある目的情報にヒットしたてのサーバント（いわゆるホットなサーバント）は、他の目的情報も保持している可能性が高い、と考えられる場合には、各サーバントにおいて、直近にヒットしたＭ１個（ただし１≦Ｍ１≦Ｗ）の方路のみに検索パケットを送出する。この場合、直近にヒットしたＭ１個以外の方路に対し、それらの方路のそれぞれについて、１未満の確率で検索パケットが送出されるようにしてもよい。
【００３６】
第２の選択方法として、ヒットするサーバントは空間内に均一に分散配置していると考えられる場合には、ヒットしていない方向へ分岐を多くして検索する。具体的には、各サーバントのＷ種類の方路のうち、直近でヒットしていない方路のうちのＭ２個（ただし１≦Ｍ２≦Ｗ）の方路、あるいはヒットした数が少ないＭ２個の方路に対してのみ検索パケットを送出する。この場合、検索パケットを受け取ったサーバントでは、各方路ともヒットしていないようなことがあり得るので、１ホップ目のみにおいて上述したような方路の選択を適用し、２ホップ目からは、Ｂ＜ＷであるＢ個の方路をランダムに選択して、ＴＴＬ＜Ｄの範囲で検索を続けるようにすることが好ましい。
【００３７】
図６は、検索要求を発出するサーバントにおいて蓄積されているヒット情報の一例を示す図である。ここでは、検索パケットの送出に必要な情報のみが示されている。サーバント１は、各ヒット情報を、Ｗ個の方路のそれぞれに対応してＷ種類保持している。上述したように、ヒット情報には、パラメータａｋとして、ｋ番目に新しくヒットしたサーバントがあるときにどの方路からそのヒットに対応するヒット情報パケットを受け取ったかが記録されており、このパラメータａｋを用いて、どの方路が、直近にヒットした方路であるかがわかるようになっている。図示したものでは、方路ごとに、直近のヒット時刻、目的情報に対応するファイル名、ヒットサーバントのＩＰアドレスを保持している。そして、図示した例では、直近にヒットしたＭ１種類の方路に対応して「○」印が付されており、また、直近でヒットしていない（より少なくヒットしている）Ｍ２種類の方路に対応して「★」印が付されている。
【００３８】
《第４の実施形態》
Ｇｎｕｔｅｌｌａ型の検索では、検索パケットがあるサーバントに到着してそのサーバントにおいてヒットした時に、その検索パケットの伝搬経路の逆順を通って、検索要求を発出したサーバントに対して、ヒット情報パケットが送られる。このとき、検索パケットやヒット情報パケットの伝搬経路の途上にあるサーバントに対してヒット情報を格納しておき、次に、その目的情報についての検索が行われた場合には、そのヒット情報が格納されたサーバントが、目的情報そのものを保持する本来のサーバントに代わってヒット情報パケットを送信することによって、検索パケットの流通に伴うトラヒックを削減することができる。この場合、ヒット情報を格納されたサーバントは、目的情報そのものは保持していないので、ヒット情報からは、目的情報が何であったかを知ることはできない。そこで、サーバントは、第１の実施形態と同様に、直近にそこを通過したＮ種類のヒット情報パケットの内容をヒット情報をして記憶するとともに、同じく直近にそこを通過したＮ種類の検索パケットの内容（目的情報（探している情報）の種別）を記憶する機能を備えている。具体的には、集合
（Ｑ１（ｓ１），Ｑ２（ｓ２），…，ＱＮ（ｓＮ））
を記憶する。ここで、Ｑｋは、現時点から遡ってｋ番目に新しく当該サーバントを通過したＱｕｅｒｙの目的情報であり、ｓｋは、ｋ番目に新しい目的情報の内容（探しているファイル種別）である。
【００３９】
ヒットした検索パケットとヒット情報パケットとは対になっているものであるから、サーバントは、検索パケットを新たに受け取った場合に、その検索パケットによる検索内容が既に内容が格納されている検索パケットと同じであるかを判別し、同じである場合には、格納しているヒット情報から対応するヒット情報パケットを生成して返信する。
【００４０】
図７は、本実施形態におけるヒット情報の格納状態を示している。
【００４１】
ところで本実施形態では、各サーバントにヒット情報を無条件で格納してもよいが、各サーバントに対し、ヒット情報の格納の可否を尋ね、可としたサーバントのみにヒット情報を格納するようにしてもよい。また、ヒット情報パケットの伝搬経路上のサーバントのうち、ランダムにＳ％（ただし０＜Ｓ＜１００）を選択してその選択されたサーバントにヒット情報を格納し、残りのサーバントには格納しないようにしてもよい。また、伝搬経路上のＰ個ごとに離れたサーバントのヒット情報を格納しても良い。さらにまた、経由するサーバントの格納スペースの使用状況を見て、使用状況がＸ％以下（ただし、０＜Ｘ＜１００）であればそのサーバントへヒット情報を格納し、Ｘ％より大きな使用率である場合には格納しないようにしてもよい。
【００４２】
《サーバントの構成例》
以上、本発明の好ましい実施形態でのサーバント選択方法、方路選択方法及びヒット情報格納方法を説明したが、次に、これらの各方法を実施する際に用いられるサーバントの構成について、図８を用いて説明する。サーバント１は、上述したように、自身を経由する検索パケットとヒット情報パケットとに関して、直近に通過したＮ種類についてそれぞれの内容（検索パケットに関しては、目的情報（探している情報）の種別、ヒット情報パケットに関しては、ヒット情報の集合）を記憶する機能を備えている。
【００４３】
サーバント（端末装置）１は、ＩＰ網１２に接続し、通常のパーソナルコンピュータの機能を備えるいわゆる端末であるが、Ｐ２Ｐアプリケーションレイヤとしては、サーバントとして見えるものである。このサーバント１は、大別すると、外部からの情報（コマンド）を受け付け、外部へ発信する出力情報を管理する機能を有する入出力管理部２と、サーバント内の各種情報を処理する機能を有するプロセッシング部３と、他サーバントやネットワーク内の状態などの諸々の情報を蓄える機能を備えるメモリ部５と、各種情報をＩＰパケットに変換したり、その逆にＩＰパケットから各種情報への分解を行ったりする機能を有するＰＡＤ（パケット組み立て／分解部）９と、ＩＰパケットを他のサーバントに送出する機能を備えるパケット送信部１０と、網内の他のサーバントから到着するパケットを受信する機能を備えるパケット受信部１１と、を備えている。パケット送信部１０及びパケット受信部１１は、ＩＰ網１２に接続されており、隣接するサーバントとの間に方路が設定されている。プロセッシング部３の内部には、各種情報の詳細な解析を行う情報解析部４が設けられている。上述の各実施形態で説明したような方路やサーバントの選択も情報解析部４で行われる。メモリ部５の内部には、過去の各種パケットのヒットや情報の有無などの履歴情報を時系列的に解析する機能を備える履歴解析部６と、各種情報を格納／蓄積する場所であるメモリ８と、メモリ８内に格納されている情報の入出力などの管理を行うメモリ管理部７とが設けられている。特に、検索パケットに関しての目的情報（探している情報）の種別と、ヒット情報パケットに関してのヒット情報の集合は、メモリ８内に格納されるようになっている。
【００４４】
このようなサーバント１は、それを実現するための計算機プログラムを、パーソナルコンピュータなどに読み込ませ、そのプログラムを実行させることによっても実現できる。サーバントを実現するためのプログラムは、磁気テープやＣＤ−ＲＯＭなどの記録媒体によって、あるいは、ネットワークを介して、コンピュータに読み込まれる。
【００４５】
そのようなコンピュータは、ハードウェア構成としては、一般に、ＣＰＵ（中央処理装置）と、プログラムやデータを格納するためのハードディスク装置と、主メモリと、キーボードやマウスなどの入力装置と、ＣＲＴなどの表示装置と、ＣＤ−ＲＯＭ等の記録媒体を読み取る読み取り装置と、ＩＰ網１２との接続に用いられる通信インタフェースと、を備えている。そして、ＣＤ−ＲＯＭ等の記録媒体から、あるいはネットワークからプログラムを読み込み、そのプログラムをＣＰＵが実行することにより、このコンピュータは、上述したサーバントとして機能することになる。
【００４６】
【発明の効果】
以上説明したように本発明によれば、Ｐ２Ｐ型通信を行う際に、網内の検索パケットをなるべく減らして効率よく目的情報（ファイル）を見つけるための手順、手法を確立することができる。また、目的情報のファイルが見つかった後に、そのヒット情報が必要なサーバントに対してのみ効率的に情報を配信及び保持させることができる。
【図面の簡単な説明】
【図１】本発明が適用されるＰ２Ｐネットワークの構成の一例を示す図である。
【図２】本発明の第１の実施形態でのヒット情報の一例を示す図である。
【図３】第１の実施形態での検索要求発出サーバントの処理を説明するフローチャートである。
【図４】本発明の第２の実施形態でのサーバント選択法を説明する図である。
【図５】第２の実施形態での検索要求発出サーバントの処理を説明するフローチャートである。
【図６】本発明の第３の実施形態でのヒット情報の一例を示す図である。
【図７】本発明の第４の実施形態を説明する図である。
【図８】サーバントの構成を示すブロック図である。
【符号の説明】
１    サーバント
２    入出力管理部
３    プロセッシング部
４    情報解析部
５    メモリ部
６    履歴解析部
７    メモリ管理部
８    メモリ
９    ＰＡＤ
１０    パケット送信部
１１    パケット受信部
１２    ＩＰ網（インターネット）
【図１】
2004341912.tif 000003
【図２】
2004341912.tif 000004
【図３】
2004341912.tif 000005
【図４】
2004341912.tif 000006
【図５】
2004341912.tif 000007
【図６】
2004341912.tif 000008
【図７】
2004341912.tif 000009
【図８】
2004341912.tif 000010