JP4302339B2 - データ配信管理装置、データ配信管理システムおよびデータ配信管理方法 - Google Patents
データ配信管理装置、データ配信管理システムおよびデータ配信管理方法 Download PDFInfo
- Publication number
- JP4302339B2 JP4302339B2 JP2001321030A JP2001321030A JP4302339B2 JP 4302339 B2 JP4302339 B2 JP 4302339B2 JP 2001321030 A JP2001321030 A JP 2001321030A JP 2001321030 A JP2001321030 A JP 2001321030A JP 4302339 B2 JP4302339 B2 JP 4302339B2
- Authority
- JP
- Japan
- Prior art keywords
- buffer
- destination
- data
- source
- distribution management
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Landscapes
- Data Exchanges In Wide-Area Networks (AREA)
- Communication Control (AREA)
Description
【０００１】
【発明の属する技術分野】
この発明は、送信したデータに対する送達確認応答を必要とする送信装置と該送信装置の通信相手先である受信装置との間の伝送路上に配置され、前記送信装置との間の伝送遅延が前記受信装置との間の伝送遅延に比して小さく、少なくとも前記送信装置からのデータを前記受信装置に対して転送する転送処理と該転送したデータに対する送達確認応答を作成し返送する返送処理とを行うことができるデータ配信管理装置に関し、特にデータ配信時における送達確認応答の受信タイミングに依存した速度性能劣化を改善することができるデータ配信管理装置、データ配信管理システムおよびデータ配信管理方法に関するものである。
【０００２】
【従来の技術】
図１４は、従来のデータ配信管理装置を用いたデータ配信管理システムの構成を示すブロック図である（情報処理学会研究報告98-DPS-89-12参照）。図１４において、このデータ配信管理システムは、送信装置Ｃ１１と、受信装置Ｃ１２と、この送信装置Ｃ１１および受信装置Ｃ１２にＴＣＰによる通信を行う回線Ｌ１１，Ｌ１２を介してそれぞれ接続された送信ゲートウェイ１００とを有する。回線Ｌ１２は、回線Ｌ１１に比して伝送遅延が大きい回線であり、たとえば衛星回線である。
【０００３】
図１６において、送信装置Ｃ１１は、データパケットを出力するデータパケット出力部１１１と、送信ゲートウェイ１００が作成した仮の到達確認応答を受信する仮到達確認応答受信部１１２とを有する。送信ゲートウェイ１００は、バッファ１０１および配信管理テーブル１０１を有するとともに、送信装置Ｃ１１から送信されたデータパケットを受信し、このデータパケットをバッファ１０１に蓄積させる蓄積部１０３と、回線Ｌ１２を介してバッファ１０１に蓄積したデータパケットを受信装置Ｃ１２に出力する出力部１０４と、受信装置Ｃ１２に送信したデータパケットに対する仮の送達確認応答を作成する仮送達確認応答作成部１０５と、この作成した仮の送達確認応答を送信装置Ｃ１１に送信する仮送達確認応答送信部１０６と、受信装置Ｃ１２から送られた送達確認応答を受信する送達確認応答受信部１０７と、受信したＳＹＮ（接続要求）パケットから通信情報を取得し、配信管理テーブル１０２に配信情報として記録する配信情報記録制御部１０８と、データパケットの再送処理を行う再送処理部１０９とを有する。また、受信装置Ｃ１２は、送信ゲートウェイ１００から送られたデータパケットを受信するデータパケット受信部１２１と、送信ゲートウェイ１００に対して送達確認応答を出力する送達確認応答出力部１２２とを有する。
【０００４】
送信装置Ｃ１１からデータパケットが送出されると、送信ゲートウェイ１００は、受信したデータパケットをバッファ１０１に一時的に蓄積するとともに、配信管理テーブル１０２に、このデータパケットのエントリを追加する。送信ゲートウェイ１００は、送信装置Ｃ１１から受信したデータパケットを、回線Ｌ１２を介して受信装置Ｃ１２に転送するとともに、このデータパケットに対する仮の到達確認応答のデータパケットを作成し、送信装置Ｃ１１にこの仮の到達確認応答を送信する。
【０００５】
受信装置Ｃ１２は、送信ゲートウェイ１００からデータパケットを受信すると、この受信データパケットに対する送達確認応答を作成し、この送達確認応答を送信ゲートウェイ１００に送信する。この送達確認応答には、対応するデータパケットに関するデータとこのデータパケットの到達確認状況に関するデータとが含まれる。受信装置Ｃ１２から送達確認応答を受信した送信ゲートウェイ１００は、送信ゲートウェイ１００内に保持されているデータパケットであって、この送達確認応答に対応するデータパケットをクリアする。
【０００６】
ここで、送信ゲートウェイ１００から受信装置Ｃ１２にデータパケットが送信される過程において、このデータパケットの転送に失敗し、受信装置Ｃ１２がこのデータパケットを受信することができなかった場合、送信ゲートウェイ１００は、受信装置Ｃ１２側から同一の送達確認応答を３つ続けて受信し、このデータパケットの再送処理を行う。
【０００７】
このように、従来のデータ配信管理システムでは、送信ゲートウェイ１００が、送信ゲートウェイ１００から受信装置Ｃ１２に対するデータパケットの送信と同時に、送信装置Ｃ１１に対して仮の送達確認応答（ｔｍｐＡＣＫ）を返送することによって、回線Ｌ１２の伝送遅延によるＴＣＰのウィンドウサイズの減少を防ぎ、スループットの低下をなくして速度性能の劣化を改善していた。
【０００８】
また、送信ゲートウェイ１００は、送信装置Ｃ１１からデータパケットを受信すると、仮の送達確認応答を作成し、受信装置からの送達確認応答（ＡＣＫ）を受け付けるまで、このデータパケットを保持し、３つの同一の送達確認応答（ＤｕｐｌｉｃａｔｅＡＣＫ）を受信した時点で、このデータパケットの送信を失敗と判定し、この保持しているデータパケットの再送を行うようにしていた。
【０００９】
【発明が解決しようとする課題】
ところで、従来のデータ配信管理システムにおける速度性能劣化改善方式では、送信ゲートウェイ１００は、送信装置Ｃ１１に対し、送信ゲートウェイ１００から受信装置Ｃ１２へのデータ送信と同時に、仮の送達確認応答（ｔｍｐＡＣＫ）を返すことによって、伝送遅延によるＴＣＰのウィンドウサイズの減少を防ぎ、スループットを低下させること無く配信を行うシステムであったが、この方式では、データセグメントを受信すると直ちに、全てのデータセグメントに対する仮の送達確認応答を作成し、送信していた。
【００１０】
しかし、この方式では、送信ゲートウェイ１００が、送信装置Ｃ１１における送受信バッファあるいはＷｉｎｄｏｗの状態、および回線の輻輳を考慮せず、仮の送達確認応答を返すため、送信ゲートウェイ１００および送信装置Ｃ１１の処理の負荷が高くなり、結果として速度性能の劣化防止を十分果たすことができなかったという問題点があった。
【００１１】
また、受信装置Ｃ１２からのＡＣＫを含むデータは、受信装置Ｃ１２で把握している送信装置Ｃ１１の受信Ｗｉｎｄｏｗの状態に応じて決定されたスループットで送信されてきており、送信ゲートウェイ１００においてデータが受信された時点では、送信装置Ｃ１１の受信バッファあるいはＷｉｎｄｏｗが減少していた場合にも、古いＷｉｎｄｏｗ情報に基づいたスループットでデータ転送を行っていたため、送信装置Ｃ１１の受信バッファおよびＷｉｎｄｏｗがオーバーフローを引き起こす可能性があるという問題点もあった。
【００１２】
この発明は上記に鑑みてなされたもので、送受信のバッファおよびＷｉｎｄｏｗサイズおよび回線の輻輳を考慮し、ｔｍｐＡＣＫの送信のタイミングや送信量を調整し、一層速く、一層効率的にデータの配信を行うことができるデータ配信管理装置、データ配信管理システムおよびデータ配信管理方法を得ることを目的とする。
【００１７】
【課題を解決するための手段】
上記目的を達成するため、この発明にかかるデータ配信管理装置は、少なくとも受信したデータを宛先に向けて転送するとともに、宛先からの送達確認応答を受信するまでデータセグメントを保存し、必要に応じて再送処理を行う機能を有したデータ配信管理装置において、受信したデータセグメントを保存するバッファと、送信元のスループット情報をもとに、前記バッファのバッファサイズを可変設定するバッファ管理手段と、宛先の受信バッファの状態に応じたデータ転送速度調整を行う速度調整手段と、受信したデータを宛先に向けて転送した際に、送信元に対して仮の送達確認応答を作成し、返送する仮送達確認応答手段と、前記バッファのバッファサイズ不足を予測する予測手段と、と、前記予測手段が前記バッファのバッファサイズ不足を予測した場合に、前記仮の送達確認応答の返送を停止させる制御を行うとともに、前記送信元および前記宛先のそれぞれに設定された優先度指標に応じて前記バッファサイズを調整する配信管理手段と、を備えたことを特徴とする。
【００１８】
この発明によれば、バッファ管理手段が、送信元のスループット情報をもとに、前記バッファのバッファサイズを可変設定するようにしている。また、速度調整手段が、宛先の受信バッファの状態に応じてスループットの増減幅を調整するようにしている。さらに、前記配信管理手段は、前記予測手段が前記バッファのバッファサイズ不足を予測した場合に、前記仮の送達確認応答の返送を停止させる制御を行うようにし、バッファ状態に応じて送信側のスループットを調整するとともに、送信元ＩＰと送信元ポートとの組み合わせ、および宛先ＩＰと宛先ポートとの組み合わせが全て同一の通信を一纏めとする管理単位ごとに、かつ、該送信元および該宛先のそれぞれに対して設定された優先度指標に応じて前記バッファサイズを調整するようにしている。
【００１９】
つぎの発明にかかるデータ配信管理装置は、少なくとも受信したデータを宛先に向けて転送するとともに、宛先からの送達確認応答を受信するまでデータセグメントを保存し、必要に応じて再送処理を行う機能を有したデータ配信管理装置において、受信したデータセグメントを保存するバッファと、送信元のスループット情報をもとに、前記バッファのバッファサイズを可変設定するバッファ管理手段と、宛先の受信バッファの状態に応じたデータ転送速度調整を行う速度調整手段と、受信したデータを宛先に向けて転送した際に、送信元に対して仮の送達確認応答を作成し、返送する仮送達確認応答手段と、前記バッファのバッファサイズ不足を予測する予測手段と、送信元ＩＰと送信元ポートとの組み合わせ、および宛先ＩＰと宛先ポートとの組み合わせが全て同一の通信を一の管理単位とし、該管理単位ごとに、かつ、該送信元および該宛先のそれぞれに対して、優先度の程度を表す指標を設定した優先度管理テーブルと、前記予測手段が前記バッファのバッファサイズ不足を予測した場合に、前記仮の送達確認応答の返信速度を低下させる制御を行うとともに、前記送信元および前記宛先のそれぞれに設定された優先度指標に応じて前記バッファサイズを調整する配信管理手段と、を備えたことを特徴とする。
【００２０】
この発明によれば、バッファ管理手段が、送信元のスループット情報をもとに、前記バッファのバッファサイズを可変設定するようにしている。また、速度調整手段が、宛先の受信バッファの状態に応じてスループットの増減幅を調整するようにしている。さらに、前記配信管理手段は、前記予測手段が前記バッファのバッファサイズ不足を予測した場合に、前記仮の送達確認応答の返信速度を低下させる制御を行うようにし、バッファ状態に応じて送信側のスループットを調整するとともに、送信元ＩＰと送信元ポートとの組み合わせ、および宛先ＩＰと宛先ポートとの組み合わせが全て同一の通信を一纏めとする管理単位ごとに、かつ、該送信元および該宛先のそれぞれに対して設定された優先度指標に応じて前記バッファサイズを調整するようにしている。
【００２１】
つぎの発明にかかるデータ配信管理装置は、少なくとも受信したデータを宛先に向けて転送するとともに、宛先からの送達確認応答を受信するまでデータセグメントを保存し、必要に応じて再送処理を行う機能を有したデータ配信管理装置において、受信したデータセグメントを保存するバッファと、送信元のスループット情報をもとに、前記バッファのバッファサイズを可変設定するバッファ管理手段と、宛先の受信バッファの状態に応じたデータ転送速度調整を行う速度調整手段と、受信したデータを宛先に向けて転送した際に、送信元に対して仮の送達確認応答を作成し、返送する仮送達確認応答手段と、前記バッファのバッファサイズ不足を予測する予測手段と、送信元ＩＰと送信元ポートとの組み合わせ、および宛先ＩＰと宛先ポートとの組み合わせが全て同一の通信を一の管理単位とし、該管理単位ごとに、かつ、該送信元および該宛先のそれぞれに対して、優先度の程度を表す指標を設定した優先度管理テーブルと、前記予測手段が前記バッファのバッファサイズ不足を予測した場合に、前記仮の送達確認応答のウィンドウ情報を小さくする制御を行うとともに、前記送信元および前記宛先のそれぞれに設定された優先度指標に応じて前記バッファサイズを調整する配信管理手段と、を備えたことを特徴とする。
【００２２】
この発明によれば、バッファ管理手段が、送信元のスループット情報をもとに、前記バッファのバッファサイズを可変設定するようにしている。また、速度調整手段が、宛先の受信バッファの状態に応じてスループットの増減幅を調整するようにしている。さらに、前記配信管理手段は、前記予測手段が前記バッファのバッファサイズ不足を予測した場合に、前記仮の送達確認応答のウィンドウ情報を小さくする制御を行うようにし、バッファ状態に応じて送信側のスループットを調整するとともに、送信元ＩＰと送信元ポートとの組み合わせ、および宛先ＩＰと宛先ポートとの組み合わせが全て同一の通信を一纏めとする管理単位ごとに、かつ、該送信元および該宛先のそれぞれに対して設定された優先度指標に応じて前記バッファサイズを調整するようにしている。
【００２３】
つぎの発明にかかるデータ配信管理装置は、少なくとも受信したデータを宛先に向けて転送するとともに、宛先からの送達確認応答を受信するまでデータセグメントを保存し、必要に応じて再送処理を行う機能を有したデータ配信管理装置において、受信したデータセグメントを保存するバッファと、送信元のスループット情報をもとに、前記バッファのバッファサイズを可変設定するバッファ管理手段と、宛先の受信バッファの状態に応じたデータ転送速度調整を行う速度調整手段と、受信したデータを宛先に向けて転送した際に、送信元に対して仮の送達確認応答を作成し、返送する仮送達確認応答手段と、前記バッファのバッファサイズ不足を予測する予測手段と、送信元ＩＰと送信元ポートとの組み合わせ、および宛先ＩＰと宛先ポートとの組み合わせが全て同一の通信を一の管理単位とし、該管理単位ごとに、かつ、該送信元および該宛先のそれぞれに対して、優先度の程度を表す指標を設定した優先度管理テーブルと、前記予測手段が前記バッファのバッファサイズ不足を予測した場合に、新規の前記仮の送達確認応答を利用するコネクション接続要求を受けない制御を行うとともに、前記送信元および前記宛先のそれぞれに設定された優先度指標に応じて前記バッファサイズを調整する配信管理手段と、を備えたことを特徴とする。
【００２４】
この発明によれば、バッファ管理手段が、送信元のスループット情報をもとに、前記バッファのバッファサイズを可変設定するようにしている。また、速度調整手段が、宛先の受信バッファの状態に応じてスループットの増減幅を調整するようにしている。さらに、前記配信管理手段は、前記予測手段が前記バッファのバッファサイズ不足を予測した場合に、新規の前記仮の送達確認応答を利用するコネクション接続要求を受けない制御を行うようにし、バッファ状態に応じて送信側のスループットを調整するとともに、送信元ＩＰと送信元ポートとの組み合わせ、および宛先ＩＰと宛先ポートとの組み合わせが全て同一の通信を一纏めとする管理単位ごとに、かつ、該送信元および該宛先のそれぞれに対して設定された優先度指標に応じて前記バッファサイズを調整するようにしている。
【００２７】
つぎの発明にかかるデータ配信管理装置は、上記の発明において、前記配信管理手段は、前記バッファの空き領域が、予め設定されたバッファサイズの余裕値を超えた場合に受信データ量を抑制する通信に対して、前記余裕値を超えた場合、前記受信データ量が抑制されるように該通信の送信元に指示することを特徴とする。
【００２８】
この発明によれば、前記配信管理手段は、前記バッファの空き領域が、予め設定されたバッファサイズの余裕値を超えた場合に受信データ量を抑制する通信に対して、前記余裕値を超えた場合、前記受信データ量が抑制されるように該通信の送信元に指示するようにしている。
【００２９】
つぎの発明にかかるデータ配信管理装置は、上記の発明において、選択的な速度調整を行うか否かを決定する決定手段をさらに備えたことを特徴とする。
【００３０】
この発明によれば、決定手段が、選択的な速度調整を行うか否かを決定するようにしている。
【００３１】
つぎの発明にかかるデータ配信管理システムは、データを送受信する第１の端末装置と、前記該第１の端末装置の通信相手先である第２の端末装置と、前記第１の端末装置と前記第２の端末装置との間の伝送路上に配置され、上記の発明ののいずれか一つに記載の１以上のデータ配信管理装置とを備えたことを特徴とする。
【００３２】
この発明によれば、データ配信管理装置が第１の端末装置と第２の端末装置との間に配置され、第１の端末装置あるいは第２の端末装置からのスループットの低下を防止する制御をするようにしている。
【００３７】
つぎの発明にかかるデータ配信管理方法は、少なくとも受信したデータを宛先に向けて転送するとともに、宛先からの送達確認応答を受信するまでデータセグメントを保存し、必要に応じて再送処理を行う機能を有したデータ配信管理装置のデータ配信管理方法において、受信したデータセグメントを保存する保存工程と、送信元のスループット情報および配信処理終了までにかかる時間をもとに、前記バッファのバッファサイズを可変設定するバッファ管理工程と、宛先の受信バッファの状態に応じたデータ転送速度調整を行う速度調整工程と、受信したデータを宛先に向けて転送した際に、送信元に対して仮の送達確認応答を作成し、返送する仮送達確認応答工程と、前記バッファのバッファサイズ不足を予測する予測工程と、送信元ＩＰと送信元ポートとの組み合わせ、および宛先ＩＰと宛先ポートとの組み合わせが全て同一の通信を一の管理単位とし、該管理単位ごとに、かつ、該送信元および該宛先のそれぞれに対して、優先度の程度を表す指標を設定する優先度設定工程と、前記予測工程が前記バッファのバッファサイズ不足を予測した場合に、前記仮の送達確認応答の返送を停止させる制御を行うとともに、前記送信元および前記宛先のそれぞれに設定された優先度指標に応じて前記バッファサイズを調整する配信管理工程と、を含むことを特徴とする。
【００３８】
この発明によれば、バッファ管理工程が、送信元のスループット情報をもとに、前記バッファのバッファサイズを可変設定するようにしている。また、速度調整工程が、宛先の受信バッファの状態に応じてスループットの増減幅を調整するようにしている。さらに、前記配信管理工程は、前記予測工程が前記バッファのバッファサイズ不足を予測した場合に、前記仮の送達確認応答の返送を停止させる制御を行うようにし、バッファ状態に応じて送信側のスループットを調整するとともに、送信元ＩＰと送信元ポートとの組み合わせ、および宛先ＩＰと宛先ポートとの組み合わせが全て同一の通信を一纏めとする管理単位ごとに、かつ、該送信元および該宛先のそれぞれに対して設定された優先度指標に応じて前記バッファサイズを調整するようにしている。
【００３９】
つぎの発明にかかるデータ配信管理方法は、少なくとも受信したデータを宛先に向けて転送するとともに、宛先からの送達確認応答を受信するまでデータセグメントを保存し、必要に応じて再送処理を行う機能を有したデータ配信管理装置のデータ配信管理方法において、受信したデータセグメントを保存する保存工程と、送信元のスループット情報および配信処理終了までにかかる時間をもとに、前記バッファのバッファサイズを可変設定するバッファ管理工程と、宛先の受信バッファの状態に応じたデータ転送速度調整を行う速度調整工程と、受信したデータを宛先に向けて転送した際に、送信元に対して仮の送達確認応答を作成し、返送する仮送達確認応答工程と、前記バッファのバッファサイズ不足を予測する予測工程と、送信元ＩＰと送信元ポートとの組み合わせ、および宛先ＩＰと宛先ポートとの組み合わせが全て同一の通信を一の管理単位とし、該管理単位ごとに、かつ、該送信元および該宛先のそれぞれに対して、優先度の程度を表す指標を設定する優先度設定工程と、前記予測工程が前記バッファのバッファサイズ不足を予測した場合に、前記仮の送達確認応答の返信速度を低下させる制御を行うとともに、前記仮の送達確認応答の返送を停止させる制御を行うとともに、前記送信元および前記宛先のそれぞれに設定された優先度指標に応じて前記バッファサイズを調整する配信管理工程と、を含むことを特徴とする。
【００４０】
この発明によれば、バッファ管理工程が、送信元のスループット情報をもとに、前記バッファのバッファサイズを可変設定するようにしている。また、速度調整工程が、宛先の受信バッファの状態に応じてスループットの増減幅を調整するようにしている。さらに、前記配信管理工程は、前記予測工程が前記バッファのバッファサイズ不足を予測した場合に、前記仮の送達確認応答の返信速度を低下させる制御を行うようにし、バッファ状態に応じて送信側のスループットを調整するとともに、送信元ＩＰと送信元ポートとの組み合わせ、および宛先ＩＰと宛先ポートとの組み合わせが全て同一の通信を一纏めとする管理単位ごとに、かつ、該送信元および該宛先のそれぞれに対して設定された優先度指標に応じて前記バッファサイズを調整するようにしている。
【００４１】
つぎの発明にかかるデータ配信管理方法は、少なくとも受信したデータを宛先に向けて転送するとともに、宛先からの送達確認応答を受信するまでデータセグメントを保存し、必要に応じて再送処理を行う機能を有したデータ配信管理装置のデータ配信管理方法において、受信したデータセグメントを保存する保存工程と、送信元のスループット情報および配信処理終了までにかかる時間をもとに、前記バッファのバッファサイズを可変設定するバッファ管理工程と、宛先の受信バッファの状態に応じたデータ転送速度調整を行う速度調整工程と、受信したデータを宛先に向けて転送した際に、送信元に対して仮の送達確認応答を作成し、返送する仮送達確認応答工程と、前記バッファのバッファサイズ不足を予測する予測工程と、送信元ＩＰと送信元ポートとの組み合わせ、および宛先ＩＰと宛先ポートとの組み合わせが全て同一の通信を一の管理単位とし、該管理単位ごとに、かつ、該送信元および該宛先のそれぞれに対して、優先度の程度を表す指標を設定する優先度設定工程と、前記予測工程が前記バッファのバッファサイズ不足を予測した場合に、前記仮の送達確認応答のウィンドウ情報を小さくする制御を行うとともに、前記送信元および前記宛先のそれぞれに設定された優先度指標に応じて前記バッファサイズを調整する配信管理工程と、を含むことを特徴とする。
【００４２】
この発明によれば、バッファ管理工程が、送信元のスループット情報をもとに、前記バッファのバッファサイズを可変設定するようにしている。また、速度調整工程が、宛先の受信バッファの状態に応じてスループットの増減幅を調整するようにしている。さらに、前記配信管理工程は、前記予測工程が前記バッファのバッファサイズ不足を予測した場合に、前記仮の送達確認応答のウィンドウ情報を小さくする制御を行うようにし、バッファ状態に応じて送信側のスループットを調整するとともに、送信元ＩＰと送信元ポートとの組み合わせ、および宛先ＩＰと宛先ポートとの組み合わせが全て同一の通信を一纏めとする管理単位ごとに、かつ、該送信元および該宛先のそれぞれに対して設定された優先度指標に応じて前記バッファサイズを調整するようにしている。
【００４３】
つぎの発明にかかるデータ配信管理方法は、少なくとも受信したデータを宛先に向けて転送するとともに、宛先からの送達確認応答を受信するまでデータセグメントを保存し、必要に応じて再送処理を行う機能を有したデータ配信管理装置のデータ配信管理方法において、受信したデータセグメントを保存する保存工程と、送信元のスループット情報および配信処理終了までにかかる時間をもとに、前記バッファのバッファサイズを可変設定するバッファ管理工程と、宛先の受信バッファの状態に応じたデータ転送速度調整を行う速度調整工程と、受信したデータを宛先に向けて転送した際に、送信元に対して仮の送達確認応答を作成し、返送する仮送達確認応答工程と、前記バッファのバッファサイズ不足を予測する予測工程と、送信元ＩＰと送信元ポートとの組み合わせ、および宛先ＩＰと宛先ポートとの組み合わせが全て同一の通信を一の管理単位とし、該管理単位ごとに、かつ、該送信元および該宛先のそれぞれに対して、優先度の程度を表す指標を設定する優先度設定工程と、前記予測工程が前記バッファのバッファサイズ不足を予測した場合に、新規の前記仮の送達確認応答を利用するコネクション接続要求を受けない制御を行うとともに、前記送信元および前記宛先のそれぞれに設定された優先度指標に応じて前記バッファサイズを調整する配信管理工程と、を含むことを特徴とする。
【００４４】
この発明によれば、バッファ管理工程が、送信元のスループット情報をもとに、前記バッファのバッファサイズを可変設定するようにしている。また、速度調整工程が、宛先の受信バッファの状態に応じてスループットの増減幅を調整するようにしている。さらに、前記配信管理工程は、前記予測工程が前記バッファのバッファサイズ不足を予測した場合に、新規の前記仮の送達確認応答を利用するコネクション接続要求を受けない制御を行うようにし、バッファ状態に応じて送信側のスループットを調整するとともに、送信元ＩＰと送信元ポートとの組み合わせ、および宛先ＩＰと宛先ポートとの組み合わせが全て同一の通信を一纏めとする管理単位ごとに、かつ、該送信元および該宛先のそれぞれに対して設定された優先度指標に応じて前記バッファサイズを調整するようにしている。
【００４５】
つぎの発明にかかるデータ配信管理方法は、上記の発明において、宛先毎に優先度が設定する優先度設定工程をさらに含み、前記配信管理工程は、前記優先度に応じて前記バッファサイズを調整することを特徴とする。
【００４６】
この発明によれば、前記配信管理工程は、前記優先度に応じて前記バッファサイズを調整するようにしている。
【００４７】
つぎの発明にかかるデータ配信管理方法は、上記の発明において、前記配信管理方法は、前記バッファの空き領域が、予め設定されたバッファサイズの余裕値を超えた場合に受信データ量を抑制する通信に対して、前記受信データ量が抑制されるように該通信の送信元に指示することを特徴とする。
【００４８】
この発明によれば、前記配信管理工程は、前記バッファの空き領域が、予め設定されたバッファサイズの余裕値を超えた場合に受信データ量を抑制する通信に対して、前記受信データ量が抑制されるように該通信の送信元に指示することを特徴とする。
【００４９】
つぎの発明にかかるデータ配信管理方法は、上記の発明において、選択的な速度調整を行うか否かを決定する決定工程をさらに備えたことを特徴とする。
【００５０】
この発明によれば、決定工程が、選択的な速度調整を行うか否かを決定するようにしている。
【００５１】
【発明の実施の形態】
以下、添付図面を参照して、この発明にかかるデータ配信管理装置、データ配信管理システムおよびデータ配信管理方法の好適な実施の形態を詳細に説明する。
【００５２】
実施の形態１．
図１は、この発明の実施の形態１であるデータ配信管理装置を含むデータ配信管理システムの構成を示すブロック図である。図１において、このデータ配信管理システムは、送信装置Ｃ１が回線２を介してデータ配信管理装置１０に接続され、データ配信管理装置１０が回線３を介して受信装置Ｃ２に接続される。回線３は、衛星回線などの伝送遅延の大きな回線であり、回線２は、回線３に比して伝送遅延が小さい回線である。
【００５３】
データ配信管理装置１０は、送信ゲートウェイＳＧと、配信管理テーブル１と、プロトコル管理テーブル５と、バッファの割り当てを行うバッファ割当部６ａを有した送信バッファ６と、受信バッファ７、および経路管理テーブル８を有する。送信ゲートウェイＳＧは、送信装置Ｃ１との間においてデータパケットの入出力処理を行う通信部１７と、受信装置Ｃ２との間においてデータパケットの入出力処理を行う通信部１１と、仮の送達確認応答（ｔｍｐＡＣＫ）を作成するために、受信したデータパケットを保存するｔｍｐＡＣＫバッファ４と、受信装置Ｃ２に対して送信したデータパケットに対してｔｍｐＡＣＫの返送を行うか否かを判断するｔｍｐＡＣＫ使用判定部１２、送信装置Ｃ１から受信したデータパケットをもとにｔｍｐＡＣＫを作成するｔｍｐＡＣＫ作成部１３と、データパケット毎の送達確認応答のタイムアウト時間（ＳＧＴｉｍｅｒ）をカウントアップし、この送達確認応答待ちのタイムアウトイベントを発生させるＳＧＴｉｍｅｒカウント部１４と、送信装置Ｃ１にｔｍｐＡＣＫを送信したか否かの情報および受信装置Ｃ２からの送達確認応答に関する情報を配信管理テーブル１に書き込む処理を行う配信データ記録部１５と、ＳＧＴｉｍｅｒ値および配信管理テーブル１の内容に対応してデータパケットの配信を管理するＳＧ配信管理部１６とを有する。
【００５４】
なお、図１において、送信バッファ６、受信バッファ７、およびｔｍｐＡＣＫバッファ４は、それぞれ別個のバッファとして示されているが、これに限らず、部分的あるいは全てを同一のバッファとして実装するようにしてもよい。また、別個のバッファとして実装する場合であっても、同一のバッファとして実装する場合であっても、管理目的に応じて制御情報などを含めた情報とともに用いることが可能な図示しない管理テーブルを設け、パケットデータの格納位置が識別可能なように実装することによって、管理および検索の効率化を図ることができる。
【００５５】
ここで、図２〜図８を参照して、データ配信管理装置１０のデータ配信管理処理について説明する。まず、送信ゲートウェイＳＧの通信部１７，１１は、データパケットを受信すると、この受信したデータパケットを受信バッファ７に一時保存し、ＳＧ配信管理部１６は、図２に示す配信処理を行う。
【００５６】
図２において、まず、ｔｍｐＡＣＫ使用判定部１２が、受信したデータパケットのチェックを行い、このチェック結果に応じて送信ゲートウェイＳＧがもつ受信データパケットに対するｔｍｐＡＣＫ利用可能フラグの「ＯＮ」、「ＯＦＦ」を決定し、必要に応じてｔｍｐＡＣＫ利用可能フラグの「ＯＮ」、「ＯＦＦ」も含め、受信データパケットの情報を配信管理テーブル１に登録する（ステップＳ１１）。
【００５７】
その後、ｔｍｐＡＣＫ制御フラグをもとにｔｍｐＡＣＫの利用制御を行うか否かを判断する（ステップＳ１２）。ｔｍｐＡＣＫの利用制御を行わない場合（ステップＳ１２，ＮＯ）には、そのまま本処理を終了し、ｔｍｐＡＣＫの利用制御を行う場合（ステップＳ１２，ＹＥＳ）には、ｔｍｐＡＣＫ利用制御処理を実行して（ステップＳ１３）、本処理を終了する。
【００５８】
図３は、図２に示したステップＳ１１におけるパケットのチェック処理手順を示すフローチャートである。図３において、まず、遅延依存の回線への転送か否か、すなわち、遅延の大きな回線に対する転送か否かを判断する（ステップＳ２１）。この判断は、この実施の形態１において、ネットワーク層のヘッダがＩＰヘッダであるか否か、およびＩＰヘッダであった場合、正しいＩＰアドレスとなっているかどうかを確認した後、ルーティング機能によって決定される経路が、宛先への経路上に伝送遅延回線があるか否かを、経路管理テーブル８を用いて判定する。
【００５９】
ここで、プロトコルがＩＰを用いていない場合、正しいフォーマットのアドレスではない場合、および宛先への経路が伝送遅延回線を含まない場合など（ステップＳ２１，ＮＯ）には、ｔｍｐＡＣＫ利用制御フラグを「ＯＦＦ」にし（ステップＳ２２）、受信セグメントを宛先に転送し（ステップＳ２３）、本処理を終了する。なお、このｔｍｐＡＣＫ利用可能フラグは、上述した別個のバッファあるいは同一のバッファに設けられる図示しない管理テーブルを用いる場合、この管理テーブル内の情報として保持するようにしてもよい。
【００６０】
図４は、経路管理テーブル８の内容の一例を示す図である。図４において、この経路管理テーブル８は、大きく「送信元−ルータ経路」と「ルータ−宛先経路」とに項目区分される。「送信元−ルータ経路」は、さらに「送信元ＩＰ」、「最大Ｗｉｎｄｏｗサイズ」、「送信元優先度」、および送信元−ルータ間の「スループット」に項目区分される。一方、「ルータ−宛先経路」は、ルータ、すなわち送信ゲートウェイＳＧと宛先との間の経路に関する情報群であり、たとえば、どの回線につながっているかを示す、判定対象の経路「ポート」、この「ポート」への経路の「遅延」時間、「スループット」、「宛先ＩＰ」、送信ゲートウェイＳＧで扱う通信全てのパケットを転送することができなくなった状況で発生した場合などにおいて、パケット転送の優先度の一つの判定基準となる「宛先優先度」、この宛先の「最大Ｗｉｎｄｏｗサイズ」にさらに項目区分される。
【００６１】
ここで、送信元とルータとの間の「スループット」の値には、仮ＡＣＫ機能を利用した場合と利用しない場合とによってスループットが異なる場合があるため、回線のデフォルト値およびそれ以前までの通信で使用した際の実測値による値を入れる。なお、デフォルト値は、回線の種類に応じてユーザ設定が可能であり、入力されない場合や経路によって回線が特定できない場合には例えば１Ｍｂｐｓに設定する。一方、ルータと宛先との間の「スループット」は、遅延に左右されるため、回線のデフォルトのスループットを入れる。また、「遅延」時間には、回線の持つデフォルト値、あるいはそれ以前までの通信で使用した際の実測値による値を入れる。「宛先ＩＰ」の項目は、判定対照の通信の宛先ＩＰを表したものである。したがって、ＩＰヘッダの宛先アドレス部にある宛先への経路が遅延依存の経路ではないとされた場合（ステップＳ２１，ＮＯ）、ｔｍｐＡＣＫ利用可能フラグを「ＯＦＦ」にし（ステップＳ２２）、受信セグメントを宛先に転送し（ステップＳ２３）、本処理を終了する。
【００６２】
一方、正しいＩＰアドレスであり、かつ伝送遅延を含んだ経路制御を行う通信であると判定された場合（ステップＳ２１，ＹＥＳ）には、受信したセグメントのＩＰヘッダのプロトコルのバイト列を参照し、遅延依存であるか否か、たとえば、ＴＣＰか、それ以外のプロトコルであるか否かの判定を行う（ステップＳ２４）。この判定には、図５に示すプロトコル管理テーブル５が参照される。
【００６３】
ステップＳ２４において、遅延依存のプロトコルであると判定された場合、受信したセグメントのヘッダ部のコードビット（CodeBit）を参照し、通信開始時のセグメントか否かを判定し（ステップＳ２５）、通信開始セグメントであった場合（ステップＳ２５，ＹＥＳ）、ステップＳ２８に移行する。一方、通信開始セグメントではないと判定された場合（ステップＳ２５，ＮＯ）、ステップＳ２６に移行する。
【００６４】
ステップＳ２６において、受信したセグメントが、図１に示した配信管理テーブル１に、既に登録済の通信であるか否かの判定を行う。この判定では、ＩＰヘッダ中の送信元ＩＰとＴＣＰヘッダ中の送信元ポートの組み合わせ、および宛先ＩＰと宛先ポートとの組み合わせが全て同一の通信を同一の管理単位とし、登録済の通信であると判定する。
【００６５】
ここで、図６および図７は、配信管理テーブルの一例を示す図であり、図７は、図６に示した左端の１つの受付番号（通信ＩＤ）にリンクする詳細な情報である。図６において、複数にわたる行Ｄ２５，Ｄ２６は、項目Ｄ１１〜Ｄ２４を持つ、上述した管理単位を同じくする通信に関する情報を表す。また、図７において、項目Ｄ３１〜Ｄ３３は、上述した管理単位を同じくする通信においてデータ配信管理装置１０が受信したセグメントに関する情報を表すものであり、行Ｄ２５における通信に関するデータの例である。これらの各項目は、データ配信管理装置１０が受信したセグメントから情報を取得するものである。
【００６６】
図６において、項目Ｄ１１は、この通信を一意に識別するための受付番号（通信ＩＤ）である。項目Ｄ１２は、この通信に割り当てられたｔｍｐＡＣＫ作成対象セグメントを保存するための割当バッファ量を表すものである。項目Ｄ１３は、この通信が実際にｔｍｐＡＣＫ作成対象セグメントの保存のために使用している使用バッファ量を示している。項目Ｄ１４は、管理する通信の送信元ＩＰアドレスを表すものである。項目Ｄ１５は、送信元優先度を表し、この優先度は例えば、「１」、「２」、「３」、・・・のような整数値で表され、数値の高いほど優先度が高い送信元であるという実装が可能である。項目Ｄ１６は、宛先ＩＰアドレスを表す。項目Ｄ１７は、宛先優先度を表す。この優先度は例えば、「１」、「２」、「３」、・・・のような整数値で表され、数値の高いほど優先度が高い送信元であるという実装が可能である。項目Ｄ１８は、送信元スループットであり、ここには通信開始時にはデフォルト値として、経路管理テーブル８を参照し、当該通信における送信元のデフォルトのスループットを入れ、以後、一定間隔ごとにスループットの実測値を計り更新する。通信終了時に、経路管理テーブル８のデフォルトのスループットの値も、実測値を元に再計算し更新することも可能である。項目Ｄ１９は、通信の優先度フラグであり、これは例えばＴＣＰセグメントの緊急フラグが「ＯＮ」であれば、「ＯＮ」とするという実装が可能である。項目Ｄ２０は、仮ＡＣＫ送信待ちによる速度調節に関する情報であり、仮ＡＣＫ送信待ちによる速度調節機能を用いるか否かに関するフラグ、および当該フラグが「ＯＮ」の場合はその調節のための待ち時間を示す値を入れる項目であり、項目Ｄ２１は、Ｗｉｎｄｏｗサイズ情報による速度調節機能に関する情報を入れる項目であり、この機能を用いるか否かに関するフラグおよびこのフラグが「ＯＮ」の場合はどのくらいＷｉｎｄｏｗサイズを調節するかを示す値を入れる項目である。項目Ｄ２２は、データ配信管理装置１０と宛先との間の往復時間（Round Trip Time：ＲＴＴ）を表す値であり、デフォルト値は経路管理テーブル８の「遅延」情報に書いてある値の２倍の数値を入れ、通信において値を適宜とり、交信してゆくなどの実装が可能である。項目Ｄ２３は、送信元ポート番号を表し、項目Ｄ２４は、宛先ポート番号を表す。項目Ｄ２７は、送信元および宛先におけるそれぞれの最新の送信ウィンドウサイズおよび受信ウィンドウサイズを表す。項目Ｄ２８は、現在管理している通信に割り当てられている仮ＡＣＫを利用したセグメント保存用のバッファの総量を示し（Byte単位）、項目Ｄ２９は、割り当て可能な仮ＡＣＫを利用したセグメント保存用のバッファ残量を示し、この例では、仮ＡＣＫを利用したセグメント保存用のバッファの総量を「５Ｇ」としているため、残量は（５−２．８）＝２．２Ｇとなる。項目Ｄ３０は、現在使用中の仮ＡＣＫを利用したセグメント保存用のバッファの総量を表す。
【００６７】
更に、図７において、項目Ｄ３１は、個々の通信においてデータ配信管理装置１０が受信したセグメントのシーケンス番号を表し、項目Ｄ３２は、ｔｍｐＡＣＫ送信に関する情報を表し、これは送信元に対して一定の条件が整った時などの条件付の場合を含め送信可能なセグメントか否かの情報およびｔｍｐＡＣＫを送信したか否かの情報などを値として用いるものである。項目Ｄ３３は、宛先からの送達確認応答（ＲＲＡＣＫ）に対する情報を表すものであり、この例では対応するセグメントがＲＲＡＣＫを受信済であることを表すＡＣＫ受信済およびＲＲＡＣＫの到達を待っている状態である事を表すＡＣＫ待ちの２つの値を持つものである。
【００６８】
図７は、図６の項目Ｄ２７の右列に加え、一つのテーブルとする事も可能であるが、スペースの都合上、項目Ｄ１１によって関連付けられる二つの表とした。従って、例えば項目Ｄ２５で示される一群の行は、通信ＩＤとして「１」を持ち、仮ＡＣＫを用いたセグメントを保存するために８００Ｍbyteまでの大きさのバッファを割り当てられ、当該バッファのうち現時点で７５０ＭByteのバッファを使用しており、優先度が「１」の送信元マシン「10.74.3.135」の送信ポート 「FTP.DATA」から０．６５Ｍbpsのスループットで、優先度が「１」の宛先マシン「10.74.3.200」の宛先ポート「1301」に対する通信において、通信の優先度フラグが「ＯＮ」であり、仮ＡＣＫ送信待ちによる速度調節利用フラグが「ＯＮ」であり、Ｗｉｎｄｏｗサイズ情報による速度調節利用フラグが「ＯＮ」であり、データ配信管理装置と宛先との間のＲＴＴが５４３msecである通信において、送信元の送信ウィンドウサイズおよび受信ウィンドウサイズ、および宛先の送信ウィンドウサイズおよび受信ウィンドウサイズは全て１６Kバイトであり、シーケンス番号「398」を持つセグメントは、ｔｍｐＡＣＫの送信は不可、即ちいかなる条件になった場合もｔｍｐＡＣＫの送信を行わないセグメントであり、現時点で宛先からの送達確認応答を待っている状態であることを表すものである。これらの項目および必要に応じて追加する項目を用いて、セグメントのｔｍｐＡＣＫの管理、受信確認および結果に応じた再送の制御、送信元へのｔｍｐＡＣＫおよびＲＲＡＣＫ（宛先からの送達確認応答）の送信速度の制御、宛先への転送速度の制御、データ配信管理装置１０の送受信バッファの管理を行う事ができる。
【００６９】
このような配信管理テーブル１を用いて、データ配信管理装置１０は、受信したセグメントのＩＰヘッダにある送信元ＩＰアドレスおよび宛先ＩＰアドレス、およびＴＣＰヘッダにある送信元ポート番号および宛先ポート番号を参照し、ＩＰヘッダ中の送信元ＩＰとＴＣＰヘッダ中の送信元ポートの組み合わせ、および宛先ＩＰと宛先ポートの組み合わせで表される通信が配信管理テーブル１上にあるか否かの判定を行う。判定の結果、配信管理テーブル１上に登録されている通信であったと判定された場合（ステップＳ２６，ＹＥＳ）、ステップＳ３２に移行し、受信したセグメントが、宛先の受信Ｗｉｎｄｏｗ内のセグメントであるか否かを判定し（ステップＳ３２）、宛先の受信Ｗｉｎｄｏｗ内のセグメントであった場合（ステップＳ３２，ＹＥＳ）、ステップＳ３３に移行し、ＦＩＮフラグをチェックし、最終パケット（通信終了パケット）であるか否かを判定し、通信終了ではなかった場合はステップＳ３４に移行する。
【００７０】
ステップＳ２６において、配信管理テーブル１上に登録されている通信ではないと判定された場合、ｔｍｐＡＣＫ利用制御フラグを「ＯＦＦ」にし（ステップＳ２２）、受信セグメントを宛先に転送し（ステップＳ２３）、本処理を終了する。
【００７１】
ステップＳ３３において、通信終了セグメントであった場合、受信したセグメントのエントリを登録し、同一通信内のセグメントのエントリでｔｍｐＡＣＫ利用可能となっており、かつ、ｔｍｐＡＣＫ送信済でないものを全てｔｍｐＡＣＫ利用不可とし、データ配信管理装置１０のｔｍｐＡＣＫ利用可能フラグを「ＯＦＦ」にし、ＦＩＮ受信済フラグを「ＯＮ」にし（ステップＳ３５）、受信セグメントを宛先に転送し（ステップＳ２３）、本処理を終了する。
【００７２】
ステップＳ３４において、送信元の送信Ｗｉｎｄｏｗサイズを確認し、スロースタートであるか否かを判定し、スロースタートであった場合（ステップＳ３４，ＹＥＳ）、ｔｍｐＡＣＫ利用可能フラグを「ＯＦＦ」にした（ステップＳ３６）後、受信セグメントを宛先に転送し（ステップＳ２３）、本処理を終了する。
【００７３】
一方、ステップＳ３４において、スロースタートと判定された場合、受信したセグメントが宛先からの送達確認応答か否かを判定し（ステップＳ３７）、宛先からの送達確認応答であった場合（ステップＳ３７，ＹＥＳ）、ｔｍｐＡＣＫバッファ４に、受信したセグメントを保存し、データ配信管理装置１０のＳＧ配信管理部１６の配信確認処理（図１０）に、受信装置Ｃ２から送達確認応答を受信したことを通知するイベントを発生させ、ｔｍｐＡＣＫ利用可能フラグを「ＯＮ」にセットし（ステップＳ３８）、本処理を終了する。
【００７４】
ステップＳ３７において、受信したセグメントが、宛先からの送達確認応答ではないと判定された場合、バッファの空き具合に応じて仮ＡＣＫを作成送信する処理を行うか否かを定め、さらにその仮ＡＣＫ作成に伴う処理を行う（ステップＳ３９）。この処理の詳細については、図８および図９を参照して後述する。その後、受信セグメントを宛先に転送し（ステップＳ２３）、本処理を終了する。
【００７５】
一方、ステップＳ２５において、通信開始セグメントであると判定された場合、判定を行っているセグメントを含めて、通信開始セグメントが通信の手順とおりに正しく送受信されているか否かの判定を行う（ステップＳ２８）。一連の作業により、通信開始セグメントは正しい順序で、到達された事を確認されたもののみ、ステップＳ２９においてバッファのチェック処理を行う。
【００７６】
ステップＳ２９のバッファチェックは、通信開始セグメントの送信元および宛先情報を取り出し、経路管理テーブル８および配信管理テーブル１の情報を用いて、送信元からのスループット、ルータ−宛先間の遅延情報によって、必要なバッファの容量、およびバッファの空き具合のチェックを行い、バッファが十分か否かの判定を行う。この十分か否かの判定は、（バッファ総量）−（現在使っているバッファ量）−（新規の通信に必要と予測されたバッファ量）＝（残っているバッファ量）−（新規の通信に必要と予測されたバッファ量）＞（データ配信管理装置１０が予め持っている余裕度を示すバッファ量）、との条件を満たすか否かで行う。
【００７７】
さらに、この時、バッファの空き容量が十分ではないと判定された場合、送信元、宛先、およびパケットの緊急フラグを見て、優先するべき通信か否かを判定し、優先するべき通信であると判定した場合は、たとえ、十分なバッファ容量がない場合も、割当可能フラグを立て、代わりに、緊急度に応じて他の優先度を下げるべき通信のバッファ容量の調節フラグを「ＯＮ」に割り当てるバッファ容量の再計算を行い配信管理テーブル１に記載する、ｔｍｐＡＣＫ利用可能フラグを「ＯＦＦ」にする、仮ＡＣＫ送信待ちによる速度調節フラグを「ＯＮ」にし、仮ＡＣＫ送信待ち時間を計算し、配信管理テーブル１に記載する、Ｗｉｎｄｏｗ情報による速度調節フラグを「ＯＮ」にし、速度調節のためのＷｉｎｄｏｗ情報を計算し、配信管理テーブル１に記載する、などの対策を行う。これらのフラグを立てる組み合わせは、通信毎の通信の優先度の開きとバッファの空き容量とからなる管理テーブルを用いるなどの実装が可能である。速度調節用仮ACK送信待ち時間とは、速度調節のために一定時間待ってから仮ＡＣＫを作成および送信することで、データ配信管理装置１０の処理およびデータ配信管理装置１０と送信装置Ｃ１との間のフローの削減を促すことを目的とする。例えば、仮ＡＣＫ送信待ちによる速度調節利用フラグが「ＯＮ」であった場合、各々の通信毎のタイマをデータ配信管理装置１０が持ち、指定された時間毎にフラグを「ＯＮ」にし、仮ＡＣＫを送信した時点でフラグを「ＯＦＦ」にし、再びカウントを開始するという実装が考えられる。このバッファ割当可能フラグは、バッファ割当部６ａが持ち、この一連のステップＳ２９の処理は、バッファ割当部６ａが行うものである。
【００７８】
ステップＳ２９の処理の後、バッファ割当フラグを見て、バッファ割当が可能か否かの判定を行い（ステップＳ３０）、可能でない場合はステップＳ２２に移行する。一方、ステップＳ３０において、バッファ割当可能との判断をされた場合、送信管理テーブル１にエントリを追加する（ステップＳ３１）。このステップＳ３１の処理後、受信したセグメントが宛先からの送達確認応答か否かを判定し（ステップＳ４０）、宛先からの送達確認応答であると判定された場合は、ステップＳ３８の処理を行った後、本処理を終了する。一方、宛先からの送達確認応答ではないと判定された場合（ステップＳ４０，ＮＯ）には、ｔｍｐＡＣＫ利用可能フラグを「ＯＦＦ」にし（ステップＳ４１）、受信セグメントを宛先に転送した（ステップＳ２３）後、本処理を終了する。
【００７９】
一方、ステップＳ２８において、データ配信管理装置１０が正しい順序で通信開始セグメントを受信していないと判定された場合、データ配信管理装置１０のｔｍｐＡＣＫ利用可能フラグを「ＯＦＦ」にし（ステップＳ２２）、受信セグメントを宛先に転送する（ステップＳ２３）。この時、宛先の送信管理テーブル１および経路管理テーブル８を参照し、送信管理テーブル１に載っている通信のパケットに対しては、宛先の受信装置Ｃ２の受信Ｗｉｎｄｏｗサイズおよびデータ配信管理装置１０と宛先との間のスループットに応じて、転送速度の調節を行う。ステップＳ２３の処理後、一連の処理を終了する。
【００８０】
つぎに、図８に示すフローチャートを参照して、ステップＳ３９に対応するｔｍｐＡＣＫ作成送信待ちによる速度調節処理について説明する。まず、ステップＳ３９の処理は、バッファの空き具合に応じて仮ＡＣＫを作成送信する処理を行うか否かを定め、さらにその仮ＡＣＫ作成に伴う処理を表す。これらの処理は、送信元である送信装置Ｃ１から受信し、データ配信管理装置１０において、受信装置Ｃ２に転送するとともに、ｔｍｐＡＣＫ作成および送信を行い、このｔｍｐＡＣＫ作成および送信処理(ｔｍｐＡＣＫ処理)対象となったデータセグメントを一時的に保持すると同時に、該データセグメントを一時的に保持するためのバッファの容量に関する調節を行うものである。
【００８１】
ここで、図１０は、このバッファの容量の調節の仕組みを示す模式図である。図１０において、各バッファＢ１〜Ｂ３は、上述したｔｍｐＡＣＫ処理を行ったデータセグメントを一時的に保存するためのバッファ全体を示している。バッファＢ１，Ｂ２は、データ配信管理装置１０が現在管理している通信のうち、ｔｍｐＡＣＫ処理を含む通信（通信「１」，「２」）に割り当てられたバッファであり、バッファＢ３は、通信「１」，「２」および今後新たに管理する通信のための予備的なバッファである。
【００８２】
通信「１」用のバッファＢ１が足りなくなった、あるいは足りなくなりつつあるとの判定が出された場合、予備的なバッファＢ３から、必要量Ｂ３ａを算出し、その分を、通信「１」に追加し、バッファＢ１に割り当てている。
【００８３】
さて、図８において、最初に、バッファのチェックを行う（ステップＳ５１）。このバッファチェック処理では、開始通知以外のデータセグメントを受信した場合に行うものであり（開始通知の場合は、ステップＳ２９によって処理される）、このセグメントの送信元および宛先情報を取り出し、経路管理テーブル８および配信管理テーブル１の情報を用いて、送信元からのスループット、ルータ−宛先間の遅延情報によって、必要なバッファの容量、およびバッファの空き具合のチェックを行い、バッファが十分か否かの判定を行う。この十分かどうかの判定は、（バッファ総量）−（現在使っているバッファ量）＝（残っているバッファ量）＞（データ配信管理装置１０が予め持っている余裕度を示すバッファ量）、との条件を満たすか否かで行う。さらに、この時、バッファの空き容量が十分ではないと判定された場合、送信元、宛先、およびパケットの緊急フラグを見て、優先するべき通信か否かを判定し、優先するべき通信であると判定した場合は、たとえ、十分なバッファ容量がない場合も、バッファ容量の調節フラグをオフにし、代わりに、緊急度に応じて他の優先度を下げるべき通信のバッファ容量の調節フラグを「ＯＮ」に割り当てるバッファ容量の再計算を行い、配信管理テーブル１に記載する、ｔｍｐＡＣＫ利用可能フラグを「ＯＦＦ」にする、仮ＡＣＫ送信待ちによる速度調節フラグを「ＯＮ」にし、仮ＡＣＫ送信待ち時間を計算し、配信管理テーブル１に記載する、Ｗｉｎｄｏｗ情報による速度調節フラグを「ＯＮ」にし、速度調節のためのＷｉｎｄｏｗ情報を計算し、配信管理テーブル１に記載する、などの対策を行う。これらのフラグを立てる組み合わせは、通信毎の通信の優先度の開きとバッファの空き容量とからなる管理テーブルを用いるなどの実装が可能である。また、逆に、十分なバッファ量があるとの判定がされた場合、速度調節用のフラグおよびバッファ容量の調節フラグの少なくとも一つが「ＯＮ」になっている通信があった場合（複数の場合は通信の優先度も考慮し）、その通信に対し提供可能なバッファ容量を再計算し、割り当て可能なバッファ容量の値を更新する、あるいはバッファ容量調節フラグを「ＯＦＦ」にする、ｔｍｐＡＣＫ利用可能フラグを「ＯＮ」にし、配信管理テーブル１に記載する、仮ＡＣＫ送信待ちによる速度調節フラグが「ＯＮ」の場合は、速度調節のための待ち時間を再計算し、待ち時間を短縮する、あるいは仮ＡＣＫ送信待ちによる速度調節フラグを「ＯＦＦ」にし、配信管理テーブル１に記載する、Ｗｉｎｄｏｗ情報による速度調節フラグが「ＯＮ」の場合は、速度調節のためのＷｉｎｄｏｗ情報値を再計算し、Ｗｉｎｄｏｗ情報を増加させる、あるいはＷｉｎｄｏｗ情報による速度調節フラグを「ＯＦＦ」にし、配信管理テーブル１に記載する、などの対策を行う。
【００８４】
その後、バッファ容量の調節フラグを見て、「ＯＮ」の場合（ステップＳ５２，ＹＥＳ）、ステップＳ５３に移行し、「ＯＦＦ」の場合（ステップＳ５２，ＮＯ）、配信管理テーブル１に情報を登録し、ｔｍｐＡＣＫ利用可能フラグを「ＯＮ」に設定する（ステップＳ５４）。この際、最新のセグメント到着時点における情報として、配信管理テーブル１の個々のセグメントに関する情報のエントリ毎にｔｍｐＡＣＫ利用可能かどうかの情報を設定する。なお、ｔｍｐＡＣＫ利用可能フラグを「ＯＮ」にしたセグメントは、バッファに保存する。
【００８５】
一方、バッファ容量の調節フラグを見て、「ＯＮ」の場合、仮ＡＣＫフラグが「ＯＮ」か否か（ステップＳ５１によって決定される、ｔｍｐＡＣＫ利用可能フラグが「ＯＮ」か否か）を判定し（ステップＳ５３）、「ＯＦＦ」であった場合、配信管理テーブル１にパケットに関する情報、すなわちパケット番号、ｔｍｐＡＣＫ送信を「不可」、ＲＲＡＣＫ状態に「ACK待ち」を追加し、ｔｍｐＡＣＫ利用可能フラグを「ＯＦＦ」にし（ステップＳ５５）、本処理を終了する。
【００８６】
一方、ステップＳ５３において、仮ＡＣＫフラグが「ＯＮ」であると判定された場合、仮ＡＣＫの作成および送信に関する処理を行い（ステップＳ５６）、本処理を終了する。ステップＳ５６の処理の詳細については、図９に示すフローチャートを参照して後述する。
【００８７】
図９は、ステップＳ５６に対応し、仮ＡＣＫ作成送信処理の手順を示すフローチャートである。図９において、まず、図３に示した一連の処理によって設定したＦＩＮ受信済フラグの値を参照し、通信終了セグメントが受信済か否かの判定を行う（ステップＳ６１）。ＦＩＮ受信済と判定された場合（ステップＳ６１，ＹＥＳ）、なにも行わず本処理を終了してリターンする。
【００８８】
一方、ＦＩＮ受信済と判定されなかった場合（ステップＳ６１，ＮＯ）、ｔｍｐＡＣＫバッファに保存してあるセグメントがＳＹＮ＋ＡＣＫセグメントか否かを判定する（ステップＳ６２）。ＳＹＮ＋ＡＣＫセグメントであった場合（ステップＳ６２，ＹＥＳ）、ＳＹＮ＋ＡＣＫセグメントが宛先に未転送だった場合に、この未転送のデータを転送し（ステップＳ６３）、さらに転送済みのデータを破棄し（ステップＳ６４）、本処理を終了してリターンする。
【００８９】
一方、ステップＳ６２において、ｔｍｐＡＣＫバッファに保存してあるセグメントがＳＹＮ＋ＡＣＫセグメントではないと判定された場合、仮ＡＣＫの作成対象となるセグメントを決定する（ステップＳ６５）。この時。例えばＳＡＣＫなしのＴＣＰ通信であった場合、「自分以外に自分より、シーケンス番号が大きくかつＦＩＮでないセグメントが少なくとも１つある」ことを確認し得るセグメントのうちシーケンス番号が最大のものを、仮ＡＣＫ作成対象とするという実装が考えられる。
【００９０】
その後、Ｗｉｎｄｏｗ情報による速度制御を利用するか否かを判定する（ステップＳ６６）。ステップＳ６６では、配信管理テーブル１のＷｉｎｄｏｗサイズ情報による速度調節情報をみて、速度調節のフラグが「ＯＮ」であった場合（ステップＳ６６，ＹＥＳ）、仮ＡＣＫ作成用のデータパケット（図１に示したｔｍｐＡＣＫバッファ４に入っている仮ＡＣＫ作成時に用いる仮ＡＣＫ雛型で、ステップＳ３８において保存してあるもの）に入っているＡＣＫセグメントのＷｉｎｄｏｗサイズに対し、新しく算出された値を代入する。例えば、配信管理テーブル１を用い、通信ＩＤが「１」の通信に対し、この操作を行う場合、Min(現在の送信元のＷｉｎｄｏｗサイズ，現在の宛先のＷｉｎｄｏｗサイズ)*０．７＝１６Ｋ*０．７=１１．２を新しいＷｉｎｄｏｗサイズとする。そして、仮ＡＣＫ作成用データパケットのＷｉｎｄｏｗ情報の変更処理を行って（ステップＳ６７）、仮ＡＣＫ送信待ちによる速度調節を利用するか否かの判定を行う（ステップＳ６８）。
【００９１】
ステップＳ６８では、配信管理テーブル１にあるフラグをもとに仮ＡＣＫ送信待ちによる速度調節を利用するか否かを判定する。仮ＡＣＫ送信待ちによる速度調節を利用する場合（ステップＳ６８，ＹＥＳ）には、速度調節用の仮ＡＣＫ送信待ち時間を経過したか否かを判定する（ステップＳ６９）。この判定は、データ配信管理装置１０が、通信毎に仮ＡＣＫ送信待ち用のタイマと、タイマが切れた事を示すフラグを持っている場合、そのフラグを見て判定を行う。
【００９２】
速度調節用仮ＡＣＫ送信待ち時間が経過していた場合（ステップＳ６９，ＹＥＳ）、速度調節用仮ＡＣＫ送信待ちタイマおよび関連フラグをリセットし（ステップＳ７１）、ステップＳ７２に移行する。一方、速度調節用仮ＡＣＫ送信待ち時間が経過していなかった（ステップＳ６９，ＮＯ）場合、速度調節用タイマが切れるまで待った（ステップＳ７０）後、ステップＳ７１に移行する。
【００９３】
その後、ｔｍｐＡＣＫ作成バッファに保存してあるセグメントの確認応答番号を、ステップＳ６５によって決定したｔｍｐＡＣＫ作成対象セグメントのシーケンス番号に「１」を加えた番号に書き換えたセグメントを、ｔｍｐＡＣＫとして作成する。ＳＡＣＫオプション付のＴＣＰの場合は、ステップＳ６５においてＳＡＣＫオプションを考慮したｔｍｐＡＣＫ作成対象を決定し、ステップＳ７２において、ＳＡＣＫオプションも加えた送達確認応答を作成する実装を行うことも可能である。
【００９４】
その後、ｔｍｐＡＣＫを送信し（ステップＳ７３）、送信したｔｍｐＡＣＫが対応する全ての配信管理テーブル１上にエントリしてあるセグメントの情報をｔｍｐＡＣＫ送信済にし（ステップＳ７４）、本処理を終了してリターンする。
【００９５】
つぎに、図１１に示したフローチャートを参照して、ＳＧ配信管理部１６による受信確認および再送制御の処理について説明する。図１１において、まず、受信装置Ｃ２からの送達確認応答到着を示す、イベントを受け取ったか否かを判定する（ステップＳ８１）。これは、図３のステップＳ３８に示したセグメントのチェックの処理によって発生されるイベントである。
【００９６】
受信装置Ｃ２から送達確認応答が到着していた場合（ステップＳ８１，ＹＥＳ）、さらに受信装置Ｃ２からの開始通知か否かを判定し（ステップＳ８２）、開始通知であった場合（ステップＳ８２，ＹＥＳ）、本処理を終了する。一方、受信装置Ｃ２からの開始通知ではないと判定された場合（ステップＳ８２，ＮＯ）、配信管理テーブル１に、受信した送達確認応答が示すセグメントに対する結果を記入する（ステップＳ８３）。例えば、ＳＡＣＫオプションなしの通信の場合、配信管理テーブル１のエントリのうち、ＡＣＫ受信待ちであり、かつ、受信した送達確認応答が示すセグメントより、シーケンス番号が小さいセグメントを、全てをＡＣＫ受信済にする。一方、ＳＡＣＫオプションありの通信の場合、配信管理テーブル１のエントリのうち、ＡＣＫ受信待ちであり、かつ、受信した送達確認応答が示すセグメントより、シーケンス番号が小さいセグメントで、かつＳＡＣＫオプションにないセグメントを全て受信済とする。さらに、この時、ＡＣＫ待ち状態で、かつｔｍｐＡＣＫを送信していなかったセグメントに対するＡＣＫであった場合、そのまま、受信したＡＣＫを宛先（ＡＣＫが対象とするセグメントの送信元）に対し、転送する。
【００９７】
その後、配信管理テーブル１のエントリのうちＡＣＫ受信済のセグメント全てを、送信バッファから削除する（ステップＳ８４）。なお、削除に関するタイマを持ち、一定時間ごとにまとめて、削除する方法による実装も可能である。
【００９８】
一方、ステップＳ８１において、受信装置Ｃ２からの送達確認応答受信のイベントを受けていないと判定された場合、再送タイムアウトが発生したか否かを判定する（ステップＳ８５）。再送タイムアウトが発生していないと判定された場合（ステップＳ８５，ＮＯ）、本処理を終了する。
【００９９】
一方、再送タイムアウトが発生していた場合（ステップＳ８５，ＹＥＳ）、配信管理テーブル１にあるタイムアウトが発生したセグメントのエントリの再送回数をインクリメントし、再送フラグを「ＯＮ」にし（ステップＳ８６）、さらに配信終了か否かの判定を行う（ステップＳ８７）。通常のＴＣＰ通信における配信終了セグメントの交換を検知した場合、および再送のタイムアウトを繰り返し、データ配信管理装置が再送のリトライアウトをすることにより、配信を終了する場合に配信終了と判定され、配信終了処理を行い（ステップＳ８８）、本処理を終了する。なお、再送のタイムアウト値、およびリトライアウトの回数は、送信装置Ｃ１および受信装置Ｃ２の、再送のタイムアウト値およびリトライアウト回数より、十分に長く設定される必要がある。
【０１００】
配信終了処理では、配信終了状態によって異なる処理を行う。通常のＴＣＰ通信における配信終了セグメントの交換を検知した場合、ｔｍｐＡＣＫ用バッファ、送信バッファ、受信バッファの全てにおいて、終了する通信におけるセグメントを全て、削除し、配信管理テーブル１のエントリも削除する。なお、配信管理テーブル１のエントリは、データの蓄積を兼ね、保存しておくことも可能である。また、エントリに寿命を設ける、あるいはエントリがあふれない限り残しておくという実装も可能である。
【０１０１】
一方、配信終了ではないと判定された場合（ステップＳ８７，ＮＯ）、ステップＳ８９〜Ｓ９１において再送を行う。まず、配信管理テーブル１の再送フラグが「ＯＮ」になっているものを、送信バッファのセグメントを再送し、配信管理テーブル１の再送フラグを「ＯＦＦ」にする。その後、再送タイマをリセットし（ステップＳ９０）、データ配信管理装置１０の再送回数カウンタのインクリメントを行い（ステップＳ９１）、処理を終了する。
【０１０２】
ここで、図１２および図１３を参照して、データ配信管理装置１０におけるバッファ管理の実現について説明する。図１２に示すように、送信装置Ｃ１はＴＣＰアルゴリズムで動作し、送信装置Ｃ１は、このＴＣＰアルゴリズム内の輻輳制御アルゴリズムＡ１で輻輳制御を行う。この実施の形態１におけるデータ配信管理装置１０は、この輻輳制御アルゴリズムＡ１と同等な輻輳制御機能を有するＴＣＰ輻輳制御アルゴリズムＡ２を有し、これによって、上述したバッファ管理を実現している。
【０１０３】
ＴＣＰの輻輳制御アルゴリズムは、輻輳ウィンドウ（ＣＷＮＤ）のサイズを変えることによって、転送速度の制御を行い、スロースタートと輻輳回避との２つの輻輳制御を行っている。スロースタートは、ＡＣＫを受け取る度に１つずつウィンドウサイズを指数的に増加させ、輻輳回避は、ＡＣＫを受け取る度に１つずつウィンドウサイズを線形に増加させる。そして、データの喪失が生じれば、輻輳ウィンドウサイズを減らし、データの喪失が生じない場合、輻輳ウィンドウサイズを増やすようにしている。たとえば、スロースタートの輻輳制御を行う場合、送信装置Ｃ１では、ＴＣＰの輻輳制御アルゴリズムを用いた送信量ＣＷＮＤを決定しておき、次の送信量ＣＷＮＤnewは、
ＣＷＮＤnew＝ＣＷＮＤold＋（新規受信ＡＣＫ数）＊ＭＴＵ
で算出される（ステップＳ１０１）。なお、ＭＴＵは、最大転送単位（Maximum Transmission Unit）である。
【０１０４】
一方、データ配信管理装置１０側では、ＴＣＰ輻輳制御アルゴリズムＡ２を用い、送信元からのデータ量、すなわちＣＷＮＤの増加量を予測する（ステップＳ１１１）。すなわち、データ配信管理装置１０側では、ＣＷＮＤの推移予測および接続回線の速度から、単位時間当たりにどのくらいのデータが送付され、転送先の遅延状況から、どれくらいのバッファ量を必要とするかを予測する。その後、送信装置Ｃ１側からデータ送信されると、この予測に基づいて、バッファ管理を行うことによって、ＡＣＫの返送速度の増減やＡＣＫ送信の停止を行い、これによって結果的に、送信装置Ｃ１のＣＷＮＤの増加速度の増減を制御する。また、データ配信管理装置１０は、この予測に基づいて、バッファ管理を行うことによって、ＡＣＫのＷｉｎｄｏｗ情報の拡大あるいは縮小を行い、これによって結果的に、送信装置Ｃ１の送信Ｗｉｎｄｏｗの拡大あるいは縮小する制御を行う。このように、データ配信管理装置１０内に送信装置Ｃ１側に設けられた輻輳制御アルゴリズムと同等なアルゴリズムを搭載することによって、バッファ管理を行い、結果的にデータの配信管理を行うようにしている。
【０１０５】
なお、ステップＳ２１では、遅延依存の回線であることを前提としているが、これに限らず、バーストエラーに起因した再送に伴う伝送遅延が生じる無線回線のような回線にも適用し、スプーフィング処理を行うことによってスループットの低下を防止することができる。この場合、図１４に示す処理を行うことによって、遅延依存の回線と同様に、バーストエラーに起因した再送に伴う伝送遅延に対しても、バッファ管理を行うことによって、スプーフィング処理を実行し、スループットの低下を防止するようにしている。図１４において、まず、データ配信管理装置１０は、通信すべき回線がバーストエラーが生じ易い回線であるか否かを判断する（ステップＳ１２１）。この判断は、たとえば、接続される経路毎の回線状況、すなわちバーストエラーが生じ易い回線であるか否かをテーブルとして保持しておくことによって実現される。
【０１０６】
その後、バーストエラーが生じ易い回線である場合（ステップＳ１２１，ＹＥＳ）には、転送データの一時保存を行い（ステップＳ１２２）、スプーフィング処理に備える。その後、一定期間、宛先からＡＣＫを受信しなかったか否かを判断する（ステップＳ１２３）。ＡＣＫを受信していない場合（ステップＳ１２３，ＹＥＳ）には、スプーフィング処理を実行し（ステップＳ１２４）、スループットの低下を防止し、本処理を終了する。このスプーフィング処理は、仮ＡＣＫの転送を行う上述したステップＳ１３の処理に該当する。
【０１０７】
一方、バーストエラーが生じ易い回線でない場合（ステップＳ１２１，ＮＯ）、および一定期間内に、宛先からＡＣＫを受信した場合（ステップＳ１２３，ＮＯ）には転送データを破棄した後（ステップＳ１２５）、本処理を終了する。なお、この処理は、上述した遅延依存の回線に対するスプーフィング処理と組み合わせるようにしてもよい。
【０１０８】
実施の形態２．
つぎに、この発明の実施の形態２について説明する。上述した実施の形態１では、データ配信管理装置１０を、伝送遅延の大きな回線３と小さな回線２との間に配置していたが、この実施の形態２では、送信装置Ｃ１および受信装置Ｃ２がそれぞれ送受信機能を有する端末装置とし、受信装置Ｃ２側にデータ配信管理装置１０に相当するデータ配信管理装置を設け、双方向の遅延に対して改善することができるようにしている。
【０１０９】
図１３に示すように、遅延の大きな回線３の両端にデータ配信管理装置１０，２０を設け、各データ配信管理装置１０，２０に遅延の小さい回線２ａ，２ｂを介して端末装置Ｃ２１，Ｃ２２をそれぞれ接続する。ここで、端末装置Ｃ２１，Ｃ２２は、データの送信機能および受信機能を備えている。データ配信管理装置１０は、図１に示したデータ配信管理装置１０と同じであり、端末装置Ｃ２１から送られた送信データを回線３を介して端末装置Ｃ２２に転送するとともに、端末装置Ｃ２１に対する仮の到達確認応答の返送処理を行う。データ配信管理装置２０は、データ配信管理装置１０と同様に、端末装置Ｃ２２から送られた送信データを、回線３を介して端末Ｃ２１に転送するとともに、端末装置Ｃ２２に対する仮の到達確認応答の返送処理を行う。ただし、データ配信管理装置１０，２０は、遅延の大きな回線３からデータを受信した場合、このデータの転送処理のみを行う。たとえば、データ配信管理装置２０は、データ配信管理装置１０からデータを受信した場合、このデータを端末装置Ｃ２２に転送する処理のみを行い、仮の到達確認応答の返送処理は行わない。これによって、双方向の遅延を改善した通信を行うことができる。
【０１１２】
【発明の効果】
以上説明したように、この発明によれば、バッファ管理手段は、送信元のスループット情報をもとに、自身のバッファのバッファサイズを可変設定するようにしているので、データ配信における輻輳状態を回避し、高信頼かつ高速な通信を実現できる。また、速度調整手段は、宛先の受信バッファの状態に応じてスループットの増減幅を調整するようにしているので、輻輳による伝送遅延による速度性能の劣化を改善することができるという効果を奏する。さらに、配信管理手段は、予測手段がバッファのバッファサイズ不足を予測した場合に、仮の送達確認応答の返送を停止させる制御を行うようにし、自身のバッファ状態に応じて送信側のスループットを調整するようにしているので、輻輳に応じた伝送遅延による速度性能の劣化を改善することができるという効果を奏する。また、送信元ＩＰと送信元ポートとの組み合わせ、および宛先ＩＰと宛先ポートとの組み合わせが全て同一の通信を一の管理単位とし、この管理単位ごとに、かつ、送信元および宛先のそれぞれに対して、優先度の程度を表す指標を設定した優先度管理テーブルが具備され、配信管理手段は、送信元および宛先のそれぞれに設定された優先度指標に応じてバッファサイズを調整するようにしているので、従来のデータ配信管理装置と比較して、一層速く、一層効率的なデータ配信を行うことができるという効果を奏する。
【０１１３】
つぎの発明によれば、バッファ管理手段は、送信元のスループット情報をもとに、バッファのバッファサイズを可変設定するようにしているので、データ配信における輻輳状態を回避し、高信頼かつ高速な通信を実現できる。また、速度調整手段は、宛先の受信バッファの状態に応じてスループットの増減幅を調整するようにしているので、輻輳による伝送遅延による速度性能の劣化を改善することができるという効果を奏する。さらに、配信管理手段は、予測手段がバッファのバッファサイズ不足を予測した場合に、仮の送達確認応答の返信速度を低下させる制御を行うようにし、バッファ状態に応じて送信側のスループットを調整するようにしているので、輻輳に応じた伝送遅延による速度性能の劣化を改善することができるという効果を奏する。また、送信元ＩＰと送信元ポートとの組み合わせ、および宛先ＩＰと宛先ポートとの組み合わせが全て同一の通信を一の管理単位とし、この管理単位ごとに、かつ、送信元および宛先のそれぞれに対して、優先度の程度を表す指標を設定した優先度管理テーブルが具備され、配信管理手段は、送信元および宛先のそれぞれに設定された優先度指標に応じてバッファサイズを調整するようにしているので、従来のデータ配信管理装置と比較して、一層速く、一層効率的なデータ配信を行うことができるという効果を奏する。
【０１１４】
つぎの発明によれば、バッファ管理手段は、送信元のスループット情報をもとに、バッファのバッファサイズを可変設定するようにしているので、データ配信における輻輳状態を回避し、高信頼かつ高速な通信を実現できる。また、速度調整手段は、宛先の受信バッファの状態に応じてスループットの増減幅を調整するようにしているので、輻輳による伝送遅延による速度性能の劣化を改善することができるという効果を奏する。さらに、配信管理手段は、予測手段がバッファのバッファサイズ不足を予測した場合に、仮の送達確認応答のウィンドウ情報を小さくする制御を行うようにし、バッファ状態に応じて送信側のスループットを調整するようにしているので、輻輳に応じた伝送遅延による速度性能の劣化を改善することができるという効果を奏する。また、送信元ＩＰと送信元ポートとの組み合わせ、および宛先ＩＰと宛先ポートとの組み合わせが全て同一の通信を一の管理単位とし、この管理単位ごとに、かつ、送信元および宛先のそれぞれに対して、優先度の程度を表す指標を設定した優先度管理テーブルが具備され、配信管理手段は、送信元および宛先のそれぞれに設定された優先度指標に応じてバッファサイズを調整するようにしているので、従来のデータ配信管理装置と比較して、一層速く、一層効率的なデータ配信を行うことができるという効果を奏する。
【０１１５】
つぎの発明によれば、バッファ管理手段は、送信元のスループット情報をもとに、バッファのバッファサイズを可変設定するようにしているので、データ配信における輻輳状態を回避し、高信頼かつ高速な通信を実現できる。また、速度調整手段は、宛先の受信バッファの状態に応じてスループットの増減幅を調整するようにしているので、輻輳による伝送遅延による速度性能の劣化を改善することができるという効果を奏する。さらに、配信管理手段は、予測手段がバッファのバッファサイズ不足を予測した場合に、新規の仮の送達確認応答を利用するコネクション接続要求を受けない制御を行うようにし、バッファ状態に応じて送信側のスループットを調整するようにしているので、輻輳に応じた伝送遅延による速度性能の劣化を改善することができるという効果を奏する。また、送信元ＩＰと送信元ポートとの組み合わせ、および宛先ＩＰと宛先ポートとの組み合わせが全て同一の通信を一の管理単位とし、この管理単位ごとに、かつ、送信元および宛先のそれぞれに対して、優先度の程度を表す指標を設定した優先度管理テーブルが具備され、配信管理手段は、送信元および宛先のそれぞれに設定された優先度指標に応じてバッファサイズを調整するようにしているので、従来のデータ配信管理装置と比較して、一層速く、一層効率的なデータ配信を行うことができるという効果を奏する。
【０１１７】
つぎの発明によれば、前記配信管理手段は、前記バッファの空き領域が、予め設定されたバッファサイズの余裕値を超えた場合に受信データ量を抑制する通信に対して、前記受信データ量が抑制されるように該通信の送信元に指示するようにしているので、柔軟かつ効率的なデータ配信を行うことができるという効果を奏する。
【０１１８】
つぎの発明によれば、決定手段が、選択的な速度調整を行うか否かを決定するようにしているので、柔軟かつ効率的なデータ配信を行うことができるという効果を奏する。
【０１１９】
つぎの発明によれば、データ配信管理装置が第１の端末装置と第２の端末装置との間に配置され、第１の端末装置あるいは第２の端末装置からのスループットの低下を防止する制御するようにしているので、輻輳に応じた伝送遅延による速度性能の劣化を改善することができるという効果を奏する。
【０１２２】
つぎの発明によれば、バッファ管理工程は、送信元のスループット情報をもとに、バッファのバッファサイズを可変設定するようにしているので、データ配信における輻輳状態を回避し、高信頼かつ高速な通信を実現できる。また、速度調整工程は、宛先の受信バッファの状態に応じてスループットの増減幅を調整するようにしているので、輻輳による伝送遅延による速度性能の劣化を改善することができるという効果を奏する。さらに、配信管理工程は、予測工程がバッファのバッファサイズ不足を予測した場合に、仮の送達確認応答の返送を停止させる制御を行うようにし、バッファ状態に応じて送信側のスループットを調整するようにしているので、輻輳に応じた伝送遅延による速度性能の劣化を改善することができるという効果を奏する。また、送信元ＩＰと送信元ポートとの組み合わせ、および宛先ＩＰと宛先ポートとの組み合わせが全て同一の通信を一の管理単位とし、この管理単位ごとに、かつ、送信元および宛先のそれぞれに対して、優先度の程度を表す指標を設定した優先度管理テーブルが具備され、配信管理工程は、送信元および宛先のそれぞれに設定された優先度指標に応じてバッファサイズを調整するようにしているので、従来のデータ配信管理装置と比較して、一層速く、一層効率的なデータ配信を行うことができるという効果を奏する。
【０１２３】
つぎの発明によれば、バッファ管理工程は、送信元のスループット情報をもとに、バッファのバッファサイズを可変設定するようにしているので、データ配信における輻輳状態を回避し、高信頼かつ高速な通信を実現できる。また、速度調整工程は、宛先の受信バッファの状態に応じてスループットの増減幅を調整するようにしているので、輻輳による伝送遅延による速度性能の劣化を改善することができるという効果を奏する。さらに、配信管理工程は、予測工程がバッファのバッファサイズ不足を予測した場合に、仮の送達確認応答の返信速度を低下させる制御を行うようにし、バッファ状態に応じて送信側のスループットを調整するようにしているので、輻輳に応じた伝送遅延による速度性能の劣化を改善することができるという効果を奏する。また、また、送信元ＩＰと送信元ポートとの組み合わせ、および宛先ＩＰと宛先ポートとの組み合わせが全て同一の通信を一の管理単位とし、この管理単位ごとに、かつ、送信元および宛先のそれぞれに対して、優先度の程度を表す指標を設定した優先度管理テーブルが具備され、配信管理工程は、送信元および宛先のそれぞれに設定された優先度指標に応じてバッファサイズを調整するようにしているので、従来のデータ配信管理装置と比較して、一層速く、一層効率的なデータ配信を行うことができるという効果を奏する。
【０１２４】
つぎの発明によれば、バッファ管理工程は、送信元のスループット情報をもとに、バッファのバッファサイズを可変設定するようにしているので、データ配信における輻輳状態を回避し、高信頼かつ高速な通信を実現できる。また、速度調整工程は、宛先の受信バッファの状態に応じてスループットの増減幅を調整するようにしているので、輻輳による伝送遅延による速度性能の劣化を改善することができるという効果を奏する。さらに、配信管理工程は、予測工程がバッファのバッファサイズ不足を予測した場合に、仮の送達確認応答のウィンドウ情報を小さくする制御を行うようにし、バッファ状態に応じて送信側のスループットを調整するようにしているので、輻輳に応じた伝送遅延による速度性能の劣化を改善することができるという効果を奏する。また、また、送信元ＩＰと送信元ポートとの組み合わせ、および宛先ＩＰと宛先ポートとの組み合わせが全て同一の通信を一の管理単位とし、この管理単位ごとに、かつ、送信元および宛先のそれぞれに対して、優先度の程度を表す指標を設定した優先度管理テーブルが具備され、配信管理工程は、送信元および宛先のそれぞれに設定された優先度指標に応じてバッファサイズを調整するようにしているので、従来のデータ配信管理装置と比較して、一層速く、一層効率的なデータ配信を行うことができるという効果を奏する。
【０１２５】
つぎの発明によれば、バッファ管理工程は、送信元のスループット情報をもとに、バッファのバッファサイズを可変設定するようにしているので、データ配信における輻輳状態を回避し、高信頼かつ高速な通信を実現できる。また、速度調整工程は、宛先の受信バッファの状態に応じてスループットの増減幅を調整するようにしているので、輻輳による伝送遅延による速度性能の劣化を改善することができるという効果を奏する。さらに、配信管理工程は、予測工程がバッファのバッファサイズ不足を予測した場合に、新規の仮の送達確認応答を利用するコネクション接続要求を受けない制御を行うようにし、バッファ状態に応じて送信側のスループットを調整するようにしているので、輻輳に応じた伝送遅延による速度性能の劣化を改善することができるという効果を奏する。また、また、送信元ＩＰと送信元ポートとの組み合わせ、および宛先ＩＰと宛先ポートとの組み合わせが全て同一の通信を一の管理単位とし、この管理単位ごとに、かつ、送信元および宛先のそれぞれに対して、優先度の程度を表す指標を設定した優先度管理テーブルが具備され、配信管理工程は、送信元および宛先のそれぞれに設定された優先度指標に応じてバッファサイズを調整するようにしているので、従来のデータ配信管理装置と比較して、一層速く、一層効率的なデータ配信を行うことができるという効果を奏する。
【０１２７】
つぎの発明によれば、前記配信管理工程は、前記バッファの空き領域が、予め設定されたバッファサイズの余裕値を超えた場合に受信データ量を抑制する通信に対して、前記受信データ量が抑制されるように該通信の送信元に指示するようにしているので、柔軟かつ効率的なデータ配信を行うことができるという効果を奏する。
【０１２８】
つぎの発明によれば、決定工程が、選択的な速度調整を行うか否かを決定するようにしているので、柔軟かつ効率的なデータ配信を行うことができるという効果を奏する。
【図面の簡単な説明】
【図１】 この発明の実施の形態１であるデータ配信管理装置を含むデータ配信管理システムの構成を示すブロック図である。
【図２】 図１に示したデータ配信管理装置によるデータ配信管理処理手順を示すフローチャートである。
【図３】 図２に示したパケットのチェック処理手順を示す詳細フローチャートである。
【図４】 図１に示した経路管理テーブルの内容の一例を示す図である。
【図５】 図１に示したプロトコル管理テーブルの内容の一例を示す図である。
【図６】 図１に示した配信管理テーブルの内容の一例を示す図である。
【図７】 図１に示した配信管理テーブルの内容の一例を示す図である。
【図８】 ステップＳ３９に対応したｔｍｐＡＣＫ作成送信待ちによる速度調整の処理手順を示すフローチャートである。
【図９】 ステップＳ５６に対応した仮ＡＣＫ作成送信処理の手順を示すフローチャートである。
【図１０】 バッファ区分を示す図である。
【図１１】 受信確認および再送制御の処理手順を示すフローチャートである。
【図１２】 ＴＣＰ輻輳制御アルゴリズムが搭載されるデータ配信管理装置を示す図である。
【図１３】 ＴＣＰ輻輳制御アルゴリズムが搭載されるデータ配信管理装置と送信装置との間におけるデータ配信管理処理を示すフローチャートである。
【図１４】 バーストエラーが生じ易い回線に対するスプーフィング処理の適用処理手順を示すフローチャートである。
【図１５】 この発明の実施の形態４であって、二つのデータ配信管理装置を用いて双方向通信を可能にしたデータ配信管理システムの構成を示すブロック図である。
【図１６】 従来のデータ配信管理装置を含むデータ配信管理システムの構成を示すブロック図である。
【符号の説明】
１ 配信管理テーブル、２，２ａ，２ｂ，３ 回線、４ ｔｍｐＡＣＫバッファ、５ プロトコル管理テーブル、６ 送信バッファ、６ａ バッファ割当部、７ 受信バッファ、８ 経路管理テーブル、１０，２０ データ配信管理装置、１１，１７ 通信部、１２ ｔｍｐＡＣＫ使用判定部、１３ ｔｍｐＡＣＫ作成部、１４ ＳＧＴｉｍｅｒカウント部、１５ 配信データ記録部、１６ ＳＧ配信管理部、ＳＧ 送信ゲートウェイ、Ｃ１ 送信装置、Ｃ２ 受信装置、Ｃ２１，Ｃ２２ 端末装置。
【発明の属する技術分野】
この発明は、送信したデータに対する送達確認応答を必要とする送信装置と該送信装置の通信相手先である受信装置との間の伝送路上に配置され、前記送信装置との間の伝送遅延が前記受信装置との間の伝送遅延に比して小さく、少なくとも前記送信装置からのデータを前記受信装置に対して転送する転送処理と該転送したデータに対する送達確認応答を作成し返送する返送処理とを行うことができるデータ配信管理装置に関し、特にデータ配信時における送達確認応答の受信タイミングに依存した速度性能劣化を改善することができるデータ配信管理装置、データ配信管理システムおよびデータ配信管理方法に関するものである。
【０００２】
【従来の技術】
図１４は、従来のデータ配信管理装置を用いたデータ配信管理システムの構成を示すブロック図である（情報処理学会研究報告98-DPS-89-12参照）。図１４において、このデータ配信管理システムは、送信装置Ｃ１１と、受信装置Ｃ１２と、この送信装置Ｃ１１および受信装置Ｃ１２にＴＣＰによる通信を行う回線Ｌ１１，Ｌ１２を介してそれぞれ接続された送信ゲートウェイ１００とを有する。回線Ｌ１２は、回線Ｌ１１に比して伝送遅延が大きい回線であり、たとえば衛星回線である。
【０００３】
図１６において、送信装置Ｃ１１は、データパケットを出力するデータパケット出力部１１１と、送信ゲートウェイ１００が作成した仮の到達確認応答を受信する仮到達確認応答受信部１１２とを有する。送信ゲートウェイ１００は、バッファ１０１および配信管理テーブル１０１を有するとともに、送信装置Ｃ１１から送信されたデータパケットを受信し、このデータパケットをバッファ１０１に蓄積させる蓄積部１０３と、回線Ｌ１２を介してバッファ１０１に蓄積したデータパケットを受信装置Ｃ１２に出力する出力部１０４と、受信装置Ｃ１２に送信したデータパケットに対する仮の送達確認応答を作成する仮送達確認応答作成部１０５と、この作成した仮の送達確認応答を送信装置Ｃ１１に送信する仮送達確認応答送信部１０６と、受信装置Ｃ１２から送られた送達確認応答を受信する送達確認応答受信部１０７と、受信したＳＹＮ（接続要求）パケットから通信情報を取得し、配信管理テーブル１０２に配信情報として記録する配信情報記録制御部１０８と、データパケットの再送処理を行う再送処理部１０９とを有する。また、受信装置Ｃ１２は、送信ゲートウェイ１００から送られたデータパケットを受信するデータパケット受信部１２１と、送信ゲートウェイ１００に対して送達確認応答を出力する送達確認応答出力部１２２とを有する。
【０００４】
送信装置Ｃ１１からデータパケットが送出されると、送信ゲートウェイ１００は、受信したデータパケットをバッファ１０１に一時的に蓄積するとともに、配信管理テーブル１０２に、このデータパケットのエントリを追加する。送信ゲートウェイ１００は、送信装置Ｃ１１から受信したデータパケットを、回線Ｌ１２を介して受信装置Ｃ１２に転送するとともに、このデータパケットに対する仮の到達確認応答のデータパケットを作成し、送信装置Ｃ１１にこの仮の到達確認応答を送信する。
【０００５】
受信装置Ｃ１２は、送信ゲートウェイ１００からデータパケットを受信すると、この受信データパケットに対する送達確認応答を作成し、この送達確認応答を送信ゲートウェイ１００に送信する。この送達確認応答には、対応するデータパケットに関するデータとこのデータパケットの到達確認状況に関するデータとが含まれる。受信装置Ｃ１２から送達確認応答を受信した送信ゲートウェイ１００は、送信ゲートウェイ１００内に保持されているデータパケットであって、この送達確認応答に対応するデータパケットをクリアする。
【０００６】
ここで、送信ゲートウェイ１００から受信装置Ｃ１２にデータパケットが送信される過程において、このデータパケットの転送に失敗し、受信装置Ｃ１２がこのデータパケットを受信することができなかった場合、送信ゲートウェイ１００は、受信装置Ｃ１２側から同一の送達確認応答を３つ続けて受信し、このデータパケットの再送処理を行う。
【０００７】
このように、従来のデータ配信管理システムでは、送信ゲートウェイ１００が、送信ゲートウェイ１００から受信装置Ｃ１２に対するデータパケットの送信と同時に、送信装置Ｃ１１に対して仮の送達確認応答（ｔｍｐＡＣＫ）を返送することによって、回線Ｌ１２の伝送遅延によるＴＣＰのウィンドウサイズの減少を防ぎ、スループットの低下をなくして速度性能の劣化を改善していた。
【０００８】
また、送信ゲートウェイ１００は、送信装置Ｃ１１からデータパケットを受信すると、仮の送達確認応答を作成し、受信装置からの送達確認応答（ＡＣＫ）を受け付けるまで、このデータパケットを保持し、３つの同一の送達確認応答（ＤｕｐｌｉｃａｔｅＡＣＫ）を受信した時点で、このデータパケットの送信を失敗と判定し、この保持しているデータパケットの再送を行うようにしていた。
【０００９】
【発明が解決しようとする課題】
ところで、従来のデータ配信管理システムにおける速度性能劣化改善方式では、送信ゲートウェイ１００は、送信装置Ｃ１１に対し、送信ゲートウェイ１００から受信装置Ｃ１２へのデータ送信と同時に、仮の送達確認応答（ｔｍｐＡＣＫ）を返すことによって、伝送遅延によるＴＣＰのウィンドウサイズの減少を防ぎ、スループットを低下させること無く配信を行うシステムであったが、この方式では、データセグメントを受信すると直ちに、全てのデータセグメントに対する仮の送達確認応答を作成し、送信していた。
【００１０】
しかし、この方式では、送信ゲートウェイ１００が、送信装置Ｃ１１における送受信バッファあるいはＷｉｎｄｏｗの状態、および回線の輻輳を考慮せず、仮の送達確認応答を返すため、送信ゲートウェイ１００および送信装置Ｃ１１の処理の負荷が高くなり、結果として速度性能の劣化防止を十分果たすことができなかったという問題点があった。
【００１１】
また、受信装置Ｃ１２からのＡＣＫを含むデータは、受信装置Ｃ１２で把握している送信装置Ｃ１１の受信Ｗｉｎｄｏｗの状態に応じて決定されたスループットで送信されてきており、送信ゲートウェイ１００においてデータが受信された時点では、送信装置Ｃ１１の受信バッファあるいはＷｉｎｄｏｗが減少していた場合にも、古いＷｉｎｄｏｗ情報に基づいたスループットでデータ転送を行っていたため、送信装置Ｃ１１の受信バッファおよびＷｉｎｄｏｗがオーバーフローを引き起こす可能性があるという問題点もあった。
【００１２】
この発明は上記に鑑みてなされたもので、送受信のバッファおよびＷｉｎｄｏｗサイズおよび回線の輻輳を考慮し、ｔｍｐＡＣＫの送信のタイミングや送信量を調整し、一層速く、一層効率的にデータの配信を行うことができるデータ配信管理装置、データ配信管理システムおよびデータ配信管理方法を得ることを目的とする。
【００１７】
【課題を解決するための手段】
上記目的を達成するため、この発明にかかるデータ配信管理装置は、少なくとも受信したデータを宛先に向けて転送するとともに、宛先からの送達確認応答を受信するまでデータセグメントを保存し、必要に応じて再送処理を行う機能を有したデータ配信管理装置において、受信したデータセグメントを保存するバッファと、送信元のスループット情報をもとに、前記バッファのバッファサイズを可変設定するバッファ管理手段と、宛先の受信バッファの状態に応じたデータ転送速度調整を行う速度調整手段と、受信したデータを宛先に向けて転送した際に、送信元に対して仮の送達確認応答を作成し、返送する仮送達確認応答手段と、前記バッファのバッファサイズ不足を予測する予測手段と、と、前記予測手段が前記バッファのバッファサイズ不足を予測した場合に、前記仮の送達確認応答の返送を停止させる制御を行うとともに、前記送信元および前記宛先のそれぞれに設定された優先度指標に応じて前記バッファサイズを調整する配信管理手段と、を備えたことを特徴とする。
【００１８】
この発明によれば、バッファ管理手段が、送信元のスループット情報をもとに、前記バッファのバッファサイズを可変設定するようにしている。また、速度調整手段が、宛先の受信バッファの状態に応じてスループットの増減幅を調整するようにしている。さらに、前記配信管理手段は、前記予測手段が前記バッファのバッファサイズ不足を予測した場合に、前記仮の送達確認応答の返送を停止させる制御を行うようにし、バッファ状態に応じて送信側のスループットを調整するとともに、送信元ＩＰと送信元ポートとの組み合わせ、および宛先ＩＰと宛先ポートとの組み合わせが全て同一の通信を一纏めとする管理単位ごとに、かつ、該送信元および該宛先のそれぞれに対して設定された優先度指標に応じて前記バッファサイズを調整するようにしている。
【００１９】
つぎの発明にかかるデータ配信管理装置は、少なくとも受信したデータを宛先に向けて転送するとともに、宛先からの送達確認応答を受信するまでデータセグメントを保存し、必要に応じて再送処理を行う機能を有したデータ配信管理装置において、受信したデータセグメントを保存するバッファと、送信元のスループット情報をもとに、前記バッファのバッファサイズを可変設定するバッファ管理手段と、宛先の受信バッファの状態に応じたデータ転送速度調整を行う速度調整手段と、受信したデータを宛先に向けて転送した際に、送信元に対して仮の送達確認応答を作成し、返送する仮送達確認応答手段と、前記バッファのバッファサイズ不足を予測する予測手段と、送信元ＩＰと送信元ポートとの組み合わせ、および宛先ＩＰと宛先ポートとの組み合わせが全て同一の通信を一の管理単位とし、該管理単位ごとに、かつ、該送信元および該宛先のそれぞれに対して、優先度の程度を表す指標を設定した優先度管理テーブルと、前記予測手段が前記バッファのバッファサイズ不足を予測した場合に、前記仮の送達確認応答の返信速度を低下させる制御を行うとともに、前記送信元および前記宛先のそれぞれに設定された優先度指標に応じて前記バッファサイズを調整する配信管理手段と、を備えたことを特徴とする。
【００２０】
この発明によれば、バッファ管理手段が、送信元のスループット情報をもとに、前記バッファのバッファサイズを可変設定するようにしている。また、速度調整手段が、宛先の受信バッファの状態に応じてスループットの増減幅を調整するようにしている。さらに、前記配信管理手段は、前記予測手段が前記バッファのバッファサイズ不足を予測した場合に、前記仮の送達確認応答の返信速度を低下させる制御を行うようにし、バッファ状態に応じて送信側のスループットを調整するとともに、送信元ＩＰと送信元ポートとの組み合わせ、および宛先ＩＰと宛先ポートとの組み合わせが全て同一の通信を一纏めとする管理単位ごとに、かつ、該送信元および該宛先のそれぞれに対して設定された優先度指標に応じて前記バッファサイズを調整するようにしている。
【００２１】
つぎの発明にかかるデータ配信管理装置は、少なくとも受信したデータを宛先に向けて転送するとともに、宛先からの送達確認応答を受信するまでデータセグメントを保存し、必要に応じて再送処理を行う機能を有したデータ配信管理装置において、受信したデータセグメントを保存するバッファと、送信元のスループット情報をもとに、前記バッファのバッファサイズを可変設定するバッファ管理手段と、宛先の受信バッファの状態に応じたデータ転送速度調整を行う速度調整手段と、受信したデータを宛先に向けて転送した際に、送信元に対して仮の送達確認応答を作成し、返送する仮送達確認応答手段と、前記バッファのバッファサイズ不足を予測する予測手段と、送信元ＩＰと送信元ポートとの組み合わせ、および宛先ＩＰと宛先ポートとの組み合わせが全て同一の通信を一の管理単位とし、該管理単位ごとに、かつ、該送信元および該宛先のそれぞれに対して、優先度の程度を表す指標を設定した優先度管理テーブルと、前記予測手段が前記バッファのバッファサイズ不足を予測した場合に、前記仮の送達確認応答のウィンドウ情報を小さくする制御を行うとともに、前記送信元および前記宛先のそれぞれに設定された優先度指標に応じて前記バッファサイズを調整する配信管理手段と、を備えたことを特徴とする。
【００２２】
この発明によれば、バッファ管理手段が、送信元のスループット情報をもとに、前記バッファのバッファサイズを可変設定するようにしている。また、速度調整手段が、宛先の受信バッファの状態に応じてスループットの増減幅を調整するようにしている。さらに、前記配信管理手段は、前記予測手段が前記バッファのバッファサイズ不足を予測した場合に、前記仮の送達確認応答のウィンドウ情報を小さくする制御を行うようにし、バッファ状態に応じて送信側のスループットを調整するとともに、送信元ＩＰと送信元ポートとの組み合わせ、および宛先ＩＰと宛先ポートとの組み合わせが全て同一の通信を一纏めとする管理単位ごとに、かつ、該送信元および該宛先のそれぞれに対して設定された優先度指標に応じて前記バッファサイズを調整するようにしている。
【００２３】
つぎの発明にかかるデータ配信管理装置は、少なくとも受信したデータを宛先に向けて転送するとともに、宛先からの送達確認応答を受信するまでデータセグメントを保存し、必要に応じて再送処理を行う機能を有したデータ配信管理装置において、受信したデータセグメントを保存するバッファと、送信元のスループット情報をもとに、前記バッファのバッファサイズを可変設定するバッファ管理手段と、宛先の受信バッファの状態に応じたデータ転送速度調整を行う速度調整手段と、受信したデータを宛先に向けて転送した際に、送信元に対して仮の送達確認応答を作成し、返送する仮送達確認応答手段と、前記バッファのバッファサイズ不足を予測する予測手段と、送信元ＩＰと送信元ポートとの組み合わせ、および宛先ＩＰと宛先ポートとの組み合わせが全て同一の通信を一の管理単位とし、該管理単位ごとに、かつ、該送信元および該宛先のそれぞれに対して、優先度の程度を表す指標を設定した優先度管理テーブルと、前記予測手段が前記バッファのバッファサイズ不足を予測した場合に、新規の前記仮の送達確認応答を利用するコネクション接続要求を受けない制御を行うとともに、前記送信元および前記宛先のそれぞれに設定された優先度指標に応じて前記バッファサイズを調整する配信管理手段と、を備えたことを特徴とする。
【００２４】
この発明によれば、バッファ管理手段が、送信元のスループット情報をもとに、前記バッファのバッファサイズを可変設定するようにしている。また、速度調整手段が、宛先の受信バッファの状態に応じてスループットの増減幅を調整するようにしている。さらに、前記配信管理手段は、前記予測手段が前記バッファのバッファサイズ不足を予測した場合に、新規の前記仮の送達確認応答を利用するコネクション接続要求を受けない制御を行うようにし、バッファ状態に応じて送信側のスループットを調整するとともに、送信元ＩＰと送信元ポートとの組み合わせ、および宛先ＩＰと宛先ポートとの組み合わせが全て同一の通信を一纏めとする管理単位ごとに、かつ、該送信元および該宛先のそれぞれに対して設定された優先度指標に応じて前記バッファサイズを調整するようにしている。
【００２７】
つぎの発明にかかるデータ配信管理装置は、上記の発明において、前記配信管理手段は、前記バッファの空き領域が、予め設定されたバッファサイズの余裕値を超えた場合に受信データ量を抑制する通信に対して、前記余裕値を超えた場合、前記受信データ量が抑制されるように該通信の送信元に指示することを特徴とする。
【００２８】
この発明によれば、前記配信管理手段は、前記バッファの空き領域が、予め設定されたバッファサイズの余裕値を超えた場合に受信データ量を抑制する通信に対して、前記余裕値を超えた場合、前記受信データ量が抑制されるように該通信の送信元に指示するようにしている。
【００２９】
つぎの発明にかかるデータ配信管理装置は、上記の発明において、選択的な速度調整を行うか否かを決定する決定手段をさらに備えたことを特徴とする。
【００３０】
この発明によれば、決定手段が、選択的な速度調整を行うか否かを決定するようにしている。
【００３１】
つぎの発明にかかるデータ配信管理システムは、データを送受信する第１の端末装置と、前記該第１の端末装置の通信相手先である第２の端末装置と、前記第１の端末装置と前記第２の端末装置との間の伝送路上に配置され、上記の発明ののいずれか一つに記載の１以上のデータ配信管理装置とを備えたことを特徴とする。
【００３２】
この発明によれば、データ配信管理装置が第１の端末装置と第２の端末装置との間に配置され、第１の端末装置あるいは第２の端末装置からのスループットの低下を防止する制御をするようにしている。
【００３７】
つぎの発明にかかるデータ配信管理方法は、少なくとも受信したデータを宛先に向けて転送するとともに、宛先からの送達確認応答を受信するまでデータセグメントを保存し、必要に応じて再送処理を行う機能を有したデータ配信管理装置のデータ配信管理方法において、受信したデータセグメントを保存する保存工程と、送信元のスループット情報および配信処理終了までにかかる時間をもとに、前記バッファのバッファサイズを可変設定するバッファ管理工程と、宛先の受信バッファの状態に応じたデータ転送速度調整を行う速度調整工程と、受信したデータを宛先に向けて転送した際に、送信元に対して仮の送達確認応答を作成し、返送する仮送達確認応答工程と、前記バッファのバッファサイズ不足を予測する予測工程と、送信元ＩＰと送信元ポートとの組み合わせ、および宛先ＩＰと宛先ポートとの組み合わせが全て同一の通信を一の管理単位とし、該管理単位ごとに、かつ、該送信元および該宛先のそれぞれに対して、優先度の程度を表す指標を設定する優先度設定工程と、前記予測工程が前記バッファのバッファサイズ不足を予測した場合に、前記仮の送達確認応答の返送を停止させる制御を行うとともに、前記送信元および前記宛先のそれぞれに設定された優先度指標に応じて前記バッファサイズを調整する配信管理工程と、を含むことを特徴とする。
【００３８】
この発明によれば、バッファ管理工程が、送信元のスループット情報をもとに、前記バッファのバッファサイズを可変設定するようにしている。また、速度調整工程が、宛先の受信バッファの状態に応じてスループットの増減幅を調整するようにしている。さらに、前記配信管理工程は、前記予測工程が前記バッファのバッファサイズ不足を予測した場合に、前記仮の送達確認応答の返送を停止させる制御を行うようにし、バッファ状態に応じて送信側のスループットを調整するとともに、送信元ＩＰと送信元ポートとの組み合わせ、および宛先ＩＰと宛先ポートとの組み合わせが全て同一の通信を一纏めとする管理単位ごとに、かつ、該送信元および該宛先のそれぞれに対して設定された優先度指標に応じて前記バッファサイズを調整するようにしている。
【００３９】
つぎの発明にかかるデータ配信管理方法は、少なくとも受信したデータを宛先に向けて転送するとともに、宛先からの送達確認応答を受信するまでデータセグメントを保存し、必要に応じて再送処理を行う機能を有したデータ配信管理装置のデータ配信管理方法において、受信したデータセグメントを保存する保存工程と、送信元のスループット情報および配信処理終了までにかかる時間をもとに、前記バッファのバッファサイズを可変設定するバッファ管理工程と、宛先の受信バッファの状態に応じたデータ転送速度調整を行う速度調整工程と、受信したデータを宛先に向けて転送した際に、送信元に対して仮の送達確認応答を作成し、返送する仮送達確認応答工程と、前記バッファのバッファサイズ不足を予測する予測工程と、送信元ＩＰと送信元ポートとの組み合わせ、および宛先ＩＰと宛先ポートとの組み合わせが全て同一の通信を一の管理単位とし、該管理単位ごとに、かつ、該送信元および該宛先のそれぞれに対して、優先度の程度を表す指標を設定する優先度設定工程と、前記予測工程が前記バッファのバッファサイズ不足を予測した場合に、前記仮の送達確認応答の返信速度を低下させる制御を行うとともに、前記仮の送達確認応答の返送を停止させる制御を行うとともに、前記送信元および前記宛先のそれぞれに設定された優先度指標に応じて前記バッファサイズを調整する配信管理工程と、を含むことを特徴とする。
【００４０】
この発明によれば、バッファ管理工程が、送信元のスループット情報をもとに、前記バッファのバッファサイズを可変設定するようにしている。また、速度調整工程が、宛先の受信バッファの状態に応じてスループットの増減幅を調整するようにしている。さらに、前記配信管理工程は、前記予測工程が前記バッファのバッファサイズ不足を予測した場合に、前記仮の送達確認応答の返信速度を低下させる制御を行うようにし、バッファ状態に応じて送信側のスループットを調整するとともに、送信元ＩＰと送信元ポートとの組み合わせ、および宛先ＩＰと宛先ポートとの組み合わせが全て同一の通信を一纏めとする管理単位ごとに、かつ、該送信元および該宛先のそれぞれに対して設定された優先度指標に応じて前記バッファサイズを調整するようにしている。
【００４１】
つぎの発明にかかるデータ配信管理方法は、少なくとも受信したデータを宛先に向けて転送するとともに、宛先からの送達確認応答を受信するまでデータセグメントを保存し、必要に応じて再送処理を行う機能を有したデータ配信管理装置のデータ配信管理方法において、受信したデータセグメントを保存する保存工程と、送信元のスループット情報および配信処理終了までにかかる時間をもとに、前記バッファのバッファサイズを可変設定するバッファ管理工程と、宛先の受信バッファの状態に応じたデータ転送速度調整を行う速度調整工程と、受信したデータを宛先に向けて転送した際に、送信元に対して仮の送達確認応答を作成し、返送する仮送達確認応答工程と、前記バッファのバッファサイズ不足を予測する予測工程と、送信元ＩＰと送信元ポートとの組み合わせ、および宛先ＩＰと宛先ポートとの組み合わせが全て同一の通信を一の管理単位とし、該管理単位ごとに、かつ、該送信元および該宛先のそれぞれに対して、優先度の程度を表す指標を設定する優先度設定工程と、前記予測工程が前記バッファのバッファサイズ不足を予測した場合に、前記仮の送達確認応答のウィンドウ情報を小さくする制御を行うとともに、前記送信元および前記宛先のそれぞれに設定された優先度指標に応じて前記バッファサイズを調整する配信管理工程と、を含むことを特徴とする。
【００４２】
この発明によれば、バッファ管理工程が、送信元のスループット情報をもとに、前記バッファのバッファサイズを可変設定するようにしている。また、速度調整工程が、宛先の受信バッファの状態に応じてスループットの増減幅を調整するようにしている。さらに、前記配信管理工程は、前記予測工程が前記バッファのバッファサイズ不足を予測した場合に、前記仮の送達確認応答のウィンドウ情報を小さくする制御を行うようにし、バッファ状態に応じて送信側のスループットを調整するとともに、送信元ＩＰと送信元ポートとの組み合わせ、および宛先ＩＰと宛先ポートとの組み合わせが全て同一の通信を一纏めとする管理単位ごとに、かつ、該送信元および該宛先のそれぞれに対して設定された優先度指標に応じて前記バッファサイズを調整するようにしている。
【００４３】
つぎの発明にかかるデータ配信管理方法は、少なくとも受信したデータを宛先に向けて転送するとともに、宛先からの送達確認応答を受信するまでデータセグメントを保存し、必要に応じて再送処理を行う機能を有したデータ配信管理装置のデータ配信管理方法において、受信したデータセグメントを保存する保存工程と、送信元のスループット情報および配信処理終了までにかかる時間をもとに、前記バッファのバッファサイズを可変設定するバッファ管理工程と、宛先の受信バッファの状態に応じたデータ転送速度調整を行う速度調整工程と、受信したデータを宛先に向けて転送した際に、送信元に対して仮の送達確認応答を作成し、返送する仮送達確認応答工程と、前記バッファのバッファサイズ不足を予測する予測工程と、送信元ＩＰと送信元ポートとの組み合わせ、および宛先ＩＰと宛先ポートとの組み合わせが全て同一の通信を一の管理単位とし、該管理単位ごとに、かつ、該送信元および該宛先のそれぞれに対して、優先度の程度を表す指標を設定する優先度設定工程と、前記予測工程が前記バッファのバッファサイズ不足を予測した場合に、新規の前記仮の送達確認応答を利用するコネクション接続要求を受けない制御を行うとともに、前記送信元および前記宛先のそれぞれに設定された優先度指標に応じて前記バッファサイズを調整する配信管理工程と、を含むことを特徴とする。
【００４４】
この発明によれば、バッファ管理工程が、送信元のスループット情報をもとに、前記バッファのバッファサイズを可変設定するようにしている。また、速度調整工程が、宛先の受信バッファの状態に応じてスループットの増減幅を調整するようにしている。さらに、前記配信管理工程は、前記予測工程が前記バッファのバッファサイズ不足を予測した場合に、新規の前記仮の送達確認応答を利用するコネクション接続要求を受けない制御を行うようにし、バッファ状態に応じて送信側のスループットを調整するとともに、送信元ＩＰと送信元ポートとの組み合わせ、および宛先ＩＰと宛先ポートとの組み合わせが全て同一の通信を一纏めとする管理単位ごとに、かつ、該送信元および該宛先のそれぞれに対して設定された優先度指標に応じて前記バッファサイズを調整するようにしている。
【００４５】
つぎの発明にかかるデータ配信管理方法は、上記の発明において、宛先毎に優先度が設定する優先度設定工程をさらに含み、前記配信管理工程は、前記優先度に応じて前記バッファサイズを調整することを特徴とする。
【００４６】
この発明によれば、前記配信管理工程は、前記優先度に応じて前記バッファサイズを調整するようにしている。
【００４７】
つぎの発明にかかるデータ配信管理方法は、上記の発明において、前記配信管理方法は、前記バッファの空き領域が、予め設定されたバッファサイズの余裕値を超えた場合に受信データ量を抑制する通信に対して、前記受信データ量が抑制されるように該通信の送信元に指示することを特徴とする。
【００４８】
この発明によれば、前記配信管理工程は、前記バッファの空き領域が、予め設定されたバッファサイズの余裕値を超えた場合に受信データ量を抑制する通信に対して、前記受信データ量が抑制されるように該通信の送信元に指示することを特徴とする。
【００４９】
つぎの発明にかかるデータ配信管理方法は、上記の発明において、選択的な速度調整を行うか否かを決定する決定工程をさらに備えたことを特徴とする。
【００５０】
この発明によれば、決定工程が、選択的な速度調整を行うか否かを決定するようにしている。
【００５１】
【発明の実施の形態】
以下、添付図面を参照して、この発明にかかるデータ配信管理装置、データ配信管理システムおよびデータ配信管理方法の好適な実施の形態を詳細に説明する。
【００５２】
実施の形態１．
図１は、この発明の実施の形態１であるデータ配信管理装置を含むデータ配信管理システムの構成を示すブロック図である。図１において、このデータ配信管理システムは、送信装置Ｃ１が回線２を介してデータ配信管理装置１０に接続され、データ配信管理装置１０が回線３を介して受信装置Ｃ２に接続される。回線３は、衛星回線などの伝送遅延の大きな回線であり、回線２は、回線３に比して伝送遅延が小さい回線である。
【００５３】
データ配信管理装置１０は、送信ゲートウェイＳＧと、配信管理テーブル１と、プロトコル管理テーブル５と、バッファの割り当てを行うバッファ割当部６ａを有した送信バッファ６と、受信バッファ７、および経路管理テーブル８を有する。送信ゲートウェイＳＧは、送信装置Ｃ１との間においてデータパケットの入出力処理を行う通信部１７と、受信装置Ｃ２との間においてデータパケットの入出力処理を行う通信部１１と、仮の送達確認応答（ｔｍｐＡＣＫ）を作成するために、受信したデータパケットを保存するｔｍｐＡＣＫバッファ４と、受信装置Ｃ２に対して送信したデータパケットに対してｔｍｐＡＣＫの返送を行うか否かを判断するｔｍｐＡＣＫ使用判定部１２、送信装置Ｃ１から受信したデータパケットをもとにｔｍｐＡＣＫを作成するｔｍｐＡＣＫ作成部１３と、データパケット毎の送達確認応答のタイムアウト時間（ＳＧＴｉｍｅｒ）をカウントアップし、この送達確認応答待ちのタイムアウトイベントを発生させるＳＧＴｉｍｅｒカウント部１４と、送信装置Ｃ１にｔｍｐＡＣＫを送信したか否かの情報および受信装置Ｃ２からの送達確認応答に関する情報を配信管理テーブル１に書き込む処理を行う配信データ記録部１５と、ＳＧＴｉｍｅｒ値および配信管理テーブル１の内容に対応してデータパケットの配信を管理するＳＧ配信管理部１６とを有する。
【００５４】
なお、図１において、送信バッファ６、受信バッファ７、およびｔｍｐＡＣＫバッファ４は、それぞれ別個のバッファとして示されているが、これに限らず、部分的あるいは全てを同一のバッファとして実装するようにしてもよい。また、別個のバッファとして実装する場合であっても、同一のバッファとして実装する場合であっても、管理目的に応じて制御情報などを含めた情報とともに用いることが可能な図示しない管理テーブルを設け、パケットデータの格納位置が識別可能なように実装することによって、管理および検索の効率化を図ることができる。
【００５５】
ここで、図２〜図８を参照して、データ配信管理装置１０のデータ配信管理処理について説明する。まず、送信ゲートウェイＳＧの通信部１７，１１は、データパケットを受信すると、この受信したデータパケットを受信バッファ７に一時保存し、ＳＧ配信管理部１６は、図２に示す配信処理を行う。
【００５６】
図２において、まず、ｔｍｐＡＣＫ使用判定部１２が、受信したデータパケットのチェックを行い、このチェック結果に応じて送信ゲートウェイＳＧがもつ受信データパケットに対するｔｍｐＡＣＫ利用可能フラグの「ＯＮ」、「ＯＦＦ」を決定し、必要に応じてｔｍｐＡＣＫ利用可能フラグの「ＯＮ」、「ＯＦＦ」も含め、受信データパケットの情報を配信管理テーブル１に登録する（ステップＳ１１）。
【００５７】
その後、ｔｍｐＡＣＫ制御フラグをもとにｔｍｐＡＣＫの利用制御を行うか否かを判断する（ステップＳ１２）。ｔｍｐＡＣＫの利用制御を行わない場合（ステップＳ１２，ＮＯ）には、そのまま本処理を終了し、ｔｍｐＡＣＫの利用制御を行う場合（ステップＳ１２，ＹＥＳ）には、ｔｍｐＡＣＫ利用制御処理を実行して（ステップＳ１３）、本処理を終了する。
【００５８】
図３は、図２に示したステップＳ１１におけるパケットのチェック処理手順を示すフローチャートである。図３において、まず、遅延依存の回線への転送か否か、すなわち、遅延の大きな回線に対する転送か否かを判断する（ステップＳ２１）。この判断は、この実施の形態１において、ネットワーク層のヘッダがＩＰヘッダであるか否か、およびＩＰヘッダであった場合、正しいＩＰアドレスとなっているかどうかを確認した後、ルーティング機能によって決定される経路が、宛先への経路上に伝送遅延回線があるか否かを、経路管理テーブル８を用いて判定する。
【００５９】
ここで、プロトコルがＩＰを用いていない場合、正しいフォーマットのアドレスではない場合、および宛先への経路が伝送遅延回線を含まない場合など（ステップＳ２１，ＮＯ）には、ｔｍｐＡＣＫ利用制御フラグを「ＯＦＦ」にし（ステップＳ２２）、受信セグメントを宛先に転送し（ステップＳ２３）、本処理を終了する。なお、このｔｍｐＡＣＫ利用可能フラグは、上述した別個のバッファあるいは同一のバッファに設けられる図示しない管理テーブルを用いる場合、この管理テーブル内の情報として保持するようにしてもよい。
【００６０】
図４は、経路管理テーブル８の内容の一例を示す図である。図４において、この経路管理テーブル８は、大きく「送信元−ルータ経路」と「ルータ−宛先経路」とに項目区分される。「送信元−ルータ経路」は、さらに「送信元ＩＰ」、「最大Ｗｉｎｄｏｗサイズ」、「送信元優先度」、および送信元−ルータ間の「スループット」に項目区分される。一方、「ルータ−宛先経路」は、ルータ、すなわち送信ゲートウェイＳＧと宛先との間の経路に関する情報群であり、たとえば、どの回線につながっているかを示す、判定対象の経路「ポート」、この「ポート」への経路の「遅延」時間、「スループット」、「宛先ＩＰ」、送信ゲートウェイＳＧで扱う通信全てのパケットを転送することができなくなった状況で発生した場合などにおいて、パケット転送の優先度の一つの判定基準となる「宛先優先度」、この宛先の「最大Ｗｉｎｄｏｗサイズ」にさらに項目区分される。
【００６１】
ここで、送信元とルータとの間の「スループット」の値には、仮ＡＣＫ機能を利用した場合と利用しない場合とによってスループットが異なる場合があるため、回線のデフォルト値およびそれ以前までの通信で使用した際の実測値による値を入れる。なお、デフォルト値は、回線の種類に応じてユーザ設定が可能であり、入力されない場合や経路によって回線が特定できない場合には例えば１Ｍｂｐｓに設定する。一方、ルータと宛先との間の「スループット」は、遅延に左右されるため、回線のデフォルトのスループットを入れる。また、「遅延」時間には、回線の持つデフォルト値、あるいはそれ以前までの通信で使用した際の実測値による値を入れる。「宛先ＩＰ」の項目は、判定対照の通信の宛先ＩＰを表したものである。したがって、ＩＰヘッダの宛先アドレス部にある宛先への経路が遅延依存の経路ではないとされた場合（ステップＳ２１，ＮＯ）、ｔｍｐＡＣＫ利用可能フラグを「ＯＦＦ」にし（ステップＳ２２）、受信セグメントを宛先に転送し（ステップＳ２３）、本処理を終了する。
【００６２】
一方、正しいＩＰアドレスであり、かつ伝送遅延を含んだ経路制御を行う通信であると判定された場合（ステップＳ２１，ＹＥＳ）には、受信したセグメントのＩＰヘッダのプロトコルのバイト列を参照し、遅延依存であるか否か、たとえば、ＴＣＰか、それ以外のプロトコルであるか否かの判定を行う（ステップＳ２４）。この判定には、図５に示すプロトコル管理テーブル５が参照される。
【００６３】
ステップＳ２４において、遅延依存のプロトコルであると判定された場合、受信したセグメントのヘッダ部のコードビット（CodeBit）を参照し、通信開始時のセグメントか否かを判定し（ステップＳ２５）、通信開始セグメントであった場合（ステップＳ２５，ＹＥＳ）、ステップＳ２８に移行する。一方、通信開始セグメントではないと判定された場合（ステップＳ２５，ＮＯ）、ステップＳ２６に移行する。
【００６４】
ステップＳ２６において、受信したセグメントが、図１に示した配信管理テーブル１に、既に登録済の通信であるか否かの判定を行う。この判定では、ＩＰヘッダ中の送信元ＩＰとＴＣＰヘッダ中の送信元ポートの組み合わせ、および宛先ＩＰと宛先ポートとの組み合わせが全て同一の通信を同一の管理単位とし、登録済の通信であると判定する。
【００６５】
ここで、図６および図７は、配信管理テーブルの一例を示す図であり、図７は、図６に示した左端の１つの受付番号（通信ＩＤ）にリンクする詳細な情報である。図６において、複数にわたる行Ｄ２５，Ｄ２６は、項目Ｄ１１〜Ｄ２４を持つ、上述した管理単位を同じくする通信に関する情報を表す。また、図７において、項目Ｄ３１〜Ｄ３３は、上述した管理単位を同じくする通信においてデータ配信管理装置１０が受信したセグメントに関する情報を表すものであり、行Ｄ２５における通信に関するデータの例である。これらの各項目は、データ配信管理装置１０が受信したセグメントから情報を取得するものである。
【００６６】
図６において、項目Ｄ１１は、この通信を一意に識別するための受付番号（通信ＩＤ）である。項目Ｄ１２は、この通信に割り当てられたｔｍｐＡＣＫ作成対象セグメントを保存するための割当バッファ量を表すものである。項目Ｄ１３は、この通信が実際にｔｍｐＡＣＫ作成対象セグメントの保存のために使用している使用バッファ量を示している。項目Ｄ１４は、管理する通信の送信元ＩＰアドレスを表すものである。項目Ｄ１５は、送信元優先度を表し、この優先度は例えば、「１」、「２」、「３」、・・・のような整数値で表され、数値の高いほど優先度が高い送信元であるという実装が可能である。項目Ｄ１６は、宛先ＩＰアドレスを表す。項目Ｄ１７は、宛先優先度を表す。この優先度は例えば、「１」、「２」、「３」、・・・のような整数値で表され、数値の高いほど優先度が高い送信元であるという実装が可能である。項目Ｄ１８は、送信元スループットであり、ここには通信開始時にはデフォルト値として、経路管理テーブル８を参照し、当該通信における送信元のデフォルトのスループットを入れ、以後、一定間隔ごとにスループットの実測値を計り更新する。通信終了時に、経路管理テーブル８のデフォルトのスループットの値も、実測値を元に再計算し更新することも可能である。項目Ｄ１９は、通信の優先度フラグであり、これは例えばＴＣＰセグメントの緊急フラグが「ＯＮ」であれば、「ＯＮ」とするという実装が可能である。項目Ｄ２０は、仮ＡＣＫ送信待ちによる速度調節に関する情報であり、仮ＡＣＫ送信待ちによる速度調節機能を用いるか否かに関するフラグ、および当該フラグが「ＯＮ」の場合はその調節のための待ち時間を示す値を入れる項目であり、項目Ｄ２１は、Ｗｉｎｄｏｗサイズ情報による速度調節機能に関する情報を入れる項目であり、この機能を用いるか否かに関するフラグおよびこのフラグが「ＯＮ」の場合はどのくらいＷｉｎｄｏｗサイズを調節するかを示す値を入れる項目である。項目Ｄ２２は、データ配信管理装置１０と宛先との間の往復時間（Round Trip Time：ＲＴＴ）を表す値であり、デフォルト値は経路管理テーブル８の「遅延」情報に書いてある値の２倍の数値を入れ、通信において値を適宜とり、交信してゆくなどの実装が可能である。項目Ｄ２３は、送信元ポート番号を表し、項目Ｄ２４は、宛先ポート番号を表す。項目Ｄ２７は、送信元および宛先におけるそれぞれの最新の送信ウィンドウサイズおよび受信ウィンドウサイズを表す。項目Ｄ２８は、現在管理している通信に割り当てられている仮ＡＣＫを利用したセグメント保存用のバッファの総量を示し（Byte単位）、項目Ｄ２９は、割り当て可能な仮ＡＣＫを利用したセグメント保存用のバッファ残量を示し、この例では、仮ＡＣＫを利用したセグメント保存用のバッファの総量を「５Ｇ」としているため、残量は（５−２．８）＝２．２Ｇとなる。項目Ｄ３０は、現在使用中の仮ＡＣＫを利用したセグメント保存用のバッファの総量を表す。
【００６７】
更に、図７において、項目Ｄ３１は、個々の通信においてデータ配信管理装置１０が受信したセグメントのシーケンス番号を表し、項目Ｄ３２は、ｔｍｐＡＣＫ送信に関する情報を表し、これは送信元に対して一定の条件が整った時などの条件付の場合を含め送信可能なセグメントか否かの情報およびｔｍｐＡＣＫを送信したか否かの情報などを値として用いるものである。項目Ｄ３３は、宛先からの送達確認応答（ＲＲＡＣＫ）に対する情報を表すものであり、この例では対応するセグメントがＲＲＡＣＫを受信済であることを表すＡＣＫ受信済およびＲＲＡＣＫの到達を待っている状態である事を表すＡＣＫ待ちの２つの値を持つものである。
【００６８】
図７は、図６の項目Ｄ２７の右列に加え、一つのテーブルとする事も可能であるが、スペースの都合上、項目Ｄ１１によって関連付けられる二つの表とした。従って、例えば項目Ｄ２５で示される一群の行は、通信ＩＤとして「１」を持ち、仮ＡＣＫを用いたセグメントを保存するために８００Ｍbyteまでの大きさのバッファを割り当てられ、当該バッファのうち現時点で７５０ＭByteのバッファを使用しており、優先度が「１」の送信元マシン「10.74.3.135」の送信ポート 「FTP.DATA」から０．６５Ｍbpsのスループットで、優先度が「１」の宛先マシン「10.74.3.200」の宛先ポート「1301」に対する通信において、通信の優先度フラグが「ＯＮ」であり、仮ＡＣＫ送信待ちによる速度調節利用フラグが「ＯＮ」であり、Ｗｉｎｄｏｗサイズ情報による速度調節利用フラグが「ＯＮ」であり、データ配信管理装置と宛先との間のＲＴＴが５４３msecである通信において、送信元の送信ウィンドウサイズおよび受信ウィンドウサイズ、および宛先の送信ウィンドウサイズおよび受信ウィンドウサイズは全て１６Kバイトであり、シーケンス番号「398」を持つセグメントは、ｔｍｐＡＣＫの送信は不可、即ちいかなる条件になった場合もｔｍｐＡＣＫの送信を行わないセグメントであり、現時点で宛先からの送達確認応答を待っている状態であることを表すものである。これらの項目および必要に応じて追加する項目を用いて、セグメントのｔｍｐＡＣＫの管理、受信確認および結果に応じた再送の制御、送信元へのｔｍｐＡＣＫおよびＲＲＡＣＫ（宛先からの送達確認応答）の送信速度の制御、宛先への転送速度の制御、データ配信管理装置１０の送受信バッファの管理を行う事ができる。
【００６９】
このような配信管理テーブル１を用いて、データ配信管理装置１０は、受信したセグメントのＩＰヘッダにある送信元ＩＰアドレスおよび宛先ＩＰアドレス、およびＴＣＰヘッダにある送信元ポート番号および宛先ポート番号を参照し、ＩＰヘッダ中の送信元ＩＰとＴＣＰヘッダ中の送信元ポートの組み合わせ、および宛先ＩＰと宛先ポートの組み合わせで表される通信が配信管理テーブル１上にあるか否かの判定を行う。判定の結果、配信管理テーブル１上に登録されている通信であったと判定された場合（ステップＳ２６，ＹＥＳ）、ステップＳ３２に移行し、受信したセグメントが、宛先の受信Ｗｉｎｄｏｗ内のセグメントであるか否かを判定し（ステップＳ３２）、宛先の受信Ｗｉｎｄｏｗ内のセグメントであった場合（ステップＳ３２，ＹＥＳ）、ステップＳ３３に移行し、ＦＩＮフラグをチェックし、最終パケット（通信終了パケット）であるか否かを判定し、通信終了ではなかった場合はステップＳ３４に移行する。
【００７０】
ステップＳ２６において、配信管理テーブル１上に登録されている通信ではないと判定された場合、ｔｍｐＡＣＫ利用制御フラグを「ＯＦＦ」にし（ステップＳ２２）、受信セグメントを宛先に転送し（ステップＳ２３）、本処理を終了する。
【００７１】
ステップＳ３３において、通信終了セグメントであった場合、受信したセグメントのエントリを登録し、同一通信内のセグメントのエントリでｔｍｐＡＣＫ利用可能となっており、かつ、ｔｍｐＡＣＫ送信済でないものを全てｔｍｐＡＣＫ利用不可とし、データ配信管理装置１０のｔｍｐＡＣＫ利用可能フラグを「ＯＦＦ」にし、ＦＩＮ受信済フラグを「ＯＮ」にし（ステップＳ３５）、受信セグメントを宛先に転送し（ステップＳ２３）、本処理を終了する。
【００７２】
ステップＳ３４において、送信元の送信Ｗｉｎｄｏｗサイズを確認し、スロースタートであるか否かを判定し、スロースタートであった場合（ステップＳ３４，ＹＥＳ）、ｔｍｐＡＣＫ利用可能フラグを「ＯＦＦ」にした（ステップＳ３６）後、受信セグメントを宛先に転送し（ステップＳ２３）、本処理を終了する。
【００７３】
一方、ステップＳ３４において、スロースタートと判定された場合、受信したセグメントが宛先からの送達確認応答か否かを判定し（ステップＳ３７）、宛先からの送達確認応答であった場合（ステップＳ３７，ＹＥＳ）、ｔｍｐＡＣＫバッファ４に、受信したセグメントを保存し、データ配信管理装置１０のＳＧ配信管理部１６の配信確認処理（図１０）に、受信装置Ｃ２から送達確認応答を受信したことを通知するイベントを発生させ、ｔｍｐＡＣＫ利用可能フラグを「ＯＮ」にセットし（ステップＳ３８）、本処理を終了する。
【００７４】
ステップＳ３７において、受信したセグメントが、宛先からの送達確認応答ではないと判定された場合、バッファの空き具合に応じて仮ＡＣＫを作成送信する処理を行うか否かを定め、さらにその仮ＡＣＫ作成に伴う処理を行う（ステップＳ３９）。この処理の詳細については、図８および図９を参照して後述する。その後、受信セグメントを宛先に転送し（ステップＳ２３）、本処理を終了する。
【００７５】
一方、ステップＳ２５において、通信開始セグメントであると判定された場合、判定を行っているセグメントを含めて、通信開始セグメントが通信の手順とおりに正しく送受信されているか否かの判定を行う（ステップＳ２８）。一連の作業により、通信開始セグメントは正しい順序で、到達された事を確認されたもののみ、ステップＳ２９においてバッファのチェック処理を行う。
【００７６】
ステップＳ２９のバッファチェックは、通信開始セグメントの送信元および宛先情報を取り出し、経路管理テーブル８および配信管理テーブル１の情報を用いて、送信元からのスループット、ルータ−宛先間の遅延情報によって、必要なバッファの容量、およびバッファの空き具合のチェックを行い、バッファが十分か否かの判定を行う。この十分か否かの判定は、（バッファ総量）−（現在使っているバッファ量）−（新規の通信に必要と予測されたバッファ量）＝（残っているバッファ量）−（新規の通信に必要と予測されたバッファ量）＞（データ配信管理装置１０が予め持っている余裕度を示すバッファ量）、との条件を満たすか否かで行う。
【００７７】
さらに、この時、バッファの空き容量が十分ではないと判定された場合、送信元、宛先、およびパケットの緊急フラグを見て、優先するべき通信か否かを判定し、優先するべき通信であると判定した場合は、たとえ、十分なバッファ容量がない場合も、割当可能フラグを立て、代わりに、緊急度に応じて他の優先度を下げるべき通信のバッファ容量の調節フラグを「ＯＮ」に割り当てるバッファ容量の再計算を行い配信管理テーブル１に記載する、ｔｍｐＡＣＫ利用可能フラグを「ＯＦＦ」にする、仮ＡＣＫ送信待ちによる速度調節フラグを「ＯＮ」にし、仮ＡＣＫ送信待ち時間を計算し、配信管理テーブル１に記載する、Ｗｉｎｄｏｗ情報による速度調節フラグを「ＯＮ」にし、速度調節のためのＷｉｎｄｏｗ情報を計算し、配信管理テーブル１に記載する、などの対策を行う。これらのフラグを立てる組み合わせは、通信毎の通信の優先度の開きとバッファの空き容量とからなる管理テーブルを用いるなどの実装が可能である。速度調節用仮ACK送信待ち時間とは、速度調節のために一定時間待ってから仮ＡＣＫを作成および送信することで、データ配信管理装置１０の処理およびデータ配信管理装置１０と送信装置Ｃ１との間のフローの削減を促すことを目的とする。例えば、仮ＡＣＫ送信待ちによる速度調節利用フラグが「ＯＮ」であった場合、各々の通信毎のタイマをデータ配信管理装置１０が持ち、指定された時間毎にフラグを「ＯＮ」にし、仮ＡＣＫを送信した時点でフラグを「ＯＦＦ」にし、再びカウントを開始するという実装が考えられる。このバッファ割当可能フラグは、バッファ割当部６ａが持ち、この一連のステップＳ２９の処理は、バッファ割当部６ａが行うものである。
【００７８】
ステップＳ２９の処理の後、バッファ割当フラグを見て、バッファ割当が可能か否かの判定を行い（ステップＳ３０）、可能でない場合はステップＳ２２に移行する。一方、ステップＳ３０において、バッファ割当可能との判断をされた場合、送信管理テーブル１にエントリを追加する（ステップＳ３１）。このステップＳ３１の処理後、受信したセグメントが宛先からの送達確認応答か否かを判定し（ステップＳ４０）、宛先からの送達確認応答であると判定された場合は、ステップＳ３８の処理を行った後、本処理を終了する。一方、宛先からの送達確認応答ではないと判定された場合（ステップＳ４０，ＮＯ）には、ｔｍｐＡＣＫ利用可能フラグを「ＯＦＦ」にし（ステップＳ４１）、受信セグメントを宛先に転送した（ステップＳ２３）後、本処理を終了する。
【００７９】
一方、ステップＳ２８において、データ配信管理装置１０が正しい順序で通信開始セグメントを受信していないと判定された場合、データ配信管理装置１０のｔｍｐＡＣＫ利用可能フラグを「ＯＦＦ」にし（ステップＳ２２）、受信セグメントを宛先に転送する（ステップＳ２３）。この時、宛先の送信管理テーブル１および経路管理テーブル８を参照し、送信管理テーブル１に載っている通信のパケットに対しては、宛先の受信装置Ｃ２の受信Ｗｉｎｄｏｗサイズおよびデータ配信管理装置１０と宛先との間のスループットに応じて、転送速度の調節を行う。ステップＳ２３の処理後、一連の処理を終了する。
【００８０】
つぎに、図８に示すフローチャートを参照して、ステップＳ３９に対応するｔｍｐＡＣＫ作成送信待ちによる速度調節処理について説明する。まず、ステップＳ３９の処理は、バッファの空き具合に応じて仮ＡＣＫを作成送信する処理を行うか否かを定め、さらにその仮ＡＣＫ作成に伴う処理を表す。これらの処理は、送信元である送信装置Ｃ１から受信し、データ配信管理装置１０において、受信装置Ｃ２に転送するとともに、ｔｍｐＡＣＫ作成および送信を行い、このｔｍｐＡＣＫ作成および送信処理(ｔｍｐＡＣＫ処理)対象となったデータセグメントを一時的に保持すると同時に、該データセグメントを一時的に保持するためのバッファの容量に関する調節を行うものである。
【００８１】
ここで、図１０は、このバッファの容量の調節の仕組みを示す模式図である。図１０において、各バッファＢ１〜Ｂ３は、上述したｔｍｐＡＣＫ処理を行ったデータセグメントを一時的に保存するためのバッファ全体を示している。バッファＢ１，Ｂ２は、データ配信管理装置１０が現在管理している通信のうち、ｔｍｐＡＣＫ処理を含む通信（通信「１」，「２」）に割り当てられたバッファであり、バッファＢ３は、通信「１」，「２」および今後新たに管理する通信のための予備的なバッファである。
【００８２】
通信「１」用のバッファＢ１が足りなくなった、あるいは足りなくなりつつあるとの判定が出された場合、予備的なバッファＢ３から、必要量Ｂ３ａを算出し、その分を、通信「１」に追加し、バッファＢ１に割り当てている。
【００８３】
さて、図８において、最初に、バッファのチェックを行う（ステップＳ５１）。このバッファチェック処理では、開始通知以外のデータセグメントを受信した場合に行うものであり（開始通知の場合は、ステップＳ２９によって処理される）、このセグメントの送信元および宛先情報を取り出し、経路管理テーブル８および配信管理テーブル１の情報を用いて、送信元からのスループット、ルータ−宛先間の遅延情報によって、必要なバッファの容量、およびバッファの空き具合のチェックを行い、バッファが十分か否かの判定を行う。この十分かどうかの判定は、（バッファ総量）−（現在使っているバッファ量）＝（残っているバッファ量）＞（データ配信管理装置１０が予め持っている余裕度を示すバッファ量）、との条件を満たすか否かで行う。さらに、この時、バッファの空き容量が十分ではないと判定された場合、送信元、宛先、およびパケットの緊急フラグを見て、優先するべき通信か否かを判定し、優先するべき通信であると判定した場合は、たとえ、十分なバッファ容量がない場合も、バッファ容量の調節フラグをオフにし、代わりに、緊急度に応じて他の優先度を下げるべき通信のバッファ容量の調節フラグを「ＯＮ」に割り当てるバッファ容量の再計算を行い、配信管理テーブル１に記載する、ｔｍｐＡＣＫ利用可能フラグを「ＯＦＦ」にする、仮ＡＣＫ送信待ちによる速度調節フラグを「ＯＮ」にし、仮ＡＣＫ送信待ち時間を計算し、配信管理テーブル１に記載する、Ｗｉｎｄｏｗ情報による速度調節フラグを「ＯＮ」にし、速度調節のためのＷｉｎｄｏｗ情報を計算し、配信管理テーブル１に記載する、などの対策を行う。これらのフラグを立てる組み合わせは、通信毎の通信の優先度の開きとバッファの空き容量とからなる管理テーブルを用いるなどの実装が可能である。また、逆に、十分なバッファ量があるとの判定がされた場合、速度調節用のフラグおよびバッファ容量の調節フラグの少なくとも一つが「ＯＮ」になっている通信があった場合（複数の場合は通信の優先度も考慮し）、その通信に対し提供可能なバッファ容量を再計算し、割り当て可能なバッファ容量の値を更新する、あるいはバッファ容量調節フラグを「ＯＦＦ」にする、ｔｍｐＡＣＫ利用可能フラグを「ＯＮ」にし、配信管理テーブル１に記載する、仮ＡＣＫ送信待ちによる速度調節フラグが「ＯＮ」の場合は、速度調節のための待ち時間を再計算し、待ち時間を短縮する、あるいは仮ＡＣＫ送信待ちによる速度調節フラグを「ＯＦＦ」にし、配信管理テーブル１に記載する、Ｗｉｎｄｏｗ情報による速度調節フラグが「ＯＮ」の場合は、速度調節のためのＷｉｎｄｏｗ情報値を再計算し、Ｗｉｎｄｏｗ情報を増加させる、あるいはＷｉｎｄｏｗ情報による速度調節フラグを「ＯＦＦ」にし、配信管理テーブル１に記載する、などの対策を行う。
【００８４】
その後、バッファ容量の調節フラグを見て、「ＯＮ」の場合（ステップＳ５２，ＹＥＳ）、ステップＳ５３に移行し、「ＯＦＦ」の場合（ステップＳ５２，ＮＯ）、配信管理テーブル１に情報を登録し、ｔｍｐＡＣＫ利用可能フラグを「ＯＮ」に設定する（ステップＳ５４）。この際、最新のセグメント到着時点における情報として、配信管理テーブル１の個々のセグメントに関する情報のエントリ毎にｔｍｐＡＣＫ利用可能かどうかの情報を設定する。なお、ｔｍｐＡＣＫ利用可能フラグを「ＯＮ」にしたセグメントは、バッファに保存する。
【００８５】
一方、バッファ容量の調節フラグを見て、「ＯＮ」の場合、仮ＡＣＫフラグが「ＯＮ」か否か（ステップＳ５１によって決定される、ｔｍｐＡＣＫ利用可能フラグが「ＯＮ」か否か）を判定し（ステップＳ５３）、「ＯＦＦ」であった場合、配信管理テーブル１にパケットに関する情報、すなわちパケット番号、ｔｍｐＡＣＫ送信を「不可」、ＲＲＡＣＫ状態に「ACK待ち」を追加し、ｔｍｐＡＣＫ利用可能フラグを「ＯＦＦ」にし（ステップＳ５５）、本処理を終了する。
【００８６】
一方、ステップＳ５３において、仮ＡＣＫフラグが「ＯＮ」であると判定された場合、仮ＡＣＫの作成および送信に関する処理を行い（ステップＳ５６）、本処理を終了する。ステップＳ５６の処理の詳細については、図９に示すフローチャートを参照して後述する。
【００８７】
図９は、ステップＳ５６に対応し、仮ＡＣＫ作成送信処理の手順を示すフローチャートである。図９において、まず、図３に示した一連の処理によって設定したＦＩＮ受信済フラグの値を参照し、通信終了セグメントが受信済か否かの判定を行う（ステップＳ６１）。ＦＩＮ受信済と判定された場合（ステップＳ６１，ＹＥＳ）、なにも行わず本処理を終了してリターンする。
【００８８】
一方、ＦＩＮ受信済と判定されなかった場合（ステップＳ６１，ＮＯ）、ｔｍｐＡＣＫバッファに保存してあるセグメントがＳＹＮ＋ＡＣＫセグメントか否かを判定する（ステップＳ６２）。ＳＹＮ＋ＡＣＫセグメントであった場合（ステップＳ６２，ＹＥＳ）、ＳＹＮ＋ＡＣＫセグメントが宛先に未転送だった場合に、この未転送のデータを転送し（ステップＳ６３）、さらに転送済みのデータを破棄し（ステップＳ６４）、本処理を終了してリターンする。
【００８９】
一方、ステップＳ６２において、ｔｍｐＡＣＫバッファに保存してあるセグメントがＳＹＮ＋ＡＣＫセグメントではないと判定された場合、仮ＡＣＫの作成対象となるセグメントを決定する（ステップＳ６５）。この時。例えばＳＡＣＫなしのＴＣＰ通信であった場合、「自分以外に自分より、シーケンス番号が大きくかつＦＩＮでないセグメントが少なくとも１つある」ことを確認し得るセグメントのうちシーケンス番号が最大のものを、仮ＡＣＫ作成対象とするという実装が考えられる。
【００９０】
その後、Ｗｉｎｄｏｗ情報による速度制御を利用するか否かを判定する（ステップＳ６６）。ステップＳ６６では、配信管理テーブル１のＷｉｎｄｏｗサイズ情報による速度調節情報をみて、速度調節のフラグが「ＯＮ」であった場合（ステップＳ６６，ＹＥＳ）、仮ＡＣＫ作成用のデータパケット（図１に示したｔｍｐＡＣＫバッファ４に入っている仮ＡＣＫ作成時に用いる仮ＡＣＫ雛型で、ステップＳ３８において保存してあるもの）に入っているＡＣＫセグメントのＷｉｎｄｏｗサイズに対し、新しく算出された値を代入する。例えば、配信管理テーブル１を用い、通信ＩＤが「１」の通信に対し、この操作を行う場合、Min(現在の送信元のＷｉｎｄｏｗサイズ，現在の宛先のＷｉｎｄｏｗサイズ)*０．７＝１６Ｋ*０．７=１１．２を新しいＷｉｎｄｏｗサイズとする。そして、仮ＡＣＫ作成用データパケットのＷｉｎｄｏｗ情報の変更処理を行って（ステップＳ６７）、仮ＡＣＫ送信待ちによる速度調節を利用するか否かの判定を行う（ステップＳ６８）。
【００９１】
ステップＳ６８では、配信管理テーブル１にあるフラグをもとに仮ＡＣＫ送信待ちによる速度調節を利用するか否かを判定する。仮ＡＣＫ送信待ちによる速度調節を利用する場合（ステップＳ６８，ＹＥＳ）には、速度調節用の仮ＡＣＫ送信待ち時間を経過したか否かを判定する（ステップＳ６９）。この判定は、データ配信管理装置１０が、通信毎に仮ＡＣＫ送信待ち用のタイマと、タイマが切れた事を示すフラグを持っている場合、そのフラグを見て判定を行う。
【００９２】
速度調節用仮ＡＣＫ送信待ち時間が経過していた場合（ステップＳ６９，ＹＥＳ）、速度調節用仮ＡＣＫ送信待ちタイマおよび関連フラグをリセットし（ステップＳ７１）、ステップＳ７２に移行する。一方、速度調節用仮ＡＣＫ送信待ち時間が経過していなかった（ステップＳ６９，ＮＯ）場合、速度調節用タイマが切れるまで待った（ステップＳ７０）後、ステップＳ７１に移行する。
【００９３】
その後、ｔｍｐＡＣＫ作成バッファに保存してあるセグメントの確認応答番号を、ステップＳ６５によって決定したｔｍｐＡＣＫ作成対象セグメントのシーケンス番号に「１」を加えた番号に書き換えたセグメントを、ｔｍｐＡＣＫとして作成する。ＳＡＣＫオプション付のＴＣＰの場合は、ステップＳ６５においてＳＡＣＫオプションを考慮したｔｍｐＡＣＫ作成対象を決定し、ステップＳ７２において、ＳＡＣＫオプションも加えた送達確認応答を作成する実装を行うことも可能である。
【００９４】
その後、ｔｍｐＡＣＫを送信し（ステップＳ７３）、送信したｔｍｐＡＣＫが対応する全ての配信管理テーブル１上にエントリしてあるセグメントの情報をｔｍｐＡＣＫ送信済にし（ステップＳ７４）、本処理を終了してリターンする。
【００９５】
つぎに、図１１に示したフローチャートを参照して、ＳＧ配信管理部１６による受信確認および再送制御の処理について説明する。図１１において、まず、受信装置Ｃ２からの送達確認応答到着を示す、イベントを受け取ったか否かを判定する（ステップＳ８１）。これは、図３のステップＳ３８に示したセグメントのチェックの処理によって発生されるイベントである。
【００９６】
受信装置Ｃ２から送達確認応答が到着していた場合（ステップＳ８１，ＹＥＳ）、さらに受信装置Ｃ２からの開始通知か否かを判定し（ステップＳ８２）、開始通知であった場合（ステップＳ８２，ＹＥＳ）、本処理を終了する。一方、受信装置Ｃ２からの開始通知ではないと判定された場合（ステップＳ８２，ＮＯ）、配信管理テーブル１に、受信した送達確認応答が示すセグメントに対する結果を記入する（ステップＳ８３）。例えば、ＳＡＣＫオプションなしの通信の場合、配信管理テーブル１のエントリのうち、ＡＣＫ受信待ちであり、かつ、受信した送達確認応答が示すセグメントより、シーケンス番号が小さいセグメントを、全てをＡＣＫ受信済にする。一方、ＳＡＣＫオプションありの通信の場合、配信管理テーブル１のエントリのうち、ＡＣＫ受信待ちであり、かつ、受信した送達確認応答が示すセグメントより、シーケンス番号が小さいセグメントで、かつＳＡＣＫオプションにないセグメントを全て受信済とする。さらに、この時、ＡＣＫ待ち状態で、かつｔｍｐＡＣＫを送信していなかったセグメントに対するＡＣＫであった場合、そのまま、受信したＡＣＫを宛先（ＡＣＫが対象とするセグメントの送信元）に対し、転送する。
【００９７】
その後、配信管理テーブル１のエントリのうちＡＣＫ受信済のセグメント全てを、送信バッファから削除する（ステップＳ８４）。なお、削除に関するタイマを持ち、一定時間ごとにまとめて、削除する方法による実装も可能である。
【００９８】
一方、ステップＳ８１において、受信装置Ｃ２からの送達確認応答受信のイベントを受けていないと判定された場合、再送タイムアウトが発生したか否かを判定する（ステップＳ８５）。再送タイムアウトが発生していないと判定された場合（ステップＳ８５，ＮＯ）、本処理を終了する。
【００９９】
一方、再送タイムアウトが発生していた場合（ステップＳ８５，ＹＥＳ）、配信管理テーブル１にあるタイムアウトが発生したセグメントのエントリの再送回数をインクリメントし、再送フラグを「ＯＮ」にし（ステップＳ８６）、さらに配信終了か否かの判定を行う（ステップＳ８７）。通常のＴＣＰ通信における配信終了セグメントの交換を検知した場合、および再送のタイムアウトを繰り返し、データ配信管理装置が再送のリトライアウトをすることにより、配信を終了する場合に配信終了と判定され、配信終了処理を行い（ステップＳ８８）、本処理を終了する。なお、再送のタイムアウト値、およびリトライアウトの回数は、送信装置Ｃ１および受信装置Ｃ２の、再送のタイムアウト値およびリトライアウト回数より、十分に長く設定される必要がある。
【０１００】
配信終了処理では、配信終了状態によって異なる処理を行う。通常のＴＣＰ通信における配信終了セグメントの交換を検知した場合、ｔｍｐＡＣＫ用バッファ、送信バッファ、受信バッファの全てにおいて、終了する通信におけるセグメントを全て、削除し、配信管理テーブル１のエントリも削除する。なお、配信管理テーブル１のエントリは、データの蓄積を兼ね、保存しておくことも可能である。また、エントリに寿命を設ける、あるいはエントリがあふれない限り残しておくという実装も可能である。
【０１０１】
一方、配信終了ではないと判定された場合（ステップＳ８７，ＮＯ）、ステップＳ８９〜Ｓ９１において再送を行う。まず、配信管理テーブル１の再送フラグが「ＯＮ」になっているものを、送信バッファのセグメントを再送し、配信管理テーブル１の再送フラグを「ＯＦＦ」にする。その後、再送タイマをリセットし（ステップＳ９０）、データ配信管理装置１０の再送回数カウンタのインクリメントを行い（ステップＳ９１）、処理を終了する。
【０１０２】
ここで、図１２および図１３を参照して、データ配信管理装置１０におけるバッファ管理の実現について説明する。図１２に示すように、送信装置Ｃ１はＴＣＰアルゴリズムで動作し、送信装置Ｃ１は、このＴＣＰアルゴリズム内の輻輳制御アルゴリズムＡ１で輻輳制御を行う。この実施の形態１におけるデータ配信管理装置１０は、この輻輳制御アルゴリズムＡ１と同等な輻輳制御機能を有するＴＣＰ輻輳制御アルゴリズムＡ２を有し、これによって、上述したバッファ管理を実現している。
【０１０３】
ＴＣＰの輻輳制御アルゴリズムは、輻輳ウィンドウ（ＣＷＮＤ）のサイズを変えることによって、転送速度の制御を行い、スロースタートと輻輳回避との２つの輻輳制御を行っている。スロースタートは、ＡＣＫを受け取る度に１つずつウィンドウサイズを指数的に増加させ、輻輳回避は、ＡＣＫを受け取る度に１つずつウィンドウサイズを線形に増加させる。そして、データの喪失が生じれば、輻輳ウィンドウサイズを減らし、データの喪失が生じない場合、輻輳ウィンドウサイズを増やすようにしている。たとえば、スロースタートの輻輳制御を行う場合、送信装置Ｃ１では、ＴＣＰの輻輳制御アルゴリズムを用いた送信量ＣＷＮＤを決定しておき、次の送信量ＣＷＮＤnewは、
ＣＷＮＤnew＝ＣＷＮＤold＋（新規受信ＡＣＫ数）＊ＭＴＵ
で算出される（ステップＳ１０１）。なお、ＭＴＵは、最大転送単位（Maximum Transmission Unit）である。
【０１０４】
一方、データ配信管理装置１０側では、ＴＣＰ輻輳制御アルゴリズムＡ２を用い、送信元からのデータ量、すなわちＣＷＮＤの増加量を予測する（ステップＳ１１１）。すなわち、データ配信管理装置１０側では、ＣＷＮＤの推移予測および接続回線の速度から、単位時間当たりにどのくらいのデータが送付され、転送先の遅延状況から、どれくらいのバッファ量を必要とするかを予測する。その後、送信装置Ｃ１側からデータ送信されると、この予測に基づいて、バッファ管理を行うことによって、ＡＣＫの返送速度の増減やＡＣＫ送信の停止を行い、これによって結果的に、送信装置Ｃ１のＣＷＮＤの増加速度の増減を制御する。また、データ配信管理装置１０は、この予測に基づいて、バッファ管理を行うことによって、ＡＣＫのＷｉｎｄｏｗ情報の拡大あるいは縮小を行い、これによって結果的に、送信装置Ｃ１の送信Ｗｉｎｄｏｗの拡大あるいは縮小する制御を行う。このように、データ配信管理装置１０内に送信装置Ｃ１側に設けられた輻輳制御アルゴリズムと同等なアルゴリズムを搭載することによって、バッファ管理を行い、結果的にデータの配信管理を行うようにしている。
【０１０５】
なお、ステップＳ２１では、遅延依存の回線であることを前提としているが、これに限らず、バーストエラーに起因した再送に伴う伝送遅延が生じる無線回線のような回線にも適用し、スプーフィング処理を行うことによってスループットの低下を防止することができる。この場合、図１４に示す処理を行うことによって、遅延依存の回線と同様に、バーストエラーに起因した再送に伴う伝送遅延に対しても、バッファ管理を行うことによって、スプーフィング処理を実行し、スループットの低下を防止するようにしている。図１４において、まず、データ配信管理装置１０は、通信すべき回線がバーストエラーが生じ易い回線であるか否かを判断する（ステップＳ１２１）。この判断は、たとえば、接続される経路毎の回線状況、すなわちバーストエラーが生じ易い回線であるか否かをテーブルとして保持しておくことによって実現される。
【０１０６】
その後、バーストエラーが生じ易い回線である場合（ステップＳ１２１，ＹＥＳ）には、転送データの一時保存を行い（ステップＳ１２２）、スプーフィング処理に備える。その後、一定期間、宛先からＡＣＫを受信しなかったか否かを判断する（ステップＳ１２３）。ＡＣＫを受信していない場合（ステップＳ１２３，ＹＥＳ）には、スプーフィング処理を実行し（ステップＳ１２４）、スループットの低下を防止し、本処理を終了する。このスプーフィング処理は、仮ＡＣＫの転送を行う上述したステップＳ１３の処理に該当する。
【０１０７】
一方、バーストエラーが生じ易い回線でない場合（ステップＳ１２１，ＮＯ）、および一定期間内に、宛先からＡＣＫを受信した場合（ステップＳ１２３，ＮＯ）には転送データを破棄した後（ステップＳ１２５）、本処理を終了する。なお、この処理は、上述した遅延依存の回線に対するスプーフィング処理と組み合わせるようにしてもよい。
【０１０８】
実施の形態２．
つぎに、この発明の実施の形態２について説明する。上述した実施の形態１では、データ配信管理装置１０を、伝送遅延の大きな回線３と小さな回線２との間に配置していたが、この実施の形態２では、送信装置Ｃ１および受信装置Ｃ２がそれぞれ送受信機能を有する端末装置とし、受信装置Ｃ２側にデータ配信管理装置１０に相当するデータ配信管理装置を設け、双方向の遅延に対して改善することができるようにしている。
【０１０９】
図１３に示すように、遅延の大きな回線３の両端にデータ配信管理装置１０，２０を設け、各データ配信管理装置１０，２０に遅延の小さい回線２ａ，２ｂを介して端末装置Ｃ２１，Ｃ２２をそれぞれ接続する。ここで、端末装置Ｃ２１，Ｃ２２は、データの送信機能および受信機能を備えている。データ配信管理装置１０は、図１に示したデータ配信管理装置１０と同じであり、端末装置Ｃ２１から送られた送信データを回線３を介して端末装置Ｃ２２に転送するとともに、端末装置Ｃ２１に対する仮の到達確認応答の返送処理を行う。データ配信管理装置２０は、データ配信管理装置１０と同様に、端末装置Ｃ２２から送られた送信データを、回線３を介して端末Ｃ２１に転送するとともに、端末装置Ｃ２２に対する仮の到達確認応答の返送処理を行う。ただし、データ配信管理装置１０，２０は、遅延の大きな回線３からデータを受信した場合、このデータの転送処理のみを行う。たとえば、データ配信管理装置２０は、データ配信管理装置１０からデータを受信した場合、このデータを端末装置Ｃ２２に転送する処理のみを行い、仮の到達確認応答の返送処理は行わない。これによって、双方向の遅延を改善した通信を行うことができる。
【０１１２】
【発明の効果】
以上説明したように、この発明によれば、バッファ管理手段は、送信元のスループット情報をもとに、自身のバッファのバッファサイズを可変設定するようにしているので、データ配信における輻輳状態を回避し、高信頼かつ高速な通信を実現できる。また、速度調整手段は、宛先の受信バッファの状態に応じてスループットの増減幅を調整するようにしているので、輻輳による伝送遅延による速度性能の劣化を改善することができるという効果を奏する。さらに、配信管理手段は、予測手段がバッファのバッファサイズ不足を予測した場合に、仮の送達確認応答の返送を停止させる制御を行うようにし、自身のバッファ状態に応じて送信側のスループットを調整するようにしているので、輻輳に応じた伝送遅延による速度性能の劣化を改善することができるという効果を奏する。また、送信元ＩＰと送信元ポートとの組み合わせ、および宛先ＩＰと宛先ポートとの組み合わせが全て同一の通信を一の管理単位とし、この管理単位ごとに、かつ、送信元および宛先のそれぞれに対して、優先度の程度を表す指標を設定した優先度管理テーブルが具備され、配信管理手段は、送信元および宛先のそれぞれに設定された優先度指標に応じてバッファサイズを調整するようにしているので、従来のデータ配信管理装置と比較して、一層速く、一層効率的なデータ配信を行うことができるという効果を奏する。
【０１１３】
つぎの発明によれば、バッファ管理手段は、送信元のスループット情報をもとに、バッファのバッファサイズを可変設定するようにしているので、データ配信における輻輳状態を回避し、高信頼かつ高速な通信を実現できる。また、速度調整手段は、宛先の受信バッファの状態に応じてスループットの増減幅を調整するようにしているので、輻輳による伝送遅延による速度性能の劣化を改善することができるという効果を奏する。さらに、配信管理手段は、予測手段がバッファのバッファサイズ不足を予測した場合に、仮の送達確認応答の返信速度を低下させる制御を行うようにし、バッファ状態に応じて送信側のスループットを調整するようにしているので、輻輳に応じた伝送遅延による速度性能の劣化を改善することができるという効果を奏する。また、送信元ＩＰと送信元ポートとの組み合わせ、および宛先ＩＰと宛先ポートとの組み合わせが全て同一の通信を一の管理単位とし、この管理単位ごとに、かつ、送信元および宛先のそれぞれに対して、優先度の程度を表す指標を設定した優先度管理テーブルが具備され、配信管理手段は、送信元および宛先のそれぞれに設定された優先度指標に応じてバッファサイズを調整するようにしているので、従来のデータ配信管理装置と比較して、一層速く、一層効率的なデータ配信を行うことができるという効果を奏する。
【０１１４】
つぎの発明によれば、バッファ管理手段は、送信元のスループット情報をもとに、バッファのバッファサイズを可変設定するようにしているので、データ配信における輻輳状態を回避し、高信頼かつ高速な通信を実現できる。また、速度調整手段は、宛先の受信バッファの状態に応じてスループットの増減幅を調整するようにしているので、輻輳による伝送遅延による速度性能の劣化を改善することができるという効果を奏する。さらに、配信管理手段は、予測手段がバッファのバッファサイズ不足を予測した場合に、仮の送達確認応答のウィンドウ情報を小さくする制御を行うようにし、バッファ状態に応じて送信側のスループットを調整するようにしているので、輻輳に応じた伝送遅延による速度性能の劣化を改善することができるという効果を奏する。また、送信元ＩＰと送信元ポートとの組み合わせ、および宛先ＩＰと宛先ポートとの組み合わせが全て同一の通信を一の管理単位とし、この管理単位ごとに、かつ、送信元および宛先のそれぞれに対して、優先度の程度を表す指標を設定した優先度管理テーブルが具備され、配信管理手段は、送信元および宛先のそれぞれに設定された優先度指標に応じてバッファサイズを調整するようにしているので、従来のデータ配信管理装置と比較して、一層速く、一層効率的なデータ配信を行うことができるという効果を奏する。
【０１１５】
つぎの発明によれば、バッファ管理手段は、送信元のスループット情報をもとに、バッファのバッファサイズを可変設定するようにしているので、データ配信における輻輳状態を回避し、高信頼かつ高速な通信を実現できる。また、速度調整手段は、宛先の受信バッファの状態に応じてスループットの増減幅を調整するようにしているので、輻輳による伝送遅延による速度性能の劣化を改善することができるという効果を奏する。さらに、配信管理手段は、予測手段がバッファのバッファサイズ不足を予測した場合に、新規の仮の送達確認応答を利用するコネクション接続要求を受けない制御を行うようにし、バッファ状態に応じて送信側のスループットを調整するようにしているので、輻輳に応じた伝送遅延による速度性能の劣化を改善することができるという効果を奏する。また、送信元ＩＰと送信元ポートとの組み合わせ、および宛先ＩＰと宛先ポートとの組み合わせが全て同一の通信を一の管理単位とし、この管理単位ごとに、かつ、送信元および宛先のそれぞれに対して、優先度の程度を表す指標を設定した優先度管理テーブルが具備され、配信管理手段は、送信元および宛先のそれぞれに設定された優先度指標に応じてバッファサイズを調整するようにしているので、従来のデータ配信管理装置と比較して、一層速く、一層効率的なデータ配信を行うことができるという効果を奏する。
【０１１７】
つぎの発明によれば、前記配信管理手段は、前記バッファの空き領域が、予め設定されたバッファサイズの余裕値を超えた場合に受信データ量を抑制する通信に対して、前記受信データ量が抑制されるように該通信の送信元に指示するようにしているので、柔軟かつ効率的なデータ配信を行うことができるという効果を奏する。
【０１１８】
つぎの発明によれば、決定手段が、選択的な速度調整を行うか否かを決定するようにしているので、柔軟かつ効率的なデータ配信を行うことができるという効果を奏する。
【０１１９】
つぎの発明によれば、データ配信管理装置が第１の端末装置と第２の端末装置との間に配置され、第１の端末装置あるいは第２の端末装置からのスループットの低下を防止する制御するようにしているので、輻輳に応じた伝送遅延による速度性能の劣化を改善することができるという効果を奏する。
【０１２２】
つぎの発明によれば、バッファ管理工程は、送信元のスループット情報をもとに、バッファのバッファサイズを可変設定するようにしているので、データ配信における輻輳状態を回避し、高信頼かつ高速な通信を実現できる。また、速度調整工程は、宛先の受信バッファの状態に応じてスループットの増減幅を調整するようにしているので、輻輳による伝送遅延による速度性能の劣化を改善することができるという効果を奏する。さらに、配信管理工程は、予測工程がバッファのバッファサイズ不足を予測した場合に、仮の送達確認応答の返送を停止させる制御を行うようにし、バッファ状態に応じて送信側のスループットを調整するようにしているので、輻輳に応じた伝送遅延による速度性能の劣化を改善することができるという効果を奏する。また、送信元ＩＰと送信元ポートとの組み合わせ、および宛先ＩＰと宛先ポートとの組み合わせが全て同一の通信を一の管理単位とし、この管理単位ごとに、かつ、送信元および宛先のそれぞれに対して、優先度の程度を表す指標を設定した優先度管理テーブルが具備され、配信管理工程は、送信元および宛先のそれぞれに設定された優先度指標に応じてバッファサイズを調整するようにしているので、従来のデータ配信管理装置と比較して、一層速く、一層効率的なデータ配信を行うことができるという効果を奏する。
【０１２３】
つぎの発明によれば、バッファ管理工程は、送信元のスループット情報をもとに、バッファのバッファサイズを可変設定するようにしているので、データ配信における輻輳状態を回避し、高信頼かつ高速な通信を実現できる。また、速度調整工程は、宛先の受信バッファの状態に応じてスループットの増減幅を調整するようにしているので、輻輳による伝送遅延による速度性能の劣化を改善することができるという効果を奏する。さらに、配信管理工程は、予測工程がバッファのバッファサイズ不足を予測した場合に、仮の送達確認応答の返信速度を低下させる制御を行うようにし、バッファ状態に応じて送信側のスループットを調整するようにしているので、輻輳に応じた伝送遅延による速度性能の劣化を改善することができるという効果を奏する。また、また、送信元ＩＰと送信元ポートとの組み合わせ、および宛先ＩＰと宛先ポートとの組み合わせが全て同一の通信を一の管理単位とし、この管理単位ごとに、かつ、送信元および宛先のそれぞれに対して、優先度の程度を表す指標を設定した優先度管理テーブルが具備され、配信管理工程は、送信元および宛先のそれぞれに設定された優先度指標に応じてバッファサイズを調整するようにしているので、従来のデータ配信管理装置と比較して、一層速く、一層効率的なデータ配信を行うことができるという効果を奏する。
【０１２４】
つぎの発明によれば、バッファ管理工程は、送信元のスループット情報をもとに、バッファのバッファサイズを可変設定するようにしているので、データ配信における輻輳状態を回避し、高信頼かつ高速な通信を実現できる。また、速度調整工程は、宛先の受信バッファの状態に応じてスループットの増減幅を調整するようにしているので、輻輳による伝送遅延による速度性能の劣化を改善することができるという効果を奏する。さらに、配信管理工程は、予測工程がバッファのバッファサイズ不足を予測した場合に、仮の送達確認応答のウィンドウ情報を小さくする制御を行うようにし、バッファ状態に応じて送信側のスループットを調整するようにしているので、輻輳に応じた伝送遅延による速度性能の劣化を改善することができるという効果を奏する。また、また、送信元ＩＰと送信元ポートとの組み合わせ、および宛先ＩＰと宛先ポートとの組み合わせが全て同一の通信を一の管理単位とし、この管理単位ごとに、かつ、送信元および宛先のそれぞれに対して、優先度の程度を表す指標を設定した優先度管理テーブルが具備され、配信管理工程は、送信元および宛先のそれぞれに設定された優先度指標に応じてバッファサイズを調整するようにしているので、従来のデータ配信管理装置と比較して、一層速く、一層効率的なデータ配信を行うことができるという効果を奏する。
【０１２５】
つぎの発明によれば、バッファ管理工程は、送信元のスループット情報をもとに、バッファのバッファサイズを可変設定するようにしているので、データ配信における輻輳状態を回避し、高信頼かつ高速な通信を実現できる。また、速度調整工程は、宛先の受信バッファの状態に応じてスループットの増減幅を調整するようにしているので、輻輳による伝送遅延による速度性能の劣化を改善することができるという効果を奏する。さらに、配信管理工程は、予測工程がバッファのバッファサイズ不足を予測した場合に、新規の仮の送達確認応答を利用するコネクション接続要求を受けない制御を行うようにし、バッファ状態に応じて送信側のスループットを調整するようにしているので、輻輳に応じた伝送遅延による速度性能の劣化を改善することができるという効果を奏する。また、また、送信元ＩＰと送信元ポートとの組み合わせ、および宛先ＩＰと宛先ポートとの組み合わせが全て同一の通信を一の管理単位とし、この管理単位ごとに、かつ、送信元および宛先のそれぞれに対して、優先度の程度を表す指標を設定した優先度管理テーブルが具備され、配信管理工程は、送信元および宛先のそれぞれに設定された優先度指標に応じてバッファサイズを調整するようにしているので、従来のデータ配信管理装置と比較して、一層速く、一層効率的なデータ配信を行うことができるという効果を奏する。
【０１２７】
つぎの発明によれば、前記配信管理工程は、前記バッファの空き領域が、予め設定されたバッファサイズの余裕値を超えた場合に受信データ量を抑制する通信に対して、前記受信データ量が抑制されるように該通信の送信元に指示するようにしているので、柔軟かつ効率的なデータ配信を行うことができるという効果を奏する。
【０１２８】
つぎの発明によれば、決定工程が、選択的な速度調整を行うか否かを決定するようにしているので、柔軟かつ効率的なデータ配信を行うことができるという効果を奏する。
【図面の簡単な説明】
【図１】 この発明の実施の形態１であるデータ配信管理装置を含むデータ配信管理システムの構成を示すブロック図である。
【図２】 図１に示したデータ配信管理装置によるデータ配信管理処理手順を示すフローチャートである。
【図３】 図２に示したパケットのチェック処理手順を示す詳細フローチャートである。
【図４】 図１に示した経路管理テーブルの内容の一例を示す図である。
【図５】 図１に示したプロトコル管理テーブルの内容の一例を示す図である。
【図６】 図１に示した配信管理テーブルの内容の一例を示す図である。
【図７】 図１に示した配信管理テーブルの内容の一例を示す図である。
【図８】 ステップＳ３９に対応したｔｍｐＡＣＫ作成送信待ちによる速度調整の処理手順を示すフローチャートである。
【図９】 ステップＳ５６に対応した仮ＡＣＫ作成送信処理の手順を示すフローチャートである。
【図１０】 バッファ区分を示す図である。
【図１１】 受信確認および再送制御の処理手順を示すフローチャートである。
【図１２】 ＴＣＰ輻輳制御アルゴリズムが搭載されるデータ配信管理装置を示す図である。
【図１３】 ＴＣＰ輻輳制御アルゴリズムが搭載されるデータ配信管理装置と送信装置との間におけるデータ配信管理処理を示すフローチャートである。
【図１４】 バーストエラーが生じ易い回線に対するスプーフィング処理の適用処理手順を示すフローチャートである。
【図１５】 この発明の実施の形態４であって、二つのデータ配信管理装置を用いて双方向通信を可能にしたデータ配信管理システムの構成を示すブロック図である。
【図１６】 従来のデータ配信管理装置を含むデータ配信管理システムの構成を示すブロック図である。
【符号の説明】
１ 配信管理テーブル、２，２ａ，２ｂ，３ 回線、４ ｔｍｐＡＣＫバッファ、５ プロトコル管理テーブル、６ 送信バッファ、６ａ バッファ割当部、７ 受信バッファ、８ 経路管理テーブル、１０，２０ データ配信管理装置、１１，１７ 通信部、１２ ｔｍｐＡＣＫ使用判定部、１３ ｔｍｐＡＣＫ作成部、１４ ＳＧＴｉｍｅｒカウント部、１５ 配信データ記録部、１６ ＳＧ配信管理部、ＳＧ 送信ゲートウェイ、Ｃ１ 送信装置、Ｃ２ 受信装置、Ｃ２１，Ｃ２２ 端末装置。
Claims (13)
- 少なくとも受信したデータを宛先に向けて転送するとともに、宛先からの送達確認応答を受信するまでデータセグメントを保存し、必要に応じて再送処理を行う機能を有したデータ配信管理装置において、
受信したデータセグメントを保存するバッファと、
送信元のスループット情報をもとに、前記バッファのバッファサイズを可変設定するバッファ管理手段と、
宛先の受信バッファの状態に応じたデータ転送速度調整を行う速度調整手段と、
受信したデータを宛先に向けて転送した際に、送信元に対して仮の送達確認応答を作成し、返送する仮送達確認応答手段と、
前記バッファのバッファサイズ不足を予測する予測手段と、
送信元ＩＰと送信元ポートとの組み合わせ、および宛先ＩＰと宛先ポートとの組み合わせが全て同一の通信を一の管理単位とし、該管理単位ごとに、かつ、該送信元および該宛先のそれぞれに対して、優先度の程度を表す指標を設定した優先度管理テーブルと、
前記予測手段が前記バッファのバッファサイズ不足を予測した場合に、前記仮の送達確認応答の返送を停止させる制御を行うとともに、前記送信元および前記宛先のそれぞれに設定された優先度指標に応じて前記バッファサイズを調整する配信管理手段と、
を備えたことを特徴とするデータ配信管理装置。 - 少なくとも受信したデータを宛先に向けて転送するとともに、宛先からの送達確認応答を受信するまでデータセグメントを保存し、必要に応じて再送処理を行う機能を有したデータ配信管理装置において、
受信したデータセグメントを保存するバッファと、
送信元のスループット情報をもとに、前記バッファのバッファサイズを可変設定するバッファ管理手段と、
宛先の受信バッファの状態に応じたデータ転送速度調整を行う速度調整手段と、
受信したデータを宛先に向けて転送した際に、送信元に対して仮の送達確認応答を作成し、返送する仮送達確認応答手段と、
前記バッファのバッファサイズ不足を予測する予測手段と、
送信元ＩＰと送信元ポートとの組み合わせ、および宛先ＩＰと宛先ポートとの組み合わせが全て同一の通信を一の管理単位とし、該管理単位ごとに、かつ、該送信元および該宛先のそれぞれに対して、優先度の程度を表す指標を設定した優先度管理テーブルと、
前記予測手段が前記バッファのバッファサイズ不足を予測した場合に、前記仮の送達確認応答の返信速度を低下させる制御を行うとともに、前記送信元および前記宛先のそれぞれに設定された優先度指標に応じて前記バッファサイズを調整する配信管理手段と、
を備えたことを特徴とするデータ配信管理装置。 - 少なくとも受信したデータを宛先に向けて転送するとともに、宛先からの送達確認応答を受信するまでデータセグメントを保存し、必要に応じて再送処理を行う機能を有したデータ配信管理装置において、
受信したデータセグメントを保存するバッファと、
送信元のスループット情報をもとに、前記バッファのバッファサイズを可変設定するバッファ管理手段と、
宛先の受信バッファの状態に応じたデータ転送速度調整を行う速度調整手段と、
受信したデータを宛先に向けて転送した際に、送信元に対して仮の送達確認応答を作成し、返送する仮送達確認応答手段と、
前記バッファのバッファサイズ不足を予測する予測手段と、
送信元ＩＰと送信元ポートとの組み合わせ、および宛先ＩＰと宛先ポートとの組み合わせが全て同一の通信を一の管理単位とし、該管理単位ごとに、かつ、該送信元および該宛先のそれぞれに対して、優先度の程度を表す指標を設定した優先度管理テーブルと、
前記予測手段が前記バッファのバッファサイズ不足を予測した場合に、前記仮の送達確認応答のウィンドウ情報を小さくする制御を行うとともに、前記送信元および前記宛先のそれぞれに設定された優先度指標に応じて前記バッファサイズを調整する配信管理手段と、
を備えたことを特徴とするデータ配信管理装置。 - 少なくとも受信したデータを宛先に向けて転送するとともに、宛先からの送達確認応答を受信するまでデータセグメントを保存し、必要に応じて再送処理を行う機能を有したデータ配信管理装置において、
受信したデータセグメントを保存するバッファと、
送信元のスループット情報をもとに、前記バッファのバッファサイズを可変設定するバッファ管理手段と、
宛先の受信バッファの状態に応じたデータ転送速度調整を行う速度調整手段と、
受信したデータを宛先に向けて転送した際に、送信元に対して仮の送達確認応答を作成し、返送する仮送達確認応答手段と、
前記バッファのバッファサイズ不足を予測する予測手段と、
送信元ＩＰと送信元ポートとの組み合わせ、および宛先ＩＰと宛先ポートとの組み合わせが全て同一の通信を一の管理単位とし、該管理単位ごとに、かつ、該送信元および該宛先のそれぞれに対して、優先度の程度を表す指標を設定した優先度管理テーブルと、
前記予測手段が前記バッファのバッファサイズ不足を予測した場合に、新規の前記仮の送達確認応答を利用するコネクション接続要求を受けない制御を行うとともに、前記送信元および前記宛先のそれぞれに設定された優先度指標に応じて前記バッファサイズを調整する配信管理手段と、
を備えたことを特徴とするデータ配信管理装置。 - 前記配信管理手段は、前記バッファの空き領域が、予め設定されたバッファサイズの余裕値を超えた場合に受信データ量を抑制する通信に対して、前記受信データ量が抑制されるように該通信の送信元に指示することを特徴とする請求項１〜４のいずれか一つに記載のデータ配信管理装置。
- 選択的な速度調整を行うか否かを決定する決定手段をさらに備えたことを特徴とする請求項１〜５のいずれか一つに記載のデータ配信管理装置。
- データを送受信する第１の端末装置と、
前記該第１の端末装置の通信相手先である第２の端末装置と、
前記第１の端末装置と前記第２の端末装置との間の伝送路上に配置され、請求項１〜６のいずれか一つに記載の１以上のデータ配信管理装置と、
を備えたことを特徴とするデータ配信管理システム。 - 少なくとも受信したデータを宛先に向けて転送するとともに、宛先からの送達確認応答を受信するまでデータセグメントを保存し、必要に応じて再送処理を行う機能を有したデータ配信管理装置のデータ配信管理方法において、
受信したデータセグメントを保存する保存工程と、
送信元のスループット情報および配信処理終了までにかかる時間をもとに、前記バッファのバッファサイズを可変設定するバッファ管理工程と、
宛先の受信バッファの状態に応じたデータ転送速度調整を行う速度調整工程と、
受信したデータを宛先に向けて転送した際に、送信元に対して仮の送達確認応答を作成し、返送する仮送達確認応答工程と、
前記バッファのバッファサイズ不足を予測する予測工程と、
送信元ＩＰと送信元ポートとの組み合わせ、および宛先ＩＰと宛先ポートとの組み合わせが全て同一の通信を一の管理単位とし、該管理単位ごとに、かつ、該送信元および該宛先のそれぞれに対して、優先度の程度を表す指標を設定する優先度設定工程と、
前記予測工程が前記バッファのバッファサイズ不足を予測した場合に、前記仮の送達確認応答の返送を停止させる制御を行うとともに、前記送信元および前記宛先のそれぞれに設定された優先度指標に応じて前記バッファサイズを調整する配信管理工程と、
を含むことを特徴とするデータ配信管理方法。 - 少なくとも受信したデータを宛先に向けて転送するとともに、宛先からの送達確認応答を受信するまでデータセグメントを保存し、必要に応じて再送処理を行う機能を有したデータ配信管理装置のデータ配信管理方法において、
受信したデータセグメントを保存する保存工程と、
送信元のスループット情報および配信処理終了までにかかる時間をもとに、前記バッファのバッファサイズを可変設定するバッファ管理工程と、
宛先の受信バッファの状態に応じたデータ転送速度調整を行う速度調整工程と、
受信したデータを宛先に向けて転送した際に、送信元に対して仮の送達確認応答を作成し、返送する仮送達確認応答工程と、
前記バッファのバッファサイズ不足を予測する予測工程と、
送信元ＩＰと送信元ポートとの組み合わせ、および宛先ＩＰと宛先ポートとの組み合わせが全て同一の通信を一の管理単位とし、該管理単位ごとに、かつ、該送信元および該宛先のそれぞれに対して、優先度の程度を表す指標を設定する優先度設定工程と、
前記予測工程が前記バッファのバッファサイズ不足を予測した場合に、前記仮の送達確認応答の返信速度を低下させる制御を行うとともに、前記仮の送達確認応答の返送を停止させる制御を行うとともに、前記送信元および前記宛先のそれぞれに設定された優先度指標に応じて前記バッファサイズを調整する配信管理工程と、
を含むことを特徴とするデータ配信管理方法。 - 少なくとも受信したデータを宛先に向けて転送するとともに、宛先からの送達確認応答を受信するまでデータセグメントを保存し、必要に応じて再送処理を行う機能を有したデータ配信管理装置のデータ配信管理方法において、
受信したデータセグメントを保存する保存工程と、
送信元のスループット情報および配信処理終了までにかかる時間をもとに、前記バッファのバッファサイズを可変設定するバッファ管理工程と、
宛先の受信バッファの状態に応じたデータ転送速度調整を行う速度調整工程と、
受信したデータを宛先に向けて転送した際に、送信元に対して仮の送達確認応答を作成し、返送する仮送達確認応答工程と、
前記バッファのバッファサイズ不足を予測する予測工程と、
送信元ＩＰと送信元ポートとの組み合わせ、および宛先ＩＰと宛先ポートとの組み合わせが全て同一の通信を一の管理単位とし、該管理単位ごとに、かつ、該送信元および該宛先のそれぞれに対して、優先度の程度を表す指標を設定する優先度設定工程と、
前記予測工程が前記バッファのバッファサイズ不足を予測した場合に、前記仮の送達確認応答のウィンドウ情報を小さくする制御を行うとともに、前記送信元および前記宛先のそれぞれに設定された優先度指標に応じて前記バッファサイズを調整する配信管理工程と、
を含むことを特徴とするデータ配信管理方法。 - 少なくとも受信したデータを宛先に向けて転送するとともに、宛先からの送達確認応答を受信するまでデータセグメントを保存し、必要に応じて再送処理を行う機能を有したデータ配信管理装置のデータ配信管理方法において、
受信したデータセグメントを保存する保存工程と、
送信元のスループット情報および配信処理終了までにかかる時間をもとに、前記バッファのバッファサイズを可変設定するバッファ管理工程と、
宛先の受信バッファの状態に応じたデータ転送速度調整を行う速度調整工程と、
受信したデータを宛先に向けて転送した際に、送信元に対して仮の送達確認応答を作成し、返送する仮送達確認応答工程と、
前記バッファのバッファサイズ不足を予測する予測工程と、
送信元ＩＰと送信元ポートとの組み合わせ、および宛先ＩＰと宛先ポートとの組み合わせが全て同一の通信を一の管理単位とし、該管理単位ごとに、かつ、該送信元および該宛先のそれぞれに対して、優先度の程度を表す指標を設定する優先度設定工程と、
前記予測工程が前記バッファのバッファサイズ不足を予測した場合に、新規の前記仮の送達確認応答を利用するコネクション接続要求を受けない制御を行うとともに、前記送信元および前記宛先のそれぞれに設定された優先度指標に応じて前記バッファサイズを調整する配信管理工程と、
を含むことを特徴とするデータ配信管理方法。 - 前記配信管理工程は、前記バッファの空き領域が、予め設定されたバッファサイズの余裕値を超えた場合に受信データ量を抑制する通信に対して、前記受信データ量が抑制されるように該通信の送信元に指示することを特徴とする請求項８〜１１のいずれか一つに記載のデータ配信管理方法。
- 選択的な速度調整を行うか否かを決定する決定工程をさらに含むことを特徴とする請求項８〜１２のいずれか一つに記載のデータ配信管理方法。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2001321030A JP4302339B2 (ja) | 2001-10-18 | 2001-10-18 | データ配信管理装置、データ配信管理システムおよびデータ配信管理方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2001321030A JP4302339B2 (ja) | 2001-10-18 | 2001-10-18 | データ配信管理装置、データ配信管理システムおよびデータ配信管理方法 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2003124984A JP2003124984A (ja) | 2003-04-25 |
| JP4302339B2 true JP4302339B2 (ja) | 2009-07-22 |
Family
ID=19138324
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2001321030A Expired - Fee Related JP4302339B2 (ja) | 2001-10-18 | 2001-10-18 | データ配信管理装置、データ配信管理システムおよびデータ配信管理方法 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP4302339B2 (ja) |
Families Citing this family (20)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| FR2831742B1 (fr) * | 2001-10-25 | 2004-02-27 | Cit Alcatel | Procede de transmission de paquets par l'intermediaire d'un reseau de telecommunications utilisant le protocole ip |
| JP3974027B2 (ja) * | 2002-11-28 | 2007-09-12 | 株式会社エヌ・ティ・ティ・ドコモ | 基地局制御装置、データ伝送方法及びプログラム |
| WO2005006673A1 (ja) * | 2003-07-15 | 2005-01-20 | Fujitsu Limited | 帯域制御装置 |
| JP4639603B2 (ja) * | 2004-02-24 | 2011-02-23 | パナソニック株式会社 | 無線伝送装置および無線伝送装置の省電力駆動方法 |
| JP4624062B2 (ja) * | 2004-10-12 | 2011-02-02 | Ｎｅｃインフロンティア株式会社 | 通信システム |
| JP4318651B2 (ja) | 2005-02-25 | 2009-08-26 | 富士通株式会社 | 出力方法、出力装置及び通信システム |
| JP4509825B2 (ja) * | 2005-03-01 | 2010-07-21 | 三菱電機株式会社 | 移動体通信システム |
| JP2007124225A (ja) * | 2005-10-27 | 2007-05-17 | Oki Electric Ind Co Ltd | ネットワークスイッチ装置及び方法、無線アクセス装置、および、無線ネットワーク |
| JP2007189509A (ja) * | 2006-01-13 | 2007-07-26 | Mitsubishi Electric Corp | 呼制御サーバ、メディアプロキシおよび輻輳制御方法 |
| JP4627290B2 (ja) * | 2006-09-29 | 2011-02-09 | Ｋｄｄｉ株式会社 | Ｔｃｐを用いたレート制御方法、サーバ及びプログラム |
| JP4675409B2 (ja) * | 2008-12-08 | 2011-04-20 | 富士通株式会社 | 出力装置及び通信システム |
| JP5573709B2 (ja) | 2011-01-31 | 2014-08-20 | ブラザー工業株式会社 | 通信装置 |
| JP2013013093A (ja) * | 2012-07-20 | 2013-01-17 | Thomson Licensing | Ｔｃｐａｃｋの管理によるｌａｎにおけるスループット改善 |
| JP5564603B1 (ja) * | 2013-06-07 | 2014-07-30 | ソフトバンクモバイル株式会社 | 中継ノード |
| JP6350124B2 (ja) * | 2014-08-29 | 2018-07-04 | 沖電気工業株式会社 | データ中継装置、データ中継方法、及びデータ中継プログラム |
| JP2016139903A (ja) * | 2015-01-27 | 2016-08-04 | 富士通株式会社 | 通信装置、及びそのデータ中継方法 |
| WO2017090154A1 (ja) * | 2015-11-26 | 2017-06-01 | 株式会社日立製作所 | ストレージシステム及びストレージプログラム |
| JP6436926B2 (ja) * | 2016-03-03 | 2018-12-12 | ソフトバンク株式会社 | 通信装置、通信システム、プログラム、及び通信方法 |
| US20190245795A1 (en) * | 2016-09-23 | 2019-08-08 | Nec Corporation | Protocol termination device, relay method, and recording medium |
| JP6805713B2 (ja) * | 2016-10-19 | 2020-12-23 | 日本電気株式会社 | 受信トラヒックの高速化装置、高速化方法、および高速化プログラム |
-
2001
- 2001-10-18 JP JP2001321030A patent/JP4302339B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JP2003124984A (ja) | 2003-04-25 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4302339B2 (ja) | データ配信管理装置、データ配信管理システムおよびデータ配信管理方法 | |
| KR101746629B1 (ko) | 통신 장치 및 통신 방법 | |
| US6937600B2 (en) | Communication device and communication control method using lower layer data transmission order control at upper layer | |
| US7369498B1 (en) | Congestion control method for a packet-switched network | |
| US9178741B2 (en) | Method and system for processing a data unit | |
| CN101189840B (zh) | 数据单元中继设备和控制该数据单元中继设备的方法 | |
| EP1434380B1 (en) | Data transmission control method and system | |
| JP5544430B2 (ja) | 通信装置および通信システム | |
| KR101143172B1 (ko) | 웹 서비스를 위한 신뢰성 있는 메시징 프로토콜을 이용한메시지의 효율적인 전송 | |
| US20060221825A1 (en) | Congestion control network relay device and method | |
| US6438101B1 (en) | Method and apparatus for managing congestion within an internetwork using window adaptation | |
| US7069356B2 (en) | Method of controlling a queue buffer by performing congestion notification and automatically adapting a threshold value | |
| EP1371192B1 (en) | Method and device for improving a data throughput | |
| CN109714267B (zh) | 管理反向队列的传输控制方法及系统 | |
| JP2004297742A (ja) | 通信装置、通信制御方法及びプログラム | |
| JP3377994B2 (ja) | データ配信管理装置およびデータ配信管理方法 | |
| CN1674485A (zh) | 动态提供计算机系统资源的方法和系统 | |
| US8416694B2 (en) | Network feedback method and device | |
| JP3893247B2 (ja) | データ配信管理装置 | |
| EP1723751A1 (en) | Methods and devices for controlling data unit handling | |
| JP3782308B2 (ja) | データ配信管理装置、これを用いたデータ配信管理システムおよびデータ配信管理方法ならびにその方法をコンピュータに実行させるプログラム | |
| TW202335471A (zh) | 網路流壅塞管理裝置及其方法 | |
| TWI831622B (zh) | 網路流壅塞管理裝置及其方法 | |
| Schüler et al. | Performance improvements for TCP in mobile networks with high packet delay variations |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20040917 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20060529 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20060613 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20060804 |
|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20061031 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20061226 |
|
| A911 | Transfer to examiner for re-examination before appeal (zenchi) |
Free format text: JAPANESE INTERMEDIATE CODE: A911 Effective date: 20070109 |
|
| A912 | Re-examination (zenchi) completed and case transferred to appeal board |
Free format text: JAPANESE INTERMEDIATE CODE: A912 Effective date: 20070223 |
|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20090422 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120501 Year of fee payment: 3 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120501 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130501 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20140501 Year of fee payment: 5 |
|
| LAPS | Cancellation because of no payment of annual fees |