(57)【特許請求の範囲】
【請求項１】
同一のプロセス内における複数のアプリケーション間の通信処理を、前記複数のアプリケーションの内の一つのアプリケーションと前記アプリケーションが存在するプロセスとは別の他のプロセスとの間の通信処理または前記アプリケーションが存在する装置とは別の他の装置との間の通信処理に変換し、変換した通信処理を行う通信手段と、
前記通信手段による前記通信処理の実行中において発生した通信エラーを検出するエラー検出手段と、
前記通信エラーの種別と、当該通信エラーの種別に対応した通信エラーの重要度と、を予め定めた通信エラーの種別と重要度との対応関係から識別する識別手段と、
前記識別手段によって識別された重要度が一定値以上であるとエラー処理を実行する例外処理手段と、
を備えることを特徴とする通信制御装置。
【請求項２】
前記重要度が前記識別手段によって一定値以上と識別されると正常な通信の状態を示すフラグの設定を通信エラーの発生を示す設定に変更するフラグ設定手段を更に備えることを特徴とする請求項１に記載の通信制御装置。
【請求項３】
前記通信エラーの種別と、当該通信エラーの種別に対応した通信エラーの重要度と、の対応関係を記憶する記憶手段と、
前記識別手段によって識別された前記重要度が一定値以上であると前記通信エラーの種別を前記記憶手段に出力する情報記憶手段と、を更に備えることを特徴とする請求項１または２に記載の通信制御装置。
【請求項４】
前記例外処理手段は、前記識別手段によって識別された重要度に応じて複数の例外処理フローを実行することを特徴とする請求項１乃至３のいずれか１項に記載の通信制御装置。
【請求項５】
前記通信手段は、前記複数のアプリケーション間のサブルーチンコールを他の装置との間の通信プロトコルに変換して通信することを特徴とする請求項１乃至４のいずれか１項に記載の通信制御装置。
【請求項６】
複数の通信制御装置において、一方の通信制御装置のアプリケーションから他方の通信制御装置のアプリケーションの関数を呼び出し相互に情報の送受信を行う通信制御システムであって、
前記通信制御装置は、
同一のプロセス内における複数のアプリケーション間の通信処理を、前記複数のアプリケーションの内の一つのアプリケーションと前記アプリケーションが存在するプロセスとは別の他のプロセスとの間の通信処理または前記アプリケーションが存在する通信制御装置とは別の前記他方の通信制御装置との間の通信処理に変換し、変換した通信処理を行う通信手段と、
前記通信手段による前記通信処理の実行中において発生した通信エラーを検出するエラー検出手段と、
前記通信エラーの種別と、当該通信エラーの種別に対応した通信エラーの重要度と、を予め定めた通信エラーの種別と重要度との対応関係から識別する識別手段と、
前記識別手段によって識別された重要度が一定値以上の場合に、エラー処理を実行する例外処理手段と、を備えることを特徴とする通信制御システム。
【請求項７】
通信制御装置における通信制御方法であって、
前記通信制御装置の通信手段が、同一のプロセス内における複数のアプリケーション間の通信処理を、前記複数のアプリケーションの内の一つのアプリケーションと前記アプリケーションが存在するプロセスとは別の他のプロセスとの間の通信処理または前記アプリケーションが存在する通信制御装置とは別の他の通信制御装置との間の通信処理に変換し、変換した通信処理を行う通信工程と、
前記通信制御装置のエラー検出手段が、前記通信工程による前記通信処理の実行中において発生した通信エラーを検出するエラー検出工程と、
前記通信制御装置の識別手段が、前記通信エラーの種別と、当該通信エラーの種別に対応した通信エラーの重要度と、を予め定めた通信エラーの種別と重要度との対応関係から識別する識別工程と、
前記通信制御装置の例外処理手段が、前記識別手段によって識別された重要度が一定値以上の場合に、エラー処理を実行する例外処理工程と、
を有することを特徴とする通信制御方法。
【請求項８】
コンピュータを、請求項１乃至５のいずれか１項に記載の通信制御装置の各手段として機能させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信制御装置、通信制御システム、通信制御方法およびプログラムに関する。
【背景技術】
【０００２】
コンピュータ・ノード上の複数のソフトウェアコンポーネントが相互に通信しながら動作するプロセス間通信において、サブルーチンコール（関数呼び出し）のようにしてデータの通信が可能な手法がある（例えば、ＳｕｎＲＰＣ）。この手法によれば、プロセス間やノード間通信を用いて別プロセス（同じノード上でも別のノード上でもかまわない）とデータをやりとりすることができる。
【０００３】
一方、複数のプロセス、複数のコンピュータ・ノードにプロセス内の関数呼び出しを模擬するソフトウェア部品を配置し、ソフトウェア部品を再利用することによりソフトウェア開発効率の向上、品質の向上が目指されている。
【０００４】
しかし、プロセス内の関数呼び出しと同一のインターフェースを用いて、プロセス間あるいはノード間の通信（遠隔手続き）を行う場合、通信エラーが発生する可能性がある。プロセス内の関数を呼び出すように記述されたソフトウェアは、遠隔手続きにおける通信エラーを直接検出することができない。例えば、関数の戻り値がｖｏｉｄであったり、関数の実行結果を表す値のみを返す仕様等、呼び出された関数自身がエラーを返した場合以外に、プロセス内の関数呼び出しの仕様では、呼び出しの失敗は想定されていないからである。
【０００５】
この問題を解決するため、例外ハンドラやコールバックハンドラ（以下、総称して「ハンドラ」と呼ぶ）を使った方法が利用されている（Ｊａｖａ（登録商標）言語におけるｃａｔｃｈ構文、Ｃ言語におけるシグナルハンドラなどが相当する）。この方法では、関数呼び出しの仕様はエラーを考慮しない仕様のまま、呼び出し側プロセス内にエラー処理を行うためのスレッドを用意する。同時に、通信エラーを検出するとこのスレッドにエラー処理あるいはエラー復帰のための特殊な関数を実行させることによって、関数の仕様には影響せずに通信エラーの検出と対応を行うものである。
【０００６】
ハンドラを使用しないエラー処理技術に関しては、先行技術として特許文献１や特許文献２などが提案されている。
【０００７】
特許文献１には、複数のプロセスを実行するシステムにおいて、各プロセスに予めエラー検証のための検証プログラムコードを付加しておく構成が開示されている。そして、通信エラーなどシステム異常が発生したことを検証プログラムコードによって検出し、システム復旧を行う手法が開示されている。特許文献１は、特別に付与されたプログラムコードによってエラーの検出を行うため、関数戻り値の仕様などは通信エラーの発生検出を意図したものではない。
【０００８】
特許文献２は、関数のリモート呼び出しにおいてクライアント側にタイムアウト機構を設けることにより、サーバ側からクライアント側への通信におけるエラーを検出する構成が開示されている。ここで、タイムアウト機構の実装されるクライアント側とは、リモート関数呼び出し機構自体を指しており、関数を呼び出す部分の実装にエラー検出機構が含まれるものではない。
【先行技術文献】
【特許文献】
【０００９】
【特許文献１】特許０３２９００５２号公報
【特許文献２】特開２００１−２８２６５６号公報
【発明の概要】
【発明が解決しようとする課題】
【００１０】
ハンドラを用いたエラー検出手法では、プロセス毎にエラー検出部を実装する必要がある。プロセス内で関数呼び出しを行っていたソフトウェアをそのまま遠隔手続きを行うプログラムとして再利用し、開発効率を向上させようとする目的に鑑みると、プロセス毎にコードの修正量が多くなってしまい望ましくない。プログラムコードの修正量を減らす観点からは、遠隔手続き呼び出しライブラリにエラー検出部を実装する手法も考えられる。しかしこの手法は、遠隔手続き呼び出しライブラリにエラー検出機能、およびエラーからの復帰、エラー処理機能を実装することになる。エラー検出機能・エラー処理機能は、一般的に、ソフトウェアシステムが動作するハードウェアに依存するものである。ハードウェアへの依存の強いソフトウェアをライブラリ内に実装した場合、同ライブラリを他のハードウェアで動作するシステムに移植する際には、ハードウェアへの依存性の観点から汎用性が減ずるという問題がある。
【００１１】
特許文献１では、各プロセスに予めエラー検証のための検証プログラムコードを付加しておくことが必要である。この検証プログラムコードは一般的にウォッチドッグ、ハートビートなどと呼ばれるものである。この手法では例外ハンドラやコールバックハンドラを用いる手法と同じくプロセス毎に例外処理を実装する必要がある。そのため、多数のプロセスから構成される分散システムにおいては実装しなければならないコードの量が多く開発効率の点で問題がある。
【００１２】
特許文献２では、検出できる通信エラーがサーバ側からクライアント側への送信時のエラーに限られていること、また、タイムアウト機構をクライアント側に実装しなければいけない。そのため、特許文献１の手法と同じく実装コードの量が多いことから開発効率、またクライアント側からサーバ側へのエラーが検出できないことからエラー発生の補足性能の点で問題がある。
【課題を解決するための手段】
【００１３】
分散型のシステムではほとんどの場合、システムに複数プロセスで共有されるログシステムを有し、各プロセスはログシステムへの出力を行うログ出力機能を有している。一般的に、分散型のシステムでは複数のプロセスが協調してソフトウェアの機能を実現しており、ログをもとにシステムの動作やエラーの解析を行うためには、特定プロセスに属していない、システム全体で統一されたログが必要となる。このことが、ログシステムの存在する理由である。
【００１４】
本発明は、複数のプロセスで共有されるログ出力機能をエラー検出に利用した通信制御技術を提供することを目的とする。
【００１５】
上記の目的を達成する本発明の一つの側面にかかる通信制御装置は、
同一のプロセス内における複数のアプリケーション間の通信処理を、前記複数のアプリケーションの内の一つのアプリケーションと前記アプリケーションが存在するプロセスとは別の他のプロセスとの間の通信処理または前記アプリケーションが存在する装置とは別の他の装置との間の通信処理に変換し、変換した通信処理を行う通信手段と、
前記通信手段による前記通信処理の実行中において発生した通信エラーを検出するエラー検出手段と、
前記通信エラーの種別と、当該通信エラーの種別に対応した通信エラーの重要度と、を予め定めた通信エラーの種別と重要度との対応関係から識別する識別手段と、
前記識別手段によって識別された重要度が一定値以上であるとエラー処理を実行する例外処理手段と、
を備えることを特徴とする。
【発明の効果】
【００１６】
本発明によれば、ログ出力機能をエラー検出に利用した通信制御技術の提供が可能になる。
【００１７】
ログ出力機能をエラー検出にも利用することにより、各プロセスにエラー検出部を実装する必要がなく、呼び出し側のコード修正量が少なくて済むため、ソフトウェアの再利用性を高め開発効率を向上させることが可能になる。
【００１８】
あるいは、エラー状態フラグを介して間接的に通信エラーの検出と通知を行うことにより、プロセス内の関数呼び出しを、特定のハードウェアの機能への依存の少ない、汎用的な遠隔呼び出し処理に適用することが可能になる。
【図面の簡単な説明】
【００１９】
【図１】本発明の実施形態にかかる通信制御装置の構成例を示す図。
【図２】遠隔呼び出しライブラリの備える機能構成を説明する図。
【図３】情報記憶部から出力されるログの種別と、ログの重要度のレベルとの対応関係を示す図。
【図４】エラー検出時の処理の流れを説明する図。
【図５】エラー通知部によるエラー状態フラグの監視と、監視結果に伴う処理の流れを説明する図。
【図６】例外処理部によるエラー処理の流れを説明する図。
【発明を実施するための形態】
【００２０】
本発明は、同一プロセス内の通信を、プログラムコードの大幅な変更を伴わずにプロセス間あるいはノード間の通信に適用して、通信処理を行う技術を提供する。ここで、同一プロセス内の通信とは、例えば、一のアプリケーションから他のアプリケーションの関数を呼び出し、アプリケーション間で情報の送受信を行うための通信をいい、以下、この通信を関数呼び出しともいう。また、プロセス間あるいはノード間の通信とは、例えば、異なるプロセス間あるいは通信制御装置（ノード）間において、一方のアプリケーションから他方のアプリケーションの関数を呼び出し、相互に情報の送受信を行うための通信をいう。以下、この通信を遠隔呼び出しともいう。
【００２１】
本発明の実施形態にかかる通信制御装置の構成を図面の参照により説明する。
【００２２】
図１は通信制御システムを構成する通信制御装置の構成例を示す図である。通信制御システムを構成する通信制御装置（ノード０１）１０１上に、ＣＰＵ１０２、ネットワークコントローラ１０３およびメモリ１０４が配置されており、システムバス１０５によって相互に接続されている。メモリ１０４はＣＰＵ１０２の備えるメモリ保護機構によってプロセス毎に分割されている。通信制御装置（ノード０１）１０１でプロセスＡ、プロセスＢが動作している場合は、メモリ１０４内にプロセスＡのメモリ空間１０６、プロセスＢのメモリ空間１０７が存在する。
【００２３】
また、これらに加えてメモリ１０４上には、ノード毎に唯一存在するエラー状態フラグ１０８、エラー通知部１０９、およびエラー処理を実行する例外処理部１１０が存在する。プロセスＡのメモリ空間１０６内には、プロセスＡ上で動作するアプリケーション１１１およびアプリケーション１１１にリンクされる遠隔呼び出しライブラリ１１２が配置されている。同様にプロセスＢのメモリ空間１０７内には、アプリケーション１１３およびアプリケーション１１３にリンクされる遠隔呼び出しライブラリ１１４が配置されている。これらはプロセス毎に配置されるものである。
【００２４】
通信制御装置（ノード０１）１０１は、ネットワークコントローラ１０３により、確立された通信路１１５を経由して、通信制御装置（ノード０２）１１６と接続されている。通信制御装置（ノード０２）１１６も通信制御装置（ノード０１）１０１と同様の構成を有しており、通信制御装置（ノード０１）１０１のプロセスＡ，Ｂは通信路１１５を経由して通信制御装置（ノード０２）１１６のプロセスＣ、Ｄと通信可能である。
【００２５】
図２は、図１における遠隔呼び出しライブラリ１１２の備える機能構成を説明する図である。通信制御装置（ノード０１）１０１と通信制御装置（ノード０２）１１６とを有するシステムにおいて、通信制御装置（ノード０１）１０１においてプロセスＡが動作しており、プロセスＡのメモリ空間１０６上ではアプリケーション１１１が動作している。
【００２６】
アプリケーション１１１は、同一のプロセスＡのメモリ空間１０６内に存在する他のアプリケーションに属する関数を呼び出し、通信処理を行うようプログラムされている。遠隔呼び出しライブラリ１１２は、プロセスＡのメモリ空間１０６内でアプリケーション１１１とリンクされている。
【００２７】
遠隔呼び出しライブラリ１１２は、通信処理を行う通信部２０６を備える。通信部２０６は、アプリケーション１１１からのプロセス内における関数の呼び出し処理（通信処理）を、他のプロセスとの間の通信処理または他の通信制御装置との間の通信処理、通信プロトコルに変換し、通信処理を行うことを特徴としている。通信部２０６は、例えば、アプリケーション１１１からのプロセス内における関数の呼び出し処理（サブルーチンコール）を、他のアプリケーション、他のプロセス間あるいは他のノード間との間の通信処理（遠隔呼び出し）に変換する。
【００２８】
アプリケーション１１１の通信相手となる他のアプリケーションは、アプリケーション１１１と同一のプロセスＡのメモリ空間１０６内に配置されていてもよい。また、他のアプリケーションは、同一の通信制御装置（ノード０１）１０１上、または、通信制御装置（ノード０１）１０１と異なる別のノードである通信制御装置（ノード０２）１１６上に配置されていてもよい。
【００２９】
また、遠隔呼び出しライブラリ１１２は、通信に係るエラーを検出するエラー検出部２０７および、通信をはじめとするライブラリ自身の動作状態を出力するための情報記憶部２０８を備えている。本実施形態においては、情報記憶部２０８の情報記憶機能として記憶媒体にエラーログを出力する機能が実装されているものとする。ここで、記録媒体とは、磁気ディスク上の特定ファイルでも、メモリ上の特定の領域でもよく、ログ記録用の専用マシン上に確保された記憶領域であってもよい。
【００３０】
遠隔呼び出しライブラリ１１２は、エラー検出部２０７によって通信エラーが検出され、情報記憶部２０８から出力されるログの種別を判定し、通信エラーの重要度を識別する記録情報識別部２０９を備える。エラー検出部２０７で通信エラーが検出され、情報記憶部２０８から通信エラーに係るエラーログが出力される際、記録情報識別部２０９は、例外処理部１１０に対して例外処理を促す重要な通信エラーであるか否かを判断する。
【００３１】
更に、遠隔呼び出しライブラリ１１２は、記録情報識別部２０９によって通信エラーが重要なものと判断された場合、エラー状態フラグ１０８を、非シグナル状態からシグナル状態とするフラグ設定部２１０を備えている。ここで、非シグナル状態とは、システムが正常動作をしていることを示し、シグナル状態とは、通信エラー状態の発生を示す。
【００３２】
更に、通信制御装置（ノード０１）１０１上には、エラー通知部１０９が設けられている。エラー通知部１０９は、フラグ設定部２１０によってエラー状態フラグ１０８がシグナル状態に変更された場合に、例外処理部１１０に対してエラーが起きたことを通知し、例外処理（エラー処理）の実行を促す。
【００３３】
図３は、情報記憶部２０８から出力されるログの種別３０１と、ログの重要度のレベル３０２との対応関係を示す図である。通信エラーの種別（ログの種別）と、通信エラーの種別に対応した通信エラーの重要度を示すログレベルとの対応関係は、予め、通信制御装置のメモリ１０４または外部のハードディスク等に記憶しておくことが可能である。
【００３４】
ログの重要度のレベル３０２とログの種別３０１とは、１対１に対応している。記録情報識別部２０９は、情報記憶部２０８から出力されるログの種別３０１を識別することにより、ログの種別に対応しているログの重要度のレベル３０２を判定することができる。本実施形態では、ログの重要度のレベル３０２の数値は、小さいほど、重要度が高いログであることを示している。すなわち、ログの重要度のレベル３０２（ログレベル）の「１」に対応するログ種別、ＬＯＧ＿ＦＡＴＡＬ３０３が最も重要度の高いログ種別になる。ＬＯＧ＿ＦＡＴＡＬ３０３は、例えば、ハードウェアエラー、オペレーティングシステムの内部エラーなど復帰不能な深刻なエラーの属性を表す。ログレベル「２」に対応するログ種別は、ＬＯＧ＿ＥＲＲＯＲ３０４であり、これは通信エラーなど処理の継続ができない重要なエラーを表す。ログレベル「３」に対応するログ種別は、ＬＯＧ＿ＷＡＲＮＩＮＧ３０５であり、処理のタイムアウトなど、処理の継続が可能な軽微な異常を表す。ログレベル「４」に対応するログ種別は、ＬＯＧ＿ＩＮＦＯ３０６であり、システムの動作状態を予防的に知るための、正常状態でも出力されるログである。ログレベル「５」に対応するログの種別は、ＬＯＧ＿ＤＥＢＵＧ３０７であり、システムのデバッグ時や障害解析時にのみ使用されるような、システムの詳細な内部動作状態を出力するためのログである。
【００３５】
記録情報識別部２０９は、これらのログレベルを利用して、フラグ設定部２１０を作動させるか否かの判定を行ない、判定結果によりフラグ設定部２１０を制御することが可能である。例えば、ログの種別として、ＬＯＧ＿ＦＡＴＡＬ（ログレベル１）またはＬＯＧ＿ＥＲＲＯＲ（ログレベル２）が出力された場合のみ、記録情報識別部２０９は、フラグ設定部２１０を作動させることが可能である。一方、それ以外のログ種別の場合、記録情報識別部２０９は、フラグ設定部２１０を作動させないように制御することが可能である。
【００３６】
システムの仕様によりエラーの種別を表現するログ属性が存在しない場合には、一定以上の重要なエラーログが出力されたという条件で、記録情報識別部２０９は、フラグ設定部２１０を作動させることが可能である。また、ログレベルが特定できない場合、全てのエラーログを対象として、記録情報識別部２０９は、フラグ設定部２１０を作動させることも可能である。
【００３７】
（エラー検出時の処理フロー）
エラー検出時の処理フローを図４の参照により説明する。まず、通信部２０６による通信処理の実行中、エラー検出部２０７によって、「通信エラー」が検出されると、本処理がスタートする（ステップＳ４０１）。次に、ステップＳ４０２において、記録情報識別部２０９は、検出された通信エラーのログの種別を決定し、通信エラーの重要度を識別する。例えば、「通信エラー」は、図３に示すログの属性、ＬＯＧ＿ＥＲＲＯＲ３０４に相当し、対応するログレベルは「２」である。
【００３８】
ログの種別が決定されると、ステップＳ４０３において、情報記憶部２０８によりログが出力される。
【００３９】
情報記憶部２０８は、通信制御装置（ノード０１）１０１の外部のハードディスク、または通信制御装置（ノード０１）１０１のメモリ１０４上の特定領域に、ログレベルの高低に応じてログの出力先を制御することが可能である。例えば、情報記憶部２０８は、重要度の高いログレベル１、２のみについて、外部のハードディスク、またはメモリ１０４ログを出力するように制御することも可能である。
【００４０】
ステップＳ４０３において、ログ出力が行われると、ステップＳ４０４において、記録情報識別部２０９は、先のステップＳ４０３で出力されたログレベルが一定以上のレベルであるか否かを識別する。本ステップの処理は、例外処理を行うか否かの閾値を設定することに相当する。ログレベルを一定以上とすることにより、正常状態でも出力され得る軽微なログによって例外処理が起動されてしまわないように制御することができる。
【００４１】
ステップＳ４０４の判定で、ログレベルが一定値未満の場合（Ｓ４０４−Ｎ０）、処理は終了し（Ｓ４０６）、ログレベルが一定値以上の場合（Ｓ４０４−Ｙｅｓ）、処理はステップＳ４０５に進められ、フラグ設定処理が実行される。ステップＳ４０５において、記録情報識別部２０９は、フラグ設定部２１０を作動させことによりエラー状態フラグ１０８を更新し、ログレベルが一定値以上の高いレベルにある通信エラー状態の発生を示すシグナル状態に設定する。
【００４２】
（エラー通知部１０９によるフラグ監視フロー）
図５は、エラー通知部１０９により実行されるエラー状態フラグ１０８の監視と、監視結果に伴う処理の流れを説明する図である。ステップＳ５０１において、エラー通知部１０９は、システム起動後の任意の時点でエラー状態フラグ１０８の監視を開始する。ここで、監視とは、初期状態として設定されているエラー状態フラグ１０８のログレベルが一定値未満であることを示す非シグナル状態から、ログレベルが一定値以上であることを示すシグナル状態への変化を検知することをいう。監視の方法は一定時間ごとにエラー状態フラグ１０８をチェックするポーリングによってもよいし、イベントなどシステム固有の方法で受動的にフラグ状態の変化を示す情報を、エラー通知部１０９が受信するようにしてもよい。
【００４３】
監視中にエラー状態フラグ１０８が非シグナル状態からシグナル状態への設定変更を検出すると（Ｓ５０２−Ｙｅｓ）、ステップＳ５０３において、エラー通知部１０９は、例外処理部１１０にエラーの発生を通知（エラー通知）する。エラー通知を受けた例外処理部１１０の具体的な処理内容については図６を用いて詳細に説明する。
【００４４】
（例外処理部１１０によるエラー処理フロー）
図６は、エラー通知部１０９からエラー通知を受けた例外処理部１１０によるエラー処理の流れを説明する図である。
【００４５】
まず、ステップＳ６０１において、例外処理部１１０がエラー通知部１０９からエラー通知を受信すると、本処理がスタートする。ステップＳ６０２において、例外処理部１１０は、ユーザインタフェース（ＵＩ）画面にエラーが発生したこと（エラー状態）を表示する。その後、ステップＳ６０３において、例外処理部１１０は、システムに属する全てのプロセスを終了させる。そして、ステップＳ６０４において、例外処理部１１０は、ハードウェアをシャットダウンすることにより、例外処理を終了する（ステップＳ６０５）。
【００４６】
この例外処理とはシステムが深刻な異常状態に陥った際に行われる処理で、アプリケーションが動作するハードウェアに依存するものである。図６の例外処理として、全システムの停止、およびハードウェアのシャットダウンは一例であり、復帰可能なエラーの場合はプロセスを終了させずに再起動させてもよい。また、エラーの程度（ログレベル）に応じて複数の例外処理フローを実行するようにしてもよい。また、ハードウェアを停止ないし再起動する処理であってもよく、アプリケーションの全体あるいは一部分を停止ないし再起動する処理であってもよく、また、システムに特有のエラーからの復帰を行う処理であってもよい。
【００４７】
本実施形態によれば、ログ出力機能をエラー検出に利用した通信制御技術が提供される。ログ出力機能をエラー検出にも利用することにより、各プロセスにエラー検出部を実装する必要がなく、呼び出し側のコード修正量が少なくて済むため、ソフトウェアの再利用性を高め開発効率を向上させることが可能になる。エラー状態フラグを介して間接的に通信エラーの検出と通知を行うことにより、プロセス内の関数呼び出しを、特定のハードウェアの機能への依存の少ない、汎用的な遠隔呼び出し処理に適用することが可能になる。
【００４８】
（その他の実施例）
また、本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。
【図１】
0005871499.tif 000002
【図２】
0005871499.tif 000003
【図３】
0005871499.tif 000004
【図４】
0005871499.tif 000005
【図５】
0005871499.tif 000006
【図６】
0005871499.tif 000007