(57)【要約】  環境的な制約を受けることなく効率的なデータ転送を可能とする通信装置は、ネットワーク（３００）を介して接続された送信側装置（２００）に対して、データ量をウィンドウサイズとして通知することにより、送信側装置（２００）から送信されたウィンドウサイズ分のデータを受信する通信装置であって、送信側装置（２００）から送信されたデータパケットを記憶するための領域を有する受信用バッファメモリ（１２０）と、受信用バッファメモリ（１２０）の容量よりも大きいウィンドウサイズを送信側装置（２００）に通知し、通知されたウィンドウサイズに応じて送信側装置（２００）から送信されたデータパケットを受信して受信用バッファメモリ（１２０）に格納する通信プロトコル処理部（１３０）と、受信用バッファメモリ（１２０）に格納されたデータパケットを取り出して処理する中央制御部（１４０）とを備える。
2008023656.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークを介して接続された通信相手装置に対して、データ量をウィンドウサイズとして通知することにより、前記通信相手装置から送信された前記ウィンドウサイズ分のデータを受信する通信装置であって、
前記通信相手装置から送信されたデータを記憶するための記憶手段と、
前記記憶手段の容量よりも大きい前記ウィンドウサイズを前記通信相手装置に通知するサイズ通知手段と、
前記サイズ通知手段により通知された前記ウィンドウサイズに応じて前記通信相手装置から送信されたデータを受信して前記記憶手段に格納する受信手段と、
前記記憶手段に格納されたデータを取り出して処理する処理手段と
を備えることを特徴とする通信装置。
【請求項２】
前記通信相手装置は、前記サイズ通知手段により通知されたウィンドウサイズ分のデータを複数のデータパケットとして順次送信し、
前記受信手段は、前記複数のデータパケットを順次受信して前記記憶手段に格納し、
前記通信装置は、さらに、
前記記憶手段に格納されたデータパケットを廃棄することにより、前記記憶手段の空き容量を確保する廃棄手段と、
前記廃棄手段により廃棄されたデータパケットの再送を前記通信相手装置に対して要求する再送要求手段とを備える
ことを特徴とする請求項１記載の通信装置。
【請求項３】
前記再送要求手段は、さらに、前記受信手段によって受信されたが前記記憶手段に格納されなかったデータパケットの再送を前記通信相手装置に対して要求する
ことを特徴とする請求項２記載の通信装置。
【請求項４】
前記処理手段は、前記記録手段に格納されているデータパケットを予め定められた順序で取り出し、
前記廃棄手段は、
前記処理手段による前記順序に従った、前記記憶手段からのデータパケットの取り出しが滞り、前記記憶手段に新たなデータパケットを格納する容量がないときに、前記記憶手段に記憶されているデータパケットを廃棄する
ことを特徴とする請求項２記載の通信装置。
【請求項５】
前記再送要求手段は、
前記廃棄手段により廃棄されたデータパケットを示す否定応答パケットを、前記データパケットを前記通信相手装置から再送させるのに必要な数だけ、前記通信相手装置に送信することにより、前記データパケットの再送を前記通信相手装置に要求する
ことを特徴とする請求項４記載の通信装置。
【請求項６】
前記廃棄手段は、前記サイズ通知手段により通知されたウィンドウサイズに応じて前記通信相手装置から順次送信されるデータパケットのうち、最後に送信されるデータパケットが最終パケットとして前記記憶手段に格納されるように、前記最終パケットを除く他のデータパケットを前記記憶手段から廃棄する
ことを特徴とする請求項４記載の通信装置。
【請求項７】
前記再送要求手段は、
前記記憶手段に格納されている前記最終パケットと他のデータパケットとを示す肯定応答パケットを前記通信相手装置に送信することにより、前記最終パケットと他のデータパケットの間に送信された複数のデータパケットの一括した再送を前記通信相手装置に要求する
ことを特徴とする請求項６記載の通信装置。
【請求項８】
前記通信装置が複数の通信フローのそれぞれで同時にデータを受信するときには、
前記サイズ通知手段は、各通信フローのウィンドウサイズの合計が前記記憶手段の容量よりも大きくなるように、通信フローごとにウィンドウサイズを設定して通知し、
前記受信手段は、複数の通信フローごとにデータを受信して前記記憶手段に格納する
ことを特徴とする請求項１記載の通信装置。
【請求項９】
前記通信装置は、さらに、
前記各通信フローに対する優先度を決定する優先度決定手段を備え、
前記サイズ通知手段は、通信フローに対して決定された優先度が高いほど、前記通信フローに対して大きなウィンドウサイズを設定する
ことを特徴とする請求項８記載の通信装置。
【請求項１０】
前記優先度決定手段は、前記処理手段において実行されるアプリケーションプログラムに応じて前記優先度を決定する
ことを特徴とする請求項９記載の通信装置。
【請求項１１】
前記優先度決定手段は、動画像の転送を行う通信フローに対して、動画像以外のデータの転送を行う通信フローよりも高い優先度を決定する
ことを特徴とする請求項９記載の通信装置。
【請求項１２】
前記サイズ通知手段は、前記通信フローの数が多いほど小さくなるようなウィンドウサイズを設定する
ことを特徴とする請求項８記載の通信装置。
【請求項１３】
前記サイズ通知手段は、前記通信フローで使用される伝送路の伝搬遅延時間に応じて前記通信フローに対するウィンドウサイズを設定する
ことを特徴とする請求項８記載の通信装置。
【請求項１４】
前記サイズ通知手段は、前記通信フローで使用される伝送路の伝搬遅延時間が長いほど大きなウィンドウサイズを前記通信フローに対して設定する
ことを特徴とする請求項１３記載の通信装置。
【請求項１５】
前記サイズ通知手段は、前記通信フローで使用される伝送路の伝搬遅延時間が短いほど大きなウィンドウサイズを前記通信フローに対して設定する
ことを特徴とする請求項１３記載の通信装置。
【請求項１６】
前記サイズ通知手段は、前記通信フローにおける伝送帯域が広いほど大きいウィンドウサイズを前記通信フローに対して設定する
ことを特徴とする請求項８記載の通信装置。
【請求項１７】
前記サイズ通知手段は、前記記憶手段の空き容量が閾値以下になると、前記各通信フローに対して設定されているウィンドウサイズを小さくする
ことを特徴とする請求項８記載の通信装置。
【請求項１８】
前記サイズ通知手段は、前記記憶手段の全体の容量に応じて前記閾値を決定する
ことを特徴とする請求項１７記載の通信装置。
【請求項１９】
ネットワークを介して接続された通信相手装置に対して、データ量をウィンドウサイズとして通知することにより、前記通信相手装置から送信された前記ウィンドウサイズ分のデータを受信する通信方法であって、
前記通信相手装置から送信されたデータを記憶するための記憶手段の容量よりも大きい前記ウィンドウサイズを前記通信相手装置に通知するサイズ通知ステップと、
前記サイズ通知ステップで通知された前記ウィンドウサイズに応じて前記通信相手装置から送信されたデータを受信して前記記憶手段に格納する受信ステップと、
前記記憶手段に格納されたデータを取り出して処理する処理ステップと
を含むことを特徴とする通信方法。
【請求項２０】
ネットワークを介して接続された通信相手装置に対して、データ量をウィンドウサイズとして通知することにより、前記通信相手装置から送信された前記ウィンドウサイズ分のデータを受信するためのプログラムであって、
前記通信相手装置から送信されたデータを記憶するための記憶手段の容量よりも大きい前記ウィンドウサイズを前記通信相手装置に通知するサイズ通知ステップと、
前記サイズ通知ステップで通知された前記ウィンドウサイズに応じて前記通信相手装置から送信されたデータを受信して前記記憶手段に格納する受信ステップと、
前記記憶手段に格納されたデータを取り出して処理する処理ステップと
をコンピュータに実行させることを特徴とするプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信装置に関し、特に、ＴＣＰ／ＩＰ（Transmission Control Protocol/Internet Protocol）を用いてデータを受信する通信装置に関する。
【背景技術】
【０００２】
ＴＣＰ／ＩＰネットワークにおけるデータ転送において、データはパケットと呼ばれる単位で送受信される。【０００３】
送信側装置はパケットを受信側装置に送信する。受信側装置は、送信側装置から送信されたパケットを受け取ると、肯定応答パケット（Acknowledgement Packet：以下ＡＣＫパケットという）を送信側装置に送信する。送信側装置は、受信側装置から送信されたＡＣＫパケットを受け取ることにより、送信側装置によって送信されたパケットが受信側装置に受信されたことを確認する。【０００４】
送信側装置がＡＣＫパケットを得ることなしに受信側装置に送り続けることが可能なデータ量は、ウィンドウサイズによって制限されている。このウィンドウサイズは、一般的には、受信側装置が受信したデータを保持できる最大量を上限（ＲＷＩＮ）とし、ネットワークの輻輳状態などに応じて増減される。理想的な状況では、ネットワークの輻輳がなく、ウィンドウサイズはＲＷＩＮの値で安定している状態となる。【０００５】
したがって、送信側装置がネットワークを介してデータを受信装置に送信する場合には、送信側装置がウィンドウサイズ分のデータを送信してから、受信側装置からＡＣＫパケットを受け取るまでの時間（Round Trip Time：以下ＲＴＴという）だけ、送信側装置による送信処理はブロックされる。【０００６】
ここで、送信側装置が転送遅延の大きなネットワークを介してデータを受信側装置に送信する場合には、ＲＴＴが長くなるために、効率的なデータ転送（高速なデータ転送）が行えないという問題がある。【０００７】
特に、家庭用電気製品（冷蔵庫、電子レンジ等）にネットワーク接続機能を備えた「ネット家電」と呼ばれる装置が受信側装置として用いられる場合には、この問題が顕著になる。つまり、ネット家電の通信用メモリ（受信用バッファメモリ）は一般的に小さく、その通信用メモリの空き容量がＲＷＩＮに設定されるため、上述のような問題が顕著になる。【０００８】
従来、この問題を解決するための送信側装置が提案されている（例えば、特許文献１参照）。この特許文献１の送信側装置は、ＴＣＰ／ＩＰ制御において、ネットワークの遅延時間を仮想ウィンドウサイズに変換し、上述のウィンドウサイズにその仮想ウィンドウサイズを加算する。そして、送信側装置は、その加算結果であるサイズを新たなウィンドウサイズとして設定し、その新たなウィンドウサイズに従ってデータの送信を行う。これにより、効率的なデータ転送が実現される。【０００９】
図１は、上記特許文献１の送信側装置の構成を示す構成図である。【００１０】
上記特許文献１の送信側装置９２０は、ネットワークを介して受信側装置９１０に接続されている。【００１１】
また、送信側装置９２０は、例えばアプリケーションプログラムなどを実行する中央制御部９２１と、そのプログラムの実行に必要なデータが格納されるメインメモリ９２２と、ＴＣＰ／ＩＰに従った通信を行う通信制御部９２３とを備えている。【００１２】
通信制御部９２３は、受信側装置９１０に送信するデータを格納するための送信用バッファメモリ９２５と、上述の仮想ウィンドウサイズの加算を行う仮想バッファ追加部９２６と、送信用バッファメモリ９２５に格納されているデータを受信側装置９１０に送信する通信プロトコル処理部９２４とを備えている。【００１３】
通信プロトコル処理部９２４は、受信側装置９１０からウィンドウサイズを通知されると、そのウィンドウサイズを仮想バッファ追加部９２６に知らせる。【００１４】
仮想バッファ追加部９２６は、その知らされたウィンドウサイズが小さければ、そのウィンドウサイズに仮想ウィンドウサイズを加算することにより、そのウィンドウサイズを更新する。【００１５】
通信プロトコル処理部９２４は、仮想バッファ追加部９２６で更新されたウィンドウサイズ分のデータを、送信用バッファメモリ９２５から取り出して受信側装置９１０に送信する。【００１６】
これにより、送信側装置９２０は、受信側装置９１０から通知されたウィンドウサイズが小さくても、そのウィンドウサイズを大きくして、ＲＴＴ内においてより多くのデータを受信側装置９１０に送信しようとする。【００１７】
一方、上記問題を解決するための受信側装置も提案されている（例えば、特許文献２参照）。この特許文献２の受信側装置は、ＴＣＰ／ＩＰの制御において、受信用バッファメモリの不足分をメインメモリから補い、その不足分が補われた受信用バッファメモリの容量をウィンドウサイズとして送信側装置に通知する。これにより、効率的なデータ転送が実現される。【００１８】
図２は、上記特許文献２の受信側装置の構成を示す構成図である。【００１９】
上記特許文献２の受信側装置９６０は、ネットワークを介して送信側装置９７０に接続されている。【００２０】
また、受信側装置９６０は、例えばアプリケーションプログラムなどを実行する中央制御部９６２と、そのプログラムの実行に必要なデータが格納されるメインメモリ９６３と、ＴＣＰ／ＩＰに従った通信を行う通信制御部９６５と、中央制御部９６２に対してモードの切り替えを指示するモード制御部９６１とを備えている。【００２１】
通信制御部９６５は、送信側装置９７０から送信されて受信したデータを格納するための第１受信用バッファメモリ９６７と、ＡＣＫパケットの送信などを行いながら送信側装置９７０からデータを受信して第１受信用バッファメモリ９６７に格納する通信プロトコル処理部９６６とを備えている。【００２２】
モード制御部９６１は、第１受信用バッファメモリ９６７の空き容量が小さい場合、メインメモリ９６３の一部の領域を第２受信用バッファメモリ９７４として確保するように中央制御部９６２に指示する。【００２３】
中央制御部９６２は、このような指示を受けると、第２受信用バッファメモリ９７４を確保し、通信プロトコル処理部９６６にその指示内容を通知する。その結果、通信プロトコル処理部９６６は、第１受信用バッファメモリ９６７の空き容量に第２受信用バッファメモリ９７４のサイズを加算し、その加算結果をウィンドウサイズとして送信側装置９７０に通知する。【００２４】
これにより、受信側装置９６０は、送信側装置９７０から送信されるデータを受信するための受信用バッファメモリのサイズを大きくすることができ、ＲＴＴ内においてより多くのデータを送信側装置９７０から送信させて受信することができる。
【特許文献１】特開平９−２４７２０９号公報
【特許文献２】特開２００５−１０９７６５号公報
【発明の開示】
【発明が解決しようとする課題】
【００２５】
しかしながら、上記特許文献１および特許文献２の受信側装置（通信装置）では、効率的なデータ転送を行うための環境的な制約があるという問題がある。【００２６】
つまり、上記特許文献１の受信側装置９１０では、効率的なデータ転送を行うために、送信側装置９２０がウィンドウサイズを大きくするような機能を有していなければならないという制約がある。【００２７】
また、上記特許文献２の受信側装置９６０では、効率的なデータ転送を行うために、受信用バッファメモリとして割り当て可能な領域がメインメモリ９６３になければならないという制約がある。つまり、受信側装置において受信用バッファメモリが十分確保されていない環境では効率的なデータ転送が行えないのである。【００２８】
そこで、本発明は、かかる問題に鑑みてなされたものであって、環境的な制約を受けることなく効率的なデータ転送を可能とする通信装置（受信側装置）を提供することを目的とする。
【課題を解決するための手段】
【００２９】
上記目的を達成するために、本発明に係る通信装置は、ネットワークを介して接続された通信相手装置に対して、データ量をウィンドウサイズとして通知することにより、前記通信相手装置から送信された前記ウィンドウサイズ分のデータを受信する通信装置であって、前記通信相手装置から送信されたデータを記憶するための記憶手段と、前記記憶手段の容量よりも大きい前記ウィンドウサイズを前記通信相手装置に通知するサイズ通知手段と、前記サイズ通知手段により通知された前記ウィンドウサイズに応じて前記通信相手装置から送信されたデータを受信して前記記憶手段に格納する受信手段と、前記記憶手段に格納されたデータを取り出して処理する処理手段とを備えることを特徴とする。【００３０】
これにより、記憶手段の容量よりも大きなウィンドウサイズが例えばＡＣＫパケットにより通信相手装置（送信側装置）に通知されるため、記憶手段（受信用バッファメモリ）の容量が少なくても、ＲＴＴ内において通信相手装置から多くのデータを送信させることができ、その結果、記憶容量という環境的な制約を受けることなく効率的なデータ転送を行うことができる。つまり、上記特許文献２の受信側装置９６０では、メインメモリ９６３の一部を受信用バッファメモリの一部に割り当てることにより、その受信用バッファメモリの容量を増やし、その容量をウィンドウサイズとして通知したが、本発明では、このような割り当てができなくても、効率的なデータ転送を行うことができる。【００３１】
言い換えれば、本発明に係る通信装置では、ＴＣＰコネクション毎の専用の記憶手段の容量以上のメモリを確保できないために、ＲＴＴに見合うＲＷＩＮと同等のメモリ領域を確保することができない環境であっても、大きなウィンドウサイズを通知する。その結果、本発明に係る通信装置では、ＲＴＴに見合うメモリ領域が確保できない環境にあっても、処理手段による処理が滞らない限り効率的なデータ転送を行うことができる。【００３２】
また、前記通信相手装置は、前記サイズ通知手段により通知されたウィンドウサイズ分のデータを複数のデータパケットとして順次送信し、前記受信手段は、前記複数のデータパケットを順次受信して前記記憶手段に格納し、前記通信装置は、さらに、前記記憶手段に格納されたデータパケットを廃棄することにより、前記記憶手段の空き容量を確保する廃棄手段と、前記廃棄手段により廃棄されたデータパケットの再送を前記通信相手装置に対して要求する再送要求手段とを備えることを特徴としてもよい。ここで、前記処理手段は、前記記録手段に格納されているデータパケットを予め定められた順序で取り出し、前記廃棄手段は、前記処理手段による前記順序に従った、前記記憶手段からのデータパケットの取り出しが滞り、前記記憶手段に新たなデータパケットを格納する容量がないときに、前記記憶手段に記憶されているデータパケットを廃棄する。【００３３】
例えば、通信相手装置に通知されるウィンドウサイズが大きければ大きいほど、パケットロスが発生する確率が増す。パケットロスが発生すると、消失したデータパケット（ロスパケット）が送信された後に送信されて記憶手段に順次格納されたデータパケットを処理手段によって取り出すことができず、記憶手段の空き容量がなくなってしまうことがある。つまり、受信処理が滞ってしまうことがある。このような場合が生じると、ロスパケットが通信相手装置から再送されても、記憶手段に空き容量がないため、その再送されたロスパケットは記憶手段に格納されず、受信処理の滞った状態が継続し、通信相手装置からデータを受信するデータ転送処理が停止してしまう可能性がある。【００３４】
そこで本発明では、記憶手段に格納されているデータパケットが廃棄されて空き容量が確保されるため、上述のように再送されたロスパケットを記憶手段に格納して、その記憶手段に格納されている多くのデータパケットを処理手段に受け渡すことができ、データ転送処理の停止を避けることができる。さらに、廃棄されたデータパケットの再送が要求されるため、その廃棄されたデータパケットを再び受信して記憶手段に格納することができる。【００３５】
その結果、受信処理が滞ったとしても、データ転送効率を著しく劣化させることを避けることができる。【００３６】
また、前記再送要求手段は、前記廃棄手段により廃棄されたデータパケットを示す否定応答パケットを、前記データパケットを前記通信相手装置から再送させるのに必要な数だけ、前記通信相手装置に送信することにより、前記データパケットの再送を前記通信相手装置に要求することを特徴としてもよい。【００３７】
例えば、通信相手装置がTriple Duplicate ＡＣＫ対応の通信機能を有している場合には、Triple Duplicate ＡＣＫパケットが否定応答パケットとして通信相手装置に送信されるため、その通信相手装置に対して、廃棄されたデータパケットを迅速に再送させることができる。その結果、パケットロスが発生して受信処理が滞っても、通知したウィンドウサイズ分のデータパケットを迅速に受信することができる。【００３８】
また、前記廃棄手段は、前記サイズ通知手段により通知されたウィンドウサイズに応じて前記通信相手装置から順次送信されるデータパケットのうち、最後に送信されるデータパケットが最終パケットとして前記記憶手段に格納されるように、前記最終パケットを除く他のデータパケットを前記記憶手段から廃棄することを特徴としてもよい。ここで、前記再送要求手段は、前記記憶手段に格納されている前記最終パケットと他のデータパケットとを示す肯定応答パケットを前記通信相手装置に送信することにより、前記最終パケットと他のデータパケットの間に送信された複数のデータパケットの一括した再送を前記通信相手装置に要求する。【００３９】
例えば、通信相手装置がSelective ＡＣＫ対応の通信機能を有している場合には、Selective ＡＣＫパケットが肯定応答パケットとして通信相手装置に送信されるため、その通信相手装置に対して、廃棄された複数のデータパケットを迅速に一括して再送させることができる。その結果、パケットロスが発生して受信処理が滞っても、通知したウィンドウサイズ分のデータパケットをより迅速に受信することができる。さらに、最終パケットが残るように他のデータパケットが廃棄されることによって、Selective ＡＣＫパケットにより再送要求されるべきデータパケットを容易に特定することができる。【００４０】
なお、本発明は、このような通信装置として実現することができるだけでなく、その通信装置が通信する方法や、その通信装置が通信するためのプログラム、そのプログラムを格納する記憶媒体、集積回路としても実現することができる。
【発明の効果】
【００４１】
本発明の通信装置は、環境的な制約を受けることなく効率的にデータを転送することができるという作用効果を奏する。つまり、本発明の通信装置では、ＴＣＰコネクション毎の専用の受信用バッファメモリの容量以上のメモリを確保できないために、ＲＴＴに見合うＲＷＩＮと同等のメモリ領域が確保できない環境であっても、大きなウィンドウサイズを用いて通信を行うことができ、効率的なデータ転送が可能となる。また、パケット廃棄と再送要求を繰り返すことにより、通信装置（受信側装置）において受信用バッファメモリ内のパケットの処理が一時的に滞った場合でも、効率を大きく落とすことなくデータ転送を続けることができる。
【図面の簡単な説明】
【００４２】
【図１】図１は、特許文献１の送信側装置の構成を示す構成図である。
【図２】図２は、特許文献２の受信側装置の構成を示す構成図である。
【図３】図３は、本発明の実施の形態における受信側装置の構成の一例を示す構成図である。
【図４】図４は、同上の受信側装置と送信側装置との通信を示すシーケンス図である。
【図５】図５は、パケットロスによりデータ転送が停止してしまう様子を示すシーケンス図である。
【図６】図６は、本発明の実施の形態における、パケットロスが発生したときの受信側装置とＴＤＡＣＫ対応の送信側装置との間で行われる通信の一例を示すシーケンス図である。
【図７】図７は、同上の、パケットロスが発生したときの受信側装置とＳＡＣＫ対応の送信側装置と間で行われる通信の一例を示すシーケンス図である。
【図８】図８は、同上の受信側装置の全体的な動作を示すフローチャートである。
【図９】図９は、同上の受信側装置の復帰処理（図８のステップＳ１０４）における動作を示すフローチャートである。
【図１０】図１０は、同上の変形例１に係る受信側装置と送信側装置との間で行われる通信の一例を示すシーケンス図である。
【図１１】図１１は、同上の変形例２に係る受信中継装置の構成を示す構成図である。
【図１２】図１２は、同上の変形例３に係る受信側装置の動作を説明するための説明図である。
【図１３】図１３は、同上の変形例４に係る受信側装置の動作を説明するための説明図である。
【図１４】図１４は、同上の変形例５に係る受信側装置の動作を説明するための説明図である。
【図１５】図１５は、同上の変形例６に係る受信側装置の動作を説明するための説明図である。
【図１６】図１６は、同上の変形例７に係る受信側装置の動作を説明するための説明図である。
【図１７】図１７は、同上の変形例８に係る受信側装置の動作を説明するための説明図である。
【図１８】図１８は、同上の受信側装置および送信側装置の外観構成を示す図である。
【符号の説明】
【００４３】
１００    受信側装置（通信装置）
１１０    通信制御部
１２０    受信用バッファメモリ
１３０    通信プロトコル処理部
１３１    送受信制御部
１３２    ＡＣＫ生成部
１３３    ウィンドウサイズ設定部
１３４    パケット廃棄部
１３５    再送要求部
１４０    中央制御部
１５０    メインメモリ
２００    送信側装置
３００    ネットワーク
【発明を実施するための最良の形態】
【００４４】
以下、本発明の実施の形態における受信側装置（通信装置）について、図面を参照しながら説明する。【００４５】
ここで、説明を簡略化するために、本実施の形態では、１パケット内に格納されるデータ長（ＬＥＮ）を１ＫＢｙｔｅとする。さらに、１つのシーケンス番号（ＳＥＱ）が割り当てられたデータのサイズも１ＫＢｙｔｅ（１パケット）とし、ウィンドウサイズ（ＲＷＩＮ）の単位も１ＫＢｙｔｅとする。【００４６】
図３は、本発明の実施の形態における受信側装置の構成の一例を示す図である。【００４７】
本実施の形態における受信側装置（通信装置）１００は、ネットワーク３００を介して送信側装置２００に接続され、その送信側装置２００とＴＣＰ／ＩＰに従った通信を行う。【００４８】
ここで、受信側装置１００および送信側装置２００は、ネットワーク３００と有線または無線で接続する通信装置であって、例えばＥｔｈｅｒｎｅｔ（登録商標）インタフェースを備えたパーソナルコンピュータや、ネットワーク通信が可能な家電装置などである。ネットワーク３００は、有線または無線を含む通信ネットワークであり、インターネットなどの公衆の通信ネットワークなどが例として挙げられる。なお、受信側装置１００および送信側装置２００は、電力線を通信回線として使用して通信してもよい。【００４９】
この受信側装置１００は、通信制御部１１０と、メインメモリ１５０と、中央制御部１４０とを備え、送信側装置２００から送信されるデータを受信する。【００５０】
中央制御部１４０は、通信制御部１１０およびメインメモリ１５０を制御し、例えば、送信側装置２００から送信されたデータを用いてアプリケーションプログラムなどを実行する。なお、本実施の形態では、この中央制御部１４０は、後述する通信制御部１１０の受信用バッファメモリ１２０に格納されたデータを取り出して処理する処理手段として構成されている。【００５１】
メインメモリ１５０は、中央制御部１４０における処理において必要なデータを記録するための領域を有する。【００５２】
通信制御部１１０は、送信側装置２００からデータを送信させてそのデータを受信する通信プロトコル処理部１３０と、通信プロトコル処理部１３０によって受信されたデータを格納するための受信用バッファメモリ１２０とを備えている。【００５３】
通信プロトコル処理部１３０は、送受信制御部１３１と、ＡＣＫ生成部１３２と、ウィンドウサイズ設定部１３３と、パケット廃棄部１３４と、再送要求部１３５とを備えている。【００５４】
送受信制御部１３１は、送信側装置２００から送信されたパケット単位のデータ（以下、データパケットという）を受信して受信用バッファメモリ１２０に格納する。また、送受信制御部１３１は、例えば、送信側装置２００からデータパケットを受信して受信用バッファメモリ１２０に格納したときには、ＡＣＫ生成部１３２にＡＣＫパケットの生成を促し、生成されたＡＣＫパケットを送信側装置２００に送信する。【００５５】
また、送受信制御部１３１は、ＡＣＫパケットに応じて送信側装置２００から送信されて受信したデータパケットのシーケンス番号を監視することにより、パケットロスの発生を検知する。例えば、送受信制御部１３１は、ＡＣＫパケットを送信し、そのＡＣＫパケットに応じて送信側装置２００から順次送信されて受信したデータパケットのシーケンス番号に欠番があるか否かを判別する。そして、欠番があるときには、送受信制御部１３１は、その欠番に対応するデータパケットがネットワーク３００で消失して受信されなかったと判断し、パケットロスの発生を検知する。なお、上述のように消失したデータパケットを、以下、ロスパケットという。【００５６】
また、送受信制御部１３１は、パケットロスの発生を検知したときには、その発生をウィンドウサイズ設定部１３３に通知する。さらに、送受信制御部１３１は、パケットロス発生後に上述のＡＣＫパケットに対応する全てのデータパケットが受信されたときには、そのパケットロスに対する復帰処理が完了したと判断して、その復帰処理完了をウィンドウサイズ設定部１３３に通知する。【００５７】
ＡＣＫ生成部１３２は、ＡＣＫ番号と、ウィンドウサイズ設定部１３３によって設定されたウィンドウサイズ（ＲＷＩＮ）とを示すＡＣＫパケットを生成して送受信制御部１３１に出力する。【００５８】
ここで、ＡＣＫ生成部１３２は、再送要求部１３５によって再送が要求されたとき（再送要求時）に、ＡＣＫパケットを生成して送受信制御部１３１から送信側装置２００に送信させる。さらに、ＡＣＫ生成部１３２は、再送要求時以外にも、送受信制御部１３１でデータパケットが受信されて受信用バッファメモリ１２０に格納されたときには（受信応答時）、ＡＣＫパケットを生成して送受信制御部１３１から送信側装置２００に送信させる。【００５９】
ＡＣＫ生成部１３２は、受信応答時には、通常、そのデータパケットのシーケンス番号の次のシーケンス番号と同一のＡＣＫ番号を示すＡＣＫパケットを肯定応答パケットとして生成する。しかし、ＡＣＫ生成部１３２は、送受信制御部１３１によってパケットロスの発生が検知されているときには、その消失したデータパケット（ロスパケット）のシーケンス番号と同一のＡＣＫ番号を示すＡＣＫパケットを否定応答パケットとして生成する。【００６０】
また、ＡＣＫ生成部１３２は、再送要求時には、再送要求部１３５によって指示されたＡＣＫ番号のＡＣＫパケットを生成する。【００６１】
つまり、ＡＣＫ生成部１３２は、送信側装置２００がTriple Duplicate ＡＣＫ（以下、ＴＤＡＣＫという）対応の通信機能を有している場合には、同一のＡＣＫ番号を示す３つのＡＣＫパケット（否定応答パケット）を生成する。なお、上記３つのＡＣＫパケットを、以下、Triple Duplicate ＡＣＫパケットまたはＴＤＡＣＫパケットという。また、ＡＣＫ生成部１３２は、送信側装置２００がSelective ＡＣＫ（以下：ＳＡＣＫという）対応の通信機能を有している場合には、受信用バッファメモリ１２０に格納されている複数のデータパケットのシーケンス番号と同一の複数のＡＣＫ番号を含むＡＣＫパケット（以下、Selective ＡＣＫパケットまたはＳＡＣＫパケットという）を肯定応答パケットとして生成する。【００６２】
なお、送信側装置２００は、受信応答時のＡＣＫパケットを受信すると、ＴＣＰ／ＩＰに従って、そのＡＣＫパケットの示すウィンドウサイズ分のデータパケットを、そのＡＣＫパケットの受信以後さらにＡＣＫパケットを受信することなく送信する。また、このとき、送信側装置２００は、受信したＡＣＫパケットの示すＡＣＫ番号と同一のシーケンス番号が割り当てられたデータパケットと、そのシーケンス番号以降の連続するシーケンス番号が割り当てられたデータパケットとを送信する。【００６３】
また、送信側装置２００は、ＴＤＡＣＫ対応の通信機能を有している場合には、ＴＤＡＣＫパケット（否定応答パケット）を受信すると、そのＴＤＡＣＫパケットの示すＡＣＫ番号と同一のシーケンス番号が割り当てられたデータパケットを既に送信していても、そのデータパケットを再送（高速再送）する。【００６４】
また、送信側装置２００は、ＳＡＣＫ対応の通信機能を有している場合には、ＳＡＣＫパケットを受信すると、そのＳＡＣＫパケットにより示される複数のＡＣＫ番号により、受信用バッファメモリ１２０に格納されている複数のデータパケットのシーケンス番号を特定する。つまり、送信側装置２００は、受信側装置１００に送信したにも関わらず、受信用バッファメモリ１２０に格納されていない１つまたは複数のデータパケットのシーケンス番号を特定する。そして、送信側装置２００は、受信用バッファメモリ１２０に格納されていないそれらのデータパケットを一括して再送（高速再送）する。【００６５】
ウィンドウサイズ設定部１３３は、通常、受信用バッファメモリ１２０の容量に依存せず、パケット処理に一時的な滞りが発生した場合に受信しきれないデータ量をウィンドウサイズとして設定する。【００６６】
つまり、本実施の形態におけるウィンドウサイズ設定部１３３は、受信用バッファメモリ１２０の記憶容量（空き容量）よりも大きいサイズをウィンドウサイズとして設定する。以下、このような設定を高速転送設定という。なお、このウィンドウサイズは、受信側装置１００が受信したいデータの転送レートにあわせて設定される。例えば、ウィンドウサイズ設定部１３３は、ＲＴＴの間に、受信用バッファメモリ１２０から中央制御部１４０に移動させることが可能なデータのサイズをウィンドウサイズとして設定する。【００６７】
一方、ウィンドウサイズ設定部１３３は、送受信制御部１３１からパケットロスの発生の通知を受けたときには、そのときから復帰処理の完了の通知を受け取るまで、受信用バッファメモリ１２０の空き容量をウィンドウサイズとして設定する。つまり、ウィンドウサイズ設定部１３３は、パケット廃棄部１３４を介して受信用バッファメモリ１２０の空き容量を監視して、その空き容量をウィンドウサイズとして設定する。以下、このような設定を通常転送設定という。【００６８】
ここで、パケットロスに起因して、受信用バッファメモリ１２０に空き容量がなくなることがある。この場合には、送受信制御部１３１は、送信側装置２００から送信されたデータパケットを受信しても、既に格納されているデータパケットが廃棄されない限り、その受信したデータパケットを受信用バッファメモリ１２０に格納することができない。【００６９】
このように、既に格納されているデータパケットが廃棄されない限り、新たなデータパケットを格納することができない受信用バッファメモリ１２０の状態を、以下、停滞状態という。【００７０】
パケット廃棄部１３４は、受信用バッファメモリ１２０が上述のような停滞状態になると、その状態を解消するため、受信用バッファメモリ１２０に既に格納されているデータパケットを廃棄する。つまり、パケット廃棄部１３４は、送受信制御部１３１によって受信された最新のデータパケットが受信用バッファメモリ１２０に格納されるように、例えば、受信用バッファメモリ１２０に既に格納されているシーケンス番号の最も大きいデータパケットを廃棄する。その結果、ロスパケットが再送されたときには、そのパケットが受信用バッファメモリ１２０に格納される。以下、このように廃棄されたデータパケットを廃棄パケットという。【００７１】
再送要求部１３５は、廃棄パケットの再送を送信側装置２００に対して要求する。すなわち、再送要求部１３５は、廃棄パケットを送信側装置２００から送信させるために必要なＡＣＫパケットの生成をＡＣＫ生成部１３２に促す。【００７２】
例えば、再送要求部１３５は、送信側装置２００がＴＤＡＣＫ対応の通信機能を有している場合には、廃棄パケットのシーケンス番号をＡＣＫ番号として示すＴＤＡＣＫパケットを生成するようにＡＣＫ生成部１３２に指示する。【００７３】
また、再送要求部１３５は、送信側装置２００がＳＡＣＫ対応の通信機能を有している場合には、受信用バッファメモリ１２０に格納されている複数のデータパケットのシーケンス番号をＡＣＫ生成部１３２に通知し、それらのシーケンス番号をそれぞれＡＣＫ番号として示すＳＡＣＫパケットを生成するようにＡＣＫ生成部１３２に指示する。なお、シーケンス番号の連続する複数のデータパケットが受信用バッファメモリ１２０に格納されていれば、再送要求部１３５は、その連続するシーケンス番号のうち先頭と最後のシーケンス番号のみをＡＣＫ生成部１３２に通知する。【００７４】
また、再送要求部１３５は、ＡＣＫ生成部１３２にＡＣＫパケットの生成を指示するときには、ウィンドウサイズ設定部１３３にウィンドウサイズの設定を促す。【００７５】
なお、本実施の形態では、受信用バッファメモリ１２０が、送信側装置２００（通信相手装置）から送信されたデータを記憶するための記憶手段として構成されている。また、ウィンドウサイズ設定部１３３、ＡＣＫ生成部１３２および送受信制御部１３１がサイズ通知手段として構成され、送受信制御部１３１が受信手段として構成されている。さらに、パケット廃棄部１３４が廃棄手段として構成され、再送要求部１３５が再送要求手段として構成されている。【００７６】
図４は、受信側装置１００と送信側装置２００との通信を示すシーケンス図である。【００７７】
まず、受信側装置１００と送信側装置２００とは、例えば、Three Way Handshakeなどにより、ＴＣＰ接続時のコネクションを設立する。【００７８】
そして、受信側装置１００のウィンドウサイズ設定部１３３は、上述の高速転送設定を行う。すなわち、ウィンドウサイズ設定部１３３は、受信用バッファメモリ１２０の容量が４ＫＢしかないにもかかわらず、例えば８ＫＢのウィンドウサイズ（ＲＷＩＮ＝８）を設定する。その結果、ＡＣＫ生成部１３２は、ＲＷＩＮ＝８を示すＡＣＫパケットＰ１２を生成する。なお、ここでは、ＡＣＫ生成部１３２は、ＡＣＫ番号が０（ＡＣＫ＝０）を示すＡＣＫパケットＰ１２を生成する。【００７９】
このようにＡＣＫパケットＰ１２が生成されると、受信側装置１００の送受信制御部１３１は、そのＡＣＫパケットＰ１２を肯定応答パケットして送信側装置２００に送信する。つまり、ＡＣＫパケットＰ１２によって、８ＫＢのウィンドウサイズが送信側装置２００に通知される。【００８０】
送信側装置２００は、ＡＣＫパケットＰ１２を受信すると、そのＡＣＫパケットＰ１２の示すウィンドウサイズ（ＲＷＩＮ＝８）分のデータパケットＰ１３，Ｐ１４，…，Ｐ２０を送信する。ここで、送信側装置２００は、そのＡＣＫパケットＰ１２の示すＡＣＫ番号（ＡＣＫ＝０）と同一のシーケンス番号（ＳＥＱ＝０）が割り当てられたデータパケットＰ１３から順に、各データパケットＰ１３，Ｐ１４，…，Ｐ２０を送信する。【００８１】
受信側装置１００の送受信制御部１３１は、送信側装置２００からデータパケットＰ１３，Ｐ１４，…，Ｐ２０を順次受信すると、それらのデータパケットを順に受信用バッファメモリ１２０に格納する。【００８２】
受信側装置１００の中央制御部１４０は、受信用バッファメモリ１２０に格納されているデータパケットを順次取り出し、そのデータパケットを用いた処理を実行する。【００８３】
ここで、送信側装置２００から送信されるデータパケットＰ１３，Ｐ１４，…，Ｐ２０の合計サイズはＡＣＫパケットＰ１２の示すウィンドウサイズ（８ＫＢ）であるのに対して、受信用バッファメモリ１２０の容量は４ＫＢしかない。しかし、上述のように、中央制御部１４０が、受信用バッファメモリ１２０に格納されたデータパケットを順次取り出してアプリケーションプログラムに渡していくため、送信された全てのデータパケットＰ１３，Ｐ１４，…，Ｐ２０が正常に受信される。【００８４】
さらに、受信側装置１００の送受信制御部１３１は、ＡＣＫパケットＰ１２のようなＲＷＩＮ＝８を示すＡＣＫパケットの送信を繰り返し行い、ＲＴＴごとに、８ＫＢ分のデータパケットを送信側装置２００から受信する。【００８５】
このように、本実施の形態では、受信用バッファメモリ１２０の容量ではなく、その容量よりも大きな仮想的なウィンドウサイズに応じた速度でデータ転送を行うことができ、通信速度の向上が期待できる。例えば、上記のように、実際の受信用バッファメモリ１２０の容量（４ＫＢ）の２倍（８ＫＢ）のウィンドウサイズが送信側装置２００に通知された場合には、パケットロスが発生しない環境下では２倍の通信速度によるデータ転送が実現される。【００８６】
なお、本実施の形態における高速転送設定では、ウィンドウサイズを受信用バッファメモリ１２０の容量の２倍に設定したが、任意のサイズに設定してもよく、好ましくは、パケットロスが発生しない限りの最大サイズに設定する。【００８７】
ここで、ウィンドウサイズ設定部１３３が受信用バッファメモリ１２０の容量よりも大きいウィンドウサイズを設定しただけでは、パケットロスが発生したときに、受信側装置１００と送信側装置２００との間のデータ転送が停止してしまうことがある。【００８８】
図５は、パケットロスによりデータ転送が停止してしまう様子を示すシーケンス図である。【００８９】
例えば、ＡＣＫパケットＰ１２に応じて送信側装置２００から送信されたデータパケットＰ１３，Ｐ１４，…，Ｐ２０のうち、データパケットＰ１３がネットワーク３００において消失する。つまり、パケットロスが発生する。【００９０】
このとき、データパケットＰ１４，Ｐ１５，Ｐ１６，Ｐ１７が順に受信側装置に受信されると、受信側装置の受信用バッファメモリには、それらのデータパケットが順に格納され、受信用バッファメモリの空き容量がなくなる。つまり、受信側装置の受信用バッファメモリは上述の停滞状態となる。【００９１】
なお、図５では、受信用バッファメモリに格納されるデータパケットを、そのデータパケットに割り当てられたシーケンス番号を用いて示している。【００９２】
ここで、ＴＣＰでは順序制御が行われているため、受信用バッファメモリから中央制御部（アプリケーションプログラム）への各データパケットの受け渡しは、シーケンス番号の昇順に従って行われる。したがって、上述のようにパケットロスが発生したときには、データパケットＰ１３（ＳＥＱ＝０）が受信用バッファメモリに格納されていないため、データパケットＰ１４，Ｐ１５，Ｐ１６、Ｐ１７（ＳＥＱ＝１，２，３，４）が受信用バッファメモリに格納されても、これらのデータパケットを中央制御部に受け渡すことができない。【００９３】
その結果、受信用バッファメモリに空き容量がないため、データパケットＰ１８、Ｐ１９，Ｐ２０が受信側装置に順に受信されても、それらのデータパケットは受信用バッファメモリに格納されず破棄されてしまう。【００９４】
また、上述のように、データパケットＰ１４，Ｐ１５，Ｐ１６，Ｐ１７が順に受信側装置に受信されると、受信側装置からは、その受信ごとに、ＡＣＫ番号が０であること（ＡＣＫ＝０）を示すＡＣＫパケット（否定応答パケット）Ｐ２１，Ｐ２２，Ｐ２３，Ｐ２５が送信側装置２００に送信される。【００９５】
ここで、送信側装置２００がＴＤＡＣＫ対応の通信機能を有していれば、送信側装置２００は、ＡＣＫ＝０を示す３つのＡＣＫパケットＰ２１，Ｐ２２，Ｐ２３をＴＤＡＣＫパケットとして受け取ると、シーケンス番号０のデータパケットＰ２４をロスパケットとして再送する。【００９６】
しかし、データパケットＰ２４が再送されたときにも、上述と同様に、受信用バッファメモリに空き容量がないため、そのデータパケットＰ２４は受信用バッファメモリに格納されず破棄される。【００９７】
さらに、シーケンス番号０のデータパケットＰ２６が再送されても、上述と同様、そのデータパケットＰ２６は受信用バッファメモリに格納されず破棄される。【００９８】
その結果、送信側装置２００から受信側装置へのデータ転送が停止されてしまう。【００９９】
そこで、本実施の形態における受信側装置１００は、上述のようなデータ転送の停止を避けるために、停滞状態にある受信用バッファメモリ１２０に格納されているデータパケットを廃棄して、廃棄されたデータパケットの再送を送信側装置２００に要求する。【０１００】
図６は、パケットロスが発生したときの受信側装置１００とＴＤＡＣＫ対応の送信側装置２００との間で行われる通信の一例を示すシーケンス図である。【０１０１】
まず、受信側装置１００と送信側装置２００とは、例えば、Three Way Handshakeなどにより、ＴＣＰ接続時のコネクションを設立する。このとき、受信側装置１００の送受信制御部１３１は、送信側装置２００の通信機能を特定する。例えば、送受信制御部１３１は、送信側装置２００の通信機能がＴＤＡＣＫに対応していると判断する。その結果、受信側装置１００は、パケットロスが発生したときには送信側装置２００に対してＴＤＡＣＫ対応の再送要求を行う。【０１０２】
具体的には、まず、受信側装置１００のウィンドウサイズ設定部１３３は、上述と同様、高速転送設定を行う。すなわち、ウィンドウサイズ設定部１３３は、受信用バッファメモリ１２０の容量が４ＫＢしかないにもかかわらず、８ＫＢのウィンドウサイズ（ＲＷＩＮ＝８）を設定する。その結果、ＡＣＫ生成部１３２は、ＡＣＫ＝０およびＲＷＩＮ＝８を示すＡＣＫパケットＰ１２を生成する。【０１０３】
このようにＡＣＫパケットＰ１２が生成されると、受信側装置１００の送受信制御部１３１は、そのＡＣＫパケットＰ１２を肯定応答パケットとして送信側装置２００に送信する。【０１０４】
送信側装置２００は、ＡＣＫパケットＰ１２を受信すると、上述と同様、そのＡＣＫパケットＰ１２の示すウィンドウサイズ（ＲＷＩＮ＝８）分のデータパケットＰ１３，Ｐ１４，…，Ｐ２０を送信する。【０１０５】
ここで、ＡＣＫパケットＰ１２に応じて送信側装置２００から送信されたデータパケットＰ１３，Ｐ１４，…，Ｐ２０のうち、データパケットＰ１３がネットワーク３００において消失する。つまり、パケットロスが発生する。【０１０６】
受信側装置１００の送受信制御部１３１は、データパケットＰ１４（ＳＥＱ＝１）を受信すると、シーケンス番号０のデータパケットを受信していないため、シーケンス番号０のデータパケット（ロスパケット）が消失したこと、すなわちパケットロスが発生したことを検知する。さらに、送受信制御部１３１は、ロスパケットのシーケンス番号０をＡＣＫ生成部１３２に通知する。【０１０７】
また、送受信制御部１３１は、データパケットＰ１４，Ｐ１５，Ｐ１６，Ｐ１７を順に受信して、受信用バッファメモリ１２０にそれらのデータパケット（ＳＥＱ＝１，２，３，４）を順に格納する。しかし、上述のように、シーケンス番号０のデータパケットＰ１３が受信用バッファメモリ１２０に格納されていないため、データパケットＰ１４，Ｐ１５，Ｐ１６，Ｐ１７を中央制御部１４０に受け渡すことができず、受信用バッファメモリ１２０の空き容量がなくなる。つまり、このとき、受信用バッファメモリ１２０は停滞状態となる。【０１０８】
そこで、パケット廃棄部１３４は、シーケンス番号４のデータパケットＰ１７を廃棄し、その廃棄パケットのシーケンス番号４を再送要求部１３５に通知する。その結果、停滞状態は一時的に解かれ、受信用バッファメモリ１２０に空き容量ができ、受信用バッファメモリ１２０は、新たなデータパケットを格納し得る状態となる。【０１０９】
これにより、送受信制御部１３１は、送信側装置２００から送信されて受信したデータパケットＰ１８（ＳＥＱ＝５）を受信用バッファメモリ１２０に格納する。【０１１０】
データパケットＰ１８（ＳＥＱ＝５）が受信用バッファメモリ１２０に格納されると、受信用バッファメモリ１２０は、データパケットＰ１４，Ｐ１５，Ｐ１６，Ｐ１８（ＳＥＱ＝１，２，３，５）を格納することとなり、再び停滞状態となる。【０１１１】
そこで、パケット廃棄部１３４は、シーケンス番号５のデータパケットＰ１８を廃棄し、その廃棄パケットのシーケンス番号５を再送要求部１３５に通知する。その結果、停滞状態は一時的に解かれ、受信用バッファメモリ１２０に空き容量ができ、受信用バッファメモリ１２０は、新たなデータパケットを格納し得る状態となる。【０１１２】
これにより、送受信制御部１３１は、送信側装置２００から送信されて受信したデータパケットＰ１９（ＳＥＱ＝６）を受信用バッファメモリ１２０に格納する。【０１１３】
このようなデータパケットの格納と廃棄とは、シーケンス番号７のデータパケット（最終パケット）Ｐ２０が受信側装置１００に受信されるまで繰り返される。その結果、受信用バッファメモリ１２０に格納されたデータパケットＰ２０（ＳＥＱ＝７）は削除され、受信用バッファメモリ１２０に空き容量ができ、受信用バッファメモリ１２０は、新たなデータパケットを格納し得る状態となる。【０１１４】
なお、本実施の形態では、受信用バッファメモリ１２０が停滞状態になる度に、その受信用バッファメモリ１２０に格納されているデータパケットを廃棄したが、最終パケットであるデータパケットＰ２０が受信側装置１００に到達した後にのみデータパケットを廃棄してもよい。【０１１５】
この場合には、ＳＥＱ＝４を示すデータパケットＰ１７が受信用バッファメモリ１２０に格納されると、その受信用バッファメモリ１２０は停滞状態になるが、上述のようにそのデータパケットＰ１７が廃棄されず、停滞状態が継続する。その結果、ＳＥＱ＝５を示すデータパケットＰ１８が送受信制御部１３１に受信されても、送受信制御部１３１はそのデータパケットＰ１８を受信用バッファメモリ１２０に格納することができずに消失させてしまう。その後も停滞状態が継続しているため、送受信制御部１３１は、ＳＥＱ＝６，７を示すデータパケットＰ１９，２０を順次受信しても、上述と同様、それらを順次消失させてしまう。【０１１６】
パケット廃棄部１３４は、最終パケットであるデータパケットＰ２０が消失した後に、停滞状態にある受信用バッファメモリ１２０に格納されている、例えばシーケンス番号が最も大きいデータパケットＰ１７（ＳＥＱ＝４）を廃棄する。その結果、受信用バッファメモリ１２０に空き容量ができ、受信用バッファメモリ１２０は、新たなデータパケットを格納し得る状態となる。【０１１７】
このような場合、再送要求部１３５は、パケット廃棄部１３４によって廃棄されたデータパケットの再送だけでなく、送受信制御部１３１によって受信されたが受信用バッファメモリ１２０に格納されなかったデータパケットの再送も送信側装置２００に要求する。【０１１８】
また、送受信制御部１３１が上書によりその受信用バッファメモリ１２０に格納されているデータパケットを廃棄してもよい。【０１１９】
この場合には、ＳＥＱ＝４を示すデータパケットＰ１７が受信用バッファメモリ１２０に格納されると、その受信用バッファメモリ１２０は停滞状態になる。ここで、ＳＥＱ＝５を示すデータパケットＰ１８が送受信制御部１３１に受信されると、送受信制御部１３１は、そのデータパケットＰ１８を受信用バッファメモリ１２０に上書することにより、そのデータパケットＰ１８を受信用バッファメモリ１２０に格納すると同時に、ＳＥＱ＝４を示すデータパケットＰ１７を廃棄する。その後も、送受信制御部１３１は、ＳＥＱ＝６，７を示すデータパケットＰ１９，２０を順次受信すると、上述と同様、それらを受信用バッファメモリ１２０に順次上書し、ＳＥＱ＝５，６を示すデータパケットＰ１８，Ｐ１９を順次廃棄する。【０１２０】
パケット廃棄部１３４は、停滞状態にある受信用バッファメモリ１２０に格納されている最終パケットのデータパケットＰ２０（ＳＥＱ＝７）だけを廃棄する。その結果、受信用バッファメモリ１２０に空き容量ができ、受信用バッファメモリ１２０は、新たなデータパケットを格納し得る状態となる。【０１２１】
このような場合、再送要求部１３５は、パケット廃棄部１３４によって廃棄されたデータパケットの再送だけでなく、送受信制御部１３１による上書によって廃棄されたデータパケットの再送も送受信側装置２００に要求する。【０１２２】
ところで、受信側装置１００は、上述のデータパケットＰ１４，Ｐ１５，Ｐ１６，Ｐ１７を受信すると、それらがシーケンス番号０のデータパケットでないため、その受信ごとに、ＡＣＫ＝０を示す否定応答パケットであるＡＣＫパケットＰ２１，Ｐ２２，Ｐ２３，Ｐ２５を送信側装置２００に送信する。【０１２３】
すなわち、送受信制御部１３１がデータパケットＰ１４（ＳＥＱ＝１）を受信したときにパケットロスの発生を検知すると、ウィンドウサイズ設定部１３３は、高速転送設定を停止して、通常転送設定を行う。その結果、ウィンドウサイズ設定部１３３は、受信用バッファメモリ１２０の空き容量をウィンドウサイズ（ＲＷＩＮ＝３）として設定する。【０１２４】
これにより、ＡＣＫ生成部１３２は、送受信制御部１３１でデータパケットＰ１４（ＳＥＱ＝１）が受信されると、ＡＣＫ＝０およびＲＷＩＮ＝３を示すＡＣＫパケット（否定応答パケット）Ｐ２１を生成してそのＡＣＫパケットＰ２１を送受信制御部１３１から送信側装置２００に送信させる。【０１２５】
さらに、送受信制御部１３１がデータパケットＰ１５（ＳＥＱ＝２）を受信したときにも、ウィンドウサイズ設定部１３３は通常転送設定を行う。すなわち、ウィンドウサイズ設定部１３３は、受信用バッファメモリ１２０の空き容量をウィンドウサイズ（ＲＷＩＮ＝２）として設定する。【０１２６】
これにより、ＡＣＫ生成部１３２は、送受信制御部１３１でデータパケットＰ１５（ＳＥＱ＝２）が受信されると、ＡＣＫ＝０およびＲＷＩＮ＝２を示すＡＣＫパケット（否定応答パケット）Ｐ２２を生成してそのＡＣＫパケットＰ２２を送受信制御部１３１から送信側装置２００に送信させる。【０１２７】
このように、受信側装置１００は、データパケットＰ１７を受信するまで、データパケットを受信するごとに、ＡＣＫパケット（ＡＣＫ＝０）を送信側装置２００に送信する。【０１２８】
一方、送信側装置２００は、ＴＤＡＣＫ対応の通信機能を有しているため、ＡＣＫ＝０を示すＡＣＫパケットＰ２１，Ｐ２２，Ｐ２３を受信すると、シーケンス番号０を示すデータパケットＰ２４（ロスパケット）を受信側装置１００に再送する。【０１２９】
受信側装置１００の送受信制御部１３１は、再送されたデータパケットＰ２４を受信すると、そのデータパケットＰ２４を受信用バッファメモリ１２０に格納する。【０１３０】
その結果、受信用バッファメモリ１２０には、それぞれシーケンス番号０，１，２，３を示すデータパケットが格納されるため、これらのデータパケットは中央制御部１４０に速やかに受け渡される。【０１３１】
ここで、受信側装置１００の再送要求部１３５は、再送されたロスパケットが受信されて受信用バッファメモリ１２０に格納されると、パケット廃棄部１３４によって廃棄された廃棄パケットの再送を送信側装置２００に要求する。【０１３２】
具体的に、再送要求部１３５は、パケット廃棄部１３４から通知された廃棄パケットのシーケンス番号４，５，６，７のうち、例えば最も小さいシーケンス番号４と同一のＡＣＫ番号（ＡＣＫ＝４）を示す４つのＡＣＫパケットの生成をＡＣＫ生成部１３２に促す。【０１３３】
その結果、ＡＣＫ生成部１３２は、ＡＣＫ＝４を示す４つのＡＣＫパケット（否定応答パケット）Ｐ２６，Ｐ２７，Ｐ２８，Ｐ２９を生成して、これらのＡＣＫパケットを送受信制御部１３１から送信側装置２００に送信させる。なおこのとき、ウィンドウサイズ設定部１３３は、例えばウィンドウサイズとしてＲＷＩＮ＝４を設定し、上述のように送信されるＡＣＫパケットのそれぞれにはＲＷＩＮ＝４が示されている。また、ＡＣＫパケットＰ２７，Ｐ２８，Ｐ２９はＴＤＡＣＫとして送信される。【０１３４】
一方、送信側装置２００は、上述のような４つのＡＣＫパケットＰ２６，Ｐ２７，Ｐ２８，Ｐ２９を受信すると、それらのＡＣＫパケットによって示されるＡＣＫ番号４と同一のシーケンス番号（ＳＥＱ＝４）のデータパケットＰ３０を受信側装置１００に送信する。すなわち、廃棄パケット（データパケットＰ３０）の高速再送が行われる。【０１３５】
受信側装置１００の送受信制御部１３１は、データパケットＰ３０を受信すると受信用バッファメモリ１２０に格納する。その結果、シーケンス番号４の廃棄パケットは、再びデータパケットＰ３０として受信用バッファメモリ１２０に格納されて中央制御部１４０に受け渡される。【０１３６】
ここで、再送要求部１３５は、さらに、パケット廃棄部１３４から通知された廃棄パケットのシーケンス番号４，５，６，７のうち、二番目に小さいシーケンス番号５と同一のＡＣＫ番号（ＡＣＫ＝５）を示す４つのＡＣＫパケットの生成をＡＣＫ生成部１３２に促す。【０１３７】
その結果、ＡＣＫ生成部１３２は、ＡＣＫ＝５を示す４つのＡＣＫパケット（否定応答パケット）Ｐ３１，Ｐ３２，Ｐ３３，Ｐ３４を生成して、これらのＡＣＫパケットを送受信制御部１３１から送信側装置２００に送信させる。なおこのとき、ウィンドウサイズ設定部１３３は、例えばウィンドウサイズとしてＲＷＩＮ＝４を設定し、上述のように送信されるＡＣＫパケットのそれぞれにはＲＷＩＮ＝４が示されている。また、ＡＣＫパケットＰ３２，Ｐ３３，Ｐ３４はＴＤＡＣＫとして送信される。【０１３８】
送信側装置２００は、上述のような４つのＡＣＫパケットＰ３１，Ｐ３２，Ｐ３３，Ｐ３４を受信すると、それらのＡＣＫパケットによって示されるＡＣＫ番号５と同一のシーケンス番号（ＳＥＱ＝５）のデータパケットＰ３５を受信側装置１００に送信する。すなわち、廃棄パケット（データパケットＰ３５）の高速再送が行われる。【０１３９】
受信側装置１００の送受信制御部１３１は、データパケットＰ３５を受信すると受信用バッファメモリ１２０に格納する。その結果、シーケンス番号５の廃棄パケットは、再びデータパケットＰ３５として受信用バッファメモリ１２０に格納されて中央制御部１４０に受け渡される。【０１４０】
このような、廃棄パケットの高速再送が繰り返し行われることにより、高速転送設定時の肯定応答パケットであるＡＣＫパケットＰ１２（ＡＣＫ＝０，ＲＷＩＮ＝８）に応じて送信側装置２００から送信されて中央制御部１４０に受け渡されるべきデータパケットが全て、中央制御部１４０に受け渡される。【０１４１】
その結果、送受信制御部１３１は、パケットロスに対する復帰処理が完了したと判断して、その復帰処理完了をウィンドウサイズ設定部１３３に通知する。ウィンドウサイズ設定部１３３は、その通知を受けた後には、再び、高速転送設定を行う。【０１４２】
図７は、パケットロスが発生したときの受信側装置１００とＳＡＣＫ対応の送信側装置２００と間で行われる通信の一例を示すシーケンス図である。【０１４３】
まず、受信側装置１００と送信側装置２００とは、例えば、Three Way Handshakeなどにより、ＴＣＰ接続時のコネクションを設立する。このとき、受信側装置１００の送受信制御部１３１は、送信側装置２００の通信機能を特定する。例えば、送受信制御部１３１は、送信側装置２００の通信機能がＳＡＣＫに対応していると判断する。その結果、受信側装置１００は、パケットロスが発生したときには送信側装置２００に対してＳＡＣＫ対応の再送要求を行う。【０１４４】
具体的には、まず、受信側装置１００のウィンドウサイズ設定部１３３は、上述と同様、高速転送設定を行う。すなわち、ウィンドウサイズ設定部１３３は、受信用バッファメモリ１２０の容量が４ＫＢしかないにもかかわらず、８ＫＢのウィンドウサイズ（ＲＷＩＮ＝８）を設定する。その結果、ＡＣＫ生成部１３２は、ＡＣＫ＝０およびＲＷＩＮ＝８を示すＡＣＫパケットＰ１２を生成する。【０１４５】
このようにＡＣＫパケットＰ１２が生成されると、受信側装置１００の送受信制御部１３１は、そのＡＣＫパケットＰ１２を肯定応答パケットとして送信側装置２００に送信する。【０１４６】
送信側装置２００は、ＡＣＫパケットＰ１２を受信すると、上述と同様、そのＡＣＫパケットＰ１２の示すウィンドウサイズ（ＲＷＩＮ＝８）分のデータパケットＰ１３，Ｐ１４，…，Ｐ２０を送信する。【０１４７】
ここで、ＡＣＫパケットＰ１２に応じて送信側装置２００から送信されたデータパケットＰ１３，Ｐ１４，…，Ｐ２０のうち、データパケットＰ１３がネットワーク３００において消失する。つまり、パケットロスが発生する。【０１４８】
受信側装置１００の送受信制御部１３１は、データパケットＰ１４（ＳＥＱ＝１）を受信すると、シーケンス番号０のデータパケットを受信していないため、シーケンス番号０のデータパケット（ロスパケット）が消失したこと、すなわちパケットロスが発生したことを検知する。さらに、送受信制御部１３１は、ロスパケットのシーケンス番号０をＡＣＫ生成部１３２に通知する。【０１４９】
また、送受信制御部１３１は、データパケットＰ１４，Ｐ１５，Ｐ１６，Ｐ１７を順に受信して、受信用バッファメモリ１２０にそれらのデータパケット（ＳＥＱ＝１，２，３，４）を順に格納する。しかし、上述のように、シーケンス番号０のデータパケットＰ１３が受信用バッファメモリ１２０に格納されていないため、データパケットＰ１４，Ｐ１５，Ｐ１６，Ｐ１７を中央制御部１４０に受け渡すことができず、受信用バッファメモリ１２０の空き容量がなくなる。つまり、このとき、受信用バッファメモリ１２０は停滞状態となる。【０１５０】
そこで、パケット廃棄部１３４は、シーケンス番号４のデータパケットＰ１７を廃棄する。その結果、停滞状態は一時的に解かれ、受信用バッファメモリ１２０に空き容量ができ、受信用バッファメモリ１２０は、新たなデータパケットを格納し得る状態となる。【０１５１】
これにより、送受信制御部１３１は、送信側装置２００から送信されて受信したデータパケットＰ１８（ＳＥＱ＝５）を受信用バッファメモリ１２０に格納する。【０１５２】
データパケットＰ１８（ＳＥＱ＝５）が受信用バッファメモリ１２０に格納されると、受信用バッファメモリ１２０は、データパケットＰ１４，Ｐ１５，Ｐ１６，Ｐ１８（ＳＥＱ＝１，２，３，５）を格納することとなり、再び停滞状態となる。【０１５３】
そこで、パケット廃棄部１３４は、シーケンス番号５のデータパケットＰ１８を廃棄する。その結果、停滞状態は一時的に解かれ、受信用バッファメモリ１２０に空き容量ができ、受信用バッファメモリ１２０は、新たなデータパケットを格納し得る状態となる。【０１５４】
これにより、送受信制御部１３１は、送信側装置２００から送信されて受信したデータパケットＰ１９（ＳＥＱ＝６）を受信用バッファメモリ１２０に格納する。【０１５５】
このようなデータパケットの格納と廃棄とは、シーケンス番号７のデータパケット（最終パケット）Ｐ２０が受信側装置１００に受信されるまで繰り返される。【０１５６】
但し、パケット廃棄部１３４は、最終パケットであるデータパケットＰ２０が受信用バッファメモリ１２０に格納されてその受信用バッファメモリ１２０が停滞状態になると、その最終パケットであるデータパケットＰ２０ではなく、シーケンス番号３のデータパケットＰ１６を廃棄する。【０１５７】
すなわち、パケット廃棄部１３４は、受信用バッファメモリ１２０が停滞状態になったときには、直前に格納されたデータパケットが最終パケットであるか否かを判断する。なお、最終パケットとは、高速転送設定時の肯定応答パケットであるＡＣＫパケットＰ１２に対して送信側装置２００から送信されるデータパケットのうちの、最後に送信されるデータパケットである。【０１５８】
そして、パケット廃棄部１３４は、データパケットＰ２０が最終パケットであると判断すると、停滞状態にある受信用バッファメモリ１２０に格納されているデータパケットのうち、ＳＥＱ＝７を示すデータパケットＰ２０ではなく、他のＳＥＱ＝３を示すデータパケット（中間パケット）Ｐ１６を廃棄する。【０１５９】
その結果、パケット廃棄部１３４は、データパケットＰ１６，Ｐ１７，Ｐ１８，Ｐ１９（ＳＥＱ＝３，４，５，６）を廃棄することとなる。【０１６０】
このようにパケット廃棄部１３４が最終パケットを削除せずに受信用バッファメモリ１２０に残しておくことにより、再送要求部１３５は、受信用バッファメモリ１２０に格納されていない複数の廃棄パケットを一括して再送させるためのＳＡＣＫパケットの生成をＡＣＫ生成部１３２に促すことができる。例えば、再送要求部１３５は、ＳＥＱ＝１，２，７を示すデータパケットＰ１４，Ｐ１５，Ｐ２０が受信用バッファメモリ１２０に格納されているため、通常のＡＣＫ番号０に加えて、連続するシーケンス番号の先頭と最後であるＳＥＱ＝１，２と、何れのシーケンス番号とも連続していないシーケンス番号であるＳＥＱ＝７とを送信側装置２００に通知する。つまり、このときに生成されるＳＡＣＫパケットは、受信用バッファメモリ１２０に格納されている３つのデータパケットのシーケンス番号１，２，７をＡＣＫ番号として示すことにより、シーケンス番号２とシーケンス番号７との間のシーケンス番号３〜６を、再送要求の対象とされているデータパケットのシーケンス番号として示すことができる。【０１６１】
また、受信側装置１００は、上述のデータパケットＰ１４，Ｐ１５，Ｐ１６，Ｐ１７を受信すると、それらがシーケンス番号０のデータパケットでないため、その受信ごとに、ＡＣＫ＝０を示す否定応答パケットであるＡＣＫパケットＰ２１，Ｐ２２，Ｐ２３，Ｐ２５を送信側装置２００に送信する。【０１６２】
すなわち、送受信制御部１３１がデータパケットＰ１４（ＳＥＱ＝１）を受信したときにパケットロスの発生を検知すると、ウィンドウサイズ設定部１３３は、高速転送設定を停止して、通常転送設定を行う。その結果、ウィンドウサイズ設定部１３３は、受信用バッファメモリ１２０の空き容量をウィンドウサイズ（ＲＷＩＮ＝３）として設定する。【０１６３】
これにより、ＡＣＫ生成部１３２は、送受信制御部１３１でデータパケットＰ１４（ＳＥＱ＝１）が受信されると、ＡＣＫ＝０およびＲＷＩＮ＝３を示すＡＣＫパケット（否定応答パケット）Ｐ２１を生成してそのＡＣＫパケットＰ２１を送受信制御部１３１から送信側装置２００に送信させる。【０１６４】
さらに、送受信制御部１３１がデータパケットＰ１５（ＳＥＱ＝２）を受信したときにも、ウィンドウサイズ設定部１３３は通常転送設定を行う。すなわち、ウィンドウサイズ設定部１３３は、受信用バッファメモリ１２０の空き容量をウィンドウサイズ（ＲＷＩＮ＝２）として設定する。【０１６５】
これにより、ＡＣＫ生成部１３２は、送受信制御部１３１でデータパケットＰ１５（ＳＥＱ＝２）が受信されると、ＡＣＫ＝０およびＲＷＩＮ＝２を示すＡＣＫパケット（否定応答パケット）Ｐ２２を生成してそのＡＣＫパケットＰ２２を送受信制御部１３１から送信側装置２００に送信させる。【０１６６】
このように、受信側装置１００は、データパケットＰ１７を受信するまで、データパケットを受信するごとに、ＡＣＫパケット（ＡＣＫ＝０）を送信側装置２００に送信する。【０１６７】
ここで、受信側装置１００の再送要求部１３５は、最終パケットであるシーケンス番号７のデータパケットＰ２０が受信用バッファメモリ１２０に格納されてシーケンス番号３のデータパケットＰ１６が廃棄されると、パケット廃棄部１３４によって廃棄された廃棄パケットの再送を送信側装置２００に要求する。【０１６８】
具体的に、再送要求部１３５は、受信用バッファメモリ１２０に格納されているデータパケットのシーケンス番号を特定する。上述の場合には、受信用バッファメモリ１２０には、データパケットＰ１４，Ｐ１５，２０（ＳＥＱ＝１，２，７）が格納されているため、再送要求部１３５はシーケンス番号１，２，７を特定する。そして、再送要求部１３５は、特定したシーケンス番号１，２，７をＡＣＫ生成部１３２に通知して、それらのシーケンス番号をそれぞれＡＣＫ番号として示すＳＡＣＫパケットを生成するようにＡＣＫ生成部１３２に指示する。なお、この例の場合、上述のように特定されたシーケンス番号１，２，７のうち、連続しているシーケンス番号がＳＥＱ＝１，２であって、その先頭と最後のシーケンス番号がＳＥＱ＝１，２であるため、再送要求部１３５は、その特定されたシーケンス番号１，２，７を全てＡＣＫ生成部１３２に通知している。【０１６９】
その結果、ＡＣＫ生成部１３２は、通常のＡＣＫ＝０と、ＡＣＫ＝１，２，７（欠落しているデータパケットのシーケンス番号３〜６）とを示すＳＡＣＫパケットＰ２６を生成して、そのＳＡＣＫパケットＰ２６を送受信制御部１３１から送信側装置２００に送信させる。なおこのとき、ウィンドウサイズ設定部１３３は、例えばウィンドウサイズとしてＲＷＩＮ＝１を設定し、上述のように送信されるＳＡＣＫパケットにはＲＷＩＮ＝１が示されている。【０１７０】
一方、送信側装置２００は、ＳＡＣＫ対応の通信機能を有しているため、ＡＣＫ＝０を示すＡＣＫパケットＰ２１，Ｐ２２，Ｐ２３を受信すると、シーケンス番号０を示すデータパケットＰ２４（ロスパケット）を受信側装置１００に再送する。【０１７１】
受信側装置１００の送受信制御部１３１は、再送されたデータパケットＰ２４を受信すると、そのデータパケットＰ２４を受信用バッファメモリ１２０に格納する。【０１７２】
その結果、受信用バッファメモリ１２０には、それぞれシーケンス番号０，１，２を示すデータパケットが格納されるため、これらのデータパケットは中央制御部１４０に速やかに受け渡される。【０１７３】
また、送信側装置２００は、上述のようなＳＡＣＫパケットＰ２６を受信すると、そのＳＡＣＫパケットＰ２６によって特定されるシーケンス番号（ＳＥＱ＝３〜６）のデータパケットＰ２７，Ｐ２８，Ｐ２９，Ｐ３０を受信側装置１００に送信する。すなわち、廃棄パケット（データパケットＰ２７，Ｐ２８，Ｐ２９，Ｐ３０）の高速再送が一括して行われる。【０１７４】
受信側装置１００の送受信制御部１３１は、データパケットＰ２７，Ｐ２８，Ｐ２９，Ｐ３０を受信すると受信用バッファメモリ１２０に格納する。その結果、シーケンス番号３，４，５，６の廃棄パケットは、再びデータパケットＰ２７，Ｐ２８，Ｐ２９，Ｐ３０として受信用バッファメモリ１２０に格納されて中央制御部１４０に受け渡される。さらに、その後、受信用バッファメモリ１２０に格納されていたシーケンス番号７のデータパケットＰ２０も中央制御部１４０に受け渡される。【０１７５】
このような、廃棄パケットの高速再送が行われることにより、高速転送設定時の肯定応答パケットであるＡＣＫパケットＰ１２（ＡＣＫ＝０，ＲＷＩＮ＝８）に応じて送信側装置２００から送信されて中央制御部１４０に受け渡されるべきデータパケットが全て、中央制御部１４０に受け渡される。【０１７６】
その結果、送受信制御部１３１は、パケットロスに対する復帰処理が完了したと判断して、その復帰処理完了をウィンドウサイズ設定部１３３に通知する。したがって、ウィンドウサイズ設定部１３３は、その通知を受けた後には、再び、高速転送設定を行う。【０１７７】
図８は、本実施の形態における受信側装置１００の全体的な動作を示すフローチャートである。【０１７８】
まず、受信側装置１００は、ウィンドウサイズ設定部１３３による高速転送設定により、受信用バッファメモリ１２０の容量より大きなウィンドウサイズを示すＡＣＫパケットを肯定応答パケットとして生成して送信側装置２００に送信する（ステップＳ１００）。これにより、送信側装置２００にはそのウィンドウサイズが通知され、送信側装置２００からは、そのウィンドウサイズ分のデータパケットが送信される。【０１７９】
受信側装置１００は、そのＡＣＫパケットに応じて送信側装置２００から送信されたデータパケットが消失したか否か、すなわちパケットロスが発生したか否かを判別する（ステップＳ１０２）。ここで、受信側装置１００は、パケットロスが発生したと判別したときには（ステップＳ１０２のＹ）、そのパケットロスによって生じる受信用バッファメモリ１２０の停滞状態を解消するために、復帰処理を実行する（ステップＳ１０４）。【０１８０】
一方、受信側装置１００は、パケットロスが発生していないと判別したときや（ステップＳ１０２のＮ）、復帰処理の実行が完了したときには、ステップＳ１００で通知されたウィンドウサイズ分のデータパケットを全て受信する。その後、受信側装置１００は、送信側装置２００からのデータパケットの受信を終了すべきか否かを判別する（ステップＳ１０６）。【０１８１】
ここで、受信側装置１００は、終了すべきでないと判別すると（ステップＳ１０６のＮ）、ステップＳ１００からの処理を繰り返し実行し、終了すべきと判別すると（ステップＳ１０６のＹ）、全ての処理を終了する。【０１８２】
図９は、受信側装置１００の復帰処理（図８のステップＳ１０４）における動作を示すフローチャートである。【０１８３】
受信側装置１００は、送信側装置２００とコネクションを設立するときに、送信側装置２００の通信機能を特定しており、パケットロスが発生したときには、送信側装置２００の通信機能に応じた復帰処理を行う。【０１８４】
具体的に、受信側装置１００は、まず、送信側装置２００がＳＡＣＫ対応の通信機能を有しているか否かを判別する（ステップＳ２００）。ここで、受信側装置１００は、送信側装置２００がＳＡＣＫ対応の通信機能を有していると判別すると（ステップＳ２００のＹ）、図７を用いて説明したような復帰処理を行う。【０１８５】
すなわち、受信側装置１００のパケット廃棄部１３４は、受信用バッファメモリ１２０が停滞状態にあると、その受信用バッファメモリ１２０に格納されている複数（４つ）のデータパケットから、１つの中間パケットを廃棄する（ステップＳ２０２）。ここで、中間パケットとは、パケットロスが発生する直前の高速転送設定時に送信されたＡＣＫパケットに応じて、送信側装置２００から送信されるデータパケットのうち、最終パケット以外の最近格納されたデータパケットである。【０１８６】
このように中間パケットが廃棄されることによって、受信用バッファメモリ１２０に空き容量ができる。したがって、その後に、送信側装置２００からデータパケットが送信されると、受信側装置１００の送受信制御部１３１は、そのデータパケットを受信してその受信用バッファメモリ１２０に格納する（ステップＳ２０４）。その結果、受信用バッファメモリ１２０は再び停滞状態になる。【０１８７】
このとき、受信側装置１００のパケット廃棄部１３４は、ステップＳ２０４で格納されたデータパケットが最終パケットか否かを判別する（ステップＳ２０６）。【０１８８】
ここで、パケット廃棄部１３４は、最終パケットでないと判別すると（ステップＳ２０６のＮ）、最近のＡＣＫパケット（肯定応答パケット）が高速転送設定で送信されてから所定の時間が経過したか否か、すなわちタイムアウトが生じたか否かを判別する（ステップＳ２０８）。パケット廃棄部１３４は、タイムアウトが生じていないと判別すると（ステップＳ２０８のＮ）、再びステップＳ２０２からの処理を繰り返し実行する。【０１８９】
一方、パケット廃棄部１３４は、ステップＳ２０６で最終パケットであると判別すると（ステップＳ２０６のＹ）、その最終パケットを受信用バッファメモリ１２０に残したまま、中間パケットを廃棄する（ステップＳ２１０）。その結果、受信用バッファメモリ１２０の停滞状態は解かれて、受信用バッファメモリ１２０は、送信側装置２００から再送されるロスパケットを格納し得る状態となる。【０１９０】
また、パケット廃棄部１３４は、ステップＳ２０８でタイムアウトが生じたと判別すると（ステップＳ２０８のＹ）、直前のステップＳ２０４で格納された中間パケットを最終パケットとして扱い、その最終パケットを受信用バッファメモリ１２０に残したまま、他の中間パケットを廃棄する（ステップＳ２１０）。その結果、上述と同様、受信用バッファメモリ１２０の停滞状態は解かれて、受信用バッファメモリ１２０は、送信側装置２００から再送されるロスパケットを格納し得る状態となる。【０１９１】
なお、送受信制御部１３１は、最終パケット以外のデータパケットを受信すると、その受信ごとに、ロスパケットの再送を促すＡＣＫパケット（否定応答パケット）を送信側装置２００に送信している。したがって、このようなＡＣＫパケットに応じて、送信側装置２００からロスパケットが再送されると、受信側装置１００の送受信制御部１３１は、そのロスパケットを受信して受信用バッファメモリ１２０に格納する。その結果、受信用バッファメモリ１２０に格納されているデータパケットのうち、そのロスパケットを含む幾つかのデータパケットが速やかに中央制御部１４０に受け渡される。【０１９２】
さらに、受信側装置１００は、ステップＳ２０２，Ｓ２１０で廃棄された全ての中間パケット（廃棄パケット）の再送を一括して要求するＳＡＣＫパケットを送信側装置２００に送信する（ステップＳ２１２）。【０１９３】
そして、受信側装置１００は、そのＳＡＣＫパケットによって廃棄パケットを全て受信したか否かを判別し（ステップＳ２１４）、受信していないと判別したときには（ステップＳ２１４のＮ）、再びステップＳ２１２からの処理を繰り返し実行する。【０１９４】
また、受信側装置１００は、ステップＳ２００で、送信側装置２００がＳＡＣＫ対応の通信機能を有していないと判別すると（ステップＳ２００のＮ）、さらに、送信側装置２００がＴＤＡＣＫ対応の通信機能を有しているか否かを判別する（ステップＳ２１６）。ここで、受信側装置１００は、送信側装置２００がＴＤＡＣＫ対応の通信機能を有していると判別すると（ステップＳ２１６のＹ）、図６を用いて説明したような復帰処理を行う。【０１９５】
すなわち、受信側装置１００のパケット廃棄部１３４は、受信用バッファメモリ１２０が停滞状態にあると、その受信用バッファメモリ１２０に格納されている複数（４つ）のデータパケットから、１つの中間パケットを廃棄する（ステップＳ２１８）。【０１９６】
このように中間パケットが廃棄されることによって、受信用バッファメモリ１２０に空き容量ができる。したがって、その後に、送信側装置２００からデータパケットが送信されると、受信側装置１００の送受信制御部１３１は、そのデータパケットを受信してその受信用バッファメモリ１２０に格納する（ステップＳ２２０）。その結果、受信用バッファメモリ１２０は再び停滞状態になる。【０１９７】
このとき、受信側装置１００のパケット廃棄部１３４は、ステップＳ２２０で格納されたデータパケットが最終パケットか否かを判別する（ステップＳ２２２）。【０１９８】
ここで、パケット廃棄部１３４は、最終パケットでないと判別すると（ステップＳ２２２のＮ）、最近のＡＣＫパケット（肯定応答パケット）が高速転送設定で送信されてから所定の時間が経過したか否か、すなわちタイムアウトが生じたか否かを判別する（ステップＳ２２４）。パケット廃棄部１３４は、タイムアウトが生じていないと判別すると（ステップＳ２２４のＮ）、再びステップＳ２１８からの処理を繰り返し実行する。【０１９９】
一方、パケット廃棄部１３４は、ステップＳ２２２で最終パケットであると判別すると（ステップＳ２２２のＹ）、その最終パケットを廃棄する（ステップＳ２２６）。その結果、受信用バッファメモリ１２０の停滞状態は解かれて、受信用バッファメモリ１２０は、送信側装置２００から再送されるロスパケットを格納し得る状態となる。【０２００】
また、パケット廃棄部１３４は、ステップＳ２２４でタイムアウトが生じたと判別すると（ステップＳ２２４のＹ）、直前のステップＳ２２０で格納された中間パケットを最終パケットとして扱い、その最終パケットを廃棄する（ステップＳ２２６）。その結果、上述と同様、受信用バッファメモリ１２０の停滞状態は解かれて、受信用バッファメモリ１２０は、送信側装置２００から再送されるロスパケットを格納し得る状態となる。【０２０１】
なお、送受信制御部１３１は、データパケットを受信すると、その受信ごとに、ロスパケットの再送を促すＡＣＫパケット（否定応答パケット）を送信側装置２００に送信している。したがって、このようなＡＣＫパケットに応じて、送信側装置２００からロスパケットが再送されると、受信側装置１００の送受信制御部１３１は、そのロスパケットを受信して受信用バッファメモリ１２０に格納する。その結果、受信用バッファメモリ１２０に格納されているデータパケットのうち、そのロスパケットを含む幾つかのデータパケットが速やかに中央制御部１４０に受け渡される。【０２０２】
さらに、受信側装置１００は、ステップＳ２２６の後に再送されたロスパケットを受信すると、ステップＳ２１８，Ｓ２２６で廃棄された全ての中間パケット（廃棄パケット）のうち１つの廃棄パケットの再送を要求する４つのＡＣＫパケット（否定応答パケット）を送信側装置２００に送信する（ステップＳ２２８）。なお、この４つのＡＣＫパケットのうち３つはＴＤＡＣＫパケットである。【０２０３】
そして、受信側装置１００は、そのＴＤＡＣＫパケットの送信によって廃棄パケットを全て受信したか否かを判別する（ステップＳ２３０）。ここで、受信側装置１００は、全て受信していないと判別したときには（ステップＳ２３０のＮ）、最近のＡＣＫパケット（肯定応答パケット）が高速転送設定で送信されてから所定の時間が経過したか否か、すなわちタイムアウトが生じたか否かを判別する（ステップＳ２３２）。受信側装置１００は、タイムアウトが生じていないと判別すると（ステップＳ２３２のＮ）、再びステップＳ２２８からの処理を実行する。【０２０４】
一方、受信側装置１００は、タイムアウトが生じたと判別すると（ステップＳ２３２のＹ）、受信側装置１００のパケット廃棄部１３４は、受信用バッファメモリ１２０内の全てのデータパケットを廃棄して、送信側装置２００から改めて再送されるデータパケットを受信する（ステップＳ２３４）。【０２０５】
なお、受信側装置１００は、ステップＳ２２８で廃棄パケットの再送を要求する前に、再送要求により全ての廃棄パケットを順次再送させて受信するまでに要する時間と、タイムアウトにより全ての廃棄パケットを再送させて受信するまでに要する時間とを比較してもよい。この場合、受信側装置１００は、再送要求における時間がタイムアウトにおける時間よりも短いと判断した場合には、ステップＳ２２８の処理を実行し、逆に、タイムアウトにおける時間が再送要求における時間よりも短いと判断した場合には、ステップＳ２２８の処理を実行せずにタイムアウトが生じるまで待機する。【０２０６】
また、受信側装置１００は、ステップＳ２００で、送信側装置２００がＴＤＡＣＫ対応の通信機能を有していないと判別すると（ステップＳ２１６のＮ）、タイムアウトによる復帰処理を行う。【０２０７】
つまり、受信側装置１００は、タイムアウトが生じるまで待機し（ステップＳ２３６）、上述のステップＳ２３４の処理を実行する。【０２０８】
このように本実施の形態では、受信用バッファメモリ１２０の容量よりも大きなウィンドウサイズがＡＣＫパケットにより送信側装置２００に通知されるため、受信用バッファメモリ１２０の容量が少なくても、ＲＴＴ内において送信側装置２００から多くのデータを送信させることができ、その結果、記憶容量という環境的な制約を受けることなく効率的なデータ転送を行うことができる。【０２０９】
さらに、本実施の形態では、パケットロスが発生して受信用バッファメモリ１２０が停滞状態になったときには、受信用バッファメモリ１２０に格納されているデータパケットが廃棄されて空き容量が確保されるため、再送されたロスパケットを受信用バッファメモリ１２０に格納して、その受信用バッファメモリ１２０に格納されている多くのデータパケットを中央制御部１４０のアプリケーションプログラムに受け渡すことができる。その結果、受信用バッファメモリ１２０が停滞状態になることよってデータ受信処理（データ転送）が停止されるのを避けることができる。【０２１０】
さらに、廃棄されたデータパケットの再送が要求されるため、タイムアウトの発生を待たずに、その廃棄されたデータパケットを再び受信して受信用バッファメモリ１２０に格納することができる。その結果、データ受信処理（データ転送）が滞ったとしても、データ転送効率を著しく劣化させることを避けることができる。つまり、高速転送設定により設定されて通知されたウィンドウサイズに応じて送信側装置２００から送信される全てのデータパケットを迅速に受信することができる。【０２１１】
（変形例１）
上記実施の形態の受信側装置１００は、送信側装置２００がＴＤＡＣＫ対応またはＳＡＣＫ対応の通信機能を有しているときには、廃棄パケットの再送を送信側装置２００に要求した。しかし、本発明に係る通信装置は、廃棄パケットの再送を送信側装置２００に要求しなくてもよい。【０２１２】
図１０は、本変形例に係る受信側装置１００と送信側装置２００との間で行われる通信の一例を示すシーケンス図である。なお、この例では、送信側装置２００はＴＤＡＣＫ対応の通信機能を有している。【０２１３】
まず、受信側装置１００は、図６または図７に示す処理と同様の処理を行うことにより、シーケンス番号４のデータパケットＰ１７を受信して受信用バッファメモリ１２０に格納する。その結果、受信用バッファメモリ１２０は上述のように停滞状態となる。【０２１４】
ここで、パケット廃棄部１３４は、その停滞状態を解くために、シーケンス番号４のデータパケットＰ１７を廃棄すると、その廃棄パケットのシーケンス番号４をＡＣＫ生成部１３２に通知する。そして、送受信制御部１３１は、送信側装置２００から送信されて受信したデータパケットＰ１８（ＳＥＱ＝５）を受信用バッファメモリ１２０に格納する。【０２１５】
データパケットＰ１８（ＳＥＱ＝５）が受信用バッファメモリ１２０に格納されると、受信用バッファメモリ１２０は、データパケットＰ１４，Ｐ１５，Ｐ１６，Ｐ１８（ＳＥＱ＝１，２，３，５）を格納することとなり、再び停滞状態となる。【０２１６】
そこで、パケット廃棄部１３４は、その停滞状態を解くために、シーケンス番号５のデータパケットＰ１８を廃棄すると、その廃棄パケットのシーケンス番号５をＡＣＫ生成部１３２に通知する。そして、送受信制御部１３１は、送信側装置２００から送信されて受信したデータパケットＰ１９（ＳＥＱ＝６）を受信用バッファメモリ１２０に格納する。【０２１７】
このようなデータパケットの格納と廃棄とは、シーケンス番号７のデータパケット（最終パケット）Ｐ２０が受信側装置１００に受信されるまで繰り返される。その結果、受信用バッファメモリ１２０に格納されたデータパケットＰ２０（ＳＥＱ＝７）は削除され、受信用バッファメモリ１２０に空き容量ができ、受信用バッファメモリ１２０は、新たなデータパケットを格納し得る状態となる。【０２１８】
また、受信側装置１００は、データパケットＰ１４，Ｐ１５，Ｐ１６，Ｐ１７を受信すると、図６または図７に処理と同様、その受信ごとにＡＣＫ＝０を示すＡＣＫパケット（否定応答パケット）Ｐ２１，Ｐ２２，Ｐ２３，Ｐ２５を送信側装置２００に送信する。【０２１９】
一方、送信側装置２００は、ＴＤＡＣＫ対応の通信機能を有しているため、ＡＣＫ＝０を示すＡＣＫパケットＰ２１，Ｐ２２，Ｐ２３を受信すると、シーケンス番号０を示すデータパケットＰ２４（ロスパケット）を受信側装置１００に再送する。【０２２０】
受信側装置１００の送受信制御部１３１は、再送されたデータパケットＰ２４を受信すると、そのデータパケットＰ２４を受信用バッファメモリ１２０に格納する。【０２２１】
その結果、受信用バッファメモリ１２０には、それぞれシーケンス番号０，１，２，３を示すデータパケットが格納されるため、これらのデータパケットは中央制御部１４０に速やかに受け渡される。【０２２２】
また、送受信制御部１３１は、再送されたデータパケットＰ２４を受信すると、そのデータパケットＰ２４に対するＡＣＫパケット（否定応答パケット）Ｐ２６を送信側装置２００に送信する。このＡＣＫパケットＰ２６は、ＡＣＫ＝４およびＲＷＩＮ＝４を示す。【０２２３】
つまり、このとき、ＡＣＫ生成部１３２は、ウィンドウサイズ設定部１３３による通常転送設定により設定されたウィンドウサイズ（ＲＷＩＮ＝４）と、パケット廃棄部１３４から通知された廃棄パケットのシーケンス番号４と同一のＡＣＫ番号（ＡＣＫ＝４）とを示すＡＣＫパケットＰ２６を生成している。【０２２４】
送信側装置２００は、ＡＣＫ＝０およびＲＷＩＮ＝４を示すＡＣＫパケットＰ２６を受信すると、シーケンス番号０〜７のデータパケットＰ１３〜Ｐ２０を送信しているため、シーケンス番号８，９，１０，１１を示すデータパケットＰ２７，２８，２９，３０を受信側装置１００に送信する。【０２２５】
受信側装置１００の送受信制御部１３１は、データパケットＰ２７，Ｐ２８，Ｐ２９，Ｐ３０を順に受信して、受信用バッファメモリ１２０にそれらのデータパケット（ＳＥＱ＝８，９，１０，１１）を順に格納する。しかし、上述のように、シーケンス番号４のデータパケットＰ１７が受信用バッファメモリ１２０に格納されていないため、データパケットＰ２７，Ｐ２８，Ｐ２９，Ｐ３０を中央制御部１４０に受け渡すことができず、受信用バッファメモリ１２０の空き容量がなくなる。つまり、このとき、受信用バッファメモリ１２０は停滞状態となる。【０２２６】
そこで、パケット廃棄部１３４は、シーケンス番号１１のデータパケットＰ３０を廃棄し、その廃棄パケットのシーケンス番号１１をＡＣＫ生成部１３２に通知する。その結果、停滞状態は一時的に解かれ、受信用バッファメモリ１２０に空き容量ができ、受信用バッファメモリ１２０は、新たなデータパケットを格納し得る状態となる。【０２２７】
また、受信側装置１００は、上述のデータパケットＰ２７，Ｐ２８，Ｐ２９，Ｐ３０を受信すると、それらがシーケンス番号４のデータパケットでないため、その受信ごとに、ＡＣＫ＝４を示す否定応答パケットであるＡＣＫパケットＰ３１，Ｐ３２，Ｐ３３，Ｐ３５を送信側装置２００に送信する。【０２２８】
すなわち、送受信制御部１３１でデータパケットＰ２７（ＳＥＱ＝８）が受信されると、そのデータパケットＰ２７のシーケンス番号は、ＡＣＫパケットＰ２６の示すＡＣＫ番号４と同一ではない。したがって、ＡＣＫ生成部１３２は、ウィンドウサイズ設定部１３３による通常転送設定により設定されたウィンドウサイズ（ＲＷＩＮ＝３）と上述のＡＣＫ番号４とを示すＡＣＫパケットＰ３１を否定応答パケットとして生成し、そのＡＣＫパケットＰ３１を送受信制御部１３１から送信側装置２００に送信させる。【０２２９】
さらに、送受信制御部１３１でデータパケットＰ２８（ＳＥＱ＝９）が受信されると、そのデータパケットＰ２８のシーケンス番号は、ＡＣＫパケットＰ２６の示すＡＣＫ番号４と同一ではない。したがって、ＡＣＫ生成部１３２は、ウィンドウサイズ設定部１３３による通常転送設定により設定されたウィンドウサイズ（ＲＷＩＮ＝２）と上述のＡＣＫ番号４とを示すＡＣＫパケットＰ３２を否定応答パケットとして生成し、そのＡＣＫパケットＰ３２を送受信制御部１３１から送信側装置２００に送信させる。【０２３０】
このように、受信側装置１００は、データパケットＰ３０を受信するまで、データパケットを受信するごとに、ＡＣＫ＝４を示すＡＣＫパケットを否定応答パケットとして送信側装置２００に送信する。【０２３１】
送信側装置２００は、ＴＤＡＣＫ対応の通信機能を有しているため、ＡＣＫ＝４を示すＡＣＫパケットＰ３１，Ｐ３２，Ｐ３３を受信すると、シーケンス番号４を示すデータパケットＰ３４を受信側装置１００に再送する。【０２３２】
受信側装置１００の送受信制御部１３１は、再送されたデータパケットＰ３４を受信すると、そのデータパケットＰ３４を受信用バッファメモリ１２０に格納する。【０２３３】
その結果、受信用バッファメモリ１２０には、シーケンス番号４を示すデータパケットが格納されるため、そのデータパケットは中央制御部１４０に速やかに受け渡される。【０２３４】
また、受信側装置１００の送受信制御部１３１は、再送されたデータパケットＰ３４を受信すると、ＡＣＫパケット（否定応答パケット）Ｐ３６を送信側装置２００に送信する。このＡＣＫパケットＰ３６は、ＡＣＫ＝５およびＲＷＩＮ＝１を示す。【０２３５】
つまり、このとき、ＡＣＫ生成部１３２は、ウィンドウサイズ設定部１３３による通常転送設定により設定されたウィンドウサイズ（ＲＷＩＮ＝１）と、パケット廃棄部１３４から通知された廃棄パケットのシーケンス番号５と同一のＡＣＫ番号（ＡＣＫ＝５）とを示すＡＣＫパケットＰ３６を生成している。【０２３６】
このように、受信側装置１００と送信側装置２００との間で通信処理が行われるが、廃棄パケットの再送要求が行われないため、最初のＡＣＫパケットＰ１２で示されたシーケンス番号０〜７のデータパケットが全て受信側装置１００に受信されて中央制御部１４０に受け渡されるまでには時間がかかる。また、ＡＣＫパケットＰ１２の送受信が行われてから、シーケンス番号０〜７の全てのデータパケットが受信されない状態で所定時間が経過したときには、タイムアウトが発生する。例えば、ＡＣＫパケットＰ３６が送信された後に、タイムアウトが発生すると、送信側装置２００からシーケンス番号５〜７のデータパケットが再送される。したがって、受信側装置１００は、ＡＣＫパケットＰ１２の送受信が行われてから、シーケンス番号０〜７の全てのデータパケットが受信されない状態で所定時間が経過したときには、タイムアウトが発生したと判断し、受信用バッファメモリ１２０内の全てのデータパケットを廃棄する。【０２３７】
その結果、受信側装置１００は、再び高速転送設定により設定されたウィンドウサイズ（ＲＷＩＮ＝８）を示すＡＣＫパケットを送信側装置２００に送信し、シーケンス番号８のデータパケットから各データパケットを順次受信する。【０２３８】
（変形例２）
上記実施の形態では、受信側装置１００は、送信側装置２００から送信されるデータを利用する中央制御部１４０およびメインメモリ１５０を備えていたが、これらを備えていなくてもよい。すなわち、本発明に係る通信装置は、送信側装置２００から送信されるデータを中継して、そのデータを利用するデータ処理装置に送信する受信中継装置であってもよい。【０２３９】
図１１は、本変形例に係る受信中継装置の構成を示す構成図である。【０２４０】
受信中継装置１００ａは、ネットワーク３００を介して送信側装置２００と接続され、その送信側装置２００とＴＣＰ／ＩＰに従った通信を行う。また、受信中継装置１００ａは、ネットワーク３０１を介してデータ処理装置４００と接続されている。【０２４１】
この受信中継装置１００ａは、ＴＣＰ／ＩＰの終端として構成され、送信側装置２００から送信されたデータを受信し、その受信したデータをデータ処理装置４００に送信する。つまり、受信中継装置１００ａとデータ処理装置４００とから、上記実施の形態における受信側装置１００が構成される。【０２４２】
また、受信中継装置１００ａは、上記実施の形態における受信側装置１００の通信制御部１１０と、送信処理部１６０とを備えている。送信処理部１６０は、通信制御部１１０の受信用バッファメモリ１２０に格納されたデータパケットを取り出してデータ処理装置４００に送信する処理手段として構成されている。【０２４３】
（変形例３）
本変形例に係る受信側装置１００は、複数の通信フローのそれぞれのウィンドウサイズの合計が受信用バッファメモリ１２０の容量よりも大きくなるように、通信フローごとにウィンドウサイズを設定する。【０２４４】
図１２は、本変形例に係る受信側装置１００の動作を説明するための説明図である。【０２４５】
受信側装置１００は、例えば送信側装置２００ａ，２００ｂからデータを受信する処理を並列に行う。このとき、受信側装置１００のウィンドウサイズ設定部１３３は、送信側装置２００ａ，２００ｂのそれぞれに、例えば、６４ＫＢのウィンドウサイズを設定する。【０２４６】
つまり、ウィンドウサイズ設定部１３３は、送信側装置（通信フロー）のそれぞれに対して受信用バッファメモリ１２０の容量（１００ＫＢ）よりも小さいウィンドウサイズを設定する。そしてこのとき、ウィンドウサイズ設定部１３３は、全ての送信側装置（全ての通信フロー）に対して設定されるウィンドウサイズの合計が受信用バッファメモリ１２０の容量（１００ＫＢ）よりも大きくなるように、各送信側装置（各通信フロー）に対するウィンドウサイズを設定する。以下、このように１つの送信側装置（１つの通信フロー）に対して設定されるウィンドウサイズを拡大ウィンドウサイズという。【０２４７】
したがって、受信側装置１００は、送信側装置２００ａ，２００ｂのそれぞれに対して、その拡大ウィンドウサイズ（ＲＷＩＮ＝６４）をＡＣＫパケットにより通知する。【０２４８】
なお、上述の例では、受信側装置１００と複数の送信側装置のそれぞれとの間で複数の通信フローを設定したが、受信側装置１００と１つの送信側装置との間で複数の通信フローを設定してもよい。つまり、本変形例に係る受信側装置１００は、送信側装置の数に関わらず、通信フローごとに上述のような拡大ウィンドウサイズを設定する。【０２４９】
このように本変形例では、通信フローが複数であっても、各通信フローで通知される拡大ウィンドウサイズ（ＲＷＩＮ＝６４）の合計が受信用バッファメモリ１２０の容量（１００ＫＢ）よりも大きいため、複数の通信フローの処理が同時に滞らない限りスループットを改善することが可能となる。【０２５０】
（変形例４）
本変形例に係る受信側装置１００は、上述の変形例３に係る受信側装置１００と同様、各通信フローに対して拡大ウィンドウサイズを設定して通知するが、このとき、その通信フローの優先度に応じた拡大ウィンドウサイズを設定する。【０２５１】
図１３は、本変形例に係る受信側装置１００の動作を説明するための説明図である。【０２５２】
受信側装置１００は、例えば送信側装置２００ａ，２００ｂからデータを受信する処理を並列に行う。このとき、受信側装置１００の通信プロトコル処理部１３０は、送信側装置２００ａの通信フローに対する優先度と、送信側装置２００ｂの通信フローに対する優先度とを決定する。そして、通信プロトコル処理部１３０のウィンドウサイズ設定部１３３は、優先度の高い通信フローに対して大きな拡大ウィンドウサイズを設定し、優先度の低い通信フローに対して小さい拡大ウィンドウサイズを設定する。つまり、本変形例では、通信プロトコル処理部１３０が優先度決定手段として構成されている。【０２５３】
例えば、通信プロトコル処理部１３０は、送信側装置２００ｂの通信フローに対して高い優先度を決定し、送信側装置２００ａの通信フローに対して低い優先度を決定する。この場合、ウィンドウサイズ設定部１３３は、送信側装置２００ｂの通信フローに対して例えば９６ＫＢの拡大ウィンドウサイズを設定する。一方、ウィンドウサイズ設定部１３３は、送信側装置２００ａの通信フローに対して例えば６４ＫＢの拡大ウィンドウサイズを設定する。【０２５４】
通信プロトコル処理部１３０は、優先度を決定するときには、通信プロトコルや、中央制御部１４０で実行されているアプリケーションプログラムなどに基づいて優先度を決定する。例えば、通信プロトコル処理部１３０は、通信フローにおいてＦＴＰ（File Transfer Protocol）に従ったファイルの受信が行われる場合には、その通信フローに対して低い優先度を決定し、通信フローにおいてＨＴＴＰ（Hyper Text Transfer Protocol）に従った動画のストリーミング配信の受信が行われる場合には、その通信フローに対して高い優先度を決定する。【０２５５】
このように、受信側装置１００は、複数の通信フローのそれぞれでデータの受信を並列して行うときには、そのときごとに、各通信フローに対する優先度を動的に決定し、拡大ウィンドウサイズを設定する。【０２５６】
また、受信側装置１００は、送信側装置に対して静的な優先度を決定してもよい。この場合、受信側装置１００は、例えば、送信側装置２００ａに対して常に低い優先度を決定し、送信側装置２００ｂに対して常に高い優先度を決定する。したがって、受信側装置１００は、送信側装置２００ａ，２００ｂからデータを受信するときには、そのデータの内容や通信プロトコルに関わらず、送信側装置２００ａに対して小さい拡大ウィンドウサイズを設定し、送信側装置２００ｂに対して大きい拡大ウィンドウサイズを設定する。【０２５７】
なお、上述の例では、受信側装置１００と複数の送信側装置のそれぞれとの間で複数の通信フローを設定したが、受信側装置１００と１つの送信側装置との間で複数の通信フローを設定してもよい。【０２５８】
このように本変形例では、優先度に応じて、自在にスループットを制御することが可能となる。【０２５９】
（変形例５）
本変形例に係る受信側装置１００は、上述の変形例３に係る受信側装置１００と同様、各通信フローに対して拡大ウィンドウサイズを設定して通知するが、このとき、その通信フローの数に応じた拡大ウィンドウサイズを設定する。【０２６０】
図１４は、本変形例に係る受信側装置１００の動作を説明するための説明図である。【０２６１】
受信側装置１００は、例えば、図１２に示すように、２つの送信側装置２００ａ，２００ｂからデータを受信する処理を並列に行う場合、送信側装置２００ａ，２００ｂの通信フローに対してそれぞれ６４ＫＢの拡大ウィンドウサイズを設定する。【０２６２】
さらに、受信側装置１００は、例えば、図１４に示すように、４つの送信側装置２００ａ〜２００ｄからデータを受信する処理を並列に行う場合、送信側装置２００ａ〜２００ｄの通信フローに対してそれぞれ３２ＫＢの拡大ウィンドウサイズを設定する。【０２６３】
このように、受信側装置１００は、送信側装置（通信フロー）の数が多くなるほど小さくなるような拡大ウィンドウサイズを設定する。【０２６４】
なお、上述の例では、受信側装置１００と複数の送信側装置のそれぞれとの間で複数の通信フローを設定したが、受信側装置１００と１つの送信側装置との間で複数の通信フローを設定してもよい。【０２６５】
このように本変形例では、通信フロー数に応じて、スループットを制御することが可能となる。【０２６６】
（変形例６）
本変形例に係る受信側装置１００は、上述の変形例３に係る受信側装置１００と同様、各通信フローに対して拡大ウィンドウサイズを設定して通知するが、このとき、その通信フローの伝搬遅延時間に応じた拡大ウィンドウサイズを設定する。【０２６７】
図１５は、本変形例に係る受信側装置１００の動作を説明するための説明図である。【０２６８】
受信側装置１００は、例えば送信側装置２００ａ，２００ｂからデータを受信する処理を並列に行う。このとき、受信側装置１００の通信プロトコル処理部１３０は、送信側装置２００ａの通信フローに対する伝搬遅延時間と、送信側装置２００ｂの通信フローに対する伝搬遅延時間とを特定する。【０２６９】
なお、伝搬遅延時間とは、ＲＴＴからバッファ内の遅延時間を差し引いた残りの時間の半分に相当する時間である。また、受信側装置１００が、変形例２の受信中継装置１００ａとして構成されているときには、上述の伝搬遅延時間は、送信側装置２００と受信中継装置１００ａとの間における時間であっても、送信側装置２００とデータ処理装置４００との間における時間であってもよい。【０２７０】
そして、通信プロトコル処理部１３０のウィンドウサイズ設定部１３３は、例えば、伝搬遅延時間の長い通信フローに対して大きな拡大ウィンドウサイズを設定し、伝搬遅延時間の短い通信フローに対して小さい拡大ウィンドウサイズを設定する。これにより、各通信フローの通信時間を略均等にすることができる。【０２７１】
例えば、通信プロトコル処理部１３０は、送信側装置２００ａの通信フローに対する伝搬遅延時間（１０ｍｓ）と、送信側装置２００ｂの通信フローに対する伝搬遅延時間（２０ｍｓ）とを特定する。【０２７２】
この場合、ウィンドウサイズ設定部１３３は、送信側装置２００ａの通信フローに対して例えば３２ＫＢの拡大ウィンドウサイズを設定する。一方、ウィンドウサイズ設定部１３３は、送信側装置２００ｂの通信フローに対して例えば６４ＫＢの拡大ウィンドウサイズを設定する。【０２７３】
通信プロトコル処理部１３０は、通信フローにおける伝搬遅延時間を特定するときには、例えばＰＩＮＧ（Packet INternet Groper）を利用することによりその伝搬遅延時間を計測する。【０２７４】
このように、受信側装置１００は、複数の通信フローのそれぞれでデータの受信を並列して行うときには、そのときごとに、各通信フローに対する伝搬遅延時間を特定し、拡大ウィンドウサイズを設定する。【０２７５】
なお、上述の例では、受信側装置１００は、伝搬遅延時間の長い通信フローに対して大きな拡大ウィンドウサイズを設定し、伝搬遅延時間の短い通信フローに対して小さい拡大ウィンドウサイズを設定したが、逆に設定してもよい。つまり、受信側装置１００は、伝搬遅延時間の長い通信フローに対して小さな拡大ウィンドウサイズを設定し、伝搬遅延時間の短い通信フローに対して大きな拡大ウィンドウサイズを設定する。これにより、伝搬遅延時間が短い通信フローの通信時間をできるだけ短くし、その通信フローの終了後、他方の通信フローに対して大きなウィンドウサイズを設定することができる。【０２７６】
また、上述の例では、受信側装置１００と複数の送信側装置のそれぞれとの間で複数の通信フローを設定したが、受信側装置１００と１つの送信側装置との間で複数の通信フローを設定してもよい。【０２７７】
このように本変形例では、伝搬遅延時間というネットワークの状況に応じて、スループットを制御することが可能となる。【０２７８】
（変形例７）
本変形例に係る受信側装置１００は、上述の変形例３に係る受信側装置１００と同様、各通信フローに対して拡大ウィンドウサイズを設定して通知するが、このとき、その通信フローの伝送帯域に応じた拡大ウィンドウサイズを設定する。【０２７９】
図１６は、本変形例に係る受信側装置１００の動作を説明するための説明図である。【０２８０】
受信側装置１００は、例えば送信側装置２００ａ，２００ｂからデータを受信する処理を並列に行う。このとき、受信側装置１００の通信プロトコル処理部１３０は、送信側装置２００ａの通信フローにおける伝送帯域と、送信側装置２００ｂの通信フローにおける伝送帯域とを特定する。【０２８１】
そして、通信プロトコル処理部１３０のウィンドウサイズ設定部１３３は、例えば、伝送帯域の広い通信フローに対して大きな拡大ウィンドウサイズを設定し、伝送帯域の狭い通信フローに対して小さい拡大ウィンドウサイズを設定する。これにより、パケットロスの発生を抑えることができる。【０２８２】
例えば、通信プロトコル処理部１３０は、送信側装置２００ａの通信フローにおける伝送帯域（１０Ｍｂｐｓ）と、送信側装置２００ｂの通信フローに対する伝送帯域（２０Ｍｂｐｓ）とを特定する。【０２８３】
この場合、ウィンドウサイズ設定部１３３は、送信側装置２００ａの通信フローに対して例えば３２ＫＢの拡大ウィンドウサイズを設定する。一方、ウィンドウサイズ設定部１３３は、送信側装置２００ｂの通信フローに対して例えば６４ＫＢの拡大ウィンドウサイズを設定する。【０２８４】
通信プロトコル処理部１３０は、通信フローにおける伝送帯域を特定するときには、例えば、パケットロスが発生する帯域を見つけ出すことにより特定することができる。【０２８５】
このように、受信側装置１００は、複数の通信フローのそれぞれでデータの受信を並列して行うときには、そのときごとに、各通信フローに対する伝送帯域を特定し、拡大ウィンドウサイズを設定する。【０２８６】
また、受信側装置１００は、通信フローの通信媒体に対して静的な伝送帯域を特定してもよい。この場合、受信側装置１００は、例えば、光ファイバなどの通信媒体に対して常に広い伝送帯域を特定し、無線ＬＡＮなどの通信媒体に対して常に狭い伝送帯域を特定する。【０２８７】
したがって、受信側装置１００は、無線ＬＡＮを介して通信する送信側装置２００ａからデータを受信するときには、常に小さい拡大ウィンドウサイズを設定し、光ファイバを介して通信する送信側装置２００ｂからデータを受信するときには、常に大きい拡大ウィンドウサイズを設定する。【０２８８】
また、上述の例では、受信側装置１００と複数の送信側装置のそれぞれとの間で複数の通信フローを設定したが、受信側装置１００と１つの送信側装置との間で複数の通信フローを設定してもよい。【０２８９】
このように本変形例では、伝送帯域というネットワークの状況に応じて、スループットを制御することが可能となる。【０２９０】
（変形例８）
本変形例に係る受信側装置１００は、上述の変形例３に係る受信側装置１００と同様、各通信フローに対して拡大ウィンドウサイズを設定して通知するが、このとき、その受信用バッファメモリ１２０の空き容量に応じて拡大ウィンドウサイズを変更する。【０２９１】
図１７は、本変形例に係る受信側装置１００の動作を説明するための説明図である。【０２９２】
受信側装置１００は、例えば、図１２に示すように、送信側装置２００ａ，２００ｂからデータを受信する処理を並列に行う場合に、受信用バッファメモリ１２０の空き容量が１００ＫＢだけあると、送信側装置２００ａ，２００ｂの通信フローに対してそれぞれ６４ＫＢの拡大ウィンドウサイズを設定する。【０２９３】
ここで、例えば、図１７に示すように、受信用バッファメモリ１２０に格納されたデータが中央制御部１４０に受け渡される速度が低下すると、その受信用バッファメモリ１２０の空き容量が少なくなり２０ＫＢになる。【０２９４】
このとき、受信側装置１００は、例えば、送信側装置２００ａ，２００ｂの通信フローに対して設定されている拡大ウィンドウサイズ（６４ＫＢ）を３２ＫＢに一時的に変更する。【０２９５】
このように、受信側装置１００は、受信用バッファメモリ１２０の空き容量が少なくなるほど小さくなるような拡大ウィンドウサイズを設定する。【０２９６】
なお、受信側装置１００は、受信用バッファメモリ１２０の空き容量が閾値以下になったときに、各通信フローに対する拡大ウィンドウサイズを小さくしてもよい。ここで、受信側装置１００のウィンドウサイズ設定部１３３は、受信用バッファメモリ１２０の全体容量に対する割合によって上述の閾値を決定してもよい。例えば、ウィンドウサイズ設定部１３３は、受信用バッファメモリ１２０の全体容量の２０％に相当するサイズを閾値に決定する。また、ウィンドウサイズ設定部１３３は、ＲＴＴに応じて上述の閾値を決定してもよい。【０２９７】
また、上述の例では、受信側装置１００と複数の送信側装置のそれぞれとの間で複数の通信フローを設定したが、受信側装置１００と１つの送信側装置との間で複数の通信フローを設定してもよい。【０２９８】
このように本変形例では、受信用バッファメモリ１２０の空き容量に応じて、スループットを制御することが可能となる。【０２９９】
以上、本発明の通信装置について、上記実施の形態およびその変形例を用いて説明したが、本発明はこれらに限定されるものではない。【０３００】
例えば、上記実施の形態およびその変形例では、停滞状態にある受信用バッファメモリ１２０に新たなデータパケットを格納するために、その受信用バッファメモリ１２０に格納されているデータパケットを廃棄したが、その受信用バッファメモリ１２０に新たなデータパケットを格納することができるようになる処理であれば、どのような処理を行ってもよい。例えば、受信用バッファメモリ１２０からデータパケットを退避させてもよく、再送されたデータパケットの到着時に上書する領域を作成してもよい。【０３０１】
また、上記実施の形態およびその変形例では、受信用バッファメモリ１２０が停滞状態になったときにデータパケットを廃棄したが、受信用バッファメモリ１２０の空き容量が、０より大きい閾値以下になったときにデータパケットを廃棄してもよい。【０３０２】
また、上記実施の形態およびその変形例では、送信側装置２００がＳＡＣＫ対応の通信機能を有している場合には、廃棄パケットの再送を要求するため、その送信側装置２００に対してＳＡＣＫパケットを送信したが、さらに、ＴＤＡＣＫパケットを送信してもよい。これにより、送信側装置２００から廃棄パケットをより迅速に再送させることができる。【０３０３】
また、上記実施の形態およびその変形例では、受信用バッファメモリ１２０の空き容量をウィンドウサイズとして示すＳＡＣＫパケットを送信したが、ＳＡＣＫパケットにより示されるウィンドウサイズは受信用バッファメモリ１２０の空き容量に依存していなくてもよい。【０３０４】
また、上記実施の形態およびその変形例において、本発明に係る通信装置（受信側装置１００）は、図１８に示すように、例えば携帯電話として構成され、送信側装置２００は、例えばパーソナルコンピュータやサーバとして構成されてもよい。
【産業上の利用可能性】
【０３０５】
本発明の通信装置は、環境的な制約を受けることなく効率的にデータを転送することができるという効果を奏し、例えばパーソナルコンピュータや携帯電話、ネット家電など、ＴＣＰに基づく受信処理を行うあらゆる通信装置に適用可能である。
【図１】
2008023656.tif 000003
【図２】
2008023656.tif 000004
【図３】
2008023656.tif 000005
【図４】
2008023656.tif 000006
【図５】
2008023656.tif 000007
【図６】
2008023656.tif 000008
【図７】
2008023656.tif 000009
【図８】
2008023656.tif 000010
【図９】
2008023656.tif 000011
【図１０】
2008023656.tif 000012
【図１１】
2008023656.tif 000013
【図１２】
2008023656.tif 000014
【図１３】
2008023656.tif 000015
【図１４】
2008023656.tif 000016
【図１５】
2008023656.tif 000017
【図１６】
2008023656.tif 000018
【図１７】
2008023656.tif 000019
【図１８】
2008023656.tif 000020
【手続補正書】
【提出日】平成20年11月19日(2008.11.19)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
ネットワークを介して接続された通信相手装置に対して、データ量をウィンドウサイズとして通知することにより、前記通信相手装置から送信された前記ウィンドウサイズ分のデータを受信する通信装置であって、
前記通信相手装置から送信されたデータを記憶するための記憶手段と、
前記記憶手段の容量よりも大きい前記ウィンドウサイズを前記通信相手装置に通知するサイズ通知手段と、
前記サイズ通知手段により通知された前記ウィンドウサイズに応じて前記通信相手装置から送信されたデータを受信して前記記憶手段に格納する受信手段と、
前記記憶手段に格納されたデータを取り出して処理する処理手段と
を備えることを特徴とする通信装置。
【請求項２】
前記通信相手装置は、前記サイズ通知手段により通知されたウィンドウサイズ分のデータを複数のデータパケットとして順次送信し、
前記受信手段は、前記複数のデータパケットを順次受信して前記記憶手段に格納し、
前記通信装置は、さらに、
前記記憶手段に格納されたデータパケットを廃棄することにより、前記記憶手段の空き容量を確保する廃棄手段と、
前記廃棄手段により廃棄されたデータパケットの再送を前記通信相手装置に対して要求する再送要求手段とを備える
ことを特徴とする請求項１記載の通信装置。
【請求項３】
前記再送要求手段は、さらに、前記受信手段によって受信されたが前記記憶手段に格納されなかったデータパケットの再送を前記通信相手装置に対して要求する
ことを特徴とする請求項２記載の通信装置。
【請求項４】
前記処理手段は、前記記録手段に格納されているデータパケットを予め定められた順序で取り出し、
前記廃棄手段は、
前記処理手段による前記順序に従った、前記記憶手段からのデータパケットの取り出しが滞り、前記記憶手段に新たなデータパケットを格納する容量がないときに、前記記憶手段に記憶されているデータパケットを廃棄する
ことを特徴とする請求項２記載の通信装置。
【請求項５】
前記再送要求手段は、
前記廃棄手段により廃棄されたデータパケットを示す否定応答パケットを、前記データパケットを前記通信相手装置から再送させるのに必要な数だけ、前記通信相手装置に送信することにより、前記データパケットの再送を前記通信相手装置に要求する
ことを特徴とする請求項４記載の通信装置。
【請求項６】
前記廃棄手段は、前記サイズ通知手段により通知されたウィンドウサイズに応じて前記通信相手装置から順次送信されるデータパケットのうち、最後に送信されるデータパケットが最終パケットとして前記記憶手段に格納されるように、前記最終パケットを除く他のデータパケットを前記記憶手段から廃棄する
ことを特徴とする請求項４記載の通信装置。
【請求項７】
前記再送要求手段は、
前記記憶手段に格納されている前記最終パケットと他のデータパケットとを示す肯定応答パケットを前記通信相手装置に送信することにより、前記最終パケットと他のデータパケットの間に送信された複数のデータパケットの一括した再送を前記通信相手装置に要求する
ことを特徴とする請求項６記載の通信装置。
【請求項８】
前記通信装置が複数の通信フローのそれぞれで同時にデータを受信するときには、
前記サイズ通知手段は、各通信フローのウィンドウサイズの合計が前記記憶手段の容量よりも大きくなるように、通信フローごとにウィンドウサイズを設定して通知し、
前記受信手段は、複数の通信フローごとにデータを受信して前記記憶手段に格納する
ことを特徴とする請求項１記載の通信装置。
【請求項９】
前記通信装置は、さらに、
前記各通信フローに対する優先度を決定する優先度決定手段を備え、
前記サイズ通知手段は、通信フローに対して決定された優先度が高いほど、前記通信フローに対して大きなウィンドウサイズを設定する
ことを特徴とする請求項８記載の通信装置。
【請求項１０】
前記優先度決定手段は、前記処理手段において実行されるアプリケーションプログラムに応じて前記優先度を決定する
ことを特徴とする請求項９記載の通信装置。
【請求項１１】
前記優先度決定手段は、動画像の転送を行う通信フローに対して、動画像以外のデータの転送を行う通信フローよりも高い優先度を決定する
ことを特徴とする請求項９記載の通信装置。
【請求項１２】
前記サイズ通知手段は、前記通信フローの数が多いほど小さくなるようなウィンドウサイズを設定する
ことを特徴とする請求項８記載の通信装置。
【請求項１３】
前記サイズ通知手段は、前記通信フローで使用される伝送路の伝搬遅延時間に応じて前記通信フローに対するウィンドウサイズを設定する
ことを特徴とする請求項８記載の通信装置。
【請求項１４】
前記サイズ通知手段は、前記通信フローで使用される伝送路の伝搬遅延時間が長いほど大きなウィンドウサイズを前記通信フローに対して設定する
ことを特徴とする請求項１３記載の通信装置。
【請求項１５】
前記サイズ通知手段は、前記通信フローで使用される伝送路の伝搬遅延時間が短いほど大きなウィンドウサイズを前記通信フローに対して設定する
ことを特徴とする請求項１３記載の通信装置。
【請求項１６】
前記サイズ通知手段は、前記通信フローにおける伝送帯域が広いほど大きいウィンドウサイズを前記通信フローに対して設定する
ことを特徴とする請求項８記載の通信装置。
【請求項１７】
前記サイズ通知手段は、前記記憶手段の空き容量が閾値以下になると、前記各通信フローに対して設定されているウィンドウサイズを小さくする
ことを特徴とする請求項８記載の通信装置。
【請求項１８】
前記サイズ通知手段は、前記記憶手段の全体の容量に応じて前記閾値を決定する
ことを特徴とする請求項１７記載の通信装置。
【請求項１９】
ネットワークを介して接続された通信相手装置に対して、データ量をウィンドウサイズとして通知することにより、前記通信相手装置から送信された前記ウィンドウサイズ分のデータを受信する通信方法であって、
前記通信相手装置から送信されたデータを記憶するための記憶手段の容量よりも大きい前記ウィンドウサイズを前記通信相手装置に通知するサイズ通知ステップと、
前記サイズ通知ステップで通知された前記ウィンドウサイズに応じて前記通信相手装置から送信されたデータを受信して前記記憶手段に格納する受信ステップと、
前記記憶手段に格納されたデータを取り出して処理する処理ステップと
を含むことを特徴とする通信方法。
【請求項２０】
ネットワークを介して接続された通信相手装置に対して、データ量をウィンドウサイズとして通知することにより、前記通信相手装置から送信された前記ウィンドウサイズ分のデータを受信するためのプログラムであって、
前記通信相手装置から送信されたデータを記憶するための記憶手段の容量よりも大きい前記ウィンドウサイズを前記通信相手装置に通知するサイズ通知ステップと、
前記サイズ通知ステップで通知された前記ウィンドウサイズに応じて前記通信相手装置から送信されたデータを受信して前記記憶手段に格納する受信ステップと、
前記記憶手段に格納されたデータを取り出して処理する処理ステップと
をコンピュータに実行させることを特徴とするプログラム。
【手続補正２】
【補正対象書類名】明細書
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信装置に関し、特に、ＴＣＰ／ＩＰ（Transmission Control Protocol/Internet Protocol）を用いてデータを受信する通信装置に関する。
【背景技術】
【０００２】
ＴＣＰ／ＩＰネットワークにおけるデータ転送において、データはパケットと呼ばれる単位で送受信される。
【０００３】
送信側装置はパケットを受信側装置に送信する。受信側装置は、送信側装置から送信されたパケットを受け取ると、肯定応答パケット（Acknowledgement Packet：以下ＡＣＫパケットという）を送信側装置に送信する。送信側装置は、受信側装置から送信されたＡＣＫパケットを受け取ることにより、送信側装置によって送信されたパケットが受信側装置に受信されたことを確認する。
【０００４】
送信側装置がＡＣＫパケットを得ることなしに受信側装置に送り続けることが可能なデータ量は、ウィンドウサイズによって制限されている。このウィンドウサイズは、一般的には、受信側装置が受信したデータを保持できる最大量を上限（ＲＷＩＮ）とし、ネットワークの輻輳状態などに応じて増減される。理想的な状況では、ネットワークの輻輳がなく、ウィンドウサイズはＲＷＩＮの値で安定している状態となる。
【０００５】
したがって、送信側装置がネットワークを介してデータを受信装置に送信する場合には、送信側装置がウィンドウサイズ分のデータを送信してから、受信側装置からＡＣＫパケットを受け取るまでの時間（Round Trip Time：以下ＲＴＴという）だけ、送信側装置による送信処理はブロックされる。
【０００６】
ここで、送信側装置が転送遅延の大きなネットワークを介してデータを受信側装置に送信する場合には、ＲＴＴが長くなるために、効率的なデータ転送（高速なデータ転送）が行えないという問題がある。
【０００７】
特に、家庭用電気製品（冷蔵庫、電子レンジ等）にネットワーク接続機能を備えた「ネット家電」と呼ばれる装置が受信側装置として用いられる場合には、この問題が顕著になる。つまり、ネット家電の通信用メモリ（受信用バッファメモリ）は一般的に小さく、その通信用メモリの空き容量がＲＷＩＮに設定されるため、上述のような問題が顕著になる。
【０００８】
従来、この問題を解決するための送信側装置が提案されている（例えば、特許文献１参照）。この特許文献１の送信側装置は、ＴＣＰ／ＩＰ制御において、ネットワークの遅延時間を仮想ウィンドウサイズに変換し、上述のウィンドウサイズにその仮想ウィンドウサイズを加算する。そして、送信側装置は、その加算結果であるサイズを新たなウィンドウサイズとして設定し、その新たなウィンドウサイズに従ってデータの送信を行う。これにより、効率的なデータ転送が実現される。
【０００９】
図１は、上記特許文献１の送信側装置の構成を示す構成図である。
【００１０】
上記特許文献１の送信側装置９２０は、ネットワークを介して受信側装置９１０に接続されている。
【００１１】
また、送信側装置９２０は、例えばアプリケーションプログラムなどを実行する中央制御部９２１と、そのプログラムの実行に必要なデータが格納されるメインメモリ９２２と、ＴＣＰ／ＩＰに従った通信を行う通信制御部９２３とを備えている。
【００１２】
通信制御部９２３は、受信側装置９１０に送信するデータを格納するための送信用バッファメモリ９２５と、上述の仮想ウィンドウサイズの加算を行う仮想バッファ追加部９２６と、送信用バッファメモリ９２５に格納されているデータを受信側装置９１０に送信する通信プロトコル処理部９２４とを備えている。
【００１３】
通信プロトコル処理部９２４は、受信側装置９１０からウィンドウサイズを通知されると、そのウィンドウサイズを仮想バッファ追加部９２６に知らせる。
【００１４】
仮想バッファ追加部９２６は、その知らされたウィンドウサイズが小さければ、そのウィンドウサイズに仮想ウィンドウサイズを加算することにより、そのウィンドウサイズを更新する。
【００１５】
通信プロトコル処理部９２４は、仮想バッファ追加部９２６で更新されたウィンドウサイズ分のデータを、送信用バッファメモリ９２５から取り出して受信側装置９１０に送信する。
【００１６】
これにより、送信側装置９２０は、受信側装置９１０から通知されたウィンドウサイズが小さくても、そのウィンドウサイズを大きくして、ＲＴＴ内においてより多くのデータを受信側装置９１０に送信しようとする。
【００１７】
一方、上記問題を解決するための受信側装置も提案されている（例えば、特許文献２参照）。この特許文献２の受信側装置は、ＴＣＰ／ＩＰの制御において、受信用バッファメモリの不足分をメインメモリから補い、その不足分が補われた受信用バッファメモリの容量をウィンドウサイズとして送信側装置に通知する。これにより、効率的なデータ転送が実現される。
【００１８】
図２は、上記特許文献２の受信側装置の構成を示す構成図である。
【００１９】
上記特許文献２の受信側装置９６０は、ネットワークを介して送信側装置９７０に接続されている。
【００２０】
また、受信側装置９６０は、例えばアプリケーションプログラムなどを実行する中央制御部９６２と、そのプログラムの実行に必要なデータが格納されるメインメモリ９６３と、ＴＣＰ／ＩＰに従った通信を行う通信制御部９６５と、中央制御部９６２に対してモードの切り替えを指示するモード制御部９６１とを備えている。
【００２１】
通信制御部９６５は、送信側装置９７０から送信されて受信したデータを格納するための第１受信用バッファメモリ９６７と、ＡＣＫパケットの送信などを行いながら送信側装置９７０からデータを受信して第１受信用バッファメモリ９６７に格納する通信プロトコル処理部９６６とを備えている。
【００２２】
モード制御部９６１は、第１受信用バッファメモリ９６７の空き容量が小さい場合、メインメモリ９６３の一部の領域を第２受信用バッファメモリ９７４として確保するように中央制御部９６２に指示する。
【００２３】
中央制御部９６２は、このような指示を受けると、第２受信用バッファメモリ９７４を確保し、通信プロトコル処理部９６６にその指示内容を通知する。その結果、通信プロトコル処理部９６６は、第１受信用バッファメモリ９６７の空き容量に第２受信用バッファメモリ９７４のサイズを加算し、その加算結果をウィンドウサイズとして送信側装置９７０に通知する。
【００２４】
これにより、受信側装置９６０は、送信側装置９７０から送信されるデータを受信するための受信用バッファメモリのサイズを大きくすることができ、ＲＴＴ内においてより多くのデータを送信側装置９７０から送信させて受信することができる。
【特許文献１】特開平９−２４７２０９号公報
【特許文献２】特開２００５−１０９７６５号公報
【発明の開示】
【発明が解決しようとする課題】
【００２５】
しかしながら、上記特許文献１および特許文献２の受信側装置（通信装置）では、効率的なデータ転送を行うための環境的な制約があるという問題がある。
【００２６】
つまり、上記特許文献１の受信側装置９１０では、効率的なデータ転送を行うために、送信側装置９２０がウィンドウサイズを大きくするような機能を有していなければならないという制約がある。
【００２７】
また、上記特許文献２の受信側装置９６０では、効率的なデータ転送を行うために、受信用バッファメモリとして割り当て可能な領域がメインメモリ９６３になければならないという制約がある。つまり、受信側装置において受信用バッファメモリが十分確保されていない環境では効率的なデータ転送が行えないのである。
【００２８】
そこで、本発明は、かかる問題に鑑みてなされたものであって、環境的な制約を受けることなく効率的なデータ転送を可能とする通信装置（受信側装置）を提供することを目的とする。
【課題を解決するための手段】
【００２９】
上記目的を達成するために、本発明に係る通信装置は、ネットワークを介して接続された通信相手装置に対して、データ量をウィンドウサイズとして通知することにより、前記通信相手装置から送信された前記ウィンドウサイズ分のデータを受信する通信装置であって、前記通信相手装置から送信されたデータを記憶するための記憶手段と、前記記憶手段の容量よりも大きい前記ウィンドウサイズを前記通信相手装置に通知するサイズ通知手段と、前記サイズ通知手段により通知された前記ウィンドウサイズに応じて前記通信相手装置から送信されたデータを受信して前記記憶手段に格納する受信手段と、前記記憶手段に格納されたデータを取り出して処理する処理手段とを備えることを特徴とする。
【００３０】
これにより、記憶手段の容量よりも大きなウィンドウサイズが例えばＡＣＫパケットにより通信相手装置（送信側装置）に通知されるため、記憶手段（受信用バッファメモリ）の容量が少なくても、ＲＴＴ内において通信相手装置から多くのデータを送信させることができ、その結果、記憶容量という環境的な制約を受けることなく効率的なデータ転送を行うことができる。つまり、上記特許文献２の受信側装置９６０では、メインメモリ９６３の一部を受信用バッファメモリの一部に割り当てることにより、その受信用バッファメモリの容量を増やし、その容量をウィンドウサイズとして通知したが、本発明では、このような割り当てができなくても、効率的なデータ転送を行うことができる。
【００３１】
言い換えれば、本発明に係る通信装置では、ＴＣＰコネクション毎の専用の記憶手段の容量以上のメモリを確保できないために、ＲＴＴに見合うＲＷＩＮと同等のメモリ領域を確保することができない環境であっても、大きなウィンドウサイズを通知する。その結果、本発明に係る通信装置では、ＲＴＴに見合うメモリ領域が確保できない環境にあっても、処理手段による処理が滞らない限り効率的なデータ転送を行うことができる。
【００３２】
また、前記通信相手装置は、前記サイズ通知手段により通知されたウィンドウサイズ分のデータを複数のデータパケットとして順次送信し、前記受信手段は、前記複数のデータパケットを順次受信して前記記憶手段に格納し、前記通信装置は、さらに、前記記憶手段に格納されたデータパケットを廃棄することにより、前記記憶手段の空き容量を確保する廃棄手段と、前記廃棄手段により廃棄されたデータパケットの再送を前記通信相手装置に対して要求する再送要求手段とを備えることを特徴としてもよい。ここで、前記処理手段は、前記記録手段に格納されているデータパケットを予め定められた順序で取り出し、前記廃棄手段は、前記処理手段による前記順序に従った、前記記憶手段からのデータパケットの取り出しが滞り、前記記憶手段に新たなデータパケットを格納する容量がないときに、前記記憶手段に記憶されているデータパケットを廃棄する。
【００３３】
例えば、通信相手装置に通知されるウィンドウサイズが大きければ大きいほど、パケットロスが発生する確率が増す。パケットロスが発生すると、消失したデータパケット（ロスパケット）が送信された後に送信されて記憶手段に順次格納されたデータパケットを処理手段によって取り出すことができず、記憶手段の空き容量がなくなってしまうことがある。つまり、受信処理が滞ってしまうことがある。このような場合が生じると、ロスパケットが通信相手装置から再送されても、記憶手段に空き容量がないため、その再送されたロスパケットは記憶手段に格納されず、受信処理の滞った状態が継続し、通信相手装置からデータを受信するデータ転送処理が停止してしまう可能性がある。
【００３４】
そこで本発明では、記憶手段に格納されているデータパケットが廃棄されて空き容量が確保されるため、上述のように再送されたロスパケットを記憶手段に格納して、その記憶手段に格納されている多くのデータパケットを処理手段に受け渡すことができ、データ転送処理の停止を避けることができる。さらに、廃棄されたデータパケットの再送が要求されるため、その廃棄されたデータパケットを再び受信して記憶手段に格納することができる。
【００３５】
その結果、受信処理が滞ったとしても、データ転送効率を著しく劣化させることを避けることができる。
【００３６】
また、前記再送要求手段は、前記廃棄手段により廃棄されたデータパケットを示す否定応答パケットを、前記データパケットを前記通信相手装置から再送させるのに必要な数だけ、前記通信相手装置に送信することにより、前記データパケットの再送を前記通信相手装置に要求することを特徴としてもよい。
【００３７】
例えば、通信相手装置がTriple Duplicate ＡＣＫ対応の通信機能を有している場合には、Triple Duplicate ＡＣＫパケットが否定応答パケットとして通信相手装置に送信されるため、その通信相手装置に対して、廃棄されたデータパケットを迅速に再送させることができる。その結果、パケットロスが発生して受信処理が滞っても、通知したウィンドウサイズ分のデータパケットを迅速に受信することができる。
【００３８】
また、前記廃棄手段は、前記サイズ通知手段により通知されたウィンドウサイズに応じて前記通信相手装置から順次送信されるデータパケットのうち、最後に送信されるデータパケットが最終パケットとして前記記憶手段に格納されるように、前記最終パケットを除く他のデータパケットを前記記憶手段から廃棄することを特徴としてもよい。ここで、前記再送要求手段は、前記記憶手段に格納されている前記最終パケットと他のデータパケットとを示す肯定応答パケットを前記通信相手装置に送信することにより、前記最終パケットと他のデータパケットの間に送信された複数のデータパケットの一括した再送を前記通信相手装置に要求する。
【００３９】
例えば、通信相手装置がSelective ＡＣＫ対応の通信機能を有している場合には、Selective ＡＣＫパケットが肯定応答パケットとして通信相手装置に送信されるため、その通信相手装置に対して、廃棄された複数のデータパケットを迅速に一括して再送させることができる。その結果、パケットロスが発生して受信処理が滞っても、通知したウィンドウサイズ分のデータパケットをより迅速に受信することができる。さらに、最終パケットが残るように他のデータパケットが廃棄されることによって、Selective ＡＣＫパケットにより再送要求されるべきデータパケットを容易に特定することができる。
【００４０】
なお、本発明は、このような通信装置として実現することができるだけでなく、その通信装置が通信する方法や、その通信装置が通信するためのプログラム、そのプログラムを格納する記憶媒体、集積回路としても実現することができる。
【発明の効果】
【００４１】
本発明の通信装置は、環境的な制約を受けることなく効率的にデータを転送することができるという作用効果を奏する。つまり、本発明の通信装置では、ＴＣＰコネクション毎の専用の受信用バッファメモリの容量以上のメモリを確保できないために、ＲＴＴに見合うＲＷＩＮと同等のメモリ領域が確保できない環境であっても、大きなウィンドウサイズを用いて通信を行うことができ、効率的なデータ転送が可能となる。また、パケット廃棄と再送要求を繰り返すことにより、通信装置（受信側装置）において受信用バッファメモリ内のパケットの処理が一時的に滞った場合でも、効率を大きく落とすことなくデータ転送を続けることができる。
【発明を実施するための最良の形態】
【００４２】
以下、本発明の実施の形態における受信側装置（通信装置）について、図面を参照しながら説明する。
【００４３】
ここで、説明を簡略化するために、本実施の形態では、１パケット内に格納されるデータ長（ＬＥＮ）を１ＫＢｙｔｅとする。さらに、１つのシーケンス番号（ＳＥＱ）が割り当てられたデータのサイズも１ＫＢｙｔｅ（１パケット）とし、ウィンドウサイズ（ＲＷＩＮ）の単位も１ＫＢｙｔｅとする。
【００４４】
図３は、本発明の実施の形態における受信側装置の構成の一例を示す図である。
【００４５】
本実施の形態における受信側装置（通信装置）１００は、ネットワーク３００を介して送信側装置２００に接続され、その送信側装置２００とＴＣＰ／ＩＰに従った通信を行う。
【００４６】
ここで、受信側装置１００および送信側装置２００は、ネットワーク３００と有線または無線で接続する通信装置であって、例えばＥｔｈｅｒｎｅｔ（登録商標）インタフェースを備えたパーソナルコンピュータや、ネットワーク通信が可能な家電装置などである。ネットワーク３００は、有線または無線を含む通信ネットワークであり、インターネットなどの公衆の通信ネットワークなどが例として挙げられる。なお、受信側装置１００および送信側装置２００は、電力線を通信回線として使用して通信してもよい。
【００４７】
この受信側装置１００は、通信制御部１１０と、メインメモリ１５０と、中央制御部１４０とを備え、送信側装置２００から送信されるデータを受信する。
【００４８】
中央制御部１４０は、通信制御部１１０およびメインメモリ１５０を制御し、例えば、送信側装置２００から送信されたデータを用いてアプリケーションプログラムなどを実行する。なお、本実施の形態では、この中央制御部１４０は、後述する通信制御部１１０の受信用バッファメモリ１２０に格納されたデータを取り出して処理する処理手段として構成されている。
【００４９】
メインメモリ１５０は、中央制御部１４０における処理において必要なデータを記録するための領域を有する。
【００５０】
通信制御部１１０は、送信側装置２００からデータを送信させてそのデータを受信する通信プロトコル処理部１３０と、通信プロトコル処理部１３０によって受信されたデータを格納するための受信用バッファメモリ１２０とを備えている。
【００５１】
通信プロトコル処理部１３０は、送受信制御部１３１と、ＡＣＫ生成部１３２と、ウィンドウサイズ設定部１３３と、パケット廃棄部１３４と、再送要求部１３５とを備えている。
【００５２】
送受信制御部１３１は、送信側装置２００から送信されたパケット単位のデータ（以下、データパケットという）を受信して受信用バッファメモリ１２０に格納する。また、送受信制御部１３１は、例えば、送信側装置２００からデータパケットを受信して受信用バッファメモリ１２０に格納したときには、ＡＣＫ生成部１３２にＡＣＫパケットの生成を促し、生成されたＡＣＫパケットを送信側装置２００に送信する。
【００５３】
また、送受信制御部１３１は、ＡＣＫパケットに応じて送信側装置２００から送信されて受信したデータパケットのシーケンス番号を監視することにより、パケットロスの発生を検知する。例えば、送受信制御部１３１は、ＡＣＫパケットを送信し、そのＡＣＫパケットに応じて送信側装置２００から順次送信されて受信したデータパケットのシーケンス番号に欠番があるか否かを判別する。そして、欠番があるときには、送受信制御部１３１は、その欠番に対応するデータパケットがネットワーク３００で消失して受信されなかったと判断し、パケットロスの発生を検知する。なお、上述のように消失したデータパケットを、以下、ロスパケットという。
【００５４】
また、送受信制御部１３１は、パケットロスの発生を検知したときには、その発生をウィンドウサイズ設定部１３３に通知する。さらに、送受信制御部１３１は、パケットロス発生後に上述のＡＣＫパケットに対応する全てのデータパケットが受信されたときには、そのパケットロスに対する復帰処理が完了したと判断して、その復帰処理完了をウィンドウサイズ設定部１３３に通知する。
【００５５】
ＡＣＫ生成部１３２は、ＡＣＫ番号と、ウィンドウサイズ設定部１３３によって設定されたウィンドウサイズ（ＲＷＩＮ）とを示すＡＣＫパケットを生成して送受信制御部１３１に出力する。
【００５６】
ここで、ＡＣＫ生成部１３２は、再送要求部１３５によって再送が要求されたとき（再送要求時）に、ＡＣＫパケットを生成して送受信制御部１３１から送信側装置２００に送信させる。さらに、ＡＣＫ生成部１３２は、再送要求時以外にも、送受信制御部１３１でデータパケットが受信されて受信用バッファメモリ１２０に格納されたときには（受信応答時）、ＡＣＫパケットを生成して送受信制御部１３１から送信側装置２００に送信させる。
【００５７】
ＡＣＫ生成部１３２は、受信応答時には、通常、そのデータパケットのシーケンス番号の次のシーケンス番号と同一のＡＣＫ番号を示すＡＣＫパケットを肯定応答パケットとして生成する。しかし、ＡＣＫ生成部１３２は、送受信制御部１３１によってパケットロスの発生が検知されているときには、その消失したデータパケット（ロスパケット）のシーケンス番号と同一のＡＣＫ番号を示すＡＣＫパケットを否定応答パケットとして生成する。
【００５８】
また、ＡＣＫ生成部１３２は、再送要求時には、再送要求部１３５によって指示されたＡＣＫ番号のＡＣＫパケットを生成する。
【００５９】
つまり、ＡＣＫ生成部１３２は、送信側装置２００がTriple Duplicate ＡＣＫ（以下、ＴＤＡＣＫという）対応の通信機能を有している場合には、同一のＡＣＫ番号を示す３つのＡＣＫパケット（否定応答パケット）を生成する。なお、上記３つのＡＣＫパケットを、以下、Triple Duplicate ＡＣＫパケットまたはＴＤＡＣＫパケットという。また、ＡＣＫ生成部１３２は、送信側装置２００がSelective ＡＣＫ（以下：ＳＡＣＫという）対応の通信機能を有している場合には、受信用バッファメモリ１２０に格納されている複数のデータパケットのシーケンス番号と同一の複数のＡＣＫ番号を含むＡＣＫパケット（以下、Selective ＡＣＫパケットまたはＳＡＣＫパケットという）を肯定応答パケットとして生成する。
【００６０】
なお、送信側装置２００は、受信応答時のＡＣＫパケットを受信すると、ＴＣＰ／ＩＰに従って、そのＡＣＫパケットの示すウィンドウサイズ分のデータパケットを、そのＡＣＫパケットの受信以後さらにＡＣＫパケットを受信することなく送信する。また、このとき、送信側装置２００は、受信したＡＣＫパケットの示すＡＣＫ番号と同一のシーケンス番号が割り当てられたデータパケットと、そのシーケンス番号以降の連続するシーケンス番号が割り当てられたデータパケットとを送信する。
【００６１】
また、送信側装置２００は、ＴＤＡＣＫ対応の通信機能を有している場合には、ＴＤＡＣＫパケット（否定応答パケット）を受信すると、そのＴＤＡＣＫパケットの示すＡＣＫ番号と同一のシーケンス番号が割り当てられたデータパケットを既に送信していても、そのデータパケットを再送（高速再送）する。
【００６２】
また、送信側装置２００は、ＳＡＣＫ対応の通信機能を有している場合には、ＳＡＣＫパケットを受信すると、そのＳＡＣＫパケットにより示される複数のＡＣＫ番号により、受信用バッファメモリ１２０に格納されている複数のデータパケットのシーケンス番号を特定する。つまり、送信側装置２００は、受信側装置１００に送信したにも関わらず、受信用バッファメモリ１２０に格納されていない１つまたは複数のデータパケットのシーケンス番号を特定する。そして、送信側装置２００は、受信用バッファメモリ１２０に格納されていないそれらのデータパケットを一括して再送（高速再送）する。
【００６３】
ウィンドウサイズ設定部１３３は、通常、受信用バッファメモリ１２０の容量に依存せず、パケット処理に一時的な滞りが発生した場合に受信しきれないデータ量をウィンドウサイズとして設定する。
【００６４】
つまり、本実施の形態におけるウィンドウサイズ設定部１３３は、受信用バッファメモリ１２０の記憶容量（空き容量）よりも大きいサイズをウィンドウサイズとして設定する。以下、このような設定を高速転送設定という。なお、このウィンドウサイズは、受信側装置１００が受信したいデータの転送レートにあわせて設定される。例えば、ウィンドウサイズ設定部１３３は、ＲＴＴの間に、受信用バッファメモリ１２０から中央制御部１４０に移動させることが可能なデータのサイズをウィンドウサイズとして設定する。
【００６５】
一方、ウィンドウサイズ設定部１３３は、送受信制御部１３１からパケットロスの発生の通知を受けたときには、そのときから復帰処理の完了の通知を受け取るまで、受信用バッファメモリ１２０の空き容量をウィンドウサイズとして設定する。つまり、ウィンドウサイズ設定部１３３は、パケット廃棄部１３４を介して受信用バッファメモリ１２０の空き容量を監視して、その空き容量をウィンドウサイズとして設定する。以下、このような設定を通常転送設定という。
【００６６】
ここで、パケットロスに起因して、受信用バッファメモリ１２０に空き容量がなくなることがある。この場合には、送受信制御部１３１は、送信側装置２００から送信されたデータパケットを受信しても、既に格納されているデータパケットが廃棄されない限り、その受信したデータパケットを受信用バッファメモリ１２０に格納することができない。
【００６７】
このように、既に格納されているデータパケットが廃棄されない限り、新たなデータパケットを格納することができない受信用バッファメモリ１２０の状態を、以下、停滞状態という。
【００６８】
パケット廃棄部１３４は、受信用バッファメモリ１２０が上述のような停滞状態になると、その状態を解消するため、受信用バッファメモリ１２０に既に格納されているデータパケットを廃棄する。つまり、パケット廃棄部１３４は、送受信制御部１３１によって受信された最新のデータパケットが受信用バッファメモリ１２０に格納されるように、例えば、受信用バッファメモリ１２０に既に格納されているシーケンス番号の最も大きいデータパケットを廃棄する。その結果、ロスパケットが再送されたときには、そのパケットが受信用バッファメモリ１２０に格納される。以下、このように廃棄されたデータパケットを廃棄パケットという。
【００６９】
再送要求部１３５は、廃棄パケットの再送を送信側装置２００に対して要求する。すなわち、再送要求部１３５は、廃棄パケットを送信側装置２００から送信させるために必要なＡＣＫパケットの生成をＡＣＫ生成部１３２に促す。
【００７０】
例えば、再送要求部１３５は、送信側装置２００がＴＤＡＣＫ対応の通信機能を有している場合には、廃棄パケットのシーケンス番号をＡＣＫ番号として示すＴＤＡＣＫパケットを生成するようにＡＣＫ生成部１３２に指示する。
【００７１】
また、再送要求部１３５は、送信側装置２００がＳＡＣＫ対応の通信機能を有している場合には、受信用バッファメモリ１２０に格納されている複数のデータパケットのシーケンス番号をＡＣＫ生成部１３２に通知し、それらのシーケンス番号をそれぞれＡＣＫ番号として示すＳＡＣＫパケットを生成するようにＡＣＫ生成部１３２に指示する。なお、シーケンス番号の連続する複数のデータパケットが受信用バッファメモリ１２０に格納されていれば、再送要求部１３５は、その連続するシーケンス番号のうち先頭と最後のシーケンス番号のみをＡＣＫ生成部１３２に通知する。
【００７２】
また、再送要求部１３５は、ＡＣＫ生成部１３２にＡＣＫパケットの生成を指示するときには、ウィンドウサイズ設定部１３３にウィンドウサイズの設定を促す。
【００７３】
なお、本実施の形態では、受信用バッファメモリ１２０が、送信側装置２００（通信相手装置）から送信されたデータを記憶するための記憶手段として構成されている。また、ウィンドウサイズ設定部１３３、ＡＣＫ生成部１３２および送受信制御部１３１がサイズ通知手段として構成され、送受信制御部１３１が受信手段として構成されている。さらに、パケット廃棄部１３４が廃棄手段として構成され、再送要求部１３５が再送要求手段として構成されている。
【００７４】
図４は、受信側装置１００と送信側装置２００との通信を示すシーケンス図である。
【００７５】
まず、受信側装置１００と送信側装置２００とは、例えば、Three Way Handshakeなどにより、ＴＣＰ接続時のコネクションを設立する。
【００７６】
そして、受信側装置１００のウィンドウサイズ設定部１３３は、上述の高速転送設定を行う。すなわち、ウィンドウサイズ設定部１３３は、受信用バッファメモリ１２０の容量が４ＫＢしかないにもかかわらず、例えば８ＫＢのウィンドウサイズ（ＲＷＩＮ＝８）を設定する。その結果、ＡＣＫ生成部１３２は、ＲＷＩＮ＝８を示すＡＣＫパケットＰ１２を生成する。なお、ここでは、ＡＣＫ生成部１３２は、ＡＣＫ番号が０（ＡＣＫ＝０）を示すＡＣＫパケットＰ１２を生成する。
【００７７】
このようにＡＣＫパケットＰ１２が生成されると、受信側装置１００の送受信制御部１３１は、そのＡＣＫパケットＰ１２を肯定応答パケットして送信側装置２００に送信する。つまり、ＡＣＫパケットＰ１２によって、８ＫＢのウィンドウサイズが送信側装置２００に通知される。
【００７８】
送信側装置２００は、ＡＣＫパケットＰ１２を受信すると、そのＡＣＫパケットＰ１２の示すウィンドウサイズ（ＲＷＩＮ＝８）分のデータパケットＰ１３，Ｐ１４，…，Ｐ２０を送信する。ここで、送信側装置２００は、そのＡＣＫパケットＰ１２の示すＡＣＫ番号（ＡＣＫ＝０）と同一のシーケンス番号（ＳＥＱ＝０）が割り当てられたデータパケットＰ１３から順に、各データパケットＰ１３，Ｐ１４，…，Ｐ２０を送信する。
【００７９】
受信側装置１００の送受信制御部１３１は、送信側装置２００からデータパケットＰ１３，Ｐ１４，…，Ｐ２０を順次受信すると、それらのデータパケットを順に受信用バッファメモリ１２０に格納する。
【００８０】
受信側装置１００の中央制御部１４０は、受信用バッファメモリ１２０に格納されているデータパケットを順次取り出し、そのデータパケットを用いた処理を実行する。
【００８１】
ここで、送信側装置２００から送信されるデータパケットＰ１３，Ｐ１４，…，Ｐ２０の合計サイズはＡＣＫパケットＰ１２の示すウィンドウサイズ（８ＫＢ）であるのに対して、受信用バッファメモリ１２０の容量は４ＫＢしかない。しかし、上述のように、中央制御部１４０が、受信用バッファメモリ１２０に格納されたデータパケットを順次取り出してアプリケーションプログラムに渡していくため、送信された全てのデータパケットＰ１３，Ｐ１４，…，Ｐ２０が正常に受信される。
【００８２】
さらに、受信側装置１００の送受信制御部１３１は、ＡＣＫパケットＰ１２のようなＲＷＩＮ＝８を示すＡＣＫパケットの送信を繰り返し行い、ＲＴＴごとに、８ＫＢ分のデータパケットを送信側装置２００から受信する。
【００８３】
このように、本実施の形態では、受信用バッファメモリ１２０の容量ではなく、その容量よりも大きな仮想的なウィンドウサイズに応じた速度でデータ転送を行うことができ、通信速度の向上が期待できる。例えば、上記のように、実際の受信用バッファメモリ１２０の容量（４ＫＢ）の２倍（８ＫＢ）のウィンドウサイズが送信側装置２００に通知された場合には、パケットロスが発生しない環境下では２倍の通信速度によるデータ転送が実現される。
【００８４】
なお、本実施の形態における高速転送設定では、ウィンドウサイズを受信用バッファメモリ１２０の容量の２倍に設定したが、任意のサイズに設定してもよく、好ましくは、パケットロスが発生しない限りの最大サイズに設定する。
【００８５】
ここで、ウィンドウサイズ設定部１３３が受信用バッファメモリ１２０の容量よりも大きいウィンドウサイズを設定しただけでは、パケットロスが発生したときに、受信側装置１００と送信側装置２００との間のデータ転送が停止してしまうことがある。
【００８６】
図５は、パケットロスによりデータ転送が停止してしまう様子を示すシーケンス図である。
【００８７】
例えば、ＡＣＫパケットＰ１２に応じて送信側装置２００から送信されたデータパケットＰ１３，Ｐ１４，…，Ｐ２０のうち、データパケットＰ１３がネットワーク３００において消失する。つまり、パケットロスが発生する。
【００８８】
このとき、データパケットＰ１４，Ｐ１５，Ｐ１６，Ｐ１７が順に受信側装置に受信されると、受信側装置の受信用バッファメモリには、それらのデータパケットが順に格納され、受信用バッファメモリの空き容量がなくなる。つまり、受信側装置の受信用バッファメモリは上述の停滞状態となる。
【００８９】
なお、図５では、受信用バッファメモリに格納されるデータパケットを、そのデータパケットに割り当てられたシーケンス番号を用いて示している。
【００９０】
ここで、ＴＣＰでは順序制御が行われているため、受信用バッファメモリから中央制御部（アプリケーションプログラム）への各データパケットの受け渡しは、シーケンス番号の昇順に従って行われる。したがって、上述のようにパケットロスが発生したときには、データパケットＰ１３（ＳＥＱ＝０）が受信用バッファメモリに格納されていないため、データパケットＰ１４，Ｐ１５，Ｐ１６、Ｐ１７（ＳＥＱ＝１，２，３，４）が受信用バッファメモリに格納されても、これらのデータパケットを中央制御部に受け渡すことができない。
【００９１】
その結果、受信用バッファメモリに空き容量がないため、データパケットＰ１８、Ｐ１９，Ｐ２０が受信側装置に順に受信されても、それらのデータパケットは受信用バッファメモリに格納されず破棄されてしまう。
【００９２】
また、上述のように、データパケットＰ１４，Ｐ１５，Ｐ１６，Ｐ１７が順に受信側装置に受信されると、受信側装置からは、その受信ごとに、ＡＣＫ番号が０であること（ＡＣＫ＝０）を示すＡＣＫパケット（否定応答パケット）Ｐ２１，Ｐ２２，Ｐ２３，Ｐ２５が送信側装置２００に送信される。
【００９３】
ここで、送信側装置２００がＴＤＡＣＫ対応の通信機能を有していれば、送信側装置２００は、ＡＣＫ＝０を示す３つのＡＣＫパケットＰ２１，Ｐ２２，Ｐ２３をＴＤＡＣＫパケットとして受け取ると、シーケンス番号０のデータパケットＰ２４をロスパケットとして再送する。
【００９４】
しかし、データパケットＰ２４が再送されたときにも、上述と同様に、受信用バッファメモリに空き容量がないため、そのデータパケットＰ２４は受信用バッファメモリに格納されず破棄される。
【００９５】
さらに、シーケンス番号０のデータパケットＰ２６が再送されても、上述と同様、そのデータパケットＰ２６は受信用バッファメモリに格納されず破棄される。
【００９６】
その結果、送信側装置２００から受信側装置へのデータ転送が停止されてしまう。
【００９７】
そこで、本実施の形態における受信側装置１００は、上述のようなデータ転送の停止を避けるために、停滞状態にある受信用バッファメモリ１２０に格納されているデータパケットを廃棄して、廃棄されたデータパケットの再送を送信側装置２００に要求する。
【００９８】
図６は、パケットロスが発生したときの受信側装置１００とＴＤＡＣＫ対応の送信側装置２００との間で行われる通信の一例を示すシーケンス図である。
【００９９】
まず、受信側装置１００と送信側装置２００とは、例えば、Three Way Handshakeなどにより、ＴＣＰ接続時のコネクションを設立する。このとき、受信側装置１００の送受信制御部１３１は、送信側装置２００の通信機能を特定する。例えば、送受信制御部１３１は、送信側装置２００の通信機能がＴＤＡＣＫに対応していると判断する。その結果、受信側装置１００は、パケットロスが発生したときには送信側装置２００に対してＴＤＡＣＫ対応の再送要求を行う。
【０１００】
具体的には、まず、受信側装置１００のウィンドウサイズ設定部１３３は、上述と同様、高速転送設定を行う。すなわち、ウィンドウサイズ設定部１３３は、受信用バッファメモリ１２０の容量が４ＫＢしかないにもかかわらず、８ＫＢのウィンドウサイズ（ＲＷＩＮ＝８）を設定する。その結果、ＡＣＫ生成部１３２は、ＡＣＫ＝０およびＲＷＩＮ＝８を示すＡＣＫパケットＰ１２を生成する。
【０１０１】
このようにＡＣＫパケットＰ１２が生成されると、受信側装置１００の送受信制御部１３１は、そのＡＣＫパケットＰ１２を肯定応答パケットとして送信側装置２００に送信する。
【０１０２】
送信側装置２００は、ＡＣＫパケットＰ１２を受信すると、上述と同様、そのＡＣＫパケットＰ１２の示すウィンドウサイズ（ＲＷＩＮ＝８）分のデータパケットＰ１３，Ｐ１４，…，Ｐ２０を送信する。
【０１０３】
ここで、ＡＣＫパケットＰ１２に応じて送信側装置２００から送信されたデータパケットＰ１３，Ｐ１４，…，Ｐ２０のうち、データパケットＰ１３がネットワーク３００において消失する。つまり、パケットロスが発生する。
【０１０４】
受信側装置１００の送受信制御部１３１は、データパケットＰ１４（ＳＥＱ＝１）を受信すると、シーケンス番号０のデータパケットを受信していないため、シーケンス番号０のデータパケット（ロスパケット）が消失したこと、すなわちパケットロスが発生したことを検知する。さらに、送受信制御部１３１は、ロスパケットのシーケンス番号０をＡＣＫ生成部１３２に通知する。
【０１０５】
また、送受信制御部１３１は、データパケットＰ１４，Ｐ１５，Ｐ１６，Ｐ１７を順に受信して、受信用バッファメモリ１２０にそれらのデータパケット（ＳＥＱ＝１，２，３，４）を順に格納する。しかし、上述のように、シーケンス番号０のデータパケットＰ１３が受信用バッファメモリ１２０に格納されていないため、データパケットＰ１４，Ｐ１５，Ｐ１６，Ｐ１７を中央制御部１４０に受け渡すことができず、受信用バッファメモリ１２０の空き容量がなくなる。つまり、このとき、受信用バッファメモリ１２０は停滞状態となる。
【０１０６】
そこで、パケット廃棄部１３４は、シーケンス番号４のデータパケットＰ１７を廃棄し、その廃棄パケットのシーケンス番号４を再送要求部１３５に通知する。その結果、停滞状態は一時的に解かれ、受信用バッファメモリ１２０に空き容量ができ、受信用バッファメモリ１２０は、新たなデータパケットを格納し得る状態となる。
【０１０７】
これにより、送受信制御部１３１は、送信側装置２００から送信されて受信したデータパケットＰ１８（ＳＥＱ＝５）を受信用バッファメモリ１２０に格納する。
【０１０８】
データパケットＰ１８（ＳＥＱ＝５）が受信用バッファメモリ１２０に格納されると、受信用バッファメモリ１２０は、データパケットＰ１４，Ｐ１５，Ｐ１６，Ｐ１８（ＳＥＱ＝１，２，３，５）を格納することとなり、再び停滞状態となる。
【０１０９】
そこで、パケット廃棄部１３４は、シーケンス番号５のデータパケットＰ１８を廃棄し、その廃棄パケットのシーケンス番号５を再送要求部１３５に通知する。その結果、停滞状態は一時的に解かれ、受信用バッファメモリ１２０に空き容量ができ、受信用バッファメモリ１２０は、新たなデータパケットを格納し得る状態となる。
【０１１０】
これにより、送受信制御部１３１は、送信側装置２００から送信されて受信したデータパケットＰ１９（ＳＥＱ＝６）を受信用バッファメモリ１２０に格納する。
【０１１１】
このようなデータパケットの格納と廃棄とは、シーケンス番号７のデータパケット（最終パケット）Ｐ２０が受信側装置１００に受信されるまで繰り返される。その結果、受信用バッファメモリ１２０に格納されたデータパケットＰ２０（ＳＥＱ＝７）は削除され、受信用バッファメモリ１２０に空き容量ができ、受信用バッファメモリ１２０は、新たなデータパケットを格納し得る状態となる。
【０１１２】
なお、本実施の形態では、受信用バッファメモリ１２０が停滞状態になる度に、その受信用バッファメモリ１２０に格納されているデータパケットを廃棄したが、最終パケットであるデータパケットＰ２０が受信側装置１００に到達した後にのみデータパケットを廃棄してもよい。
【０１１３】
この場合には、ＳＥＱ＝４を示すデータパケットＰ１７が受信用バッファメモリ１２０に格納されると、その受信用バッファメモリ１２０は停滞状態になるが、上述のようにそのデータパケットＰ１７が廃棄されず、停滞状態が継続する。その結果、ＳＥＱ＝５を示すデータパケットＰ１８が送受信制御部１３１に受信されても、送受信制御部１３１はそのデータパケットＰ１８を受信用バッファメモリ１２０に格納することができずに消失させてしまう。その後も停滞状態が継続しているため、送受信制御部１３１は、ＳＥＱ＝６，７を示すデータパケットＰ１９，２０を順次受信しても、上述と同様、それらを順次消失させてしまう。
【０１１４】
パケット廃棄部１３４は、最終パケットであるデータパケットＰ２０が消失した後に、停滞状態にある受信用バッファメモリ１２０に格納されている、例えばシーケンス番号が最も大きいデータパケットＰ１７（ＳＥＱ＝４）を廃棄する。その結果、受信用バッファメモリ１２０に空き容量ができ、受信用バッファメモリ１２０は、新たなデータパケットを格納し得る状態となる。
【０１１５】
このような場合、再送要求部１３５は、パケット廃棄部１３４によって廃棄されたデータパケットの再送だけでなく、送受信制御部１３１によって受信されたが受信用バッファメモリ１２０に格納されなかったデータパケットの再送も送信側装置２００に要求する。
【０１１６】
また、送受信制御部１３１が上書によりその受信用バッファメモリ１２０に格納されているデータパケットを廃棄してもよい。
【０１１７】
この場合には、ＳＥＱ＝４を示すデータパケットＰ１７が受信用バッファメモリ１２０に格納されると、その受信用バッファメモリ１２０は停滞状態になる。ここで、ＳＥＱ＝５を示すデータパケットＰ１８が送受信制御部１３１に受信されると、送受信制御部１３１は、そのデータパケットＰ１８を受信用バッファメモリ１２０に上書することにより、そのデータパケットＰ１８を受信用バッファメモリ１２０に格納すると同時に、ＳＥＱ＝４を示すデータパケットＰ１７を廃棄する。その後も、送受信制御部１３１は、ＳＥＱ＝６，７を示すデータパケットＰ１９，２０を順次受信すると、上述と同様、それらを受信用バッファメモリ１２０に順次上書し、ＳＥＱ＝５，６を示すデータパケットＰ１８，Ｐ１９を順次廃棄する。
【０１１８】
パケット廃棄部１３４は、停滞状態にある受信用バッファメモリ１２０に格納されている最終パケットのデータパケットＰ２０（ＳＥＱ＝７）だけを廃棄する。その結果、受信用バッファメモリ１２０に空き容量ができ、受信用バッファメモリ１２０は、新たなデータパケットを格納し得る状態となる。
【０１１９】
このような場合、再送要求部１３５は、パケット廃棄部１３４によって廃棄されたデータパケットの再送だけでなく、送受信制御部１３１による上書によって廃棄されたデータパケットの再送も送受信側装置２００に要求する。
【０１２０】
ところで、受信側装置１００は、上述のデータパケットＰ１４，Ｐ１５，Ｐ１６，Ｐ１７を受信すると、それらがシーケンス番号０のデータパケットでないため、その受信ごとに、ＡＣＫ＝０を示す否定応答パケットであるＡＣＫパケットＰ２１，Ｐ２２，Ｐ２３，Ｐ２５を送信側装置２００に送信する。
【０１２１】
すなわち、送受信制御部１３１がデータパケットＰ１４（ＳＥＱ＝１）を受信したときにパケットロスの発生を検知すると、ウィンドウサイズ設定部１３３は、高速転送設定を停止して、通常転送設定を行う。その結果、ウィンドウサイズ設定部１３３は、受信用バッファメモリ１２０の空き容量をウィンドウサイズ（ＲＷＩＮ＝３）として設定する。
【０１２２】
これにより、ＡＣＫ生成部１３２は、送受信制御部１３１でデータパケットＰ１４（ＳＥＱ＝１）が受信されると、ＡＣＫ＝０およびＲＷＩＮ＝３を示すＡＣＫパケット（否定応答パケット）Ｐ２１を生成してそのＡＣＫパケットＰ２１を送受信制御部１３１から送信側装置２００に送信させる。
【０１２３】
さらに、送受信制御部１３１がデータパケットＰ１５（ＳＥＱ＝２）を受信したときにも、ウィンドウサイズ設定部１３３は通常転送設定を行う。すなわち、ウィンドウサイズ設定部１３３は、受信用バッファメモリ１２０の空き容量をウィンドウサイズ（ＲＷＩＮ＝２）として設定する。
【０１２４】
これにより、ＡＣＫ生成部１３２は、送受信制御部１３１でデータパケットＰ１５（ＳＥＱ＝２）が受信されると、ＡＣＫ＝０およびＲＷＩＮ＝２を示すＡＣＫパケット（否定応答パケット）Ｐ２２を生成してそのＡＣＫパケットＰ２２を送受信制御部１３１から送信側装置２００に送信させる。
【０１２５】
このように、受信側装置１００は、データパケットＰ１７を受信するまで、データパケットを受信するごとに、ＡＣＫパケット（ＡＣＫ＝０）を送信側装置２００に送信する。
【０１２６】
一方、送信側装置２００は、ＴＤＡＣＫ対応の通信機能を有しているため、ＡＣＫ＝０を示すＡＣＫパケットＰ２１，Ｐ２２，Ｐ２３を受信すると、シーケンス番号０を示すデータパケットＰ２４（ロスパケット）を受信側装置１００に再送する。
【０１２７】
受信側装置１００の送受信制御部１３１は、再送されたデータパケットＰ２４を受信すると、そのデータパケットＰ２４を受信用バッファメモリ１２０に格納する。
【０１２８】
その結果、受信用バッファメモリ１２０には、それぞれシーケンス番号０，１，２，３を示すデータパケットが格納されるため、これらのデータパケットは中央制御部１４０に速やかに受け渡される。
【０１２９】
ここで、受信側装置１００の再送要求部１３５は、再送されたロスパケットが受信されて受信用バッファメモリ１２０に格納されると、パケット廃棄部１３４によって廃棄された廃棄パケットの再送を送信側装置２００に要求する。
【０１３０】
具体的に、再送要求部１３５は、パケット廃棄部１３４から通知された廃棄パケットのシーケンス番号４，５，６，７のうち、例えば最も小さいシーケンス番号４と同一のＡＣＫ番号（ＡＣＫ＝４）を示す４つのＡＣＫパケットの生成をＡＣＫ生成部１３２に促す。
【０１３１】
その結果、ＡＣＫ生成部１３２は、ＡＣＫ＝４を示す４つのＡＣＫパケット（否定応答パケット）Ｐ２６，Ｐ２７，Ｐ２８，Ｐ２９を生成して、これらのＡＣＫパケットを送受信制御部１３１から送信側装置２００に送信させる。なおこのとき、ウィンドウサイズ設定部１３３は、例えばウィンドウサイズとしてＲＷＩＮ＝４を設定し、上述のように送信されるＡＣＫパケットのそれぞれにはＲＷＩＮ＝４が示されている。また、ＡＣＫパケットＰ２７，Ｐ２８，Ｐ２９はＴＤＡＣＫとして送信される。
【０１３２】
一方、送信側装置２００は、上述のような４つのＡＣＫパケットＰ２６，Ｐ２７，Ｐ２８，Ｐ２９を受信すると、それらのＡＣＫパケットによって示されるＡＣＫ番号４と同一のシーケンス番号（ＳＥＱ＝４）のデータパケットＰ３０を受信側装置１００に送信する。すなわち、廃棄パケット（データパケットＰ３０）の高速再送が行われる。
【０１３３】
受信側装置１００の送受信制御部１３１は、データパケットＰ３０を受信すると受信用バッファメモリ１２０に格納する。その結果、シーケンス番号４の廃棄パケットは、再びデータパケットＰ３０として受信用バッファメモリ１２０に格納されて中央制御部１４０に受け渡される。
【０１３４】
ここで、再送要求部１３５は、さらに、パケット廃棄部１３４から通知された廃棄パケットのシーケンス番号４，５，６，７のうち、二番目に小さいシーケンス番号５と同一のＡＣＫ番号（ＡＣＫ＝５）を示す４つのＡＣＫパケットの生成をＡＣＫ生成部１３２に促す。
【０１３５】
その結果、ＡＣＫ生成部１３２は、ＡＣＫ＝５を示す４つのＡＣＫパケット（否定応答パケット）Ｐ３１，Ｐ３２，Ｐ３３，Ｐ３４を生成して、これらのＡＣＫパケットを送受信制御部１３１から送信側装置２００に送信させる。なおこのとき、ウィンドウサイズ設定部１３３は、例えばウィンドウサイズとしてＲＷＩＮ＝４を設定し、上述のように送信されるＡＣＫパケットのそれぞれにはＲＷＩＮ＝４が示されている。また、ＡＣＫパケットＰ３２，Ｐ３３，Ｐ３４はＴＤＡＣＫとして送信される。
【０１３６】
送信側装置２００は、上述のような４つのＡＣＫパケットＰ３１，Ｐ３２，Ｐ３３，Ｐ３４を受信すると、それらのＡＣＫパケットによって示されるＡＣＫ番号５と同一のシーケンス番号（ＳＥＱ＝５）のデータパケットＰ３５を受信側装置１００に送信する。すなわち、廃棄パケット（データパケットＰ３５）の高速再送が行われる。
【０１３７】
受信側装置１００の送受信制御部１３１は、データパケットＰ３５を受信すると受信用バッファメモリ１２０に格納する。その結果、シーケンス番号５の廃棄パケットは、再びデータパケットＰ３５として受信用バッファメモリ１２０に格納されて中央制御部１４０に受け渡される。
【０１３８】
このような、廃棄パケットの高速再送が繰り返し行われることにより、高速転送設定時の肯定応答パケットであるＡＣＫパケットＰ１２（ＡＣＫ＝０，ＲＷＩＮ＝８）に応じて送信側装置２００から送信されて中央制御部１４０に受け渡されるべきデータパケットが全て、中央制御部１４０に受け渡される。
【０１３９】
その結果、送受信制御部１３１は、パケットロスに対する復帰処理が完了したと判断して、その復帰処理完了をウィンドウサイズ設定部１３３に通知する。ウィンドウサイズ設定部１３３は、その通知を受けた後には、再び、高速転送設定を行う。
【０１４０】
図７は、パケットロスが発生したときの受信側装置１００とＳＡＣＫ対応の送信側装置２００と間で行われる通信の一例を示すシーケンス図である。
【０１４１】
まず、受信側装置１００と送信側装置２００とは、例えば、Three Way Handshakeなどにより、ＴＣＰ接続時のコネクションを設立する。このとき、受信側装置１００の送受信制御部１３１は、送信側装置２００の通信機能を特定する。例えば、送受信制御部１３１は、送信側装置２００の通信機能がＳＡＣＫに対応していると判断する。その結果、受信側装置１００は、パケットロスが発生したときには送信側装置２００に対してＳＡＣＫ対応の再送要求を行う。
【０１４２】
具体的には、まず、受信側装置１００のウィンドウサイズ設定部１３３は、上述と同様、高速転送設定を行う。すなわち、ウィンドウサイズ設定部１３３は、受信用バッファメモリ１２０の容量が４ＫＢしかないにもかかわらず、８ＫＢのウィンドウサイズ（ＲＷＩＮ＝８）を設定する。その結果、ＡＣＫ生成部１３２は、ＡＣＫ＝０およびＲＷＩＮ＝８を示すＡＣＫパケットＰ１２を生成する。
【０１４３】
このようにＡＣＫパケットＰ１２が生成されると、受信側装置１００の送受信制御部１３１は、そのＡＣＫパケットＰ１２を肯定応答パケットとして送信側装置２００に送信する。
【０１４４】
送信側装置２００は、ＡＣＫパケットＰ１２を受信すると、上述と同様、そのＡＣＫパケットＰ１２の示すウィンドウサイズ（ＲＷＩＮ＝８）分のデータパケットＰ１３，Ｐ１４，…，Ｐ２０を送信する。
【０１４５】
ここで、ＡＣＫパケットＰ１２に応じて送信側装置２００から送信されたデータパケットＰ１３，Ｐ１４，…，Ｐ２０のうち、データパケットＰ１３がネットワーク３００において消失する。つまり、パケットロスが発生する。
【０１４６】
受信側装置１００の送受信制御部１３１は、データパケットＰ１４（ＳＥＱ＝１）を受信すると、シーケンス番号０のデータパケットを受信していないため、シーケンス番号０のデータパケット（ロスパケット）が消失したこと、すなわちパケットロスが発生したことを検知する。さらに、送受信制御部１３１は、ロスパケットのシーケンス番号０をＡＣＫ生成部１３２に通知する。
【０１４７】
また、送受信制御部１３１は、データパケットＰ１４，Ｐ１５，Ｐ１６，Ｐ１７を順に受信して、受信用バッファメモリ１２０にそれらのデータパケット（ＳＥＱ＝１，２，３，４）を順に格納する。しかし、上述のように、シーケンス番号０のデータパケットＰ１３が受信用バッファメモリ１２０に格納されていないため、データパケットＰ１４，Ｐ１５，Ｐ１６，Ｐ１７を中央制御部１４０に受け渡すことができず、受信用バッファメモリ１２０の空き容量がなくなる。つまり、このとき、受信用バッファメモリ１２０は停滞状態となる。
【０１４８】
そこで、パケット廃棄部１３４は、シーケンス番号４のデータパケットＰ１７を廃棄する。その結果、停滞状態は一時的に解かれ、受信用バッファメモリ１２０に空き容量ができ、受信用バッファメモリ１２０は、新たなデータパケットを格納し得る状態となる。
【０１４９】
これにより、送受信制御部１３１は、送信側装置２００から送信されて受信したデータパケットＰ１８（ＳＥＱ＝５）を受信用バッファメモリ１２０に格納する。
【０１５０】
データパケットＰ１８（ＳＥＱ＝５）が受信用バッファメモリ１２０に格納されると、受信用バッファメモリ１２０は、データパケットＰ１４，Ｐ１５，Ｐ１６，Ｐ１８（ＳＥＱ＝１，２，３，５）を格納することとなり、再び停滞状態となる。
【０１５１】
そこで、パケット廃棄部１３４は、シーケンス番号５のデータパケットＰ１８を廃棄する。その結果、停滞状態は一時的に解かれ、受信用バッファメモリ１２０に空き容量ができ、受信用バッファメモリ１２０は、新たなデータパケットを格納し得る状態となる。
【０１５２】
これにより、送受信制御部１３１は、送信側装置２００から送信されて受信したデータパケットＰ１９（ＳＥＱ＝６）を受信用バッファメモリ１２０に格納する。
【０１５３】
このようなデータパケットの格納と廃棄とは、シーケンス番号７のデータパケット（最終パケット）Ｐ２０が受信側装置１００に受信されるまで繰り返される。
【０１５４】
但し、パケット廃棄部１３４は、最終パケットであるデータパケットＰ２０が受信用バッファメモリ１２０に格納されてその受信用バッファメモリ１２０が停滞状態になると、その最終パケットであるデータパケットＰ２０ではなく、シーケンス番号３のデータパケットＰ１６を廃棄する。
【０１５５】
すなわち、パケット廃棄部１３４は、受信用バッファメモリ１２０が停滞状態になったときには、直前に格納されたデータパケットが最終パケットであるか否かを判断する。なお、最終パケットとは、高速転送設定時の肯定応答パケットであるＡＣＫパケットＰ１２に対して送信側装置２００から送信されるデータパケットのうちの、最後に送信されるデータパケットである。
【０１５６】
そして、パケット廃棄部１３４は、データパケットＰ２０が最終パケットであると判断すると、停滞状態にある受信用バッファメモリ１２０に格納されているデータパケットのうち、ＳＥＱ＝７を示すデータパケットＰ２０ではなく、他のＳＥＱ＝３を示すデータパケット（中間パケット）Ｐ１６を廃棄する。
【０１５７】
その結果、パケット廃棄部１３４は、データパケットＰ１６，Ｐ１７，Ｐ１８，Ｐ１９（ＳＥＱ＝３，４，５，６）を廃棄することとなる。
【０１５８】
このようにパケット廃棄部１３４が最終パケットを削除せずに受信用バッファメモリ１２０に残しておくことにより、再送要求部１３５は、受信用バッファメモリ１２０に格納されていない複数の廃棄パケットを一括して再送させるためのＳＡＣＫパケットの生成をＡＣＫ生成部１３２に促すことができる。例えば、再送要求部１３５は、ＳＥＱ＝１，２，７を示すデータパケットＰ１４，Ｐ１５，Ｐ２０が受信用バッファメモリ１２０に格納されているため、通常のＡＣＫ番号０に加えて、連続するシーケンス番号の先頭と最後であるＳＥＱ＝１，２と、何れのシーケンス番号とも連続していないシーケンス番号であるＳＥＱ＝７とを送信側装置２００に通知する。つまり、このときに生成されるＳＡＣＫパケットは、受信用バッファメモリ１２０に格納されている３つのデータパケットのシーケンス番号１，２，７をＡＣＫ番号として示すことにより、シーケンス番号２とシーケンス番号７との間のシーケンス番号３〜６を、再送要求の対象とされているデータパケットのシーケンス番号として示すことができる。
【０１５９】
また、受信側装置１００は、上述のデータパケットＰ１４，Ｐ１５，Ｐ１６，Ｐ１７を受信すると、それらがシーケンス番号０のデータパケットでないため、その受信ごとに、ＡＣＫ＝０を示す否定応答パケットであるＡＣＫパケットＰ２１，Ｐ２２，Ｐ２３，Ｐ２５を送信側装置２００に送信する。
【０１６０】
すなわち、送受信制御部１３１がデータパケットＰ１４（ＳＥＱ＝１）を受信したときにパケットロスの発生を検知すると、ウィンドウサイズ設定部１３３は、高速転送設定を停止して、通常転送設定を行う。その結果、ウィンドウサイズ設定部１３３は、受信用バッファメモリ１２０の空き容量をウィンドウサイズ（ＲＷＩＮ＝３）として設定する。
【０１６１】
これにより、ＡＣＫ生成部１３２は、送受信制御部１３１でデータパケットＰ１４（ＳＥＱ＝１）が受信されると、ＡＣＫ＝０およびＲＷＩＮ＝３を示すＡＣＫパケット（否定応答パケット）Ｐ２１を生成してそのＡＣＫパケットＰ２１を送受信制御部１３１から送信側装置２００に送信させる。
【０１６２】
さらに、送受信制御部１３１がデータパケットＰ１５（ＳＥＱ＝２）を受信したときにも、ウィンドウサイズ設定部１３３は通常転送設定を行う。すなわち、ウィンドウサイズ設定部１３３は、受信用バッファメモリ１２０の空き容量をウィンドウサイズ（ＲＷＩＮ＝２）として設定する。
【０１６３】
これにより、ＡＣＫ生成部１３２は、送受信制御部１３１でデータパケットＰ１５（ＳＥＱ＝２）が受信されると、ＡＣＫ＝０およびＲＷＩＮ＝２を示すＡＣＫパケット（否定応答パケット）Ｐ２２を生成してそのＡＣＫパケットＰ２２を送受信制御部１３１から送信側装置２００に送信させる。
【０１６４】
このように、受信側装置１００は、データパケットＰ１７を受信するまで、データパケットを受信するごとに、ＡＣＫパケット（ＡＣＫ＝０）を送信側装置２００に送信する。
【０１６５】
ここで、受信側装置１００の再送要求部１３５は、最終パケットであるシーケンス番号７のデータパケットＰ２０が受信用バッファメモリ１２０に格納されてシーケンス番号３のデータパケットＰ１６が廃棄されると、パケット廃棄部１３４によって廃棄された廃棄パケットの再送を送信側装置２００に要求する。
【０１６６】
具体的に、再送要求部１３５は、受信用バッファメモリ１２０に格納されているデータパケットのシーケンス番号を特定する。上述の場合には、受信用バッファメモリ１２０には、データパケットＰ１４，Ｐ１５，２０（ＳＥＱ＝１，２，７）が格納されているため、再送要求部１３５はシーケンス番号１，２，７を特定する。そして、再送要求部１３５は、特定したシーケンス番号１，２，７をＡＣＫ生成部１３２に通知して、それらのシーケンス番号をそれぞれＡＣＫ番号として示すＳＡＣＫパケットを生成するようにＡＣＫ生成部１３２に指示する。なお、この例の場合、上述のように特定されたシーケンス番号１，２，７のうち、連続しているシーケンス番号がＳＥＱ＝１，２であって、その先頭と最後のシーケンス番号がＳＥＱ＝１，２であるため、再送要求部１３５は、その特定されたシーケンス番号１，２，７を全てＡＣＫ生成部１３２に通知している。
【０１６７】
その結果、ＡＣＫ生成部１３２は、通常のＡＣＫ＝０と、ＡＣＫ＝１，２，７（欠落しているデータパケットのシーケンス番号３〜６）とを示すＳＡＣＫパケットＰ２６を生成して、そのＳＡＣＫパケットＰ２６を送受信制御部１３１から送信側装置２００に送信させる。なおこのとき、ウィンドウサイズ設定部１３３は、例えばウィンドウサイズとしてＲＷＩＮ＝１を設定し、上述のように送信されるＳＡＣＫパケットにはＲＷＩＮ＝１が示されている。
【０１６８】
一方、送信側装置２００は、ＳＡＣＫ対応の通信機能を有しているため、ＡＣＫ＝０を示すＡＣＫパケットＰ２１，Ｐ２２，Ｐ２３を受信すると、シーケンス番号０を示すデータパケットＰ２４（ロスパケット）を受信側装置１００に再送する。
【０１６９】
受信側装置１００の送受信制御部１３１は、再送されたデータパケットＰ２４を受信すると、そのデータパケットＰ２４を受信用バッファメモリ１２０に格納する。
【０１７０】
その結果、受信用バッファメモリ１２０には、それぞれシーケンス番号０，１，２を示すデータパケットが格納されるため、これらのデータパケットは中央制御部１４０に速やかに受け渡される。
【０１７１】
また、送信側装置２００は、上述のようなＳＡＣＫパケットＰ２６を受信すると、そのＳＡＣＫパケットＰ２６によって特定されるシーケンス番号（ＳＥＱ＝３〜６）のデータパケットＰ２７，Ｐ２８，Ｐ２９，Ｐ３０を受信側装置１００に送信する。すなわち、廃棄パケット（データパケットＰ２７，Ｐ２８，Ｐ２９，Ｐ３０）の高速再送が一括して行われる。
【０１７２】
受信側装置１００の送受信制御部１３１は、データパケットＰ２７，Ｐ２８，Ｐ２９，Ｐ３０を受信すると受信用バッファメモリ１２０に格納する。その結果、シーケンス番号３，４，５，６の廃棄パケットは、再びデータパケットＰ２７，Ｐ２８，Ｐ２９，Ｐ３０として受信用バッファメモリ１２０に格納されて中央制御部１４０に受け渡される。さらに、その後、受信用バッファメモリ１２０に格納されていたシーケンス番号７のデータパケットＰ２０も中央制御部１４０に受け渡される。
【０１７３】
このような、廃棄パケットの高速再送が行われることにより、高速転送設定時の肯定応答パケットであるＡＣＫパケットＰ１２（ＡＣＫ＝０，ＲＷＩＮ＝８）に応じて送信側装置２００から送信されて中央制御部１４０に受け渡されるべきデータパケットが全て、中央制御部１４０に受け渡される。
【０１７４】
その結果、送受信制御部１３１は、パケットロスに対する復帰処理が完了したと判断して、その復帰処理完了をウィンドウサイズ設定部１３３に通知する。したがって、ウィンドウサイズ設定部１３３は、その通知を受けた後には、再び、高速転送設定を行う。
【０１７５】
図８は、本実施の形態における受信側装置１００の全体的な動作を示すフローチャートである。
【０１７６】
まず、受信側装置１００は、ウィンドウサイズ設定部１３３による高速転送設定により、受信用バッファメモリ１２０の容量より大きなウィンドウサイズを示すＡＣＫパケットを肯定応答パケットとして生成して送信側装置２００に送信する（ステップＳ１００）。これにより、送信側装置２００にはそのウィンドウサイズが通知され、送信側装置２００からは、そのウィンドウサイズ分のデータパケットが送信される。
【０１７７】
受信側装置１００は、そのＡＣＫパケットに応じて送信側装置２００から送信されたデータパケットが消失したか否か、すなわちパケットロスが発生したか否かを判別する（ステップＳ１０２）。ここで、受信側装置１００は、パケットロスが発生したと判別したときには（ステップＳ１０２のＹ）、そのパケットロスによって生じる受信用バッファメモリ１２０の停滞状態を解消するために、復帰処理を実行する（ステップＳ１０４）。
【０１７８】
一方、受信側装置１００は、パケットロスが発生していないと判別したときや（ステップＳ１０２のＮ）、復帰処理の実行が完了したときには、ステップＳ１００で通知されたウィンドウサイズ分のデータパケットを全て受信する。その後、受信側装置１００は、送信側装置２００からのデータパケットの受信を終了すべきか否かを判別する（ステップＳ１０６）。
【０１７９】
ここで、受信側装置１００は、終了すべきでないと判別すると（ステップＳ１０６のＮ）、ステップＳ１００からの処理を繰り返し実行し、終了すべきと判別すると（ステップＳ１０６のＹ）、全ての処理を終了する。
【０１８０】
図９は、受信側装置１００の復帰処理（図８のステップＳ１０４）における動作を示すフローチャートである。
【０１８１】
受信側装置１００は、送信側装置２００とコネクションを設立するときに、送信側装置２００の通信機能を特定しており、パケットロスが発生したときには、送信側装置２００の通信機能に応じた復帰処理を行う。
【０１８２】
具体的に、受信側装置１００は、まず、送信側装置２００がＳＡＣＫ対応の通信機能を有しているか否かを判別する（ステップＳ２００）。ここで、受信側装置１００は、送信側装置２００がＳＡＣＫ対応の通信機能を有していると判別すると（ステップＳ２００のＹ）、図７を用いて説明したような復帰処理を行う。
【０１８３】
すなわち、受信側装置１００のパケット廃棄部１３４は、受信用バッファメモリ１２０が停滞状態にあると、その受信用バッファメモリ１２０に格納されている複数（４つ）のデータパケットから、１つの中間パケットを廃棄する（ステップＳ２０２）。ここで、中間パケットとは、パケットロスが発生する直前の高速転送設定時に送信されたＡＣＫパケットに応じて、送信側装置２００から送信されるデータパケットのうち、最終パケット以外の最近格納されたデータパケットである。
【０１８４】
このように中間パケットが廃棄されることによって、受信用バッファメモリ１２０に空き容量ができる。したがって、その後に、送信側装置２００からデータパケットが送信されると、受信側装置１００の送受信制御部１３１は、そのデータパケットを受信してその受信用バッファメモリ１２０に格納する（ステップＳ２０４）。その結果、受信用バッファメモリ１２０は再び停滞状態になる。
【０１８５】
このとき、受信側装置１００のパケット廃棄部１３４は、ステップＳ２０４で格納されたデータパケットが最終パケットか否かを判別する（ステップＳ２０６）。
【０１８６】
ここで、パケット廃棄部１３４は、最終パケットでないと判別すると（ステップＳ２０６のＮ）、最近のＡＣＫパケット（肯定応答パケット）が高速転送設定で送信されてから所定の時間が経過したか否か、すなわちタイムアウトが生じたか否かを判別する（ステップＳ２０８）。パケット廃棄部１３４は、タイムアウトが生じていないと判別すると（ステップＳ２０８のＮ）、再びステップＳ２０２からの処理を繰り返し実行する。
【０１８７】
一方、パケット廃棄部１３４は、ステップＳ２０６で最終パケットであると判別すると（ステップＳ２０６のＹ）、その最終パケットを受信用バッファメモリ１２０に残したまま、中間パケットを廃棄する（ステップＳ２１０）。その結果、受信用バッファメモリ１２０の停滞状態は解かれて、受信用バッファメモリ１２０は、送信側装置２００から再送されるロスパケットを格納し得る状態となる。
【０１８８】
また、パケット廃棄部１３４は、ステップＳ２０８でタイムアウトが生じたと判別すると（ステップＳ２０８のＹ）、直前のステップＳ２０４で格納された中間パケットを最終パケットとして扱い、その最終パケットを受信用バッファメモリ１２０に残したまま、他の中間パケットを廃棄する（ステップＳ２１０）。その結果、上述と同様、受信用バッファメモリ１２０の停滞状態は解かれて、受信用バッファメモリ１２０は、送信側装置２００から再送されるロスパケットを格納し得る状態となる。
【０１８９】
なお、送受信制御部１３１は、最終パケット以外のデータパケットを受信すると、その受信ごとに、ロスパケットの再送を促すＡＣＫパケット（否定応答パケット）を送信側装置２００に送信している。したがって、このようなＡＣＫパケットに応じて、送信側装置２００からロスパケットが再送されると、受信側装置１００の送受信制御部１３１は、そのロスパケットを受信して受信用バッファメモリ１２０に格納する。その結果、受信用バッファメモリ１２０に格納されているデータパケットのうち、そのロスパケットを含む幾つかのデータパケットが速やかに中央制御部１４０に受け渡される。
【０１９０】
さらに、受信側装置１００は、ステップＳ２０２，Ｓ２１０で廃棄された全ての中間パケット（廃棄パケット）の再送を一括して要求するＳＡＣＫパケットを送信側装置２００に送信する（ステップＳ２１２）。
【０１９１】
そして、受信側装置１００は、そのＳＡＣＫパケットによって廃棄パケットを全て受信したか否かを判別し（ステップＳ２１４）、受信していないと判別したときには（ステップＳ２１４のＮ）、再びステップＳ２１２からの処理を繰り返し実行する。
【０１９２】
また、受信側装置１００は、ステップＳ２００で、送信側装置２００がＳＡＣＫ対応の通信機能を有していないと判別すると（ステップＳ２００のＮ）、さらに、送信側装置２００がＴＤＡＣＫ対応の通信機能を有しているか否かを判別する（ステップＳ２１６）。ここで、受信側装置１００は、送信側装置２００がＴＤＡＣＫ対応の通信機能を有していると判別すると（ステップＳ２１６のＹ）、図６を用いて説明したような復帰処理を行う。
【０１９３】
すなわち、受信側装置１００のパケット廃棄部１３４は、受信用バッファメモリ１２０が停滞状態にあると、その受信用バッファメモリ１２０に格納されている複数（４つ）のデータパケットから、１つの中間パケットを廃棄する（ステップＳ２１８）。
【０１９４】
このように中間パケットが廃棄されることによって、受信用バッファメモリ１２０に空き容量ができる。したがって、その後に、送信側装置２００からデータパケットが送信されると、受信側装置１００の送受信制御部１３１は、そのデータパケットを受信してその受信用バッファメモリ１２０に格納する（ステップＳ２２０）。その結果、受信用バッファメモリ１２０は再び停滞状態になる。
【０１９５】
このとき、受信側装置１００のパケット廃棄部１３４は、ステップＳ２２０で格納されたデータパケットが最終パケットか否かを判別する（ステップＳ２２２）。
【０１９６】
ここで、パケット廃棄部１３４は、最終パケットでないと判別すると（ステップＳ２２２のＮ）、最近のＡＣＫパケット（肯定応答パケット）が高速転送設定で送信されてから所定の時間が経過したか否か、すなわちタイムアウトが生じたか否かを判別する（ステップＳ２２４）。パケット廃棄部１３４は、タイムアウトが生じていないと判別すると（ステップＳ２２４のＮ）、再びステップＳ２１８からの処理を繰り返し実行する。
【０１９７】
一方、パケット廃棄部１３４は、ステップＳ２２２で最終パケットであると判別すると（ステップＳ２２２のＹ）、その最終パケットを廃棄する（ステップＳ２２６）。その結果、受信用バッファメモリ１２０の停滞状態は解かれて、受信用バッファメモリ１２０は、送信側装置２００から再送されるロスパケットを格納し得る状態となる。
【０１９８】
また、パケット廃棄部１３４は、ステップＳ２２４でタイムアウトが生じたと判別すると（ステップＳ２２４のＹ）、直前のステップＳ２２０で格納された中間パケットを最終パケットとして扱い、その最終パケットを廃棄する（ステップＳ２２６）。その結果、上述と同様、受信用バッファメモリ１２０の停滞状態は解かれて、受信用バッファメモリ１２０は、送信側装置２００から再送されるロスパケットを格納し得る状態となる。
【０１９９】
なお、送受信制御部１３１は、データパケットを受信すると、その受信ごとに、ロスパケットの再送を促すＡＣＫパケット（否定応答パケット）を送信側装置２００に送信している。したがって、このようなＡＣＫパケットに応じて、送信側装置２００からロスパケットが再送されると、受信側装置１００の送受信制御部１３１は、そのロスパケットを受信して受信用バッファメモリ１２０に格納する。その結果、受信用バッファメモリ１２０に格納されているデータパケットのうち、そのロスパケットを含む幾つかのデータパケットが速やかに中央制御部１４０に受け渡される。
【０２００】
さらに、受信側装置１００は、ステップＳ２２６の後に再送されたロスパケットを受信すると、ステップＳ２１８，Ｓ２２６で廃棄された全ての中間パケット（廃棄パケット）のうち１つの廃棄パケットの再送を要求する４つのＡＣＫパケット（否定応答パケット）を送信側装置２００に送信する（ステップＳ２２８）。なお、この４つのＡＣＫパケットのうち３つはＴＤＡＣＫパケットである。
【０２０１】
そして、受信側装置１００は、そのＴＤＡＣＫパケットの送信によって廃棄パケットを全て受信したか否かを判別する（ステップＳ２３０）。ここで、受信側装置１００は、全て受信していないと判別したときには（ステップＳ２３０のＮ）、最近のＡＣＫパケット（肯定応答パケット）が高速転送設定で送信されてから所定の時間が経過したか否か、すなわちタイムアウトが生じたか否かを判別する（ステップＳ２３２）。受信側装置１００は、タイムアウトが生じていないと判別すると（ステップＳ２３２のＮ）、再びステップＳ２２８からの処理を実行する。
【０２０２】
一方、受信側装置１００は、タイムアウトが生じたと判別すると（ステップＳ２３２のＹ）、受信側装置１００のパケット廃棄部１３４は、受信用バッファメモリ１２０内の全てのデータパケットを廃棄して、送信側装置２００から改めて再送されるデータパケットを受信する（ステップＳ２３４）。
【０２０３】
なお、受信側装置１００は、ステップＳ２２８で廃棄パケットの再送を要求する前に、再送要求により全ての廃棄パケットを順次再送させて受信するまでに要する時間と、タイムアウトにより全ての廃棄パケットを再送させて受信するまでに要する時間とを比較してもよい。この場合、受信側装置１００は、再送要求における時間がタイムアウトにおける時間よりも短いと判断した場合には、ステップＳ２２８の処理を実行し、逆に、タイムアウトにおける時間が再送要求における時間よりも短いと判断した場合には、ステップＳ２２８の処理を実行せずにタイムアウトが生じるまで待機する。
【０２０４】
また、受信側装置１００は、ステップＳ２００で、送信側装置２００がＴＤＡＣＫ対応の通信機能を有していないと判別すると（ステップＳ２１６のＮ）、タイムアウトによる復帰処理を行う。
【０２０５】
つまり、受信側装置１００は、タイムアウトが生じるまで待機し（ステップＳ２３６）、上述のステップＳ２３４の処理を実行する。
【０２０６】
このように本実施の形態では、受信用バッファメモリ１２０の容量よりも大きなウィンドウサイズがＡＣＫパケットにより送信側装置２００に通知されるため、受信用バッファメモリ１２０の容量が少なくても、ＲＴＴ内において送信側装置２００から多くのデータを送信させることができ、その結果、記憶容量という環境的な制約を受けることなく効率的なデータ転送を行うことができる。
【０２０７】
さらに、本実施の形態では、パケットロスが発生して受信用バッファメモリ１２０が停滞状態になったときには、受信用バッファメモリ１２０に格納されているデータパケットが廃棄されて空き容量が確保されるため、再送されたロスパケットを受信用バッファメモリ１２０に格納して、その受信用バッファメモリ１２０に格納されている多くのデータパケットを中央制御部１４０のアプリケーションプログラムに受け渡すことができる。その結果、受信用バッファメモリ１２０が停滞状態になることよってデータ受信処理（データ転送）が停止されるのを避けることができる。
【０２０８】
さらに、廃棄されたデータパケットの再送が要求されるため、タイムアウトの発生を待たずに、その廃棄されたデータパケットを再び受信して受信用バッファメモリ１２０に格納することができる。その結果、データ受信処理（データ転送）が滞ったとしても、データ転送効率を著しく劣化させることを避けることができる。つまり、高速転送設定により設定されて通知されたウィンドウサイズに応じて送信側装置２００から送信される全てのデータパケットを迅速に受信することができる。
【０２０９】
（変形例１）
上記実施の形態の受信側装置１００は、送信側装置２００がＴＤＡＣＫ対応またはＳＡＣＫ対応の通信機能を有しているときには、廃棄パケットの再送を送信側装置２００に要求した。しかし、本発明に係る通信装置は、廃棄パケットの再送を送信側装置２００に要求しなくてもよい。
【０２１０】
図１０は、本変形例に係る受信側装置１００と送信側装置２００との間で行われる通信の一例を示すシーケンス図である。なお、この例では、送信側装置２００はＴＤＡＣＫ対応の通信機能を有している。
【０２１１】
まず、受信側装置１００は、図６または図７に示す処理と同様の処理を行うことにより、シーケンス番号４のデータパケットＰ１７を受信して受信用バッファメモリ１２０に格納する。その結果、受信用バッファメモリ１２０は上述のように停滞状態となる。
【０２１２】
ここで、パケット廃棄部１３４は、その停滞状態を解くために、シーケンス番号４のデータパケットＰ１７を廃棄すると、その廃棄パケットのシーケンス番号４をＡＣＫ生成部１３２に通知する。そして、送受信制御部１３１は、送信側装置２００から送信されて受信したデータパケットＰ１８（ＳＥＱ＝５）を受信用バッファメモリ１２０に格納する。
【０２１３】
データパケットＰ１８（ＳＥＱ＝５）が受信用バッファメモリ１２０に格納されると、受信用バッファメモリ１２０は、データパケットＰ１４，Ｐ１５，Ｐ１６，Ｐ１８（ＳＥＱ＝１，２，３，５）を格納することとなり、再び停滞状態となる。
【０２１４】
そこで、パケット廃棄部１３４は、その停滞状態を解くために、シーケンス番号５のデータパケットＰ１８を廃棄すると、その廃棄パケットのシーケンス番号５をＡＣＫ生成部１３２に通知する。そして、送受信制御部１３１は、送信側装置２００から送信されて受信したデータパケットＰ１９（ＳＥＱ＝６）を受信用バッファメモリ１２０に格納する。
【０２１５】
このようなデータパケットの格納と廃棄とは、シーケンス番号７のデータパケット（最終パケット）Ｐ２０が受信側装置１００に受信されるまで繰り返される。その結果、受信用バッファメモリ１２０に格納されたデータパケットＰ２０（ＳＥＱ＝７）は削除され、受信用バッファメモリ１２０に空き容量ができ、受信用バッファメモリ１２０は、新たなデータパケットを格納し得る状態となる。
【０２１６】
また、受信側装置１００は、データパケットＰ１４，Ｐ１５，Ｐ１６，Ｐ１７を受信すると、図６または図７に処理と同様、その受信ごとにＡＣＫ＝０を示すＡＣＫパケット（否定応答パケット）Ｐ２１，Ｐ２２，Ｐ２３，Ｐ２５を送信側装置２００に送信する。
【０２１７】
一方、送信側装置２００は、ＴＤＡＣＫ対応の通信機能を有しているため、ＡＣＫ＝０を示すＡＣＫパケットＰ２１，Ｐ２２，Ｐ２３を受信すると、シーケンス番号０を示すデータパケットＰ２４（ロスパケット）を受信側装置１００に再送する。
【０２１８】
受信側装置１００の送受信制御部１３１は、再送されたデータパケットＰ２４を受信すると、そのデータパケットＰ２４を受信用バッファメモリ１２０に格納する。
【０２１９】
その結果、受信用バッファメモリ１２０には、それぞれシーケンス番号０，１，２，３を示すデータパケットが格納されるため、これらのデータパケットは中央制御部１４０に速やかに受け渡される。
【０２２０】
また、送受信制御部１３１は、再送されたデータパケットＰ２４を受信すると、そのデータパケットＰ２４に対するＡＣＫパケット（否定応答パケット）Ｐ２６を送信側装置２００に送信する。このＡＣＫパケットＰ２６は、ＡＣＫ＝４およびＲＷＩＮ＝４を示す。
【０２２１】
つまり、このとき、ＡＣＫ生成部１３２は、ウィンドウサイズ設定部１３３による通常転送設定により設定されたウィンドウサイズ（ＲＷＩＮ＝４）と、パケット廃棄部１３４から通知された廃棄パケットのシーケンス番号４と同一のＡＣＫ番号（ＡＣＫ＝４）とを示すＡＣＫパケットＰ２６を生成している。
【０２２２】
送信側装置２００は、ＡＣＫ＝０およびＲＷＩＮ＝４を示すＡＣＫパケットＰ２６を受信すると、シーケンス番号０〜７のデータパケットＰ１３〜Ｐ２０を送信しているため、シーケンス番号８，９，１０，１１を示すデータパケットＰ２７，２８，２９，３０を受信側装置１００に送信する。
【０２２３】
受信側装置１００の送受信制御部１３１は、データパケットＰ２７，Ｐ２８，Ｐ２９，Ｐ３０を順に受信して、受信用バッファメモリ１２０にそれらのデータパケット（ＳＥＱ＝８，９，１０，１１）を順に格納する。しかし、上述のように、シーケンス番号４のデータパケットＰ１７が受信用バッファメモリ１２０に格納されていないため、データパケットＰ２７，Ｐ２８，Ｐ２９，Ｐ３０を中央制御部１４０に受け渡すことができず、受信用バッファメモリ１２０の空き容量がなくなる。つまり、このとき、受信用バッファメモリ１２０は停滞状態となる。
【０２２４】
そこで、パケット廃棄部１３４は、シーケンス番号１１のデータパケットＰ３０を廃棄し、その廃棄パケットのシーケンス番号１１をＡＣＫ生成部１３２に通知する。その結果、停滞状態は一時的に解かれ、受信用バッファメモリ１２０に空き容量ができ、受信用バッファメモリ１２０は、新たなデータパケットを格納し得る状態となる。
【０２２５】
また、受信側装置１００は、上述のデータパケットＰ２７，Ｐ２８，Ｐ２９，Ｐ３０を受信すると、それらがシーケンス番号４のデータパケットでないため、その受信ごとに、ＡＣＫ＝４を示す否定応答パケットであるＡＣＫパケットＰ３１，Ｐ３２，Ｐ３３，Ｐ３５を送信側装置２００に送信する。
【０２２６】
すなわち、送受信制御部１３１でデータパケットＰ２７（ＳＥＱ＝８）が受信されると、そのデータパケットＰ２７のシーケンス番号は、ＡＣＫパケットＰ２６の示すＡＣＫ番号４と同一ではない。したがって、ＡＣＫ生成部１３２は、ウィンドウサイズ設定部１３３による通常転送設定により設定されたウィンドウサイズ（ＲＷＩＮ＝３）と上述のＡＣＫ番号４とを示すＡＣＫパケットＰ３１を否定応答パケットとして生成し、そのＡＣＫパケットＰ３１を送受信制御部１３１から送信側装置２００に送信させる。
【０２２７】
さらに、送受信制御部１３１でデータパケットＰ２８（ＳＥＱ＝９）が受信されると、そのデータパケットＰ２８のシーケンス番号は、ＡＣＫパケットＰ２６の示すＡＣＫ番号４と同一ではない。したがって、ＡＣＫ生成部１３２は、ウィンドウサイズ設定部１３３による通常転送設定により設定されたウィンドウサイズ（ＲＷＩＮ＝２）と上述のＡＣＫ番号４とを示すＡＣＫパケットＰ３２を否定応答パケットとして生成し、そのＡＣＫパケットＰ３２を送受信制御部１３１から送信側装置２００に送信させる。
【０２２８】
このように、受信側装置１００は、データパケットＰ３０を受信するまで、データパケットを受信するごとに、ＡＣＫ＝４を示すＡＣＫパケットを否定応答パケットとして送信側装置２００に送信する。
【０２２９】
送信側装置２００は、ＴＤＡＣＫ対応の通信機能を有しているため、ＡＣＫ＝４を示すＡＣＫパケットＰ３１，Ｐ３２，Ｐ３３を受信すると、シーケンス番号４を示すデータパケットＰ３４を受信側装置１００に再送する。
【０２３０】
受信側装置１００の送受信制御部１３１は、再送されたデータパケットＰ３４を受信すると、そのデータパケットＰ３４を受信用バッファメモリ１２０に格納する。
【０２３１】
その結果、受信用バッファメモリ１２０には、シーケンス番号４を示すデータパケットが格納されるため、そのデータパケットは中央制御部１４０に速やかに受け渡される。
【０２３２】
また、受信側装置１００の送受信制御部１３１は、再送されたデータパケットＰ３４を受信すると、ＡＣＫパケット（否定応答パケット）Ｐ３６を送信側装置２００に送信する。このＡＣＫパケットＰ３６は、ＡＣＫ＝５およびＲＷＩＮ＝１を示す。
【０２３３】
つまり、このとき、ＡＣＫ生成部１３２は、ウィンドウサイズ設定部１３３による通常転送設定により設定されたウィンドウサイズ（ＲＷＩＮ＝１）と、パケット廃棄部１３４から通知された廃棄パケットのシーケンス番号５と同一のＡＣＫ番号（ＡＣＫ＝５）とを示すＡＣＫパケットＰ３６を生成している。
【０２３４】
このように、受信側装置１００と送信側装置２００との間で通信処理が行われるが、廃棄パケットの再送要求が行われないため、最初のＡＣＫパケットＰ１２で示されたシーケンス番号０〜７のデータパケットが全て受信側装置１００に受信されて中央制御部１４０に受け渡されるまでには時間がかかる。また、ＡＣＫパケットＰ１２の送受信が行われてから、シーケンス番号０〜７の全てのデータパケットが受信されない状態で所定時間が経過したときには、タイムアウトが発生する。例えば、ＡＣＫパケットＰ３６が送信された後に、タイムアウトが発生すると、送信側装置２００からシーケンス番号５〜７のデータパケットが再送される。したがって、受信側装置１００は、ＡＣＫパケットＰ１２の送受信が行われてから、シーケンス番号０〜７の全てのデータパケットが受信されない状態で所定時間が経過したときには、タイムアウトが発生したと判断し、受信用バッファメモリ１２０内の全てのデータパケットを廃棄する。
【０２３５】
その結果、受信側装置１００は、再び高速転送設定により設定されたウィンドウサイズ（ＲＷＩＮ＝８）を示すＡＣＫパケットを送信側装置２００に送信し、シーケンス番号８のデータパケットから各データパケットを順次受信する。
【０２３６】
（変形例２）
上記実施の形態では、受信側装置１００は、送信側装置２００から送信されるデータを利用する中央制御部１４０およびメインメモリ１５０を備えていたが、これらを備えていなくてもよい。すなわち、本発明に係る通信装置は、送信側装置２００から送信されるデータを中継して、そのデータを利用するデータ処理装置に送信する受信中継装置であってもよい。
【０２３７】
図１１は、本変形例に係る受信中継装置の構成を示す構成図である。
【０２３８】
受信中継装置１００ａは、ネットワーク３００を介して送信側装置２００と接続され、その送信側装置２００とＴＣＰ／ＩＰに従った通信を行う。また、受信中継装置１００ａは、ネットワーク３０１を介してデータ処理装置４００と接続されている。
【０２３９】
この受信中継装置１００ａは、ＴＣＰ／ＩＰの終端として構成され、送信側装置２００から送信されたデータを受信し、その受信したデータをデータ処理装置４００に送信する。つまり、受信中継装置１００ａとデータ処理装置４００とから、上記実施の形態における受信側装置１００が構成される。
【０２４０】
また、受信中継装置１００ａは、上記実施の形態における受信側装置１００の通信制御部１１０と、送信処理部１６０とを備えている。送信処理部１６０は、通信制御部１１０の受信用バッファメモリ１２０に格納されたデータパケットを取り出してデータ処理装置４００に送信する処理手段として構成されている。
【０２４１】
（変形例３）
本変形例に係る受信側装置１００は、複数の通信フローのそれぞれのウィンドウサイズの合計が受信用バッファメモリ１２０の容量よりも大きくなるように、通信フローごとにウィンドウサイズを設定する。
【０２４２】
図１２は、本変形例に係る受信側装置１００の動作を説明するための説明図である。
【０２４３】
受信側装置１００は、例えば送信側装置２００ａ，２００ｂからデータを受信する処理を並列に行う。このとき、受信側装置１００のウィンドウサイズ設定部１３３は、送信側装置２００ａ，２００ｂのそれぞれに、例えば、６４ＫＢのウィンドウサイズを設定する。
【０２４４】
つまり、ウィンドウサイズ設定部１３３は、送信側装置（通信フロー）のそれぞれに対して受信用バッファメモリ１２０の容量（１００ＫＢ）よりも小さいウィンドウサイズを設定する。そしてこのとき、ウィンドウサイズ設定部１３３は、全ての送信側装置（全ての通信フロー）に対して設定されるウィンドウサイズの合計が受信用バッファメモリ１２０の容量（１００ＫＢ）よりも大きくなるように、各送信側装置（各通信フロー）に対するウィンドウサイズを設定する。以下、このように１つの送信側装置（１つの通信フロー）に対して設定されるウィンドウサイズを拡大ウィンドウサイズという。
【０２４５】
したがって、受信側装置１００は、送信側装置２００ａ，２００ｂのそれぞれに対して、その拡大ウィンドウサイズ（ＲＷＩＮ＝６４）をＡＣＫパケットにより通知する。
【０２４６】
なお、上述の例では、受信側装置１００と複数の送信側装置のそれぞれとの間で複数の通信フローを設定したが、受信側装置１００と１つの送信側装置との間で複数の通信フローを設定してもよい。つまり、本変形例に係る受信側装置１００は、送信側装置の数に関わらず、通信フローごとに上述のような拡大ウィンドウサイズを設定する。
【０２４７】
このように本変形例では、通信フローが複数であっても、各通信フローで通知される拡大ウィンドウサイズ（ＲＷＩＮ＝６４）の合計が受信用バッファメモリ１２０の容量（１００ＫＢ）よりも大きいため、複数の通信フローの処理が同時に滞らない限りスループットを改善することが可能となる。
【０２４８】
（変形例４）
本変形例に係る受信側装置１００は、上述の変形例３に係る受信側装置１００と同様、各通信フローに対して拡大ウィンドウサイズを設定して通知するが、このとき、その通信フローの優先度に応じた拡大ウィンドウサイズを設定する。
【０２４９】
図１３は、本変形例に係る受信側装置１００の動作を説明するための説明図である。
【０２５０】
受信側装置１００は、例えば送信側装置２００ａ，２００ｂからデータを受信する処理を並列に行う。このとき、受信側装置１００の通信プロトコル処理部１３０は、送信側装置２００ａの通信フローに対する優先度と、送信側装置２００ｂの通信フローに対する優先度とを決定する。そして、通信プロトコル処理部１３０のウィンドウサイズ設定部１３３は、優先度の高い通信フローに対して大きな拡大ウィンドウサイズを設定し、優先度の低い通信フローに対して小さい拡大ウィンドウサイズを設定する。つまり、本変形例では、通信プロトコル処理部１３０が優先度決定手段として構成されている。
【０２５１】
例えば、通信プロトコル処理部１３０は、送信側装置２００ｂの通信フローに対して高い優先度を決定し、送信側装置２００ａの通信フローに対して低い優先度を決定する。この場合、ウィンドウサイズ設定部１３３は、送信側装置２００ｂの通信フローに対して例えば９６ＫＢの拡大ウィンドウサイズを設定する。一方、ウィンドウサイズ設定部１３３は、送信側装置２００ａの通信フローに対して例えば６４ＫＢの拡大ウィンドウサイズを設定する。
【０２５２】
通信プロトコル処理部１３０は、優先度を決定するときには、通信プロトコルや、中央制御部１４０で実行されているアプリケーションプログラムなどに基づいて優先度を決定する。例えば、通信プロトコル処理部１３０は、通信フローにおいてＦＴＰ（File Transfer Protocol）に従ったファイルの受信が行われる場合には、その通信フローに対して低い優先度を決定し、通信フローにおいてＨＴＴＰ（Hyper Text Transfer Protocol）に従った動画のストリーミング配信の受信が行われる場合には、その通信フローに対して高い優先度を決定する。
【０２５３】
このように、受信側装置１００は、複数の通信フローのそれぞれでデータの受信を並列して行うときには、そのときごとに、各通信フローに対する優先度を動的に決定し、拡大ウィンドウサイズを設定する。
【０２５４】
また、受信側装置１００は、送信側装置に対して静的な優先度を決定してもよい。この場合、受信側装置１００は、例えば、送信側装置２００ａに対して常に低い優先度を決定し、送信側装置２００ｂに対して常に高い優先度を決定する。したがって、受信側装置１００は、送信側装置２００ａ，２００ｂからデータを受信するときには、そのデータの内容や通信プロトコルに関わらず、送信側装置２００ａに対して小さい拡大ウィンドウサイズを設定し、送信側装置２００ｂに対して大きい拡大ウィンドウサイズを設定する。
【０２５５】
なお、上述の例では、受信側装置１００と複数の送信側装置のそれぞれとの間で複数の通信フローを設定したが、受信側装置１００と１つの送信側装置との間で複数の通信フローを設定してもよい。
【０２５６】
このように本変形例では、優先度に応じて、自在にスループットを制御することが可能となる。
【０２５７】
（変形例５）
本変形例に係る受信側装置１００は、上述の変形例３に係る受信側装置１００と同様、各通信フローに対して拡大ウィンドウサイズを設定して通知するが、このとき、その通信フローの数に応じた拡大ウィンドウサイズを設定する。
【０２５８】
図１４は、本変形例に係る受信側装置１００の動作を説明するための説明図である。
【０２５９】
受信側装置１００は、例えば、図１２に示すように、２つの送信側装置２００ａ，２００ｂからデータを受信する処理を並列に行う場合、送信側装置２００ａ，２００ｂの通信フローに対してそれぞれ６４ＫＢの拡大ウィンドウサイズを設定する。
【０２６０】
さらに、受信側装置１００は、例えば、図１４に示すように、４つの送信側装置２００ａ〜２００ｄからデータを受信する処理を並列に行う場合、送信側装置２００ａ〜２００ｄの通信フローに対してそれぞれ３２ＫＢの拡大ウィンドウサイズを設定する。
【０２６１】
このように、受信側装置１００は、送信側装置（通信フロー）の数が多くなるほど小さくなるような拡大ウィンドウサイズを設定する。
【０２６２】
なお、上述の例では、受信側装置１００と複数の送信側装置のそれぞれとの間で複数の通信フローを設定したが、受信側装置１００と１つの送信側装置との間で複数の通信フローを設定してもよい。
【０２６３】
このように本変形例では、通信フロー数に応じて、スループットを制御することが可能となる。
【０２６４】
（変形例６）
本変形例に係る受信側装置１００は、上述の変形例３に係る受信側装置１００と同様、各通信フローに対して拡大ウィンドウサイズを設定して通知するが、このとき、その通信フローの伝搬遅延時間に応じた拡大ウィンドウサイズを設定する。
【０２６５】
図１５は、本変形例に係る受信側装置１００の動作を説明するための説明図である。
【０２６６】
受信側装置１００は、例えば送信側装置２００ａ，２００ｂからデータを受信する処理を並列に行う。このとき、受信側装置１００の通信プロトコル処理部１３０は、送信側装置２００ａの通信フローに対する伝搬遅延時間と、送信側装置２００ｂの通信フローに対する伝搬遅延時間とを特定する。
【０２６７】
なお、伝搬遅延時間とは、ＲＴＴからバッファ内の遅延時間を差し引いた残りの時間の半分に相当する時間である。また、受信側装置１００が、変形例２の受信中継装置１００ａとして構成されているときには、上述の伝搬遅延時間は、送信側装置２００と受信中継装置１００ａとの間における時間であっても、送信側装置２００とデータ処理装置４００との間における時間であってもよい。
【０２６８】
そして、通信プロトコル処理部１３０のウィンドウサイズ設定部１３３は、例えば、伝搬遅延時間の長い通信フローに対して大きな拡大ウィンドウサイズを設定し、伝搬遅延時間の短い通信フローに対して小さい拡大ウィンドウサイズを設定する。これにより、各通信フローの通信時間を略均等にすることができる。
【０２６９】
例えば、通信プロトコル処理部１３０は、送信側装置２００ａの通信フローに対する伝搬遅延時間（１０ｍｓ）と、送信側装置２００ｂの通信フローに対する伝搬遅延時間（２０ｍｓ）とを特定する。
【０２７０】
この場合、ウィンドウサイズ設定部１３３は、送信側装置２００ａの通信フローに対して例えば３２ＫＢの拡大ウィンドウサイズを設定する。一方、ウィンドウサイズ設定部１３３は、送信側装置２００ｂの通信フローに対して例えば６４ＫＢの拡大ウィンドウサイズを設定する。
【０２７１】
通信プロトコル処理部１３０は、通信フローにおける伝搬遅延時間を特定するときには、例えばＰＩＮＧ（Packet INternet Groper）を利用することによりその伝搬遅延時間を計測する。
【０２７２】
このように、受信側装置１００は、複数の通信フローのそれぞれでデータの受信を並列して行うときには、そのときごとに、各通信フローに対する伝搬遅延時間を特定し、拡大ウィンドウサイズを設定する。
【０２７３】
なお、上述の例では、受信側装置１００は、伝搬遅延時間の長い通信フローに対して大きな拡大ウィンドウサイズを設定し、伝搬遅延時間の短い通信フローに対して小さい拡大ウィンドウサイズを設定したが、逆に設定してもよい。つまり、受信側装置１００は、伝搬遅延時間の長い通信フローに対して小さな拡大ウィンドウサイズを設定し、伝搬遅延時間の短い通信フローに対して大きな拡大ウィンドウサイズを設定する。これにより、伝搬遅延時間が短い通信フローの通信時間をできるだけ短くし、その通信フローの終了後、他方の通信フローに対して大きなウィンドウサイズを設定することができる。
【０２７４】
また、上述の例では、受信側装置１００と複数の送信側装置のそれぞれとの間で複数の通信フローを設定したが、受信側装置１００と１つの送信側装置との間で複数の通信フローを設定してもよい。
【０２７５】
このように本変形例では、伝搬遅延時間というネットワークの状況に応じて、スループットを制御することが可能となる。
【０２７６】
（変形例７）
本変形例に係る受信側装置１００は、上述の変形例３に係る受信側装置１００と同様、各通信フローに対して拡大ウィンドウサイズを設定して通知するが、このとき、その通信フローの伝送帯域に応じた拡大ウィンドウサイズを設定する。
【０２７７】
図１６は、本変形例に係る受信側装置１００の動作を説明するための説明図である。
【０２７８】
受信側装置１００は、例えば送信側装置２００ａ，２００ｂからデータを受信する処理を並列に行う。このとき、受信側装置１００の通信プロトコル処理部１３０は、送信側装置２００ａの通信フローにおける伝送帯域と、送信側装置２００ｂの通信フローにおける伝送帯域とを特定する。
【０２７９】
そして、通信プロトコル処理部１３０のウィンドウサイズ設定部１３３は、例えば、伝送帯域の広い通信フローに対して大きな拡大ウィンドウサイズを設定し、伝送帯域の狭い通信フローに対して小さい拡大ウィンドウサイズを設定する。これにより、パケットロスの発生を抑えることができる。
【０２８０】
例えば、通信プロトコル処理部１３０は、送信側装置２００ａの通信フローにおける伝送帯域（１０Ｍｂｐｓ）と、送信側装置２００ｂの通信フローに対する伝送帯域（２０Ｍｂｐｓ）とを特定する。
【０２８１】
この場合、ウィンドウサイズ設定部１３３は、送信側装置２００ａの通信フローに対して例えば３２ＫＢの拡大ウィンドウサイズを設定する。一方、ウィンドウサイズ設定部１３３は、送信側装置２００ｂの通信フローに対して例えば６４ＫＢの拡大ウィンドウサイズを設定する。
【０２８２】
通信プロトコル処理部１３０は、通信フローにおける伝送帯域を特定するときには、例えば、パケットロスが発生する帯域を見つけ出すことにより特定することができる。
【０２８３】
このように、受信側装置１００は、複数の通信フローのそれぞれでデータの受信を並列して行うときには、そのときごとに、各通信フローに対する伝送帯域を特定し、拡大ウィンドウサイズを設定する。
【０２８４】
また、受信側装置１００は、通信フローの通信媒体に対して静的な伝送帯域を特定してもよい。この場合、受信側装置１００は、例えば、光ファイバなどの通信媒体に対して常に広い伝送帯域を特定し、無線ＬＡＮなどの通信媒体に対して常に狭い伝送帯域を特定する。
【０２８５】
したがって、受信側装置１００は、無線ＬＡＮを介して通信する送信側装置２００ａからデータを受信するときには、常に小さい拡大ウィンドウサイズを設定し、光ファイバを介して通信する送信側装置２００ｂからデータを受信するときには、常に大きい拡大ウィンドウサイズを設定する。
【０２８６】
また、上述の例では、受信側装置１００と複数の送信側装置のそれぞれとの間で複数の通信フローを設定したが、受信側装置１００と１つの送信側装置との間で複数の通信フローを設定してもよい。
【０２８７】
このように本変形例では、伝送帯域というネットワークの状況に応じて、スループットを制御することが可能となる。
【０２８８】
（変形例８）
本変形例に係る受信側装置１００は、上述の変形例３に係る受信側装置１００と同様、各通信フローに対して拡大ウィンドウサイズを設定して通知するが、このとき、その受信用バッファメモリ１２０の空き容量に応じて拡大ウィンドウサイズを変更する。
【０２８９】
図１７は、本変形例に係る受信側装置１００の動作を説明するための説明図である。
【０２９０】
受信側装置１００は、例えば、図１２に示すように、送信側装置２００ａ，２００ｂからデータを受信する処理を並列に行う場合に、受信用バッファメモリ１２０の空き容量が１００ＫＢだけあると、送信側装置２００ａ，２００ｂの通信フローに対してそれぞれ６４ＫＢの拡大ウィンドウサイズを設定する。
【０２９１】
ここで、例えば、図１７に示すように、受信用バッファメモリ１２０に格納されたデータが中央制御部１４０に受け渡される速度が低下すると、その受信用バッファメモリ１２０の空き容量が少なくなり２０ＫＢになる。
【０２９２】
このとき、受信側装置１００は、例えば、送信側装置２００ａ，２００ｂの通信フローに対して設定されている拡大ウィンドウサイズ（６４ＫＢ）を３２ＫＢに一時的に変更する。
【０２９３】
このように、受信側装置１００は、受信用バッファメモリ１２０の空き容量が少なくなるほど小さくなるような拡大ウィンドウサイズを設定する。
【０２９４】
なお、受信側装置１００は、受信用バッファメモリ１２０の空き容量が閾値以下になったときに、各通信フローに対する拡大ウィンドウサイズを小さくしてもよい。ここで、受信側装置１００のウィンドウサイズ設定部１３３は、受信用バッファメモリ１２０の全体容量に対する割合によって上述の閾値を決定してもよい。例えば、ウィンドウサイズ設定部１３３は、受信用バッファメモリ１２０の全体容量の２０％に相当するサイズを閾値に決定する。また、ウィンドウサイズ設定部１３３は、ＲＴＴに応じて上述の閾値を決定してもよい。
【０２９５】
また、上述の例では、受信側装置１００と複数の送信側装置のそれぞれとの間で複数の通信フローを設定したが、受信側装置１００と１つの送信側装置との間で複数の通信フローを設定してもよい。
【０２９６】
このように本変形例では、受信用バッファメモリ１２０の空き容量に応じて、スループットを制御することが可能となる。
【０２９７】
以上、本発明の通信装置について、上記実施の形態およびその変形例を用いて説明したが、本発明はこれらに限定されるものではない。
【０２９８】
例えば、上記実施の形態およびその変形例では、停滞状態にある受信用バッファメモリ１２０に新たなデータパケットを格納するために、その受信用バッファメモリ１２０に格納されているデータパケットを廃棄したが、その受信用バッファメモリ１２０に新たなデータパケットを格納することができるようになる処理であれば、どのような処理を行ってもよい。例えば、受信用バッファメモリ１２０からデータパケットを退避させてもよく、再送されたデータパケットの到着時に上書する領域を作成してもよい。
【０２９９】
また、上記実施の形態およびその変形例では、受信用バッファメモリ１２０が停滞状態になったときにデータパケットを廃棄したが、受信用バッファメモリ１２０の空き容量が、０より大きい閾値以下になったときにデータパケットを廃棄してもよい。
【０３００】
また、上記実施の形態およびその変形例では、送信側装置２００がＳＡＣＫ対応の通信機能を有している場合には、廃棄パケットの再送を要求するため、その送信側装置２００に対してＳＡＣＫパケットを送信したが、さらに、ＴＤＡＣＫパケットを送信してもよい。これにより、送信側装置２００から廃棄パケットをより迅速に再送させることができる。
【０３０１】
また、上記実施の形態およびその変形例では、受信用バッファメモリ１２０の空き容量をウィンドウサイズとして示すＳＡＣＫパケットを送信したが、ＳＡＣＫパケットにより示されるウィンドウサイズは受信用バッファメモリ１２０の空き容量に依存していなくてもよい。
【０３０２】
また、上記実施の形態およびその変形例において、本発明に係る通信装置（受信側装置１００）は、図１８に示すように、例えば携帯電話として構成され、送信側装置２００は、例えばパーソナルコンピュータやサーバとして構成されてもよい。
【産業上の利用可能性】
【０３０３】
本発明の通信装置は、環境的な制約を受けることなく効率的にデータを転送することができるという効果を奏し、例えばパーソナルコンピュータや携帯電話、ネット家電など、ＴＣＰに基づく受信処理を行うあらゆる通信装置に適用可能である。
【図面の簡単な説明】
【０３０４】
【図１】図１は、特許文献１の送信側装置の構成を示す構成図である。
【図２】図２は、特許文献２の受信側装置の構成を示す構成図である。
【図３】図３は、本発明の実施の形態における受信側装置の構成の一例を示す構成図である。
【図４】図４は、同上の受信側装置と送信側装置との通信を示すシーケンス図である。
【図５】図５は、パケットロスによりデータ転送が停止してしまう様子を示すシーケンス図である。
【図６】図６は、本発明の実施の形態における、パケットロスが発生したときの受信側装置とＴＤＡＣＫ対応の送信側装置との間で行われる通信の一例を示すシーケンス図である。
【図７】図７は、同上の、パケットロスが発生したときの受信側装置とＳＡＣＫ対応の送信側装置と間で行われる通信の一例を示すシーケンス図である。
【図８】図８は、同上の受信側装置の全体的な動作を示すフローチャートである。
【図９】図９は、同上の受信側装置の復帰処理（図８のステップＳ１０４）における動作を示すフローチャートである。
【図１０】図１０は、同上の変形例１に係る受信側装置と送信側装置との間で行われる通信の一例を示すシーケンス図である。
【図１１】図１１は、同上の変形例２に係る受信中継装置の構成を示す構成図である。
【図１２】図１２は、同上の変形例３に係る受信側装置の動作を説明するための説明図である。
【図１３】図１３は、同上の変形例４に係る受信側装置の動作を説明するための説明図である。
【図１４】図１４は、同上の変形例５に係る受信側装置の動作を説明するための説明図である。
【図１５】図１５は、同上の変形例６に係る受信側装置の動作を説明するための説明図である。
【図１６】図１６は、同上の変形例７に係る受信側装置の動作を説明するための説明図である。
【図１７】図１７は、同上の変形例８に係る受信側装置の動作を説明するための説明図である。
【図１８】図１８は、同上の受信側装置および送信側装置の外観構成を示す図である。
【符号の説明】
【０３０５】
１００    受信側装置（通信装置）
１１０    通信制御部
１２０    受信用バッファメモリ
１３０    通信プロトコル処理部
１３１    送受信制御部
１３２    ＡＣＫ生成部
１３３    ウィンドウサイズ設定部
１３４    パケット廃棄部
１３５    再送要求部
１４０    中央制御部
１５０    メインメモリ
２００    送信側装置
３００    ネットワーク
【手続補正３】
【補正対象書類名】図面
【補正対象項目名】全図
【補正方法】変更
【補正の内容】
【図１】
2008023656.tif 000021
【図２】
2008023656.tif 000022
【図３】
2008023656.tif 000023
【図４】
2008023656.tif 000024
【図５】
2008023656.tif 000025
【図６】
2008023656.tif 000026
【図７】
2008023656.tif 000027
【図８】
2008023656.tif 000028
【図９】
2008023656.tif 000029
【図１０】
2008023656.tif 000030
【図１１】
2008023656.tif 000031
【図１２】
2008023656.tif 000032
【図１３】
2008023656.tif 000033
【図１４】
2008023656.tif 000034
【図１５】
2008023656.tif 000035
【図１６】
2008023656.tif 000036
【図１７】
2008023656.tif 000037
【図１８】
2008023656.tif 000038
【国際調査報告】
2008023656.tif 000039
2008023656.tif 000040