クライアント装置、通信システム、生存確認方法、及びプログラム
【課題】処理負担軽減と異常状態検出時間の短縮という相反する条件を満たす生存確認の技術を提供する。
【解決手段】サーバ装置との間に構築されたトンネルを介してデータ通信を行うクライアント装置は、データパケット送信がない場合に、第１の時間間隔で生存確認要求を前記サーバ装置に送信し、生存確認要求応答を受信した場合に、生存確認要求応答受領を前記サーバ装置に送信し、データパケット送信がある場合において、生存確認要求応答を前記サーバ装置から受信した後の第２の時間経過内に、生存確認要求応答受領付きデータパケットを前記サーバ装置に送信し、当該第２の時間経過後に、生存確認要求付きデータパケットを前記サーバ装置に送信し、生存確認要求応答を前記サーバ装置から受信しないで第３の時間が経過した場合に、前記トンネルの状態が悪化したと判定する。
【解決手段】サーバ装置との間に構築されたトンネルを介してデータ通信を行うクライアント装置は、データパケット送信がない場合に、第１の時間間隔で生存確認要求を前記サーバ装置に送信し、生存確認要求応答を受信した場合に、生存確認要求応答受領を前記サーバ装置に送信し、データパケット送信がある場合において、生存確認要求応答を前記サーバ装置から受信した後の第２の時間経過内に、生存確認要求応答受領付きデータパケットを前記サーバ装置に送信し、当該第２の時間経過後に、生存確認要求付きデータパケットを前記サーバ装置に送信し、生存確認要求応答を前記サーバ装置から受信しないで第３の時間が経過した場合に、前記トンネルの状態が悪化したと判定する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信ネットワークにおける生存確認技術に関連するものである。
【背景技術】
【０００２】
企業内ネットワークや家庭内ネットワーク等のプライベートネットワークと、インターネット等の外部ネットワークとの間には、通信のセキュリティを確保するためのファイアウォール装置（NAT装置等も含む）が設置されるのが一般的である。
【０００３】
このようなファイアウォール装置では、ネットワーク管理のポリシーに応じて、通信を許可するプロトコルが設定されるが、例えば、多くの場合、プライベートネットワーク内のクライアント装置からの要求に係るHTTP／HTTPS通信は許容されている。
【０００４】
そこで、プライベートネットワーク内のクライアント装置と、外部の装置との間で、IP電話や映像会議等の通信を行うために、HTTPのように通信が許容されているプロトコルのヘッダで、目的とする通信のパケットをカプセリングすることにより、仮想的な通信路であるトンネルを形成し、当該トンネルを通して、IP電話や映像会議等の目的とする通信を行うトンネリング技術が用いられている。
【０００５】
図１は、上記のようなトンネリング技術を利用したファイアウォール越え通信の例を示す図である。図１に示すように、トンネリング技術では、トンネルクライアント機能を備えたクライアント装置（図１の例ではPC)と、外部ネットワーク（インターネット）に設置されたトンネルサーバ装置との間でトンネルを形成し、通信を行う。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開2010-109733号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
トンネリングを用いた通信を行う場合に、途中経路で通過するファイアウォール装置やプロクシサーバ装置の機能により、長時間無通信の場合に、強制的に切断させられてしまう場合や、切断状態にならないまでも信号が疎通しなくなっている、いわゆるトンネルが詰まった状態が生じる場合がある。このような状態を回避するために、クライアント装置がトンネルサーバ装置に生存確認要求を定期的に送信し、クライアント装置がサーバ装置から生存確認要求応答を受信することにより、クライアント装置がトンネル状態の判断や再接続等を行う疎通確認技術が従来からある。
【０００８】
上記の技術では、生存確認要求の送信間隔が短いと、本来のデータパケット以外の無駄なパケットが増加し、無通信クライアントを含む多数のクライアントのトラフィックが集中するトンネルサーバ装置やそのネットワークにおいて、処理負荷が増加し、性能低下を招く恐れがある。逆に、送信間隔を長くしてしまうと、詰まり状態を長時間検出できず、通信が長時間途切れたりする問題が生じる。つまり、従来の疎通確認のための技術では、処理負担軽減と異常状態検出時間の短縮という相反する条件を同時に満たすことは困難であった。
【０００９】
一方、TCP/IP等の技術により実現される信頼性が担保された通信路では、通信路上のパケットドロップ等の外乱によりパケットの再送等が発生し、結果として遅延が生じることで通信が安定しない場合がある。これを解消するため、複数本のトンネル接続を束ねて１本の論理的なトンネル接続を構成し、その中にパケットを分散して送信することで通信の安定化を図る従来技術がある。
【００１０】
上記の技術では、より安定した通信を実現するために、複数本のトンネル接続の各々について、例えば上述した疎通確認技術を適用することにより、無通信切断防止及び疎通確認を行うとともに、複数本のトンネル接続経由でパケットを流す際に、通信状態の悪いトンネル接続を避けてパケットを流すことが望ましい。
【００１１】
本発明は上記の問題点に鑑みてなされたものであり、処理負担軽減と異常状態検出時間の短縮という相反する条件を満たすとともに、複数本のトンネル接続を束ねて通信を行う通信方式において通信状態の悪いトンネル接続を避ける動作を迅速に行うことを可能とした生存確認の技術を提供することを目的とする。
【００１２】
ここで、複数本のトンネル接続を束ねてパケットを通すことで通信を安定化させる従来技術を用いる場合、送信側で順次送信しても途中経路の外乱等の影響で受信側では順序性が担保されない場合があり、その結果、パケットが順序逆転するため、電話やテレビ会議等のリアルタイム性が要求される場合など、アプリケーションの特性によりアプリケーションが正常に動作しない等の影響が出ていた。本発明の一実施形態では、このような順序逆転を防止する技術を提供することも目的としている。
【課題を解決するための手段】
【００１３】
上記の課題を解決するために、本発明は、サーバ装置との間に構築されたトンネルを介してデータ通信を行うクライアント装置であって、
前記サーバ装置との間で前記トンネルを構築し、当該トンネルを経由してパケットの送受信を行うクライアント側トンネル通信手段と、
前記トンネルを介して生存確認のためのパケット送受信を行うクライアント側生存確認手段と、を備え、
前記クライアント側生存確認手段は、
前記クライアント装置が備えるアプリケーション部からのデータパケット送信がない場合に、第１の時間間隔で生存確認要求を前記サーバ装置に送信し、当該生存確認要求を受信した前記サーバ装置から生存確認要求応答を受信した場合に、生存確認要求応答受領を前記サーバ装置に送信し、
前記アプリケーション部からのデータパケット送信がある場合において、生存確認要求応答又は生存確認要求応答付きデータパケットを前記サーバ装置から受信した後の第２の時間経過内に、生存確認要求応答受領付きデータパケットを前記サーバ装置に送信し、生存確認要求応答又は生存確認要求応答付きデータパケットを前記サーバ装置から受信した後の当該第２の時間経過後に、生存確認要求付きデータパケットを前記サーバ装置に送信し、
生存確認要求応答又は生存確認要求応答付きデータパケットを前記サーバ装置から受信しないで第３の時間が経過した場合に、前記トンネルの状態が悪化したと判定することを特徴とするクライアント装置として構成することができる。
【００１４】
前記第１の時間は前記第３の時間より長く、当該第３の時間は前記第２の時間より長いように設定することとしてよい。
【００１５】
また、本発明は、上記クライアント装置と、前記サーバ装置とを備える通信システムであって、
前記サーバ装置は、
前記サーバ装置との間で前記トンネルを構築し、当該トンネルを経由してパケットの送受信を行うサーバ側トンネル通信手段と、
前記トンネルを介して生存確認のためのパケット送受信を行うサーバ側生存確認手段と、を備え、
前記サーバ側生存確認手段は、
前記サーバ装置からのデータパケット送信がない場合において、生存確認要求を前記クライアント装置から受信した場合に、生存確認要求応答を前記クライアント装置に送信し、前記サーバ装置からのデータパケット送信がある場合において、生存確認要求付きデータパケットを前記クライアント装置から受信した場合に、生存確認要求応答付きデータパケットを前記クライアント装置に送信し、
生存確認要求応答又は生存確認要求応答付きデータパケットを前記クライアント装置に送信後、第４の時間経過内に生存確認要求応答受領又は生存確認要求応答受領付きデータパケットを前記クライアント装置から受信しない場合に、前記トンネルの状態が悪化したと判定することを特徴とする通信システムとして構成することもできる。
【００１６】
上記通信システムにおいて、
前記サーバ側トンネル通信手段は、
前記クライアント側トンネル通信手段との間に構築された複数のトンネルに対して順次、送信順を示す送信番号を付したパケットを送信する分配送信手段を備え、
前記クライアント側トンネル通信手段は、
最後に再送信を行った第１のパケットの送信番号と、前記サーバ側トンネル通信手段から受信した第２のパケットの送信番号とを比較し、当該第２のパケットの送信番号が前記第１のパケットの送信番号＋１以下である場合に、当該第２のパケットを再送信し、当該第２のパケットの送信番号が前記第１のパケットの送信番号＋２以上である場合において、キューの中にパケットが既に存在しない場合に、当該第２のパケットをキューに格納し、所定の時間経過後に、当該第２のパケットを再送信する再送信順序制御手段を備えるように構成してもよい。
【００１７】
また、前記サーバ側トンネル通信手段は、前記サーバ側生存確認手段により状態が悪化したと判定されたトンネルを使用しないように構成してもよい。
【００１８】
また、上記通信システムにおいて、
前記クライアント側トンネル通信手段は、
前記サーバ側トンネル通信手段との間に構築された複数のトンネルに対して順次、送信順を示す送信番号を付したパケットを送信する分配送信手段を備え、
前記サーバ側トンネル通信手段は、
最後に再送信を行った第１のパケットの送信番号と、前記クライアント側トンネル通信手段から受信した第２のパケットの送信番号とを比較し、当該第２のパケットの送信番号が前記第１のパケットの送信番号＋１以下である場合に、当該第２のパケットを再送信し、当該第２のパケットの送信番号が前記第１のパケットの送信番号＋２以上である場合において、キューの中にパケットが既に存在しない場合に、当該第２のパケットをキューに格納し、所定の時間経過後に、当該第２のパケットを再送信する再送信順序制御手段を備えるように構成してもよい。
【００１９】
また、前記クライアント側トンネル通信手段は、前記クライアント側生存確認手段により状態が悪化したと判定されたトンネルを使用しないように構成してもよい。
【発明の効果】
【００２０】
本発明によれば、処理負担軽減と異常状態検出時間の短縮という相反する条件を満たすとともに、複数本のトンネル接続を束ねて通信を行う通信方式において通信状態の悪いトンネル接続を避ける動作を迅速に行うことを可能とした生存確認の技術を提供することが可能となる。
【図面の簡単な説明】
【００２１】
【図１】トンネリング技術を利用したファイアウォール越え通信の例を示す図である。
【図２】本発明の実施の形態におけるシステムの全体構成図である。
【図３】クライアント装置１の生存確認機能部１２の機能構成図である。
【図４】サーバ装置２の生存確認機能部２２の機能構成図である。
【図５】システムの動作イメージを示す図である。
【図６】メッセージフォーマットの例を示す図である。
【図７】クライアント装置における生存確認処理フローである（トンネル接続時、生存確認要求応答受信時）。
【図８】クライアント装置における生存確認処理フローである（パケットデータ送信時、タイマー４Cタイムアウト処理時）。
【図９】クライアント装置における生存確認処理フローである（タイマー３Cタイムアウト処理時）。
【図１０】クライアント装置における生存確認処理フローである（タイマー２Cタイムアウト処理時）。
【図１１】クライアント装置における生存確認処理フローである（タイマー１Cタイムアウト処理時）。
【図１２】サーバ装置における生存確認処理フローである（トンネル接続時、生存確認要求応答受領受信時）。
【図１３】サーバ装置における生存確認処理フローである（生存確認要求付きデータパケット受信時）。
【図１４】サーバ装置における生存確認処理フローである（生存確認要求（単独）受信時、タイマー５Sタイムアウト時、パケットデータ送信時）。
【図１５】サーバ装置における生存確認処理フローである（タイマー２Sタイムアウト時）。
【図１６】クライアント装置における生存確認要求処理の状態遷移図である。
【図１７】サーバ装置における生存確認要求処理の状態遷移図である。
【図１８】系全体の状態遷移を表した状態遷移図である。
【図１９】サーバ装置とクライアント装置間における生存確認動作シーケンスの一例を示す図である。
【図２０】サーバ装置とクライアント装置間における生存確認動作シーケンスの一例を示す図である。
【図２１】パケット送信側とパケット受信側におけるトンネル機能部の構成を示す図である。
【図２２】複数トンネル接続通信（片方向分）の送信処理フロー（初期化処理）である。
【図２３】複数トンネル接続通信（片方向分）の送信処理フロー（分配送信処理）である。
【図２４】複数トンネル接続通信（片方向分）の送信処理フロー（トンネル状態良好化時処理、トンネル接続時処理）である。
【図２５】複数トンネル接続通信（片方向分）の送信処理フロー（トンネル状態応答悪化時処理、トンネル切断時処理）である。
【図２６】複数トンネル接続通信（片方向分）の受信処理フロー（初期化処理）である。
【図２７】複数トンネル接続通信（片方向分）の受信処理フロー（集約受信処理）である。
【図２８】複数トンネル接続通信（片方向分）の受信処理フロー（タイマータイムアウト処理）である。
【図２９】サーバ装置（送信側）からクライアント装置（受信側）への通信処理例（ジッタ小の場合）を示す図である。
【図３０】サーバ装置（送信側）からクライアント装置（受信側）への通信処理例（ジッタ大の場合）を示す図である。
【図３１】サーバ装置（送信側）からクライアント装置（受信側）への従来技術における通信処理例を示す図である。
【発明を実施するための形態】
【００２２】
以下、図面を参照して本発明の実施の形態を説明する。
【００２３】
＜第１の実施の形態＞
（システム構成）
図２に、第１の実施の形態におけるシステムの全体構成を示す。図２に示すように、本実施の形態のシステムは、インターネット５と、企業内ネットワーク等のプライベートネットワーク６との境界に設置されるファイアフォール装置４、ファイアウォール装置４配下にあるトンネルクライアント機能を有するクライアント装置１、トンネルサーバ機能を有するサーバ装置２、及び、クライアント装置１と通信を行う通信相手装置３とを含む。本実施の形態では、サーバ装置２と、通信相手装置３は、インターネット５に接続されている。
【００２４】
図２に示すように、クライアント装置１は、クライアント側のトンネル接続に係る処理を行うトンネル機能部１１と、本発明に係るクライアント側の生存確認処理を行う生存確認機能部１２と、IP電話や映像会議等の目的の通信を行うアプリケーション部１３を備える。サーバ装置２は、サーバ側のトンネル接続に係る処理を行うトンネル機能部２１と、本発明に係るサーバ側の生存確認処理を行う生存確認機能部２２を備える。
【００２５】
本実施の形態におけるクライアント装置１は、OS（オペレーティングシステム）と、上記機能部に対応するプログラム等を備えるコンピュータ（PC、携帯端末等）である。また、本実施の形態におけるサーバ装置２は、OS、上記機能部に対応するプログラム等を備えるコンピュータである。
【００２６】
図３に、クライアント装置１の生存確認機能部１２の機能構成を示す。図３に示すように、生存確認機能部１２は、生存確認用パケット送受信制御部１２１、情報格納部１２２、タイマー１C、タイマー２C、タイマー３C、タイマー４Cを有する。
【００２７】
生存確認用パケット送受信制御部１２１は、生存確認のためにパケットの送受信を制御する機能部であり、タイマーを参照しながら後述するような処理動作を行う。情報格納部１２２は、状態（良好、応答悪化）、生存確認要求応答受領送信済みフラグを格納する。
【００２８】
タイマー１Cは再接続発動タイマーであり、クライアント装置１が最終パケットを送信してから、再接続を実施するまでの時間を計測する。本実施の形態では、タイマー１Cが計測する時間として５秒程度の値を想定している。
【００２９】
タイマー２Cは状態悪化判定タイマーであり、クライアント装置１が最終パケットを送信してから、その応答が返るまでの基準となる時間を計測する。本実施の形態では、タイマー２Cが計測する時間として３秒程度の値を想定している。
【００３０】
タイマー３Cは生存確認要求送信兼応答受領タイマーであり、連続パケット送信時に「生存確認要求」を載せて送信する最低時間間隔を計測すると同時に、「生存確認要求応答受領」の送信までの期限を計測する。本実施の形態では、タイマー３Cが計測する時間として０．５秒程度の値を想定している。
【００３１】
タイマー４Cは生存確認要求最長送信タイマーであり、長時間パケットの送信が無い場合等に単独の「生存確認要求」を送信する期限を計測する。本実施の形態では、タイマー４Cが計測する時間として１０秒程度の値を想定している。
【００３２】
図４に、サーバ装置２の生存確認機能部２２の機能構成を示す。図４に示すように、生存確認機能部２２は、生存確認用パケット送受信制御部２２１、情報格納部２２２、タイマー２S、タイマー５Sを有する。
【００３３】
生存確認用パケット送受信制御部２２１は、生存確認のためにパケットの送受信を制御する機能部であり、タイマーを参照しながら後述するような処理動作を行う。情報格納部２２２は、状態（良好、応答悪化）を格納する。
【００３４】
タイマー２Sは状態悪化判定タイマーであり、サーバ装置２が「生存確認要求応答」を送信してから、「生存確認要求応答受領」をクライアント装置１から受信するまでの期限を計測する。本実施の形態では、タイマー２Sが計測する時間として３秒程度の値を想定している。
【００３５】
タイマー５Sは「生存確認要求応答」タイマーであり、サーバ装置２が「生存確認要求」（単独のものを除く）を受信してから「生存確認要求応答」を送信するまでの期限を計測する。本実施の形態では、タイマー５Sが計測する時間として１秒程度の値を想定している。
【００３６】
なお、「生存確認要求」と「生存確認要求応答受領」はクライアント装置１からサーバ装置２に伝達される信号であり、「生存確認要求応答」は逆にサーバ装置２からクライアント装置１に伝達される信号である。
【００３７】
本実施の形態に係るクライアント装置１及びサーバ装置２のそれぞれは、CPU、記憶装置等を有するコンピュータに上記の各機能を実現するためのプログラムを実行させることにより実現できる。当該プログラムは可搬メモリ等の記録媒体からコンピュータにインストールすることとしてもよいし、ネットワーク上のサーバからダウンロードすることとしてもよい。
【００３８】
また、トンネル接続を実現する方式には種々のものあるが、本発明においてトンネル接続を実現する方式は特定の方式に限定されるわけではなく、本発明は様々なトンネル接続の方式に適用可能である。
【００３９】
（システムの動作）
以下では、第１の実施の形態におけるシステムの動作を説明する。以下の動作は、基本的に、クライアント装置１の生存確認機能部１２と、サーバ装置２の生存確認機能部２２により実行されるものである。
【００４０】
図５は、システムの動作イメージを示す図である。図５に示すように、単独の生存確認用のメッセージ（パケット）、もしくは、本来の通信データ（アプリケーションプログラムにより送受信されるデータ）であるデータパケットに付された形での生存確認用のメッセージがクライアント装置１とサーバ装置２間で送受信される。
【００４１】
図６（ａ）〜（ｅ）は、本実施の形態で用いられるメッセージのフォーマット例を示す図である。なお、ここで示すフォーマットは一例に過ぎず、他の種々のフォーマット、サイズ、メッセージ種別を示す値を使用可能である。
【００４２】
本実施の形態では、ヘッダは１バイトのサイズとなっている。図６（ａ）に示すように、「23h」が上りトンネルに流れた場合、単独の生存確認要求とみなし、下りトンネルに流れた場合、単独の生存確認要求応答とみなす。図６（ｂ）に示すように、ヘッダ「24h」は単独の生存確認要求応答受領とみなす。
【００４３】
図６（ｃ）〜（ｅ）に示すように、データパケットを表すヘッダは「30h」となっており、これに生存確認要求または生存確認要求応答を重畳させた場合のヘッダは「31h」となる。また、生存確認要求応答受領を重畳させた場合のヘッダは「32h」となる。
【００４４】
このように、ヘッダの一部ビットを利用することにより、オーバーヘッド無しに生存確認が可能となる。
【００４５】
次に、図７〜図１５のフローチャートを参照して、クライアント装置１、及びサーバ装置２の動作を説明する。
図７は、クライアント装置１におけるトンネル接続時の処理、及び生存確認要求応答受信時の処理を示すフローチャートである。図７に示すように、クライアント装置１では、トンネル接続開始直後に、状態を「良好」に設定し（ステップ１）、生存確認要求応答受領送信済みフラグを「未送信」にセットする（ステップ２）。続いて、タイマー３C（生存確認要求送信兼応答受領タイマー）、タイマー４C（生存確認要求最長送信タイマー）をスタートさせ、タイマー１C（再接続発動タイマー）、タイマー２C（状態悪化判定タイマー）を停止させる。以降、クライアント装置１における生存確認機能部１２は、パケット到着やタイマー動作（タイムアウト）のイベントを契機に動作する。
【００４６】
図８は、データパケット送信時の処理、及びタイマー４C（生存確認要求最長送信タイマー）のタイムアウト時の処理を示すフローチャートである。
【００４７】
図８に示すように、クライアント装置１がデータパケットを送信する際に、先ずタイマー３C（生存確認要求送信兼応答受領タイマー）がタイムアウトしているか否かを判定する（ステップ１１）。タイマー３Cがタイムアウトしている場合（ステップ１１のＹｅｓ）、生存確認要求を送付すべきと判断し、生存確認要求をデータパケットに重畳して送信し（ステップ１２）、タイマー３Ｃを停止する（ステップ１３）。
【００４８】
一方、ステップ１１の判定がＮｏ、すなわちタイマー３Ｃ（生存確認要求送信兼応答受領タイマー）がタイムアウトしていなかった場合、必要に応じ、生存確認要求応答受領を送信すべきと判断し、生存確認要求応答受領送信済みフラグを検証し（ステップ１４）、未送信の場合（ステップ１４のＮｏ）に限り、生存確認要求応答受領をデータパケットに重畳して送信する（ステップ１５）し、生存確認要求応答受領送信済みフラグを「送信済み」にセットする。ステップ１４の判定がＹｅｓ、すなわち生存確認要求応答受領を送信済みであった場合、何も重畳せず、単独のデータパケットとして送信する（ステップ１７）。
【００４９】
ステップ１３、１６、１７の後、タイマー４Ｃを停止し、タイマー１Ｃ、２Ｃをスタートする（ステップ１９）。
【００５０】
サーバ装置２から生存確認要求応答を受信した場合のクライアント装置１の処理を図７を参照して説明する。図７に示すとおり、サーバ装置２から生存確認要求応答を受信した場合、タイマー２Ｃ（状態悪化判定タイマー）がタイムアウトしているか否かをチェックし（ステップ４）、タイマー２Ｃがタイムアウトしていない場合（ステップ４のＮｏ）に限り、状態を「良好」に設定し（ステップ１）、その後、クライアント装置１における状態をトンネル接続直後と同様に初期化する（ステップ２、３）。タイマー２Ｃがタイムアウトしている場合（ステップ４のＹｅｓ）、状態は「状態悪化」に設定されており、その設定のまま、クライアント装置１におけるフラグ等をトンネル接続直後と同様に初期化する（ステップ２、３）。
【００５１】
タイマー４Ｃ（生存確認要求最長送信タイマー）がタイムアウトした場合の処理を図８を参照して説明する。タイマー４Ｃがタイムアウトした場合、これはデータパケット送信がしばらく無かったことを意味するため、生存確認要求を単独パケットとして送信する（ステップ１８）。その後、タイマー４Cを停止し、タイマー１C（再接続発動タイマー）、タイマー２C（状態悪化判定タイマー）をスタートする（ステップ１９）。
【００５２】
図９はタイマー３C（生存確認要求送信兼応答受領タイマー）がタイムアウトした場合のクライアント装置１における処理を示すフローチャートである。タイマー３C（生存確認要求送信兼応答受領タイマー）がタイムアウトした場合、生存確認要求応答受領の送信タイミングであるから、生存確認要求応答受領送信済みフラグをチェックして送信済みか否かをチェックし（ステップ２１）、送信済みでなければ（ステップ２１のＮｏ）、生存確認要求応答受領を単独パケットとして送信し（ステップ２２）、生存確認要求応答受領送信済みフラグを「送信済み」にセットする（ステップ２３）。
【００５３】
図１０はタイマー２C（状態悪化判定タイマー）がタイムアウトした場合のクライアント装置１における処理を示すフローチャートである。図１０に示すように、タイマー２C（状態悪化判定タイマー）がタイムアウトした場合、状態が悪化したと判断され、状態を「応答悪化」に設定する（ステップ３１）。
【００５４】
図１１はタイマー１C（再接続発動タイマー）がタイムアウトした場合のクライアント装置１における処理を示すフローチャートである。図１１に示すように、タイマー１C（再接続発動タイマー）がタイムアウトした場合、新規に１本トンネル接続を行い（ステップ５１）、トンネル接続時処理を行って（ステップ５２）、旧トンネル接続を切断し（ステップ５３）、新トンネル接続に制御を渡す。
【００５５】
図１２はトンネル接続時等におけるサーバ装置２の処理を示すフローチャートである。図１２に示すように、サーバ装置２では、トンネル接続時に状態を「良好」に設定し（ステップ６１）、以降、以下で説明するようにイベントベースで動作する。
【００５６】
図１３は、生存確認要求付きデータパケットをクライアント装置１から受信した場合におけるサーバ装置２の処理を示すフローチャートである。図１３に示すように、生存確認要求付きデータパケットをクライアント装置１から受信した場合、タイマー５Ｓ（生存確認要求応答タイマー）をスタートする（ステップ７１）。
図１４は、生存確認要求を単独パケットとしてクライアント装置１から受信した場合等におけるサーバ装置２の処理を示すフローチャートである。図１４に示すように、生存確認要求を単独で受信した場合、サーバ装置２は、生存確認要求応答を単独でクライアント装置１に送信し（ステップ８１）、タイマー２Ｓ（状態悪化判定タイマー）を（再）スタートし、タイマー５Ｓを停止する（ステップ８４）。
【００５７】
また、図１４に示すように、クライアント装置１へデータパケットを送信する時には、タイマー５Ｓ（生存確認要求応答送信タイマー）が動作中か否かを判断し（ステップ８２）、動作中（ステップ８２のYｅｓ）であれば、生存確認要求応答付きのデータパケットをクライアント装置１に送信し（ステップ８３）、タイマー２Ｓ（状態悪化判定タイマー）を（再）スタートし、タイマー５Ｓを停止する（ステップ８４）。タイマー５Ｓ（生存確認要求応答送信タイマー）が動作中でない場合（ステップ８２のNｏ）、通常のデータパケット送信を行う（ステップ８５）。
【００５８】
図１２に示すように、生存確認要求応答受領をクライアント装置１から受信した場合、タイマー２Ｓ（状態悪化判定タイマー）がタイムアウトしていない場合（ステップ６２のNｏ）に限り、状態を「良好」に設定する（ステップ６１）。
【００５９】
図１４に示すように、タイマー５Ｓ（生存確認要求応答送信タイマー）がタイムアウトした場合、単独の生存確認要求応答をクライアント装置１に送信し（ステップ８１）、ステップ８４を行う。
【００６０】
また、図１５に示すように、タイマー２Ｓ（状態悪化判定タイマー）がタイムアウトした場合、状態を「応答悪化」に設定する（ステップ９１）。
【００６１】
次に、上述した各装置における処理手順に対応する状態の遷移について説明する。
【００６２】
図１６は、クライアント装置１における生存確認要求処理の状態遷移図である。図１６に示すように、「良好」の状態からタイマー２C（状態悪化判定タイマー）の経過で「応答悪化」になる（ステップ１０１）。タイマー１C（再接続発動タイマー）経過前でのパケット送信を契機にタイマー２Cがスタートし、タイマー２C経過前のパケット到着により「良好」の状態になる（ステップ１０２）。
【００６３】
「応答悪化」の状態からタイマー１C（再接続発動タイマー）が経過すると、「接続不良」（※１）となり、「切断」（※２）となる（ステップ１０３、１０４）。そして、初期接続、もしくは再接続を経て「良好」の状態になる（ステップ１０５）。ただし、本発明の実施の形態では、接続不良と判断された場合（タイマー１Cが経過した場合）、直ちに切断するため「接続不良」状態は実効上存在しない。また、本実施の形態の構成上、「切断」状態を扱う必要がないため、フローチャート上は「切断」状態を示していない。
【００６４】
図１７は、サーバ装置２における生存確認要求処理の状態遷移図である。図１７に示すように、「良好」の状態からタイマー２S（状態悪化判定タイマー）の経過で「応答悪化」になる（ステップ２０１）。タイマー２S再スタート後、タイマー２S経過前のパケット到着により「良好」の状態になる（ステップ２０２）。また、「良好」もしくは「応答悪化」の状態から切断された場合に「切断」となり、その後、接続がなされる（ステップ２０３、２０４、２０５）。なお、前述したとおり、本実施の形態の構成上、「切断」状態を扱う必要がないため、フローチャート上は「切断」状態を示していない。
【００６５】
図１８は、クライアント装置１とサーバ装置２を１セットのシステムとみなし、系全体の状態遷移を表した状態遷移図である。図１８では、概ね、単独または重畳で受信する制御信号を「状態」として、タイマーのタイムアウトやパケット送信を状態遷移の条件という形で表記している。
【００６６】
上記のフローチャートや状態遷移に従った処理動作を行うサーバ装置２とクライアント装置１間における生存確認動作シーケンスの一例を図１９に示す。図１９に示す例は、データパケットの通信がない場合の動作を示している。
【００６７】
図１９の場合、クライアント装置１においてデータパケットの送信がされないので、図７のステップ３でスタートしたタイマー４Ｃ（生存確認要求最長送信タイマー）は、データパケットの送信を契機として停止されることはなく、タイムアウトになり、図８のステップ１８に示すとおり、単独での生存確認要求が送信される（図１９のステップ５０１）。生存確認要求を受信したサーバ装置２において、図１４のステップ８１、８４に示すとおり、単独の生存確認要求応答をクライアント装置１に送信し（図１９のステップ５０２）、タイマー２Ｓ（状態悪化判定タイマー）を（再）スタートする。
【００６８】
生存確認要求応答を受信したクライアント装置１は、図７に示す生存確認要求応答受信時の処理を行い、タイマー３Ｃ、４Ｃをスタートする。図１９の例では、データパケットに付される生存確認要求応答を受信することはないので、タイマー３Ｃはタイムアウトし、図８に示すように、クライアント装置１は単独の生存確認要求応答受領をサーバ装置２に送信する（図１９のステップ５０３）。生存確認要求応答受領を受信したサーバ装置１では、図１２に示すように、タイマー２Ｓのタイムアウト確認を行うが、本例ではタイマー２Ｓはタイムアウトしておらず、状態は「良好」であると判断する。
【００６９】
その後、クライアント装置１においてタイマー４Ｃ（生存確認要求最長送信タイマー）がタイムアウトし、生存確認要求を送信し（ステップ５０４）、サーバ装置２から生存確認要求応答が送信される（ステップ５０５）。
【００７０】
このようにデータパケットの送受信がない場合、タイマー４Ｃにより決定される最長間隔で生存確認が繰り返される。
【００７１】
生存確認動作シーケンスの他の例を図２０に示す。図２０に示す例は、データパケットの送受信がある場合の動作を示している。
【００７２】
本例において、データパケットがないときには、上述した処理と同様にして、生存確認要求、生存確認要求応答、生存確認要求応答受領の送受信がなされる（ステップ６０１〜６０３）。
【００７３】
クライアント装置１において送信するデータパケットがある場合、図８に示すとおり、タイマー３C（生存確認要求送信兼応答受領タイマー）をチェックし、ここではタイムアウトしているので、生存確認要求付きデータパケットを送信する（ステップ６０４）。
【００７４】
一方、サーバ装置２からは順次データパケットが送信されるが、図２０の例において、ステップ６０５に示すデータパケットは、タイマー５S（生存確認要求応答タイマー）が動作中でないため、通常のデータパケットとして送信される（図１４のステップ８５）。
【００７５】
ステップ６０４の生存確認要求付きデータパケットを受信したサーバ装置２において、図１３のステップ７１に示すとおり、タイマー５S（生存確認要求応答タイマー）がスタートし、図１４のステップ８３に示すとおり、データパケット送信を契機として生存確認要求応答付きデータパケットが送信され（図２０のステップ６０６）、タイマー５Sが停止し、タイマー２S（状態悪化判定タイマー）が再スタートされる。
【００７６】
クライアント装置１からも順次データパケットが送信されるが、図２０の例において、ステップ６０７、６１２に示すデータパケットについては、タイマー３Cが停止されている（タイムアウトしていない）とともに、生存確認要求応答受領を送信済みなので、生存確認要求なしのデータパケットとして送信される（図８のステップ１７）。
【００７７】
ステップ６０６の生存確認要求応答付きデータパケットを受信したクライアント装置１は、図７に示すとおり、タイマー３C、４Cをスタートさせるとともに、データパケット送信時に、生存確認要求応答受領付きデータパケットを送信する（図２０のステップ６０８、図８のステップ１５）。
【００７８】
ステップ６０９、６１０で示すデータパケットについては、タイマー５Sが動作中でないので、そのままサーバ装置２からクライアント装置１に送信される。
【００７９】
ステップ６０８の生存確認要求応答受領付きデータパケットを送信した後、クライアント装置１では、データパケット送信時に、生存確認要求付きデータパケットを送信する（図２０のステップ６１１、図８のステップ１２）。
【００８０】
ステップ６１１の生存確認要求付きデータパケットを受信したサーバ装置２において、タイマー５S（生存確認要求応答タイマー）がスタートするが、ここではタイマー５Sがタイムアウトし、単独の生存確認要求応答が送信される（ステップ６１３）。それを受けたクライアント装置１からはタイマー３Cのタイムアウトを契機として単独の生存確認要求応答受領が送信される（ステップ６１４）。
【００８１】
このようにデータパケットの送受信がある場合、タイマー２Ｓ（状態悪化判定タイマー）とクライアント装置１からの上りパケット送信間隔で決まる短い時間間隔での生存確認が繰り返される。これにより状態監視が頻繁になるため、より短期間に状態悪化を検出できる。
【００８２】
本実施の形態において、クライアント装置１とサーバ装置２間のトンネルの本数は特に限定されないが、これまでの説明はトンネルが１本である場合を想定している。
【００８３】
後述する第２の実施の形態にように、複数本のトンネルを使用する場合は、本実施の形態で説明する生存確認処理をトンネル毎に行う。
【００８４】
また、本実施の形態に係る構成は、以下のように表すこともできる。
【００８５】
サーバ装置２との間に構築されたトンネルを介してデータ通信を行うクライアント装置１は、前記サーバ装置２との間で前記トンネルを構築し、当該トンネルを経由してパケットの送受信を行うクライアント側トンネル通信手段１１と、前記トンネルを介して生存確認のためのパケット送受信を行うクライアント側生存確認手段１２と、を備え、前記クライアント側生存確認手段１２は、前記クライアント装置１が備えるアプリケーション部１３からのデータパケット送信がない場合に、第１の時間（タイマー４Ｃ）間隔で生存確認要求を前記サーバ装置２に送信し、当該生存確認要求を受信した前記サーバ装置２から生存確認要求応答を受信した場合に、生存確認要求応答受領を前記サーバ装置２に送信し、前記アプリケーション部１３からのデータパケット送信がある場合において、生存確認要求応答又は生存確認要求応答付きデータパケットを前記サーバ装置２から受信した後の第２の時間（タイマー３Ｃ）経過内に、生存確認要求応答受領付きデータパケットを前記サーバ装置２に送信し、生存確認要求応答又は生存確認要求応答付きデータパケットを前記サーバ装置から受信した後の当該第２の時間経過後に、生存確認要求付きデータパケットを前記サーバ装置２に送信し、前記生存確認要求応答又は前記生存確認要求応答付きデータパケットを前記サーバ装置から受信しないで第３の時間（タイマー２Ｃ）が経過した場合に、前記トンネルの状態が悪化したと判定する。
【００８６】
また、前記サーバ装置２は、前記サーバ装置２との間で前記トンネルを構築し、当該トンネルを経由してパケットの送受信を行うサーバ側トンネル通信手段２１と、前記トンネルを介して生存確認のためのパケット送受信を行うサーバ側生存確認手段２２と、を備え、前記サーバ側生存確認手段２２は、前記サーバ装置２からのデータパケット送信がない場合において、生存確認要求を前記クライアント装置１から受信した場合に、生存確認要求応答を前記クライアント装置１に送信し、前記サーバ装置２からのデータパケット送信がある場合において、生存確認要求付きデータパケットを前記クライアント装置１から受信した場合に、生存確認要求応答付きデータパケットを前記クライアント装置１に送信し、前記生存確認要求応答又は前記生存確認要求応答付きデータパケットを前記クライアント装置１に送信後、第４の時間（タイマー２Ｓ）経過内に生存確認要求応答受領又は生存確認要求応答受領付きデータパケットを前記クライアント装置１から受信しない場合に、前記トンネルの状態が悪化したと判定する。
【００８７】
＜第２の実施の形態＞
次に、本発明の第２の実施の形態について説明する。本実施の形態でのシステム構成は図２〜４で説明した第１の実施の形態と同様である。ただし、本実施の形態では、クライアント装置１のトンネル機能部１１、及びサーバ装置２のトンネル機能部２１のそれぞれが、複数本のトンネル接続を束ねてパケット送受信を行う機能を備えている。また、生存確認機能部１２、２２は、複数本のトンネル接続を用いる構成に対応した機能を含む。
【００８８】
図２１は、パケット送信側とパケット受信側におけるトンネル機能部１１、２１の構成を示す図である。図２１は、本実施の形態の機能を分かりやすく示すために、片方向の通信構成を示すものであるが、実際には、クライアント装置１とサーバ装置２の各々において、図２１に示すパケット送信側の機能とパケット受信側の機能を備える。つまり、図２１は、クライアント装置１からサーバ装置２への上り方向の通信構成、または、サーバ装置２からクライアント装置１への下り方向の通信構成を示している。
【００８９】
図２１に示すように、パケット送信側のトンネル機能部は、分配部１０１、カウンター１０２、トンネル接続リスト格納部１０３を含む。パケット受信側のトンネル機能部は、集約受信部２０１、最終送信番号格納部２０２、タイマー２０３を含む。もちろん、各トンネル機能部は、複数本のトンネル接続を行う機能も含む。
【００９０】
パケット送信側では、トンネル接続リスト格納部１０３に接続中のトンネルのリストであるトンネル接続リストが格納される。図２１の例では、トンネル接続０〜Nが示されている。分配部１０１は、トンネル接続リスト及びカウンターを利用して、送信対象のパケットに対して順次番号を付与し、複数のトンネルに対して順次パケットを送信する。送信に用いるトンネルを複数リストとして順に用いて送信する構成となっている。また、各トンネルの状態が悪化した場合、リストから取り除き、良好に復帰した場合、再度リストに加える。
【００９１】
パケット受信側では、最後に再送信したパケットの番号が、最終送信番号格納部２０２に格納される。集約受信部２０１はパケットを格納するキュー（バッファメモリ）を備え、以下の処理を行う。なお、以下のような制御を行う集約受信部２０１は、再送信順序制御手段の一例である。
【００９２】
集約受信部２０１は、最終送信パケット番号と受信したパケットのパケット番号とを比較し、受信したパケットのパケット番号が最終送信パケット番号＋１以下であれば直ちに送信し、＋２以上であれば、集約受信部２０１におけるキューの中を確認し、既に待ち合わせのパケットがあればキューの中のパケットに引き続き受信したパケットを再送信する。キューにパケットが無ければ、受信したパケットをキューに格納してタイマー２０３を始動する。タイマー２０３がタイムアウトするまで次のパケットがこなかった場合は、キューに格納されたパケットを送信する。
【００９３】
以下では、上記の処理をより詳細にフローチャートを参照して説明する。
【００９４】
図２２は、パケット送信側トンネル機能部における初期化処理を示すフローチャートである。図２２に示すように、カウンター値を０にし（ステップ１１１）、トンネル接続リストを空にし（ステップ１１２）、トンネル接続をN本オープンする（ステップ１１３）。
【００９５】
図２３は、パケット送信側トンネル機能部における分配部１０１が行う分配送信処理を示すフローチャートである。図２３に示すように、パケットにカウンター値を付加し（ステップ１２１）、トンネル接続リストの先頭にあるトンネルにパケットを送信する（ステップ１２２）。そして、カウンター値に１を加算し（ステップ１２３）、トンネル接続リストの先頭の要素をリストの末尾に移動する（ステップ１２４）。
【００９６】
図２４は、パケット送信側トンネル機能部における、トンネル状態「良好」化時、もしくはトンネル接続時の処理を示すフローチャートである。ここで、トンネル状態「良好」化時とは、生存確認部（１２、２２）において、トンネル接続が「応答悪化」の状態から、「良好」の状態になったことが検知された時のことである。
【００９７】
ここでは、トンネル接続の末尾に、接続した（又は良好になった）トンネルを追加する（ステップ１３１）。
【００９８】
図２５は、パケット送信側トンネル機能部における、トンネル状態「応答悪化」時、もしくはトンネル切断時の処理を示すフローチャートである。ここで、トンネル状態「応答悪化」時とは、生存確認部（１２、２２）において、トンネル接続が「良好」の状態から、「応答悪化」の状態になったことが検知された時のことである。
【００９９】
ここでは、トンネル接続リストから該当するトンネルを削除する（ステップ１４１）。
【０１００】
図２６は、パケット受信側トンネル機能部における初期化処理を示すフローチャートである。初期化時において、最終送信番号を−１にする（ステップ１５１）。
【０１０１】
図２７は、パケット受信側トンネル機能部における集約受信部２０１が実行する集約受信処理を示すフローチャートである。
【０１０２】
パケットを受信すると、受信したパケットのパケット番号が最終送信番号＋１以下かどうかをチェックする（ステップ１６１）。最終送信番号＋１以下である場合（ステップ１６１のYes）、受信したパケットを再送信し、最終送信番号を当該パケットの番号とする（ステップ１６２）。
【０１０３】
ステップ１６１において、受信したパケットのパケット番号が最終送信番号＋１以下でない場合（＋２以上の場合）、キューの中に既に待ち合わせ中のパケットが存在するか否かを確認する（ステップ１６３）。待ち合わせ中のパケットが存在する場合（ステップ１６３のYes）、キューの中のパケットを全て送信し、タイマーを停止し、最終送信番号を更新する（ステップ１６４）。その後、受信したパケットを再送信し、最終送信番号を当該パケットの番号とする（ステップ１６２）。ステップ１６３において待ち合わせ中のパケットが存在しない場合、パケットをキューに投入し（ステップ１６５）、タイマーをスタートする（ステップ１６６）。
【０１０４】
図２８は、パケット受信側トンネル機能部におけるタイマータイムアウト処理を示すフローチャートである。図２８に示すとおり、タイマーがタイムアウトになると、キューの中のパケットを、パケットを受信した順番で全て送信し、タイマーを停止し、最終送信番号を更新する（ステップ１７１）。
【０１０５】
本実施の形態では、送信に用いるトンネル接続について、接続状態であると同時に、トンネル状態が「良好」であることも条件としている。つまり、状態が悪化したと判定されたトンネル接続を使用しないこととしている。これにより、パケット再送等により一時的に応答の悪化したトンネル接続を回避して良好な応答を保つことができる。
【０１０６】
上記のように動作するトンネル機能部を備えるサーバ装置２（送信側）からクライアント装置１（受信側）への通信処理例を図２９、図３０を参照して説明する。
【０１０７】
図２９は、サーバ装置２からクライアント装置１への伝送路におけるジッターが小さい場合の処理例を示す。図２９に示すように、パケット＃０〜＃１５がサーバ装置２から各トンネル接続経由で順番に送信される。本例では、パケット＃４がパケット＃５よりも少し遅れてクライアント装置１に到達する。この場合、受信側の処理を示す図２７に示すように、クライアント装置１では、パケット＃３の次に受信するパケット＃５をキューに格納し、タイマータイムアウト前にパケット＃４を受信することにより、パケット＃４をアプリケーションプログラム（アプリケーション部１３）に送信し、次に、キューの中のパケット＃５をアプリケーションプログラムに送信する。パケット＃８、＃９についても同様である。
【０１０８】
このように、ジッターが小さい場合、順序が入れ替わって到着したパケットも順序通り並べ替えて送信することができる。
【０１０９】
図３０は、サーバ装置２からクライアント装置１への伝送路におけるジッターが大きい場合の処理例を示す。
【０１１０】
本例では、パケット＃６が大きく遅れてクライアント装置１に到達する。この場合、クライアント装置１において、パケット＃５の次に受信したパケット＃７はキューに格納されるが、続くパケットを受信する前にタイマーがタイムアウトになり、キューの中のパケット＃７が送信される。従って、パケット＃７については少し遅延する。
【０１１１】
パケット＃６はパケット＃９の次に受信され、パケット＃１１がその次に受信される。この場合、パケット＃９の次に受信したパケット＃６についての図２７のステップ１６１の判定はYesになるので、パケット＃６はすぐにアプリケーションプログラムに送信される。次に受信するパケット＃１１については、キューに格納される（ステップ１６１のNo、ステップ１６３、１６５）。タイマータイムアウト前にパケット＃１０を受信することにより、パケット＃１０をアプリケーションプログラムに送信し、次に、キューの中のパケット＃１１をアプリケーションプログラムに送信する。
【０１１２】
ジッターが大きい場合、大きい遅延を受けたパケットについての順序入れ替わりは防止できないものの他のパケットまでが大きく遅延することなく処理される。
【０１１３】
ここで、従来技術による複数トンネリング通信での受信処理の一例（ジッター小の場合）を図３１に示す。図３１に示すように、ジッターが小であっても、従来技術では順序逆転が発生してしまうが、本実施の形態に係る技術では順序逆転を防止できる。これにより、リアルタイムコミュニケーション系などパケットの順序性が問題になるアプリケーションでも、順序逆転を防止することにより、品質低下を抑制できる。
【０１１４】
＜実施の形態の効果＞
第１、第２の実施の形態で説明した技術によれば、データパケットが送受信されているときに、データパケットに重畳して生存確認用の信号を送受信する構成をとるので、処理負担軽減と異常状態検出時間の短縮という相反する条件を満たした生存確認を行うことができるとともに、サーバ装置側でも通信状態の安定性判定をすることでより短い時間で状態判定が行うことができ、クライアント装置１からサーバ装置２への上り方向の状態判定と同様にサーバ装置２からクライアント装置１への下り方向の状態判定も可能となる。そのため、トンネルのコネクションが切断されてしまった等の異常事態をいち早く検出し、他の正常なトンネル接続に振り分けることでトンネル経由の通信への影響時間を短縮することができる。
【０１１５】
また、一定時間内のパケット順序入れ替り補正により、ほとんどのパケット順序を保ったままで、かつ遅延時間を小さく伝送できるため、VoIPや映像コミュニケーションなどリアルタイム通信でかつパケット順序が通信品質に影響を与える通信プロトコルに対しても安定的に利用可能となる。
【０１１６】
本発明は、上記の実施の形態に限定されることなく、特許請求の範囲内において、種々変更・応用が可能である。
【符号の説明】
【０１１７】
１ クライアント装置
１１ トンネル機能部
１２ 生存確認機能部
１３ アプリケーション部
２ サーバ装置
２１ トンネル機能部
２２ 生存確認機能部
３ 通信相手装置
４ ファイアウォール装置
５ インターネット
６ プライベートネットワーク
１２１ 生存確認用パケット送受信制御部
１C、２C、３C、４C タイマー
１２２ 情報格納部
２２１ 生存確認用パケット送受信制御部
２S、５S タイマー
２２２ 情報格納部
１０１ 分配部
１０２ カウンター
１０３ トンネル接続リスト格納部
２０１ 集約受信部
２０２ 最終送信番号格納部
２０３ タイマー
【技術分野】
【０００１】
本発明は、通信ネットワークにおける生存確認技術に関連するものである。
【背景技術】
【０００２】
企業内ネットワークや家庭内ネットワーク等のプライベートネットワークと、インターネット等の外部ネットワークとの間には、通信のセキュリティを確保するためのファイアウォール装置（NAT装置等も含む）が設置されるのが一般的である。
【０００３】
このようなファイアウォール装置では、ネットワーク管理のポリシーに応じて、通信を許可するプロトコルが設定されるが、例えば、多くの場合、プライベートネットワーク内のクライアント装置からの要求に係るHTTP／HTTPS通信は許容されている。
【０００４】
そこで、プライベートネットワーク内のクライアント装置と、外部の装置との間で、IP電話や映像会議等の通信を行うために、HTTPのように通信が許容されているプロトコルのヘッダで、目的とする通信のパケットをカプセリングすることにより、仮想的な通信路であるトンネルを形成し、当該トンネルを通して、IP電話や映像会議等の目的とする通信を行うトンネリング技術が用いられている。
【０００５】
図１は、上記のようなトンネリング技術を利用したファイアウォール越え通信の例を示す図である。図１に示すように、トンネリング技術では、トンネルクライアント機能を備えたクライアント装置（図１の例ではPC)と、外部ネットワーク（インターネット）に設置されたトンネルサーバ装置との間でトンネルを形成し、通信を行う。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開2010-109733号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
トンネリングを用いた通信を行う場合に、途中経路で通過するファイアウォール装置やプロクシサーバ装置の機能により、長時間無通信の場合に、強制的に切断させられてしまう場合や、切断状態にならないまでも信号が疎通しなくなっている、いわゆるトンネルが詰まった状態が生じる場合がある。このような状態を回避するために、クライアント装置がトンネルサーバ装置に生存確認要求を定期的に送信し、クライアント装置がサーバ装置から生存確認要求応答を受信することにより、クライアント装置がトンネル状態の判断や再接続等を行う疎通確認技術が従来からある。
【０００８】
上記の技術では、生存確認要求の送信間隔が短いと、本来のデータパケット以外の無駄なパケットが増加し、無通信クライアントを含む多数のクライアントのトラフィックが集中するトンネルサーバ装置やそのネットワークにおいて、処理負荷が増加し、性能低下を招く恐れがある。逆に、送信間隔を長くしてしまうと、詰まり状態を長時間検出できず、通信が長時間途切れたりする問題が生じる。つまり、従来の疎通確認のための技術では、処理負担軽減と異常状態検出時間の短縮という相反する条件を同時に満たすことは困難であった。
【０００９】
一方、TCP/IP等の技術により実現される信頼性が担保された通信路では、通信路上のパケットドロップ等の外乱によりパケットの再送等が発生し、結果として遅延が生じることで通信が安定しない場合がある。これを解消するため、複数本のトンネル接続を束ねて１本の論理的なトンネル接続を構成し、その中にパケットを分散して送信することで通信の安定化を図る従来技術がある。
【００１０】
上記の技術では、より安定した通信を実現するために、複数本のトンネル接続の各々について、例えば上述した疎通確認技術を適用することにより、無通信切断防止及び疎通確認を行うとともに、複数本のトンネル接続経由でパケットを流す際に、通信状態の悪いトンネル接続を避けてパケットを流すことが望ましい。
【００１１】
本発明は上記の問題点に鑑みてなされたものであり、処理負担軽減と異常状態検出時間の短縮という相反する条件を満たすとともに、複数本のトンネル接続を束ねて通信を行う通信方式において通信状態の悪いトンネル接続を避ける動作を迅速に行うことを可能とした生存確認の技術を提供することを目的とする。
【００１２】
ここで、複数本のトンネル接続を束ねてパケットを通すことで通信を安定化させる従来技術を用いる場合、送信側で順次送信しても途中経路の外乱等の影響で受信側では順序性が担保されない場合があり、その結果、パケットが順序逆転するため、電話やテレビ会議等のリアルタイム性が要求される場合など、アプリケーションの特性によりアプリケーションが正常に動作しない等の影響が出ていた。本発明の一実施形態では、このような順序逆転を防止する技術を提供することも目的としている。
【課題を解決するための手段】
【００１３】
上記の課題を解決するために、本発明は、サーバ装置との間に構築されたトンネルを介してデータ通信を行うクライアント装置であって、
前記サーバ装置との間で前記トンネルを構築し、当該トンネルを経由してパケットの送受信を行うクライアント側トンネル通信手段と、
前記トンネルを介して生存確認のためのパケット送受信を行うクライアント側生存確認手段と、を備え、
前記クライアント側生存確認手段は、
前記クライアント装置が備えるアプリケーション部からのデータパケット送信がない場合に、第１の時間間隔で生存確認要求を前記サーバ装置に送信し、当該生存確認要求を受信した前記サーバ装置から生存確認要求応答を受信した場合に、生存確認要求応答受領を前記サーバ装置に送信し、
前記アプリケーション部からのデータパケット送信がある場合において、生存確認要求応答又は生存確認要求応答付きデータパケットを前記サーバ装置から受信した後の第２の時間経過内に、生存確認要求応答受領付きデータパケットを前記サーバ装置に送信し、生存確認要求応答又は生存確認要求応答付きデータパケットを前記サーバ装置から受信した後の当該第２の時間経過後に、生存確認要求付きデータパケットを前記サーバ装置に送信し、
生存確認要求応答又は生存確認要求応答付きデータパケットを前記サーバ装置から受信しないで第３の時間が経過した場合に、前記トンネルの状態が悪化したと判定することを特徴とするクライアント装置として構成することができる。
【００１４】
前記第１の時間は前記第３の時間より長く、当該第３の時間は前記第２の時間より長いように設定することとしてよい。
【００１５】
また、本発明は、上記クライアント装置と、前記サーバ装置とを備える通信システムであって、
前記サーバ装置は、
前記サーバ装置との間で前記トンネルを構築し、当該トンネルを経由してパケットの送受信を行うサーバ側トンネル通信手段と、
前記トンネルを介して生存確認のためのパケット送受信を行うサーバ側生存確認手段と、を備え、
前記サーバ側生存確認手段は、
前記サーバ装置からのデータパケット送信がない場合において、生存確認要求を前記クライアント装置から受信した場合に、生存確認要求応答を前記クライアント装置に送信し、前記サーバ装置からのデータパケット送信がある場合において、生存確認要求付きデータパケットを前記クライアント装置から受信した場合に、生存確認要求応答付きデータパケットを前記クライアント装置に送信し、
生存確認要求応答又は生存確認要求応答付きデータパケットを前記クライアント装置に送信後、第４の時間経過内に生存確認要求応答受領又は生存確認要求応答受領付きデータパケットを前記クライアント装置から受信しない場合に、前記トンネルの状態が悪化したと判定することを特徴とする通信システムとして構成することもできる。
【００１６】
上記通信システムにおいて、
前記サーバ側トンネル通信手段は、
前記クライアント側トンネル通信手段との間に構築された複数のトンネルに対して順次、送信順を示す送信番号を付したパケットを送信する分配送信手段を備え、
前記クライアント側トンネル通信手段は、
最後に再送信を行った第１のパケットの送信番号と、前記サーバ側トンネル通信手段から受信した第２のパケットの送信番号とを比較し、当該第２のパケットの送信番号が前記第１のパケットの送信番号＋１以下である場合に、当該第２のパケットを再送信し、当該第２のパケットの送信番号が前記第１のパケットの送信番号＋２以上である場合において、キューの中にパケットが既に存在しない場合に、当該第２のパケットをキューに格納し、所定の時間経過後に、当該第２のパケットを再送信する再送信順序制御手段を備えるように構成してもよい。
【００１７】
また、前記サーバ側トンネル通信手段は、前記サーバ側生存確認手段により状態が悪化したと判定されたトンネルを使用しないように構成してもよい。
【００１８】
また、上記通信システムにおいて、
前記クライアント側トンネル通信手段は、
前記サーバ側トンネル通信手段との間に構築された複数のトンネルに対して順次、送信順を示す送信番号を付したパケットを送信する分配送信手段を備え、
前記サーバ側トンネル通信手段は、
最後に再送信を行った第１のパケットの送信番号と、前記クライアント側トンネル通信手段から受信した第２のパケットの送信番号とを比較し、当該第２のパケットの送信番号が前記第１のパケットの送信番号＋１以下である場合に、当該第２のパケットを再送信し、当該第２のパケットの送信番号が前記第１のパケットの送信番号＋２以上である場合において、キューの中にパケットが既に存在しない場合に、当該第２のパケットをキューに格納し、所定の時間経過後に、当該第２のパケットを再送信する再送信順序制御手段を備えるように構成してもよい。
【００１９】
また、前記クライアント側トンネル通信手段は、前記クライアント側生存確認手段により状態が悪化したと判定されたトンネルを使用しないように構成してもよい。
【発明の効果】
【００２０】
本発明によれば、処理負担軽減と異常状態検出時間の短縮という相反する条件を満たすとともに、複数本のトンネル接続を束ねて通信を行う通信方式において通信状態の悪いトンネル接続を避ける動作を迅速に行うことを可能とした生存確認の技術を提供することが可能となる。
【図面の簡単な説明】
【００２１】
【図１】トンネリング技術を利用したファイアウォール越え通信の例を示す図である。
【図２】本発明の実施の形態におけるシステムの全体構成図である。
【図３】クライアント装置１の生存確認機能部１２の機能構成図である。
【図４】サーバ装置２の生存確認機能部２２の機能構成図である。
【図５】システムの動作イメージを示す図である。
【図６】メッセージフォーマットの例を示す図である。
【図７】クライアント装置における生存確認処理フローである（トンネル接続時、生存確認要求応答受信時）。
【図８】クライアント装置における生存確認処理フローである（パケットデータ送信時、タイマー４Cタイムアウト処理時）。
【図９】クライアント装置における生存確認処理フローである（タイマー３Cタイムアウト処理時）。
【図１０】クライアント装置における生存確認処理フローである（タイマー２Cタイムアウト処理時）。
【図１１】クライアント装置における生存確認処理フローである（タイマー１Cタイムアウト処理時）。
【図１２】サーバ装置における生存確認処理フローである（トンネル接続時、生存確認要求応答受領受信時）。
【図１３】サーバ装置における生存確認処理フローである（生存確認要求付きデータパケット受信時）。
【図１４】サーバ装置における生存確認処理フローである（生存確認要求（単独）受信時、タイマー５Sタイムアウト時、パケットデータ送信時）。
【図１５】サーバ装置における生存確認処理フローである（タイマー２Sタイムアウト時）。
【図１６】クライアント装置における生存確認要求処理の状態遷移図である。
【図１７】サーバ装置における生存確認要求処理の状態遷移図である。
【図１８】系全体の状態遷移を表した状態遷移図である。
【図１９】サーバ装置とクライアント装置間における生存確認動作シーケンスの一例を示す図である。
【図２０】サーバ装置とクライアント装置間における生存確認動作シーケンスの一例を示す図である。
【図２１】パケット送信側とパケット受信側におけるトンネル機能部の構成を示す図である。
【図２２】複数トンネル接続通信（片方向分）の送信処理フロー（初期化処理）である。
【図２３】複数トンネル接続通信（片方向分）の送信処理フロー（分配送信処理）である。
【図２４】複数トンネル接続通信（片方向分）の送信処理フロー（トンネル状態良好化時処理、トンネル接続時処理）である。
【図２５】複数トンネル接続通信（片方向分）の送信処理フロー（トンネル状態応答悪化時処理、トンネル切断時処理）である。
【図２６】複数トンネル接続通信（片方向分）の受信処理フロー（初期化処理）である。
【図２７】複数トンネル接続通信（片方向分）の受信処理フロー（集約受信処理）である。
【図２８】複数トンネル接続通信（片方向分）の受信処理フロー（タイマータイムアウト処理）である。
【図２９】サーバ装置（送信側）からクライアント装置（受信側）への通信処理例（ジッタ小の場合）を示す図である。
【図３０】サーバ装置（送信側）からクライアント装置（受信側）への通信処理例（ジッタ大の場合）を示す図である。
【図３１】サーバ装置（送信側）からクライアント装置（受信側）への従来技術における通信処理例を示す図である。
【発明を実施するための形態】
【００２２】
以下、図面を参照して本発明の実施の形態を説明する。
【００２３】
＜第１の実施の形態＞
（システム構成）
図２に、第１の実施の形態におけるシステムの全体構成を示す。図２に示すように、本実施の形態のシステムは、インターネット５と、企業内ネットワーク等のプライベートネットワーク６との境界に設置されるファイアフォール装置４、ファイアウォール装置４配下にあるトンネルクライアント機能を有するクライアント装置１、トンネルサーバ機能を有するサーバ装置２、及び、クライアント装置１と通信を行う通信相手装置３とを含む。本実施の形態では、サーバ装置２と、通信相手装置３は、インターネット５に接続されている。
【００２４】
図２に示すように、クライアント装置１は、クライアント側のトンネル接続に係る処理を行うトンネル機能部１１と、本発明に係るクライアント側の生存確認処理を行う生存確認機能部１２と、IP電話や映像会議等の目的の通信を行うアプリケーション部１３を備える。サーバ装置２は、サーバ側のトンネル接続に係る処理を行うトンネル機能部２１と、本発明に係るサーバ側の生存確認処理を行う生存確認機能部２２を備える。
【００２５】
本実施の形態におけるクライアント装置１は、OS（オペレーティングシステム）と、上記機能部に対応するプログラム等を備えるコンピュータ（PC、携帯端末等）である。また、本実施の形態におけるサーバ装置２は、OS、上記機能部に対応するプログラム等を備えるコンピュータである。
【００２６】
図３に、クライアント装置１の生存確認機能部１２の機能構成を示す。図３に示すように、生存確認機能部１２は、生存確認用パケット送受信制御部１２１、情報格納部１２２、タイマー１C、タイマー２C、タイマー３C、タイマー４Cを有する。
【００２７】
生存確認用パケット送受信制御部１２１は、生存確認のためにパケットの送受信を制御する機能部であり、タイマーを参照しながら後述するような処理動作を行う。情報格納部１２２は、状態（良好、応答悪化）、生存確認要求応答受領送信済みフラグを格納する。
【００２８】
タイマー１Cは再接続発動タイマーであり、クライアント装置１が最終パケットを送信してから、再接続を実施するまでの時間を計測する。本実施の形態では、タイマー１Cが計測する時間として５秒程度の値を想定している。
【００２９】
タイマー２Cは状態悪化判定タイマーであり、クライアント装置１が最終パケットを送信してから、その応答が返るまでの基準となる時間を計測する。本実施の形態では、タイマー２Cが計測する時間として３秒程度の値を想定している。
【００３０】
タイマー３Cは生存確認要求送信兼応答受領タイマーであり、連続パケット送信時に「生存確認要求」を載せて送信する最低時間間隔を計測すると同時に、「生存確認要求応答受領」の送信までの期限を計測する。本実施の形態では、タイマー３Cが計測する時間として０．５秒程度の値を想定している。
【００３１】
タイマー４Cは生存確認要求最長送信タイマーであり、長時間パケットの送信が無い場合等に単独の「生存確認要求」を送信する期限を計測する。本実施の形態では、タイマー４Cが計測する時間として１０秒程度の値を想定している。
【００３２】
図４に、サーバ装置２の生存確認機能部２２の機能構成を示す。図４に示すように、生存確認機能部２２は、生存確認用パケット送受信制御部２２１、情報格納部２２２、タイマー２S、タイマー５Sを有する。
【００３３】
生存確認用パケット送受信制御部２２１は、生存確認のためにパケットの送受信を制御する機能部であり、タイマーを参照しながら後述するような処理動作を行う。情報格納部２２２は、状態（良好、応答悪化）を格納する。
【００３４】
タイマー２Sは状態悪化判定タイマーであり、サーバ装置２が「生存確認要求応答」を送信してから、「生存確認要求応答受領」をクライアント装置１から受信するまでの期限を計測する。本実施の形態では、タイマー２Sが計測する時間として３秒程度の値を想定している。
【００３５】
タイマー５Sは「生存確認要求応答」タイマーであり、サーバ装置２が「生存確認要求」（単独のものを除く）を受信してから「生存確認要求応答」を送信するまでの期限を計測する。本実施の形態では、タイマー５Sが計測する時間として１秒程度の値を想定している。
【００３６】
なお、「生存確認要求」と「生存確認要求応答受領」はクライアント装置１からサーバ装置２に伝達される信号であり、「生存確認要求応答」は逆にサーバ装置２からクライアント装置１に伝達される信号である。
【００３７】
本実施の形態に係るクライアント装置１及びサーバ装置２のそれぞれは、CPU、記憶装置等を有するコンピュータに上記の各機能を実現するためのプログラムを実行させることにより実現できる。当該プログラムは可搬メモリ等の記録媒体からコンピュータにインストールすることとしてもよいし、ネットワーク上のサーバからダウンロードすることとしてもよい。
【００３８】
また、トンネル接続を実現する方式には種々のものあるが、本発明においてトンネル接続を実現する方式は特定の方式に限定されるわけではなく、本発明は様々なトンネル接続の方式に適用可能である。
【００３９】
（システムの動作）
以下では、第１の実施の形態におけるシステムの動作を説明する。以下の動作は、基本的に、クライアント装置１の生存確認機能部１２と、サーバ装置２の生存確認機能部２２により実行されるものである。
【００４０】
図５は、システムの動作イメージを示す図である。図５に示すように、単独の生存確認用のメッセージ（パケット）、もしくは、本来の通信データ（アプリケーションプログラムにより送受信されるデータ）であるデータパケットに付された形での生存確認用のメッセージがクライアント装置１とサーバ装置２間で送受信される。
【００４１】
図６（ａ）〜（ｅ）は、本実施の形態で用いられるメッセージのフォーマット例を示す図である。なお、ここで示すフォーマットは一例に過ぎず、他の種々のフォーマット、サイズ、メッセージ種別を示す値を使用可能である。
【００４２】
本実施の形態では、ヘッダは１バイトのサイズとなっている。図６（ａ）に示すように、「23h」が上りトンネルに流れた場合、単独の生存確認要求とみなし、下りトンネルに流れた場合、単独の生存確認要求応答とみなす。図６（ｂ）に示すように、ヘッダ「24h」は単独の生存確認要求応答受領とみなす。
【００４３】
図６（ｃ）〜（ｅ）に示すように、データパケットを表すヘッダは「30h」となっており、これに生存確認要求または生存確認要求応答を重畳させた場合のヘッダは「31h」となる。また、生存確認要求応答受領を重畳させた場合のヘッダは「32h」となる。
【００４４】
このように、ヘッダの一部ビットを利用することにより、オーバーヘッド無しに生存確認が可能となる。
【００４５】
次に、図７〜図１５のフローチャートを参照して、クライアント装置１、及びサーバ装置２の動作を説明する。
図７は、クライアント装置１におけるトンネル接続時の処理、及び生存確認要求応答受信時の処理を示すフローチャートである。図７に示すように、クライアント装置１では、トンネル接続開始直後に、状態を「良好」に設定し（ステップ１）、生存確認要求応答受領送信済みフラグを「未送信」にセットする（ステップ２）。続いて、タイマー３C（生存確認要求送信兼応答受領タイマー）、タイマー４C（生存確認要求最長送信タイマー）をスタートさせ、タイマー１C（再接続発動タイマー）、タイマー２C（状態悪化判定タイマー）を停止させる。以降、クライアント装置１における生存確認機能部１２は、パケット到着やタイマー動作（タイムアウト）のイベントを契機に動作する。
【００４６】
図８は、データパケット送信時の処理、及びタイマー４C（生存確認要求最長送信タイマー）のタイムアウト時の処理を示すフローチャートである。
【００４７】
図８に示すように、クライアント装置１がデータパケットを送信する際に、先ずタイマー３C（生存確認要求送信兼応答受領タイマー）がタイムアウトしているか否かを判定する（ステップ１１）。タイマー３Cがタイムアウトしている場合（ステップ１１のＹｅｓ）、生存確認要求を送付すべきと判断し、生存確認要求をデータパケットに重畳して送信し（ステップ１２）、タイマー３Ｃを停止する（ステップ１３）。
【００４８】
一方、ステップ１１の判定がＮｏ、すなわちタイマー３Ｃ（生存確認要求送信兼応答受領タイマー）がタイムアウトしていなかった場合、必要に応じ、生存確認要求応答受領を送信すべきと判断し、生存確認要求応答受領送信済みフラグを検証し（ステップ１４）、未送信の場合（ステップ１４のＮｏ）に限り、生存確認要求応答受領をデータパケットに重畳して送信する（ステップ１５）し、生存確認要求応答受領送信済みフラグを「送信済み」にセットする。ステップ１４の判定がＹｅｓ、すなわち生存確認要求応答受領を送信済みであった場合、何も重畳せず、単独のデータパケットとして送信する（ステップ１７）。
【００４９】
ステップ１３、１６、１７の後、タイマー４Ｃを停止し、タイマー１Ｃ、２Ｃをスタートする（ステップ１９）。
【００５０】
サーバ装置２から生存確認要求応答を受信した場合のクライアント装置１の処理を図７を参照して説明する。図７に示すとおり、サーバ装置２から生存確認要求応答を受信した場合、タイマー２Ｃ（状態悪化判定タイマー）がタイムアウトしているか否かをチェックし（ステップ４）、タイマー２Ｃがタイムアウトしていない場合（ステップ４のＮｏ）に限り、状態を「良好」に設定し（ステップ１）、その後、クライアント装置１における状態をトンネル接続直後と同様に初期化する（ステップ２、３）。タイマー２Ｃがタイムアウトしている場合（ステップ４のＹｅｓ）、状態は「状態悪化」に設定されており、その設定のまま、クライアント装置１におけるフラグ等をトンネル接続直後と同様に初期化する（ステップ２、３）。
【００５１】
タイマー４Ｃ（生存確認要求最長送信タイマー）がタイムアウトした場合の処理を図８を参照して説明する。タイマー４Ｃがタイムアウトした場合、これはデータパケット送信がしばらく無かったことを意味するため、生存確認要求を単独パケットとして送信する（ステップ１８）。その後、タイマー４Cを停止し、タイマー１C（再接続発動タイマー）、タイマー２C（状態悪化判定タイマー）をスタートする（ステップ１９）。
【００５２】
図９はタイマー３C（生存確認要求送信兼応答受領タイマー）がタイムアウトした場合のクライアント装置１における処理を示すフローチャートである。タイマー３C（生存確認要求送信兼応答受領タイマー）がタイムアウトした場合、生存確認要求応答受領の送信タイミングであるから、生存確認要求応答受領送信済みフラグをチェックして送信済みか否かをチェックし（ステップ２１）、送信済みでなければ（ステップ２１のＮｏ）、生存確認要求応答受領を単独パケットとして送信し（ステップ２２）、生存確認要求応答受領送信済みフラグを「送信済み」にセットする（ステップ２３）。
【００５３】
図１０はタイマー２C（状態悪化判定タイマー）がタイムアウトした場合のクライアント装置１における処理を示すフローチャートである。図１０に示すように、タイマー２C（状態悪化判定タイマー）がタイムアウトした場合、状態が悪化したと判断され、状態を「応答悪化」に設定する（ステップ３１）。
【００５４】
図１１はタイマー１C（再接続発動タイマー）がタイムアウトした場合のクライアント装置１における処理を示すフローチャートである。図１１に示すように、タイマー１C（再接続発動タイマー）がタイムアウトした場合、新規に１本トンネル接続を行い（ステップ５１）、トンネル接続時処理を行って（ステップ５２）、旧トンネル接続を切断し（ステップ５３）、新トンネル接続に制御を渡す。
【００５５】
図１２はトンネル接続時等におけるサーバ装置２の処理を示すフローチャートである。図１２に示すように、サーバ装置２では、トンネル接続時に状態を「良好」に設定し（ステップ６１）、以降、以下で説明するようにイベントベースで動作する。
【００５６】
図１３は、生存確認要求付きデータパケットをクライアント装置１から受信した場合におけるサーバ装置２の処理を示すフローチャートである。図１３に示すように、生存確認要求付きデータパケットをクライアント装置１から受信した場合、タイマー５Ｓ（生存確認要求応答タイマー）をスタートする（ステップ７１）。
図１４は、生存確認要求を単独パケットとしてクライアント装置１から受信した場合等におけるサーバ装置２の処理を示すフローチャートである。図１４に示すように、生存確認要求を単独で受信した場合、サーバ装置２は、生存確認要求応答を単独でクライアント装置１に送信し（ステップ８１）、タイマー２Ｓ（状態悪化判定タイマー）を（再）スタートし、タイマー５Ｓを停止する（ステップ８４）。
【００５７】
また、図１４に示すように、クライアント装置１へデータパケットを送信する時には、タイマー５Ｓ（生存確認要求応答送信タイマー）が動作中か否かを判断し（ステップ８２）、動作中（ステップ８２のYｅｓ）であれば、生存確認要求応答付きのデータパケットをクライアント装置１に送信し（ステップ８３）、タイマー２Ｓ（状態悪化判定タイマー）を（再）スタートし、タイマー５Ｓを停止する（ステップ８４）。タイマー５Ｓ（生存確認要求応答送信タイマー）が動作中でない場合（ステップ８２のNｏ）、通常のデータパケット送信を行う（ステップ８５）。
【００５８】
図１２に示すように、生存確認要求応答受領をクライアント装置１から受信した場合、タイマー２Ｓ（状態悪化判定タイマー）がタイムアウトしていない場合（ステップ６２のNｏ）に限り、状態を「良好」に設定する（ステップ６１）。
【００５９】
図１４に示すように、タイマー５Ｓ（生存確認要求応答送信タイマー）がタイムアウトした場合、単独の生存確認要求応答をクライアント装置１に送信し（ステップ８１）、ステップ８４を行う。
【００６０】
また、図１５に示すように、タイマー２Ｓ（状態悪化判定タイマー）がタイムアウトした場合、状態を「応答悪化」に設定する（ステップ９１）。
【００６１】
次に、上述した各装置における処理手順に対応する状態の遷移について説明する。
【００６２】
図１６は、クライアント装置１における生存確認要求処理の状態遷移図である。図１６に示すように、「良好」の状態からタイマー２C（状態悪化判定タイマー）の経過で「応答悪化」になる（ステップ１０１）。タイマー１C（再接続発動タイマー）経過前でのパケット送信を契機にタイマー２Cがスタートし、タイマー２C経過前のパケット到着により「良好」の状態になる（ステップ１０２）。
【００６３】
「応答悪化」の状態からタイマー１C（再接続発動タイマー）が経過すると、「接続不良」（※１）となり、「切断」（※２）となる（ステップ１０３、１０４）。そして、初期接続、もしくは再接続を経て「良好」の状態になる（ステップ１０５）。ただし、本発明の実施の形態では、接続不良と判断された場合（タイマー１Cが経過した場合）、直ちに切断するため「接続不良」状態は実効上存在しない。また、本実施の形態の構成上、「切断」状態を扱う必要がないため、フローチャート上は「切断」状態を示していない。
【００６４】
図１７は、サーバ装置２における生存確認要求処理の状態遷移図である。図１７に示すように、「良好」の状態からタイマー２S（状態悪化判定タイマー）の経過で「応答悪化」になる（ステップ２０１）。タイマー２S再スタート後、タイマー２S経過前のパケット到着により「良好」の状態になる（ステップ２０２）。また、「良好」もしくは「応答悪化」の状態から切断された場合に「切断」となり、その後、接続がなされる（ステップ２０３、２０４、２０５）。なお、前述したとおり、本実施の形態の構成上、「切断」状態を扱う必要がないため、フローチャート上は「切断」状態を示していない。
【００６５】
図１８は、クライアント装置１とサーバ装置２を１セットのシステムとみなし、系全体の状態遷移を表した状態遷移図である。図１８では、概ね、単独または重畳で受信する制御信号を「状態」として、タイマーのタイムアウトやパケット送信を状態遷移の条件という形で表記している。
【００６６】
上記のフローチャートや状態遷移に従った処理動作を行うサーバ装置２とクライアント装置１間における生存確認動作シーケンスの一例を図１９に示す。図１９に示す例は、データパケットの通信がない場合の動作を示している。
【００６７】
図１９の場合、クライアント装置１においてデータパケットの送信がされないので、図７のステップ３でスタートしたタイマー４Ｃ（生存確認要求最長送信タイマー）は、データパケットの送信を契機として停止されることはなく、タイムアウトになり、図８のステップ１８に示すとおり、単独での生存確認要求が送信される（図１９のステップ５０１）。生存確認要求を受信したサーバ装置２において、図１４のステップ８１、８４に示すとおり、単独の生存確認要求応答をクライアント装置１に送信し（図１９のステップ５０２）、タイマー２Ｓ（状態悪化判定タイマー）を（再）スタートする。
【００６８】
生存確認要求応答を受信したクライアント装置１は、図７に示す生存確認要求応答受信時の処理を行い、タイマー３Ｃ、４Ｃをスタートする。図１９の例では、データパケットに付される生存確認要求応答を受信することはないので、タイマー３Ｃはタイムアウトし、図８に示すように、クライアント装置１は単独の生存確認要求応答受領をサーバ装置２に送信する（図１９のステップ５０３）。生存確認要求応答受領を受信したサーバ装置１では、図１２に示すように、タイマー２Ｓのタイムアウト確認を行うが、本例ではタイマー２Ｓはタイムアウトしておらず、状態は「良好」であると判断する。
【００６９】
その後、クライアント装置１においてタイマー４Ｃ（生存確認要求最長送信タイマー）がタイムアウトし、生存確認要求を送信し（ステップ５０４）、サーバ装置２から生存確認要求応答が送信される（ステップ５０５）。
【００７０】
このようにデータパケットの送受信がない場合、タイマー４Ｃにより決定される最長間隔で生存確認が繰り返される。
【００７１】
生存確認動作シーケンスの他の例を図２０に示す。図２０に示す例は、データパケットの送受信がある場合の動作を示している。
【００７２】
本例において、データパケットがないときには、上述した処理と同様にして、生存確認要求、生存確認要求応答、生存確認要求応答受領の送受信がなされる（ステップ６０１〜６０３）。
【００７３】
クライアント装置１において送信するデータパケットがある場合、図８に示すとおり、タイマー３C（生存確認要求送信兼応答受領タイマー）をチェックし、ここではタイムアウトしているので、生存確認要求付きデータパケットを送信する（ステップ６０４）。
【００７４】
一方、サーバ装置２からは順次データパケットが送信されるが、図２０の例において、ステップ６０５に示すデータパケットは、タイマー５S（生存確認要求応答タイマー）が動作中でないため、通常のデータパケットとして送信される（図１４のステップ８５）。
【００７５】
ステップ６０４の生存確認要求付きデータパケットを受信したサーバ装置２において、図１３のステップ７１に示すとおり、タイマー５S（生存確認要求応答タイマー）がスタートし、図１４のステップ８３に示すとおり、データパケット送信を契機として生存確認要求応答付きデータパケットが送信され（図２０のステップ６０６）、タイマー５Sが停止し、タイマー２S（状態悪化判定タイマー）が再スタートされる。
【００７６】
クライアント装置１からも順次データパケットが送信されるが、図２０の例において、ステップ６０７、６１２に示すデータパケットについては、タイマー３Cが停止されている（タイムアウトしていない）とともに、生存確認要求応答受領を送信済みなので、生存確認要求なしのデータパケットとして送信される（図８のステップ１７）。
【００７７】
ステップ６０６の生存確認要求応答付きデータパケットを受信したクライアント装置１は、図７に示すとおり、タイマー３C、４Cをスタートさせるとともに、データパケット送信時に、生存確認要求応答受領付きデータパケットを送信する（図２０のステップ６０８、図８のステップ１５）。
【００７８】
ステップ６０９、６１０で示すデータパケットについては、タイマー５Sが動作中でないので、そのままサーバ装置２からクライアント装置１に送信される。
【００７９】
ステップ６０８の生存確認要求応答受領付きデータパケットを送信した後、クライアント装置１では、データパケット送信時に、生存確認要求付きデータパケットを送信する（図２０のステップ６１１、図８のステップ１２）。
【００８０】
ステップ６１１の生存確認要求付きデータパケットを受信したサーバ装置２において、タイマー５S（生存確認要求応答タイマー）がスタートするが、ここではタイマー５Sがタイムアウトし、単独の生存確認要求応答が送信される（ステップ６１３）。それを受けたクライアント装置１からはタイマー３Cのタイムアウトを契機として単独の生存確認要求応答受領が送信される（ステップ６１４）。
【００８１】
このようにデータパケットの送受信がある場合、タイマー２Ｓ（状態悪化判定タイマー）とクライアント装置１からの上りパケット送信間隔で決まる短い時間間隔での生存確認が繰り返される。これにより状態監視が頻繁になるため、より短期間に状態悪化を検出できる。
【００８２】
本実施の形態において、クライアント装置１とサーバ装置２間のトンネルの本数は特に限定されないが、これまでの説明はトンネルが１本である場合を想定している。
【００８３】
後述する第２の実施の形態にように、複数本のトンネルを使用する場合は、本実施の形態で説明する生存確認処理をトンネル毎に行う。
【００８４】
また、本実施の形態に係る構成は、以下のように表すこともできる。
【００８５】
サーバ装置２との間に構築されたトンネルを介してデータ通信を行うクライアント装置１は、前記サーバ装置２との間で前記トンネルを構築し、当該トンネルを経由してパケットの送受信を行うクライアント側トンネル通信手段１１と、前記トンネルを介して生存確認のためのパケット送受信を行うクライアント側生存確認手段１２と、を備え、前記クライアント側生存確認手段１２は、前記クライアント装置１が備えるアプリケーション部１３からのデータパケット送信がない場合に、第１の時間（タイマー４Ｃ）間隔で生存確認要求を前記サーバ装置２に送信し、当該生存確認要求を受信した前記サーバ装置２から生存確認要求応答を受信した場合に、生存確認要求応答受領を前記サーバ装置２に送信し、前記アプリケーション部１３からのデータパケット送信がある場合において、生存確認要求応答又は生存確認要求応答付きデータパケットを前記サーバ装置２から受信した後の第２の時間（タイマー３Ｃ）経過内に、生存確認要求応答受領付きデータパケットを前記サーバ装置２に送信し、生存確認要求応答又は生存確認要求応答付きデータパケットを前記サーバ装置から受信した後の当該第２の時間経過後に、生存確認要求付きデータパケットを前記サーバ装置２に送信し、前記生存確認要求応答又は前記生存確認要求応答付きデータパケットを前記サーバ装置から受信しないで第３の時間（タイマー２Ｃ）が経過した場合に、前記トンネルの状態が悪化したと判定する。
【００８６】
また、前記サーバ装置２は、前記サーバ装置２との間で前記トンネルを構築し、当該トンネルを経由してパケットの送受信を行うサーバ側トンネル通信手段２１と、前記トンネルを介して生存確認のためのパケット送受信を行うサーバ側生存確認手段２２と、を備え、前記サーバ側生存確認手段２２は、前記サーバ装置２からのデータパケット送信がない場合において、生存確認要求を前記クライアント装置１から受信した場合に、生存確認要求応答を前記クライアント装置１に送信し、前記サーバ装置２からのデータパケット送信がある場合において、生存確認要求付きデータパケットを前記クライアント装置１から受信した場合に、生存確認要求応答付きデータパケットを前記クライアント装置１に送信し、前記生存確認要求応答又は前記生存確認要求応答付きデータパケットを前記クライアント装置１に送信後、第４の時間（タイマー２Ｓ）経過内に生存確認要求応答受領又は生存確認要求応答受領付きデータパケットを前記クライアント装置１から受信しない場合に、前記トンネルの状態が悪化したと判定する。
【００８７】
＜第２の実施の形態＞
次に、本発明の第２の実施の形態について説明する。本実施の形態でのシステム構成は図２〜４で説明した第１の実施の形態と同様である。ただし、本実施の形態では、クライアント装置１のトンネル機能部１１、及びサーバ装置２のトンネル機能部２１のそれぞれが、複数本のトンネル接続を束ねてパケット送受信を行う機能を備えている。また、生存確認機能部１２、２２は、複数本のトンネル接続を用いる構成に対応した機能を含む。
【００８８】
図２１は、パケット送信側とパケット受信側におけるトンネル機能部１１、２１の構成を示す図である。図２１は、本実施の形態の機能を分かりやすく示すために、片方向の通信構成を示すものであるが、実際には、クライアント装置１とサーバ装置２の各々において、図２１に示すパケット送信側の機能とパケット受信側の機能を備える。つまり、図２１は、クライアント装置１からサーバ装置２への上り方向の通信構成、または、サーバ装置２からクライアント装置１への下り方向の通信構成を示している。
【００８９】
図２１に示すように、パケット送信側のトンネル機能部は、分配部１０１、カウンター１０２、トンネル接続リスト格納部１０３を含む。パケット受信側のトンネル機能部は、集約受信部２０１、最終送信番号格納部２０２、タイマー２０３を含む。もちろん、各トンネル機能部は、複数本のトンネル接続を行う機能も含む。
【００９０】
パケット送信側では、トンネル接続リスト格納部１０３に接続中のトンネルのリストであるトンネル接続リストが格納される。図２１の例では、トンネル接続０〜Nが示されている。分配部１０１は、トンネル接続リスト及びカウンターを利用して、送信対象のパケットに対して順次番号を付与し、複数のトンネルに対して順次パケットを送信する。送信に用いるトンネルを複数リストとして順に用いて送信する構成となっている。また、各トンネルの状態が悪化した場合、リストから取り除き、良好に復帰した場合、再度リストに加える。
【００９１】
パケット受信側では、最後に再送信したパケットの番号が、最終送信番号格納部２０２に格納される。集約受信部２０１はパケットを格納するキュー（バッファメモリ）を備え、以下の処理を行う。なお、以下のような制御を行う集約受信部２０１は、再送信順序制御手段の一例である。
【００９２】
集約受信部２０１は、最終送信パケット番号と受信したパケットのパケット番号とを比較し、受信したパケットのパケット番号が最終送信パケット番号＋１以下であれば直ちに送信し、＋２以上であれば、集約受信部２０１におけるキューの中を確認し、既に待ち合わせのパケットがあればキューの中のパケットに引き続き受信したパケットを再送信する。キューにパケットが無ければ、受信したパケットをキューに格納してタイマー２０３を始動する。タイマー２０３がタイムアウトするまで次のパケットがこなかった場合は、キューに格納されたパケットを送信する。
【００９３】
以下では、上記の処理をより詳細にフローチャートを参照して説明する。
【００９４】
図２２は、パケット送信側トンネル機能部における初期化処理を示すフローチャートである。図２２に示すように、カウンター値を０にし（ステップ１１１）、トンネル接続リストを空にし（ステップ１１２）、トンネル接続をN本オープンする（ステップ１１３）。
【００９５】
図２３は、パケット送信側トンネル機能部における分配部１０１が行う分配送信処理を示すフローチャートである。図２３に示すように、パケットにカウンター値を付加し（ステップ１２１）、トンネル接続リストの先頭にあるトンネルにパケットを送信する（ステップ１２２）。そして、カウンター値に１を加算し（ステップ１２３）、トンネル接続リストの先頭の要素をリストの末尾に移動する（ステップ１２４）。
【００９６】
図２４は、パケット送信側トンネル機能部における、トンネル状態「良好」化時、もしくはトンネル接続時の処理を示すフローチャートである。ここで、トンネル状態「良好」化時とは、生存確認部（１２、２２）において、トンネル接続が「応答悪化」の状態から、「良好」の状態になったことが検知された時のことである。
【００９７】
ここでは、トンネル接続の末尾に、接続した（又は良好になった）トンネルを追加する（ステップ１３１）。
【００９８】
図２５は、パケット送信側トンネル機能部における、トンネル状態「応答悪化」時、もしくはトンネル切断時の処理を示すフローチャートである。ここで、トンネル状態「応答悪化」時とは、生存確認部（１２、２２）において、トンネル接続が「良好」の状態から、「応答悪化」の状態になったことが検知された時のことである。
【００９９】
ここでは、トンネル接続リストから該当するトンネルを削除する（ステップ１４１）。
【０１００】
図２６は、パケット受信側トンネル機能部における初期化処理を示すフローチャートである。初期化時において、最終送信番号を−１にする（ステップ１５１）。
【０１０１】
図２７は、パケット受信側トンネル機能部における集約受信部２０１が実行する集約受信処理を示すフローチャートである。
【０１０２】
パケットを受信すると、受信したパケットのパケット番号が最終送信番号＋１以下かどうかをチェックする（ステップ１６１）。最終送信番号＋１以下である場合（ステップ１６１のYes）、受信したパケットを再送信し、最終送信番号を当該パケットの番号とする（ステップ１６２）。
【０１０３】
ステップ１６１において、受信したパケットのパケット番号が最終送信番号＋１以下でない場合（＋２以上の場合）、キューの中に既に待ち合わせ中のパケットが存在するか否かを確認する（ステップ１６３）。待ち合わせ中のパケットが存在する場合（ステップ１６３のYes）、キューの中のパケットを全て送信し、タイマーを停止し、最終送信番号を更新する（ステップ１６４）。その後、受信したパケットを再送信し、最終送信番号を当該パケットの番号とする（ステップ１６２）。ステップ１６３において待ち合わせ中のパケットが存在しない場合、パケットをキューに投入し（ステップ１６５）、タイマーをスタートする（ステップ１６６）。
【０１０４】
図２８は、パケット受信側トンネル機能部におけるタイマータイムアウト処理を示すフローチャートである。図２８に示すとおり、タイマーがタイムアウトになると、キューの中のパケットを、パケットを受信した順番で全て送信し、タイマーを停止し、最終送信番号を更新する（ステップ１７１）。
【０１０５】
本実施の形態では、送信に用いるトンネル接続について、接続状態であると同時に、トンネル状態が「良好」であることも条件としている。つまり、状態が悪化したと判定されたトンネル接続を使用しないこととしている。これにより、パケット再送等により一時的に応答の悪化したトンネル接続を回避して良好な応答を保つことができる。
【０１０６】
上記のように動作するトンネル機能部を備えるサーバ装置２（送信側）からクライアント装置１（受信側）への通信処理例を図２９、図３０を参照して説明する。
【０１０７】
図２９は、サーバ装置２からクライアント装置１への伝送路におけるジッターが小さい場合の処理例を示す。図２９に示すように、パケット＃０〜＃１５がサーバ装置２から各トンネル接続経由で順番に送信される。本例では、パケット＃４がパケット＃５よりも少し遅れてクライアント装置１に到達する。この場合、受信側の処理を示す図２７に示すように、クライアント装置１では、パケット＃３の次に受信するパケット＃５をキューに格納し、タイマータイムアウト前にパケット＃４を受信することにより、パケット＃４をアプリケーションプログラム（アプリケーション部１３）に送信し、次に、キューの中のパケット＃５をアプリケーションプログラムに送信する。パケット＃８、＃９についても同様である。
【０１０８】
このように、ジッターが小さい場合、順序が入れ替わって到着したパケットも順序通り並べ替えて送信することができる。
【０１０９】
図３０は、サーバ装置２からクライアント装置１への伝送路におけるジッターが大きい場合の処理例を示す。
【０１１０】
本例では、パケット＃６が大きく遅れてクライアント装置１に到達する。この場合、クライアント装置１において、パケット＃５の次に受信したパケット＃７はキューに格納されるが、続くパケットを受信する前にタイマーがタイムアウトになり、キューの中のパケット＃７が送信される。従って、パケット＃７については少し遅延する。
【０１１１】
パケット＃６はパケット＃９の次に受信され、パケット＃１１がその次に受信される。この場合、パケット＃９の次に受信したパケット＃６についての図２７のステップ１６１の判定はYesになるので、パケット＃６はすぐにアプリケーションプログラムに送信される。次に受信するパケット＃１１については、キューに格納される（ステップ１６１のNo、ステップ１６３、１６５）。タイマータイムアウト前にパケット＃１０を受信することにより、パケット＃１０をアプリケーションプログラムに送信し、次に、キューの中のパケット＃１１をアプリケーションプログラムに送信する。
【０１１２】
ジッターが大きい場合、大きい遅延を受けたパケットについての順序入れ替わりは防止できないものの他のパケットまでが大きく遅延することなく処理される。
【０１１３】
ここで、従来技術による複数トンネリング通信での受信処理の一例（ジッター小の場合）を図３１に示す。図３１に示すように、ジッターが小であっても、従来技術では順序逆転が発生してしまうが、本実施の形態に係る技術では順序逆転を防止できる。これにより、リアルタイムコミュニケーション系などパケットの順序性が問題になるアプリケーションでも、順序逆転を防止することにより、品質低下を抑制できる。
【０１１４】
＜実施の形態の効果＞
第１、第２の実施の形態で説明した技術によれば、データパケットが送受信されているときに、データパケットに重畳して生存確認用の信号を送受信する構成をとるので、処理負担軽減と異常状態検出時間の短縮という相反する条件を満たした生存確認を行うことができるとともに、サーバ装置側でも通信状態の安定性判定をすることでより短い時間で状態判定が行うことができ、クライアント装置１からサーバ装置２への上り方向の状態判定と同様にサーバ装置２からクライアント装置１への下り方向の状態判定も可能となる。そのため、トンネルのコネクションが切断されてしまった等の異常事態をいち早く検出し、他の正常なトンネル接続に振り分けることでトンネル経由の通信への影響時間を短縮することができる。
【０１１５】
また、一定時間内のパケット順序入れ替り補正により、ほとんどのパケット順序を保ったままで、かつ遅延時間を小さく伝送できるため、VoIPや映像コミュニケーションなどリアルタイム通信でかつパケット順序が通信品質に影響を与える通信プロトコルに対しても安定的に利用可能となる。
【０１１６】
本発明は、上記の実施の形態に限定されることなく、特許請求の範囲内において、種々変更・応用が可能である。
【符号の説明】
【０１１７】
１ クライアント装置
１１ トンネル機能部
１２ 生存確認機能部
１３ アプリケーション部
２ サーバ装置
２１ トンネル機能部
２２ 生存確認機能部
３ 通信相手装置
４ ファイアウォール装置
５ インターネット
６ プライベートネットワーク
１２１ 生存確認用パケット送受信制御部
１C、２C、３C、４C タイマー
１２２ 情報格納部
２２１ 生存確認用パケット送受信制御部
２S、５S タイマー
２２２ 情報格納部
１０１ 分配部
１０２ カウンター
１０３ トンネル接続リスト格納部
２０１ 集約受信部
２０２ 最終送信番号格納部
２０３ タイマー
【特許請求の範囲】
【請求項１】
サーバ装置との間に構築されたトンネルを介してデータ通信を行うクライアント装置であって、
前記サーバ装置との間で前記トンネルを構築し、当該トンネルを経由してパケットの送受信を行うクライアント側トンネル通信手段と、
前記トンネルを介して生存確認のためのパケット送受信を行うクライアント側生存確認手段と、を備え、
前記クライアント側生存確認手段は、
前記クライアント装置が備えるアプリケーション部からのデータパケット送信がない場合に、第１の時間間隔で生存確認要求を前記サーバ装置に送信し、当該生存確認要求を受信した前記サーバ装置から生存確認要求応答を受信した場合に、生存確認要求応答受領を前記サーバ装置に送信し、
前記アプリケーション部からのデータパケット送信がある場合において、生存確認要求応答又は生存確認要求応答付きデータパケットを前記サーバ装置から受信した後の第２の時間経過内に、生存確認要求応答受領付きデータパケットを前記サーバ装置に送信し、生存確認要求応答又は生存確認要求応答付きデータパケットを前記サーバ装置から受信した後の当該第２の時間経過後に、生存確認要求付きデータパケットを前記サーバ装置に送信し、
生存確認要求応答又は生存確認要求応答付きデータパケットを前記サーバ装置から受信しないで第３の時間が経過した場合に、前記トンネルの状態が悪化したと判定する
ことを特徴とするクライアント装置。
【請求項２】
前記第１の時間は前記第３の時間より長く、当該第３の時間は前記第２の時間より長いことを特徴とする請求項１に記載のクライアント装置。
【請求項３】
請求項１又は２に記載のクライアント装置と、前記サーバ装置とを備える通信システムであって、
前記サーバ装置は、
前記サーバ装置との間で前記トンネルを構築し、当該トンネルを経由してパケットの送受信を行うサーバ側トンネル通信手段と、
前記トンネルを介して生存確認のためのパケット送受信を行うサーバ側生存確認手段と、を備え、
前記サーバ側生存確認手段は、
前記サーバ装置からのデータパケット送信がない場合において、生存確認要求を前記クライアント装置から受信した場合に、生存確認要求応答を前記クライアント装置に送信し、前記サーバ装置からのデータパケット送信がある場合において、生存確認要求付きデータパケットを前記クライアント装置から受信した場合に、生存確認要求応答付きデータパケットを前記クライアント装置に送信し、
生存確認要求応答又は生存確認要求応答付きデータパケットを前記クライアント装置に送信後、第４の時間経過内に生存確認要求応答受領又は生存確認要求応答受領付きデータパケットを前記クライアント装置から受信しない場合に、前記トンネルの状態が悪化したと判定する
ことを特徴とする通信システム。
【請求項４】
請求項３に記載の通信システムにおいて、
前記サーバ側トンネル通信手段は、
前記クライアント側トンネル通信手段との間に構築された複数のトンネルに対して順次、送信順を示す送信番号を付したパケットを送信する分配送信手段を備え、
前記クライアント側トンネル通信手段は、
最後に再送信を行った第１のパケットの送信番号と、前記サーバ側トンネル通信手段から受信した第２のパケットの送信番号とを比較し、当該第２のパケットの送信番号が前記第１のパケットの送信番号＋１以下である場合に、当該第２のパケットを再送信し、当該第２のパケットの送信番号が前記第１のパケットの送信番号＋２以上である場合において、キューの中にパケットが既に存在しない場合に、当該第２のパケットをキューに格納し、所定の時間経過後に、当該第２のパケットを再送信する再送信順序制御手段を備える
ことを特徴とする通信システム。
【請求項５】
請求項４に記載の通信システムにおいて、
前記サーバ側トンネル通信手段は、前記サーバ側生存確認手段により状態が悪化したと判定されたトンネルを使用しない
ことを特徴とする通信システム。
【請求項６】
請求項３ないし５のうちいずれか１項に記載の通信システムにおいて、
前記クライアント側トンネル通信手段は、
前記サーバ側トンネル通信手段との間に構築された複数のトンネルに対して順次、送信順を示す送信番号を付したパケットを送信する分配送信手段を備え、
前記サーバ側トンネル通信手段は、
最後に再送信を行った第１のパケットの送信番号と、前記クライアント側トンネル通信手段から受信した第２のパケットの送信番号とを比較し、当該第２のパケットの送信番号が前記第１のパケットの送信番号＋１以下である場合に、当該第２のパケットを再送信し、当該第２のパケットの送信番号が前記第１のパケットの送信番号＋２以上である場合において、キューの中にパケットが既に存在しない場合に、当該第２のパケットをキューに格納し、所定の時間経過後に、当該第２のパケットを再送信する再送信順序制御手段を備える
ことを特徴とする通信システム。
【請求項７】
請求項６に記載の通信システムにおいて、
前記クライアント側トンネル通信手段は、前記クライアント側生存確認手段により状態が悪化したと判定されたトンネルを使用しない
ことを特徴とする通信システム。
【請求項８】
サーバ装置との間に構築されたトンネルを介してデータ通信を行うクライアント装置と、前記サーバ装置とを備える通信システムにより実行される生存確認方法であって、
前記クライアント装置は、
前記クライアント装置が備えるアプリケーション部からのデータパケット送信がない場合に、第１の時間間隔で生存確認要求を前記サーバ装置に送信し、当該生存確認要求を受信した前記サーバ装置から生存確認要求応答を受信した場合に、生存確認要求応答受領を前記サーバ装置に送信し、
前記アプリケーション部からのデータパケット送信がある場合において、生存確認要求応答又は生存確認要求応答付きデータパケットを前記サーバ装置から受信した後の第２の時間経過内に、生存確認要求応答受領付きデータパケットを前記サーバ装置に送信し、生存確認要求応答又は生存確認要求応答付きデータパケットを前記サーバ装置から受信した後の当該第２の時間経過後に、生存確認要求付きデータパケットを前記サーバ装置に送信し、
生存確認要求応答又は生存確認要求応答付きデータパケットを前記サーバ装置から受信しないで第３の時間が経過した場合に、前記トンネルの状態が悪化したと判定し、
前記サーバ装置は、
前記サーバ装置からのデータパケット送信がない場合において、生存確認要求を前記クライアント装置から受信した場合に、生存確認要求応答を前記クライアント装置に送信し、前記サーバ装置からのデータパケット送信がある場合において、生存確認要求付きデータパケットを前記クライアント装置から受信した場合に、生存確認要求応答付きデータパケットを前記クライアント装置に送信し、
生存確認要求応答又は生存確認要求応答付きデータパケットを前記クライアント装置に送信後、第４の時間経過内に生存確認要求応答受領又は生存確認要求応答受領付きデータパケットを前記クライアント装置から受信しない場合に、前記トンネルの状態が悪化したと判定する
ことを特徴とする生存確認方法。
【請求項９】
コンピュータを、サーバ装置との間に構築されたトンネルを介してデータ通信を行うクライアント装置として機能させるためのプログラムであって、コンピュータを、
前記サーバ装置との間で前記トンネルを構築し、当該トンネルを経由してパケットの送受信を行うクライアント側トンネル通信手段、
前記トンネルを介して生存確認のためのパケット送受信を行うクライアント側生存確認手段、として機能させ、
前記クライアント側生存確認手段は、
前記クライアント装置が備えるアプリケーション部からのデータパケット送信がない場合に、第１の時間間隔で生存確認要求を前記サーバ装置に送信し、当該生存確認要求を受信した前記サーバ装置から生存確認要求応答を受信した場合に、生存確認要求応答受領を前記サーバ装置に送信し、
前記アプリケーション部からのデータパケット送信がある場合において、生存確認要求応答又は生存確認要求応答付きデータパケットを前記サーバ装置から受信した後の第２の時間経過内に、生存確認要求応答受領付きデータパケットを前記サーバ装置に送信し、生存確認要求応答又は生存確認要求応答付きデータパケットを前記サーバ装置から受信した後の当該第２の時間経過後に、生存確認要求付きデータパケットを前記サーバ装置に送信し、
生存確認要求応答又は生存確認要求応答付きデータパケットを前記サーバ装置から受信しないで第３の時間が経過した場合に、前記トンネルの状態が悪化したと判定する
ことを特徴とするプログラム。
【請求項１】
サーバ装置との間に構築されたトンネルを介してデータ通信を行うクライアント装置であって、
前記サーバ装置との間で前記トンネルを構築し、当該トンネルを経由してパケットの送受信を行うクライアント側トンネル通信手段と、
前記トンネルを介して生存確認のためのパケット送受信を行うクライアント側生存確認手段と、を備え、
前記クライアント側生存確認手段は、
前記クライアント装置が備えるアプリケーション部からのデータパケット送信がない場合に、第１の時間間隔で生存確認要求を前記サーバ装置に送信し、当該生存確認要求を受信した前記サーバ装置から生存確認要求応答を受信した場合に、生存確認要求応答受領を前記サーバ装置に送信し、
前記アプリケーション部からのデータパケット送信がある場合において、生存確認要求応答又は生存確認要求応答付きデータパケットを前記サーバ装置から受信した後の第２の時間経過内に、生存確認要求応答受領付きデータパケットを前記サーバ装置に送信し、生存確認要求応答又は生存確認要求応答付きデータパケットを前記サーバ装置から受信した後の当該第２の時間経過後に、生存確認要求付きデータパケットを前記サーバ装置に送信し、
生存確認要求応答又は生存確認要求応答付きデータパケットを前記サーバ装置から受信しないで第３の時間が経過した場合に、前記トンネルの状態が悪化したと判定する
ことを特徴とするクライアント装置。
【請求項２】
前記第１の時間は前記第３の時間より長く、当該第３の時間は前記第２の時間より長いことを特徴とする請求項１に記載のクライアント装置。
【請求項３】
請求項１又は２に記載のクライアント装置と、前記サーバ装置とを備える通信システムであって、
前記サーバ装置は、
前記サーバ装置との間で前記トンネルを構築し、当該トンネルを経由してパケットの送受信を行うサーバ側トンネル通信手段と、
前記トンネルを介して生存確認のためのパケット送受信を行うサーバ側生存確認手段と、を備え、
前記サーバ側生存確認手段は、
前記サーバ装置からのデータパケット送信がない場合において、生存確認要求を前記クライアント装置から受信した場合に、生存確認要求応答を前記クライアント装置に送信し、前記サーバ装置からのデータパケット送信がある場合において、生存確認要求付きデータパケットを前記クライアント装置から受信した場合に、生存確認要求応答付きデータパケットを前記クライアント装置に送信し、
生存確認要求応答又は生存確認要求応答付きデータパケットを前記クライアント装置に送信後、第４の時間経過内に生存確認要求応答受領又は生存確認要求応答受領付きデータパケットを前記クライアント装置から受信しない場合に、前記トンネルの状態が悪化したと判定する
ことを特徴とする通信システム。
【請求項４】
請求項３に記載の通信システムにおいて、
前記サーバ側トンネル通信手段は、
前記クライアント側トンネル通信手段との間に構築された複数のトンネルに対して順次、送信順を示す送信番号を付したパケットを送信する分配送信手段を備え、
前記クライアント側トンネル通信手段は、
最後に再送信を行った第１のパケットの送信番号と、前記サーバ側トンネル通信手段から受信した第２のパケットの送信番号とを比較し、当該第２のパケットの送信番号が前記第１のパケットの送信番号＋１以下である場合に、当該第２のパケットを再送信し、当該第２のパケットの送信番号が前記第１のパケットの送信番号＋２以上である場合において、キューの中にパケットが既に存在しない場合に、当該第２のパケットをキューに格納し、所定の時間経過後に、当該第２のパケットを再送信する再送信順序制御手段を備える
ことを特徴とする通信システム。
【請求項５】
請求項４に記載の通信システムにおいて、
前記サーバ側トンネル通信手段は、前記サーバ側生存確認手段により状態が悪化したと判定されたトンネルを使用しない
ことを特徴とする通信システム。
【請求項６】
請求項３ないし５のうちいずれか１項に記載の通信システムにおいて、
前記クライアント側トンネル通信手段は、
前記サーバ側トンネル通信手段との間に構築された複数のトンネルに対して順次、送信順を示す送信番号を付したパケットを送信する分配送信手段を備え、
前記サーバ側トンネル通信手段は、
最後に再送信を行った第１のパケットの送信番号と、前記クライアント側トンネル通信手段から受信した第２のパケットの送信番号とを比較し、当該第２のパケットの送信番号が前記第１のパケットの送信番号＋１以下である場合に、当該第２のパケットを再送信し、当該第２のパケットの送信番号が前記第１のパケットの送信番号＋２以上である場合において、キューの中にパケットが既に存在しない場合に、当該第２のパケットをキューに格納し、所定の時間経過後に、当該第２のパケットを再送信する再送信順序制御手段を備える
ことを特徴とする通信システム。
【請求項７】
請求項６に記載の通信システムにおいて、
前記クライアント側トンネル通信手段は、前記クライアント側生存確認手段により状態が悪化したと判定されたトンネルを使用しない
ことを特徴とする通信システム。
【請求項８】
サーバ装置との間に構築されたトンネルを介してデータ通信を行うクライアント装置と、前記サーバ装置とを備える通信システムにより実行される生存確認方法であって、
前記クライアント装置は、
前記クライアント装置が備えるアプリケーション部からのデータパケット送信がない場合に、第１の時間間隔で生存確認要求を前記サーバ装置に送信し、当該生存確認要求を受信した前記サーバ装置から生存確認要求応答を受信した場合に、生存確認要求応答受領を前記サーバ装置に送信し、
前記アプリケーション部からのデータパケット送信がある場合において、生存確認要求応答又は生存確認要求応答付きデータパケットを前記サーバ装置から受信した後の第２の時間経過内に、生存確認要求応答受領付きデータパケットを前記サーバ装置に送信し、生存確認要求応答又は生存確認要求応答付きデータパケットを前記サーバ装置から受信した後の当該第２の時間経過後に、生存確認要求付きデータパケットを前記サーバ装置に送信し、
生存確認要求応答又は生存確認要求応答付きデータパケットを前記サーバ装置から受信しないで第３の時間が経過した場合に、前記トンネルの状態が悪化したと判定し、
前記サーバ装置は、
前記サーバ装置からのデータパケット送信がない場合において、生存確認要求を前記クライアント装置から受信した場合に、生存確認要求応答を前記クライアント装置に送信し、前記サーバ装置からのデータパケット送信がある場合において、生存確認要求付きデータパケットを前記クライアント装置から受信した場合に、生存確認要求応答付きデータパケットを前記クライアント装置に送信し、
生存確認要求応答又は生存確認要求応答付きデータパケットを前記クライアント装置に送信後、第４の時間経過内に生存確認要求応答受領又は生存確認要求応答受領付きデータパケットを前記クライアント装置から受信しない場合に、前記トンネルの状態が悪化したと判定する
ことを特徴とする生存確認方法。
【請求項９】
コンピュータを、サーバ装置との間に構築されたトンネルを介してデータ通信を行うクライアント装置として機能させるためのプログラムであって、コンピュータを、
前記サーバ装置との間で前記トンネルを構築し、当該トンネルを経由してパケットの送受信を行うクライアント側トンネル通信手段、
前記トンネルを介して生存確認のためのパケット送受信を行うクライアント側生存確認手段、として機能させ、
前記クライアント側生存確認手段は、
前記クライアント装置が備えるアプリケーション部からのデータパケット送信がない場合に、第１の時間間隔で生存確認要求を前記サーバ装置に送信し、当該生存確認要求を受信した前記サーバ装置から生存確認要求応答を受信した場合に、生存確認要求応答受領を前記サーバ装置に送信し、
前記アプリケーション部からのデータパケット送信がある場合において、生存確認要求応答又は生存確認要求応答付きデータパケットを前記サーバ装置から受信した後の第２の時間経過内に、生存確認要求応答受領付きデータパケットを前記サーバ装置に送信し、生存確認要求応答又は生存確認要求応答付きデータパケットを前記サーバ装置から受信した後の当該第２の時間経過後に、生存確認要求付きデータパケットを前記サーバ装置に送信し、
生存確認要求応答又は生存確認要求応答付きデータパケットを前記サーバ装置から受信しないで第３の時間が経過した場合に、前記トンネルの状態が悪化したと判定する
ことを特徴とするプログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８】
【図２９】
【図３０】
【図３１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８】
【図２９】
【図３０】
【図３１】
【公開番号】特開２０１２−２１６９６４（Ｐ２０１２−２１６９６４Ａ）
【公開日】平成２４年１１月８日（２０１２．１１．８）
【国際特許分類】
【出願番号】特願２０１１−８０１７８（Ｐ２０１１−８０１７８）
【出願日】平成２３年３月３１日（２０１１．３．３１）
【出願人】（３９９０３５７６６）エヌ・ティ・ティ・コミュニケーションズ株式会社 (321)
【Ｆターム（参考）】
【公開日】平成２４年１１月８日（２０１２．１１．８）
【国際特許分類】
【出願日】平成２３年３月３１日（２０１１．３．３１）
【出願人】（３９９０３５７６６）エヌ・ティ・ティ・コミュニケーションズ株式会社 (321)
【Ｆターム（参考）】
[ Back to top ]