JP7387335B2 - 通信装置、制御方法およびプログラム - Google Patents

Description

本発明は、データ通信を行う通信装置に関する。

ＴＣＰ／ＩＰのパケット化処理である、送信データのセグメント分割処理と、分割したセグメントのＴＣＰ／ＩＰプロトコル処理とをハードウェアが行う技術がある。ここで、ＴＣＰ／ＩＰはＴｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ／Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌの略である。

特許文献１には、セグメント分割処理およびＴＣＰ／ＩＰプロトコル処理をＣＰＵと異なるハードウェアで処理する方法が記載されている。

特開２０１８－１９６０５３号公報

特許文献１の方法は、通信デバイスに依存せずにＴＣＰ／ＩＰパケット化をオフロード処理することができるが、ＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）カーネルのプロトコルスタックへの変更が伴う（例えば、ＯＳのソースコードを変更する必要がある）。このような変更は保守性や品質面の観点から避けたいという要望がある。
本発明は、上記した課題に鑑みてなされたものであり、送信データの処理負担の分散を簡便な構成で実現できるようにすることを目的とする。

上記目的を達成するために、本発明の１つの態様による通信装置は、送信すべきセグメントデータを分割して、所定の通信プロトコルに基づいて送信する通信装置であって、前記セグメントデータを記憶する記憶手段と、ＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）カーネルが前記セグメントデータに対する前記所定の通信プロトコルによるプロトコル処理を実行中に、前記セグメントデータを管理する第一の管理データをＯＳカーネルから取得する取得手段と、前記第一の管理データにより管理されるセグメントデータのセグメントサイズが所定のサイズを超える場合、前記第一の管理データが管理する前記セグメントデータを前記記憶手段から取得し、前記取得した前記セグメントデータを分割する分割手段と、前記分割手段により分割されたセグメントデータを前記記憶手段に送信する第一の送信手段と、前記通信装置が前記分割されたセグメントデータを送信する際に用いるべきヘッダ情報を含む第二の管理データを、前記第一の管理データが管理するヘッダ情報に少なくとも基づき生成する生成手段と、前記生成手段によって生成された前記第二の管理データを前記ＯＳカーネルに送信する第二の送信手段と、前記第二の送信手段により送信された前記第二の管理データが管理するヘッダ情報と前記分割されたセグメントデータに基づいてフレームの生成を行い、当該フレームを外部装置へ送信する第三の送信手段と、を備える。

本発明によれば、送信データの処理負担の分散を簡便な構成で実現できる。

実施形態１に係る通信装置のハードウェア構成図。 実施形態１に係る通信装置の機能構成図。 実施形態１に係るバッファ管理データ処理判定部の処理判定フロー図。 実施形態１に係るオフロード処理後のバッファ管理データを示す図。 実施形態２に係る通信装置の機能構成図。 実施形態２に係るオフロード処理後のバッファ管理データを示す図。

以下、添付図面を参照して本発明の実施形態を詳細に説明する。なお、以下の実施形態は本発明を限定するものではなく、また、実施形態で説明されている特徴の組み合わせの全てが本発明の解決手段に必須のものとは限らない。実施形態の構成は、本発明が適用される装置の仕様や各種条件（使用条件、使用環境等）によって適宜修正または変更され得る。本発明の技術的範囲は、特許請求の範囲によって確定されるのであって、以下の個別の実施形態によって限定されない。

＜実施形態１＞
＜通信装置のハードウェア構成＞
図１は、本実施形態における通信装置１００のハードウェア構成の一例を示す図である。通信装置１００は、カメラ、プリンタ、スマートフォン、タブレット、ＰＣ（Ｐｅｒｓｏｎａｌ Ｃｏｍｐｕｔｅｒ）、プロジェクタ等の通信機能を備えた装置である。通信装置１００は、ＣＰＵ１０２と、ＲＯＭ１０３と、ＲＡＭ１０４と、通信デバイス１０５と、オフロード処理ハードウェア１０６とを有する。システムバス１０１は、ＣＰＵ１０２、ＲＯＭ１０３、ＲＡＭ１０４、通信デバイス１０５およびオフロード処理ハードウェア１０６を接続し、各種データの転送経路となる。ＣＰＵはＣｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔの略である。ＲＯＭはＲｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙの略である。ＲＡＭはＲａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙの略である。

ＣＰＵ１０２は、ＯＳやデバイスドライバを介して各ハードウェア構成部（１０３～１０６）を統括的に制御し、通信装置１００を制御する。
ＲＯＭ１０３は、ＣＰＵ１０２で実行されるＯＳやデバイスドライバ等の制御プログラムを格納している。
ＲＡＭ１０４は、ＣＰＵ１０２の主メモリおよびワークエリア等として機能し、プログラムやデータを一時記憶する。

通信デバイス１０５は、ＭＡＣ（Ｍｅｄｉａ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ）モジュール１０７とＰＨＹ（Ｐｈｙｓｉｃａｌ Ｌａｙｅｒ）モジュール１０８を有し、Ｅｔｈｅｒｎｅｔ等のネットワーク１１１を介した通信相手装置との通信を行う。データの送受信は、ＣＰＵ１０２によりネットワークドライバが実行され、これに応じてＭＡＣモジュール１０７が制御されることにより行われる。尚、本実施形態では、通信デバイス１０５は、Ｅｔｈｅｒｎｅｔを介した通信を行うものとするが、これに替えて、無線ＬＡＮ（Ｗｉ－Ｆｉ）等、ＩＰ通信可能な媒体を介して通信を行うことも可能である。

オフロード処理ハードウェア１０６は、ＤＭＡＣ（Ｄｉｒｅｃｔ Ｍｅｍｏｒｙ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌｌｅｒ）１０９とプロトコル処理ハードウェア１１０を有し、セグメント分割処理や通信プロトコル処理をＣＰＵからオフロードする。
ＤＭＡＣ１０９は、ＲＡＭ１０４に記憶されているデータを、プロトコル処理ハードウェア１１０に転送したり、逆にプロトコル処理ハードウェア１１０で処理したデータをＲＡＭ１０４に転送したりする。ＤＭＡＣ１０９によるデータ転送は、ＣＰＵ１０２により制御される。なお、図１には１つのＤＭＡＣ１０９しか示されていないが、オフロード処理ハードウェア１０６に複数のＤＭＡＣ１０９を設けてもよい。複数のＤＭＡＣとは、例えば、ＲＡＭ１０４からデータを読み込むためのＤＭＡＣと、ＲＡＭ１０４にデータを書き込むためのＤＭＡＣである。

プロトコル処理ハードウェア１１０は、ＴＣＰ／ＩＰ等の通信プロトコル処理を実行する機能を持ったハードウェアで、ＴＣＰやＵＤＰのチェックサム計算、通信ヘッダ生成処理等を行う。
なお、図１に示した構成は一例であり、通信装置１００は図１に示されていない構成要素を備えてもよい。例えば、通信装置１００はタイマ管理部を備えてもよい。タイマ管理部は、所定時間が経過したかを管理する。また、図１には１つのＣＰＵ１０２しか示されていないが、複数のＣＰＵを設けてもよい。あるいは、ＣＰＵ１０２は１つまたは複数のプロセッサにより置換されてもよい。通信装置１００がカメラの場合には、撮像部や表示部を備えてもよい。

＜通信装置の機能構成＞
図２は、本実施形態における通信装置１００の機能構成の一例を示す図である。尚、本実施形態では、ＣＰＵ１０２が実行するＯＳカーネル２０１はＬｉｎｕｘ（登録商標）を想定するが、ＯＳカーネル２０１はＬｉｎｕｘに限定されない。
アプリケーション２００は、ユーザアプリケーションである。アプリケーション２００により、任意のサイズの、送信対象のアプリケーションデータ（送信データ）がプロトコルスタック２０２に入力される。尚、本実施形態では、アプリケーション２００は、ＴＣＰ／ＩＰｖ４通信を行うアプリケーションとして説明するが、ＵＤＰ通信を行うアプリケーションでもよいし、ＩＰｖ６通信を行うアプリケーションでもよい。

プロトコルスタック２０２は、コネクション管理部２０３、第一バッファ管理データ生成部２０４、第一セグメント分割処理部２０５、第一プロトコル処理部２０６、ウィンドウ制御部２０７およびバッファ管理データフック部２０８を有する。
コネクション管理部２０３は、通信装置１００の通信コネクションを管理する。例えば、コネクション管理部２０３は、アプリケーション２００に対する通信コネクションのＭＳＳやオフロード設定情報等のソケット情報やＡＲＰ（Ａｄｄｒｅｓｓ Ｒｅｓｏｌｕｔｉｏｎ Ｐｒｏｔｏｃｏｌ）テーブルのエントリ情報等を管理する。ＡＲＰテーブルには、送信すべきセグメントデータのＭＡＣアドレスとＩＰアドレスが、エントリ情報として記憶される。

第一バッファ管理データ生成部２０４は、カーネル空間で使用する送信バッファの管理データを生成する。例えば、Ｌｉｎｕｘでは、ｓｔｒｕｃｔ ｓｋ＿ｂｕｆｆで定義される構造体を生成する。バッファ管理データは、カーネル空間のデータアドレスやソケット情報への参照、通信デバイス情報への参照等を含んでいる。

第一セグメント分割処理部２０５は、ユーザ空間に存在するアプリケーション２００からの送信データをＭＳＳ単位で分割しながらバッファ管理データが管理するカーネル空間の送信バッファに分割送信データをコピーする。送信バッファにコピーする分割送信データのデータサイズはウィンドウ制御部２０７で管理されているＴＣＰ送信ウィンドウサイズや輻輳ウィンドウサイズ等から決定される。また、ＴＣＰセッションでチェックサム計算のオフロード設定がされていない場合、ＴＣＰセグメントに対するチェックサム値がコピーの際に計算される。
第一プロトコル処理部２０６は、ＴＣＰやＵＤＰのトランスポート層の処理、ＩＰのネットワーク層の処理、具体的には各プロトコルのヘッダ生成処理を行う。

ウィンドウ制御部２０７は、ＴＣＰ送信ウィンドウサイズおよび輻輳ウィンドウを管理する。
バッファ管理データフック部２０８は、第一プロトコル処理部２０６がＩＰ処理をしている途中でバッファ管理データをフックして処理するコールバックを登録する機能を有する。例えば、Ｌｉｎｕｘでは、Ｎｅｔｆｉｌｔｅｒと呼ばれるフレームワークで提供されるＡＰＩを使ってバッファ管理データフック部２０８が実現される。ここで、バッファ管理データのフックとは、バッファ管理データの取得処理を意味する。

通信デバイス転送処理部２０９は、プロトコルスタック２０２で処理されたバッファ管理データを通信デバイス１０５に入力する機能を有する。通信デバイス転送処理部２０９には、通信デバイス１０５のドライバも含まれる。なお、通信デバイス１０５のドライバはＯＳカーネル２０１に含まれていてもよいし、後述する動的にロードするソフトウェア（以下、「動的ロードソフトウェア２１０」と称する）として実現してもよい。

動的ロードソフトウェア２１０は、ＯＳカーネル２０１の起動後に動的にロードされる。動的ロードソフトウェア２１０は、コールバック登録部２１１、バッファ管理データ処理判定部２１２、プロトコル処理返付部２１３、ソケット情報書き換え部２１４、第二バッファ管理データ生成部２１５および通信デバイス処理入力部２１６を有する。
コールバック登録部２１１は、バッファ管理データフック部２０８が提供する機能を用いて、バッファ管理データをＩＰプロトコル処理中にフックして処理するコールバックを登録する。つまり、本実施形態において、コールバック登録部２１１は、バッファ管理データをフックする機能を有する。

バッファ管理データ処理判定部２１２は、コールバック登録部２１１で登録されたコールバック内で、フックしたバッファ管理データの中身を解析し、処理判定を行う（バッファ管理データの処理の方法を決定する）。例えば、バッファ管理データ処理判定部２１２は、フックしたバッファ管理データを、フック元であるプロトコルスタック２０２の処理に戻すという判定（決定）をすることができる。また、バッファ管理データ処理判定部２１２は、フックしたバッファ管理データのソケット情報を書き換えるという判定をすることができる。さらに、バッファ管理データ処理判定部２１２は、フックしたバッファ管理データをオフロード処理するという判定をすることもできる。処理判定の詳細については図３を用いて後述する。

プロトコル処理返付部２１３は、バッファ管理データ処理判定部２１２においてフックしたバッファ管理データをプロトコルスタック２０２の処理に戻すと判定された場合、当該バッファ管理データをプロトコルスタック２０２に戻す。あるいは、プロトコル処理返付部２１３は、ソケット情報書き換え部２１４でソケット情報を書き換えたバッファ管理データをプロトコルスタック２０２に戻す。例えば、Ｎｅｔｆｉｌｔｅｒフレームワークにおいては、コールバックの返り値としてＮＦ＿ＡＣＣＥＰＴで定義された定数を返すことでプロトコルスタック２０２の処理に戻す。

ソケット情報書き換え部２１４は、バッファ管理データ処理判定部２１２においてフックしたバッファ管理データのソケット情報を書き換えると判定された場合、当該バッファ管理データのソケット情報を書き換える。書き換えるソケット情報は、例えば、ＭＳＳのキャッシュ値と、チェックサム計算をハードウェアオフロードする設定である。ＭＳＳのキャッシュ値を実際のＭＳＳ値よりも大きな値に設定することで、プロトコルスタック２０２の第一セグメント分割処理部２０５において分割されるセグメントデータサイズが大きくなる。これにより、一つのバッファ管理データで管理されるセグメントデータサイズが大きくなる。または、セグメントオフロードするように設定することでセグメントデータサイズを大きくしてもよい。セグメントオフロードするように設定する場合、最大セグメントサイズおよび最大セグメント数の設定も行う。また、チェックサム計算をハードウェアオフロードするように設定することで、第一セグメント分割処理部２０５においてコピーの際に発生するチェックサム計算処理がスキップされ、プロトコルスタック２０２の処理が軽減される。ソケット情報を書き換えたバッファ管理データはプロトコル処理返付部２１３によりプロトコルスタック２０２に戻される。ソケット情報を書き換えたコネクションについては、以降、大きなセグメントデータサイズでＴＣＰチェックサム計算がされない状態のバッファ管理データが動的ロードソフトウェア２１０にフックされる。

第二バッファ管理データ生成部２１５は、バッファ管理データ処理判定部２１２においてフックしたバッファ管理データのセグメント分割処理と通信プロトコル処理をハードウェアオフロードすると判定された場合に、バッファ管理データを生成する。生成するバッファ管理データの個数は、フックしたバッファ管理データが管理するセグメントデータサイズを実際のＴＣＰセッションのＭＳＳで割ることで算出する。割り切れずに余りが発生する場合は切り上げる。例えば、フックしたバッファ管理データが管理するセグメントデータサイズが１５０００Ｂｙｔｅであり、ＭＳＳが１４６０Ｂｙｔｅの場合、１１個のバッファ管理データを生成する。また、第二バッファ管理データ生成部２１５は、生成したバッファ管理データおよびフックしたバッファ管理データをオフロード処理ハードウェア１０６に入力する。第二バッファ管理データ生成部２１５が生成したバッファ管理データは、ＯＳカーネル２０１からフックしたバッファ管理データとは異なるので、第二のバッファ管理データと称してもよい。

通信デバイス処理入力部２１６は、オフロード処理ハードウェア１０６においてセグメント分割処理および通信プロトコル処理がなされたバッファ管理データ（第二のバッファ管理データ）を、通信デバイス転送処理部２０９に入力する。つまり、通信デバイス処理入力部２１６は、第二のバッファ管理データを、フック元であるＯＳカーネル２０１に送信する。第二のバッファ管理データの入力は、ＯＳカーネル２０１の機能を用いて行われる。例えば、Ｌｉｎｕｘにおいては、ｄｅｖ＿ｑｕｅｕｅ＿ｘｍｉｔ（）を呼び出すことで、第二のバッファ管理データを入力する。フックしたバッファ管理データは、この段階で解放する。例えば、Ｌｉｎｕｘにおいては、通信デバイス処理入力部２１６は、フックしたバッファ管理データをｋｆｒｅｅ＿ｓｋｂ（）により解放する。また、通信デバイス処理入力部２１６が、全ての第二のバッファ管理データを通信デバイス転送処理部２０９に入力し終わると、コールバック関数の一連の処理が終わる。動的ロードソフトウェア２１０（通信デバイス処理入力部２１６）は、プロトコルスタック２０２に、フックしたバッファ管理データをコールバック関数内で処理した旨の信号（コールバックの返り値）を送る。例えば、Ｎｅｔｆｉｌｔｅｒフレームワークにおいては、コールバックの返り値としてＮＦ＿ＳＴＯＬＥＮで定義された定数を送る。

オフロード処理ハードウェア１０６は、第二セグメント分割処理部２１７と第二プロトコル処理部２１８を有する。
第二セグメント分割処理部２１７は、ＤＭＡＣを備えており、フックしたバッファ管理データで管理されるセグメントデータのアドレスを読み出し元とし、セグメントデータを取得する。第二セグメント分割処理部２１７は、取得したセグメントデータを、ＭＳＳ単位でセグメントデータをメモリコピーすることでセグメント分割処理を行う。より詳しくは、第二セグメント分割処理部２１７は、第二バッファ管理データ生成部２１５で生成した複数のバッファ管理データに対し、管理されるデータ領域を書き出し先としてＭＳＳ単位でセグメントデータをメモリコピーすることでセグメント分割処理を行う。

第二プロトコル処理部２１８は、セグメント分割処理がなされたバッファ管理データに対して、ＴＣＰ／ＩＰのプロトコル処理を行う。フックしたバッファ管理データにプロトコル処理中のヘッダデータが含まれているので、第二プロトコル処理部２１８は、当該ヘッダデータに基づいて第二バッファ管理データ生成部２１５で生成した複数のバッファ管理データに対し、プロトコル処理を行う。例えば、ＩＰヘッダについては、アドレス情報やプロトコル情報等はそのままコピーし、個々のバッファ管理データで異なる値（パケット長、識別子、チェックサム等）は計算および再入力を行う。ＴＣＰヘッダについては、ポート番号情報やコントロールフラグ等はそのままコピーし、シーケンス番号やチェックサム等は計算および再入力を行う。また、第二プロトコル処理部２１８はＭＡＣヘッダも生成する。フックしたバッファ管理データにはＭＡＣヘッダは付与されていないが、第二プロトコル処理部２１８は、ＡＰＲテーブルの宛先デバイス情報から取得できる近傍エントリ情報に基づいてＭＡＣヘッダを生成する。例えば、Ｌｉｎｕｘにおいては、第二プロトコル処理部２１８はｓｔｒｕｃｔ ｎｅｉｇｈｂｏｕｒ構造体で管理される情報からＭＡＣヘッダを生成する。

なお、本実施形態では、第二セグメント分割処理部２１７と第二プロトコル処理部２１８はオフロード処理ハードウェア１０６で実現しているが、ソフトウェアで実現してもよい。
また、図２に示した構成は一例であり、複数の機能部が１つの機能部に統合されてもよいし、いずれかの機能部が複数の機能部に分けられてもよい。さらに、図２に示した機能部に含まれる一部または全部の機能がハードウェア化されていてもよい。ハードウェア化は、例えばＡＳＩＣ（Ａｐｐｌｉｃａｔｉｏｎ Ｓｐｅｃｉｆｉｃ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ）により実現される。

＜バッファ管理データ処理判定部の判定フロー＞
図３は、本実施形態におけるバッファ管理データ処理判定部２１２の判定フロー図である。バッファ管理データ処理判定部２１２は、プロトコルスタック２０２からフックしたバッファ管理データを解析し、処理の方法を決定する。図３において、ＳはＳｔｅｐの略である。図３の処理は、例えば、図１のＣＰＵ１０２がＲＯＭ１０３に記憶されたプログラムを読み出して実行することにより行われる。

Ｓ３０１において、バッファ管理データ処理判定部２１２は、フックしたバッファ管理データのＩＰヘッダからトランスポート層の通信プロトコルを確認し、オフロード処理対象の通信プロトコルか否かを判定する。本実施形態ではＴＣＰプロトコルのみオフロード処理するものとして説明する。つまり、Ｓ３０１の判定は、通信プロトコルの種類に基づいて行われる。トランスポート層の通信プロトコルがＴＣＰプロトコルであれば（Ｓ３０１の判定結果がＹｅｓの場合）Ｓ３０２に進み、ＴＣＰプロトコルでなければＳ３０６に進む。
Ｓ３０２において、バッファ管理データ処理判定部２１２は、フックしたバッファ管理データのＴＣＰヘッダからポート番号を確認し、オフロード処理対象のポート番号かどうかを判定する。対象ポート番号であればＳ３０３に進み、対象ポート番号でなければＳ３０６に進む。なお、ポート番号によるフィルタリングは無くてもよい（つまりＳ３０２は省略してもよい）が、例えば、特定のアプリケーションのみオフロード処理を行いたい場合はＳ３０２を実行する。Ｓ３０２を実行するためには、オフロード処理を行いたいアプリケーションで使用するポート番号を予め入力しておく。

Ｓ３０３において、バッファ管理データ処理判定部２１２は、ソケット情報が書き換え済みか否かを判定する。具体的には、バッファ管理データ処理判定部２１２は、ソケット情報の中のＭＳＳのキャッシュ値とハードウェアチェックサムオフロードフラグを確認する。ソケット情報が書き換え済みであればＳ３０４に進み、書き換え済みでなければＳ３０８に進む。
Ｓ３０４では、バッファ管理データ処理判定部２１２は、ＡＲＰテーブルを参照して、次に送信すべきセグメントデータに関する近傍エントリ情報があるかどうかを判定する。近傍エントリ情報がなければ（Ｓ３０４の判定結果がＮｏの場合）、第二プロトコル処理部２１８でＭＡＣヘッダが生成できないため、フックしたバッファ管理データをプロトコル処理に戻す（Ｓ３０６）。近傍エントリ情報があればＳ３０５に進む。

Ｓ３０５において、バッファ管理データ処理判定部２１２は、フックしたバッファ管理データのセグメントデータサイズがＭＳＳよりも大きいかどうかを判定する。セグメントデータサイズがＭＳＳよりも大きければＳ３０７に進み、ＭＳＳ以下であればＳ３０６に進む。
Ｓ３０６において、バッファ管理データ処理判定部２１２は、フックしたバッファ管理データがオフロード処理対象ではなく、プロトコル処理に戻すと判定する。そして、バッファ管理データ処理判定部２１２は、当該バッファ管理データをプロトコル処理返付部２１３に送る。

Ｓ３０７において、バッファ管理データ処理判定部２１２は、フックしたバッファ管理データがオフロード処理対象であると判定する。そして、バッファ管理データ処理判定部２１２は、当該バッファ管理データを第二バッファ管理データ生成部２１５に送る。
Ｓ３０８において、バッファ管理データ処理判定部２１２は、フックしたバッファ管理データのソケット情報を書き換えると判定する。そして、バッファ管理データ処理判定部２１２は、当該バッファ管理データをソケット情報書き換え部２１４に送る。

＜プロトコル処理後のバッファ管理データ＞
図４は、第二セグメント分割処理部２１７におけるセグメントデータのコピー（複製）および分割と、第二プロトコル処理部２１８におけるプロトコル処理後のバッファ管理データを示した図である。
バッファ管理データ４００はプロトコルスタック２０２からフックしたバッファ管理データである。
セグメントデータ４０１はバッファ管理データ４００で管理されるセグメントデータである。セグメントデータ４０１はＭＳＳを超えるセグメントサイズの場合にオフロード処理対象となる。

ヘッダデータ４０２は、セグメントデータ４０１に対して、第一プロトコル処理部２０６で処理中のヘッダデータである。ヘッダデータ４０２には、ＴＣＰヘッダおよびＩＰヘッダが付与されており、ＴＣＰチェックサム値は計算されていない状態を想定する。
バッファ管理データ４０３、４０４、４０５、４０６は、第二バッファ管理データ生成部２１５で生成されるバッファ管理データ（第二のバッファ管理データ）である。図４は、第二のバッファ管理データが４つの場合を示しているが、第二のバッファ管理データの数は４に限定されない。

セグメントデータ４０７、４０８、４０９、４１０は、第二セグメント分割処理部２１７においてセグメントデータ４０１を分割して得られるセグメントデータであって、バッファ管理データ４０３、４０４、４０５、４０６で管理するセグメントデータ領域にコピーされる。バッファ管理データ４０３～４０６の数は、セグメントデータ４０７～４１０の数と同じである。
ヘッダデータ４１１、４１２、４１３、４１４は、ヘッダデータ４０２に基づいて生成され、セグメントデータ４０７、４０８、４０９、４１０に付けられるヘッダデータである。より詳しくは、第二プロトコル処理部２１８でプロトコル処理されたバッファ管理データ４０３～４０６が管理するデータヘッダ４１１～４１４には、ヘッダデータ４０２に基づいて生成されたＴＣＰヘッダとＩＰヘッダが付与される。そして、ヘッダデータ４１１～４１４には、ＡＲＰテーブルの近傍エントリ情報から得られるＭＡＣヘッダも付与される。ヘッダデータ４０２および４１１～４１４は通信ヘッダと称してもよい。

以上、本実施形態によれば、ＯＳカーネル２０１のプロトコルスタック２０２が処理中のＭＳＳを超えるセグメントデータサイズのバッファ管理データ４００をフックする。フックしたバッファ管理データ４００のセグメントデータ４０１をオフロード処理によりセグメント分割してデータコピーを行う。データコピーしたセグメントデータ４０７～４１０を持ち、通信プロトコル処理をした新たなバッファ管理データ４０３～４０６を生成する。そして、新たに生成したバッファ管理データ４０３～４０６をＯＳカーネル２０１の通信デバイス転送処理部２０９に戻す。この一連の処理により、ＯＳカーネル２０１とは異なる動的にロードしたソフトウェア２１０でセグメント分割処理および通信プロトコル処理を、通信デバイス１０５に依存せず、ＯＳカーネル２０１の変更もせずに実行することができる。よって、送信データの処理負担の分散を簡便な構成で実現できる。

なお、図３のＳ３０２で使用するポート番号は、宛先／送信元ポート番号である。また、ポート番号の代わりに宛先ＩＰアドレスを使用して、オフロード処理対象の宛先ＩＰアドレスであればＳ３０３に進むようにしてもよい。
また、バッファ管理データ処理判定部２１２は、ＴＣＰウインドウスケールのシフトカウント（３ウエイシェイクハンド後）が、所定値（例えば、１）以上であれば、フックしたバッファ管理データのソケット情報を書き換えるという判定をしてもよい。
Ｓ３０６を実行した時点で、チェックサム計算がオフになっているならば、プロトコル処理返付部２１３は、チェックサム計算を行ってから、当該バッファ管理データをプロトコルスタック２０２に戻してもよい。この場合、プロトコル処理返付部２１３は、バッファ管理データをＩＰ層に戻す。

＜実施形態２＞
実施形態１では、第二セグメント分割処理部２１７において、フックしたバッファ管理データ４００が管理するセグメントデータ４０１を、バッファ管理データ４０３～４０６が管理するセグメントデータ領域に分割しつつコピーした。実施形態２では、第二セグメント分割処理部２１７において、セグメントデータ４０１をコピーしない場合を説明する。以下の記載において、実施形態１と同様な構成、機能および処理については、同じ参照符号を付ける。

ハードウェア構成については実施形態１（図１）と同様であるため説明を省略する。また、バッファ管理データ処理判定部２１２の判定フローについては図３と同様であるため説明を省略する。

＜通信装置の機能構成＞
図５は、実施形態２における通信装置１００の機能構成の一例を示す図である。実施形態１（図２）と異なる部分のみ説明する。実施形態２の動的ロードソフトウェア２１０は、図２の構成と比較すると、バッファ管理データ管理部５００をさらに備えている。
バッファ管理データ管理部５００は、第二バッファ管理データ生成部２１５で生成されたバッファ管理データをクローンし、動的ロードソフトウェア２１０内で管理する。クローンは、セグメントデータ（図４の符号４０７～４１０）自体をコピーする処理を行うのではなく、当該セグメントデータへの参照を持ったバッファ管理データを生成する処理を行う。例えば、Ｌｉｎｕｘにおいては、ｓｋｂ＿ｃｌｏｎｅ（）により、バッファ管理データ（クローン）が生成される。また、バッファ管理データ管理部５００は、管理しているバッファ管理データについて、現在の確認応答番号（ＡＣＫ番号、シーケンス番号）から当該バッファ管理データが不要かどうかを確認し、不要であれば解放する。解放可否確認のタイミングはコールバックが呼ばれた際に毎回確認してもよいし、コールバックの任意の回数毎に確認してもよし、所定時間経過毎に確認してもよい。

＜プロトコル処理後のバッファ管理データ＞
図６は、本実施形態における第二セグメント分割処理部２１７におけるセグメントデータの分割、および第二プロトコル処理部２１８におけるプロトコル処理後のバッファ管理データを示した図である。
バッファ管理データ４００、セグメントデータ４０１、ヘッダデータ４０２、バッファ管理データ４０３～４０６、ヘッダデータ４１１～４１４については実施形態１における図４と同様であるため説明を省略する。

本実施形態では、コピーしたセグメントデータ４０７～４１０（図４）を用いるのではなく、セグメントデータ参照６００、６０１、６０２、６０３を用いる。セグメントデータ参照６００、６０１、６０２、６０３は、それぞれバッファ管理データ４０３、４０４、４０５、４０６のフラグメントされたデータ参照であり、セグメントデータ４０１をＭＳＳで分割したデータの先頭アドレスを指す。セグメントデータ参照６００、６０１、６０２、６０３は、メモリアドレス情報であり、それぞれ対応するバッファ管理データ４０３、４０４、４０５、４０６に格納されている。セグメントデータ参照６００～６０３は、第二セグメント分割処理部２１７により、バッファ管理データ４０３～４０６へ格納される。
バッファ管理データ４０３～４０６のヘッダデータ４１１～４１４とセグメントデータ４０１は連続領域に存在しないため、通信デバイス１０５への転送時にＧａｔｈｅｒ機能を用いて連結する。そのため、本実施形態では、通信デバイス転送処理部２０９がＧａｔｈｅｒ機能を備えているとする。

以上、本実施形態によれば、ＯＳカーネル２０１のプロトコルスタック２０２が処理中のＭＳＳを超えるセグメントデータサイズのバッファ管理データ４００をフックする。フックしたバッファ管理データ４００のセグメントデータ４０１をオフロード処理によりセグメント分割する。分割したセグメントデータへの参照４１１～４１４を持ち、通信プロトコル処理をした新たなバッファ管理データ４０３～４０６を生成する。新たに生成したバッファ管理データ４０３～４０６をＯＳカーネル２０１の通信デバイス転送処理部２０９に戻す。これにより、ＯＳカーネル２０１とは異なる動的にロードしたソフトウェア２１０でセグメント分割処理および通信プロトコル処理を、通信デバイス１０５に依存せず、ＯＳカーネル２０１の変更もせずに実行することができる。また、セグメントデータのコピーをしないので、実施形態１と比較して、オフロード処理における負荷が軽減される。

本発明は、上述の実施形態の１以上の機能を実現するプログラムを、ネットワークまたは記憶媒体を介してシステムまたは装置に供給し、そのシステムまたは装置のコンピュータにおける１つ以上のプロセッサがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。

１００…通信装置、１０６…オフロード処理ハードウェア、２０１…ＯＳカーネル、２０２…プロトコルスタック、２０８…バッファ管理データフック部、２１２…バッファ管理データ処理判定部、２１３…プロトコル処理返付部、２１４…ソケット情報書き換え部、２１５…第二バッファ管理データ生成部、２１７…第二セグメント分割処理部、２１８…第二プロトコル処理部、４００…バッファ管理データ、４０１…セグメントデータ、４０３～４０６…バッファ管理データ、４０７～４１０…セグメントデータ

Claims (9)

1. 送信すべきセグメントデータを分割して、所定の通信プロトコルに基づいて送信する通信装置であって、
   前記セグメントデータを記憶する記憶手段と、
   ＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）カーネルが前記セグメントデータに対する前記所定の通信プロトコルによるプロトコル処理を実行中に、前記セグメントデータを管理する第一の管理データをＯＳカーネルから取得する取得手段と、
   前記第一の管理データにより管理されるセグメントデータのセグメントサイズが所定のサイズを超える場合、前記第一の管理データが管理する前記セグメントデータを前記記憶手段から取得し、前記取得した前記セグメントデータを分割する分割手段と、
   前記分割手段により分割されたセグメントデータを前記記憶手段に送信する第一の送信手段と、
   前記通信装置が前記分割されたセグメントデータを送信する際に用いるべきヘッダ情報を含む第二の管理データを、前記第一の管理データが管理するヘッダ情報に少なくとも基づき生成する生成手段と、
   前記生成手段によって生成された前記第二の管理データを前記ＯＳカーネルに送信する第二の送信手段と、
   前記第二の送信手段により送信された前記第二の管理データが管理するヘッダ情報と前記分割されたセグメントデータに基づいてフレームの生成を行い、当該フレームを外部装置へ送信する第三の送信手段と、
   を備えることを特徴とする通信装置。
2. 前記取得手段は、前記ＯＳカーネルが備えている機能を用いて、前記第一の管理データを取得することを特徴とする請求項１に記載の通信装置。
3. 前記第二の送信手段は、前記ＯＳカーネルが備えている機能を用いて、前記第一の管理データを前記ＯＳカーネルに送信することを特徴とする請求項１または２に記載の通信装置。
4. 前記分割手段および前記生成手段は、前記ＯＳカーネルと異なるソフトウェアの機能、または、前記通信装置のＣＰＵと異なるハードウェアの機能により実現されることを特徴とする請求項１から３のいずれか１項に記載の通信装置。
5. 前記第一の送信手段および前記第二の送信手段は、前記ＯＳカーネルと異なるソフトウェアの機能により実現されることを特徴とする請求項１から４のいずれか１項に記載の通信装置。
6. 前記第三の送信手段は、前記第二の管理データが管理するセグメントデータのセグメントサイズと、ソケット情報と、前記所定の通信プロトコルの種類と、宛先のポート番号と、送信元ポート番号と、ＡＲＰ（Ａｄｄｒｅｓｓ Ｒｅｓｏｌｕｔｉｏｎ Ｐｒｏｔｏｃｏｌ）テーブルのエントリ情報と、宛先ＩＰアドレスと、ＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）ウインドウスケールのシフトカウントの少なくとも一つに基づいて、前記フレームの生成を行うことを特徴とする請求項１から５のいずれか１項に記載の通信装置。
7. 前記所定の通信プロトコルは、ＴＣＰ／ＩＰプロトコルであることを特徴とする請求項１から６のいずれか１項に記載の通信装置。
8. 送信すべきセグメントデータを分割して、所定の通信プロトコルに基づいて送信する通信装置の制御方法であって、
   前記セグメントデータを所定の記憶領域に記憶する記憶ステップと、
   ＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）カーネルが前記セグメントデータに対する前記所定の通信プロトコルによるプロトコル処理を実行中に、前記セグメントデータを管理する第一の管理データをＯＳカーネルから取得する取得ステップと、
   前記第一の管理データにより管理されるセグメントデータのセグメントサイズが所定のサイズを超える場合、前記第一の管理データが管理する前記セグメントデータを前記所定の記憶領域から取得し、前記取得した前記セグメントデータを分割する分割ステップと、
   前記分割ステップにおいて分割されたセグメントデータを前記所定の記憶領域に送信する第一の送信ステップと、
   前記通信装置が前記分割されたセグメントデータを送信する際に用いるべきヘッダ情報を含む第二の管理データを、前記第一の管理データが管理するヘッダ情報に少なくとも基づき生成する生成ステップと、
   前記生成ステップにおいて生成された前記第二の管理データを、前記ＯＳカーネルに送信する第二の送信ステップと、
   前記第二の送信ステップにおいて送信された前記第二の管理データが管理するヘッダ情報と前記分割されたセグメントデータに基づいてフレームの生成を行い、当該フレームを外部装置へ送信する第三の送信ステップと、
   を有することを特徴とする制御方法。
9. コンピュータを請求項１から７のいずれか１項に記載の通信装置として動作させるためのプログラム。

Images