(57)【要約】【課題】より大きいサイズを有する送信データに対するパケット化処理を行う際に、事前に計算されたチェックサム値を活用する。【解決手段】通信装置は、複数のパケットに対応する送信データをＤＭＡ（Ｄｉｒｅｃｔ  Ｍｅｍｏｒｙ  Ａｃｃｅｓｓ）により送信バッファへ転送し、該送信データの転送に並行して、該送信データに対する第１のチェックサム値を計算し、該転送された該送信データに対するパケット化処理を行う際に、該第１のチェックサム値を利用してパケット化処理を行うことで、複数のパケットを生成する。【選択図】図２
2019201249.tif 000002
【特許請求の範囲】
【請求項１】
通信装置であって、
複数のパケットに対応する送信データをＤＭＡ（Ｄｉｒｅｃｔ  Ｍｅｍｏｒｙ  Ａｃｃｅｓｓ）により送信バッファへ転送する転送手段と、
前記転送手段による前記送信データの転送に並行して、当該送信データに対する第１のチェックサム値を計算する第１の計算手段と、
前記転送手段により転送された前記送信データに対するパケット化処理を行う際に、前記第１の計算手段により計算された前記第１のチェックサム値を利用してパケット化処理を行うことで、複数のパケットを生成する第１の生成手段と、
を有することを特徴とする通信装置。
【請求項２】
通信相手装置へ送信する際の送信データサイズを決定する決定手段と、
前記決定手段により決定された前記送信データサイズに基づいて、前記第１のチェックサム値が利用可能かを判定する判定手段と、
前記判定手段により前記第１のチェックサム値が利用可能と判定された場合、前記第１の生成手段が複数のパケットを生成することを特徴とする請求項１に記載の通信装置。
【請求項３】
前記決定手段は、前記通信相手装置から受信した情報に基づいて、前記送信データサイズを決定することを特徴とする請求項２に記載の通信装置。
【請求項４】
前記転送手段により転送された前記送信データに対するパケット化処理を行う際に、第２のチェックサム値を計算する第２の計算手段と、
前記転送手段により転送された前記送信データに対するパケット化処理を行う際に、前記第２の計算手段により計算された前記第２のチェックサム値を利用してパケット化処理を行うことで、複数のパケットを生成する第２の生成手段と、
を更に有し、
前記判定手段により前記第１のチェックサム値が利用可能でないと判定された場合、前記第２の生成手段が複数のパケットを生成することを特徴とする請求項２または３に記載の通信装置。
【請求項５】
前記判定手段により前記第１のチェックサム値が利用可能でないと判定された場合、前記送信データをチャンク化するチャンク化手段を更に有し、
前記第２の計算手段は、前記チャンク化手段によりチャンク化された各セグメントについて、前記第２のチェックサム値を計算することを特徴とする請求項４に記載の通信装置。
【請求項６】
前記第１のチェックサム値を前記送信データと関連付けてメモリで管理する管理手段を更に有し、
前記判定手段は、前記メモリを参照することにより、前記第１のチェックサム値が利用可能かを判定することを特徴とする請求項２から５のいずれか１項に記載の通信装置。
【請求項７】
前記第１のチェックサム値は、前記送信データを構成する各セグメントに対するチェックサム値であることを特徴とする請求項１から６のいずれか１項に記載の通信装置。
【請求項８】
前記第１の生成手段は、前記第１のチェックサム値を用いて前記各セグメントに対するヘッダを生成し、前記ヘッダと前記各セグメントを連結することにより、複数のパケットを生成することを特徴とする請求項７に記載の通信装置。
【請求項９】
前記送信データに対するチェックサム値を計算し、当該計算したチェックサム値を利用してパケット化することによりパケットを生成する第３の生成手段を更に有し、
前記判定手段は、前記決定手段により決定された前記送信データサイズが所定のサイズを超えるか否かを判定し、
前記判定手段による前記送信データサイズが前記所定のサイズを超えるか否かの判定の結果に基づいて、前記第１の生成手段が複数のパケットを生成するか、前記第３の生成手段がパケットを生成することを特徴とする請求項２から６のいずれか１項に記載の通信装置。
【請求項１０】
通信装置の制御方法であって、
複数のパケットに対応する送信データをＤＭＡ（Ｄｉｒｅｃｔ  Ｍｅｍｏｒｙ  Ａｃｃｅｓｓ）により送信バッファへ転送する転送工程と、
前記転送工程における前記送信データの転送に並行して、当該送信データに対する第１のチェックサム値を計算する計算工程と、
前記転送工程において転送された前記送信データに対するパケット化処理を行う際に、前記第１の計算工程において計算された前記第１のチェックサム値を利用してパケット化処理を行うことで、複数のパケットを生成する生成工程と、
を有することを特徴とする制御方法。
【請求項１１】
コンピュータを、請求項１から９のいずれか１項に記載の通信装置として機能させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信装置、通信装置の制御方法、およびプログラムに関する。
【背景技術】
【０００２】
従来、パケット通信において、通信の信頼性を保証するため、送信側から送信されたパケットを受信した受信側が、ＡＣＫと呼ばれる確認応答を用いる通信方式が利用されている。例えば、インターネット通信において広く利用されているＴＣＰ／ＩＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ／Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）では、送信側は、送信データをセグメントにチャンク化してパケット化して送信する。受信側は、セグメントをオクテット単位にシーケンス番号で管理し、受信に成功したセグメントのシーケンス番号をＡＣＫとして応答する。また、送信側は、所定時間内にＡＣＫを受信しなかったセグメントを含むパケットの再送を行う。
【０００３】
ＴＣＰ／ＩＰのプロトコル処理では、送信側は、通信データのパケット化や再送処理のために、ネットワークバッファを用意している。近年、ＴＣＰ／ＩＰのプロトコル処理では、ＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）による処理軽減および高速送信を実現可能なパケット化技術が用いられている。例えば、指定されたユーザデータをソケットＡＰＩ  ｓｅｎｄ（）のコール毎にネットワークバッファへの転送とチェックサム計算を同時にハードウェアオフロードで処理を行い、転送時に計算された（事前に計算された）チェックサム値を用いてＣＰＵ処理でパケット化する技術である。この技術では、所定の送信単位である１ＭＳＳ（Ｍａｘｉｍｕｍ  Ｓｅｇｍｅｎｔ  Ｓｉｚｅ）以下のデータサイズが、一つずつＣＰＵ処理でパケット化される。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】国際公開第２０１０／０７３６７１号
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかしながら、従来の技術では、より大きいサイズを有する送信データに対するパケット化処理を行う際に、事前に計算されたチェックサム値を活用することができなかった。
【０００６】
本発明は、上記課題に鑑みてなされたものであり、より大きいサイズを有する送信データに対するパケット化処理を行う際に、事前に計算されたチェックサム値を活用することを目的とする。
【課題を解決するための手段】
【０００７】
上記目的を達成するための一手段として、本発明の通信装置は以下の構成を有する。すなわち、通信装置であって、複数のパケットに対応する送信データをＤＭＡ（Ｄｉｒｅｃｔ  Ｍｅｍｏｒｙ  Ａｃｃｅｓｓ）により送信バッファへ転送する転送手段と、前記転送手段による前記送信データの転送に並行して、当該送信データに対する第１のチェックサム値を計算する第１の計算手段と、前記転送手段により転送された前記送信データに対するパケット化処理を行う際に、前記第１の計算手段により計算された前記第１のチェックサム値を利用してパケット化処理を行うことで、複数のパケットを生成する第１の生成手段と、有する。
【発明の効果】
【０００８】
本発明によれば、より大きいサイズを有する送信データに対するパケット化処理を行う際に、事前に計算されたチェックサム値を活用することが可能となる。
【図面の簡単な説明】
【０００９】
【図１】実施形態における通信装置のハードウェア構成例を示す。
【図２】実施形態における通信装置のソフトウェア構成例を示す。
【図３】実施形態１におけるデータ送信処理を説明するフローチャートである。
【図４】実施形態２におけるデータ送信処理を説明するフローチャートである。
【発明を実施するための形態】
【００１０】
以下、添付の図面を参照して、本発明をその実施形態に基づいて詳細に説明する。なお、以下の実施形態において示す構成は一例に過ぎず、本発明は図示された構成に限定されるものではない。
【００１１】
［実施形態１］
送信側におけるＴＣＰ／ＩＰパケット生成の一般的な処理では、まず、ソケットＡＰＩ  ｓｅｎｄ（）によって指定されたユーザデータがネットワークバッファに転送され、ＭＴＵ（ｍａｘｉｍｕｍ  ｔｒａｎｓｍｉｓｓｉｏｎ  ｕｎｉｔ）にチャンク化される。そして、チャンク化されたデータと擬似ヘッダのチェックサムが計算され、ＴＣＰヘッダとＩＰヘッダが追加されたＴＣＴ／ＩＰパケットが生成される。伝送経路がイーサネット（登録商標）の場合、これらのヘッダに加えて、イーサネットヘッダが付加されたイーサネットフレームが生成され、送信される。受信側は、セグメントをオクテット単位にシーケンス番号で管理し、受け取ったセグメントのシーケンス番号をＡＣＫとして応答する必要がある。
【００１２】
ＴＣＰ／ＩＰのプロトコル処理では、送信側のパケット送信の度に受信側がＡＣＫを送信することによる通信速度の低下を回避するために、所定の送信ウィンドウサイズを利用するウィンドウ制御が行われる。ＴＣＰ／ＩＰのウィンドウ制御では、受信側は、受信バッファの残りサイズを送信ウィンドウサイズに設定したＡＣＫを送信し、送信側は、送信ウィンドウサイズになるまでＡＣＫを待つことなく送信データを送信することができる。更に、ＴＣＰ／ＩＰのウィンドウ制御では、通信速度をより向上させるために、スライディングウィンドウが用いられる。スライディングウィンドウでは、受信側はパケットを受信する度にＡＣＫを送信し、送信側は最初のＡＣＫを受信するとウィンドウをスライドさせて、ＡＣＫを待つことなくウィンドウサイズ分のデータを連続的に送信することが可能となる。
【００１３】
上述したように、近年では、ＣＰＵによる処理軽減及び高速送信のため、事前に計算したチェックサム値を用いて１ＭＳＳ以下のデータサイズを、一つずつＣＰＵ処理でパケット化する技術が用いられている。また、送信データのセグメントチャンク化処理と、チャンク化したセグメントのＩＰパケット化処理をネットワークＩ／Ｆでハードウェアオフロードがする技術が用いられている。このような技術は、ＴＳＯ（ＴＣＰ  Ｓｅｇｍｅｎｔａｔｉｏｎ  Ｏｆｆｌｏａｄ）機能により実現化されている（特許文献１参照）。ＴＳＯ機能は、ＮＩＣ（Ｎｅｔｗｏｒｋ  Ｉｎｔｅｒｆａｃｅ  Ｃａｒｄ）などのハードウェアオフロードで実施することが一般的である。ＴＳＯ機能を用いることで、アプリケーションデータを従来のＭＳＳ単位よりも大きいデータ単位でハードウェアオフロードに送信要求を行い、ハードウェアオフロードにてＭＳＳ単位にチャンク化してネットワークに連続送信することが可能となる。一方、ＴＳＯ機能によっても、事前にユーザデータをネットワークバッファへ転送時にハードウェアオフロードで計算したチェックサム値を活用した複数のＩＰパケット化処理ができない。
【００１４】
本実施形態では、ＭＳＳを超えるデータに対しても、事前に計算したチェックサム値を活用した複数のＩＰパケット生成処理を行うことを可能とする通信装置について説明する。
【００１５】
（通信装置１０の構成）
図１に、実施形態１における通信装置１０のハードウェア構成例を示す。通信装置１０は、そのハードウェア構成として、ＲＡＭ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）１０１、ＲＯＭ（Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ）１０３、ＣＰＵ１０２、通信部１１０を有する。これらの構成要素は通常の通信装置と同様であるが、本実施形態における通信装置１０は更に、データ転送部１０５、フレーム生成部１０６、パケット生成部１０７、チェックサム計算部１１１を有する。以下、各構成要素について説明する。
【００１６】
ＲＡＭ１０１は、各種データの保存やワークメモリとして使用される。ＲＡＭ１０１は、送信データを格納して管理するための送信バッファ１１２を有する。ＲＯＭ１０３は、ＣＰＵ１０２により実行される各種プログラム等を記憶する。ＣＰＵ１０２は、ＲＡＭ１０１をワークメモリとして、ＲＯＭ１０３や、図示していないハードディスクなどのプログラム格納部としての記録媒体に格納された各種プログラムを実行し得る。
【００１７】
通信部１１０は、ＭＡＣ（Ｍｅｄｉａ  Ａｃｃｅｓｓ  Ｃｏｎｔｒｏｌ）モジュール１０８とＰＨＹ（Ｐｈｙｓｉｃａｌ  Ｌａｙｅｒ）モジュール１０９を有し、Ｅｔｈｅｒｎｅｔ（商標登録）などのネットワークを介した通信相手装置との通信を行う。データの送受信は、ＣＰＵ１０２によりネットワークドライバが実行され、これに応じてＭＡＣモジュール１０８が制御されることにより行われる。なお、本実施形態では、通信部１１０は、イーサネット（登録商標）を介した通信を行うものとするが、これに替えて、無線ＬＡＮ（Ｗｉ−Ｆｉ）など、ＩＰ通信可能な媒体を介して通信を行うことも可能である。
【００１８】
データ転送部１０５は、例えばＤＭＡ（Ｄｉｒｅｃｔ  Ｍｅｍｏｒｙ  Ａｃｃｅｓｓ）により構成され、通信装置１０内部でデータを転送する。例えば、データ転送部１０５は、ＲＡＭ１０１に記憶されているデータを、フレーム生成部１０６やパケット生成部１０７に転送する。データ転送部１０５は、ＣＰＵ１０２により転送制御されてもよい。チェックサム計算部１１１は、ＲＡＭ１０１に記憶されているデータに対してチェックサム計算を行う。フレーム生成部１０６は、送信する送信データサイズを決定し、決定したサイズの送信データと、送信データに対するヘッダ情報を生成するためのヘッダ情報の生成処理を行う。パケット生成部１０７は、フレーム生成部１０６により生成された送信データとヘッダ情報に基づいて、送信データのセグメント化およびヘッダの生成を行い、当該セグメントとヘッダから送信パケットを生成する。タイマ管理部１０４は、パケット送信に関して必要な所定時間を管理する。なお、以下に説明する（送信）パケットは、ＩＰ通信上で送受信されるデータの単位である。このパケットの組み立て方法については、本実施形態の本質ではないので、説明を省略する。
【００１９】
図２は、本実施形態における通信装置１０の機能構成例を示す。アプリケーション２０１は、ユーザアプリケーションを指す。本実施形態では、アプリケーション２０１は、ソケットＡＰＩ  ｓｅｎｄ（）を呼び出すアプリケーションであり、これにより、任意のサイズの、送信対象のアプリケーションデータ（送信データ）がプロトコルスタック２０２に入力される。
【００２０】
プロトコルスタック２０２は、ネットワークバッファ管理部２０３、セグメント処理部２０４、通信プロトコル処理部２０５、コネクション管理部２０６、ＴＣＰウィンドウ制御部２０７、輻輳制御部２０８から構成される。ネットワークバッファ管理部２０３は、アプリケーション２０１から入力された送信データを、ＲＡＭ１０１の送信バッファ１１２（図１）に格納して管理する。ネットワークバッファ管理部２０３はまた、送信バッファ１１２に格納されている送信データのサイズを管理する。コネクション管理部２０６は、通信装置１０の通信コネクションに関する情報を管理する。例えば、コネクション管理部２０６は、通信コネクションにおけるＭＳＳ（Ｍａｘｉｍｕｍ  Ｓｅｇｍｅｎｔ  Ｓｉｚｅ）等のコネクション情報を管理する。ＴＣＰウィンドウ制御部２０７は、通信インタフェース制御部２０９を介して通信相手装置から受信したＡＣＫ（確認応答）から、ＴＣＰコネクションの送信ウィンドウサイズを取得し、管理する。輻輳制御部２０８は、ＴＣＰコネクションにおける輻輳制御を管理する。例えば、輻輳制御部２０８は、アプリケーション２０１に対する通信コネクションにおける輻輳ウィンドウサイズを管理する。送信ウィンドウサイズと輻輳ウィンドウサイズは、送信データサイズを決定するために使用され得る。
【００２１】
セグメント処理部２０４は、ネットワークバッファ管理部２０３、コネクション管理部２０６、ＴＣＰウィンドウ制御部２０７、輻輳制御部２０８で管理されている情報等に基づいて、送信データサイズ（送信可能な全体の送信データのサイズ）を決定する。すなわち、ＲＡＭ１０１内の送信バッファ１１２に格納されている送信データのサイズ、ＭＳＳ、送信ウィンドウサイズ、輻輳ウィンドウサイズ等に基づいて、送信データサイズが決定される。通信プロトコル処理部２０５は、パケット生成部１０７を制御して、ＴＣＰセグメントのＴＣＰヘッダやＩＰヘッダの生成と、それに伴うチェックサム計算等の処理を行う。そして、通信プロトコル処理部２０５は、これらの処理から得られたデータから、パケット化処理を行って送信パケットを生成する。
【００２２】
データ転送部４００は、データ転送部１０５とチェックサム計算部１１１（図１）に対応し、チャンク部４０１、チェックサム計算部４０２から構成される。チャンク部４０１は、送信データを、データ転送するための所定の単位（例えばＭＳＳ単位）にチャンク化する。チェックサム計算部４０２は、チャンク部４０１によりチャンク化された各データに対してチェックサム計算を行う。
【００２３】
パケット生成部３００は、データ転送部１０５、パケット生成部１０７、チェックサム計算部１１１（図１）に対応し、データ転送部３０１、ヘッダ生成部３０２、パケット生成部３０３から構成される。データ転送部３０１は、送信データを所定の単位（例えばＭＳＳ単位）へのチャンク化し、チャンク化した各データに対してチェックサム計算を行う。ヘッダ生成部３０２は、フレーム生成部１０６により生成されたヘッダ情報に基づいて、ＴＣＰ／ＩＰヘッダとイーサネットヘッダを生成する。パケット生成部３０３は、データ転送部３０１とヘッダ生成部３０２から出力されたデータから、パケット化処理を行って送信パケットを生成する。
【００２４】
本実施形態では、セグメント処理部２０４により決定された送信データサイズに応じて、通信プロトコル処理部２０５またはパケット生成部３００が、送信パケットを生成する。送信パケットの生成手法については、図３を用いて後述する。
【００２５】
通信プロトコル処理部２０５またはパケット生成部３００により生成された送信パケットは、通信インタフェース制御部２０９に入力される。通信インタフェース制御部２０９は、プロトコルスタック２０２と通信インタフェース２１０との間でデータや情報のやり取りを担う。通信インタフェース２１０は、図１のＭＡＣモジュール１０８、ＰＨＹモジュール１０９に対応し、ネットワークと通信を行う。送信パケットの送信は、タイマ管理部１０４により一定時間以上経過したことが通知された場合に、行われてもよい。
【００２６】
（処理の流れ）
次に、図３を参照して、本実施形態における処理について説明する。図３は、本実施形態におけるデータ送信処理を説明するフローチャートである。本フローチャートは、ソケットＡＰＩ  ｓｅｎｄ（）（以下、ｓｅｎｄ（））によるデータ送信処理を想定する。
【００２７】
まず、ステップＳ１０１において、ＣＰＵ１０２により、ＲＯＭ１０３に格納されている所定のプログラムが実行されることに応じて、アプリケーション２０１は、ｓｅｎｄ（）を呼び出す。ｓｅｎｄ（）が呼び出されると、データ転送部１０５は、ステップＳ１０２で、データ転送先であるＲＡＭ１０１内の送信バッファ１１４へ送信データを転送する。それと並行して、チャンク部４０１は、送信データをＭＳＳ単位にチャンク化し、チェックサム計算部４０２は、チャンク化されたデータに対してチェックサム計算する。なお、上述したように、チャンク部４０１とチェックサム計算部４０２を含むデータ転送部４００（図２）は、データ転送部１０５とチェックサム計算部１１１（図１）に対応する。
【００２８】
ステップＳ１０３では、ネットワークバッファ管理部２０３が、チャンク化されたデータと、チャンク化されたデータに対するチェックサム値を関連付けし、送信バッファ１１２に格納する。ステップＳ１０４では、セグメント処理部２０４が、送信バッファ１１４に格納されている送信データ（チャンク化された一連のデータ）のサイズが、ＴＣＰウィンドウ制御部２０７により管理されている送信ウィンドウサイズを超えるかどうかを判定する。送信バッファ１１４に格納されている送信データのサイズが送信ウィンドウサイズを超えない場合は（ステップＳ１０４でＮｏ）、処理はステップＳ１０５に進む。ステップＳ１０５では、セグメント処理部２０４は、送信バッファ１１４に格納されている送信データのサイズを、送信データサイズとして決定する。一方、送信バッファ１１４に格納されている送信データのサイズが送信ウィンドウサイズ超える場合は（ステップＳ１０４でＹｅｓ）、処理はステップＳ１０６に進む。ステップＳ１０６では、セグメント処理部２０４は、送信ウィンドウサイズを、送信データサイズとして決定する。
【００２９】
ステップＳ１０７では、通信プロトコル処理部２０５が、ステップＳ１０６またはＳ１０５で決定した送信データサイズが、コネクション管理部２０６で管理されているＭＳＳを超えるかどうか判定する。決定した送信データサイズがＭＳＳを超えない場合は（ステップＳ１０７でＮｏ）、処理はステップＳ１０８に進む。ステップＳ１０８では、通信プロトコル処理部２０５は、送信データに対するチェックサムを計算してＴＣＰ／ＩＰヘッダを生成し、ＴＣＰ／ＩＰヘッダと送信データ（セグメント）を連結してパケット化し、ＴＣＰ／ＩＰパケットを生成する。通信プロトコル処理部２０５は、更に、イーサネットヘッダを生成し、生成したイーサネットヘッダを用いて、生成したＴＣＰ／ＩＰパケットをイーサネットフレーム化し、ステップＳ１１４に進む。
【００３０】
一方、決定した送信データサイズがＭＳＳを超える場合は（ステップＳ１０７でＹｅｓ）、処理はステップＳ１０９へ進む。ステップＳ１０９では、フレーム生成部１０６は、ＴＣＰ／ＩＰヘッダとイーサネットヘッダを生成するための情報としてヘッダ情報を生成し、ステップＳ１１０へ進む。ステップＳ１１０〜Ｓ１１３の処理は、パケット生成部３００による処理である。なお、上述したように、パケット生成部３００（図２）は、データ転送部１０５、パケット生成部１０７、チェックサム計算部１１１（図１）に対応する。
【００３１】
ステップＳ１１０では、データ転送部３０１は、ステップＳ１０２で計算されたチェックサム値が利用可能かどうかを判定する。ステップ１０２で計算されたチェックサム値は、ステップＳ１０３で、チャンク化されたデータと関連付けられて送信バッファ１１２に格納されている。しかしながら、Ｓ１０４からのＳ１０５またはＳ１０６の処理を経て、送信データサイズに基づいて決定される実際の送信データ（実送信データ）は変わり得る。例えば、実送信データが、複数のチャンクに跨ることもあり得る。よって、ステップＳ１１０では、データ転送部３０１が、ステップＳ１０２で計算されたチェックサム値が実送信データに対応するか否かを判定する。
【００３２】
ステップＳ１１０の判定の結果、ステップＳ１０２で計算されたチェックサム値が利用可能でない場合は（ステップＳ１１０でＮｏ）、処理はステップＳ１１１へ進む。ステップＳ１１１では、データ転送部３０１は、実送信データがＭＳＳ単位にチャンク化された各セグメントに対するチェックサム計算（再計算）を行う。続いて、ヘッダ生成部３０２は、ステップＳ１０９で生成されたヘッダ情報を使用し、各セグメントに対してＴＣＰ／ＩＰヘッダとイーサネットヘッダを（自動）生成する。ステップＳ１１３では、パケット生成部３０３は、Ｓ１１１で生成されたＴＣＰ／ＩＰヘッダと各セグメントを連結し、ＴＣＰ／ＩＰパケット化した後、イーサネットヘッダを付加し、イーサネットフレーム化する。
【００３３】
ステップＳ１０２で計算されたチェックサム値が利用可能である場合は（ステップＳ１１０でＹｅｓ）、処理はステップＳ１１２へ進む。ステップＳ１１２では、ヘッダ生成部３０２は、ステップＳ１０２で計算されたチェックサム値と、ステップＳ１０９で生成されたヘッダ情報を使用し、各セグメントに対して、ＴＣＰ／ＩＰヘッダとイーサネットヘッダを（自動）生成する。ステップＳ１１３では、パケット生成部３０３は、Ｓ１１２で生成されたＴＣＰ／ＩＰヘッダと各セグメントを連結し、ＴＣＰ／ＩＰパケット化した後、イーサネットヘッダを付加し、イーサネットフレーム化する。なお、一度に連結できるセグメントの数は、輻輳ウィドウサイズに基づいて決定され得る。ステップＳ１１４では、通信プロトコル処理部２０５は、イーサネットフレームを通信インタフェース制御部２０９に送信し、処理を終了する。
【００３４】
このように、送信データサイズがＭＳＳを超える場合であっても、事前にハードウェアで計算したチェックサム値を用いてＩＰパケット化処理を行うことができる。また、事前にハードウェアで計算したチェックサム値を用いることができない場合であっても、ハードウェアで再計算したチェックサム値を用いて、ＩＰパケット化処理を行うことができる。なお、ステップＳ１１０〜Ｓ１１３におけるハードウェアによる処理を、ソフトウェアで処理を実行した場合においても、本実施形態を適用可能である。また、本実施形態では、通信インタフェースが一つ存在する例を挙げたが、通信インタフェースが複数の場合にも本実施形態を適用することができる。また、本実施形態では、ＴＣＰ／ＩＰプロトコルを例にして説明したが、ＵＤＰ（Ｕｓｅｒ  Ｄａｔａｇｒａｍ  Ｐｒｏｔｏｃｏｌ）プロトコル等の他のプロトコルを適用することも可能である。
【００３５】
［実施形態２］
続いて、実施形態２について説明する。なお、本実施形態において、実施形態１と同様の構成については、同一符号を付して、その詳細説明を省略する。
【００３６】
（処理の流れ）
図４を参照して、本実施形態における処理について説明する。図４は、本実施形態におけるデータ送信処理を説明するフローチャートである。本フローチャートは、ソケットＡＰＩ  ｓｅｎｄ（）によるデータ送信処理を想定する。なお、Ｓ２０１〜Ｓ２１０の処理は、実施形態１において説明した図３のステップＳ１０１〜Ｓ１１０と同様の処理のため、説明を省略する。
【００３７】
ステップＳ２１０では、データ転送部３０１は、ステップＳ２０２で計算されたチェックサム値が利用可能かどうかを判定する。ステップＳ２０２で計算されたチェックサム値が利用可能でない場合は（ステップＳ２１０でＮｏ）、処理はステップＳ２１１へ進む。ステップＳ２１１では、データ転送部３０１は、実送信データがＭＳＳ単位にチャンク化されているかどうかを判定する。ステップＳ２０２において、送信データはチャンク化されているが、Ｓ１０４からのＳ１０５またはＳ１０６の処理を経て、送信データサイズに対応する送信データ（実送信データ）は変わり得る。よって、Ｓ２１１では、データ転送部３０１は、実送信データがＭＳＳ単位にチャンク化されているか、すなわち、フラグメント化されているかを判定する。
【００３８】
実送信データがＭＳＳ単位にチャンク化されていない場合は（ステップＳ２１１でＮｏ）、処理はステップＳ２１２へ進む。ステップＳ２１２では、データ転送部３０１は、実送信データをセグメントサイズへチャンク化し、チャンク化した各送信データ（セグメント）に対するチェックサム計算（再計算）を行う。続いて、ヘッダ生成部３０２は、ステップＳ２０９で生成されたヘッダ情報を使用し、各セグメントに対してＴＣＰ／ＩＰヘッダとイーサネットヘッダを（自動）生成する。ステップＳ２１５では、パケット生成部３０３は、Ｓ２１２で生成されたＴＣＰ／ＩＰヘッダとセグメントを連結し、ＴＣＰ／ＩＰパケット化した後、イーサネットヘッダを付加し、イーサネットフレーム化する。
【００３９】
実送信データがＭＳＳ単位にチャンク化されている場合は（ステップＳ２１１でＹｅｓ）、処理はステップＳ２１３へ進む。ステップＳ２１３では、データ転送部３０１は、チャンク化された各送信データ（セグメント）のチェックサム計算を行う。また、ヘッダ生成部３０２は、ステップＳ２０９で生成されたヘッダ情報を使用し、各セグメントに対してＴＣＰ／ＩＰヘッダとイーサネットヘッダを（自動）生成する。ステップＳ２１５では、パケット生成部３０３は、Ｓ２１３で生成されたＴＣＰ／ＩＰヘッダとセグメントを連結し、ＴＣＰ／ＩＰパケット化した後、イーサネットヘッダを付加し、イーサネットフレーム化する。
【００４０】
ステップＳ２０２で計算されたチェックサム値が利用可能である場合は（ステップＳ２１０でＹｅｓ）、処理はステップＳ２１４へ進む。ステップＳ２１４では、ヘッダ生成部３０２は、ステップＳ２０２で計算されたチェックサム値と、ステップＳ１０９で生成されたヘッダ情報を使用し、各セグメントに対して、ＴＣＰ／ＩＰヘッダとイーサネットヘッダを（自動）生成する。ステップＳ２１５では、パケット生成部３０３は、Ｓ２１４で生成されたＴＣＰ／ＩＰヘッダとセグメントを連結し、ＴＣＰ／ＩＰパケット化した後、イーサネットヘッダを付加し、イーサネットフレーム化する。なお、一度に連結できるセグメントの数は、輻輳ウィドウサイズに基づいて決定され得る。ステップＳ２１６では、通信プロトコル処理部２０５は、イーサネットフレームを通信インタフェース制御部２０９に送信し、処理を終了する。
【００４１】
このように、送信データサイズがＭＳＳを超える場合であっても、事前にハードウェアで計算したチェックサム値を用いてＩＰパケット化処理を行うことができる。また、事前にハードウェアで計算したチェックサム値を用いることができない場合や、実送信データがチャンク化されていない場合であっても、ハードウェアで再計算したチェックサム値を用いて、ＩＰパケット化処理を行うことができる。なお、ステップＳ２１０〜Ｓ２１５におけるハードウェアによる処理を、ソフトウェアで処理を実行した場合においても、本実施形態を適用可能である。また、本実施形態では、通信インタフェースが一つ存在する例を挙げたが、通信インタフェースが複数の場合にも本実施形態を適用することができる。また、本実施形態では、ＴＣＰ／ＩＰプロトコルを例にして説明したが、ＵＤＰプロトコル等の他のプロトコルを適用することも可能である。
【００４２】
［その他の実施形態］
本発明は、上述の実施形態の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサーがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。
【符号の説明】
【００４３】
１０１  ＲＡＭ、１０２  ＣＰＵ、１０３  ＲＯＭ、１０４  タイマ管理部、１０５  データ転送部、１０６  フレーム生成部、１０７  パケット生成部、１０８  ＭＡＣモジュール、１０９  ＰＨＹモジュール、１１０  通信部、１１１  チェックサム計算部  
【図１】
2019201249.tif 000003
【図２】
2019201249.tif 000004
【図３】
2019201249.tif 000005
【図４】
2019201249.tif 000006