(57)【要約】【課題】  ＩＰ網を介してホスト間通信を実施する通信システムにおいて、通信制御プロセス異常終了時におけるパケット損失を回避する情報処理装置に関するものである。【解決手段】  本発明による情報処理装置は、データ処理を実行する機能部プロセス１１０と、機能部プロセス１１０と通信し、機能部プロセス１１０からのパケットを受信し、バッファ１２３に蓄積されているパケットを機能部プロセス１１０へ送信するプロセス間通信部１２４と、受信されたパケットが書き込まれるバッファ１２３を有し、通信制御処理を実行する通信制御プロセス１２０と、機能部プロセス１１０と通信制御プロセス１２０とが共有してアクセス可能な共有メモリ１４０と、機能部プロセス１１０の生存状態を確認し、機能部プロセス１１０がダウンした場合、機能部プロセス１１０を再起動させる監視プロセス１３０とを備える。【選択図】  図１
2005284924.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークを介して通信端末にデータを提供する情報処理装置であって、
データ処理を実行する機能部プロセス実行部と、
前記機能部プロセス実行部と通信し、前記機能部プロセス実行部からのパケットを受信し、バッファに蓄積されているパケットを前記機能部プロセス実行部へ送信するプロセス間通信部と、受信されたパケットが書き込まれるバッファを有し、通信制御処理を実行する通信制御プロセス実行部と、
前記機能部プロセス実行部と前記通信制御プロセス実行部とが共有してアクセス可能な共有メモリと、
前記機能部プロセス実行部の生存状態を確認し、前記機能部プロセス実行部がダウンした場合、機能部プロセス実行部を再起動させる監視プロセス実行部と
を備え、
再起動された機能部プロセス実行部は前記共有メモリからダウン直前のデータを読み込むこと
を特徴とする情報処理装置。
【請求項２】
ネットワークを介して通信端末にデータを提供する情報処理装置であって、
データ処理を実行する機能部プロセス実行部と、
前記機能部プロセス実行部と通信し、前記機能部プロセス実行部からのパケットを受信し、バッファに蓄積されているパケットを前記機能部プロセス実行部へ送信するプロセス間通信部と、受信されたパケットが書き込まれるバッファを有し、通信制御処理を実行する通信制御プロセス実行部と、
前記機能部プロセス実行部と前記通信制御プロセス実行部とが共有してアクセス可能な共有メモリと、
セッションの確立を行い、前記機能部プロセス実行部が実行するプロセスを生成し、前記セッションを前記機能部プロセス実行部に引き継がせ、前記機能部プロセス実行部の生存状態を確認し、前記機能部プロセス実行部がダウンした場合、機能部プロセス実行部を再起動させる親プロセス実行部とを備え、
再起動された機能部プロセス実行部は前記共有メモリからダウン直前のデータを読み込むこと
を特徴とする情報処理装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＩＰ（Internet Protocol）網を介してホスト間通信を実施する通信システムにおいて、通信制御プロセス異常終了時におけるパケット損失を回避する情報処理装置に関するものである。
【背景技術】
【０００２】
ＩＰ網に接続されたＬｉｎｕｘやＵＮＩＸ（登録商標）システムにおける、従来のネットワーク通信を実施するプロセスについて、図９および図１０を用いて説明する。図９は、従来技術におけるサーバの第１のシステム構成を示す図である。図１０は、従来技術におけるサーバの第２のシステム構成を示す図である。
【０００３】
図９には、サーバ１００のコネクションレス型であるＵＤＰ（User Datagram Protocol）を用いた場合の従来の通信例を示す。通常、ネットワーク２を介してネットワーク通信を実施する通信制御部１６２と他の機能、例えば端末の管理やサービスに使用するデータの管理を行う機能部１６１は同一プロセス１６０内に存在する。また、コネクションレス型であるので、全通信端末３０１〜３０ｎからのパケットを同一のプロセスで受信する。このとき、ソフトウェアの不具合などにより、プロセスが異常終了すると、全通信端末３０１〜３０ｎからのパケットが損失する。
【０００４】
また図１０には、サーバ１００のコネクション型であるＴＣＰ（Transmission Control Protocol）を用いた場合のモデルを示す。ＴＣＰの場合もＵＤＰと同様、ネットワーク２を介してネットワーク通信を実施する通信制御部１６２（１６２−１〜１６２−ｎ）と他の機能を行う機能部１６１（１６１−１〜１６２−ｎ）は同一プロセス１６０（１６０−１〜１６０−ｎ）内に存在する。ＵＤＰとの違いは、ＴＣＰでは一般にセッションごとにプロセスあるいはスレッドを用意し、各セッションにおけるパケットの送受信は、セッションごとのプロセスが実施する。親プロセス１５０は、ＴＣＰセッション確立までの処理（3 way handshakeに相当する処理）のみを実施し、ＴＣＰセッション確立後は、子プロセス１６０−１〜１６０−ｎに処理を引き継がせる。このとき、ソフトウェアの不具合などにより、プロセスが異常終了すると、通信端末３０１〜３０ｎからのセッションが切断される。
【０００５】
また、ＴＣＰの場合のネットワーク通信プロセス障害復旧方式として、特開平１１−８５５５６号公報に記載される方式がある。特開平１１−８５５５６号公報に記載される方式では、プロセスを冗長化し、ＴＣＰセッションに関する情報（文献内ではネットワーク情報と呼んでいる）を共有メモリに書き込み、実行系プロセス障害発生時、待機系のプロセスがＴＣＰセッションに関する情報を読み込んで通信を引き継ぐ方式が述べられている。この方式では、ＴＣＰセッション切断は回避できる可能性があるものの、実行系のプロセスを切り替える間に受信したパケットを処理できないのでパケット損失となる。
【特許文献１】特開平１１−８５５５６号公報
【発明の開示】
【発明が解決しようとする課題】
【０００６】
しかし、上記に説明されるような従来の情報処理装置においては、ＩＰ網に接続されたＬｉｎｕｘやＵＮＩＸ（登録商標）系システムにおいて、従来は、ネットワーク通信を実施する部分と他の機能は同一プロセス内に存在するため、ソフトウェアの不具合などにより、プロセスが異常終了すると、端末からのパケットが損失するという課題があった。
また、特開平１１−８５５５６号公報にも、プロセス障害発生から待機系プロセス起動までにパケット損失が発生するという課題があった。
【０００７】
そもそも、プロセス障害の原因は、ソフトウェアの複雑化によりバグが発生しやすくなることである。特に複雑化するのは、プロセス内における機能部分である。一方、通信制御は、ＴＣＰやＵＤＰのパケット送受信などの汎用的な機能を提供するのみで、複雑化しない。例えば、ＬｉｎｕｘやＵＮＩＸ（登録商標）ではＴＣＰやＵＤＰパケットの送受信機能を提供するsocket、bind、listen、accept、send、recv関数などがＯＳ（オペレーティングシステム）から提供されている。プログラムは一般にこれらの関数を利用して通信する。
【０００８】
そこで、本発明は情報処理装置において、通信制御と機能部を別プロセスとし、複雑化した機能部プロセスに障害が発生しても、障害発生の可能性が低い通信制御プロセスにより、パケット損失やセッション切断を回避する方法を提供する。
【課題を解決するための手段】
【０００９】
かかる課題を解決するため、本発明による情報処理装置は、ネットワークを介して通信端末にデータを提供する通信装置であって、データ処理を実行する機能部プロセスと、  機能部プロセスと通信し、機能部プロセスからのパケットを受信し、バッファに蓄積されているパケットを機能部プロセスへ送信するプロセス間通信部と、受信されたパケットが書き込まれるバッファを有し、通信制御処理を実行する通信制御プロセスと、機能部プロセスと通信制御プロセスとが共有してアクセス可能な共有メモリと、機能部プロセスの生存状態を確認し、機能部プロセスがダウンした場合、機能部プロセスを再起動させる監視プロセスとを備え、再起動された機能部プロセス実行部は共有メモリからダウン直前のデータを読み込むことを特徴とする。
【発明の効果】
【００１０】
発明の効果として、本発明の情報処理装置によれば、情報処理装置の複雑になりがちなサービス提供機能部分と通信制御機能部分を、機能部プロセスと通信制御プロセスのように別プロセスとすることで、機能部プロセスがダウンした時も情報処理装置でのパケット損失を回避してサービスを再開することができる。
【発明を実施するための最良の形態】
【００１１】
本発明による情報処理装置は、通信制御部と機能部を別プロセスとして、通信制御プロセス実行部と機能部プロセス実行部とを備え、以下に記載される実施例１および実施例２を用いて説明される。
【実施例１】
【００１２】
以下、本発明による情報処理装置の実施例１は、ＵＤＰを用いた場合を例にして図１〜図４を用いて説明される。図１は本発明の実施例１におけるサーバのシステム構成を示す図である。図２は本発明の実施例１におけるサーバの通信制御プロセスの動作を示すフローチャート図である。図３は本発明の実施例１におけるサーバの機能部プロセスの動作を示すフローチャート図である。図４は本発明の実施例１におけるサーバの監視プロセスの動作を示す図である。
【００１３】
まず、図１を用いて本発明による実施例１のサーバのシステム構成が説明される。
図１において、サーバ１００はネットワーク２を介して複数の通信端末３０１〜３０ｎが接続される。
ネットワーク２を介して複数の通信端末３０１〜３０ｎにデータを提供するサーバ１００は、機能部プロセス１１０、通信制御プロセス１２０、監視プロセス１３０、共有メモリ１４０から構成される。
ネットワーク２は、例えば、ＶｏＩＰ（Voice over Internet Protocol）通信が可能なＩＰネットワークである。
通信端末３０１〜３０ｎは、ＶｏＩＰ通信機能を有する通信端末である。
【００１４】
データ処理を実行する機能部プロセス１１０は、例えば、ＶｏＩＰ通信における加入者の電話番号の管理、加入者間の通話の管理などのサービスに関する機能を提供するプロセス実行部である。上記のサービスに関する処理を行うのが機能部１１１である。また機能部プロセス１１０は、これらのサービス提供に必要なデータをすべて共有メモリ１４０上で管理する。
【００１５】
次に、図１において通信制御プロセス１２０は、通信制御プロセス１２０を構成する各機能について説明される。通信制御処理を実行するプロセス実行部である通信制御プロセス１２０は、パケット送信部１２１、パケット受信部１２２と、バッファ１２３、プロセス間通信部１２４から構成される。
【００１６】
パケット送信部１２１は、プロセス間通信部１２４からＩＰパケットを受信すると、ネットワーク２を介して複数の通信端末３０１〜３０ｎへＩＰパケットを送信する機能を有する。
パケット受信部１２２は、ネットワーク２を介して複数の通信端末３０１〜３０ｎからＩＰパケットを受信すると、ＩＰパケットをバッファ１２３に書き込む（蓄積する）機能を有する。
【００１７】
プロセス間通信部１２４は、機能部プロセス１１０と通信し、機能部プロセス１１０からのＩＰパケットを受信し、また、バッファ１２３に蓄積されているＩＰパケットを機能部プロセス１１０へ送信する機能を有する。
通信制御プロセス１２０は、機能部プロセス１１０がダウン中に、ネットワーク２を介して通信端末３０１〜３０ｎから受信したＩＰパケットをバッファ１２３に蓄積し続ける。
【００１８】
監視プロセス１３０は、機能部プロセス１１０の生存状態を定期的にまたは常時監視し、機能部プロセス１１０がソフトウェアの不具合などによりダウンしたことを検知する。そして監視プロセス１３０は、機能部プロセス１１０がダウンしたことを検知した場合、機能部プロセス１１０を再起動させるプロセス実行部である。
【００１９】
共有メモリ１４０は、機能部プロセス１１０と通信制御プロセス１２０とが共有してアクセス可能なメモリであり、使用されるデータが格納される。また、共有メモリ１４０に書き込まれたデータは、機能部プロセス１１０がダウンしても失われず、再起動された機能部プロセス１１０は、共有メモリ１４０にアクセスし、ダウン直前のデータを共有メモリ１４０から読み込むことが可能である。また、機能部プロセス１１０は、通信制御プロセス１２０へアクセスし、バッファ１２３に蓄積されているＩＰパケットを取得し、サービスを再開することが可能である。
【００２０】
以下、図２〜図４を用いて、本発明による実施例１の情報処理装置の動作が説明される。図２は、本発明の実施例１におけるサーバの通信制御プロセスの動作を示すフローチャート図である。図３は、サーバの機能部プロセスの動作を示すフローチャート図である。図４は、サーバの監視プロセスの動作を示すフローチャート図である。まず、図２を用いて、サーバの通信制御プロセスの動作が説明される。
【００２１】
図２において、通信制御プロセス１２０は、ステップＳ１０１で起動すると、ステップＳ１０２で図示されないＵＤＰポートをオープンし、ＵＤＰパケットを受信可能な状態とする。ステップＳ１０３は、通信制御プロセス１２０の終了判定を実施する。ステップＳ１０３で通信制御プロセス１２０を終了すると判定された場合は、ステップＳ１１０以降の通信制御プロセス１２０の終了処理へ移る。ステップＳ１０３で通信制御プロセス１２０を終了しないと判定された場合は、ステップＳ１０４へ移る。
【００２２】
ステップＳ１０４は、パケット受信部１２２がＩＰパケットを受信しているかどうかを判定する。ステップＳ１０４でパケット受信部１２２がＩＰパケットを受信しているとき、ステップＳ１０５へ移る。ステップＳ１０５でパケット受信部１２２がＩＰパケットを受信していないとき、ステップＳ１０６へ移る。ステップＳ１０５は受信したＩＰパケットをバッファ１２３へ書き込む処理である。ステップＳ１０５を終えるとステップＳ１０６へ移る。
【００２３】
ステップＳ１０６は、機能部プロセス１１０からＩＰパケットを受信したかを判定する。ステップＳ１０６で機能部プロセス１１０からＩＰパケットを受信したとき、ステップＳ１０７へ、機能部プロセス１１０からＩＰパケットを受信していない時はステップＳ１０８へ移る。ステップＳ１０７は、機能部プロセス１１０から受信したＩＰパケットをネットワーク２へ送出する処理である。ステップＳ１０７を完了すると、ステップＳ１０８へ移る。
【００２４】
ステップＳ１０８は機能部プロセス１１０からＩＰパケットの取得要求の有無を確認する。ステップＳ１０８で機能部プロセス１１０からＩＰパケットの取得要求があった時はステップＳ１０９へ移り、機能部プロセス１１０からＩＰパケットの取得要求がなかった時はステップＳ１０３へ戻る。ステップＳ１０９では、バッファ１２３に蓄積されているＩＰパケットを機能部プロセス１１０へ渡す。
【００２５】
ステップＳ１１０、ステップＳ１１１は通信制御プロセス１２０の終了処理である。ステップＳ１１０ではＵＤＰポートをクローズし、以後ＵＤＰパケットを受信しないようにする。ステップＳ１１１は通信制御プロセス１２０自身の終了である。
【００２６】
次に、図３を用いて、サーバの機能部プロセスの動作が説明される。
機能部プロセス１２０は、ステップＳ２０１で起動されると、ステップＳ２０２で共有メモリ１４０へアクセスし、データを読み込む。そして、共有メモリ１４０にデータが残っていれば、前回異常終了したと判断し、データを引き継ぐ。
【００２７】
ステップＳ２０３は、機能部プロセス１１０の終了判定を実施する。ステップＳ２０３で機能部プロセス１１０を終了すると判定された場合、ステップＳ２０５以降の終了処理へ移る。ステップＳ２０３で機能部プロセス１１０を終了しないと判定された場合、ステップＳ２０４へ移る。ステップＳ２０４は、機能部プロセス１１０で提供するサービスの処理を実施する。通信制御プロセス１２０からＩＰパケット取得、通信制御プロセス１２０へのパケット送出はステップＳ２０４の中で実施される。また、図３では省略しているが、一般に複雑化によりバグが埋め込まれるのはステップＳ２０４の中である。ステップＳ２０４を終えると、ステップＳ２０３へ戻る。
【００２８】
ステップＳ２０５、ステップＳ２０６は、機能部プロセス１１０の終了処理である。ステップＳ２０５は共有メモリ１４０のデータを削除する。ステップＳ２０５は機能部プロセス１１０自身の停止である。
【００２９】
さらに、図４を用いて、サーバの監視プロセスの動作が説明される。
監視プロセス１３０は、ステップＳ３０１で起動されると、ステップＳ３０２に移り、監視プロセス１３０の終了判定を実施する。ステップ３０２で監視プロセス１３０を終了すると判定された場合、ステップＳ３０６の終了処理へ移る。ステップＳ３０２で監視プロセスを終了しないと判定された場合、ステップＳ３０３へ移る。ステップＳ３０３は、監視プロセス１３０が機能部プロセスの生存状態の監視を開始する。
【００３０】
ステップＳ３０４は、機能部プロセス１１０がソフトウェアの不具合などによりダウンしたかどうかを判定する処理である。ステップＳ３０４で、機能部プロセス１１０がダウンしたと判定された場合、ステップＳ３０５へ移る。ステップＳ３０４で、機能部プロセス１１０がダウンしていないと判定された場合、ステップＳ３０２に戻る。
【００３１】
ステップＳ３０５は、ダウンした機能部プロセス１１０を再起動作させる処理である。ステップＳ３０５で機能部プロセス１１０を再起動させると、ステップＳ３０２へ戻る。
【００３２】
以上のように、機能部プロセス１１０がダウンした時も、通信制御プロセス１２０がネットワーク２からのパケット受信を継続でき、機能部プロセス１１０が復旧時に通信制御プロセス１２０からパケットを取得することで、パケットロスを回避できる。
よって、実施例１の本発明のサーバによれば、サーバの複雑になりがちなサービス提供機能部分と通信制御を、機能部プロセスと通信制御プロセスのように別プロセスとすることで、機能部プロセスがダウンした時もパケット損失を発生させずに、サービスを再開することができる。
【実施例２】
【００３３】
以下、本発明による情報処理装置の実施例２は、ＴＣＰを用いた場合を例にして図５〜図８を用いて説明される。図５は本発明の実施例２におけるサーバのシステム構成を示す図である。図６は本発明の実施例２における通信制御プロセスの動作を示すフローチャート図である。図７は本発明の実施例２における機能部プロセスの動作を示すフローチャート図である。図８は本発明の実施例２における親プロセスの動作を示すフローチャート図である。
【００３４】
まず、図５を用いて本発明による実施例２のサーバのシステム構成が説明される。
図５において、サーバ１００は、実施例１で説明されたように、ネットワーク２を介して複数の通信端末３０１〜３０ｎが接続される。
ネットワーク２を介して複数の通信端末３０１〜３０ｎにデータを提供するサーバ１００は、実施例１で説明された機能部プロセス１１０、通信制御プロセス１２０および共有メモリを有し、さらに、ＴＣＰセッション確立までを処理する親プロセスを有する。
【００３５】
親プロセス１５０は、背景技術で述べられたように、ＴＣＰのセッション確立までを処理し、ＴＣＰセッションが確立すると、機能部プロセス１１０（１１０−１〜１１０−ｎ）が実行するプロセスを生成し、ＴＣＰセッションを機能部プロセス１１０へ引き継がせるプロセス実行部である。さらに親プロセス１５０は、機能部プロセス１１０の生存状態を確認し、機能部プロセス１１０がダウンした場合、機能部プロセス１１０を再起動させる。
【００３６】
機能部プロセス１１０は、実施例１で説明されたように、サービスに関する機能を提供し、これらのサービス提供に必要なデータをすべて共有メモリ１４０上で管理する。親プロセス１５０により再起動された機能部プロセス１１０は、共有メモリ１４０へアクセスし、ダウン直前のデータを取得する。そして、機能部プロセス１１０は、通信制御プロセス１２０へアクセスし、バッファ１２３に蓄積されているパケットを取得し、サービスを再開する。なお、実施例２で説明される機能部プロセス１１０は、実施例１で説明された機能部プロセス１１０と異なり、ＴＣＰセッションと1対１となっている。
【００３７】
本発明の特徴である通信制御プロセス１２０（１２０−１〜１２０−ｎ）は、実施例１で説明された通信制御プロセス１２０と同様に、パケット送信部１２１、パケット受信部１２２、バッファ１２３、プロセス間通信部１２４で構成される。なお、図５ではパケット送信部１２１、パケット受信部１２２、バッファ１２３、プロセス間通信部１２４の各機能ブロックを省略しているが、各機能ブロック間の関係は実施例１で説明された図１と同様の構成である。また各機能ブロックが提供する機能も実施例１と同じである。
【００３８】
以下、図６〜図８を用いて、本発明による実施例２の情報処理装置の動作が説明される。図６は本発明の実施例２における通信制御プロセスの動作を示すフローチャート図である。図７は本発明の実施例２における機能部プロセスの動作を示すフローチャート図である。図８は本発明の実施例２における親プロセスの動作を示すフローチャート図である。まず、図６を用いて、サーバの通信制御プロセスの動作が説明される。
【００３９】
図６において、通信制御プロセス１２０は、ステップＳ４０１で起動すると、ステップＳ４０２でＴＣＰセッションを親プロセス１５０から機能部プロセス１１０経由で引継ぎ、ＴＣＰパケットを受信可能な状態とする。ステップＳ４０２は、通信制御プロセス１２０の終了判定を実施する。ステップＳ４０３で通信制御プロセス１２０を終了すると判定された場合、ステップＳ４１０以降の終了処理へ移る。ステップＳ４０３で通信制御プロセス１２０を終了しないと判定された場合、ステップＳ４０４へ移る。
【００４０】
ステップＳ４０４は、パケット受信部１２２がパケットを受信しているかどうかを判定する。ステップＳ４０４でパケット受信部１２２がパケットを受信しているとき、ステップＳ４０５へ移る。ステップＳ４０４でパケット受信部１２２がパケットを受信していないとき、ステップＳ４０６へ移る。ステップＳ４０５は受信したパケットをバッファへ書き込む処理である。ステップＳ４０５を終えるとステップＳ４０６へ移る。
【００４１】
ステップＳ４０６は、機能部プロセス１１０からパケットを受信したかを判定する。ステップＳ４０６で機能部プロセス１１０からパケットを受信したとき、ステップＳ４０７へ、機能部プロセス１１０からパケットを受信していない時はステップＳ４０８へ移る。ステップＳ４０７は、機能部プロセス１１０から受信したパケットをＩＰ網へ送出する処理である。ステップＳ４０７を完了すると、ステップＳ４０８へ移る。
【００４２】
ステップＳ４０８は機能部プロセス１１０からパケットの取得要求の有無を確認する。ステップＳ４０８で機能部プロセス１１０からパケットの取得要求がある時はステップＳ４０９へ移り、機能部プロセス１１０からパケットの取得要求がない時はステップＳ４０３へ戻る。ステップＳ４０９では、バッファに蓄積されているパケットを機能部プロセス１１０へ渡す。
【００４３】
ステップＳ４１０、ステップＳ４１１は通信制御プロセス１２０の終了処理である。ステップＳ４１０ではＴＣＰセッションを切断し、以後ＴＣＰパケットを受信しないようにする。ステップＳ４１１は通信制御プロセス１２０自身の終了である。
【００４４】
次に、図７を用いて、サーバの機能部プロセスの動作が説明される。機能部プロセス１１０は、ステップＳ５０１で起動されると、ステップＳ５０２で共有メモリ１４０へアクセスし、データを読み込む。共有メモリ１４０にデータが残っていれば、前回異常終了したと判断し、データを引き継ぐ。
【００４５】
ステップＳ５０３は、自機能部プロセス１２０に対応する通信制御プロセス１２０が存在するかを確認する。自機能部プロセス１２０に対応する通信制御プロセス１２０が存在する場合はステップＳ５０５へ移る。自機能部プロセス１２０に対応する通信制御プロセス１２０が存在しない場合は、ステップＳ５０４へ移る。ステップＳ５０４は、通信制御プロセス１２０の生成を実施し、親プロセス１５０が確立したＴＣＰセッションを引き継がせる。
【００４６】
ステップＳ５０５は、機能部プロセス１１０の終了判定を実施する。ステップＳ５０５で機能部プロセス１１０を終了すると判定された場合、ステップＳ５０７以降の終了処理へ移る。ステップＳ５０５で機能部プロセス１１０を終了しないと判定された場合、ステップＳ５０５へ移る。ステップＳ５０６は、機能部プロセス１１０で提供するサービスの処理を実施する。通信制御プロセス１２０からパケット取得、通信制御プロセス１２０へのパケット送出はステップＳ５０６の中で実施される。また、図７では省略しているが、一般に複雑化によりバグが埋め込まれるのはステップＳ５０６の中である。ステップＳ５０６を終えると、ステップＳ５０５へ戻る。
【００４７】
ステップＳ５０７、ステップＳ５０８、ステップＳ５０９は、機能部プロセス１１０の終了処理である。ステップＳ５０７は共有メモリ１４０のデータを削除する。ステップ５０８は、ＴＣＰセッションの切断処理である。ステップＳ５０９は機能部プロセス１１０自身の停止である。
【００４８】
さらに、図８を用いて、サーバの親プロセスの動作が説明される。図８において、親プロセス１５０は、ステップＳ６０１で起動すると、ステップＳ６０２で図示されないＴＣＰポートをオープンし、ＴＣＰパケットを受信可能な状態とする。ステップＳ６０３は、親プロセス１５０の終了判定を実施する。ステップＳ６０３で親プロセス１５０を終了すると判定された場合は、ステップＳ６０９以降の親プロセス１５０の終了処理へ移る。ステップＳ６０３で親プロセス１５０を終了しないと判定された場合は、ステップＳ６０４へ移る。
【００４９】
ステップＳ６０４は、親プロセス１５０が新たにＴＣＰセッションを確立したかを判定する。ステップＳ６０４で親プロセス１５０が新たにＴＣＰセッションを確立したとき、ステップＳ６０５へ移る。ステップＳ６０４で親プロセス１５０が新たにＴＣＰセッションを確立していないとき、ステップＳ６０７へ移る。ステップＳ６０５は全機能部プロセス１１０の生成を実施し、ステップＳ６０６でセッションを引き継がせる。
【００５０】
ステップＳ６０７は、いずれかの機能部プロセス１１０がダウンしたかどうかを判定する。ステップＳ６０７でいずれかの機能部プロセス１１０がダウンしたと判定された場合、ステップＳ６０８へ移る。ステップＳ６０７でいずれの機能部プロセス１１０もダウンしていない場合、ステップＳ６０３へ戻る。ステップＳ６０８はダウンした機能部プロセス１１０を再起動させる処理であり、ダウンした機能部プロセス１１０を再起動後、ステップＳ６０８に戻る。ステップＳ６０９、ステップＳ６１０、ステップＳ６１１は、親プロセス１５０の終了処理である。ステップＳ６０９ではＴＣＰポートをクローズし、以後ＴＣＰパケットを受信しないようにする。ステップＳ６１０は、全機能部プロセス１１０を終了させる処理である。ステップＳ６１１は、親プロセス１５０自身の停止である。
【００５１】
以上の方式により、機能部プロセス１１０がダウンした時、通信制御プロセス１２０がＴＣＰセッションを保持しつづけることで、パケット損失を回避でき、機能部プロセス１１０が復旧した後もＴＣＰセッションを再度確立する必要なく、サービスを継続できる。
以上のように、複雑になりがちなサービス提供機能部分と通信制御機能部分を、機能部プロセスと通信制御プロセスのように別プロセスとすることで、機能部プロセスがダウンした時もパケット損失を回避でき、サービスを再開できる。
また、実施例１で説明されたサーバ１００との違いは、実施例１はコネクションレス型の通信に適用する方法であったが、実施例２で説明されたサーバ１００は、コネクション型通信でもＴＣＰセッション切断を発生させないようにして本発明を適用できることを示した。
【図面の簡単な説明】
【００５２】
【図１】本発明の実施例１におけるサーバのシステム構成を示す図
【図２】本発明の実施例１におけるサーバの通信制御プロセスの動作を示すフローチャート図
【図３】本発明の実施例１におけるサーバの機能部プロセスの動作を示すフローチャート図
【図４】本発明の実施例１におけるサーバの監視プロセスの動作を示すフローチャート図
【図５】本発明の実施例２におけるサーバのシステム構成を示す図
【図６】本発明の実施例２におけるサーバの通信制御プロセスの動作を示すフローチャート図
【図７】本発明の実施例２におけるサーバの機能部プロセスの動作を示すフローチャート図
【図８】本発明の実施例２におけるサーバの親プロセスの動作を示すフローチャート図
【図９】従来技術におけるサーバの第１のシステム構成を示す図
【図１０】従来技術におけるサーバの第２のシステム構成を示す図
【符号の説明】
【００５３】
１００…サーバ、１１０…機能部プロセス、１１１…機能部、１２０…通信制御プロセス、１２１…パケット送信部、１２２…パケット受信部、１２３…バッファ、１２４…プロセス間通信部、１３０…監視プロセス、１４０…共有メモリ、１５０…親プロセス
【図１】
2005284924.tif 000003
【図２】
2005284924.tif 000004
【図３】
2005284924.tif 000005
【図４】
2005284924.tif 000006
【図５】
2005284924.tif 000007
【図６】
2005284924.tif 000008
【図７】
2005284924.tif 000009
【図８】
2005284924.tif 000010
【図９】
2005284924.tif 000011
【図１０】
2005284924.tif 000012