(57)【要約】【課題】通信パケットの送受信の状況に応じて、通信パケットをより効率的に送信することが可能な通信装置を提供する。【解決手段】通信装置は、複数の通信ヘッダを生成する第１の生成手段と、第１の生成手段により生成される複数の通信ヘッダのうち、送信データを分割して生成される複数のペイロード中の終端のペイロードに付加すべき通信ヘッダに、フラグ情報を設定すべきと判定する判定手段と、判定手段により判定された通信ヘッダにフラグ情報が設定されるよう、第１の生成手段を制御する制御手段と、第１の生成手段により生成された複数の通信ヘッダのそれぞれに、複数のペイロードのそれぞれを付加して複数の通信パケットを生成する第２の生成手段と、を備える。【選択図】  図３
2020043486.tif 000002
【特許請求の範囲】
【請求項１】
複数の通信ヘッダを生成する第１の生成手段と、
前記第１の生成手段により生成される前記複数の通信ヘッダのうち、送信データを分割して生成される複数のペイロード中の終端のペイロードに付加すべき通信ヘッダに、フラグ情報を設定すべきと判定する判定手段と、
前記判定手段により判定された通信ヘッダに前記フラグ情報が設定されるよう、前記第１の生成手段を制御する制御手段と、
前記第１の生成手段により生成された前記複数の通信ヘッダのそれぞれに、前記複数のペイロードのそれぞれを付加して複数の通信パケットを生成する第２の生成手段と、
を備えることを特徴とする通信装置。
【請求項２】
送信バッファをさらに備え、
前記判定手段は、前記送信データが、前記送信バッファの中の最後の送信データである場合に、前記フラグ情報を設定すべき通信ヘッダを判定する、
ことを特徴とする請求項１に記載の通信装置。
【請求項３】
通信パケットの送信先通信装置のウインドウサイズを、前記送信先通信装置から受信する受信手段をさらに備え、
前記判定手段は、前記受信手段により受信される前記ウインドウサイズに基づいて、前記送信先通信装置の受信バッファが次の通信パケットの送信により一杯になると予測される場合に、前記フラグ情報を設定すべき通信ヘッダを判定する、
ことを特徴とする請求項１から２のいずれか１項に記載の通信装置。
【請求項４】
前記第１の生成手段はレジスタを備え、
前記制御手段は、前記判定手段により判定された通信ヘッダに前記フラグ情報を設定させる編集情報を前記レジスタに設定することにより、前記第１の生成手段を制御する、
ことを特徴とする請求項１から３のいずれか１項に記載の通信装置。
【請求項５】
前記第１の生成手段により生成される前記複数の通信ヘッダを記憶するメモリをさらに備え、
前記第１の生成手段は、前記制御手段から通知される生成すべき通信パケットの数に基づいて、複製元の通信ヘッダを複製し、複製した通信ヘッダを編集することにより、前記複数の通信ヘッダを生成して、前記メモリに記憶する、
ことを特徴とする請求項１から４のいずれか１項に記載の通信装置。
【請求項６】
前記判定手段は、ＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ）のＴＣＢ（Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｂｌｏｃｋ）が保持するシーケンス番号を参照することにより、前記フラグ情報を設定すべき通信パケットを判定する、
ことを特徴とする請求項１から５のいずれか１項に記載の通信装置。
【請求項７】
通信パケットの送信先通信装置のウインドウサイズ、輻輳ウインドウサイズ、および前記第１の生成手段が処理可能なデータ量の上限値のいずれか１つ以上に基づいて、前記送信データのサイズを算出する算出手段をさらに備える、
ことを特徴とする請求項１から６のいずれか１項に記載の通信装置。
【請求項８】
前記通信ヘッダは、Ｅｔｈｅｒヘッダ、ＩＰｖ４ヘッダ、ＩＰｖ６ヘッダ、ＴＣＰヘッダ、またはＵＤＰヘッダである、
ことを特徴とする請求項１から７のいずれか１項に記載の通信装置。
【請求項９】
前記フラグ情報は、ＴＣＰヘッダのフラグビットの領域に設定されるＰＳＨ（Ｐｕｓｈ）フラグである、
ことを特徴とする請求項１から８のいずれか１項に記載の通信装置。
【請求項１０】
前記制御手段は、ＴＣＰの再送処理で再送される通信パケットに付加すべき通信ヘッダに前記フラグ情報を設定する、
ことを特徴とする請求項１から９のいずれか１項に記載の通信装置。
【請求項１１】
前記制御手段は、アプリケーション層から要求されるデータの転送サイズが、ＭＳＳ（Ｍａｘｉｍｕｍ  Ｓｅｇｍｅｎｔ  Ｓｉｚｅ）以下の場合、送信される通信パケットに付加すべき通信ヘッダに前記フラグ情報を設定する、
ことを特徴とする請求項１から１０のいずれか１項に記載の通信装置。
【請求項１２】
前記第１の生成手段は、ＴＣＰ  Ｓｅｇｍｅｎｔａｔｉｏｎ  Ｏｆｆｌｏａｄ（ＴＳＯ）により前記複数の通信ヘッダを生成する、
ことを特徴とする請求項１から１１のいずれか１項に記載の通信装置。
【請求項１３】
通信パケットを送信する通信装置の制御方法であって、
複数の通信ヘッダのうち、送信データを分割して生成される複数のペイロード中の終端のペイロードに付加すべき通信ヘッダに、フラグ情報を設定すべきと判定するステップと、
複数の通信ヘッダを生成するとともに、前記複数の通信ヘッダのうち、判定された通信ヘッダに前記フラグ情報を設定するステップと、
生成された前記複数の通信ヘッダのそれぞれに、前記複数のペイロードのそれぞれを付加して複数の通信パケットを生成するステップと、
を含むことを特徴とする通信装置の制御方法。
通信装置の制御方法。
【請求項１４】
コンピュータを、請求項１から１２のいずれか１項に記載の通信装置の各手段として機能させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、送信データに付加する通信ヘッダを生成可能な通信装置、通信装置の制御方法およびプログラムに関する。
【背景技術】
【０００２】
近年、いわゆるスマートデバイス等の多機能端末上では、ネットワーク経由で配信される高解像度動画（８Ｋ／４Ｋ）をリアルタイムで閲覧することができる。こうした高解像度動画を閲覧するニーズの増加に伴って、動画配信のためのネットワーク上のデータトラフィックが増大している。
一方、Ｅｔｈｅｒｎｅｔ（登録商標）による１０Ｇｂｐｓ通信、移動体通信の５Ｇ通信等、データトラフィックの増大に対応すべくネットワークの高速化が進展している。こうしたネットワークの高速化に伴って、各通信プロトコルで規定された処理である通信プロトコル処理の効率化が要請されている。こうした通信プロトコルにはＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ）／ＩＰ（Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）やＵＤＰ（Ｕｓｅｒ  Ｄａｔａｇｒａｍ  Ｐｒｏｔｏｃｏｌ）等がある。
【０００３】
通信プロトコル処理の効率化を実現するためには、通信パケットを生成する処理の効率化は欠かせないものとなるが、通信パケット生成を高速で処理しなければならない通信装置のＣＰＵへの負荷はそれだけ高まることになる。
このような通信プロトコル処理に伴うＣＰＵの負荷を低減させてパケット送信を高速化する技術の１つに、ＴＳＯ（ＴＣＰ  Ｓｅｇｍｅｎｔａｔｉｏｎ  Ｏｆｆｌｏａｄ）処理がある。
このＴＳＯ処理は、通信プロトコル処理（ＴＣＰセグメント処理）の一部を、ＣＰＵから例えばＮＩＣ（Ｎｅｔｗｏｒｋ  Ｉｎｔｅｒｆａｃｅ  Ｃａｒｄ）等のハードウエアへオフロードすることで、ＣＰＵへの負荷を低減するものである。
【０００４】
通信プロトコル処理は、国際標準化機構（ＩＳＯ）によって策定された、階層構造のＯＳＩ（Ｏｐｅｎ  Ｓｙｓｔｅｍ  Ｉｎｔｅｒｃｏｎｎｅｃｔｉｏｎ）参照モデルにおいて、７つの階層に分けて定義されている。上記のＴＣＰセグメント処理は、ＯＳＩ参照モデルで定義されるアプリケーション層で生成された送信データを複数のペイロードに分割し、データ通信を実行する下位レイヤで使用される複数のＴＣＰセグメント（通信パケット）に変換する処理である。
【０００５】
特許文献１は、上記のＴＣＰセグメント処理をハードウエアにオフロードして送信パケットを生成する通信制御装置を開示する。
具体的には、特許文献１の技術によれば、通信制御装置のペイロード分割部は、アプリケーション層で生成された転送可能長を超える送信データを転送可能長で分割してフレーム単位の送信ペイロードを生成する。通信制御装置の各ヘッダ生成部は、送信データが分割されている間に、分割された送信ペイロードに付与するＴＣＰヘッダ、ＩＰヘッダ等のヘッダを生成する。ヘッダ／ペイロード合成部は、生成されたヘッダと分割された送信ペイロードとをフレームとして合成して送信パケットを完成する。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２００６−８１０３２号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
ところで、上記のＴＣＰセグメント処理において、送信すべきペイロードに付加するＴＣＰヘッダは、ＴＣＰの各種制御用のフラグビットのフィールドを含む。それぞれのフラグビットを設定することにより、ＴＣＰのコネクション制御、順序制御、再送制御、ウィンドウ制御、フロー制御等を実行することができる。
しかしながら、このフラグビットの設定如何によっては、通信パケットの送信性能が低下してしまうおそれがあった。具体的には、例えば、送信側通信装置が、ＴＣＰヘッダのフラグビット中のＰＳＨ（Ｐｕｓｈ）フラグをオンに設定して通信パケットを送信したものとする。ＰＳＨフラグがオンに設定された通信パケットを受信した受信側通信装置では、ＴＣＰ規格に従い、通信パケット中のデータを、受信バッファでバッファリングせず即座に上位レイヤのアプリケーションに受け渡さなければならない。
【０００８】
すなわち、受信側通信装置は、１パケットごとに通信プロトコル処理を実行し、受信されたパケットのＴＣＰヘッダ中のＰＳＨフラグを検知する度に、受信バッファ内のデータを上位レイヤであるアプリケーション層へ転送しようとする。このため、受信側通信装置の通信パケット受信効率が低下することで、送信側通信装置のパケット送信効率も低下しかねない。しかしながら、ＴＣＰセグメント処理をハードウエアにオフロードする特許文献１のような技術では、ＰＳＨフラグ等のフラグビットを状況に応じてＴＣＰヘッダ等の通信ヘッダに適切に設定することができない。
【０００９】
本発明は、上述の課題に鑑みてなされたものであり、通信パケットの送受信の状況に応じて、通信パケットをより効率的に送信することが可能な通信装置、通信装置の制御方法およびプログラムを提供することを目的とする。
【課題を解決するための手段】
【００１０】
上記課題を解決するため、本発明に係る通信装置のある態様によれば、複数の通信ヘッダを生成する第１の生成手段と、前記第１の生成手段により生成される前記複数の通信ヘッダのうち、送信データを分割して生成される複数のペイロード中の終端のペイロードに付加すべき通信ヘッダに、フラグ情報を設定すべきと判定する判定手段と、前記判定手段により判定された通信ヘッダに前記フラグ情報が設定されるよう、前記第１の生成手段を制御する制御手段と、前記第１の生成手段により生成された前記複数の通信ヘッダのそれぞれに、前記複数のペイロードのそれぞれを付加して複数の通信パケットを生成する第２の生成手段と、を備える通信装置が提供される。
【発明の効果】
【００１１】
本発明によれば、通信パケットの送受信の状況に応じて、通信パケットをより効率的に送信することができる。
【図面の簡単な説明】
【００１２】
【図１】本実施形態に係る通信装置１のハードウエアおよび機能構成の一例を示すブロック図
【図２】通信装置１のパケット送信処理の処理手順の一例を示すフローチャート
【図３】実施形態１における図２の通信プロトコル処理（Ｓ４）の詳細処理手順の一例を示すフローチャート
【図４】ＴＣＰヘッダのヘッダレイアウトを説明する図
【図５】実施形態２における図２の通信プロトコル処理（Ｓ４）の詳細処理手順の一例を示すフローチャート
【図６】図５のＳ５１での判断における受信ウインドウサイズと送信データとの関係の一例を説明する図
【発明を実施するための形態】
【００１３】
以下、添付図面を参照して、本発明を実施するための実施形態について詳細に説明する。なお、以下に説明する実施形態は、本発明の実現手段としての一例であり、本発明が適用される装置の構成や各種条件によって適宜修正又は変更されるべきものであり、本発明は以下の実施形態に必ずしも限定されるものではない。また、本実施形態で説明されている特徴の組み合わせの全てが本発明の解決手段に必須のものとは限らない。なお、同一の構成については、同じ符号を付して説明する。
【００１４】
（実施形態１）
本実施形態においては、パケットを生成および送信可能な通信装置において、送信データに付加される通信ヘッダを生成する際に、通信ヘッダ中のフラグ情報を設定するか否かを判定する。
具体的には、本実施形態において、通信装置は、生成すべき複数の通信ヘッダのうち、送信データを分割して生成される複数のペイロード中の終端のペイロードに付加すべき通信ヘッダに、フラグ情報を設定すべきと判定する。そして、通信装置は、判定された通信ヘッダにフラグ情報が設定されるよう、複数の通信ヘッダの生成を制御し、生成された複数の通信ヘッダのそれぞれに、複数のペイロードのそれぞれを付加することで複数の通信パケットを生成する。一方、フラグ情報を設定すべきと判定されなかった他のペイロードに付加すべき通信ヘッダには、フラグ情報は設定されなくてよい。
【００１５】
これにより、送信側通信装置は、終端のペイロードを含む通信パケットが受信側通信装置に受信されるまで、受信側通信装置の受信バッファ内のデータをアプリケーション層へ転送させないよう、受信側通信装置内のデータ転送を制御することができる。従って、受信側通信装置での受信バッファからアプリケーション層へのデータ転送の頻度を低減することができ、パケットをより効率的に送信することで通信性能の低下が有効に防止される。
【００１６】
ここで、通信装置において、アプリケーションから転送される送信データから複数の通信パケットを生成する処理は、例えば、ＴＳＯ（ＴＣＰ  Ｓｅｇｍｅｎｔａｔｉｏｎ  Ｏｆｆｌｏａｄ）技術を使用してオフロード実行されてよい。
パケット生成の際に送信ペイロードに付加される通信ヘッダは、ＴＣＰヘッダ、ＩＰヘッダ（ＩＰｖ４ヘッダ、ＩＰｖ６ヘッダ）、およびＥｔｈｅｒ（Ｅｔｈｅｒｎｅｔ（登録商標））ヘッダを含んでよい。
また、通信ヘッダ中のフラグ情報は、通信プロトコルを制御するフラグビットであってよく、フラグ設定によって受信データをバッファリングせずに即座にアプリケーションに受け渡すことを示すＰＳＨ（Ｐｕｓｈ）フラグを含んでよい。フラグの設定とは、フラグビットをオンにする、すなわちフラグビットの値を「１」にすることをいう。
【００１７】
＜本実施形態のハードウエアおよび機能構成＞
図１は、本実施形態に係る通信装置のハードウエア構成および機能構成の一例を示す図である。
図１に示す通信装置１の各機能モジュールのうち、ソフトウエアにより実現される機能については、各機能モジュールの機能を提供するためのプログラムがＲＯＭ等のメモリに記憶され、ＲＡＭに読み出してＣＰＵが実行することにより実現される。ハードウエアにより実現される機能については、例えば、所定のコンパイラを用いることで、各機能モジュールの機能を実現するためのプログラムからＦＰＧＡ上に自動的に専用回路を生成すればよい。ＦＰＧＡとは、Ｆｉｅｌｄ  Ｐｒｏｇｒａｍｍａｂｌｅ  Ｇａｔｅ  Ａｒｒａｙの略である。また、ＦＰＧＡと同様にしてＧａｔｅ  Ａｒｒａｙ回路を形成し、ハードウエアとして実現するようにしてもよい。また、ＡＳＩＣ（Ａｐｐｌｉｃａｔｉｏｎ  Ｓｐｅｃｉｆｉｃ  Ｉｎｔｅｇｒａｔｅｄ  Ｃｉｒｃｕｉｔ）により実現するようにしてもよい。なお、図１に示した機能ブロックの構成は一例であり、複数の機能ブロックが１つの機能ブロックを構成するようにしてもよいし、いずれかの機能ブロックが複数の機能を行うブロックに分かれてもよい。
通信装置１は、サブシステム２、メインＣＰＵ３、およびメインメモリ４を備える。サブシステム２は、各種通信プロトコルで規定された処理である通信プロトコル処理を実行する。サブシステム２、メインＣＰＵ３、およびメインメモリ４は、システムバス５を介して相互に接続されている。
【００１８】
メインＣＰＵ３は、ＯＳＩ参照モデルで定義されるアプリケーション層でアプリケーションソフトウエアを実行するとともに、通信装置１全体の制御を実行する。具体的には、メインＣＰＵ３は、アプリケーションソフトウエアを実行する上で必要となるデータやプログラムなどをメインメモリ４の内部に記憶し、必要に応じてシステムバス５を介して読み出しや書き込みを行う。
メインメモリ４は、システムバス５を介して、通信装置１内の各機能ブロックが共有して利用可能なメモリであり、例えば主としてＤＲＡＭ（Ｄｙｎａｍｉｃ  Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）等の半導体メモリで構成されてよい。メインメモリ４内部の領域は、プログラムを格納する領域やアプリケーションソフトウエアが使用するアプリケーションバッファ領域などに分けられる。
【００１９】
サブシステム２は、サブＣＰＵ２１、ローカルメモリ２２、ＤＭＡ（Ｄｉｒｅｃｔ  Ｍｅｍｏｒｙ  Ａｃｃｅｓｓ）コントローラ２３、通信Ｉ／Ｆ２４、およびヘッダ処理部２５を備える。サブＣＰＵ２１、ローカルメモリ２２、ＤＭＡコントローラ２３、通信Ｉ／Ｆ２４およびヘッダ処理部２５は、ローカルバス２６を介して相互に接続されている。
【００２０】
サブシステム２は、通信装置１における通信プロトコル処理を実行するサブシステムであり、特に、サブシステム２は、ＴＣＰ／ＩＰプロトコル等の通信プロトコル処理に特化して外部機器とネットワークを介したデータ転送処理を実行する。
本実施形態において、サブシステム２は、通信プロトコル処理専用のハードウエア（ハードウエアアクセラレータ）を搭載して、通信プロトコル処理の一部をメインＣＰＵ３に代えて高速で実行してよい。
なお、ＴＣＰ／ＩＰプロトコルは説明を行うために示す一例であり、サブシステム２は、その他の通信プロトコルの通信プロトコル処理を実行することができる。以下、ＴＣＰ／ＩＰプロトコルは、別段の定義のない限り、ＵＤＰプロトコルを含むものとして説明する。
【００２１】
サブＣＰＵ２１は、サブシステム２による通信プロトコル処理全体の実行を制御する。具体的には、サブＣＰＵ２１は、ＩＰｖ４（ＩＰバージョン４）、ＩＰｖ６（ＩＰバージョン６）、ＵＤＰ、ＴＣＰ等の各通信プロトコル処理を実行する。サブＣＰＵ２１が実行する通信プロトコル処理は、送信シーケンス制御、輻輳制御、通信エラー制御等を含む。
なお、サブＣＰＵ２１は、１つのプロセッサとして構成してもよいし、複数のプロセッサによるマルチプロセッサ構成としてもよい。さらに、サブＣＰＵ２１は、プロセッサと一部の機能をアクセラレートするハードウエアアクセラレータとで構成してもよい。
【００２２】
ローカルメモリ２２は、サブシステム２のサブＣＰＵ２１が利用可能なメモリであり、例えば、主としてＳＲＡＭ（Ｓｔａｔｉｃ  Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）等の半導体メモリで構成されてよい。
また、ローカルメモリ２２へは、メインＣＰＵ３からもシステムバス５およびローカルバス２６を介してアクセス可能である。ローカルメモリ２２は、通信プロトコル処理を実行する上で必要となる送受信データを格納するネットワークバッファ２２１の領域を備える。ネットワークバッファ２２１は、アプリケーションソフトウエアにより準備され、メインメモリ４から転送された送信データを格納する送信バッファである。ローカルメモリ２２へは、必要に応じてサブシステム２の各機能モジュールが、ローカルバス２６を介して読み出しや書き込みを実行する。
【００２３】
ＤＭＡコントローラ２３は、サブＣＰＵ２１およびヘッダ処理部２５双方から直接制御可能であり、ローカルメモリ２２へのアクセスを提供し、サブＣＰＵ２１からの指示により、ＤＭＡ転送を実行する。
ＤＭＡコントローラ２３は、ディスクリプタに記述された内容に従ってソース側からディスティネーション側へデータ転送を実行する。このディスクリプタには、データ転送元となるソース側のメモリ等のアドレス情報、データ転送先となるディスティネーション側のメモリ等のアドレス情報、およびデータ転送の転送サイズ等の情報が記述される。
【００２４】
具体的には、サブＣＰＵ２１等が、ローカルメモリ２２にディスクリプタを書き込み、その後ＤＭＡコントローラ２３に対してＤＭＡ転送開始指示を通知する。このＤＭＡ転送開始指示を通知するには、例えばディスクリプタを保存しているローカルメモリ２２のアドレス情報を設定すればよい。
このＤＭＡ転送開始指示の通知を受けたＤＭＡコントローラ２３は、メインメモリ４とローカルメモリ２２との間、内部メモリ２５３とローカルメモリ２２との間のＤＭＡ転送処理を実行する。さらにＤＭＡコントローラ２３は、内部メモリ２５３と通信Ｉ／Ｆ２４との間、ローカルメモリ２２と通信Ｉ／Ｆ２４との間のＤＭＡ転送処理も実行する。
【００２５】
通信Ｉ／Ｆ２４は、ＬＡＮ（Ｌｏｃａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）等で構成されるネットワーク２７とのインタフェースであり、外部装置との通信における物理層（ＰＨＹ層）とデータリンク層（ＭＡＣ層）の通信制御を担っている。
通信Ｉ／Ｆ２４は、内部に送受信データを一時的に蓄積するバッファメモリを装備し、ＤＭＡコントローラ２３のＤＭＡ転送によって、送受信データの入出力が行われる。なお、図１の構成に替えて、通信Ｉ／Ｆ２４がＤＭＡコントローラ２３を内蔵して、この内蔵ＤＭＡコントローラ２３を使用してもよい。
【００２６】
ヘッダ処理部２５は、レジスタ部２５１、コア部２５２、および内部メモリ２５３を備える。このヘッダ処理部２５は、通信プロトコル処理における通信ヘッダの生成処理を実行する。
本実施形態において、ヘッダ処理部２５は、サブＣＰＵ２１が実行する通信プロトコル処理のうち、その一部である通信ヘッダの生成処理を肩代わりして実行する。
【００２７】
レジスタ部２５１は、ヘッダ処理のひな形となるヘッダ情報２５１ａ（以下、「ひな形ヘッダ」という。）通信ヘッダ生成のためのヘッダ編集情報２５１ｂ、およびコア部２５２を制御するために必要となるヘッダ生成制御情報２５１ｃをそれぞれ記憶する。
サブＣＰＵ２１は、ひな形ヘッダ２５１ａおよびヘッダ生成制御情報２５１ｃをレジスタ部２５１に設定し、またヘッダ生成制御情報２５１ｃをレジスタ部２５１に設定することで、コア部２５２を起動して、複数の通信ヘッダを生成させる。
【００２８】
ひな形ヘッダ２５１ａは、ヘッダ処理部２５により複製されて複数の通信ヘッダ２５３ａを生成する際に複製元となるヘッダ情報である。ひな形ヘッダ２５１ａは、サブＣＰＵ２１により実行されるソフトウエアにより設定される。このひな形ヘッダ２５１ａの内部構成は、例えばＯＳＩ参照モデルに規定されるトランスポート層のＴＣＰヘッダとネットワーク層のＩＰヘッダとに分けられる。ＴＣＰヘッダとＩＰヘッダは、各層における通信プロトコル処理を実行する際に使用される。なお、ひな形ヘッダ２５１ａは、ＴＣＰヘッダおよびＩＰヘッダだけでなく、Ｅｔｈｅｒヘッダを含んでよい。Ｅｔｈｅｒヘッダとは、送信先のＭＡＣアドレスや送信元のＭＡＣアドレスが記述されているＯＳＩ参照モデルに規定されるデータリンク層で使用される通信ヘッダである。あるいは、ひな形ヘッダ２５１ａには、ＴＣＰヘッダに替えてＵＤＰヘッダを使用してもよい。
【００２９】
ヘッダ編集情報２５１ｂは、複数の通信ヘッダを作成して編集するために必要となる編集情報であり、サブＣＰＵ２１により実行されるソフトウエアにより設定される。
具体的には、ヘッダ編集情報２５１ｂは、ひな形ヘッダ２５１ａを複製する回数、作成する通信ヘッダの種別、およびひな形ヘッダ２５１ａを複製して作成した通信ヘッダの編集箇所等を保持する。
ヘッダ生成制御情報２５１ｃは、コア部２５２のヘッダ生成動作を制御するために必要となる情報であり、サブＣＰＵ２１により実行されるソフトウエアにより設定される。
【００３０】
コア部２５２は、ヘッダ処理を実行する機能モジュールである。具体的には、コア部２５２は、ヘッダ編集情報２５１ｂに記述された複製回数、すなわち生成すべき通信パケットの数に基づいて、ひな形ヘッダ２５１ａを複製し、複製した複数の通信ヘッダのそれぞれをヘッダ編集情報２５１ｂに基づいて編集する。これによりコア部２５２は、複数の通信ヘッダ２５３ａを生成し、生成された複数の通信ヘッダ２５３ａを内部メモリ２５３に保存する。
内部メモリ２５３は、ヘッダ処理部２５のコア部２５２およびサブＣＰＵ２１からアクセス可能なメモリであり、例えば主としてＳＲＡＭ（Ｓｔａｔｉｃ  Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）等の半導体メモリで構成される。内部メモリ２５３は、コア部２５２により生成された複数の通信ヘッダ２５３ａを記憶する。
【００３１】
＜通信装置１のパケット送信処理＞
図２は、本実施形態において通信装置１が、ネットワーク２７を介して受信側通信装置と接続し、受信側通信装置へ通信パケットを送信するパケット送信処理の処理手順の一例を示すフローチャートである。以下では通信装置１が受信側通信装置との間でデータ転送する際に通信プロトコルとしてＴＣＰ／ＩＰを使用する例を説明するが、本実施形態はＴＣＰ／ＩＰプロトコル以外のプロトコルにも適用可能である。図２では図２のパケット送信処理は、例えば、アプリケーションからユーザデータの送信を指示されたことを契機に起動されてよいが、これに限定されない。
【００３２】
Ｓ１で、通信機器１は、ネットワーク２７を介して受信側通信装置と通信状態となり、メインＣＰＵ３により実行されるアプリケーションソフトウエアが受信側通信装置へ送信するための送信データをメインメモリ４のアプリケーションバッファ領域に準備する。アプリケーションバッファ領域に送信データが所定の量まで蓄積されると、アプリケーションソフトウエアは、メインＣＰＵ３を介してサブＣＰＵ２１に対して受信側通信装置へ送信すべき送信データの準備が完了したことを通知する。
【００３３】
サブＣＰＵ２１へ通知される送信データ準備完了の通知は、現在の通信状態を示す情報を含む。この現在の通信状態を示す情報は、例えばＴＣＰプロトコルを使用した通信接続の開始を示す情報、ＴＣＰプロトコルを使用したデータ転送の開始を示す情報、あるいはＴＣＰプロトコルを使用した通信の切断処理の開始を示す情報であってよい。
【００３４】
Ｓ２で、通信装置１のサブＣＰＵ２１は、メインＣＰＵ３で実行されるアプリケーションソフトウエアにより外部機器へ送信するための送信データの準備が完了したか否かを判定する。具体的には、サブＣＰＵ２１は、Ｓ１で送信データ準備完了の通知を受信した場合、メインメモリ４のアプリケーションバッファ領域に受信側通信装置へ送信するための送信データが蓄積完了していると判定し（Ｓ２：Ｙ）、Ｓ３へ進む。一方、送信データ準備完了の通知を受信しない場合、アプリケーションバッファ領域に受信側通信装置へ送信するための送信データが蓄積完了していないと判定して（Ｓ２：Ｙ）、Ｓ１へ戻ってＳ１の処理を繰り返す。
【００３５】
アプリケーションバッファ領域に受信側通信装置へ送信するための送信データが蓄積完了していると判定された場合、Ｓ３で、サブＣＰＵ２１は、受信側通信装置に対して通信プロトコルに従ったデータ送信処理を開始する。具体的には、サブＣＰＵ２１は、まず、送信データを、メインメモリ４のアプリケーションバッファ領域からサブシステム２内のローカルメモリ２２のネットワークバッファ２２１へ転送する。
【００３６】
Ｓ３では、サブＣＰＵ２１は、Ｓ１でメインＣＰＵ３から受信した送信データ準備完了の通知に基づいて、ＤＭＡ転送により、送信データをメインメモリ４からローカルメモリ２２のネットワークバッファ２２１へ転送する。このＤＭＡ転送を設定するには、まず、サブＣＰＵ２１がＤＭＡ転送の内容を記述するディスクリプタを生成してローカルメモリ２２に保存する。そして、サブＣＰＵ２１がこのディスクリプタを保存したローカルメモリ２２のアドレス情報をＤＭＡコントローラ２３に設定することで、ＤＭＡ転送が実行される。このＤＭＡ転送の完了を以って、サブＣＰＵ２１による通信プロトコルに従った送信処理の準備が完了したことになる。
【００３７】
Ｓ４で、サブＣＰＵ２１は、通信プロトコルに従って、Ｓ３でネットワークバッファ２２１に転送された送信データをセグメント分割して、複数の通信パケットを生成するための複数のペイロードを確定させる。Ｓ４ではさらに、ヘッダ処理部２５は、複数の通信パケットを生成するための複数の通信ヘッダを生成する。
具体的には、サブＣＰＵ２１は、ローカルメモリ２２のネットワークバッファ２２１に転送された送信データから、生成すべき通信パケットのサイズおよび数を決定する。
次に、サブＣＰＵ２１は、ヘッダ処理部２５が通信パケットの通信ヘッダを生成するために必要となる各種情報（２５１ａ〜２５１ｃ）をレジスタ部２５１に設定して、ヘッダ処理部２５を起動する。起動されたヘッダ処理部２５は、生成すべき通信パケットの数と同数の通信ヘッダを、ヘッダ処理部２５内の内部メモリ２５３に生成する。これにより、通信パケットのペイロードの確定と、ペイロードに付加すべき通信ヘッダの生成が完了する。
【００３８】
なお、サブＣＰＵ２１は、Ｓ４で、Ｓ１で受信する送信データ準備完了の通知に含まれる現在の通信状態に応じて、ヘッダ処理部２５のレジスタ部２５１に設定する内容を変化させる。これにより、ヘッダ処理部２５が内部メモリ２５３に生成する通信ヘッダは、現在の通信状態に応じた通信ヘッダとなる。
例えば、Ｓ１で受信される送信データ準備完了の通知に含まれる現在の通信状態が、ＴＣＰプロトコルを使用した通信接続を開始する状態を示す場合、Ｓ４で、通信を開始するために必要となる通信ヘッダが生成される。あるいは、現在の通信状態が、ＴＣＰプロトコルを使用したデータ転送を開始する状態を示す場合、Ｓ４で、データ転送を開始するために必要となる通信ヘッダが生成される。同様に、現在の通信状態が、ＴＣＰプロトコルを使用した通信の切断処理を開始する状態を示す場合、Ｓ４で、通信を切断するために必要となる通信ヘッダが生成される。
なお、Ｓ４における通信ヘッダ生成処理の詳細は、図３および図４を参照して後述する。
【００３９】
Ｓ５で、サブＣＰＵ２１は、Ｓ４で確定した通信パケットのペイロードと生成された通信ヘッダとを合成して通信パケットを生成し、通信Ｉ／Ｆ２４を介して受信側通信装置へ送信する。
具体的には、サブＣＰＵ２１は、ローカルメモリ２２のネットワークバッファ２２１内の送信データをペイロード単位で切り出し、内部メモリ２５３に生成された各通信ヘッダ２５３ａと結合して１つの通信パケットを生成する。そしてサブＣＰＵ２１は、ＤＭＡコントローラ２５にＤＭＡ転送を設定することにより、ＤＭＡコントローラ２３によるＤＭＡ転送を起動して、生成された通信パケットを、通信Ｉ／Ｆ２４へ転送させる。サブＣＰＵ２１は、Ｓ４で決定された通信パケットの数分の複数の通信パケットにつき、ＤＭＡ転送を実行する。
通信Ｉ／Ｆ２４へ転送された通信パケットは、データリンク層（ＭＡＣ層）や物理層（ＰＨＹ層）の通信プロトコル処理の実行を経て、ネットワーク２７を介して受信側通信装置へ送信される。
【００４０】
Ｓ６で、通信装置１は、通信装置１と受信側通信装置との通信状態を終了させる事象が発生したか否かを判定する。受信側通信装置との通信状態を終了させる事象が発生した場合（Ｓ６：Ｙ）、Ｓ７に進み、一方、受信側通信装置との通信状態を終了させる事象が発生していない場合（Ｓ６：Ｎ）、Ｓ１に戻ってＳ１からＳ６の処理を繰り返す。
Ｓ６で判断される受信側通信装置との通信状態を終了させる事象は、例えば、メインＣＰＵ３で実行されているアプリケーションソフトウエアからユーザからの操作等で通信装置１と受信側通信装置との接続を終了させる指示入力を検知したことを含む。受信側通信装置との通信状態を終了させる事象はまた、ユーザがネットワークケーブルを通信装置１から引き抜く等して通信回線が断絶したことを通信Ｉ／Ｆ２４が検知したことを含む。受信側通信装置との通信状態を終了させる事象はまた、通信相手である受信側通信装置から通信回線を切断する旨の通知を含んだ通信パケットを受信したことを含む。
【００４１】
Ｓ７で、通信装置１は、受信側通信装置との通信状態を終了させる処理を実行する。
具体的には、通信装置１のサブＣＰＵ２１は、サブＣＰＵ２１が担う通信プロトコル処理に従って、受信側通信装置との通信回線を切断し、ローカルメモリ２２やヘッダ処理部２５の内部メモリ２５３に保存している関連情報を削除する。その後、サブＣＰＵ２１は、メインＣＰＵ３へ通信回線の切断が完了した旨を通知する。通信回線の切断が完了した旨の通知を受信したメインＣＰＵ３は、アプリケーションソフトウエアの制御の下、通信回線が切断した旨をユーザに通知すべく表示装置を介して表示してもよい。
【００４２】
＜本実施形態における通信ヘッダ生成処理詳細＞
図３は、図２のＳ４における通信プロトコル処理における詳細処理手順の一例を示すフローチャートであり、サブＣＰＵ２１がデータ送信処理を開始してからヘッダ処理部２５を起動するまでの処理を一例として説明する。
Ｓ４１で、サブＣＰＵ２１は、通信プロトコルに従った送信処理を開始し、ウインドウサイズ、輻輳ウインドウサイズ、およびラージパケットサイズの上限値をそれぞれ比較して、これらのうち最小値のものを、パケットの送信サイズとして決定する。
【００４３】
Ｓ４１で決定されるパケットの送信サイズは、通信プロトコルやメモリ等のリソース量に基づいて、ローカルメモリ２２のネットワークバッファ２２１から取り出して、ヘッダ処理部２５でのＴＳＯ処理に受け渡すべきデータサイズである。ウィンドウサイズは、ＡＣＫ（確認応答）パケットを待つことなく送信可能なデータ量であり、受信側通信装置の受信バッファの空き容量を受信側通信装置からＡＣＫパケットで通知されることで取得することができる。輻輳ウインドウサイズは、通信状況に応じて送信すべきデータ量を調整する値である。例えば、ＡＣＫパケットを受信した際に輻輳ウインドウサイズを増やし、ＡＣＫパケットが返って来ずに輻輳が発生した際には輻輳ウインドウサイズを減らす。ラージパケットの上限値は、ヘッダ処理部２５で処理可能なデータ量である。
【００４４】
Ｓ４２で、サブＣＰＵ２１は、ローカルメモリ２２内のネットワークバッファ２２１に取り込んだ送信データを、Ｓ４１で決定された送信サイズで切り出した際に、切り出したデータがネットワークバッファ２２１中の最後の送信データであるか否かを判定する。
具体的には、サブＣＰＵ２１は、以下の式（１）を満たした場合、最後の送信データであると判定して（Ｓ４２：Ｙ）、Ｓ４３へ進む。一方、式（１）を満たさない場合、サブＣＰＵ２１は、最後の送信データでないと判定して（Ｓ４２：Ｎ）Ｓ４３をスキップしてＳ４４へ進む。
ＳＮＤ．ＮＸＴ  ＋  送信サイズ ＝＝ ＳＮＤ．ＵＮＡ  ＋ 未送信データ  （１）
【００４５】
ここで、ＳＮＤ．ＮＸＴ（Ｓｅｎｄ Ｎｅｘｔ）およびＳＮＤ．ＵＮＡ（Ｓｅｎｄ Ｕｎａｃｋｎｏｗｌｅｄ）は、ＴＣＢ（Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｂｌｏｃｋ）で管理している送信シーケンス変数である。このＴＣＢは、ＴＣＰにおいて通信相手との接続状態を保持するデータ構造であり、遷移状態、シーケンス番号、ＡＣＫ番号等を保持している。
「ＳＮＤ．ＮＸＴ」は、次に送信する未送信データの先頭を示すシーケンス番号であり、「ＳＮＤ．ＵＮＡ」は、ＡＣＫパケットを受信していない送信データの先頭を示すシーケンス番号である。送信サイズは、Ｓ４１で決定された、ネットワークバッファ２２１から取り出してヘッダ処理部２５でのＴＳＯ処理に受け渡すべきデータサイズである。未送信サイズは、ＤＭＡコントローラ２３がアプリケーションバッファ領域からネットワークバッファ２２１にＤＭＡ転送し未送信であるデータのサイズである。
【００４６】
Ｓ４３で、サブＣＰＵ２１は、Ｓ４１で決定された送信サイズに基づいて、生成される複数の通信パケットのうち最終の通信パケットのＴＣＰヘッダ、すなわち終端のペイロードに付加されるべきＴＣＰヘッダにＰＳＨフラグを設定することを決定する。
なお、上記では、Ｓ４２で、送信サイズで切り出した送信データがネットワークバッファ２２１の最後の送信データでない場合には、Ｓ４４に進み、終端のペイロードに付加されるべきＴＣＰヘッダであってもＰＳＨフラグを設定しない例を説明した。しかしながら、これに替えて、サブＣＰＵ２１は、送信サイズで切り出した送信データがネットワークバッファ２２１の最後の送信データでない場合であっても、終端のペイロードに付加されるべきＴＣＰヘッダにＰＳＨフラグを設定してもよい。すなわち、送信サイズで切り出された送信データごと、終端のペイロードに付加されるべき通信ヘッダのＰＳＨフラグを設定してもよい。
【００４７】
図４は、ＴＣＰヘッダのヘッダレイアウトを示す図である。図４に示すように、ＴＣＰペイロード３２に付加されるＴＣＰヘッダ３１は、フラグビット３１１のフィールドを含む。このフラグビット３１１は、通信プロトコルを制御するためのフラグビット列により構成される。
ＰＳＨ（Ｐｕｓｈ）フラグは、このフラグビットの１つであり、フラグ設定によって受信データをバッファリングせずに即座にアプリケーションに受け渡すことを示す。フラグビットはさらに、緊急に処理すべきデータを含むことを示すＵＲＧ（Ｕｒｇｅｎｔ）フラグ、確認応答が有効であることを示すＡＣＫ（Ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ）フラグを含んでよい。フラグビットはさらに、コネクションを強制的に切断することを示すＲＳＴ（Ｒｅｓｅｔ）フラグ、コネクションの確立要求を示すＳＹＮ（Ｓｙｎｃｈｒｏｎｉｚｅ）フラグ、およびコネクションの正常終了を示すＦＩＮ（Ｆｉｎ）フラグを含んでよい。サブＣＰＵ２１は、これらのフラグビットを設定すべきか否かをヘッダ編集情報２５１ｂにセットすることで、コア部２５２に通信ヘッダのフラグ情報（フラグビット）を編集させる。
【００４８】
図３に戻り、Ｓ４４で、サブＣＰＵ２１は、Ｓ４１で決定されたこれから送信する送信サイズと、ＭＳＳ（Ｍａｘｉｍｕｍ  Ｓｅｇｍｅｎｔ  Ｓｉｚｅ）から、ヘッダ処理部２５を介して一度に生成すべき通信パケットの数を算出する。
このＭＳＳは、ＴＣＰないしＵＤＰにおいて１セグメントとして転送可能なデータ長である。例えば、サブＣＰＵ２１は、送信サイズを６４Ｋバイト、ＭＳＳを１４６０バイトとした場合、以下の式（２）のように算出する。
送信サイズ(６４Ｋバイト) ＝ ＭＳＳ(１４６０バイト) × 通信パケット数（４４パケット）＋ １２９６バイト      （２）
すなわち、サブＣＰＵ２１は、ＭＳＳ（１４６０バイト）のサイズの通信パケットを４４パケット、余りの１２９０バイトの通信パケットを１パケット、計４５パケットの通信パケットを送信するものと算出する。
【００４９】
Ｓ４５で、サブＣＰＵ２１は、Ｓ４５で算出された通信パケット数に基づいて、ヘッダ処理部２５が一度に処理する複数の通信パケットのうち、最終となる通信パケットを決定する。すなわち、サブＣＰＵ２１は、未送信であるデータを分割した複数のペイロードのうち終端のペイロードを決定して、決定された終端のペイロードに付加すべき通信ヘッダを決定する。
上記の例で、送信サイズを６４Ｋバイト、ＭＳＳを１４６０バイトで４５パケットを送信する場合、サブＣＰＵ２１は、４５パケット目を最終パケットであると決定して、当該最終パケットのＰＳＨフラグを設定するようヘッダ編集情報２５１ｂを生成する。
【００５０】
Ｓ４６で、サブＣＰＵ２１は、Ｓ４３からＳ４５で算出された情報を含むヘッダ編集情報２５１ｂおよびヘッダ生成制御情報２５１ｃを、ヘッダ処理部２５のレジスタ部２５１へセットする。Ｓ４６の処理実行により、ヘッダ処理部２５が複数の通信ヘッダを生成する準備が完了する。
Ｓ４７で、サブＣＰＵ２１は、ヘッダ処理部２５を起動して複数の通信パケットを生成させる。
サブＣＰＵ２１がレジスタ部２５１にヘッダ生成制御情報２５１ｃをセットすることで、ヘッダ処理部２５が起動される。ヘッダ処理部２５が起動されると、コア部２５２は、レジスタ部２５１にセットされたヘッダ編集情報２５１ｂおよびヘッダ生成制御情報２５１ｃに基づいて、内部メモリ２５３内に複数の通信ヘッダを複製し、複製された通信ヘッダを編集する。
【００５１】
Ｓ４８で、サブＣＰＵ２１は、確定した複数のペイロードのそれぞれに、ヘッダ処理部２５が生成した複数の通信ヘッダのそれぞれを合成して、複数の通信パケットを生成する。サブＣＰＵ２１はさらに、ローカルメモリ２２内のネットワークバッファ２２１に取り込んだ送信データのすべてに対して、通信パケット生成処理を完了したか否かを判定する。
ネットワークバッファ２２１に取り込んだ送信データのすべてを処理した場合（Ｓ４８：Ｙ）、図２のＳ５へ進む。一方、ネットワークバッファ２２１に取り込んだ送信データがすべて処理されていない場合（Ｓ４８：Ｎ）、図４２に戻って、Ｓ４２からＳ４７までの処理を繰り返す。
例えば、ネットワークバッファに取り込んだデータが１２８Ｋバイト、Ｓ４１で決定された送信サイズが６４Ｋバイトである場合、Ｓ４２からＳ４７までの処理を１回実行しただけでは、すべての送信データの処理は未だ完了しない。この場合、Ｓ４２へ戻り、２回目のループ処理が開始する。なお、ネットワークバッファ２２１に取り込んだ送信データの送信が完了するまで、Ｓ４１で決定された送信サイズは更新されない。
【００５２】
なお、上記で説明した図３に示す通信パケット生成処理は、ヘッダ処理部２５が使用可能である場合のフローチャートである。
これに対して、ヘッダ処理部２５が使用可能でない場合、サブＣＰＵ２１は、ヘッダ処理部２５を使用するのに替えて、ソフトウエア処理により、図２のＳ４の通信プロトコル処理を実行する。例えば、ヘッダ処理部２５が通信プロトコル処理を実行中である場合やアクセスできない場合、あるいは内部メモリ２５３にあるデータが未送信であって十分な空き領域を確保できない場合等に、サブＣＰＵ２１は、ヘッダ処理部２５が使用可能でないと判定する。この場合、サブＣＰＵ２１は、ソフトウエア処理により、ネットワークバッファ２２１中の送信データの終端のペイロードに付加されるべき通信ヘッダにのみＰＳＨフラグを設定してよい。
【００５３】
さらに、ヘッダ処理部２５自体は利用可能であるものの、サブＣＰＵ２１がヘッダ処理部２５に替えてソフトウエアにより図２のＳ４の通信プロトコル処理を実行してもよい。  例えば、ＴＣＰの再送処理時に、再送パケットに付加する通信ヘッダに対しては、サブＣＰＵ２１は、ソフトウエアにより１パケットずつにＰＳＨフラグを設定してもよい。これにより、受信側通信装置において、再送パケットをバッファリングせず速やかにアプリケーションに受け渡すことができる。
あるいは、アプリケーション層から要求されるデータ転送サイズがＭＳＳ以下である場合、生成する通信パケットに付加する通信ヘッダに対して、サブＣＰＵ２１は、ソフトウエアにより１パケットにＰＳＨフラグを設定してもよい。
【００５４】
以上説明したように、本実施形態によれば、通信装置は、生成すべき複数の通信ヘッダのうち、送信データを分割して生成される複数のペイロード中の終端のペイロードに付加すべき通信ヘッダに、フラグ情報を設定すべきと判定する。そして、通信装置は、判定された通信ヘッダにフラグ情報が設定されるよう、複数の通信ヘッダの生成を制御し、生成された複数の通信ヘッダのそれぞれに、複数のペイロードのそれぞれを付加することで複数の通信パケットを生成する。一方、フラグ情報を設定すべきと判定されなかった他のペイロードに付加すべき通信ヘッダには、フラグ情報は設定されなくてよい。
これにより、送信側通信装置は、終端のペイロードを含む通信パケットが受信側通信装置に受信されるまで、受信側通信装置の受信バッファ内のデータをアプリケーション層へ転送させないよう、受信側通信装置内のデータ転送を制御することができる。従って、受信側通信装置での受信バッファからアプリケーション層へのデータ転送の頻度を低減することができ、パケットをより効率的に送信することで通信性能の低下が有効に防止される。
【００５５】
（実施形態２）
以下、本発明の実施形態２を、実施形態１と異なる点につき説明する。
本実施形態においては、通信装置は、生成される複数の通信ヘッダのうち、いずれの通信ヘッダのフラグ情報を設定するかを、受信側通信装置の受信バッファの状態を予測することで判定する。そして、通信装置は、次回のデータ送信で、受信側通信装置の受信バッファが一杯になると予測される場合に、送信データから分割された複数のペイロードのうち、終端のペイロードに付加されるべき通信ヘッダのフラグ情報を設定する。
これにより、受信側通信装置の受信バッファが一杯になる前に、受信側アプリケーションに送信された通信パケットを強制的に受け渡すよう、受信側通信装置を制御することができる。従って、受信側通信装置のウインドウサイズが０となることを回避しつつ、次のパケット送信処理を実行することができ、パケットをより効率的に送信することができる。
【００５６】
図５は、実施形態２に係る通信装置１が実行する図２のＳ４における通信プロトコル処理の詳細処理手順の一例を示すフローチャートであり、サブＣＰＵ２１がパケット送信処理を開始してからヘッダ処理部２５を起動するまでの処理を一例として説明する。
Ｓ４１は、図３のＳ４１と同様である。
本実施形態において、Ｓ４１で送信サイズを決定した後、Ｓ５１で、サブＣＰＵ２１は、まず、通信パケットの送信先である受信側通信装置の受信バッファの状態を予測する。
具体的には、サブＣＰＵ２１は、受信側通信装置の受信バッファが次回のデータ送信で一杯になるか否かを判定する。
【００５７】
次回のデータ送信で受信側通信装置の受信バッファが一杯になると判定された場合（Ｓ５１：Ｙ）、Ｓ４３へ進んで、サブＣＰＵ２１は、図３のＳ４３と同様、ＰＵＳＨフラグを立てると決定する。一方、次回のデータ送信で受信側通信装置の受信バッファが一杯にならないと判定された場合（Ｓ５１：Ｎ）、Ｓ４２に進む。Ｓ４２で、サブＣＰＵ２１は、図３のＳ４２と同様、切り出したデータがネットワークバッファ２２１中の最後の送信データであるか否かを判定する。
Ｓ４４からＳ４８までの処理は、図３のＳ４４からＳ４８までの処理と同様である。
【００５８】
図６は、送信側通信装置のネットワークバッファ中で未送信であるデータと、受信側通信装置の受信バッファの受信ウインドウサイズとの関係を説明する図である。
図６に示すように、送信側の通信装置１のローカルメモリ２２のネットワークバッファ２２１には、未送信データ６１が格納される。ネットワークバッファ２２１に格納される未送信データ６１は、図５のＳ４１で決定された送信サイズで、送信データ１と、送信データ２とに区切られている。送信データ１は、ＭＳＳ単位で切り出された７つのペイロード（ペイロードＰ１〜Ｐ７）に区切られている。送信データ２も同様に、ＭＳＳ単位で切り出された７つのペイロードに区切られている。
【００５９】
ここで、受信側通信装置は、受信側通信装置の受信バッファ６２の受信ウインドウサイズ（１１パケット）を、ＡＣＫパケットに含めて、送信側の通信装置１へ通知したものとする。このとき、通信装置１のネットワークバッファ２１１中の送信データ１は、７つのペイロード（Ｐ１〜Ｐ７）に分割されるため、７つのパケットとして送信され、受信側通信装置の受信バッファ６２にバッファリングされる。
ここで、送信側の通信装置１は、送信データ１を送信する前に、受信側通信装置において送信データ１を送信した後の受信ウインドウサイズと、次に送信すべき送信データ２のサイズとを比較する。これにより、送信データ１に続いて送信データ２を送信した場合に、受信側通信装置の受信バッファ６２が一杯になるか否かを予測することができる。
【００６０】
図６の例では、送信データ１が受信された後の受信側通信装置の受信バッファ６２の受信ウインドウサイズは、通知された受信ウインドウサイズ（１１パケット）から、送信データ１のサイズ（７パケット）を減じた４パケットと予測できる。ネットワークバッファ２１に取り込まれたデータは送信完了するまで送信サイズが更新されないため、送信データ２のサイズも７パケットであり、この４パケットの受信ウインドウサイズは、送信データ２のサイズ（７パケット）より小さい。すなわち、通信装置１は、送信データ１に続いて送信データ２を受信側通信装置へ送信した場合に、受信側通信装置の受信バッファ６２が一杯になると予測する。
この場合、通信装置１のサブＣＰＵ２１は、図５のＳ５１で、送信データ１の終端のペイロードＰ７に付加される通信ヘッダ（ＴＣＰヘッダ）中のＰＳＨフラグＦ１を設定するよう、ヘッダ編集情報２５１ｂを設定してヘッダ処理部２５を制御する。図６の例では、送信データ２は、ネットワークバッファ２１１中の最後の送信データであるため、サブＣＰＵ２１は、送信データ２の終端のペイロードに付加される通信ヘッダ（ＴＣＰヘッダ）中のＰＳＨフラグＦ２も設定する。
【００６１】
このように、図５のＳ５１で、サブＣＰＵ２１は、受信側通信装置が送信するＡＣＫパケットに含まれるウインドウサイズから、次回のデータ送信で送信先通信装置の受信バッファが一杯になるか否かの状態を予測する。
サブＣＰＵ２１は、受信側通信装置の受信バッファが一杯になると判定した場合、Ｓ４３に進み、送信データ１の終端のペイロードＰ７に付加する通信ヘッダにＰＳＨフラグを設定すると決定する。一方、サブＣＰＵ２１は、受信側通信装置の受信バッファが一杯にならないと判定した場合、Ｓ４２に進む。
受信側通信装置のネットワークバッファが一杯になってしまうと、送信側通信装置は次のパケット送信ができず、待ち時間が発生してしまう。これに対して、本実施形態では、受信側通信装置の受信バッファが一杯になる前に、予めＰＳＨフラグを設定してパケット送信することで、受信側通信装置からのＡＣＫパケットの受信ウインドウサイズが０にならずに次のパケット送信が実行できる。これにより、送信側の通信装置１のパケット送信の待ち時間が短縮するため、パケット送信のスループットが向上する。
【００６２】
以上説明したように、本実施形態によれば、通信装置は、生成される複数の通信ヘッダのうち、いずれの通信ヘッダのフラグ情報を設定するかを、受信側通信装置の受信バッファの状態を予測することで判定する。そして、通信装置は、次回のデータ送信で、受信側通信装置の受信バッファが一杯になると予測される場合に、送信データから分割された複数のペイロードのうち、終端のペイロードに付加されるべき通信ヘッダのフラグ情報を設定する。
これにより、受信側通信装置の受信バッファが一杯になる前に、受信側アプリケーションに送信された通信パケットを強制的に受け渡すよう、受信側通信装置を制御することができる。従って、受信側通信装置のウインドウサイズが０となることを回避しつつ、次のパケット送信処理を実行することができ、パケットをより効率的に送信することができる。
【００６３】
＜他の実施形態＞
なお、上述した各実施形態は、その複数を組み合わせて実現することが可能である。
また、本発明は、上述の実施形態の一部または１以上の機能を実現するプログラムによっても実現可能である。すなわち、そのプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータ（またはＣＰＵやＭＰＵ等）における１つ以上のプロセッサがプログラムを読出し実行する処理により実現可能である。また、そのプログラムをコンピュータ可読な記録媒体に記録して提供してもよい。
また、コンピュータが読みだしたプログラムを実行することにより、実施形態の機能が実現されるものに限定されない。例えば、プログラムの指示に基づき、コンピュータ上で稼働しているオペレーティングシステム（ＯＳ）などが実際の処理の一部または全部を行い、その処理によって上記した実施形態の機能が実現されてもよい。
【符号の説明】
【００６４】
１…通信装置、２…サブシステム、３…メインＣＰＵ、４…メインメモリ、５…システムバス、２１…サブＣＰＵ、２２…ローカルメモリ、２３…ＤＭＡコントローラ、２４…通信Ｉ／Ｆ、２５…ヘッダ処理部、２６…ローカルバス、２７…ネットワーク、２２１…ネットワークバッファ、２５１…レジスタ部、２５２…コア部、２５３…内部メモリ
【図１】
2020043486.tif 000003
【図２】
2020043486.tif 000004
【図３】
2020043486.tif 000005
【図４】
2020043486.tif 000006
【図５】
2020043486.tif 000007
【図６】
2020043486.tif 000008
【手続補正書】
【提出日】令和1年9月11日(2019.9.11)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
通信装置であって、
複数のＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ）ヘッダを生成する第１の生成手段と、
前記第１の生成手段により生成される前記複数のＴＣＰヘッダのうちの何れのＴＣＰヘッダに、ＴＣＰのＰＳＨフラグを設定するかを判定する判定手段と、
前記判定手段により判定されたＴＣＰヘッダに前記ＰＳＨフラグを設定して前記複数のＴＣＰヘッダを生成するよう前記第１の生成手段を制御する制御手段と、
前記第１の生成手段により生成された前記複数のＴＣＰヘッダのそれぞれに、他の通信装置に送信するペイロードを付加して複数の通信パケットを生成する第２の生成手段と、
を有することを特徴とする通信装置。
【請求項２】
前記判定手段は、前記複数の通信パケットのうち、最後に送信される通信パケットのＴＣＰヘッダに前記ＰＳＨフラグを設定すると判定することを特徴とする請求項１に記載の通信装置。
【請求項３】
アプリケーション層から要求されるデータの転送サイズが、ＭＳＳ（Ｍａｘｉｍｕｍ  Ｓｅｇｍｅｎｔ  Ｓｉｚｅ）以下の場合、前記判定手段は、前記複数の通信パケットのうち、最後に送信される通信パケットのＴＣＰヘッダに前記ＰＳＨフラグを設定すると判定することを特徴とする請求項２に記載の通信装置。
【請求項４】
前記他の通信装置に送信するペイロードを格納する送信バッファを更に有し、
前記第２の生成手段により生成される前記複数の通信パケットに含まれるペイロードのサイズを超えるサイズのペイロードを前記送信バッファが格納している場合、前記制御手段は、前記複数の通信パケットのうち、最後に送信される通信パケットのＴＣＰヘッダに前記ＰＳＨフラグが設定されないように前記第１の生成手段を制御することを特徴とする請求項１から３のいずれか１項に記載の通信装置。
【請求項５】
前記他の通信装置のウインドウサイズを取得する取得手段を更に有し、
前記判定手段は、前記取得手段により取得された前記ウインドウサイズに基づいて、前記複数のＴＣＰヘッダのうちの何れのＴＣＰヘッダに、前記ＰＳＨフラグを設定するかを判定することを特徴とする請求項１から４のいずれか１項に記載の通信装置。
【請求項６】
前記制御手段は、前記判定手段により判定されたＴＣＰヘッダに前記ＰＳＨフラグを設定させる情報をレジスタに登録することにより、前記第１の生成手段を制御することを特徴とする請求項１から５のいずれか１項に記載の通信装置。
【請求項７】
前記第１の生成手段は、所定のＴＣＰヘッダを複製し、該複製されたＴＣＰヘッダを編集することによって、前記複数のＴＣＰヘッダを生成することを特徴とする請求項１から６のいずれか１項に記載の通信装置。
【請求項８】
前記制御手段は、生成するＴＣＰヘッダの数、および、前記所定のＴＣＰヘッダの情報を前記第１の生成手段に入力することを特徴とする請求項７に記載の通信装置。
【請求項９】
前記判定手段は、前記他の通信装置との間のＴＣＰ接続に係る情報を保持するＴＣＢ（Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｂｌｏｃｋ）に含まれるシーケンス番号を参照することにより、前記複数のＴＣＰヘッダのうちの何れのＴＣＰヘッダに、前記ＰＳＨフラグを設定するかを判定することを特徴とする請求項１から８のいずれか１項に記載の通信装置。
【請求項１０】
前記他の通信装置のウインドウサイズ、輻輳ウインドウサイズ、および前記第１の生成手段が処理可能なデータ量の少なくともいずれかに基づいて、前記他の通信装置に送信する送信データのサイズを算出する算出手段を更に有することを特徴とする請求項１から９のいずれか１項に記載の通信装置。
【請求項１１】
前記制御手段は、ＴＣＰにおける再送処理で再送される通信パケットに付加されるＴＣＰヘッダに、前記ＰＳＨフラグを設定して前記複数のＴＣＰヘッダを生成するよう前記第１の生成手段を制御することを特徴とする請求項１から１０のいずれか１項に記載の通信装置。
【請求項１２】
前記第１の生成手段は、ＴＣＰ  Ｓｅｇｍｅｎｔａｔｉｏｎ  Ｏｆｆｌｏａｄ（ＴＳＯ）により前記複数の通信ヘッダを生成することを特徴とする請求項１から１１のいずれか１項に記載の通信装置。
【請求項１３】
前記第２の生成手段により生成された前記複数の通信パケットを前記他の通信装置に送信する送信手段をさらに有することを特徴とする請求項１から１２のいずれか１項に記載の通信装置。
【請求項１４】
複数のＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ）ヘッダを生成する生成手段を有する通信装置の制御方法であって、
前記複数のＴＣＰヘッダのうちの何れのＴＣＰヘッダに、ＴＣＰのＰＳＨフラグを設定するかを判定する判定工程と、
前記判定工程において判定されたＴＣＰヘッダに前記ＰＳＨフラグを設定して前記複数のＴＣＰヘッダを生成するよう前記生成手段を制御する制御工程と、
前記生成手段において生成された前記複数のＴＣＰヘッダのそれぞれに、他の通信装置に送信するペイロードを付加して複数の通信パケットを生成する生成工程と、
を有することを特徴とする制御方法。
【請求項１５】
コンピュータを、請求項１から１３のいずれか１項に記載の通信装置の各手段として機
能させるためのプログラム。
【手続補正２】
【補正対象書類名】明細書
【補正対象項目名】００１０
【補正方法】変更
【補正の内容】
【００１０】
上記課題を解決するため、本発明に係る通信装置は、複数のＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ）ヘッダを生成する第１の生成手段と、前記第１の生成手段により生成される前記複数のＴＣＰヘッダのうちの何れのＴＣＰヘッダに、ＴＣＰのＰＳＨフラグを設定するかを判定する判定手段と、前記判定手段により判定されたＴＣＰヘッダに前記ＰＳＨフラグを設定して前記複数のＴＣＰヘッダを生成するよう前記第１の生成手段を制御する制御手段と、前記第１の生成手段により生成された前記複数のＴＣＰヘッダのそれぞれに、他の通信装置に送信するペイロードを付加して複数の通信パケットを生成する第２の生成手段と、を有する。