サーバ・クライアントシステム
【課題】 システムによっては、クライアントが正常に動作しつつも長期間、サーバに対して状態通知ができない状態になることがあり得る。
【解決手段】 クライアントはサーバに対して状態通知不能になる処理を開始する前に、サーバに対して状態通知不能になる旨と、状態通知再開までの予測時間を通知する。
サーバはこれを受信し、状態通知不能と宣言された時間中は、クライアントからの状態通知がない場合においてもクライアントの異常とは判断しない。
クライアントから受信した予測時間を経過しても、なお状態通知がない場合は、クライアントの異常と判定する。
【解決手段】 クライアントはサーバに対して状態通知不能になる処理を開始する前に、サーバに対して状態通知不能になる旨と、状態通知再開までの予測時間を通知する。
サーバはこれを受信し、状態通知不能と宣言された時間中は、クライアントからの状態通知がない場合においてもクライアントの異常とは判断しない。
クライアントから受信した予測時間を経過しても、なお状態通知がない場合は、クライアントの異常と判定する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、サーバ・クライアントシステムに関するものである。
特に、クライアントはサーバへ定期的に状態通知を行い、サーバは受信した状態通知の解析による異常検知、ならびに、一定時間状態通知が途絶えたことによるクライアントのダウン検知の、２つの監視手段を有するサーバ・クライアントシステムに関するものである。
【背景技術】
【０００２】
従来、サーバによるクライアントの異常検知手段としては、Watch DogとHeart Beatの2つの方式があった。
【０００３】
Watch Dogとは、サーバからクライアントに対して、定期的に動作確認のための通信を行い、そのレスポンスを解析することで異常を検知する手法である。
【０００４】
Heart Beatとは、逆にクライアントからサーバに定期的に状態通知を行い、サーバはその状態通知を解析することで異常を検知する手法である。
【０００５】
サーバ・クライアントの監視手段において、異常が繰り返し発生した場合、クライアントはサーバに対し繰り返し異常発生を通知し、繰り返し異常状態から回復するまで状態通知を停止することで、通信トラフィックを低減する（特許文献１参照）。
【特許文献１】開平１０−２６９４８１号公報
【発明の開示】
【発明が解決しようとする課題】
【０００６】
本発明は、Heart Beatに関するものである。
Heart Beatにおいて、クライアントから一定時間状態通知がなかった場合、サーバはクライアントが異常な状態に陥っていると判断する。
【０００７】
しかし、システムによっては、クライアントが正常に動作しつつも長期間、サーバに対して状態通知ができない状態になることがあり得る。
【０００８】
例としては、クライアントプロセスや機器自体の計画された再起動、高負荷プロセスによる処理の占有、などが挙げられる。
【０００９】
このような場合でも、サーバは、クライアントからの状態通知がないことから、クライアントの状態を異常と判断してしまう。
【００１０】
そのため、本来は不要である復旧処理を実行したり、管理者宛に異常を通知したりしてしまう。
【課題を解決するための手段】
【００１１】
この問題を解決するため、クライアントはサーバに対して状態通知不能になる処理を開始する前に、サーバに対して状態通知不能になる旨と、状態通知再開までの予測時間を通知する。
【００１２】
サーバはこれを受信し、状態通知不能と宣言された時間中は、クライアントからの状態通知がない場合においてもクライアントの異常とは判断しない。
【００１３】
クライアントから受信した予測時間を経過しても、なお状態通知がない場合は、クライアントの異常と判定する。
【発明の効果】
【００１４】
本発明によって、クライアントからの状態通知が途絶えた理由をサーバが解釈できるようになり、異常検知の精度を高めることができる。
【発明を実施するための最良の形態】
【００１５】
（実施例１）
本発明の実施例として、デジタル複合機とその上で動作するアプリケーション(クライアント)とサーバから構成されるシステムをあげる。
【００１６】
アプリケーションは、定期的にサーバに対してクライアントの状態を通知し、サーバは状態通知を一定間隔で受信することで、クライアントの状態を監視している。サーバは、クライアントの異常を検知すると、管理者に対してメールにて通知を行う。
【００１７】
概アプリケーションは、デジタル複合機の外からHTTPを用いてアクセスし、デジタル複合機ならびにアプリケーション自身の状態確認、動作変更を指示することができる。
【００１８】
デジタル複合機の特定の設定が変更された場合、設定を反映するために再起動が必要となる。この場合、アプリケーションが、自動的にデジタル複合機を再起動させる。アプリケーションは、再起動の前に、サーバに対してデジタル複合機を再起動させることと、再起動が完了し状態通知を再開するまでの予測時間を通知する。
【００１９】
図1は、本発明の実施例におけるシステムの全体の構成を説明するブロック図である。デジタル複合機100、101、Webブラウザを含む端末102、サーバ103、メールサーバ104がネットワーク105に接続されている。端末102は、この実施例ではデジタル複合機ならびにその上で動作するアプリケーションの状態確認ならびに設定変更を行うためのUIとして用いられる。また、メールサーバ104は、サーバにおける異常検知時の動作として、管理者にメール通知するために利用される。
【００２０】
図２は、本発明の実施例において、デジタル複合機が再起動する場合のシーケンス図である。図中の100〜103は、図1にも示したのシステムの構成要素であり、図1と同じ番号を振っている。
【００２１】
Webブラウザ102より、アプリケーションを介してデジタル複合機の設定変更が指示される(200)。デジタル複合機は、設定を変更し(201)、設定変更を反映するために再起動が必要であれば、再起動プロセスに入る。再起動プロセスにおいては、サーバに対して再起動を行うことと、再起動完了までの予測時間を通知する(202)。具体的には、図4に示すクライアント状態データを送信する。再起動を行うことの通知は、ステータスコード(401)にその旨を意味する値を設定することで行う。
【００２２】
その後、デジタル複合機は再起動を行い(204)、再起動完了後、その旨をサーバに通知する(206)。この時、送信するクライアント状態データは、ステータスコード(401)として通常稼動を表す値を設定し、状態通知停止時間(402)は設定しない。
【００２３】
サーバは、クライアントからの状態通知を受信し、受信したデータを解析し、ステータスおよび状態通知停止時間を記録する(203)。その後、クライアント状態監視部は、202で記録した状態通知停止時間を用いて、クライアントの生存確認を行う(205)。やがて、クライアントから再起動完了の通知(206)を受信したら、クライアントのステータスおよび状態通知停止時間を更新する(207)。
【００２４】
図３は、本発明の実施例において、アプリケーションを介したデジタル複合機ならびにアプリケーション自身の状態表示・設定変更を行う際に、関連するデジタル複合機上のモジュールの構成図である。ここで図示したモジュールは、デジタル複合機内のモジュールの一部である。
【００２５】
ネットワークI/F(300)は、他の機器とのネットワークを介しての通信を制御するモジュールである。
【００２６】
HTTP通信部(301)、SOAP通信部(302)は、それぞれネットワークI/Fが送受信したデータを、それぞれのプロトコルとして解析するためのモジュールである。
【００２７】
アプリケーション(303)は、定期的にサーバに対してクライアントの状態を通知する機能と、HTTPによるリクエストを受信し、デジタル複合機ならびにアプリケーション自身の状態表示、動作変更を行う機能を持つ。
【００２８】
HTTPリクエストは、ネットワークI/F(300)、HTTP通信部(301)を通して受信する。
【００２９】
アプリケーションが、サーバに対して状態通知する際には、SOAP通信部(302)、HTTP通信部(301)、ネットワークI/F(303)を介して通信する。
【００３０】
MIB I/F(304)は、MIBプロトコルを用いてデジタル複合機を制御するためのモジュールである。
【００３１】
OSサービス部(305)は、デジタル複合機の電源や、ファイルシステムなどを制御するモジュールである。
【００３２】
アプリケーションが、デジタル複合機を再起動する際には、MIB I/F(304)を介して、OSサービス部(305)にアクセスする。
【００３３】
図４は、本発明の実施例において、クライアントであるデジタル複合機から、サーバに対して通信するクライアント状態データの構造である。
【００３４】
クライアントID(400)は、クライアントごとに一意の識別子である。これは、クライアントが初めてサーバと通信する時点で、サーバより配布される。
【００３５】
ステータスコード(401)は、クライアントの状態を表した数字列である。
【００３６】
状態通知停止時間(402)は、次の状態通知までの時間を秒単位で設定する。この項目は、通常は設定しない。この場合は、サーバ側でデフォルト値が入っているものとして扱われる。デジタル復号機を再起動する際などに、再起動完了までの予測時間を設定する。
【００３７】
図５は、本発明の実施例において、サーバのクライアント状態データ受信部の基本的な処理フローである。
【００３８】
この処理は、クライアントからの状態通知を受信するごとに、新たなスレッドとして実行される。
【００３９】
500で、クライアントから受信したデータを解析する。クライアント状態データとして正常に解析できた場合は、501へ進む。
【００４０】
501で、クライアント状態データに状態通知停止時間が含まれている場合には503へ、含まれない場合は502へ進む。
【００４１】
502では、状態通知停止時間として、規定の値を設定する。
【００４２】
503で、受信したクライアントに対応するクライアントIDの、状態通知受信時刻と、ステータスを記録する。また、状態通知停止時間を次回受信間隔として記録する。
【００４３】
なお、上記で説明した動作フローは一例であり、上記の処理の流れに限定されるものではない。
【００４４】
図６は、本発明の実施例において、サーバのクライアント状態監視部の基本的な処理フローである。
【００４５】
この処理は、一定時間ごとに、新たなスレッドとして実行される。
【００４６】
600〜604までの処理は、クライアントの数だけ繰り返される。
【００４７】
600で、全てのクライアントに対して処理を行ったか判定する。全てのクライアントに対して処理を行った場合、終了する。そうでない場合は、未処理のクライアントを1つ選択し、601〜604の処理を実行する。
【００４８】
601で、概クライアントについて記録されたステータスを確認する。ステータスが正常でない場合は、604へ進む。正常である場合は、602へ進む。
【００４９】
602で、現在時刻を取得する。
【００５０】
603で、クライアントの生存を確認する。記録された、概クライアントからのステータス受信時刻に次回受信間隔を加えた時刻を、現在時刻が過ぎているか調べる。そうである場合は、クライアントからの状態通知が途絶えているため、クライアントが生存していないと判断し、604へ進む。そうでなければ、クライアントは正常であると判断し、600へ戻る。
【００５１】
604は、クライアントの異常を検出した際の処理である。ここでは、予め設定された管理者のメールアドレスに対して、異常を通知するものとする。
【００５２】
なお、上記で説明した動作フローは一例であり、上記の処理の流れに限定されるものではない。
【図面の簡単な説明】
【００５３】
【図１】システムの構成。
【図２】デジタル複合機再起動時のシーケンス。
【図３】デジタル複合機の構成（抜粋）。
【図４】クライアント状態データの構造。
【図５】サーバのクライアント状態データ受信部の基本的な処理フロー。
【図６】サーバのクライアント状態監視部の基本的な処理フロー。
【符号の説明】
【００５４】
100〜101 デジタル複合機(クライアント)
102 Webブラウザ
103 サーバ
104 メールサーバ
200〜207 デジタル複合機再起動時の処理
300〜305 デジタル複合機のモジュール（抜粋）
400〜402 クライアント状態データの構成要素
500〜604 処理ステップ
【技術分野】
【０００１】
本発明は、サーバ・クライアントシステムに関するものである。
特に、クライアントはサーバへ定期的に状態通知を行い、サーバは受信した状態通知の解析による異常検知、ならびに、一定時間状態通知が途絶えたことによるクライアントのダウン検知の、２つの監視手段を有するサーバ・クライアントシステムに関するものである。
【背景技術】
【０００２】
従来、サーバによるクライアントの異常検知手段としては、Watch DogとHeart Beatの2つの方式があった。
【０００３】
Watch Dogとは、サーバからクライアントに対して、定期的に動作確認のための通信を行い、そのレスポンスを解析することで異常を検知する手法である。
【０００４】
Heart Beatとは、逆にクライアントからサーバに定期的に状態通知を行い、サーバはその状態通知を解析することで異常を検知する手法である。
【０００５】
サーバ・クライアントの監視手段において、異常が繰り返し発生した場合、クライアントはサーバに対し繰り返し異常発生を通知し、繰り返し異常状態から回復するまで状態通知を停止することで、通信トラフィックを低減する（特許文献１参照）。
【特許文献１】開平１０−２６９４８１号公報
【発明の開示】
【発明が解決しようとする課題】
【０００６】
本発明は、Heart Beatに関するものである。
Heart Beatにおいて、クライアントから一定時間状態通知がなかった場合、サーバはクライアントが異常な状態に陥っていると判断する。
【０００７】
しかし、システムによっては、クライアントが正常に動作しつつも長期間、サーバに対して状態通知ができない状態になることがあり得る。
【０００８】
例としては、クライアントプロセスや機器自体の計画された再起動、高負荷プロセスによる処理の占有、などが挙げられる。
【０００９】
このような場合でも、サーバは、クライアントからの状態通知がないことから、クライアントの状態を異常と判断してしまう。
【００１０】
そのため、本来は不要である復旧処理を実行したり、管理者宛に異常を通知したりしてしまう。
【課題を解決するための手段】
【００１１】
この問題を解決するため、クライアントはサーバに対して状態通知不能になる処理を開始する前に、サーバに対して状態通知不能になる旨と、状態通知再開までの予測時間を通知する。
【００１２】
サーバはこれを受信し、状態通知不能と宣言された時間中は、クライアントからの状態通知がない場合においてもクライアントの異常とは判断しない。
【００１３】
クライアントから受信した予測時間を経過しても、なお状態通知がない場合は、クライアントの異常と判定する。
【発明の効果】
【００１４】
本発明によって、クライアントからの状態通知が途絶えた理由をサーバが解釈できるようになり、異常検知の精度を高めることができる。
【発明を実施するための最良の形態】
【００１５】
（実施例１）
本発明の実施例として、デジタル複合機とその上で動作するアプリケーション(クライアント)とサーバから構成されるシステムをあげる。
【００１６】
アプリケーションは、定期的にサーバに対してクライアントの状態を通知し、サーバは状態通知を一定間隔で受信することで、クライアントの状態を監視している。サーバは、クライアントの異常を検知すると、管理者に対してメールにて通知を行う。
【００１７】
概アプリケーションは、デジタル複合機の外からHTTPを用いてアクセスし、デジタル複合機ならびにアプリケーション自身の状態確認、動作変更を指示することができる。
【００１８】
デジタル複合機の特定の設定が変更された場合、設定を反映するために再起動が必要となる。この場合、アプリケーションが、自動的にデジタル複合機を再起動させる。アプリケーションは、再起動の前に、サーバに対してデジタル複合機を再起動させることと、再起動が完了し状態通知を再開するまでの予測時間を通知する。
【００１９】
図1は、本発明の実施例におけるシステムの全体の構成を説明するブロック図である。デジタル複合機100、101、Webブラウザを含む端末102、サーバ103、メールサーバ104がネットワーク105に接続されている。端末102は、この実施例ではデジタル複合機ならびにその上で動作するアプリケーションの状態確認ならびに設定変更を行うためのUIとして用いられる。また、メールサーバ104は、サーバにおける異常検知時の動作として、管理者にメール通知するために利用される。
【００２０】
図２は、本発明の実施例において、デジタル複合機が再起動する場合のシーケンス図である。図中の100〜103は、図1にも示したのシステムの構成要素であり、図1と同じ番号を振っている。
【００２１】
Webブラウザ102より、アプリケーションを介してデジタル複合機の設定変更が指示される(200)。デジタル複合機は、設定を変更し(201)、設定変更を反映するために再起動が必要であれば、再起動プロセスに入る。再起動プロセスにおいては、サーバに対して再起動を行うことと、再起動完了までの予測時間を通知する(202)。具体的には、図4に示すクライアント状態データを送信する。再起動を行うことの通知は、ステータスコード(401)にその旨を意味する値を設定することで行う。
【００２２】
その後、デジタル複合機は再起動を行い(204)、再起動完了後、その旨をサーバに通知する(206)。この時、送信するクライアント状態データは、ステータスコード(401)として通常稼動を表す値を設定し、状態通知停止時間(402)は設定しない。
【００２３】
サーバは、クライアントからの状態通知を受信し、受信したデータを解析し、ステータスおよび状態通知停止時間を記録する(203)。その後、クライアント状態監視部は、202で記録した状態通知停止時間を用いて、クライアントの生存確認を行う(205)。やがて、クライアントから再起動完了の通知(206)を受信したら、クライアントのステータスおよび状態通知停止時間を更新する(207)。
【００２４】
図３は、本発明の実施例において、アプリケーションを介したデジタル複合機ならびにアプリケーション自身の状態表示・設定変更を行う際に、関連するデジタル複合機上のモジュールの構成図である。ここで図示したモジュールは、デジタル複合機内のモジュールの一部である。
【００２５】
ネットワークI/F(300)は、他の機器とのネットワークを介しての通信を制御するモジュールである。
【００２６】
HTTP通信部(301)、SOAP通信部(302)は、それぞれネットワークI/Fが送受信したデータを、それぞれのプロトコルとして解析するためのモジュールである。
【００２７】
アプリケーション(303)は、定期的にサーバに対してクライアントの状態を通知する機能と、HTTPによるリクエストを受信し、デジタル複合機ならびにアプリケーション自身の状態表示、動作変更を行う機能を持つ。
【００２８】
HTTPリクエストは、ネットワークI/F(300)、HTTP通信部(301)を通して受信する。
【００２９】
アプリケーションが、サーバに対して状態通知する際には、SOAP通信部(302)、HTTP通信部(301)、ネットワークI/F(303)を介して通信する。
【００３０】
MIB I/F(304)は、MIBプロトコルを用いてデジタル複合機を制御するためのモジュールである。
【００３１】
OSサービス部(305)は、デジタル複合機の電源や、ファイルシステムなどを制御するモジュールである。
【００３２】
アプリケーションが、デジタル複合機を再起動する際には、MIB I/F(304)を介して、OSサービス部(305)にアクセスする。
【００３３】
図４は、本発明の実施例において、クライアントであるデジタル複合機から、サーバに対して通信するクライアント状態データの構造である。
【００３４】
クライアントID(400)は、クライアントごとに一意の識別子である。これは、クライアントが初めてサーバと通信する時点で、サーバより配布される。
【００３５】
ステータスコード(401)は、クライアントの状態を表した数字列である。
【００３６】
状態通知停止時間(402)は、次の状態通知までの時間を秒単位で設定する。この項目は、通常は設定しない。この場合は、サーバ側でデフォルト値が入っているものとして扱われる。デジタル復号機を再起動する際などに、再起動完了までの予測時間を設定する。
【００３７】
図５は、本発明の実施例において、サーバのクライアント状態データ受信部の基本的な処理フローである。
【００３８】
この処理は、クライアントからの状態通知を受信するごとに、新たなスレッドとして実行される。
【００３９】
500で、クライアントから受信したデータを解析する。クライアント状態データとして正常に解析できた場合は、501へ進む。
【００４０】
501で、クライアント状態データに状態通知停止時間が含まれている場合には503へ、含まれない場合は502へ進む。
【００４１】
502では、状態通知停止時間として、規定の値を設定する。
【００４２】
503で、受信したクライアントに対応するクライアントIDの、状態通知受信時刻と、ステータスを記録する。また、状態通知停止時間を次回受信間隔として記録する。
【００４３】
なお、上記で説明した動作フローは一例であり、上記の処理の流れに限定されるものではない。
【００４４】
図６は、本発明の実施例において、サーバのクライアント状態監視部の基本的な処理フローである。
【００４５】
この処理は、一定時間ごとに、新たなスレッドとして実行される。
【００４６】
600〜604までの処理は、クライアントの数だけ繰り返される。
【００４７】
600で、全てのクライアントに対して処理を行ったか判定する。全てのクライアントに対して処理を行った場合、終了する。そうでない場合は、未処理のクライアントを1つ選択し、601〜604の処理を実行する。
【００４８】
601で、概クライアントについて記録されたステータスを確認する。ステータスが正常でない場合は、604へ進む。正常である場合は、602へ進む。
【００４９】
602で、現在時刻を取得する。
【００５０】
603で、クライアントの生存を確認する。記録された、概クライアントからのステータス受信時刻に次回受信間隔を加えた時刻を、現在時刻が過ぎているか調べる。そうである場合は、クライアントからの状態通知が途絶えているため、クライアントが生存していないと判断し、604へ進む。そうでなければ、クライアントは正常であると判断し、600へ戻る。
【００５１】
604は、クライアントの異常を検出した際の処理である。ここでは、予め設定された管理者のメールアドレスに対して、異常を通知するものとする。
【００５２】
なお、上記で説明した動作フローは一例であり、上記の処理の流れに限定されるものではない。
【図面の簡単な説明】
【００５３】
【図１】システムの構成。
【図２】デジタル複合機再起動時のシーケンス。
【図３】デジタル複合機の構成（抜粋）。
【図４】クライアント状態データの構造。
【図５】サーバのクライアント状態データ受信部の基本的な処理フロー。
【図６】サーバのクライアント状態監視部の基本的な処理フロー。
【符号の説明】
【００５４】
100〜101 デジタル複合機(クライアント)
102 Webブラウザ
103 サーバ
104 メールサーバ
200〜207 デジタル複合機再起動時の処理
300〜305 デジタル複合機のモジュール（抜粋）
400〜402 クライアント状態データの構成要素
500〜604 処理ステップ
【特許請求の範囲】
【請求項１】
クライアントからの定期的な状態通知によってクライアントの状態を監視する監視手段と、クライアントからの状態通知が途絶えたことでクライアントの動作が停止したと判断する生存確認手段を有するサーバと、
定期的にサーバに対して状態通知を行う状態通知手段を持つクライアントから構成される、
サーバ・クライアントシステムにおいて、
クライアントの有する上記状態通知手段は、状態通知を停止するにあたって状態通知を停止することと、その停止時間の予測値をサーバに通知することを特徴とし、
上記サーバの有する生存確認手段は、クライアントから状態通知の停止を受信後、受信した停止時間内はクライアントからの通知がなくともクライアントの動作が停止したと判断しないことを特徴とする、
サーバ・クライアントシステム。
【請求項１】
クライアントからの定期的な状態通知によってクライアントの状態を監視する監視手段と、クライアントからの状態通知が途絶えたことでクライアントの動作が停止したと判断する生存確認手段を有するサーバと、
定期的にサーバに対して状態通知を行う状態通知手段を持つクライアントから構成される、
サーバ・クライアントシステムにおいて、
クライアントの有する上記状態通知手段は、状態通知を停止するにあたって状態通知を停止することと、その停止時間の予測値をサーバに通知することを特徴とし、
上記サーバの有する生存確認手段は、クライアントから状態通知の停止を受信後、受信した停止時間内はクライアントからの通知がなくともクライアントの動作が停止したと判断しないことを特徴とする、
サーバ・クライアントシステム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図２】
【図３】
【図４】
【図５】
【図６】
【公開番号】特開２００８−７７３２４（Ｐ２００８−７７３２４Ａ）
【公開日】平成２０年４月３日（２００８．４．３）
【国際特許分類】
【出願番号】特願２００６−２５４５８８（Ｐ２００６−２５４５８８）
【出願日】平成１８年９月２０日（２００６．９．２０）
【出願人】（０００００１００７）キヤノン株式会社 (59,756)
【Ｆターム（参考）】
【公開日】平成２０年４月３日（２００８．４．３）
【国際特許分類】
【出願日】平成１８年９月２０日（２００６．９．２０）
【出願人】（０００００１００７）キヤノン株式会社 (59,756)
【Ｆターム（参考）】
[ Back to top ]