(57)【要約】【課題】 エンベデッドシステムで実行されるソフトウェアブロックのアプリケーション間に設定されているＴＣＰコネクションの状態を監視し、それによってＴＣＰコネクションを管理する。【解決手段】  任意の二つのアプリケーションの間に設定されたＴＣＰコネクションの設定情報及び前記ＴＣＰコネクションについてのＴＣＰセッションコネクティビティチェックのための設定値を保存しておき、当該設定情報及び設定値に従ってＳＣＣメッセージを生成して相手側のＴＣＰ/ＩＰカーネルに送信すると共に、この相手側のＴＣＰ/ＩＰカーネルからのＳＣＣ応答メッセージの受信の有無に基づいて前記ＴＣＰコネクションが正常に動作しているか否かをＴＣＰ/ＩＰカーネルにより判定する構成とする。  【選択図】  図９
2005228316.tif 000002
【特許請求の範囲】
【請求項１】
任意の二つのアプリケーションの間に設定されたＴＣＰコネクションを管理する装置であって、
前記ＴＣＰコネクションの設定情報及び前記ＴＣＰコネクションについてのＴＣＰセッションコネクティビティチェックのための設定値を保存しておき、当該設定情報及び設定値に従ってＳＣＣメッセージを生成して相手側のＴＣＰ/ＩＰカーネルに送信すると共に、この相手側のＴＣＰ/ＩＰカーネルからのＳＣＣ応答メッセージの受信の有無に基づいて前記ＴＣＰコネクションが正常に動作しているか否かを判定するＴＣＰ/ＩＰカーネルを含むこと
を特徴とするＴＣＰコネクション管理装置。
【請求項２】
前記ＴＣＰ/ＩＰカーネルは、前記二つのアプリケーションの間に設定されたＴＣＰコネクションについての設定情報及び前記ＴＣＰコネクションについてのＴＣＰセッションコネクティビティチェックのための設定値を保存する保存部と、
前記設定情報及び前記設定値に従ってＳＣＣメッセージを生成し、さらにＳＣＣメッセージを送信する時間であるか否かを判定して、その判定結果に基づいて前記生成されたＳＣＣメッセージを出力すると共に、前記相手側のＴＣＰ/ＩＰカーネルからのＳＣＣ応答メッセージの受信の有無に基づいて前記ＴＣＰコネクションが正常に動作しているか否かを判定する制御部と、
前記制御部から出力された前記ＳＣＣメッセージを受け取って前記相手側のＴＣＰ/ＩＰカーネルに送信する入出力部と、
前記ＳＣＣメッセージを送信する時間であるか否かを判定するためのタイマーと、を含むこと
を特徴とする請求項１記載のＴＣＰコネクション管理装置。
【請求項３】
前記ＴＣＰコネクションにより連結された二つのアプリケーションのうち前記ＴＣＰ/ＩＰカーネルの上位階層に存在するアプリケーションが、前記ＴＣＰコネクションの生成及び、生成されるＴＣＰコネクションについてのＴＣＰセッションコネクティビティチェックを実行することを前記ＴＣＰ/ＩＰカーネルに要請すること
を特徴とする請求項１記載のＴＣＰコネクション管理装置。
【請求項４】
前記ＴＣＰ/ＩＰカーネルは、前記アプリケーションから前記ＴＣＰコネクションについてのＴＣＰセッションコネクティビティチェックの要請を受け取ったときにだけ前記ＴＣＰコネクションについてのＴＣＰセッションコネクティビティチェックを実行すること
を特徴とする請求項３記載のＴＣＰコネクション管理装置。
【請求項５】
前記ＳＣＣメッセージ及び前記ＳＣＣ応答メッセージは、ＴＣＰコネクションの連結状態を監視するためのパケットであることを示すＳＣＣフラッグを制御フラッグに含むＴＣＰパケットであること
を特徴とする請求項１記載のＴＣＰコネクション管理装置。
【請求項６】
前記相手側のＴＣＰ/ＩＰカーネルにＳＣＣメッセージを送信した前記ＴＣＰ/ＩＰカーネルは、この相手側のＴＣＰ/ＩＰカーネルからＳＣＣ応答メッセージを所定の時間内に受信しないときには、前記二つのアプリケーションの間に設定されたＴＣＰコネクションに異常が発生したと判定すること
を特徴とする請求項１記載のＴＣＰコネクション管理装置。
【請求項７】
前記ＴＣＰセッションコネクティビティチェックのための設定値は、ＴＣＰセッションコネクティビティチェックを実行するか否かを選択する値を含むこと
を特徴とする請求項１記載のＴＣＰコネクション管理装置。
【請求項８】
前記ＴＣＰセッションコネクティビティチェックのための設定値は、前記ＳＣＣメッセージの送信条件を決める値としてｓｔｒｉｃｔ値を含むこと
を特徴とする請求項１記載のＴＣＰコネクション管理装置。
【請求項９】
前記ｓｔｒｉｃｔ値が設定されている場合には、前記ＴＣＰ/ＩＰカーネルは、周期的に前記相手側のＴＣＰ/ＩＰカーネルにＳＣＣメッセージを送信し、相手側のＴＣＰ/ＩＰカーネルからＳＣＣ応答メッセージを所定の時間内に受信しないときには、前記二つのアプリケーションの間に設定されたＴＣＰコネクションに異常が発生したと判定すること
を特徴とする請求項８記載のＴＣＰコネクション管理装置。
【請求項１０】
前記ｓｔｒｉｃｔ値が設定されていない場合には、前記ＴＣＰ/ＩＰカーネルは、前記二つのアプリケーションの間のＴＣＰ回線上に信号が存在しないときにＳＣＣメッセージを送信し、相手側のＴＣＰ/ＩＰカーネルからＳＣＣ応答メッセージが所定の時間以上受信されないときには、前記二つのアプリケーションの間に設定されたＴＣＰコネクションに異常が発生したと判定すること
を特徴とする請求項８記載のＴＣＰコネクション管理装置。
【請求項１１】
前記ＴＣＰコネクションについてのＴＣＰセッションコネクティビティチェックのための設定値は、前記ＳＣＣメッセージを送信する周期を設定する値を含むこと
を特徴とする請求項１記載のＴＣＰコネクション管理装置。
【請求項１２】
前記ＴＣＰ/ＩＰカーネルは、前記二つのアプリケーションの間に設定されたＴＣＰコネクションに異常が発生したと判定したときには、前記ＴＣＰコネクションを遮断すること
を特徴とする請求項１記載のＴＣＰコネクション管理装置。
【請求項１３】
任意の二つのアプリケーションの間に設定されたＴＣＰコネクションを管理する方法であって、
前記ＴＣＰコネクションがＴＣＰセッションコネクティビティチェックを要請するＴＣＰコネクションであるか否かを判定する第１のステップと、
ＴＣＰセッションコネクティビティチェックのためのＳＣＣメッセージを生成する第２のステップと、
前記生成されたＳＣＣメッセージを前記ＴＣＰコネクションを介して連結される相手側のＴＣＰ/ＩＰカーネルに送信する第３のステップと、
前記相手側のＴＣＰ/ＩＰカーネルから前記ＳＣＣメッセージについての応答メッセージが所定の時間内に受信されたか否かを判定し、前記応答メッセージが前記時間内に受信されないときには、前記ＴＣＰコネクションの動作が正常でないと判定する第４のステップと、を含むこと
を特徴とするＴＣＰコネクション管理方法。
【請求項１４】
前記動作が正常でないと判定されたＴＣＰコネクションを遮断する第５のステップをさらに含むこと
を特徴とする請求項１３記載のＴＣＰコネクション管理方法。
【請求項１５】
任意の二つのアプリケーションの間に設定されたＴＣＰコネクションを管理する方法であって、
前記ＴＣＰコネクションがＴＣＰセッションコネクティビティチェックを要請するＴＣＰコネクションであるか否かを判定する第１のステップと、
前記ＴＣＰコネクションの回線上にトラフィックが存在するか否かを判定する第２のステップと、
前記ＴＣＰコネクションの回線上にトラフィックが存在しないと判定したときには、ＴＣＰセッションコネクティビティチェックのためのＳＣＣメッセージを生成し、前記ＴＣＰコネクションを介して連結される相手側のＴＣＰ/ＩＰカーネルに当該ＳＣＣメッセージを送信する第３のステップと、
前記相手側のＴＣＰ/ＩＰカーネルから前記ＳＣＣメッセージについての応答メッセージが所定の時間内に受信されたか否かを判定し、前記応答メッセージが前記時間内に受信されないときには、前記ＴＣＰコネクションの動作が正常でないと判定する第４のステップと、を含むこと
を特徴とするＴＣＰコネクション管理方法。
【請求項１６】
任意の二つのアプリケーションの間に設定されたＴＣＰコネクションを管理する方法を実行する装置により実行可能な命令からなるプログラムを保存し、前記装置により読み取り可能なプログラム保存装置であって、
前記ＴＣＰコネクションを管理する方法は、
前記ＴＣＰコネクションがＴＣＰセッションコネクティビティチェックを要請するＴＣＰコネクションであるか否かを判定する第１のステップと、
ＴＣＰセッションコネクティビティチェックのためのＳＣＣメッセージを生成する第２のステップと、
前記生成されたＳＣＣメッセージを前記ＴＣＰコネクションを介して連結される相手側のＴＣＰ/ＩＰカーネルに送信する第３のステップと、
前記相手側のＴＣＰ/ＩＰカーネルから前記ＳＣＣメッセージについての応答メッセージが所定の時間内に受信されるか否かを判定し、前記応答メッセージが前記時間内に受信されないときには、前記ＴＣＰコネクションが正常に動作しないと判定する第４のステップと、を含むこと
を特徴とするプログラム保存装置。
【請求項１７】
前記方法は、正常に動作しないと判定されたＴＣＰコネクションを閉じる第５のステップをさらに含むこと
を特徴とする請求項１６記載のプログラム保存装置。
【請求項１８】
任意の二つのアプリケーションの間に設定されたＴＣＰコネクションを管理する方法を実行する装置により実行可能な命令からなるプログラムを保存し、前記装置により読み取り可能なプログラム保存装置であって、
前記ＴＣＰコネクションを管理する方法は、
前記ＴＣＰコネクションがＴＣＰセッションコネクティビティチェックを要請するＴＣＰコネクションであるか否かを判定する第１のステップと、
前記ＴＣＰコネクションの回線上にトラフィックが存在するか否かを判定する第２のステップと、
前記ＴＣＰコネクションの回線上にトラフィックが存在しないと判定したときには、ＴＣＰセッションコネクティビティチェックのためのＳＣＣメッセージを生成して、前記ＴＣＰコネクションを介して連結される相手側のＴＣＰ/ＩＰ カーネルに送信する第３のステップと、
前記相手側のＴＣＰ/ＩＰカーネルから前記ＳＣＣメッセージについての応答メッセージが所定の時間内に受信されるか否かを判定し、前記回答メッセージが前記時間内に受信されないときには、前記ＴＣＰコネクションが正常に動作しないと判定する第４のステップと、を含むこと
を特徴とするプログラム保存装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、エンベデッドシステム(Embedded System)におけるＴＣＰコネクション(Transmission Control Protocol Connection)管理装置及び方法に関し、より詳しくは、エンベデッドシステムで実行されるソフトウェアブロック間に設定されているＴＣＰコネクションの状態を監視し、それによってＴＣＰコネクションを管理するエンベデッドシステムにおけるＴＣＰコネクション管理装置、ＴＣＰコネクション管理方法及びプログラム保存装置に関する。
【背景技術】
【０００２】
エンベデッドシステム（例えば、組み込みシステムと呼ばれることもある）とは、特定ニーズに従う一つの単位グループに多数のプロセッサを備え、各々のプロセッサの相互機能協力により対応するグループが目的とするサービスを提供するシステムを意味する。即ち、エンベデッドシステムでは、目的達成への相互協力のために各プロセッサで動作するソフトウェア(以下、“Ｓ/Ｗ”と称する)ブロック間の連結が必要である。このため、エンベデッドシステムでは、特定のＳ/Ｗブロック間の連結に断絶及び異常動作が発生すると、他のＳ/Ｗブロックの機能にまで影響を及ぶことになる。したがって、特にエンベデッドシステムにおいては、コネクションの異常動作の有無を速やかに検知して、遮断することのできる管理装置及び方法が求められている。
【０００３】
一方、ネットワークシステムは、多数のＳ/Ｗブロックが相互に連動して動作しており、各々のＳ/Ｗブロック間の通信のために、共有メモリー(Shared Memory)、メッセージキュー(Message Queue)、ＴＣＰ/ＵＤＰ(User Datagram Protocol)/ＩＰ(Internet Protocol)などの多様な手法を使用している。その中で、共有メモリーやメッセージキューは、同一のハードウェア(以下、“Ｈ/Ｗ”と称する)ブロック内で動作するＳ/Ｗブロック間の通信のために使用され、ＴＣＰ/ＵＤＰ/ＩＰは、別個のＨ/Ｗブロックで動作するＳ/Ｗブロック間の通信のために使用される。 特に、大容量ネットワークシステムのような多数のＨ/Ｗブロックで構成されているエンベデッドシステムにおいては、Ｈ/Ｗブロック間の通信を実現し、より一層信頼性のある通信を実現するためにＴＣＰ/ＩＰが広く使用されている。その理由は、ＴＣＰは、パケットが伝送されたか否かを確認し、伝送されなかったパケットを再送信するため、例えばＵＤＰに比べて信頼度が高い通信方法であるからである。このようなＴＣＰが提供する高信頼性通信サービスは、送信側の上位層から送ったデータを受信側ＴＣＰ上位層に完全な形で提供することができる。
【０００４】
前記したように、ＴＣＰ/ＩＰは、ネットワークで信頼性ある通信を支援するために開発された。しかしながら、ＴＣＰ/ＩＰは、ポーリングプロトコル(Polling Protocol)ではない。ここで、ポーリングプロトコルとは、送信要求の有無を順次に問い合わせ、要求がある場合にはその端末装置に送信を開始するように命令し、要求がない場合には次の端末装置について問い合わせを行なう伝送制御方式のプロトコルを意味する。したがって、ＴＣＰでは、コネクションの状態を随時点検する過程を提供しない。
【０００５】
ここで、ＴＣＰにおいては、キープアライブタイマー(keepalive timer)がコネクションの状態を検査するが、これはピアコネクション(peer connection)の状態を検査するためではなくバッドピア(bad peer)を確認するためのものである。即ち、キープアライブタイマーは二つのＴＣＰ間の設定が長時間に亘ってアイドル(idle)状態になることを防止するために使用される。例えば、一のクライアントがサーバーとのＴＣＰコネクションを設定してデータを伝送した後、それ以上はデータを送信しないとすると、このクライアントはＴＣＰコネクションの設定を要請した側であり、サーバーはクライアントからＴＣＰコネクションの設定の要請を受けた側である。
【０００６】
そして、クライアントに異常が発生した場合、異常が発生したクライアントとサーバーとの間のＴＣＰコネクションは永久に連結された状態を維持するようになる。このような状況を解除するために、殆どのサーバーにはキープアライブタイマーが設けられている。サーバーは、クライアントからセグメントを受けるごとに、キープアライブタイマーのタイマー値を初期化する。タイマーの終了時間は一般的に２時間に設定される。この場合、サーバーが２時間経過するまでにクライアントからいずれのセグメントも受信しなかった場合、サーバーは異常発生の有無を判定するためにプロブセグメントを伝送する。各々７５秒の時間間隔で１０個のプロブを伝送したにもかかわらずいずれの応答も受信しなかった場合には、サーバーはクライアントがダウン（例えばシステムダウン）されたと判定し、このＴＣＰコネクションを終了する。したがって、キープアライブタイマーを用いてＴＣＰコネクションの状態を検査する場合、システムはＴＣＰコネクションに異常が発生してから長時間が経過した後でなければ、異常を検知してこのＴＣＰコネクションを終了することができない。
【０００７】
また、ＴＣＰコネクション状態を監視するための他の手法として、ほとんどのシステムではアプリケーション階層(Application Layer)にて周期的に小さなメッセージを送信及び受信する方法を使用する。この方法を使用するシステムは、特定のＴＣＰコネクションにおいて予め決められた一定時間間隔内にメッセージの交換が行なわれないときには、このＴＣＰコネクションに異常が発生したと判定する。この方法は、ＴＣＰコネクションの異常を迅速に検知することができる点においてキープアライブタイマーよりも効率的である。しかしながら、このような各々のアプリケーション階層でＴＣＰコネクションについての監視を実行する方法を、多数のアプリケーションプロセスが動作しているエンベデッドシステムに適用すると、対応する機能についてのコネクションを維持、及びコネクションの断絶を速やかに検出する必要があるすべてのアプリケーションに組み込まなくてはならないので、多量のオーバーヘッド(overhead)が発生してしまう。
【０００８】
特に、すべてのアプリケーションに共通に適用されるイベント(Event)、例えば、サブシステムの電源遮断(Power OFF)、リンクの断絶、Ｈ/Ｗブロック(Hardware Block)の脱離のようなイベントが発生した場合には、各Ｓ/Ｗブロック間のコネクションは実際に何らのデータも交換することができない状態となる。従って、このような状態にあるコネクションを速やかに検知し、コネクションを終了（遮断）して各Ｓ/Ｗブロック別に必要な機能を実行することにより、効率的なエンベデッドシステムを実現することができる。
【０００９】
図１は、Ｓ/Ｗブロック間でのメッセージ交換によりＴＣＰコネクションを監視する手法を採用したエンベデッドシステムを説明するための図である。
【００１０】
図１に示すように、エンベデッドシステムは、複数のＨ/Ｗブロック１００−１〜１００−ｎにより構成されている。各Ｈ/Ｗブロック１００は、ＴＣＰ/ＩＰカーネルにより他のＨ/Ｗブロック１００とのＴＣＰ/ＩＰ通信を実行することができる。各Ｈ/Ｗブロック１００では複数のＳ/Ｗブロック１１１〜１１９が実行されており、これらＳ/Ｗブロック１１１〜１１９は、他のＨ/Ｗブロック１００で実行されるＳ/Ｗブロック１１１〜１１９とＴＣＰ/ＩＰ通信により連結される。しかしながら、この場合、各Ｓ/Ｗブロック１１１〜１１９間のＴＣＰコネクションの状態を監視するためには、すべてのＳ/Ｗブロック１１１〜１１９間でメッセージ交換を行なう必要がある。
【００１１】
例えば、Ｈ/Ｗブロック１のＳ/Ｗブロック（１）１１１−１と、Ｈ/Ｗブロック２のＳ/Ｗブロック（１）１１２−１との間のＴＣＰコネクションを監視するために使用される監視メッセージの伝送経路は、Ｈ/Ｗブロック１のＳ/Ｗブロック（１）１１１−１→Ｈ/Ｗブロック１のＴＣＰ/IＰカーネル１２０−１→Ｈ/Ｗブロック２のＴＣＰ/ＩＰカーネル１２０−２→Ｈ/Ｗブロック２のＳ/Ｗブロック（１）１１２−１である。また、それについての応答メッセージは、反対の経路を介してＨ/Ｗブロック２のＳ/Ｗブロック（１）１１２−１からＨ/Ｗブロック１のＳ/Ｗブロック（１）１１１−１に伝送される。
【００１２】
このような手法によりＴＣＰコネクションの状態を監視するためには、上述した経路を介してメッセージの伝送が随時に行われる必要があるので、過度なオーバーヘッドが発生してしまう。したがって、エンベデッドシステムを効率的に管理するために、迅速であると共にオーバーヘッドが少ないＴＣＰコネクション管理装置及び方法の実現が要求される。
【発明の開示】
【発明が解決しようとする課題】
【００１３】
本発明は上述したような従来技術の問題点を解決するためになされたものであり、その目的は、エンベデッドシステムにおけるＴＣＰコネクションの断絶や異常の有無を迅速に検知することのできるＴＣＰコネクション管理装置、ＴＣＰコネクション管理方法及びプログラム保存装置を提供することにある。
【００１４】
本発明の他の目的は、ＴＣＰコネクションを監視するときに発生するオーバーヘッドが少ないＴＣＰコネクション管理装置、ＴＣＰコネクション管理方法及びプログラム保存装置を提供することにある。
【００１５】
本発明のさらに他の目的は、より一層標準化されたＴＣＰコネクションの状態監視機能を実現することのできるＴＣＰコネクション管理装置、ＴＣＰコネクション管理方法及びプログラム保存装置を提供することにある。
【課題を解決するための手段】
【００１６】
前記目的を達成するための本発明のＴＣＰコネクション管理装置は、任意の二つのアプリケーションの間に設定されたＴＣＰコネクションを管理する装置であって、前記ＴＣＰコネクションの設定情報及び前記ＴＣＰコネクションについてのＴＣＰセッションコネクティビティチェックのための設定値を保存しておき、当該設定情報及び設定値に従ってＳＣＣメッセージを生成して相手側のＴＣＰ/ＩＰカーネルに送信すると共に、この相手側のＴＣＰ/ＩＰカーネルからのＳＣＣ応答メッセージの受信の有無に基づいて前記ＴＣＰコネクションが正常に動作しているか否かを判定するＴＣＰ/ＩＰカーネルを含むことを特徴とする。
【００１７】
また、本発明のＴＣＰコネクション管理方法は、前記ＴＣＰコネクションがＴＣＰセッションコネクティビティチェックを要請するＴＣＰコネクションであるか否かを判定する第１のステップと、ＴＣＰセッションコネクティビティチェックのためのＳＣＣメッセージを生成する第２のステップと、前記生成されたＳＣＣメッセージを前記ＴＣＰコネクションを介して連結される相手側のＴＣＰ/ＩＰカーネルに送信する第３のステップと、前記相手側のＴＣＰ/ＩＰカーネルから前記ＳＣＣメッセージについての応答メッセージが所定の時間内に受信されたか否かを判定し、前記応答メッセージが前記時間内に受信されないときには、前記ＴＣＰコネクションの動作が正常でないと判定する第４のステップと、を含むことを特徴とする。
【００１８】
また、本発明のプログラム保存装置は、任意の二つのアプリケーションの間に設定されたＴＣＰコネクションを管理する方法を実行する装置により実行可能な命令からなるプログラムを保存し、前記装置により読み取り可能なプログラム保存装置であって、前記ＴＣＰコネクションを管理する方法は、前記ＴＣＰコネクションがＴＣＰセッションコネクティビティチェックを要請するＴＣＰコネクションであるか否かを判定する第１のステップと、ＴＣＰセッションコネクティビティチェックのためのＳＣＣメッセージを生成する第２のステップと、前記生成されたＳＣＣメッセージを前記ＴＣＰコネクションを介して連結される相手側のＴＣＰ/ＩＰカーネルに送信する第３のステップと、前記相手側のＴＣＰ/ＩＰカーネルから前記ＳＣＣメッセージについての応答メッセージが所定の時間内に受信されるか否かを判定し、前記応答メッセージが前記時間内に受信されないときには、前記ＴＣＰコネクションが正常に動作しないと判定する第４のステップと、を含むことを特徴とする。
【００１９】
また、本発明の他のプログラム保存装置は、任意の二つのアプリケーションの間に設定されたＴＣＰコネクションを管理する方法を実行する装置により実行可能な命令からなるプログラムを保存し、前記装置により読み取り可能なプログラム保存装置であって、前記ＴＣＰコネクションを管理する方法は、前記ＴＣＰコネクションがＴＣＰセッションコネクティビティチェックを要請するＴＣＰコネクションであるか否かを判定する第１のステップと、前記ＴＣＰコネクションの回線上にトラフィックが存在するか否かを判定する第２のステップと、前記ＴＣＰコネクションの回線上にトラフィックが存在しないと判定したときには、ＴＣＰセッションコネクティビティチェックのためのＳＣＣメッセージを生成して、前記ＴＣＰコネクションを介して連結される相手側のＴＣＰ/ＩＰ カーネルに送信する第３のステップと、前記相手側のＴＣＰ/ＩＰカーネルから前記ＳＣＣメッセージについての応答メッセージが所定の時間内に受信されるか否かを判定し、前記回答メッセージが前記時間内に受信されないときには、前記ＴＣＰコネクションが正常に動作しないと判定する第４のステップと、を含むことを特徴とする。
【発明の効果】
【００２０】
本発明によれば、特にエンベデッドシステムで実行中であるアプリケーション間に設定されているＴＣＰコネクションの状態を監視するためのＴＣＰセッションコネクティビティチェック(TCP Session Connectivity Check)をアプリケーションよりも下位層にあるＴＣＰ/ＩＰカーネルで行なうことにより、非正常的に動作するＴＣＰコネクションを素早く検知することが可能であると共に、監視時のオーバーヘッドを少なくすることが可能である。
【００２１】
また本発明によれば、特にエンベデッドシステムにおいて、システムカーネルレベルでＴＣＰコネクションの状態を監視する機能を実現したことにより、ＴＣＰセッションコネクティビティチェック機能の標準化を図ることが可能になる。さらに、従来においては多数のアプリケーションの全てが備えている必要がある機能をシステムカーネルに持たせてその機能を使用可能にできるオプションを提供することにより、システムの開発期間の短縮化と信頼性を向上させることが可能になる。
【発明を実施するための最良の形態】
【００２２】
以下、添付図面を参照して本発明のＴＣＰコネクション管理装置、ＴＣＰコネクション管理方法及びプログラム保存装置について詳細に説明する。
【００２３】
以下の説明において、添付図面にはその説明の便宜のために参照符号を使用しており、同一な機能を有する多数のブロックを図示する場合は、「−」を使用して各々を区分している。例えば、図１に示した各Ｈ/Ｗブロックは、１００−１、１００−２などの参照符号を使用する。各々のＨ/Ｗブロックを区分して言及する必要がある場合は、参照符号を１００−１、１００−２のように付し、Ｈ/Ｗブロックを通称する場合には、参照符号を代表番号である１００として説明する。
【００２４】
さらに、以下の説明において、本発明はその対象をエンベデッドシステムとして説明しており、また、本発明を特に効果的に適用できるシステムもエンベデッドシステムである。しかし、本発明は、エンベデッドシステムに限られることはなく、ＴＣＰコネクションの監視が必要な他のシステムにも適用することができる。
【００２５】
図１に示したＴＣＰ/ＩＰカーネル１２０は、ファイル、プロセッサ及びネットワークの管理を実行するＴＣＰカーネル階層に該当するものであり、実行中である各Ｓ/Ｗブロック１１１〜１１９を管理する。これは、ＴＣＰ/ＩＰカーネル１２０がＳ/Ｗブロック１１１〜１１９の間に設定されているＴＣＰコネクション情報を有している必要があることを意味する。そして、ＴＣＰ/ＩＰカーネル１２０は、このＴＣＰコネクション情報を参照して、Ｓ/Ｗブロック１１１〜１１９の間に設定されたＴＣＰコネクションについての監視を実行する。このように、各Ｓ/Ｗブロック１１１〜１１９の間のＴＣＰコネクションについての監視をＴＣＰ/ＩＰ カーネル１２０が実行する場合、ＴＣＰ/ＩＰカーネル１２０の間でのみ監視メッセージを交換すればよいので、ＴＣＰコネクションの監視によるオーバーヘッドを格段に減少させることができる。
【００２６】
図２は、ＴＣＰコネクションで使用されるＴＣＰパケットのフォーマットを示す図である。
【００２７】
図２に示したように、ＴＣＰパケットは、ヘッダー部２００と、データ部２４０とで構成されている。ＴＣＰヘッダー部２００は、１６ビットのソースポート(Source Port)番号フィールド２０２と、１６ビットの受信先ポート(Destination Port)番号フィールド２０４と、３２ビットのシーケンス番号(Sequence Number)フィールド２０６と、３２ビットの応答番号(ＡＣＫnowledgement Number)フィールド２０８と、４ビットのデータオフセットフィールド２１０と、６ビットの予備フィールドとしての予約(Reserved)フィールド２１２と、６ビットの制御フラッグフィールド２１４〜２２４と、１６ビットのウィンドウサイズフィールド２２６と、１６ビットのチェックサム(Checksum)フィールド２２８と、１６ビットの緊急ポインタ(Urgent Pointer)フィールド２３０と、２４ビットのオプション(Options)フィールド２３２と、８ビットのパディング(padding)フィールド２３４と、を含んでいる。
【００２８】
ＴＣＰパケットのヘッダー部２００は、パケットがいずれのコネクションに属しているかを識別する情報を含む。ＴＣＰヘッダー部２００のソースポート番号フィールド２０２及び受信先ポート番号フィールド２０４のポート番号は、ＴＣＰが提供する識別子である。これらポート番号は、０から６５５３５までの識別子である。シーケンス番号フィールド２０６は、ＴＣＰパケットの送信順序を示すために使用される。即ち、シーケンス番号フィールド２０６は、データが分割されてＴＣＰパケットで送信される場合、この分割されたデータを元の順序に組み合わせるために使用される。応答番号フィールド２０８は、受信側がＴＣＰパケットを正常に受信したことを送信側に知らせるために使用される。データオフセットフィールド２１０は、ＴＣＰヘッダーの長さを示す。一般的に、特別なオプションを含まないＴＣＰヘッダーの長さは２０バイトである。予約フィールド２１２は、その後の拡張のために準備されたフィールドであり、６バイトの長さを有する。
【００２９】
制御フラッグフィールド２１４〜２２４は、一般的にその値が「１」に設定される際に意味を有し、その各々の意味は次のとおりである。先ず、ＵＲＧ(Urgent Flag、緊急フラッグ)２１４は、緊急処理をしなければならないデータが含まれていることを知らせるために使用される。緊急処理をしなければならないデータの位置は、緊急ポインタ２３０に含まれている。ＡＣＫ(Acknowledgement Flag、応答確認フラッグ)２１６は、応答確認を使用するか否かを示す。ＡＣＫ２１６の値が応答確認を使わないように設定されている場合、ＴＣＰの特徴である信頼性ある通信をやめてＵＤＰ通信に近い形態で動作する。ＰＳＨ(Push Flag、プッシュフラッグ)２１８は、ＴＣＰが受け取ったデータを上層のいずれのアプリケーションに送信するかを示す。ＲＳＴ(Reset Flag、初期化フラッグ)２２０は、通信不良が発生して制御できないときに初期化を命令するために使用される。ＳＹＮ(Synchronize Flag、同期化フラグ)２２２は、仮想回線を確立する際に使用される。ＦＩＮ(Fin Flag、終了フラグ)２２４は、送信側がデータ送信を終了したことを示す際に使用される。
【００３０】
ウィンドウサイズ２２６は、通信可能なデータ量を示す。緊急ポインタ２３０は、ＵＲＧ２１４が設定されているとき、つまり「１」が設定されているときに利用することができる。ウィンドウサイズ２２６に示された数値は、緊急処理をしなければならないデータを示すためのポインタとして取り扱われる。オプション２３２は、通信の詳細事項を調整するために使用され、オプションであるので指定しなくても通信ができる。オプションを指定するかどうかは使用者が選択することができる。チェックサム２２８は、データエラーを検出する方法として、パケットの完全性を検査するために使用される。
【００３１】
図３は、図２に示したＴＣＰヘッダー部のオプションフィールドに使用することのできるＴＣＰオプションの一例を示す図である。
【００３２】
なお、図３において、各ＴＣＰオプションについてのレファレンスを記載することで、これについての詳しい説明は省略する。
【００３３】
図４は、Ｓ/Ｗブロック間のＴＣＰコネクション生成過程を示す図である。
【００３４】
図４に示したＳ/ＷブロックＡ４００及びＳ/ＷブロックＢ４１０は、図１に示したＳ/Ｗブロック１１１〜１１９に相当する。まず、Ｓ/ＷブロックＡ４００は、Ｓ/ＷブロックＢ４１０に対しＳＹＮフラッグ２２２が「１」でありＡＣＫフラッグ２１６が「０」であるＳＹＮパケット４０１を送信する。Ｓ/ＷブロックＡ４００からＴＣＰパケット４０１を受信したＳ/ＷブロックＢ４１０は、これについての応答としてＳＹＮフラッグ２２２及びＡＣＫフラッグ２１６が共に「１」であるＳＹＮ応答(ＡＣＫ)パケット４０３をＳ/ＷブロックＡ４００に送信する。さらに、当該ＳＹＮ応答パケット４０３を受信したＳ/ＷブロックＡ４００は、ＡＣＫフラッグ２１６が「１」でありＳＹＮフラッグ２２２が「０」であるＡＣＫパケット４０５をＳ/ＷブロックＢ４１０に送信する。これにより、Ｓ/ＷブロックＡ４００とＳ/ＷブロックＢ４１０との間にＴＣＰコネクションが生成される。このようなコネクション生成過程を３重ハンドシェイク(3-way handshake)と呼ぶ。
【００３５】
図４に示した過程を経て生成されたＴＣＰコネクションについて異常の有無を検査するためのＴＣＰセッションコネクティビティチェック機能、即ち、ＴＣＰコネクション断絶検査(TCP Connection Loss Check)機能は、ＴＣＰのオプション機能を使用して実行される。本実施形態に従うＴＣＰセッションコネクティビティチェックのためには、図４に示したＴＣＰコネクション生成過程において新たなＴＣＰオプションを追加したＳＹＮメッセージを用いてＴＣＰセッションコネクティビティチェックの実行要請のための交渉(Negotiation)を実行する。このように任意のＴＣＰコネクションについてＴＣＰセッションコネクティビティチェックを実行するかどうかは、ＴＣＰコネクションを生成する際に決定される。即ち、生成されるＴＣＰコネクションについてＴＣＰセッションコネクティビティチェックを実行するかどうかは、そのＴＣＰコネクションについての生成を要請するソフトウェアブロック１１１〜１１９がＴＣＰセッションコネクティビティチェックの実行を要請するかによって決定される。
【００３６】
図５は、ソケット及びプロトコルスタックの階層構造を示す図である。
【００３７】
図５に示した階層構造について説明すれば、最下位階には、ネットワークインターフェースである並列ポート５００、直列ポート５０２及び、イーサネット（登録商標）カード５０４が位置する。ネットワークインターフェースは、ネットワークの種類に対応したハードウェアである。
【００３８】
ネットワークインターフェースの上位階には、デバイスドライバーであるＰＬＩＰ(Parallel Line Internet Protocol)５１０、ＳＬＩＰ(Serial Line Internet Protocol)５１２、イーサネット（登録商標）５１４及びＡＲＰ(Address Resolution Protocol)５１６が位置する。デバイスドライバーは、ハードウェアと通信するソフトウェアである。
【００３９】
デバイスドライバーの上位階にあるネットワーク階層には、ＩＰ(Internet Protocol)５２０が位置する。さらにネットワーク階層の上位階にあるトランスポート階層には、ＴＣＰ５３０及びＵＤＰ(User Datagram Protocol)５３２が位置する。
【００４０】
トランスポート階層の上位階には、ＩＮＥＴソケット５４０が位置する。さらにＩＮＥＴソケット５４０の上位階には、ＢＳＤ(Berkeley Software Distribution)ソケット５５０が位置する。ＩＮＥＴソケット５４０及びＢＳＤソケット５５０は、通称してソケットと呼ばれている。ソケットとは、ＴＣＰ/ＩＰに基づいたＩＰＣ(Interprocess Communication, プロセス間通信)インターフェースである。このソケットを使えば、例えばファイルの読み出し／書き込みと同じようにしてネットワーク経由でデータを送受信できるようになる。ＩＮＥＴソケット５４０は、ＴＣＰとＵＤＰのためのソケットであり、またＢＳＤソケット５５０は、一般的なソケットインターフェースを管理する。
【００４１】
そして、階層構造の最上位階がアプリケーション５６０になる。
【００４２】
図５において、ネットワークは、アプリケーション５６０を除いた全ての要素のインターフェースをする。即ち、ＢＳＤソケット５５０から並列ポート５００、直列ポート５０２、イーサネット（登録商標）カード５０４までがオペレーティングシステムに相当する。このオペレーティングシステムの中で、トランスポート階層のＴＣＰ５３０及びネットワーク階層のＩＰ５２０が特にカーネルに相当する。もちろん、この区分はシステムの通信と関連付けての区分である。
【００４３】
Ｓ/Ｗブロック１１１〜１１９は、図５に示したアプリケーション５６０に相当する。即ち、階層構造において最上位階に位置しているＳ/Ｗブロック１１１〜１１９は、メッセージ伝送などの通信を実行するために使用される。
【００４４】
図６は、例えばリナックスカーネル(Linux kernal)を用いたシステムでの制御フローを示す図である。
【００４５】
任意のアプリケーション、即ち、任意のＳ/Ｗブロック１１１〜１１９が他のＳ／Ｗブロック１１１〜１１９に対し一つのメッセージを送信しようとする場合、システム上では、図６に示すようにして制御が行われる。先ず、メッセージを送信しようとするＳ／Ｗブロック１１１〜１１９は、インターフェースの一つであるＶＦＳ(Virtual File System)６００から「sys_write()」という関数を呼び出して、送信しようとするメッセージの内容を記録する。これを通じて、Ｓ/Ｗブロックが送信しようとするメッセージは、ＢＳＤソケット５５０に伝送される。
【００４６】
ＶＦＳ６００から前記メッセージを受信したＢＳＤソケット５５０は、「sock_write()」という関数を呼び出して、このメッセージをＩＮＥＴソケット５４０に伝送する。ＩＮＥＴソケット５４０は、「INET_sendmsg()」という関数を呼び出して、ＢＳＤソケット５５０から受信したメッセージをＴＣＰ５３０に伝送する。ＴＣＰ５３０は、「tcp_send_skb()」という関数を呼び出して、ＩＮＥＴ５４０ソケットから受信したメッセージをＩＰ５２０に伝送する。ＩＰ５２０は、「ip_queue_xmit()」という関数を呼び出して、ＴＣＰ５３０から受信したメッセージをデバイス６１０に伝送する。デバイス６１０は、「el−3_start_xmit()」という関数を呼び出して、ＴＣＰ５３０から受信したメッセージを送信する。
【００４７】
ここで、本実施形態では、ＴＣＰコネクティビティチェックをカーネルであるＴＣＰ/ＩＰが実行するので、ＴＣＰコネクティビティチェックを行なう場合には、図６のＴＣＰ５３０以下の関数の呼び出しだけが実行される。したがって、その他の関数、つまり図６のＩＮＥＴソケット５４０以上の関数の呼び出し及び、それに伴うメッセージの伝送を省略することができるので、その分においてオーバーヘッドを少なくすることができる。
【００４８】
図７は、ＢＳＤシステムで支援されるソケットオプションを示す図であり、図８は、本実施形態を実施するために追加される新たなＴＣＰオプションとしてのSO_SCC(Socket Option_Session Connectivity Check)を示す図である。 
【００４９】
即ち、図８に示した新たなＴＣＰオプションとしてのSO_SCC(Socket Option_Session Connectivity Check)を追加することにより、本実施形態に従うＴＣＰセッションコネクティビティチェックを実現することができる。この場合、最初にＴＣＰコネクションを生成する際に、SO_SCCを用いて対応するＴＣＰについてのＴＣＰコネクティビティチェックが実行されるように設定する。
【００５０】
本実施形態に従うＴＣＰセッションコネクティビティチェック機能を備えたことにより、ＴＣＰ/ＩＰカーネル１２０がＳ/Ｗブロック１１１〜１１９の間に設定されたＴＣＰコネクションについての監視を実行する。それについては図面を参照して以下に詳しく説明する。
【００５１】
図９は、本実施形態に従うＴＣＰセッションコネクティビティチェックをＴＣＰ/ＩＰカーネル１２０で実行するエンベデッドシステムの構成図である。
【００５２】
本実施形態のように、ＴＣＰセッションコネクティビティチェックがＴＣＰ/ＩＰカーネル１２０で行われる場合には、図９に示すように、ＴＣＰセッションコネクティビティチェックのためのメッセージ交換は、ＴＣＰ/ＩＰカーネル１２０間だけで行われる。例えば、Ｈ/Ｗブロック１のＳ/Ｗブロック（１）１１１−１と、Ｈ/Ｗブロック２のＳ/Ｗブロック（１）１１２−１との間に設定されたＴＣＰコネクションについてのコネクティビティチェックのために行なわれるメッセージ交換は、Ｈ/Ｗブロック１のＴＣＰ/ＩＰカーネル１２０−１と、Ｈ/Ｗブロック２のＴＣＰ/ＩＰカーネル１２０−２との間だけで行われる。即ち、各Ｓ/Ｗブロック１１１〜１１９とＴＣＰ/ＩＰカーネル１２０との間のメッセージ交換が省略されるので、その分においてオーバーヘッドを少なくすることが可能である。一方、ＴＣＰ/ＩＰカーネル１２０間のメッセージ交換により、ＴＣＰ/ＩＰカーネル１２０のＴＣＰセッションコネクティビティチェックを実行するためには、ＴＣＰコネクションを生成する際においてその設定を既述のメッセージの交換により行なっておく必要がある。なお、ＴＣＰコネクションの生成については、図４に記載した生成過程を経ることで行なわれる。
【００５３】
続いて、本実施形態に従うＴＣＰ/ＩＰカーネル１２０の構造について、図面を参照して説明する。
【００５４】
図１０は、図９に示したＴＣＰ/ＩＰカーネルが備えたＴＣＰセッションコネクティビティチェックを実行するための構成を示すブロック図である。
【００５５】
図１０に示すように、本実施形態に従うＴＣＰ/ＩＰカーネル１２０は、入出力部１０００、制御部１０１０、プログラム保存装置に相当する保存部１０２０及びタイマー１０３０を含む構成である。タイマー１０３０は、特にＳＣＣタイマーを使用することができる。
【００５６】
ＴＣＰ/ＩＰカーネル１２０の入出力部１０００は、上位階層と下位階層との間でインターフェースを提供する。これにより、ＴＣＰ/ＩＰカーネル１２０は、自分が含まれるハードウェアブロック１００−１〜１００−ｎと、他のハードウェアブロック１００−１〜１００−ｎとの間でＴＣＰ/ＩＰ通信を実現する。ここで、ハードウェアブロック１のＴＣＰ/ＩＰカーネル１２０−１の場合を一例に挙げて説明する。
【００５７】
ハードウェアブロック１のＴＣＰ/ＩＰカーネル１２０−１は、入出力部１０００を介してソフトウェアブロック１１１−１〜１１１−ｋ及び相手側のハードウェアブロックのＴＣＰ/ＩＰカーネル１２０−１〜１２０−ｎにメッセージを伝送することができる。勿論、詳細に説明すれば、ＴＣＰ/ＩＰカーネル１２０−１は、ソフトウェアブロック１１１−１〜１１１−ｋ又は相手側のＴＣＰ/ＩＰカーネル１２０−１〜１２０−ｎと直接連結されるのではなく、図５及び図６に示したような中間過程を介して連結されている。しかし、以下の説明では中間過程についての説明は省略する。
【００５８】
保存部１０２０は、自分（当該ＴＣＰ/ＩＰカーネル１２０−１）の上位で動作中であるソフトウェアブロック１１１−１〜１１１−ｋについての情報及び、この動作中であるソフトウェアブロック１１１−１〜１１１−ｋについての本実施形態に従うＴＣＰセッションコネクティビティチェックのための設定値を保存する。保存部１０２０に保存されるＴＣＰセッションコネクティビティチェックのための設定値については後述する。
【００５９】
制御部１０１０は、前記設定値に従ってＴＣＰセッションコネクティビティチェックのためのＳＣＣメッセージの送信条件を決定し、ＴＣＰコネクションの異常動作の有無を判定する。タイマー１０３０は、ＳＣＣメッセージを送信する周期及び、ＳＣＣ応答メッセージが受信されていない時間の経過をカウントする。
【００６０】
続いて、ＴＣＰ/ＩＰカーネル１２０におけるＴＣＰセッションコネクティビティチェックを実施するための設定について、図面を参照して説明する。
【００６１】
図１１は、本実施形態に使用されるＴＣＰセッションコネクティビティチェックのオプション項目を示す図である。
【００６２】
図１１に示すように、本実施形態に従うＴＣＰセッションコネクティビティチェックオプションは、ｋｉｎｄフィールド１１００と、Ｌｅｎフィールド１１０２と、確認(confirm)フィールド１１０４と、ｓｔｒｉｃｔチェックフィールド１１０６と、チェック間隔フィールド１１０８と、終了カウントフィールド１１１０と、を含んでいる。
【００６３】
本実施形態においては、ｋｉｎｄ＝２７に設定されたｋｉｎｄフィールド１１００は、本実施形態に従うＴＣＰコネクション監視機能を働かせるように設定したことを示している。ｌｅｎｇｔｈ＝７に設定されたＬｅｎフィールド１１０２は、その長さを示す。確認フィールド１１０４は、オプションが適切に設定されたことを示す値である。ｓｔｒｉｃｔチェックフィールド１１０６は、ＳＣＣメッセージを常に送信するか否かを決定する。チェック間隔フィールド１１０８は、ＳＣＣメッセージを送信する周期を決定する。終了カウントフィールド１１１０は、ＳＣＣメッセージ又はＳＣＣ応答メッセージを受信しなかった場合に、対応するＴＣＰセッションを終了（遮断）する前に再伝送するＳＣＣメッセージの個数又はＳＣＣ応答メッセージを待つ時間を示す。
【００６４】
ここで、図１１に示した追加ソケットオプションについてのプログラムコードの一例を挙げておくと、次のようである。
【００６５】
struct tcp_scc { 
intl_onoff;/* zero=off, nonzero=on */ 
intl_strict;/* zero=non strict, nonzero=strict */ 
intl_interval;/* seconds */ 
intl_count; 
}; 
【００６６】
このようなプログラムコードを使用する実施形態では、ＴＣＰセッションコネクティビティチェックのために、少なくともＯＮ/ＯＦＦ、ｓｔｒｉｃｔ、ｉｎｔｅｒｖａｌ、ｃｏｕｎｔの設定値を使用する。ここで、ＯＮ/ＯＦＦは、本実施形態に従うＴＣＰセッションコネクティビティチェック機能の使用の有無を示す値であり、図１１の確認フィールド１１０４の値に相当する。ｓｔｒｉｃｔは、周期的なメッセージの送信の有無を示す値であり、ｓｔｒｉｃｔ チェックフィールド１１０６の値に相当する。ｉｎｔｅｒｖａｌは、メッセージを送信する時間間隔を示す値であり、チェック間隔フィールド１１０８の値に相当する。ｃｏｕｎｔは、終了カウントフィールド１１１０の値に相当する。
【００６７】
これらの値の使用例について説明すれば、次のようである。ＯＮ/ＯＦＦ値は「０」又は「１」の二つの値の中で選択できる。例えばＯＮ/ＯＦＦ値が「０」である場合は、本実施形態によるＴＣＰセッションコネクティビティチェック機能を使用しないと判定し、ＯＮ/ＯＦＦ値が「１」である場合は、ＴＣＰセッションコネクティビティチェック機能を使用すると判定する。Ｓｔｒｉｃｔ値は「０」又は「１」の二つの値の中で選択できる。ｓｔｒｉｃｔ値が「０」である場合は、ＴＣＰ/ＩＰカーネル１２０は周期的にＳＣＣメッセージを送信してＴＣＰセッションコネクティビティチェックを実行する。ｓｔｒｉｃｔ値が「１」である場合は、ＴＣＰ/ＩＰカーネル１２０は監視対象であるＴＣＰコネクション回線上にいずれの信号も存在しない場合にＳＣＣメッセージを送信してＴＣＰセッションコネクティビティチェックを実行する。ＳＣＣメッセージを送信する時間間隔を設定するｉｎｔｅｒｖａｌ値は、一般的に秒単位で設定できる。Ｃｏｕｎｔ値は、待機回数を示す値又は待機時間を示す値で設定できる。なお、この場合においてｓｔｒｉｃｔ値が「１」に設定されている場合を、ｓｔｒｉｃｔ値が設定されていると呼び、ｓｔｒｉｃｔ値が「０」に設定されている場合を、ｓｔｒｉｃｔ値が設定されていないと呼ぶ。
【００６８】
このような設定値は、Ｓ/Ｗブロック１１１〜１１９毎に適切に設定することができ、ＴＣＰ/ＩＰカーネル１２０は、設定されたこれら設定値に基づいてＴＣＰセッションコネクティビティチェック機能を実行する。なお、図１１は、ｋｉｎｄフィールド１１００を「２７」に設定し、Ｌｅｎフィールド１１０２を「７」に設定した例を一実施形態として示している。しかしながら、図１１に示したフィールド値の設定値及び各フィールドのサイズについての設定値は、本発明の理解を助けるために例示したものであり、本発明はこのような具体的な数値により限定されない。
【００６９】
図１２は、本実施形態によるセッションコネクティビティチェック機能を有するＴＣＰパケットフォーマットを示す図である。
【００７０】
図１２に示すように、本実施形態では、図２に示したＴＣＰパケットのヘッダー部２００における６ビットの予約フィールド２１２の中の１ビットをＴＣＰセッションコネクティビティチェック(Session Connectivity Check, ＳＣＣ; 以下、「コネクティビティチェック」と称する)フラッグ１２００として使用することにより、コネクティビティチェック機能を有するＴＣＰパケットを生成することができる。即ち、本実施形態に従うＴＣＰパケットのヘッダー部２００の制御フラッグは７ビットになる。そして、既述の制御フラッグ２１４〜２２４に追加されるＳＣＣフィールド１２００は、本実施形態に従うコネクティビティチェックのために使用される。
【００７１】
最初にＴＣＰコネクションを生成する際、ＴＣＰセッションコネクティビティチェックオプションを使用して二つのＳ/Ｗブロック１１１〜１１９の間に設定されたＴＣＰコネクションを監視するための交渉をメッセージ交換により実行した後に、ＴＣＰコネクションのクライアント側ではＴＣＰコネクションのサーバー側に、図１２に示したようなＳＣＣフラッグ１２００を含むＴＣＰヘッダー２００を有するＴＣＰパケットであるＳＣＣメッセージを送信する。このとき、ＴＣＰコネクションの設定を要請した側のＳ/Ｗブロック１１１〜１１９の下位に存在するＴＣＰ/ＩＰカーネル１２０がクライアントとなり、このクライアントからＴＣＰコネクション設定の要請を受けた側のＳ/Ｗブロック１１１〜１１９の下位に存在するＴＣＰ/ＩＰカーネル１２０がサーバーとなる。
【００７２】
続いて、本実施形態によるＴＣＰセッションコネクティビティチェックの過程について説明する。図１３及び図１４は、ｓｔｒｉｃｔが「１」に設定された場合の過程について記載してある。したがって、ＴＣＰ/ＩＰカーネル１２０は、ＳＣＣメッセージを常に送信しないで、対応するＴＣＰコネクションが何のトラフィックも受け取らないときにだけＴＣＰセッションコネクティビティチェック過程を開始する。
【００７３】
図１３は、本実施形態に従うクライアント側におけるＴＣＰセッションコネクティビティチェック過程を示すフローチャートである。
【００７４】
ただし、図１３に示したフローチャートは、サーバー１３１０に異常が発生したときに実行される過程である。この場合のＴＣＰセッションコネクティビティチェック過程を大きく区分すると、以下の３過程に分けられる。
【００７５】
第１の過程；クライアント１３００は、ＴＣＰコネクションを生成する際に、ＴＣＰセッションコネクティビティオプションに設定された周期に従って、ＳＹＮＣからサーバー１３１０にＳＣＣメッセージを送信する。第２の過程；クライアント１３００は、ＳＣＣメッセージを送信した後、その応答としてのＳＣＣ応答メッセージを受信すると、設定された時間経過後に次のＳＣＣメッセージを送信するためにＳＣＣタイマー１０３０を動作させる。第３の過程；クライアント１３００は、ＳＣＣメッセージを送信した後、その応答としてのＳＣＣ応答メッセージを受信しないときには、設定されたカウントに従ってＳＣＣメッセージを再伝送し、設定されたカウント内にその応答としてのＳＣＣ応答メッセージを受信しない場合には、そのＴＣＰコネクションを閉じる。
【００７６】
この過程について詳細に説明すれば、次のようである。
【００７７】
まず、クライアント１３００は、サーバー１３１０と連結された回線上にトラフィックがないかを判定する(ステップ１３２０)。即ち、クライアント１３００は、回線を介して送信されるか又は受信される信号の有無を判定する。回線上にトラフィックがないと判定した場合、クライアント１３００はＳＣＣタイマー１０３０を用いてカウントを開始する。
【００７８】
次に、クライアント１３００は、ＳＣＣタイマー１０３０のタイマー値が満了したか否か、即ち、サーバー１３１０との間にトラフィックがない時間が予め設定された所定の時間を経過したか否かを判定する(ステップ１３２２)。設定された時間が経過するまでクライアント１３００とサーバー１３１０との間の回線にトラフィックがなかった場合、クライアント１３００はサーバー１３１０とのＴＣＰコネクションが正常に動作しているかどうかを検査する必要があると判定する。そしてクライアント１３００は、サーバー１３１０とのＴＣＰコネクションを検査するためにサーバー１３１０にＳＣＣメッセージ１３２３を送信する。
【００７９】
クライアント１３００からのＳＣＣメッセージ１３２３を受信したサーバー１３１０は、ＳＣＣタイマー１０３０のタイマー値をリセットする(ステップ１３２４)。その理由は、サーバー１３１０は、ＳＣＣメッセージ１３２３を受信することにより、クライアント１３００との回線上にトラフィックが発生したと判定するためである。サーバー１３１０は、ＳＣＣメッセージ１３２３に対する応答信号としてＳＣＣ応答メッセージ１３２５をクライアント１３００に送信することにより、ＴＣＰコネクションが正常に行われていることをクライアント１３００に通知する。
【００８０】
サーバー１３１０からＳＣＣ応答メッセージ１３２５を受信したクライアント１３００は、ＳＣＣタイマー１０３０のタイマー値をリセットしてからさらにカウントを開始する。クライアント１３００は、ＳＣＣタイマー１０３０のタイマー値が満了されるたびにサーバー１３１０にＳＣＣメッセージを送信し、それについてのＳＣＣ応答メッセージを受信することによりＴＣＰコネクションが正常に動作していることを確認する。
【００８１】
一方、ＴＣＰコネクションに異常が発生して二つのＳ/Ｗブロック１１１〜１１９の間にメッセージが正常に伝送されない場合には、クライアント１３００がＳＣＣメッセージを送信してもサーバー１３１０はこれについて応答することができない。そのときの過程が、図１３のステップ１３２６〜ステップ１３４６に示されている。
【００８２】
クライアント１３００はＳＣＣタイマー１０３０のタイマー値が満了されたか否かを判定する(ステップ１３２６)。ＳＣＣタイマー１０３０のタイマー値が満了された場合、クライアント１３００は、サーバー１３１０にＳＣＣメッセージ１３２７を送信する。ところが、サーバー１３１０とのＴＣＰコネクションが非正常的に終了された場合には、このＳＣＣメッセージ１３２７をサーバー１３１０に伝送できないし、サーバー１３１０はそれについて応答することもない。したがって、クライアント１３００はサーバー１３１０からＳＣＣメッセージ１３２７についての応答メッセージを受信することができなくなる。
【００８３】
クライアント１３００は、ＳＣＣメッセージ１３２７を送信した時点からカウントを始めたＳＣＣタイマー１０３０のタイマー値が満了されたか否かを判定する(ステップ１３４０)。ＳＣＣタイマー１０３０のタイマー値が満了された場合、即ち、クライアント１３００がサーバー１３１０に対しＳＣＣメッセージ１３２７を送信し、このＳＣＣメッセージに対する応答メッセージを受信しなかった時間が、予め設定された所定の時間を経過したと判定された場合、クライアント１３００は、サーバー１３１０とのＴＣＰコネクションが非正常に終了されたと判定するか否かを決定するためにカウントを開始する(ステップ１３４２)。カウント値が所定の設定値（臨界値）を超えたと判定した場合には(ステップ１３４４)、クライアント１３００は、サーバー１３１０とのＴＣＰコネクションが非正常に終了したと判定し、そのＴＣＰコネクションを終了する(ステップ１３４６)。
【００８４】
一方、図１３に示した場合と異なり、サーバー１３１０側ではなくクライアント１３００側に異常が発生してＴＣＰコネクションが非正常的になる場合が発生することがある。この場合には、ＴＣＰコネクションが正常に動作しているか否かはサーバー１３１０が判定しなければならない。ＴＣＰコネクションが正常に動作しているか否かをサーバー１３１０が判定する過程について、図面を参照して説明する。
【００８５】
図１４は、本実施形態に従うサーバー側におけるＴＣＰセッションコネクティビティチェック過程を示すフローチャートである。
【００８６】
ただし、図１４に示したフローチャートは、クライアント１３００に異常が発生したときに実行される過程である。この場合のＴＣＰセッションコネクティビティチェック過程を大きく区分すると、以下の３過程に分けられる。
【００８７】
第１の過程；サーバー１３１０は、最初のＴＣＰコネクションを生成する際に使用される、ＳＹＮＣに含まれるＴＣＰセッションコネクティビティオプションに設定された周期に従ってクライアント１３００側からＳＣＣメッセージが受信されるのを待つ。第２の過程；ＳＣＣタイマー１０３０が満了(expire)になる前にクライアント１３００からＳＣＣメッセージが受信されたときには、サーバー１３１０は、ＳＣＣ応答メッセージをクライアント１３００に送信した後、次のＳＣＣメッセージが設定された時間内に受信されるか否かを判定するためのＳＣＣタイマー１０３０を動作させる。第３の過程；ＳＣＣタイマー１０３０が満了された場合、サーバー１３１０は、設定されたカウント値内にＳＣＣメッセージが受信されるか否かを判定するためのＳＣＣタイマー１０３０を動作させ、設定されたカウント値内にＳＣＣメッセージが受信されない場合には、そのＴＣＰコネクションを閉じる。
【００８８】
この過程について詳細に説明すれば、次のようである。
【００８９】
まず、クライアント１３００は、サーバー１３１０と連結された回線上にトラフィックがないかを判定する(ステップ１４００)。回線上にトラフィックがない場合には、クライアント１３００はＳＣＣタイマー１０３０を用いてカウントを開始する。
【００９０】
次に、クライアント１３００は、ＳＣＣタイマー１０３０のタイマー値が満了したか否か、即ち、サーバー１３１０との間にトラフィックがない時間が予め設定された所定の時間を経過したか否かを判定する(ステップ１４０２)。設定された時間が経過するまでクライアント１３００とサーバー１３１０との間の回線にトラフィックがなかった場合、クライアント１３００は、サーバー１３１０とのＴＣＰコネクションが正常に動作しているか否かを検査する必要があると判定する。そして、クライアント１３００は、サーバー１３１０とのＴＣＰコネクションを検査するためにサーバー１３１０にＳＣＣメッセージ１４０３を送信する。
【００９１】
クライアント１３００からのＳＣＣメッセージ１４０３を受信したサーバー１３１０は、ＳＣＣタイマー１０３０のタイマー値をリセットする(ステップ１４０４)。その理由は、サーバー１３１０は、ＳＣＣメッセージ１４０３を受信することによりクライアント１３００との回線上にトラフィックが発生したと判定するためである。サーバー１３１０は、ＳＣＣメッセージ１４０３に対する応答信号としてＳＣＣ応答メッセージ１４０５をクライアント１３００に送信することにより、ＴＣＰコネクションが正常に行われていることを通知する。
【００９２】
ところが、ＳＣＣメッセージ１４０３を送信した後にクライアント１３００側に異常が発生した場合、クライアント１３００がダウン（システムダウン）されるか又はＴＣＰコネクションが非正常的に終了される(ステップ１４１０)。 エンベデッドシステムが効率的に動作するためには、このようなクライアント１３００の異常の有無をサーバー１３１０が判定しなければならない。
【００９３】
クライアント１３００に異常が発生した場合、サーバー１３１０はクライアント１３００からＳＣＣメッセージを受信することができない。したがって、ステップＳ１４０４においてリセットしたＳＣＣタイマー１０３０のタイマー値が満了するまでＴＣＰ回線上にはいずれの信号も存在しなくなる。そしてＳＣＣタイマー１０３０のタイマー値が満了すると(ステップ１４２０)、サーバー１３１０は、クライアント１３００とのＴＣＰコネクションが非正常に終了したと判定するか否かを決定するためのカウントを開始する(ステップ１４２２)。カウント値が所定の設定値（臨界値）を超えたと判定した場合には(ステップ１４２４)、サーバー１３１０は、クライアント１３００とのＴＣＰコネクションが非正常に終了したと判定してそのＴＣＰコネクションを終了する(ステップ１４２６)。
【００９４】
一方、図１３及び図１４は、ｓｔｒｉｃｔチェックフィールド１１０６の値が「１」に設定された場合、即ち、ＴＣＰ/ＩＰカーネル１２０が任意のＴＣＰコネクションの回線上にいずれの信号もない場合にＳＣＣメッセージを送信して対応するＴＣＰコネクションの状態を監視するＴＣＰセッションコネクティビティチェック過程についてのフローチャートである。これに対し、ｓｔｒｉｃｔチェックフィールド１１０６の値が「０」に設定された場合、即ち、ＴＣＰ/ＩＰカーネル１２０が設定された時間間隔に従って周期的にＳＣＣメッセージを送信して、ＴＣＰコネクションの状態を監視する場合には、クライアント１３００は、図１３のステップＳ１３２０及び図１４のステップＳ１４００における、回線上にトラフィックが存在するか否かを判定する過程を省略し、周期的にＳＣＣメッセージを送信してＴＣＰセッションコネクティビティチェックを実行する。
【００９５】
上述したｓｔｒｉｃｔ値の設定によってＳＣＣメッセージの送信条件が異なる二つの実施形態について効果を述べておくと、次のような差異がある。ＴＣＰコネクション上にトラフィックが存在しない場合にだけＳＣＣメッセージを送信する第１の実施形態は、トラフィックの存在有無に関わらずＳＣＣメッセージを送信する第２の実施形態に比して少ないオーバーヘッドでＴＣＰセッションコネクティビティチェックを実行することができる。その反面、任意のＴＣＰコネクションに異常が発生したが、その回線上に異常動作によるトラフィックが存在する場合は、第１の実施形態では対応するＴＣＰコネクションの異常発生の有無を判定することができない。したがって、適用しようとするシステムの特性に応じて適切な実施形態のＴＣＰセッションコネクティビティチェックを適用し、それによって適切な設定値を選択することが望ましい。
【００９６】
一方、上述のように、Ｓ/Ｗブロック１１１〜１１９の間に設定されたＴＣＰコネクションの状態を検査することにおいては、そのＴＣＰコネクションの設定を要請した側であるクライアント１３００がＴＣＰコネクション接続状態検査の主体になることが望ましいが、クライアント１３００側に異常が発生する場合に備えてサーバー１３１０がＴＣＰコネクション接続状態検査の主体になることもできる。即ち、サーバー１３１０がＳＣＣメッセージの送信条件を判定し、条件が満たされた際にクライアント１３００にＳＣＣメッセージを送信してＴＣＰコネクション接続状態の検査を実行することもできる。
【図面の簡単な説明】
【００９７】
【図１】エンベデッドシステムのソフトウェアブロック間でのメッセージ交換によるＴＣＰセッションコネクティビティチェックを示す図である。
【図２】ＴＣＰコネクションで使用されるＴＣＰパケットのフォーマットを示す図である。
【図３】ＴＣＰヘッダー部のオプションフィールドに設定されるＴＣＰオプションを示す図である。
【図４】ソフトウェアブロック間のＴＣＰコネクション生成過程を示す図である。
【図５】プロトコル階層構造を示す図である。
【図６】リナックスカーネルにおける制御を示すフローチャートである。
【図７】ＢＳＤシステムのソケットオプションを示す図である。
【図８】本実施形態に従うＴＣＰオプションであるSO_SCCを示す図である。
【図９】本実施形態に従うＴＣＰ/ＩＰカーネルで実行されるＴＣＰセッションコネクティビティチェックを示す図である。
【図１０】本実施形態に従うＴＣＰ/ＩＰカーネルの構成要素を示すブロック図である。
【図１１】本実施形態に従うＴＣＰセッションコネクティビティチェックオプションの項目を示す図である。
【図１２】本実施形態に従うＴＣＰセッションコネクティビティチェック機能のために使用されるＴＣＰパケットフォーマットを示す図である。
【図１３】本実施形態に従うクライアント側におけるＴＣＰセッションコネクティビティチェック過程を示すフローチャートである。
【図１４】本実施形態に従うサーバー側におけるＴＣＰセッションコネクティビティチェック過程を示すフローチャートである。
【符号の説明】
【００９８】
１２０  ＴＣＰ/ＩＰカーネル
１０００  入出力部 
１０１０  制御部
１０２０  保存部
１０３０  タイマー
１３００  クライアント
１３１０  サーバー
【図１】
2005228316.tif 000003
【図２】
2005228316.tif 000004
【図３】
2005228316.tif 000005
【図４】
2005228316.tif 000006
【図５】
2005228316.tif 000007
【図６】
2005228316.tif 000008
【図７】
2005228316.tif 000009
【図８】
2005228316.tif 000010
【図９】
2005228316.tif 000011
【図１０】
2005228316.tif 000012
【図１１】
2005228316.tif 000013
【図１２】
2005228316.tif 000014
【図１３】
2005228316.tif 000015
【図１４】
2005228316.tif 000016