JP2017183833A - 通信装置およびその制御方法 - Google Patents

Abstract

【課題】確認応答を使用した通信におけるデータ転送速度を向上させる。【解決手段】通信装置において、他の通信装置から送信されるデータパケットに対する確認応答パケットを生成する生成手段と、データパケットを受信した場合に、生成手段により生成された該データパケットに対応する確認応答パケットを送信する送信手段と、を有する。生成手段は、少なくとも一部のデータパケットに対する確認応答パケットの生成処理を該データパケットの受信に先立って開始する。【選択図】図３

Description

本発明は、確認応答を使用するパケット通信における通信制御技術に関するものである。

従来、データ通信において通信の信頼性を保証するため、パケット化したデータを受信した際に受信側から送信側へＡＣＫ（ACKnowledgement）と呼ばれる確認応答を送信する手法がある。これにより、送信側は受信側が正常にデータを受信したことを知ることが出来る。例えば、特許文献１に示されるように、インターネット通信において広く利用されているＴＣＰ（Transmission Control Protocol）では、パケットをオクテット単位にシーケンス番号で管理している。そして、受け取ったパケットのシーケンス番号をＡＣＫパケットとして応答している。

また、ＴＣＰのＡＣＫパケットでは、受信バッファの空き容量をウィンドウサイズとして通知し、送信側は通知されたウィンドウサイズまでは、ＡＣＫパケットを受信することなくデータを連続して送信することができる。ウィンドウサイズまでデータを送信すると、送信側は、受信側からのＡＣＫパケットを受信し、新たなウィンドウサイズが通知されるまでデータを送信しない。

特開２０００−２２７４４号公報

しかしながら、ＴＣＰなどの確認応答を使用する通信方式においては、通信状況によっては次のデータを送信することができない場合がある。例えば、送信側が、ＡＣＫを受信することなく受信側の受信バッファが埋まるまでデータを送信した場合、次のデータを送信することが出来なくなる。すなわち、受信側におけるＡＣＫの生成及び送信の遅延により、送信側による次のデータの送信も遅延することになる。その結果、送信側と受信側の間のデータ転送速度が遅くなってしまうことになる。

本発明は、上記の問題点を鑑みてなされたものであり、確認応答を使用した通信におけるデータ転送速度を向上させることを目的とする。

上述の問題点を解決するため、本発明に係る通信装置は以下の構成を備える。すなわち、通信装置において、他の通信装置から送信されるデータパケットに対する確認応答パケットを生成する生成手段と、前記データパケットを受信した場合に、前記生成手段により生成された該データパケットに対応する確認応答パケットを送信する送信手段と、を有し、前記生成手段は、少なくとも一部のデータパケットに対する確認応答パケットの生成処理を該データパケットの受信に先立って開始する。

本発明によれば、確認応答を使用した通信におけるデータ転送速度を向上可能とする技術を提供することができる。

第１実施形態に係るＴＣＰ／ＩＰスタックの構成を説明する図である。 通信装置の構成を示すブロック図である。 第１実施形態におけるＡＣＫパケット生成の動作フローチャートである。 タスクの優先順位の例を示す図である。 ＴＣＰ接続管理機構の構造を示す図である。 受信パケットに対するＡＣＫパケットの送信位置及び構造を示す図である。 第１実施形態におけるＡＣＫパケット送信の動作フローチャートである。 第１実施形態に係るＴＣＰ通信における効果を説明する図である。 各種パケットの構造を示す図である。 第２実施形態におけるＡＣＫパケット生成の動作フローチャートである。 第３実施形態におけるＡＣＫパケット生成の動作フローチャートである。 第３実施形態におけるＡＣＫパケット送信の動作フローチャートである。 第４実施形態における受信パケットに対するＡＣＫパケットの送信位置を示す図である。 第４実施形態の変形例１におけるＡＣＫパケット送信の動作フローチャートである。 第４実施形態の変形例２におけるＡＣＫパケット送信の動作フローチャートである。

以下に、図面を参照して、この発明の好適な実施の形態を詳しく説明する。なお、以下の実施の形態はあくまで例示であり、本発明の範囲を限定する趣旨のものではない。

（第１実施形態）
本発明に係る通信装置の第１実施形態として、ＴＣＰ／ＩＰ通信を行う通信装置を例に挙げて以下に説明する。特に、対向装置から到来するデータパケットの受信に先立って、該データ受信に対する確認応答パケット（ＡＣＫパケット）の生成処理を開始し、データパケットを受信した場合により短期間でＡＣＫパケットを送出可能とする形態について説明する。

＜装置構成＞
図１は、第１実施形態に係るＴＣＰ／ＩＰスタックの構成を説明する図である。図２は、図１に示すＴＣＰ／ＩＰスタックを搭載した通信装置２１２の構成を示すブロック図である。

通信装置２１２は、ＣＰＵ２０２、ワークメモリであるＤＲＡＭ２０３、ＣＰＵ２０２が実行するプログラムなどを格納するＲＯＭ２０９を有する。また、通信装置２１２は、イーサネット（商標登録）規格などのネットワーク２１０を介した通信を行うためのＬＡＮモジュール２０４を有する。

ＡＣＫ生成処理タスク１１０は、受信したデータの確認応答であるＡＣＫパケットを生成するタスクである。アプリケーションタスク１０１を構成するアプリケーションは、データの送受信を行う通信アプリケーションである。第１実施形態においては、ＴＣＰ／ＩＰの送信処理はアプリケーションタスク１０１で行われる。

受信バッファ１０２は、上述の通信アプリケーションのための受信バッファであり、受信処理タスク１０３が受信キュー１０４を介して受信したデータがコピーされる。上述の通信アプリケーションによる受信データの読み出しは、受信バッファ１０２を介して行われる。受信キュー１０４は、ＬＡＮドライバ１０６が受信したパケットが挿入されるキューである。受信キュー１０４は、例えばＤＲＡＭ２０３内に構成されている。

送信キュー１０５は、アプリケーションタスク１０１のＴＣＰ／ＩＰの送信処理により生成されたＴＣＰ／ＩＰパケットが挿入されるキューである。送信キュー１０５は、例えばＤＲＡＭ２０３内に構成されている。

ＬＡＮドライバ１０６は、ＬＡＮモジュール２０４を制御し、イーサネット（商標登録）規格などに準拠したＬＡＮ２１０を介してパケットの送受信を行う機能部である。ＡＣＫパケットバッファ１０７は、生成したＡＣＫパケットを埋めるバッファであり、ＤＲＡＭ２０３内に構成されている。ＴＣＰ接続管理機構１０８は、ＴＣＰ接続を管理する機能部であり、ＤＲＡＭ２０３内に構成されている。

＜装置の動作＞
図５は、ＴＣＰ接続管理機構１０８の構造を示す図である。ＴＣＰ接続管理機構１０８は、ＴＣＰ接続管理構造体４０１、生成されたＡＣＫパケットを管理するためのＡＣＫパケット管理構造体４０２、ＴＣＰ管理接続構造体の先頭を保持するＴＣＰ接続構造体先頭４０３を含む。ＴＣＰ接続管理構造体４０１は、ＴＣＰ接続管理構造体先頭４０３からリンクされる。また、次（後続）のＴＣＰ接続管理構造体４０１へは“次のＴＣＰ接続”のポインタによりリンクされている。

図３は、第１実施形態におけるＡＣＫパケット生成の動作フローチャートである。

Ｓ３０２では、ＣＰＵ２０２は、タスクが実行のイベントを待機し、イベントが派生するとＳ３０３に進む。Ｓ３０３では、ＣＰＵ２０２は、ＴＣＰ接続管理構造体先頭４０３から“次のＴＣＰ接続”を抜き出す。Ｓ３０４では、ＣＰＵ２０２は、次のＴＣＰ接続が存在するか否かを判定する。ＴＣＰ接続がなければ（すなわち、ＴＣＰ接続管理構造体４０１の“次のＴＣＰ接続”の値がＮＵＬＬであれば）イベント待ち（Ｓ３０２）に戻る。ＴＣＰ接続があれば（すなわち、ＴＣＰ接続管理構造体４０１の“次のＴＣＰ接続”がＮＵＬＬでなければ）Ｓ３０５に進む。

Ｓ３０５では、ＣＰＵ２０２は、ＴＣＰ接続管理構造体４０１から生成済み確認応答番号（生成済みＡＣＫ番号）を抜き出す。Ｓ３０６では、ＣＰＵ２０２は、受信バッファサイズと生成済みＡＣＫ番号から生成予定のＡＣＫ番号の最大値を求める。生成予定のＡＣＫ番号の最大値を設定しておくことにより、無限にＡＣＫパケットを生成することを防ぐことができる。生成予定のＡＣＫ番号の最大値は、例えば、受信側ウィンドウサイズに基づいて以下のように求めることができる。

生成予定のＡＣＫ番号の最大値 ＝ 受信済みシーケンス番号 ＋ 受信側ウィンドウサイズ − 生成済みＡＣＫ番号
Ｓ３０７では、ＣＰＵ２０２は、生成済みＡＣＫ番号と生成予定のＡＣＫ番号の最大値を比較する。生成済みＡＣＫ番号が生成予定のＡＣＫ番号の最大値より小さければＳ３０８に進み、生成済みＡＣＫ番号が生成予定ＡＣＫ番号の最大値以上であった場合は、Ｓ３１０に進む。

Ｓ３０８では、ＣＰＵ２０２は、ＡＣＫパケットを生成し、生成済みＡＣＫ番号を更新する。ただし、対応するデータパケットを未受信である場合、ＡＣＫパケットの生成において、シーケンス番号とウィンドウサイズは未知のパラメータである。シーケンス番号はデータを送った場合、ウィンドウサイズはＴＣＰを使用するアプリケーションの読み込みタイミングに依存する。そのため、ＡＣＫパケットの生成時には、シーケンス番号とウィンドウサイズに“０”を入れてチェックサムを計算してＡＣＫパケットのチェックサムに代入する。そして、ＡＣＫパケットの送信時に、確定したシーケンス番号とウィンドウサイズを代入してチェックサムにシーケンス番号とウィンドウサイズを足すようにする。ＡＣＫパケットの生成及びＡＣＫ番号の更新について図６を参照して更に説明する。

図６は、受信パケットに対するＡＣＫパケットの送信位置（タイミング）及び構造を示す図である。なお、ＴＣＰでは、最大セグメントサイズ（ＭＳＳ：Maximum Segment Size）より大きいサイズのデータを受信した場合、すなわち、２個のパケットを受信した場合に１個のＡＣＫパケットを送信することが推奨されている。そのため、図６においては、生成するＡＣＫ番号は生成済みのＡＣＫ番号に（ＭＳＳ×２）を加えたものとしている。

点線の矩形で示されるパケット５０１は、到着する予測されるパケット（すなわち、現時点で未受信のパケット）を示している。また、パケット５０１には、併せて当該パケットの「シーケンス番号の開始位置」と「ＴＣＰのデータサイズ」が記述されている。例えば、パケット５０１では、“２”がシーケンス番号であり、“１４６０”がＴＣＰのＭＳＳサイズ（当該パケットでのデータサイズ）を示している。

三角マークで示すタイミング５０２は、ＡＣＫパケットが送信される時間的な位置を示している。ここでは、上述の通り、２個目のパケットの受信にしたあとに送信している例を示している。ＡＣＫパケット５０３は、生成されるＡＣＫパケットの構造の例を示している。図６では、受信するデータを含むパケットのシーケンス番号の初期値が“２”であり、ＭＳＳサイズ×２＝２９２０であるため、生成するＡＣＫパケットのＡＣＫ番号は、それぞれ“２９２２”、“５８４２”、“８７６２”となっている。

Ｓ３０９では、ＣＰＵ２０２は、生成したＡＣＫパケットをＡＣＫパケット管理構造体の生成済みＡＣＫパケット管理のキューの最後にキューイングする。

Ｓ３１０では、ＣＰＵ２０２は、現在注目しているＴＣＰ接続に対するＡＣＫパケットをこれ以上生成する必要はないため、次のＴＣＰ接続管理構造体４０１を抜き出す。

なお、イベント待ち（Ｓ３０２）の解除は、アプリケーションがデータを読み込んだとき、ＴＣＰ−ＳＹＮパケットを受信したとき、ＴＣＰ−ＳＹＮパケットを送信するときに行われる。また、ＴＣＰデータパケットを受信したとき、ＴＣＰデータパケットを送信するとき、ＴＣＰ接続を切断するときにも行われる。

図４は、ＡＣＫパケットの生成（図３）の優先順位の例を示す図である。図４（ａ）は、アイドルタスクでＡＣＫパケットの生成を行う場合のタスクの優先順位を示している。上に行くほど優先度が高いタスクであり、下に行くほど優先度が低いタスクであることを示している。アイドルタスクは、機器組み込み型のＯＳにおいて、他に実行すべき処理がないアイドル状態の場合に実行される、何の処理も行わないタスクである。（ａ）では、ここにＡＣＫ生成処理を組み込むことで、すべき処理がない場合、つまりＣＰＵにおいて他に処理するタスクがない場合に実行することができる。

また、図４（ｂ）は、ＡＣＫパケットの生成の専用タスクを設けた場合のタスクの優先順位を示している。（ｂ）では、アイドルタスクよりやや優先順位が高いタスクとして、ＡＣＫ生成専用のタスクを設けた場合を示している。また、（ｃ）では、アプリケーションタスク毎に独立したＡＣＫ生成処理タスクを設けた場合を示している。このように構成しても、アイドルタスクが実行される直前の状態、つまりＣＰＵが他に処理するタスクがない場合に実行することができる。

なお、ネットワーク処理をネットワーク以外の処理よりも優先させる場合、ＡＣＫ生成タスクの優先順位がネットワーク以外の処理の優先順位よりも高くなるよう構成するとよい。また、ＴＣＰ接続要求受付直後やＴＣＰ接続完了後など、ＴＣＰ通信開始より前に行うよう構成してもよい。

図７は、第１実施形態におけるＡＣＫパケット送信の動作フローチャートである。この動作は、ＴＣＰパケットの受信を待機し、Ｓ６０１でＴＣＰパケットの受信をトリガに開始される。

Ｓ６０１では、ＣＰＵ２０２は、ＴＣＰパケットを受信する。Ｓ６０２では、ＣＰＵ２０２は、ＴＣＰパケットの宛先アドレス、宛先ポート番号、送信元アドレス、送信元ポート番号などから、受信したＴＣＰパケットに対応するＴＣＰ接続管理構造体を検索する。ここでは、検索の結果、ＴＣＰ接続管理構造体４０１が特定される。

Ｓ６０３では、ＣＰＵ２０２は、受信したＴＣＰパケットに対応するＴＣＰ接続管理構造体が存在するか否かを判断し、存在する場合はＳ６０４に進み、存在しない場合はＳ６１３に進む。Ｓ６１３では、ＣＰＵ２０２は、ＴＣＰ＿Ｒｅｓｅｔ（ＴＣＰ−ＲＳＴ）パケットを送信した後、Ｓ６１８に進み処理を終了する。

Ｓ６０４では、ＣＰＵ２０２は、受信したパケットのデータを、当該受信パケットに対応するＴＣＰ接続管理構造体にキューイングしたり、受信したデータの順序制御を行うなどのＴＣＰ受信処理を行う。

Ｓ６０５では、ＣＰＵ２０２は、受信したデータに対してＡＣＫを送信するかどうか判断する。ＡＣＫを送信しない場合はＳ６１８に進み処理を終了する。ＡＣＫを送信する場合は、Ｓ６０６では、ＣＰＵ２０２は、ＴＣＰ接続管理構造体のＡＣＫパケットを調査し、Ｓ６０７では、ＣＰＵ２０２は、生成済みのＡＣＫパケットが存在するか否かを判断する。生成済みのＡＣＫパケットがなければ、Ｓ６１４では、受信したデータに対応するＡＣＫパケットを生成して送信した後、Ｓ６１８に進み処理を終了する。生成済みのＡＣＫパケットがあればＳ６０８に進む。

Ｓ６０８及びＳ６０９では、ＣＰＵ２０２は、“受信パケットにおけるシーケンス番号とデータサイズとの和（すなわち、応答すべきＡＣＫ番号）”と、“生成済みのＡＣＫパケットのＡＣＫ番号”とを比較する。生成済みのＡＣＫパケットのＡＣＫ番号が応答すべきＡＣＫ番号より大きい場合はＳ６１４に進みＡＣＫパケットを新規に生成し送信する。一方、生成済みのＡＣＫパケットのＡＣＫ番号と応答すべきＡＣＫ番号とが同じである場合はＳ６１５に進み、生成済みのＡＣＫパケットのＡＣＫ番号が応答すべきＡＣＫ番号より小さい場合はＳ６１０に進む。

Ｓ６１５では、ＣＰＵ２０２は、生成済みのＡＣＫパケットを調整する。具体的には、ＴＣＰ接続管理構造体からシーケンス番号と受信バッファ残量をＡＣＫパケットに代入する。そして、それらの値をチェックサムに足し込む。その後、Ｓ６１６では、ＣＰＵ２０２は、調整された生成済みのＡＣＫパケットを送信する。Ｓ６１７では、送信したＡＣＫパケットをフリーにした後、すなわち、現在注目しているＡＣＫパケットを破棄し、Ｓ６１８に進み処理を終了する。

Ｓ６１０では、ＣＰＵ２０２は、次の生成済みのＡＣＫパケットがあるかどうかを調べる。次の生成済みのＡＣＫパケットがある場合はＳ６１１に進み。一方、次の生成済みのＡＣＫパケットが無い場合はＳ６１５に進み、現在注目している生成済みのＡＣＫパケットを調整して送信する。

Ｓ６１１では、ＣＰＵ２０２は、“受信パケットにおけるシーケンス番号とデータサイズとの和（すなわち、応答すべきＡＣＫ番号）”と、“次の生成済みのＡＣＫパケットのＡＣＫ番号”とを比較する。次のＡＣＫ番号の方が小さければ、Ｓ６１２に進み、現在の生成済みのＡＣＫパケットをフリーにした後、次の生成済みのＡＣＫを現在の生成済みのＡＣＫとして設定し、Ｓ６０９に戻る。一方、次のＡＣＫ番号の方が大きい場合は、当該次の生成済みのＡＣＫパケットは受信していないデータに対するものであるためＳ６１５に進み、現在注目している生成済みのＡＣＫパケットを調整して送信する。

＜ＡＣＫパケットにおけるＩＰヘッダ生成＞
ＡＣＫパケットの生成処理（Ｓ３０８）に含まれる各種処理について図５及び図９を参照して説明する。図９（ａ）は、ＴＣＰのＡＣＫパケットの構造を示し、図９（ｂ）は、ＴＣＰヘッダと仮想ヘッダの構造を示している。

ＴＣＰのＡＣＫパケットは、ＩＰヘッダ（２０バイト）、ＴＣＰヘッダ（２０バイト）から構成されており、このパケットを送信することで送信側にＴＣＰデータを受信したことを通知する。仮想ヘッダとＴＣＰヘッダは、ＴＣＰチェックサムの計算に使われる。

まず、ＴＣＰ接続管理構造体４０１を参照し、送信元ＩＰアドレス、宛先ＩＰアドレスを調べ、仮想ヘッダの送信元ＩＰアドレス、宛先ＩＰアドレスに代入する。仮想ヘッダのＺｅｒｏには“０ｘ００”、プロトコル番号にはＴＣＰを示す“０ｘ０６”、ＴＣＰ長にはＴＣＰヘッダ長である“２０”をそれぞれ代入する。

また、ＴＣＰ接続管理構造体４０１を参照し、送信元ポート番号、宛先ポート番号を調べ、ＴＣＰヘッダの送信元ポート番号、宛先ポート番号にコピーする。更に、ＴＣＰ接続管理構造体４０１を参照し、送信済みシーケンス番号と受信済みシーケンス番号を調べ、それぞれを、ＴＣＰヘッダの送信済み番号に、ＴＣＰヘッダのＡＣＫ番号に代入する。

ヘッダ長には２０÷４（３２ビット単位で表現されるため）で“５”を代入する。Ｆｌａｇ＋ＲｅｓｅｒｖｅｄにはＡＣＫパケットであるので“ＡＣＫフラグ”を立てる。更に、ｗｉｎｄｏｗ ｓｉｚｅには、この時の残りの受信バッファサイズを代入する。チェックサムに“０”、緊急ポインタに“０”を代入する。仮想ヘッダ＋ＴＣＰヘッダのチェックサムを計算し、チェックサムに代入する。次にＴＣＰヘッダを残したまま仮想ヘッダを取り除き、ＩＰヘッダを生成する。

次に、生成したＩＰヘッダの各部に値を代入する。送信元ＩＰアドレスと宛先ＩＰアドレスはＴＣＰ接続管理構造体４０１の情報を代入する。全体長にはＩＰヘッダ長＋ＴＣＰヘッダ長である“４０”を代入する。プロトコル番号にはＴＣＰを示す“０ｘ０６”、ヘッダチェックサムには“０”を代入する。そして、ヘッダチェックサムには、ＩＰヘッダ部分２０バイトのチェックサムを計算した結果を代入する。

このように、ＡＣＫパケットの生成には、仮想ヘッダの生成、ＴＣＰヘッダの生成、仮想ヘッダのチェックサム計算、ＴＣＰヘッダのチェックサム計算、ＩＰヘッダの生成、ＩＰヘッダのチェックサム計算、が含まれる。このような様々なデータ処理が必要であるため、ＡＣＫパケットの生成には相応の時間を要することになる。

＜効果＞
図８は、第１実施形態に係るＴＣＰ通信における効果を説明する図である。図８（ａ）は、従来技術における送受信の動作を示しており、図８（ｂ）は、第１実施形態における送受信の動作を示している。それぞれ、ＴＣＰ接続確立後の、送信側機器から受信側機器へのデータ送信、受信側機器から送信側機器へのＡＣＫ送信を例示的に示している。図８において縦方向は時間の経過を示している。特に、受信側機器における「ＡＣＫ生成」「受信処理」「ｉｄｌｅ」の各時間を例示的に示している。

なお、「ＡＣＫ生成」は、ＡＣＫ生成からＡＣＫ送信までの処理に要する時間、「受信処理」は、ＴＣＰパケット受信からアプリケーションによるデータの読み込みまでの処理に要する時間、「ｉｄｌｅ」は、ＣＰＵの空き時間である。

説明を簡単にするため、図８では、送信側機器が送信するパケットの各々で送信されるデータ量は、ＭＳＳ単位であるとする。また、受信側機器の受信バッファは、ＭＳＳ×４のパケットを受信するといっぱいになるとする。更に、以下の説明においては、最初の６個のパケット（Ａ〜Ｆ）の送信について詳細に説明するが、後続のパケットにおいても同様の動作が実行される。

・従来技術における送受信の動作
送信側機器は、受信側機器のウィンドウサイズ（残りの受信バッファサイズ）分のパケット（ここでは、Ａ、Ｂ、Ｃ、Ｄの４個）を送信する。受信側機器は、パケットを受信する毎に受信処理を行う。ＴＣＰでは連続して大きなパケットを受信する場合、受信側機器は、２×ＭＳＳのデータを受信するとＡＣＫを１回送信する。そのため、ここでは、受信側機器は、２個のパケット（Ａ、Ｂ）の受信処理を行い、これらの受信処理の完了後、Ｂまでのパケットを受信したことを示すＡＣＫ（図における「Ａ＋Ｂ」）を生成し送信する。同様に、後続の２個のパケット（Ｃ、Ｄ）の受信処理を行い、これらの受信処理の完了後、Ｄまでのパケットを受信したことを示すＡＣＫ（図における「Ｃ＋Ｄ」）を生成し、送信する。

送信側機器が上述の４個のパケット（Ａ、Ｂ、Ｃ、Ｄ）を送った時点で相手のウィンドウサイズがいっぱいになっているため、送信側機器は、受信側機器が送信するＡＣＫを受信するまで次のパケット（Ｅ以降）を送信することができない。

送信側機器は、ＡＣＫパケット（上述の「Ａ＋Ｂ」）を受信するとウィンドウサイズが２ＭＳＳ分空いたことが分かるため、２個のパケット（Ｅ、Ｆ）を送信する。この時点で、受信側機器は、２個のパケット（Ｃ、Ｄ）の受信処理とこれらのパケットに対するＡＣＫ（図における「Ｃ＋Ｄ」）の送信を終えている。しかしながら、受信側機器は、次のパケット（Ｅ以降）を受信していないため、アイドルタスクを実行している。その後、受信側機器は、２個のパケット（Ｅ、Ｆ）を受信すると、それぞれ受信処理を行い、Ｆまでのパケットを受信したことを示すＡＣＫ（図における「Ｅ＋Ｆ」）を生成し、送信する。

・第１実施形態における送受信の動作
送信側機器は、受信側機器のウィンドウサイズ分のパケット（ここでは、Ａ、Ｂ、Ｃ、Ｄの４個）を送信する。受信側機器は、２個のパケット（Ａ、Ｂ）の受信処理を行い、これらの受信処理の完了後、Ｂまでのパケットを受信したことを示すＡＣＫを生成し送信する。同様に、２個のパケット（Ｃ、Ｄ）の受信処理を行い、これらの受信処理の完了後、Ｄまでのパケットを受信したことを示すＡＣＫを生成し、送信する。ここまでの動作は従来技術と同じである。

ＡＣＫ（「Ｃ＋Ｄ」）を送信後、受信側機器は、後続のパケット（Ｅ以降）の到着までの間（すなわち、従来の動作では「ｉｄｌｅ」であった期間）、後続のパケットに対応するＡＣＫの生成処理を行う。受信側機器は、パケット（Ｅ）を受信すると当該パケットの受信処理を行い、パケット（Ｆ）を受信すると当該パケットの受信処理を行う。

受信側機器は、Ｆまでのパケットを受信したことを示すＡＣＫ（図における「Ｅ＋Ｆ」）を図７の動作に従って選択し送信する。すなわち、先行して生成済みのＡＣＫを選択し使用しているため、Ｆまでのパケットを受信した後、従来より短い時間で対応するＡＣＫ（「Ｅ＋Ｆ」）を送信することができる。以降も同様な動作を行うことにより、受信側機器がＲのパケットを受信するまでの時間をδだけ短くすることができる。すなわち、同じ量のデータをより短時間に送信することが可能となっており、送信側機器から受信側機器により高速にデータを伝送することが可能となる。

以上説明したとおり第１実施形態によれば、ＴＣＰ通信におけるＡＣＫパケットの生成処理を、対応するデータパケットの受信に先立って開始する。これにより、対応するデータパケットを受信した際に、ＡＣＫパケットの生成処理の少なくとも一部が完了しているため、速やかに、ＡＣＫパケットを送信することが可能となり、通信時間を短縮することが可能となる。特に、ＡＣＫパケットの生成を優先順位の低いタスクあるいはアイドルタスクにおいて実行することにより、他の処理に悪影響を与えることなく、ＣＰＵをより有効利用することが可能となる。

なお、上述の説明では、ＡＣＫパケットの生成に関連する処理を全てＣＰＵが行っているものとして説明をしているが、一部の処理をハードウェアにオフロードするよう構成してもよい。

（第２実施形態）
第２実施形態では、所定の種別の通信接続、例えば、大量のデータを受信するＴＣＰ接続のみを対象として、第１実施形態で説明したＡＣＫパケットの生成処理を行う形態について説明する。

図１０は、第２実施形態におけるＡＣＫパケット生成の動作フローチャートである。なお、図１０は、図３に対して、Ｓ３０４とＳ３０５との間にＳ１１１１を追加したものに相当する。具体的には、Ｓ１１１１において、ＣＰＵ２０２は、Ｓ３０４において存在すると判定されたＴＣＰ接続に対して、当該ＴＣＰ接続が大量のデータを受信するＴＣＰ接続であるか否かを判断する。

そして、大量のデータを受信するＴＣＰ接続である場合にのみ、事前にＡＣＫパケットを生成する。すなわち、大量のデータを受信するＴＣＰ接続でない場合は、事前にＡＣＫパケットを生成せず、データパケットを受信後にＡＣＫパケットを生成する。

なお、大量のデータを受信するかどうかの判断は、例えば、ＴＣＰ接続管理構造体４０１のフラグに、大量のデータを受信することを示すフラグが存在しているか否かに基づいて判定する。すなわち、大量のデータを受信するアプリケーションは、通信前や通信中に大量のデータを受信することを示すフラグをＴＣＰ接続管理構造体４０１に設定する。

また、アプリケーションがフラグを設定する代わりに、プロトコルスタックが、フラグを設定するよう構成してもよい。例えば、受信したパケットの先頭を読み出し、画像データ、動画データであった場合に大量のデータを受信することを示すフラグを設定するとよい。

以上説明したとおり第２実施形態によれば、画像データや音声データなどの大量のデータを受信する場合のみ事前にＡＣＫパケットを生成する。これにより、事前に生成したＡＣＫパケットに使用されるメモリ量を減らすことができ、また、ＣＰＵを他の処理に利用することが可能となる。

（第３実施形態）
第３実施形態では、同時接続数に基づいて事前に生成するＡＣＫパケットに関して制限を設ける形態について説明する。以下の説明では、同時接続数に基づいて、生成可能なＡＣＫパケットの個数の上限値（ＡＣＫ＿ＭＡＸ）を決定する例について説明する。

図１１は、第３実施形態におけるＡＣＫパケット生成の動作フローチャートである。図１１は、図３に対して、Ｓ３０７とＳ３０８との間にＳ１２１１，Ｓ１２１２を追加したものに相当する。また、図１２は、第３実施形態におけるＡＣＫパケット送信の動作フローチャートである。なお、図１２は、図７に対して、ＡＣＫをフリー（Ｓ６１２，Ｓ６１７）にした後にＳ１３１９，Ｓ１３２０を追加したものに相当する。

以下の説明において、ＡＣＫ＿ＭＡＸは、生成するＡＣＫパケットの個数の上限値、ａｃｋ＿ｎｏｗは、現在生成済みのＡＣＫパケットの個数をそれぞれ示すパラメータである。ＡＣＫ＿ＭＡＸの値は、通信装置２１２が搭載するメモリのサイズ等に基づいて静的に決定しても良いし、通信装置２１２の使用者が設定する形態でも良い。また、ａｃｋ＿ｎｏｗの値は、例えば、通信装置２１２の起動時あるいはＴＣＰスタックの起動時にゼロクリアされる（起動時には、生成済みＡＣＫパケットは０個）。

具体的には、ＡＣＫパケット生成フロー（図１１）のＳ３０７において生成済みＡＣＫ番号と生成予定ＡＣＫ番号を比較し、生成済みＡＣＫ番号が生成予定ＡＣＫ番号より小さい場合Ｓ１２１１に進む。

Ｓ１２１１では、ＣＰＵ２０２は、ａｃｋ＿ｎｏｗとＡＣＫ＿ＭＡＸとを比較する。ａｃｋ＿ｎｏｗがＡＣＫ＿ＭＡＸより小さければ、Ｓ１２１２で、ａｃｋ＿ｎｏｗを１増やし（インクリメント）、Ｓ３０８でＡＣＫパケットを生成する。

一方、ＡＣＫパケット送信フロー（図１２）においてＡＣＫをフリーにする場合は、ａｃｋ＿ｎｏｗを１減らす（デクリメント）。これにより、現在生成済みのＡＣＫパケットの個数を正しく管理することが可能となる。

以上説明したとおり第３実施形態によれば、生成するＡＣＫパケットの個数に上限を設けることができる。これにより、ＴＣＰの同時接続数が多い場合などにおいて、ＡＣＫパケットを多量に生成することによるメモリの過剰な消費を防ぐことが可能となる。なお、ＡＣＫ＿ＭＡＸをＴＣＰ接続毎に決定するよう構成してもよい。また、ＴＣＰ接続毎に異なる最大個数（ＡＣＫ＿ＭＡＸ）を設定してもよい。ＴＣＰ接続毎に異なる最大個数（ＡＣＫ＿ＭＡＸ）を設定する場合、その上限値を接続の受信バッファサイズをＭＳＳで割った値を使用して決定してもよい。

（第４実施形態）
第４実施形態では、受信したデータパケットのデータサイズが、予測されたサイズと一致しない場合の動作について説明する。

図１３は、第４実施形態における受信パケットに対するＡＣＫパケットの送信位置を示す図である。なお、点線の矩形は受信側機器が未受信であり、実線で示す矩形は受信側端末が受信済みであることを示している。

図１３（ａ）に示すパケット群を受信することを想定し、図１３（ａ）のタイミング５０２でＡＣＫを生成したとする。しかし、実際には図１３（ｂ）に示すように、受信パケット５０１−０３のようなパケットを受信することがある。この場合、タイミング５０２−０２やタイミング５０２−０３のように、ＡＣＫパケットの送信タイミング及びＡＣＫ番号が、データパケットの受信タイミング及びデータサイズの区切り単位からずれることになる。

ところで、ＴＣＰでは、データの送達確認をパケット単位では無くバイト単位（シーケンス番号）で管理している。そのため、予め生成したＡＣＫパケットを送信しても、正常にデータ通信を継続することが可能である。そこで、例えば、図１３（ｂ）では、パケット５０１−０５を受信したときに、タイミング５０２−０２でＡＣＫパケットを送信する。

このように、生成したＡＣＫパケットの“ＡＣＫ番号”と“受信したパケットのシーケンス番号＋データサイズ”とが一致しない場合であっても、正常にデータ通信を継続することが可能である。すなわち、“受信したパケットのシーケンス番号＋データサイズ”よりも小さいＡＣＫ番号を有するＡＣＫパケットを送信することにより、ＡＣＫパケットを作り直すこと無く通信を継続することが可能となる。

・変形例１
上述のように、ＴＣＰにおいては、受信したデータパケットを単位としたＡＣＫパケットを返信しなくとも、正常に通信を継続することが出来る。ただし、受信したパケットを単位としたＡＣＫパケットを返信するよう構成してもよい。

図１３（ｃ）は、第４実施形態の変形例１における受信パケットに対するＡＣＫパケットの送信位置を示す図である。タイミング５１２−０１、５１２−０２において送信されるＡＣＫパケットは、上述の図１３（ｂ）のタイミング５０２−０１、５０２−０２において送信されるＡＣＫパケットと同様である。一方、タイミング５１２−０３において送信されるＡＣＫパケットは、受信したパケットの単位に対する確認応答となるように生成し送信している。なお、図１３（ｃ）においては、各タイミングの下に括弧書きで生成済みＡＣＫパケットのＡＣＫ番号を示している。

図１４は、第４実施形態の変形例１におけるＡＣＫパケット送信の動作フローチャートである。なお、図１４は、図７に対して、Ｓ１６１９を追加したものに相当する。図１４において、Ｓ６１０に進むのは、現在注目している生成済みＡＣＫパケットにおいて“（受信パケットの）シーケンス番号とデータサイズとの和”が“ＡＣＫ番号”より小さい場合である。具体的には、現在注目している生成済みＡＣＫパケットのＡＣＫ番号がずれている場合である。

その状態において、次のＡＣＫパケットが無い場合、Ｓ１６１９では、ＣＰＵ２０２は、ＴＣＰ接続管理構造体の生成済みＡＣＫ番号を、受信したパケットのシーケンス番号及びデータサイズに基づいた値に書き換える。これにより、例えば、タイミング５１２−０３で送信されることになるＡＣＫパケットのＡＣＫ番号は、“８７６２（＝２＋１４６０×６）”だったものが“８０３２（＝５１１２＋１４６０×２）”に書き換わることになる。すなわち、ＡＣＫ番号のずれが修正され、受信したデータを単位としたＡＣＫパケットを返信することが可能となる。

・変形例２
ところで、受信したデータパケットのデータサイズが予測されたサイズと相違しかつ図１３（ｂ）に示すような応答を行った場合には問題が生じることがある。具体的には、図１３（ｂ）のタイミング５０２−０２でＡＣＫパケットを送信した後、パケット５０１−０６以降のパケットを受信しなかった場合、受信済みのデータ（パケット５０１−０５の一部）に対するＡＣＫパケットは送信されないことになる。そこで、変形例２では、生成したＡＣＫパケットに対して強制送信のためのタイマを設け、タイマ発火時に当該ＡＣＫパケットを送信する。

図１５は、第４実施形態の変形例２におけるＡＣＫパケット送信の動作フローチャートである。なお、図１５は、図７に対して、Ｓ１７１９、Ｓ１７２０、Ｓ１７２１を追加したものに相当する。図１５において、Ｓ６１０に進むのは、現在注目している生成済みＡＣＫパケットにおいて“（受信パケットの）シーケンス番号とデータサイズとの和”が“ＡＣＫ番号”より小さい場合である。具体的には、現在注目している生成済みＡＣＫパケットのＡＣＫ番号がずれている場合である。

その状態において、次のＡＣＫパケットが無い場合、Ｓ１７１９では、ＣＰＵ２０２は、ＡＣＫ強制送信タイマを設定する。なお、別のＡＣＫパケットを送信する場合（Ｓ６１４、Ｓ６１６）には、タイムアウトによるＡＣＫパケットを送信する必要がない。そのため、Ｓ１７２０、Ｓ１７２１においては、ＡＣＫ強制送信タイマをＯＦＦにするよう制御する。一方、ＡＣＫ強制送信タイマがタイムアウトすると、これまで受信したデータに対するＡＣＫパケットとして、生成したＡＣＫパケットを送信する。

このように構成することで、受信したデータパケットのデータサイズが予測されたサイズと相違する場合においても、受信したデータに対するＡＣＫパケットの返信漏れを防ぐことが可能となる。

（その他の実施例）
本発明は、上述の実施形態の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサーがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。

１０１ アプリケーションタスク； １０２ 受信バッファ； １０３ 受信処理タスク； １０４ 受信キュー； １０５ 送信キュー； １０６ ＬＡＮドライバ； １０７ ＡＣＫパケットバッファ； １０８ ＴＣＰ接続管理機構； １１０ ＡＣＫ生成処理タスク

Claims (11)

1. 通信装置であって、
   他の通信装置から送信されるデータパケットに対する確認応答パケットを生成する生成手段と、
   前記データパケットを受信した場合に、前記生成手段により生成された該データパケットに対応する確認応答パケットを送信する送信手段と、
   を有し、
   前記生成手段は、少なくとも一部のデータパケットに対する確認応答パケットの生成処理を該データパケットの受信に先立って開始する
   ことを特徴とする通信装置。
2. 前記送信手段は、データパケットを受信した際に、該データパケットに対応する確認応答パケットが既に前記生成手段により生成されている場合は、該生成された確認応答パケットを送信し、該データパケットに対応する確認応答パケットが前記生成手段により生成されていない場合は、前記データパケットに対応する確認応答パケットの前記生成手段による生成を待機し、該生成された確認応答パケットを送信する
   ことを特徴とする請求項１に記載の通信装置。
3. 前記生成手段は、ＣＰＵがプログラムを実行することにより実現され、
   前記生成手段は、データパケットの受信に先立った該データパケットに対する確認応答パケットの生成処理を、前記ＣＰＵにおいて該生成処理より優先度の高いタスクが存在しない場合又は該ＣＰＵがアイドル状態にある場合に、実行する
   ことを特徴とする請求項１又は２に記載の通信装置。
4. 未受信のデータパケットに対して前記生成手段が生成可能な確認応答パケットの個数の上限値を設定する設定手段を更に有する
   ことを特徴とする請求項１から３の何れか１項に記載の通信装置。
5. 前記通信装置と前記他の通信装置とはＴＣＰ（Transmission Control Protocol）に準拠した通信を行い、
   既に受信したデータパケットのＴＣＰヘッダに記述されたシーケンス番号と最大セグメントサイズとに基づいて、未受信のデータパケットに対する確認応答パケットの確認応答番号を決定する決定手段を更に有する
   ことを特徴とする請求項１から４の何れか１項に記載の通信装置。
6. 前記生成手段は、前記他の通信装置との間の通信接続が所定の種別の通信接続であることに応じて、データパケットに対する確認応答パケットの生成処理を該データパケットの受信に先立って開始する
   ことを特徴とする請求項１から５の何れか１項に記載の通信装置。
7. 前記他の通信装置との間の通信接続が前記所定の種別の通信接続であるか否かを、当該通信接続を使用するアプリケーションによって接続管理構造体に設定されたフラグ及び当該通信接続で利用されるプロトコルスタックによって接続管理構造体に設定されたフラグの少なくとも一方に基づいて判定する判定手段を更に有する
   ことを特徴とする請求項６に記載の通信装置。
8. データパケットを受信したとき、該データパケットにおけるシーケンス番号とデータサイズとの和と、前記生成手段により既に生成された確認応答パケットの確認応答番号と、を比較する比較手段を有し、
   前記比較手段により前記和と一致する前記確認応答番号を有する確認応答パケットが無いと判定された場合、前記送信手段は、前記和よりも小さい前記確認応答番号を有する確認応答パケットを送信する
   ことを特徴とする請求項１から７の何れか１項に記載の通信装置。
9. データパケットを受信したとき、該データパケットにおけるシーケンス番号とデータサイズとの和と、前記生成手段により既に生成された確認応答パケットの確認応答番号と、を比較する比較手段を有し、
   前記比較手段により前記和と一致する前記確認応答番号を有する確認応答パケットが無いと判定された場合、前記生成手段は、前記和よりも小さい前記確認応答番号を有する確認応答パケットの該確認応答番号を前記和の値に書き換え、
   前記送信手段は、該書き換えを行った確認応答パケットを送信する
   ことを特徴とする請求項１から７の何れか１項に記載の通信装置。
10. 通信装置の制御方法であって、
    他の通信装置から送信されるデータパケットに対する確認応答パケットを生成する生成工程と、
    前記データパケットを受信した場合に、前記生成工程により生成された該データパケットに対応する確認応答パケットを送信する送信工程と、
    を含み、
    前記生成工程における少なくとも一部のデータパケットに対する確認応答パケットの生成処理は、該データパケットの受信に先立って開始される
    ことを特徴とする通信装置の制御方法。
11. コンピュータを、請求項１から９の何れか１項に記載の通信装置の各手段として機能させるためのプログラム。

Images