中継装置、通信システム及びそれらに用いるフロー制御方法
【課題】 メモリ不足を発生させることなく、代理接続サービスを継続することが可能な中継装置を提供する。
【解決手段】 中継装置は、複数のＴＣＰセッションを代理接続し、受信データを保持する受信バッファのサイズをＴＣＰセッションの受信ウインドウサイズとして接続先に通知する。中継装置は、自装置の中継動作に用いるメモリを、受信ウインドウサイズを接続済みＴＣＰセッションで総和した通知済み受信ウインドウサイズ領域（Ａ１）と、中継転送するデータをＴＣＰセッションの接続先に送信する際に通信途中のデータ紛失時の再送に備えるための送信バッファ領域（Ａ２）との２つの部分に分けて管理し、送信バッファ領域（Ａ２）の空き領域に基づいて受信データの中継を実施するデータ転送手段を有する。
【解決手段】 中継装置は、複数のＴＣＰセッションを代理接続し、受信データを保持する受信バッファのサイズをＴＣＰセッションの受信ウインドウサイズとして接続先に通知する。中継装置は、自装置の中継動作に用いるメモリを、受信ウインドウサイズを接続済みＴＣＰセッションで総和した通知済み受信ウインドウサイズ領域（Ａ１）と、中継転送するデータをＴＣＰセッションの接続先に送信する際に通信途中のデータ紛失時の再送に備えるための送信バッファ領域（Ａ２）との２つの部分に分けて管理し、送信バッファ領域（Ａ２）の空き領域に基づいて受信データの中継を実施するデータ転送手段を有する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は中継装置、通信システム及びそれらに用いるフロー制御方法に関し、特にＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）セッション単位でのフロー制御方法に関する。
【背景技術】
【０００２】
受信ウインドウサイズを拡大したＴＣＰセッションを大量（数万セッション以上）に代理接続（Ｐｒｏｘｙ）する装置においては、受信ウインドウサイズとセッション数との乗算で示される分のメモリを保有している必要がある。
【０００３】
上記のＴＣＰセッションを代理接続する装置としては、一つのＴＣＰセッションのデータをシステム内の受信バッファに蓄積して、受信ウインドウサイズを指定する装置が提案されている（例えば、特許文献１参照）。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００５−３４８１０７号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
上述した本発明に関連するＴＣＰセッションを代理接続する装置では、受信ウインドウサイズとセッション数の乗算で示される分のメモリを保有していない場合、ネットワークが輻輳している状況下においてＴＣＰセッションで運ばれるデータがメモリ不足によって蓄積することができず、代理接続サービスを継続することが困難となる。
【０００６】
具体的には、メモリ不足によってパケットロスが発生し、最終的にＴＣＰセッションを切断してしまうことが発生し得る。この状況は、受信ウインドウサイズを拡大した場合において、必要メモリ量が多量になることから、より顕著となる。
【０００７】
そこで、本発明の目的は上記の問題点を解消し、メモリ不足を発生させることなく、代理接続サービスを継続することができる中継装置、通信システム及びそれらに用いるフロー制御方法を提供することにある。
【課題を解決するための手段】
【０００８】
本発明による中継装置は、複数のＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）セッションを代理接続し、受信データを保持する受信バッファのサイズを前記ＴＣＰセッションの受信ウインドウサイズとして接続先に通知する中継装置であって、
自装置の中継動作に用いるメモリを、前記受信ウインドウサイズを接続済みＴＣＰセッションで総和した通知済み受信ウインドウサイズ領域と、中継転送するデータを前記ＴＣＰセッションの接続先に送信する際に通信途中のデータ紛失時の再送に備えるための送信バッファ領域との２つの部分に分けて管理し、
前記送信バッファ領域の空き領域に基づいて前記受信データの中継を実施するデータ転送手段を備えている。
【０００９】
本発明による通信システムは、上記の中継装置を含むことを特徴とする。
【００１０】
本発明によるフロー制御方法は、複数のＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）セッションを代理接続し、受信データを保持する受信バッファのサイズを前記ＴＣＰセッションの受信ウインドウサイズとして接続先に通知する中継装置に用いるフロー制御方法であって、
前記中継装置の中継動作に用いるメモリを、前記受信ウインドウサイズを接続済みＴＣＰセッションで総和した通知済み受信ウインドウサイズ領域と、中継転送するデータを前記ＴＣＰセッションの接続先に送信する際に通信途中のデータ紛失時の再送に備えるための送信バッファ領域との２つの部分に分けて管理し、
前記中継装置が、前記送信バッファ領域の空き領域に基づいて前記受信データの中継を実施するデータ転送処理を実行している。
【発明の効果】
【００１１】
本発明は、上記のような構成及び動作とすることで、メモリ不足を発生させることなく、代理接続サービスを継続することができるという効果が得られる。
【図面の簡単な説明】
【００１２】
【図１】本発明におけるメモリの使用方式を示す図である。
【図２】本発明の実施の形態による通信システムの構成例を示すブロック図である。
【図３】本発明の実施の形態におけるバッファの概念図である。
【図４】本発明の実施の形態による中継装置の動作を示すフローチャートである。
【発明を実施するための形態】
【００１３】
次に、本発明の実施の形態について図面を参照して説明する。まず、本発明による中継装置の概要について説明する。本発明による中継装置は、受信ウインドウサイズを拡大したＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）セッションを大量（数万セッション以上）に代理接続（Ｐｒｏｘｙ）する装置であり、メモリ不足による代理接続サービスの中断を発生させずに、各セッションをベストエフォートで接続できるようにしている。つまり、本発明は、ＴＣＰセッション接続先へ通知する受信ウインドウサイズを能動的に制御することにより、メモリ不足を発生させることなく、代理接続サービスを継続できる装置を提供する。
【００１４】
本発明による中継装置は、端末とサーバとの間のＴＣＰ通信を中継している。ここで、端末側は、モバイル環境や国際伝送網等の遅延（ＲＴＴ：Ｒｏｕｎｄ Ｔｒｉｐ Ｔｉｍｅ）の大きな環境を想定し、帯域遅延積の関係から端末側の受信ウインドウサイズが大きいものとする。
【００１５】
図１は本発明におけるメモリの使用方式を示す図である。図１に示すメモリは、上記の中継装置に搭載されているメモリのうち、中継動作に用いられるメモリを示したものである。
【００１６】
このメモリの搭載メモリ量Ａは、受信ウインドウサイズを接続済みＴＣＰセッションで総和した通知済み受信ウインドウサイズ領域Ａ１と、中継転送するデータを相手先に送信する際に通信途中のデータ紛失時の再送に備えるための送信バッファ領域Ａ２との２つに分類される。つまり、受信バッファの総和が通知済み受信ウインドウサイズ領域Ａ１となる。
【００１７】
しかしながら、送信バッファの総和は、送信バッファ領域Ａ２とは等しくならない。これは、受信ウインドウサイズに関しては、下記で説明するように、相手に通知したサイズを変更することができないために固定的に確保されることに対し、送信バッファ領域Ａ２は、送信しようとした時に初めて確保されるものであるため、送信バッファの総和は、通信状況によって増減するためである。また、通信相手から通知された受信ウインドウサイズの最大値を総和したものは送信バッファ領域Ａ２を超える可能性がある。
【００１８】
本発明による中継装置は、搭載メモリを通知済み受信ウインドウサイズ領域Ａ１と送信バッファ領域Ａ２との２つの部分に分けて管理することで、端末やサーバに通知した受信ウインドウサイズ分のデータの確実な受信を保証することができる。これにより、本発明による中継装置は、メモリ不足によってパケットを受信できないという状況を防ぐことができ、パケットロスによるダウンロード速度低下や、再送動作が発生することによる送信側端末（あるいはサーバ）の負荷増大を回避することができる。
【００１９】
また、本発明による中継装置は、送信バッファを通信状況に応じてＴＣＰセッションに割り当てるためにアクティブセッションの概念を導入したことにより、接続セッション数が大量化した場合でも送信バッファを必要とするセッションを管理することが可能となる。これにより、本発明による代理接続装置は、単純に接続セッション数を残りメモリ量で除算しただけではメモリ使用効率が悪くなってしまう問題を回避し、メモリ使用効率を上げることができる。
【００２０】
さらに、本発明による中継装置は、メモリの空き状況のうち、受信に備えて確保しておくべき領域と、他のセッションと共有できる空きメモリとを分けて管理することが可能になることから、空きメモリが不足してきた状況下においても、ベストエフォート動作が可能となる。
【００２１】
図２は本発明の実施の形態による通信システムの構成例を示すブロック図である。図２において、本発明の実施の形態による通信システムは、端末２とサーバ３との間で中継装置１を介してＴＣＰ通信を行っている。ここで、端末２側は、モバイル環境や国際伝送網等の遅延（ＲＴＴ）の大きな環境を想定し、帯域遅延積の関係から端末２側の受信ウインドウサイズが大きいものとする。
【００２２】
次に、中継装置１は、ＴＣＰプロトコルの処理を行うＴＣＰ処理部１１と、受信したデータを対側装置に転送するまでの間保持しておくためのデータ記憶部１２と、受信したデータを加工して転送するためのデータ転送部１３と、データの到着や相手装置へのデータ送信完了等のイベントを発生させるためのイベント発生部１４と、現時点で空いているメモリ量を計算するための空きバッファ量計算部１５と、現時点で通信中であることを示すアクティブセッションを管理するためのアクティブセッション管理部１６とを具備している。
【００２３】
中継装置１は、ＴＣＰ処理部１１において、空きバッファ量計算部１５によって計算される空きバッファ量を参照し、受信ウインドウサイズとして通信相手である端末２やサーバ３に通知すると同時に、空きバッファ量から通知した分を減算する。このことにより、端末２やサーバ３から受信したデータは、全てデータ記憶部１２において受信できることが保証される。
【００２４】
データ転送部１３においてデータを加工・中継する際は、空きバッファ量をアクティブセッション管理部１６から提供されるアクティブセッション数で割ったものを送信データ量の上限としてデータの中継を実施する。ここで、送信データは、通信途中のデータ紛失に備えて保持したままにしておくが、通信相手より受信確認（ＡＣＫ：ＡＣＫｎｏｗｌｅｄｇｅｍｅｎｔ）されれば破棄して良いデータであるため、受信確認された時点でイベント発生部１４より送信完了イベントを発生させ、空きバッファ量計算部１５にて空きバッファ量を増加させる。
【００２５】
図３は本発明の実施の形態におけるバッファの概念図である。図３において、受信バッファ１０１，１０３は、それぞれサーバ３と端末２とからの受信データを保持するバッファである。この受信バッファ１０１，１０３のサイズは、ＴＣＰセッションの受信ウインドウサイズとして通信相手に対して通知されており、プロトコル規約により一度通知したサイズを受信側の都合で減らす（ｓｈｒｉｎｋさせる）ことは原則としてできない。
【００２６】
受信バッファ１０１，１０３のサイズは、ＴＣＰ処理部１１がデータを受信すると減少し、データ転送部１３がデータを処理して対側の送信バッファ１０２，１０４に書込むと増加する。
【００２７】
次に、送信バッファ１０２，１０４は、それぞれ端末２とサーバ３とへ送信するためのデータを保持するバッファである。この送信バッファ１０２，１０４のサイズは、通信相手側の受信ウインドウサイズとして通信相手から最大値が通知されるものであり、通知されたサイズを超えて送信を行うことはできない。
【００２８】
図４は本発明の実施の形態による中継装置１の動作を示すフローチャートである。図４は、本実施の形態の送信時におけるデータ転送部１３の動作を示しており、中継装置１内のＣＰＵ（中央処理装置）（図示せず）がプログラムを実行することでも実現可能である。これら図１〜図４を参照して本実施の形態の送信時におけるデータ転送の動作について説明する。
【００２９】
尚、図４においては、サーバ３から端末２へデータを送信している場合のデータ転送の動作を示している。また、端末２からサーバ３へデータを送信するという逆側の動作についても、ここで説明する場合と同様に考えることができるため、ここでは逆側の動作の説明を省略する。さらに、ＴＣＰセッションの接続、切断といったプロトコル動作についても一般的であるため、ここではそれらプロトコル動作の説明も省略する。
【００３０】
データ転送部１３は、ＴＣＰセッションが接続されると、中継動作を開始し、イベントの受信を待つ（図４ステップＳ１）。ＴＣＰ処理部１１は、受信バッファ１０１にデータが到着すると、イベント発生部１４を通じて受信イベントを発生させる。この受信イベントは、ＴＣＰセッション単位に発生する。
【００３１】
データ転送部１３は、この受信イベントを受信すると、送信バッファ１０２の空きを確認し、受信したデータを送信するために十分な空きが存在すれば、送信バッファ１０２を予約する（図４ステップＳ２）。
【００３２】
送信バッファ１０２の空きは、空きバッファ量計算部１５によって、（セッション毎の送信バッファ量）＝ｍｉｎ（（セッション単位の最大として設定されている値），（空きメモリ量）／（アクティブセッション数），（受信データ量））という式で計算が行われる。
【００３３】
ここで、アクティブセッションとは未送信の送信データを保持しているセッションのことを指し、アクティブセッション管理部１６によって計算される。言い換えれば、単純に接続しているだけで通信していないセッションを除くということである。
【００３４】
データ転送部１３は、もしも、送信バッファ１０２に十分な空きが存在しなければ、何もせずにそのまま中継動作を終了する。つまり、受信バッファ１０１にそのまま受信データを待ち合わせておくということになり、サーバ３は、受信バッファ１０１のメモリ量分までしかデータを送信することができず、フロー制御されていることとなる。
【００３５】
次に、データ転送部１３は、送信バッファ１０２の予約を行うと、ＴＣＰ処理部１１から上記のステップＳ２の処理で予約した分だけのデータを受信し、必要な加工処理を実施してから送信バッファ１０２に書込む（図４ステップＳ３）。送信バッファ１０２に書込まれた送信データは、ＴＣＰ処理部１１によって通常のＴＣＰ規約にしたがって端末２へ送信される。
【００３６】
送信が完了した場合（つまり、ＴＣＰのＡＣＫを受信した場合）、送信バッファ１０２から不要となった送信済みデータが取り除かれることとなるが、この時、イベント発生部１４を通じて送信完了イベントが発生される。データ転送部１３は、送信完了イベントを受けると、上述したデータ受信イベントと同様の動作を行う。
【００３７】
この手順を実施した後、まだ受信バッファ１０１に処理すべきデータが残っていた場合は、受信イベントをイベント発生部１４を通じてデータ転送部１３に送信する。この受信イベントは、発生順に処理されるため、別のセッションにデータが到着していた場合は、そちらの処理が先に実施されることとなり、セッション間の公平性が保たれる。
【００３８】
このように、本実施の形態では、中継装置１の搭載メモリを通知済み受信ウインドウサイズ領域Ａ１と送信バッファ領域Ａ２との２つの部分に分けて管理することで、端末２やサーバ３に通知した受信ウインドウサイズ分のデータの確実な受信を保証することができる。
【００３９】
これにより、本実施の形態では、中継装置１がメモリ不足によってパケットを受信できないという状況を防ぐことができ、パケットロスによるダウンロード速度低下や、再送動作が発生することによる送信側端末（あるいはサーバ）の負荷増大を回避することができる。
【００４０】
また、本実施の形態では、送信バッファ１０２，１０４を通信状況に応じてＴＣＰセッションに割り当てるためにアクティブセッションの概念を導入したことにより、接続セッション数が大量化した場合でも送信バッファ１０２，１０４を必要とするセッションを管理することが可能となる。
【００４１】
これにより、本実施の形態では、単純に接続セッション数で残りメモリ量を除算しただけではメモリ使用効率が悪くなってしまう問題を回避し、メモリ使用効率を上げることができる。
【００４２】
さらに、本実施の形態では、メモリの空き状況のうち、受信に備えて確保しておくべき領域と、他のセッションと共有できる空きメモリとを分けて管理することが可能になることから、空きメモリが不足してきた状況下においても、ベストエフォート動作が可能となる。
【００４３】
上述した本発明の実施の形態においては、中継装置１と端末２、サーバ３とを別々の装置として記載しているが、端末２、サーバ３のどちらかと中継装置１とを一体化した場合も、片方向の通信に関しては上記と同様の効果を期待することができる。
【００４４】
本実施の形態においては、端末２側がモバイルネットワーク等の遅延が大きいネットワークを想定して記述しているが、特に前提として必要ではなく、どのようなネットワークにおいても上記と同様の効果が得られる。
【符号の説明】
【００４５】
１ 中継装置
２ 端末
３ サーバ
１１ ＴＣＰ処理部
１２ データ記憶部
１３ データ転送部
１４ イベント発生部
１５ 空きバッファ量計算部
１６ アクティブセッション管理部
１０１，１０３ 受信バッファ
１０２，１０４ 送信バッファ
Ａ 搭載メモリ量
Ａ１ 通知済み受信ウインドウサイズ
Ａ２ 送信バッファ
【技術分野】
【０００１】
本発明は中継装置、通信システム及びそれらに用いるフロー制御方法に関し、特にＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）セッション単位でのフロー制御方法に関する。
【背景技術】
【０００２】
受信ウインドウサイズを拡大したＴＣＰセッションを大量（数万セッション以上）に代理接続（Ｐｒｏｘｙ）する装置においては、受信ウインドウサイズとセッション数との乗算で示される分のメモリを保有している必要がある。
【０００３】
上記のＴＣＰセッションを代理接続する装置としては、一つのＴＣＰセッションのデータをシステム内の受信バッファに蓄積して、受信ウインドウサイズを指定する装置が提案されている（例えば、特許文献１参照）。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００５−３４８１０７号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
上述した本発明に関連するＴＣＰセッションを代理接続する装置では、受信ウインドウサイズとセッション数の乗算で示される分のメモリを保有していない場合、ネットワークが輻輳している状況下においてＴＣＰセッションで運ばれるデータがメモリ不足によって蓄積することができず、代理接続サービスを継続することが困難となる。
【０００６】
具体的には、メモリ不足によってパケットロスが発生し、最終的にＴＣＰセッションを切断してしまうことが発生し得る。この状況は、受信ウインドウサイズを拡大した場合において、必要メモリ量が多量になることから、より顕著となる。
【０００７】
そこで、本発明の目的は上記の問題点を解消し、メモリ不足を発生させることなく、代理接続サービスを継続することができる中継装置、通信システム及びそれらに用いるフロー制御方法を提供することにある。
【課題を解決するための手段】
【０００８】
本発明による中継装置は、複数のＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）セッションを代理接続し、受信データを保持する受信バッファのサイズを前記ＴＣＰセッションの受信ウインドウサイズとして接続先に通知する中継装置であって、
自装置の中継動作に用いるメモリを、前記受信ウインドウサイズを接続済みＴＣＰセッションで総和した通知済み受信ウインドウサイズ領域と、中継転送するデータを前記ＴＣＰセッションの接続先に送信する際に通信途中のデータ紛失時の再送に備えるための送信バッファ領域との２つの部分に分けて管理し、
前記送信バッファ領域の空き領域に基づいて前記受信データの中継を実施するデータ転送手段を備えている。
【０００９】
本発明による通信システムは、上記の中継装置を含むことを特徴とする。
【００１０】
本発明によるフロー制御方法は、複数のＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）セッションを代理接続し、受信データを保持する受信バッファのサイズを前記ＴＣＰセッションの受信ウインドウサイズとして接続先に通知する中継装置に用いるフロー制御方法であって、
前記中継装置の中継動作に用いるメモリを、前記受信ウインドウサイズを接続済みＴＣＰセッションで総和した通知済み受信ウインドウサイズ領域と、中継転送するデータを前記ＴＣＰセッションの接続先に送信する際に通信途中のデータ紛失時の再送に備えるための送信バッファ領域との２つの部分に分けて管理し、
前記中継装置が、前記送信バッファ領域の空き領域に基づいて前記受信データの中継を実施するデータ転送処理を実行している。
【発明の効果】
【００１１】
本発明は、上記のような構成及び動作とすることで、メモリ不足を発生させることなく、代理接続サービスを継続することができるという効果が得られる。
【図面の簡単な説明】
【００１２】
【図１】本発明におけるメモリの使用方式を示す図である。
【図２】本発明の実施の形態による通信システムの構成例を示すブロック図である。
【図３】本発明の実施の形態におけるバッファの概念図である。
【図４】本発明の実施の形態による中継装置の動作を示すフローチャートである。
【発明を実施するための形態】
【００１３】
次に、本発明の実施の形態について図面を参照して説明する。まず、本発明による中継装置の概要について説明する。本発明による中継装置は、受信ウインドウサイズを拡大したＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）セッションを大量（数万セッション以上）に代理接続（Ｐｒｏｘｙ）する装置であり、メモリ不足による代理接続サービスの中断を発生させずに、各セッションをベストエフォートで接続できるようにしている。つまり、本発明は、ＴＣＰセッション接続先へ通知する受信ウインドウサイズを能動的に制御することにより、メモリ不足を発生させることなく、代理接続サービスを継続できる装置を提供する。
【００１４】
本発明による中継装置は、端末とサーバとの間のＴＣＰ通信を中継している。ここで、端末側は、モバイル環境や国際伝送網等の遅延（ＲＴＴ：Ｒｏｕｎｄ Ｔｒｉｐ Ｔｉｍｅ）の大きな環境を想定し、帯域遅延積の関係から端末側の受信ウインドウサイズが大きいものとする。
【００１５】
図１は本発明におけるメモリの使用方式を示す図である。図１に示すメモリは、上記の中継装置に搭載されているメモリのうち、中継動作に用いられるメモリを示したものである。
【００１６】
このメモリの搭載メモリ量Ａは、受信ウインドウサイズを接続済みＴＣＰセッションで総和した通知済み受信ウインドウサイズ領域Ａ１と、中継転送するデータを相手先に送信する際に通信途中のデータ紛失時の再送に備えるための送信バッファ領域Ａ２との２つに分類される。つまり、受信バッファの総和が通知済み受信ウインドウサイズ領域Ａ１となる。
【００１７】
しかしながら、送信バッファの総和は、送信バッファ領域Ａ２とは等しくならない。これは、受信ウインドウサイズに関しては、下記で説明するように、相手に通知したサイズを変更することができないために固定的に確保されることに対し、送信バッファ領域Ａ２は、送信しようとした時に初めて確保されるものであるため、送信バッファの総和は、通信状況によって増減するためである。また、通信相手から通知された受信ウインドウサイズの最大値を総和したものは送信バッファ領域Ａ２を超える可能性がある。
【００１８】
本発明による中継装置は、搭載メモリを通知済み受信ウインドウサイズ領域Ａ１と送信バッファ領域Ａ２との２つの部分に分けて管理することで、端末やサーバに通知した受信ウインドウサイズ分のデータの確実な受信を保証することができる。これにより、本発明による中継装置は、メモリ不足によってパケットを受信できないという状況を防ぐことができ、パケットロスによるダウンロード速度低下や、再送動作が発生することによる送信側端末（あるいはサーバ）の負荷増大を回避することができる。
【００１９】
また、本発明による中継装置は、送信バッファを通信状況に応じてＴＣＰセッションに割り当てるためにアクティブセッションの概念を導入したことにより、接続セッション数が大量化した場合でも送信バッファを必要とするセッションを管理することが可能となる。これにより、本発明による代理接続装置は、単純に接続セッション数を残りメモリ量で除算しただけではメモリ使用効率が悪くなってしまう問題を回避し、メモリ使用効率を上げることができる。
【００２０】
さらに、本発明による中継装置は、メモリの空き状況のうち、受信に備えて確保しておくべき領域と、他のセッションと共有できる空きメモリとを分けて管理することが可能になることから、空きメモリが不足してきた状況下においても、ベストエフォート動作が可能となる。
【００２１】
図２は本発明の実施の形態による通信システムの構成例を示すブロック図である。図２において、本発明の実施の形態による通信システムは、端末２とサーバ３との間で中継装置１を介してＴＣＰ通信を行っている。ここで、端末２側は、モバイル環境や国際伝送網等の遅延（ＲＴＴ）の大きな環境を想定し、帯域遅延積の関係から端末２側の受信ウインドウサイズが大きいものとする。
【００２２】
次に、中継装置１は、ＴＣＰプロトコルの処理を行うＴＣＰ処理部１１と、受信したデータを対側装置に転送するまでの間保持しておくためのデータ記憶部１２と、受信したデータを加工して転送するためのデータ転送部１３と、データの到着や相手装置へのデータ送信完了等のイベントを発生させるためのイベント発生部１４と、現時点で空いているメモリ量を計算するための空きバッファ量計算部１５と、現時点で通信中であることを示すアクティブセッションを管理するためのアクティブセッション管理部１６とを具備している。
【００２３】
中継装置１は、ＴＣＰ処理部１１において、空きバッファ量計算部１５によって計算される空きバッファ量を参照し、受信ウインドウサイズとして通信相手である端末２やサーバ３に通知すると同時に、空きバッファ量から通知した分を減算する。このことにより、端末２やサーバ３から受信したデータは、全てデータ記憶部１２において受信できることが保証される。
【００２４】
データ転送部１３においてデータを加工・中継する際は、空きバッファ量をアクティブセッション管理部１６から提供されるアクティブセッション数で割ったものを送信データ量の上限としてデータの中継を実施する。ここで、送信データは、通信途中のデータ紛失に備えて保持したままにしておくが、通信相手より受信確認（ＡＣＫ：ＡＣＫｎｏｗｌｅｄｇｅｍｅｎｔ）されれば破棄して良いデータであるため、受信確認された時点でイベント発生部１４より送信完了イベントを発生させ、空きバッファ量計算部１５にて空きバッファ量を増加させる。
【００２５】
図３は本発明の実施の形態におけるバッファの概念図である。図３において、受信バッファ１０１，１０３は、それぞれサーバ３と端末２とからの受信データを保持するバッファである。この受信バッファ１０１，１０３のサイズは、ＴＣＰセッションの受信ウインドウサイズとして通信相手に対して通知されており、プロトコル規約により一度通知したサイズを受信側の都合で減らす（ｓｈｒｉｎｋさせる）ことは原則としてできない。
【００２６】
受信バッファ１０１，１０３のサイズは、ＴＣＰ処理部１１がデータを受信すると減少し、データ転送部１３がデータを処理して対側の送信バッファ１０２，１０４に書込むと増加する。
【００２７】
次に、送信バッファ１０２，１０４は、それぞれ端末２とサーバ３とへ送信するためのデータを保持するバッファである。この送信バッファ１０２，１０４のサイズは、通信相手側の受信ウインドウサイズとして通信相手から最大値が通知されるものであり、通知されたサイズを超えて送信を行うことはできない。
【００２８】
図４は本発明の実施の形態による中継装置１の動作を示すフローチャートである。図４は、本実施の形態の送信時におけるデータ転送部１３の動作を示しており、中継装置１内のＣＰＵ（中央処理装置）（図示せず）がプログラムを実行することでも実現可能である。これら図１〜図４を参照して本実施の形態の送信時におけるデータ転送の動作について説明する。
【００２９】
尚、図４においては、サーバ３から端末２へデータを送信している場合のデータ転送の動作を示している。また、端末２からサーバ３へデータを送信するという逆側の動作についても、ここで説明する場合と同様に考えることができるため、ここでは逆側の動作の説明を省略する。さらに、ＴＣＰセッションの接続、切断といったプロトコル動作についても一般的であるため、ここではそれらプロトコル動作の説明も省略する。
【００３０】
データ転送部１３は、ＴＣＰセッションが接続されると、中継動作を開始し、イベントの受信を待つ（図４ステップＳ１）。ＴＣＰ処理部１１は、受信バッファ１０１にデータが到着すると、イベント発生部１４を通じて受信イベントを発生させる。この受信イベントは、ＴＣＰセッション単位に発生する。
【００３１】
データ転送部１３は、この受信イベントを受信すると、送信バッファ１０２の空きを確認し、受信したデータを送信するために十分な空きが存在すれば、送信バッファ１０２を予約する（図４ステップＳ２）。
【００３２】
送信バッファ１０２の空きは、空きバッファ量計算部１５によって、（セッション毎の送信バッファ量）＝ｍｉｎ（（セッション単位の最大として設定されている値），（空きメモリ量）／（アクティブセッション数），（受信データ量））という式で計算が行われる。
【００３３】
ここで、アクティブセッションとは未送信の送信データを保持しているセッションのことを指し、アクティブセッション管理部１６によって計算される。言い換えれば、単純に接続しているだけで通信していないセッションを除くということである。
【００３４】
データ転送部１３は、もしも、送信バッファ１０２に十分な空きが存在しなければ、何もせずにそのまま中継動作を終了する。つまり、受信バッファ１０１にそのまま受信データを待ち合わせておくということになり、サーバ３は、受信バッファ１０１のメモリ量分までしかデータを送信することができず、フロー制御されていることとなる。
【００３５】
次に、データ転送部１３は、送信バッファ１０２の予約を行うと、ＴＣＰ処理部１１から上記のステップＳ２の処理で予約した分だけのデータを受信し、必要な加工処理を実施してから送信バッファ１０２に書込む（図４ステップＳ３）。送信バッファ１０２に書込まれた送信データは、ＴＣＰ処理部１１によって通常のＴＣＰ規約にしたがって端末２へ送信される。
【００３６】
送信が完了した場合（つまり、ＴＣＰのＡＣＫを受信した場合）、送信バッファ１０２から不要となった送信済みデータが取り除かれることとなるが、この時、イベント発生部１４を通じて送信完了イベントが発生される。データ転送部１３は、送信完了イベントを受けると、上述したデータ受信イベントと同様の動作を行う。
【００３７】
この手順を実施した後、まだ受信バッファ１０１に処理すべきデータが残っていた場合は、受信イベントをイベント発生部１４を通じてデータ転送部１３に送信する。この受信イベントは、発生順に処理されるため、別のセッションにデータが到着していた場合は、そちらの処理が先に実施されることとなり、セッション間の公平性が保たれる。
【００３８】
このように、本実施の形態では、中継装置１の搭載メモリを通知済み受信ウインドウサイズ領域Ａ１と送信バッファ領域Ａ２との２つの部分に分けて管理することで、端末２やサーバ３に通知した受信ウインドウサイズ分のデータの確実な受信を保証することができる。
【００３９】
これにより、本実施の形態では、中継装置１がメモリ不足によってパケットを受信できないという状況を防ぐことができ、パケットロスによるダウンロード速度低下や、再送動作が発生することによる送信側端末（あるいはサーバ）の負荷増大を回避することができる。
【００４０】
また、本実施の形態では、送信バッファ１０２，１０４を通信状況に応じてＴＣＰセッションに割り当てるためにアクティブセッションの概念を導入したことにより、接続セッション数が大量化した場合でも送信バッファ１０２，１０４を必要とするセッションを管理することが可能となる。
【００４１】
これにより、本実施の形態では、単純に接続セッション数で残りメモリ量を除算しただけではメモリ使用効率が悪くなってしまう問題を回避し、メモリ使用効率を上げることができる。
【００４２】
さらに、本実施の形態では、メモリの空き状況のうち、受信に備えて確保しておくべき領域と、他のセッションと共有できる空きメモリとを分けて管理することが可能になることから、空きメモリが不足してきた状況下においても、ベストエフォート動作が可能となる。
【００４３】
上述した本発明の実施の形態においては、中継装置１と端末２、サーバ３とを別々の装置として記載しているが、端末２、サーバ３のどちらかと中継装置１とを一体化した場合も、片方向の通信に関しては上記と同様の効果を期待することができる。
【００４４】
本実施の形態においては、端末２側がモバイルネットワーク等の遅延が大きいネットワークを想定して記述しているが、特に前提として必要ではなく、どのようなネットワークにおいても上記と同様の効果が得られる。
【符号の説明】
【００４５】
１ 中継装置
２ 端末
３ サーバ
１１ ＴＣＰ処理部
１２ データ記憶部
１３ データ転送部
１４ イベント発生部
１５ 空きバッファ量計算部
１６ アクティブセッション管理部
１０１，１０３ 受信バッファ
１０２，１０４ 送信バッファ
Ａ 搭載メモリ量
Ａ１ 通知済み受信ウインドウサイズ
Ａ２ 送信バッファ
【特許請求の範囲】
【請求項１】
複数のＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）セッションを代理接続し、受信データを保持する受信バッファのサイズを前記ＴＣＰセッションの受信ウインドウサイズとして接続先に通知する中継装置であって、
自装置の中継動作に用いるメモリを、前記受信ウインドウサイズを接続済みＴＣＰセッションで総和した通知済み受信ウインドウサイズ領域と、中継転送するデータを前記ＴＣＰセッションの接続先に送信する際に通信途中のデータ紛失時の再送に備えるための送信バッファ領域との２つの部分に分けて管理し、
前記送信バッファ領域の空き領域に基づいて前記受信データの中継を実施するデータ転送手段を有することを特徴とする中継装置。
【請求項２】
前記ＴＣＰセッションの接続先へ送信するデータを保持する送信バッファを、通信状況に応じて前記ＴＣＰセッションに割り当てるためにアクティブセッションの概念を導入し、前記送信バッファを必要とするセッションを管理することを特徴とする請求項１記載の中継装置。
【請求項３】
前記データ転送手段は、前記送信バッファに十分な空きが存在しなければ、何もせずにそのまま中継動作を終了し、前記受信バッファにそのまま受信データを待ち合わせておくことを特徴とする請求項２記載の中継装置。
【請求項４】
上記の請求項１から請求項３のいずれかに記載の中継装置を含むことを特徴とする通信システム。
【請求項５】
複数のＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）セッションを代理接続し、受信データを保持する受信バッファのサイズを前記ＴＣＰセッションの受信ウインドウサイズとして接続先に通知する中継装置に用いるフロー制御方法であって、
前記中継装置の中継動作に用いるメモリを、前記受信ウインドウサイズを接続済みＴＣＰセッションで総和した通知済み受信ウインドウサイズ領域と、中継転送するデータを前記ＴＣＰセッションの接続先に送信する際に通信途中のデータ紛失時の再送に備えるための送信バッファ領域との２つの部分に分けて管理し、
前記中継装置が、前記送信バッファ領域の空き領域に基づいて前記受信データの中継を実施するデータ転送処理を実行することを特徴とするフロー制御方法。
【請求項６】
前記中継装置において、前記ＴＣＰセッションの接続先へ送信するデータを保持する送信バッファを、通信状況に応じて前記ＴＣＰセッションに割り当てるためにアクティブセッションの概念を導入したことを特徴とする請求項５記載のフロー制御方法。
【請求項７】
前記データ転送処理において、前記送信バッファに十分な空きが存在しなければ、何もせずにそのまま中継動作を終了し、前記受信バッファにそのまま受信データを待ち合わせておくことを特徴とする請求項６記載のフロー制御方法。
【請求項１】
複数のＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）セッションを代理接続し、受信データを保持する受信バッファのサイズを前記ＴＣＰセッションの受信ウインドウサイズとして接続先に通知する中継装置であって、
自装置の中継動作に用いるメモリを、前記受信ウインドウサイズを接続済みＴＣＰセッションで総和した通知済み受信ウインドウサイズ領域と、中継転送するデータを前記ＴＣＰセッションの接続先に送信する際に通信途中のデータ紛失時の再送に備えるための送信バッファ領域との２つの部分に分けて管理し、
前記送信バッファ領域の空き領域に基づいて前記受信データの中継を実施するデータ転送手段を有することを特徴とする中継装置。
【請求項２】
前記ＴＣＰセッションの接続先へ送信するデータを保持する送信バッファを、通信状況に応じて前記ＴＣＰセッションに割り当てるためにアクティブセッションの概念を導入し、前記送信バッファを必要とするセッションを管理することを特徴とする請求項１記載の中継装置。
【請求項３】
前記データ転送手段は、前記送信バッファに十分な空きが存在しなければ、何もせずにそのまま中継動作を終了し、前記受信バッファにそのまま受信データを待ち合わせておくことを特徴とする請求項２記載の中継装置。
【請求項４】
上記の請求項１から請求項３のいずれかに記載の中継装置を含むことを特徴とする通信システム。
【請求項５】
複数のＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）セッションを代理接続し、受信データを保持する受信バッファのサイズを前記ＴＣＰセッションの受信ウインドウサイズとして接続先に通知する中継装置に用いるフロー制御方法であって、
前記中継装置の中継動作に用いるメモリを、前記受信ウインドウサイズを接続済みＴＣＰセッションで総和した通知済み受信ウインドウサイズ領域と、中継転送するデータを前記ＴＣＰセッションの接続先に送信する際に通信途中のデータ紛失時の再送に備えるための送信バッファ領域との２つの部分に分けて管理し、
前記中継装置が、前記送信バッファ領域の空き領域に基づいて前記受信データの中継を実施するデータ転送処理を実行することを特徴とするフロー制御方法。
【請求項６】
前記中継装置において、前記ＴＣＰセッションの接続先へ送信するデータを保持する送信バッファを、通信状況に応じて前記ＴＣＰセッションに割り当てるためにアクティブセッションの概念を導入したことを特徴とする請求項５記載のフロー制御方法。
【請求項７】
前記データ転送処理において、前記送信バッファに十分な空きが存在しなければ、何もせずにそのまま中継動作を終了し、前記受信バッファにそのまま受信データを待ち合わせておくことを特徴とする請求項６記載のフロー制御方法。
【図１】
【図２】
【図３】
【図４】
【図２】
【図３】
【図４】
【公開番号】特開２０１２−９００７１（Ｐ２０１２−９００７１Ａ）
【公開日】平成２４年５月１０日（２０１２．５．１０）
【国際特許分類】
【出願番号】特願２０１０−２３５０３１（Ｐ２０１０−２３５０３１）
【出願日】平成２２年１０月２０日（２０１０．１０．２０）
【出願人】（０００００４２３７）日本電気株式会社 (19,353)
【Ｆターム（参考）】
【公開日】平成２４年５月１０日（２０１２．５．１０）
【国際特許分類】
【出願日】平成２２年１０月２０日（２０１０．１０．２０）
【出願人】（０００００４２３７）日本電気株式会社 (19,353)
【Ｆターム（参考）】
[ Back to top ]