(57)【要約】【課題】バッファサイズを動的に制御可能な通信装置、方法、及びプログラムを提供する。【解決手段】一実施形態に係る通信装置は、通信処理部と、書き込み部と、読み出し部と、バッファ変更部と、を備える。通信処理部は、パケットの送信処理及び受信処理の少なくとも一方を実行する。書き込み部は、パケットに含まれるデータをバッファに書き込む。読み出し部は、バッファからデータを読み出す。バッファ変更部は、バッファへの書き込みの少なくとも一部を停止させ、バッファが空になった後にバッファを変更し、変更後のバッファへの書き込みを再開させる。【選択図】図１
2017163346.tif 000002
【特許請求の範囲】
【請求項１】
パケットの送信処理及び受信処理の少なくとも一方を実行する通信処理部と、
前記パケットに含まれるデータをバッファに書き込む書き込み部と、
前記バッファから前記データを読み出す読み出し部と、
前記バッファへの書き込みの少なくとも一部を停止させ、前記バッファが空になった後に前記バッファを変更し、変更後の前記バッファへの前記書き込みを再開させるバッファ変更部と、
を備える通信装置。
【請求項２】
前記通信処理部は、前記受信処理により受信パケットから受信データを抽出し、
前記書き込み部は、前記受信データを受信バッファに書き込み、
前記読み出し部は、前記受信バッファから前記受信データを読み出し、
前記バッファ変更部は、少なくとも一部の前記受信パケットの前記受信処理を停止させ、前記受信バッファが空になった後に前記受信バッファを変更し、停止させた前記受信処理を再開させる
請求項１に記載の通信装置。
【請求項３】
前記バッファ変更部は、全ての前記受信パケットの前記受信処理を停止させる
請求項２に記載の通信装置。
【請求項４】
前記バッファ変更部は、受信済みの前記受信パケットの最大シーケンス番号より大きいシーケンス番号を有する前記受信パケットの前記受信処理を停止させる
請求項２に記載の通信装置。
【請求項５】
前記バッファ変更部は、前記受信処理を停止させた後、前記受信バッファに書き込まれた前記受信データの少なくとも一部を、他の記憶領域にコピーする
請求項２乃至請求項４のいずれか１項に記載の通信装置。
【請求項６】
前記他の記憶領域は、変更後の前記受信バッファである
請求項５に記載の通信装置。
【請求項７】
前記通信処理部は、変更後の前記受信バッファのサイズが、通知済みのウィンドウサイズより小さい場合、前記受信バッファが解放されても、前記ウィンドウサイズを更新しない
請求項２乃至請求項６のいずれか１項に記載の通信装置。
【請求項８】
前記読み出し部と、前記バッファ変更部と、を備えるホストプロセッサと、
前記書き込み部と、前記通信処理部と、を備えるデータ転送部と、
を備え、
前記通信処理部は、前記ホストプロセッサから代行を依頼されたセッションの前記受信パケットに対して、前記受信処理を実行する
請求項２乃至請求項７のいずれか１項に記載の通信装置。
【請求項９】
前記データ転送部は、ＴＣＰ／ＩＰオフロードエンジンである
請求項８に記載の通信装置。
【請求項１０】
前記書き込み部は、送信データを送信バッファに書き込み、
前記読み出し部は、前記送信バッファから前記送信データを読み出し、
前記通信処理部は、前記送信処理により前記送信データから送信パケットを生成し、
前記バッファ変更部は、少なくとも一部の前記送信データの書き込みを停止させ、前記送信バッファが空になった後に前記送信バッファを変更し、停止させた前記送信データの書き込みを再開させる
請求項１に記載の通信装置。
【請求項１１】
前記書き込み部と、前記バッファ変更部と、を備えるホストプロセッサと、
前記読み出し部と、前記通信処理部と、を備えるデータ転送部と、
を備え、
前記通信処理部は、前記ホストプロセッサから代行を依頼されたセッションの前記送信データに対して、前記送信処理を実行する
請求項１０に記載の通信装置。
【請求項１２】
前記データ転送部は、ＴＣＰ／ＩＰオフロードエンジンである
請求項１１に記載の通信装置。
【請求項１３】
パケットの送信処理及び受信処理の少なくとも一方の実行中に、
前記パケットに含まれるデータのバッファへの書き込みの少なくとも一部を停止し、
前記バッファからの前記データの読み出しを継続し、
前記バッファが空になった後に前記バッファを変更し、
変更後の前記バッファへの前記書き込みを再開する
通信方法。
【請求項１４】
パケットの送信処理及び受信処理の少なくとも一方の実行中に、
前記パケットに含まれるデータのバッファへの書き込みの少なくとも一部を停止し、
前記バッファからの前記データの読み出しを継続し、
前記バッファが空になった後に前記バッファを変更し、
変更後の前記バッファへの前記書き込みを再開する
ことを通信装置に実行させる通信プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明の実施形態は、通信装置、方法、及びプログラムに関する。
【背景技術】
【０００２】
サーバ装置や端末装置などに搭載される通信装置は、一般的に、ＭＡＣ層及び物理層のプロトコルとして、イーサネット（登録商標）や802.11a/b/g/n/acなどを利用し、上位層のプロトコルとして、インターネット等で広く使われているＴＣＰ／ＩＰやＵＤＰ／ＩＰなどを利用する。
【０００３】
イーサネットは、現在１Ｇｂｐｓが主流であり、データセンター等では１０Ｇｂｐｓや４０Ｇｂｐｓのイーサネットが使われ始めている。また、次世代の１００Ｇｂｐｓイーサネットの仕様策定も完了している。IEEE 802.11においても、数Ｇｂｐｓの利用が、今後は普及していくと思われる。
【０００４】
このような高速ネットワークの普及に伴い、ＣＰＵ（Central Processing Unit）の処理性能やメモリ帯域等の、通信処理に必要な計算機リソースが増大している。そして、計算機リソースの増大は、コストや消費電力等の増大を招いている。
【０００５】
従来、ホストプロセッサの処理負荷やシステムメモリの帯域を低減するため、ＴＣＰ／ＩＰオフロードエンジン（以下、「ＴＯＥ」という）などの専用ハードウェアが用いられてきた。ＴＯＥは、ホストプロセッサの代わりに、ＴＣＰ／ＩＰのプロトコル処理を行う、専用プロセッサや専用回路を備えた装置である。ＴＯＥを用いることにより、ホストプロセッサからＴＣＰ／ＩＰのプロトコル処理をオフロードし、従来のソフトウェアによるプロトコル処理よりも高速に、プロトコル処理を行うことが可能となる。
【０００６】
ところで、プロトコル処理では、送受信パケットから取り出された送受信データを一時的に保持するための送受信バッファを、システムメモリ等の記憶領域に確保する必要がある。従来のＴＯＥでは、大きなサイズの送受信バッファが、セッション毎に固定的に確保されていた。これにより、ＴＯＥは、効率的に送受信処理を行うことが可能であった。しかしながら、この方法では、ＴＯＥが送受信処理を行っていない間も送受信バッファが確保されるため、メモリの使用効率が低いという問題があった。
【０００７】
メモリの使用効率を高めるために、ＴＣＰ／ＩＰのコネクション確立時に送受信バッファを確保するＴＯＥも提案されている。しかしながら、このＴＯＥでは、バッファサイズの動的な制御ができないため、バッファサイズを動的に制御可能なソフトウェアによるプロトコル処理に比べて、依然としてメモリの使用効率が低かった。
【先行技術文献】
【特許文献】
【０００８】
【特許文献１】特開２００５−３１６６２９号公報
【発明の概要】
【発明が解決しようとする課題】
【０００９】
バッファサイズを動的に制御可能な通信装置、方法、及びプログラムを提供する。
【課題を解決するための手段】
【００１０】
一実施形態に係る通信装置は、通信処理部と、書き込み部と、読み出し部と、バッファ変更部と、を備える。通信処理部は、パケットの送信処理及び受信処理の少なくとも一方を実行する。書き込み部は、パケットに含まれるデータをバッファに書き込む。読み出し部は、バッファからデータを読み出す。バッファ変更部は、バッファへの書き込みの少なくとも一部を停止させ、バッファが空になった後にバッファを変更し、変更後のバッファへの書き込みを再開させる。
【図面の簡単な説明】
【００１１】
【図１】第１実施形態に係る通信装置の一例を示す図。
【図２】通信装置の通常の受信動作の一例を示すフローチャート。
【図３】リングバッファの一例を示す図。
【図４】第１実施形態に係る受信バッファの変更動作の一例を示すフローチャート。
【図５】第１実施形態における受信状態の遷移を示す状態遷移図。
【図６】２つの使用中領域の間に空き領域が生じた受信バッファの一例を示す図。
【図７】シーケンス番号により管理されたバッファ情報の一例を示す図。
【図８】第２実施形態に係る受信バッファの変更動作の一例を示すフローチャート。
【図９】第２実施形態における受信状態の遷移を示す状態遷移図。
【図１０】第３実施形態に係る受信バッファの変更動作の一例を示すフローチャート。
【図１１】第４実施形態に係る受信バッファの変更動作の一例を示すフローチャート。
【図１２】第４実施形態における受信状態の遷移を示す状態遷移図。
【図１３】第４実施形態に係るパケットの送受信の一例を示すシーケンス図。
【図１４】第４実施形態に係るパケットの送受信の一例を示すシーケンス図。
【図１５】第５実施形態に係る通信装置の一例を示す図。
【図１６】第５実施形態に係る通常の送信動作の一例を示すフローチャートである。
【図１７】第５実施形態に係る送信バッファの変更動作の一例を示すフローチャート。
【発明を実施するための形態】
【００１２】
以下、本発明の実施形態について図面を参照して説明する。
【００１３】
（第１実施形態）
第１実施形態に係る通信装置について、図１〜図５を参照して説明する。本実施形態に係る通信装置は、ネットワークを介して接続された外部装置（送信側の他の通信装置）からパケットを受信し、受信したパケットに対してプロトコル処理を実行し、プロトコル処理により得られたデータを受信バッファに格納し、受信バッファに格納されたデータを利用してアプリケーションを実行する。また、本実施形態に係る通信装置は、受信バッファのサイズを、受信処理中に動的に制御することができる。
【００１４】
上記のネットワークには、イーサネットや無線ＬＡＮなどの、任意の有線通信ネットワーク及び無線通信ネットワークが含まれる。以下では、通信装置が受信したパケットを受信パケット、受信パケットに対してプロトコル処理を実行することにより得られたデータを受信データという。なお、通信装置は、パケットの代わりにフレームを受信してもよい。
【００１５】
本実施形態に係る通信装置は、例えば、ＰＣ、サーバ装置、専用ＬＳＩ、ＦＰＧＡ（Field Programmable Gate Array）、又はＡＳＩＣ（Application Specific Integrated Circuit）により構成されるが、これに限られない。
【００１６】
図１は、本実施形態に係る通信装置の一例を示す図である。図１の通信装置は、記憶装置１と、ホストプロセッサ２と、データ転送部３と、を備える。
【００１７】
記憶装置１は、例えば、ＳＲＡＭ（Static Random Access Memory）、ＳＤＲＡＭ（Synchronous Dynamic Random Access Memory）、ＳＳＤ（Solid State Drive）、ＨＤＤ（Hard Disk Drive）、又はＳＤカードであるが、これに限られない。記憶装置１は、受信バッファ領域１１と、セッション情報領域１２と、を備える。
【００１８】
受信バッファ領域１１は、各セッションの受信バッファが設けられる記憶領域である。各セッションの受信バッファには、各セッションにおいて受信された受信データが一時的に記憶される。図１の例では、受信バッファ領域１１には、セッション１〜セッションＮの受信バッファが設けられている。
【００１９】
セッション情報領域１２は、各セッションのセッション情報を記憶する記憶領域である。セッション情報は、セッションを管理するための情報であり、プロトコル処理（送信パケットのヘッダの生成や受信パケットのヘッダの解析など）を実行するために、データ転送部３により利用される。
【００２０】
例えば、データ転送部３がＴＣＰ／ＩＰのプロトコル処理を実行する場合、セッション情報には、宛先ＩＰアドレス、発信元ＩＰアドレス、宛先ポート番号、発信元ポート番号、シーケンス番号、及びＡＣＫ番号などが含まれる。また、セッション情報には、バッファ情報が含まれる。バッファ情報は、バッファを管理するための情報であり、バッファの位置（アドレス）、サイズ、使用中領域、及び空き領域などを含む。本実施形態において、バッファ情報には、受信バッファのバッファ情報が含まれる。
【００２１】
なお、図１の例では、通信装置は、１つの記憶装置１を備えるが、複数の記憶装置を備えてもよい。この場合、受信バッファ領域１１及びセッション情報領域１２は、それぞれ異なる記憶装置に設けられてもよい。また、本実施形態において、記憶装置１は、各セッションのバッファ情報を記憶するための記憶領域を、セッション情報領域１２とは別に備えてもよい。
【００２２】
ホストプロセッサ２は、例えば、ＣＰＵであり、通信装置全体の制御を行う。ホストプロセッサ２は、アプリケーション部２１と、データ転送部制御部２２と、受信データ読み出し部２３と、バッファ変更部２４と、を備える。これらの機能は、ホストプロセッサ２が、対応するソフトウェアを実行することにより実現される。
【００２３】
アプリケーション部２１は、ホストプロセッサ２が所定のアプリケーションを実行することにより実現される。アプリケーションは、外部装置からデータを取得するものであれば、任意である。外部装置は、例えば、ファイルサーバ又はキャッシュプロキシであるが、これに限られない。アプリケーション部２１は、外部装置にデータを要求し、要求に応じて得られた受信データを利用して、所定の処理を実行する。
【００２４】
データ転送部制御部２２（以下、「制御部２２」という）は、通信コネクションの確立及び切断や、プロトコル処理を含む受信処理を実行する。また、制御部２２は、アプリケーション部２１が要求したデータの受信処理の一部又は全部について、データ転送部３に代行を依頼する。制御部２２は、データ転送制御部３に受信処理の代行を依頼したセッションについては受信処理を行わない。
【００２５】
また、制御部２２は、バッファ情報を含むセッション情報をセッション毎に生成し、セッション情報領域１２に格納する。これにより、各セッションに対して受信バッファが確保される。制御部２２により確保される受信バッファのサイズは、固定長であってもよいし、アプリケーション部２１により指定されてもよい。図１の制御部２２は、受信データ読み出し部２３を備える。
【００２６】
受信データ読み出し部２３（以下、「読み出し部２３」という）は、受信バッファに書き込まれた受信データを読み出し、アプリケーション部２１に渡す。アプリケーション部２１は、読み出し部２３から受け取った受信データを利用して、所定の処理を実行する。
【００２７】
なお、図１の例では、読み出し部２３は、制御部２２に設けられている。これは、読み出し部２３の機能が、制御部２２の機能を実現するソフトウェアの機能の一部であることを想定しているためである。しかしながら、本実施形態において、読み出し部２３は、制御部２２とは独立して設けられてもよい。すなわち、制御部２２の機能と、読み出し部２３の機能と、がそれぞれ異なるソフトウェアにより実現されてもよい。
【００２８】
バッファ変更部２４（以下、「変更部２４」という）は、アプリケーション部２１からの受信バッファの変更指示に従って、バッファ情報を更新し、受信バッファのサイズを変更する。変更部２４は、受信バッファを変更する際、受信バッファの状態に応じて、データ転送部３を制御する。データ転送部３の制御方法について、詳しくは後述する。
【００２９】
なお、アプリケーション部２１は、ＯＳ（Operating System）のメモリ管理機構と連携し、記憶装置１の使用状態に応じて受信バッファの変更を指示してもよいし、ネットワークの通信帯域の状況に応じて受信バッファの変更を指示してもよい。また、バッファ変更指示は、ホストプロセッサ２が実行する専用のアプリケーションにより行われてもよい。
【００３０】
データ転送部３（以下、「転送部３」という）は、制御部２２から受信処理を依頼されたセッション（コネクション）について、ホストプロセッサ１に代わって、受信パケットに対するプロトコル処理を実行する。具体的には、転送部３は、受信パケットのヘッダを解析し、受信パケットに格納された受信データを抽出し、抽出した受信データを所定の受信バッファに書き込む。
【００３１】
転送部３は、専用のハードウェアにより構成されてもよいし、汎用のプロセッサがソフトウェアを実行することにより構成されてもよい。ただし、処理効率を向上させるために、転送部３は、ＴＯＥなどの専用のハードウェアにより構成されるのが好ましい。転送部３は、通信処理部３１と、セッション情報アクセス部３２と、受信データ書き込み部３３と、を備える。
【００３２】
通信処理部３１は、制御部２２が生成したセッション情報を利用して外部装置と通信し、外部装置から受信パケットを受信し、受信パケットに対して所定のプロトコル処理を実行する。通信処理部３１は、ＴＣＰ／ＩＰのプロトコル処理を実行してもよいし、ＵＤＰ／ＩＰのプロトコル処理を実行してもよい。また、通信処理部３１は、プロトコル処理と共に、イーサネット処理や無線処理などを実行してもよい。
【００３３】
セッション情報アクセス部３２（以下、「アクセス部３２」という）は、転送部３がセッション情報領域１２にアクセスするための処理部である。通信処理部３１及び受信データ書き込み部３３は、アクセス部３２を介して、セッション情報の取得及び更新をする。転送部３がセッション情報領域１２から直接的にセッション情報にアクセス可能な場合には、転送部３はアクセス部３２を備えなくてもよい。
【００３４】
受信データ書き込み部３３（以下、「書き込み部３３」という）は、バッファ情報を利用して、通信処理部３１が抽出した受信データを、制御部２２により確保された所定の受信バッファに書き込む。書き込み部３３は、バッファ情報に、アクセス部３２を介してアクセスする。
【００３５】
次に、本実施形態に係る通信装置の動作について説明する。以下では、通信装置の通常の受信動作と、受信バッファの変更動作と、についてそれぞれ説明する。
【００３６】
図２は、通信装置の通常の受信動作の一例を示すフローチャートである。以下では、受信パケットに対してＴＣＰ／ＩＰのプロトコル処理が実行される場合を例に説明する。ＴＣＰ／ＩＰの場合は、各セッションは、宛先ＩＰアドレス/発信元ＩＰアドレス、宛先ポート番号/発信元ポート番号の４つの情報で管理される。
【００３７】
まず、アプリケーション部２１は、外部装置のＩＰアドレスやポート番号などの、データの受信に必要な情報を制御部２２に通知し、制御部２２にデータの受信を指示する（ステップＳ１）。
【００３８】
次に、制御部２２は、アプリケーション部２１からの指示に従って、外部装置との間のコネクションを確立する（ステップＳ２）。
【００３９】
コネクションの確立が完了すると、制御部２２は、確立したコネクションのセッション情報を生成し、生成したセッション情報をセッション情報領域１２に格納する。また、制御部２２は、確立したコネクションに対応するセッションにおける受信処理の代行を、転送部３に依頼する（ステップＳ３）。以下、制御部２２が転送部３に受信処理の代行を依頼したセッションを、代行セッションという。
【００４０】
この際、制御部２２は、代行セッションの受信データを一時的に格納する受信バッファを、受信バッファ領域１１上に確保する。確保された受信バッファのバッファ情報は、代行セッションのセッション情報に含まれる。制御部２２と転送部３との間の受信データの受け渡しは、この受信バッファを介して行われる。なお、受信データを受け渡すための受信バッファの管理方法について、詳しくは後述する。
【００４１】
代行を依頼された通信処理部３１は、代行セッションの受信処理の代行を開始し、外部装置から送信されたパケットを、ネットワークを介して順次受信する（ステップＳ４）。
【００４２】
そして、通信処理部３１は、受信パケットに対して、受信処理を実行する。具体的には、通信処理部３１は、受信パケットのヘッダを解析し、送信元のＩＰアドレスとポート番号を確認し、受信パケットが代行セッションのパケットであるか判定する（ステップＳ５）。
【００４３】
受信パケットが代行セッションのパケットでない場合（ステップＳ５のＮＯ）、通信処理部３１は、受信パケットを制御部２２に渡す（ステップＳ６）。
【００４４】
受信パケットを受け取った制御部２２は、受け取った受信パケットに対して、プロトコル処理を含む受信処理を実行する（ステップＳ７）。
【００４５】
一方、受信パケットが代行セッションのパケットである場合（ステップＳ５のＹＥＳ）、通信処理部３１は、アクセス部３２を介して代行セッションのセッション情報を取得し、取得したセッション情報に基づいて、ＴＣＰ／ＩＰのプロトコル処理を実行する（ステップＳ８）。
【００４６】
具体的には、通信処理部３１は、バッファ情報や受信パケットのシーケンス番号を確認し、受信パケットが受信可能であるか判定する。受信不能な場合には、例えば、受信バッファに空き領域がない場合、受信パケットのシーケンス番号が不適切な場合、及び受信パケットのチェックサムが不適切である場合などが含まれる。
【００４７】
受信パケットが受信可能である場合、通信処理部３１は、受信パケットから受信データを抽出し、抽出した書き込み部３３に渡し、代行セッションのセッション情報（シーケンス番号など）を更新する。また、通信処理部３１は、データを受信したことを示すＡＣＫパケットを生成し、生成したＡＣＫパケットを、ネットワークを介して外部装置に送信する。
【００４８】
受信データを受け取った書き込み部３３は、受け取った受信データを、代行セッションの受信バッファに書き込む（ステップＳ９）。受信データの書き込みが完了すると、書き込み部３３は、代行セッションのバッファ情報を更新する。
【００４９】
また、書き込み部３３は、受信データが書き込まれたことを、割り込み信号などを利用して読み出し部２３に通知する。書き込み部３３は、受信データの書き込みが完了する度に通知してもよいし、受信バッファに書き込まれた受信データのサイズが、所定のサイズを超える度に通知してもよい。所定のサイズは、予め設定されていてもよいし、コネクション確立時に、制御部２２から通知されてもよい。
【００５０】
受信データが書き込まれたことを通知された読み出し部２３は、セッション情報領域１２から代行セッションのバッファ情報を読み出し、読み出したバッファ情報に基づいて、代行セッションの受信バッファから受信データを読み出し、読み出した受信データをアプリケーション部２１に渡す（ステップＳ１０）。読み出し部２３は、受信データを読み出した後、代行セッションの受信バッファを解放し、代行セッションのバッファ情報を更新する。
【００５１】
その後、制御部２２は、代行セッションの現在のウィンドウサイズ（受信バッファの空き領域のサイズ）を通知するＡＣＫを生成し、ネットワークを介して外部装置に送信する。このＡＣＫの送信は、通信処理部３１が行ってもよい。この場合、読み出し部２３が、バッファ情報の更新を、通信処理部３１に通知すればよい。
【００５２】
以上のような受信動作により、転送部３は、ホストプロセッサ１の代わりに、代行セッションの受信処理を実行することができる。また、同一のコネクションでは同一の受信バッファを利用して受信データの受け渡しが行われるため、転送部３は、ホストプロセッサ１に、受信データを効率的に渡すことができる。
【００５３】
ここで、受信バッファの管理方法について説明する。以下では、受信バッファがリングバッファである場合を例に説明するが、受信バッファはリングバッファに限られない。
【００５４】
図３は、リングバッファの一例を示す図である。図３のリングバッファ（受信バッファ）において、斜線部は、受信データが書き込まれた領域（以下、「使用中領域」という）であり、他の部分は、受信データが書き込まれていない領域（以下、「空き領域」という）である。リングバッファを利用する場合、バッファ情報には、読み出し位置及び書込み位置、リングバッファのアドレスとシーケンス番号の対応関係が含まれる。
【００５５】
書き込み位置は、書き込み部３３が新たな受信データの書き込みを開始する、受信バッファ上の位置である。書き込み位置は、例えば、ＴＣＰ／ＩＰのシーケンス番号や、受信バッファ上のアドレスとして管理される。データ転送部３は、リングバッファのアドレスとシーケンス番号の対応関係（例えば、読み出し位置のシーケンス番号とリングバッファのアドレス）をバッファ情報に持ち、書き込み位置や読み出し位置がリングバッファを巡回する際に対応関係を更新する事で、受信パケットのシーケンス番号から該当するアドレスを算出する事が可能である。書き込み部３３は、受信データを書き込む際、現在のバッファ情報に含まれる書き込み位置から、受信データの書き込みを開始する。そして、書き込み部３３は、書き込み完了後、バッファ情報に含まれる書き込み位置を更新する。図３の例では、書き込み位置は、矢印の方向に更新される。書き込み完了後の使用中領域は、元の書き込み位置から、更新後の書き込み位置までの連続領域となる。
【００５６】
読み出し位置は、読み出し部２３が受信データの読み出しを開始する、受信バッファ上の位置である。読み出し位置は、例えば、ＴＣＰ／ＩＰのシーケンス番号や、受信バッファ上のアドレスとして管理される。読み出し部２３は、受信データを読み出す際、現在のバッファ情報に含まれる読み出し位置から書き込み位置までの受信データを読み出す。そして、読み出し部２３は、読み出し完了後、バッファ情報に含まれる読み出し位置を更新する。図３の例では、読み出し位置は、矢印の方向に更新される。読み出し部２３が読み出し位置を更新すると、読み出し位置と書き込み位置とが一致し、使用中領域が解放される。
【００５７】
以上のようにバッファ情報を更新することにより、ホストプロセッサ１と転送部３との間で受信データを受け渡しすることができる。
【００５８】
図４は、本実施形態に係る通信装置の受信バッファの変更動作の一例を示すフローチャートである。受信バッファの変更動作は、通信処理部３１による受信処理の実行中に行われる。
【００５９】
まず、アプリケーション部２１は、代行セッションの中から、受信バッファを変更するセッションを指定して、バッファ変更部２４に受信バッファの変更を指示する。この際、アプリケーション部２１は、バッファ変更部２４に、変更後の新たな受信バッファのバッファ情報を通知する（ステップＳ１１）。以下、受信バッファを変更される代行セッションを対象セッションという。
【００６０】
アプリケーション部２１は、受信バッファ領域１１に新たな受信バッファを確保し、確保した受信バッファのバッファ情報を通知してもよい。また、アプリケーション部２１は、新たな受信バッファを確保せずに、新たな受信バッファのサイズを通知してもよい。この場合、新たな受信バッファの確保は、バッファ変更部２４が行えばよい。
【００６１】
受信バッファの変更を指示されたバッファ変更部２４は、通信処理部３１による対象セッションの受信処理を停止させる（ステップＳ１２）。これにより、受信バッファへの新たな受信データの書き込みが停止する。バッファ変更部２４による転送部３の制御方法について、詳しくは後述する。
【００６２】
受信処理の停止後、受信バッファが空ではない場合（ステップＳ１３のＮＯ）、読み出し部２３は、対象セッションの受信バッファからの受信データの読み出しを継続する（ステップＳ１４）。読み出し部２３が読み出しを継続すると、受信バッファは最終的に空になる。
【００６３】
受信バッファが空になると（ステップＳ１３のＹＥＳ）、バッファ変更部２４は、アプリケーション部２１から通知されたバッファ情報に基づいて、対象セッションのバッファ情報を更新し、対象セッションの受信バッファを新たな受信バッファに変更する（ステップＳ１５）。
【００６４】
具体的には、バッファ変更部２４は、アプリケーション部２１が確保した新たな受信バッファのバッファ情報を通知されている場合、通知されたバッファ情報を、対象セッションのバッファ情報として、セッション情報領域１２に書き込めばよい。また、バッファ変更部２４は、新たな受信バッファのサイズを通知されている場合、通知されたサイズを有する新たな受信バッファを確保し、確保した受信バッファのバッファ情報を、対象セッションのバッファ情報として、セッション情報領域１２に書き込めばよい。
【００６５】
なお、バッファ変更部２４は、対象セッションの受信バッファの状態を監視することにより、受信バッファが空になったことを検知してもよいし、受信バッファが空になったことを読み出し部２３から通知されてもよい。
【００６６】
バッファ変更部２４は、対象セッションの受信バッファを変更した後、通信処理部３１による対象セッションの受信処理を再開させる（ステップＳ１６）。バッファ変更部２４による転送部３の制御方法について、詳しくは後述する。
【００６７】
受信処理の停止中に外部装置から送信されたパケットは破棄されるため、外部機器からは、パケットロスが発生したように見える。このため、通信処理部３１が受信処理を再開し、外部装置がパケットを再送すると、対象セッションの受信処理を復帰させることができる。
【００６８】
ここで、バッファ変更部２４による転送部３の制御方法について説明する。以下では、制御方法の一例として、バッファ変更部２４が、セッション情報を変更することにより、転送部３を制御する方法について説明する。
【００６９】
この制御方法を利用する場合、セッション情報には、セッションの状態を示す情報として、受信状態が含まれる。通信処理部３１は、この受信状態に従って、受信処理を実行する。
【００７０】
図５は、本実施形態における受信状態の遷移を示す状態遷移図である。図５の例では、受信状態は、通常状態と、一時停止と、の２種類の値を取り得る。通信処理部３１は、受信状態が通常状態の場合、受信処理を実行し、受信状態が一時停止の場合、受信処理を停止する。
【００７１】
バッファ変更部２４は、受信バッファの変更処理の開始時に、対象セッションの受信状態を通常状態から一時停止に変更することにより、通信処理部３１による受信処理を停止させることができる（ステップＳ１２）。また、バッファ変更部２４は、変更処理の終了時に、対象セッションの受信状態を一時停止から通常状態に変更することにより、通信処理部３１による受信処理を再開させることができる（ステップＳ１６）。
【００７２】
このように、バッファ変更部２４は、セッション情報を変更することにより、通信処理部３１を制御することができる。しかしながら、制御方法は、これに限られず、既存の任意の方法を採用することができる。
【００７３】
以上説明した通り、本実施形態に係る通信装置は、対象セッションの受信バッファを、対象セッションの受信処理中に変更することができる。すなわち、本実施形態に係る通信装置は、受信バッファのサイズを、受信処理中に動的に制御することができる。これにより、メモリ（記憶装置１の受信バッファ領域１１）の使用率やネットワークの帯域などに応じて受信バッファのサイズを制御することが可能となり、メモリの使用効率を向上させることができる。
【００７４】
また、本実施形態に係る通信装置は、固定長の受信バッファを確保するＴＯＥにより、転送部３を構成することができる。このようなＴＯＥにより転送部３を構成することにより、ホストプロセッサ１からプロトコル処理がオフロードされ、プロトコル処理が高速化され、かつ、メモリの使用効率が高い通信装置を実現することができる。
【００７５】
（第２実施形態）
第２実施形態に係る通信装置について、図６〜図９を参照して説明する。本実施形態に係る通信装置の構成は、第１実施形態と同様であるため、説明を省略する。また、以下では、受信バッファはリングバッファであるものとする。
【００７６】
ＴＣＰ／ＩＰのように、受信パケットの順序を保証するプロトコルでは、受信処理の途中で、２つの使用中領域の間に空き領域が生じることがある。図６は、２つの使用中領域の間に空き領域が生じた受信バッファの一例を示す図である。図６の受信バッファは、受信データ１が書き込まれた使用中領域と、受信データ２が書き込まれた使用中領域と、の間に空き領域２が形成されている。このような空き領域２は、受信データ２の受信処理中に生じ得る。
【００７７】
受信バッファの変更時に、空き領域２が生じた場合、受信途中の受信データ２を破棄することで、受信バッファの変更が可能である。しかしながら、この方法で受信バッファを変更すると、途中まで受信した受信データ２を再度受信する必要があるため、受信処理に無駄が生じる。また、ＴＣＰのＳＡＣＫ（Selective Acknowledgment）オプションを使用した場合、受信データ２のシーケンス番号が外部装置に通知されてしまうため、受信バッファの変更後に、受信データ２が送信されなくなってしまう。
【００７８】
そこで、本実施形態では、受信途中の受信データを破棄することなく受信バッファを変更できる、受信バッファの変更方法について説明する。本実施形態において、バッファ情報には、読み出し位置と、書き込み位置と、空き領域情報と、使用中領域情報と、が含まれる。
【００７９】
空き領域情報は、受信バッファにおける、書き込み位置以降の空き領域の位置を示す情報である。空き領域情報には、空き領域の始点及び終点の位置が含まれる。空き領域の始点は、書き込み位置と一致し、空き領域の終点は、使用中領域の始点と一致する。空き領域情報は、例えば、ＴＣＰ／ＩＰのシーケンス番号や、受信バッファ上のアドレスとして管理される。
【００８０】
使用中領域情報は、受信バッファにおける、空き領域以降の使用中領域の位置を示す情報である。使用中領域情報には、使用中領域の始点及び終点の位置が含まれる。使用中領域の始点は、空き領域の終点と一致する。使用中領域情報は、例えば、ＴＣＰ／ＩＰのシーケンス番号や、受信バッファ上のアドレスとして管理される。
【００８１】
以下では、バッファ情報（読み出し位置、書き込み位置、空き領域情報、及び使用中領域情報）は、シーケンス番号として管理されるものとする。図７は、シーケンス番号により管理されたバッファ情報の一例を示す図である。図７の例では、読み出し位置はｎ、書き込み位置はｎ＋１０ＫＢ、空き領域２はｎ＋１０ＫＢ（始点）からｎ＋１８ＫＢ（終点）まで、使用中領域はｎ＋１８ＫＢ（始点）からｎ＋２７ＫＢ（終点）まで、である。ここで、図７の例では受信データ間の空き領域は空き領域２のみであるが、受信データ間に複数個の空き領域が存在しても良い。許容される最大空き領域数は、バッファ情報に含まれる空き領域情報、及び使用中領域情報に依存する。
【００８２】
図８は、本実施形態に係る通信装置の受信バッファの変更動作の一例を示すフローチャートである。図８のフローチャートは、図４のフローチャートのステップＳ１２の代わりに、ステップＳ１７，Ｓ１８を追加したものである。図８のステップＳ１１，Ｓ１３〜Ｓ１６は、図４と同様である。以下、ステップＳ１７，１８について説明する。
【００８３】
本実施形態において、受信バッファの変更を指示されたバッファ変更部２４は、通信処理部３１による対象セッションの受信処理の一部を停止させる。具体的には、バッファ変更部２４は、最大シーケンス番号（rcv_max）よりも大きなシーケンス番号を有するパケットの受信処理を停止させる（ステップＳ１７）。ここでいう最大シーケンス番号は、通信処理部３１が受信済みの受信データの、シーケンス番号の最大値のことであり、使用中領域の終点のシーケンス番号に相当する。図７の例では、最大シーケンス番号は、ｎ＋２７ＫＢである。
【００８４】
受信処理を一部停止されると、通信処理部３１は、最大シーケンス番号より大きいシーケンス番号を有するパケットの受信処理を停止し、最大シーケンス番号以下のシーケンス番号を有するパケットの受信処理を継続する。
【００８５】
具体的には、通信処理部３１は、受信パケットが対象セッションのパケットであるか判定し、対象セッションのパケットである場合、対象セッションのバッファ情報を参照して、受信パケットのシーケンス番号と、最大シーケンス番号と、を比較する。
【００８６】
通信処理部３１は、受信パケットのシーケンス番号が最大シーケンス番号より大きい場合、プロトコル処理を行わずに、受信パケットを破棄する。一方、通信処理部３１は、受信パケットのシーケンス番号が最大シーケンス番号以下の場合、受信パケットをプロトコル処理し、得られた受信データを書き込み部３３に渡す。そして、書き込み部３３が、受け取った受信データを受信バッファに書き込み、読み出し部２３に通知し、対象セッションのバッファ情報（書き込み位置、空き領域情報、及び使用中領域情報）を更新する。
【００８７】
これにより、転送部３は、最大シーケンス番号以下のシーケンス番号を有する受信パケットを受信処理し、得られた受信データを受信バッファに書き込むことができる（ステップＳ１８）。こうして書き込まれる受信データは、空き領域に対応する受信データである。したがって、この受信データの書き込みが完了すると、空き領域がなくなり、使用中領域は、読み出し位置から書き込み位置までの連続領域となる。
【００８８】
以降の処理は図４と同様である。すなわち、読み出し部２３が、対象セッションの受信バッファが空になるまで受信データを読み出し（ステップＳ１４）、バッファ変更部２４が対象セッションの受信バッファを変更し（ステップＳ１５）、バッファ変更部２４が通信処理部３１に受信処理を再開させる（ステップＳ１６）。
【００８９】
ここで、バッファ変更部２４による転送部３の制御方法について説明する。以下では、第１実施形態と同様に、バッファ変更部２４が、セッション情報（受信状態）を変更することにより、転送部３を制御する方法について説明する。
【００９０】
図９は、本実施形態における受信状態の遷移を示す状態遷移図である。図９の例では、受信状態は、通常状態と、一部停止と、の２種類の値を取り得る。通信処理部３１は、受信状態が通常状態の場合、受信処理を実行し、受信状態が一部停止の場合、シーケンス番号が最大シーケンス番号より大きい受信パケットの受信処理を停止する。
【００９１】
バッファ変更部２４は、受信バッファの変更処理の開始時に、対象セッションの受信状態を通常状態から一部停止に変更することにより、通信処理部３１による受信処理を一部停止させることができる（ステップＳ１７）。また、バッファ変更部２４は、変更処理の終了時に、対象セッションの受信状態を一部停止から通常状態に変更することにより、通信処理部３１による受信処理を再開させることができる（ステップＳ１６）。
【００９２】
このように、バッファ変更部２４は、セッション情報を変更することにより、通信処理部３１を制御することができる。しかしながら、制御方法は、これに限られず、既存の任意の方法を採用することができる。
【００９３】
以上説明した通り、本実施形態に係る通信装置は、受信途中の受信データを破棄することなく、対象セッションの受信バッファを変更することができる。これにより、本実施形態によれば、受信処理の無駄を抑制することができる。また、本実施形態によれば、ＴＣＰのＳＡＣＫオプションを利用することが可能となる。
【００９４】
なお、本実施形態に係るバッファ変更方法は、受信データのロストや受信データの到着順序の入れ替わりによって、受信バッファに空き領域が生じた場合にも適用可能である。
【００９５】
（第３実施形態）
第３実施形態に係る通信装置について、図１０を参照して説明する。本実施形態に係る通信装置の構成は、第１実施形態と同様であるため、説明を省略する。また、以下では、受信バッファはリングバッファであるものとする。
【００９６】
第２実施形態では、受信バッファに空き領域が生じた場合に、空き領域に対応する受信データを受信した後、受信バッファを変更する変更方法について説明した。これに対して、本実施形態では、受信バッファに空き領域が生じた場合に、空き領域以降の使用中領域に書き込まれた受信データをコピーした後、受信バッファを変更する変更方法について説明する。
【００９７】
図１０は、本実施形態に係る通信装置の受信バッファの変更動作の一例を示すフローチャートである。図１０のフローチャートは、図４のフローチャートのステップＳ１２とステップＳ１３との間に、ステップＳ１９を追加したものである。図１０のステップＳ１１〜Ｓ１６は、図４と同様である。以下、ステップＳ１９について説明する。
【００９８】
通信処理部３１による受信処理の停止後、バッファ変更部２４は、対象セッションの受信バッファに格納された受信データの少なくとも一部を、他の記憶領域にコピーする。この際、バッファ変更部２４は、空き領域以降の使用中領域に格納された受信データ（図６における受信データ２）をコピーしてもよいし、全ての受信データをコピーしてもよい。また、他の記憶領域は、アプリケーション部２１又はバッファ変更部２４が、変更後の受信バッファとして確保した記憶領域であってもよいし、受信バッファ領域１１とは別の記憶領域であってもよい。
【００９９】
以降の処理は図４と同様である。すなわち、読み出し部２３が、対象セッションの受信バッファが空になるまで受信データを読み出し（ステップＳ１４）、バッファ変更部２４が対象セッションの受信バッファを変更し（ステップＳ１５）、バッファ変更部２４が通信処理部３１に受信処理を再開させる（ステップＳ１６）。
【０１００】
他の記憶領域が受信バッファ領域１１とは別の記憶領域である場合、バッファ変更部２４は、通信処理部３１に受信処理を再開させる前に、他の記憶領域にコピーした受信データを、変更後の受信バッファにコピーすればよい。
【０１０１】
以上説明した通り、本実施形態に係る通信装置は、受信途中の受信データを破棄することなく、対象セッションの受信バッファを変更することができる。これにより、本実施形態によれば、受信処理の無駄を抑制することができる。また、本実施形態によれば、ＴＣＰのＳＡＣＫオプションを利用することが可能となる。
【０１０２】
なお、本実施形態に係るバッファ変更方法は、受信データのロストや受信データの到着順序の入れ替わりによって、受信バッファに空き領域が生じた場合にも適用可能である。
【０１０３】
（第４実施形態）
第４実施形態に係る通信装置について、図１１〜図１４を参照して説明する。ＴＣＰでは、受信側の通信装置のウィンドウサイズ（受信バッファの空き領域のサイズ）を、送信側の通信装置に通知し、送信側の通信装置が、通知されたウィンドウサイズ以上のデータを送らないようにフロー制御が行われる。このため、上述の各実施形態のように、受信処理中に受信バッファのサイズを縮小すると、変更後のウィンドウサイズが通知済みのウィンドウサイズより小さくなり、プロトコル違反となる。そこで、本実施形態では、変更後の受信バッファのサイズが、通知済みのウィンドウサイズより小さくなる場合を考慮した、受信バッファの変更方法について説明する。なお、本実施形態に係る通信装置の構成は、第１実施形態と同様であるため、説明を省略する。
【０１０４】
本実施形態では、セッション情報に含まれる受信状態は、通常状態と、一時停止と、未更新状態と、の３種類の値を取り得る。通信処理部３１は、受信状態が未更新状態の場合、受信バッファが解放されても、ウィンドウサイズを更新しない。
【０１０５】
図１１は、本実施形態に係る通信装置の受信バッファの変更動作の一例を示すフローチャートである。図１１のフローチャートは、図４のフローチャートのステップＳ１５とステップＳ１６との間に、ステップＳ２０〜Ｓ２５を追加したものである。図１１のステップＳ１１〜Ｓ１６は、図４と同様である。以下、ステップＳ２０〜Ｓ２５について説明する。
【０１０６】
バッファ変更部２４は、対象セッションの受信バッファを変更すると、変更後の受信バッファのサイズと、外部装置に通知済みのウィンドウサイズと、を比較する（ステップＳ２０）。
【０１０７】
変更後の受信バッファのサイズが通知済みのウィンドウサイズ以上である場合（ステップＳ２０のＹＥＳ）、バッファ変更部２４は、対象セッションの受信状態を、一時停止から通常状態に変更し、通信処理部３１に受信処理を再開させる（ステップＳ１６）。通信処理部３１は、受信状態が通常状態の場合、受信バッファを解放した際に、ウィンドウサイズを更新する。すなわち、通信処理部３１は、ＡＣＫにより、解放後の受信バッファの空き領域のサイズをウィンドウサイズとして外部装置に通知する。
【０１０８】
一方、変更後の受信バッファのサイズが通知済みのウィンドウサイズより小さい場合（ステップＳ２０のＮＯ）、バッファ変更部２４は、対象セッションの受信状態を、一時停止から未更新状態に変更し、通信処理部３１に受信処理を再開させる（ステップＳ２１）。通信処理部３１は、受信状態が未更新状態の場合、受信バッファを解放した際に、ウィンドウサイズを更新しない。すなわち、通信処理部３１は、ＡＣＫにより、解放後の受信バッファの空き領域のサイズをウィンドウサイズとして外部装置に通知しない。また、バッファ変更部２４は、対象セッションのセッション情報に含まれるＳ及びrcv_sizeの値を設定する。
【０１０９】
Ｓは、変更後の受信バッファのサイズと、通知済みのウィンドウサイズと、の差である。変更後の受信バッファのサイズをbuf_size、通知済みのウィンドウサイズをrcv_wnd、とすると、Ｓの値は、rcv_wnd−buf_sizeに設定される。Ｓは、受信状態が未更新状態に変更された際に一度だけ計算される。
【０１１０】
また、rcv_sizeは、未更新状態の間に通信装置が受信した受信データ全体のサイズである。ステップＳ２１では、rcv_sizeの値は、０に設定される。rcv_sizeは、通信処理部３１が未更新状態の間に受信データを受信する度に更新される。
【０１１１】
通信処理部３１は、受信処理を再開すると、外部装置から対象セッションのパケットを受信し（ステップＳ２２）、受信パケットに対してプロトコル処理を実行する（ステップＳ２３）。これにより、受信パケットに含まれる受信データが、受信バッファに書き込まれる。
【０１１２】
そして、通信処理部３１は、rcv_size及びrcv_wndを更新する。受信データのサイズをｎとすると、rcv_size＝rcv_size＋ｎ、rcv_wnd＝rcv_wnd−ｎとなる（ステップＳ２４）。通信処理部３１は、ＡＣＫにより、更新後のrcv_wndをウィンドウサイズとして通知する。
【０１１３】
通信処理部３１がrcv_size及びrcv_wndを更新した後、バッファ変更部２４は、rcv_sizeとＳとを比較する。
【０１１４】
rcv_sizeがＳ以上である場合（ステップＳ２５のＹＥＳ）、バッファ変更部２４は、対象セッションの受信状態を通常状態に変更し、通信処理部３１に通常の受信処理を再開させる（ステップＳ１６）。
【０１１５】
rcv_sizeがＳ以上である場合とは、buf_sizeが、外部装置に通知しているウィンドウサイズrcv_wnd以上である場合に相当する（buf_size≧rcv_wnd）。この場合、上述のプロトコル違反は解消される。
【０１１６】
一方、rcv_sizeがＳより小さい場合（ステップＳ２５のＮＯ）、バッファ変更部２４は、対象セッションの受信状態を未更新状態のまま維持する。そして、通信処理部３１は、次のパケットを受信する（ステップＳ２２）。
【０１１７】
rcv_sizeがＳより小さい場合とは、buf_sizeが、外部装置に通知しているウィンドウサイズrcv_wndより小さい場合に相当する（buf_size＜rcv_wnd）。この場合、上述のプロトコル違反は解消されていない。
【０１１８】
図１２は、本実施形態における受信状態の遷移を示す状態遷移図である。図１２の例では、受信状態は、通常状態と、一時停止と、未更新状態と、の３種類の値を取り得る。図１２に示すように、バッファ変更部２５は、受信バッファの変更処理が開始すると、受信状態を通常状態から一時停止に変更する。また、バッファ変更部２５は、受信バッファの変更処理が終了し、buf_sizeが通知済みのウィンドウサイズrcv_wnd以上である場合、受信状態を一時停止から通常状態に変更する。また、バッファ変更部２５は、受信バッファの変更処理が終了し、buf_sizeが通知済みのウィンドウサイズrcv_wndより小さい場合、受信状態を一時停止から未更新状態に変更する。また、バッファ変更部２５は、受信バッファの変更処理が終了し、受信状態を未更新状態に変更した後、buf_sizeが通知済みのウィンドウサイズrcv_wnd以上である場合（rcv_size≧Ｓである場合）、受信状態を未更新状態から通常状態に変更する。
【０１１９】
ここで、上述の受信バッファの変更動作の具体例について、図１３及び図１４を参照して説明する。図１３及び図１４は、対象セッションにおける、本実施形態に係る通信装置と外部装置との間のパケットの送受信の一例を示すシーケンス図である。図１３及び図１４におけるsnd_wndは、外部装置が認識している受信バッファのウィンドウサイズを示し、空きバッファは、受信バッファの実際の空き領域のサイズを示す。空きバッファは、実際のウィンドウサイズに相当する。
【０１２０】
図１３の例では、まず、外部装置及び通信装置が、ＳＹＮ及びＳＹＮ＿ＡＣＫをやりとりすることにより、ＴＣＰコネクションを確立する。このとき、セッション状態は、通常状態に設定される。
【０１２１】
ＴＣＰコネクションの確立時、通信装置は、１２８ＫＢの受信バッファを確保する。このとき、rcv_wndは、１２８ＫＢである（rcv_wnd＝１２８ＫＢ）。通信装置は、ＳＹＮ＿ＡＣＫにより、このrcv_wndを外部装置に通知する。これにより、外部装置は、受信バッファのウィンドウサイズを１２８ＫＢと認識する（snd_wnd＝１２８ＫＢ）。
【０１２２】
ＴＣＰコネクションの確立後、外部装置は、１０ＫＢのデータを送信する。このとき、外部装置は、snd_wndを、１１８ＫＢ（＝１２８ＫＢ−１０ＫＢ）に更新する（snd_wnd＝１１８ＫＢ）。通信装置がこのデータを受信し、受信バッファに書き込むと、空きバッファは１１８ＫＢ（＝１２８ＫＢ−１０ＫＢ）となる。通信装置は、rcv_wndを１１８ＫＢに更新し、更新したrcv_wndをＡＣＫにより外部装置に通知する（rcv_wnd＝１１８ＫＢ）。このとき、snd_wnd及びrcv_wndは一致する。
【０１２３】
次に、読み出し部２３が受信バッファから受信データを読み出し、受信バッファが解放されると、空きバッファは１２８ＫＢとなる。通信装置は、rcv_wndを１２８ＫＢに更新し、更新したrcv_wndをＡＣＫにより外部装置に通知する（rcv_wnd＝１２８ＫＢ）。rcv_wndを通知された外部装置は、snd_wndを１２８ＫＢに更新する（snd_wnd＝１２８ＫＢ）。
【０１２４】
続いて、図１４に示すように、外部装置は、１０ＫＢのデータを送信する。このとき、外部装置は、snd_wndを、１１８ＫＢ（＝１２８ＫＢ−１０ＫＢ）に更新する（snd_wnd＝１１８ＫＢ）。通信装置がこのデータを受信し、受信バッファに書き込むと、空きバッファは１１８ＫＢ（＝１２８ＫＢ−１０ＫＢ）となる。通信装置は、rcv_wndを１１８ＫＢに更新し、更新したrcv_wndをＡＣＫにより外部装置に通知する（rcv_wnd＝１１８ＫＢ）。このとき、snd_wnd及びrcv_wndは一致する。
【０１２５】
図１４の例では、その後、通信装置は、受信バッファを変更する（ステップＳ１１〜Ｓ１５）。buf_sizeは、６４ＫＢであり、通知済みウィンドウサイズ１１８ＫＢより小さい（ステップＳ２０のＮＯ）。したがって、バッファ変更部２５は、受信状態を未更新状態に変更し、Ｓ及びrcv_sizeの値を設定する（ステップＳ２１）。このとき、Ｓは５４ＫＢ（＝１１８ＫＢ−６４ＫＢ）、rcv_sizeは０ＫＢに設定される。
【０１２６】
次に、外部装置は、３０ＫＢのデータを送信する。このとき、外部装置は、snd_wndを、８８ＫＢ（＝１１８ＫＢ−３０ＫＢ）に更新する（snd_wnd＝８８ＫＢ）。通信装置がこのデータを受信し、受信バッファに書き込むと、空きバッファは３４ＫＢ（＝６４ＫＢ−３０ＫＢ）となる。しかしながら、この空きバッファをウィンドウサイズとして外部装置に通知すると、上述の通り、プロトコル違反となる。
【０１２７】
そこで、未更新状態の場合、通信装置は、通知済みのrcv_wndに基づいて、rcv_wndを更新し、更新したrcv_wndをウィンドウサイズとして外部装置に通知する（ステップＳ２４）。図１４の例では、通信装置は、rcv_wndを８８ＫＢ（＝１１８ＫＢ−３０ＫＢ）に更新し、更新したrcv_wndをＡＣＫにより外部装置に通知する（rcv_wnd＝８８ＫＢ）。これにより、snd_wnd及びrcv_wndは一致するため、プロトコル違反は生じない。また、通信装置は、rcv_sizeを、３０ＫＢ（＝０ＫＢ＋３０ＫＢ）に更新する。
【０１２８】
その後、通信装置は、rcv_sizeとＳとを比較する（ステップＳ２５）。このとき、Ｓ（＝５４ＫＢ）は、rcv_size（＝３０ＫＢ）より大きいため（ステップＳ２５のＮＯ）、通信装置は、受信状態が未更新状態のまま、受信処理を継続する。
【０１２９】
ここで、読み出し部２３が受信バッファから受信データを読み出し、受信バッファが解放されると、空きバッファは６４ＫＢとなる。しかしながら、受信状態が未更新状態であるため、通信装置は、ウィンドウサイズを更新しない。すなわち、通信装置は、新たな空きバッファを、ＡＣＫにより外部装置に通知しない。
【０１３０】
次に、外部装置は、３０ＫＢのデータを送信する。このとき、外部装置は、snd_wndを、５８ＫＢ（＝８８ＫＢ−３０ＫＢ）に更新する（snd_wnd＝５８ＫＢ）。通信装置がこのデータを受信し、受信バッファに書き込むと、空きバッファは３４ＫＢ（＝６４ＫＢ−３０ＫＢ）となる。しかしながら、この空きバッファをウィンドウサイズとして外部装置に通知すると、上述の通り、プロトコル違反となる。
【０１３１】
そこで、未更新状態の場合、通信装置は、通知済みのrcv_wndに基づいて、rcv_wndを更新し、更新したrcv_wndをウィンドウサイズとして外部装置に通知する（ステップＳ２４）。図１４の例では、通信装置は、rcv_wndを５８ＫＢ（＝８８ＫＢ−３０ＫＢ）に更新し、更新したrcv_wndをＡＣＫにより外部装置に通知する（rcv_wnd＝５８ＫＢ）。これにより、snd_wnd及びrcv_wndは一致するため、プロトコル違反は生じない。また、通信装置は、rcv_sizeを、６０ＫＢ（＝３０ＫＢ＋３０ＫＢ）に更新する。
【０１３２】
その後、通信装置は、rcv_sizeとＳとを比較する（ステップＳ２５）。このとき、Ｓ（＝５４ＫＢ）は、rcv_size（＝６０ＫＢ）以下であるため（ステップＳ２５のＹＥＳ）、通信装置は、受信状態を未更新状態から通常状態に変更し、受信処理を継続する（ステップＳ１６）。
【０１３３】
ここで、読み出し部２３が受信バッファから受信データを読み出し、受信バッファが解放されると、空きバッファは６４ＫＢとなる。このとき、受信状態は通常状態であるから、通信装置は、rcv_wndを、実際のウィンドウサイズである空きバッファ（＝６４ＫＢ）に更新し、更新したrcv_wndをＡＣＫにより外部装置に通知する（rcv_wnd＝６４ＫＢ）。rcv_wndを通知された外部装置は、snd_wndを６４ＫＢに更新する（snd_wnd＝６４ＫＢ）。以降、通信装置は、通常状態での受信処理を継続する。
【０１３４】
以上説明した通り、本実施形態に係る通信装置は、受信バッファのサイズが通知済みのウィンドウサイズより小さい場合、受信バッファを解放してもウィンドウサイズを更新しない。これにより、通信装置は、ＴＣＰのようなフロー制御を行う通信プロトコルを利用して外部装置と通信する場合であっても、プロトコル違反を生じさせることなく、受信処理を実行することができる。
【０１３５】
（第５実施形態）
第５実施形態に係る通信装置について、図１５〜図１７を参照して説明する。本実施形態に係る通信装置は、アプリケーションが生成したデータを送信バッファに格納し、送信バッファに格納されたデータに対してプロトコル処理を実行し、プロトコル処理により得られたパケットを、ネットワークを介して接続された外部装置（受信側の他の通信装置）に送信する。また、本実施形態に係る通信装置は、送信バッファのサイズを、送信処理中に動的に制御することができる。
【０１３６】
上記のネットワークには、イーサネットや無線ＬＡＮなどの、任意の有線通信ネットワーク及び無線通信ネットワークが含まれる。以下では、通信装置が送信したパケットを送信パケット、アプリケーションが用意したデータを送信データという。なお、通信装置は、パケットの代わりにフレームを送信してもよい。
【０１３７】
本実施形態に係る通信装置は、例えば、ＰＣ、サーバ装置、専用ＬＳＩ、ＦＰＧＡ（Field Programmable Gate Array）、又はＡＳＩＣ（Application Specific Integrated Circuit）により構成されるが、これに限られない。
【０１３８】
図１５は、本実施形態に係る通信装置の一例を示す図である。図１５の通信装置は、記憶装置１と、ホストプロセッサ２と、データ転送部３と、を備える。以下、第１実施形態との相違点を中心に説明する。
【０１３９】
記憶装置１は、受信バッファ領域１１の代わりに、送信バッファ領域１３を備える。
【０１４０】
送信バッファ領域１３は、各セッションの送信バッファが設けられる記憶領域である。各セッションの送信バッファには、各セッションにおいて送信される送信データが一時的に記憶される。図１５の例では、送信バッファ領域１３には、セッション１〜セッションＮの送信バッファが設けられている。
【０１４１】
本実施形態において、セッション情報領域１２は、受信バッファのバッファ情報を含むセッション情報を記憶する。
【０１４２】
ホストプロセッサ２は、受信データ読み出し部２３の代わりに、送信データ書き込み部２５を備える。
【０１４３】
送信データ書き込み部２５（以下、「書き込み部２５」という）は、アプリケーション部２１から受け取った送信データを送信バッファに書き込む。
【０１４４】
なお、本実施形態において、アプリケーション部２１は、ホストプロセッサ２が所定のアプリケーションを実行することにより実現される。アプリケーションは、外部装置にデータを送信するものであれば、任意である。
【０１４５】
転送部３は、書き込み部３３の代わりに、送信データ読み出し部３４を備える。
【０１４６】
送信データ読み出し部３４（以下、「読み出し部３４」という）は、バッファ情報を利用して、送信バッファに格納された送信データを読み出し、通信処理部３１に渡す。
【０１４７】
本実施形態において、通信処理部３１は、セッション情報を利用して外部装置と通信する。また、通信処理部３１は、読み出し部３４から受け取った送信データにプロトコル処理を実行して送信パケットを生成し、外部装置に送信パケットを送信する。
【０１４８】
次に、本実施形態に係る通信装置の動作について説明する。以下では、通信装置の通常の送信動作と、送信バッファの変更動作と、についてそれぞれ説明する。
【０１４９】
図１６は、通信装置の通常の送信動作の一例を示すフローチャートである。以下では、送信データに対してＴＣＰ／ＩＰのプロトコル処理が実行される場合を例に説明する。また、送信バッファはリングバッファであり、バッファ情報には送信バッファの読み出し位置及び書き込み位置が含まれるものとする。
【０１５０】
まず、アプリケーション部２１は、外部装置のＩＰアドレスやポート番号などの、データの送信に必要な情報を制御部２２に通知し、制御部２２にデータの送信を指示する（ステップＳ２６）。
【０１５１】
次に、制御部２２は、アプリケーション部２１からの指示に従って、外部装置との間のコネクションを確立する（ステップＳ２７）。
【０１５２】
コネクションの確立が完了すると、制御部２２は、確立したコネクションのセッション情報を生成し、生成したセッション情報をセッション情報領域１２に格納する。また、制御部２２は、確立したコネクションに対応するセッションにおける送信処理の代行を、転送部３に依頼する（ステップＳ２８）。以下、制御部２２が転送部３に送信処理の代行を依頼したセッションを、代行セッションという。
【０１５３】
この際、制御部２２は、代行セッションの送信データを一時的に格納する送信バッファを、送信バッファ領域１３上に確保する。確保された送信バッファのバッファ情報は、代行セッションのセッション情報に含まれる。制御部２２と転送部３との間の送信データの受け渡しは、この送信バッファを介して行われる。なお、送信バッファは、受信バッファと同様の方法で管理することができる。
【０１５４】
代行を依頼された通信処理部３１は、代行セッションの送信処理の代行を開始する（ステップＳ２９）。
【０１５５】
その後、書き込み部２５は、アプリケーション部２１から対象セッションの送信データを受け取ると、受け取った送信データを対象セッションの送信バッファに書き込む（ステップＳ３０）。送信データの書き込みが完了すると、書き込み部２５は、対象セッションのセッション情報に含まれる書き込み位置を更新する。
【０１５６】
代行セッションの送信バッファに、送信データを書き込み可能な空き領域がない場合、書き込み部２５は、送信データを書き込み可能な空き領域が生じるまで、送信データの書き込みを待機してもよい。書き込み部２５は、代行セッションのバッファ情報を監視して、送信データを書き込み可能な空き領域が生じたことを検知してもよい。また、外部装置からＡＣＫを受信した通信処理部３１が、送信データを書き込み可能な空き領域が生じたことを、書き込み部２５に通知してもよい。通信処理部３１が受信するＡＣＫについて、詳しくは後述する。
【０１５７】
送信バッファに送信データが書き込まれると、読み出し部３４は、送信バッファに書き込まれた送信データを読み出し、読み出した送信データと、代行セッションを識別する情報（例えば、セッション識別子）と、を通信処理部３１に渡す（ステップＳ３１）。
【０１５８】
読み出し部３４は、代行セッションのバッファ情報を監視して、送信データが書き込まれたことを検知してもよい。また、書き込み部２５が、送信データの書き込みが完了する度に、送信データが書き込まれたことを読み出し部３４に通知してもよい。また、書き込み部２５が、送信バッファに書き込まれた送信データのサイズが、所定のサイズを超える度に、送信データが書き込まれたことを読み出し部３４に通知してもよい。所定のサイズは、予め設定されていてもよいし、コネクション確立時に、制御部２２から通知されてもよい。
【０１５９】
送信データを受け取った通信処理部３１は、アクセス部３２を介して取得した代行セッションのセッション情報に基づいて、受け取った送信データに対するＴＣＰ／ＩＰのプロトコル処理を実行する（ステップＳ３２）。具体的には、送信データに対するＴＣＰヘッダの付加などを行う。これにより、送信データを含む送信パケットが生成される。
【０１６０】
送信パケットの生成後、通信処理部３１は、ネットワークを介して、外部装置に送信パケットを送信する（ステップＳ３３）。
【０１６１】
外部装置は、通信装置が送信した送信パケットを受信すると、送信パケットにプロトコル処理を実行し、送信データを抽出し、送信データを受信したことを示すＡＣＫを生成し、生成したＡＣＫを送信する。そして、通信処理部３１は、外部装置が送信したＡＣＫを受信する（ステップＳ３４）。
【０１６２】
通信処理部３１は、ＡＣＫを受信すると、代行セッションの読み出し位置を更新し、送信バッファを解放する（ステップＳ３５）。すなわち、本実施形態において、通信処理部３１は、送信データの再送が不要となったことを確認してから、送信バッファを解放する。
【０１６３】
以上の送信動作により、全ての送信データの送信が完了すると、制御部２２は、送信が完了したことをアプリケーション部２１に通知する。
【０１６４】
以上のような送信動作により、転送部３は、ホストプロセッサ１の代わりに、代行セッションの送信処理を実行することができる。また、同一のコネクションでは同一の送信バッファを利用して送信データの受け渡しが行われるため、ホストプロセッサ１は、転送部３に、送信データを効率的に渡すことができる。
【０１６５】
図１７は、本実施形態に係る通信装置の送信バッファの変更動作の一例を示すフローチャートである。送信バッファの変更動作は、通信処理部３１による送信処理の実行中に行われる。
【０１６６】
まず、アプリケーション部２１は、代行セッションの中から、送信バッファを変更するセッションを指定して、バッファ変更部２４に送信バッファの変更を指示する。この際、アプリケーション部２１は、バッファ変更部２４に、変更後の新たな送信バッファのバッファ情報を通知する（ステップＳ３６）。以下、送信バッファを変更される代行セッションを対象セッションという。
【０１６７】
アプリケーション部２１は、送信バッファ領域１１に新たな送信バッファを確保し、確保した送信バッファのバッファ情報を通知してもよい。また、アプリケーション部２１は、新たな送信バッファを確保せずに、新たな送信バッファのサイズを通知してもよい。この場合、新たな送信バッファの確保は、バッファ変更部２４が行えばよい。
【０１６８】
送信バッファの変更を指示されたバッファ変更部２４は、書き込み部２５による送信データの書き込みを停止させる（ステップＳ３７）。これにより、送信バッファへの新たな送信データの書き込みが停止する。バッファ変更部２４は、第１実施形態において説明した転送部３の制御方法と同様に、セッション情報を更新することにより書き込み部２５を制御することができる。
【０１６９】
具体的には、セッション情報に、セッションの状態を示す情報として、一時停止及び通常状態の２種類の値を取り得る送信状態を含める。書き込み部２５は、送信状態が一時停止の場合、送信データの書き込みを停止し、送信状態が通常状態の場合、送信データの書き込みを行う。バッファ変更部２４は、対象セッションの送信状態を更新することにより、書き込み部２５を制御することができる。
【０１７０】
送信データの書き込みの停止後、送信バッファが空ではない場合（ステップＳ３８のＮＯ）、読み出し部３４は、対象セッションの送信バッファからの送信データの読み出しを継続する（ステップＳ３９）。読み出し部３４が読み出しを継続すると、送信バッファは最終的に空になる。
【０１７１】
送信バッファが空になると（ステップＳ３８のＹＥＳ）、バッファ変更部２４は、アプリケーション部２１から通知されたバッファ情報に基づいて、対象セッションのバッファ情報を更新し、対象セッションの送信バッファを新たな送信バッファに変更する（ステップＳ４０）。
【０１７２】
具体的には、バッファ変更部２４は、アプリケーション部２１が確保した新たな送信バッファのバッファ情報を通知されている場合、通知されたバッファ情報を、対象セッションのバッファ情報として、セッション情報領域１２に書き込めばよい。また、バッファ変更部２４は、新たな送信バッファのサイズを通知されている場合、通知されたサイズを有する新たな送信バッファを確保し、確保した送信バッファのバッファ情報を、対象セッションのバッファ情報として、セッション情報領域１２に書き込めばよい。
【０１７３】
なお、バッファ変更部２４は、対象セッションの送信バッファの状態を監視することにより、送信バッファが空になったことを検知してもよいし、送信バッファが空になったことを読み出し部３４から通知されてもよい。
【０１７４】
バッファ変更部２４は、対象セッションの送信バッファを変更した後、書き込み部２５による送信データの書き込みを再開させる（ステップＳ４１）。
【０１７５】
以上説明した通り、本実施形態に係る通信装置は、対象セッションの送信バッファを、対象セッションの送信処理中に変更することができる。すなわち、本実施形態に係る通信装置は、送信バッファのサイズを、送信処理中に動的に制御することができる。これにより、メモリ（記憶装置１の送信バッファ領域１３）の使用率やネットワークの帯域などに応じて送信バッファのサイズを制御することが可能となり、メモリの使用効率を向上させることができる。
【０１７６】
また、本実施形態に係る通信装置は、固定長の送信バッファを確保するＴＯＥにより、転送部３を構成することができる。このようなＴＯＥにより転送部３を構成することにより、ホストプロセッサ１からプロトコル処理がオフロードされ、プロトコル処理が高速化され、かつ、メモリの使用効率が高い通信装置を実現することができる。
【０１７７】
なお、第１実施形態と第５実施形態とを組み合わせることも可能である。この場合、通信装置は、受信バッファ領域１１と、送信バッファ領域１３と、読み出し部２３と、書き込み部２５と、書き込み部３３と、読み出し部３４と、をそれぞれ備えればよい。これにより、送受信バッファのサイズを送受信処理中に動的に制御することができる通信装置を実現することができる。
【０１７８】
なお、本発明は上記各実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記各実施形態に開示されている複数の構成要素を適宜組み合わせることによって種々の発明を形成できる。また例えば、各実施形態に示される全構成要素からいくつかの構成要素を削除した構成も考えられる。さらに、異なる実施形態に記載した構成要素を適宜組み合わせてもよい。
【符号の説明】
【０１７９】
１：記憶装置、２：ホストプロセッサ、３：データ転送部、１１：受信バッファ領域、１２：セッション情報領域、１３：送信バッファ領域、２１：アプリケーション部、２２：データ転送部制御部、２３：受信データ読み出し部、２４：バッファ変更部、２５：送信データ書き込み部、３１：通信処理部、３２：セッション情報アクセス部、３３：受信データ書き込み部、３４：送信データ読み出し部
【図１】
2017163346.tif 000003
【図２】
2017163346.tif 000004
【図３】
2017163346.tif 000005
【図４】
2017163346.tif 000006
【図５】
2017163346.tif 000007
【図６】
2017163346.tif 000008
【図７】
2017163346.tif 000009
【図８】
2017163346.tif 000010
【図９】
2017163346.tif 000011
【図１０】
2017163346.tif 000012
【図１１】
2017163346.tif 000013
【図１２】
2017163346.tif 000014
【図１３】
2017163346.tif 000015
【図１４】
2017163346.tif 000016
【図１５】
2017163346.tif 000017
【図１６】
2017163346.tif 000018
【図１７】
2017163346.tif 000019