JP4670042B2 - ノード装置、ノード装置情報更新方法、及びノード装置情報更新プログラム - Google Patents

Description

本発明は、ネットワークを介して互いに接続された複数のノード装置を備えたピアツーピア（Peer to Peer（P2P））型のコンテンツ配信システムに関し、特に、１のノード装置から他のノード装置に配信されるべきコンテンツデータに関する情報更新方法及びコンテンツ配信システム等の技術分野に関する。

この種のコンテンツ配信システムにおいては、各ノード装置は、複数のノード装置に分散保存されているコンテンツデータに関する情報（例えば、コンテンツデータの属性情報（コンテンツの名称等）や、コンテンツデータを保存しているノード装置のＩＰアドレス）が記述されたリストを有しており、当該リストに記述された情報に基づき、ユーザが所望するコンテンツデータをダウンロードすることが可能になっている。このようなリストは、複数のノード装置において共通に使用されるべき共用情報であり、一般に、コンテンツ配信システム上に保存されている全てのコンテンツデータを管理する管理サーバにより管理され、当該管理サーバから各ノード装置に対して上記リストが配信されることになる。

例えば、特許文献１には、この種の管理サーバとして、最上位に存在し、コンテンツ配信管理システム内の全てのコンテンツ情報を管理するインデックスサーバが開示されている。
特開２００２−３１８７２０号公報

ところで、ピアツーピア型のコンテンツ配信システムにおいては、ノード装置の脱退（ノード装置の電源断や故障、或いはネットワークの部分的な切断等による）及び参加が行なわれる頻度が高く、しかも、コンテンツデータのノード装置への新たな保存又は消去が行なわれる頻度が高くなるため、上述したようなリストの更新を頻繁に行わなくてはならず、従って、当該リストを常に最新の状態に保つ必要がある。

一方当該リストを各ノード装置に分散して所有させる方法があるが、当該リストを前述したように常に最新の状態に保つためには、コンテンツデータを保持するノード装置の脱退や、機能停止（例えば、停電や故障等により）や、既に所望のコンテンツが削除されていないことを頻繁に確認する情報をコンテンツ配信システムに発信する必要がある。

しかし、当該リストを有するノード装置間の当該リスト情報を同じ状態に更新するために、当該リスト情報上のノード装置に対して頻繁に確認していたのでは、当該確認のための情報が大量に送信されてしまうため、コンテンツ配信システムに負荷がかかりすぎ、コンテンツ配信システムが効率的に運用されなくなるという問題点があった。

そこで当該リスト情報上のノード装置の情報を効率よく管理・更新する方法が望まれていた。

本発明は、以上の問題等に鑑みてなされたものであり、上記のように、当該リスト情報上のノード装置の情報を効率良く取得することを可能としたノード装置、ノード装置情報更新方法、ノード装置情報更新プログラム、及びノード装置情報更新プログラムを記録した記録媒体を提供することを課題とする。

本発明によれば、各ノード装置は、複数のノード装置において共通に使用されるべきコンテンツデータ等の共用情報を識別するためのコンテンツＩＤ（Identification）等の共用情報識別情報と、共用情報を記憶しているノード装置を識別するためのノードＩＰ（Internet Protocol）アドレス等のノード識別情報の組からなるインデックス情報等の共用情報所在情報を記憶するためのＲＡＭ(Random Access Memory)等の所在情報記憶手段と、所定の更新確認時間間隔で、共用情報所在情報の削除の要否を判断するＣＰＵまたは制御部等の更新判断手段とを設け、更新判断手段の判断に基づいて、前記所在情報記憶手段に記憶されている共用情報所在情報を削除する構成にした。

この構成によれば、インデックス情報を所有するノード装置は、そのノード装置が位置する場所によって変化する中継ノード数に基づいて、インデックス情報上のノード装置の情報を確認する時間間隔を変更するようにしたので、コンテンツ配信システムに負荷がかからずに、コンテンツ配信システムを効率的に運用することができるようになった。

この構成によれば、インデックス情報を所有するノード装置は、インデックス情報上のノード装置の脱退または機能停止またはコンテンツの削除を確認した場合には、他のインデックス情報を所有するノード装置に対して、前記確認したノード装置の情報を発信するようにした。したがって、他のノード装置は、前記確認したノード装置の情報確認のための問い合わせ情報を自ら送信する前に、すみやかにインデックス情報を削除することができるようになった。この結果、ノード装置間のインデックス情報の同一性を速やかに確保できると共にコンテンツ配信システムへの負荷を軽減できる。

この構成によれば、インデックス情報上のノード装置の情報を確実に確認できるようになった。

この構成によれば、インデックス情報上のノード装置の脱退または機能停止またはコンテンツの削除を確認したノード装置は、記憶部に記憶されている当該コンテンツデータに係わるインデックス情報を削除する。各ノード装置に所有されるインデックス情報の同一性がすみやかに確保できるようになった。

請求項１に記載の発明は、ネットワークを介して互いに接続された複数のノード装置を備えた情報配信システムにおける前記ノード装置であって、前記複数のノード装置において共通に使用されるべき共用情報を識別するための共用情報識別情報と、前記共用情報とを記憶しているノード装置を識別するためのノード識別情報の組からなる共用情報所在情報を記憶するための所在情報記憶手段と、所定の更新確認時間間隔で、前記共用情報を有する第２ノード装置に係わる第一更新情報を取得する第一更新情報取得手段と、前記取得された第一更新情報に基づいて、前記所在情報記憶手段に記憶されている共用情報所在情報の削除の要否を判断する更新判断手段と、前記更新判断手段の判断に基づいて、前記所在情報記憶手段に記憶されている共用情報所在情報を削除する情報更新手段と、前記所在情報記憶手段を備えるノード装置と、前記共用情報を有する第１ノード装置との間に介在する中継ノード装置の数を示す中継数情報を記憶する中継数情報記憶手段と、前記中継数情報に基づいて更新確認時間間隔を演算する時間情報演算手段と、を備え、前記第一更新情報取得手段は、前記更新確認時間間隔で、前記共用情報を有するノード装置に係わる第一更新情報を取得することを特徴とする。
請求項２に記載の発明は、請求項１に記載のノード装置において、前記時間情報演算手段は、中継数が多くなると更新確認時間間隔を長くすることを特徴とするノード装置。

請求項１に記載の発明によれば、前記所在情報記憶手段を備えるノード装置と前記共用情報を有する第１ノード装置との間に介在するキャッシュノード等の中継ノード装置の数を示す転送数等の中継数情報を記憶するＲＡＭ等の中継数情報記憶手段と、中継数情報に基づいて共用情報を記憶しているノード装置の存在の有無を確認する時間間隔等の更新確認時間間隔を演算するＣＰＵ（Central Processing Unit）または制御部等の時間情報演算手段とを備える構成とした。
請求項２に記載の発明によれば、ＣＰＵまたは制御部等の時間情報演算手段は、ノード装置等の中継する装置の数をあらわす中継数が多くなると、更新確認時間間隔を長くする構成とした。

この構成によれば、インデックス情報上のノード装置の情報を確認する時間を、当該ノード装置から離れたノード装置ほど、長い時間間隔とするようにした。したがって、コンテンツ配信システムに負荷がかからずに、コンテンツ配信システムを効率的に運用することができるようになった。特に、インデックス情報上のノード装置は、ノード空間に分散されているので、更新確認頻度もノード空間上に分散されるようになり、コンテンツ配信システムにおいて偏在した負荷がかからないようになった。

この構成によれば、インデックス情報を所有するノード装置は、そのノード装置が位置する場所によって変化する中継ノード数に基づいて、コンテンツデータを保持しているノード装置の情報を確認する時間間隔を変更するようにしたので、コンテンツ配信システムに負荷がかからずに、コンテンツ配信システムを効率的に運用することができるようになった。

この構成によれば、インデックス情報を所有するノード装置は、インデックス情報上のノード装置の脱退または機能停止またはコンテンツの削除を確認した場合には、他のインデックス情報を所有するノード装置に対して、前記確認したノード装置の情報を発信するようにした。したがって、他のノード装置は、前記確認したノード装置の情報確認のための問い合わせ情報を自ら送信する前に、すみやかにインデックス情報を削除することができるようになった。この結果、ノード装置間のインデックス情報の同一性を速やかに確保できると共にコンテンツ配信システムへの負荷を軽減できる。

この構成によれば、コンテンツデータを保持しているノード装置の情報を確実に確認できるようになった。

この構成によれば、インデックス情報上のノード装置の脱退または機能停止またはコンテンツの削除を確認したノード装置は、記憶部に記憶されている当該コンテンツデータに係わるインデックス情報を削除する。各ノード装置に所有されるインデックス情報の同一性がすみやかに確保できるようになった。

請求項３に記載の発明は、ネットワークを介して互いに接続された複数のノード装置を備えた情報配信システムにおけるノード装置情報更新方法であって、前記複数のノード装置において共通に使用されるべき共用情報を識別するための共用情報識別情報と、前記共用情報を記憶しているノード装置を識別するためのノード識別情報の組からなる共用情報所在情報を所在情報記憶手段に記憶させるための所在情報記憶工程と、前記所在情報記憶手段を備えるノード装置と、前記共用情報を有する第１ノード装置との間に介在する中継ノード装置の数を示す中継数情報を中継数情報記憶手段が記憶する中継数情報記憶工程と、前記中継数情報に基づいて更新確認時間間隔を時間情報演算手段が演算する時間情報演算工程と、前記時間情報演算工程において演算された前記更新確認時間間隔で、前記共用情報を有する第２ノード装置に係わる第一更新情報を第一更新情報取得手段が取得する第一更新情報取得工程と、前記取得された第一更新情報に基づいて、前記所在情報記憶工程において記憶される共用情報所在情報の削除の要否を更新判断手段が判断する更新判断工程と、前記更新判断工程の判断に基づいて、前記所在情報記憶工程において記憶される共用情報所在情報を情報更新手段が削除する情報更新工程と、を含むことを特徴とする。
請求項４に記載の発明は、請求項３に記載のノード装置情報更新方法において、前記時間情報演算工程において、前記時間情報演算手段は、中継数が多くなると更新確認時間間隔を長くすることを特徴とする。

請求項４に記載の発明によれば、ＣＰＵまたは制御部等の時間情報演算工程において、ノード装置等の中継する装置の数をあらわす中継数が多くなると、更新確認時間間隔を長くする構成とした。

この構成によれば、インデックス情報上のノード装置の情報を確認する時間を、当該ノード装置から離れたノード装置ほど、長い時間間隔とするようにした。したがって、コンテンツ配信システムに負荷がかからずに、コンテンツ配信システムを効率的に運用することができるようになった。特に、インデックス情報上のノード装置は、ノード空間に分散されているので、更新確認頻度もノード空間上に分散されるようになり、コンテンツ配信システムにおいて偏在した負荷がかからないようになった。

請求項５に記載の発明は、ネットワークを介して互いに接続された複数のノード装置を備えた情報配信システムにおける所在情報記憶手段、第一更新情報取得手段、更新判断手段、情報更新手段を備える前記ノード装置に含まれるコンピュータにおいて実行されるプログラムであって、前記複数のノード装置において共通に使用されるべき共用情報を識別するための共用情報識別情報と、前記共用情報を記憶しているノード装置を識別するためのノード識別情報の組からなる共用情報所在情報を前記所在情報記憶手段に記憶させるための所在情報記憶ステップと、前記所在情報記憶手段を備えるノード装置と、前記共用情報を有する第１ノード装置との間に介在する中継ノード装置の数を示す中継数情報を中継数情報記憶手段が記憶する中継数情報記憶ステップと、前記中継数情報に基づいて更新確認時間間隔を時間情報演算手段が演算する時間情報演算ステップと、前記時間情報演算ステップにおいて演算された前記更新確認時間間隔で、前記共用情報を有する第２ノード装置に係わる第一更新情報を第一更新情報取得手段が取得する第一更新情報取得ステップと、前記取得された第一更新情報に基づいて、前記所在情報記憶手段に記憶されている共用情報所在情報の削除の要否を前記更新判断手段に判断させる更新判断ステップと、前記更新判断手段の判断に基づいて、前記所在情報記憶手段に記憶されている共用情報所在情報を前記更新判断手段に削除させる情報更新ステップと、を前記コンピュータに実行させることを特徴とする。
請求項６に記載の発明は、請求項５に記載のノード装置情報更新プログラムにおいて、前記時間情報演算ステップは、前記時間情報演算手段に、中継数が多くなると更新確認時間間隔を長くさせることを特徴とする。

本発明によれば、インデックス情報を所有する各ノード装置は、そのノード装置が位置する場所によって変化する中継ノード数に基づいて、コンテンツデータを保持しているノード装置の情報を確認する時間間隔を変更するようにしたので、コンテンツ配信システムに負荷がかからずに、コンテンツ配信システムを効率的に運用することができるようになった。また、各ノード装置に所有されるインデックス情報の同一性がすみやかに確保できるようになった。

以下、本発明の最良の実施形態を図面に基づいて説明する。なお、以下に説明する実施の形態は、コンテンツ配信システムに対して本発明を適用した場合の実施形態である。

［１．１．１コンテンツ配信システムの構成等］
始めに、図１を参照して、情報配信システムとしてのコンテンツ配信システムの概要構成等について説明する。

図１は、本実施形態に係るコンテンツ配信システムにおける各ノード装置の接続態様の一例を示す図である。

図１の下部枠１０１内に示すように、ＩＸ（Internet eＸchange）３、ＩＳＰ（Internet Service Provider）４、ＤＳＬ（Digital Subscriber Line）回線事業者（の装置）５、ＦＴＴＨ（Fiber To The Home）回線事業者（の装置）６、及び通信回線（例えば、電話回線や光ケーブル等）７等によって、インターネット等のネットワーク（現実世界のネットワーク）８が構築されている。

コンテンツ配信システムＳは、このようなネットワーク８を介して相互に接続された複数のノード装置１ａ，１ｂ，１ｃ・・・１ｘ，１ｙ，１ｚ・・・を備えて構成されることになり、ピアツーピア方式のネットワークシステムとなっている。各ノード装置１ａ，１ｂ，１ｃ・・・１ｘ，１ｙ，１ｚ・・には、ノード装置を示す情報としての固有の製造番号及びＩＰ（Internet Protocol）アドレスが割り当てられている。なお、製造番号及びＩＰアドレスは、複数のノード装置１間で重複しないものである。なお、以下の説明において、ノード装置１ａ，１ｂ，１ｃ・・・１ｘ，１ｙ，１ｚ・・・のうち何れかのノード装置を示す場合には、便宜上、ノード装置１という場合がある。

そして、このコンテンツ配信システムＳにおいては、特定のアルゴリズム、例えば、後述する分散ハッシュテーブル（以下、ＤＨＴ（Distributed Hash Table）という）を利用したアルゴリズムによって、図１の上部枠１００内に示すような、オーバレイネットワーク９が構築されることになる。つまり、このオーバレイネットワーク９は、既存のネットワーク８を用いて形成された仮想的なリンクを構成するネットワークを意味する。

本実施形態においては、ＤＨＴを利用したアルゴリズムによって構築されたオーバレイネットワーク９を前提としており、このオーバレイネットワーク９上に配置されたノード装置１を、コンテンツ配信システムＳに参加（言い換えれば、オーバレイネットワーク９に参加）しているノード装置１という。コンテンツ配信システムＳへの参加は、未だ参加していないノード装置が、既に参加している任意のノード装置１に対して参加要求を送ることによって行われる。

コンテンツ配信システムＳに参加している各ノード装置１のノードＩＤは、例えば、ＩＰアドレスあるいは製造番号を共通のハッシュ関数によりハッシュ化した値であり、一つのＩＤ空間に偏りなく分散して配置されることになる。このように共通のハッシュ関数により求められた（ハッシュ化された）ノードＩＤは、当該ＩＰアドレスあるいは製造番号が異なれば、同じ値になる確率が極めて低いものである。なお、ハッシュ関数については公知であるので詳しい説明を省略する。本実施形態では、ＩＰアドレス（グローバルＩＰアドレス）を共通のハッシュ関数によりハッシュ化した値をノードＩＤとする。

また、コンテンツ配信システムＳに参加している複数のノード装置１には、１のノード装置１から他のノード装置1に配信されるべき配信情報としてのコンテンツ（例えば、映画や音楽等）データが分散して保存（格納）されている。例えば、ノード装置１ａには、タイトルがＸＸＸの映画のコンテンツデータが保存されており、一方、ノード装置１ｂには、タイトルがＹＹＹの映画のコンテンツデータが保存されるというように、互いに異なるコンテンツデータが、複数のノード装置１に分散されて保存される（ただし、同じコンテンツデータが複数のノード装置１に分散されて保存される場合もある）。

どのノード装置１に、どのコンテンツデータが保存されるようにしてもよいが、例えば、コンテンツデータに関する情報の一例としてのキーワード（例えば、コンテンツの名称（コンテンツタイトル）やコンテンツの概要情報（あらすじ）等のキーワード）が、上記ノードＩＤを得るときと共通のハッシュ関数によりハッシュ化され（つまり、ノード装置１のＩＰアドレスのハッシュ値と同一のＩＤ空間に配置）、そのハッシュ値と最も近い（例えば、上位桁がより多く一致する）ノードＩＤを有するノード装置１が、当該コンテンツデータを保存するか、あるいは、その所在情報を管理する。これにより、コンテンツデータを偏りなくコンテンツ配信システムＳ上に分散させることが可能となる。なお、異なるコンテンツデータであっても、同一のキーワード（例えば、コンテンツの名称）になる場合が想定されるが、この場合、同じハッシュ値になってしまうので、これを避けるために、ハッシュ化するキーワードを、例えば、コンテンツの名称と著作権情報（例えば、出演者名、監督名、原作者名、歌手名、作曲者名、又は作詞者名等）の組合せとすればよい。

このように分散保存されているコンテンツデータの所在は、各ノード装置１が、ＤＨＴにより少しずつ分担して保持しており、これらのＤＨＴが用いられてコンテンツデータの所在、即ち、保存元であるノード装置１を検索（発見）できるようになっている。このＤＨＴには、例えば、他のノード装置への経路情報、すなわち、ノードＩＤ空間内で適度に離れた他のノード装置のノードＩＤ（ハッシュ値）とそのＩＰアドレスが、複数登録されている。

［１．１．２．ノード装置の構成等］
次に、図２を参照して、ノード装置１の構成及び機能について説明する。

図２は、ノード装置１の概要構成例を示す図である。

各ノード装置１は、図２に示すように、演算機能を有するＣＰＵ，作業用ＲＡＭ，各種データ及びプログラムを記憶するＲＯＭ等から構成されたコンピュータとしての制御部１１と、上記コンテンツデータ、上記キーワードリストＬ、上記ＤＨＴ及びプログラム等を記憶保存（格納）するためのＨＤＤ等から構成された共用情報報記憶手段としての記憶部１２（上記コンテンツデータは、保存されていないノード装置１もある）と、受信されたコンテンツデータを一時蓄積するバッファメモリ１３と、コンテンツデータに含まれるエンコードされたビデオデータ（映像情報）及びオーディオデータ（音声情報）等をデコード（データ伸張や復号化等）するデコーダ部１４と、当該デコードされたビデオデータ等に対して所定の描画処理を施しビデオ信号として出力する映像処理部１５と、当該映像処理部１５から出力されたビデオ信号に基づき映像表示するＣＲＴ，液晶ディスプレイ等の表示部１６と、上記デコードされたオーディオデータをアナログオーディオ信号にＤ（Digital）／Ａ（Analog）変換した後これをアンプにより増幅して出力する音声処理部１７と、当該音声処理部１７から出力されたオーディオ信号を音波として出力するスピーカ１８と、コンテンツデータに含まれるビデオデータ及びオーディオデータ等をエンコード（データ圧縮や暗号化等）するエンコーダ部１９と、ネットワーク８を通じて他のノード装置１との間の情報の通信制御を行うための通信部２０と、ユーザからの指示を受け付け当該指示に応じた指示信号を制御部１１に対して与える入力部（例えば、キーボード、マウス、或いは、操作パネル等）２１と、を備えて構成され、制御部１１、記憶部１２、バッファメモリ１３、デコーダ部１４、エンコーダ部１９、及び通信部２０はバス２２を介して相互に接続されている。

そして、制御部１１におけるＣＰＵが記憶部１２等に記憶された各種プログラムを実行することにより、ノード装置１全体を統括制御するようになっており、また、入力部２１からの指示信号に応じて、コンテンツデータ登録処理等を行うようになっている。

[１．２ コンテンツデータ関連情報を保持するノード装置の決定方法]
ここで、図３（ａ）を参照して、コンテンツデータを保持しているノード装置のアドレス情報を記憶するノード装置１の決定方法の一例について説明する。

コンテンツのタイトル、コンテンツデータの属性データ、コンテンツデータの先頭数バイトなどにハッシュ関数をかけた値をコンテンツＩＤと称することは前述したとおりである。このコンテンツＩＤとノードＩＤとは同一のリング状のＩＤ空間上に点在しているものとして考えることができる。

これらの関係を図３（ａ）に示す。図３（ａ）は、２つの同心円をあらわしており、内側の同心円Ｃ１はコンテンツＩＤの空間をあらわす。外側の同心円Ｃ２はノードＩＤの空間をあらわす。また、コンテンツＩＤはｃＩＤとあらわし、ノードＩＤはｎＩＤとしてあらわしている。さらにコンテンツＩＤおよびノードＩＤは３２ビットのアドレスを持つものとし、図３（ａ）では３２ビットのアドレスを４ビット毎に１６進数であらわしている。さらに、同心円Ｃ１および同心円Ｃ２において、各アドレスは反時計方向の向きに回るに従って、アドレスの値が大きくなっている。点Ａ１および点Ａ２は、値０であり、点Ａ１および点Ａ２の１つ右側のＩＤは、２³²−１である。各同心円上では、各ＩＤの生成にハッシュ関数を使用しているので、各ノード、各コンテンツは、この空間上に偏在することなく散らばって存在するようになる。

ＤＨＴでは、「あるコンテンツＩＤを管理するノードは、そのコンテンツＩＤに一番近いノードＩＤをもつノードである」。という約束にする。「近い」の定義は、本願においては、そのＩＤを超えないでＩＤ値の差が一番少ないＩＤを最も近いＩＤとする。例えば、図３（ａ）において同心円Ｃ２上にあるノードＩＤがＡ０３３４０５５であるノード装置およびノードＩＤがＡ０３３４０ＦＦであるノード装置について前記の条件に従えば、コンテンツＩＤがＡ０３３４０８０であるコンテンツデータは、ノードＩＤがＡ０３３４０５５であるノード装置が管理する。

このように各コンテンツを各ノードで管理することにより、様々なコンテンツを、多数のノードで分散して管理することができるようになる。ここで管理するという意味は、コンテンツ自体を保持することを意味するわけではなく、コンテンツが実際のネットワークに接続されたノード装置のうちどのアドレスを持つノード装置に保持されているかを示す情報を所有しているという意味である。このアドレスとは、図１におけるオーバレイネットワーク１０１におけるノード装置のＩＰアドレス等のアドレスを示す。

すなわち、実際のコンテンツが存在している場所は、前記のノード装置であってもよいし、別のノード装置であってもよいことを示す。

コンテンツの所在場所を管理するノード装置を「ルートノード」と称する。ルートノードは、コンテンツＩＤと、そのコンテンツを保持しているノード装置のＩＰアドレスとの組合せ情報を管理している。この組合せ情報を少なくとも有する情報をインデックス情報と称する。インデックス情報には、コンテンツタイトルやコンテンツ属性が含まれている場合もある。

また、１つのルートノードが、複数のインデックス情報を有している場合もある。これは、異なるコンテンツのコンテンツＩＤがたまたま近い値になった場合において、そのコンテンツＩＤの近くに他のノード装置がない場合に発生する。コンテンツ情報本体（ＭＰＥＧファイルやＭＰ３ファイルなどのコンテンツデータ）を保持しているノード装置のことを、コンテンツホルダと称する。インデックス情報の組合せの例を図３（ｂ）に示す。図３（ｂ）の上段には、インデックス情報の内容が示されている。最上段のインデックス情報には、コンテンツＩＤとして“５４ＤＥ９８７８”、ホルダのＩＰアドレスとして“２２１：２３：１５４：６５”、コンテンツのタイトルとして“タイタニック”、コンテンツのジャンルとして“ラブロマンス”等の情報が含まれることがわかる。

[１．３ ＤＨＴのルーティングテーブルの原理説明]
前述したように全てのノード装置のＩＰアドレスを各ノード装置が記憶することは、現実的ではないので、あるノード装置は特定のノード装置のＩＰアドレスだけを記憶する。このために、ＤＨＴにおいては、特別なルーティングテーブルを用意している。このルーティングテーブルの構成を以下に説明する。

まず、ノードＩＤ空間をいくつかの領域に分割する必要があるがここでは４分割にした状態を図４に示す。ノードＩＤのアドレスを１６ビットとし、４進数であらわしているので、図４の各ノードＩＤアドレスは８桁であらわされる。図４において領域Ａ０を示す左上の部分がアドレス（００００００００）からアドレス（０３３３３３３３）までをあらわし、領域Ａ１を示す図４において左下の部分がアドレス（１０００００００）からアドレス（１３３３３３３３）までをあらわし、領域Ａ２を示す図４において右下の部分がアドレス（２０００００００）からアドレス（２３３３３３３３）までをあらわし、領域Ａ３を示す図４において左上の部分がアドレス（３０００００００）からアドレス（３３３３３３３３）までをあらわしている。

図４の例では、ノード装置Ｎ１（ノードＩＤアドレスは１０２３０２１０。）のルーティングテーブルをどのように作製するかについて説明する。

[１．３．１ レベル１のルーティング]
図４に示すようにノードＩＤ空間を４分割する。４分割されたそれぞれの領域は、４進数で表現すると、領域Ａ０が０×××××××（×は０乃至３までのいずれかの値である。）とあらわされ、領域Ａ１が１×××××××とあらわされ、領域Ａ２が２×××××××とあらわされ、領域Ａ３が３×××××××とあらわされる。レベル１のルーティングでは、ノード装置Ｎ１が存在する領域Ａ１以外の領域のノード装置を無作為に選んで、そのノード装置のノードＩＤアドレスとＩＰアドレスをノード装置Ｎ１のＲＡＭ等の記憶部に記憶する。例えば、レベル１のルーティングテーブルは図５のようになる。図５では領域Ａ０のノード装置としてノード装置Ｎ０を選択しているので、ノード０のノードＩＤアドレス（０１３０００００）とノード０のＩＰアドレスとをルーティングテーブルの１列目に対応付けて記憶する。２列目は、領域Ａ１に存在するノード１自身をあらわしている。次に、領域Ａ２のノード装置としてノード装置Ｎ２を選択しているので、ノード装置Ｎ２のノードＩＤアドレス（２２０３１０００）とノード装置Ｎ２のＩＰアドレスとを３列目に対応付けて記憶する。次に領域Ａ３のノード装置としてノード装置Ｎ３を選択しているので、ノード装置Ｎ３のノードＩＤアドレス（３２２０１０１０）とノード装置Ｎ３のＩＰアドレスとを３列目に対応付けて記憶する。このように各領域にノード装置が存在する場合には、自己が存在しない各領域の少なくとも一つのノード装置のノードＩＤアドレスとノードＩＰアドレスを組み合わせて、記憶部に記憶する。

[１．３．２ レベル２のルーティング]
次に、図４に示された自己のノード装置であるノード装置Ｎ１が存在する領域Ａ１をさらに４分割する。領域Ａ１が４分割された状態を図６にあらわす。図６に示すように自己のノード装置であるノード装置Ｎ１が存在する領域Ａ１をさらに４分割する。４分割されたそれぞれの領域は、４進数で表現すると、領域Ａ１０が１０××××××（×は０乃至３までのいずれかの値である。）とあらわされ、領域Ａ１１が１１××××××とあらわされ、領域Ａ１２が１２××××××とあらわされ、領域Ａ１３が１３××××××とあらわされる。

レベル２のルーティングでは、ノード装置Ｎ１が存在する領域Ａ１０以外の領域である領域Ａ１１、領域Ａ１２および領域Ａ１３に存在するノード装置を無作為に選んで、そのノード装置のノードＩＤアドレスとＩＰアドレスをノード装置Ｎ１のＲＡＭ等の記憶部に記憶する。例えば、レベル２のルーティングテーブルは図７のようになる。レベル２のルーティングテーブルの１列目は、領域Ａ１０に存在するノード装置Ｎ１自身をあらわしている。２列目では領域Ａ１１のノード装置としてノード装置Ｎ４を選択しているので、ノード装置Ｎ４のノードＩＤアドレス（１１３２０１０１）とノード装置Ｎ４のＩＰアドレスとをルーティングテーブルの２列目に対応付けて記憶する。次に、領域Ａ１２のノード装置としてノード装置Ｎ５を選択しているので、ノード装置Ｎ５のノードＩＤアドレス（１２０２０２３０）とノード装置Ｎ５のＩＰアドレスとを対応付けて３列目に記憶する。次に領域Ａ１３のノード装置としてノード装置Ｎ６を選択しているので、ノード装置Ｎ６のノードＩＤアドレス（１３２１０００１）とノード装置Ｎ６のＩＰアドレスとを対応付けて４列目に記憶する。このように領域Ａ１０から領域Ａ１３の各領域にノード装置が存在する場合には、自己のノード装置Ｎ１が存在しない各領域の少なくとも一つのノード装置のノードＩＤアドレスとノードＩＰアドレスを組み合わせて記憶部に記憶する。

[１．３．３ レベル３のルーティング]
次に、図６に示された自己のノード装置であるノード装置Ｎ１が存在する領域Ａ１０をさらに４分割する。領域Ａ１０が４分割された状態を図８にあらわす。４分割されたそれぞれの領域は、４進数で表現すると、領域Ａ１００が１００×××××（×は０乃至３までのいずれかの値である。）とあらわされ、領域Ａ１０１が１０１×××××とあらわされ、領域Ａ１０２が１０２×××××とあらわされ、領域Ａ１０３が１０３×××××とあらわされる。

レベル３のルーティングでは、ノード装置Ｎ１が存在する領域Ａ１００以外の領域である領域Ａ１０１、領域Ａ１０２および領域Ａ１０３に存在するノード装置を無作為に選んで、そのノード装置のノードＩＤアドレスとＩＰアドレスをノード装置Ｎ１のＲＡＭ等の記憶部に記憶する。例えば、レベル３のルーティングテーブルは図９のようになる。レベル３のルーティングテーブルの１列目では領域Ａ１００のノード装置としてノード装置Ｎ７を選択しているので、ノード装置Ｎ７のノードＩＤアドレス（１００００３０２）とノード装置Ｎ７のＩＰアドレスとをルーティングテーブルの２列目に対応付けて記憶する。レベル装置Ｎ３のルーティングテーブルの２列目は、図８からあきらかなように領域Ａ１０１に存在するノードが存在しないために何も書き込まれない。レベル３のルーティングテーブルの３列目は、領域Ａ１０２に存在するノード装置Ｎ１自身をあらわしている。また、レベル３のルーティングテーブルの４列目は、図８からあきらかなように領域Ａ１０３に存在するノードが存在しないために何も書き込まれない。

このように領域Ａ１００から領域Ａ１０３の各領域にノード装置が存在する場合には、自己のノード装置Ｎ１が存在しない各領域の少なくとも一つのノード装置のノードＩＤアドレスとノードＩＰアドレスを組み合わせて記憶しておく。

しかし、本原理説明では、領域Ａ１０１と領域Ａ１０３にはノード装置が存在しないので、領域Ａ１０１と領域Ａ１０３に相当する記憶領域には、ノードＩＤとＩＰアドレスは前述したように何も記載されない。

このようにＩＤノード空間を均等に４分割した場合に、ノード装置が存在しない領域が発生してくる。この場合に、そのノード装置が存在しないノードＩＤ空間領域に対応するコンテンツＩＤがある場合には、その領域の直前の領域に存在するノード装置が前述したルートノードになる。

例えば、コンテンツＩＤが１０１００００１の場合、対応するノードＩＤ空間の領域は、領域Ａ１０１である。しかし、本原理説明では、領域Ａ１０１内にはノード装置が存在しない。したがって、前述したように、コンテンツＩＤ１０１００００１を管理するルートノードは最も近い領域に存在するノード装置Ｎ７になる。すなわちノード装置Ｎ７の記憶部に図３に示されるような、コンテンツＩＤ１０１００００１とコンテンツ情報本体を保持しているノードであるコンテンツホルダのＩＰアドレスが記憶されることになる。

[１．３．４ レベル４移行のルーティング]
以上述べたようにように、ノードＩＤ空間を分割していくに従って、分割されたノードＩＤ空間とその領域に存在するノード装置とが特定されていくことになる。本実施形態では、ノードＩＤは８桁であらわされている。その８桁の最上位の桁をルーティングレベル１としているので、全てのノードＩＤを特定するためには、ルーティングレベル８まで、前述したようにノードＩＤ空間の分割を行えばよいことが分かる。

また、本原理説明において、ルーティングレベル４からルーティングレベル８までの説明は省略するが、ルーティングレベル８までルーティングを行った結果であるルーティングテーブルを図１０に示す。

図１０に示されるルーティングレベル８までのルーティングをノードＩＤ空間に存在する全てのノード装置が行う。そして、各ノード装置が自己のノードＩＤに関してレベル８までのルーティングテーブルをもつよようにする。

[１．４ ルーティングテーブルを使用した検索]
各ノード装置が、レベル８までのルーティングテーブルを使用することによって、コンテンツを保持しているノード装置を効率よく検索することができるようになる。

図１１において、ノードＩＤが１２００３０３０であるノード装置Ｎ８が、コンテンツＩＤが３１３２０１００であるコンテンツ情報の所在を示すインデックス情報を所有するルートノードであるノード装置Ｎ１１（ノードＩＤは３１３２０１００である。）に照会して、コンテンツ所在情報を検索する場合について説明する。

コンテンツＩＤとルートノードのノードＩＤとが一致しない場合があるが、ここの説明においては、コンテンツＩＤ３１３２０１００と一致するノードＩＤを持つノード装置Ｎ１１が存在するものとする。

次に検索手順を説明する。

コンテンツＩＤの値と同じノードＩＤを持つノードＩＤが３１３２０１００のノード装置は、３×××××××の領域に存在する。従って、ノードＩＤが１２００３０３０であるノード装置Ｎ８は、自分が持つルーティングテーブルのレベル１から３×××××××の領域でＩＰアドレスがあらかじめ知られているノード装置を探す。この場合、ノードＩＤが３０１０００００であるノード装置Ｎ９のＩＰアドレスが、自己の持つルーティングテーブルから既知であるので、ノード装置Ｎ９に検索対象コンテンツＩＤについて問い合わせをする（後述の、問い合わせメッセージ（“Ｑｕｅｒｙ”メッセージ）を送信する。）。

ノードＩＤが３０１０００００であるノード装置Ｎ９は、自分が持つルーティングテーブルを参照して、レベル２のルーティングテーブルから、ノードＩＤが３１×××××の領域でＩＰアドレスがあらかじめ知られているノード装置を探す。この場合、ノードＩＤが３１０１２００１であるノード装置Ｎ１０のＩＰアドレスが、自己の持つルーティングテーブルから既知であるので、ノード装置Ｎ１０に検索対象コンテンツＩＤについて問い合わせをする。

ノードＩＤが３１０１２００１であるノード装置Ｎ１０は、自分が持つルーティングテーブルを参照して、レベル３のルーティングテーブルから、ノードＩＤが３１３××××の領域でＩＰアドレスがあらかじめ知られているノード装置を探す。この場合、ノードＩＤが３１３２０１００であるノード装置Ｎ１１のＩＰアドレスが、自己の持つルーティングテーブルから既知であることが分かる。この場合には、ノードＩＤとコンテンツＩＤとが同値であるので、ノード装置Ｎ１１がルートノードであることが分かる。このルートノードは、コンテンツＩＤが３１３２０１００であるコンテンツデータを保持するノード装置のＩＰアドレスを含むインデックス情報を所持している。

この後、ノード装置Ｎ１１は、コンテンツＩＤが３１３２０１００で示されるコンテンツを保持しているノード装置のＩＰアドレスを、検索を開始した先頭のノード装置Ｎ８に知らせる。この結果ノード装置Ｎ８は、紹介されたそのノード装置（コンテンツホルダ）からコンテンツＩＤが３１３２０１００で示されるコンテンツを転送してもらうことができる。

[１．５ ＤＨＴでのコンテンツデータの登録]
上述したＤＨＴにおいて、コンテンツデータをネットワークに登録する場合について説明する。すなわち、あるノード装置が保持するコンテンツデータを、ネットワークに接続された他のノード装置がアクセスできるよう公開する（“Ｐｕｂｌｉｓｈ”すると称する。）場合を、そのコンテンツデータを登録するという。この場合には、当該コンテンツデータを保持するノード装置がコンテンツホルダとなる。このコンテンツホルダは、前述したように、コンテンツデータのタイトル等のコンテンツデータに特有の情報からコンテンツＩＤをノード装置が生成する。

その後、当該コンテンツＩＤと同じ値又は最も近い値を持つルートノードとなるべきノード装置を、当該コンテンツホルダが検索する。例えば、コンテンツホルダから、コンテンツ登録およびルートノード検索メッセージ（“Ｐｕｂｌｉｓｈ”メッセージ）を、コンテンツＩＤに基づいて、ＤＨＴルーティングを使用して検索する。コンテンツ登録メッセージは、前述したＤＨＴルーティングに従って、ノード装置間を転送される。

図１２に示した図において、コンテンツホルダであるノード装置Ｎ１２から発信されたコンテンツ登録メッセージは、ノード装置Ｎ１３およびノード装置Ｎ１４を経由して、コンテンツＩＤと同じ値またはもっとも近いノードＩＤ値を持つルートノードであるノード装置Ｎ１５に到達する。

このルートノードとなったノード装置Ｎ１５は、コンテンツＩＤ、コンテンツＩＤに対応するコンテンツデータを保持するコンテンツホルダのＩＰアドレスおよび補助情報（コンテンツデータのタイトル、ジャンル、作者名などの補助情報）を、インデックス情報として登録する。

各ノード装置は、当該コンテンツＩＤに対応するコンテンツデータを取得する場合には、ＤＨＴルーティングによって、当該コンテンツＩＤに対応するルートノードに問い合わせメッセージ（“Ｑｕｅｒｙ”メッセージ）を発信する。問い合わせメッセージを受信したルートノードは、問い合わせに係わるコンテンツＩＤに対応するコンテンツデータを保持するコンテンツホルダのＩＰアドレスを、問い合わせ元のノード装置に発信する。当該ＩＰアドレスを受信した問い合わせ元のノード装置は、当該ＩＰアドレスであらわされるコンテンツホルダからコンテンツデータを取得する。

[１．６ ＤＨＴでのインデックスキャッシュ]
前述したように、コンテンツＩＤの値とそのコンテンツデータを保持するノード装置のＩＰアドレスとの関係を示す情報であるインデックス情報を保持しているノード装置をルートノードと呼んでいる。このインデックス情報は、ルートノードが一台で保持する必要はない。すなわち、ルーティングテーブルを使用した検索において説明した、図１１に示されたノード装置Ｎ９およびノード装置Ｎ１０がインデックス情報をノード装置Ｎ９およびノード装置Ｎ１０のそれぞれの記憶部に記憶しておくことも可能である。この場合には、ノード装置Ｎ８からの問い合わせメッセージは、ルートノードであるノード装置Ｎ１１まで転送されなくとも、途上のノード装置Ｎ９が返答することで、速やかに処理され、ノード装置Ｎ８は、コンテンツＩＤが３１３２０１００であるコンテンツデータを保持するノード装置のＩＰアドレス情報を、ノード装置Ｎ９から取得することができる。

このような、各ノード装置が所有するインデックス情報を記憶している記憶部を、以下インデックスキャッシュと称する。

詳細について図１２を用いて説明する。

図１２は、ノード装置がインデックス情報を所持するノード装置へ問い合わせる経路をあらわした図である。図１２に示された円Ｃ３は、ＤＨＴのノードＩＤ空間をあらわしており、円Ｃ３上にノード装置Ｎ１２乃至ノード装置Ｎ１８が分散して配置されている。

ノード装置Ｎ１２はコンテンツデータを保持しているノード装置（コンテンツホルダ）である。ノード装置Ｎ１５は、前述したＤＨＴルーティングで検索されるインデックス情報を所有しているルートノードである。ノード装置Ｎ１３は、ノード装置Ｎ１２からノード装置Ｎ１５に至るルーティング経路にあるノード装置である。例えば、レベル１のルーティングにおいてノード装置Ｎ１２から検索されるノード装置である。また、ノード装置Ｎ１４は、ノード装置１３と同様にノード装置Ｎ１２からノード装置Ｎ１５に至るルーティング経路にあるノード装置である。例えば、レベル２のルーティングにおいて、ノード装置Ｎ１３から検索されるノード装置である。ノード装置Ｎ１６、Ｎ１７、Ｎ１９は、コンテンツを取得しようとしているノード（リクエスタ）である。

ノード装置Ｎ１６から、ノード装置Ｎ１２が検索しているコンテンツＩＤを管理するルートノードであるノード装置Ｎ１５に至る経路は、経路Ｋ４、経路Ｋ２および経路Ｋ３である。ノード装置Ｎ１６は、経路Ｋ４を経由して、ノード装置Ｎ１３にコンテンツＩＤを管理しているノード装置を問い合わせる。ノード装置Ｎ１３が特定されるのは、ノード装置Ｎ１６が所有しているＤＨＴのルーティングテーブルにノード装置Ｎ１３が記憶されていることによって特定される。

ノード装置Ｎ１６からルートノードであるノード装置Ｎ１５に至る経路（問い合わせ時の経路）は、ノード装置Ｎ１２からルートノードであるノード装置Ｎ１５に至る経路（登録時の経路）の一部である、経路Ｋ２および経路Ｋ３を共有する。ノード装置Ｎ１３およびノード装置Ｎ１４が保持しているＤＨＴのルーティングテーブルがノード装置Ｎ１２およびノード装置Ｎ１６の問い合わせに対して同じように機能するからである。

別のリクエスタであるノード装置Ｎ１７に目を転ずると、ノード装置Ｎ１７から、ノード装置Ｎ１２が検索しているコンテンツＩＤを管理しているルートノードであるノード装置Ｎ１５に至る経路は、経路Ｋ５、経路Ｋ６および経路Ｋ３である。ノード装置Ｎ１７からノード装置Ｎ１８に至る経路Ｋ５は、ノード装置Ｎ１７が所有しているルーティングテーブルによって決定される。また、ノード装置Ｎ１８からノード装置Ｎ１４に至る経路Ｋ６は、ノード装置Ｎ１８が所有しているルーティングテーブルによって決定される。

ノード装置Ｎ１７からルートノードであるノード装置Ｎ１５に至る経路（問い合わせ時の経路）は、ノード装置Ｎ１２からルートノードであるノード装置Ｎ１５に至る経路（登録時の経路）の一部である、経路Ｋ３を共有する。ノード装置Ｎ１４が保持しているＤＨＴのルーティングテーブルがノード装置Ｎ１２およびノード装置Ｎ１７の問い合わせに対して同じように機能するからである。

図１３は、コンテンツホルダであるノード装置Ｎ１２からルートノードであるノード装置Ｎ１５に至る経路を直線としてあらわし、その直線に図１２における各ノード装置と経路を加えた図である。

図１３は、“Ｐｕｂｌｉｓｈ”されたコンテンツデータ（コンテンツホルダＮ１２に保持されている）を取得しようとするノード装置（リクエスタ）Ｎ１６、Ｎ１７、およびＮ１８が、問い合わせメッセージ（“Ｑｕｅｒｙ”メッセージ）は、ルートノードに近づくに従って、コンテンツ登録メッセージ（“Ｐｕｂｌｉｓｈ”メッセージ）と同じ経路を経由するようになる。これらの経路が、一種の木構造に見えるので、図１３にあらわされた経路構造のツリーを“スパニングツリー”と呼ぶ。

インデックス情報を所有するノード装置はルートノードであるノード装置Ｎ１５だけが保持していてもよいが、経路が共通する始端であるノード装置Ｎ１３およびノード装置Ｎ１４もルートノードであるノード装置Ｎ１５が所有しているインデックス情報と同じ情報をインデックスキャッシュに所有することにより、問い合わせ情報の通信量を減らすことができる。コンテンツの登録時に、当該インデックス情報は、転送されてノード装置Ｎ１３、Ｎ１４を通過するので、この情報をノード装置Ｎ１３、Ｎ１４が記憶しておく（キャッシュしておく）ことは、容易に行える。

この場合には、ノード装置Ｎ１６からノード装置１５までの経路Ｋ４、経路Ｋ２および経路Ｋ３のうち、経路Ｋ２および経路Ｋ３にメッセージを転送する必要がなくなる。経路Ｋ４の終端にあるノード装置Ｎ１３がインデックス情報を記憶するインデックスキャッシュを所有するからである。すなわち、ノード装置Ｎ１６は所望のコンテンツを所有するノード装置Ｎ１２のＩＰアドレスを、ノード装置Ｎ１３から取得することができる。

具体的には、ノード装置Ｎ１６からノード装置Ｎ１３に問い合わせられたコンテンツのＩＰアドレスは、ノード装置Ｎ１３のインデックスキャッシュから経路Ｋ８を経由してノード装置Ｎ１６に返信される。

また、ノード装置Ｎ１７からノード装置１５までの経路Ｋ５、経路Ｋ６および経路Ｋ３のうち、経路Ｋ３にメッセージを転送する必要がなくなる。経路Ｋ６の終端にあるノード装置Ｎ１４がインデックス情報を記憶するインデックスキャッシュを所有するからである。すなわち、ノード装置Ｎ１７は所望のコンテンツを所有するノード装置Ｎ１２のＩＰアドレスを、ノード装置Ｎ１４から取得することができる。

具体的には、ノード装置Ｎ１７からノード装置Ｎ１４に問い合わせられたコンテンツのＩＰアドレスは、ノード装置Ｎ１４のインデックスキャッシュから経路Ｋ９を経由してノード装置Ｎ１７に返信される。

以上説明したように、ルートノードに至る途中のノード装置がルートノードに所有されているインデックス情報と同じ情報をインデックスキャッシュに記憶する。このようにすると、所望のコンテンツデータを保持しているノードＩＤのＩＰアドレスを、各ノード装置が素早く取得することができる。

また、図１３における経路Ｋ２および経路Ｋ３の情報伝達量が減るので、経路Ｋ２および経路Ｋ３を使用する他の情報の伝達速度が向上し、システム全体としての情報伝達効率が向上する。

[１．７ インデックスキャッシュの更新]
複数のノード装置で、あるコンテンツに対する同じ内容であるインデックス情報をインデックスキャッシュに所有するためには，インデックスキャッシュは適切に更新される必要がある。コンテンツデータを保持しているノード装置がネットワークに接続されなくなった場合にもかかわらず、インデックスキャッシュを検索した場合に、存在しなくなったコンテンツデータを保持していたＩＰアドレスを問い合わせ元のノード装置に返信すると不都合だからである。すなわち、存在しなくなったコンテンツデータを検索する無駄な情報のやりとりが発生するのである。

インデックスキャッシュを更新して、あるコンテンツデータに関する各インデックスキャッシュの内容が合っている状態をコヒーレントと称する。また、あるコンテンツデータに関する各インデックスキャッシュの内容が合っていない状態をインコヒーレントと称する。インコヒーレントな状態は、なるべく短い期間であることが、ノード装置が相互にネットワークとして接続されたシステムにとって望ましいのである。

しかし、インデックスキャッシュの内容を頻繁に確認していたのでは、システム全体に無駄な情報のやりとりが発生してしまい、システム全体に情報確認のために負荷が余分にかかってしまうことになる。この負荷が余分にかかる状態は、インデックスキャッシュを保持するノード装置が増えるほど顕著になる。

具体的には、コヒーレントな状態を保つために、コヒーレントを確認するメッセージ等の情報のやりとりが大量に発生することにより、その他の情報のやりとりに時間がかかってしまうという不具合が発生してしまう。

[２．１ 本願の実施形態（インデックスキャッシュの更新）]
次に、図１４乃至図１９を用いて、本実施形態について説明する。本実施形態は、同一のコンテンツデータに関するインデックス情報をインデックスキャッシュに記憶するノード装置（キャッシュノード）から、そのコンテンツを有するノード装置（コンテンツホルダ）に対する問い合わせのタイミングをキャッシュノードごとに変化させるものである。例えば、コンテンツホルダからルートノードに至る経路に存在するキャッシュノードから、コンテンツホルダへの問い合わせの頻度を、コンテンツホルダからの距離によって変化させる。

図１４は、ＤＨＴによるルートノードの検索およびコヒーレント確認方法の様子の一例を示す図である。図１４には、あるコンテンツを有するコンテンツホルダＣＨ、コンテンツホルダＣＨのＩＰアドレスとコンテンツＩＤとをインデックス情報として所有するルートノードＲＮ１、インデックス情報を記憶するインデックスキャッシュを所有するキャッシュノードＣＮ１、ＣＮ２およびＣＮ３、コンテンツホルダＣＨのＩＰアドレスを取得しようとするノード装置であるリクエスタＲＱ１、ＲＱ２、ＲＱ３、ＲＱ４およびＲＱ５、およびリクエスタからのコンテンツホルダＣＨのＩＰアドレスを取得しようとする情報を転送するノード装置Ｎ２０、Ｎ２１およびＮ２２があらわされている。

ルートノードＲＮ１および各キャッシュノードからコンテンツホルダＣＨに対して、コンテンツホルダＣＨがネットワークに接続されているか否かを確認する経路は、経路ＳＫ１、経路ＳＫ２、経路ＳＫ３および経路ＳＫ４であらわされている。各経路は、図１の下部枠１０１内において示されるインターネット等のネットワーク（現実世界のネットワーク）によって構成されている。ここでは、当該インターネット等のネットワークが実現されている構成による経路ではなく、図１上部枠１００のオーバレイネットワークの経路について説明する。

経路ＳＫ１は、ルートノードＲＮ１がコンテンツホルダＣＨに対して、コンテンツデータの存在確認をする経路である。例えば、コンテンツデータの存在確認をするためには、生存確認メッセージ（“Ｃｏｎｆｉｒｍ”と称する）等の情報をルートノードＲＮ１からコンテンツホルダＣＨに、ネットワークを介して伝送する。

すなわち、経路ＳＫ１を使用したコヒーレント状態の確認は、ルートノードＲＮ１から発信された生存確認メッセージが、コンテンツホルダＣＨに到着し、その後コンテンツホルダＣＨから正常な応答メッセージ（“Ａｌｉｖｅ”と称する）等の情報がルートノードＲＮ１に到着するか否かによってコヒーレント状態の確認が行われる。

例えば、コンテンツホルダＣＨがネットワークに接続されていない場合には、ルートノードＲＮ１から発信された生存確認メッセージ（“Ｃｏｎｆｉｒｍ”）が、その行き先がみつからないため、ルートノードＲＮ１には正常な応答メッセージ（“Ａｌｉｖｅ”）が戻って来ない。このことにより、ルートノードＲＮ１はコンテンツホルダＣＨがネットワークに接続されていないという情報を取得する。

この場合には、ルートノードＲＮ１は、ルートノードＲＮ１に記憶されているコンテンツデータに対応するインデックス情報を削除する。

また、コンテンツホルダＣＨがネットワークに接続されている場合であって、コンテンツホルダＣＨがコンテンツデータをすでに保持していない場合にも、ルートノードＲＮ１には正常な応答メッセージ（“Ａｌｉｖｅ”）が戻って来ない。このことにより、ルートノードＲＮ１は、コンテンツデータがコンテンツホルダＣＨに存在しないという情報を取得する。または、コンテンツホルダＣＨが、コンテンツデータがコンテンツホルダＣＨにはもうありませんという旨の情報を、ルートノードＲＮ１に返信することもできる。

この場合にも、ルートノードＲＮ１は、ルートノードＲＮ１に記憶されているコンテンツデータに対応するインデックス情報を削除する。

さらに、コンテンツデータを保持するコンテンツホルダＣＨがネットワークに正常に接続されている場合には、コンテンツデータが正常に存在する応答情報（“Ａｌｉｖｅ”）をルートノードＲＮ１が取得する。

この場合には、ルートノードＲＮ１は、ルートノードＲＮ１に記憶されているインデックス情報を削除しない。

次に経路ＳＫ２について説明する。経路ＳＫ２は、キャッシュノードＣＮ３がコンテンツホルダＣＨに対して、コンテンツデータの存在確認をする経路である。

例えば、コンテンツデータの存在確認をするためには、生存確認メッセージ等の情報をキャッシュノードＣＮ１からコンテンツホルダＣＨに、ネットワークを介して伝送する。

すなわち、経路ＳＫ２を使用したコヒーレント状態の確認は、キャッシュノードＣＮ３から発信された生存確認メッセージが、コンテンツホルダＣＨに到着し、その後コンテンツホルダＣＨから正常な応答メッセージ等の情報がキャッシュノードＣＮ３に到着するか否かによってコヒーレント状態の確認が行われる。

例えば、コンテンツホルダＣＨがネットワークに接続されていない場合には、キャッシュノードＣＮ３から発信された生存確認メッセージが、その行き先がみつからないため、キャッシュノードＣＮ３には正常な応答メッセージが戻って来ない。このことにより、キャッシュノードＣＮ３はコンテンツホルダＣＨがネットワークに接続されていないという情報を取得する。

この場合には、キャッシュノードＣＮ３は、キャッシュノードＣＮ３に記憶されているコンテンツデータに対応するインデックス情報を削除する。

また、コンテンツホルダＣＨがネットワークに接続されている場合であって、コンテンツホルダＣＨがコンテンツデータをすでに保持していない場合にも、キャッシュノードＣＮ３には正常な応答メッセージが戻って来ない。（あるいは、コンテンツが存在しないという旨の応答メッセージが戻る。）したがって、キャッシュノードＣＮ３は、コンテンツデータがコンテンツホルダＣＨに存在しないという情報を取得する。

この場合にも、キャッシュノードＣＮ３は、キャッシュノードＣＮ３に記憶されているコンテンツデータに対応するインデックス情報を削除する。

さらに、コンテンツデータを保持するコンテンツホルダＣＨがネットワークに正常に接続されている場合には、コンテンツデータが正常に存在する応答情報をキャッシュノードＣＮ３が取得する。

この場合には、キャッシュノードＣＮ３は、キャッシュノードＣＮ３に記憶されているコンテンツデータに対応するインデックス情報を削除しない。

経路ＳＫ３および経路ＳＫ４は、経路ＳＫ１および経路ＳＫ２と同様に、キャッシュノードＣＮ２およびキャッシュノードＣＮ１が、コンテンツホルダＣＨに生存確認メッセージ等の情報を送受信する経路である。

すなわち、キャッシュノードＣＮ２またはキャッシュノードＣＮ１から送信された生存確認メッセージに対して、コンテンツホルダＣＨから正常な応答情報である応答メッセージが送信され、キャッシュノードＣＮ２またはキャッシュノードＣＮ１がその応答メッセージを受信した場合には、キャッシュノードＣＮ２またはキャッシュノードＣＮ１はコンテンツデータに対応したインデックス情報を削除および書き換えを行わない。

また、キャッシュノードＣＮ２またはキャッシュノードＣＮ１が正常な応答メッセージを受信しない場合には、キャッシュノードＣＮ２またはキャッシュノードＣＮ１は発信された生存確認メッセージに対応するコンテンツデータのインデックス情報を削除する。

次に、図１４に示されている経路ＳＫ５、経路ＳＫ６、経路ＳＫ７および経路ＳＫ８について説明する。

経路ＳＫ５はルートノードＲＮ１とキャッシュノードＣＮ３との間でメッセージ等の情報が伝送される経路である。

例えば、キャッシュノードＣＮ３からコンテンツホルダＣＨに対して、生存確認メッセージ（“Ｃｏｎｆｉｒｍ”）が送信された後に、コンテンツホルダＣＨから応答メッセージ（“Ａｌｉｖｅ”）が送信されないために、キャッシュノードＣＮ３が応答メッセージ（“Ａｌｉｖｅ”）を受信しない場合がある。この場合には、キャッシュノードＣＮ３は、該当するコンテンツデータのインデックス情報を削除する。

キャッシュノードＣＮ３とルートノードＲＮ１とのコヒーレント状態を保つ為には、それぞれのノード装置がコンテンツホルダＣＨに生存確認メッセージ（“Ｃｏｎｆｉｒｍ”）を送信するだけではなく、上述した場合のように、キャッシュノードＣＮ３が応答メッセージ（“Ａｌｉｖｅ”）を受信しない場合には、その情報をルートノードＲＮ１に経路ＳＫ５を経由して伝えてもよい。

例えば、キャッシュノードＣＮ３は、コンテンツデータがコンテンツホルダＣＨに存在しなくなったことを示す消滅メッセージ（“Ｖａｎｉｓｈ”と称する。）をルートノードＲＮ１に発信する。消滅メッセージを受信したルートノードＲＮ１は、当該コンテンツデータに関するインデックス情報をルートノードＲＮ１のインデックスキャッシュから削除する。

また、ルートノードＲＮ１からコンテンツノードＣＨに生存確認メッセージを発信した後に、コンテンツノードＣＨから応答メッセージを受信しなかった場合には、ルートノードＲＮ１は、コンテンツデータがコンテンツホルダＣＨに存在しなくなったことを示す消滅メッセージ（“Ｖａｎｉｓｈ”と称する。）をキャッシュノードＣＮ３に発信する。消滅メッセージを受信したキャッシュノードＣＮ３は、当該コンテンツデータに関するインデックス情報をキャッシュノードＣＮ３のインデックスキャッシュから削除する。

このように、コンテンツホルダＣＨから応答メッセージを受信しなかった、キャッシュノードＣＮ３またはルートノードＲＮ１が、相互に消滅メッセージを送信しあうことで、あるコンテンツに対するインデックス情報のインコヒーレント状態をできるだけ早く解消し、コヒーレント状態を保つことができる。

経路ＳＫ６はキャッシュノードＣＮ３とキャッシュノードＣＮ２との間でメッセージ等の情報が伝送される経路である。

例えば、キャッシュノードＣＮ２からコンテンツホルダＣＨに対して、生存確認メッセージ（“Ｃｏｎｆｉｒｍ”）が送信された後に、コンテンツホルダＣＨから応答メッセージ（“Ａｌｉｖｅ”）が送信されないために、キャッシュノードＣＮ２が応答メッセージ（“Ａｌｉｖｅ”）を受信しない場合がある。この場合には、キャッシュノードＣＮ２は、該当するコンテンツデータのインデックス情報を削除する。

キャッシュノードＣＮ２とキャッシュノードＣＮ３とのコヒーレント状態を保つ為には、それぞれのノード装置がコンテンツホルダＣＨに生存確認メッセージ（“Ｃｏｎｆｉｒｍ”）を送信するだけではなく、上述した場合のように、キャッシュノードＣＮ２が応答メッセージ（“Ａｌｉｖｅ”）を受信しない場合には、その情報をキャッシュノードＣＮ３に経路ＳＫ４を経由して伝えてもよい。

例えば、キャッシュノードＣＮ２は、コンテンツデータがコンテンツホルダＣＨに存在しなくなったことを示す消滅メッセージをキャッシュノードＣＮ３に発信する。消滅メッセージを受信したキャッシュノードＣＮ３は、当該コンテンツデータに関するインデックス情報をキャッシュノードＣＮ３のインデックスキャッシュから削除する。

また、キャッシュノードＣＮ３からコンテンツノードＣＨに生存確認メッセージを発信した後に、コンテンツノードＣＨから応答メッセージを受信しなかった場合には、キャッシュノードＣＮ３は、コンテンツデータがコンテンツホルダＣＨに存在しなくなったことを示す消滅メッセージをキャッシュノードＣＮ２に発信する。消滅メッセージを受信したキャッシュノードＣＮ２は、当該コンテンツデータに関するインデックス情報をキャッシュノードＣＮ２のインデックスキャッシュから削除する。

このように、コンテンツホルダＣＨから応答メッセージを受信しなかった、キャッシュノードＣＮ２またはキャッシュノードＣＮ３が、相互に消滅メッセージを送信しあうことで、あるコンテンツに対するインデックス情報のインコヒーレント状態をできるだけ早く解消し、コヒーレント状態を保つことができる。

経路ＳＫ７および経路ＳＫ８においても、上記と同様のメッセージの送受信が行われる。

経路ＳＫ７において、キャッシュノードＣＮ２またはキャッシュノードＣＮ１がコンテンツホルダＣＨから応答メッセージを受信しなかった場合には、キャッシュノードＣＮ２またはキャッシュノードＣＮ１が、キャッシュノードＣＮ１またはキャッシュノードＣＮ２に対して消滅メッセージを送信する。つまり、キャッシュノードＣＮ２は、キャッシュノードＣＮ１に対して消滅メッセージを送信する。キャッシュノードＣＮ１は、該当するコンテンツに対するインデックス情報を、キャッシュノードＣＮ１のインデックスキャッシュから削除する。また、キャッシュノードＣＮ１は、キャッシュノードＣＮ２に対して消滅メッセージを送信する。キャッシュノードＣＮ２は、該当するコンテンツに対するインデックス情報を、キャッシュノードＣＮ２のインデックスキャッシュから削除する。

このように、コンテンツホルダＣＨから応答メッセージを受信しなかった、キャッシュノードＣＮ１またはキャッシュノードＣＮ２が、相互に消滅メッセージを送信しあうことで、あるコンテンツデータに対するインデックス情報のインコヒーレント状態をできるだけ早く解消し、コヒーレント状態を保つことができる。

次に、経路ＳＫ８について説明する。コンテンツホルダＣＨの電源が切られた場合等のネットワークとの接続がなくなった場合には、コンテンツホルダＣＨがネットワークから離脱することになる。この場合に、キャシュノードＣＮ１がコンテンツホルダＣＨに関するインデックス情報を持ち続けてしまうと、インコヒーレントな状態が続くので、好ましくない。そこで、コンテンツホルダＣＨがネットワークから離脱する場合には、コンテンツホルダＣＨから消滅メッセージをキャッシュノードＣＮ１に発信する。キャッシュノードＣＮ１は、該当するコンテンツに対するインデックス情報を、キャッシュノードＣＮ１のインデックスキャッシュから削除する。このように、コンテンツホルダＣＨが保持していたコンテンツデータに対するインデックス情報のインコヒーレント状態をできるだけ早く解消し、コヒーレント状態を保つことができる。

上述したように、消滅メッセージは、経路ＳＫ５、ＳＫ６、ＳＫ７またはＳＫ８を経由して、キャッシュノードＣＮ１、ＣＮ２並びにＣＮ３、およびルートノードＲＮ１の間を自由に転送されることができる。

例えば、キャッシュノードＣＮ１が消滅メッセージを受信した場合には、キャッシュノードＣＮ１からキャッシュノードＣＮ２に当該消滅メッセージが転送される。さらに、キャッシュノードＣＮ２からキャッシュノードＣＮ３に当該消滅メッセージが転送される。そして、キャッシュノードＣＮ３からルートノードＲＮ１に当該消滅メッセージが転送される。このように、キャッシュノードＣＮ１が受信した消滅メッセージはルートノードＲＮ１へ転送されることになる。このようにして経路上の全てのノード装置において、該当するコンテンツに対するインデックス情報をインデックスキャッシュから削除する。

また、例えば、キャッシュノードＣＮ２が消滅メッセージを受信した場合には、キャッシュノードＣＮ２からキャッシュノードＣＮ３に当該消滅メッセージが転送される。さらに、キャッシュノードＣＮ３からルートノードＲＮ１に当該消滅メッセージが転送される。さらに、キャッシュノードＣＮ２は、ルートノードＲＮ１と逆方向にあるキャッシュノードＣＮ１にも、当該消滅メッセージを転送する。このようにして経路上の全てのノード装置において、該当するコンテンツに対するインデックス情報をインデックスキャッシュから削除する。

なお、下流のキャッシュノードのＩＰアドレスを知るためには、登録時に、公開メッセージがコンテンツホルダからキャッシュノードを中継してルートノードに転送される過程で、各キャッシュノードがメッセージの送信元のＩＰアドレスを記憶（スパニングツリーの逆方向リンクを記憶）しておくことで、実現できる。

次にインデックスキャッシュの内容について説明する。

図１５にルートノードＲＮ１、キャッシュノードＣＮ３、キャッシュノードＣＮ２およびキャッシュノードＣＮ１がインデックスキャッシュに記憶している内容の一例を示す。

図１５（ａ）は、コンテンツＩＤが５４ＤＥ９８７８（１６進表示）である“タイタニック”というコンテンツデータについて、ルートノードＲＮ１がインデックスキャッシュに保持している内容である。図１５（ａ）の１列目はコンテンツＩＤを示し、２列目は、コンテンツホルダＣＨのＩＰアドレスを示す。また、図１５（ａ）の４列目はコンテンツデータのタイトルを示し、５列目は、コンテンツデータのジャンルを示す。

図１５（ａ）の３列目は転送数を示す。転送数とは、コンテンツホルダＣＨから発信されたメッセージが幾つのキャッシュノードを経由しているかを示す数である。コンテンツホルダＣＨからルートノードＲＮ１にメッセージが発信された場合には、メッセージはキャッシュノード１、キャッシュノード２およびキャッシュノード３を経由してルートノードＲＮ１に受信される。コンテンツホルダＣＨからルートノードＲＮ１までにメッセージが経由したキャシュノードは３つになるので、転送数は３となる。したがって、ルートノードＲＮ１のインデックスキャッシュの内容を示した図１５（ａ）の３列目の転送数は３となる。

例えば、コンテンツ登録メッセージにカウンタを設け、各キャッシュノードで、コンテンツ登録メッセージを転送するたびに、カウンタ値を１つ増加させることによって実現できる。

次に、キャッシュノード３のインデックスキャッシュの内容を図１５（ｂ）に示す。図１５（ｂ）の１列目、２列目、４列目および５列目の内容は、ルートノードＲＮ１のインデックスキャッシュの内容を示す図１５（ａ）と同じである。コンテンツホルダＣＨからキャシュノードＣＮ３にコンテンツ登録メッセージが発信された場合には、メッセージはキャッシュノード１およびキャッシュノード２を経由してキャシュノードＣＮ３に受信される。コンテンツホルダＣＨからキャッシュノードＣＮ３までにメッセージが経由したキャッシュノードは２つになるので、転送数は２となる。したがって、キャッシュノードＣＮ３のインデックスキャッシュの内容を示した図１５（ｂ）の２列目の転送数は２となる。

次に、キャッシュノード２のインデックスキャッシュの内容を図１５（ｃ）に示す。図１５（ｃ）の１列目、２列目、４列目および５列目の内容は、ルートノードＲＮ１のインデックスキャッシュの内容を示す図１５（ａ）と同じである。コンテンツホルダＣＨからキャシュノードＣＮ２にコンテンツ登録メッセージが発信された場合には、メッセージはキャッシュノード１を経由してキャシュノードＣＮ２に受信される。コンテンツホルダＣＨからキャッシュノードＣＮ２までにメッセージが経由したキャッシュノードは１つになるので、転送数は１となる。したがって、キャッシュノードＣＮ２のインデックスキャッシュの内容を示した図１５（ｃ）の２列目の転送数は１となる。

次に、キャッシュノード１のインデックスキャッシュの内容を図１５（ｄ）に示す。図１５（ｄ）の１列目、２列目、４列目および５列目の内容は、ルートノードＲＮ１のインデックスキャッシュの内容を示す図１５（ａ）と同じである。コンテンツホルダＣＨからキャシュノードＣＮ１にコンテンツ登録メッセージが発信された場合には、メッセージは直接キャシュノードＣＮ１に受信される。コンテンツホルダＣＨからキャッシュノードＣＮ１までにメッセージが経由したキャッシュノードは一つもないので、転送数は０となる。したがって、キャッシュノードＣＮ２のインデックスキャッシュの内容を示した図１５（ｄ）の２列目の転送数は０となる。

次に、ルートノードＲＮ１、キャッシュノードＣＮ３、キャッシュノードＣＮ２およびキャッシュノードＣＮ１から、コンテンツホルダＣＨに対して生存確認
メッセージを発信するタイミングについて説明する。生存確認メッセージが頻繁に発信されると、コヒーレント状態の確認のためにネットワークに負荷がかかりすぎるので、ネットワークが効率的に利用されない。そこで、生存確認メッセージを発信するノード装置からコンテンツホルダＣＨまでの転送数に対応して、ノード装置から生存確認メッセージを発信させる頻度を変化させる。

例えば、式（１）に示すように生存確認メッセージの発信間隔ＰＩを決める。

（数１）
ＰＩ＝４⁽転送数⁾×１０分 ・・・ （式１）
キャッシュノードＣＮ１の転送数は０なので、ＰＩの値は１０分となる。従って、キャッシュノードＣＮ１からキャッシュホルダＣＨへの生存確認メッセージは１０分間隔で発信される。

また、キャッシュノードＣＮ２の転送数は１なので、ＰＩの値は４０分となる。従って、キャッシュノードＣＮ１からキャッシュホルダＣＨへの生存確認メッセージは４０分間隔で発信される。

さらに、キャッシュノードＣＮ３の転送数は２なので、ＰＩの値は１６０分となる。従って、キャッシュノードＣＮ１からキャッシュホルダＣＨへの生存確認メッセージは１６０分間隔で発信される。

さらに、ルートノードＲＮ１の転送数は３なので、ＰＩの値は６４０分となる。従って、キャッシュノードＣＮ１からキャッシュホルダＣＨへの生存確認メッセージは６４０分間隔で発信される。

このようにして、経路ＳＫ１、経路ＳＫ２、経路ＳＫ３および経路ＳＫ４を経由して、コンテンツホルダＣＨに生存確認メッセージを送信する頻度を変化させることによってネットワークの負荷の軽減を図っている。

[２．２ 実施形態の動作をあらわすフローチャートの説明]
図１６、図１７、図１８および図１９は、本実施形態の動作をあらわすフローチャートである。

図１６は、メッセージの内容を分類するフローチャートである。図１７は、Ｐｕｂｌｉｓｈメッセージの処理をあらわすフローチャートである。図１８は、Ｖａｎｉｓｈメッセージの処理をあらわすフローチャートである。図１９は、タイマーによる処理をあらわすフローチャートである。

各ノード装置は、コンテンツデータを取得しようとするノード装置であるリクエスタ、コンテンツデータを保持するコンテンツホルダおよびインデックス情報を所有するルートノードのいずれとしても機能するので、図１６乃至図１９を用いて、各種メッセージの処理を説明する。

最初に図１６について説明する。図１６はメッセージの内容を分類するフローチャートである。

ステップＳ１において、ノード装置は、メッセージを読み取る。

ステップＳ２において、受信したメッセージが“Ｐｕｂｌｉｓｈ”メッセージであるか否かを判断する。受信したメッセージが“Ｐｕｂｌｉｓｈ”メッセージである場合（ステップＳ２：ＹＥＳ）には、ステップＳ３に進む。受信したメッセージが“Ｐｕｂｌｉｓｈ”メッセージでない場合（ステップＳ２：ＮＯ）には、ステップＳ４に進む。

ステップＳ３において、“Ｐｕｂｌｉｓｈ”メッセージの処理を行う。“Ｐｕｂｌｉｓｈ”メッセージの処理内容は図１７において詳細に説明する。

ステップＳ４において、受信したメッセージが“Ｃｏｎｆｉｒｍ”メッセージであるか否かを判断する。受信したメッセージが“Ｃｏｎｆｉｒｍ”メッセージである場合（ステップＳ４：ＹＥＳ）には、ステップＳ５に進む。受信したメッセージが“Ｃｏｎｆｉｒｍ”メッセージでない場合（ステップＳ４：ＮＯ）には、ステップＳ６に進む。

ステップＳ５において、応答メッセージである“Ａｌｉｖｅ”メッセージの送信を行う。この“Ａｌｉｖｅ”メッセージの送信を行うノード装置は、コンテンツホルダとして機能している場合であって、問い合わせにかかわるコンテンツを保持している場合である。

ステップＳ６において、受信したメッセージが“Ｖａｎｉｓｈ”メッセージであるか否かを判断する。受信したメッセージが“Ｖａｎｉｓｈ”メッセージである場合（ステップＳ６：ＹＥＳ）には、ステップＳ７に進む。受信したメッセージが“Ｖａｎｉｓｈ”メッセージでない場合（ステップＳ６：ＮＯ）には、ステップＳ８に進む。

ステップＳ７において、“Ｖａｎｉｓｈ”メッセージの処理を行う。“Ｖａｎｉｓｈ”メッセージの処理内容は図１８において詳細に説明する。

ステップＳ８において、受信したメッセージが“Ｐｕｂｌｉｓｈ”メッセージ、“Ｃｏｎｆｉｒｍ”メッセージおよび“Ｖａｎｉｓｈ”メッセージのいずれでもない場合には、その他のメッセージ処理を行う。その他のメッセージとしては、コンテンツホルダの場所を問い合わせるメッセージ（“Ｑｕｅｒｙ”メッセージ）などがある。“Ｑｕｅｒｙ”メッセージの場合には、“Ｑｕｅｒｙ”メッセージを受信したノード装置が所有するルーティングテーブルから、コンテンツＩＤに対応したノード装置を選択して、選択されたノード装置に“Ｑｕｅｒｙ”メッセージを送信する。また、“Ｑｕｅｒｙ”メッセージを受信したノード装置がルートノードである場合には、“Ｑｕｅｒｙ”メッセージを最初に発信したノード装置に対して“Ｑｕｅｒｙ”メッセージに対応するコンテンツデータを保持するコンテンツホルダのＩＰアドレスを含むメッセージを送信する。

次に、図１７について説明する。図１７は、Ｐｕｂｌｉｓｈメッセージの処理をあらわすフローチャートである。

ステップＳ１０において、ノード装置が受信したメッセージ情報に含まれるコンテンツＩＤ（ｃＩＤ）、ＩＰアドレス、転送数（“Ｐｕｂｌｉｓｈ”メッセージが経由したキャッシュノードの数）をノード装置の記憶部に記憶する。

ステップＳ１１において、転送数からコヒーレンシ確認（コヒーレント状態であるか、インコヒーレント状態であるかの確認）のための時間間隔を算出する。時間間隔は、式１に示された計算式に従って算出される。

ステップＳ１２において、ステップＳ１１において算出されたコヒーレンシ確認時間間隔後にタイマーイベントが発生するように、タイマーを設定する。

ステップＳ１３において、コンテンツＩＤと自ノード装置のノードＩＤとを比較して、上位の桁から何桁まで同値であるか比較する。それによって、自ノード装置が所有するルーティングテーブルのどのレベルからメッセージを転送すべきノード装置を選択すべきかについて判断する。

ステップＳ１４において、ステップＳ１３において判断されたレベルとコンテンツＩＤとから、受信した“Ｐｕｂｌｉｓｈ”メッセージを転送すべきノード装置を決定する。

ステップＳ１５において、転送先ノード装置が自ノード装置であるか否かを判断する。転送先ノード装置が自ノード装置である場合（ステップＳ１５：ＹＥＳ）には、ステップＳ１８に進む。転送先ノード装置が自ノード装置ではない場合（ステップＳ１５：ＮＯ）には、ステップＳ１６に進む。

ステップＳ１６において、“Ｐｕｂｌｉｓｈ”メッセージ中に記録されている転送数を１増加させる。

ステップＳ１７において、ステップＳ１４において選択されたノード装置に対して、“Ｐｕｂｌｉｓｈ”メッセージを転送する。

ステップＳ１８において、自ノード装置は、ルートノードになるべきノード装置であるので、“Ｐｕｂｌｉｓｈ”メッセージの内容を自ノード装置のインデックスキャッシュに追加記録する。

次に、図１８について説明する。図１８は、Ｖａｎｉｓｈメッセージの処理をあらわすフローチャートである。

ステップＳ２０において、ノード装置が受信したメッセージ情報に含まれるコンテンツＩＤ（ｃＩＤ）およびＩＰアドレスに該当する情報をノード装置のインデックスキャッシュから削除する。

ステップＳ２１において、コンテンツＩＤと自ノード装置のノードＩＤとを比較して、上位の桁から何桁まで同値であるか比較する。それによって、自ノード装置が所有するルーティングテーブルのどのレベルからメッセージを転送すべきノード装置を選択すべきかについて判断する。

ステップＳ２２において、ステップＳ２１において判断されたレベルとコンテンツＩＤとから、受信した“Ｖａｎｉｓｈ”メッセージを転送すべきノード装置を決定する。

ステップＳ２３において、転送先ノード装置が自ノード装置であるか否かを判断する。転送先ノード装置が自ノード装置である場合（ステップＳ２３：ＹＥＳ）には、ステップＳ２５に進む。転送先ノード装置が自ノード装置ではない場合（ステップＳ２３：ＮＯ）には、ステップＳ２４に進む。

ステップＳ２４において、ステップＳ２２において選択されたノード装置に対して、“Ｖａｎｉｓｈ”メッセージを転送する。

ステップＳ２５において、ルートノードである自ノード装置のインデックス情報から、“Ｖａｎｉｓｈ”メッセージ情報に含まれるコンテンツＩＤ（ｃＩＤ）およびＩＰアドレスに該当する情報を削除する。

次に、図１９について説明する。図１９は、タイマーによる処理（タイマーイベントの処理）をあらわすフローチャートである。図１９であらわされるフローチャートは、タイマーで設定された時間が到来するたびに起動される。

図１９であらわされるタイマーは、一つの役割として、“Ｐｕｂｌｉｓｈ”メッセージを受信したキャッシュノードが、“Ｃｏｎｆｉｒｍ”メッセージを送信した後の一定時間内に、コンテンツホルダからの“Ａｌｉｖｅ”メッセージの受信の有無を判断するために使用される。また、もう一つの役目として、キャッシュノードとしてノード装置が動作する場合に設定されるコヒーレンシ確認時間間隔を設定するためのタイマーとして使用される（図１７のステップＳ１２）。

“Ｃｏｎｆｉｒｍ”メッセージは、コンテンツ毎にノード装置から発信されるために、複数のタイマーを管理するためのタイマーマネージャが存在する（図示せず。）。タイマーを設定するノード装置は、設定時間とともに複数のタイマーを識別するためのタイマーＩＤをタイマーマネージャに設定する。本実施形態では、タイマーＩＤとしてコンテンツＩＤを使用する。タイマーに設定された時間が経過すると、図１９に示されるタイマーの処理ルーチンが開始される。

ステップＳ３０において、タイマーが設定された時のコンテンツＩＤ（ｃＩＤ）をタイマーマネージャから取得する。

ステップＳ３１において、キャッシュノードとなっているノード装置は、ステップＳ３０で取得されたコンテンツＩＤに相当するコンテンツデータを保持するコンテンツホルダ（コンテンツホルダは、当該コンテンツをネットワークへ登録させるために、“Ｐｕｂｌｉｓｈ”メッセージを発信したノード装置である。）
に対して“Ｃｏｎｆｉｒｍ”メッセージを発信する。

ステップＳ３２において、当該コンテンツＩＤに対応するコンテンツデータを保持するコンテンツホルダから“Ａｌｉｖｅ”メッセージが送信され、自ノード装置に当該“Ａｌｉｖｅ”メッセージが受信されるか、一定時間待つ。

ステップＳ３３において、“Ａｌｉｖｅ”メッセージが受信されたかを判断する。“Ａｌｉｖｅ”メッセージが受信されなかった場合（ステップＳ３３：ＮＯ）にはステップＳ３５に進む。“Ａｌｉｖｅ”メッセージが受信された場合（ステップＳ３３：ＹＥＳ）にはステップＳ３４に進む。

ステップＳ３４において、図１７のステップＳ１２で算出されたコヒーレンシ確認時間間隔とコンテンツＩＤをタイマーマネージャに設定する。

ステップＳ３５において、自ノード装置が、コンテンツＩＤのルートノードに該当するか否かを判断する。自ノード装置が、コンテンツＩＤのルートノードである場合（ステップＳ３５：ＹＥＳ）には、ステップＳ３８に進む。自ノード装置が、コンテンツＩＤのルートノードでない場合（ステップＳ３５：ＮＯ）には、ステップＳ３６に進む。

ステップＳ３６において、ステップＳ３５で判断されたコンテンツＩＤに対応するインデックス情報をインデックスキャッシュから削除する。

ステップＳ３７において、自ノード装置からルートノード方向にあるキャッシュノードに対して“Ｖａｎｉｓｈ”メッセージを発信する。

ステップＳ３８において、自ノード装置はルートノードであるので、ルートノードのステップＳ３５で判断されたコンテンツＩＤに対応するインデックス情報を記憶部から削除する。

上記実施形態において、コヒーレンシ確認間隔時間は式１を用いて算出しているが、これに限られるわけではなく、転送数によって異なる時間を算出するのであれば任意の関数または数式を用いて、コヒーレンシ確認間隔時間を算出することができる。

また、上記実施形態において、ルートノードに近いノード装置ほどコヒーレンシ確認間隔時間が大きくなっているが、これに限定されるわけではない。例えば、ルートノードに近いノード装置ほどコヒーレンシ確認間隔時間を小さくするように構成することも可能である。すなわち、インデックス情報を所有するノード装置毎にコヒーレンシ確認間隔時間が異なるように設定することで、特定のネットワーク上の経路への負荷の集中を減少させることができる。なお、各コンテンツの複製（レプリカ）を複数のコンテンツホルダが保持して、それを一つのルートノードが管理するような構成においては、本実施例のように、コンテンツホルダに近いほど頻繁にコヒーレンシ確認を行うようにしたほうが、好適である。逆にすると、ルートノードに確認の仕事が集中するからである。

また、上記実施形態においては、ＤＨＴを利用したアルゴリズムによって構築されたオーバレイネットワークを前提とし、キーワード等のコンテンツデータに特有の情報をハッシュ化して、かかるハッシュ値及びＤＨＴに基づいて、コンテンツデータの保存元であるノード装置、或いは、インデックス情報の管理元であるノード装置を特定するように構成したが、これの代わりに、例えば、キーワード等のコンテンツデータに特有の情報（或いは、これに付随する情報）を用いて所定の演算を行うアルゴリズムや関数（関数ｆｉｎｄ（例えば、キーワードに対応する数値に変換したもの）＝インデックス情報の管理元であるノード装置のＩＰアドレス）により、コンテンツデータの保存元であるノード装置、或いは、インデックス情報の管理元であるノード装置を特定するように構成してもよい。

また、上記実施形態においては、制御部１１が、所定のハッシュ関数によりキーワードのハッシュ値を生成するように構成したが、これに限定されるものではなく、キーワードに基づいて、当該キーワードに対応するキーワードＩＤ（他と識別可能な）を生成して、これに基づいて、インデックス情報の管理元であるノード装置を特定するように構成してもよい。

また、上記実施形態においては、複数のノード装置において共通に使用される共用情報としてコンテンツデータを例にとって説明したが、これに限定されるものではなく、例えば複数のノード装置において共通に使用されるべきソースプログラム等、複数のユーザが共通して持つ必要のある共用データに対して適用してもよい。この場合も、各更新段階の共用データの管理元であるノード装置が複数存在することになり、図１６に示す処理により、各ノード装置は、共用情報を保持するノード装置がネットワークから脱退することを検知すると、共用データに関する情報を速やかに削除する。

本実施形態に係るコンテンツ配信システムにおける各ノード装置の接続態様の一例を示す図である。 ノード装置１の概要構成例を示す図である。 ノードＩＤ空間とコンテンツＩＤ空間の一例を示す図である。 インデックス情報の組合せの例を示した図である。 ノードＩＤ空間を４分割にした状態をあらわす図である。 レベル１のルーティングテーブルをあらわす図である。 ノードＩＤ空間の領域Ａ１が４分割された状態をあらわす図である。 レベル２のルーティングテーブルをあらわす図である。 ノードＩＤ空間の領域Ａ１０が４分割された状態をあらわす図である。 レベル３のルーティングテーブルをあらわす図である。 ルーティングレベル８までのルーティングテーブルをあらわす図である。 ノード装置が、インデックス情報を所有するルートノードを検索する説明図である。 ノード装置がインデックス情報を所持するノード装置へ問い合わせる経路をあらわした図である。 コンテンツホルダからルートノードに至る経路をあらわす図である。 ＤＨＴによるルートノードの検索およびコヒーレント確認方法の様子の一例を示す図である。 インデックスキャッシュに記憶されている内容の一例を示す図である。 メッセージの内容を分類するフローチャートである。 Ｐｕｂｌｉｓｈメッセージの処理をあらわすフローチャートである。 Ｖａｎｉｓｈメッセージの処理をあらわすフローチャートである。 タイマーによる処理をあらわすフローチャートである。

符号の説明

１ ノード装置
８ ネットワーク
１１ 制御部
１２ 記憶部
１３ バッファメモリ
１４ デコーダ部
１５ 映像処理部
１６ 表示部
１７ 音声処理部
１８ スピーカ
１９ エンコーダ部
２０ 通信部
２１ 入力部
２２ バス
Ｓ コンテンツ配信システム

Claims (6)

1. ネットワークを介して互いに接続された複数のノード装置を備えた情報配信システムにおける前記ノード装置であって、
   前記複数のノード装置において共通に使用されるべき共用情報を識別するための共用情報識別情報と、前記共用情報とを記憶しているノード装置を識別するためのノード識別情報の組からなる共用情報所在情報を記憶するための所在情報記憶手段と、
   所定の更新確認時間間隔で、前記共用情報を有する第２ノード装置に係わる第一更新情報を取得する第一更新情報取得手段と、
   前記取得された第一更新情報に基づいて、前記所在情報記憶手段に記憶されている共用情報所在情報の削除の要否を判断する更新判断手段と、
   前記更新判断手段の判断に基づいて、前記所在情報記憶手段に記憶されている共用情報所在情報を削除する情報更新手段と、
   前記所在情報記憶手段を備えるノード装置と、前記共用情報を有する第１ノード装置との間に介在する中継ノード装置の数を示す中継数情報を記憶する中継数情報記憶手段と、
   前記中継数情報に基づいて更新確認時間間隔を演算する時間情報演算手段と、
   を備え、
   前記第一更新情報取得手段は、前記更新確認時間間隔で、前記共用情報を有するノード装置に係わる第一更新情報を取得することを特徴とするノード装置。
2. 請求項１に記載のノード装置において、前記時間情報演算手段は、中継数が多くなると更新確認時間間隔を長くすることを特徴とするノード装置。
3. ネットワークを介して互いに接続された複数のノード装置を備えた情報配信システムにおけるノード装置情報更新方法であって、
   前記複数のノード装置において共通に使用されるべき共用情報を識別するための共用情報識別情報と、前記共用情報を記憶しているノード装置を識別するためのノード識別情報の組からなる共用情報所在情報を所在情報記憶手段に記憶させるための所在情報記憶工程と、
   前記所在情報記憶手段を備えるノード装置と、前記共用情報を有する第１ノード装置との間に介在する中継ノード装置の数を示す中継数情報を中継数情報記憶手段が記憶する中継数情報記憶工程と、
   前記中継数情報に基づいて更新確認時間間隔を時間情報演算手段が演算する時間情報演算工程と、
   前記時間情報演算工程において演算された前記更新確認時間間隔で、前記共用情報を有する第２ノード装置に係わる第一更新情報を第一更新情報取得手段が取得する第一更新情報取得工程と、
   前記取得された第一更新情報に基づいて、前記所在情報記憶工程において記憶される共用情報所在情報の削除の要否を更新判断手段が判断する更新判断工程と、
   前記更新判断工程の判断に基づいて、前記所在情報記憶工程において記憶される共用情報所在情報を情報更新手段が削除する情報更新工程と、
   を含むことを特徴とするノード装置情報更新方法。
4. 請求項３に記載のノード装置情報更新方法において、
   前記時間情報演算工程において、前記時間情報演算手段は、中継数が多くなると更新確認時間間隔を長くすることを特徴とするノード装置情報更新方法。
5. ネットワークを介して互いに接続された複数のノード装置を備えた情報配信システムにおける所在情報記憶手段、第一更新情報取得手段、更新判断手段、情報更新手段を備える前記ノード装置に含まれるコンピュータにおいて実行されるプログラムであって、
   前記複数のノード装置において共通に使用されるべき共用情報を識別するための共用情報識別情報と、前記共用情報を記憶しているノード装置を識別するためのノード識別情報の組からなる共用情報所在情報を前記所在情報記憶手段に記憶させるための所在情報記憶ステップと、
   前記所在情報記憶手段を備えるノード装置と、前記共用情報を有する第１ノード装置との間に介在する中継ノード装置の数を示す中継数情報を中継数情報記憶手段が記憶する中継数情報記憶ステップと、
   前記中継数情報に基づいて更新確認時間間隔を時間情報演算手段が演算する時間情報演算ステップと、
   前記時間情報演算ステップにおいて演算された前記更新確認時間間隔で、前記共用情報を有する第２ノード装置に係わる第一更新情報を第一更新情報取得手段が取得する第一更新情報取得ステップと、
   前記取得された第一更新情報に基づいて、前記所在情報記憶手段に記憶されている共用情報所在情報の削除の要否を前記更新判断手段に判断させる更新判断ステップと、
   前記更新判断手段の判断に基づいて、前記所在情報記憶手段に記憶されている共用情報所在情報を前記更新判断手段に削除させる情報更新ステップと、
   を前記コンピュータに実行させることを特徴とするノード装置情報更新プログラム。
6. 請求項５に記載のノード装置情報更新プログラムにおいて、
   前記時間情報演算ステップは、前記時間情報演算手段に、中継数が多くなると更新確認時間間隔を長くさせることを特徴とするノード装置情報更新プログラム。

Images