(57)【特許請求の範囲】
【請求項１】
ルーティングテーブルを用いてピアツーピア方式で通信可能な状態でネットワークを介して互いに接続された複数のノード装置とそれらノード装置に前記ネットワークを介して接続されたサーバとを有するピアツーピア通信システムであって、
各ノード装置は、自ノード装置が前記ネットワーク上に生存するか否かの監視を他ノード装置に依頼する生存確認依頼ノードとしての機能と、他ノード装置が前記ネットワーク上に生存するか否かを監視する監視ノードとしての機能とを有し、
各ノード装置は、
前記生存確認依頼ノードとして機能するとき、自ノード装置のための前記ルーティングテーブルに記憶されている他ノード装置のうちの少なくとも一つを、自ノード装置を監視すべき監視ノードとして選択する監視ノード選択手段を含み、
各ノード装置は、
前記監視ノードとして機能するとき、前記生存確認依頼ノードとしての他ノード装置が前記ネットワーク上に生存するか否かを判定する生存判定手段と、
その生存判定手段により、前記生存確認依頼ノードが前記ネットワーク上に生存しないと判定された場合に、前記生存確認依頼ノードが前記ネットワーク上に生存しないことを前記サーバに通知する通知手段と
を含むピアツーピア通信システム。
【請求項２】
前記サーバは、
前記ネットワークに参加している複数のノード装置の設置位置をノードＩＤに関連付けて予め記憶している記憶手段と、
前記監視ノードとして機能する各ノード装置から、前記生存確認依頼ノードが前記ネットワーク上に生存しないことが通知された場合に、前記記憶手段にアクセスすることにより、前記生存確認依頼ノードの前記ネットワーク上における設置位置を特定する位置特定手段と
を含む請求項１に記載のピアツーピア通信システム。
【請求項３】
ルーティングテーブルを用いてピアツーピア方式で通信可能な状態でネットワークを介して他の複数のノード装置に接続されるとともに前記ネットワークを介してサーバに接続されたノード装置であって、
前記ネットワーク上に生存するか否かの監視を当該ノード装置に依頼した生存確認依頼ノードが前記ネットワーク上に生存するか否かを監視する監視手段と、
その監視手段による監視結果に基づき、前記生存確認依頼ノードが前記ネットワーク上に生存するか否かを判定する生存判定手段と、
その生存判定手段により、前記生存確認依頼ノードが前記ネットワーク上に生存しないと判定された場合に、前記生存確認依頼ノードが前記ネットワーク上に生存しないことを前記サーバに通知する通知手段と
を含むノード装置。
【請求項４】
前記監視手段は、指定時刻が到来すると、前記生存確認依頼ノードを監視する時限的監視手段を含む請求項３に記載のノード装置。
【請求項５】
前記監視手段は、前記生存確認依頼ノードに特定のリクエストを送信する送信手段を含み、
前記生存判定手段は、そのリクエストの送信に応答して前記生存確認依頼ノードがレスポンスを当該ノード装置に返信しない場合に、その生存確認依頼ノードが前記ネットワーク上に生存しないと判定する判定手段を含む請求項３または４に記載のノード装置。
【請求項６】
同じ生存確認依頼ノードを監視する他の監視ノードを記憶する監視ノード記憶手段を含み、
前記通知手段は、前記生存判定手段により、前記生存確認依頼ノードが前記ネットワーク上に生存しないと判定された場合に、前記生存確認依頼ノードが前記ネットワーク上に生存しないことを、前記監視ノード記憶手段に記憶されている他の監視ノードに通知する他監視ノード通知手段を含む請求項３ないし５のいずれかに記載のノード装置。
【請求項７】
前記ネットワークから脱退する際に、脱退することを前記生存確認依頼ノードに通知する脱退通知手段を含む請求項３ないし６のいずれかに記載のノード装置。
【請求項８】
監視対象の前記生存確認依頼ノードを記憶する生存確認依頼ノード記憶手段と、
生存確認の依頼を受信した場合に、前記生存確認依頼ノード記憶手段に記憶されている前記生存確認依頼ノードの数が所定値を超えているか否かを判定するノード数判定手段と、
そのノード数判定手段により、前記生存確認依頼ノードの数が前記所定値以下であると判定された場合には、生存確認の依頼を受諾し、前記所定値を超えていると判定された場合には、生存確認の依頼を拒否する依頼受諾・拒否手段と
を含む請求項３ないし７のいずれかに記載のノード装置。
【請求項９】
同じ生存確認依頼ノードを監視する他の監視ノードを記憶する監視ノード記憶手段を含み、
前記通知手段は、前記サーバへの通信に失敗した場合に、前記監視ノード記憶手段に記憶されている他の監視ノードに、前記生存確認依頼ノードが前記ネットワーク上に生存しないことを前記サーバに通知するように依頼する代行通知手段を含む請求項３ないし８のいずれかに記載のノード装置。
【請求項１０】
ルーティングテーブルを用いてピアツーピア方式で通信可能な状態でネットワークを介して他の複数のノード装置に接続されるとともに前記ネットワークを介してサーバに接続されたノード装置であって、
自ノード装置のための前記ルーティングテーブルに記憶されている他のノード装置のうちの少なくとも一つを、自ノード装置を監視すべき監視ノードとして選択する監視ノード選択手段と、
自ノード装置が前記ネットワーク上に生存するか否かの監視を、前記監視ノード選択手段によって選択された監視ノードに依頼する生存確認依頼手段と
を含むノード装置。
【請求項１１】
前記監視ノードが、自ノード装置の生存を確認したか否かを判定する監視ノード判定手段と、
その監視ノード判定手段により、前記監視ノードが自ノード装置の生存を確認していないと判定された場合に、前記監視ノードとは別のノード装置を新たな監視ノードとして選択する監視ノード変更手段と
を含む請求項１０に記載のノード装置。
【請求項１２】
前記監視ノード判定手段は、指定時刻に、前記監視ノードから特定のリクエストを受信しない場合に、その監視ノードが自ノード装置の生存を確認していないと判定する生存未確認判定手段を含む請求項１１に記載のノード装置。
【請求項１３】
前記監視ノードが前記ネットワークから脱退するメッセージを受信した場合に、前記監視ノードとは別のノード装置を新たな監視ノードとして選択する監視ノード変更手段を含む請求項１１または１２に記載のノード装置。
【請求項１４】
請求項３ないし１３のいずれかに記載のノード装置の各手段としてコンピュータを機能させるために実行されるプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ルーティングテーブルを用いてピアツーピア方式で通信可能な状態でネットワークを介して互いに接続された複数のノード装置とそれらノード装置に前記ネットワークを介して接続されたサーバとを有するピアツーピア通信システムおよび前記ノード装置に関するものである。
【背景技術】
【０００２】
複数のノード装置（例えば、複数のパーソナルコンピュータ）間でコンテンツ（例えば、視聴覚コンテンツ）等の情報を共有するために、複数のノード装置の参加によってオーバレイネットワークを論理的に構築し、そのオーバレイネットワーク上で前記複数のノード装置が相互に通信を行うことを可能にする技術が既に実用化されている。
【０００３】
そのような通信システムの一例が特許文献１にピアツーピア通信システムとして開示されている。この通信システムにおいては、複数のノード装置に、オーバレイネットワーク上における複数の論理的位置がそれぞれ割り当てられる。複数のノード装置にそれぞれ割り当てられる複数の論理的位置を、オーバレイネットワーク上において分散して記憶させるために、例えば、分散ハッシュテーブルＤＨＴ(Distributed Hash Table)が用いられる。
【０００４】
以上説明したピアツーピア通信システムにおいては、各ノード装置がオーバレイネットワーク上に実際に生存しているか否かという情報を他のノード装置が正しく取得することが、ノード装置間での正常な情報交換を維持するために重要である。
【０００５】
一方、各ノード装置がオーバレイネットワークから正常に脱退する場合、すなわち、正規の終了手続を行った後に、ネットワークとの接続を終了する場合には問題はないが、正規の終了手続を経ることなく異常に終了する可能性がある。例えば、そのノード装置内のソフトウエアの不具合や、そのノード装置とネットワークとの物理的な接続を実現するケーブルの切断や離脱があると、ノード装置が、他のノード装置への事前の通知なしで、ネットワークから脱退する可能性がある。
【０００６】
このような可能性があることから、ピアツーピア通信システムにおいては、従来、いずれのノード装置も、それらノード装置を集中的に監視するサーバと接続され、それにより、各ノード装置ごとに、サーバ−クライアント系システムが構築されていた。そのサーバ−クライアント系システムにおいては、いずれのノード装置も、サーバとの間で予め取り決めたKeep Aliveメッセージをサーバへ定期的に通知し、それにより、サーバは、いずれのノード装置についても、各ノード装置がオーバレイネットワーク上に生存するか否かを監視することができるようになっていた。具体的には、サーバは、あるノード装置からのKeep Aliveメッセージの受信が途切れて一定時間経過したら、そのノード装置に異常が発生した旨のアラームを、ピアツーピア通信システムの管理者に対して発する。
【特許文献１】特開２００６−１９７４００号公報
【発明の開示】
【発明が解決しようとする課題】
【０００７】
しかしながら、この従来のノード監視手法では、同じサーバによって監視されるべきノード装置の数が増えると、サーバの負荷が増加する。そのため、ノード監視のためにサーバに課される負担をできる限り軽減することが必要である場合には、その従来のノード監視手法では対応することが困難である。
【０００８】
以上説明した事情を背景として、本発明は、ルーティングテーブルを用いてピアツーピア方式で通信可能な状態でネットワークを介して互いに接続された複数のノード装置とそれらノード装置に前記ネットワークを介して接続されたサーバとを有するピアツーピア通信システムおよび前記ノード装置において、各ノード装置がネットワーク上に生存しているか否かの監視を行うためにサーバに課される負担を完全にまたは部分的に省略することを可能とするためになされたものである。
【課題を解決するための手段】
【０００９】
本発明によって下記の各態様が得られる。各態様は、項に区分し、各項には番号を付し、必要に応じて他の項の番号を引用する形式で記載する。これは、本発明が採用し得る技術的特徴の一部およびそれの組合せの理解を容易にするためであり、本発明が採用し得る技術的特徴およびそれの組合せが以下の態様に限定されると解釈すべきではない。すなわち、下記の態様には記載されていないが本明細書には記載されている技術的特徴を本発明の技術的特徴として適宜抽出して採用することは妨げられないと解釈すべきなのである。
【００１０】
さらに、各項を他の項の番号を引用する形式で記載することが必ずしも、各項に記載の技術的特徴を他の項に記載の技術的特徴から分離させて独立させることを妨げることを意味するわけではなく、各項に記載の技術的特徴をその性質に応じて適宜独立させることが可能であると解釈すべきである。
【００１１】
（１）  ルーティングテーブルを用いてピアツーピア方式で通信可能な状態でネットワークを介して互いに接続された複数のノード装置とそれらノード装置に前記ネットワークを介して接続されたサーバとを有するピアツーピア通信システムであって、
各ノード装置は、自ノード装置が前記ネットワーク上に生存するか否かの監視を他ノード装置に依頼する生存確認依頼ノードとしての機能と、他ノード装置が前記ネットワーク上に生存するか否かを監視する監視ノードとしての機能とを有し、
各ノード装置は、
前記生存確認依頼ノードとして機能するとき、自ノード装置のための前記ルーティングテーブルに記憶されている他ノード装置のうちの少なくとも一つを、自ノード装置を監視すべき監視ノードとして選択する監視ノード選択手段を含み、
各ノード装置は、
前記監視ノードとして機能するとき、前記生存確認依頼ノードとしての他ノード装置が前記ネットワーク上に生存するか否かを判定する生存判定手段と、
その生存判定手段により、前記生存確認依頼ノードが前記ネットワーク上に生存しないと判定された場合に、前記生存確認依頼ノードが前記ネットワーク上に生存しないことを前記サーバに通知する通知手段と
を含むピアツーピア通信システム。
【００１２】
このピアツーピア通信システムにおいては、複数のノード装置が、各ノード装置のためのルーティングテーブルの内容を利用することにより、相互に、各ノード装置がネットワーク上に生存しているか否かを判定する。そして、あるノード装置が、他のノード装置により、ネットワーク上に生存しないと判定された場合にはじめて、サーバに、あるノード装置がネットワーク上に生存しないことが通知される。
【００１３】
したがって、このピアツーピア通信システムによれば、サーバが、すべてのノード装置を、個別に、しかも、定期的に監視することが不可欠ではなくなり、よって、各ノード装置を監視するためにサーバに課される負担が軽減される。すなわち、ネットワーク上に生存するはずであるいずれのノード装置もネットワーク上に実際に生存する正常時に、複数のノード装置とサーバとの間における大量のトラフィックが発生せずに済み、いずれかのノード装置がネットワーク上に実際に生存しない異常時のみ、そのノード装置とサーバとの間におけるトラフィックが発生するのみで済むため、サーバの負荷が軽減されるのである。
【００１４】
（２）  前記サーバは、
前記ネットワークに参加している複数のノード装置の設置位置をノードＩＤに関連付けて予め記憶している記憶手段と、
前記監視ノードとして機能する各ノード装置から、前記生存確認依頼ノードが前記ネットワーク上に生存しないことが通知された場合に、前記記憶手段にアクセスすることにより、前記生存確認依頼ノードの前記ネットワーク上における設置位置を特定する位置特定手段と
を含む（１）項に記載のピアツーピア通信システム。
【００１５】
このピアツーピア通信システムにおいては、あるノード装置がネットワーク上に生存しないと判定された場合に、そのノード装置の、ネットワーク上における設置位置が特定される。
【００１６】
したがって、このピアツーピア通信システムによれば、ネットワークの管理者は、そのネットワーク上に生存しないノード装置に対して、必要な情報の提供やサービスの提供（例えば、復旧作業を含む）を迅速に行うことが可能となる。
【００１７】
（３）  ルーティングテーブルを用いてピアツーピア方式で通信可能な状態でネットワークを介して他の複数のノード装置に接続されるとともに前記ネットワークを介してサーバに接続されたノード装置であって、
前記ネットワーク上に生存するか否かの監視を当該ノード装置に依頼した生存確認依頼ノードが前記ネットワーク上に生存するか否かを監視する監視手段と、
その監視手段による監視結果に基づき、前記生存確認依頼ノードが前記ネットワーク上に生存するか否かを判定する生存判定手段と、
その生存判定手段により、前記生存確認依頼ノードが前記ネットワーク上に生存しないと判定された場合に、前記生存確認依頼ノードが前記ネットワーク上に生存しないことを前記サーバに通知する通知手段と
を含むノード装置。
【００１８】
このノード装置は、同じネットワークに接続されている他のノード装置がネットワーク上に生存するか否かの監視の依頼を受諾すると、他のノード装置を監視することにより、他のノード装置がネットワーク上に生存するか否かを判定する。さらに、このノード装置は、他のノード装置がネットワーク上に生存しないと判定した場合、そのことをサーバに通知する。
【００１９】
したがって、このノード装置によれば、サーバに依存することなく、他のノード装置がネットワーク上に生存するか否かを監視することが可能となり、よって、他のノード装置を監視するためにサーバに課される負担が軽減される。
【００２０】
（４）  前記監視手段は、指定時刻が到来すると、前記生存確認依頼ノードを監視する時限的監視手段を含む（３）項に記載のノード装置。
【００２１】
（５）  前記監視手段は、前記生存確認依頼ノードに特定のリクエストを送信する送信手段を含み、
前記生存判定手段は、そのリクエストの送信に応答して前記生存確認依頼ノードがレスポンスを当該ノード装置に返信しない場合に、その生存確認依頼ノードが前記ネットワーク上に生存しないと判定する判定手段を含む（３）または（４）項に記載のノード装置。
【００２２】
（６）  同じ生存確認依頼ノードを監視する他の監視ノードを記憶する監視ノード記憶手段を含み、
前記通知手段は、前記生存判定手段により、前記生存確認依頼ノードが前記ネットワーク上に生存しないと判定された場合に、前記生存確認依頼ノードが前記ネットワーク上に生存しないことを、前記監視ノード記憶手段に記憶されている他の監視ノードに通知する他監視ノード通知手段を含む（３）ないし（５）項のいずれかに記載のノード装置。
【００２３】
このノード装置によれば、同じ生存確認依頼ノードが複数の監視ノードによって監視される場合に、自ノード装置が、その生存確認依頼ノードがネットワーク上に生存しないと判定すると、そのことが複数の監視ノードによって共有される。
【００２４】
したがって、同じ生存確認依頼ノードが、複数の監視ノードによって予定外に冗長的に監視される可能性を軽減することが可能となり、その結果、各監視ノードに課される監視負担を軽減することが可能となる。
【００２５】
（７）  前記ネットワークから脱退する際に、脱退することを前記生存確認依頼ノードに通知する脱退通知手段を含む（３）ないし（６）項のいずれかに記載のノード装置。
【００２６】
このノード装置によれば、生存確認依頼ノードを監視すべき監視ノードがネットワークから脱退した場合に、そのことが生存確認依頼ノードに通知されるため、ある監視ノードがネットワークから脱退することが原因で、生存確認依頼ノードが監視されなくなってしまう事態の発生を回避することが可能となる。
【００２７】
（８）  監視対象の前記生存確認依頼ノードを記憶する生存確認依頼ノード記憶手段と、
生存確認の依頼を受信した場合に、前記生存確認依頼ノード記憶手段に記憶されている前記生存確認依頼ノードの数が所定値を超えているか否かを判定するノード数判定手段と、
そのノード数判定手段により、前記生存確認依頼ノードの数が前記所定値以下であると判定された場合には、生存確認の依頼を受諾し、前記所定値を超えていると判定された場合には、生存確認の依頼を拒否する依頼受諾・拒否手段と
を含む（３）ないし（７）項のいずれかに記載のノード装置。
【００２８】
このノード装置によれば、同じ監視ノードが複数の生存確認依頼ノードを監視することが許容される態様で実施される場合に、同じ監視ノードによって監視されるべき生存確認依頼ノードの数が過大であるために、その監視ノードの監視負担が過大化することを防止することが可能となる。
【００２９】
（９）  同じ生存確認依頼ノードを監視する他の監視ノードを記憶する監視ノード記憶手段を含み、
前記通知手段は、前記サーバへの通信に失敗した場合に、前記監視ノード記憶手段に記憶されている他の監視ノードに、前記生存確認依頼ノードが前記ネットワーク上に生存しないことを前記サーバに通知するように依頼する代行通知手段を含む（３）ないし（８）項のいずれかに記載のノード装置。
【００３０】
このノード装置によれば、ある監視ノードが、ある生存確認依頼ノードがネットワーク上に生存しないと判定したために、そのことをサーバに通知しようとしたが、それに失敗した場合であっても、他の監視ノードを利用することにより、そのサーバへの通知が試行される。したがって、このノード装置によれば、ある生存確認依頼ノードがネットワーク上に生存しないという情報がもれなくサーバに通知され、それにより、もれなくネットワーク管理者にも通知される。
【００３１】
（１０）  ルーティングテーブルを用いてピアツーピア方式で通信可能な状態でネットワークを介して他の複数のノード装置に接続されるとともに前記ネットワークを介してサーバに接続されたノード装置であって、
自ノード装置のための前記ルーティングテーブルに記憶されている他のノード装置のうちの少なくとも一つを、自ノード装置を監視すべき監視ノードとして選択する監視ノード選択手段と、
自ノード装置が前記ネットワーク上に生存するか否かの監視を、前記監視ノード選択手段によって選択された監視ノードに依頼する生存確認依頼手段と
を含むノード装置。
【００３２】
このノード装置によれば、自ノード装置を監視可能な他のノード装置が複数存在する場合に、自ノード装置のためのルーティングテーブルを参照することにより、それらノード装置のうちの少なくとも１つが監視ノードとして自動的に選択される。さらに、その選択された監視ノードにより、自ノード装置がネットワーク上に生存するか否かが判定される。
【００３３】
（１１）  前記監視ノードが、自ノード装置の生存を確認したか否かを判定する監視ノード判定手段と、
その監視ノード判定手段により、前記監視ノードが自ノード装置の生存を確認していないと判定された場合に、前記監視ノードとは別のノード装置を新たな監視ノードとして選択する監視ノード変更手段と
を含む（１０）項に記載のノード装置。
【００３４】
このノード装置によれば、自ノード装置を監視すべき監視ノードが、何らかの理由により、自ノード装置を監視しないことが判明した場合に、別のノード装置が新たな監視ノードとして自動的に選択される。よって、このノード装置によれば、最初に選択された監視ノードが異常であっても、自ノード装置がネットワーク上に生存するか否かを監視することが可能となる。
【００３５】
（１２）  前記監視ノード判定手段は、指定時刻に、前記監視ノードから特定のリクエストを受信しない場合に、その監視ノードが自ノード装置の生存を確認していないと判定する生存未確認判定手段を含む（１１）項に記載のノード装置。
【００３６】
（１３）  前記監視ノードが前記ネットワークから脱退するメッセージを受信した場合に、前記監視ノードとは別のノード装置を新たな監視ノードとして選択する監視ノード変更手段を含む（１１）または（１２）項に記載のノード装置。
【００３７】
このノード装置によれば、自ノード装置を監視すべき監視ノードがネットワークから脱退すると、自ノード装置が別の監視ノードによって監視されるため、監視ノードがネットワークから脱退することが原因で、自ノード装置が監視されなくなるという事態の発生が回避される。
【００３８】
（１４）  （３）ないし（１３）項のいずれかに記載のノード装置の各手段としてコンピュータを機能させるために実行されるプログラム。
【００３９】
このプログラムがコンピュータにより実行されれば、前記（３）ないし（１３）項のいずれかに係る装置と基本的に同じ原理に従い、同様な作用効果が実現され得る。
【００４０】
本項に係るプログラムは、それの機能を果たすためにコンピュータにより実行される指令の組合せのみならず、各指令に従って処理されるファイルやデータをも含むように解釈することが可能である。
【００４１】
また、このプログラムは、それ単独でコンピュータにより実行されることにより、所期の目的を達するものとしたり、他のプログラムと共にコンピュータにより実行されることにより、所期の目的を達するものとすることができる。後者の場合、本項に係るプログラムは、データを主体とするものとすることができる。
【００４２】
（１５）  （１４）項に記載のプログラムをコンピュータ読取り可能に記録した記録媒体。
【００４３】
この記録媒体に記録されているプログラムがコンピュータにより実行されれば、前記（３）ないし（１３）項のいずれかに係る方法と同じ作用効果が実現され得る。
【００４４】
この記録媒体は種々な形式を採用可能であり、例えば、フレキシブル・ディスク等の磁気記録媒体、ＣＤ、ＣＤ−ＲＯＭ等の光記録媒体、ＭＯ等の光磁気記録媒体、ＲＯＭ等のアンリムーバブル・ストレージ等のいずれかを採用し得る。
【発明を実施するための最良の形態】
【００４５】
以下、本発明のさらに具体的な実施の形態のうちの一つを図面に基づいて詳細に説明する。本実施形態は、ＤＨＴを用いてオーバレイネットワークを構成して複数のノード装置間においてコンテンツ等の情報を共有しつつピアツーピア通信を行うことを可能にする情報通信システムＳに本発明を適用する場合の一例である。
【００４６】
図１には、この情報通信システムＳの接続構成が系統的に示されている。この情報通信システムＳにおいては、各ノード装置が、時間的に変化する役割の種類に応じて種々の処理を選択的に行う。
【００４７】
概略的には、各ノード装置（図１においては、白丸で表す。）は、よく知られているように、ノードＩＤの計算、ルーティングテーブルの作成、他のノード装置から受信したメッセージの、次のノード装置への転送、他のノード装置から受信したメッセージに応じた処理等を行う。この情報通信システムＳの基本的な動作が特開２００６−１９７４００号公報に開示されており、その開示内容はそれ全体として、その公報が引用されることによって本明細書に合体させられる。
【００４８】
次に、図１を参照することにより、この情報通信システムＳの物理的構成および論理的構成を説明する。図１において符号１００が付された上枠内には、論理的存在としてのオーバレイネットワーク９が系統的に示され、一方、同図において符号１０１が付された下枠内には、物理的存在としてのネットワーク（例えば、インターネット，ＬＡＮ，ＷＡＮ）８が系統的に示されている。
【００４９】
下枠１０１内に示すように、物理的なネットワーク（現実世界のネットワーク）８を構築するために、ＩＸ（Internet eXchange）３、ＩＳＰ（Internet Service Provider）４、ＤＳＬ（Digital Subscriber Line）回線事業者用の装置５、ＦＴＴＨ（Fiber To The Home）回線事業者用の装置６、通信回線（例えば、電話回線や光ケーブル等）７等が用いられる。
【００５０】
情報通信システムＳは、このようなネットワーク８を介して相互に接続された複数のノード装置１ａ，１ｂ，１ｃ，・・・，１ｘ，１ｙ，１ｚ，・・・を含むように構成され、それにより、ピアツーピア方式のネットワークシステムが実現される。
【００５１】
各ノード装置１ａ，１ｂ，１ｃ，・・・，１ｘ，１ｙ，１ｚ，・・・には、各ノード装置１の同一性を表す情報（デバイスＩＤ）として、各ノード装置１に固有の製造番号およびＩＰ（Internet Protocol）アドレスが割り当てられている。各ノード装置１の製造番号およびＩＰアドレスは、複数のノード装置１間で重複しないように設定される。
【００５２】
以下、説明の便宜上、ノード装置１ａ，１ｂ，１ｃ，・・・，１ｘ，１ｙ，１ｚ，・・・のうちいずれかに言及するために、単に、ノード装置１ということがある。
【００５３】
情報通信システムＳは、分散ハッシュテーブルＤＨＴ(Distributed Hash Table）を利用してノードＩＤを計算する。具体的には、この情報通信システムＳは、ＤＨＴを利用したアルゴリズムにより、図１の上部枠１００内に示すようにオーバレイネットワーク９を構築する。このオーバレイネットワーク９は、既存のネットワーク８を用いて形成された、仮想リンクより成るネットワークを意味する。
【００５４】
次に、図２を参照することにより、各ノード装置１の構成および機能を説明する。複数の各ノード装置１の構成は互いに共通するため、１つのノード装置１のみを代表的に説明する。図２は、その代表的なノード装置１の構成の一例を概略的に示している。
【００５５】
図２に示すように、ノード装置１は、制御部１１と記憶部１２とを備えている。制御部１は、演算機能を有するＣＰＵ，作業用ＲＡＭ，各種データおよびプログラムを記憶するＲＯＭ等から構成されたコンピュータを備えている。記憶部１２は、コンテンツデータ、インデックス情報、上記ＤＨＴ，プログラム等を記憶保存（格納）するためのＨＤ等から構成されている。ただし、複数のノード装置１の中には、コンテンツデータを保存していないノード装置１もある。
【００５６】
ノード装置１は、さらに、受信されたコンテンツデータ等を一時蓄積するバッファメモリ１３と、コンテンツデータに含まれるエンコードされたビデオデータ（映像情報）、オーディオデータ（音声情報）等をデコード（データ伸張や復号化等）するデコーダ部１４とを備えている。ノード装置１は、さらに、デコードされたビデオデータ等に対して所定の描画処理を施しビデオ信号として出力する映像処理部１５と、その映像処理部１５から出力されたビデオ信号に基づき映像表示するＣＲＴ，液晶ディスプレイ等の表示部１６とを備えている。
【００５７】
ノード装置１は、さらに、デコードされたオーディオデータをアナログオーディオ信号にＤ（Digital）／Ａ（Analog）変換した後、その信号をアンプにより増幅して出力する音声処理部１７と、その音声処理部１７から出力されたオーディオ信号を音波として出力するスピーカ１８とを備えている。
【００５８】
ノード装置１は、さらに、ネットワーク８を通じて他のノード装置１との間の情報の通信制御を行うための通信部２０と、ユーザからの指示を受け付けるとともにその指示に応じた指示信号を制御部１１に対して与える入力部（例えば、キーボード、マウス、操作パネル等）２１とを備えている。
【００５９】
図２に示すように、制御部１１、記憶部１２、バッファメモリ１３、デコーダ部１４および通信部２０はバス２２を介して相互に接続されている。
【００６０】
ノード装置１においては、制御部１１におけるＣＰＵが記憶部１２等に記憶された各種プログラムを実行し、それにより、ノード装置１全体が統括制御される。また、入力部２１からの指示信号に応じて、コンテンツデータの登録処理等が行われる。
【００６１】
各ノード装置１は、よく知られているように、上記オーバレイネットワークに参加するために、図３に表で表す如きルーティングテーブルを作成する。さらに、各ノード装置１は、実行されるプログラムの種類に応じて、果たす役割が変化し、具体的には、情報を送信（転送）するノード装置として機能したり、情報を受信するノード装置として機能する。
【００６２】
この情報通信システムＳにおいては、各ノード装置１が正規の終了手続を経ずに停止したか否か、すなわち、異常であるか否かが、上述のルーティングテーブルを利用してノード装置１相互の通信を行うことによって判定される。
【００６３】
この異常検出技術を、図４（ａ）および（ｂ）を参照してさらに具体的に説明する。まず、自ノードＸは、それのルーティングテーブルに記憶されているＩＰアドレスのノード群｛Ａ（１），Ａ（２），．．．，Ａ（Ｎ）｝から、一部のノード群｛Ａ（１），Ａ（２），．．．，Ａ（ｋ）｝に、自ノードＸがネットワーク８上に生存していることを確認することを依頼する（以下、「生存確認を依頼する」という。）。生存確認を依頼された他のノード装置１は、自ノードＸを監視する役目を有することから、以下、監視ノードという。
【００６４】
この依頼に際し、各監視ノードが自ノードＸにアクセスすべき時刻（すなわち、監視時刻）が自ノードＸによって指定されるが、その指定方法はこれに限定されず、例えば、各監視ノードが自ら指定してもよい。それにより、自ノードＸは、それぞれ監視ノードである複数のノードＡ（１）〜Ａ（ｋ）（図４に示す例においては、ｋ＝３）に、１ノードずつ順に自ノードＸの生存を確認することを依頼する（図４（ａ）においては、「確認依頼」で示す。）。
【００６５】
自ノードＸは、それが正常にネットワーク８上に生存する場合には、図４（ａ）に示すように、各監視ノードからのアクセスに応答して、生存する旨のレスポンス（図４（ａ）においては、「ＯＫ」で示す。）を各監視ノードに返信する。
【００６６】
これに対し、自ノードＸは、正規の終了手続きを経て停止しようとする際には、図４（ａ）に示すように、ネットワーク８から脱退する前に、監視ノード群｛Ａ（１），Ａ（２），．．．，Ａ（ｋ）｝にそれぞれ脱退メッセージ（図４（ａ）においては、「ＮＧ」で示す。）を送信する。脱退メッセージを受信したノード群｛Ａ（１），Ａ（２），．．．，Ａ（ｋ）｝は、以後、自ノードＸについての生存確認を行わない。
【００６７】
自ノードＸから脱退メッセージを受信しておらず、しかも、ネットワーク８に生存すらしていないためにいずれかの監視ノードが自ノードＸに対してその生存を確認するためのメッセージを送信してもそれに対して自ノードＸが何ら応答しない場合には（図４（ｂ）においては、「応答なし」で示す。）、その監視ノードは、自ノードＸの異常をサーバ２００に通知し、さらに、他の監視ノードにも通知する。
【００６８】
図５には、サーバ２００の構成が概念的にブロック図で表されている。このサーバ２００は、図２に示すノード装置１と基本的に共通する構成を有している。具体的には、このサーバ２００においては、プロセッサ２０２と記憶部２０４とがバス２０５によって互いに接続され、それにより、コンピュータが構成されている。
【００６９】
バス２０５には、さらに、入出力コントローラ２０６が接続され、その入出力コントローラ２０６には、マウス等、入力装置２１０と、液晶ディスプレイ、プリンタ等、出力装置２１２とが接続されている。バス２０５には、さらに、通信部２２０が接続され、サーバ２００は、その通信部２２０を介して、ネットワーク８上の任意の端末（複数のノード装置１およびサーバ２００に関連付けられたクライアントを含む）と通信可能となっている。
【００７０】
概略的に説明するに、サーバ２００は、情報通信システムＳを構成する複数のノード装置１を集中的に保守管理する管理者によって使用される。さらに、このサーバ２００には、ネットワーク８に参加しているノードの設置場所が予め登録されている。
【００７１】
このサーバ２００は、いずれかの監視ノードから、自ノードＸが生存していないこと、すなわち、異常であることの通知を受けると、異常が発生した自ノードＸの場所をサーバ２００の画面上に表示すること、および／または、そのサーバ２００に接続されたクライアント（図示しない）に送信してそのクライアントの画面上に表示する。したがって、自ノードＸに異常が発生した場合には、サーバ２００は、そのことを情報通信システムＳの管理者にいち早く通知することが可能であり、よって、その管理者は、自ノードＸの障害にいち早く対応するなど、必要な対策を講ずることが可能となる。
【００７２】
次に、フローチャートを参照することにより、各ノード装置１において実行される処理を具体的に説明する。図６には、制御部１１によって実行されるメインプログラムがフローチャートで概念的に表されている。このメインプログラムは、各ノード装置１の電源ＯＮに応答して起動し、まず、ステップＳ１において、ピアツーピア型のネットワーク８に参加するために、ルーティングテーブルが作成される。
【００７３】
次に、ステップＳ２において、生存確認依頼ノードとしての機能が開始され、また、ステップＳ３において、監視ノードとしての機能が開始される。ステップＳ２およびＳ３は、いずれもスレッドとして、事実上、互いに並行的に実行される。
【００７４】
具体的には、ステップＳ２においては、自ノード装置１が、監視ノードに対して自ノード装置の生存の確認を依頼する生存確認依頼ノードとして機能する場合に、監視を依頼すべき他のノード装置を特定する生存確認依頼リスト（図３に示す例については、図７（ａ）参照）に対するノード装置の追加・削除が行われる。このステップＳ２の詳細は、生存確認依頼ルーチンとして、後に、それをフローチャートで概念的に表す図８を参照して説明する。
【００７５】
これに対し、ステップＳ３においては、自ノード装置１が、他のノード装置にとっての監視ノードとして機能する場合に、監視されるべき他のノード装置を特定する監視リスト（図３に示す例については、図７（ｂ）参照）に対するノード装置の追加・削除が行われる。このステップＳ３の詳細は、後に、監視ルーチンとして、それをフローチャートで概念的に表す図９を参照して説明する。
【００７６】
図６に戻ると、ステップＳ４において、自ノード装置１が他のノード装置１からメッセージを受信するのが待たれる。受信したなら、ステップＳ５において、その受信したメッセージが、それに適合する手法で処理される。続いて、ステップＳ６において、自ノード装置１に対し、ユーザからのシャットダウン要求があったか否かが判定される。シャットダウン要求がなければ、ステップＳ４に戻るが、シャットダウン要求があれば、ステップＳ７において、生存確認依頼ノードとしての機能と、監視ノードとしての機能とがいずれも終了することが待たれる。終了したならば、このメインプログラムの実行が終了する。
【００７７】
ここで、図６に示すステップＳ２の詳細を、図８のフローチャートを参照して説明する。まず、ステップＳ１０１において、生存確認依頼リストを作成するために、図１０にフローチャートで概念的に表されている生存確認依頼リスト作成ルーチンが実行される。
【００７８】
この生存確認依頼リスト作成ルーチンの実行により、自ノード装置１を監視すべき他のノード装置１すなわち監視ノードが決定される。その監視ノード決定技術の概略を説明する。
【００７９】
前述のように、自ノード装置１は、ネットワーク８への参加時にルーティングテーブルを作成する。ノードＩＤが１２８ｂｉｔである場合には、最大で２５６（＝１６ｘ１６）台のノード装置１がルーティングテーブルに存在することになる。
【００８０】
自ノード装置１が生存確認依頼ノードとして機能する場合には、自ノード装置１のルーティングテーブルに記憶されている他のノード装置１に生存確認を依頼するが、２５６台のノード装置１のすべてに生存確認を依頼する場合には、自ノード装置１に異常が発生すると、２５６台のノード装置１が自ノード装置１の異常を検知する必要があるため、効率的ではない。したがって、ルーティングテーブルに記憶されているノード装置１の中から、自ノード装置１の生存を確認すべきノード群｛Ａ（１），Ａ（２），…，Ａ（ｋ）｝を適当な方法で選択して監視ノードとして決定することが望ましい。
【００８１】
具体的には、本実施形態においては、例えば、図３に示すルーティングテーブルが、レベル１の行を左端から右端へ移動し、右端に到達したら次のレベルの行の左端へ戻るという順序でスキャンされ、それにより、それぞれのノード装置１が順次、監視ノードとして決定される。
【００８２】
例えば、自ノード装置１の生存を１５分間隔で確認することが必要である場合は、４台（＝６０（分）／１５（分））のノード装置１がそれぞれ監視ノードとして決定され、この場合、各監視ノードの監視回数は、１回／時間となる。例えば、図３に示すルーティングテーブルを用いる場合には、まず、最初の４回のノード装置Ａ〜Ｄがそれぞれ監視ノードとして決定され、ノード装置Ｅが、次の監視ノード候補となる。
【００８３】
さらに、この生存確認依頼リスト作成ルーチンの実行により、自ノード装置１から監視ノードに対して、生存確認の依頼が行われる。その生存確認依頼技術の概略を説明する。
【００８４】
自ノード装置１は、監視ノードが自ノード装置２の生存を確認すべき時刻（以下、「生存確認時刻」という。）を指定する。図３に示す例においては、例えば、生存確認の開始時刻を１４：００とすると、ノードＡには１４：００、ノードＢには１４：１５、ノードＣには１４：３０、ノードＤには１４：４５がそれぞれ、生存確認時刻として指示される。
【００８５】
自ノード装置１は、監視ノードのノードＩＤおよびＩＰアドレスと、前述の生存確認依頼リスト（図７（ａ）に示すように、監視ノードと生存確認時刻とが互いに関連付けられて記憶される）を記憶する。各監視ノードは、自ノード装置１のノードＩＤ、ＩＰアドレス、生存確認時刻および自ノード装置１の生存確認依頼リストを、自ノード装置１から受信して記憶する。
【００８６】
また、例えば、図３に示す例においては、自ノード装置１は、１４：００にノードＡによって生存確認されるメッセージを受信すると、自ノード装置１は、それに対する応答に、次回の生存確認時刻が１５：００である情報を含める。なぜなら、１５分間隔で自ノード装置１の生存を確認する場合には、最後のノードＤの生存確認時刻が１４：４５であるため、その時刻から１５分経過した時刻が次回の生存確認時刻となるからである。自ノード装置１がこのようにして生存確認時刻を更新すると、それに合わせて監視ノードも生存確認時刻を更新する。
【００８７】
なお、同じ監視ノードは、既に他のノード装置を監視している可能性がある。同じ監視ノードについての監視数が多くなってしまう場合には、新たな生存確認の依頼を拒否することができる。
【００８８】
以上、図１０に示す生存確認依頼リスト作成ルーチンの概略を説明したが、以下、図１０を参照することにより、詳細に説明する。
【００８９】
まず、ステップＳ３０１において、初期設定が行われる。具体的には、自ノード装置１（＝ノードＸ）を監視すべき監視ノードの数（生存確認依頼リストに登録されている監視ノードの数）がＮに設定され、他のノード装置１が監視ノードとして決定されるごとに１ずつインクリメントされる整数としての監視ノード決定数ｋの値が０に設定され、生存確認を順次行う際の時間間隔がΔｔ（指定値）に設定され、生存確認開始時刻（自ノード装置１を監視すべき最初の時刻）がＴ（指定値）に設定される。さらに、ルーティングテーブル上における監視ノード候補の位置（ｉ，ｊ）（ｉ：行の番号、ｊ：列の番号）が（０，０）に設定される。
【００９０】
次に、ステップＳ３０２において、生存確認依頼リストがクリアされる。続いて、ステップＳ３０３において、ルーティングテーブル上における位置（ｉ，ｊ）に何らかのノード装置１が登録されているか否かが判定される。いずれのノ−ド装置１も登録されていない場合には、ステップＳ３０４において、列番号ｊが１だけインクリメントされ、その後、ステップＳ３０５において、列番号ｊの現在値がルーティングテーブルの列数に一致するか否かが判定される。一致しない場合には、ステップＳ３０３に戻るが、一致する場合には、ステップＳ３０６において、行番号ｉが１だけインクリメントされるとともに、列番号ｊが「０」に戻される。
【００９１】
続いて、ステップＳ３０７において、行番号ｉの現在値がルーティングテーブルのレベル数（図３に示す例においては、「４」）に一致するか否かが判定される。一致しない場合には、ステップＳ３０３に戻るが、一致する場合には、ステップＳ３０８において、行番号ｉが「０」に戻された後にステップＳ３０３に戻る。
【００９２】
これに対し、ルーティングテーブル上における位置（ｉ，ｊ）に何らかのノード装置１が登録されている場合には、ステップＳ３０３の判定がＹＥＳとなり、ステップＳ３０９において、ルーティングテーブル上における位置（ｉ，ｊ）に登録されているノード装置１が自ノード装置１であるか否かが判定される。そうであれば、ステップＳ３０４に移行するが、そうでなければ、ステップＳ３１０において、いずれのノ−ド装置１も登録されていない場合には、ステップＳ３０４において、列番号ｊが１だけインクリメントされ、その後、ステップＳ３１０に移行する。
【００９３】
このステップＳ３１０においては、ルーティングテーブル上における位置（ｉ，ｊ）に登録されているノード装置１が監視ノードとして決定されるとともに、その監視ノードに対し、生存確認開始時刻Ｔが到来したときに自ノード装置１の生存を確認することが依頼される。続いて、ステップＳ３１１において、ルーティングテーブル上における位置（ｉ，ｊ）に登録されているノード装置１（監視ノード）から、生存確認依頼を肯定する応答があったか否かが判定される。肯定応答がなかった場合には、ステップＳ３０４に移行するが、あった場合には、ステップＳ３１２に移行する。
【００９４】
このステップＳ３１２においては、自ノード装置１の生存確認依頼リストに、ルーティングテーブル上における位置（ｉ，ｊ）に登録されているノード装置１（監視ノード）のノードＩＤ、ＩＰアドレスおよび生存確認時刻ｔ（今回は、生存確認開始時刻Ｔに一致する）が記憶される。
【００９５】
その後、ステップＳ３１３において、監視ノード決定数ｋが１だけインクリメントされる。続いて、ステップＳ３１４において、監視ノード決定数ｋの現在値が監視ノード数Ｎに一致するか否かが判定される。一致しない場合には、ステップＳ３１５において、次の生存確認時刻ｔが、今回の生存開始時刻ｔ（今回は、生存確認開始時刻Ｔに一致する）に時間間隔Δｔを加算されたものとして求められる。続いて、ステップＳ３０４に移行する。
【００９６】
これに対して、監視ノード決定数ｋの現在値が監視ノード数Ｎに一致する場合には、ステップＳ３１６において、必要な監視ノードのすべてが決定された後、それら監視ノードのすべてに対して、自ノード装置１のノードＩＤ、ＩＰアドレス、生存確認時刻ｔおよび生存確認依頼リストが送信される。以上で、この生存確認依頼リスト作成ルーチンの実行が終了し、その後、図８に示すステップＳ１０２に移行する。
【００９７】
図１１には、図４に示される例についてこの生存確認依頼リスト作成ルーチンが実行された場合に行われる手続がシーケンス図で表されている。
【００９８】
図８に示すステップＳ１０２においては、自ノード装置１が監視ノードの異常を検知するために、図１２にフローチャートで概念的に表されている監視ノード異常検知ルーチンが実行される。この監視ノード異常検知ルーチンは、スレッドとして実行され、その結果、他のステップと事実上、並行して実行される。
【００９９】
概略的に説明するに、この監視ノード異常検知ルーチンが実行されると、注目する監視ノードが、それに関連付けられた生存確認時刻ｔが経過しても、自ノード装置１の生存の確認を行わないために、生存確認依頼リストから削除されずに残存している場合に、自ノード装置１は、その監視ノードが異常停止したものと判定する。この場合、自ノード装置１は、前述の監視ノード選択手順に従って、その異常の監視ノードが行うはずであった生存確認を、次の監視ノード候補に依頼する。
【０１００】
具体的に説明するに、この監視ノード異常検知ルーチンが起動すると、まず、ステップＳ４０１において、監視ノード数、すなわち、自ノード装置１の生存確認依頼リストに登録されている監視ノードの数がＮに設定され、さらに、注目すべき監視ノードを特定するための番号ｉが「１」に設定される。
【０１０１】
次に、ステップＳ４０２において、複数の監視ノードのうち今回注目されるもの（番号ｉの現在値を有する監視ノードであって、以下、「今回の監視ノードＡ（ｉ）」という。）に関連付けられた生存確認時刻ｔが経過したか否かが判定される。
【０１０２】
本実施形態においては、今回の監視ノードＡ（ｉ）は、本来であれば、生存確認時刻ｔが到来したときに、生存確認依頼ノードを監視し、その結果、生存確認依頼ノードの監視リストから削除されるはずである。一方、生存確認依頼ノードは、生存確認時刻ｔが経過したにもかかわらず、該当する各監視ノードＡから何ら特定のリクエストを受信しない場合に、各監視ノードＡは、生存確認依頼ノードの生存を正常に確認しなかったと判定するように設計されている。
【０１０３】
したがって、生存確認時刻ｔが経過した後にも、今回の監視ノードＡ（ｉ）が監視リストに存在するということは、今回の監視ノードＡ（ｉ）が生存確認時刻ｔに生存確認を行わなかったことを意味する。よって、このステップＳ４０２においては、結局、今回の監視ノードＡ（ｉ）が生存確認時刻ｔに生存確認を行わなかったか否かが判定されることになる。
【０１０４】
今回の監視ノードＡ（ｉ）に関連付けられた生存確認時刻ｔが経過していない場合には、ステップＳ４０３において、番号ｉが１だけインクリメントされ、その後、ステップＳ４０４において、番号ｉの現在値が監視ノード数Ｎより大きいか否かが判定される。番号ｉの現在値が監視ノード数Ｎより大きくはない場合には、直ちにステップＳ４０２に戻るが、大きい場合は、ステップＳ４０５において番号ｉの現在値が「１」に戻された後、ステップＳ４０２に戻る。
【０１０５】
これに対して、今回の監視ノードＡ（ｉ）に関連付けられた生存確認時刻ｔが経過した場合（すなわち、今回の監視ノードＡ（ｉ）が生存確認時刻ｔに生存確認を行わなかった場合）には、ステップＳ４０２の判定がＹＥＳとなり、ステップＳ４０６において、次の監視ノード候補（例えば、図３に示す例においては、ノードＢ）に、今回の監視ノードＡ（ｉ）に関連付けられた生存確認時刻ｔから時間間隔Ｐが経過した次回の生存確認時刻ｔに自ノード装置１の生存を確認することが依頼される。
【０１０６】
続いて、ステップＳ４０７において、その依頼を受けたノード装置が、新たな監視ノードＡ（ｉ）とされ、自ノード装置１の生存確認依頼リストに、その新たな監視ノードＡ（ｉ）のノードＩＤ、ＩＰアドレスおよび生存確認時刻ｔが記憶される。これにより、自ノード装置１の生存確認依頼リストが更新される。
【０１０７】
続いて、ステップＳ４０８において、番号ｉが「１」に戻される。その後、ステップＳ４０９において、今回の監視ノードＡ（ｉ）に対し、更新された生存確認依頼リストが通知される。続いて、ステップＳ４１０において、番号ｉが１だけインクリメントされ、その後、ステップＳ４１１において、番号ｉの現在値が監視ノード数Ｎより大きいか否かが判定される。番号ｉの現在値が監視ノード数Ｎより大きくはない場合には、ステップＳ４０９に戻るが、大きい場合には、ステップＳ４０１に戻る。
【０１０８】
図８に戻ると、ステップＳ１０３において、自ノード装置１が監視ノードから脱退メッセージを受信したか否かが判定される。受信した場合には、ステップＳ１０４において、自ノード装置１の生存確認依頼リストから、その脱退した監視ノードを削除するために、図１３にフローチャートで概念的に表されている監視ノード削除ルーチンが実行される。
【０１０９】
この監視ノード削除ルーチンにおいては、まず、ステップＳ４５１において、監視ノード数、すなわち、自ノード装置１の生存確認依頼リストに登録されている監視ノードの数がＮに設定され、さらに、注目すべき監視ノードを特定するための番号ｉが「１」に設定される。
【０１１０】
次に、ステップＳ４５２において、脱退メッセージを送信した監視ノード（図３に示す例においては、例えば、ノードＡが該当する可能性があるため、以下、説明の便宜上、「脱退メッセージを送信したノードＡ」という。）のノードＩＤと、今回の監視ノードＡ（ｉ）のノードＩＤとが互いに一致するか否かが判定される。一致しない場合には、ステップＳ４５３において、番号ｉが１だけインクリメントされる。
【０１１１】
その後、ステップＳ４５４において、番号ｉの現在値が監視ノード数Ｎより大きいか否かが判定される。大きくはない場合には、ステップＳ４５２に戻るが、大きい場合には、ステップＳ４５６に移行する。脱退メッセージを送信したノードＡのノードＩＤと、今回の監視ノードＡ（ｉ）のノードＩＤとが互いに一致する場合には、ステップＳ４５５において、生存確認依頼リストから今回の監視ノードＡ（ｉ）が削除された後、ステップＳ４５６に移行する。
【０１１２】
いずれにしても、ステップＳ４５６においては、脱退メッセージを送信したノードＡに対して、脱退メッセージを受信した旨の応答が行われる。続いて、ステップＳ４５７において、次の監視ノード候補（例えば、図３に示す例においては、ノードＢ）に、今回の監視ノードＡ（ｉ）に関連付けられた生存確認時刻ｔから時間間隔Ｐが経過した次回の生存確認時刻ｔに自ノード装置１の生存を確認することが依頼される。
【０１１３】
続いて、ステップＳ４５８において、その依頼を受けたノード装置が、新たな監視ノードＡ（ｉ）とされ、自ノード装置１の生存確認依頼リストに、その新たな監視ノードＡ（ｉ）のノードＩＤ、ＩＰアドレスおよび生存確認時刻ｔが記憶される。これにより、自ノード装置１の生存確認依頼リストが更新される。
【０１１４】
続いて、ステップＳ４５９において、番号ｉが１に戻される。その後、ステップＳ４６０において、今回の監視ノードＡ（ｉ）に対し、更新された生存確認依頼リストが通知される。続いて、ステップＳ４６１において、番号ｉが１だけインクリメントされ、その後、ステップＳ４６２において、番号ｉの現在値が監視ノード数Ｎより大きいか否かが判定される。番号ｉの現在値が監視ノード数Ｎより大きくはない場合には、ステップＳ４６０に戻るが、大きい場合には、この監視ノード削除ルーチンの実行が終了する。
【０１１５】
その後、図８に示すステップＳ１０５において、自ノード装置１に対してユーザがシャットダウン要求を出したか否かが判定される。シャットダウン要求が出されていない場合には、ステップＳ１０３に戻るが、出された場合には、ステップＳ１０６において、自ノード装置１がネットワーク８から脱退するために、図１４にフローチャートで概念的に表されているノード脱退通知ルーチンが実行される。
【０１１６】
概略的に説明するに、このノード脱退通知ルーチンが実行されると、自ノード装置１は、ネットワーク８から脱退しようとする際に、すべての監視ノードに対して脱退メッセージを送信する。その脱退メッセージを受信した各監視ノードは、以後、自ノード装置１の生存確認を行わない。
【０１１７】
具体的に説明するに、このノード脱退通知ルーチンが実行されると、まず、ステップＳ５０１において、監視ノード数、すなわち、自ノード装置１の生存確認依頼リストに登録されている監視ノードの数がＮに設定され、さらに、生存確認を依頼すべき複数の監視ノードにそれぞれ付された番号ｉが「１」に設定される。
【０１１８】
次に、ステップＳ５０２において、今回の監視ノードＡ（ｉ）に対して脱退メッセージが送信される。続いて、ステップＳ５０３において、今回の監視ノードＡ（ｉ）からの応答を受け取るのが待たれる。応答を受けたなら、ステップＳ５０４において、番号ｉが１だけインクリメントされ、続いて、ステップＳ５０５において、番号ｉの現在値が監視ノード数Ｎより大きいか否かが判定される。番号ｉの現在値が監視ノード数Ｎより大きくはない場合には、ステップＳ５０２に戻るが、大きい場合には、このノード脱退通知ルーチンの実行が終了する。
【０１１９】
図１５には、図４（ｂ）に示される例についてこのノード脱退通知ルーチンが実行された場合に行われる手続がシーケンス図で表されている。この例においては、監視ノードＡ（１）が、ノードＸからの脱退メッセージがないにもかかわらず、ノードＸの生存確認の応答がなければ、ノードＸが異常停止したことをサーバ２００へ通知する。監視ノードＡ（１）は、サーバ２００への通知に失敗したら、同じ生存確認依頼ノードを監視する他の監視ノードＡ（２）へ代行通知を依頼する。監視ノードＡ（２）は、サーバ２００への通知に成功したら、ノードＸが異常停止したことを、同じ生存確認依頼ノードを監視するすべての監視ノード（ここではＡ（３）のみ）に通知する。
【０１２０】
ここで、図６に示すステップＳ３の詳細を、図９のフローチャートを参照して説明する。前述のように、ステップＳ３は、自ノード装置１が監視ノードとして、すなわち、生存確認依頼ノード装置を監視するノードとして機能するために実行される。
【０１２１】
図９に示すように、ステップＳ３においては、まず、ステップＳ２０１が実行される。このステップＳ２０１においては、自ノード装置１が、監視ノードとして、自ノード装置１に対して生存確認を依頼したノード装置の異常を検知するために、図１６にフローチャートで概念的に表されている生存確認依頼ノード異常検知ルーチンが実行される。この生存確認依頼ノード異常検知ルーチンは、スレッドとして実行され、その結果、他のステップと事実上、並行して実行される。
【０１２２】
概略的に説明するに、この生存確認依頼ノード異常検知ルーチンが実行されると、自ノード装置１（今回は、監視ノードとして機能する）が生存確認依頼ノード（図４に示す例においては、ノードＸ）から脱退メッセージを受信しておらず、しかも、生存確認依頼ノードに対して、その生存を確認するためのメッセージを送信しても、その生存確認依頼ノードから何ら応答がなかった場合には、生存確認依頼ノードが異常停止したと判定し、そのことをサーバ２００に通知する。
【０１２３】
この場合、自ノード装置１は、サーバ２００への通知に失敗すると、同じ生存確認依頼ノードを監視すべき他の複数の監視ノードのちのいずれかを代行監視ノードとして選択し、その代行監視ノードに、生存確認依頼ノードが異常停止したことをサーバ２００に通知することを依頼する。
【０１２４】
具体的に説明するに、この生存確認依頼ノード異常検知ルーチンが実行されると、まず、ステップＳ６０１において、生存確認依頼ノード数、すなわち、自ノード装置１の監視リストに登録されている複数の生存確認依頼ノードの数がＭとして設定され、注目すべき生存確認依頼ノードを特定するための番号ｉが「１」として設定され、生存確認のリトライ回数がＲ（指定値）として設定され、生存確認がリトライされるごとに１ずつインクリメントされる生存確認試行回数ｒが「０」として設定される。
【０１２５】
次に、ステップＳ６０２において、今回の生存確認依頼ノードＸ（ｉ）に関連付けられた生存確認時刻ｔが経過したか否かが判定される。経過していない場合には、ステップＳ６０３において、番号ｉが１だけインクリメントされ、続いて、ステップＳ６０４において、番号ｉの現在値が生存確認依頼ノード数Ｍより大きいか否かが判定される。大きくはない場合には、直ちにステップＳ６０２に戻るが、大きい場合には、ステップＳ６０５において番号ｉの現在値が「１」に戻された後、ステップＳ６０２に戻る。
【０１２６】
今回の生存確認依頼ノードＸ（ｉ）に関連付けられた生存確認時刻ｔが経過した場合には、ステップＳ６０２の判定がＹＥＳとなり、ステップＳ６０６において、生存確認試行回数ｒが「０」に戻され、続いて、ステップＳ６０７において、今回の生存確認依頼ノードＸ（ｉ）に対して、その生存を確認するためのメッセージが送信される。その後、ステップＳ６０８において、今回の生存確認依頼ノードＸ（ｉ）から、自ノード装置１に対して応答があったか否かが判定される。応答があった場合には、直ちにステップＳ６０３に移行するが、応答がなかった場合には、ステップＳ６０９において、生存確認試行回数ｒが１だけインクリメントされる。
【０１２７】
その後、ステップＳ６１０において、生存確認試行回数ｒの現在値がリトライ回数Ｒに一致するか否かが判定される。一致しない場合には、ステップＳ６０７に戻るが、一致する場合には、ステップＳ６１０ａに移行する。このステップＳ６１０ａにおいては、今回の生存確認依頼ノードＸ（ｉ）がネットワーク８上に生存しない、すなわち、異常であると判定される。その後、ステップＳ６１１において、今回の生存確認依頼ノードＸ（ｉ）が異常であることをサーバ２００に通知することが試行される。
【０１２８】
続いて、ステップＳ６１２において、その試行が成功したか否かが判定される。成功した場合には、ステップＳ６１９において、自ノード装置１が、今回の生存確認依頼ノードＸ（ｉ）に対して生存確認を続行することを停止させるために、自ノード装置１の監視リストから今回の生存確認依頼ノードＸ（ｉ）が削除される。
【０１２９】
その後、ステップＳ６２０において、今回の生存確認依頼ノードＸ（ｉ）の生存確認依頼リストに登録されているすべての監視ノードＡ（ｋ）（ｋ＝１，．．．Ｎ）に対して、今回の生存確認依頼ノードＸ（ｉ）が異常であることが通知される。これは、それら監視ノードＡ（ｋ）が、今回の生存確認依頼ノードＸ（ｉ）に対して生存確認を行うことを停止させるためである。続いて、ステップＳ６２１において、生存確認依頼ノード数Ｍが１だけデクリメントされ、その後、ステップＳ６０３に戻る。
【０１３０】
これに対し、今回は、今回の生存確認依頼ノードＸ（ｉ）が異常であることをサーバ２００に通知するための試行が失敗したと仮定すると、ステップＳ６１２の判定がＮＯとなり、ステップＳ６１３において、監視モード数、すなわち、今回の生存確認依頼ノードＸ（ｉ）の生存確認依頼リストに登録されている監視ノードＡ（ｊ）の数がＮとして設定され、さらに、番号ｊが「１」として設定される。
【０１３１】
続いて、ステップＳ６１４において、今回の生存確認依頼ノードＸ（ｉ）の生存確認依頼リストに登録されている監視ノードＡのうち今回の監視ノードＡ（ｊ）に、今回の生存確認依頼ノードＸ（ｉ）が異常であることをサーバ２００に通知するための試行が依頼される。すなわち、今回の監視ノードＡ（ｊ）が、前述の代行監視ノードなのである。
【０１３２】
その後、ステップＳ６１５において、サーバ２００に通知するための試行が成功したか否かが判定される。成功した場合には、ステップＳ６１９に移行するが、失敗した場合には、ステップＳ６１６において、番号ｊの現在値が１だけインクリメントされ、続いて、ステップＳ６１７において、番号ｊの現在値が監視ノード数Ｎより大きいか否かが判定される。大きくはない場合には、直ちにステップＳ６１４に移行するが、大きい場合には、ステップＳ６１８において番号ｊの現在値が「１」に戻された後に、ステップＳ６１４に戻る。
【０１３３】
図１７には、図４（ａ）に示される例についてこの生存確認依頼ノード異常検知ルーチンが実行された場合に行われる手続がシーケンス図で表されている。
【０１３４】
図１８には、サーバ２００によって実行されるプログラムがフローチャートで概念的に表されている。このプログラムが起動すると、まず、ステップＳ６５１において、いずれかの監視ノードから、いずれかのノード装置１（生存確認依頼ノード）がネットワーク８上に生存しないこと、すなわち、異常ノードが存在することを表す通知を受け取ることが待たれる。
【０１３５】
異常ノードが存在することを表す通知をサーバ２００が受け取ると、ステップＳ６５２において、その異常ノードの、ネットワーク８上における設置位置を特定するために、記憶部２０４へのアクセスが行われる。その記憶部２０４には、ネットワーク８に参加している複数のノード装置１の設置位置が、各ノード装置１に固有のノードＩＤに関連付けて予め記憶されている。
【０１３６】
したがって、このステップＳ６５２においては、今回の異常ノードに固有のノードＩＤをキーワードとして記憶部２０４を検索することにより、その異常ノードの設置場所を特定するためのデータが記憶部２０４から取得される。
【０１３７】
続いて、ステップＳ６５３において、その取得されたデータに基づき、今回の異常ノードの設置位置が特定され、その後、ステップＳ６５４において、今回の異常ノードが、その特定された設置位置に存在することを表す情報が出力装置２１２の画面上に表示される。続いて、ステップＳ６５５において、サーバ２００に接続された前述のクライアントが存在する場合には、そのクライアントに、ネットワーク８を通じて、今回の異常ノードが、その特定された設置位置に存在することを表す情報が送信される。その後、ステップＳ６５１に戻る。
【０１３８】
図９に戻ると、ステップＳ２０２において、自ノード装置１が、いずれかの生存確認依頼ノードから、生存確認依頼を受信したか否かが判定される。受信した場合には、ステップＳ２０３において、自ノード装置１が自己の監視リストを作成するために、図１９にフローチャートで概念的に表されている監視リスト作成ルーチンが実行される。
【０１３９】
この監視リスト作成ルーチンが実行されると、まず、ステップＳ７０１において、生存確認依頼ノード数、すなわち、自ノード装置１の監視リストに登録されている生存確認依頼ノードの数がＭに設定される。
【０１４０】
次に、ステップＳ７０２において、生存確認依頼ノード数Ｍが、自ノード装置１が監視可能であるノード数の上限値Ｍｍａｘ以下であるか否かが判定される。生存確認依頼ノード数Ｍが上限値Ｍｍａｘ以下であれば、ステップＳ７０３において、図１０におけるステップＳ３１０において生存確認依頼を出した生存確認依頼ノードに対して肯定応答が行われるが、生存確認依頼ノード数Ｍが上限値Ｍｍａｘを超えていれば、ステップＳ７０６において、否定応答が行われる。このステップＳ７０６の実行が終了すると、この監視リスト作成ルーチンの実行も終了する。
【０１４１】
ステップＳ７０３において肯定応答が行われた場合には、その後、ステップＳ７０４において、監視ノード数Ｍが１だけインクリメントされる。その後、ステップＳ７０５において、追加されたＭ番目の生存確認依頼ノードＸ（Ｍ）のノードＩＤ、ＩＰアドレスおよび生存確認時刻ｔが、自ノード装置１の監視リストに記憶される。以上で、この監視リスト作成ルーチンの実行が終了する。
【０１４２】
図９に戻ると、ステップＳ２０２の判定がＮＯである場合には直ちに、ＹＥＳである場合にはステップＳ２０３の実行を経た後に、ステップＳ２０４が実行される。このステップＳ２０４においては、生存確認の対象であるノード（すなわち、監視されている最中である生存確認依頼ノード）から、自ノード装置１が脱退メッセージを受信したか否かが判定される。自ノード装置１が脱退メッセージを受信した場合には、ステップＳ２０５において、その脱退しようとしている生存確認依頼ノードを監視リストから削除するために、図２０にフローチャートで概念的に表されている脱退ノード削除ルーチンが実行される。
【０１４３】
この脱退ノード削除ルーチンが実行されると、まず、ステップＳ８０１において、生存確認依頼ノード数、すなわち、自ノード装置１の監視リストに登録されている生存確認依頼ノードの数がＭに設定され、さらに、注目すべき生存確認依頼ノードを特定するための番号ｉが「１」に設定される。
【０１４４】
次に、ステップＳ８０２において、脱退メッセージを送信した生存確認依頼ノード（図３に示す例においては、例えば、ノードＸが該当する可能性があるため、以下、説明の便宜上、「脱退メッセージを送信したノードＸ」という。）のノードＩＤと、今回の生存確認依頼ノードＸ（ｉ）のノードＩＤとが互いに一致するか否かが判定される。一致しない場合には、ステップＳ８０３において、番号ｉが１だけインクリメントされる。
【０１４５】
その後、ステップＳ８０４において、番号ｉの現在値が生存確認依頼ノード数Ｍより大きいか否かが判定される。大きくはない場合には、ステップＳ８０２に戻るが、大きい場合には、ステップＳ８０６に移行する。脱退メッセージを送信したノードＸのノードＩＤと、今回の生存確認依頼ノードＸ（ｉ）のノードＩＤとが互いに一致する場合には、ステップＳ８０５において、監視リストから今回の生存確認依頼ノードＸ（ｉ）が削除された後、ステップＳ８０６に移行する。
【０１４６】
いずれにしても、ステップＳ８０６においては、脱退メッセージを送信したノードＸに対し、脱退メッセージを受信した旨の応答が行われる。以上で、この脱退ノード削除ルーチンの実行が終了する。
【０１４７】
図９に戻ると、ステップＳ２０４の判定がＮＯである場合には直ちに、ＹＥＳである場合には、ステップＳ２０５を経た後に、ステップＳ２０６が実行される。このステップＳ２０６においては、本来の監視ノードではない別の監視ノードが、生存確認依頼ノードが異常であることをサーバ２００に通知させることを代行させられる。すなわち、代行監視ノードによるサーバ２００への通知が行われるのである。その代行通知のために、図２１にフローチャートで概念的に表されている代行通知ルーチンが実行される。
【０１４８】
概略的に説明するに、この代行通知ルーチンが実行されると、自ノード装置１は、他の監視ノードによるサーバ２００への通知を代行する代行監視ノードとして、生存確認依頼ノードが異常停止したことをサーバ２００に通知することを試行する。自ノード装置１は、その試行に成功すると、同じ生存確認依頼ノードを監視すべき他の監視ノードに対し、生存確認依頼ノードが異常停止したことを通知する。
【０１４９】
具体的に説明するに、この代行通知ルーチンが実行されると、まず、ステップＳ９０１において、他の監視ノードから、監視対象である生存確認依頼ノードが生存していないこと（すなわち、異常であること）が通知されたか否かが判定される。通知された場合には、ステップＳ９０２において、自ノード装置１の監視リストから、その生存しない生存確認依頼ノードが削除され、その後、ステップＳ９０３に移行する。これに対し、他の監視ノードから、監視されつつある生存確認依頼ノードが生存していないことが通知されなかった場合には、直ちにステップＳ９０３に移行する。
【０１５０】
いずれの場合にも、ステップＳ９０３においては、他の監視ノードから、自ノード装置１が代行監視ノードとして、サーバ２００への通知を試行することを依頼されたか否かが判定される。代行通知が依頼されなかった場合には、直ちにこの代行通知ルーチンの実行が終了する。これに対し、代行通知が依頼された場合には、ステップＳ９０４において、生存しない生存確認依頼ノードの存在、すなわち、特定の生存確認依頼ノードが異常であることをサーバ２００に通知することが試行される。
【０１５１】
その後、ステップＳ９０５において、その試行が成功したか否かが判定される。成功した場合には、ステップＳ９０６において、自ノード装置１の監視リストから、生存しない生存確認依頼ノードが削除される。その後、ステップＳ９０７に移行する。これに対し、生存しない生存確認依頼ノードの存在をサーバ２００に通知するための試行が失敗した場合には、直ちにステップＳ９０７に移行する。
【０１５２】
いずれの場合にも、ステップＳ９０７においては、サーバ２００への通知の成否が、前記他の監視ノードに対して回答される。以上で、この代行通知ルーチンの実行が終了する。
【０１５３】
その後、図９に示すステップＳ２０７において、自ノード装置１に対し、ユーザからシャットダウン要求が出されたか否かが判定される。出されなかった場合には、ステップＳ２０２に戻るが、出された場合には、ステップＳ２０８に移行する。
【０１５４】
このステップＳ２０８においては、監視ノードがネットワーク８から脱退するために、図２２にフローチャートで概念的に表されている監視ノード脱退ルーチンが実行される。
【０１５５】
概略的に説明するに、この監視ノード脱退ルーチンが実行されると、生存確認依頼ノードＸより先に監視ノードがネットワーク８から脱退しようとする場合には、その監視ノードは、それの監視対象であるノードＸに、ネットワーク８からの脱退を通知する。監視ノードの脱退を通知されたノードＸは、図８に示すステップＳ１０４の実行により、その監視ノードを生存確認依頼リストから削除する。ある監視ノードが生存確認依頼リストから削除されると、それに代わり、別のノード装置１が新たな監視ノードとして選択される。
【０１５６】
具体的に説明するに、この監視ノード脱退ルーチンが実行されると、まず、ステップＳ１００１において、生存確認依頼ノード数、すなわち、自ノード装置１の監視リストに登録されている生存確認依頼ノードの数がＭに設定され、さらに、注目すべき生存確認依頼ノードを特定するための番号ｉが「１」に設定される。
【０１５７】
次に、ステップＳ１００２において、番号ｉの現在値が生存確認依頼ノード数Ｍ以下であるか否かが判定される。そうであれば、ステップＳ１００３において、今回の生存確認依頼ノードＸ（ｉ）に対して、自ノード装置１がネットワーク８から脱退することを表す脱退メッセージが送信される。続いて、ステップＳ１００４において、今回の生存確認依頼ノードＸ（ｉ）から、その脱退メッセージを受信したことを表す応答を受け取るのが待たれる。受け取ったならば、ステップＳ１００５において、番号ｉの現在値が１だけインクリメントされる。その後、ステップＳ１００２に戻る。
【０１５８】
番号ｉの現在値が生存確認依頼ノード数Ｍより大きい場合には、ステップＳ１００２の判定がＮＯとなり、ステップＳ１００６に移行する。このステップＳ１００６においては、図１４に示すノード脱退通知ルーチンが実行されることにより、監視ノードとしての自ノード装置１がネットワーク８から脱退することが他の監視ノードに通知される。以上で、この監視ノード脱退ルーチンの実行が終了する。これにより、図９に示すステップＳ３の実行が終了する。
【０１５９】
図２３には、図４（ａ）に示される例についてこの監視ノード脱退ルーチンが実行された場合に行われる手続がシーケンス図で表されている。
【０１６０】
以上の説明から明らかなように、本実施形態においては、説明の便宜上、各ノード装置１のうち、図１０に示すステップＳ１０１を実行する部分が前記（１）項における「監視ノード選択手段」の一例を構成し、図１６に示すステップＳ６１０ａを実行する部分が同項における「生存判定手段」の一例を構成し、同図に示すステップＳ６１１が同項における「通知手段」の一例を構成していると考えることが可能である。
【０１６１】
さらに、本実施形態においては、説明の便宜上、サーバ２００の記憶部２０４が前記（２）項における「記憶手段」の一例を構成し、サーバ２００のうち、図１８に示すプログラムを実行する部分が同項における「位置特定手段」の一例を構成していると考えることが可能である。
【０１６２】
さらに、本実施形態においては、説明の便宜上、各ノード装置１のうち、図１６に示すステップＳ６０７を実行する部分が、前記（３）項における「監視手段」の一例を構成し、同図に示すステップＳ６０８、Ｓ６０９、Ｓ６１０およびＳ６１０ａを実行する部分が、同項における「生存判定手段」の一例を構成し、同図に示すステップＳ６１１を実行する部分が、同項における「通知手段」の一例を構成していると考えることが可能である。
【０１６３】
さらに、本実施形態においては、説明の便宜上、各ノード装置１のうち、図１６に示すステップＳ６０２ないしＳ６０７、Ｓ６０９およびＳ６１０を実行する部分が、前記（４）項における「時限的監視手段」の一例を構成していると考えることが可能である。
【０１６４】
さらに、本実施形態においては、説明の便宜上、各ノード装置１のうち、図１６に示すステップＳ６０７を実行する部分が、前記（５）項における「送信手段」の一例を構成し、同図に示すステップＳ６１０ａを実行する部分が、同項における「判定手段」の一例を構成していると考えることが可能である。
【０１６５】
さらに、本実施形態においては、説明の便宜上、各ノード装置１の記憶部１２のうち、生存確認依頼リストを記憶する部分が、前記（６）項における「監視ノード記憶手段」の一例を構成し、図１６に示すステップＳ６２０を実行する部分が、同項における「他監視ノード通知手段」の一例を構成していると考えることが可能である。
【０１６６】
さらに、本実施形態においては、説明の便宜上、各ノード装置１のうち、図９に示すステップＳ２０８を実行する部分が、前記（７)項における「脱退通知手段」の一例を構成していると考えることが可能である。
【０１６７】
さらに、本実施形態においては、説明の便宜上、各ノード装置１の記憶部１２のうち、監視リストを記憶する部分が、前記（８）項における「生存確認依頼ノード記憶手段」の一例を構成し、各ノード装置１のうち、図１９に示すステップＳ７０２を実行する部分が、同項における「ノード数判定手段」の一例を構成し、同図に示すステップＳ７０３およびＳ７０６を実行する部分が、同項における「依頼受諾・拒否手段」の一例を構成していると考えることが可能である。
【０１６８】
さらに、本実施形態においては、説明の便宜上、各ノード装置１の記憶部１２のうち、生存確認依頼リストを記憶する部分が、前記（９）項における「監視ノード記憶手段」の一例を構成し、図１６に示すステップＳ６１３ないしＳ６１８を実行する部分が、同項における「代行通知手段」の一例を構成していると考えることが可能である。
【０１６９】
さらに、本実施形態においては、説明の便宜上、各ノード装置１のうち、図８に示すステップＳ１０１を実行する部分が、前記（１０)項における「監視ノード選択手段」の一例を構成し、図１０に示すステップＳ３１０を実行する部分が、同項における「生存確認依頼手段」の一例を構成していると考えることが可能である。
【０１７０】
さらに、本実施形態においては、説明の便宜上、各ノード装置１のうち、図１２に示すステップＳ４０２を実行する部分が、前記（１１)項における「監視ノード判定手段」の一例を構成し、同図に示すステップＳ４０６を実行する部分が、同項における「監視ノード変更手段」の一例を構成していると考えることが可能である。
【０１７１】
さらに、本実施形態においては、説明の便宜上、各ノード装置１のうち、図１２に示すステップＳ４０２を実行する部分が、前記（１２)項における「未生存確認判定手段」の一例を構成していると考えることが可能である。
【０１７２】
さらに、本実施形態においては、説明の便宜上、各ノード装置１のうち、図１３に示すステップＳ４５２ないしＳ４５７を実行する部分が、前記（１３)項における「監視ノード変更手段」の一例を構成していると考えることが可能である。
【０１７３】
さらに、本実施形態においては、説明の便宜上、図６に示すメインプログラムが、前記（１４）項に係る「プログラム」の一例を構成していると考えることが可能である。
【０１７４】
以上、本発明の実施の形態のいくつかを図面に基づいて詳細に説明したが、これらは例示であり、前記［発明の開示］の欄に記載の態様を始めとして、当業者の知識に基づいて種々の変形、改良を施した他の形態で本発明を実施することが可能である。
【図面の簡単な説明】
【０１７５】
【図１】本発明の一実施形態に従う情報通信システムにおけるネットワークの物理的構成と論理的構成とを概念的に表す系統図である。
【図２】図１に示す各ノード装置の概略的なハードウエア構成の一例を概念的に表すブロック図である。
【図３】図１に示す情報通信システムにおいて各ノード装置がネットワークに参加するために作成されるルーティングテーブルの一例を示す図である。
【図４】図１に示す情報通信システムにおいてノードＸの異常がルーティングテーブルを利用して他のノードＡによって検知されてサーバ２００に通知される様子を説明するための図である。
【図５】図４に示すサーバの構成を概念的に表すブロック図である。
【図６】図１に示す各ノード装置のコンピュータによって実行されるメインプログラムを概念的に表すフローチャートである。
【図７】図７（ａ）は、図１に示す各ノード装置が使用する生存確認依頼リストの一例を説明するための図であり、図７（ｂ）は、図１に示す各ノード装置が使用する監視リストの一例を説明するための図である。
【図８】図６に示すステップＳ２の詳細を生存確認依頼ルーチンとして概念的に表すフローチャートである。
【図９】図６に示すステップＳ３の詳細を監視ルーチンとして概念的に表すフローチャートである。
【図１０】図８に示すステップＳ１０１の詳細を生存確認依頼リスト作成ルーチンとして概念的に表すフローチャートである。
【図１１】図１０に示す生存確認依頼リスト作成ルーチンの一実行例を説明するためのシーケンス図である。
【図１２】図８に示すステップＳ１０２の詳細を監視ノード異常検知ルーチンとして概念的に表すフローチャートである。
【図１３】図８に示すステップＳ１０４の詳細を監視ノード削除ルーチンとして概念的に表すフローチャートである。
【図１４】図８に示すステップＳ１０６の詳細をノード脱退通知ルーチンとして概念的に表すフローチャートである。
【図１５】図１４に示すノード脱退通知ルーチンの一実行例を説明するためのシーケンス図である。
【図１６】図９に示すステップＳ２０１の詳細を生存確認依頼ノード異常検知ルーチンとして概念的に表すフローチャートである。
【図１７】図１６に示す生存確認依頼ノード異常検知ルーチンの一実行例を説明するためのシーケンス図である。
【図１８】図５に示すサーバのコンピュータによって実行されるプログラムを概念的に表すフローチャートである。
【図１９】図９に示すステップＳ２０３の詳細を監視リスト作成ルーチンとして概念的に表すフローチャートである。
【図２０】図９に示すステップＳ２０５の詳細を脱退ノード削除ルーチンとして概念的に表すフローチャートである。
【図２１】図９に示すステップＳ２０６の詳細を代行通知ルーチンとして概念的に表すフローチャートである。
【図２２】図９に示すステップＳ２０８の詳細を監視ノード脱退ルーチンとして概念的に表すフローチャートである。
【図２３】図２２に示す監視ノード脱退ルーチンの一実行例を説明するためのシーケンス図である。
【符号の説明】
【０１７６】
１  ノード装置
８  ネットワーク
９  オーバレイネットワーク
１１  制御部
１２  記憶部
１３  バッファメモリ
１４  デコーダ部
１５  映像処理部
１６  表示部
１７  音声処理部
１８  スピーカ
２０  通信部
２１  入力部
２２  バス
２００  サーバ
Ｓ  情報通信システム
【図１】
0004780075.tif 000002
【図２】
0004780075.tif 000003
【図３】
0004780075.tif 000004
【図４】
0004780075.tif 000005
【図５】
0004780075.tif 000006
【図６】
0004780075.tif 000007
【図７】
0004780075.tif 000008
【図８】
0004780075.tif 000009
【図９】
0004780075.tif 000010
【図１０】
0004780075.tif 000011
【図１１】
0004780075.tif 000012
【図１２】
0004780075.tif 000013
【図１３】
0004780075.tif 000014
【図１４】
0004780075.tif 000015
【図１５】
0004780075.tif 000016
【図１６】
0004780075.tif 000017
【図１７】
0004780075.tif 000018
【図１８】
0004780075.tif 000019
【図１９】
0004780075.tif 000020
【図２０】
0004780075.tif 000021
【図２１】
0004780075.tif 000022
【図２２】
0004780075.tif 000023
【図２３】
0004780075.tif 000024