(57)【要約】【課題】      柔軟性・拡張性に優れたデータ通信技術を提供すること。【解決手段】  ソフトウェアモジュールの実行を制御する汎用プロセッサと、通信を制御する通信制御プロセッサとを有するデータ通信装置は、データ通信において必要とされるプロトコルの処理が予め設定された管理元で可能か否を判定する判定部と、判定部の判定により、プロトコルの処理が管理元で実行できない場合、プロトコルの処理を制御するために生成されたプロトコル・コントロール・ブロックの管理元を切り替える切り替え部とを備えることを特徴とする。【選択図】  図４
2007142582.tif 000002
【特許請求の範囲】
【請求項１】
ソフトウェアモジュールの実行を制御する汎用プロセッサと、通信を制御する通信制御プロセッサとを有するデータ通信装置であって、
データ通信において必要とされるプロトコルの処理が予め設定された管理元で可能か否を判定する判定手段と、
前記判定手段の判定により、前記プロトコルの処理が前記管理元で実行できない場合、前記プロトコルの処理を制御するために生成されたプロトコル・コントロール・ブロックの管理元を切り替える切り替え手段と
を備えることを特徴とするデータ通信装置。
【請求項２】
前記プロトコルには、トランスポート・コントロール・プロトコル、インターネット・プロトコル、トランスポート・レベル・セキュリティ  ハンドシェイクプロトコル、トランスポート・レベル・セキュリティ  レコードプロトコル及びユーザ・データグラム・プロトコルのうち少なくとも一つが含まれることを特徴とする請求項１に記載のデータ通信装置。
【請求項３】
受信したデータ処理要求の内容を特定する特定手段を更に備え、
前記特定手段の特定結果に基づき、処理すべきデータの処理容量により前記プロトコル・コントロール・ブロックの管理元が予め設定されることを特徴とする請求項１に記載のデータ通信装置。
【請求項４】
ＦＩＮパケットの送信または受信により、前記トランスポート・コントロール・プロトコル用のプロトコル・コントロール・ブロックが前記通信制御プロセッサの管理元にあるプロトコル処理を切断する場合、前記切り替え手段は、前記汎用プロセッサに管理元を切り替えることを特徴とする請求項１に記載のデータ通信装置。
【請求項５】
前記プロトコル・コントロール・ブロックの通信負荷を設定された閾値と比較し、当該比較の結果に基づき前記プロトコル・コントロール・ブロックの管理元を切り替えるための命令を発行する比較手段を更に備え、
前記切り替え手段は、前記比較手段により発行される命令に従い前記プロトコル・コントロール・ブロックの管理元を切り替えることを特徴とする請求項１に記載のデータ通信装置。
【請求項６】
ソフトウェアモジュールの実行を制御する汎用プロセッサと、通信を制御する通信制御プロセッサとを有するデータ通信装置におけるデータ通信方法であって、
データ通信において必要とされるプロトコルの処理が予め設定された管理元で可能か否を判定する判定工程と、
前記判定工程の判定により、前記プロトコルの処理が前記管理元で実行できない場合、前記プロトコルの処理を制御するために生成されたプロトコル・コントロール・ブロックの管理元を切り替える切り替え工程と
を備えることを特徴とするデータ通信方法。
【請求項７】
前記プロトコルには、トランスポート・コントロール・プロトコル、インターネット・プロトコル、トランスポート・レベル・セキュリティ  ハンドシェイクプロトコル、トランスポート・レベル・セキュリティ  レコードプロトコル及びユーザ・データグラム・プロトコルのうち少なくとも一つが含まれることを特徴とする請求項６に記載のデータ通信方法。
【請求項８】
受信したデータ処理要求の内容を特定する特定工程を更に備え、
処理すべきデータの処理容量により前記プロトコル・コントロール・ブロックの管理元が予め設定されることを特徴とする請求項６に記載のデータ通信方法。
【請求項９】
ＦＩＮパケットの送信または受信により、前記トランスポート・コントロール・プロトコル用のプロトコル・コントロール・ブロックが前記通信制御プロセッサの管理元にあるプロトコル処理を切断する場合、前記切り替え工程は、前記汎用プロセッサに管理元を切り替えることを特徴とする請求項６に記載のデータ通信方法。
【請求項１０】
前記プロトコル・コントロール・ブロックの通信負荷を設定された閾値と比較し、当該比較の結果に基づき前記プロトコル・コントロール・ブロックの管理元を切り替えるための命令を発行する比較工程を更に備え、
前記切り替え工程は、前記比較工程により発行される命令に従い前記プロトコル・コントロール・ブロックの管理元を切り替えることを特徴とする請求項６に記載のデータ通信方法。
【請求項１１】
請求項６乃至１０のいずれかに記載のデータ通信方法をコンピュータに実行させることを特徴とするプログラム。
【請求項１２】
請求項１１に記載のプログラムを格納したことを特徴とするコンピュータ可読の記憶媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワークを介して行うデータ通信技術に関するものである。
【背景技術】
【０００２】
インターネットを中心とするネットワークプロトコルとして、インターネット・プロトコル(ＩＰ)、トランスポート・コントロール・プロトコル(ＴＣＰ)等が用いられている。ここで、ＩＰは、Internet Protocolを示し、ＴＣＰは、Transmission Control Protocolを示す。これら一連のプロトコル群はＴＣＰ/ＩＰと呼ばれている。
【０００３】
ＴＣＰ/ＩＰは、汎用プロセッサ上のソフトウェアモジュールとして、オペレーティングシステムに組み込まれた形で実現されることが多い。近年ＴＣＰ/ＩＰのプロトコル処理を専門に受け持つハードウェアモジュールとしてＴＯＥ (TCP/IP Offload Engine)が用いられるようになってきている。
【０００４】
ＴＯＥは、専用のハードウェア、または専用プロセッサとファームウェアとして構成されることが多いが、汎用プロセッサ上のソフトウェア処理の代替という点で同じものとみなすことができる。ＴＣＰ/ＩＰに限らず、より上位のプロトコル処理を受け持つハードウェアも存在するが、これらは総称して通信オフロードエンジンと呼ばれている。
【０００５】
ＴＯＥを用いると、チェックサム計算などＴＣＰ/ＩＰプロトコル処理に適した機構を備えることから、比較的低いコストで高い性能を得ることができる。更に汎用プロセッサの処理負荷を軽減することで、アプリケーションとして画像処理など負荷の重い処理を実施することができ、システムの機能を高めることもできる。一方、従来のＴＯＥでは、コネクション数の上限が予め制限されていたり、ＴＣＰ/ＩＰのパラメータ調整範囲が制限されていたりする場合がある。このため、汎用プロセッサ上のソフトウェアモジュールにくらべると柔軟性・拡張性が乏しく、結果的に適用範囲が限られるという問題がある。
【０００６】
なお、特許文献１には、異なる通信プロトコルをもつ複数のデバイスを接続可能とするために、接続されるデバイスに応じてプログラムを切り換えることが開示されている。
【特許文献１】特開平７−２５４９４６公報
【発明の開示】
【発明が解決しようとする課題】
【０００７】
すなわち、ＴＯＥを含む従来の通信オフロードエンジンでは、汎用プロセッサ上のソフトウェアモジュールと比べて柔軟性・拡張性が乏しい。特に、ＴＣＰのような内部状態の複雑なプロトコルについては、汎用プロセッサ上のソフトウェアモジュールと併用することができないという問題がある。
【課題を解決するための手段】
【０００８】
本発明は、上記の従来技術における問題を解決するべく、柔軟性・拡張性に優れたデータ通信技術を提供することを目的とするものである。ＴＣＰ/ＩＰのプロトコル処理を汎用プロセッサ上のソフトウェアモジュールと通信オフロードエンジンを併用しつつ、通信内容に応じて動的に選択する。これにより、高い柔軟性・拡張性を確保しつつ、通信内容に応じて最適な処理系の選択を実現するデータ通信技術の提供を目的とする。
【０００９】
上記の目的を達成するべく、本発明に係るデータ通信装置は、
ソフトウェアモジュールの実行を制御する汎用プロセッサと、通信を制御する通信制御プロセッサとを有するデータ通信装置であって、
データ通信において必要とされるプロトコルの処理が予め設定された管理元で可能か否を判定する判定手段と、
前記判定手段の判定により、前記プロトコルの処理が前記管理元で実行できない場合、前記プロトコルの処理を制御するために生成されたプロトコル・コントロール・ブロックの管理元を切り替える切り替え手段と
を備えることを特徴とする。
【００１０】
あるいは、本発明に係るデータ通信方法は、
ソフトウェアモジュールの実行を制御する汎用プロセッサと、通信を制御する通信制御プロセッサとを有するデータ通信装置におけるデータ通信方法であって、
データ通信において必要とされるプロトコルの処理が予め設定された管理元で可能か否を判定する判定工程と、
前記判定工程の判定により、前記プロトコルの処理が前記管理元で実行できない場合、前記プロトコルの処理を制御するために生成されたプロトコル・コントロール・ブロックの管理元を切り替える切り替え工程と
を備えることを特徴とする。
【発明の効果】
【００１１】
本発明によれば、データ通信の内容に応じて、汎用プロセッサまたは通信を制御する通信制御プロセッサを選択することで、高い柔軟性及び拡張性を確保しつつ、最適な処理系の選択が可能になる。
【発明を実施するための最良の形態】
【００１２】
（第１実施形態）
以下、図面を参照して本発明の実施形態を説明する。図１は、本発明の実施形態に係るデータ通信装置の構成を示すブロック図である。汎用プロセッサ（ＣＰＵ）１０１、専用の通信制御プロセッサであるオフロードエンジン（ＴＯＥ）１０２、ＲＯＭ１０３、ＲＡＭ１０４、ネットワーク１０７と接続するためのネットワークインタフェース（ＮＩＣ）１０５は、バス１０６により接続されている。
【００１３】
汎用プロセッサ１０１は、例えば、Ｕｎｉｘ（登録商標）のような汎用オペレーティングシステムを稼動させ、オフロードエンジン１０２は、組込み用のオペレーティングシステムを稼動させる。両オペレーティングシステムは、それぞれＴＣＰ/ＩＰに基づく処理（ＴＣＰ/ＩＰ処理）を行うソフトウェアモジュールを含む。これらのソフトウェアモジュール群は、ＲＯＭ１０３に記録されており、ＲＡＭ１０４をワークエリアとして用いて動作することが可能である。但し、オフロードエンジン１０２は、ソフトウェアモジュールを含まないハードウェアとして構成してもよい。以下の説明は、ハードウェアで構成されたオフロードエンジン１０２についても、同様に適用することができるものとする。
【００１４】
更に、ネットワークインタフェース１０５は、必ずしもバス１０６に独立に接続されている必要はなく、オフロードエンジン１０２と一体構成であってもよい。
【００１５】
例えば、イーサネット（登録商標）のように標準で内蔵されるネットワークインタフェースの場合は、送受信バッファを含めてオフロードエンジン１０２と一体の構成にすれば、バスの負荷を軽減することが可能である。一方、無線LANなどで、ＵＳＢデバイスやＰＣカードのような外部接続型ネットワークインタフェースの場合は、図１に示した構成とすることが多い。
【００１６】
本実施形態に係るデータ通信装置は、ネットワーク１０７を介したデータの送信および受信処理を行うことが可能である。データ通信装置は、データ通信の内容に応じて、ソフトウェアモジュールの実行を制御する汎用プロセッサ（ＣＰＵ１０１）または、通信を制御する通信制御プロセッサ（以下、オフロードエンジン（ＴＯＥ））１０２を選択する。
【００１７】
ここで、データ通信装置は、汎用プロセッサ１０１、オフロードエンジン１０２、ソフトウェアモジュールの協働により設定部、判定部、切り替え部、特定部及び比較部により構成される。
【００１８】
設定部は、プロトコルの処理を制御するために生成されたプロトコル・コントロール・ブロック（ＰＣＢ）の管理元として、汎用プロセッサ１０１またはオフロードエンジン１０２のいずれかに設定する。
【００１９】
判定部は、データ通信において必要とされるプロトコルの処理が可能か否を、各管理元において、プロトコル・コントロール・ブロックの有無（管理下にあるか否か）により判定する。
【００２０】
判定部の判定により、プロトコルの処理が設定された管理元で実行できない場合、切り替え部は、プロトコル・コントロール・ブロックの管理元を切り替える。すなわち、切り替え部は、汎用プロセッサ１０１及びオフロードエンジン１０２の両方で処理が可能なプロトコル・コントロール・ブロックの有無（オフロードすべきか否か）を判定する。そして、オフロード可能な場合、管理元で実行できないプロトコルの処理を実行するために、両方で処理が可能なプロトコル・コントロール・ブロックの管理元を切り替える。
【００２１】
特定部は、受信したデータ処理要求（ＨＴＴＰリクエスト）の内容を特定する。すなわち、処理すべきデータが、処理容量の大きいデータ（例えば、映像データの送信）であるか、処理容量の小さいデータ（例えば、カメラの制御データ等）であるかを特定する。
【００２２】
比較部は、プロトコル・コントロール・ブロックの通信負荷を設定された閾値と比較し、比較結果によりプロトコル・コントロール・ブロックの管理元を切り替えるためのオフロード開始命令、またはオフロード開始命令を発行する。
【００２３】
図２は、ＴＣＰ/ＩＰの内部処理を制御するためのプロトコル・コントロール・ブロック(ＰＣＢ:Protocol Control Block)の構成を模式的に示す図である。各プロトコルに対応してＩＰ用ＰＣＢ２０１、ＴＣＰ用ＰＣＢ２０２などが用いられる。更に、トランスポート・レベル・セキュリティ(ＴＬＳ:Transport Level Security)による暗号通信を行う場合は、上位のＰＣＢとしてＴＬＳコネクション用ＰＣＢ２０３やＴＬＳセッション用ＰＣＢ２０４等が用いられる。一連のＰＣＢはアプリケーションが設定したプロトコルに従って作成され、相互に関連づけられた上で、アプリケーションインタフェースであるソケット(ｓｏｃｋｅｔ)２０５から参照される。
【００２４】
図３は、ＴＣＰ用ＰＣＢ２０２の概略的な内容を示す図である。ＴＣＰ用ＰＣＢ２０２には通信を制御するための状態変数と状態フラグ、通信負荷を表わす通信レート、送信と受信の制御に用いられるシーケンス番号、送信及び受信ウインドウが含まれる。更に、ＴＣＰ用ＰＣＢ２０２には、データを一時的に格納するバッファとバッファ管理情報、輻輳ウインドウのようなフロー制御情報、再送や遅延ＡＣＫ等の送信に用いられるタイマーも含まれる。
【００２５】
受信バッファ３０１と送信バッファ３０２は、それぞれ対応するウインドウやシーケンス番号によって内容が管理されている。他のＰＣＢに保持される内容はプロトコル毎に異なる。例えば、ＩＰ用のＰＣＢ２０１ではアドレス情報や経路情報、ＴＬＳコネクション用ＰＣＢ２０３では暗号化鍵や暗号化状態、ＴＬＳセッション用ＰＣＢ２０４ではセッション識別情報、証明書、暗号化アルゴリズムなどである。
【００２６】
ＰＣＢに関する構成上の特徴は、ＰＣＢが汎用プロセッサ１０１とオフロードエンジン１０２で共有されており、更にいずれの管理下にあるか識別するための情報（図３の「管理元」）を保持している点である。すなわち、ＰＣＢ（２０１〜２０４）はＲＡＭ１０４上に保持されるデータ構造である。そして、ＰＣＢ（２０１〜２０４）相互、あるいはＰＣＢ（２０１〜２０４）とソケット２０５は、メモリ空間のアドレスを用いて相互に参照し合っている。汎用プロセッサ１０１のアドレス空間とオフロードエンジン１０２のアドレス空間は同一である方が望ましいが、異なる場合でもアドレス変換によって参照できればよい。
【００２７】
各ＰＣＢ（２０１〜２０４）を汎用プロセッサ１０１の管理下に置くか、オフロードエンジン１０２の管理下に置くかは、アプリケーションから設定される。
【００２８】
例えば、ＴＣＰ用ＰＣＢ２０２であれば、サーバとしてクライアントからの接続を受け入れるパッシブオープンと、クライアントとしてサーバへの接続を行うアクティブオープンとがある。前者の場合は、例えば、ＨＴＴＰ用のポートを作成して接続要求を受け付けるように（listen）しておき、ＳＹＮパケットによる接続要求を受け付けると新たなＰＣＢが作成される。受け付け（listen）用ポートを汎用プロセッサ１０１側に作成しておけば、新しい接続に対応するＰＣＢも汎用プロセッサ１０１側に作成される。逆に、受け付け（listen）用ポートをオフロードエンジン１０２側に作成しておけば、新しい接続に対応するＰＣＢもオフロードエンジン１０２側に作成される。アプリケーションから受け付け（listen）用ポートを作成する際に、ソケット作成命令においていずれの管理下に置くかを設定することができる。そして、受け付け（listen）用ポートを作成した後も後述するオフロード開始命令、またはオフロード停止命令によって管理元を切り替えることができる。オフロード開始命令、またはオフロード停止命令は、パッシブオープンによって作成されたＰＣＢ、またはアクティブオープンによって作成されたＰＣＢについても、全く同様に適用することが可能である。
【００２９】
更に、ＴＬＳによる暗号通信を行う場合、図２に示すようにＴＬＳコネクション用ＰＣＢ２０３やＴＬＳセッション用ＰＣＢ２０４が設けられる。各ＰＣＢについては個別にオフロード開始、オフロード終了を設定することができる。すなわち、ソケット作成命令においてプロトコル毎に管理元を設定することができるとともに、作成した後でプロトコルを設定して管理元を切り替えることも可能である。
【００３０】
図４は、汎用プロセッサ（ＣＰＵ）１０１とオフロードエンジン（ＴＯＥ）１０２のプロトコルスタックの構成例を示す図である。汎用プロセッサ１０１はアプリケーションを実行し、ＡＰＩを介して通信制御を行う。汎用プロセッサ１０１側には、ＴＣＰとユーザ・データグラム・プロトコル（ＵＤＰ）、およびＴＬＳハンドシェイクプロトコル(ＴＬＳ Ｈ)に対応したプロトコル処理機能がある。オフロードエンジン１０２側にはＩＰ、ＴＣＰとＵＤＰ、およびＴＬＳレコードプロトコル(ＴＬＳ Ｒ)に対応したプロトコル処理機能がある。
【００３１】
この例では、ＴＣＰとＵＤＰに対応したプロトコル処理機能が汎用プロセッサ１０１とオフロードエンジン１０２の両方に組み込まれている。従って、ＴＣＰやＵＤＰについてはオフロード開始命令、またはオフロード停止命令を用いることによって、ＰＣＢの管理元を切り替えることができる。
【００３２】
一方、ＴＬＳハンドシェイクプロトコル（ＴＬＳ  Ｈ）、ＴＬＳレコードプロトコル（ＴＬＳ  Ｒ）に対応したプロトコル処理機能は、それぞれ汎用プロセッサ１０１側、オフロードエンジン１０２側にのみ組み込まれている。そのため、これらのプロトコル処理ついてはソケット作成時にＰＣＢの管理元が決定されるため、その後のオフロード開始命令・オフロード停止命令によって管理元を切り替えることはできない。すなわち、オフロード開始命令、オフロード停止命令が適用されるには、汎用プロセッサ１０１側とオフロードエンジン１０２側の両方に共通のプロトコル処理機能を持つプロトコルスタック要素が組み込まれている必要がある。例えば、ＴＬＳ  Ｒに対応したプロトコルスタック要素が、汎用プロセッサ１０１及びオフロードエンジン１０２の両方に組み込まれていれば、オフロード開始・停止命令によって、ＰＣＢの管理元を切り替えることができる。
【００３３】
図５は、ＰＣＢの管理元を汎用プロセッサ１０１とオフロードエンジン１０２の間で切り替える手順を示すフローチャートである。汎用プロセッサ１０１からオフロードエンジン１０２に切り替える命令をオフロード開始命令という。また、オフロードエンジン１０２から汎用プロセッサ１０１に切り替える命令をオフロード停止命令という。両者の処理手順は同じであるため、以下の説明では、オフロード開始命令について説明する。
【００３４】
ステップＳ５００において、アプリケーションがソケットとプロトコルを設定してオフロード開始命令を発行する。そして、ステップＳ５０１で、初めに設定されたソケットが存在するかどうかを確認する。ソケットが存在すれば（Ｓ５０１−ＹＥＳ）、処理はステップＳ５０２に進められ、設定されたプロトコルに対応するＰＣＢが存在するかどうか確認する。続いて、ステップＳ５０３において、そのＰＣＢが汎用プロセッサ１０１の管理下にあり、しかもオフロードエンジン１０２側に設定されたプロトコルに対応するプロトコルスタック要素が組み込まれているか（オフロード可能）どうかを判定する。オフロード可能と判定されれば、ステップＳ５０４において、汎用プロセッサ１０１の管理下から削除し、ステップＳ５０５において、オフロードエンジン１０２側の管理下への追加を行って、処理を完了する。
【００３５】
一方、ソケットが存在しない場合（Ｓ５０１−ＮＯ）、ＰＣＢが存在しない場合（Ｓ５０２−ＮＯ）、そして、プロトコルスタック要素が組み込まれていない場合（Ｓ５０３−ＮＯ）、ステップＳ５０６でエラー処理を行う。
【００３６】
ステップＳ５０４とＳ５０５の処理内容は、汎用プロセッサ１０１とオフロードエンジン１０２の組合せによって決まる。一般には汎用プロセッサ１０１側とオフロードエンジン１０２側でＰＣＢの構造が異なるので、構造を変換するとともに、関連する付加的な処理、例えば、ＴＣＰのタイマーの移動を行う必要がある。具体的には、移動元のＰＣＢを参照して移動先のＰＣＢを作成し、ＰＣＢ間の相互参照関係を更新した後、移動元のＰＣＢを消去すればよい。尚、この処理を行っている間、パケットの送受信処理は保留されることはいうまでもない。
【００３７】
次に、図４に示したプロトコルスタックに基づいて、送信処理と受信処理における汎用プロセッサ１０１とオフロードエンジン１０２の動作について説明する。
【００３８】
（パケットの送信処理）
初めに、汎用プロセッサ１０１側のＴＣＰを用いてパケットを送信する場合について説明する。アプリケーションがデータの送信処理を行うと、汎用プロセッサ１０１側のオペレーティングシステムにおいてソケットが検索され、最上位のＰＣＢとして汎用プロセッサ１０１の管理下にあるＴＣＰ用ＰＣＢが取り出される。この結果、汎用プロセッサ１０１側のＴＣＰが起動され、送信バッファの空き領域に送信データが格納された後、ＴＣＰヘッダを作成する。
【００３９】
次に、汎用プロセッサ１０１は、下位プロトコルであるＩＰ処理を行うが、ＩＰは汎用プロセッサ１０１側にはなく、オフロードエンジン１０２側にある。このため、汎用プロセッサ１０１及びオフロードエンジン１０２の両方で処理が可能なＴＣＰ用ＰＣＢを介して管理元（汎用プロセッサ１０１側）で実行できないＩＰの処理をオフロードエンジン１０２側に依頼する。汎用プロセッサ１０１は、ＴＣＰヘッダと送信バッファを合わせてオフロードエンジン１０２にＩＰへの送信処理を依頼する。具体的には、オフロードエンジン１０２に対する割込み要求を行うか、またはオフロードエンジン１０２の制御レジスタへの書き込みを行うことになる。
【００４０】
送信処理の依頼がオフロードエンジン１０２に受け付けられるとＴＣＰ以下の送信処理の管理元が切り替えられることになる。送信処理の依頼を受け付けたオフロードエンジン１０２は、ＩＰ処理としてＩＰヘッダの作成等を行い、通信インタフェースを介してパケットを送出する。
【００４１】
オフロードエンジン１０２側のＴＣＰを用いてパケットを送信する場合は、ソケットから取り出される最上位のＰＣＢはオフロードエンジン１０２の管理下にあるものである。この場合、汎用プロセッサ１０１のＴＣＰを起動せず、割込みやレジスタへの書き込みによって、オフロードエンジン１０２のＴＣＰに対してＴＣＰ以下の送信処理を依頼する。オフロードエンジン１０２はＴＣＰの処理、ＩＰの処理を行ったのち、通信インタフェースを介してパケットを送出する。この間、汎用プロセッサ１０１は、オフロードエンジン１０２との間における通信処理には一切関与しない。
【００４２】
（パケットの受信処理）
次に、パケット受信処理について説明する。ネットワークインタフェース１０５がパケットを受信すると、ネットワークインタフェース１０５は、受信データをメモリ（ＲＡＭ１０４）に転送した後、オフロードエンジン１０２に対して、割込み等によってパケットの受信を通知する。
【００４３】
オフロードエンジン１０２はＩＰヘッダを解析して、上位プロトコルのＰＣＢを検索する。上位プロトコルのＰＣＢがオフロードエンジン１０２側にあればそのまま上位プロトコルの処理を行う。オフロードエンジン１０２側に上位のプロトコルのＰＣＢがなく汎用プロセッサ１０１側にあれば、割込みによって汎用プロセッサ１０１に上位プロトコルの処理を依頼する。以下これを繰返し、上位プロトコルがなくなった時点で、ソケットを用いてアプリケーションに対して受信データを提供する。
【００４４】
以上の処理は、ＴＬＳを用いた暗号通信等にもそのまま適用される。すなわち、アプリケーションがＴＬＳコネクションを作成すると、ClientHelloから始まる一連のＴＬＳハンドシェイクメッセージの送受信が行われる。この場合、ＴＬＳハンドシェイクプロトコル（ＴＬＳ  Ｈ）は汎用プロセッサ１０１側、ＴＬＳレコードプロトコル（ＴＬＳ  Ｒ）はオフロードエンジン１０２側で処理された後、ＴＣＰ以下の送信処理が行われることになる。
【００４５】
以上の処理において、ＴＣＰの内部処理に関するプロトコル処理を一括して汎用プロセッサ１０１の管理下とすることで、オフロードエンジン１０２の負担を軽減するとともに、限られたオフロードエンジン１０２の資源を有効に利用することも可能である。例えば、ＴＣＰの切断処理は「接続終了」を意味するＦＩＮパケットの交換によって行われる。ＦＩＮパケットを送信または受信したとき、ＴＣＰ用ＰＣＢがオフロードエンジン１０２の管理下にあれば、アプリケーションのオフロード開始・停止命令とは無関係に、汎用プロセッサ１０１の管理下に切り替えを行えばよい。
【００４６】
切断処理を開始した後、ＰＣＢを破棄するまでの期間は一般に長時間に及ぶ可能性がある。しかしながら、この間に大量の通信を行うことは稀であって、汎用プロセッサ１０１側でプロトコル処理を受け持つことによって、オフロードエンジン１０２を大量データの送受信処理に集中されることが可能になる。
【００４７】
（アプリケーションの構成例）
アプリケーションの構成例として、ハイパーテキスト転送プロトコル（ＨＴＴＰ）を用いて映像送信やカメラ制御を行うサーバの動作ついて説明する。ここで、映像送信はオフロードエンジン１０２のＴＣＰを使用し、カメラ制御は汎用プロセッサ１０１のＴＣＰを使用するものとする。ＨＴＴＰの処理は、汎用プロセッサ１０１側のオペレーティングシステム上で動作するアプリケーションによって行うものとし、さらにＨＴＴＰポートは汎用プロセッサ１０１側のＰＣＢとして作成されているものとする。
【００４８】
クライアントからＨＴＴＰ接続要求があると、汎用プロセッサ１０１側のＴＣＰで接続要求が処理され、アプリケーションレベルでＨＴＴＰコネクションが確立され、汎用プロセッサ１０１側に新たにＰＣＢが作成される。
【００４９】
ＨＴＴＰコネクションが確立すると、クライアントはＨＴＴＰリクエストを送信する。送信されるＨＴＴＰリクエストの内容は、例えば、映像送信要求、またはカメラの制御要求である。ＨＴＴＰリクエストが受信されると、対応するＰＣＢに従って汎用プロセッサ１０１のＴＣＰでＨＴＴＰリクエストが処理された後、アプリケーションにＨＴＴＰリクエストが通知される。アプリケーションはＨＴＴＰリクエストに含まれる文字列等の情報によって、要求の内容（例えば、映像送信要求、カメラ制御要求）を特定する。そして、通信負荷の大きい映像送信要求であればオフロード開始命令によってＰＣＢをオフロードエンジン１０２の管理下に切り替える。以下、映像データ送信はオフロードエンジン１０２によって処理され、カメラ制御は汎用プロセッサ１０１によって処理されるようになる。
【００５０】
但し、映像データの生成とオフロードエンジン１０２への供給、カメラ制御要求の解析とカメラ制御コマンドの生成等については、別途既知の手段を用いることによって行われるものとする。
【００５１】
上記の説明において、ＨＴＴＰ以外のプロトコルを用いて映像送信やカメラ制御を行うサーバについても、全く同様に行うことが可能であることはいうまでもない。
【００５２】
更に上記の説明において、プロトコルの種別や処理内容以外に、例えば、通信形態としてピアツーピア方式を用いる場合、通信形態に基づいてＰＣＢの管理元を選択してもよい。ピアツーピアは小規模なＬＡＮ環境で用いられる場合が多く、サーバを介さずに直接通信し合うことから効率が向上する場合がある。ピアツーピア方式を用いる場合、ＰＣＢの管理元を固定的にオフロードエンジン１０２とするようにしてもよい。
【００５３】
ＰＣＢの管理元はアプリケーションが発行するオフロード開始命令とオフロード停止命令によって制御されるが、通信負荷状況に応じて自動的に管理元が切り替えられるように制御することも可能である。
【００５４】
図６は、通信負荷（通信レート）順に並べられたＰＣＢのリストを示す図である。個々のＰＣＢには管理元とともに通信レートとして単位時間当りの通信量が記録されている（図３を参照）。通信レートはＰＣＢを用いて通信を行うたびに更新され、その値が前後のＰＣＢと逆転したときに並び変えが行われる。更にリスト先頭のＰＣＢは負荷最大のＰＣＢ、終端のＰＣＢは負荷最小のＰＣＢとしてＲＡＭ１０４に保持される。
【００５５】
図７は、通信負荷（通信レート）に応じてＰＣＢの管理元を自動的に切り替える手順を示すフローチャートである。この処理手順は、上記の通信レートの値が変化したときに起動されるか、またはタイマーを用いて定期的に起動される。
【００５６】
ステップＳ７０１において、対象とするＰＣＢを負荷最大のＰＣＢとする。ステップＳ７０２において、このＰＣＢの通信レートを所定の閾値１と比較する。通信レートが閾値１を上回っていれば（Ｓ７０２−ＹＥＳ）、ステップＳ７０３において、管理元が汎用プロセッサ（ＣＰＵ）１０１であるかどうかを確認する。管理元が汎用プロセッサ１０１であれば（Ｓ７０３−ＹＥＳ）、ステップＳ７０４において、オフロード開始により管理元をオフロードエンジン１０２に切り替える。
【００５７】
ステップＳ７０５において、次に通信レートの大きなＰＣＢの取り出しを行う。ステップＳ７０６の判定で、ＰＣＢが無ければ（Ｓ７０６−ＹＥＳ）、処理を終了する。一方、ＰＣＢがあれば（Ｓ７０６−ＮＯ）、処理をステップＳ７０２に戻し、ステップＳ７０２以降の処理を繰り返す。
【００５８】
ステップＳ７０２において通信レートが閾値１以下であれば（Ｓ７０２−ＮＯ）、処理をステップＳ７０７に進め、別の閾値２と比較する。ここで閾値２は閾値１以下の値である。
【００５９】
ステップＳ７０７の判定において、ＰＣＢの通信レートが閾値２以下でなければ（Ｓ７０７−ＮＯ）、処理をステップＳ７１０に進めて、次に通信レートの大きいＰＣＢの取り出しを行う。一方、ＰＣＢの通信レートが閾値２以下であれば（Ｓ７０７−ＹＥＳ）、管理元がオフロードエンジン１０２であるかどうかを確認する（ステップＳ７０８）。管理元がオフロードエンジンであれば（Ｓ７０８−ＹＥＳ）、オフロード停止によって管理元を汎用プロセッサ１０１に切り替える（ステップＳ７０９）。続いて、ステップＳ７１０において、次に通信レートの大きなＰＣＢの取り出しを行う。次に通信レートの大きなＰＣＢがあれば（Ｓ７１１−ＮＯ）、処理をステップＳ７０７に戻し、ステップＳ７０７以降の処理を繰り返す。ステップＳ７１１の判定で、ＰＣが無ければ（Ｓ７１１−ＹＥＳ）、処理を終了する。
【００６０】
以上説明したように、本実施形態によれば、データ通信の内容に応じて、汎用プロセッサまたは通信を制御する通信制御プロセッサを選択することで、高い柔軟性及び拡張性を確保しつつ、最適な処理系の選択が可能になる。
【００６１】
（他の実施形態）
なお、本発明の目的は、前述した実施形態の機能を実現するソフトウェアのプログラムコードを記録した記憶媒体を、システムあるいは装置に供給することによっても、達成されることは言うまでもない。また、システムあるいは装置のコンピュータ（またはＣＰＵやＭＰＵ）が記憶媒体に格納されたプログラムコードを読出し実行することによっても、達成されることは言うまでもない。
【００６２】
この場合、記憶媒体から読出されたプログラムコード自体が前述した実施形態の機能を実現することになり、そのプログラムコードを記憶した記憶媒体は本発明を構成することになる。
【００６３】
プログラムコードを供給するための記憶媒体としては、例えば、フレキシブルディスク，ハードディスク，光ディスク，光磁気ディスク，ＣＤ−ＲＯＭ，ＣＤ−Ｒ，不揮発性のメモリカード，ＲＯＭなどを用いることができる。
【００６４】
また、コンピュータが読出したプログラムコードを実行することにより、前述した実施形態の機能が実現される。また、プログラムコードの指示に基づき、コンピュータ上で稼働しているＯＳ（オペレーティングシステム）などが実際の処理の一部または全部を行い、その処理によって前述した実施形態が実現される場合も含まれることは言うまでもない。
【図面の簡単な説明】
【００６５】
【図１】本発明の実施形態に係るデータ通信装置の構成を示すブロック図である。
【図２】プロトコル・コントロール・ブロックの構成を模式的に示す図である。
【図３】ＴＣＰのプロトコル・コントロール・ブロックの内容を示す図である。
【図４】プロトコルスタックの構成例を示す図である。
【図５】オフロード開始命令の処理手順を示すフローチャートである。
【図６】通信レート順に並べられたプロトコル・コントロール・ブロックのリストを示す図である。
【図７】通信負荷に応じてプロトコル・コントロール・ブロックの管理元を自動的に制御する手順を示すフローチャートである。
【図１】
2007142582.tif 000003
【図２】
2007142582.tif 000004
【図３】
2007142582.tif 000005
【図４】
2007142582.tif 000006
【図５】
2007142582.tif 000007
【図６】
2007142582.tif 000008
【図７】
2007142582.tif 000009