JP4701265B2 - 送信端末及びデータ送信方法 - Google Patents

Description

送信バッファに蓄積されているデータを所定のフロー制御に基づいて送信する送信端末及びデータ送信方法。

一般に、広域通信回線網や狭域通信回線網などの通信回線網において、送信元の端末と送信先の端末との間における通信（エンド・ツー・エンドの通信）は、当該通信回線網上に設置されているサーバ・プロキシサーバ・ゲートウェイ等（以下、サーバ等）を経由して行われる。このとき、サーバ等は、当該通信回線網上において、ＴＣＰに基づいた通信のフロー制御を行う終端端末として機能する。また、サーバ等（終端端末）における所定のフロー制御は、ＴＣＰ層における所定の処理を行うＴＣＰ処理部によって行われている。

以下において、送信元の端末（送信端末）から送信先の端末（受信端末）に所定のデータが送信される方法、及び、ＴＣＰ処理部によって行われる所定のフロー制御について、図面を参照しながら説明する。

図５は、送信端末から受信端末に所定のデータが送信される方法について示す図である。図５に示すように、送信端末は、各階層における所定のプロトコルに従って、所定のデータを受信端末に送信する。具体的には、送信端末は、アプリケーション層における処理を行うアプリケーション処理部において所定のデータを生成し、トランスポート層における処理を行うトランスポート処理部において所定のデータにトランスポートヘッダ（ＴＨ）を付加することによってセグメントを生成し、ネットワーク層における処理を行うネットワーク処理部においてセグメントにネットワークヘッダ（ＮＨ）を付加することによってデータグラムを生成し、データリンク層・物理層における処理を行うデータリンク処理部においてデータグラムにデータリンクヘッダ（ＤＨ）を付加することによってフレームを生成するとともに、当該フレームを受信端末に送信する。また、受信端末は、送信端末とは逆の処理を行うことにより、アプリケーション処理部において所定のデータを取得する。

図６は、送信端末のＴＣＰ処理部及び受信端末のＴＣＰ処理部において行われるフロー制御を示すシーケンス図である。図６（ａ）は、データの送信が正常に行われるときのフロー制御を示すシーケンス図である。

図６（ａ）に示すように、ステップ１０１ａにおいて、送信端末は、各階層において所定のヘッダが付加されたデータ（１）を送信し、ステップ１０１ｂにおいて、受信端末は、当該データ（１）を受信する。

ステップ１０２ａにおいて、受信端末は、データ（１）を受信したことを示す応答信号（ＡＣＫ（１））を送信し、ステップ１０２ｂにおいて、送信端末は、当該応答信号（ＡＣＫ（１））を受信する。

ステップ１０３において、送信端末は、データを送信する周期（送信周期）を短くしたり、データを送信する速度（送信レート）を上げたりする。

一方、図６（ｂ）は、データの送信が正常に行われないときのフロー制御を示すシーケンス図である。

図６（ｂ）に示すように、ステップ１０４ａにおいて、送信端末は、各階層において所定のヘッダが付加されたデータ（２）を送信し、ステップ１０４ｂにおいて、受信端末は、当該データ（２）を受信する。

ステップ１０５において、受信端末は、データ（２）を受信したことを示す応答信号（ＡＣＫ（３））を送信する。

ステップ１０６において、送信端末は、データ（２）を送信してから所定の時間が経過しても応答信号（ＡＣＫ（３））が届かないため、データを送信する周期（送信周期）を長くしたり、データを送信する速度（送信レート）を下げたりする。

以上説明したように、送信端末のＴＣＰ処理部は、受信端末からの応答信号（ＡＣＫ）に基づいて、所定のフロー制御を行っているが、送信端末のアプリケーション処理部は、予め設定されている所定の蓄積データ量で所定のデータをＴＣＰ処理部に送信するのみで、フロー制御を行っていなかった。

一方、ウィンドウスケールと呼ばれる新しいパラメータを用いて、大きなウィンドウデータサイズを実現すること（拡張されたＴＣＰ）によって、通信回線網上における遅延が大きい場合において、スループットの向上を図る方法が提案されている。また、通信回線網上における遅延が大きい場合において、スループットの向上を図る方法として、トランスポート層における独自のプロトコルを用いて通信のフロー制御を行う方法も提案されている（特開平７−２５０１００号公報）。
特開平７−２５０１００号公報

しかしながら、サーバ等のＴＣＰ処理部は、送信バッファの空き容量が予め設定されている所定の蓄積データ量よりも小さい場合には、当該送信バッファに空き容量があるにもかかわらず、送信バッファにデータを蓄積することができないエラー（No Buffer Error）が発生したものと判断してしまい、データの送信が完全に停止してしまうという問題があった。

なお、サーバ等の送信バッファでオーバーフローが発生しやすい場合としては、高速通信回線網を介して受信したデータを低速通信回線網上にサーバ等が送信する場合、サーバ等の処理速度が遅い場合などが考えられる。

また、ウィンドウスケールや独自のプロトコルを用いて、スループットの向上を図る方法においては、拡張されたＴＣＰや独自のプロトコルを、通信を行う終端端末（送信元の端末・送信先の端末・サーバ等）の双方に導入しなければならないという問題があった。

さらに、サーバ等は、通信が行われていない時間が所定の時間（以下、キープアライブタイム）を超える（タイムアウトが発生する）と、サーバ等の間における通信の接続を切断する機能（キープアライブ機能）を具備しているが、通信回線網上に無線通信区間がある場合には、無線リソースが無駄に使用されることを回避するために、当該キープアライブタイムが短く設定される場合がある。このとき、すぐに回復可能な輻輳やわずかなパケットの消失などが発生しただけで、タイムアウトが発生する可能性が大きくなるという問題があった。

本発明は、上述の問題を解決すべくなされたものであり、拡張されたＴＣＰや独自のプロトコルを、通信を行う終端端末（送信元の端末・送信先の端末・サーバ等）の双方に導入する必要がなく、サーバ等の送信バッファの空き容量が予め設定されている所定の蓄積データ量よりも小さい場合であっても、送信バッファに空き容量が少しでもある場合には、当該送信バッファに所定のデータを蓄積することにより、所定のデータの送信が完全に停止する可能性を軽減することができる送信端末及びデータ送信方法を提供することを目的とする。

また、本発明は、キープアライブタイムが短く設定されている場合であっても、タイムアウトが発生する可能性を軽減することができる送信端末及びデータ送信方法を提供することを目的とする。

本発明の第１の特徴は、アプリケーション層における所定の処理を行うアプリケーション処理部と、トランスポート層における所定の処理を行うトランスポート処理部とを具備する端末装置において、トランスポート処理部が、アプリケーション処理部から受信した所定のデータを送信バッファに蓄積し、蓄積された所定のデータを所定のフロー制御に基づいて送信し、アプリケーション処理部が、トランスポート処理部によって通知された送信バッファの空き容量に応じて、所定のデータをトランスポート処理部に送信することを要旨とする。

かかる特徴によれば、アプリケーション処理部が、送信バッファの空き容量に応じて、所定のデータをトランスポート処理部に送信することにより、端末装置は、送信バッファに空き容量が少しでもあれば、送信バッファに所定のデータを蓄積するとともに、送信バッファに蓄積されている所定のデータを送信することができる（所定のデータの送信が完全に停止する可能性を軽減できる）。

また、端末装置は、キープアライブタイムが短く設定されている場合であっても、送信バッファの空き容量が少しでもあれば、所定のデータを送信バッファに蓄積するとともに、送信バッファに蓄積されているデータを送信する（通信の接続が維持される）ことにより、タイムアウトが発生する可能性を軽減することができる。

本発明の第２の特徴は、本発明の第１の特徴において、アプリケーション処理部が、トランスポート処理部によって通知された送信バッファの空き容量よりも小さいデータ量で、所定のデータをトランスポート処理部に送信することを要旨とする。

かかる特徴によれば、アプリケーション処理部が、送信バッファの空き容量よりも小さいデータ量で、所定のデータをトランスポート処理部に送信することにより、端末装置は、緊急時に使用する目的などのために、送信バッファの空き容量を確保することができる。

本発明の第３の特徴は、本発明の第１の特徴又は第２の特徴において、トランスポート処理部が、アプリケーション処理部から受信した所定のデータを送信バッファに蓄積することができないときに、送信バッファの空き容量をアプリケーション処理部に通知することを要旨とする。

かかる特徴によれば、トランスポート処理部が、所定のデータを送信バッファに蓄積することができないときに、当該送信バッファの空き容量をアプリケーション処理部に送信することにより、端末装置は、必要なときに送信バッファの空き容量を確認することができる。

本発明の第４の特徴は、本発明の第１の特徴乃至第３の特徴のいずれかにおいて、アプリケーション処理部が、トランスポート処理部によって通知された送信バッファの空き容量に応じて、所定のデータをトランスポート処理部に送信する周期を変更することを特徴とする。

かかる特徴によれば、アプリケーション処理部が、例えば、送信バッファの空き容量が“０”である場合に、所定のデータをトランスポート処理部に送信する周期を長くし、送信バッファの空き容量が予め設定されている所定の蓄積データ量よりも大きい場合に、所定のデータをトランスポート処理部に送信する周期を短くすることにより、端末装置は、送信バッファにおいて発生したオーバーフローの解消を図るとともに、スループットの向上を図ることができる。

本発明の第５の特徴は、本発明の第１の特徴又は第４の特徴のいずれかの特徴において、アプリケーション処理部が、トランスポート処理部から所定のデータを受信し、通知された送信バッファの空き容量に応じて、当該所定のデータをトランスポート処理部に送信することを要旨とする。

かかる特徴によれば、所定のデータを転送する端末装置（例えば、プロキシサーバ）は、送信バッファに空き容量が少しでもあれば、送信バッファに所定のデータを蓄積するとともに、送信バッファに蓄積されている所定のデータを転送することができる。

本発明の第６の特徴は、トランスポート層における所定の処理を行うトランスポート処理部が、アプリケーション層における所定の処理を行うアプリケーション処理部から受信した所定のデータを送信バッファに蓄積し、蓄積された所定のデータを所定のフロー制御に基づいて送信するステップと、アプリケーション処理部が、トランスポート処理部によって通知された送信バッファの空き容量に応じて、所定のデータをトランスポート処理部に送信するステップとをデータ送信方法が具備することを要旨とする。

本発明によれば、サーバ等の送信バッファの空き容量が予め設定されている所定の蓄積データ量よりも小さい場合であっても、送信バッファに空き容量が少しでもある場合には、当該送信バッファに所定のデータを蓄積することにより、データの送信が完全に停止する可能性を既存のＴＣＰを用いて軽減することができる送信端末及びデータ送信方法を提供することができる。

以下において、本実施形態における端末装置の構成について、図面を参照しながら説明する。なお、本実施形態において、端末装置は、プロキシサーバであるものとして説明するが、これに限定されるものではなく、通信回線網上に所定のデータを送信する端末（サーバ・ゲートウェイなど）であってもよいものとする。

（プロキシサーバの構成）
図１は、本実施形態におけるプロキシサーバ２０が設置されている環境を説明するための図である。

図１に示すように、プロキシサーバ２０は、高速通信回線網（以下、ＷＡＮ１）を介してサーバ１０との通信を行い、低速通信回線網（以下、ＬＡＮ２）を介して、クライアント端末３０との通信を行う。

なお、本実施形態において、プロキシサーバ２０は、サーバ１０から受信したデータをクライアント端末３０に送信するものとして説明する。

図２は、本実施形態におけるプロキシサーバ２０の構成を示すブロック図である。図２に示すように、プロキシサーバ２０は、受信部２１と、データリンク・物理処理部２２と、ネットワーク処理部２３と、ＴＣＰ処理部２４と、ＴＣＰ受信バッファ２５と、ＴＣＰ送信バッファ２６と、アプリケーション処理部２７と、アプリケーションバッファ２８と、送信部２９とを具備する。

受信部２１は、サーバ１０によって送信されたデータを、ＷＡＮ１を介して受信する。

データリンク・物理処理部２２は、ＰＰＰ（Point to Point Protocol）などのプロトコルに基づいて、物理層・データリンク層における所定の処理を行う。具体的には、データリンク・物理処理部２２は、受信部２１が受信したデータをネットワーク処理部２３に送信し、ネットワーク処理部２３から受信したデータを受信部２１に送信する。

ネットワーク処理部２３は、ＩＰ（Internet Protocol）などのプロトコルに基づいて、ネットワーク層における所定の処理を行う。具体的には、ネットワーク処理部２３は、ネットワーク処理部２３から受信したデータをＴＣＰ処理部２４に送信し、ＴＣＰ処理部２４から受信したデータをネットワーク処理部２３に送信する。

ＴＣＰ処理部２４は、ＴＣＰに基づいて、ＴＣＰ層における処理を行う。具体的には、ＴＣＰ処理部２４は、ネットワーク処理部２３から受信したデータをＴＣＰ受信バッファ２５に蓄積し、ＴＣＰ受信バッファ２５に蓄積されているデータをアプリケーション処理部２７に送信する。

また、ＴＣＰ処理部２４は、アプリケーション処理部２７から受信したデータをＴＣＰ送信バッファ２６に蓄積し、ＴＣＰ送信バッファ２６に蓄積されているデータを所定のフロー制御に基づいてネットワーク処理部２３に送信する。

さらに、ＴＣＰ処理部２４は、アプリケーション処理部２７から受信したデータをＴＣＰ送信バッファ２６に蓄積することができない場合には、そのことを示すエラー信号（No Buffer Error 信号）と、ＴＣＰ送信バッファ２６の空き容量を示す空き容量情報（例えば、“Available Buffer Size 300 Byte”）とをアプリケーション処理部２７に送信する。

ＴＣＰ受信バッファ２５には、ネットワーク処理部２３から受信したデータが蓄積されている。

ＴＣＰ送信バッファ２６には、アプリケーション処理部２７から受信したデータが蓄積されている。

アプリケーション処理部２７は、予め設定されている所定の蓄積データ量（例えば、1000 Byte）で、アプリケーションバッファ２８に蓄積されているデータをＴＣＰ処理部２４に送信する。

また、アプリケーション処理部２７は、ＴＣＰ処理部２４から受信したＴＣＰ送信バッファ２６の空き容量を示す空き容量情報（例えば、“Available Buffer Size 300 Byte”）に応じたデータ量（300 Byte）で、アプリケーションバッファ２８に蓄積されているデータをＴＣＰ送信バッファ２６に送信する。

なお、アプリケーション処理部２７は、ＴＣＰ処理部２４から受信した空き容量情報（例えば、“Available Buffer Size 300 Byte”）によって示されるＴＣＰ送信バッファ２６の空き容量（300 Byte）よりも小さいデータ量（例えば、200 Byte）で、アプリケーションバッファ２８に蓄積されているデータをＴＣＰ処理部２４に送信するように構成されていてもよい。

さらに、アプリケーション処理部２７は、ＴＣＰ処理部２４から受信した空き容量情報（例えば、“Available Buffer Size 300 Byte”）に応じて、アプリケーションバッファ２８に蓄積されているデータをＴＣＰ処理部２４に送信する周期（アプリケーションバッファ２８に蓄積されているデータをＴＣＰ送信バッファ２６に蓄積する周期（以下、蓄積周期））を変更する。

アプリケーションバッファ２８には、ＴＣＰ処理部２４から受信したデータが蓄積されている。

送信部２９は、データリンク・物理処理部２２から受信したデータを、ＬＡＮ２を介してクライアント端末３０に送信する。

なお、本実施形態において、ＴＣＰ処理部２４は、アプリケーション処理部２７から受信した所定のデータをＴＣＰ送信バッファ２６に蓄積し、蓄積された所定のデータを所定のフロー制御に基づいて送信するトランスポート処理部を構成し、アプリケーション処理部２７は、ＴＣＰ処理部２４によって通知されたＴＣＰ送信バッファ２６の空き容量に応じて所定のデータをＴＣＰ処理部２４に送信するアプリケーション処理部を構成する。

（プロキシサーバの動作）
以下において、本実施形態におけるプロキシサーバ２０の動作について、図面を参照しながら説明する。

図３は、本実施形態におけるデータ蓄積処理を示すフロー図である。なお、データ蓄積処理とは、プロキシサーバ２０がアプリケーションバッファ２８に蓄積されているデータを、ＬＡＮ２を介してクライアント端末３０に送信する際に、アプリケーションバッファ２８に蓄積されているデータをＴＣＰ送信バッファ２６に蓄積する処理である。また、データ蓄積処理は、所定の周期（蓄積周期）で繰り返されるものである。

図３に示すように、ステップ２０において、プロキシサーバ２０は、ＴＣＰ送信バッファ２６の空き容量が“０”であるか否か確認する。また、プロキシサーバ２０は、ＴＣＰ送信バッファ２６の空き容量が“０”である場合には、ステップ２１の処理に移り、ＴＣＰ送信バッファ２６の空き容量が“０”でない場合には、ステップ２２の処理に移る。

ステップ２１において、プロキシサーバ２０は、上限となる長さを限度として蓄積周期を長くする。

ステップ２２において、プロキシサーバ２０は、予め設定されている所定の蓄積データ量（例えば、1000 Byte）がＴＣＰ送信バッファ２６の空き容量以下であるか否か確認する。また、プロキシサーバ２０は、予め設定されている所定の蓄積データ量（例えば、1000 Byte）がＴＣＰ送信バッファ２６の空き容量以下である場合には、ステップ２４の処理に移り、予め設定されている所定の蓄積データ量（例えば、1000 Byte）がＴＣＰ送信バッファ２６の空き容量よりも大きい場合には、ステップ２３の処理に移る。

ステップ２３において、プロキシサーバ２０は、ＴＣＰ送信バッファ２６の空き容量（例えば、300 Byte）に応じたデータ量（例えば、300 Byte）で、アプリケーションバッファ２８に蓄積されているデータをＴＣＰ送信バッファ２６に蓄積する。

なお、プロキシサーバ２０は、ＴＣＰ送信バッファ２６の空き容量（例えば、300 Byte）よりも小さいデータ量（例えば、200 Byte）で、アプリケーションバッファ２８に蓄積されているデータをＴＣＰ送信バッファ２６に蓄積するように構成されていてもよい。

ステップ２４において、プロキシサーバ２０は、予め設定されている所定の蓄積データ量（例えば、1000 Byte）で、アプリケーションバッファ２８に蓄積されているデータをＴＣＰ送信バッファ２６に蓄積する。

ステップ２５において、プロキシサーバ２０は、下限となる長さを限度として蓄積周期を短くする。

なお、本実施形態において、プロキシサーバ２０は、ステップ２１及びステップ２５において蓄積周期を変更するように構成されているが、蓄積周期を変更しない（ステップ２１及びステップ２５の処理を行わない）ように構成されていてもよい。

以下において、上述のデータ蓄積処理において、アプリケーション処理部２７とＴＣＰ処理部２４との間で行われる処理について説明する。図４は、本実施形態におけるアプリケーション処理部２７とＴＣＰ処理部２４との間で行われる処理を示すシーケンス図である。

図４に示すように、ステップ１０ａにおいて、ＴＣＰ処理部２４は、ＴＣＰ受信バッファ２５に蓄積されているデータ（０）をアプリケーション処理部２７に送信し、ステップ１０ｂにおいて、アプリケーション処理部２７は、当該データ（０）を受信する。

なお、ＴＣＰ受信バッファ２５に蓄積されているデータ（０）は、ネットワーク処理部２３及びデータリンク・物理処理部２２を介して、受信部２１から受信したデータである。

ステップ１１ａにおいて、アプリケーション処理部２７は、予め設定されている所定の蓄積データ量（例えば、1000 byte）で、アプリケーションバッファ２８に蓄積されているデータ（１）をＴＣＰ処理部２４に送信し、ステップ１１ｂにおいて、ＴＣＰ処理部２４は、当該データ（１）を受信する。

ステップ１２において、ＴＣＰ処理部２４は、アプリケーション処理部２７から受信したデータ（１）のデータ量（例えば、1000 Byte）がＴＣＰ送信バッファ２６の空き容量以下であるか否か確認する。また、ＴＣＰ処理部２４は、受信したデータ（１）のデータ量（例えば、1000 Byte）がＴＣＰ送信バッファ２６の空き容量以下である場合には、ステップ１５の処理に移り、受信したデータ（１）のデータ量（例えば、1000 Byte）がＴＣＰ送信バッファ２６の空き容量よりも大きい場合には、ステップ１３ａの処理に移る。

ステップ１３ａにおいて、ＴＣＰ処理部２４は、予め設定されている所定の蓄積データ量（例えば、1000 Byte）で、アプリケーション処理部２７から受信したデータ（１）をＴＣＰ送信バッファ２６に蓄積することができないことを示すエラー信号（No Buffer Error信号）と、ＴＣＰ送信バッファ２６の空き容量を示す空き容量情報（例えば、“Available Buffer Size 0 Byte”や“Available Buffer Size 300 Byte”）とをアプリケーション処理部２７に送信し、ステップ１３ｂにおいて、アプリケーション処理部２７は、当該エラー信号（No Buffer Error信号）と当該空き容量情報（例えば、“Available Buffer Size 0 Byte”や“Available Buffer Size 300 Byte”）とを受信する。

ステップ１４ａにおいて、アプリケーション処理部２７は、ステップ１３ｂで受信した空き容量情報（例えば、“Available Buffer Size 300 Byte”）に応じたデータ量（例えば、300 Byte）で、アプリケーションバッファ２８に蓄積されているデータ（２）をＴＣＰ処理部２４に送信し、ステップ１４ｂにおいて、ＴＣＰ処理部２４は、当該データ（２）を受信する。

なお、アプリケーション処理部２７は、ステップ１３ｂで受信した空き容量情報（例えば、“Available Buffer Size 300 Byte”）によって示されるＴＣＰ送信バッファ２６の空き容量（300 Byte）よりも小さいデータ量（例えば、200 Byte）で、アプリケーションバッファ２８に蓄積されているデータをＴＣＰ処理部２４に送信するように構成されていてもよい。

ステップ１５において、ＴＣＰ処理部２４は、ステップ１１ｂで受信したデータ（１）、又は、ステップ１４ｂで受信したデータ（２）をＴＣＰ送信バッファ２６に蓄積する。

ステップ１６において、ＴＣＰ処理部２４は、所定のフロー制御に基づいて、ＴＣＰ送信バッファ２６に蓄積されているデータを、ネットワーク処理部２３及びデータリンク・物理処理部２２を介して送信部２９に送信する。

ステップ１７において、アプリケーション処理部２７は、アプリケーションバッファ２８に蓄積されているデータをＴＣＰ処理部２４に送信する周期（アプリケーションバッファ２８に蓄積されているデータをＴＣＰ送信バッファ２６に蓄積しようとする周期（蓄積周期））を変更する。具体的には、アプリケーション処理部２７は、ＴＣＰ処理部２４からエラー信号（No Buffer Error信号）を受信しなかった場合には、下限となる長さを限度として、蓄積周期を短くする。また、アプリケーション処理部２７は、ステップ１３ｂで空き容量情報（“Available Buffer Size 0 Byte”）を受信した場合には、上限となる長さを限度として、蓄積周期を長くする。

なお、アプリケーション処理部２７は、ステップ１３ｂで空き容量情報（“Available Buffer Size 300 Byte”）を受信した場合に、当該空き容量情報に応じて、蓄積周期を変更してもよい。

また、本実施形態において、アプリケーション処理部２７は、ステップ１７において蓄積周期を変更するように構成されているが、蓄積周期を変更しない（ステップ１７の処理を行わない）ように構成されていてもよい。

（プロキシサーバの作用、及び、効果）
本実施形態におけるプロキシサーバ２０によれば、アプリケーション処理部２７が、ＴＣＰ送信バッファ２６の空き容量に応じて、アプリケーションバッファ２８に蓄積されているデータをＴＣＰ処理部２４に送信することにより、プロキシサーバ２０は、ＴＣＰ送信バッファ２６に空き容量が少しでもあれば、アプリケーションバッファ２８に蓄積されているデータをＴＣＰ送信バッファ２６に蓄積するとともに、ＴＣＰ送信バッファ２６に蓄積されているデータを、ＬＡＮ２を介してクライアント端末３０に送信することができる（データの送信が完全に停止する可能性を軽減できる）。

また、プロキシサーバ２０は、キープアライブタイムが短く設定されている場合であっても、ＴＣＰ送信バッファ２６の空き容量が少しでもあれば、ＴＣＰ受信バッファ２５に蓄積されているデータをＴＣＰ送信バッファ２６に蓄積するとともに、ＴＣＰ送信バッファ２６に蓄積されているデータを、ＬＡＮ２を介してクライアント端末３０に送信する（通信の接続が維持される）ことにより、タイムアウトが発生する可能性を軽減することができる。

さらに、ＴＣＰ処理部２４が、アプリケーションバッファ２８に蓄積されているデータをＴＣＰ送信バッファ２６に蓄積することができないときに、当該ＴＣＰ送信バッファ２６の空き容量をアプリケーション処理部２７に送信することにより、プロキシサーバ２０は、必要なときにＴＣＰ送信バッファ２６の空き容量を確認することができる。

また、アプリケーション処理部２７が、ＴＣＰ送信バッファ２６の空き容量が“０”である場合には、蓄積周期を長くし、ＴＣＰ送信バッファ２６の空き容量が予め設定されている所定の蓄積データ量（例えば、1000 Byte）よりも大きい場合には、蓄積周期を短くすることにより、プロキシサーバ２０は、ＴＣＰ送信バッファ２６において発生したオーバーフローの解消を図るとともに、スループットの向上を図ることができる。

本実施形態におけるプロキシサーバ２０が設置されている環境を説明するための図である。 本実施形態におけるプロキシサーバ２０の構成を示すブロック図である。 本実施形態におけるプロキシサーバ２０の動作を示す図である。 本実施形態におけるアプリケーション処理部２７とＴＣＰ処理部２４との間で行われる処理を示すシーケンス図である。 送信端末から受信端末に所定のデータが送信される方法について示す図である。 送信端末のＴＣＰ処理部及び受信端末のＴＣＰ処理部において行われるフロー制御を示すシーケンス図である。

符号の説明

１…ＷＡＮ、２…ＬＡＮ、１０…サーバ、２０…プロキシサーバ、２１…受信部、２２…データリンク・物理処理部、２３…ネットワーク処理部、２４…ＴＣＰ処理部、２５…ＴＣＰ受信バッファ、２６…ＴＣＰ送信バッファ、２７…アプリケーション処理部、２８…アプリケーションバッファ、２９…送信部、３０…クライアント端末

Claims (4)

1. アプリケーション層における所定の処理を行うアプリケーション処理部と、前記アプリケーション層よりも下位のトランスポート層における所定の処理を行うトランスポート処理部とを具備しており、受信端末にデータを送信する送信端末であって、
   前記アプリケーション処理部は、所定データ量のデータを前記トランスポート処理部に送信し、
   前記トランスポート処理部は、前記アプリケーション処理部から受信したデータを送信バッファに蓄積し、前記送信バッファに蓄積されたデータを前記受信端末に送信し、
   前記トランスポート処理部は、前記受信端末がデータの受信に成功したか否かに基づいて、前記受信端末に送信するデータのフロー制御を行い、
   前記トランスポート処理部は、前記アプリケーション処理部から受信した前記所定データ量のデータを前記送信バッファに蓄積することができない場合に、エラー信号とともに、前記送信バッファの空き容量を前記アプリケーション処理部に通知し、
   前記アプリケーション処理部は、前記トランスポート処理部によって前記エラー信号とともに通知された前記送信バッファの空き容量に応じて、前記送信バッファの空き容量以下のデータを前記トランスポート処理部に送信し、前記トランスポート処理部にデータを送信する送信周期を変更することを特徴とする送信端末。
2. 前記アプリケーション処理部は、前記送信バッファの空き容量が前記所定データ量よりも小さい場合に、前記送信周期を長くすることを特徴とする請求項１に記載の送信端末。
3. 前記アプリケーション処理部は、前記送信バッファの空き容量が前記所定データ量よりも大きい場合に、前記送信周期を短くすることを特徴とする請求項１に記載の送信端末。
4. アプリケーション層における所定の処理を行うアプリケーション処理部が、前記アプリケーション層よりも下位のトランスポート層における所定の処理を行うトランスポート処理部に、所定のデータ量のデータを送信するステップと、
   前記トランスポート処理部が、前記受信端末がデータの受信に成功したか否かに基づいて、前記受信端末に送信するデータのフロー制御を行うステップと、
   前記トランスポート処理部が、前記アプリケーション処理部から受信した前記所定データ量のデータを送信バッファに蓄積し、前記送信バッファに蓄積されたデータを受信端末に送信するステップと、
   前記トランスポート処理部が、前記アプリケーション処理部から受信した前記所定データ量のデータを前記送信バッファに蓄積することができない場合に、エラー信号とともに、前記送信バッファの空き容量を前記アプリケーション処理部に通知するステップと、
   前記アプリケーション処理部が、前記トランスポート処理部によって前記エラー信号とともに通知された前記送信バッファの空き容量に応じて、前記送信バッファの空き容量以下のデータを前記トランスポート処理部に送信し、前記トランスポート処理部にデータを送信する送信周期を変更するデータ送信方法。

Images