JP2004021770A - ネットワークシステムおよびプログラム - Google Patents
ネットワークシステムおよびプログラム Download PDFInfo
- Publication number
- JP2004021770A JP2004021770A JP2002178038A JP2002178038A JP2004021770A JP 2004021770 A JP2004021770 A JP 2004021770A JP 2002178038 A JP2002178038 A JP 2002178038A JP 2002178038 A JP2002178038 A JP 2002178038A JP 2004021770 A JP2004021770 A JP 2004021770A
- Authority
- JP
- Japan
- Prior art keywords
- node
- resource
- command
- search
- 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
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/104—Peer-to-peer [P2P] networks
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/104—Peer-to-peer [P2P] networks
- H04L67/1061—Peer-to-peer [P2P] networks using node-based peer discovery mechanisms
- H04L67/1068—Discovery involving direct consultation or announcement among potential requesting and potential source peers
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/56—Provisioning of proxy services
- H04L67/568—Storing data temporarily at an intermediate stage, e.g. caching
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
- H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
- H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
- H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Security & Cryptography (AREA)
- Computer And Data Communications (AREA)
- Information Transfer Between Computers (AREA)
Abstract
【課題】コマンドの増殖を効率よく防止し、通信トラフィックを減少させることができるようにする。
【解決手段】ネットワーク上の各ノードは、他のノードが備えるリソースの在り処を表す情報をキャッシュ記憶するキャッシュ記憶部１７と、ｌｏｏｋｕｐコマンドを受信したときにキャッシュ記憶部１７を検索し、この検索にヒットした場合にはｌｏｏｋｕｐコマンドを消滅させ、それに対応するｈｉｔリプライを直ちに返すように制御する制御部１３とを備える。これにより、実際にはリソースがｌｏｏｋｕｐコマンド発行元から遠くに存在する場合でも、それより近いノードからｈｉｔリプライを返し、それ以降はｌｏｏｋｕｐコマンドを伝播しなくても済むようにする。
【選択図】 図２
【解決手段】ネットワーク上の各ノードは、他のノードが備えるリソースの在り処を表す情報をキャッシュ記憶するキャッシュ記憶部１７と、ｌｏｏｋｕｐコマンドを受信したときにキャッシュ記憶部１７を検索し、この検索にヒットした場合にはｌｏｏｋｕｐコマンドを消滅させ、それに対応するｈｉｔリプライを直ちに返すように制御する制御部１３とを備える。これにより、実際にはリソースがｌｏｏｋｕｐコマンド発行元から遠くに存在する場合でも、それより近いノードからｈｉｔリプライを返し、それ以降はｌｏｏｋｕｐコマンドを伝播しなくても済むようにする。
【選択図】 図２
Description
【０００１】
【発明の属する技術分野】
本発明はネットワークシステムおよびプログラムに関し、特に、サーバを介さずにクライアント同士で直接データの交換を行うシステムに用いて好適なものである。
【０００２】
【従来の技術】
近年、インターネットの浸透とインターネットユーザ数の爆発的増加という社会的背景、パーソナルコンピュータ（パソコン）の高性能化とネットワークの高速化という技術的背景をもとに、ピアツーピア（Ｐ２Ｐ）と呼ばれるネットワーク技術が注目を集めている。
【０００３】
従来のネットワークシステムは、少数のサーバと多数のクライアントとをネットワークを介して接続したものが殆どであり、クライアントで生成されたリソースはサーバに集められて管理されていた。ところが、爆発的ユーザ数増加の中、ユーザの生み出したリソースをサーバに集めるコストは無視できないものになっている。
【０００４】
すなわち、従来のＷｅｂアーキテクチャにおいてサーバにリソースを集める際に、インターネット上に散らばっているリソースを発見するメカニズムには、ディレクトリサービスとサーチエンジンの２つのタイプが存在する。前者は人海戦術と呼ぶべきアプローチで、人手の作業によってリソースを集めるものである。後者はエージェントロボットがインターネットを巡回することによってリソースを集めてまわるものであり、何れのタイプも言わば力任せのアプローチである。
【０００５】
また、サーバに集められたリソースは、アクセスの集中を生む。この結果、クライアントとして用いられる高性能なパソコンは殆ど遊休状態となり、高速ネットワークもサーバ周辺だけがいびつに混雑する結果となっている。
【０００６】
これに対し、Ｐ２Ｐによるネットワーク技術は、ユーザに近い部分でサーバを介さずに、クライアント同士がダイレクトに情報のやり取りをするアーキテクチャである。つまり、多数のクライアントで生成されたリソースはそれぞれのクライアント自身で管理されるため、多数のリソースをサーバに集める必要もないし、リソース取得のためにアクセスの集中が生じることも殆どない。また、高性能なパソコンが持つ遊休資源を有効に使うことも可能となる。
【０００７】
図５を参照して、Ｐ２Ｐアーキテクチャを利用して所望のリソースを検索および取得する際の手順を説明する。まず、図５（ａ）のように、リソース１１０の取得を希望しているユーザのノード１００は、どこにリソース１１０があるかを探し出すためのｌｏｏｋｕｐコマンドを近接ノード（接続しているノード）１０１，１０２に発行する。
【０００８】
ｌｏｏｋｕｐコマンド受け取ったノード１０１，１０２は、要求されているリソース１１０を自身が持っているかどうかを調べる。該当するリソース１１０が見つからない場合は、図５（ｂ）のように、ｌｏｏｋｕｐコマンドを近接ノード（ｌｏｏｋｕｐコマンドの送信元以外で接続しているノード）１０３〜１０６に転送する。このｌｏｏｋｕｐコマンドを受け取ったノード１０３〜１０６も、要求されているリソース１１０を自身が持っているかどうかを調べる。
【０００９】
このようにコマンド伝播とリソース１１０の検索を繰り返していく中で、ノード１０３では、リソース１１０の検索にヒットする。検索にヒットした場合は、図５（ｃ）に示すように、ｌｏｏｋｕｐコマンドの送信元であるノード１０１にｈｉｔリプライを返す。ｈｉｔリプライを受け取ったノード１０１は、ｌｏｏｋｕｐコマンドの送信元であるユーザノード１００にｈｉｔリプライを転送する。このようにｈｉｔリプライは、ｌｏｏｋｕｐコマンドを伝播した各ノードにより逆向きに伝播され、コマンド発行元のユーザノード１００まで届けられる。
【００１０】
ｈｉｔリプライは、リソース１１０のアクセスインタフェースの名前と検索ヒットノード１０３の情報とを含むパケットである。以上の手順により、最初にｌｏｏｋｕｐコマンドを発行したユーザノード１００では、所望のリソース１１０がノード１０３に存在することを発見できる。ｈｉｔリプライを受け取ったユーザノード１００は次に、図５（ｄ）のようにノード１０３にダイレクトにアクセスし、リソース１１０を取得する。
【００１１】
【発明が解決しようとする課題】
しかしながら、上記従来のＰ２Ｐネットワーク技術では、リソースを取得する前提として、所望のリソースがどこにあるかを発見するためにｌｏｏｋｕｐコマンドを多数のノードに伝播していかなければならならない。そのため、ネットワーク上に非常に多くのコマンド伝播が生じ、それだけ通信トラフィックが増大するという問題があった。
【００１２】
個々のコマンドについては、そのパケットにＴＴＬ（Ｔｉｍｅ Ｔｏ Ｌｉｖｅ）を設定してコマンドの増殖を防止する工夫はなされている。ＴＴＬとは、コマンド伝播回数を設定しておき、ノードがｌｏｏｋｕｐコマンドを受信する毎にこれを１つずつ減算していき、ゼロになったときにそのコマンドを消滅するようにしたものである。このＴＴＬを用いれば、あるｌｏｏｋｕｐコマンドが発行されたにも関わらず所望のリソースが発見されない場合に、そのコマンドが無限に伝播されていくのを防止し、ネットワーク上に無駄なコマンドが飛び交うのを防ぐことができる。
【００１３】
しかしながら、このようなＴＴＬを用いたとしても、所望のリソースが発見されない場合に限ってコマンドの増殖を防ぐことができるに過ぎず、所望のリソースが存在する場合におけるコマンド増殖は防ぐことができない。すなわち、ｌｏｏｋｕｐコマンド発行元ノードの近くにリソースが存在すれば、コマンドの増殖はそれほど多くならない。しかし、コマンド発行元ノードから遠く離れたノードにしかリソースがない場合は、そのリソースを発見するまでに多数のノードを経由することになり、コマンドの増殖を生む。
【００１４】
このように、コマンド発行元ノードから遠く離れたノードにしかリソースが存在しない場合は、コマンドの増殖によってネットワーク上の通信トラフィックが増大するという問題を生じる。また、あるノードがｌｏｏｋｕｐコマンドを発行してからｈｉｔリプライを受信するまでの時間が長くなり、ネットワークとしての応答性が悪くなるという問題も生じる。
【００１５】
また、従来のＰ２Ｐネットワーク技術では、交換可能なリソースは所有者が不特定のファイルだけであり、特定の所有者のリソースを共有することはできなかった。例えば、あるユーザのスケジュール情報等に代表される知識データベースを他のノードでも共有することはできなかった。これは、特定ユーザのリソースはそのユーザが使用するノードにのみ存在し、これをコピーして管理する仕組みがないためである。
【００１６】
すなわち、所有者が不特定のファイルであれば、これをコピーして複数のノードに置いておくことができるため、ｌｏｏｋｕｐコマンドによるリソースの発見および交換が比較的容易に行われる。これに対して、特定ユーザのリソースは特定のノードにのみ存在するため、そこから遠くにあるノードからでは、ＴＴＬの制御によってｌｏｏｋｕｐコマンドが途中で消滅してしまい、リソースを発見できないことが多くなる。
【００１７】
運良くリソースを発見できても、発見するまでにコマンドの増殖を招き、通信トラフィックが混雑する原因となってしまう。また、ｌｏｏｋｕｐコマンドを発行してからｈｉｔリプライが返ってくるまでの応答性も極めて悪くなる。以上のような理由から、従来はＰ２Ｐネットワークシステムにおいて特定ユーザの知識ＤＢを共有することは実質的にできなかった。
【００１８】
また、生存期間が比較的短く、更新やコピー、移動などが頻繁に行われるリソース（以下、動的リソースと呼ぶ）を複数のノード間で共有しようとする場合、複数のノードに存在する同じリソースは常に同じ内容となるようにしておかなければならない。複数のノードに存在する動的リソースの内容がまちまちであると、どのノードがｌｏｏｋｕｐコマンドにより発見されるかによって、取得するリソースが古い内容であったり新しい内容であったりして問題となるからである。
【００１９】
そのため、ネットワーク上では、複数のノードに存在する同じ動的リソースが全て最新版となるように、あるノードにおいて動的リソースが更新されたときには、その更新された動的リソースは他のノードにも転送されるようになっている。これにより、ネットワーク上には多量のデータが定常的に流れており、これも通信トラフィックを混雑させる要因になっているという問題があった。
【００２０】
本発明は、このような問題を解決するために成されたものであり、コマンドの増殖を効率よく防止し、通信トラフィックを減少させることができるようにすることを目的とする。
また、本発明は、ｌｏｏｋｕｐコマンドを発行してからｈｉｔリプライが返ってくるまでの応答性を向上させることができるようにすることも目的とする。
また、本発明は、Ｐ２Ｐネットワーク技術において特定ユーザの知識ＤＢを共有することができるようにすることも目的とする。
また、本発明は、動的リソースを最新版に保つために行われるデータ転送の量を削減し、通信トラフィックを減少させることができるようにすることも目的としている。
【００２１】
【課題を解決するための手段】
本発明のネットワークシステムは、各ノードが、検索ヒット応答の伝播時に、検索ヒットノードが備えるリモートリソースの識別情報とその在り処をキャッシュ記憶するキャッシュ記憶手段と、リソース検索コマンドが与えられたときに上記キャッシュ記憶手段を参照してリソースの検索を行い、当該リソースの検索にヒットした場合に検索ヒット応答を返すように制御する制御手段とを備えたことを特徴とする。
【００２２】
本発明の他の態様では、各ノードが、リソースの識別情報およびそのリソースに関するユーザ情報を記憶する情報記憶手段と、リソース検索コマンドが与えられたときに上記情報記憶手段を参照してリソースの検索を行い、要求されたユーザリソースの検索にヒットした場合に検索ヒット応答を返すように制御する制御手段とを備えたことを特徴とする。
【００２３】
本発明の他の態様では、各ノードが、リソースを、当該リソースが更新されたときには更新前後の差分情報を記憶して管理するリソース管理手段と、リソースの識別情報および差分情報に関する版情報を記憶する情報記憶手段と、リソース検索コマンドが与えられたときに上記情報記憶手段を参照してリソースの検索を行い、当該リソースの検索にヒットした場合に検索ヒット応答を返すように制御する制御手段とを備えたことを特徴とする。
【００２４】
本発明の他の態様では、各ノードが、最新の差分情報を検索するリソース検索コマンドを所定タイミング毎に発行して上記最新の差分情報を取得する同期処理手段を備えたことを特徴とする。
【００２５】
本発明の他の態様では、各ノードが、接続、アクセス、コマンド伝播の少なくとも一に関する履歴を記憶する履歴記憶手段と、上記履歴記憶手段に記憶されている履歴に基づいて、複数ノード間の接続を制御する接続制御手段とを備えたことを特徴とする。
【００２６】
【発明の実施の形態】
以下、本発明の一実施形態を図面に基づいて説明する。
図１は、本実施形態のネットワークシステムが適用されるネットワークの概略構成例を示す図である。本実施形態のネットワークは、ノードの集合１００〜１０８で定義される。ノードとは、本実施形態のプロトコルを実装したプログラムのプロセスのことを言う。したがって、例えば１つのパソコンの中にも、起動しているプログラムが複数あれば、複数のノードが存在することになる。
【００２７】
ノード同士は、複数のセッションを互いに張った状態でトポロジを形成する。この常態的なセッションを「接続」と呼ぶことにする。「接続」が常態的なトポロジ形成をなして、この接続セッション上を基本的なプロトコル（リソース検索コマンドに相当するｌｏｏｋｕｐコマンドや、検索ヒット応答に相当するｈｉｔリプライ等）が流れる。
【００２８】
これに対して、ユーザノード１００（ｌｏｏｋｕｐコマンドの発行元ノード）からリソース１１０の存在するノード１０３（ｈｉｔリプライの発行元ノード）に対して張るセッションを「アクセス」と呼ぶことにする。「アクセス」は、リソース発見後にコマンド発行元ノードと検索ヒットノードとの間に一時的に張られるセッションで、この上をアクセスインタフェースに応じたプロトコルが流れる。
【００２９】
上記した「接続」および「アクセス」のトポロジ形成の状態は中央で管理されず、個々のノード１００〜１０８が自律的に形成する。
【００３０】
図２は、各ノード１００〜１０８が備える機能構成を示すブロック図である。図２において、１１は接続部であり、他のノードと接続してｌｏｏｋｕｐコマンドやｈｉｔリプライ等のやり取りを行う。１２はアクセス部であり、他のノードとアクセスしてリソースのやり取りを行う。１３は制御部であり、ノード内の全体制御を行う。
【００３１】
１４はインデックス記憶部であり、自身が元々備えるローカルリソースのインデックスを記憶する。制御部１３は、起動時にローカルストレージにあるリソースのインデックスをインデックス記憶部１４に登録する。リモートにある他のノードからリソースをコピーした場合も、そのインデックスをインデックス記憶部１４に登録する。このインデックスについての詳細は後述する。
【００３２】
１５は伝播情報記憶部であり、コマンド伝播の情報（パケットＩＤと伝播先ノードとのペア）を記憶する。この伝播情報は、Ｌｏｏｋｕｐコマンドの伝播時に各ノードに記憶していく。ｈｉｔリプライの伝播時に制御部１３がこの伝播情報を参照することで、当該ｈｉｔリプライをｌｏｏｋｕｐコマンドの伝播時と逆向きに伝播し、コマンド発行元ノードまで届けることが可能となる。
【００３３】
１６は履歴記憶部であり、ｌｏｏｋｕｐコマンドやｈｉｔリプライなどのコマンド伝播、他のノードに対する過去の接続状況やアクセス状況などに関する履歴を記憶する。具体的には、自ノードにおける過去の検索ヒット数（ｈｉｔリプライの発行数）、ｈｉｔリプライ以外のコマンドの発行数、他のノードとのネットワーク的近さ（ｌｏｏｋｕｐコマンドを発行してからｈｉｔリプライが返ってくるまでの時間等）、過去にどのノードに接続していたか、あるいは接続できなかったかを表す接続実績、他のノードに対するアクセス数等の情報を記憶する。
【００３４】
１７はキャッシュ記憶部であり、検索ヒット応答の伝播時に、検索ヒットノードが備えるリモートリソースの識別情報とその在り処をキャッシュ記憶する。これは、例えば他のノードから受け取ったｌｏｏｋｕｐコマンドおよびそれに対するｈｉｔリプライをキャッシュ記憶することによって行う。
【００３５】
この場合、制御部１３は、他のノードから接続部１１を介してコマンドを受信したときに、それと同じコマンドがキャッシュ記憶部１７に記憶されているかどうかを調べる。そして、同じコマンドが記憶されている場合は、受信したコマンドを消滅させる（他のノードに伝播しないようにする）。
【００３６】
例えば、他のノードから送られてきたコマンドがｌｏｏｋｕｐコマンドであれば、制御部１３は、それと同じコマンド（同じリソースを検索するするｌｏｏｋｕｐコマンド）およびそれに対応するｈｉｔリプライがキャッシュ記憶部１７に記憶されているかどうかを調べる。同じｌｏｏｋｕｐコマンドとｈｉｔリプライとのペアがキャッシュ記憶部１７に記憶されている場合は、受信したｌｏｏｋｕｐコマンドを消滅させて、それに対応するｈｉｔリプライをキャッシュ記憶部１７から読み出して返す。
【００３７】
一方、受信したｌｏｏｋｕｐコマンドと同じコマンドがキャッシュ記憶部１７に記憶されていない場合、あるいは、同じｌｏｏｋｕｐコマンドはあってもそれに対応するｈｉｔリプライが記憶されていない場合は、インデックス記憶部１４を参照し、要求されているリソース（自身が備えるローカルリソースおよび他のノードからコピーしたリモートリソースの双方を含む）を自身が持っているかどうかを調べ、持っている場合にはｈｉｔリプライを発行して他のノードに返す。当該リソースを持っていない場合は、近接ノードに対して更にｌｏｏｋｕｐコマンドを伝播する。
【００３８】
このように、本実施形態では、各ノードにキャッシュ記憶部１７を設けて過去のｌｏｏｋｕｐコマンドおよびｈｉｔリプライのペアを記憶し、必要な情報がキャッシュ記憶部１７に記憶されている場合にはｌｏｏｋｕｐコマンドを他のノードに伝播せず、直ちにｈｉｔリプライを返すようにしている。
【００３９】
これにより、実際には所望のリソースがコマンド発行元のユーザノードから遠くに存在する場合でも、ユーザノードに近いノードからｈｉｔリプライを返し、それ以降はｌｏｏｋｕｐコマンドを伝播しなくても済む。ユーザノード自身が必要な情報をキャッシュ記憶している場合は、ｌｏｏｋｕｐコマンドの発行すらしなくても済むようになる。したがって、ＴＴＬ以外でもコマンドの増殖を防ぐことが可能となる。同時に、ｌｏｏｋｕｐコマンドを発行してからｈｉｔリプライが返ってくるまでのネットワークとしての応答性を上げることもできる。
【００４０】
なお、この図２に示した機能構成は、実際にはコンピュータのＣＰＵあるいはＭＰＵ、ＲＡＭ、ＲＯＭなどで構成され、ＲＡＭやＲＯＭに記憶されたプログラムが動作することによって実現できる。したがって、コンピュータが上記の機能を果たすように動作させるプログラムを例えばＣＤ−ＲＯＭのような記録媒体に記録し、コンピュータに読み込ませることによって実現できるものである。
【００４１】
上記プログラムを記録する記録媒体としては、ＣＤ−ＲＯＭ以外に、フレキシブルディスク、ハードディスク、磁気テープ、光ディスク、光磁気ディスク、ＤＶＤ、不揮発性メモリカード等を用いることができる。また、上記プログラムをインターネット等のネットワークを介してコンピュータにダウンロードすることによっても実現できる。
【００４２】
また、コンピュータが供給されたプログラムを実行することにより上述の実施形態の機能が実現されるだけでなく、そのプログラムがコンピュータにおいて稼働しているＯＳ（オペレーティングシステム）あるいは他のアプリケーションソフト等と共同して上述の実施形態の機能が実現される場合や、供給されたプログラムの処理の全てあるいは一部がコンピュータの機能拡張ボードや機能拡張ユニットにより行われて上述の実施形態の機能が実現される場合も、かかるプログラムは本実施形態に含まれる。
【００４３】
次に、上記図１のように構成されたネットワークにおいて所望のリソースを検索する際の手順を説明する。まず、リソース１１０の取得を希望しているユーザノード１００は、これに接続している近接ノード１０１，１０２にｌｏｏｋｕｐコマンドを発行する。このとき発行されるｌｏｏｋｕｐコマンドのパケットは、要求するリソース１１０のＩＤを含んでいる。
【００４４】
ｌｏｏｋｕｐコマンド受け取ったノード１０１，１０２は、それと同じコマンドおよび対応するｈｉｔリプライが自身のキャッシュ記憶部１７に記憶されているかどうかを調べる。同じｌｏｏｋｕｐコマンドとｈｉｔリプライとのペアが記憶されている場合は、当該ｈｉｔリプライをキャッシュ記憶部１７から読み出し、ユーザノード１００に返す。一方、受信したｌｏｏｋｕｐコマンドと同じコマンドあるいはそれに対応するｈｉｔリプライがキャッシュ記憶部１７に記憶されていない場合は、インデックス記憶部１４内のインデックス情報をリソースＩＤで検索する。
【００４５】
ここで、検索にヒットしない場合は、ユーザノード１００から受信したｌｏｏｋｕｐコマンドを近接ノード１０３〜１０６に伝播する。このｌｏｏｋｕｐコマンドを受け取ったノード１０３〜１０６においても同様に、キャッシュ記憶部１７を検索して同じｌｏｏｋｕｐコマンドやそれに対応するｈｉｔリプライが記憶されているかどうかを調べるとともに、インデックス記憶部１４を検索して、要求されているリソース１１０を自身が持っているかどうかを調べる。
【００４６】
このようにコマンド伝播を繰り返していく中で、ノード１０３においてリソース１１０の検索にヒットしたとする。この場合ノード１０３は、ｈｉｔリプライを発行する。発行されたｈｉｔリプライは、各ノードの伝播情報記憶部１５に記憶されている伝播情報に基づいて、ｌｏｏｋｕｐコマンドを伝播した各ノードにより逆向きに伝播され、コマンド発行元のユーザノード１００まで届けられる。このようなｌｏｏｋｕｐコマンドとｈｉｔリプライの伝播を行う際に、それらのコマンドがキャッシュ記憶部１７にキャッシュ記憶される。
【００４７】
なお、上記の例において、ノード１０４がノード１０１からｌｏｏｋｕｐコマンドを受信した際には、キャッシュ記憶部１７およびインデックス記憶部１４を検索した結果に応じて、近接ノード１０５，１０７に対してｌｏｏｋｕｐコマンドが更に伝播されることになる。このとき、ノード１０５は、同じｌｏｏｋｕｐコマンドをノード１０２から既に受信して近接ノード１０４，１０７へと転送している。
【００４８】
このときノード１０５内の制御部１３は、伝播情報記憶部１５を参照して、一度転送したコマンドについては、その後別のノードから受け取っても転送しないように制御する。他のノード内の制御部１３も同様の制御を行う。これにより、ネットワーク上に無駄なコマンドが飛び交うのを防ぎ、コマンド伝播の爆発を防止することができる。
【００４９】
図３は、ノード間でやり取りされるパケットデータの構造を示す図である。図３（ａ）に示すように、本実施形態のパケットデータは、ＴＣＰヘッダとＴＣＰデータとを含んで構成されている。このうちＴＣＰデータは、図３（ｂ）に示すように、Ｐ２Ｐアーキテクチャに特有のヘッダと、各種リソースに相当するアプリケーションデータと、当該アプリケーションデータの属性や後述する版情報（リビジョン情報）とを含んでいる。
【００５０】
また、図３（ｃ）に示すように、Ｐ２Ｐヘッダは、ＧＵＩＤ（Ｇｌｏｂａｌ Ｕｎｉｑｕｅ Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ）等によるメッセージＩＤ、ｌｏｏｋｕｐコマンドやｈｉｔリプライ等のコマンド、コマンドの寿命設定時間を表すＴＴＬ情報などを含んで構成されている。伝播情報記憶部１５、履歴記憶部１６、キャッシュ記憶部１７には、メッセージＩＤやコマンドなどが記憶される。
【００５１】
このように本実施形態でもＴＴＬを用いることにより、あるｌｏｏｋｕｐコマンドが発行されたにも関わらず所望のリソースが発見されない場合に、そのコマンドが無限に伝播されていくのを防止し、ネットワーク上に無駄なコマンドが飛び交うのを防ぐことができる。ＴＴＬによってｌｏｏｋｕｐコマンドが途中で消滅した場合、ユーザにはタイムオーバー通知が成される。ユーザはその後で希望する場合には、同じｌｏｏｋｕｐコマンドを発行してリソースの検索を再度試みる。
【００５２】
通常、ネットワークのトポロジは固定的ではない。すなわち、ノードは随時、プログラムの起動によってネットワーク上に新たに参加する。逆に、プログラムの終了によって、ノードは突然ネットワーク上から離脱する。そのため、ＴＴＬによって一度タイムオーバー通知が成された場合でも、再度ｌｏｏｋｕｐコマンドを発行すると、その時点でノードの接続状況が前回と変わっており、所望のリソースを発見できることもある。
【００５３】
ところが、タイムオーバー通知の直後にｌｏｏｋｕｐコマンドを発行しても、ノードの接続状況が変わっていないことが多い。この場合には、何度ｌｏｏｋｕｐコマンドを発行しても、その都度タイムオーバーとなって所望のリソースを発見できない。また、接続状況が変わっていても、相変わらず所望のリソースが遠くにあるため、ＴＴＬによるコマンド寿命の設定によって依然としてリソースを発見できないこともある。
【００５４】
そこで、本実施形態では、上述したノードの参加および離脱とは別に、参加済みのノードの接続先を自律的に変更するように制御する。このとき、制御部１３は、履歴記憶部１６を参照して、経路が最短となるようにノード間の接続先を動的に変更する。
【００５５】
例えば、過去の検索ヒット数（ｈｉｔリプライの発行数）が多いノードは、多数のユーザが所望するリソースを備えている重要なノードであるので、これに対する接続を積極的に試みる。ｌｏｏｋｕｐコマンドの発行数が多いノードも重要なノードなので、これに対する接続を試みる。特に、２つのノード間でリソースへのアクセスが多い場合は、その２つのノード間でより速くｈｉｔリプライを返す方が良いので、そのノード間は接続するようにする。
【００５６】
また、ネットワーク的な距離が近いノード間は接続するが、ネットワーク的な距離が遠いノード間は接続を切るようにする。ネットワーク的な距離は、ｌｏｏｋｕｐコマンドを発行してからｈｉｔリプライが返ってくるまでの時間を実績としてとるようにしても良いし、特別な距離測定用コマンドを定期的に近接ノードに送ることによって距離を測るようにしても良い。また、例えばファイアウォールの存在等によって過去に接続できなかったノード間には接続を形成しないようにする。
【００５７】
このように、履歴記憶部１６に記憶されている種々の履歴情報に基づいてノード間の接続を能動的に変えることにより、ＴＴＬによるタイムオーバーが何度も続く事態を防ぐことができる。また、ＴＴＬによるコマンド寿命の問題とは関係なく、ネットワークとしての応答性を上げることができるとともに、コマンドの増殖も有効に抑制することができる。
【００５８】
すなわち、本実施形態によれば、重要なノードがトポロジの中心方向に徐々に押し込まれていき、そこに多くのノードが接続されるようになる。これにより、ノード間の接続を最適化することができる。上述したキャッシュ記憶部１７を用いた場合、過去と同じリソースの検索であればキャッシュ情報にヒットして直ちにｈｉｔリプライが返されるが、異なるリソースを検索する場合にはキャッシュ情報にヒットしない。しかし、この場合でも、ノード間の接続が最適化されている結果、所望のリソースを有するノードとのネットワーク的な距離は近い可能性が高く、多くのコマンド伝播をしなくてもｈｉｔリプライを受けることができる。
【００５９】
次に、インデックス記憶部１４に記憶されるインデックスの詳細について説明する。本実施形態のインデックスは、リソースを一意に識別するリソースＩＤ（識別情報）と、リソースの版を識別するリビジョンＩＤ（版情報）と、リソースの所有者であるユーザを一意に識別するユーザＩＤ（ユーザ情報）とを含んでいる。
【００６０】
このように、リソースＩＤの他にユーザＩＤを持つことにより、他のノードからリソースをコピーした場合でも、そのリソースが誰の所有物であるかを特定することができる。これにより、特定ユーザのリソースを他のノードにもコピーして置いておくことが可能となる。
【００６１】
制御部１３は、特定ユーザのリソースを検索するためのｌｏｏｋｕｐコマンドが与えられたときには、そのｌｏｏｋｕｐコマンド中に含まれているリソースＩＤとユーザＩＤとをもとにインデックス記憶部１４を検索し、この検索にヒットした場合にｈｉｔリプライを返すように制御する。
【００６２】
このようにすることによって、リソースのオリジナルが存在する特定ユーザのノードから遠くにあるノードにおいても、ＴＴＬの制御によってｌｏｏｋｕｐコマンドの消滅を受けることなく、当該特定ユーザのリソースのコピーを他のノードから取得することができるようになる。つまり、Ｐ２Ｐネットワークシステムにおいても特定ユーザの知識ＤＢを共有することが可能となる。
【００６３】
ただし、複数のノード間で特定ユーザのリソースを共有しようとする場合、複数のノードに存在する同じリソースは常に同じ内容となるようにしておかなければならない。これは、特定ユーザのリソースに限らず、内容が更新され得る動的リソースであれば同じことである。そのために制御部１３は、あるノードにおいて動的リソースが更新されたときには、その動的リソースを他のノードにも転送することにより、複数のノードに存在する同じ動的リソースが全て同じ内容となるように同期処理を行う。
【００６４】
この同期処理において転送するデータ量を削減するために、本実施形態ではリソースの更新をリビジョンで管理するようにしている。すなわち、本実施形態のリソースは、図４（ａ）に示すように、内容が更新される都度、更新前後の差分情報をストレージに記憶することによって管理する。更新されたリソースの版がどの状態であるかを示すのがリビジョンＩＤであり、図４（ｂ）のようにリソースＩＤとリビジョンＩＤとによって特定の状態にアクセスすることができる。
【００６５】
各ノードの制御部１３は、一定時間毎に最新リビジョンを検索するｌｏｏｋｕｐコマンドを発行して、他のノードから最新の差分情報を取得することにより、同期処理を行う。このとき制御部１３は、受信したｌｏｏｋｕｐコマンド中に含まれているリソースＩＤとリビジョンＩＤとをもとにインデックス記憶部１４を検索し、この検索にヒットした場合にｈｉｔリプライを返すように制御する。
【００６６】
このように、本実施形態によれば、動的リソースの同期処理の際には差分情報のみを転送するようにしたので、転送データ量を削減し、通信トラフィックを減少させることができる。なお、ここでは一定時間毎にｌｏｏｋｕｐコマンドを発行する例について説明しているが、リビジョン間をマージするタイミングはこれに限定されるものではない。
【００６７】
以上に説明した本実施形態のプロトコルは、様々なネットワークシステムに適用することが可能である。例えば、Ｐ２Ｐプロトコルをベースにしたグループウェアに適用することができる。このグループウェアの中では、例えば、個人またはグループのスケジュールやタスクの管理、文書等のファイル管理、プロジェクトの進捗管理などを行うことができる。
【００６８】
以上詳しく説明したように、本実施形態においては、
・コマンドのパケットにＴＴＬを設定する。
・一度転送したコマンドは、別のノードから受け取っても転送しない。
・リモートリソースの在り処を各ノードがキャッシュ記憶する。
といった仕組みを持つことにより、コマンドの増殖を防止し、通信トラフィックの増大を抑止することができる。また、ネットワークとしての応答性を向上させることもできる。
【００６９】
また、本実施形態では、コマンド伝播や接続、アクセスなどに関する過去の実績を履歴として記憶しておき、その履歴に応じて複数ノード間の接続を可変制御するようにしたので、ノード間の接続を最適化して、ネットワークとしての応答性を更に向上させることができる。
【００７０】
また、本実施形態では、リソースをユーザＩＤによって管理するようにしたので、特定ユーザのリソースを複数のノードにコピーして管理することが可能となる。これにより、特定ユーザのリソースであってもｌｏｏｋｕｐコマンドによるリソースの発見および交換を行うことができ、Ｐ２Ｐネットワーク技術において特定ユーザの知識ＤＢを共有することができるようになる。
【００７１】
また、本実施形態では、動的リソースの同期処理を行う際に、更新前後の差分情報のみを転送するようにしたので、転送データ量を削減し、通信トラフィックを減少させることができる。
【００７２】
なお、上記実施形態においては、キャッシュ記憶部１７には、他のノードから受け取ったｌｏｏｋｕｐコマンドおよびｈｉｔリプライそのものを記憶するようにしているが、どのノードにリソースが存在するのかを表した情報を記憶するようにしても良い。例えば、ｈｉｔリプライを受信したときに、そのｈｉｔリプライを発行した他のノードおよびそのノードが備えるリモートリソースのＩＤを記憶するようにする。
【００７３】
この場合、制御部１３は、他のノードからｌｏｏｋｕｐコマンドを受信した際に、そのｌｏｏｋｕｐコマンド中に含まれているリソースＩＤがキャッシュ記憶部１７に記憶されているかどうかを調べる。そして、該当するリソースＩＤが記憶されている場合には、そのリソースを実際に持っているノードの情報をキャッシュ記憶部１７から読み出し、当該ノードを知らせるｈｉｔリプライを発行して、ｌｏｏｋｕｐコマンド送信元のノードに返すようにする。
【００７４】
その他、上記実施形態は、本発明を実施するにあたっての具体化の一例を示したものに過ぎず、これによって本発明の技術的範囲が限定的に解釈されてはならないものである。すなわち、本発明はその精神、またはその主要な特徴から逸脱することなく、様々な形で実施することができる。
【００７５】
【発明の効果】
本発明は上述したように、リソースの在り処を表す情報を各ノードがキャッシュ記憶し、キャッシュ記憶された情報に基づいて検索がヒットした場合にはリソース検索コマンドを他のノードに伝播せず、直ちに検索ヒット応答を返すようにしている。これにより、ＴＴＬの手法以外でもコマンドの増殖を有効に防ぐことができ、通信トラフィックの増大を抑止することができる。また、リソース検索コマンドを発行してから検索ヒット応答が返ってくるまでのネットワークとしての応答性を上げることもできる。
【００７６】
本発明の他の特徴によれば、各ノードにおいてリソースに関するユーザ情報を記憶し、そのユーザ情報に基づいて検索がヒットした場合に検索ヒット応答を返すようにしている。これにより、特定ユーザのリソースを複数のノードにコピーして管理することが可能となり、Ｐ２Ｐネットワーク技術において特定ユーザの知識ＤＢを共有することができるようになる。
【００７７】
また、本発明の他の特徴によれば、リソースが更新されたときには更新前後の差分情報を記憶して管理するようにしている。これにより、動的リソースの同期処理を行う際に、更新前後の差分情報のみを転送するようにすることができ、転送データ量を削減して通信トラフィックの混雑を抑制することができる。
【００７８】
また、本発明の他の特徴によれば、コマンド伝播等に関する履歴を記憶しておき、その履歴情報に応じて複数ノード間の接続を可変制御するようにしたので、ノード間の接続を最適化することができる。これにより、コマンドの増殖を防止して通信トラフィックの混雑を抑止することができるとともに、ネットワークとしての応答性を更に向上させることができる。
【図面の簡単な説明】
【図１】本実施形態のネットワークシステムが適用されるネットワークの概略構成例を示す図である。
【図２】本実施形態のノードが備える機能構成を示すブロック図である。
【図３】本実施形態のノード間でやり取りされるパケットデータの構造を示す図である。
【図４】本実施形態によるリソースの構成を示す図である。
【図５】Ｐ２Ｐアーキテクチャを利用して所望のリソースを検索および取得する際の手順を示す図である。
【符号の説明】
１１ 接続部
１２ アクセス部
１３ 制御部
１４ インデックス記憶部
１５ 伝播情報記憶部
１６ 履歴記憶部
１７ キャッシュ記憶部
１００ ユーザノード（ｌｏｏｋｕｐコマンド発行元ノード）
１０１〜１０８ ノード
１１０ リソース
【発明の属する技術分野】
本発明はネットワークシステムおよびプログラムに関し、特に、サーバを介さずにクライアント同士で直接データの交換を行うシステムに用いて好適なものである。
【０００２】
【従来の技術】
近年、インターネットの浸透とインターネットユーザ数の爆発的増加という社会的背景、パーソナルコンピュータ（パソコン）の高性能化とネットワークの高速化という技術的背景をもとに、ピアツーピア（Ｐ２Ｐ）と呼ばれるネットワーク技術が注目を集めている。
【０００３】
従来のネットワークシステムは、少数のサーバと多数のクライアントとをネットワークを介して接続したものが殆どであり、クライアントで生成されたリソースはサーバに集められて管理されていた。ところが、爆発的ユーザ数増加の中、ユーザの生み出したリソースをサーバに集めるコストは無視できないものになっている。
【０００４】
すなわち、従来のＷｅｂアーキテクチャにおいてサーバにリソースを集める際に、インターネット上に散らばっているリソースを発見するメカニズムには、ディレクトリサービスとサーチエンジンの２つのタイプが存在する。前者は人海戦術と呼ぶべきアプローチで、人手の作業によってリソースを集めるものである。後者はエージェントロボットがインターネットを巡回することによってリソースを集めてまわるものであり、何れのタイプも言わば力任せのアプローチである。
【０００５】
また、サーバに集められたリソースは、アクセスの集中を生む。この結果、クライアントとして用いられる高性能なパソコンは殆ど遊休状態となり、高速ネットワークもサーバ周辺だけがいびつに混雑する結果となっている。
【０００６】
これに対し、Ｐ２Ｐによるネットワーク技術は、ユーザに近い部分でサーバを介さずに、クライアント同士がダイレクトに情報のやり取りをするアーキテクチャである。つまり、多数のクライアントで生成されたリソースはそれぞれのクライアント自身で管理されるため、多数のリソースをサーバに集める必要もないし、リソース取得のためにアクセスの集中が生じることも殆どない。また、高性能なパソコンが持つ遊休資源を有効に使うことも可能となる。
【０００７】
図５を参照して、Ｐ２Ｐアーキテクチャを利用して所望のリソースを検索および取得する際の手順を説明する。まず、図５（ａ）のように、リソース１１０の取得を希望しているユーザのノード１００は、どこにリソース１１０があるかを探し出すためのｌｏｏｋｕｐコマンドを近接ノード（接続しているノード）１０１，１０２に発行する。
【０００８】
ｌｏｏｋｕｐコマンド受け取ったノード１０１，１０２は、要求されているリソース１１０を自身が持っているかどうかを調べる。該当するリソース１１０が見つからない場合は、図５（ｂ）のように、ｌｏｏｋｕｐコマンドを近接ノード（ｌｏｏｋｕｐコマンドの送信元以外で接続しているノード）１０３〜１０６に転送する。このｌｏｏｋｕｐコマンドを受け取ったノード１０３〜１０６も、要求されているリソース１１０を自身が持っているかどうかを調べる。
【０００９】
このようにコマンド伝播とリソース１１０の検索を繰り返していく中で、ノード１０３では、リソース１１０の検索にヒットする。検索にヒットした場合は、図５（ｃ）に示すように、ｌｏｏｋｕｐコマンドの送信元であるノード１０１にｈｉｔリプライを返す。ｈｉｔリプライを受け取ったノード１０１は、ｌｏｏｋｕｐコマンドの送信元であるユーザノード１００にｈｉｔリプライを転送する。このようにｈｉｔリプライは、ｌｏｏｋｕｐコマンドを伝播した各ノードにより逆向きに伝播され、コマンド発行元のユーザノード１００まで届けられる。
【００１０】
ｈｉｔリプライは、リソース１１０のアクセスインタフェースの名前と検索ヒットノード１０３の情報とを含むパケットである。以上の手順により、最初にｌｏｏｋｕｐコマンドを発行したユーザノード１００では、所望のリソース１１０がノード１０３に存在することを発見できる。ｈｉｔリプライを受け取ったユーザノード１００は次に、図５（ｄ）のようにノード１０３にダイレクトにアクセスし、リソース１１０を取得する。
【００１１】
【発明が解決しようとする課題】
しかしながら、上記従来のＰ２Ｐネットワーク技術では、リソースを取得する前提として、所望のリソースがどこにあるかを発見するためにｌｏｏｋｕｐコマンドを多数のノードに伝播していかなければならならない。そのため、ネットワーク上に非常に多くのコマンド伝播が生じ、それだけ通信トラフィックが増大するという問題があった。
【００１２】
個々のコマンドについては、そのパケットにＴＴＬ（Ｔｉｍｅ Ｔｏ Ｌｉｖｅ）を設定してコマンドの増殖を防止する工夫はなされている。ＴＴＬとは、コマンド伝播回数を設定しておき、ノードがｌｏｏｋｕｐコマンドを受信する毎にこれを１つずつ減算していき、ゼロになったときにそのコマンドを消滅するようにしたものである。このＴＴＬを用いれば、あるｌｏｏｋｕｐコマンドが発行されたにも関わらず所望のリソースが発見されない場合に、そのコマンドが無限に伝播されていくのを防止し、ネットワーク上に無駄なコマンドが飛び交うのを防ぐことができる。
【００１３】
しかしながら、このようなＴＴＬを用いたとしても、所望のリソースが発見されない場合に限ってコマンドの増殖を防ぐことができるに過ぎず、所望のリソースが存在する場合におけるコマンド増殖は防ぐことができない。すなわち、ｌｏｏｋｕｐコマンド発行元ノードの近くにリソースが存在すれば、コマンドの増殖はそれほど多くならない。しかし、コマンド発行元ノードから遠く離れたノードにしかリソースがない場合は、そのリソースを発見するまでに多数のノードを経由することになり、コマンドの増殖を生む。
【００１４】
このように、コマンド発行元ノードから遠く離れたノードにしかリソースが存在しない場合は、コマンドの増殖によってネットワーク上の通信トラフィックが増大するという問題を生じる。また、あるノードがｌｏｏｋｕｐコマンドを発行してからｈｉｔリプライを受信するまでの時間が長くなり、ネットワークとしての応答性が悪くなるという問題も生じる。
【００１５】
また、従来のＰ２Ｐネットワーク技術では、交換可能なリソースは所有者が不特定のファイルだけであり、特定の所有者のリソースを共有することはできなかった。例えば、あるユーザのスケジュール情報等に代表される知識データベースを他のノードでも共有することはできなかった。これは、特定ユーザのリソースはそのユーザが使用するノードにのみ存在し、これをコピーして管理する仕組みがないためである。
【００１６】
すなわち、所有者が不特定のファイルであれば、これをコピーして複数のノードに置いておくことができるため、ｌｏｏｋｕｐコマンドによるリソースの発見および交換が比較的容易に行われる。これに対して、特定ユーザのリソースは特定のノードにのみ存在するため、そこから遠くにあるノードからでは、ＴＴＬの制御によってｌｏｏｋｕｐコマンドが途中で消滅してしまい、リソースを発見できないことが多くなる。
【００１７】
運良くリソースを発見できても、発見するまでにコマンドの増殖を招き、通信トラフィックが混雑する原因となってしまう。また、ｌｏｏｋｕｐコマンドを発行してからｈｉｔリプライが返ってくるまでの応答性も極めて悪くなる。以上のような理由から、従来はＰ２Ｐネットワークシステムにおいて特定ユーザの知識ＤＢを共有することは実質的にできなかった。
【００１８】
また、生存期間が比較的短く、更新やコピー、移動などが頻繁に行われるリソース（以下、動的リソースと呼ぶ）を複数のノード間で共有しようとする場合、複数のノードに存在する同じリソースは常に同じ内容となるようにしておかなければならない。複数のノードに存在する動的リソースの内容がまちまちであると、どのノードがｌｏｏｋｕｐコマンドにより発見されるかによって、取得するリソースが古い内容であったり新しい内容であったりして問題となるからである。
【００１９】
そのため、ネットワーク上では、複数のノードに存在する同じ動的リソースが全て最新版となるように、あるノードにおいて動的リソースが更新されたときには、その更新された動的リソースは他のノードにも転送されるようになっている。これにより、ネットワーク上には多量のデータが定常的に流れており、これも通信トラフィックを混雑させる要因になっているという問題があった。
【００２０】
本発明は、このような問題を解決するために成されたものであり、コマンドの増殖を効率よく防止し、通信トラフィックを減少させることができるようにすることを目的とする。
また、本発明は、ｌｏｏｋｕｐコマンドを発行してからｈｉｔリプライが返ってくるまでの応答性を向上させることができるようにすることも目的とする。
また、本発明は、Ｐ２Ｐネットワーク技術において特定ユーザの知識ＤＢを共有することができるようにすることも目的とする。
また、本発明は、動的リソースを最新版に保つために行われるデータ転送の量を削減し、通信トラフィックを減少させることができるようにすることも目的としている。
【００２１】
【課題を解決するための手段】
本発明のネットワークシステムは、各ノードが、検索ヒット応答の伝播時に、検索ヒットノードが備えるリモートリソースの識別情報とその在り処をキャッシュ記憶するキャッシュ記憶手段と、リソース検索コマンドが与えられたときに上記キャッシュ記憶手段を参照してリソースの検索を行い、当該リソースの検索にヒットした場合に検索ヒット応答を返すように制御する制御手段とを備えたことを特徴とする。
【００２２】
本発明の他の態様では、各ノードが、リソースの識別情報およびそのリソースに関するユーザ情報を記憶する情報記憶手段と、リソース検索コマンドが与えられたときに上記情報記憶手段を参照してリソースの検索を行い、要求されたユーザリソースの検索にヒットした場合に検索ヒット応答を返すように制御する制御手段とを備えたことを特徴とする。
【００２３】
本発明の他の態様では、各ノードが、リソースを、当該リソースが更新されたときには更新前後の差分情報を記憶して管理するリソース管理手段と、リソースの識別情報および差分情報に関する版情報を記憶する情報記憶手段と、リソース検索コマンドが与えられたときに上記情報記憶手段を参照してリソースの検索を行い、当該リソースの検索にヒットした場合に検索ヒット応答を返すように制御する制御手段とを備えたことを特徴とする。
【００２４】
本発明の他の態様では、各ノードが、最新の差分情報を検索するリソース検索コマンドを所定タイミング毎に発行して上記最新の差分情報を取得する同期処理手段を備えたことを特徴とする。
【００２５】
本発明の他の態様では、各ノードが、接続、アクセス、コマンド伝播の少なくとも一に関する履歴を記憶する履歴記憶手段と、上記履歴記憶手段に記憶されている履歴に基づいて、複数ノード間の接続を制御する接続制御手段とを備えたことを特徴とする。
【００２６】
【発明の実施の形態】
以下、本発明の一実施形態を図面に基づいて説明する。
図１は、本実施形態のネットワークシステムが適用されるネットワークの概略構成例を示す図である。本実施形態のネットワークは、ノードの集合１００〜１０８で定義される。ノードとは、本実施形態のプロトコルを実装したプログラムのプロセスのことを言う。したがって、例えば１つのパソコンの中にも、起動しているプログラムが複数あれば、複数のノードが存在することになる。
【００２７】
ノード同士は、複数のセッションを互いに張った状態でトポロジを形成する。この常態的なセッションを「接続」と呼ぶことにする。「接続」が常態的なトポロジ形成をなして、この接続セッション上を基本的なプロトコル（リソース検索コマンドに相当するｌｏｏｋｕｐコマンドや、検索ヒット応答に相当するｈｉｔリプライ等）が流れる。
【００２８】
これに対して、ユーザノード１００（ｌｏｏｋｕｐコマンドの発行元ノード）からリソース１１０の存在するノード１０３（ｈｉｔリプライの発行元ノード）に対して張るセッションを「アクセス」と呼ぶことにする。「アクセス」は、リソース発見後にコマンド発行元ノードと検索ヒットノードとの間に一時的に張られるセッションで、この上をアクセスインタフェースに応じたプロトコルが流れる。
【００２９】
上記した「接続」および「アクセス」のトポロジ形成の状態は中央で管理されず、個々のノード１００〜１０８が自律的に形成する。
【００３０】
図２は、各ノード１００〜１０８が備える機能構成を示すブロック図である。図２において、１１は接続部であり、他のノードと接続してｌｏｏｋｕｐコマンドやｈｉｔリプライ等のやり取りを行う。１２はアクセス部であり、他のノードとアクセスしてリソースのやり取りを行う。１３は制御部であり、ノード内の全体制御を行う。
【００３１】
１４はインデックス記憶部であり、自身が元々備えるローカルリソースのインデックスを記憶する。制御部１３は、起動時にローカルストレージにあるリソースのインデックスをインデックス記憶部１４に登録する。リモートにある他のノードからリソースをコピーした場合も、そのインデックスをインデックス記憶部１４に登録する。このインデックスについての詳細は後述する。
【００３２】
１５は伝播情報記憶部であり、コマンド伝播の情報（パケットＩＤと伝播先ノードとのペア）を記憶する。この伝播情報は、Ｌｏｏｋｕｐコマンドの伝播時に各ノードに記憶していく。ｈｉｔリプライの伝播時に制御部１３がこの伝播情報を参照することで、当該ｈｉｔリプライをｌｏｏｋｕｐコマンドの伝播時と逆向きに伝播し、コマンド発行元ノードまで届けることが可能となる。
【００３３】
１６は履歴記憶部であり、ｌｏｏｋｕｐコマンドやｈｉｔリプライなどのコマンド伝播、他のノードに対する過去の接続状況やアクセス状況などに関する履歴を記憶する。具体的には、自ノードにおける過去の検索ヒット数（ｈｉｔリプライの発行数）、ｈｉｔリプライ以外のコマンドの発行数、他のノードとのネットワーク的近さ（ｌｏｏｋｕｐコマンドを発行してからｈｉｔリプライが返ってくるまでの時間等）、過去にどのノードに接続していたか、あるいは接続できなかったかを表す接続実績、他のノードに対するアクセス数等の情報を記憶する。
【００３４】
１７はキャッシュ記憶部であり、検索ヒット応答の伝播時に、検索ヒットノードが備えるリモートリソースの識別情報とその在り処をキャッシュ記憶する。これは、例えば他のノードから受け取ったｌｏｏｋｕｐコマンドおよびそれに対するｈｉｔリプライをキャッシュ記憶することによって行う。
【００３５】
この場合、制御部１３は、他のノードから接続部１１を介してコマンドを受信したときに、それと同じコマンドがキャッシュ記憶部１７に記憶されているかどうかを調べる。そして、同じコマンドが記憶されている場合は、受信したコマンドを消滅させる（他のノードに伝播しないようにする）。
【００３６】
例えば、他のノードから送られてきたコマンドがｌｏｏｋｕｐコマンドであれば、制御部１３は、それと同じコマンド（同じリソースを検索するするｌｏｏｋｕｐコマンド）およびそれに対応するｈｉｔリプライがキャッシュ記憶部１７に記憶されているかどうかを調べる。同じｌｏｏｋｕｐコマンドとｈｉｔリプライとのペアがキャッシュ記憶部１７に記憶されている場合は、受信したｌｏｏｋｕｐコマンドを消滅させて、それに対応するｈｉｔリプライをキャッシュ記憶部１７から読み出して返す。
【００３７】
一方、受信したｌｏｏｋｕｐコマンドと同じコマンドがキャッシュ記憶部１７に記憶されていない場合、あるいは、同じｌｏｏｋｕｐコマンドはあってもそれに対応するｈｉｔリプライが記憶されていない場合は、インデックス記憶部１４を参照し、要求されているリソース（自身が備えるローカルリソースおよび他のノードからコピーしたリモートリソースの双方を含む）を自身が持っているかどうかを調べ、持っている場合にはｈｉｔリプライを発行して他のノードに返す。当該リソースを持っていない場合は、近接ノードに対して更にｌｏｏｋｕｐコマンドを伝播する。
【００３８】
このように、本実施形態では、各ノードにキャッシュ記憶部１７を設けて過去のｌｏｏｋｕｐコマンドおよびｈｉｔリプライのペアを記憶し、必要な情報がキャッシュ記憶部１７に記憶されている場合にはｌｏｏｋｕｐコマンドを他のノードに伝播せず、直ちにｈｉｔリプライを返すようにしている。
【００３９】
これにより、実際には所望のリソースがコマンド発行元のユーザノードから遠くに存在する場合でも、ユーザノードに近いノードからｈｉｔリプライを返し、それ以降はｌｏｏｋｕｐコマンドを伝播しなくても済む。ユーザノード自身が必要な情報をキャッシュ記憶している場合は、ｌｏｏｋｕｐコマンドの発行すらしなくても済むようになる。したがって、ＴＴＬ以外でもコマンドの増殖を防ぐことが可能となる。同時に、ｌｏｏｋｕｐコマンドを発行してからｈｉｔリプライが返ってくるまでのネットワークとしての応答性を上げることもできる。
【００４０】
なお、この図２に示した機能構成は、実際にはコンピュータのＣＰＵあるいはＭＰＵ、ＲＡＭ、ＲＯＭなどで構成され、ＲＡＭやＲＯＭに記憶されたプログラムが動作することによって実現できる。したがって、コンピュータが上記の機能を果たすように動作させるプログラムを例えばＣＤ−ＲＯＭのような記録媒体に記録し、コンピュータに読み込ませることによって実現できるものである。
【００４１】
上記プログラムを記録する記録媒体としては、ＣＤ−ＲＯＭ以外に、フレキシブルディスク、ハードディスク、磁気テープ、光ディスク、光磁気ディスク、ＤＶＤ、不揮発性メモリカード等を用いることができる。また、上記プログラムをインターネット等のネットワークを介してコンピュータにダウンロードすることによっても実現できる。
【００４２】
また、コンピュータが供給されたプログラムを実行することにより上述の実施形態の機能が実現されるだけでなく、そのプログラムがコンピュータにおいて稼働しているＯＳ（オペレーティングシステム）あるいは他のアプリケーションソフト等と共同して上述の実施形態の機能が実現される場合や、供給されたプログラムの処理の全てあるいは一部がコンピュータの機能拡張ボードや機能拡張ユニットにより行われて上述の実施形態の機能が実現される場合も、かかるプログラムは本実施形態に含まれる。
【００４３】
次に、上記図１のように構成されたネットワークにおいて所望のリソースを検索する際の手順を説明する。まず、リソース１１０の取得を希望しているユーザノード１００は、これに接続している近接ノード１０１，１０２にｌｏｏｋｕｐコマンドを発行する。このとき発行されるｌｏｏｋｕｐコマンドのパケットは、要求するリソース１１０のＩＤを含んでいる。
【００４４】
ｌｏｏｋｕｐコマンド受け取ったノード１０１，１０２は、それと同じコマンドおよび対応するｈｉｔリプライが自身のキャッシュ記憶部１７に記憶されているかどうかを調べる。同じｌｏｏｋｕｐコマンドとｈｉｔリプライとのペアが記憶されている場合は、当該ｈｉｔリプライをキャッシュ記憶部１７から読み出し、ユーザノード１００に返す。一方、受信したｌｏｏｋｕｐコマンドと同じコマンドあるいはそれに対応するｈｉｔリプライがキャッシュ記憶部１７に記憶されていない場合は、インデックス記憶部１４内のインデックス情報をリソースＩＤで検索する。
【００４５】
ここで、検索にヒットしない場合は、ユーザノード１００から受信したｌｏｏｋｕｐコマンドを近接ノード１０３〜１０６に伝播する。このｌｏｏｋｕｐコマンドを受け取ったノード１０３〜１０６においても同様に、キャッシュ記憶部１７を検索して同じｌｏｏｋｕｐコマンドやそれに対応するｈｉｔリプライが記憶されているかどうかを調べるとともに、インデックス記憶部１４を検索して、要求されているリソース１１０を自身が持っているかどうかを調べる。
【００４６】
このようにコマンド伝播を繰り返していく中で、ノード１０３においてリソース１１０の検索にヒットしたとする。この場合ノード１０３は、ｈｉｔリプライを発行する。発行されたｈｉｔリプライは、各ノードの伝播情報記憶部１５に記憶されている伝播情報に基づいて、ｌｏｏｋｕｐコマンドを伝播した各ノードにより逆向きに伝播され、コマンド発行元のユーザノード１００まで届けられる。このようなｌｏｏｋｕｐコマンドとｈｉｔリプライの伝播を行う際に、それらのコマンドがキャッシュ記憶部１７にキャッシュ記憶される。
【００４７】
なお、上記の例において、ノード１０４がノード１０１からｌｏｏｋｕｐコマンドを受信した際には、キャッシュ記憶部１７およびインデックス記憶部１４を検索した結果に応じて、近接ノード１０５，１０７に対してｌｏｏｋｕｐコマンドが更に伝播されることになる。このとき、ノード１０５は、同じｌｏｏｋｕｐコマンドをノード１０２から既に受信して近接ノード１０４，１０７へと転送している。
【００４８】
このときノード１０５内の制御部１３は、伝播情報記憶部１５を参照して、一度転送したコマンドについては、その後別のノードから受け取っても転送しないように制御する。他のノード内の制御部１３も同様の制御を行う。これにより、ネットワーク上に無駄なコマンドが飛び交うのを防ぎ、コマンド伝播の爆発を防止することができる。
【００４９】
図３は、ノード間でやり取りされるパケットデータの構造を示す図である。図３（ａ）に示すように、本実施形態のパケットデータは、ＴＣＰヘッダとＴＣＰデータとを含んで構成されている。このうちＴＣＰデータは、図３（ｂ）に示すように、Ｐ２Ｐアーキテクチャに特有のヘッダと、各種リソースに相当するアプリケーションデータと、当該アプリケーションデータの属性や後述する版情報（リビジョン情報）とを含んでいる。
【００５０】
また、図３（ｃ）に示すように、Ｐ２Ｐヘッダは、ＧＵＩＤ（Ｇｌｏｂａｌ Ｕｎｉｑｕｅ Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ）等によるメッセージＩＤ、ｌｏｏｋｕｐコマンドやｈｉｔリプライ等のコマンド、コマンドの寿命設定時間を表すＴＴＬ情報などを含んで構成されている。伝播情報記憶部１５、履歴記憶部１６、キャッシュ記憶部１７には、メッセージＩＤやコマンドなどが記憶される。
【００５１】
このように本実施形態でもＴＴＬを用いることにより、あるｌｏｏｋｕｐコマンドが発行されたにも関わらず所望のリソースが発見されない場合に、そのコマンドが無限に伝播されていくのを防止し、ネットワーク上に無駄なコマンドが飛び交うのを防ぐことができる。ＴＴＬによってｌｏｏｋｕｐコマンドが途中で消滅した場合、ユーザにはタイムオーバー通知が成される。ユーザはその後で希望する場合には、同じｌｏｏｋｕｐコマンドを発行してリソースの検索を再度試みる。
【００５２】
通常、ネットワークのトポロジは固定的ではない。すなわち、ノードは随時、プログラムの起動によってネットワーク上に新たに参加する。逆に、プログラムの終了によって、ノードは突然ネットワーク上から離脱する。そのため、ＴＴＬによって一度タイムオーバー通知が成された場合でも、再度ｌｏｏｋｕｐコマンドを発行すると、その時点でノードの接続状況が前回と変わっており、所望のリソースを発見できることもある。
【００５３】
ところが、タイムオーバー通知の直後にｌｏｏｋｕｐコマンドを発行しても、ノードの接続状況が変わっていないことが多い。この場合には、何度ｌｏｏｋｕｐコマンドを発行しても、その都度タイムオーバーとなって所望のリソースを発見できない。また、接続状況が変わっていても、相変わらず所望のリソースが遠くにあるため、ＴＴＬによるコマンド寿命の設定によって依然としてリソースを発見できないこともある。
【００５４】
そこで、本実施形態では、上述したノードの参加および離脱とは別に、参加済みのノードの接続先を自律的に変更するように制御する。このとき、制御部１３は、履歴記憶部１６を参照して、経路が最短となるようにノード間の接続先を動的に変更する。
【００５５】
例えば、過去の検索ヒット数（ｈｉｔリプライの発行数）が多いノードは、多数のユーザが所望するリソースを備えている重要なノードであるので、これに対する接続を積極的に試みる。ｌｏｏｋｕｐコマンドの発行数が多いノードも重要なノードなので、これに対する接続を試みる。特に、２つのノード間でリソースへのアクセスが多い場合は、その２つのノード間でより速くｈｉｔリプライを返す方が良いので、そのノード間は接続するようにする。
【００５６】
また、ネットワーク的な距離が近いノード間は接続するが、ネットワーク的な距離が遠いノード間は接続を切るようにする。ネットワーク的な距離は、ｌｏｏｋｕｐコマンドを発行してからｈｉｔリプライが返ってくるまでの時間を実績としてとるようにしても良いし、特別な距離測定用コマンドを定期的に近接ノードに送ることによって距離を測るようにしても良い。また、例えばファイアウォールの存在等によって過去に接続できなかったノード間には接続を形成しないようにする。
【００５７】
このように、履歴記憶部１６に記憶されている種々の履歴情報に基づいてノード間の接続を能動的に変えることにより、ＴＴＬによるタイムオーバーが何度も続く事態を防ぐことができる。また、ＴＴＬによるコマンド寿命の問題とは関係なく、ネットワークとしての応答性を上げることができるとともに、コマンドの増殖も有効に抑制することができる。
【００５８】
すなわち、本実施形態によれば、重要なノードがトポロジの中心方向に徐々に押し込まれていき、そこに多くのノードが接続されるようになる。これにより、ノード間の接続を最適化することができる。上述したキャッシュ記憶部１７を用いた場合、過去と同じリソースの検索であればキャッシュ情報にヒットして直ちにｈｉｔリプライが返されるが、異なるリソースを検索する場合にはキャッシュ情報にヒットしない。しかし、この場合でも、ノード間の接続が最適化されている結果、所望のリソースを有するノードとのネットワーク的な距離は近い可能性が高く、多くのコマンド伝播をしなくてもｈｉｔリプライを受けることができる。
【００５９】
次に、インデックス記憶部１４に記憶されるインデックスの詳細について説明する。本実施形態のインデックスは、リソースを一意に識別するリソースＩＤ（識別情報）と、リソースの版を識別するリビジョンＩＤ（版情報）と、リソースの所有者であるユーザを一意に識別するユーザＩＤ（ユーザ情報）とを含んでいる。
【００６０】
このように、リソースＩＤの他にユーザＩＤを持つことにより、他のノードからリソースをコピーした場合でも、そのリソースが誰の所有物であるかを特定することができる。これにより、特定ユーザのリソースを他のノードにもコピーして置いておくことが可能となる。
【００６１】
制御部１３は、特定ユーザのリソースを検索するためのｌｏｏｋｕｐコマンドが与えられたときには、そのｌｏｏｋｕｐコマンド中に含まれているリソースＩＤとユーザＩＤとをもとにインデックス記憶部１４を検索し、この検索にヒットした場合にｈｉｔリプライを返すように制御する。
【００６２】
このようにすることによって、リソースのオリジナルが存在する特定ユーザのノードから遠くにあるノードにおいても、ＴＴＬの制御によってｌｏｏｋｕｐコマンドの消滅を受けることなく、当該特定ユーザのリソースのコピーを他のノードから取得することができるようになる。つまり、Ｐ２Ｐネットワークシステムにおいても特定ユーザの知識ＤＢを共有することが可能となる。
【００６３】
ただし、複数のノード間で特定ユーザのリソースを共有しようとする場合、複数のノードに存在する同じリソースは常に同じ内容となるようにしておかなければならない。これは、特定ユーザのリソースに限らず、内容が更新され得る動的リソースであれば同じことである。そのために制御部１３は、あるノードにおいて動的リソースが更新されたときには、その動的リソースを他のノードにも転送することにより、複数のノードに存在する同じ動的リソースが全て同じ内容となるように同期処理を行う。
【００６４】
この同期処理において転送するデータ量を削減するために、本実施形態ではリソースの更新をリビジョンで管理するようにしている。すなわち、本実施形態のリソースは、図４（ａ）に示すように、内容が更新される都度、更新前後の差分情報をストレージに記憶することによって管理する。更新されたリソースの版がどの状態であるかを示すのがリビジョンＩＤであり、図４（ｂ）のようにリソースＩＤとリビジョンＩＤとによって特定の状態にアクセスすることができる。
【００６５】
各ノードの制御部１３は、一定時間毎に最新リビジョンを検索するｌｏｏｋｕｐコマンドを発行して、他のノードから最新の差分情報を取得することにより、同期処理を行う。このとき制御部１３は、受信したｌｏｏｋｕｐコマンド中に含まれているリソースＩＤとリビジョンＩＤとをもとにインデックス記憶部１４を検索し、この検索にヒットした場合にｈｉｔリプライを返すように制御する。
【００６６】
このように、本実施形態によれば、動的リソースの同期処理の際には差分情報のみを転送するようにしたので、転送データ量を削減し、通信トラフィックを減少させることができる。なお、ここでは一定時間毎にｌｏｏｋｕｐコマンドを発行する例について説明しているが、リビジョン間をマージするタイミングはこれに限定されるものではない。
【００６７】
以上に説明した本実施形態のプロトコルは、様々なネットワークシステムに適用することが可能である。例えば、Ｐ２Ｐプロトコルをベースにしたグループウェアに適用することができる。このグループウェアの中では、例えば、個人またはグループのスケジュールやタスクの管理、文書等のファイル管理、プロジェクトの進捗管理などを行うことができる。
【００６８】
以上詳しく説明したように、本実施形態においては、
・コマンドのパケットにＴＴＬを設定する。
・一度転送したコマンドは、別のノードから受け取っても転送しない。
・リモートリソースの在り処を各ノードがキャッシュ記憶する。
といった仕組みを持つことにより、コマンドの増殖を防止し、通信トラフィックの増大を抑止することができる。また、ネットワークとしての応答性を向上させることもできる。
【００６９】
また、本実施形態では、コマンド伝播や接続、アクセスなどに関する過去の実績を履歴として記憶しておき、その履歴に応じて複数ノード間の接続を可変制御するようにしたので、ノード間の接続を最適化して、ネットワークとしての応答性を更に向上させることができる。
【００７０】
また、本実施形態では、リソースをユーザＩＤによって管理するようにしたので、特定ユーザのリソースを複数のノードにコピーして管理することが可能となる。これにより、特定ユーザのリソースであってもｌｏｏｋｕｐコマンドによるリソースの発見および交換を行うことができ、Ｐ２Ｐネットワーク技術において特定ユーザの知識ＤＢを共有することができるようになる。
【００７１】
また、本実施形態では、動的リソースの同期処理を行う際に、更新前後の差分情報のみを転送するようにしたので、転送データ量を削減し、通信トラフィックを減少させることができる。
【００７２】
なお、上記実施形態においては、キャッシュ記憶部１７には、他のノードから受け取ったｌｏｏｋｕｐコマンドおよびｈｉｔリプライそのものを記憶するようにしているが、どのノードにリソースが存在するのかを表した情報を記憶するようにしても良い。例えば、ｈｉｔリプライを受信したときに、そのｈｉｔリプライを発行した他のノードおよびそのノードが備えるリモートリソースのＩＤを記憶するようにする。
【００７３】
この場合、制御部１３は、他のノードからｌｏｏｋｕｐコマンドを受信した際に、そのｌｏｏｋｕｐコマンド中に含まれているリソースＩＤがキャッシュ記憶部１７に記憶されているかどうかを調べる。そして、該当するリソースＩＤが記憶されている場合には、そのリソースを実際に持っているノードの情報をキャッシュ記憶部１７から読み出し、当該ノードを知らせるｈｉｔリプライを発行して、ｌｏｏｋｕｐコマンド送信元のノードに返すようにする。
【００７４】
その他、上記実施形態は、本発明を実施するにあたっての具体化の一例を示したものに過ぎず、これによって本発明の技術的範囲が限定的に解釈されてはならないものである。すなわち、本発明はその精神、またはその主要な特徴から逸脱することなく、様々な形で実施することができる。
【００７５】
【発明の効果】
本発明は上述したように、リソースの在り処を表す情報を各ノードがキャッシュ記憶し、キャッシュ記憶された情報に基づいて検索がヒットした場合にはリソース検索コマンドを他のノードに伝播せず、直ちに検索ヒット応答を返すようにしている。これにより、ＴＴＬの手法以外でもコマンドの増殖を有効に防ぐことができ、通信トラフィックの増大を抑止することができる。また、リソース検索コマンドを発行してから検索ヒット応答が返ってくるまでのネットワークとしての応答性を上げることもできる。
【００７６】
本発明の他の特徴によれば、各ノードにおいてリソースに関するユーザ情報を記憶し、そのユーザ情報に基づいて検索がヒットした場合に検索ヒット応答を返すようにしている。これにより、特定ユーザのリソースを複数のノードにコピーして管理することが可能となり、Ｐ２Ｐネットワーク技術において特定ユーザの知識ＤＢを共有することができるようになる。
【００７７】
また、本発明の他の特徴によれば、リソースが更新されたときには更新前後の差分情報を記憶して管理するようにしている。これにより、動的リソースの同期処理を行う際に、更新前後の差分情報のみを転送するようにすることができ、転送データ量を削減して通信トラフィックの混雑を抑制することができる。
【００７８】
また、本発明の他の特徴によれば、コマンド伝播等に関する履歴を記憶しておき、その履歴情報に応じて複数ノード間の接続を可変制御するようにしたので、ノード間の接続を最適化することができる。これにより、コマンドの増殖を防止して通信トラフィックの混雑を抑止することができるとともに、ネットワークとしての応答性を更に向上させることができる。
【図面の簡単な説明】
【図１】本実施形態のネットワークシステムが適用されるネットワークの概略構成例を示す図である。
【図２】本実施形態のノードが備える機能構成を示すブロック図である。
【図３】本実施形態のノード間でやり取りされるパケットデータの構造を示す図である。
【図４】本実施形態によるリソースの構成を示す図である。
【図５】Ｐ２Ｐアーキテクチャを利用して所望のリソースを検索および取得する際の手順を示す図である。
【符号の説明】
１１ 接続部
１２ アクセス部
１３ 制御部
１４ インデックス記憶部
１５ 伝播情報記憶部
１６ 履歴記憶部
１７ キャッシュ記憶部
１００ ユーザノード（ｌｏｏｋｕｐコマンド発行元ノード）
１０１〜１０８ ノード
１１０ リソース
Claims (6)
- 接続している近接ノード群にリソース検索コマンドを伝播していき、あるノードにおいてリソースの検索にヒットした場合、当該検索ヒットノードから検索ヒット応答を、上記リソース検索コマンドを伝播した各ノードにより逆向きに伝播してコマンド発行元ノードまで届けた後、上記コマンド発行元ノードが上記検索ヒットノードにアクセスして上記リソースを取得するように成されたネットワークシステムであって、各ノードは、
上記検索ヒット応答の伝播時に、上記検索ヒットノードが備えるリモートリソースの識別情報とその在り処をキャッシュ記憶するキャッシュ記憶手段と、
上記リソース検索コマンドが与えられたときに上記キャッシュ記憶手段を参照してリソースの検索を行い、当該リソースの検索にヒットした場合に上記検索ヒット応答を返すように制御する制御手段とを備えたことを特徴とするネットワークシステム。 - 接続している近接ノード群にリソース検索コマンドを伝播していき、あるノードにおいてリソースの検索にヒットした場合、当該検索ヒットノードから検索ヒット応答を、上記リソース検索コマンドを伝播した各ノードにより逆向きに伝播してコマンド発行元ノードまで届けた後、上記コマンド発行元ノードが上記検索ヒットノードにアクセスして上記リソースを取得するように成されたネットワークシステムであって、各ノードは、
上記リソースの識別情報およびそのリソースに関するユーザ情報を記憶する情報記憶手段と、
上記リソース検索コマンドが与えられたときに上記情報記憶手段を参照してリソースの検索を行い、要求されたユーザリソースの検索にヒットした場合に上記検索ヒット応答を返すように制御する制御手段とを備えたことを特徴とするネットワークシステム。 - 接続している近接ノード群にリソース検索コマンドを伝播していき、あるノードにおいてリソースの検索にヒットした場合、当該検索ヒットノードから検索ヒット応答を、上記リソース検索コマンドを伝播した各ノードにより逆向きに伝播してコマンド発行元ノードまで届けた後、上記コマンド発行元ノードが上記検索ヒットノードにアクセスして上記リソースを取得するように成されたネットワークシステムであって、各ノードは、
上記リソースを、当該リソースが更新されたときには更新前後の差分情報を記憶して管理するリソース管理手段と、
上記リソースの識別情報および上記差分情報に関する版情報を記憶する情報記憶手段と、
上記リソース検索コマンドが与えられたときに上記情報記憶手段を参照してリソースの検索を行い、当該リソースの検索にヒットした場合に上記検索ヒット応答を返すように制御する制御手段とを備えたことを特徴とするネットワークシステム。 - 上記各ノードは、最新の差分情報を検索するリソース検索コマンドを所定タイミング毎に発行して上記最新の差分情報を取得する同期処理手段を備えたことを特徴とする請求項３に記載のネットワークシステム。
- 接続している近接ノード群にリソース検索コマンドを伝播していき、あるノードにおいてリソースの検索にヒットした場合、当該検索ヒットノードから検索ヒット応答を、上記リソース検索コマンドを伝播した各ノードにより逆向きに伝播してコマンド発行元ノードまで届けた後、上記コマンド発行元ノードが上記検索ヒットノードにアクセスして上記リソースを取得するように成されたネットワークシステムであって、各ノードは、
上記接続、アクセス、コマンド伝播の少なくとも一に関する履歴を記憶する履歴記憶手段と、
上記履歴記憶手段に記憶されている履歴に基づいて、複数ノード間の接続を制御する接続制御手段とを備えたことを特徴とするネットワークシステム。 - 請求項１〜５の何れか１項に記載の各手段としてコンピュータを機能させるためのプログラム。
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002178038A JP2004021770A (ja) | 2002-06-19 | 2002-06-19 | ネットワークシステムおよびプログラム |
| PCT/JP2003/007616 WO2004001629A1 (ja) | 2002-06-19 | 2003-06-16 | ネットワークシステムおよびプログラム |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002178038A JP2004021770A (ja) | 2002-06-19 | 2002-06-19 | ネットワークシステムおよびプログラム |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| JP2004021770A true JP2004021770A (ja) | 2004-01-22 |
Family
ID=29996503
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2002178038A Pending JP2004021770A (ja) | 2002-06-19 | 2002-06-19 | ネットワークシステムおよびプログラム |
Country Status (2)
| Country | Link |
|---|---|
| JP (1) | JP2004021770A (ja) |
| WO (1) | WO2004001629A1 (ja) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2008537619A (ja) * | 2005-03-21 | 2008-09-18 | インターナショナル・ビジネス・マシーンズ・コーポレーション | ピア・ツー・ピア（ｐ２ｐ）・ネットワークを効率的に拡張するための方法、装置、およびプログラム |
Families Citing this family (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN111125580B (zh) * | 2019-12-09 | 2023-08-15 | 北京五八信息技术有限公司 | 网络资源获取方法、装置、电子设备及存储介质 |
Family Cites Families (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2000250799A (ja) * | 1999-03-02 | 2000-09-14 | Mitsubishi Electric Corp | 複製ファイル管理システム |
-
2002
- 2002-06-19 JP JP2002178038A patent/JP2004021770A/ja active Pending
-
2003
- 2003-06-16 WO PCT/JP2003/007616 patent/WO2004001629A1/ja active Application Filing
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2008537619A (ja) * | 2005-03-21 | 2008-09-18 | インターナショナル・ビジネス・マシーンズ・コーポレーション | ピア・ツー・ピア（ｐ２ｐ）・ネットワークを効率的に拡張するための方法、装置、およびプログラム |
| JP4755683B2 (ja) * | 2005-03-21 | 2011-08-24 | インターナショナル・ビジネス・マシーンズ・コーポレーション | ピア・ツー・ピア（ｐ２ｐ）・ネットワークを効率的に拡張するための方法、装置、およびプログラム |
| US8788573B2 (en) | 2005-03-21 | 2014-07-22 | International Business Machines Corporation | Method and apparatus for efficiently expanding a P2P network |
Also Published As
| Publication number | Publication date |
|---|---|
| WO2004001629A1 (ja) | 2003-12-31 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US9602618B2 (en) | Method and system for dynamic distributed data caching | |
| US6760756B1 (en) | Distributed virtual web cache implemented entirely in software | |
| US7451141B2 (en) | Method and apparatus for restricting a fan-out search in a peer-to-peer network based on accessibility of nodes | |
| JP2007310673A (ja) | Ｐ２ｐネットワークのストレージ構成方法およびストレージシステム | |
| US7958195B2 (en) | Method and apparatus for improving data transfers in peer-to-peer networks | |
| JP2004127189A (ja) | ゲートウェイ装置、コンテンツ転送システム及びコンテンツ転送方法 | |
| US20030187931A1 (en) | Facilitating resource access using prioritized multicast responses to a discovery request | |
| JP4590651B2 (ja) | レプリケーション制御方法とシステムおよびプログラム | |
| JP4573732B2 (ja) | サーバント装置 | |
| Cai et al. | Foreseer: a novel, locality-aware peer-to-peer system architecture for keyword searches | |
| AU2008287031A1 (en) | A method and system for tracking and optimizing advertisements on a decentralized network | |
| JP4741301B2 (ja) | 情報検索システム、情報検索装置、情報検索方法、記録媒体及びプログラム | |
| US20080307045A1 (en) | Method, system and apparatus for managing directory information | |
| KR100694079B1 (ko) | 유무선 통합 네트워크에서 ｐ２ｐ 서비스를 위한 데이터다운로드 방법 및 그 노드 | |
| JP4828315B2 (ja) | リソース検索システム | |
| JP2004021770A (ja) | ネットワークシステムおよびプログラム | |
| KR20030014513A (ko) | 서버 부하의 분산을 위한 클라이언트 데이터 공유 시스템및 그 방법 | |
| JP2007317107A (ja) | 情報処理システム、及び情報処理装置、並びに制御プログラム | |
| AU5756000A (en) | Distributed virtual web cache implemented entirely in software | |
| JP2004280847A (ja) | 情報中継装置及び記憶媒体 | |
| JP2005322022A (ja) | ピアツーピア端末装置及びキャッシュ生成方法ならびにそのコンピュータプログラム | |
| JP4243150B2 (ja) | コンテンツ配信システムおよび利用者端末装置 | |
| JP2006221457A (ja) | Ｐｕｒｅ型Ｐ２Ｐ通信におけるレプリケーション制御を行うサーバントとそのレプリケーション制御方法およびプログラム | |
| US7698414B1 (en) | Global monitoring and statistics collection for a plurality of computing nodes | |
| JP2004102531A (ja) | ネットワークシステム、ノード、ノード制御方法、ノード制御プログラム |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20050525 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20080318 |
|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20080715 |