JP2013179615A - データ通信装置および通信プログラム - Google Patents

Abstract

【課題】セッションの切断が正しく動作しない問題を解決する。
【解決手段】制御処理部は、相手装置とのデータ通信のセッション状態を管理する。情報記憶部は、前記セッション状態と、前記相手装置との間で使用するプロトコルによるフロー制御で使用するフロー制御情報を記憶する。データ処理部は、前記フロー制御情報と前記セッション状態に基づき、前記相手装置とネットワークを介してデータ通信を行い、前記データ通信に応じて前記フロー制御情報を更新する。データ終端送信判定部は、前記情報記憶部内の前記フロー制御情報に基づき、前記相手装置に前記データ通信の終了を通知する終端通知データを送信可能かどうか判定する。前記データ終端設定部は、前記データ終端送信判定部により可能と判定されたとき、前記終端通知データを送信することを前記データ処理部に指示し、不可と判定されたとき、可能と判定されるまで、前記終端通知データの送信指示を待機する。
【選択図】図１６

Description

本発明は、データ通信装置および通信プログラムに関するものである。

インターネット等で広く用いられるTCP/IPなどのプロトコル処理は、従来主にCPU上で動作するソフトウェアにより実現されていた。しかしながら、近年のネットワーク高速化に伴い、CPUのTCP/IP処理負荷が増大しており、TCP/IP処理を専用のハードウェアによって行うTOE（TCP/IP Offload Engine）を用いることにより、高速な通信を実現する装置が提案されている。

米国公開2004/0078462公報 特開2009‐77024公報

TOEは通常CPU上で動作するソフトウェアから制御されるが、ソフトウェアからの制御を考慮すると、データ送信の性能が出なかったり、セッションの切断が正しく動作しなかったりするなどの問題がある。

本発明の一側面は、データ送信の性能が出ない問題、およびセッションの切断が正しく動作しない問題の少なくとも一方を解決することを目的とする。

本発明の一態様としてのデータ通信装置は、フロー制御を行うプロトコルを用いて相手装置とデータ通信を行うデータ通信装置である。

前記データ通信装置は、制御処理部と、情報記憶部と、データ処理部と、データ終端送信判定部と、データ終端設定部とを備える。

前記制御処理部は、前記データ通信のセッション状態を管理する。

前記情報記憶部は、前記セッション状態と、前記フロー制御で使用するフロー制御情報を記憶する。

前記データ処理部は、前記フロー制御情報と前記セッション状態に基づき、前記相手装置とネットワークを介してデータ通信を行い、前記データ通信に応じて前記フロー制御情報を更新する。

前記データ終端送信判定部は、前記情報記憶部内の前記フロー制御情報に基づき、前記相手装置に前記データ通信の終了を通知する終端通知データを送信可能かどうか判定する。

前記データ終端設定部は、前記データ終端送信判定部により可能と判定されたとき、前記終端通知データを送信することを前記データ処理部に指示する。

前記データ処理部は、前記終端通知データを前記相手装置に送信する。

前記データ終端設定部は、前記データ終端送信判定部により不可と判定されたとき、可能と判定されるまで、前記終端通知データの送信指示を待機する。

第1の実施形態に係るデータ送信装置の構成を概略的に示す図。 プロトコルスタックとアプリケーションの間のデータの受け渡しでメモリコピーが行われる様子を示す図。 NICがアプリケーションバッファにダイレクトにデータを書き込む方式の説明図。 遅延確認応答を説明するための図。 第1の実施形態の動作を説明するための図。 アプリケーションデータとそれに対する確認応答の例を示す図。 アプリケーションデータとそれに対する確認応答の別の例を示す図。 図1の装置にコピーサイズ特定部を追加した構成を示す図。 図8の装置に、送信レート測定部と遅延測定部を追加した構成を示す図。 図1の装置にパケット送信指示部を追加した構成を示す図。 パケット送信指示部の動作を説明するための図。 図1の装置にバッファ管理部を追加した構成を示す図。 第2の実施形態に係るデータ通信装置の構成を概略的に示す図。 図13の装置の動作を説明するためのフローチャート。 図13の装置の変形例を示す図。 第3の実施形態に係るデータ通信装置の構成を概略的に示す図。 図16の装置の動作を説明するためのフローチャート。 図16の装置の変形例を示す図。 TCPのヘッダ構造を示す図。 TCPの状態名とその説明とを表した図。 セッション情報の一例を示す図。

（第1の実施形態）
インターネット通信で使われている主要なプロトコルとしてTCP/IPがある。従来のTCP/IPは主にソフトウェア処理によって実現されており、たとえばパソコンや組み込み機器などのCPUによって動作する。このような場合、ネットワークとのデータのやりとりは、主にはMAC/PHY機能を備えるNIC（Network Interface Card）または専用ASICやFPGAなどのLSIによって実行される（以降はこれをNICで代表して説明する）。

受信の場合は、ネットワークから受信されたパケットはNICからメモリにDMA転送され、その後にCPUのプロトコルスタックソフトウェアによってプロトコル処理が行われる。送信の場合は、CPUのプロトコルスタックソフトウェアによってメモリ上に生成されたパケットが、NICによってDMA転送で読み出されてネットワークに送信される。通常CPUではプロトコル処理のほかにアプリケーション処理も実行しており、プロトコルスタックとアプリケーションの間のデータの受け渡しでメモリコピーが行われる。これらのデータの流れを図示すると図2のようになる。

図2を見てわかるように、このような方式ではアプリケーションバッファとNICとの間でデータが一旦バッファリングされることになり、データがメモリ上を合計2往復することになる。そこで、プロトコル処理の一部をNICで行うことで、NICがアプリケーションバッファにダイレクトにデータを書き込む方式が従来、提案されている。この場合のデータの流れを図示すると図 3のようになる。こうすることによりデータの流れはメモリ上を1往復するだけになるので、データのコピーによる性能面・消費電力面でのオーバーヘッドを回避することができる。本処理は受信処理の例であるが、送信処理についても同様にメモリコピーを行わずに動作することが望ましい。

しかしながら、このように送信処理において単純にコピーを省くと、アプリケーションAPIとしてSocket APIを前提とした場合に問題が生じる。Socket APIはアプリケーションデータを一度に一つしか指定できないという制約がある。
具体的には、図4に示すように、アプリケーションがsend()関数を呼んであるアプリケーションデータを指定すると、その関数が返らないと、次のsend()関数を呼ぶことができない。このため、その関数が返るまで、次のアプリケーションデータの送信指示を行うことができない。それに対して、アプリケーションデータを指定されたプロトコルスタック側は、send()関数を返してしまうとそのアプリケーションデータは開放される可能性があるため、データを完全に送信し終わる、すなわち、アプリケーションデータの最後データの確認応答が返ってくるまで、データを再送する可能性があるため、send()関数を返すことができない（注：図2に示した構成ではスタックのバッファにコピーを行ってデータを保持しておくため、送信が終わっていない段階でsend()関数を返すことができる）。
確認応答が遅れる理由としては、例えば、（A）受信装置が遅延確認応答（後述）を行っている場合、（B）受信装置との間のネットワークの往復遅延が大きい場合、（C）受信装置の処理速度が遅い場合、などが挙げられる。このような場合、send()関数を返すタイミングが遅くなり、結果的に無通信時間が発生し、伝送レートが無駄に低下してしまう。

以上の問題を解決する本発明の実施形態を図1に示す。図1は基本的な構成を示すものであり、代表的な例としてはPC、サーバ、ASIC、FPGA（Field Programmable Gate Array）などで実現される。図１の装置は、例えばTCP/IPプロトコルをはじめとする通信プロトコルに基づいて、対向する受信装置からデータのシーケンス番号に基づいた確認応答を受けながら、連続したデータ送信を行うデータ送信装置である。

このデータ送信装置は、データ送信指示部101、パケット送信指示部102、データ記憶部103、データ読み出し部104、ヘッダ生成部105、パケット生成部106、ネットワークI/F部107、確認応答受信部108、パケット再送指示部109、データコピー部110、送信完了判定部111で構成される。

データ送信指示部101は、アプリケーションデータの送信を指示するデータ送信指示を生成する。

パケット送信指示部102は、データ送信指示に基づいて、パケット毎の送信を連続的にわせるパケット送信指示を生成する。

データ記憶部103は、送信するアプリケーションデータを記憶するデータ記憶領域と、一時バッファ領域（以下、一時バッファ）とを有する。

データ読み出し部104は、パケット送信指示を受け、データ記憶部103のデータ記憶領域からアプリケーションデータを1パケット分読み出す。

ヘッダ生成部105は、パケット送信指示を受け、送信するパケットに含まれるデータのシーケンス番号情報を含むヘッダを生成する。

パケット生成部106は、生成されたヘッダと読み出されたデータからパケットを生成する。

ネットワークI/F部107は、生成したパケットのネットワークへの送信、及び、ネットワークからのパケットの受信を行う。

確認応答受信部108は、送信したパケットのデータのうち、どのデータまで受信されたかを示す確認応答シーケンス番号情報を含む確認応答パケットを受信する。

パケット再送指示部109は、受けた確認応答シーケンス番号情報から再送するデータを特定し、データ読み出し部104とヘッダ生成部105に、特定したデータのパケット送信指示を行う。

データコピー部110は、データ読み出し部104がデータを読み出した際、そのデータがアプリケーションデータの終端から数えて所定のバイト数以内のデータの場合、読み出したデータをデータ記憶部103にコピーとして保存する。

送信完了判定部111は、データ読み出し部104がアプリケーションデータの終端までデータを読み出し、かつ、前記アプリケーションデータの終端から数えて所定のバイト数以内のバイトに相当する確認応答シーケンス番号情報を含む確認応答を受信したとき、アプリケーションデータの送信完了を判定し、送信完了をデータ送信指示部101に通知する。送信完了が判定されると、次に送信するアプリケーションデータが、データ記憶部103のデータ記憶領域に上書きされる。

一例として、データ送信指示部101はデータ送信装置のホストCPU上のアプリケーションソフトウェア、データ記憶部103はSDRAMなどの外部メモリ、それ以外の部分についてはNIC、ASIC、FPGAなどホストCPUとは別のハードウェアで実現される形態が考えられるが、その限りではない。たとえば当該それ以外の部分がソフトウェアにより実現されてもよい。

具体的な処理の流れは次のようになる。まず、データ送信指示部101が、送信したいアプリケーションデータを、例えばメモリ上の先頭アドレスと長さ（アドレス0x42000000、長さ1MBなど）を指定して、パケット送信指示部102に指示を出す。これは例えば、Socket APIのsend()関数などで実現される。

パケット送信指示部102は、指定されたアプリケーションデータを先頭から1パケットのデータ長（例えばTCPの最大セグメントサイズ。1460バイトなど）毎に切り出す。パケット送信指示部102は、切り出したデータの先頭アドレス、長さ、先頭データのシーケンス番号などを指定して、ヘッダ生成部105にヘッダ生成指示、データ読み出し部104にデータ読み出し指示を、連続的に出す。

例えばシーケンス番号が1から始まる場合、1パケット目の指示はアドレス0x42000000、長さ1460バイト、先頭データ（バイト）のシーケンス番号1とあらわされる。これは、シーケンス番号1から始まる長さ1460バイトのバイト列、という意味であり、実際にはシーケンス番号1〜1460のデータを指示していることになる。2パケット目の指示はアドレス0x420005b4、長さ1460バイト、シーケンス番号1461となり、3パケット目の指示はアドレス0x42000b68、長さ1460バイト、シーケンス番号2921、となる。なお、ここではシーケンス番号がバイト毎に1ずつ付与される例を示しているが、本発明はこの限りではない。

また、アプリケーションデータが1MB（ = 1024×1024バイト）だとすると、1024×1024 / 1460 = 718余り296なので、718パケット目まで上記と同様に長さが1460バイトとなり、最後の719パケット目は長さ296バイトとなる。すなわち、最後の719パケット目の指示はアドレス0x420ffed8、長さ296バイト、シーケンス番号1048281、となる。

ヘッダ生成部105は、このような指示に基づいて指定されたシーケンス番号を含むTCP/IPヘッダをプロトコル仕様に基づいて生成する。データ読み出し部104は、指定されたアドレスから指定された長さだけデータ記憶部103からデータを読み出す。ヘッダ生成部105は、生成したヘッダをパケット生成部106に渡し、データ読み出し部104は、読み出したデータを、後段のパケット生成部106に渡す。

パケット生成部106はそれらを結合してパケットを生成し、さらにチェックサムなどをヘッダに付加してネットワークI/F部107に渡す。ネットワークI/F部107は、そのパケットをネットワークの先の受信装置に向けて送信する。

送信されたパケットが受信装置によって受信されると、受信装置はプロトコル仕様に基づき、受信したことの確認応答を返す。つまり、受信したデータの次に期待するデータのシーケンス番号を確認応答シーケンス番号として確認応答パケットに含め、送信装置に応答する。

送信装置はその確認応答パケットを受け、確認応答シーケンス番号を見ることで、そのシーケンス番号より手前のデータは受信装置に到達したことを確認することができる。

もしネットワーク上でパケットが損失した場合は、受信装置では離散したシーケンス番号のパケットを受信することになる。その場合、例えばTCP/IPのプロトコル仕様では、受信装置は連続して受信した最後のデータのシーケンス番号の次に期待するデータのシーケンス番号を応答する。

たとえば、まずシーケンス番号1、長さ1460バイトのパケットを受信して確認応答シーケンス番号1461を応答し、その後にシーケンス番号1461、長さ1460バイトのパケットを受信して確認応答シーケンス番号2921を応答したとする。その次には、シーケンス番号2921のパケットの受信が期待される。しかし、このパケットがネットワーク上で損失して、その次のパケットであるシーケンス番号4381、長さ1460バイトのパケットを受信したとする。この場合は、あくまで連続して受信したのはシーケンス番号2920までのデータなので、確認応答シーケンス番号2921の確認応答パケットを応答することになる。

すると、その後の後続パケットが受信装置に到達しても、受信装置からの確認応答パケットに含まれる確認応答シーケンス番号は全て2921なので、確認応答シーケンス番号2921の確認応答パケットが重複することになる。

送信装置は、この重複した確認応答シーケンス番号を検知することで、そのシーケンス番号で始まるパケットがネットワーク上で損失したことを検知することができる。つまり、前述のパケット再送指示部109は、この重複した確認応答シーケンス番号のパケットを再送するパケットとして特定し、そのシーケンス番号2921の再送指示を出す。

具体的には、アドレス0x42000b68（シーケンス番号2921と開始シーケンス番号1との差をアプリケーションデータの先頭アドレス0x42000000に加算して算出）、長さ1460バイト、シーケンス番号2921、として出す。そして、ヘッダ生成部105、データ読み出し部104、パケット生成部106、ネットワークI/F部107はこの指示に基づいて、先と同様に再送パケットをネットワークに送信する。

再送パケットの特定方法に関しては上記の限りではなく、その他には例えば一定時間の間確認応答が返ってこなければ、その時点で受信している最大の確認応答シーケンス番号を再送パケットのシーケンス番号として特定する方法なども挙げられる。これらの再送パケットの特定方式はほんの一例であり、TCP/IPなどのプロトコル仕様に基づいて特定されるこれ以外の特定方式も本発明の実施形態に適用できるものとする。これらの特定方式自体は本発明の実施形態とは無関係であり、また本発明の実施形態を限定するものではない。

また、確認応答受信部108はパケットの受信時に動作することから、典型的にはその他の機能部によるパケットの送信処理とは非同期に行われる。よって、確認応答受信部108が受けた確認応答シーケンス番号の情報は、確認応答パケットを受信した時点で確認応答受信部108によっていったん不図示のメモリ等に記憶される形態も可能である。この場合、送信完了判定部111、パケット再送指示部109、その他パケット送信時に確認応答シーケンス番号の情報を参照する全ての機能部は、このメモリ等を読みだすことで確認応答シーケンス番号の情報を取得する。

以上のようにして、アプリケーションデータを直接読み出しながらパケット送信、確認応答に基づくパケット再送が行われる。最終的にアプリケーションデータの最後のバイトの次のバイトに対応する確認応答シーケンス番号を含む確認応答パケットを受信した時点で、全てのデータを相手に送達できたことを確認できる。

しかしながら、最後のバイトの次のバイトに対応する確認応答シーケンス番号を含む確認応答パケットの受信は、前述のように遅れる場合がある（図4参照）。これは、前述した（A）の遅延確認応答によるものである。（A）の遅延確認応答とは、例えばTCP/IPにおけるDelayed ACKに相当する。受信装置がデータパケットを受け取るたびに確認応答を行うのは必ずしも必要ではないことから、通信負荷及び送受信装置の処理負荷を減らすため、2パケット分のデータを受ける毎に2パケット分まとめて確認応答を出すことである。遅延確認応答では、最後の送信データが2パケットであり、かつこれら2パケットのセグメント長が、最大セグメント長のときは、遅延なく確認応答が返されるが、最後の送信データが1パケットのとき、もしくは2パケットの場合の最後のパケットのセグメント長が最大セグメント長未満のときは、仕様により確認応答が遅延するという特徴がある。

そこで本発明の実施形態では、それを完全に待つことをせずに送信完了を判定し、次のアプリケーションデータの送信を実行可能とするように動作する。これを図 5を用いて詳細に説明する。図5は送信するデータ列を示したものであり、右向きにシーケンス番号が増加していくように記載している。

まず、データ送信指示部101がアプリケーションデータ（1）（太線部）を指定する。すると、パケット送信指示部102が図のようにデータを7つのパケット分に分割して順次パケット送信指示を出す。この送信指示に基づいて、データ読み出し部104がパケット毎にデータ記憶部（メモリ）103からデータの読み出しを行い、ヘッダ生成部105がヘッダの生成を行い、パケット生成部106がこれらのデータおよびヘッダに基づきパケットを生成し、ネットワークIF部107を介して送信する。

ここで、データ読み出し部104は、読み出すデータがアプリケーションデータの終端から所定の長さ（この場合は2パケット分のデータの長さ）以内の場合、そのデータを再送のために一時的にデータ記憶部103のアプリケーションデータが格納されている領域（データ記憶領域）とは別の領域（一時バッファ）に記憶する。つまり、図5に示すように、データコピー部110が、データ読み出し部104により読み出されたデータを、アプリケーションデータが格納されている領域とは別の領域（例えば0x60000000）の一時バッファ（2）にコピー（3）する。

以上の動作と並行して受信装置からの確認応答パケットを順次受信する。受信したパケットに含まれる確認応答シーケンス番号が、先程一時バッファにコピーしたデータの先頭のデータに対応するシーケンス番号以上の値になった場合、コピーしたデータより小さいシーケンス番号のデータ（ここでは現在のアプリケーションデータのうちコピーをしていないデータに相当）は受信側に対して全て送達できたことを確認できたことになる。したがって、その時点で送信完了判定部111がアプリケーションデータの送信完了を判定し、データ送信指示部101に通知する。これは、例えばSocket APIのsend()関数で送信指示が行われた場合、そのsend()関数が返ることをもって通知される。

すると、データ送信指示部101は次のアプリケーションデータ（5）（図5の三本線部）を再びsend()関数を呼ぶなどして指定し、パケット送信指示部102はそのデータを同様にパケットに分割して送信指示を出す。次のアプリケーションは、データ記憶部103のデータ記憶領域に書き込まれる。これは、１つ前のアプリケーションデータと同じ領域に書き込まれる場合もあるし、別の領域に書き込まれる場合もある。

ここで、受信装置からの確認応答によって再送を行う際、図の（6）以降のシーケンス番号のデータを再送する場合は、データ読み出し部104は次のアプリケーションデータ（6）からデータを直接読みだし、（6）より手前のシーケンス番号のデータを再送する場合は、データ読み出し部104は先程コピーしたデータが記憶されている一時バッファ（2）からデータを読み出す。

このように動作することで、全てのデータをコピーすることなく、受信装置からの確認応答が遅れた場合でも、それを待たずして次のアプリケーションデータの送信を行うことができる。結果的に無通信時間の少ない連続的なデータ送信が可能となり、データ送信の高速化を、低消費電力で実現することができる。

なお、以上の例ではアプリケーションデータの終端から2パケット分の長さのデータを一時バッファにコピーする例を示したが、この長さに関してはこの限りではない。

確認応答が遅延する理由として、前述の通り、（A）受信装置が遅延確認応答を行っている場合、（B）受信装置との間のネットワークの往復遅延が大きい場合、（C）受信装置の処理速度が遅い場合、などが挙げられる。

（A）の遅延確認応答とは、前述したように、TCP/IPにおけるDelayed ACK等に相当し、通信負荷及び送受信装置の処理負荷を減らすため、2パケット分のデータを受ける毎に2パケット分まとめて確認応答を出すことである。この場合、ネットワーク上でパケットが損失しなかった場合、いかなるアプリケーションデータのサイズでも、ワーストケースで必ずデータの最後から2パケット分より時間的に前のパケットの確認応答は遅延されずに返ってくる。したがって、送信装置では必ず2パケット分のデータをコピーして、この分の確認応答を待たずして次のアプリケーションデータを送信するように動作すれば、常に遅延確認応答の影響を受けずにデータ送信を行うことができる。

これをもう少し詳しく説明すると次のようになる。図6はアプリケーションデータとそれに対する確認応答（実線矢印）の様子である。通常はこのように最後のパケットが最大セグメントサイズより短いが、この場合、コピーするのは最大セグメントサイズ×1＋最後の短いパケット分（点線矢印の長さ分）になる。

以上はパケットの個数が偶数個の場合だが、図 7のようにパケットの数が奇数個の場合は、最後の短いパケットだけの確認応答が遅れることになるので、このような場合は最後の1パケットだけコピーすればよい。

このようにパケット数の偶奇によって当にコピーすべきサイズは最後の2パケットであったり、最後の1パケットであったりするが、簡単にはワーストケースとして最後の2パケットをコピーしておけば常に遅延の影響を受けずに済む。より最適には、以上のいずれになるかを予測して、1パケットでよい場合は1パケットだけコピーするように動作することが望ましい。このような判断のもとに、コピーするデータサイズを特定するコピーサイズ特定部112を備えた構成を図 8に示す。図1と同一名称の要素には同一の符号を付して、拡張された処理を除き、重複する説明を省略する。コピーサイズ特定部112は、パケット数の偶奇を判断し、偶数の場合は最後の2パケット、奇数の場合は最後の1パケットのみコピーすることを決定し、データコピー部110に通知する。あるいは、偶数の場合は最後の2パケット分のデータ長、奇数の場合は最後の1パケットのデータ長を特定し、特定したデータ長をデータコピー部110に通知する。データコピー部110は、通知された情報にしたがって、コピーを行う。

また、以上は前述の確認応答が遅れる理由（A）の場合に対応した形態だが、（B）受信装置との間のネットワークの往復遅延が大きい場合、（C）受信装置の処理速度が遅い場合、に対応に対しては、以下の形態が可能である。送信装置において、直ちに返ってくる偶数パケット目の確認応答の、対応するデータを送信した時間からの経過時間、すなわち、確認応答の遅延時間と、現在のデータ送信ビットレートを測定する。そして、これら遅延時間とデータ送信ビットレートの積に応じたデータサイズを、前述の1パケット分または2パケット分のサイズへ、さらに加えたサイズだけをコピーする。積に応じたデータサイズとしては、当該積の値そのものでもよいし、あるいは、最大セグメント長×2が当該積の値以上のときは、最大セグメント長×2でよい。当該最大セグメント長×2が当該積の値未満のときは、当該積の値未満で、最大セグメント長×2の倍数の最大値、あるいは当該積の値以上で、最大セグメント長×2の倍数の最小値でもよい。送信完了判定では、追加コピーされたデータの確認応答を待たずして、送信完了を判定することができる。

確認応答の遅延時間を測定する遅延測定部113、送信ビットレートの測定を行う送信レート測定部114を備えた構成を図9に示す。図8と同一名称の要素には同一の符号を付して、拡張された処理を除き、重複する説明を省略する。遅延測定部113は、パケット生成部がパケットをネットワークI/F部に渡してから確認応答が受信されるまでの遅延時間を、直ちに返ってくる偶数パケット目について測定する。送信レート測定部114は、パケット生成部106により生成されるパケットの送信を観測することで、データ送信における単位時間当たりの送信データ長さを測定することで、送信ビットレートを得る。コピーサイズ特定部112は、これら遅延時間と送信ビットレートとに基づき、追加してコピーするサイズを特定し、特定したサイズを、前述したデータサイズ（たとえば2パケット分）に加算した値だけ、コピーを行う。送信完了判定部111は、全てのデータのパケットを送信し、かつ、コピーするデータの先頭バイトのシーケンス番号以上を示す確認応答を受信した時点で、送信完了を判定する。このような形態によって、（B）や（C）の遅延が加わっても、その影響を受けずに連続したデータ送信を実現できる。

次に、データ送信がさらに進んだ場合の処理について述べる。以上の例では、あるアプリケーションデータの送信に引き続き、その次のアプリケーションデータの送信が実行される処理について説明した。

この「次のアプリケーションデータ」の送信が進んでその終端に近づくと、最初のアプリケーションデータの送信と同様に、やがて一時バッファへのデータコピーを行うことになる。しかしながら、この時点で最初のアプリケーションデータの最後のデータ（＝最初のアプリケーションデータをコピーした一時バッファ上の最後のデータ）に対する確認応答（つまり図5において（6）のシーケンス番号の確認応答）が返ってきていない場合、依然としてその一時バッファのデータを再送する可能性があることから、一時バッファ上のデータを残しておく必要がある。

よって、その状態で次のアプリケーションデータの一時バッファへのコピーを実行してしまうと、一時バッファ上のデータが次のアプリケーションデータによって上書きされてしまうため、その後に最初のアプリケーションデータの再送を行った場合、本来とは異なるデータを再送してしまうという問題が生じる。この問題を回避する形態を図10に示す。

図10は図1に加え、パケット送信指示部102のパケット送信指示を一時的に止めさせるパケット送信抑制部115を備えている。図1と同一名称の要素には同一の符号を付して、拡張された処理を除き、重複する説明を省略する。

図 11は 図 5と（1）〜（6）まで同じであり、アプリケーションデータ（5）の一時バッファへのコピーの開始時点を示す（7）が加わっている。

上述のように次のアプリケーションデータの送信がこの（7）まで到達したとする。このとき、パケット送信抑制部115は、その前のアプリケーションデータの最後のデータ（6）の確認応答が返ってきていない間は、パケット送信指示部102にパケット送信を一時的に止めさせる。確認応答が返ってきたら、パケット送信を再開させる。このように動作することで、一時バッファに残っているひとつ前のアプリケーションデータを、現在のアプリケーションデータで上書きすることがなくなるので、上述の問題を回避することが出来る。

より最適には次のようにしてもよい。データ（6）の確認応答が返ってきていなくても、データ（6）より1パケット手前の確認応答が返ってきている場合は、一時バッファ内の2パケット分のうち最初の1パケット目のデータは送達が確認できたことになるので再送は不要となり、データを解放してよいことを意味する。よって、この場合は（7）のパケット送信を行い、そのパケットのデータを一時バッファの1パケット目の領域にコピーし、（7）より次のパケットの送信に達した時に、パケット送信指示を止めさせるように動作してもよい。

しかしながら、以上のような送信抑制は性能を少なからず低下させる場合がある。例えばアプリケーションデータが、一時バッファへのコピーサイズより小さい場合に顕著である。なぜなら、この場合アプリケーションデータは全て一時バッファにコピーすることになるので、つまりはこの時点でひとつ前のアプリケーションデータの最後のデータの確認応答が返ってきていない場合は、全くデータを送信できなくなる。このような場合でも性能を低下させないようにするには、より複雑な一時バッファの管理を行うことが望ましい。その場合の形態を図 12に示す。図 12は図 10に加え、一時バッファの管理を行うバッファ管理部を備えている。図10と同一名称の要素には同一の符号を付して、拡張された処理を除き、重複する説明を省略する。

バッファ管理部116の動作の一例としては、複数の一時バッファおよびそのアドレス情報を管理する形態が考えられる。例えば一時バッファ1〜8の8つの一時バッファを持っていたとすると、最初のアプリケーションデータのコピーは一時バッファ1を用い、次のアプリケーションデータのコピーは一時バッファ2を用い、その次のアプリケーションデータのコピーは一時バッファ3を用い、というように用いることで、確認応答が全く返ってこない段階でも8つのアプリケーションデータの送信を可能とする。また、1つ目のアプリケーションデータの最後のデータの確認応答が返ってくれば、1つ目の一時バッファを解放して9つめのアプリケーションデータのコピーに使用するなど、順次使いまわすことが出来る。

あくまでも一時バッファの個数は有限なので、それが枯渇した時点でパケット送信を抑制する動作は必要だが、このような複数の一時バッファの管理を行うことで、確認応答を待たずして複数のアプリケーションデータの送信を行うことができ、ひいては前述の性能低下を軽減することが出来る。

もう一つの例としては、コピーするデータを連結させる形態が考えられる。アプリケーションデータが一時バッファへのコピーサイズより小さい場合に性能の低下が顕著になる場合について説明したが、例えばこの場合、最初のアプリケーションデータのコピーを先頭から行い、それに後続して同じ一時バッファに次のアプリケーションデータのコピーを行う。

例えば最初のアプリケーションデータのコピーが1000バイトで、次のアプリケーションデータが3バイトだった場合、この3バイトのコピーを同じ一時バッファの1001〜1003バイト目に対して行う。さらに次のアプリケーションデータが15バイトだった場合、やはり同じ一時バッファの1004〜1018バイト目に対してコピーを行う。この状態で最初のアプリケーションデータのコピーの最初のデータのシーケンス番号を先頭としたパケットの再送を行う場合、簡単にはこれら1018バイトを全て読みだして連結したパケットを送信する。

実際にネットワークで損失したのは最初の1000バイトだけであり、その後ろの18バイトは受信装置にすでに到達している可能性があるが、その場合は受信装置によってその18バイトが破棄されるだけであり、特に問題とはならない場合がある。

以上のように、このような動作でも確認応答を待たずして複数のアプリケーションデータの送信を行うことができ、ひいては前述の性能低下を軽減することが出来る。なお、どこからどこまでが1パケットの塊かの情報（例えばこの場合だと1000バイト、3バイト、15バイトという情報）を別途保持して、この情報をもとに、先ほど説明した再送において1000バイトのみのパケットを再送してもよい。

（第2の実施形態）（FIN受信時の構成）
インターネット等で広く用いられるTCP/IPなどのプロトコル処理は、従来主にCPU上で動作するソフトウェアにより実現されていた。しかしながら、近年のネットワーク高速化に伴い、CPUのTCP/IP処理負荷が増大しており、TCP/IP処理を専用のハードウェアによって行うTOE（TCP/IP Offload Engine）を用いることにより、高速な通信を実現する装置が提案されている。

従来のデータ通信装置には、低速処理用の通信アダプタと高速処理用の通信アダプタを備え、アルゴリズムが複雑なTCPセッション接続および切断用のパケット処理のみを低速処理用の通信アダプタで実行し、映像データなどを含んだペイロード伝送用のパケット処理のみを高速アダプタで実行するものがあった。しかし、この装置では、ネットワーク上でロスなどが発生し、データの再送が発生している場合に、セッションを切断するためのコントロールフラグにFINがセットされたセグメント(以下、FINセグメント)を受信した時に問題があった。低速アダプタではFINセグメントを受信すると、セッション状態をCLOSE-WAITに遷移させるが、上記のようにデータの再送が発生している間にこの状態遷移を行うと、高速処理用の通信アダプタで、再送データを受信できなくなる問題があった。

以下、このような問題を解消する第２の実施形態について詳細に説明する。

図 13は、本発明の第2の実施形態に係わるデータ通信装置を示すブロック図である。
この第2の実施形態に係わるデータ通信装置は、クライアントからネットワークを介してTCPによりコンテンツを受信してストレージに保存したり、逆にストレージに蓄積されたコンテンツをネットワーク経由でクライアントに送信したりするコンテンツ蓄積サーバである。

このサーバは、CPU201、システムメモリ202、ストレージ203、TOE204から構成され、それぞれはローカルバスや、PCI Express などのバスで接続される。

CPU201は制御処理部215を備えている。TOE204は、データ処理部211と、データ終端検出部212と、データ受信完了判定部213と、データ終端受信完了通知部214と、情報共有部216とを備えている。

データ処理部211は、ネットワーク220を介してデータを送受信するための処理を行う。具体的に、データ処理部211は、相手装置からネットワークを介して一連のデータをデータ毎に受信する。

データ終端検出部212は、受信したデータに含まれるデータ終端情報（FINフラグ）を検出する。データ終端情報は、データ通信の終了指示に相当する。一連のデータの末尾の終端データが、このデータ終端情報を含んでいる。

データ受信完了判定部213は、データ終端情報が検出されると、一連のデータの全データの受信が完了したか否かを判定する。

データ終端受信完了通知部214は、データ終端までの全データの受信が完了したと判定されると、通信相手の機器に対して全データの受信が完了したと通知するよう、データ処理部211に指示する。

制御処理部215は、データ通信における自端末の状態（セッションの状態）を制御する。

情報共有部216は、制御処理部215とデータ処理部211で共有する、セッション情報を保持する。セッション情報は、制御処理部215で制御されるセッション状態も含んでいる。データ処理部211は、情報共有部216で保持されるセッション情報に基づき、データ通信を行う。たとえばデータ処理部211は、セッション状態がESTABLISHEDである間は、相手装置からのデータを受信するが、CLOSE-WAIT 1であるときは、データの受信を行わない。

本装置は、RFC793で定義されるTCPを用いて通信を行う。図 19にTCPのヘッダ構造を示す。

本装置を用いてクライアントからネットワークを介してコンテンツをストレージに蓄積する例について説明する。

まず、本装置では、各部の初期化処理などの後、CPU201の制御処理部215にて、TCPのセッション確立を行うための準備を行う。TCPのセッション状態一覧を図20の表に示す。本装置はサーバとして動作するため、例えば50000番などのあらかじめ決められたポート番号でTCPのセッション情報を作成し、その状態をLISTENに設定にする。なお図中の「ローカルユーザ」は、本装置のCPUで動作するアプリケーション等を意味する。図21の表にセッション情報の例を示す。このセッション情報をセッション毎に情報共有部216に保持する。なお、セッション情報はIPアドレスとポート番号を使って、ハッシュリストを作成し、合致するセッションの探索を高速化してもよい。

このように準備を行った状態で、他の通信装置(以降、相手装置とする)からTCPの接続要求が行われる。TCPでは、スリーウェイハンドシェイクと呼ばれる手順にて接続確立を行う。相手装置からは、例えばOSの割り当てた使用していないポート番号を始点ポート番号に設定し、終点ポート番号に本装置の待ち受けポート番号50000を設定し、シーケンス番号、データオフセット、ウィンドウサイズ、チェックサム、緊急ポインタを適切に設定し、コントロールフラグにはSYNのみを立てたTCPセグメント(以下、SYNセグメントと呼ぶ)が送信される。

ネットワークを介してこれを受信した本装置では、まずデータ処理部211で、TCPの下位層プロトコルの受信処理を行う。ここで、下位層のプロトコルとは、例えば、物理層およびデータリンク層はEthernet(R)であり、ネットワーク層はIPv4(Internet Protocol version 4)である。下位層プロトコルの処理が行われた後、TCPの受信処理を行う。

TCPの受信処理では、まずTCPのチェックサムが正しいかどうかの判別を行い、セグメントが壊れていないことを確認する。セグメントが壊れていないことを確認した後、セッション情報の探索を行う。

本装置では、CPU201とTOE204で協調してTCP/IPの処理を行うため、セッションの情報を情報共有部216にて共有している。この情報共有部216は、TOE204内のSRAM(Static Random Access Memory)で実現してもよいし、システムメモリ上で実現してもよい。

データ処理部211は、受信したセグメントのコントロールフラグフィールドを確認する。また、データ処理部211は、受信したTCPセグメントの始点IPアドレス、終点IPアドレス、始点ポート、終点ポートに合致するセッションが情報共有部216に存在するかどうか、また、そのセッション状態の確認を行う。

受信したセグメントと合致するセッションが存在し、セグメントに含まれるデータが受信ウィンドウ範囲内にある場合、データ処理部211はシステムメモリ202にデータを書き込み、ストレージ203にデータを保存し、RCV_NXTやRCV_WNDなどのセッション情報更新処理を行い、相手装置に対してコントロールフラグにACKをセットしたセグメント(ACKセグメント)を送信する。

ただし、データ処理部211は、セッション情報のRCV_SHUTがセットされている場合は、セグメントにデータが含まれていてもデータの処理は行わない。さらに、データ処理部211は以下の条件のいずれかに当てはまる場合、フレームを制御処理部215に渡し、制御処理部215で処理を行う。
・セッションの状態がSYN-RECEIVED(以下、SYN-RECV)である
・セッション情報のRCV_SHUTがセットされている
・受信したセグメントが、送信したFINセグメントに対するACKである
・受信したセグメントのコントロールフラグに、RST、SYN、FINのいずれかがセットされている
RCV_SHUTは以降のセグメントの受信を禁止するものである。制御処理部215にてセッションを切断する際のオプションとして送信のみを禁止するか、受信のみを禁止するか、送受ともに禁止するかを指定できる。この時、受信を禁止した場合にRCV_SHUTがセットされる。

制御処理部215は、セッション情報に合致しなかったTCPの処理を行う機能を備えており、クライアントからのSYNセグメントを受信した場合には、情報共有部216のセッション情報から、セッション状態がLISTEN状態で、かつ始点IPアドレス、終点IPアドレス、終点ポートが合致するセッションを探索する。

合致するものがなければ、コントロールフラグにRSTを立てたTCPセグメントを送信することをデータ処理部211に指示する。

一方、合致するセッションがあれば、セッション状態をSYN-RECVに変更し、初期化したシーケンス番号と、1増加させた確認応答番号、ウィンドウサイズ等の情報をセッション情報として保存する。

その後、コントロールフラグにSYNとACKを立てたTCPセグメント(以下、SYN-ACKと呼ぶ)を送信することをデータ処理部211に指示する。

クライアントでは、このSYN-ACKセグメントを受信すると、これに対するACKセグメントを送信する。

これを受信したデータ処理部211では、下位層プロトコルの処理を行った後、TCPのチェックサムを計算し、セグメントが壊れていなければ、セッションの探索を行う。探索により、合致するセッション情報が見つかり、そのセッション状態はSYN-RECVであるので、フレームをCPUの制御処理部215に渡す。制御処理部215では、SYNに対するACKセグメントであることを認識し、セッション状態をESTABLISHED状態に変更する。

なお、SYN-RECIEVED状態またはSYN-SENT状態で、SYNセグメントに対するACKセグメントを受信してESTABLISHED状態に変化させる時のみ、TOE204側で確認応答番号を1増加させ、セッションの状態をESTABLISHED状態に変化させる特定状態制御処理部(図示なし)を備えてもよい。特定状態制御処理部を備えることで、CPUの動作速度が十分でない場合にも、データセグメントを取りこぼすことなく、通信を行うことが可能となる。

状態がESTABLISHED状態になると、クライアントからデータの送信が行われる。このデータの転送では、データを含むTCPセグメントが送信され、それを受信した本装置では、データ処理部211で、下位層プロトコルとTCPのチェックサム計算を行い、情報共有部216からセッションを探索する。この場合、合致するセッションが見つかり、セグメントに含まれるデータが受信ウィンドウの範囲内であれば、情報共有部216のRCV_NXTやRCV_WNDといったセッション情報を更新し、データをシステムメモリ202上に書き込み、ストレージ203に保存する。また、さらに、受信したデータに対するACKセグメントを生成し、ネットワークを介して、クライアントに送信する。

図 14は、本発明の第2の実施形態に係わるデータ通信装置の動作を示すフローチャートである。

クライアントでは、送信すべきデータが全て送信されると、セッションを切断するため、コントロールフラグにFINをセットしたセグメントを生成し、送信する。

データ処理部211ではクライアントからのセグメントを受信し、下位層のプロトコル処理を行った後、TCPのチェックサム計算を行い、情報共有部216から合致するセッションの探索を行う（S101）。この場合、セッションの状態がESTABLISHEDのものが見つかる。続いて、シーケンス番号が受信ウィンドウ内であるかの確認と、確認応答番号の確認を行い、データが受信ウィンドウの範囲内であれば、情報共有部216のセッション情報のうち、RCV_NXTや、RCV_WNDといった値を更新し、システムメモリ202にデータを書き出し、ストレージ203にデータを保存する。また、相手装置にACKセグメントを送信する。

データ終端検出部212によりコントロールフラグにFINがセットされたセグメントの受信が検出されたか判断し（S102）、検出されないときは（S102のNO）、ステップS201に戻る。

FINがセットされたセグメントの受信が検出されると（S102のYES）、情報共有部216のセッション情報のFIN_RECVエントリに、FINを受信したことを設定する（S103）。また、FIN_SEQにFINセグメントに含まれる最後のデータのシーケンス番号を記憶させる（S103）。

データ受信完了判定部213は情報共有部216からセッション情報のRCV_NXTと、FIN_SEQを読み出し、RCV_NXTがFIN_SEQに達したかどうかを判定する（S104）。この時に、まだRCV_NXTがFIN_SEQに達していない場合は（S104のNO）、新たなセグメントを受信する度に、データ処理部211からデータ受信完了判定部213に通知を行い、データ受信完了の判定を行う。
データ終端が検出され、データ受信が完了したら（S104のYES）、制御処理部215に通知を行い、また、FINセグメントに対するACKセグメントを送信するようデータ終端受信完了通知部214がデータ処理部211に指示する（S105）。また制御処理部215が、状態をESTABLISHEDからCLOSE-WAITに遷移させる（S106）。なお、このときの確認応答番号はFINを1byte分のデータとして扱い、FIN_SEQ+1の値を確認応答番号として送信する。

上記のACKセグメントをクライアントで受信すると、クライアント側のセッション切断が完了し、ハーフクローズ状態となる。サーバでは、完了を検知してFINセグメントの送信を行い、クライアントからFINに対するACKセグメントが返ってきたら、サーバでのセッションの切断が完了する。

なお、上記では、TOE204内にデータ受信完了判定部213を備える場合で説明を行ったが、図 15のようにCPU205内にデータ受信完了判定部216を備える構成をとることもできる。この場合、データ処理部211から割り込みにより新たにセグメントが到着したことをデータ受信完了判定部216に通知する。その都度、データ受信完了判定部216では、情報共有部216からセッション情報のRCV_NXTとFIN_SEQを読み出し、RCV_NXTがFIN_SEQに達していれば制御処理部215に通知し、制御処理部215は状態遷移を行う。

また、データ処理部211からデータ受信完了判定部213に割り込みによる通知を行わない構成をとることもできる。この場合、データ受信完了判定部213は、例えば10msなどの一定間隔で情報共有部216のセッション情報のRCV_NXTとFIN_SEQの値を比較し、RCV_NXTがFIN_SEQに達した場合に、制御処理部215に通知することができる。

また、上記において、データ処理部211から制御処理部215にフレームを渡す手段としては、割り込みとレジスタ、共有メモリを用いて実現してもよい。例えば、フレームの格納場所のポインタを示すエントリで構成されたリングバッファを作成し、TOE204のレジスタを介して制御処理部215とデータ処理部211で処理が完了したインデックス番号を通知しあうようにし、割り込みでイベントの発生を通知する。

なお、相手機器が、FINセグメント以外の全セグメントに対するACKセグメントの受信を確認した後にFINセグメントの送信を行うようにすれば、本装置でFINセグメントを受信した後、全セグメントを受信したかどうかの判定を行う必要がなくなり、開発コストを低減させることができる。

このように、第2の実施形態に係わるデータ通信装置によれば、ネットワーク上でロスなどが発生し、データの再送が発生している場合において、FINセグメントを受信した時にも、全データの受信を完了してからセッションの状態遷移（ESTABLISHED→CLOSE-WAIT 1）を行うため、再送データをもれなく受信することが可能となる。

（第3の実施形態）（FIN送信時の構成）
インターネット等で広く用いられるTCP/IPなどのプロトコル処理は従来、主にCPU上で動作するソフトウェアにより実現されていた。しかしながら、近年のネットワーク高速化に伴い、CPUのTCP/IP処理負荷が増大しており、TCP/IP処理を専用のハードウェアによって行うTOE（TCP/IP Offload Engine）を用いることにより、高速な通信を実現する装置が提案されている。

従来のデータ通信装置には、低速処理用の通信アダプタと高速処理用の通信アダプタを備え、アルゴリズムが複雑なTCPセッション接続および切断用のパケット処理のみを低速処理用の通信アダプタで実行し、映像データなどを含んだペイロード伝送用のパケット処理のみを高速アダプタで実行するものがあった。

しかし、FINセグメントの送信において、低速処理用の通信アダプタと高速処理用の通信アダプタが非同期に動作するため、FINセグメントの送信時に問題が発生しうる。

FINセグメントは1バイトデータとして扱われるが、受信側のウィンドウサイズが1バイト以上あると判断して、低速処理用の通信アダプタが、FINセグメントを送信した場合、実際にはウィンドウサイズがゼロであったとき、フロー制御に違反したセグメントを送信してしまう。

また、FINセグメントに対するACKセグメントを送信する際、受信側の高速処理用の通信アダプタからデータが送信され続けていると、低速処理用の通信アダプタは、正しい確認応答番号を算出できなくなる。

さらに送信側の高速処理用の通信アダプタが、低速アダプタとは別のハードウェアで生成されたデータを、低速アダプタとは独立に受信側にデータを送信し続けている状況でFINセグメントを送信しようとすると、FINセグメントに付与するシーケンス番号を正しく算出できなくなる。

以下、これらの問題を解消する第3の実施形態について詳細に説明する。

図 16は、本発明の第3の実施形態に係わるデータ通信装置を示すブロック図である。

この第3の実施形態に係わるデータ通信装置は、テレビ電話サーバであり、クライアントからの映像を表示(音声もスピーカーから出力)し、ビデオカメラで撮影した映像(マイクから入力音声を含む)をクライアントに送信する。

この装置は、CPU301、システムメモリ302、マイク付のビデオカメラ303、スピーカー付のディスプレイ304、TOE305から構成され、それぞれはローカルバスや、PCI Expressなどのバスや、IEEE1394、HDMI(High-Definition Multimedia Interface)などで接続される。なお、ディスプレイのコントローラやデコーダ、エンコーダーについては省略している。CPU301では、映像表示に関わるアプリケーションが動作する。

CPU301は制御処理部312を備えている。TOE305は、データ処理部311と、制御処理部312と、情報共有部313と、データ終端設定部314と、データ終端送信判定部315とを備えている。

データ処理部311は、ネットワーク320を介してデータを送受信するための処理を行う。

制御処理部312は、データ通信における自端末の状態（セッションの状態）を制御する。

情報共有部313は、制御処理部312とデータ処理部313で共有するセッションの情報を保持する。セッションの情報は、上記セッション状態や、フロー制御で使うフロー制御情報（たとえばウィンドウサイズ）といった情報も含む。

データ終端設定部314は、データ送信の完了（セッションの終了）を通知する終端通知データ（FINセグメント）を生成し、データ処理部311に終端通知データの送信を指示する。

データ終端送信判定部315は、情報共有部313のフロー制御情報に基づき、終端通知データを相手装置に送信可能かどうかを判定する。

以下では、TCPによりクライアントからネットワークを介して映像データを送信し、その映像データが表す映像を本装置のサーバ側で表示し、また同一のTCPセッションでサーバから映像データをクライアントに送信する例について説明する。

セッション確立までは前記第2の実施形態と同様であるため、説明を省略する。セッション確立後、状態がESTABLISHED状態になると、クライアントからサーバに対して、映像が送信される。

受信されたデータは、第2の実施形態と同様にデータ処理部211で処理され、システムメモリ302を介してディスプレイ304に映像が表示される。一方、本サーバからは同一のTCPセッションを用いてネットワーク320を介し、クライアントへビデオカメラ303で撮影した映像のデータを送信する。

クライアントにおいて、データが受信されるとクライアントは、データ受信を正常に完了したことを通知するため、コントロールフラグにACKをセットし、正常受信したシーケンス番号を確認応答番号に設定したセグメントを送信する。

図 17は、本発明の第3の実施形態に係わるデータ通信装置のセッション切断動作を示すフローチャートである。

通話を終了する場合、TCPセッションを切断するため、コントロールフラグにFINをセットしたFINセグメントを送信する必要がある。以下、サーバから通話を切断する場合を例にして説明を行う。

まずビデオカメラに対して、CPU301で動作するアプリケーションは、撮影した映像の出力を止めるように指示する。次に、制御処理部312は、情報共有部313のセッションの状態を、ESTABLISHEDからFIN-WAIT-1に変更する（S201）。

次に、データ終端送信判定部315は、情報共有部313からセッション情報を読み出し、送信ウィンドウサイズSND_WND（フロー制御情報）が、0であるか否かを判定する（S202）。TCPにおいて、FINフラグは1byte分のデータとみなされるため、SND_WNDが0となっているとFINセグメントを送信することができない。よって、このデータ終端送信判定部315は、ウィンドウサイズが1byte以上あるかどうかで、FINセグメントの送信が可能かどうかを判定する。

可能であれば、データ終端設定部314は、データ処理部311に対して、コントロールフラグにFINをセットしたセグメント（FINセグメント）を送信するように指示する。指示を受けたデータ処理部311では、情報共有部313のセッション情報のRCV_NXTとSND_NXTを読み出してそれぞれ、確認応答番号とシーケンス番号に設定して、FINセグメントを送信する（S205）。

一方、送信可能でない場合は、送信ウィンドウが開くまで待つ処理を行う（S203、S204のNO）。すなわち、相手装置からウィンドウアップデート通知があるまで、データ処理部311で受信データを処理し、自装置の送信ウィンドウサイズが更新されたら（S204のYES）、再度判定を行う（S202）。

このように、本実施形態を用いることで、TOE内部でウィンドウサイズを検査し、FINセグメントを生成するため、相手装置のウィンドウサイズを適正に反映したFINセグメントを送信できる。よって、FINセグメントがウィンドウサイズ不足により受信されないといった問題は防止される。

また、相手装置からデータを受信していて情報共有部313のセッション情報のRCV_NXTが常に変化している場合においても、FINセグメントの確認応答番号を正しく設定することができる。

また、上記実施形態ではサーバからのデータ送信を停止した上で、FINセグメントを送信する場合を示したが、データ送信を継続している状態で、FINセグメントを送信するようにしてもよい。この場合でも、TOE 内部でシーケンス番号を設定するため、FINセグメントのシーケンス番号を正しく設定できる。

上記では、FINを送信する場合について説明したが、データ終端設定部314を用いてコントロールフラグにRSTをセットしたセグメントを送信してもよい。RSTの場合、送信ウィンドウサイズの確認は不要なため、データ終端送信判定部315での判定は常に真となる。

また、図 18に示すようにデータ終端設定部314およびデータ終端送信判定部315をTOE305ではなく、CPU301が備えてもよい。この場合、送信ウィンドウサイズが変化した際に、データ処理部311からの割り込みによりデータ終端送信判定部315に通知されるようにして、FINセグメントの送信が可能かを、判定するようにしてもよい。また、データ終端送信判定部315が、タイマなどを用い、一定間隔で情報共有部313から送信ウィンドウサイズを読み出し、送信可能か判定してもよい。

以上、本発明の実施の形態について説明した。本発明は上述した実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態にわたる構成要素を適宜組み合わせてもよい。

また、上述した実施形態で説明した装置の少なくとも一部は、ハードウェアで構成してもよいし、ソフトウェアで構成してもよい。また、装置の少なくとも一部の機能を実現するプログラムを、フレキシブルディスクやCD-ROM等の記録媒体に収納し、コンピュータに読み込ませて実行させてもよい。記録媒体は、磁気ディスクや光ディスク等の着脱可能なものに限定されず、ハードディスク装置やメモリなどの固定型の記録媒体でもよい。

また、装置の少なくとも一部の機能を実現するプログラムを、インターネット等の通信回線（無線通信も含む）を介して頒布してもよい。さらに、同プログラムを暗号化したり、変調をかけたり、圧縮した状態で、インターネット等の有線回線や無線回線を介して、あるいは記録媒体に収納して頒布してもよい。

Claims (2)

1. フロー制御を行うプロトコルを用いて相手装置とデータ通信を行うデータ通信装置であって、
   前記データ通信のセッション状態を管理する制御処理部と、
   前記セッション状態と、前記フロー制御で使用するフロー制御情報を記憶する情報記憶部と、
   前記フロー制御情報と前記セッション状態に基づき、前記相手装置とネットワークを介してデータ通信を行い、前記データ通信に応じて前記フロー制御情報を更新するデータ処理部と、
   前記情報記憶部内の前記フロー制御情報に基づき、前記相手装置に前記データ通信の終了を通知する終端通知データを送信可能かどうか判定するデータ終端送信判定部と、
   前記データ終端送信判定部により可能と判定されたとき、前記終端通知データを送信することを前記データ処理部に指示するデータ終端設定部と、
   を備え、
   前記データ処理部は、前記終端通知データを前記相手装置に送信し、
   前記データ終端設定部は、前記データ終端送信判定部により不可と判定されたとき、可能と判定されるまで、前記終端通知データの送信指示を待機する
   データ通信装置。
2. フロー制御を行うプロトコルを用いて相手装置とデータ通信を行うデータ通信装置に実行させる通信プログラムであって、
   前記データ通信のセッション状態を管理する制御処理ステップと、
   前記セッション状態を情報記憶部に書き込むステップと、
   前記フロー制御で使用するフロー制御情報を前記情報記憶部に書き込むステップと、
   前記フロー制御情報と前記セッション状態に基づき、前記相手装置とネットワークを介してデータ通信を行い、前記データ通信に応じて前記フロー制御情報を更新するデータ処理ステップと、
   前記情報記憶部内の前記フロー制御情報に基づき、前記相手装置に前記データ通信の終了を通知する終端通知データを送信可能かどうか判定するデータ終端送信判定ステップと、
   前記終端通知データを送信するデータ終端設定ステップと、
   を備え、
   前記データ処理ステップは、前記データ終端送信判定ステップが前記終端通知データを送信可能と判定したとき、前記終端通知データを前記相手装置に送信し、前記データ終端送信判定ステップが前記終端通知データを送信不可と判定したとき、前記データ終端送信判定ステップが前記終端通知データを送信可能と判定するまで、前記終端通知データの送信を待機する
   通信プログラム。

Images