(57)【要約】【課題】大規模なネットワークにおいても共用情報の効率的な更新を実現する。【解決手段】ネットワークに含まれるノード装置で共用する共用情報を更新する際に、各ノード装置は、共用情報の過去の更新時に共用情報を送信したノード装置を更新相手として記憶し、共用情報の新たな更新時に、更新相手として記憶しているノード装置にのみ更新された共用情報を送信する。ノード装置Ａはノード装置Ｂ、Ｃ、Ｄを更新相手として記憶し、共用情報の新たな更新時に、ノード装置Ｂ、Ｃ、Ｄにのみ更新された共用情報を送信し、ノード装置Ｂ、Ｃ、Ｄでも同様に更新相手として記憶しているノード装置にのみ、ノード装置Ａから受信した共用情報を送信し、以降、ノード装置ごとに同様の処理が繰り返されてネットワークの全てのノード装置に共用情報を行き渡らせる。【選択図】図１
2011221625.tif 000002
【特許請求の範囲】
【請求項１】
複数の通信装置が含まれ、随時更新される共用情報を通信装置間で共用する通信ネットワークに含まれ、
共用情報が更新された際に、更新された共用情報を他のいずれかの通信装置に送信する通信装置であって、
前記共用情報の過去の更新時に、更新された共用情報を送信した通信装置を更新対象装置として示す更新対象装置情報を記憶する情報記憶部と、
前記共用情報が新たに更新された場合に、前記更新対象装置情報から更新対象装置を抽出する装置抽出部と、
前記装置抽出部により抽出された更新対象装置に対して、新たに更新された共用情報を送信する共用情報更新部とを有することを特徴とする通信装置。
【請求項２】
前記装置抽出部は、
前記更新対象装置情報から抽出した更新対象装置に、新たに更新された共用情報のバージョン値を通知し、
前記共用情報更新部は、
前記装置抽出部によりバージョン値が通知された更新対象装置から、新たに更新された共用情報を送信するよう要求された場合に、当該更新対象装置に対して、新たに更新された共用情報を送信することを特徴とする請求項１に記載の通信装置。
【請求項３】
前記共用情報更新部は、
新たに更新された共用情報に対する送信要求があった更新対象装置を新たな更新対象装置とする更新を前記更新対象装置情報に対して行うことを特徴とする請求項２に記載の通信装置。
【請求項４】
前記共用情報更新部は、
前記更新対象装置情報に示されている更新対象装置以外の通信装置から、新たに更新された共用情報を送信するよう要求された場合に、当該通信装置に対して、新たに更新された共用情報を送信するとともに、前記通信装置を新たな更新対象装置とする更新を前記更新対象装置情報に対して行うことを特徴とする請求項１〜３のいずれかに記載の通信装置。
【請求項５】
前記通信装置は、更に、
前記共用情報が、更新対象装置における更新処理時に当該更新対象装置の再起動が必要な再起動共用情報である場合に、更新対象装置が再起動を行うべき再起動タイミングを決定する再起動タイミング決定部を有し、
前記共用情報更新部は、
前記装置抽出部により抽出された更新対象装置に対して、新たに更新された再起動共用情報を送信するとともに、前記更新対象装置に対して前記再起動タイミング決定部により決定された再起動タイミングを通知することを特徴とする請求項１〜４のいずれかに記載の通信装置。
【請求項６】
前記再起動タイミング決定部は、
更新対象装置が複数ある場合に、複数の更新対象装置における再起動が特定の時刻に集中しないように各更新対象装置の再起動タイミングを決定することを特徴とする請求項５に記載の通信装置。
【請求項７】
前記再起動タイミング決定部は、
ネットワーク構成において近接している２以上の更新対象装置における再起動が特定の時刻に集中しないように各更新対象装置の再起動タイミングを決定することを特徴とする請求項６に記載の通信装置。
【請求項８】
複数の通信装置が含まれ、随時更新される共用情報を通信装置間で共用する通信ネットワークに含まれ、
共用情報が更新された際に、更新された共用情報を他のいずれかの通信装置に送信する通信装置が行う共用情報更新方法であって、
前記共用情報が新たに更新された場合に、前記通信装置が、前記共用情報の過去の更新時に、更新された共用情報を送信した通信装置を更新対象装置として示す更新対象装置情報を所定の記憶領域から読み出す情報読み出しステップと、
前記通信装置が、更新対象装置情報から更新対象装置を抽出する装置抽出ステップと、
前記通信装置が、前記装置抽出ステップにより抽出された更新対象装置に対して、新たに更新された共用情報を送信する共用情報更新ステップとを有することを特徴とする共用情報更新方法。
【請求項９】
複数の通信装置が含まれ、随時更新される共用情報を通信装置間で共用する通信ネットワークに含まれ、
共用情報が更新された際に、更新された共用情報を他のいずれかの通信装置に送信するコンピュータである通信装置に、
前記共用情報が新たに更新された場合に、前記共用情報の過去の更新時に、更新された共用情報を送信した通信装置を更新対象装置として示す更新対象装置情報を所定の記憶領域から読み出す情報読み出し処理と、
更新対象装置情報から更新対象装置を抽出する装置抽出処理と、
前記装置抽出処理により抽出された更新対象装置に対して、新たに更新された共用情報を送信する共用情報更新処理とを実行させることを特徴とするプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信ネットワークに含まれる通信装置（以下、ノード装置ともいう）間で共用する共用情報に更新があった場合に、更新後の共用情報をすべての通信装置に効率的に配布するための技術に関する。
より具体的には、分散ハッシュテーブル（以下、ＤＨＴという）を用いたオーバーレイネットワークに含まれる通信装置間での共用情報の配布に関する。
【０００２】
ノード装置間をピア・ツー・ピア型で構成した情報共有システムにおいて、大規模なネットワークを構成する際に、ＤＨＴを用いたオーバーレイネットワークの構築が行われることがある。
オーバーレイネットワークを用いることにより、各ノード装置が、ネットワークに参加している全てのノード装置へのリンク情報（例えば、ＩＰアドレス、ホストネーム等）を認識するのではなく、一部のノード装置のリンク情報のみを認識する。
そして、データ問い合わせを行うノード装置は、リンク情報を認識している一部のノード装置にデータ問い合わせを送信する。
以降は、データ問い合わせを受信したノード装置が自己がリンク情報を認識している一部のノード装置に対してデータ問い合わせを転送することを繰り返して、全てのノード装置に対して、データの問い合わせを行うことが可能となる。
オーバーレイネットワークは、ノード装置の数が爆発的に増えた際、非常に有効な手段である。
【背景技術】
【０００３】
従来のピア・ツー・ピア型の情報共有システムでは、各ノード装置に記憶しているファームウェア、アプリケーションソフトウェアや各種設定ファイル等の共通に使用する共用情報の更新、所謂バージョンアップもしくはアップデートを行うために、常に最新の共用情報を有するサーバを一台もしくは複数台設定している。
そして、このような情報共有システムでは、各ノード装置は、このサーバに対し、最新の共用情報に関する問い合わせを行い、もし最新の共用情報があった場合にはこのサーバからダウンロードすることになっている。
しかし、この方法では、システム規模が増大した場合、全てのノード装置からのアクセスがサーバに集中し、サーバ及びネットワークに対して過大な負荷をかけてしまい、結果としてスムーズに更新を行うことが難しいという課題がある。
【０００４】
この課題に対し、特許文献１の技術では、オーバーレイネットワーク上で各ノード装置がサーバに対して個々にアクセスするのではなく、システム内のノード装置間で定常的に行われるデータ通信に便乗することにより、サーバへの集中アクセスを分散させている。
【０００５】
より具体的には、特許文献１では、以下の更新方法が開示されている。
【０００６】
（１）メッセージを通知するためのメッセージデータのヘッダ部に「共用情報のバージョン情報」を追加し、このメッセージデータを送信することにより、メッセージデータを受け取った側では自装置で保有しているＳ／Ｗ（ソフトウェア）のバージョンと、受け取ったメッセージデータのヘッダ部に埋め込んだバージョンとを比較し、自身のバージョンが古かった場合、自身よりも新しいバージョンを有している他のノード装置から最新の共用情報を取得する。
【０００７】
（２）前記（１）において、共用情報（ファイル等に相当）のバージョン情報を記憶する手段を用意し、前記（１）と同様にデータ通信時に、受け取ったメッセージデータのヘッダ部に埋め込んだバージョンと自身の有する共用情報のバージョンを比較する際、直接共用情報を確認するのではなく、この「バージョン情報記憶手段」のバージョン情報と比較することにより、効率化を前記（１）と比べて図っている。
【０００８】
（３）前記（２）において、データ通信時に中継の役割を担っているノード装置において、前記（２）で記載したバージョン情報記憶手段に入っている情報をもメッセージデータのヘッダ部に追加し、次のノード装置へと転送を行う。
これにより、メッセージデータを受信したノード装置は、送信元のノード装置ではなく、近隣に位置し、最後の転送を実施したノード装置が保有するＳ／Ｗのバージョンとの比較を行える。
【０００９】
（４）前記（２）及び（３）において、同様にデータ通信時に、受け取ったメッセージデータのヘッダ部に埋め込んだバージョン情報と自身の有する共用情報のバージョンと比較を行うのであるが、メッセージデータのヘッダ部で通知されているバージョンが自身のものよりも新しいバージョンであった場合、即座に更新処理はせず、ある一定の回数だけ、新しいバージョンが存在することを確認してから、更新処理に取り掛かるようにする。
このような確認作業を入れることにより、即座に更新処理を行わなくなるため、システムネットワーク負荷を軽減できる、また、悪意のある者が意図的に不正なバージョンを送信したとしても回避できる効果がある。
【００１０】
（５）前記（４）では、要約すると、データ通信を複数回受け取り、所定の回数だけ「自分のＳ／Ｗが他のノードのＳ／Ｗよりも古い」と判明した場合に更新の手続きをとるものであった。
それに対し、（５）では、一回のデータ通信において、中継したノード装置が各々、メッセージデータのヘッダ部に次々とバージョン番号を数珠つなぎに埋め込みながら渡していく。
受信を行うノード装置は、メッセージデータのヘッダ部に多数埋め込んであるバージョン番号と比較をするのであるが、ここでも前記（４）に似たような判定方法を用いている。
それは、ある一定の数だけ、自分より新しいバージョンを有するノード装置があれば更新処理を行うというものである。
【００１１】
（６）前記（１）から（５）において、自身のＳ／Ｗのバージョンが古いと判断できた場合、照会手段を用いることにより、あらかじめ決めておいた特定のノード装置に対して、最新バージョンの照会を行い、古いと判断されたら、特定のノード装置に対して更新情報の要求が行えるようにする。
こうすることにより、サーバへの集中アクセスを分散化できるとともに特定のノード装置を指定できることより、クラッキング等を防止する効果がある。
【００１２】
（７）前記（１）〜（５）において、送信を行うノード装置では、データに共用情報のバージョン番号を入れるだけではなく、自己の識別番号もメッセージデータのヘッダ部に含ませる。
受信側ノード装置では、受け取ったデータのヘッダ部に含んでいるバージョン番号だけではなく、この識別情報をも比較する（手元には自ノード装置が厚い信頼を置いているノードが保有している識別番号が代入されている）ことにより、送信したデータが信頼できるものなのかの判定を行っている。
自ノード装置のバージョン番号がこの信頼を置いているノードよりも古ければ、信頼を置いているノードに対しアクセスを行い、更新を行う。
【００１３】
（８）前記（２）〜（４）において、送信を行うノード装置は、データのヘッダ部に自ノードのバージョン記憶手段に格納されているバージョン情報だけではなく、自己のネットワーク環境を示す指標値となるネットワーク環境情報をも含ませて送信を行う。
ネットワーク環境情報は、そのノード装置の有効帯域の高低であったり、定点からのＨＯＰ数であったり、あるいはＩＰアドレスのセグメント情報等である。
受信したノード装置は、自ノードのバージョン判別手段にて、更新情報を入手する相手先候補の中から、もっともネットワーク環境情報が良いものを選択し、そのノード装置に対して、共用情報更新を行う。
【先行技術文献】
【特許文献】
【００１４】
【特許文献１】特開２００７−５８２７５号公報
【発明の概要】
【発明が解決しようとする課題】
【００１５】
上述の特許文献１に示すＳ／Ｗ更新方法では、主に以下に示す課題があると考えられる。
【００１６】
（１）特許文献１では、更新のトリガとなっているのは、データ通信の必要性であり、とあるノード装置から別のとあるノード装置との間のものである。
これは、ネットワークにあまり負荷をかけず、通常の通信の妨害にならないよう更新作業を進めるのには適しているが、ネットワークに接続しているノード装置すべてが均等にやりとり（通信）できているという仮定の上になりたっている。
実際には、ネットワーク上のすべてのノード装置が均等に通信を行っていることはまれであるため、ネットワーク上のすべてのノード装置でＳ／Ｗの更新が完了するのがいつになるのかを想定することが難しい。
（２）また、特許文献１では、通信データのヘッダ部に通信経路となる各ノード装置の、バージョン情報を数珠つなぎに代入するが、これによって通信のオーバーヘッドを生じてしまう場合がある。
（３）また、特許文献１では、自ノードの有するバージョンが古いと判っても、セキュリティを高めるために、ある一定のノード分バージョンを比較して自ノードのバージョンが古いと認識した後でなければ、更新作業に移れない。このため、速やかな更新が行えない。
（４）また、Ｓ／Ｗの更新によっては、Ｈ／Ｗ（装置全体）のリブートを要するものも多々ある。しかし、特許文献１のＳ／Ｗ更新方法では、このような配慮がないため、更新が済んだものから順次リブートが発生してしまうため、たとえＤＨＴを利用したオーバーレイネットワークであっても、局所的なエリアでのリブートが併発してしまうと、システムの修復が完全にできなくなる（別系統のネットワークが発生してしまう）可能性があり、実用的ではない。
【００１７】
この発明は上記のような課題を解決することを主な目的の一つとし、大規模なネットワークにおいても効率的な共用情報の更新を行うことを主な目的とする。
【課題を解決するための手段】
【００１８】
本発明に係る通信装置は、
複数の通信装置が含まれ、随時更新される共用情報を通信装置間で共用する通信ネットワークに含まれ、
共用情報が更新された際に、更新された共用情報を他のいずれかの通信装置に送信する通信装置であって、
前記共用情報の過去の更新時に、更新された共用情報を送信した通信装置を更新対象装置として示す更新対象装置情報を記憶する情報記憶部と、
前記共用情報が新たに更新された場合に、前記更新対象装置情報から更新対象装置を抽出する装置抽出部と、
前記装置抽出部により抽出された更新対象装置に対して、新たに更新された共用情報を送信する共用情報更新部とを有することを特徴とする。
【発明の効果】
【００１９】
本発明によれば、共用情報の過去の更新時に共用情報を送信した更新対象装置を示す更新対象装置情報を記憶し、共用情報が新たに更新された場合に、更新対象装置に対して、新たに更新された共用情報を送信するため、通信装置間の偶発的なデータ通信に基づく場合に比較して、効率的かつ確実に共用情報を通信ネットワーク全体に対し行き渡らすことが可能となる。
【図面の簡単な説明】
【００２０】
【図１】実施の形態１に係るノード装置間の更新の依存関係の例を示す図。
【図２】実施の形態１に係るノード装置Ａが保有する更新相手リストの例を示す図。
【図３】実施の形態１に係るノード装置Ｂが保有する更新相手リストの例を示す図。
【図４】実施の形態１に係るノード装置の構成例を示す図。
【図５】実施の形態１に係るノード装置の動作例を示すフローチャート図。
【図６】実施の形態１に係るノード装置の動作例を示すフローチャート図。
【図７】実施の形態２に係るノード装置の構成例を示す図。
【図８】実施の形態２に係るノード装置間の接続例を示す図。
【図９】実施の形態２に係るネットワークを分割する平面グラフの例を示す図。
【図１０】実施の形態２に係るネットワークを分割する色分けの例を示す図。
【図１１】実施の形態２に係るノード装置の動作例を示すフローチャート図。
【図１２】実施の形態１及び２に係るノード装置のハードウェア構成例を示す図。
【発明を実施するための形態】
【００２１】
実施の形態１．
本実施の形態では、各ノード装置において、自身が更新を施した相手ノード装置の一覧（更新相手リスト）を備えることにより、短い間隔で新たな更新が行われた際、速やかに最新のバージョンを送り届けることを可能としている。
以下、図面を参照しながら説明する。
【００２２】
図１は、本実施の形態に係る通信ネットワーク１０（例えば、オーバーレイネットワーク）に含まれるノード装置Ａ〜Ｓの更新の依存関係を示す例である。
図１では、ノード装置Ａから共用情報（更新ファイル名“ｂｉｏｓ．ｄａｔ”、バージョン番号“１．０１”のファイル）を与え、それが次第に他のノード装置に伝達した例を示している。
矢印は、共用情報の伝達の方向を表す。
なお、共用情報とは、通信ネットワーク１０に含まれる各ノード装置で共用される情報であり、また随時更新される情報である。
共用情報は、例えばアプリケーションソフトウェアであり、また、更新された共用情報は、例えば、バージョン番号（バージョン値）により識別可能である。
なお、各ノード装置は、通信装置の例である。
【００２３】
図２は、図１の例において、ノード装置Ａが保有する更新相手リストを示しており、ここでは、２種類の更新ファイル名の記録が書いてある例を示している。
まず、更新ファイル名（１００Ａ）には“ｂｉｏｓ．ｄａｔ”（１０１Ａ）が、バージョン番号（１１０Ａ）には“１．０１”（１１１Ａ）が、更新ファイルを送信した相手（１２０Ａ）にはＢ（１２１Ａ）、Ｃ（１２２Ａ）、Ｄ（１２３Ａ）の各ノード装置が記されている。
また、更新ファイル名（１３０Ａ）には“ｄｅｖｉｃｅ．ｄａｔ”（１３１Ａ）が、バージョン番号（１４０Ａ）が“２．０１”（１４１Ａ）の時の更新ファイルを送信した相手（１５０Ａ）としてＢ（１５１Ａ）、Ｃ（１５２Ａ）、Ｄ（１５３Ａ）、Ｅ（１５４Ａ）の各ノード装置が記されている。
また、バージョン番号（１６０Ａ）が“２．０２”（１６１Ａ）の時の更新ファイルを送信した相手（１７０Ａ）としてＣ（１７１Ａ）、Ｄ（１７３Ａ）の各ノード装置が記されている。
【００２４】
同様に図３には、ノード装置Ｂが保有する更新相手リストの例を示しており、ここでは、更新ファイル名（１００Ｂ）には“ｂｉｏｓ．ｄａｔ”（１０１Ｂ）が、バージョン番号（１１０Ｂ）には“１．０１”（１１１Ｂ）が、更新ファイルを送信した相手（１２０Ｂ）には、Ｅ（１２１Ｂ）、Ｆ（１２２）Ｂ、Ｇ（１２３Ｂ）、Ｈ（１２４Ｂ）、Ｉ（１２５Ｂ）の各ノード装置が記入されている。
残りのノード装置が保有する更新相手リストについては省略するが、図１に示した矢印の先にあるノード装置が図２及び図３と同様の形式で示される更新相手リストが各ノード装置に存在する。
【００２５】
図１のような更新の依存関係がある状況において、更新された共用情報である更新ファイル“ｂｉｏｓ．ｄａｔ”、バージョン番号“１．０２”がノード装置Ａに到着した場合を例にして、本実施の形態に係るノード装置の構成及び動作を図４を用いて説明する。
【００２６】
図４において、４００ａは送信側のノード装置である。ここの例ではノード装置Ａとする。
４００ｂは受信側のノード装置である。例えば、ノード装置Ｂである。
【００２７】
４０１ａと４０１ｂは共用情報更新部である。
４０２ａと４０２ｂは共用情報である。
共用情報更新部４０１ａは、共用情報４０２ａを後述の通信部４０５ａを介してノード装置４００ｂに送信する。
また、共用情報更新部４０１ｂは、後述の通信部４０６ｂを介してノード装置４００ａから共用情報４０２ａを受信し、情報記憶部４１０ｂに共用情報４０２ｂとして格納する。
なお、図４では、共用情報４０２ａが通信部４０５ａから送信されるようには示されておらず、共用情報４０２ａが通信部４０６ｂにより受信されるようには示されていないが、これは作図上の理由であり、共用情報４０２ａは通信部４０５ａから送信され、共用情報４０２ａは通信部４０６ｂにより受信されるものとする。
また、以下の説明において、共用情報更新部４０１ａが共用情報４０２ａを送信するとの記述、共用情報更新部４０１ｂが共用情報４０２ａを受信するとの記述は、それぞれ、通信部４０５ａ及び通信部４０６ｂを介して送信、受信を行う意味である。
また、
【００２８】
４０３ａは、送信側のノード装置４００ａが送信する送信データである。
４０４ａと４０４ｂは、（共用情報の）バージョン番号（バージョン値）である。
４０５ａは、送信側のノード装置４００ａにおいて送信データ４０３ａを送信する通信部である。
４０６ｂは、受信側のノード装置４００ｂにおいて送信データ４０３ａを受信する通信部である。
４０７ｂは、前述の通信部４０６ｂで受け取った受信データ（内容は、送信データ４０３ａと一致）である。
【００２９】
４０８ａと４０８ｂは、バージョン判別部である。
受信側のノード装置４００ｂのバージョン判別部４０８ｂは、他のノード装置から通知された共用情報のバージョン番号と自ノードで保有している共用情報のバージョン番号とを比較する。
送信側のノード装置４００ａのバージョン判別部４０８ａは、他のノード装置から共用情報のバージョン番号を通知された際に、バージョン判別部４０８ｂと同じ動作を行う。
【００３０】
４２０ａと４２０ｂは、更新監視部である。
送信側のノード装置４００ａの更新監視部４２０ａは、共用情報４０２ａが更新されたので、他のノード装置に対して更新処理を行う。
より具体的には、共用情報４０２ａが更新された際に、後述する更新相手リスト４３０ａから更新相手のノード装置を抽出し、抽出したノード装置に対して、（共用情報の）バージョン番号４０４ａが含まれる送信データ４０３ａを生成し、抽出したノード装置に対して送信データ４０３ａを通信部４０５ａを介して送信する。
受信側のノード装置４００ｂの更新監視部４２０ｂは、ノード装置４００ｂが他のノード装置に対して（共用情報の）バージョン番号４０４ｂを通知する際に、更新監視部４２０ａと同じ動作を行う。
更新監視部４２０ａ、４２０ｂは、装置抽出部の例である。
【００３１】
４３０ａと４３０ｂは、自ノード装置が有する共用情報４０２ａ、４０２ｂについての更新を施した相手ノード装置の一覧を有する更新相手リストである。
更新相手リスト４３０ａ、４３０ｂは、図２、図３に示した情報であり、過去の共用情報の更新時に、更新された共用情報を送信したノード装置を更新相手（更新対象装置）として示す情報である。
図２及び図３から明らかなように、更新相手リスト４３０ａ、４３０ｂは、それぞれ内容が異なっている。
更新相手リスト４３０ａ、４３０ｂは、更新対象装置情報の例である。
【００３２】
４１０ａ、４１０ｂは、情報記憶部である。
情報記憶部４１０ａは、共用情報４０２ａ、（共用情報の）バージョン番号４０４ａ、更新相手リスト４３０ａを記憶する。
情報記憶部４１０ｂは、共用情報４０２ｂ、（共用情報の）バージョン番号４０４ｂ、更新相手リスト４３０ｂを記憶する。
【００３３】
なお、更新監視部４２０ａ、４２０ｂ、更新相手リスト４３０ａ、４３０ｂを除く残りの構成要素はすべて、特許文献１に記載の要素であってもよい。
このため、これらの構成要素を用いた送信側ノード装置４００ａと受信側ノード装置４００ｂとの間ではデータ送信に便乗した形での共用情報の更新作業が行われてもよい。
【００３４】
次に、本実施の形態に係るノード装置４００の動作をフローチャートを用いて説明する。
図５が受信側のノード装置４００ｂの動作例を示し、図６が送信側のノード装置４００ａの動作例を示す。
以下では、新たな更新ファイル“ｂｉｏｓ．ｄａｔ”、バージョン番号“１．０２”がノード装置Ａに到着した例を用いて説明を進める。
また、以下では、ノード装置４００ａの構成要素を用いて、ノード装置Ａの動作を説明し、また、ノード装置４００ｂの構成要素を用いて、ノード装置Ｂの動作を説明する。
【００３５】
まず、ノード装置Ａ内の更新監視部４２０ａが、更新相手リスト４３０ａを読み出す（図６のＳ６０１）（情報読み出しステップ）。
【００３６】
次に、ノード装置Ａ内の更新監視部４２０ａは、更新相手リスト４３０ａに示される更新相手のうち、更新されたファイル名と同じファイル名に対して示されている更新相手を抽出する（Ｓ６０２）（装置抽出ステップ）。
ノード装置Ａの更新相手リスト４３０ａは、図２に示す内容であり、更新監視部４２０ａは、リストの中の更新ファイル名“ｂｉｏｓ．ｄａｔ”の検索を行う。
図２中では、１０１Ａに同ファイル名があるので、更新監視部４２０ａは、そのリストの相手（１２０Ａ）に挙げられているノード装置Ｂ（１２１Ａ）、ノード装置Ｃ（１２２Ａ）、ノード装置Ｄ（１２３Ａ）の三つが、過去の古いバージョンの更新を実施しに自ノード装置に対してアクセスを行い、また、自ノード装置がこれらのノード装置にして過去のバージョンのファイルを送信したことが分かる。
【００３７】
次に、ノード装置Ａの更新監視部４２０ａは、Ｓ６０２で抽出した更新相手のノード装置（ノード装置Ｂ、Ｃ、Ｄ）の更新監視部に共用情報に新しいバージョンがある旨を伝える（Ｓ６０３）。
具体的には、更新監視部４２０は、（共用情報の）バージョン番号４０４ａが含まれる送信データ４０３ａを生成して、通信部４０５ａから対象となるノード装置に送信データ４０３ａを送信する。
なお、前述のように、特許文献１に開示の方法と同様に、他の用途の送信データ４０３ａに（共用情報の）バージョン番号４０４ａを含ませるようにしてもよい。
なお、以下では、ノード装置Ｂに対して送信データ４０３ａを送信した際の動作のみを説明するが、他のノード装置に対しても同様である。
【００３８】
ノード装置Ｂでは、通信部４０６ｂが、更新された共用情報のバージョン番号４０４ａが含まれる送信データ４０３ａを受信する（図５のＳ５０１）。
なお、ノード装置Ｂ内では送信データ４０３ａは受信データ４０７ｂと表現する。
ノード装置Ｂのバージョン判別部４０８ｂが、受信データ４０７ｂに含まれているバージョン番号４０４ａ（“ｂｉｏｓ．ｄａｔ”の“１．０２”）が、自ノードの情報記憶部４１０ｂ内のバージョン番号４０４ｂよりも新しいか否かを判断する。
受信データ４０７ｂに含まれているバージョン番号４０４ａが新しいと判断した場合は、共用情報更新部４０１ｂがノード装置Ａの共用情報更新部４０１ａ宛てに共用情報の送信要求を通信部４０６ｂから送信し、共用情報更新部４０１ａから送信された共用情報（“ｂｉｏｓ．ｄａｔ”のバージョン“１．０２”）を通信部４０６ｂを介して受信し、受信した共用情報を新たな共用情報４０２ｂとして情報記憶部４１０ｂに格納する（Ｓ５０２）。
【００３９】
ノード装置Ａでは、共用情報更新部４０１ａが通信部４０５ａを介して、共用情報更新部４０１ｂからの送信要求を受信し（図６のＳ６０４でＹＥＳ）、更新された共用情報（“ｂｉｏｓ．ｄａｔ”のバージョン“１．０２”）を通信部４０５ａを介してノード装置Ｂに送信する（Ｓ６０５）（共用情報更新ステップ）。
【００４０】
Ｓ６０３でバージョン番号を通知した全ての更新相手に対して処理を終えている場合は（Ｓ６０６でＹＥＳ）、Ｓ６０７において更新相手リストの更新が行われる。
全ての更新相手に対して処理を終えている場合とは、更新相手の各ノード装置について、更新後の共用情報の送信が完了しているか、又は共用情報の送信は不要との応答を受領している場合である。
【００４１】
Ｓ６０７では、共用情報更新部４０１ａが、更新があったファイル名、バージョン番号、更新を行ったノード装置を更新相手リスト４３０ａに追加し、更新相手リスト４３０ａを更新する。
例えば、ファイル名“ｂｉｏｓ．ｄａｔ”のバージョン“１．０２”について、ノード装置Ｂ、Ｃ、Ｄに対して更新を行った場合は、図２の更新相手リストの１２３Ａと１３１Ａの間に、１１１Ａ、１２１Ａ、１２２Ａ、１２３Ａと同様の形式にて、“バージョン番号：１．０２”、“相手：Ｂ”、“相手：Ｃ”、“相手：Ｄ”という４行が追加される。
【００４２】
一方、ノード装置Ｂでは、図５のＳ５０２により共用情報４０２ｂが更新された後、共用情報更新部４０１ｂが、更新監視部４２０ｂを呼び出し、更新監視部４２０ｂに更新があったファイル名およびバージョン番号を伝える（Ｓ５０３）。
更新監視部４２０ｂは、共用情報更新部４０１ｂから受け取った情報をもとに更新相手リスト４３０ｂを参照し、同じファイルを更新するために過去に自ノードにアクセスしてきたことのある更新相手のノード装置（図１及び図３の例では、ノード装置Ｅ〜Ｉ）を調べ、それらの更新相手のノード装置に対して、更新された共用情報４０２ｂのバージョン番号を、通信部４０６ｂを介して送信し、また、共用情報更新部４０１ｂが更新相手のノード装置に更新された共用情報４０２ｂを送信する（Ｓ５０４）。
具体的には、ノード装置Ｂが送信側のノード装置４００ａとなり、ノード装置Ｅ〜Ｉに対して図６に示す処理を行って、ノード装置Ｅ〜Ｉに更新された共用情報４０２ｂを送信する。
また、ノード装置Ｅ〜Ｉでも、図５及び図６の処理が繰り返し行われる。
【００４３】
なお、図６のフローでは、ノード装置Ａは、更新相手のノード装置Ｂ〜Ｄに並行してＳ６０３〜Ｓ６０５を行う例としているが、これに代えて、ノード装置ＢへＳ６０３及びＳ６０４の処理をはじめに行い、ノード装置Ｂへの処理が完了した後に、更新相手リスト４３０ａにある残りのノード装置Ｃ、ノード装置Ｄに対して、順次ノード装置Ｂへ実施したのと同じ処理を行うようにしてもよい。
【００４４】
また、図６のフローでは、更新相手のノード装置に対してバージョン番号を通知し、更新相手のノード装置から送信要求があった際に共用情報を送信するようにしているが、バージョン番号の通知及び送信要求の受信を省略して、即座に更新相手のノード装置に共用情報を送信するようにしてもよい。
【００４５】
また、最初のノード装置Ａに対する共用情報の更新方法はどのようなものでもよい。例えば、手動での更新でも良いし、リモート操作での更新、特許文献１に示されている更新方法でもよい。
【００４６】
また、ノード装置Ａにおいて、更新相手リスト４３０ａに列挙されていない新規のノード装置から共用情報４０２ａの送信を要求された場合には、共用情報更新部４０１ａは、当該新規のノード装置に共用情報４０２ａを送信するとともに、当該新規のノード装置を新たな更新相手として更新相手リスト４３０ａに含ませて更新相手リスト４３０ａを更新する。
【００４７】
また、本実施の形態に示す方式とともに特許文献１に示す方式を並行して実施してもよい。
なお、特許文献１に示す方式では、ノード装置間でのデータ通信がないと共用情報に新たなバージョンがあることがシステム全体に行き渡るのに時間がかかりすぎるため、各ノード装置は、自身が保有している共用情報のバージョン番号を近傍のノード装置に周期的に知らせることを行う、または逆に近傍のノードに対して問い合わせを出す等を行うことで、積極的に新バージョンの浸透を促してもよい。
なお、近傍を何ホップ先までとするのか、頻度をどれくらい高めるのか等は、そのシステムのネットワーク負荷の状況によって調整を行う必要あり、本動作は、図４中の更新監視部で行われる。
【００４８】
なお、本実施の形態では、背景技術の（１）及び（２）として説明した方式（ノード装置Ｂにおいてノード装置Ａから通知されたバージョンと自身のバージョンを比較して、自身のバージョンが古ければ、ノード装置Ａに共用情報の送信を要求する）に対応させて説明を行ったが、（３）〜（８）のすべての方式において同様に本実施の形態に示した方式をあてはめることにより、効率的に更新を行うことが可能である。
また、ベースとなっているオーバーレイネットワーク及びオーバーレイネットワーク上に配置されるノード装置は、本明細書で明示していない機能、構成については特許文献１に記載のものと同様とすることができる。
【００４９】
以上、本実施の形態によれば、自ノード装置内に、更新監視を行う更新監視制御部と、自ノード装置に対して更新情報を要求してきたノード装置の一覧である更新相手リストを有することにより、新しいバージョンの共用情報がシステムに注入した際、システム全体に対し、速やかに新しいバージョンの共用情報を行き渡らすことが可能となる。
また、新しいバージョンの共用情報を受け取った新たなノード装置は、自主的に自身の有している更新相手リストを検索し、さらに、自身の更新相手のノード装置に対して更新作業を実施していく。これにより、更なるシステム全体の速やかな更新が可能となる。
【００５０】
つまり、本実施の形態では、各ノード装置において、自身が更新を施した相手ノード装置の一覧（更新相手リスト）を備えることにより、短い間隔で新たな更新が行われた際、速やかに最新のバージョンを送り届けることを可能としている。
そして、本実施の形態によれば、更新ファイルがシステムに流れ始めた後に立て続けに新たな更新ファイルを行き渡らせなければならない時、各々のノード装置が、過去にどのノード装置に対して、更新ファイルを流布したかの記録をもとに、自発的に更新を促す通信（どのように実現してもよい、例えば特別な更新チェック用のプロトコルでもよい）を行い、積極的に更新作業を行うことが可能となる。
従来方法では、ノード装置間での偶発的なデータ通信に頼らなければならないため、どうしても更新作業を速やかに行いたくても不可能であったが、本実施の形態の方式を用いれば速やかに更新できる。
【００５１】
また、本実施の形態では、普段のデータ通信時に更新作業を行う方法ではないため、従来手法のようにネットワークに対し、負荷をかけることなく更新することが可能となる。
局所的には負荷が高くなるが、それは更新を必要としているノード近辺だけである。従来方法によれば、すでに更新済みのノード装置が途中にあれば、それらまで巻き込んで通信するため、結果としてネットワーク負荷を高めてしまう可能性がある。
なお、本実施の形態の方式において更新相手リストの最大値を取り決めることにより、局所的なノード装置に更新流布の負荷が集中することを回避することが可能である。
【００５２】
以上、本実施の形態では、サーバ等の特定の装置に過大な負荷を与えることなく、各ノード装置が保持する共用情報を最新のものに更新する際、情報が短時間の間に、何回も更新する場合もしくは、一度更新が行われたが、急に改めて更新を行わなければならなくなった場合であっても、「誰に対して更新を施したか」を記録しておくことにより、各ノード装置に対して効率的に反映を行う方式を説明した。
【００５３】
実施の形態２．
本実施の形態では、実施の形態１に示した方法により共用情報の受け渡しを行う際、新しいバージョンの共用情報を受け取った近傍の複数のノード装置が、一斉にリブートしてしまうことにより、システムに影響を与えてしまうことを回避する方法を説明する。
【００５４】
更新する共用情報が、ＢＩＯＳ（Ｂａｓｉｃ  Ｉｎｐｕｔ  Ｏｕｔｐｕｔ  Ｓｙｓｔｅｍ）やＯＳ（Ｏｐｅｒａｔｉｎｇ  Ｓｙｓｔｅｍ）、または一部の特殊なデバイスドライバであった場合、ノード装置のリブートが必要である。
大規模なシステムの場合、ノード装置のリブート操作は、人手で行うことは不可能であるため、各ノード装置が自発的に再起動を行う方法をとる。
再起動にはどうしても一定の時間がかかってしまうため、多くのノード装置がほぼ同時にリブートを開始してしまうと、ネットワークに残っているノード装置だけでは、システムを維持できなくなってしまう可能性がある。
本実施の形態では、共用情報の更新に伴い速やかなマシンリブートが必要となる場合、共用情報の更新を実施したノード装置が次から次へと一斉にシャットダウンをしないよう、順位づけを行う。
【００５５】
図７は、本実施の形態に係るノード装置４００の構成例を示す。
図中の送信側のノード装置４００ａ、受信側のノード装置４００ｂ、共用情報更新部４０１ａ、４０１ｂ、共用情報４０２ａ、４０２ｂ、送信データ４０３ａ、（共用情報の）バージョン番号４０４ａ、４０４ｂ、通信部４０５ａ、通信部４０６ｂ、受信データ４０７ｂ、バージョン判別部４０８ａ、４０８ｂ、情報記憶部４１０ａ、４１０ｂ、更新監視部４２０ａ、４２０ｂ、更新相手リスト４３０ａ、４３０ｂは図４に示したものと同様であり、説明を省略する。
図７において新たに追加された要素は、４４０ａと４４０ｂの再起動タイミング決定部、４４１ａと４４１ｂの再起動タイミング通知、４５０ａと４５０ｂの再起動実行部である。
【００５６】
再起動タイミング決定部４４０ａ、４４０ｂは、共用情報の更新を行った後、リブートが必要となった場合のタイミングを計る。
より具体的には、受信側のノード装置４００ｂでのリブート（再起動）が必要な共用情報（再起動共用情報）である場合に、受信側のノード装置４００がリブートを行うべきタイミング（再起動タイミング）を決定する。
【００５７】
もっとも簡単な対処としては、受信側のノード装置４００ｂの再起動タイミング決定部４４０ｂが、乱数を発生し、乱数に従って所定時間だけ待つようにし、それから再起動実行部４５０ｂを呼び出してもよい。
例えば、乱数を０．０から１．０の間で発生させ、それに１分をかけた時間だけ待つようにする方法がある。
【００５８】
また、本実施の形態でも、送信側のノード装置４００ａの共用情報更新部４０１ａが、実施の形態１で説明したように、更新相手リスト４３０ａ上のノード装置に対して新しいバージョンの共用情報４０２ａを送信するが、その際、再起動タイミング決定部４４０ａが決定したリブートを行う順番を通知する数値を再起動タイミング通知４４１ａとして併せて送る方法もある。
このような方法では、受信側のノード装置４００ｂでは、再起動タイミング決定部４４０ｂが再起動タイミング通知４４１ａを取得し、共用情報の更新終了後、再起動タイミング通知４４１ａで通知されている数値を参照し、適宜待ち時間を計算し、待ち時間の経過後に再起動実行部４５０ｂを呼び出す。
【００５９】
同時に更新を行うノード装置が５台ある場合、例として図１と図３におけるノード装置Ｂが、ノード装置Ｅ、Ｆ、Ｇ、Ｈ、Ｉへ更新を行う場合を用いて説明する。
ノード装置Ｂの再起動タイミング決定部４４０ａは、ノード装置Ｅに１、ノード装置Ｆに２、ノード装置Ｇに３、ノード装置Ｈに４、ノード装置Ｉに５を決定し、再起動タイミング通知４４１ａにおいて各ノード装置に各値を通知する。
例えば、ノード装置がリブートするのに必要とする時間が２分だとすれば、再起動タイミング通知４４１ａに示されている値に従い、ノード装置Ｅは１×２＝２分、ノード装置Ｆは２×２＝４分、同様にノード装置Ｇは６分、ノード装置Ｈは８分、ノード装置Ｉは１０分後にリブートを行う。
これにより、近傍のノードが同時にリブートしてしまい、システムのネットワーク通信に影響を及ぼしてしまうことを回避することができる。
【００６０】
また、更新相手リスト４３０ａに数十ノードといった、膨大な数のノード装置があった場合、リブートの順番となる数値を単純にインクリメントしただけでは、後半の順番のノード装置４００ｂでは、無駄にリブートを待たされてしまう。
このため、再起動タイミング決定部４４０ａは、更新相手のノード装置に、例えば、１〜４の数値を繰り返し割り振るようにする。
割り振り方には、送信側のノード装置４００ａに接続する近傍のノード装置同士が隣り合わせの数値又は同じ数値にならないように行う。
このように１〜４を割り振り、送信側のノード装置に接続しているノード装置同士のうち、同じ数値を持つものだけがリブートするようにすることで、受信側の各ノード装置が一つ一つリブートの順を待つよりも効率的にリブート作業が完了できる。
【００６１】
なお、各ノード装置を１〜４に割り振る場合は、あらかじめシステムのすべてのノード装置を、ノード装置間で実際に通信を行うことができるネットワーク接続経路を境界線とした平面グラフにし、それぞれの領域をノード装置と見立て、色分けを行う。
色分けは四色定理により、隣り合わせ同士のノード装置が必ず別の色になるように塗り分けることが可能である。
このように各ノードを１〜４に分類しておくことにより、ノード装置がリブートする際、４つのグループに分かれてそれぞれのグループが別々に（順に）リブートを行う。
なお、グループは四色定理で分けてあるため、隣り合わせたノード装置が同時にリブートすることがない、つまり、必ず回避できる経路の確保が保障される。
但し、隣り合わせではない、任意のノード装置を２つ選んだ時、その２つのノード装置間に挟まれる中間のノード装置による回避経路が最低２つある場合に限る。関所が一点しかない場合はその一点がリブートしたら迂回経路は確保できないためである。
【００６２】
この方法を用いれば、仮にシステム内のすべてのノード装置が新しいバージョンへの更新を同時に行った場合であっても、一斉にリブートすることなく、常にシステムが稼働できる状況を維持することが可能となる。
【００６３】
図８は、図１の例のベースとなっているネットワークのノード間の接続関係を示す。
図９は、図８を平面グラフにしたものであり、図９の平面グラフをもとに図８の各ノードを色分けしたものが、図１０である。
【００６４】
また、図１１は、本実施の形態に係る送信側のノード装置４００ａの動作例を示す。
図１１では、Ｓ１１０１、Ｓ１１０２以外のステップは図６と同じである。
Ｓ１１０１では、共用情報が更新時に再起動を伴うものであれば、再起動タイミング決定部４４０ａが更新相手ごとに再起動タイミングを決定し、Ｓ１１０２では、共用情報更新部４０１ａが共用情報４０２ａとともに、再起動タイミング通知４４１ａを送信する。
受信側のノード装置４００ｂでは、上述の通り、再起動タイミング決定部４４０ｂが再起動タイミング通知４４１ａを取得し、共用情報の更新終了後、再起動タイミング通知４４１ａで通知されている数値を参照し、適宜待ち時間を計算し、待ち時間の経過後に再起動実行部４５０ｂを呼び出す。
再起動実行部４５０ｂでは、呼び出されると、所定の手順で再起動を行う。
【００６５】
このように、本実施の形態では、共用情報が更新時に再起動を伴うものである場合に、ノード装置ごとに再起動のタイミングを調整しているので、共用情報を受け取った複数のノード装置が一斉にリブートしてしまうことによりシステムに影響を与えてしまう事態を回避することができる。
【００６６】
以上、本実施の形態では、共用情報の更新に伴い速やかなマシンリブートが必要となる場合、共用情報の更新を実施したノード装置が次から次へと一斉にシャットダウンをしないよう、順位づけを行うことを説明した。
【００６７】
最後に、実施の形態１及び２に示したノード装置４００のハードウェア構成例について説明する。
図１２は、実施の形態１及び２に示すノード装置４００のハードウェア資源の一例を示す図である。
なお、図１２の構成は、あくまでもノード装置４００のハードウェア構成の一例を示すものであり、ノード装置４００のハードウェア構成は図１２に記載の構成に限らず、他の構成であってもよい。
【００６８】
図１２において、ノード装置４００は、プログラムを実行するＣＰＵ９１１（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ、中央処理装置、処理装置、演算装置、マイクロプロセッサ、マイクロコンピュータ、プロセッサともいう）を備えている。
ＣＰＵ９１１は、バス９１２を介して、例えば、ＲＯＭ（Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ）９１３、ＲＡＭ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）９１４、通信ボード９１５、表示装置９０１、キーボード９０２、マウス９０３、磁気ディスク装置９２０と接続され、これらのハードウェアデバイスを制御する。
更に、ＣＰＵ９１１は、ＦＤＤ９０４（Ｆｌｅｘｉｂｌｅ  Ｄｉｓｋ  Ｄｒｉｖｅ）、コンパクトディスク装置９０５（ＣＤＤ）、プリンタ装置９０６、スキャナ装置９０７と接続していてもよい。また、磁気ディスク装置９２０の代わりに、光ディスク装置、メモリカード（登録商標）読み書き装置などの記憶装置でもよい。
ＲＡＭ９１４は、揮発性メモリの一例である。ＲＯＭ９１３、ＦＤＤ９０４、ＣＤＤ９０５、磁気ディスク装置９２０の記憶媒体は、不揮発性メモリの一例である。これらは、記憶装置の一例である。
実施の形態１及び２で説明した「情報記憶部４１０」は、ＲＡＭ９１４、磁気ディスク装置９２０等により実現される。
通信ボード９１５、キーボード９０２、マウス９０３、スキャナ装置９０７、ＦＤＤ９０４などは、入力装置の一例である。
また、通信ボード９１５、表示装置９０１、プリンタ装置９０６などは、出力装置の一例である。
【００６９】
通信ボード９１５は、図１等に示すように、ネットワークに接続されている。例えば、通信ボード９１５は、ＬＡＮ（ローカルエリアネットワーク）、インターネット、ＷＡＮ（ワイドエリアネットワーク）、ＳＡＮ（ストレージエリアネットワーク）などに接続されていても構わない。
【００７０】
磁気ディスク装置９２０には、オペレーティングシステム９２１（ＯＳ）、ウィンドウシステム９２２、プログラム群９２３、ファイル群９２４が記憶されている。
プログラム群９２３のプログラムは、ＣＰＵ９１１がオペレーティングシステム９２１、ウィンドウシステム９２２を利用しながら実行する。
【００７１】
また、ＲＡＭ９１４には、ＣＰＵ９１１に実行させるオペレーティングシステム９２１のプログラムやアプリケーションプログラムの少なくとも一部が一時的に格納される。
また、ＲＡＭ９１４には、ＣＰＵ９１１による処理に必要な各種データが格納される。
【００７２】
また、ＲＯＭ９１３には、ＢＩＯＳ（Ｂａｓｉｃ  Ｉｎｐｕｔ  Ｏｕｔｐｕｔ  Ｓｙｓｔｅｍ）プログラムが格納され、磁気ディスク装置９２０にはブートプログラムが格納されている。
ノード装置４００の起動時には、ＲＯＭ９１３のＢＩＯＳプログラム及び磁気ディスク装置９２０のブートプログラムが実行され、ＢＩＯＳプログラム及びブートプログラムによりオペレーティングシステム９２１が起動される。
【００７３】
上記プログラム群９２３には、実施の形態１及び２の説明において「〜部」（「情報記憶部」以外、以下同様）として説明している機能を実行するプログラムが記憶されている。プログラムは、ＣＰＵ９１１により読み出され実行される。
【００７４】
ファイル群９２４には、実施の形態１及び２の説明において、「〜の判断」、「〜の抽出」、「〜の比較」、「〜の照合」、「〜の更新」、「〜の設定」、「〜の登録」、「〜の選択」等として説明している処理の結果を示す情報やデータや信号値や変数値やパラメータが、「〜ファイル」や「〜データベース」の各項目として記憶されている。
「〜ファイル」や「〜データベース」は、ディスクやメモリなどの記録媒体に記憶される。ディスクやメモリなどの記憶媒体に記憶された情報やデータや信号値や変数値やパラメータは、読み書き回路を介してＣＰＵ９１１によりメインメモリやキャッシュメモリに読み出され、抽出・検索・参照・比較・演算・計算・処理・編集・出力・印刷・表示などのＣＰＵの動作に用いられる。
抽出・検索・参照・比較・演算・計算・処理・編集・出力・印刷・表示のＣＰＵの動作の間、情報やデータや信号値や変数値やパラメータは、メインメモリ、レジスタ、キャッシュメモリ、バッファメモリ等に一時的に記憶される。
また、実施の形態１及び２で説明しているフローチャートの矢印の部分は主としてデータや信号の入出力を示し、データや信号値は、ＲＡＭ９１４のメモリ、ＦＤＤ９０４のフレキシブルディスク、ＣＤＤ９０５のコンパクトディスク、磁気ディスク装置９２０の磁気ディスク、その他光ディスク、ミニディスク、ＤＶＤ等の記録媒体に記録される。また、データや信号は、バス９１２や信号線やケーブルその他の伝送媒体によりオンライン伝送される。
【００７５】
また、実施の形態１及び２の説明において「〜部」として説明しているものは、「〜回路」、「〜装置」、「〜機器」であってもよく、また、「〜ステップ」、「〜手順」、「〜処理」であってもよい。
すなわち、実施の形態１及び２で説明したフローチャートに示すステップ、手順、処理により、本発明に係る「共用情報更新方法」を実現することができる。
また、「〜部」として説明しているものは、ＲＯＭ９１３に記憶されたファームウェアで実現されていても構わない。或いは、ソフトウェアのみ、或いは、素子・デバイス・基板・配線などのハードウェアのみ、或いは、ソフトウェアとハードウェアとの組み合わせ、さらには、ファームウェアとの組み合わせで実施されても構わない。ファームウェアとソフトウェアは、プログラムとして、磁気ディスク、フレキシブルディスク、光ディスク、コンパクトディスク、ミニディスク、ＤＶＤ等の記録媒体に記憶される。プログラムはＣＰＵ９１１により読み出され、ＣＰＵ９１１により実行される。すなわち、プログラムは、実施の形態１及び２の「〜部」としてコンピュータを機能させるものである。あるいは、実施の形態１及び２の「〜部」の手順や方法をコンピュータに実行させるものである。
【００７６】
このように、実施の形態１及び２に示すノード装置４００は、処理装置たるＣＰＵ、記憶装置たるメモリ、磁気ディスク等、入力装置たるキーボード、マウス、通信ボード等、出力装置たる表示装置、通信ボード等を備えるコンピュータであり、上記したように「〜部」として示された機能をこれら処理装置、記憶装置、入力装置、出力装置を用いて実現するものである。
【符号の説明】
【００７７】
４００  ノード装置、４０１  共用情報更新部、４０２  共用情報、４０３  送信データ、４０４  バージョン番号、４０５  通信部、４０６  通信部、４０７  受信データ、４０８  バージョン判別部、４１０  情報記憶部、４２０  更新監視部、４３０  更新相手リスト、４４０  再起動タイミング決定部、４４１  再起動タイミング通知、４５０  再起動実行部。
【図１】
2011221625.tif 000003
【図２】
2011221625.tif 000004
【図３】
2011221625.tif 000005
【図４】
2011221625.tif 000006
【図５】
2011221625.tif 000007
【図６】
2011221625.tif 000008
【図７】
2011221625.tif 000009
【図８】
2011221625.tif 000010
【図９】
2011221625.tif 000011
【図１０】
2011221625.tif 000012
【図１１】
2011221625.tif 000013
【図１２】
2011221625.tif 000014