(57)【要約】【課題】高い信頼性を備えるアプリケーション間通信のためのプログラムを提供する。【解決手段】上記課題を解決するために、通信制御部１１１に、アプリケーションＡまたはＢからの要求に応じてアプリケーション間通信用のセション処理を行うアプリケーション間通信用セション処理部７１０と、異常監視用のセション処理を行う異常監視用セション処理部７２０と、通信パケットの送受信処理を行う共通制御部７３０と、を備える。【選択図】図９
2010081496.tif 000002
【特許請求の範囲】
【請求項１】
物理的に独立した２以上の通信経路と互いに通信可能に接続されたノード間で行う通信であって、第１のノード上で動作する第１のアプリケーションと第２のノード上で動作する第２のアプリケーションとで行われるアプリケーション間通信において、
前記第１のアプリケーションと前記第２のアプリケーションとの間で通信するためのアプリケーション間通信用セションの確立の要求を前記第１のアプリケーションから受けると、前記第１のノード上で動作し少なくとも前記第１のアプリケーションの通信を制御する第１の通信制御部と、前記第２のノード上で動作し少なくとも前記第２のアプリケーションの通信を制御する第２の通信制御部との間に、通信の異常を監視する異常監視通信を行うための異常監視用セションが既に確立されているか否かを確認し、該異常監視用セションが確立されていない場合には、前記第２の通信制御部に対して、前記異常監視用セションの確立を要求して該異常監視用セションを確立する異常監視用セション確立処理と、
前記異常監視用セションが確立すると、前記アプリケーション間通信用セションの確立を前記第２のアプリケーションに要求して前記アプリケーション間通信用セションを確立するアプリケーション間通信用セション確立処理と、
前記アプリケーション間通信用セションにおいて前記第２のアプリケーションから一定時間応答を受信しない場合に再度前記第２のアプリケーションに同一内容の通信パケットを送信する再送処理の間隔より短い間隔で、前記異常監視用セションにおいて異常監視に必要な情報のみを用いて異常監視通信を行う異常監視通信処理と、
を全ての前記通信経路に対して同一の通信パケットを同時に送信することにより前記第１のノードに実行させるプログラム。
【請求項２】
前記第１の通信制御部は、前記第１のアプリケーションが動作するオペレーティング・システム上で動作し、該オペレーティング・システム上で動作する全てのアプリケーション間通信を行うアプリケーションの通信を制御し、
前記第２の通信制御部は、前記第２のアプリケーションが動作するオペレーティング・システム上で動作し、該オペレーティング・システム上で動作する全てのアプリケーション間通信を行うアプリケーションの通信を制御する、
ことを特徴とする請求項１に記載のプログラム。
【請求項３】
前記異常監視用セションにおいて、前記第１の通信制御部は、前記第２の通信制御部に送る通信パケットにマルチキャストＩＰアドレスを設定して送信する、
ことを特徴とする請求項１に記載のプログラム。
【請求項４】
物理的に独立した２以上の通信経路と互いに通信可能に接続されたノード間で行う通信であって、第１のノード上で動作する第１のアプリケーションと第２のノード上で動作する第２のアプリケーションとで行われるアプリケーション間通信において、
前記第１のノード上で動作し少なくとも前記第１のアプリケーションの通信を制御する第１の通信制御部から、該第１の通信制御部と前記第２のノード上で動作し少なくとも前記第２のアプリケーションの通信を制御する第２の通信制御部との間で通信の異常を監視する異常監視通信を行うための前記異常監視用セションの確立の要求を受けると、Ｉ／Ｏ割込みに連動して、前記第１の通信制御部と前記異常監視用セションを確立する異常監視用セション確立処理と、
前記第１の通信制御部から、前記第１のアプリケーションと前記第２のアプリケーションとの間で通信するためのアプリケーション間通信用セションの確立の要求を受けると、前記第１のアプリケーションと前記アプリケーション間通信用セションを確立するアプリケーション間通信用セション確立処理と、
前記アプリケーション間通信用セションにおいて前記第２のアプリケーションから一定時間応答を受信しない場合に第１のアプリケーションが再度前記第２のアプリケーション
に同一内容の通信パケットを送信する再送処理の間隔より短い間隔で、前記異常監視用セションにおいて異常監視に必要な情報のみを用いて異常監視通信を行う異常監視通信処理と、
を全ての前記通信経路に対して同一の通信パケットを同時に送信することにより前記第２のノードに実行させるプログラム。
【請求項５】
物理的に独立した２以上の通信経路と互いに通信可能に接続されたノード間で行う通信であって、第１のノード上で動作する第１のアプリケーションと第２のノード上で動作する第２のアプリケーションとで行われるアプリケーション間通信において、
前記第１のアプリケーションと前記第２のアプリケーションとの間で通信するためのアプリケーション間通信用セションの確立の要求を前記第１のアプリケーションから受けると、前記第１のノード上で動作し少なくとも前記第１のアプリケーションの通信を制御する第１の通信制御部と、前記第２のノード上で動作し少なくとも前記第２のアプリケーションの通信を制御する第２の通信制御部との間に、通信の異常を監視する異常監視通信を行うための異常監視用セションが既に確立されているか否かを確認し、該異常監視用セションが確立されていない場合には、前記第２の通信制御部に対して、前記異常監視用セションの確立を要求して該異常監視用セションを確立する異常監視用セション確立処理と、
前記異常監視用セションが確立すると、前記アプリケーション間通信用セションの確立を前記第２のアプリケーションに要求して前記アプリケーション間通信用セションを確立するアプリケーション間通信用セション確立処理と、
前記アプリケーション間通信用セションにおいて前記第２のアプリケーションから一定時間応答を受信しない場合に再度前記第２のアプリケーションに同一内容の通信パケットを送信する再送処理の間隔より短い間隔で、前記異常監視用セションにおいて異常監視に必要な情報のみを用いて異常監視通信を行う異常監視通信処理と、
を全ての前記通信経路に対して同一の通信パケットを同時に送信することにより前記第１のノードに実行させる通信方法。
【請求項６】
物理的に独立した２以上の通信経路と互いに通信可能に接続されたノード間で行う通信であって、第１のノード上で動作する第１のアプリケーションと第２のノード上で動作する第２のアプリケーションとで行われるアプリケーション間通信において、
前記第１のノード上で動作し少なくとも前記第１のアプリケーションの通信を制御する第１の通信制御部から、該第１の通信制御部と前記第２のノード上で動作し少なくとも前記第２のアプリケーションの通信を制御する第２の通信制御部との間で通信の異常を監視する異常監視通信を行うための前記異常監視用セションの確立の要求を受けると、Ｉ／Ｏ割込みに連動して、前記第１の通信制御部と前記異常監視用セションを確立する異常監視用セション確立処理と、
前記第１の通信制御部から、前記第１のアプリケーションと前記第２のアプリケーションとの間で通信するためのアプリケーション間通信用セションの確立の要求を受けると、前記第１のアプリケーションと前記アプリケーション間通信用セションを確立するアプリケーション間通信用セション確立処理と、
前記アプリケーション間通信用セションにおいて前記第２のアプリケーションから一定時間応答を受信しない場合に第１のアプリケーションが再度前記第２のアプリケーションに同一内容の通信パケットを送信する再送処理の間隔より短い間隔で、前記異常監視用セションにおいて異常監視に必要な情報のみを用いて異常監視通信を行う異常監視通信処理と、
を全ての前記通信経路に対して同一の通信パケットを同時に送信することにより前記第２のノードに実行させる通信方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、アプリケーション間通信の高信頼化を実現する技術に関する。
【背景技術】
【０００２】
従来、ネットワーク等を介して接続されるそれぞれのノード上で動作するアプリケーション間の通信の可用性を高めるために、次のような対策が行われている。なお、このアプリケーション間の通信を単に「アプリケーション間通信」という。
【０００３】
（１）ネットワークの通信経路を冗長化する。
ネットワークの高信頼化を図るために、図３０に示すように、ルータなどのネットワーク機器や通信経路を冗長化し、ダイナミックルーティングプロトコルを用いて経路障害を検知し通信経路を切替える処理が一般に行われている。
【０００４】
図３０は、ルータ＃２−ルータ＃４間およびルータ＃２−ルータ＃５間でネットワーク異常を検出した場合に、ルーティングプロトコルを用いて実線で示す通信経路から破線で示す通信経路に通信経路の切替えを行う処理の概要を示している。
【０００５】
しかし、ルーティングプロトコルを用いて動的に通信経路を変更するには、高速に切替えが可能なＯＳＰＦ（Ｏｐｅｎ  Ｓｈｏｒｔｅｓｔ  Ｐａｔｈ  Ｆｉｒｓｔ）プロトコルを用いても、ルータ全体の整合性を確保する等の処理が必要なために最低でも１０秒程度を要する。
【０００６】
また、ＴＣＰプロトコルを用いる場合、送信先のノードから確認応答がないと、送信元のノードは再送処理を行う。この再送処理が行われる間隔は、再送処理が行われる毎に倍の時間に設定される。
【０００７】
図３１は、アプリケーション間通信における再送処理の間隔を説明する図である。
図３１に示すように、最初の再送処理は、送信処理から１秒後に行われる。その次の送信処理は、最初の再送処理から２秒後に行われる。同様にして、前回の再送処理から４秒後、８秒後に次の再送処理が行われる。
【０００８】
そのため、図３１で示すように、通信可能な通信経路に切替えが完了しても、すぐには再送処理が行われない場合がある。図３１の場合、通信可能な通信経路への切替えが完了してから、さらに８秒程度経過しないと再送処理が行われない。
【０００９】
その結果、ネットワーク内の通信経路に異常が生じた場合、アプリケーション間通信の中断時間が長くなってしまう。
【００１０】
（２）アプリケーション間通信における異常検知時間を短縮して異常の検知を高速化する。
図３２および図３３は、アプリケーション間通信における再送処理の間隔を短縮した再送処理を説明する図である。
図３２に示すように、ネットワーク異常を検出してから通信経路の切替え完了までに要する時間よりも短い一定値に再送処理の間隔を設定すると、送信元ノードが、通信経路の切替え完了前に誤って異常を検出する可能性がある。この場合、ネットワークを冗長構成にすることで得られるはずの高い信頼性を発揮することができない。
【００１１】
さらに、短い間隔で再送処理を行う場合、送信元ノードは通信経路の切替え中に何度も再送処理を行うことになるので、送信元ノードが大量の再送データを送信し、通信帯域を圧迫すると同時に送信元ノードのＣＰＵの負荷を増大させてしまう。
【００１２】
また、図３３に示すように、送信先ノードにおけるアプリケーションの処理が一時的に遅延した場合でも、送信元ノードは、再送処理の間隔が短いために誤って送信先ノードまたは通信経路に異常が発生したと判断をしてしまう。
【００１３】
以上のように、再送処理の間隔、すなわち異常検知時間を短くすると、送信元ノードが誤って異常を検出してしまう。
【００１４】
（３）サーバとして動作するノードを冗長化してサーバ側におけるネットワーク障害時のシステム継続率を向上する。
サーバとして動作するノードの高信頼化を図るために、複数台のノードでクラスタリングし、各ノード内部品（ハードウェア、ソフトウェア）および各ノード用ネットワーク接続機器を冗長化し、何れかのノードで障害が発生した時に現用系装置、すなわちアクティブ・ノードを切替える処理が一般に行われている。
【００１５】
図３４は、サーバとして動作するノードの冗長化構成の例を示す図である。
図３４に示すノードＸ、ノードＹおよびノードＺは、クラスタ構成を成す。そして、ノードＸはアクティブ・ノードである。また、ノードＹおよびノードＺは待機系装置、すなわちスタンバイ・ノードである。また、クラスタ構成を成すノードＸ、ノードＹおよびノードＺは、ルータ＃５を介して互いに双方向の通信監視を行う。
【００１６】
例えば、ノードＸに通信異常を検出すると、スタンバイ・ノードであるノードＹまたはノードＺのうちあらかじめ設定された優先度が高いノードＹをアクティブ・ノードに切替える。
【００１７】
しかし、切替え先となるスタンバイ・ノードが複数存在する場合、サーバ側の異常検知だけでは、送信元ノードとのアプリケーション間通信を継続するために最適なノードを判断することは難しい。
【００１８】
例えば、ノードＸからノードＹにアクティブ・ノードを切替えた時に、ルータ＃４とノードＹとの間で通信異常が発生していると、アプリケーション間通信を継続することができなくなってしまう。
【００１９】
上記技術に関連して、同報通信を行うネットワークシステムにおける伝送路の異常検出および伝送路の切り換えを行うことにより、同報通信を行うネットワークシステムの高信頼化を図る同報通信異常時の伝送路切り換え方式が知られている。また、通信負担を軽減するとともに、確実に制御装置からオペレータステーションに様々なメッセージの通知を行う分散型制御装置について知られている。
【特許文献１】特開平０４−２０７３３８号公報
【特許文献２】特開平０６−２５３３７３号公報
【発明の開示】
【発明が解決しようとする課題】
【００２０】
本発明は、上述した問題に鑑みてなされたものであり、その解決しようとする課題は、高い信頼性を備えるアプリケーション間通信のためのプログラムを提供することである。
【課題を解決するための手段】
【００２１】
上記課題を解決するために、本プログラムは、物理的に独立した２以上の通信経路と互いに通信可能に接続されたノード間で行う通信であって、第１のノード上で動作する第１のアプリケーションと第２のノード上で動作する第２のアプリケーションとで行われるアプリケーション間通信において、前記第１のアプリケーションと前記第２のアプリケーションとの間で通信するためのアプリケーション間通信用セションの確立の要求を前記第１のアプリケーションから受けると、前記第１のノード上で動作し少なくとも前記第１のアプリケーションの通信を制御する第１の通信制御部と、前記第２のノード上で動作し少なくとも前記第２のアプリケーションの通信を制御する第２の通信制御部と、の間に、通信の異常を監視する異常監視通信を行うための異常監視用セションが既に確立されているか否かを確認し、該異常監視用セションが確立されていない場合には、前記第２の通信制御部に対して、前記異常監視用セションの確立を要求して該異常監視用セションを確立する異常監視用セション確立処理と、前記異常監視用セションが確立すると、前記アプリケーション間通信用セションの確立を前記第２のアプリケーションに要求して前記アプリケーション間通信用セションを確立するアプリケーション間通信用セション確立処理と、前記アプリケーション間通信用セションにおいて前記第２のアプリケーションから一定時間応答を受信しない場合に再度前記第２のアプリケーションに同一内容の通信パケットを送信する再送処理の間隔より短い間隔で、前記異常監視用セションにおいて異常監視に必要な情報のみを用いて異常監視通信を行う異常監視通信処理と、を全ての前記通信経路に対して同一の通信パケットを同時に送信することにより前記第１のノードに実行させる。
【００２２】
本プログラムによると、物理的に独立した２以上の通信経路と互いに通信可能に接続されたノード間において、全ての前記通信経路に対して同一の通信パケットを同時に送信することにより通信が行われるので、１の通信経路に異常が発生しても、他の通信経路を介して通信が可能となる。通信経路の切替え等を行う必要がなくなるので、アプリケーション間通信を中断せずに継続することが可能となる。
【００２３】
また、異常監視用セションでは、アプリケーション間通信用セションで行われる再送処理の間隔より短い間隔で、異常監視通信を行うことができるので、アプリケーション間通信用セションにおける再送処理の間隔を十分長く設定することが可能となる。
【００２４】
さらに、異常監視用セションは、第１の通信制御部と第２の通信制御部との間に、通信の異常を監視する異常監視通信を行うための異常監視用セションが確立されていない場合にだけ確立される。そして、異常監視用セションでは、異常監視に必要な情報のみを用いて異常監視通信が行われる。
【００２５】
その結果、通信経路の帯域と各ノードの通信にかかる負荷を大幅に改善することが可能となる。
【発明の効果】
【００２６】
以上に説明したように、本プログラムによると、高い信頼性を備えるアプリケーション間通信を提供することができる。
【発明を実施するための最良の形態】
【００２７】
以下、本発明の実施形態について、図１〜図２９に基づいて説明する。
図１は、本実施例に係るアプリケーション間通信を実現するシステム構成の例を示す図である。
【００２８】
システム１００は、クライアントとして動作するノード１１０と、サーバとして動作するノード１２０および１３０と、互いに独立な２つのネットワーク１４０および１４１と、を備える。以下、クライアントとして動作するノードを「クライアントノード」という
。また、サーバとして動作するノードを「サーバノード」という。
【００２９】
クライアントノード１１０とサーバノード１２０は、ネットワーク１４０および１４１を介して通信可能に接続されている。同様に、クライアントノード１１０とサーバノード１３０は、ネットワーク１４０および１４１を介して通信可能に接続されている。
【００３０】
クライアントノード１１０は、例えば、所定のプログラムを実行するＣＰＵ、プログラムやデータを一時的に記憶するメモリ、プログラムやデータを記憶する記憶装置、ネットワークと接続して通信を行う通信装置を少なくとも備える情報処理装置である。
【００３１】
図１の例では、クライアントノード１１０が、アプリケーション間通信を行うアプリケーションＡおよびＢを実行している場合を示している。
クライアントノード１１０は、所定のプログラムをＯＳ（Ｏｐｅｒａｔｉｎｇ  Ｓｙｓｔｅｍ）上で動作させることにより、本実施例に係るアプリケーション間通信の実現に必要な通信制御を行う通信制御部１１１を実現する。
【００３２】
同様に、サーバノード１２０および１３０は、例えば、所定のプログラムを実行するＣＰＵ、プログラムやデータを一時的に記憶するメモリ、プログラムやデータを記憶する記憶装置、ネットワークと接続して通信を行う通信装置を少なくとも備える情報処理装置である。
【００３３】
図１の例では、サーバノード１２０が、アプリケーション間通信を行うアプリケーションＣを実行し、サーバノード１３０が、アプリケーション間通信を行うアプリケーションＤを実行している場合を示している。
【００３４】
サーバノード１２０は、所定のプログラムをＯＳ上で動作させることにより、本実施例に係るアプリケーション間通信の実現に必要な通信制御を行う通信制御部１２１を実現する。同様に、サーバノード１３０は、所定のプログラムをＯＳ上で動作させることにより、本実施例に係るアプリケーション間通信の実現に必要な通信制御を行う通信制御部１３１を実現する。
【００３５】
また、サーバノード１２０−サーバノード１３０間は、互いにルータ＃００を介して通信可能に接続されている。サーバノード１２０およびサーバノード１３０は、互いに通信を行って通信先のサーバノードに異常がないか否かを監視する。以下、この通信による監視を「サーバノード間異常監視」という。
【００３６】
ネットワーク１４０は、ルータ＃０１〜＃０４を備え、クライアントノード１１０が備えるＮＩＣ（Ｎｅｔｗｏｒｋ  Ｉｎｔｅｒｆａｃｅ  Ｃａｒｄ）と、サーバノード１２０および１３０が備えるＮＩＣと、を接続している。同様に、ネットワーク１４１は、ルータ＃１１〜＃１４を備え、クライアントノード１１０が備えるＮＩＣと、サーバノード１２０および１３０が備えるＮＩＣと、を接続している。
【００３７】
通信制御部１１１は、クライアントノード１１０上で動作するＯＳ上で動作している。同様に、通信制御部１２１は、サーバノード１２０上で動作するＯＳ上で動作し、通信制御部１３１は、サーバノード１３０上で動作するＯＳ上で動作している。
【００３８】
また、アプリケーションＡおよびＢは、クライアントノード１１０上で動作するＯＳ上で動作している。同様に、アプリケーションＣは、サーバノード１２０上で動作するＯＳ上で動作し、アプリケーションＤは、サーバノード１３０上で動作するＯＳ上で動作している。
【００３９】
ただし、クライアントノード１１０において、２つのアプリケーションＡおよびＢがＯＳ上で実行される場合に限定する趣旨ではない。例えば、アプリケーションＡだけがＯＳ上で実行されてもよいし、アプリケーション間通信を行う２以上のアプリケーションがＯＳ上で実行されてもよい。サーバノード１２０および１３０についても同様である。
【００４０】
また、図１では、２つのサーバノード１２０および１３０でクラスタ構成を成す場合を示しているが、これに限定する趣旨ではない。例えば、２以上のサーバノードでクラスタ構成をなしてもよい。
【００４１】
以上の構成において、アプリケーションＡとアプリケーションＣとは、通信制御部１１１、ネットワーク１４０および１４１、通信制御部１２１を介してアプリケーション間通信を行う。アプリケーションＡとアプリケーションＤとは、通信制御部１１１、ネットワーク１４０および１４１、通信制御部１３１を介してアプリケーション間通信を行う。
【００４２】
同様に、アプリケーションＢとアプリケーションＣとは、通信制御部１１１、ネットワーク１４０および１４１、通信制御部１２１を介してアプリケーション間通信を行う。アプリケーションＢとアプリケーションＤとは、通信制御部１１１、ネットワーク１４０および１４１、通信制御部１３１を介してアプリケーション間通信を行う。
【００４３】
また、上述したアプリケーション間通信とは別に、通信制御部１１１と通信制御部１２１とは、ネットワーク１４０および１４１を介して通信を行って通信先のノードまたはネットワークに異常がないか否かを監視する。以下、この通信による監視を「クライアント／サーバノード間異常監視」という。また、この通信を「異常監視通信」という。
【００４４】
図２は、本実施例に係るアプリケーション間通信時のコネクション環境を説明する図である。
アプリケーション間通信を行う場合、アプリケーション間通信を行うアプリケーション間でアプリケーション間通信用セションを確立してからアプリケーション間通信が行われる。
【００４５】
例えば、アプリケーションＡが、アプリケーションＣとアプリケーション間通信を行う場合、アプリケーションＡは、アプリケーションＣとの間にアプリケーション間通信用セションを確立する。また、アプリケーションＡが、アプリケーションＤとアプリケーション間通信を行う場合、アプリケーションＡは、アプリケーションＤとの間にアプリケーション間通信用セションを確立する。
【００４６】
同様に、アプリケーションＢが、アプリケーションＣとアプリケーション間通信を行う場合、アプリケーションＢは、アプリケーションＣとの間にアプリケーション間通信用セションを確立する。また、アプリケーションＢが、アプリケーションＤとアプリケーション間通信を行う場合、アプリケーションＢは、アプリケーションＤとの間にアプリケーション間通信用セションを確立する。
【００４７】
異常監視通信を行う場合、異常監視通信を行う通信制御部間で異常監視用セションを確立してから異常監視通信が行われる。この異常監視用セションの確立は、最初にアプリケーション間通信用セションを確立する前に行われる。すなわち、異常監視用セションは、アプリケーション間通信を行うアプリケーションが動作するＯＳ上で動作する通信制御部間にそれぞれ１つだけ確立する。
【００４８】
例えば、アプリケーションＡーアプリケーションＣ間またはアプリケーションＢーアプ
リケーションＣ間でアプリケーション間通信用セションを確立する前に、クライアントノード１１０の通信制御部１１１とサーバノード１２０の通信制御部１２１との間で異常監視用セションが１つ確立される。
【００４９】
同様に、アプリケーションＡーアプリケーションＤ間またはアプリケーションＢーアプリケーションＤ間でアプリケーション間通信用セションを確立する前に、クライアントノード１１０の通信制御部１１１とサーバノード１３０の通信制御部１３１との間で異常監視用セションが１つ確立される。
【００５０】
なお、図２では、クライアントノード１１１、サーバノード１２０および１３０に、それぞれ１つのＯＳが動作する場合を示している。通信制御部１１１、１２１および１３１は、所定のプログラムをＯＳ上で動作させることにより実現されるので、図２では、クライアントノード１１１−サーバノード１２０間、クライアントノード１１１−サーバノード１３１間にそれぞれ１つずつ異常監視用セションが確立されている場合を示している。しかし、図２に示す構成に限定する趣旨ではない。
【００５１】
例えば、サーバノード１２０上に複数のＯＳを動作させる場合、クライアントノード１１１の通信制御部１１１とサーバノード１２０の各ＯＳ上で動作する通信制御部との間に異常監視用セションが確立される。
【００５２】
図３は、本実施例に係る通信パケットの流れを説明する図である。図３は、クライアントノード１１１のアプリケーションＡが送信する通信パケットの流れを説明する図である。
【００５３】
図３では、サーバノードを３重化、すなわち、アクティブ状態のサーバノード１とスタンバイ状態のサーバノード２およびサーバノード３とでクラスタリングした場合を示している。スタンバイ１やスタンバイ２の数字は、アクティブに切替える優先順位を示している。
【００５４】
アプリケーションＡは、アプリケーション間通信用セションにおいて、マルチキャストＩＰアドレスを指定して通信パケットを送信する。図１などに示したアプリケーションＢも同様である。
【００５５】
したがって、例えば、サーバノード１２０、１３０および１４０に同一のマルチキャストＩＰアドレスが設定されている場合、図３に示すように、アプリケーションＡから送信された通信パケットは、アプリケーションＣ、ＤおよびＥが受信する。
【００５６】
同様に、通信制御部１１１は、異常監視用セションにおいて、マルチキャストＩＰアドレスを指定して通信パケットを送信する。
したがって、例えば、サーバノード１２０、１３０および１４０に同一のマルチキャストＩＰアドレスが設定されている場合、図３に示すように、通信制御部１１１から送信された通信パケットは、通信制御部１２１、１３１および１４１が受信する。
【００５７】
なお、本実施例では、図１に示したように互いに独立した２つのネットワーク１４０および１４１に同一の通信パケットを送信する。したがって、アプリケーションＣ、ＤおよびＥや通信制御部１２１、１３１および１４１は、最初に受信した通信パケットについてのみ処理を行い、以後同一の通信パケットを受信した場合には何も処理をしない、または、受信した通信パケットを破棄する。
【００５８】
以下、異常監視用セションにおける通信パケットを「監視パケット」といい、クライア
ントノードからサーバノードに送信される監視パケットを「監視要求パケット」、監視要求パケットに対してサーバノードからクライアントノードに送信される監視パケットを「監視応答パケット」という。
【００５９】
以上のように、アプリケーション間通信用セションの通信先は、アクティブ状態のサーバノード１２０のアプリケーションＣに仮想化されているが、アプリケーション間通信用セションの通信先の実体は、サーバノード１２０、１３０および１４０のアプリケーションＣ、ＤおよびＥとなる。
【００６０】
同様に、異常監視用セションの通信先は、アクティブ状態のサーバノード１２０の通信制御部１２１に仮想化されているが、異常監視用セションの通信先の実体は、通信制御部１２１、１３１および１４１となる。
【００６１】
ここで、図３に示す構成は、例えば、多重化するサーバノードの数、各サーバノード上で動作するＯＳやアプリケーションの数を限定する趣旨ではない。
【００６２】
図４は、本実施例に係る異常監視用セションでの通信パケットの流れを説明する図である。
図４は、クライアントノードにおける通信制御部がサーバノードに対して送信する異常監視用セッションにおける通信パケットの流れを示している。
クライアントノード１１０の通信制御部１１１は、マルチキャストＩＰアドレスを指定して監視要求パケットを送信する。サーバノードが図３に示したクラスタリングを構成し、かつ、同一のマルチキャストＩＰアドレスが設定されている場合、サーバノード１２０、１３０および１４０に監視要求パケットが送信される。
【００６３】
サーバノード１２０、１３０および１４０の通信制御部１２１、１３１および１４１は、通信制御部１１１から送信された監視要求パケットを受信すると、Ｉ／Ｏ割込みに連動して動作し、通信制御部１１１に対して監視応答パケットを送信する。
【００６４】
上述した監視パケットの送受信処理は、例えば、ＴＣＰプロトコルを用いた場合に行われる再送処理の間隔よりも短い数十から数百ｍＳ程度の間隔で行われる。
【００６５】
図５は、本実施例に係るアプリケーション間通信用セションと異常監視用セションの関係を説明する図である。
クライアントノード１１０上で動作するアプリケーションＡは、例えば、サーバノード１２０上で動作するアプリケーションＣとのアプリケーション間通信用セションの確立を要求するために、通信制御部１１１にアプリケーション間通信用セションの確立を要求する通信パケット１の送信を指示する。
【００６６】
以下、場合に応じて、アプリケーション間通信用セションの確立の要求を「アプリパス確立要求」といい、アプリケーション間通信用セションの確立を要求するための通信パケットを「アプリパス確立要求パケット」という。
【００６７】
すると、通信制御部１１１は、アプリケーションＡからのアプリパス確立要求１を一時保留する。すなわち、通信制御部１１１は、アプリケーション間通信用セションの確立を一時保留する。
【００６８】
そして、通信制御部１１１は、監視要求パケットにマルチキャストＩＰアドレスを指定して一斉送信し、サーバノード１２０、１３０および１４０上で動作する通信制御部１２１、１３１および１４１に対して異常監視用セションの確立を要求する。
【００６９】
通信制御部１１１から監視要求パケットを受信すると、サーバノード１２０、１３０および１４０上で動作する通信制御部１２１、１３１および１４１は、それぞれ通信制御部１１１と異常監視用セションを確立するために所定の処理を行う。そして、異常監視用セションを確立するための所定の処理を完了すると、通信制御部１２１、１３１および１４１は、それぞれ監視応答パケットを通信制御部１１１に送信する。
【００７０】
以上の処理により、通信制御部１１１−通信制御部１２１間と、通信制御部１１１−通信制御部１３１間と、通信制御部１１１−通信制御部１４１間と、に異常監視用セションが確立すると、通信制御部１１１は、アプリケーションＡから送られたアプリパス確立要求パケット１のサーバノードへの送信の保留を解除し、アプリパス確立要求パケット１にマルチキャストＩＰアドレスを指定して一斉送信する。
【００７１】
通信制御部１１１からアプリパス確立要求パケット１を受信すると、サーバノード１２０、１３０および１４０上で動作するアプリケーションＣ、ＤおよびＥは、アプリケーションＡとアプリケーション間通信用セションを確立するための所定の処理を行う。
【００７２】
そして、アプリケーション間通信用セションを確立するための所定の処理が完了すると、アプリケーションＣ、ＤおよびＥは、それぞれアプリパス確立要求パケット１に応じてアプリケーション間通信用セションが確立した旨を応答するための通信パケットをアプリケーションＡに対して送信する。
【００７３】
以下、場合に応じて、アプリケーション間通信用セションが確立した旨を応答する通信パケットを「アプリパス確立応答パケット」という。
通信制御部１１１は、アプリケーションＣ、ＤおよびＥから送信されたアプリパス確立応答パケット１を受信すると、受信したアプリパス確立応答パケット１をアプリケーションＡに通知する。
【００７４】
以上の処理により、アプリケーションＡ−アプリケーションＣ間と、アプリケーションＡ−アプリケーションＤ間と、アプリケーションＡ−アプリケーションＥ間と、にアプリケーション間通信用セションが確立される。
【００７５】
なお、既に、通信制御部１１１−通信制御部１２１間と、通信制御部１１１−通信制御部１３１間と、通信制御部１１１−通信制御部１４１間と、に異常監視用セションが確立されている場合、通信制御部１１１は、異常監視用セションの確立処理は行わない。
【００７６】
したがって、アプリケーションＢからアプリパス確立要求パケット２を受信した場合、通信制御部１１１は、アプリパス確立要求パケット２の送信を一時保留することなく、アプリパス確立要求パケット２にマルチキャストＩＰアドレスを指定して一斉送信する。そして、アプリケーションＢ−アプリケーションＣ間と、アプリケーションＢ−プリケーションＤ間と、アプリケーションＢ−アプリケーションＥ間と、にアプリケーション間通信用セションを確立する。
【００７７】
図６は、本実施例に係る異常監視用セションで使用する監視パケットの構成例を示す図である。
本実施例に係る異常監視用セションにおける通信は、ＵＤＰプロトコルにしたがって行われる。監視パケットは、ＵＤＰパケットのデータ部に監視パケット用ヘッダを設定することにより生成する。ＵＤＰパケットは公知の技術であるので、以下、監視パケット用ヘッダについてのみ説明する。
【００７８】
本実施例に係る監視パケット用ヘッダは、シーケンス番号（順序番号）と、モードと、ノード番号と、ステータス１と、ステータス２と、ノード１・ステータスと、ノード２・ステータスと、ノード３・ステータスと、を備える。
【００７９】
シーケンス番号は、クライアントノード１１０の通信制御部１１１が、監視要求パケットを送信する毎に、前回送信した監視要求パケットのシーケンス番号を１だけインクリメントしたシーケンシャルな番号である。また、監視要求パケットを受信したサーバノードの通信制御部は、監視応答パケット送信時に、受信した監視要求パケットのシーケンス番号を設定する。
【００８０】
モードは、通信パスの種別である。通信パスとは、例えば、アプリケーション間通信用セションにより確立された通信パス、異常監視用セションにより確立された通信パスである。監視パケット送信時に、通信制御部１１１、１２１、１３１または１４１が設定する。例えば、「０」は、アプリケーション通信パスを示し、「１」は、異常監視パスを示す。
【００８１】
以下、アプリケーション間通信用セションにより確立された通信パスを「アプリケーション通信パス」といい、異常監視用セションにより確立された通信パスを「異常監視パス」という。
【００８２】
ノード番号、ステータス１、ステータス２、ノード１・ステータス、ノード２・ステータス、ノード３・ステータスは、モードが異常監視パスの場合に有効な設定である。
ノード番号は、監視要求パケットを受信したサーバノードのノード番号を示す。監視要求パケットを受信したサーバノードの通信制御部が、監視応答パケット送信時にノード番号を設定する。
【００８３】
例えば、同一のマルチキャストＩＰアドレスを指定した通信パケットを受信するサーバノードが３台ある場合、「１」がサーバノード１、「２」がサーバノード２、「３」がサーバノード３を示す。
【００８４】
ステータス１は、監視要求パケットを受信したサーバノードの状態を示す。監視応答パケット送信時に設定される情報である。例えば、「１」は自ノードがアクティブ・ノードであることを示す。また、「２」以降の整数値は自ノードがスタンバイであることを示す。この整数値は、アクティブ・ノードへ切替える優先順位を示す。
【００８５】
ステータス２は、監視要求パケットを受信したサーバノードの状態の変更の有無を示す。監視応答パケット送信時に設定される情報である。
例えば、「０」は自ノードのステータスに変更がないことを示す。また、「１」は自ノードの状態をスタンバイからアクティブに変更中であることを示す。「２」は自ノードの状態がスタンバイからアクティブに変更を完了したことを示す。
【００８６】
ノード１・ステータスは、サーバノード１との通信状態を示す。例えば、「１」はサーバノード１との通信は正常であることを示す。また、「２」はサーバノード１との通信に異常を検出したことを示す。ノード２・ステータス、ノード３・ステータスも同様である。
【００８７】
以下では、必要に応じて、ノード１・ステータス、ノード２・ステータスおよびノード３・ステータスを総じて「ノード・ステータス」という。
なお、図６には、同一マルチキャストＩＰアドレスを指定した通信パケットを受信するサーバノードが３台の場合を示したが、これに限定する趣旨でない。同一マルチキャスト
ＩＰアドレスを指定した通信パケットを受信するサーバノード数に応じて、ステータス１に設定する値、ノード・ステータスの数などは適宜変更すればよい。
【００８８】
図７は、本実施例に係るクライアントノード１１０の通信制御部１１１で使用する制御テーブルの構成例を示す図である。以下、クライアントノード１１０の通信制御部１１１で使用する制御テーブルを「クライアント用制御テーブル」という。
【００８９】
図７に示すクライアント用制御テーブルは、マルチキャストＩＰアドレスと、ポート番号と、送信シーケンス番号と、受信者リストと、を備える。
マルチキャストＩＰアドレスは、監視要求パケットを一斉送信する送信先のサーバノードに共通に設定されるマルチキャストＩＰアドレスである。ポート番号は、送信先のサーバノードの通信ポートの番号である。また、送信シーケンス番号は、監視要求パケットを送信する毎に１だけインクリメントされるシーケンス番号である。
【００９０】
マルチキャストＩＰアドレス、ポート番号、送信シーケンス番号は、通信制御部１１１が、監視要求パケット送信時に監視パケット用ヘッダに設定する。
受信者リストは、マルチキャストＩＰアドレスを設定して送信した監視要求パケットに対して監視要求パケットを送信してきたサーバノードに関する情報のリストである。図７は、図３で示した構成の場合を示しているので、ノード番号１のサーバノード１２０、ノード番号２のサーバノード１３０およびノード番号３のサーバノード１４０が受信者リストに登録されている。
【００９１】
ここで、受信者リストは、監視応答パケットを送信したサーバノードのノード番号と、監視応答パケットを送信したサーバノードのＩＰアドレスと、監視応答パケットの監視パケット用ヘッダに設定されたステータス１、ステータス２およびノード・ステータスと、監視応答パケットの未受信回数と、を備える。
【００９２】
図８は、本実施例に係るサーバノード１２０、１３０および１４０の通信制御部１２１、１３１および１４１で使用する制御テーブルの構成例を示す図である。以下、サーバノードの通信制御部で使用する制御テーブルを「サーバ用制御テーブル」という。
【００９３】
図８に示すサーバ用制御テーブルは、送信元ＩＰアドレスと、送信元ポート番号と、マルチキャストＩＰアドレスと、ポート番号と、受信シーケンス番号と、要求未受信回数と、ノード番号と、ステータス１およびステータス２と、他ノードのノード・ステータスと、を備える。
【００９４】
送信元ＩＰアドレスは、受信した監視要求パケットの送信元のＩＰアドレスである。送信元ポート番号は、受信した監視要求パケットの送信元の通信ポートの番号である。
マルチキャストＩＰアドレスは、自ノードに割り当てられたマルチキャストＩＰアドレスである。ポート番号は、自ノードの通信ポートの番号である。受信シーケンス番号は、受信した監視要求パケットの監視パケット用ヘッダに設定されたシーケンス番号である。要求未受信回数は、監視要求パケットの未受信回数である。ノード番号は、自ノードのノード番号である。
【００９５】
また、ステータス１およびステータス２は、受信した監視要求パケットに設定されたステータス１およびステータス２である。他ノードのノード・ステータスは、図２２に示すサーバノード間異常監視によって検出する他のサーバノードの通信異常を示す。
【００９６】
図９は、本実施例に係るサーバノード１１０またはクライアントノード１２０、１３０および１４０を実現する主要な構成を説明するブロック図である。本実施例に係るクライ
アントノード１１０とサーバノード１２０、１３０および１４０は同様の構成なので、図９には、クライアントノード１１０について示している。
【００９７】
図１で説明したように、本実施例に係るクライアントノード１１０は、アプリケーション間通信を行うアプリケーションＡおよびＢと、本実施例に係るアプリケーション間通信の実現に必要な通信制御を行う通信制御部１１１と、アプリケーションＡ、Ｂおよび通信制御部１１１を動作させるＯＳと、を備える。
【００９８】
なお、アプリケーションＡ、Ｂ、通信制御部１１１およびＯＳは、クライアントノード１１０に備わるＣＰＵが、必要に応じてメモリ等を使用して、所定のプログラムの命令を実行することで実現される。
【００９９】
アプリケーションＡおよびＢは、ＯＳ上で動作するソフトウェアである。ただし、各アプリケーションは、それぞれ通信制御部１１１が提供するＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ  Ｐｒｏｇｒａｍ  Ｉｎｔｅｒｆａｃｅ）を利用してアプリケーション間通信を行う。
【０１００】
例えば、各アプリケーションが出力する通信パケットは、通信制御部１１１を介してＯＳに渡される。すると、ＯＳは、クライアントノード１１０に備わるネットワークＩ／Ｆを介してネットワークに通信パケットを送信する。
【０１０１】
なお、図９では、ＯＳ上に２つのアプリケーションＡおよびＢを動作させる場合を示しているが、これに限定する趣旨ではない。例えば、アプリケーションを１つだけが動作させてもよいし、３以上のアプリケーションを動作させてもよい。ただし、３以上のアプリケーションを動作させる場合であっても、全てのアプリケーションは通信制御部１１１が提供するＡＰＩを利用して通信を行う。
【０１０２】
通信制御部１１１は、ＯＳ上で動作するソフトウェアである。そして、通信制御部１１１は、通信制御部１１１が動作するＯＳ上で動作するアプリケーション間通信用のアプリケーションにＡＰＩを提供する。
【０１０３】
通信制御部１１１は、アプリケーションＡまたはＢからの要求に応じてアプリケーション間通信用のセション処理を行うアプリケーション間通信用セション処理部７１０と、異常監視用のセション処理を行う異常監視用セション処理部７２０と、通信パケットの送受信処理を行う共通制御部７３０と、を備える。
【０１０４】
アプリケーション間通信用セション処理部７１０は、通信環境を作成・設定する処理部へのインターフェースである環境作成・設定ＡＰＩ７１１と、通信環境を作成・設定する処理部である環境作成・設定処理部７１２と、通信パケットを送信する処理部へのインターフェースであるパケット送信ＡＰＩ７１３と、通信パケットを受信する処理部とのインターフェースであるパケット受信ＡＰＩ７１４と、を備える。
【０１０５】
環境作成・設定処理部７１２は、環境作成・設定ＡＰＩ７１１を介してアプリケーションＡまたはＢからアプリケーション間通信用セションの確立を要求されると、アプリケーション間通信に使用するソケットを構築し、構築したソケットに対する必要なリソースの割り当て、ポート番号やＩＰアドレスの割り当てなどを行って通信環境の作成・設定を行う。
【０１０６】
また、環境作成・設定処理部７１２は、アプリケーション間通信用セションの確立の要求があったことを異常監視セション処理部７２０に通知する。同時に、環境作成・設定処理部７１２は、アプリケーション間通信に使用する例えば図７や図８に示す制御テーブル
を制御テーブル記億部７３１に生成する。
【０１０７】
異常監視セション処理部７２０は、パケット送信処理部７３２およびパケット受信処理部７３３を使用して、異常監視用セションの確立先と監視パケットを含む通信パケットの送受信処理を行う。
【０１０８】
環境作成・設定処理部７１２からアプリケーション間通信用セション確立の要求があったことの通知を受けると、異常監視用セション処理部７２０は、アプリケーション間通信用セションの確立処理を一時保留する。
【０１０９】
そして、異常監視セション処理部７２０は、アプリケーション間通信用セションの確立先のアプリケーションが動作するＯＳ上で動作する通信制御部と、パケット送信処理部７３２およびパケット受信処理部７３３を使用して通信し、アプリケーション間通信用セションの確立先のアプリケーションが動作するＯＳ上で動作する通信制御部と異常監視用セションを確立する処理を行う。
【０１１０】
異常監視用セションが確立すると、異常監視セション処理部７２０は、アプリケーションＡまたはＢが要求したアプリケーション間通信用セションの確立先のアプリケーションと、パケット送信処理部７３２およびパケット受信処理部７３３を使用して通信し、アプリケーション間通信用セションを確立する。
【０１１１】
共通制御部７３０は、図７または図８に示した制御テーブルを記憶する制御テーブル記億部７３１と、通信パケットの送信処理を行うパケット送信処理部７３２と、通信パケットの受信処理を行うパケット受信処理部７３３と、を備える。
【０１１２】
パケット送信処理部７３２は、パケット送信ＡＰＩ７１３を介して行われるアプリケーションＡまたはＢからの要求、または、異常監視セション処理部７２０からの要求、にしたがって、通信パケットをサーバノードに送信する処理を行う。
【０１１３】
パケット受信処理部７３３は、ＮＩＣ等のネットワークＩ／Ｆ、ＯＳを介して通信パケットを受信すると、アプリケーション間通信用セションか異常監視セションかに応じてアプリケーションＡ、Ｂまたは異常監視セション処理部７２０に受信した通信パケットを通知する。
【０１１４】
本実施例に係るサーバノード１２０、１３０および１４０は、上記構成に加えて、クラスタを構成するサーバノード１２０、１３０および１４０を管理する高信頼動作処理部７４０を備える。
【０１１５】
クラスタを構成するサーバノード間では、サーバノード間異常監視が行われる。サーバノード間異常監視により検出した異常は、高信頼動作処理部７４０に通知される。通知を受けた高信頼動作処理部７４０は、クラスタを構成する他のサーバノードに対して、その異常を通知する。
【０１１６】
図１０は、本実施例に係るクライアントノード１１０がサーバノード１２０の異常を検出するまでの処理の概要を説明する図である。
説明を簡単にするために、時刻Ａにクライアントノード１１０の通信制御部１１１とサーバノード１２０の通信制御部１２１とが異常監視セションを確立し、その後、時間Ｘの間隔で通信制御部１１１−通信制御部１２１間で監視パケットの送受信処理を行う場合を示している。図９および図１０も同様である。
【０１１７】
時刻Ａに通信制御部１１１が送信した監視要求パケットに対する監視応答パケットの送信が完了した後に、サーバノード１２０がダウンすると、その後に通信制御部１１１が送信する監視要求パケットに対するサーバノード１２０からの監視応答パケットを通信制御部１１１は受信しないことになる。
【０１１８】
なお、監視要求パケットに対する監視応答パケットを、次の監視要求パケットを送信するまでに受信しない場合に、その監視応答パケットを受信しないと判断する。
本実施例では、３回監視応答パケットを受信しない場合、監視応答パケットを受信しないサーバノード１２０に異常が発生したと判断する。図１０の場合、時刻Ａ＋４Ｘの時点で、通信制御部１１１は、サーバノード１２０に異常が発生したと判断する。
【０１１９】
図１１は、本実施例に係るシステム１００が恒久障害を検出するまでの処理を説明する図である。
時刻Ａに通信制御部１１１が送信した監視要求パケットに対する監視応答パケットの送信が完了した後に、クライアントノード１１０とサーバノード１２０、１３０および１４０との間の全ての系のネットワークに障害が発生すると、その後に通信制御部１１１が送信する監視要求パケットは、サーバノード１２０、１３０および１４０に届かない。
【０１２０】
したがって、ネットワークに障害が発生した後に通信制御部１１１が送信する監視要求パケットに対するサーバノード１２０、１３０および１４０からの監視応答パケットを通信制御部１１１は受信しないことになる。
【０１２１】
本実施例では、３回連続して全サーバノードから監視応答パケットを受信しない場合、通信制御部１１１は、ネットワークに障害が発生したと判断する。以下、この障害を「恒久障害」という。図１１の場合、時刻Ａ＋４Ｘの時点で、通信制御部１１１は、恒久障害が発生したと判断する。
【０１２２】
図１２は、本実施例に係るシステム１００においてサーバノード１２０がクライアントノード１１０との通信異常を検出するまでの処理を説明する図である。
時刻Ａに通信制御部１１１が送信した監視要求パケットに対する監視応答パケットの送信が完了した後に、クライアントノード１１０−サーバノード１２０のネットワークに異常が発生すると、その後に通信制御部１１１が送信する監視要求パケットは、サーバノード１２０に届かないことになる。
【０１２３】
サーバノード１２０では、異常監視セションが確立した時刻Ａから時間Ｘが経過するまでに、通信制御部１１１からの監視要求パケットを受信しない場合に、監視要求パケットが未受信と判断する。
【０１２４】
本実施例では、３回監視要求パケットを受信しない場合、クライアントノード１１０−サーバノード１２０間のネットワークに異常が発生したと判断する。図１２の場合、時刻Ａ＋４Ｘの時点で、サーバノード１２０は、クライアントノード１１０−サーバノード１２０間のネットワークに異常が発生したと判断する。
【０１２５】
図１３は、本実施例に係るクライアントノード１１０における通信制御部１１１の環境作成・設定処理部７１２の処理を示すフローチャートである。
ステップＳ１３０１において、アプリケーションからアプリケーション間通信用セションの確立の要求を受けると、環境作成・設定処理部７１２は、要求されたアプリケーション間通信用セションが既に確立されているか否かを判別する。
【０１２６】
要求されたアプリケーション間通信用セションが未だ確立されていない場合、環境作成
・設定処理部７１２は、処理をステップＳ１３０２に移行する（ステップＳ１３０１  ＮＯ）。
【０１２７】
ステップＳ１３０２において、環境作成・設定処理部７１２は、要求されたアプリケーション間通信用セションの確立処理を一時保留する。
ステップＳ１３０３において、環境作成・設定処理部７１２は、アプリケーションがアプリケーション間通信用セションの確立を要求しているアプリケーションが動作するＯＳ上で動作している通信制御部と異常監視セションを確立するように異常監視セション処理部７２０に要求する。
【０１２８】
ステップＳ１３０４において、環境作成・設定処理部７１２は、ステップＳ１３０３の処理が正常に終了して異常監視用セションが確立されたか否かを判別する。異常監視用セションの確立に失敗した場合、環境作成・設定処理部７１２は、処理をステップＳ１３０９に移行する（ステップＳ１３０４  ＮＯ）。また、異常監視用セションの確立に成功した場合、環境作成・設定処理部７１２は、処理をステップＳ１３０５に移行する（ステップＳ１３０４  ＹＥＳ）。
【０１２９】
ステップＳ１３０５において、環境作成・設定処理部７１２は、ステップＳ１３０２の処理で一時保留したアプリケーション間通信用セションの確立処理を行う。そして、アプリケーション間通信用セションの確立が完了すると、環境作成・設定処理部７１２は、ステップＳ１３０８に移行し処理を終了する。
【０１３０】
一方、ステップＳ１３０１において、要求されたアプリケーション間通信用セションが既に確立されている場合、環境作成・設定処理部７１２は、処理をステップＳ１３０６に移行する（ステップＳ１３０１  ＹＥＳ）。
【０１３１】
ステップＳ１３０６において、環境作成・設定処理部７１２は、アプリケーション間通信用セションの確立先との通信状態が正常か否かを判別する。例えば、環境作成・設定処理部７１２は、制御テーブル記憶部７３１に記憶されているクライアント用制御テーブルを参照する。そして、クライアント用制御テーブルの受信者リストに登録されているアプリケーション間通信用セションの確立先のノード・ステータスに設定されている値を取得する。
【０１３２】
取得した値が「１」である場合、環境作成・設定処理部７１２は、通信状態が正常であると判断する。また、取得した値が「２」である場合、環境作成・設定処理部７１２は、通信状態が異常であると判断する。
【０１３３】
ステップＳ１３０６において、通信状態が正常と判断すると、環境作成・設定処理部７１２は、処理をステップＳ１３０７に移行する（ステップＳ１３０６  ＹＥＳ）。そして、ステップＳ１３０７において、環境作成・設定処理部７１２は、アプリケーション間通信用セションの確立先のアプリケーションとアプリケーション間通信用セションを確立する。
【０１３４】
ステップＳ１３０６において、通信状態が異常であると判断すると、環境作成・設定処理部７１２は、処理をステップＳ１３０９に移行する（ステップＳ１３０６  ＮＯ）。そして、ステップＳ１３０９において、環境作成・設定処理部７１２は、恒久障害を検出した旨をアプリケーションに通知して処理を終了する。
【０１３５】
図１４は、本実施例に係るクライアントノード１１０における通信制御部１１１のパケット送信処理を示すフローチャートである。
ステップＳ１４０１において、アプリケーションから通信パケットの送信依頼を受けると、パケット送信ＡＰＩ７１３は、制御テーブル記憶部７３１に記憶されているクライアント用制御テーブルを参照し、クライアント用制御テーブルの受信者リストに登録されているパケット送信先のＩＰアドレスのノードのノード・ステータスに設定されている値を取得する。
【０１３６】
取得した値が「１」である場合、パケット送信ＡＰＩ７１３は、通信状態が正常であると判断する。また、取得した値が「２」である場合、パケット送信ＡＰＩ７１３は、通信状態が異常であると判断する。
【０１３７】
ステップＳ１４０１において、通信状態が異常と判断した場合、パケット送信ＡＰＩ７１３は、処理をステップＳ１４０２に移行する（ステップＳ１４０１  ＹＥＳ）。
ステップＳ１４０２において、パケット送信ＡＰＩ７１３は、パケット送信先のノードがアクティブ状態への変更の処理中であるか否かを判別する。この時、パケット送信ＡＰＩ７１３は、ステップＳ１４０１で参照したクライアント用制御テーブルを参照し、クライアント用制御テーブルの受信者リストに登録されているパケット送信先ＩＰのＩＰアドレスのノードのステータス２に設定されている値を取得する。
【０１３８】
取得した値が「１」である場合、パケット送信ＡＰＩ７１３は、スタンバイ状態からアクティブ状態への変更の処理中であると判断する。そして、パケット送信ＡＰＩ７１３は、処理をステップＳ１４０３に移行する（ステップＳ１４０２  ＹＥＳ）。
【０１３９】
ステップＳ１４０３において、パケット送信ＡＰＩ７１３は、パケット送信処理部７３２への通信パケットの送信依頼を一定時間保留する。そして、処理をステップＳ１４０５に移行する。そして、一定時間経過すると、パケット送信処理部７３２は、ステップＳ１４０１から処理を開始する。
【０１４０】
また、ステップＳ１４０２において、取得した値が「１」以外である場合、パケット送信ＡＰＩ７１３は、スタンバイ状態からアクティブ状態への状態の変更処理中でないと判断する。そして、パケット送信ＡＰＩ７１３は、処理をステップＳ１４０４に移行する（ステップＳ１４０２  ＮＯ）。
【０１４１】
ステップＳ１４０４において、パケット送信ＡＰＩ７１３は、パケット送信処理部７３２にアプリケーションから依頼のあった通信パケットの送信を依頼する。そして、パケット送信処理部７３２は、ステップ１４０５に移行し処理を終了する。
【０１４２】
一方、ステップＳ１４０１において、通信状態が異常と判断した場合、パケット送信ＡＰＩ７１３は、処理をステップＳ１４０６に移行する（ステップＳ１４０１  ＮＯ）。
ステップＳ１４０６において、パケット送信処理部７３２は、恒久障害と判断し、パケット送信先と既に確立しているアプリケーション間通信用セションを解放する。そして、パケット送信処理部７３２は、恒久障害を検出した旨をアプリケーションに通知して処理を終了する。
【０１４３】
図１５は、本実施例に係るクライアントノード１１０の異常監視セション処理部７２０による監視パケットの送受信処理の概要を示すフローチャートである。
例えば、図１３で示したステップＳ１３０３において、環境作成・設定処理部７１２から異常監視セションの確立の要求を受けるなどすると、監視セション処理部７２０は、異常監視セションの確立処理を開始する。
【０１４４】
ステップＳ１５０１において、異常監視セション処理部７２０は、環境作成・設定処理
部７１２からの要求が異常監視セションの確立の要求であるか否かを判別する。そして、異常監視セションの確立の要求である場合、異常監視セション処理部７２０は、処理をステップＳ１５０２に移行する（ステップＳ１５０１  ＹＥＳ）。
【０１４５】
ステップＳ１５０２において、異常監視セション処理部７２０は、異常監視セションの確立処理を行う。異常監視セションの確立が完了すると、異常監視セション処理部７２０は、ステップＳ１５０７に移行し異常監視セションの確立処理を終了する。
【０１４６】
一方、ステップＳ１５０１において、異常監視セションの確立の要求でない場合、異常監視セション処理部７２０は、処理をステップＳ１５０３に移行する（ステップＳ１５０１  ＮＯ）。
【０１４７】
ステップＳ１５０３において、監視セション処理部７２０は、あらかじめ設定された監視応答受信時間を経過したか否かを判断する。監視応答受信時間とは、図１０に例示したように、監視要求パケットを送信してからその監視要求パケットに対する監視応答パケットの受信を待つ時間（図１０ではＸ時間）のことをいう。
【０１４８】
監視応答受信時間を経過したと判断すると、異常監視セション処理部７２０は、処理をステップＳ１５０４に移行する（ステップＳ１５０３  ＹＥＳ）。
ステップＳ１５０４において、異常監視セション処理部７２０は、一定期間経過後に異常監視セションの確立処理を再度実施するために、異常監視セション処理部７２０自身についてタイマ処理を行う。以下、このタイマ処理を「異常監視セションタイマ処理」という。タイマ処理が完了すると、異常監視セション処理部７２０は、ステップＳ１５０７に移行して異常監視セションの確立処理を終了する。
【０１４９】
一方、ステップＳ１５０３において、監視応答受信時間を経過していないと判断すると、異常監視セション処理部７２０は、処理をステップＳ１５０５に移行する（ステップＳ１５０３  ＮＯ）。
【０１５０】
ステップＳ１５０５において、異常監視セション処理部７２０は、監視応答パケットを受信したか否かを判別する。監視応答パケットを受信した場合、異常監視セション処理部７２０は、処理をステップＳ１５０６に移行する（ステップＳ１５０５  ＹＥＳ）。
【０１５１】
ステップＳ１５０６において、異常監視セション処理部７２０は、監視応答パケットの受信処理を行う。そして、監視応答パケットの受信処理が完了すると、異常監視セション処理部７２０は、ステップＳ１５０７に移行して異常監視セションの確立処理を終了する。
【０１５２】
一方、監視応答パケットを受信しない場合、異常監視セション処理部７２０は、ステップＳ１５０７に移行して異常監視セションの確立処理を終了する（ステップＳ１５０５  ＮＯ）。
【０１５３】
図１６は、本実施例に係るクライアントノード１１０における異常監視セション処理部７２０の異常監視セション確立処理（ステップＳ１５０２）のフローチャートである。
ステップＳ１６０１において、異常監視セション処理部７２０は、制御テーブル記憶部７３１に図７で示したクライアント用制御テーブルを作成する。
【０１５４】
例えば、アプリケーションから依頼されたアプリケーション間通信用セションの確立先のサーバノードを含む複数のサーバノードに割り当てられたマルチキャストＩＰアドレスと、アプリケーションから依頼されたアプリケーション間通信用セションの確立先のサー
バノードを含む複数のサーバノードに共通に割り当てられた通信ポートと、をクライアント用制御テーブルに設定する。
【０１５５】
また、初期状態では監視応答パケットを受信していないので、受信シーケンス番号を０に設定する。受信者リストには、監視応答パケットを受信する毎に、受信した監視応答パケットの内容を登録する。
【０１５６】
ステップＳ１６０２において、異常監視セション処理部７２０は、図６に示した監視要求パケットを作成する。
例えば、異常監視セション処理部７２０は、必要な領域を確保したデータを作成し、マルチキャストＩＰアドレスを設定するなど必要な情報を設定してＩＰヘッダおよびＵＤＰヘッダを作成する。さらに、異常監視セション処理部７２０は、監視パケット用ヘッダ部のシーケンス番号に１を設定し、モードに１を設定する。
【０１５７】
ステップＳ１６０３において、異常監視セション処理部７２０は、監視応答受信タイマを起動する。すなわち、異常監視セション処理部７２０は、監視応答受信時間経過後に次の監視応答パケットの受信処理を行うように、タイマに監視応答受信時間を設定する。
【０１５８】
ステップＳ１６０４において、異常監視セション処理部７２０は、ステップＳ１６０２で作成した監視要求パケットを送信するように、パケット送信処理部７３２に要求する。すると、パケット送信処理部７３２は、異常監視セション処理部７２０から要求のあった監視要求パケットの送信処理を行う。
【０１５９】
図１７は、本実施例に係るクライアントノード１１０における異常監視セション処理部７２０の監視応答パケットの受信処理（Ｓ１５０６）を示す図である。
ステップＳ１７０１において、異常監視セション処理部７２０は、監視応答パケットを受信すると、監視応答パケットのＩＰヘッダ部を参照し送信元のＩＰアドレスを取得する。そして、異常監視セション処理部７２０は、制御テーブル記憶部７３１に記憶されているクライアント用制御テーブルの受信者リストを参照し、取得したＩＰアドレスと一致するノードがある場合には、そのノードの応答未受信回数を０に設定する。
【０１６０】
なお、取得したＩＰアドレスのノードが受信者リストに登録されていない場合、異常監視セション処理部７２０は、受信した監視応答パケットにしたがって新たなノードを受信者リストに登録する。
【０１６１】
ステップＳ１７０２において、異常監視セション処理部７２０は、受信した監視応答パケットから図６に示したステータス２の値を取得する。そして、異常監視セション処理部７２０は、クライアント用制御テーブルの受信者リストを参照し、ステップＳ１７０１で取得したＩＰアドレスと一致するノードのステータス２の情報を、監視応答パケットから取得したステータス２の値で更新する。
【０１６２】
図１８は、本実施例に係るクライアントノード１１０における異常監視セション処理部７２０の異常監視セションタイマ処理（Ｓ１５０４）を示す図である。
ステップＳ１８０１において、異常監視セション処理部７２０は、制御テーブル記憶部７３１に記憶されているクライアント用制御テーブルの受信者リストを参照する。そして、監視応答受信時間を経過しても監視応答パケットを受信しないノードの応答未受信回数を１だけインクリメントする。
【０１６３】
ステップＳ１８０２において、異常監視セション処理部７２０は、ステップＳ１８０１で算出した応答未受信回数と、あらかじめ決められた異常検知回数と、を比較する。そし
て、応答未受信回数が異常検知回数以上の場合、異常監視セション処理部７２０は、処理をステップＳ１８０３に移行する（ステップＳ１８０２  ＹＥＳ）。なお、既に、図１０などでは異常検知回数が３回の場合について説明した。
【０１６４】
ステップＳ１８０３において、異常監視セション処理部７２０は、ステップＳ１８０２で応答未受信回数が異常検知回数以上と判断されたノードのノード・ステータスに通信異常を設定する。本実施例では、ステータス１に通信異常を示す「２」を設定する。
【０１６５】
一方、ステップＳ１８０２において、応答未受信回数が異常検知回数より小さい場合、異常監視セション処理部７２０は、処理をステップＳ１８０４に移行する（ステップＳ１８０２  ＮＯ）。
【０１６６】
ステップＳ１８０４において、異常監視セション処理部７２０は、図６に示した監視要求パケットを作成する。例えば、異常監視セション処理部７２０は、必要な領域を確保したデータを作成し、マルチキャストＩＰアドレスを設定するなど必要な情報を設定してＩＰヘッダおよびＵＤＰを生成する。
【０１６７】
また、クライアント用制御テーブルの送信シーケンス番号を１だけインクリメントするとともに、そのインクリメントした値を監視パケット用ヘッダのシーケンス番号に設定する。また、監視パケット用ヘッダのモードに１を設定する。
【０１６８】
さらに、クライアント用制御テーブルの受信者リストに登録されている送信先ノードのノード・ステータスの値を、監視パケット用ヘッダのノード・ステータスに設定する。
ステップＳ１８０５において、異常監視セション処理部７２０は、監視応答受信タイマを起動する。すなわち、異常監視セション処理部７２０は、監視応答受信時間経過後に次の監視応答パケットの受信処理を行うように、タイマに監視応答受信時間を設定する。
【０１６９】
ステップＳ１８０６において、異常監視セション処理部７２０は、ステップＳ１８０４で作成した監視要求パケットを送信するように、パケット送信処理部７３２に要求する。すると、パケット送信処理部７３２は、異常監視セション処理部７２０から要求のあった監視要求パケットの送信処理を行う。
【０１７０】
図１９は、本実施例に係るサーバノード１２０、１３０または１４０における異常監視セション処理部７２０による監視パケットの送受信処理の概要を示すフローチャートである。
【０１７１】
ステップＳ１９０１において、パケット受信処理部７３３から通信パケットの受信の通知を受けるなどすると、異常監視セション処理部７２０は、受信した通信パケットが監視要求パケットであるか否かを判別する。
【０１７２】
例えば、異常監視セション処理部７２０は、通信パケットの監視パケット用ヘッダを参照する。そして、監視パケット用ヘッダのモードが異常監視パスに設定されている場合、異常監視セション処理部７２０は、受信した通信パケットが監視要求パケットであると判断し、処理をステップＳ１９０２に移行する（ステップＳ１９０１  ＹＥＳ）。
【０１７３】
ステップＳ１９０２において、異常監視セション処理部７２０は、監視要求パケットの受信処理を行う。監視要求パケットの受信処理が完了すると、異常監視セション処理部７２０は、ステップＳ１９０７に移行して監視パケットの送受信処理を終了する。
【０１７４】
一方、ステップＳ１９０１において、監視パケット用ヘッダのモードが異常監視パスに
設定されていない場合、異常監視セション処理部７２０は、受信した通信パケットが監視要求パケットでない判断し、処理をステップＳ１９０３に移行する（ステップＳ１９０１
ＮＯ）。
【０１７５】
ステップＳ１９０３において、異常監視セション処理部７２０は、あらかじめ設定された監視要求受信時間を経過したか否かを判断する。監視要求受信時間とは、図１２に例示したように、監視要求パケットを受信してから次の監視要求パケットの受信を待つ時間（図１２ではＸ時間）のことをいう。
【０１７６】
監視要求受信時間を経過したと判断すると、異常監視セション処理部７２０は、処理をステップＳ１９０４に移行する（ステップＳ１９０３  ＹＥＳ）。
ステップＳ１９０４において、異常監視セション処理部７２０は、監視要求パケットの未受信回数を更新する。未受信回数を更新すると、異常監視セション処理部７２０は、ステップＳ１９０７に移行して監視パケットの送受信処理を終了する。
【０１７７】
一方、ステップＳ１９０３において、監視要求受信時間を経過していないと判断すると、異常監視セション処理部７２０は、処理をステップＳ１９０５に移行する（ステップＳ１９０３  ＮＯ）。
【０１７８】
ステップＳ１９０５において、異常監視セション処理部７２０は、高信頼動作処理部７４０から状態変更通知を受信したか否かを判別する。高信頼動作処理部７４０は、後述するステップＳ２２０２、Ｓ２２０８、Ｓ２２１２の処理によりノードの状態が変更された旨を通知する。例えば、サーバノード１３０や１４０がスタンバイ状態からアクティブ状態に変更した場合、高信頼動作処理部７４０は、ノードの状態が変更された旨を異常監視セション処理部７２０に通知する。
【０１７９】
高信頼動作処理部７４０からノードの状態が変更された旨の通知を受信すると、異常監視セション処理部７２０は、処理をステップＳ１９０６に移行する（ステップＳ１９０５
ＹＥＳ）。
【０１８０】
ステップＳ１９０６において、異常監視セション処理部７２０は、制御テーブル記憶部７３１に記憶されているサーバ用制御テーブルにおける自ノードのステータス２に、スタンバイからアクティブに変更中である旨を設定する。ステータス２への設定が完了すると、異常監視セション処理部７２０は、ステップＳ１９０７に移行して関しパケットの送受信処理を終了する。
【０１８１】
一方、ステップＳ１９０５において、高信頼動作処理部７４０からノードの状態が変更された旨の通知を受信していない場合、異常監視セション処理部７２０は、処理をステップＳ１９０７に移行する（ステップＳ１９０５  ＮＯ）。そして、異常監視セション処理部７２０は、監視パケットの送受信処理を終了する。
【０１８２】
図２０は、本実施例に係るサーバノード１２０、１３０または１４０における異常監視セション処理部７２０による監視要求パケットの受信処理（Ｓ１９０２）を示すフローチャートである。
【０１８３】
ステップＳ２００１において、異常監視セション処理部７２０は、受信した監視要求パケットが新規の異常監視セションによるものか否かを判別する。例えば、異常監視セション処理部７２０は、制御テーブル記憶部７３１を参照し、受信した監視要求パケットの送信元のＩＰアドレスについてのサーバ用制御テーブルの有無を確認する。受信した監視要求パケットの送信元のＩＰアドレスについてのサーバ用制御テーブルがない場合、異常監
視セション処理部７２０は、受信した監視要求パケットが新規の異常監視セションによるものと判断し、処理をステップＳ２００２に移行する（Ｓ２００１  ＹＥＳ）。
【０１８４】
ステップＳ２００２において、異常監視セション処理部７２０は、受信した監視要求パケットのヘッダ部から必要な情報を読み出し、図８に示したサーバ用制御テーブルを生成する。
【０１８５】
一方、ステップＳ２００１において、受信した監視要求パケットの送信元のＩＰアドレスについてのサーバ用制御テーブルが存在する場合、異常監視セション処理部７２０は、受信した監視要求パケットが新規の異常監視セションによるものでないと判断し、処理をステップＳ２００３に移行する（Ｓ２００１  ＮＯ）。
【０１８６】
ステップＳ２００３において、異常監視セション処理部７２０は、他のサーバノードに状態変更があるか否かを判別する。
例えば、異常監視セション処理部７２０は、制御テーブル記憶部７３１のサーバ用制御テーブルを参照する。そして、異常監視セション処理部７２０は、サーバ用制御テーブルの他ノード状態に登録されている自ノード以外のノードのノード状態を取得する。また、異常監視セション処理部７２０は、受信した監視要求パケットの監視パケット用ヘッダから自ノード以外のノードのノード・ステータスを取得する。
【０１８７】
そして、異常監視セション処理部７２０は、サーバ用制御テーブルから取得したノード状態と監視要求パケットから取得したノード状態との比較する。そして、異常監視セション処理部７２０は、両ノード状態に差異があればノードの状態が変更されたと判断し、両ノード状態に差異がなければノードの状態は変更されていないと判断する。
【０１８８】
他ノードに状態変更があると判断した場合、異常監視セション処理部７２０は、処理をステップＳ２００４に移行する（ステップＳ２００３  ＹＥＳ）。
ステップＳ２００４において、異常監視セション処理部７２０は、状態変更のあったノードを高信頼動作処理部７４０に通知する。この場合、異常監視セション処理部７２０は、例えば、状態変更のあったノードと、そのノードがスタンバイからアクティブ状態へ変更中である旨、またはアクティブ状態である旨を通知する。
【０１８９】
高信頼動作処理部７４０への通知が完了すると、異常監視セション処理部７２０は、処理をステップＳ２００５へ移行する。
一方、ステップＳ２００３において、他ノードに状態変更がないと判断した場合、異常監視セション処理部７２０は、処理をステップＳ２００５に移行する（ステップＳ２００３  ＮＯ）。
【０１９０】
ステップＳ２００５において、異常監視セション処理部７２０は、図６に示した監視応答パケットを作成する。例えば、異常監視セション処理部７２０は、必要な領域を確保したデータを作成し、送信先のクライアントノード１１０のＩＰアドレスを設定するなど必要な情報を設定してＩＰヘッダおよびＵＤＰヘッダを生成する。また、監視パケット用ヘッダのシーケンス番号に受信した監視要求パケットのシーケンス番号を設定し、モードに１を設定する。さらに、ノード番号、ステータス１、ステータス２、ノード・ステータスにサーバ用制御テーブルの情報を反映する。
【０１９１】
ステップＳ２００６において、異常監視セション処理部７２０は、監視要求受信タイマを起動する。すなわち、異常監視セション処理部７２０は、監視要求受信時間経過後に次の監視要求パケットの受信処理を行うように、タイマに監視要求受信時間を設定する。
【０１９２】
ステップＳ２００７において、異常監視セション処理部７２０は、ステップＳ２００５で作成した監視応答パケットを送信するように、パケット送信処理部７３２に要求する。すると、パケット送信処理部７３２は、異常監視セション処理部７２０から要求のあった監視応答パケットの送信処理を行う。
【０１９３】
図２１は、本実施例に係るサーバノード１２０、１３０および１４０における異常監視セション処理部７２０による未受信回数の更新処理（ステップＳ１９０４）を示すフローチャートである。
【０１９４】
ステップＳ２１０１において、異常監視セション処理部７２０は、制御テーブル記憶部７３１に記憶されているサーバ用制御テーブルの要求未受信回数を取得する。そして、異常監視セション処理部７２０は、取得した要求未受信回数を１だけインクリメントし、そのインクリメントした値をサーバ用制御テーブルの要求未受信回数に設定する。
【０１９５】
ステップＳ２１０２において、異常監視セション処理部７２０は、ステップＳ２１０１で算出した要求未受信回数と、あらかじめ決められた異常検知回数と、を比較する。そして、要求未受信回数が異常検知回数以上の場合、異常監視セション処理部７２０は、処理をステップＳ２１０３に移行する（ステップＳ２１０２  ＹＥＳ）。なお、既に、図１２などでは異常検知回数が３回の場合について説明した。
【０１９６】
ステップＳ２１０３において、異常監視セション処理部７２０は、高信頼動作処理部７４０にクライアントノード１１０との通信異常を検出した旨を通知する。そして、高信頼動作処理部７４０への通知が完了すると、異常監視セション処理部７２０は、ステップＳ２１０４に移行して監視要求パケットの受信処理を終了する。
【０１９７】
一方、ステップＳ２１０２において、要求未受信回数が異常検知回数より小さい場合、異常監視セション処理部７２０は、ステップＳ２１０４に移行し（ステップＳ２１０２  ＮＯ）、未受信回数の更新処理を終了する。
【０１９８】
図２２は、本実施例に係るサーバノード１２０、１３０または１４０における高信頼動作処理部７４０の動作を示すフローチャートである。
ステップＳ２２０１において、サーバノード１２０、１３０または１４０からイベントを受信すると、高信頼動作処理部７４０は、イベントがスタンバイからアクティブへの切替え完了の通知か否かを判別する。
【０１９９】
イベントがスタンバイからアクティブへの切替え完了の通知である場合、高信頼動作処理部７４０は、処理をステップＳ２２０２に移行する（ステップＳ２２０１  ＹＥＳ）。
ステップＳ２２０２において、高信頼動作処理部７４０は、イベントを送信したサーバノードの通信制御部１２１、１３１または１４１に対して、スタンバイからアクティブへの切替えが完了した旨を通知する。この時、通知を受けた通信制御部１２１、１３１または１４１は、イベントを送信したサーバノードのサーバ用制御テーブルのステータス２を、アクティブへの変更が完了したことを示す「２」に設定する。
【０２００】
以下、図２２の説明では、通信制御部１２１、１３１または１４１を単に「通信制御部」という。
一方、イベントがスタンバイからアクティブへの切替え完了の通知でない場合、高信頼動作処理部７４０は、処理をステップＳ２２０３に移行する（ステップＳ２２０１  ＮＯ）。
【０２０１】
ステップＳ２２０３において、高信頼動作処理部７４０は、イベントが異常監視パスの
通信異常の通知であるか否かを判別する。
イベントが異常監視パスの通信異常の通知でない場合、高信頼動作処理部７４０は、処理をステップＳ２２０４に移行する（ステップＳ２２０３  ＹＥＳ）。
【０２０２】
ステップＳ２２０４において、高信頼動作処理部７４０は、イベントがアクティブ・ノードでの異常発生の通知であるか否かを判別する。イベントがアクティブ・ノードでの異常発生の通知でない場合、高信頼動作処理部７４０は、処理をステップＳ２２０５に移行する（ステップＳ２２０４  ＮＯ）。
【０２０３】
ステップＳ２２０５において、高信頼動作処理部７４０は、イベントを発生したノードを、システム１００の構成から切り離す。例えば、システム１００の構成を定義する構成定義ファイル等からイベントを発生したノードを削除する。ノードの切り離しが完了すると、高信頼動作処理部７４０は、ステップＳ２２１３に移行し、イベントの受付け処理を終了する。
【０２０４】
一方、ステップＳ２２０４において、イベントがアクティブ・ノードでの異常発生の通知である場合、高信頼動作処理部７４０は、処理をステップＳ２２０６に移行する（ステップＳ２２０４  ＹＥＳ）。
【０２０５】
ステップＳ２２０６において、高信頼動作処理部７４０は、通信異常が発生していないスタンバイ状態のサーバノードが存在するか否かを判別する。なお、高信頼動作処理部７４０は、通信異常が発生したサーバノードを検出すると所定の記憶装置に通信異常が発生したサーバノードを記憶する（ステップＳ２２１０）。以下、この記憶した情報を「通信異常ノード情報」という。
【０２０６】
通信異常が発生したスタンバイ状態のサーバノードが存在する場合、高信頼動作処理部７４０は、処理をステップＳ２２１１に移行する（ステップＳ２２０６  ＹＥＳ）。
一方、ステップＳ２２０６において、通信異常ノード情報にスタンバイ状態のサーバノードが記憶されている場合、高信頼動作処理部７４０は、スタンバイ状態のサーバノードに通信異常があると判断し、処理をステップＳ２２０７に移行する（ステップＳ２２０６  ＹＥＳ）。
【０２０７】
ステップＳ２２０７において、高信頼動作処理部７４０は、アクティブ状態のサーバノードに対して停止を指示する。また、アクティブ状態のサーバノードが停止すると、高信頼動作処理部７４０は、通信異常ノード情報を参照し、通信異常ノード情報に記憶されていないスタンバイ状態のサーバノードのうちあらかじめ決められた優先順位の最も高いものを抽出する。そして、抽出した通信異常の発生していないスタンバイ状態のノードに対してアクティブ化の開始を指示する。
【０２０８】
ステップＳ２２０８において、高信頼動作処理部７４０は、スタンバイ状態のサーバノードをアクティブ状態に切替え中である旨を通信制御部に通知する。
ここで、ステップＳ２２０３において、受信したイベントが異常監視パスの通信異常の通知でない場合、高信頼動作処理部７４０は、処理をステップＳ２２０９に移行する（ステップＳ２２０３  ＮＯ）。
【０２０９】
ステップＳ２２０９において、高信頼動作処理部７４０は、通信異常が発生したサーバノードはアクティブ状態であるか否かを判別する。そして、通信異常が発生したサーバノードはアクティブ状態でない場合、高信頼動作処理部７４０は、処理をステップＳ２２１０に移行する（ステップＳ２２０９  ＮＯ）。
【０２１０】
ステップＳ２２１０において、高信頼動作処理部７４０は、ステップＳ２２０３において通信異常を検出したサーバノードを通信異常ノード情報に記憶する。
一方、通信異常が発生したサーバノードがアクティブ状態である場合、高信頼動作処理部７４０は、処理をステップＳ２２１１に移行する（ステップＳ２２０９  ＹＥＳ）。
【０２１１】
ステップＳ２２１１において、高信頼動作処理部７４０は、アクティブ状態のサーバノードを停止するように指示する。そして、アクティブ状態のサーバノードが停止すると、高信頼動作処理部７４０は、スタンバイ状態のサーバノードからあらかじめ決められた優先順位の最も高いものを選択し、選択したサーバノードに対してアクティブ状態への切替えの開始を指示する。
【０２１２】
ステップＳ２２１２において、高信頼動作処理部７４０は、スタンバイ状態のサーバノードをアクティブ状態に切替え中である旨を通信制御部に通知する。
以上に示したステップＳ２２０５、Ｓ２２０８、Ｓ２２１０またはＳ２２１２の処理が完了すると、高信頼動作処理部７４０は、ステップＳ２２１３に移行してイベントの受付け処理を終了する。
【０２１３】
以上の説明において、図１では、クライアントノード１１０、サーバノード１２０および１３０には、それぞれ１つのＯＳが動作している場合を示しているが、これに限定する趣旨ではない。例えば、図２８に示すように、サーバノード１２０および１３０に２以上のＯＳが動作していてもよい。
【０２１４】
図２８のサーバノード１２０には、３つのＯＳが動作し、各ＯＳ上にアプリケーションＣおよび通信制御部１２１、アプリケーションＦおよび通信制御部１５１、アプリケーションＧおよび通信制御部１６１がそれぞれ動作している場合を示している。
【０２１５】
同様に、サーバノード１３０には、３つのＯＳが動作し、各ＯＳ上にアプリケーションＤおよび通信制御部１３１、アプリケーションＨおよび通信制御部１７１、アプリケーションＩおよび通信制御部１８１がそれぞれ動作している場合を示している。
【０２１６】
ただし、アプリケーションＣ、Ｆ、Ｇは、それぞれサービス１、２、３を提供し、アプリケーションＤ、Ｈ、Ｉは、それぞれサービス１、２、３を提供するものとする。
この場合、例えば、サービス毎にアプリケーションが使用する異なるポートを割り当てると、クライアントノード１１０は、アプリケーションが提供するサービス毎に、異常監視通信を行うことができる。
【０２１７】
この時のクライアント用制御テーブルを図２９に示す。図２９に示すクライアント用制御テーブルは、ポート番号毎に受信者リストを管理する場合のクライアント用制御テーブルの例を示している。クライアント用制御テーブルの内容については、図７で説明したので省略する。
【０２１８】
なお、サービス毎にマルチキャストＩＰアドレスを割り当てた場合には、マルチキャストＩＰアドレス毎に受信者リストを管理するクライアント用制御テーブルを使用すればよい。
【０２１９】
（１）本実施例に係るシステム１００は、図２３に示すように、互いに２つの独立なネットワーク、または２以上の互いに独立なネットワークでノード間を接続する。そして、通信パケットは、それぞれのネットワークに同時に送信する。
ここで、図２３に示す実線の経路をネットワーク１系、点線の経路をネットワーク２系とすると、図２４に示すように、送信元ノードは両ネットワークに同時に通信パケットを
送信するので、実線で示すネットワーク１系に障害が発生しても、点線で示すネットワーク２系を経由して送信元ノードから送信先ノードに通信パケットが到達する。
【０２２０】
一方、送信先ノードは、ネットワーク１系とネットワーク２系の両方から通信パケットを受信するので、例えば、ネットワーク１系に障害が発生しても、ネットワーク２系から通信パケットを受信し、その通信パケットに対して応答パケットを送信することができる。
【０２２１】
これにより、いずれかのネットワークで障害が発生した場合であっても、障害した箇所を回避するために経路変更をすることなく、障害が発生していないネットワークを経由して通信パケットを送信先に到達する。
【０２２２】
その結果、ネットワークに障害が発生した場合であっても、通信経路の変更等によりアプリケーション間通信を中断することを防止することが可能となる。そして、アプリケーション間通信を中断する時間を０とすることが可能となる。
【０２２３】
（２）本実施例に係るシステム１００では、アプリケーション間通信用セションとは別に、ノード間の異常、例えばネットワークの異常や通信相手の異常を監視するために送信元ノードの通信制御部と送信先ノードの通信制御部との間で異常監視セションを確立し、アプリケーション間通信用セションにおける再送間隔の間隔より短い間隔で監視パケットの送受信を行う。
短い間隔でノード間の異常監視を行うことにより、ネットワークの異常や通信相手の異常を早期に検出することが可能となる。
例えば、図２５では、異常監視セションにおいて０．５秒間隔で通信パケットの送受信をおこなって異常監視を行う場合を示している。ネットワーク１系とネットワーク２系とで障害が発生すると、アプリケーション間通信用セションでは、アプリケーションが１秒後に再送処理を行う。一方、異常監視セションでは、通信制御部が０．５秒間隔で監視パケットを送信する。そして、監視応答パケットの未受信回数が３回以上となると、通信制御部は経路異常と判断し、アプリケーションからの通信パケットの送信要求に対して経路異常を通知する。その結果、ネットワークでの異常発生から１．５秒で異常が正しく検出される。
【０２２４】
また、異常監視セションは、アプリケーション間毎ではなく通信制御部間で１つだけ確立して異常監視を行うので、その分アプリケーション間通信用セションにおける再送間隔を長く設定することが可能となる。
【０２２５】
異常監視セションにおいては、短い間隔で監視パケットの送受信が行われるが、図６に示したように必要最小限の極小さいサイズのデータであるので、ネットワークの帯域と各ノードにおけるＣＰＵ負荷を大幅に改善することが可能となる。
さらに、アプリケーション間通信用セションにおける再送間隔が長くなることで、結果として、システム１００全体のトラフィックを軽減することが可能となる。
【０２２６】
（３）本実施例に係るシステム１００は、図２６に示すように、通信制御部間で異常監視セションを確立して一定間隔で通信を行う。一方、送信先ノードが監視要求パケットを受信すると、Ｉ／Ｏ割込みに連動して通信制御部が動作する。そして、通信制御部は、図１９などに示した監視要求パケット受信処理を実行し、監視要求パケットに対する監視応答パケットを送信する。
【０２２７】
したがって、受信先ノードのＣＰＵが一時的に高負荷の状態であった場合でも、受信した監視要求パケットに対して監視応答パケットを送信する応答処理が可能となる。通信制
御部間では一定間隔で監視パケットの送受信処理が可能となるので、送信元ノードにおけるアプリケーションの通信パケットの再送処理時間を、例えば送信先ノードでの処理遅延予想時間よりも長く設定することが可能となる。
【０２２８】
その結果、受信先ノードにおいてＣＰＵの一時的高負荷によりアプリケーション間通信を行っているアプリケーションの応答が一時的に遅延している状態を、送信元ノードが異常と誤検出することを防止することが可能となる。
【０２２９】
（４）本実施例に係るシステム１００は、サーバノードがクラスタ構成を成す。そして、各サーバノードは、サーバノード間異常監視により互いの通信状態を監視する。一方、クライアントノードは、クライアントノード／サーバノード間異常監視により各サーバノードとの通信経路に発生する異常や各サーバノードに発生する異常を監視する。
そして、アクティブ状態のサーバノードに異常が発生した場合、図２２に示したように、サーバノード間異常監視の結果得られる情報と、クライアントノード／サーバノード間異常監視の結果得られる情報と、からアクティブ状態に切替えるべきサーバノードを決定する。
【０２３０】
その結果、異常の発生していないスタンバイ・ノードを正確に判断することが可能となる。その結果、不適切なスタンバイ・ノードのアクティブ状態への切替えを防止することが可能となる。
【０２３１】
なお、サーバノード間異常監視の結果得られる情報とは、例えば、図２２で説明した通信異常ノード情報である。また、クライアントノード／サーバノード間異常監視の結果得られる情報とは、例えば、図８に示した他のノード・ステータスである。
【０２３２】
例えば、図２７に示すように、ルータ＃４において、サーバノード１３０との間のネットワークに異常が発生した場合、クライアントノード１１０は、監視応答要求時間内にサーバノード１３０から監視応答パケットを受信しないので、サーバノード１３０との通信に異常を検出する。
【０２３３】
すると、クライアントノード１１０は、図７に示したノード・ステータスに通信異常を記憶するとともに、監視要求パケットの監視パケット用ヘッダのノード・ステータスに通信異常を設定して送信し、サーバノード１３０との通信に異常が発生した旨を通知する。
【０２３４】
監視要求パケットを受信したサーバノード１２０、１４０は、図８に示した他のノード・ステータスにサーバノード１３０に異常が発生した旨を記憶する。
また、図２７に示すクラスタにおいて、サーバノード１２０との通信に異常が発生した場合、例えば、サーバノード１４０は、サーバノード１２０との通信に異常を検出すると、高信頼動作処理部７４０にその旨を通知する。
【０２３５】
高信頼動作処理部７４０は、図２２に示したフローチャートにしたがって、サーバノード１４０をアクティブ状態に切替えるように通信制御部１４１に指示する（例えば、ステップＳ２２０４、Ｓ２２０６〜Ｓ２２０８）。
【０２３６】
（５）システム１００において、クライアントノードからサーバノードへは、マルチキャストＩＰアドレスを指定してデータ転送が行われる。これにより、クラスタ構成を実現する全てのサーバノードに対し、ネットワーク毎に同一データを送信することが可能となる。
この通信方式を、アプリケーション間通信用セションだけでなく、異常監視用セションにも適用し、クライアントノードから、常にクラスタ構成を実現する全てのサーバノード
に対し監視パケットを送信して、全てのサーバノードの状態をクライアントノード内の通信制御部（図７に示した制御テーブル）で監視する。
【０２３７】
その結果、図２７に示すように、アクティブ状態のサーバノードから監視応答パケットが一定時間受信できなかった場合に、同一のクラスタ内のスタンバイ状態のサーバノードのうち、どのサーバノードから監視応答パケットを受信できているかを、クライアントノードで正確に判断することが可能となる。
【０２３８】
また、クライアントノードでは、監視応答パケットを受信できているサーバノードのノード番号を設定した監視要求パケットを送信することで、クラスタ構成の各サーバノードにおいて、同一クラスタ構成内のノードのうち、どのサーバノードがクライアントノードと正常に通信できているかを正確に判断することが可能となる。
【０２３９】
また、スタンバイ・ノードをアクティブ化する際、新たにアクティブ状態となったサーバノードが、最初に送信する監視応答パケットに、アクティブ・ノードの切替えが発生した旨の情報（図６に示すステータス２の情報）を付加して送信し、クライアントノードでは、この情報が設定された監視応答パケットの受信を契機に、アプリケーション間通信用セションで応答受信待ちの送信データを再送することで、アプリケーション間通信の中断時間を最小化することが可能となる。
以上のように、システム１００は、高い信頼性を備えるアプリケーション間通信を実現することが可能となる。
【０２４０】
以上の実施例１〜ｎを含む実施形態に関し、さらに以下の付記を開示する。
（付記１）
物理的に独立した２以上の通信経路と互いに通信可能に接続されたノード間で行う通信であって、第１のノード上で動作する第１のアプリケーションと第２のノード上で動作する第２のアプリケーションとで行われるアプリケーション間通信において、
前記第１のアプリケーションと前記第２のアプリケーションとの間で通信するためのアプリケーション間通信用セションの確立の要求を前記第１のアプリケーションから受けると、前記第１のノード上で動作し少なくとも前記第１のアプリケーションの通信を制御する第１の通信制御部と、前記第２のノード上で動作し少なくとも前記第２のアプリケーションの通信を制御する第２の通信制御部との間に、通信の異常を監視する異常監視通信を行うための異常監視用セションが既に確立されているか否かを確認し、該異常監視用セションが確立されていない場合には、前記第２の通信制御部に対して、前記異常監視用セションの確立を要求して該異常監視用セションを確立する異常監視用セション確立処理と、
前記異常監視用セションが確立すると、前記アプリケーション間通信用セションの確立を前記第２のアプリケーションに要求して前記アプリケーション間通信用セションを確立するアプリケーション間通信用セション確立処理と、
前記アプリケーション間通信用セションにおいて前記第２のアプリケーションから一定時間応答を受信しない場合に再度前記第２のアプリケーションに同一内容の通信パケットを送信する再送処理の間隔より短い間隔で、前記異常監視用セションにおいて異常監視に必要な情報のみを用いて異常監視通信を行う異常監視通信処理と、
を全ての前記通信経路に対して同一の通信パケットを同時に送信することにより前記第１のノードに実行させるプログラム。
（付記２）
前記第１の通信制御部は、前記第１のアプリケーションが動作するオペレーティング・システム上で動作し、該オペレーティング・システム上で動作する全てのアプリケーション間通信を行うアプリケーションの通信を制御し、
前記第２の通信制御部は、前記第２のアプリケーションが動作するオペレーティング・システム上で動作し、該オペレーティング・システム上で動作する全てのアプリケーショ
ン間通信を行うアプリケーションの通信を制御する、
ことを特徴とする請求項１に記載のプログラム。
（付記３）
前記異常監視用セションにおいて、前記第１の通信制御部は、前記第２の通信制御部に送る通信パケットにマルチキャストＩＰアドレスを設定して送信する、
ことを特徴とする請求項１に記載のプログラム。
（付記４）
前記異常監視用セションにおいて、一定時間内に前記第２の通信制御部からの応答を受信しない回数が所定の回数を超えた場合、前記第２のノードとの間の通信に異常が発生したと判断する、
ことを特徴とする請求項１に記載のプログラム。
（付記５）
前記第２のノードとの間の通信に異常が発生したと判断すると、前記第１の通信制御部は、前記第１のアプリケーションに前記第２のノードとの間の通信に異常が発生したことを通知する、
ことを特徴とする請求項４に記載のプログラム。
（付記６）
前記異常監視通信処理は、少なくとも前記第２のノードとの通信の異常の有無を含む情報を設定した監視要求パケットを、全ての前記通信経路に対して同時に送信する、
ことを特徴とする請求項４に記載のプログラム。
（付記７）
物理的に独立した２以上の通信経路と互いに通信可能に接続されたノード間で行う通信であって、第１のノード上で動作する第１のアプリケーションと第２のノード上で動作する第２のアプリケーションとで行われるアプリケーション間通信において、
前記第１のノード上で動作し少なくとも前記第１のアプリケーションの通信を制御する第１の通信制御部から、該第１の通信制御部と前記第２のノード上で動作し少なくとも前記第２のアプリケーションの通信を制御する第２の通信制御部との間で通信の異常を監視する異常監視通信を行うための前記異常監視用セションの確立の要求を受けると、Ｉ／Ｏ割込みに連動して、前記第１の通信制御部と前記異常監視用セションを確立する異常監視用セション確立処理と、
前記第１の通信制御部から、前記第１のアプリケーションと前記第２のアプリケーションとの間で通信するためのアプリケーション間通信用セションの確立の要求を受けると、前記第１のアプリケーションと前記アプリケーション間通信用セションを確立するアプリケーション間通信用セション確立処理と、
前記アプリケーション間通信用セションにおいて前記第２のアプリケーションから一定時間応答を受信しない場合に第１のアプリケーションが再度前記第２のアプリケーションに同一内容の通信パケットを送信する再送処理の間隔より短い間隔で、前記異常監視用セションにおいて異常監視に必要な情報のみを用いて異常監視通信を行う異常監視通信処理と、
を全ての前記通信経路に対して同一の通信パケットを同時に送信することにより前記第２のノードに実行させるプログラム。
（付記８）
前記第１の通信制御部は、前記第１のアプリケーションが動作するオペレーティング・システム上で動作し、該オペレーティング・システム上で動作する全てのアプリケーション間通信を行うアプリケーションの通信を制御し、
前記第２の通信制御部は、前記第２のアプリケーションが動作するオペレーティング・システム上で動作し、該オペレーティング・システム上で動作する全てのアプリケーション間通信を行うアプリケーションの通信を制御する、
ことを特徴とする請求項１に記載のプログラム。
（付記９）
前記異常監視用セションにおいて、一定時間内に前記第１の通信制御部からの通信パケットを受信しない回数が所定の回数を超えた場合、前記第１のノードとの間の通信に異常が発生したと判断する、
ことを特徴とする請求項１に記載のプログラム。
（付記１０）
前記第１のノードとの間の通信に異常が発生したと判断すると、前記第２の通信制御部は、前記第２のアプリケーションに前記第２のノードとの間の通信に異常が発生したことを通知する、
ことを特徴とする請求項９に記載のプログラム。
（付記１１）
前記異常監視通信処理は、少なくとも前記第１のノードとの通信の異常の有無を含む情報が設定された監視要求パケットを、前記第１の通信制御部から受信し、該監視要求パケットと同一の監視パケットを重複して受信した場合には、重複して受信した監視要求パケットを破棄する、
ことを特徴とする請求項９に記載のプログラム。
（付記１２）
前記第２のノードは、アクティブ状態のノードと、１または２以上のスタンバイ状態のノードと、によるクラスタ構成を成す、
ことを特徴とする請求項７に記載のプログラム。
（付記１３）
クラスタ構成を成す前記ノードは、一定間隔で相互に通信を行って各ノードの通信状態を監視する、
ことを特徴とする請求項７に記載のプログラム。
（付記１４）
前記第１の通信制御部から送信された通信パケットであって、クラスタ構成を成す前記第２のノードに含まれる各ノードとの通信の異常の有無を含む情報が設定された監視要求パケットから、該第２のノードに含まれる各ノードの通信の異常に関する情報を取得し、
該取得した前記第２のノードに含まれる各ノードの通信の異常に関する情報と、クラスタ構成を成す前記第２のノードに含まれる各ノードが一定間隔で相互に通信を行って各ノードの通信状態を監視した結果得られる前記第２のノードに含まれる各ノードの通信の異常に関する情報と、から、アクティブ状態に切替えるノードを決定する、
ことを特徴とする請求項１２に記載のプログラム。
（付記１５）
物理的に独立した２以上の通信経路と互いに通信可能に接続されたノード間で行う通信であって、第１のノード上で動作する第１のアプリケーションと第２のノード上で動作する第２のアプリケーションとで行われるアプリケーション間通信において、
前記第１のアプリケーションと前記第２のアプリケーションとの間で通信するためのアプリケーション間通信用セションの確立の要求を前記第１のアプリケーションから受けると、前記第１のノード上で動作し少なくとも前記第１のアプリケーションの通信を制御する第１の通信制御部と、前記第２のノード上で動作し少なくとも前記第２のアプリケーションの通信を制御する第２の通信制御部との間に、通信の異常を監視する異常監視通信を行うための異常監視用セションが既に確立されているか否かを確認し、該異常監視用セションが確立されていない場合には、前記第２の通信制御部に対して、前記異常監視用セションの確立を要求して該異常監視用セションを確立する異常監視用セション確立処理と、
前記異常監視用セションが確立すると、前記アプリケーション間通信用セションの確立を前記第２のアプリケーションに要求して前記アプリケーション間通信用セションを確立するアプリケーション間通信用セション確立処理と、
前記アプリケーション間通信用セションにおいて前記第２のアプリケーションから一定時間応答を受信しない場合に再度前記第２のアプリケーションに同一内容の通信パケットを送信する再送処理の間隔より短い間隔で、前記異常監視用セションにおいて異常監視に
必要な情報のみを用いて異常監視通信を行う異常監視通信処理と、
を全ての前記通信経路に対して同一の通信パケットを同時に送信することにより前記第１のノードに実行させる通信方法。
（付記１６）
物理的に独立した２以上の通信経路と互いに通信可能に接続されたノード間で行う通信であって、第１のノード上で動作する第１のアプリケーションと第２のノード上で動作する第２のアプリケーションとで行われるアプリケーション間通信において、
前記第１のノード上で動作し少なくとも前記第１のアプリケーションの通信を制御する第１の通信制御部から、該第１の通信制御部と前記第２のノード上で動作し少なくとも前記第２のアプリケーションの通信を制御する第２の通信制御部との間で通信の異常を監視する異常監視通信を行うための前記異常監視用セションの確立の要求を受けると、Ｉ／Ｏ割込みに連動して、前記第１の通信制御部と前記異常監視用セションを確立する異常監視用セション確立処理と、
前記第１の通信制御部から、前記第１のアプリケーションと前記第２のアプリケーションとの間で通信するためのアプリケーション間通信用セションの確立の要求を受けると、前記第１のアプリケーションと前記アプリケーション間通信用セションを確立するアプリケーション間通信用セション確立処理と、
前記アプリケーション間通信用セションにおいて前記第２のアプリケーションから一定時間応答を受信しない場合に第１のアプリケーションが再度前記第２のアプリケーションに同一内容の通信パケットを送信する再送処理の間隔より短い間隔で、前記異常監視用セションにおいて異常監視に必要な情報のみを用いて異常監視通信を行う異常監視通信処理と、
を全ての前記通信経路に対して同一の通信パケットを同時に送信することにより前記第２のノードに実行させる通信方法。
（付記１７）
物理的に独立した２以上の通信経路と互いに通信可能に接続された第１のノード上で動作する第１のアプリケーションと第２のノード上で動作する第２のアプリケーションとで行うアプリケーション間通信のための通信装置において、
前記第１のアプリケーションと前記第２のアプリケーションとの間で通信するためのアプリケーション間通信用セションの確立の要求を前記第１のアプリケーションから受けると、前記第１のノード上で動作し少なくとも前記第１のアプリケーションの通信を制御する第１の通信制御部と、前記第２のノード上で動作し少なくとも前記第２のアプリケーションの通信を制御する第２の通信制御部との間に、通信の異常を監視する異常監視通信を行うための異常監視用セションが既に確立されているか否かを確認し、該異常監視用セションが確立されていない場合には、前記第２の通信制御部に対して、前記異常監視用セションの確立を要求して該異常監視用セションを確立する異常監視用セション確立部と、
前記異常監視用セションが確立すると、前記アプリケーション間通信用セションの確立を前記第２のアプリケーションに要求して前記アプリケーション間通信用セションを確立するアプリケーション間通信用セション確立部と、
前記アプリケーション間通信用セションにおいて前記第２のアプリケーションから一定時間応答を受信しない場合に再度前記第２のアプリケーションに同一内容の通信パケットを送信する再送処理の間隔より短い間隔で、前記異常監視用セションにおいて異常監視に必要な情報のみを用いて異常監視通信を行う異常監視通信部と、
が全ての前記通信経路に対して同一の通信パケットを同時に送信することにより通信を行う通信装置。
（付記１８）
物理的に独立した２以上の通信経路と互いに通信可能に接続された第１のノード上で動作する第１のアプリケーションと第２のノード上で動作する第２のアプリケーションとで行うアプリケーション間通信のための通信装置において、
前記第１のノード上で動作し少なくとも前記第１のアプリケーションの通信を制御する
第１の通信制御部から、該第１の通信制御部と前記第２のノード上で動作し少なくとも前記第２のアプリケーションの通信を制御する第２の通信制御部との間で通信の異常を監視する異常監視通信を行うための前記異常監視用セションの確立の要求を受けると、Ｉ／Ｏ割込みに連動して、前記第１の通信制御部と前記異常監視用セションを確立する異常監視用セション確立部と、
前記第１の通信制御部から、前記第１のアプリケーションと前記第２のアプリケーションとの間で通信するためのアプリケーション間通信用セションの確立の要求を受けると、前記第１のアプリケーションと前記アプリケーション間通信用セションを確立するアプリケーション間通信用セション確立部と、
前記アプリケーション間通信用セションにおいて前記第２のアプリケーションから一定時間応答を受信しない場合に第１のアプリケーションが再度前記第２のアプリケーションに同一内容の通信パケットを送信する再送処理の間隔より短い間隔で、前記異常監視用セションにおいて異常監視に必要な情報のみを用いて異常監視通信を行う異常監視通信部と、
が全ての前記通信経路に対して同一の通信パケットを同時に送信することにより通信を行う通信装置。
（付記１９）
前記第２のノードは、アクティブ状態のノードと、１または２以上のスタンバイ状態のノードと、によるクラスタ構成を成す、
ことを特徴とする請求項１８に記載の通信装置。
（付記２０）
前記第１の通信制御部から送信された通信パケットであって、クラスタ構成を成す前記第２のノードに含まれる各ノードとの通信の異常の有無を含む情報が設定された監視要求パケットから、該第２のノードに含まれる各ノードの通信の異常に関する情報を取得し、
該取得した前記第２のノードに含まれる各ノードの通信の異常に関する情報と、クラスタ構成を成す前記第２のノードに含まれる各ノードが一定間隔で相互に通信を行って各ノードの通信状態を監視した結果得られる前記第２のノードに含まれる各ノードの通信の異常に関する情報と、から、アクティブ状態に切替えるノードを決定する、
ことを特徴とする請求項１９に記載のプログラム。
（付記２１）
物理的に独立した２以上の通信経路と互いに通信可能に接続された第１のノード上で動作する第１のアプリケーションと第２のノード上で動作する第２のアプリケーションとで行うアプリケーション間通信のための通信装置において、
前記第１のアプリケーションと前記第２のアプリケーションとの間で通信するためのアプリケーション間通信用セションの確立の要求を前記第１のアプリケーションから受けると、前記第１のノード上で動作し少なくとも前記第１のアプリケーションの通信を制御する第１の通信制御部と、前記第２のノード上で動作し少なくとも前記第２のアプリケーションの通信を制御する第２の通信制御部との間に、通信の異常を監視する異常監視通信を行うための異常監視用セションが既に確立されているか否かを確認し、該異常監視用セションが確立されていない場合には、前記第２の通信制御部に対して、前記異常監視用セションの確立を要求して該異常監視用セションを確立する異常監視用セション確立部と、
前記異常監視用セションが確立すると、前記アプリケーション間通信用セションの確立を前記第２のアプリケーションに要求して前記アプリケーション間通信用セションを確立するアプリケーション間通信用セション確立部と、
前記アプリケーション間通信用セションにおいて前記第２のアプリケーションから一定時間応答を受信しない場合に再度前記第２のアプリケーションに同一内容の通信パケットを送信する再送処理の間隔より短い間隔で、前記異常監視用セションにおいて異常監視に必要な情報のみを用いて異常監視通信を行う異常監視通信部と、
が全ての前記通信経路に対して同一の通信パケットを同時に送信することにより通信を行う第１のノードと、
前記第１のノード上で動作し少なくとも前記第１のアプリケーションの通信を制御する第１の通信制御部から、該第１の通信制御部と前記第２のノード上で動作し少なくとも前記第２のアプリケーションの通信を制御する第２の通信制御部との間で通信の異常を監視する異常監視通信を行うための前記異常監視用セションの確立の要求を受けると、Ｉ／Ｏ割込みに連動して、前記第１の通信制御部と前記異常監視用セションを確立する異常監視用セション確立部と、
前記第１の通信制御部から、前記第１のアプリケーションと前記第２のアプリケーションとの間で通信するためのアプリケーション間通信用セションの確立の要求を受けると、前記第１のアプリケーションと前記アプリケーション間通信用セションを確立するアプリケーション間通信用セション確立部と、
前記アプリケーション間通信用セションにおいて前記第２のアプリケーションから一定時間応答を受信しない場合に第１のアプリケーションが再度前記第２のアプリケーションに同一内容の通信パケットを送信する再送処理の間隔より短い間隔で、前記異常監視用セションにおいて異常監視に必要な情報のみを用いて異常監視通信を行う異常監視通信部と、
が全ての前記通信経路に対して同一の通信パケットを同時に送信することにより通信を行う第２のノードと、
を備える通信システム。
【図面の簡単な説明】
【０２４１】
【図１】アプリケーション間通信を実現するシステム構成の例を示す図である。
【図２】アプリケーション間通信時のコネクション環境を説明する図である。
【図３】通信パケットの流れを説明する図である。
【図４】異常監視用セションでの通信パケットの流れを説明する図である。
【図５】アプリケーション間通信用セションと異常監視用セションの関係を説明する図である。
【図６】異常監視用セションで使用する監視パケットの構成例を示す図である。
【図７】クライアントノードの通信制御部で使用する制御テーブルの構成例を示す図である。
【図８】サーバノードの通信制御部で使用する制御テーブルの構成例を示す図である。
【図９】サーバノードまたはクライアントノードを実現する主要な構成を説明するブロック図である。
【図１０】クライアントノードがサーバノードとの異常を検出するまでの処理の概要を説明する図である。
【図１１】システムが恒久障害を検出するまでの処理を説明する図である。
【図１２】サーバノードがクライアントノードとの通信異常を検出するまでの処理を説明する図である。
【図１３】クライアントノードにおける通信制御部の環境作成・設定処理部の処理を示すフローチャートである。
【図１４】クライアントノードにおける通信制御部のパケット送信処理を示すフローチャートである。
【図１５】クライアントノードの異常監視セション処理部による監視パケットの送受信処理の概要を示すフローチャートである。
【図１６】クライアントノードにおける異常監視セション処理部の異常監視セション確立処理（ステップＳ１５０２）のフローチャートである。
【図１７】クライアントノードにおける異常監視セション処理部の監視応答パケットの受信処理（Ｓ１５０６）を示す図である。
【図１８】クライアントノードにおける異常監視セション処理部の異常監視セションタイマ処理（Ｓ１５０４）を示す図である。
【図１９】サーバノードにおける異常監視セション処理部による監視パケットの送受信処理の概要を示すフローチャートである。
【図２０】サーバノードにおける異常監視セション処理部による監視要求パケットの受信処理（Ｓ１９０２）を示すフローチャートである。
【図２１】サーバノードにおける異常監視セション処理部による未受信回数の更新処理（ステップＳ１９０４）を示すフローチャートである。
【図２２】サーバノードにおける高信頼動作処理部の動作を示すフローチャートである。
【図２３】本実施例に係るシステムの効果を説明する図である。
【図２４】本実施例に係るシステムの効果を説明する図である。
【図２５】本実施例に係るシステムの効果を説明する図である。
【図２６】本実施例に係るシステムの効果を説明する図である。
【図２７】本実施例に係るシステムの効果を説明する図である。
【図２８】アプリケーション間通信を実現するシステム構成の変形例を示す図である。
【図２９】図２８に示したシステム構成の場合のクライアント用制御テーブルの例を示す図である。
【図３０】プロセス間通信の従来例を説明する図である。
【図３１】プロセス間通信の従来例を説明する図である。
【図３２】プロセス間通信の従来例を説明する図である。
【図３３】プロセス間通信の従来例を説明する図である。
【図３４】プロセス間通信の従来例を説明する図である。
【符号の説明】
【０２４２】
１００      システム
１１０      クライアントノード
１１１      通信制御部
１２０、１３０、１４０      サーバノード
１２１、１３１、１４１      通信制御部
７１０      アプリケーション間通信用セション処理部
７１１      環境作成・設定ＡＰＩ
７１２      環境作成・設定処理部
７１３      パケット送信ＡＰＩ
７１４      パケット受信ＡＰＩ
７２０      異常監視用セション処理部
７３０      共通制御部
７３１      制御テーブル記憶部
７３２      パケット送信処理部
７３３      パケット受信処理部
【図１】
2010081496.tif 000003
【図３】
2010081496.tif 000004
【図４】
2010081496.tif 000005
【図５】
2010081496.tif 000006
【図７】
2010081496.tif 000007
【図８】
2010081496.tif 000008
【図９】
2010081496.tif 000009
【図１０】
2010081496.tif 000010
【図１１】
2010081496.tif 000011
【図１２】
2010081496.tif 000012
【図１３】
2010081496.tif 000013
【図１４】
2010081496.tif 000014
【図１５】
2010081496.tif 000015
【図１６】
2010081496.tif 000016
【図１７】
2010081496.tif 000017
【図１８】
2010081496.tif 000018
【図１９】
2010081496.tif 000019
【図２０】
2010081496.tif 000020
【図２１】
2010081496.tif 000021
【図２２】
2010081496.tif 000022
【図２３】
2010081496.tif 000023
【図２４】
2010081496.tif 000024
【図２５】
2010081496.tif 000025
【図２６】
2010081496.tif 000026
【図２７】
2010081496.tif 000027
【図２８】
2010081496.tif 000028
【図２９】
2010081496.tif 000029
【図３０】
2010081496.tif 000030
【図３１】
2010081496.tif 000031
【図３２】
2010081496.tif 000032
【図３３】
2010081496.tif 000033
【図３４】
2010081496.tif 000034
【図２】
2010081496.tif 000035
【図６】
2010081496.tif 000036