(57)【要約】【課題】サーバ等の送信バッファの空き容量が予め設定されている所定の蓄積データ量よりも小さい場合であっても、送信バッファに空き容量が少しでもある場合には、当該送信バッファにデータを蓄積することにより、データの送信が完全に停止する可能性を既存のＴＣＰを用いて軽減することができる端末装置及びデータ送信方法を提供する。【解決手段】端末装置がトランスポート処理部とアプリケーション処理部とを具備する端末装置において、トランスポート処理部が、アプリケーション処理部から受信した所定のデータを送信バッファに蓄積し、蓄積された所定のデータを所定のフロー制御に基づいて送信し、アプリケーション処理部が、トランスポート処理部によって通知された送信バッファの空き容量に応じて、所定のデータをトランスポート処理部に送信する。【選択図】  図４
2005044047.tif 000002
【特許請求の範囲】
【請求項１】
アプリケーション層における所定の処理を行うアプリケーション処理部と、トランスポート層における所定の処理を行うトランスポート処理部とを具備する端末装置であって、
前記トランスポート処理部は、前記アプリケーション処理部から受信した所定のデータを送信バッファに蓄積し、蓄積された前記所定のデータを所定のフロー制御に基づいて送信し、
前記アプリケーション処理部は、前記トランスポート処理部によって通知された前記送信バッファの空き容量に応じて、前記所定のデータを前記トランスポート処理部に送信することを特徴とする端末装置。
【請求項２】
前記アプリケーション処理部は、前記トランスポート処理部によって通知された前記送信バッファの空き容量よりも小さいデータ量で、前記所定のデータを前記トランスポート処理部に送信することを特徴とする請求項１に記載の端末装置。
【請求項３】
前記トランスポート処理部は、前記アプリケーション処理部から受信した前記所定のデータを前記送信バッファに蓄積することができないときに、前記送信バッファの空き容量を前記アプリケーション処理部に通知することを特徴とする請求項１又は請求項２に記載の端末装置。
【請求項４】
前記アプリケーション処理部は、前記トランスポート処理部によって通知された前記送信バッファの空き容量に応じて、前記所定のデータを前記トランスポート処理部に送信する周期を変更することを特徴とする請求項１乃至請求項３のいずれかに記載の端末装置。
【請求項５】
前記アプリケーション処理部は、前記トランスポート処理部から前記所定のデータを受信し、通知された前記送信バッファの空き容量に応じて、当該所定のデータを前記トランスポート処理部に送信することを特徴とする請求項１乃至請求項４のいずれかに記載の端末装置。
【請求項６】
トランスポート層における所定の処理を行うトランスポート処理部が、アプリケーション層における所定の処理を行うアプリケーション処理部から受信した所定のデータを送信バッファに蓄積し、蓄積された前記所定のデータを所定のフロー制御に基づいて送信するステップと、
前記アプリケーション処理部が、前記トランスポート処理部によって通知された前記送信バッファの空き容量に応じて、前記所定のデータを前記トランスポート処理部に送信するステップとを具備することを特徴とするデータ送信方法。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
送信バッファに蓄積されているデータを所定のフロー制御に基づいて送信する端末装置、及び、データ送信方法。
【０００２】
【従来の技術】
一般に、広域通信回線網や狭域通信回線網などの通信回線網において、送信元の端末と送信先の端末との間における通信（エンド・ツー・エンドの通信）は、当該通信回線網上に設置されているサーバ・プロキシサーバ・ゲートウェイ等（以下、サーバ等）を経由して行われる。このとき、サーバ等は、当該通信回線網上において、ＴＣＰに基づいた通信のフロー制御を行う終端端末として機能する。また、サーバ等（終端端末）における所定のフロー制御は、ＴＣＰ層における所定の処理を行うＴＣＰ処理部によって行われている。
【０００３】
以下において、送信元の端末（送信端末）から送信先の端末（受信端末）に所定のデータが送信される方法、及び、ＴＣＰ処理部によって行われる所定のフロー制御について、図面を参照しながら説明する。
【０００４】
図５は、送信端末から受信端末に所定のデータが送信される方法について示す図である。図５に示すように、送信端末は、各階層における所定のプロトコルに従って、所定のデータを受信端末に送信する。具体的には、送信端末は、アプリケーション層における処理を行うアプリケーション処理部において所定のデータを生成し、トランスポート層における処理を行うトランスポート処理部において所定のデータにトランスポートヘッダ（ＴＨ）を付加することによってセグメントを生成し、ネットワーク層における処理を行うネットワーク処理部においてセグメントにネットワークヘッダ（ＮＨ）を付加することによってデータグラムを生成し、データリンク層・物理層における処理を行うデータリンク処理部においてデータグラムにデータリンクヘッダ（ＤＨ）を付加することによってフレームを生成するとともに、当該フレームを受信端末に送信する。また、受信端末は、送信端末とは逆の処理を行うことにより、アプリケーション処理部において所定のデータを取得する。
【０００５】
図６は、送信端末のＴＣＰ処理部及び受信端末のＴＣＰ処理部において行われるフロー制御を示すシーケンス図である。図６（ａ）は、データの送信が正常に行われるときのフロー制御を示すシーケンス図である。
【０００６】
図６（ａ）に示すように、ステップ１１１ａにおいて、送信端末は、各階層において所定のヘッダが付加されたデータ（１）を送信し、ステップ１１１ｂにおいて、受信端末は、当該データ（１）を受信する。
【０００７】
ステップ１１２ａにおいて、受信端末は、データ（１）を受信したことを示す応答信号（ＡＣＫ（１））を送信し、ステップ１１２ｂにおいて、送信端末は、当該応答信号（ＡＣＫ（１））を受信する。
【０００８】
ステップ１１３において、送信端末は、データを送信する周期（送信周期）を短くしたり、データを送信する速度（送信レート）を上げたりする。
【０００９】
一方、図６（ｂ）は、データの送信が正常に行われないときのフロー制御を示すシーケンス図である。
【００１０】
図６（ｂ）に示すように、ステップ１１４ａにおいて、送信端末は、各階層において所定のヘッダが付加されたデータ（２）を送信し、ステップ１１４ｂにおいて、受信端末は、当該データ（２）を受信する。
【００１１】
ステップ１１５において、受信端末は、データ（２）を受信したことを示す応答信号（ＡＣＫ（３））を送信する。
【００１２】
ステップ１１６において、送信端末は、データ（２）を送信してから所定の時間が経過しても応答信号（ＡＣＫ（３））が届かないため、データを送信する周期（送信周期）を長くしたり、データを送信する速度（送信レート）を下げたりする。
【００１３】
以上説明したように、送信端末のＴＣＰ処理部は、受信端末からの応答信号（ＡＣＫ）に基づいて、所定のフロー制御を行っているが、送信端末のアプリケーション処理部は、予め設定されている所定の蓄積データ量で所定のデータをＴＣＰ処理部に送信するのみで、フロー制御を行っていなかった。
【００１４】
一方、ウィンドウスケールと呼ばれる新しいパラメータを用いて、大きなウィンドウデータサイズを実現すること（拡張されたＴＣＰ）によって、通信回線網上における遅延が大きい場合において、スループットの向上を図る方法が提案されている。また、通信回線網上における遅延が大きい場合において、スループットの向上を図る方法として、トランスポート層における独自のプロトコルを用いて通信のフロー制御を行う方法も提案されている（特開平７−２５０１００号公報）。
【００１５】
【特許文献１】特開平７−２５０１００号公報
【００１６】
【発明が解決しようとする課題】
しかしながら、サーバ等のＴＣＰ処理部は、送信バッファの空き容量が予め設定されている所定の蓄積データ量よりも小さい場合には、当該送信バッファに空き容量があるにもかかわらず、送信バッファにデータを蓄積することができないエラー（Ｎｏ  Ｂｕｆｆｅｒ  Ｅｒｒｏｒ）が発生したものと判断してしまい、データの送信が完全に停止してしまうという問題があった。
【００１７】
なお、サーバ等の送信バッファでオーバーフローが発生しやすい場合としては、高速通信回線網を介して受信したデータを低速通信回線網上にサーバ等が送信する場合、サーバ等の処理速度が遅い場合などが考えられる。
【００１８】
また、ウィンドウスケールや独自のプロトコルを用いて、スループットの向上を図る方法においては、拡張されたＴＣＰや独自のプロトコルを、通信を行う終端端末（送信元の端末・送信先の端末・サーバ等）の双方に導入しなければならないという問題があった。
【００１９】
さらに、サーバ等は、通信が行われていない時間が所定の時間（以下、キープアライブタイム）を超える（タイムアウトが発生する）と、サーバ等の間における通信の接続を切断する機能（キープアライブ機能）を具備しているが、通信回線網上に無線通信区間がある場合には、無線リソースが無駄に使用されることを回避するために、当該キープアライブタイムが短く設定される場合がある。このとき、すぐに回復可能な輻輳やわずかなパケットの消失などが発生しただけで、タイムアウトが発生する可能性が大きくなるという問題があった。
【００２０】
本発明は、上述の問題を解決すべくなされたものであり、拡張されたＴＣＰや独自のプロトコルを、通信を行う終端端末（送信元の端末・送信先の端末・サーバ等）の双方に導入する必要がなく、サーバ等の送信バッファの空き容量が予め設定されている所定の蓄積データ量よりも小さい場合であっても、送信バッファに空き容量が少しでもある場合には、当該送信バッファに所定のデータを蓄積することにより、所定のデータの送信が完全に停止する可能性を軽減することができる端末装置及びデータ送信方法を提供することを目的とする。
【００２１】
また、本発明は、キープアライブタイムが短く設定されている場合であっても、タイムアウトが発生する可能性を軽減することができる端末装置及びデータ送信方法を提供することを目的とする。
【００２２】
【課題を解決するための手段】
本発明の第１の特徴は、アプリケーション層における所定の処理を行うアプリケーション処理部と、トランスポート層における所定の処理を行うトランスポート処理部とを具備する端末装置において、トランスポート処理部が、アプリケーション処理部から受信した所定のデータを送信バッファに蓄積し、蓄積された所定のデータを所定のフロー制御に基づいて送信し、アプリケーション処理部が、トランスポート処理部によって通知された送信バッファの空き容量に応じて、所定のデータをトランスポート処理部に送信することを要旨とする。
【００２３】
かかる特徴によれば、アプリケーション処理部が、送信バッファの空き容量に応じて、所定のデータをトランスポート処理部に送信することにより、端末装置は、送信バッファに空き容量が少しでもあれば、送信バッファに所定のデータを蓄積するとともに、送信バッファに蓄積されている所定のデータを送信することができる（所定のデータの送信が完全に停止する可能性を軽減できる）。
【００２４】
また、端末装置は、キープアライブタイムが短く設定されている場合であっても、送信バッファの空き容量が少しでもあれば、所定のデータを送信バッファに蓄積するとともに、送信バッファに蓄積されているデータを送信する（通信の接続が維持される）ことにより、タイムアウトが発生する可能性を軽減することができる。
【００２５】
本発明の第２の特徴は、本発明の第１の特徴において、アプリケーション処理部が、トランスポート処理部によって通知された送信バッファの空き容量よりも小さいデータ量で、所定のデータをトランスポート処理部に送信することを要旨とする。
【００２６】
かかる特徴によれば、アプリケーション処理部が、送信バッファの空き容量よりも小さいデータ量で、所定のデータをトランスポート処理部に送信することにより、端末装置は、緊急時に使用する目的などのために、送信バッファの空き容量を確保することができる。
【００２７】
本発明の第３の特徴は、本発明の第１の特徴又は第２の特徴において、トランスポート処理部が、アプリケーション処理部から受信した所定のデータを送信バッファに蓄積することができないときに、送信バッファの空き容量をアプリケーション処理部に通知することを要旨とする。
【００２８】
かかる特徴によれば、トランスポート処理部が、所定のデータを送信バッファに蓄積することができないときに、当該送信バッファの空き容量をアプリケーション処理部に送信することにより、端末装置は、必要なときに送信バッファの空き容量を確認することができる。
【００２９】
本発明の第４の特徴は、本発明の第１の特徴乃至第３の特徴のいずれかにおいて、アプリケーション処理部が、トランスポート処理部によって通知された送信バッファの空き容量に応じて、所定のデータをトランスポート処理部に送信する周期を変更することを特徴とする。
【００３０】
かかる特徴によれば、アプリケーション処理部が、例えば、送信バッファの空き容量が“０”である場合に、所定のデータをトランスポート処理部に送信する周期を長くし、送信バッファの空き容量が予め設定されている所定の蓄積データ量よりも大きい場合に、所定のデータをトランスポート処理部に送信する周期を短くすることにより、端末装置は、送信バッファにおいて発生したオーバーフローの解消を図るとともに、スループットの向上を図ることができる。
【００３１】
本発明の第５の特徴は、本発明の第１の特徴又は第４の特徴のいずれかの特徴において、アプリケーション処理部が、トランスポート処理部から所定のデータを受信し、通知された送信バッファの空き容量に応じて、当該所定のデータをトランスポート処理部に送信することを要旨とする。
【００３２】
かかる特徴によれば、所定のデータを転送する端末装置（例えば、プロキシサーバ）は、送信バッファに空き容量が少しでもあれば、送信バッファに所定のデータを蓄積するとともに、送信バッファに蓄積されている所定のデータを転送することができる。
【００３３】
本発明の第６の特徴は、トランスポート層における所定の処理を行うトランスポート処理部が、アプリケーション層における所定の処理を行うアプリケーション処理部から受信した所定のデータを送信バッファに蓄積し、蓄積された所定のデータを所定のフロー制御に基づいて送信するステップと、アプリケーション処理部が、トランスポート処理部によって通知された送信バッファの空き容量に応じて、所定のデータをトランスポート処理部に送信するステップとをデータ送信方法が具備することを要旨とする。
【００３４】
【発明の実施の形態】
以下において、本実施形態における端末装置の構成について、図面を参照しながら説明する。なお、本実施形態において、端末装置は、プロキシサーバであるものとして説明するが、これに限定されるものではなく、通信回線網上に所定のデータを送信する端末（サーバ・ゲートウェイなど）であってもよいものとする。
【００３５】
（プロキシサーバの構成）
図１は、本実施形態におけるプロキシサーバ２０が設置されている環境を説明するための図である。
【００３６】
図１に示すように、プロキシサーバ２０は、高速通信回線網（以下、ＷＡＮ１）を介してサーバ１０との通信を行い、低速通信回線網（以下、ＬＡＮ２）を介して、クライアント端末３０との通信を行う。
【００３７】
なお、本実施形態において、プロキシサーバ２０は、サーバ１０から受信したデータをクライアント端末３０に送信するものとして説明する。
【００３８】
図２は、本実施形態におけるプロキシサーバ２０の構成を示すブロック図である。図２に示すように、プロキシサーバ２０は、受信部２１と、データリンク・物理処理部２２と、ネットワーク処理部２３と、ＴＣＰ処理部２４と、ＴＣＰ受信バッファ２５と、ＴＣＰ送信バッファ２６と、アプリケーション処理部２７と、アプリケーションバッファ２８と、送信部２９とを具備する。
【００３９】
受信部２１は、サーバ１０によって送信されたデータを、ＷＡＮ１を介して受信する。
【００４０】
データリンク・物理処理部２２は、ＰＰＰ（Ｐｏｉｎｔ  ｔｏ  Ｐｏｉｎｔ  Ｐｒｏｔｏｃｏｌ）などのプロトコルに基づいて、物理層・データリンク層における所定の処理を行う。
具体的には、データリンク・物理処理部２２は、受信部２１が受信したデータをネットワーク処理部２３に送信し、ネットワーク処理部２３から受信したデータを受信部２１に送信する。
【００４１】
ネットワーク処理部２３は、ＩＰ（Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）などのプロトコルに基づいて、ネットワーク層における所定の処理を行う。具体的には、ネットワーク処理部２３は、ネットワーク処理部２３から受信したデータをＴＣＰ処理部２４に送信し、ＴＣＰ処理部２４から受信したデータをネットワーク処理部２３に送信する。
【００４２】
ＴＣＰ処理部２４は、ＴＣＰに基づいて、ＴＣＰ層における処理を行う。具体的には、ＴＣＰ処理部２４は、ネットワーク処理部２３から受信したデータをＴＣＰ受信バッファ２５に蓄積し、ＴＣＰ受信バッファ２５に蓄積されているデータをアプリケーション処理部２７に送信する。
【００４３】
また、ＴＣＰ処理部２４は、アプリケーション処理部２７から受信したデータをＴＣＰ送信バッファ２６に蓄積し、ＴＣＰ送信バッファ２６に蓄積されているデータを所定のフロー制御に基づいてネットワーク処理部２３に送信する。
【００４４】
さらに、ＴＣＰ処理部２４は、アプリケーション処理部２７から受信したデータをＴＣＰ送信バッファ２６に蓄積することができない場合には、そのことを示すエラー信号（Ｎｏ  Ｂｕｆｆｅｒ  Ｅｒｒｏｒ  信号）と、ＴＣＰ送信バッファ２６の空き容量を示す空き容量情報（例えば、“Ａｖａｉｌａｂｌｅ  Ｂｕｆｆｅｒ  Ｓｉｚｅ  ３００  Ｂｙｔｅ”）とをアプリケーション処理部２７に送信する。
【００４５】
ＴＣＰ受信バッファ２５には、ネットワーク処理部２３から受信したデータが蓄積されている。
【００４６】
ＴＣＰ送信バッファ２６には、アプリケーション処理部２７から受信したデータが蓄積されている。
【００４７】
アプリケーション処理部２７は、予め設定されている所定の蓄積データ量（例えば、１０００  Ｂｙｔｅ）で、アプリケーションバッファ２８に蓄積されているデータをＴＣＰ処理部２４に送信する。
【００４８】
また、アプリケーション処理部２７は、ＴＣＰ処理部２４から受信したＴＣＰ送信バッファ２６の空き容量を示す空き容量情報（例えば、“Ａｖａｉｌａｂｌｅ  Ｂｕｆｆｅｒ  Ｓｉｚｅ  ３００  Ｂｙｔｅ”）に応じたデータ量（３００  Ｂｙｔｅ）で、アプリケーションバッファ２８に蓄積されているデータをＴＣＰ送信バッファ２６に送信する。
【００４９】
なお、アプリケーション処理部２７は、ＴＣＰ処理部２４から受信した空き容量情報（例えば、“Ａｖａｉｌａｂｌｅ  Ｂｕｆｆｅｒ  Ｓｉｚｅ  ３００  Ｂｙｔｅ”）によって示されるＴＣＰ送信バッファ２６の空き容量（３００  Ｂｙｔｅ）よりも小さいデータ量（例えば、２００  Ｂｙｔｅ）で、アプリケーションバッファ２８に蓄積されているデータをＴＣＰ処理部２４に送信するように構成されていてもよい。
【００５０】
さらに、アプリケーション処理部２７は、ＴＣＰ処理部２４から受信した空き容量情報（例えば、“Ａｖａｉｌａｂｌｅ  Ｂｕｆｆｅｒ  Ｓｉｚｅ  ３００  Ｂｙｔｅ”）に応じて、アプリケーションバッファ２８に蓄積されているデータをＴＣＰ処理部２４に送信する周期（アプリケーションバッファ２８に蓄積されているデータをＴＣＰ送信バッファ２６に蓄積する周期（以下、蓄積周期））を変更する。
【００５１】
アプリケーションバッファ２８には、ＴＣＰ処理部２４から受信したデータが蓄積されている。
【００５２】
送信部２９は、データリンク・物理処理部２２から受信したデータを、ＬＡＮ２を介してクライアント端末３０に送信する。
【００５３】
なお、本実施形態において、ＴＣＰ処理部２４は、アプリケーション処理部２７から受信した所定のデータをＴＣＰ送信バッファ２６に蓄積し、蓄積された所定のデータを所定のフロー制御に基づいて送信するトランスポート処理部を構成し、アプリケーション処理部２７は、ＴＣＰ処理部２４によって通知されたＴＣＰ送信バッファ２６の空き容量に応じて所定のデータをＴＣＰ処理部２４に送信するアプリケーション処理部を構成する。
【００５４】
（プロキシサーバの動作）
以下において、本実施形態におけるプロキシサーバ２０の動作について、図面を参照しながら説明する。
【００５５】
図３は、本実施形態におけるデータ蓄積処理を示すフロー図である。なお、データ蓄積処理とは、プロキシサーバ２０がアプリケーションバッファ２８に蓄積されているデータを、ＬＡＮ２を介してクライアント端末３０に送信する際に、アプリケーションバッファ２８に蓄積されているデータをＴＣＰ送信バッファ２６に蓄積する処理である。また、データ蓄積処理は、所定の周期（蓄積周期）で繰り返されるものである。
【００５６】
図３に示すように、ステップ２０において、プロキシサーバ２０は、ＴＣＰ送信バッファ２６の空き容量が“０”であるか否か確認する。また、プロキシサーバ２０は、ＴＣＰ送信バッファ２６の空き容量が“０”である場合には、ステップ２１の処理に移り、ＴＣＰ送信バッファ２６の空き容量が“０”でない場合には、ステップ２２の処理に移る。
【００５７】
ステップ２１において、プロキシサーバ２０は、上限となる長さを限度として蓄積周期を長くする。
【００５８】
ステップ２２において、プロキシサーバ２０は、予め設定されている所定の蓄積データ量（例えば、１０００  Ｂｙｔｅ）がＴＣＰ送信バッファ２６の空き容量以下であるか否か確認する。また、プロキシサーバ２０は、予め設定されている所定の蓄積データ量（例えば、１０００  Ｂｙｔｅ）がＴＣＰ送信バッファ２６の空き容量以下である場合には、ステップ２４の処理に移り、予め設定されている所定の蓄積データ量（例えば、１０００  Ｂｙｔｅ）がＴＣＰ送信バッファ２６の空き容量よりも大きい場合には、ステップ２３の処理に移る。
【００５９】
ステップ２３において、プロキシサーバ２０は、ＴＣＰ送信バッファ２６の空き容量（例えば、３００  Ｂｙｔｅ）に応じたデータ量（例えば、３００  Ｂｙｔｅ）で、アプリケーションバッファ２８に蓄積されているデータをＴＣＰ送信バッファ２６に蓄積する。
【００６０】
なお、プロキシサーバ２０は、ＴＣＰ送信バッファ２６の空き容量（例えば、３００  Ｂｙｔｅ）よりも小さいデータ量（例えば、２００  Ｂｙｔｅ）で、アプリケーションバッファ２８に蓄積されているデータをＴＣＰ送信バッファ２６に蓄積するように構成されていてもよい。
【００６１】
ステップ２４において、プロキシサーバ２０は、予め設定されている所定の蓄積データ量（例えば、１０００  Ｂｙｔｅ）で、アプリケーションバッファ２８に蓄積されているデータをＴＣＰ送信バッファ２６に蓄積する。
【００６２】
ステップ２５において、プロキシサーバ２０は、下限となる長さを限度として蓄積周期を短くする。
【００６３】
なお、本実施形態において、プロキシサーバ２０は、ステップ２１及びステップ２５において蓄積周期を変更するように構成されているが、蓄積周期を変更しない（ステップ２１及びステップ２５の処理を行わない）ように構成されていてもよい。
【００６４】
以下において、上述のデータ蓄積処理において、アプリケーション処理部２７とＴＣＰ処理部２４との間で行われる処理について説明する。図４は、本実施形態におけるアプリケーション処理部２７とＴＣＰ処理部２４との間で行われる処理を示すシーケンス図である。
【００６５】
図４に示すように、ステップ１０ａにおいて、ＴＣＰ処理部２４は、ＴＣＰ受信バッファ２５に蓄積されているデータ（０）をアプリケーション処理部２７に送信し、ステップ１０ｂにおいて、アプリケーション処理部２７は、当該データ（０）を受信する。
【００６６】
なお、ＴＣＰ受信バッファ２５に蓄積されているデータ（０）は、ネットワーク処理部２３及びデータリンク・物理処理部２２を介して、受信部２１から受信したデータである。
【００６７】
ステップ１１ａにおいて、アプリケーション処理部２７は、予め設定されている所定の蓄積データ量（例えば、１０００  ｂｙｔｅ）で、アプリケーションバッファ２８に蓄積されているデータ（１）をＴＣＰ処理部２４に送信し、ステップ１１ｂにおいて、ＴＣＰ処理部２４は、当該データ（１）を受信する。
【００６８】
ステップ１２において、ＴＣＰ処理部２４は、アプリケーション処理部２７から受信したデータ（１）のデータ量（例えば、１０００  Ｂｙｔｅ）がＴＣＰ送信バッファ２６の空き容量以下であるか否か確認する。また、ＴＣＰ処理部２４は、受信したデータ（１）のデータ量（例えば、１０００  Ｂｙｔｅ）がＴＣＰ送信バッファ２６の空き容量以下である場合には、ステップ１５の処理に移り、受信したデータ（１）のデータ量（例えば、１０００  Ｂｙｔｅ）がＴＣＰ送信バッファ２６の空き容量よりも大きい場合には、ステップ１３ａの処理に移る。
【００６９】
ステップ１３ａにおいて、ＴＣＰ処理部２４は、予め設定されている所定の蓄積データ量（例えば、１０００  Ｂｙｔｅ）で、アプリケーション処理部２７から受信したデータ（１）をＴＣＰ送信バッファ２６に蓄積することができないことを示すエラー信号（Ｎｏ  Ｂｕｆｆｅｒ  Ｅｒｒｏｒ信号）と、ＴＣＰ送信バッファ２６の空き容量を示す空き容量情報（例えば、“Ａｖａｉｌａｂｌｅ  Ｂｕｆｆｅｒ  Ｓｉｚｅ  ０  Ｂｙｔｅ”や“Ａｖａｉｌａｂｌｅ  Ｂｕｆｆｅｒ  Ｓｉｚｅ  ３００  Ｂｙｔｅ”）とをアプリケーション処理部２７に送信し、ステップ１３ｂにおいて、アプリケーション処理部２７は、当該エラー信号（Ｎｏ  Ｂｕｆｆｅｒ  Ｅｒｒｏｒ信号）と当該空き容量情報（例えば、“Ａｖａｉｌａｂｌｅ  Ｂｕｆｆｅｒ  Ｓｉｚｅ  ０  Ｂｙｔｅ”や“Ａｖａｉｌａｂｌｅ  Ｂｕｆｆｅｒ  Ｓｉｚｅ  ３００  Ｂｙｔｅ”）とを受信する。
【００７０】
ステップ１４ａにおいて、アプリケーション処理部２７は、ステップ１３ｂで受信した空き容量情報（例えば、“Ａｖａｉｌａｂｌｅ  Ｂｕｆｆｅｒ  Ｓｉｚｅ  ３００  Ｂｙｔｅ”）に応じたデータ量（例えば、３００  Ｂｙｔｅ）で、アプリケーションバッファ２８に蓄積されているデータ（２）をＴＣＰ処理部２４に送信し、ステップ１４ｂにおいて、ＴＣＰ処理部２４は、当該データ（２）を受信する。
【００７１】
なお、アプリケーション処理部２７は、ステップ１３ｂで受信した空き容量情報（例えば、“Ａｖａｉｌａｂｌｅ  Ｂｕｆｆｅｒ  Ｓｉｚｅ  ３００  Ｂｙｔｅ”）によって示されるＴＣＰ送信バッファ２６の空き容量（３００  Ｂｙｔｅ）よりも小さいデータ量（例えば、２００  Ｂｙｔｅ）で、アプリケーションバッファ２８に蓄積されているデータをＴＣＰ処理部２４に送信するように構成されていてもよい。
【００７２】
ステップ１５において、ＴＣＰ処理部２４は、ステップ１１ｂで受信したデータ（１）、又は、ステップ１４ｂで受信したデータ（２）をＴＣＰ送信バッファ２６に蓄積する。
【００７３】
ステップ１６において、ＴＣＰ処理部２４は、所定のフロー制御に基づいて、ＴＣＰ送信バッファ２６に蓄積されているデータを、ネットワーク処理部２３及びデータリンク・物理処理部２２を介して送信部２９に送信する。
【００７４】
ステップ１７において、アプリケーション処理部２７は、アプリケーションバッファ２８に蓄積されているデータをＴＣＰ処理部２４に送信する周期（アプリケーションバッファ２８に蓄積されているデータをＴＣＰ送信バッファ２６に蓄積しようとする周期（蓄積周期））を変更する。具体的には、アプリケーション処理部２７は、ＴＣＰ処理部２４からエラー信号（Ｎｏ  Ｂｕｆｆｅｒ  Ｅｒｒｏｒ信号）を受信しなかった場合には、下限となる長さを限度として、蓄積周期を短くする。また、アプリケーション処理部２７は、ステップ１３ｂで空き容量情報（“Ａｖａｉｌａｂｌｅ  Ｂｕｆｆｅｒ  Ｓｉｚｅ  ０  Ｂｙｔｅ”）を受信した場合には、上限となる長さを限度として、蓄積周期を長くする。
【００７５】
なお、アプリケーション処理部２７は、ステップ１３ｂで空き容量情報（“Ａｖａｉｌａｂｌｅ  Ｂｕｆｆｅｒ  Ｓｉｚｅ  ３００  Ｂｙｔｅ”）を受信した場合に、当該空き容量情報に応じて、蓄積周期を変更してもよい。
【００７６】
また、本実施形態において、アプリケーション処理部２７は、ステップ１７において蓄積周期を変更するように構成されているが、蓄積周期を変更しない（ステップ１７の処理を行わない）ように構成されていてもよい。
【００７７】
（プロキシサーバの作用、及び、効果）
本実施形態におけるプロキシサーバ２０によれば、アプリケーション処理部２７が、ＴＣＰ送信バッファ２６の空き容量に応じて、アプリケーションバッファ２８に蓄積されているデータをＴＣＰ処理部２４に送信することにより、プロキシサーバ２０は、ＴＣＰ送信バッファ２６に空き容量が少しでもあれば、アプリケーションバッファ２８に蓄積されているデータをＴＣＰ送信バッファ２６に蓄積するとともに、ＴＣＰ送信バッファ２６に蓄積されているデータを、ＬＡＮ２を介してクライアント端末３０に送信することができる（データの送信が完全に停止する可能性を軽減できる）。
【００７８】
また、プロキシサーバ２０は、キープアライブタイムが短く設定されている場合であっても、ＴＣＰ送信バッファ２６の空き容量が少しでもあれば、ＴＣＰ受信バッファ２５に蓄積されているデータをＴＣＰ送信バッファ２６に蓄積するとともに、ＴＣＰ送信バッファ２６に蓄積されているデータを、ＬＡＮ２を介してクライアント端末３０に送信する（通信の接続が維持される）ことにより、タイムアウトが発生する可能性を軽減することができる。
【００７９】
さらに、ＴＣＰ処理部２４が、アプリケーションバッファ２８に蓄積されているデータをＴＣＰ送信バッファ２６に蓄積することができないときに、当該ＴＣＰ送信バッファ２６の空き容量をアプリケーション処理部２７に送信することにより、プロキシサーバ２０は、必要なときにＴＣＰ送信バッファ２６の空き容量を確認することができる。
【００８０】
また、アプリケーション処理部２７が、ＴＣＰ送信バッファ２６の空き容量が“０”である場合には、蓄積周期を長くし、ＴＣＰ送信バッファ２６の空き容量が予め設定されている所定の蓄積データ量（例えば、１０００  Ｂｙｔｅ）よりも大きい場合には、蓄積周期を短くすることにより、プロキシサーバ２０は、ＴＣＰ送信バッファ２６において発生したオーバーフローの解消を図るとともに、スループットの向上を図ることができる。
【００８１】
【発明の効果】
本発明によれば、サーバ等の送信バッファの空き容量が予め設定されている所定の蓄積データ量よりも小さい場合であっても、送信バッファに空き容量が少しでもある場合には、当該送信バッファに所定のデータを蓄積することにより、データの送信が完全に停止する可能性を既存のＴＣＰを用いて軽減することができる端末装置及びデータ送信方法を提供することができる。
【図面の簡単な説明】
【図１】本実施形態におけるプロキシサーバ２０が設置されている環境を説明するための図である。
【図２】本実施形態におけるプロキシサーバ２０の構成を示すブロック図である。
【図３】本実施形態におけるプロキシサーバ２０の動作を示す図である。
【図４】本実施形態におけるアプリケーション処理部２７とＴＣＰ処理部２４との間で行われる処理を示すシーケンス図である。
【図５】送信端末から受信端末に所定のデータが送信される方法について示す図である。
【図６】送信端末のＴＣＰ処理部及び受信端末のＴＣＰ処理部において行われるフロー制御を示すシーケンス図である。
【符号の説明】
１…ＷＡＮ、２…ＬＡＮ、１０…サーバ、２０…プロキシサーバ、２１…受信部、２２…データリンク・物理処理部、２３…ネットワーク処理部、２４…ＴＣＰ処理部、２５…ＴＣＰ受信バッファ、２６…ＴＣＰ送信バッファ、２７…アプリケーション処理部、２８…アプリケーションバッファ、２９…送信部、３０…クライアント端末
【図１】
2005044047.tif 000003
【図２】
2005044047.tif 000004
【図３】
2005044047.tif 000005
【図４】
2005044047.tif 000006
【図５】
2005044047.tif 000007
【図６】
2005044047.tif 000008