JP2003124984A - データ配信管理装置、データ配信管理システムおよびデータ配信管理方法 - Google Patents
データ配信管理装置、データ配信管理システムおよびデータ配信管理方法Info
- Publication number
- JP2003124984A JP2003124984A JP2001321030A JP2001321030A JP2003124984A JP 2003124984 A JP2003124984 A JP 2003124984A JP 2001321030 A JP2001321030 A JP 2001321030A JP 2001321030 A JP2001321030 A JP 2001321030A JP 2003124984 A JP2003124984 A JP 2003124984A
- Authority
- JP
- Japan
- Prior art keywords
- buffer
- data
- distribution management
- confirmation response
- delivery
- 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.)
- Granted
Links
Abstract
(57)【要約】
【課題】 送受信のバッファおよびＷｉｎｄｏｗサイズ
および回線の輻輳を考慮し、ｔｍｐＡＣＫの送信のタイ
ミングや送信量を調整し、一層速く、一層効率的にデー
タの配信を行うこと。 【解決手段】 少なくとも受信したデータを受信装置Ｃ
２に向けて転送とするとともに、受信装置Ｃ２からの送
達確認応答を受信するまでデータセグメントを保存し、
必要に応じて再送処理を行う機能を有したデータ配信管
理装置１０において、受信したデータセグメントを保存
するバッファ６，７と、送信元のスループット情報をも
とに、バッファ６，７のバッファサイズを可変設定する
バッファ割当部６ａとを備える。
および回線の輻輳を考慮し、ｔｍｐＡＣＫの送信のタイ
ミングや送信量を調整し、一層速く、一層効率的にデー
タの配信を行うこと。 【解決手段】 少なくとも受信したデータを受信装置Ｃ
２に向けて転送とするとともに、受信装置Ｃ２からの送
達確認応答を受信するまでデータセグメントを保存し、
必要に応じて再送処理を行う機能を有したデータ配信管
理装置１０において、受信したデータセグメントを保存
するバッファ６，７と、送信元のスループット情報をも
とに、バッファ６，７のバッファサイズを可変設定する
バッファ割当部６ａとを備える。
Description
【０００１】
【発明の属する技術分野】この発明は、送信したデータ
に対する送達確認応答を必要とする送信装置と該送信装
置の通信相手先である受信装置との間の伝送路上に配置
され、前記送信装置との間の伝送遅延が前記受信装置と
の間の伝送遅延に比して小さく、少なくとも前記送信装
置からのデータを前記受信装置に対して転送する転送処
理と該転送したデータに対する送達確認応答を作成し返
送する返送処理とを行うことができるデータ配信管理装
置に関し、特にデータ配信時における送達確認応答の受
信タイミングに依存した速度性能劣化を改善することが
できるデータ配信管理装置、データ配信管理システムお
よびデータ配信管理方法に関するものである。
に対する送達確認応答を必要とする送信装置と該送信装
置の通信相手先である受信装置との間の伝送路上に配置
され、前記送信装置との間の伝送遅延が前記受信装置と
の間の伝送遅延に比して小さく、少なくとも前記送信装
置からのデータを前記受信装置に対して転送する転送処
理と該転送したデータに対する送達確認応答を作成し返
送する返送処理とを行うことができるデータ配信管理装
置に関し、特にデータ配信時における送達確認応答の受
信タイミングに依存した速度性能劣化を改善することが
できるデータ配信管理装置、データ配信管理システムお
よびデータ配信管理方法に関するものである。
【０００２】
【従来の技術】図１４は、従来のデータ配信管理装置を
用いたデータ配信管理システムの構成を示すブロック図
である（情報処理学会研究報告98-DPS-89-12参照）。図
１４において、このデータ配信管理システムは、送信装
置Ｃ１１と、受信装置Ｃ１２と、この送信装置Ｃ１１お
よび受信装置Ｃ１２にＴＣＰによる通信を行う回線Ｌ１
１，Ｌ１２を介してそれぞれ接続された送信ゲートウェ
イ１００とを有する。回線Ｌ１２は、回線Ｌ１１に比し
て伝送遅延が大きい回線であり、たとえば衛星回線であ
る。
用いたデータ配信管理システムの構成を示すブロック図
である（情報処理学会研究報告98-DPS-89-12参照）。図
１４において、このデータ配信管理システムは、送信装
置Ｃ１１と、受信装置Ｃ１２と、この送信装置Ｃ１１お
よび受信装置Ｃ１２にＴＣＰによる通信を行う回線Ｌ１
１，Ｌ１２を介してそれぞれ接続された送信ゲートウェ
イ１００とを有する。回線Ｌ１２は、回線Ｌ１１に比し
て伝送遅延が大きい回線であり、たとえば衛星回線であ
る。
【０００３】図１６において、送信装置Ｃ１１は、デー
タパケットを出力するデータパケット出力部１１１と、
送信ゲートウェイ１００が作成した仮の到達確認応答を
受信する仮到達確認応答受信部１１２とを有する。送信
ゲートウェイ１００は、バッファ１０１および配信管理
テーブル１０１を有するとともに、送信装置Ｃ１１から
送信されたデータパケットを受信し、このデータパケッ
トをバッファ１０１に蓄積させる蓄積部１０３と、回線
Ｌ１２を介してバッファ１０１に蓄積したデータパケッ
トを受信装置Ｃ１２に出力する出力部１０４と、受信装
置Ｃ１２に送信したデータパケットに対する仮の送達確
認応答を作成する仮送達確認応答作成部１０５と、この
作成した仮の送達確認応答を送信装置Ｃ１１に送信する
仮送達確認応答送信部１０６と、受信装置Ｃ１２から送
られた送達確認応答を受信する送達確認応答受信部１０
７と、受信したＳＹＮ（接続要求）パケットから通信情
報を取得し、配信管理テーブル１０２に配信情報として
記録する配信情報記録制御部１０８と、データパケット
の再送処理を行う再送処理部１０９とを有する。また、
受信装置Ｃ１２は、送信ゲートウェイ１００から送られ
たデータパケットを受信するデータパケット受信部１２
１と、送信ゲートウェイ１００に対して送達確認応答を
出力する送達確認応答出力部１２２とを有する。
タパケットを出力するデータパケット出力部１１１と、
送信ゲートウェイ１００が作成した仮の到達確認応答を
受信する仮到達確認応答受信部１１２とを有する。送信
ゲートウェイ１００は、バッファ１０１および配信管理
テーブル１０１を有するとともに、送信装置Ｃ１１から
送信されたデータパケットを受信し、このデータパケッ
トをバッファ１０１に蓄積させる蓄積部１０３と、回線
Ｌ１２を介してバッファ１０１に蓄積したデータパケッ
トを受信装置Ｃ１２に出力する出力部１０４と、受信装
置Ｃ１２に送信したデータパケットに対する仮の送達確
認応答を作成する仮送達確認応答作成部１０５と、この
作成した仮の送達確認応答を送信装置Ｃ１１に送信する
仮送達確認応答送信部１０６と、受信装置Ｃ１２から送
られた送達確認応答を受信する送達確認応答受信部１０
７と、受信したＳＹＮ（接続要求）パケットから通信情
報を取得し、配信管理テーブル１０２に配信情報として
記録する配信情報記録制御部１０８と、データパケット
の再送処理を行う再送処理部１０９とを有する。また、
受信装置Ｃ１２は、送信ゲートウェイ１００から送られ
たデータパケットを受信するデータパケット受信部１２
１と、送信ゲートウェイ１００に対して送達確認応答を
出力する送達確認応答出力部１２２とを有する。
【０００４】送信装置Ｃ１１からデータパケットが送出
されると、送信ゲートウェイ１００は、受信したデータ
パケットをバッファ１０１に一時的に蓄積するととも
に、配信管理テーブル１０２に、このデータパケットの
エントリを追加する。送信ゲートウェイ１００は、送信
装置Ｃ１１から受信したデータパケットを、回線Ｌ１２
を介して受信装置Ｃ１２に転送するとともに、このデー
タパケットに対する仮の到達確認応答のデータパケット
を作成し、送信装置Ｃ１１にこの仮の到達確認応答を送
信する。
されると、送信ゲートウェイ１００は、受信したデータ
パケットをバッファ１０１に一時的に蓄積するととも
に、配信管理テーブル１０２に、このデータパケットの
エントリを追加する。送信ゲートウェイ１００は、送信
装置Ｃ１１から受信したデータパケットを、回線Ｌ１２
を介して受信装置Ｃ１２に転送するとともに、このデー
タパケットに対する仮の到達確認応答のデータパケット
を作成し、送信装置Ｃ１１にこの仮の到達確認応答を送
信する。
【０００５】受信装置Ｃ１２は、送信ゲートウェイ１０
０からデータパケットを受信すると、この受信データパ
ケットに対する送達確認応答を作成し、この送達確認応
答を送信ゲートウェイ１００に送信する。この送達確認
応答には、対応するデータパケットに関するデータとこ
のデータパケットの到達確認状況に関するデータとが含
まれる。受信装置Ｃ１２から送達確認応答を受信した送
信ゲートウェイ１００は、送信ゲートウェイ１００内に
保持されているデータパケットであって、この送達確認
応答に対応するデータパケットをクリアする。
０からデータパケットを受信すると、この受信データパ
ケットに対する送達確認応答を作成し、この送達確認応
答を送信ゲートウェイ１００に送信する。この送達確認
応答には、対応するデータパケットに関するデータとこ
のデータパケットの到達確認状況に関するデータとが含
まれる。受信装置Ｃ１２から送達確認応答を受信した送
信ゲートウェイ１００は、送信ゲートウェイ１００内に
保持されているデータパケットであって、この送達確認
応答に対応するデータパケットをクリアする。
【０００６】ここで、送信ゲートウェイ１００から受信
装置Ｃ１２にデータパケットが送信される過程におい
て、このデータパケットの転送に失敗し、受信装置Ｃ１
２がこのデータパケットを受信することができなかった
場合、送信ゲートウェイ１００は、受信装置Ｃ１２側か
ら同一の送達確認応答を３つ続けて受信し、このデータ
パケットの再送処理を行う。
装置Ｃ１２にデータパケットが送信される過程におい
て、このデータパケットの転送に失敗し、受信装置Ｃ１
２がこのデータパケットを受信することができなかった
場合、送信ゲートウェイ１００は、受信装置Ｃ１２側か
ら同一の送達確認応答を３つ続けて受信し、このデータ
パケットの再送処理を行う。
【０００７】このように、従来のデータ配信管理システ
ムでは、送信ゲートウェイ１００が、送信ゲートウェイ
１００から受信装置Ｃ１２に対するデータパケットの送
信と同時に、送信装置Ｃ１１に対して仮の送達確認応答
（ｔｍｐＡＣＫ）を返送することによって、回線Ｌ１２
の伝送遅延によるＴＣＰのウィンドウサイズの減少を防
ぎ、スループットの低下をなくして速度性能の劣化を改
善していた。
ムでは、送信ゲートウェイ１００が、送信ゲートウェイ
１００から受信装置Ｃ１２に対するデータパケットの送
信と同時に、送信装置Ｃ１１に対して仮の送達確認応答
（ｔｍｐＡＣＫ）を返送することによって、回線Ｌ１２
の伝送遅延によるＴＣＰのウィンドウサイズの減少を防
ぎ、スループットの低下をなくして速度性能の劣化を改
善していた。
【０００８】また、送信ゲートウェイ１００は、送信装
置Ｃ１１からデータパケットを受信すると、仮の送達確
認応答を作成し、受信装置からの送達確認応答（ＡＣ
Ｋ）を受け付けるまで、このデータパケットを保持し、
３つの同一の送達確認応答（ＤｕｐｌｉｃａｔｅＡＣ
Ｋ）を受信した時点で、このデータパケットの送信を失
敗と判定し、この保持しているデータパケットの再送を
行うようにしていた。
置Ｃ１１からデータパケットを受信すると、仮の送達確
認応答を作成し、受信装置からの送達確認応答（ＡＣ
Ｋ）を受け付けるまで、このデータパケットを保持し、
３つの同一の送達確認応答（ＤｕｐｌｉｃａｔｅＡＣ
Ｋ）を受信した時点で、このデータパケットの送信を失
敗と判定し、この保持しているデータパケットの再送を
行うようにしていた。
【０００９】
【発明が解決しようとする課題】ところで、従来のデー
タ配信管理システムにおける速度性能劣化改善方式で
は、送信ゲートウェイ１００は、送信装置Ｃ１１に対
し、送信ゲートウェイ１００から受信装置Ｃ１２へのデ
ータ送信と同時に、仮の送達確認応答（ｔｍｐＡＣＫ）
を返すことによって、伝送遅延によるＴＣＰのウィンド
ウサイズの減少を防ぎ、スループットを低下させること
無く配信を行うシステムであったが、この方式では、デ
ータセグメントを受信すると直ちに、全てのデータセグ
メントに対する仮の送達確認応答を作成し、送信してい
た。
タ配信管理システムにおける速度性能劣化改善方式で
は、送信ゲートウェイ１００は、送信装置Ｃ１１に対
し、送信ゲートウェイ１００から受信装置Ｃ１２へのデ
ータ送信と同時に、仮の送達確認応答（ｔｍｐＡＣＫ）
を返すことによって、伝送遅延によるＴＣＰのウィンド
ウサイズの減少を防ぎ、スループットを低下させること
無く配信を行うシステムであったが、この方式では、デ
ータセグメントを受信すると直ちに、全てのデータセグ
メントに対する仮の送達確認応答を作成し、送信してい
た。
【００１０】しかし、この方式では、送信ゲートウェイ
１００が、送信装置Ｃ１１における送受信バッファある
いはＷｉｎｄｏｗの状態、および回線の輻輳を考慮せ
ず、仮の送達確認応答を返すため、送信ゲートウェイ１
００および送信装置Ｃ１１の処理の負荷が高くなり、結
果として速度性能の劣化防止を十分果たすことができな
かったという問題点があった。
１００が、送信装置Ｃ１１における送受信バッファある
いはＷｉｎｄｏｗの状態、および回線の輻輳を考慮せ
ず、仮の送達確認応答を返すため、送信ゲートウェイ１
００および送信装置Ｃ１１の処理の負荷が高くなり、結
果として速度性能の劣化防止を十分果たすことができな
かったという問題点があった。
【００１１】また、受信装置Ｃ１２からのＡＣＫを含む
データは、受信装置Ｃ１２で把握している送信装置Ｃ１
１の受信Ｗｉｎｄｏｗの状態に応じて決定されたスルー
プットで送信されてきており、送信ゲートウェイ１００
においてデータが受信された時点では、送信装置Ｃ１１
の受信バッファあるいはＷｉｎｄｏｗが減少していた場
合にも、古いＷｉｎｄｏｗ情報に基づいたスループット
でデータ転送を行っていたため、送信装置Ｃ１１の受信
バッファおよびＷｉｎｄｏｗがオーバーフローを引き起
こす可能性があるという問題点もあった。
データは、受信装置Ｃ１２で把握している送信装置Ｃ１
１の受信Ｗｉｎｄｏｗの状態に応じて決定されたスルー
プットで送信されてきており、送信ゲートウェイ１００
においてデータが受信された時点では、送信装置Ｃ１１
の受信バッファあるいはＷｉｎｄｏｗが減少していた場
合にも、古いＷｉｎｄｏｗ情報に基づいたスループット
でデータ転送を行っていたため、送信装置Ｃ１１の受信
バッファおよびＷｉｎｄｏｗがオーバーフローを引き起
こす可能性があるという問題点もあった。
【００１２】この発明は上記に鑑みてなされたもので、
送受信のバッファおよびＷｉｎｄｏｗサイズおよび回線
の輻輳を考慮し、ｔｍｐＡＣＫの送信のタイミングや送
信量を調整し、一層速く、一層効率的にデータの配信を
行うことができるデータ配信管理装置、データ配信管理
システムおよびデータ配信管理方法を得ることを目的と
する。
送受信のバッファおよびＷｉｎｄｏｗサイズおよび回線
の輻輳を考慮し、ｔｍｐＡＣＫの送信のタイミングや送
信量を調整し、一層速く、一層効率的にデータの配信を
行うことができるデータ配信管理装置、データ配信管理
システムおよびデータ配信管理方法を得ることを目的と
する。
【００１３】
【課題を解決するための手段】上記目的を達成するた
め、この発明にかかるデータ配信管理装置は、少なくと
も受信したデータを宛先に向けて転送するとともに、宛
先からの送達確認応答を受信するまでデータセグメント
を保存し、必要に応じて再送処理を行う機能を有したデ
ータ配信管理装置において、受信したデータセグメント
を保存するバッファと、送信元のスループット情報をも
とに、前記バッファのバッファサイズを可変設定するバ
ッファ管理手段とを備えたことを特徴とする。
め、この発明にかかるデータ配信管理装置は、少なくと
も受信したデータを宛先に向けて転送するとともに、宛
先からの送達確認応答を受信するまでデータセグメント
を保存し、必要に応じて再送処理を行う機能を有したデ
ータ配信管理装置において、受信したデータセグメント
を保存するバッファと、送信元のスループット情報をも
とに、前記バッファのバッファサイズを可変設定するバ
ッファ管理手段とを備えたことを特徴とする。
【００１４】この発明によれば、バッファ管理手段が、
送信元のスループット情報をもとに、前記バッファのバ
ッファサイズを可変設定するようにしている。
送信元のスループット情報をもとに、前記バッファのバ
ッファサイズを可変設定するようにしている。
【００１５】つぎの発明にかかるデータ配信管理装置
は、上記の発明において、宛先の受信バッファの状態に
応じたデータ転送速度調整を行う速度調整手段をさらに
備えたことを特徴とする。
は、上記の発明において、宛先の受信バッファの状態に
応じたデータ転送速度調整を行う速度調整手段をさらに
備えたことを特徴とする。
【００１６】この発明によれば、速度調整手段が、宛先
の受信バッファの状態に応じてスループットの増減幅を
調整するようにしている。
の受信バッファの状態に応じてスループットの増減幅を
調整するようにしている。
【００１７】つぎの発明にかかるデータ配信管理装置
は、上記の発明において、受信したデータを宛先に向け
て転送するとともに送信元に対して仮の送達確認応答を
作成し、返送する仮送達確認応答手段と、前記バッファ
のバッファサイズ不足を予測する予測手段と、前記予測
手段が前記バッファのバッファサイズ不足を予測した場
合に、前記仮の送達確認応答の返送を停止させる制御を
行う配信管理手段とをさらに備えたことを特徴とする。
は、上記の発明において、受信したデータを宛先に向け
て転送するとともに送信元に対して仮の送達確認応答を
作成し、返送する仮送達確認応答手段と、前記バッファ
のバッファサイズ不足を予測する予測手段と、前記予測
手段が前記バッファのバッファサイズ不足を予測した場
合に、前記仮の送達確認応答の返送を停止させる制御を
行う配信管理手段とをさらに備えたことを特徴とする。
【００１８】この発明によれば、配信管理手段が、前記
予測手段が前記バッファのバッファサイズ不足を予測し
た場合に、前記仮の送達確認応答の返送を停止させる制
御を行うようにし、バッファ状態に応じて送信側のスル
ープットを調整するようにしている。
予測手段が前記バッファのバッファサイズ不足を予測し
た場合に、前記仮の送達確認応答の返送を停止させる制
御を行うようにし、バッファ状態に応じて送信側のスル
ープットを調整するようにしている。
【００１９】つぎの発明にかかるデータ配信管理装置
は、上記の発明において、受信したデータを宛先に向け
て転送するとともに送信元に対して仮の送達確認応答を
作成し、返送する仮送達確認応答手段と、前記バッファ
のバッファサイズ不足を予測する予測手段と、前記予測
手段が前記バッファのバッファサイズ不足を予測した場
合に、前記仮の送達確認応答の返信速度を低下させる制
御を行う配信管理手段とをさらに備えたことを特徴とす
る。
は、上記の発明において、受信したデータを宛先に向け
て転送するとともに送信元に対して仮の送達確認応答を
作成し、返送する仮送達確認応答手段と、前記バッファ
のバッファサイズ不足を予測する予測手段と、前記予測
手段が前記バッファのバッファサイズ不足を予測した場
合に、前記仮の送達確認応答の返信速度を低下させる制
御を行う配信管理手段とをさらに備えたことを特徴とす
る。
【００２０】この発明によれば、前記配信管理手段は、
前記予測手段が前記バッファのバッファサイズ不足を予
測した場合に、前記仮の送達確認応答の返信速度を低下
させる制御を行い、バッファ状態に応じて送信側のスル
ープットを調整するようにしている。
前記予測手段が前記バッファのバッファサイズ不足を予
測した場合に、前記仮の送達確認応答の返信速度を低下
させる制御を行い、バッファ状態に応じて送信側のスル
ープットを調整するようにしている。
【００２１】つぎの発明にかかるデータ配信管理装置
は、上記の発明において、受信したデータを宛先に向け
て転送するとともに送信元に対して仮の送達確認応答を
作成し、返送する仮送達確認応答手段と、前記バッファ
のバッファサイズ不足を予測する予測手段と、前記予測
手段が前記バッファのバッファサイズ不足を予測した場
合に、前記仮の送達確認応答のウィンドウ情報を小さく
する制御を行う配信管理手段とをさらに備えたことを特
徴とする。
は、上記の発明において、受信したデータを宛先に向け
て転送するとともに送信元に対して仮の送達確認応答を
作成し、返送する仮送達確認応答手段と、前記バッファ
のバッファサイズ不足を予測する予測手段と、前記予測
手段が前記バッファのバッファサイズ不足を予測した場
合に、前記仮の送達確認応答のウィンドウ情報を小さく
する制御を行う配信管理手段とをさらに備えたことを特
徴とする。
【００２２】この発明によれば、前記配信管理手段は、
前記予測手段が前記バッファのバッファサイズ不足を予
測した場合に、前記仮の送達確認応答のウィンドウ情報
を小さくする制御を行い、バッファ状態に応じて送信側
のスループットを調整するようにしている。
前記予測手段が前記バッファのバッファサイズ不足を予
測した場合に、前記仮の送達確認応答のウィンドウ情報
を小さくする制御を行い、バッファ状態に応じて送信側
のスループットを調整するようにしている。
【００２３】つぎの発明にかかるデータ配信管理装置
は、上記の発明において、受信したデータを宛先に向け
て転送するとともに送信元に対して仮の送達確認応答を
作成し、返送する仮送達確認応答手段と、前記バッファ
のバッファサイズ不足を予測する予測手段と、前記予測
手段が前記バッファのバッファサイズ不足を予測した場
合に、新規の前記仮の送達確認応答を利用するコネクシ
ョン接続要求を受けない制御を行う配信管理手段とをさ
らに備えたことを特徴とする。
は、上記の発明において、受信したデータを宛先に向け
て転送するとともに送信元に対して仮の送達確認応答を
作成し、返送する仮送達確認応答手段と、前記バッファ
のバッファサイズ不足を予測する予測手段と、前記予測
手段が前記バッファのバッファサイズ不足を予測した場
合に、新規の前記仮の送達確認応答を利用するコネクシ
ョン接続要求を受けない制御を行う配信管理手段とをさ
らに備えたことを特徴とする。
【００２４】この発明によれば、前記配信管理手段は、
前記予測手段が前記バッファのバッファサイズ不足を予
測した場合に、新規の前記仮の送達確認応答を利用する
コネクション接続要求を受けない制御を行い、バッファ
状態に応じて送信側のスループットを調整するようにし
ている。
前記予測手段が前記バッファのバッファサイズ不足を予
測した場合に、新規の前記仮の送達確認応答を利用する
コネクション接続要求を受けない制御を行い、バッファ
状態に応じて送信側のスループットを調整するようにし
ている。
【００２５】つぎの発明にかかるデータ配信管理装置
は、上記の発明において、宛先毎に優先度が設定された
優先度管理テーブルをさらに備え、前記配信管理手段
は、前記優先度に応じて前記バッファサイズを調整する
ことを特徴とする。
は、上記の発明において、宛先毎に優先度が設定された
優先度管理テーブルをさらに備え、前記配信管理手段
は、前記優先度に応じて前記バッファサイズを調整する
ことを特徴とする。
【００２６】この発明によれば、前記配信管理手段は、
前記優先度に応じて前記バッファサイズを調整するよう
にしている。
前記優先度に応じて前記バッファサイズを調整するよう
にしている。
【００２７】つぎの発明にかかるデータ配信管理装置
は、上記の発明において、前記配信管理手段は、前記バ
ッファの空き領域が、予め設定されたバッファサイズの
余裕値を超えた場合に受信データ量を抑制する通信に対
して、前記余裕値を超えた場合、前記受信データ量が抑
制されるように該通信の送信元に指示することを特徴と
する。
は、上記の発明において、前記配信管理手段は、前記バ
ッファの空き領域が、予め設定されたバッファサイズの
余裕値を超えた場合に受信データ量を抑制する通信に対
して、前記余裕値を超えた場合、前記受信データ量が抑
制されるように該通信の送信元に指示することを特徴と
する。
【００２８】この発明によれば、前記配信管理手段は、
前記バッファの空き領域が、予め設定されたバッファサ
イズの余裕値を超えた場合に受信データ量を抑制する通
信に対して、前記余裕値を超えた場合、前記受信データ
量が抑制されるように該通信の送信元に指示するように
している。
前記バッファの空き領域が、予め設定されたバッファサ
イズの余裕値を超えた場合に受信データ量を抑制する通
信に対して、前記余裕値を超えた場合、前記受信データ
量が抑制されるように該通信の送信元に指示するように
している。
【００２９】つぎの発明にかかるデータ配信管理装置
は、上記の発明において、選択的な速度調整を行うか否
かを決定する決定手段をさらに備えたことを特徴とす
る。
は、上記の発明において、選択的な速度調整を行うか否
かを決定する決定手段をさらに備えたことを特徴とす
る。
【００３０】この発明によれば、決定手段が、選択的な
速度調整を行うか否かを決定するようにしている。
速度調整を行うか否かを決定するようにしている。
【００３１】つぎの発明にかかるデータ配信管理システ
ムは、データを送受信する第１の端末装置と、前記該第
１の端末装置の通信相手先である第２の端末装置と、前
記第１の端末装置と前記第２の端末装置との間の伝送路
上に配置され、上記の発明ののいずれか一つに記載の１
以上のデータ配信管理装置とを備えたことを特徴とす
る。
ムは、データを送受信する第１の端末装置と、前記該第
１の端末装置の通信相手先である第２の端末装置と、前
記第１の端末装置と前記第２の端末装置との間の伝送路
上に配置され、上記の発明ののいずれか一つに記載の１
以上のデータ配信管理装置とを備えたことを特徴とす
る。
【００３２】この発明によれば、データ配信管理装置が
第１の端末装置と第２の端末装置との間に配置され、第
１の端末装置あるいは第２の端末装置からのスループッ
トの低下を防止する制御をするようにしている。
第１の端末装置と第２の端末装置との間に配置され、第
１の端末装置あるいは第２の端末装置からのスループッ
トの低下を防止する制御をするようにしている。
【００３３】つぎの発明にかかるデータ配信管理方法
は、少なくとも受信したデータを宛先に向けて転送する
とともに、宛先からの送達確認応答を受信するまでデー
タセグメントを保存し、必要に応じて再送処理を行う機
能を有したデータ配信管理装置のデータ配信管理方法に
おいて、受信したデータセグメントを保存する保存工程
と、送信元のスループット情報および配信処理終了まで
にかかる時間をもとに、前記バッファのバッファサイズ
を可変設定するバッファ管理工程とを含むことを特徴と
する。
は、少なくとも受信したデータを宛先に向けて転送する
とともに、宛先からの送達確認応答を受信するまでデー
タセグメントを保存し、必要に応じて再送処理を行う機
能を有したデータ配信管理装置のデータ配信管理方法に
おいて、受信したデータセグメントを保存する保存工程
と、送信元のスループット情報および配信処理終了まで
にかかる時間をもとに、前記バッファのバッファサイズ
を可変設定するバッファ管理工程とを含むことを特徴と
する。
【００３４】この発明によれば、バッファ管理工程が、
送信元のスループット情報および配信処理終了までにか
かる時間をもとに、前記バッファのバッファサイズを可
変設定するようにしている。
送信元のスループット情報および配信処理終了までにか
かる時間をもとに、前記バッファのバッファサイズを可
変設定するようにしている。
【００３５】つぎの発明にかかるデータ配信管理方法
は、上記の発明において、宛先の受信バッファの状態に
応じたデータ転送速度調整を行う速度調整工程をさらに
含むことを特徴とする。
は、上記の発明において、宛先の受信バッファの状態に
応じたデータ転送速度調整を行う速度調整工程をさらに
含むことを特徴とする。
【００３６】この発明によれば、速度調整工程が、宛先
の受信バッファの状態に応じてスループットの増減幅を
調整するようにしている。
の受信バッファの状態に応じてスループットの増減幅を
調整するようにしている。
【００３７】つぎの発明にかかるデータ配信管理方法
は、上記の発明において、受信したデータを宛先に向け
て転送するとともに送信元に対して仮の送達確認応答を
作成し、返送する仮送達確認応答工程と、前記バッファ
のバッファサイズ不足を予測する予測工程と、前記予測
工程が前記バッファのバッファサイズ不足を予測した場
合に、前記仮の送達確認応答の返送を停止させる制御を
行う配信管理工程とをさらに備えたことを特徴とする。
は、上記の発明において、受信したデータを宛先に向け
て転送するとともに送信元に対して仮の送達確認応答を
作成し、返送する仮送達確認応答工程と、前記バッファ
のバッファサイズ不足を予測する予測工程と、前記予測
工程が前記バッファのバッファサイズ不足を予測した場
合に、前記仮の送達確認応答の返送を停止させる制御を
行う配信管理工程とをさらに備えたことを特徴とする。
【００３８】この発明によれば、配信管理工程が、前記
予測工程が前記バッファのバッファサイズ不足を予測し
た場合に、前記仮の送達確認応答の返送を停止させる制
御を行うようにし、バッファ状態に応じて送信側のスル
ープットを調整するようにしている。
予測工程が前記バッファのバッファサイズ不足を予測し
た場合に、前記仮の送達確認応答の返送を停止させる制
御を行うようにし、バッファ状態に応じて送信側のスル
ープットを調整するようにしている。
【００３９】つぎの発明にかかるデータ配信管理方法
は、上記の発明において、前記配信管理工程は、前記予
測工程が前記バッファのバッファサイズ不足を予測した
場合に、前記仮の送達確認応答の返信速度を低下させる
制御を行うことを特徴とする。
は、上記の発明において、前記配信管理工程は、前記予
測工程が前記バッファのバッファサイズ不足を予測した
場合に、前記仮の送達確認応答の返信速度を低下させる
制御を行うことを特徴とする。
【００４０】この発明によれば、前記配信管理工程は、
前記予測工程が前記バッファのバッファサイズ不足を予
測した場合に、前記仮の送達確認応答の返信速度を低下
させる制御を行い、バッファ状態に応じて送信側のスル
ープットを調整するようにしている。
前記予測工程が前記バッファのバッファサイズ不足を予
測した場合に、前記仮の送達確認応答の返信速度を低下
させる制御を行い、バッファ状態に応じて送信側のスル
ープットを調整するようにしている。
【００４１】つぎの発明にかかるデータ配信管理方法
は、上記の発明において、前記配信管理工程は、前記予
測工程が前記バッファのバッファサイズ不足を予測した
場合に、前記仮の送達確認応答のウィンドウ情報を小さ
くする制御を行うことを特徴とする。
は、上記の発明において、前記配信管理工程は、前記予
測工程が前記バッファのバッファサイズ不足を予測した
場合に、前記仮の送達確認応答のウィンドウ情報を小さ
くする制御を行うことを特徴とする。
【００４２】この発明によれば、前記配信管理工程は、
前記予測工程が前記バッファのバッファサイズ不足を予
測した場合に、前記仮の送達確認応答のウィンドウ情報
を小さくする制御を行い、バッファ状態に応じて送信側
のスループットを調整するようにしている。
前記予測工程が前記バッファのバッファサイズ不足を予
測した場合に、前記仮の送達確認応答のウィンドウ情報
を小さくする制御を行い、バッファ状態に応じて送信側
のスループットを調整するようにしている。
【００４３】つぎの発明にかかるデータ配信管理方法
は、上記の発明において、前記配信管理工程は、前記予
測工程が前記バッファのバッファサイズ不足を予測した
場合に、新規の前記仮の送達確認応答を利用するコネク
ション接続要求を受けない制御を行うことを特徴とす
る。
は、上記の発明において、前記配信管理工程は、前記予
測工程が前記バッファのバッファサイズ不足を予測した
場合に、新規の前記仮の送達確認応答を利用するコネク
ション接続要求を受けない制御を行うことを特徴とす
る。
【００４４】この発明によれば、前記配信管理工程は、
前記予測工程が前記バッファのバッファサイズ不足を予
測した場合に、新規の前記仮の送達確認応答を利用する
コネクション接続要求を受けない制御を行い、バッファ
状態に応じて送信側のスループットを調整するようにし
ている。
前記予測工程が前記バッファのバッファサイズ不足を予
測した場合に、新規の前記仮の送達確認応答を利用する
コネクション接続要求を受けない制御を行い、バッファ
状態に応じて送信側のスループットを調整するようにし
ている。
【００４５】つぎの発明にかかるデータ配信管理方法
は、上記の発明において、宛先毎に優先度が設定する優
先度設定工程をさらに含み、前記配信管理工程は、前記
優先度に応じて前記バッファサイズを調整することを特
徴とする。
は、上記の発明において、宛先毎に優先度が設定する優
先度設定工程をさらに含み、前記配信管理工程は、前記
優先度に応じて前記バッファサイズを調整することを特
徴とする。
【００４６】この発明によれば、前記配信管理工程は、
前記優先度に応じて前記バッファサイズを調整するよう
にしている。
前記優先度に応じて前記バッファサイズを調整するよう
にしている。
【００４７】つぎの発明にかかるデータ配信管理方法
は、上記の発明において、前記配信管理方法は、前記バ
ッファの空き領域が、予め設定されたバッファサイズの
余裕値を超えた場合に受信データ量を抑制する通信に対
して、前記受信データ量が抑制されるように該通信の送
信元に指示することを特徴とする。
は、上記の発明において、前記配信管理方法は、前記バ
ッファの空き領域が、予め設定されたバッファサイズの
余裕値を超えた場合に受信データ量を抑制する通信に対
して、前記受信データ量が抑制されるように該通信の送
信元に指示することを特徴とする。
【００４８】この発明によれば、前記配信管理工程は、
前記バッファの空き領域が、予め設定されたバッファサ
イズの余裕値を超えた場合に受信データ量を抑制する通
信に対して、前記受信データ量が抑制されるように該通
信の送信元に指示することを特徴とする。
前記バッファの空き領域が、予め設定されたバッファサ
イズの余裕値を超えた場合に受信データ量を抑制する通
信に対して、前記受信データ量が抑制されるように該通
信の送信元に指示することを特徴とする。
【００４９】つぎの発明にかかるデータ配信管理方法
は、上記の発明において、選択的な速度調整を行うか否
かを決定する決定工程をさらに備えたことを特徴とす
る。
は、上記の発明において、選択的な速度調整を行うか否
かを決定する決定工程をさらに備えたことを特徴とす
る。
【００５０】この発明によれば、決定工程が、選択的な
速度調整を行うか否かを決定するようにしている。
速度調整を行うか否かを決定するようにしている。
【００５１】
【発明の実施の形態】以下、添付図面を参照して、この
発明にかかるデータ配信管理装置、データ配信管理シス
テムおよびデータ配信管理方法の好適な実施の形態を詳
細に説明する。
発明にかかるデータ配信管理装置、データ配信管理シス
テムおよびデータ配信管理方法の好適な実施の形態を詳
細に説明する。
【００５２】実施の形態１．図１は、この発明の実施の
形態１であるデータ配信管理装置を含むデータ配信管理
システムの構成を示すブロック図である。図１におい
て、このデータ配信管理システムは、送信装置Ｃ１が回
線２を介してデータ配信管理装置１０に接続され、デー
タ配信管理装置１０が回線３を介して受信装置Ｃ２に接
続される。回線３は、衛星回線などの伝送遅延の大きな
回線であり、回線２は、回線３に比して伝送遅延が小さ
い回線である。
形態１であるデータ配信管理装置を含むデータ配信管理
システムの構成を示すブロック図である。図１におい
て、このデータ配信管理システムは、送信装置Ｃ１が回
線２を介してデータ配信管理装置１０に接続され、デー
タ配信管理装置１０が回線３を介して受信装置Ｃ２に接
続される。回線３は、衛星回線などの伝送遅延の大きな
回線であり、回線２は、回線３に比して伝送遅延が小さ
い回線である。
【００５３】データ配信管理装置１０は、送信ゲートウ
ェイＳＧと、配信管理テーブル１と、プロトコル管理テ
ーブル５と、バッファの割り当てを行うバッファ割当部
６ａを有した送信バッファ６と、受信バッファ７、およ
び経路管理テーブル８を有する。送信ゲートウェイＳＧ
は、送信装置Ｃ１との間においてデータパケットの入出
力処理を行う通信部１７と、受信装置Ｃ２との間におい
てデータパケットの入出力処理を行う通信部１１と、仮
の送達確認応答（ｔｍｐＡＣＫ）を作成するために、受
信したデータパケットを保存するｔｍｐＡＣＫバッファ
４と、受信装置Ｃ２に対して送信したデータパケットに
対してｔｍｐＡＣＫの返送を行うか否かを判断するｔｍ
ｐＡＣＫ使用判定部１２、送信装置Ｃ１から受信したデ
ータパケットをもとにｔｍｐＡＣＫを作成するｔｍｐＡ
ＣＫ作成部１３と、データパケット毎の送達確認応答の
タイムアウト時間（ＳＧＴｉｍｅｒ）をカウントアップ
し、この送達確認応答待ちのタイムアウトイベントを発
生させるＳＧＴｉｍｅｒカウント部１４と、送信装置Ｃ
１にｔｍｐＡＣＫを送信したか否かの情報および受信装
置Ｃ２からの送達確認応答に関する情報を配信管理テー
ブル１に書き込む処理を行う配信データ記録部１５と、
ＳＧＴｉｍｅｒ値および配信管理テーブル１の内容に対
応してデータパケットの配信を管理するＳＧ配信管理部
１６とを有する。
ェイＳＧと、配信管理テーブル１と、プロトコル管理テ
ーブル５と、バッファの割り当てを行うバッファ割当部
６ａを有した送信バッファ６と、受信バッファ７、およ
び経路管理テーブル８を有する。送信ゲートウェイＳＧ
は、送信装置Ｃ１との間においてデータパケットの入出
力処理を行う通信部１７と、受信装置Ｃ２との間におい
てデータパケットの入出力処理を行う通信部１１と、仮
の送達確認応答（ｔｍｐＡＣＫ）を作成するために、受
信したデータパケットを保存するｔｍｐＡＣＫバッファ
４と、受信装置Ｃ２に対して送信したデータパケットに
対してｔｍｐＡＣＫの返送を行うか否かを判断するｔｍ
ｐＡＣＫ使用判定部１２、送信装置Ｃ１から受信したデ
ータパケットをもとにｔｍｐＡＣＫを作成するｔｍｐＡ
ＣＫ作成部１３と、データパケット毎の送達確認応答の
タイムアウト時間（ＳＧＴｉｍｅｒ）をカウントアップ
し、この送達確認応答待ちのタイムアウトイベントを発
生させるＳＧＴｉｍｅｒカウント部１４と、送信装置Ｃ
１にｔｍｐＡＣＫを送信したか否かの情報および受信装
置Ｃ２からの送達確認応答に関する情報を配信管理テー
ブル１に書き込む処理を行う配信データ記録部１５と、
ＳＧＴｉｍｅｒ値および配信管理テーブル１の内容に対
応してデータパケットの配信を管理するＳＧ配信管理部
１６とを有する。
【００５４】なお、図１において、送信バッファ６、受
信バッファ７、およびｔｍｐＡＣＫバッファ４は、それ
ぞれ別個のバッファとして示されているが、これに限ら
ず、部分的あるいは全てを同一のバッファとして実装す
るようにしてもよい。また、別個のバッファとして実装
する場合であっても、同一のバッファとして実装する場
合であっても、管理目的に応じて制御情報などを含めた
情報とともに用いることが可能な図示しない管理テーブ
ルを設け、パケットデータの格納位置が識別可能なよう
に実装することによって、管理および検索の効率化を図
ることができる。
信バッファ７、およびｔｍｐＡＣＫバッファ４は、それ
ぞれ別個のバッファとして示されているが、これに限ら
ず、部分的あるいは全てを同一のバッファとして実装す
るようにしてもよい。また、別個のバッファとして実装
する場合であっても、同一のバッファとして実装する場
合であっても、管理目的に応じて制御情報などを含めた
情報とともに用いることが可能な図示しない管理テーブ
ルを設け、パケットデータの格納位置が識別可能なよう
に実装することによって、管理および検索の効率化を図
ることができる。
【００５５】ここで、図２〜図８を参照して、データ配
信管理装置１０のデータ配信管理処理について説明す
る。まず、送信ゲートウェイＳＧの通信部１７，１１
は、データパケットを受信すると、この受信したデータ
パケットを受信バッファ７に一時保存し、ＳＧ配信管理
部１６は、図２に示す配信処理を行う。
信管理装置１０のデータ配信管理処理について説明す
る。まず、送信ゲートウェイＳＧの通信部１７，１１
は、データパケットを受信すると、この受信したデータ
パケットを受信バッファ７に一時保存し、ＳＧ配信管理
部１６は、図２に示す配信処理を行う。
【００５６】図２において、まず、ｔｍｐＡＣＫ使用判
定部１２が、受信したデータパケットのチェックを行
い、このチェック結果に応じて送信ゲートウェイＳＧが
もつ受信データパケットに対するｔｍｐＡＣＫ利用可能
フラグの「ＯＮ」、「ＯＦＦ」を決定し、必要に応じて
ｔｍｐＡＣＫ利用可能フラグの「ＯＮ」、「ＯＦＦ」も
含め、受信データパケットの情報を配信管理テーブル１
に登録する（ステップＳ１１）。
定部１２が、受信したデータパケットのチェックを行
い、このチェック結果に応じて送信ゲートウェイＳＧが
もつ受信データパケットに対するｔｍｐＡＣＫ利用可能
フラグの「ＯＮ」、「ＯＦＦ」を決定し、必要に応じて
ｔｍｐＡＣＫ利用可能フラグの「ＯＮ」、「ＯＦＦ」も
含め、受信データパケットの情報を配信管理テーブル１
に登録する（ステップＳ１１）。
【００５７】その後、ｔｍｐＡＣＫ制御フラグをもとに
ｔｍｐＡＣＫの利用制御を行うか否かを判断する（ステ
ップＳ１２）。ｔｍｐＡＣＫの利用制御を行わない場合
（ステップＳ１２，ＮＯ）には、そのまま本処理を終了
し、ｔｍｐＡＣＫの利用制御を行う場合（ステップＳ１
２，ＹＥＳ）には、ｔｍｐＡＣＫ利用制御処理を実行し
て（ステップＳ１３）、本処理を終了する。
ｔｍｐＡＣＫの利用制御を行うか否かを判断する（ステ
ップＳ１２）。ｔｍｐＡＣＫの利用制御を行わない場合
（ステップＳ１２，ＮＯ）には、そのまま本処理を終了
し、ｔｍｐＡＣＫの利用制御を行う場合（ステップＳ１
２，ＹＥＳ）には、ｔｍｐＡＣＫ利用制御処理を実行し
て（ステップＳ１３）、本処理を終了する。
【００５８】図３は、図２に示したステップＳ１１にお
けるパケットのチェック処理手順を示すフローチャート
である。図３において、まず、遅延依存の回線への転送
か否か、すなわち、遅延の大きな回線に対する転送か否
かを判断する（ステップＳ２１）。この判断は、この実
施の形態１において、ネットワーク層のヘッダがＩＰヘ
ッダであるか否か、およびＩＰヘッダであった場合、正
しいＩＰアドレスとなっているかどうかを確認した後、
ルーティング機能によって決定される経路が、宛先への
経路上に伝送遅延回線があるか否かを、経路管理テーブ
ル８を用いて判定する。
けるパケットのチェック処理手順を示すフローチャート
である。図３において、まず、遅延依存の回線への転送
か否か、すなわち、遅延の大きな回線に対する転送か否
かを判断する（ステップＳ２１）。この判断は、この実
施の形態１において、ネットワーク層のヘッダがＩＰヘ
ッダであるか否か、およびＩＰヘッダであった場合、正
しいＩＰアドレスとなっているかどうかを確認した後、
ルーティング機能によって決定される経路が、宛先への
経路上に伝送遅延回線があるか否かを、経路管理テーブ
ル８を用いて判定する。
【００５９】ここで、プロトコルがＩＰを用いていない
場合、正しいフォーマットのアドレスではない場合、お
よび宛先への経路が伝送遅延回線を含まない場合など
（ステップＳ２１，ＮＯ）には、ｔｍｐＡＣＫ利用制御
フラグを「ＯＦＦ」にし（ステップＳ２２）、受信セグ
メントを宛先に転送し（ステップＳ２３）、本処理を終
了する。なお、このｔｍｐＡＣＫ利用可能フラグは、上
述した別個のバッファあるいは同一のバッファに設けら
れる図示しない管理テーブルを用いる場合、この管理テ
ーブル内の情報として保持するようにしてもよい。
場合、正しいフォーマットのアドレスではない場合、お
よび宛先への経路が伝送遅延回線を含まない場合など
（ステップＳ２１，ＮＯ）には、ｔｍｐＡＣＫ利用制御
フラグを「ＯＦＦ」にし（ステップＳ２２）、受信セグ
メントを宛先に転送し（ステップＳ２３）、本処理を終
了する。なお、このｔｍｐＡＣＫ利用可能フラグは、上
述した別個のバッファあるいは同一のバッファに設けら
れる図示しない管理テーブルを用いる場合、この管理テ
ーブル内の情報として保持するようにしてもよい。
【００６０】図４は、経路管理テーブル８の内容の一例
を示す図である。図４において、この経路管理テーブル
８は、大きく「送信元−ルータ経路」と「ルータ−宛先
経路」とに項目区分される。「送信元−ルータ経路」
は、さらに「送信元ＩＰ」、「最大Ｗｉｎｄｏｗサイ
ズ」、「送信元優先度」、および送信元−ルータ間の
「スループット」に項目区分される。一方、「ルータ−
宛先経路」は、ルータ、すなわち送信ゲートウェイＳＧ
と宛先との間の経路に関する情報群であり、たとえば、
どの回線につながっているかを示す、判定対象の経路
「ポート」、この「ポート」への経路の「遅延」時間、
「スループット」、「宛先ＩＰ」、送信ゲートウェイＳ
Ｇで扱う通信全てのパケットを転送することができなく
なった状況で発生した場合などにおいて、パケット転送
の優先度の一つの判定基準となる「宛先優先度」、この
宛先の「最大Ｗｉｎｄｏｗサイズ」にさらに項目区分さ
れる。
を示す図である。図４において、この経路管理テーブル
８は、大きく「送信元−ルータ経路」と「ルータ−宛先
経路」とに項目区分される。「送信元−ルータ経路」
は、さらに「送信元ＩＰ」、「最大Ｗｉｎｄｏｗサイ
ズ」、「送信元優先度」、および送信元−ルータ間の
「スループット」に項目区分される。一方、「ルータ−
宛先経路」は、ルータ、すなわち送信ゲートウェイＳＧ
と宛先との間の経路に関する情報群であり、たとえば、
どの回線につながっているかを示す、判定対象の経路
「ポート」、この「ポート」への経路の「遅延」時間、
「スループット」、「宛先ＩＰ」、送信ゲートウェイＳ
Ｇで扱う通信全てのパケットを転送することができなく
なった状況で発生した場合などにおいて、パケット転送
の優先度の一つの判定基準となる「宛先優先度」、この
宛先の「最大Ｗｉｎｄｏｗサイズ」にさらに項目区分さ
れる。
【００６１】ここで、送信元とルータとの間の「スルー
プット」の値には、仮ＡＣＫ機能を利用した場合と利用
しない場合とによってスループットが異なる場合がある
ため、回線のデフォルト値およびそれ以前までの通信で
使用した際の実測値による値を入れる。なお、デフォル
ト値は、回線の種類に応じてユーザ設定が可能であり、
入力されない場合や経路によって回線が特定できない場
合には例えば１Ｍｂｐｓに設定する。一方、ルータと宛
先との間の「スループット」は、遅延に左右されるた
め、回線のデフォルトのスループットを入れる。また、
「遅延」時間には、回線の持つデフォルト値、あるいは
それ以前までの通信で使用した際の実測値による値を入
れる。「宛先ＩＰ」の項目は、判定対照の通信の宛先Ｉ
Ｐを表したものである。したがって、ＩＰヘッダの宛先
アドレス部にある宛先への経路が遅延依存の経路ではな
いとされた場合（ステップＳ２１，ＮＯ）、ｔｍｐＡＣ
Ｋ利用可能フラグを「ＯＦＦ」にし（ステップＳ２
２）、受信セグメントを宛先に転送し（ステップＳ２
３）、本処理を終了する。
プット」の値には、仮ＡＣＫ機能を利用した場合と利用
しない場合とによってスループットが異なる場合がある
ため、回線のデフォルト値およびそれ以前までの通信で
使用した際の実測値による値を入れる。なお、デフォル
ト値は、回線の種類に応じてユーザ設定が可能であり、
入力されない場合や経路によって回線が特定できない場
合には例えば１Ｍｂｐｓに設定する。一方、ルータと宛
先との間の「スループット」は、遅延に左右されるた
め、回線のデフォルトのスループットを入れる。また、
「遅延」時間には、回線の持つデフォルト値、あるいは
それ以前までの通信で使用した際の実測値による値を入
れる。「宛先ＩＰ」の項目は、判定対照の通信の宛先Ｉ
Ｐを表したものである。したがって、ＩＰヘッダの宛先
アドレス部にある宛先への経路が遅延依存の経路ではな
いとされた場合（ステップＳ２１，ＮＯ）、ｔｍｐＡＣ
Ｋ利用可能フラグを「ＯＦＦ」にし（ステップＳ２
２）、受信セグメントを宛先に転送し（ステップＳ２
３）、本処理を終了する。
【００６２】一方、正しいＩＰアドレスであり、かつ伝
送遅延を含んだ経路制御を行う通信であると判定された
場合（ステップＳ２１，ＹＥＳ）には、受信したセグメ
ントのＩＰヘッダのプロトコルのバイト列を参照し、遅
延依存であるか否か、たとえば、ＴＣＰか、それ以外の
プロトコルであるか否かの判定を行う（ステップＳ２
４）。この判定には、図５に示すプロトコル管理テーブ
ル５が参照される。
送遅延を含んだ経路制御を行う通信であると判定された
場合（ステップＳ２１，ＹＥＳ）には、受信したセグメ
ントのＩＰヘッダのプロトコルのバイト列を参照し、遅
延依存であるか否か、たとえば、ＴＣＰか、それ以外の
プロトコルであるか否かの判定を行う（ステップＳ２
４）。この判定には、図５に示すプロトコル管理テーブ
ル５が参照される。
【００６３】ステップＳ２４において、遅延依存のプロ
トコルであると判定された場合、受信したセグメントの
ヘッダ部のコードビット（CodeBit）を参照し、通信開
始時のセグメントか否かを判定し（ステップＳ２５）、
通信開始セグメントであった場合（ステップＳ２５，Ｙ
ＥＳ）、ステップＳ２８に移行する。一方、通信開始セ
グメントではないと判定された場合（ステップＳ２５，
ＮＯ）、ステップＳ２６に移行する。
トコルであると判定された場合、受信したセグメントの
ヘッダ部のコードビット（CodeBit）を参照し、通信開
始時のセグメントか否かを判定し（ステップＳ２５）、
通信開始セグメントであった場合（ステップＳ２５，Ｙ
ＥＳ）、ステップＳ２８に移行する。一方、通信開始セ
グメントではないと判定された場合（ステップＳ２５，
ＮＯ）、ステップＳ２６に移行する。
【００６４】ステップＳ２６において、受信したセグメ
ントが、図１に示した配信管理テーブル１に、既に登録
済の通信であるか否かの判定を行う。この判定では、Ｉ
Ｐヘッダ中の送信元ＩＰとＴＣＰヘッダ中の送信元ポー
トの組み合わせ、および宛先ＩＰと宛先ポートとの組み
合わせが全て同一の通信を同一の管理単位とし、登録済
の通信であると判定する。
ントが、図１に示した配信管理テーブル１に、既に登録
済の通信であるか否かの判定を行う。この判定では、Ｉ
Ｐヘッダ中の送信元ＩＰとＴＣＰヘッダ中の送信元ポー
トの組み合わせ、および宛先ＩＰと宛先ポートとの組み
合わせが全て同一の通信を同一の管理単位とし、登録済
の通信であると判定する。
【００６５】ここで、図６および図７は、配信管理テー
ブルの一例を示す図であり、図７は、図６に示した左端
の１つの受付番号（通信ＩＤ）にリンクする詳細な情報
である。図６において、複数にわたる行Ｄ２５，Ｄ２６
は、項目Ｄ１１〜Ｄ２４を持つ、上述した管理単位を同
じくする通信に関する情報を表す。また、図７におい
て、項目Ｄ３１〜Ｄ３３は、上述した管理単位を同じく
する通信においてデータ配信管理装置１０が受信したセ
グメントに関する情報を表すものであり、行Ｄ２５にお
ける通信に関するデータの例である。これらの各項目
は、データ配信管理装置１０が受信したセグメントから
情報を取得するものである。
ブルの一例を示す図であり、図７は、図６に示した左端
の１つの受付番号（通信ＩＤ）にリンクする詳細な情報
である。図６において、複数にわたる行Ｄ２５，Ｄ２６
は、項目Ｄ１１〜Ｄ２４を持つ、上述した管理単位を同
じくする通信に関する情報を表す。また、図７におい
て、項目Ｄ３１〜Ｄ３３は、上述した管理単位を同じく
する通信においてデータ配信管理装置１０が受信したセ
グメントに関する情報を表すものであり、行Ｄ２５にお
ける通信に関するデータの例である。これらの各項目
は、データ配信管理装置１０が受信したセグメントから
情報を取得するものである。
【００６６】図６において、項目Ｄ１１は、この通信を
一意に識別するための受付番号（通信ＩＤ）である。項
目Ｄ１２は、この通信に割り当てられたｔｍｐＡＣＫ作
成対象セグメントを保存するための割当バッファ量を表
すものである。項目Ｄ１３は、この通信が実際にｔｍｐ
ＡＣＫ作成対象セグメントの保存のために使用している
使用バッファ量を示している。項目Ｄ１４は、管理する
通信の送信元ＩＰアドレスを表すものである。項目Ｄ１
５は、送信元優先度を表し、この優先度は例えば、
「１」、「２」、「３」、・・・のような整数値で表さ
れ、数値の高いほど優先度が高い送信元であるという実
装が可能である。項目Ｄ１６は、宛先ＩＰアドレスを表
す。項目Ｄ１７は、宛先優先度を表す。この優先度は例
えば、「１」、「２」、「３」、・・・のような整数値
で表され、数値の高いほど優先度が高い送信元であると
いう実装が可能である。項目Ｄ１８は、送信元スループ
ットであり、ここには通信開始時にはデフォルト値とし
て、経路管理テーブル８を参照し、当該通信における送
信元のデフォルトのスループットを入れ、以後、一定間
隔ごとにスループットの実測値を計り更新する。通信終
了時に、経路管理テーブル８のデフォルトのスループッ
トの値も、実測値を元に再計算し更新することも可能で
ある。項目Ｄ１９は、通信の優先度フラグであり、これ
は例えばＴＣＰセグメントの緊急フラグが「ＯＮ」であ
れば、「ＯＮ」とするという実装が可能である。項目Ｄ
２０は、仮ＡＣＫ送信待ちによる速度調節に関する情報
であり、仮ＡＣＫ送信待ちによる速度調節機能を用いる
か否かに関するフラグ、および当該フラグが「ＯＮ」の
場合はその調節のための待ち時間を示す値を入れる項目
であり、項目Ｄ２１は、Ｗｉｎｄｏｗサイズ情報による
速度調節機能に関する情報を入れる項目であり、この機
能を用いるか否かに関するフラグおよびこのフラグが
「ＯＮ」の場合はどのくらいＷｉｎｄｏｗサイズを調節
するかを示す値を入れる項目である。項目Ｄ２２は、デ
ータ配信管理装置１０と宛先との間の往復時間（Round
Trip Time：ＲＴＴ）を表す値であり、デフォルト値は
経路管理テーブル８の「遅延」情報に書いてある値の２
倍の数値を入れ、通信において値を適宜とり、交信して
ゆくなどの実装が可能である。項目Ｄ２３は、送信元ポ
ート番号を表し、項目Ｄ２４は、宛先ポート番号を表
す。項目Ｄ２７は、送信元および宛先におけるそれぞれ
の最新の送信ウィンドウサイズおよび受信ウィンドウサ
イズを表す。項目Ｄ２８は、現在管理している通信に割
り当てられている仮ＡＣＫを利用したセグメント保存用
のバッファの総量を示し（Byte単位）、項目Ｄ２９は、
割り当て可能な仮ＡＣＫを利用したセグメント保存用の
バッファ残量を示し、この例では、仮ＡＣＫを利用した
セグメント保存用のバッファの総量を「５Ｇ」としてい
るため、残量は（５−２．８）＝２．２Ｇとなる。項目
Ｄ３０は、現在使用中の仮ＡＣＫを利用したセグメント
保存用のバッファの総量を表す。
一意に識別するための受付番号（通信ＩＤ）である。項
目Ｄ１２は、この通信に割り当てられたｔｍｐＡＣＫ作
成対象セグメントを保存するための割当バッファ量を表
すものである。項目Ｄ１３は、この通信が実際にｔｍｐ
ＡＣＫ作成対象セグメントの保存のために使用している
使用バッファ量を示している。項目Ｄ１４は、管理する
通信の送信元ＩＰアドレスを表すものである。項目Ｄ１
５は、送信元優先度を表し、この優先度は例えば、
「１」、「２」、「３」、・・・のような整数値で表さ
れ、数値の高いほど優先度が高い送信元であるという実
装が可能である。項目Ｄ１６は、宛先ＩＰアドレスを表
す。項目Ｄ１７は、宛先優先度を表す。この優先度は例
えば、「１」、「２」、「３」、・・・のような整数値
で表され、数値の高いほど優先度が高い送信元であると
いう実装が可能である。項目Ｄ１８は、送信元スループ
ットであり、ここには通信開始時にはデフォルト値とし
て、経路管理テーブル８を参照し、当該通信における送
信元のデフォルトのスループットを入れ、以後、一定間
隔ごとにスループットの実測値を計り更新する。通信終
了時に、経路管理テーブル８のデフォルトのスループッ
トの値も、実測値を元に再計算し更新することも可能で
ある。項目Ｄ１９は、通信の優先度フラグであり、これ
は例えばＴＣＰセグメントの緊急フラグが「ＯＮ」であ
れば、「ＯＮ」とするという実装が可能である。項目Ｄ
２０は、仮ＡＣＫ送信待ちによる速度調節に関する情報
であり、仮ＡＣＫ送信待ちによる速度調節機能を用いる
か否かに関するフラグ、および当該フラグが「ＯＮ」の
場合はその調節のための待ち時間を示す値を入れる項目
であり、項目Ｄ２１は、Ｗｉｎｄｏｗサイズ情報による
速度調節機能に関する情報を入れる項目であり、この機
能を用いるか否かに関するフラグおよびこのフラグが
「ＯＮ」の場合はどのくらいＷｉｎｄｏｗサイズを調節
するかを示す値を入れる項目である。項目Ｄ２２は、デ
ータ配信管理装置１０と宛先との間の往復時間（Round
Trip Time：ＲＴＴ）を表す値であり、デフォルト値は
経路管理テーブル８の「遅延」情報に書いてある値の２
倍の数値を入れ、通信において値を適宜とり、交信して
ゆくなどの実装が可能である。項目Ｄ２３は、送信元ポ
ート番号を表し、項目Ｄ２４は、宛先ポート番号を表
す。項目Ｄ２７は、送信元および宛先におけるそれぞれ
の最新の送信ウィンドウサイズおよび受信ウィンドウサ
イズを表す。項目Ｄ２８は、現在管理している通信に割
り当てられている仮ＡＣＫを利用したセグメント保存用
のバッファの総量を示し（Byte単位）、項目Ｄ２９は、
割り当て可能な仮ＡＣＫを利用したセグメント保存用の
バッファ残量を示し、この例では、仮ＡＣＫを利用した
セグメント保存用のバッファの総量を「５Ｇ」としてい
るため、残量は（５−２．８）＝２．２Ｇとなる。項目
Ｄ３０は、現在使用中の仮ＡＣＫを利用したセグメント
保存用のバッファの総量を表す。
【００６７】更に、図７において、項目Ｄ３１は、個々
の通信においてデータ配信管理装置１０が受信したセグ
メントのシーケンス番号を表し、項目Ｄ３２は、ｔｍｐ
ＡＣＫ送信に関する情報を表し、これは送信元に対して
一定の条件が整った時などの条件付の場合を含め送信可
能なセグメントか否かの情報およびｔｍｐＡＣＫを送信
したか否かの情報などを値として用いるものである。項
目Ｄ３３は、宛先からの送達確認応答（ＲＲＡＣＫ）に
対する情報を表すものであり、この例では対応するセグ
メントがＲＲＡＣＫを受信済であることを表すＡＣＫ受
信済およびＲＲＡＣＫの到達を待っている状態である事
を表すＡＣＫ待ちの２つの値を持つものである。
の通信においてデータ配信管理装置１０が受信したセグ
メントのシーケンス番号を表し、項目Ｄ３２は、ｔｍｐ
ＡＣＫ送信に関する情報を表し、これは送信元に対して
一定の条件が整った時などの条件付の場合を含め送信可
能なセグメントか否かの情報およびｔｍｐＡＣＫを送信
したか否かの情報などを値として用いるものである。項
目Ｄ３３は、宛先からの送達確認応答（ＲＲＡＣＫ）に
対する情報を表すものであり、この例では対応するセグ
メントがＲＲＡＣＫを受信済であることを表すＡＣＫ受
信済およびＲＲＡＣＫの到達を待っている状態である事
を表すＡＣＫ待ちの２つの値を持つものである。
【００６８】図７は、図６の項目Ｄ２７の右列に加え、
一つのテーブルとする事も可能であるが、スペースの都
合上、項目Ｄ１１によって関連付けられる二つの表とし
た。従って、例えば項目Ｄ２５で示される一群の行は、
通信ＩＤとして「１」を持ち、仮ＡＣＫを用いたセグメ
ントを保存するために８００Ｍbyteまでの大きさのバッ
ファを割り当てられ、当該バッファのうち現時点で７５
０ＭByteのバッファを使用しており、優先度が「１」の
送信元マシン「10.74.3.135」の送信ポート 「FTP.DAT
A」から０．６５Ｍbpsのスループットで、優先度が
「１」の宛先マシン「10.74.3.200」の宛先ポート「130
1」に対する通信において、通信の優先度フラグが「Ｏ
Ｎ」であり、仮ＡＣＫ送信待ちによる速度調節利用フラ
グが「ＯＮ」であり、Ｗｉｎｄｏｗサイズ情報による速
度調節利用フラグが「ＯＮ」であり、データ配信管理装
置と宛先との間のＲＴＴが５４３msecである通信におい
て、送信元の送信ウィンドウサイズおよび受信ウィンド
ウサイズ、および宛先の送信ウィンドウサイズおよび受
信ウィンドウサイズは全て１６Kバイトであり、シーケ
ンス番号「398」を持つセグメントは、ｔｍｐＡＣＫの
送信は不可、即ちいかなる条件になった場合もｔｍｐＡ
ＣＫの送信を行わないセグメントであり、現時点で宛先
からの送達確認応答を待っている状態であることを表す
ものである。これらの項目および必要に応じて追加する
項目を用いて、セグメントのｔｍｐＡＣＫの管理、受信
確認および結果に応じた再送の制御、送信元へのｔｍｐ
ＡＣＫおよびＲＲＡＣＫ（宛先からの送達確認応答）の
送信速度の制御、宛先への転送速度の制御、データ配信
管理装置１０の送受信バッファの管理を行う事ができ
る。
一つのテーブルとする事も可能であるが、スペースの都
合上、項目Ｄ１１によって関連付けられる二つの表とし
た。従って、例えば項目Ｄ２５で示される一群の行は、
通信ＩＤとして「１」を持ち、仮ＡＣＫを用いたセグメ
ントを保存するために８００Ｍbyteまでの大きさのバッ
ファを割り当てられ、当該バッファのうち現時点で７５
０ＭByteのバッファを使用しており、優先度が「１」の
送信元マシン「10.74.3.135」の送信ポート 「FTP.DAT
A」から０．６５Ｍbpsのスループットで、優先度が
「１」の宛先マシン「10.74.3.200」の宛先ポート「130
1」に対する通信において、通信の優先度フラグが「Ｏ
Ｎ」であり、仮ＡＣＫ送信待ちによる速度調節利用フラ
グが「ＯＮ」であり、Ｗｉｎｄｏｗサイズ情報による速
度調節利用フラグが「ＯＮ」であり、データ配信管理装
置と宛先との間のＲＴＴが５４３msecである通信におい
て、送信元の送信ウィンドウサイズおよび受信ウィンド
ウサイズ、および宛先の送信ウィンドウサイズおよび受
信ウィンドウサイズは全て１６Kバイトであり、シーケ
ンス番号「398」を持つセグメントは、ｔｍｐＡＣＫの
送信は不可、即ちいかなる条件になった場合もｔｍｐＡ
ＣＫの送信を行わないセグメントであり、現時点で宛先
からの送達確認応答を待っている状態であることを表す
ものである。これらの項目および必要に応じて追加する
項目を用いて、セグメントのｔｍｐＡＣＫの管理、受信
確認および結果に応じた再送の制御、送信元へのｔｍｐ
ＡＣＫおよびＲＲＡＣＫ（宛先からの送達確認応答）の
送信速度の制御、宛先への転送速度の制御、データ配信
管理装置１０の送受信バッファの管理を行う事ができ
る。
【００６９】このような配信管理テーブル１を用いて、
データ配信管理装置１０は、受信したセグメントのＩＰ
ヘッダにある送信元ＩＰアドレスおよび宛先ＩＰアドレ
ス、およびＴＣＰヘッダにある送信元ポート番号および
宛先ポート番号を参照し、ＩＰヘッダ中の送信元ＩＰと
ＴＣＰヘッダ中の送信元ポートの組み合わせ、および宛
先ＩＰと宛先ポートの組み合わせで表される通信が配信
管理テーブル１上にあるか否かの判定を行う。判定の結
果、配信管理テーブル１上に登録されている通信であっ
たと判定された場合（ステップＳ２６，ＹＥＳ）、ステ
ップＳ３２に移行し、受信したセグメントが、宛先の受
信Ｗｉｎｄｏｗ内のセグメントであるか否かを判定し
（ステップＳ３２）、宛先の受信Ｗｉｎｄｏｗ内のセグ
メントであった場合（ステップＳ３２，ＹＥＳ）、ステ
ップＳ３３に移行し、ＦＩＮフラグをチェックし、最終
パケット（通信終了パケット）であるか否かを判定し、
通信終了ではなかった場合はステップＳ３４に移行す
る。
データ配信管理装置１０は、受信したセグメントのＩＰ
ヘッダにある送信元ＩＰアドレスおよび宛先ＩＰアドレ
ス、およびＴＣＰヘッダにある送信元ポート番号および
宛先ポート番号を参照し、ＩＰヘッダ中の送信元ＩＰと
ＴＣＰヘッダ中の送信元ポートの組み合わせ、および宛
先ＩＰと宛先ポートの組み合わせで表される通信が配信
管理テーブル１上にあるか否かの判定を行う。判定の結
果、配信管理テーブル１上に登録されている通信であっ
たと判定された場合（ステップＳ２６，ＹＥＳ）、ステ
ップＳ３２に移行し、受信したセグメントが、宛先の受
信Ｗｉｎｄｏｗ内のセグメントであるか否かを判定し
（ステップＳ３２）、宛先の受信Ｗｉｎｄｏｗ内のセグ
メントであった場合（ステップＳ３２，ＹＥＳ）、ステ
ップＳ３３に移行し、ＦＩＮフラグをチェックし、最終
パケット（通信終了パケット）であるか否かを判定し、
通信終了ではなかった場合はステップＳ３４に移行す
る。
【００７０】ステップＳ２６において、配信管理テーブ
ル１上に登録されている通信ではないと判定された場
合、ｔｍｐＡＣＫ利用制御フラグを「ＯＦＦ」にし（ス
テップＳ２２）、受信セグメントを宛先に転送し（ステ
ップＳ２３）、本処理を終了する。
ル１上に登録されている通信ではないと判定された場
合、ｔｍｐＡＣＫ利用制御フラグを「ＯＦＦ」にし（ス
テップＳ２２）、受信セグメントを宛先に転送し（ステ
ップＳ２３）、本処理を終了する。
【００７１】ステップＳ３３において、通信終了セグメ
ントであった場合、受信したセグメントのエントリを登
録し、同一通信内のセグメントのエントリでｔｍｐＡＣ
Ｋ利用可能となっており、かつ、ｔｍｐＡＣＫ送信済で
ないものを全てｔｍｐＡＣＫ利用不可とし、データ配信
管理装置１０のｔｍｐＡＣＫ利用可能フラグを「ＯＦ
Ｆ」にし、ＦＩＮ受信済フラグを「ＯＮ」にし（ステッ
プＳ３５）、受信セグメントを宛先に転送し（ステップ
Ｓ２３）、本処理を終了する。
ントであった場合、受信したセグメントのエントリを登
録し、同一通信内のセグメントのエントリでｔｍｐＡＣ
Ｋ利用可能となっており、かつ、ｔｍｐＡＣＫ送信済で
ないものを全てｔｍｐＡＣＫ利用不可とし、データ配信
管理装置１０のｔｍｐＡＣＫ利用可能フラグを「ＯＦ
Ｆ」にし、ＦＩＮ受信済フラグを「ＯＮ」にし（ステッ
プＳ３５）、受信セグメントを宛先に転送し（ステップ
Ｓ２３）、本処理を終了する。
【００７２】ステップＳ３４において、送信元の送信Ｗ
ｉｎｄｏｗサイズを確認し、スロースタートであるか否
かを判定し、スロースタートであった場合（ステップＳ
３４，ＹＥＳ）、ｔｍｐＡＣＫ利用可能フラグを「ＯＦ
Ｆ」にした（ステップＳ３６）後、受信セグメントを宛
先に転送し（ステップＳ２３）、本処理を終了する。
ｉｎｄｏｗサイズを確認し、スロースタートであるか否
かを判定し、スロースタートであった場合（ステップＳ
３４，ＹＥＳ）、ｔｍｐＡＣＫ利用可能フラグを「ＯＦ
Ｆ」にした（ステップＳ３６）後、受信セグメントを宛
先に転送し（ステップＳ２３）、本処理を終了する。
【００７３】一方、ステップＳ３４において、スロース
タートと判定された場合、受信したセグメントが宛先か
らの送達確認応答か否かを判定し（ステップＳ３７）、
宛先からの送達確認応答であった場合（ステップＳ３
７，ＹＥＳ）、ｔｍｐＡＣＫバッファ４に、受信したセ
グメントを保存し、データ配信管理装置１０のＳＧ配信
管理部１６の配信確認処理（図１０）に、受信装置Ｃ２
から送達確認応答を受信したことを通知するイベントを
発生させ、ｔｍｐＡＣＫ利用可能フラグを「ＯＮ」にセ
ットし（ステップＳ３８）、本処理を終了する。
タートと判定された場合、受信したセグメントが宛先か
らの送達確認応答か否かを判定し（ステップＳ３７）、
宛先からの送達確認応答であった場合（ステップＳ３
７，ＹＥＳ）、ｔｍｐＡＣＫバッファ４に、受信したセ
グメントを保存し、データ配信管理装置１０のＳＧ配信
管理部１６の配信確認処理（図１０）に、受信装置Ｃ２
から送達確認応答を受信したことを通知するイベントを
発生させ、ｔｍｐＡＣＫ利用可能フラグを「ＯＮ」にセ
ットし（ステップＳ３８）、本処理を終了する。
【００７４】ステップＳ３７において、受信したセグメ
ントが、宛先からの送達確認応答ではないと判定された
場合、バッファの空き具合に応じて仮ＡＣＫを作成送信
する処理を行うか否かを定め、さらにその仮ＡＣＫ作成
に伴う処理を行う（ステップＳ３９）。この処理の詳細
については、図８および図９を参照して後述する。その
後、受信セグメントを宛先に転送し（ステップＳ２
３）、本処理を終了する。
ントが、宛先からの送達確認応答ではないと判定された
場合、バッファの空き具合に応じて仮ＡＣＫを作成送信
する処理を行うか否かを定め、さらにその仮ＡＣＫ作成
に伴う処理を行う（ステップＳ３９）。この処理の詳細
については、図８および図９を参照して後述する。その
後、受信セグメントを宛先に転送し（ステップＳ２
３）、本処理を終了する。
【００７５】一方、ステップＳ２５において、通信開始
セグメントであると判定された場合、判定を行っている
セグメントを含めて、通信開始セグメントが通信の手順
とおりに正しく送受信されているか否かの判定を行う
（ステップＳ２８）。一連の作業により、通信開始セグ
メントは正しい順序で、到達された事を確認されたもの
のみ、ステップＳ２９においてバッファのチェック処理
を行う。
セグメントであると判定された場合、判定を行っている
セグメントを含めて、通信開始セグメントが通信の手順
とおりに正しく送受信されているか否かの判定を行う
（ステップＳ２８）。一連の作業により、通信開始セグ
メントは正しい順序で、到達された事を確認されたもの
のみ、ステップＳ２９においてバッファのチェック処理
を行う。
【００７６】ステップＳ２９のバッファチェックは、通
信開始セグメントの送信元および宛先情報を取り出し、
経路管理テーブル８および配信管理テーブル１の情報を
用いて、送信元からのスループット、ルータ−宛先間の
遅延情報によって、必要なバッファの容量、およびバッ
ファの空き具合のチェックを行い、バッファが十分か否
かの判定を行う。この十分か否かの判定は、（バッファ
総量）−（現在使っているバッファ量）−（新規の通信
に必要と予測されたバッファ量）＝（残っているバッフ
ァ量）−（新規の通信に必要と予測されたバッファ量）
＞（データ配信管理装置１０が予め持っている余裕度を
示すバッファ量）、との条件を満たすか否かで行う。
信開始セグメントの送信元および宛先情報を取り出し、
経路管理テーブル８および配信管理テーブル１の情報を
用いて、送信元からのスループット、ルータ−宛先間の
遅延情報によって、必要なバッファの容量、およびバッ
ファの空き具合のチェックを行い、バッファが十分か否
かの判定を行う。この十分か否かの判定は、（バッファ
総量）−（現在使っているバッファ量）−（新規の通信
に必要と予測されたバッファ量）＝（残っているバッフ
ァ量）−（新規の通信に必要と予測されたバッファ量）
＞（データ配信管理装置１０が予め持っている余裕度を
示すバッファ量）、との条件を満たすか否かで行う。
【００７７】さらに、この時、バッファの空き容量が十
分ではないと判定された場合、送信元、宛先、およびパ
ケットの緊急フラグを見て、優先するべき通信か否かを
判定し、優先するべき通信であると判定した場合は、た
とえ、十分なバッファ容量がない場合も、割当可能フラ
グを立て、代わりに、緊急度に応じて他の優先度を下げ
るべき通信のバッファ容量の調節フラグを「ＯＮ」に割
り当てるバッファ容量の再計算を行い配信管理テーブル
１に記載する、ｔｍｐＡＣＫ利用可能フラグを「ＯＦ
Ｆ」にする、仮ＡＣＫ送信待ちによる速度調節フラグを
「ＯＮ」にし、仮ＡＣＫ送信待ち時間を計算し、配信管
理テーブル１に記載する、Ｗｉｎｄｏｗ情報による速度
調節フラグを「ＯＮ」にし、速度調節のためのＷｉｎｄ
ｏｗ情報を計算し、配信管理テーブル１に記載する、な
どの対策を行う。これらのフラグを立てる組み合わせ
は、通信毎の通信の優先度の開きとバッファの空き容量
とからなる管理テーブルを用いるなどの実装が可能であ
る。速度調節用仮ACK送信待ち時間とは、速度調節のた
めに一定時間待ってから仮ＡＣＫを作成および送信する
ことで、データ配信管理装置１０の処理およびデータ配
信管理装置１０と送信装置Ｃ１との間のフローの削減を
促すことを目的とする。例えば、仮ＡＣＫ送信待ちによ
る速度調節利用フラグが「ＯＮ」であった場合、各々の
通信毎のタイマをデータ配信管理装置１０が持ち、指定
された時間毎にフラグを「ＯＮ」にし、仮ＡＣＫを送信
した時点でフラグを「ＯＦＦ」にし、再びカウントを開
始するという実装が考えられる。このバッファ割当可能
フラグは、バッファ割当部６ａが持ち、この一連のステ
ップＳ２９の処理は、バッファ割当部６ａが行うもので
ある。
分ではないと判定された場合、送信元、宛先、およびパ
ケットの緊急フラグを見て、優先するべき通信か否かを
判定し、優先するべき通信であると判定した場合は、た
とえ、十分なバッファ容量がない場合も、割当可能フラ
グを立て、代わりに、緊急度に応じて他の優先度を下げ
るべき通信のバッファ容量の調節フラグを「ＯＮ」に割
り当てるバッファ容量の再計算を行い配信管理テーブル
１に記載する、ｔｍｐＡＣＫ利用可能フラグを「ＯＦ
Ｆ」にする、仮ＡＣＫ送信待ちによる速度調節フラグを
「ＯＮ」にし、仮ＡＣＫ送信待ち時間を計算し、配信管
理テーブル１に記載する、Ｗｉｎｄｏｗ情報による速度
調節フラグを「ＯＮ」にし、速度調節のためのＷｉｎｄ
ｏｗ情報を計算し、配信管理テーブル１に記載する、な
どの対策を行う。これらのフラグを立てる組み合わせ
は、通信毎の通信の優先度の開きとバッファの空き容量
とからなる管理テーブルを用いるなどの実装が可能であ
る。速度調節用仮ACK送信待ち時間とは、速度調節のた
めに一定時間待ってから仮ＡＣＫを作成および送信する
ことで、データ配信管理装置１０の処理およびデータ配
信管理装置１０と送信装置Ｃ１との間のフローの削減を
促すことを目的とする。例えば、仮ＡＣＫ送信待ちによ
る速度調節利用フラグが「ＯＮ」であった場合、各々の
通信毎のタイマをデータ配信管理装置１０が持ち、指定
された時間毎にフラグを「ＯＮ」にし、仮ＡＣＫを送信
した時点でフラグを「ＯＦＦ」にし、再びカウントを開
始するという実装が考えられる。このバッファ割当可能
フラグは、バッファ割当部６ａが持ち、この一連のステ
ップＳ２９の処理は、バッファ割当部６ａが行うもので
ある。
【００７８】ステップＳ２９の処理の後、バッファ割当
フラグを見て、バッファ割当が可能か否かの判定を行い
（ステップＳ３０）、可能でない場合はステップＳ２２
に移行する。一方、ステップＳ３０において、バッファ
割当可能との判断をされた場合、送信管理テーブル１に
エントリを追加する（ステップＳ３１）。このステップ
Ｓ３１の処理後、受信したセグメントが宛先からの送達
確認応答か否かを判定し（ステップＳ４０）、宛先から
の送達確認応答であると判定された場合は、ステップＳ
３８の処理を行った後、本処理を終了する。一方、宛先
からの送達確認応答ではないと判定された場合（ステッ
プＳ４０，ＮＯ）には、ｔｍｐＡＣＫ利用可能フラグを
「ＯＦＦ」にし（ステップＳ４１）、受信セグメントを
宛先に転送した（ステップＳ２３）後、本処理を終了す
る。
フラグを見て、バッファ割当が可能か否かの判定を行い
（ステップＳ３０）、可能でない場合はステップＳ２２
に移行する。一方、ステップＳ３０において、バッファ
割当可能との判断をされた場合、送信管理テーブル１に
エントリを追加する（ステップＳ３１）。このステップ
Ｓ３１の処理後、受信したセグメントが宛先からの送達
確認応答か否かを判定し（ステップＳ４０）、宛先から
の送達確認応答であると判定された場合は、ステップＳ
３８の処理を行った後、本処理を終了する。一方、宛先
からの送達確認応答ではないと判定された場合（ステッ
プＳ４０，ＮＯ）には、ｔｍｐＡＣＫ利用可能フラグを
「ＯＦＦ」にし（ステップＳ４１）、受信セグメントを
宛先に転送した（ステップＳ２３）後、本処理を終了す
る。
【００７９】一方、ステップＳ２８において、データ配
信管理装置１０が正しい順序で通信開始セグメントを受
信していないと判定された場合、データ配信管理装置１
０のｔｍｐＡＣＫ利用可能フラグを「ＯＦＦ」にし（ス
テップＳ２２）、受信セグメントを宛先に転送する（ス
テップＳ２３）。この時、宛先の送信管理テーブル１お
よび経路管理テーブル８を参照し、送信管理テーブル１
に載っている通信のパケットに対しては、宛先の受信装
置Ｃ２の受信Ｗｉｎｄｏｗサイズおよびデータ配信管理
装置１０と宛先との間のスループットに応じて、転送速
度の調節を行う。ステップＳ２３の処理後、一連の処理
を終了する。
信管理装置１０が正しい順序で通信開始セグメントを受
信していないと判定された場合、データ配信管理装置１
０のｔｍｐＡＣＫ利用可能フラグを「ＯＦＦ」にし（ス
テップＳ２２）、受信セグメントを宛先に転送する（ス
テップＳ２３）。この時、宛先の送信管理テーブル１お
よび経路管理テーブル８を参照し、送信管理テーブル１
に載っている通信のパケットに対しては、宛先の受信装
置Ｃ２の受信Ｗｉｎｄｏｗサイズおよびデータ配信管理
装置１０と宛先との間のスループットに応じて、転送速
度の調節を行う。ステップＳ２３の処理後、一連の処理
を終了する。
【００８０】つぎに、図８に示すフローチャートを参照
して、ステップＳ３９に対応するｔｍｐＡＣＫ作成送信
待ちによる速度調節処理について説明する。まず、ステ
ップＳ３９の処理は、バッファの空き具合に応じて仮Ａ
ＣＫを作成送信する処理を行うか否かを定め、さらにそ
の仮ＡＣＫ作成に伴う処理を表す。これらの処理は、送
信元である送信装置Ｃ１から受信し、データ配信管理装
置１０において、受信装置Ｃ２に転送するとともに、ｔ
ｍｐＡＣＫ作成および送信を行い、このｔｍｐＡＣＫ作
成および送信処理(ｔｍｐＡＣＫ処理)対象となったデー
タセグメントを一時的に保持すると同時に、該データセ
グメントを一時的に保持するためのバッファの容量に関
する調節を行うものである。
して、ステップＳ３９に対応するｔｍｐＡＣＫ作成送信
待ちによる速度調節処理について説明する。まず、ステ
ップＳ３９の処理は、バッファの空き具合に応じて仮Ａ
ＣＫを作成送信する処理を行うか否かを定め、さらにそ
の仮ＡＣＫ作成に伴う処理を表す。これらの処理は、送
信元である送信装置Ｃ１から受信し、データ配信管理装
置１０において、受信装置Ｃ２に転送するとともに、ｔ
ｍｐＡＣＫ作成および送信を行い、このｔｍｐＡＣＫ作
成および送信処理(ｔｍｐＡＣＫ処理)対象となったデー
タセグメントを一時的に保持すると同時に、該データセ
グメントを一時的に保持するためのバッファの容量に関
する調節を行うものである。
【００８１】ここで、図１０は、このバッファの容量の
調節の仕組みを示す模式図である。図１０において、各
バッファＢ１〜Ｂ３は、上述したｔｍｐＡＣＫ処理を行
ったデータセグメントを一時的に保存するためのバッフ
ァ全体を示している。バッファＢ１，Ｂ２は、データ配
信管理装置１０が現在管理している通信のうち、ｔｍｐ
ＡＣＫ処理を含む通信（通信「１」，「２」）に割り当
てられたバッファであり、バッファＢ３は、通信
「１」，「２」および今後新たに管理する通信のための
予備的なバッファである。
調節の仕組みを示す模式図である。図１０において、各
バッファＢ１〜Ｂ３は、上述したｔｍｐＡＣＫ処理を行
ったデータセグメントを一時的に保存するためのバッフ
ァ全体を示している。バッファＢ１，Ｂ２は、データ配
信管理装置１０が現在管理している通信のうち、ｔｍｐ
ＡＣＫ処理を含む通信（通信「１」，「２」）に割り当
てられたバッファであり、バッファＢ３は、通信
「１」，「２」および今後新たに管理する通信のための
予備的なバッファである。
【００８２】通信「１」用のバッファＢ１が足りなくな
った、あるいは足りなくなりつつあるとの判定が出され
た場合、予備的なバッファＢ３から、必要量Ｂ３ａを算
出し、その分を、通信「１」に追加し、バッファＢ１に
割り当てている。
った、あるいは足りなくなりつつあるとの判定が出され
た場合、予備的なバッファＢ３から、必要量Ｂ３ａを算
出し、その分を、通信「１」に追加し、バッファＢ１に
割り当てている。
【００８３】さて、図８において、最初に、バッファの
チェックを行う（ステップＳ５１）。このバッファチェ
ック処理では、開始通知以外のデータセグメントを受信
した場合に行うものであり（開始通知の場合は、ステッ
プＳ２９によって処理される）、このセグメントの送信
元および宛先情報を取り出し、経路管理テーブル８およ
び配信管理テーブル１の情報を用いて、送信元からのス
ループット、ルータ−宛先間の遅延情報によって、必要
なバッファの容量、およびバッファの空き具合のチェッ
クを行い、バッファが十分か否かの判定を行う。この十
分かどうかの判定は、（バッファ総量）−（現在使って
いるバッファ量）＝（残っているバッファ量）＞（デー
タ配信管理装置１０が予め持っている余裕度を示すバッ
ファ量）、との条件を満たすか否かで行う。さらに、こ
の時、バッファの空き容量が十分ではないと判定された
場合、送信元、宛先、およびパケットの緊急フラグを見
て、優先するべき通信か否かを判定し、優先するべき通
信であると判定した場合は、たとえ、十分なバッファ容
量がない場合も、バッファ容量の調節フラグをオフに
し、代わりに、緊急度に応じて他の優先度を下げるべき
通信のバッファ容量の調節フラグを「ＯＮ」に割り当て
るバッファ容量の再計算を行い、配信管理テーブル１に
記載する、ｔｍｐＡＣＫ利用可能フラグを「ＯＦＦ」に
する、仮ＡＣＫ送信待ちによる速度調節フラグを「Ｏ
Ｎ」にし、仮ＡＣＫ送信待ち時間を計算し、配信管理テ
ーブル１に記載する、Ｗｉｎｄｏｗ情報による速度調節
フラグを「ＯＮ」にし、速度調節のためのＷｉｎｄｏｗ
情報を計算し、配信管理テーブル１に記載する、などの
対策を行う。これらのフラグを立てる組み合わせは、通
信毎の通信の優先度の開きとバッファの空き容量とから
なる管理テーブルを用いるなどの実装が可能である。ま
た、逆に、十分なバッファ量があるとの判定がされた場
合、速度調節用のフラグおよびバッファ容量の調節フラ
グの少なくとも一つが「ＯＮ」になっている通信があっ
た場合（複数の場合は通信の優先度も考慮し）、その通
信に対し提供可能なバッファ容量を再計算し、割り当て
可能なバッファ容量の値を更新する、あるいはバッファ
容量調節フラグを「ＯＦＦ」にする、ｔｍｐＡＣＫ利用
可能フラグを「ＯＮ」にし、配信管理テーブル１に記載
する、仮ＡＣＫ送信待ちによる速度調節フラグが「Ｏ
Ｎ」の場合は、速度調節のための待ち時間を再計算し、
待ち時間を短縮する、あるいは仮ＡＣＫ送信待ちによる
速度調節フラグを「ＯＦＦ」にし、配信管理テーブル１
に記載する、Ｗｉｎｄｏｗ情報による速度調節フラグが
「ＯＮ」の場合は、速度調節のためのＷｉｎｄｏｗ情報
値を再計算し、Ｗｉｎｄｏｗ情報を増加させる、あるい
はＷｉｎｄｏｗ情報による速度調節フラグを「ＯＦＦ」
にし、配信管理テーブル１に記載する、などの対策を行
う。
チェックを行う（ステップＳ５１）。このバッファチェ
ック処理では、開始通知以外のデータセグメントを受信
した場合に行うものであり（開始通知の場合は、ステッ
プＳ２９によって処理される）、このセグメントの送信
元および宛先情報を取り出し、経路管理テーブル８およ
び配信管理テーブル１の情報を用いて、送信元からのス
ループット、ルータ−宛先間の遅延情報によって、必要
なバッファの容量、およびバッファの空き具合のチェッ
クを行い、バッファが十分か否かの判定を行う。この十
分かどうかの判定は、（バッファ総量）−（現在使って
いるバッファ量）＝（残っているバッファ量）＞（デー
タ配信管理装置１０が予め持っている余裕度を示すバッ
ファ量）、との条件を満たすか否かで行う。さらに、こ
の時、バッファの空き容量が十分ではないと判定された
場合、送信元、宛先、およびパケットの緊急フラグを見
て、優先するべき通信か否かを判定し、優先するべき通
信であると判定した場合は、たとえ、十分なバッファ容
量がない場合も、バッファ容量の調節フラグをオフに
し、代わりに、緊急度に応じて他の優先度を下げるべき
通信のバッファ容量の調節フラグを「ＯＮ」に割り当て
るバッファ容量の再計算を行い、配信管理テーブル１に
記載する、ｔｍｐＡＣＫ利用可能フラグを「ＯＦＦ」に
する、仮ＡＣＫ送信待ちによる速度調節フラグを「Ｏ
Ｎ」にし、仮ＡＣＫ送信待ち時間を計算し、配信管理テ
ーブル１に記載する、Ｗｉｎｄｏｗ情報による速度調節
フラグを「ＯＮ」にし、速度調節のためのＷｉｎｄｏｗ
情報を計算し、配信管理テーブル１に記載する、などの
対策を行う。これらのフラグを立てる組み合わせは、通
信毎の通信の優先度の開きとバッファの空き容量とから
なる管理テーブルを用いるなどの実装が可能である。ま
た、逆に、十分なバッファ量があるとの判定がされた場
合、速度調節用のフラグおよびバッファ容量の調節フラ
グの少なくとも一つが「ＯＮ」になっている通信があっ
た場合（複数の場合は通信の優先度も考慮し）、その通
信に対し提供可能なバッファ容量を再計算し、割り当て
可能なバッファ容量の値を更新する、あるいはバッファ
容量調節フラグを「ＯＦＦ」にする、ｔｍｐＡＣＫ利用
可能フラグを「ＯＮ」にし、配信管理テーブル１に記載
する、仮ＡＣＫ送信待ちによる速度調節フラグが「Ｏ
Ｎ」の場合は、速度調節のための待ち時間を再計算し、
待ち時間を短縮する、あるいは仮ＡＣＫ送信待ちによる
速度調節フラグを「ＯＦＦ」にし、配信管理テーブル１
に記載する、Ｗｉｎｄｏｗ情報による速度調節フラグが
「ＯＮ」の場合は、速度調節のためのＷｉｎｄｏｗ情報
値を再計算し、Ｗｉｎｄｏｗ情報を増加させる、あるい
はＷｉｎｄｏｗ情報による速度調節フラグを「ＯＦＦ」
にし、配信管理テーブル１に記載する、などの対策を行
う。
【００８４】その後、バッファ容量の調節フラグを見
て、「ＯＮ」の場合（ステップＳ５２，ＹＥＳ）、ステ
ップＳ５３に移行し、「ＯＦＦ」の場合（ステップＳ５
２，ＮＯ）、配信管理テーブル１に情報を登録し、ｔｍ
ｐＡＣＫ利用可能フラグを「ＯＮ」に設定する（ステッ
プＳ５４）。この際、最新のセグメント到着時点におけ
る情報として、配信管理テーブル１の個々のセグメント
に関する情報のエントリ毎にｔｍｐＡＣＫ利用可能かど
うかの情報を設定する。なお、ｔｍｐＡＣＫ利用可能フ
ラグを「ＯＮ」にしたセグメントは、バッファに保存す
る。
て、「ＯＮ」の場合（ステップＳ５２，ＹＥＳ）、ステ
ップＳ５３に移行し、「ＯＦＦ」の場合（ステップＳ５
２，ＮＯ）、配信管理テーブル１に情報を登録し、ｔｍ
ｐＡＣＫ利用可能フラグを「ＯＮ」に設定する（ステッ
プＳ５４）。この際、最新のセグメント到着時点におけ
る情報として、配信管理テーブル１の個々のセグメント
に関する情報のエントリ毎にｔｍｐＡＣＫ利用可能かど
うかの情報を設定する。なお、ｔｍｐＡＣＫ利用可能フ
ラグを「ＯＮ」にしたセグメントは、バッファに保存す
る。
【００８５】一方、バッファ容量の調節フラグを見て、
「ＯＮ」の場合、仮ＡＣＫフラグが「ＯＮ」か否か（ス
テップＳ５１によって決定される、ｔｍｐＡＣＫ利用可
能フラグが「ＯＮ」か否か）を判定し（ステップＳ５
３）、「ＯＦＦ」であった場合、配信管理テーブル１に
パケットに関する情報、すなわちパケット番号、ｔｍｐ
ＡＣＫ送信を「不可」、ＲＲＡＣＫ状態に「ACK待ち」
を追加し、ｔｍｐＡＣＫ利用可能フラグを「ＯＦＦ」に
し（ステップＳ５５）、本処理を終了する。
「ＯＮ」の場合、仮ＡＣＫフラグが「ＯＮ」か否か（ス
テップＳ５１によって決定される、ｔｍｐＡＣＫ利用可
能フラグが「ＯＮ」か否か）を判定し（ステップＳ５
３）、「ＯＦＦ」であった場合、配信管理テーブル１に
パケットに関する情報、すなわちパケット番号、ｔｍｐ
ＡＣＫ送信を「不可」、ＲＲＡＣＫ状態に「ACK待ち」
を追加し、ｔｍｐＡＣＫ利用可能フラグを「ＯＦＦ」に
し（ステップＳ５５）、本処理を終了する。
【００８６】一方、ステップＳ５３において、仮ＡＣＫ
フラグが「ＯＮ」であると判定された場合、仮ＡＣＫの
作成および送信に関する処理を行い（ステップＳ５
６）、本処理を終了する。ステップＳ５６の処理の詳細
については、図９に示すフローチャートを参照して後述
する。
フラグが「ＯＮ」であると判定された場合、仮ＡＣＫの
作成および送信に関する処理を行い（ステップＳ５
６）、本処理を終了する。ステップＳ５６の処理の詳細
については、図９に示すフローチャートを参照して後述
する。
【００８７】図９は、ステップＳ５６に対応し、仮ＡＣ
Ｋ作成送信処理の手順を示すフローチャートである。図
９において、まず、図３に示した一連の処理によって設
定したＦＩＮ受信済フラグの値を参照し、通信終了セグ
メントが受信済か否かの判定を行う（ステップＳ６
１）。ＦＩＮ受信済と判定された場合（ステップＳ６
１，ＹＥＳ）、なにも行わず本処理を終了してリターン
する。
Ｋ作成送信処理の手順を示すフローチャートである。図
９において、まず、図３に示した一連の処理によって設
定したＦＩＮ受信済フラグの値を参照し、通信終了セグ
メントが受信済か否かの判定を行う（ステップＳ６
１）。ＦＩＮ受信済と判定された場合（ステップＳ６
１，ＹＥＳ）、なにも行わず本処理を終了してリターン
する。
【００８８】一方、ＦＩＮ受信済と判定されなかった場
合（ステップＳ６１，ＮＯ）、ｔｍｐＡＣＫバッファに
保存してあるセグメントがＳＹＮ＋ＡＣＫセグメントか
否かを判定する（ステップＳ６２）。ＳＹＮ＋ＡＣＫセ
グメントであった場合（ステップＳ６２，ＹＥＳ）、Ｓ
ＹＮ＋ＡＣＫセグメントが宛先に未転送だった場合に、
この未転送のデータを転送し（ステップＳ６３）、さら
に転送済みのデータを破棄し（ステップＳ６４）、本処
理を終了してリターンする。
合（ステップＳ６１，ＮＯ）、ｔｍｐＡＣＫバッファに
保存してあるセグメントがＳＹＮ＋ＡＣＫセグメントか
否かを判定する（ステップＳ６２）。ＳＹＮ＋ＡＣＫセ
グメントであった場合（ステップＳ６２，ＹＥＳ）、Ｓ
ＹＮ＋ＡＣＫセグメントが宛先に未転送だった場合に、
この未転送のデータを転送し（ステップＳ６３）、さら
に転送済みのデータを破棄し（ステップＳ６４）、本処
理を終了してリターンする。
【００８９】一方、ステップＳ６２において、ｔｍｐＡ
ＣＫバッファに保存してあるセグメントがＳＹＮ＋ＡＣ
Ｋセグメントではないと判定された場合、仮ＡＣＫの作
成対象となるセグメントを決定する（ステップＳ６
５）。この時。例えばＳＡＣＫなしのＴＣＰ通信であっ
た場合、「自分以外に自分より、シーケンス番号が大き
くかつＦＩＮでないセグメントが少なくとも１つある」
ことを確認し得るセグメントのうちシーケンス番号が最
大のものを、仮ＡＣＫ作成対象とするという実装が考え
られる。
ＣＫバッファに保存してあるセグメントがＳＹＮ＋ＡＣ
Ｋセグメントではないと判定された場合、仮ＡＣＫの作
成対象となるセグメントを決定する（ステップＳ６
５）。この時。例えばＳＡＣＫなしのＴＣＰ通信であっ
た場合、「自分以外に自分より、シーケンス番号が大き
くかつＦＩＮでないセグメントが少なくとも１つある」
ことを確認し得るセグメントのうちシーケンス番号が最
大のものを、仮ＡＣＫ作成対象とするという実装が考え
られる。
【００９０】その後、Ｗｉｎｄｏｗ情報による速度制御
を利用するか否かを判定する（ステップＳ６６）。ステ
ップＳ６６では、配信管理テーブル１のＷｉｎｄｏｗサ
イズ情報による速度調節情報をみて、速度調節のフラグ
が「ＯＮ」であった場合（ステップＳ６６，ＹＥＳ）、
仮ＡＣＫ作成用のデータパケット（図１に示したｔｍｐ
ＡＣＫバッファ４に入っている仮ＡＣＫ作成時に用いる
仮ＡＣＫ雛型で、ステップＳ３８において保存してある
もの）に入っているＡＣＫセグメントのＷｉｎｄｏｗサ
イズに対し、新しく算出された値を代入する。例えば、
配信管理テーブル１を用い、通信ＩＤが「１」の通信に
対し、この操作を行う場合、Min(現在の送信元のＷｉｎ
ｄｏｗサイズ，現在の宛先のＷｉｎｄｏｗサイズ)*０．
７＝１６Ｋ*０．７=１１．２を新しいＷｉｎｄｏｗサイ
ズとする。そして、仮ＡＣＫ作成用データパケットのＷ
ｉｎｄｏｗ情報の変更処理を行って（ステップＳ６
７）、仮ＡＣＫ送信待ちによる速度調節を利用するか否
かの判定を行う（ステップＳ６８）。
を利用するか否かを判定する（ステップＳ６６）。ステ
ップＳ６６では、配信管理テーブル１のＷｉｎｄｏｗサ
イズ情報による速度調節情報をみて、速度調節のフラグ
が「ＯＮ」であった場合（ステップＳ６６，ＹＥＳ）、
仮ＡＣＫ作成用のデータパケット（図１に示したｔｍｐ
ＡＣＫバッファ４に入っている仮ＡＣＫ作成時に用いる
仮ＡＣＫ雛型で、ステップＳ３８において保存してある
もの）に入っているＡＣＫセグメントのＷｉｎｄｏｗサ
イズに対し、新しく算出された値を代入する。例えば、
配信管理テーブル１を用い、通信ＩＤが「１」の通信に
対し、この操作を行う場合、Min(現在の送信元のＷｉｎ
ｄｏｗサイズ，現在の宛先のＷｉｎｄｏｗサイズ)*０．
７＝１６Ｋ*０．７=１１．２を新しいＷｉｎｄｏｗサイ
ズとする。そして、仮ＡＣＫ作成用データパケットのＷ
ｉｎｄｏｗ情報の変更処理を行って（ステップＳ６
７）、仮ＡＣＫ送信待ちによる速度調節を利用するか否
かの判定を行う（ステップＳ６８）。
【００９１】ステップＳ６８では、配信管理テーブル１
にあるフラグをもとに仮ＡＣＫ送信待ちによる速度調節
を利用するか否かを判定する。仮ＡＣＫ送信待ちによる
速度調節を利用する場合（ステップＳ６８，ＹＥＳ）に
は、速度調節用の仮ＡＣＫ送信待ち時間を経過したか否
かを判定する（ステップＳ６９）。この判定は、データ
配信管理装置１０が、通信毎に仮ＡＣＫ送信待ち用のタ
イマと、タイマが切れた事を示すフラグを持っている場
合、そのフラグを見て判定を行う。
にあるフラグをもとに仮ＡＣＫ送信待ちによる速度調節
を利用するか否かを判定する。仮ＡＣＫ送信待ちによる
速度調節を利用する場合（ステップＳ６８，ＹＥＳ）に
は、速度調節用の仮ＡＣＫ送信待ち時間を経過したか否
かを判定する（ステップＳ６９）。この判定は、データ
配信管理装置１０が、通信毎に仮ＡＣＫ送信待ち用のタ
イマと、タイマが切れた事を示すフラグを持っている場
合、そのフラグを見て判定を行う。
【００９２】速度調節用仮ＡＣＫ送信待ち時間が経過し
ていた場合（ステップＳ６９，ＹＥＳ）、速度調節用仮
ＡＣＫ送信待ちタイマおよび関連フラグをリセットし
（ステップＳ７１）、ステップＳ７２に移行する。一
方、速度調節用仮ＡＣＫ送信待ち時間が経過していなか
った（ステップＳ６９，ＮＯ）場合、速度調節用タイマ
が切れるまで待った（ステップＳ７０）後、ステップＳ
７１に移行する。
ていた場合（ステップＳ６９，ＹＥＳ）、速度調節用仮
ＡＣＫ送信待ちタイマおよび関連フラグをリセットし
（ステップＳ７１）、ステップＳ７２に移行する。一
方、速度調節用仮ＡＣＫ送信待ち時間が経過していなか
った（ステップＳ６９，ＮＯ）場合、速度調節用タイマ
が切れるまで待った（ステップＳ７０）後、ステップＳ
７１に移行する。
【００９３】その後、ｔｍｐＡＣＫ作成バッファに保存
してあるセグメントの確認応答番号を、ステップＳ６５
によって決定したｔｍｐＡＣＫ作成対象セグメントのシ
ーケンス番号に「１」を加えた番号に書き換えたセグメ
ントを、ｔｍｐＡＣＫとして作成する。ＳＡＣＫオプシ
ョン付のＴＣＰの場合は、ステップＳ６５においてＳＡ
ＣＫオプションを考慮したｔｍｐＡＣＫ作成対象を決定
し、ステップＳ７２において、ＳＡＣＫオプションも加
えた送達確認応答を作成する実装を行うことも可能であ
る。
してあるセグメントの確認応答番号を、ステップＳ６５
によって決定したｔｍｐＡＣＫ作成対象セグメントのシ
ーケンス番号に「１」を加えた番号に書き換えたセグメ
ントを、ｔｍｐＡＣＫとして作成する。ＳＡＣＫオプシ
ョン付のＴＣＰの場合は、ステップＳ６５においてＳＡ
ＣＫオプションを考慮したｔｍｐＡＣＫ作成対象を決定
し、ステップＳ７２において、ＳＡＣＫオプションも加
えた送達確認応答を作成する実装を行うことも可能であ
る。
【００９４】その後、ｔｍｐＡＣＫを送信し（ステップ
Ｓ７３）、送信したｔｍｐＡＣＫが対応する全ての配信
管理テーブル１上にエントリしてあるセグメントの情報
をｔｍｐＡＣＫ送信済にし（ステップＳ７４）、本処理
を終了してリターンする。
Ｓ７３）、送信したｔｍｐＡＣＫが対応する全ての配信
管理テーブル１上にエントリしてあるセグメントの情報
をｔｍｐＡＣＫ送信済にし（ステップＳ７４）、本処理
を終了してリターンする。
【００９５】つぎに、図１１に示したフローチャートを
参照して、ＳＧ配信管理部１６による受信確認および再
送制御の処理について説明する。図１１において、ま
ず、受信装置Ｃ２からの送達確認応答到着を示す、イベ
ントを受け取ったか否かを判定する（ステップＳ８
１）。これは、図３のステップＳ３８に示したセグメン
トのチェックの処理によって発生されるイベントであ
る。
参照して、ＳＧ配信管理部１６による受信確認および再
送制御の処理について説明する。図１１において、ま
ず、受信装置Ｃ２からの送達確認応答到着を示す、イベ
ントを受け取ったか否かを判定する（ステップＳ８
１）。これは、図３のステップＳ３８に示したセグメン
トのチェックの処理によって発生されるイベントであ
る。
【００９６】受信装置Ｃ２から送達確認応答が到着して
いた場合（ステップＳ８１，ＹＥＳ）、さらに受信装置
Ｃ２からの開始通知か否かを判定し（ステップＳ８
２）、開始通知であった場合（ステップＳ８２，ＹＥ
Ｓ）、本処理を終了する。一方、受信装置Ｃ２からの開
始通知ではないと判定された場合（ステップＳ８２，Ｎ
Ｏ）、配信管理テーブル１に、受信した送達確認応答が
示すセグメントに対する結果を記入する（ステップＳ８
３）。例えば、ＳＡＣＫオプションなしの通信の場合、
配信管理テーブル１のエントリのうち、ＡＣＫ受信待ち
であり、かつ、受信した送達確認応答が示すセグメント
より、シーケンス番号が小さいセグメントを、全てをＡ
ＣＫ受信済にする。一方、ＳＡＣＫオプションありの通
信の場合、配信管理テーブル１のエントリのうち、ＡＣ
Ｋ受信待ちであり、かつ、受信した送達確認応答が示す
セグメントより、シーケンス番号が小さいセグメント
で、かつＳＡＣＫオプションにないセグメントを全て受
信済とする。さらに、この時、ＡＣＫ待ち状態で、かつ
ｔｍｐＡＣＫを送信していなかったセグメントに対する
ＡＣＫであった場合、そのまま、受信したＡＣＫを宛先
（ＡＣＫが対象とするセグメントの送信元）に対し、転
送する。
いた場合（ステップＳ８１，ＹＥＳ）、さらに受信装置
Ｃ２からの開始通知か否かを判定し（ステップＳ８
２）、開始通知であった場合（ステップＳ８２，ＹＥ
Ｓ）、本処理を終了する。一方、受信装置Ｃ２からの開
始通知ではないと判定された場合（ステップＳ８２，Ｎ
Ｏ）、配信管理テーブル１に、受信した送達確認応答が
示すセグメントに対する結果を記入する（ステップＳ８
３）。例えば、ＳＡＣＫオプションなしの通信の場合、
配信管理テーブル１のエントリのうち、ＡＣＫ受信待ち
であり、かつ、受信した送達確認応答が示すセグメント
より、シーケンス番号が小さいセグメントを、全てをＡ
ＣＫ受信済にする。一方、ＳＡＣＫオプションありの通
信の場合、配信管理テーブル１のエントリのうち、ＡＣ
Ｋ受信待ちであり、かつ、受信した送達確認応答が示す
セグメントより、シーケンス番号が小さいセグメント
で、かつＳＡＣＫオプションにないセグメントを全て受
信済とする。さらに、この時、ＡＣＫ待ち状態で、かつ
ｔｍｐＡＣＫを送信していなかったセグメントに対する
ＡＣＫであった場合、そのまま、受信したＡＣＫを宛先
（ＡＣＫが対象とするセグメントの送信元）に対し、転
送する。
【００９７】その後、配信管理テーブル１のエントリの
うちＡＣＫ受信済のセグメント全てを、送信バッファか
ら削除する（ステップＳ８４）。なお、削除に関するタ
イマを持ち、一定時間ごとにまとめて、削除する方法に
よる実装も可能である。
うちＡＣＫ受信済のセグメント全てを、送信バッファか
ら削除する（ステップＳ８４）。なお、削除に関するタ
イマを持ち、一定時間ごとにまとめて、削除する方法に
よる実装も可能である。
【００９８】一方、ステップＳ８１において、受信装置
Ｃ２からの送達確認応答受信のイベントを受けていない
と判定された場合、再送タイムアウトが発生したか否か
を判定する（ステップＳ８５）。再送タイムアウトが発
生していないと判定された場合（ステップＳ８５，Ｎ
Ｏ）、本処理を終了する。
Ｃ２からの送達確認応答受信のイベントを受けていない
と判定された場合、再送タイムアウトが発生したか否か
を判定する（ステップＳ８５）。再送タイムアウトが発
生していないと判定された場合（ステップＳ８５，Ｎ
Ｏ）、本処理を終了する。
【００９９】一方、再送タイムアウトが発生していた場
合（ステップＳ８５，ＹＥＳ）、配信管理テーブル１に
あるタイムアウトが発生したセグメントのエントリの再
送回数をインクリメントし、再送フラグを「ＯＮ」にし
（ステップＳ８６）、さらに配信終了か否かの判定を行
う（ステップＳ８７）。通常のＴＣＰ通信における配信
終了セグメントの交換を検知した場合、および再送のタ
イムアウトを繰り返し、データ配信管理装置が再送のリ
トライアウトをすることにより、配信を終了する場合に
配信終了と判定され、配信終了処理を行い（ステップＳ
８８）、本処理を終了する。なお、再送のタイムアウト
値、およびリトライアウトの回数は、送信装置Ｃ１およ
び受信装置Ｃ２の、再送のタイムアウト値およびリトラ
イアウト回数より、十分に長く設定される必要がある。
合（ステップＳ８５，ＹＥＳ）、配信管理テーブル１に
あるタイムアウトが発生したセグメントのエントリの再
送回数をインクリメントし、再送フラグを「ＯＮ」にし
（ステップＳ８６）、さらに配信終了か否かの判定を行
う（ステップＳ８７）。通常のＴＣＰ通信における配信
終了セグメントの交換を検知した場合、および再送のタ
イムアウトを繰り返し、データ配信管理装置が再送のリ
トライアウトをすることにより、配信を終了する場合に
配信終了と判定され、配信終了処理を行い（ステップＳ
８８）、本処理を終了する。なお、再送のタイムアウト
値、およびリトライアウトの回数は、送信装置Ｃ１およ
び受信装置Ｃ２の、再送のタイムアウト値およびリトラ
イアウト回数より、十分に長く設定される必要がある。
【０１００】配信終了処理では、配信終了状態によって
異なる処理を行う。通常のＴＣＰ通信における配信終了
セグメントの交換を検知した場合、ｔｍｐＡＣＫ用バッ
ファ、送信バッファ、受信バッファの全てにおいて、終
了する通信におけるセグメントを全て、削除し、配信管
理テーブル１のエントリも削除する。なお、配信管理テ
ーブル１のエントリは、データの蓄積を兼ね、保存して
おくことも可能である。また、エントリに寿命を設け
る、あるいはエントリがあふれない限り残しておくとい
う実装も可能である。
異なる処理を行う。通常のＴＣＰ通信における配信終了
セグメントの交換を検知した場合、ｔｍｐＡＣＫ用バッ
ファ、送信バッファ、受信バッファの全てにおいて、終
了する通信におけるセグメントを全て、削除し、配信管
理テーブル１のエントリも削除する。なお、配信管理テ
ーブル１のエントリは、データの蓄積を兼ね、保存して
おくことも可能である。また、エントリに寿命を設け
る、あるいはエントリがあふれない限り残しておくとい
う実装も可能である。
【０１０１】一方、配信終了ではないと判定された場合
（ステップＳ８７，ＮＯ）、ステップＳ８９〜Ｓ９１に
おいて再送を行う。まず、配信管理テーブル１の再送フ
ラグが「ＯＮ」になっているものを、送信バッファのセ
グメントを再送し、配信管理テーブル１の再送フラグを
「ＯＦＦ」にする。その後、再送タイマをリセットし
（ステップＳ９０）、データ配信管理装置１０の再送回
数カウンタのインクリメントを行い（ステップＳ９
１）、処理を終了する。
（ステップＳ８７，ＮＯ）、ステップＳ８９〜Ｓ９１に
おいて再送を行う。まず、配信管理テーブル１の再送フ
ラグが「ＯＮ」になっているものを、送信バッファのセ
グメントを再送し、配信管理テーブル１の再送フラグを
「ＯＦＦ」にする。その後、再送タイマをリセットし
（ステップＳ９０）、データ配信管理装置１０の再送回
数カウンタのインクリメントを行い（ステップＳ９
１）、処理を終了する。
【０１０２】ここで、図１２および図１３を参照して、
データ配信管理装置１０におけるバッファ管理の実現に
ついて説明する。図１２に示すように、送信装置Ｃ１は
ＴＣＰアルゴリズムで動作し、送信装置Ｃ１は、このＴ
ＣＰアルゴリズム内の輻輳制御アルゴリズムＡ１で輻輳
制御を行う。この実施の形態１におけるデータ配信管理
装置１０は、この輻輳制御アルゴリズムＡ１と同等な輻
輳制御機能を有するＴＣＰ輻輳制御アルゴリズムＡ２を
有し、これによって、上述したバッファ管理を実現して
いる。
データ配信管理装置１０におけるバッファ管理の実現に
ついて説明する。図１２に示すように、送信装置Ｃ１は
ＴＣＰアルゴリズムで動作し、送信装置Ｃ１は、このＴ
ＣＰアルゴリズム内の輻輳制御アルゴリズムＡ１で輻輳
制御を行う。この実施の形態１におけるデータ配信管理
装置１０は、この輻輳制御アルゴリズムＡ１と同等な輻
輳制御機能を有するＴＣＰ輻輳制御アルゴリズムＡ２を
有し、これによって、上述したバッファ管理を実現して
いる。
【０１０３】ＴＣＰの輻輳制御アルゴリズムは、輻輳ウ
ィンドウ（ＣＷＮＤ）のサイズを変えることによって、
転送速度の制御を行い、スロースタートと輻輳回避との
２つの輻輳制御を行っている。スロースタートは、ＡＣ
Ｋを受け取る度に１つずつウィンドウサイズを指数的に
増加させ、輻輳回避は、ＡＣＫを受け取る度に１つずつ
ウィンドウサイズを線形に増加させる。そして、データ
の喪失が生じれば、輻輳ウィンドウサイズを減らし、デ
ータの喪失が生じない場合、輻輳ウィンドウサイズを増
やすようにしている。たとえば、スロースタートの輻輳
制御を行う場合、送信装置Ｃ１では、ＴＣＰの輻輳制御
アルゴリズムを用いた送信量ＣＷＮＤを決定しておき、
次の送信量ＣＷＮＤnewは、 ＣＷＮＤnew＝ＣＷＮＤold＋（新規受信ＡＣＫ数）＊Ｍ
ＴＵ で算出される（ステップＳ１０１）。なお、ＭＴＵは、
最大転送単位（MaximumTransmission Unit）である。
ィンドウ（ＣＷＮＤ）のサイズを変えることによって、
転送速度の制御を行い、スロースタートと輻輳回避との
２つの輻輳制御を行っている。スロースタートは、ＡＣ
Ｋを受け取る度に１つずつウィンドウサイズを指数的に
増加させ、輻輳回避は、ＡＣＫを受け取る度に１つずつ
ウィンドウサイズを線形に増加させる。そして、データ
の喪失が生じれば、輻輳ウィンドウサイズを減らし、デ
ータの喪失が生じない場合、輻輳ウィンドウサイズを増
やすようにしている。たとえば、スロースタートの輻輳
制御を行う場合、送信装置Ｃ１では、ＴＣＰの輻輳制御
アルゴリズムを用いた送信量ＣＷＮＤを決定しておき、
次の送信量ＣＷＮＤnewは、 ＣＷＮＤnew＝ＣＷＮＤold＋（新規受信ＡＣＫ数）＊Ｍ
ＴＵ で算出される（ステップＳ１０１）。なお、ＭＴＵは、
最大転送単位（MaximumTransmission Unit）である。
【０１０４】一方、データ配信管理装置１０側では、Ｔ
ＣＰ輻輳制御アルゴリズムＡ２を用い、送信元からのデ
ータ量、すなわちＣＷＮＤの増加量を予測する（ステッ
プＳ１１１）。すなわち、データ配信管理装置１０側で
は、ＣＷＮＤの推移予測および接続回線の速度から、単
位時間当たりにどのくらいのデータが送付され、転送先
の遅延状況から、どれくらいのバッファ量を必要とする
かを予測する。その後、送信装置Ｃ１側からデータ送信
されると、この予測に基づいて、バッファ管理を行うこ
とによって、ＡＣＫの返送速度の増減やＡＣＫ送信の停
止を行い、これによって結果的に、送信装置Ｃ１のＣＷ
ＮＤの増加速度の増減を制御する。また、データ配信管
理装置１０は、この予測に基づいて、バッファ管理を行
うことによって、ＡＣＫのＷｉｎｄｏｗ情報の拡大ある
いは縮小を行い、これによって結果的に、送信装置Ｃ１
の送信Ｗｉｎｄｏｗの拡大あるいは縮小する制御を行
う。このように、データ配信管理装置１０内に送信装置
Ｃ１側に設けられた輻輳制御アルゴリズムと同等なアル
ゴリズムを搭載することによって、バッファ管理を行
い、結果的にデータの配信管理を行うようにしている。
ＣＰ輻輳制御アルゴリズムＡ２を用い、送信元からのデ
ータ量、すなわちＣＷＮＤの増加量を予測する（ステッ
プＳ１１１）。すなわち、データ配信管理装置１０側で
は、ＣＷＮＤの推移予測および接続回線の速度から、単
位時間当たりにどのくらいのデータが送付され、転送先
の遅延状況から、どれくらいのバッファ量を必要とする
かを予測する。その後、送信装置Ｃ１側からデータ送信
されると、この予測に基づいて、バッファ管理を行うこ
とによって、ＡＣＫの返送速度の増減やＡＣＫ送信の停
止を行い、これによって結果的に、送信装置Ｃ１のＣＷ
ＮＤの増加速度の増減を制御する。また、データ配信管
理装置１０は、この予測に基づいて、バッファ管理を行
うことによって、ＡＣＫのＷｉｎｄｏｗ情報の拡大ある
いは縮小を行い、これによって結果的に、送信装置Ｃ１
の送信Ｗｉｎｄｏｗの拡大あるいは縮小する制御を行
う。このように、データ配信管理装置１０内に送信装置
Ｃ１側に設けられた輻輳制御アルゴリズムと同等なアル
ゴリズムを搭載することによって、バッファ管理を行
い、結果的にデータの配信管理を行うようにしている。
【０１０５】なお、ステップＳ２１では、遅延依存の回
線であることを前提としているが、これに限らず、バー
ストエラーに起因した再送に伴う伝送遅延が生じる無線
回線のような回線にも適用し、スプーフィング処理を行
うことによってスループットの低下を防止することがで
きる。この場合、図１４に示す処理を行うことによっ
て、遅延依存の回線と同様に、バーストエラーに起因し
た再送に伴う伝送遅延に対しても、バッファ管理を行う
ことによって、スプーフィング処理を実行し、スループ
ットの低下を防止するようにしている。図１４におい
て、まず、データ配信管理装置１０は、通信すべき回線
がバーストエラーが生じ易い回線であるか否かを判断す
る（ステップＳ１２１）。この判断は、たとえば、接続
される経路毎の回線状況、すなわちバーストエラーが生
じ易い回線であるか否かをテーブルとして保持しておく
ことによって実現される。
線であることを前提としているが、これに限らず、バー
ストエラーに起因した再送に伴う伝送遅延が生じる無線
回線のような回線にも適用し、スプーフィング処理を行
うことによってスループットの低下を防止することがで
きる。この場合、図１４に示す処理を行うことによっ
て、遅延依存の回線と同様に、バーストエラーに起因し
た再送に伴う伝送遅延に対しても、バッファ管理を行う
ことによって、スプーフィング処理を実行し、スループ
ットの低下を防止するようにしている。図１４におい
て、まず、データ配信管理装置１０は、通信すべき回線
がバーストエラーが生じ易い回線であるか否かを判断す
る（ステップＳ１２１）。この判断は、たとえば、接続
される経路毎の回線状況、すなわちバーストエラーが生
じ易い回線であるか否かをテーブルとして保持しておく
ことによって実現される。
【０１０６】その後、バーストエラーが生じ易い回線で
ある場合（ステップＳ１２１，ＹＥＳ）には、転送デー
タの一時保存を行い（ステップＳ１２２）、スプーフィ
ング処理に備える。その後、一定期間、宛先からＡＣＫ
を受信しなかったか否かを判断する（ステップＳ１２
３）。ＡＣＫを受信していない場合（ステップＳ１２
３，ＹＥＳ）には、スプーフィング処理を実行し（ステ
ップＳ１２４）、スループットの低下を防止し、本処理
を終了する。このスプーフィング処理は、仮ＡＣＫの転
送を行う上述したステップＳ１３の処理に該当する。
ある場合（ステップＳ１２１，ＹＥＳ）には、転送デー
タの一時保存を行い（ステップＳ１２２）、スプーフィ
ング処理に備える。その後、一定期間、宛先からＡＣＫ
を受信しなかったか否かを判断する（ステップＳ１２
３）。ＡＣＫを受信していない場合（ステップＳ１２
３，ＹＥＳ）には、スプーフィング処理を実行し（ステ
ップＳ１２４）、スループットの低下を防止し、本処理
を終了する。このスプーフィング処理は、仮ＡＣＫの転
送を行う上述したステップＳ１３の処理に該当する。
【０１０７】一方、バーストエラーが生じ易い回線でな
い場合（ステップＳ１２１，ＮＯ）、および一定期間内
に、宛先からＡＣＫを受信した場合（ステップＳ１２
３，ＮＯ）には転送データを破棄した後（ステップＳ１
２５）、本処理を終了する。なお、この処理は、上述し
た遅延依存の回線に対するスプーフィング処理と組み合
わせるようにしてもよい。
い場合（ステップＳ１２１，ＮＯ）、および一定期間内
に、宛先からＡＣＫを受信した場合（ステップＳ１２
３，ＮＯ）には転送データを破棄した後（ステップＳ１
２５）、本処理を終了する。なお、この処理は、上述し
た遅延依存の回線に対するスプーフィング処理と組み合
わせるようにしてもよい。
【０１０８】実施の形態２．つぎに、この発明の実施の
形態２について説明する。上述した実施の形態１では、
データ配信管理装置１０を、伝送遅延の大きな回線３と
小さな回線２との間に配置していたが、この実施の形態
２では、送信装置Ｃ１および受信装置Ｃ２がそれぞれ送
受信機能を有する端末装置とし、受信装置Ｃ２側にデー
タ配信管理装置１０に相当するデータ配信管理装置を設
け、双方向の遅延に対して改善することができるように
している。
形態２について説明する。上述した実施の形態１では、
データ配信管理装置１０を、伝送遅延の大きな回線３と
小さな回線２との間に配置していたが、この実施の形態
２では、送信装置Ｃ１および受信装置Ｃ２がそれぞれ送
受信機能を有する端末装置とし、受信装置Ｃ２側にデー
タ配信管理装置１０に相当するデータ配信管理装置を設
け、双方向の遅延に対して改善することができるように
している。
【０１０９】図１３に示すように、遅延の大きな回線３
の両端にデータ配信管理装置１０，２０を設け、各デー
タ配信管理装置１０，２０に遅延の小さい回線２ａ，２
ｂを介して端末装置Ｃ２１，Ｃ２２をそれぞれ接続す
る。ここで、端末装置Ｃ２１，Ｃ２２は、データの送信
機能および受信機能を備えている。データ配信管理装置
１０は、図１に示したデータ配信管理装置１０と同じで
あり、端末装置Ｃ２１から送られた送信データを回線３
を介して端末装置Ｃ２２に転送するとともに、端末装置
Ｃ２１に対する仮の到達確認応答の返送処理を行う。デ
ータ配信管理装置２０は、データ配信管理装置１０と同
様に、端末装置Ｃ２２から送られた送信データを、回線
３を介して端末Ｃ２１に転送するとともに、端末装置Ｃ
２２に対する仮の到達確認応答の返送処理を行う。ただ
し、データ配信管理装置１０，２０は、遅延の大きな回
線３からデータを受信した場合、このデータの転送処理
のみを行う。たとえば、データ配信管理装置２０は、デ
ータ配信管理装置１０からデータを受信した場合、この
データを端末装置Ｃ２２に転送する処理のみを行い、仮
の到達確認応答の返送処理は行わない。これによって、
双方向の遅延を改善した通信を行うことができる。
の両端にデータ配信管理装置１０，２０を設け、各デー
タ配信管理装置１０，２０に遅延の小さい回線２ａ，２
ｂを介して端末装置Ｃ２１，Ｃ２２をそれぞれ接続す
る。ここで、端末装置Ｃ２１，Ｃ２２は、データの送信
機能および受信機能を備えている。データ配信管理装置
１０は、図１に示したデータ配信管理装置１０と同じで
あり、端末装置Ｃ２１から送られた送信データを回線３
を介して端末装置Ｃ２２に転送するとともに、端末装置
Ｃ２１に対する仮の到達確認応答の返送処理を行う。デ
ータ配信管理装置２０は、データ配信管理装置１０と同
様に、端末装置Ｃ２２から送られた送信データを、回線
３を介して端末Ｃ２１に転送するとともに、端末装置Ｃ
２２に対する仮の到達確認応答の返送処理を行う。ただ
し、データ配信管理装置１０，２０は、遅延の大きな回
線３からデータを受信した場合、このデータの転送処理
のみを行う。たとえば、データ配信管理装置２０は、デ
ータ配信管理装置１０からデータを受信した場合、この
データを端末装置Ｃ２２に転送する処理のみを行い、仮
の到達確認応答の返送処理は行わない。これによって、
双方向の遅延を改善した通信を行うことができる。
【０１１０】
【発明の効果】以上説明したように、この発明によれ
ば、バッファ管理手段が、送信元のスループット情報を
もとに、前記バッファのバッファサイズを可変設定する
ようにしているので、データ配信における輻輳状態を回
避し、高信頼かつ高速な通信を実現できる。
ば、バッファ管理手段が、送信元のスループット情報を
もとに、前記バッファのバッファサイズを可変設定する
ようにしているので、データ配信における輻輳状態を回
避し、高信頼かつ高速な通信を実現できる。
【０１１１】つぎの発明によれば、速度調整手段が、宛
先の受信バッファの状態に応じてスループットの増減幅
を調整するようにしているので、輻輳による伝送遅延に
よる速度性能の劣化を改善することができるという効果
を奏する。
先の受信バッファの状態に応じてスループットの増減幅
を調整するようにしているので、輻輳による伝送遅延に
よる速度性能の劣化を改善することができるという効果
を奏する。
【０１１２】つぎの発明によれば、配信管理手段が、前
記予測手段が前記バッファのバッファサイズ不足を予測
した場合に、前記仮の送達確認応答の返送を停止させる
制御を行うようにし、バッファ状態に応じて送信側のス
ループットを調整するようにしているので、輻輳に応じ
た伝送遅延による速度性能の劣化を改善することができ
るという効果を奏する。
記予測手段が前記バッファのバッファサイズ不足を予測
した場合に、前記仮の送達確認応答の返送を停止させる
制御を行うようにし、バッファ状態に応じて送信側のス
ループットを調整するようにしているので、輻輳に応じ
た伝送遅延による速度性能の劣化を改善することができ
るという効果を奏する。
【０１１３】つぎの発明によれば、前記配信管理手段
は、前記予測手段が前記バッファのバッファサイズ不足
を予測した場合に、前記仮の送達確認応答の返信速度を
低下させる制御を行い、バッファ状態に応じて送信側の
スループットを調整するようにしているので、輻輳に応
じた伝送遅延による速度性能の劣化を改善することがで
きるという効果を奏する。
は、前記予測手段が前記バッファのバッファサイズ不足
を予測した場合に、前記仮の送達確認応答の返信速度を
低下させる制御を行い、バッファ状態に応じて送信側の
スループットを調整するようにしているので、輻輳に応
じた伝送遅延による速度性能の劣化を改善することがで
きるという効果を奏する。
【０１１４】つぎの発明によれば、前記配信管理手段
は、前記予測手段が前記バッファのバッファサイズ不足
を予測した場合に、前記仮の送達確認応答のウィンドウ
情報を小さくする制御を行い、バッファ状態に応じて送
信側のスループットを調整するようにしているので、輻
輳に応じた伝送遅延による速度性能の劣化を改善するこ
とができるという効果を奏する。
は、前記予測手段が前記バッファのバッファサイズ不足
を予測した場合に、前記仮の送達確認応答のウィンドウ
情報を小さくする制御を行い、バッファ状態に応じて送
信側のスループットを調整するようにしているので、輻
輳に応じた伝送遅延による速度性能の劣化を改善するこ
とができるという効果を奏する。
【０１１５】つぎの発明によれば、前記配信管理手段
は、前記予測手段が前記バッファのバッファサイズ不足
を予測した場合に、新規の前記仮の送達確認応答を利用
するコネクション接続要求を受けない制御を行い、バッ
ファ状態に応じて送信側のスループットを調整するよう
にしているので、輻輳に応じた伝送遅延による速度性能
の劣化を改善することができるという効果を奏する。
は、前記予測手段が前記バッファのバッファサイズ不足
を予測した場合に、新規の前記仮の送達確認応答を利用
するコネクション接続要求を受けない制御を行い、バッ
ファ状態に応じて送信側のスループットを調整するよう
にしているので、輻輳に応じた伝送遅延による速度性能
の劣化を改善することができるという効果を奏する。
【０１１６】つぎの発明によれば、前記配信管理手段
は、前記優先度に応じて前記バッファサイズを調整する
ようにしているので、柔軟かつ効率的なデータ配信を行
うことができるという効果を奏する。
は、前記優先度に応じて前記バッファサイズを調整する
ようにしているので、柔軟かつ効率的なデータ配信を行
うことができるという効果を奏する。
【０１１７】つぎの発明によれば、前記配信管理手段
は、前記バッファの空き領域が、予め設定されたバッフ
ァサイズの余裕値を超えた場合に受信データ量を抑制す
る通信に対して、前記受信データ量が抑制されるように
該通信の送信元に指示するようにしているので、柔軟か
つ効率的なデータ配信を行うことができるという効果を
奏する。
は、前記バッファの空き領域が、予め設定されたバッフ
ァサイズの余裕値を超えた場合に受信データ量を抑制す
る通信に対して、前記受信データ量が抑制されるように
該通信の送信元に指示するようにしているので、柔軟か
つ効率的なデータ配信を行うことができるという効果を
奏する。
【０１１８】つぎの発明によれば、決定手段が、選択的
な速度調整を行うか否かを決定するようにしているの
で、柔軟かつ効率的なデータ配信を行うことができると
いう効果を奏する。
な速度調整を行うか否かを決定するようにしているの
で、柔軟かつ効率的なデータ配信を行うことができると
いう効果を奏する。
【０１１９】つぎの発明によれば、データ配信管理装置
が第１の端末装置と第２の端末装置との間に配置され、
第１の端末装置あるいは第２の端末装置からのスループ
ットの低下を防止する制御するようにしているので、輻
輳に応じた伝送遅延による速度性能の劣化を改善するこ
とができるという効果を奏する。
が第１の端末装置と第２の端末装置との間に配置され、
第１の端末装置あるいは第２の端末装置からのスループ
ットの低下を防止する制御するようにしているので、輻
輳に応じた伝送遅延による速度性能の劣化を改善するこ
とができるという効果を奏する。
【０１２０】つぎの発明によれば、バッファ管理工程
が、送信元のスループット情報および配信処理終了まで
にかかる時間をもとに、前記バッファのバッファサイズ
を可変設定するようにしているので、データ配信におけ
る輻輳状態を回避し、高信頼かつ高速な通信を実現でき
る。
が、送信元のスループット情報および配信処理終了まで
にかかる時間をもとに、前記バッファのバッファサイズ
を可変設定するようにしているので、データ配信におけ
る輻輳状態を回避し、高信頼かつ高速な通信を実現でき
る。
【０１２１】つぎの発明によれば、速度調整工程が、宛
先の受信バッファの状態に応じてスループットの増減幅
を調整するようにしているので、輻輳による伝送遅延に
よる速度性能の劣化を改善することができるという効果
を奏する。
先の受信バッファの状態に応じてスループットの増減幅
を調整するようにしているので、輻輳による伝送遅延に
よる速度性能の劣化を改善することができるという効果
を奏する。
【０１２２】つぎの発明によれば、配信管理工程が、前
記予測工程が前記バッファのバッファサイズ不足を予測
した場合に、前記仮の送達確認応答の返送を停止させる
制御を行うようにし、バッファ状態に応じて送信側のス
ループットを調整するようにしているので、輻輳に応じ
た伝送遅延による速度性能の劣化を改善することができ
るという効果を奏する。
記予測工程が前記バッファのバッファサイズ不足を予測
した場合に、前記仮の送達確認応答の返送を停止させる
制御を行うようにし、バッファ状態に応じて送信側のス
ループットを調整するようにしているので、輻輳に応じ
た伝送遅延による速度性能の劣化を改善することができ
るという効果を奏する。
【０１２３】つぎの発明によれば、前記配信管理工程
は、前記予測工程が前記バッファのバッファサイズ不足
を予測した場合に、前記仮の送達確認応答の返信速度を
低下させる制御を行い、バッファ状態に応じて送信側の
スループットを調整するようにしているので、輻輳に応
じた伝送遅延による速度性能の劣化を改善することがで
きるという効果を奏する。
は、前記予測工程が前記バッファのバッファサイズ不足
を予測した場合に、前記仮の送達確認応答の返信速度を
低下させる制御を行い、バッファ状態に応じて送信側の
スループットを調整するようにしているので、輻輳に応
じた伝送遅延による速度性能の劣化を改善することがで
きるという効果を奏する。
【０１２４】つぎの発明によれば、前記配信管理工程
は、前記予測工程が前記バッファのバッファサイズ不足
を予測した場合に、前記仮の送達確認応答のウィンドウ
情報を小さくする制御を行い、バッファ状態に応じて送
信側のスループットを調整するようにしているので、輻
輳に応じた伝送遅延による速度性能の劣化を改善するこ
とができるという効果を奏する。
は、前記予測工程が前記バッファのバッファサイズ不足
を予測した場合に、前記仮の送達確認応答のウィンドウ
情報を小さくする制御を行い、バッファ状態に応じて送
信側のスループットを調整するようにしているので、輻
輳に応じた伝送遅延による速度性能の劣化を改善するこ
とができるという効果を奏する。
【０１２５】つぎの発明によれば、前記配信管理工程
は、前記予測工程が前記バッファのバッファサイズ不足
を予測した場合に、新規の前記仮の送達確認応答を利用
するコネクション接続要求を受けない制御を行い、バッ
ファ状態に応じて送信側のスループットを調整するよう
にしているので、輻輳に応じた伝送遅延による速度性能
の劣化を改善することができるという効果を奏する。
は、前記予測工程が前記バッファのバッファサイズ不足
を予測した場合に、新規の前記仮の送達確認応答を利用
するコネクション接続要求を受けない制御を行い、バッ
ファ状態に応じて送信側のスループットを調整するよう
にしているので、輻輳に応じた伝送遅延による速度性能
の劣化を改善することができるという効果を奏する。
【０１２６】つぎの発明によれば、前記配信管理工程
は、前記優先度に応じて前記バッファサイズを調整する
ようにしているので、柔軟かつ効率的なデータ配信を行
うことができるという効果を奏する。
は、前記優先度に応じて前記バッファサイズを調整する
ようにしているので、柔軟かつ効率的なデータ配信を行
うことができるという効果を奏する。
【０１２７】つぎの発明によれば、前記配信管理工程
は、前記バッファの空き領域が、予め設定されたバッフ
ァサイズの余裕値を超えた場合に受信データ量を抑制す
る通信に対して、前記受信データ量が抑制されるように
該通信の送信元に指示するようにしているので、柔軟か
つ効率的なデータ配信を行うことができるという効果を
奏する。
は、前記バッファの空き領域が、予め設定されたバッフ
ァサイズの余裕値を超えた場合に受信データ量を抑制す
る通信に対して、前記受信データ量が抑制されるように
該通信の送信元に指示するようにしているので、柔軟か
つ効率的なデータ配信を行うことができるという効果を
奏する。
【０１２８】つぎの発明によれば、決定工程が、選択的
な速度調整を行うか否かを決定するようにしているの
で、柔軟かつ効率的なデータ配信を行うことができると
いう効果を奏する。
な速度調整を行うか否かを決定するようにしているの
で、柔軟かつ効率的なデータ配信を行うことができると
いう効果を奏する。
【図１】 この発明の実施の形態１であるデータ配信管
理装置を含むデータ配信管理システムの構成を示すブロ
ック図である。
理装置を含むデータ配信管理システムの構成を示すブロ
ック図である。
【図２】 図１に示したデータ配信管理装置によるデー
タ配信管理処理手順を示すフローチャートである。
タ配信管理処理手順を示すフローチャートである。
【図３】 図２に示したパケットのチェック処理手順を
示す詳細フローチャートである。
示す詳細フローチャートである。
【図４】 図１に示した経路管理テーブルの内容の一例
を示す図である。
を示す図である。
【図５】 図１に示したプロトコル管理テーブルの内容
の一例を示す図である。
の一例を示す図である。
【図６】 図１に示した配信管理テーブルの内容の一例
を示す図である。
を示す図である。
【図７】 図１に示した配信管理テーブルの内容の一例
を示す図である。
を示す図である。
【図８】 ステップＳ３９に対応したｔｍｐＡＣＫ作成
送信待ちによる速度調整の処理手順を示すフローチャー
トである。
送信待ちによる速度調整の処理手順を示すフローチャー
トである。
【図９】 ステップＳ５６に対応した仮ＡＣＫ作成送信
処理の手順を示すフローチャートである。
処理の手順を示すフローチャートである。
【図１０】 バッファ区分を示す図である。
【図１１】 受信確認および再送制御の処理手順を示す
フローチャートである。
フローチャートである。
【図１２】 ＴＣＰ輻輳制御アルゴリズムが搭載される
データ配信管理装置を示す図である。
データ配信管理装置を示す図である。
【図１３】 ＴＣＰ輻輳制御アルゴリズムが搭載される
データ配信管理装置と送信装置との間におけるデータ配
信管理処理を示すフローチャートである。
データ配信管理装置と送信装置との間におけるデータ配
信管理処理を示すフローチャートである。
【図１４】 バーストエラーが生じ易い回線に対するス
プーフィング処理の適用処理手順を示すフローチャート
である。
プーフィング処理の適用処理手順を示すフローチャート
である。
【図１５】 この発明の実施の形態４であって、二つの
データ配信管理装置を用いて双方向通信を可能にしたデ
ータ配信管理システムの構成を示すブロック図である。
データ配信管理装置を用いて双方向通信を可能にしたデ
ータ配信管理システムの構成を示すブロック図である。
【図１６】 従来のデータ配信管理装置を含むデータ配
信管理システムの構成を示すブロック図である。
信管理システムの構成を示すブロック図である。
１ 配信管理テーブル、２，２ａ，２ｂ，３ 回線、４
ｔｍｐＡＣＫバッファ、５ プロトコル管理テーブ
ル、６ 送信バッファ、６ａ バッファ割当部、７ 受
信バッファ、８ 経路管理テーブル、１０，２０ デー
タ配信管理装置、１１，１７ 通信部、１２ ｔｍｐＡ
ＣＫ使用判定部、１３ ｔｍｐＡＣＫ作成部、１４ Ｓ
ＧＴｉｍｅｒカウント部、１５ 配信データ記録部、１
６ ＳＧ配信管理部、ＳＧ 送信ゲートウェイ、Ｃ１
送信装置、Ｃ２ 受信装置、Ｃ２１，Ｃ２２ 端末装
置。
ｔｍｐＡＣＫバッファ、５ プロトコル管理テーブ
ル、６ 送信バッファ、６ａ バッファ割当部、７ 受
信バッファ、８ 経路管理テーブル、１０，２０ デー
タ配信管理装置、１１，１７ 通信部、１２ ｔｍｐＡ
ＣＫ使用判定部、１３ ｔｍｐＡＣＫ作成部、１４ Ｓ
ＧＴｉｍｅｒカウント部、１５ 配信データ記録部、１
６ ＳＧ配信管理部、ＳＧ 送信ゲートウェイ、Ｃ１
送信装置、Ｃ２ 受信装置、Ｃ２１，Ｃ２２ 端末装
置。
─────────────────────────────────────────────────────
フロントページの続き
Ｆターム(参考） 5K030 HA05 KA03 LA01 LC01 LE16
MB15
5K034 AA01 AA03 AA05 DD03 EE11
HH01 HH02 MM03
Claims (19)
- 【請求項１】 少なくとも受信したデータを宛先に向け
て転送するとともに、宛先からの送達確認応答を受信す
るまでデータセグメントを保存し、必要に応じて再送処
理を行う機能を有したデータ配信管理装置において、 受信したデータセグメントを保存するバッファと、 送信元のスループット情報をもとに、前記バッファのバ
ッファサイズを可変設定するバッファ管理手段と、 を備えたことを特徴とするデータ配信管理装置。 - 【請求項２】 宛先の受信バッファの状態に応じたデー
タ転送速度調整を行う速度調整手段をさらに備えたこと
を特徴とする請求項１に記載のデータ配信管理装置。 - 【請求項３】 受信したデータを宛先に向けて転送する
とともに送信元に対して仮の送達確認応答を作成し、返
送する仮送達確認応答手段と、 前記バッファのバッファサイズ不足を予測する予測手段
と、 前記予測手段が前記バッファのバッファサイズ不足を予
測した場合に、前記仮の送達確認応答の返送を停止させ
る制御を行う配信管理手段と、 をさらに備えたことを特徴とする請求項１または２に記
載のデータ配信管理装置。 - 【請求項４】 受信したデータを宛先に向けて転送する
とともに送信元に対して仮の送達確認応答を作成し、返
送する仮送達確認応答手段と、 前記バッファのバッファサイズ不足を予測する予測手段
と、 前記予測手段が前記バッファのバッファサイズ不足を予
測した場合に、前記仮の送達確認応答の返信速度を低下
させる制御を行う配信管理手段と、 をさらに備えたことを特徴とする請求項１または２に記
載のデータ配信管理装置。 - 【請求項５】 受信したデータを宛先に向けて転送する
とともに送信元に対して仮の送達確認応答を作成し、返
送する仮送達確認応答手段と、 前記バッファのバッファサイズ不足を予測する予測手段
と、 前記予測手段が前記バッファのバッファサイズ不足を予
測した場合に、前記仮の送達確認応答のウィンドウ情報
を小さくする制御を行う配信管理手段と、 をさらに備えたことを特徴とする請求項１または２に記
載のデータ配信管理装置。 - 【請求項６】 受信したデータを宛先に向けて転送する
とともに送信元に対して仮の送達確認応答を作成し、返
送する仮送達確認応答手段と、 前記バッファのバッファサイズ不足を予測する予測手段
と、 前記予測手段が前記バッファのバッファサイズ不足を予
測した場合に、新規の前記仮の送達確認応答を利用する
コネクション接続要求を受けない制御を行う配信管理手
段と、 をさらに備えたことを特徴とする請求項１または２に記
載のデータ配信管理装置。 - 【請求項７】 宛先毎に優先度が設定された優先度管理
テーブルをさらに備え、 前記配信管理手段は、前記優先度に応じて前記バッファ
サイズを調整することを特徴とする請求項３〜６のいず
れか一つに記載のデータ配信管理装置。 - 【請求項８】 前記配信管理手段は、前記バッファの空
き領域が、予め設定されたバッファサイズの余裕値を超
えた場合に受信データ量を抑制する通信に対して、前記
受信データ量が抑制されるように該通信の送信元に指示
することを特徴とする請求項３〜７のいずれか一つに記
載のデータ配信管理装置。 - 【請求項９】 選択的な速度調整を行うか否かを決定す
る決定手段をさらに備えたことを特徴とする請求項１〜
８のいずれか一つに記載のデータ配信管理装置。 - 【請求項１０】 データを送受信する第１の端末装置
と、 前記該第１の端末装置の通信相手先である第２の端末装
置と、 前記第１の端末装置と前記第２の端末装置との間の伝送
路上に配置され、請求項１〜９のいずれか一つに記載の
１以上のデータ配信管理装置と、 を備えたことを特徴とするデータ配信管理システム。 - 【請求項１１】 少なくとも受信したデータを宛先に向
けて転送するとともに、宛先からの送達確認応答を受信
するまでデータセグメントを保存し、必要に応じて再送
処理を行う機能を有したデータ配信管理装置のデータ配
信管理方法において、 受信したデータセグメントを保存する保存工程と、 送信元のスループット情報および配信処理終了までにか
かる時間をもとに、前記バッファのバッファサイズを可
変設定するバッファ管理工程と、 を含むことを特徴とするデータ配信管理方法。 - 【請求項１２】 宛先の受信バッファの状態に応じたデ
ータ転送速度調整を行う速度調整工程をさらに含むこと
を特徴とする請求項１１に記載のデータ配信管理方法。 - 【請求項１３】 受信したデータを宛先に向けて転送す
るとともに送信元に対して仮の送達確認応答を作成し、
返送する仮送達確認応答工程と、 前記バッファのバッファサイズ不足を予測する予測工程
と、 前記予測工程が前記バッファのバッファサイズ不足を予
測した場合に、前記仮の送達確認応答の返送を停止させ
る制御を行う配信管理工程と、 をさらに含むことを特徴とする請求項１１または１２に
記載のデータ配信管理方法。 - 【請求項１４】 前記配信管理工程は、前記予測工程が
前記バッファのバッファサイズ不足を予測した場合に、
前記仮の送達確認応答の返信速度を低下させる制御を行
うことを特徴とする請求項１３に記載のデータ配信管理
方法。 - 【請求項１５】 前記配信管理工程は、前記予測工程が
前記バッファのバッファサイズ不足を予測した場合に、
前記仮の送達確認応答のウィンドウ情報を小さくする制
御を行うことを特徴とする請求項１３に記載のデータ配
信管理方法。 - 【請求項１６】 前記配信管理工程は、前記予測工程が
前記バッファのバッファサイズ不足を予測した場合に、
新規の前記仮の送達確認応答を利用するコネクション接
続要求を受けない制御を行うことを特徴とする請求項１
３に記載のデータ配信管理方法。 - 【請求項１７】 宛先毎に優先度が設定する優先度設定
工程をさらに含み、 前記配信管理工程は、前記優先度に応じて前記バッファ
サイズを調整することを特徴とする請求項１３〜１６の
いずれか一つに記載のデータ配信管理方法。 - 【請求項１８】 前記配信管理工程は、前記バッファの
空き領域が、予め設定されたバッファサイズの余裕値を
超えた場合に受信データ量を抑制する通信に対して、前
記受信データ量が抑制されるように該通信の送信元に指
示することを特徴とする請求項１３〜１７のいずれか一
つに記載のデータ配信管理方法。 - 【請求項１９】 選択的な速度調整を行うか否かを決定
する決定工程をさらに含むことを特徴とする請求項１１
〜１８のいずれか一つに記載のデータ配信管理方法。
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 true JP2003124984A (ja) | 2003-04-25 |
| JP4302339B2 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) |
Cited By (20)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2003143216A (ja) * | 2001-10-25 | 2003-05-16 | Alcatel | 遠隔通信網を介しｉｐプロトコルを用いるパケットの送信方法 |
| JP2004180158A (ja) * | 2002-11-28 | 2004-06-24 | Ntt Docomo Inc | 基地局制御装置、データ伝送方法及びプログラム |
| WO2005006673A1 (ja) * | 2003-07-15 | 2005-01-20 | Fujitsu Limited | 帯域制御装置 |
| JP2005244269A (ja) * | 2004-02-24 | 2005-09-08 | Matsushita Electric Ind Co Ltd | 無線伝送装置および無線伝送装置の省電力駆動方法 |
| JP2006114973A (ja) * | 2004-10-12 | 2006-04-27 | Nec Infrontia Corp | 無線基地局及び無線端末装置 |
| JP2006245824A (ja) * | 2005-03-01 | 2006-09-14 | Mitsubishi Electric Corp | 移動体通信システム |
| JP2007124225A (ja) * | 2005-10-27 | 2007-05-17 | Oki Electric Ind Co Ltd | ネットワークスイッチ装置及び方法、無線アクセス装置、および、無線ネットワーク |
| JP2007189509A (ja) * | 2006-01-13 | 2007-07-26 | Mitsubishi Electric Corp | 呼制御サーバ、メディアプロキシおよび輻輳制御方法 |
| JP2008085950A (ja) * | 2006-09-29 | 2008-04-10 | Kddi Corp | Ｔｃｐを用いたレート制御方法、サーバ及びプログラム |
| JP2009105921A (ja) * | 2008-12-08 | 2009-05-14 | Fujitsu Ltd | 出力装置及び通信システム |
| US7986759B2 (en) | 2005-02-25 | 2011-07-26 | Fujitsu Limited | Data output method, data output apparatus and communication system |
| JP2013013093A (ja) * | 2012-07-20 | 2013-01-17 | Thomson Licensing | Ｔｃｐａｃｋの管理によるｌａｎにおけるスループット改善 |
| JP5564603B1 (ja) * | 2013-06-07 | 2014-07-30 | ソフトバンクモバイル株式会社 | 中継ノード |
| JP2016051944A (ja) * | 2014-08-29 | 2016-04-11 | 沖電気工業株式会社 | データ中継装置、データ中継方法、及びデータ中継プログラム |
| JP2016139903A (ja) * | 2015-01-27 | 2016-08-04 | 富士通株式会社 | 通信装置、及びそのデータ中継方法 |
| WO2017090154A1 (ja) * | 2015-11-26 | 2017-06-01 | 株式会社日立製作所 | ストレージシステム及びストレージプログラム |
| JP2017158115A (ja) * | 2016-03-03 | 2017-09-07 | ソフトバンク株式会社 | 通信装置、通信システム、プログラム、及び通信方法 |
| US9762511B2 (en) | 2011-01-31 | 2017-09-12 | Brother Kogyo Kabushiki Kaisha | Communication device |
| WO2018056406A1 (ja) * | 2016-09-23 | 2018-03-29 | 日本電気株式会社 | プロトコル終端装置、中継方法、プログラム |
| JP2018067788A (ja) * | 2016-10-19 | 2018-04-26 | 日本電気株式会社 | 受信トラヒックの高速化装置、高速化方法、および高速化プログラム |
-
2001
- 2001-10-18 JP JP2001321030A patent/JP4302339B2/ja not_active Expired - Fee Related
Cited By (28)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2003143216A (ja) * | 2001-10-25 | 2003-05-16 | Alcatel | 遠隔通信網を介しｉｐプロトコルを用いるパケットの送信方法 |
| JP2004180158A (ja) * | 2002-11-28 | 2004-06-24 | Ntt Docomo Inc | 基地局制御装置、データ伝送方法及びプログラム |
| WO2005006673A1 (ja) * | 2003-07-15 | 2005-01-20 | Fujitsu Limited | 帯域制御装置 |
| JPWO2005006673A1 (ja) * | 2003-07-15 | 2006-08-31 | 富士通株式会社 | 帯域制御装置 |
| JP2005244269A (ja) * | 2004-02-24 | 2005-09-08 | Matsushita Electric Ind Co Ltd | 無線伝送装置および無線伝送装置の省電力駆動方法 |
| JP4639603B2 (ja) * | 2004-02-24 | 2011-02-23 | パナソニック株式会社 | 無線伝送装置および無線伝送装置の省電力駆動方法 |
| JP2006114973A (ja) * | 2004-10-12 | 2006-04-27 | Nec Infrontia Corp | 無線基地局及び無線端末装置 |
| JP4624062B2 (ja) * | 2004-10-12 | 2011-02-02 | Ｎｅｃインフロンティア株式会社 | 通信システム |
| US7986759B2 (en) | 2005-02-25 | 2011-07-26 | Fujitsu Limited | Data output method, data output apparatus and communication system |
| JP4509825B2 (ja) * | 2005-03-01 | 2010-07-21 | 三菱電機株式会社 | 移動体通信システム |
| JP2006245824A (ja) * | 2005-03-01 | 2006-09-14 | Mitsubishi Electric Corp | 移動体通信システム |
| 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 | Ｋｄｄｉ株式会社 | Ｔｃｐを用いたレート制御方法、サーバ及びプログラム |
| JP2008085950A (ja) * | 2006-09-29 | 2008-04-10 | Kddi Corp | Ｔｃｐを用いたレート制御方法、サーバ及びプログラム |
| JP4675409B2 (ja) * | 2008-12-08 | 2011-04-20 | 富士通株式会社 | 出力装置及び通信システム |
| JP2009105921A (ja) * | 2008-12-08 | 2009-05-14 | Fujitsu Ltd | 出力装置及び通信システム |
| US9762511B2 (en) | 2011-01-31 | 2017-09-12 | Brother Kogyo Kabushiki Kaisha | Communication device |
| JP2013013093A (ja) * | 2012-07-20 | 2013-01-17 | Thomson Licensing | Ｔｃｐａｃｋの管理によるｌａｎにおけるスループット改善 |
| JP5564603B1 (ja) * | 2013-06-07 | 2014-07-30 | ソフトバンクモバイル株式会社 | 中継ノード |
| JP2016051944A (ja) * | 2014-08-29 | 2016-04-11 | 沖電気工業株式会社 | データ中継装置、データ中継方法、及びデータ中継プログラム |
| JP2016139903A (ja) * | 2015-01-27 | 2016-08-04 | 富士通株式会社 | 通信装置、及びそのデータ中継方法 |
| US10153827B2 (en) | 2015-01-27 | 2018-12-11 | Fujitsu Limited | Communication apparatus and data relay method |
| WO2017090154A1 (ja) * | 2015-11-26 | 2017-06-01 | 株式会社日立製作所 | ストレージシステム及びストレージプログラム |
| JP2017158115A (ja) * | 2016-03-03 | 2017-09-07 | ソフトバンク株式会社 | 通信装置、通信システム、プログラム、及び通信方法 |
| WO2018056406A1 (ja) * | 2016-09-23 | 2018-03-29 | 日本電気株式会社 | プロトコル終端装置、中継方法、プログラム |
| JPWO2018056406A1 (ja) * | 2016-09-23 | 2019-07-04 | 日本電気株式会社 | プロトコル終端装置、中継方法、プログラム |
| JP2018067788A (ja) * | 2016-10-19 | 2018-04-26 | 日本電気株式会社 | 受信トラヒックの高速化装置、高速化方法、および高速化プログラム |
Also Published As
| Publication number | Publication date |
|---|---|
| JP4302339B2 (ja) | 2009-07-22 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4302339B2 (ja) | データ配信管理装置、データ配信管理システムおよびデータ配信管理方法 | |
| US6438101B1 (en) | Method and apparatus for managing congestion within an internetwork using window adaptation | |
| KR101746629B1 (ko) | 통신 장치 및 통신 방법 | |
| US7924728B2 (en) | Systems and methods for energy-conscious communication in wireless ad-hoc networks | |
| US7633880B2 (en) | Access network device for managing queue corresponding to real time multimedia traffic characteristics and method thereof | |
| US7643427B2 (en) | Multipath routing architecture for large data transfers | |
| KR101143172B1 (ko) | 웹 서비스를 위한 신뢰성 있는 메시징 프로토콜을 이용한메시지의 효율적인 전송 | |
| US6937600B2 (en) | Communication device and communication control method using lower layer data transmission order control at upper layer | |
| CN109714267B (zh) | 管理反向队列的传输控制方法及系统 | |
| US20080031149A1 (en) | Communications scheduler | |
| US20060221825A1 (en) | Congestion control network relay device and method | |
| US20060203730A1 (en) | Method and system for reducing end station latency in response to network congestion | |
| EP1378097A2 (en) | Method of controlling a queue buffer | |
| JP2004297742A (ja) | 通信装置、通信制御方法及びプログラム | |
| JP4269176B2 (ja) | セッション中継装置及び中継方法 | |
| JP3377994B2 (ja) | データ配信管理装置およびデータ配信管理方法 | |
| US8416694B2 (en) | Network feedback method and device | |
| Natarajan et al. | Non-renegable selective acknowledgments (NR-SACKs) for SCTP | |
| WO2005020524A1 (ja) | セッション中継装置及び中継方法 | |
| JP5832335B2 (ja) | 通信装置および通信システム | |
| JP3893247B2 (ja) | データ配信管理装置 | |
| US8724458B2 (en) | Methods and devices for controlling data unit handling | |
| JP3782308B2 (ja) | データ配信管理装置、これを用いたデータ配信管理システムおよびデータ配信管理方法ならびにその方法をコンピュータに実行させるプログラム | |
| TWI831622B (zh) | 網路流壅塞管理裝置及其方法 | |
| TW202335471A (zh) | 網路流壅塞管理裝置及其方法 |
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 |