WO2015177924A1 - 通信装置及び通信方法及びプログラム - Google Patents

Abstract

　クライアント装置（１０３）の通信部（１１１）は、サーバ装置（１０１）との接続を確立する。通信制御部（１１２）は、サーバ装置（１０１）へのリクエストパケットとは別に、通信部（１１１）により確立されたサーバ装置（１０１）との接続を維持するための維持パケットを送信する。

Description

通信装置及び通信方法及びプログラム

　本発明は、パケットを通信する技術に関する。

　通常、クライアントサーバシステムでは、複数のクライアント装置が１つのサーバ装置に接続し、クライアント装置はリクエストを送信し、サーバ装置はリクエストに対するレスポンスを返信する。
　しかし近年、リアルタイムチャットアプリケーションやＭ２Ｍ（Ｍａｃｈｉｎｅ　Ｔｏ　Ｍａｃｈｉｎｅ）など、クライアント装置からサーバ装置だけでなくサーバ装置からクライアント装置へリクエストを送信するシステムが求められている。
　そのため、クライアント装置からサーバ装置へリクエストを送信した後、サーバ装置からクライアント装置へのレスポンスをサーバ装置にて一定時間保留しておき、保留しておいたレスポンスにリクエストを載せることによりサーバ装置からクライアント装置へリクエストを送信する方法が用いられてきた（例えば、特許文献１、特許文献２）。

特開２００６－１３４１０８号公報 特開２００９－６５３４９号公報

　特許文献１及び特許文献２では、サーバ装置からクライアント装置へのレスポンスを一定時間保留する方法と、保留時間を調整する方法に関する記載がある。
　しかし、レスポンスを長時間保留すると、サーバ装置とクライアント装置との間の機器によりサーバ装置とクライアント装置との間の接続を強制切断される（タイムアウトする）可能性がある。
　サーバ装置とクライアント装置との間の機器とは、例えばＮＡＴ（Ｎｅｔｗｏｒｋ　Ａｄｄｒｅｓｓ　Ｔｒａｎｓｌａｔｉｏｎ）ルータである。
　ＮＡＴルータは、通信を中継するために必要な情報をメモリ上に保持しているが、一般的に一定時間サーバ装置とクライアント装置との間に通信がない場合に、ＮＡＴルータはこの情報を消去する。
　このため、サーバ装置とクライアント装置との間で以後同じ接続を使用した通信が行えなくなる。
　従って、サーバ装置からクライアント装置へのリクエストの有無に関わらず前記一定時間が経過する前にサーバ装置はクライアント装置にレスポンスを返信し、再度クライアント装置からのリクエストを受信し、クライアント装置へのレスポンスを保留するという処理によりタイムアウトを防止する必要があった。

　このように、特許文献１及び特許文献２の技術では、サーバ装置とクライアント装置との間の接続を維持するためにサーバ装置は周期的にクライアント装置へレスポンスを行う必要があり、サーバ装置に負荷がかかるという課題がある。

　本発明は、この課題を解決することを主な目的としており、通信先装置（例えば、サーバ装置）に負荷をかけずに、通信装置（例えば、クライアント装置）と通信先装置との間の接続を維持することを主な目的とする。

　本発明に係る通信装置は、
　通信先装置との接続を確立する通信部と、
　前記通信先装置へのリクエストパケットとは別に、前記通信部により確立された前記通信先装置との接続を維持するための維持パケットを送信する維持パケット送信部とを有することを特徴とする。

　本発明によれば、通信装置が、リクエストパケットとは別に、通信先装置との接続を維持するための維持パケットを送信するため、通信先装置は、接続を維持するための処理を行う必要がなく、通信先装置に負荷をかけることなく、通信装置と通信先装置との接続を維持することができる。

実施の形態１及び実施の形態２における全体システム構成例を示す図。 実施の形態１における通信制御部の構成例を示す図。 実施の形態１における接続管理部の処理例を示すフローチャート図。 実施の形態１における維持パケット送信部の処理例を示すフローチャート図。 実施の形態１における維持パケットに含まれる情報の例を示す図。 実施の形態２における通信制御部の構成例を示す図。 実施の形態２における維持パケット送信部の処理例を示すフローチャート図。 実施の形態２における維持パケットＴＴＬ調整部の処理例を示すフローチャート図。 実施の形態１及び実施の形態２におけるクライアント装置のハードウェア構成例を示す図。

　実施の形態１．
　本実施の形態では、サーバ装置に負荷をかけることなくサーバ装置とクライアント装置との間の接続を長時間維持することを可能にする方式を説明する。

　また、特許文献１及び特許文献２の技術では、クライアント装置へのレスポンスの返信からクライアント装置からのリクエストの受信までの時間は、サーバ装置はクライアント装置へリクエストを送信することができないという課題がある。
　本実施の形態では、このような課題を解決し、サーバ装置からクライアント装置にリクエストを送信できない時間をなくす方式を説明する。

　図１は、実施の形態１における全体システムの構成例を示す図である。

　サーバ装置１０１は、クライアント装置１０３からのリクエストパケットを受信し、リクエストパケットに対するレスポンスパケットをクライアント装置１０３に送信する。
　本実施の形態に係るサーバ装置１０１は、どのようなサーバ装置でもよく、本実施の形態のために既存のサーバ装置に処理の追加、変更、削除を行う必要はない。
　サーバ装置１０１には、例えば、Ａｐａｃｈｅ　ＨＴＴＰ（Ｈｙｐｅｒｔｅｘｔ　Ｔｒａｎｓｆｅｒ　Ｐｒｏｔｏｃｏｌ）サーバ装置などのＨＴＴＰサーバ装置が挙げられるが、ＨＴＴＰサーバ装置以外でもよい。
　なお、サーバ装置１０１は、通信先装置の例に相当する。

　ＮＡＴルータ１０２は、ＩＰ（Ｉｎｔｅｒｎｅｔ　Ｐｒｏｔｏｃｏｌ）アドレスの変換を行うルータである。
　一般的にＮＡＴルータは、家庭内や企業内で利用するプライベートＩＰアドレスとインターネットで利用するグローバルＩＰアドレスとを変換することで、複数台のクライアントが１つのグローバルＩＰアドレスでインターネットに接続できるようにする。
　サーバ装置１０１とクライアント装置１０３との間で接続が確立されると、ＩＰアドレスの変換関係が示される変換関係情報がＮＡＴルータ１０２のメモリ上に保存される。
　しかしながら、サーバ装置１０１とクライアント装置１０３の間で一定時間通信がないと、変換関係情報が消去され、以後は同じ接続を使用した通信が行えなくなる。
　一般的に、１台のサーバ装置１０１に対し複数台のＮＡＴルータ１０２が存在する。
　なお、ＮＡＴルータ１０２は、中継装置の例に相当する。

　クライアント装置１０３は、サーバ装置１０１にリクエストパケットを送信し、サーバ装置１０１からレスポンスパケットを受信する。
　また、クライアント装置１０３は、リクエストパケットとは別に、サーバ装置１０１との接続を維持するための維持パケットを送信する。
　一般的に、１台のＮＡＴルータ１０２に対し複数台のクライアント装置１０３が接続する。
　なお、クライアント装置１０３は、通信装置の例に相当する。

　次に、クライアント装置１０３の内部構成例を説明する。

　通信部１１１は、サーバ装置１０１との間の接続を確立し、また、サーバ装置１０１との間の接続を切断する。
　通信部１１１は、図１に示すように、ＮＡＴルータ１０２を介して、サーバ装置１０１との間に接続を確立する。
　通信部１１１は、複数のＮＡＴルータ１０２を介して、サーバ装置１０１との接続を確立してもよい。
　また、通信部１１１は、サーバ装置１０１との接続が確立している間、サーバ装置１０１へリクエストパケットを送信し、サーバ装置１０１からレスポンスパケットを受信する。
　例えば、サーバ装置１０１がＨＴＴＰサーバ装置の場合、通信部１１１はＨＴＴＰリクエストパケットを送信し、サーバ装置１０１からＨＴＴＰレスポンスパケットを受信する。

　通信制御部１１２は、通信部１１１から接続開始イベント又は接続終了イベントを受け取り、サーバ装置１０１とクライアント装置１０３との間の接続を維持するために維持パケットを送信する。
　接続開始イベントは、通信部１１１がサーバ装置１０１との間の接続を確立したことを通知するイベントである。
　接続終了イベントは、通信部１１１がサーバ装置１０１との間の接続を切断したことを通知するイベントである。
　接続開始イベント及び接続終了イベントには、送信元ＩＰアドレス、送信元ポート番号、送信先ＩＰアドレス、送信先ポート番号が含まれる。

　図２は、図１に示した通信制御部１１２の構成例を示す。

　接続管理部１２１は、通信部１１１から接続開始イベントを受け取り、維持パケット送信部１２２の起動を行う。
　また、接続管理部１２１は、通信部１１１から接続終了イベントを受け取り、維持パケット送信部１２２の停止を行う。
　また、接続管理部１２１は、維持パケット送信部１２２の起動の際に、維持パケット送信部１２２の起動に用いる接続情報を、接続情報保管部１２３に追加する。
　更に、維持パケット送信部１２２の停止の際に、接続情報保管部１２３から接続情報を削除する。

　維持パケット送信部１２２は、維持パケットを送信する。
　維持パケットは、図５に示す情報を含む。
　図５に示す各項目は、後述する。

　接続情報保管部１２３は、接続情報を保持する。
　接続情報には、送信元ＩＰアドレス、送信元ポート番号、送信先ＩＰアドレス、送信先ポート番号と維持パケット送信スレッドＩＤが記述される。
　維持パケット送信スレッドＩＤとは、維持パケット送信部１２２が動作するスレッドの識別子である。

　図３は、実施の形態１における接続管理部１２１の処理例を示すフローチャートである。

　処理３０１では、接続管理部１２１が、通信部１１１から接続開始イベント又は接続終了イベントを受け取る。
　接続開始イベント及び接続終了イベントのそれぞれには、送信元ＩＰアドレス、送信元ポート番号、送信先ＩＰアドレス、送信先ポート番号が含まれる。
　処理３０２では、接続管理部１２１は、通信部１１１から受け取ったイベントの種別を判断する。
　受け取ったイベントが接続開始イベントである場合は、接続管理部１２１は、処理３０３に進む。
　受け取ったイベントが接続終了イベントである場合は、接続管理部１２１は、処理３０５に進む。

　処理３０３では、接続管理部１２１が維持パケット送信部１２２を別スレッドで起動する。
　このとき、接続管理部１２１は、維持パケット送信部１２２に、接続開始イベントに含まれる情報を渡す。
　また、接続管理部１２１は、維持パケット送信部１２２を起動したスレッドのスレッドＩＤである維持パケット送信スレッドＩＤを取得しておく。

　処理３０４では、接続管理部１２１が接続情報保管部１２３に接続情報を保管する。
　接続情報保管部１２３に保管する接続情報には、送信元ＩＰアドレス、送信元ポート番号、送信先ＩＰアドレス、送信先ポート番号、維持パケット送信スレッドＩＤが含まれる。
　処理３０４の終了後は、処理３０１に戻る。

　処理３０５では、接続管理部１２１は、接続情報保管部１２３から、接続情報に含まれる維持パケット送信スレッドＩＤを取得する。
　また、接続管理部１２１が接続情報保管部１２３から、維持パケット送信スレッドＩＤを含む接続情報を削除する。

　処理３０６では、接続管理部１２１が維持パケット送信部１２２にスレッド停止命令を送信する。
　これにより、維持パケット送信部１２２は動作を停止する。
　なお、停止対象のスレッドは、処理３０５で取得した維持パケット送信スレッドＩＤに対応するスレッドである。
　処理３０６の終了後は、処理３０１に戻る。

　図４は、実施の形態１における維持パケット送信部１２２の処理例を示すフローチャートである。

　処理３１１では、維持パケット送信部１２２が接続管理部１２１から接続開始イベントに含まれる情報を受け取り、別スレッドとして処理を開始する。

　処理３１２では、維持パケット送信部１２２は一定時間待機する。
　待機時間は、クライアント装置１０３ごとに定める固定値であり、設定ファイルからの読出しやユーザからの入力により設定される。

　処理３１３では、維持パケット送信部１２２は、接続管理部１２１からスレッド停止命令を受信したかどうかを判断する。
　スレッド停止命令を受信した場合は、維持パケット送信部１２２は、処理を終了する。
　スレッド停止命令を受信していない場合は、維持パケット送信部１２２は、処理３１４へ進む。

　処理３１４では、維持パケット送信部１２２がＴＴＬ（Ｔｉｍｅ　Ｔｏ　Ｌｉｖｅ）値を指定し、サーバ装置１０１を宛先とする維持パケットを生成し、維持パケットを送信する。
　ここでＴＴＬ値は、クライアント装置１０３ごとに定める固定値であり、設定ファイルからの読出しやユーザからの入力により設定される。
　このとき、ＴＴＬ値は維持パケットがサーバ装置１０１へ到達するために不十分な値（例えば１～１０程度）とする。
　つまり、維持パケット送信部１２２は、維持パケットがサーバ装置１０１に到達せずに、いずれかのＮＡＴルータ１０２において維持パケットが破棄されることになるＴＴＬ値を維持パケットに設定する。
　なお、維持パケット送信部１２２は、処理３１４の時点ですでに維持パケットが生成されている場合は、新たに維持パケットを生成する必要はなく、生成済みの維持パケットを送信する。
　処理３１４の終了後は、処理３１２に戻る。

　図５は、実施の形態１に係る維持パケットに含まれる情報を示す。

　維持パケットは、ＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ　Ｃｏｎｔｒｏｌ　Ｐｒｏｔｏｃｏｌ）パケットまたはＵＤＰ（Ｕｓｅｒ　Ｄａｔａｇｒａｍ　Ｐｒｏｔｏｃｏｌ）パケットまたはこれらに準ずるパケットであり、図５に示す情報を含んでいる。
　ＴＴＬ値４０１は、ＩＰｖ４パケットのヘッダに含まれるパケットの生存時間を表す値であり、０－２５５の範囲で指定する。
　ＴＴＬ値は、パケットがルータにより転送されるごとに１ずつ減少する。
　ＴＴＬ値が０になったパケットは破棄される。
　ＩＰｖ６パケットのヘッダには、同様の意味及び機能を持つＨｏｐ　Ｌｉｍｉｔがある。
　通信部１１１では、確実にリクエストパケットをサーバ装置１０１へ到達させるため、ＴＴＬ値を１２８など十分大きな値に設定する。
　一方、維持パケット送信部１２２は、維持パケットがサーバ装置１０１へ到達しないようにするため、ＴＴＬ値を維持パケットをサーバ装置１０１に到達させるためには不十分な値に設定する。
　送信元ＩＰアドレス４０２は、クライアント装置１０３のＩＰアドレスである。
　送信元ＩＰアドレス４０２は、通信部１１１が送信するリクエストパケット、維持パケット送信部１２２が送信する維持パケットともに同じ値である。
　送信先ＩＰアドレス４０３は、通信先のサーバ装置１０１のＩＰアドレスである。
　送信先ＩＰアドレス４０３は、通信部１１１が送信するリクエストパケット、維持パケット送信部１２２が送信する維持パケットともに同じ値である。
　送信元ポート番号４０４は、クライアント装置１０３がパケット送信に使用するポート番号である。
　送信元ポート番号４０４は、通信部１１１が送信するリクエストパケット、維持パケット送信部１２２が送信する維持パケットともに同じ値である。
　送信先ポート番号４０５は、サーバ装置１０１がパケット受信に使用するポート番号である。
　送信先ポート番号４０５は、通信部１１１が送信するリクエストパケット、維持パケット送信部１２２が送信する維持パケットともに同じ値である。

　図５の内容をもつ維持パケットは、クライアント装置１０３から、クライアント装置１０３に直結しているＮＡＴルータ１０２に送信され、以降、ＮＡＴルータ１０２間をサーバ装置１０１に向けて転送されるが、サーバ装置１０１に到達する前にＴＴＬ値が０になり、いずれかのＮＡＴルータ１０２で破棄される。
　各ＮＡＴルータ１０２では、定期的に維持パケットを受信するため、サーバ装置１０１とクライアント装置１０３との間のパケットを中継するための変換関係情報は消去されず、このため、サーバ装置１０１とクライアント装置１０３との間の接続は維持される。
　このように、本実施の形態では、サーバ装置１０１は、接続を維持する目的で定期的にレスポンスパケットをクライアント装置１０３に送信する必要がない。
　このため、本実施の形態によれば、サーバ装置１０１からクライアント装置１０３へのリクエストが無い場合には、サーバ装置１０１は、レスポンスパケットの送信を保留することができ、サーバ装置１０１の負荷が軽減されるという効果が得られる。
　また、サーバ装置１０１は、接続を維持する目的で定期的にレスポンスパケットをクライアント装置１０３に送信する必要がないので、クライアント装置１０３へのリクエストが発生した際にレスポンスパケットを送信することができる。
　このため、本実施の形態によれば、サーバ装置１０１からクライアント装置１０３へリクエストを送信することができない時間が０になるという効果が得られる。
　また、本実施の形態では、維持パケットのＴＴＬ値を調整することで、維持パケットをサーバ装置１０１まで到達させないようにしているため、サーバ装置１０１が維持パケットを処理することがなく、サーバ装置１０１に負荷をかけないという効果が得られる。

　実施の形態２．
　実施の形態２について、図１、図５、図６～図８を用いて説明する。
　本実施の形態でも、システム構成は図１に示す通りである。
　また、維持パケットに含まれる情報も、図５に示す通りである。
　以下では、実施の形態１との違いを説明する。

　図６は、実施の形態２における通信制御部１１２の構成例を示す。

　図６では、図２に示す構成と比べて、維持パケットＴＴＬ調整部１２４が追加されている。
　維持パケットＴＴＬ調整部１２４は、図８に示す処理を実行し、維持パケットに設定するＴＴＬ値を特定する。
　維持パケットＴＴＬ調整部１２４は、ＴＴＬ値特定部の例に相当する。
　また、本実施の形態では、維持パケット送信部１２２は、接続管理部１２１から接続情報を受け取り、維持パケットＴＴＬ調整部１２４からＴＴＬ値を受け取り、図５に示す情報を含む維持パケットをサーバ装置１０１に対し送信する。
　接続管理部１２１、接続情報保管部１２３は、実施の形態１で説明したものと同様であり、説明を省略する。

　図７は、実施の形態２における維持パケット送信部１２２の処理例を示すフローチャートである。

　処理３２１では、維持パケット送信部１２２が接続管理部１２１から接続開始イベントを受け取り、別スレッドとして動作を開始する。

　処理３２２では、維持パケット送信部１２２が維持パケットＴＴＬ調整部１２４からＴＴＬ値を取得する。

　処理３２３では、維持パケット送信部１２２は一定時間待機する。
　待機時間は、クライアント装置１０３ごとに定める固定値であり、設定ファイルからの読出しやユーザからの入力により設定される。

　処理３２４では、維持パケット送信部１２２は、接続管理部１２１からスレッド停止命令を受信したかどうかを判断する。
　スレッド停止命令を受信した場合は、維持パケット送信部１２２は、処理を終了する。
　スレッド停止命令を受信していない場合は、維持パケット送信部１２２は、処理３２５へ進む。

　処理３２５では、維持パケット送信部１２２がＴＴＬ値を指定し、サーバ装置１０１を宛先とする維持パケットを生成し、維持パケットを送信する。
　ここでＴＴＬ値は、処理３２２で取得したＴＴＬ値である。
　なお、維持パケット送信部１２２は、処理３２５の時点ですでに維持パケットが生成されている場合は、新たに維持パケットを生成する必要はなく、生成済みの維持パケットを送信する。
　処理３２５の終了後は、処理３２３に戻る。

　図８は、実施の形態２における維持パケットＴＴＬ調整部１２４の処理例を示すフローチャートである。

　処理７０１では、維持パケットＴＴＬ調整部１２４は、維持パケットＴＴＬ調整部１２４に含まれるＴＴＬ値取得機能によりクライアント装置１０３からサーバ装置１０１までのＴＴＬ値の取得を試行する。
　ＴＴＬ値取得機能としては、例えばＬｉｎｕｘ（登録商標）のｔｒａｃｅｒｏｕｔｅコマンドやＷｉｎｄｏｗｓ（登録商標）のｔｒａｃｅｒｔコマンドやその他同等の機能が考えられる。
　ｔｒａｃｅｒｏｕｔｅコマンドでは、プロトコルにＵＤＰやＩＣＭＰ（Ｉｎｔｅｒｎｅｔ　Ｃｏｎｔｒｏｌ　Ｍｅｓｓａｇｅ　Ｐｒｏｔｏｃｏｌ）を用いるため、通信部１１１が用いるプロトコルと異なる場合がある。
　そのため、ｔｒａｃｅｒｏｕｔｅコマンドが失敗しＴＴＬ値を取得できない場合がある。

　処理７０２では、維持パケットＴＴＬ調整部１２４は、処理７０１によりＴＴＬ値を取得できたかどうかを判断する。
　ＴＴＬ値を取得できた場合は、維持パケットＴＴＬ調整部１２４は、処理７０７へ進む。
　ＴＴＬ値を取得できなかった場合は、維持パケットＴＴＬ調整部１２４は、処理７０３へ進む。

　処理７０３から処理７０６は、処理７０１においてＴＴＬ値取得機能がＴＴＬ値を取得できなかった場合にＴＴＬ値を取得するための処理である。
　処理７０３では、維持パケットＴＴＬ調整部１２４は、処理７０４で送信する維持パケットの初期ＴＴＬ値として１を設定する。
　処理７０４では、維持パケットＴＴＬ調整部１２４は、処理７０３または処理７０６で設定されたＴＴＬ値を指定した維持パケットをサーバ装置１０１に向けて送信する。
　ここで送信する維持パケットには、通信部１１１が使用するプロトコルと同じプロトコルを使用する。
　判断７０５では、維持パケットＴＴＬ調整部１２４は、サーバ装置１０１から維持パケットに対するレスポンスパケットを受信したかどうかを判断する。
　レスポンスパケットを受信した場合は、維持パケットＴＴＬ調整部１２４は、処理７０７へ進む。
　レスポンスパケットを受信しなかった場合は、維持パケットＴＴＬ調整部１２４は、処理７０６へ進む。
　処理７０６では、維持パケットＴＴＬ調整部１２４は、処理７０４で送信するパケットのＴＴＬ値を１増加させる。

　処理７０７では、処理７０２または、処理７０３から処理７０６で取得したＴＴＬ値を１減少させる。
　これは、ＴＴＬ値を、サーバ装置１０１までの経路上のＮＡＴルータ１０２には維持パケットが到達するがサーバ装置１０１へは到達しない値とするためである。
　つまり、維持パケットＴＴＬ調整部１２４は、処理７０１から処理７０７を行うことで、サーバ装置１０１の直前のＮＡＴルータ１０２までは維持パケットを到達させることができるＴＴＬ値を特定する。

　このように、ＴＴＬ値を維持パケットがサーバ装置１０１へ到達しない値とすることで、サーバ装置１０１に負荷をかけることなく、サーバ装置１０１とクライアント装置１０３との間の接続がタイムアウトすることを防止する。

　以上、本発明の実施の形態について説明したが、これらの実施の形態を組み合わせて実施しても構わない。
　あるいは、これらの実施の形態のうち、１つを部分的に実施しても構わない。
　あるいは、これらの実施の形態を部分的に組み合わせて実施しても構わない。
　なお、本発明は、これらの実施の形態に限定されるものではなく、必要に応じて種々の変更が可能である。

　最後に、実施の形態１及び実施の形態２に示したクライアント装置１０３のハードウェア構成例を図９を参照して説明する。
　クライアント装置１０３はコンピュータであり、クライアント装置１０３の各要素をプログラムで実現することができる。
　クライアント装置１０３のハードウェア構成としては、バスに、演算装置９０１、外部記憶装置９０２、主記憶装置９０３、通信装置９０４、入出力装置９０５が接続されている。

　演算装置９０１は、プログラムを実行するＣＰＵ（Ｃｅｎｔｒａｌ　Ｐｒｏｃｅｓｓｉｎｇ　Ｕｎｉｔ）である。
　外部記憶装置９０２は、例えばＲＯＭ（Ｒｅａｄ　Ｏｎｌｙ　Ｍｅｍｏｒｙ）やフラッシュメモリ、ハードディスク装置である。
　主記憶装置９０３は、ＲＡＭ（Ｒａｎｄｏｍ　Ａｃｃｅｓｓ　Ｍｅｍｏｒｙ）である。
　通信装置９０４は、通信部１１１の物理層に対応する。
　入出力装置９０５は、例えばマウス、キーボード、ディスプレイ装置等である。

　プログラムは、通常は外部記憶装置９０２に記憶されており、主記憶装置９０３にロードされた状態で、順次演算装置９０１に読み込まれ、実行される。
　プログラムは、図１、図２及び図６に示す「～部」として説明している機能を実現するプログラムである。
　更に、外部記憶装置９０２にはオペレーティングシステム（ＯＳ）も記憶されており、ＯＳの少なくとも一部が主記憶装置９０３にロードされ、演算装置９０１はＯＳを実行しながら、図１、図２及び図６に示す「～部」の機能を実現するプログラムを実行する。
　また、実施の形態１及び実施の形態２の説明において、「～の判断」、「～の判定」、「～の特定」、「～の設定」、「～の指定」、「～の選択」、「～の生成」、「～の受信」等として説明している処理の結果を示す情報やデータや信号値や変数値が主記憶装置９０３にファイルとして記憶されている。

　なお、図９の構成は、あくまでもクライアント装置１０３のハードウェア構成の一例を示すものであり、クライアント装置１０３のハードウェア構成は図９に記載の構成に限らず、他の構成であってもよい。
　また、実施の形態１及び実施の形態２に示したサーバ装置１０１も、図９のハードウェア構成をしていてもよいし、他のハードウェア構成であってもよい。

　また、実施の形態１及び実施の形態２に示す手順により、本発明に係る通信方法を実現可能である。

　１０１　サーバ装置、１０２　ＮＡＴルータ、１０３　クライアント装置、１１１　通信部、１１２　通信制御部、１２１　接続管理部、１２２　維持パケット送信部、１２３　接続情報保管部、１２４　維持パケットＴＴＬ調整部。
 

Claims (9)

1. 　通信先装置との接続を確立する通信部と、
   　前記通信先装置へのリクエストパケットとは別に、前記通信部により確立された前記通信先装置との接続を維持するための維持パケットを送信する維持パケット送信部とを有することを特徴とする通信装置。
2. 　前記通信部は、
   　１つ以上の中継装置を介して前記通信先装置との接続を確立し、
   　前記維持パケット送信部は、
   　前記通信先装置を宛先とするが、いずれかの中継装置で破棄される維持パケットを送信することを特徴とする請求項１に記載の通信装置。
3. 　前記維持パケット送信部は、
   　前記通信先装置の直前の中継装置で破棄される維持パケットを送信することを特徴とする請求項２に記載の通信装置。
4. 　前記維持パケット送信部は、
   　前記通信先装置の直前の中継装置までのＴＴＬ（Ｔｉｍｅ　Ｔｏ　Ｌｉｖｅ）値が設定された維持パケットを送信することを特徴とする請求項３に記載の通信装置。
5. 　前記通信装置は、更に、
   　前記通信先装置の直前の中継装置までのＴＴＬ値を特定するＴＴＬ値特定部とを有し、
   　前記維持パケット送信部は、
   　前記ＴＴＬ値特定部により特定されたＴＴＬ値が設定された維持パケットを送信することを特徴とする請求項４に記載の通信装置。
6. 　前記維持パケット送信部は、
   　一定の時間間隔ごとに、維持パケットを送信することを特徴とする請求項１に記載の通信装置。
7. 　前記通信部は、
   　１つ以上のＮＡＴ（Ｎｅｔｗｏｒｋ　Ａｄｄｒｅｓｓ　Ｔｒａｎｓｌａｔｉｏｎ）ルータを介して前記通信先装置との接続を確立し、
   　前記維持パケット送信部は、
   　前記通信先装置を宛先とするが、いずれかのＮＡＴルータで破棄される維持パケットを送信することを特徴とする請求項１に記載の通信装置。
8. 　コンピュータが、通信先装置との接続を確立し、
   　前記コンピュータが、前記通信先装置へのリクエストパケットとは別に、前記通信先装置との接続を維持するための維持パケットを送信することを特徴とする通信方法。
9. 　通信先装置との接続を確立する通信処理と、
   　前記通信先装置へのリクエストパケットとは別に、前記通信処理により確立された前記通信先装置との接続を維持するための維持パケットを送信する維持パケット送信処理とをコンピュータに実行させることを特徴とするプログラム。
    

Images