(57)【特許請求の範囲】
【請求項１】
送信したデータに対する送達確認応答を必要とする通信を行う第１の端末装置と該第１の端末装置の通信相手先である第２の端末装置との間の伝送路上に配置され、前記第１の端末装置との間の伝送遅延が前記第２の端末装置との間の伝送遅延に比して小さく、少なくとも前記第１の端末装置からのデータを前記第２の端末装置に対して転送する転送処理と該転送したデータに対する送達確認応答を作成し返送する返送処理とを行うことができるデータ配信管理装置において、
前記第１の端末装置のウィンドウサイズの情報を保持する保持手段と、
前記保持手段が保持するウィンドウサイズの情報に基づいて、該ウィンドウサイズが所定量より小さいとき前記送達確認応答の返送処理を行い、該ウィンドウサイズが所定量より大きいとき前記送達確認応答の返送処理を行わないように決定する決定手段と、
前記決定手段が前記送達確認応答の返送処理を行うと決定した場合に前記送達確認応答の返送処理を行う制御手段と、
を備えたことを特徴とするデータ配信管理装置。
【請求項２】
送信したデータに対する送達確認応答を必要とする通信を行う第１の端末装置と該第１の端末装置の通信相手先である第２の端末装置との間の伝送路上に配置され、前記第１の端末装置との間の伝送遅延が前記第２の端末装置との間の伝送遅延に比して小さく、少なくとも前記第１の端末装置からのデータを前記第２の端末装置に対して転送する転送処理と該転送したデータに対する送達確認応答を作成し返送する返送処理とを行うことができるデータ配信管理装置において、
前記第１の端末装置のウィンドウサイズの情報を保持する保持手段と、
前記保持手段が保持するウィンドウサイズの情報に基づいて、該ウィンドウサイズが所定量より小さいとき前記送達確認応答の返送処理のタイミングを短くし、該ウィンドウサイズが所定量より大きいとき前記送達確認応答のタイミングを長くする制御手段と、
を備えたことを特徴とするデータ配信管理装置。
【請求項３】
前記第２の端末装置から受信した送達確認応答の受信時点から前記第１の端末装置に送達確認応答を返送する返送時点までの遅延時間に略対応した所定の下限値を初期値とする現在の遅延時間から、前記第１の端末装置における現在のウィンドウサイズから前回のウィンドウサイズを減算した第１の減算値に所定値を乗算した第２の値を減算した第２の減算値と、前記所定の下限値との最大値を算出し、該最大値と所定の上限値との最小値とを算出し、該最小値を前記現在の遅延時間として再設定する処理を繰り返して最新の現在の遅延時間を算出する算出手段をさらに備え、
前記制御手段は、前記算出手段によって算出された最新の現在の遅延時間に応じて前記第１の端末装置が送信したデータに対する前記送達確認応答の返送タイミングを可変させる制御を行うことを特徴とする請求項２に記載のデータ配信管理装置。
【請求項４】
送信したデータに対する送達確認応答を必要とする通信を行う第１の端末装置と該第１の端末装置の通信相手先である第２の端末装置との間の伝送路上に配置され、前記第１の端末装置との間の伝送遅延が前記第２の端末装置との間の伝送遅延に比して小さく、少なくとも前記第１の端末装置からのデータを前記第２の端末装置に対して転送する転送処理と該転送したデータに対する送達確認応答を作成し返送する返送処理とを行うことができるデータ配信管理装置において、
前記第１の端末装置のウィンドウサイズと前記第１の端末装置から受信したデータセグメントとを少なくとも保持する保持手段と、
前記保持手段が保持する前記ウィンドウサイズと前記データセグメントとの組み合わせに基づいて、前記ウィンドウサイズが所定量より小さくかつ前記送達確認応答を送信するデータセグメントが有るとき前記送達確認応答の返送処理を行い、前記ウィンドウサイズが所定量より大きいか或いは前記送達確認応答を送信するデータセグメントが無いとき前記送達確認応答の返送処理を行わないように決定する決定手段と、
前記決定手段が前記送達確認応答の返送を行うと決定した場合に該送達確認応答の返送を行う制御手段と、
を備えたことを特徴とするデータ配信管理装置。
【請求項５】
少なくとも前記第１の端末装置が送信したデータを保持するデータバッファと、少なくとも前記第１の端末装置が送信したデータの登録情報を管理する管理手段と、前記第１の端末装置が送信したデータを転送した前記第２の端末装置から該データに対する送達確認応答を受信した場合、前記データバッファに保持されている該データおよび前記管理手段が管理する該データの登録情報を削除する制御を行う削除制御手段と、
をさらに備えたことを特徴とする請求項１〜４のいずれか一つに記載のデータ配信管理装置。
【請求項６】
前記データバッファ内に保持されたデータのうちの削除対象のデータである送達確認済みのセグメント数を計数する計数手段をさらに備え、
前記削除制御手段は、前記第１の端末装置が送信したデータを転送した前記第２の端末装置から該データに対する送達確認応答の受信の都度、前記管理手段が管理する該データに登録情報を送達確認済みに設定し、前記計数手段が計数する該送達確認済みに設定されたセグメント数が所定数を越えた場合に、前記データバッファに保持されている該送達確認済みのデータと前記管理手段が管理する該送達確認済みのデータの登録情報を削除する  ことを特徴とする請求項５に記載のデータ配信管理装置。
【請求項７】
前記データバッファ内に保持されたデータのうちの削除対象のデータである送達確認済みのセグメント数を計数する第１の計数手段と、
前記管理手段が管理するデータのうちの削除対象のデータの登録情報を計数する第２の計数手段と、
をさらに備え、
前記削除制御手段は、前記第１の端末装置が送信したデータを転送した前記第２の端末装置から該データに対する送達確認応答の受信の都度、前記管理手段が管理する該データに関する情報を送達確認済みに設定し、前記第１の計数手段が計数する送達確認済みに設定されたセグメント数が第１の所定数を越えた場合に、前記データバッファに保持されている該送達確認済みのデータを削除し、前記第２の計数手段が計数する送達確認済みのデータの登録情報が第２の所定数を越えた場合に、該送達確認済みのデータの登録情報を削除する
ことを特徴とする請求項５に記載のデータ配信管理装置。
【請求項８】
所定時間を計時する計時手段をさらに備え、
前記削除制御手段は、前記第１の端末装置が送信したデータを転送した前記第２の端末  装置から該データに対する送達確認応答の受信の都度、前記管理手段が管理する該データに登録情報を送達確認済みに設定し、前記計時手段が前記所定時間を計時した際に、前記データバッファに保持されている該送達確認済みのデータと前記管理手段が管理する該送達確認済みのデータの登録情報を削除する
ことを特徴とする請求項５に記載のデータ配信管理装置。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
この発明は、送信したデータに対する送達確認応答を必要とする通信を行う第１の端末装置と該第１の端末装置の通信相手先である第２の端末装置との間の伝送路上に配置され、前記第１の端末装置との間の伝送遅延が前記第２の端末装置との間の伝送遅延に比して小さく、少なくとも前記第１の端末装置からのデータを前記第２の端末装置に対して転送する転送処理と該転送したデータに対する送達確認応答を作成し返送する返送処理とを行うことができるデータ配信管理装置に関し、特にデータ配信時における送達確認応答の受信タイミングに依存した速度性能劣化を改善することができるデータ配信管理装置に関するものである。
【０００２】
【従来の技術】
従来から、ＴＣＰを用いた通信では、送信側のＴＣＰは、送信バッファに対応したウィンドウサイズを持ち、このウィンドウサイズ内に限り、送信ウィンドウをスライドさせることによって、次々とデータ送信を行う。仮に、なんらかの理由によって送達確認応答を受け入れていない状況となった場合、ＴＣＰは、輻輳状態であると判断し、ウィンドウサイズを小さくし、これによってスループットを下げ、輻輳を解消しようとする。
【０００３】
しかし、衛星回線のような大容量であるとともに、物理的に伝送遅延の大きな回線においてＴＣＰを用いた場合、物理的な距離によって、データ送信からこのデータに対する送達確認応答が返ってくるまでに０．５秒以上を要する場合がある。この０．５秒は、一般的なＴＣＰにおける再送タイムアウト時間、すなわちデータ送信を失敗と判断し、データ再送を開始するまでの時間であり、ＴＣＰが、輻輳状態が生じていると判断してしまう時間である。この結果、衛星回線のように大容量の回線本来の大きさに見合った速度性能、すなわちスループットを発揮することができないという問題点が生じる。
【０００４】
図１１は、従来のデータ配信管理装置を用いたデータ配信管理システムの構成を示すブロック図である（情報処理学会研究報告98-DPS-89-12参照）。このデータ配信管理システムは、上述した問題点を解決し、スループットを向上させることができるシステムである。図１１において、このデータ配信管理システムは、送信装置Ｃ１１と、受信装置Ｃ１２と、この送信装置Ｃ１１および受信装置Ｃ１２にＴＣＰによる通信を行う回線Ｌ１１，Ｌ１２を介してそれぞれ接続された送信ゲートウェイ１００とを有する。回線Ｌ１２は、回線Ｌ１１に比して伝送遅延が大きい回線であり、たとえば衛星回線である。
【０００５】
図１１において、送信装置Ｃ１１は、データパケットを出力するデータパケット出力部１１１と、送信ゲートウェイ１００が作成した仮の到達確認応答を受信する仮送達確認応答受信部１１２とを有する。送信ゲートウェイ１００は、バッファ１０１および配信管理テーブル１０２を有するとともに、送信装置Ｃ１１から送信されたデータパケットを受信し、このデータパケットをバッファ１０１に蓄積させる蓄積部１０３と、回線Ｌ１２を介してバッファ１０１に蓄積したデータデータパケットを受信装置Ｃ１２に出力する出力部１０４と、受信装置Ｃ１２に送信したデータパケットに対する仮の送達確認応答を作成する仮送達確認応答作成部１０５と、この作成した仮の送達確認応答を送信装置Ｃ１１に送信する仮送達確認応答送信部１０６と、受信装置Ｃ１２から送られた送達確認応答を受信する仮送達確認応答受信部１０７と、受信したＳＹＮ（接続要求）パケットから通信情報を取得し、配信管理テーブル１０２に配信情報として記録する配信情報記憶制御部１０８と、データパケットの再送処理を行う再送処理部１０９とを有する。また、受信装置Ｃ１２は、送信ゲートウェイ１００から送られたデータパケットを受信するデータパケット受信部１２１と、送信ゲートウェイ１００に対して送達確認応答を出力する送達確認応答出力部１２２とを有する。
【０００６】
送信装置Ｃ１１からデータパケットが送出されると、送信ゲートウェイ１００は、受信したデータパケットをバッファ１０１に一時的に蓄積するとともに、配信管理テーブル１０２に、このデータパケットのエントリを追加する。送信ゲートウェイ１００は、送信装置Ｃ１１から受信したデータパケットを、回線Ｌ１２を介して受信装置Ｃ１２に転送するとともに、このデータパケットに対する仮の到達確認応答のデータパケットを作成し、送信装置Ｃ１１にこの仮の到達確認応答を送信する。
【０００７】
受信装置Ｃ１２は、送信ゲートウェイ１００からデータパケットを受信すると、この受信データパケットに対する送達確認応答を作成し、この送達確認応答を送信ゲートウェイ１００に送信する。この送達確認応答には、対応するデータパケットに関するデータとこのデータパケットの到達確認状況に関するデータとが含まれる。受信装置Ｃ１２から送達確認応答を受信した送信ゲートウェイ１００は、送信ゲートウェイ１００内に保持されているデータパケットであって、この送達確認応答に対応するデータパケットをクリアする。
【０００８】
ここで、送信ゲートウェイ１００から受信装置Ｃ１２にデータパケットが送信される過程において、このデータパケットの転送に失敗し、受信装置Ｃ１２がこのデータパケットを受信することができなかった場合、送信ゲートウェイ１００は、受信装置Ｃ１２側から同一の送達確認応答を３つ続けて受信し、このデータパケットの再送処理を行う。
【０００９】
このように、従来のデータ配信管理システムでは、送信ゲートウェイ１００が、送信ゲートウェイ１００から受信装置Ｃ１２に対するデータパケットの送信と同時に、送信装置Ｃ１１に対して仮の送達確認応答（ｔｍｐＡＣＫ）を返送することによって、回線Ｌ１２の伝送賃によるＴＣＰのウィンドウサイズの減少を防ぎ、スループットの低下をなくして速度性能の劣化を改善していた。
【００１０】
また、送信ゲートウェイ１００は、送信装置からデータパケットを受信すると、仮の送達確認応答を作成し、受信装置からの送達確認応答（ＡＣＫ）を受け付けるまで、このデータパケットを保持し、３つの同一の送達確認応答（ＤｕｐｌｉｃａｔｅＡＣＫ）を受信した時点で、このデータパケットの送信を失敗と判定し、この保持しているデータパケットの再送を行うようにしていた。
【００１１】
【発明が解決しようとする課題】
しかしながら、従来のデータ配信管理システムでは、送信装置Ｃ１１からデータセグメントを受信すると、送信ゲートウェイ１００が、送信装置Ｃ１１の送受信バッファあるいはウィンドウの状態、さらには回線Ｌ１１の輻輳状態を考慮せずに、直ちに全てのデータセグメントに対する仮の送達確認応答を作成し、送信装置Ｃ１１に対して送信するようにしていたため、送信ゲートウェイ１００および送信装置Ｃ１１の処理負荷が大きくなり、結果として速度性能が劣化する場合が生じるという問題点があった。
【００１２】
また、受信装置Ｃ１２から送信された送達確認応答を含むデータは、受信装置Ｃ１２が把握している送信装置Ｃ１１の受信ウィンドウの状態に応じて決定されたスループットで送信されるが、送信ゲートウェイ１００においてデータが受信された時点では、前回の古いウィンドウサイズに基づいたスループットでデータ転送を行っていたため、送信装置Ｃ１１の受信バッファあるいは受信ウィンドウが減少していた場合、送信装置Ｃ１１の更新された受信バッファあるいは受信ウィンドウの状態に対応できず、送信装置Ｃ１１の受信バッファおよびウィンドウがオーバーフローを引き起こしてしまう場合があるという問題点があった。
【００１３】
この発明は、上記に鑑みてなされたもので、送受信バッファ、ウィンドウサイズおよび回線の輻輳などの状態を考慮し、仮の送達確認応答の送信タイミングあるいは送信量を調整し、一層高速かつ効率的にデータ配信を行うことができるデータ配信管理装置を得ることを目的とする。
【００１４】
【課題を解決するための手段】
上記目的を達成するため、この発明にかかるデータ配信管理装置は、送信したデータに対する送達確認応答を必要とする通信を行う第１の端末装置と該第１の端末装置の通信相手先である第２の端末装置との間の伝送路上に配置され、前記第１の端末装置との間の伝送遅延が前記第２の端末装置との間の伝送遅延に比して小さく、少なくとも前記第１の端末装置からのデータを前記第２の端末装置に対して転送する転送処理と該転送したデータに対する送達確認応答を作成し返送する返送処理とを行うことができるデータ配信管理装置において、前記第１の端末装置のウィンドウサイズの情報を保持する保持手段と、前記保持手段が保持するウィンドウサイズの情報をもとに前記送達確認応答の返送処理を行うか否かを決定する決定手段と、前記決定手段が前記送達確認応答の返送処理を行うと決定した場合に前記送達確認応答の返送処理を行う制御手段とを備えたことを特徴とする。
【００１５】
この発明によれば、保持手段が、前記第１の端末装置のウィンドウサイズの情報を保持し、決定手段が、前記保持手段が保持するウィンドウサイズの情報をもとに前記送達確認応答の返送処理を行うか否かを決定し、制御手段が、前記決定手段が前記送達確認応答の返送処理を行うと決定した場合のみに前記送達確認応答の返送処理を行うようにし、送信元に対する送達確認応答の送信タイミングあるいは送信量を調整するようにしている。
【００１６】
つぎの発明にかかるデータ配信管理装置は、送信したデータに対する送達確認応答を必要とする通信を行う第１の端末装置と該第１の端末装置の通信相手先である第２の端末装置との間の伝送路上に配置され、前記第１の端末装置との間の伝送遅延が前記第２の端末装置との間の伝送遅延に比して小さく、少なくとも前記第１の端末装置からのデータを前記第２の端末装置に対して転送する転送処理と該転送したデータに対する送達確認応答を作成し返送する返送処理とを行うことができるデータ配信管理装置において、前記第１の端末装置のウィンドウサイズの情報を保持する保持手段と、前記保持手段が保持するウィンドウサイズの情報が示すウィンドウサイズに応じて前記第１の端末装置が送信したデータに対する前記送達確認応答の返送タイミングを可変させる制御を行う制御手段とを備えたことを特徴とする。
【００１７】
この発明によれば、保持手段が、前記第１の端末装置のウィンドウサイズの情報を保持し、制御手段が、前記保持手段が保持するウィンドウサイズの情報が示すウィンドウサイズに応じて前記第１の端末装置が送信したデータに対する前記送達確認応答の返送タイミングを可変させる制御を行うようにしている。
【００１８】
つぎの発明にかかるデータ配信管理装置は、上記の発明において、前記第２の端末装置から受信した送達確認応答の受信時点から前記第１の端末装置に送達確認応答を返送する返送時点までの遅延時間に略対応した所定の下限値を初期値とする現在の遅延時間から、前記第１の端末装置における現在のウィンドウサイズから前回のウィンドウサイズを減算した第１の減算値に所定値を乗算した第２の値を減算した第２の減算値と、前記所定の下限値との最大値を算出し、該最大値と所定の上限値との最小値とを算出し、該最小値を前記現在の遅延時間として再設定する処理を繰り返して最新の現在の遅延時間を算出する算出手段をさらに備え、前記制御手段は、前記算出手段によって算出された最新の現在の遅延時間に応じて前記第１の端末装置が送信したデータに対する前記送達確認応答の返送タイミングを可変させる制御を行うことを特徴とする。
【００１９】
この発明によれば、算出手段が、前記第２の端末装置から受信した送達確認応答の受信時点から前記第１の端末装置に送達確認応答を返送する返送時点までの遅延時間に略対応した所定の下限値を初期値とする現在の遅延時間から、前記第１の端末装置における現在のウィンドウサイズから前回のウィンドウサイズを減算した第１の減算値に所定値を乗算した第２の値を減算した第２の減算値と、前記所定の下限値との最大値を算出し、該最大値と所定の上限値との最小値とを算出し、該最小値を前記現在の遅延時間として再設定する処理を繰り返して最新の現在の遅延時間を算出し、前記制御手段が、前記算出手段によって算出された最新の現在の遅延時間に応じて前記第１の端末装置が送信したデータに対する前記送達確認応答の返送タイミングを可変させる制御を行うようにしている。
【００２０】
つぎの発明にかかるデータ配信管理装置は、送信したデータに対する送達確認応答を必要とする通信を行う第１の端末装置と該第１の端末装置の通信相手先である第２の端末装置との間の伝送路上に配置され、前記第１の端末装置との間の伝送遅延が前記第２の端末装置との間の伝送遅延に比して小さく、少なくとも前記第１の端末装置からのデータを前記第２の端末装置に対して転送する転送処理と該転送したデータに対する送達確認応答を作成し返送する返送処理とを行うことができるデータ配信管理装置において、前記第１の端末装置のウィンドウサイズと前記第１の端末装置から受信したデータのセグメント数と前記第２の端末装置からの受信確認応答の有無とを少なくとも保持する保持手段と、前記保持手段が保持する前記ウィンドウサイズと前記セグメント数と前記受信確認応答の有無との組み合わせによって前記第１の端末装置が送信したデータに対する前記送達確認応答の返送を行うか否かを決定する決定手段と、前記決定手段が前記送達確認応答の返送を行うと決定した場合に該送達確認応答の返送を行う制御手段とを備えたことを特徴とする。
【００２１】
この発明によれば、保持手段が、前記第１の端末装置のウィンドウサイズと前記第１の端末装置から受信したデータのセグメント数と前記第２の端末装置からの受信確認応答の有無とを少なくとも保持し、決定手段が、前記保持手段が保持する前記ウィンドウサイズと前記セグメント数と前記受信確認応答の有無との組み合わせによって前記第１の端末装置が送信したデータに対する前記送達確認応答の返送を行うか否かを決定し、制御手段が、前記決定手段が前記送達確認応答の返送を行うと決定した場合に該送達確認応答の返送を行うようにしている。
【００２２】
つぎの発明にかかるデータ配信管理装置は、送信したデータに対する送達確認応答を必要とする通信を行う第１の端末装置と該第１の端末装置の通信相手先である第２の端末装置との間の伝送路上に配置され、前記第１の端末装置との間の伝送遅延が前記第２の端末装置との間の伝送遅延に比して小さく、少なくとも前記第１の端末装置からのデータを前記第２の端末装置に対して転送する転送処理と該転送したデータに対する送達確認応答を作成し返送する返送処理とを行うことができるデータ配信管理装置において、前記第１の端末装置のウィンドウサイズの情報を保持する保持手段と、前記保持手段が保持するウィンドウサイズの情報が示すウィンドウサイズに応じて前記第１の端末装置が送信したデータに対する前記送達確認応答の作成密度を可変させる制御を行う制御手段とを備えたことを特徴とする。
【００２３】
この発明によれば、保持手段が、前記第１の端末装置のウィンドウサイズの情報を保持し、制御手段が、前記保持手段が保持するウィンドウサイズの情報が示すウィンドウサイズに応じて前記第１の端末装置が送信したデータに対する前記送達確認応答の作成密度を可変、たとえば送達確認応答を間引く制御を行うようにしている。
【００２４】
つぎの発明にかかるデータ配信管理装置は、上記の発明において、少なくとも前記第１の端末装置が送信したデータを保持するデータバッファと、少なくとも前記第１の端末装置が送信したデータの登録情報を管理する管理手段と、前記第１の端末装置が送信したデータを転送した前記第２の端末装置から該データに対する送達確認応答を受信した場合、前記データバッファに保持されている該データおよび前記管理手段が管理する該データの登録情報を削除する制御を行う削除制御手段とをさらに備えたことを特徴とする。
【００２５】
この発明によれば、データバッファが、少なくとも前記第１の端末装置が送信したデータを保持し、管理手段が、少なくとも前記第１の端末装置が送信したデータの登録情報を管理し、削除制御手段が、前記第１の端末装置が送信したデータを転送した前記第２の端末装置から該データに対する送達確認応答を受信した場合、前記データバッファに保持されている該データおよび前記管理手段が管理する該データの登録情報を削除する制御を行うようにしている。
【００２６】
つぎの発明にかかるデータ配信管理装置は、上記の発明において、前記データバッファ内に保持されたデータのうちの削除対象のデータである送達確認済みのセグメント数を計数する計数手段をさらに備え、前記削除制御手段は、前記第１の端末装置が送信したデータを転送した前記第２の端末装置から該データに対する送達確認応答の受信の都度、前記管理手段が管理する該データに登録情報を送達確認済みに設定し、前記計数手段が計数する該送達確認済みに設定されたセグメント数が所定数を越えた場合に、前記データバッファに保持されている該送達確認済みのデータと前記管理手段が管理する該送達確認済みのデータの登録情報を削除することを特徴とする。
【００２７】
この発明によれば、計数手段が、前記データバッファ内に保持されたデータのうちの削除対象のデータである送達確認済みのセグメント数を計数し、前記削除制御手段が、前記第１の端末装置が送信したデータを転送した前記第２の端末装置から該データに対する送達確認応答の受信の都度、前記管理手段が管理する該データに登録情報を送達確認済みに設定し、前記計数手段が計数する該送達確認済みに設定されたセグメント数が所定数を越えた場合に、前記データバッファに保持されている該送達確認済みのデータと前記管理手段が管理する該送達確認済みのデータの登録情報を削除するようにしている。
【００２８】
つぎの発明にかかるデータ配信管理装置は、上記の発明において、前記データバッファ内に保持されたデータのうちの削除対象のデータである送達確認済みのセグメント数を計数する第１の計数手段と、前記管理手段が管理するデータのうちの削除対象のデータの登録情報を計数する第２の計数手段とをさらに備え、前記削除制御手段は、前記第１の端末装置が送信したデータを転送した前記第２の端末装置から該データに対する送達確認応答の受信の都度、前記管理手段が管理する該データに関する情報を送達確認済みに設定し、前記第１の計数手段が計数する送達確認済みに設定されたセグメント数が第１の所定数を越えた場合に、前記データバッファに保持されている該送達確認済みのデータを削除し、前記第２の計数手段が計数する送達確認済みのデータの登録情報が第２の所定数を越えた場合に、該送達確認済みのデータの登録情報を削除することを特徴とする。
【００２９】
この発明によれば、第１の計数手段が、前記データバッファ内に保持されたデータのうちの削除対象のデータである送達確認済みのセグメント数を計数し、第２の計数手段が、前記管理手段が管理するデータのうちの削除対象のデータの登録情報を計数し、前記削除制御手段が、前記第１の端末装置が送信したデータを転送した前記第２の端末装置から該データに対する送達確認応答の受信の都度、前記管理手段が管理する該データに関する情報を送達確認済みに設定し、前記第１の計数手段が計数する送達確認済みに設定されたセグメント数が第１の所定数を越えた場合に、前記データバッファに保持されている該送達確認済みのデータを削除し、前記第２の計数手段が計数する送達確認済みのデータの登録情報が第２の所定数を越えた場合に、該送達確認済みのデータの登録情報を削除するようにしている。
【００３０】
つぎの発明にかかるデータ配信管理装置は、上記の発明において、所定時間を計時する計時手段をさらに備え、前記削除制御手段は、前記第１の端末装置が送信したデータを転送した前記第２の端末装置から該データに対する送達確認応答の受信の都度、前記管理手段が管理する該データに登録情報を送達確認済みに設定し、前記計時手段が前記所定時間を計時した際に、前記データバッファに保持されている該送達確認済みのデータと前記管理手段が管理する該送達確認済みのデータの登録情報を削除することを特徴とする。
【００３１】
この発明によれば、計時手段が、所定時間を計時する計時手段をさらに備え、前記削除制御手段が、前記第１の端末装置が送信したデータを転送した前記第２の端末装置から該データに対する送達確認応答の受信の都度、前記管理手段が管理する該データに登録情報を送達確認済みに設定し、計時手段が前記所定時間を計時した際に、前記データバッファに保持されている該送達確認済みのデータと前記管理手段が管理する該送達確認済みのデータの登録情報を削除するようにしている。
【００３２】
【発明の実施の形態】
以下、添付図面を参照して、この発明にかかるデータ配信管理装置の好適な実施の形態を詳細に説明する。
【００３３】
実施の形態１．
図１は、この発明の実施の形態１であるデータ配信管理装置を含むデータ配信管理システムの構成を示すブロック図である。図１において、このデータ配信管理システムは、端末装置Ｃ１が回線２ａを介してデータ配信管理装置１０に接続され、データ配信管理装置１０が回線３を介してデータ配信管理装置２０に接続され、データ配信管理装置２０が回線２ｂを介して端末装置Ｃ２に接続される。回線３は、衛星回線などの伝送遅延の大きな回線であり、回線２ａ，２ｂは、回線３に比して伝送遅延が小さい回線である。
【００３４】
データ配信管理装置１０は、ゲートウェイ機能部１０ａと、配信管理テーブル１（保持手段）と、プロトコル管理テーブル５と、送信バッファ６、および受信バッファ７とを有する。データ配信管理装置１０は、端末装置Ｃ１との間においてデータパケットの入出力処理を行う通信部１７と、データ配信管理装置２０を介した端末装置Ｃ２との間においてデータパケットの入出力処理を行う通信部１１と、仮の送達確認応答（ｔｍｐＡＣＫ）を作成するためのデータパケットを保存するｔｍｐＡＣＫバッファ４と、端末装置Ｃ２に対して送信したデータパケットに対してｔｍｐＡＣＫの返送を行うか否かを判断するｔｍｐＡＣＫ使用判定部１２（決定手段）、端末装置Ｃ１から受信したデータパケットをもとにｔｍｐＡＣＫを作成するｔｍｐＡＣＫ作成部１３（制御手段）と、データパケット毎の送達確認応答のタイムアウト時間（ＳＧＴｉｍｅｒ）をカウントアップし、この送達確認応答待ちのタイムアウトイベントを発生させるＳＧＴｉｍｅｒカウント部１４（制御手段）と、端末装置Ｃ１にｔｍｐＡＣＫを送信したか否かの情報および端末装置Ｃ２からの送達確認応答に関する情報を配信管理テーブル１に書き込む処理を行う配信データ記録部１５と、ＳＧＴｉｍｅｒ値および配信管理テーブル１の内容に対応してデータパケットの配信を管理するＳＧ配信管理部１６（制御手段）とを有する。
【００３５】
なお、図１において、送信バッファ６、受信バッファ７、およびｔｍｐＡＣＫバッファ４は、それぞれ別個のバッファとして示されているが、これに限らず、部分的あるいは全てを同一のバッファとして実装するようにしてもよい。また、別個のバッファとして実装する場合であっても、同一のバッファとして実装する場合であっても、管理目的に応じて制御情報などを含めた情報とともに用いることが可能な図示しない管理テーブルを設け、パケットデータの格納位置が識別可能なように実装することによって、管理および検索の効率化を図ることができる。
【００３６】
データ配信管理装置２０は、データ配信管理装置１０と同じ構成を有する。データ配信管理装置１０は、端末装置Ｃ１から送信されたデータパケットをデータ配信管理装置２０を介して端末装置Ｃ２に転送する。この際、データ配信管理装置１０は、ｔｍｐＡＣＫ使用判定部１２において端末装置Ｃ１から受信したデータパケットに対し、ｔｍｐＡＣＫの返送機能を適用するか否かを判定し、適用すると判定された場合、端末装置Ｃ１に、送信されたデータパケットに対する仮の到達確認応答（ｔｍｐＡＣＫ）を返送し、データ配信管理装置２０は、通常のゲートウェイと同様に、データ配信管理装置１０から送られたデータパケットを端末装置Ｃ２に転送するルーティング処理のみを行い、ｔｍｐＡＣＫの返送処理は行わない。また、データ配信管理装置２０は、端末装置Ｃ２から送信されたデータパケットをデータ配信管理装置１０を介して端末装置Ｃ１に転送する。この際、データ配信管理装置２０は、ｔｍｐＡＣＫ使用判定部１２において端末装置Ｃ２から受信したデータパケットに対し、ｔｍｐＡＣＫの返送機能を適用するか否かを判定し、適用すると判定された場合、端末装置Ｃ２に、送信されたデータパケットに対するｔｍｐＡＣＫを返送し、データ配信管理装置１０は、通常のゲートウェイと同様に、データ配信管理装置２０から送られたデータパケットを端末装置Ｃ１に転送するルーティング処理のみを行い、ｔｍｐＡＣＫの返送処理は行わない。これによって、端末装置Ｃ１，Ｃ２間の双方向通信が実現される。なお、以下の説明では、端末装置Ｃ１が送信側端末とし、端末装置Ｃ２が受信側端末とし、データ配信管理装置１０の動作処理について説明するが、端末装置Ｃ２が送信側端末とし、端末装置Ｃ１が受信側端末した場合におけるデータ配信管理装置２０の動作処理は、データ配信管理装置１０と同じである。
【００３７】
ここで、図２〜図８を参照して、データ配信管理装置１０のデータ配信管理処理について説明する。まず、データ配信管理装置１０の通信部１７，１１は、データパケットを受信すると、この受信したデータパケットを受信バッファ７に一時保存し、ＳＧ配信管理部１６は、図２に示す配信処理を行う。
【００３８】
図２において、まず、ｔｍｐＡＣＫ使用判定部１２が、受信したデータパケットのチェックを行い、このチェック結果に応じてデータ配信管理装置１０がもつ受信データパケットに対するｔｍｐＡＣＫ利用可能フラグの「ＯＮ」、「ＯＦＦ」を決定し、必要に応じてｔｍｐＡＣＫ利用可能フラグの「ＯＮ」、「ＯＦＦ」も含め、受信データパケットの情報を配信管理テーブル１に登録する（ステップＳ１１）。
【００３９】
その後、ｔｍｐＡＣＫ制御フラグをもとにｔｍｐＡＣＫの利用制御を行うか否かを判断する（ステップＳ１２）。ｔｍｐＡＣＫの利用制御を行わない場合（ステップＳ１２，ＮＯ）には、そのまま本処理を終了し、ｔｍｐＡＣＫの利用制御を行う場合（ステップＳ１２，ＹＥＳ）には、ｔｍｐＡＣＫ利用制御処理を実行して（ステップＳ１３）、本処理を終了する。
【００４０】
図３は、図２に示したステップＳ１１におけるパケットのチェック処理手順を示すフローチャートである。図３において、まず、データ配信管理装置１０は、受信したデータパケットのＩＰアドレスが正しいＩＰアドレスであり、かつ受信したデータパケットの送信先が、遅延の大きな回線を介した転送であるか否かを経路管理テーブル１ａを用いて判断する（ステップＳ２１）。このステップＳ２１では、ネットワーク層のヘッダがＩＰヘッダであるか否かを確認し、その後、ルーティング機能によって決定される経路上に伝送遅延回線が存在するか否かを配信管理テーブル１を用いて判断する。プロトコルがＩＰを用いていない場合、正しいフォーマットのアドレスでない場合、さらに宛先までの経路上に伝送遅延回線が存在しない場合（ステップＳ２１，ＮＯ）には、ｔｍｐＡＣＫ利用可能フラグを「ＯＦＦ」に設定し（ステップＳ２２）、受信したデータパケットを宛先に転送し（ステップＳ２３）、ステップＳ１１にリターンする。なお、このｔｍｐＡＣＫ利用可能フラグは、上述した別個のバッファあるいは同一のバッファに設けられる図示しない管理テーブルを用いる場合、この管理テーブル内の情報として保持するようにしてもよい。
【００４１】
ここで、図４は、経路管理テーブル１ａの内容を示す図である。図４において、この経路管理テーブル１ａには、宛先ＩＰ毎に、宛先までの経路が管理され、各経路毎に遅延が有無が記述されている。たとえば、宛先ＩＰが「１０．７４．３．２００」の場合、経路「１」〜「４」の４つの経路がリストアップされているが、経路「１」の経路は、遅延がある経路となる。したがって、経路「１」が選択された場合に、遅延依存の回線に対する転送であると判断される。
【００４２】
その後、受信したデータパケットのＩＰアドレスが正しく、かつ宛先までの経路に伝送遅延が存在する場合（ステップＳ２１，ＹＥＳ）、ｔｍｐＡＣＫ使用判定部１２は、プロトコル管理テーブル５を用いて、ＩＰヘッダのプロトコルが遅延依存であるか否かを判断する（ステップＳ２４）。ＩＰヘッダのプロトコルが遅延依存である場合（ステップＳ２４，ＹＥＳ）には、さらにＴＣＰヘッダの送信ポートが遅延依存であるか否かを判断する（ステップＳ２５）。ＩＰヘッダのプロトコルが遅延依存でない場合（ステップＳ２４，ＮＯ）およびＴＣＰヘッダの送信ポートが遅延依存でない場合（ステップＳ２５，ＮＯ）には、ｔｍｐＡＣＫ利用可能フラグを「ＯＦＦ」に設定し（ステップＳ２２）、さらに受信したデータパケットを宛先に転送し（ステップＳ２３）、ステップＳ１１にリターンする。
【００４３】
ここで、図５は、ｔｍｐＡＣＫ使用判定部１２が用いるプロトコル管理テーブル５内の判定テーブルの一例を示す図である。図５において、参照ヘッダの項目Ｄ１は、判定対象のデータパケットの判定に用いるヘッダ部を示している。また、プロトコル名の項目Ｄ２は、参照ヘッダの項目Ｄ１で指定したヘッダ部にあるデータのプロトコルの種別項目を示している。さらに、スプーフィング使用可否の項目Ｄ３は、ｔｍｐＡＣＫの返送処理を用いるべきプロトコルであるか否かを示す情報を表している。この判定テーブルをもとにしたステップＳ２４，Ｓ２５の具体的な判断処理について説明すると、まず、ステップＳ２４において、ｔｍｐＡＣＫ使用判定部１２は、受信したデータパケットのＩＰヘッダのプロトコルを示すバイト列を参照し、ＴＣＰのデータを受信したと判定された場合、ステップＳ２５において、ＴＣＰヘッダ部の送信元ポート番号を参照し、ＢＧＰでないと判定された場合に、ｔｍｐＡＣＫの返送処理を利用できると判断できる。一方、ＢＧＰのデータを受信した場合は、ｔｍｐＡＣＫの返送処理を利用できないと判断できる。
【００４４】
また、ステップＳ２４において、ＩＰヘッダのプロトコル部にある上位プロトコルがデータ配信管理装置１０において遅延依存のプロトコルではないとされた場合（ステップＳ２４，ＮＯ）、上述したようにｔｍｐＡＣＫ利用可能フラグを「ＯＦＦ」にし（ステップＳ２２）、受信したデータパケットを宛先に転送し（ステップＳ２３）、ステップＳ１１にリターンする。一方、ステップＳ２４において、上位プロトコルが遅延依存のプロトコルであると判断され、ステップＳ２５において、ＴＣＰヘッダの送信元ポート番号をもとに、遅延依存のプロトコルではないとされた場合も、上述したようにｔｍｐＡＣＫ利用可能フラグを「ＯＦＦ」にし（ステップＳ２２）、受信したデータパケットを宛先に転送し（ステップＳ２３）、ステップＳ１１にリターンする。
【００４５】
さて、ステップＳ２４，Ｓ２５において、遅延依存のプロトコルであると判断された場合には、受信したデータパケットのヘッダ部のコードビットの値を参照し、通信開始時のデータパケットであるか否かを判断する（ステップＳ２６）。図示しない開始時パケットバッファとして専用のバッファを設ける。あるいは、受信バッファ７および送信バッファ６などのバッファを用いて、図示しない開始時パケットバッファとしてもよい。なお、図示しない開始時パケットバッファに保存するデータパケットを、送信装置毎、受信装置毎、通信する送信装置および受信装置の組み合わせ毎、通信する装置および通信ポートが同一のものを一つの通信として定義した場合における通信毎、あるいは通信の種類毎にタグを付けて管理するようにしてもよい。
【００４６】
通信開始時のデータパケットでない場合（ステップＳ２６，ＮＯ）には、受信したデータパケットが、配信管理テーブル１に既に登録済の通信であるか否かの判断を行う（ステップＳ２７）。このステップＳ２７では、ＩＰヘッダ中の送信元ＩＰとＴＣＰヘッダ中の送信元ポートとの組み合わせおよび宛先ＩＰと宛先ポートとの組み合わせが全て同一の通信を同一の管理単位とし、登録済の通信であると判断する。
【００４７】
ここで、図６は、配信管理テーブルの一例を示す図である。図６において、項目Ｄ１１〜Ｄ１６は、管理単位が同じ通信に関する情報を表す項目であり、項目Ｄ１７〜Ｄ１９は、管理単位が同じ通信においてデータ配信管理装置１０が受信したデータパケットに関する情報を表す項目である。各項目Ｄ１１〜Ｄ１９は、データ配信管理装置１０が受信したデータパケットから取得された情報である。項目Ｄ１１は、管理する通信の送信元ＩＰアドレスを表し、項目Ｄ１２は、宛先ＩＰアドレスを表し、項目Ｄ１３は、送信元ポート番号を表し、項目Ｄ１４は、宛先ポート番号を表し、項目Ｄ１５は、仮ＡＣＫ停止フラグを示し、項目Ｄ１６は、送信元および宛先におけるそれぞれの最新の送信ウィンドウサイズおよび受信ウィンドウサイズを表している。また、項目Ｄ１７は、この通信においてデータ配信管理装置１０が受信したデータセグメントのシーケンス番号を表し、項目Ｄ１８は、ｔｍｐＡＣＫの送信に関する情報を表している。この項目Ｄ１８の情報は、送信元に対して一定の条件が整った時などの条件付の場合を含め、送信可能なデータパケットであるか否かの情報およびｔｍｐＡＣＫを送信したか否かの情報などを値として用いるものである。また、項目Ｄ１９は、宛先からの送達確認応答（ＲＲＡＣＫ）に対する情報を表すものであり、図６では、対応するデータパケットがＲＲＡＣＫを受信済であることを表す「ＡＣＫ受信済」およびＲＲＡＣＫの到達を待っている状態であることを表す「ＡＣＫ待ち」の２つの値をもつ。
【００４８】
たとえば、図６において、行ＤＤ１には、送信元の端末装置「10.74.3.177」の送信ポート「FTP.DATA」から、宛先の端末装置「10.74.3.200」の宛先ポート「1301」に対する通信において、仮ＡＣＫ停止フラグが「ＯＦＦ」であり、送信元の送信ウィンドウサイズおよび受信ウィンドウサイズ、および宛先の送信ウィンドウサイズおよび受信ウィンドウサイズは全て16Kバイトであり、シーケンス番号「398」を持つデータパケットは、ｔｍｐＡＣＫの送信が「不可」、すなわち、いかなる条件になった場合でも、ｔｍｐＡＣＫの送信を行わないデータパケットであり、現時点で宛先からの送達確認応答を待っている状態であることを表すものである。
【００４９】
ＳＧ配信管理部１６は、この配信管理テーブル１の上述した項目および必要に応じて追加する項目を用いて、データパケットのｔｍｐＡＣＫの管理、受信確認、および受信結果に応じた再送の制御、送信元へのｔｍｐＡＣＫおよび宛先からの送達確認応答であるＲＲＡＣＫの送信速度の制御、宛先への転送速度の制御、データ配信管理装置１０の送信バッファ６および受信バッファ７の管理を行うことができる。
【００５０】
データ配信管理装置１０は、この配信管理テーブル１を用いて、受信したデータパケットのＩＰヘッダにある送信元ＩＰアドレスおよび宛先ＩＰアドレス、およびＴＣＰヘッダにある送信元ポート番号および宛先ポート番号を参照し、ＩＰヘッダ中の送信元ＩＰとＴＣＰヘッダ中の送信元ポートとの組み合わせ、および宛先ＩＰと宛先ポートとの組み合わせで表される通信が、配信管理テーブル１内にあるか否かの判断を行う。この判断の結果、配信管理テーブル１に登録されていない通信であった場合（ステップＳ２７，ＮＯ）、ステップＳ２２に移行することになる。
【００５１】
また、配信管理テーブル１に登録されている通信であると判断された場合（ステップＳ２７，ＹＥＳ）、ステップＳ３１に移行し、受信したデータパケットが、宛先の受信ウィンドウ内のデータパケットであるか否かを判断し、宛先の受信ウィンドウ内のデータパケットであった場合（ステップＳ３１，ＹＥＳ）、ステップＳ３２に移行し、宛先の受信ウィンドウ内のデータパケットでなかった場合（ステップＳ３１，ＮＯ）、ｔｍｐＡＣＫ利用可能フラグを「ＯＦＦ」にし、配信管理テーブル１に、データパケットに関する情報を登録し、ｔｍｐＡＣＫ利用可能フラグを「ＯＦＦ」に設定し（ステップＳ３９）、受信したデータパケットを宛先に転送し（ステップＳ２３）、ステップＳ１１にリターンする。
【００５２】
一方、ステップＳ３２において、通信終了のデータパケットでないと判断された場合、ステップＳ３４に移行する。ステップＳ３４において、配信管理テーブル１を参照し、送信元の「送信Ｗｉｎｄｏｗサイズ」が規定のＷｉｎｄｏｗサイズ、たとえば「２」以上に達しているか否か、および宛先の「受信Ｗｉｎｄｏｗサイズ」が規定のＷｉｎｄｏｗサイズ、たとえば「２」以上に達しているか否かを判断し、双方ともに規定のＷｉｎｄｏｗサイズに達していると判断した場合（ステップＳ３４，ＹＥＳ）、データ配信管理装置１０のｔｍｐＡＣＫ利用可能フラグを「ＯＦＦ」に設定し（ステップＳ３９）、受信したデータパケットを宛先に転送し（ステップＳ２３）、ステップＳ１１にリターンする。また、ステップＳ３２において、通信終了のデータパケットであると判断された場合（ステップＳ３２，ＹＥＳ）には、ステップＳ４０に移行する。ステップＳ４０では、図６に示した配信管理テーブルのｔｍｐＡＣＫ送信に関する項目Ｄ１８に、「不可」かつ「ＦＩＮフラグ受信済み」を入れ、ステップＳ２３に移行する。
【００５３】
一方、ステップＳ３４において、Ｗｉｎｄｏｗサイズが十分でないと判断された場合、受信したデータパケットが端末装置Ｃ２からの送達確認応答であるか否かを判断する（ステップＳ３５）。受信したデータパケットが端末装置Ｃ２からの送達確認応答でないと判断された場合（ステップＳ３５，ＮＯ）、配信管理テーブル１に、情報を登録し、ｔｍｐＡＣＫ利用可能フラグを「ＯＮ」に設定し（ステップＳ３７）、受信したデータパケットを宛先に転送し（ステップＳ２３）、ステップＳ１１にリターンする。なお、ｔｍｐＡＣＫ利用可能フラグを「ＯＮ」にしたデータパケットは、送信バッファ６に保存する。ステップＳ３７の処理を行う際、実装によっては、最新のデータパケットの到着時点における情報として、配信管理テーブル１の個々のデータパケットに関する情報のエントリ毎にｔｍｐＡＣＫの利用が可能か否かの情報を設定する。これによって、たとえばスロースタート時にはｔｍｐＡＣＫ利用制御を行わない、などのウィンドウサイズの状態に応じた細かな制御を行うことができる。
【００５４】
受信したデータパケットが端末装置Ｃ２からの送達確認応答であると判断された場合（ステップＳ３５，ＹＥＳ）、ｔｍｐＡＣＫバッファ４に、受信したデータパケットを保存し、データ配信管理装置１０のＳＧ配信管理部１６に対して、端末装置Ｃ２から送達確認応答を受信したことを通知するイベントを発生させ、ｔｍｐＡＣＫ利用可能フラグを「ＯＮ」に設定し（ステップＳ３６）、ステップＳ１１にリターンする。なお、このステップＳ３６の処理は、実装によって、たとえば、ＩＰヘッダおよびＩＰデータ部のみなどの必要な部分のみを保存することも可能である。また、シーケンス番号などによって、受信したデータパケットが既にｔｍｐＡＣＫ作成用のデータパケットとして登録されていたものより、後のデータパケットであるか否かを判断し、最新すなわち最も後のデータパケットをｔｍｐＡＣＫ作成用のデータパケットとして登録するようにしてもよい。また、ステップＳ３５において、受信したデータパケットが端末装置Ｃ２からの送達確認応答ではなかった場合（ステップＳ３５，ＮＯ）も、ｔｍｐＡＣＫ作成用として、ｔｍｐＡＣＫバッファ４に、受信したデータパケットを保存し、ｔｍｐＡＣＫ作成時にそのデータを利用することも可能である。
【００５５】
一方、ステップＳ２６において、通信開始のデータパケットであると判断された場合、現在判断を行っているデータパケットを含めて、通信開始のデータパケットが通信の手順通りに正しく送受信されているか否かの判断を行う（ステップＳ２９）。一連の作業によって、通信開始のデータパケットは正しい順序で到達されたことを確認されたもののみ、図示しない開始時パケットバッファに保存される。従って、このステップＳ２９の判断は、受信したデータパケットが、最初の通信開始時用のデータパケットであるか、あるいは同一通信における最後に受信された通信開始時用のデータパケットの次に受信されるべきデータパケットであるのかのいずれかをチェックすればよいことになる。
【００５６】
その後、データ配信管理装置１０が正しい順序で通信開始のデータパケットを受信していると判断された場合（ステップＳ２９，ＹＥＳ）、このデータパケットの情報を配信管理テーブル１に追加登録する（ステップＳ３０）。その後、受信したデータパケットが端末装置Ｃ２からの送達確認応答であるか否かを判断し（ステップＳ４１）、端末装置Ｃ２からの送達確認応答であると判断された場合（ステップＳ４１，ＹＥＳ）、上述したステップＳ３６の処理を行った後、ステップＳ１１にリターンする。一方、端末装置Ｃ２からの送達確認応答でないと判断された場合（ステップＳ４１，ＮＯ）、受信したデータパケットを宛先に転送し（ステップＳ２３）、ステップＳ１１にリターンする。
【００５７】
一方、ステップＳ２９において、データ配信管理装置１０が正しい順序で通信開始のデータパケットを受信していないと判断された場合（ステップＳ２９，ＮＯ）およびステップＳ２７において配信管理テーブル１に登録されている通信でないと判断された場合（ステップＳ２７，ＮＯ）、データ配信管理装置１０のｔｍｐＡＣＫ利用可能フラグを「ＯＦＦ」にし（ステップＳ２２）、受信したデータパケットを宛先に転送し（ステップＳ２３）、ステップＳ１１にリターンする。
【００５８】
つぎに、図７に示すフローチャートを参照して、図２に示したステップＳ１３によるｔｍｐＡＣＫ利用制御処理の詳細手順について説明する。図７は、ウィンドウサイズに応じたｔｍｐＡＣＫの送信タイミングの調整処理手順を示すフローチャートである。ここで、この調整処理は、データセグメントが受信され、ｔｍｐＡＣＫ利用制御フラグを参照し、ｔｍｐＡＣＫ利用制御実施イベント、あるいは遅延仮ＡＣＫに関わるタイマやカウンタから出力されるイベントによって開始される。遅延仮ＡＣＫは、ＴＣＰにおける遅延ＡＣＫの手法などと同様に、一定時間あるいは一定パケット数の受信を待ってから仮ＡＣＫ（ｔｍｐＡＣＫ）を作成および送信することで、データ配信管理装置１０の処理およびデータ配信管理装置１０との間のフローの削減を促すことを目的とする。
【００５９】
したがって、遅延仮ＡＣＫに関わるタイマやカウンタが出力するイベントとは、たとえば、一定時間待ってから遅延仮ＡＣＫの作成および送信を行う方法による遅延仮ＡＣＫを用いる実装の場合、ｔｍｐＡＣＫ使用判定部１２が、遅延仮ＡＣＫを発生させるタイミングをはかるタイマ、タイムアウト時間変数あるいは定数およびそれらによってオン、オフの値が設定される遅延仮ＡＣＫ時間経過フラグを持ち、一定時間毎にｔｍｐＡＣＫ作成部１３に対して、遅延仮ＡＣＫ用の待ち時間がきたことを知らせるために発生するものである。
【００６０】
図７において、まず図３に示した一連の処理によって設定されたＦＩＮ受信済フラグの値を参照し、通信終了のデータパケットが受信済であるか否かの判断を行う（ステップＳ５１）。ＦＩＮパケット受信済と判断された場合（ステップＳ５１，ＹＥＳ）、そのままステップＳ１３にリターンする。一方、ＦＩＮパケット受信済と判断されなかった場合（ステップＳ５１，ＮＯ）、ｔｍｐＡＣＫバッファ４に保存してあるデータパケットがＳＹＮデータパケットとＡＣＫデータパケット（（ＳＹＮ＋ＡＣＫ）パケット）であるか否かを判断する（ステップＳ５２）。（ＳＹＮ＋ＡＣＫ）パケットであった場合（ステップＳ５２，ＹＥＳ）、未転送の（ＳＹＮ＋ＡＣＫ）パケットを送信元、すなわち端末装置Ｃ１に転送し（ステップＳ５３）、ステップＳ１３にリターンする。一方、ステップＳ５２において、ｔｍｐＡＣＫバッファ４に保存してあるデータパケットが（ＳＹＮ＋ＡＣＫ）パケットでないと判断された場合（ステップＳ５２，ＮＯ）、配信管理テーブル１および後述する図６に示す仮ＡＣＫ作成停止フラグの「ＯＮ」、「ＯＦＦ」を参照し、ｔｍｐＡＣＫの送信に必要なデータセグメントを受信しているか否かおよび仮ＡＣＫ送信可能か否かの判断を行う（ステップＳ５４）。ｔｍｐＡＣＫの送信に必要なデータセグメントを受信したか否かの判断は、たとえばｔｍｐＡＣＫを作成しようとしているセグメントＸから、後のシーケンス番号のセグメントが１つ以上受信した時点で、セグメントＸに対するｔｍｐＡＣＫの作成を可能とするという実装とすることができる。
【００６１】
ステップＳ５４において、ｔｍｐＡＣＫの送信に必要なデータセグメントを受信していないと判断した場合（ステップＳ５４，ＮＯ）、ｔｍｐＡＣＫバッファ４にある未転送のＡＣＫセグメントが存在する場合、このＡＣＫセグメントを端末装置Ｃ１に転送し（ステップＳ５３）、ステップＳ１３にリターンする。
【００６２】
一方、ステップＳ５４において、ｔｍｐＡＣＫの送信に必要なデータセグメントを受信したと判断した場合（ステップＳ５４，ＹＥＳ）、ｔｍｐＡＣＫの作成の対象となる端末装置Ｃ１からのデータセグメントを決定する（ステップＳ５５）。このステップＳ５５の処理では、配信管理テーブル１を用い、端末装置Ｃ１のウィンドウ（Ｗｉｎｄｏｗ）サイズ、ｔｍｐＡＣＫの送信状況および端末装置Ｃ１，Ｃ２間のＴＣＰプロトコルのＳＡＣＫオプションなどを参照して処理を行う。
【００６３】
たとえば、ＳＡＣＫオプションなしの通信の場合、配信管理テーブル１のエントリのうち、ＡＣＫ受信待ちであり、かつ、ｔｍｐＡＣＫを送信しておらず、かつ自シーケンス番号に比してシーケンス番号が小さいセグメントが全てデータ配信管理装置１０において受信されているセグメントの中で、シーケンス番号が２番目に大きいものを、ｔｍｐＡＣＫ作成の対象として決定する。
【００６４】
その後、ｔｍｐＡＣＫ作成バッファに保存してあるセグメントの確認応答番号を、ステップＳ５５によって決定したｔｍｐＡＣＫ作成対象セグメントのシーケンス番号に「１」を加えた番号に書き換えたセグメントを、ｔｍｐＡＣＫとして作成する（ステップＳ５６）。ＳＡＣＫオプション付きのＴＣＰの場合、ステップＳ５５において、ＳＡＣＫオプションを考慮したｔｍｐＡＣＫ作成対象を決定し、ステップＳ５６において、ＳＡＣＫオプションも加えた送達確認応答を作成する実装を行うことも可能である。
【００６５】
その後、送信元である端末装置Ｃ１に対してｔｍｐＡＣＫを送信する（ステップＳ５７）。ここで、ウィンドウサイズに応じ、送信タイミングを加減する。たとえば、次式（１）に示す待ち時間ＷtimeNEW待った後に、ｔｍｐＡＣＫの送信を行うようにする。すなわち、
0003893247.tif 000002
である。ここで、「ＷtimeNEW」は、現在の待ち時間であり、「ＬＢＯＵＮＤ」は、送信待ちの上限値であり、たとえば端末装置Ｃ１における再送タイムアウト値などに設定される。また、「ＷtimeOLD」は、前回算出した「ＷtimeNEW」であり、初期値は、「ＬＢＯＵＮＤ」である。「WindowSIZENEW」は、現在の端末装置Ｃ１のウィンドウサイズであり、「WindowSIZEOLD」は、前回の端末装置Ｃ１のウィンドウサイズである。「ＬＢＯＵＮＤ」は、送信待ちの下限値、たとえば「０」であり、「α」は、「ＷtimeNEW」を算出するための所定数を表す。
【００６６】
ｔｍｐＡＣＫを送信元に転送した後、送信したｔｍｐＡＣＫに対応する全ての配信管理テーブル１上にエントリしてあるセグメントの情報をｔｍｐＡＣＫ送信済みに設定変更し（ステップＳ５８）、ステップＳ１３にリターンする。
【００６７】
つぎに、図８に示すフローチャートを参照して、データ配信管理装置１０のＳＧ配信管理部１６による受信確認処理およびその結果による再送制御処理の手順について説明する。この受信確認処理および再送制御処理は、図２に示したパケットのチェック処理およびｔｍｐＡＣＫ利用制御処理と並列して処理される。
【００６８】
図８において、まず端末装置Ｃ２からの送達確認応答の到着を示すイベントを受け取ったか否かを判断する（ステップＳ６１）。このイベントは、ステップＳ１１におけるパケットのチェックの処理において発生されるイベントである。送達確認応答が到着していた場合（ステップＳ６１，ＹＥＳ）、端末装置Ｃ２からの開始通知であるか否かを判断し（ステップＳ６９）、開始通知であった場合（ステップＳ６９，ＹＥＳ）、本処理を終了する。一方、端末装置Ｃ２からの開始通知でないと判断された場合（ステップＳ６９，ＮＯ）、配信管理テーブル１に、受信した送達確認応答が示すデータセグメントに対する結果を記入する（ステップＳ７０）。たとえば、ＳＡＣＫオプションなしの通信の場合、配信管理テーブル１のエントリのうち、ＡＣＫ受信待ちであり、かつ、受信した送達確認応答が示すデータセグメントに比してシーケンス番号が小さいデータセグメントの全てをＡＣＫ受信済にする。一方、ＳＡＣＫオプションありの通信の場合、配信管理テーブル１のエントリのうち、ＡＣＫ受信待ちであり、かつ、受信した送達確認応答が示すデータセグメントに比してシーケンス番号が小さいデータセグメントであり、かつ、ＳＡＣＫオプションにないデータセグメントの全てをＡＣＫ受信済とする。
【００６９】
ステップＳ７０の処理後、配信管理テーブル１のエントリのうち、ＡＣＫ受信済のセグメントを送信バッファ６から削除する（ステップＳ７１）。ここで、ＡＣＫ受信セグメントの削除処理は、削除に関するタイマを持ち、一定時間毎にまとめて削除するようにしてもよい。
【００７０】
一方、ステップＳ６１において、端末装置Ｃ２からの送達確認応答受信のイベントを受けていないと判断された場合、さらに再送タイムアウトが発生したか否かを判断する（ステップＳ６２）。再送タイムアウトが発生していなかった場合（ステップＳ６２，ＮＯ）、そのまま本処理を終了する。一方、再送タイムアウトが発生したと判断された場合（ステップＳ６２，ＹＥＳ）、ｔｍｐＡＣＫの送信を停止するか否かを判断する（ステップＳ６３）。
【００７１】
ここで、データ配信管理装置１０は、受信バッファ７にあわせた擬似ウィンドウ（ＴＣＰ通信におけるウィンドウを模倣したもの）を持ち、この擬似ウィンドウサイズから、受信バッファ７に残っている分量を減算した量、すなわち擬似ウィンドウサイズから、送信元から受信したセグメントの総量を減算し、さらに宛先からの送達確認応答がきているセグメントの総量を加算した量が、データ配信管理装置１０において把握している送信元のウィンドウサイズよりもさらに１セグメント分のサイズを越える場合、ｔｍｐＡＣＫの停止をしないと判断し（ステップＳ６３，ＮＯ）、図６に示した仮ＡＣＫ作成停止フラグを「ＯＦＦ」に設定し、ｔｍｐＡＣＫの送信を開始する処理を行い（ステップＳ６４）、ステップＳ６６に移行する。
【００７２】
一方、その逆である場合、ｔｍｐＡＣＫの停止をすると判断し（ステップＳ６３，ＹＥＳ）、図６に示した仮ＡＣＫ作成停止フラグを「ＯＮ」に設定し、ｔｍｐＡＣＫの送信を停止する処理を行い（ステップＳ６５）、ステップＳ６６に移行する。ここで、上述したｔｍｐＡＣＫを停止するか否かの判断を具体的に説明する。擬似ウィンドウサイズを「Ｘ」バイト、この時点におけるデータ配信管理装置１０が把握している送信元すなわち端末装置Ｃ１のウィンドウサイズを「ｍ」バイト、現在受信バッファ７にあるセグメントの総量を「ｙ」バイト、受信する１セグメントの大きさを「ｋ」バイトとすると、次式（２）が成立したときに、仮ＡＣＫの停止をする判断を行う。すなわち、
Ｘ−ｙ＜ｍ＋ｋ                                            …  （２）
である。
【００７３】
その後、配信管理テーブル１にあるタイムアウトが発生したデータセグメントのエントリの再送回数をインクリメントし、再送フラグを「ＯＮ」にし（ステップＳ６６）、配信終了か否かの判断を行う（ステップＳ６７）。通常のＴＣＰ通信における配信終了のデータパケットの交換を検知した場合、あるいは再送のタイムアウトを繰り返し、データ配信管理装置１０が再送のリトライアウトをすることによって配信を終了する場合に、配信終了と判断され（ステップＳ６７，ＹＥＳ）、配信終了処理を行い（ステップＳ６８）、本処理を終了する。なお、再送のタイムアウト値、およびリトライアウトの回数は、端末装置Ｃ１および端末装置Ｃ２における再送のタイムアウト値およびリトライアウト回数よりも十分に長く設定される必要がある。
【００７４】
ステップＳ６８の処理は、配信終了状態によって異なる処理を行う。通常のＴＣＰ通信における配信終了のデータパケットの交換を検知した場合、ｔｍｐＡＣＫバッファ４、送信バッファ６、受信バッファ７の全てにおいて、終了する通信におけるデータセグメントを全て削除し、配信管理テーブル１のエントリも削除する。なお、配信管理テーブル１のエントリは、データの蓄積を兼ね、保存しておくことも可能である。また、エントリに寿命を設け、あるいはエントリが溢れない限り残しておくようにしてもよい。
【００７５】
一方、ステップＳ６７において、配信終了でないと判断された場合、ステップＳ７２〜Ｓ７４の再送処理を行う。すなわち、ステップＳ７２では、配信管理テーブル１の再送フラグが「ＯＮ」になっているものを、送信バッファ６のデータセグメントを再送し、配信管理テーブル１の再送フラグを「ＯＦＦ」にする。このステップＳ７２の処理後、再送タイマをリセットし（ステップＳ７３）、データ配信管理装置１０の再送回数カウンタのインクリメントを行い（ステップＳ７４）、本処理を終了する。
【００７６】
実施の形態２．
つぎに、この発明の実施の形態２について説明する。この実施の形態２では、図６に示したｔｍｐＡＣＫ利用制御処理を、ウィンドウサイズに応じた遅延を付加してｔｍｐＡＣＫの作成処理および送信処理を行うようにしている。
【００７７】
図９は、この発明の実施の形態２であるデータ配信管理装置のｔｍｐＡＣＫ利用処理手順を示すフローチャートである。図９において、図２に示した一連の処理によって設定されたＦＩＮ受信済フラグの値を参照し、通信終了のデータパケットが受信済であるか否かの判断を行う（ステップＳ８１）。ＦＩＮパケット受信済と判断された場合（ステップＳ８１，ＹＥＳ）、そのままステップＳ１３にリターンする。
【００７８】
一方、ＦＩＮパケット受信済と判断されなかった場合（ステップＳ８１，ＮＯ）、仮ＡＣＫ用の遅延時間が経過したことを示すフラグが立っているか否かを判断する（ステップＳ８２）。仮ＡＣＫ用の遅延時間が経過していた場合（ステップＳ８２，ＹＥＳ）、遅延仮ＡＣＫタイマおよび関連フラグをリセットする（ステップＳ８３）。
【００７９】
このとき、たとえば、図１０に示す対応テーブルを用い、ウィンドウサイズに応じた遅延仮ＡＣＫタイマ値を更新設定する。たとえば、図１０において、ウィンドウサイズが「５」ｋbyte以上である場合には、遅延タイマを「５」msecに更新設定する。その後、ステップＳ８４に移行する。
【００８０】
ステップＳ８２において、仮ＡＣＫ用の遅延時間が経過していないと判断された場合、データ配信管理装置１０において、端末装置Ｃ１に対する未転送データがあるか否かを判断し（ステップＳ８６）、未転送データがなかった場合（ステップＳ８６，ＮＯ）は、ステップＳ１３にリターンし、未転送データがあった場合（ステップＳ８６，ＹＥＳ）、ステップＳ８７に移行する。
【００８１】
ステップＳ８７において、ｔｍｐＡＣＫバッファ４に保存してあるデータパケットが（ＳＹＮ＋ＡＣＫ）パケットであるか否かを判断し、（ＳＹＮ＋ＡＣＫ）パケットであった場合、未転送の（ＳＹＮ＋ＡＣＫ）パケットを宛先に転送し（ステップＳ８５）、ステップＳ１３にリターンする。
【００８２】
一方、ステップＳ８７において、ｔｍｐＡＣＫバッファ４に保存してあるデータパケットが（ＳＹＮ＋ＡＣＫ）パケットでないと判断された場合、ｔｍｐＡＣＫの送信に必要なデータセグメントを受信しているか否かの判断を行う（ステップＳ８８）。ステップＳ８４およびステップ８８の処理では、配信管理テーブル１および仮ＡＣＫ作成フラグのオン、オフを参照し、ｔｍｐＡＣＫの送信に必要なセグメントを受信したか否かおよびｔｍｐＡＣＫの送信が可能か否かを判断する。すなわち、遅延ありｔｍｐＡＣＫを使用するか否かを判断する。ｔｍｐＡＣＫ送信に必要なセグメントを受信したか否かの判断は、たとえば、ｔｍｐＡＣＫを作成しようとしているセグメントＸよりも、後のシーケンス番号のセグメントを１つ以上受信した時点で、セグメントＸに対するｔｍｐＡＣＫの作成が可能とする。
【００８３】
ステップＳ８４において、遅延ありｔｍｐＡＣＫを使用しないと判断した場合、ｔｍｐＡＣＫバッファ４にある未転送のＡＣＫパケットを端末装置Ｃ１に転送し（ステップＳ８５）、ステップＳ１３にリターンする。
【００８４】
一方、ステップＳ８４，Ｓ８８において、遅延ありｔｍｐＡＣＫを使用すると判断した場合、ｔｍｐＡＣＫの作成の対象となる端末装置Ｃ１からのデータセグメントを決定する（ステップＳ８９）。このステップ８９の処理では、配信管理テーブル１を用い、データ配信管理装置１０における受信状況、送信元のウィンドウサイズ、ｔｍｐＡＣＫの送信状況、および端末装置Ｃ１と端末装置Ｃ２との間のＴＣＰプロトコルのＳＡＣＫオプションなどを参照して処理を行う。
【００８５】
たとえば、ＳＡＣＫオプションなしの通信の場合、配信管理テーブル１のエントリのうち、ＡＣＫ受信待ちであり、かつ、ｔｍｐＡＣＫを送信しておらず、かつ、自シーケンス番号に比してシーケンス番号が小さいセグメントが全てのデータ配信管理装置１０において受信されているセグメントの中で、シーケンス番号が、２番目に大きいものを、ｔｍｐＡＣＫ作成対象として決定する。
【００８６】
また、たとえば、ＳＡＣＫオプションありの通信の場合、ｔｍｐＡＣＫ送信可能であり、かつ、ｔｍｐＡＣＫ未送信であり、かつ、ＡＣＫ受信待ちであり、かつ、自シーケンス番号が小さいセグメントのうち、連続したシーケンス番号を持つ未受信のセグメント群が４つ以下であるデータ配信管理装置１０において受信しているセグメントのなかで、シーケンス番号が最も後ろのものよりも一つ前のセグメントをｔｍｐＡＣＫの作成および送信の対象として決定する。
【００８７】
ステップＳ８９の処理後、ｔｍｐＡＣＫバッファ４に保存してあるデータセグメントの到達確認応答番号を、ステップＳ８９において決定したｔｍｐＡＣＫの作成対象のデータセグメントのシーケンス番号に「１」を加えた番号に書き換えたデータセグメントを、ｔｍｐＡＣＫとして作成する。ＳＡＣＫオプション付のＴＣＰの場合、ステップＳ８９においてＳＡＣＫオプションを考慮したｔｍｐＡＣＫを作成する実装も可能である。その後、ステップＳ９０において、ＳＡＣＫオプションも加えた送達確認応答を作成する。
【００８８】
ステップＳ９０の処理後、端末装置Ｃ１にｔｍｐＡＣＫを送信し（ステップＳ９１）、この送信したｔｍｐＡＣＫが対応する全ての配信管理テーブル１上にエントリしてあるデータセグメントの情報をｔｍｐＡＣＫ送信済に変更設定し（ステップＳ９２）、ステップＳ１３にリターンする。
【００８９】
【発明の効果】
以上説明したように、この発明によれば、保持手段が、前記第１の端末装置のウィンドウサイズの情報を保持し、決定手段が、前記保持手段が保持するウィンドウサイズの情報をもとに前記送達確認応答の返送処理を行うか否かを決定し、制御手段が、前記決定手段が前記送達確認応答の返送処理を行うと決定した場合のみに前記送達確認応答の返送処理を行うようにし、送信元に対する送達確認応答の送信タイミングあるいは送信量を調整するようにしているので、一層高速かつ効率的にデータ配信を行うことができるとともに、送信元の状況に見合わない急激なデータ送信速度あるいはデータ量の増加を回避することができるデータ配信管理装置を実現することができるという効果を奏する。
【００９０】
つぎの発明によれば、保持手段が、前記第１の端末装置のウィンドウサイズの情報を保持し、制御手段が、前記保持手段が保持するウィンドウサイズの情報が示すウィンドウサイズに応じて前記第１の端末装置が送信したデータに対する前記送達確認応答の返送タイミングを可変させる制御を行うようにしているので、一層高速かつ効率的にデータ配信を行うことができるデータ配信管理装置を実現することができるという効果を奏する。
【００９１】
つぎの発明によれば、算出手段が、前記第２の端末装置から受信した送達確認応答の受信時点から前記第１の端末装置に送達確認応答を返送する返送時点までの遅延時間に略対応した所定の下限値を初期値とする現在の遅延時間から、前記第１の端末装置における現在のウィンドウサイズから前回のウィンドウサイズを減算した第１の減算値に所定値を乗算した第２の値を減算した第２の減算値と、前記所定の下限値との最大値を算出し、該最大値と所定の上限値との最小値とを算出し、該最小値を前記現在の遅延時間として再設定する処理を繰り返して最新の現在の遅延時間を算出し、前記制御手段が、前記算出手段によって算出された最新の現在の遅延時間に応じて前記第１の端末装置が送信したデータに対する前記送達確認応答の返送タイミングを可変させる制御を行うようにしているので、一層高速かつ効率的にデータ配信を行うことができるデータ配信管理装置を実現することができるという効果を奏する。
【００９２】
つぎの発明によれば、保持手段が、前記第１の端末装置のウィンドウサイズと前記第１の端末装置から受信したデータのセグメント数と前記第２の端末装置からの受信確認応答の有無とを少なくとも保持し、決定手段が、前記保持手段が保持する前記ウィンドウサイズと前記セグメント数と前記受信確認応答の有無との組み合わせによって前記第１の端末装置が送信したデータに対する前記送達確認応答の返送を行うか否かを決定し、制御手段が、前記決定手段が前記送達確認応答の返送を行うと決定した場合に該送達確認応答の返送を行うようにしているので、一層高速かつ効率的にデータ配信を行うことができるデータ配信管理装置を実現することができるという効果を奏する。
【００９３】
つぎの発明によれば、保持手段が、前記第１の端末装置のウィンドウサイズの情報を保持し、制御手段が、前記保持手段が保持するウィンドウサイズの情報が示すウィンドウサイズに応じて前記第１の端末装置が送信したデータに対する前記送達確認応答の作成密度を可変、たとえば送達確認応答を間引く制御を行うようにしているので、一層高速かつ効率的にデータ配信を行うことができるデータ配信管理装置を実現することができるという効果を奏する。
【００９４】
つぎの発明によれば、データバッファが、少なくとも前記第１の端末装置が送信したデータを保持し、管理手段が、少なくとも前記第１の端末装置が送信したデータの登録情報を管理し、削除制御手段が、前記第１の端末装置が送信したデータを転送した前記第２の端末装置から該データに対する送達確認応答を受信した場合、前記データバッファに保持されている該データおよび前記管理手段が管理する該データの登録情報を削除する制御を行うようにしているので、データ配信管理装置にかかる負荷を軽減することができるという効果を奏する。
【００９５】
つぎの発明によれば、計数手段が、前記データバッファ内に保持されたデータのうちの削除対象のデータである送達確認済みのセグメント数を計数し、前記削除制御手段が、前記第１の端末装置が送信したデータを転送した前記第２の端末装置から該データに対する送達確認応答の受信の都度、前記管理手段が管理する該データに登録情報を送達確認済みに設定し、前記計数手段が計数する該送達確認済みに設定されたセグメント数が所定数を越えた場合に、前記データバッファに保持されている該送達確認済みのデータと前記管理手段が管理する該送達確認済みのデータの登録情報を削除するようにしているので、データ配信管理装置にかかる負荷を軽減することができるという効果を奏する。
【００９６】
つぎの発明によれば、第１の計数手段が、前記データバッファ内に保持されたデータのうちの削除対象のデータである送達確認済みのセグメント数を計数し、第２の計数手段が、前記管理手段が管理するデータのうちの削除対象のデータの登録情報を計数し、前記削除制御手段が、前記第１の端末装置が送信したデータを転送した前記第２の端末装置から該データに対する送達確認応答の受信の都度、前記管理手段が管理する該データに関する情報を送達確認済みに設定し、前記第１の計数手段が計数する送達確認済みに設定されたセグメント数が第１の所定数を越えた場合に、前記データバッファに保持されている該送達確認済みのデータを削除し、前記第２の計数手段が計数する送達確認済みのデータの登録情報が第２の所定数を越えた場合に、該送達確認済みのデータの登録情報を削除するようにしているので、データ配信管理装置にかかる負荷を軽減することができるという効果を奏する。
【００９７】
つぎの発明によれば、計時手段が、所定時間を計時する計時手段をさらに備え、前記削除制御手段が、前記第１の端末装置が送信したデータを転送した前記第２の端末装置から該データに対する送達確認応答の受信の都度、前記管理手段が管理する該データに登録情報を送達確認済みに設定し、計時手段が前記所定時間を計時した際に、前記データバッファに保持されている該送達確認済みのデータと前記管理手段が管理する該送達確認済みのデータの登録情報を削除するようにしているので、データ配信管理装置にかかる負荷を軽減することができるという効果を奏する。
【図面の簡単な説明】
【図１】  この発明の実施の形態１であるデータ配信管理装置を含むデータ配信管理システムの構成を示すブロック図である。
【図２】  図１に示したデータ配信管理装置によるデータ配信管理処理手順を示すフローチャートである。
【図３】  図２に示したパケットのチェック処理手順を示す詳細フローチャートである。
【図４】  図１に示した経路管理テーブルの内容の一例を示す図である。
【図５】  図１に示したプロトコル管理テーブルの内容の一例を示す図である。
【図６】  図１に示した配信管理テーブルの内容の一例を示す図である。
【図７】  図２に示したｔｍｐＡＣＫ利用制御処理手順を示す詳細フローチャートである。
【図８】  図１に示したデータ配信管理装置による受信確認処理および再送制御処理の手順を示すフローチャートである。
【図９】  この発明の実施の形態２であるデータ配信管理装置によるｔｍｐＡＣＫ利用制御処理手順を示す詳細フローチャートである。
【図１０】  図９に示したデータ配信管理装置が有するウィンドウサイズと遅延タイマの設定値との対応関係を示す対応テーブルの一例を示す図である。
【図１１】  従来のデータ配信管理装置を含むデータ配信管理システムの構成を示すブロック図である。
【符号の説明】
１  配信管理テーブル、１ａ  経路管理テーブル、２ａ，２ｂ，３  回線、４ｔｍｐＡＣＫバッファ、５  プロトコル管理テーブル、６  送信バッファ、７受信バッファ、１０，２０  データ配信管理装置、１０ａ  ゲートウェイ機能部、１１，１７  通信部、１２  ｔｍｐＡＣＫ使用判定部、１３  ｔｍｐＡＣＫ作成部、１４  ＳＧＴｉｍｅｒカウント部、１５  配信データ記録部、１６  ＳＧ配信管理部、Ｃ１，Ｃ２  端末装置。
【図１】
0003893247.tif 000003
【図２】
0003893247.tif 000004
【図３】
0003893247.tif 000005
【図４】
0003893247.tif 000006
【図５】
0003893247.tif 000007
【図６】
0003893247.tif 000008
【図７】
0003893247.tif 000009
【図８】
0003893247.tif 000010
【図９】
0003893247.tif 000011
【図１０】
0003893247.tif 000012
【図１１】
0003893247.tif 000013