JP4777996B2 - 通信装置、通信方法、プログラムおよび集積回路 - Google Patents

通信装置、通信方法、プログラムおよび集積回路 Download PDF

Info

Publication number
JP4777996B2
JP4777996B2 JP2007539872A JP2007539872A JP4777996B2 JP 4777996 B2 JP4777996 B2 JP 4777996B2 JP 2007539872 A JP2007539872 A JP 2007539872A JP 2007539872 A JP2007539872 A JP 2007539872A JP 4777996 B2 JP4777996 B2 JP 4777996B2
Authority
JP
Japan
Prior art keywords
packet
data
unit
reception
ack
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
JP2007539872A
Other languages
English (en)
Other versions
JPWO2007043373A1 (ja
Inventor
洋 倉田
芳紀 岡崎
敦宏 辻
景一 高垣
陽介 松下
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Panasonic Corp
Panasonic Holdings Corp
Original Assignee
Panasonic Corp
Matsushita Electric Industrial Co Ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Panasonic Corp, Matsushita Electric Industrial Co Ltd filed Critical Panasonic Corp
Priority to JP2007539872A priority Critical patent/JP4777996B2/ja
Publication of JPWO2007043373A1 publication Critical patent/JPWO2007043373A1/ja
Application granted granted Critical
Publication of JP4777996B2 publication Critical patent/JP4777996B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
    • H04L1/1829—Arrangements specially adapted for the receiver end
    • H04L1/1832—Details of sliding window management
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/19—Flow control; Congestion control at layers above the network layer
    • H04L47/193—Flow control; Congestion control at layers above the network layer at the transport layer, e.g. TCP related
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/26—Flow control; Congestion control using explicit feedback to the source, e.g. choke packets
    • H04L47/263—Rate modification at the source after receiving feedback
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/28—Flow control; Congestion control in relation to timing considerations
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/163—In-band adaptation of TCP data exchange; In-band control procedures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
    • H04L1/1867—Arrangements specially adapted for the transmitter end
    • H04L1/1887—Scheduling and prioritising arrangements

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Communication Control (AREA)

Description

本発明は、通信装置に関し、特に、インターネットプロトコル（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ：以下ＩＰ）ネットワークを介してトランスミッションコントロールプロトコル（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ：以下ＴＣＰ）を用いたデータ転送を行う通信装置に関する。
図１は、ＴＣＰにおけるデータ転送の流れを示したシーケンス図である。
ＴＣＰにおけるデータ転送において、データはパケットと呼ばれる単位で送受信される。また、１パケットサイズは、予めやり取りしたパケット最大サイズ情報（Ｍａｘｉｍｕｍ Ｓｅｇｍｅｎｔ Ｓｉｚｅ：以下ＭＳＳ）を元に決定される。送信側装置が送ったパケットに対して、そのパケットが受信側装置に到達したことは、肯定応答パケット（Ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ Ｐａｃｋｅｔ：以下ＡＣＫまたはＡＣＫパケット）を受信側装置が送り、それを送信側装置が受け取ることによって確認される。なお、肯定応答パケットは確認応答パケットともいう。図１の例では、データパケットを実線で、ＡＣＫパケットを破線で示している。また、データパケットには、例えばＰ２１（Ｓｅｑ＝１０）が表記されており、シーケンス番号１０のパケットを送信していることを示している。さらに、ＡＣＫパケットには、例えばＰ１１（Ａｃｋ＝１０，Ｗｉｎ＝４）が表記されており、ＡＣＫ番号１０およびウィンドウサイズ４のパケットであることを示している。なお、説明を簡単にするためにデータパケットサイズは、１として説明する。
次に、ウィンドウサイズの説明をする。ウィンドウサイズとは、送信側装置が、ＡＣＫパケットを得ることなしに、受信側装置にデータを送り続けることが可能なデータ量を意味している。このウィンドウサイズは、一般的には、受信側装置が受信したデータを保持できる最大量の上限（以下ＲＷＩＮ＿ＭＡＸ）を示しており、ネットワークの輻輳状態などに応じて送信側装置により増減される。理想的な状態では、ネットワークの輻輳がなく、ウィンドウサイズはＲＷＩＮ＿ＭＡＸの値で安定している状態となる。
図１の例では、受信側装置は、ＡＣＫパケットＰ１１によって、ＡＣＫ番号が１０であることと、ウィンドウサイズが４であることを通知している。よって、送信側装置は、シーケンス番号１０〜１３のデータパケットＰ２１、Ｐ２２、Ｐ２３、Ｐ２４を、４つのデータパケットに対するＡＣＫパケットを待たずに送信することが可能である。
受信側装置は、受信側装置が受信したデータを一時的に保持するための受信バッファを持ち、一般に、ＲＷＩＮ＿ＭＡＸ分のデータを確保することが可能である。また、この受信バッファの空き容量は、送信側装置からのパケット受信により減少し、アプリケーションプログラム（以下、単にアプリケーションという）へ受信データを引き渡すことで増加する。さらに、受信バッファの空き容量が増加した折には、受信側装置は、ウィンドウ更新通知パケットと呼ばれるパケットを送信し、送信側装置に受信バッファの空き容量が増加したことを通知する機能を持つ。
図１の例では、データパケットＰ２１、Ｐ２２、Ｐ２３、Ｐ２４の送信後、ＡＣＫパケットＰ１２、Ｐ１３においてウィンドウサイズが減少し、最終的に０となっている。つまり、受信したデータパケットＰ２１、Ｐ２２、Ｐ２３、Ｐ２４は、受信バッファに保持されたままとなっており、まだアプリケーションへの受信データの引き渡しが行われていない状態である。その後、受信側装置は、アプリケーションに受信データの引き渡しを行うと、ウィンドウ更新通知パケットＰ１４を送信し、ウィンドウサイズが４つだけ空いたことを送信側装置に通知する。送信側装置は、ウィンドウ更新通知パケットＰ１４を受信すると、続きのデータパケットＰ２５、Ｐ２６、Ｐ２７、Ｐ２８の送信を再開する。
また、受信側装置がＡＣＫパケットＰ１１を送信する時刻と、送信側装置から送信されたデータパケットＰ２１を受信する時刻との差を応答遅延時間（Ｒｏｕｎｄ Ｔｒｉｐ Ｔｉｍｅ：以下ＲＴＴ）と呼ぶ。ＲＴＴの大きなネットワークを介して、データ転送を行う際は、送信側装置は、ウィンドウサイズ分のデータ転送を行った後、受信側からのＡＣＫもしくはウィンドウ更新通知が到着するまでの間、送信処理を停止することになる。そのため、効率の良いデータ転送ができなくなってしまう。そこで、効率の良いデータ転送を行うためには、ＲＷＩＮ＿ＭＡＸを大きくする必要がある。
さらに、ＴＣＰには、非特許文献１に記載される機能、つまり高速再送機能がある。
図２は、高速再送機能に関するパケット送受信を示すシーケンス図である。
図２に示すように、送信側装置から送信されるデータパケットのうち、データパケットＰ２８４がパケットロスし、受信側装置に到達しなかったとする。このとき、受信側装置は、パケットロスしたデータパケットＰ２８４以降のデータパケットＰ２８５、Ｐ２８６、Ｐ２８７を受信することで、データパケットＰ２８４がロスしたかもしくは、何らかの理由で、到着順序が入れ替わっていると判断できる。そのため、受信側装置は、データパケットＰ２８５を受信した時点で、データパケットＰ２８４が到着していないことを送信側装置に通知するため、即座にＡＣＫパケットＰ２７３を送信する。このＡＣＫパケットを即時確認応答という。また、このＡＣＫパケットＰ２７３は、以前に送信しているＡＣＫパケットＰ２７２と同じＡＣＫパケットであることから、重複ＡＣＫということもある。以下、重複ＡＣＫとして説明する。以降、受信側装置は、データパケットＰ２８４を受信するまで、ＡＣＫパケットＰ２７２と同様な重複ＡＣＫパケットＰ２７４、Ｐ２７５を送信する。
次に、この重複ＡＣＫパケットＰ２７３、Ｐ２７４、Ｐ２７５を受信した送信側装置は、連続して３回同じＡＣＫパケットを受信したことにより、重複ＡＣＫパケットが示すパケットをロスしたことを検知し、即座にデータパケットＰ２８８の再送を行う。この即座に再送処理を行うことを高速再送（Ｆａｓｔ Ｒｅｔｒａｎｓｍｉｓｓｉｏｎ）という。
この高速再送は、後述するタイムアウトによる再送に比べ非常に早く、パケットロス発生時の迅速な復帰を可能としている。
しかし、家庭用電気製品にネットワーク機能を備えた「ネット家電」と呼ばれる装置においては、その受信性能の低さから、ＲＷＩＮ＿ＭＡＸを大きくすることで、受信性能を越えたパケットが到着し、かえってデータ転送効率を落としてしまう恐れがある。
図３は、ネット家電の構成の一例を示す図である。
ネット家電（図中の受信側装置）１は、ネットワーク７と有線または無線で接続する通信機能を持つ装置であり、例えば、Ｅｔｈｅｒｎｅｔ（登録商標）インタフェースを備える。ネットワーク７は有線または無線を含むネットワークであり、インターネットなどの公衆ネットワークなどが例として挙げられる。
受信側装置１は、システムバス２、処理部３、記憶部４、および通信部５を備える。
通信部５は、システムバス２上に接続されたハードウェアである。通信部５は、記憶部４に格納されたパケットをネットワーク７に送信する機能と、ネットワーク７からパケットを受信する機能を有する。また、通信部５は、ネットワーク７から受信したパケットを一時的に保持するための記憶領域（以下、ＦＩＦＯという）６を有する。
処理部３は、システムバス２上に接続されたハードウェアである。記憶部４に格納されたデータをパケットとして構築する処理を行ったり、受信したパケットの解析処理を行ったりする。なお、処理部３は、送信パケットを記憶部４から通信部５へ転送したり、通信部５のＦＩＦＯ６に格納されているパケットを記憶部４へ転送したりする機能を有する場合もある。
記憶部４は、送受信するパケットやそのデータを保持する機能を有する。
また、受信側装置１は、パケットを受信すると次のような処理を行う。
（１）送信側装置８から送信されたパケットを通信部５で受信し、ＦＩＦＯ６へ格納
（２）ＦＩＦＯ６へ格納されたパケットを、システムバス２を介して記憶部４へ転送
（３）記憶部４へ転送されたパケットの内容を処理部３により解析
（４）受信したパケットに対して解析結果で得られたデータを、アプリケーションに渡す
図４は、ネット家電のデータ転送効率が低下してしまう場合におけるデータ転送の一例を示すシーケンス図である。なお、図４は、図３の受信側装置１と送信側装置８との間のデータ転送をＴＣＰで実施した場合のシーケンスを示す。また、受信側装置１はネット家電であって受信性能が低く、送信側装置８はＰＣ（Personal Computer）などのように高い送信性能を有する。
ここで、
ＲＷＩＮ＿ＭＡＸ：３２（単位をＫＢ、ネットワークでの輻輳なしとする）
ＦＩＦＯ６の容量：４（単位をＫＢとする）
システムバス２の転送能力：２０Ｍｂｐｓ
ネットワーク７の転送能力：１００Ｍｂｐｓ
を例として説明する。
受信側装置１は、ウィンドウサイズをＲＷＩＮ＿ＭＡＸ（３２ＫＢ）に設定したＡＣＫパケットＰ３１を送信側装置８に送信する。送信側装置８は、ＡＣＫパケットＰ３１を受信するとＲＷＩＮ＿ＭＡＸ（３２ＫＢ）分のデータパケットＰ４１をネットワーク７に送信する。その結果、１００Ｍｂｐｓの転送能力で、ＲＷＩＮ＿ＭＡＸ（３２ＫＢ）分のデータパケットが一気に受信側装置１の通信部５に到着することになる。しかし、受信側装置１のＦＩＦＯ６は、容量４ＫＢしかないため、ＲＷＩＮ＿ＭＡＸ（３２ＫＢ）分のデータを格納しきることは不可能である。
そこで、データパケットが到着し次第、そのデータパケットを早急にＦＩＦＯ６から記憶部４へ転送する必要がある。このとき、データパケットＰ４１の到着間隔に比べ、ＦＩＦＯ６から記憶部４へ受信済みパケットを転送する能力が勝っている場合は、ＦＩＦＯ６が溢れる前に、受信済みパケットを記憶部４へ転送しきることができ、送信側装置から送信されるデータパケットＰ４１を全て受信しきることが可能である。なお、ＰＣにおけるシステムバス２に相当するバスの最大転送能力は、例えばＰＣＩバスの場合、１０６４Ｍｂｐｓ（１３３ＭＢ／ｓ）であり、ネットワーク７の転送能力に比べ十分に早い。
しかし、受信側装置１がネット家電などでは、ＦＩＦＯ６から記憶部４への転送能力が、ネットワーク７の転送能力に比べ劣ってしまう場合が多い。本例では、ＦＩＦＯ６から記憶部４への転送能力と、通信部５に到着するパケットのスピード、すなわちネットワーク７の転送能力とに５倍の差がある場合で説明を行う。
受信側装置１は、１つ目のデータパケットＰ４１−１を受信すると、ＦＩＦＯ６から記憶部４へ受信済みパケットのデータ転送を行う。このデータ転送に要する時間を５Ｔとすると、転送性能の差が５倍であるから、ネットワーク７から到着するデータパケットの間隔は、Ｔとなる。よって、この５Ｔの間に、５つのデータパケットが受信側装置１に到着することになる。しかし、ＦＩＦＯ６の容量は、４ＫＢである。そのため、５つ目のデータパケットが到着した時点で空き容量不足となり、そのデータパケットはＦＩＦＯ６から溢れることになる。このように、その後のデータも、パケットロスが発生することになり、その後無駄な再送が行われることになる。結局、ＲＷＩＮ＿ＭＡＸを大きくしすぎたために、無駄な再送の多発により転送効率が落ちてしまうことになる。そこで、一般には、ネット家電などのような非力な通信装置においては、ＲＷＩＮ＿ＭＡＸの上限はＦＩＦＯ６の容量に合わせて設定される。
このようにＲＷＩＮ＿ＭＡＸをＦＩＦＯ６の容量（４ＫＢ）と一致する値に設定した場合、ＲＴＴが１０ミリ秒の環境では、やはり４ＫＢ／１０ミリ秒＝３．２Ｍｂｐｓと内部バス１の転送能力は２０Ｍｂｐｓの性能の割に、パケット転送性能が出ない。なお、ＦＩＦＯ６の容量がＲＷＩＮ＿ＭＡＸ（３２ＫＢ）分あると仮定すると、ＲＷＩＮ＿ＭＡＸを３２ＫＢとして通知でき、３２ＫＢ／１０ミリ秒＝２５．６Ｍｂｐｓとなり、内部バスの性能で制限されてとしても、２０Ｍｂｐｓもの転送性能を引き出すことができる。
また、ネット家電においては、その処理能力の低さから、ＲＷＩＮ＿ＭＡＸの設定値によっては、大幅に受信能力を落としてしまうことがある。
図５は、処理能力の高い受信側装置（例えばＰＣなど）の受信処理を示すシーケンス図である。なお、ＲＷＩＮ＿ＭＡＸを４とした場合を例に説明する。
まず、図５に示すように、送信側装置から送信されるデータパケットＰ３０１、Ｐ３０２、Ｐ３０３のうちデータパケットＰ３０２がパケットロスにより受信側装置に到達しなかったとする。このとき、受信側装置は、データパケットＰ３０１を受信することにより、ＡＣＫパケットＰ２９１を送信する。ＡＣＫパケットＰ２９１を受信した送信側装置は、シーケンス番号１１まで到達したことと、ウィンドウサイズが４であることから、続きのデータパケットＰ３０４を送信する。一方、受信側装置は、シーケンス番号１２のデータパケットＰ３０２が到達する前に、シーケンス番号１３のデータパケットＰ３０３を受信することで、データパケットＰ３０２がパケットロスしたか、または順序が入れ替わっていることを検知し、データパケットＰ３０３受信後、即座に即時確認応答Ｐ２９２を送信する。さらに、受信側装置は、データパケットＰ３０４を受信することにより、即時確認応答Ｐ２９４、Ｐ２９５を送信する。
次に、送信側装置は、即時確認応答を３個受信することにより、高速再送機能が働き、シーケンス番号１２のデータパケットＰ３０５を再送する。このように、パケットロスが発生した場合、高速な再送機能により通信を復帰することが可能となっている。
図６は、処理能力の低い受信側装置（例えばネット家電など）の受信処理を示すシーケンス図である。なお、ＲＷＩＮ＿ＭＡＸを４とした場合を例に説明する。
まず、図６に示すように、送信側装置から送信されるデータパケットＰ３２１、Ｐ３２２、Ｐ３２３のうちデータパケットＰ３２２がパケットロスにより受信側装置に到達しなかったとする。特に、受信能力の低い受信側装置の場合、データが受信側装置のＦＩＦＯ６から溢れてしまい、ネットワークが輻輳していなくても、パケットロスを引き起こしてしまうことがある。このとき、受信側装置は、データパケットＰ３２１を受信することにより、ＡＣＫパケットＰ３１１を送信する。このとき、受信側装置が送信するＡＣＫパケットＰ３１１は、受信側装置において、受信したデータパケットＰ３２１の受信処理が完了していないため、ウィンドウサイズが２となっている。そのため、ＡＣＫパケットＰ３１１を受信した送信側装置からは、何れのデータパケットも送信されない。その後、受信側装置は、シーケンス番号１２のデータパケットＰ３２２が到達する前に、シーケンス番号１３のデータパケットＰ３２３を受信することで、データパケットＰ３２２がパケットロスしたか、または順序が入れ替わっていることを検知し、データパケットＰ３２３受信後、即座に即時確認応答Ｐ３１２を送信する。このときのウィンドウサイズも受信処理が完了していないため、ウィンドウサイズが２となっている。その後、受信処理が終わった受信側装置は、ウィンドウサイズを４としたウィンドウ更新通知パケットＰ３１３を送信する。ウィンドウ更新通知パケットＰ３１３を受信した送信側装置は、シーケンス番号が１１で、ウィンドウサイズが４であることから、シーケンス番号１４、１５のデータパケットＰ３２４を送信する。また、データパケットＰ３２４を受信した受信側装置は、即時確認応答Ｐ３１４、Ｐ３１５を送信する。このとき、受信側装置が送信した即時確認応答パケットは連続２個である。そのため、送信側装置では、高速再送機能が働かない。そのため、送信側装置は、シーケンス番号１２のＡＣＫパケット受信がないため、タイムアウト時間Ｔ１を経過後、タイムアウトによる再送を行うことになる（Ｐ３２５）。このように、処理能力が低い場合、受信側装置は、即時確認応答を連続で行うことができないため、高速再送機能が働かず、タイムアウトを待った低速な再送となってしまう。このため、少しのパケットロス発生でも全く転送レートが出ない。
そこで、既存のＦＩＦＯ６の容量で、ＲＷＩＮ＿ＭＡＸを大きく通知しつつも、パケットロスを発生させずに、ＲＴＴの大きな環境でもネット家電の受信能力を最大限に発揮するためには、送信側装置が送信するデータの送信レートを、受信側装置から制御する必要がある。さらに、たとえパケットロスが発生しても、必要以上にレート低下を招かない必要がある。
特許文献１には、受信側装置によって、送信側装置のデータ送信レートを制御する方式が開示されている。特許文献１の方式によれば、受信側装置は、受信したデータに対するＡＣＫを生成すると、即座に送信せずに一旦ＡＣＫ送信キューにＡＣＫパケットを保持する。その後、次の（１）および（２）に従い、規則的な間隔で、ＡＣＫの送信を行うことでデータ送信レートを制御する。
（１）ＡＣＫ送信キュー内の残りのＡＣＫパケットが所定数未満の場合、送信されるべきＡＣＫを分割する。
（２）ＡＣＫの送信のつど、ウィンドウサイズ情報を１ＭＳＳずつ増加させる。
図７は、特許文献１におけるデータパケットとＡＣＫパケットのやり取りを示したシーケンス図である。
受信側装置は、送信側装置から送信されデータパケットＰ６１を受信すると、送信側装置へのＡＣＫパケットを生成し、ＡＣＫ送信キューへ挿入する。なお、このとき生成されたＡＣＫパケットは、ＡＣＫ番号１０のＡＣＫパケットである。その後、受信側装置は、規則的な間隔により決定された、所定時刻にＡＣＫパケットＰ５１を送信する。ＡＣＫパケットＰ５１は、ＡＣＫパケット送信を行う際、ＡＣＫ送信キューにＡＣＫパケットが所定数（２として説明する）に満たなかったため、ＡＣＫ分割を行っている。そのため、ＡＣＫ番号は、１０ではなく、９．１となっている。また、ウィンドウサイズは１ＭＳＳ増加した２となっている。
次に、ＡＣＫパケットＰ５１を受信した送信側装置は、ウィンドウサイズ２のパケットを受信したことにより、シーケンス番号９．１から１１．１まで送信可能となったため、未送信の後続のデータであるシーケンス番号１０のデータパケットＰ６２を送信する。
さらに、受信側装置は、ＡＣＫパケットＰ５１を送信後、規則的な間隔により決定された、所定時刻を迎えると、ＡＣＫパケットＰ５２の送信を行う。ＡＣＫパケットＰ５２に関しても、ＡＣＫパケット送信を行う際、ＡＣＫ送信キューにＡＣＫパケットが所定数（２として説明する）に満たなかったため、ＡＣＫ分割を行うことになる。そのため、ＡＣＫ番号は、１０ではなく、９．２となり、ウィンドウサイズは１ＭＳＳ増加した３となっている。このＡＣＫパケットＰ５２を受信した受信側装置は、ＡＣＫパケットＰ５１の受信時と同様に、シーケンス番号９．２から１２．２まで送信可能となったため、未送信の後続のデータであるシーケンス番号１１のデータパケットＰ６３を送信する。
以降、同様に１ＭＳＳずつウィンドウサイズを増加させながら、規則的な間隔で、ＡＣＫパケットＰ５３、Ｐ５４を送信していく。
このように、規則的な間隔で、ＡＣＫ分割を行い、１ＭＳＳずつウィンドウサイズを増加させ、ＡＣＫパケットを送信することで、送信側装置が送信するデータパケットの間隔を制御している。
特許第３６１７６４９号公報 標準仕様書「ＲＦＣ２００１」、ＩＥＴＦ、［平成１８月７月２１検索］、インターネット＜ＵＲＬ：ｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ｒｆｃ／ｒｆｃ２００１．ｔｘｔ＞
しかし、特許文献１の方式では、受信したデータに対するＡＣＫを、送信前に一旦キューに保持し、規則的な間隔で、ＡＣＫ分割を行い、ウィンドウサイズを１ＭＳＳずつ増加させることで、送信側装置から送信される送信レートの制御を行っているため、受信側装置からの送信レート制御を行うことは可能だが、次のような問題を含んでいる。
（１）データ受信を行わないと制御が開始できないという問題
（２）ＡＣＫ分割を行うため処理負荷がかるという問題
（３）ウィンドウサイズを１ＭＳＳ増加させるため細かなＡＣＫ送信間隔の制御が必要であるため負荷がかかるという問題
（４）パケットロス発生時の対応がないという問題
例えば、ＲＴＴを１０ミリ秒とすると、図７に示すように、１ＲＴＴ（１０ミリ秒）の間に４回ＡＣＫを送信していることになる。よって、ＡＣＫ送信間隔は、２．５ミリ秒となる。しかし、２．５ミリ秒間隔のＡＣＫ送信では、ＲＴＴ内に増加できるＲＷＩＮ＿ＭＡＸは、５どまりである。仮に、ＲＷＩＮ＿ＭＡＸを３２まで増加させたい場合、ＡＣＫ送信間隔は、１０ミリ秒／（３２−１）＝０．３２ミリ秒とする必要があり処理負荷が増大する。例えば、ＣＰＵ動作クロック１３３ＭＨｚのネット家電機器において、１ＭＳＳのデータパケットを受信する処理に要する時間は、０．３ミリ秒程度であり、また、ＡＣＫパケットを送信する処理に要する時間は、０．２ミリ秒程度である。よって、このような例の場合、０．３２ミリ秒間隔でＡＣＫ送信処理を行うことは、不可能である。
そこで、本発明は、かかる問題に鑑みてなされたものであって、データを送信する送信側装置に対して、そのデータの送信トラフィックを自らの受信能力に応じて自発的に制御し得るとともに、その制御処理負担を軽減した通信装置を提供することを第１の目的とする。また、パケットロスが発生したときにも、消失したパケットの迅速な再送を送信装置に対して促すことが可能な通信装置を提供することを第２の目的とする。
上記目的を達成するために、本発明に係る通信装置は、他の通信装置から送信されたデータを受信する受信手段と、前記受信手段によって受信されたデータに対する前記他の通信装置への応答内容を示す確認応答パケットを生成し、前記他の通信装置に送信する第１のパケット生成手段と、自装置が受信可能なデータの受信サイズを示す情報が含まれるデータ要求パケットであって、前記他の通信装置に対してデータの送信を要求するデータ要求パケットを生成し、前記他の通信装置に送信する第２のパケット生成手段と、前記受信サイズに更新量を加算することで、当該受信サイズを更新するサイズ算出手段と、自装置の通信能力に基づいて、前記データ要求パケットを送信する時間間隔である更新時間と前記更新量とを決定する更新決定手段と、を備え、前記第２のパケット生成手段は、前記受信手段によるデータの受信結果に関わらず、前記更新時間の経過ごとに、前記サイズ算出手段に前記受信サイズを更新させて前記データ要求パケットを送信することを特徴とする。
また、上記目的を達成するために、本発明に係る通信装置は、他の通信装置から送信されたデータを受信する通信装置であって、前記データを受信する受信手段と、前記受信手段によって受信されたデータに対する前記他の通信装置への応答内容を示す確認応答パケットを生成し、前記他の通信装置に送信する第１のパケット生成手段と、前記受信手段によるデータの受信結果に関わらず、前記他の通信装置に対してデータの送信を要求するデータ要求パケットを生成し、前記他の通信装置に送信する第２のパケット生成手段とを備えることを特徴とする。例えば、前記第２のパケット生成手段は、受信可能なデータのサイズが受信サイズとして前記データ要求パケットに含まれるように、当該データ要求パケットを生成する。
これにより、他の通信装置に対してデータの送信を要求するウィンドウ更新通知パケットたるデータ要求パケットが、他の通信装置から送信されたデータの受信結果に関わらず、他の通信装置に送信されるため、他の通信装置から送信されるデータ量を任意のタイミングで自発的に制御することが可能となる。例えば、他の通信装置からのデータの受信を待たずに制御することが可能である。さらに、ＡＣＫを分割するという処理や、多くのＡＣＫを短い送信間隔で送信することが不要となるため、制御処理負担を軽減することができる。さらに、データ要求パケットには受信サイズが含まれているため、他の通信装置に対して、受信可能なデータのサイズを通知することができ、その結果、受信能力に応じた送信トラフィックの制御を実現することができる。
また、前記通信装置は、さらに、前記受信サイズに更新量を加算することで、当該受信サイズを更新するサイズ算出手段を備え、前記第２のパケット生成手段は、更新時間の経過ごとに、前記サイズ算出手段に前記受信サイズを更新させて、更新された受信サイズを含む前記データ要求パケットを生成し、前記他の通信装置に送信することを特徴としてもよい。
これにより、更新時間の経過ごとに、つまり所定の更新間隔で、ウィンドウサイズたる受信サイズが更新量ずつ増加し、ウィンドウ更新通知パケットであるデータ要求パケットが送信されるため、他の通信装置の送信データのトラフィックパターンを制御することが可能となり、通信装置の処理に合わせたデータの受信を行うことができる。また、ウィンドウサイズが更新量ずつ増加することにより、他の通信装置から連続して送信される各データの量を、更新量にすることが可能となる。その結果、それらのデータを受信する通信装置では、受信されたデータをアプリケーションプログラムに引き渡す前に一時的に記憶するメモリの容量を、更新量までに削減することができる。
また、前記通信装置は、さらに、前記通信装置の通信能力に基づいて、前記更新時間および前記更新量を決定する更新決定手段を備えることを特徴としてもよい。
これにより、通信装置の通信能力に応じたトラフィックパターンに、他の通信装置によるデータの送信パターンを合わせることが可能となる。
また、前記受信手段は、受信されたデータを一時的に保持するためのメモリを有する物理層通信デバイスとして構成され、前記更新決定手段は、前記メモリの容量と、前記メモリに保持されたデータの転送能力とに基づいて、前記更新時間および前記更新量を決定することを特徴としてもよい。
これにより、物理層通信デバイスの能力に適したトラフィックパターンに、他の通信装置によるデータの送信パターンを合わせることが可能となり、物理層通信デバイスでのパケットロスを防止することができる。
また、前記通信装置は、さらに、前記受信手段により受信されたデータを処理する処理手段を備え、前記更新決定手段は、さらに、前記処理手段の処理能力に基づいて、前記更新時間を決定することを特徴としてもよい。
これにより、通信装置のデータ処理能力に適したトラフィックパターンに、他の通信装置によるデータの送信パターンを合わせることが可能となり、通信装置の通信及びデータ処理のために割く処理量を制御することができる。
また、前記更新決定手段は、さらに、前記通信装置で動作するアプリケーションプログラムが必要とするビットレートに基づいて、前記更新時間を決定することを特徴としてもよい。
これにより、通信装置におけるアプリケーションプログラムの必要とするビットレートに適したトラフィックパターンに、他の通信装置によるデータの送信パターンを合わせることが可能となり、アプリケーションプログラムが要求する以上の無駄なトラフィックの発生を防止することができる。
また、前記第２のパケット生成手段は、前記更新時間の経過ごとに、前記データ要求パケットを生成しているときに、前記受信手段によってデータが受信されると、前記データ要求パケットの生成を中止することを特徴としてもよい。
これにより、ウィンドウ更新通知パケットたるデータ要求パケットの送信が中止され、つまりウィンドウ更新通知機能が停止されるため、データ要求パケットが継続して送信され続けて他の通信装置が送信するデータの送信レートが無限に上がってしまうことを防止することができる。
また、前記第２のパケット生成手段は、前記更新時間の経過ごとに行われる前記データ要求パケットの生成を中止しているときに、前記受信手段によってデータが受信されると、前記更新時間の経過ごとに行われる前記データ要求パケットの生成を再開することを特徴としてもよい。
これにより、他の通信装置がデータ送信を中止して再開したときには、再度、通信装置の通信能力に合わせたトラフィックパターンの制御が可能となる。
また、前記サイズ算出手段は、さらに、前記通信装置で動作するアプリケーションプログラムが要求するデータの総量を取得し、前記受信手段によって受信されたデータの受信量が前記総量に近づくにつれて減少するような応答サイズを算出し、第１のパケット生成手段は、受信可能なデータのサイズが前記応答サイズであることを前記応答内容として示す前記確認応答パケットを生成することを特徴としてもよい。
これにより、一連のデータの受信終了に合わせて、それらのデータに対するＡＣＫパケットたる確認応答パケットの応答サイズ（ウィンドウサイズ）が減少するため、他の通信装置がデータ送信を再開したときには、再開時に他の通信装置から送信されるデータの量を、その減少された応答サイズに制限することができるので、通信装置の受信性能に合わせたデータ送信の再開を行うことができる。
また、前記第１のパケット生成手段は、受信可能なデータのサイズを応答サイズとして示す前記確認応答パケットを生成し、前記更新時間の経過ごとに行われる前記データ要求パケットの生産が中止しているときに、先に送信されてロスしたデータが再送されて前記受信手段によって受信された際には、前記第１のパケット生成手段は、前回生成された前記確認応答パケットの応答サイズよりも小さい応答サイズを示す確認応答パケットを生成し、前記第２のパケット生成手段は、前記更新時間の経過ごとに行われる前記データ要求パケットの生産を再開することを特徴としてもよい。
これにより、パケットロス発生時においても、送信データのレート制御を行うことが可能となる。
また、前記通信装置は、さらに、前記更新時間の経過ごとに行われる前記データ要求パケットの生産が中止しているときに、前記第１のパケット生成手段による前記確認応答パケットの送信のタイミングを遅らせる遅延手段を備えることを特徴としてもよい。
これにより、確認応答パケットの送信のタイミングが遅れるため、他の送信装置から連続的に送信された各データの受信時刻の間隔が揺らいでも、制御したトラフィックパターンを継続的に維持することが可能となる。例えば、他の通信装置から送信された複数のデータの受信と、それらのデータに対する通信装置からの複数の確認応答パケット（ＡＣＫパケット）の送信とがそれぞれ、更新時間の経過ごと、つまり所定間隔で行われている。このようなときに、他の通信装置から送信されたデータが所定間隔よりも短い間隔で受信されると、そのデータを受信した通信装置は、そのデータに対する確認応答パケットを即座に送信することなく、確認応答パケットの送信を遅延させる。つまり、通信装置は、前回に確認応答パケットを送信してから更新時間が経過した後に、その確認応答パケットを送信する。
また、前記受信手段は、受信されたデータを一時的に保持するためのメモリを有する物理層通信デバイスとして構成され、前記通信装置は、さらに、前記メモリの容量と、前記メモリに保持されたデータの転送能力とに基づいて、前記確認応答パケットの送信間隔を決定する送信間隔決定手段を備え、前記遅延手段は、前記送信間隔決定手段によって決定された送信間隔で複数の前記確認応答パケットが送信されるように、前記タイミングを遅らせることを特徴としてもよい。
これにより、メモリの容量と転送能力に基づいた送信間隔で確認応答パケットが送信されるため、物理層通信デバイスの能力に適したトラフィックパターンに、他の通信装置によるデータの送信パターンを合わせることが可能となり、物理層通信デバイスでのパケットロスを防止することができる。
また、前記通信装置は、さらに、前記受信手段により受信されたデータを処理する処理手段と、前記処理手段の処理能力に基づいて、前記確認応答パケットの送信間隔を決定する送信間隔決定手段とを備え、前記遅延手段は、前記送信間隔決定手段によって決定された送信間隔で複数の前記確認応答パケットが送信されるように、前記タイミングを遅らせることを特徴としてもよい。
これにより、通信装置のデータ処理能力に適したトラフィックパターンに、他の通信装置によるデータの送信パターンを合わせることが可能となり、通信装置の通信及びデータ処理のために割く処理量を制御することができる。
また、前記通信装置は、さらに、前記通信装置で動作するアプリケーションプログラムが必要とするビットレートに基づいて、前記確認応答パケットの送信間隔を決定する送信間隔決定手段を備え、前記遅延手段は、前記送信間隔決定手段によって決定された送信間隔で複数の前記確認応答パケットが送信されるように、前記タイミングを遅らせることを特徴としてもよい。
これにより、通信装置におけるアプリケーションプログラムの要求するビットレートに適したトラフィックパターンに、他の通信装置によるデータの送信パターンを合わせることが可能となり、アプリケーションプログラムが要求する以上の無駄なトラフィックの発生を防止することができる。
また、前記通信装置は、さらに、受信レート変更の要求に基づいて、前記確認応答パケットの送信間隔を決定する送信間隔決定手段を備え、前記遅延手段は、前記送信間隔決定手段によって決定された送信間隔で複数の前記確認応答パケットが送信されるように、前記タイミングを遅らせることを特徴としてもよい。
これにより、受信レート変更の要求があったときには、その要求に基づいた送信間隔で確認応答パケットが送信されるため、その要求に適したトラフィックパターンに、他の通信装置によるデータの送信パターンを合わせることが可能となる。
また、前記第１のパケット生成手段は、受信可能なデータのサイズを応答サイズとして示す前記確認応答パケットを生成し、前記遅延手段は、さらに、前記第１のパケット生成手段によって生成された前記確認応答パケットの示す応答サイズを、受信レート変更の要求に基づいて変更することを特徴としてもよい。
これにより、受信レート変更の要求があったときには、その要求に基づいた応答サイズ（ウィンドウサイズ）を示す確認応答パケット（ＡＣＫパケット）が送信されるため、その要求に適したトラフィックパターンに、他の通信装置によるデータの送信パターンを合わせることが可能となる。
また、前記第２のパケット生成手段は、前記受信手段によって受信されたデータの受信量が閾値を超えたときに、前記更新時間の経過ごとに行われる前記データ要求パケットの生成を開始することを特徴としてもよい。
これにより、他の通信装置が徐々にデータの送信レートを増加させても、通信装置の通信能力に応じたトラフィックパターンに、他の通信装置によるデータの送信パターンを合わせることが可能となる。
また、前記第２のパケット生成手段は、要求されるデータの先頭番号を含む前記データ要求パケットを生成し、前記受信手段によって受信されたデータの受信量が閾値を超えたときには、順次送信される前記データ要求パケットの先頭番号が増加するように、前記更新時間の経過ごとに行われる前記データ要求パケットの生成を開始することを特徴としてもよい。
これにより、データの受信量が閾値を超えたときには、ウィンドウ更新通知パケットたるデータ要求パケットが更新時間の経過ごとに送信される。そして、各データ要求パケットのウィンドウサイズたる受信サイズとＡＣＫ番号たる先頭番号とは、前回のデータ要求パケットの受信サイズと先頭番号よりも増加する。その結果、通信装置の通信能力に応じたトラフィックパターンに、他の通信装置によるデータの送信パターンを確実に合わせることが可能となる。
また、前記通信装置は、さらに、前記他の通信装置から送信されたデータのロスを検出する検出手段を備え、前記第１のパケット生成手段は、受信可能なデータのサイズを応答サイズとして示す前記確認応答パケットを生成し、前記検出手段によってロスが検出されたときには、前回生成された確認応答パケットの応答サイズよりも小さい応答サイズを示す確認応答パケットを生成することを特徴としてもよい。例えば、前記第１のパケット生成手段は、前回生成された確認応答パケットの応答サイズと、ロスしたデータの量との差分を前記小さい応答サイズとして示す前記確認応答パケットを生成する。
これにより、パケットロスが発生したときには、確認応答パケット（ＡＣＫパケット）の応答サイズ（ウィンドウサイズ）が小さくなるため、他の通信装置によるデータの送信レートを落として、パケットロスの発生を抑えることができる。
また、前記第１のパケット生成手段は、さらに、前記検出手段によって所定時間にロスが検出されなかったときには、前回生成された確認応答パケットの応答サイズよりも大きい応答サイズを示す確認応答パケットを生成することを特徴としてもよい。
これにより、パケットロスが所定時間内に発生しなかったときには、確認応答パケット（ＡＣＫパケット）の応答サイズ（ウィンドウサイズ）が大きくなるため、他の通信装置によるデータの送信レートを上げて、データ送信効率を上げることができる。
また、前記第２のパケット生成手段は、前記他の通信装置によって順次送信されたデータが予め定められた順序通りに前記受信手段に受信されなかった場合、または、前記データがロスした場合に送信されるべき否定応答パケットとして、前記データ要求パケットを生成することを特徴としてもよい。例えば、前記第２のパケット生成手段は、データのロスが発生した場合に、ロス発生の直前に前記受信手段で受信されたデータに対する確認応答パケットと同一の内容を示す、所定数の前記データ要求パケットを生成して送信する。
これにより、他の通信装置から送信されたデータがロスしても、他の通信装置から送信されたデータの受信結果に関わらず、他の通信装置に対して高速再送機能を誘発させることができる。その結果、タイムアウトを待つことなく、ロスしたデータを受信することができる。
また、前記受信手段で受信されたデータのうち、消失したロスデータを検知するロス検知手段を備え、前記第１のパケット生成手段は、前記他の通信装置からのデータの送信に対する確認応答として、前記ロス検知手段によって検知されたロスデータの再送を指示する前記確認応答パケットを、前記他の通信装置に送信し、前記第２のパケット生成手段は、前記第１のパケット生成手段により送信される確認応答パケットの送信数が、前記他の通信装置に対して前記ロスデータの再送を実行させるだけの必要数に満たない場合に、前記他の通信装置からのデータの送信に関わらず、前記必要数から送信数を差し引いた複製数だけ、前記確認応答パケットを前記データ要求パケットとして前記他の通信装置に送信することを特徴としてもよい。
例えば、他の汎用の通信装置は、３つのＤｕｐＡｃｋをそれぞれ確認応答パケットとして受信したときに、それらのＤｕｐＡｃｋの示すロスデータを再送する。即ち、他の通信装置に対してロスデータの再送を実行させるだけのＤｕｐＡｃｋの必要数とは「３」である。このような場合、本発明に係る通信装置の第１のパケット生成手段は、他の通信装置からのパケットの送信に対する受信応答として、ＤｕｐＡｃｋ（確認応答パケット）を送信し、第２のパケット生成手段は、そのＤｕｐＡｃｋの送信数が必要数「３」に満たない場合に、他の通信装置からのデータパケットの送信に関わらず、その必要数「３」から送信数を差し引いた複製数だけ、ＤｕｐＡｃｋをデータ要求パケットとして他の通信装置に送信する。したがって、例えば、第１のパケット生成手段がＤｕｐＡｃｋを２つ送信しているときには（送信数が「２」）、第２のパケット生成手段は、他の通信装置からパケットを受け取っていないにも関わらず、ＤｕｐＡｃｋを１つ送信する。
これにより、通信装置のリソースが十分でない場合であっても、すなわち、通信装置における受信処理の遅延によりＴＣＰ Ｗｉｎｄｏｗサイズが回復しない場合においても、タイムアウトまで待つことなく、他の通信装置に対してロスデータの高速再送を発動させることができる。その結果、ロスデータによるスループットの低下を最小限に抑えることができる。また、従来例のようにＥＬＮを解釈する機能を他の通信装置に対して要求することなく、汎用の通信装置に対して高速再送を促すことができる。
また、受信手段で取得されたデータからロスデータが検知されるため、ネットワークが過負荷状態であるために消失したデータ（例えばＴＣＰパケット）の再送を指示するような誤ったＤｕｐＡｃｋが送信されることがない。したがって、そのようなＤｕｐＡｃｋに応じて他の通信装置が過負荷状態のネットワークにさらにデータを送信して無駄なトラフィックを発生させてしまうようなことを防ぐことができる。
また、前記受信手段は、メモリを備え、前記他の通信装置から送信されるデータを順次取得して前記メモリに格納し、前記ロス検知手段は、前記メモリに格納されずに消失したロスデータを検知することを特徴としてもよい。
これにより、例えば受信用ＦＩＦＯメモリから溢れたことにより消失したロスデータが確実に検知されるため、他の通信装置に対してそのデータの高速再送を確実に促すことができる。
また、前記通信装置は、さらに、前記受信手段からデータを取得して、ＯＳＩ参照モデルのネットワーク層としての処理を前記データに対して行なうネットワーク処理手段を備え、前記ロス検知手段は、前記ネットワーク処理手段において消失したロスデータを検知することを特徴としてもよい。
これにより、例えばＩＰ（Internet Protocol）の処理を行なうネットワーク処理手段、すなわちＩＰ処理部において消失したロスデータが確実に検知されるため、他の通信装置に対してそのデータの高速再送を確実に促すことができる。
また、前記ロス検知手段は、消失したロスデータがＴＣＰ（Transmission Control Protocol）に基づくデータである場合に限って、前記ロスデータを検知することを特徴としてもよい。
これにより、ＴＣＰパケット以外のロスデータに対して誤った確認応答パケットまたはデータ要求パケットが送信されるのを防ぐことができ、そのようなパケットに応じて他の通信装置からデータが送信されて、無駄なトラフィックが発生するのを防ぐことができる。
また、前記通信装置は、さらに、前記受信手段で取得されたデータに基づいて再送指示対象の前記他の通信装置を特定する装置特定手段を備えることを特徴としてもよい。
例えば、受信手段より取得されたデータにより示されるＩＰアドレスやポート番号などに基づいて再送指示対象の他の通信装置が特定されるため、データの送信元となる他の通信装置に対して確実に確認応答パケットまたはデータ要求パケットを送信することができ、誤った装置に対して再送指示信号を送信することにより生じる無駄なトラフィックの発生を抑制することができる。
また、前記ロス検知手段は、ロスデータを検知したときには前記検知結果を保持しておき、前記通信装置は、さらに、前記ロス検知手段によるロスデータの検知から所定期間が経過したとき、前記通信装置が所定数のデータを送信したとき、前記通信装置によるデータの処理速度が前記ロスデータの検知時よりも遅くなったとき、または、前記第２のパケット生成手段によってデータ要求パケットが送信されたときに、前記ロス検知手段により保持されている検知結果を削除するリセット手段を備えることを特徴としてもよい。
これにより、ロス検知手段により保持されている検知結果（パケットロス情報）が削除されるため、他の通信装置からデータが再送されているにも関わらず、確認応答パケットまたはデータ要求パケットを誤って送信してしまうということを防ぐことができ、そのような誤ったパケットによる無駄なトラフィックの発生を抑制することができる。また、ロスデータの検知から所定期間が経過したときに検知結果が削除される場合には、所定期間の経過に従って確実に検知結果を削除することができる。また、通信装置が所定数のデータを送信したときに検知結果が削除される場合には、タイマ機能などを要せず検知結果を簡単に適切なタイミングで削除することができる。また、通信装置によるデータの処理速度（例えば、ＰＰＳ）がロスデータの検知時よりも遅くなったときに検知結果が削除される場合には、通信装置が過負荷状態であるにもかかわらず検知結果が保持されているために確認応答パケットまたはデータ要求パケットが送信されることを防ぐことができ、そのパケットに応じて他の通信装置からデータが送信されて無駄なトラフィックが発生してしまうのを抑制することができる。さらに、ロスデータの検知とその検知結果の削除とが頻繁に繰り返されることを防ぐことができ、適切なタイミングで検知結果を削除することができる。また、前記第２のパケット生成手段によってデータ要求パケットが送信されたときに検知結果が削除される場合には、適切な確認応答パケットまたはデータ要求パケットを送信することができる。例えば、データ要求パケットが送信された後に検知結果が削除されていなければ、再びロスデータが検知されたときに、第１および第２のパケット生成手段は、誤ったロスデータの再送を指示する確認応答パケットまたはデータ要求パケットを送信してしまうことがある。したがって、本発明では上述のようなタイミングで検知結果を削除することにより、適切な再送指示信号を送信することができる。
また、前記第２のパケット生成手段は、前記第１のパケット生成手段によって確認応答パケットが生成されるときに前記複製数を算出することを特徴としてもよい。
これにより、複製数が早期に算出されるため、第２のパケット生成手段はその算出された複製数だけデータ要求パケットを早急に送信することができ、その結果、他の通信装置に対して高速再送を最も速く発動させることができる。さらに、第２のパケット生成手段はデータ要求パケットを早急に送信することができるため、そのデータ要求パケットやそのパケットに関連する情報などを長時間保持しておく必要がない。その結果、メモリ容量を削減することができる。
また、前記第２のパケット生成手段は、前記第１のパケット生成手段によって確認応答パケットが送信されてから所定期間が経過する前に、前記確認応答パケットが送信されてから所定期間が経過する前であって且つ前記通信装置の負荷率が所定の閾値以下になったとき、または、前記通信装置の受信可能なデータ量が増加したことを前記通信装置が前記他の通信装置に通知する前に、前記複製数を算出することを特徴としてもよい。
これにより、第１のパケット生成手段によって確認応答パケットが送信されてから所定期間（例えば、タイムアウト期間）が経過する前に複製数が算出される場合には、第２のパケット生成手段は、その所定期間において第１のパケット生成手段から送信された確認応答パケットの送信数を確実にカウントすることができ、正確な複製数を算出することができる。また、確認応答パケットが送信されてから所定期間が経過する前であって且つ前記通信装置の負荷率（例えば、ＣＰＵの使用率）が所定の閾値以下になったときに複製数が算出される場合には、上述と同様に正確な複製数を算出することができるとともに、第２のパケット生成手段は、通信装置の負荷が小さいときに、データ要求パケットを適切に生成することができる。また、通信装置の受信可能なデータ量が増加したこと（例えば、ＷｉｎＵｐｄａｔｅ）を通信装置が他の通信装置に通知する前に複製数が算出される場合には、上述と同様に正確な複製数を算出することができる。さらに、例えば、ＷｉｎＵｐｄａｔｅが他の通信装置に通知された後に、複製数が算出されて、その後、その複製数だけのＤｕｐＡｃｋがデータ要求パケットとして第２のパケット生成手段から送信される場合には、他の通信装置は、第１のパケット生成手段から送信されたＤｕｐＡｃｋ（確認応答パケット）と、第２のパケット生成手段から送信されたＤｕｐＡｃｋ（データ要求パケット）とを区別する。したがって、他の通信装置は、ロスデータに対して同一のＤｕｐＡｃｋが必要数だけ送信されていないと判断して、そのロスデータに対して高速再送を実行しない場合がある。そこで、本発明では、上述のようにＷｉｎＵｐｄａｔｅを通知する前に複製数を算出することにより、ＷｉｎＵｐｄａｔｅの通知前にその複製数だけのＤｕｐＡｃｋを送信することができ、他の通信装置に対して高速再送を確実に促すことができる。
また、前記第２のパケット生成手段は、前記通信装置で受信可能なデータ量に基づいて前記複製数を算出することを特徴としてもよい。例えば、前記第２のパケット生成手段は、前記第１のパケット生成手段によって最初の確認応答パケットが送信されるときに、前記受信可能なデータ量に基づいて、前記第１のパケット生成手段から送信される予定の送信数を算出し、前記必要数から前記送信数を差し引くことにより、前記複製数を算出することを特徴としてもよい。
これにより、最初の確認応答パケットが送信されるときに、第１のパケット生成手段から送信される予定の送信数が例えばＷｉｎｄｏｗサイズに基づいて算出されて、その送信数に基づいて複製数が算出されるため、その最初の確認応答パケットが送信された後に、第２のパケット生成手段はその複製数だけのデータ要求パケットを早急に送信することができる。
また、前記第２のパケット生成手段は、前記複製数が２以上であるときには、ＯＳＩ参照モデルのデータリンク層またはトランスポート層にあるデータ要求パケットを複製して、前記複製数のデータ要求パケット信号を送信することを特徴としてもよい。
これにより、データリンク層にあるＭＡＣ（Media Access Control）フレームとして構築されたＤｕｐＡｃｋ（確認応答パケット）が複製される場合には、その複製元のＤｕｐＡｃｋが送信可能な状態に完成されているため、ＤｕｐＡｃｋを再送するのに要するメモリ容量を削減できるとともに、ＣＰＵの処理負荷を低減することができる。また、トランスポート層にあるＴＣＰパケットとして構築されたＤｕｐＡｃｋ（確認応答パケット）が複製される場合には、その複製数の管理をトランスポート層（ＴＣＰ）で容易に行なえることができる。その結果、例えば既存の通信装置に対して本発明を適用するときには、そのトランスポート層に対して改修を行なえばよく、改修箇所を限定することができる。
なお、本発明は、このような通信装置として実現することができるだけでなく、その方法やプログラム、そのプログラムを格納する記憶媒体、集積回路としても実現することができる。
本発明の通信装置は、送信側の他の通信装置の送信データレートを制御することが可能となり、処理能力を超えたデータを受信することで発生していたパケットロスを抑制し、スループット低下を防止する。さらに、通信装置の処理能力に適した送信レートに、送信側の他の通信装置の送信レートを制御することで、効率の良いデータ転送を行え最大スループットを得ることが可能となる。
以下本発明の実施の形態について、図面を参照しながら説明する。なお、実施の形態における説明においては、ＴＣＰを用いた通信を例に説明を行うが、ＴＣＰ同様に、受信可能なバッファ空き容量を確認応答パケットによって通知する同種の通信プロトコルにおいても、本発明は、適用可能である。また、実施の形態の説明においては、受信専用の通信装置を受信側装置とし、送信専用の通信装置を送信側装置とし、受信側装置に本発明を適用したとして説明を行うが、受信側装置および送信側装置の双方に、送受信機能を備えてもよく、送信側装置に本発明を適用しても良い。
（実施の形態１）
図８は、本実施の形態に係る通信装置（受信側装置）の構成の一例を示す図である。受信側装置３１は、ネットワーク３７と有線または無線で接続する通信機能を持つ装置であり、例えば、Ｅｔｈｅｒｎｅｔ（登録商標）インタフェースを備える。ネットワーク３７は有線または無線を含むネットワークであり、インターネットなどの公衆ネットワークなどが例として挙げられる。
受信側装置３１は、システムバス３２、処理部３３、記憶部３４、および通信部３５を備える。
通信部３５は、システムバス３２上に接続されたハードウェアである。通信部３５は、記憶部３４に格納されたパケットをネットワーク３７に送信する機能と、ネットワーク３７からパケットを受信する機能を有する。また、通信部３５は、ネットワーク３７から受信したパケットを一時的に保持するための記憶領域（以下、ＦＩＦＯという）３６を有する。なお、実施の形態１〜１０では、通信部が受信手段として構成されている。
処理部３３は、システムバス３２上に接続されたハードウェアである。処理部３３は、記憶部３４に格納されたデータをパケットとして構築する処理を行ったり、受信したパケットに対して解析処理を行ったりする。なお、処理部３３は、送信パケットを記憶部３４から通信部３５へ転送したり、通信部３５のＦＩＦＯ３６に格納されているパケットを記憶部３４へ転送したりする機能を有する場合もある。
記憶部３４は、送受信するパケットやそのデータを保持する機能を有する。
ここで、受信側装置３１の受信処理を説明する。受信側装置３１は、ネットワーク３７からパケットを受信すると、まず通信部３５のＦＩＦＯ３６に受信したパケットを格納する。次に、受信側装置３１は、ＦＩＦＯ３６に格納した受信パケットをＦＩＦＯ３６から記憶部３４へシステムバス３２を介して転送する。記憶部３４へ転送された受信パケットの内容は、処理部３３によって解析され、受信処理される。処理部３３は、解析結果を得ると、アプリケーションプログラム（以下、単にアプリケーションという）に受信したデータを引き渡す。
図９は、本実施の形態の受信側装置３１における処理部３３の機能構成の一例を示す構成図である。なお、本実施の形態においては、ＴＣＰ処理部４２は、処理部３３で実行されるプログラムとして構成されているが、ＬＳＩ（Large Scale Integration）などで実装されたものであっても良い。また、図中の実線は、送受信パケットのデータフローを、破線は制御情報のやり取りに関するフローを示している。
処理部３３は、ＩＰ処理部４１、ＴＣＰ処理部４２およびアプリケーション処理部４３を備える。
受信側装置３１のＴＣＰ処理部４２は、ＴＣＰパケット処理部４４、受信バッファ４７、ウィンドウサイズ算出部４８、ウィンドウ更新タイマ部４９、受信レート決定部５０、および前回ＲＷＩＮ記憶部５１から構成される。次に、これらの各構成要素の説明をする。
ＴＣＰパケット処理部４４は、ＴＣＰパケットの送受信処理の機能を有する。ＴＣＰパケット処理部４４は、受信したパケットのアプリケーションを特定し、そのパケットをアプリケーションへ引き渡すため、受信バッファ４７に格納する。さらに、ＴＣＰパケット処理部４４は、ＴＣＰパケットを構築し、ＩＰ処理部４１へ渡し、ＴＣＰ／ＩＰパケットとして送信する機能を有する。また、ＴＣＰパケット処理部４４には、ＡＣＫ生成部４５とウィンドウ更新通知生成部４６が含まれる。
ＡＣＫ生成部４５は、受信したＴＣＰパケットのシーケンス番号に基づいて、ＡＣＫ番号を決定し、ＡＣＫパケットを生成する。ＡＣＫパケットには、ウィンドウサイズ算出部４８から得た、現在受信可能な空き容量（以下、ウィンドウサイズ）も設定される。なお、実施の形態１〜９では、ＡＣＫ生成部は第１のパケット生成手段として構成されて、ＡＣＫパケットは確認応答パケットに相当する。また、ＡＣＫパケットに設定されるウィンドウサイズは応答サイズに相当する。
ウィンドウ更新通知生成部４６は、受信バッファ４７の空き状況に増加が生じたとき、ウィンドウ更新通知パケットを生成する。さらに、ウィンドウ更新通知生成部４６は、ウィンドウ更新タイマ部４９からの指示により、ウィンドウ更新通知パケットを生成する機能を有する。ウィンドウ更新通知パケットには、ウィンドウサイズ算出部４８から得た、ウィンドウサイズが設定される。なお、実施の形態１〜９では、ウィンドウ更新通知生成部は第２のパケット生成手段として構成されて、ウィンドウ更新通知パケットはデータ要求パケットに相当する。また、ウィンドウ更新通知パケットに設定されるウィンドウサイズは受信サイズに相当する。
受信バッファ４７は、アプリケーション処理部４３に渡すための受信データを一時的に保持する機能を有する。受信バッファ４７は、最大ＲＷＩＮ＿ＭＡＸのデータを格納することができ、アプリケーション処理部４３の要求により、受信バッファ４７に一時的に保持されているデータを順に、アプリケーション処理部４３へ渡す。また、受信バッファ４７は、アプリケーション処理部４３へデータが渡されることによってウィンドウサイズが増加した際は、ウィンドウ更新通知生成部４６へウィンドウサイズが増加したことを通知する。
ウィンドウサイズ算出部４８は、送信側装置３８へウィンドウサイズとして通知する値を算出する機能を有する。ウィンドウサイズ算出部４８は、受信レート決定部５０から指示される更新量（以下、ＲＷＩＮ＿Ｕｐｄａｔｅ）と、前回ＲＷＩＮ記憶部５１に格納される前回通知したウィンドウサイズ（ＲＷＩＮ＿Ｐｒｅｖ）とに基づき、ウィンドウサイズを算出する。ウィンドウサイズは、次の式で算出される。
ウィンドウサイズ＝ＲＷＩＮ＿Ｐｒｅｖ＋ＲＷＩＮ＿Ｕｐｄａｔｅ・・・（式１）
なお、受信バッファ４７が格納可能なデータの最大サイズ（ＲＷＩＮ＿ＭＡＸ）も考慮して、次の式で算出してもよい。
ウィンドウサイズ＝ＭＩＮ（ＲＷＩＮ＿Ｐｒｅｖ＋ＲＷＩＮ＿Ｕｐｄａｔｅ，
ＲＷＩＮ＿ＭＡＸ）・・・（式２）
ＭＩＮ（Ａ，Ｂ）は、ＡとＢの最小値を返すものとする。
ウィンドウ更新タイマ部４９は、所定間隔で、ウィンドウ更新通知生成部４６にウィンドウ更新通知パケットの送信を指示する機能を有する。また、所定間隔は、受信レート決定部５０により指示される。
受信レート決定部５０は、受信側装置３１におけるＴＣＰパケットの受信レートに基づき、ウィンドウサイズ算出部４８の更新量と、ウィンドウ更新タイマ部４９の所定間隔を決定する機能を有する。次に、更新量と所定間隔の決定方法の例を示す。
例１：
更新量と所定間隔は、ＦＩＦＯ３６の容量とシステムバス３２の転送能力に基づいて次の式で算出することができる。
更新量＝ＦＩＦＯ３６の容量・・・（式３）
所定間隔＝ＦＩＦＯ３６の容量／システムバス３２の転送能力・・・（式４）
具体的には、受信側装置３１のＦＩＦＯ３６の容量が４ＫＢであり、システムバス３２の転送能力が４０Ｍｂｐｓである場合、更新量は、ＦＩＦＯ３６の容量に合わせ４ＫＢとなり、所定間隔は、４ＫＢをシステムバス３２が転送するのに要する時間０．８ミリ秒となる。なお、所定間隔は、０．８ミリ秒以上とすることで、システムバス３２の転送能力以下のデータ転送量に抑えることができるので、１ミリ秒としても良い。また、所定間隔を算出する際、システムバス３２の転送能力で除算しているが、ＣＰＵ（Central Processing Unit）処理能力も加味し、１パケットの処理時間とシステムバスの転送能力とから所定間隔を算出しても良い。
例２：
更新量と所定間隔は、ＦＩＦＯ３６の容量とアプリケーションが要求するビットレートに基づいて次の式で算出することができる。
更新量＝ＦＩＦＯ３６の容量・・・（式５）
所定間隔＝ＲＴＴ／ＣＥＩＬＩＮＧ（（（アプリケーションが必要とするビットレート
×ＲＴＴ）／８）／更新量，１）・・・（式６）
ＣＥＩＬＩＮＧ（Ａ，Ｂ）は、ＡをＢの単位で切り上げた結果を出力する。
具体的には、受信側装置３１のＦＩＦＯ３６のサイズが４ＫＢであり、アプリケーションが要求するビットレート１０Ｍｂｐｓ、ＲＴＴを１０ミリ秒とした場合、更新量は、ＦＩＦＯ３６のサイズに合わせ４ＫＢとなる。さらに、この場合、アプリケーションの要求するビットレートが１０Ｍｂｐｓであるため、１ＲＴＴ（１０ミリ秒）中に、１２．５ＫＢのデータをアプリケーションが受信する必要がある。したがって、更新量として４ＫＢずつの増加を考慮すると、１ＲＴＴに中に３．１２５回、すなわち４回の更新が必要となる。よって、所定間隔は、ＲＴＴ／４である２．５ミリ秒となる。
例３：
更新量と所定間隔は、受信バッファ４７に格納可能なデータの最大容量ＲＷＩＮ＿ＭＡＸとアプリケーションが要求するビットレートに基づいて次の式から算出することができる。
更新量＝ＲＷＩＮ＿ＭＡＸ・・・（式７）
所定間隔＝ＲＴＴ／ＣＥＩＬＩＮＧ（（（アプリケーションが必要とするビットレート
×ＲＴＴ）／８）／ＲＷＩＮ＿ＭＡＸ，１）・・・（式８）
具体的には、受信バッファ４７に格納可能なデータの最大容量ＲＷＩＮ＿ＭＡＸを８ＫＢ、アプリケーションが必要とするビットレート１０Ｍｂｐｓ、ＲＴＴを１０ミリ秒とした場合、更新量は、ＲＷＩＮ＿ＭＡＸに合わせ８ＫＢとなる。さらに、この場合、アプリケーションの必要とするビットレートが１０Ｍｂｐｓであるため、１ＲＴＴ（１０ミリ秒）中に、１２．５ＫＢのデータを受信する必要がある。したがって、更新量として８ＫＢずつの増加を考慮すると、１ＲＴＴ中に１．５６２５回、すなわち２回の更新が必要となる。よって、所定間隔は、ＲＴＴ／２である５ミリ秒となる。
なお、例１〜例３で示した式を元に、更新量をＭＳＳ単位に丸めたり、所定間隔をミリ秒もしくは、数ミリ秒単位に切り上げたりしてもよい。
また、受信レート決定部５０は、複数のコネクションが張られた場合や、処理部３３が別の通信処理以外の処理を実施するため、処理能力が低下した場合など、受信側装置３１の受信状況が変化場合に合わせて、更新量と所定間隔を動的に変更する機能を持っても良い。
前回ＲＷＩＮ記憶部５１は、前回にウィンドウ更新通知を行った際に用いたウィンドウサイズ（以下、前回ウィンドウサイズという）を記録保持する機能を有する。前回ＲＷＩＮ記憶部５１は、記録保持する前回ウィンドウサイズをウィンドウサイズ算出部４８へ渡し、ウィンドウサイズ算出部４８が算出した結果を受け取り、前回ウィンドウサイズを更新し記録保持を行う。
図１０は、本実施の形態におけるデータパケットとＡＣＫパケットのやり取りを示したシーケンス図である。図１０の例では、受信側装置３１が送信するＡＣＫパケット、もしくは、ウィンドウ更新通知パケットを破線で示し、送信側装置３８が送信するデータパケットを実線で示している。また、１パケット長を１、更新量を４、更新間隔（上述の所定間隔）をＴミリ秒、として説明をする。さらに、図中のＰ７１（Ａｃｋ＝１０，Ｗｉｎ＝４）は、ＡＣＫ番号１０およびウィンドウサイズ４のＡＣＫパケットであることを示し、Ｐ８１（Ｓｅｑ＝１０，１１，１２，１３）は、シーケンス番号１０、１１、１２、１３のデータパケットであることを示している。
受信側装置３１は、送信側装置３８とコネクションの確立などを経て、送信側装置３８から送信されるデータを受信する状態となる。このとき、受信側装置３１は、更新量４をＡＣＫパケット（ウィンドウ更新通知パケットでも良い）のウィンドウサイズとして設定し、そのＡＣＫパケット（ウィンドウ更新通知パケット）を送信側装置３８へ通知している（Ｐ７１）。ＡＣＫパケットＰ７１を受信した送信側装置３８は、受信したＡＣＫパケットＰ７１のウィンドウサイズが４であることから、シーケンス番号１０、１１、１２、１３の４個のデータパケットＰ８１を送信する（Ｐ８１）。
次に、受信側装置３１は、ＡＣＫパケットＰ７１を送信後、所定間隔のＴミリ秒が経過すると、式１に従い、前回通知したウィンドウサイズ４に、更新量４を加算し、８をウィンドウ更新通知パケットのウィンドウサイズに設定し、そのウィンドウ更新通知パケットを送信側装置３８へ通知する（Ｐ７２）。ＡＣＫパケットＰ７２を受信した送信側装置３８は、受信したＡＣＫパケットＰ７２のウィンドウサイズが８であることから、既に送信済みシーケンス番号１０、１１、１２、１３を含めて８個のデータパケットを送信することが可能となる。そのため、送信側装置３８は、データパケットＰ８１の続きであるシーケンス番号１４、１５、１６、１７のデータパケットＰ８２を送信する。
以降、ＡＣＫパケットＰ７３、Ｐ７４も上述と同様に受信側装置３１から送信される。また、データパケットＰ８３、Ｐ８４も上述と同様に送信側装置３８から送信される。
このとき、受信側装置３１が送信するＡＣＫパケットの間隔は、Ｔミリ秒間隔であるため、送信側装置３８がＡＣＫパケットを受信する間隔もＴミリ秒間隔となる。さらに、送信側装置３８が受信するＡＣＫパケット間隔がＴミリ秒間隔であり、更新量ずつウィンドウサイズが増加しているため、送信側装置３８は、Ｔミリ秒間隔で、更新量ずつのデータパケットを送信することとなる。
受信側装置３１は、送信側装置３８がＴミリ秒間隔で、データパケットを送信するため、Ｔミリ秒間隔で更新量ずつのデータパケットを受信することとなる。なお、このＴミリ秒は、（式４）または、（式６）などから算出した値であるため、このＴミリ秒の間に、受信側装置３１は、更新量分のデータを処理することが可能である。よって、受信処理が溢れることなく受信処理を行うことが可能である。
このように本実施の形態では、送信側装置３８から送信される送信データの間隔とその量を、受信側装置３１で制御することにより、受信側装置３１の最大限の性能を引き出すことが可能となる。また、本発明により、この送信データの間隔とその量の制御を、データパケットの受信によらず任意のタイミングで開始することが可能である。さらに、更新量の単位で送信データ量を制御することで、ウィンドウ更新通知パケットの生成回数を減らし、ウィンドウ更新通知パケットのＡＣＫ番号も同一のものを使用する。その結果、一連のウィンドウ更新通知パケットで変更すべきパラメータはウィンドウサイズだけであるため、処理負荷を軽減することが可能となる。例えば、ＲＷＩＮ＿ＭＡＸを３２、更新量を４、ＲＴＴを１０ミリ秒としたとき、本実施の形態では、ウィンドウ更新通知パケットの送信間隔は、１．４２ミリ秒となる。一方、特許文献１では、ＡＣＫ分割を行い１ＭＳＳずつ受信可能な空きバッファ容量を更新する方式を使用するため、０．３２ミリ秒間隔で制御する必要がある。したがって、本実施の形態では、従来と比べて処理負荷を軽減できる。さらに、送信側装置３８から送信される送信データの間隔とその量を、受信側装置３１のアプリケーションの受信レートにあったレートに制御することができ、受信バッファには、最大でも更新量分のデータしか滞留せず、メモリ効率も良くなる。
（実施の形態２）
本実施の形態における通信装置（受信側装置）は、実施の形態１の図８に示す構成と略同様であって、処理部のみが異なる。したがって、処理部以外の構成要素についての詳細な説明は省略する。
図１１は、本実施の形態の受信側装置３１における処理部の機能構成の一例を示す構成図である。本実施の形態の受信側装置３１は、実施の形態１の処理部３３の代わりに処理部３３ａを備える。以降、各構成要素の機能に関して説明を行う。なお、本実施の形態における処理部３３ａは、実施の形態１の処理部３３に対して付加的な機能を有するため、実施の形態１との差分のみを説明する。
処理部３３ａは、ＩＰ処理部６１、ＴＣＰ処理部６２およびアプリケーション処理部６３を備える。
また、本実施の形態の受信側装置３１のＴＣＰ処理部６２は、ＴＣＰパケット処理部６４、受信バッファ６７、ウィンドウサイズ算出部６８、ウィンドウ更新タイマ部６９、受信レート決定部７０、および前回ＲＷＩＮ記憶部７１から構成される。ここで、受信バッファ６７、ウィンドウサイズ算出部６８および前回ＲＷＩＮ記憶部７１は、実施の形態１の受信バッファ４７、ウィンドウサイズ算出部４８および前回ＲＷＩＮ記憶部５１と同一の機能および構成を有する。
ＴＣＰパケット処理部６４は、ＡＣＫ生成部６５およびウィンドウ更新通知生成部６６を備える。このようなＴＣＰパケット処理部６４は、実施の形態１に示したＴＣＰパケット処理部４４の機能を有するとともに、通知するウィンドウサイズを（式１）に基づき更新している最中に、送信側装置３８からのパケットを受信したら、ウィンドウ更新通知機能を停止することを受信レート決定部７０に通知する機能をさらに有する。なお、ウィンドウ更新通知機能とは、実施の形態１に示すように、所定間隔で、ウィンドウサイズを増加させて、その増加されたウィンドウサイズを示すウィンドウ更新通知パケットを送信側装置３８に送信することをいう。
ウィンドウ更新タイマ部６９は、実施の形態１に示したウィンドウ更新タイマ部４９の機能を有するとともに、受信レート決定部７０からの停止通知に基づきタイマ機能を停止する機能をさらに有する。
受信レート決定部７０は、実施の形態１に示した受信レート決定部５０の機能を有するとともに、ＴＣＰパケット処理部６４からの停止通知を受けて、ウィンドウ更新タイマ部６９を停止する機能と更新量を０とする機能とをさらに有する。
図１２は、本実施の形態におけるデータパケットとＡＣＫパケットのやり取りを示したシーケンス図である。図１２の例では、受信側装置３１が送信するＡＣＫパケット、もしくは、ウィンドウ更新通知パケットを破線で示し、送信側装置３８が送信するデータパケットを実線で示している。また、１パケット長を１、更新量を４、更新間隔（上述の所定間隔）をＴミリ秒、として説明をする。さらに、図中のＰ９１（Ａｃｋ＝１０，Ｗｉｎ＝４）は、ＡＣＫ番号１０およびウィンドウサイズ４のＡＣＫパケットであることを示し、Ｐ１０１（Ｓｅｑ＝１０，１１，１２，１３）は、シーケンス番号１０、１１、１２、１３のデータパケットであることを示している。
受信側装置３１がＡＣＫパケットＰ９４を送信するまでと、送信側装置３８がデータパケットＰ１０４を送信するまでは、受信側装置３１および送信側装置３８におけるデータ送受信処理は、実施の形態１と同様である。したがって、受信側装置３１が、ＡＣＫパケットＰ９５を送信する処理、すなわち１ＲＴＴ経過後の処理から説明する。
１ＲＴＴ経過後、受信側装置３１は、データパケットＰ１０１を受信する。受信側装置３１は、データパケットＰ１０１を受信すると、データパケットＰ１０１に対するＡＣＫパケットＰ９５を生成し、送信側装置３８へ送信する。また、データパケットＰ１０１を受信すると受信レート決定部７０は、ウィンドウ更新タイマ部６９のウィンドウ更新タイマを停止し、ウィンドウサイズ算出部６８での更新量を０に設定する。そのため、送信するＡＣＫパケットＰ９５のウィンドウサイズは、前回ＲＷＩＮ記憶部７１が保持するウィンドウサイズ値である１６となる。
このＡＣＫパケットＰ９５を受信した送信側装置３８は、ＡＣＫ番号１４およびウィンドウサイズ１６から、シーケンス番号１４以降のデータをウィンドウサイズ１６分送信することができる。そこで、送信側装置３８は、シーケンス番号１４以降の未送信データであるシーケンス番号２６、２７、２８、２９のデータパケットＰ１０５を送信する。
次に、受信側装置３１が、データパケットＰ１０２を受信したときの処理に関して説明する。データパケットＰ１０２受信時には、ウィンドウ更新タイマは停止しており、更新量は０となっている。そのため、データパケットＰ１０２に対するＡＣＫパケットＰ９６のウィンドウサイズは、前回ＲＷＩＮ記憶部７１が保持するウィンドウサイズ値である１６となる。また、このＡＣＫパケットＰ９６を受信した送信側装置３８は、シーケンス番号１８以降の未送信データであるシーケンス番号３０、３１、３２、３３のデータパケットＰ１０６を送信する。以降、同様に処理を繰り返す。
図１３は、本実施の形態における受信側装置３１の動作を示すフローチャートである。
まず、受信側装置３１は、送信側装置３８との間でコネクションを確立し、送信側装置３８から送信されるデータを受信し得る状態になる。そして、受信側装置３１は、ウィンドウ更新通知機能を開始する（ステップＳ４００）。つまり、受信側装置３１は、ＡＣＫ番号＝Ｎおよびウィンドウサイズ＝更新量を示すＡＣＫパケットまたはウィンドウ更新通知パケットを生成して、送信側装置３８に送信する。なお、Ｎは、受信側装置３１が要求するデータパケットのシーケンス番号である。また、このとき受信側装置３１のウィンドウ更新タイマ部４９は時間計測を開始する。
次に、受信側装置３１は、受信側装置３８からデータパケットを受信したか否かを判別する（ステップＳ４０２）。ここで、受信側装置３８からデータパケットを受信していないと判別したときには（ステップＳ４０２のＮ）、さらに、受信側装置３１は、所定期間であるＴミリ秒が経過したか否かを判別する（ステップＳ４０４）。
受信側装置３１は、Ｔミリ秒が経過したと判別すると（ステップＳ４０４のＹ）、ＡＣＫ番号＝Ｎおよびウィンドウサイズ＝前回のウィンドウサイズ＋更新量を示すウィンドウ更新通知パケットを生成して、送信側装置３８に送信する（ステップＳ４０６）。一方、Ｔミリ秒が経過していないと判別したとき（ステップＳ４０４のＮ）や、ステップＳ４０６でウィンドウ更新通知パケットの送信が終了したときには、受信側装置３１は、再びステップＳ４０２からの処理を実行する。
また、受信側装置３１は、ステップＳ４０２でデータパケットを受信したと判別すると（ステップＳ４０２のＹ）、上述のウィンドウ更新通知機能を停止する（ステップＳ４０８）。つまり、ウィンドウ更新タイマ部４９は時間計測を停止し、更新量は０にリセットされる。さらに、受信側装置３１は、送信側装置３８から送信されて受信されたデータパケットに対する確認応答として、ＡＣＫ番号＝Ｎ＋ｎおよびウィンドウサイズ＝前回のウィンドウサイズを示すＡＣＫパケットを生成して、送信側装置３８に送信する（ステップＳ４１０）。なお、ｎは、受信側装置３１で受信されたデータパケットの数である。
そして、受信側装置３１は、再び、送信側装置３８からデータパケットを受信したか否かを判別する（ステップＳ４１２）。その結果、データパケットを受信したと判別したときには（ステップＳ４１２のＹ）、受信側装置３１は、ステップＳ４１０からの処理を繰り返し実行し、データパケットを受信していないと判別したときには（ステップＳ４１２のＮ）、送信側装置３８からのデータの受信処理を終了する。
このように本実施の形態では、実施の形態１と同様の効果を得ることができるとともに、１ＲＴＴ経過後に受信レート決定部７０が更新量を０にしてウィンドウ更新タイマを停止することで、データ受信後も送信側装置３８から送信される送信データのレートを一定に保つことが可能となる。
（実施の形態３）
本実施の形態における通信装置（受信側装置）は、実施の形態１の図８に示す構成と略同様であって、処理部のみが異なる。したがって、処理部以外の構成要素についての詳細な説明は省略する。
図１４は、本実施の形態の受信側装置３１における処理部の機能構成の一例を示す構成図である。本実施の形態の受信側装置３１は、実施の形態１の処理部３３の代わりに処理部３３ｂを備える。以降、各構成要素の機能に関して説明を行う。なお、本実施の形態における処理部３３ｂは、実施の形態２の処理部３３ａに対して付加的な機能を有するため、実施の形態２との差分のみを説明する。
処理部３３ｂは、ＩＰ処理部８１、ＴＣＰ処理部８２およびアプリケーション処理部８３を備える。
また、本実施の形態の受信側装置３１のＴＣＰ処理部８２は、ＴＣＰパケット処理部８４、受信バッファ８７、ウィンドウサイズ算出部８８、ウィンドウ更新タイマ部８９、受信レート決定部９０、および前回ＲＷＩＮ記憶部９１から構成される。ここで、受信バッファ８７および前回ＲＷＩＮ記憶部９１は、実施の形態１の受信バッファ４７および前回ＲＷＩＮ記憶部５１と同一の機能および構成を有する。
ＴＣＰパケット処理部８４は、ＡＣＫ生成部８５およびウィンドウ更新通知生成部８６を備える。このようなＴＣＰパケット処理部８４は、実施の形態２に示したＴＣＰパケット処理部６４の機能を有するとともに、ウィンドウ更新通知機能が停止している最中に、送信側装置３８からのパケットを受信したら、受信レート決定部９０にウィンドウ更新通知機能再開を通知する機能を有する。
ウィンドウサイズ算出部８８は、実施の形態１および２に示したウィンドウサイズ算出部４８，６８の機能を有する。さらに、ウィンドウサイズ算出部８８は、１連のデータ受信における総データ量をアプリケーション処理部８３から通知される機能を有する場合は、総データ量だけのデータの受信の終了に合わせてＡＣＫパケットで通知するウィンドウサイズを減少させる機能を有する。
ウィンドウ更新タイマ部８９は、実施の形態２に示したウィンドウ更新タイマ部６９の機能と、受信レート決定部９０からのウィンドウ更新通知機能再開の通知を受け、ウィンドウ更新通知機能を再開する機能を有する。
受信レート決定部９０は、実施の形態２に示した受信レート決定部７０の機能と、ＴＣＰパケット処理部８４からのウィンドウ更新通知機能再開の通知を受け、所定間隔と更新量の算出を行い、ウィンドウ更新タイマ部８９にウィンドウ更新通知機能再開の通知を行う機能を有する。
図１５は、本実施の形態におけるデータパケットとＡＣＫパケットのやり取りを示したシーケンス図である。図１５の例では、受信側装置３１が送信するＡＣＫパケット、もしくは、ウィンドウ更新通知パケットを破線で示し、送信側装置３８が送信するデータパケットを実線で示している。また、１パケット長を１、更新量を４、更新間隔（上述の所定間隔）をＴミリ秒、として説明をする。さらに、図中のＰ１１１（Ａｃｋ＝６，Ｗｉｎ＝８）は、ＡＣＫ番号６およびウィンドウサイズ８のＡＣＫパケットであることを示し、Ｐ１２１（Ｓｅｑ＝２，３，４，５）は、シーケンス番号２、３、４、５のデータパケットであることを示している。
送信側装置３８は、データパケットＰ１２１、Ｐ１２２を送信することで、一旦データ転送を終える。その後、任意の時間を空けてデータパケットＰ１２３の転送を再開する。このときのＡＣＫパケットとデータパケットのやり取りを説明する。
まず、送信側装置３８がデータパケットＰ１２２で転送を一旦終了するときに関して説明する。
ウィンドウサイズ算出部８８は、１連のデータ受信における総データ量をアプリケーション処理部８３から通知されている。そこで、ウィンドウサイズ算出部８８は、総データ量だけのデータの受信の終了に合わせて、送信するＡＣＫパケットのウィンドウサイズを減少させる。（式９）は、ウィンドウサイズ算出部８８におけるウィンドウサイズ算出式を示している。
ウィンドウサイズ＝ＭＩＮ（（総データ量−受信データ量）＋更新量，
前回ＲＷＩＮ記憶部が保持するウィンドウサイズ）・・・（式９）
すなわち、
ウィンドウサイズ＝ＭＩＮ（残りの受信データ量＋更新量，
前回ＲＷＩＮ記憶部が保持するウィンドウサイズ）・・・（式１０）
となる。
なお、総データ量にあわせて、
ウィンドウサイズ＝ＭＩＮ（総データ量−受信データ量，
前回ＲＷＩＮ記憶部が保持するウィンドウサイズ）・・・（式１１）
としても良い。（式１１）とした場合は、送信側装置３８からデータ送信が再開される際、受信側装置３１の受信バッファに空きが存在するか確認するプルーブパケットからデータ送信が始まることとなる。
図１５において、送信側装置３８は、データパケットＰ１２１を送信する。データパケットＰ１２１を受信した受信側装置３１は、データパケットＰ１２１に対応するＡＣＫパケットＰ１１１を生成し、送信する。このとき受信側装置３１が送信するデータパケットは、（式９）に基づき、ウィンドウサイズ８と設定される。次に、送信側装置３８は、データパケットＰ１２２を送信する。データパケットＰ１２２を受信した受信側装置３１は、データパケットＰ１２２に対応するＡＣＫパケットＰ１１２を生成し、送信する。このとき受信側装置３１が送信するデータパケットは、（式９）に基づき、ウィンドウサイズ４と設定される。このように、残り受信データ量に合わせてウィンドウサイズを減少させていく。
次に、送信側装置３８がデータ送信を再開した以降、すなわちデータパケットＰ１２３を送信した以降で説明する。
送信側装置３８は、データパケットＰ１２３を送信し、データ送信を再開する。このとき、受信側装置３１が前回送信したＡＣＫパケットＰ１１２のウィンドウサイズが４であったことから、送信側装置３８は、シーケンス番号１０、１１、１２、１３とウィンドウサイズ分のデータパケットを送信することになる。このように、データ送信が一旦停止する際に、ウィンドウサイズを減少させていたことで、データ送信再開の際に、バースト的に送信データが到着することを防止している。
次に、受信側装置３１は、送信側装置３８が送信再開をしたデータパケットＰ１２３を受信すると、受信したデータパケットＰ１２３に対応するＡＣＫパケットＰ１１３を生成し、送信する。その後、受信側装置３１は、受信レート決定部９０にデータ転送が再開されたことを通知する。通知を受けた受信レート決定部９０は、実施の形態１と同様に、更新量と所定間隔を決定し、ウィンドウ更新タイマ部８９にウィンドウ更新タイマの再開を促す。その結果、ＡＣＫパケットＰ１１３を送信後、所定間隔のＴミリ秒が経過すると、受信側装置３１は、（式１）に従い、前回通知したウィンドウサイズ４に、更新容量４を加算し、８をウィンドウ更新通知パケットのウィンドウサイズに設定し、そのウィンドウ更新通知パケットを送信側装置３８へ通知する（Ｐ１１４）。さらに、受信側装置３１は、所定間隔のＴミリ秒間隔で、ウィンドウ更新通知パケットＰ１１５、Ｐ１１６を送信していく。これにより、送信側装置３８では、所定間隔のＴミリ秒間隔で、データパケットＰ１２４、Ｐ１２５、Ｐ１２６を送信することとなる。
このように本実施の形態では、実施の形態１および２と同様の効果を得ることができる。さらに、本実施の形態では、データ転送が一旦停止した際にも、ウィンドウサイズを減少させてウィンドウ更新通知機能を再開することで、送信側装置からの送信が一旦停止した後の再開した送信データの送信レートを制御することも可能となる。
（実施の形態４）
本実施の形態における通信装置（受信側装置）は、実施の形態１の図８に示す構成と略同様であって、処理部のみが異なる。したがって、処理部以外の構成要素についての詳細な説明は省略する。
また、本実施の形態の受信側装置３１における処理部は、実施の形態２の図１１に示す処理部３３ａと略同様の構成を有する。したがって、本実施の形態における処理部について、図１１を用い、実施の形態２との違いが明確になるように以下説明する。
本実施の形態におけるＴＣＰパケット処理部６４は、実施の形態２に示した機能を有するとともに、ウィンドウ更新通知機能が停止している最中に、パケットロスを検知し、送信側装置３８からのロスしたパケットの再送を確認したら、受信レート決定部７０にウィンドウ更新通知機能再開を通知する機能を有する。
本実施の形態におけるウィンドウ更新タイマ部８９は、実施の形態２に示した機能を有するとともに、受信レート決定部７０からのウィンドウ更新通知機能再開の通知を受け、ウィンドウ更新タイマ機能を再開する機能を有する。
受信レート決定部７０は、実施の形態２に示した機能を有する。さらに、受信レート決定部７０は、ＴＣＰパケット処理部６４からのウィンドウ更新通知機能再開の通知を受け、所定間隔と更新量の算出を行い、ウィンドウ更新タイマ部６９にウィンドウ更新通知機能再開の通知を行う機能と、前回ＲＷＩＮ記憶部７１に記録されている前回ウィンドウサイズ値を初期値、例えば０に戻す機能とを有する。
前回ＲＷＩＮ記憶部７１は、実施の形態２に示した機能と、受信レート決定部７０の働きにより、記憶している前回ウィンドウサイズ値が初期化される機能とを有する。
図１６は、本実施の形態におけるデータパケットとＡＣＫパケットのやり取りを示したシーケンス図である。図１６の例では、受信側装置３１が送信するＡＣＫパケット、もしくは、ウィンドウ更新通知パケットを破線で示し、送信側装置３８が送信するデータパケットを実線で示している。また、説明を簡略化するために、１パケット長を１、更新量を１、更新間隔（上述の所定間隔）をＴミリ秒、として説明をする。さらに、図中のＰ１３１（Ａｃｋ＝１１，Ｗｉｎ＝６）は、ＡＣＫ番号１１およびウィンドウサイズ６のＡＣＫパケットであることを示し、Ｐ１５１（Ｓｅｑ＝１０）は、シーケンス番号１０のデータパケットであることを示している。
受信側装置３１は、ウィンドウ更新通知機能を停止している状態で、一定間隔で、送信側装置３８からの送信データパケットを受信している。このとき、データパケットＰ１５２がパケットロスしたとして説明をする。
受信側装置３１は、データパケットＰ１５３の到着によりパケットロスが発生したことに気付く。そのため、受信側装置３１は、ＡＣＫ番号１１のＡＣＫパケットＰ１３３を送信する。その後も、受信側装置３１は、同様にパケットロス以降のデータパケットＰ１５４、Ｐ１５５、Ｐ１５６を受信し、パケットロスが発生しているため、ＡＣＫ番号１１のＡＣＫパケットＰ１３４、Ｐ１３５、Ｐ１３６を送信する。このとき、送信側装置３８は、重複したＡＣＫ番号のＡＣＫパケットを４連続で受信すると、ネットワーク上でパケットロスが発生したと検知し、タイムアウトを待たずに即座に、データパケットＰ１５８を再送する（ＴＣＰ高速再送機能）。ここまでは、従来のＴＣＰでも、実装されている機能である。
次に、ＴＣＰ高速再送機能により、データパケットＰ１５８が再送処理された以降の説明をする。
受信側装置３１では、再送されたデータパケットＰ１５８が受信されると、ＴＣＰパケット処理部６４は、受信レート決定部７０へ、パケットロスが発生して再送パケットを受信したことを通知する。再送パケットを受信したことを通知された受信レート決定部７０は、前回ＲＷＩＮ記憶部７１の値を初期化し、ウィンドウ更新タイマ部６９にウィンドウ更新タイマの起動を促し、更新量を１とし、ウィンドウ更新通知機能を再開する。その後、受信側装置３１は、ＡＣＫパケットＰ１３８を生成し、送信する。このとき生成されるＡＣＫパケットＰ１３８は、現在受信しているシーケンス番号１６から、ＡＣＫ番号１７を設定し、前回ＲＷＩＮ記憶部７１に記録されている値と更新量を元にウィンドウサイズ１が設定される。このＡＣＫパケットＰ１３８を受信した送信側装置３１は、通知されたウィンドウサイズ１に基づき、続きのシーケンス番号１７のデータパケットＰ１５９を送信する。
次に、受信側装置３１は、ＡＣＫパケットＰ１３８を送信後、所定間隔のＴミリ秒が経過すると、（式１）に従い、前回通知したウィンドウサイズ１に、更新容量１を加算し、２をウィンドウ更新通知パケットのウィンドウサイズに設定し、そのウィンドウ更新通知パケットを送信側装置３８へ通知する（Ｐ１３９）。ＡＣＫパケットＰ１３９を受信した送信側装置３８は、受信したＡＣＫパケットＰ１３９のウィンドウサイズが２であることから、既に送信済みシーケンス番号１７を含めて２個のデータパケットを送信することが可能となる。そのため、送信側装置３８は、データパケットＰ１５９の続きであるシーケンス番号１８のデータパケットＰ１６０を送信する。以降、受信側装置３１は、実施の形態１と同様にＴミリ秒間隔で、ウィンドウ更新処理を行い、Ｔミリ秒間隔で、データパケットを受信することになる。
このように本実施の形態では、実施の形態１および２と同様の効果を得ることができる。さらに、本実施の形態では、パケットロス発生後も、ウィンドウ更新通知機能を再開させることによって、送信側装置の再送データに関しても送信レート制御を行うことが可能となる。また、実施の形態３と組み合わせることにより、実施の形態３で得られる効果も享受することができる。
（実施の形態５）
本実施の形態における通信装置（受信側装置）は、実施の形態１の図８に示す構成と略同様であって、処理部のみが異なる。したがって、処理部以外の構成要素についての詳細な説明は省略する。
図１７は、本実施の形態の受信側装置３１における処理部の機能構成の一例を示す構成図である。本実施の形態の受信側装置３１は、実施の形態１の処理部３３の代わりに処理部３３ｃを備える。以降、各構成要素の機能に関して説明を行う。なお、本実施の形態における処理部３３ｃは、実施の形態２の処理部３３ａに対して付加的な機能を有するため、実施の形態２との差分のみを説明する。
処理部３３ｃは、ＩＰ処理部１０１、ＴＣＰ処理部１０２およびアプリケーション処理部１０３を備える。
また、本実施の形態の受信側装置３１のＴＣＰ処理部１０２は、ＴＣＰパケット処理部１０４、受信バッファ１０７、ウィンドウサイズ算出部１０８、ウィンドウ更新タイマ部１０９、受信レート決定部１１０、前回ＲＷＩＮ記憶部１１１、およびＡＣＫ遅延部１１２から構成される。ここで、受信バッファ１０７、ウィンドウサイズ算出部１０８、ウィンドウ更新タイマ部１０９、および前回ＲＷＩＮ記憶部１１１は、実施の形態２の受信バッファ６７、ウィンドウサイズ算出部６８、ウィンドウ更新タイマ部６９および前回ＲＷＩＮ記憶部７１と同一の機能および構成を有する。
ＴＣＰパケット処理部１０４は、ＡＣＫ生成部１０５およびウィンドウ更新通知生成部１０６を備える。ウィンドウ更新通知生成部１０６は、実施の形態２のウィンドウ更新通知生成部６６と同様の機能および構成を有する。
ＡＣＫ生成部１０５は、実施の形態１〜４のＡＣＫ生成部と同様、受信したＴＣＰパケットのシーケンス番号に基づいて、ＡＣＫ番号を決定し、ＡＣＫパケットを生成する。ＡＣＫパケットには、ウィンドウサイズ算出部１０８から得た、現在受信可能な空き容量であるウィンドウサイズも設定される。さらに、本実施の形態のＡＣＫ生成部１０５は、生成したＡＣＫパケットをＡＣＫ遅延部１１２へ渡す。渡されたＡＣＫパケットは、その後送信される。
受信レート決定部１１０は、実施の形態２の受信レート決定部７０と同様の機能を有するとともに、ＡＣＫ遅延部１１２にＡＣＫパケット遅延時間とそのＡＣＫ量とを指定する機能を有する。ＡＣＫパケット遅延時間およびＡＣＫ量は、次の式で決定される。
ＡＣＫ量＝更新量・・・（式１２）
ＡＣＫパケット遅延時間＝更新間隔（上述の所定間隔）・・・（式１３）
なお、ＡＣＫ量およびＡＣＫパケット遅延時間は、更新量および更新間隔を算出する式と同様に、ＦＩＦＯ３６の容量や、システムバス３２の転送能力から算出したり、アプリケーションが要求するビットレートから算出したりすることができる。
ＡＣＫ遅延部１１２は、生成されたＡＣＫパケットを送信前に一時的に保持し、遅延させる機能を有する。ＡＣＫ遅延時間は、受信レート決定部１１０により決定される。
図１８は、本実施の形態におけるデータパケットとＡＣＫパケットのやり取りを示したシーケンス図である。図１８の例では、受信側装置３１が送信するＡＣＫパケット、もしくは、ウィンドウ更新通知パケットを破線で示し、送信側装置３８が送信するデータパケットを実線で示している。また、１パケット長を１、更新量を４、更新間隔（上述の所定間隔）をＴミリ秒、として説明をする。さらに、図中のＰ１７５（Ａｃｋ＝１４，Ｗｉｎ＝１６）は、ＡＣＫ番号１４、ウィンドウサイズ１６のＡＣＫパケットであることを示し、Ｐ１８３（Ｓｅｑ＝１８，１９，２０，２１）は、シーケンス番号１８、１９、２０、２１のデータパケットであることを示している。
受信側装置３１は、実施の形態２と同様に、ウィンドウ更新通知機能を開始後、１ＲＴＴが経過し、データパケットＰ１８１を受信したために、ウィンドウ更新通知機能を停止している状態である。
受信側装置３１のＡＣＫ生成部１０５は、データパケットＰ１８１が受信されるとそのＡＣＫパケットを生成し、ＡＣＫ遅延部１１２へ渡す。ＡＣＫパケットを受け取ったＡＣＫ遅延部１１２は、前回ＡＣＫパケット（または、ウィンドウ更新通知パケット）を送信した時刻にＡＣＫパケット遅延時間を加算したＡＣＫ送信時刻を求め、現在時刻がＡＣＫ遅延時刻を越えているかつ、ＡＣＫ番号が前回ＡＣＫパケットに比べＡＣＫ量分進んでいるのなら、即座にＡＣＫパケットを送信する。図１８では、データパケットＰ１８１が受信された時点で、前回ＡＣＫパケット送信時刻からＡＣＫパケット遅延時間が経過しているので、即座にＡＣＫパケットＰ１７５は送信されている。
ここで、送信側装置３８が送信したデータパケットＰ１８２がネットワーク３７の状況変化により通常よりも早く受信されたとする。受信側装置３１のＡＣＫ生成部１０５は、受信したデータパケットＰ１８２に対するＡＣＫパケットを生成し、ＡＣＫ遅延部１１２へ渡す。ＡＣＫパケットを受け取ったＡＣＫ遅延部１１２は、前回ＡＣＫパケットＰ１７５の送信時刻にＡＣＫ遅延時間を加算したＡＣＫ送信時刻を求めた結果、ＡＣＫ送信時刻に現在時刻が満たないので、即座にＡＣＫパケットＰ１７６の送信を行わない。その後、ＡＣＫ遅延部１１２は、ＡＣＫ送信時刻に現在時刻が達すると、ＡＣＫ遅延部１１２で保留していたＡＣＫパケットＰ１７６を送信する。
図１９は、本実施の形態におけるデータパケットとＡＣＫパケットの他のやり取りを示したシーケンス図である。図１９の例では、受信側装置３１が送信するＡＣＫパケット、もしくは、ウィンドウ更新通知パケットを破線で示し、送信側装置３８が送信するデータパケットを実線で示している。また、１パケット長を１、更新量を４、更新間隔（上述の所定間隔）をＴミリ秒、として説明をする。
受信側装置３１は、実施の形態２と同様に、ウィンドウ更新通知機能を開始後、１ＲＴＴが経過し、データパケットＰ２０１を受信したために、ウィンドウ更新通知機能を停止している状態である。
受信側装置３１のＡＣＫ生成部１０５は、データパケットＰ２０１が受信されるとそのＡＣＫパケットを生成し、ＡＣＫ遅延部１１２へ渡す。ＡＣＫパケットを受け取ったＡＣＫ遅延部１１２は、前回ＡＣＫパケット（または、ウィンドウ更新通知パケット）を送信した時刻にＡＣＫパケット遅延時間を加算したＡＣＫ送信時刻を求め、現在時刻がＡＣＫ遅延時刻を越えているかつ、ＡＣＫ番号が前回ＡＣＫパケットに比べＡＣＫ量分進んでいるのなら、即座にＡＣＫパケットを送信する。図１９では、データパケットＰ２０１が受信された時点で、前回ＡＣＫパケット送信時刻からＡＣＫパケット遅延時間が経過しているので、即座にＡＣＫパケットＰ１９５は送信されている。
ここで、送信側装置３８が送信したデータパケットＰ２０２がネットワーク３７の状況変化により通常より遅延して受信されたとする。受信側装置３１のＡＣＫ生成部１０５は、受信したデータパケットＰ２０２に対するＡＣＫパケットを生成し、ＡＣＫ遅延部１１２へ渡す。ＡＣＫパケットを受け取ったＡＣＫ遅延部１１２は、前回ＡＣＫパケットＰ１９５の送信時刻にＡＣＫ遅延時間を加算したＡＣＫ送信時刻を求めた結果、すでに現在時刻がＡＣＫ送信時刻を経過しているので、即座にＡＣＫパケット１９６の送信を行う。つまり、図１９では、前回ＡＣＫパケットＰ１９５の送信時刻からＡＣＫパケット遅延時間を十分に経過しているので、即座にＡＣＫパケットＰ１９６は送信されている。
さらに、受信側装置３１は、送信側装置３８が送信したデータパケットＰ２０３を受信する。受信側装置３１は、受信したデータパケットＰ２０３に対するＡＣＫパケットを生成し、ＡＣＫ遅延部１１２へ渡す。ＡＣＫパケットを受け取ったＡＣＫ遅延部１１２は、前回ＡＣＫパケットＰ１９６の送信時刻にＡＣＫ遅延時間を加算したＡＣＫ送信時刻を求めた結果、ＡＣＫ送信時刻に現在時刻が満たないため、ＡＣＫパケット１９７の送信を行わない。その後、ＡＣＫ遅延部１１２は、ＡＣＫ送信時刻に現在時刻が達すると、ＡＣＫ遅延部１１２で保留していたＡＣＫパケットＰ１９７を送信する。以降も、ＡＣＫ遅延部１１２は、ＡＣＫ送信時刻を確認し、ＡＣＫパケットＰ１９８、Ｐ１９９の送信を行う。そして、ＡＣＫパケットＰ２００の時点で、データパケット到着間隔が所定間隔に戻ったため、即座にＡＣＫパケットが送信されるようになる。
このように本実施の形態では、実施の形態１および２と同様の効果を得ることができる。さらに、本実施の形態では、ネットワークの揺らぎによって、データパケットの到着間隔に変化が生じたとしても、ＡＣＫパケットの送信間隔を制御することによって、送信側装置の送信レート制御を行うことが可能となる。また、本実施の形態を実施の形態３または４と組み合わせることにより、実施の形態３または４で得られる効果も享受することができる。
（実施の形態６）
本実施の形態における通信装置（受信側装置）は、実施の形態１の図８に示す構成と略同様であって、処理部のみが異なる。したがって、処理部以外の構成要素についての詳細な説明は省略する。
また、本実施の形態の受信側装置３１における処理部は、実施の形態５の図１７に示す処理部３３ｃと略同様の構成を有する。したがって、本実施の形態における処理部について、図１７を用い、実施の形態５との違いが明確になるように以下説明する。
図１７は、本発明の受信側装置３１におけるＴＣＰ処理部を中心とした処理構成例を示したものである。以降、各処理部の機能に関して説明を行う。なお、実施の形態５と構成例は、同じでありその機能に若干の差があるのみである。本実施の形態を説明する上では、実施の形態５との差分のみを説明する。
本実施の形態における受信レート決定部１１０は、実施の形態５に示した機能を有するとともに、受信レート変更の要求を受けて、ＡＣＫ遅延時間とＡＣＫ量を更新し、ＡＣＫ遅延部１１２へ通知する機能を有する。
本実施の形態におけるＡＣＫ遅延部１１２は、実施の形態５に示した機能を有するとともに、受信レート変更要求に基づき受信レート決定部１１０で決定された、ＡＣＫ遅延時間とＡＣＫ量とを受け取り、送信するＡＣＫパケットに反映する機能を有する。
図２０は、本実施の形態におけるデータパケットとＡＣＫパケットのやり取りを示したシーケンス図である。図２０の例では、受信側装置３１が送信するＡＣＫパケット、もしくは、ウィンドウ更新通知パケットを破線で示し、送信側装置３８が送信するデータパケットを実線で示している。また、ウィンドウ更新通知の開始後の、１ＲＴＴが経過するまでの１パケット長を１、更新量を４、更新間隔（上述の所定間隔）をＴミリ秒、として説明をする。さらに、図中のＰ２１１（Ａｃｋ＝１４，Ｗｉｎ＝１６）は、ＡＣＫ番号１４およびウィンドウサイズ１６のＡＣＫパケットであることを示し、Ｐ２２２（Ｓｅｑ＝１８，１９，２０，２１）は、シーケンス番号１８、１９、２０、２１のデータパケットであることを示している。
受信側装置３１は、データパケットＰ２２１を受信し、ＡＣＫパケットＰ２１２を送信する。ここまでは、受信側装置３１は、実施の形態５と同様のデータ送受信処理を行なう。その後、受信側装置３１は、図中の「受信レート変更」の時刻に受信レートを変更したくなったとする。本実施の形態では、受信間隔（上述の所定間隔）を２倍の２Ｔミリ秒と変更したいとする。このレート変更要求は、受信レート決定部１１０に通知される。受信レートの変更要求を受け取った受信レート決定部１１０は、受信間隔を２倍にしたいことから、ＡＣＫ遅延部１１２にＡＣＫパケット遅延時間を２倍とするように指示を出す。
その後、受信側装置３１がデータパケットＰ２２２を受信すると、ＡＣＫ生成部１０５はＡＣＫパケットを生成し、ＡＣＫ遅延部１１２へ渡す。ＡＣＫパケットを受け取ったＡＣＫ遅延部１１２は、前回のＡＣＫ送信時刻にＡＣＫパケット遅延時間を加算して、ＡＣＫパケット送信時刻を求める。このとき算出されるＡＣＫ送信時刻は、受信レート変更要求を受けずに算出されるＡＣＫ送信時刻よりも先となっている。そのため、データパケットＰ２２２が受信された時点において、現在時刻がＡＣＫ送信時刻に達していないので、受信側装置３１のＡＣＫ遅延部１１２は、即座にＡＣＫ送信を行わない。
さらに、受信側装置３１がデータパケットＰ２２３を受信すると、ＡＣＫ生成部１０５はＡＣＫパケットを生成し、ＡＣＫ遅延部１１２へ渡す。ＡＣＫパケットを受け取ったＡＣＫ遅延部１１２は、前回のＡＣＫ送信時刻にＡＣＫパケット遅延時間を加算して、ＡＣＫパケット送信時刻を求める。その結果、データパケットＰ２２３が受信された時点において、現在時刻がＡＣＫ送信時刻に達しているので、ＡＣＫ遅延部１１２は即座にＡＣＫ送信を行う。また、このときＡＣＫ遅延部１１２は、前のデータパケットＰ２２２に対するＡＣＫパケットが保留されているため、その保留分のデータ量４をウィンドウサイズから減算して、ウィンドウサイズ１２としてＡＣＫパケットＰ２１３の送信を行う。以降同様に、受信側装置３１はデータパケットＰ２２４、Ｐ２２５の受信処理を行い、ＡＣＫパケットＰ２１４の送信を行う。このようにして、送信側装置３８が送信するデータパケットの送信間隔を２倍に変更することが可能である。
図２１は、本実施の形態におけるデータパケットとＡＣＫパケットの他のやり取りを示したシーケンス図である。図２１の例では、受信側装置３１が送信するＡＣＫパケット、もしくは、ウィンドウ更新通知パケットを破線で示し、送信側装置３８が送信するデータパケットを実線で示している。また、ウィンドウ更新通知の開始後の、１ＲＴＴが経過するまでの１パケット長を１、更新量を４、更新間隔（上述の所定間隔）をＴミリ秒、として説明をする。
受信側装置３１は、データパケットＰ２４１を受信し、ＡＣＫパケットＰ２３２を送信する。ここまでは、受信側装置３１は、実施の形態５と同様のデータ送受信処理を行なう。その後、受信側装置３１は、図中の「受信レート変更」の時刻に受信レートを変更したくなったとする。本実施の形態では、更新量を２分の１に変更したいとする。このレート変更要求は、受信レート決定部１１０に通知される。受信レート変更要求を受け取った受信レート決定部１１０は、更新量を２分の１にしたいことから、ＡＣＫ遅延部１１２に更新量を２分の１とするように指示を出す。すなわち、本実施の形態では、更新量が２に変更される。
その後、受信側装置３１がデータパケットＰ２４２を受信すると、ＡＣＫ生成部１０５はＡＣＫパケットを生成し、ＡＣＫ遅延部１１２へ渡す。ＡＣＫパケットを受け取ったＡＣＫ遅延部１１２は、前回のＡＣＫ送信時刻にＡＣＫパケット遅延時間を加算して、ＡＣＫパケット送信時刻を求める。このとき算出されるＡＣＫ送信時刻は、データパケットＰ２４２が受信された時点において現在時刻に達しているため、ＡＣＫ遅延部１１２は即座にＡＣＫパケットＰ２３３を送信する。しかし、受信レート変更要求によりＡＣＫ遅延部１１２の更新量は、２分の１となっている。そのため、現在送信しようとしているＡＣＫパケットのＡＣＫ量が、シーケンス番号１８、１９、２０、２１の４つ分であり、更新量が２であるから、ＡＣＫ遅延部１１２は、（式１４）に従いウィンドウサイズを１４に設定してＡＣＫパケットＰ２３３を送信する。
ウィンドウサイズ＝前回ＲＷＩＮ記憶部１１１が記憶するウィンドウサイズ
−（ＡＣＫ量−更新量）・・・（式１４）
同様に、受信側装置３１は、データパケットＰ２４３、Ｐ２４４、Ｐ２４５を受信するとウィンドウサイズを２ずつ減らしながら、ＡＣＫパケットＰ２３４、Ｐ２３５、Ｐ２３６を送信していく。
その後、受信側装置３１は、送信側装置３８からデータパケットＰ２４６を受信する。ここで、データパケットＰ２４６はシーケンス番号３４、３５の２つのデータ分であって、ＡＣＫ量＝２となる。したがって、受信側装置３１は、（式１４）に従い、前回のウィンドウサイズと同じ８のウィンドウサイズを示すＡＣＫパケットＰ２３７を送信することになる。このようにして、送信側装置３８が送信するデータパケットの送信量を２分の１に変更することが可能である。
このように本実施の形態では、実施の形態１、２および５と同様の効果を得ることができる。さらに、本実施の形態では、受信側装置の受信状況の変化に応じて、ＡＣＫ送信間隔やウィンドウサイズを制御することにより、送信側装置が送信するデータパケットの送信レートを動的に変更することが可能である。また、本実施の形態を実施の形態３または４と組み合わせることにより、実施の形態３または４で得られる効果も享受することができる。
（実施の形態７）
本実施の形態における通信装置（受信側装置）は、実施の形態１の図８に示す構成と略同様であって、処理部のみが異なる。したがって、処理部以外の構成要素についての詳細な説明は省略する。
図２２は、本実施の形態の受信側装置３１における処理部の機能構成の一例を示す構成図である。本実施の形態の受信側装置３１は、実施の形態１の処理部３３の代わりに処理部３３ｄを備える。以降、各構成要素の機能に関して説明を行う。なお、本実施の形態における処理部３３ｄは、実施の形態１の処理部３３に対して付加的な機能を有するため、実施の形態１との差分のみを説明する。
処理部３３ｄは、ＩＰ処理部１２１、ＴＣＰ処理部１２２およびアプリケーション処理部１２３を備える。
また、本実施の形態の受信側装置３１のＴＣＰ処理部１２２は、ＴＣＰパケット処理部１２４、受信バッファ１２７、ウィンドウサイズ算出部１２８、ウィンドウ更新タイマ部１２９、受信レート決定部１３０、および前回ＲＷＩＮ記憶部１３１から構成される。ここで、受信バッファ１２７、ウィンドウサイズ算出部１２８、ウィンドウ更新タイマ部１２９、および前回ＲＷＩＮ記憶部１３１は、実施の形態１の受信バッファ４７、ウィンドウサイズ算出部４８、ウィンドウ更新タイマ部４９および前回ＲＷＩＮ記憶部５１と同一の機能および構成を有する。
ＴＣＰパケット処理部１２４は、ＡＣＫ生成部１２５およびウィンドウ更新通知生成部１２６を備える。ＴＣＰパケット処理部１２４は、実施の形態１に示したＴＣＰパケット処理部４４の機能を有するとともに、受信レート決定部１３０から更新量が通知され、連続受信データパケットが更新量に達したとき、受信データパケットが更新量に達したことを受信レート決定部１３０に通知する機能をさらに有する。
受信レート決定部１３０は、実施の形態１に示した受信レート決定部５０の機能を有する。さらに、受信レート決定部１３０は、ＴＣＰパケット処理部１２４へ更新量を通知する機能と、連続受信データパケットが更新量に達したときに、受信データパケットが更新量に達したことを通知する通知をＴＣＰパケット処理部１２４から受け取る機能とを有する。さらに、受信レート決定部１３０は、更新量に達したことの通知を受け取ると、（式３）〜（式８）のいずれかの方法で更新量と所定間隔を算出し、ウィンドウサイズ算出部１２８とウィンドウ更新タイマ部１２９へその値を伝える。
図２３は、本実施の形態におけるデータパケットとＡＣＫパケットのやり取りを示したシーケンス図である。図２３の例では、受信側装置３１が送信するＡＣＫパケット、もしくは、ウィンドウ更新通知パケットを破線で示し、送信側装置３８が送信するデータパケットを実線で示している。また、１パケット長を１、更新量を４、更新間隔（上述の所定間隔）をＴミリ秒、として説明をする。さらに、図中のＰ２５１（Ａｃｋ＝２，Ｗｉｎ＝４）は、ＡＣＫ番号２およびウィンドウサイズ４のＡＣＫパケットであることを示し、Ｐ２６１（Ｓｅｑ＝１）は、シーケンス番号１のデータパケットであることを示している。
送信側装置３８は、送信データ量を徐々に増加させるスロースタートという機能を有している。そのため、送信側装置３８が送信する送信データパケットの数は、１ＲＴＴごとに、１パケット（Ｐ２６１）、２パケット（Ｐ２６２）、４パケット（Ｐ２６３）と増加している。データパケットＰ２６２が受信されるまでは、受信側装置３１では、送信側装置３８が連続に送信するデータパケットが更新量に達していないため、ウィンドウ更新通知機能は行われていない。
その後、受信側装置３１は、データパケットＰ２６３を受信する。データパケットＰ２６３を受信した受信側装置３１は、データパケットＰ２６３に対するＡＣＫパケットＰ２５３を生成し送信する。また、受信側装置３１では、ＴＣＰパケット処理部１２４が受信レート決定部１３０へ、更新量に達したことを通知する。更新量に達したことを通知された受信レート決定部１３０は、ウィンドウサイズ算出部１２８へ更新量（本実施の形態では４）を通知し、ウィンドウ更新タイマ部１２９へウィンドウ更新タイマの起動を促し、ウィンドウ更新通知機能を開始する。ＡＣＫパケットＰ２５３を受信した送信側装置３８は、受信したＡＣＫパケットＰ２５３のウィンドウサイズが４であることから、続きのシーケンス番号８、９、１０、１１を送信する。
次に、ウィンドウ更新通知機能を開始した受信側装置３１は、ＡＣＫパケットＰ２５３を送信後、所定間隔Ｔミリ秒経過すると、（式１）に従い、前回通知したウィンドウサイズ４に、更新量４を加算し、８をウィンドウ更新通知パケットのウィンドウサイズに設定し、そのウィンドウ更新通知パケットを送信側装置３８へ通知する（Ｐ２５４）。ＡＣＫパケットＰ２５４を受信した送信側装置３８は、受信したＡＣＫパケットＰ２５４のウィンドウサイズが８であることから、既に送信済みシーケンス番号８、９、１０、１１を含めて８個のデータパケットを送信することが可能となる。そのため、送信側装置３８は、データパケットＰ２６３の続きであるシーケンス番号１２、１３、１４、１５のデータパケットＰ２６４を送信する。
このように本実施の形態では、実施の形態１と同様の効果を得ることができるとともに、送信側装置がスロースタートを行う場合においても、受信側装置から送信側装置の送信レートを制御することができる。また、以下の図２４に示すデータ送受信処理であっても、上述と同様の効果を得ることができる。
図２４は、本実施の形態におけるデータパケットとＡＣＫパケットの他のやり取りを示したシーケンス図である。図２４の例では、受信側装置３１が送信するＡＣＫパケット、もしくは、ウィンドウ更新通知パケットを破線で示し、送信側装置３８が送信するデータパケットを実線で示している。また、１パケット長を１、更新量を４、更新間隔（上述の所定間隔）をＴミリ秒、として説明をする。
このとき、受信側装置３１と送信側装置３８とのデータ送受信処理は、データパケットＰ３４３が受信されるまで、図２３に示す処理と同様に行われる。次に、受信側装置３１では、データパケットＰ３４３が受信されると、ＴＣＰパケット処理部１２４は、受信レート決定部１３０へ、更新量に達したことを通知する。更新量に達したことを通知された受信レート決定部１３０は、ウィンドウサイズ算出部１２８へ更新量（本実施の形態では４）を通知し、ウィンドウ更新タイマ部１２９へウィンドウ更新タイマの起動を促し、ウィンドウ更新通知機能を開始する。
次に、ウィンドウ更新通知機能を開始した受信側装置３１は、次の式１４に則りウィンドウ更新を行う。
ウィンドウサイズ＝前回通知したウィンドウサイズ＋更新量−ＡＣＫ番号増加量 ・・・（式１４）
なお、本実施の形態では、前回通知したウィンドウサイズを４、更新量を４、ＡＣＫ番号増加量を１として説明する。
データパケットＰ３４３を受信した受信側装置３１は、ウィンドウ更新通知機能により、データパケット受信後、ＡＣＫパケットＰ３３３を送信側装置へと送信する。このときの、ＡＣＫパケットＰ３３３は、ＡＣＫ番号はＡＣＫ番号増加量１により、５となり、ウィンドウサイズは、（式１４）により、７となる。ＡＣＫパケットＰ３３３を受信した送信側装置３８は、受信したＡＣＫパケットＰ３３３のウィンドウサイズが７で、ＡＣＫ番号が５であることから、５以降のシーケンスで未送信シーケンスであるシーケンス番号８、９、１０、１１のデータパケットＰ３４４を送信する。
次に、ウィンドウ更新通知機能により受信側装置３１は、ＡＣＫパケットＰ３３３を送信後、所定間隔のＴミリ秒が経過すると、（式１４）に従い、前回通知したウィンドウサイズ７に、更新容量４を加算し、ＡＣＫ番号増加量１に基づいて、ウィンドウサイズ１０を算出する。受信側装置３１は、算出したウィンドウサイズ１０を設定したＡＣＫパケットＰ３３４を、送信側装置３８へ通知する。ＡＣＫパケットＰ３３４を受信した送信側装置３８は、受信したＡＣＫパケットＰ３３４のウィンドウサイズが１０で、ＡＣＫ番号が６であることから、ＡＣＫ番号が６以降のシーケンスで未送信シーケンスであるシーケンス番号１２、１３、１４、１５のデータパケットＰ３４５を送信する。
このように本実施の形態では、実施の形態１と同様の効果を得ることができるとともに、送信側装置がスロースタートを行う場合においても、受信側装置から送信側装置の送信レートを制御することが可能である。また、本実施の形態を実施の形態２、３、または４などと組み合わせることにより、各々の実施の形態で得られる効果も享受することができる。
なお、本実施の形態では、送信側装置３８から連続的に送信されたデータパケットが更新量に達したときに、ウィンドウ更新通知機能を開始させたが、予め定められた時間が経過したときや、送信側装置３８から送信された全てのデータパケットの数が予め定められた数に達したときに、ウィンドウ更新通知機能を開始させてもよい。
（実施の形態８）
本実施の形態における通信装置（受信側装置）は、実施の形態１の図８に示す構成と略同様であって、処理部のみが異なる。したがって、処理部以外の構成要素についての詳細な説明は省略する。
図２５は、本実施の形態の受信側装置３１における処理部の機能構成の一例を示す構成図である。本実施の形態の受信側装置３１は、実施の形態１の処理部３３の代わりに処理部３３ｅを備える。
処理部３３ｅは、ＩＰ処理部１４１、ＴＣＰ処理部１４２およびアプリケーション処理部１４３を備える。なお、本実施の形態においては、ＴＣＰ処理部１４２は、処理部３３ｅで実行されるプログラムとして説明を行うが、ＬＳＩなどに実装されたものであっても良い。また、図中の実線は、送受信パケットのデータフローを、破線は制御情報のやり取りに関するフローを示している。
受信側装置３１のＴＣＰ処理部１４２は、ＴＣＰパケット処理部１４４、受信バッファ１４７、ウィンドウサイズ算出部１４８、および前回ＲＷＩＮ記憶部１４９から構成される。
ＴＣＰパケット処理部１４４は、ＴＣＰパケットの送受信処理の機能を有する。ＴＣＰパケット処理部１４４は、受信したパケットのアプリケーションを特定し、そのパケットをアプリケーションへ引き渡すため、受信バッファ１４７に格納する。さらに、ＴＣＰパケット処理部１４４は、ＴＣＰパケットを構築し、ＩＰ処理部１４１へ渡し、ＴＣＰ／ＩＰパケットとして送信する機能を有する。また、ＴＣＰパケット処理部１４４には、ＡＣＫ生成部１４５、ウィンドウ更新通知生成部１４６およびパケットロス検知部１５０が含まれる。
ＡＣＫ生成部１４５は、受信したＴＣＰパケットのシーケンス番号に基づいて、ＡＣＫ番号を決定し、ＡＣＫパケットを生成する。ＡＣＫパケットには、ウィンドウサイズ算出部１４８から得た、現在受信可能な空き容量、つまりウィンドウサイズも設定される。
ウィンドウ更新通知生成部１４６は、受信バッファ１４７の空き状況に増加が生じたとき、ウィンドウ更新通知パケットを生成する。また、ウィンドウ更新通知生成部１４６は、ウィンドウサイズ算出部１４８から得たウィンドウサイズを、そのウィンドウ更新通知パケットに設定する。
パケットロス検知部１５０は、ＴＣＰパケットに抜けやロスがあったことを検知する機能を持つ。また、パケットロス検知部１５０は、ロスが発生したことをウィンドウサイズ算出部１４８に通知する機能を有する。
受信バッファ１４７は、アプリケーション処理部１４３に渡すための受信データを一時的に保持する機能を有する。受信バッファ１４７は、最大ＲＷＩＮ＿ＭＡＸのデータを格納することができ、アプリケーション処理部１４３の要求により、受信バッファ１４７に一時的に保持されているデータを順に、アプリケーション処理部１４３へと渡す。また、受信バッファ１４７は、アプリケーション処理部１４３へデータが渡されることによってウィンドウサイズが増加した際は、ウィンドウ更新通知生成部１４６へウィンドウサイズが増加したことを通知する。
ウィンドウサイズ算出部１４８は、送信側装置３８へウィンドウサイズとして通知する値を算出する機能を有する。つまり、本実施の形態におけるウィンドウサイズ算出部１４８は、パケットロス検知部１５０から通知されたパケットロスに基づいて、ウィンドウサイズを算出する。ウィンドウサイズは、次の式で算出される。
ウィンドウサイズ＝前回通知したウィンドウサイズ−前回通知したウィンドウサイズ中ロスしたデータ量・・・（式１５）
また、所定時間Ｈにパケットロスが検知されていなかった場合は、次の式で算出しても良い。
ウィンドウサイズ＝前回通知したウィンドウサイズ＋更新量・・・（式１６）
なお、更新量は、１ＭＳＳであったり、複数ＭＳＳであったりしても良い。
前回ＲＷＩＮ記憶部１４９は、前回にウィンドウ更新通知を行った際に用いたウィンドウサイズ（以下、前回ウィンドウサイズという）を記録保持する機能を有する。前回ＲＷＩＮ記憶部１４９は、記録保持する前回ウィンドウサイズをウィンドウサイズ算出部１４８へ渡し、ウィンドウサイズ算出部１４８が算出した結果を受け取り、前回ウィンドウサイズを更新し記録保持を行う。
図２６は、本実施の形態におけるデータパケットとＡＣＫパケットのやり取りを示したシーケンス図である。図２６の例では、受信側装置３１が送信するＡＣＫパケット、もしくは、ウィンドウ更新通知パケットを破線で示し、送信側装置３８が送信するデータパケットを実線で示している。また、説明を簡略化するために、１パケット長を１、更新量を２、所定時間をＨミリ秒、として説明をする。さらに、図中のＰ３５１（Ａｃｋ＝１，Ｗｉｎ＝８）は、ＡＣＫ番号１およびウィンドウサイズ８のＡＣＫパケットであることを示し、Ｐ３６２（Ｓｅｑ＝８）は、シーケンス番号８のデータパケットであることを示している。
受信側装置３１は、送信側装置３８とコネクションの確立などを経て、送信側装置３８から送信されるデータを受信する状態となる。このとき、受信側装置３１は、ウィンドウサイズを８として、送信側装置３８へ通知している（Ｐ３５１）。送信側装置３８は、ウィンドウサイズ８に基づいて、データパケットＰ３６１、Ｐ３６２を受信側装置３１へ送信する。しかし、このときネットワーク３７が混雑している、または、中継装置の能力不足などが原因で、データパケットＰ３６２がロスしたとする。データパケットＰ３６２が到達しなかった受信側装置３１では、到着したシーケンス番号までに対するＡＣＫパケットＰ３５２を送信する。ＡＣＫパケットＰ３５２を受信した送信側装置３８は、続きのシーケンス番号であるデータパケットＰ３６３を送信する。
データパケットＰ３６３を受信した受信側装置３１は、シーケンス番号８がロスしたこと検知し、前回送信したＡＣＫパケットＰ３５２と同様のＡＣＫパケット（以下、重複ＡＣＫパケットという）Ｐ３５３を、受信したパケット（シーケンス番号９〜１５のパケット）数分だけ送信する。なお、本実施の形態では、７個の重複ＡＣＫパケットＰ３５３が送信されることになる。重複ＡＣＫパケットを受信した送信側装置３８は、シーケンス番号８がロスしたことを知り、高速再送機能によりシーケンス番号８のデータパケットＰ３６４を再送する。
再送されたデータパケットＰ３６４を受信した受信側装置３１は、（式１５）によりウィンドウサイズを減少させ、ウィンドウサイズ７としてＡＣＫパケットＰ３５４を送信する。ＡＣＫパケットＰ３５４を受信した送信側装置３８は、そのＡＣＫパケットに設定されるウィンドウサイズが７であることから、７パケット分のデータパケットＰ３６５を送信する。
つまり、ＡＣＫパケットＰ３５４でウィンドウサイズが８に設定されていれば、送信側装置３８は、データパケットＰ３６１、Ｐ３６２を送信したときと同様、再び、８個のパケットを有するデータパケットを受信側装置３１に送信しようとする。その結果、再び、パケットロスが発生する可能性が高まる。
しかしながら、本実施の形態では、ＡＣＫパケットＰ３５４でウィンドウサイズが７に設定されるため、再びパケットロスが発生するのを防ぐことができる。
図２７は、本実施の形態におけるデータパケットとＡＣＫパケットの他のやり取りを示したシーケンス図である。図２７の例では、受信側装置３１が送信するＡＣＫパケット、もしくは、ウィンドウ更新通知パケットを破線で示し、送信側装置３８が送信するデータパケットを実線で示している。また、説明を簡略化するために、１パケット長を１、更新量を２、所定時間をＨミリ秒、として説明をする。
受信側装置３１は、送信側装置３８とコネクションの確立などを経て、送信側装置３８から送信されるデータを受信する状態となる。このとき、受信側装置３１は、ウィンドウサイズを６として、送信側装置３８へ通知している（Ｐ３７１）。送信側装置３８は、ウィンドウサイズ６に基づいて、データパケットＰ３８１を受信側装置３１へ送信する。データパケットＰ３８１を受信した受信側装置３１は、ＡＣＫ番号７およびウィンドウサイズ６を示すＡＣＫパケットＰ３７２を送信側装置３８に送信する。このような受信側装置３１と送信側装置３８のデータ送受信処理は、暫く継続して繰り返される。
そして、受信側装置３１は、データパケットの受信を開始して所定時間Ｈが経過すると、（式１６）によりウィンドウサイズを更新量だけ増加させ、ウィンドウサイズを８として通知する（Ｐ３７３）。これにより、送信側装置３８は、ウィンドウサイズ８に応じたデータパケットＰ３８２を送信する。
つまり、所定時間Ｈの間にパケットロスが発生していなければ、送信側装置３８は、パケットロスの発生を抑えた状態でより多くのパケットを送信することができる可能性が高い。 したがって、本実施の形態では、所定時間Ｈの間にパケットロスが発生していなければ、ウィンドウサイズが大きく設定されるため、データ転送効率を向上することができる。
このように本実施の形態では、ウィンドウサイズをパケットロス状況にあわせ動的に変化させることで、連続的なパケットロスを防止することが可能となる。また、パケットロスが発生していないことを検知し、ウィンドウサイズを増加させることで、より効率の良いデータ転送を実現することが可能となる。
（実施の形態９）
本実施の形態における通信装置（受信側装置）は、実施の形態１の図８に示す構成と略同様であって、処理部のみが異なる。したがって、処理部以外の構成要素についての詳細な説明は省略する。
図２８は、本実施の形態の受信側装置３１における処理部の機能構成の一例を示す構成図である。本実施の形態の受信側装置３１は、実施の形態１の処理部３３の代わりに処理部３３ｅを備える。
処理部３３ｆは、ＩＰ処理部１６１、ＴＣＰ処理部１６２およびアプリケーション処理部１６３を備える。なお、本実施の形態においては、ＴＣＰ処理部１６２は、処理部３３ｆで実行されるプログラムとして説明を行うが、ＬＳＩなどに実装されたものであっても良い。また、図中の実線は、送受信パケットのデータフローを、破線は制御情報のやり取りに関するフローを示している。
受信側装置３１のＴＣＰ処理部１６２は、ＴＣＰパケット処理部１６４、受信バッファ１６７およびウィンドウサイズ算出部１６８から構成される。なお、受信バッファ１６７は、実施の形態１の受信バッファ４７と同一の機能および構成を有する。
ＴＣＰパケット処理部１６４は、ＴＣＰパケットの送受信処理の機能を有する。ＴＣＰパケット処理部１６４は、受信したパケットのアプリケーションを特定し、そのパケットをアプリケーションへ引き渡すため、受信バッファ１６７に格納する。さらに、ＴＣＰパケット処理部１６４は、ＴＣＰパケットを構築し、ＩＰ処理部１６１へ渡し、ＴＣＰ／ＩＰパケットとして送信する機能を有する。また、ＴＣＰパケット処理部１６４には、ＡＣＫ生成部１６５、重複ＡＣＫ生成部１６６およびパケット抜け検知部１６９が含まれる。
ＡＣＫ生成部１６５は、受信したＴＣＰパケットのシーケンス番号に基づいて、ＡＣＫ番号を決定し、ＡＣＫパケットを生成する。ＡＣＫパケットには、ウィンドウサイズ算出部１６８から得た、現在受信可能な空き容量、つまりウィンドウサイズも設定される。
重複ＡＣＫ生成部１６６は、受信パケットに抜けが発生したことをパケット抜け検知部１６９から通知されると、重複ＡＣＫパケットを生成し、送信する機能を有する。また、重複ＡＣＫパケットには、ウィンドウサイズ算出部１６８から得た、ウィンドウサイズが設定される。
パケット抜け検知部１６９は、ＴＣＰパケットに抜けやロスがあったことを検知する機能を持つ。また、パケット抜け検知部１６９は、パケット抜けがあったことを重複ＡＣＫ生成部１６６に通知する。
ウィンドウサイズ算出部１６８は、受信バッファ１６７の空き状況によりウィンドウサイズを算出し、ＡＣＫ生成部１６５や重複ＡＣＫ生成部１６６へ通知する機能を有する。
図２９は、本実施の形態におけるデータパケットとＡＣＫパケットのやり取りを示したシーケンス図である。図２９の例では、受信側装置３１が送信するＡＣＫパケット、もしくは、ウィンドウ更新通知パケットを破線で示し、送信側装置３８が送信するデータパケットを実線で示している。
送信側装置３８は、受信側装置３１からＡＣＫパケットＰ３９１を受信すると、データパケットＰ４０１，Ｐ４０２，Ｐ４０３を受信側装置Ｐ３９１に送信する。ここで、送信側装置３８が送信したデータパケットＰ４０１、Ｐ４０２、Ｐ４０３のうち、データパケットＰ４０２が受信側装置３１に受信されなかったとする。
このとき、受信側装置３１は、データパケットＰ４０３の到着によりパケットの抜けを検知する。パケットの抜けを検知した受信側装置３１は、即座にＡＣＫパケットＰ３９２を所定数生成し、送信側装置３８へ送信する。
所定数のＡＣＫパケットＰ３９２を受信した送信側装置３８は、高速再送機能により、即座にデータパケットＰ４０４を再送する。
このように本実施の形態では、パケット抜け検知後、同一のＡＣＫパケットを所定数、送信側装置へ送信することにより、送信側装置に高速再送機能を迅速に誘発させることが可能となり、パケット抜けからのすばやい復旧を行うことが可能となる。
（実施の形態１０）
以下本実施の形態について、図面を参照しながら説明する。
図３０は、本発明の実施の形態に係るネットワークの構成例および通信装置の構成例を示す図である。図３０において、通信装置２００Ａが、ネットワーク３Ａを経由し、通信装置１００Ａと通信する。通信装置１００Ａおよび通信装置２００Ａは、ネットワーク３Ａと有線または無線で接続する通信機能を持つ装置であり、例えば、Ｅｔｈｅｒｎｅｔ（登録商標）インタフェースを備えた装置（例えばＰＣ（Personal Computer）や、ネットワーク通信が可能な家電装置など）である。ネットワーク３Ａは、有線または無線を含むネットワークであり、インターネットなどの公衆ネットワークなどが例として挙げられる。
本実施の形態では、通信装置１００Ａと通信装置２００Ａとがそれぞれの間でＴＣＰのコネクションを確立し、通信装置２００Ａから通信装置１００Ａにデータが送信されることを想定する。このような想定上、ＴＣＰのコネクションにおけるデータ送信の関係において、データ送信元の通信装置２００Ａを送信側装置、データ送信先の通信装置１００Ａを受信側装置と呼ぶ。例えば、ＦＴＰ（File Transfer Protocol）サーバである送信側装置（例えばＰＣ）から、アプリケーションプログラムに基づく動作を行なうＦＴＰクライアントたる受信側装置がファイルをダウンロードする場合や、ＰＯＰ（Post Office Protocol）サーバである送信装置から、電子メールを扱うアプリケーションプログラムに基づく動作を行なう受信側装置が電子メールを受信する場合などを想定する。
通信装置１００Ａは、処理部たるＣＰＵ１０１Ａ、記憶部１０２Ａ、システムバス１０３Ａ、および通信部１０５Ａを備える。
通信部１０５Ａは、システムバス１０３Ａ上に接続されたハードウェアである。この通信部１０５Ａは、ＣＰＵ１０１Ａによって渡されたデータをネットワーク３Ａに送信する機能と、ネットワーク３Ａからデータを受信してＣＰＵ１０１Ａに渡す機能とを有する。
また、この通信部１０５Ａは、ネットワーク３Ａから受信したデータを一時的に保持する受信用ＦＩＦＯメモリ１５１Ａと、ＣＰＵ１０１Ａから渡されたデータを一時的に保持する送信用ＦＩＦＯメモリ１５２Ａとを備える。さらに、通信部１０５Ａは、ネットワーク３Ａから受信したデータが受信用ＦＩＦＯメモリ１５１Ａに収まらず溢れてしまった場合、そのデータロスを検知するデータロス検知部１５０Ａを備える。
なお、データロス検知部１５０Ａは、ロスしたパケットのプロトコルおよびポート番号が、現在通信しているプロトコルおよびポート番号と一致した場合のみに、オーバーランの発生をＣＰＵ１０１Ａに通知してもよい。さらに、受信用ＦＩＦＯメモリ１５１Ａと送信用ＦＩＦＯメモリ１５２Ａは、送信と受信で共有していても良い。
ＣＰＵ１０１Ａは、通信部１０５Ａの受信用ＦＩＦＯメモリ１５１Ａに格納されたデータを記憶部１０２Ａに移動する（読み出し）機能と、記憶部１０２Ａに格納されているデータを通信部１０５Ａの送信用ＦＩＦＯメモリ１５２Ａに移動する（書き込み）機能をもつ。また、ＣＰＵ１０１Ａは、記憶部１０２Ａに格納さているデータに対してデータの解析や送信用データの作成処理など、ＴＣＰを含むプロトコル処理も行なう。また、ＣＰＵ１０１Ａは、通信アプリケーションプログラムや、必要に応じてその他のプログラムを、記憶部１０２Ａを使用しながら実行する機能を持つ。
なお、記憶部１０２Ａから通信部１０５Ａの送信用ＦＩＦＯメモリ１５２Ａまたは通信部１０５Ａの受信用ＦＩＦＯメモリ１５１Ａから記憶部１０２Ａへのデータの転送において、通信装置１００Ａ，２００Ａは、別途ＤＭＡコントローラを具備し、ＣＰＵではなく、ＤＭＡ（Direct Memory Access）コントローラによりデータの移動を行なう場合もある。さらに、各プロトコル処理は、ＣＰＵ１０１Ａにより実施されるのではなく、別途ハードウェアでそれぞれ実施されてもよい。
図３１は、通信装置１００ＡにおけるＣＰＵ１０１Ａの機能構成を示す構成図である。
図３１に示す機能構成は、図３０に示すＣＰＵ１０１Ａ上で動作するソフトウェアとして実現可能である。なお、図３１の構成図は、受信側装置として、本発明に係るＴＣＰデータの受信処理を中心として記載されているが、通信装置１００Ａは、ＴＣＰデータの送信処理を行なう機能部を具備していてもよい。また、通信装置２００Ａは、従来の通信装置であってもよいし、本発明が適用された受信処理の機能部を持つ通信装置であってもよい。以下、各機能部の説明を記述するにあたり、本発明に係る受信処理についてのみ詳細に記述し、送信処理に係る機能および動作の説明は省略する。また、本発明に直接関係のないＴＣＰ通信を実現するためのその他の構成についても説明を省略する。
なお、図３１においては、データの流れをいくつかの種類の線を用いてあらわしている。実線はパケットまたはデータの流れを示すデータフロー、点線は制御信号（通知またはパラメータ）の流れを示す制御フローである。
図３１において、通信装置１００ＡのＣＰＵ１０１Ａは、受信または送信するパケットを処理するパケット処理部の詳細な構成として、ＡＰＩ部１１００、ＴＣＰ処理部１２００、ＩＰ処理部１３００、ＩＦ処理部１４００、およびＭＡＣ処理部１５００を有する。さらに、ＴＣＰ処理部１２００は、受信バッファ１２４０、Ｗｉｎｄｏｗ制御部１２５０、ＷｉｎＵｐｄａｔｅ生成部１２６０、ＤｕｐＡｃｋ生成部１２７０、Ａｃｋ生成部１２８０、ＴＣＰ送信部１２２０、ＴＣＰ受信部１２１０、ＴＣＰロス検知部１２１５、およびＤｕｐＡｃｋ管理部１２３０を有する。またさらに、ＭＡＣ処理部１５００は、ロス通知部５０００、パケット複製部７０００、ＭＡＣ送信部１５２０、およびＭＡＣ受信部１５１０を有する。
ＡＰＩ部１１００は、ＴＣＰ処理部１２００と例えばＦＴＰなどのアプリケーションプログラムとの間のデータの受け渡し、および、その処理完了の通知を行なう。ＡＰＩ部１１００は、アプリケーションプログラムからの要求に応じて、ＴＣＰ処理部１２００にデータの受け渡しを要求し、ＴＣＰ処理部１２００から渡されたデータを、アプリケーションプログラムが処理できるように必要に応じて変換やコピーを行い、その処理の完了をＴＣＰ処理部１２００に通知する。
ＴＣＰ処理部１２００は、ＩＰ処理部１３００から受け取ったＴＣＰパケットを、ＡＰＩ部１１００に渡すデータに変換する。ＴＣＰ処理部１２００は、ＩＰ処理部１３００から受け取った一つあるいは複数のＴＣＰパケットに含まれるデータを、ＴＣＰパケットから抽出して保持し、ＡＰＩ部１１００からのデータの受け渡し要求に応じて、該当するデータを渡す。また、ＴＣＰ処理部１２００は、ＩＰ処理部１３００から受け取ったＴＣＰパケットに対するＡｃｋを作成してＩＰ処理部１３００に渡す。なお、本実施の形態では、Ａｃｋを、上記実施の形態１〜９のＡＣＫまたはＡＣＫパケットとして説明する。
ＩＰ処理部１３００は、ＩＦ処理部１４００から受け取ったＩＰパケットからＴＣＰパケットを抽出し、ＴＣＰ処理部１２００に渡す。また、ＩＰ処理部１３００は、ＴＣＰ処理部１２００から受け取ったＴＣＰパケットにＩＰヘッダを追加してＩＰパケットを構築し、ＩＦ処理部１４００に渡す。
ＩＦ処理部１４００は、ＭＡＣ処理部１５００から受け取ったＭＡＣフレームからＩＰパケットを抽出し、ＩＰ処理部１３００に渡す。また、ＩＦ処理部１４００は、ＩＰ処理部１３００から受け取ったＩＰパケットにＭＡＣヘッダを追加してＭＡＣフレームを構築してＭＡＣ処理部１５００に渡す。
ＭＡＣ処理部１５００は、図３０に示す通信部１０５Ａが受け取ったデータをＩＦ処理部１４００に渡す。この処理は、図３０の通信部１０５Ａの受信用ＦＩＦＯメモリ１５１Ａから図３０の記憶部１０２Ａにデータを渡す（読み出し）処理である。また、ＭＡＣ処理部１５００は、ＩＦ処理部１４００から受け取ったＭＡＣフレームを通信部１０５Ａに渡す。この処理は、図３０の記憶部１０２Ａから通信部１０５Ａの送信用ＦＩＦＯメモリ１５２Ａにデータを渡す（書き込み）処理である。
以下、上記のＴＣＰ処理部１２００およびＭＡＣ処理部１５００のさらに詳細な構成について図３１を使用して説明する。
ＴＣＰ処理部１２００の受信バッファ１２４０は、ＴＣＰ受信部１２１０から受け取ったデータを管理するバッファ領域である。管理するデータの実態は、図３０の記憶部１０２Ａに配置される。受信バッファ１２４０は、管理するデータをＡＰＩ部１１００に渡し、渡し終えたデータを保持していたバッファ領域を開放する機能をもつ。また、Ｗｉｎｄｏｗ制御部１２５０からの使用可能なバッファサイズの問い合わせに対し、使用可能なバッファサイズをＷｉｎｄｏｗ制御部１２５０に伝える機能をもつ。
Ｗｉｎｄｏｗ制御部１２５０は、受信バッファ１２４０に問い合わせて得た使用可能なバッファサイズからＷｉｎを算出して保持する。なお、本実施の形態では、Ｗｉｎを、実施の形態１〜９のウィンドウサイズとして説明する。また、Ｗｉｎｄｏｗ制御部１２５０は、ＤｕｐＡｃｋ管理部１２３０およびＡｃｋ生成部１２８０からのＷｉｎの問い合わせに対し、管理しているＷｉｎをそれぞれに渡す。さらに、Ｗｉｎｄｏｗ制御部１２５０は、ＡＰＩ部１１００からアプリケーション処理の完了の通知を受けると、受信バッファ１２４０に問い合わせて得た使用可能なバッファサイズからＷｉｎを算出し、算出したＷｉｎをＤｕｐＡｃｋ管理部１２３０に渡す。
ＷｉｎＵｐｄａｔｅ生成部１２６０は、ＤｕｐＡｃｋ管理部１２３０よりＷｉｎを受け取った場合に、ＷｉｎｄｏｗＵｐｄａｔｅ（受信できるＷｉｎが増加したことを送信側装置に通知するＡｃｋ、以後ＷｉｎＵｐｄａｔｅ）を作成してＴＣＰ送信部１２２０に渡す。
ＤｕｐＡｃｋ生成部１２７０は、ＤｕｐＡｃｋ管理部１２３０より受け取ったＤｕｐＡｃｋ情報よりＤｕｐＡｃｋ（Duplicate acknowledgement：即時応答確認）を生成してＴＣＰ送信部１２２０に渡す。なお、ＤｕｐＡｃｋ情報は、上記実施の形態１〜９のＡＣＫ番号たるシーケンスナンバー（以下、Ｓｅｑという）と、Ｗｉｎとを含む。また、ＤｕｐＡｃｋまたはＤｕｐＡｃｋパケットは、上記実施の形態１〜９の重複ＡＣＫに相当する。
Ａｃｋ生成部１２８０は、ＴＣＰ受信部１２１０よりＳｅｑを受け取った場合、Ｗｉｎｄｏｗ制御部１２５０に問い合わせて得たＷｉｎと、ＴＣＰ受信部１２１０より受け取ったＳｅｑとに基づいてＡｃｋを作成し、ＴＣＰ送信部１２２０に渡す。
なお、本実施の形態では、ＤｕｐＡｃｋ生成部１２７０およびＡｃｋ生成部１２８０のそれぞれが、確認応答パケットたるＤｕｐＡｃｋまたはＡｃｋを生成する第１のパケット生成手段として構成されている。
ＴＣＰ送信部１２２０は、ＤｕｐＡｃｋ管理部１２３０またはＡｃｋ生成部１２８０から受け取ったＴＣＰパケット（ＤｕｐＡｃｋまたはＡｃｋ）に必要なＴＣＰヘッダ情報を設定して、そのＴＣＰパケットをＩＰ処理部１３００に渡す。
ＴＣＰ受信部１２１０は、ＴＣＰパケットのＳｅｑが順序どおりであるかどうかを調査するＴＣＰロス検知部１２１５を備える。ＴＣＰ処理部１２００は、ＩＰ処理部１３００から受け取ったＴＣＰパケットのＳｅｑが順序どおりであった場合（ＴＣＰロス検知部１２１５がＴＣＰパケットのロスを検知しなかった場合）、ＴＣＰパケットからデータを抽出する処理を実施し、受信バッファ１２４０に渡す。また、ＴＣＰ受信部１２１０は、Ｓｅｑが順序通りであった場合に次のＳｅｑをＡｃｋ生成部１２８０に渡す。なお、Ａｃｋ生成部１２８０へ次のＳｅｑを渡す機能は、毎回発生しなくてもよい。この場合、Ａｃｋ生成部１２８０への通知は、複数回に１回の割合で通知されたり、Ｄｅｌａｙｅｄ Ａｃｋアルゴリズムにより、システムのタイマから所定時間経過後に行われたりする。
ＴＣＰロス検知部１２１５は、ＴＣＰ受信部１２１０が受け取ったＴＣＰパケットのＳｅｑを調査し、Ｓｅｑが順序通りでなかった場合、期待していたＳｅｑをＤｕｐＡｃｋ管理部１２３０に渡す。
ＤｕｐＡｃｋ管理部１２３０は、ＴＣＰロス検知部１２１５から受け取ったＳｅｑと、Ｗｉｎｄｏｗ制御部１２５０に問い合わせて得たＷｉｎとをＤｕｐＡｃｋ情報として保持する。さらに、ＤｕｐＡｃｋ管理部１２３０は、ＤｕｐＡｃｋ情報をＤｕｐＡｃｋ生成部１２７０に渡し、その渡した回数をＤｕｐＡｃｋ送信数としてカウントする。
また、ＤｕｐＡｃｋ管理部１２３０は、Ｗｉｎｄｏｗ制御部１２５０よりＷｉｎを受け取った場合に、ロス通知部５０００からのパケットロス情報に基づいて、保持するＤｕｐＡｃｋ送信数から所定数に足りないＤｕｐＡｃｋ複製数を算出する。その結果が１以上の場合は、ＤｕｐＡｃｋ管理部１２３０は、Ｗｉｎｄｏｗ制御部１２５０より受け取ったＷｉｎをＷｉｎＵｐｄａｔｅ生成部１２６０に渡す前に、保持するＤｕｐＡｃｋ情報（ＳｅｑおよびＷｉｎ）をＤｕｐＡｃｋ生成部１２７０に渡す。そして、ＤｕｐＡｃｋ管理部１２３０は、パケット複製部７０００の問い合わせに対し、算出したＤｕｐＡｃｋ複製数を通知する。なお、本実施の形態においては、ＤｕｐＡｃｋ管理部１２３０が算出したＤｕｐＡｃｋ複製数について、パケット単位での管理を例に説明する。
なお、ＤｕｐＡｃｋ複製数を、送信するパケット単位ではなく例えば、ＴＣＰのコネクション単位や通信装置全体で一つとして管理してもよい。
さらに、ＤｕｐＡｃｋ管理部１２３０は、ＤｕｐＡｃｋ複製数をパケット複製部７０００に通知すると、パケットロス通知部５０００から受け取ったパケットロス情報を消去し、さらにＤｕｐＡｃｋ複製数およびＤｕｐＡｃｋ送信数を初期値にリセットする。ＤｕｐＡｃｋ複製数の初期値としては、１を例に説明する。また、ＤｕｐＡｃｋ送信数の初期値としては、０を例に説明する。
ＭＡＣ処理部１５００は、ＭＡＣ受信部１５１０、ＭＡＣ送信部１５２０、およびロス通知部５０００を備える。それぞれの詳細な説明を以下に示す。
ＭＡＣ受信部１５１０は、図３０の通信部１０５Ａの受信用ＦＩＦＯメモリ１５１Ａから読み出したＭＡＣフレーム（Ｐ２００）をＩＦ処理部１４００に渡す。即ち、ＭＡＣ受信部１５１０は、図３０の受信用ＦＩＦＯメモリ１５１Ａのデータを、ＣＰＵ１０１Ａを介して記憶部１０２Ａに移動させようとする。
ＭＡＣ送信部１５２０は、パケット複製部７０００を備える。ＭＡＣ送信部１５２０は、ＩＦ処理部１４００から受け取ったＭＡＣフレームをパケット複製部７０００が指示する複製数だけ、図３０の通信部１０５Ａの送信用ＦＩＦＯメモリ１５２Ａに書き込む（Ｐ１００）。即ち、ＭＡＣ送信部１５２０は、図３０のＣＰＵ１０１Ａから送信用ＦＩＦＯメモリ１５２Ａへデータを移動させようとする。したがって、ＭＡＣ送信部１５２０は、ＤｕｐＡｃｋを複製して送信用ＦＩＦＯメモリ１５２Ａに書き込む。
パケット複製部７０００は、ＤｕｐＡｃｋ管理部１２３０に問い合わせ、問い合わせて得たＤｕｐＡｃｋ複製数（Ｎ個）に基づいて、ＭＡＣ送信部１５２０に対して、対象となるＭＡＣフレームのＮ回の送信指示を行なう。なお、図３０の通信部１０５ＡがＭＡＣフレームをＤｕｐＡｃｋ複製数（Ｎ個）だけ複製して送信する機能をもつ場合には、パケット複製部７０００は、対象となるＭＡＣフレームのデータの移動は１回として、Ｎ回複製して送信する指示のみを行なってもよい。
なお、本実施の形態では、ＭＡＣ送信部１５２０とパケット複製部７０００とが、データ要求パケットたるＤｕｐＡｃｋを生成する第２のパケット生成手段として構成されている。
ロス通知部５０００は、図３０のデータロス検知部１５０Ａからのパケットロス通知（Ｅ１５０）を受け取り、ＤｕｐＡｃｋ管理部１２３０にパケットロス情報を渡す。なお、パケットロス通知（Ｅ１５０）にＩＰアドレスや、プロトコル、ポート番号が含まれる場合は、ロス通知部５０００は、ＤｕｐＡｃｋ管理部１２３０にパケットロス情報としてＩＰアドレス、プロトコル、およびポート番号も渡す。その結果、ＤｕｐＡｃｋ管理部１２３０は、ロス通知部５０００から取得したＩＰアドレスやポート番号に基づいて、ロスしたパケットの再送を促す相手である送信側装置２００Ａを特定する。即ち、ＤｕｐＡｃｋ管理部１２３０は装置特定手段を備える。
以下、本実施の形態に係る通信装置間の通信シーケンスについて、通信装置１００Ａを受信側装置、通信装置２００Ａを送信側装置として動作させたときを例として図３２を用いて説明する。
図３２は、本実施の形態における通信装置間の通信シーケンスを示す図である。なお、受信側装置１００Ａの性能は低い（例えばＣＰＵ１０１Ａの性能が１３３ＭＨｚ）。また、説明を簡略化するために、１パケット内に格納されるデータ長である１パケット長（ＬＥＮ）を１ＫＢｙｔｅにし、ＳｅｑやＷｉｎの単位や値も、これに合わせている。また、図３２は、受信側装置１００ＡのＷｉｎが少なくなっている状況を示す。さらに、図３２では、送信側装置２００Ａと受信側装置１００ＡとのＴＣＰ接続時のコネクション設立と、受信側装置１００ＡのＷｉｎが多い状態から少ない状態（Ｗｉｎ＝４、図３２のＷ１１参照）にいたるまでの通信のシーケンスとを省略する。
図３２に示すように、受信側装置１００Ａは、Ｓｅｑ＝１のデータ（Ｐ２１）の受信に対し、Ａｃｋ（Ｐ１２）を送信側装置２００Ａに送信している。このＡｃｋには、次に要求するパケットのシーケンスナンバー（Ｎｕｍ＝２）と、受信側装置１００Ａの受信可能なデータ量（Ｗｉｎ＝３）とがパラメータとして含まれている。Ｗｉｎの値が３（Ｗ１２）であるのは、Ｓｅｑ＝１のデータに対するアプリケーションプログラムでの受信処理が完了しておらず、受信可能なデータ量が減少しているためである。図３２の例では、Ｓｅｑ＝２のデータ（Ｐ２２）が、受信側装置１００Ａの受信処理中でＴＣＰ（通信プロトコルのトランスポート層）の処理に至るまでに消失している（パケットの消失が発生している）。そのため、受信側装置１００ＡはＳｅｑ＝２（Ｐ２２）に対するＡｃｋを返さない。
次に、受信側装置１００Ａは、Ｓｅｑ＝３、４（Ｐ２３、Ｐ２４）のデータの受信に対し、Ａｃｋを送信側装置に送信する。このＡｃｋ（Ｐ１３、Ｐ１４）は、どちらもパラメータがＮｕｍ＝２およびＷｉｎ＝３となる。これは、受信側装置１００Ａが、Ｓｅｑ＝１のデータの後に、Ｓｅｑ＝３およびＳｅｑ＝４のデータを受信したため、Ｓｅｑ＝２のデータが不足していることを検知したためである。受信側装置１００Ａは、Ｓｅｑ＝２のパケットを要求するＡｃｋを、Ｓｅｑ＝１のパケットの受信時に既に送信している。したがって、このＡｃｋ（Ｐ１３、Ｐ１４）はＳｅｑ＝２のデータが到達していないことを伝えるＤｕｐＡｃｋとなる。このとき、これらのＤｕｐＡｃｋ（Ｐ１３、Ｐ１４）のＷｉｎは、Ｓｅｑ＝１のパケットに対するＡｃｋ（Ｐ１２）のＷｉｎと同じである。これは、Ｓｅｑ＝１のデータに対するアプリケーションプログラムの受信処理が完了していないためである。
受信側装置１００ＡのＣＰＵ１０１Ａが低速であるため、Ｓｅｑ＝１のデータに対するアプリケーションプログラムの受信処理は、受信側装置１００Ａが２つ目のＤｕｐＡｃｋを送信した後に完了する。アプリケーションプログラムの受信処理が完了した後に、受信側装置１００Ａは、送信側装置２００ＡにＷｉｎが回復したことを伝えるＷｉｎＵｐｄａｔｅ（Ｎｕｍ＝２およびＷｉｎ＝４）（Ｐ１６）を送信する。ここで、受信側装置１００Ａは、このＷｉｎＵｐｄａｔｅを送信する直前に、既に送信したＤｕｐＡｃｋ（Ｐ１４）をコピーして、そのコピーされたＤｕｐＡｃｋ（Ｐ１５）を送信側装置２００Ａに送信する。送信側装置２００Ａは、３つ目のＤｕｐＡｃｋ（Ｐ１５）を受信し、Ｓｅｑ＝２の再送データ（Ｐ２５）を高速再送する。
図３３は、受信側装置１００Ａにおける処理シーケンスの例を示す図である。具体的に、図３３は、受信側装置１００ＡがＳｅｑ＝１（Ｐ２１）のデータを受信し、ＷｉｎＵｐｄａｔｅ（Ｐ１６）を送信するまでの処理シーケンスを示す。図３３の処理シーケンスと、図３０および図３１の受信側装置１００Ａの構成図とを用いて、本実施の形態における受信側装置１００Ａでの処理を説明する。なお、図３３中、点線で囲まれた“通信部”は、図３０の通信部１０５Ａを示し、点線で囲まれた“ＭＡＣ”は、図３１のＭＡＣ処理部１５００を示し、点線で囲まれた“ＩＦ”は、図３１のＩＦ処理部１４００を示し、点線で囲まれた“ＩＰ”は、図３１のＩＰ処理部１３００を示す。さらに、図３３中、点線で囲まれた“ＴＣＰ”は、図３１のＴＣＰ処理部１２００を示し、点線で囲まれた“ＡＰＩ”は、図３１のＡＰＩ部１１００を示し、点線で囲まれた“アプリケーション”は、図３１のアプリケーションプログラムを示す。
まず、図３３の処理フローに従って、受信側装置１００ＡがＳｅｑ＝１（Ｐ２１）のパケットを受信してからＡｃｋ（Ｐ１２）を送信するまでの処理シーケンス（Ｐ２１、Ｐ２１１、Ｐ１２１、およびＰ１２）を説明する。
図３３に示すように、通信装置（送信側装置）２００Ａから送信されたＳｅｑ＝１のパケット（Ｐ２１）は、ネットワーク３Ａを介し通信装置（受信側装置）１００Ａの通信部１０５Ａによって受信処理される。通信部１０５Ａの受信用ＦＩＦＯメモリ１５１Ａに格納されたＳｅｑ＝１のパケット（Ｐ２１）は、ＣＰＵ１０１Ａにより、受信用ＦＩＦＯメモリ１５１Ａから記憶部１０２Ａに読み出される。なお、受信用ＦＩＦＯメモリ１５１Ａから記憶部１０２Ａへの移動において、別途受信側装置１００ＡにＤＭＡコントローラを具備し、ＣＰＵ１０１Ａではなく、ＤＭＡコントローラによりそのパケットが移動されてもよい。
ＭＡＣ処理部１５００のＭＡＣ受信部１５１０によって通信部１０５Ａの受信用ＦＩＦＯメモリ１５１Ａより読み出されたＳｅｑ＝１のＭＡＣフレーム（Ｐ２１）は、ＩＦ処理部１４００およびＩＰ処理部１３００により非パケット化されてＴＣＰ受信部１２１０に渡される（データフローＰ２１１）。
ＴＣＰ受信部１２１０は、Ｓｅｑ＝１のＴＣＰパケットのＴＣＰヘッダの解析処理を行い、非パケット化処理を完了する。このとき、ＴＣＰロス検知部１２１５において、Ｓｅｑ＝１のパケット（Ｐ２１）受信処理前にパケットロスが発生していないので、Ｓｅｑ＝１のパケットは順序通りの受信データであると判断され、受信バッファ１２４０およびＤｕｐＡｃｋ管理部１２３０に受信データとして渡される。この渡された受信データは、ＡＰＩ部１１００を通してアプリケーションプログラムに渡されることとなる。
また、ＴＣＰロス検知部１２１５において、順序通りのパケットであることが確認されたので、ＴＣＰ受信部１２１０は、当該データを受信したことを送信側装置２００Ａに通知するため、Ａｃｋ生成部１２８０に次のＳｅｑであるＳｅｑ＝２を渡す。ＴＣＰ受信部１２１０からＳｅｑを受け取ったＡｃｋ生成部１２８０は、Ｗｉｎｄｏｗ制御部１２５０を介して、受信バッファ１２４０に現在受信可能なＷｉｎを問い合わせる。Ａｃｋ生成部１２８０は、問い合わせ結果であるＷｉｎ＝３とＴＣＰ受信部１２１０から受け取ったＳｅｑとを基に、Ｓｅｑ＝１のパケット（Ｐ２１）に対してＮｕｍ＝２およびＷｉｎ＝３を示すＴＣＰパケットを生成し、ＴＣＰ送信部１２２０に渡す。
ＴＣＰ送信部１２２０は、そのＴＣＰパケットに対してＴＣＰヘッダ構築処理を行い、ＩＰ処理部１３００およびＩＦ処理部１４００は、そのＴＣＰヘッダ構築処理されたＴＣＰパケットに対してパケット構築を行なう。パケット構築されたＮｕｍ＝２およびＷｉｎ＝３を示すＭＡＣフレームは、ＭＡＣ処理部１５００のＭＡＣ送信部１５２０によって、パケットとして通信部１０５Ａの送信用ＦＩＦＯメモリ１５２Ａに書き込まれる（データフローＰ１２１）。
このように、通信部１０５Ａの送信用ＦＩＦＯメモリに書き込まれたデータ（ＭＡＣフレーム）は、Ｓｅｑ＝１のパケット（Ｐ２１）のＡｃｋ（Ｐ１２）としてネットワーク３Ａを介して送信側装置２００Ａへ送信される。
次に、図３３の処理フローに沿って、受信側装置１００ＡがＳｅｑ＝２（Ｐ２２）を受信してからの処理シーケンス（Ｐ２２およびＥ１００）を説明する。
通信装置（送信側装置）２００Ａから送信されたＳｅｑ＝２のパケット（Ｐ２２）は、ネットワーク３Ａを介し、通信装置（受信側装置）１００Ａの通信部１０５Ａによって受信処理される。しかし、ＣＰＵ１０１Ａが低速であるために、通信部１０５Ａの受信用ＦＩＦＯメモリ１５１Ａにおいて既に受信されたパケットがあふれてしまい、オーバーランが発生する。その結果、Ｓｅｑ＝２のパケット（Ｐ２２）は受信用ＦＩＦＯメモリ１５１Ａに格納されない。
Ｓｅｑ＝２のパケットでオーバーランが発生したため、データロス検知部１５０ＡはＣＰＵ１０１Ａに対して、オーバーランが発生したことを通知する（制御フローＥ１００）。即ち、ロス通知部５０００は、パケットロス通知を受け取り、ＴＣＰ処理部１２００のＤｕｐＡｃｋ管理部１２３０にパケットロス情報を渡す。ＤｕｐＡｃｋ管理部１２３０は受け取ったパケットロス情報を保持する。
次に、図３３の処理フローに沿って、受信側装置１００ＡがＳｅｑ＝３およびＳｅｑ＝４のパケット（Ｐ２３、Ｐ２４）を受信してからＡｃｋ（Ｐ１３、Ｐ１４）を送信するまでの処理シーケンス（Ｐ２３１、Ｐ１３１、Ｐ２４１、Ｐ１４１）を説明する。Ｐ２３およびＰ２４のデータに対する処理は、Ｐ２１のデータに対する処理と同様であるため、ここではそれらの処理の説明を省略する。また、Ｐ１３およびＰ１４のデータに対する処理は、Ｐ１２のデータに対する処理と同様であるため、ここではそれらの処理の説明を省略する。
ＭＡＣ処理部１５００のＭＡＣ受信部１５１０によって読み出されたＳｅｑ＝３のパケット（Ｐ２３）は、ＩＦ処理部１４００およびＩＰ処理部１３００により非パケット化され、ＴＣＰ受信部１２１０に渡される（データフローＰ２３１）。ＴＣＰ受信部１２１０は、受け取ったＴＣＰパケットのＴＣＰヘッダの解析処理を行い、非パケット化処理を完了する。このとき、Ｓｅｑ＝２のパケット（Ｐ２２）が未だ到着していないため、Ｓｅｑ＝３のＴＣＰパケットは、ＴＣＰロス検知部１２１５において、順序通りではない受信データであると判断される。ＴＣＰロス検知部１２１５は順序どおりで届くはずのシーケンスナンバー（Ｓｅｑ＝２）をＤｕｐＡｃｋ管理部１２３０に渡す。
Ｓｅｑ＝２を受け取ったＤｕｐＡｃｋ管理部１２３０は、Ｗｉｎｄｏｗ制御部１２５０を介して、受信バッファ１２４０に現在受信可能なＷｉｎを問い合わせ、Ｗｉｎ＝３を受け取る。ＤｕｐＡｃｋ管理部１２３０は、ＴＣＰロス検知部１２１５から受け取ったＳｅｑ＝２と、Ｗｉｎｄｏｗ制御部１２５０に問い合わせて得たＷｉｎ＝３とをＤｕｐＡｃｋ情報として保持し、ＤｕｐＡｃｋ情報をＤｕｐＡｃｋ生成部１２８０に渡す。さらに、ＤｕｐＡｃｋ管理部１２３０は、ＤｕｐＡｃｋ送信数を「１」にカウントする。ＤｕｐＡｃｋ生成部１２８０は、受け取ったＤｕｐＡｃｋ情報（ＷｉｎおよびＳｅｑ）より、Ｎｕｍ＝２およびＷｉｎ＝３を示すＤｕｐＡｃｋを生成し、生成したＤｕｐＡｃｋをＴＣＰ送信部１２２０に渡す。
ＤｕｐＡｃｋ（Ｎｕｍ＝２およびＷｉｎ＝３）は、ＴＣＰ送信部１２２０からＩＰ処理部１３００およびＩＦ処理部１４００を経て、パケット構築される（データフローＰ１３１）。パケット構築されたパケット（ＭＡＣフレーム）は、ＭＡＣ処理部１５００のパケット複製部７０００に出力される。このとき、パケット複製部７０００は、ＤｕｐＡｃｋ管理部１２３０に複製数を問い合わせ、その複製数が「１」であるため、ＭＡＣ処理部１５００に対してパケットの複製を指示しない。その結果、ＭＡＣ送信部１５２０は、通信部１０５Ａの送信用ＦＩＦＯメモリ１５２Ａにパケットを１つだけ書き込む。
データフローＰ２３１と同様に、ＭＡＣ処理部１５００のＭＡＣ受信部１５１０によって読み出されたＳｅｑ＝４のパケット（Ｐ２４）は、ＴＣＰ処理部１２００のＤｕｐＡｃｋ管理部１２３０およびＤｕｐＡｃｋ生成部１２７０にまで至る（データフローＰ２４１）。ＤｕｐＡｃｋ管理部１２３０は、現在保持しているＤｕｐＡｃｋ情報のＳｅｑ＝２と、ＴＣＰロス検知部１２１５から受け取ったＳｅｑとが同一であることを判断し、同一の場合、ＤｕｐＡｃｋ管理部１２３０が管理するＤｕｐＡｃｋの送信数を２にカウントする。
データフローＰ１３１と同様に、ＤｕｐＡｃｋ（Ｐ１４）は、ＴＣＰ送信部１２２０からＭＡＣ処理部１５００のパケット複製部７０００に至り、ＭＡＣ送信部１５２０によって通信部１０５ＡのＦＩＦＯメモリ１５２Ａに書き込まれる（データフローＰ１４１）。
次に、図３３の処理フローに沿って、Ｓｅｑ＝１（Ｐ２１）のデータのアプリケーションプログラムによる処理が完了し、ＤｕｐＡｃｋの複製を開始するまでの処理シーケンス（Ｐ２１２およびＰ２１３）を説明する。
送信側装置２００Ａでは、受信側装置１００ＡからのＡｃｋ（Ｐ１２）を受信してからＷｉｎの状態（図３２に示すＷ１２）が変化していない。Ｗ１２の状態では、新たに次のパケット（Ｓｅｑ＝５）を送信することができない。その間に、受信側装置１００Ａでは、アプリケーションプログラムからの受信要求により、受信バッファ１２４０およびＤｕｐＡｃｋ管理部１２３０がＡＰＩ部１１００を介してアプリケーションプログラムに受信データを渡す（データフローＰ２１２）。
ＡＰＩ部１１００は、受信データをアプリケーションに渡し終えるとＷｉｎｄｏｗ制御部１２５０へ受信完了したことを通知する（データフローＰ２１３）。
次に、図３３の処理フローに沿って、ＤｕｐＡｃｋがパケット構築され、ＭＡＣ処理部１５００においてＤｕｐＡｃｋが複製される処理シーケンス（Ｐ１５１）を説明する。
ＡＰＩ部１１００から受信完了したという通知を受けたＷｉｎｄｏｗ制御部１２５０は、受信バッファ１２４０にバッファの空き容量を問い合わせ、得たバッファ空き容量の情報からＷｉｎ＝４を算出する。算出したＷｉｎをＤｕｐＡｃｋ管理部１２３０に渡す。
Ｗｉｎを受け取ったＤｕｐＡｃｋ管理部１２３０は、制御フローＥ１００において保持していたパケットロス情報に基づき、ＤｕｐＡｃｋ送信数「２」と所定の数「３」とを用いてＤｕｐＡｃｋ複製数算出方法によりＤｕｐＡｃｋ複製数を算出する。このときの算出結果は、「１」であり、その値はＤｕｐＡｃｋ管理部１２３０で保持される。ＤｕｐＡｃｋ複製数算出方法については、後で説明する。さらに、ＤｕｐＡｃｋ管理部は、保持していたＤｕｐＡｃｋ情報（Ｓｅｑ＝２およびＷｉｎ＝３）をＤｕｐＡｃｋ生成部１２７０に渡す。
ＤｕｐＡｃｋ生成部１２７０は、受け取ったＤｕｐＡｃｋ情報により、ＤｕｐＡｃｋ（Ｎｕｍ＝２およびＷｉｎ＝３）を作成してＴＣＰ送信部１２２０に渡す。
ＴＣＰ送信部１２２０に渡されたＮｕｍ＝２およびＷｉｎ＝３を示すＴＣＰパケット（ＤｕｐＡｃｋ）は、ＩＰ処理部１３００およびＩＦ処理部１４００を経て、パケット構築される（データフローＰ１５１）。パケット構築されたＤｕｐＡｃｋパケット（ＭＡＣフレーム）は、ＭＡＣ処理部１５００のパケット複製部７０００に出力される。このときパケット複製部７０００は、ＤｕｐＡｃｋ管理部１２３０に問い合わせを行なう。パケット複製部７０００は、ＤｕｐＡｃｋ管理部１２３０から問い合わせて得たＤｕｐＡｃｋ複製数「１」により、ＭＡＣ送信部１５２０に対して、通信部１０５Ａの送信用ＦＩＦＯメモリ１５２Ａに１つパケットを書き込むように指示する。そして、ＭＡＣ送信部１５２０は、１つのＤｕｐＡｃｋパケットを送信用ＦＩＦＯメモリ１５２Ａに書き込む。
本実施の形態においては、ＭＡＣ送信部１５２０は、ＤｕｐＡｃｋ複製数が「１」のため、通信部１０５Ａの送信用ＦＩＦＯメモリ１５２Ａに１回だけＤｕｐＡｃｋパケットの書き込みを行ったが、ＤｕｐＡｃｋ複製数がＮ（Ｎ≧２）の場合は、同一のものをＮ回書き込むことにより、Ｎ個のＤｕｐＡｃｋパケットの送信が行なわれる。
通信部１０５Ａの送信用ＦＩＦＯメモリ１５２Ａに書きこまれたパケットは、通信部１０５Ａよりネットワーク３Ａを介して送信側装置２００ＡへＤｕｐＡｃｋパケット（Ｐ１５）として送信される。
次に、図３３の処理フローに沿って、ＴＣＰ処理部１２００で作成されたＷｉｎＵｐｄａｔｅがパケット構築され、送信される処理シーケンス（Ｐ１６１、Ｐ１６）を説明する。
ＤｕｐＡｃｋ管理部１２３０は、Ｗｉｎｄｏｗ制御部１２５０から受け取ったＷｉｎ＝４をＷｉｎＵｐｄａｔｅ生成部１２６０に渡す。ＷｉｎＵｐｄａｔｅ生成部１２６０は、ＷｉｎＵｐｄａｔｅを作り、ＴＣＰ送信部１２２０に渡す。ＴＣＰ送信部１２２０に渡されたＷｉｎＵｐｄａｔｅは、ＩＰ処理部１３００およびＩＦ処理部１４００を経て、パケット構築される（データフローＰ１６１）。パケット構築されたＷｉｎＵｐｄａｔｅパケット（ＭＡＣフレーム）は、ＭＡＣ送信部１５２０から通信部１０５Ａに渡される。
そして、通信部１０５Ａは、そのＷｉｎＵｐｄａｔｅ（Ｐ１６）を、ネットワーク３Ａを介して送信側装置２００Ａへパケット送信する。
ＤｕｐＡｃｋ管理部１２３０は、複製したＤｕｐＡｃｋパケット（Ｐ１５）の送信後、制御フローＥ１００でロス通知部５０００から渡されて保持していたパケットロス情報を消去し、ＤｕｐＡｃｋ複製数を「１」に初期化する。
さらに、ＤｕｐＡｃｋ管理部１２３０は、パケットロスしたシーケンスのパケットを受信することで、ＤｕｐＡｃｋ管理部１２３０が記憶していたＤｕｐＡｃｋ情報（ＳｅｑおよびＷｉｎ）を消去し、ＤｕｐＡｃｋ送信数を「０」にして、ＤｕｐＡｃｋ複製数を「０」にする。
なお、パケットロス情報の消去については、ＤｕｐＡｃｋ管理部１２３０がＤｕｐＡｃｋを複製していない場合でもロス通知部５０００からパケットロス情報を受け取ってから所定時間経過後（例えば１秒後）にそのパケットロス情報を消去してもよい。
また、ロス通知部５０００からパケットロス情報を受け取ってからＰＰＳ（Packet Per
Sec）が低くなった場合に、パケットロス情報の消去を実施してもよい。即ち、ＤｕｐＡｃｋ管理部１２３０はリセット手段を備える。
さらに、ロス通知部５０００からパケットロス情報を受け取ってから送信したパケット数をパケット複製部７０００が管理しておき、特定のパケット数が送信された場合に、パケットロス情報の消去を実施してもよい。
ここで、本実施の形態におけるＴＣＰ処理部１２００のＤｕｐＡｃｋ管理部１２３０によるＤｕｐＡｃｋ複製数算出方法のアルゴリズムについて図３４を用いて説明する。
図３４は、本実施の形態におけるＤｕｐＡｃｋ複製数算出方法のアルゴリズムを示すフローチャートである。
ＤｕｐＡｃｋ管理部１２３０は、Ｗｉｎｄｏｗ制御部１２５０からＷｉｎ更新の通知を受けると、保持しているＤｕｐＡｃｋ送信数が１以上でかつＮ未満かどうかを調査する（ステップＳ１００）。さらに、ＤｕｐＡｃｋ管理部１２３０は、ロス通知部５０００によるロス通知が行われ、パケットロス情報が記録されているか否かを調査する（ステップＳ１０２）。
即ち、ステップＳ１００において、ＤｕｐＡｃｋ管理部１２３０は、自分が管理するＤｕｐＡｃｋ送信数が０以下または（Ｎ＋１）以上の場合は（ステップＳ１００のＮ）、ＤｕｐＡｃｋ複製数を「０」とする（ステップＳ１０４）。一方、保持しているＤｕｐＡｃｋ送信数が１以上でかつＮ未満の場合は（ステップＳ１００のＹ）、ＤｕｐＡｃｋ管理部１２３０はステップＳ１０２の処理を実行する。なお、Ｎは、送信側装置に対して再送を実行させるのに必要なＤｕｐＡｃｋの数（所定数または必要数）である。
ステップＳ１０２において、ロス通知部５０００からのパケットロス情報が記録されていた場合は（ステップＳ１０２のＹ）、ＤｕｐＡｃｋ管理部１２３０は、ＤｕｐＡｃｋ複製数を式「Ｎ−ＤｕｐＡｃｋ送信数」で算出する（ステップＳ１０６）。一方、パケットロス情報が記録されていない場合は（ステップＳ１０２のＮ）、ＤｕｐＡｃｋ管理部１２３０は、ＤｕｐＡｃｋ複製数を「０」とする（ステップＳ１０４）。
例えば、本実施の形態では、上述のＤｕｐＡｃｋ複製数算出方法のアルゴリズムの開始時において、ＤｕｐＡｃｋ管理部１２３０は、ＤｕｐＡｃｋ送信数「２」とロス通知部５０００からパケットロス情報を受け取り保持（記録）している。したがって、ステップＳ１００では、ＤｕｐＡｃｋ送信数が「２」であるため、ＤｕｐＡｃｋ管理部１２３０は、ステップＳ１０２の処理を実行する。そして、ステップＳ１０２では、ＤｕｐＡｃｋ管理部１２３０は、パケットロス情報を保持しているため、ＤｕｐＡｃｋ複製数をＮ＝３およびＤｕｐＡｃｋ送信数「２」より算出する。よって、「ＤｕｐＡｃｋ複製数＝Ｎ−ＤｕｐＡｃｋ送信数」よりＤｕｐＡｃｋ複製数は「１」になる。
なお、上記Ｎは送信側装置２００Ａが高速再送を発動する数であることが望ましい。また、本実施の形態では、Ｎを一例として３としているが、ＤｕｐＡｃｋのネットワークでのパケットロスを回避する条件ということで、３以上としてもよい。大きい値は特に、ネットワークの品質が悪く、経路上でＤｕｐＡｃｋが消失しやすい場合に有効である。ただし、この値が大きいということは、ネットワークのトラヒックを増やすことに繋がるため、無用に大きくすることは好ましくない。望ましくは３、大きくても４が好ましい。
このように本実施の形態では、以上の処理を行なうことで、送信側装置２００Ａに高速再送を発動させＴＣＰの再送によるスループット低下を押さえる効果と、受信側装置１００Ａ内でのパケットロスである場合にのみ送信側装置２００Ａの高速再送を発動させる効果と、ネットワークを過負荷状態にしない効果と、複製するＤｕｐＡｃｋによる無駄なトラフィックを抑える効果と、ＤｕｐＡｃｋ送信に要する受信側装置１００ＡのＣＰＵの消費を抑える効果と、誤ったＤｕｐＡｃｋを送信しない効果とがある。
（変形例１）
ここで上記実施の形態１０における第１の変形例について説明する。
上記実施の形態１０では、受信側装置１００Ａは通信部１０５Ａにおけるデータロスを検知したが、本変形例に係る受信側装置１００ＡはＩＰ処理部１３００におけるデータロスを検知する。
なお、本変形例について、上記実施の形態１０に共通していない部分に関してのみ説明する。
図３５は、上記実施の形態１０における第１の変形例のネットワーク構成例および通信装置の構成例を示す図である。
通信部１０５Ａは、システムバス１０３Ａ上に接続されたハードウェアであって、上記実施の形態１０の通信部１０５Ａのようにデータロス検知部１５０Ａを備えていない。この通信部１０５Ａは、ＣＰＵ１０１Ａによって渡されたデータをネットワーク３Ａに送信する機能と、ネットワーク３Ａから受信したデータを受信する機能とを有する。また、通信部１０５Ａは、ネットワーク３Ａから受信したデータを一時的に保持する受信用ＦＩＦＯメモリ１５１Ａと、ＣＰＵ１０１Ａから渡されたデータを一時的に保持する送信用ＦＩＦＯメモリ１５２Ａとを備える。
本変形例に係るＣＰＵ１０１Ａのプログラムによって実現される機能構成について図３６を用いて説明する。
図３６は、受信側装置１００ＡにおけるＣＰＵ１０１Ａの機能構成を示す構成図である。なお図３６中、実線はデータの流れを示すデータフロー、点線は制御信号の流れを示す制御フローである。受信側装置１００Ａの受信または送信するパケットを処理するパケット処理部の詳細な構成として、受信側装置１００ＡのＣＰＵ１０１Ａは、ＡＰＩ部１１００、ＴＣＰ処理部１２００、ＩＰ処理部１３００、およびＭＡＣ処理部１５００を備える。図３６の各機能部の説明を以下に示す。ＡＰＩ部１１００およびＴＣＰ処理部１２００に関しては、上記実施の形態１０の機能と全く同様であるため説明を省略する。
本変形例に係るＭＡＣ処理部１５００は、上記実施の形態１０におけるＭＡＣ処理部１５００と異なりロス通知部５０００を備えず、ＭＡＣ受信部１５１０およびＭＡＣ送信部１５２０のみを備える。このＭＡＣ受信部１５１０およびＭＡＣ送信部１５２０は、上記実施の形態１０と同様の機能を有する。
ＩＰ処理部１３００は、上記実施の形態１０のＩＰ処理部１３００と同様に、ＩＦ処理部１４００から受け取ったＩＰパケットからＴＣＰパケットを抽出し、ＴＣＰ処理部１２００に受け渡す。また、ＩＰ処理部１３００は、ＴＣＰ処理部１２００から受け取ったＴＣＰパケットにＩＰヘッダを追加してＩＰパケットを構築してＩＦ処理部１４００に渡す。このようなＩＰ処理部１３００は、上記実施の形態１０のＩＰ処理部１３００と異なり、受信用ＦＩＦＯキュー１３１０とデータロス検知部１５０Ａとロス通知部５０００とを備える。
受信用ＦＩＦＯキュー１３１０は、ＩＦ処理部１４００から渡されるデータを一時的に格納する領域である。この領域には、記憶部１０２Ａの領域のうちの一部が割り当てられ、受信用ＦＩＦＯキュー１３１０は、その領域に格納されるデータを管理する機能をもつ。即ち、受信用ＦＩＦＯキュー１３１０は、ＩＦ処理部１４００から受け取ったデータを受け取った順番にＩＰ処理部１３００に処理させる（First-In First-Out）ように管理している。
データロス検知部１５０Ａは、受信用ＦＩＦＯキュー１３１０において受信オーバーランが発生したことを検知し、ロスが発生したことをロス通知部５０００にパケットロス通知（Ｅ１５０）を通知する。
ロス通知部５０００は、データロス検知部１５０Ａからパケットロス通知（Ｅ１５０）を受け取り、ロスが発生したことを通知するパケットロス情報を、ＴＣＰ処理部１２００のＤｕｐＡｃｋ管理部１２３０に渡す。なお、パケットロス通知（Ｅ１５０）にＩＰアドレス、プロトコルやポート番号を含む場合は、ロス通知部５０００は、ＩＰアドレス、プロトコルおよびポート番号を含むパケットロス情報をＤｕｐＡｃｋ管理部１２３０に渡す。
図３７は、本変形例に係る受信側装置１００Ａにおける処理シーケンスの例を示す図である。即ち、この図３７は、受信側装置１００ＡがＳｅｑ＝１（Ｐ２１）のパケットを受信し、ＷｉｎＵｐｄａｔｅ（Ｐ１６）を送信するまでの処理シーケンスを示す。なお、図３７中、点線で囲まれた“通信部”は、図３５の通信部１０５Ａを示し、点線で囲まれた“ＭＡＣ”は、図３６のＭＡＣ処理部１５００を示し、点線で囲まれた“ＩＦ”は、図３６のＩＦ処理部１４００を示し、点線で囲まれた“ＩＰ”は、図３６のＩＰ処理部１３００を示す。さらに図３７中、点線で囲まれた“ＴＣＰ”は、図３６のＴＣＰ処理部１２００を示し、点線で囲まれた“ＡＰＩ”は、図３６のＡＰＩ部１１００を示し、点線で囲まれた“アプリケーション”は、図３６のアプリケーションプログラムを示す。
この図３７に示す処理シーケンスは、図３３に示す処理シーケンスと比べて、Ｓｅｑ＝２のパケット（Ｐ２２）に対する受信側装置１００Ａでのパケットロス検知の受信処理シーケンスのみが異なる。以下、この受信処理シーケンスに関してのみ説明する。
図３７の処理フローに沿って、受信側装置１００ＡによるＳｅｑ＝２（Ｐ２２）のパケットに対する処理シーケンス（Ｐ２２、Ｐ２２１、Ｅ１５０）を説明する。
通信装置（送信側装置）２００Ａから送信されたＳｅｑ＝２のパケット（Ｐ２２）は、ネットワーク３Ａを介し通信装置（受信側装置）１００Ａの通信部１０５Ａにより受信処理される。
ＭＡＣ処理部１５００のＭＡＣ受信部１５１０は、通信部１０５Ａの受信用ＦＩＦＯメモリ１５１Ａより読み出されたパケット（Ｐ２２）を受け取る。読み出されたＳｅｑ＝２のパケット（Ｐ２２）は、ＩＦ処理部１４００を介して、ＩＰ処理部１３００の受信用ＦＩＦＯキュー１３１０に渡される（データフローＰ２２１）。
ここで、ＩＦ処理部１４００からＩＰ処理部１３００の受信用ＦＩＦＯキュー１３１０にＩＰパケットを渡す処理の速度または量が、ＩＰ処理部１３００においてＩＰパケットからＴＣＰパケットを抽出してそのＴＣＰパケットをＴＣＰ処理部１２００に渡す処理の速度または量をこえてしまい、受信用ＦＩＦＯキュー１３１０においてオーバーランが発生する。データロス検知部１５０Ａは、ロス通知部５０００にロスが発生したことを通知する（Ｅ１５０）。ロス通知部５０００は、受信用ＦＩＦＯキュー１３１０におけるオーバーランが発生したというパケットロス通知を受け、ＴＣＰ処理部１２００のＤｕｐＡｃｋ管理部１２３０にパケットロス情報を渡す。
なお、本変形例では、ＩＰ処理部１３００に受信用ＦＩＦＯキュー１３１０があるとして説明を行ったが、ＩＦ処理部１４００に同様の受信用ＦＩＦＯキューを持つときには、ＩＦ処理部１４００にデータロス検知部およびロス通知部を設けてもよい。また、ロスしたデータを調査し、特定のプロトコル（例えば、ＩＰｖ４、ＩＰｖ６）であった場合のみに通知しても良い。
また、データロス検知部１５０Ａにおいて、ロスしたデータを調査し、特定のプロトコル（例えばＴＣＰ）であった場合にのみ、そのロスを通知してもよい。
さらに、データロス検知部１５０Ａにおいて、ロスしたデータのアドレスや、ポート番号をパケットロス通知に付加してもよい。また、ＤｕｐＡｃｋ管理部１２３０において、受け取ったＩＰアドレスや、ポート番号に基づいて、ロスの判定をしてもよい。
このように本変形例では、以上の処理を行なうことで、送信側装置２００Ａに高速再送を発動させＴＣＰの再送によるスループット低下を押さえる効果と、受信側装置１００Ａ内での特定のＴＣＰパケットのパケットロスである場合にのみ送信側装置２００Ａの高速再送を発動させる効果と、ネットワークを過負荷状態にしない効果と、複製するＤｕｐＡｃｋによる無駄なトラフィックを抑える効果と、誤ったＤｕｐＡｃｋを送信しない効果とがある。
（変形例２）
ここで上記実施の形態１０における第２の変形例について説明する。
上記実施の形態１０では、ＭＡＣ処理部１５００でＤｕｐＡｃｋを複製したが、本変形例では、ＴＣＰ処理部１２００でＤｕｐＡｃｋを複製する。
以下、本変形例について、上記実施の形態１０に共通していない部分に関してのみ説明する。
図３８は、上記実施の形態１０における第２の変形例に係るＣＰＵ１０１Ａの機能構成を示す構成図である。実線はデータの流れを示すデータフロー、点線は制御信号の流れを示す制御フローである。受信側装置１００Ａの受信または送信するパケットを処理するパケット処理部の詳細な構成として、受信側装置１００ＡのＣＰＵ１０１Ａは、ＡＰＩ部１１００、ＴＣＰ処理部１２００、ＩＰ処理部１３００、およびＭＡＣ処理部１５００を備える。図３８の各機能部の説明を以下に示す。なお、ＡＰＩ部１１００、ＩＰ処理部１３００、およびＩＦ処理部１４００に関しては、上記実施の形態１０の機能と全く同様であるため説明を省略する。
本変形例に係るＴＣＰ処理部１２００は、パケット複製部７０００を備えたＴＣＰ送信部１２２０に特徴がある。
ＴＣＰ送信部１２２０は、Ａｃｋ生成部１２８０、ＷｉｎＵｐｄａｔｅ生成部１２６０、およびＤｕｐＡｃｋ生成部１２７０から受け取ったＴＣＰパケット（Ａｃｋ、ＷｉｎＵｐｄａｔｅ、およびＤｕｐＡｃｋ）に、必要なＴＣＰヘッダ情報を設定し、そのＴＣＰヘッダ情報が設定されたＴＣＰパケットをＩＰ処理部１３００に渡す。また、ＴＣＰ送信部１２２０は、パケット複製部７０００が複製したＤｕｐＡｃｋをＩＰ処理部１３００に渡す。
パケット複製部７０００は、ＤｕｐＡｃｋ管理部１２３０に問い合わせて得たＤｕｐＡｃｋ複製数に基づいて、そのＤｕｐＡｃｋ複製数だけＤｕｐＡｃｋを複製し、複製したＤｕｐＡｃｋをＩＰ処理部１３００に渡すように、ＴＣＰ送信部１２２０に対して指示する。
なお、本変形例では、このパケット複製部７０００が、ＤｕｐＡｃｋをデータ要求パケットとして生成する第２のパケット生成手段として構成されている。
ＭＡＣ処理部１５００は、上記実施の形態１０におけるＭＡＣ処理部１５００と異なり、パケット複製部７０００を備えていない。ＭＡＣ受信部１５１０、ＭＡＣ送信部１５２０、およびロス通知部５０００は、上記実施の形態１０と同様の機能を有する。
ここで、図３３に示す処理シーケンスを用いて、本変形例における受信側装置１００Ａでの処理を説明する。なお、本変形例では、図３３中、点線で囲まれた“通信部”は、図３０の通信部１０５Ａを示し、点線で囲まれた“ＭＡＣ”は、図３８のＭＡＣ処理部１５００を示し、点線で囲まれた“ＩＦ”は、図３８のＩＦ処理部１４００を示し、点線で囲まれた“ＩＰ”は、図３８のＩＰ処理部１３００を示す。さらに、図３３中、点線で囲まれた“ＴＣＰ”は、図３８のＴＣＰ処理部１２００を示し、点線で囲まれた“ＡＰＩ”は、図３８のＡＰＩ部１１００を示し、点線で囲まれた“アプリケーション”は、図３８のアプリケーションプログラムを示す。
本変形例では、図３３に示すＳｅｑ＝２のＤｕｐＡｃｋパケット（Ｐ１５）の複製（データフローＰ１５１）に特徴があり、この点に関してのみ説明する。
受信完了通知を受けたＷｉｎｄｏｗ制御部１２５０は、受信バッファ１２４０にバッファの空き容量を問い合わせ、問い合わせ結果からＷｉｎ＝４を算出する。そしてＷｉｎｄｏｗ制御部１２５０は、算出したＷｉｎをＤｕｐＡｃｋ管理部１２３０に通知する。Ｗｉｎを受け取ったＤｕｐＡｃｋ管理部１２３０は、制御フローＥ１００におけるパケットロス情報を保持しているため、ＤｕｐＡｃｋ送信数の「２」と所定の数である「３」からＤｕｐＡｃｋ複製数を所定の方法（図３４に示すＤｕｐＡｃｋ複製数算出方法）により算出する。算出したＤｕｐＡｃｋ複製数は「１」であるため、ＤｕｐＡｃｋ管理部１２３０は、保持していたＤｕｐＡｃｋ情報（Ｓｅｑ＝２およびＷｉｎ＝３）をＤｕｐＡｃｋ生成部１２７０に渡し、算出したＤｕｐＡｃｋ複製数を保持する。ＤｕｐＡｃｋ管理部１２３０は、ＤｕｐＡｃｋ情報をＤｕｐＡｃｋ生成部に渡した後に、Ｗｉｎｄｏｗ制御部１２５０から受け取ったＷｉｎ＝４をＷｉｎＵｐｄａｔｅ生成部１２６０に渡す。ＤｕｐＡｃｋ生成部１２７０は、受け取ったＤｕｐＡｃｋ情報よりＤｕｐＡｃｋ（Ｎｕｍ＝２およびＷｉｎ＝３）を作成してＴＣＰ送信部１２２０のパケット複製部７０００に渡す。
パケット複製部７０００は、ＤｕｐＡｃｋ生成部１２７０より受け取ったＤｕｐＡｃｋを、ＤｕｐＡｃｋ管理部１２３０より問い合わせて得たＤｕｐＡｃｋ複製数だけ複製してＴＣＰ送信部１２２０に送信させる。上述の例では、ＤｕｐＡｃｋ複製数は「１」であるため、パケット複製部７０００は、受け取ったＤｕｐＡｃｋを複製せずにその１つのＤｕｐＡｃｋをＴＣＰ送信部１２２０に送信するように指示する。ただし、ＤｕｐＡｃｋ複製数がＮ（≧２）である場合は、パケット複製部７０００は、ＤｕｐＡｃｋを複製してＤｕｐＡｃｋの数を合計Ｎ個にし、ＴＣＰ送信部１２２０に対して、複製したＤｕｐＡｃｋ（複製元のＤｕｐＡｃｋを含む）をすべて送信するように指示する。
ＴＣＰ送信部１２２０は、パケット複製部７０００に送信するように指示されたＤｕｐＡｃｋをＩＰ処理部１３００に渡す。そしてＤｕｐＡｃｋは、ＩＦ処理部１４００を経て、パケット構築され、ＭＡＣ処理部１５００のＭＡＣ送信部１５２０により通信部１０５ＡのＦＩＦＯメモリ１５２Ａに書き込まれる。
このように本変形例では、以上の処理を行なうことにより、パケット数などをＴＣＰで管理している場合に複製するＤｕｐＡｃｋの数を管理しやすくなる。さらに、既存の通信モジュールにパケット複製部を導入する場合にＴＣＰ処理部内で改修をすることとなり、改修箇所を限定することができる。
（変形例３）
ここで上記実施の形態１０における第３の変形例について説明する。
上記実施の形態１０では、受信側装置１００Ａは、Ｗｉｎｄｏｗの状態に基づくタイミングでＤｕｐＡｃｋを複製して送信したが、本変形例に係る受信側装置１００Ａは、Ｗｉｎｄｏｗの状態に変わらずに１回目のＤｕｐＡｃｋの送信のタイミングでそのＤｕｐＡｃｋを複製して送信する。
以下、本変形例について、上記実施の形態１０に共通していない部分に関してのみ説明する。
本変形例に係るＴＣＰ処理部１２００は、ＤｕｐＡｃｋ管理部１２３０に特徴がある。
ＤｕｐＡｃｋ管理部１２３０は、ＴＣＰロス検知部１２１５から受け取ったＳｅｑを受け取った場合に、その受け取ったＳｅｑと、Ｗｉｎｄｏｗ制御部１２５０に問い合わせて得たＷｉｎとをＤｕｐＡｃｋ情報とし、そのＤｕｐＡｃｋ情報からＤｕｐＡｃｋ複製数を算出して保持する。さらに、ＤｕｐＡｃｋ管理部１２３０は、ＤｕｐＡｃｋ情報をＤｕｐＡｃｋ生成部１２７０に渡し、その渡した回数をＤｕｐＡｃｋ送信数としてカウントする。
ＤｕｐＡｃｋ管理部１２３０は、パケット複製部７０００の問い合わせに対して算出したＤｕｐＡｃｋ複製数を通知する。なお、本変形例においては、ＤｕｐＡｃｋ管理部１２３０が算出したＤｕｐＡｃｋ複製数については、パケット単位での管理を例に説明する。
さらに、ＤｕｐＡｃｋ管理部１２３０は、ＤｕｐＡｃｋ複製数をパケット複製部７０００に通知すると、パケットロス通知部５０００から受け取ったパケットロス情報を消去し、さらにＤｕｐＡｃｋ複製数を初期値する機能を持つ。ＤｕｐＡｃｋ複製数の初期値としては、「１」を例に説明する。また、ＤｕｐＡｃｋ送信数の初期値としては、「０」を例に説明する。
図３９は、本変形例に係る通信装置間の通信シーケンスを示す図である。なお、上記実施の形態１０と同様、この通信シーケンスは、受信側装置１００Ａの性能が低い（例えばＣＰＵの性能が１３３ＭＨｚ）場合のシーケンス例を示す。
受信側装置１００Ａは、Ｓｅｑ＝３のデータの受信に対し、Ａｃｋを送信側装置２００Ａに送信する。このＡｃｋ（Ｐ１３）のパラメータは、Ｎｕｍ＝２およびＷｉｎ＝３を示す。これは、受信側装置１００Ａが、Ｓｅｑ＝１のデータの後に、Ｓｅｑ＝３のデータを受信したため、Ｓｅｑ＝２のデータが不足していることを検知したためである。Ｓｅｑ＝２を要求するＡｃｋは、Ｓｅｑ＝１の受信時に既に送信されており、このＡｃｋ（Ｐ１３）はＳｅｑ＝２のデータが到達していないことを伝えるＤｕｐＡｃｋとなる。このＤｕｐＡｃｋ（Ｐ１３）のＷｉｎは、Ｓｅｑ＝１に対するＡｃｋ（Ｐ１２）のＷｉｎと同じである。これは、Ｓｅｑ＝１のデータに対するアプリケーションプログラムでの受信処理が完了していないためである。
本変形例に係る受信側装置１００Ａは、１回目のＤｕｐＡｃｋを送信したとき、Ｓｅｑ＝２のデータが到達していないと検知しているため、前回送信したＤｕｐＡｃｋ（Ｐ１３）を複製したＤｕｐＡｃｋ（Ｐ１４）を送信側装置２００Ａへ送信する。
そして、受信側装置１００Ａは、Ｓｅｑ＝４のデータの受信に対し、Ｓｅｑ＝３のデータを受信した場合と同様に、Ｓｅｑ＝２を要求するＤｕｐＡｃｋ（Ｐ１５）を送信側装置２００Ａへ送信する。送信側装置２００Ａは、ＤｕｐＡｃｋを３つ（Ｐ１３、Ｐ１４、Ｐ１５）を受信したため、Ｓｅｑ＝２の再送データ（Ｐ２５）を高速再送する。
図４０は、受信側装置１００Ａにおける処理シーケンスの例を示す図である。具体的に、図４０は、受信側装置１００ＡがＳｅｑ＝１（Ｐ２１）のデータを受信し、３つめのＤｕｐＡｃｋ（Ｐ１５）を送信するまでの処理シーケンスの例を示す。
以下、図４０の処理フローに沿って、受信側装置１００ＡがＳｅｑ＝３のパケット（Ｐ２３）を受信してからＡｃｋ（Ｐ１５）を送信するまでの処理シーケンス（Ｐ２３１、Ｐ１３１、Ｐ１３、Ｐ１４、Ｐ２４１、およびＰ１４１）を説明する。なお、図４０中、点線で囲まれた“通信部”は、図３０の通信部１０５Ａを示し、点線で囲まれた“ＭＡＣ”は、図３１のＭＡＣ処理部１５００を示し、点線で囲まれた“ＩＦ”は、図３１のＩＦ処理部１４００を示す。さらに、図４０中、点線で囲まれた“ＩＰ”は、図３１のＩＰ処理部１３００を示し、点線で囲まれた“ＴＣＰ”は、図３１のＴＣＰ処理部１２００を示し、点線で囲まれた“ＡＰＩ”は、図３１のＡＰＩ部１１００を示し、点線で囲まれた“アプリケーション”は、図３１のアプリケーションプログラムを示す。
ＭＡＣ処理部１５００のＭＡＣ受信部１５１０は、通信部１０５Ａの受信用ＦＩＦＯメモリ１５１Ａより読み出されたデータ（ＭＡＣフレーム）（Ｐ２３）を受け取る。読み出されたＳｅｑ＝３のデータ（ＭＡＣフレーム）は、ＩＦ処理部１４００およびＩＰ処理部１３００により非パケット化処理され、ＴＣＰ受信部１２１０にＴＣＰパケットとして渡される（データフローＰ２３１）。
ＴＣＰ受信部１２１０は、Ｓｅｑ＝３のＴＣＰパケットのＴＣＰヘッダの解析処理を行い、非パケット化処理を完了する。このときＳｅｑ＝３のＴＣＰパケットは、ＴＣＰロス検知部１２１５において、Ｓｅｑ＝２のデータが到着していないため、順序通りではないデータであると判断される。ＴＣＰ受信部１２１０は、Ｓｅｑ＝３のデータを受信バッファ１２４０に渡し、ＴＣＰロス検知部１２１５は順序どおりで届くはずのシーケンスナンバー（Ｓｅｑ＝２）をＤｕｐＡｃｋ管理部１２３０に渡す。受信バッファ１２４０は、順序通りに到着しなかったデータを、その順序通りのデータが到着するまで保持するように管理する。
ＤｕｐＡｃｋ管理部１２３０は、受け取ったＳｅｑ（Ｓｅｑ＝２）と、Ｗｉｎｄｏｗ制御部１２５０を介して、受信バッファ１２４０に現在受信可能なＷｉｎを問い合わせた結果のＷｉｎ（Ｗｉｎ＝３）とをＤｕｐＡｃｋ情報として、ＤｕｐＡｃｋ生成部１２７０に渡し、ＤｕｐＡｃｋ送信数を「１」にカウントする。ＤｕｐＡｃｋ生成部１２７０は、受け取ったＤｕｐＡｃｋ情報よりＤｕｐＡｃｋ（Ｎｕｍ＝２およびＷｉｎ＝３）を作成してＴＣＰ送信部１２２０に渡す。
さらに、ＤｕｐＡｃｋ管理部１２３０は、制御フローＥ１００において、ロス通知部５０００から受け取ったパケットロス情報を保持しているため、このときに、ＤｕｐＡｃｋの複製数をＤｕｐＡｃｋ複製数算出方法により算出する。本変形例に係るＤｕｐＡｃｋ複製数算出方法では、Ｗｉｎ＝３、ＭＳＳ＝１、および所定の数＝３より、ＤｕｐＡｃｋ複製数は「２」として算出される（本変形例に係るＤｕｐＡｃｋ複製数算出方法の詳細については後述する）。
なお、ＤｕｐＡｃｋ管理部１２３０は、１つめのＤｕｐＡｃｋ作成時にＳｅｑとＷｉｎを保持しておき、ＤｕｐＡｃｋ作成から再送によるＴｉｍｅＯｕｔの経過前までの所定の時間が経過した後に、ＳｅｑとＷｉｎをＤｕｐＡｃｋ生成部１２７０に渡し、ＤｕｐＡｃｋの足りない分（複製数）の複製数を算出してもよい。
なお、ＤｕｐＡｃｋ管理部１２３０は、１つめのＤｕｐＡｃｋ作成時にＳｅｑとＷｉｎを保持しておき、ＤｕｐＡｃｋ作成から再送によるＴｉｍｅＯｕｔの経過前までにＣＰＵの使用率が所定の閾値以下になったときに、ＳｅｑとＷｉｎをＤｕｐＡｃｋ生成部１２７０に渡し、ＤｕｐＡｃｋの足りない分（複製数）の複製数を算出してもよい。
次に、ＴＣＰ送信部１２２０はＤｕｐＡｃｋを出力し、そのＤｕｐＡｃｋは、ＩＰ処理部１３００およびＩＦ処理部１４００を経て、パケット構築される（データフローＰ１３１）。ＭＡＣ送信部１５２０のパケット複製部７０００は、ＤｕｐＡｃｋ管理部１２３０から問い合わせて得たＤｕｐＡｃｋ複製数の「２」により、ＩＦ処理部１４００から受け取ったＭＡＣフレームをＭＡＣ送信部１５２０に２つ分送信するように指示する。ＭＡＣ送信部１５２０は、受け取ったＭＡＣフレームを複製して、２つのＭＡＣフレームを通信部１０５Ａの送信用ＦＩＦＯメモリ１５２Ａに書き込む。
通信部１０５Ａの送信用ＦＩＦＯメモリ１５２Ａに書き込まれた２つのＤｕｐＡｃｋ（ＭＡＣフレームＰ１３，Ｐ１４）はネットワーク３Ａを介して送信側装置２００Ａへ送信される。
ＤｕｐＡｃｋ管理部１２３０は、パケット（Ｐ１４）を送信した直後に、ロス通知部５０００から受け取ったパケットロス情報を消去する。さらに、ＤｕｐＡｃｋ複製数を「１」に初期化する。
次に、ＭＡＣ処理部１５００のＭＡＣ受信部１５１０は、通信部１０５Ａの受信用ＦＩＦＯメモリ１５１Ａより読み出されたパケット（ＭＡＣフレーム（Ｐ２４））を受け取る。読み出されたＳｅｑ＝４のパケット（ＭＡＣフレーム）は、ＩＦ処理部１４００およびＩＰ処理部１３００により非パケット化処理され、ＴＣＰ受信部１２１０にＴＣＰパケットとして渡される（データフローＰ２４１）。
ＴＣＰ受信部１２１０は、Ｓｅｑ＝３のＴＣＰパケットのＴＣＰヘッダの解析処理を行い、非パケット化処理を完了する。このときＳｅｑ＝３のデータは、ＴＣＰロス検知部１２１５において、Ｓｅｑ＝２データが到着していないため、順序通りではないデータであると判断される。ＴＣＰ受信部１２１０は、Ｓｅｑ＝３のデータを受信バッファ１２４０に渡し、ＴＣＰロス検知部１２１５は順序どおりで届くはずのシーケンスナンバー（Ｓｅｑ＝２）をＤｕｐＡｃｋ管理部１２３０に渡す。受信バッファ１２４０は、順序通りに到着しなかったデータを、その順序通りのデータが到着するまで保持するように管理する。
ＤｕｐＡｃｋ管理部１２３０は、Ｗｉｎｄｏｗ制御部１２５０を介して、受信バッファ１２４０に現在受信可能なＷｉｎを問い合わせ、問い合わせて得たＷｉｎと、ＴＣＰロス検知部１２１５より受け取ったＳｅｑとをＤｕｐＡｃｋ情報として保持する。ＤｕｐＡｃｋ管理部１２３０は、ＤｕｐＡｃｋ生成部１２７０にＤｕｐＡｃｋ情報を渡す。ＤｕｐＡｃｋ生成部１２７０は、受け取ったＤｕｐＡｃｋ情報（Ｓｅｑ＝２およびＷｉｎ＝３）から、Ｎｕｍ＝２およびＷｉｎ＝３を示すパケット（Ｐ１５）を生成し、生成したＤｕｐＡｃｋをＴＣＰ送信部１２２０に渡す。このとき、ＤｕｐＡｃｋ管理部１２３０は、ロス通知部５０００からのパケットロス情報を受け取っていないため、ＤｕｐＡｃｋ複製数を算出しない。ＤｕｐＡｃｋ複製数は「１」のままである。
次に、ＴＣＰ送信部１２２０はＤｕｐＡｃｋを出力し、そのＤｕｐＡｃｋは、ＩＰ処理部１３００およびＩＦ処理部１４００を経て、パケット構築される（データフローＰ１４１）。パケット構築されたＤｕｐＡｃｋ（ＭＡＣフレーム）は、ＭＡＣ処理部１５００のＭＡＣ送信部１５２０に取得される。このときパケット複製部７０００は、ＤｕｐＡｃｋ管理部１２３０にＤｕｐＡｃｋ複製数を問い合わせて、複製数が「１」であることを把握する。複製数が「１」であることにより、ＭＡＣ送信部１５２０は、ＭＡＣフレームを通信部１０５Ａの送信用ＦＩＦＯメモリ１５２Ａに１つだけ書き込む。
ＭＡＣ送信部１５２０により通信部１０５Ａの送信用ＦＩＦＯメモリ１５１Ａに書き込まれたＭＡＣフレームは、ネットワーク３Ａを介して送信側装置２００Ａへとパケットとして送信される。これが、３つ目のＤｕｐＡｃｋとなり、送信側装置２００Ａは高速再送を発動する。
図４１は、本変形例におけるＴＣＰ処理部１２００のＤｕｐＡｃｋ管理部１２３０によるＤｕｐＡｃｋ複製数算出方法のアルゴリズムを示すフローチャートである。
ＤｕｐＡｃｋ管理部１２３０は、ＴＣＰロス検知部１２１５からＳｅｑを受けると、Ｗｉｎｄｏｗ制御部１２５０から問い合わせて得たＷｉｎを、ＭＳＳ（Max Section Size）で除算した商（Ｗｉｎ／ＭＳＳ）から「２」を減算した結果が、所定の数（高速再送に必要とされるＤｕｐＡｃｋの数「Ｎ」であって、例えばＮ＝３）未満かどうかを調査する（ステップＳ２００）。なお、上述のＭＳＳは、送信側装置２００Ａが１回に送信可能な最大のデータ長であって、本変形例では例えば「１」である。
さらに、ＤｕｐＡｃｋ管理部１２３０は、ロス通知部５０００により受け取ったパケットロス情報が記録されているか否かを調査する（ステップＳ２０２）。
即ち、ステップＳ２００において、ＤｕｐＡｃｋ管理部１２３０は、ＷｉｎをＭＳＳで除算した商（Ｗｉｎ／ＭＳＳ）から「２」を減算した結果が、所定の数「Ｎ」以上の場合は（ステップＳ２００のＮ）、ＤｕｐＡｃｋ複製数を「１」とする（ステップＳ２０４）。一方、ＷｉｎをＭＳＳで除算した商（Ｗｉｎ／ＭＳＳ）から「２」を減算した結果が、所定の数「Ｎ」未満の場合は（ステップＳ２００のＹ）、ＤｕｐＡｃｋ管理部１２３０はステップＳ２０２の処理を実行する。
ステップＳ２０２において、ロス通知部５０００からのパケットロス情報が記録されていた場合は（ステップＳ２０２のＹ）、ＤｕｐＡｃｋ管理部１２３０は、ＤｕｐＡｃｋ複製数を式「ＤｕｐＡｃｋ複製数＝Ｎ−｛（Ｗｉｎ／ＭＳＳ）−２｝」により算出する。一方、パケットロス情報が記録されていない場合は（ステップＳ２０２のＮ）、ＤｕｐＡｃｋ管理部１２３０は、ＤｕｐＡｃｋ複製数を「１」とする（ステップＳ２０４）。
具体的に、本変形例では、ＤｕｐＡｃｋ管理部１２３０は、まず、Ｗｉｎｄｏｗ制御部１２５０からＷｉｎ＝３を得る。また、ＭＳＳは例えば「１」であって、ロス通知部５０００からのパケットロス情報が記録されている。
このような場合、ＤｕｐＡｃｋ管理部１２３０は、ステップＳ２００において、（（Ｗｉｎ／ＭＳＳ）−２＝３／１−２＝１）＜（Ｎ＝３）であるため、ステップＳ２０２の処理を行う。
そして、ステップＳ２０２において、ＤｕｐＡｃｋ管理部１２３０は、パケットロス情報が記録されていると判断して、ステップＳ２０６においてＤｕｐＡｃｋ複製数＝３−｛（３／１）−２｝＝２を算出する。
なお、ＤｕｐＡｃｋ管理部１２３０は、ステップＳ２０６において、ＤｕｐＡｃｋ複製数を所定の数「Ｎ」として算出してもよい。
このように本変形例では、以上の処理を行なうことで、送信側装置２００Ａに高速再送を最も速く発動させＴＣＰの再送によるスループット低下を押さえる効果と、受信側装置１００Ａ内でのパケットロスである場合にのみ送信側装置２００Ａの高速再送を発動させる効果と、ネットワークを過負荷状態にしない効果と、複製するＤｕｐＡｃｋによる無駄なトラフィックを抑える効果と、ＤｕｐＡｃｋの送信に要する受信側装置１００ＡのＣＰＵの消費を抑える効果と、誤ったＤｕｐＡｃｋを送信しないという効果とがある。
以上のように、本発明について実施の形態１〜１０およびその変形例を用いて説明したが、ブロック図（図８、図３０および図３５など）の各機能ブロックは典型的には集積回路であるＬＳＩとして実現される。これらは個別に１チップ化されても良いし、一部又は全てを含むように１チップ化されても良い（例えばメモリ以外の機能ブロックが１チップ化されていても良い。）。
ここでは、ＬＳＩとしたが、集積度の違いにより、ＩＣ、システムＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩと呼称されることもある。
また、集積回路化の手法はＬＳＩに限るものではなく、専用回路又は汎用プロセサで実現してもよい。ＬＳＩ製造後に、プログラムすることが可能なＦＰＧＡ（Field Programmable Gate Array）や、ＬＳＩ内部の回路セルの接続や設定を再構成可能なリコンフィギュラブル・プロセッサーを利用しても良い。
さらには、半導体技術の進歩又は派生する別技術によりＬＳＩに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積化を行ってもよい。バイオ技術の適応等が可能性としてありえる。
また、各機能ブロックのうち、符号化または復号化の対象となるデータを格納する手段だけ１チップ化せずに別構成としても良い。
本発明の通信装置は、データの送信トラフィックを自らの受信能力に応じて自発的に制御し得るとともに、その制御処理負担を軽減することができるという効果を奏し、例えばＴＣＰおよびＴＣＰと同等のウィンドウ制御機能および確認応答機能を持つ通信プロトコルに基づいて受信処理を行うあらゆる通信装置に適用可能である。
図１は、ＴＣＰにおけるデータ送受信シーケンス図である。 図２は、高速再送機能に関するパケット送受信シーケンス図である。 図３は、ネット家電の構成図である。 図４は、データ転送効率が低下してしまう場合におけるデータ転送の一例を示すシーケンス図である。 図５は、高速な受信側装置におけるパケット送受信シーケンス図である。 図６は、低速な受信側装置におけるパケット送受信シーケンス図である。 図７は、従来技術におけるＴＣＰ送受信シーケンス図である。 図８は、本発明の実施の形態１に係るネットワークと通信装置の構成の一例を示す構成図である。 図９は、本発明の実施の形態１に係る処理部の機能構成例を示す構成図である。 図１０は、本発明の実施の形態１におけるパケット送受信のシーケンス図である。 図１１は、本発明の実施の形態２に係る処理部の機能構成例を示した構成図である。 図１２は、本発明の実施の形態２におけるパケット送受信のシーケンス図である。 図１３は、本発明の実施の形態２における受信側装置の動作を示すフローチャートである。 図１４は、本発明の実施の形態３に係る処理部の機能構成例を示した構成図である。 図１５は、本発明の実施の形態３におけるパケット送受信のシーケンス図である。 図１６は、本発明の実施の形態４におけるパケット送受信のシーケンス図である。 図１７は、本発明の実施の形態５に係る処理部の機能構成例を示した構成図である。 図１８は、本発明の実施の形態５におけるパケット送受信のシーケンス図である。 図１９は、本発明の実施の形態５における他のパケット送受信のシーケンス図である。 図２０は、本発明の実施の形態６におけるパケット送受信のシーケンス図である。 図２１は、本発明の実施の形態６における他のパケット送受信のシーケンス図である。 図２２は、本発明の実施の形態７に係る処理部の機能構成例を示した構成図である。 図２３は、本発明の実施の形態７におけるパケット送受信のシーケンス図である。 図２４は、本発明の実施の形態７における他のパケット送受信のシーケンス図である。 図２５は、本発明の実施の形態８に係る処理部の機能構成例を示した構成図である。 図２６は、本発明の実施の形態８におけるパケット送受信のシーケンス図である。 図２７は、本発明の実施の形態８における他のパケット送受信のシーケンス図である。 図２８は、本発明の実施の形態９に係る処理部の機能構成例を示した構成図である。 図２９は、本発明の実施の形態９におけるパケット送受信のシーケンス図である。 図３０は、本発明の実施の形態１０におけるネットワークの構成例および通信装置の構成例を示す図である。 図３１は、本発明の実施の形態１０における通信装置のＣＰＵの機能構成を示す構成図である。 図３２は、本発明の実施の形態１０における通信装置間の通信シーケンスを示す図である。 図３３は、本発明の実施の形態１０における受信側装置における処理シーケンスの例を示す図である。 図３４は、本発明の実施の形態１０におけるＤｕｐＡｃｋ管理部におけるＤｕｐＡｃｋ複製数算出処理を示すフローチャートである。 図３５は、実施の形態１０の変形例１に係るネットワーク構成例および通信装置の構成例を示す図である。 図３６は、実施の形態１０の変形例１に係る受信側装置のＣＰＵの機能構成を示す構成図である。 図３７は、実施の形態１０の変形例１に係る受信側装置の処理シーケンスの例を示す図である。 図３８は、実施の形態１０の変形例２に係る受信側装置のＣＰＵの機能構成を示す構成図である。 図３９は、実施の形態１０の変形例３に係る通信装置間の通信シーケンスを示す図である。 図４０は、実施の形態１０の変形例３に係る受信側装置の処理シーケンスの例を示す図である。 図４１は、実施の形態１０の変形例３に係るＤｕｐＡｃｋ管理部におけるＤｕｐＡｃｋ複製数算出処理を示すフローチャートである。
符号の説明
１ 受信側装置
２ システムバス
３ 処理部
４ 記憶部
５ 通信部
６ ＦＩＦＯ
７ ネットワーク
８ 送信側装置
３１ 受信側装置
３２ システムバス
３３ 処理部
３４ 記憶部
３５ 通信部
３６ ＦＩＦＯ
３７ ネットワーク
３８ 送信側装置
４１ ＩＰ処理部
４２ ＴＣＰ処理部
４３ アプリケーション処理部
４４ ＴＣＰパケット処理部
４５ ＡＣＫ生成部
４６ ウィンドウ更新通知生成部
４７ 受信バッファ
４８ ウィンドウサイズ算出部
４９ ウィンドウ更新タイマ部
５０ 受信レート決定部
５１ 前回ＲＷＩＮ記憶部
６１ ＩＰ処理部
６２ ＴＣＰ処理部
６３ アプリケーション処理部
６４ ＴＣＰパケット処理部
６５ ＡＣＫ生成部
６６ ウィンドウ更新通知生成部
６７ 受信バッファ
６８ ウィンドウサイズ算出部
６９ ウィンドウ更新タイマ部
７０ 受信レート決定部
７１ 前回ＲＷＩＮ記憶部
８１ ＩＰ処理部
８２ ＴＣＰ処理部
８３ アプリケーション処理部
８４ ＴＣＰパケット処理部
８５ ＡＣＫ生成部
８６ ウィンドウ更新通知生成部
８７ 受信バッファ
８８ ウィンドウサイズ算出部
８９ ウィンドウ更新タイマ部
９０ 受信レート決定部
９１ 前回ＲＷＩＮ記憶部
１０１ ＩＰ処理部
１０２ ＴＣＰ処理部
１０３ アプリケーション処理部
１０４ ＴＣＰパケット処理部
１０５ ＡＣＫ生成部
１０６ ウィンドウ更新通知生成部
１０７ 受信バッファ
１０８ ウィンドウサイズ算出部
１０９ ウィンドウ更新タイマ部
１１０ 受信レート決定部
１１１ 前回ＲＷＩＮ記憶部
１１２ ＡＣＫ遅延部
１２１ ＩＰ処理部
１２２ ＴＣＰ処理部
１２３ アプリケーション処理部
１２４ ＴＣＰパケット処理部
１２５ ＡＣＫ生成部
１２６ ウィンドウ更新通知生成部
１２７ 受信バッファ
１２８ ウィンドウサイズ算出部
１２９ ウィンドウ更新タイマ部
１３０ 受信レート決定部
１３１ 前回ＲＷＩＮ記憶部
１４１ ＩＰ処理部
１４２ ＴＣＰ処理部
１４３ アプリケーション処理部
１４４ ＴＣＰパケット処理部
１４５ ＡＣＫ生成部
１４６ ウィンドウ更新通知生成部
１４７ 受信バッファ
１４８ ウィンドウサイズ算出部
１４９ 前回ＲＷＩＮ記憶部
１５０ パケットロス検知部
１６１ ＩＰ処理部
１６２ ＴＣＰ処理部
１６３ アプリケーション処理部
１６４ ＴＣＰパケット処理部
１６５ ＡＣＫ生成部
１６６ 重複ＡＣＫ生成部
１６７ 受信バッファ
１６８ ウィンドウサイズ算出部
１６９ パケット抜け検知部

Claims (24)

  1. 他の通信装置から送信されたデータを受信する受信手段と、
    前記受信手段によって受信されたデータに対する前記他の通信装置への応答内容を示す確認応答パケットを生成し、前記他の通信装置に送信する第１のパケット生成手段と、
    自装置が受信可能なデータの受信サイズを示す情報が含まれるデータ要求パケットであって、前記他の通信装置に対してデータの送信を要求するデータ要求パケットを生成し、前記他の通信装置に送信する第２のパケット生成手段と、
    前記受信サイズに更新量を加算することで、当該受信サイズを更新するサイズ算出手段と、
    自装置の通信能力に基づいて、前記データ要求パケットを送信する時間間隔である更新時間と前記更新量とを決定する更新決定手段と、を備え、
    前記第２のパケット生成手段は、前記受信手段によるデータの受信結果に関わらず、前記更新時間の経過ごとに、前記サイズ算出手段に前記受信サイズを更新させて前記データ要求パケットを送信することを特徴とする通信装置。
  2. 前記受信手段は、受信されたデータを一時的に保持するためのメモリを有する物理層通信デバイスとして構成され、
    前記更新決定手段は、前記メモリの容量と、前記メモリに保持されたデータの転送能力とに基づいて、前記更新時間および前記更新量を決定する
    ことを特徴とする請求項１記載の通信装置。
  3. 前記更新決定手段は、さらに、前記通信装置で動作するアプリケーションプログラムが必要とするビットレートに基づいて、前記更新時間を決定する
    ことを特徴とする請求項１記載の通信装置。
  4. 前記第２のパケット生成手段は、前記更新時間の経過ごとに、前記データ要求パケットを生成しているときに、前記受信手段によってデータが受信されると、前記データ要求パケットの生成を中止する
    ことを特徴とする請求項１記載の通信装置。
  5. 前記第２のパケット生成手段は、前記更新時間の経過ごとに行われる前記データ要求パケットの生成を中止しているときに、前記受信手段によってデータが受信されると、前記更新時間の経過ごとに行われる前記データ要求パケットの生成を再開する
    ことを特徴とする請求項４記載の通信装置。
  6. 前記第１のパケット生成手段は、受信可能なデータのサイズを応答サイズとして示す前記確認応答パケットを生成し、
    前記更新時間の経過ごとに行われる前記データ要求パケットの生産が中止しているときに、先に送信されてロスしたデータが再送されて前記受信手段によって受信された際には、
    前記第１のパケット生成手段は、前回生成された前記確認応答パケットの応答サイズよりも小さい応答サイズを示す確認応答パケットを生成し、
    前記第２のパケット生成手段は、前記更新時間の経過ごとに行われる前記データ要求パケットの生産を再開する
    ことを特徴とする請求項４記載の通信装置。
  7. 前記通信装置は、さらに、前記更新時間の経過ごとに行われる前記データ要求パケットの生産が中止しているときに、前記第１のパケット生成手段による前記確認応答パケットの送信のタイミングを遅らせる遅延手段を備える
    ことを特徴とする請求項４記載の通信装置。
  8. 前記受信手段は、受信されたデータを一時的に保持するためのメモリを有する物理層通信デバイスとして構成され、
    前記通信装置は、さらに、前記メモリの容量と、前記メモリに保持されたデータの転送能力とに基づいて、前記確認応答パケットの送信間隔を決定する送信間隔決定手段を備え、
    前記遅延手段は、前記送信間隔決定手段によって決定された送信間隔で複数の前記確認応答パケットが送信されるように、前記タイミングを遅らせる
    ことを特徴とする請求項７記載の通信装置。
  9. 前記通信装置は、さらに、前記通信装置で動作するアプリケーションプログラムが必要とするビットレートに基づいて、前記確認応答パケットの送信間隔を決定する送信間隔決定手段を備え、
    前記遅延手段は、前記送信間隔決定手段によって決定された送信間隔で複数の前記確認応答パケットが送信されるように、前記タイミングを遅らせる
    ことを特徴とする請求項７記載の通信装置。
  10. 前記第２のパケット生成手段は、前記受信手段によって受信されたデータの受信量が閾値を超えたときに、前記更新時間の経過ごとに行われる前記データ要求パケットの生成を開始する
    ことを特徴とする請求項１記載の通信装置。
  11. 前記通信装置は、さらに、
    前記他の通信装置から送信されたデータのロスを検出する検出手段を備え、
    前記第１のパケット生成手段は、受信可能なデータのサイズを応答サイズとして示す前記確認応答パケットを生成し、前記検出手段によってロスが検出されたときには、前回生成された確認応答パケットの応答サイズよりも小さい応答サイズを示す確認応答パケットを生成する
    ことを特徴とする請求項１記載の通信装置。
  12. 前記第１のパケット生成手段は、さらに、前記検出手段によって所定時間にロスが検出されなかったときには、前回生成された確認応答パケットの応答サイズよりも大きい応答サイズを示す確認応答パケットを生成する
    ことを特徴とする請求項１１記載の通信装置。
  13. 前記第１のパケット生成手段は、前回生成された確認応答パケットの応答サイズと、ロスしたデータの量との差分を前記小さい応答サイズとして示す前記確認応答パケットを生成する
    ことを特徴とする請求項１１記載の通信装置。
  14. 前記第２のパケット生成手段は、
    前記他の通信装置によって順次送信されたデータが予め定められた順序通りに前記受信手段に受信されなかった場合、または、前記データがロスした場合に送信されるべき否定応答パケットとして、前記データ要求パケットを生成する
    ことを特徴とする請求項１記載の通信装置。
  15. 前記第２のパケット生成手段は、データのロスが発生した場合に、ロス発生の直前に前記受信手段で受信されたデータに対する確認応答パケットと同一の内容を示す、所定数の前記データ要求パケットを生成して送信する
    ことを特徴とする請求項１４記載の通信装置。
  16. 前記受信手段で受信されたデータのうち、消失したロスデータを検知するロス検知手段を備え、
    前記第１のパケット生成手段は、
    前記他の通信装置からのデータの送信に対する確認応答として、前記ロス検知手段によって検知されたロスデータの再送を指示する前記確認応答パケットを、前記他の通信装置に送信し、
    前記第２のパケット生成手段は、
    前記第１のパケット生成手段により送信される確認応答パケットの送信数が、前記他の通信装置に対して前記ロスデータの再送を実行させるだけの必要数に満たない場合に、前記他の通信装置からのデータの送信に関わらず、前記必要数から送信数を差し引いた複製数だけ、前記確認応答パケットを前記データ要求パケットとして前記他の通信装置に送信する
    ことを特徴とする請求項１４記載の通信装置。
  17. 前記受信手段は、メモリを備え、前記他の通信装置から送信されるデータを順次取得して前記メモリに格納し、
    前記ロス検知手段は、前記メモリに格納されずに消失したロスデータを検知する
    ことを特徴とする請求項１６記載の通信装置。
  18. 前記第２のパケット生成手段は、前記第１のパケット生成手段によって確認応答パケットが生成されるときに前記複製数を算出する
    ことを特徴とする請求項１６記載の通信装置。
  19. 前記第２のパケット生成手段は、
    前記第１のパケット生成手段によって確認応答パケットが送信されてから所定期間が経過する前に、前記確認応答パケットが送信されてから所定期間が経過する前であって且つ前記通信装置の負荷率が所定の閾値以下になったとき、または、前記通信装置の受信可能なデータ量が増加したことを前記通信装置が前記他の通信装置に通知する前に、前記複製数を算出する
    ことを特徴とする請求項１６記載の通信装置。
  20. 前記第２のパケット生成手段は、前記通信装置で受信可能なデータ量に基づいて前記複製数を算出する
    ことを特徴とする請求項１６記載の通信装置。
  21. 前記第２のパケット生成手段は、
    前記第１のパケット生成手段によって最初の確認応答パケットが送信されるときに、前記受信可能なデータ量に基づいて、前記第１のパケット生成手段から送信される予定の送信数を算出し、前記必要数から前記送信数を差し引くことにより、前記複製数を算出する
    ことを特徴とする請求項２０記載の通信装置。
  22. 他の通信装置から送信されたデータを受信する受信ステップと、
    前記受信ステップで受信されたデータに対する前記他の通信装置への応答内容を示す確認応答パケットを生成し、前記他の通信装置に送信する第１のパケット生成ステップと、
    自装置が受信可能なデータの受信サイズを示す情報が含まれるデータ要求パケットであって、前記他の通信装置に対してデータの送信を要求するデータ要求パケットを生成し、前記他の通信装置に送信する第２のパケット生成ステップと、
    サイズ算出手段が、前記受信サイズに更新量を加算することで、当該受信サイズを更新するステップと、
    自装置の通信能力に基づいて、前記データ要求パケットを送信する時間間隔である更新時間と前記更新量とを決定するステップと、を備え、
    前記第２のパケット生成ステップでは、前記受信ステップでのデータの受信結果に関わらず、前記更新時間の経過ごとに、前記サイズ算出手段に前記受信サイズを更新させて前記データ要求パケットを送信する
    ことを特徴とする通信方法。
  23. 他の通信装置から送信されたデータを受信する受信ステップと、
    前記受信ステップで受信されたデータに対する前記他の通信装置への応答内容を示す確認応答パケットを生成し、前記他の通信装置に送信する第１のパケット生成ステップと、
    コンピュータが受信可能なデータの受信サイズを示す情報が含まれるデータ要求パケットであって、前記他の通信装置に対してデータの送信を要求するデータ要求パケットを生成し、前記他の通信装置に送信する第２のパケット生成ステップと、
    サイズ算出手段が、前記受信サイズに更新量を加算することで、当該受信サイズを更新するステップと、
    前記コンピュータの通信能力に基づいて、前記データ要求パケットを送信する時間間隔である更新時間と前記更新量とを決定するステップと、を前記コンピュータに実行させ、
    前記第２のパケット生成ステップでは、前記受信ステップでのデータの受信結果に関わらず、前記更新時間の経過ごとに、前記サイズ算出手段に前記受信サイズを更新させて前記データ要求パケットを送信する
    ことを特徴とするプログラム。
  24. 他の通信装置から送信されたデータを受信する受信手段と、
    前記受信手段によって受信されたデータに対する前記他の通信装置への応答内容を示す確認応答パケットを生成し、前記他の通信装置に送信する第１のパケット生成手段と、
    集積回路が受信可能なデータの受信サイズを示す情報が含まれるデータ要求パケットであって、前記他の通信装置に対してデータの送信を要求するデータ要求パケットを生成し、前記他の通信装置に送信する第２のパケット生成手段と、
    前記受信サイズに更新量を加算することで、当該受信サイズを更新するサイズ算出手段と、
    前記集積回路の通信能力に基づいて、前記データ要求パケットを送信する時間間隔である更新時間と前記更新量とを決定する更新決定手段と、を備え、
    前記第２のパケット生成手段は、前記受信手段によるデータの受信結果に関わらず、前記更新時間の経過ごとに、前記サイズ算出手段に前記受信サイズを更新させて前記データ要求パケットを送信することを特徴とする集積回路。
JP2007539872A 2005-10-03 2006-10-02 通信装置、通信方法、プログラムおよび集積回路 Expired - Fee Related JP4777996B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2007539872A JP4777996B2 (ja) 2005-10-03 2006-10-02 通信装置、通信方法、プログラムおよび集積回路

Applications Claiming Priority (6)

Application Number Priority Date Filing Date Title
JP2005290576 2005-10-03
JP2005290576 2005-10-03
JP2006197892 2006-07-20
JP2006197892 2006-07-20
PCT/JP2006/319661 WO2007043373A1 (ja) 2005-10-03 2006-10-02 通信装置
JP2007539872A JP4777996B2 (ja) 2005-10-03 2006-10-02 通信装置、通信方法、プログラムおよび集積回路

Publications (2)

Publication Number Publication Date
JPWO2007043373A1 JPWO2007043373A1 (ja) 2009-04-16
JP4777996B2 true JP4777996B2 (ja) 2011-09-21

Family

ID=37942617

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2007539872A Expired - Fee Related JP4777996B2 (ja) 2005-10-03 2006-10-02 通信装置、通信方法、プログラムおよび集積回路

Country Status (7)

Country Link
US (1) US20090268747A1 (ja)
EP (1) EP1933509A1 (ja)
JP (1) JP4777996B2 (ja)
KR (1) KR20080053334A (ja)
CN (1) CN101278529B (ja)
TW (1) TW200723782A (ja)
WO (1) WO2007043373A1 (ja)

Families Citing this family (49)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9189307B2 (en) 2004-08-06 2015-11-17 LiveQoS Inc. Method of improving the performance of an access network for coupling user devices to an application server
US8009696B2 (en) 2004-08-06 2011-08-30 Ipeak Networks Incorporated System and method for achieving accelerated throughput
US9647952B2 (en) 2004-08-06 2017-05-09 LiveQoS Inc. Network quality as a service
US7769014B2 (en) * 2007-02-13 2010-08-03 Seiko Epson Corporation Transmitting and receiving system, transmitting apparatus, and receiving apparatus
TWI355164B (en) * 2007-02-27 2011-12-21 Quanta Comp Inc Data transmitting method for wireless communicatio
JP4587053B2 (ja) * 2007-08-28 2010-11-24 日本電気株式会社 通信装置、通信システム、パケット欠落検出方法、およびパケット欠落検出プログラム
JP4557028B2 (ja) * 2008-03-19 2010-10-06 ソニー株式会社 情報処理装置、情報処理方法、クライアント機器、情報処理システム
JP5247215B2 (ja) * 2008-04-04 2013-07-24 キヤノン株式会社 通信装置及びその制御方法
US9270477B2 (en) * 2008-05-28 2016-02-23 Airmagnet, Inc. Method and apparatus of measuring and reporting data gap from within an analysis tool
JP5406558B2 (ja) * 2009-02-24 2014-02-05 キヤノン株式会社 データ処理装置、データ処理方法およびプログラム
JP5460088B2 (ja) * 2009-03-17 2014-04-02 キヤノン株式会社 情報処理装置、情報処理方法およびプログラム
US8300535B2 (en) * 2009-02-24 2012-10-30 Canon Kabushiki Kaisha Information processing apparatus, method thereof, and storage medium
US8325601B2 (en) * 2009-05-08 2012-12-04 Canon Kabushiki Kaisha Reliable network streaming of a single data stream over multiple physical interfaces
JP2011081769A (ja) * 2009-09-14 2011-04-21 Ricoh Co Ltd データ転送装置、データ転送デバイスおよびデータ転送方法
JP4821904B2 (ja) * 2009-10-23 2011-11-24 エヌイーシーコンピュータテクノ株式会社 データ通信システム及びデータ通信方法
WO2011074454A1 (ja) * 2009-12-14 2011-06-23 日本電気株式会社 パケット再送制御システム、方法、及びプログラム
US8370725B2 (en) * 2010-02-01 2013-02-05 Mosys, Inc. Communication interface and protocol
US8964543B1 (en) * 2010-02-16 2015-02-24 Google Inc. System and method of reducing latency by transmitting duplicate packets over a network
JP5682618B2 (ja) * 2010-03-03 2015-03-11 日本電気株式会社 パケット再送制御システム、方法、及びプログラム
US9137278B2 (en) * 2010-04-08 2015-09-15 Vasona Networks Inc. Managing streaming bandwidth for multiple clients
JP5601029B2 (ja) * 2010-05-27 2014-10-08 ソニー株式会社 通信装置及び通信方法、並びにコンピューター・プログラム
WO2012066824A1 (ja) * 2010-11-16 2012-05-24 株式会社日立製作所 通信装置および通信システム
US8683285B2 (en) * 2010-12-29 2014-03-25 Plx Technology, Inc. Parallel packetized interconnect with simplified data link layer
US10951743B2 (en) 2011-02-04 2021-03-16 Adaptiv Networks Inc. Methods for achieving target loss ratio
JP5329581B2 (ja) 2011-02-04 2013-10-30 株式会社東芝 無線通信端末および無線通信方法
US8717900B2 (en) 2011-02-07 2014-05-06 LivQoS Inc. Mechanisms to improve the transmission control protocol performance in wireless networks
US9590913B2 (en) 2011-02-07 2017-03-07 LiveQoS Inc. System and method for reducing bandwidth usage of a network
JP5780050B2 (ja) 2011-08-17 2015-09-16 富士通株式会社 伝送システム
WO2013035897A1 (en) * 2011-09-06 2013-03-14 Alcatel Lucent A method for avoiding network congestion and an apparatus thereof
EP2757724B1 (en) * 2011-09-16 2016-11-09 Huawei Technologies Co., Ltd. Method for transmitting fragments and device for transmitting fragments
JP5814829B2 (ja) * 2012-03-01 2015-11-17 株式会社東芝 無線通信装置及び方法
JP6146409B2 (ja) * 2012-05-30 2017-06-14 日本電気株式会社 通信装置および通信方法
US9444727B2 (en) * 2012-10-16 2016-09-13 Cisco Technology, Inc. Duplicating traffic along local detours before path remerge to increase packet delivery
US9986063B2 (en) * 2012-11-28 2018-05-29 Panasonic Intellectual Property Management Co., Ltd. Receiving terminal and receiving method
US20150012792A1 (en) * 2013-07-03 2015-01-08 Telefonaktiebolaget L M Ericsson (Publ) Method and apparatus for providing a transmission control protocol minimum retransmission timer
US9584425B2 (en) * 2013-08-20 2017-02-28 Brocade Communications Systems, Inc. Bandwidth optimization using coalesced DUP ACKs
US9760577B2 (en) * 2013-09-06 2017-09-12 Red Hat, Inc. Write-behind caching in distributed file systems
CN105393589B (zh) * 2013-09-29 2019-08-02 华为技术有限公司 一种数据传输的方法及设备
US9706923B2 (en) * 2014-02-25 2017-07-18 General Electric Company System and method for adaptive interference mitigation in wireless sensor network
KR102187810B1 (ko) * 2014-09-26 2020-12-08 삼성전자주식회사 통신 시스템에서 데이터 흐름 제어 장치 및 방법
JP5881071B1 (ja) 2014-11-20 2016-03-09 パナソニックＩｐマネジメント株式会社 無線通信装置、無線通信システム及び無線通信方法
JP6455135B2 (ja) * 2014-12-24 2019-01-23 富士通株式会社 パケット抽出装置、パケット抽出プログラムおよびパケット抽出方法
US10768997B2 (en) 2016-12-05 2020-09-08 International Business Machines Corporation Tail latency-based job offloading in load-balanced groups
US10700978B2 (en) 2016-12-05 2020-06-30 International Business Machines Corporation Offloading at a virtual switch in a load-balanced group
US20180159922A1 (en) * 2016-12-05 2018-06-07 International Business Machines Corporation Job assignment using artificially delayed responses in load-balanced groups
CN109698762B (zh) * 2017-10-24 2020-10-23 华为技术有限公司 一种调整参数的方法及参数调整装置
CN114221905A (zh) * 2020-09-03 2022-03-22 阿里巴巴集团控股有限公司 处理单元及流控制单元、以及相关方法
US11323309B1 (en) 2021-01-14 2022-05-03 Juniper Networks, Inc. Asynchronous socket replication between nodes of a network
US11570116B1 (en) 2021-03-10 2023-01-31 Juniper Networks, Inc. Estimating standby socket window size during asynchronous socket replication

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH09191321A (ja) * 1996-01-08 1997-07-22 Nec Corp 適応クレジット制御型転送方法
JPH1127308A (ja) * 1997-07-01 1999-01-29 Kokusai Denshin Denwa Co Ltd <Kdd> インターネット対応リンクモニタ方法
JP2004032757A (ja) * 2002-06-18 2004-01-29 Matsushita Electric Ind Co Ltd 最適化された受信側始動型送信レート増大方法
JP2004523992A (ja) * 2001-04-04 2004-08-05 テレフオンアクチーボラゲット エル エム エリクソン（パブル） データフロー制御方法

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20010024445A1 (en) * 2000-02-23 2001-09-27 Takuro Noda Communication system, communication device and communication method
EP1137217A1 (en) * 2000-03-20 2001-09-26 Telefonaktiebolaget Lm Ericsson ARQ parameter negociation in a data packet transmission system using link adaptation
US7142508B2 (en) * 2000-12-22 2006-11-28 Radiance Technologies, Inc. System and method for controlling data transfer rates on a network
US7500010B2 (en) * 2005-04-07 2009-03-03 Jeffrey Paul Harrang Adaptive file delivery system and method

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH09191321A (ja) * 1996-01-08 1997-07-22 Nec Corp 適応クレジット制御型転送方法
JPH1127308A (ja) * 1997-07-01 1999-01-29 Kokusai Denshin Denwa Co Ltd <Kdd> インターネット対応リンクモニタ方法
JP2004523992A (ja) * 2001-04-04 2004-08-05 テレフオンアクチーボラゲット エル エム エリクソン（パブル） データフロー制御方法
JP2004032757A (ja) * 2002-06-18 2004-01-29 Matsushita Electric Ind Co Ltd 最適化された受信側始動型送信レート増大方法

Also Published As

Publication number Publication date
JPWO2007043373A1 (ja) 2009-04-16
WO2007043373A9 (ja) 2007-06-14
WO2007043373A1 (ja) 2007-04-19
CN101278529B (zh) 2011-10-19
CN101278529A (zh) 2008-10-01
EP1933509A1 (en) 2008-06-18
KR20080053334A (ko) 2008-06-12
US20090268747A1 (en) 2009-10-29
TW200723782A (en) 2007-06-16

Similar Documents

Publication Publication Date Title
JP4777996B2 (ja) 通信装置、通信方法、プログラムおよび集積回路
US7835273B2 (en) Method for transmitting data in mobile ad hoc network and network apparatus using the same
EP2887595B1 (en) Method and node for retransmitting data packets in a tcp connection
JP4283589B2 (ja) 通信装置、通信制御方法及びプログラム
JP4147534B2 (ja) 通信装置および通信方法
US20080037420A1 (en) Immediate ready implementation of virtually congestion free guaranteed service capable network: external internet nextgentcp (square waveform) TCP friendly san
WO2009026854A1 (fr) Procédé de commande d&#39;envoi de données et dispositif de transmission de données
JP5786853B2 (ja) パケット再送制御装置、パケット再送制御方法、パケット再送制御プログラム
JP2006229955A (ja) 無線ネットワーク環境で伝送遅延による不要な再伝送を減少させるための方法及びそれを用いた通信装置
AU2005308530A1 (en) Immediate ready implementation of virtually congestion free guaranteed service capable network: external internet NextGenTCP (square wave form) TCP friendly san
US20090316579A1 (en) Immediate Ready Implementation of Virtually Congestion Free Guaranteed Service Capable Network: External Internet Nextgentcp Nextgenftp Nextgenudps
WO2017107148A1 (zh) 一种数据传输方法及网络侧设备
JP2006050295A (ja) データパケット伝送方法及びシステム
Zeng et al. TCP packet control for wireless networks
JP2004140596A (ja) Ｔｃｐ上のデータ転送における品質を推定する方法およびシステム
KR101231793B1 (ko) Ｔｃｐ 세션 최적화 방법 및 네트워크 노드
JP2006279867A (ja) Ａｄｓｌ通信装置、プログラム及び方法
TWI308012B (en) Method for adaptive estimation of retransmission timeout in wireless communication systems
KR100915996B1 (ko) 대역폭변화에 따른 적응형 전송 제어 프로토콜을 이용한데이터 패킷 전송 방법 및 그를 위한 송신측 단말장치
Zhu et al. Performance of Tahoe, Reno, and SACK TCP at Different Scenarios
Diwakar et al. A Survey on TCP Congestion Control and its Variants for Wireless Networks
JP5375313B2 (ja) 通信装置、擬似応答装置、送信レート制御方法およびプログラム
JP2017158047A (ja) 中継装置、中継方法及び中継プログラム
Sathiaseelan et al. Robust TCP (TCP-R) with explicit packet drop notification (EPDN) for satellite networks
Akhtar et al. Modified Tahoe TCP for wireless networks using OPNET simulator

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20090907

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20110405

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20110513

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20110607

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20110630

R150 Certificate of patent or registration of utility model

Free format text: JAPANESE INTERMEDIATE CODE: R150

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20140708

Year of fee payment: 3

LAPS Cancellation because of no payment of annual fees