(57)【特許請求の範囲】
【請求項１】
クライアント内のクライアント・プロセスと、前記クライアントに接続されたサーバ内のサーバ・プロセスとの間のサービス接続をモニタする方法であって、前記クライアント・プロセスは、クライアント・ライブラリと、該クライアント・ライブラリを制御するシングル・スレッドのクライアント・コードとを含み、
前記クライアントが、
クライアント・プロセスのクライアント・コードのアクティビティを前記クライアント・プロセスのクライアント・ライブラリによってモニタするステップであって、前記クライアント・ライブラリによってモニタするステップは、前記サーバ・プロセスへの前記サービス接続を前記クライアント・ライブラリによって開くステップと、前記クライアント・コードに障害が発生していないことを表すpingメッセージを、前記サービス接続を介して前記クライアント・ライブラリによって前記サーバ・プロセスに定期的に送信するステップとを含む、前記クライアント・ライブラリによってモニタするステップを実行し、
前記サーバが、
サーバ・プロセスへのサービス接続を介して前記クライアント・ライブラリのアクティビティを前記サーバ・プロセスによってモニタするステップであって、前記サーバ・プロセスによってモニタするステップは、前記クライアント・プロセスが接続するのを待ち、そしてクライアント接続を確立するステップと、前記サーバ・プロセスによって、そのリソースのうち１つ又は複数をクライアント・プロセスに与えるステップと、前記クライアント・ライブラリからの前記pingメッセージを待つステップと、サーバping許容度の間隔内に前記サービス接続を介して前記pingメッセージが受信されたかどうかを判定するステップと、前記サーバ・プロセスにおいて、前記pingメッセージが受信された場合、次のpingメッセージを待つステップと、前記pingメッセージが受信されない場合に、前記クライアント・プロセスとサーバ・プロセス間の前記サービス接続を終了し、前記サービス接続の終了に続いて前記サーバ・プロセスにおいてクライアント・リソースの制御権を回復するステップを含み、前記サービス接続上の前記クライアント・ライブラリの前記アクティビティが、前記クライアント・コードでのアクティビティを示す、前記サーバ・プロセスによってモニタするステップと
を実行する方法。
【請求項２】
前記クライアント・コードのアクティビティを前記クライアント・ライブラリによってモニタする前記ステップが、ベース・タイムアウト値（ＢＴＯ）にネットワーク信頼性値（ＮＲ）を掛けてクライアントping間隔（ＣＰＩ）を決定するステップと、前記サーバ・プロセスへの最終のpingメッセージ以降の時間間隔が前記ＣＰＩを超えたとき、前記クライアント・コードにおけるモニタされたアクティビティを示すpingメッセージを前記サービス接続を介して前記サーバ・プロセスに定期的に送信するために前記ＣＰＩを使用するステップと
をさらに含む、請求項１に記載の方法。
【請求項３】
前記クライアント・ライブラリのアクティビティを前記サーバ・プロセスによってモニタする前記ステップが、ＢＴＯ＋ＣＰＩで定義されるサーバping許容度（ＳＰＴ）の間隔内に前記サービス接続を介してpingメッセージが受信されたかどうかを判定するステップを含み、前記サーバ・プロセスにおいて、pingメッセージが受信された場合、次のpingメッセージを待つステップと、pingメッセージが受信されない場合に前記クライアント・プロセスとサーバ・プロセス間の前記サービス接続を終了するステップとを含む、請求項２に記載の方法。
【請求項４】
前記クライアント・コードのアクティビティを前記クライアント・ライブラリによってモニタする前記ステップが、前記クライアント・コードから前記クライアント・ライブラリに制御が転送されたときに現在の時刻（ＣＴ）を決定するステップと、最終のpingメッセージが前記サーバ・プロセスに送信された時刻（Ｔ）をＣＴから差し引くことによって前記最終のpingメッセージが前記サーバ・プロセスに送信されてからの前記時間間隔を決定するステップとを含み、前記使用するステップが、ＣＴ−Ｔ>ＣＰＩかどうかを判定するステップを含み、前記クライアント・ライブラリによって、ＣＴ−Ｔ>ＣＰＩである場合、pingメッセージをサーバ・プロセスに送信するステップと、ＣＴ−Ｔ>ＣＰＩでない場合、制御をクライアント・コードに返すステップとを含む、請求項２に記載の方法。
【請求項５】
前記クライアント・コードのアクティビティを前記クライアント・ライブラリによってモニタする前記ステップが、前記pingメッセージが前記サービス接続を介して前記サーバ・プロセスに送信されたときに現在の時刻と等しい時刻Ｔを設定するステップと、次いで前記クライアント・コードに制御を返すステップとをさらに含む、請求項４に記載の方法。
【請求項６】
クライアント内のクライアント・プロセスと、前記クライアントに接続されたサーバ内のサーバ・プロセスとの間のサービス接続をモニタするためのシステムであって、前記クライアント・プロセスは、クライアント・ライブラリと、該クライアント・ライブラリを制御するシングル・スレッドのクライアント・コードとを含み、
前記クライアントが、
クライアント・プロセスのクライアント・コードのアクティビティを前記クライアント・プロセスのクライアント・ライブラリによってモニタするための手段であって、前記クライアント・ライブラリによってモニタする手段は、前記サーバ・プロセスへの前記サービス接続を前記クライアント・ライブラリによって開く手段と、前記クライアント・コードに障害が発生していないことを表すpingメッセージを、前記サービス接続を介して前記クライアント・ライブラリによって前記サーバ・プロセスに定期的に送信する手段とを含む、前記クライアント・ライブラリによってモニタする手段を含み、
前記サーバが、
サーバ・プロセスへのサービス接続を介して前記クライアント・ライブラリのアクティビティを前記サーバ・プロセスによってモニタするための手段であって、前記サーバ・プロセスによってモニタする手段は、前記クライアント・プロセスが接続するのを待ち、そしてクライアント接続を確立する手段と、前記サーバ・プロセスによって、そのリソースのうち１つ又は複数をクライアント・プロセスに与える手段と、前記クライアント・ライブラリからの前記pingメッセージを待つ手段と、サーバping許容度の間隔内に前記サービス接続を介して前記pingメッセージが受信されたかどうかを判定する手段と、前記サーバ・プロセスにおいて、前記pingメッセージが受信された場合、次のpingメッセージを待つ手段と、前記pingメッセージが受信されない場合に、前記クライアント・プロセスとサーバ・プロセス間の前記サービス接続を終了し、前記サービス接続の終了に続いて前記サーバ・プロセスにおいてクライアント・リソースの制御権を回復する手段を含み、前記サービス接続上のクライアント・ライブラリの前記アクティビティが、前記クライアント・コードでのアクティビティを示す、前記サーバ・プロセスによってモニタするための手段を含む、
システム。
【請求項７】
前記クライアント・コードのアクティビティを前記クライアント・ライブラリによってモニタするための前記手段が、ベース・タイムアウト値（ＢＴＯ）にネットワーク信頼性値（ＮＲ）を掛けてクライアントping間隔（ＣＰＩ）を決定するための手段と、前記サーバ・プロセスへの最終のpingメッセージ以降の時間間隔が前記ＣＰＩを超えたとき、前記クライアント・コードにおけるモニタされたアクティビティを示すpingメッセージを前記サービス接続を介して前記サーバ・プロセスに定期的に送信するために前記ＣＰＩを使用するための手段と
をさらに含む、請求項６に記載のシステム。
【請求項８】
前記クライアント・ライブラリのアクティビティを前記サーバ・プロセスによってモニタするための前記手段が、ＢＴＯ＋ＣＰＩで定義されるサーバping許容度（ＳＰＴ）の間隔内に前記サービス接続を介してpingメッセージが受信されたかどうかを判定するための手段を含み、前記サーバ・プロセスにおいて、pingメッセージが受信された場合、次のpingメッセージを待つ手段と、pingメッセージが受信されない場合に前記クライアント・プロセスとサーバ・プロセス間の前記サービス接続を終了する手段とを含む、請求項７に記載のシステム。
【請求項９】
前記クライアント・コードのアクティビティを前記クライアント・ライブラリによってモニタするための前記手段が、前記クライアント・コードから前記クライアント・ライブラリに制御が転送されたときに現在の時刻（ＣＴ）を決定するための手段と、最終のpingメッセージが前記サーバ・プロセスに送信された時刻（Ｔ）をＣＴから差し引くことによって前記最終のpingメッセージが前記サーバ・プロセスに送信されてからの前記時間間隔を決定するための手段とを含み、前記使用するための手段が、ＣＴ−Ｔ>ＣＰＩかどうかを判定するための手段を含み、前記クライアント・ライブラリによって、ＣＴ−Ｔ>ＣＰＩである場合、pingメッセージをサーバ・プロセスに送信する手段と、ＣＴ−Ｔ>ＣＰＩでない場合、制御をクライアント・コードに返す手段とを含む、請求項７に記載のシステム。
【請求項１０】
前記クライアント・コードのアクティビティを前記クライアント・ライブラリによってモニタするための前記手段が、前記pingメッセージが前記サービス接続を介して前記サーバ・プロセスに送信されたときに現在の時刻と等しい時刻Ｔを設定するための手段と、次いで前記クライアント・コードに制御を返すための手段とをさらに含む、請求項９に記載のシステム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、一般にはコンピュータ・ネットワークに関し、詳細にはクライアント・プロセスがサーバ・プロセスへのサービス接続を有するクライアント／サーバ・ネットワーク・アーキテクチャに関する。より詳細には、サーバ・プロセスへの１つまたは複数のサービス接続をモニタし管理するための機能に関する。
【０００２】
【従来の技術】
ライブラリ・コードを利用するには、シングル・スレッドのライブラリなら、実行スレッドは１つだけでよい。このクラスのライブラリでは、スレッドはライブラリを展開するクライアント・コードによって作成され、ライブラリ・コードは、他の実行スレッドを作成するため、ライブラリには存在しない。この制約は非スレッド・セーフのライブラリにはよくあることであり、今日使用されているコード・ライブラリの大部分は非スレッド・セーフである。新たな実行スレッドの開始に対してライブラリが制約を受ける場合がある点については、マルチスレッド環境ではしばしば別の理由がある。
【０００３】
シングル・スレッドのライブラリの不利な面は、サーバへのクライアント接続の健全性をこうしたライブラリからモニタするのが困難なことである。ライブラリがサーバ・プロセスとの接続を開くのはよくあることである。サーバとの接続がアクティブな間、クライアント・ライブラリ・コードは、ファイルに対する排他ロックや他の重要なリソースなど、サーバ・プロセスにとって重要なリソースをサーバから獲得することができる。したがってサーバにとっては、たとえばクライアント・コードにおけるプログラム障害によってライブラリがこれらのリソースを無期限に保持している状況を検出できることが望ましい。シングル・スレッドのライブラリの場合、ライブラリはクライアント・コードから制御を受け取ったときしかサーバにメッセージを送信することができない。クライアント・コードが制御スレッドのライブラリ・コードへの転送に無期限に失敗した場合、ライブラリ・コードはメッセージをサーバへ返送することができないだろう。
【０００４】
【発明が解決しようとする課題】
したがって本発明は、クライアント・コードにおける障害を検出し、クライアント・ライブラリへの接続を閉じることによってその障害に対応し、ライブラリがロックしているリソースを回復する能力を有するサーバ・プロセスを提供することを対象とする。
【０００５】
【課題を解決するための手段】
簡単に要約すると、本発明は一態様においてクライアント・プロセスとサーバ・プロセス間のサービス接続をモニタする方法を含む。この方法は、クライアント・プロセスのクライアント・コードのアクティビティをクライアント・プロセスのクライアント・ライブラリによってモニタするステップであって、クライアント・プロセスがシングル・スレッドのプロセスであるステップと、サービス接続を介してサーバ・プロセスに至るクライアント・ライブラリのアクティビティをモニタするステップであって、サービス接続のなされたクライアント・ライブラリのアクティビティがクライアント・コードにおけるアクティビティを示すステップとを含む。
【０００６】
繰り返しになるが、本明細書において提供するのは、シングル・スレッドのクライアント・ライブラリとサーバ・プロセス間のサービス接続をモニタし管理するための非干渉的な機能である。この非干渉的な機能によって、サーバ・アプリケーションは、生じるネットワーク・トラフィックの量を最小にしてクライアントをモニタすることができる。この非干渉的な機能は、クライアントping間隔（ＣＰＩ）とベース・タイムアウト値（ＢＴＯ）に基づいてプロセッサの処理速度とシステム・パフォーマンスの関数として得られる有意な数値から構成することができる。
【０００７】
【発明の実施の形態】
本発明の態様を組み込んで使用する分散コンピューティング環境の一例を図１に示し、ここに記載する。分散コンピューティング環境１００は、たとえば複数のＬＡＮゲート１０４を介して互いに結合された複数のフレーム１０２を含む。フレーム１０２とＬＡＮゲート１０４について、ここに詳しく記載する。
【０００８】
一例では分散コンピューティング環境１００は８つのフレームを含み、各フレームは複数の処理ノード１０６を含む。一例では各フレームは（各々が１つまたは複数のプロセッサを有する）１６の処理ノードを含む。たとえば各処理ノードは、ＡＩＸというＵＮＩＸ（Ｒ）ベースのオペレーティング・システムを実行するＲＩＳＣ／６０００コンピュータである。１つのフレーム内の各処理ノードは、たとえば内部のＬＡＮ接続を介して、当該フレームの他の処理ノードに結合されている。さらに各フレームはＬＡＮゲート１０４を介して他のフレームに結合されている。
【０００９】
たとえば各ＬＡＮゲート１０４は、ＲＩＳＣ／６０００コンピュータ、ＬＡＮへの任意のコンピュータ・ネットワーク接続、ネットワーク・ルータのいずれかを含む。しかしこれらは例にすぎない。他のタイプのＬＡＮゲートがあること、およびフレームを互いに結合させるには他のメカニズムも使用できることは、関連技術分野の技術者にとって明らかであろう。
【００１０】
図１の分散コンピューティング環境は一例にすぎない。フレーム数は８つ以上でも８つ以下でもよく、フレームごとのノード数は１６以上でも１６以下でもよい。さらに処理ノードは、ＡＩＸを実行するＲＩＳＣ／６０００コンピュータでなくてもよい。処理ノードのうちの複数またはすべては、異なるタイプのコンピュータまたは異なるオペレーティング・システムあるいはその両方を含むことができる。たとえば本発明は、ＬＩＮＵＸ（Ｒ）オペレーティング・システムまたはＷｉｎｄｏｗｓ（Ｒ）オペレーティング・システムあるいはその両方と共に使用することができる。さらに異種環境では、こうした環境のノードまたはオペレーティング・システムあるいはその両方のうち１つまたは複数がこうした環境の他のノードまたはオペレーティング・システムとは異なるような本発明の態様を含み使用することができる。こうした異種環境のノードは、互いに共同してリソースを共有するように動作する。これらのバリエーションのすべてを権利請求される本発明の一部とみなす。
【００１１】
図２は、クライアント／サーバ分散ネットワークを単純化した例であり、クライアント・プロセス２００はサービス接続２２０を介してサーバ・プロセス２１０と通信する。クライアント・プロセス２００はクライアント・コード２３０とクライアント・ライブラリ２４０を含む。前述のように、本発明は（ライブラリ２４０などの）シングル・スレッドのクライアント・ライブラリ環境においてサービス接続２２０などのクライアント接続の健全性をモニタする非干渉的な機能を含む。この機能によって解決される問題は、サーバ・プロセス２１０のクライアント２００が誤動作し、サーバ・アプリケーションへのアクティブな接続を無期限に保持する場合である。またクライアントによって重要なリソースがサーバ・アプリケーション内に「ロック」されたままになる場合もある。サーバ・アプリケーションは接続がアクティブかどうかを知る必要がある。すなわち接続がアクティブでない場合に、サーバが接続を閉じ、関連するリソースを解放できるようにである。
【００１２】
一例としてサーバ・プロセス２１０は、コンピューティング環境内で１セットのリソースを所有し制御する１つまたは複数のリソース・マネージャを含むことができる。リソース・マネージャの一例として、International Business Machines Corporation（ニューヨーク州アーモンク）が提供するＤＢ２などのデータベース管理機能がある。ＤＢ２については、「OS/390 Version 5 Release Guide」（ＩＢＭ資料番号ＳＣ２６−８９６５−０１、１９９７年６月）に記載されており、そのすべてを参照により本明細書に組み込む。
【００１３】
ここまでに概説した問題に対してとりうる１つの解決策は、クライアント・ライブラリが実行スレッドの制御を得るたびにサーバ・プロセスに返送される検査メッセージを使用することであろう。しかしこうしたアプローチでは、とりわけクライアント・コードによってライブラリが頻繁に使用される場合に、サーバに対する検査メッセージが多数生じる。たとえばライブラリが１０ミリ秒間隔で使用される場合、こうしたアプローチはサーバとの通信帯域幅を使用しすぎる。
【００１４】
本発明による好ましい機能は、クライアント・コードが非アクティブな期間を規定できるように構成されたタイマを、サーバに１つ、クライアントに１つ、計２つ使用する。この数値は異なるアプリケーションごとに経験的に決定することができ、本明細書に記載されている方法用の入力パラメータとして提供される。この入力パラメータを「ベース・タイムアウト（ＢＴＯ）値」と呼ぶ。加えて以下に記載する技術は、検査メッセージが送信される間隔を決定するためにネットワーク信頼性（ＮＲ）の測定を用いる。この間隔を「クライアントping間隔（ＣＰＩ）」と呼び、一実施形態では、ネットワークにおいてパッケージが除去される割合の平均として表されるＮＲ値にＢＴＯ値を掛けることによって決定される。式（１）はこの計算を表す。
ＣＰＩ＝ＢＴＯ×ＮＲ    （１）
【００１５】
ＣＰＩ値とＢＴＯ値を用いて、クライアント・コードが非アクティブになり始めたかどうかを判定するためにサーバ・プロセスによって使用されるようにタイマを定義することができる。サーバ・プロセスにおけるこのタイマの間隔を「サーバping許容度（ＳＰＴ）」と呼び、一実施形態では式（２）で表すことができる。
ＳＰＴ＝ＢＴＯ＋ＣＰＩ    （２）
【００１６】
ＢＴＯ１単位の間隔内にクライアントがライブラリ・コードの実行に失敗した場合、サーバはクライアント・コードを非アクティブとみなすしかないが、このことがＳＰＴ値によって保証される点に留意されたい。サーバはＳＰＴの時間間隔内にこの失敗を認識するだろう。これらの計算がネットワーク信頼性（ＮＲ）における要因でもある点に留意されたい。図３および図４のフローチャート実施形態は、ＢＴＯ入力値とＮＲ入力値の読み取り、およびこれらを用いた前述のようなＣＰＩとＳＰＴの計算を使用している。
【００１７】
図３は本発明によるクライアント・ライブラリ処理の一実施形態を示す。この処理は３００からスタートし、３０５でＢＴＯ値とＮＲ値を読み取る。このＢＴＯ値とＮＲ値は、前述のようにユーザによって入力された数値を含む。ＢＴＯ値は、たとえばクライアントが何のアクティビティも示さずに、すなわちクライアント・ライブラリに制御を転送せずにサーバ・リソースに対するロックの保持を認められる時間の最大量を見積もることによって、経験的に得られる。
【００１８】
３１５でクライアント・ライブラリがサーバ・プロセスへのサービス接続を開き、３２０で変数Ｔが現在の時刻（current_time()）として定義される。３２５で最初のpingがクライアント・ライブラリからサーバに送信される。次いでクライアント・ライブラリ・プロセスは、制御がクライアント・コードから転送されるのを待つ３３０で始まるループに入る。３３５で制御がクライアント・コードから転送されると、３４０でクライアント・ライブラリが転送時に現在の時刻（ＣＴ）を決定する。３５０で現在の時刻（ＣＴ）からサーバに先立つpingの時刻（Ｔ）を差し引いた値がＣＰＩより大きいかどうかの問い合わせが行われる。繰り返しになるが、ＣＰＩ（クライアントping間隔）とは、クライアント・ライブラリがサーバに活性メッセージを送信する最大の間隔である。基本的にＣＰＩは、活性プロトコルによって生じるネットワーク・トラフィックの量を制御するために使用される。いかなるＣＰＩ監視の範囲内においても監視される活性メッセージ（すなわちping）が１つを越えないことを意味する量が下限である。
【００１９】
現在の時刻（ＣＴ）と先立つpingの時刻（Ｔ）との差がＣＰＩより大きくない場合、３６０でクライアント・ライブラリは制御を単にクライアント・コードに返し、その後３３０で制御がクライアント・コードからクライアント・ライブラリに返送されるのを待ち、このプロセスを繰り返す。差がＣＰＩより大きい場合、３７０でpingメッセージがサーバ・プロセスに送信され、３８０で直近のpingメッセージの時刻（Ｔ）がcurrent_time()にリセットされる。次いで３９０で制御がクライアント・コードに返され、クライアント・ライブラリは、しばらく後に制御が返送されるのを待つ。
【００２０】
図４は、本発明の原理によるサーバ・プロセスで実施される処理の一実施形態を示す。この処理は４００でスタートし、４０５でＢＴＯ値とＮＲ値を読み取り、４１０でクライアントping間隔（ＣＰＩ）を計算する。次いで４１５でサーバping許容度（ＳＰＴ）がＢＴＯ＋ＣＰＩによって決定される。繰り返しになるが、ＳＰＴとは、接続が非アクティブなので閉じるべきだと決定する前にサーバがクライアントの活性メッセージ（すなわちping）の受信を待つ「猶予期間」である。これはアクティビティの測定に用いられる上限である。基本的にＢＴＯ値にＣＰＩを足すと、ＳＰＴ値に対する余分な許容度が生じ、これは、ＣＰＩが最後にクライアント・ライブラリに転送されたときに実行スレッドがＣＰＩの終了を単に見逃すような極端なシナリオにおいて、重要な意味を持つことがある。
【００２１】
この状況を説明する１つの方法は、例を用いることである。ＣＰＩを１０秒と仮定すると、ベース・タイムアウト値は６０秒と推定される。この場合、ＳＰＴは７０秒である。ここでＳＰＴに余分なＣＰＩを１単位（１０秒）足すと、余分な許容度が生じ、次のシナリオが可能になる。
（１）制御スレッドがクライアント・ライブラリに転送されるたびに、ライブラリは活性メッセージを送信すべきかどうかチェックし、最終メッセージ作成のタイム・スタンプを保存する。
（２）実行スレッドが最後にライブラリに転送されたのが最終の活性メッセージ発行の９秒後である場合、９＜ＣＰＩなので、クライアント・ライブラリはその時点では活性メッセージを作成しない。さもないとＣＰＩの下限に満たないからである。
（３）次いで５５秒後、すなわち最終メッセージ送信の６４秒後に実行スレッドが再度転送される。もしタイムアウト値の上限が経験的に測定して６０秒であるならば、サーバはクライアント接続を非アクティブとみなしただろう。それにもかかわらず、クライアント・ライブラリがアクティビティなしに監視される最大の時間間隔は５５秒であり、これは上限を超えていない。
【００２２】
結論としては、本発明がクライアント・アクティビティの監視をクライアント・ライブラリ内に置いている点と、非干渉的な活性メッセージがクライアント・ライブラリによって送信される点から、サーバ・プロセスが接続アクティビティを検査するために使用する上限値に対して少なくとも１単位の許容度を追加することが好ましい。
【００２３】
便利なことに、式ＳＰＴ＝ＢＴＯ＋ＣＰＩによって有意なタイムアウト値が算出され、これはサーバがクライアント接続におけるアクティビティを判定するのに使用される。さらにＢＴＯ値とＣＰＩ値は、容易に推定（または構成）できる有意な量であり、クライアント・アプリケーションにとって次のような意義を有する。（１）ＣＰＩ値は２つの活性メッセージ間で認められる時間の最小量であり、無関係なメッセージを減らすために使用される。（２）ＢＴＯ値は、クライアント・アプリケーションが実行スレッドをクライアント・ライブラリに返送せずにとることができる最大の時間である。
【００２４】
図４に関して続けると、ＳＰＴの決定後、４２０でサーバ・プロセスはクライアント・プロセスが接続を開始するのを待つ。４２５でクライアント接続（ここではサーバ接続とも呼ぶ）を確立した後、４３０でサーバ・プロセスはそのリソースのうち１つまたは複数をクライアント・プロセスに与えることができる。次いで４４０でサーバ・プロセスは、前述のような継続されたクライアント・コード・アクティビティを示すクライアント・ライブラリのpingメッセージを待つ。４５０でサーバ・プロセスは、pingメッセージがＳＰＴの間隔内に受信されるかどうかを判定し、受信された場合、４４０で次のpingメッセージを待つ。サービス接続がＳＰＴよりも長い間隔で非アクティブな場合、サーバ・プロセスは、４６０でクライアント・プロセスへの接続を終了し、４７０でクライアント・リソースを回復した後、４２０に戻って新たなクライアント接続を待つ。
【００２５】
当業者なら前述の記載から、本発明のプロセスによって使用される時間の量がクライアント・システムにおける同一のクロックから得られることに気づくだろう。このことは本明細書に記載されているプロセスの長所であり、これによってクライアント・クロックとサーバ・クロックの同期が不要になる。本明細書で概説されている機能によって、サーバ・アプリケーションは最小のネットワーク・トラフィックでクライアントをモニタすることができる。またこの機能は、ＣＰＩとＢＴＯの推定に基づいてプロセッサの処理速度とシステム・パフォーマンスの関数として得られる有意な数値から構成することができる。さらに本明細書で提示されている技術は非干渉的であり、シングル・スレッドのクライアント・アプリケーションによって使用することができる。
【００２６】
本発明は、たとえばコンピュータで使用可能なメディアを有する製造品（たとえば１つまたは複数のコンピュータ・プログラム製品）に含むことができる。このメディアは、たとえば本発明の性能を提供し実施するためのコンピュータ可読プログラム・コード手段を内蔵する。この製造品はコンピュータ・システムの一部に含むこともできるし、別個に販売することもできる。
【００２７】
本明細書に記載されている流れ図は、例として提供されたものである。本明細書に記載されているこれらの図やステップ（または操作）に対して、本発明の趣旨から逸脱せずに変更を加えることができる。たとえば場合によっては、ステップを異なる順序で実行したり、ステップを追加、削除または修正することもできる。これらの変更のすべては、添付の特許請求の範囲に記載されるように、本発明の一部を構成するものとみなす。
【００２８】
まとめとして、本発明の構成に関して以下の事項を開示する。
【００２９】
（１）  クライアント内のクライアント・プロセスと、前記クライアントに接続されたサーバ内のサーバ・プロセスとの間のサービス接続をモニタする方法であって、
前記クライアントが、
クライアント・プロセスのクライアント・コードのアクティビティを前記クライアント・プロセスのクライアント・ライブラリによってモニタするステップであって、前記クライアント・プロセスがシングル・スレッドのプロセスであり、前記クライアント・プロセスが前記クライアント・コードと前記クライアント・ライブラリの両方を含む、前記モニタするステップと、
前記サーバが、
サーバ・プロセスへのサービス接続を介して前記クライアント・ライブラリのアクティビティを前記サーバ・プロセスによってモニタするステップであって、前記サービス接続上の前記クライアント・ライブラリの前記アクティビティが、前記クライアント・コードでのアクティビティを示す、前記モニタするステップと
を含む方法。
（２）  前記クライアント・コードのアクティビティを前記クライアント・ライブラリによってモニタする前記ステップが、前記クライアント・コードにおけるモニタされたアクティビティを示すpingメッセージを、前記サービス接続を介して前記サーバ・プロセスに定期的に送信するステップをさらに含む、（１）に記載の方法。
（３）  前記クライアント・ライブラリのアクティビティを前記サーバ・プロセスによってモニタする前記ステップが、サーバping許容度の間隔内に前記サービス接続を介してpingメッセージが受信されたかどうかを判定するステップを含み、前記サーバ・プロセスにおいて、pingメッセージが受信された場合、次のpingメッセージを待つステップと、pingメッセージが受信されない場合に前記クライアント・プロセスとサーバ・プロセス間の前記サービス接続を終了するステップとを含む、（２）に記載の方法。
（４）  サーバ・プロセスが、そのリソースのうち１つ又は複数をクライアント・プロセスに与えるステップを含む、（１）に記載の方法。
（５）  前記サービス接続の終了に続いて前記サーバ・プロセスにおいてクライアント・リソースを回復するステップをさらに含む、（４）に記載の方法。
（６）  前記クライアント・コードのアクティビティを前記クライアント・ライブラリによってモニタする前記ステップが、ベース・タイムアウト値（ＢＴＯ）にネットワーク信頼性値（ＮＲ）を掛けてクライアントping間隔（ＣＰＩ）を決定するステップと、前記サーバ・プロセスへの最終のpingメッセージ以降の時間間隔が前記ＣＰＩを超えたとき、前記クライアント・コードにおけるモニタされたアクティビティを示すpingメッセージを前記サービス接続を介して前記サーバ・プロセスに定期的に送信するために前記ＣＰＩを使用するステップと
をさらに含む、（１）に記載の方法。
（７）  前記クライアント・ライブラリのアクティビティを前記サーバ・プロセスによってモニタする前記ステップが、ＢＴＯ＋ＣＰＩで定義されるサーバping許容度（ＳＰＴ）の間隔内に前記サービス接続を介してpingメッセージが受信されたかどうかを判定するステップを含み、前記サーバ・プロセスにおいて、pingメッセージが受信された場合、次のpingメッセージを待つステップと、pingメッセージが受信されない場合に前記クライアント・プロセスとサーバ・プロセス間の前記サービス接続を終了するステップとを含む、（６）に記載の方法。
（８）  前記クライアント・コードのアクティビティを前記クライアント・ライブラリによってモニタする前記ステップが、前記クライアント・コードから前記クライアント・ライブラリに制御が転送されたときに現在の時刻（ＣＴ）を決定するステップと、最終のpingメッセージが前記サーバ・プロセスに送信された時刻（Ｔ）をＣＴから差し引くことによって前記最終のpingメッセージが前記サーバ・プロセスに送信されてからの前記時間間隔を決定するステップとを含み、前記使用するステップが、ＣＴ−Ｔ>ＣＰＩかどうかを判定するステップを含み、前記クライアント・ライブラリによって、ＣＴ−Ｔ>ＣＰＩである場合、pingメッセージをサーバ・プロセスに送信するステップと、ＣＴ−Ｔ>ＣＰＩでない場合、制御をクライアント・コードに返すステップとを含む、（６）に記載の方法。
（９）  前記クライアント・コードのアクティビティを前記クライアント・ライブラリによってモニタする前記ステップが、前記pingメッセージが前記サービス接続を介して前記サーバ・プロセスに送信されたときに現在の時刻と等しい時刻Ｔを設定するステップと、次いで前記クライアント・コードに制御を返すステップとをさらに含む、（８）に記載の方法。
（１０）  クライアント内のクライアント・プロセスと、前記クライアントに接続されたサーバ内のサーバ・プロセスとの間のサービス接続をモニタするためのシステムであって、
前記クライアントが、
クライアント・プロセスのクライアント・コードのアクティビティを前記クライアント・プロセスのクライアント・ライブラリによってモニタするための手段であって、前記クライアント・プロセスがシングル・スレッドのプロセスであり、前記クライアント・プロセスが前記クライアント・コードと前記クライアント・ライブラリの両方を含む、前記モニタするための手段を含み、
前記サーバが、
サーバ・プロセスへのサービス接続を介して前記クライアント・ライブラリのアクティビティを前記サーバ・プロセスによってモニタするための手段であって、前記サービス接続上のクライアント・ライブラリの前記アクティビティが、前記クライアント・コードでのアクティビティを示す、前記モニタするための手段を含む、
システム。
（１１）  前記クライアント・コードのアクティビティを前記クライアント・ライブラリによってモニタするための前記手段が、前記クライアント・コードにおけるモニタされたアクティビティを示すpingメッセージを、前記サービス接続を介して前記サーバ・プロセスに定期的に送信するための手段をさらに含む、（１０）に記載のシステム。
（１２）  前記クライアント・ライブラリのアクティビティを前記サーバ・プロセスによってモニタするための前記手段が、サーバping許容度の間隔内に前記サービス接続を介してpingメッセージが受信されたかどうかを判定するための手段を含み、前記サーバ・プロセスにおいて、pingメッセージが受信された場合、次のpingメッセージを待つ手段と、pingメッセージが受信されない場合に前記クライアント・プロセスとサーバ・プロセス間の前記サービス接続を終了する手段とを含む、（１１）に記載のシステム。
（１３）  サーバ・プロセスが、そのリソースのうち１つ又は複数をクライアント・プロセスに与える手段を含む、（１０）に記載のシステム。
（１４）  前記サービス接続の終了に続いて前記サーバ・プロセスにおいてクライアント・リソースを回復するための手段をさらに含む、（１３）に記載のシステム。
（１５）  前記クライアント・コードのアクティビティを前記クライアント・ライブラリによってモニタするための前記手段が、ベース・タイムアウト値（ＢＴＯ）にネットワーク信頼性値（ＮＲ）を掛けてクライアントping間隔（ＣＰＩ）を決定するための手段と、前記サーバ・プロセスへの最終のpingメッセージ以降の時間間隔が前記ＣＰＩを超えたとき、前記クライアント・コードにおけるモニタされたアクティビティを示すpingメッセージを前記サービス接続を介して前記サーバ・プロセスに定期的に送信するために前記ＣＰＩを使用するための手段と
をさらに含む、（１０）に記載のシステム。
（１６）  前記クライアント・ライブラリのアクティビティを前記サーバ・プロセスによってモニタするための前記手段が、ＢＴＯ＋ＣＰＩで定義されるサーバping許容度（ＳＰＴ）の間隔内に前記サービス接続を介してpingメッセージが受信されたかどうかを判定するための手段を含み、前記サーバ・プロセスにおいて、pingメッセージが受信された場合、次のpingメッセージを待つ手段と、pingメッセージが受信されない場合に前記クライアント・プロセスとサーバ・プロセス間の前記サービス接続を終了する手段とを含む、（１５）に記載のシステム。
（１７）  前記クライアント・コードのアクティビティを前記クライアント・ライブラリによってモニタするための前記手段が、前記クライアント・コードから前記クライアント・ライブラリに制御が転送されたときに現在の時刻（ＣＴ）を決定するための手段と、最終のpingメッセージが前記サーバ・プロセスに送信された時刻（Ｔ）をＣＴから差し引くことによって前記最終のpingメッセージが前記サーバ・プロセスに送信されてからの前記時間間隔を決定するための手段とを含み、前記使用するための手段が、ＣＴ−Ｔ>ＣＰＩかどうかを判定するための手段を含み、前記クライアント・ライブラリによって、ＣＴ−Ｔ>ＣＰＩである場合、pingメッセージをサーバ・プロセスに送信する手段と、ＣＴ−Ｔ>ＣＰＩでない場合、制御をクライアント・コードに返す手段とを含む、（１５）に記載のシステム。
（１８）  前記クライアント・コードのアクティビティを前記クライアント・ライブラリによってモニタするための前記手段が、前記pingメッセージが前記サービス接続を介して前記サーバ・プロセスに送信されたときに現在の時刻と等しい時刻Ｔを設定するための手段と、次いで前記クライアント・コードに制御を返すための手段とをさらに含む、（１７）に記載のシステム。
【図面の簡単な説明】
【図１】本発明の態様を組み込んで使用するコンピューティング環境の一例を示す図である。
【図２】本発明の原理による機能を使用するためのクライアント・プロセスとサーバ・プロセスの一実施形態を示す図である。
【図３】本発明の原理によるクライアント・ライブラリ処理の一実施形態を示すフローチャートである。
【図４】本発明の原理によるサーバ処理の一実施形態を示すフローチャートである。
【符号の説明】
１００  分散コンピューティング環境
１０２  フレーム
１０４  ＬＡＮゲート
１０６  処理ノード
２００  クライアント・プロセス
２１０  サーバ・プロセス
２２０  サービス接続
２３０  クライアント・コード
２４０  クライアント・ライブラリ
【図１】
0003803039.tif 000002
【図２】
0003803039.tif 000003
【図３】
0003803039.tif 000004
【図４】
0003803039.tif 000005