JP2002217988A - データ配信管理装置およびデータ配信管理方法 - Google Patents

Abstract

(57)【要約】 【課題】 送信装置と受信装置との間における通信に関
する矛盾を解消するとともに、仮の送達確認応答の作成
および送信に関する負荷を軽減し、一層、高速かつ正確
にデータの配信を行うこと。 【解決手段】 送信したデータに対する送達確認応答を
必要とする送信装置Ｃ１と受信装置Ｃ２との間の伝送路
上に配置され、回線２の伝送遅延が回線３の伝送遅延に
比して小さく、送信装置Ｃ１からのデータを受信装置Ｃ
２に対して転送する転送処理と該転送したデータに対す
る送達確認応答を作成し返送する返送処理とを行うこと
ができるデータ配信管理装置１０において、ＳＧ配信管
理部１６は、送信装置Ｃ１が送信したデータが遅延に依
存するプロトコルであるか否かを判断し、遅延に依存す
るプロトコルであると判断した場合のみ、送達確認応答
の返送処理を行わせる。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】この発明は、送信したデータ
に対する送達確認応答を必要とする送信装置と該送信装
置の通信相手先である受信装置との間の伝送路上に配置
され、前記送信装置との間の伝送遅延が前記受信装置と
の間の伝送遅延に比して小さく、少なくとも前記送信装
置からのデータを前記受信装置に対して転送する転送処
理と該転送したデータに対する送達確認応答を作成し返
送する返送処理とを行うことができるデータ配信管理装
置に関し、特にデータ配信時における送達確認応答の受
信タイミングに依存した速度性能劣化を改善することが
できるデータ配信管理装置およびデータ配信管理方法に
関するものである。

【０００２】

【従来の技術】図２２は、従来のデータ配信管理装置を
用いたデータ配信管理システムの構成を示すブロック図
である（情報処理学会研究報告98-DPS-89-12参照）。図
２２において、このデータ配信管理システムは、送信装
置Ｃ１１と、受信装置Ｃ１２と、この送信装置Ｃ１１お
よび受信装置Ｃ１２にＴＣＰによる通信を行う回線Ｌ１
１，Ｌ１２を介してそれぞれ接続された送信ゲートウェ
イ１００とを有する。回線Ｌ１２は、回線Ｌ１１に比し
て伝送遅延が大きい回線であり、たとえば衛星回線であ
る。

【０００３】図２２において、送信装置Ｃ１１は、デー
タパケットを出力するデータパケット出力部１１１と、
送信ゲートウェイ１００が作成した仮の到達確認応答を
受信する仮到達確認応答受信部１１２とを有する。送信
ゲートウェイ１００は、バッファ１０１および配信管理
テーブル１０１を有するとともに、送信装置Ｃ１１から
送信されたデータパケットを受信し、このデータパケッ
トをバッファ１０１に蓄積させる蓄積部１０３と、回線
Ｌ１２を介してバッファ１０１に蓄積したデータデータ
パケットを受信装置Ｃ１２に出力する出力部１０４と、
受信装置Ｃ１２に送信したデータパケットに対する仮の
送達確認応答を作成する仮送達確認応答作成部１０５
と、この作成した仮の送達確認応答を送信装置Ｃ１１に
送信する仮送達確認応答送信部１０６と、受信装置Ｃ１
２から送られた送達確認応答を受信する送達確認応答受
信部１０７と、受信したＳＹＮ（接続要求）パケットか
ら通信情報を取得し、配信管理テーブル１０２に配信情
報として記録する配信情報記録制御部１０８と、データ
パケットの再送処理を行う再送処理部１０９とを有す
る。また、受信装置Ｃ１２は、送信ゲートウェイ１００
から送られたデータパケットを受信するデータパケット
受信部１２１と、送信ゲートウェイ１００に対して送達
確認応答を出力する送達確認応答出力部１２２とを有す
る。

【０００４】送信装置Ｃ１１からデータパケットが送出
されると、送信ゲートウェイ１００は、受信したデータ
パケットをバッファ１０１に一時的に蓄積するととも
に、配信管理テーブル１０２に、このデータパケットの
エントリを追加する。送信ゲートウェイ１００は、送信
装置Ｃ１１から受信したデータパケットを、回線Ｌ１２
を介して受信装置Ｃ１２に転送するとともに、このデー
タパケットに対する仮の到達確認応答のデータパケット
を作成し、送信装置Ｃ１１にこの仮の到達確認応答を送
信する。

【０００５】受信装置Ｃ１２は、送信ゲートウェイ１０
０からデータパケットを受信すると、この受信データパ
ケットに対する送達確認応答を作成し、この送達確認応
答を送信ゲートウェイ１００に送信する。この送達確認
応答には、対応するデータパケットに関するデータとこ
のデータパケットの到達確認状況に関するデータとが含
まれる。受信装置Ｃ１２から送達確認応答を受信した送
信ゲートウェイ１００は、送信ゲートウェイ１００内に
保持されているデータパケットであって、この送達確認
応答に対応するデータパケットをクリアする。

【０００６】ここで、送信ゲートウェイ１００から受信
装置Ｃ１２にデータパケットが送信される過程におい
て、このデータパケットの転送に失敗し、受信装置Ｃ１
２がこのデータパケットを受信することができなかった
場合、送信ゲートウェイ１００は、受信装置Ｃ１２側か
ら同一の送達確認応答を３つ続けて受信し、このデータ
パケットの再送処理を行う。

【０００７】このように、従来のデータ配信管理システ
ムでは、送信ゲートウェイ１００が、送信ゲートウェイ
１００から受信装置Ｃ１２に対するデータパケットの送
信と同時に、送信装置Ｃ１１に対して仮の送達確認応答
（ｔｍｐＡＣＫ）を返送することによって、回線Ｌ１２
の伝送賃によるＴＣＰのウィンドウサイズの減少を防
ぎ、スループットの低下をなくして速度性能の劣化を改
善していた。

【０００８】また、送信ゲートウェイ１００は、送信装
置からデータパケットを受信すると、仮の送達確認応答
を作成し、受信装置からの送達確認応答（ＡＣＫ）を受
け付けるまで、このデータパケットを保持し、３つの同
一の送達確認応答（ＤｕｐｌｉｃａｔｅＡＣＫ）を受信
した時点で、このデータパケットの送信を失敗と判定
し、この保持しているデータパケットの再送を行うよう
にしていた。

【０００９】

【発明が解決しようとする課題】しかしながら、従来の
データ配信管理システムでは、伝送遅延に影響されない
プロトコルのデータセグメント、あるいは仮の送達確認
応答を用いると伝送効率が悪化するプロトコルのデータ
セグメントの存在を考慮しておらず、全てのデータセグ
メントに対して、仮の送達確認応答を送信装置Ｃ１１側
に返送していたため、送信ゲートウェイ１００および送
信装置Ｃ１１の処理負荷が大きくなり、逆に速度性能が
劣化する場合が生じるという問題点があった。

【００１０】また、上述したように、全てのデータセグ
メントに対して、仮の送達確認応答を送信装置Ｃ１１側
に返送しているので、送信装置Ｃ１１側からの間違った
データセグメントや、ＢＧＰなどのウィンドウ以外のデ
ータセグメントとして解釈されるデータセグメントを受
信した場合であっても、仮の送達確認応答を送信装置Ｃ
１１側に返送するため、通信に矛盾が生じる場合があ
り、この場合、送信ゲートウェイ１００および送信装置
Ｃ１１の処理負荷が大きくなり、結果として速度性能が
劣化するという問題点があった。

【００１１】さらに、受信装置Ｃ１２から送られた送達
確認応答は、送信ゲートウェイ１００において全て破棄
され、送信装置Ｃ１１には転送されないため、受信装置
Ｃ１２から送信装置Ｃ１１に送信されるデータセグメン
ト内に、受信装置Ｃ１２から送られる送達確認応答が含
まれている、いわゆる「ＰｉｇｇｙＢａｃｋ」の手法を
用いて送信されている場合、受信装置Ｃ１２から送信装
置Ｃ１１に対するデータセグメントが、送信装置Ｃ１１
側に届かないという問題点があった。

【００１２】この発明は、上記に鑑みてなされたもの
で、送信装置と受信装置との間における通信に関する矛
盾を解消するとともに、仮の送達確認応答の作成および
送信に関する負荷を軽減し、一層、高速かつ正確にデー
タの配信を行うことができるデータ配信管理装置および
データ配信管理方法を得ることを目的とする。

【００１３】

【課題を解決するための手段】上記目的を達成するた
め、この発明にかかるデータ配信管理装置は、送信した
データに対する送達確認応答を必要とする通信を行う第
１の端末装置と該第１の端末装置の通信相手先である第
２の端末装置との間の伝送路上に配置され、少なくとも
前記第１の端末装置からのデータを前記第２の端末装置
に対して転送する転送処理と該転送したデータに対する
送達確認応答を作成し返送する返送処理とを行うことが
できるデータ配信管理装置において、前記第１の端末装
置が送信したデータが伝送遅延に依存するプロトコルで
あるか否かを判断する判断手段と、前記判断手段が伝送
遅延に依存するプロトコルであると判断した場合、前記
送達確認応答の返送処理を行わせることができる管理制
御手段とを備えたことを特徴とする。

【００１４】この発明によれば、判断手段が、前記第１
の端末装置が送信したデータが伝送遅延に依存するプロ
トコルであるか否かを判断し、管理制御手段が、前記判
断手段が前記伝送遅延に依存するプロトコルであると判
断した場合のみ、前記送達確認応答の返送処理を行わ
せ、伝送遅延に影響されないプロトコルの場合あるいは
仮の送達確認応答を用いると効率が悪くなるプロトコル
の場合などに返送処理を行わないようにしている。

【００１５】つぎの発明にかかるデータ配信管理装置
は、送信したデータに対する送達確認応答を必要とする
通信を行う第１の端末装置と該第１の端末装置の通信相
手先である第２の端末装置との間の伝送路上に配置さ
れ、少なくとも前記第１の端末装置からのデータを前記
第２の端末装置に対して転送する転送処理と該転送した
データに対する送達確認応答を作成し返送する返送処理
とを行うことができるデータ配信管理装置において、前
記第１の端末装置が送信したデータの宛先がエラーの多
い回線を経由するか否かを判断する判断手段と、前記判
断手段がエラーの多い回線を経由すると判断した場合、
前記送達確認応答の返送処理を行わせることができる管
理制御手段とを備えたことを特徴とする。

【００１６】この発明によれば、判断手段が、前記第１
の端末装置が送信したデータの宛先がエラーの多い回線
を経由するか否かを判断し、管理制御手段が、前記判断
手段がエラーの多い回線を経由すると判断した場合、前
記送達確認応答の返送処理を行わせ、エラーに起因する
スループットの低下を防止するようにしている。

【００１７】つぎの発明にかかるデータ配信管理装置
は、上記の発明において、前記判断手段は、前記第１の
端末装置が送信したデータが、エラーに依存してスルー
プットを低下させる可能性のあるプロトコルであるか否
かをさらに判断し、前記管理制御手段は、前記判断手段
が、エラーの多い回線を経由し、かつエラーに依存して
スループットを低下させる可能性のあるプロトコルであ
る判断した場合、前記送達確認応答の返送処理を行わせ
ることができることを特徴とする。

【００１８】この発明によれば、前記判断手段が、前記
第１の端末装置が送信したデータが、エラーに依存して
スループットを低下させる可能性のあるプロトコルであ
るか否かをさらに判断し、前記管理制御手段は、前記判
断手段が、エラーの多い回線を経由し、かつエラーに依
存してスループットを低下させる可能性のあるプロトコ
ルである判断した場合、前記送達確認応答の返送処理を
行わせ、送達確認応答の返送処理を、プロトコル毎に判
断するようにしている。

【００１９】つぎの発明にかかるデータ配信管理装置
は、上記の発明において、前記判断手段は、少なくとも
前記伝送遅延に依存するプロトコルであるか否かあるい
はエラーの多い回線を経由するか否かを判断し、前記管
理制御手段は、前記判断手段が、前記伝送遅延に依存す
るプロトコルである、あるいはエラーの多い回線を経由
すると判断した場合、前記送達確認応答の返送処理を行
わせることができることを特徴とする。

【００２０】この発明によれば、判断手段が、少なくと
も前記伝送遅延に依存するプロトコルであるか否かある
いはエラーの多い回線を経由するか否かを判断し、前記
管理制御手段は、前記判断手段が、前記伝送遅延に依存
するプロトコルである、あるいはエラーの多い回線を経
由すると判断した場合、前記送達確認応答の返送処理を
行わせ、伝送遅延のみによる影響の回避、エラーのみに
よる影響の回避、および伝送遅延およびエラーによる影
響の回避を行うようにしている。

【００２１】つぎの発明にかかるデータ配信管理装置
は、上記の発明において、前記第１の端末装置が送信し
たデータが通信開始に関するデータであるか否かを判断
する通信開始判断手段を備え、前記管理制御手段は、前
記通信開始判断手段が通信開始に関するデータであると
判断した場合、前記送達確認応答の返送処理を行わせな
い管理制御を行うことを特徴とする。

【００２２】この発明によれば、通信開始判断手段が、
前記第１の端末装置が送信したデータが通信開始に関す
るデータであるか否かを判断し、前記管理制御手段が、
前記通信開始判断手段が通信開始に関するデータである
と判断した場合、前記送達確認応答の返送処理を行わせ
ない管理制御を行うようにしている。

【００２３】つぎの発明にかかるデータ配信管理装置
は、上記の発明において、前記第１の端末装置が送信し
たデータが通信終了に関するデータであるか否かを判断
する通信終了判断手段を備え、前記管理制御手段は、前
記通信終了判断手段が通信終了に関するデータであると
判断した場合、前記送達確認応答の返送処理を行わせな
い管理制御を行うことを特徴とする。

【００２４】この発明によれば、通信終了判断手段が、
前記第１の端末装置が送信したデータが通信終了に関す
るデータであるか否かを判断し、前記管理制御手段が、
前記通信終了判断手段が通信終了に関するデータである
と判断した場合、前記送達確認応答の返送処理を行わせ
ない管理制御を行うようにしている。

【００２５】つぎの発明にかかるデータ配信管理装置
は、上記の発明において、前記第１の端末装置が送信し
たデータが前記第２の端末装置において正しく受理され
るデータであるか否かを判断する受信判断手段を備え、
前記管理制御手段は、前記受信判断手段が前記第２の端
末装置において正しく受理されるデータでないと判断し
た場合、前記送達確認応答の返送処理を行わせない管理
制御を行うことを特徴とする。

【００２６】この発明によれば、受信判断手段が、前記
第１の端末装置が送信したデータが前記第２の端末装置
において正しく受理されるデータであるか否かを判断
し、前記管理制御手段が、前記受信判断手段が前記第２
の端末装置において正しく受理されるデータでないと判
断した場合、前記送達確認応答の返送処理を行わせない
管理制御を行うようにしている。

【００２７】つぎの発明にかかるデータ配信管理装置
は、上記の発明において、前記第１の端末装置および前
記第２の端末装置から受信した任意のデータのヘッダ情
報から、前記第１の端末装置と前記第２の端末装置との
間の通信に関する情報を取得する情報取得手段と、前記
情報取得手段が取得した通信に関する情報を保持する情
報保持手段とを備え、前記判断手段、通信開始判断手
段、通信終了判断手段あるいは受信判断手段は、前記通
信に関する情報をもとに判断することを特徴とする。

【００２８】この発明によれば、情報取得手段が、前記
第１の端末装置および前記第２の端末装置から受信した
任意のデータのヘッダ情報から、前記第１の端末装置と
前記第２の端末装置との間の通信に関する情報を取得
し、情報保持手段が、前記情報取得手段が取得した通信
に関する情報を保持し、前記判断手段、通信開始判断手
段、通信終了判断手段あるいは受信判断手段が、前記通
信に関する情報をもとに判断することによって、送達確
認応答の返送処理を行わせ、この結果、仮の送達確認応
答を用いると効率が悪くなるプロトコルの場合に返送処
理を行わないようにしている。

【００２９】つぎの発明にかかるデータ配信管理装置
は、上記の発明において、前記第１の端末装置および前
記第２の端末装置から受信した通信確立時のデータを保
持する１以上のデータバッファを備え、前記管理制御手
段は、前記１以上のデータバッファ区分および前記１以
上のデータバッファに格納されたデータ内容をもとに通
信確立後における前記返送処理の実行管理を行うことを
特徴とする。

【００３０】この発明によれば、１以上のデータバッフ
ァが、前記第１の端末装置および前記第２の端末装置か
ら受信した通信確立時のデータを保持し、前記管理制御
手段は、前記１以上のデータバッファ区分および前記１
以上のデータバッファに格納されたデータ内容をもとに
通信確立後における前記返送処理の実行管理を行うよう
にしている。

【００３１】つぎの発明にかかるデータ配信管理装置
は、上記の発明において、前記１以上のデータバッファ
は、前記第１の端末装置と前記第２の端末装置とのコネ
クション毎に設けられた複数のデータバッファであるこ
とを特徴とする。

【００３２】この発明によれば、前記１以上のデータバ
ッファを、前記第１の端末装置と前記第２の端末装置と
のコネクション毎に設けられた複数のデータバッファと
し、コネクション単位で通信を管理するようにしてい
る。

【００３３】つぎの発明にかかるデータ配信管理装置
は、上記の発明において、前記１以上のデータバッファ
を前記コネクション毎に管理する管理テーブルをさらに
備えたことを特徴とする。

【００３４】この発明によれば、管理テーブルによっ
て、前記１以上のデータバッファを前記コネクション毎
に管理するようにしている。

【００３５】つぎの発明にかかるデータ配信管理装置
は、上記の発明において、前記１以上のデータバッファ
は、プロトコル種別毎に区分された複数のデータバッフ
ァであることを特徴とする。

【００３６】この発明によれば、前記１以上のデータバ
ッファを、プロトコル種別毎に区分された複数のデータ
バッファとし、プロトコル種別毎に通信を管理するよう
にしている。

【００３７】つぎの発明にかかるデータ配信管理装置
は、上記の発明において、前記１以上のデータバッファ
をプロトコル種別毎に管理する管理テーブルをさら備え
たことを特徴とする。

【００３８】この発明によれば、管理テーブルによっ
て、前記１以上のデータバッファをプロトコル種別毎に
管理するようにしている。

【００３９】つぎの発明にかかるデータ配信管理装置
は、上記の発明において、前記第２の端末装置から送ら
れた送達確認応答を受信し、該送達確認応答の結果を保
持する結果保持手段をさらに備えたことを特徴とする。

【００４０】この発明によれば、結果保持手段が、前記
第２の端末装置から送られた送達確認応答を受信し、該
送達確認応答の結果を保持するようにしている。

【００４１】つぎの発明にかかるデータ配信管理装置
は、上記の発明において、前記第２の端末装置から受信
した送達確認応答内に前記第１の端末装置に対するデー
タが含まれているか否かをさらに判断するデータ包含判
断手段を備え、前記管理制御手段は、前記データ包含判
断手段が、前記送達確認応答内に前記第１の端末装置に
対するデータが含まれていないと判断した場合、前記結
果保持手段に保持された送達確認応答を破棄することを
特徴とする。

【００４２】この発明によれば、データ包含判断手段
が、前記第２の端末装置から受信した送達確認応答内に
前記第１の端末装置に対するデータが含まれているか否
かを判断し、管理制御手段が、前記データ包含判断手段
が前記送達確認応答内に前記第１の端末装置に対するデ
ータが含まれていないと判断した場合、前記結果保持手
段に保持された送達確認応答を破棄するようにしてい
る。

【００４３】つぎの発明にかかるデータ配信管理装置
は、上記の発明において、前記第１の端末装置と前記第
２の端末装置との間の通信に関する情報を管理する管理
手段と、前記第１の端末装置から前記第２の端末装置に
転送したデータを保持するバッファと、前記第２の端末
装置から送られる送達確認応答の時間を計時するタイマ
と、前記管理手段が管理する通信に関する情報および前
記タイマが計時する送達確認応答の時間をもとに、前記
第２の端末装置から前記送達確認応答を受信できなかっ
たデータセグメントがある場合、このデータセグメント
を前記バッファから取り出し、前記第２の端末装置に再
送する再送制御手段とをさらに備えたことを特徴とす
る。

【００４４】この発明によれば、管理手段が、前記第１
の端末装置と前記第２の端末装置との間の通信に関する
情報を管理し、バッファが、前記第１の端末装置から前
記第２の端末装置に転送したデータを保持し、タイマ
が、前記第２の端末装置から送られる送達確認応答の時
間を計時し、再送制御手段が、前記管理手段が管理する
通信に関する情報および前記タイマが計時する送達確認
応答の時間をもとに、前記第２の端末装置から前記送達
確認応答を受信できなかったデータセグメントがある場
合、このデータセグメントを前記バッファから取り出
し、前記第２の端末装置に再送するようにしている。

【００４５】つぎの発明にかかるデータ配信管理装置
は、送信したデータに対する送達確認応答を必要とする
通信を行う第１の端末装置と該第１の端末装置の通信相
手先である第２の端末装置との間の伝送路上に配置さ
れ、少なくとも前記第１の端末装置からのデータを前記
第２の端末装置に対して転送する転送処理と該転送した
データに対する送達確認応答を作成し返送する返送処理
とを行うことができるデータ配信管理装置において、受
信した各データセグメントのデータ内容をもとに各デー
タセグメントに対して前記送達確認応答を作成し返送す
る返送処理を行わせるか否かを決定する決定手段と、前
記決定手段が決定した返送処理を実行する返送処理実行
手段とを備えたことを特徴とする。

【００４６】この発明によれば、決定手段が、受信した
各データセグメントのデータ内容をもとに各データセグ
メントに対して前記送達確認応答を作成し返送する返送
処理を行わせるか否かを決定し、返送処理実行手段が、
前記決定手段が決定した返送処理を実行するようにして
いる。

【００４７】つぎの発明にかかるデータ配信管理装置
は、上記の発明において、前記決定手段が決定した前記
送達確認応答の返送処理を行わせるか否かの決定情報を
保持する決定情報保持手段をさらに備えたことを特徴と
する。

【００４８】この発明によれば、決定情報保持手段が、
前記決定手段が決定した前記送達確認応答の返送処理を
行わせるか否かの決定情報を保持するようにしている。

【００４９】つぎの発明にかかるデータ配信管理装置
は、上記の発明において、前記返送処理実行手段が、前
記送達確認応答を前記第１の端末装置に送信した場合、
該送達確認応答が返送済であることを示す返送済情報を
保持する返送済情報保持手段をさらに備えたことを特徴
とする。

【００５０】この発明によれば、前記送達確認応答を前
記第１の端末装置に送信した場合、返送済情報保持手段
に、該送達確認応答が返送済であることを示す返送済情
報を、たとえばフラグとして保持するようにしている。

【００５１】つぎの発明にかかるデータ配信管理装置
は、送信したデータに対する送達確認応答を必要とする
通信を行う第１の端末装置と該第１の端末装置の通信相
手先である第２の端末装置との間の伝送路上に配置さ
れ、少なくとも前記第１の端末装置からのデータを前記
第２の端末装置に対して転送する転送処理と該転送した
データに対する送達確認応答を作成し返送する返送処理
とを行うことができるデータ配信管理装置において、前
記第１の端末装置、前記第２の端末装置、あるいは前記
第１の端末装置および前記第２の端末装置の双方が送信
したデータの制御データを、前記送達確認応答の作成時
に用いることを特徴とする。

【００５２】この発明によれば、返送処理を行う場合、
前記第１の端末装置、前記第２の端末装置、あるいは前
記第１の端末装置および前記第２の端末装置の双方が送
信したデータの制御データを、前記送達確認応答の作成
時に用いるようにしている。

【００５３】つぎの発明にかかるデータ配信管理装置
は、上記の発明において、前記第１の端末装置、前記第
２の端末装置、あるいは前記第１の端末装置および前記
第２の端末装置の双方が送信したデータの制御データを
保存する保存手段を備え、前記保存手段に保存された制
御データを、前記送達確認応答の作成時に用いることを
特徴とする。

【００５４】この発明によれば、保存手段が、前記第１
の端末装置、前記第２の端末装置、あるいは前記第１の
端末装置および前記第２の端末装置の双方が送信したデ
ータの制御データを保存し、この保存された制御データ
を、前記送達確認応答の作成時に用いるようにしてい
る。

【００５５】つぎの発明にかかるデータ配信管理装置
は、上記の発明において、前記第１の端末装置、前記第
２の端末装置、あるいは前記第１の端末装置および前記
第２の端末装置の双方が送信したデータの制御データか
ら前記送達確認応答の作成時に用いるデータを取得する
取得手段を備え、前記取得手段が取得したデータを前記
送達確認応答の作成時に用いることを特徴とする。

【００５６】この発明によれば、取得手段が、前記第１
の端末装置、前記第２の端末装置、あるいは前記第１の
端末装置および前記第２の端末装置の双方が送信したデ
ータの制御データから前記送達確認応答の作成時に用い
るデータを取得し、この取得したデータを前記送達確認
応答の作成時に用いるようにしている。

【００５７】つぎの発明にかかるデータ配信管理装置
は、上記の発明において、前記取得手段が取得した制御
データを保持する保持手段をさらに備え、前記保持手段
に保持された制御データを前記送達確認応答の作成時に
用いることを特徴とする。

【００５８】この発明によれば、保持手段が、前記取得
手段が取得した制御データを保持し、この保持手段に保
持された制御データを前記送達確認応答の作成時に用い
るようにしている。

【００５９】つぎの発明にかかるデータ配信管理装置
は、上記の発明において、一度用いた送達確認応答を再
度、次の送達確認応答作成の際に用いることを特徴とす
る。

【００６０】この発明によれば、一度用いた送達確認応
答を再度、次の送達確認応答作成の際に用いるようにし
ている。

【００６１】つぎの発明にかかるデータ配信管理装置
は、上記の発明において、前記送達確認応答を作成する
際、前記第２の端末装置から前記第１の端末装置に向け
て送られたデータに、このデータに対応して前記第２の
端末装置から前記第１の端末装置に向けて送られた送達
確認応答を含める情報結合手段をさらに備え、前記情報
結合手段によって結合されたデータを前記第１の端末装
置に送信することを特徴とする。

【００６２】この発明によれば、情報結合手段が、前記
送達確認応答を作成する際、前記第２の端末装置から前
記第１の端末装置に向けて送られたデータに、このデー
タに対応して前記第２の端末装置から前記第１の端末装
置に向けて送られた送達確認応答とを含め、前記情報結
合手段によって結合されたデータを前記第１の端末装置
に送信するようにし、たとえばＰｉｇｇｙＢａｃｋの手
法を用いて第１の端末装置から送信されたデータを確実
に第２の端末装置に送信するようにしている。

【００６３】つぎの発明にかかるデータ配信管理装置
は、上記の発明において、最終データセグメントでなく
かつ前記第２の端末装置において未受信の送達確認応答
作成のためにカウントすべきデータセグメントである、
未受信データセグメントの個数を示す所定数を有し、該
所定数の未受信データセグメントが存在するか否かをさ
らに判断するセグメント数判断手段を備え、前記管理制
御手段は、前記セグメント数判断手段が、前記未受信デ
ータセグメントが存在すると判断した場合、送達確認応
答を作成し、前記第１の端末装置に対して該送達確認応
答を送信することを特徴とする。

【００６４】この発明によれば、前記セグメント数判断
手段が、最終データセグメントでなくかつ前記第２の端
末装置において未受信の送達確認応答作成のためにカウ
ントすべきデータセグメントである、未受信データセグ
メントの個数を示す所定数を有し、該所定数が示す未受
信データセグメントが存在するか否かをさらに判断し、
前記管理制御手段は、前記セグメント数判断手段が、前
記未受信データセグメントが存在すると判断した場合、
送達確認応答を作成し、前記第１の端末装置に対して該
送達確認応答を送信するようにしている。

【００６５】つぎの発明にかかるデータ配信管理装置
は、上記の発明において、送達確認応答の送信タイミン
グに関する時間変数を有し、該時間変数が示す時間経過
時毎に、送達確認応答作成対象のセグメントを決定する
対象セグメント決定手段をさらに備え、前記管理制御手
段は、前記対象セグメント決定手段によって決定された
送達確認応答作成対象のセグメントの受信状態に対する
前記送達確認応答を作成し、該送達確認応答を前記第１
の端末装置に送信することを特徴とする。

【００６６】この発明によれば、対象セグメント決定手
段が、送達確認応答の送信タイミングに関する時間変数
を有し、該時間変数が示す時間経過時毎に、送達確認応
答作成対象のセグメントを決定し、前記管理制御手段
が、前記対象セグメント決定手段によって決定された送
達確認応答作成対象のセグメントの受信状態に対する前
記送達確認応答を作成し、該送達確認応答を前記第１の
端末装置に送信するようにしている。

【００６７】つぎの発明にかかるデータ配信管理装置
は、上記の発明において、送達確認応答の送信タイミン
グに関する受信セグメント数量変数を有し、該受信セグ
メント数量変数が示すセグメント数受信毎に、送達確認
応答作成対象のセグメントを決定する対象セグメント決
定手段をさらに備え、前記管理制御手段は、前記対象セ
グメント決定手段によって決定された送達確認応答作成
対象のセグメントの受信状態に対する前記送達確認応答
を作成し、該送達確認応答を前記第１の端末装置に送信
することを特徴とする。

【００６８】この発明によれば、対象セグメント決定手
段が、送達確認応答の送信タイミングに関する受信セグ
メント数量変数を有し、該受信セグメント数量変数が示
すセグメント数受信毎に、送達確認応答作成対象のセグ
メントを決定し、前記管理制御手段が、前記対象セグメ
ント決定手段によって決定された送達確認応答作成対象
のセグメントの受信状態に対する前記送達確認応答を作
成し、該送達確認応答を前記第１の端末装置に送信する
ようにしている。

【００６９】つぎの発明にかかるデータ配信管理装置
は、上記の発明において、前記管理制御手段は、予め設
定された伝送遅延量に比して大きい伝送遅延量をもつ伝
送路から受信したデータに対しては該データの転送処理
を行い、前記予め設定された伝送遅延量に比して小さい
伝送遅延量をもつ伝送路から受信したデータに対しては
該データの転送処理および該転送したデータに対する送
達確認応答を作成し返送する返送処理を行うことを特徴
とする。

【００７０】この発明によれば、管理制御手段が、予め
設定された伝送遅延量に比して大きい伝送遅延量をもつ
伝送路から受信したデータに対しては該データの転送処
理を行い、前記予め設定された伝送遅延量に比して小さ
い伝送遅延量をもつ伝送路から受信したデータに対して
は該データの転送処理および該転送したデータに対する
送達確認応答を作成し返送する返送処理を行うようにし
ている。

【００７１】つぎの発明にかかるデータ配信管理装置
は、上記の発明において、前記第１の端末装置との間の
伝送遅延は、前記第２の端末装置との間の伝送遅延に比
して小さいことを特徴とする。

【００７２】この発明によれば、前記第１の端末装置と
の間の伝送遅延が、前記第２の端末装置との間の伝送遅
延に比して小さい場合に、送受信間の通信に関する矛盾
を解消し、第１の端末装置から第２の端末装置に対する
データ配信を高速かつ正確に行えるようにしている。

【００７３】つぎの発明にかかるデータ配信管理方法
は、送信したデータに対する送達確認応答を必要とする
通信を行う第１の端末装置と該第１の端末装置の通信相
手先である第２の端末装置との間の伝送路上に配置さ
れ、少なくとも前記第１の端末装置からのデータを前記
第２の端末装置に対して転送する転送処理と該転送した
データに対する送達確認応答を作成し返送する返送処理
とを行うことができるデータ配信管理方法において、前
記第１の端末装置が送信したデータが伝送遅延に依存す
るプロトコルであるか否かを判断する判断工程と、前記
判断工程が前記伝送遅延に依存するプロトコルであると
判断した場合、前記送達確認応答の返送処理を行わせる
ことができる管理制御工程とを含むことを特徴とする。

【００７４】この発明によれば、判断工程が、前記第１
の端末装置が送信したデータが伝送遅延に依存するプロ
トコルであるか否かを判断し、管理制御工程が、前記判
断工程が伝送遅延に依存するプロトコルであると判断し
た場合、前記送達確認応答の返送処理を行わせるように
している。

【００７５】つぎの発明にかかるデータ配信管理方法
は、送信したデータに対する送達確認応答を必要とする
通信を行う第１の端末装置と該第１の端末装置の通信相
手先である第２の端末装置との間の伝送路上に配置さ
れ、少なくとも前記第１の端末装置からのデータを前記
第２の端末装置に対して転送する転送処理と該転送した
データに対する送達確認応答を作成し返送する返送処理
とを行うことができるデータ配信管理方法において、前
記第１の端末装置が送信したデータの宛先がエラーの多
い回線を経由するか否かを判断する判断工程と、前記判
断工程がエラーの多い回線を経由すると判断した場合、
前記送達確認応答の返送処理を行わせることができる管
理制御工程とを含むことを特徴とする。

【００７６】この発明によれば、判断工程が、前記第１
の端末装置が送信したデータの宛先がエラーの多い回線
を経由するか否かを判断し、管理制御工程が、前記判断
工程がエラーの多い回線を経由すると判断した場合、前
記送達確認応答の返送処理を行わせることができるよう
にし、エラーに起因するスループットの低下を防止する
ようにしている。

【００７７】つぎの発明にかかるデータ配信管理方法
は、上記の発明において、前記判断工程は、前記第１の
端末装置が送信したデータが、エラーに依存してスルー
プットを低下させる可能性のあるプロトコルであるか否
かをさらに判断し、エラーの多い回線を経由するか否か
を判断し、前記管理制御工程は、前記判断工程が、エラ
ーの多い回線を経由し、かつエラーに依存してスループ
ットを低下させる可能性のあるプロトコルであると判断
した場合、前記送達確認応答の返送処理を行わせること
ができることを特徴とする。

【００７８】この発明によれば、前記判断工程が、前記
第１の端末装置が送信したデータが、エラーに依存して
スループットを低下させる可能性のあるプロトコルであ
るか否かをさらに判断し、前記管理制御工程は、前記判
断工程が、エラーの多い回線を経由し、かつエラーに依
存してスループットを低下させる可能性のあるプロトコ
ルであると判断した場合、前記送達確認応答の返送処理
を行わせ、送達確認応答の返送処理を、プロトコル毎に
判断するようにしている。

【００７９】つぎの発明にかかるデータ配信管理方法
は、上記の発明において、前記判断工程は、少なくとも
前記伝送遅延に依存するプロトコルであるか否かあるい
はエラーの多い回線を経由するか否かを判断し、前記管
理制御工程は、前記判断工程が、前記伝送遅延に依存す
るプロトコルである、あるいはエラーの多い回線を経由
すると判断した場合、前記送達確認応答の返送処理を行
わせることができることを特徴とする。

【００８０】この発明によれば、前記判断工程が、少な
くとも前記伝送遅延に依存するプロトコルであるか否か
あるいはエラーの多い回線を経由するか否かを判断し、
前記管理制御工程は、前記判断工程が、前記伝送遅延に
依存するプロトコルである、あるいはエラーの多い回線
を経由すると判断した場合、前記送達確認応答の返送処
理を行わせ、伝送遅延のみによる影響の回避、エラーの
みによる影響の回避、および伝送遅延およびエラーによ
る影響の回避を行うようにしている。

【００８１】つぎの発明にかかるデータ配信管理方法
は、上記の発明において、前記第１の端末装置が送信し
たデータが通信開始に関するデータであるか否かを判断
する通信開始判断工程を含み、前記管理制御工程は、前
記通信開始判断工程が通信開始に関するデータであると
判断した場合、前記送達確認応答の返送処理を行わせな
い管理制御を行うことを特徴とする。

【００８２】この発明によれば、通信開始判断工程が、
前記第１の端末装置が送信したデータが通信開始に関す
るデータであるか否かを判断し、管理制御工程が、前記
通信開始判断工程が通信開始に関するデータであると判
断した場合、前記送達確認応答の返送処理を行わせない
管理制御を行うようにしている。

【００８３】つぎの発明にかかるデータ配信管理方法
は、前記第１の端末装置が送信したデータが通信終了に
関するデータであるか否かを判断する通信終了判断工程
を含み、前記管理制御工程は、前記通信終了判断工程が
通信終了に関するデータであると判断した場合、前記送
達確認応答の返送処理を行わせない管理制御を行うこと
を特徴とする。

【００８４】この発明によれば、通信終了判断工程が、
前記第１の端末装置が送信したデータが通信終了に関す
るデータであるか否かを判断し、管理制御工程が、前記
通信終了判断工程が通信終了に関するデータであると判
断した場合、前記送達確認応答の返送処理を行わせない
管理制御を行うようにしている。

【００８５】つぎの発明にかかるデータ配信管理方法
は、上記の発明において、前記第１の端末装置が送信し
たデータが前記第２の端末装置において正しく受理され
るデータであるか否かを判断する受信判断工程を含み、
前記管理制御工程は、前記受信判断工程が前記第２の端
末装置において正しく受理されるデータでないと判断し
た場合、前記送達確認応答の返送処理を行わせない管理
制御を行うことを特徴とする。

【００８６】この発明によれば、受信判断工程が、前記
第１の端末装置が送信したデータが前記第２の端末装置
において正しく受理されるデータであるか否かを判断
し、前記管理制御工程が、前記受信判断工程が前記第２
の端末装置において正しく受理されるデータでないと判
断した場合、前記送達確認応答の返送処理を行わせない
管理制御を行うようにしている。

【００８７】

【発明の実施の形態】以下、添付図面を参照して、この
発明にかかるデータ配信管理装置およびデータ配信管理
方法の好適な実施の形態を詳細に説明する。

【００８８】実施の形態１．図１は、この発明の実施の
形態１であるデータ配信管理装置を含むデータ配信管理
システムの構成を示すブロック図である。図１におい
て、このデータ配信管理システムは、送信装置Ｃ１が回
線２を介してデータ配信管理装置１０に接続され、デー
タ配信管理装置１０が回線３を介して受信装置Ｃ２に接
続される。回線３は、衛星回線などの伝送遅延の大きな
回線であり、回線２は、回線３に比して伝送遅延が小さ
い回線である。

【００８９】データ配信管理装置１０は、送信ゲートウ
ェイＳＧと、配信管理テーブル１と、プロトコル管理テ
ーブル５と、送信バッファ６と、受信バッファ７とを有
する。送信ゲートウェイＳＧは、送信装置Ｃ１との間に
おいてデータパケットの入出力処理を行う通信部１７
と、受信装置Ｃ２との間においてデータパケットの入出
力処理を行う通信部１１と、仮の送達確認応答（ｔｍｐ
ＡＣＫ）を作成するために、受信したデータパケットを
保存するｔｍｐＡＣＫバッファ４と、受信装置Ｃ２に対
して送信したデータパケットに対してｔｍｐＡＣＫの返
送を行うか否かを判断するｔｍｐＡＣＫ使用判定部１
２、送信装置Ｃ１から受信したデータパケットをもとに
ｔｍｐＡＣＫを作成するｔｍｐＡＣＫ作成部１３と、デ
ータパケット毎の送達確認応答のタイムアウト時間（Ｓ
ＧＴｉｍｅｒ）をカウントアップし、この送達確認応答
待ちのタイムアウトイベントを発生させるＳＧＴｉｍｅ
ｒカウント部１４と、送信装置Ｃ１にｔｍｐＡＣＫを送
信したか否かの情報および受信装置Ｃ２からの送達確認
応答に関する情報を配信管理テーブル１に書き込む処理
を行う配信データ記録部１５と、ＳＧＴｉｍｅｒ値およ
び配信管理テーブル１の内容に対応してデータパケット
の配信を管理するＳＧ配信管理部１６とを有する。

【００９０】なお、図１において、送信バッファ６、受
信バッファ７、およびｔｍｐＡＣＫバッファ４は、それ
ぞれ別個のバッファとして示されているが、これに限ら
ず、部分的あるいは全てを同一のバッファとして実装す
るようにしてもよい。また、別個のバッファとして実装
する場合であっても、同一のバッファとして実装する場
合であっても、管理目的に応じて制御情報などを含めた
情報とともに用いることが可能な図示しない管理テーブ
ルを設け、パケットデータの格納位置が識別可能なよう
に実装することによって、管理および検索の効率化を図
ることができる。

【００９１】ここで、図２〜図８を参照して、データ配
信管理装置１０のデータ配信管理処理について説明す
る。まず、送信ゲートウェイＳＧの通信部１７，１１
は、データパケットを受信すると、この受信したデータ
パケットを受信バッファ７に一時保存し、ＳＧ配信管理
部１６は、図２に示す配信処理を行う。

【００９２】図２において、まず、ｔｍｐＡＣＫ使用判
定部１２が、受信したデータパケットのチェックを行
い、このチェック結果に応じて送信ゲートウェイＳＧが
もつ受信データパケットに対するｔｍｐＡＣＫ利用可能
フラグの「ＯＮ」、「ＯＦＦ」を決定し、必要に応じて
ｔｍｐＡＣＫ利用可能フラグの「ＯＮ」、「ＯＦＦ」も
含め、受信データパケットの情報を配信管理テーブル１
に登録する（ステップＳ１１）。

【００９３】その後、ｔｍｐＡＣＫ制御フラグをもとに
ｔｍｐＡＣＫの利用制御を行うか否かを判断する（ステ
ップＳ１２）。ｔｍｐＡＣＫの利用制御を行わない場合
（ステップＳ１２，ＮＯ）には、そのまま本処理を終了
し、ｔｍｐＡＣＫの利用制御を行う場合（ステップＳ１
２，ＹＥＳ）には、ｔｍｐＡＣＫ利用制御処理を実行し
て（ステップＳ１３）、本処理を終了する。

【００９４】図３は、図２に示したステップＳ１１にお
けるパケットのチェック処理手順を示すフローチャート
である。図３において、まず、受信したデータパケット
のヘッダがＩＰヘッダであり、かつ正しいＩＰアドレス
であるか否かを判断する（ステップＳ２１）。すなわ
ち、この受信したデータパケットの送信元および宛先が
正しいか否かを判断する。受信したデータパケットの送
信元および宛先が正しくない場合（ステップＳ２１，Ｎ
Ｏ）には、ｔｍｐＡＣＫ利用可能フラグを「ＯＦＦ」に
設定し（ステップＳ２２）、受信したデータパケットを
宛先に転送し（ステップＳ２３）、ステップＳ１１にリ
ターンする。なお、このｔｍｐＡＣＫ利用可能フラグ
は、上述した別個のバッファあるいは同一のバッファに
設けられる図示しない管理テーブルを用いる場合、この
管理テーブル内の情報として保持するようにしてもよ
い。

【００９５】受信したデータパケットの送信元および宛
先が正しい場合（ステップＳ２１，ＹＥＳ）、ｔｍｐＡ
ＣＫ使用判定部１２は、プロトコル管理テーブル５を用
いて、ＩＰヘッダのプロトコルが遅延依存であるか否か
を判断する（ステップＳ２４）。ＩＰヘッダのプロトコ
ルが遅延依存である場合（ステップＳ２４，ＹＥＳ）に
は、さらにＴＣＰヘッダの送信元ポートおよび宛先ポー
トを参照し、送信元ポートおよび宛先ポート、または送
信元ポートあるいは宛先ポートのいずれか一方が遅延依
存であるか否かを判断する（ステップＳ２５）。ＩＰヘ
ッダのプロトコルが遅延依存でない場合（ステップＳ２
４，ＮＯ）およびＴＣＰヘッダの送信元ポートおよび／
または宛先ポートが遅延依存でない場合（ステップＳ２
５，ＮＯ）には、ｔｍｐＡＣＫ利用可能フラグを「ＯＦ
Ｆ」に設定し（ステップＳ２２）、さらに受信したデー
タパケットを宛先に転送し（ステップＳ２３）、ステッ
プＳ１１にリターンする。

【００９６】ここで、図４は、ｔｍｐＡＣＫ使用判定部
１２が用いるプロトコル管理テーブル５内の判定テーブ
ルの一例を示す図である。図４において、参照ヘッダの
項目Ｄ１は、判定対象のデータパケットの判定に用いる
ヘッダ部を示している。また、プロトコル名の項目Ｄ２
は、参照ヘッダの項目Ｄ１で指定したヘッダ部にあるデ
ータのプロトコルの種別項目を示している。さらに、ス
プーフィング使用可否の項目Ｄ３は、ｔｍｐＡＣＫの返
送処理を用いるべきプロトコルであるか否かを示す情報
を表している。この判定テーブルをもとにしたステップ
Ｓ２４，Ｓ２５の具体的な判断処理について説明する
と、まず、ステップＳ２４において、ｔｍｐＡＣＫ使用
判定部１２は、受信したデータパケットのＩＰヘッダの
プロトコルを示すバイト列を参照し、ＴＣＰのデータを
受信したと判定された場合、ステップＳ２５において、
ＴＣＰヘッダ部の送信元ポート番号を参照し、ＢＧＰで
ないと判定された場合に、ｔｍｐＡＣＫの返送処理を利
用できると判断できる。一方、ＢＧＰのデータを受信し
た場合は、ｔｍｐＡＣＫの返送処理を利用できないと判
断できる。

【００９７】また、ステップＳ２４において、ＩＰヘッ
ダのプロトコル部にある上位プロトコルが送信ゲートウ
ェイＳＧにおいて遅延依存のプロトコルではないとされ
た場合（ステップＳ２４，ＮＯ）、上述したようにｔｍ
ｐＡＣＫ利用可能フラグを「ＯＦＦ」にし（ステップＳ
２２）、受信したデータパケットを宛先に転送し（ステ
ップＳ２３）、ステップＳ１１にリターンする。一方、
ステップＳ２４において、上位プロトコルが遅延依存の
プロトコルであると判断され、ステップＳ２５におい
て、ＴＣＰヘッダの送信元ポート番号をもとに、遅延依
存のプロトコルではないとされた場合も、上述したよう
にｔｍｐＡＣＫ利用可能フラグを「ＯＦＦ」にし（ステ
ップＳ２２）、受信したデータパケットを宛先に転送し
（ステップＳ２３）、ステップＳ１１にリターンする。

【００９８】さて、ステップＳ２４，Ｓ２５において、
遅延依存のプロトコルである判断された場合には、受信
したデータパケットのヘッダ部のコードビットの値を参
照し、通信開始時のデータパケットであるか否かを判断
する（ステップＳ２６）。図示しない開始時パケットバ
ッファとして専用のバッファを設ける。あるいは、受信
バッファ７および送信バッファ６などのバッファを用い
て、図示しない開始時パケットバッファとしてもよい。
なお、図示しない開始時パケットバッファに保存するデ
ータパケットを、送信装置毎、受信装置毎、通信する送
信装置および受信装置の組み合わせ毎、通信する装置お
よび通信ポートが同一のものを一つの通信として定義し
た場合における通信毎、あるいは通信の種類毎にタグを
付けて管理するようにしてもよい。

【００９９】通信開始時のデータパケットでない場合
（ステップＳ２６，ＮＯ）には、受信したデータパケッ
トが、配信管理テーブル１に既に登録済の通信であるか
否かの判断を行う（ステップＳ２７）。このステップＳ
２７では、ＩＰヘッダ中の送信元ＩＰとＴＣＰヘッダ中
の送信元ポートとの組み合わせおよび宛先ＩＰと宛先ポ
ートとの組み合わせが全て同一の通信を同一の管理単位
とし、登録済の通信であると判断する。

【０１００】ここで、図５は、配信管理テーブルの一例
を示す図である。図５において、項目Ｄ１１〜Ｄ１５
は、管理単位が同じ通信に関する情報を表す項目であ
り、項目Ｄ１６〜Ｄ１８は、管理単位が同じ通信におい
て送信ゲートウェイＳＧが受信したデータパケットに関
する情報を表す項目である。各項目Ｄ１１〜Ｄ１８は、
送信ゲートウェイＳＧが受信したデータパケットから取
得された情報である。項目Ｄ１１は、管理する通信の送
信元ＩＰアドレスを表し、項目Ｄ１２は、宛先ＩＰアド
レスを表し、項目Ｄ１３は、送信元ポート番号を表し、
項目Ｄ１４は、宛先ポート番号を表し、項目Ｄ１４は、
送信元および宛先におけるそれぞれの最新の送信ウィン
ドウサイズおよび受信ウィンドウサイズを表している。
また、項目Ｄ１６は、この通信において送信ゲートウェ
イＳＧが受信したデータセグメントのシーケンス番号を
表し、項目Ｄ１７は、ｔｍｐＡＣＫの送信に関する情報
を表している。この項目Ｄ１７の情報は、送信元に対し
て一定の条件が整った時などの条件付の場合を含め、送
信可能なデータパケットであるか否かの情報およびｔｍ
ｐＡＣＫを送信したか否かの情報などを値として用いる
ものである。また、項目Ｄ１８は、宛先からの送達確認
応答（ＲＲＡＣＫ）に対する情報を表すものであり、図
５では、対応するデータパケットがＲＲＡＣＫを受信済
であることを表す「ＡＣＫ受信済」およびＲＲＡＣＫの
到達を待っている状態であることを表す「ＡＣＫ待ち」
の２つの値をもつ。

【０１０１】たとえば、図５において、行ＤＤ１には、
送信元の送信装置「10.74.3.177」の送信ポート「FTP.D
ATA」から、宛先の受信装置「10.74.3.200」の宛先ポー
ト「1301」に対する通信において、送信元の送信ウィン
ドウサイズおよび受信ウィンドウサイズ、および宛先の
送信ウィンドウサイズおよび受信ウィンドウサイズは全
て16Kバイトであり、シーケンス番号「398」を持つデー
タパケットは、ｔｍｐＡＣＫの送信が「不可」、すなわ
ち、いかなる条件になった場合でも、ｔｍｐＡＣＫの送
信を行わないデータパケットであり、現時点で宛先から
の送達確認応答を待っている状態であることを表すもの
である。

【０１０２】ＳＧ配信管理部１６は、この配信管理テー
ブル１の上述した項目および必要に応じて追加する項目
を用いて、データパケットのｔｍｐＡＣＫの管理、受信
確認、および受信結果に応じた再送の制御、送信元への
ｔｍｐＡＣＫおよび宛先からの送達確認応答であるＲＲ
ＡＣＫの送信速度の制御、宛先への転送速度の制御、送
信ゲートウェイＳＧの送信バッファ６および受信バッフ
ァ７の管理を行うことができる。

【０１０３】送信ゲートウェイＳＧは、この配信管理テ
ーブル１を用いて、受信したデータパケットのＩＰヘッ
ダにある送信元ＩＰアドレスおよび宛先ＩＰアドレス、
およびＴＣＰヘッダにある送信元ポート番号および宛先
ポート番号を参照し、ＩＰヘッダ中の送信元ＩＰとＴＣ
Ｐヘッダ中の送信元ポートとの組み合わせ、および宛先
ＩＰと宛先ポートとの組み合わせで表される通信が、配
信管理テーブル１内にあるか否かの判断を行う。この判
断の結果、配信管理テーブル１に登録されていない通信
であった場合、ステップＳ２８に移行することになる。

【０１０４】また、配信管理テーブル１に登録されてい
る通信であったと判断された場合、ステップＳ３１に移
行し、受信したデータパケットが、宛先の受信ウィンド
ウ内のデータパケットであるか否かを判断し、宛先の受
信ウィンドウ内のデータパケットであった場合（ステッ
プＳ３１，ＹＥＳ）、ステップＳ３２に移行し、宛先の
受信ウィンドウ内のデータパケットでなかった場合（ス
テップＳ３１，ＮＯ）、ｔｍｐＡＣＫ利用可能フラグを
「ＯＦＦ」にし、配信管理テーブル１に、データパケッ
トに関する情報を登録し、ｔｍｐＡＣＫ利用可能フラグ
を「ＯＦＦ」に設定し（ステップＳ３９）、受信したデ
ータパケットを宛先に転送し（ステップＳ２３）、ステ
ップＳ１１にリターンする。

【０１０５】一方、ステップＳ２７において、配信管理
テーブル１に登録されている通信でないと判断された場
合、図示しない開始時パケットバッファに保存されてい
る通信のいずれかに所属するデータパケットであるか否
かを判断する（ステップＳ２８）。図示しない開始時パ
ケットバッファに保存されている通信のいずれにも所属
しないデータパケットでないと判断された場合（ステッ
プＳ２８，ＮＯ）には、ｔｍｐＡＣＫ利用可能フラグを
「ＯＦＦ」にし（ステップＳ２２）、受信したデータパ
ケットを宛先に転送し（ステップＳ２３）、ステップＳ
１１にリターンする。

【０１０６】ステップＳ２８において、図示しない開始
時パケットバッファにある通信であると判断された場
合、さらにウィンドウ内のデータパケットであるか否か
が判断され（ステップＳ３１）、ウィンドウ内のデータ
パケットであると判断された場合（ステップＳ３１，Ｙ
ＥＳ）、さらに、通信終了のデータパケットであるか否
かが判断される（ステップＳ３２）。通信終了のデータ
パケットであった場合（ステップＳ３２，ＹＥＳ）、受
信したデータパケットのエントリを登録し、同一通信内
のデータパケットのエントリでｔｍｐＡＣＫ利用が可能
となっており、かつｔｍｐＡＣＫ送信済でないものを、
全てｔｍｐＡＣＫ利用を不可とし、送信ゲートウェイＳ
ＧのｔｍｐＡＣＫ利用可能フラグを「ＯＦＦ」にし、Ｆ
ＩＮ受信済フラグを「ＯＮ」にし（ステップＳ４０）、
受信したデータパケットを宛先に転送し（ステップＳ２
３）、ステップＳ１１にリターンする。

【０１０７】一方、ステップＳ３２において、通信終了
のデータパケットでないと判断された場合、ステップＳ
３４に移行する。また、ステップＳ２８において、図示
しない開始時パケットバッファにある通信でないと判断
された場合、送信ゲートウェイＳＧのｔｍｐＡＣＫ利用
可能フラグを「ＯＦＦ」にし（ステップＳ２２）、受信
したデータパケットを宛先に転送し（ステップＳ２
３）、ステップＳ１１にリターンする。

【０１０８】ステップＳ３４において、ウィンドウプロ
ーブか否かを判断し、ウィンドウプローブであると判断
した場合（ステップＳ３４，ＹＥＳ）、送信ゲートウェ
イＳＧのｔｍｐＡＣＫ利用可能フラグを「ＯＦＦ」に設
定し（ステップＳ３９）、受信したデータパケットを宛
先に転送し（ステップＳ２３）、ステップＳ１１にリタ
ーンする。

【０１０９】一方、ステップＳ３４において、ウィンド
ウプローブでないと判断された場合、受信したデータパ
ケットが受信装置Ｃ２からの送達確認応答であるか否か
を判断する（ステップＳ３５）。受信したデータパケッ
トが受信装置Ｃ２からの送達確認応答であった場合（ス
テップＳ３５，ＹＥＳ）、ｔｍｐＡＣＫバッファ４に、
受信したデータパケットを保存し、送信ゲートウェイＳ
ＧのＳＧ配信管理部１６に対して、受信装置Ｃ２から送
達確認応答を受信したことを通知するイベントを発生さ
せ（ステップＳ４５）、ｔｍｐＡＣＫ利用可能フラグを
「ＯＮ」に設定し（ステップＳ３６）、ステップＳ１１
にリターンする。このステップＳ３６におけるデータパ
ケットの保存とＡＣＫ受信通知とは、図６に示したＡＣ
Ｋ受信通知およびＡＣＫ用パケット作成処理によって行
われる。すなわち、まず、受信装置Ｃ２からのＡＣＫを
受信したことを通知するイベントを発生する（ステップ
Ｓ４５）。このイベント発生によって、後述する図１３
に示した受信確認処理および再送処理が実行されること
になる。その後、ｔｍｐＡＣＫバッファ４に格納された
パケットは、データ転送済みであるか否かを判断する
（ステップＳ４６）。データ転送済である場合（ステッ
プＳ４６，ＹＥＳ）には、仮ＡＣＫ用にパケットを差し
替え（ステップＳ４７）、本処理を終了する。一方、デ
ータ転送済でない場合（ステップＳ４６，ＮＯ）には、
ＰｉｇｇｙＢａｃｋのように、ＡＣＫにデータが添付さ
れているか否かを判断し（ステップＳ４８）、ＡＣＫに
データが添付されている場合（ステップＳ４８，ＹＥ
Ｓ）には、仮ＡＣＫ用にパケットを保存して（ステップ
Ｓ４９）、本処理を終了し、ＡＣＫにデータが添付され
ていない場合（ステップＳ４８，ＮＯ）には、そのまま
本処理を終了する。

【０１１０】なお、このステップＳ３６の処理は、実装
によって、たとえば、ＩＰヘッダおよびＩＰデータ部の
みなどの必要な部分のみを保存することも可能である。
また、シーケンス番号などによって、受信したデータパ
ケットが既にｔｍｐＡＣＫ作成用のデータパケットとし
て登録されていたものより、後のデータパケットである
か否かを判断し、最新すなわち最も後のデータパケット
をｔｍｐＡＣＫ作成用のデータパケットとして登録する
ようにしてもよい。また、ステップＳ３５において、受
信したデータパケットが受信装置Ｃ２からの送達確認応
答ではなかった場合（ステップＳ３５，ＮＯ）も、ｔｍ
ｐＡＣＫ作成用として、ｔｍｐＡＣＫバッファ４に、受
信したデータパケットを保存し、ｔｍｐＡＣＫ作成時に
そのデータを利用することも可能である。

【０１１１】ステップＳ３５において、受信したデータ
パケットが受信装置Ｃ２からの送達確認応答でないと判
断された場合、配信管理テーブル１に、情報を登録し、
ｔｍｐＡＣＫ利用可能フラグを「ＯＮ」に設定し（ステ
ップＳ３７）、受信したデータパケットを宛先に転送し
（ステップＳ２３）、ステップＳ１１にリターンする。
なお、ｔｍｐＡＣＫ利用可能フラグを「ＯＮ」にしたデ
ータパケットは、送信バッファ６に保存する。ステップ
Ｓ３７の処理を行う際、実装によっては、最新のデータ
パケットの到着時点における情報として、配信管理テー
ブル１の個々のデータパケットに関する情報のエントリ
毎にｔｍｐＡＣＫの利用が可能か否かの情報を設定する
ようにしてもよい。

【０１１２】一方、ステップＳ２６において、通信開始
のデータパケットであると判断された場合、現在判断を
行っているデータパケットを含めて、通信開始のデータ
パケットが通信の手順通りに正しく送受信されているか
否かの判断を行う（ステップＳ２９）。一連の作業によ
って、通信開始のデータパケットは正しい順序で到達さ
れたことを確認されたもののみ、図示しない開始時パケ
ットバッファに保存される（ステップＳ３０）。従っ
て、このステップＳ２９の判断は、受信したデータパケ
ットが、最初の通信開始時用のデータパケットである
か、あるいは同一通信における最後に受信された通信開
始時用のデータパケットの次に受信されるべきデータパ
ケットであるのかのいずれかをチェックすればよいこと
になる。その後、受信したデータパケットが受信装置Ｃ
２からの送達確認応答であるか否かを判断し（ステップ
Ｓ４１）、受信装置Ｃ２からの送達確認応答であると判
断された場合（ステップＳ４１，ＹＥＳ）、上述したス
テップＳ３６の処理を行った後、ステップＳ１１にリタ
ーンする。一方、受信装置Ｃ２からの送達確認応答でな
いと判断された場合（ステップＳ４１，ＮＯ）、送信ゲ
ートウェイＳＧのｔｍｐＡＣＫ利用可能フラグを「ＯＦ
Ｆ」にし（ステップＳ４２）、その後、受信したデータ
パケットを宛先に転送し（ステップＳ２３）、ステップ
Ｓ１１にリターンする。

【０１１３】一方、ステップＳ２９において、送信ゲー
トウェイＳＧが正しい順序で通信開始のデータパケット
を受信していないと判断された場合、受信したデータパ
ケットと同一の通信に属するものがあれば、図示しない
開始時パケットバッファから削除し（ステップＳ３
８）、送信ゲートウェイＳＧのｔｍｐＡＣＫ利用可能フ
ラグを「ＯＦＦ」にし（ステップＳ２２）、受信したデ
ータパケットを宛先に転送し（ステップＳ２３）、ステ
ップＳ１１にリターンする。

【０１１４】つぎに、図７に示すフローチャートを参照
して、図２に示したステップＳ１３によるｔｍｐＡＣＫ
利用制御処理の詳細手順について説明する。図７は、遅
延仮ＡＣＫの手法を用いない場合のｔｍｐＡＣＫの作成
および送信に関する処理を示している。ここで、遅延仮
ＡＣＫとは、ＴＣＰにおける遅延ＡＣＫの手法などと同
様に、一定時間あるいは一定パケット数の受信を待って
から仮ＡＣＫ（ｔｍｐＡＣＫ）を作成および送信するこ
とで、送信ゲートウェイＳＧの処理および送信ゲートウ
ェイＳＧとの間のフローの削減を促すことを目的とす
る。

【０１１５】図７において、まず図３に示した一連の処
理によって設定されたＦＩＮ受信済フラグの値を参照
し、通信終了のデータパケットが受信済であるか否かの
判断を行う（ステップＳ５１）。ＦＩＮパケット受信済
と判断された場合（ステップＳ５１，ＹＥＳ）、そのま
まステップＳ１３にリターンする。一方、ＦＩＮパケッ
ト受信済と判断されなかった場合（ステップＳ５１，Ｎ
Ｏ）、ｔｍｐＡＣＫバッファ４に保存してあるデータパ
ケットがＳＹＮデータパケットとＡＣＫデータパケット
（（ＳＹＮ＋ＡＣＫ）パケット）であるか否かを判断す
る（ステップＳ５２）。（ＳＹＮ＋ＡＣＫ）パケットで
あった場合（ステップＳ５２，ＹＥＳ）、未転送の（Ｓ
ＹＮ＋ＡＣＫ）パケットを宛先、すなわち送信装置Ｃ１
に転送し（ステップＳ５３）、その後、この転送した
（ＳＹＮ＋ＡＣＫ）パケットを、ｔｍｐＡＣＫバッファ
４から削除し（ステップＳ５９）、ステップＳ１３にリ
ターンする。なお、この未転送のデータ（パケット）と
は、いわゆるＰｉｇｇｙＢａｃｋのパケットである。一
方、ステップＳ５２において、ｔｍｐＡＣＫバッファ４
に保存してあるデータパケットが（ＳＹＮ＋ＡＣＫ）パ
ケットでないと判断された場合（ステップＳ５２，Ｎ
Ｏ）、ｔｍｐＡＣＫの送信に必要なデータセグメントを
受信しているか否かの判断を行う（ステップＳ５４）。

【０１１６】ステップＳ５２の処理は、配信管理テーブ
ル１を参照し、ｔｍｐＡＣＫの送信に必要なセグメント
数変数を用いて、ｔｍｐＡＣＫの送信に必要なデータセ
グメントを受信したか否かを判断する。ここで、ｔｍｐ
ＡＣＫの送信に必要なセグメント数変数とは、送信ゲー
トウェイＳＧがもつ値であり、送信ゲートウェイＳＧ
が、送信装置Ｃ１から受信したデータセグメントに対
し、ｔｍｐＡＣＫを作成および送信するためには、その
後、いくつのデータセグメントを受信する必要があるか
を示す「０」以上の値である。たとえば、このセグメン
ト数変数の値が「１」であった場合、送信ゲートウェイ
ＳＧがＮ番目のデータセグメントに対するｔｍｐＡＣＫ
を作成および送信するためには、少なくとも送信ゲート
ウェイＳＧにおいて「Ｎ＋１」番目のデータセグメント
が受信され、かつ「Ｎ＋１」番目のデータセグメントが
ＦＩＮのデータセグメントでないことが、Ｎ番目のデー
タセグメントに対するｔｍｐＡＣＫの作成および送信処
理を行う必要条件である。従って、このｔｍｐＡＣＫの
送信に必要なセグメント数変数とは、送信ゲートウェイ
ＳＧが、Ｎ以外に、幾つの受信すべきデータセグメント
があるかを示す値である。

【０１１７】ここで、ｔｍｐＡＣＫの送信に必要なセグ
メント数変数を「１」とした場合におけるプロトコルの
一例を、図８を参照して説明する。まず、送信ゲートウ
ェイＳＧは、送信装置Ｃ１から、データ（ｎ＋１）まで
の全てのデータセグメントの受信を確認し、受信装置Ｃ
２に対して送信する。さらに、送信ゲートウェイＳＧ
は、データ（ｎ＋１）に対するｔｍｐＡＣＫであるＡＣ
Ｋ（ｎ＋２）を作成する。

【０１１８】その後、送信ゲートウェイＳＧは、データ
（ｎ＋２）の受信を確認した時点ｔ１で、送信装置Ｃ１
に対してｔｍｐＡＣＫであるＡＣＫ（ｎ＋２）を送信す
る。一方、受信装置Ｃ２は、データ（ｎ＋１）を受信
し、ＡＣＫ（ｎ＋２）を作成し、送信ゲートウェイＳＧ
に送信する。

【０１１９】その後、送信ゲートウェイＳＧは、送信装
置Ｃ１から、データ（ｍ）を受け取り、このデータ
（ｍ）を受信装置Ｃ２に対して送信し、データ（ｍ＋
１）の受信を待つ。その後、送信ゲートウェイＳＧは、
データ（ｍ＋１）がＦＩＮセグメントであることを確認
し、その後のｔｍｐＡＣＫの作成および送信を行わな
い。また、送信ゲートウェイＳＧは、ＦＩＮを受信装置
Ｃ２に対して送信する（時点ｔ２）。

【０１２０】その後、受信装置Ｃ２は、データ（ｍ）を
受信し、ＡＣＫ（ｍ＋１）を作成し、送信ゲートウェイ
に送信する。これに対し、送信ゲートウェイＳＧは、Ａ
ＣＫ（ｍ＋１）を受信し、送信装置Ｃ１に対してＡＣＫ
（ｍ＋１）を送信する（時点ｔ３）。

【０１２１】さて、図７に戻り、ステップＳ５４におい
て、ｔｍｐＡＣＫの送信に必要なデータセグメントを受
信していないと判断した場合、ｔｍｐＡＣＫバッファ４
にある未転送のＡＣＫデータパケットを送信装置Ｃ１に
転送し（ステップＳ５３）、この転送したＡＣＫデータ
パケットを、ｔｍｐＡＣＫバッファ４から削除し（ステ
ップＳ５９）、ステップＳ１３にリターンする。

【０１２２】一方、ステップＳ５４において、ｔｍｐＡ
ＣＫの送信に必要なデータセグメントを受信したと判断
した場合、ｔｍｐＡＣＫの作成の対象となる送信装置Ｃ
１からのデータセグメントを決定する（ステップＳ５
５）。このステップＳ５５の処理では、配信管理テーブ
ル１を用い、送信ゲートウェイＳＧにおける受信状況、
ｔｍｐＡＣＫの送信状況、および送信装置Ｃ１と受信装
置Ｃ２との間におけるＴＣＰプロトコルのＳＡＣＫオプ
ションなどを参照して処理を行う。たとえば、ｔｍｐＡ
ＣＫの送信に必要なセグメント数変数が「１」で、ＳＡ
ＣＫオプションなしの通信の場合、配信管理テーブル１
のエントリのうち、ＡＣＫ受信待ちでありかつ、ｔｍｐ
ＡＣＫを送信しておらず、かつ自シーケンス番号よりも
シーケンス番号が小さいセグメントで全て送信ゲートウ
ェイＳＧにおいて受信されているセグメントの中で、シ
ーケンス番号が、２番目に大きいものを、ｔｍｐＡＣＫ
の作成対象のデータセグメントとして決定する。

【０１２３】なお、ｔｍｐＡＣＫの送信に必要なセグメ
ント数変数が「１」でＳＡＣＫオプションありの通信の
場合、配信管理テーブル１のエントリのうち、ＡＣＫ受
信待ちであり、かつ、ｔｍｐＡＣＫを送信しておらず、
かつ自シーケンス番号に比してシーケンス番号が小さい
データセグメントのうち、送信ゲートウェイＳＧにおい
て受信されていない連続したシーケンス番号を持つセグ
メント集合が４以下であるセグメントの中で、シーケン
ス番号が、２番目に大きいものを、ｔｍｐＡＣＫの作成
対象と決定するようにしてもよい。

【０１２４】ステップＳ５５の処理後、ｔｍｐＡＣＫ作
成バッファ４に保存してあるデータセグメントの送達確
認応答番号を、ステップＳ５５において決定したｔｍｐ
ＡＣＫの作成対象であるデータセグメントのシーケンス
番号に「１」を加えた番号に書き換えたデータセグメン
トをｔｍｐＡＣＫとして作成する。ＳＡＣＫオプション
付のＴＣＰの場合、ステップＳ５５においてＳＡＣＫオ
プションを考慮したｔｍｐＡＣＫの作成対象のデータセ
グメントを決定し、ステップＳ５６において、ＳＡＣＫ
オプションも加えた送達確認応答を作成するようにして
もよい。

【０１２５】ステップＳ５６の処理後、送信装置Ｃ１に
ｔｍｐＡＣＫを送信し（ステップＳ５７）、この送信し
たｔｍｐＡＣＫに対応する全ての配信管理テーブル１上
にエントリしてあるデータセグメントの情報をｔｍｐＡ
ＣＫ送信済に設定変更し（ステップＳ５８）、ステップ
Ｓ１３にリターンする。

【０１２６】ここで、図９および図１０に示すシーケン
ス図を参照して通信接続時における接続情報の取得およ
び管理について考察する。図９は、従来の通信接続時に
おける接続情報の取得および管理の手順を示すシーケン
ス図であり、図１０は、この実施の形態１における接続
情報の取得および管理の手順を示すシーケンス図であ
る。なお、通信接続時における接続情報の取得および管
理に関しては、図３に示したステップＳ２９，Ｓ３０の
処理が主として対応している。

【０１２７】図９に示すように、従来のデータ配信管理
装置では送信装置からのＳＹＮパケットを受けると、こ
のＳＹＮパケットを受信装置側に転送するとともに、Ｓ
ＹＮパケットであるか否かを判定し、ＳＹＮパケットで
ある場合に、このＳＹＮパケットから接続管理に関する
管理情報を切り出してバッファに保存する。この管理情
報としては、たとえば、最初のＳＹＮパケット受信時
に、このＳＹＮパケットから、送信元および宛先のＩＰ
アドレス、ポート番号などの接続識別および接続管理に
必要な情報である。なお、管理情報を切り出す対象のパ
ケットは、ＳＹＮパケットに限定されている。その後、
従来のデータ配信管理装置は、受信装置から送られたＳ
ＹＮパケットのＡＣＫパケットを受信し、ＳＹＮＡＣＫ
として送信装置に転送するとともに、バッファに保存さ
れていた管理情報をもとに、ＳＹＮパケットであるか否
かを判定し、管理情報の切り出しと保存とを行う。この
時点で、従来のデータ配信管理装置は、送信装置からＳ
ＹＮＡＣＫに対するＡＣＫを受け付け、このＳＹＮＡＣ
Ｋに対するＡＣＫを受信装置側に転送するとともに、バ
ッファに保存した管理情報をもとにＳＹＮパケットであ
るか否かの判定を行い、管理情報の切り出しと保存とを
行う。その後、通信が確立した時点で、送信装置側から
データが送られると、このデータに対して、バッファに
保存された管理情報をもとにＳＹＮパケットであるか否
かの判定を行い、判定結果をもとに、受信したデータパ
ケットをバッファに保存し、管理情報をもとに仮ＡＣＫ
の作成を行うようにしている。

【０１２８】これに対し、この実施の形態１では、図１
０に示すように、送信装置Ｃ１からＳＹＮパケットを受
信すると、従来と同様にＳＹＮパケットであるか否かの
判定を行い、ＳＹＮパケットである場合にこのＳＹＮパ
ケットをバッファに保存するが、この際、ＳＹＮパケッ
トから管理情報の切り出しを行わずに、ＳＹＮパケット
そのものをバッファに保存するようにしている。その
後、データ配信管理装置１０は、受信装置Ｃ２から送ら
れたＳＹＮパケットのＡＣＫパケットを受信し、ＳＹＮ
ＡＣＫとして送信装置Ｃ１に転送するとともに、バッフ
ァに保存されていたパケットと同一の通信をもつ正しい
順序のＳＹＮパケットであるか否かの判定を行い、正し
い順序のＳＹＮパケットである場合にこのＳＹＮパケッ
トをバッファに保存する。この時点で、データ配信管理
装置１０は、送信装置Ｃ１からＳＹＮＡＣＫに対するＡ
ＣＫを受け付け、このＡＹＮＡＣＫに対するＡＣＫを受
信装置Ｃ２側に転送するとともに、バッファに保存した
パケットと同一の通信をもつ正しい順序のＳＹＮパケッ
トであるか否かの判定を行う。この判定によって正しい
順序のＳＹＮパケットである場合、すなわち通信確立が
された場合にはじめて、このＳＹＮパケットから管理情
報を切り出してバッファに保存する。その後、この通信
が確立した後に、送信装置Ｃ１側からデータが送られる
と、このデータに対して、バッファに保存された管理情
報をもとにＳＹＮパケットであるか否かの判定を行い、
判定結果をもとに、受信したデータパケットから管理情
報の切り出しとバッファへの保存を行い、この管理情報
をもとに仮ＡＣＫの作成を行うようにしている。

【０１２９】したがって、この実施の形態１では、通信
確立前における通信開始時においてＳＹＮパケットから
管理情報の切り出し処理を行わず、ＳＹＮパケットその
ものをバッファに保存するようにしているので、通信開
始時における処理の簡略化を図ることができる。

【０１３０】同様にして、図１１および図１２に示すシ
ーケンス図を参照して通信確立後における仮ＡＣＫ作成
処理について考察する。図１１は、従来の通信確立後に
おける仮ＡＣＫ作成処理の手順を示すシーケンス図であ
り、図１２は、この実施の形態１における通信確立後に
おける仮ＡＣＫ作成処理の手順を示すシーケンス図であ
る。なお、この通信確立後における仮ＡＣＫ作成処理に
関しては、図３に示したステップＳ３６の処理が主とし
て対応している。

【０１３１】図１１に示すように、従来のデータ配信管
理装置は、通信確立後、送信装置からデータが送られる
と、このデータを受信装置に転送するとともに、このデ
ータに対して、バッファに保存された管理情報を用い
て、新規に仮ＡＣＫを作成し、送信装置に送る。この仮
ＡＣＫを受けた送信装置は、次のデータを従来のデータ
配信管理装置に送出する。一方、従来のデータ配信管理
装置からデータを受信した受信装置は、ＡＣＫの新規作
成を行って、従来のデータ配信管理装置に送出する。

【０１３２】これに対し、この実施の形態１では、図１
２に示すように、受信装置Ｃ２からＳＹＮＡＣＫを受け
ると、仮ＡＣＫパケットを作成し、この仮ＡＣＫパケッ
トを仮ＡＣＫパケットのひな形としてコピーし、ｔｍｐ
ＡＣＫバッファ４に仮ＡＣＫ作成用として保存してお
く。通信確立後、送信装置Ｃ１からデータが送られる
と、このデータを受信装置Ｃ２に転送するとともに、こ
のデータに対する仮ＡＣＫの新規作成を行う。すなわ
ち、コピーしてｔｍｐＡＣＫバッファに保存されていた
ＡＣＫパケットのシーケンス番号、確認応答番号、コー
ドビットフラグなど、必要な書き換えを行って、仮ＡＣ
Ｋを作成する。なお、このｔｍｐＡＣＫバッファ４に保
存された仮ＡＣＫのパケットに、データ部が含まれてい
た場合（ＰｉｇｇｙＢａｃｋの場合）、仮ＡＣＫ送信後
に、このデータ部を消去するようにしている。また、次
のＡＣＫが到着した場合、ｔｍｐＡＣＫバッファ４に保
存したパケットの差し替えを行う。ただし、ｔｍｐＡＣ
Ｋバッファ４に保存したパケットは、１つにする必要は
ないので、幾つか溜まった時点で、１つ残して、まとめ
て消去する、あるいは最後に消去するなどの方法をとる
ようにしてもよい。

【０１３３】したがって、この実施の形態１では、仮Ａ
ＣＫパケットをひな形としてコピーし、これをｔｍｐＡ
ＣＫバッファ４に保存し、その後の仮ＡＣＫパケットの
作成を容易にするとともに、既に作成されたオリジナル
の仮ＡＣＫパケットと、これから作成される仮ＡＣＫパ
ケットとの矛盾を解消することができる。

【０１３４】つぎに、図１３に示すフローチャートを参
照して、送信ゲートウェイＳＧのＳＧ配信管理部１６に
よる受信確認処理およびその結果による再送制御処理の
手順について説明する。この受信確認処理および再送制
御処理は、図２に示したパケットのチェック処理および
ｔｍｐＡＣＫ利用制御処理と並列して処理される。

【０１３５】図１３において、まず受信装置Ｃ２からの
送達確認応答の到着を示すイベント（ステップＳ４５参
照）を受け取ったか否かを判断する（ステップＳ６
１）。このイベントは、ステップＳ１１におけるパケッ
トのチェックの処理において発生されるイベントであ
る。送達確認応答が到着していた場合（ステップＳ６
１，ＹＥＳ）、受信装置Ｃ２からの開始通知であるか否
かを判断し（ステップＳ６９）、開始通知であった場合
（ステップＳ６９，ＹＥＳ）、本処理を終了する。一
方、受信装置Ｃ２からの開始通知でないと判断された場
合（ステップＳ６９，ＮＯ）、配信管理テーブル１に、
受信した送達確認応答が示すデータセグメントに対する
結果を記入する（ステップＳ７０）。たとえば、ＳＡＣ
Ｋオプションなしの通信の場合、配信管理テーブル１の
エントリのうち、ＡＣＫ受信待ちであり、かつ、受信し
た送達確認応答が示すデータセグメントに比してシーケ
ンス番号が小さいデータセグメントの全てをＡＣＫ受信
済にする。一方、ＳＡＣＫオプションありの通信の場
合、配信管理テーブル１のエントリのうち、ＡＣＫ受信
待ちであり、かつ、受信した送達確認応答が示すデータ
セグメントに比してシーケンス番号が小さいデータセグ
メントであり、かつ、ＳＡＣＫオプションにないデータ
セグメントの全てをＡＣＫ受信済とする。

【０１３６】ステップＳ７０の処理後、配信管理テーブ
ル１のエントリのうち、ＡＣＫ受信済のセグメントを送
信バッファ６から削除する（ステップＳ７１）。

【０１３７】一方、ステップＳ６１において、受信装置
Ｃ２からの送達確認応答受信のイベントを受けていない
と判断された場合、さらに再送タイムアウトが発生した
か否かを判断する（ステップＳ６２）。再送タイムアウ
トが発生していなかった場合（ステップＳ６２，Ｎ
Ｏ）、そのまま本処理を終了する。一方、再送タイムア
ウトが発生したと判断された場合（ステップＳ６２，Ｙ
ＥＳ）、配信管理テーブル１にあるタイムアウトが発生
したデータセグメントのエントリの再送回数をインクリ
メントし、再送フラグを「ＯＮ」にし（ステップＳ６
３）、配信終了か否かの判断を行う（ステップＳ６
４）。通常のＴＣＰ通信における配信終了のデータパケ
ットの交換を検知した場合、あるいは再送のタイムアウ
トを繰り返し、送信ゲートウェイＳＧが再送のリトライ
アウトをすることによって配信を終了する場合に、配信
終了と判断され（ステップＳ６４，ＹＥＳ）、配信終了
処理を行い（ステップＳ６５）、本処理を終了する。な
お、再送のタイムアウト値、およびリトライアウトの回
数は、送信装置Ｃ１および受信装置Ｃ２における再送の
タイムアウト値およびリトライアウト回数よりも十分に
長く設定される必要がある。

【０１３８】ステップＳ６５の処理は、配信終了状態に
よって異なる処理を行う。通常のＴＣＰ通信における配
信終了のデータパケットの交換を検知した場合、ｔｍｐ
ＡＣＫバッファ４、送信バッファ６、受信バッファ７の
全てにおいて、終了する通信におけるデータセグメント
を全て削除し、配信管理テーブル１のエントリも削除す
る。

【０１３９】一方、ステップＳ６４において、配信終了
でないと判断された場合、ステップＳ６６〜Ｓ６８の再
送処理を行う。すなわち、ステップＳ６６では、配信管
理テーブル１の再送フラグが「ＯＮ」になっているもの
を、送信バッファ６のデータセグメントを再送し、配信
管理テーブル１の再送フラグを「ＯＦＦ」にする。この
ステップＳ６６の処理後、再送タイマをリセットし（ス
テップＳ６７）、送信ゲートウェイＳＧの再送回数カウ
ンタのインクリメントを行い（ステップＳ６８）、本処
理を終了する。

【０１４０】ここで、図１４に示すフローチャートを参
照して、この実施の形態１における全体処理の概要につ
いて説明する。図１４において、まず、ステップＳ２
４，Ｓ２５に対応し、ＩＰヘッダのプロトコルが遅延依
存のプロトコルであるか、またはＴＣＰヘッダの送信元
ポートおよび／または宛先ポートが遅延依存であるかの
判断を行う（ステップＳ１０１）。たとえば、ＵＤＰ上
のアプリケーションの一つを、スプーフィング対象とす
るプロトコル判定テーブルを持って、さらに詳細な判断
を行うようにしてもよい。

【０１４１】ＩＰヘッダのプロトコルが遅延依存のプロ
トコルでなく、またはＴＣＰヘッダの送信元ポートおよ
び／または宛先ポートが遅延依存でない場合（ステップ
Ｓ１０１，ＮＯ）、受信したパケットを宛先に転送する
処理を行って（ステップＳ１０７）、本処理を終了す
る。一方、ＩＰヘッダのプロトコルが遅延依存のプロト
コルであり、かつＴＣＰヘッダの送信元ポートおよび／
または宛先ポートが遅延依存である場合（ステップＳ１
０１，ＹＥＳ）、ステップＳ２７に対応し、受信したデ
ータパケットが配信管理テーブル１に管理済みの通信で
あるか否かを判断する（ステップＳ１０２）。

【０１４２】受信したデータパケットが、配信管理テー
ブル１に管理済みの通信でない場合（ステップＳ１０
２，ＮＯ）、さらにステップＳ２８，Ｓ２９に対応し
て、正しい通信開始時パケットであるか否かを判断する
（ステップＳ１０８）。正しい通信開始時パケットであ
る場合（ステップＳ１０８，ＹＥＳ）、ステップＳ３
０，Ｓ３６，Ｓ３７に対応した通信確立処理を行った
（ステップＳ１１０）後、この受信したパケットを宛先
に転送し（ステップＳ１０７）、本処理を終了する。一
方、正しい通信開始時パケットでない場合（ステップＳ
１０８，ＮＯ）には、エラー処理を行う（ステップＳ１
０９）。このエラー処理の内容は、宛先において正しく
受信されないパケット受信時には、配信管理テーブル１
および開始時パケットバッファから、データを消去し、
スプーフィング処理を中止する。その後、ステップＳ１
０７に移行し、受信したパケットを宛先に転送する処理
を行って、本処理を終了する。

【０１４３】一方、受信したデータパケットが、配信管
理テーブル１に管理済みの通信である場合（ステップＳ
１０２，ＹＥＳ）、受信したパケットが正しいパケット
であるか否かを判断する（ステップＳ１０３）。この判
断は、ステップＳ２１，Ｓ３１の判定処理を含むＴＣＰ
が行うシンタックスチェックである。正しいパケットで
ないと判断された場合（ステップＳ１０３，ＮＯ）に
は、エラー処理を行い（ステップＳ１０９）、さらに受
信したパケットを宛先に転送し（ステップＳ１０７）、
本処理を終了する。

【０１４４】正しいパケットであると判断された場合
（ステップＳ１０３，ＹＥＳ）には、さらに受信したパ
ケットが通信終了パケットであるか否かを判断する（ス
テップＳ１０４）。この判断は、ステップＳ３２の判定
処理に対応する。すなわち、パケットのＦＩＮフラグお
よび最初のＦＩＮパケットを受信した時点で「ＯＮ」に
なったＦＩＮ受信フラグによって判定される。ここで、
通信終了パケットである場合（ステップＳ１０４，ＹＥ
Ｓ）には、通信終了処理を行い（ステップＳ１１１）、
宛先へのパケット転送を行った（ステップＳ１０７）
後、本処理を終了する。この通信終了処理は、ステップ
Ｓ４０に対応する処理であり、終了に関するパケットで
あった場合、最初のＦＩＮパケットを受信した時点でＦ
ＩＮ受信フラグを「ＯＮ」にし、ＴＣＰと同様の手法に
よって、通信終了と判定するまで、宛先へのパケットを
転送する（次の処理に進む処理を行う）。通信終了後
は、具体的には、待ち受け処理（ＴｉｍｅＷａｉｔ処
理）と同様に、バッファや配信管理テーブル１の情報を
消去する。

【０１４５】通信終了パケットでない場合（ステップＳ
１０４，ＮＯ）には、さらに遅延依存の宛先であるか否
かを判断する（ステップＳ１０５）。この遅延依存の宛
先であるか否かの判断は、ステップＳ２５，Ｓ４１に対
応し、たとえば、データ送信元（送信装置Ｃ１）の再送
タイムアウト時間（ＲＴＯ）に比して、データ配信管理
装置１０と宛先（受信装置Ｃ２）との間のＲＴＴの方が
長いか否かを判断し、ＲＴＴの方が長い場合に遅延依存
の宛先であると判断する。遅延依存の宛先でない場合
（ステップＳ１０５，ＮＯ）には、図６に示したよう
に、ＡＣＫ受信通知および仮ＡＣＫ用パケット作成の処
理を行って（ステップＳ１１２）、本処理を終了する。
一方、遅延依存の宛先である場合（ステップＳ１０５，
ＹＥＳ）には、ステップＳ１３あるいは図７に対応する
仮ＡＣＫ（ｔｍｐＡＣＫ）利用制御処理を行った（ステ
ップＳ１０６）後、受信したパケットを宛先に転送し
（ステップＳ１０７）、本処理を終了する。

【０１４６】実施の形態２．つぎに、この発明の実施の
形態２について説明する。この実施の形態２では、図７
に示したｔｍｐＡＣＫ利用制御処理を、時間による遅延
ＡＣＫの手法を用いてｔｍｐＡＣＫの作成処理および送
信処理を行うようにしている。

【０１４７】図１５は、この発明の実施の形態２である
データ配信管理装置のｔｍｐＡＣＫ利用処理手順を示す
フローチャートである。図１５において、図２に示した
一連の処理によって設定されたＦＩＮ受信済フラグの値
を参照し、通信終了のデータパケットが受信済であるか
否かの判断を行う（ステップＳ２０１）。ＦＩＮパケッ
ト受信済と判断された場合（ステップＳ２０１，ＹＥ
Ｓ）、そのままステップＳ１３にリターンする。

【０１４８】一方、ＦＩＮパケット受信済と判断されな
かった場合（ステップＳ２０１，ＮＯ）、仮ＡＣＫ用の
遅延時間が経過したことを示すフラグが立っているか否
かを判断する（ステップＳ２０２）。仮ＡＣＫ用の遅延
時間が経過していた場合（ステップＳ２０２，ＹＥ
Ｓ）、遅延仮ＡＣＫタイマおよび関連フラグをリセット
し（ステップＳ２０３）、ｔｍｐＡＣＫの送信に必要な
データセグメントを受信しているか否かを判断する（ス
テップＳ２０４）。

【０１４９】ステップＳ２０２において、仮ＡＣＫ用の
遅延時間が経過していないと判断された場合、送信ゲー
トウェイＳＧにおいて、送信装置Ｃ１に対する未転送デ
ータがあるか否かを判断し（ステップＳ２０６）、Ｐｉ
ｇｇｙＢａｃｋなどによる未転送データがなかった場合
（ステップＳ２０６，ＮＯ）は、ステップＳ１３にリタ
ーンし、未転送データがあった場合（ステップＳ２０
６，ＹＥＳ）、ステップＳ２０７に移行する。

【０１５０】ステップＳ２０７において、ｔｍｐＡＣＫ
バッファ４に保存してあるデータパケットが（ＳＹＮ＋
ＡＣＫ）パケットであるか否かを判断し、（ＳＹＮ＋Ａ
ＣＫ）パケットであった場合、未転送の（ＳＹＮ＋ＡＣ
Ｋ）パケットを宛先に転送し（ステップＳ２０５）、そ
の後、この未転送の（ＳＹＮ＋ＡＣＫ）パケットを、ｔ
ｍｐＡＣＫバッファ４から削除し（ステップＳ２１
３）、ステップＳ１３にリターンする。この未転送のパ
ケットは、いわゆるＰｉｇｇｙＢａｃｋのパケットであ
る。

【０１５１】一方、ステップＳ２０７において、ｔｍｐ
ＡＣＫバッファ４に保存してあるデータパケットが（Ｓ
ＹＮ＋ＡＣＫ）パケットでないと判断された場合、ｔｍ
ｐＡＣＫの送信に必要なデータセグメントを受信してい
るか否かの判断を行う（ステップＳ２０８）。ステップ
Ｓ２０４およびステップＳ２０８の処理では、配信管理
テーブル１を参照し、ｔｍｐＡＣＫの送信に必要なセグ
メント数変数を用いてｔｍｐＡＣＫの送信に必要なデー
タセグメントを受信したか否かを判断する。

【０１５２】ステップＳ２０４において、ｔｍｐＡＣＫ
の送信に必要なデータセグメントを受信していないと判
断された場合、ｔｍｐＡＣＫバッファ４にある未転送の
ＡＣＫパケットを送信装置Ｃ１に転送し（ステップＳ２
０５）、その後、この未転送のＡＣＫパケットを、ｔｍ
ｐＡＣＫバッファ４から削除し（ステップＳ２１３）、
ステップＳ１３にリターンする。この未転送のパケット
は、いわゆるＰｉｇｇｙＢａｃｋのパケットである。

【０１５３】一方、ステップＳ２０４，Ｓ２０８におい
て、ｔｍｐＡＣＫの送信に必要なデータセグメントを受
信したと判断された場合、ｔｍｐＡＣＫの作成の対象と
なる送信装置Ｃ１からのデータセグメントを決定する
（ステップＳ２０９）。このステップＳ２０９の処理で
は、配信管理テーブル１を用い、送信ゲートウェイＳＧ
における受信状況、ｔｍｐＡＣＫの送信状況、および送
信装置Ｃ１と受信装置Ｃ２との間のＴＣＰプロトコルの
ＳＡＣＫオプションなどを参照して処理を行う。

【０１５４】たとえば、ｔｍｐＡＣＫの送信に必要なセ
グメント数変数が「１」で、かつＳＡＣＫオプションな
しの通信の場合、配信管理テーブル１のエントリのう
ち、ｔｍｐＡＣＫの送信が可能であり、かつ、ｔｍｐＡ
ＣＫが未送信であり、かつ、ＡＣＫ受信待ちであり、か
つ、自シーケンス番号が小さいデータセグメントの全て
である、送信ゲートウェイＳＧにおいて受信しているデ
ータセグメントのなかで、シーケンス番号が最も後ろの
ものよりも、一つ前のデータセグメントをｔｍｐＡＣＫ
の作成および送信対象として決定する。また、たとえ
ば、ｔｍｐＡＣＫの送信に必要なセグメント数変数が
「１」で、かつＳＡＣＫオプションありの通信の場合、
ｔｍｐＡＣＫの送信が可能であり、かつ、ｔｍｐＡＣＫ
が未送信であり、かつ、ＡＣＫ受信待ちであり、かつ、
自シーケンス番号が小さいデータセグメントのうち、連
続したシーケンス番号を持つ未受信のセグメント群が４
つ以下である、送信ゲートウェイＳＧにおいて受信して
いるデータセグメントのなかで、シーケンス番号が最も
後ろのものよりも、一つ前のセグメントをｔｍｐＡＣＫ
の作成および送信対象として決定する。

【０１５５】ステップＳ２０９の処理後、ｔｍｐＡＣＫ
バッファ４に保存してあるデータセグメントの到達確認
応答番号を、ステップＳ２０９において決定したｔｍｐ
ＡＣＫの作成対象のデータセグメントのシーケンス番号
に「１」を加えた番号に書き換えたデータセグメント
を、ｔｍｐＡＣＫとして作成する。ＳＡＣＫオプション
付のＴＣＰの場合、ステップＳ２０９においてＳＡＣＫ
オプションを考慮したｔｍｐＡＣＫの作成対象を決定
し、ステップＳ２１０において、ＳＡＣＫオプションも
加えた送達確認応答を作成する。

【０１５６】ステップＳ２１０の処理後、送信装置Ｃ１
にｔｍｐＡＣＫを送信し（ステップＳ２１１）、この送
信したｔｍｐＡＣＫが対応する全ての配信管理テーブル
１上にエントリしてあるデータセグメントの情報をｔｍ
ｐＡＣＫ送信済に変更設定し（ステップＳ２１２）、ス
テップＳ１３にリターンする。

【０１５７】実施の形態３．つぎに、この発明の実施の
形態３について説明する。この実施の形態３では、図７
に示したｔｍｐＡＣＫ利用制御処理を、受信パケット数
による遅延ＡＣＫの手法を用いてｔｍｐＡＣＫの作成処
理および送信処理を行うようにしている。

【０１５８】図１６は、この発明の実施の形態３である
データ配信管理装置のｔｍｐＡＣＫ利用処理手順を示す
フローチャートである。図１６において、図２に示した
一連の処理によって設定されたＦＩＮ受信済フラグの値
を参照し、通信終了のデータパケットが受信済であるか
否かの判断を行う（ステップＳ３０１）。ＦＩＮパケッ
ト受信済と判断された場合（ステップＳ３０１，ＹＥ
Ｓ）、そのままステップＳ１３にリターンする。

【０１５９】一方、ＦＩＮパケット受信済と判断されな
かった場合（ステップＳ３０１，ＮＯ）、遅延分の個数
のデータセグメントを受信したか否かを判断する（ステ
ップＳ１０２）。遅延分の個数のデータセグメントを受
信した場合（ステップＳ３０２，ＹＥＳ）、遅延仮ＡＣ
Ｋタイマおよび関連フラグをリセットし（ステップＳ３
０７）、ｔｍｐＡＣＫの送信に必要なデータセグメント
を受信しているか否かを判断する（ステップＳ３０
８）。

【０１６０】ステップＳ３０２において、遅延分の個数
のデータセグメントを受信していないと判断された場
合、送信ゲートウェイＳＧにおいて、送信装置Ｃ１に対
する未転送データがあるか否かを判断し（ステップＳ３
０３）、未転送データがなかった場合（ステップＳ３０
３，ＮＯ）は、ステップＳ１３にリターンし、未転送デ
ータがあった場合（ステップＳ３０３，ＹＥＳ）、ステ
ップＳ３０４に移行する。

【０１６１】ステップＳ３０４において、ｔｍｐＡＣＫ
バッファ４に保存してあるデータパケットが（ＳＹＮ＋
ＡＣＫ）パケットであるか否かを判断し、（ＳＹＮ＋Ａ
ＣＫ）パケットであった場合、未転送の（ＳＹＮ＋ＡＣ
Ｋ）パケットを宛先に転送し（ステップＳ３０６）、そ
の後、この未転送の（ＳＹＮ＋ＡＣＫ）パケットを、ｔ
ｍｐＡＣＫバッファ４から削除し（ステップＳ３１
３）、ステップＳ１３にリターンする。この未転送のパ
ケットは、いわゆるＰｉｇｇｙＢａｃｋのパケットであ
る。

【０１６２】一方、ステップＳ３０４において、ｔｍｐ
ＡＣＫバッファ４に保存してあるデータパケットが（Ｓ
ＹＮ＋ＡＣＫ）パケットでないと判断された場合、ｔｍ
ｐＡＣＫの送信に必要なデータセグメントを受信してい
るか否かの判断を行う（ステップＳ３０５）。ステップ
Ｓ３０５およびステップＳ３０８の処理では、配信管理
テーブル１を参照し、ｔｍｐＡＣＫの送信に必要なセグ
メント数変数を用いてｔｍｐＡＣＫの送信に必要なデー
タセグメントを受信したか否かを判断する。

【０１６３】ステップＳ３０５において、ｔｍｐＡＣＫ
の送信に必要なデータセグメントを受信していないと判
断された場合、ｔｍｐＡＣＫバッファ４にある未転送の
ＡＣＫパケットを送信装置Ｃ１に転送し（ステップＳ３
０６）、その後、この未転送のＡＣＫパケットを、ｔｍ
ｐＡＣＫバッファ４から削除し（ステップＳ３１３）、
ステップＳ１３にリターンする。この未転送のパケット
は、いわゆるＰｉｇｇｙＢａｃｋのパケットである。

【０１６４】一方、ステップＳ３０５，Ｓ３０８におい
て、ｔｍｐＡＣＫの送信に必要なデータセグメントを受
信したと判断された場合、ｔｍｐＡＣＫの作成の対象と
なる送信装置Ｃ１からのデータセグメントを決定する
（ステップＳ３０９）。このステップＳ３０９の処理で
は、配信管理テーブル１を用い、送信ゲートウェイＳＧ
における受信状況、ｔｍｐＡＣＫの送信状況、および送
信装置Ｃ１と受信装置Ｃ２との間のＴＣＰプロトコルの
ＳＡＣＫオプションなどを参照して処理を行う。

【０１６５】たとえば、ｔｍｐＡＣＫの送信に必要なセ
グメント数変数が「１」で、かつＳＡＣＫオプションな
しの通信の場合、配信管理テーブル１のエントリのう
ち、ｔｍｐＡＣＫの送信が可能であり、かつ、ｔｍｐＡ
ＣＫが未送信であり、かつ、ＡＣＫ受信待ちであり、か
つ、自シーケンス番号が小さいデータセグメントの全て
である、送信ゲートウェイＳＧにおいて受信しているデ
ータセグメントのなかで、シーケンス番号が最も後ろの
ものよりも、一つ前のデータセグメントをｔｍｐＡＣＫ
の作成および送信対象として決定する。また、たとえ
ば、ｔｍｐＡＣＫの送信に必要なセグメント数変数が
「１」で、かつＳＡＣＫオプションありの通信の場合、
ｔｍｐＡＣＫの送信が可能であり、かつ、ｔｍｐＡＣＫ
が未送信であり、かつ、ＡＣＫ受信待ちであり、かつ、
自シーケンス番号が小さいデータセグメントのうち、連
続したシーケンス番号を持つ未受信のセグメント群が４
つ以下である、送信ゲートウェイＳＧにおいて受信して
いるデータセグメントのなかで、シーケンス番号が最も
後ろのものよりも、一つ前のセグメントをｔｍｐＡＣＫ
の作成および送信対象として決定する。

【０１６６】ステップＳ３０９の処理後、ｔｍｐＡＣＫ
バッファ４に保存してあるデータセグメントの到達確認
応答番号を、ステップＳ３０９において決定したｔｍｐ
ＡＣＫの作成対象のデータセグメントのシーケンス番号
に「１」を加えた番号に書き換えたデータセグメント
を、ｔｍｐＡＣＫとして作成する。ＳＡＣＫオプション
付のＴＣＰの場合、ステップＳ３０９においてＳＡＣＫ
オプションを考慮したｔｍｐＡＣＫの作成対象を決定
し、ステップＳ３１０において、ＳＡＣＫオプションも
加えた送達確認応答を作成する。

【０１６７】ステップＳ３１０の処理後、送信装置Ｃ１
にｔｍｐＡＣＫを送信し（ステップＳ３１１）、この送
信したｔｍｐＡＣＫが対応する全ての配信管理テーブル
１上にエントリしてあるデータセグメントの情報をｔｍ
ｐＡＣＫ送信済に変更設定し（ステップＳ３１２）、ス
テップＳ１３にリターンする。

【０１６８】上述した実施の形態１〜３において、図
７，図１５，図１６に示したｔｍｐＡＣＫの作成および
送信に関する一連の処理は、データパケットが受信さ
れ、ｔｍｐＡＣＫ利用可能フラグを参照し、ｔｍｐＡＣ
Ｋ利用制御のイベント、および遅延仮ＡＣＫに関わるタ
イマやカウンタによってあげられるイベントによって開
始される。

【０１６９】遅延仮ＡＣＫとは、上述したように、ＴＣ
Ｐにおける遅延ＡＣＫの手法等と同様に、一定時間ある
いは一定パケット数の受信を待ってから仮ＡＣＫを作成
および送信することによって、送信ゲートウェイＳＧの
処理および送信ゲートウェイＳＧと送信装置Ｃ１との間
のフローの削減を促すようにしている。

【０１７０】従って、遅延仮ＡＣＫに関わるタイマやカ
ウンタがあげるイベントとは、たとえば，実施の形態２
に示すように、一定時間待ってから遅延仮ＡＣＫの作成
および送信を行う方法による遅延仮ＡＣＫを用いる実装
の場合には、ｔｍｐＡＣＫ使用判定部１２は、遅延仮Ａ
ＣＫを発生させるタイミングをはかるタイマ、タイムア
ウト時間変数あるいは定数およびそれらによって「Ｏ
Ｎ」、「ＯＦＦ」の値を設定される遅延仮ＡＣＫ時間経
過フラグを持ち、一定時間ごとにｔｍｐＡＣＫ作成部１
３に対して、遅延仮ＡＣＫ用の待ち時間が来たことを知
らせるために発生するものである。

【０１７１】また、実施の形態３に示すように、一定個
数のパケットの受信を待ってから、遅延仮ＡＣＫの作成
および送信を行う方法による遅延仮ＡＣＫを用いる実装
の場合、通信ごとの受信パケット数のカウンタを持ち、
遅延に必要なパケット数あるいはバイト数に関する変数
（または定数）およびそれらによって「ＯＮ」、「ＯＦ
Ｆ」の値が設定される遅延仮ＡＣＫ必要個数受信済フラ
グを持ち、一定個数あるいはバイト数のパケットが受信
される毎に発生するものである。

【０１７２】なお、仮ＡＣＫの生成方法に関しては、送
信ゲートウェイＳＧに、遅延時間指定か、遅延個数指定
か、遅延仮ＡＣＫを用いないか、などの遅延仮ＡＣＫの
作成および送信に関するフラグを持たせることによっ
て、上述した図７，図１５，図１６に示した実施の形態
１〜３の処理の選択を行うようにしてもよい。

【０１７３】上述した実施の形態１〜３では、送信ゲー
トウェイＳＧにおいて、プロトコルの種別とプロトコル
の種類とによって、送信ゲートウェイにおいて送達確認
応答を作成し返送する機能を用いると定めている通信に
対してのみに、上述した仮の送達確認応答の作成および
返送処理を行わせるようにしている。

【０１７４】また、受信装置Ｃ２において正しく受信さ
れるセグメントであるかを判断し、受信装置Ｃ２におい
て正しく受信されるセグメントのみに対して、上述した
仮の送達確認応答の作成および返送処理を行わせるよう
にしている。

【０１７５】さらに、利用目的や通信毎に効率的にバッ
ファを管理する機能を用い、また送信ゲートウェイＳＧ
において受信装置Ｃ１からのＡＣＫセグメントやその情
報を保存し、これを用いて上述した仮の送達確認応答を
作成することによって、受信装置Ｃ２から送信装置Ｃ１
に向けたＡＣＫが含まれているデータセグメントが破棄
されることなく、送信装置Ｃ１に転送されるようにして
いる。

【０１７６】また、送信ゲートウェイＳＧにおいて、送
信装置Ｃ１に対する仮の送達確認応答を作成する際に、
遅延を導入し、送信ゲートウェイＳＧおよび送信装置Ｃ
１の処理の負荷を軽減するとともに、送信ゲートウェイ
ＳＧと送信装置Ｃ１との間の輻輳を抑えることができ
る。

【０１７７】この結果、伝送遅延に影響されないプロト
コルおよびセグメント、あるいは仮の送達確認応答を用
いると効率が悪くなるプロトコルおよびセグメントを考
慮し、かつ受信装置Ｃ２における受信確認と矛盾なく、
かつ全てのデータが確実に転送され、かつ送信装置Ｃ１
および送信ゲートウェイＳＧの処理の負荷を軽減し、か
つ送信ゲートウェイＳＧと送信装置Ｃ１との間の輻輳を
抑えた、高信頼かつ高速な通信が可能となる。

【０１７８】実施の形態４．つぎに、この発明の実施の
形態４について説明する。上述した実施の形態１〜３で
は、データ配信管理装置１０を、伝送遅延の大きな回線
３と小さな回線２との間に配置していたが、この実施の
形態４では、送信装置Ｃ１および受信装置Ｃ２がそれぞ
れ送受信機能を有する端末装置とし、受信装置Ｃ２側に
データ配信管理装置１０に相当するデータ配信管理装置
を設け、双方向の遅延に対して改善することができるよ
うにしている。

【０１７９】図１７に示すように、遅延の大きな回線３
の両端にデータ配信管理装置１０，２０を設け、各デー
タ配信管理装置１０，２０に遅延の小さい回線２ａ，２
ｂを介して端末装置Ｃ２１，Ｃ２２をそれぞれ接続す
る。ここで、端末装置Ｃ２１，Ｃ２２は、データの送信
機能および受信機能を備えている。データ配信管理装置
１０は、図１に示したデータ配信管理装置１０と同じで
あり、端末装置Ｃ２１から送られた送信データを回線３
を介して端末装置Ｃ２２に転送するとともに、端末装置
Ｃ２１に対する仮の到達確認応答の返送処理を行う。デ
ータ配信管理装置２０は、データ配信管理装置１０と同
様に、端末装置Ｃ２２から送られた送信データを、回線
３を介して端末Ｃ２１に転送するとともに、端末装置Ｃ
２２に対する仮の到達確認応答の返送処理を行う。ただ
し、データ配信管理装置１０，２０は、遅延の大きな回
線３からデータを受信した場合、このデータの転送処理
のみを行う。たとえば、データ配信管理装置２０は、デ
ータ配信管理装置１０からデータを受信した場合、この
データを端末装置Ｃ２２に転送する処理のみを行い、仮
の到達確認応答の返送処理は行わない。これによって、
双方向の遅延を改善した通信を行うことができる。

【０１８０】実施の形態５．つぎに、この発明の実施の
形態５について説明する。上述した実施の形態１〜４で
は、いずれも衛星回線などのような伝送遅延に対処する
ためのデータ配信管理装置であったが、この実施の形態
５では、バーストエラーなどの特有なエラーが発生する
無線回線などに適用できるようにしている。

【０１８１】図１８は、この発明の実施の形態５である
データ配信管理装置の構成を示すブロック図である。こ
のデータ配信管理装置は、経路回線判定テーブル８をさ
らに有し、上述した実施の形態１〜４に示したＳＧ配信
管理部１６が、つぎに示す図１９に示す処理を行い、そ
の他の構成および動作は、実施の形態１〜４と同じであ
る。

【０１８２】図１９は、この発明の実施の形態５である
データ配信管理装置の概要処理手順を示すフローチャー
トである。図１９において、まず、転送する宛先が、バ
ーストエラーなどのようにエラーが多発する回線を介す
るか否かを、経路回線判定テーブル８を参照して判断す
る（ステップＳ４００）。経路回線判定テーブル８は、
図２０に示すように、「宛先」と、「経由回線」と、エ
ラーが多いか少ないかを示す「エラー」との項目を有
し、転送すべき宛先と経由回線とに対応してエラーが多
いか少ないかの情報が格納されている。ここで、経路回
線判定テーブル８を参照して、ＳＧ配信管理部１６が、
エラーの多い回線を経由しないと判断した場合（ステッ
プＳ４００，ＮＯ）には、受信したパケットを宛先に転
送する処理を行って（ステップＳ４０７）、本処理を終
了する。一方、エラーの多い回線を経由すると判断した
場合（ステップＳ４００，ＹＥＳ）には、ステップＳ４
０１に移行する。

【０１８３】その後、ステップＳ２４，Ｓ２５に対応
し、ＩＰヘッダのプロトコルがエラー依存のプロトコル
であるか、またはＴＣＰヘッダの送信元ポートおよび／
または宛先ポートがエラー依存であるかの判断を行う
（ステップＳ４０１）。たとえば、ＵＤＰ上のアプリケ
ーションの一つを、スプーフィング対象とするプロトコ
ル判定テーブルを持って、さらに詳細な判断を行うよう
にしてもよい。

【０１８４】ＩＰヘッダのプロトコルがエラー依存のプ
ロトコルでなく、またはＴＣＰヘッダの送信元ポートお
よび／または宛先ポートがエラー依存でない場合（ステ
ップＳ４０１，ＮＯ）、受信したパケットを宛先に転送
する処理を行って（ステップＳ４０７）、本処理を終了
する。一方、ＩＰヘッダのプロトコルがエラー依存のプ
ロトコルであり、かつＴＣＰヘッダの送信元ポートおよ
び／または宛先ポートがエラー依存である場合（ステッ
プＳ４０１，ＹＥＳ）、ステップＳ２７に対応し、受信
したデータパケットが配信管理テーブル１に管理済みの
通信であるか否かを判断する（ステップＳ４０２）。

【０１８５】受信したデータパケットが、配信管理テー
ブル１に管理済みの通信でない場合（ステップＳ４０
２，ＮＯ）、さらにステップＳ２８，Ｓ２９に対応し
て、正しい通信開始時パケットであるか否かを判断する
（ステップＳ４０８）。正しい通信開始時パケットであ
る場合（ステップＳ４０８，ＹＥＳ）、ステップＳ３
０，Ｓ３６，Ｓ３７に対応した通信確立処理を行った
（ステップＳ４１０）後、この受信したパケットを宛先
に転送し（ステップＳ４０７）、本処理を終了する。一
方、正しい通信開始時パケットでない場合（ステップＳ
４０８，ＮＯ）には、エラー処理を行う（ステップＳ４
０９）。このエラー処理の内容は、宛先において正しく
受信されないパケット受信時には、配信管理テーブル１
および開始時パケットバッファから、データを消去し、
スプーフィング処理を中止する。その後、ステップＳ４
０７に移行し、受信したパケットを宛先に転送する処理
を行って、本処理を終了する。

【０１８６】一方、受信したデータパケットが、配信管
理テーブル１に管理済みの通信である場合（ステップＳ
４０２，ＹＥＳ）、受信したパケットが正しいパケット
であるか否かを判断する（ステップＳ４０３）。この判
断は、ステップＳ２１，Ｓ３１の判定処理を含むＴＣＰ
が行うシンタックスチェックである。正しいパケットで
ないと判断された場合（ステップＳ４０３，ＮＯ）に
は、処理上のエラー処理を行い（ステップＳ４０９）、
さらに受信したパケットを宛先に転送し（ステップＳ４
０７）、本処理を終了する。

【０１８７】正しいパケットであると判断された場合
（ステップＳ４０３，ＹＥＳ）には、さらに受信したパ
ケットが通信終了パケットであるか否かを判断する（ス
テップＳ４０４）。この判断は、ステップＳ３２の判定
処理に対応する。すなわち、パケットのＦＩＮフラグお
よび最初のＦＩＮパケットを受信した時点で「ＯＮ」に
なったＦＩＮ受信フラグによって判定される。ここで、
通信終了パケットである場合（ステップＳ４０４，ＹＥ
Ｓ）には、通信終了処理を行い（ステップＳ４１１）、
宛先へのパケット転送を行った（ステップＳ４０７）
後、本処理を終了する。この通信終了処理は、ステップ
Ｓ４０に対応する処理であり、終了に関するパケットで
あった場合、最初のＦＩＮパケットを受信した時点でＦ
ＩＮ受信フラグを「ＯＮ」にし、ＴＣＰと同様の手法に
よって、通信終了と判定するまで、宛先へのパケットを
転送する（次の処理に進む処理を行う）。通信終了後
は、具体的には、待ち受け処理（ＴｉｍｅＷａｉｔ処
理）と同様に、バッファや配信管理テーブル１の情報を
消去する。

【０１８８】通信終了パケットでない場合（ステップＳ
４０４，ＮＯ）には、さらにエラー依存の宛先であるか
否かを判断する（ステップＳ４０５）。このエラー依存
の宛先であるか否かの判断は、ステップＳ２５，Ｓ４１
に対応し、たとえば、送信装置Ｃ１とデータ配信管理装
置１０との間の回線のビット誤り率（ＢＥＲ）に比し
て、データ配信管理装置１０と宛先（受信装置Ｃ２）と
の間のＢＥＲが高いか否かを判断し、ＢＥＲが高い場
合、エラー依存の宛先であると判断する。エラー依存の
宛先でない場合（ステップＳ４０５，ＮＯ）には、図６
に示したように、ＡＣＫ受信通知および仮ＡＣＫ用パケ
ット作成の処理を行って（ステップＳ４１２）、本処理
を終了する。一方、エラー依存の宛先である場合（ステ
ップＳ４０５，ＹＥＳ）には、ステップＳ１３あるいは
図７に対応する仮ＡＣＫ（ｔｍｐＡＣＫ）利用制御処理
を行った（ステップＳ４０６）後、受信したパケットを
宛先に転送し（ステップＳ４０７）、本処理を終了す
る。

【０１８９】ところで、上述した処理は、バーストエラ
ーなどのエラーに起因してスループットが低下する無線
回線のような回線にも適用でき、スプーフィング処理を
行うことによって、このスループットの低下を防止する
ことができる。この場合、図２１に示す処理を行うこと
によって、バーストエラーに伴うスループットの低下
を、バッファ管理を行うことによって、スプーフィング
処理を実行し、このスループットの低下を防止するよう
にしている。図２１において、まず、データ配信管理装
置１０は、通信すべき回線がバーストエラーが生じ易い
回線であるか否かを判断する（ステップＳ５２１）。こ
の判断は、上述した経路回線判定テーブル８を参照して
判断する。

【０１９０】その後、バーストエラーが生じ易い回線で
ある場合（ステップＳ５２１，ＹＥＳ）には、転送デー
タの一時保存を行い（ステップＳ５２２）、スプーフィ
ング処理に備える。その後、一定期間、宛先からＡＣＫ
を受信しなかったか否かを判断する（ステップＳ５２
３）。ＡＣＫを受信していない場合（ステップＳ５２
３，ＹＥＳ）には、スプーフィング処理を実行し（ステ
ップＳ５２４）、スループットの低下を防止し、本処理
を終了する。このスプーフィング処理は、仮ＡＣＫの転
送を行う上述したステップＳ１３の処理に該当する。

【０１９１】一方、バーストエラーが生じ易い回線でな
い場合（ステップＳ５２１，ＮＯ）、および一定期間内
に、宛先からＡＣＫを受信した場合（ステップＳ５２
３，ＮＯ）には、本処理を終了する。なお、この処理
は、上述した遅延依存の回線に対するスプーフィング処
理と組み合わせるようにしてもよい。

【０１９２】なお、ステップＳ４０５におけるエラー依
存の判断は、その他、たとえばエラー依存の宛先である
ことを予め設定しておいてもよいし、たとえばＴＣＰの
ＣＲＣエラーなどを動的に取得して、判断するようにし
てもよい。さらに、エラーには、定常的な熱雑音による
エラーのほか、バースト的なエラーもあるため、それぞ
れの特有なエラーに対応して処理するようにしてもよ
い。また、上述した実施の形態５に示したエラー依存の
対処処理に加えて、上述した実施の形態１〜４に示した
伝送遅延の対処処理を適宜組み合わせるようにしてもよ
い。

【０１９３】

【発明の効果】以上説明したように、この発明によれ
ば、判断手段が、前記第１の端末装置が送信したデータ
が伝送遅延に依存するプロトコルであるか否かを判断
し、管理制御手段が、前記判断手段が前記伝送遅延に依
存するプロトコルであると判断した場合のみ、前記送達
確認応答の返送処理を行わせ、伝送遅延に影響されない
プロトコルの場合あるいは仮の送達確認応答を用いると
効率が悪くなるプロトコルの場合などに返送処理を行わ
ないようにしているので、データを迅速かつ確実に転送
でき、第１の端末装置および当該データ配信管理装置の
負荷が軽減され、高信頼かつ高速な通信を行うことがで
きるという効果を奏する。

【０１９４】つぎの発明によれば、判断手段が、前記第
１の端末装置が送信したデータの宛先がエラーの多い回
線を経由するか否かを判断し、管理制御手段が、前記判
断手段がエラーの多い回線を経由すると判断した場合、
前記送達確認応答の返送処理を行わせ、エラーに起因す
るスループットの低下を防止するようにしているので、
データを迅速かつ確実に転送でき、第１の端末装置およ
び当該データ配信管理装置の負荷が軽減され、高信頼か
つ高速な通信を行うことができるという効果を奏する。

【０１９５】つぎの発明によれば、前記判断手段が、前
記第１の端末装置が送信したデータが、エラーに依存し
てスループットを低下させる可能性のあるプロトコルで
あるか否かをさらに判断し、前記管理制御手段は、前記
判断手段が、エラーの多い回線を経由し、かつエラーに
依存してスループットを低下させる可能性のあるプロト
コルである判断した場合、前記送達確認応答の返送処理
を行わせ、送達確認応答の返送処理を、プロトコル毎に
判断するようにしているので、データを迅速かつ確実に
転送でき、第１の端末装置および当該データ配信管理装
置の負荷が軽減され、高信頼かつ高速な通信を行うこと
ができるという効果を奏する。

【０１９６】つぎの発明によれば、判断手段が、少なく
とも前記伝送遅延に依存するプロトコルであるか否かあ
るいはエラーの多い回線を経由するか否かを判断し、前
記管理制御手段は、前記判断手段が、前記伝送遅延に依
存するプロトコルである、あるいはエラーの多い回線を
経由すると判断した場合、前記送達確認応答の返送処理
を行わせ、伝送遅延のみによる影響の回避、エラーのみ
による影響の回避、および伝送遅延およびエラーによる
影響の回避を行うようにしているので、データを迅速か
つ確実に転送でき、第１の端末装置および当該データ配
信管理装置の負荷が軽減され、高信頼かつ高速な通信を
行うことができるという効果を奏する。

【０１９７】つぎの発明によれば、通信開始判断手段
が、前記第１の端末装置が送信したデータが通信開始に
関するデータであるか否かを判断し、管理制御手段が、
前記通信開始判断手段が通信開始に関するデータである
と判断した場合、前記送達確認応答の返送処理を行わせ
ないようにしているので、伝送遅延に影響されないプロ
トコルあるいは仮の送達確認応答を用いると効率が悪く
なるプロトコルの場合に返送処理が行われず、データを
迅速かつ確実に転送でき、第１の端末装置装置および当
該データ配信管理装置の負荷が軽減され、高信頼かつ高
速な通信を行うことができるという効果を奏する。

【０１９８】つぎの発明によれば、通信終了判断手段
が、前記第１の端末装置が送信したデータが通信終了に
関するデータであるか否かを判断し、管理制御手段が、
前記通信終了判断手段が通信終了に関するデータである
と判断した場合、前記送達確認応答の返送処理を行わせ
ないようにしているので、データを迅速かつ確実に転送
でき、第１の端末装置および当該データ配信管理装置の
負荷が軽減され、高信頼かつ高速な通信を行うことがで
きるという効果を奏する。

【０１９９】つぎの発明によれば、受信判断手段が、前
記第１の端末装置が送信したデータが前記第２の端末装
置において正しく受理されるデータであるか否かを判断
し、管理制御手段が、前記受信判断手段が前記第２の端
末装置において正しく受理されるデータでないと判断し
た場合、前記送達確認応答の返送処理を行わせず、第２
の端末装置側における受信確認と矛盾のない通信を行う
ようにしているので、データを迅速かつ確実に転送で
き、第１の端末装置および当該データ配信管理装置の負
荷が軽減され、高信頼かつ高速な通信を行うことができ
るという効果を奏する。

【０２００】つぎの発明によれば、情報取得手段が、前
記第１の端末装置および前記第２の端末装置から受信し
た任意のデータのヘッダ情報から、前記第１の端末装置
と前記第２の端末装置との間の通信に関する情報を取得
し、情報保持手段が、前記情報取得手段が取得した通信
に関する情報を保持し、前記判断手段、通信開始判断手
段、通信終了判断手段あるいは受信判断手段が、前記通
信に関する情報をもとに判断することによって、前記送
達確認応答の返送処理を行わせ、この結果、伝送遅延や
伝送誤りが生じてもスループットに影響しないプロトコ
ルあるいは仮の送達確認応答を用いると効率が悪くなる
プロトコルの場合に返送処理を行わないようにしている
ので、データを迅速かつ確実に転送でき、第１の端末装
置および当該データ配信管理装置の負荷が軽減され、高
信頼かつ高速な通信を行うことができるという効果を奏
する

【０２０１】つぎの発明によれば、１以上のデータバッ
ファが、前記第１の端末装置および前記第２の端末装置
から受信した通信確立時のデータを保持し、前記管理制
御手段は、前記１以上のデータバッファ区分および前記
１以上のデータバッファに格納されたデータ内容をもと
に通信確立後における前記返送処理の実行管理を行うよ
うにしているので、効率的な通信管理を行うことがで
き、結果として、高信頼かつ高速な通信を実現できると
いう効果を奏する。

【０２０２】つぎの発明によれば、前記１以上のデータ
バッファを、前記第１の端末装置と前記第２の端末装置
とのコネクション毎に設けられた複数のデータバッファ
とし、コネクション単位で通信を管理するようにしてい
るので、効率的な通信管理を行うことができ、結果とし
て、高信頼かつ高速な通信を実現できるという効果を奏
する。

【０２０３】つぎの発明によれば、管理テーブルによっ
て、前記１以上のデータバッファを前記コネクション毎
に管理するようにしているので、効率的な通信管理を行
うことができ、結果として、高信頼かつ高速な通信を実
現できるという効果を奏する。

【０２０４】つぎの発明によれば、前記１以上のデータ
バッファを、プロトコル種別毎に区分された複数のデー
タバッファとし、プロトコル種別毎に通信を管理するよ
うにしているので、効率的な通信管理を行うことがで
き、結果として、高信頼かつ高速な通信を実現できると
いう効果を奏する。

【０２０５】つぎの発明によれば、管理テーブルによっ
て、前記１以上のデータバッファをプロトコル種別毎に
管理するようにしているので、効率的な通信管理を行う
ことができ、結果として、高信頼かつ高速な通信を実現
できるという効果を奏する。

【０２０６】つぎの発明によれば、結果保持手段が、前
記第２の端末装置から送られた送達確認応答を受信し、
該送達確認応答の結果を保持するようにしているので、
効率的な通信管理を行うことができ、結果として、高信
頼かつ高速な通信を実現できるという効果を奏する。

【０２０７】つぎの発明によれば、データ包含判断手段
が、前記第２の端末装置から受信した送達確認応答内に
前記第１の端末装置に対するデータが含まれているか否
かを判断し、管理制御手段が、前記データ包含判断手段
が前記送達確認応答内に前記第１の端末装置に対するデ
ータが含まれていないと判断した場合、前記結果保持手
段に保持された送達確認応答を破棄するようにしている
ので、効率的かつ柔軟な送達確認応答の作成および送信
を行うことができ、高信頼かつ高速な通信を実現できる
という効果を奏する。

【０２０８】つぎの発明によれば、管理手段が、前記第
１の端末装置と前記第２の端末装置との間の通信に関す
る情報を管理し、バッファが、前記第１の端末装置から
前記第２の端末装置に転送したデータを保持し、タイマ
が、前記第２の端末装置から送られる送達確認応答の時
間を計時し、再送制御手段が、前記管理手段が管理する
通信に関する情報および前記タイマが計時する送達確認
応答の時間をもとに、前記第２の端末装置から前記送達
確認応答を受信できなかったデータセグメントがある場
合、このデータセグメントを前記バッファから取り出
し、前記第２の端末装置に再送するようにしているの
で、確実な再送制御を行うことができ、結果として、高
信頼かつ高速な通信を実現できるという効果を奏する。

【０２０９】つぎの発明によれば、決定手段が、受信し
た各データセグメントのデータ内容をもとに各データセ
グメントに対して前記送達確認応答を作成し返送する返
送処理を行わせるか否かを決定し、返送処理実行手段
が、前記決定手段が決定した返送処理を実行するように
しているので、効率的な管理制御を行うことができ、結
果として、高信頼かつ高速な通信を実現できるという効
果を奏する。

【０２１０】つぎの発明によれば、決定情報保持手段
が、前記決定手段が決定した前記送達確認応答の返送処
理を行わせるか否かの決定情報を保持するようにしてい
るので、効率的な管理制御を行うことができ、結果とし
て、高信頼かつ高速な通信を実現できるという効果を奏
する。

【０２１１】つぎの発明によれば、前記送達確認応答を
前記第１の端末装置に送信した場合、返送済情報保持手
段に、該送達確認応答が返送済であることを示す返送済
情報を、たとえばフラグとして保持するようにしている
ので、効率的な管理制御を行うことができ、結果とし
て、高信頼かつ高速な通信を実現できるという効果を奏
する。

【０２１２】つぎの発明によれば、返送処理を行う場
合、前記第１の端末装置、前記第２の端末装置、あるい
は前記第１の端末装置および前記第２の端末装置の双方
が送信したデータの制御データを、前記送達確認応答の
作成時に用いるようにしているので、高信頼かつ高速な
通信を行うことができるという効果を奏する。

【０２１３】つぎの発明によれば、保存手段が、前記第
１の端末装置、前記第２の端末装置、あるいは前記第１
の端末装置および前記第２の端末装置の双方が送信した
データの制御データを保存し、この保存された制御デー
タを、前記送達確認応答の作成時に用いるようにしてい
るので、効率的な送達確認応答の作成を行うことがで
き、高信頼かつ高速な通信を実現できるという効果を奏
する。

【０２１４】つぎの発明によれば、取得手段が、前記第
１の端末装置、前記第２の端末装置、あるいは前記第１
の端末装置および前記第２の端末装置の双方が送信した
データの制御データから前記送達確認応答の作成時に用
いるデータを取得し、この取得したデータを前記送達確
認応答の作成時に用いるようにしているので、効率的な
送達確認応答の作成を行うことができ、高信頼かつ高速
な通信を実現できるという効果を奏する。

【０２１５】つぎの発明によれば、保持手段が、前記取
得手段が取得した制御データを保持し、この保持手段に
保持された制御データを前記送達確認応答の作成時に用
いるようにしているので、効率的な送達確認応答の作成
を行うことができ、高信頼かつ高速な通信を実現できる
という効果を奏する。

【０２１６】つぎの発明によれば、一度用いた送達確認
応答を再度、次の送達確認応答作成の際に用いるように
しているので、効率的な送達確認応答の作成を行うこと
ができ、高信頼かつ高速な通信を実現できるという効果
を奏する。

【０２１７】つぎの発明によれば、情報結合手段が、前
記送達確認応答を作成する際、前記第２の端末装置から
前記第１の端末装置に向けて送られたデータに、このデ
ータに対応して前記第２の端末装置から前記第１の端末
装置に向けて送られた送達確認応答とを含め、前記情報
結合手段によって結合されたデータを前記第１の端末装
置に送信するようにし、たとえばＰｉｇｇｙＢａｃｋの
手法を用いて第１の端末装置から送信されたデータを確
実に第２の端末装置に送信するようにしているので、高
信頼かつ高速な通信を行うことができるという効果を奏
する。

【０２１８】つぎの発明によれば、前記セグメント数判
断手段が、最終データセグメントでなくかつ前記第２の
端末装置において未受信の送達確認応答作成のためにカ
ウントすべきデータセグメントである、未受信データセ
グメントの個数を示す所定数を有し、該所定数が示す未
受信データセグメントが存在するか否かをさらに判断
し、前記管理制御手段は、前記セグメント数判断手段
が、前記未受信データセグメントが存在すると判断した
場合、送達確認応答を作成し、前記第１の端末装置に対
して該送達確認応答を送信するようにしているので、効
率的かつ柔軟な送達確認応答の作成および送信を行うこ
とができ、高信頼かつ高速な通信を実現できるという効
果を奏する。

【０２１９】つぎの発明によれば、対象セグメント決定
手段が、送達確認応答の送信タイミングに関する時間変
数を有し、該時間変数が示す時間経過時毎に、送達確認
応答作成対象のセグメントを決定し、前記管理制御手段
が、前記対象セグメント決定手段によって決定された送
達確認応答作成対象のセグメントの受信状態に対する前
記送達確認応答を作成し、該送達確認応答を前記第１の
端末装置に送信するようにしているので、効率的かつ柔
軟な送達確認応答の作成および送信を行うことができ、
高信頼かつ高速な通信を実現できるという効果を奏す
る。

【０２２０】つぎの発明によれば、対象セグメント決定
手段が、送達確認応答の送信タイミングに関する受信セ
グメント数量変数を有し、該受信セグメント数量変数が
示すセグメント数受信毎に、送達確認応答作成対象のセ
グメントを決定し、前記管理制御手段が、前記対象セグ
メント決定手段によって決定された送達確認応答作成対
象のセグメントの受信状態に対する前記送達確認応答を
作成し、該送達確認応答を前記第１の端末装置に送信す
るようにしているので、効率的かつ柔軟な送達確認応答
の作成および送信を行うことができ、高信頼かつ高速な
通信を実現できるという効果を奏する。

【０２２１】つぎの発明によれば、管理制御手段が、予
め設定された伝送遅延量に比して大きい伝送遅延量をも
つ伝送路から受信したデータに対しては該データの転送
処理を行い、前記予め設定された伝送遅延量に比して小
さい伝送遅延量をもつ伝送路から受信したデータに対し
ては該データの転送処理および該転送したデータに対す
る送達確認応答を作成し返送する返送処理を行うように
しているので、たとえば、２つのデータ配信管理装置を
第１の端末装置側および第２の端末装置側に設置して、
伝送遅延の大きな伝送路を介した双方向の通信を行う場
合であっても、高信頼かつ高速の通信を実現することが
できるという効果を奏する。

【０２２２】つぎの発明によれば、前記第１の端末装置
との間の伝送遅延が、前記第２の端末装置との間の伝送
遅延に比して小さい場合に、送受信間の通信に関する矛
盾を解消し、第１の端末装置から第２の端末装置に対す
るデータ配信を高速かつ正確に行えるようにしているの
で、伝送遅延の大きい衛星回線などに具体的に適用する
ことができるという効果を奏する。

【０２２３】つぎの発明によれば、判断工程が、前記第
１の端末装置が送信したデータが伝送遅延に依存するプ
ロトコルであるか否かを判断し、管理制御工程が、前記
判断工程が伝送遅延に依存するプロトコルであると判断
した場合、前記送達確認応答の返送処理を行わせるよう
にしているので、データを迅速かつ確実に転送でき、第
１の端末装置および当該データ配信管理装置の負荷が軽
減され、高信頼かつ高速な通信を行うことができるとい
う効果を奏する。

【０２２４】つぎの発明によれば、判断工程が、前記第
１の端末装置が送信したデータの宛先がエラーの多い回
線を経由するか否かを判断し、管理制御工程が、前記判
断工程がエラーの多い回線を経由すると判断した場合、
前記送達確認応答の返送処理を行わせることができるよ
うにし、エラーに起因するスループットの低下を防止す
るようにしているので、データを迅速かつ確実に転送で
き、第１の端末装置および当該データ配信管理装置の負
荷が軽減され、高信頼かつ高速な通信を行うことができ
るという効果を奏する。

【０２２５】つぎの発明によれば、前記判断工程が、前
記第１の端末装置が送信したデータが、エラーに依存し
てスループットを低下させる可能性のあるプロトコルで
あるか否かをさらに判断し、前記管理制御工程は、前記
判断工程が、エラーの多い回線を経由し、かつエラーに
依存してスループットを低下させる可能性のあるプロト
コルであると判断した場合、前記送達確認応答の返送処
理を行わせ、送達確認応答の返送処理を、プロトコル毎
に判断するようにしているので、データを迅速かつ確実
に転送でき、第１の端末装置および当該データ配信管理
装置の負荷が軽減され、高信頼かつ高速な通信を行うこ
とができるという効果を奏する。

【０２２６】つぎの発明によれば、前記判断工程が、少
なくとも前記伝送遅延に依存するプロトコルであるか否
かあるいはエラーの多い回線を経由するか否かを判断
し、前記管理制御工程は、前記判断工程が、前記伝送遅
延に依存するプロトコルである、あるいはエラーの多い
回線を経由すると判断した場合、前記送達確認応答の返
送処理を行わせ、伝送遅延のみによる影響の回避、エラ
ーのみによる影響の回避、および伝送遅延およびエラー
による影響の回避を行うようにしているので、データを
迅速かつ確実に転送でき、第１の端末装置および当該デ
ータ配信管理装置の負荷が軽減され、高信頼かつ高速な
通信を行うことができるという効果を奏する。

【０２２７】つぎの発明によれば、通信開始判断工程
が、前記第１の端末装置が送信したデータが通信開始に
関するデータであるか否かを判断し、管理制御工程が、
前記通院開始判断工程が通信開始に関するデータである
と判断した場合、前記送達確認応答の返送処理を行わせ
ない管理制御を行うようにしているので、データを迅速
かつ確実に転送でき、第１の端末装置および当該データ
配信管理装置の負荷が軽減され、高信頼かつ高速な通信
を行うことができるという効果を奏する。

【０２２８】つぎの発明によれば、通信終了判断工程
が、前記第１の端末装置が送信したデータが通信終了に
関するデータであるか否かを判断し、管理制御工程が、
前記通信終了判断工程が通信終了に関するデータである
と判断した場合、前記送達確認応答の返送処理を行わせ
ない管理制御を行うようにしているので、データを迅速
かつ確実に転送でき、第１の端末装置および当該データ
配信管理装置の負荷が軽減され、高信頼かつ高速な通信
を行うことができるという効果を奏する。

【０２２９】つぎの発明によれば、受信判断工程が、前
記第１の端末装置が送信したデータが前記第２の端末装
置において正しく受理されるデータであるか否かを判断
し、前記管理制御工程が、前記受信判断工程が前記第２
の端末装置において正しく受理されるデータでないと判
断した場合、前記送達確認応答の返送処理を行わせない
管理制御を行うようにしているので、データを迅速かつ
確実に転送でき、第１の端末装置および当該データ配信
管理装置の負荷が軽減され、高信頼かつ高速な通信を行
うことができるという効果を奏する。

【図面の簡単な説明】

【図１】 この発明の実施の形態１であるデータ配信管
理装置を含むデータ配信管理システムの構成を示すブロ
ック図である。

【図２】 図１に示したデータ配信管理装置によるデー
タ配信管理処理手順を示すフローチャートである。

【図３】 図２に示したパケットのチェック処理手順を
示す詳細フローチャートである。

【図４】 図１に示したプロトコル管理テーブルの内容
の一例を示す図である。

【図５】 図１に示した配信管理テーブルの内容の一例
を示す図である。

【図６】 ステップＳ３６に対応したＡＣＫ受信通知お
よび仮ＡＣＫパケット作成処理手順を示すフローチャー
トである。

【図７】 図２に示したｔｍｐＡＣＫ利用制御処理手順
を示す詳細フローチャートである。

【図８】 ｔｍｐＡＣＫの送信に必要なセグメント数変
数を「１」とした場合におけるプロトコルの一例を示す
図である。

【図９】 従来の通信接続時における接続情報の取得管
理手順を示すシーケンス図である。

【図１０】 この発明の実施の形態１による通信接続時
における接続情報の取得管理手順を示すシーケンス図で
ある。

【図１１】 従来の通信確立後における仮ＡＣＫ作成処
理手順を示すシーケンス図である。

【図１２】 この発明の実施の形態１による通信確立後
における仮ＡＣＫ作成処理手順を示すシーケンス図であ
る。

【図１３】 図１に示したデータ配信管理装置による受
信確認処理および再送制御処理の手順を示すフローチャ
ートである。

【図１４】 この発明の実施の形態１であるデータ配信
管理装置の全体処理の概要を示すフローチャートであ
る。

【図１５】 この発明の実施の形態２であるデータ配信
管理装置によるｔｍｐＡＣＫ利用制御処理手順を示す詳
細フローチャートである。

【図１６】 この発明の実施の形態３であるデータ配信
管理装置によるｔｍｐＡＣＫ利用制御処理手順を示す詳
細フローチャートである。

【図１７】 この発明の実施の形態４であって、二つの
データ配信管理装置を用いて双方向通信を可能にしたデ
ータ配信管理システムの構成を示すブロック図である。

【図１８】 この発明の実施の形態５であるデータ配信
管理装置の構成を示すブロック図である。

【図１９】 この発明の実施の形態５であるデータ配信
管理装置の全体処理の概要を示すフローチャートであ
る。

【図２０】 経路回線判定テーブルの内容を示す図であ
る。

【図２１】 バーストエラーが生じ易い回線に対するス
プーフィング処理の適用処理手順を示すフローチャート
である。

【図２２】 従来のデータ配信管理装置を含むデータ配
信管理システムの構成を示すブロック図である。

【符号の説明】

１ 配信管理テーブル、２，２ａ，２ｂ，３ 回線、４
ｔｍｐＡＣＫバッファ、５ プロトコル管理テーブ
ル、６ 送信バッファ、７ 受信バッファ、１０，２０
データ配信管理装置、１１，１７ 通信部、１２ ｔ
ｍｐＡＣＫ使用判定部、１３ ｔｍｐＡＣＫ作成部、１
４ ＳＧＴｉｍｅｒカウント部、１５ 配信データ記録
部、１６ ＳＧ配信管理部、ＳＧ 送信ゲートウェイ、
Ｃ１ 送信装置、Ｃ２ 受信装置、Ｃ２１，Ｃ２２ 端
末装置。

Claims (37)

【特許請求の範囲】
1. 【請求項１】 送信したデータに対する送達確認応答を
   必要とする通信を行う第１の端末装置と該第１の端末装
   置の通信相手先である第２の端末装置との間の伝送路上
   に配置され、少なくとも前記第１の端末装置からのデー
   タを前記第２の端末装置に対して転送する転送処理と該
   転送したデータに対する送達確認応答を作成し返送する
   返送処理とを行うことができるデータ配信管理装置にお
   いて、 前記第１の端末装置が送信したデータが伝送遅延に依存
   するプロトコルであるか否かを判断する判断手段と、 前記判断手段が伝送遅延に依存するプロトコルであると
   判断した場合、前記送達確認応答の返送処理を行わせる
   ことができる管理制御手段と、 を備えたことを特徴とするデータ配信管理装置。
2. 【請求項２】 送信したデータに対する送達確認応答を
   必要とする通信を行う第１の端末装置と該第１の端末装
   置の通信相手先である第２の端末装置との間の伝送路上
   に配置され、少なくとも前記第１の端末装置からのデー
   タを前記第２の端末装置に対して転送する転送処理と該
   転送したデータに対する送達確認応答を作成し返送する
   返送処理とを行うことができるデータ配信管理装置にお
   いて、 前記第１の端末装置が送信したデータの宛先がエラーの
   多い回線を経由するか否かを判断する判断手段と、 前記判断手段がエラーの多い回線を経由すると判断した
   場合、前記送達確認応答の返送処理を行わせることがで
   きる管理制御手段と、 を備えたことを特徴とするデータ配信管理装置。
3. 【請求項３】 前記判断手段は、前記第１の端末装置が
   送信したデータが、エラーに依存してスループットを低
   下させる可能性のあるプロトコルであるか否かをさらに
   判断し、 前記管理制御手段は、前記判断手段が、エラーの多い回
   線を経由し、かつエラーに依存してスループットを低下
   させる可能性のあるプロトコルであると判断した場合、
   前記送達確認応答の返答処理を行わせることができるこ
   とを特徴とする請求項２に記載のデータ配信管理装置。
4. 【請求項４】 前記判断手段は、少なくとも前記伝送遅
   延に依存するプロトコルであるか否かあるいはエラーの
   多い回線を経由するか否かを判断し、 前記管理制御手段は、前記判断手段が、前記伝送遅延に
   依存するプロトコルである、あるいはエラーの多い回線
   を経由すると判断した場合、前記送達確認応答の返送処
   理を行わせることができることを特徴とする請求項２に
   記載のデータ配信管理装置。
5. 【請求項５】 前記第１の端末装置が送信したデータが
   通信開始に関するデータであるか否かを判断する通信開
   始判断手段を備え、 前記管理制御手段は、前記通信開始判断手段が通信開始
   に関するデータであると判断した場合、前記送達確認応
   答の返送処理を行わせない管理制御を行うことを特徴と
   する請求項１〜４のいずれか一つに記載のデータ配信管
   理装置。
6. 【請求項６】 前記第１の端末装置が送信したデータが
   通信終了に関するデータであるか否かを判断する通信終
   了判断手段を備え、 前記管理制御手段は、前記通信終了判断手段が通信終了
   に関するデータであると判断した場合、前記送達確認応
   答の返送処理を行わせない管理制御を行うことを特徴と
   する請求項１〜５のいずれか一つに記載のデータ配信管
   理装置。
7. 【請求項７】 前記第１の端末装置が送信したデータが
   前記第２の端末装置において正しく受理されるデータで
   あるか否かを判断する受信判断手段を備え、 前記管理制御手段は、前記受信判断手段が前記第２の端
   末装置において正しく受理されるデータでないと判断し
   た場合、前記送達確認応答の返送処理を行わせない管理
   制御を行うことを特徴とする請求項１〜６のいずれか一
   つに記載のデータ配信管理装置。
8. 【請求項８】 前記第１の端末装置および前記第２の端
   末装置から受信した任意のデータのヘッダ情報から、前
   記第１の端末装置と前記第２の端末装置との間の通信に
   関する情報を取得する情報取得手段と、 前記情報取得手段が取得した通信に関する情報を保持す
   る情報保持手段と、 を備え、 前記判断手段、通信開始判断手段、通信終了判断手段あ
   るいは受信判断手段は、前記通信に関する情報をもとに
   判断することを特徴とする請求項１〜７のいずれか一つ
   に記載のデータ配信管理装置。
9. 【請求項９】 前記第１の端末装置および前記第２の端
   末装置から受信した通信確立時のデータを保持する１以
   上のデータバッファを備え、 前記管理制御手段は、前記１以上のデータバッファ区分
   および前記１以上のデータバッファに格納されたデータ
   内容をもとに通信確立後における前記返送処理の実行管
   理を行うことを特徴とする請求項１〜８のいずれか一つ
   に記載のデータ配信管理装置。
10. 【請求項１０】 前記１以上のデータバッファは、前記
    第１の端末装置と前記第２の端末装置とのコネクション
    毎に設けられた複数のデータバッファであることを特徴
    とする請求項９に記載のデータ配信管理装置。
11. 【請求項１１】 前記１以上のデータバッファを前記コ
    ネクション毎に管理する管理テーブルをさらに備えたこ
    とを特徴とする請求項９または１０に記載のデータ配信
    管理装置。
12. 【請求項１２】 前記１以上のデータバッファは、プロ
    トコル種別毎に区分された複数のデータバッファである
    ことを特徴とする請求項９〜１１のいずれか一つに記載
    のデータ配信管理装置。
13. 【請求項１３】 前記１以上のデータバッファを前記プ
    ロトコル種別毎に管理する管理テーブルをさらに備えた
    ことを特徴とする請求項９〜１２のいずれか一つに記載
    のデータ配信管理装置。
14. 【請求項１４】 前記第２の端末装置から送られた送達
    確認応答を受信し、該送達確認応答の結果を保持する結
    果保持手段をさらに備えたことを特徴とする請求項８〜
    １３のいずれか一つに記載のデータ配信管理装置。
15. 【請求項１５】 前記第２の端末装置から受信した送達
    確認応答内に前記第１の端末装置に対するデータが含ま
    れているか否かをさらに判断するデータ包含判断手段を
    備え、 前記管理制御手段は、前記データ包含判断手段が、前記
    送達確認応答内に前記第１の端末装置に対するデータが
    含まれていないと判断した場合、前記結果保持手段に保
    持された送達確認応答を破棄することを特徴とする請求
    項１４に記載のデータ配信管理装置。
16. 【請求項１６】 前記第１の端末装置と前記第２の端末
    装置との間の通信に関する情報を管理する管理手段と、 前記第１の端末装置から前記第２の端末装置に転送した
    データを保持するバッファと、 前記第２の端末装置から送られる送達確認応答の時間を
    計時するタイマと、 前記管理手段が管理する通信に関する情報および前記タ
    イマが計時する送達確認応答の時間をもとに、前記第２
    の端末装置から前記送達確認応答を受信できなかったデ
    ータセグメントがある場合、このデータセグメントを前
    記バッファから取り出し、前記第２の端末装置に再送す
    る再送制御手段と、 をさらに備えたことを特徴とする請求項８〜１５のいず
    れか一つに記載のデータ配信管理装置。
17. 【請求項１７】 送信したデータに対する送達確認応答
    を必要とする通信を行う第１の端末装置と該第１の端末
    装置の通信相手先である第２の端末装置との間の伝送路
    上に配置され、少なくとも前記第１の端末装置からのデ
    ータを前記第２の端末装置に対して転送する転送処理と
    該転送したデータに対する送達確認応答を作成し返送す
    る返送処理とを行うことができるデータ配信管理装置に
    おいて、 受信した各データセグメントのウィンドウ情報をもとに
    各データセグメントに対して前記送達確認応答を作成し
    返送する返送処理を行わせるか否かを決定する決定手段
    と、 前記決定手段が決定した返送処理を実行する返送処理実
    行手段と、 を備えたことを特徴とするデータ配信管理装置。
18. 【請求項１８】 前記決定手段が決定した前記送達確認
    応答の返送処理を行わせるか否かの決定情報を保持する
    決定情報保持手段をさらに備えたことを特徴とする請求
    項１７に記載のデータ配信管理装置。
19. 【請求項１９】 前記返送処理実行手段が、前記送達確
    認応答を前記第１の端末装置に送信した場合、該送達確
    認応答が返送済であることを示す返送済情報を保持する
    返送済情報保持手段をさらに備えたことを特徴とする請
    求項１７または１８に記載のデータ配信管理装置。
20. 【請求項２０】 送信したデータに対する送達確認応答
    を必要とする通信を行う第１の端末装置と該第１の端末
    装置の通信相手先である第２の端末装置との間の伝送路
    上に配置され、少なくとも前記第１の端末装置からのデ
    ータを前記第２の端末装置に対して転送する転送処理と
    該転送したデータに対する送達確認応答を作成し返送す
    る返送処理とを行うことができるデータ配信管理装置に
    おいて、 前記第１の端末装置、前記第２の端末装置、あるいは前
    記第１の端末装置および前記第２の端末装置の双方が送
    信したデータの制御データを、前記送達確認応答の作成
    時に用いることを特徴とするデータ配信管理装置。
21. 【請求項２１】 前記第１の端末装置、前記第２の端末
    装置、あるいは前記第１の端末装置および前記第２の端
    末装置の双方が送信したデータの制御データを保存する
    保存手段を備え、 前記保存手段に保存された制御データを、前記送達確認
    応答の作成時に用いることを特徴とする請求項２０に記
    載のデータ配信管理装置。
22. 【請求項２２】 前記第１の端末装置、前記第２の端末
    装置、あるいは前記第１の端末装置および前記第２の端
    末装置の双方が送信したデータの制御データから前記送
    達確認応答の作成時に用いるデータを取得する取得手段
    を備え、 前記取得手段が取得したデータを前記送達確認応答の作
    成時に用いることを特徴とする請求項２０または２１に
    記載のデータ配信管理装置。
23. 【請求項２３】 前記取得手段が取得した制御データを
    保持する保持手段をさらに備え、 前記保持手段に保持された制御データを前記送達確認応
    答の作成時に用いることを特徴とする請求項２０に記載
    のデータ配信管理装置。
24. 【請求項２４】 一度用いた送達確認応答を再度、次の
    送達確認応答作成の際に用いることを特徴とする請求項
    ２０〜２３のいずれか一つに記載のデータ配信管理装
    置。
25. 【請求項２５】 前記送達確認応答を作成する際、前記
    第２の端末装置から前記第１の端末装置に向けて送られ
    たデータに、このデータに対応して前記第２の端末装置
    から前記第１の端末装置に向けて送られた送達確認応答
    を含める情報結合手段をさらに備え、 前記情報結合手段によって結合されたデータを前記第１
    の端末装置に送信することを特徴とする請求項２０〜２
    ４のいずれか一つに記載のデータ配信管理装置。
26. 【請求項２６】 最終データセグメントでなくかつ前記
    第２の端末装置において未受信の送達確認応答作成のた
    めにカウントすべきデータセグメントである、未受信デ
    ータセグメントの個数を示す所定数を有し、該所定数の
    未受信データセグメントが存在するか否かをさらに判断
    するセグメント数判断手段を備え、 前記管理制御手段は、前記セグメント数判断手段が、前
    記未受信データセグメントが存在すると判断した場合、
    送達確認応答を作成し、前記第１の端末装置に対して該
    送達確認応答を送信することを特徴とする請求項６〜１
    ４のいずれか一つに記載のデータ配信管理装置。
27. 【請求項２７】 送達確認応答の送信タイミングに関す
    る時間変数を有し、該時間変数が示す時間経過時毎に、
    送達確認応答作成対象のセグメントを決定する対象セグ
    メント決定手段をさらに備え、 前記管理制御手段は、前記対象セグメント決定手段によ
    って決定された送達確認応答作成対象のセグメントの受
    信状態に対する前記送達確認応答を作成し、該送達確認
    応答を前記第１の端末装置に送信することを特徴とする
    請求項８〜１６または２６のいずれか一つに記載のデー
    タ配信管理装置。
28. 【請求項２８】 送達確認応答の送信タイミングに関す
    る受信セグメント数量変数を有し、該受信セグメント数
    量変数が示すセグメント数受信毎に、送達確認応答作成
    対象のセグメントを決定する対象セグメント決定手段を
    さらに備え、 前記管理制御手段は、前記対象セグメント決定手段によ
    って決定された送達確認応答作成対象のセグメントの受
    信状態に対する前記送達確認応答を作成し、該送達確認
    応答を前記第１の端末装置に送信することを特徴とする
    請求項８〜１６または２６のいずれか一つに記載のデー
    タ配信管理装置。
29. 【請求項２９】 前記管理制御手段は、 予め設定された伝送遅延量に比して大きい伝送遅延量を
    もつ伝送路から受信したデータに対しては該データの転
    送処理を行い、前記予め設定された伝送遅延量に比して
    小さい伝送遅延量をもつ伝送路から受信したデータに対
    しては該データの転送処理および該転送したデータに対
    する送達確認応答を作成し返送する返送処理を行うこと
    を特徴とする請求項１〜２８のいずれか一つに記載のデ
    ータ配信管理装置。
30. 【請求項３０】 前記第１の端末装置との間の伝送遅延
    は、前記第２の端末装置との間の伝送遅延に比して小さ
    いことを特徴とする請求項１〜２９のいずれか一つに記
    載のデータ配信管理装置。
31. 【請求項３１】 送信したデータに対する送達確認応答
    を必要とする通信を行う第１の端末装置と該第１の端末
    装置の通信相手先である第２の端末装置との間の伝送路
    上に配置され、少なくとも前記第１の端末装置からのデ
    ータを前記第２の端末装置に対して転送する転送処理と
    該転送したデータに対する送達確認応答を作成し返送す
    る返送処理とを行うことができるデータ配信管理方法に
    おいて、 前記第１の端末装置が送信したデータが伝送遅延に依存
    するプロトコルであるか否かを判断する判断工程と、 前記判断工程が前記伝送遅延に依存するプロトコルであ
    ると判断した場合、前記送達確認応答の返送処理を行わ
    せることができる管理制御工程と、 を含むことを特徴とするデータ配信管理方法。
32. 【請求項３２】 送信したデータに対する送達確認応答
    を必要とする通信を行う第１の端末装置と該第１の端末
    装置の通信相手先である第２の端末装置との間の伝送路
    上に配置され、少なくとも前記第１の端末装置からのデ
    ータを前記第２の端末装置に対して転送する転送処理と
    該転送したデータに対する送達確認応答を作成し返送す
    る返送処理とを行うことができるデータ配信管理方法に
    おいて、 前記第１の端末装置が送信したデータの宛先がエラーの
    多い回線を経由するか否かを判断する判断工程と、 前記判断工程がエラーの多い回線を経由すると判断した
    場合、前記送達確認応答の返送処理を行わせることがで
    きる管理制御工程と、 を含むことを特徴とするデータ配信管理方法。
33. 【請求項３３】 前記判断工程は、前記第１の端末装置
    が送信したデータが、エラーに依存してスループットを
    低下させる可能性のあるプロトコルであるか否かをさら
    に判断し、 前記管理制御工程は、前記判断工程が、エラーの多い回
    線を経由し、かつエラーに依存してスループットを低下
    させる可能性のあるプロトコルであると判断した場合、
    前記送達確認応答の返送処理を行わせることができるこ
    とを特徴とする請求項３２に記載のデータ配信管理方
    法。
34. 【請求項３４】 前記判断工程は、少なくとも前記伝送
    遅延に依存するプロトコルであるか否かあるいはエラー
    の多い回線を経由するか否かを判断し、 前記管理制御工程は、前記判断工程が、前記伝送遅延に
    依存するプロトコルである、あるいはエラーの多い回線
    を経由すると判断した場合、前記送達確認応答の返送処
    理を行わせることができることを特徴とする請求項３２
    に記載のデータ配信管理方法。
35. 【請求項３５】 前記第１の端末装置が送信したデータ
    が通信開始に関するデータであるか否かを判断する通信
    開始判断工程を含み、 前記管理制御工程は、前記通信開始判断工程が通信開始
    に関するデータであると判断した場合、前記送達確認応
    答の返送処理を行わせない管理制御を行うことを特徴と
    する請求項３２〜３４に記載のデータ配信管理方法。
36. 【請求項３６】 前記第１の端末装置が送信したデータ
    が通信終了に関するデータであるか否かを判断する通信
    終了判断工程を含み、 前記管理制御工程は、前記通信終了判断工程が通信終了
    に関するデータであると判断した場合、前記送達確認応
    答の返送処理を行わせない管理制御を行うことを特徴と
    する請求項３２〜３５に記載のデータ配信管理方法。
37. 【請求項３７】 前記第１の端末装置が送信したデータ
    が前記第２の端末装置において正しく受理されるデータ
    であるか否かを判断する受信判断工程を含み、 前記管理制御工程は、前記受信判断工程が前記第２の端
    末装置において正しく受理されるデータでないと判断し
    た場合、前記送達確認応答の返送処理を行わせない管理
    制御を行うことを特徴とする請求項３２〜３６のいずれ
    か一つに記載のデータ配信管理方法。