JP2004274237A - 情報処理装置および方法、記録媒体、並びにプログラム - Google Patents
情報処理装置および方法、記録媒体、並びにプログラム Download PDFInfo
- Publication number
- JP2004274237A JP2004274237A JP2003060043A JP2003060043A JP2004274237A JP 2004274237 A JP2004274237 A JP 2004274237A JP 2003060043 A JP2003060043 A JP 2003060043A JP 2003060043 A JP2003060043 A JP 2003060043A JP 2004274237 A JP2004274237 A JP 2004274237A
- Authority
- JP
- Japan
- Prior art keywords
- data
- segment
- received
- transmitted
- information processing
- 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.)
- Withdrawn
Links
- 238000000034 method Methods 0.000 title description 58
- 230000010365 information processing Effects 0.000 claims abstract description 44
- 230000005540 biological transmission Effects 0.000 claims description 104
- 238000003672 processing method Methods 0.000 claims 1
- 239000000872 buffer Substances 0.000 description 28
- 238000010586 diagram Methods 0.000 description 11
- 238000004088 simulation Methods 0.000 description 10
- 230000007423 decrease Effects 0.000 description 7
- 238000004891 communication Methods 0.000 description 4
- 230000006870 function Effects 0.000 description 4
- 102100036409 Activated CDC42 kinase 1 Human genes 0.000 description 2
- 230000003287 optical effect Effects 0.000 description 2
- 239000004065 semiconductor Substances 0.000 description 2
- 239000002699 waste material Substances 0.000 description 2
- 101000741965 Homo sapiens Inactive tyrosine-protein kinase PRAG1 Proteins 0.000 description 1
- 102100038659 Inactive tyrosine-protein kinase PRAG1 Human genes 0.000 description 1
- 230000001186 cumulative effect Effects 0.000 description 1
- 230000003247 decreasing effect Effects 0.000 description 1
- 230000002542 deteriorative effect Effects 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 239000004973 liquid crystal related substance Substances 0.000 description 1
- 238000011084 recovery Methods 0.000 description 1
- 230000004044 response Effects 0.000 description 1
Images
Landscapes
- Detection And Prevention Of Errors In Transmission (AREA)
- Communication Control (AREA)
Abstract
【課題】重度の輻輳時に、効率的にデータを送信することができるようにする。
【解決手段】送信側のＰＣ１−１は、ＴＣＰウインドウ内のデータセグメントＤ１乃至Ｄ４を送信してから所定の時間が経過してもＡＣＫセグメントが受信されない場合、前回送信したデータセグメントＤ１乃至Ｄ４の次のデータセグメントＤ５を受信側のＰＣ１−２に送信する。ネットワーク３を介して、受信側のＰＣ１−２に送信する。なお、このとき、送信側のＰＣ１−１は、ＴＣＢ記憶部のＬｅａｐ＿ｓｅｑｎｏ変数に、飛躍セグメントのシーケンス番号を格納し、飛躍セグメントを送信中であるということを示すために、ＴＣＢ記憶部のＬｅａｐ＿ｆｌｇ変数をオン状態に設定する。本発明は、ＴＣＰプロトコルを用いて、ネットワークを介して、データ送受信を行う情報処理システムに適用することができる。
【選択図】 図８
【解決手段】送信側のＰＣ１−１は、ＴＣＰウインドウ内のデータセグメントＤ１乃至Ｄ４を送信してから所定の時間が経過してもＡＣＫセグメントが受信されない場合、前回送信したデータセグメントＤ１乃至Ｄ４の次のデータセグメントＤ５を受信側のＰＣ１−２に送信する。ネットワーク３を介して、受信側のＰＣ１−２に送信する。なお、このとき、送信側のＰＣ１−１は、ＴＣＢ記憶部のＬｅａｐ＿ｓｅｑｎｏ変数に、飛躍セグメントのシーケンス番号を格納し、飛躍セグメントを送信中であるということを示すために、ＴＣＢ記憶部のＬｅａｐ＿ｆｌｇ変数をオン状態に設定する。本発明は、ＴＣＰプロトコルを用いて、ネットワークを介して、データ送受信を行う情報処理システムに適用することができる。
【選択図】 図８
Description
【０００１】
【発明の属する技術分野】
本発明は、情報処理装置および方法、記録媒体、並びにプログラムに関し、特に、重度の輻輳時に、効率的にデータを送信することができるようにした情報処理装置および方法、記録媒体、並びにプログラムに関する。
【０００２】
【従来の技術】
インターネットに用いられるトランスポート層のプロトコルとしては、例えば、コネクションレスのＵＤＰ（Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ）と、コネクションを行うことにより信頼性を確保するＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）が存在する。
【０００３】
インターネットを利用するユーザの多くは、各自のネットワークインフラ（Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ）を最大限に利用したいと考えている。そこで、ＵＤＰにおいては、特許文献１に示されるように、ＮＡＣＫ（Ｎｅｇａｔｉｖｅ ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ）を用いて、欠損要求があったデータのみを送ることにより、多数のユーザに対して、データを効率的、かつ高い信頼性で配信することができるようにした送受信装置が提案されている。
【０００４】
一方、ＴＣＰは、上位アプリケーションから受け取ったデータを、１００％確実に送信することを保証するプロトコルである。ＴＣＰで送受信される情報は、セグメントと呼ばれる単位で送受信される。セグメントには、データセグメントとＡＣＫ（ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ：確認応答）セグメントの２種類が存在する。ＴＣＰは、この２種類のセグメントを利用して、次のような輻輳制御により通信の信頼性を確保する。
【０００５】
まず、送信側のＴＣＰは、データセグメントを受信側に送信する。このデータセグメントを受信すると、受信側のＴＣＰは、受信したデータセグメントに対応するＡＣＫセグメントを送信側に送信する。送信側のＴＣＰは、ＡＣＫセグメントを受信することで、データセグメントの送信が成功したことを確認する。したがって、ＡＣＫセグメントが受信されなかったデータセグメントは、送信側のＴＣＰにより再度送信されることになる。しかしながら、この場合、送信側のＴＣＰでは、図１に示されるように、送信側のＴＣＰからのデータセグメントが欠損したのか、あるいは、図２に示されるように、受信側のＴＣＰからのＡＣＫセグメントが欠損したのかの判断が行われていない。したがって、送信側のＴＣＰは、データセグメント、ＡＣＫセグメントのどちらが欠損してもデータセグメントの再送処理を実行する。
【０００６】
図１および図２は、送信側のＴＣＰによるデータセグメントの再送処理の例を示している。送信側と受信側は、図示せぬネットワークを介してセグメントを通信する。図１の例においては、送信側のＴＣＰから送信されたデータセグメントＤ１は、受信側に到着する前のネットワーク上で欠損する。したがって、受信側のＴＣＰからデータセグメントＤ１に対応するＡＣＫセグメントは送信されず、送信側のＴＣＰはＡＣＫセグメントを受信することができない。送信側のＴＣＰは、データセグメントＤ１を送信してから、再送タイマを起動し、再送タイマにより計時動作を行い、所定の時間（再送タイマ動作時間）が経過したか否かを判断し、所定の時間が経過してもＡＣＫセグメントＡ１が受信されない場合、データセグメントＤ１を再送セグメントとして受信側に送信する。これにより、受信側のＴＣＰは、データセグメントＤ１を受信することができる。
【０００７】
一方、図２の例においては、送信側のＴＣＰから送信されたデータセグメントＤ２は、受信側に無事到着する。受信側のＴＣＰは、受信したデータセグメントＤ２に対応するＡＣＫセグメントＡ２を送信側に送信する。しかしながら、ＡＣＫセグメントＡ２は、送信側に到着する前のネットワーク上において欠損し、送信側のＴＣＰは、それを受信することができない。受信側のＴＣＰは、データセグメントＤ２を送信してから、再送タイマを起動させ、再送タイマにより計時動作を行い、所定の時間（再送タイマ動作時間）が経過したか否かを判断し、所定の時間が経過してもＡＣＫセグメントＡ２が受信されない場合、データセグメントＤ２を再送セグメントとして受信側に送信する。しかしながら、受信側では、前回の送信により、すでにデータセグメントＤ２が受信されている。したがって、受信側のＴＣＰは、データセグメントＤ２を重複して受信することになる。
【０００８】
以上のように、ＡＣＫセグメントの欠損によるデータセグメントの再送は、受信側に到着しているデータセグメントを再度送信することになるため、無駄な処理になってしまう。
【０００９】
なお、ＴＣＰの確認応答の方法においては、シーケンス番号が割り振られたデータセグメントがどこまで届いたのかをＡＣＫセグメントが通知する累積確認応答が行われる。したがって、ＡＣＫセグメントが欠損したとしても、それ以降に連続して受信側から送信されるＡＣＫセグメントが送信側に到達する。受信側においては、それらのＡＣＫセグメントにより、どのデータセグメントが届いているかの状況が把握できるので、欠損したＡＣＫセグメントかあっても再送処理に関して影響を与えない。
【００１０】
しかしながら、これは、データセグメントが円滑に送信され、ＴＣＰの送信ウインドウが拡張しているような場合、すなわち、受信側で送信されるＡＣＫセグメントの数が十分多く存在するような場合に限られる。例えば、頻繁な輻輳制御により、ＴＣＰの送信ウインドウが収縮している場合、受信側のＴＣＰで送信されるＡＣＫセグメントの数も少なくなる。このような場合に、ＡＣＫセグメントが欠損した場合、それ以降に連続して受信側から送信されるＡＣＫセグメントが少ないため、送信側に到達するＡＣＫセグメントはさらに少ない。したがって、ＴＣＰの送信ウインドウが収縮している場合において、ＡＣＫセグメントの欠損により、データセグメントの再送が実行され、その結果、データセグメントが重複してしまう確率は、ＴＣＰの送信ウインドウが拡張しているような場合の確率よりも高くなる。
【００１１】
次に、図３および図４のグラフを参照して、３台のノードが１台のノードを経由して接続しているネットワーク環境において実行されたデータ転送のシミュレーション結果を説明する。このシミュレーションは、３台のノードが１台のノードを経由して接続しているネットワーク環境において、１００個のデータを送出するＦＴＰ（Ｆｉｌｅ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）のコネクション（データ転送）を指数分布の間隔に従ってランダムに発生させ、１秒間に発生するコネクションの数の平均値を、０．２５コネクション刻みで、１コネクションから３．５コネクションまで変更させて、３０００秒間実行されたものである。なお、このシミュレーションにおいては、現在のＴＣＰの事実上の標準とされているＲｅｎｏ方式、ＴＣＰウインドウ（ＴＣＰにおいて用いられるバッファ量）内で複数のデータセグメントの欠損が起こった場合のＲｅｎｏ方式のＦａｓｔ Ｒｅｃｏｖｅｒｙを改良したＮｅｗＲｅｎｏ方式、および、ＡＣＫパケットにセグメントの欠損情報を格納することを可能としたＳａｃｋ方式の３種類のＴＣＰの方式が用いられている。
【００１２】
図３は、シミュミレーション時間内に終了したコネクション（データ転送）の数を示すグラフである。図３の例においては、横軸は、１秒間に発生するコネクションの数の平均値（すなわち、トラフィック負荷度）を示しており、トラフィックの負荷は、右に行くに従って高くなる。縦軸は、Ｒｅｎｏ方式、ＮｅｗＲｅｎｏ方式、およびＳａｃｋ方式を用いてデータ転送が終了したコネクション数（終了コネクション数）を示しており、終了コネクション数は、上に行くに従って多くなる。
【００１３】
図３のグラフの横軸に注目すると、ＴＣＰのどの方式においても、終了コネクション数は、図中矢印に示される２．５コネクション数／秒まで直線的に増加しているが、２．７５コネクション数／秒を過ぎたころから明らかに減少していることがわかる。これにより、このネットワークの許容量は、１秒間に２．５コネクション乃至２．７５コネクションを転送するあたりのトラフィック負荷度であり、この許容量を越えると、セグメント（データセグメントおよびＡＣＫセグメント）の欠損によりＴＣＰの輻輳制御（再送処理）が行われていることが予測される。
【００１４】
図４は、１コネクションにおける平均送受信パケット数を示すグラフである。図４の例においては、横軸は、１秒間に発生するコネクションの数の平均値（トラフィック負荷度）を示しており、トラフィックの負荷度は、右に行くに従って高くなる。縦軸は、Ｒｅｎｏ方式、ＮｅｗＲｅｎｏ方式、およびＳａｃｋ方式を用いた場合の送信パケット数（ｓ）と受信パケット数（ｒ）を示しており、送受信パケット数は、上に行くに従って多くなる。
【００１５】
図４のグラフにおいて、送信パケット数（矢印Ｐ１）と受信パケット数（矢印Ｐ２）の差は、ネットワーク内で実際に欠損したパケット数（矢印Ｐ３）である。ここで注意すべき点は、ＦＴＰのコネクション（データ転送）は、１００個のパケットを送受信するように設定されているにもかかわらず、ネットワークのトラフィックの負荷が高くなるにつれて、矢印Ｐ２に示されるように受信パケット数も増加していることである。これは、すなわち、受信側に重複したパケットが到着していることを示している。
【００１６】
なお、Ｒｅｎｏ方式、ＮｅｗＲｅｎｏ方式、およびＳａｃｋ方式において性能差がほとんど見られなかったのは、ＮｅｗＲｅｎｏ方式、およびＳａｃｋ方式は、ＴＣＰウインドウ内での複数のデータセグメントの欠損に対して有効であるが、いまの場合のように、トラフィックの負荷が高いときは、ＴＣＰウインドウの大きさが小さく収縮されているため、有効になる機会が少なかったといえる。
【００１７】
【特許文献１】
特開平１１−１７７３７号公報
【００１８】
【発明が解決しようとする課題】
以上のように、ネットワーク上において、トラフィックの負荷が高くなると、ＡＣＫセグメントの欠損が多くなり、結果的に、受信側に重複したデータセグメントが無駄に受信されてしまう課題があった。これにより、再送されるデータセグメントが増加してしまい、ますますトラフィックの負荷がかかってしまう課題があった。
【００１９】
本発明はこのような状況に鑑みてなされたものであり、重度の輻輳時に、効率的にデータを送信することができるようにするものである。
【００２０】
【課題を解決するための手段】
本発明の情報処理装置は、ネットワークを介して、所定のプロトコルでデータを他の情報処理装置に送信する送信手段と、送信手段によりデータが送信されてから所定の時間内に、他の情報処理装置からデータに対応するＡＣＫ（ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ）を受信したか否かを判断する受信判断手段とを備え、受信判断手段により他の情報処理装置からデータに対応するＡＣＫが受信されていないと判断された場合、送信手段は、前回送信されたデータに続く次のデータを送信することを特徴とする。
【００２１】
所定のプロトコルは、ＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）であるようにすることができる。
【００２２】
受信判断手段によりデータに対応するＡＣＫが受信されていないと判断された場合に、送信手段により送信された次のデータのシーケンス番号を記憶する記憶手段と、受信判断手段によりデータに対応するＡＣＫが受信されていないと判断され、送信手段により次のデータが送信された場合に、そのことを示すフラグを保持する保持手段とをさらに備えるようにすることができる。
【００２３】
保持手段によりフラグが保持されているか否かを判断するフラグ判断手段をさらに備え、受信判断手段によりデータに対応するＡＣＫが受信されていないと判断され、かつ、フラグ判断手段によりフラグが保持されていると判断された場合、送信手段は、受信判断手段によりＡＣＫが受信されていないと判断されたデータを再度送信するようにすることができる。
【００２４】
受信判断手段によりデータに対応するＡＣＫが受信されたと判断され、かつ、フラグ判断手段によりフラグが保持されていると判断された場合、保持手段は、フラグの保持を解除するようにすることができる。
【００２５】
受信判断手段によりデータに対応するＡＣＫが受信されたと判断された場合、次に送信する送信データのシーケンス番号が、記憶手段に記憶されているシーケンス番号と同じであるか否かを判断するデータ判断手段をさらに備え、データ判断手段により送信データのシーケンス番号が、記憶手段に記憶されているシーケンス番号と同じであると判断された場合、送信手段は、送信データの送信をスキップし、送信データの次のデータを送信するようにすることができる。
【００２６】
本発明の情報処理装置は、ネットワークを介して、所定のプロトコルでデータを他の情報処理装置に送信する送信ステップと、送信ステップの処理によりデータが送信されてから所定の時間内に、他の情報処理装置からデータに対応するＡＣＫを受信したか否かを判断する受信判断ステップとを含み、受信判断ステップの処理により他の情報処理装置からデータに対応するＡＣＫが受信されていないと判断された場合、送信ステップの処理は、前回送信されたデータに続く次のデータを送信することを特徴とする。
【００２７】
本発明の記録媒体のプログラムは、ネットワークを介して、所定のプロトコルでデータを他の情報処理装置に送信する送信ステップと、送信ステップの処理によりデータが送信されてから所定の時間内に、他の情報処理装置からデータに対応するＡＣＫを受信したか否かを判断する受信判断ステップとを含み、受信判断ステップの処理により他の情報処理装置からデータに対応するＡＣＫが受信されていないと判断された場合、送信ステップの処理は、前回送信されたデータに続く次のデータを送信することを特徴とする。
【００２８】
本発明のプログラムは、ネットワークを介して、所定のプロトコルでデータを他の情報処理装置に送信する送信ステップと、送信ステップの処理によりデータが送信されてから所定の時間内に、他の情報処理装置からデータに対応するＡＣＫを受信したか否かを判断する受信判断ステップとを含み、受信判断ステップの処理により他の情報処理装置からデータに対応するＡＣＫが受信されていないと判断された場合、送信ステップの処理は、前回送信されたデータに続く次のデータを送信することを特徴とする。
【００２９】
本発明においては、ネットワークを介して、所定のプロトコルでデータが他の情報処理装置に送信され、データが送信されてから所定の時間内に、他の情報処理装置からデータに対応するＡＣＫを受信したか否かが判断される。そして、他の情報処理装置からデータに対応するＡＣＫが受信されていないと判断された場合、前回送信されたデータに続く次のデータが送信される。
【００３０】
ネットワークとは、少なくとも２つの装置が接続され、ある装置から、他の装置に対して、情報の伝達をできるようにした仕組みをいう。ネットワークを介して通信する装置は、独立した装置どうしであってもよいし、１つの装置を構成している内部ブロックどうしであってもよい。
【００３１】
【発明の実施の形態】
以下、図を参照して本発明の実施の形態について説明する。
【００３２】
図５は、本発明を適用した情報処理システムの構成例を表している。ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）などで構成されるネットワーク３には、パーソナルコンピュータ（以下、ＰＣと称する）１−１乃至１−３が、ルータ２を介して接続される。なお、ネットワーク３は、ＬＡＮにより構成されるようにしたが、インターネットなどで構成されるようにしてもよく、接続される装置の台数も限定されない。
【００３３】
各ＰＣ１−１乃至１−３とルータ２間の帯域幅は、５００ｋｂｐｓで、遅延は５０ｍｓに設定される。また、また、各ＰＣ１−１乃至１−３のキューは、１００パケット分でドロップテイル方式を用いて、ＦＩＦＯ（Ｆｉｒｓｔ Ｉｎ Ｆｉｒｓｔ Ｏｕｔ）によりパケットを扱う。
【００３４】
ＰＣ１−１乃至１−３は、ＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）プロトコルのＬＥＡＰ方式（図８を参照して後述する）を用いて、ルータ２を介してお互いにデータ送受信（コネクション）を実行する。
【００３５】
図６は、ＰＣ１−１乃至１−３（個々に区別する必要がない場合、単にＰＣ１と称する）の構成を表している。図６において、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）１１は、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）１２に記憶されているプログラム、または記憶部１８からＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）１３にロードされたプログラムに従って各種の処理を実行する。ＲＡＭ１３にはまた、ＣＰＵ１１が各種の処理を実行する上において必要なデータなども適宜記憶される。
【００３６】
ＣＰＵ１１、ＲＯＭ１２およびＲＡＭ１３は、バス１４を介して相互に接続されている。このバス１４にはまた、入出力インタフェース１５も接続されている。
【００３７】
入出力インタフェース１５には、キーボード、マウスなどよりなる入力部１６、ＣＲＴ（Ｃａｔｈｏｄｅ Ｒａｙ Ｔｕｂｅ）、ＬＣＤ（Ｌｉｑｕｉｄ Ｃｒｙｓｔａｌ Ｄｉｓｐｌａｙ）などよりなるディスプレイ、並びにスピーカなどよりなる出力部１７、ハードディスクなどより構成される記憶部１８、モデム、ターミナルアダプタなどより構成される通信部１９が接続されている。通信部１９は、ネットワーク３を介しての通信処理を行う。
【００３８】
入出力インタフェース１５にはまた、必要に応じてドライブ２０が接続され、磁気ディスク２１、光ディスク２２、光磁気ディスク２３、或いは半導体メモリ２４などが適宜装着され、それらから読み出されたコンピュータプログラムが、必要に応じて記憶部１８にインストールされる。
【００３９】
なお、ルータ３も、ＰＣ１と基本的に同様に構成されている。したがって、以下の説明においては、図６のＰＣ１の構成は、必要に応じて、ルータ３の構成としても引用する。
【００４０】
図７は、ＰＣ１のデータ送受信処理における機能構成例を示すブロック図である。図７に示される機能ブロックは、ＰＣ１の図６のＣＰＵ１１により所定の制御プログラムが実行されることで実現される。
【００４１】
データ制御部３１は、ＰＣ１のデータ送受信処理において、ユーザ側のインタフェース部分を提供する。データ制御部３１は、ユーザの操作により、図６の入力部１６を介して入力される指示に基づいて、記憶部１９に記憶されているデータを一旦読み込み、読み込んだデータを送信バッファ３４に書き込む。また、データ制御部３１は、受信バッファ３７のデータを読み込み、入力部１６を介して入力されるユーザの指示のもと、記憶部１９に書き込んだり、そのままプログラムで使用する。
【００４２】
ＴＣＰ制御部３２は、図８を参照して詳しく後述するＴＣＰプロトコルのＬＥＡＰ方式に基づいて、ＴＣＢ（ＴＣＰ Ｃｏｎｔｒｏｌ Ｂｌｏｃｋ）記憶部３３にネットワーク３を介して実行されるコネクションの状態を保持しながら、送信バッファ３４、送信部３５、受信部３６および受信バッファ３７を制御し、データ送受信処理を実行する。
【００４３】
ＴＣＰ制御部３２は、データ制御部３１により書き込まれた送信バッファ３４内のデータをＴＣＰセグメントの大きさに区切り、ＴＣＰウインドウの値の数のデータセグメントを、ＴＣＰウインドウとして設定し、ＴＣＰウインドウ内のデータセグメントを送信部３５に供給する。ＴＣＰウインドウの値は、送信されるデータセグメント量を示しており、ネットワーク３において、セグメントの損失がなければ、徐々に大きくなる。しかしながら、セグメントが欠損すると、ＴＣＰウインドウの値は、１セグメントに戻る。ＴＣＰ制御部３２は、このようなＴＣＰウインドウの値を用いて、送信するデータセグメントの量を調整する。
【００４４】
また、ＴＣＰ制御部３２は、送信部３５からデータセグメントが送信されると、内蔵する再送タイマを起動させる。再送タイマは、受信部３６に、他のＰＣから、前回送信されたデータセグメントを受信したことを通知するＡＣＫ（ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ：確認応答）セグメントが受信されると停止する。再送タイマは、所定の時間（再送タイマ動作時間）が経過しても、受信部３６にＡＣＫセグメントが受信されない場合、タイムアウトする。なお、ＡＣＫセグメントは、シーケンス番号が割り振られたデータセグメントがどこまで届いたのかを確認し、届いていないシーケンス番号の最小のデータセグメントを送信側のＰＣに要求する機能を有する。
【００４５】
ＴＣＰ制御部３２は、再送タイマにより計時動作を行い、受信部３６を監視しており、他のＰＣから前回送信されたデータセグメントに対応するＡＣＫセグメントが所定の時間（再送タイマ動作時間）内に受信されたか否かを判断し、その判断に基づいて、どのデータセグメントを送信部３５に供給するかを制御する。
【００４６】
具体的には、受信部３６が前回送信されたデータセグメントに対応するＡＣＫセグメントを受信した場合、ＴＣＰ制御部３２は、ＴＣＰウインドウの値を拡張し、受信したＡＣＫセグメントが要求するデータセグメントから、ＴＣＰウインドウの値の数のデータセグメントを、ＴＣＰウインドウとして設定し、ＴＣＰウインドウ内のデータセグメントを送信部３５に供給する。例えば、ＴＣＰウインドウの値が５であれば、受信したＡＣＫセグメントが要求するデータセグメントから、５個のデータセグメントを、ＴＣＰウインドウとして設定し、ＴＣＰウインドウ内のデータセグメントを送信部３５に供給する。
【００４７】
一方、受信部３６が前回送信されたデータセグメントに対応するＡＣＫを受信しなかった場合、ＴＣＰ制御部３２は、ネットワーク３上でのセグメント（ＡＣＫセグメントまたはデータセグメント）の欠損があったとして、ＴＣＰウインドウの値を１に収縮し、前回送信したデータセグメントのうち、シーケンス番号の最小のデータセグメントである再送セグメントを、ＴＣＰウインドウとして設定するが、その再送セグメントは送信せずに、前回送信したデータセグメント（すなわち、前回のＴＣＰウインドウ）の次のデータセグメントを飛躍セグメントとして送信部３５に供給する。
【００４８】
また、ＴＣＰ制御部３２は、受信部３６を監視しており、受信部３６が他のＰＣからネットワーク３を介して、データセグメントを受信した場合、受信したデータセグメントに対応するＡＣＫセグメントを送信部３５に供給する。
【００４９】
送信部３５は、ＴＣＰ制御部３２の制御のもと、ＴＣＰ制御部３２より供給されたデータセグメントまたはＡＣＫセグメントを、ネットワーク３を介して、他のＰＣに送信する。
【００５０】
ＴＣＢ記憶部３３は、メモリなどにより構成され、ＴＣＰ制御部３２により書き込まれたＴＣＰウインドウの値、再送タイマ動作時間、飛躍セグメントのシーケンス番号を格納するｌｅａｐ＿ｓｅｑｎｏ変数、および、飛躍セグメントがネットワーク３上にあるか否か（すなわち、送信されていて、まだ、飛躍セグメントに対応するＡＣＫセグメントを受信していない状態であるか否か）を判断するためのフラグであるｌｅａｐ＿ｆｌｇ変数などのコネクション（データ転送）の状態を保持している。送信バッファ３４は、３２ｋｂｙｔｅのバッファにより構成され、他のＰＣに送信するデータセグメントが一旦蓄積され、蓄積されたデータセグメントは、送信部３５により送信されると消去される。これにより、データ制御部３１は、送信バッファ３４の空き領域に、新たにデータを書き込むことができる。
【００５１】
受信部３６は、他のＰＣから送信されたＡＣＫセグメントを、ネットワーク３を介して受信する。また、受信部３６は、他のＰＣから送信されたデータセグメントを、ネットワーク３を介して受信し、受信したデータセグメントを順序どおりに並べ替えて、受信バッファ３７に書き込む。受信バッファ３７は、３２ｋｂｙｔｅのバッファにより構成され、受信部３６より書き込まれたデータが一旦蓄積される。蓄積されたデータは、データ制御部３１により読み込まれる。
【００５２】
次に、図５の情報処理システムの動作について説明する。
【００５３】
ＰＣ１−１のデータ制御部３１は、記憶部１９に記憶されているデータを一旦読み込み、読み込んだデータを送信バッファ３４に書き込む。ＴＣＰ制御部３２は、データ制御部３１により書き込まれた送信バッファ３４内のデータをＴＣＰセグメントの大きさに区切り、ＴＣＰウインドウの値の数のデータセグメントを、ＴＣＰウインドウとして設定し、ＴＣＰウインドウ内のデータセグメントを送信部３５に供給する。送信部３５は、ＴＣＰ制御部３２の制御のもと、ＴＣＰ制御部３２より供給されたデータセグメントを、ネットワーク３およびルータ２を介して、ＰＣ１−２に送信する。
【００５４】
ＰＣ１−２の受信部３６は、ＰＣ１−１から送信されたデータセグメントを、ネットワーク３およびルータ２を介して受信し、受信したデータセグメントを順序どおりに並べ替えて、受信バッファ３７に書き込む。ＴＣＰ制御部３２は、受信部３６を監視しており、受信部３６がＰＣ１−１からデータセグメントを受信した場合、受信したデータセグメントに対応するＡＣＫセグメントを送信部３５に供給する。送信部３５は、ＴＣＰ制御部３２の制御のもと、ＴＣＰ制御部３２より供給されたＡＣＫセグメントを、ネットワーク３およびルータ２を介して、ＰＣ１−１に送信する。
【００５５】
ＰＣ１−１の受信部３６は、ＰＣ１−２から送信されたＡＣＫセグメントを、ネットワーク３を介して受信する。ＴＣＰ制御部３２は、受信部３６を監視しており、再送タイマにより計時動作を行い、他のＰＣからＡＣＫセグメントが所定の時間（再送タイマ動作時間）内に受信されたか否かを判断し、受信部３６がＡＣＫセグメントを受信したと判断した場合、ＴＣＰウインドウの値を拡張し、受信したＡＣＫセグメントが要求するデータセグメントから、ＴＣＰウインドウの値の数のデータセグメントを、ＴＣＰウインドウとして設定し、ＴＣＰウインドウ内のデータセグメントを送信部３５に供給する。
【００５６】
以上のようにして、ネットワーク３上において、セグメントの欠損がない場合のＰＣ１−１およびＰＣ１−２間のデータ送受信処理が実行される。
【００５７】
次に、図８および図９を参照して、本発明のＬＥＡＰ方式と従来のＲｅｎｏ方式におけるセグメントが欠損した場合のデータセグメントの再送処理を比較して説明する。図８および図９の例においては、送信側のＰＣ１−１が、ネットワーク３を介して、受信側のＰＣ１−２にデータを送信する例について説明する。なお、図８は、本発明のＬＥＡＰ方式によるデータセグメントの再送処理を説明する図であり、図９は、従来のＲｅｎｏ方式によるデータセグメントの再送処理を説明する図である。また、以下のデータセグメントの再送処理は、ＰＣ１−１およびＰＣ１−２のＴＣＰ制御部３２が制御する処理であるが、それぞれ、ＰＣ１−１およびＰＣ１−２を主語として説明する。
【００５８】
図８の例において、「ｗｎｄ＝４」、「ｗｎｄ＝１」および「ｗｎｄ＝２」は、送信側のＰＣ１−１におけるＴＣＰウインドウの値が「４」、「１」および「２」であることを示している。また、送信側ＰＣ１−１において、点線の四角は、ＴＣＰウインドウのデータセグメントを示しており、実線の四角は、実際に送信されるデータセグメントを示している。
【００５９】
図中左側において、送信側のＰＣ１−１は、ＴＣＰウインドウの値が「４」であるので、４つのデータセグメントＤ１乃至Ｄ４をＴＣＰウインドウとして設定し、ＴＣＰウインドウ内のデータセグメントを、ネットワーク３を介して、受信側のＰＣ１−２に送信する。このとき、データセグメントＤ４は、輻輳Ｅが生じているネットワーク３上で欠損する。したがって、受信側のＰＣ１−２は、ネットワーク３を介して、データセグメントＤ１乃至Ｄ３だけを受信する。
【００６０】
そこで、受信側のＰＣ１−２は、データセグメントＤ１乃至Ｄ３を受信したことを通知するＡＣＫセグメントＡ１乃至Ａ３を、ネットワーク３を介して、送信側のＰＣ１−１に送信する。しかしながら、ネットワーク３上の輻輳Ｅにより、ＡＣＫセグメントＡ１乃至Ａ３は、ネットワーク３上で欠損する。
【００６１】
したがって、いまの場合、送信側のＰＣ１−１は、データセグメントＤ１乃至Ｄ４に対応するＡＣＫセグメントを、１つも受信することができない。送信側のＰＣ１−１は、データセグメントＤ１乃至Ｄ４を送信したとき、再送タイマを起動する。送信側のＰＣ１−１は、再送タイマにより計時動作を行い、所定の時間（再送タイマ動作時間）が経過しても、データセグメントＤ１乃至Ｄ４に対応するＡＣＫセグメントを受信しない場合、再送タイマをタイムアウトし、ＴＣＰウインドウの値を１に収縮する。
【００６２】
このとき、従来のＲｅｎｏ方式であれば、図９に示されるように、送信側のＰＣ１−１は、前回送信されたデータセグメントのうち、シーケンス番号の最小のデータセグメントであるデータセグメントＤ１を、ＴＣＰウインドウとして設定し、ＴＣＰウインドウ内のデータセグメントＤ１を再送セグメントとして送信する。データセグメントＤ１は、再送タイマがタイムアウトした時点のＴＣＰウインドウ内のデータセグメントＤ１乃至Ｄ４のうち、シーケンス番号が最小のデータセグメントである。しかしながら、データセグメントＤ１は、受信側のＰＣ１−２により既に受信されているデータセグメントであるため、受信側のＰＣ１−２により破棄されてしまう。その後、受信側のＰＣ１−２は、データセグメントＤ１に対応するＡＣＫセグメントＡ１をネットワーク３を介して送信側のＰＣ１−１に送信する。
【００６３】
ＡＣＫセグメントは、シーケンス番号が割り振られたデータセグメントがどこまで届いたのかを確認し、届いていないシーケンス番号の最小のデータセグメントを要求する機能を有する。したがって、ＡＣＫセグメントＡ１は、受信側のＰＣにおいて受信されているデータセグメントＤ３の次のシーケンス番号のデータセグメントであるデータセグメントＤ４を要求する。ＡＣＫセグメントＡ１を受信した送信側のＰＣ１−１は、再送タイマを停止し、ＴＣＰウインドウを１つ拡張させて、ＴＣＰウインドウの値を「２」とし、要求されたデータセグメントＤ４とその次のデータセグメントＤ５を、ＴＣＰウインドウとして設定し、ＴＣＰウインドウ内のデータセグメントＤ４およびＤ５を、ネットワーク３を介して受信側のＰＣ１−２に送信する。
【００６４】
一方、図８のＬＥＡＰ方式においては、送信側のＰＣ１−１は、ＴＣＰウインドウ内のデータセグメントＤ１（再送セグメント）ではなく、前回送信したデータセグメント（再送タイマがタイムアウトした時点のＴＣＰウインドウ内のデータセグメント）Ｄ１乃至Ｄ４の次のデータセグメントＤ５を受信側のＰＣ１−２に送信する。すなわち、いまの場合、ＴＣＰウインドウは、データセグメントＤ１が設定されており、データセグメントＤ５は、ＴＣＰウインドウ内にはないため、送信側のＰＣ１−１は、データセグメントＤ５を飛躍セグメントとしてネットワーク３を介して、受信側のＰＣ１−２に送信する。なお、このとき、送信側のＰＣ１−１は、ＴＣＢ記憶部３３のＬｅａｐ＿ｓｅｑｎｏ変数に、飛躍セグメントのシーケンス番号を格納し、飛躍セグメントを送信中であるということを示すために、ＴＣＢ記憶部３３のＬｅａｐ＿ｆｌｇ変数をオン状態に設定する。
【００６５】
受信側のＰＣ１−２は、ネットワーク３を介してデータセグメントＤ５を受信し、データセグメントＤ５に対応するＡＣＫセグメントＡ５を、ネットワーク３を介して送信側のＰＣに送信する。このＡＣＫセグメントＡ５は、受信側のＰＣ１−２において受信されていない最小のシーケンス番号のデータセグメントであるデータセグメントＤ４を要求する。
【００６６】
これに対応して、送信側のＰＣ１−１は、ＡＣＫセグメントＡ５を受信すると、再送タイマを停止させる。そして、送信側のＰＣ１−１は、ＴＣＢ記憶部３３のＬｅａｐ＿ｆｌｇ変数をオフ状態に設定し、ＴＣＰウインドウを１つ拡張させて、ＴＣＰウインドウの値を「２」とし、要求されたデータセグメントＤ４とその次のデータセグメントＤ５を、ＴＣＰウインドウとして設定する。しかしながら、データセグメントＤ４に続くデータセグメントＤ５は、飛躍セグメントとして、すでに受信側のＰＣ１−２に送信され、受信されている。したがって、送信側のＰＣ１−１は、ＴＣＢ記憶部３３のＬｅａｐ＿ｓｅｑｎｏ変数のシーケンス番号に基づいて、ＴＣＰウインドウ内のセグメントであっても、飛躍セグメントであるデータセグメントＤ５は送信せず、ＴＣＰウインドウ内のデータセグメントＤ４と、飛躍セグメントの次のデータセグメントＤ６を、ネットワーク３を介して、受信側のＰＣ１−２に送信する。
【００６７】
以上により、送信側のＰＣ１−１においては、重複したデータセグメントＤ１を送信することが抑制される。これにより、図８のＬＥＡＰ方式のデータセグメント再送処理においては、図９の従来のＲｅｎｏ方式のデータセグメント再送処理よりも１つ先のデータセグメントＤ６が送信されるので、効率的にデータの送受信処理が実行される。
【００６８】
次に、図１０乃至図１２のフローチャートを参照して、ネットワーク３を介してＰＣ１−２へデータを送信するＰＣ１−１のデータ送信処理を説明する。
【００６９】
データ制御部３１は、ユーザの操作により、入力部１６を介して入力される指示に基づいて、記憶部１９に記録されているデータを一旦読み込み、読み込んだデータを送信バッファ３４に書き込む。
【００７０】
ＴＣＰ制御部３２は、ステップＳ１において、送信バッファ３４を監視しており、送信バッファ３４に送信する送信データセグメントがあるか否かを判断し、送信バッファ３４に送信データセグメントがあると判断した場合、ＴＣＰ制御部３２は、送信バッファ３４に書き込まれたデータを、ＴＣＰセグメントの大きさに区切り、ＴＣＰウインドウの値の数のデータセグメントを、ＴＣＰウインドウとして設定し、ステップＳ２に進む。
【００７１】
ステップＳ２において、ＴＣＰ制御部３２は、送信データセグメントがＴＣＰウインドウ内にあるか否かを判断する。このとき、データセグメントの初めての送信の場合、または、前回のＴＣＰウインドウとして設定したデータセグメントに対応するＡＣＫセグメントが受信された場合、送信データセグメントは、ＴＣＰウインドウとして設定されるため、送信データセグメントがＴＣＰウインドウ内にあると判断される。一方、前回のＴＣＰウインドウとして設定したデータセグメントが送信され、そのデータセグメントに対応するＡＣＫセグメントが受信されていない場合、また、ＴＣＰウインドウは、前回の送信されたデータセグメントに設定されているため、送信されるデータセグメントは、ＴＣＰウインドウ内にないと判断される。
【００７２】
ステップＳ２において、送信データセグメントがＴＣＰウインドウ内にはないと判断された場合、ステップＳ３に進み、ＴＣＰ制御部３２は、受信部３６が、ＰＣ１−２から、前回送信されたデータセグメントに対応するＡＣＫセグメントを受信したか否かを判断し、前回送信されたデータセグメントに対応するＡＣＫセグメントを受信していないと判断した場合、ステップＳ４に進む。ＴＣＰ制御部３２は、前回のデータセグメントを送信してから再送タイマを起動させ、計時動作を行っている。ステップＳ４において、ＴＣＰ制御部３２は、再送タイマにより計時動作を行い、前回のデータセグメントを送信してから所定の時間が経過したか否かを判断する。ステップＳ４において、前回のデータセグメントを送信してから所定の時間が経過していないと判断された場合、処理は、ステップＳ３に戻り、それ以降の処理を繰り返す。
【００７３】
ステップＳ３において、前回のデータセグメントに対応するＡＣＫセグメントを受信したと判断された場合、ＴＣＰ制御部３２は、再送タイマを停止し、ステップＳ５において、ＴＣＢ記憶部３３のｌｅａｐ＿ｆｌｇがオン状態であるか否かを判断する。ＴＣＰ制御部３２は、ステップＳ５において、ＴＣＢ記憶部３３のｌｅａｐ＿ｆｌｇがオン状態であると判断した場合、ステップＳ６に進み、ＴＣＢ記憶部３３のｌｅａｐ＿ｆｌｇをオフ状態に設定し、ステップＳ７に進む。ステップＳ５において、ＴＣＢ記憶部３３のｌｅａｐ＿ｆｌｇがオン状態ではないと判断された場合、ＴＣＰ制御部３２は、ステップＳ６をスキップし、ステップＳ７に進む。ステップＳ７において、ＴＣＰ制御部３２は、ＴＣＰウインドウの値を拡張し、ステップＳ３において受信されたＡＣＫセグメントが要求するデータセグメントから、ＴＣＰウインドウの値の数のデータセグメントを、ＴＣＰウインドウとして設定し、ステップＳ２に戻り、それ以降の処理を繰り返す。
【００７４】
ステップＳ２において、送信データセグメントがＴＣＰウインドウ内にあると判断された場合、処理は、図１１のステップＳ８に進み、ＴＣＰ制御部３２は、ＴＣＢ記憶部３３のｌｅａｐ＿ｓｅｑ変数の飛躍セグメントのシーケンス番号に基づいて、送信する送信データセグメントが飛躍セグメントであるか否かを判断する。ステップＳ８において、送信データセグメントが飛躍セグメントであると判断された場合（例えば、図８におけるデータセグメントＤ５）、送信データセグメントが飛躍セグメントとしてすでにＰＣ１−２に送信されていることになるので、ステップＳ９において、ＴＣＰ制御部３２は、ＴＣＰウインドウ内の送信データセグメントは送信せず、ＴＣＰウインドウ内の他のデータセグメント（ある場合）と、送信データセグメントの次のデータセグメント（例えば、図８におけるデータセグメントＤ６）を、ネットワーク３を介して、ＰＣ１−２に送信し、図１０のステップＳ１に戻り、それ以降の処理を繰り返す。
【００７５】
ステップＳ８において、送信データセグメントが飛躍セグメントではないと判断された場合（例えば、図８のデータセグメントＤ４）、ステップＳ９において、ＴＣＰ制御部３２は、送信データセグメントを、ネットワーク３を介して、ＰＣ１−２に送信し、図１０のステップＳ１に戻り、それ以降の処理を繰り返す。
【００７６】
一方、ＴＣＰ制御部３２は、図１０のステップＳ４において、前回のデータセグメントを送信してから所定の時間が経過したと判断した場合、再送タイマをタイムアウトし、図１２のステップＳ１１に進み、ＴＣＢ記憶部３３のｌｅａｐ＿ｆｌｇがオン状態であるか否かを判断する。ステップＳ１１において、ＴＣＢ記憶部３３のｌｅａｐ＿ｆｌｇがオン状態であると判断された場合、ＴＣＰ制御部３２は、ステップＳ１２に進み、ＴＣＢ記憶部３３のｌｅａｐ＿ｓｅｑ変数の飛躍セグメントのシーケンス番号に基づいて、飛躍セグメントを送信し、図１０のステップＳ１に戻り、それ以降の処理を繰り返す。ここで、ＴＣＢ記憶部３３のｌｅａｐ＿ｆｌｇがオン状態であるということは、すでに飛躍セグメントがＰＣ１−２に送信されているが、送信された飛躍セグメントに対応するＡＣＫセグメントがＰＣ１−２から受信されていないということである。したがって、ステップＳ１２において、飛躍セグメントは、ＰＣ１−２に再送されていることになる。
【００７７】
このようにして、ＰＣ１−１は、飛躍セグメントに対応するＡＣＫセグメントが受信されるまで飛躍セグメントをＰＣ１−２に再送し続ける。なお、従来のＴＣＰのＲｅｎｏ方式においては、同一データセグメントを１３回送信してもＡＣＫセグメントが受信されない場合、そのデータセグメントは、コネクションを諦めて破棄されるようになっている。ＬＥＡＰ方式の場合、飛躍セグメントの１回目の送信が、従来のデータセグメントの１回目の再送（２回目の送信）である。そこで、従来のＴＣＰとの整合性を保つため、飛躍セグメントの送信が１２回目になってもＡＣＫセグメントが受信されない場合、飛躍セグメントは、従来のＴＣＰと同様にコネクションを諦めて破棄される。また、上述したように、飛躍セグメントに対応するＡＣＫが欠損する場合もあるので、飛躍セグメントを複数保持するようにしてもよい。
【００７８】
なお、実際には、ＰＣ１−１は、受信したＡＣＫセグメントが飛躍セグメントに対応するものであるか否かは判断できないので、以前に送信したデータセグメントに対応するＡＣＫセグメントが遅延して到着し、ｌｅａｐ＿ｆｌｇをオフ状態にしてしまう場合もある。しかしながら、再送タイマのタイムアウトの値（再送タイマ動作時間）は、ネットワークの遅延を基準としてその数倍の時間が設定されるため、このようなＡＣＫセグメントの遅延が起こり、同時に飛躍セグメントが欠損している状況はまれであるといえる。
【００７９】
ステップＳ１１において、ＴＣＢ記憶部３３のｌｅａｐ＿ｆｌｇがオフ状態である（ネットワーク３上に飛躍セグメントは存在しない）と判断された場合、ＴＣＰ制御部３２は、ステップＳ１３に進み、受信側のＰＣ１−２において受信されていない最小のシーケンス番号のデータセグメントである、再送セグメント（例えば、図８のデータセグメントＤ１）に対する重複ＡＣＫを受信したか否かを判断し、再送セグメントに対する重複ＡＣＫを受信したと判断した場合、ステップＳ１６に進み、ネットワーク３を介してＰＣ１−２に、再送セグメントを送信し、図１０のステップＳ１に戻り、それ以降の処理を繰り返す。
【００８０】
このステップＳ１３の処理について、図１３を参照して説明する。図１３の例の場合、送信側ＰＣ１−１は、ＴＣＰウインドウの値が「４」であるので、４つのデータセグメントＤ１乃至Ｄ４をＴＣＰウインドウとして設定し、ＴＣＰウインドウ内のデータセグメントを、ネットワーク３を介して、受信側のＰＣ１−２に送信する。しかしながら、データセグメントＤ１は、ネットワーク３上で欠損してしまう。この場合、受信側ＰＣ１−２は、データセグメントＤ２乃至Ｄ４を受信し、各データセグメントに対応するＡＣＫセグメントＡ２乃至Ａ４を、ネットワーク３を介して、送信側のＰＣ１−１に送信する。ＡＣＫセグメントＡ２乃至Ａ４は、受信側のＰＣ１−２において受信されていない最小のシーケンス番号のデータセグメントであるデータセグメントＤ１を要求する。
【００８１】
この場合、ＡＣＫセグメントＡ２と同一のデータセグメントＤ１（再送セグメント）を要求しているＡＣＫセグメントＡ３およびＡ４は、再送セグメントに対する重複ＡＣＫとされる。このように、送信側のＰＣ１−１において、重複ＡＣＫが受信された場合、送信側のＰＣ１−２に、再送セグメントであるデータセグメントＤ１が受信されていないことが可能性が高いといえる（なお、データセグメントＤ１だけが遅延してデータセグメントＤ２、Ｄ３またはＤ４の後に到着することもあるが、非常に低い確率である）。したがって、再送セグメントに対する重複ＡＣＫが受信されている場合は、再送セグメントであるデータセグメントＤ１が送信側のＰＣ１−２に受信され、それに対応するＡＣＫセグメントがネットワーク３上で損失された可能性がないに等しいので、この場合には、飛躍セグメントではなく、ＴＣＰ制御部３２は、重複ＡＣＫが要求する再送セグメントを送信するように制御する。
【００８２】
ステップＳ１３において、再送セグメントに対する重複ＡＣＫを受信していないと判断された場合、ＴＣＰ制御部３２は、ステップＳ１４に進み、ＴＣＰのヘッダのフラグ領域に基づいて、再送セグメントに特殊ビットが設定されているか否かを判断する。ステップＳ１４において、再送セグメントに特殊ビットが設定されていると判断された場合、ステップＳ１６に進み、ネットワーク３を介してＰＣ１−２に、再送セグメントを送信し、図１０のステップＳ１に戻り、それ以降の処理を繰り返す。
【００８３】
このステップＳ１４の処理について具体的に説明すると、ＴＣＰのデータセグメントには、順序を入れ換えて送信しても意味があるデータセグメントと、順序を入れ換えて送信してしまうと、そのデータセグメントが持つ意味がなくなってしまうデータセグメントが存在する。後者のデータセグメントとしては、例えば、コネクション（データ転送）開始時に送信されるＳＹＮセグメントがある。ＳＹＮセグメントがネットワーク３上で欠損し、ＰＣ１−２に受信されていない場合に、飛躍セグメントとして新しいデータセグメントが受信側のＰＣ１−２に送信されたとしても、受信側のＰＣ１−２は受け取ることができない。したがって、このような場合には、ＴＣＰ制御部３２は、飛躍セグメントではなく、再送セグメント（ＳＹＮセグメント）を送信するように制御する。
【００８４】
このようなセグメントは、ＳＹＮセグメントの他にコネクション終了時に送信されるＦＩＮセグメント、コネクション強制終了時に送信されるＲＳＴセグメント、および、一連のセグメントをデータ制御部３１に渡すためのトリガとなるＰＵＳＨセグメントがある。
【００８５】
ステップＳ１４において、再送セグメントに特殊ビットが設定されていないと判断された場合、ＴＣＰ制御部３２は、ステップＳ１５に進み、直前に受信したＡＣＫセグメントに基づいて、受信側のＰＣ１−２の受信バッファ３７が送信データセグメントを受信可能であるか否かを判断する。ステップＳ１５において、受信側のＰＣ１−２の受信バッファ３７が、送信データセグメントを受信可能ではないと判断された場合、ステップＳ１６に進み、ネットワーク３を介してＰＣ１−２に、再送セグメントを送信し、図１０のステップＳ１に戻り、それ以降の処理を繰り返す。
【００８６】
このステップＳ１４の処理について具体的に説明する。ＴＣＰウインドウの値は、送信側ＰＣ１−１のＴＣＰ制御部３２が保持する輻輳ウインドウの値と、受信側ＰＣ１−２からＡＣＫセグメントにより告知される広告ウインドウの値の小さい方が設定される。広告ウインドウの値は、受信側のＰＣ１−２の受信バッファ３７の空き容量であるため、広告ウインドウの値を越えたデータセグメントはバッファされずに破棄される。極度の輻輳時には、データセグメントの欠損により輻輳ウインドウが収縮しているため、ＴＣＰウインドウは、受信側からの広告ウインドウではなく輻輳ウインドウで制限されることが多い。しかしながら、輻輳時以外にも、ＡＣＫセグメントの欠損は発生することがあるため、飛躍セグメントが広告ウインドウ（受信バッファ３７）の大きさを越えている場合、ＴＣＰ制御部３２は、飛躍セグメントではなく、再送セグメントを送信するように制御する。
【００８７】
ステップＳ１５において、受信側のＰＣ１−２の受信バッファ３７が、送信データセグメントを受信可能であると判断された場合、ＴＣＰ制御部３２は、ステップＳ１７において、ＴＣＢ記憶部３３のｌｅａｐ＿ｆｌｇをオン状態に設定し、ステップＳ１８に進む。ＴＣＰ制御部３２は、ステップＳ１８において、送信データセグメントのシーケンス番号をｌｅａｐ＿ｓｅｑ変数に保持し、送信データセグメントを飛躍セグメントとし、ステップＳ１９に進む。ＴＣＰ制御部３２は、ステップＳ１９において、送信部３５を制御し、飛躍セグメントを、ネットワーク３を介して、受信側のＰＣ１−２に送信し、図１０のステップＳ１に戻り、以降の処理を繰り返す。
【００８８】
図１０のステップＳ１において、ＴＣＰ制御部３２は、送信データセグメントが送信バッファ３４にないと判断した場合、データ送信処理を終了させる。
【００８９】
次に、図１４および図１５を参照して、図５の情報処理システムにおいて実行されたデータ転送のシミュレーション結果を説明する。このシミュレーションは、３台のＰＣ１−１乃至１−３が１台のルータ２を経由して接続しているネットワーク３のネットワーク環境において、１００個のデータを送出するＦＴＰのコネクション（データ転送）を指数分布の間隔に従ってランダムに発生させ、１秒間に発生するコネクションの数の平均値を、０．２５コネクション刻みで、１コネクションから３．５コネクションまで変更させて、３０００秒間実行されたものである。なお、このシミュレーションにおいては、図８を参照して上述したＬＥＡＰ方式および図９を参照して上述した従来のＴＣＰの方式としてＲｅｎｏ方式が用いられている。
【００９０】
図１４は、１コネクションにおける平均送受信パケット数を示すグラフである。図１４の例においては、横軸は、１秒間に発生するコネクションの数の平均値（トラフィック負荷度）を示しており、トラフィックの負荷度は、右に行くに従って高くなる。縦軸は、ＬＥＡＰ方式、および従来のＲｅｎｏ方式を用いた場合の送信パケット数（ｓ）と受信パケット数（ｒ）を示しており、送受信パケット数は、上に行くに従って多くなる。
【００９１】
図１４の例の場合、ＬＥＡＰ方式においては、トラフィック負荷度が１コネクション数／秒のとき、送信パケット数は、１００．０１３パケットであり、受信パケット数は、１００．００１パケットであり、トラフィック負荷度が１．２５コネクション数／秒のとき、送信パケット数は、１００．０７パケットであり、受信パケット数は、１００．０１７パケットである。トラフィック負荷度が１．５コネクション数／秒のとき、送信パケット数は、１００．２３パケットであり、受信パケット数は、１００．０４３パケットであり、トラフィック負荷度が１．７５コネクション数／秒のとき、送信パケット数は、１００．６６５パケットであり、受信パケット数は、１００．１２６パケットである。トラフィック負荷度が２コネクション数／秒のとき、送信パケット数は、１００．９２４パケットであり、受信パケット数は、１００．１８２パケットであり、トラフィック負荷度が２．２５コネクション数／秒のとき、送信パケット数は、１０２．００３パケットであり、受信パケット数は、１００．５０６パケットである。
【００９２】
また、トラフィック負荷度が２．５コネクション数／秒のとき、送信パケット数は、１０３．６６パケットであり、受信パケット数は、１００．８９９パケットであり、トラフィック負荷度が２．７５コネクション数／秒のとき、送信パケット数は、１０５．０９６パケットであり、受信パケット数は、１０１．３３５パケットである。また、トラフィック負荷度が３コネクション数／秒のとき、送信パケット数は、１０６．９８９パケットであり、受信パケット数は、１０１．６４６パケットであり、トラフィック負荷度が３．２５コネクション数／秒のとき、送信パケット数は、１１０．１７７パケットであり、受信パケット数は、１０１．７８３パケットであり、トラフィック負荷度が３．５コネクション数／秒のとき、送信パケット数は、１１３．９９パケットであり、受信パケット数は、１０１．５９パケットである。
【００９３】
一方、従来のＲｅｎｏ方式においては、トラフィック負荷度が１コネクション数／秒のとき、送信パケット数は、１００．００１パケットであり、受信パケット数は、１００．００１パケットであり、トラフィック負荷度が１．２５コネクション数／秒のとき、送信パケット数は、１００．０７３パケットであり、受信パケット数は、１００．０２２パケットである。トラフィック負荷度が１．５コネクション数／秒のとき、送信パケット数は、１００．２１３パケットであり、受信パケット数は、１００．０４５パケットであり、トラフィック負荷度が１．７５コネクション数／秒のとき、送信パケット数は、１００．６８９パケットであり、受信パケット数は、１００．１６８パケットである。トラフィック負荷度が２コネクション数／秒のとき、送信パケット数は、１０１．４８５パケットであり、受信パケット数は、１００．４４８パケットであり、トラフィック負荷度が２．２５コネクション数／秒のとき、送信パケット数は、１０２．７２１パケットであり、受信パケット数は、１００．８１４パケットである。
【００９４】
また、トラフィック負荷度が２．５コネクション数／秒のとき、送信パケット数は、１０６．６９６パケットであり、受信パケット数は、１０３．１４７パケットであり、トラフィック負荷度が２．７５コネクション数／秒のとき、送信パケット数は、１２８．８５３パケットであり、受信パケット数は、１０９．０６１パケットである。また、トラフィック負荷度が３コネクション数／秒のとき、送信パケット数は、１８５．７２７パケットであり、受信パケット数は、１２０．３９４パケットであり、トラフィック負荷度が３．２５コネクション数／秒のとき、送信パケット数は、１９４．２９８パケットであり、受信パケット数は、１２３．３７パケットであり、トラフィック負荷度が３．５コネクション数／秒のとき、送信パケット数は、２０９．２６８パケットであり、受信パケット数は、１３０．０５６パケットである。
【００９５】
図１４のグラフにおいて、例えば、トラフィック負荷度が３．２５コネクション数／秒のとき、Ｒｅｎｏ方式の送信パケット数は、１９４．２９８パケットであり、ＬＥＡＰ方式の送信パケット数は、１１０．１７７パケットである。すなわち、ＬＥＡＰ方式を用いることにより、矢印Ｑ１に示されるように、およそ８０パケットの無駄な送信パケットが減少する。また、例えば、トラフィック負荷度が３．５コネクション数／秒のとき、Ｒｅｎｏ方式の受信パケット数は、１３０．０５６パケットであり、ＬＥＡＰ方式の受信パケット数は、１０１．５９パケットである。すなわち、ＬＥＡＰ方式を用いることにより、矢印Ｑ２に示されるように、およそ３０パケットの無駄な受信パケットが減少する。
【００９６】
さらに、ＬＥＡＰ方式においては、受信パケット数は、ほぼ１００パケットに近づいている。これにより、図１４においては、１コネクションが転送するセグメント数は、１００パケットであるため、ＬＥＡＰ方式においては、無駄のないデータ転送が実現されていることがわかる。なお、１００パケットちょうどにならないのは、ＳＹＮセグメントまたはＦＩＮセグメントなどの特殊セグメントが再送される場合、もしくは、飛躍セグメントのＡＣＫセグメントが欠損してしまい、到着したはずの飛躍セグメントが再送される場合があるためである。
【００９７】
また、受信パケット数が減少するということは、すなわち、送信パケット数が減少することにも関係する。したがって、コネクション全体で送信するパケット数が減少するため、ネットワーク３全体でのトラフィックの負荷度が抑制される。このため、パケット欠損率も抑制され、その結果、送信パケット数は、さらに減少する。
【００９８】
図１５は、シミュミレーション時間内に終了したデータ転送の数を示すグラフである。図１５の例においては、横軸は、１秒間に発生するコネクションの数の平均値（すなわち、トラフィック負荷度）を示しており、トラフィックの負荷は、右に行くに従って高くなる。縦軸は、ＬＥＡＰ方式および従来のＲｅｎｏ方式を用いてデータ転送が終了したコネクション数（終了コネクション数）を示しており、終了コネクション数は、上に行くに従って多くなる。
【００９９】
図１５のグラフの場合、ＬＥＡＰ方式においては、トラフィック負荷度が１コネクション数／秒のとき、２９９７コネクションが終了し、トラフィック負荷度が１．２５コネクション数／秒のとき、３６９４コネクションが終了し、トラフィック負荷度が１．５コネクション数／秒のとき、４４２５コネクションが終了している。また、トラフィック負荷度が１．７５コネクション数／秒のとき、５１２２コネクションが終了し、トラフィック負荷度が２コネクション数／秒のとき、５９１２コネクションが終了し、トラフィック負荷度が２．２５コネクション数／秒のとき、６７２５コネクションが終了している。トラフィック負荷度が２．５コネクション数／秒のとき、７３８７コネクションが終了し、トラフィック負荷度が２．７５コネクション数／秒のとき、８０７０コネクションが終了し、トラフィック負荷度が３コネクション数／秒のとき、８３４２コネクションが終了している。また、トラフィック負荷度が３．２５コネクション数／秒のとき、８３７０コネクションが終了し、トラフィック負荷度が３．５コネクション数／秒のとき、７７７２コネクションが終了している。
【０１００】
一方、従来のＲｅｎｏ方式においては、トラフィック負荷度が１コネクション数／秒のとき、２９３２コネクションが終了し、トラフィック負荷度が１．２５コネクション数／秒のとき、３６７９コネクションが終了し、トラフィック負荷度が１．５コネクション数／秒のとき、４４５３コネクションが終了している。また、トラフィック負荷度が１．７５コネクション数／秒のとき、５２１４コネクションが終了し、トラフィック負荷度が２コネクション数／秒のとき、５８４８コネクションが終了し、トラフィック負荷度が２．２５コネクション数／秒のとき、６６６７コネクションが終了している。トラフィック負荷度が２．５コネクション数／秒のとき、７４５０コネクションが終了し、トラフィック負荷度が２．７５コネクション数／秒のとき、７９２８コネクションが終了し、トラフィック負荷度が３コネクション数／秒のとき、６７０１コネクションが終了している。また、トラフィック負荷度が３．２５コネクション数／秒のとき、６０８０コネクションが終了し、トラフィック負荷度が３．５コネクション数／秒のとき、４５０８コネクションが終了している。
【０１０１】
図１５のグラフの横軸に注目すると、従来のＲｅｎｏ方式の場合、２．５コネクション数／秒までは直線的に終了コネクション数が直線的に増加している。しかしながら、トラフィック負荷度が２．７５コネクション数／秒のとき、７９２８コネクションであった終了コネクション数が、トラフィック負荷度が３コネクション数／秒のとき、６７０１コネクションに減少していることに示されるように、トラフィック負荷度が２．７５コネクション数／秒を越えたあたりから、終了コネクション数は、急激に減少している。
【０１０２】
一方、ＬＥＡＰ方式を用いた場合には、トラフィック負荷度が３．２５コネクション数／秒のとき、８３７０コネクションであった終了コネクション数が、トラフィック負荷度が３．５コネクション数／秒のとき、７７７２コネクションに減少していることに示されるように、トラフィック負荷度が３．２５コネクション数／秒を越えたあたりから、終了コネクション数は、徐々に減少している。
【０１０３】
また、図中の矢印に示されるように、トラフィック負荷度が３．５コネクション数／秒のあたりにおいては、Ｒｅｎｏ方式では、４５０８コネクションしか終了していないのに対して、ＬＥＡＰ方式では、Ｒｅｎｏ方式の倍近くの７７７２コネクションが終了している。以上のように、ＬＥＡＰ方式を用いることにより、図５のネットワーク３全体の資源利用効率も大幅に上昇させることができる。
【０１０４】
以上のように、ＬＥＡＰ方式を用いることにより、輻輳時のネットワーク状態において、重複したセグメントの送信を回避し、無駄のない、効率的なデータ転送をすることができる。
【０１０５】
また、ＬＥＡＰ方式においては、送信側の機能を追加しただけであり、実装が容易にできる。さらに、従来のＴＣＰのＲｅｎｏ方式などとも整合性をとるようにしたので、輻輳していない通常のネットワーク状態におけるＴＣＰの性能を劣化させることもない。
【０１０６】
なお、上記説明においては、ＴＣＰプロトコルを用いてデータ送信処理を実行したが、確認応答のＡＣＫを用いるものであれば、他のプロトコルを用いるようにしてもよい。
【０１０７】
上述した一連の処理は、ハードウェアにより実行させることもできるが、ソフトウェアにより実行させることもできる。一連の処理をソフトウェアにより実行させる場合には、そのソフトウェアを構成するプログラムが、専用のハードウェアに組み込まれているコンピュータ、または、各種のプログラムをインストールすることで、各種の機能を実行することが可能な、例えば汎用のパーソナルコンピュータなどに、プログラム格納媒体からインストールされる。
【０１０８】
コンピュータにインストールされ、コンピュータによって実行可能な状態とされるプログラムを格納するプログラム格納媒体は、図６に示されるように、磁気ディスク２１（フレキシブルディスクを含む）、光ディスク２２（ＣＤ−ＲＯＭ（Ｃｏｍｐａｃｔ Ｄｉｓｃ−Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、ＤＶＤ（Ｄｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｃ）を含む）、光磁気ディスク２３（ＭＤ（Ｍｉｎｉ−Ｄｉｓｃ）（商標）を含む）、もしくは半導体メモリ２４などよりなるパッケージメディア、または、プログラムが一時的もしくは永続的に格納されるＲＯＭ１２や、記憶部１８などにより構成される。
【０１０９】
なお、本明細書において、記録媒体に記録されるプログラムを記述するステップは、記載された順序に従って時系列的に行われる処理はもちろん、必ずしも時系列的に処理されなくとも、並列的あるいは個別に実行される処理をも含むものである。
【０１１０】
なお、本明細書において、システムとは、複数の装置により構成される装置全体を表すものである。
【０１１１】
【発明の効果】
以上の如く、本発明によれば、通常時のデータ転送の性能を劣化させることなく、重度の輻輳時に、効率的にデータを送信することができる。
【図面の簡単な説明】
【図１】従来のデータ再送処理について説明する図である。
【図２】従来のデータ再送処理の他の例について説明する図である。
【図３】従来のＴＣＰの方式において、シミュミレーション時間内に終了したコネクションの数を示すグラフである。
【図４】従来のＴＣＰの方式において、１コネクションにおける平均送受信パケット数を示すグラフである。
【図５】本発明を適用した情報処理システムの構成例を示す図である。
【図６】図５のパーソナルコンピュータの構成例を示すブロック図である。
【図７】図５のパーソナルコンピュータの機能構成例を示すブロック図である。
【図８】図５の情報処理システムにおけるＬＥＡＰ方式のデータ再送処理について説明する図である。
【図９】図８のＬＥＡＰ方式と比較するための従来のＲｅｎｏ方式のデータ再送処理について説明する図である。
【図１０】図５のパーソナルコンピュータのデータ送信処理を説明するフローチャートである。
【図１１】図５のパーソナルコンピュータのデータ送信処理を説明するフローチャートである。
【図１２】図５のパーソナルコンピュータのデータ送信処理を説明するフローチャートである。
【図１３】再送セグメントの重複ＡＣＫを説明する図である。
【図１４】図８のＬＥＡＰ方式と従来のＲｅｎｏ方式の１コネクションにおける平均送受信パケット数を示すグラフである。
【図１５】図８のＬＥＡＰ方式と従来のＲｅｎｏ方式のシミュミレーション時間内に終了したコネクションの数を示すグラフである。
【符号の説明】
１−１乃至１−３ パーソナルコンピュータ，２ ルータ，３ ネットワーク，１１ ＣＰＵ，３１ データ制御部，３２ ＴＣＰ制御部，３３ ＴＣＢ記憶部，３４ 送信バッファ，３５ 送信部，３６ 受信部，３７ 受信バッファ
【発明の属する技術分野】
本発明は、情報処理装置および方法、記録媒体、並びにプログラムに関し、特に、重度の輻輳時に、効率的にデータを送信することができるようにした情報処理装置および方法、記録媒体、並びにプログラムに関する。
【０００２】
【従来の技術】
インターネットに用いられるトランスポート層のプロトコルとしては、例えば、コネクションレスのＵＤＰ（Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ）と、コネクションを行うことにより信頼性を確保するＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）が存在する。
【０００３】
インターネットを利用するユーザの多くは、各自のネットワークインフラ（Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ）を最大限に利用したいと考えている。そこで、ＵＤＰにおいては、特許文献１に示されるように、ＮＡＣＫ（Ｎｅｇａｔｉｖｅ ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ）を用いて、欠損要求があったデータのみを送ることにより、多数のユーザに対して、データを効率的、かつ高い信頼性で配信することができるようにした送受信装置が提案されている。
【０００４】
一方、ＴＣＰは、上位アプリケーションから受け取ったデータを、１００％確実に送信することを保証するプロトコルである。ＴＣＰで送受信される情報は、セグメントと呼ばれる単位で送受信される。セグメントには、データセグメントとＡＣＫ（ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ：確認応答）セグメントの２種類が存在する。ＴＣＰは、この２種類のセグメントを利用して、次のような輻輳制御により通信の信頼性を確保する。
【０００５】
まず、送信側のＴＣＰは、データセグメントを受信側に送信する。このデータセグメントを受信すると、受信側のＴＣＰは、受信したデータセグメントに対応するＡＣＫセグメントを送信側に送信する。送信側のＴＣＰは、ＡＣＫセグメントを受信することで、データセグメントの送信が成功したことを確認する。したがって、ＡＣＫセグメントが受信されなかったデータセグメントは、送信側のＴＣＰにより再度送信されることになる。しかしながら、この場合、送信側のＴＣＰでは、図１に示されるように、送信側のＴＣＰからのデータセグメントが欠損したのか、あるいは、図２に示されるように、受信側のＴＣＰからのＡＣＫセグメントが欠損したのかの判断が行われていない。したがって、送信側のＴＣＰは、データセグメント、ＡＣＫセグメントのどちらが欠損してもデータセグメントの再送処理を実行する。
【０００６】
図１および図２は、送信側のＴＣＰによるデータセグメントの再送処理の例を示している。送信側と受信側は、図示せぬネットワークを介してセグメントを通信する。図１の例においては、送信側のＴＣＰから送信されたデータセグメントＤ１は、受信側に到着する前のネットワーク上で欠損する。したがって、受信側のＴＣＰからデータセグメントＤ１に対応するＡＣＫセグメントは送信されず、送信側のＴＣＰはＡＣＫセグメントを受信することができない。送信側のＴＣＰは、データセグメントＤ１を送信してから、再送タイマを起動し、再送タイマにより計時動作を行い、所定の時間（再送タイマ動作時間）が経過したか否かを判断し、所定の時間が経過してもＡＣＫセグメントＡ１が受信されない場合、データセグメントＤ１を再送セグメントとして受信側に送信する。これにより、受信側のＴＣＰは、データセグメントＤ１を受信することができる。
【０００７】
一方、図２の例においては、送信側のＴＣＰから送信されたデータセグメントＤ２は、受信側に無事到着する。受信側のＴＣＰは、受信したデータセグメントＤ２に対応するＡＣＫセグメントＡ２を送信側に送信する。しかしながら、ＡＣＫセグメントＡ２は、送信側に到着する前のネットワーク上において欠損し、送信側のＴＣＰは、それを受信することができない。受信側のＴＣＰは、データセグメントＤ２を送信してから、再送タイマを起動させ、再送タイマにより計時動作を行い、所定の時間（再送タイマ動作時間）が経過したか否かを判断し、所定の時間が経過してもＡＣＫセグメントＡ２が受信されない場合、データセグメントＤ２を再送セグメントとして受信側に送信する。しかしながら、受信側では、前回の送信により、すでにデータセグメントＤ２が受信されている。したがって、受信側のＴＣＰは、データセグメントＤ２を重複して受信することになる。
【０００８】
以上のように、ＡＣＫセグメントの欠損によるデータセグメントの再送は、受信側に到着しているデータセグメントを再度送信することになるため、無駄な処理になってしまう。
【０００９】
なお、ＴＣＰの確認応答の方法においては、シーケンス番号が割り振られたデータセグメントがどこまで届いたのかをＡＣＫセグメントが通知する累積確認応答が行われる。したがって、ＡＣＫセグメントが欠損したとしても、それ以降に連続して受信側から送信されるＡＣＫセグメントが送信側に到達する。受信側においては、それらのＡＣＫセグメントにより、どのデータセグメントが届いているかの状況が把握できるので、欠損したＡＣＫセグメントかあっても再送処理に関して影響を与えない。
【００１０】
しかしながら、これは、データセグメントが円滑に送信され、ＴＣＰの送信ウインドウが拡張しているような場合、すなわち、受信側で送信されるＡＣＫセグメントの数が十分多く存在するような場合に限られる。例えば、頻繁な輻輳制御により、ＴＣＰの送信ウインドウが収縮している場合、受信側のＴＣＰで送信されるＡＣＫセグメントの数も少なくなる。このような場合に、ＡＣＫセグメントが欠損した場合、それ以降に連続して受信側から送信されるＡＣＫセグメントが少ないため、送信側に到達するＡＣＫセグメントはさらに少ない。したがって、ＴＣＰの送信ウインドウが収縮している場合において、ＡＣＫセグメントの欠損により、データセグメントの再送が実行され、その結果、データセグメントが重複してしまう確率は、ＴＣＰの送信ウインドウが拡張しているような場合の確率よりも高くなる。
【００１１】
次に、図３および図４のグラフを参照して、３台のノードが１台のノードを経由して接続しているネットワーク環境において実行されたデータ転送のシミュレーション結果を説明する。このシミュレーションは、３台のノードが１台のノードを経由して接続しているネットワーク環境において、１００個のデータを送出するＦＴＰ（Ｆｉｌｅ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）のコネクション（データ転送）を指数分布の間隔に従ってランダムに発生させ、１秒間に発生するコネクションの数の平均値を、０．２５コネクション刻みで、１コネクションから３．５コネクションまで変更させて、３０００秒間実行されたものである。なお、このシミュレーションにおいては、現在のＴＣＰの事実上の標準とされているＲｅｎｏ方式、ＴＣＰウインドウ（ＴＣＰにおいて用いられるバッファ量）内で複数のデータセグメントの欠損が起こった場合のＲｅｎｏ方式のＦａｓｔ Ｒｅｃｏｖｅｒｙを改良したＮｅｗＲｅｎｏ方式、および、ＡＣＫパケットにセグメントの欠損情報を格納することを可能としたＳａｃｋ方式の３種類のＴＣＰの方式が用いられている。
【００１２】
図３は、シミュミレーション時間内に終了したコネクション（データ転送）の数を示すグラフである。図３の例においては、横軸は、１秒間に発生するコネクションの数の平均値（すなわち、トラフィック負荷度）を示しており、トラフィックの負荷は、右に行くに従って高くなる。縦軸は、Ｒｅｎｏ方式、ＮｅｗＲｅｎｏ方式、およびＳａｃｋ方式を用いてデータ転送が終了したコネクション数（終了コネクション数）を示しており、終了コネクション数は、上に行くに従って多くなる。
【００１３】
図３のグラフの横軸に注目すると、ＴＣＰのどの方式においても、終了コネクション数は、図中矢印に示される２．５コネクション数／秒まで直線的に増加しているが、２．７５コネクション数／秒を過ぎたころから明らかに減少していることがわかる。これにより、このネットワークの許容量は、１秒間に２．５コネクション乃至２．７５コネクションを転送するあたりのトラフィック負荷度であり、この許容量を越えると、セグメント（データセグメントおよびＡＣＫセグメント）の欠損によりＴＣＰの輻輳制御（再送処理）が行われていることが予測される。
【００１４】
図４は、１コネクションにおける平均送受信パケット数を示すグラフである。図４の例においては、横軸は、１秒間に発生するコネクションの数の平均値（トラフィック負荷度）を示しており、トラフィックの負荷度は、右に行くに従って高くなる。縦軸は、Ｒｅｎｏ方式、ＮｅｗＲｅｎｏ方式、およびＳａｃｋ方式を用いた場合の送信パケット数（ｓ）と受信パケット数（ｒ）を示しており、送受信パケット数は、上に行くに従って多くなる。
【００１５】
図４のグラフにおいて、送信パケット数（矢印Ｐ１）と受信パケット数（矢印Ｐ２）の差は、ネットワーク内で実際に欠損したパケット数（矢印Ｐ３）である。ここで注意すべき点は、ＦＴＰのコネクション（データ転送）は、１００個のパケットを送受信するように設定されているにもかかわらず、ネットワークのトラフィックの負荷が高くなるにつれて、矢印Ｐ２に示されるように受信パケット数も増加していることである。これは、すなわち、受信側に重複したパケットが到着していることを示している。
【００１６】
なお、Ｒｅｎｏ方式、ＮｅｗＲｅｎｏ方式、およびＳａｃｋ方式において性能差がほとんど見られなかったのは、ＮｅｗＲｅｎｏ方式、およびＳａｃｋ方式は、ＴＣＰウインドウ内での複数のデータセグメントの欠損に対して有効であるが、いまの場合のように、トラフィックの負荷が高いときは、ＴＣＰウインドウの大きさが小さく収縮されているため、有効になる機会が少なかったといえる。
【００１７】
【特許文献１】
特開平１１−１７７３７号公報
【００１８】
【発明が解決しようとする課題】
以上のように、ネットワーク上において、トラフィックの負荷が高くなると、ＡＣＫセグメントの欠損が多くなり、結果的に、受信側に重複したデータセグメントが無駄に受信されてしまう課題があった。これにより、再送されるデータセグメントが増加してしまい、ますますトラフィックの負荷がかかってしまう課題があった。
【００１９】
本発明はこのような状況に鑑みてなされたものであり、重度の輻輳時に、効率的にデータを送信することができるようにするものである。
【００２０】
【課題を解決するための手段】
本発明の情報処理装置は、ネットワークを介して、所定のプロトコルでデータを他の情報処理装置に送信する送信手段と、送信手段によりデータが送信されてから所定の時間内に、他の情報処理装置からデータに対応するＡＣＫ（ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ）を受信したか否かを判断する受信判断手段とを備え、受信判断手段により他の情報処理装置からデータに対応するＡＣＫが受信されていないと判断された場合、送信手段は、前回送信されたデータに続く次のデータを送信することを特徴とする。
【００２１】
所定のプロトコルは、ＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）であるようにすることができる。
【００２２】
受信判断手段によりデータに対応するＡＣＫが受信されていないと判断された場合に、送信手段により送信された次のデータのシーケンス番号を記憶する記憶手段と、受信判断手段によりデータに対応するＡＣＫが受信されていないと判断され、送信手段により次のデータが送信された場合に、そのことを示すフラグを保持する保持手段とをさらに備えるようにすることができる。
【００２３】
保持手段によりフラグが保持されているか否かを判断するフラグ判断手段をさらに備え、受信判断手段によりデータに対応するＡＣＫが受信されていないと判断され、かつ、フラグ判断手段によりフラグが保持されていると判断された場合、送信手段は、受信判断手段によりＡＣＫが受信されていないと判断されたデータを再度送信するようにすることができる。
【００２４】
受信判断手段によりデータに対応するＡＣＫが受信されたと判断され、かつ、フラグ判断手段によりフラグが保持されていると判断された場合、保持手段は、フラグの保持を解除するようにすることができる。
【００２５】
受信判断手段によりデータに対応するＡＣＫが受信されたと判断された場合、次に送信する送信データのシーケンス番号が、記憶手段に記憶されているシーケンス番号と同じであるか否かを判断するデータ判断手段をさらに備え、データ判断手段により送信データのシーケンス番号が、記憶手段に記憶されているシーケンス番号と同じであると判断された場合、送信手段は、送信データの送信をスキップし、送信データの次のデータを送信するようにすることができる。
【００２６】
本発明の情報処理装置は、ネットワークを介して、所定のプロトコルでデータを他の情報処理装置に送信する送信ステップと、送信ステップの処理によりデータが送信されてから所定の時間内に、他の情報処理装置からデータに対応するＡＣＫを受信したか否かを判断する受信判断ステップとを含み、受信判断ステップの処理により他の情報処理装置からデータに対応するＡＣＫが受信されていないと判断された場合、送信ステップの処理は、前回送信されたデータに続く次のデータを送信することを特徴とする。
【００２７】
本発明の記録媒体のプログラムは、ネットワークを介して、所定のプロトコルでデータを他の情報処理装置に送信する送信ステップと、送信ステップの処理によりデータが送信されてから所定の時間内に、他の情報処理装置からデータに対応するＡＣＫを受信したか否かを判断する受信判断ステップとを含み、受信判断ステップの処理により他の情報処理装置からデータに対応するＡＣＫが受信されていないと判断された場合、送信ステップの処理は、前回送信されたデータに続く次のデータを送信することを特徴とする。
【００２８】
本発明のプログラムは、ネットワークを介して、所定のプロトコルでデータを他の情報処理装置に送信する送信ステップと、送信ステップの処理によりデータが送信されてから所定の時間内に、他の情報処理装置からデータに対応するＡＣＫを受信したか否かを判断する受信判断ステップとを含み、受信判断ステップの処理により他の情報処理装置からデータに対応するＡＣＫが受信されていないと判断された場合、送信ステップの処理は、前回送信されたデータに続く次のデータを送信することを特徴とする。
【００２９】
本発明においては、ネットワークを介して、所定のプロトコルでデータが他の情報処理装置に送信され、データが送信されてから所定の時間内に、他の情報処理装置からデータに対応するＡＣＫを受信したか否かが判断される。そして、他の情報処理装置からデータに対応するＡＣＫが受信されていないと判断された場合、前回送信されたデータに続く次のデータが送信される。
【００３０】
ネットワークとは、少なくとも２つの装置が接続され、ある装置から、他の装置に対して、情報の伝達をできるようにした仕組みをいう。ネットワークを介して通信する装置は、独立した装置どうしであってもよいし、１つの装置を構成している内部ブロックどうしであってもよい。
【００３１】
【発明の実施の形態】
以下、図を参照して本発明の実施の形態について説明する。
【００３２】
図５は、本発明を適用した情報処理システムの構成例を表している。ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）などで構成されるネットワーク３には、パーソナルコンピュータ（以下、ＰＣと称する）１−１乃至１−３が、ルータ２を介して接続される。なお、ネットワーク３は、ＬＡＮにより構成されるようにしたが、インターネットなどで構成されるようにしてもよく、接続される装置の台数も限定されない。
【００３３】
各ＰＣ１−１乃至１−３とルータ２間の帯域幅は、５００ｋｂｐｓで、遅延は５０ｍｓに設定される。また、また、各ＰＣ１−１乃至１−３のキューは、１００パケット分でドロップテイル方式を用いて、ＦＩＦＯ（Ｆｉｒｓｔ Ｉｎ Ｆｉｒｓｔ Ｏｕｔ）によりパケットを扱う。
【００３４】
ＰＣ１−１乃至１−３は、ＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）プロトコルのＬＥＡＰ方式（図８を参照して後述する）を用いて、ルータ２を介してお互いにデータ送受信（コネクション）を実行する。
【００３５】
図６は、ＰＣ１−１乃至１−３（個々に区別する必要がない場合、単にＰＣ１と称する）の構成を表している。図６において、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）１１は、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）１２に記憶されているプログラム、または記憶部１８からＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）１３にロードされたプログラムに従って各種の処理を実行する。ＲＡＭ１３にはまた、ＣＰＵ１１が各種の処理を実行する上において必要なデータなども適宜記憶される。
【００３６】
ＣＰＵ１１、ＲＯＭ１２およびＲＡＭ１３は、バス１４を介して相互に接続されている。このバス１４にはまた、入出力インタフェース１５も接続されている。
【００３７】
入出力インタフェース１５には、キーボード、マウスなどよりなる入力部１６、ＣＲＴ（Ｃａｔｈｏｄｅ Ｒａｙ Ｔｕｂｅ）、ＬＣＤ（Ｌｉｑｕｉｄ Ｃｒｙｓｔａｌ Ｄｉｓｐｌａｙ）などよりなるディスプレイ、並びにスピーカなどよりなる出力部１７、ハードディスクなどより構成される記憶部１８、モデム、ターミナルアダプタなどより構成される通信部１９が接続されている。通信部１９は、ネットワーク３を介しての通信処理を行う。
【００３８】
入出力インタフェース１５にはまた、必要に応じてドライブ２０が接続され、磁気ディスク２１、光ディスク２２、光磁気ディスク２３、或いは半導体メモリ２４などが適宜装着され、それらから読み出されたコンピュータプログラムが、必要に応じて記憶部１８にインストールされる。
【００３９】
なお、ルータ３も、ＰＣ１と基本的に同様に構成されている。したがって、以下の説明においては、図６のＰＣ１の構成は、必要に応じて、ルータ３の構成としても引用する。
【００４０】
図７は、ＰＣ１のデータ送受信処理における機能構成例を示すブロック図である。図７に示される機能ブロックは、ＰＣ１の図６のＣＰＵ１１により所定の制御プログラムが実行されることで実現される。
【００４１】
データ制御部３１は、ＰＣ１のデータ送受信処理において、ユーザ側のインタフェース部分を提供する。データ制御部３１は、ユーザの操作により、図６の入力部１６を介して入力される指示に基づいて、記憶部１９に記憶されているデータを一旦読み込み、読み込んだデータを送信バッファ３４に書き込む。また、データ制御部３１は、受信バッファ３７のデータを読み込み、入力部１６を介して入力されるユーザの指示のもと、記憶部１９に書き込んだり、そのままプログラムで使用する。
【００４２】
ＴＣＰ制御部３２は、図８を参照して詳しく後述するＴＣＰプロトコルのＬＥＡＰ方式に基づいて、ＴＣＢ（ＴＣＰ Ｃｏｎｔｒｏｌ Ｂｌｏｃｋ）記憶部３３にネットワーク３を介して実行されるコネクションの状態を保持しながら、送信バッファ３４、送信部３５、受信部３６および受信バッファ３７を制御し、データ送受信処理を実行する。
【００４３】
ＴＣＰ制御部３２は、データ制御部３１により書き込まれた送信バッファ３４内のデータをＴＣＰセグメントの大きさに区切り、ＴＣＰウインドウの値の数のデータセグメントを、ＴＣＰウインドウとして設定し、ＴＣＰウインドウ内のデータセグメントを送信部３５に供給する。ＴＣＰウインドウの値は、送信されるデータセグメント量を示しており、ネットワーク３において、セグメントの損失がなければ、徐々に大きくなる。しかしながら、セグメントが欠損すると、ＴＣＰウインドウの値は、１セグメントに戻る。ＴＣＰ制御部３２は、このようなＴＣＰウインドウの値を用いて、送信するデータセグメントの量を調整する。
【００４４】
また、ＴＣＰ制御部３２は、送信部３５からデータセグメントが送信されると、内蔵する再送タイマを起動させる。再送タイマは、受信部３６に、他のＰＣから、前回送信されたデータセグメントを受信したことを通知するＡＣＫ（ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ：確認応答）セグメントが受信されると停止する。再送タイマは、所定の時間（再送タイマ動作時間）が経過しても、受信部３６にＡＣＫセグメントが受信されない場合、タイムアウトする。なお、ＡＣＫセグメントは、シーケンス番号が割り振られたデータセグメントがどこまで届いたのかを確認し、届いていないシーケンス番号の最小のデータセグメントを送信側のＰＣに要求する機能を有する。
【００４５】
ＴＣＰ制御部３２は、再送タイマにより計時動作を行い、受信部３６を監視しており、他のＰＣから前回送信されたデータセグメントに対応するＡＣＫセグメントが所定の時間（再送タイマ動作時間）内に受信されたか否かを判断し、その判断に基づいて、どのデータセグメントを送信部３５に供給するかを制御する。
【００４６】
具体的には、受信部３６が前回送信されたデータセグメントに対応するＡＣＫセグメントを受信した場合、ＴＣＰ制御部３２は、ＴＣＰウインドウの値を拡張し、受信したＡＣＫセグメントが要求するデータセグメントから、ＴＣＰウインドウの値の数のデータセグメントを、ＴＣＰウインドウとして設定し、ＴＣＰウインドウ内のデータセグメントを送信部３５に供給する。例えば、ＴＣＰウインドウの値が５であれば、受信したＡＣＫセグメントが要求するデータセグメントから、５個のデータセグメントを、ＴＣＰウインドウとして設定し、ＴＣＰウインドウ内のデータセグメントを送信部３５に供給する。
【００４７】
一方、受信部３６が前回送信されたデータセグメントに対応するＡＣＫを受信しなかった場合、ＴＣＰ制御部３２は、ネットワーク３上でのセグメント（ＡＣＫセグメントまたはデータセグメント）の欠損があったとして、ＴＣＰウインドウの値を１に収縮し、前回送信したデータセグメントのうち、シーケンス番号の最小のデータセグメントである再送セグメントを、ＴＣＰウインドウとして設定するが、その再送セグメントは送信せずに、前回送信したデータセグメント（すなわち、前回のＴＣＰウインドウ）の次のデータセグメントを飛躍セグメントとして送信部３５に供給する。
【００４８】
また、ＴＣＰ制御部３２は、受信部３６を監視しており、受信部３６が他のＰＣからネットワーク３を介して、データセグメントを受信した場合、受信したデータセグメントに対応するＡＣＫセグメントを送信部３５に供給する。
【００４９】
送信部３５は、ＴＣＰ制御部３２の制御のもと、ＴＣＰ制御部３２より供給されたデータセグメントまたはＡＣＫセグメントを、ネットワーク３を介して、他のＰＣに送信する。
【００５０】
ＴＣＢ記憶部３３は、メモリなどにより構成され、ＴＣＰ制御部３２により書き込まれたＴＣＰウインドウの値、再送タイマ動作時間、飛躍セグメントのシーケンス番号を格納するｌｅａｐ＿ｓｅｑｎｏ変数、および、飛躍セグメントがネットワーク３上にあるか否か（すなわち、送信されていて、まだ、飛躍セグメントに対応するＡＣＫセグメントを受信していない状態であるか否か）を判断するためのフラグであるｌｅａｐ＿ｆｌｇ変数などのコネクション（データ転送）の状態を保持している。送信バッファ３４は、３２ｋｂｙｔｅのバッファにより構成され、他のＰＣに送信するデータセグメントが一旦蓄積され、蓄積されたデータセグメントは、送信部３５により送信されると消去される。これにより、データ制御部３１は、送信バッファ３４の空き領域に、新たにデータを書き込むことができる。
【００５１】
受信部３６は、他のＰＣから送信されたＡＣＫセグメントを、ネットワーク３を介して受信する。また、受信部３６は、他のＰＣから送信されたデータセグメントを、ネットワーク３を介して受信し、受信したデータセグメントを順序どおりに並べ替えて、受信バッファ３７に書き込む。受信バッファ３７は、３２ｋｂｙｔｅのバッファにより構成され、受信部３６より書き込まれたデータが一旦蓄積される。蓄積されたデータは、データ制御部３１により読み込まれる。
【００５２】
次に、図５の情報処理システムの動作について説明する。
【００５３】
ＰＣ１−１のデータ制御部３１は、記憶部１９に記憶されているデータを一旦読み込み、読み込んだデータを送信バッファ３４に書き込む。ＴＣＰ制御部３２は、データ制御部３１により書き込まれた送信バッファ３４内のデータをＴＣＰセグメントの大きさに区切り、ＴＣＰウインドウの値の数のデータセグメントを、ＴＣＰウインドウとして設定し、ＴＣＰウインドウ内のデータセグメントを送信部３５に供給する。送信部３５は、ＴＣＰ制御部３２の制御のもと、ＴＣＰ制御部３２より供給されたデータセグメントを、ネットワーク３およびルータ２を介して、ＰＣ１−２に送信する。
【００５４】
ＰＣ１−２の受信部３６は、ＰＣ１−１から送信されたデータセグメントを、ネットワーク３およびルータ２を介して受信し、受信したデータセグメントを順序どおりに並べ替えて、受信バッファ３７に書き込む。ＴＣＰ制御部３２は、受信部３６を監視しており、受信部３６がＰＣ１−１からデータセグメントを受信した場合、受信したデータセグメントに対応するＡＣＫセグメントを送信部３５に供給する。送信部３５は、ＴＣＰ制御部３２の制御のもと、ＴＣＰ制御部３２より供給されたＡＣＫセグメントを、ネットワーク３およびルータ２を介して、ＰＣ１−１に送信する。
【００５５】
ＰＣ１−１の受信部３６は、ＰＣ１−２から送信されたＡＣＫセグメントを、ネットワーク３を介して受信する。ＴＣＰ制御部３２は、受信部３６を監視しており、再送タイマにより計時動作を行い、他のＰＣからＡＣＫセグメントが所定の時間（再送タイマ動作時間）内に受信されたか否かを判断し、受信部３６がＡＣＫセグメントを受信したと判断した場合、ＴＣＰウインドウの値を拡張し、受信したＡＣＫセグメントが要求するデータセグメントから、ＴＣＰウインドウの値の数のデータセグメントを、ＴＣＰウインドウとして設定し、ＴＣＰウインドウ内のデータセグメントを送信部３５に供給する。
【００５６】
以上のようにして、ネットワーク３上において、セグメントの欠損がない場合のＰＣ１−１およびＰＣ１−２間のデータ送受信処理が実行される。
【００５７】
次に、図８および図９を参照して、本発明のＬＥＡＰ方式と従来のＲｅｎｏ方式におけるセグメントが欠損した場合のデータセグメントの再送処理を比較して説明する。図８および図９の例においては、送信側のＰＣ１−１が、ネットワーク３を介して、受信側のＰＣ１−２にデータを送信する例について説明する。なお、図８は、本発明のＬＥＡＰ方式によるデータセグメントの再送処理を説明する図であり、図９は、従来のＲｅｎｏ方式によるデータセグメントの再送処理を説明する図である。また、以下のデータセグメントの再送処理は、ＰＣ１−１およびＰＣ１−２のＴＣＰ制御部３２が制御する処理であるが、それぞれ、ＰＣ１−１およびＰＣ１−２を主語として説明する。
【００５８】
図８の例において、「ｗｎｄ＝４」、「ｗｎｄ＝１」および「ｗｎｄ＝２」は、送信側のＰＣ１−１におけるＴＣＰウインドウの値が「４」、「１」および「２」であることを示している。また、送信側ＰＣ１−１において、点線の四角は、ＴＣＰウインドウのデータセグメントを示しており、実線の四角は、実際に送信されるデータセグメントを示している。
【００５９】
図中左側において、送信側のＰＣ１−１は、ＴＣＰウインドウの値が「４」であるので、４つのデータセグメントＤ１乃至Ｄ４をＴＣＰウインドウとして設定し、ＴＣＰウインドウ内のデータセグメントを、ネットワーク３を介して、受信側のＰＣ１−２に送信する。このとき、データセグメントＤ４は、輻輳Ｅが生じているネットワーク３上で欠損する。したがって、受信側のＰＣ１−２は、ネットワーク３を介して、データセグメントＤ１乃至Ｄ３だけを受信する。
【００６０】
そこで、受信側のＰＣ１−２は、データセグメントＤ１乃至Ｄ３を受信したことを通知するＡＣＫセグメントＡ１乃至Ａ３を、ネットワーク３を介して、送信側のＰＣ１−１に送信する。しかしながら、ネットワーク３上の輻輳Ｅにより、ＡＣＫセグメントＡ１乃至Ａ３は、ネットワーク３上で欠損する。
【００６１】
したがって、いまの場合、送信側のＰＣ１−１は、データセグメントＤ１乃至Ｄ４に対応するＡＣＫセグメントを、１つも受信することができない。送信側のＰＣ１−１は、データセグメントＤ１乃至Ｄ４を送信したとき、再送タイマを起動する。送信側のＰＣ１−１は、再送タイマにより計時動作を行い、所定の時間（再送タイマ動作時間）が経過しても、データセグメントＤ１乃至Ｄ４に対応するＡＣＫセグメントを受信しない場合、再送タイマをタイムアウトし、ＴＣＰウインドウの値を１に収縮する。
【００６２】
このとき、従来のＲｅｎｏ方式であれば、図９に示されるように、送信側のＰＣ１−１は、前回送信されたデータセグメントのうち、シーケンス番号の最小のデータセグメントであるデータセグメントＤ１を、ＴＣＰウインドウとして設定し、ＴＣＰウインドウ内のデータセグメントＤ１を再送セグメントとして送信する。データセグメントＤ１は、再送タイマがタイムアウトした時点のＴＣＰウインドウ内のデータセグメントＤ１乃至Ｄ４のうち、シーケンス番号が最小のデータセグメントである。しかしながら、データセグメントＤ１は、受信側のＰＣ１−２により既に受信されているデータセグメントであるため、受信側のＰＣ１−２により破棄されてしまう。その後、受信側のＰＣ１−２は、データセグメントＤ１に対応するＡＣＫセグメントＡ１をネットワーク３を介して送信側のＰＣ１−１に送信する。
【００６３】
ＡＣＫセグメントは、シーケンス番号が割り振られたデータセグメントがどこまで届いたのかを確認し、届いていないシーケンス番号の最小のデータセグメントを要求する機能を有する。したがって、ＡＣＫセグメントＡ１は、受信側のＰＣにおいて受信されているデータセグメントＤ３の次のシーケンス番号のデータセグメントであるデータセグメントＤ４を要求する。ＡＣＫセグメントＡ１を受信した送信側のＰＣ１−１は、再送タイマを停止し、ＴＣＰウインドウを１つ拡張させて、ＴＣＰウインドウの値を「２」とし、要求されたデータセグメントＤ４とその次のデータセグメントＤ５を、ＴＣＰウインドウとして設定し、ＴＣＰウインドウ内のデータセグメントＤ４およびＤ５を、ネットワーク３を介して受信側のＰＣ１−２に送信する。
【００６４】
一方、図８のＬＥＡＰ方式においては、送信側のＰＣ１−１は、ＴＣＰウインドウ内のデータセグメントＤ１（再送セグメント）ではなく、前回送信したデータセグメント（再送タイマがタイムアウトした時点のＴＣＰウインドウ内のデータセグメント）Ｄ１乃至Ｄ４の次のデータセグメントＤ５を受信側のＰＣ１−２に送信する。すなわち、いまの場合、ＴＣＰウインドウは、データセグメントＤ１が設定されており、データセグメントＤ５は、ＴＣＰウインドウ内にはないため、送信側のＰＣ１−１は、データセグメントＤ５を飛躍セグメントとしてネットワーク３を介して、受信側のＰＣ１−２に送信する。なお、このとき、送信側のＰＣ１−１は、ＴＣＢ記憶部３３のＬｅａｐ＿ｓｅｑｎｏ変数に、飛躍セグメントのシーケンス番号を格納し、飛躍セグメントを送信中であるということを示すために、ＴＣＢ記憶部３３のＬｅａｐ＿ｆｌｇ変数をオン状態に設定する。
【００６５】
受信側のＰＣ１−２は、ネットワーク３を介してデータセグメントＤ５を受信し、データセグメントＤ５に対応するＡＣＫセグメントＡ５を、ネットワーク３を介して送信側のＰＣに送信する。このＡＣＫセグメントＡ５は、受信側のＰＣ１−２において受信されていない最小のシーケンス番号のデータセグメントであるデータセグメントＤ４を要求する。
【００６６】
これに対応して、送信側のＰＣ１−１は、ＡＣＫセグメントＡ５を受信すると、再送タイマを停止させる。そして、送信側のＰＣ１−１は、ＴＣＢ記憶部３３のＬｅａｐ＿ｆｌｇ変数をオフ状態に設定し、ＴＣＰウインドウを１つ拡張させて、ＴＣＰウインドウの値を「２」とし、要求されたデータセグメントＤ４とその次のデータセグメントＤ５を、ＴＣＰウインドウとして設定する。しかしながら、データセグメントＤ４に続くデータセグメントＤ５は、飛躍セグメントとして、すでに受信側のＰＣ１−２に送信され、受信されている。したがって、送信側のＰＣ１−１は、ＴＣＢ記憶部３３のＬｅａｐ＿ｓｅｑｎｏ変数のシーケンス番号に基づいて、ＴＣＰウインドウ内のセグメントであっても、飛躍セグメントであるデータセグメントＤ５は送信せず、ＴＣＰウインドウ内のデータセグメントＤ４と、飛躍セグメントの次のデータセグメントＤ６を、ネットワーク３を介して、受信側のＰＣ１−２に送信する。
【００６７】
以上により、送信側のＰＣ１−１においては、重複したデータセグメントＤ１を送信することが抑制される。これにより、図８のＬＥＡＰ方式のデータセグメント再送処理においては、図９の従来のＲｅｎｏ方式のデータセグメント再送処理よりも１つ先のデータセグメントＤ６が送信されるので、効率的にデータの送受信処理が実行される。
【００６８】
次に、図１０乃至図１２のフローチャートを参照して、ネットワーク３を介してＰＣ１−２へデータを送信するＰＣ１−１のデータ送信処理を説明する。
【００６９】
データ制御部３１は、ユーザの操作により、入力部１６を介して入力される指示に基づいて、記憶部１９に記録されているデータを一旦読み込み、読み込んだデータを送信バッファ３４に書き込む。
【００７０】
ＴＣＰ制御部３２は、ステップＳ１において、送信バッファ３４を監視しており、送信バッファ３４に送信する送信データセグメントがあるか否かを判断し、送信バッファ３４に送信データセグメントがあると判断した場合、ＴＣＰ制御部３２は、送信バッファ３４に書き込まれたデータを、ＴＣＰセグメントの大きさに区切り、ＴＣＰウインドウの値の数のデータセグメントを、ＴＣＰウインドウとして設定し、ステップＳ２に進む。
【００７１】
ステップＳ２において、ＴＣＰ制御部３２は、送信データセグメントがＴＣＰウインドウ内にあるか否かを判断する。このとき、データセグメントの初めての送信の場合、または、前回のＴＣＰウインドウとして設定したデータセグメントに対応するＡＣＫセグメントが受信された場合、送信データセグメントは、ＴＣＰウインドウとして設定されるため、送信データセグメントがＴＣＰウインドウ内にあると判断される。一方、前回のＴＣＰウインドウとして設定したデータセグメントが送信され、そのデータセグメントに対応するＡＣＫセグメントが受信されていない場合、また、ＴＣＰウインドウは、前回の送信されたデータセグメントに設定されているため、送信されるデータセグメントは、ＴＣＰウインドウ内にないと判断される。
【００７２】
ステップＳ２において、送信データセグメントがＴＣＰウインドウ内にはないと判断された場合、ステップＳ３に進み、ＴＣＰ制御部３２は、受信部３６が、ＰＣ１−２から、前回送信されたデータセグメントに対応するＡＣＫセグメントを受信したか否かを判断し、前回送信されたデータセグメントに対応するＡＣＫセグメントを受信していないと判断した場合、ステップＳ４に進む。ＴＣＰ制御部３２は、前回のデータセグメントを送信してから再送タイマを起動させ、計時動作を行っている。ステップＳ４において、ＴＣＰ制御部３２は、再送タイマにより計時動作を行い、前回のデータセグメントを送信してから所定の時間が経過したか否かを判断する。ステップＳ４において、前回のデータセグメントを送信してから所定の時間が経過していないと判断された場合、処理は、ステップＳ３に戻り、それ以降の処理を繰り返す。
【００７３】
ステップＳ３において、前回のデータセグメントに対応するＡＣＫセグメントを受信したと判断された場合、ＴＣＰ制御部３２は、再送タイマを停止し、ステップＳ５において、ＴＣＢ記憶部３３のｌｅａｐ＿ｆｌｇがオン状態であるか否かを判断する。ＴＣＰ制御部３２は、ステップＳ５において、ＴＣＢ記憶部３３のｌｅａｐ＿ｆｌｇがオン状態であると判断した場合、ステップＳ６に進み、ＴＣＢ記憶部３３のｌｅａｐ＿ｆｌｇをオフ状態に設定し、ステップＳ７に進む。ステップＳ５において、ＴＣＢ記憶部３３のｌｅａｐ＿ｆｌｇがオン状態ではないと判断された場合、ＴＣＰ制御部３２は、ステップＳ６をスキップし、ステップＳ７に進む。ステップＳ７において、ＴＣＰ制御部３２は、ＴＣＰウインドウの値を拡張し、ステップＳ３において受信されたＡＣＫセグメントが要求するデータセグメントから、ＴＣＰウインドウの値の数のデータセグメントを、ＴＣＰウインドウとして設定し、ステップＳ２に戻り、それ以降の処理を繰り返す。
【００７４】
ステップＳ２において、送信データセグメントがＴＣＰウインドウ内にあると判断された場合、処理は、図１１のステップＳ８に進み、ＴＣＰ制御部３２は、ＴＣＢ記憶部３３のｌｅａｐ＿ｓｅｑ変数の飛躍セグメントのシーケンス番号に基づいて、送信する送信データセグメントが飛躍セグメントであるか否かを判断する。ステップＳ８において、送信データセグメントが飛躍セグメントであると判断された場合（例えば、図８におけるデータセグメントＤ５）、送信データセグメントが飛躍セグメントとしてすでにＰＣ１−２に送信されていることになるので、ステップＳ９において、ＴＣＰ制御部３２は、ＴＣＰウインドウ内の送信データセグメントは送信せず、ＴＣＰウインドウ内の他のデータセグメント（ある場合）と、送信データセグメントの次のデータセグメント（例えば、図８におけるデータセグメントＤ６）を、ネットワーク３を介して、ＰＣ１−２に送信し、図１０のステップＳ１に戻り、それ以降の処理を繰り返す。
【００７５】
ステップＳ８において、送信データセグメントが飛躍セグメントではないと判断された場合（例えば、図８のデータセグメントＤ４）、ステップＳ９において、ＴＣＰ制御部３２は、送信データセグメントを、ネットワーク３を介して、ＰＣ１−２に送信し、図１０のステップＳ１に戻り、それ以降の処理を繰り返す。
【００７６】
一方、ＴＣＰ制御部３２は、図１０のステップＳ４において、前回のデータセグメントを送信してから所定の時間が経過したと判断した場合、再送タイマをタイムアウトし、図１２のステップＳ１１に進み、ＴＣＢ記憶部３３のｌｅａｐ＿ｆｌｇがオン状態であるか否かを判断する。ステップＳ１１において、ＴＣＢ記憶部３３のｌｅａｐ＿ｆｌｇがオン状態であると判断された場合、ＴＣＰ制御部３２は、ステップＳ１２に進み、ＴＣＢ記憶部３３のｌｅａｐ＿ｓｅｑ変数の飛躍セグメントのシーケンス番号に基づいて、飛躍セグメントを送信し、図１０のステップＳ１に戻り、それ以降の処理を繰り返す。ここで、ＴＣＢ記憶部３３のｌｅａｐ＿ｆｌｇがオン状態であるということは、すでに飛躍セグメントがＰＣ１−２に送信されているが、送信された飛躍セグメントに対応するＡＣＫセグメントがＰＣ１−２から受信されていないということである。したがって、ステップＳ１２において、飛躍セグメントは、ＰＣ１−２に再送されていることになる。
【００７７】
このようにして、ＰＣ１−１は、飛躍セグメントに対応するＡＣＫセグメントが受信されるまで飛躍セグメントをＰＣ１−２に再送し続ける。なお、従来のＴＣＰのＲｅｎｏ方式においては、同一データセグメントを１３回送信してもＡＣＫセグメントが受信されない場合、そのデータセグメントは、コネクションを諦めて破棄されるようになっている。ＬＥＡＰ方式の場合、飛躍セグメントの１回目の送信が、従来のデータセグメントの１回目の再送（２回目の送信）である。そこで、従来のＴＣＰとの整合性を保つため、飛躍セグメントの送信が１２回目になってもＡＣＫセグメントが受信されない場合、飛躍セグメントは、従来のＴＣＰと同様にコネクションを諦めて破棄される。また、上述したように、飛躍セグメントに対応するＡＣＫが欠損する場合もあるので、飛躍セグメントを複数保持するようにしてもよい。
【００７８】
なお、実際には、ＰＣ１−１は、受信したＡＣＫセグメントが飛躍セグメントに対応するものであるか否かは判断できないので、以前に送信したデータセグメントに対応するＡＣＫセグメントが遅延して到着し、ｌｅａｐ＿ｆｌｇをオフ状態にしてしまう場合もある。しかしながら、再送タイマのタイムアウトの値（再送タイマ動作時間）は、ネットワークの遅延を基準としてその数倍の時間が設定されるため、このようなＡＣＫセグメントの遅延が起こり、同時に飛躍セグメントが欠損している状況はまれであるといえる。
【００７９】
ステップＳ１１において、ＴＣＢ記憶部３３のｌｅａｐ＿ｆｌｇがオフ状態である（ネットワーク３上に飛躍セグメントは存在しない）と判断された場合、ＴＣＰ制御部３２は、ステップＳ１３に進み、受信側のＰＣ１−２において受信されていない最小のシーケンス番号のデータセグメントである、再送セグメント（例えば、図８のデータセグメントＤ１）に対する重複ＡＣＫを受信したか否かを判断し、再送セグメントに対する重複ＡＣＫを受信したと判断した場合、ステップＳ１６に進み、ネットワーク３を介してＰＣ１−２に、再送セグメントを送信し、図１０のステップＳ１に戻り、それ以降の処理を繰り返す。
【００８０】
このステップＳ１３の処理について、図１３を参照して説明する。図１３の例の場合、送信側ＰＣ１−１は、ＴＣＰウインドウの値が「４」であるので、４つのデータセグメントＤ１乃至Ｄ４をＴＣＰウインドウとして設定し、ＴＣＰウインドウ内のデータセグメントを、ネットワーク３を介して、受信側のＰＣ１−２に送信する。しかしながら、データセグメントＤ１は、ネットワーク３上で欠損してしまう。この場合、受信側ＰＣ１−２は、データセグメントＤ２乃至Ｄ４を受信し、各データセグメントに対応するＡＣＫセグメントＡ２乃至Ａ４を、ネットワーク３を介して、送信側のＰＣ１−１に送信する。ＡＣＫセグメントＡ２乃至Ａ４は、受信側のＰＣ１−２において受信されていない最小のシーケンス番号のデータセグメントであるデータセグメントＤ１を要求する。
【００８１】
この場合、ＡＣＫセグメントＡ２と同一のデータセグメントＤ１（再送セグメント）を要求しているＡＣＫセグメントＡ３およびＡ４は、再送セグメントに対する重複ＡＣＫとされる。このように、送信側のＰＣ１−１において、重複ＡＣＫが受信された場合、送信側のＰＣ１−２に、再送セグメントであるデータセグメントＤ１が受信されていないことが可能性が高いといえる（なお、データセグメントＤ１だけが遅延してデータセグメントＤ２、Ｄ３またはＤ４の後に到着することもあるが、非常に低い確率である）。したがって、再送セグメントに対する重複ＡＣＫが受信されている場合は、再送セグメントであるデータセグメントＤ１が送信側のＰＣ１−２に受信され、それに対応するＡＣＫセグメントがネットワーク３上で損失された可能性がないに等しいので、この場合には、飛躍セグメントではなく、ＴＣＰ制御部３２は、重複ＡＣＫが要求する再送セグメントを送信するように制御する。
【００８２】
ステップＳ１３において、再送セグメントに対する重複ＡＣＫを受信していないと判断された場合、ＴＣＰ制御部３２は、ステップＳ１４に進み、ＴＣＰのヘッダのフラグ領域に基づいて、再送セグメントに特殊ビットが設定されているか否かを判断する。ステップＳ１４において、再送セグメントに特殊ビットが設定されていると判断された場合、ステップＳ１６に進み、ネットワーク３を介してＰＣ１−２に、再送セグメントを送信し、図１０のステップＳ１に戻り、それ以降の処理を繰り返す。
【００８３】
このステップＳ１４の処理について具体的に説明すると、ＴＣＰのデータセグメントには、順序を入れ換えて送信しても意味があるデータセグメントと、順序を入れ換えて送信してしまうと、そのデータセグメントが持つ意味がなくなってしまうデータセグメントが存在する。後者のデータセグメントとしては、例えば、コネクション（データ転送）開始時に送信されるＳＹＮセグメントがある。ＳＹＮセグメントがネットワーク３上で欠損し、ＰＣ１−２に受信されていない場合に、飛躍セグメントとして新しいデータセグメントが受信側のＰＣ１−２に送信されたとしても、受信側のＰＣ１−２は受け取ることができない。したがって、このような場合には、ＴＣＰ制御部３２は、飛躍セグメントではなく、再送セグメント（ＳＹＮセグメント）を送信するように制御する。
【００８４】
このようなセグメントは、ＳＹＮセグメントの他にコネクション終了時に送信されるＦＩＮセグメント、コネクション強制終了時に送信されるＲＳＴセグメント、および、一連のセグメントをデータ制御部３１に渡すためのトリガとなるＰＵＳＨセグメントがある。
【００８５】
ステップＳ１４において、再送セグメントに特殊ビットが設定されていないと判断された場合、ＴＣＰ制御部３２は、ステップＳ１５に進み、直前に受信したＡＣＫセグメントに基づいて、受信側のＰＣ１−２の受信バッファ３７が送信データセグメントを受信可能であるか否かを判断する。ステップＳ１５において、受信側のＰＣ１−２の受信バッファ３７が、送信データセグメントを受信可能ではないと判断された場合、ステップＳ１６に進み、ネットワーク３を介してＰＣ１−２に、再送セグメントを送信し、図１０のステップＳ１に戻り、それ以降の処理を繰り返す。
【００８６】
このステップＳ１４の処理について具体的に説明する。ＴＣＰウインドウの値は、送信側ＰＣ１−１のＴＣＰ制御部３２が保持する輻輳ウインドウの値と、受信側ＰＣ１−２からＡＣＫセグメントにより告知される広告ウインドウの値の小さい方が設定される。広告ウインドウの値は、受信側のＰＣ１−２の受信バッファ３７の空き容量であるため、広告ウインドウの値を越えたデータセグメントはバッファされずに破棄される。極度の輻輳時には、データセグメントの欠損により輻輳ウインドウが収縮しているため、ＴＣＰウインドウは、受信側からの広告ウインドウではなく輻輳ウインドウで制限されることが多い。しかしながら、輻輳時以外にも、ＡＣＫセグメントの欠損は発生することがあるため、飛躍セグメントが広告ウインドウ（受信バッファ３７）の大きさを越えている場合、ＴＣＰ制御部３２は、飛躍セグメントではなく、再送セグメントを送信するように制御する。
【００８７】
ステップＳ１５において、受信側のＰＣ１−２の受信バッファ３７が、送信データセグメントを受信可能であると判断された場合、ＴＣＰ制御部３２は、ステップＳ１７において、ＴＣＢ記憶部３３のｌｅａｐ＿ｆｌｇをオン状態に設定し、ステップＳ１８に進む。ＴＣＰ制御部３２は、ステップＳ１８において、送信データセグメントのシーケンス番号をｌｅａｐ＿ｓｅｑ変数に保持し、送信データセグメントを飛躍セグメントとし、ステップＳ１９に進む。ＴＣＰ制御部３２は、ステップＳ１９において、送信部３５を制御し、飛躍セグメントを、ネットワーク３を介して、受信側のＰＣ１−２に送信し、図１０のステップＳ１に戻り、以降の処理を繰り返す。
【００８８】
図１０のステップＳ１において、ＴＣＰ制御部３２は、送信データセグメントが送信バッファ３４にないと判断した場合、データ送信処理を終了させる。
【００８９】
次に、図１４および図１５を参照して、図５の情報処理システムにおいて実行されたデータ転送のシミュレーション結果を説明する。このシミュレーションは、３台のＰＣ１−１乃至１−３が１台のルータ２を経由して接続しているネットワーク３のネットワーク環境において、１００個のデータを送出するＦＴＰのコネクション（データ転送）を指数分布の間隔に従ってランダムに発生させ、１秒間に発生するコネクションの数の平均値を、０．２５コネクション刻みで、１コネクションから３．５コネクションまで変更させて、３０００秒間実行されたものである。なお、このシミュレーションにおいては、図８を参照して上述したＬＥＡＰ方式および図９を参照して上述した従来のＴＣＰの方式としてＲｅｎｏ方式が用いられている。
【００９０】
図１４は、１コネクションにおける平均送受信パケット数を示すグラフである。図１４の例においては、横軸は、１秒間に発生するコネクションの数の平均値（トラフィック負荷度）を示しており、トラフィックの負荷度は、右に行くに従って高くなる。縦軸は、ＬＥＡＰ方式、および従来のＲｅｎｏ方式を用いた場合の送信パケット数（ｓ）と受信パケット数（ｒ）を示しており、送受信パケット数は、上に行くに従って多くなる。
【００９１】
図１４の例の場合、ＬＥＡＰ方式においては、トラフィック負荷度が１コネクション数／秒のとき、送信パケット数は、１００．０１３パケットであり、受信パケット数は、１００．００１パケットであり、トラフィック負荷度が１．２５コネクション数／秒のとき、送信パケット数は、１００．０７パケットであり、受信パケット数は、１００．０１７パケットである。トラフィック負荷度が１．５コネクション数／秒のとき、送信パケット数は、１００．２３パケットであり、受信パケット数は、１００．０４３パケットであり、トラフィック負荷度が１．７５コネクション数／秒のとき、送信パケット数は、１００．６６５パケットであり、受信パケット数は、１００．１２６パケットである。トラフィック負荷度が２コネクション数／秒のとき、送信パケット数は、１００．９２４パケットであり、受信パケット数は、１００．１８２パケットであり、トラフィック負荷度が２．２５コネクション数／秒のとき、送信パケット数は、１０２．００３パケットであり、受信パケット数は、１００．５０６パケットである。
【００９２】
また、トラフィック負荷度が２．５コネクション数／秒のとき、送信パケット数は、１０３．６６パケットであり、受信パケット数は、１００．８９９パケットであり、トラフィック負荷度が２．７５コネクション数／秒のとき、送信パケット数は、１０５．０９６パケットであり、受信パケット数は、１０１．３３５パケットである。また、トラフィック負荷度が３コネクション数／秒のとき、送信パケット数は、１０６．９８９パケットであり、受信パケット数は、１０１．６４６パケットであり、トラフィック負荷度が３．２５コネクション数／秒のとき、送信パケット数は、１１０．１７７パケットであり、受信パケット数は、１０１．７８３パケットであり、トラフィック負荷度が３．５コネクション数／秒のとき、送信パケット数は、１１３．９９パケットであり、受信パケット数は、１０１．５９パケットである。
【００９３】
一方、従来のＲｅｎｏ方式においては、トラフィック負荷度が１コネクション数／秒のとき、送信パケット数は、１００．００１パケットであり、受信パケット数は、１００．００１パケットであり、トラフィック負荷度が１．２５コネクション数／秒のとき、送信パケット数は、１００．０７３パケットであり、受信パケット数は、１００．０２２パケットである。トラフィック負荷度が１．５コネクション数／秒のとき、送信パケット数は、１００．２１３パケットであり、受信パケット数は、１００．０４５パケットであり、トラフィック負荷度が１．７５コネクション数／秒のとき、送信パケット数は、１００．６８９パケットであり、受信パケット数は、１００．１６８パケットである。トラフィック負荷度が２コネクション数／秒のとき、送信パケット数は、１０１．４８５パケットであり、受信パケット数は、１００．４４８パケットであり、トラフィック負荷度が２．２５コネクション数／秒のとき、送信パケット数は、１０２．７２１パケットであり、受信パケット数は、１００．８１４パケットである。
【００９４】
また、トラフィック負荷度が２．５コネクション数／秒のとき、送信パケット数は、１０６．６９６パケットであり、受信パケット数は、１０３．１４７パケットであり、トラフィック負荷度が２．７５コネクション数／秒のとき、送信パケット数は、１２８．８５３パケットであり、受信パケット数は、１０９．０６１パケットである。また、トラフィック負荷度が３コネクション数／秒のとき、送信パケット数は、１８５．７２７パケットであり、受信パケット数は、１２０．３９４パケットであり、トラフィック負荷度が３．２５コネクション数／秒のとき、送信パケット数は、１９４．２９８パケットであり、受信パケット数は、１２３．３７パケットであり、トラフィック負荷度が３．５コネクション数／秒のとき、送信パケット数は、２０９．２６８パケットであり、受信パケット数は、１３０．０５６パケットである。
【００９５】
図１４のグラフにおいて、例えば、トラフィック負荷度が３．２５コネクション数／秒のとき、Ｒｅｎｏ方式の送信パケット数は、１９４．２９８パケットであり、ＬＥＡＰ方式の送信パケット数は、１１０．１７７パケットである。すなわち、ＬＥＡＰ方式を用いることにより、矢印Ｑ１に示されるように、およそ８０パケットの無駄な送信パケットが減少する。また、例えば、トラフィック負荷度が３．５コネクション数／秒のとき、Ｒｅｎｏ方式の受信パケット数は、１３０．０５６パケットであり、ＬＥＡＰ方式の受信パケット数は、１０１．５９パケットである。すなわち、ＬＥＡＰ方式を用いることにより、矢印Ｑ２に示されるように、およそ３０パケットの無駄な受信パケットが減少する。
【００９６】
さらに、ＬＥＡＰ方式においては、受信パケット数は、ほぼ１００パケットに近づいている。これにより、図１４においては、１コネクションが転送するセグメント数は、１００パケットであるため、ＬＥＡＰ方式においては、無駄のないデータ転送が実現されていることがわかる。なお、１００パケットちょうどにならないのは、ＳＹＮセグメントまたはＦＩＮセグメントなどの特殊セグメントが再送される場合、もしくは、飛躍セグメントのＡＣＫセグメントが欠損してしまい、到着したはずの飛躍セグメントが再送される場合があるためである。
【００９７】
また、受信パケット数が減少するということは、すなわち、送信パケット数が減少することにも関係する。したがって、コネクション全体で送信するパケット数が減少するため、ネットワーク３全体でのトラフィックの負荷度が抑制される。このため、パケット欠損率も抑制され、その結果、送信パケット数は、さらに減少する。
【００９８】
図１５は、シミュミレーション時間内に終了したデータ転送の数を示すグラフである。図１５の例においては、横軸は、１秒間に発生するコネクションの数の平均値（すなわち、トラフィック負荷度）を示しており、トラフィックの負荷は、右に行くに従って高くなる。縦軸は、ＬＥＡＰ方式および従来のＲｅｎｏ方式を用いてデータ転送が終了したコネクション数（終了コネクション数）を示しており、終了コネクション数は、上に行くに従って多くなる。
【００９９】
図１５のグラフの場合、ＬＥＡＰ方式においては、トラフィック負荷度が１コネクション数／秒のとき、２９９７コネクションが終了し、トラフィック負荷度が１．２５コネクション数／秒のとき、３６９４コネクションが終了し、トラフィック負荷度が１．５コネクション数／秒のとき、４４２５コネクションが終了している。また、トラフィック負荷度が１．７５コネクション数／秒のとき、５１２２コネクションが終了し、トラフィック負荷度が２コネクション数／秒のとき、５９１２コネクションが終了し、トラフィック負荷度が２．２５コネクション数／秒のとき、６７２５コネクションが終了している。トラフィック負荷度が２．５コネクション数／秒のとき、７３８７コネクションが終了し、トラフィック負荷度が２．７５コネクション数／秒のとき、８０７０コネクションが終了し、トラフィック負荷度が３コネクション数／秒のとき、８３４２コネクションが終了している。また、トラフィック負荷度が３．２５コネクション数／秒のとき、８３７０コネクションが終了し、トラフィック負荷度が３．５コネクション数／秒のとき、７７７２コネクションが終了している。
【０１００】
一方、従来のＲｅｎｏ方式においては、トラフィック負荷度が１コネクション数／秒のとき、２９３２コネクションが終了し、トラフィック負荷度が１．２５コネクション数／秒のとき、３６７９コネクションが終了し、トラフィック負荷度が１．５コネクション数／秒のとき、４４５３コネクションが終了している。また、トラフィック負荷度が１．７５コネクション数／秒のとき、５２１４コネクションが終了し、トラフィック負荷度が２コネクション数／秒のとき、５８４８コネクションが終了し、トラフィック負荷度が２．２５コネクション数／秒のとき、６６６７コネクションが終了している。トラフィック負荷度が２．５コネクション数／秒のとき、７４５０コネクションが終了し、トラフィック負荷度が２．７５コネクション数／秒のとき、７９２８コネクションが終了し、トラフィック負荷度が３コネクション数／秒のとき、６７０１コネクションが終了している。また、トラフィック負荷度が３．２５コネクション数／秒のとき、６０８０コネクションが終了し、トラフィック負荷度が３．５コネクション数／秒のとき、４５０８コネクションが終了している。
【０１０１】
図１５のグラフの横軸に注目すると、従来のＲｅｎｏ方式の場合、２．５コネクション数／秒までは直線的に終了コネクション数が直線的に増加している。しかしながら、トラフィック負荷度が２．７５コネクション数／秒のとき、７９２８コネクションであった終了コネクション数が、トラフィック負荷度が３コネクション数／秒のとき、６７０１コネクションに減少していることに示されるように、トラフィック負荷度が２．７５コネクション数／秒を越えたあたりから、終了コネクション数は、急激に減少している。
【０１０２】
一方、ＬＥＡＰ方式を用いた場合には、トラフィック負荷度が３．２５コネクション数／秒のとき、８３７０コネクションであった終了コネクション数が、トラフィック負荷度が３．５コネクション数／秒のとき、７７７２コネクションに減少していることに示されるように、トラフィック負荷度が３．２５コネクション数／秒を越えたあたりから、終了コネクション数は、徐々に減少している。
【０１０３】
また、図中の矢印に示されるように、トラフィック負荷度が３．５コネクション数／秒のあたりにおいては、Ｒｅｎｏ方式では、４５０８コネクションしか終了していないのに対して、ＬＥＡＰ方式では、Ｒｅｎｏ方式の倍近くの７７７２コネクションが終了している。以上のように、ＬＥＡＰ方式を用いることにより、図５のネットワーク３全体の資源利用効率も大幅に上昇させることができる。
【０１０４】
以上のように、ＬＥＡＰ方式を用いることにより、輻輳時のネットワーク状態において、重複したセグメントの送信を回避し、無駄のない、効率的なデータ転送をすることができる。
【０１０５】
また、ＬＥＡＰ方式においては、送信側の機能を追加しただけであり、実装が容易にできる。さらに、従来のＴＣＰのＲｅｎｏ方式などとも整合性をとるようにしたので、輻輳していない通常のネットワーク状態におけるＴＣＰの性能を劣化させることもない。
【０１０６】
なお、上記説明においては、ＴＣＰプロトコルを用いてデータ送信処理を実行したが、確認応答のＡＣＫを用いるものであれば、他のプロトコルを用いるようにしてもよい。
【０１０７】
上述した一連の処理は、ハードウェアにより実行させることもできるが、ソフトウェアにより実行させることもできる。一連の処理をソフトウェアにより実行させる場合には、そのソフトウェアを構成するプログラムが、専用のハードウェアに組み込まれているコンピュータ、または、各種のプログラムをインストールすることで、各種の機能を実行することが可能な、例えば汎用のパーソナルコンピュータなどに、プログラム格納媒体からインストールされる。
【０１０８】
コンピュータにインストールされ、コンピュータによって実行可能な状態とされるプログラムを格納するプログラム格納媒体は、図６に示されるように、磁気ディスク２１（フレキシブルディスクを含む）、光ディスク２２（ＣＤ−ＲＯＭ（Ｃｏｍｐａｃｔ Ｄｉｓｃ−Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、ＤＶＤ（Ｄｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｃ）を含む）、光磁気ディスク２３（ＭＤ（Ｍｉｎｉ−Ｄｉｓｃ）（商標）を含む）、もしくは半導体メモリ２４などよりなるパッケージメディア、または、プログラムが一時的もしくは永続的に格納されるＲＯＭ１２や、記憶部１８などにより構成される。
【０１０９】
なお、本明細書において、記録媒体に記録されるプログラムを記述するステップは、記載された順序に従って時系列的に行われる処理はもちろん、必ずしも時系列的に処理されなくとも、並列的あるいは個別に実行される処理をも含むものである。
【０１１０】
なお、本明細書において、システムとは、複数の装置により構成される装置全体を表すものである。
【０１１１】
【発明の効果】
以上の如く、本発明によれば、通常時のデータ転送の性能を劣化させることなく、重度の輻輳時に、効率的にデータを送信することができる。
【図面の簡単な説明】
【図１】従来のデータ再送処理について説明する図である。
【図２】従来のデータ再送処理の他の例について説明する図である。
【図３】従来のＴＣＰの方式において、シミュミレーション時間内に終了したコネクションの数を示すグラフである。
【図４】従来のＴＣＰの方式において、１コネクションにおける平均送受信パケット数を示すグラフである。
【図５】本発明を適用した情報処理システムの構成例を示す図である。
【図６】図５のパーソナルコンピュータの構成例を示すブロック図である。
【図７】図５のパーソナルコンピュータの機能構成例を示すブロック図である。
【図８】図５の情報処理システムにおけるＬＥＡＰ方式のデータ再送処理について説明する図である。
【図９】図８のＬＥＡＰ方式と比較するための従来のＲｅｎｏ方式のデータ再送処理について説明する図である。
【図１０】図５のパーソナルコンピュータのデータ送信処理を説明するフローチャートである。
【図１１】図５のパーソナルコンピュータのデータ送信処理を説明するフローチャートである。
【図１２】図５のパーソナルコンピュータのデータ送信処理を説明するフローチャートである。
【図１３】再送セグメントの重複ＡＣＫを説明する図である。
【図１４】図８のＬＥＡＰ方式と従来のＲｅｎｏ方式の１コネクションにおける平均送受信パケット数を示すグラフである。
【図１５】図８のＬＥＡＰ方式と従来のＲｅｎｏ方式のシミュミレーション時間内に終了したコネクションの数を示すグラフである。
【符号の説明】
１−１乃至１−３ パーソナルコンピュータ，２ ルータ，３ ネットワーク，１１ ＣＰＵ，３１ データ制御部，３２ ＴＣＰ制御部，３３ ＴＣＢ記憶部，３４ 送信バッファ，３５ 送信部，３６ 受信部，３７ 受信バッファ
Claims (9)
- ネットワークを介して、所定のプロトコルでデータを他の情報処理装置に送信する送信手段と、
前記送信手段により前記データが送信されてから所定の時間内に、前記他の情報処理装置から前記データに対応するＡＣＫ（ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ）を受信したか否かを判断する受信判断手段と
を備え、
前記受信判断手段により前記他の情報処理装置から前記データに対応するＡＣＫが受信されていないと判断された場合、前記送信手段は、前回送信された前記データに続く次のデータを送信する
ことを特徴とする情報処理装置。 - 前記所定のプロトコルは、ＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）である
ことを特徴とする請求項１に記載の情報処理装置。 - 前記受信判断手段により前記データに対応するＡＣＫが受信されていないと判断された場合に、前記送信手段により送信された前記次のデータのシーケンス番号を記憶する記憶手段と、
前記受信判断手段により前記データに対応するＡＣＫが受信されていないと判断され、前記送信手段により前記次のデータが送信された場合に、そのことを示すフラグを保持する保持手段と
をさらに備えることを特徴とする請求項１に記載の情報処理装置。 - 前記保持手段により前記フラグが保持されているか否かを判断するフラグ判断手段をさらに備え、
前記受信判断手段により前記データに対応するＡＣＫが受信されていないと判断され、かつ、前記フラグ判断手段により前記フラグが保持されていると判断された場合、前記送信手段は、前記受信判断手段により前記ＡＣＫが受信されていないと判断された前記データを再度送信する
ことを特徴とする請求項３に記載の情報処理装置。 - 前記受信判断手段により前記データに対応するＡＣＫが受信されたと判断され、かつ、前記フラグ判断手段により前記フラグが保持されていると判断された場合、前記保持手段は、前記フラグの保持を解除する
ことを特徴とする請求項４に記載の情報処理装置。 - 前記受信判断手段により前記データに対応するＡＣＫが受信されたと判断された場合、次に送信する送信データのシーケンス番号が、前記記憶手段に記憶されている前記シーケンス番号と同じであるか否かを判断するデータ判断手段をさらに備え、
前記データ判断手段により前記送信データのシーケンス番号が、前記記憶手段に記憶されている前記シーケンス番号と同じであると判断された場合、前記送信手段は、前記送信データの送信をスキップし、前記送信データの次のデータを送信する
ことを特徴とする請求項３に記載の情報処理装置。 - ネットワークを介して、所定のプロトコルでデータを他の情報処理装置に送信する送信ステップと、
前記送信ステップの処理により前記データが送信されてから所定の時間内に、前記他の情報処理装置から前記データに対応するＡＣＫを受信したか否かを判断する受信判断ステップと
を含み、
前記受信判断ステップの処理により前記他の情報処理装置から前記データに対応するＡＣＫが受信されていないと判断された場合、前記送信ステップの処理は、前回送信された前記データに続く次のデータを送信する
ことを特徴とする情報処理方法。 - ネットワークを介して、所定のプロトコルでデータを他の情報処理装置に送信する送信ステップと、
前記送信ステップの処理により前記データが送信されてから所定の時間内に、前記他の情報処理装置から前記データに対応するＡＣＫを受信したか否かを判断する受信判断ステップと
を含み、
前記受信判断ステップの処理により前記他の情報処理装置から前記データに対応するＡＣＫが受信されていないと判断された場合、前記送信ステップの処理は、前回送信された前記データに続く次のデータを送信する
ことを特徴とするコンピュータが読み取り可能なプログラムが記録されている記録媒体。 - ネットワークを介して、所定のプロトコルでデータを他の情報処理装置に送信する送信ステップと、
前記送信ステップの処理により前記データが送信されてから所定の時間内に、前記他の情報処理装置から前記データに対応するＡＣＫを受信したか否かを判断する受信判断ステップと
を含む処理をコンピュータに実行させ、
前記受信判断ステップの処理により前記他の情報処理装置から前記データに対応するＡＣＫが受信されていないと判断された場合、前記送信ステップの処理は、前回送信された前記データに続く次のデータを送信する
ことを特徴とするプログラム。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2003060043A JP2004274237A (ja) | 2003-03-06 | 2003-03-06 | 情報処理装置および方法、記録媒体、並びにプログラム |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2003060043A JP2004274237A (ja) | 2003-03-06 | 2003-03-06 | 情報処理装置および方法、記録媒体、並びにプログラム |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| JP2004274237A true JP2004274237A (ja) | 2004-09-30 |
Family
ID=33122707
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2003060043A Withdrawn JP2004274237A (ja) | 2003-03-06 | 2003-03-06 | 情報処理装置および方法、記録媒体、並びにプログラム |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP2004274237A (ja) |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2009194565A (ja) * | 2008-02-13 | 2009-08-27 | Fujitsu Ltd | データ送信装置、コンピュータプログラム及びデータ送信方法 |
| JP2013015643A (ja) * | 2011-07-01 | 2013-01-24 | Yamaha Corp | 演奏データ送信装置及び演奏データ受信装置 |
-
2003
- 2003-03-06 JP JP2003060043A patent/JP2004274237A/ja not_active Withdrawn
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2009194565A (ja) * | 2008-02-13 | 2009-08-27 | Fujitsu Ltd | データ送信装置、コンピュータプログラム及びデータ送信方法 |
| JP2013015643A (ja) * | 2011-07-01 | 2013-01-24 | Yamaha Corp | 演奏データ送信装置及び演奏データ受信装置 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US7720063B2 (en) | Method apparatus and system for accelerated communication | |
| JP4504977B2 (ja) | オフロードユニットを使用したｔｃｐ接続のためのデータ処理 | |
| US8259728B2 (en) | Method and system for a fast drop recovery for a TCP connection | |
| JP4283589B2 (ja) | 通信装置、通信制御方法及びプログラム | |
| US8174975B2 (en) | Network adapter with TCP support | |
| JP4511174B2 (ja) | Ｔｃｐ／ｉｐを使用した高速度データ送信システムおよび方法 | |
| JP4886685B2 (ja) | ネットワーク・プロトコル処理のオフロードにおいてメモリ管理をサポートする装置および方法 | |
| JP4791322B2 (ja) | 帯域幅保証を伴う適応性帯域幅制御のための方法及び装置 | |
| JP5020076B2 (ja) | 低頻度ａｃｋのシステムに適した高性能ｔｃｐ | |
| WO2013012604A1 (en) | System and method for reliable virtual bi-directional data stream communications with single socket point-to-multipoint capability | |
| EP1701506B1 (en) | Method and system for transmission control protocol (TCP) traffic smoothing | |
| JP4128198B2 (ja) | 帯域制御装置 | |
| EP1889421B1 (en) | Multi-stream acknowledgement scheduling | |
| US20120054362A1 (en) | Mechanism for autotuning mass data transfer from a sender to a receiver over parallel connections | |
| JP2006236391A (ja) | パケットベースの通信ネットワークにおけるメッセージ受信の肯定応答システム及び方法 | |
| US20070291782A1 (en) | Acknowledgement filtering | |
| WO2017097201A1 (zh) | 一种数据传输方法、发送装置及接收装置 | |
| JP2007013449A (ja) | シェーパー制御方法、データ通信システム、ネットワークインタフェース装置及びネットワーク中継装置 | |
| US20050038899A1 (en) | Method, system and article for client application control of network transmission loss tolerance | |
| JP2007110680A (ja) | 通信装置、通信プログラム、通信制御方法および記録媒体 | |
| JP2004274237A (ja) | 情報処理装置および方法、記録媒体、並びにプログラム | |
| WO2006058255A2 (en) | Methods and apparatus for optimizing a tcp session for a wireless network | |
| EP1744495A1 (en) | Round trip time estimation | |
| JP7427464B2 (ja) | 通信装置、通信方法およびプログラム | |
| WO2006058211A2 (en) | Methods and apparatus for optimizing a tcp session for a wireless network |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A300 | Application deemed to be withdrawn because no request for examination was validly filed |
Free format text: JAPANESE INTERMEDIATE CODE: A300 Effective date: 20060509 |