データ送信装置、データ通信装置および通信プログラム
【課題】データ送信の性能が出ない問題、およびセッションの切断が正しく動作しない問題の少なくとも一方を解決する。
【解決手段】データ送信装置は、アプリケーションデータをパケットに分割して送信し、送信したパケットの受信装置からの確認応答を受けながら、連続的にパケット送信を行う。送信するアプリケーションデータをデータ記憶部のデータ記憶領域に記憶する。データ記憶領域からデータを読み出し、付与するシーケンス番号を設定し、パケットとして送信する。当該データを読み出した際、そのデータがアプリケーションデータの終端から所定の長さ以内のデータの場合、読み出したデータのコピーをデータ記憶部の一時バッファ領域に保存する。次のアプリケーションデータの送信が開始された後に、次のアプリケーションデータの最初のデータより前のシーケンス番号のデータを送信するときは、データ記憶部の一時バッファ領域からデータを読み出す。
【解決手段】データ送信装置は、アプリケーションデータをパケットに分割して送信し、送信したパケットの受信装置からの確認応答を受けながら、連続的にパケット送信を行う。送信するアプリケーションデータをデータ記憶部のデータ記憶領域に記憶する。データ記憶領域からデータを読み出し、付与するシーケンス番号を設定し、パケットとして送信する。当該データを読み出した際、そのデータがアプリケーションデータの終端から所定の長さ以内のデータの場合、読み出したデータのコピーをデータ記憶部の一時バッファ領域に保存する。次のアプリケーションデータの送信が開始された後に、次のアプリケーションデータの最初のデータより前のシーケンス番号のデータを送信するときは、データ記憶部の一時バッファ領域からデータを読み出す。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、データ送信装置、データ通信装置および通信プログラムに関するものである。
【背景技術】
【０００２】
インターネット等で広く用いられるTCP/IPなどのプロトコル処理は、従来主にCPU上で動作するソフトウェアにより実現されていた。しかしながら、近年のネットワーク高速化に伴い、CPUのTCP/IP処理負荷が増大しており、TCP/IP処理を専用のハードウェアによって行うTOE（TCP/IP Offload Engine）を用いることにより、高速な通信を実現する装置が提案されている。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】米国公開2004/0078462公報
【特許文献２】特開2009‐77024公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
TOEは通常CPU上で動作するソフトウェアから制御されるが、ソフトウェアからの制御を考慮すると、データ送信の性能が出なかったり、セッションの切断が正しく動作しなかったりするなどの問題がある。
【０００５】
本発明の一側面は、データ送信の性能が出ない問題、およびセッションの切断が正しく動作しない問題の少なくとも一方を解決することを目的とする。
【課題を解決するための手段】
【０００６】
本発明の一態様としてのデータ送信装置は、アプリケーションデータをパケットに分割して送信し、送信したパケットの受信装置からの確認応答を受けながら、連続的にパケット送信を行うデータ送信装置である。
【０００７】
前記データ送信装置は、データ送信指示部と、データ記憶部と、パケット送信指示部と、データ読み出し部と、データコピー部と、ヘッダ生成部と、ネットワークI/F部と、確認応答受信部と、パケット再送指示部と、送信完了判定部とを備える。
【０００８】
前記データ送信指示部は、前記アプリケーションデータの送信指示を生成する。
【０００９】
前記データ記憶部は、データ領域と一時バッファ領域とを有し、送信するアプリケーションデータを前記データ領域に記憶する。
【００１０】
前記パケット送信指示部は、前記アプリケーションデータの送信指示に基づいて、パケット毎の送信を連続的に行うためのパケット送信指示を生成する。
【００１１】
前記データ読み出し部は、前記パケット送信指示に基づいて、前記データ記憶部の前記データ領域からアプリケーションデータを1パケット分読み出す。
【００１２】
前記データコピー部は、前記データ読み出し部がデータを読み出した際、そのデータがアプリケーションデータの終端から所定の長さ以内のデータの場合、読み出したデータのコピーを前記データ記憶部の前記一時バッファ領域に保存する。
【００１３】
前記ヘッダ生成部は、前記パケット送信指示に基づき、送信するパケットに含まれるデータのシーケンス番号情報を含むヘッダを生成する。
【００１４】
前記パケット生成部は、生成されたヘッダと、読み出されたデータとから、パケットを生成する。
【００１５】
前記ネットワークI/F部は、生成したパケットを、ネットワークを介して前記受信装置に送信する。
【００１６】
前記確認応答受信部は、送信したパケットのデータのうち前記受信装置がどのデータまで受信したかを示す確認応答シーケンス番号情報を含む確認応答パケットを受信する。
【００１７】
前記パケット再送指示部は、前記確認応答シーケンス番号情報から再送するデータを特定し、前記データ読み出し部と前記ヘッダ生成部に、特定したデータの再送指示を行う。
【００１８】
前記送信完了判定部は、前記データ読み出し部がアプリケーションデータの終端までデータを読み出し、かつ、前記確認応答受信部が前記アプリケーションデータの終端から所定の長さ以内のデータより手前のデータの全てを受信したことを示す確認応答を受信したとき、前記アプリケーションデータの送信完了を判定し、送信完了を前記データ送信指示部に通知する。
【００１９】
前記データ送信指示部は、前記送信完了の通知を受けると次のアプリケーションデータの送信指示を生成する。
【００２０】
前記データ読み出し部は、前記次のアプリケーションデータの送信指示生成後に前記次のアプリケーションデータの最初のデータに相当するシーケンス番号より前のシーケンス番号のデータを送信するときは、前記データ記憶部の前記一時バッファ領域から前記データを読み出す。
【００２１】
本発明の一態様としてのデータ通信装置は、データの消失が検知された場合に送信側から前記データの再送を行うプロトコルを用いたデータ通信を行うデータ通信装置である。
【００２２】
前記データ通信装置は、データ処理部と、制御処理部と、情報記憶部と、データ終端検出部と、データ受信完了判定部とを備える。
【００２３】
前記データ処理部は、送信装置とネットワークを介して送受信し、受信においては一連のデータを前記データ毎に受信し、受信したデータを処理する。
【００２４】
前記制御処理部は、前記送信装置とのデータ通信のセッション状態を管理する。
【００２５】
前記情報記憶部は、前記セッション状態を記憶する。
【００２６】
前記データ終端検出部は、前記一連のデータの末尾の終端データが受信されたことを検出する。
【００２７】
前記データ受信完了判定部は、前記終端データの受信が検知されたとき、前記一連のデータの受信がすべて完了しているか否かを判定する。
【００２８】
前記データ処理部は、前記情報記憶部に記憶された前記セッション状態に応じて、前記送信装置からのデータを処理する。
【００２９】
前記制御処理部は、前記データ受信完了判定部により前記一連のデータの受信がすべて完了していると判定されたとき、前記セッション状態を終了状態に遷移させ、完了していないと判定されたとき、完了したと判定されるまで、前記セッション状態の遷移を待機する。
【００３０】
本発明の一態様としてのデータ通信装置は、フロー制御を行うプロトコルを用いて相手装置とデータ通信を行うデータ通信装置である。
【００３１】
前記データ通信装置は、制御処理部と、情報記憶部と、データ処理部と、データ終端送信判定部と、データ終端設定部とを備える。
【００３２】
前記制御処理部は、前記データ通信のセッション状態を管理する。
【００３３】
前記情報記憶部は、前記セッション状態と、前記フロー制御で使用するフロー制御情報を記憶する。
【００３４】
前記データ処理部は、前記フロー制御情報と前記セッション状態に基づき、前記相手装置とネットワークを介してデータ通信を行い、前記データ通信に応じて前記フロー制御情報を更新する。
【００３５】
前記データ終端送信判定部は、前記情報記憶部内の前記フロー制御情報に基づき、前記相手装置に前記データ通信の終了を通知する終端通知データを送信可能かどうか判定する。
【００３６】
前記データ終端設定部は、前記データ終端送信判定部により可能と判定されたとき、前記終端通知データを送信することを前記データ処理部に指示する。
【００３７】
前記データ処理部は、前記終端通知データを前記相手装置に送信する。
【００３８】
前記データ終端設定部は、前記データ終端送信判定部により不可と判定されたとき、可能と判定されるまで、前記終端通知データの送信指示を待機する。
【図面の簡単な説明】
【００３９】
【図１】第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等の記録媒体に収納し、コンピュータに読み込ませて実行させてもよい。記録媒体は、磁気ディスクや光ディスク等の着脱可能なものに限定されず、ハードディスク装置やメモリなどの固定型の記録媒体でもよい。
【０１８１】
また、装置の少なくとも一部の機能を実現するプログラムを、インターネット等の通信回線（無線通信も含む）を介して頒布してもよい。さらに、同プログラムを暗号化したり、変調をかけたり、圧縮した状態で、インターネット等の有線回線や無線回線を介して、あるいは記録媒体に収納して頒布してもよい。
【技術分野】
【０００１】
本発明は、データ送信装置、データ通信装置および通信プログラムに関するものである。
【背景技術】
【０００２】
インターネット等で広く用いられるTCP/IPなどのプロトコル処理は、従来主にCPU上で動作するソフトウェアにより実現されていた。しかしながら、近年のネットワーク高速化に伴い、CPUのTCP/IP処理負荷が増大しており、TCP/IP処理を専用のハードウェアによって行うTOE（TCP/IP Offload Engine）を用いることにより、高速な通信を実現する装置が提案されている。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】米国公開2004/0078462公報
【特許文献２】特開2009‐77024公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
TOEは通常CPU上で動作するソフトウェアから制御されるが、ソフトウェアからの制御を考慮すると、データ送信の性能が出なかったり、セッションの切断が正しく動作しなかったりするなどの問題がある。
【０００５】
本発明の一側面は、データ送信の性能が出ない問題、およびセッションの切断が正しく動作しない問題の少なくとも一方を解決することを目的とする。
【課題を解決するための手段】
【０００６】
本発明の一態様としてのデータ送信装置は、アプリケーションデータをパケットに分割して送信し、送信したパケットの受信装置からの確認応答を受けながら、連続的にパケット送信を行うデータ送信装置である。
【０００７】
前記データ送信装置は、データ送信指示部と、データ記憶部と、パケット送信指示部と、データ読み出し部と、データコピー部と、ヘッダ生成部と、ネットワークI/F部と、確認応答受信部と、パケット再送指示部と、送信完了判定部とを備える。
【０００８】
前記データ送信指示部は、前記アプリケーションデータの送信指示を生成する。
【０００９】
前記データ記憶部は、データ領域と一時バッファ領域とを有し、送信するアプリケーションデータを前記データ領域に記憶する。
【００１０】
前記パケット送信指示部は、前記アプリケーションデータの送信指示に基づいて、パケット毎の送信を連続的に行うためのパケット送信指示を生成する。
【００１１】
前記データ読み出し部は、前記パケット送信指示に基づいて、前記データ記憶部の前記データ領域からアプリケーションデータを1パケット分読み出す。
【００１２】
前記データコピー部は、前記データ読み出し部がデータを読み出した際、そのデータがアプリケーションデータの終端から所定の長さ以内のデータの場合、読み出したデータのコピーを前記データ記憶部の前記一時バッファ領域に保存する。
【００１３】
前記ヘッダ生成部は、前記パケット送信指示に基づき、送信するパケットに含まれるデータのシーケンス番号情報を含むヘッダを生成する。
【００１４】
前記パケット生成部は、生成されたヘッダと、読み出されたデータとから、パケットを生成する。
【００１５】
前記ネットワークI/F部は、生成したパケットを、ネットワークを介して前記受信装置に送信する。
【００１６】
前記確認応答受信部は、送信したパケットのデータのうち前記受信装置がどのデータまで受信したかを示す確認応答シーケンス番号情報を含む確認応答パケットを受信する。
【００１７】
前記パケット再送指示部は、前記確認応答シーケンス番号情報から再送するデータを特定し、前記データ読み出し部と前記ヘッダ生成部に、特定したデータの再送指示を行う。
【００１８】
前記送信完了判定部は、前記データ読み出し部がアプリケーションデータの終端までデータを読み出し、かつ、前記確認応答受信部が前記アプリケーションデータの終端から所定の長さ以内のデータより手前のデータの全てを受信したことを示す確認応答を受信したとき、前記アプリケーションデータの送信完了を判定し、送信完了を前記データ送信指示部に通知する。
【００１９】
前記データ送信指示部は、前記送信完了の通知を受けると次のアプリケーションデータの送信指示を生成する。
【００２０】
前記データ読み出し部は、前記次のアプリケーションデータの送信指示生成後に前記次のアプリケーションデータの最初のデータに相当するシーケンス番号より前のシーケンス番号のデータを送信するときは、前記データ記憶部の前記一時バッファ領域から前記データを読み出す。
【００２１】
本発明の一態様としてのデータ通信装置は、データの消失が検知された場合に送信側から前記データの再送を行うプロトコルを用いたデータ通信を行うデータ通信装置である。
【００２２】
前記データ通信装置は、データ処理部と、制御処理部と、情報記憶部と、データ終端検出部と、データ受信完了判定部とを備える。
【００２３】
前記データ処理部は、送信装置とネットワークを介して送受信し、受信においては一連のデータを前記データ毎に受信し、受信したデータを処理する。
【００２４】
前記制御処理部は、前記送信装置とのデータ通信のセッション状態を管理する。
【００２５】
前記情報記憶部は、前記セッション状態を記憶する。
【００２６】
前記データ終端検出部は、前記一連のデータの末尾の終端データが受信されたことを検出する。
【００２７】
前記データ受信完了判定部は、前記終端データの受信が検知されたとき、前記一連のデータの受信がすべて完了しているか否かを判定する。
【００２８】
前記データ処理部は、前記情報記憶部に記憶された前記セッション状態に応じて、前記送信装置からのデータを処理する。
【００２９】
前記制御処理部は、前記データ受信完了判定部により前記一連のデータの受信がすべて完了していると判定されたとき、前記セッション状態を終了状態に遷移させ、完了していないと判定されたとき、完了したと判定されるまで、前記セッション状態の遷移を待機する。
【００３０】
本発明の一態様としてのデータ通信装置は、フロー制御を行うプロトコルを用いて相手装置とデータ通信を行うデータ通信装置である。
【００３１】
前記データ通信装置は、制御処理部と、情報記憶部と、データ処理部と、データ終端送信判定部と、データ終端設定部とを備える。
【００３２】
前記制御処理部は、前記データ通信のセッション状態を管理する。
【００３３】
前記情報記憶部は、前記セッション状態と、前記フロー制御で使用するフロー制御情報を記憶する。
【００３４】
前記データ処理部は、前記フロー制御情報と前記セッション状態に基づき、前記相手装置とネットワークを介してデータ通信を行い、前記データ通信に応じて前記フロー制御情報を更新する。
【００３５】
前記データ終端送信判定部は、前記情報記憶部内の前記フロー制御情報に基づき、前記相手装置に前記データ通信の終了を通知する終端通知データを送信可能かどうか判定する。
【００３６】
前記データ終端設定部は、前記データ終端送信判定部により可能と判定されたとき、前記終端通知データを送信することを前記データ処理部に指示する。
【００３７】
前記データ処理部は、前記終端通知データを前記相手装置に送信する。
【００３８】
前記データ終端設定部は、前記データ終端送信判定部により不可と判定されたとき、可能と判定されるまで、前記終端通知データの送信指示を待機する。
【図面の簡単な説明】
【００３９】
【図１】第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等の記録媒体に収納し、コンピュータに読み込ませて実行させてもよい。記録媒体は、磁気ディスクや光ディスク等の着脱可能なものに限定されず、ハードディスク装置やメモリなどの固定型の記録媒体でもよい。
【０１８１】
また、装置の少なくとも一部の機能を実現するプログラムを、インターネット等の通信回線（無線通信も含む）を介して頒布してもよい。さらに、同プログラムを暗号化したり、変調をかけたり、圧縮した状態で、インターネット等の有線回線や無線回線を介して、あるいは記録媒体に収納して頒布してもよい。
【特許請求の範囲】
【請求項１】
アプリケーションデータをパケットに分割して送信し、送信したパケットの受信装置からの確認応答を受けながら、連続的にパケット送信を行うデータ送信装置において、
前記アプリケーションデータの送信指示を生成するデータ送信指示部と、
データ領域と一時バッファ領域とを有し、送信するアプリケーションデータを前記データ領域に記憶するデータ記憶部と、
前記アプリケーションデータの送信指示に基づいて、パケット毎の送信を連続的に行うためのパケット送信指示を生成するパケット送信指示部と、
前記パケット送信指示に基づいて、前記データ記憶部の前記データ領域からアプリケーションデータを1パケット分読み出すデータ読み出し部と、
前記データ読み出し部がデータを読み出した際、そのデータがアプリケーションデータの終端から所定の長さ以内のデータの場合、読み出したデータのコピーを前記データ記憶部の前記一時バッファ領域に保存するデータコピー部と、
前記パケット送信指示に基づき、送信するパケットに含まれるデータのシーケンス番号情報を含むヘッダを生成するヘッダ生成部と、
生成されたヘッダと、読み出されたデータとから、パケットを生成するパケット生成部と、
生成したパケットを、ネットワークを介して前記受信装置に送信するネットワークI/F部と、
送信したパケットのデータのうち前記受信装置がどのデータまで受信したかを示す確認応答シーケンス番号情報を含む確認応答パケットを受信する確認応答受信部と、
前記確認応答シーケンス番号情報から再送するデータを特定し、前記データ読み出し部と前記ヘッダ生成部に、特定したデータの再送指示を行うパケット再送指示部と、
前記データ読み出し部がアプリケーションデータの終端までデータを読み出し、かつ、前記確認応答受信部が前記アプリケーションデータの終端から所定の長さ以内のデータより手前のデータの全てを受信したことを示す確認応答を受信したとき、前記アプリケーションデータの送信完了を判定し、送信完了を前記データ送信指示部に通知する送信完了判定部と、を備え、
前記データ送信指示部は、前記送信完了の通知を受けると次のアプリケーションデータの送信指示を生成し、
前記データ読み出し部は、前記次のアプリケーションデータの送信指示生成後に前記次のアプリケーションデータの最初のデータに相当するシーケンス番号より前のシーケンス番号のデータを送信するときは、前記データ記憶部の前記一時バッファ領域から前記データを読み出すこと、
を特徴とするデータ送信装置。
【請求項２】
前記所定の長さは、前記受信装置において確認応答を行うデータ間隔以下の長さであること、
を特徴とする請求項1に記載のデータ送信装置。
【請求項３】
前記所定の長さは、前記アプリケーションデータをパケットに分割した際の、最後の2パケット分のデータの長さであること、
を特徴とする請求項2に記載のデータ送信装置。
【請求項４】
前記確認応答シーケンス番号情報と前記アプリケーションデータの長さに基づき、前記所定の長さを、前記アプリケーションデータをパケットに分割した際の最後の2パケット分か1パケット分かのいずれかに特定するコピーサイズ特定部、
をさらに備えることを特徴とする請求項2に記載のデータ送信装置。
【請求項５】
前記所定の長さは、前記受信装置において確認応答を行うデータ間隔に対して、前記パケット生成部がネットワークI/F部にパケットを送ってから前記確認応答受信部がそのパケットに対する確認応答を受信するまでの時間と、データ送信における単位時間当たりの送信データ長さとの積、を加えた値に応じた長さである、
ことを特徴とする請求項1に記載のデータ送信装置。
【請求項６】
前記パケット生成部がネットワークI/F部にパケットを送ってから前記確認応答受信部がそのパケットに対する確認応答を受信するまでの時間を測定する遅延測定部と、
前記データ送信における単位時間当たりの送信データ長さを測定する送信データレート測定部と、
前記遅延測定部が測定した遅延時間が大きくなる、または、前記送信レート測定部が測定した送信レートが大きくなると、前記所定の長さを大きくし、前記遅延測定部が測定した遅延時間が小さくなる、または、前記送信レート測定部が測定した送信レートが小さくなると、前記所定の長さを小さくする、コピーサイズ特定部、
をさらに備えたことを特徴とする請求項5に記載のデータ送信装置。
【請求項７】
前記パケット送信指示部が、前記アプリケーションデータの終端から前記所定の長さ以内のデータを含むパケットの送信を指示する際に、前記データ記憶部の前記一時バッファ領域にこれ以上データをコピーできないと判断したとき、前記パケット送信指示部のパケット送信指示を一時的に止めさせるパケット送信抑制部、
をさらに備えたことを特徴とする請求項1ないし6のいずれか一項に記載のデータ送信装置。
【請求項８】
前記パケット送信抑制部は、前記確認応答受信部がひとつ前のアプリケーションデータの全ての確認応答を受信していないとき、前記データ記憶部にこれ以上データをコピーできないと判断すること、
を特徴とする請求項7に記載のデータ送信装置。
【請求項９】
バッファ管理部をさらに備え、
前記データ記憶部は、複数の一時バッファ領域を有し、
前記バッファ管理部は、複数の一時バッファ領域のアドレス情報を管理し、
前記データ記憶部の前記複数の一時バッファ領域はそれぞれ別のアプリケーションデータについてデータのコピーを記憶し、
前記パケット送信抑制部は、前記複数の一時バッファ領域の全てにアプリケーションデータについてのデータのコピーが記憶されているとき、前記データ記憶部にこれ以上データをコピーできないと判断すること、
を特徴とする請求項7に記載のデータ送信装置。
【請求項１０】
前記バッファ管理部は、前記複数のアプリケーションデータについてのデータのコピーが一つの前記一時バッファ領域に結合して記憶されるように管理する、
を特徴とする請求項7に記載のデータ送信装置。
【請求項１１】
アプリケーションデータをパケットに分割して送信し、送信したパケットの受信装置からの確認応答を受けながら、連続的にパケット送信を行うデータ送信装置に実行させる通信プログラムであって、
前記アプリケーションデータの送信指示を生成するデータ送信指示ステップと、
前記送信指示に基づいて、パケット毎の送信を連続的に行うためのパケット送信指示を生成するパケット送信指示部と、
データ記憶領域と一時バッファ領域とを有し、送信するアプリケーションデータを前記データ記憶領域に記憶するデータ記憶部から、前記パケット送信指示に基づいて、アプリケーションデータを1パケット分読み出すデータ読み出しステップと、
前記データ読み出しステップでデータを読み出した際、そのデータがアプリケーションデータの終端から所定の長さ以内のデータの場合、読み出したデータのコピーを前記データ記憶部の前記一時バッファ領域に保存するデータコピーステップと、
前記パケット送信指示に基づき、送信するパケットに含まれるデータのシーケンス番号情報を含むヘッダを生成するヘッダ生成ステップと、
生成されたヘッダと読み出されたデータからパケットを生成するパケット生成ステップと、
生成したパケットを、ネットワークを介して前記受信装置に送信するネットワ送信ステップと、
送信したパケットのデータのうち前記受信装置がどのデータまで受信したかを示す確認応答シーケンス番号情報を含む確認応答パケットを受信する確認応答受信ステップと、
前記確認応答シーケンス番号情報から再送するデータを特定し、前記データ読み出しステップと前記ヘッダ生成ステップに、特定したデータの再送指示を行うパケット再送指示ステップと、
前記データ読み出しステップがアプリケーションデータの終端までデータを読み出し、かつ、前記確認応答受信ステップが前記アプリケーションデータの終端から所定の長さ以内のデータより手前のデータの全てを受信したことを示す確認応答を受信したとき、前記アプリケーションデータの送信完了を判定する送信完了判定ステップと、
を前記データ送信装置に実行させ、
前記データ送信指示ステップは、前記送信完了の通知を受けると次のアプリケーションデータの送信指示を生成し、
前記データ読み出しステップは、前記次のアプリケーションデータの送信指示生成後に前記次のアプリケーションデータの最初のデータに相当するシーケンス番号より前のシーケンス番号のデータを送信するときは、前記データ記憶部の前記一時バッファ領域から前記データを読み出すこと、
を特徴とする通信プログラム。
【請求項１２】
データの消失が検知された場合に送信側から前記データの再送を行うプロトコルを用いたデータ通信を行うデータ通信装置であって
送信装置とネットワークを介して送受信し、受信においては一連のデータを前記データ毎に受信し、受信したデータを処理するデータ処理部と、
前記送信装置とのデータ通信のセッション状態を管理する制御処理部と、
前記セッション状態を記憶する情報記憶部と、
前記一連のデータの末尾の終端データが受信されたことを検出するデータ終端検出部と、
前記終端データの受信が検知されたとき、前記一連のデータの受信がすべて完了しているか否かを判定するデータ受信完了判定部と、
を備え、
前記データ処理部は、前記情報記憶部に記憶された前記セッション状態に応じて、前記送信装置からのデータを処理し、
前記制御処理部は、前記データ受信完了判定部により前記一連のデータの受信がすべて完了していると判定されたとき、前記セッション状態を終了状態に遷移させ、完了していないと判定されたとき、完了したと判定されるまで、前記セッション状態の遷移を待機する
データ通信装置。
【請求項１３】
前記データ受信完了判定部により前記一連のデータの受信が完了したと判定されたとき、前記送信装置に対して前記受信が完了したとの通知データを送信するデータ終端受信完了通知部
をさらに備えたことを特徴とする請求項12に記載のデータ通信装置。
【請求項１４】
フロー制御を行うプロトコルを用いて相手装置とデータ通信を行うデータ通信装置であって、
前記データ通信のセッション状態を管理する制御処理部と、
前記セッション状態と、前記フロー制御で使用するフロー制御情報を記憶する情報記憶部と、
前記フロー制御情報と前記セッション状態に基づき、前記相手装置とネットワークを介してデータ通信を行い、前記データ通信に応じて前記フロー制御情報を更新するデータ処理部と、
前記情報記憶部内の前記フロー制御情報に基づき、前記相手装置に前記データ通信の終了を通知する終端通知データを送信可能かどうか判定するデータ終端送信判定部と、
前記データ終端送信判定部により可能と判定されたとき、前記終端通知データを送信することを前記データ処理部に指示するデータ終端設定部と、
を備え、
前記データ処理部は、前記終端通知データを前記相手装置に送信し、
前記データ終端設定部は、前記データ終端送信判定部により不可と判定されたとき、可能と判定されるまで、前記終端通知データの送信指示を待機する
データ通信装置。
【請求項１５】
データの消失が検知された場合に送信側から前記データの再送を行うプロトコルを用いたデータ通信を行うためのデータ通信装置に実行させる通信プログラムであって、
送信装置とネットワークを介して送受信し、受信においては一連のデータを前記データ毎に受信し、受信したデータを処理するデータ処理ステップと、
前記送信装置とのデータ通信のセッション状態を管理し、前記セッション状態を情報記憶部に書き込む制御処理ステップと、
前記一連のデータの末尾の終端データが受信されたことを検出するデータ終端検出ステップと、
前記終端データの受信が検知されたとき、前記一連のデータの受信がすべて完了しているか否かを判定するデータ受信完了判定ステップと、
を備え、
前記データ処理ステップは、前記情報記憶部に記憶された前記セッション状態に応じて、前記送信装置からのデータを処理し、
前記制御処理ステップは、前記データ受信完了判定ステップにより前記一連のデータの受信がすべて完了していると判定されたとき、前記セッション状態を終了状態に遷移させ、完了していないと判定されたとき、完了したと判定されるまで、前記セッション状態の遷移を待機する、通信プログラム。
【請求項１】
アプリケーションデータをパケットに分割して送信し、送信したパケットの受信装置からの確認応答を受けながら、連続的にパケット送信を行うデータ送信装置において、
前記アプリケーションデータの送信指示を生成するデータ送信指示部と、
データ領域と一時バッファ領域とを有し、送信するアプリケーションデータを前記データ領域に記憶するデータ記憶部と、
前記アプリケーションデータの送信指示に基づいて、パケット毎の送信を連続的に行うためのパケット送信指示を生成するパケット送信指示部と、
前記パケット送信指示に基づいて、前記データ記憶部の前記データ領域からアプリケーションデータを1パケット分読み出すデータ読み出し部と、
前記データ読み出し部がデータを読み出した際、そのデータがアプリケーションデータの終端から所定の長さ以内のデータの場合、読み出したデータのコピーを前記データ記憶部の前記一時バッファ領域に保存するデータコピー部と、
前記パケット送信指示に基づき、送信するパケットに含まれるデータのシーケンス番号情報を含むヘッダを生成するヘッダ生成部と、
生成されたヘッダと、読み出されたデータとから、パケットを生成するパケット生成部と、
生成したパケットを、ネットワークを介して前記受信装置に送信するネットワークI/F部と、
送信したパケットのデータのうち前記受信装置がどのデータまで受信したかを示す確認応答シーケンス番号情報を含む確認応答パケットを受信する確認応答受信部と、
前記確認応答シーケンス番号情報から再送するデータを特定し、前記データ読み出し部と前記ヘッダ生成部に、特定したデータの再送指示を行うパケット再送指示部と、
前記データ読み出し部がアプリケーションデータの終端までデータを読み出し、かつ、前記確認応答受信部が前記アプリケーションデータの終端から所定の長さ以内のデータより手前のデータの全てを受信したことを示す確認応答を受信したとき、前記アプリケーションデータの送信完了を判定し、送信完了を前記データ送信指示部に通知する送信完了判定部と、を備え、
前記データ送信指示部は、前記送信完了の通知を受けると次のアプリケーションデータの送信指示を生成し、
前記データ読み出し部は、前記次のアプリケーションデータの送信指示生成後に前記次のアプリケーションデータの最初のデータに相当するシーケンス番号より前のシーケンス番号のデータを送信するときは、前記データ記憶部の前記一時バッファ領域から前記データを読み出すこと、
を特徴とするデータ送信装置。
【請求項２】
前記所定の長さは、前記受信装置において確認応答を行うデータ間隔以下の長さであること、
を特徴とする請求項1に記載のデータ送信装置。
【請求項３】
前記所定の長さは、前記アプリケーションデータをパケットに分割した際の、最後の2パケット分のデータの長さであること、
を特徴とする請求項2に記載のデータ送信装置。
【請求項４】
前記確認応答シーケンス番号情報と前記アプリケーションデータの長さに基づき、前記所定の長さを、前記アプリケーションデータをパケットに分割した際の最後の2パケット分か1パケット分かのいずれかに特定するコピーサイズ特定部、
をさらに備えることを特徴とする請求項2に記載のデータ送信装置。
【請求項５】
前記所定の長さは、前記受信装置において確認応答を行うデータ間隔に対して、前記パケット生成部がネットワークI/F部にパケットを送ってから前記確認応答受信部がそのパケットに対する確認応答を受信するまでの時間と、データ送信における単位時間当たりの送信データ長さとの積、を加えた値に応じた長さである、
ことを特徴とする請求項1に記載のデータ送信装置。
【請求項６】
前記パケット生成部がネットワークI/F部にパケットを送ってから前記確認応答受信部がそのパケットに対する確認応答を受信するまでの時間を測定する遅延測定部と、
前記データ送信における単位時間当たりの送信データ長さを測定する送信データレート測定部と、
前記遅延測定部が測定した遅延時間が大きくなる、または、前記送信レート測定部が測定した送信レートが大きくなると、前記所定の長さを大きくし、前記遅延測定部が測定した遅延時間が小さくなる、または、前記送信レート測定部が測定した送信レートが小さくなると、前記所定の長さを小さくする、コピーサイズ特定部、
をさらに備えたことを特徴とする請求項5に記載のデータ送信装置。
【請求項７】
前記パケット送信指示部が、前記アプリケーションデータの終端から前記所定の長さ以内のデータを含むパケットの送信を指示する際に、前記データ記憶部の前記一時バッファ領域にこれ以上データをコピーできないと判断したとき、前記パケット送信指示部のパケット送信指示を一時的に止めさせるパケット送信抑制部、
をさらに備えたことを特徴とする請求項1ないし6のいずれか一項に記載のデータ送信装置。
【請求項８】
前記パケット送信抑制部は、前記確認応答受信部がひとつ前のアプリケーションデータの全ての確認応答を受信していないとき、前記データ記憶部にこれ以上データをコピーできないと判断すること、
を特徴とする請求項7に記載のデータ送信装置。
【請求項９】
バッファ管理部をさらに備え、
前記データ記憶部は、複数の一時バッファ領域を有し、
前記バッファ管理部は、複数の一時バッファ領域のアドレス情報を管理し、
前記データ記憶部の前記複数の一時バッファ領域はそれぞれ別のアプリケーションデータについてデータのコピーを記憶し、
前記パケット送信抑制部は、前記複数の一時バッファ領域の全てにアプリケーションデータについてのデータのコピーが記憶されているとき、前記データ記憶部にこれ以上データをコピーできないと判断すること、
を特徴とする請求項7に記載のデータ送信装置。
【請求項１０】
前記バッファ管理部は、前記複数のアプリケーションデータについてのデータのコピーが一つの前記一時バッファ領域に結合して記憶されるように管理する、
を特徴とする請求項7に記載のデータ送信装置。
【請求項１１】
アプリケーションデータをパケットに分割して送信し、送信したパケットの受信装置からの確認応答を受けながら、連続的にパケット送信を行うデータ送信装置に実行させる通信プログラムであって、
前記アプリケーションデータの送信指示を生成するデータ送信指示ステップと、
前記送信指示に基づいて、パケット毎の送信を連続的に行うためのパケット送信指示を生成するパケット送信指示部と、
データ記憶領域と一時バッファ領域とを有し、送信するアプリケーションデータを前記データ記憶領域に記憶するデータ記憶部から、前記パケット送信指示に基づいて、アプリケーションデータを1パケット分読み出すデータ読み出しステップと、
前記データ読み出しステップでデータを読み出した際、そのデータがアプリケーションデータの終端から所定の長さ以内のデータの場合、読み出したデータのコピーを前記データ記憶部の前記一時バッファ領域に保存するデータコピーステップと、
前記パケット送信指示に基づき、送信するパケットに含まれるデータのシーケンス番号情報を含むヘッダを生成するヘッダ生成ステップと、
生成されたヘッダと読み出されたデータからパケットを生成するパケット生成ステップと、
生成したパケットを、ネットワークを介して前記受信装置に送信するネットワ送信ステップと、
送信したパケットのデータのうち前記受信装置がどのデータまで受信したかを示す確認応答シーケンス番号情報を含む確認応答パケットを受信する確認応答受信ステップと、
前記確認応答シーケンス番号情報から再送するデータを特定し、前記データ読み出しステップと前記ヘッダ生成ステップに、特定したデータの再送指示を行うパケット再送指示ステップと、
前記データ読み出しステップがアプリケーションデータの終端までデータを読み出し、かつ、前記確認応答受信ステップが前記アプリケーションデータの終端から所定の長さ以内のデータより手前のデータの全てを受信したことを示す確認応答を受信したとき、前記アプリケーションデータの送信完了を判定する送信完了判定ステップと、
を前記データ送信装置に実行させ、
前記データ送信指示ステップは、前記送信完了の通知を受けると次のアプリケーションデータの送信指示を生成し、
前記データ読み出しステップは、前記次のアプリケーションデータの送信指示生成後に前記次のアプリケーションデータの最初のデータに相当するシーケンス番号より前のシーケンス番号のデータを送信するときは、前記データ記憶部の前記一時バッファ領域から前記データを読み出すこと、
を特徴とする通信プログラム。
【請求項１２】
データの消失が検知された場合に送信側から前記データの再送を行うプロトコルを用いたデータ通信を行うデータ通信装置であって
送信装置とネットワークを介して送受信し、受信においては一連のデータを前記データ毎に受信し、受信したデータを処理するデータ処理部と、
前記送信装置とのデータ通信のセッション状態を管理する制御処理部と、
前記セッション状態を記憶する情報記憶部と、
前記一連のデータの末尾の終端データが受信されたことを検出するデータ終端検出部と、
前記終端データの受信が検知されたとき、前記一連のデータの受信がすべて完了しているか否かを判定するデータ受信完了判定部と、
を備え、
前記データ処理部は、前記情報記憶部に記憶された前記セッション状態に応じて、前記送信装置からのデータを処理し、
前記制御処理部は、前記データ受信完了判定部により前記一連のデータの受信がすべて完了していると判定されたとき、前記セッション状態を終了状態に遷移させ、完了していないと判定されたとき、完了したと判定されるまで、前記セッション状態の遷移を待機する
データ通信装置。
【請求項１３】
前記データ受信完了判定部により前記一連のデータの受信が完了したと判定されたとき、前記送信装置に対して前記受信が完了したとの通知データを送信するデータ終端受信完了通知部
をさらに備えたことを特徴とする請求項12に記載のデータ通信装置。
【請求項１４】
フロー制御を行うプロトコルを用いて相手装置とデータ通信を行うデータ通信装置であって、
前記データ通信のセッション状態を管理する制御処理部と、
前記セッション状態と、前記フロー制御で使用するフロー制御情報を記憶する情報記憶部と、
前記フロー制御情報と前記セッション状態に基づき、前記相手装置とネットワークを介してデータ通信を行い、前記データ通信に応じて前記フロー制御情報を更新するデータ処理部と、
前記情報記憶部内の前記フロー制御情報に基づき、前記相手装置に前記データ通信の終了を通知する終端通知データを送信可能かどうか判定するデータ終端送信判定部と、
前記データ終端送信判定部により可能と判定されたとき、前記終端通知データを送信することを前記データ処理部に指示するデータ終端設定部と、
を備え、
前記データ処理部は、前記終端通知データを前記相手装置に送信し、
前記データ終端設定部は、前記データ終端送信判定部により不可と判定されたとき、可能と判定されるまで、前記終端通知データの送信指示を待機する
データ通信装置。
【請求項１５】
データの消失が検知された場合に送信側から前記データの再送を行うプロトコルを用いたデータ通信を行うためのデータ通信装置に実行させる通信プログラムであって、
送信装置とネットワークを介して送受信し、受信においては一連のデータを前記データ毎に受信し、受信したデータを処理するデータ処理ステップと、
前記送信装置とのデータ通信のセッション状態を管理し、前記セッション状態を情報記憶部に書き込む制御処理ステップと、
前記一連のデータの末尾の終端データが受信されたことを検出するデータ終端検出ステップと、
前記終端データの受信が検知されたとき、前記一連のデータの受信がすべて完了しているか否かを判定するデータ受信完了判定ステップと、
を備え、
前記データ処理ステップは、前記情報記憶部に記憶された前記セッション状態に応じて、前記送信装置からのデータを処理し、
前記制御処理ステップは、前記データ受信完了判定ステップにより前記一連のデータの受信がすべて完了していると判定されたとき、前記セッション状態を終了状態に遷移させ、完了していないと判定されたとき、完了したと判定されるまで、前記セッション状態の遷移を待機する、通信プログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【公開番号】特開２０１２−１８２５５１（Ｐ２０１２−１８２５５１Ａ）
【公開日】平成２４年９月２０日（２０１２．９．２０）
【国際特許分類】
【出願番号】特願２０１１−４２６０５（Ｐ２０１１−４２６０５）
【出願日】平成２３年２月２８日（２０１１．２．２８）
【出願人】（０００００３０７８）株式会社東芝 (54,554)
【Ｆターム（参考）】
【公開日】平成２４年９月２０日（２０１２．９．２０）
【国際特許分類】
【出願日】平成２３年２月２８日（２０１１．２．２８）
【出願人】（０００００３０７８）株式会社東芝 (54,554)
【Ｆターム（参考）】
[ Back to top ]