(57)【要約】【課題】ピアノードのみで自立的にグローバルサービスの提供を行う。【解決手段】本発明は、オーバレイネットワークを構成する各ノードにおいて、サービスの名前であるサービス名と、サービスの実体であるサービス実体とを記憶させた。そして、サービス名をハッシュ化して得たサービスキーと自ノードの識別情報のハッシュ化して得たノード識別子とのハッシュ空間における距離Ｄ１が、ハッシュ空間上に存在する自ノード以外のノードのノード識別子とサービスキーとの距離Ｄ２のいずれよりも近い場合には、サービス実体を起動してサービスの提供を開始するようにした。【選択図】図７
2008204299.tif 000002
【特許請求の範囲】
【請求項１】
少なくとも１つのノードが、分散ハッシュテーブル技術によりハッシュ空間上に割り当てられて構成されるオーバレイネットワークシステムであって、当該オーバレイネットワークシステムを構成するすべてのノードを対象とした少なくとも１つのサービスが提供されるオーバレイネットワークシステムにおいて、
前記ノードは、
前記サービスの名前であるサービス名と、前記サービスの実体であるサービス実体とを記憶する記憶部と、
前記サービス名をハッシュ化して得たサービスキーと自ノードの識別情報のハッシュ化して得たノード識別子とのハッシュ空間における距離が、前記ハッシュ空間上に存在する自ノード以外のノードのノード識別子と前記サービスキーとの距離のいずれよりも近い場合には、前記サービス実体を起動して前記サービスの提供を開始する制御部とを備えたことを特徴とする
オーバレイネットワークシステム。
【請求項２】
請求項１記載のオーバレイネットワークシステムにおいて、
前記ノードは、前記サービスの実施に際して必要となるデータであるサービス記録データファイルと前記サービス記録データファイルの名前であるサービス記録データファイル名を前記記憶部に記憶し、
前記制御部は、自ノードで前記サービスの提供を開始する場合に、前記サービス記録データファイル名をハッシュ化して得たサービス記録データファイルキーを用いて前記サービス記録データファイルキーに割り当てられるノードを検索し、前記検索されたノードに前記サービス記録データファイルを転送することを特徴とする
オーバレイネットワークシステム。
【請求項３】
請求項１記載のオーバレイネットワークシステムにおいて、
前記ノードは、前記サービス実体へのアクセス方法を記載したサービスプロファイルと前記サービスプロファイルの名前であるサービスプロファイル名を前記記憶部に記憶し、
前記制御部は、前記サービスを開始する場合に、前記サービスプロファイルを公開することを特徴とする
オーバレイネットワークシステム。
【請求項４】
請求項３記載のオーバレイネットワークシステムにおいて、
前記サービスプロファイル名は、前記サービス名と同名であることを特徴とする
オーバレイネットワークシステム。
【請求項５】
請求項３記載のオーバレイネットワークシステムにおいて、
前記ノードの前記制御部は、前記サービスを利用する場合は、前記記憶部に記憶された前記サービス名をハッシュ化して得たサービスキーを用いて、前記サービスキーが割り当てられるノードを検索し、前記検索されたノードから前記サービスプロファイルを取得して前記サービス実体にアクセスすることを特徴とする
オーバレイネットワークシステム。
【請求項６】
請求項２記載のオーバレイネットワークシステムにおいて、
前記ノードの前記制御部は、自ノードで前記サービスを提供している場合で、当該オーバレイネットワークより離脱する場合には、自ノードの近傍のノードの中から、前記ノード識別子と前記サービス名をハッシュ化して得たサービスキーとのハッシュ空間上の距離が自ノードの次に近いノードを検索し、前記検索されたノードに対してサービス引継ぎ要求を送信することを特徴とする
オーバレイネットワークシステム。
【請求項７】
請求項６記載のオーバレイネットワークシステムにおいて、
前記ノードの前記制御部は、他ノードから送信された前記サービス引継ぎ要求を受信した場合には、前記サービス記録データファイルキーを用いて前記サービス記録データファイルが記憶されたノードを検索し、前記検索されたノードから前記サービス記録データファイルを取得し、前記サービス実体を起動して前記サービスの提供を開始することを特徴とする
オーバレイネットワークシステム。
【請求項８】
請求項２記載のオーバレイネットワークシステムにおいて、
前記ノードの前記制御部は、前記近傍のノードの障害を検知した場合には、前記サービス名をハッシュ化して得たサービスキーを用いて前記サービスキーが割り当てられるノードを検索し、前記検索されたノードに対して前記サービスを提供中であるか否かの確認要求を送信することを特徴とする
オーバレイネットワークシステム。
【請求項９】
請求項８記載のオーバレイネットワークシステムにおいて、
前記ノードの前記制御部は、他ノードから送信された前記サービスを提供中であるか否かの確認要求を受信した場合には、自ノードで前記サービス実体を起動しているか否かを判断し、前記サービス実体を起動していない場合には、前記サービス記録データファイルキーを用いて前記サービス記録データファイルが記憶されたノードを検索し、前記検索されたノードから前記サービス記録データファイルを取得し、前記サービス実体を起動して前記サービスの提供を開始することを特徴とする
オーバレイネットワークシステム。
【請求項１０】
少なくとも１つのノードが、分散ハッシュテーブル技術によりハッシュ空間上に割り当てられて構成されるオーバレイネットワークシステムであって、当該オーバレイネットワークシステムを構成するすべてのノードを対象とした少なくとも１つのサービスが提供されるオーバレイネットワークシステムにおけるサービス提供方法において、
前記ノードは、
前記サービスの名前であるサービス名と、前記サービスの実体であるサービス実体とを記憶し、
前記サービス名をハッシュ化して得たサービスキーと自ノードの識別情報のハッシュ化して得たノード識別子とのハッシュ空間における距離が、前記ハッシュ空間上に存在する自ノード以外のノードのノード識別子と前記サービスキーとの距離のいずれよりも近い場合には、前記サービス実体を起動して前記サービスの提供を開始することを特徴とする
サービス提供方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、少なくとも１つのノードが、分散ハッシュテーブル技術によりハッシュ空間上に割り当てられて構成されるオーバレイネットワークシステム及び、そのオーバレイネットワークシステムに適用されるサービス提供方法に関する。
【背景技術】
【０００２】
近年、クライアント・サーバ型の形態に代わって、ネットワークに接続されたすべてのノード（ピアノード）が動的にその役割を変えられる、ピア・ツー・ピア（以降Ｐ２Ｐと称する）と呼ばれる接続形態が注目を集めている。クライアント・サーバ型のシステムで、サーバが一括して保有していたデータは、Ｐ２Ｐを用いたシステムにおいては各ピアノードに分散して保存される。つまり、データの保存場所の検索はピアノード同士が協力して行う。
【０００３】
データの保存場所の検索技術としては、例えば分散ハッシュテーブル（以下、ＤＨＴ:Distributed Hash Tableと称する）が知られている。ＤＨＴでは、データから生成されたハッシュ値と近いハッシュ値を持つノードに、データの実体の保存場所情報が登録される。このとき、データのハッシュ値生成とノードのハッシュ値生成には、同じハッシュ関数が使われる。そして、データの実態の保存場所情報が登録された各ノードにおいて、データのハッシュ値とデータの実態の保存場所情報との組が、テーブル（ハッシュテーブル）として保持される。
【０００４】
ハッシュ値は、元となるデータが異なれば全く違う値となるため、データの保存場所情報が登録される先も、ネットワーク上に分散されるようになる。つまり、ハッシュテーブルが各ピアノードに分散して配置されるようになるため、各ピアノードにかかる負荷も分散される。
【０００５】
データの検索を行う場合には、データのハッシュ値を算出してそのハッシュ値をキーに検索すればよい。ＤＨＴでは、ネットワークを構成するすべてのノードに、近傍のノードへのルートが記されたルーティングテーブルを予め備えさせており、そのルーティングテーブルにおいては、各ノード間の距離が、各ノードのハッシュ値で表現されている。
【０００６】
ネットワーク上のいずれかのノードに登録されたデータを参照したい場合は、まずそのデータのハッシュ値を求め、自ノード内のルーティングテーブルの中で、データのハッシュ値と最も近いハッシュ値を持つノードに対して、検索要求を投げかける。検索要求を受け取ったノードがデータの保存場所情報を所持していない場合は、今度は検索要求を受け取ったノードが、自ノード内のルーティングテーブルの中の、データのハッシュ値と最も近いハッシュ値を持つノードに対して、検索要求を投げかける。このような動作が繰り返されることにより検索範囲が縮まっていき、最終的に、検索したいデータの保存場所情報を得ることが可能となる。検索したいデータの保存場所情報が分かれば、その情報を基に実際のデータを取得することができる。つまり、ＤＨＴの技術を利用して構築されたオーバレイネットワーク上では、データの実体がどこにあるかを意識することなく、データ実体にアクセスすることが可能となる。
【０００７】
このように、ＤＨＴでは、ハッシュ値で示された各ピアノード間の距離に基づいてルーティングが行われるため、ＩＰネットワーク上に設けられたセグメントを意識する必要がなくなる。つまり、ＩＰ層よりも上の層でルーティングを行うＤＨＴを用いて、オーバレイネットワークを構築することが可能となる。
【０００８】
オーバレイネットワーク上で提供されるサービスには、大きく分けて、個々のノードが提供する独自のサービス（ローカルサービス）と、オーバレイネットワーク全体に係わるサービス（グローバルサービス）の２種類がある。個々のノードが提供するローカルサービスとしては、例えばＷｅｂサービスやＦＴＰサービスがある。個々のノードにより提供されるサービスは、ノードがネットワーク上に生存する期間においてのみ利用可能であり、ノードがネットワークから外れた場合は、サービス自体も利用不可能となる。
【０００９】
これに対してグローバルサービスは、ノードがオーバレイネットワークに新規に参加したり、又はオーバレイネットワークから離脱する等の変更があった場合も、オーバレイネットワークが存在している間は、継続して提供が求められるサービスである。グローバルサービスの例としては、例えば新しいノードがネットワークに参加する際の認証サービスや、管理用に用いるノード一覧サービス、サービス一覧サービスなどがある。
【００１０】
グローバルサービスの提供にあたっては、サービス提供の確実性を高めるために、グローバルサービス提供用のサーバをネットワーク上に設けたり、サーバのような役割を果たすスーパーノードとして、予め指定した幾つかのノードを指定しておく等の手法が採用されることが多い。オーバレイネットワーク上にサーバを設ける形態はハイブリッドＰ２Ｐ、スーパーノードを設ける形態はスーパーノード型ハイブリッドＰ２Ｐと呼ばれており、これに対して、純粋にピアノードのみによって構成される形態は、ピュアＰ２Ｐと呼ばれている。
【００１１】
特許文献１には、中央サーバを併用したハイブリッドＰ２Ｐシステムについて開示してある。
【特許文献１】特開２００５−１９６６７６号公報
【発明の開示】
【発明が解決しようとする課題】
【００１２】
ところで、グローバルサービスを安定的に提供するために、オーバレイネットワーク上にサーバやスーパーノードを設ける場合には、ピュアＰ２Ｐに比べてシステムの柔軟性に欠けるという問題があった。
【００１３】
また、スーパーノード型ハイブリッドＰ２Ｐにおいては、一般に、スーパーノードの指定はノードの能力（ＣＰＵ性能やメモリ容量、ネットワーク帯域等）を基に行われるが、例えばテレビ会議システムに用いられる端末や、ネットワークカメラ等で構成されるネットワークにおいては、すべての端末（ノード）の性能はほぼ均一となる。このような場合は、どのノードをスーパーノードに指定すればよいかの判断が難しくなってしまうという問題があった。
【００１４】
本発明はかかる点に鑑みてなされたものであり、ピアノードのみで自立的にグローバルサービスの提供を行うことを目的とする。
【課題を解決するための手段】
【００１５】
本発明は、少なくとも１つのノードが、分散ハッシュテーブル技術によりハッシュ空間上に割り当てられて構成されるオーバレイネットワークシステムであって、当該オーバレイネットワークシステムを構成するすべてのノードを対象とした少なくとも１つのサービスが提供されるオーバレイネットワークシステムにおいて、ノードに、サービスの名前であるサービス名と、サービスの実体であるサービス実体とを記憶する記憶部を備えた。そして、サービス名をハッシュ化して得たサービスキーと自ノードの識別情報のハッシュ化して得たノード識別子とのハッシュ空間における距離が、ハッシュ空間上に存在する自ノード以外のノードのノード識別子とサービスキーとの距離のいずれよりも近い場合には、サービス実体を起動してサービスの提供を開始するようにした。
【００１６】
このようにしたことで、ノード識別子とサービスキーとのハッシュ空間上の距離が一番近いノードにサービスが自動的に割り当てられるようになる。
【発明の効果】
【００１７】
本発明によると、サービスの提供を行うノードが自動的に割り当てられるため、ピアノードのみで自立的にグローバルサービスの提供を行うことができるようになる。
【発明を実施するための最良の形態】
【００１８】
以下、本発明の一実施の形態を、添付図面を参照して説明する。本実施の形態では、本発明のネットワークシステムを、複数台のテレビ会議端末で構成されるテレビ会議システムに適用してある。図１は、ネットワーク１を介して、複数台のテレビ会議端末１００が互いに接続された様子を示す図である。図１における各テレビ会議端末１００は、オーバレイネットワークを構成するノードでもある。このため、図１では、ネットワーク１に接続された６台のテレビ会議端末１００を、それぞれノードＮ１〜Ｎ６としてある。以降の説明においても、テレビ会議端末１００のノードとしての機能を説明する際には、テレビ会議端末１００をノードＮｎ（ｎは整数）と称する。オーバレイネットワーク構築の技術としては、ＤＨＴを用いてあり、そのアルゴリズムとして、Ｃｈｏｒｄを使用した場合を例に挙げて説明する。
【００１９】
まず、テレビ会議端末１００の内部構成例について説明する。図１のテレビ会議端末１００は、外付けもしくは内蔵のカメラユニット内に組み込まれたレンズ１０と、レンズ１０を介して入射した被写体光を光電変換し、映像信号を生成する撮像部１１とを備える。レンズ１０及び撮像部１１は、テレビ会議端末１００のユーザの姿を撮影するものであり、撮影して得られた映像信号は、図示せぬ信号処理部で信号処理された後、通信インターフェース部（以下、Ｉ／Ｆ部と称する）１２を介してネットワーク１上の他のテレビ会議端末１００に配信される。
【００２０】
通信Ｉ／Ｆ部１２は、ネットワーク１との接続のインターフェース部であり、ネットワーク１上の他のテレビ会議端末１００から送信されたデータを、テレビ会議端末１００内に取り込む役割も果たす。テレビ会議端末１００は、通信Ｉ／Ｆ部１２を介して得た他のテレビ会議端末ユーザの像を映すための、表示部１３も備える。表示部１３は、液晶パネル等で構成される。
【００２１】
また、テレビ会議端末１００は、マイクロフォン１４とスピーカ１５も備えており、マイクロフォン１４及びスピーカ１５は音声処理部１６に接続してある。音声処理部１６は、マイクロフォン１４が拾って得たテレビ会議端末１００のユーザの音声信号に対して、伝送用の音声データ処理を行い、処理した音声信号を通信Ｉ／Ｆ部１２に送信する。さらに、通信Ｉ／Ｆ部１２を通して得た他のテレビ会議端末１００のユーザの音声信号に対して、音声データ処理を行い、処理した音声信号をスピーカ１５から出力させる。
【００２２】
上述した各部での動作は、ボタンやキーボード等で構成される操作部１７への、ユーザの操作入力に基づいて行われる。そしてその制御は、ＣＰＵ（Central Processing Unit）等で構成される制御部１８によって行われる。制御部１８にはメモリ１９を接続してあり、メモリ１９には、制御に必要なプログラム等を記憶させてある。制御部１８は、メモリ１９に記憶されたプログラムを読み出して実行する。
【００２３】
テレビ会議端末１００には、メモリカードやハードディスク等で構成される記憶部２０も設けてあり、記憶部２０には、ネットワーク１上の他のユーザから送られたデータ等を記憶させることができる。また、記憶部２０には予めルーティングテーブルＴ１と、グローバルサービステーブルＴ２を記憶させてある。
【００２４】
ルーティングテーブルＴ１とは、自ノードの近傍のノードの所在地情報を記したテーブルであり、例えばｍ行で構成される。ｍ行のテーブルのｉ行目には、自ノードＩＤ+２＾(ｉ-１) のノードの情報を記してあり、ｍ＝４とした場合には、各ノードは自分の１，２，４，８先のノード情報をルーティングテーブルＴ１内に保持することになる。ノードＩＤとは、hash(X)の式により求められるハッシュ値であり、Xには、ノードのＩＰアドレスや識別子等が代入される。つまり、ノードのＩＰアドレスや識別子等をハッシュ化したハッシュ値が、ノードＩＤ（識別子）となる。
【００２５】
各ノードが、このようなルーティングテーブルを所有していることで、例えば自分の１，２，４，８先のノードの情報しか知らなくても、各ノードのルーティングテーブルＴ１の情報を基に検索要求が次々と転送されることで、検索範囲が絞られていく。そして、最終的には目的とするデータにたどり着くことができる。
【００２６】
グローバルサービステーブルＴ２とは、オーバレイネットワーク上で提供されるすべてのグローバルサービス（以下、単にサービスとも称する）に関する情報を記述したテーブルである。グローバルサービスの例としては、テレビ会議端末１００の認証サービスや、各テレビ会議端末１００を一覧で閲覧可能なアドレス帳サービス等がある。グローバルサービステーブルＴ２の詳細については後述する。
【００２７】
本発明では、サービスを、以下の４つの要素を備えるものとして定義している。
・サービス名
・サービス実体
・サービスプロファイル
・サービス記録データファイル
サービス名とは、オーバレイネットワーク上で提供されるサービスの名前であり、所定のネーミングスキームに基づいて、ＵＲＩ（Uniform Resource Identifier）等で表現してある。例えば、認証サービスであればurn:abcdabcd:dht:product:service:global:authentication 、アドレス帳サービスであれば、urn: abcdabcd:dht:product:service:global:nodelistのように表現される。サービス実体は、実行可能なプログラムのことであり、サービスの開始又は停止を動的に設定可能な状態としてある。
【００２８】
サービスプロファイルとは、サービスにアクセスするためのエンドポイント情報（ＩＰアドレスやＵＲＬ等）や、ＡＰＩ（Application Programming Interface）が記述された、ファイル形式のコンテンツである。各ノードが自分の環境に合わせて自動でコンフィギュレーション可能なファイルであり、各ノードによって中身が異なる。例えば、サービスプロファイルのフォーマットが、Servide-EndPoint=http:host:port:/path/serviceのようなものである場合は、同じサービスに対するサービスプロファイルであっても、ノードＮ１では http://192.168.0.1/cgi-bin/service1.cgi、ノードＮ２では、http://192.168.1.1:8080/service/service1.cgiのように、それぞれ異なる記述となる。サービスプロファイル及びサービス実体は、各ノードの記憶部２０（図１参照）に記憶してある。
【００２９】
サービス記録データファイルとは、サービスの実施に伴って生じる、記録・保存すべきデータが記述されるファイルである。サービス記録データファイルは、サービス実体によって動的に生成（export）又は取り込み（import）されるものである。
【００３０】
本発明ではさらに、定義した要素のそれぞれに識別のための名前を付与し、これらの要素を、付与した名前のハッシュ値を用いてオーバレイネットワークの同一のハッシュ空間上にマッピングすることを行っている。これにより、このように定義されたサービスを、オーバレイネットワーク上のどこからでも自在に検索及び取得することができるようになる。
【００３１】
識別のための名前やハッシュ値を一覧にしたものがグローバルサービステーブルＴ２であり、オーバレイネットワークを構成するすべてのノードは、等しくグローバルサービステーブルＴ２を保持するようにしてある。そして、グローバルサービステーブルＴ２の各項目は、オーバレイネットワーク上で展開されるすべてのサービスに対応して、サービスの数だけ設定される。つまり、オーバレイネットワーク上で展開されるサービスが、認証サービスとアドレス帳サービスであれば、認証サービスとアドレス帳サービスのそれぞれに関して、上述した項目が設定されるようになる。
【００３２】
図２には、グローバルサービステーブルＴ２の構成例を示してある。グローバルサービステーブルＴ２は、インデックス、サービス名、サービスキー、サービスプロファイル名、サービスプロファイルキー、サービスプロファイル、サービス実体、サービス記録データファイル名、サービス記録データファイルキー、サービス記録データファイルで構成される。
【００３３】
インデックスとは、グローバルサービステーブルの行方向の項目数に対応して付与されるものであり、１〜ｎの数値が入る。グローバルサービステーブルの行方向の項目数は、グローバルサービスの数に応じて増減する。サービス名については、上述したとおりであるため説明を省略する。サービスキーとは、サービス名をハッシュ化して得られるハッシュ値であり、hash(サービス名)で求められる。図２においては、サービス名は“urn:abcd:dht:service:global:servicename1”であるため、サービスキーは“hash(urn:abcd:dht:service:global:servicename1)となる。
【００３４】
サービスプロファイル名は、サービス名と同名としてある。サービスプロファイルキーは、サービスプロファイル名をハッシュ化して得られるハッシュ値であるが、サービスプロファイル名とサービス名を同名としてあるため、サービスプロファイルキーとサービスキーとは同じ値となる。
【００３５】
サービスプロファイルには、上述したサービスプロファイルの実体へのパスが記載される。サービスプロファイルは記憶部２０（図１参照）に記憶させてあるため、記憶部２０におけるパスが記される。図２に示した例では“/dht/service_profile/service_profile1.xml”のように記述してある。サービス実体にも、上述したサービス実体へのパスが記載される。図２に示した例では、“www/cgi-bin/service1.cgi”のように記述してある。
【００３６】
サービス記録データファイル名は、上述したサービス記録データファイルの名前であり、サービス名と同様に、ＵＲＩ等の文字列で構成される。図２に示した例では、“urn:abcd:dht:service:global:servicedata1”と記述してある。サービス記録データファイルキーは、サービス記録データファイル名をハッシュ化したハッシュ値であるため、hash(urn:abcd:dht:service:global:servicedata1)となる。サービス記録データファイルには、サービス記録データファイルの実体へのパスが記載されている。
【００３７】
なお、サービスキー、サービスプロファイルキー、サービス記録データファイルキーは、サービス名、サービスプロファイル名、サービス記録データファイル名を基に算出が可能であるため、予めグローバルサービステーブル上に項目として備えておかず、都度計算して求めるような構成としてもよい。
【００３８】
すべてのノードは、皆等しく同じグローバルサービステーブルを保持しているが、サービスの提供は、特定のノードにのみ行わせるようにしてある。特定のノードとは、ノードＩＤと、サービスキーとの距離が一番近いノードのことであり、本例では、そのノードを、サービスの提供者としている。そして、サービス提供者は以下の条件を満たしているものとする。
・サービス実体を持っており、それを実行している
・サービスプロファイルの提供する
・サービス記録データファイルに必要なデータを作成・更新し、最新のものをオーバレイネットワーク上にアップロードする
つまり、オーバレイネットワーク上のすべてのノードがサービス実体を備えているが、それを実行するのはサービス提供者となったノードのみとなる。このため、実行中のサービスへのアクセス方法を記したサービスプロファイルとしては、サービス提供者の保持するサービスプロファイルのみが有効となる。
【００３９】
図３は、サービス提供者に割り当てられたノードが行う、サービス提供処理例を示したフローチャートである。サービス提供者の割り当て処理については後述する。サービス提供者に割り当てられたノードは、まず自ノード内でサービスプロファイルを用意し（ステップＳ１）、記憶部２０に記憶されたサービス実体（プログラム）を起動してサービスの提供を開始する（ステップＳ２）。そして、自ノード内でサービス記録データファイルを生成する（ステップＳ３）。サービス記録データファイルを生成した後は、サービス記録データファイルをアップロードする対象ノードの及びその近傍のノードを割り出し、それらのノードに、サービス記録データファイルを保存する（ステップＳ４）。
【００４０】
ステップＳ４のアップロード対象ノードの割り出し及び対象ノードへのファイルの保存は、put(key, content)の式を用いて行う。つまり、put(サービス記録データファイルキー，サービス記録データファイル)の式を実行することにより、サービス記録データファイルキーにマッピングされるノード（及びその近傍のノード）が割り出され、対象のノードにサービス記録データファイル（のコピー又は復元可能な断片）が保存される。
【００４１】
サービス記録データファイルを保存した後は、自ノード内のサービス記録データファイルが更新されたか否かの判断が行われる（ステップＳ５）。更新が行われない場合は何も処理を行わず、更新が行われた場合にはステップＳ４に戻って、更新したファイルをアップデート対象ノードに保存する。なお、自ノード内のサービス記録データファイルを、アップデート対象ノードに保存する処理は、自ノード内のサービス記録データファイルが更新されるたびに行われるものとする。
【００４２】
サービス名とサービス記録データファイル名とでは異なる名前を付与してあり、異なる名前（データ）から生成されたハッシュ値は必ず異なる値となるため、このような処理を行うことで、サービスの提供者ノードとサービス記録データファイルの保存先ノードが、オーバレイネットワーク上で分散されるようになる。なお、以降の説明においては、図３に示した処理を「サービス利用フロー」と称する。
【００４３】
次に、サービスを利用する側のノードにおいて行う処理の例について、図４のフローチャートを参照して説明する。サービスを利用したいノードでは、まず、自ノードのグローバルサービステーブルＴ２に記載されたサービスプロファイルキーを用いて、サービス提供者ノードを検索する（ステップＳ１１）。サービス提供者ノードの検索は、Node=lookup(key)の式を用いて行う。keyの部分にサービスプロファイルキーを代入することにより、サービスプロファイルキーにマッピングされたノードを求めることができる。
【００４４】
サービス提供者ノードを割り出せた後は、自ノードのルーティングテーブルＴ１を基にサービス提供者ノードにアクセスし、サービス提供者ノードの所有するサービスプロファイルを入手する（ステップＳ１２）。そしてサービスプロファイルを解析し（ステップＳ１３）、サービスプロファイルに記述された方法でサービスにアクセスして、サービスを利用する（ステップＳ１４）。なお、以降の説明においては、図４に示した処理を「サービス利用フロー」と称する。
【００４５】
次に、図５のフローチャートを参照して、他のノードからサービスを引き継いだノードが行う処理例について説明する。新たにサービス提供者となったノードは、まずサービスプロファイルを用意する（ステップＳ２１）。次に、グローバルサービステーブルＴ２内のサービス記録データファイルキーを用いて、オーバレイネットワークからサービス記録データファイルを取得し（ステップＳ２２）、サービスを再構築する（ステップＳ２３）。サービス記録データファイルの取得は、content=get(key)の式を用いて行う。keyの部分にサービス記録データファイルキーを代入することにより、サービス記録データファイルキーにマッピングされたノードから、サービス記録データファイルを取得することができる。
【００４６】
サービス記録データファイルを入手した後は、サービス実体（プログラム）を開始する（ステップＳ２４）。そして、サービスを提供している間中、自ノード内のサービス記録データファイルが更新されたか否かの判断が行われる（ステップＳ２５）。更新が行われない場合は何も処理を行わず、更新が行われた場合には、更新したファイルをアップデート対象ノードに保存する（ステップＳ２６）。なお、自ノード内のサービス記録データファイルを、アップデート対象ノードに保存する処理は、自ノード内のサービス記録データファイルが更新されるたびに行われるものとする。なお、以降の説明においては、図５に示した処理を「サービス受継ぎフロー」と称する。
【００４７】
次に、図６及び図７のフローチャートを参照して、新規ノードがオーバレイネットワークに参加する際の処理例について説明する。図６には、新規に参加するノードが、オーバレイネットワークを構築する最初のノードであった場合の例を示してある。オーバレイネットワークに最初に参加したノードは、自ノードのグローバルサービステーブルＴ２に記載されたすべてのサービスに対して、サービス提供フローを実行する（ステップＳ３１）。つまり、このノードが、グローバルサービステーブルＴ２に記載されたすべてのサービスにおけるサービス提供者となる。
【００４８】
図７には、既に幾つかのサービスが提供されている状態のオーバレイネットワークに、新規ノードが参加する際の処理例を示してある。新規に参加するノードは、まず自分のノードＩＤと、グローバルサービステーブルＴ２中に記述されたすべてのサービスのサービスキーとの距離Ｄ１を算出する（ステップＳ３１）。次に、サービスキーを用いて、すべてのサービスにおけるサービス提供者ノードを検索する（ステップＳ３２）。サービス提供者ノードを検索した後は、各サービス提供者ノードのノードＩＤと、グローバルサービステーブル内の各サービスキーとの距離Ｄ２を算出する（ステップＳ３３）。
【００４９】
次に、距離Ｄ１と距離Ｄ２との大きさが比較され（ステップＳ３４）、距離Ｄ１が距離Ｄ２以上（距離Ｄ１＞＝距離Ｄ２）の場合は、サービスキーに対する距離が、既存のサービス提供者よりも自ノードの方が遠いもしくは同距離であるため、新規に参加したノードは、サービスを受継がずそのまま処理を終了する。距離Ｄ１が距離Ｄ２より小さい（距離Ｄ１＜距離Ｄ２）場合には、既存のサービス提供者ノードよりも、自ノードの方がサービスキーに対する距離が近いことになるので、自らがサービス提供者になるべく、既存のサービス提供者ノードに対してサービス受継ぎ許可申請リクエストを送信する（ステップＳ３５）。
【００５０】
既存のサービス提供者ノードは、サービス受継ぎ許可申請リクエストを受信すると（ステップＳ３６）、リクエストを許可するか否かの判断を行い（ステップＳ３７）、不許可の場合は、不許可の理由もつけて要求元の新規参加ノードにレスポンスを送信する（ステップＳ３８）。リクエストを許可する場合も、要求元の新規参加ノードにレスポンスを送信する（ステップＳ３９）。
【００５１】
新規参加ノードは、既存のサービス提供者ノードからのレスポンスを受信すると（ステップＳ４０）、レスポンスの内容から、サービスの受継ぎが許可されたか否かの判断を行う（ステップＳ４１）。サービスの受継ぎが許可されなかった場合は、そのまま処理を終了する。サービスの受継ぎが許可された場合は、サービス受継ぎフローを実行し（ステップＳ４２）、サービス受継ぎフローの実行が完了した後に、元のサービス提供者ノードに対して完了通知を送信する（ステップＳ４３）。元のサービス提供者ノードは、完了通知を受信すると（ステップＳ４４）、実施中のサービスを停止する（ステップＳ４５）。
【００５２】
このように処理することで、サービスキーとの距離が一番近いノードが、常にそのサービスのサービス提供者となるようになる。
【００５３】
次に、ノードがオーバレイネットワークから離脱する場合の処理例について、図８及び図９のフローチャートを参照して説明する。図８には、ノードが正常にオーバレイネットワークから離脱する場合の処理例を示してあり、図９には、障害などでノードが突然離脱する場合の処理例について示してある。図８において、オーバレイネットワークから離脱を予定しているノードは、まず自分がサービス提供者であるか否かの判断を行う（ステップＳ５１）。サービス提供者でない場合には、そのままオーバレイネットワークを離脱する（ステップＳ６０）。
【００５４】
離脱予定のノードがサービス提供者であった場合には、離脱予定ノードは、サービスキーとの距離が自分の次に近いノードを自ノード内のルーティングテーブルを参照して選び、サービス譲渡対象ノードとして選定する（ステップＳ５２）。そして、サービス譲渡対象ノードに対して、サービス引継ぎリクエストを送信する（ステップＳ５３）。
【００５５】
サービス譲渡対象ノードは、離脱予定のノードからサービス引継ぎリクエストを受信すると（ステップＳ５４）、サービス引継ぎリクエストを無条件で受諾し（ステップＳ５５）、サービス受継ぎフローを実行する（ステップＳ５６）。サービス受継ぎフローの実行が完了したら、離脱予定のノードに対して、サービス受継ぎ完了の通知を送信する（ステップＳ５７）。離脱予定のノードは、サービス譲渡対象ノードからサービス受継ぎ完了の通知を受信すると（ステップＳ５８）、実行中のサービスを停止し（ステップＳ５９）、オーバレイネットワークから離脱する（ステップＳ６０）。
【００５６】
次に、図９のフローチャートを参照して、障害等でノードが突然オーバレイネットワークを離脱してしまった場合の処理例について説明する。オーバレイネットワークを構成する各ノードは、pingやkeep alive信号を定期的に隣接するノードに発信するようにしてあり、特定のノードが突然オーバレイネットワークを離脱した場合には、そのノードの近傍のノードがその状況を察知できるようにしてある。よって、特定のノードに障害が発生した場合に最初にアクションを起こすのは、その障害を検知した近傍のノードとなる。
【００５７】
近傍のノードの障害を検知したノードは、自ノードのグローバルサービステーブルＴ２に記述されたすべてのサービスキーを用いて、サービスキーにマッピングされたノードの検索を行う（ステップＳ７１）。そして、サービスキーにマッピングされたすべてのノードに対して、サービス利用の可否（サービスを実施中かどうか）の確認を行うための問い合わせを送信する（ステップＳ７２）。
【００５８】
問い合わせを受信したノードは、問い合わせを受信後（ステップＳ７３）、自ノードにおいてサービスを実施中であるか否かの判断を行う（ステップＳ７４）。サービスを実施中である場合には、サービス実施中の旨、障害を検知したノードにレスポンスを送信し（ステップＳ７５）、処理を終了する。サービスを実施していなかった場合も、障害を検知したノードにその旨レスポンスを送信し（ステップＳ７６）、サービス受継ぎフローを実行する（ステップＳ７７）。障害を検知したノードは、問い合わせを受信したノードから送られたレスポンスを受信すると（ステップＳ７８）、そのまま処理を終了する。
【００５９】
次に、上述したようなノードのオーバレイネットワークへの新規参加時、ノードの離脱時のサービスの動的割り当て処理の具体的な例を、図１０の図を参照して説明する。図１０（ａ）〜（ｆ）は、ハッシュ空間上に各ノードが配置された状態を示したものである。本例ではＣｈｏｒｄアルゴリズムを用いた場合を例に挙げているため、ハッシュ空間を円状で表現してあり、各ノードを、時計回りの方向に進むにつれてノードＩＤが大きくなるように配置してある。
【００６０】
Ｃｈｏｒｄにおいては、ハッシュ空間とノードのマッピングに、next(k)という関数を用いている。この関数は、あるキーｋに対して、時計回りの方向に最初に存在するノードが、そのキーｋとの距離が一番近いと定義するものである。図１０においては、オーバレイネットワーク上で提供されているサービスをサービスＳ１としてあり、サービスＳ１のサービスキーを４としてある。
【００６１】
図１０（ａ）では、オーバレイネットワークに最初のノードが参加した時の状態を示している。図１０（ａ）において最初に参加したノードはノードＮ１であり、ノードＮ１がサービスＳ１のサービス提供者となっている。このとき、実際には図６で説明したフローが実施される。図１０（ａ）でノードＮ４を破線で示してあるが、これは、仮にこの位置にノードＮ４が存在する場合にはnext(4)=ノードＮ４となり、サービスＳ１のサービスキー４とノードＮ４のＩＤとが一番近くなることを意味する。つまり、仮にノードＮ４が存在する場合には、サービスＳ１はノードＮ４により提供されることになる。
【００６２】
図１０（ｂ）では、ノードＮ１の他に、ノードＮ２とノードＮ３が新規に参加した場合の状態を示してある。ノードＮ２とノードＮ３が新規に参加したとしても、next(4)はノードＮ１であり、サービスキーと一番距離が近いのは依然ノードＮ１であるため、サービスＳ１の受継ぎは行われない。
【００６３】
図１０（ｃ）では、新たにノードＮ６が参加した場合の状態を示している。ノードＮ６が参加したことで、サービスキー４と一番距離が近いのはノードＮ６となるため、サービスＳ１は、ノードＮ１からノードＮ６に受継がれる。ここでは、図７に示した処理が実施される。
【００６４】
図１０（ｄ）では、ノードＮ５が新たに参加することにより、next(4)=ノードＮ５となったため、サービスＳ１がノードＮ６からノードＮ５に引き継がれた様子を示してある。図１０（ｅ）では、ノードＮ５が正常に離脱した場合の状態を示してある。つまり、図１０に示された処理が行われる。それにより、ノードＮ５で提供されていたサービスＳ１は、ノードＮ５の次にサービスキー４に近いノードである、ノードＮ６によって受継がれるようになる。
【００６５】
図１０（ｆ）に示したように、ノードＮ６が障害等で突然オーバレイネットワークを離脱した場合は、その状況を察知したノードＮ１とノードＮ３が障害検知ノードとなり、図９で説明した処理が行われる。図９のステップＳ７２における、サービスキーにマッピングされたノードは、図１０（ｆ）ではノードＮ１となるため、ノードＮ１がサービス受継ぎフローを実行し（図９のステップＳ７７）、サービスＳ１はノードＮ１に引き継がれる。
【００６６】
このように、オーバレイネットワーク上で提供される各サービスに対して識別のための名前（サービス名）をつけ、サービス名をハッシュ化したハッシュ値にマッピングされたノードをサービス提供者とするようにしたため、サービスがノードに動的に割り当てられるようになる。
【００６７】
また、サービス名と、サービス記録データファイル名とに異なる名前を付与し、サービス名のハッシュ値であるサービスキーと、サービス記録データファイル名のハッシュ値であるサービス記録データファイルキーを用いて、それぞれをオーバレイネットワーク上に割り当てるようにしたため、サービスキーにマッピングされるサービスの提供者と、サービス記録データファイルキーにマッピングされるノードとが、ネットワーク上で分散して配置されるようになる。
【００６８】
つまり、サービス記録データファイルがサービス提供者ノードとは異なるノードに記録されるようになるため、サービス提供者ノードの離脱等によりサービス提供者の変更があっても、サービスを受継いだノードは、オーバレイネットワーク上に記憶されたサービス記録データファイルを用いて、即座にサービスを再開できる。すなわち、オーバレイネットワークにおいて、グローバルサービスを切れ目無く安定的に提供することが可能となる。
【００６９】
また、オーバレイネットワークを構成するすべてのノードが、皆等しくサービス実体を有する構成としてあるため、既存のサービス提供者ノードからサービスを受継いだ場合にも、サービス実体の受け渡し等を行うことなく、すぐにサービスを開始することができる。
【００７０】
また、サービス提供者ノードにおいて障害等が発生し、突然サービスを提供できなくなった場合でも、その障害を検知した近傍のノードが、サービスキーを用いてサービスキーにマッピングされるノードを探し出し、対象のノードにサービス受継ぎの処理を行わせるようにしたため、オーバレイネットワーク上で提供されるグローバルサービスが途切れてしまうことが無くなる。
【００７１】
このように、ピアノードのみの構成であってもグローバルサービスを途切れなく提供することができる構成としてあるため、サーバやスーパーノードを設ける必要がなくなる。またこれにより、柔軟性の高いシステムを構築することができる。
【００７２】
また、サービスのサービス名をハッシュ化して得たサービスキーを基に、サービスをノードに割り当てるようにしたため、オーバレイネットワークを構成するすべてのノードに対して、サービスが公平かつ平等に割り当てられるようになる。よって、特定のノードに負荷が集中してしまうようなことがなくなる。
【００７３】
なお、ここまで説明した実施の形態では、分散ハッシュテーブルのアルゴリズムとしてＣｈｏｒｄを用いた場合を例に挙げて説明したが、これに限定されるものではなく、ＣＡＮやＰａｓｔｒｙ等、他のアルゴリズムを用いたシステムに適用してもよい。
【００７４】
また、上述した実施の形態では、テレビ会議システムに適用した例を示したが、ネットワークを構成する各端末間に性能の差が殆どないようなシステムであれば、例えばネットワークカメラを用いた監視システム等にも適用が可能である。監視システムに適用した場合には、端末の認証サービスや端末一覧取得サービス、イベント情報取得サービス等を実現することが可能となる。
【図面の簡単な説明】
【００７５】
【図１】本発明の一実施の形態によるテレビ会議システムの構成例を示す構成図である。
【図２】本発明の一実施の形態によるグローバルサービステーブルの構成例を示す説明図である。
【図３】本発明の一実施の形態によるサービス提供者ノードの処理例を示すフローチャートである。
【図４】本発明の一実施の形態によるサービス利用者における処理例を示すフローチャートである。
【図５】本発明の一実施の形態によるサービス受継ぎ時の処理例を示すフローチャートである。
【図６】本発明の一実施の形態によるオーバレイネットワークに参加時の処理例を示すフローチャートである。
【図７】本発明の一実施の形態によるオーバレイネットワークに参加時の処理例を示すフローチャートである。
【図８】本発明の一実施の形態によるノードの正常離脱時の処理例を示すフローチャートである。
【図９】本発明の一実施の形態によるノードの障害時の処理例を示すフローチャートである。
【図１０】本発明の一実施の形態によるサービスの動的割り当て処理例を示す説明図である。
【符号の説明】
【００７６】
１０…レンズ、１１…撮像部、１２…通信インターフェース部、１３…表示部、１４…マイクロフォン、１５…スピーカ、１６…音声処理部、１７…操作部、１８…制御部、１９…メモリ、２０…記憶部、Ｎ１〜Ｎ６…ノード、Ｓ１…サービス
【図１】
2008204299.tif 000003
【図２】
2008204299.tif 000004
【図３】
2008204299.tif 000005
【図４】
2008204299.tif 000006
【図５】
2008204299.tif 000007
【図６】
2008204299.tif 000008
【図７】
2008204299.tif 000009
【図８】
2008204299.tif 000010
【図９】
2008204299.tif 000011
【図１０】
2008204299.tif 000012
【手続補正書】
【提出日】平成20年3月28日(2008.3.28)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
少なくとも１つのノードが、分散ハッシュテーブル技術によりハッシュ空間上に割り当てられて構成されるオーバレイネットワークシステムであって、当該オーバレイネットワークシステムを構成するすべてのノードを対象とした少なくとも１つのサービスが提供されるオーバレイネットワークシステムにおいて、
前記ノードは、
前記サービスの名前であるサービス名と、前記サービスの実体であるサービス実体とを記憶する記憶部と、
前記サービス名をハッシュ化して得たサービスキーを用いて、現在サービスを提供中のサービス提供ノードを検索し、自ノードの識別情報をハッシュ化して得たノード識別子前記サービスキーとのハッシュ空間における距離が、前記サービス提供ノードのノード識別子と前記サービスキーとの距離よりも近い場合には、自ノードがサービス受継ぎ可能かを前記サービス提供ノードに確認し、前記サービス提供ノードより受継ぎを許可されたときは、自ノードの前記サービス実体を起動して前記サービスの提供を開始する制御部とを備えたことを特徴とする
オーバレイネットワークシステム。
【請求項２】
請求項１記載のオーバレイネットワークシステムにおいて、
前記ノードは、前記サービスの実施に際して必要となるデータであるサービス記録データファイルと前記サービス記録データファイルの名前であるサービス記録データファイル名を前記記憶部に記憶し、
前記制御部は、自ノードで前記サービスの提供を開始する場合に、前記サービス記録データファイル名をハッシュ化して得たサービス記録データファイルキーを用いて前記サービス記録データファイルキーに割り当てられるノードを検索し、前記検索されたノードに前記サービス記録データファイルを複写転送することを特徴とする
オーバレイネットワークシステム。
【請求項３】
請求項１記載のオーバレイネットワークシステムにおいて、
前記ノードは、前記サービス実体へのアクセス方法を記載したサービスプロファイルと前記サービスプロファイルの名前であるサービスプロファイル名を前記記憶部に記憶し、
前記制御部は、前記サービスを開始する場合に、前記サービスプロファイルを提供することを特徴とする
オーバレイネットワークシステム。
【請求項４】
請求項３記載のオーバレイネットワークシステムにおいて、
前記ノードの前記制御部は、前記サービスを利用する場合は、前記記憶部に記憶された前記サービス名をハッシュ化して得たサービスキーを用いて、前記サービスキーが割り当てられるノードを検索し、前記検索されたノードから前記サービスプロファイルを取得して前記サービス実体にアクセスすることを特徴とする
オーバレイネットワークシステム。
【請求項５】
請求項１記載のオーバレイネットワークシステムにおいて、
前記ノードの前記制御部は、自ノードで前記サービスを提供している場合で、当該オーバレイネットワークより離脱する場合には、自ノードの近傍のノードの中から、前記ノード識別子と前記サービス名をハッシュ化して得たサービスキーとのハッシュ空間上の距離が自ノードの次に近いノードを検索し、前記検索されたノードに対してサービス引継ぎ要求を送信することを特徴とするオーバレイネットワークシステム。
【請求項６】
請求項５記載のオーバレイネットワークシステムにおいて、
前記ノードの前記制御部は、他ノードから送信された前記サービス引継ぎ要求を受信した場合には、前記サービス記録データファイルキーを用いて前記サービス記録データファイルが記憶されたノードを検索し、前記検索されたノードから前記サービス記録データファイルを取得し、前記サービス実体を起動して前記サービスの提供を開始することを特徴とする
オーバレイネットワークシステム。
【請求項７】
請求項２記載のオーバレイネットワークシステムにおいて、
前記ノードの前記制御部は、前記近傍のノードの障害を検知した場合には、前記サービス名をハッシュ化して得たサービスキーを用いて前記サービスキーが対応付けられたすべてのノードを検索し、前記検索されたノードに対して前記サービスを提供中であるか否かの確認要求を送信することを特徴とする
オーバレイネットワークシステム。
【請求項８】
請求項７記載のオーバレイネットワークシステムにおいて、
前記ノードの前記制御部は、他ノードから送信された前記サービスを提供中であるか否かの確認要求を受信した場合には、自ノードで前記サービス実体を起動しているか否かを判断し、前記サービス実体を起動していない場合には、前記サービス記録データファイルキーを用いて前記サービス記録データファイルが記憶されたノードを検索し、前記検索されたノードから前記サービス記録データファイルを取得し、前記サービス実体を起動して前記サービスの提供を開始することを特徴とする
オーバレイネットワークシステム。
【請求項９】
少なくとも１つのノードが、分散ハッシュテーブル技術によりハッシュ空間上に割り当てられて構成されるオーバレイネットワークシステムであって、当該オーバレイネットワークシステムを構成するすべてのノードを対象とした少なくとも１つのサービスが提供されるオーバレイネットワークシステムにおけるサービス提供プログラムにおいて、  
前記ノードが、前記サービスの名前であるサービス名と、前記サービスの実体であるサービス実体とを記憶するステップと、
前記ノードが、前記サービス名をハッシュ化して得たサービスキーを用いて、現在サービスを提供中のサービス提供ノードを検索し、自ノードの識別情報をハッシュ化して得たノード識別子前記サービスキーとのハッシュ空間における距離が、前記サービス提供ノードのノード識別子と前記サービスキーとの距離よりも近い場合には、自ノードがサービス受継ぎ可能かを前記サービス提供ノードに確認し、前記サービス提供ノードより受継ぎを許可されたときは、自ノードの前記サービス実体を起動して前記サービスの提供を開始するステップとをコンピュータに実行させるための
サービス提供プログラム。
【請求項１０】
請求項９記載のサービス提供プログラムにおいて、
前記ノードが、前記サービスの実施に際して必要となるデータであるサービス記録データファイルと前記サービス記録データファイルの名前であるサービス記録データファイル
名を記憶するステップを有し、
前記サービスの提供を開始するステップでは、自ノードで前記サービスの提供を開始する場合に、前記サービス記録データファイル名をハッシュ化して得たサービス記録データファイルキーを用いて前記サービス記録データファイルキーに割り当てられるノードを検索し、前記検索されたノードに前記サービス記録データファイルを複写転送することを特徴とする
サービス提供プログラム。
【請求項１１】
請求項９記載のサービス提供プログラムにおいて、
前記ノードが、前記サービス実体へのアクセス方法を記載したサービスプロファイルと前記サービスプロファイルの名前であるサービスプロファイル名を記憶するステップを有し、
前記サービスの提供を開始するステップでは、前記サービスを開始する場合に、前記サービスプロファイルを提供することを特徴とする
サービス提供プログラム。
【請求項１２】
請求項１１記載のサービス提供プログラムにおいて、
前記ノードが前記サービスを利用する場合は、前記記憶された前記サービス名をハッシュ化して得たサービスキーを用いて、前記サービスキーが割り当てられるノードを検索し、前記検索されたノードから前記サービスプロファイルを取得して前記サービス実体にアクセスするステップを有することを特徴とする
サービス提供プログラム。
【請求項１３】
請求項９記載のサービス提供プログラムにおいて、
前記サービスの提供を開始するステップでは、自ノードで前記サービスを提供している場合で、当該オーバレイネットワークより離脱する場合には、自ノードの近傍のノードの中から、前記ノード識別子と前記サービス名をハッシュ化して得たサービスキーとのハッシュ空間上の距離が自ノードの次に近いノードを検索し、前記検索されたノードに対してサービス引継ぎ要求を送信することを特徴とする
サービス提供プログラム。
【請求項１４】
請求項１０記載のサービス提供プログラムにおいて、
前記サービスの提供を開始するステップでは、他ノードから送信された前記サービス引継ぎ要求を受信した場合には、前記サービス記録データファイルキーを用いて前記サービス記録データファイルが記憶されたノードを検索し、前記検索されたノードから前記サービス記録データファイルを取得し、前記サービス実体を起動して前記サービスの提供を開始することを特徴とする
サービス提供プログラム。
【請求項１５】
請求項１０記載のサービス提供プログラムにおいて、
前記ノードの前記制御部は、前記近傍のノードの障害を検知した場合には、前記サービ
ス名をハッシュ化して得たサービスキーを用いてすべての前記サービスキーが対応付けられたノードを検索し、前記検索されたノードに対して前記サービスを提供中であるか否かの確認要求を送信するステップを有することを特徴とする
サービス提供プログラム。
【請求項１６】
請求項１５記載のサービス提供プログラムにおいて
前記サービスの提供を開始するステップでは、他ノードから送信された前記サービスを提供中であるか否かの確認要求を受信した場合には、自ノードで前記サービス実体を起動しているか否かを判断し、前記サービス実体を起動していない場合には、前記サービス記録データファイルキーを用いて前記サービス記録データファイルが記憶されたノードを検索し、前記検索されたノードから前記サービス記録データファイルを取得し、前記サービス実体を起動して前記サービスの提供を開始することを特徴とする
サービス提供プログラム。
【手続補正３】
【補正対象書類名】明細書
【補正対象項目名】０００１
【補正方法】変更
【補正の内容】
【０００１】
本発明は、少なくとも１つのノードが、分散ハッシュテーブル技術によりハッシュ空間上に割り当てられて構成されるオーバレイネットワークシステム及び、そのオーバレイネットワークシステムに適用されるサービスを提供するためのサービス提供プログラムに関する。
【手続補正４】
【補正対象書類名】明細書
【補正対象項目名】００１５
【補正方法】変更
【補正の内容】
【００１５】
本発明は、少なくとも１つのノードが、分散ハッシュテーブル技術によりハッシュ空間上に割り当てられて構成されるオーバレイネットワークシステムであって、当該オーバレイネットワークシステムを構成するすべてのノードを対象とした少なくとも１つのサービスが提供されるオーバレイネットワークシステムにおいて、ノードに、サービスの名前であるサービス名と、サービスの実体であるサービス実体とを記憶する記憶部を備えた。そして、サービス名をハッシュ化して得たサービスキーを用いて、現在サービスを提供中のサービス提供ノードを検索し、自ノードの識別情報をハッシュ化して得たノード識別子とサービスキーとのハッシュ空間における距離が、サービス提供ノードのノード識別子とサービスキーとの距離よりも近い場合には、自ノードがサービス受継ぎ可能かをサービス提供ノードに確認し、サービス提供ノードより受継ぎを許可されたときは、サービス実体を起動してサービスの提供を開始するようにした。
【手続補正５】
【補正対象書類名】明細書
【補正対象項目名】００４１
【補正方法】変更
【補正の内容】
【００４１】
サービス記録データファイルを保存した後は、自ノード内のサービス記録データファイルが更新されたか否かの判断が行われる（ステップＳ５）。更新が行われない場合は何も処理を行わず、更新が行われた場合にはステップＳ４に戻って、更新したファイルをアップデート対象ノードに保存する。なお、自ノード内のサービス記録データファイルを、アップロード対象ノードに保存する処理は、自ノード内のサービス記録データファイルが更新されるたびに行われるものとする。
【手続補正６】
【補正対象書類名】明細書
【補正対象項目名】００４６
【補正方法】変更
【補正の内容】
【００４６】
サービス記録データファイルを入手した後は、サービス実体（プログラム）を開始する（ステップＳ２４）。そして、サービスを提供している間中、自ノード内のサービス記録データファイルが更新されたか否かの判断が行われる（ステップＳ２５）。更新が行われない場合は何も処理を行わず、更新が行われた場合には、更新したファイルをアップロード対象ノードに保存する（ステップＳ２６）。なお、自ノード内のサービス記録データファイルを、アップロード対象ノードに保存する処理は、自ノード内のサービス記録データファイルが更新されるたびに行われるものとする。なお、以降の説明においては、図５に示した処理を「サービス受継ぎフロー」と称する。