JP2009231975A - 情報処理装置、情報処理方法、クライアント機器、情報処理システム - Google Patents

Abstract

【課題】サーバ−クライアント機器間のプロキシサーバを介したリモートアクセスによる接続を、プロキシサーバの設定によらず維持すること。
【解決手段】本発明に係る情報処理装置は、接続をイニシエートするクライアント機器から送信されるデータが一時保存されるアプリケーションデータ受信バッファと、クライアント機器から送信されたデータをアプリケーションデータ受信バッファから取得して上位アプリケーションに伝送するアプリケーションデータ受信部と、クライアント機器から送信されたデータをアプリケーションデータ受信バッファへと転送するとともに、アプリケーションデータ受信バッファの空き容量を監視して当該アプリケーションデータ受信バッファが受信可能なデータ容量をクライアント機器に通知するフローコントロール受信管理部と、を備える。
【選択図】図１

Description

本発明は、情報処理装置、情報処理方法、クライアント機器、情報処理システムに関する。

サーバとクライアント機器とを、例えばインターネット越しにリモートアクセスによって接続させる方法が複数考えられている。そのうち、クライアント側のＬＡＮの入り口にファイアウォール（Ｆｉｒｅｗａｌｌ）やプロキシサーバ等を設置して、ＬＡＮ内に設置されたコンピュータのセキュリティを担保することが行われる環境で用いられる方法の例として、ＨＴＴＰトンネリングという方法を挙げることができる。この際、一定期間データの通信が行われなかった場合であってもサーバ−クライアント機器間の接続（以下、コネクションとも称する。）を確立したままにしておくために、ハートビートと呼ばれる制御信号を送信側の装置から受信側の装置へと送信することが行われる（例えば、特許文献１参照。）。

特開２００６−２０３０１号公報

ところで、データ受信側のサーバでは、送信されたデータを、所定のバッファ（例えば、ＴＣＰの受信バッファ）に一時保存することが行われる。この受信バッファの容量に空きがなくなると、データ送信側のクライアント機器はハートビートを含むデータの送信を行うことができなくなってしまう。

このような状況下で、プロキシサーバに「一定期間データ通信が行われなかった場合には、接続を解消する」という制御条件が設定されている場合、サーバ・クライアント機器間のリモートアクセスによる接続が、プロキシサーバによって解消されてしまうという問題が生じうる。

そこで、本発明は、このような問題に鑑みてなされたもので、その目的は、サーバ−クライアント機器間のプロキシサーバを介したリモートアクセスによる接続を、プロキシサーバの設定によらず維持することが可能な、新規かつ改良された情報処理装置、情報処理方法、クライアント機器、情報処理システムを提供することにある。

上記課題を解決するために、本発明のある観点によれば、接続をイニシエートするクライアント機器との間に接続を確立する接続待ち受け部と、前記クライアント機器から送信されるデータを受信するデータ受信部と、を備え、前記データ受信部は、前記クライアント機器から送信されるデータが一時保存されるアプリケーションデータ受信バッファと、前記クライアント機器から送信された前記データを前記アプリケーションデータ受信バッファから取得して、上位アプリケーションに伝送するアプリケーションデータ受信部と、前記アプリケーションデータ受信バッファの空き容量を監視して当該アプリケーションデータ受信バッファが受信可能なデータ容量を前記クライアント機器に通知するとともに、前記クライアント機器から送信されたデータを前記アプリケーションデータ受信バッファへと転送するフローコントロール受信管理部と、を有する、情報処理装置が提供される。

かかる構成によれば、フローコントロール受信管理部は、アプリケーションデータ受信バッファの空き容量を監視して当該アプリケーションデータ受信バッファが受信可能なデータ容量をクライアント機器に通知するとともに、クライアント機器から送信されたデータをアプリケーションデータ受信バッファへと転送し、アプリケーションデータ受信部は、クライアント機器から送信されたデータをアプリケーションデータ受信バッファから取得して、上位アプリケーションに伝送する。

前記フローコントロール受信管理部は、前記クライアント機器との接続が確立した際に、前記アプリケーションデータ受信バッファが受信可能なデータ容量を前記クライアント機器へと通知するようにしてもよい。

前記フローコントロール受信管理部は、前記空き容量が増加した際に、当該空き容量の増加量を前記クライアント機器へと通知するようにしてもよい。

前記情報処理装置は、前記クライアント機器との通信を制御する通信部と、前記通信部が前記クライアント機器から受信したデータが一時保存される通信部受信バッファと、を更に備え、前記フローコントロール受信管理部は、前記通信部受信バッファに一時保存されている前記データを、前記アプリケーションデータ受信バッファへと転送するようにしてもよい。

前記情報処理装置は、前記クライアント機器から送信される接続維持用制御情報を受信する接続維持用制御情報受信部を更に備え、前記接続維持用制御情報受信部は、前記接続維持用制御情報を受信すると、受信した当該接続維持用制御情報を破棄するようにしてもよい。

前記情報処理装置は、前記クライアント機器に対してデータを送信するデータ送信部を更に備え、前記データ送信部は、前記クライアント機器に対して送信されるデータが一時保存されるアプリケーションデータ送信バッファと、前記クライアント機器に対して送信されるデータを上位アプリケーションから取得して、前記アプリケーションデータ送信バッファに伝送するアプリケーションデータ送信部と、前記アプリケーションデータ送信バッファから前記データを取得し、前記クライアント機器から通知される当該クライアント機器が受信可能なデータ容量に基づいて、取得した前記データを前記クライアント機器に送信するフローコントロール送信管理部と、を有してもよい。

前記情報処理装置は、前記クライアント機器との通信を制御する通信部と、前記通信部が前記クライアント機器へ送信するデータが一時保存される通信部送信バッファと、を更に有し、前記フローコントロール送信管理部は、前記アプリケーションデータ送信バッファに一時保存されているデータを、前記通信部送信バッファへと転送するようにしてもよい。

上記課題を解決するために、本発明の別の観点によれば、接続をイニシエートするクライアント機器との間に接続を確立するステップと、前記クライアント機器から送信されるデータが一時保存されるアプリケーションデータ受信バッファの空き容量に基づいて、前記クライアント機器に前記アプリケーションデータ受信バッファが受信可能なデータ容量を通知するステップと、前記クライアント機器から送信された前記データを前記アプリケーションデータ受信バッファに一時保存するステップと、前記アプリケーションデータ受信バッファに一時保存された前記データを、上位アプリケーションに伝送するステップと、を含む、情報処理方法が提供される。

また、上記情報処理方法は、前記クライアント機器に対して送信されるデータを上位アプリケーションから取得して、前記クライアント機器に対して送信されるデータが一時保存されるアプリケーションデータ送信バッファに取得した前記データを伝送するステップと、前記アプリケーションデータ送信バッファから前記データを取得し、前記クライアント機器から通知される当該クライアント機器が受信可能なデータ容量に基づいて、取得した前記データを前記クライアント機器に送信するステップと、を更に含んでもよい。

上記課題を解決するために、本発明の更に別の観点によれば、情報処理装置との間の接続をイニシエートして、当該情報処理装置との間に接続を確立する接続確立部と、前期情報処理装置に対してデータを送信するデータ送信部と、を備え、前記データ送信部は、前記情報処理装置に対して送信されるデータが一時保存されるアプリケーションデータ送信バッファと、前記情報処理装置に対して送信されるデータを上位アプリケーションから取得して、前記アプリケーションデータ送信バッファに伝送するアプリケーションデータ送信部と、前記アプリケーションデータ送信バッファから前記データを取得し、前記情報処理装置から通知される当該情報処理装置が受信可能なデータ容量に基づいて、取得した前記データを前記情報処理装置に送信するフローコントロール送信管理部と、を有する、クライアント機器が提供される。

前記クライアント機器は、前記情報処理装置から送信されるデータを受信するデータ受信部を更に備え、前記データ受信部は、前記情報処理装置から送信されるデータが一時保存されるアプリケーションデータ受信バッファと、前記情報処理装置から送信された前記データを前記アプリケーションデータ受信バッファから取得して、上位アプリケーションに伝送するアプリケーションデータ受信部と、前記アプリケーションデータ受信バッファの空き容量を監視して当該アプリケーションデータ受信バッファが受信可能なデータ容量を前記情報処理装置に通知するとともに、前記情報処理装置から送信されたデータを前記アプリケーションデータ受信バッファへと転送するフローコントロール受信管理部と、を有してもよい。

上記課題を解決するために、本発明の更に別の観点によれば、情報処理装置との間の接続をイニシエートして、当該情報処理装置との間に接続を確立するステップと、前記情報処理装置に対して送信されるデータを上位アプリケーションから取得して、前記情報処理装置に対して送信されるデータが一時保存されるアプリケーションデータ送信バッファに取得した前記データを伝送するステップと、前記アプリケーションデータ送信バッファから前記データを取得し、前記情報処理装置から通知される当該情報処理装置が受信可能なデータ容量に基づいて、取得した前記データを前記情報処理装置に送信するステップと、を含む、情報処理方法が提供される。

上記課題を解決するために、本発明の更に別の観点によれば、上記情報処理装置と上記クライアント機器と、を含む情報処理システムが提供される。

前記クライアント機器が有する前記データ送信部は、前記情報処理装置と確立された接続を維持する接続維持用制御情報を送信する接続維持用制御情報送信部を更に備え、前記接続維持用制御情報送信部は、前記情報処理装置との間で所定時間通信を行っていない場合に、前記接続維持用制御情報を前記情報処理装置に対して送信するようにしてもよい。

本発明によれば、サーバ−クライアント機器間のプロキシサーバを介したリモートアクセスによる接続を、プロキシサーバの設定によらず維持することが可能である。

以下に添付図面を参照しながら、本発明の好適な実施の形態について詳細に説明する。なお、本明細書及び図面において、実質的に同一の機能構成を有する構成要素については、同一の符号を付することにより重複説明を省略する。

＜リモートアクセスによる接続について＞
まず、本発明の第１の実施形態に係る情報処理システムについて説明するに先立ち、リモートアクセスによる接続について、詳細に説明する。本願発明者らは、上述の課題を解決するに当たって、まず、リモートアクセスによる接続について、詳細な検討を行った。以下に、図９Ａ〜図１１を参照しながら、その検討結果について説明する。図９Ａ〜図９Ｄは、リモートアクセスによる接続を説明するための説明図である。図１０Ａおよび図１０Ｂは、ＴＣＰにおけるフローコントロールを説明するための説明図である。図１１は、プロキシサーバを介したリモートアクセスによる接続の問題点を説明するための説明図である。

インターネット越しにサーバ−クライアント機器間でリモートアクセスによる接続を確立する方法について考える。この際に、例えば図９Ａに示したように、クライアント機器９０３側の環境（すなわち、クライアント機器９０３が属しているＬＡＮ）にプロキシサーバ９０５が設置されている場合、プロキシサーバ９０５の設定にもよるが、ＨＴＴＰ（ＨｙｐｅｒＴｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）やＳＳＬ（Ｓｅｃｕｒｅ Ｓｏｃｋｅｔ Ｌａｙｅｒ）等の限られたプロトコル以外のトラフィックは、遮断されることがある。

このようなファイアウォール（ＨＴＴＰプロキシサーバ９０５）を介してリモートアクセスを成功させるための方法として、図９Ｂに示したように、ＳＳＬトンネリング方式と呼ばれる方式と、ＨＴＴＰトンネリング方式と呼ばれる方式の２種類がある。

ＳＳＬトンネリング方式は、プロキシサーバ９０５を介してＳＳＬによる接続を行って、暗号化された通信路を用いてサーバ９０１−クライアント機器９０３間で任意の通信を行うものである。しかしながら、ＨＴＴＰプロキシ（プロキシサーバ９０５）の設定によっては、ＳＳＬの目的をＨＴＴＰＳ（ＨＴＴＰのためのＳＳＬ）に制限するため、ＨＴＴＰＳのＷｅｌｌ Ｋｎｏｗｎ Ｐｏｒｔとして定義されている４４３番のポート以外のアクセスを許可しないものがある。この場合、リモートアクセスのサーバ９０１側の環境は、ポートを４４３に設定しなければならない。また、サーバ側でＮＡＴ（Ｎｅｔｗｏｒｋ Ａｄｄｒｅｓｓ Ｔｒａｎｓｌａｔｉｏｎ）を使用している場合には、ポートフォワーディング設定によってＮＡＴの外側ポートへの接続を内側の機器へフォワードするが、この場合ＮＡＴの外側ポートを４４３にしなければならない。ここで、一つのポートに対するポートフォワーディングはＮＡＴ内の１台にしかできないため、ＮＡＴ内に２台以上のサーバが存在する場合には、対応することができない。

もう一つの方法であるＨＴＴＰトンネリング方式について説明する。ＨＴＴＰプロキシであるプロキシサーバ９０５は、ＨＴＴＰを用いた通信は中継する。そこで、ＨＴＴＰトンネリング方式では、ＨＴＴＰの通信のｂｏｄｙを通信路とみなして、サーバ９０１−クライアント機器９０３間でデータの通信を行う。このＨＴＴＰトンネリング方式では、送信用にＨＴＴＰ ＰＯＳＴのトランザクションにおいて、ｒｅｑｕｅｓｔのｂｏｄｙを終端させることなく使用して、任意のデータを任意のタイミングで送信することができる。同様に、ＨＴＴＰ ＧＥＴのトランザクションにおいても、ｒｅｓｐｏｎｓｅのｂｏｄｙを終端させることなく使用して、任意のデータを任意のタイミングで受信することができる。この方法では、ＨＴＴＰ ＰＯＳＴのトランザクションとＨＴＴＰ ＧＥＴのトランザクションとを並行して行い、接続対象装置と自機との間に双方向の通信路を確保することができる。

ここで、ＨＴＴＰプロキシ（プロキシサーバ９０５）の実装に際して、例えば図９Ｃに示したように、ＨＴＴＰ ＰＯＳＴのｒｅｑｕｅｓｔ ｂｏｄｙに一定期間データが通信されない場合、その接続を切断するように設定される場合がある。このようなプロキシサーバに対応するために、一定期間データが流れない状態を回避することを目的として、以下に説明するようなことが行われる。

すなわち、ＨＴＴＰトンネリングをコネクションとして利用するアプリケーションのレイヤ（階層）と、実際にＨＴＴＰトンネリングを行うレイヤとの間に、ハートビート（Ｈｅａｒｔ Ｂｅａｔ）と呼ばれる制御信号の送受信を行うハートビート送受信部を配置する。送信側アプリケーションが一定期間データを流さない場合、ハートビート送信部がハートビートデータＨＢを受信側へと送信する。受信側の機器のハートビート受信部は、受信したハートビートデータＨＢを破棄する。

このような処理を行うことで、プロキシサーバ９０５に、一定期間データが通信されていない状況の検出（インアクティブ検出）をさせないようにすることができ、サーバ９０１とクライアント機器９０３との間に確立されたリモートアクセスによる接続を維持することができる。

＜ＴＣＰのフローコントロールについて＞
続いて、図１０Ａおよび図１０Ｂを参照しながら、ＴＣＰのフローコントロールについて、詳細に説明する。

図１０Ａに示したように、ＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）では、送信されるデータにシーケンスナンバーが振られている。送信側の装置であるＴＣＰノード（クライアント機器）９０３では、ＴＣＰの送信バッファに格納されているデータをいくつかのパケットＰに分けた後にシーケンスナンバーを振り分けて、受信側の装置であるＴＣＰノード（サーバ）９０１へと送信する。ＴＣＰノード（サーバ）９０１は、受信したパケットＰをＴＣＰの受信バッファに一時格納し、格納されているデータは、任意のタイミングでアプリケーションの受信バッファに転送される。ＴＣＰノード９０１は、どのシーケンスナンバーのデータまでを受け取ったかをＴＣＰノード９０３に伝えることで、データ落ち対策を行っている。

また、受信側の装置であるＴＣＰノード９０１は、次にどこまでのシーケンスナンバーまでのデータを受け取ることが可能かを示したデータＲを送信側の装置であるＴＣＰノード９０３に通知している。例えば図１０Ａに示した例では、ＴＣＰノード９０１からＴＣＰノード９０３へ、「４まで受け取った、１２まで送れ」というデータＲが通知されている。このデータＲを受け取ったＴＣＰノード９０３は、シーケンスナンバー１２が付与されたパケットＰまでのデータを、ＴＣＰノード９０１へと送信する。

受信側のＴＣＰノードが受け取ることのできるデータの大きさを、ウィンドウサイズ（Ｗｉｎｄｏｗ Ｓｉｚｅ）と呼び、ＴＣＰでは、このウィンドウサイズを調節することで、ＴＣＰのフローコントロール（Ｆｌｏｗ Ｃｏｎｔｒｏｌ）が実現されている。すなわち、通信中は徐々にウィンドウサイズを大きくすることで通信のスループットが上がり、通信路の帯域が足りずにデータエラーが起こった場合にはウィンドウサイズを小さくする。

ここで、受信側のアプリケーションが受信側のＴＣＰ受信バッファからデータを読み取るのが遅れたり、読み取らなかったりした場合には、例えば図１０Ｂに示したように、ＴＣＰ受信バッファの空き容量がゼロになる。図に示したようにＴＣＰの受信準備ができない状態では、受信側は、「ウィンドウサイズは０であるというデータ」（以下、ゼロウィンドウアップデート（Ｚｅｒｏ Ｗｉｎｄｏｗ Ｕｐｄａｔｅ）とも称する。）Ｒを送信する。このゼロウィンドウアップデートは、受信側の装置から送信側の装置に定期的に送られる。

ところで、ハートビートデータＨＢは、アプリケーションデータと同様に、ＴＣＰ上のデータである。そのため、図１０Ｂに示したように、受信側のＴＣＰバッファが一杯になりゼロウィンドウアップデートが定期的に通信される状態では、送信側のクライアント機器９０３はハートビートデータＨＢを送信することができない。そのため、例えば図１１に示したように、一定期間のインアクティビティを検出した経路上のＨＴＴＰプロキシサーバ９０５は、サーバ９０１−クライアント機器９０３間で確立されたリモートアクセスによる通信路を遮断してしまう可能性がある。

かかる問題を解決するために、本願発明者らが鋭意研究を行った結果、以下で説明するような情報処理システムに想到した。

（第１の実施形態）
＜情報処理システムについて＞
次に、図１を参照しながら、本発明の第１の実施形態に係る情報処理システムについて、詳細に説明する。図１は、本実施形態に係る情報処理システムについて説明するための説明図である。

本実施形態に係る情報処理システム１は、例えば図１に示したように、本実施形態に係る情報処理装置１０が属するネットワーク５と、本実施形態に係るクライアント機器２０が属するネットワーク７と、から構成されている。情報処理装置１０が属するネットワーク５と、クライアント機器２０が属するネットワーク７とは、インターネット３を介して互いに接続可能である。また、クライアント機器２０が属するネットワーク７には、プロキシサーバ（ＨＴＴＰプロキシ）９が設置されている。

本実施形態に係る情報処理装置１０およびクライアント機器２０は、それぞれリモートアクセス機能を有しており、ＨＴＴＰトンネリング方法を用いて互いに通信することが可能である。なお、以下の説明において、クライアント機器２０は、接続をイニシエートする機器を意味しており、データの送信側となる装置か受信側となる装置かを表しているものではない。同様に、情報処理装置１０は、接続がイニシエートされる機器を意味しており、データの受信側となる装置か送信側となる装置かを表しているものではない。

インターネット３は、情報処理装置１０とクライアント機器２０とを双方向通信又は一方向通信可能に接続する通信回線網であり、有線／無線を問わない。また、プロキシサーバ９は、ファイアウォールとして機能するＨＴＴＰプロキシであって、インターネット３とクライアント機器２０との間に設けられている。

情報処理装置１０およびクライアント機器２０は、リモートアクセス機能を有する装置であって、これらの装置にインストールされている上位アプリケーションを実行することで、様々な機能を実現することができる。これらの情報処理装置１０およびクライアント機器２０は、パーソナルコンピュータやサーバ等のコンピュータ装置であってもよく、テレビジョン受像器、ＤＶＤ／ＨＤＤレコーダ、携帯電話、ＰＤＡ（Ｐｅｒｓｏｎａｌ Ｄｉｇｉｔａｌ Ａｓｓｉｓｔａｎｔ）、デジタルカメラ、家庭用ゲーム機、デジタルビデオカメラ等のネットワークを介した通信機能を有する情報家電であってもよい。また、情報処理装置１０およびクライアント機器２０は、契約者が持ち運びできるポータブルデバイス（Ｐｏｒｔａｂａｌｅ Ｄｅｖｉｃｅ）、例えば、携帯型ゲーム機、ＰＨＳ、携帯型映像／音声プレーヤなどであってもよい。また、情報処理装置１０およびクライアント機器２０は、ＤＬＮＡガイドラインに準拠するデジタルメディアサーバ（Ｄｉｇｉｔａｌ Ｍｅｄｉａ Ｓｅｒｖｅｒ：ＤＭＳ）、デジタルメディアプレーヤー（Ｄｉｇｉｔａｌ Ｍｅｄｉａ Ｐｌａｙｅｒ：ＤＭＰ）、デジタルメディアレンダラー（Ｄｉｇｉｔａｌ Ｍｅｄｉａ Ｒｅｎｄｅｒｅｒ：ＤＭＲ）、デジタルメディアコントローラ（Ｄｉｇｉｔａｌ Ｍｅｄｉａ Ｃｏｎｔｒｏｌｌｅｒ）等であってもよい。

なお、上記情報処理装置１０およびクライアント機器２０については、以下で改めて詳細に説明する。

＜情報処理装置の構成について＞
続いて、図２を参照しながら、本実施形態に係る情報処理装置の構成について、詳細に説明する。図２は、本実施形態に係る情報処理装置１０の構成について説明するためのブロック図である。

本実施形態に係る情報処理装置１０は、例えば図２に示したように、通信部１０１と、ＴＣＰ送信バッファ１０３と、ＴＣＰ受信バッファ１０５と、コネクション待ち受け部１０７と、データ送信部１０９と、データ受信部１１９と、を主に備える。

通信部１０１は、例えば、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）、通信装置等から構成されており、ネットワークインターフェースを含む処理部である。この通信部１０１は、例えば、ＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）およびＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）の２種類のプロトコルに基づく通信制御を行うことが可能なスタック（ｓｔａｃｋ）である。本実施形態に係る情報処理装置１０は、この通信部１０１を介して、同一のネットワーク内に属する装置または異なるネットワークに属する装置と、通信を行う。

通信部送信バッファの一例であるＴＣＰ送信バッファ１０３、および、通信部受信バッファの一例であるＴＣＰ受信バッファ１０５のそれぞれは、例えば、ＲＯＭ、ＲＡＭや、ＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）等の記録装置等から構成されるバッファである。これらのバッファは、通信部１０１が自由にアクセスすることが可能である。

ＴＣＰ送信バッファ１０３は、通信部１０１のＴＣＰが送信するデータが一時保存されるバッファであり、ＴＣＰ受信バッファ１０５は、通信部１０１のＴＣＰが受信したデータが一時保存されるバッファである。

接続待ち受け部の一例であるコネクション待ち受け部１０７は、例えば、ＣＰＵ、ＲＯＭ、ＲＡＭ等から構成される。コネクション待ち受け部１０７は、後述するクライアント機器２０がプロキシサーバ９を介して送信した接続要請（例えば、ＨＴＴＰトンネリングの確立要請）を待ち受けて、接続の確立に必要な認証・暗号鍵決定処理等を実行し、データの送信および受信を可能とする処理部である。

データ送信部１０９は、例えば、ＣＰＵ、ＲＯＭ、ＲＡＭ等から構成され、通信部１０１を介して、送信先の情報処理装置やクライアント機器に対して、上位アプリケーションから伝送されたアプリケーションデータを送信する。このデータ送信部１０９は、フローコントロール送信管理部１１１と、ハートビート送信部１１３と、アプリケーションデータ送信部１１５と、アプリケーションデータ送信バッファ１１７と、を更に備える。

フローコントロール送信管理部１１１は、上述したようなＴＣＰのフローコントロールに基づいて、アプリケーションデータの送信管理を行う処理部である。このフローコントロール送信管理部１１１は、送信先の装置から通知された、送信先装置が受信可能なデータ容量に基づいて、後述するアプリケーションデータ送信部１１５から伝送されたアプリケーションデータの送信管理を行う。ここで、アプリケーションデータの送信管理とは、送信されるアプリケーションデータのパケットに対してシーケンスナンバーを付与したり、アプリケーションデータを送信先の装置に送信したり、パケットデータの修正や再送等の信頼性を提供したり、といった、ＴＣＰにおける一連のフローコントロールを含む。

このフローコントロール送信管理部１１１は、例えば、後述するアプリケーションデータ送信バッファ１１７から送信するアプリケーションデータを取得して、フローコントロールを行いながら、ＴＣＰ送信バッファ１０３に送信するアプリケーションデータを一時保存する。通信部１０１は、ＴＣＰ送信バッファ１０３に格納されたアプリケーションデータのパケットを、送信先の装置に対して送信する。

また、所定時間アプリケーションデータの送信が実行されていない場合には、フローコントロール送信管理部１１１は、その旨を後述するハートビート送信部１１３に通知するようにしてもよい。

接続維持用制御情報送信部の一例であるハートビート送信部１１３は、アプリケーションデータの送信先の装置との間で所定時間通信がなされていない場合に、送信先の装置に対して、接続維持用制御情報の一例であるハートビートデータを送信する。ハートビート送信部１１３で生成されたハートビートデータは、フローコントロール送信管理部１１１および通信部１０１を介して、送信先の装置へと送信される。

このハートビートデータを送信先の装置に対して送信することで、本実施形態に係る情報処理装置１０と送信先の装置との間で通信が行われたこととなり、確立されている接続を維持することが可能となる。

アプリケーションデータ送信部１１５は、上位アプリケーションから送信を要請されたアプリケーションデータを、後述するアプリケーションデータ送信バッファ１１７に一時記録する。また、アプリケーションデータ送信部１１５は、アプリケーションデータ送信バッファ１１７にアプリケーションデータを格納した旨を、ハートビート送信部１１３を介してフローコントロール送信管理部１１１に通知するようにしてもよい。

アプリケーションデータ送信バッファ１１７は、例えば、ＲＯＭ、ＲＡＭや、ＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）等の記録装置等から構成されるバッファである。このアプリケーションデータ送信バッファ１１７には、アプリケーションデータ送信部１１５が上位アプリケーションから取得したアプリケーションデータが一時記録される。アプリケーションデータ送信バッファ１１７は、フローコントロール送信管理部１１１およびアプリケーションデータ送信部１１５が、自由に読み書きすることができる。

データ受信部１１９は、例えば、ＣＰＵ、ＲＯＭ、ＲＡＭ等から構成され、通信部１０１を介して、送信先の情報処理装置やクライアント機器から送信されたアプリケーションデータを受信する。このデータ受信部１１９は、フローコントロール受信管理部１２１と、ハートビート受信部１２３と、アプリケーションデータ受信部１２５と、アプリケーションデータ受信バッファ１２７と、を更に備える。

フローコントロール受信管理部１２１は、上述したようなＴＣＰのフローコントロールに基づいて、アプリケーションデータの受信管理を行う処理部である。このフローコントロール受信管理部１２１は、後述するアプリケーションデータ受信バッファ１２７が記録可能なデータ容量の使用状況といった、アプリケーションデータ受信バッファ１２７の状態を監視する。また、フローコントロール受信管理部１２１は、通信部１０１が受信しＴＣＰ受信バッファ１０５に一時保存されているアプリケーションデータを取得し、後述するアプリケーションデータ受信部１２５に伝送する。

フローコントロール受信管理部１２１は、本実施形態に係る情報処理装置１０と送信元の装置との間に接続が確立すると、アプリケーションデータ受信バッファ１２７の使用状況を参照して、アプリケーションデータ受信バッファ１２７の空き容量を、情報処理装置１０が受信可能なデータ容量である初期空き容量サイズデータとして、接続が確立された装置に送信する。また、フローコントロール受信管理部１２１は、アプリケーションデータ受信バッファ１２７の監視結果に応じて、本実施形態に係る情報処理装置１０のアプリケーションデータ受信バッファ１２７の空き容量が増えたときに、空き容量サイズの増分を増分サイズデータとして接続が確立されている装置に送信する。

本実施形態に係るフローコントロール受信管理部１２１は、上述のように、アプリケーションデータ受信バッファ１２７の利用状況に応じて、送信元の装置に対して通知する初期空き容量サイズデータおよび増分サイズデータを決定している。そのため、送信元の装置から送信されるアプリケーションデータは、必ずアプリケーションデータ受信バッファ１２７に格納可能なデータ容量以下となるため、ＴＣＰ受信バッファ１０５の空き容量が無くなるという状況が発生しない。

接続維持用制御情報受信部の一例であるハートビート受信部１２３は、アプリケーションデータの送信元の装置から送信されたハートビートデータを受信する。受信したハートビートデータは、ハートビート受信部１２３によって破棄される。

本実施形態に係る情報処理装置１０では、上述のように、アプリケーション受信バッファ１２７の空き状況に応じたフローコントロールが行われているため、ＴＣＰ受信バッファ１０５の空き容量が無くなるという状況が発生しない。そのため、ハートビートデータそのものの受信ができなくなるという状況が発生しない。その結果、情報処理装置１０と送信先の装置との間で確立されている接続（セッション）を、プロキシサーバ９の設定によらず維持することが可能となる。

アプリケーションデータ受信部１２５は、アプリケーションデータ受信バッファ１２７に格納されているアプリケーションデータを取得して、上位アプリケーションへと伝送する。アプリケーションデータ受信部１２５が上位アプリケーションへデータの伝送を行うことにより、アプリケーションデータ受信バッファ１２７の空き容量は変化することとなる。

アプリケーションデータ受信バッファ１２７は、例えば、ＲＯＭ、ＲＡＭや、ＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）等の記録装置等から構成されるバッファである。このアプリケーションデータ受信バッファ１２７には、接続が確立されている装置から送信され、本実施形態に係る情報処理装置１０が受信したアプリケーションデータが、一時的に記録される。アプリケーションデータ受信バッファ１２７は、フローコントロール受信管理部１２１およびアプリケーションデータ受信部１２５が、自由に読み書きすることができる。

また、本実施形態に係る情報処理装置１０は、例えば、ＲＯＭ、ＲＡＭやＨＤＤ等から構成される未図示の記憶部に記録されたプログラム等をＣＰＵで実行することにより、上位アプリケーションとして機能する様々な処理を実現することが可能である。これらの上位アプリケーションは、本実施形態に係るアプリケーションデータ送信バッファ１１７およびアプリケーションデータ受信バッファ１２７に対して、自由に読み書きを行うことが可能である。

このような上位アプリケーションの一例として、例えば、ＤＬＮＡ（Ｄｉｇｉｔａｌ Ｌｉｖｉｎｇ Ｎｅｔｗｏｒｋ Ａｌｌｉａｎｃｅ）ガイドラインに準拠した各種制御プログラムを挙げることができる。

以上、本実施形態に係る情報処理装置１０の機能の一例を示した。上記の各構成要素は、汎用的な部材や回路を用いて構成されていてもよいし、各構成要素の機能に特化したハードウェアにより構成されていてもよい。また、各構成要素の機能を、ＣＰＵ等が全て行ってもよい。従って、本実施形態を実施する時々の技術レベルに応じて、適宜、利用する構成を変更することが可能である。

＜クライアント機器の構成について＞
続いて、図３を参照しながら、本実施形態に係るクライアント機器の構成について、詳細に説明する。図３は、本実施形態に係るクライアント機器２０の構成について説明するためのブロック図である。

本実施形態に係るクライアント機器２０は、例えば図３に示したように、通信部２０１と、ＴＣＰ送信バッファ２０３と、ＴＣＰ受信バッファ２０５と、コネクション確立部２０７と、データ送信部２０９と、データ受信部２１９と、を主に備える。

ここで、クライアント機器２０が備える通信部２０１、ＴＣＰ送信バッファ２０３、ＴＣＰ受信バッファ２０５、データ送信部２０９およびデータ受信部２１９は、本実施形態に係る情報処理装置１０が備える通信部１０１、ＴＣＰ送信バッファ１０３、ＴＣＰ受信バッファ１０５、データ送信部１０９およびデータ受信部１１９と同様の構成を有し、ほぼ同一の効果を奏するため、詳細な説明は省略する。

接続確立部の一例であるコネクション確立部２０７は、例えば、ＣＰＵ、ＲＯＭ、ＲＡＭ等から構成される。コネクション確立部２０７は、プロキシサーバ９を介して本実施形態に係る情報処理装置１０に接続要請（例えば、ＨＴＴＰトンネリングの確立要請）を送信し、情報処理装置１０との間でＨＴＴＰトンネリングを確立する。また、コネクション確立部２０７は、接続の確立に必要な認証・暗号鍵決定処理等を実行し、データの送信および受信を可能とする処理部である。

また、本実施形態に係るクライアント機器２０は、例えば、ＲＯＭ、ＲＡＭやＨＤＤ等から構成される未図示の記憶部に記録されたプログラム等をＣＰＵで実行することにより、上位アプリケーションとして機能する様々な処理を実現することが可能である。これらの上位アプリケーションは、本実施形態に係るアプリケーションデータ送信バッファ２１７およびアプリケーションデータ受信バッファ２２７に対して、自由に読み書きを行うことが可能である。

このような上位アプリケーションの一例として、例えば、ＤＬＮＡ（Ｄｉｇｉｔａｌ Ｌｉｖｉｎｇ Ｎｅｔｗｏｒｋ Ａｌｌｉａｎｃｅ）ガイドラインに準拠した各種制御プログラムを挙げることができる。

以上、本実施形態に係るクライアント機器２０の機能の一例を示した。上記の各構成要素は、汎用的な部材や回路を用いて構成されていてもよいし、各構成要素の機能に特化したハードウェアにより構成されていてもよい。また、各構成要素の機能を、ＣＰＵ等が全て行ってもよい。従って、本実施形態を実施する時々の技術レベルに応じて、適宜、利用する構成を変更することが可能である。

＜情報処理方法について＞
続いて、図４〜図７Ｃを参照しながら、本実施形態に係る情報処理装置１０およびクライアント機器２０で行われる情報処理方法について、詳細に説明する。図４および図５は、本実施形態に係る情報処理システムを概略的に説明するための説明図である。図６Ａ〜図６Ｄは、本実施形態に係る情報処理システムで行われる情報処理方法を説明するための説明図である。図７Ａ〜図７Ｃは、本実施形態に係る情報処理システムで行われる情報処理方法を説明するための流れ図である。

本実施形態に係る情報処理システム１では、例えば図４に示したように、情報処理装置１０の通信部１０１とクライアント機器２０の通信部２０１との間で、ＨＴＴＰトンネリング方式によるＴＣＰの非同期全二重通信ＡおよびＢが確立されている。そのため、本実施形態に係る情報処理方法は、例えば図５に示したように、クライアント機器２０から情報処理装置１０へアプリケーションデータやハートビートデータを送信する場合にも使用可能であり、情報処理装置１０からクライアント機器２０へアプリケーションデータやハートビートデータを送信する場合にも使用可能である。

また、例えばクライアント機器２０から情報処理装置１０へとデータが送信される場合には、アプリケーションデータやハートビートデータの送信はコネクションＡを介して行われ、情報処理装置１０から送信される空き容量の増分等のデータは、コネクションＢを介して送信される。

例えば図４に示したように、クライアント機器２０のアプリケーションデータ送信部２１５から情報処理装置１０のアプリケーションデータ受信部１２５に対して、コネクションＣで示したようなデータの送信を実行する場合を考える。この場合に、クライアント機器２０のデータ送信部２０９は、通信部２０１を介して、ＨＴＴＰトンネリング方式でＴＣＰの非同期全二重通信を用いて情報処理装置１０の通信部１０１に接続を行う。クライアント機器２０の通信部２０１と情報処理装置１０の通信部１０１との間でコネクションが確立されると、クライアント機器２０のデータ送信部２０９は、情報処理装置１０のデータ受信部１１９に対してアプリケーションデータを送信する。

なお、上述のようなフローコントロールは、ＰＯＳＴ側のコネクションとＧＥＴ側のコネクションの両方で行ってもよく、ＰＯＳＴ側のコネクションまたはＧＥＴ側のコネクションの片方でのみ実行するようにしてもよい。このように適宜設定を変更することにより、本実施形態に係る情報処理装置１０やクライアント機器２０の処理能力等に応じて、システムに加わる負荷を制御することが可能となる。

次に、図６Ａ〜図６Ｄを参照しながら、本実施形態に係る情報処理方法をより詳細に説明する。なお、以下の説明では、クライアント機器２０がデータ送信側の装置となるとともに、情報処理装置１０がデータ受信側の装置となって、クライアント機器２０が情報処理装置１０に対してデータを送信する場合について説明を行う。

例えば図６Ａに示したように、クライアント機器２０と情報処理装置１０との間でＨＴＴＰトンネリングによるコネクションが確立されると、情報処理装置１０のフローコントロール受信管理部１２１は、アプリケーションデータ受信バッファ１２７の空き容量を参照する。フローコントロール受信管理部１２１は、参照結果に基づいて、アプリケーションデータ受信バッファ１２７が受信可能なデータ容量を決定し、初期空き容量サイズデータＶＳとして、クライアント機器２０のフローコントロール送信管理部２１１に通知する。

初期空き容量サイズデータＶＳを受信したクライアント機器２０のフローコントロール送信管理部２１１は、通知された初期空き容量サイズを記憶しておく。クライアント機器２０のフローコントロール送信管理部２１１は、例えば図６Ｂに示したように、通知された初期空き容量サイズを超えないように、アプリケーションデータ送信バッファ２１７に格納されているデータを取得して、ＴＣＰ送信バッファ２０３に一時的に格納する。クライアント機器２０の通信部２０１は、ＴＣＰ送信バッファ２０３に格納されているアプリケーションデータを取得して、所定のデータ容量のパケットＰに区分けしながら情報処理装置１０に送信する。

情報処理装置１０の通信部１０１は、受信したパケットＰを、ＴＣＰ受信バッファ１０５に一時的に格納し、情報処理装置１０のフローコントロール受信管理部１１１は、ＴＣＰ受信バッファ１０５に格納されているアプリケーションデータを取得して、アプリケーションデータ受信バッファ１２７に格納する。このような処理が繰り返されることで、アプリケーションデータ受信バッファ１２７のデータ容量は、徐々に一杯になっていく。

ここで、例えば図６Ｃに示したように、あるタイミングで、情報処理装置１０のアプリケーションデータ受信部１２５が、アプリケーションデータ受信バッファ１２７に一時保存されているアプリケーションデータを、バッファ１２７から引き出して上位アプリケーションに転送する。その結果、アプリケーションデータ受信バッファ１２７に空きが生じる。その結果、アプリケーションデータ受信バッファ１２７の空き容量の状態を監視しているフローコントロール受信管理部１２１は、アプリケーションデータ受信バッファ１２７に生じた空き容量の大きさを把握することが可能となる。情報処理装置１０のフローコントロール受信管理部１２１は、把握した空き容量の増加分を、増分サイズデータＡＳとしてクライアント機器２０のフローコントロール送信管理部２１１に通知する。

増分サイズデータＡＳの通知を受けたクライアント機器２０のフローコントロール送信管理部２１１は、予め記憶しておいた初期空き容量サイズに、新たに通知された増分サイズを追加して、再度記憶する。クライアント機器２０のフローコントロール送信管理部２１１は、新たに記憶したデータサイズに基づいて、必要ならばデータの追加送信を行う。

また、記憶している初期空き容量サイズ分のデータを送信したクライアント機器２０のフローコントロール送信管理部２１１は、アプリケーションデータの送信を中止して、情報処理装置１０のＴＣＰ受信バッファ１０５の空き容量がゼロとなってしまう状況を回避する。

このように、本実施形態に係る情報処理方法では、接続確立時に送信先（上述の例では情報処理装置１０）の装置から通知されるアプリケーションデータ受信バッファの空き容量（すなわち、初期空き容量サイズデータ）と、アプリケーションデータ受信バッファの空き容量が増加した際に通知される増分サイズデータとを用いて、送信元の装置でデータの送信量を計算することが可能である。そのため、送信元の装置から送信されたアプリケーションデータのデータ容量は、最大でも送信先の装置のアプリケーションデータ受信バッファの空き容量の大きさとなり、必ず送信先のアプリケーションデータ受信バッファ１２７に格納可能な容量となる。そのため、送信先の装置のＴＣＰ受信バッファ（上述の例では、情報処理装置１０のＴＣＰ受信バッファ１０５）は、必ず空き容量が存在することとなる。

また、一定時間アプリケーションデータの送信が行われていないことを検知したクライアント機器２０のハートビート送信部２１３は、例えば図６Ｄに示したように、ハートビートデータＨＢを情報処理装置１０に送信する。情報処理装置１０のＴＣＰ受信バッファ１０５は、常に空き容量が存在するように管理されているため、クライアント機器２０から送信されるハートビートデータＨＢは、情報処理装置１０のＴＣＰ受信バッファ１０５に一旦格納される。情報処理装置１０のハートビート受信部１２３は、ＴＣＰ受信バッファ１０５に格納されたハートビートデータＨＢをただちに抜き取ってＴＣＰ受信バッファ１０５に空き容量を生じさせるとともに、抜き取ったハートビートデータＨＢを破棄する。

このような処理を行うことで、送信元の装置（上述の例ではクライアント機器２０）から送信されたハートビートデータは、必ず送信先の装置（上述の例では情報処理装置１０）に受信される。そのため、送信元の装置から送信先の装置へハートビートデータＨＢを送信し続けることが可能となり、プロキシサーバ９の設定によるコネクションの解消を回避することができる。

上述の説明をシーケンス図として整理すると、図７Ａ〜図７Ｃに示したようになる。図７Ａ〜図７Ｃは、本実施形態に係る情報処理システムで行われる情報処理方法を説明するための流れ図である。

まず、クライアント機器２０のコネクション確立部２０７から情報処理装置１０のコネクション待ち受け部１０７に対してコネクションの確立要請がなされると、通信に必要な認証や暗号鍵等が決定され、ＨＴＴＰトンネリングを用いたコネクションが確立する（ステップＳ１０１）。

続いて、情報処理装置１０のフローコントロール受信管理部１２１は、アプリケーションデータ受信バッファ１２７の空き状況に基づいて初期空き容量サイズ情報（例えば、容量Ｎ）を送信する（ステップＳ１０３）。

クライアント機器２０のフローコントロール送信管理部２１１は、情報処理装置１０から送信された初期空き容量サイズ情報を受信し（ステップＳ１０５）、初期空き容量サイズ情報に記載されている容量に基づいて、送信可能なデータ容量（データサイズ）を更新する（ステップＳ１０７）。例えば、初期空き容量サイズ情報に、受信可能なデータ容量がＮであると記載されていた場合には、フローコントロール送信管理部２１１は、送信可能な最大データ容量ＳｅｎｄＭａｘをＮと設定する。アプリケーションデータ送信部２１５によりアプリケーションデータ送信バッファ１１７にアプリケーションデータが格納されると（ステップＳ１０９）、フローコントロール送信管理部２１１は、送信可能な最大データ容量ＳｅｎｄＭａｘとなるまで、アプリケーションデータを送信する（ステップＳ１１１）。この際、フローコントロール送信管理部２１１は、記憶している送信可能な最大データ容量ＳｅｎｄＭａｘから送信したデータ容量（ｄａｔａｓｉｚｅ）を差し引いて、通知された初期空き容量サイズを超えないようにする。

情報処理装置１０の通信部１０１は、送信されてきたアプリケーションデータをＴＣＰ受信バッファ１０５に一時的に格納し、フローコントロール受信管理部１２１は、ＴＣＰ受信バッファ１０５からデータを引き抜いて、アプリケーションデータ受信バッファ１２７に格納する（ステップＳ１１３）。あるタイミングでアプリケーションデータ受信部１２５によってアプリケーションデータ受信バッファ１２７からアプリケーションデータが引き抜かれると（ステップＳ１１５）、フローコントロール受信管理部１２１は、増分サイズ情報（例えば、容量Ｘ）を、クライアント機器２０に通知する（ステップＳ１１７）。

クライアント機器２０のフローコントロール送信管理部２１１は、情報処理装置１０から送信された増分サイズ情報を受信し（ステップＳ１１９）、増分サイズ情報に記載されている容量に基づいて、送信可能なデータ容量を更新する（ステップＳ１２１）。例えば、増分サイズ情報に、増加したデータ容量がＸであると記載されていた場合には、フローコントロール送信管理部２１１は、記憶している送信可能な最大データ容量ＳｅｎｄＭａｘにＸを追加して、新たな最大データ容量ＳｅｎｄＭａｘとする。フローコントロール送信管理部２１１は、同様にして、送信可能な最大データ容量ＳｅｎｄＭａｘとなるまで、アプリケーションデータを送信する（ステップＳ１２３）。この際、フローコントロール送信管理部２１１は、記憶している送信可能な最大データ容量ＳｅｎｄＭａｘから送信したデータ容量（ｄａｔａｓｉｚｅ）を差し引いて、記憶しているデータサイズを超えないようにする。

情報処理装置１０の通信部１０１は、送信されてきたアプリケーションデータをＴＣＰ受信バッファ１０５に一時的に格納し、フローコントロール受信管理部１２１は、ＴＣＰ受信バッファ１０５からデータを引き抜いて、アプリケーションデータ受信バッファ１２７に格納する（ステップＳ１２５）。

このような処理が繰り返し行われる中で、一定時間データを送信していないことが検知されると（ステップＳ１２７）、クライアント機器２０のハートビート送信部２１３は、ハートビートデータＨＢを生成して、情報処理装置１０へと送信する（ステップＳ１２９）。

情報処理装置１０のＴＣＰ受信バッファ１０５は、常に空き容量があるように管理されているため、クライアント機器２０から送信されたハートビートデータＨＢは、通信部１０１によって受信され（ステップＳ１３１）、ＴＣＰ受信バッファ１０５に一旦格納される。情報処理装置１０のハートビート受信部１２３は、ＴＣＰ受信バッファ１０５から直ちにハートビートデータＨＢを引き抜いて、引き抜いたハートビートデータを破棄する（ステップＳ１３３）。

このように、本実施形態に係る情報処理方法では、接続確立時に送信先の装置から通知されるアプリケーションデータ受信バッファの空き容量（すなわち、初期空き容量サイズ情報）と、アプリケーションデータ受信バッファの空き容量が増加した際に通知される増分サイズ情報とを用いて、送信元の装置でデータの送信量を計算することが可能である。そのため、送信元の装置から送信されたアプリケーションデータのデータ容量は、最大でも送信先の装置のアプリケーションデータ受信バッファの空き容量の大きさとなり、必ず送信先のアプリケーションデータ受信バッファ１２７に格納可能な容量となる。そのため、送信先の装置のＴＣＰ受信バッファ（上述の例では、情報処理装置１０のＴＣＰ受信バッファ１０５）は、必ず空き容量が存在することとなる。

また、送信元の装置（上述の例ではクライアント機器２０）から送信されたハートビートデータは、必ず送信先の装置（上述の例では情報処理装置１０）に受信される。そのため、送信元の装置から送信先の装置へハートビートデータＨＢを送信し続けることが可能となり、プロキシサーバ９の設定によるコネクションの解消を回避することができる。

なお、上述の説明では、クライアント機器２０がデータ送信側の装置となり、情報処理装置１０がデータ受信側の装置となる場合について説明したが、情報処理装置１０がデータ送信側の装置となり、クライアント機器２０がデータ受信側の装置となる場合も同様である。すなわち、上述の説明における情報処理装置１０のデータ受信部１１９に換わってクライアント機器２０のデータ受信部２１９が処理を行い、上述の説明におけるクライアント機器２０のデータ送信部２０９に換わって情報処理装置１０のデータ送信部１０９が処理を行うこととなる。

また、上述の説明では、ハートビートデータＨＢを、確立されているコネクションの維持のために使用しているが、このハートビートデータＨＢを、装置や通信経路の障害検出に用いることも可能である。例えば、受信側の装置のハートビート受信部は、一定期間ハートビートデータＨＢまたはアプリケーションデータを受信していないことを検知した場合、確立されているコネクションまたは送信元の装置に何らかの障害が発生していると判断することが可能である。

＜ハードウェア構成について＞
次に、図８を参照しながら、本発明の各実施形態に係る情報処理装置１０のハードウェア構成について、詳細に説明する。図８は、本実施形態に係る情報処理装置１０のハードウェア構成を説明するためのブロック図である。

情報処理装置１０は、主に、ＣＰＵ３０１と、ＲＯＭ３０３と、ＲＡＭ３０５と、ホストバス３０７と、ブリッジ３０９と、外部バス３１１と、インターフェース３１３と、入力装置３１５と、出力装置３１７と、ストレージ装置３１９と、ドライブ３２１と、接続ポート３２３と、通信装置３２５とを備える。

ＣＰＵ３０１は、演算処理装置および制御装置として機能し、ＲＯＭ３０３、ＲＡＭ３０５、ストレージ装置３１９、またはリムーバブル記録媒体３２７に記録された各種プログラムに従って、情報処理装置１０内の動作全般またはその一部を制御する。ＲＯＭ３０３は、ＣＰＵ３０１が使用するプログラムや演算パラメータ等を記憶する。ＲＡＭ３０５は、ＣＰＵ３０１の実行において使用するプログラムや、その実行において適宜変化するパラメータ等を一次記憶する。これらはＣＰＵバス等の内部バスにより構成されるホストバス３０７により相互に接続されている。

ホストバス３０７は、ブリッジ３０９を介して、ＰＣＩ（Ｐｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔ Ｉｎｔｅｒｃｏｎｎｅｃｔ／Ｉｎｔｅｒｆａｃｅ）バスなどの外部バス３１１に接続されている。

入力装置３１５は、例えば、マウス、キーボード、タッチパネル、ボタン、スイッチおよびレバーなどユーザが操作する操作手段である。また、入力装置３１５は、例えば、赤外線やその他の電波を利用したリモートコントロール手段（いわゆる、リモコン）であってもよいし、情報処理装置１０の操作に対応した携帯電話やＰＤＡ等の外部接続機器３２９であってもよい。さらに、入力装置３１５は、例えば、上記の操作手段を用いてユーザにより入力された情報に基づいて入力信号を生成し、ＣＰＵ３０１に出力する入力制御回路などから構成されている。情報処理装置１０のユーザは、この入力装置３１５を操作することにより、情報処理装置１０に対して各種のデータを入力したり処理動作を指示したりすることができる。

出力装置３１７は、例えば、ＣＲＴディスプレイ装置、液晶ディスプレイ装置、プラズマディスプレイ装置、ＥＬディスプレイ装置およびランプなどの表示装置や、スピーカおよびヘッドホンなどの音声出力装置や、プリンタ装置、携帯電話、ファクシミリなど、取得した情報をユーザに対して視覚的または聴覚的に通知することが可能な装置で構成される。出力装置３１７は、例えば、情報処理装置１０が行った各種処理により得られた結果を出力する。具体的には、表示装置は、情報処理装置１０が行った各種処理により得られた結果を、テキストまたはイメージで表示する。他方、音声出力装置は、再生された音声データや音響データ等からなるオーディオ信号をアナログ信号に変換して出力する。

ストレージ装置３１９は、情報処理装置１０の記憶部の一例として構成されたデータ格納用の装置であり、例えば、ＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）等の磁気記憶部デバイス、半導体記憶デバイス、光記憶デバイス、または光磁気記憶デバイス等により構成される。このストレージ装置３１９は、ＣＰＵ３０１が実行するプログラムや各種データ、および外部から取得した音響信号データや画像信号データなどを格納する。

ドライブ３２１は、記録媒体用リーダライタであり、情報処理装置１０に内蔵、あるいは外付けされる。ドライブ３２１は、装着されている磁気ディスク、光ディスク、光磁気ディスク、または半導体メモリ等のリムーバブル記録媒体３２７に記録されている情報を読み出して、ＲＡＭ３０５に出力する。また、ドライブ３２１は、装着されている磁気ディスク、光ディスク、光磁気ディスク、または半導体メモリ等のリムーバブル記録媒体３２７に記録を書き込むことも可能である。リムーバブル記録媒体３２７は、例えば、ＤＶＤメディア、ＨＤ−ＤＶＤメディア、Ｂｌｕ−ｒａｙメディア、コンパクトフラッシュ（登録商標）（ＣｏｍｐａｃｔＦｌａｓｈ：ＣＦ）、メモリースティック、または、ＳＤメモリカード（Ｓｅｃｕｒｅ Ｄｉｇｉｔａｌ ｍｅｍｏｒｙ ｃａｒｄ）等である。また、リムーバブル記録媒体３２７は、例えば、非接触型ＩＣチップを搭載したＩＣカード（Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ ｃａｒｄ）または電子機器等であってもよい。

接続ポート３２３は、例えば、ＵＳＢ（Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ）ポート、ｉ．Ｌｉｎｋ等のＩＥＥＥ１３９４ポート、ＳＣＳＩ（Ｓｍａｌｌ Ｃｏｍｐｕｔｅｒ Ｓｙｓｔｅｍ Ｉｎｔｅｒｆａｃｅ）ポート、ＲＳ−２３２Ｃポート、光オーディオ端子、ＨＤＭＩ（Ｈｉｇｈ−Ｄｅｆｉｎｉｔｉｏｎ Ｍｕｌｔｉｍｅｄｉａ Ｉｎｔｅｒｆａｃｅ）ポート等の、機器を情報処理装置１０に直接接続するためのポートである。この接続ポート３２３に外部接続機器３２９を接続することで、情報処理装置１０は、外部接続機器３２９から直接音響信号データや画像信号データを取得したり、外部接続機器３２９に音響信号データや画像信号データを提供したりする。

通信装置３２５は、例えば、通信網３３１に接続するための通信デバイス等で構成された通信インターフェースである。通信装置３２５は、例えば、有線または無線ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）、Ｂｌｕｅｔｏｏｔｈ、またはＷＵＳＢ（Ｗｉｒｅｌｅｓｓ ＵＳＢ）用の通信カード、光通信用のルータ、ＡＤＳＬ（Ａｓｙｍｍｅｔｒｉｃ Ｄｉｇｉｔａｌ Ｓｕｂｓｃｒｉｂｅｒ Ｌｉｎｅ）用のルータ、または、各種通信用のモデム等である。この通信装置３２５は、例えば、インターネットや他の通信機器との間で音響信号等を送受信することができる。また、通信装置３２５に接続される通信網３３１は、有線または無線によって接続されたネットワーク等により構成され、例えば、インターネット、家庭内ＬＡＮ、赤外線通信、ラジオ波通信または衛星通信等であってもよい。

以上、本発明の各実施形態に係る情報処理装置１０の機能を実現可能なハードウェア構成の一例を示した。上記の各構成要素は、汎用的な部材を用いて構成されていてもよいし、各構成要素の機能に特化したハードウェアにより構成されていてもよい。従って、本実施形態を実施する時々の技術レベルに応じて、適宜、利用するハードウェア構成を変更することが可能である。

なお、本発明の各実施形態に係るクライアント機器２０は、本発明の各実施形態に係る情報処理装置１０と同様のハードウェア構成を有するため、詳細な説明は省略する。

なお、本発明の各実施形態に係る情報処理装置１０は、以下に示すような機能を有するプログラムとして提供されることも可能である。このプログラムは、接続をイニシエートするクライアント機器との間に接続を確立する接続待ち受け機能と、クライアント機器から送信されたデータをアプリケーションデータ受信バッファへと転送するとともに、アプリケーションデータ受信バッファの空き容量を監視して当該アプリケーションデータ受信バッファが受信可能なデータ容量をクライアント機器に通知するフローコントロール受信管理機能と、クライアント機器から送信されたデータをアプリケーションデータ受信バッファから取得して、上位アプリケーションに伝送するアプリケーションデータ受信機能と、をコンピュータに実現させるためのプログラムである。

このコンピュータプログラムは、コンピュータが備える記憶部に格納され、コンピュータが備えるＣＰＵに読み込まれて実行されることにより、コンピュータを上記の情報処理装置１０として機能させる。また、コンピュータプログラムが記録された、コンピュータで読み取り可能な記録媒体も提供することができる。記録媒体は、例えば、磁気ディスク、光ディスク、光磁気ディスク、フラッシュメモリなどである。また、上記のコンピュータプログラムは、記録媒体を用いずに、例えばネットワークを介して配信してもよい。

また、本発明の各実施形態に係るクライアント機器２０は、以下に示すような機能を有するプログラムとして提供されることも可能である。このプログラムは、情報処理装置との間の接続をイニシエートして、当該情報処理装置との間に接続を確立する接続確立機能と、情報処理装置に対して送信されるデータを上位アプリケーションから取得して、アプリケーションデータ送信バッファに伝送するアプリケーションデータ送信機能と、アプリケーションデータ送信バッファから情報処理装置へ送信するデータを取得し、情報処理装置から通知される当該情報処理装置が受信可能なデータ容量に基づいて、取得したデータを情報処理装置に送信するフローコントロール送信管理機能と、をコンピュータに実現させるためのプログラムである。

このコンピュータプログラムは、コンピュータが備える記憶部に格納され、コンピュータが備えるＣＰＵに読み込まれて実行されることにより、コンピュータを上記のクライアント機器２０として機能させる。また、コンピュータプログラムが記録された、コンピュータで読み取り可能な記録媒体も提供することができる。記録媒体は、例えば、磁気ディスク、光ディスク、光磁気ディスク、フラッシュメモリなどである。また、上記のコンピュータプログラムは、記録媒体を用いずに、例えばネットワークを介して配信してもよい。

このように、本発明の各実施形態によれば、インアクティビティを検出した場合にはＨＴＴＰトランザクションのＴＣＰコネクションを切断するという、一般的な設定条件が設定されたプロキシサーバに接続されている装置に対して、ＨＴＴＰトンネリングを行うことが可能となる。

以上、添付図面を参照しながら本発明の好適な実施形態について説明したが、本発明はかかる例に限定されないことは言うまでもない。当業者であれば、特許請求の範囲に記載された範疇内において、各種の変更例または修正例に想到し得ることは明らかであり、それらについても当然に本発明の技術的範囲に属するものと了解される。

本発明の第１の実施形態に係る情報処理システムを説明するための説明図である。 同実施形態に係る情報処理装置の構成を説明するためのブロック図である。 同実施形態に係るクライアント機器の構成を説明するためのブロック図である。 同実施形態に係る情報処理システムを概略的に説明するための説明図である。 同実施形態に係る情報処理システムを概略的に説明するための説明図である。 同実施形態に係る情報処理システムで行われる情報処理方法を説明するための説明図である。 同実施形態に係る情報処理システムで行われる情報処理方法を説明するための説明図である。 同実施形態に係る情報処理システムで行われる情報処理方法を説明するための説明図である。 同実施形態に係る情報処理システムで行われる情報処理方法を説明するための説明図である。 同実施形態に係る情報処理システムで行われる情報処理方法を説明するための流れ図である。 同実施形態に係る情報処理システムで行われる情報処理方法を説明するための流れ図である。 同実施形態に係る情報処理システムで行われる情報処理方法を説明するための流れ図である。 同実施形態に係る情報処理装置のハードウェア構成を説明するためのブロック図である。 リモートアクセスによる接続を説明するための説明図である。 リモートアクセスによる接続を説明するための説明図である。 リモートアクセスによる接続を説明するための説明図である。 リモートアクセスによる接続を説明するための説明図である。 ＴＣＰにおけるフローコントロールを説明するための説明図である。 ＴＣＰにおけるフローコントロールを説明するための説明図である。 プロキシサーバを介したリモートアクセスによる接続の問題点を説明するための説明図である。

符号の説明

１ 情報処理システム
９ プロキシサーバ
１０ 情報処理装置
２０ クライアント機器
１０１，２０１ 通信部
１０３，２０３ ＴＣＰ送信バッファ
１０５，２０５ ＴＣＰ受信バッファ
１０７ コネクション待ち受け部
１０９，２０９ データ送信部
１１１，２１１ フローコントロール送信管理部
１１３，２１３ ハートビート送信部
１１５，２１５ アプリケーションデータ送信部
１１７，２１７ アプリケーションデータ送信バッファ
１１９，２１９ データ受信部
１２１，２２１ フローコントロール受信管理部
１２３，２２３ ハートビート受信部
１２５，２２５ アプリケーションデータ受信部
１２７，２２７ アプリケーションデータ受信バッファ
２０７ コネクション確立部
ＶＳ 初期空き容量サイズデータ
ＡＳ 増分サイズデータ
ＨＢ ハートビートデータ
Ｐ パケット

Claims (16)

1. 接続をイニシエートするクライアント機器との間に接続を確立する接続待ち受け部と、
   前記クライアント機器から送信されるデータを受信するデータ受信部と、
   を備え、
   前記データ受信部は、
   前記クライアント機器から送信されるデータが一時保存されるアプリケーションデータ受信バッファと、
   前記クライアント機器から送信された前記データを前記アプリケーションデータ受信バッファから取得して、上位アプリケーションに伝送するアプリケーションデータ受信部と、
   前記アプリケーションデータ受信バッファの空き容量を監視して当該アプリケーションデータ受信バッファが受信可能なデータ容量を前記クライアント機器に通知するとともに、前記クライアント機器から送信されたデータを前記アプリケーションデータ受信バッファへと転送するフローコントロール受信管理部と、
   を有する、情報処理装置。
2. 前記フローコントロール受信管理部は、前記クライアント機器との接続が確立した際に、前記アプリケーションデータ受信バッファが受信可能なデータ容量を前記クライアント機器へと通知する、請求項１に記載の情報処理装置。
3. 前記フローコントロール受信管理部は、前記空き容量が増加した際に、当該空き容量の増加量を前記クライアント機器へと通知する、請求項２に記載の情報処理装置。
4. 前記情報処理装置は、
   前記クライアント機器との通信を制御する通信部と、
   前記通信部が前記クライアント機器から受信したデータが一時保存される通信部受信バッファと、
   を更に備え、
   前記フローコントロール受信管理部は、前記通信部受信バッファに一時保存されている前記データを、前記アプリケーションデータ受信バッファへと転送する、請求項１に記載の情報処理装置。
5. 前記情報処理装置は、前記クライアント機器から送信される接続維持用制御情報を受信する接続維持用制御情報受信部を更に備え、
   前記接続維持用制御情報受信部は、前記接続維持用制御情報を受信すると、受信した当該接続維持用制御情報を破棄する、請求項１に記載の情報処理装置。
6. 前記情報処理装置は、前記クライアント機器に対してデータを送信するデータ送信部を更に備え、
   前記データ送信部は、
   前記クライアント機器に対して送信されるデータが一時保存されるアプリケーションデータ送信バッファと、
   前記クライアント機器に対して送信されるデータを上位アプリケーションから取得して、前記アプリケーションデータ送信バッファに伝送するアプリケーションデータ送信部と、
   前記アプリケーションデータ送信バッファから前記データを取得し、前記クライアント機器から通知される当該データ送信装置が受信可能なデータ容量に基づいて、取得した前記データを前記クライアント機器に送信するフローコントロール送信管理部と、
   を有する、請求項１に記載の情報処理装置。
7. 前記情報処理装置は、
   前記クライアント機器との通信を制御する通信部と、
   前記通信部が前記クライアント機器へ送信するデータが一時保存される通信部送信バッファと、
   を更に有し、
   前記フローコントロール送信管理部は、前記アプリケーションデータ送信バッファに一時保存されているデータを、前記通信部送信バッファへと転送する、請求項６に記載の情報処理装置。
8. 接続をイニシエートするクライアント機器との間に接続を確立するステップと、
   前記クライアント機器から送信されるデータが一時保存されるアプリケーションデータ受信バッファの空き容量に基づいて、前記クライアント機器に前記アプリケーションデータ受信バッファが受信可能なデータ容量を通知するステップと、
   前記クライアント機器から送信された前記データを前記アプリケーションデータ受信バッファに一時保存するステップと、
   前記アプリケーションデータ受信バッファに一時保存された前記データを、上位アプリケーションに伝送するステップと、
   を含む、情報処理方法。
9. 前記クライアント機器に対して送信されるデータを上位アプリケーションから取得して、前記クライアント機器に対して送信されるデータが一時保存されるアプリケーションデータ送信バッファに取得した前記データを伝送するステップと、
   前記アプリケーションデータ送信バッファから前記データを取得し、前記クライアント機器から通知される当該クライアント機器が受信可能なデータ容量に基づいて、取得した前記データを前記クライアント機器に送信するステップと、
   を更に含む、請求項８に記載の情報処理方法。
10. 情報処理装置との間の接続をイニシエートして、当該情報処理装置との間に接続を確立する接続確立部と、
    前期情報処理装置に対してデータを送信するデータ送信部と、
    を備え、
    前記データ送信部は、
    前記情報処理装置に対して送信されるデータが一時保存されるアプリケーションデータ送信バッファと、
    前記情報処理装置に対して送信されるデータを上位アプリケーションから取得して、前記アプリケーションデータ送信バッファに伝送するアプリケーションデータ送信部と、
    前記アプリケーションデータ送信バッファから前記データを取得し、前記情報処理装置から通知される当該情報処理装置が受信可能なデータ容量に基づいて、取得した前記データを前記情報処理装置に送信するフローコントロール送信管理部と、
    を有する、クライアント機器。
11. 前記クライアント機器は、前記情報処理装置から送信されるデータを受信するデータ受信部を更に備え、
    前記データ受信部は、
    前記情報処理装置から送信されるデータが一時保存されるアプリケーションデータ受信バッファと、
    前記情報処理装置から送信された前記データを前記アプリケーションデータ受信バッファから取得して、上位アプリケーションに伝送するアプリケーションデータ受信部と、
    前記アプリケーションデータ受信バッファの空き容量を監視して当該アプリケーションデータ受信バッファが受信可能なデータ容量を前記情報処理装置に通知するとともに、前記情報処理装置から送信されたデータを前記アプリケーションデータ受信バッファへと転送するフローコントロール受信管理部と、
    を有する、請求項１０に記載のクライアント機器。
12. 情報処理装置との間の接続をイニシエートして、当該情報処理装置との間に接続を確立するステップと、
    前記情報処理装置に対して送信されるデータを上位アプリケーションから取得して、前記情報処理装置に対して送信されるデータが一時保存されるアプリケーションデータ送信バッファに取得した前記データを伝送するステップと、
    前記アプリケーションデータ送信バッファから前記データを取得し、前記情報処理装置から通知される当該情報処理装置が受信可能なデータ容量に基づいて、取得した前記データを前記情報処理装置に送信するステップと、
    を含む、情報処理方法。
13. 前記情報処理装置から送信されるデータが一時保存されるアプリケーションデータ受信バッファの空き容量に基づいて、前記情報処理装置に前記アプリケーションデータ受信バッファが受信可能なデータ容量を通知するステップと、
    前記情報処理装置から送信された前記データを前記アプリケーションデータ受信バッファに一時保存するステップと、
    前記アプリケーションデータ受信バッファに一時保存された前記データを、上位アプリケーションに伝送するステップと、
    を更に含む、請求項１２に記載の情報処理方法。
14. 情報処理装置との間の接続をイニシエートして、当該情報処理装置との間に接続を確立する接続確立部と、
    前記情報処理装置に対してデータを送信するデータ送信部と、
    を備え、
    前記データ送信部は、
    前記情報処理装置に対して送信されるデータが一時保存されるアプリケーションデータ送信バッファと、
    前記情報処理装置に対して送信されるデータを上位アプリケーションから取得して、前記アプリケーションデータ送信バッファに伝送するアプリケーションデータ送信部と、
    前記アプリケーションデータ送信バッファから前記データを取得し、前記情報処理装置から通知される当該情報処理装置が受信可能なデータ容量に基づいて、取得した前記データを前記情報処理装置に送信するフローコントロール送信管理部と、
    を有する、クライアント機器と、
    前記クライアント機器との間に接続を確立する接続待ち受け部と、
    前記クライアント機器から送信されるデータを受信するデータ受信部と、
    を備え、
    前記データ受信部は、
    前記クライアント機器から送信されるデータが一時保存されるアプリケーションデータ受信バッファと、
    前記クライアント機器から送信された前記データを前記アプリケーションデータ受信バッファから取得して、上位アプリケーションに伝送するアプリケーションデータ受信部と、
    前記アプリケーションデータ受信バッファの空き容量を監視して当該アプリケーションデータ受信バッファが受信可能なデータ容量を前記クライアント機器に通知するとともに、前記クライアント機器から送信されたデータを前記アプリケーションデータ受信バッファへと転送するフローコントロール受信管理部と、
    を有する情報処理装置と、
    を含む、情報処理システム。
15. 前記クライアント機器が有する前記データ送信部は、前記情報処理装置と確立された接続を維持する接続維持用制御情報を送信する接続維持用制御情報送信部を更に備え、
    前記接続維持用制御情報送信部は、前記情報処理装置との間で所定時間通信を行っていない場合に、前記接続維持用制御情報を前記情報処理装置に対して送信する、請求項１４に記載の情報処理システム。
16. 前記情報処理装置は、前記クライアント機器に対してデータを送信するデータ送信部を更に備え、
    前記データ送信部は、
    前記クライアント機器に対して送信されるデータが一時保存されるアプリケーションデータ送信バッファと、
    前記クライアント機器に対して送信されるデータを上位アプリケーションから取得して、前記アプリケーションデータ送信バッファに伝送するアプリケーションデータ送信部と、
    前記アプリケーションデータ送信バッファから前記データを取得し、前記クライアント機器から通知される当該クライアント機器が受信可能なデータ容量に基づいて、取得した前記データを前記クライアント機器に送信するフローコントロール送信管理部と、
    を有し、
    前記クライアント機器は、前記情報処理装置から送信されるデータを受信するデータ受信部を更に備え、
    前記データ受信部は、
    前記情報処理装置から送信されるデータが一時保存されるアプリケーションデータ受信バッファと、
    前記情報処理装置から送信された前記データを前記アプリケーションデータ受信バッファから取得して、上位アプリケーションに伝送するアプリケーションデータ受信部と、
    前記アプリケーションデータ受信バッファの空き容量を監視して当該アプリケーションデータ受信バッファが受信可能なデータ容量を前記情報処理装置に通知するとともに、前記情報処理装置から送信されたデータを前記アプリケーションデータ受信バッファへと転送するフローコントロール受信管理部と、
    を有する、請求項１４に記載の情報処理システム。
    

Images