JP2004341912A - 情報探索方法、サーバント、プログラム及び該プログラムを記録した記録媒体 - Google Patents
情報探索方法、サーバント、プログラム及び該プログラムを記録した記録媒体 Download PDFInfo
- Publication number
- JP2004341912A JP2004341912A JP2003138896A JP2003138896A JP2004341912A JP 2004341912 A JP2004341912 A JP 2004341912A JP 2003138896 A JP2003138896 A JP 2003138896A JP 2003138896 A JP2003138896 A JP 2003138896A JP 2004341912 A JP2004341912 A JP 2004341912A
- Authority
- JP
- Japan
- Prior art keywords
- servant
- search
- information
- packet
- hit
- 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.)
- Pending
Links
Images
Landscapes
- Information Transfer Between Computers (AREA)
- Computer And Data Communications (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
【課題】GnutellaなどのP2Pネットワークにおいて、ネットワーク内における検索パケットの数すなわちトラヒックをできるだけ削減できるとともに、目的情報は確実かつ効率よく探し出すことができるようにする。
【解決手段】サーバント1は、そこを通過するヒット情報パケットからヒット情報を蓄積する(ステップ31)。サーバントのユーザなどから目的情報の検索の要求があるかどうかを判別し(ステップ32)、そのような要求がなければステップ31に戻り、そのような要求があれば、ステップ33において、直近のN種類のヒット情報に基づいてm1個のサーバントを選択し、その後、選択されたサーバントに対して検索パケットを送り(ステップ34)、処理はステップ31に戻る。検索パケットを送られたサーバントは、そのサーバントを起点として、Gnutella型の検索を開始する。
【選択図】 図3
【解決手段】サーバント1は、そこを通過するヒット情報パケットからヒット情報を蓄積する(ステップ31)。サーバントのユーザなどから目的情報の検索の要求があるかどうかを判別し(ステップ32)、そのような要求がなければステップ31に戻り、そのような要求があれば、ステップ33において、直近のN種類のヒット情報に基づいてm1個のサーバントを選択し、その後、選択されたサーバントに対して検索パケットを送り(ステップ34)、処理はステップ31に戻る。検索パケットを送られたサーバントは、そのサーバントを起点として、Gnutella型の検索を開始する。
【選択図】 図3
Description
【0001】
【発明の属する技術分野】
本発明は、P2P(ピア・ツー・ピア;Peer−to−Peer)型の通信によりネットワーク内での目的情報の所在を検索する情報探索方法及び装置に関する。
【0002】
【従来の技術】
P2Pネットワーク技術は、従来のクライアント・サーバ型のネットワークを構成とは異なり、ネットワークに接続した端末自体にサーバ機能を持たせ、端末間でコンピュータ資源やサービスを直接共有できるようにする技術である。このような端末は、サーバとクライアントの両方の機能を有するという意味から、サーバントと呼ばれている。P2Pネットワークは、例えば、IP(インターネットプロトコル;Internet Protocol)網上に構築される。P2Pネットワークは、端末間でのファイルや情報の交換、あるいは、分散コンピューティングなどに使用されている(非特許文献1)。
【0003】
P2Pネットワークの形態には、大別して、目的情報の所在を一括管理するための専用サーバを用いるハイブリッド型と、そのようなサーバを使用せずに、全てのコンピュータが完全に対等であるピュア型とがある。ハイブリッド型のP2P通信の典型例としては、Napsterが挙げられる。Napsterなどのハイブリッド型のP2P通信では、各サーバントからの検索要求パケットが、専用サーバに集中するため、サーバボトルネックとなりやすい。また、専用サーバを設けることは、専用サーバにおける障害の影響がネットワーク全体に拡大することとなり、P2Pネットワークが本来有する耐障害性があるなどの利点を阻害することにもなる。
【0004】
また、ピュア型のP2P通信の典型例としては、Gnutellaが挙げられる。ピュア型のP2Pネットワークシステムでは、目的情報の所在を管理するサーバが存在しないため、各サーバントは他のサーバントに対して目的情報の所在を問い合わせる必要があるが、その問合せのやり方として、Gnutellaでは、目的情報の所在を伝言ゲーム方式で次々に問い合わせている。すなわち、Gnutellaによるネットワークシステムでは、各サーバントは、ネットワーク内における隣接サーバントに対して方路(腕)を伸ばしており、検索パケット中のTTL(Time to Live)に設定された値のホップ数の範囲まで、その全ての方路を用いて、目的の情報の有無を次々に隣接サーバントに対して問い合わせる。したがって、各サーバントでは、隣接サーバントへ伸ばしている方路の分だけ分岐されてパケットが送出されることになる。Gnutellaでは、P2Pネットワークに極めて多数のサーバントが接続している場合であっても、TTLで規定されたホップ数で到達できるサーバントの範囲内で検索を行うことにより、問合せのための時間とトラヒックの量とを現実的な範囲内に留めるようにしている。それでも、Gnutellaでは、このような情報検索パケットが多数のサーバントから並列に発信される場合には、網内のパケット数が爆発的に増加し、網内の広域にわたっての混雑が予想される。なお、目的情報を保持するサーバントの所在が明らかになったら、その目的情報のデータそのもの(ファイル実体など)は、検索要求を発出したサーバントが、IPアドレスなどの情報に基づいて、その目的情報を保持するサーバントに直接接続して取得する。
【0005】
ここでホップ数とは、伝言ゲーム形式でパケットがサーバント間が転送(フォワード)される場合に、あるパケットが何個のサーバントを経由してフォワードされたかを示し、TTL(Time to Live)値とは、何ホップ先までパケットをフォワードさせるかという最大値である。例えば、TTL=7とすることにより、7台(ホップ)先のサーバントまでフォワードされる。なお、この種の検索では、もしこの7台の手前でヒットすれば、そのパケットはその先には転送されないようになっている。以下に説明するように、TTLの値はパケットに書き込まれており、サーバントは、次のサーバントにパケットをフォワードする際に、そのパケットのTTL値を1だけ小さくする。
【0006】
以下、Gnutellaによる目的情報探索の手順について説明する。ここでは、ネットワーク内のサーバントから、そのネットワーク内にあって目的情報を保持している別のサーバントを探索する場合を説明する。P2PネットワークがIPネットワーク上に構築されるものとして、まず、各サーバントがGnutellaのP2Pネットワークに接続する手順を説明する。
(1) 他のサーバントヘ接続し、Pingパケットを送信する。
(2) Pingパケットを受信したサーバントは、TTL値が1より大きく、かつまだ受け取ったことがないGUID(Globally Unique Identifier)をもつパケットならば、TTL値を1つ減らし(このとき、ホップ値を1つ増やす)、そのパケットをさらに別のサーバントへ転送する。
(3) Pingパケットを受信したサーバントは、まだ受け取ったことがないGUIDをもつパケットならば、IPアドレス、接続を受け付けるためのTCPポート番号、公開している目的情報(例えばファイル)の総数などの情報を記録したPongパケットを、そのPingパケットの送信元へ返す。
(4) Pongパケットを受信したサーバントは、対応するPingパケットの送信元へ、そのPongパケットを返す。
(5) Pingパケットを送信し、それに対応するPongパケットを受信したサーバントは、指定された数のサーバントの情報が得られたならば、それらのサーバントに接続し、指定された数のサーバントの情報が得られなければ、さらに別のサーバントを見つけて以上のシーケンスを繰り返す。
【0007】
また、GnutellaのP2Pネットワークにおける目的情報の探索の手順は次の通りである。
(1) ファイル検索元のサーバントは、そのサーバントが直接接続しているサーバントに対して、検索パケット(Query(問い合わせ))パケットを送信する。Queryパケットのペイロードには、「この検索要求に応じるサーバントの最低通信速度」や「検索キーワード」などの検索条件が記録される。
(2) Queryパケットを受信したサーバントは、Queryパケットのヘッダに記録されているTTL値を1つ減らし(このとき、ホップ値を1つ増やす)、TTL値が1より大きければ、自サーバントに接続している全てのサーバント(ただし、Queryパケットを送信したサーバントは除く)へ、Queryパケットをそれぞれ転送する。
(3) 転送されたQueryパケットの条件に合致する目的情報を保持しているサーバントは、ヒット情報パケット(QueryHitパケット)を返し、目的情報を保持していないサーバントは、Queryパケットをさらに転送する。
(4) QueryHitパケットは、Queryパケットが転送されてきた経路を逆順にたどって発信元に戻っていく。QueryHitパケットのペイロードには、条件に合ったファイルの総数、QueryHitしたサーバント(目的情報を保持するサーバント)の各種情報(待ち受けTCPポート番号,IPアドレス,接続通信速度,条件に合った目的情報のファイルの名前とサイズとファイルインデックス(どのファイルであるかを示すためにサーバント側で付与している一連の番号),GUID)が記録されている。すなわちQueryHitパケットには、目的情報の所在情報が格納されている。
【0008】
なお、本出願人は、既に、特願2002−354988において、Gnutella型のP2Pネットワークにおける時々刻々と変化するネットワークトポロジーを再現するために、ネットワークを構成する端末(サーバント)の接続先端末数の分布を効率よくかつ容易に推定できる方法を提案している。
【0009】
【非特許文献1】
伊藤直樹:「P2Pコンピューティング 〜技術解説とアプリケーション」、ソフト・リサーチ・センター、2001
【0010】
【発明が解決しようとしている課題】
上述したように、IP網などのネットワークにおいてP2P型通信を行っている場合には、ネットワーク内あるいは目的情報を有するサーバント内において、輻輳が発生し得る。また、Gnutella型のP2Pネットワークにおいては、TTLに設定されたホップ数の範囲内のサーバントのみを検索範囲として目的情報を検索するので、P2Pネットワーク全体としてみた場合には目的情報が存在していてもその検索範囲内に目的情報が存在しない場合には、検索失敗となるとという問題点もある。
【0011】
そこで本発明の目的は、目的情報の所在を一括管理するためのサーバを用いないP2Pネットワークにおいて、ネットワーク内における検索パケット(目的情報の所在を問合せるためのパケット)の数すなわちトラヒックをできるだけ削減できるとともに、目的情報は確実かつ効率よく探し出すことができる方法及び装置を提供することにある。
【0012】
【課題を解決するための手段】
P2P(Peer−to−Peer)型通信においては、各サーバント(Servent)が対等な立場で通信を行うが、本発明では、このサーバントが有する情報を用いて、なるべく網内に送出される検索パケットの数を少なくしつつ、目的の検索をGnutella型と同程度あるいはそれ以上の確かさで実現させるようにしている。
【0013】
すなわち本発明の第1の情報探索方法は、P2P型通信における、目的情報を保持するサーバントを検索する情報探索方法であって、各サーバントは、通過するヒット情報パケットを解析して直近のヒット情報を収集し、各サーバントが自分自身から検索要求を発出する場合における、検索パケットの送出先となるサーバントを選択する際に、検索要求を発出するサーバントは、収集したヒット情報に基づいてサーバントを選択し、選択したサーバントに検索パケットを直接送り、検索パケットが直接送られたサーバントにおいてヒットしなかった場合には、その直接送られたサーバントを起点として、Gnutella型の検索を開始する。
【0014】
本発明の第2の情報探索方法は、P2P型通信における、目的情報を保持するサーバントを検索する情報探索方法であって、検索要求を発出するサーバントを起点として、TTLをDとしたGnutella型の検索である第1の検索を開始し、第1の検索でヒットしなかった場合には、Dより大きいUだけホップ数が離れたサーバントを選択し(好ましくはU≫D)、選択されたサーバントに対して検索パケットを直接送り、この選択されたサーバントを起点として、Gnutella型の検索である第2の検索を開始する。
【0015】
本発明の第3の情報探索方法は、P2P型通信における、Gnutella型の検索により目的情報を保持するサーバントを検索する情報探索方法であって、各サーバントは、通過するヒット情報パケットを解析して直近のヒット情報を収集し、検索パケットを隣接サーバントに送信しようとするサーバントは、ヒット情報を参照して、当該サーバントに設定された方路の中から検索パケットを送信すべき方路を選択する。
【0016】
本発明におけるGnutella型の検索とは、本明細書の従来の技術に書かれたGnutellaによる目的情報探索と同義であり、端的に言えば、あるサーバントを起点として、設定された方路を介して各サーバントがその隣接サーバントに対して検索パケットを送ることを所定のホップ数の範囲内で繰り返すことにより、目的情報を保持するサーバントを見つけ出す検索のことである。
【0017】
【発明の実施の形態】
次に、本発明の好ましい実施の形態について、図面を参照して説明する。
【0018】
図1は、本発明が適用されるP2Pネットワークの構成の一例を示す図である。ここでは、インターネット(Internet)などのIP網(プロトコルとしてIPを使用するネットワーク)上に、P2Pネットワークが構築されており、P2Pネットワークに対し、多数のサーバント(端末)1が自律分散的に接続している。なおこのP2Pネットワークでは、目的情報の所在を一括管理する専用サーバは設けられていない。ここでは、IP網上にP2Pネットワークが構築されているので、各サーバント1はIPアドレスによって識別されるようになっている。
【0019】
ここでは、図1に示したようなP2Pネットワークにおいて、ネットワーク内における検索パケット(Queryパケット)の数すなわちトラヒックをできるだけ削減できるとともに、目的情報は確実かつ効率よく探し出すことができる各種の手法を説明する。具体的には、P2Pネットワーク内のあるサーバント1が自ら検索要求を発する場合に、(1)どのサーバントを選択して検索パケットを送出するかを決めるサーバント選択法、(2)Gnutella型のサーバントのように複数の方路(腕)が設定されている場合に、どの方路を用いて検索パケットを送出するかを決める方路選択法を説明する。さらに、(3)目的情報が一度見つかった場合に、再度の検索によるトラヒックの増大を避けるための方法として、目的情報の所在情報を経路上のサーバントに格納する方法についても説明する。
【0020】
《第1の実施形態》
サーバント1は、Gnutella型のサーバントと同様に、隣接サーバントに対して伸びる方路(腕)を備え、他のサーバントからの検索パケット(Queryパケット)及びヒット情報パケット(QueryHitパケット)を中継する機能を有する。特に、他サーバントから検索パケットが送られてきた場合には、Gnutella型の検索を実行する機能を備えている。上述した従来の場合と同様に、検索パケットは、ペイロードとして、「この検索要求に応じるサーバントの最低通信速度」や「検索キーワード」などの検索条件を含んでいる。ヒット情報パケットは、ペイロードとして、条件に合ったファイルの総数、QueryHitしたサーバント(目的情報を保持するサーバント)の各種情報(待ち受けTCPポート番号,IPアドレス,接続通信速度,条件に合った目的情報のファイルの名前とサイズとファイルインデックス(どのファイルであるかを示すためにサーバント側で付与している一連の番号),GUID)を含んでいる。
【0021】
さらに、サーバント1は、自身を経由するヒット情報パケットに関して、直近に通過したN種類についてそれぞれの内容(ヒット情報の集合)を記憶する機能を有する。すなわちサーバント1は、そこを経由するヒット情報パケットを解析し、それらのヒット情報パケットに記録されている、QueryHitしたサーバントのIPアドレスを取得し、そのIPアドレスなどの情報をヒット情報として記憶する機能を有する。ヒット情報の詳細については後述する。このようにヒット情報パケットにおいていずれかの目的情報を含むとされたサーバントのことをヒットサーバントと呼ぶことにする。
【0022】
そして、サーバント1がそれ自身から検索要求を発出する場合(すなわち、他サーバントから送られてきた検索パケットによらずに検索を開始する場合)においては、直近に自サーバントを通過したN種類のヒット情報に基づいてm1(ただし1≦m1≦N)個のヒットサーバントを選択し、その選択されたヒットサーバントに対して、直接に(すなわち他への分岐を行うことなしに)、検索パケット(Queryパケット)をその選択されたヒットサーバントに対して送信する。これは、最近、いずれかの目的情報を持つものとしてヒットしたサーバントは、そのヒットした目的情報以外の目的情報も保持している可能性が高い、という仮定(推定)に基づくものである。
【0023】
m1個のヒットサーバントの選択方法としては、(i)直近のm1種類のヒット情報に対応するサーバントを選択する方法や、(ii)N種類のヒット情報のうち、ランダムにm1(1≦m1≦N)種類のサーバントを選択する方法などがある。
【0024】
選択されたヒットサーバントが、目的とする情報を保持している場合には、ヒット情報パケットが、そのサーバントから、検索要求を発出したサーバントに直接返信される。また、選択されたヒットサーバントが、目的とする情報を保持していない場合には、その選択されたヒットサーバントから、新たにGnutella型の検索を開始させる。なお、選択されたヒットサーバントがGnutellaによる検索処理を行えるものであれば、そのサーバントに目的情報が存在しない限り、検索パケットを受信したことによって、その近傍のサーバントに対してGnutella型の検索を自律的に開始するはずである。
【0025】
次に、サーバントに蓄積されるヒット情報について説明する。サーバント1は、そこを通過した直近のN種類のヒット情報を集合として保持するが、その集合は、
(H1(A1,h1,a1,F1),H2(A2,h2,a2,F2),…,HN(AN,hN,aN,FN))
と記述される。ここで、Hkは、現時点から遡ってk番目に新しくそのサーバントを通過したパケットに関するヒット情報であり、Akは、k番目に新しいヒット情報を持つサーバントのIPアドレスであり、hkは、k番目に新しいヒット情報を持つサーバントまでのホップ数であり、akは、k番目に新しくヒットしたサーバントの1ホップ前のサーバントの(ヒットしたサーバントまで伸ばした)腕の番号であり、Fkは、k番目に新しくヒットした検索情報(対象ファイル)の種別である。
【0026】
図2は、検索要求を発出するサーバントにおいて蓄積されているヒット情報の一例を示す図である。ここでは、検索パケットの送出に必要な情報のみが示されている。サーバント1は、各ヒット情報を、ヒット時刻の順で並べ替えてN種類保持しており(図示したものでは、若い番号ほど直近のヒット情報に対応する)、ヒット情報ごとに、ヒット時刻、目的情報に対応するファイル名、ヒットサーバントのIPアドレスを保持している。そして、図示した例では、直近のm1種類のヒット情報に対応するヒットサーバントに対応して「○」印が付されており、これにより、そのサーバントが選択されたことが示されている。
【0027】
図3は、この実施形態での処理をまとめたフローチャートである。サーバント1は、そこを通過するヒット情報パケットからヒット情報を蓄積している(ステップ31)。サーバントのユーザなどから目的情報の検索の要求があるかどうかを判別し(ステップ32)、そのような要求がなければステップ31に戻り、そのような要求があれば、ステップ33において、直近のN種類のヒット情報に基づいてm1個のサーバントを選択し、その後、選択されたサーバントに対して検索パケットを送り(ステップ34)、処理はステップ31に戻る。
【0028】
《第2の実施形態》
従来、Gnutella型のP2Pネットワークでは、目的情報の探索範囲は、自サーバントからTTLで規定されたホップ数の範囲内までの領域に限定されている。そこでこの実施形態では、探索範囲を拡大することによって、より確実に目的情報を検索できるようにしている。
【0029】
この実施形態では、図4に示すように、検索要求を発出するサーバントは、まず、TTLの値をDに設定することによって、Gnutella型の検索により、自サーバントからホップ数がDの範囲内で目的情報を検索する。ここでもし目的情報が見つからない場合には、U≫Dとして、自サーバントからUホップ離れたサーバントをランダムに選択して、その選択されたサーバントに対して検索パケットを直接に送信することによって、その選択されたサーバントを起点としてさらにGnutella型の検索を行うようにしている。サーバントとしては、第1の実施形態におけるサーバントと同様のものが使用できる。ここではヒット情報は使用しないので、サーバントは、ヒット情報を蓄積する機能は備えていなくてもよい。
【0030】
本実施形態では、最初にDホップ内でのGnutella型の検索を行い、そこで目的情報が見つからない場合には、最初の検索範囲からを遠く離れた場所を起点として、再度、Gnutella型の検索を試みる。したがって、従来の検索方法に比べ、実質的に検索範囲が大きく広がるとともに、初期段階での検索範囲を小さく設定することによって(Dの値を通常よりも小さくすることによって)、検索パケットによるトラヒックの増大も防止することができる。
【0031】
図5は、この実施形態での処理をまとめたフローチャートである。サーバント1は、TTLの値をDに設定して、隣接サーバントに対して検索パケットを送信し、Gnutella型の検索を開始する(ステップ51)。この検索で目的情報が見つかったかどうか、すなわち検索パケットに対応するヒット情報パケットを受信したかどうかを判別し(ステップ52)、目的情報が見つかった場合には、そこで検索処理を終了する。一方、ステップ52で目的情報が見つからなかった場合には、Uホップ離れたサーバントをランダムに選択し(ステップ53)、そのサーバントに対して検索パケットを直接送信する(ステップ54)。
【0032】
《第3の実施形態》
次に、本発明の第3の実施形態について説明する。Gnutella型の検索では、各サーバントには、隣接サーバントに対して伸びる方路(腕)が設定されている。ここでは、サーバントが備える方路の数をWで表わすこととする。従来の検索方法では、サーバントごとに、そのサーバントに設定された全ての方路(ただし、転送しようとする検索パケットを送ってきたサーバントへの方路を除く)に対し、検索パケットを転送するようにしている。しかしながら、方路ごとにその方路を経由して目的情報が見つかる確率は均一であるとは限らず、したがって、より目的情報が見つかりそうな方路のみを選択して検索パケットを転送することにより、目的情報の検索精度をほとんど損なうことなく、検索パケットの流通に伴うトラヒックを削減することができる。
【0033】
このように方路を選択して検索パケットを送出するために、各サーバントは、第1の実施形態の場合と同様に、そこを通過するヒット情報パケットを監視して、ヒット情報を蓄積する。
【0034】
ここで、方路の選択の方法としては、目的情報の推定される空間的配置に応じて、以下のものが考えられる。
【0035】
第1の選択方法として、ある目的情報にヒットしたてのサーバント(いわゆるホットなサーバント)は、他の目的情報も保持している可能性が高い、と考えられる場合には、各サーバントにおいて、直近にヒットしたM1個(ただし1≦M1≦W)の方路のみに検索パケットを送出する。この場合、直近にヒットしたM1個以外の方路に対し、それらの方路のそれぞれについて、1未満の確率で検索パケットが送出されるようにしてもよい。
【0036】
第2の選択方法として、ヒットするサーバントは空間内に均一に分散配置していると考えられる場合には、ヒットしていない方向へ分岐を多くして検索する。具体的には、各サーバントのW種類の方路のうち、直近でヒットしていない方路のうちのM2個(ただし1≦M2≦W)の方路、あるいはヒットした数が少ないM2個の方路に対してのみ検索パケットを送出する。この場合、検索パケットを受け取ったサーバントでは、各方路ともヒットしていないようなことがあり得るので、1ホップ目のみにおいて上述したような方路の選択を適用し、2ホップ目からは、B<WであるB個の方路をランダムに選択して、TTL<Dの範囲で検索を続けるようにすることが好ましい。
【0037】
図6は、検索要求を発出するサーバントにおいて蓄積されているヒット情報の一例を示す図である。ここでは、検索パケットの送出に必要な情報のみが示されている。サーバント1は、各ヒット情報を、W個の方路のそれぞれに対応してW種類保持している。上述したように、ヒット情報には、パラメータakとして、k番目に新しくヒットしたサーバントがあるときにどの方路からそのヒットに対応するヒット情報パケットを受け取ったかが記録されており、このパラメータakを用いて、どの方路が、直近にヒットした方路であるかがわかるようになっている。図示したものでは、方路ごとに、直近のヒット時刻、目的情報に対応するファイル名、ヒットサーバントのIPアドレスを保持している。そして、図示した例では、直近にヒットしたM1種類の方路に対応して「○」印が付されており、また、直近でヒットしていない(より少なくヒットしている)M2種類の方路に対応して「★」印が付されている。
【0038】
《第4の実施形態》
Gnutella型の検索では、検索パケットがあるサーバントに到着してそのサーバントにおいてヒットした時に、その検索パケットの伝搬経路の逆順を通って、検索要求を発出したサーバントに対して、ヒット情報パケットが送られる。このとき、検索パケットやヒット情報パケットの伝搬経路の途上にあるサーバントに対してヒット情報を格納しておき、次に、その目的情報についての検索が行われた場合には、そのヒット情報が格納されたサーバントが、目的情報そのものを保持する本来のサーバントに代わってヒット情報パケットを送信することによって、検索パケットの流通に伴うトラヒックを削減することができる。この場合、ヒット情報を格納されたサーバントは、目的情報そのものは保持していないので、ヒット情報からは、目的情報が何であったかを知ることはできない。そこで、サーバントは、第1の実施形態と同様に、直近にそこを通過したN種類のヒット情報パケットの内容をヒット情報をして記憶するとともに、同じく直近にそこを通過したN種類の検索パケットの内容(目的情報(探している情報)の種別)を記憶する機能を備えている。具体的には、集合
(Q1(s1),Q2(s2),…,QN(sN))
を記憶する。ここで、Qkは、現時点から遡ってk番目に新しく当該サーバントを通過したQueryの目的情報であり、skは、k番目に新しい目的情報の内容(探しているファイル種別)である。
【0039】
ヒットした検索パケットとヒット情報パケットとは対になっているものであるから、サーバントは、検索パケットを新たに受け取った場合に、その検索パケットによる検索内容が既に内容が格納されている検索パケットと同じであるかを判別し、同じである場合には、格納しているヒット情報から対応するヒット情報パケットを生成して返信する。
【0040】
図7は、本実施形態におけるヒット情報の格納状態を示している。
【0041】
ところで本実施形態では、各サーバントにヒット情報を無条件で格納してもよいが、各サーバントに対し、ヒット情報の格納の可否を尋ね、可としたサーバントのみにヒット情報を格納するようにしてもよい。また、ヒット情報パケットの伝搬経路上のサーバントのうち、ランダムにS%(ただし0<S<100)を選択してその選択されたサーバントにヒット情報を格納し、残りのサーバントには格納しないようにしてもよい。また、伝搬経路上のP個ごとに離れたサーバントのヒット情報を格納しても良い。さらにまた、経由するサーバントの格納スペースの使用状況を見て、使用状況がX%以下(ただし、0<X<100)であればそのサーバントへヒット情報を格納し、X%より大きな使用率である場合には格納しないようにしてもよい。
【0042】
《サーバントの構成例》
以上、本発明の好ましい実施形態でのサーバント選択方法、方路選択方法及びヒット情報格納方法を説明したが、次に、これらの各方法を実施する際に用いられるサーバントの構成について、図8を用いて説明する。サーバント1は、上述したように、自身を経由する検索パケットとヒット情報パケットとに関して、直近に通過したN種類についてそれぞれの内容(検索パケットに関しては、目的情報(探している情報)の種別、ヒット情報パケットに関しては、ヒット情報の集合)を記憶する機能を備えている。
【0043】
サーバント(端末装置)1は、IP網12に接続し、通常のパーソナルコンピュータの機能を備えるいわゆる端末であるが、P2Pアプリケーションレイヤとしては、サーバントとして見えるものである。このサーバント1は、大別すると、外部からの情報(コマンド)を受け付け、外部へ発信する出力情報を管理する機能を有する入出力管理部2と、サーバント内の各種情報を処理する機能を有するプロセッシング部3と、他サーバントやネットワーク内の状態などの諸々の情報を蓄える機能を備えるメモリ部5と、各種情報をIPパケットに変換したり、その逆にIPパケットから各種情報への分解を行ったりする機能を有するPAD(パケット組み立て/分解部)9と、IPパケットを他のサーバントに送出する機能を備えるパケット送信部10と、網内の他のサーバントから到着するパケットを受信する機能を備えるパケット受信部11と、を備えている。パケット送信部10及びパケット受信部11は、IP網12に接続されており、隣接するサーバントとの間に方路が設定されている。プロセッシング部3の内部には、各種情報の詳細な解析を行う情報解析部4が設けられている。上述の各実施形態で説明したような方路やサーバントの選択も情報解析部4で行われる。メモリ部5の内部には、過去の各種パケットのヒットや情報の有無などの履歴情報を時系列的に解析する機能を備える履歴解析部6と、各種情報を格納/蓄積する場所であるメモリ8と、メモリ8内に格納されている情報の入出力などの管理を行うメモリ管理部7とが設けられている。特に、検索パケットに関しての目的情報(探している情報)の種別と、ヒット情報パケットに関してのヒット情報の集合は、メモリ8内に格納されるようになっている。
【0044】
このようなサーバント1は、それを実現するための計算機プログラムを、パーソナルコンピュータなどに読み込ませ、そのプログラムを実行させることによっても実現できる。サーバントを実現するためのプログラムは、磁気テープやCD−ROMなどの記録媒体によって、あるいは、ネットワークを介して、コンピュータに読み込まれる。
【0045】
そのようなコンピュータは、ハードウェア構成としては、一般に、CPU(中央処理装置)と、プログラムやデータを格納するためのハードディスク装置と、主メモリと、キーボードやマウスなどの入力装置と、CRTなどの表示装置と、CD−ROM等の記録媒体を読み取る読み取り装置と、IP網12との接続に用いられる通信インタフェースと、を備えている。そして、CD−ROM等の記録媒体から、あるいはネットワークからプログラムを読み込み、そのプログラムをCPUが実行することにより、このコンピュータは、上述したサーバントとして機能することになる。
【0046】
【発明の効果】
以上説明したように本発明によれば、P2P型通信を行う際に、網内の検索パケットをなるべく減らして効率よく目的情報(ファイル)を見つけるための手順、手法を確立することができる。また、目的情報のファイルが見つかった後に、そのヒット情報が必要なサーバントに対してのみ効率的に情報を配信及び保持させることができる。
【図面の簡単な説明】
【図1】本発明が適用されるP2Pネットワークの構成の一例を示す図である。
【図2】本発明の第1の実施形態でのヒット情報の一例を示す図である。
【図3】第1の実施形態での検索要求発出サーバントの処理を説明するフローチャートである。
【図4】本発明の第2の実施形態でのサーバント選択法を説明する図である。
【図5】第2の実施形態での検索要求発出サーバントの処理を説明するフローチャートである。
【図6】本発明の第3の実施形態でのヒット情報の一例を示す図である。
【図7】本発明の第4の実施形態を説明する図である。
【図8】サーバントの構成を示すブロック図である。
【符号の説明】
1 サーバント
2 入出力管理部
3 プロセッシング部
4 情報解析部
5 メモリ部
6 履歴解析部
7 メモリ管理部
8 メモリ
9 PAD
10 パケット送信部
11 パケット受信部
12 IP網(インターネット)
【発明の属する技術分野】
本発明は、P2P(ピア・ツー・ピア;Peer−to−Peer)型の通信によりネットワーク内での目的情報の所在を検索する情報探索方法及び装置に関する。
【0002】
【従来の技術】
P2Pネットワーク技術は、従来のクライアント・サーバ型のネットワークを構成とは異なり、ネットワークに接続した端末自体にサーバ機能を持たせ、端末間でコンピュータ資源やサービスを直接共有できるようにする技術である。このような端末は、サーバとクライアントの両方の機能を有するという意味から、サーバントと呼ばれている。P2Pネットワークは、例えば、IP(インターネットプロトコル;Internet Protocol)網上に構築される。P2Pネットワークは、端末間でのファイルや情報の交換、あるいは、分散コンピューティングなどに使用されている(非特許文献1)。
【0003】
P2Pネットワークの形態には、大別して、目的情報の所在を一括管理するための専用サーバを用いるハイブリッド型と、そのようなサーバを使用せずに、全てのコンピュータが完全に対等であるピュア型とがある。ハイブリッド型のP2P通信の典型例としては、Napsterが挙げられる。Napsterなどのハイブリッド型のP2P通信では、各サーバントからの検索要求パケットが、専用サーバに集中するため、サーバボトルネックとなりやすい。また、専用サーバを設けることは、専用サーバにおける障害の影響がネットワーク全体に拡大することとなり、P2Pネットワークが本来有する耐障害性があるなどの利点を阻害することにもなる。
【0004】
また、ピュア型のP2P通信の典型例としては、Gnutellaが挙げられる。ピュア型のP2Pネットワークシステムでは、目的情報の所在を管理するサーバが存在しないため、各サーバントは他のサーバントに対して目的情報の所在を問い合わせる必要があるが、その問合せのやり方として、Gnutellaでは、目的情報の所在を伝言ゲーム方式で次々に問い合わせている。すなわち、Gnutellaによるネットワークシステムでは、各サーバントは、ネットワーク内における隣接サーバントに対して方路(腕)を伸ばしており、検索パケット中のTTL(Time to Live)に設定された値のホップ数の範囲まで、その全ての方路を用いて、目的の情報の有無を次々に隣接サーバントに対して問い合わせる。したがって、各サーバントでは、隣接サーバントへ伸ばしている方路の分だけ分岐されてパケットが送出されることになる。Gnutellaでは、P2Pネットワークに極めて多数のサーバントが接続している場合であっても、TTLで規定されたホップ数で到達できるサーバントの範囲内で検索を行うことにより、問合せのための時間とトラヒックの量とを現実的な範囲内に留めるようにしている。それでも、Gnutellaでは、このような情報検索パケットが多数のサーバントから並列に発信される場合には、網内のパケット数が爆発的に増加し、網内の広域にわたっての混雑が予想される。なお、目的情報を保持するサーバントの所在が明らかになったら、その目的情報のデータそのもの(ファイル実体など)は、検索要求を発出したサーバントが、IPアドレスなどの情報に基づいて、その目的情報を保持するサーバントに直接接続して取得する。
【0005】
ここでホップ数とは、伝言ゲーム形式でパケットがサーバント間が転送(フォワード)される場合に、あるパケットが何個のサーバントを経由してフォワードされたかを示し、TTL(Time to Live)値とは、何ホップ先までパケットをフォワードさせるかという最大値である。例えば、TTL=7とすることにより、7台(ホップ)先のサーバントまでフォワードされる。なお、この種の検索では、もしこの7台の手前でヒットすれば、そのパケットはその先には転送されないようになっている。以下に説明するように、TTLの値はパケットに書き込まれており、サーバントは、次のサーバントにパケットをフォワードする際に、そのパケットのTTL値を1だけ小さくする。
【0006】
以下、Gnutellaによる目的情報探索の手順について説明する。ここでは、ネットワーク内のサーバントから、そのネットワーク内にあって目的情報を保持している別のサーバントを探索する場合を説明する。P2PネットワークがIPネットワーク上に構築されるものとして、まず、各サーバントがGnutellaのP2Pネットワークに接続する手順を説明する。
(1) 他のサーバントヘ接続し、Pingパケットを送信する。
(2) Pingパケットを受信したサーバントは、TTL値が1より大きく、かつまだ受け取ったことがないGUID(Globally Unique Identifier)をもつパケットならば、TTL値を1つ減らし(このとき、ホップ値を1つ増やす)、そのパケットをさらに別のサーバントへ転送する。
(3) Pingパケットを受信したサーバントは、まだ受け取ったことがないGUIDをもつパケットならば、IPアドレス、接続を受け付けるためのTCPポート番号、公開している目的情報(例えばファイル)の総数などの情報を記録したPongパケットを、そのPingパケットの送信元へ返す。
(4) Pongパケットを受信したサーバントは、対応するPingパケットの送信元へ、そのPongパケットを返す。
(5) Pingパケットを送信し、それに対応するPongパケットを受信したサーバントは、指定された数のサーバントの情報が得られたならば、それらのサーバントに接続し、指定された数のサーバントの情報が得られなければ、さらに別のサーバントを見つけて以上のシーケンスを繰り返す。
【0007】
また、GnutellaのP2Pネットワークにおける目的情報の探索の手順は次の通りである。
(1) ファイル検索元のサーバントは、そのサーバントが直接接続しているサーバントに対して、検索パケット(Query(問い合わせ))パケットを送信する。Queryパケットのペイロードには、「この検索要求に応じるサーバントの最低通信速度」や「検索キーワード」などの検索条件が記録される。
(2) Queryパケットを受信したサーバントは、Queryパケットのヘッダに記録されているTTL値を1つ減らし(このとき、ホップ値を1つ増やす)、TTL値が1より大きければ、自サーバントに接続している全てのサーバント(ただし、Queryパケットを送信したサーバントは除く)へ、Queryパケットをそれぞれ転送する。
(3) 転送されたQueryパケットの条件に合致する目的情報を保持しているサーバントは、ヒット情報パケット(QueryHitパケット)を返し、目的情報を保持していないサーバントは、Queryパケットをさらに転送する。
(4) QueryHitパケットは、Queryパケットが転送されてきた経路を逆順にたどって発信元に戻っていく。QueryHitパケットのペイロードには、条件に合ったファイルの総数、QueryHitしたサーバント(目的情報を保持するサーバント)の各種情報(待ち受けTCPポート番号,IPアドレス,接続通信速度,条件に合った目的情報のファイルの名前とサイズとファイルインデックス(どのファイルであるかを示すためにサーバント側で付与している一連の番号),GUID)が記録されている。すなわちQueryHitパケットには、目的情報の所在情報が格納されている。
【0008】
なお、本出願人は、既に、特願2002−354988において、Gnutella型のP2Pネットワークにおける時々刻々と変化するネットワークトポロジーを再現するために、ネットワークを構成する端末(サーバント)の接続先端末数の分布を効率よくかつ容易に推定できる方法を提案している。
【0009】
【非特許文献1】
伊藤直樹:「P2Pコンピューティング 〜技術解説とアプリケーション」、ソフト・リサーチ・センター、2001
【0010】
【発明が解決しようとしている課題】
上述したように、IP網などのネットワークにおいてP2P型通信を行っている場合には、ネットワーク内あるいは目的情報を有するサーバント内において、輻輳が発生し得る。また、Gnutella型のP2Pネットワークにおいては、TTLに設定されたホップ数の範囲内のサーバントのみを検索範囲として目的情報を検索するので、P2Pネットワーク全体としてみた場合には目的情報が存在していてもその検索範囲内に目的情報が存在しない場合には、検索失敗となるとという問題点もある。
【0011】
そこで本発明の目的は、目的情報の所在を一括管理するためのサーバを用いないP2Pネットワークにおいて、ネットワーク内における検索パケット(目的情報の所在を問合せるためのパケット)の数すなわちトラヒックをできるだけ削減できるとともに、目的情報は確実かつ効率よく探し出すことができる方法及び装置を提供することにある。
【0012】
【課題を解決するための手段】
P2P(Peer−to−Peer)型通信においては、各サーバント(Servent)が対等な立場で通信を行うが、本発明では、このサーバントが有する情報を用いて、なるべく網内に送出される検索パケットの数を少なくしつつ、目的の検索をGnutella型と同程度あるいはそれ以上の確かさで実現させるようにしている。
【0013】
すなわち本発明の第1の情報探索方法は、P2P型通信における、目的情報を保持するサーバントを検索する情報探索方法であって、各サーバントは、通過するヒット情報パケットを解析して直近のヒット情報を収集し、各サーバントが自分自身から検索要求を発出する場合における、検索パケットの送出先となるサーバントを選択する際に、検索要求を発出するサーバントは、収集したヒット情報に基づいてサーバントを選択し、選択したサーバントに検索パケットを直接送り、検索パケットが直接送られたサーバントにおいてヒットしなかった場合には、その直接送られたサーバントを起点として、Gnutella型の検索を開始する。
【0014】
本発明の第2の情報探索方法は、P2P型通信における、目的情報を保持するサーバントを検索する情報探索方法であって、検索要求を発出するサーバントを起点として、TTLをDとしたGnutella型の検索である第1の検索を開始し、第1の検索でヒットしなかった場合には、Dより大きいUだけホップ数が離れたサーバントを選択し(好ましくはU≫D)、選択されたサーバントに対して検索パケットを直接送り、この選択されたサーバントを起点として、Gnutella型の検索である第2の検索を開始する。
【0015】
本発明の第3の情報探索方法は、P2P型通信における、Gnutella型の検索により目的情報を保持するサーバントを検索する情報探索方法であって、各サーバントは、通過するヒット情報パケットを解析して直近のヒット情報を収集し、検索パケットを隣接サーバントに送信しようとするサーバントは、ヒット情報を参照して、当該サーバントに設定された方路の中から検索パケットを送信すべき方路を選択する。
【0016】
本発明におけるGnutella型の検索とは、本明細書の従来の技術に書かれたGnutellaによる目的情報探索と同義であり、端的に言えば、あるサーバントを起点として、設定された方路を介して各サーバントがその隣接サーバントに対して検索パケットを送ることを所定のホップ数の範囲内で繰り返すことにより、目的情報を保持するサーバントを見つけ出す検索のことである。
【0017】
【発明の実施の形態】
次に、本発明の好ましい実施の形態について、図面を参照して説明する。
【0018】
図1は、本発明が適用されるP2Pネットワークの構成の一例を示す図である。ここでは、インターネット(Internet)などのIP網(プロトコルとしてIPを使用するネットワーク)上に、P2Pネットワークが構築されており、P2Pネットワークに対し、多数のサーバント(端末)1が自律分散的に接続している。なおこのP2Pネットワークでは、目的情報の所在を一括管理する専用サーバは設けられていない。ここでは、IP網上にP2Pネットワークが構築されているので、各サーバント1はIPアドレスによって識別されるようになっている。
【0019】
ここでは、図1に示したようなP2Pネットワークにおいて、ネットワーク内における検索パケット(Queryパケット)の数すなわちトラヒックをできるだけ削減できるとともに、目的情報は確実かつ効率よく探し出すことができる各種の手法を説明する。具体的には、P2Pネットワーク内のあるサーバント1が自ら検索要求を発する場合に、(1)どのサーバントを選択して検索パケットを送出するかを決めるサーバント選択法、(2)Gnutella型のサーバントのように複数の方路(腕)が設定されている場合に、どの方路を用いて検索パケットを送出するかを決める方路選択法を説明する。さらに、(3)目的情報が一度見つかった場合に、再度の検索によるトラヒックの増大を避けるための方法として、目的情報の所在情報を経路上のサーバントに格納する方法についても説明する。
【0020】
《第1の実施形態》
サーバント1は、Gnutella型のサーバントと同様に、隣接サーバントに対して伸びる方路(腕)を備え、他のサーバントからの検索パケット(Queryパケット)及びヒット情報パケット(QueryHitパケット)を中継する機能を有する。特に、他サーバントから検索パケットが送られてきた場合には、Gnutella型の検索を実行する機能を備えている。上述した従来の場合と同様に、検索パケットは、ペイロードとして、「この検索要求に応じるサーバントの最低通信速度」や「検索キーワード」などの検索条件を含んでいる。ヒット情報パケットは、ペイロードとして、条件に合ったファイルの総数、QueryHitしたサーバント(目的情報を保持するサーバント)の各種情報(待ち受けTCPポート番号,IPアドレス,接続通信速度,条件に合った目的情報のファイルの名前とサイズとファイルインデックス(どのファイルであるかを示すためにサーバント側で付与している一連の番号),GUID)を含んでいる。
【0021】
さらに、サーバント1は、自身を経由するヒット情報パケットに関して、直近に通過したN種類についてそれぞれの内容(ヒット情報の集合)を記憶する機能を有する。すなわちサーバント1は、そこを経由するヒット情報パケットを解析し、それらのヒット情報パケットに記録されている、QueryHitしたサーバントのIPアドレスを取得し、そのIPアドレスなどの情報をヒット情報として記憶する機能を有する。ヒット情報の詳細については後述する。このようにヒット情報パケットにおいていずれかの目的情報を含むとされたサーバントのことをヒットサーバントと呼ぶことにする。
【0022】
そして、サーバント1がそれ自身から検索要求を発出する場合(すなわち、他サーバントから送られてきた検索パケットによらずに検索を開始する場合)においては、直近に自サーバントを通過したN種類のヒット情報に基づいてm1(ただし1≦m1≦N)個のヒットサーバントを選択し、その選択されたヒットサーバントに対して、直接に(すなわち他への分岐を行うことなしに)、検索パケット(Queryパケット)をその選択されたヒットサーバントに対して送信する。これは、最近、いずれかの目的情報を持つものとしてヒットしたサーバントは、そのヒットした目的情報以外の目的情報も保持している可能性が高い、という仮定(推定)に基づくものである。
【0023】
m1個のヒットサーバントの選択方法としては、(i)直近のm1種類のヒット情報に対応するサーバントを選択する方法や、(ii)N種類のヒット情報のうち、ランダムにm1(1≦m1≦N)種類のサーバントを選択する方法などがある。
【0024】
選択されたヒットサーバントが、目的とする情報を保持している場合には、ヒット情報パケットが、そのサーバントから、検索要求を発出したサーバントに直接返信される。また、選択されたヒットサーバントが、目的とする情報を保持していない場合には、その選択されたヒットサーバントから、新たにGnutella型の検索を開始させる。なお、選択されたヒットサーバントがGnutellaによる検索処理を行えるものであれば、そのサーバントに目的情報が存在しない限り、検索パケットを受信したことによって、その近傍のサーバントに対してGnutella型の検索を自律的に開始するはずである。
【0025】
次に、サーバントに蓄積されるヒット情報について説明する。サーバント1は、そこを通過した直近のN種類のヒット情報を集合として保持するが、その集合は、
(H1(A1,h1,a1,F1),H2(A2,h2,a2,F2),…,HN(AN,hN,aN,FN))
と記述される。ここで、Hkは、現時点から遡ってk番目に新しくそのサーバントを通過したパケットに関するヒット情報であり、Akは、k番目に新しいヒット情報を持つサーバントのIPアドレスであり、hkは、k番目に新しいヒット情報を持つサーバントまでのホップ数であり、akは、k番目に新しくヒットしたサーバントの1ホップ前のサーバントの(ヒットしたサーバントまで伸ばした)腕の番号であり、Fkは、k番目に新しくヒットした検索情報(対象ファイル)の種別である。
【0026】
図2は、検索要求を発出するサーバントにおいて蓄積されているヒット情報の一例を示す図である。ここでは、検索パケットの送出に必要な情報のみが示されている。サーバント1は、各ヒット情報を、ヒット時刻の順で並べ替えてN種類保持しており(図示したものでは、若い番号ほど直近のヒット情報に対応する)、ヒット情報ごとに、ヒット時刻、目的情報に対応するファイル名、ヒットサーバントのIPアドレスを保持している。そして、図示した例では、直近のm1種類のヒット情報に対応するヒットサーバントに対応して「○」印が付されており、これにより、そのサーバントが選択されたことが示されている。
【0027】
図3は、この実施形態での処理をまとめたフローチャートである。サーバント1は、そこを通過するヒット情報パケットからヒット情報を蓄積している(ステップ31)。サーバントのユーザなどから目的情報の検索の要求があるかどうかを判別し(ステップ32)、そのような要求がなければステップ31に戻り、そのような要求があれば、ステップ33において、直近のN種類のヒット情報に基づいてm1個のサーバントを選択し、その後、選択されたサーバントに対して検索パケットを送り(ステップ34)、処理はステップ31に戻る。
【0028】
《第2の実施形態》
従来、Gnutella型のP2Pネットワークでは、目的情報の探索範囲は、自サーバントからTTLで規定されたホップ数の範囲内までの領域に限定されている。そこでこの実施形態では、探索範囲を拡大することによって、より確実に目的情報を検索できるようにしている。
【0029】
この実施形態では、図4に示すように、検索要求を発出するサーバントは、まず、TTLの値をDに設定することによって、Gnutella型の検索により、自サーバントからホップ数がDの範囲内で目的情報を検索する。ここでもし目的情報が見つからない場合には、U≫Dとして、自サーバントからUホップ離れたサーバントをランダムに選択して、その選択されたサーバントに対して検索パケットを直接に送信することによって、その選択されたサーバントを起点としてさらにGnutella型の検索を行うようにしている。サーバントとしては、第1の実施形態におけるサーバントと同様のものが使用できる。ここではヒット情報は使用しないので、サーバントは、ヒット情報を蓄積する機能は備えていなくてもよい。
【0030】
本実施形態では、最初にDホップ内でのGnutella型の検索を行い、そこで目的情報が見つからない場合には、最初の検索範囲からを遠く離れた場所を起点として、再度、Gnutella型の検索を試みる。したがって、従来の検索方法に比べ、実質的に検索範囲が大きく広がるとともに、初期段階での検索範囲を小さく設定することによって(Dの値を通常よりも小さくすることによって)、検索パケットによるトラヒックの増大も防止することができる。
【0031】
図5は、この実施形態での処理をまとめたフローチャートである。サーバント1は、TTLの値をDに設定して、隣接サーバントに対して検索パケットを送信し、Gnutella型の検索を開始する(ステップ51)。この検索で目的情報が見つかったかどうか、すなわち検索パケットに対応するヒット情報パケットを受信したかどうかを判別し(ステップ52)、目的情報が見つかった場合には、そこで検索処理を終了する。一方、ステップ52で目的情報が見つからなかった場合には、Uホップ離れたサーバントをランダムに選択し(ステップ53)、そのサーバントに対して検索パケットを直接送信する(ステップ54)。
【0032】
《第3の実施形態》
次に、本発明の第3の実施形態について説明する。Gnutella型の検索では、各サーバントには、隣接サーバントに対して伸びる方路(腕)が設定されている。ここでは、サーバントが備える方路の数をWで表わすこととする。従来の検索方法では、サーバントごとに、そのサーバントに設定された全ての方路(ただし、転送しようとする検索パケットを送ってきたサーバントへの方路を除く)に対し、検索パケットを転送するようにしている。しかしながら、方路ごとにその方路を経由して目的情報が見つかる確率は均一であるとは限らず、したがって、より目的情報が見つかりそうな方路のみを選択して検索パケットを転送することにより、目的情報の検索精度をほとんど損なうことなく、検索パケットの流通に伴うトラヒックを削減することができる。
【0033】
このように方路を選択して検索パケットを送出するために、各サーバントは、第1の実施形態の場合と同様に、そこを通過するヒット情報パケットを監視して、ヒット情報を蓄積する。
【0034】
ここで、方路の選択の方法としては、目的情報の推定される空間的配置に応じて、以下のものが考えられる。
【0035】
第1の選択方法として、ある目的情報にヒットしたてのサーバント(いわゆるホットなサーバント)は、他の目的情報も保持している可能性が高い、と考えられる場合には、各サーバントにおいて、直近にヒットしたM1個(ただし1≦M1≦W)の方路のみに検索パケットを送出する。この場合、直近にヒットしたM1個以外の方路に対し、それらの方路のそれぞれについて、1未満の確率で検索パケットが送出されるようにしてもよい。
【0036】
第2の選択方法として、ヒットするサーバントは空間内に均一に分散配置していると考えられる場合には、ヒットしていない方向へ分岐を多くして検索する。具体的には、各サーバントのW種類の方路のうち、直近でヒットしていない方路のうちのM2個(ただし1≦M2≦W)の方路、あるいはヒットした数が少ないM2個の方路に対してのみ検索パケットを送出する。この場合、検索パケットを受け取ったサーバントでは、各方路ともヒットしていないようなことがあり得るので、1ホップ目のみにおいて上述したような方路の選択を適用し、2ホップ目からは、B<WであるB個の方路をランダムに選択して、TTL<Dの範囲で検索を続けるようにすることが好ましい。
【0037】
図6は、検索要求を発出するサーバントにおいて蓄積されているヒット情報の一例を示す図である。ここでは、検索パケットの送出に必要な情報のみが示されている。サーバント1は、各ヒット情報を、W個の方路のそれぞれに対応してW種類保持している。上述したように、ヒット情報には、パラメータakとして、k番目に新しくヒットしたサーバントがあるときにどの方路からそのヒットに対応するヒット情報パケットを受け取ったかが記録されており、このパラメータakを用いて、どの方路が、直近にヒットした方路であるかがわかるようになっている。図示したものでは、方路ごとに、直近のヒット時刻、目的情報に対応するファイル名、ヒットサーバントのIPアドレスを保持している。そして、図示した例では、直近にヒットしたM1種類の方路に対応して「○」印が付されており、また、直近でヒットしていない(より少なくヒットしている)M2種類の方路に対応して「★」印が付されている。
【0038】
《第4の実施形態》
Gnutella型の検索では、検索パケットがあるサーバントに到着してそのサーバントにおいてヒットした時に、その検索パケットの伝搬経路の逆順を通って、検索要求を発出したサーバントに対して、ヒット情報パケットが送られる。このとき、検索パケットやヒット情報パケットの伝搬経路の途上にあるサーバントに対してヒット情報を格納しておき、次に、その目的情報についての検索が行われた場合には、そのヒット情報が格納されたサーバントが、目的情報そのものを保持する本来のサーバントに代わってヒット情報パケットを送信することによって、検索パケットの流通に伴うトラヒックを削減することができる。この場合、ヒット情報を格納されたサーバントは、目的情報そのものは保持していないので、ヒット情報からは、目的情報が何であったかを知ることはできない。そこで、サーバントは、第1の実施形態と同様に、直近にそこを通過したN種類のヒット情報パケットの内容をヒット情報をして記憶するとともに、同じく直近にそこを通過したN種類の検索パケットの内容(目的情報(探している情報)の種別)を記憶する機能を備えている。具体的には、集合
(Q1(s1),Q2(s2),…,QN(sN))
を記憶する。ここで、Qkは、現時点から遡ってk番目に新しく当該サーバントを通過したQueryの目的情報であり、skは、k番目に新しい目的情報の内容(探しているファイル種別)である。
【0039】
ヒットした検索パケットとヒット情報パケットとは対になっているものであるから、サーバントは、検索パケットを新たに受け取った場合に、その検索パケットによる検索内容が既に内容が格納されている検索パケットと同じであるかを判別し、同じである場合には、格納しているヒット情報から対応するヒット情報パケットを生成して返信する。
【0040】
図7は、本実施形態におけるヒット情報の格納状態を示している。
【0041】
ところで本実施形態では、各サーバントにヒット情報を無条件で格納してもよいが、各サーバントに対し、ヒット情報の格納の可否を尋ね、可としたサーバントのみにヒット情報を格納するようにしてもよい。また、ヒット情報パケットの伝搬経路上のサーバントのうち、ランダムにS%(ただし0<S<100)を選択してその選択されたサーバントにヒット情報を格納し、残りのサーバントには格納しないようにしてもよい。また、伝搬経路上のP個ごとに離れたサーバントのヒット情報を格納しても良い。さらにまた、経由するサーバントの格納スペースの使用状況を見て、使用状況がX%以下(ただし、0<X<100)であればそのサーバントへヒット情報を格納し、X%より大きな使用率である場合には格納しないようにしてもよい。
【0042】
《サーバントの構成例》
以上、本発明の好ましい実施形態でのサーバント選択方法、方路選択方法及びヒット情報格納方法を説明したが、次に、これらの各方法を実施する際に用いられるサーバントの構成について、図8を用いて説明する。サーバント1は、上述したように、自身を経由する検索パケットとヒット情報パケットとに関して、直近に通過したN種類についてそれぞれの内容(検索パケットに関しては、目的情報(探している情報)の種別、ヒット情報パケットに関しては、ヒット情報の集合)を記憶する機能を備えている。
【0043】
サーバント(端末装置)1は、IP網12に接続し、通常のパーソナルコンピュータの機能を備えるいわゆる端末であるが、P2Pアプリケーションレイヤとしては、サーバントとして見えるものである。このサーバント1は、大別すると、外部からの情報(コマンド)を受け付け、外部へ発信する出力情報を管理する機能を有する入出力管理部2と、サーバント内の各種情報を処理する機能を有するプロセッシング部3と、他サーバントやネットワーク内の状態などの諸々の情報を蓄える機能を備えるメモリ部5と、各種情報をIPパケットに変換したり、その逆にIPパケットから各種情報への分解を行ったりする機能を有するPAD(パケット組み立て/分解部)9と、IPパケットを他のサーバントに送出する機能を備えるパケット送信部10と、網内の他のサーバントから到着するパケットを受信する機能を備えるパケット受信部11と、を備えている。パケット送信部10及びパケット受信部11は、IP網12に接続されており、隣接するサーバントとの間に方路が設定されている。プロセッシング部3の内部には、各種情報の詳細な解析を行う情報解析部4が設けられている。上述の各実施形態で説明したような方路やサーバントの選択も情報解析部4で行われる。メモリ部5の内部には、過去の各種パケットのヒットや情報の有無などの履歴情報を時系列的に解析する機能を備える履歴解析部6と、各種情報を格納/蓄積する場所であるメモリ8と、メモリ8内に格納されている情報の入出力などの管理を行うメモリ管理部7とが設けられている。特に、検索パケットに関しての目的情報(探している情報)の種別と、ヒット情報パケットに関してのヒット情報の集合は、メモリ8内に格納されるようになっている。
【0044】
このようなサーバント1は、それを実現するための計算機プログラムを、パーソナルコンピュータなどに読み込ませ、そのプログラムを実行させることによっても実現できる。サーバントを実現するためのプログラムは、磁気テープやCD−ROMなどの記録媒体によって、あるいは、ネットワークを介して、コンピュータに読み込まれる。
【0045】
そのようなコンピュータは、ハードウェア構成としては、一般に、CPU(中央処理装置)と、プログラムやデータを格納するためのハードディスク装置と、主メモリと、キーボードやマウスなどの入力装置と、CRTなどの表示装置と、CD−ROM等の記録媒体を読み取る読み取り装置と、IP網12との接続に用いられる通信インタフェースと、を備えている。そして、CD−ROM等の記録媒体から、あるいはネットワークからプログラムを読み込み、そのプログラムをCPUが実行することにより、このコンピュータは、上述したサーバントとして機能することになる。
【0046】
【発明の効果】
以上説明したように本発明によれば、P2P型通信を行う際に、網内の検索パケットをなるべく減らして効率よく目的情報(ファイル)を見つけるための手順、手法を確立することができる。また、目的情報のファイルが見つかった後に、そのヒット情報が必要なサーバントに対してのみ効率的に情報を配信及び保持させることができる。
【図面の簡単な説明】
【図1】本発明が適用されるP2Pネットワークの構成の一例を示す図である。
【図2】本発明の第1の実施形態でのヒット情報の一例を示す図である。
【図3】第1の実施形態での検索要求発出サーバントの処理を説明するフローチャートである。
【図4】本発明の第2の実施形態でのサーバント選択法を説明する図である。
【図5】第2の実施形態での検索要求発出サーバントの処理を説明するフローチャートである。
【図6】本発明の第3の実施形態でのヒット情報の一例を示す図である。
【図7】本発明の第4の実施形態を説明する図である。
【図8】サーバントの構成を示すブロック図である。
【符号の説明】
1 サーバント
2 入出力管理部
3 プロセッシング部
4 情報解析部
5 メモリ部
6 履歴解析部
7 メモリ管理部
8 メモリ
9 PAD
10 パケット送信部
11 パケット受信部
12 IP網(インターネット)
Claims (13)
- P2P型通信における、目的情報を保持するサーバントを検索する情報探索方法であって、
各サーバントは、通過するヒット情報パケットを解析して直近のヒット情報を収集し、
各サーバントが自分自身から検索要求を発出する場合における、検索パケットの送出先となるサーバントを選択する際に、
検索要求を発出するサーバントは、収集したヒット情報に基づいてサーバントを選択し、
選択したサーバントに検索パケットを直接送り、
該検索パケットが直接送られたサーバントにおいてヒットしなかった場合には、当該直接送られたサーバントを起点として、設定された方路を介して隣接サーバントに対して検索パケットを送ることを所定のホップ数の範囲内で繰り返すことによる検索を開始する、
経路選択方法。 - 前記直近のヒット情報に基づいて、直近にヒットした所定数のサーバントを選択する、請求項1に記載の情報探索方法。
- 所定の数の直近のヒット情報を収集し、収集されたヒット情報の中からランダムにサーバントを選択する、請求項1に記載の情報探索方法。
- P2P型通信における、目的情報を保持するサーバントを検索する情報探索方法であって、
検索要求を発出するサーバントを起点として、設定された方路を介して隣接サーバントに対して検索パケットを送ることを第1の所定数のホップ数の範囲内で繰り返すことによる第1の検索を開始し、
前記第1の検索でヒットしなかった場合には、前記第1の所定数より大きい第2の所定数だけホップ数が離れたサーバントを選択し、前記選択されたサーバントに対して検索パケットを直接送り、前記選択されたサーバントを起点として、設定された方路を介して隣接サーバントに対して検索パケットを送ることを第3の所定数のホップ数の範囲内で繰り返すことによる第2の検索を開始する、
情報探索方法。 - P2P型通信における、設定された方路を介して隣接サーバントに対して検索パケットを送ることを所定のホップ数の範囲内で繰り返すことにより、目的情報を保持するサーバントを検索する情報探索方法であって、
各サーバントは、通過するヒット情報パケットを解析して直近のヒット情報を収集し、
検索パケットを隣接サーバントに送信しようとするサーバントは、前記ヒット情報を参照して、当該サーバントに設定された方路の中から前記検索パケットを送信すべき方路を選択する、情報探索方法。 - 前記サーバントがW種類の方路を有し、1≦M1≦Wとして、直近でヒットしたM1種類の方路に対してのみ前記検索パケットを送出する、請求項5に記載の情報探索方法。
- 前記サーバントがW種類の方路を有し、1≦M2≦Wとして、直近でよりヒットしなかったM2種類の方路に対してのみ前記検索パケットを送出する、請求項5に記載の情報探索方法。
- P2P型通信における、設定された方路を介して隣接サーバントに対して検索パケットを送ることを所定のホップ数の範囲内で繰り返し、ヒットした検索パケットの伝搬経路の逆経路で目的情報を保持するサーバントからヒット情報パケットを受け取ることにより、当該目的情報を保持するサーバントを検索する情報探索方法であって、
前記伝搬経路上にあるサーバントに対し、前記ヒット情報パケットに基づくヒット情報を格納する、情報探索方法。 - P2P型通信において用いられるサーバントであって、
P2Pネットワークと接続し、検索パケット及びヒット情報パケットを送受信するパケット送受信部と、
通過した検索パケット及びヒット情報パケットに関して、直近に通過したN種類の内容を記憶するメモリと、
前記メモリの内容に基づいて、前記検索パケットの送出先を決定する情報解析部と、
を有する、サーバント。 - コンピュータをP2P型通信におけるサーバントとして機能させるプログラムであって、前記コンピュータに、
通過するヒット情報パケットを解析して直近のヒット情報を収集する処理と、
検索要求を発出する場合において、前記収集したヒット情報に基づいてサーバントを選択する処理と、
選択したサーバントに検索パケットを直接送る処理と、
検索パケットが送られてきたときに、自サーバントでヒットしなかった場合には、設定された方路を介して隣接サーバントに対して検索パケットを送ることを所定のホップ数の範囲内で繰り返すことによる検索を開始する処理と、
を実行させるプログラム。 - コンピュータをP2P型通信におけるサーバントとして機能させるプログラムであって、前記コンピュータに、
設定された方路を介して隣接サーバントに対して検索パケットを送ることを第1の所定数のホップ数の範囲内で繰り返すことによる第1の検索を開始する処理と、
前記第1の検索でヒットしなかった場合には、前記第1の所定数より大きい第2の所定数だけホップ数が離れたサーバントを選択し、前記選択されたサーバントに対して検索パケットを直接送る処理と、
を実行させるプログラム。 - コンピュータをP2P型通信におけるサーバントとして機能させるプログラムであって、前記コンピュータに、
通過するヒット情報パケットを解析して直近のヒット情報を収集する処理と、
前記ヒット情報を参照して、予め設定されている方路の中から検索パケットを送信すべき方路を選択する処理と、
を実行させるプログラム。 - コンピュータが読み取り可能な記録媒体であって、請求項10乃至12のいずれか1項に記載のプログラムを記録した記録媒体。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2003138896A JP2004341912A (ja) | 2003-05-16 | 2003-05-16 | 情報探索方法、サーバント、プログラム及び該プログラムを記録した記録媒体 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2003138896A JP2004341912A (ja) | 2003-05-16 | 2003-05-16 | 情報探索方法、サーバント、プログラム及び該プログラムを記録した記録媒体 |
Publications (1)
Publication Number | Publication Date |
---|---|
JP2004341912A true JP2004341912A (ja) | 2004-12-02 |
Family
ID=33528138
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2003138896A Pending JP2004341912A (ja) | 2003-05-16 | 2003-05-16 | 情報探索方法、サーバント、プログラム及び該プログラムを記録した記録媒体 |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP2004341912A (ja) |
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2006180490A (ja) * | 2004-12-23 | 2006-07-06 | Nec Corp | ネットワーク内でサービス、リソースおよび/または機能を検索する方法 |
JP2007519375A (ja) * | 2004-01-23 | 2007-07-12 | タイヴァーサ・インコーポレーテッド | ピアツーピア・ネットワーク通信の改善方法 |
JP2022144902A (ja) * | 2021-03-19 | 2022-10-03 | ヤフー株式会社 | 情報処理装置、情報処理方法および情報処理プログラム |
-
2003
- 2003-05-16 JP JP2003138896A patent/JP2004341912A/ja active Pending
Cited By (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2007519375A (ja) * | 2004-01-23 | 2007-07-12 | タイヴァーサ・インコーポレーテッド | ピアツーピア・ネットワーク通信の改善方法 |
JP4714698B2 (ja) * | 2004-01-23 | 2011-06-29 | タイヴァーサ・インコーポレーテッド | ピアツーピア・ネットワーク通信の改善方法 |
JP2006180490A (ja) * | 2004-12-23 | 2006-07-06 | Nec Corp | ネットワーク内でサービス、リソースおよび/または機能を検索する方法 |
JP2022144902A (ja) * | 2021-03-19 | 2022-10-03 | ヤフー株式会社 | 情報処理装置、情報処理方法および情報処理プログラム |
JP7419286B2 (ja) | 2021-03-19 | 2024-01-22 | Lineヤフー株式会社 | 情報処理装置、情報処理方法および情報処理プログラム |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US7376749B2 (en) | Heuristics-based peer to peer message routing | |
US9300534B2 (en) | Method for optimally utilizing a peer to peer network | |
EP1719308B1 (en) | Selecting nodes close to another node in a network using location information for the nodes | |
US7289520B2 (en) | Method, apparatus, and system for expressway routing among peers | |
JP4915848B2 (ja) | オーバーレイネットワークでピア・ツー・ピアのファイル送受信を行うコンピュータプログラム | |
US7461128B2 (en) | Method, apparatus and system for processing message bundles on a network | |
US20100293294A1 (en) | Peer-to-peer communication optimization | |
US7747777B2 (en) | Optimizing network resources usage within an administrative boundary | |
JP5470828B2 (ja) | データ配信用通信装置、及びデータ配信システム | |
US7958195B2 (en) | Method and apparatus for improving data transfers in peer-to-peer networks | |
EP1719331B1 (en) | Determining location information for a node in a network using at least one local landmark node | |
US7848339B2 (en) | Data communication apparatus, method for its network configuration, and computer readable recording medium storing its program | |
JP4611319B2 (ja) | ネットワークアーキテクチャ | |
RU2483457C2 (ru) | Платформа маршрутизации сообщений | |
EP1473897A1 (en) | Information processing device, information processing method, and computer program | |
KR20110122947A (ko) | 허브 및 가상 그룹에 속하는 송, 수신 단말의 통신 방법 | |
EP1440529B1 (en) | System and method for information object routing in computer networks | |
JP2004341912A (ja) | 情報探索方法、サーバント、プログラム及び該プログラムを記録した記録媒体 | |
JP2004258994A (ja) | P2pネットワークにおける動的なファイル検索方法、端末、プログラム、および記録媒体 | |
JP2006221457A (ja) | Pure型P2P通信におけるレプリケーション制御を行うサーバントとそのレプリケーション制御方法およびプログラム | |
JP2004127074A (ja) | P2pネットワークにおけるファイル検索方法、端末、プログラム、および記録媒体 | |
Lai | A multi-custodians distributed storage mechanism for DTN storage-based congestion problem | |
WO2004001629A1 (ja) | ネットワークシステムおよびプログラム | |
CN118018472A (zh) | 一种数据传输处理方法、装置、存储介质及电子装置 | |
Heling | Peer Selection in Direct Connect |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
RD04 | Notification of resignation of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7424 Effective date: 20050621 |