(57)【要約】【課題】  サーバ−クライアント上で実行される多くのアプリケーションプログラムモジュールがソケットの接続を管理する管理を行わなければならない不必要な作業を低減する。【解決手段】  サーバまたはクライアントの通信のために必要なソケットを生成し、該当ソケットの接続状態をチェックするために定義されたＡＰＩを呼び出して、生成されたソケットを管理する少なくとも１つのアプリケーションプログラムモジュールと、アプリケーションプログラムモジュールから任意のＡＰＩが呼び出される場合、呼び出されたＡＰＩに設定された動作を行うためのプログラムがコーディングされた共通ライブラリーモジュールと、共通ライブラリーモジュールにコーディングされたプログラムの実行により生成され、アプリケーションプログラムモジュールにより生成されたソケットの接続状態を周期的にチェックするソケットチェック実行モジュールとを備える。【選択図】  図３
2006031685.tif 000002
【特許請求の範囲】
【請求項１】
サーバまたはクライアントの通信のために必要なソケットを生成し、該当ソケットの接続状態をチェックするために定義されたＡＰＩ（Application Programmable Interface）を呼び出して、前記生成されたソケットを管理する少なくとも１つのアプリケーションプログラムモジュールと、
前記アプリケーションプログラムモジュールから任意のＡＰＩが呼び出される場合には、呼び出されたＡＰＩに設定された動作を行うためのプログラムがコーディングされた共通ライブラリーモジュールと、
前記共通ライブラリーモジュールにコーディングされたプログラムの実行により生成され、前記生成されたソケットの接続状態を周期的にチェックするソケットチェック実行モジュールと、
を備えることを特徴とするソケット接続管理システム。
【請求項２】
前記ＡＰＩは、
ソケットチェック実行モジュールを生成するためのサーバ初期化ＡＰＩと、
任意のソケットに対する接続状態をチェックできるように、前記生成されたソケットチェック実行モジュールにソケットを登録するためのサーバ登録ＡＰＩと、
前記ソケットチェック実行モジュールに登録されており接続状態をチェックしていたソケットの登録を取り消すためのサーバ登録取消ＡＰＩと、
クライアントから受信されるソケットチェック用メッセージを処理するためのサーバプロセスＡＰＩと、
前記ソケットチェック実行モジュールに登録されていた全てのソケットを登録解除し、ソケットチェック実行モジュールを解除するためのサーバ解除ＡＰＩと、
の中で少なくとも１つのＡＰＩを含むことを特徴とする請求項１に記載のソケット接続管理システム。
【請求項３】
前記共通ライブラリーモジュールは、
ソケットチェック実行モジュールを生成するためのサーバ初期化ＡＰＩの呼び出しに対応して定義された機能を行うようにコーディングされたプログラムと、
任意のソケットに対する接続状態をチェックできるように、前記生成されたソケットチェック実行モジュールにソケットを登録するためのサーバ登録ＡＰＩの呼び出しに対応して定義された機能を行うようにコーディングされたプログラムと、
前記ソケットチェック実行モジュールに登録されており接続状態をチェックしていたソケットの登録を取り消すためのサーバ登録取消ＡＰＩの呼び出しに対応して定義された機能を行うようにコーディングされたプログラムと、
クライアントから受信されるソケットチェック用メッセージを処理するためのサーバプロセスＡＰＩの呼び出しに対応して定義された機能を行うようにコーディングされたプログラムと、
前記ソケットチェック実行モジュールに登録されていた全てのソケットを登録解除し、ソケットチェック実行モジュールを解除するためのサーバ解除ＡＰＩの呼び出しに対応して定義された機能を行うようにコーディングされたプログラムと、
の中で少なくとも１つを備えることを特徴とする請求項１に記載のソケット接続管理システム。
【請求項４】
前記ソケットチェック実行モジュールは、サーバに搭載され、
該サーバと任意のソケットを設定しているクライアントに周期的にソケットチェック要請メッセージを伝送し、該当クライアントから伝送されるソケットチェック応答メッセージが受信されたか否かによって、登録されたソケットの接続状態を周期的にチェックすることを特徴とする請求項１に記載のソケット接続管理システム。
【請求項５】
ソケットを生成しているクライアントの状態情報を格納するＤＢをさらに備えることを特徴とする請求項１に記載のソケット接続管理システム。
【請求項６】
前記クライアントの状態情報は、ソケットチェック用メッセージが送受信されたか否かに応じて、終了状態、伝送状態及び正常状態を含むことを特徴とする請求項５に記載のソケット接続管理システム。
【請求項７】
前記ＡＰＩは、
ソケットチェック実行モジュールを生成するためのクライアント初期化ＡＰＩと、
サーバから受信されるソケットチェック用メッセージを処理するためのクライアントプロセスＡＰＩと、
前記ソケットチェック実行モジュールに登録されていた全てのソケットを登録解除し、ソケットチェック実行モジュールを解除するためのクライアント解除ＡＰＩと、
の中で少なくとも１つのＡＰＩを含むことを特徴とする請求項１に記載のソケット接続管理システム。
【請求項８】
前記共通ライブラリーモジュールは、
ソケットチェック実行モジュールを生成するためのクライアント初期化ＡＰＩの呼び出しに対応して定義された機能を行うようにコーディングされたプログラムと、
サーバから受信されるソケットチェック用メッセージを処理するためのクライアントプロセスＡＰＩの呼び出しに対応して定義された機能を行うようにコーディングされたプログラムと、
前記ソケットチェック実行モジュールに登録されていた全てのソケットを登録解除し、ソケットチェック実行モジュールを解除するためのクライアント解除ＡＰＩの呼び出しに対応して定義された機能を行うようにコーディングされたプログラムと、
の中で少なくとも１つを備えることを特徴とする請求項１に記載のソケット接続管理システム。
【請求項９】
前記ソケットチェック実行モジュールは、クライアントに搭載され、
該当クライアントとソケットを設定しているサーバから周期的に伝送されるソケットチェック要請メッセージに応じて、サーバにソケットチェック応答メッセージを伝送することを特徴とする請求項１に記載のソケット接続管理システム。
【請求項１０】
サーバまたはクライアントの通信のために必要なソケットを生成し管理するようにプログラミングされたアプリケーションプログラムモジュールによって、任意のソケットを生成する段階と、
前記アプリケーションプログラムモジュールが、前記生成されたソケットの接続状態をチェックするために定義された任意のＡＰＩを呼び出す段階と、
前記アプリケーションプログラムモジュールから任意のＡＰＩが呼び出される場合に、呼び出されたＡＰＩに設定された動作が共通ライブラリーモジュールで実行される段階と、
前記共通ライブラリーモジュールにより生成されたソケットチェック実行モジュールを用いて、前記生成されたソケットの接続状態を周期的にチェックする段階と、
を有することを特徴とするソケット接続状態のチェック方法。
【請求項１１】
前記周期的にチェックする段階は、
サーバとソケットを設定しているクライアントに周期的にソケットチェック要請メッセージを伝送し、該当クライアントから伝送されるソケットチェック応答メッセージが受信されたか否かによって、登録されたソケットの接続状態を周期的にチェックすることを特徴とする請求項１０に記載のソケット接続状態のチェック方法。
【請求項１２】
前記周期的にチェックする段階は、
サーバから周期的に伝送されるソケットチェック要請メッセージに応じて、サーバにソケットチェック応答メッセージを伝送することを特徴とする請求項１０に記載のソケット接続状態のチェック方法。
【請求項１３】
前記共通ライブラリーモジュールは、サーバに搭載され、
前記共通ライブラリーモジュールで実行される段階は、
生成されたソケットの接続状態をチェックするためのソケットチェック実行モジュールを生成する段階と、
任意のソケットに対する接続状態をチェックできるように、前記生成されたソケットチェック実行モジュールに該当ソケットを登録する段階と、
前記生成されたソケットチェック実行モジュールを用いて、サーバとソケットを設定しているクライアントに周期的にソケットチェック要請メッセージを伝送し、該当クライアントから伝送されるソケットチェック応答メッセージが受信されたか否かによって、登録されたソケットの接続状態を周期的にチェックする段階と、
を有することを特徴とする請求項１０に記載のソケット接続状態のチェック方法。
【請求項１４】
前記共通ライブラリーモジュールは、クライアントに搭載され、
前記共通ライブラリーモジュールで実行される段階は、
生成されたソケットの接続状態をチェックするためのソケットチェック実行モジュールを生成する段階と、
前記生成されたソケットチェック実行モジュールによりサーバから周期的に伝送されるソケットチェック要請メッセージに応じて、サーバにソケットチェック応答メッセージを伝送する段階と、
を有することを特徴とする請求項１０に記載のソケット接続状態のチェック方法。
【請求項１５】
前記共通ライブラリーモジュールは、クライアントに搭載され、
前記共通ライブラリーモジュールで実行される段階は、
生成されたソケットの接続状態をチェックするためのソケットチェック実行モジュールを生成する段階と、
前記生成されたソケットチェック実行モジュールによりサーバから周期的に伝送されるソケットチェック要請メッセージが所定の周期内に受信されない回数が一定回数を超過する場合に接続したソケットを解除する段階と、
を有することを特徴とする請求項１０に記載のソケット接続状態のチェック方法。
【請求項１６】
任意のクライアントとソケットを設定するサーバにおいて前記設定されたソケットの接続状態をチェックする方法であって、
前記クライアントとソケットを設定した場合に、該当ソケットの接続状態をチェックするためのプログラムが格納されたライブラリー関数を呼び出す段階と、
前記呼び出されたライブラリー関数の実行により、周期的にチェックすべきソケットを登録する段階と、
前記呼び出されたライブラリー関数の実行により、前記クライアントに周期的にソケットチェック要請メッセージを伝送し、該当クライアントから伝送されるソケットチェック応答メッセージが受信されたか否かによって、登録されたソケットの接続状態を周期的にチェックする段階と、
を有することを特徴とするソケット接続状態のチェック方法。
【請求項１７】
前記周期的にチェックする段階は、
現在の時間情報を獲得する段階と、
前記ソケットを設定しているクライアントに周期的にソケット接続状態をチェックするための要請メッセージに、前記獲得した時間情報を添付して伝送する段階と、
前記クライアントから伝送される応答メッセージが受信されたか否かによって、前記ソケットの接続状態をチェックする段階と、
を有することを特徴とする請求項１６に記載のソケット接続状態のチェック方法。
【請求項１８】
前記ソケットの接続状態をチェックする段階は、
前記クライアントにソケットの接続状態をチェックするための要請メッセージを伝送した後に、所定の伝送周期のタイムアウトを超過するまで前記クライアントから応答メッセージがない無応答状態であるか否かを判断する段階と、
前記判断の結果、無応答状態である場合に、前記伝送周期のタイムアウトを超過した回数をカウントして、所定の許容回数を超過した場合には、ソケット接続を解除する段階と、
を有することを特徴とする請求項１７に記載のソケット接続状態のチェック方法。
【請求項１９】
前記ソケットの接続状態をチェックする段階は、
前記クライアントから応答メッセージが受信される場合に、該当応答メッセージに含まれた時間情報が前記クライアントへ伝送した要請メッセージに格納された時間情報と一致する正常な応答メッセージであるか否かを判断する段階と、
前記判断の結果、前記時間情報が一致しない場合には、異常な応答メッセージが受信された回数をカウントして、所定の許容回数を超過した場合には、前記クライアントとのソケット接続を解除する段階と、
を有することを特徴とする請求項１７に記載のソケット接続状態のチェック方法。
【請求項２０】
任意のサーバとソケットを設定しているクライアントにおいて該当ソケットの接続状態をチェックする方法であって、
前記サーバとソケットを設定する場合に、該当ソケットの接続状態をチェックするためのプログラムが格納されたライブラリー関数を呼び出す段階と、
前記呼び出されたライブラリー関数の実行により、前記サーバから周期的に受信されるソケットチェック要請メッセージに対してソケットチェック応答メッセージを伝送し、前記ソケットチェック要請メッセージが周期的に受信されるか否かによって、前記サーバと設定されたソケットの接続状態をチェックする段階と、
を有することを特徴とするソケット接続状態のチェック方法。
【請求項２１】
前記ソケットの接続状態をチェックする段階は、
前記サーバに前記ソケットチェック応答メッセージを伝送した後に、所定の伝送周期のタイムアウトを超過する前に、前記サーバからソケットチェック要請メッセージが受信されたか否かを判断する段階と、
前記判断の結果、前記伝送周期のタイムアウトを超過するまで前記ソケットチェック要請メッセージが受信されていない場合には、前記伝送周期のタイムアウトを超過した回数をカウントして、所定の許容回数を超過した場合には、ソケット接続を解除する段階と、
を有することを特徴とする請求項２０に記載のソケット接続状態のチェック方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、サーバとクライアント間のソケット管理に関し、詳細には、ＢＳＤ、ユニックス（Unix）（登録商標）、リナックス（Linux）系の運用体制を有するサーバ又は設備間の接続状態を管理し、接続に異常な問題が発生したときには接続を切り、再接続するソケット接続管理システム及びソケット接続状態のチェック方法に関する。
【背景技術】
【０００２】
ＢＳＤ、ユニックス（登録商標）、リナックス系のオペレーティングシステム（OS）を有するサーバまたは設備では、色々なアプリケーションが実行される。このようなアプリケーションが互いに通信を行うときは、ＴＣＰ（Transmission Control Protocol）のような接続指向のプロトコルを使用する場合が多い。ＴＣＰは、信頼性があり、全二重、連続バイトを提供する接続指向プロトコルであって、伝送されるデータの信頼性のために、基本的にエラーチェック及び再伝送、そして流れ制御機能を提供する。したがって、サーバまたは設備で実行されるアプリケーションは、ＴＣＰプロトコルによって接続状態を知ることができ、これを用いて相互間の主要メッセージをやりとりする。
【０００３】
大部分のオペレーティングシステムは、接続指向プロトコルのためのインタフェースとしてソケット（socket）を使用していて、各々のアプリケーションは、それら各々が接続に必要なソケットを管理する。
【０００４】
従来の接続指向ソケットの方式は、正常な状態でサーバとクライアント間の接続あるいは解除が可能であり、相手の状態が切られると、解除できるようになっている。しかしながら、サーバ側でもクライアント側でも相手の電源が切られたり、着脱可能なスロットから構成された設備で接続相手が取り除かれる状況では、接続ソケットが直ちに解除されずに、比較的長い時間接続ソケットを維持するようになる。しかも、ソケットが継続的に維持されている状態であるとみなされるので、内部的に情報をやりとりすることも可能だと判断され、誤動作の原因になり得る。特に、リアルタイムシステムである場合には、さらに問題となる。
【０００５】
また、接続解除がなされない場合のみならず、サーバ―クライアント間のあるモジュールの誤動作に起因してサーバとクライアント間の接続が切られた状態では、所定のソケットを解除し、再接続しなければならないが、状況を認知しない場合には、誤動作状態を継続的に維持しているようになるエラーが発生する。
【０００６】
図１は、従来の接続指向ソケットを利用した場合のエラーを示すフローチャートである。
【０００７】
図１を参照すれば、サーバ１は、第１のクライアント２及び第２のクライアント３とソケットを生成して通信を行っているうちに、第２のクライアント３に電力障害が発生したにもかかわらず、これを認知せずに、続いて第２のクライアント３にデータを伝送することによって、データ伝送のエラーを招いている。
【０００８】
一方、標準ソケットオプションのうち、“ＫＥＥＰＡＬＩＶＥ”という接続管理を行うものがあるが、一般的に２時間（７２００秒）を基本値として有し、中間にいかなるメッセージの交換がない単純な方式なので、速やかな接続復旧が不可能である。
【０００９】
したがって、大部分のアプリケーションプログラムでは、上述のような場合の処理のために、別途に各アプリケーションプログラム毎に特定の方式を用いてチェックを行わなければならないが、この場合、アプリケーションプログラム毎に個別の接続管理方式を有しなければならないので、類似の機能をすべてのアプリケーションプログラムに全て具現しなければならないという非常に不必要な作業が重複する。
【００１０】
また、各接続管理が一括して行われないので、実際には、サーバとクライアント間の接続問題なのか、単純に該当アプリケーション間の動作問題なのかを認識することができず、システム管理が難しく、複雑になる問題点がある。
【発明の開示】
【発明が解決しようとする課題】
【００１１】
本発明は、上述のような従来の問題点を解決するためになされたもので、本発明の目的は、サーバ−クライアント上で実行される多くのアプリケーションプログラムモジュールがソケットの接続を管理しなければならない不必要な作業を低減することができるソケット接続管理システム及びソケット接続状態のチェック方法を提供することにある。
【課題を解決するための手段】
【００１２】
上記目的を達成するために、本発明の一態様に係るソケット接続管理システムは、サーバまたはクライアントの通信のために必要なソケットを生成し、該当ソケットの接続状態をチェックするために定義されたＡＰＩ（Application Programmable Interface）を呼び出して、生成されたソケットを管理する少なくとも１つのアプリケーションプログラムモジュールと、アプリケーションプログラムモジュールから任意のＡＰＩが呼び出される場合に、呼び出されたＡＰＩに設定された動作を行うためのプログラムがコーディングされた共通ライブラリーモジュールと、共通ライブラリーモジュールにコーディングされたプログラムの実行により生成され、アプリケーションプログラムモジュールにより生成されたソケットの接続状態を周期的にチェックするソケットチェック実行モジュールとを備えることを特徴とする。
【００１３】
また、本発明の他の態様に係るソケット接続状態のチェック方法は、サーバまたはクライアントの通信のために必要なソケットを生成し管理するようにプログラミングされたアプリケーションプログラムモジュールが実行されることによって、任意のソケットを生成する段階と、アプリケーションプログラムモジュールが、生成されたソケットの接続状態をチェックするために定義された任意のＡＰＩ（Application Programmable Interface）を呼び出す段階と、アプリケーションプログラムモジュールから任意のＡＰＩが呼び出される場合に、呼び出されたＡＰＩに設定された動作が共通ライブラリーモジュールで実行される段階と、共通ライブラリーモジュールにコーディングされたプログラムの実行により生成されたソケットチェック実行モジュールを用いて、アプリケーションプログラムモジュールにより生成されたソケットの接続状態を周期的にチェックする段階とを備えることを特徴とする。
【００１４】
また、本発明のさらに他の態様に係るソケット接続状態のチェック方法は、任意のクライアントとソケットを設定するサーバにおいて設定されたソケットの接続状態をチェックする方法であって、クライアントとソケットを設定する場合に、該当ソケットの接続状態をチェックするためのプログラムが格納されたライブラリー関数を呼び出す段階と、呼び出されたライブラリー関数の実行により、周期的にチェックすべきソケットを登録する段階と、呼び出されたライブラリー関数の実行により、クライアントに周期的にソケットチェック要請メッセージを伝送し、該当クライアントから伝送されるソケットチェック応答メッセージが受信されたか否かによって、登録されたソケットの接続状態を周期的にチェックする段階とを備えることを特徴とする。
【００１５】
また、本発明のさらに他の態様に係るソケット接続状態のチェック方法は、任意のサーバとソケットを設定しているクライアントにおいて該当ソケットの接続状態をチェックする方法であって、サーバとソケットを設定する場合に、該当ソケットの接続状態をチェックするためのプログラムが格納されたライブラリー関数を呼び出す段階と、呼び出されたライブラリー関数の実行により、サーバから周期的に受信されるソケットチェック要請メッセージに対してソケットチェック応答メッセージを伝送し、ソケットチェック要請メッセージが周期的に受信されるか否かによって、サーバと設定されたソケットの接続状態をチェックする段階とを備えることを特徴とする。
【発明の効果】
【００１６】
本発明によれば、ＴＣＰのような接続指向プロトコルにおいては基本的に備えない部分である、接続状態チェック、相手の電源オフ時における接続解除及び再接続機能を共通ライブラリー形態で実現することによって、いろいろなアプリケーションプログラムが１つのモジュールのインタフェース関数だけを用いて該当機能を提供することができる。
【００１７】
これにより、各アプリケーションプログラムは、所望の接続管理機能を有するだけでなく、システム管理に必要なサーバ−クライアント間の接続状態をも正確に把握することができ、速やかな接続復旧あるいは接続終了を可能にする。
【００１８】
また、多くのアプリケーションプログラムモジュールが、ソケットの接続を管理しなければならない不必要な作業をなくし、１つのモジュールから構成されたライブラリーを用いて効率的に実現が可能である。これにより、ネットワーク設備間又はサーバクラスターリング環境において相手側の異常な電源オフやモジュールの脱落などのような例外な状況が発生する場合に、いろいろなアプリケーションプログラムで適用可能である。
【００１９】
また、ＴＣＰ接続において再接続や接続解除など速やかに処理されないエラーを簡単に且つ速やかに処理することができる。これにより、サーバ−クライアント間の接続管理を一元化できるシステム管理を実現することができ、システムの信頼性を高めることができる。
【発明を実施するための最良の形態】
【００２０】
以下、添付の図面を参照して、本発明の好適な実施形態を詳細に説明する。ただし、本発明は、下記実施形態に限定されるものではなく、いろいろな変形が可能である。
【００２１】
図２は、本発明の一実施形態によるソケット管理システムを適用するサーバ−クライアントの構成図である。
【００２２】
図２を参照すれば、サーバ１００と複数のクライアント２００、３００、４００、５００とがネットワークを介して接続されている。サーバ１００で実行されているサーバアプリケーションプログラムモジュールと、各クライアント２００、３００、４００、５００で実行されているクライアントアプリケーションプログラムモジュールとは、ソケット通信により接続されている。
【００２３】
サーバ１００で実行されているサーバアプリケーションプログラムモジュールは、各クライアント２００、３００、４００、５００で実行されているクライアントアプリケーションプログラムモジュールとの通信のために必要なソケットを設定し、設定されたソケットの接続状態を周期的にチェックする。
【００２４】
ここで、サーバ１００または各クライアント２００、３００、４００、５００で実行される各アプリケーションプログラムモジュールは、該当アプリケーションプログラムモジュールにプログラミングされたプロセスを行うことによって、多様なサービスを提供する。これにより、アプリケーションプログラムモジュールは、サーバ１００または各クライアント２００、３００、４００、５００で提供するサービスの種類に応じて多様な形態で実現されることができる。
【００２５】
さらに、アプリケーションプログラムモジュールは、サーバ−クライアント基盤の通信プロトコルによって多様なデジタル処理処置で運用される多様な種類のソフトウェアアプリケーションプログラムモジュールを含むことができる。
【００２６】
また、アプリケーションプログラムモジュールは、サーバ−クライアント基盤の通信プロトコルによって運用されることによって、サーバ１００または各クライアント２００、３００、４００、５００で実行される場合に、サーバ１００と各クライアント２００、３００、４００、５００で実行されているアプリケーションプログラムモジュール間の通信のためにソケットを生成し、通信が完了した後には、生成されたソケット接続を解除する一連の動作を行う。
【００２７】
各アプリケーションプログラムモジュールは、サーバ１００と各クライアント２００、３００、４００、５００との間に設定したソケットの接続状態をリアルタイムで把握する必要がある。このために、アプリケーションプログラムモジュールは、ソケットの接続状態をチェックするためにＡＰＩを呼び出して、ＡＰＩにより生成されたソケットチェック実行モジュールを用いてソケットチェック作業を行うようにする。
【００２８】
ここで、各アプリケーションプログラムモジュールは、任意のクライアントとの通信のためにソケットを生成し、生成されたソケットを維持したり解除する手続については、一般的な技術を準用する。従って、以下では、設定された任意のソケットをチェックするためにＡＰＩ（Application Programmable Interface）を呼び出して、ＡＰＩにより生成されたソケットチェック実行モジュールを用いてソケットチェック作業を行う構成及び動作について詳細に説明する。
【００２９】
本実施形態では、サーバ１００と各クライアント２００、３００、４００、５００で実行されているアプリケーションプログラムモジュールが、相互間に設定されたソケットの接続状態をチェックするためのＡＰＩを定義し、各アプリケーションプログラムモジュールでは、上記ＡＰＩを呼び出して、各ソケットに対する接続状態を周期的にチェックする。
【００３０】
これにより、ソケットの接続状態をチェックする機能を提供するためのＡＰＩは、サーバ１００とクライアント２００、３００、４００、５００でそれぞれ使用呼び出し可能なように２元化されている。以下、ＡＰＩのソケット接続状態のチェック機能をヘルスチェック（Ｈｅａｌｔｈ−Ｃｈｅｃｋ）と命名し、略字としてＨＣ（またはｈｃ）を使用する。これにより、ソケット接続状態のチェックのためのあらゆるＡＰＩは、“ｈｃ＿”で始まる。
【００３１】
サーバとクライアントは、各周期毎にソケットの接続状態をチェックするためのメッセージをやりとりする。サーバでは、クライアントに各周期毎にソケットの接続状態をチェックするためのヘルスチェック要請メッセージ（ＨＣ＿ＲＥＱＵＥＳＴ）を伝送し、クライアントは、サーバにヘルスチェック応答メッセージ（ＨＣ＿ＲＥＳＰＯＮＳＥ）を伝送する。
【００３２】
図３は、本発明の一実施形態によるサーバに動作するソケット管理システムの構成図である。
【００３３】
図３を参照すれば、サーバで実行されるソケット管理システムは、クライアントとの通信のために必要なソケットを生成し、該当ソケットの接続状態をチェックするために定義されたＡＰＩ（Application Programmable Interface）を呼び出して、上記生成されたソケットを管理する少なくとも１つ以上のアプリケーションプログラムモジュール１１０と、アプリケーションプログラムモジュール１１０から任意のＡＰＩが呼び出される場合に、呼び出されたＡＰＩに設定された動作を行うためのプログラムがコーディングされた共通ライブラリーモジュール１２０と、共通ライブラリーモジュール１２０にコーディングされたプログラムの実行により生成され、アプリケーションプログラムモジュール１１０により生成されたソケットの接続状態を周期的にチェックするソケットチェック実行モジュール１３０と、ＤＢ（データベース）１４０とを備えて構成される。
【００３４】
アプリケーションプログラムモジュール１１０には、ソケットの接続状態をチェックするために定義されたＡＰＩがエンコードされている。まず、定義されたＡＰＩについて説明する。
【００３５】
サーバ初期化ＡＰＩ（ｈｃ＿ｓｅｒｖｅｒ＿ｉｎｉｔ）１１１は、ヘルスチェックで使用するヘルスチェック機能用スレッド（thread）を生成するＡＰＩである。サーバ初期化ＡＰＩは、アプリケーションプログラム開始部分に加えられる。以下、ヘルスチェック機能用スレッドをソケットチェック実行モジュール１３０と命名する。
【００３６】
サーバ登録ＡＰＩ（ｈｃ＿ｓｅｒｖｅｒ＿ｒｅｇｉｓｔｅｒ）１１２は、ヘルスチェックで任意のソケットに対する接続状態をチェックできるようにソケットを登録するＡＰＩである。サーバ登録ＡＰＩは、アプリケーションプログラムモジュールにおいてサーバ用ソケットをオープンし、クライアントと接続される位置に加えられ、クライアントと接続されたソケットは、登録され、以後、状態を継続的にチェックするようになる。
【００３７】
サーバ登録取消ＡＰＩ（ｈｃ＿ｓｅｒｖｅｒ＿ｕｎｒｅｇｉｓｔｅｒ）１１３は、ヘルスチェックでチェックしていたソケットの登録を取り消すＡＰＩである。サーバ登録取消ＡＰＩ１１３は、正常なソケットの解除時に、アプリケーションプログラムモジュールで使われる。サーバ登録取消ＡＰＩ１１３は、アプリケーションプログラムモジュールにおいてクライアントと接続を解除する位置にコーディングされる。
【００３８】
サーバプロセスＡＰＩ（ｈｃ＿ｓｅｒｖｅｒ＿ｐｒｏｃｅｓｓ）１１４は、サーバに実行されたアプリケーションプログラムモジュールによりソケットの接続状態をチェックするように登録された該当ソケットからデータを伝送された時に、該当データがヘルスチェック用データであるか否かを確認し処理する。サーバプロセスＡＰＩ１１４は、サーバ用であるから、ソケットチェック要請メッセージ（ｈｃ＿ｒｅｑｕｅｓｔ）に対する応答であるソケットチェック応答メッセージ（ｈｃ＿ｒｅｓｐｏｎｓｅ）を受信したときの処理のためのものである。
【００３９】
サーバ解除ＡＰＩ（ｈｃ＿ｓｅｒｖｅｒ＿ｅｘｉｔ）１１５は、登録されていた全てのソケットを登録解除し、ソケットチェック実行モジュール１３０を解除するＡＰＩである。
【００４０】
共通ライブラリーモジュール１２０は、アプリケーションプログラムモジュール１１０から任意のＡＰＩが呼び出される場合に、呼び出された各ＡＰＩに設定された動作を行うためのプログラムがコーディングされている。これにより、共通ライブラリーモジュール１２０は、サーバ初期化ＡＰＩ１１１、サーバ登録ＡＰＩ１１２、サーバ登録取消ＡＰＩ１１３、サーバプロセスＡＰＩ１１４、サーバ解除ＡＰＩ１１５に対応して定義された機能を行うことができるようにコーディングされたそれぞれのプログラムを具備している。
【００４１】
すなわち、アプリケーションプログラムモジュール１１０からサーバ初期化ＡＰＩ（ｈｃ＿ｓｅｒｖｅｒ＿ｉｎｉｔ）１１１が呼び出されると、サーバ初期化ＡＰＩ１１１に対応して定義された機能を行うことができるようにコーディングされたプログラムを実行することによって、ヘルスチェックで使用するソケットチェック実行モジュールを生成し、任意のソケットの接続状態を周期的にチェックする準備をする。
【００４２】
アプリケーションプログラムモジュール１１０からサーバ登録ＡＰＩ（ｈｃ＿ｓｅｒｖｅｒ＿ｒｅｇｉｓｔｅｒ）１１２が呼び出されると、サーバ登録ＡＰＩ１１２に対応して定義された機能を行うことができるようにコーディングされたプログラムを実行することによって、ヘルスチェックで任意のソケットに対する接続状態をチェックできるように、ソケットを所定のソケットチェック実行モジュール１３０に登録する。
【００４３】
アプリケーションプログラムモジュール１１０からサーバ登録取消ＡＰＩ１１３が呼び出されると、サーバ登録取消ＡＰＩ１１３に対応して定義された機能を行うことができるようにコーディングされたプログラムを実行することによって、ソケットチェック実行モジュール１３０でチェックしていたソケットの登録を取り消す。ソケットチェック実行モジュール１３０でソケットの登録を取り消せば、該当ソケットは解除される。
【００４４】
アプリケーションプログラムモジュール１１０からサーバプロセスＡＰＩ（ｈｃ＿ｓｅｒｖｅｒ＿ｐｒｏｃｅｓｓ）１１４が呼び出されると、サーバプロセスＡＰＩ１１４に対応して定義された機能を行うことができるようにコーディングされたプログラムを実行することによって、クライアントから任意のメッセージが伝達される場合、該当メッセージがサーバから該当クライアントへ伝送したヘルスチェック要請メッセージに対するヘルスチェック応答メッセージであるか否かを確認し、それによりクライアントの状態値を変動させる。
【００４５】
アプリケーションプログラムモジュール１１０からサーバ解除ＡＰＩ（ｈｃ＿ｓｅｒｖｅｒ＿ｅｘｉｔ）１１５が呼び出されると、サーバ解除ＡＰＩ１１５に対応して定義された機能を行うことができるようにコーディングされたプログラムを実行することによって、ソケットチェック実行モジュール１３０に該当ソケットの接続状態をチェックするために登録されていた全てのソケットを登録解除し、該当ソケットチェック実行モジュール１３０を解除させる。
【００４６】
アプリケーションプログラムモジュール１１０からサーバ初期化ＡＰＩ１１１を呼び出すことによって、共通ライブラリーモジュール１２０にサーバ初期化ＡＰＩ１１１に対応して定義された機能を行うことができるようにコーディングされたプログラムが実行されて、ソケットチェック実行モジュール１３０が生成される。
【００４７】
ソケットチェック実行モジュール１３０は、各周期毎にアプリケーションプログラムモジュール１１０から指定されたソケットに対して該当ソケットの接続状態をチェックするために、ヘルスチェック要請メッセージを伝送し、それによりクライアントからヘルスチェック応答メッセージが受信されるか否かによって、該当ソケットの接続状態をチェックするようになる。
【００４８】
ＤＢ１４０は、サーバ１００とソケットを生成して通信を行っている各クライアントのＩＤ及びクライアントの状態情報を格納している。
【００４９】
図４は、本発明の一実施形態によるクライアントで動作するソケット管理システムの構成図である。
【００５０】
図４を参照すれば、クライアントで実行されるソケット管理システムは、ソケットの接続状態をチェックするＡＰＩを呼び出すようにプログラミングされた少なくとも１つ以上のアプリケーションプログラムモジュール２１０と、アプリケーションプログラムモジュール２１０から任意のＡＰＩが呼び出される場合、呼び出されたＡＰＩに設定された動作を行うためのプログラムがコーディングされた共通ライブラリーモジュール２２０と、共通ライブラリーモジュール２２０にコーディングされたプログラムの実行により生成され、アプリケーションプログラムモジュール２１０により生成されたソケットの接続状態を周期的にチェックするソケットチェック実行モジュール２３０と、ＤＢ２４０とを備えて構成される。
【００５１】
アプリケーションプログラムモジュール２１０には、ソケットの接続状態をチェックするために定義されたＡＰＩを有している。クライアントで定義されたＡＰＩについて説明する。
【００５２】
クライアントには、クライアント初期化ＡＰＩ２１１と、クライアントプロセスＡＰＩ２１２及びクライアント解除ＡＰＩ２１３が定義されている。
【００５３】
クライアント初期化ＡＰＩ（ｈｃ＿ｃｌｉｅｎｔ＿ｉｎｉｔ）２１１は、ヘルスチェックで使用する変数を初期化するＡＰＩである。クライアント初期化ＡＰＩ２１１は、アプリケーションプログラムモジュールの開始部分にコーディングされる。
【００５４】
クライアントプロセスＡＰＩ（ｈｃ＿ｃｌｉｅｎｔ＿ｐｒｏｃｅｓｓ）２１２は、クライアントに実行されているアプリケーションプログラムモジュール２１０がサーバ１００からデータを伝送された場合に、該当データがヘルスチェック用データであるか否かを確認し処理するＡＰＩである。クライアントに実行されているＡＰＩで、サーバから要請メッセージｈｃ＿ｒｅｑｕｅｓｔを受信した場合の処理のためのものである。
【００５５】
クライアント解除ＡＰＩ（ｈｃ＿ｃｌｉｅｎｔ＿ｅｘｉｔ）２１３は、必要な変数を初期化し、ヘルスチェック動作を終了するＡＰＩである。
【００５６】
共通ライブラリーモジュール２２０は、アプリケーションプログラムモジュール２１０から任意のＡＰＩが呼び出される場合、呼び出された各ＡＰＩに設定された動作を行うためのプログラムがコーディングされている。これにより、共通ライブラリーモジュール２２０は、クライアント初期化ＡＰＩ２１１、クライアントプロセスＡＰＩ２１２、クライアント解除ＡＰＩ２１３に対応して定義された機能を行うことができるようにコーディングされたそれぞれのプログラムを具備している。
【００５７】
すなわち、アプリケーションプログラムモジュール２１０からクライアント初期化ＡＰＩ（ｈｃ＿ｃｌｉｅｎｔ＿ｉｎｉｔ）２１１が呼び出されると、クライアント初期化ＡＰＩ２１１に対応して定義された機能を行うことができるようにコーディングされたプログラムを実行して、ソケットチェックのための初期化を行い、ソケットチェック実行モジュール２３０を生成することによって、サーバと設定されたソケットの接続状態を周期的にチェックする準備をする。
【００５８】
アプリケーションプログラムモジュール２１０からクライアントプロセスＡＰＩ２１２が呼び出されると、クライアントプロセスＡＰＩ２１２に対応して定義された機能を行うことができるようにコーディングされたプログラムを実行することによって、クライアントに実行されているアプリケーションプログラムモジュール２１０がサーバ１００からメッセージを伝送された場合に、該当メッセージがヘルスチェック要請メッセージ（ＨＣ＿ＲＥＱＵＥＳＴ）であるか否かを判断する。
【００５９】
アプリケーションプログラムモジュール２１０からクライアント解除ＡＰＩ２１３が呼び出されると、クライアント解除ＡＰＩ２１３に対応して定義された機能を行うことができるようにコーディングされたプログラムを実行することによって、ヘルスチェック動作を解除し、該当ソケットチェック実行モジュール２３０を終了する動作を行う。
【００６０】
アプリケーションプログラムモジュール２１０からサーバ初期化ＡＰＩ２１１を呼び出すことによって、共通ライブラリーモジュール２２０にサーバ初期化ＡＰＩ２１１に対応して定義された機能を行うことができるようにコーディングされたプログラムが実行されて、ソケットチェック実行モジュール２３０が生成される。
【００６１】
ソケットチェック実行モジュール２３０は、各周期毎にアプリケーションプログラムモジュール２１０から指定されたソケットに対して該当ソケットの接続状態をチェックするために伝送されるヘルスチェック要請メッセージを受信すれば、それにより、サーバにヘルスチェック応答メッセージを伝送することによって、サーバからヘルスチェック応答メッセージが受信されるか否かによって、該当ソケットの接続状態をチェックできるようにする。
【００６２】
ＤＢ２４０は、サーバ１００と設定されたソケットを維持するためのサーバ１００に対するソケット設定情報を格納している。
【００６３】
図５は、本発明の一実施形態によるソケット接続状態のチェックのためのメッセージ（ＨＣメッセージ）の構成図である。
【００６４】
図５を参照すれば、ヘルスチェックメッセージのヘッダーは、マジックナンバーフィールド（Ｍａｇｉｃ  Ｎｕｍｂｅｒ）と、メッセージタイプフィールド（Ｍｅｓｓａｇｅ  Ｔｙｐｅ）と、クライアントＩＤフィールド（Ｃｌｉｅｎｔ  ＩＤ）と、パケット長さフィールド（Ｌｅｎｇｔｈ）とから構成され、ボディーは、タイムスタンプフィールド（Ｔｉｍｅｓｔａｍｐ）と、タイムアウト値フィールド（Ｔｉｍｅｏｕｔ  Ｖａｌｕｅ）と、予備フィールド（Ｒｅｓｅｒｖｅｄ）とから構成される。
【００６５】
マジックナンバーフィールドと、メッセージタイプフィールドと、クライアントＩＤフィールド、及びパケット長さフィールドは、各々２バイトずつ割り当てられている。
【００６６】
マジックナンバーフィールドに設定される値は、ソケットの接続状態をチェックするためのマジックナンバーであり、該当メッセージがヘルスチェックメッセージであるか否かを判別するために特定値が設定され、ここではサーバのシステム時間値が設定される。
【００６７】
メッセージタイプフィールドには、該当メッセージがヘルスチェック要請メッセージなのか、又はヘルスチェック応答メッセージなのかを表示するための値が設定される。
【００６８】
クライアントＩＤフィールドは、サーバとソケット接続が設定されたクライアントＩＤの識別子が設定され、各クライアントを区別する。
【００６９】
パケット長さフィールドは、該当パケットの伝送エラーをチェックするために、メッセージの長さが設定される。
【００７０】
タイムスタンプフィールドには、該当パケットが伝送される時間情報が設定される。タイムスタンプ値は、サーバとクライアント間にメッセージを送受信する場合、正常に動作するか否かを確認するために、サーバで現在時間をタイムスタンプフィールドに設定して、クライアントに伝送し、クライアントはこの値をそのままヘルスチェック応答メッセージ（ＨＣ＿ＲＥＳＰＯＮＳＥ）に設定してサーバに伝送する。サーバでは、この値が正確にクライアントから来るか否かをチェックして、クライアントの状態を判断する。
【００７１】
タイムアウト値フィールドは、サーバからクライアントにヘルスチェック要請メッセージを伝送した後から時間をカウントして、一定時間が経過するまでヘルスチェック応答メッセージが受信されないと、該当ソケットの接続状態が遮断されたものと判断し、ソケットを強制的に遮断するためのタイムアウト設定値である。
【００７２】
サーバの伝送周期Ｔｓが変化すれば、クライアントの待ち周期Ｔｃも変わらなければならないので、Ｔｃ値が変化する場合、タイムアウト値を設定して伝送する。このとき、Ｔｃは、Ｔｓ＋αの値を有することが好適である。ここで、αは、ユーザにより設定される余裕値である。
【００７３】
一方、サーバ１００で各クライアントを管理するためには、クライアントの状態情報を格納していなければならない。これにより、サーバ１００では、登録されたクライアントのソケット毎に配列あるいは接続リスト（linked list）形態でＤＢ１４０を構成し、クライアントＩＤ（ｃｌｉｅｎｔ  ＩＤ）、クライアントソケット（ｃｌｉｅｎｔ  ｓｏｃｋｅｔ）、クライアント状態（ｃｌｉｅｎｔ  ｓｔａｔｕｓ）を格納する。
【００７４】
クライアントの状態は、図６に示すように、３つの状態を有することができる。
【００７５】
最初には、終了状態（ＨＣ＿ＳＴ＿ＣＬＯＳＥＤ）で任意のソケットがソケットチェックのためにソケットチェック実行モジュール１３０に登録されれば、状態が正常状態（ＨＣ＿ＳＴ＿ＮＯＲＭＡＬ）に変化し、サーバのソケットチェック実行モジュール１３０から該当クライアント２００にヘルスチェック要請メッセージ（ＨＣ＿ＲＥＱＵＥＳＴ）を伝送すれば、伝送状態（ＨＣ＿ＳＴ＿ＳＥＮＤ）となる。ここで、クライアント２００からヘルスチェック応答メッセージを受信すれば、状態が再び正常状態（ＨＣ＿ＳＴ＿ＮＯＲＭＡＬ）に変化する。サーバ１００では、ヘルスチェック要請メッセージ（ＨＣ＿ＲＥＱＵＥＳＴ）を伝送し、次回のチェック時に、このクライアント２００の状態をチェックする。
【００７６】
これにより、サーバ１００からヘルスチェック要請メッセージを受信したクライアントは、サーバ１００にヘルスチェック応答メッセージを伝送するようになり、サーバ１００では、ヘルスチェック応答メッセージが受信されたか否かによって該当クライアントの状態を判断し、ＤＢ１４０に該当クライアントの状態を設定する。
【００７７】
サーバ１００で実行されているアプリケーションプログラムモジュール１１０では、クライアントから任意のメッセージが受信されれば、サーバプロセスＡＰＩ１１４を呼び出す。サーバプロセスＡＰＩ１１４が呼び出されれば、共通ライブラリーモジュール１２０にコーディングされたプログラムが実行されることによって、クライアントから受信された該当メッセージがヘルスチェック応答メッセージであるか否かを判断する。この判断の結果、ヘルスチェック応答メッセージである場合、該当クライアントの状態値を正常状態（ＨＣ＿ＳＴ＿ＮＯＲＭＡＬ）に設定する。
【００７８】
正常状態（ＨＣ＿ＳＴ＿ＮＯＲＭＡＬ）なら、正常にヘルスチェック応答メッセージを受信した場合であるが、伝送状態（ＨＣ＿ＳＴ＿ＳＥＮＴ）に残っているなら、無応答（No response）である場合である。
【００７９】
図７は、本発明の一実施形態によるソケット管理システムを適用してサーバでソケットの管理を説明するフローチャートである。
【００８０】
図７を参照すれば、サーバで任意のアプリケーションプログラムモジュールが実行されると、アプリケーションプログラムにより、設定されたクライアントとソケットを形成する手続を行うとともに、該当ソケットの接続状態をチェックするために、アプリケーションプログラムモジュールにコーディングされたＡＰＩを呼び出す（ステップ１００。なお図中ではステップをＳと略す。以下同じ。）。アプリケーションプログラムモジュール１１０によりＡＰＩが呼び出されると、共通ライブラリーモジュール１２０では、呼び出されたＡＰＩに対応して定義されたプログラムを実行して、ソケットの接続状態を周期的にチェックするためのソケットチェック実行モジュール１３０を生成する（ステップ２００）。
【００８１】
アプリケーションプログラムモジュール１１０は、任意のクライアントとソケットを生成した後、ソケットの接続状態を周期的にチェックするために、ソケットチェック実行モジュール１３０に該当ソケットを登録するためのＡＰＩを呼び出す。これにより、共通ライブラリーモジュール１２０では、該当ＡＰＩに対応して定義されたプログラムを実行して、任意のソケットに対するヘルスチェックのために、該当ソケットをソケットチェック実行モジュール１３０に登録する（ステップ３００）。
【００８２】
ソケットチェック実行モジュール１３０では、登録されたソケットの接続状態を周期的にチェックする（ステップ４００）。
【００８３】
図８は、本発明の一実施形態によるサーバでのソケットチェック実行モジュールの動作を示すフローチャートである。
【００８４】
図８を参照すれば、サーバ１００で一旦生成されたソケットチェック実行モジュール１３０は、ソケットの接続状態を周期的にチェックすべきソケットを登録され、設定された手続によってヘルスチェックを周期的に行う（ステップ４１０）。
【００８５】
一回のヘルスチェック動作が行われると、ソケットチェック実行モジュール１３０では、現在の時間情報を獲得し（ステップ４２０）、ヘルスチェックリストに登録されたソケットを有しているクライアントに伝送するヘルスチェック要請メッセージ（ＨＣ＿ＲＥＱＵＥＳＴ）を生成する（ステップ４３０）。この際、生成されるヘルスチェック要請メッセージのヘッダーには、該当ソケットが設定されているクライアントのＩＤと、現在の時間情報及びタイムアウト値が設定される。
【００８６】
ソケットチェック実行モジュール１３０は、生成されたヘルスチェック要請メッセージ（ＨＣ＿ＲＥＱＵＥＳＴ）を、ソケットを設定している該当クライアントに伝送する（ステップ４４０）。
【００８７】
図９は、本発明の一実施形態によるサーバのソケットチェック実行モジュールが登録されたソケットの接続状態を周期的にチェックする動作を示すフローチャートである。
【００８８】
図９を参照すれば、ソケットチェック実行モジュール１３０は、ＤＢ１４０に設定された該当クライアントの状態値を読み取り（ステップ４１１）、クライアントの状態値が無応答状態であるか否かを判断する（ステップ４１２）。クライアントの状態が正常状態（ＨＣ＿ＳＴ＿ＮＯＲＭＡＬ）なら、正常にメッセージを受信した場合であるが、伝送状態（ＨＣ＿ＳＴ＿ＳＥＮＴ）のままであるなら、無応答（Ｎｏ  ｒｅｓｐｏｎｓｅ）である場合だと判断できる。
【００８９】
この判断の結果、無応答である場合には、第１のカウント値を増加させる（ステップ４１３）。そして、第１のカウント値が、所定の第１の許容回数Ｎｓを超過するか否かを判断する（ステップ４１４）。ここで、第１の許容回数Ｎｓは、サーバ１００で応答のないクライアント２００、３００を待つ最大回数を意味する。
【００９０】
この判断の結果、第１のカウント値が、所定の第１の許容回数Ｎｓを超過する場合には、該当クライアント２００、３００とのソケット接続を解除する（ステップ４１５）。
【００９１】
一方、クライアント２００、３００の状態値が無応答状態であるか否かを判断した結果、無応答でない場合には、間違った応答であるか否かを判断する（ステップ４１６）。この判断の結果、応答はあるが、マジック値が異なるクライアント２００、３００が、間違いを有している場合には、第２のカウント値を増加させる（ステップ４１７）。そして、上記第２のカウント値が、所定の第２の許容回数Ｎｓ＿ｗを超過するか否かを判断する（ステップ４１８）。ここで、第２の許容回数Ｎｓ＿ｗは、サーバ１００が、マジック値が異なるクライアント２００、３００からの間違いを有する連続的な応答を待つ最大回数を意味する。
【００９２】
この判断の結果、第２のカウント値が所定の第２の許容回数Ｎｓ＿ｗを超過する場合には、ログ（ｌｏｇ）やタイムアウト（ｔｉｍｅｏｕｔ）値を調整する（ステップ４１９）。
【００９３】
図１０は、本発明の一実施形態によるクライアントのソケットチェック実行モジュールがソケットをチェックするときに行う動作を示すフローチャートである。
【００９４】
図１０を参照すれば、クライアントのソケットチェック実行モジュール２３０は、受信周期のタイムアウト前に、サーバ１００からヘルスチェック要請メッセージ（ＨＣ＿ＲＥＱＵＥＳＴ）が受信されたか否かを判断する（ステップ５１０）。この判断の結果、ヘルスチェック要請メッセージ（ＨＣ＿ＲＥＱＵＥＳＴ）が受信された場合、それに対するヘルスチェック応答メッセージ（ＨＣ＿ＲＥＳＰＯＮＳＥ）をサーバ１００に伝送する（ステップ５２０）。
【００９５】
ソケットチェック実行モジュール２３０は、ヘルスチェック応答メッセージ（ＨＣ＿ＲＥＳＰＯＮＳＥ）をサーバ１００に伝送した場合には、受信周期カウンタ（図示せず）を初期化した後（ステップ５３０）、受信周期を新しくカウントする（ステップ５４０）。
【００９６】
一方、この判断の結果、受信周期のタイムアウト前に、ヘルスチェック要請メッセージ（ＨＣ＿ＲＥＱＵＥＳＴ）が受信されずに、受信周期のタイムアウトを超過した場合、タイムアウトが超過した回数をカウントするカウント値を増加させ（ステップ５５０）、このカウント値が許容回数を超過するか否かを判断する（ステップ５６０）。この判断の結果、該当カウント値が許容回数を超過しない場合には、受信周期カウンタを初期化し（ステップ５３０）、受信周期をカウントする（ステップ５４０）手続を行い、この判断の結果、該当カウント値が許容回数を超過する場合には、ソケット接続を解除する（ステップ５７０）。
【００９７】
図１１は、本発明の一実施形態によるサーバとクライアント間のヘルスチェックメッセージ伝送のフローチャートである。
【００９８】
ソケットのヘルスチェック機能は、サーバ１００とクライアント２００、３００間の周期的なヘルスチェックデータと両方のタイマーを用いて実現される。サーバ１００では、ヘルスチェック要請メッセージ（ＨＣ＿ＲＥＱＵＥＳＴ）を伝送し、クライアント２００、３００では、これに対する応答としてヘルスチェック応答メッセージ（ＨＣ＿ＲＥＳＰＯＮＳＥ）を伝送する。
【００９９】
ここで、Ｔｓは、サーバ１００からクライアントら２００、３００にヘルスチェック要請メッセージ（ＨＣ＿ＲＥＱＵＥＳＴ）を伝送する周期であって、Ｔｓタイムアウトが起こると、クライアント状態をチェックし、正常なクライアントにヘルスチェック要請メッセージ（ＨＣ＿ＲＥＱＵＥＳＴ）を伝送する。
【０１００】
図１１を参照すれば、第１のクライアント２００は、サーバ１００にソケット設定メッセージを伝送して、接続を試みる。これにより、サーバ１００は、第１のクライアント２００に接続を設定し、接続承認メッセージを伝送する。これにより、第１のクライアント２００とサーバ１００との間に１つのソケットが設定される。
【０１０１】
一方、第２のクライアント３００も、サーバ１００にソケット設定メッセージを伝送して、接続を試みる。これにより、サーバ１００は、第２のクライアント３００に接続を設定し、接続承認メッセージを伝送する。これにより、第２のクライアント３００とサーバ１００との間に１つのソケットが設定される。
【０１０２】
サーバ１００は、第１のクライアント２００及び第２のクライアント３００と各々ソケットを設定した後、一定周期毎に第１のクライアント２００及び第２のクライアント３００にソケットの接続状態をチェックするためのヘルスチェック要請メッセージ（ＨＣ＿ＲＥＱＵＥＳＴ）を各々伝送する。
【０１０３】
サーバ１００からヘルスチェック要請メッセージ（ＨＣ＿ＲＥＱＵＥＳＴ）を受信した第１のクライアント２００及び第２のクライアント３００は、サーバ１００にヘルスチェック応答メッセージ（ＨＣ＿ＲＥＳＰＯＮＳＥ）を伝送する。
【０１０４】
第１のクライアント２００及び第２のクライアント３００からヘルスチェック応答メッセージ（ＨＣ＿ＲＥＳＰＯＮＳＥ）を受信したサーバ１００は、ヘルスチェック要請メッセージ（ＨＣ＿ＲＥＱＵＥＳＴ）を伝送する時間になれば、第１のクライアント２００及び第２のクライアント３００にヘルスチェック要請メッセージ（ＨＣ＿ＲＥＱＵＥＳＴ）を伝送する。この際、伝送されるヘルスチェック要請メッセージ（ＨＣ＿ＲＥＱＵＥＳＴ）は、以前に伝送されたヘルスチェック要請メッセージ（ＨＣ＿ＲＥＱＵＥＳＴ）とマジックナンバー値が互いに異なるように設定される。
【０１０５】
同様に、サーバ１００からヘルスチェック要請メッセージ（ＨＣ＿ＲＥＱＵＥＳＴ）を受信した第１のクライアント２００及び第２のクライアントは、サーバ１００にヘルスチェック応答メッセージ（ＨＣ＿ＲＥＳＰＯＮＳＥ）を伝送する。
【０１０６】
図１２は、本発明の一実施形態によるヘルスチェックメッセージを用いたクライアント障害発見及び処理のフローチャートである。
【０１０７】
ここで、Ｔｓは、サーバ１００からクライアント２００、３００にヘルスチェック要請メッセージ（ＨＣ＿ＲＥＱＵＥＳＴ）を伝送する周期であって、第１の許容回数Ｎｓは、サーバ１００で応答のないクライアント２００、３００を待つ最大回数である。すなわち、Ｔｓ＊Ｎｓ時間のあいだクライアントから応答メッセージがなければ、サーバで接続を解除するのに使われる変数である。
【０１０８】
図１２を参照すれば、サーバ１００は、第１のクライアント２００及び第２のクライアント３００と各々ソケットを設定した後、一定周期毎に第１のクライアント２００及び第２のクライアント３００にソケットの接続状態をチェックするためのヘルスチェック要請メッセージ（ＨＣ＿ＲＥＱＵＥＳＴ）を各々伝送する。
【０１０９】
サーバ１００からヘルスチェック要請メッセージ（ＨＣ＿ＲＥＱＵＥＳＴ）を受信した第１のクライアント２００及び第２のクライアント３００は、サーバ１００にヘルスチェック応答メッセージ（ＨＣ＿ＲＥＳＰＯＮＳＥ）を伝送する。
【０１１０】
第１のクライアント２００及び第２のクライアント３００からヘルスチェック応答メッセージ（ＨＣ＿ＲＥＳＰＯＮＳＥ）を受信したサーバ１００は、ヘルスチェック要請メッセージ（ＨＣ＿ＲＥＱＵＥＳＴ）を伝送する時間になれば、第１のクライアント２００及び第２のクライアント３００にヘルスチェック要請メッセージ（ＨＣ＿ＲＥＱＵＥＳＴ）を伝送する。この際、伝送されるヘルスチェック要請メッセージ（ＨＣ＿ＲＥＱＵＥＳＴ）は、以前に伝送されたヘルスチェック要請メッセージ（ＨＣ＿ＲＥＱＵＥＳＴ）とマジックナンバー値が互い異なるように設定される。
【０１１１】
同様に、サーバ１００からヘルスチェック要請メッセージ（ＨＣ＿ＲＥＱＵＥＳＴ）を受信した第１のクライアント２００は、サーバ１００にヘルスチェック応答メッセージ（ＨＣ＿ＲＥＳＰＯＮＳＥ）を伝送する。
【０１１２】
一方、第２のクライアント３００で障害が発生した場合、第２のクライアント３００は、サーバ１００にヘルスチェック応答メッセージ（ＨＣ＿ＲＥＳＰＯＮＳＥ）を送ることができない。クライアント障害には、例えば、クライアントの電源オフのようなエラーがあり得る。
【０１１３】
サーバ１００は、ヘルスチェック要請メッセージ（ＨＣ＿ＲＥＱＵＥＳＴ）を伝送する時間になれば、第１のクライアント２００及び第２のクライアント３００にヘルスチェック要請メッセージ（ＨＣ＿ＲＥＱＵＥＳＴ）を伝送する。この際、伝送されるヘルスチェック要請メッセージ（ＨＣ＿ＲＥＱＵＥＳＴ）は、以前に伝送されたヘルスチェック要請メッセージ（ＨＣ＿ＲＥＱＵＥＳＴ）とマジックナンバー値が互いに異なるように設定される。
【０１１４】
同様に、サーバ１００からヘルスチェック要請メッセージ（ＨＣ＿ＲＥＱＵＥＳＴ）を受信した第１のクライアント２００は、サーバ１００にヘルスチェック応答メッセージ（ＨＣ＿ＲＥＳＰＯＮＳＥ）を伝送する。
【０１１５】
一方、第２のクライアント３００は、未だ障害が解決されていない状態であるから、サーバ１００にヘルスチェック応答メッセージ（ＨＣ＿ＲＥＳＰＯＮＳＥ）を送ることができない。
【０１１６】
サーバ１００は、ヘルスチェック要請メッセージ（ＨＣ＿ＲＥＱＵＥＳＴ）を伝送する時間になれば、第１のクライアント２００に対してはマジックナンバー値を異に設定して、ヘルスチェック要請メッセージ（ＨＣ＿ＲＥＱＵＥＳＴ）を伝送する。
【０１１７】
しかしながら、サーバ１００は、第２のクライアント３００に対しては第２のクライアント３００から受信されるべきヘルスチェック応答メッセージが受信されない回数が、所定の回数Ｎｓを超過する場合に、第２のクライアント３００と設定したソケットの接続を解除する。
【０１１８】
図１３は、本実施形態によるヘルスチェックメッセージを用いたサーバの障害発見及び処理の流れを示すフローチャートである。
【０１１９】
ここで、Ｔｃは、クライアント２００、３００からヘルスチェック要請メッセージ（ＨＣ＿ＲＥＱＵＥＳＴ）を受信した後、次回のヘルスチェック要請メッセージ（ＨＣ＿ＲＥＱＵＥＳＴ）を受信するまで待つタイマーの周期である。
【０１２０】
Ｎｃは、サーバ１００からヘルスチェック要請メッセージ（ＨＣ＿ＲＥＱＵＥＳＴ）を送らない場合、クライアント２００、３００が待つ最大回数であって、Ｔｃ＊Ｎｃ時間のあいだサーバの応答がなければ、設定されたソケットの接続を解除する。
【０１２１】
図１３を参照すれば、サーバ１００からヘルスチェック要請メッセージ（ＨＣ＿ＲＥＱＵＥＳＴ）を第１のクライアント２００及び第２のクライアント２００に伝送する。これにより、第１のクライアント２００及び第２のクライアント３００は、それに対するヘルスチェック応答メッセージ（ＨＣ＿ＲＥＳＰＯＮＳＥ）をサーバ１００に伝送する。
【０１２２】
サーバ１００では、所定の周期毎にヘルスチェック要請メッセージを第１のクライアント２００及び第２のクライアント３００に伝送するようになるが、サーバ１００に障害が発生した場合には、これ以上ヘルスチェック要請メッセージを伝送することができない。
【０１２３】
サーバ障害には、例えば、サーバの電源オフのようなエラーがあり得る。この場合、クライアントが再接続を要求すべきかは、アプリケーションプログラムによって異なることができるので、オプションとして処理する。
【０１２４】
第１のクライアント２００及び第２のクライアント３００は、サーバ１００にヘルスチェック応答メッセージを伝送した後、サーバ１００からヘルスチェック要請メッセージが受信されるか否かをチェックする。
【０１２５】
さらに、第１のクライアント２００及び第２のクライアント３００は、これらがサーバ１００にヘルスチェック応答メッセージを伝送した後、経過した時間をチェックして、伝送周期Ｔｃタイムアウトを経過した回数が、所定の回数Ｎｃを超過する場合、サーバ１００と維持していたソケットの接続を解除する。
【０１２６】
そして、第１のクライアント２００及び第２のクライアント３００は、サーバ１００に新しいソケットを設定するために、新しい接続を試みる。
【図面の簡単な説明】
【０１２７】
【図１】従来の接続指向ソケットを利用したときのエラーを示すフローチャートである。
【図２】本発明の一実施形態によるソケット管理システムを適用するサーバ―クライアントの構成図である。
【図３】本発明の一実施形態によるサーバで動作するソケット管理システムの構成図である。
【図４】本発明の一実施形態によるクライアントで動作するソケット管理システムの構成図である。
【図５】本発明の一実施形態によるソケット接続状態のチェックのためのメッセージ（ＨＣメッセージ）の構成図である。
【図６】クライアントの状態図である。
【図７】本発明の一実施形態によるソケット管理システムを適用して、サーバでソケットを管理する流れを示すフローチャートである。
【図８】本発明の一実施形態によるサーバでのソケットチェック実行モジュールの動作を示すフローチャートである。
【図９】本発明の一実施形態によるサーバのソケットチェック実行モジュールが登録されたソケットの接続状態を周期的にチェックする動作を示すフローチャートである。
【図１０】本発明の一実施形態によるクライアントのソケットチェック実行モジュールがソケットをチェックするときに行う動作を示すフローチャートである。
【図１１】本発明の一実施形態によるサーバとクライアント間のヘルスチェックメッセージ伝送のフローチャートである。
【図１２】本発明の一実施形態によるヘルスチェックメッセージを用いたクライアント障害発見及び処理のフローチャートである。
【図１３】本発明の一実施形態によるヘルスチェックメッセージを用いたサーバの障害発見及び処理のフローチャートである。
【符号の説明】
【０１２８】
１００  サーバ
２００  クライアント１
３００  クライアント２
４００  クライアント３
５００  クライアント４
１１０  アプリケーションプログラムモジュール
１２０  共通ライブラリーモジュール
１３０  ソケットチェック実行モジュール
２１０  アプリケーションプログラムモジュール
２２０  共通ライブラリーモジュール
２３０  ソケットチェック実行モジュール
【図１】
2006031685.tif 000003
【図２】
2006031685.tif 000004
【図３】
2006031685.tif 000005
【図４】
2006031685.tif 000006
【図５】
2006031685.tif 000007
【図６】
2006031685.tif 000008
【図７】
2006031685.tif 000009
【図８】
2006031685.tif 000010
【図９】
2006031685.tif 000011
【図１０】
2006031685.tif 000012
【図１１】
2006031685.tif 000013
【図１２】
2006031685.tif 000014
【図１３】
2006031685.tif 000015