JP2007110680A - 通信装置、通信プログラム、通信制御方法および記録媒体 - Google Patents

Abstract

【課題】低資源の装置であっても、余剰なトラフィックを抑制し、必要最小限のメモリ量で、ＣＰＵ負荷の少ないＴＣＰのＷｉｎ制御方式を実現すること。
【解決手段】通信装置は、受信したデータパケット数と固定サイズに基づいて算出されるバッファサイズと、受信したデータサイズにより算出されるバッファサイズを比較し、比較の結果、前記受信したデータパケット数と固定サイズに基づいて算出されたバッファサイズの方が小さい場合、前記算出されたバッファサイズを告知ウィンドウサイズとして設定し、通信相手装置にＡＣＫを送信する。
【選択図】図９

Description

本発明は、ネットワークを介して、ＴＣＰ／ＩＰプロトコルを用いて通信を行なう通信装置、通信プログラム、通信制御方法および記憶媒体に関するものである。

通信プロトコルとしてＴＣＰ／ＩＰプロトコルが広く用いられている。ＴＣＰ／ＩＰプロトコルを用いた通信では、多くの場合、通信装置において階層的に処理が行なわれる。

非特許文献１では、通信処理における階層モデル（ＯＳＩ参照モデル）として、物理層、データリンク層、ネットワーク層、トランスポート層、セッション層、アプリケーション層の７階層が定義されている。ＴＣＰ／ＩＰがよく用いられているＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）などでは、物理層、および、データリンク層として、Ｅｔｈｅｒｎｅｔ（登録商標）が多く用いられている。データリンク層をＭＡＣ層と呼ぶこともある。ＴＣＰ／ＩＰでは、ネットワーク層としてＩＰｖ４やＩＰｖ６等のプロトコル（以下単にＩＰ）を、トランスポート層としてＴＣＰを用いる。また、多くの場合、セッション層は、ソケットＡＰＩ呼ばれるＡＰＩとして定義できる。

ＭＡＣ層において用いられる電文形式をＭＡＣフレームと呼ぶ。また、ＩＰにおいて用いられる電文形式をＩＰパケットと呼ぶ。さらに、ＴＣＰにおいて用いられる電文形式をＴＣＰセグメントと呼ぶ。さらに、アプリケーション層で送受信するデータをアプリケーションデータと呼ぶ。なお、本明細書中では、アプリケーションデータサイズが０の場合も、ＴＣＰセグメントに含める。尚、以下ではＭＡＣフレーム、ＩＰパケット、ＴＣＰセグメントの全部又は一部を総称して、単にデータパケットと呼ぶ。

ＴＣＰセグメントの送信時において、通常、１つのＴＣＰセグメントは１つのＩＰパケットに格納される。ＩＰパケットは、通常１つ、あるいは必要に応じて複数のＭＡＣフレームに分割されて格納される。受信時において、通常１つ、あるいは必要に応じて複数のＭＡＣフレームからＩＰパケットが抽出され、ＩＰパケットからＴＣＰセグメントが抽出される。さらに、ＴＣＰセグメントからアプリケーションデータが抽出される。なお、ここでは、各層において、他のプロトコル、例えば、トランスポート層においてＵＤＰを使用する通信が混在した場合などは省略する。

ＴＣＰは、通信装置間において、送信側装置から送出されたＴＣＰセグメントが何らかの影響で正常に送達できなかった場合でも、再送機能により、確実なデータの転送を実現するプロトコルである。

また、ＴＣＰは、通信装置間のネットワークにおいて、無駄なトラフィックの増大を抑制するためのウィンドウ制御と呼ばれるフロー制御機能を持つ（例えば、非特許文献２参照。）。

＜ＴＣＰの動作概要＞
図２４は、ネットワーク３を介して接続された２つの通信装置１、通信装置２の間において、一方の通信装置２から他方の通信装置１へデータを転送する例を示した図である。以降の説明では、通信装置２はデータを送信する装置であり、通信装置１は、通信装置２が送信したデータを受信する装置とする。

通信装置２から通信装置１へデータを転送する場合、データに転送のための情報を付加したデータパケットを使用する。この１つのデータパケットに格納できるデータのサイズは、フレームの最大転送サイズを指定するＭＴＵや、ＴＣＰセグメントについての最大量（最大セグメントサイズ。以降、ＭＳＳ）によって規制される。ＭＴＵは、通信装置が接続するインタフェースメディアの種類に従って、例えばＥｔｈｅｒｎｅｔ（登録商標）の場合は１５００ｂｙｔｅが初期状態として設定される。

ＭＳＳは、ＴＣＰ通信の最初の通信路（コネクション）確立時に決定され、より具体的には、通信装置１と通信装置２がお互いに自身のＭＳＳをＴＣＰセグメントに乗せて通知し、通信装置２が小さい方のＭＳＳに決定する。ＴＣＰコネクション確立後、通信装置２から通信装置１へ実際にデータを転送できる状態となるが、転送するデータがＭＳＳを超える場合などにおいては、複数のパケットに分割して格納し、通信装置２から通信装置１に送られる。このパケットには、格納したデータを識別するための情報であるシーケンスナンバー（以下、Ｓｅｑ）、ＴＣＰのデータ長（以下、ＬＥＮ）、および、次に受信すべきデータのシーケンス番号を示す確認応答番号（以下、Ｎｕｍ）などが含まれる。

通信装置１はデータパケットを受信した場合、所定のタイミングにより、所定のシーケンス番号を含むＴＣＰセグメントを受信したことを示すＡＣＫ（ＡＣＫｎｏｗｌｅｄｇｅｍｅｎｔ：応答確認パケット。以下、単にＡＣＫ）を通信装置１が全て受け取ったか否かを、通信装置２が確認することを可能としている。通信装置２が送信したデータパケットが、何らかの影響で通信装置１が正常に受信できず（以下、パケットが消失したと表現する）、その結果、通信装置２が送信したパケットに対する通信装置１からのＡＣＫを受信しなかった場合、通信装置２は、該当するパケットを再送する。これにより、確実に全てのデータを転送することを可能としている。このとき、再送の間隔を制御するために、通信装置２がデータを送ってから、ＡＣＫを受信するまでにかかる時間をＲＴＴ（ＲＯＵＮＤ ＴＲＩＰ ＴＩＭＥ）として定義し、用いる場合がある。なお、一般的にＲＴＴは1つのパケットが送信元から宛先まで行き、再び戻ってくるまでに要する時間のことを指す。

さらにＴＣＰのウィンドウ制御について説明を行なう。ＴＣＰでは、受信側から送信側へ通知する、告知ウィンドウ（ＴＣＰ Ｗｉｎｄｏｗ。以下、Ｗｉｎ）という概念を取り入れており、通信装置１（データを受信する装置）は、ＡＣＫの１つのパラメータとしてＷｉｎを含めることにより、ＡＣＫを送信する時点にて、受信可能なデータ量を通信装置２（データを送信する装置）に通知する。通信装置１がＡＣＫのパラメータとして含める告知ウィンドウの大きさのことを告知ウィンドウサイズといい、ウィンドウサイズは送信側装置がＡＣＫを待たずに送信できるデータの大きさを示す。このことにより、通信装置２から送信されるＴＣＰセグメントのデータ量を制御し、通信装置１によって受信できないために無駄となるパケットがネットワークに流れ、ネットワークの通信許容量が低下することを防ぐことができる。非特許文献２では、「Ｗｉｎは、通信装置１に現在受信する準備がされているオクテットの数（確認番号から始まる）を示している」、と記載されている。

通常、受信装置のウィンドウ制御では、コネクション毎の受信バッファの残りデータサイズをＷｉｎとして決定し、このＷｉｎを含め送出することによりＴＣＰ通信でのフロー制御を行う。

図２５は、従来のＴＣＰの受信側でのウィンドウ制御の概要について、図２４の例を用いて説明する図である。

ここでは、説明を簡略化するために１つのデータパケット内に格納されるＴＣＰセグメントのデータ長（以下、ＬＥＮ）を１０００にし、ＳｅｑやＷｉｎの単位や値も、これに合わせている。通信装置２はアプリケーションデータを受信しないこととすることにより、ＴＣＰヘッダのパラメータの１つである、要求する次のＡＣＫＮｕｍｂｅｒ（以下、Ｎｕｍ）において、通信装置２から送信されるＡＣＫのＮｕｍは常に固定値であるため、省略する。これらの実際の値は、通信装置や通信装置間の伝送路の特性に依存し、ＴＣＰの接続時において決定されるが、この説明は省略する。

また、図２５は通信装置２と通信装置１とのＴＣＰ接続時のコネクション設立後、通信装置１がいくつかのパケットを受信し、そのパケットが処理途中であり、受信する準備がされているオクテットの数（パケットバッファの受信可能データサイズ）が少なくなっている（Ｗｉｎ＝６０００）状態を示している。

通信装置２のＷｉｎ状態を図２５の左側に示す（Ｗ２１、Ｗ２２）。Ｗｉｎ状態内の数値は、Ｓｅｑを示しており、１０００ｂｙｔｅ分のＷｉｎを示す。例えば、「１」であれば、１００１から２０００まで、「２」であれば、２００１から３０００までのＳｅｑを表現している。Ｗｉｎ状態で番号の表示のない網掛け部分は、送信できない、またはＡＣＫを受信して送信済みであるＳｅｑであり、番号が表示されている部分は送信可能なＳｅｑを示す。例えば、Ｗ２２は、Ｓｅｑ１００１から２０００、Ｓｅｑ２００１から３０００のデータは、既に送信済みであり、かつ、通信装置１からそれらに対するＡＣＫを受信済みであり、Ｓｅｑ３００１から９０００までのパケットを送信可能であり、それ以降のＳｅｑを持つパケットは送信できないことを示している。

（１）Ｗｉｎの通知
受信側装置である通信装置１は、次に受信すべきデータのシーケンス番号を示す確認応答番号（以下、Ｎｕｍ）と、Ｗｉｎを通信装置２に通知する（Ｐ１１）。ここでは、Ｎｕｍを１００１、図示しないＰ１１以前の状態から、Ｗｉｎを６０００としたとする。

（２）Ｗｉｎの設定とデータ送信
Ｗｉｎを受信した通信装置２は、通知されたＮｕｍからＷｉｎ分進んだ箇所までを、送信側で送信可能なウィンドウとして設定する（Ｗ２１）。この場合、Ｓｅｑ１から６０００までに設定する。通信装置１の要求するシーケンス番号（以下、Ｓｅｑ）のデータから順に、Ｗｉｎを超えない範囲でデータを送信する。ここでは、Ｗｉｎは６０００としたので、最大、Ｓｅｑが１００１から６０００までＡＣＫを受信するまでに送信することができる。ここでは、Ｓｅｑ１００１から２０００、Ｓｅｑ２００１から３０００のパケットを送信したこととする（Ｐ２１、Ｐ２２）。

（３）データ受信とＷｉｎの更新、通知
通信装置１は、受信したパケットに含まれるＳｅｑまでのデータを受信したら、自身のウィンドウを受信バッファの残りバッファサイズに基づいて更新し、受信可能なデータ量を確認する。ここでは、Ｓｅｑ３０００まで受信し、受信したパケットは全て処理完了していることとすると、Ｎｕｍは３００１、後述するウィンドウ制御により残りバッファサイズに基づいてＷｉｎを６０００と決定する。通信装置１は、上記で設定したＮｕｍとＷｉｎを含めたＡＣＫを通信装置２に送信する（Ｐ１２）。

（４）送信側Ｗｉｎの更新
通信装置２は、受信したＮｕｍとＷｉｎにより、送信側自身の輻輳制御用の送信ウィンドウを更新する（Ｗ２２）。ここでは、Ｓｅｑ３００１から９０００までに設定する。この後、Ｓｅｑ３００１から順にデータを送信することが可能になる。

以上のように受信側装置ではウィンドウ制御を行い、送信側装置から送出されるＴＣＰセグメントのデータ量の制御を実現するＴＣＰ通信でのフロー制御を可能としている。

次に、通信装置内におけるパケットの受信処理の概要を示す。

＜パケット受信処理の概要＞
図２４の通信装置１のハードウェアに関するブロック図の一例について説明する。上記と同様、通信装置１は、データの受信を行なう装置である。図２４ではシステムバス１１上にＮＩＣ（Ｎｅｔｗｏｒｋ Ｉｎｔｅｒｆａｃｅ Ｃａｒｄ）１２、ＣＰＵ１３、メモリ１４が接続されている。

ＮＩＣ１２はＭＡＣ（Ｍｅｄｉａ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ）機能を持っており、ネットワーク３から受信したパケット１０を一時的に保持するＦＩＦＯ（Ｆｉｒｓｔ−Ｉｎ Ｆｉｒｓｔ−Ｏｕｔ）メモリ１５を持つ。

通信装置１はネットワーク３から例えばＥｔｈｅｒｎｅｔ（登録商標）などの有線ケーブルを通して受信したパケット１０を一時的にＮＩＣ１２のＦＩＦＯメモリ１５に蓄積し、蓄積されたパケットはＣＰＵ１３によって、ＮＩＣ１２のＦＩＦＯメモリ１５からシステムのメモリ１４にシステムバス１１を通して移動される。

なお、上記ＮＩＣ１２のＦＩＦＯメモリ１５からメモリ１４への移動において、別途ＤＭＡコントローラを具備し、ＣＰＵではなく、ＤＭＡコントローラにより移動される場合もある。

図２６に、図２４に示した通信装置１におけるＴＣＰセグメントの受信処理の概要を示す。通信装置の機能構成は、アプリケーション２０、プロトコルスタック３０及び物理４０の各レイヤに大別できる。

アプリケーションレイヤ２０の機能は、通信装置１上で動作するアプリケーションにより実現される。

物理レイヤ４０は、ＮＩＣ１２の有する機能（ＭＡＣ機能）により実現される。

プロトコルスタック３０は、ＴＣＰ３１、ＵＤＰ３２、ＩＣＭＰ３３などのプロトコルを実現する機能部、および、ＩＰ３４、Ｉｎｔｅｒｆａｃｅ３５から構成される。

ＩＰ３４は、送信するデータにＩＰヘッダを付与したり、受信したＩＰパケットを分解し、ＴＣＰ、ＵＤＰ、ＩＣＭＰなどの各プロトコル機能部に渡したりする。

ＴＣＰ機能部３１は、前述したウィンドウ制御を行ってＷｉｎを決定するウィンドウ制御部３８を有する。

Ｉｎｔｅｒｆａｃｅ３５は、ＩＰ３４から渡されるデータにＥｔｈｅｒヘッダを付与して物理レイヤ４０を実現するハードウェアであるＮＩＣ１２に渡したり、ＮＩＣ１２から渡されたデータパケットから、Ｅｔｈｅｒヘッダを取り除いたりする。

また、プロトコルスタック３０において、パケットは、パケットバッファ３６と呼ばれるメモリで管理される。パケットバッファ３６は、図２４に示したメモリ１４に含まれる。通常、パケットバッファ３６は、メモリ取得・解放のオーバーヘッドを減らすため固定長ブロックメモリで管理されている。一般的に固定長ブロックのサイズとして、ＭＳＳ付近に設定されることが多い。

ソケットキュー３７は、プロトコル処理が完了したパケット１０をアプリケーションデータとして、アプリケーションが受信処理を行なうまで、一時的にパケットバッファに格納した状態で保持するＦＩＦＯ（Ｆｉｒｓｔ−Ｉｎ Ｆｉｒｓｔ−Ｏｕｔ）メモリである。なお、ここでは、データをパケットバッファに格納した状態でソケットキュー３７に保持していると説明したが、実装によっては、他の別のメモリ領域を使用して、ソケットキューに保持する方法、パケットバッファに格納してソケットキューに保持しておく方法や、パケットバッファを使用しつつ、データコピーを行なう方法がある。

アプリケーション２０は、プロトコルスタック３０により処理され、ソケットキュー３７に保持されているデータを受信する。

ＮＩＣ１２から移動されたパケット１０は、システムバス１１を介して、プロトコルスタック３０内に移動され、パケットバッファ３６に格納される。パケット１０は、プロトコルスタック３０内では、常にパケットバッファ３６に格納されてヘッダ処理、プロトコル処理が行われる。この例において、パケット１０は、ＴＣＰセグメントであるため、ＴＣＰのプロトコル処理が完了した後、パケットバッファ３６に格納された状態で、ソケットキュー３７に保持される。

ソケットキュー３７に保持されたパケット１０は、アプリケーション２０により任意のタイミングで受信され、パケットバッファ３６は、受信された後、開放され、新たなパケットのために使用することが可能となる。

＜ＴＣＰ通信中の通信装置内の処理と、Ｗｉｎ通知＞
図２７に従来の受信側ウィンドウ制御による、送信側への送信抑制を示した図であり、通信装置１が、通信装置２からネットワークを介して、送信されるパケットＰ１、Ｐ２、Ｐ３に含まれるデータを受信する例を示している。

尚、図２７では、通信装置２と通信装置１とのＴＣＰ接続時のコネクション設立に至るまでの通信のシーケンスを省略する。

図２７において、ＡＣＫｚ（ｘ，ｙ）は、受信側装置である通信装置１が送信するＡＣＫを示す。Ｐｚ（ｘ，ｙ）は、送信側装置である通信装置２が送信するデータを含むデータパケットを示す。ｘは、通信装置１が受信可能なＷｉｎを示し、ｙは１パケットに含まれるデータサイズ（以下、ＬＥＮ）を示す。また、ｚは、通信装置１、通信装置２が送信した順番に別々の値を付与する。

また、通信装置１は、受信可能なＷｉｎを含むＡＣＫを通信装置２へ送信するが（ＳＴ１）、ここでは、通信装置１における１つのパケットバッファのサイズが１５００ｂｙｔｅ、ＭＳＳサイズを１４６０ｂｙｔｅとし、図示しないＳＴ１以前の状態から、Ｗｉｎ（図２７中のＷ）として３×１４６０ｂｙｔｅを通知したこととする。

また、通信装置１は、通信装置１と通信装置２とのＴＣＰコネクションのために、最大保持データ量Ｄｍａｘ（例として８０００ｂｙｔｅ）のサイズの受信バッファを持つとする。

まず、通信装置２は、ＡＣＫ１を受信する。通信装置２は、通信装置１に対してＡＣＫ内に示されたＷｉｎ（３×１４６０ｂｙｔｅ）までのデータが送信可能であることを識別する。

次に、通信装置２は、Ｐ１〜Ｐ３までのデータパケットを送出する。ここで、送信側装置である通信装置２は、スロースタート等の送信側輻輳制御との関係で、必ずしも受信した全てのＷｉｎサイズのＴＣＰセグメントを送出する必要はなく、ここでは、ＬＥＮが１４６０ｂｙｔｅのパケットＰｚ（ｚ＝1〜３）を送信することとする。

次に、通信装置１は、Ｐ１〜Ｐ３までのデータパケットをネットワーク３を通して受信する。通信装置１は、受信したデータパケットＰ１〜Ｐ３をＮＩＣ１２にて一時的にＦＩＦＯメモリ１５に格納する。図２７には図示しないＣＰＵ１３は、任意のタイミングでパケットバッファに格納して、プロトコルスタックにパケットを移動する。このとき、受信したパケットは、１パケットごとにパケットバッファ３６に格納される。

パケットバッファ３６に格納されたパケットは、プロトコルスタック３０において、各々のデータパケットＰ１〜Ｐ３について、データパケット毎にヘッダ処理、プロトコル処理を行い、ソケットキュー３７にアプリケーションデータとして保持され、アプリケーション２０が受信するのを待つ（ＳＴ２、ＳＴ３、ＳＴ４）。

次に、通信装置１は、Ｗｉｎ制御部３８によって現在の受信可能なデータサイズに基づいてＷｉｎとして算出し告知するウィンドウサイズＷａｄを決定する。このＷａｄを含むＡＣＫ２を通信装置２へ送信する（ＳＴ５）。現在受信可能なデータサイズＷｄは、一例として図２８に示すように、最大保持データ量Ｄｍａｘから実受信データ量Ｄｃｕｒを減算することにより算出される。

ＳＴ５では、最大保持データ量Ｄｍａｘと受信したＰ１〜Ｐ３についての実受信データ量Ｄｃｕｒの差分、Ｄｍａｘ−Ｄｃｕｒであり、Ｗｄ＝（８０００−１４６０×３）ｂｙｔｅである。

アプリケーション２０は、任意のタイミングでソケットキュー３７からデータパケットＰ１〜Ｐ３より抽出されたデータを受信し、アプリケーションがソケットキューから受信したサイズ分、ウィンドウ制御部の保持するＷｉｎの値を大きくし、データを受信したパケットバッファを開放する（ＳＴ６）。

以上のような処理を繰り返し、受信側装置である通信装置１は、ＴＣＰ通信時におけるＷｉｎ制御を行なう。

このように、従来のＴＣＰを用いた通信における受信側装置のウィンドウ制御は、所定の時間に受信したデータのサイズに基づくものであり、受信側装置の受信バッファが受信することができる残りのデータサイズに基づいてウィンドウサイズを決定していた。
「マスタリングＴＣＰ／ＩＰ 入門偏 第３版」、竹下隆史、村山公保、荒井透、苅田幸雄［平成１４年２月２５日］ 標準仕様書「ＲＦＣ７９３」、ＩＥＴＦ、［平成１７年５月１８日検索］、インターネット＜ＵＲＬ：ｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ｒｆｃ／ｒｆｃ７９３．ｔｘｔ＞

しかしながら、従来の受信データのサイズに基づく受信側ウィンドウ制御を、ネット家電のようにＣＰＵが低速な装置やメモリ資源が少ない装置（以下、低性能な装置）に適用した場合、装置が多量のショートパケットを受信するときなどの受信側装置の処理負荷が増加するときに、送信側に対するフロー制御が充分でないことがある。

例えば、図２７では、通信装置２は１４６０ｂｙｔｅのデータパケットを送信した例を示したが、通信装置２の送出するＴＣＰセグメントのサイズは、必ずしもＭＳＳに近いＴＣＰセグメントを含むパケットではなく、実際にはアプリケーションの実装方法や、Ｎｏ Ｄｅｌａｙ送信、もしくは、極端に小さいデータサイズのパケット（以降、ショートパケット）のＤｏＳ攻撃などにより、ショートパケットが多量に送信されることがある。

送信されたショートパケットを多量に受信すると、受信側装置では、各々のデータパケットに対して、前述したようにＮＩＣでのデータパケット受信からアプリケーション部でのアプリケーションデータの抽出までの処理が必要となる。

ショートパケットを多量に受信した際に、通信装置に従来のウィンドウ制御を適用すると、受信側装置は前述のパケット毎の処理により多くのパケット処理が完了していないにもかかわらず、受信バッファの残りデータサイズ（Ｄｍａｘ−Ｄｃｕｒ）は依然として大きいこととなる。従って送信側に通知する告知ウィンドウサイズは大きいものとなってしまい、結果としてこの告知ウィンドウサイズの通知を受けた送信側装置は、通知された告知ウィンドウサイズに見合うサイズや数のデータパケットを送出する。

このような場合には、受信側の状態を反映したフロー制御が充分に行われていない。

このため、受信側装置のデータパケット受信状況を適切に反映した告知ウィンドウサイズを送信側装置に通知することが望ましい。

前記従来の課題を解決するために、本願発明は、通信装置であって、データパケットを受信するパケット受信部と、受信したパケットを保持するパケット保持部と、告知ウィンドウサイズを決定するウィンドウ制御部と、決定された前記告知ウィンドウサイズを含め、受信したデータパケットに対応したＡＣＫを生成するＡＣＫ生成部と、生成された前記ＡＣＫをデータパケットに含めて送出するデータパケット送出部と、を含み、前記ウィンドウ制御部は、保持データパケット数と固定サイズとに基づいて告知ウィンドウサイズを決定することを特徴とする。

本発明の通信装置は、受信装置の保持データパケット数に基づいて、送信側装置からの余剰なトラフィックを抑制することができるフロー制御を実現することができる。

以下本発明の実施の形態について、図面を参照しながら説明する。

（実施の形態１）
図２に、本発明の一実施の形態に係るネットワーク構成例および通信装置のハードウェア構成例を示す。

＜＜ネットワーク構成＞＞
通信装置１および通信装置２はネットワーク３と有線または無線で接続する通信機能を持つ装置であり、例えば、Ｅｔｈｅｒｎｅｔ（登録商標）インタフェースを備えた装置（例えばＰＣや、ネットワーク通信が可能な家電装置など）である。

ネットワーク３は有線または無線を含むネットワークであり、インターネットなどの公衆ネットワーク、インターネットＶＰＮなどのプライベートネットワーク、家電製品を相互に接続するホームネットワークなどが例として挙げられる。

実施の形態１では、通信装置１と通信装置２の間でＴＣＰのコネクションを確立し、通信装置２から通信装置１にデータを送信する。ここで、ＴＣＰのコネクションにおけるデータ送信の関係において、データ送信元の通信装置２を送信側装置、データ送信先の通信装置１を受信側装置と呼ぶ。例えば、ＦＴＰ（Ｆｉｌｅ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）サーバである送信側装置（例えばＰＣ）からＦＴＰクライアントとして動作するアプリケーションが動作する受信側装置がファイルをダウンロードする場合や、ＰＯＰ（Ｐｏｓｔ Ｏｆｆｉｃｅ Ｐｒｏｔｏｃｏｌ）サーバである送信装置から、電子メールを扱うアプリケーションが動作する受信側装置で電子メールを受信する場合などが想定できる。

本実施の形態では、通信装置１を本発明の一実施の形態に係る通信装置として説明を行なう。なお、通信装置２は、送信側装置として、本発明が適用されていない従来のウィンドウ制御を行う通信装置であってもよいし、本発明が適用された受信処理の機能部を持つ通信装置であってもよい。

＜＜通信装置の機能構成図＞＞
以下、通信装置１の本発明の一実施の形態が係る機能構成について、図２を用いて説明を行なう。

（ａ）ＮＩＣ１２：
ＮＩＣ１２は、システムバス１１上に接続されたハードウェアである。ＣＰＵ１３によって渡されたデータをネットワーク３に送信する機能とネットワーク３から受信したデータを受信する機能を有する。ネットワーク３から受信したデータを一時的に保持したり、ＣＰＵ１３から渡されたデータを一時的に保持したりするＦＩＦＯメモリ１５をもつ。なお、ＦＩＦＯメモリは、受信用ＦＩＦＯメモリと送信用ＦＩＦＯメモリが独立していても良い。

（ｂ）ＣＰＵ１３：
ＣＰＵ１３は、ＮＩＣ１２のＦＩＦＯメモリ１５に格納されたデータをメモリ１４に移動する（読み出し）機能と、メモリ１４に格納されているデータをＮＩＣ１２のＦＩＦＯメモリ１５に移動する（書き込み）機能をもつ。また、メモリ１４に格納さているデータに対してデータの解析や送信用データの作成処理など、ＴＣＰを含むプロトコル処理も行なう。また、通信アプリケーションや、必要に応じてその他のプログラムをメモリ１４を使用しながら実行する機能を持つ。

（ｃ）メモリ１４：
送信するデータ、および、受信するデータを含む、データを保持する機能を持つ。

なお、メモリ１４とＮＩＣ１２のＦＩＦＯ１５間におけるデータの転送は、別途ＤＭＡコントローラを具備し、ＣＰＵではなく、ＤＭＡコントローラにより転送を行なう場合もある。

なお、各プロトコル処理は、ＣＰＵ１３により実施されるのではなく、別途ハードウェアでそれぞれ実施されてもよい。

以下、通信装置１について、図２で示した構成例におけるＣＰＵ１３で実施されるプログラムを例として図３を用いてさらに詳細に説明を行なう。

図２に示した機能構成は、図１に示したＣＰＵ１３上で動作するソフトウェアとして実現可能である。なお、図２の構成図は、受信側装置として、本発明に係るＴＣＰデータの受信処理を中心として記載しているが、ＴＣＰデータの送信処理を行なうための他の機能部を具備していてもよい。

以下、各機能部の説明を記述するにあたり、本発明が係る受信処理についてのみ詳細に記述し、ＴＣＰデータ送信処理に係る機能および動作の説明は省略する。

なお、図３においては、データの流れをいくつかの種類の線を用いてあらわしている。実線はパケットまたはデータの流れを示すデータフロー、点線は制御信号（通知またはパラメータ）の流れを示す制御フローである。

図３において、通信装置１は、ネットワーク部１３００と、プロトコルスタック部１２００と、アプリケーション部１１００から構成される。

ネットワーク部１３００は、ネットワーク３からデータパケットを受信する。本実施の形態では、ネットワーク部はＭＡＣ処理部を有し、ネットワーク３から受信したパケットについてＭＡＣ処理を行い、ＦＩＦＯメモリ１５に保持しておく機能、および、プロトコルスタック部１２００から渡されるパケットに対して、ＭＡＣ処理を行い、ネットワーク３へ送信する機能を持つ。

プロトコルスタック部１２００は、ネットワーク部１３００より受信するデータパケットまたはネットワーク部１３００へ送信するデータパケットを処理する機能部であり、その詳細な構成として、パケットバッファ管理部１４００、ＡＰＩ部１２１０、ＴＣＰ処理部１２２０、ＩＰ処理部１２３０、Ｉｎｔｅｒｆａｃｅ処理部１２４０、を有している。

ＴＣＰ処理部１２２０は、受信データ管理部１２２１、Ｗｉｎ制御部１２２２、ＡＣＫ生成部１２２４、ＴＣＰ送信部１２２５、およびＴＣＰ受信部１２２６を有する。なお、通信装置１には、ＵＤＰプロトコル、ＩＣＭＰプロトコル、ＩＣＭＰｖ６プロトコルなどの処理を行なう機能部を有してもよい。

アプリケーション部１１００は、プロトコルスタック部との間で、アプリケーションデータを受信および送信することにより、ＦＴＰなどのアプリケーション処理を行なう機能を持つ。

（１）パケットバッファ管理部１４００
パケットバッファ管理部１４００は、通信装置全体の使用可能パケットバッファ数ＳＰＢｅｎを管理しており、パケットバッファの開放処理、獲得処理を行なう。パケットバッファは、アプリケーションデータやネットワークからの受信データを所定の単位で格納するものであり、ＴＣＰヘッダやＩＰヘッダも含むことが可能なメモリ管理単位である。管理するデータの実体は、図２のメモリ１４に配置される。なお、パケットバッファだけでなく、図２に記載のメモリ１４を管理している機能部に対して、使用可能な領域があるか、否かを問い合わせて、使用可能な領域があれば、それをパケットバッファとして利用する機能を持っていてもよい。なお、パケットバッファは、メモリ取得・解放のオーバーヘッドを減らすためには、固定長ブロックメモリで管理されることが望ましいが、可変長ブロックメモリであっても構わない。

（２）ＡＰＩ部１２１０
ＡＰＩ部１２１０は、アプリケーション部１１００とＴＣＰ処理部１２２０との間の要求・データの受け渡し、および、その処理完了の通知を行なう機能部である。アプリケーション部１１００の保有する機能としては例えばＦＴＰクライアントなどが挙げられる。アプリケーション部１１００からのデータ受信要求に応じて、ＴＣＰ処理部１２２０にデータの受け渡しを要求し、ＴＣＰ処理部１２２０から渡されたデータを、アプリケーション部１１００が処理できるように必要に応じて変換やコピーを行ない、その処理の完了をＴＣＰ処理部１２２０に通知する。なお、データ送信に関する記述は省略する。

（３）ＴＣＰ処理部１２２０
ＴＣＰ処理部１２２０は、ＩＰ処理部１２３０から受け取ったＴＣＰセグメントから、ＡＰＩ部１２１０に渡すアプリケーションデータに変換する機能部である。ＴＣＰ処理部１２２０はソケットキューを管理する。ソケットキューは、コネクションごとに管理されるパケットバッファ管理のためのリストであり、ＡＰＩ部１２１０、および、ＩＰ処理部１２３０とのデータの受け渡しのために一時的にデータを保持する。また、ＴＣＰ処理部１２２０は、ＴＣＰ通信の開始・終了（コネクションの確立・切断）に応じて、ソケットキューの作成、削除を行なう。ＴＣＰ処理部１２２０は、ＩＰ処理部１２３０からパケットバッファを受け取り保持し、受け取った一つ、あるいは、複数のデータパケットに含まれるデータを抽出し、送信元アドレス、宛先アドレス、送信元ポート、宛先ポートなどを基に、対応するＴＣＰ通信の単位（コネクション）に対するソケットキューにパケットバッファを関連付ける。また、ＡＰＩ部１２１０からのデータの受け渡し要求に応じて、コネクションに対するソケットキューに関連付けられたパケットバッファから、該当するデータを受け渡し、パケットバッファをソケットキューから関連付け解除し、パケットバッファを開放する。また、ＩＰ処理部１２３０から受け取ったＴＣＰセグメントに対するＡＣＫを作成しＩＰ処理部１２３０に受け渡す。なお、ＴＣＰデータ送信に関する記述は省略する。

（４）ＩＰ処理部１２３０
ＩＰ処理部１２３０は、Ｉｎｔｅｒｆａｃｅ処理部１２４０から受け取ったＩＰパケットが格納されたパケットバッファからＴＣＰセグメントが格納されているものを抽出し、ＴＣＰ処理部１２２０に受け渡す機能部である。また、ＴＣＰ処理部１２２０から受け取った、ＴＣＰセグメントが格納されているパケットバッファにＩＰヘッダを追加してＩＰパケットを構築し、Ｉｎｔｅｒｆａｃｅ処理部１２４０に受け渡す。なお、ＴＣＰ以外のプロトコルであるＵＤＰなどの処理を行ってもよい。

（５）Ｉｎｔｅｒｆａｃｅ処理部１２４０
Ｉｎｔｅｒｆａｃｅ処理部１２４０は、ＭＡＣ処理部１３１０から受け取ったＭＡＣフレームからＩＰパケットを抽出し、パケットバッファ管理部１４００にパケットバッファ獲得要求を行い、パケットバッファにＩＰパケットを格納し、ＩＰ処理部１２３０に受け渡す機能部である。また、ＩＰ処理部１２３０から受け取った、ＩＰパケットが格納されているパケットバッファにＭＡＣヘッダを追加してＭＡＣフレームを構築しＭＡＣ処理部１３１０に受け渡す。

（６）ＭＡＣ処理部１３１０
ＭＡＣ処理部１３１０は、図２に示したＮＩＣ１２が受け取ったデータをＩｎｔｅｒｆａｃｅ処理部１２４０に受け渡す機能部である。この処理は、図２のＮＩＣ１２のＦＩＦＯメモリ１５から図２のメモリ１４にデータを渡す（読み出し）処理である。また、Ｉｎｔｅｒｆａｃｅ処理部１２４０から受け取ったＭＡＣフレームをＮＩＣ１２に渡す機能部である。この処理は、図２のメモリ１４からＮＩＣ１２のＦＩＦＯメモリ１５に渡す（書き込み）処理である。

以下、上記のＴＣＰ処理部１２２０のさらに詳細な構成について図３を使用して説明する。

（３−ａ）受信データ管理部１２２１
受信データ管理部１２２１は、ＴＣＰ受信部１２２６から受け取ったデータが格納されているパケットバッファを、ソケットキューに関連付けした状態で管理する。本実施の形態での受信データ管理部１２２１は、各ソケットキューに対して、以下の２つの値を管理している。

［保持データパケット数ＰＢｃｕｒ］
１つのＴＣＰ通信（コネクション）において、データパケットを現在何個保持しているかを示す数であり、本実施の形態ではソケットキューに関連付けされているパケットバッファの個数を示す。

［最大保持データパケット数ＰＢｍａｘ］１つのＴＣＰ通信（コネクション）のために、保持することができる最大のデータパケット数を示す最大数であり、本実施の形態では受信データ管理部１２２１内のソケットキューに関連付け可能な最大パケットバッファの個数を示す。

尚、受信データ管理部１２２１は、さらに以下の２つの値を管理してもよい。

［最大保持データ量Ｄｍａｘ］
１つのＴＣＰ通信（コネクション）のために、ソケットキューに保持可能な最大データ量（ｂｙｔｅ数）を示す。ここでは、ＤｍａｘはＰＢｍａｘとパケットバッファのサイズとの積であるとする。尚、ＤｍａｘはＰＢｍａｘの値とは独立して、例えば８１９２ｂｙｔｅ等に設定することも可能である。

［実受信データ量Ｄｃｕｒ］
１つのＴＣＰ通信（コネクション）において、ソケットキューに関連づけられているパケットバッファに格納されているデータ量（ｂｙｔｅ数）の総計を示す。

また、受信データ管理部１２２１は、ソケットキューを、ＴＣＰ通信の開始・終了（コネクションの確立・切断）に応じて作成、削除を行なう。さらに、アプリケーション部１１００からの受信要求に対し、ソケットキューに関連づけられたパケットバッファに格納されたデータを、ＡＰＩ部１２１０を介してアプリケーション部１１００に渡し、データを格納していたパケットバッファをパケットバッファ管理部１４００に開放要求する。

また、受信データ管理部は、Ｗｉｎ制御部１２２２からの最大保持データパケット数ＰＢｍａｘと、現在保持データパケット数ＰＢｃｕｒの問い合わせに対し応答する。

また、受信データ管理部１２２１が最大保持データ量Ｄｍａｘと、実受信データ量Ｄｃｕｒとを保持する場合は、Ｗｉｎ制御部１２２２からの最大保持データ量Ｄｍａｘと、実受信データ量Ｄｃｕｒの受け渡し要求に対し応答する。

なお、最大保持データパケット数ＰＢｍａｘ、および、最大保持データ量Ｄｍａｘは、通常、ソケットキュー作成時にＡＰＩ部１２１０により設定されるが、その後に動的に変更要求を受けてもよい。

なおまた、ソケットキュー作成時、パケットバッファ管理部１４００に対して、最大保持データパケット数ＰＢｍａｘ分のパケットバッファを固定的に確保することを要求してもよい。要求を行なうことにより、現在保持している保持データパケット数ＰＢｃｕｒが、最大保持データパケット数ＰＢｍａｘに到達する前に、パケットバッファ管理部１４００から取得できなくなることを防ぐことができる。

（３−ｂ）Ｗｉｎ制御部１２２２
Ｗｉｎ制御部１２２２は、受信データ管理部１２２１に問い合わせ、保持データパケット数ＰＢｃｕｒからＷｉｎ（告知ウィンドウのサイズＷａｄ）を決定する。また、ＡＣＫ生成部のＷｉｎ受け渡し要求に対して、告知Ｗｉｎサイズを応答する。

なお、告知ＷｉｎサイズＷａｄの決定方法の詳細については後述する。

（３−ｅ）ＡＣＫ生成部１２２４
ＡＣＫ生成部１２２４は、ＴＣＰ受信部１２２６よりＳｅｑを受け取った場合、Ｗｉｎ制御部１２２２に問い合わせ、受け取った告知ＷｉｎサイズＷａｄとＴＣＰ受信部１２２６より受け取ったＳｅｑよりＡＣＫを作成し、ＴＣＰ送信部１２２５に渡す機能をもつ。

（３−ｆ）ＴＣＰ送信部１２２５
ＡＣＫ生成部１２２４から受け取ったＴＣＰセグメントに必要なＴＣＰヘッダ情報を設定しＩＰ処理部１２３０に渡す機能をもつ。

（３−ｇ）ＴＣＰ受信部１２２６
ＴＣＰ受信部１２２６は、ＴＣＰセグメントからデータを抽出する処理を実施し、パケットバッファに格納したまま、抽出したデータを受信データ管理部１２２１に渡す機能をもつ。また、Ｓｅｑが順序通りであった場合に次のＳｅｑをＡＣＫ生成部１２２４に渡す機能をもつ。なお、ＡＣＫ生成部１２２４へ次のＳｅｑを渡す機能は、毎回発生しなくてもよい。このとき、ＡＣＫ生成部１２２４への通知は、複数回に１回の割合で通知されたり、遅延ＡＣＫアルゴリズムにより、システムのタイマから所定時間経過後に行われたりする。遅延ＡＣＫアルゴリズムは、ＡＣＫの送信を抑えることにより、効率的なＴＣＰ通信を実現するアルゴリズムである。その詳細は非特許文献１に記載の通りであるため、ここでは説明を省略する。

＜＜ＴＣＰセグメント受信とＡＣＫ送信処理＞＞
図３を用いて、ＴＣＰセグメントの受信時の処理と、ＡＣＫ送信処理について説明を行なう。通信装置１は、データパケットを受信し、受信したパケットからアプリケーションデータを抽出し、アプリケーション部１１００にて処理を行なう。また、所定のタイミングでＴＣＰセグメントを受信したことを示すＡＣＫを送信する。

（ステップ１）パケット受信からＴＣＰ処理部１２２０までの処理（ＳＴ７０１）
まず、ＴＣＰセグメントを受信する処理から、ＴＣＰ処理部１２２０までの処理を説明する。

通信装置１では、ＭＡＣ制御部１３１０よりパケットを受信し、Ｉｎｔｅｒｆａｃｅ処理部１２４０がＭＡＣ制御部１３１０よりデータを取得する。この際、Ｉｎｔｅｒｆａｃｅ処理部１２４０は、パケットバッファ管理部１４００にパケットバッファ獲得要求を行い、パケットバッファをパケットバッファ管理部１４００より獲得し、受信したパケットに含まれるデータをパケットバッファに格納する。

パケットバッファ管理部１４００は、Ｉｎｔｅｒｆａｃｅ処理部１２４０に渡したパケットバッファ数に応じて、使用可能パケットバッファ数ＳＰＢｅｎを減らす。なお、１つのパケットバッファに格納可能なデータサイズ（１パケットバッファサイズ）よりも、受信したパケットのデータサイズが大きい場合、パケットバッファをチェーン構造にすることにより、複数のパケットバッファを１つのパケットとして扱ってもよい。

さらにＩｎｔｅｒｆａｃｅ処理部１２４０は、ＭＡＣヘッダの解析などの処理を行い、ＩＰパケットを抽出し、ＩＰパケットが格納されているパケットバッファをＩＰ処理部１２３０に渡す。

ＩＰ処理部１２３０は、ＩＰヘッダ解析などのＩＰ処理を行い、上位のプロトコルがＴＣＰであることを判定すると、ＴＣＰセグメントを抽出し、ＴＣＰセグメントが格納されているパケットバッファをＴＣＰ処理部１２２０へ渡す。なお、ＩＰ処理部１２３０におけるＩＰ処理はＲＦＣに記載の処理を逸脱しないため、ここでの説明は省略する。

（ステップ２）ＴＣＰ受信部１２２６からソケットキューへの関連付け処理（ＳＴ７０２、ＳＴ７０３）
次に、ＩＰ処理部１２３０から渡されたパケットバッファに対する、ＴＣＰ受信部１２２６の処理から、受信データ管理部１２２１におけるソケットキューへの関連付け処理までを説明する。

ＳＴ７０１によりＴＣＰセグメントと判断された受信パケットは、ＴＣＰ受信部１２２６において、ＴＣＰセグメントからアプリケーションデータを抽出する処理を実施し、パケットバッファに格納したまま、抽出したデータを受信データ管理部１２２１に渡す（ＳＴ７０２）。

受信データ管理部１２２１は、受信したパケットバッファをソケットキューに関連付ける。また、ソケットキューに関連付けた保持データパケット数に応じて保持データパケット数ＰＢｃｕｒを増やす。

また、ＴＣＰヘッダ部に含まれるＳｅｑまでの全てのデータを受信していた場合、受信したＴＣＰヘッダに含まれるＳｅｑまでのデータは受信していることを示すために、通信装置２に対してＡＣＫ送信要求を行なう。

ＴＣＰ受信部１２２６は、ＡＣＫ送信要求として、次のＳｅｑをＡＣＫ生成部１２２４に渡す（ＳＴ７０３）。ただし、ＡＣＫの送信は毎回行なう必要はなく、複数回に１回の割合で通知されたり、遅延ＡＣＫアルゴリズムにより、システムのタイマから所定時間経過後に行われたりしてもよい。

（ステップ３）アプリケーション部１１００によるデータ受信処理
次に、受信データ管理部１２２１のソケットキューに関連付けられているパケットバッファに格納されているデータをアプリケーション部１１００が受信する処理までを説明する。

アプリケーション部１１００は、ＡＰＩ部１２１０に対して、データの受信要求を行なう。ＡＰＩ部１２１０は、受信要求に対して、受信データ管理部１２２１のソケットキューに関連づけられているデータの受け渡し要求を行なう。受け渡し要求を受けた受信データ管理部１２２１は、ソケットキューに関連付けられているパケットバッファに格納されるデータをＡＰＩ部１２１０に渡し、ＡＰＩ部１２１０はアプリケーション部１１００に渡す。アプリケーション部１１００は、受け渡されたデータを処理する（ＳＴ７０４）。

なお、受信データ管理部１２２１は、ＡＰＩ部１２１０の受け渡し要求に対し、ソケットキューに関連付けられている全てのパケットバッファに格納されているデータを渡しても良いし、一部のデータを渡してもよい。

ＡＰＩ部１２１０にデータを渡した後、受信データ管理部１２２１は、ＡＰＩ部１２１０に渡したデータを格納していたパケットバッファの開放要求をパケットバッファ管理部１４００に行い、パケットバッファ管理部１４００は、パケットバッファを開放する（ＳＴ７０５）。さらに受信データ管理部１２２１は、ソケットキューから関連付けを外したパケットバッファ数や受信データ量に応じて、現在の保持データパケット数ＰＢｃｕｒ、および、実受信データ量Ｄｃｕｒを更新する。このとき、パケットバッファ管理部１４００においても開放したパケットバッファ数に応じて、使用可能パケットバッファ数ＳＰＢｅｎを増やす。

（ステップ４）ＡＣＫ生成処理
次に、ＴＣＰ受信部１２２６がＡＣＫ生成要求を行った後の、ＡＣＫ生成部１２２４の処理について説明する。

ＳＴ７０２においてＡＣＫ生成要求を受けたＡＣＫ機能部は、告知ＷｉｎサイズＷａｄを設定するために、Ｗｉｎ制御部１２２２に告知ＷｉｎサイズＷａｄを問い合わせる（ＳＴ７０６）。

Ｗｉｎ制御部１２２２は、受信データ管理部１２２１に最大保持データパケット数ＰＢｍａｘと、現在保持データパケット数ＰＢｃｕｒを問い合わせて受け取り（ＳＴ７０７）、これらにより残りパケットバッファサイズＷｐｂを算出する。残りパケットバッファサイズＷｐｂは、パケットバッファ管理部１４００が管理しているパケットバッファのうち、既にパケットを保持するために利用しているパケットバッファ以外のパケットバッファ数と、１つのパケットバッファに格納可能なデータサイズの積により算出される値である。次に、告知ＷｉｎサイズＷａｄを決定し、ＡＣＫ生成部１２２４に渡す（ＳＴ７０８）。

なお、告知ＷｉｎサイズＷａｄの算出方法の詳細は後述する。

ＡＣＫ生成部１２２４は、Ｗｉｎ制御部１２２２に渡された告知ＷｉｎサイズＷａｄをＡＣＫのパラメータに含め、ＴＣＰ送信部１２２５に送信要求を行なう（ＳＴ７０９）。

（ステップ５）ＡＣＫ送信
最後に、ＡＣＫ送信要求を受けたＴＣＰ送信部１２２５の処理からデータパケット送信までの処理を説明する。

ＴＣＰ送信部１２２５は、ＡＣＫ生成部１２２４からのＡＣＫ送信要求を受けて、パケットバッファ管理部１４００にパケットバッファ獲得要求を行い、パケットバッファを獲得する（ＳＴ７１０）。

パケットバッファ管理部１４００は、使用可能パケットバッファ数ＳＰＢｅｎの更新を行なう。獲得したパケットバッファに対し、上記でＷｉｎ制御部１２２２から受け取った告知Ｗｉｎサイズを含んだＡＣＫのデータを格納し、ＴＣＰヘッダを作成し、ＡＣＫのデータに付加する。作成したＡＣＫをＩＰ処理部１２３０に送信要求を行なう。なお、ＡＣＫのデータ、およびＴＣＰヘッダの各パラメータの設定についてはＲＦＣ記載の範囲を逸脱しないため、説明を省略する。

送信要求を受けたＩＰ処理部は、ＩＰヘッダ追加などのＩＰ処理を行い、Ｉｎｔｅｒｆａｃｅ処理部１２４０はＭＡＣヘッダ追加などの処理を行い、ＭＡＣ処理部１３１０に渡し、ＭＡＣ処理部１３１０は、構築されたＡＣＫの送信を行なう（ＳＴ７１１）。なお、ＩＰ処理部１２３０、Ｉｎｔｅｒｆａｃｅ処理部１２４０、ＭＡＣ処理部の処理については、ＲＦＣに記載の処理を逸脱しないため、説明は省略する。

パケット送信後、Ｉｎｔｅｒｆａｃｅ処理部１２４０は、パケットバッファ管理部１４００にパケットバッファの開放要求を行う（ＳＴ７１２）。

パケットバッファ管理部１４００は、開放処理、および、使用可能パケットバッファ数ＳＰＢｅｎの更新を行なう。

以上のように、通信装置はＴＣＰセグメントを受信し、ＡＣＫの送信を行なう。

＜＜告知Ｗｉｎサイズの算出方法＞＞
本実施の形態では、以下で説明を行なう告知Ｗｉｎサイズの算出方法により、余剰なトラフィックを抑制する。

図１を用いて、Ｗｉｎ制御部１２２２における告知ＷｉｎサイズＷａｄの算出方法の説明を行なう。

ここでは、告知ＷｉｎサイズＷａｄの算出の説明の一例として、１パケットバッファに１５００ｂｙｔｅのデータを格納可能であり、最大保持データパケット数ＰＢｍａｘを８個とする。又、ショートパケットの例としてＴＣＰセグメント１つに１００ｂｙｔｅのデータを含むパケット５個を受信し、受信した全てのパケットがプロトコルスタックで処理中でありソケットキューに関連付けられて保持されている場合を用いて、説明を行なう。

まず、Ｗｉｎ制御部１２２２は、ＡＣＫ生成部１２２４から告知ＷｉｎサイズＷａｄの問い合わせを受ける（Ｓ８０１）。

次に、Ｗｉｎ制御部１２２２は、受信データ管理部１２２１に対して、最大保持データパケット数ＰＢｍａｘと、現在保持データパケット数ＰＢｃｕｒを問い合わせ、各値を受け取る（Ｓ８０２）。

次に、Ｗｉｎ制御部１２２２は、最大保持データパケット数ＰＢｍａｘと現在保持データパケット数ＰＢｃｕｒの差分から保持可能である、残り保持データパケット数ＰＢｒｅｍを算出する（Ｓ８０３）。

Ｓ８０３で算出される保持可能残り保持データパケット数ＰＢｒｅｍと、最大保持データパケット数ＰＢｍａｘ及び現在保持データパケット数ＰＢｃｕｒとの関係を図４に示す。

次に、Ｗｉｎ制御部１２２２は、１パケットバッファのサイズを固定サイズＳとして、本実施の形態では１つのパケットバッファのサイズである１５００ｂｙｔｅを取得する（Ｓ８０４）。

次に、Ｗｉｎ制御部１２２２は、保持可能な残り保持データパケット数ＰＢｒｅｍと固定サイズＳとの積により、残りパケットバッファサイズＷｐｂを算出する（Ｓ８０５）。

図５に、Ｓ８０３で算出される保持可能残り保持データパケット数ＰＢｒｅｍと、最大保持データパケット数ＰＢｍａｘ及び現在保持データパケット数ＰＢｃｕｒとの関係を示す。

図５は、対象となる１つのＴＣＰ通信に対するＰＢｍａｘ、ＰＢｃｕｒ、ＰＢｒｅｍの関係を示した図であり、１パケットバッファサイズに比べ、１つのパケットバッファに含まれるデータ量が小さい状態の一例である。具体的には、図５は、１パケットに１００ｂｙｔｅのデータを含んだパケットを５個受信し、これらを５個のパケットバッファに保持している状態を示している。

このように１パケットバッファに含まれるデータ量が少ない状態が発生するのは、通信相手のＭＴＵサイズが小さく設定されている場合や、ＴＥＬＮＥＴなどのように１つのパケットに少ないＴＣＰデータ量しか含まずに送信するようなアプリケーションを用いた場合である。ＴＥＬＮＥＴは、入力された文字を１文字ずつパケットに含め、データを送信するため、１パケットに含まれるデータ長の少ないＴＣＰ通信となる。また、ＴＣＰヘッダオプションが０であり、かつ、ＴＣＰセグメントサイズが１４０ｂｙｔｅの場合、図５に示す通信が発生する。

図５には、Ｓ８０５で算出される、最大保持データパケット数ＰＢｍａｘ、現在保持データパケット数ＰＢｃｕｒ、保持可能残り保持データパケット数ＰＢｒｅｍの各値の一例を示している。現在の保持データパケット数ＰＢｃｕｒは５個であり、１つのパケットバッファには１００ｂｙｔｅのデータが格納されている。また、最大保持データパケット数ＰＢｍａｘは、８個であるため、保持可能残り保持データパケット数ＰＢｒｅｍは８−５＝３個である。１パケットバッファサイズは１５００Ｋｂｙｔｅであるため、残りパケットバッファサイズＷｐｂは（３×１５００ｂｙｔｅ）である。

最後に、算出したＷｐｂを告知ＷｉｎサイズＷａｄとして決定する（図１のＳ８０６）。

以上の構成により、残り保持データパケット数が少なくなった状態においても、通信装置が受信して現在保持している保持データパケット数から算出したＷｐｂをＷｉｎサイズとして告知する。これにより、パケットが受信できず、再送による無駄なトラフィックが発生する状況を防ぐことができる。

例えば、前述のように１００ｂｙｔｅのショートパケットを連続して受信し、全てのパケットを保持している状況で、告知ＷｉｎとしてＤｃｕｒに基づいて算出される告知ＷｉｎであるＷｄと、告知ＷｉｎとしてＰＢｃｕｒに基づいて算出される告知ＷｉｎであるＷｐｂとの比較を図６に示す。Ｗａｄとして、常にＷｄを告知する場合、保持しているデータパケットが処理されず、残り保持データパケット数がなくなった状態においても、Ｗａｄと比較して大きいサイズのＷｄを告知するために、送信側装置からパケットが送信され、無駄なトラフィックが発生する。一方で、Ｗａｄとして、Ｗｄと比較して小さいサイズのＷｐｂを告知する本発明では、残り保持データパケット数からＷｐｂが算出されるため、告知Ｗｉｎのサイズを小さくでき、無駄なトラフィックが発生することを防ぐことができる。

又、１５００ｂｙｔｅのパケットを連続して受信し、全てのパケットを保持している状況で、告知ＷｉｎとしてＤｃｕｒに基づいて算出される告知ＷｉｎであるＷｄと、告知ＷｉｎとしてＰＢｃｕｒに基づいて算出される告知ＷｉｎであるＷｐｂとの比較を図７に示す。図７のように比較的長いサイズのパケットの受信であれば、告知ＷｉｎのサイズＷａｄはＤｃｕｒを基にしたものと同じように告知Ｗｉｎを決定することができる。

尚、上述の説明では、保持データパケット数は、ソケットキューに関連付けられているパケット数であるとしたが、保持データパケット数は告知ウィンドウを決定するために必要となるパケット数であればよい。

例えば、受信したパケットが対象のＴＣＰ通信であることが判断され、ソケットキューに関連付けられていなくても、ＴＣＰ通信であることが判断された直後からアプリケーション部に受信される前までのパケット数とすることができる。また、受信したパケット全てから告知ウィンドウサイズを算出する場合であれば、通信装置がデータパケットを受信し、ＮＩＣに記憶されてから、アプリケーション部に受信される前までの全てのパケットとすることができる。

また、告知ウィンドウサイズ計算後、ＡＣＫ生成中にパケットを受信した場合は、その受信したパケットを保持パケット数に含んでも、含まなくてもよい。保持パケット数に含む場合は、告知ウィンドウサイズを再計算する処理が必要となる。

なお、残りパケットバッファサイズＷｐｂの算出は、受信データ管理部１２２１が実施し、ＡＣＫ生成部に渡しても良い。

（実施の形態２）
図８に、実施の形態２の通信装置の構成図を示す。図中、実施の形態１と共通する部分には共通の番号を付与している。

本実施の形態では、受信データ管理部１２２１は、各ソケットキューに対して前述したＰＢｃｕｒ、ＰＢｍａｘ、Ｄｍａｘ、及びＤｃｕｒの４つの値を管理しており、Ｄｍａｘとして８１９２ｂｙｔｅが設定されている。

又、本実施の形態は、実施の形態１で説明したＷｉｎ制御部の中にサイズ取得部１２２２ａとＷｉｎ抑制部１２２２ｂとを分離して含む点が、実施の形態１と異なっている。

他の機能部については第１実施例と同様であるため説明を省略し、サイズ取得部１２２２ａとＷｉｎ抑制部１２２２ｂとについて以下説明する。

サイズ取得部１２２２ａは、受信データ管理部１２２１に問い合わせ（ＳＴ７０７ａ）、応答された最大保持データ量Ｄｍａｘと、実受信データ量Ｄｃｕｒから、受信可能データ量Ｗｄを算出する。また、Ｗｉｎ抑制部１２２２ｂからの受信可能データ量Ｗｄの問い合わせに対して応答する（ＳＴ７０６ａ、ＳＴ７０６ｂ）。

受信可能データ量Ｗｄは例えば、ＤｍａｘからＤｃｕｒを減算することにより算出される。

前記算出に基づくＷｄは、最大保持データ量Ｄｍａｘと実受信データ量Ｄｃｕｒの差分となるが、受信可能データ量Ｗｄは、必ずしも、前記演算により算出される必要はなく、最大保持データ量Ｄｍａｘと実受信データ量Ｄｃｕｒの差分に一定値を掛け合わせることにより算出したりしても構わない。

Ｗｉｎ抑制部１２２２ｂは、サイズ取得部１２２２ａに問い合わせ、応答された受信可能データ量Ｗｄを得る。

また、Ｗｉｎ抑制部１２２２ｂは、受信データ管理部１２２１に問い合わせて得た最大保持データパケット数ＰＢｍａｘと保持データパケット数ＰＢｃｕｒから残りパケットバッファサイズＷｐｂを算出する。Ｗｐｂ算出の方法は実施の形態１記載と同様であるため説明を省略する。

本実施の形態では、Ｗｉｎ抑制部１２２２ｂは、受信可能データ量Ｗｄと残りバッファパケットサイズＷｐｂとを比較し、小さい方の値をＷｉｎ（告知ＷｉｎサイズＷａｄ）として決定する。

また、ＡＣＫ生成部のＷｉｎ受け渡し要求に対して、告知Ｗｉｎサイズを応答する。

次に、図９を用いてＷｉｎ抑制部１２２２ｂがＡＣＫ生成部１２２４から告知ＷｉｎサイズＷａｄの問い合わせを受けた後の、Ｗｉｎ抑制部１２２２ｂにおける告知ＷｉｎサイズＷａｄの算出方法の一例の説明を行なう。

本実施の形態では、告知ＷｉｎサイズＷａｄの算出を説明するため、１パケットバッファに１５００ｂｙｔｅのデータを格納可能であり、最大保持データパケット数Ｐｍａｘを８個、最大保持データ量Ｄｍａｘを８１９２ｂｙｔｅとする。

ＴＣＰパケット１パケットに１００ｂｙｔｅのデータを含むパケット５個がソケットキューに関連付けられている場合を用いて、説明を行なう。

（Ｃａｌｃ−１）受信可能データ量の取得（ＳＴ８１）
まず、Ｗｉｎ抑制部１２２２ｂは、サイズ取得部１２２２ａに対して、受信可能データ量Ｗｄを問い合わせる（ＳＴ８１）。

次に、サイズ取得部１２２２ａは、受信データ管理部１２２１に最大保持データ量Ｄｍａｘと、実受信データ量Ｄｃｕｒを問い合わせる。サイズ取得部１２２２ａは、受信データ管理部１２２１から受信した最大保持データ量Ｄｍａｘと、実受信データ量Ｄｃｕｒの差分から受信可能データ量Ｗｄを算出し、Ｗｉｎ制御部１２２２に応答する。なお、受信可能データ量の算出は、受信データ管理部１２２１が実施し、Ｗｉｎ制御部１２２２に渡してもよい。

図１０に最大保持データ量Ｄｍａｘ、実受信データ量Ｄｃｕｒ、および、受信可能データ量Ｗｄの関係を示す。図１０には、各数値の一例も示しており、アプリケーション部１１００からの受信要求を待つために関連づけられている実受信データ量Ｗｄは、１００ｂｙｔｅ×５＝５００ｂｙｔｅであり、最大受信データ量Ｄｍａｘが８１９２であるため、受信可能データ量Ｗｄは７６９２ｂｙｔｅである。

（Ｃａｌｃ−２）残りパケットバッファサイズＷｐｂの算出（ＳＴ８２）
次に、Ｗｉｎ抑制部１２２２ｂは、実施の形態１と同様に受信データ管理部１２２１に対して、最大保持データパケット数ＰＢｍａｘと、保持データパケット数ＰＢｃｕｒを問い合わせ、各値を受け取る。

Ｗｉｎ制御部１２２２は、実施の形態１と同様、図１１に示す、ＰＢｍａｘ、ＰＢｃｕｒ、及びＰＢｒｅｍの関係により、最大保持データパケット数ＰＢｍａｘと保持データパケット数ＰＢｃｕｒの差分から保持可能残り保持データパケット数ＰＢｒｅｍを算出する。

次に、ＰＢｒｅｍと固定サイズＳとの積により、残りパケットバッファサイズＷｐｂを算出する。

なお、残りパケットバッファサイズＷｐｂの算出は、受信データ管理部１２２１が実施し、Ｗｉｎ制御部１２２２に渡しても良い。

図１１に最大パケットバッファ数ＰＢｍａｘ、現在パケットバッファ数ＰＢｃｕｒ、保持可能残りパケットバッファ数ＰＢｒｅｍの関係を示す。図１１は、１パケットバッファサイズに比べ、１つのパケットバッファに含まれるデータ量が小さい状態である。

具体的には、図１１は、１パケットに１００ｂｙｔｅのデータを含んだパケットを５個受信した状態を示している。

図１１には、最大パケットバッファ数ＰＢｍａｘ、現在パケットバッファ数ＰＢｃｕｒ、保持可能残りパケットバッファ数ＰＢｒｅｍの各値の一例も示している。現在パケットバッファ数ＰＢｃｕｒは５個であり、１つのパケットバッファには１００ｂｙｔｅのデータが格納されている。また、最大パケットバッファ数ＰＢｍａｘは、８個であるため、保持可能残りパケットバッファ数ＰＢｒｅｍは８−５＝３個である。１パケットバッファサイズは１５００ｂｙｔｅであるため、残りパケットバッファサイズＷｐｂは４５００ｂｙｔｅである。

（Ｃａｌｃ−３）告知ＷｉｎサイズＷａｄの設定（ＳＴ８３、ＳＴ８４、ＳＴ８５、ＳＴ８６）
さらに、Ｗｉｎ抑制部１２２２ｂは、ＳＴ８１においてＷｉｎ制御部１２２２より渡された受信可能データ量Ｗｄと、ＳＴ８２において算出した残りパケットバッファサイズＷｐｂとを比較する（ＳＴ８３）。

本実施の形態では、告知するＷｉｎサイズＷａｄは受信したパケットを必ず受信できるように設定するため、小さい方を告知ＷｉｎサイズＷａｄとする。

つまり、残りパケットバッファサイズＷｐｂの方が小さければ、それを告知ＷｉｎサイズＷａｄに設定し（ＳＴ８４）、一方、受信可能データ量Ｗｄの方が小さければ、それを告知ＷｉｎサイズＷａｄに設定し（ＳＴ８５）、設定した告知ＷｉｎサイズＷａｄをＡＣＫ生成部に渡す（ＳＴ８６）。

図１２の例では、ＳＴ８１においてＷｉｎ制御部１２２２により渡された受信データ量は７６９２ｂｙｔｅであり、ＳＴ８２において算出された残りパケットバッファサイズＷｐｂは、４５００ｂｙｔｅであるため、告知Ｗｉｎサイズは残りパケットバッファサイズＷｐｂである、４５００Ｋｂｙｔｅとする。

以上の構成により、残りパケットバッファ数が少なくなった状態においても、残りパケットバッファ数から算出した残りパケットバッファ数をＷｉｎサイズとして告知することにより、自身で受信できない数のパケットを通信相手装置に送信させないように抑制することができる。これにより、パケットが受信できなかった場合の再送による無駄なトラフィックが発生することを防ぐことができる。

また、比較に基づいて告知Ｗｉｎの算出方法を切り替えるため、受信不可能であるにも関わらず、パケットを受信することを防ぎ、ＣＰＵ処理負荷をかけてしまうことを防ぐことができる。例えば、上述のショートパケット（１００ｂｙｔｅデータ）を複数保持する状況で、ＰＢｃｕｒに基づいて算出されるＷｐｂと、Ｄｃｕｒに基づいて算出されるＷｂとを、図１３に示す。

図１３に示すように、保持パケット数が０からＷｐｂとＷｂとが交差する保持パケット数ｎまではＷｄをＷａｄとし、保持パケット数がｎより大きい場合にはＷｐｂをＷａｄとして決定するため、保持パケット数に応じて段階的な告知Ｗｉｎの決定をすることができる。

このため、多量のパケットを短時間に受信し、保持データパケット数が多くなった場合にのみ、告知Ｗｉｎを急峻に小さくすることができ、装置のパケット処理状況に応じた送信抑制を実現することができる。

尚、Ｗｉｎ抑制部１２２２ｂは、比較の結果、告知ＷｉｎサイズＷａｄを残りパケットバッファサイズＷｐｂとした場合は、ＴＣＰ受信部に対して、遅延ＡＣＫアルゴリズムの使用を無効する命令を送り、受信可能データ量Ｗｄとした場合は、遅延ＡＣＫアルゴリズムを有効にする命令を送ることもできる（ＳＴ７１３）。

この場合は、さらに、残りパケットバッファサイズＷｐｂをＷｉｎサイズとして告知した場合、ＴＣＰ受信部に遅延ＡＣＫアルゴリズムを無効にする命令を送ることにより（ＳＴ７１３）、より早くＡＣＫを送信可能となり、変更されたＷｉｎサイズを告知することができる。

（実施の形態３）
実施の形態３は、実施の形態２において、告知Ｗｉｎサイズの算出方法で残りパケットバッファサイズＷｐｂを算出する際に、パケットバッファ管理部１４００ｂに使用可能パケットバッファ数ＳＰＢｅｎを問い合わせ、受け取った値を元に判断し、残りパケットバッファサイズＷｐｂを算出する機能を追加する点で、実施の形態２と異なる形態である。

本実施の形態の説明では、＜通信装置１の機能構成＞のうち、実施の形態２と共通していない部分、および、＜＜告知Ｗｉｎサイズの算出方法＞＞に関して説明する。

＜＜ネットワーク構成および構成図＞＞
図１４は、本発明の一実施の形態である実施の形態３の通信装置１の機能構成例を示した図である。実施の形態３におけるネットワーク構成および構成図について、実施の形態２の＜＜ネットワーク構成および構成図＞＞と共通していない部分について説明し、それ以外に関しては説明を省略する。

図１４の通信装置１の機能構成を以下に示す。受信データ管理部１２２１、Ｗｉｎ抑制部１２２２ｃ、パケットバッファ管理部１４００ｂを除き、他の機能は実施の形態１と同様のためここでは説明を省略する。受信データ管理部１２２１、Ｗｉｎ抑制部１２２２ｂ、パケットバッファ管理部１４００ｂは実施の形態２に記載の機能に加え、以下の機能を追加する。

（１ｂ）パケットバッファ管理部１４００ｂ
パケットバッファ管理部１４００ｂは、さらに通信装置全体の最大パケットバッファ数ＳＰＢｍａｘと、通信装置全体で現在使用しているパケットバッファ数ＳＰＢｃｕｒと、ＳＰＢｍａｘと、ＳＰＢｃｕｒの差分として算出される、通信装置全体の残りパケットバッファ数ＳＰＢｒｅｍと、既存のＴＣＰ通信（コネクション）が使用可能パケットバッファ数の使用可能閾値Ｔを有する。

Ｗｉｎ抑制部１２２２ｂからの使用可能パケットバッファ数ＳＰＢｅｎの問い合わせに対し、使用しているパケットバッファ数ＳＰＢｒｅｍが使用可能閾値Ｔより多ければ、使用可能パケットバッファ数ＳＰＢｅｎを渡す機能を追加する。使用可能閾値は、他に新しくＴＣＰ通信が確立することにより、必要と判断されるパケットバッファ数、また、現在の通信のための最大パケットバッファ数ＰＢｍａｘを考慮し、値を設定することが望ましい。

また、パケットバッファ管理部１４００ｂは、もし、通信装置全体の残りパケットバッファ数ＳＰＢｒｅｍが使用可能閾値Ｔより少ない場合は、その旨をＷｉｎ抑制部１２２２ｂに通知する。通信装置全体の残りパケットバッファ数ＳＰＢｒｅｍが使用可能閾値Ｔより少ない旨の通知方法としては、本実施の形態では、ＳＰＢｅｎの値として負値を返すこととするが、必ずしも負値とする必要はなく、ＳＰＢｒｅｍが使用可能閾値Ｔより少ないことを示すものであればよい。

なお、使用可能閾値Ｔは、パケットバッファ管理部１４００ｂの保持するパケットバッファ数の割合を定義してもよいし、絶対値としてもよい。また、現在未開設のソケット数に応じて動的に変化しても良いし、システム固定値であっても良い。また、使用可能閾値Ｔを持たず、パケットバッファ管理部１４００ｂの管理している全ての使用可能なパケットバッファを、対象となるＴＣＰ通信に割り当ててもよい。

（３−ｃ−２）Ｗｉｎ抑制部１２２２ｃ
Ｗｉｎ抑制部１２２２ｃは、残りパケットバッファサイズＷｐｂを算出する際に、パケットバッファ管理部１４００ｂに使用可能パケットバッファ数ＳＰＢｅｎを問い合わせ、受け取った値を元に、残りパケットバッファサイズＷｐｂを算出する機能を追加する。

また、Ｗｉｎ抑制部１２２２ｃは、残りパケットバッファ数ＳＰＢｒｅｍが使用可能閾値Ｔより小さい場合、実施の形態２に記載の算出方法にて、残りパケットバッファサイズＷｐｂを算出する。

＜告知Ｗｉｎサイズの算出方法＞
図１５は、本実施の形態における、Ｗｉｎ抑制部１２２２ｃにおける告知ＷｉｎサイズＷａｄの算出方法を示した一例の説明を行なうための図である。本実施の形態では、残りパケットバッファサイズＷｐｂの算出方法、および、その後の告知ＷｉｎサイズＷａｄの算出方法が、実施の形態２とは異なる。ＳＴ８１１、ＳＴ８１２について説明を行い、それ以外の処理については、実施の形態１と同様のため、ここでの説明は省略する。

Ｗｉｎ抑制部１２２２ｃは、ＡＣＫ生成部からの告知Ｗｉｎの問い合わせを受け、パケットバッファ管理部１４００ｂに使用可能パケットバッファ数ＳＰＢｅｎを問い合わせる（ＳＴ８１１）。

次に、残りパケットバッファ数ＳＰＢｒｅｍと使用可能閾値Ｔとを比較し、ＳＰＢｒｅｍがＴに対して小さいか、否かを確認する（ＳＴ８１２）。

判定の結果、残りパケットバッファ数ＳＰＢｒｅｍが小さい場合（ＳＴ８１２でＹＥＳ）は、実施の形態２に記載のＳＴ８１からの処理と同様である。

一方、小さくなかった場合（ＳＴ８１２でＮＯ）は、実施の形態２に記載のＳＴ８１と同様にＷｄを取得する（ＳＴ８１ａ）し、残りパケットバッファサイズＷｐｂの算出を行なう（ＳＴ８２ｂ）。

残りパケットバッファサイズＷｐｂは、パケットバッファ管理部１４００ｂから受信した使用可能パケットバッファ数ＳＰＢｅｎと、固定サイズＳとして本実施の形態では１パケットバッファサイズの積により算出する。

以下に、図１６と、図１７を用いて、具体的な告知ＷｉｎサイズＷａｄの算出方法を説明する。

図１６は、通信装置全体のパケットバッファ数ＳＰＢｍａｘと、通信装置全体で使用されているパケットバッファ数ＳＰＢｃｕｒと、通信装置全体の残りパケットバッファ数ＳＰＢｒｅｍと、使用可能閾値Ｔと、使用可能パケットバッファ数ＳＰＢｅｎの関係を示した図である。本実施の形態の一例として、ＳＰＢｍａｘは１６、ＳＰＢｃｕｒは１０とし、使用可能閾値Ｔは新規通信のために確保しておくパケットバッファ数のみを考慮し、４とし、動的には変更しないものとする。

以下に、ＳＰＢｒｅｍと、ＳＰＢｅｎの算出方法を示す。

図１７は、使用されているパケットバッファに含まれるデータも考慮した、通信装置全体の現在パケットバッファ数ＳＰＢｃｕｒ、パケットバッファ管理部１４００ｂの使用可能パケットバッファ数ＳＰＢｅｎの関係の一例を示す図である。図１７は図５が１つのＴＣＰ通信に対するパケットバッファ数の関係図であるのに対し、通信装置全体のパケットバッファに着目している。なお、図５と同様に、１パケットバッファサイズは１５００ｂｙｔｅとし、図中には記載していないが、最大保持データ量Ｄｍａｘは１６Ｋｂｙｔｅと設定されているとする。

図１７には、パケットバッファ管理部１４００ｂが管理している通信装置全体のパケットバッファＳＰＢｍａｘが記載されている（四角形２００２のパケットバッファ）。この中には、以下のカテゴリに含まれるパケットバッファが存在する。

・通信装置全体で使用中の現在パケットバッファ（四角２０００に囲まれた１０個のパケットバッファ）
このうち、四角２０００ａで示されるパケットバッファは、対象となるＴＣＰ通信にて使用中の現在パケットバッファは７個とする。

・パケットバッファ管理部１４００ｂの使用可能なパケットバッファＳＰＢｅｎ（四角２００３に囲まれた２個のパケットバッファ）
・新規通信のために確保されたパケットバッファＴ（四角形２００１に囲まれた４個のパケットバッファ）
具体的に、図１７のパケットバッファ管理部１４００ｂの状態における、告知ＷｉｎサイズＷａｄの算出方法について説明する。なお、本実施の形態においても、実施の形態２と同様に、１つのＴＣＰ通信の最大パケットバッファ数ＰＢｍａｘは８として説明を行う。

まず、ＳＴ８１１からＳＴ８２ｂにおいて、残りパケットバッファサイズＷｐｂを求める。パケットバッファ管理部１４００ｂにおける使用可能パケットバッファ数ＳＰＢｅｎは２個であることから、残りパケットバッファサイズＷｐｂは、使用可能パケットバッファ数と固定サイズＳ（１５００ｂｙｔｅ）との積により算出され、３０００ｂｙｔｅとなる。

次に、残りパケットサイズＷｐｂと、受信可能データ量Ｗｄを比較し（ＳＴ８３）、小さい方を告知Ｗｉｎサイズに設定する（ＳＴ８４、ＳＴ８５）。受信可能データ量Ｗｄは、ＤｍａｘとＤｃｕｒとの差分（１６Ｋｂｙｔｅ−１Ｋｂｙｔｅ）により、１５Ｋｂｙｔｅとなる。したがって、告知ＷｉｎサイズＷａｄは、受信可能データ量Ｗｄと残りパケットバッファサイズＷｐｂを比較し、小さい値である、残りパケットバッファサイズＷｐｂ（３０００ｂｙｔｅ）となる。

一方、実施の形態２によるＷｐｂの算出を行うと、ＰＢｍａｘが８、ＰＢｃｕｒが７であることから、ＰＢｒｅｍは１となり、Ｗｐｂは１×１５００となり、１５００ｂｙｔｅとなる。つまり、本実施の形態で説明した状況において、通信装置全体で使用可能パケットバッファ数を管理している本実施の形態に示す方法は、１つのＴＣＰ通信ごとにパケットバッファ数を管理した場合に比べ、大きな告知ウィンドウサイズを通信相手に告知することが可能である。

以上の構成により、１つのＴＣＰ通信においてソケットキューに最大保持データパケット数を越えるパケットバッファを関連付けられるような通信が発生しても、パケットバッファ管理部が新規に対象となるＴＣＰ通信に対して、パケットバッファを割り当てることが可能となる。そのため、通信装置のアプリケーションデータ処理のタイミングよりも、ソケットキューに最大保持データパケット数を関連付けられる方が早くパケットを受信した場合も、システム全体の保持データパケット数までパケットを受信することが可能となる。

（実施の形態４）
実施の形態４は、実施の形態２において、異常検出、および通知方法を新たに追加した形式である。本実施の形態の説明では、通信装置１の機能構成のうち、実施の形態２と共通していない部分、および、異常検出、および通知方法に関して説明する。

＜＜ネットワーク構成および構成図＞＞
図１８は、本発明の一実施の形態が係る通信装置１の機能構成例を示した図である。実施の形態２におけるネットワーク構成および構成図について、実施の形態２のネットワーク構成および構成図と共通していない部分について説明し、それ以外に関しては説明を省略する。

図１８に通信装置１の機能構成を以下に示す。異常通知部１２２８、ＲＳＴ生成部１２２９、Ｗｉｎ抑制部１２２２ｄ、表示部１６００を除き、他の機能は実施の形態１と同様のためここでは説明を省略する。Ｗｉｎ抑制部１２２２ｄは実施の形態１に記載の機能に加え、以下の機能を追加する。

（３−ｃ−４）Ｗｉｎ抑制部１２２２ｄ
Ｗｉｎ抑制部１２２２ｄは、ＡＣＫ生成部１２２４からのＷｉｎ受け渡し要求に対し、告知ＷｉｎサイズＷａｄを算出する際、告知ＷｉｎサイズＷａｄとして、残りパケットバッファサイズＷｐｂを連続で設定した回数を数える残りパケットバッファサイズ設定カウンタＣｎｔを保持する。残りバッファサイズ設定カウンタＣｎｔは、告知ＷｉｎサイズＷａｄとして、受信可能データ量Ｗｄを設定したら、０に戻される。残りパケットバッファサイズ設定カウンタＣｎｔが規定の回数を越えると、通信装置２が多数の少量データを含むＴＣＰセグメントを連続で送信してきていることと判断でき、異常な通信であると判断し、異常通知部１２２８に異常通知を行なう機能を追加する。

（３−ｉ）異常通知部１２２８
異常通知部１２２８は、Ｗｉｎ抑制部１２２２ｄより異常通知を受けると、以下の３つの処理を行なう。

（異常通知ａ）異常通知パケットの送信
異常を知らせる異常通知パケットを送信する（ＳＴ７１９）。異常通知パケットは、ＵＤＰ、ＩＣＭＰなどのプロトコルを用いて、パケットの中に異常を通知する文字列などのデータを含む。より具体的な例としては、ｓｙｓｌｏｇなどのＵＤＰプロトコルを利用してもよい。ｓｙｓｌｏｇメッセージとして、通信相手である、通信装置２のＩＰアドレス、サブネットマスク、異常を検出したＴＣＰ通信の通信装置１におけるポート番号、および、プロトコルなどを含める。また、異常通知パケットの宛先は、ユニキャストであっても、マルチキャストであってもよい。ユニキャスト送信の場合の宛先は、通信相手である通信装置２、通信ログを管理するサーバなどがあげられる。また、マルチキャスト送信の場合、同一ネットワークアドレスを持つ装置へのマルチキャスト、同一リンク内の装置へのマルチキャストなどがあげられる。

（異常通知ｂ）ＲＳＴパケットの送信
通信装置２との間の通信を強制的に切断するために、ＲＳＴパケットの送信を行なう。具体的には、通信装置２の異常を検出したＴＣＰ通信に対して、ＲＳＴ生成部１２２９にＲＳＴ生成要求を行なう。

（異常通知ｃ）ユーザへ通知
表示部１６００に通知を行い、異常な通信を検出した旨をユーザに通知する。通知する内容は、（ａ）異常通知パケットに含まれるデータなどを含む。

（３−ｊ）ＲＳＴ生成部１２２９
ＲＳＴ生成部は、異常通知部１２２８からの要求を受け（ＳＴ７２０）、ＴＣＰのプロトコル処理に基づいて、ＲＳＴのパケットを生成し、ＴＣＰ処理部に作成要求を行なう（ＳＴ７２１）。なお、本機能については、ＲＦＣ記載の範囲を逸脱しないため、詳細な説明を省略する。

（８）表示部１６００
異常通知部１２２８から通知を受けて（ＳＴ７２２）、ユーザへ異常を通知するために、文字列などを表示する機能を持つ。表示部１６００は、ＬＣＤ、ＰＤＰなどのディスプレイが使用される。なお、正常動作中もユーザへの異常通知以外の情報、画像、および映像などを表示させても構わない。

＜異常検出、および通知方法＞
異常な通信の検出方法、および、検出後の通知方法の一例について説明する。なお、ＴＣＰ受信部１２２６までのＴＣＰセグメントの受信処理、および、アプリケーション部１１００がデータの受信要求を行なう処理については、実施の形態２と同様であるため説明を省略する。

図１９は、図９の告知Ｗｉｎサイズ設定処理に、異常検出処理ルーチンを追加した一例の図である。ＡＣＫ生成部１２２４からの告知Ｗｉｎサイズの問い合わせから告知Ｗｉｎの設定を行なう処理までは、実施の形態２または実施の形態１と同様のため、ここでの説明は省略する。

ＡＣＫ生成部１２２４から告知Ｗｉｎサイズを設定後、異常検出ルーチンＳＴ４１０を実行する。

図２０を用いて、異常検出ルーチンの一例について説明を行なう。本実施の形態の一例では、残りパケットバッファ設定カウンタＣｎｔの異常通知閾値を５として説明を行なう。なお、異常通知閾値は、５以外でも構わない。

まず、異常検出ルーチンでは、告知Ｗｉｎサイズとして、残りパケットバッファサイズＷｐｂを設定したか、否かを確認する（ＳＴ４１１）。告知ＷｉｎサイズＷａｄとして残りパケットバッファサイズＷｐｂを設定した場合は、残りパケットバッファ設定カウンタＣｎｔを＋１する（ＳＴ４１２）。一方、受信可能データ量Ｗｄとした場合は、残りパケットバッファ設定カウンタＣｎｔを０とし（ＳＴ４１３）、処理を完了する。

告知ＷｉｎサイズＷａｄとして、残りパケットバッファサイズＷｐｂを設定し、残りパケットバッファ設定カウンタＣｎｔが異常通知閾値よりも小さい場合は、何もせずに完了する。

一方、異常通知閾値を越えていた場合、異常通知を行い（ＳＴ４１５）、処理を完了する。異常通知の方法については、上記で説明を行った（異常通知ａ）、（異常通知ｂ）、（異常通知ｃ）の通りである。

以上の構成により、異常なＴＣＰ通信を検出した際、通信相手に通知することにより、対向装置停止などの処置を行なうトリガとすることができる。また、ユーザに通知することにより、自身の装置に対して、異常な対向機器に対するフィルタリング、対向機器の確認、停止などの処置を行なうことができる。また、ログを管理するサーバや、マルチキャストにより、異常を通知することにより、異常通知パケットを受信した装置は、異常だと判断された装置が攻撃者であることを仮定し、事前に対処することができる。

（実施の形態５）
実施の形態５は、実施の形態２において、データ複写機能を追加した形態である。本実施の形態の説明では、通信装置１の機能構成のうち、実施の形態２と共通していない部分、および、データ複写機能に関して説明をする。

＜ネットワーク構成および構成図＞
図２１は、本発明の一実施の形態が係る通信装置１の機能構成例を示した図である。実施の形態５におけるネットワーク構成および構成図について、実施の形態２のネットワーク構成および構成図と共通していない部分について説明し、それ以外に関しては説明を省略する。

図２１に通信装置１の機能構成を以下に示す。ここでは、新規に追加するＣＰＵ負荷監視部１５００、データ複写部１２２７と、一部機能を追加する受信データ管理部１２２１ｃについて説明を行なう。これ以外の機能に関しては、実施の形態２または実施の形態１と同様のためここでは説明を省略する。

（７）ＣＰＵ負荷監視部１５００
ＣＰＵ負荷監視部１５００は、図１に記載のＣＰＵ１３の負荷を監視しており、ＣＰＵ使用率を管理している。ＣＰＵ使用率は、メモリ１４から読み出し、メモリ１４への書き込み処理、ＴＣＰを含むプロトコル処理、および、通信アプリケーションにおける処理などの通信のための処理だけでなく、その他のプログラムを実行しているときの処理も含む。ＣＰＵ使用率が高い状態をＣＰＵ負荷が高い、ＣＰＵ使用率が低い状態をＣＰＵ負荷が低いと定義する。ＣＰＵ負荷監視部１５００は、後述の（３−ａ−３）に示す受信データ管理部１２２１ｃからのＣＰＵ使用率の確認要求に対し、ＣＰＵ使用率が所定の値よりも低い場合に、受信データ管理部１２２１ｃに負荷低下通知を行なう機能を持つ。また、受信データ管理部１２２１ｃからの確認要求の有無に関わらず、ＣＰＵ負荷監視部１５００がＣＰＵ使用率を定期的に確認を行い、受信データ管理部１２２１ｃに負荷低下通知を行っても良い。

（３−ａ−３）受信データ管理部１２２１ｃ
受信データ管理部１２２１ｃは、ＴＣＰ受信部１２２６から受け取ったパケットバッファを、ソケットキューに関連付けする際に、ソケットキューが所定の条件を満たす場合に、ＣＰＵ負荷監視部１５００に対し、ＣＰＵ使用率の確認要求を行い、負荷低下通知を受け取った場合、データ複写部１２２７によりデータ複写を実施する機能を追加する。所定の条件としては、次のような条件が例として考えられる。

［所定条件］
（１）実受信データ量Ｄｃｕｒを、保持データパケット数ＰＢｃｕｒで除算した値が、所定の値（バイト）以下であること。

前記条件は、１パケットバッファ当たりに含まれるデータ量が少ない場合を意味する。

（２）保持データパケット数ＰＢｃｕｒが、最大保持データパケット数ＰＢｍａｘ以上であること。保持データパケット数数ＰＢｃｕｒが多くなり、最大保持データパケット数ＰＢｍａｘを越える場合、つまり、これ以上ソケットキューにつなげない場合を意味する。

（３）ソケットキューに接続するパケットバッファのデータ長が、所定の値（バイト）以下であること。ソケットキューに接続するがショートパケットである場合を意味する。

本実施の形態では、（１）の条件を一例として使用して説明を行なう。なお、必ずしも、（１）から（３）の条件を所定の条件とする必要はない。

（３−ｈ）データ複写部１２２７
ソケットキューに関連付けられているパケットバッファに格納されているデータを、同じソケットキューに関連付けられている他のパケットバッファに複写し、複写が完了したパケットバッファの開放要求を、パケットバッファ管理部１４００に対して行なう機能を持つ。

本実施の形態において、データの複写を行なうタイミングとして、（１）ＴＣＰ受信部１２２６が受信データ管理部１２２１ｃにパケットバッファを渡すタイミング、（２）受信データ管理部１２２１ｃからの確認要求の有無に関わらず、ＣＰＵ負荷監視部から負荷低下通知を受信データ管理部１２２１ｃに対して行なうタイミング、の２つのタイミングがある。

＜ＴＣＰパケット受信時＞
まず、（１）ＴＣＰ受信部１２２６が受信データ管理部１２２１ｃにパケットバッファを渡すタイミングについて説明する。なお、ＴＣＰ受信部１２２６までのＴＣＰパケットの受信処理、および、アプリケーション部１１００がデータの受信要求を行なう処理については、実施の形態１と同様であるため説明を省略する。

ＴＣＰ受信部１２２６が受信データ管理部１２２１ｃにパケットバッファを渡した後（ＳＴ７０２）、受信データ管理部１２２１ｃは、ソケットキューにパケットバッファを関連付ける。このとき、受信データ管理部１２２１ｃは、ソケットキューに関連付けられている現在パケットバッファ数ＰＢｃｕｒが、実受信データ量Ｄｃｕｒに対して所定のパケットバッファ数を越えていないかを確認する。本実施の形態では、ソケットキューに関連付けされているパケットバッファ全部の平均として、１パケットバッファサイズの半分以上が１つのパケットバッファに格納されていない場合にデータ複写を行なうこととし、データ複写を行なう条件は、次の演算より示すことができる。

実受信データ量Ｄｃｕｒを保持データパケット数ＰＢｃｕｒで除算した値が、１パケットバッファサイズ×１／２より小さいという条件であること。

前記条件を基に、保持データパケット数ＰＢｃｕｒが、ちょうど所定のパケットバッファ数である、とすることにより、所定のパケットバッファ数を算出すると、所定のパケットバッファ数は、２×実受信データ量Ｄｃｕｒを１パケットバッファサイズで除算した値となる。

ソケットキューに関連付けられている保持データパケット数ＰＢｃｕｒが、上記の所定のバッファ数を超えている場合、受信データ管理部１２２１ｃは、ＣＰＵ負荷監視部１５００にＣＰＵ使用率の確認要求を行なう。ＣＰＵ負荷監視部１５００は、ＣＰＵ使用率が低い場合、負荷低下通知を行なう（ＳＴ７３０）。負荷低下通知を受けた受信データ管理部１２２１ｃは、データの複写処理を行なう。

＜ＣＰＵ負荷監視部１５００からの負荷低下通知時＞
次に、（２）受信データ管理部１２２１ｃからの確認要求の有無に関わらず、ＣＰＵ負荷監視部から負荷低下通知を受信データ管理部１２２１ｃに対して行なうタイミングについて説明する。ＣＰＵ負荷監視部１５００は定期的に、ＣＰＵ使用率を確認し、ＣＰＵ負荷が低い場合は、受信データ管理部１２２１ｃに負荷低下通知を行なう（ＳＴ７３０）。受信データ管理部１２２１ｃは負荷低下通知を受けると、ソケットキューに関連付けられている保持データパケット数ＰＢｃｕｒが、実受信データ量Ｄｃｕｒに対して所定の値を越えているか否かを確認する。所定の値については、ＴＣＰパケット受信時と同様のため省略する。所定の値を越えていた場合は、データの複写処理を行なう。

＜データの複写処理＞
図２２を用いて、データ複写処理の一例を説明する。データの複写処理は、ソケットキューの先頭に関連付けられているパケットバッファから順に、次に関連付けられているパケットバッファ（以降、次パケットバッファと呼ぶ）に格納されているデータを対象としているパケットバッファに複写することを繰り返す。

まず、ソケットキューの先頭に関連付けられているパケットバッファを対象パケットバッファとし、次パケットバッファが存在するかを確認する（ＳＴ３１１）。次パケットバッファが存在しない場合は、対象パケットバッファが最後のパケットバッファであるため、現在パケットバッファ数を更新し（ＳＴ３１８）、データ複写処理は完了とする。

一方、次パケットバッファが存在する場合は、対象パケットバッファの空きパケットバッファサイズと、次パケットバッファに格納しているデータサイズを比べ（ＳＴ３１２）、空きパケットバッファが大きい場合は、次パケットバッファに格納されているデータを全て複写し（ＳＴ３１３）、小さい場合は、空きパケットバッファサイズ分を複写する（ＳＴ３１４）。次パケットバッファのデータを全て複写した場合は、そのパケットバッファは不要であるため、パケットバッファ管理部１４００に対して、開放要求し、ソケットキューとの関連付けを外し（ＳＴ３１５）、次パケットバッファの次パケットバッファを対象パケットバッファの次パケットバッファに変更する（ＳＴ３１６）。開放要求を受けたパケットバッファ管理部１４００は、パケットバッファを開放する。この処理が完了したら、対象パケットバッファを次パケットバッファとし、ＳＴ３１１に戻り、ソケットキューの最後のパケットバッファまで繰り返す。この処理により多数のパケットバッファに格納されていたデータを少数のパケットバッファに格納することができる。

なお、本実施の形態の一例では、データ複写処理を図２２の処理方法によって説明したが、多数のパケットバッファに格納されていたデータを少数のパケットバッファに複写できれば、必ずしも図２２の処理方法である必要はない。また、ＳＴ３１２において、対象パケットバッファの空きパケットバッファサイズと、次パケットバッファに格納しているデータサイズを比べ、空きパケットバッファが大きい場合は、次パケットバッファに格納されているデータを全て複写するように説明したが、必ずしも空きパケットバッファサイズを全て埋めるデータサイズを複写する必要はない。

図２３を用いて、ＴＣＰパケット受信時のデータ複写処理の一例について、さらに具体的に説明を行なう。図２３は、ＴＣＰパケットを受信し、ソケットキューに関連付けた後の状態であり、１パケットバッファサイズは１Ｋｂｙｔｅ、現在パケットバッファ数は１０個であり、１つのパケットバッファには１００ｂｙｔｅのデータが格納されている。この状態において、所定のパケットバッファ数は２×１０００／１０００より２となり、保持データパケット数は、１０個であるから、所定のパケットバッファ数を越えている。そのため、ＣＰＵ負荷監視部１５００にＣＰＵ負荷の確認要求を行い、負荷低下通知を受けた場合に、データ複写処理を図２２の処理方法により実施する。データ複写処理中に、不要となったパケットバッファ９個を全て開放要求し、保持データパケット数を１に更新する。

以上の構成により、本実施の形態は、実施の形態１から実施の形態４に記載した方法により、告知ウィンドウサイズを急激に下げることによるスループットの低下を防止するという効果が得られる。

具体的には、データ複写を行なうことにより、保持データパケット数ＰＢｃｕｒが少なくなるため、残り保持データパケット数ＰＢｒｅｍが多くなり、急激に告知ＷｉｎサイズＷａｄを下げることを防ぎ、スループットを下げることを防ぐことができる。

また、副次的な効果として、ソケットキューに関連付けられているパケットバッファ数を少なくすることにより、効率的にデータをアプリケーション部が受信することができる。また、ＣＰＵ負荷監視部１５００から定期的に負荷停止通知を行なうことにより、ＴＣＰパケットの受信とは無関係に、データの複写機能を実施することができる。

（実施の形態６）
実施の形態６は、実施の形態２において、ＭＡＣ受信可能量算出部１３１１を追加した形態である。本実施の形態の説明では、通信装置１の機能構成のうち、実施の形態２と共通していない部分、および、ＭＡＣ受信可能量算出部１３１１に関して説明をする。

＜ネットワーク構成および構成図＞
図２９は、本発明の一実施の形態が係る通信装置１の機能構成例を示した図である。実施の形態６におけるネットワーク構成および構成図について、実施の形態２のネットワーク構成および構成図と共通していない部分について説明し、それ以外に関しては説明を省略する。

ＭＡＣ処理部１３１０と、ＭＡＣ処理部１３１０におけるＦＩＦＯメモリの役割について説明する。

ＭＡＣ処理部１３１０は、ネットワークから到達したパケットを最初に受信する。その後、所定のタイミングで、Ｉｎｔｅｒｆａｃｅ処理部１２４０がパケットバッファに格納する。このとき、ＭＡＣ処理部１３１０は、ＭＡＣ処理部１３１０からＩｎｔｅｒｆａｃｅ処理部１２４０に引き上げられるまで、受信したパケットを保持しておく必要がある。その受信したパケットを保持しておくハードウェアがＦＩＦＯメモリである。つまり、通信装置１に到達したパケットは、必ずＦＩＦＯメモリに一時的に保持され、Ｉｎｔｅｒｆａｃｅ処理部１２４０によって、パケットバッファに格納される。そのため、ＦＩＦＯメモリに空きがない場合、通信装置１内に使用可能なパケットバッファが多く残っていたとしても、通信装置１は、ネットワークから到達したパケットをＭＡＣ処理部１３１０でロスすることになる。パケットロスが発生すると、ＴＣＰの再送、および、通信装置２による輻輳制御が発生し、結果的にスループットが低下する。

図２９に通信装置１の機能構成を以下に示す。ここでは、新規に追加するＭＡＣ受信可能量算出部１３１１と、実施の形態２とは一部機能の異なるＷｉｎ抑制部１２２２ｅについて説明を行なう。これ以外の機能に関しては、実施の形態２と同様のため、ここでは説明を省略する。なお、ＭＡＣ受信可能量算出部１３１１は、図２９ではＭＡＣ処理部１３１０に含まれているが、ＭＡＣ処理部１３１０以外に配置されても構わない。

（９）ＭＡＣ受信可能量算出部１３１１
最初に、ＭＡＣ受信可能量算出部１３１１について説明する。ＭＡＣ受信可能量算出部１３１１は、ＭＡＣ処理部１３１０におけるＦＩＦＯメモリの使用状態を監視しており、ＦＩＦＯメモリの空き容量から算出されるＭＡＣ受信可能ウィンドウサイズＷｍａｃを算出し、Ｗｉｎ抑制部１２２２ｂに通知する機能を持つ。なお、ＭＡＣ処理部１３１０におけるＦＩＦＯメモリのメモリ管理方式は、パケット単位による管理、受信データサイズによる管理が考えられるが、いずれの管理方式でも構わない。本実施の形態では、パケット単位によるデータ管理方式として説明を行う。

また、Ｗｉｎ抑制部１２２２ｅの実施の形態２と異なる点は、ＭＡＣ受信可能量算出部１３１１にＭＡＣ受信可能ウィンドウサイズＷｍａｃを問い合わせ、告知Ｗｉｎサイズの算出時に用いる点である。

＜＜告知Ｗｉｎサイズの算出方法＞＞
本実施の形態では、以下で説明を行なう告知Ｗｉｎサイズの算出方法により、ＭＡＣ処理部１３１０のＦＩＦＯメモリの空き容量を考慮することにより、ＭＡＣ処理部１３１０におけるパケットロスを回避し、ＴＣＰ再送の発生を抑制する。

図３０を用いて、Ｗｉｎ制御部１２２２における告知ＷｉｎサイズＷａｄの算出方法の説明を行なう。

本実施の形態では、告知ＷｉｎサイズＷａｄの算出を説明するため、１パケットバッファに１５００ｂｙｔｅのデータを格納可能であり、最大保持データパケット数Ｐｍａｘを８個、最大保持データ量Ｄｍａｘを８１９２ｂｙｔｅとする。また、ＭＡＣ処理部１３１０のＦＩＦＯメモリは最大６パケットまで保持可能とする。

なお、ここでは、ＭＡＣ処理部１３１０のＦＩＦＯメモリは、４パケットは保持されており、実施の形態２と同様に、ＴＣＰパケット１パケットに１００ｂｙｔｅのデータを含むパケット５個がソケットキューに関連付けられている場合を用いて、説明を行なう。

受信可能データ量の取得（ＳＴ８１）、残りパケットバッファサイズＷｐｂの算出（ＳＴ８２）は、実施の形態２と同様のため、説明を省略する。

（Ｃａｌｃ−４）ＭＡＣ受信可能ウィンドウサイズＷｍａｃの算出（ＳＴ８７）
Ｗｉｎ抑制部１２２２ｅは、ＭＡＣ受信可能量算出部１３１１に問い合わせる。ＭＡＣ受信可能量算出部１３１１は、ＭＡＣ処理部１３１０におけるＦＩＦＯメモリの使用状況を確認する。本実施の形態では、データは４パケット保持されており、残り２パケット保持することができる。ＭＡＣ受信可能量算出部１３１１は、２×１５００ｂｙｔｅ＝３０００ｂｙｔｅをＭＡＣ受信可能ウィンドウサイズＷｍａｃとして、Ｗｉｎ抑制部１２２２ｅに通知する。

なお、Ｅｔｈｅｒｎｅｔ（登録商標）の伝送速度が遅い、ＲＴＴが長いなどの要因で、次のパケットがネットワークから到達するまでにＦＩＦＯメモリからパケットバッファに引き上げることができる場合、その引き上げ可能なパケット処理数をＷｍａｃ算出時に考慮してもよい。

（Ｃａｌｃ−５）告知ＷｉｎサイズＷａｄの設定（ＳＴ８８、ＳＴ８６）
Ｗｉｎ抑制部１２２２ｅは、ＳＴ８１にて算出された受信可能データ量Ｗｄ、残りパケットバッファサイズＷｐｂ、ＭＡＣ受信可能ウィンドウサイズＷｍａｃを比較し、最小となる値を告知ウィンドウサイズＷａｄとして設定する（ＳＴ８８）。本実施の形態では、受信可能データ量Ｗｄは７６９２ｂｙｔｅ、残りパケットバッファサイズＷｐｂは４５００ｂｙｔｅ、ＭＡＣ受信可能ウィンドウサイズＷｍａｃは３０００ｂｙｔｅであるため、ＭＡＣ受信可能ウィンドウサイズＷｍａｃが最小となる。よって、告知ＷｉｎサイズＷａｄにＭＡＣ受信可能ウィンドウサイズＷｍａｃは３０００ｂｙｔｅを設定する。

設定した告知ＷｉｎサイズＷａｄをＡＣＫ生成部に渡す（ＳＴ８６）。

以上の構成により、ＭＡＣ受信可能ウィンドウサイズＷｍａｃを考慮することにより、到達したパケットを受信できなくなることを防止し、ＴＣＰパケットの再送を防ぐことができる。本構成は、通信装置１の告知Ｗｉｎサイズ分をバースト的に送信するような通信装置２が通信相手である場合に、より効果が高い。

（実施の形態７）
実施の形態７は、実施の形態２において、ＲＴＴ受信可能量算出部１２５０を追加し、パケットバッファ管理部１４００の代わりに実施の形態３で説明したパケットバッファ管理部１４００ｂを用いた形態である。本実施の形態の説明では、通信装置１の機能構成のうち、実施の形態２と共通していない部分、および、ＲＴＴ受信可能量算出部１２５０に関して説明をする。なお、パケットバッファ管理部１４００ｂは、パケットバッファ管理部１４００に管理する値に加え、通信装置全体の残りパケットバッファ数ＳＰＢｒｅｍ、既存のＴＣＰ通信（コネクション）が使用可能パケットバッファ数の使用可能閾値Ｔなどを管理している。本実施の形態では、使用可能閾値Ｔは０とし、通信装置全体の残りパケットバッファ数ＰＢｒｅｍ＝通信装置１全体で使用可能パケットバッファ数ＳＰＢｅｎとして、説明を行う。

＜ネットワーク構成および構成図＞
図３１は、本発明の一実施形態が係る通信装置１の機能構成例を示した図である。実施の形態７におけるネットワーク構成および構成図について、実施の形態２のネットワーク構成および構成図と共通していない部分について説明し、それ以外に関しては説明を省略する。

図３１に通信装置１の機能構成を以下に示す。ここでは、新規に追加するＲＴＴ受信可能量算出部１２５０と、一部機能を変更するＷｉｎ抑制部１２２２ｆについて説明を行なう。これ以外の機能に関しては、実施の形態２と同様のため、ここでは説明を省略する。なお、ＲＴＴ受信可能量算出部１２５０は、図３１ではＴＣＰ処理部１２２０に含まれているが、必ずしもＴＣＰ処理部１２２０に含まれていなくても構わない。

（１０）ＲＴＴ受信可能量算出部１２５０
ＲＴＴ受信可能量算出部１２５０は、ＴＣＰのＲＴＴ（ＲＯＵＮＤ ＴＲＩＰ ＴＩＭＥ）、単位時間あたりに処理するパケット数から、ＲＴＴ間に処理可能なパケット数であるＲＴＴ受信可能パケットサイズＷｒｔｔを算出し、Ｗｉｎ抑制部１２２２ｆに通知する機能（ＳＴ７４３）を持つ。ここで、「単位時間あたりに処理するパケット数」、および、「ＲＴＴ間に処理可能なパケット数」の「処理」は、パケットバッファに格納して保持していたデータを、アプリケーション１１００が引き上げ、そのデータを保持するのに使用していたパケットバッファが開放する処理まで、を指す。

ＲＴＴ受信可能量算出部１２５０におけるＲＴＴの算出方法の一例を示す。ＲＴＴの算出方法として、通信装置１がＴＣＰパケット受信処理中に、通信装置１がデータパケット受信を通知するために送信するＡＣＫパケットの送信時刻と、そのＡＣＫパケットに起因して通信装置２が送信するデータパケットの受信時刻、の差分から算出される方法を用いる。具体的には、ＴＣＰ送信部１２２５より送信されるＡＣＫパケットの送信時刻（ＳＴ７４１）と、ＴＣＰ受信部１２２６で受信する、そのＡＣＫパケットに起因するデータパケットの受信時刻（ＳＴ７４２）をそれぞれ監視しておき、その差分により、ＲＴＴを算出する。ＡＣＫパケットとデータパケットの関連の判断基準は、通信装置１が送信するＡＣＫパケットに含むＮｕｍと、通信装置２が送信するデータパケットのＳｅｑが同一の場合、ＡＣＫパケットに対するデータパケットとするものである。

なお、本実施の形態では、ＡＣＫパケットとそれに起因するデータパケットの関連によりＲＴＴを算出したが、ＴＣＰ接続確立（３ウェイハンドシェイク）時のＳＹＮパケットに対する、ＳＹＮ＋ＡＣＫパケットの受信時刻より算出してもよい。また、ＴＣＰパケット以外のプロトコルにより、ＲＴＴを算出しても構わない。

次に、単位時間あたりに処理するパケット数の取得方法について説明する。単位時間あたりに処理するパケット数は、事前に与えられていてもよいし、通信中にＡＰＩ部１２１０を介して、動的に与えられてもよい。また、パケットバッファ管理部１４００がアプリケーション１１００におけるパケットバッファ開放処理を監視しており、受信動作中の開放処理の間隔から統計的に算出を行ってもよい。

Ｗｉｎ抑制部１２２２ｆの実施の形態２と異なる点は、ＲＴＴ受信可能量算出部１２５０にＲＴＴ受信可能パケットサイズＷｒｔｔの問い合わせを行い、告知Ｗｉｎサイズの算出時に、ＲＴＴ受信可能パケットサイズＷｒｔｔを用いる点である。

＜＜告知Ｗｉｎサイズの算出方法＞＞
本実施の形態では、以下で説明を行なう告知Ｗｉｎサイズの算出方法により、ＲＴＴ間に処理可能なパケット数を考慮することにより、パケットロスを抑制し、ＴＣＰの転送速度の低下を抑制することができる。

図３２を用いて、Ｗｉｎ制御部１２２２における告知ＷｉｎサイズＷａｄの算出方法の説明を行なう。

本実施の形態では、告知ＷｉｎサイズＷａｄの算出を説明するため、１パケットバッファに１５００ｂｙｔｅのデータを格納可能であり、通信装置全体の残りパケットバッファ数ＰＢｒｅｍを１０個、最大保持データ量Ｄｍａｘを８１９２ｂｙｔｅとする。

なお、ここでは、ＴＣＰパケット１パケットに１００ｂｙｔｅのデータを含むパケット１個がソケットキューに関連付けられている場合を用いて、説明を行なう。また、ＲＴＴは１０ｍｓｅｃとし、単位時間あたりに処理するパケット数は事前に通知されており、１０ｍｓｅｃあたり、５個とする。

受信可能データ量の取得（ＳＴ８１）、残りパケットバッファサイズＷｐｂの算出（ＳＴ８２ｂ）は、実施の形態２と同様のため、説明を省略する。

（Ｃａｌｃ−６）ＲＴＴ受信可能パケットサイズＷｒｔｔの算出（ＳＴ８９１）
Ｗｉｎ抑制部１２２２ｆは、ＲＴＴ受信可能量算出部１２５０に問い合わせる。ＲＴＴ受信可能量算出部１２５０は、事前にＴＣＰ送信部１２２５のＡＣＫパケット送信時刻と、ＴＣＰ受信部１２２６での、それに起因するデータパケットの受信時刻よりＲＴＴを算出しておく。ＲＴＴ受信可能量算出部１２５０は、ＲＴＴと、単位時間あたりに処理するパケット数より、ＲＴＴ受信可能パケットサイズＷｒｔｔをＷｒｔｔ＝ＲＴＴ×（単位時間あたりに処理するパケット数）×（パケットバッファサイズ）により算出する。本実施の形態では、ＲＴＴは１０ｍｓｅｃ、１０ｍｓｅｃあたりに処理可能なパケット数は５個、パケットバッファサイズは、１５００ｂｙｔｅ、保持データパケット数は１、であるから、５×１５００＝７５００ｂｙｔｅとなる。

（Ｃａｌｃ−７）告知ＷｉｎサイズＷａｄの設定（ＳＴ８９２）
Ｗｉｎ抑制部１２２２ｆは、ＳＴ８２により算出された残りパケットバッファサイズＷｐｂと、ＲＴＴ受信可能パケットサイズＷｒｔｔと、ＳＴ８１において算出された受信可能データ量Ｗｄ、との最小値を告知ウィンドウサイズＷａｄとして設定する（ＳＴ８８）。本実施の形態では、受信可能データ量Ｗｄは８０９２ｂｙｔｅ、残りパケットバッファサイズＷｐｂは１０５００ｂｙｔｅ、ＲＴＴ受信可能パケットサイズＷｒｔｔは、７５００ｂｙｔｅである。よって、告知ＷｉｎサイズＷａｄに最小値である、ＲＴＴ受信可能パケットサイズＷｒｔｔ７５００ｂｙｔｅを設定する。

最後に、設定した告知ＷｉｎサイズＷａｄをＡＣＫ生成部に渡す（ＳＴ８６）。

なお、ＲＴＴ受信可能サイズＷｒｔｔを算出する際、ＲＴＴを継続的に計測し、増加傾向にあればＷｒｔｔを増加、減少傾向にあればＷｒｔｔを減少など、統計情報を算出し、その情報により、ＲＴＴ受信可能サイズＷｒｔｔを上記の算出値から増減させてもよい。

＜＜パケットロス時のＷｒｔｔ減算処理＞＞
なお、ＲＴＴ受信可能パケットサイズＷｒｔｔを算出する際に、パケットロスを考慮してもよい。

通信装置１は、ネットワーク揺らぎなどの影響により、ＭＡＣ処理部１３１０のＦＩＦＯメモリに空きがない場合、パケットをロスする可能性がある。パケットをロスした場合、通信装置１は、ロスしたパケットに対するＡＣＫパケットを送信しないため、通信装置２は、ＴＣＰの輻輳制御を行い、１度に送信するデータ量を段階的に抑制する。この処理を繰り返すと、結果として転送速度が低下する。そのため、ＲＴＴ受信可能量算出部１２５０は、パケットロスの発生を、通信装置２の輻輳制御による送信データ量の低下と判断し、ＲＴＴ受信可能バッファサイズＷｒｔｔを一定量減らすことで、通信装置２の輻輳制御による送信データ量の低下を防ぐ。

パケットロスを考慮する場合、ＭＡＣ処理部１３１０は、ネットワークから到達したパケットをＦＩＦＯメモリに空きがなく、格納できなかったことを記憶するパケットロス記憶機能と、パケットロスの情報をＷｉｎ抑制部１２２２ｂに通知する機能（ＳＴ７４４）をさらに有するものとする。

パケットロスを考慮した算出方法の一例を、図３３を用いて示す。図３３は、図３２の処理に、ＳＴ８９１ｂを追加したものである。

ＲＴＴ受信可能量算出部１２５０は、図３２と同様の処理により受信可能パケットサイズＷｒｔｔを算出後（ＳＴ８９１）、ＭＡＣ処理部１３１０に対し、前回のＡＣＫパケット送信以降にパケットロスが発生したかを問い合わせる。ＭＡＣ処理部１３１０は、問い合わせに対し、パケットロス数を通知し、ＲＴＴ受信可能量算出部１２５０は、パケットロス数とパケットバッファサイズを基づいてロス検知緩和サイズを算出し、ＲＴＴ受信可能サイズＷｒｔｔから減算する（ＳＴ８９３）。ロス検知緩和サイズはパケットロス数とパケットバッファサイズの積により算出してもよい。

以降の処理に関しては、図３２と同様であるため、説明を省略する。

以上の構成により、ＲＴＴ受信可能パケットサイズＷｒｔｔを告知ウィンドウサイズＷａｄとして設定することで、通信装置２からの、受信可能なパケットサイズを越えるパケットの送信を抑制し、ＴＣＰの転送速度の低下を抑制することができる。また、ＭＡＣ処理部１３１０におけるパケットロスを検知し、ＲＴＴ受信可能サイズを減算することで、通信装置２の輻輳制御による送信データ量の低下を防ぐことができる。

なお、輻輳制御を検知する方法は、パケットのロスを検知する方法以外でも構わない。

（実施の形態８）
実施の形態８は、実施の形態２において、Ｗｐｂ調整量算出部１２５１を追加した形態である。本実施の形態の説明では、通信装置１の機能構成のうち、実施の形態２と共通していない部分、および、Ｗｐｂ調整量算出部１２５１に関して説明をする。

＜ネットワーク構成および構成図＞
図３４は、本発明の一実施の形態が係る通信装置１の機能構成例を示した図である。実施の形態８におけるネットワーク構成および構成図について、実施の形態２のネットワーク構成および構成図と共通していない部分について説明し、それ以外に関しては説明を省略する。

図３４に通信装置１の機能構成を以下に示す。ここでは、新規に追加するＷｐｂ調整量算出部１２５１と、一部機能を変更する受信データ管理部１２２１ｄ、Ｗｉｎ抑制部１２２２ｇについて説明を行なう。これ以外の機能に関しては、実施の形態２と同様のため、ここでは説明を省略する。なお、Ｗｐｂ調整量算出部１２５１は、図３４ではＴＣＰ処理部１２２０に含まれているが、必ずしもＴＣＰ処理部１２２０に含まれていなくても構わない。

受信データ管理部１２２１ｄは、アプリケーション１１００からのデータ受信要求が発生する時刻、および保持していたパケットバッファの開放数を監視し、単位時間当たりのパケットバッファの開放数を単位時間処理パケット数として管理する機能をさらに有する。

Ｗｐｂ調整量算出部１２５１は、Ｗｐｂ調整量αｒｔｔを算出し、Ｗｉｎ抑制部１２２２ｇに通知する機能を持つ。本実施の形態では、Ｗｐｂ調整量αｒｔｔの算出方法の一例として、受信データ管理部１２２１ｄが管理している単位時間処理パケット数に基づいて算出する方法を説明する。

Ｗｉｎ抑制部１２２２ｇは、告知ＷｉｎサイズＷａｄを設定する際、残りパケットバッファＷｐｂに対し、Ｗｐｂ調整量αｒｔｔに加算する機能をさらに有する。

＜＜告知Ｗｉｎサイズの算出方法＞＞
本実施の形態では、以下で説明を行なう告知Ｗｉｎサイズの算出方法により、次のパケットが到達するまでの時間に処理可能なパケット数を考慮することにより、告知Ｗｉｎサイズの急激な低下を抑制することにより、ＴＣＰの転送速度の低下を抑制することができる。

図３５を用いて、Ｗｉｎ抑制部１２２２ｇにおける告知ＷｉｎサイズＷａｄの算出方法の説明を行なう。

本実施の形態では、１パケットバッファに１５００ｂｙｔｅのデータを格納可能であり、最大保持データパケット数ＰＢｍａｘを８個、最大保持データ量Ｄｍａｘを８１９２ｂｙｔｅとする。

また、ここでは、ＴＣＰパケット１パケットに１００ｂｙｔｅのデータを含むパケット６個がソケットキューに関連付けられている場合を用いて、説明を行なう。また、単位時間処理パケット数は、受信データ管理部１２２１ｄがソケットキューにパケットバッファが関連づけられる時刻、およびアプリケーション１１００からの受信要求を受け、パケットバッファが開放される時刻を監視し、統計的に算出されており、１０ｍｓｅｃあたり、３個とする。さらに本実施の形態では、ＲＴＴを次のデータパケットを受信するまでの時間として利用し、ＲＴＴを１０ｍｓｅｃとする。ＲＴＴの算出方法は実施の形態７の記載と同様のため、説明を省略する。

受信可能データ量の取得（ＳＴ８１）、残りパケットバッファサイズＷｐｂの算出（ＳＴ８２）は、実施の形態２と同様のため、説明を省略する。

（Ｃａｌｃ−８）Ｗｐｂ調整量αｒｔｔの算出（ＳＴ８９３）
Ｗｉｎ抑制部１２２２ｇは、Ｗｐｂ調整量算出部１２５１に問い合わせ、Ｗｐｂ調整量αｒｔｔを取得する。以下に、Ｗｐｂ調整量αｒｔｔの算出方法の一例を示す。

最初に、Ｗｐｂ調整量算出部１２５１は、Ｗｐｂ調整量αｒｔｔを算出する。本実施の形態では、ＲＴＴは１０ｍｓｅｃ、１０ｍｓｅｃあたりの単位時間処理数は３個、パケットバッファサイズは、１５００ｂｙｔｅであるから、Ｗｐｂ調整量αｒｔｔは、３×１５００＝４５００ｂｙｔｅを処理可能となる。

図３６は、保持データパケット数ＰＢｃｕｒ、残りパケットバッファ数ＰＢｒｅｍ、Ｗｐｂ調整量αｒｔｔの関係図を示したものである。実施の形態２では、残りパケットバッファ数ＰＢｒｅｍと固定サイズＳの積により、残りパケットバッファサイズＷｐｂを算出し、告知Ｗｉｎサイズの候補としていた。一方、本実施の形態では、次のパケットが到達するまでに処理できるパケットバッファ数を考慮し、Ｗｐｂ調整量αｒｔｔを残りパケットバッファサイズＷｐｂに加える。図３６では、Ｗｐｂ調整量αｒｔｔが、保持データパケット数ＰＢｃｕｒのうち、次のパケットが到達するまでに処理できるパケット数であることを示している。

なお、Ｗｐｂ調整量αｒｔｔの算出方法は、本実施の形態で説明した方法の他に、ＭＡＣ処理部１３１０への問い合わせ結果から得られるパケットロスの発生量に基づいて、Ｗｐｂ調整量αｒｔｔを減らす方法、などの方法が挙げられる。

（Ｃａｌｃ−８）告知ＷｉｎサイズＷａｄの設定（ＳＴ８９４）
Ｗｉｎ抑制部１２２２ｇは、残りパケットバッファサイズＷｐｂに、Ｗｐｂ調整量αｒｔｔを加算し、ＳＴ８１において渡された受信可能データ量Ｗｄと、を比較し、小さい値となる方を告知ウィンドウサイズＷａｄとして設定する。本実施の形態では、受信可能データ量Ｗｄは７６９２ｂｙｔｅ、残りパケットバッファサイズＷｐｂ＋Ｗｐｂ調整量αｒｔｔは（（８−６）×１５００＋４５００）＝７５００ｂｙｔｅである。小さい方を告知ＷｉｎサイズＷａｄとするので、告知ＷｉｎサイズＷａｄに残りパケットバッファサイズＷｐｂ＋Ｗｐｂ調整量αｒｔｔを設定する。

設定した告知ＷｉｎサイズＷａｄをＡＣＫ生成部に渡す（ＳＴ８６）。

以上の構成により、Ｗｐｂ調整量αｒｔｔを残りパケットバッファサイズＷｐｂサイズに加算することで、残りパケットバッファサイズの減少による、告知Ｗｉｎサイズの急激な低下を防ぐことができ、ＴＣＰの転送速度の低下を抑制することができる。

（その他変形例）
なお、本発明を上記実施の形態に基づいて説明してきたが、本発明は、上記の実施の形態に限定されないのはもちろんである。以下のような場合も本発明に含まれる。

（１）上記の各装置は、具体的には、マイクロプロセッサ、ＲＯＭ、ＲＡＭ、などから構成されるコンピュータシステムである。前記ＲＡＭには、コンピュータプログラムが記憶されている。前記マイクロプロセッサが、前記コンピュータプログラムにしたがって動作することにより、各装置は、その機能を達成する。ここでコンピュータプログラムは、所定の機能を達成するために、コンピュータに対する指令を示す命令コードが複数個組み合わされて構成されたものである。

（２）上記の各装置を構成する構成要素の一部または全部は、１個のシステムＬＳＩ（Ｌａｒｇｅ Ｓｃａｌｅ Ｉｎｔｅｇｒａｔｉｏｎ：大規模集積回路）から構成されているとしてもよい。システムＬＳＩは、複数の構成部を１個のチップ上に集積して製造された超多機能ＬＳＩであり、具体的には、マイクロプロセッサ、ＲＯＭ、ＲＡＭなどを含んで構成されるコンピュータシステムである。前記ＲＡＭには、コンピュータプログラムが記憶されている。前記マイクロプロセッサが、前記コンピュータプログラムにしたがって動作することにより、システムＬＳＩは、その機能を達成する。

（３）上記の各装置を構成する構成要素の一部または全部は、各装置に脱着可能なＩＣカードまたは単体のモジュールから構成されているとしてもよい。前記ＩＣカードまたは前記モジュールは、マイクロプロセッサ、ＲＯＭ、ＲＡＭなどから構成されるコンピュータシステムである。前記ＩＣカードまたは前記モジュールは、上記の超多機能ＬＳＩを含むとしてもよい。マイクロプロセッサが、コンピュータプログラムにしたがって動作することにより、前記ＩＣカードまたは前記モジュールは、その機能を達成する。このＩＣカードまたはこのモジュールは、耐タンパ性を有するとしてもよい。

（４）本発明は、上記に示す方法であるとしてもよい。また、これらの方法をコンピュータにより実現するコンピュータプログラムであるとしてもよいし、前記コンピュータプログラムからなるデジタル信号であるとしてもよい。

また、本発明は、前記コンピュータプログラムまたは前記デジタル信号をコンピュータ読み取り可能な記録媒体、例えば、フレキシブルディスク、ハードディスク、ＣＤ−ＲＯＭ、ＭＯ、ＤＶＤ、ＤＶＤ−ＲＯＭ、ＤＶＤ−ＲＡＭ、ＢＤ（Ｂｌｕ−ｒａｙ Ｄｉｓｃ）、半導体メモリなどに記録したものとしてもよい。また、これらの記録媒体に記録されている前記デジタル信号であるとしてもよい。

また、本発明は、前記コンピュータプログラムまたは前記デジタル信号を、電気通信回線、無線または有線通信回線、インターネットを代表とするネットワーク、データ放送等を経由して伝送するものとしてもよい。

また、本発明は、マイクロプロセッサとメモリを備えたコンピュータシステムであって、前記メモリは、上記コンピュータプログラムを記憶しており、前記マイクロプロセッサは、前記コンピュータプログラムにしたがって動作するとしてもよい。

また、前記プログラムまたは前記デジタル信号を前記記録媒体に記録して移送することにより、または前記プログラムまたは前記デジタル信号を前記ネットワーク等を経由して移送することにより、独立した他のコンピュータシステムにより実施するとしてもよい。

（５）上記実施の形態及び上記変形例をそれぞれ組み合わせるとしてもよい。

本発明は、ＴＣＰに基づく受信処理を行なうあらゆる通信装置に適用可能である。

本発明の実施の形態１における告知Ｗｉｎサイズの算出方法フロー図 実施の形態におけるネットワーク構成図、および通信装置１の構成図 本発明の実施の形態１における通信装置１の機能構成図 本発明の実施の形態１における最大保持データパケット数、保持データパケット数、および、残りデータパケット数の関係図 本発明の実施の形態１における１パケットに含まれるデータ量、最大保持データパケット数、現在保持データパケット数、残り保持データパケット数の関係図 本発明の実施の形態１における１００ｂｙｔｅのデータパケット受信時の告知ウィンドウを示すグラフ 本発明の実施の形態１における１５００ｂｙｔｅのデータパケット受信時の告知ウィンドウを示すグラフ 本発明の実施の形態２における通信装置１の機能構成図 本発明の実施の形態２における告知Ｗｉｎサイズの算出方法フロー図 本発明の実施の形態２における最大保持データ量、実受信データ量、および、受信可能データ量の関係図 本発明の実施の形態２における最大保持データパケット数、保持データパケット数、および、残りデータパケット数の関係図 本発明の実施の形態２における１パケットに含まれるデータ量、最大保持データパケット数、現在保持データパケット数、残り保持データパケット数の関係図 本発明の実施の形態２における１００ｂｙｔｅのデータパケット受信時の告知ウィンドウを示すグラフ 本発明の実施の形態３における通信装置１の機能構成図 本発明の実施の形態３における告知Ｗｉｎサイズの算出方法フロー図 本発明の実施の形態３における通信装置全体のパケットバッファ数、使用されているパケットバッファ数、および、使用可能パケットバッファ数の関係図 本発明の実施の形態３における１パケットに含まれるデータ量、通信装置全体のパケットバッファ数、使用されているパケットバッファ数、および、使用可能パケットバッファ数の関係図 本発明の実施の形態４における通信装置１の機能構成図 本発明の実施の形態４における告知Ｗｉｎサイズの算出方法フロー図 本発明の実施の形態４における異常検知ルーチンのフロー図 本発明の実施の形態５における通信装置１の機能構成図 本発明の実施の形態５におけるデータ複写ルーチンのフロー図 本発明の実施の形態５におけるデータ複写の動作図 従来技術におけるネットワーク構成図、および通信装置１の構成図 ウィンドウ制御概要を示すシーケンス図 パケット受信処理を示すシーケンス図 受信側装置の受信処理概要を示すシーケンス図 最大保持データ量、実受信データ量、および、受信可能データ量の関係を示す一例の図 本発明の実施の形態６における通信装置１の機能構成図 本発明の実施の形態６における告知Ｗｉｎサイズの算出方法フロー図 本発明の実施の形態７における通信装置１の機能構成図 本発明の実施の形態７における告知Ｗｉｎサイズの算出方法フロー図 本発明の実施の形態７における告知Ｗｉｎサイズの算出方法フロー図 本発明の実施の形態８における通信装置１の機能構成図 本発明の実施の形態８における告知Ｗｉｎサイズの算出方法フロー図 本発明の実施の形態８におけるＷｐｂ調整サイズ、残りパケットバッファ数、保持データパケット数、固定サイズ、および、ＲＴＴ受信可能サイズの関係図

符号の説明

１ 受信側装置
２ 送信側装置
３ ネットワーク
１０ パケット
１１ システムバス
１２ ＮＩＣ
１３ ＣＰＵ
１４ メモリ
１５ ＦＩＦＯメモリ
２０ アプリケーション
３０ プロトコルスタック
３１ ＴＣＰ層
３２ ＵＤＰ層
３３ ＩＣＭＰ層
３４ ＩＰ層
３５ Ｉｎｔｅｒｆａｃｅ層
３６ パケットバッファ
３７ ソケットキュー
４０ ネットワーク
１１００ アプリケーション部
１２００ プロトコルスタック部
１２１０ ＡＰＩ部
１２２０ ＴＣＰ処理部
１２２１，１２２１ｃ，１２２１ｄ 受信データ管理部
１２２２ Ｗｉｎ制御部
１２２２ａ サイズ取得部
１２２２ｂ，１２２２ｅ，１２２２ｆ，１２２２ｇ Ｗｉｎ抑制部
１２２４ ＡＣＫ生成部
１２２５ ＴＣＰ送信部
１２２６ ＴＣＰ受信部
１２２７ データ複写部
１２２８ 異常通知部
１２２９ ＲＳＴ生成部
１２３０ ＩＰ処理部
１２４０ Ｉｎｔｅｒｆａｃｅ処理部
１２５０ ＲＴＴ受信可能量算出部
１２５１ Ｗｐｂ調整量算出部
１３００ ネットワーク部
１３１０ ＭＡＣ処理部
１３１１ ＭＡＣ受信可能量算出部
１４００，１４００ｂ パケットバッファ管理部
１５００ ＣＰＵ負荷監視部
１６００ 表示部
２０００ 実施の形態２における対象となるＴＣＰ通信の保持データパケット数
２００１ 実施の形態２における新規通信のためのパケットバッファ
２００２ 実施の形態２における通信装置全体のパケットバッファ
２００３ 実施の形態２における使用可能なパケットバッファ

Claims (16)

1. 通信装置であって、
   データパケットを受信するパケット受信部と、
   受信したデータパケットを保持するパケット保持部と、
   告知ウィンドウサイズを決定するウィンドウ制御部と、
   受信したデータパケットに対応したＡＣＫを、決定された前記告知ウィンドウサイズを含めて生成するＡＣＫ生成部と、
   生成された前記ＡＣＫをデータパケットに含めて送出するデータパケット送出部と、
   を含み、
   前記ウィンドウ制御部は、保持データパケット数と固定サイズとに基づいて算出される残りパケットバッファサイズを告知ウィンドウサイズに決定すること、を特徴とする通信装置。
2. 前記ウィンドウ制御部は、前記残りパケットバッファサイズと、残り受信バッファサイズとを比較し、
   比較の結果、前記残りパケットバッファサイズの方が小さい場合、前記残りパケットバッファサイズに基づいて告知ウィンドウサイズを決定すること、を特徴とする請求項１に記載の通信装置。
3. 前記通信装置は、遅延ＡＣＫアルゴリズムに基づいてＡＣＫを送出可能であり、
   前記ウィンドウ制御部は、前記比較の結果、前記残りパケットバッファサイズの方が小さい場合、遅延ＡＣＫアルゴリズムの動作を無効とすることを特徴とする請求項２記載の通信装置。
4. 前記ウィンドウ制御部は、前記通信装置全体の使用可能バッファ数と前記通信装置全体で管理するバッファ数から算出される所定の閾値とを比較し、
   前記比較の結果、前記使用可能バッファ数の値が小さい場合に、
   前記使用可能バッファ数と固定サイズとに基づいて、告知ウィンドウサイズを決定することを特徴とする、請求項１または請求項２に記載の通信装置。
5. 異常通知部をさらに備え、
   前記ウィンドウ制御部は、前記比較の結果、前記残りパケットバッファサイズの方が小さい場合、さらに異常通知を行うことを特徴とする請求項２記載の通信装置。
6. ＣＰＵ負荷監視部をさらに備え、
   ＣＰＵ負荷監視部が、ＣＰＵ負荷が低いことを検知した場合、受信データ管理部に通知し、
   前記受信データ管理部は、
   前記保持データパケットを他のデータパケットに複写することにより、前記保持データパケット数を減らす
   ことを特徴とする請求項１または請求項２に記載の通信装置。
7. 通信装置が実行する通信制御方法であって、
   データパケットを受信するステップと、
   受信したパケットを保持するステップと
   告知ウィンドウサイズを決定するステップと、
   受信したデータパケットに対応したＡＣＫを、決定された前記告知ウィンドウサイズに基づき生成するステップと、
   生成された前記ＡＣＫをデータパケットに含めて送出するステップと、
   を含み、
   前記告知ウィンドウサイズを決定するステップは、保持データパケット数と固定サイズとに基づいて算出される残りパケットバッファサイズを告知ウィンドウサイズに決定すること、を特徴とする通信制御方法。
8. コンピュータを、
   データパケットを受信する手段と、
   受信したパケットを保持する手段と
   告知ウィンドウサイズを決定する手段と、
   受信したデータパケットに対応したＡＣＫを決定された前記告知ウィンドウサイズに基づき生成する手段と、
   生成された前記ＡＣＫをデータパケットに含めて送出する手段と、
   を含み、
   前記告知ウィンドウサイズを決定する手段を、保持データパケット数と固定サイズとに基づいて算出される残りパケットバッファサイズを告知ウィンドウサイズに決定する手段、
   として機能させるための通信プログラム。
9. コンピュータを、
   データパケットを受信する手段と、
   受信したパケットを保持する手段と
   告知ウィンドウサイズを決定する手段と、
   受信したデータパケットに対応したＡＣＫを決定された前記告知ウィンドウサイズに基づき生成する手段と、
   生成された前記ＡＣＫをデータパケットに含めて送出する手段と、
   を含み、
   前記告知ウィンドウサイズを決定する手段は、保持データパケット数と固定サイズとに基づいて算出される残りパケットバッファサイズを告知ウィンドウサイズに決定する手段、
   として機能させるためのプログラムを記録したコンピュータ読み取り可能な記録媒体。
10. ＭＡＣ処理部と、ＭＡＣ受信可能量算出部をさらに備え、
    ＭＡＣ処理部は、ネットワークから受信したパケットを一時的に保持する機能を有し、
    ＭＡＣ受信可能量算出部は、告知ウィンドウサイズ算出時、ＭＡＣ処理部で受信可能なパケット数、または、バッファ数からＭＡＣ受信可能ウィンドウサイズを算出し、
    前記ウィンドウ制御部は、前記残りパケットバッファサイズと、前記残り受信バッファサイズと、前記ＭＡＣ受信可能ウィンドウサイズと、を比較し、
    比較の結果、最も小さいものを告知ウィンドウサイズに決定すること、を特徴とする請求項２に記載の通信装置。
11. ＲＴＴ受信可能量算出部をさらに備え、
    ＲＴＴ受信可能量算出部は、通信相手とのＲＴＴ（ＲＯＵＮＤ ＴＲＩＰ ＴＩＭＥ）を算出し、
    さらに、所定の方法によって算出された単位時間に処理する受信パケット数と、
    前記ＲＴＴから、ＲＴＴ受信可能パケットサイズを算出し、
    前記ウィンドウ制御部は、前記残りバッファサイズと、前記残り受信バッファサイズと、前記ＲＴＴ受信可能パケットサイズと、を比較し、最小値を告知ウィンドウサイズに決定する、ことを特徴とする請求項２に記載の通信装置。
12. ＡＰＩ部をさらに備え、
    前記ＲＴＴ受信可能量算出部は、前記単位時間に処理する受信パケット数をＡＰＩ部により通知されることができる、ことを特徴とする請求項１１に記載の通信装置。
13. 前記ＲＴＴ受信可能量算出部は、前記単位時間に処理する受信パケット数を統計的に観測し、前記単位時間に処理する受信パケット数を算出するために、その情報を用いる、ことを特徴とする請求項１１に記載の通信装置。
14. 前記ＲＴＴ受信可能量算出部は、ＡＣＫパケットの送信時刻と、送信したＡＣＫパケットに起因するデータパケットの受信時刻の差分から算出されるＲＴＴを算出し、そのＲＴＴを前記ＲＴＴ受信可能パケットサイズの算出に用いること、を特徴とする請求項１１に記載の通信装置。
15. 前記ＲＴＴ受信可能量算出部は、受信するパケットをＭＡＣ処理部で保持できなかった場合に、前記ＲＴＴ受信可能パケットサイズを減らすこと、を特徴とする請求項１１に記載の通信装置。
16. 残りパケットバッファサイズ調整量算出部をさらに備え、
    前記残りパケットバッファサイズ調整量算出部は、所定の方法によって単位時間処理パケット数を算出し、
    前記ウィンドウ制御部は、前記残りパケットバッファサイズと、残り受信バッファサイズとの比較前に、前記単位時間処理パケット数を基づいて、前記残りパケットバッファサイズを所定量だけ減少させること、を特徴とする請求項２または請求項１０に記載の通信装置。

Images