JP2008061223A

JP2008061223A - 通信装置及び通信方法

Info

Publication number: JP2008061223A
Application number: JP2007172764A
Authority: JP
Inventors: Eiji Imao; 英司今尾
Original assignee: Canon Inc
Current assignee: Canon Inc
Priority date: 2006-08-04
Filing date: 2007-06-29
Publication date: 2008-03-13

Abstract

【課題】アプリケーション機器のＴＣＰ／ＩＰ通信性能を向上させることを目的とする。
【解決手段】アプリケーション機器１０１は、ネットワーク通信部１０２と、アプリケーションシステム部１０３とを備える。アプリケーションシステム部１０３は、ネットワーク通信部１０２による第１のＴＣＰ／ＩＰプロトコル処理と、該アプリケーションシステム部による第２のＴＣＰ／ＩＰプロトコル処理のいずれかを利用するアプリケーション通信を実行する。ネットワーク通信部１０２は、アプリケーション通信の通信状態によって、第１のＴＣＰ／ＩＰプロトコル処理と第２のＴＣＰ／ＩＰプロトコル処理のいずれでアプリケーション通信を処理するかを切り替える。
【選択図】図１

Description

本発明は、ＴＣＰ／ＩＰプロトコル通信を利用したアプリケーション通信を提供する通信装置及び通信方法に関するものである。

本特許出願において、アプリケーション機器とは、ネットワークに接続され、ＴＣＰ／ＩＰプロトコルを下位プロトコルとするアプリケーション通信を行うことが可能な機器を意味する。

一般にＴＣＰ／ＩＰプロトコル処理は、ＴＣＰ／ＩＰプロトコルスタックと呼ばれるソフトウェアで実現されることが多い。図２は、ＴＣＰ／ＩＰ通信におけるソフトウェア処理の階層モデルを表している。図２の中で、ＴＣＰ／ＩＰプロトコルスタックは、２０１に表す範囲のソフトウェア処理に表される。図２の２０２は、アプリケーション層であり、ＴＣＰ／ＩＰ通信を利用するアプリケーション通信プロトコル処理である。ＨＴＴＰ（ＨｙｐｅｒＴｅｘｔＴｒａｎｓｆｅｒＰｒｏｔｏｃｏｌ）等の標準的に利用されるプロトコルや、アプリケーション毎に独自に定義・実装するプロトコルが多く存在する。

２０３は、アプリケーション層処理が下位層のＴＣＰ／ＩＰプロトコルを利用するためのソフトウェアインタフェース処理を担うソケット層である。ソケットはＴＣＰ／ＩＰ通信の終端点を意味し、ＴＣＰ／ＩＰ通信を行うネットワーク機器のＩＰアドレスと、該機器における各々のＴＣＰ／ＩＰ通信に割り付けるポート番号で識別することができる。ソケットインタフェースは、アプリケーションソフトウェアがＴＣＰ／ＩＰ通信を扱うためのインタフェースとして、多くのＯＳ（オペレーティングシステム）でサポートされている。

２０４はトランスポート層、２０５はネットワーク層のプロトコル処理である。ＴＣＰ／ＩＰでは、トランスポート層にＴＣＰとＵＤＰ（ＵｓｅｒＤａｔａｇｒａｍＰｒｏｔｏｃｏｌ）、ネットワーク層にＩＰｖ４（ＩＰバージョン４）とＩＰｖ６（ＩＰバージョン６）のプロトコルが存在する。２０６はリンク層であり、ネットワークの物理メディアに依存する通信プロトコル処理である。最下層に位置する２０７は、ネットワークの物理メディア制御装置（ＭＡＣ）を制御するためのドライバソフトウェアである。

従来、アプリケーション機器のＴＣＰ／ＩＰ通信は、ＴＣＰ／ＩＰプロトコル処理をソフトウェアで実装し、該機器が内蔵するＣＰＵ（中央演算処理装置）で実行するように実現されてきた。現在でもパソコン等のプロセッサ資源が豊富な機器においては、ＯＳに組み込まれているＴＣＰ／ＩＰプロトコル処理で実現されている。

ところが、近年、アプリケーション機器が送受信するデータ量が増大しており、ＴＣＰ／ＩＰ通信のソフトウェア処理にかかるＣＰＵの処理負荷が非常に高くなっている。例えば、ネットワークカメラやネットワークビデオ配信サーバのような映像サーバ機器、又はネットワークメディアプレイヤーやネットワーク対応ハードディスクレコーダー等のデジタルＡＶ（音響・映像）機器が多く使用されている。そして、これらのネットワークを通じて映像の入出力を行う機器においては、高解像度の画像データをリアルタイムに送受信するための通信処理にかかるプロセッサ負荷が大きくなっている。

ＴＣＰ／ＩＰ通信のためのＣＰＵの処理負荷が高くなってきている状況への対応として、アプリケーション機器のＣＰＵ負荷軽減とＴＣＰ／ＩＰ通信の高スループット化を目的として、ＴＣＰ／ＩＰプロトコル処理をオフロード実行する方法が実現されてきている。ＴＣＰ／ＩＰ通信におけるオフロード処理とは、主に図２の２０８の部分のソフトウェアを、アプリケーション機器のＣＰＵではなく他の処理装置で処理することである。例えば、アプリケーション機器のＣＰＵとは異なるマイクロプロセッサでオフロード処理を行うケースや、ソフトウェアのＴＣＰ／ＩＰ処理における計算量が大きい部分を専用ハードウェア回路で高速処理するケースがある。

特許文献１には、ホスト機器が内蔵する通信処理装置又はホスト機器の外部拡張インタフェースに装着するインテリジェントネットワークインタフェースカード（ＩＮＩＣ）に関する方法が記載されている。この方法では、ハードウェア回路処理によるＴＣＰ／ＩＰプロトコル処理を実現し、ホスト機器のＣＰＵにおけるＴＣＰ／ＩＰプロトコルスタックのソフトウェア処理をオフロードしている。

この従来例において、ＣＰＵで実行する汎用のプロトコルスタックは保持しており、ソフトウェアで実現するＴＣＰ／ＩＰプロトコル処理についてはＣＰＵで実行する仕組みとなっている。つまり、汎用のプロトコルスタックによる低速処理パスと、ハードウェア処理による高速処理パスの２つの処理系を備えている。これは、ハードウェア処理でサポートできない範囲のＴＣＰ／ＩＰプロトコル処理又はハードウェア化コストが見合わないためである。

また、近年では、アプリケーション機器のＣＰＵによるＴＣＰ／ＩＰプロトコル処理を完全に専用ハードウェアによってオフロード化し、ＴＣＰ／ＩＰ通信におけるＣＰＵ資源利用を最小化することもなされている。

特表２００２−５２４００５号公報

しかしながら、ハードウェアリソースのコスト制約が厳しい組み込み機器の場合、ＴＣＰ／ＩＰプロトコル処理をハードウェアでオフロードする形態は、処理可能な通信コネクション数を少数に限定してしまう。よって、アプリケーション機器が同時に多数の通信コネクションを開設して通信できないことが問題となる。

また、このような従来ソフトウェアで処理されてきた図２の２０８に示す範囲の全てのプロトコル処理を、完全に専用ハードウェアでオフロードすることは、ハードウェア回路規模が大きくなる。したがって、ハードウェアリソースの制約が厳しい組み込み機器にはコスト面において不適である。

本願発明は、通信装置のＴＣＰ／ＩＰ通信性能を向上させることを目的とする。また、ＴＣＰ／ＩＰ通信の高スループット化を実現することと、コストに見合った、処理のハードウェア化を他の目的とする。

本発明は前記課題を解決するために、ネットワーク通信部と、アプリケーションシステム部とを備え、ＴＣＰ／ＩＰ（ＴｒａｎｓｍｉｓｓｉｏｎＣｏｎｔｒｏｌＰｒｏｔｏｃｏｌ／ＩｎｔｅｒｎｅｔＰｒｏｔｏｃｏｌ）プロトコルを使用してアプリケーション通信を行う通信装置であって、該アプリケーションシステム部は、該ネットワーク通信部による第１のＴＣＰ／ＩＰプロトコル処理と、該アプリケーションシステム部による第２のＴＣＰ／ＩＰプロトコル処理のいずれかを利用するアプリケーション通信を実行するとともに、前記ネットワーク通信部は、アプリケーション通信の通信状態によって、第１のＴＣＰ／ＩＰプロトコル処理と第２のＴＣＰ／ＩＰプロトコル処理のいずれでアプリケーション通信を処理するかを切り替えることを特徴とする通信装置を提供する。

また、通信相手とのネットワーク通信経路における輻輳等の要因によって、ＴＣＰ／ＩＰプロトコル処理をオフロードするアプリケーション通信が十分な通信性能が得られていない場合があり得る。さらに、オフロード処理するＴＣＰ／ＩＰ通信の同時コネクション数を越えているためにソフトウェア処理で実行しているアプリケーション通信の方が、オフロード処理しているアプリケーション通信よりも高スループットを要求する場合等もある。このような場合にも、アプリケーション通信のＴＣＰ／ＩＰプロトコル処理を効率良くオフロードし、アプリケーション機器全体の通信性能を向上させることができる。

本発明では、ネットワーク通信部による第１のＴＣＰ／ＩＰプロトコル処理と、該アプリケーションシステム部による第２のＴＣＰ／ＩＰプロトコル処理を利用してアプリケーション通信を効率的に実行することが可能となる。

そして、本発明によれば、高性能なＴＣＰ／ＩＰ通信を必要とするアプリケーション通信を優先的にオフロード処理することができる。そして、オフロード処理の効率的な利用が達成され、全体の通信性能を向上させることができる。

（第１の実施形態）
図１は、本発明における通信装置であるアプリケーション機器の実施形態の一例を表すブロック図である。図１の１０１は本実施形態のアプリケーション機器を表す。この通信装置であるアプリケーション機器は、ネットワーク通信部１０２と、アプリケーションシステム部１０３とを備え、ＴＣＰ／ＩＰプロトコルを使用してアプリケーション通信を行う。１０２はネットワーク通信部であり、１０３はアプリケーションシステム部を表す。ネットワーク通信部１０２のローカルバス１０４には、ネットワーク１１８に接続してフレームの送受信を行う通信制御部１０５、ネットワーク通信部１０２内の主記憶装置であるローカルＲＡＭ１０６が接続されている。また、ＴＣＰ／ＩＰプロトコル処理を実行するプロトコル処理部１０７、データのバス転送を行うためのＤＭＡコントローラ１０８、ネットワーク通信部１０２内の制御プログラムを実行する内部制御プロセッサ（ローカルＣＰＵ）１０９が接続している。

アプリケーションシステム部１０３のシステムバス１１１には、ＣＰＵ１１２、システムプログラムが格納されているＲＯＭ１１３が接続されている。また、システムプログラム実行時に使用される主記憶装置であるＲＡＭ１１４が接続されており、ＲＯＭ１１３からＲＡＭ１１４にシステムプログラムが読み込まれ、ＣＰＵ１１２によって実行される。また、同じくシステムバス１１１に接続されている１１５や１１６は、アプリケーション機器の特徴的なアプリケーション機能を実現するために使用されるハードウェア処理装置を表している。アプリケーション機能部Ａ（１１６）、アプリケーション機能部Ｂ（１１５）という名称で示している。また、図１の１１７は、ネットワーク通信部１０２とアプリケーションシステム部１０３に電力供給を制御する電源制御部である。

アプリケーション機器１０１は、通信制御部１０５にネットワーク１１８が物理的に接続される。ネットワーク１１８は、例えばイーサネット（登録商標）のような有線ネットワークであるが、無線ネットワークや、光ファイバーネットワーク等であってもよい。また、ネットワーク１１８は、アプリケーション機器１０１の利用者が遠隔地からＴＣＰ／ＩＰ通信によるアプリケーション通信を行えるように、他ネットワークやインターネットに繋がっていてもよい。

ネットワーク通信部１０２内にある通信制御部１０５は、ネットワーク１１８に対して伝送フレームの送受信を行う機能を持つ。例えばイーサネットの場合、通信制御部１０５はイーサネットのＭＡＣ処理（伝送メディア制御処理）やフレームデータの送受信を行う機能が実装される。

プロトコル処理部１０７は、通信プロトコル処理専用の処理装置であり、汎用的なＴＣＰ／ＩＰプロトコル処理を行う機能を有する。具体的には、ＩＰｖ４、ＩＰｖ６、ＩＣＭＰ、ＵＤＰ、ＴＣＰのパケット作成処理や、送信フロー制御や輻輳制御、通信エラー制御等を行う機能を有する。プロトコル処理部１０７は、特にハードウェア回路（すなわちＬＳＩ）で実装することにより、種々の処理を高速化することができる。このような処理としては、各プロトコルパケットのチェックサムの計算と検証処理や、ＩＰパケットのフラグメント（断片化）とデフラグメント（再組み立て）処理が挙げられる。また、ＴＣＰにおける送信データのセグメント（分割）処理と受信パケットからのデフラグメント（再構成）処理も挙げられる。更に、ＴＣＰパケットの再送処理、ＴＣＰ通信におけるＡＣＫ（肯定応答）処理等、ＴＣＰ／ＩＰプロトコルのソフトウェア処理において計算時間がかかる処理が挙げられる。

プロトコル処理部１０７は、アプリケーションを実行するＣＰＵ１１２のＴＣＰ／ＩＰプロトコル処理をオフロードすることで、アプリケーション通信の高スループット・低遅延を実現することが可能である。

内部制御プロセッサ１０９は、ネットワーク通信部１０２の制御プログラムを実行する。制御プログラムは、ネットワーク通信部１０２内の各装置の動作、装置間のデータフローを制御する。また、アプリケーションシステム部１０３からの制御命令を受信して内部制御を行うものである。ローカルＲＡＭ１０６は、通信制御部１０５やプロトコル処理部１０７や内部制御プロセッサ１０９の処理におけるデータの一時記憶領域に使用される。

また、ネットワーク通信部１０２内には、ローカルバス１０４とアプリケーションシステム部１０３のシステムバス１１１間のデータ転送を可能とするバスブリッジ回路１１０が備えられている。すなわちネットワーク通信部１０２とアプリケーションシステム部１０３は、それぞれのバス回路が相互に接続されており、通信データの入出力がバス転送によって行われる。そして、データのバス転送を行う装置がＤＭＡコントローラ（ＤＭＡＣ）１０８である。また、ＤＭＡコントローラ１０８はネットワーク通信部１０２内の装置間でデータを転送する場合にも使用する。

アプリケーション機器１０１のアプリケーション機能は、アプリケーションシステム部１０３で実現される。ＣＰＵ１１２は、アプリケーション機能部Ａ（１１６）とアプリケーション機能部Ｂ（１１５）の動作制御や、アプリケーション機能の一部であるアプリケーション通信を実行する。アプリケーション通信はＴＣＰ／ＩＰプロトコルを利用した通信である。ＲＡＭ１１４はＣＰＵ１１２によるプログラム実行における一時記憶領域として利用され、またネットワーク通信部１０２やアプリケーション機能部１１５及び１１６が使用する入出力データバッファしても使用される。ＣＰＵ１１２が実行するシステムプログラムは、ＴＣＰ／ＩＰプロトコル処理を行うことが可能である。すなわち、アプリケーションシステム部１０３においては、汎用のＴＣＰ／ＩＰ通信機能を、ソフトウェアで実行する。また、パケットの送受信は、ネットワーク通信部１０２内の通信制御部１０５を経由する。

以上のようなアプリケーション機器１０１の実施構成において、アプリケーション通信におけるＴＣＰ／ＩＰプロトコル処理と送受信データ処理がどのように実行されるかを、図３を示しながら示す。図３は、アプリケーション通信におけるＴＣＰ／ＩＰ通信部分の処理フローである。図３の３０１〜３０９は、それぞれ処理モジュールを表す。

３０１は、アプリケーション通信を行うアプリケーションである。例えばアプリケーションがファイル送信を行うＦＴＰ（ＦｉｌｅＴｒａｎｓｆｅｒＰｒｏｔｏｃｏｌ）サーバの場合は、そのサーバプログラムである。そして、ＦＴＰがＴＣＰ／ＩＰプロトコルを利用するアプリケーションプロトコルとなる。アプリケーション３０１はアプリケーションシステム部１０３（ＣＰＵ１１２）内で実行される。アプリケーション３０１は、通常ソケットインタフェース３０２と高速ソケットインタフェース３０３のいずれかのソケットインタフェースを使用して、アプリケーション通信を行う。

通常ソケットインタフェース３０２を使用する場合、ＴＣＰ／ＩＰプロトコル処理が、ネットワーク通信部１０２によるオフロード処理とアプリケーションシステム部１０３のＣＰＵ１１２によるソフトウェア処理のいずれかによって実行される。本実施形態ではアプリケーション通信毎にどちらの処理で実行するかを動的に切り替える。アプリケーション３０１は、どちらのＴＣＰ／ＩＰプロトコル処理（すなわち、上記のオフロード処理、または、ソフトウェア処理）が実行されているかを識別する必要がない。

一方、アプリケーション３０１が高速ソケットインタフェース３０３を利用してアプリケーション通信を実行する場合は、優先的にネットワーク通信部１０２でオフロード処理するＴＣＰ／ＩＰ通信を利用する。したがって、特定のアプリケーション通信のＴＣＰ／ＩＰプロトコル処理を常に高速処理して優先的に高スループット・低遅延で通信を実行したい場合、高速ソケットインタフェース３０３を使用すればよい。

上記３０２、３０３のそれぞれのソケットインタフェースは、アプリケーションシステム部１０３で実行されるソフトウェア処理である。

図３の３０４はソケット層の処理であり、３０５はＴＣＰ／ＩＰプロトコル及びリンク層プロトコル処理である。３０４と３０５は共にアプリケーションシステム部１０３のＣＰＵ１１２で実行するソフトウェア処理である。通常ソケットインタフェース３０２を介して３０４の処理が実行される場合は、ＴＣＰ／ＩＰプロトコル処理をソフトウェアで実行する。３０４は通常ソケットインタフェース３０２を利用するアプリケーション３０１の通信ソケット処理を行う。また、各ソケットにおいて送受信データ量を計測する。計測処理は、全てのアプリケーション通信について、一定時間毎で送受信バッファ（ＲＡＭ１１４内）の入出力データ量を計算する。

次に、３０５はＴＣＰ／ＩＰ処理であり、トランスポート層のプロトコルであるＴＣＰまたはＵＤＰ、ネットワーク層のプロトコルであるＩＰのプロトコル処理を行う。また、トランスポート層のプロトコルにＴＣＰを使用する通信では、ＴＣＰコネクションの状態を監視する。ＴＣＰコネクションの状態とは、ＲＦＣ７９３に記載であるＴＣＰ通信の進行状態のことである。また、３０５のＴＣＰ／ＩＰ処理は、一定時間毎に各々のアプリケーション通信においてパケットの送受信回数をカウントする。さらに３０５ではリンク層のプロトコル処理であり、有線ＬＡＮ（例えばＩＥＥＥ８０２．３）や無線ＬＡＮ（例えばＩＥＥＥ８０２．１１ａ／ｂ／ｇ）のプロトコルのフレーム送受信処理を行う。

図３の３０６から３０９はネットワーク通信部１０２の処理を表し、３０６から３０８はプロトコル処理部１０７における処理である。通常ソケットインタフェース３０２を介して３０６の処理が実行されるときは、アプリケーション通信のＴＣＰ／ＩＰプロトコル処理をネットワーク通信部１０２で実行するように切り替えられている場合である。

３０６はソケット層処理であり、上記の３０４と同機能を有するが、３０４のソケット層処理はＣＰＵ１１２によるソフトウェア処理であるのに対し、３０６は、プロトコル処理部１０７によるハードウェア回路処理であり、高速な処理を可能としている。同様に３０６はリンク層のプロトコル処理であり、上記の３０５の処理と同機能を有し、プロトコル処理部１０７による処理である。

３０８は、受信パケットの解析及び送受信パケットのデータパスを切り替える処理である。パケットの送信の場合、３０５ではＲＡＭ１１４上に送信フレームが作成され、３０７ではローカルＲＡＭ１０６上に送信フレームが作成される。したがって３０８は、３０５と３０７のどちらの送信であるかによって、フレームの読み出し位置を変更して通信制御部１０５にデータ転送を行う。

一方、パケットの受信の場合は、通信制御部１０５から受信したフレームのデータ構造を解析する。受信フレームのリンク層、ネットワーク層、トランスポート層のプロトコルヘッダ構造を読み出して、各層のプロトコル種類と、送信元のＩＰアドレスと、送信元・宛て先のポート番号を取得する。そして、取得した情報から、該フレームデータを３０５か３０７のいずれの受信処理であるか判別する。また、この判別と共に、３０５で受信フレームデータを処理するバッファのあるＲＡＭ１１４か、３０７で受信フレームデータを処理するバッファのあるローカルＲＡＭ１０６かのいずれかに転送する。

３０９は通信制御部１０５の通信制御処理であり、ネットワーク１１８とのデータ送受信制御を実行する。

図３の３１０はソケット切り替え制御であり、アプリケーション機器システム全体のＴＣＰ／ＩＰ通信の処理リソースの管理を行う処理である。ネットワーク通信部１０２が処理可能な通信数の割り当てを管理する。そして、アプリケーション通信毎に、前述の通常ソケットインタフェース３０２から、３０４と３０６のどちらのソケット層処理を行うかを判定し、その切り替えを動的に行う。尚、本実施形態において、３１０はネットワーク通信部１０２内の内部制御プロセッサ１０９によって実行するものとして説明する。しかしながら、プロトコル処理部１０７でハードウェア処理するものであってもよい。

３１０では、ソケット層処理の切り替えの判定に必要な情報を、３０４、３０５、３０６、３０７から受け取る。前述のように、３０４と３０６のソケット層処理は、各通信において、一定時間毎で送受信バッファの入出力データ量を計算する。また、３０５と３０７のＴＣＰ／ＩＰ処理では、一定時間毎で各ＴＣＰ／ＩＰ通信の送受信パケット数をカウントする。さらにＴＣＰを使用した通信の場合、ＴＣＰコネクションの状態を監視する。これらの結果の情報はソケット切り替え制御３１０に送られる。ソケット切り替え制御３１０は、これらの情報を受信して、アプリケーション通信が３０４と３０６のどちらのソケット層処理を実行するかの切り替えの判定及び切り替えを行う。

次に、ソケット切り替え制御３１０の上記切り替え判定について、図４と図５を参照しながら手順を説明する。図４は、アプリケーション通信のＴＣＰ／ＩＰプロトコル処理をネットワーク通信部１０２とアプリケーションシステム部１０３のどちらで実行するかの判定手順を示したフローチャートである。また、図５は、図４のＳ４０２の内容を別チャートで示した図である。

切り替え判定は、Ｓ４０１から始まり、Ｓ４０２では、全てのアプリケーション通信において、ＴＣＰ／ＩＰプロトコル処理を実行する優先順位を、ネットワーク通信部１０２で決定する。

Ｓ４０３からＳ４０９は、全てのアプリケーション通信を対象とする繰り返しのステップであり、各アプリケーション通信のＴＣＰ／ＩＰプロトコル処理をネットワーク通信部１０２が実行するか、又はアプリケーションシステム部１０３で実行するかを決定する。

尚、繰り返しのステップはＳ４０２で決定した優先順位の順番で実行する。繰り返しステップ中の最初のＳ４０４では、ネットワーク通信部１０２が処理する通信数が限界数（所定数）以内であるかを調べ、そうであるならＳ４０５へ進み、そうでないならばＳ４０８に進む。

Ｓ４０５では、繰り返しステップの現在の対象であるアプリケーション通信が、ＴＣＰを利用した通信であるかを調べる。ＴＣＰ通信であるならばＳ４０６においてＴＣＰコネクションの状態を調べる。

該ＴＣＰコネクションの状態が、ＥＳＴＡＢＬＩＳＨＥＤであるならば、Ｓ４０７において、該アプリケーション通信は、ネットワーク通信部１０２によるＴＣＰ／ＩＰプロトコル処理対象として決定する。ネットワーク通信部１０２によるＴＣＰ／ＩＰプロトコル処理は、例えば、ネットワーク通信部１０２が内蔵する専用ハードウェア回路（通信制御部１０５、プロトコル処理部１０７など）での処理である。又は、ネットワーク通信部１０２によるＴＣＰ／ＩＰプロトコル処理は、例えば、ネットワーク通信部１０２が内蔵する内部制御プロセッサ１０９によるソフトウェア処理と、ハードウェア回路による計算処理を組み合わせた処理である。このハードウェア回路は、通信制御部１０５、プロトコル処理部１０７などである。

また、Ｓ４０６において、ＴＣＰではない通信の場合（すなわち主にＵＤＰ通信の場合）は、Ｓ４０８に進む。

Ｓ４０８は、該アプリケーション通信をアプリケーションシステム部１０３のＴＣＰ／ＩＰプロトコル処理対象として決定する。アプリケーションシステム部１０３のＴＣＰ／ＩＰプロトコル処理は、アプリケーションシステム部１０３内のプロセッサ（ＣＰＵ１１２）で実行するソフトウェア処理である。

Ｓ４０３からＳ４０９の繰り返しステップによって、全てのアプリケーション通信のＴＣＰ／ＩＰプロトコル処理が、ネットワーク通信部１０２とアプリケーションシステム部１０３のいずれで実行されるかを決定する。

以上のように、ＴＣＰ／ＩＰ通信の同時通信数が、ＴＣＰ／ＩＰプロトコル処理をオフロードできる限界数までは、優先的にＴＣＰ／ＩＰプロトコル処理のオフロード手段を使用するようにする。また、該限界数を超えるＴＣＰ／ＩＰ通信は、ソフトウェア処理によって実行する。

なお、本実施形態では、アプリケーション通信の通信状態によって、ネットワーク通信部１０２によるＴＣＰ／ＩＰプロトコル処理又はアプリケーションシステム部１０３によるＴＣＰ／ＩＰプロトコル処理のいずれでアプリケーション通信を処理するかを切り替える。例えば、ＴＣＰコネクションを確立するまでのネゴシエーション中であるＴＣＰ状態や、ＴＣＰコネクションの終了段階であるＴＣＰ状態においては、アプリケーションシステム部１０３によるＴＣＰ／ＩＰプロトコル処理を実行する。

次に、Ｓ４０２のステップについて、図５を参照して説明する。

Ｓ４０２は、前述のように全てのアプリケーション通信において、ＴＣＰ／ＩＰプロトコル処理を実行する優先順位を、ネットワーク通信部１０２で決定する。

図５のＳ５０１から始まり、Ｓ５０２において優先順位付けの基準が通信データ量であるか、通信パケット数であるかを調べる。どちらの基準とするかは、アプリケーション機器のシステムであらかじめ静的に設定されてもよいし、又は運用途中で設定変更してもよいものである。

Ｓ５０２で通信データ量を基準とする場合はＳ５０３に進み、通信パケット数を基準とする場合はＳ５０４に進む。

Ｓ５０３では、３０４と３０６のそれぞれのソケット層処理におけるソケットバッファの入出力データ量計測処理の結果を元にして、データ量の多い通信の優先順位が高くなるように優先順位付けを行う。一方、Ｓ５０４では、３０５と３０７の各々のＴＣＰ／ＩＰ処理において、パケットの送受信数をカウントした結果を元にして、パケット数の多い通信の優先順位が高くなるように優先順位付けを行う。

次に、Ｓ５０５において、Ｓ５０３またはＳ５０４で作成した優先順位において、高速ソケットインタフェース３０３を利用するアプリケーション通信が優先順位の上位となるようにする。そして、Ｓ５０６で優先順位決定の手順の終了となる。

このような手順でＳ４０２のステップは実行される。

ソケット切り替え制御３１０は、以上の切り替え判定の結果に則り、アプリケーション通信のＴＣＰ／ＩＰプロトコル処理をネットワーク通信部１０２で実行するならば、判定対象のアプリケーション通信をソケット層処理モジュール３０６で処理する。逆に、アプリケーションシステム部１０３で実行するならば、判定対象のアプリケーション通信をソケット層処理モジュール３０４で処理する。ソケット切り替え制御３１０の実行は、一定時間毎に定期的に実行される。なお、本実施形態では、アプリケーション通信の通信状態によって、例えば、アプリケーション通信に一定数以上の増減が生じたタイミングにおいても、実行される。

このようにして、アプリケーション通信のＴＣＰ／ＩＰプロトコル処理を、ネットワーク通信部１０２によるオフロード処理と、アプリケーションシステム部１０３内のＣＰＵ１１２によるソフトウェア処理にいずれかに、自動的に切り替えることになる。

以上、本発明の第１の実施形態を説明した。本実施形態では、同時通信数がオフロード可能な通信数よりも多いときに、ＴＣＰ／ＩＰプロトコル処理をソフトウェア処理で実行する。したがって、同時に多数の通信コネクションを開設して通信できる。また、アプリケーション機器１０１は、高性能なＴＣＰ／ＩＰ通信を必要とするアプリケーション通信を、優先的にネットワーク通信部１０２でオフロード処理するように切り替えられるので、機器全体の通信性能を向上させることが可能となる。

（第２の実施形態）
次に、本発明の第２の実施形態について説明する。ネットワークカメラは、構内ＬＡＮ等に接続されて、ネットワークを介して撮影映像を配信するアプリケーション機器である。以下、本発明の実施形態の一例として、アプリケーション機器がネットワークカメラである場合について説明する。

本実施形態のネットワークカメラは、撮影静止画データ又は撮影動画データをリアルタイムに配信する機能や、ネットワークカメラと離れた場所にいる利用者が撮影開始や撮影停止、パン／チルト／ズーム等の遠隔撮影操作を行う機能を備える。また、撮影した静止画や動画を蓄積するための二次記憶装置を備えており、以前に撮影した静止画や動画データを転送する機能を備える。さらに、組込みＷｅｂサーバを備えており、ＰＣや携帯電話等のＷｅｂブラウザから、ネットワークカメラの撮影画像の表示や、管理者による撮影設定を行うことができる機能を備える。このような各機能は全てネットワークを介した通信によって、遠隔から利用されるものである。

図６は、ネットワークカメラにおいて本発明の実施形態の一例を示すブロック図である。本実施例のネットワークカメラのシステム構成は、第１の実施形態に記載のアプリケーション機器に準ずるものである。したがって図６は図１に依拠したブロック図になっている。図６において、図１と共通の構成要素には、共通の番号を付す。

図６の６０１は本実施形態のネットワークカメラを表す。６０３はアプリケーションシステム部１０３に相当するカメラシステム部である。カメラシステム部６０３は、ネットワーク通信部１０２を利用して数々のアプリケーション通信を実行する。

６１５は二次記憶装置を表し、例えばハードディスク装置、又はＣＦカードやＳＤカード等の記憶容量が大きな不揮発性メモリ装置である。二次記憶装置６１５はシステムバス１１１に接続されており、主にネットワークカメラ６０１が撮影する静止画や動画データをファイル保存するために使用する。６１６はネットワークカメラ６０１の撮像部であり、レンズ、ＣＣＤ（光電変換素子）、ＣＣＤ制御部等を含む。撮像部６１６では、レンズを通して投影される撮像を、ＣＣＤによってアナログ電気信号に変換する。また、アナログ電気信号に変換された撮像画像から、ノイズ除去等の処理を施し、デジタルデータに変換するＡ／Ｄ変換を行う画像処理部を備えている。

６１７はエンコーダであり、非圧縮デジタル画像データのエンコード（圧縮符号化）を実行する。撮像部６１６とエンコーダ６１７はシステムバス１１１に接続されており、撮像部６１６が一定の周期で非圧縮デジタル画像データを出力し、エンコーダ６１７がその画像データをエンコードすることにより、静止画データや動画データストリームを生成する。本実施形態におけるエンコーダ６１７は、画像データの高速なエンコード処理を実現するハードウェア装置であり、ＪＰＥＧやＭＰＥＧ４を含む複数のエンコード形式に対応している。電源制御部１１７は、カメラシステム部６０３内の１１１から１１４、６１５から６１７までの各装置に対して、電源投入と、リセット、及び、カメラシステム部６０３全体が保持データの損失なく電源をオフにするための停止処理を開始する制御等を行う。

ＣＰＵ１１２は、カメラシステム部６０３内の各装置の制御や、カメラアプリケーションを実行する。ＲＡＭ１１４は、ＣＰＵ１１２によるプログラム実行のために使用する主記憶装置であり、ネットワーク通信部１０２や、カメラシステム部６０３の撮像部６１６やエンコーダ６１７が使用する入出力データ領域としても使用される。ネットワークカメラ６０１のカメラ機能は、カメラシステム部６０３で実現される。

また、ＣＰＵ１１２で実行されるシステムプログラムは、アプリケーションの機能の一部であるアプリケーション通信を行う。例えば撮影映像のストリーミング配信の場合、撮像部６１６が撮影した非圧縮画像フレームデータをエンコーダ６１７でエンコードして、圧縮画像データをＲＡＭ１１４に出力する。ＣＰＵ１１２で実行するシステムプログラムは、ＲＡＭ１１４上の圧縮画像データからストリーミングプロトコルで送信可能な形式のストリーミングデータを作成し、ＴＣＰ／ＩＰ通信を利用した送信を行う。ストリーミングデータの送信では、１人以上の受信相手に対して別々にＴＣＰ／ＩＰ通信処理を行う。

図７は、本実施形態のアプリケーション通信処理を階層モデルとして示した図である。図７において、上位層の処理は下位層の処理に依存すること又は下位層の処理を利用することを表す。

最上位階層はネットワークカメラ６０１のシステムプログラムによるアプリケーション通信のアプリケーションプロトコル通信処理７０１である。アプリケーションプロトコル通信処理７０１は通常ソケットインタフェース７０２又は高速ソケットインタフェース７０３を介して下位通信処理に依存する。７０２と７０３はＣＰＵ１１２で実行するシステムプログラムにおけるアプリケーションプログラムインタフェース（ＡＰＩ）であり、具体的には一般的な通信ソケットインタフェース互換のプログラムインタフェースである。通常ソケットインタフェース７０２と高速ソケットインタフェース７０３は、利用する下位階層処理が異なる。

図７の７０４から７０６は、ＣＰＵ１１２で実行するシステムプログラムの一部として実装されるソフトウェア処理である。７０４は通信ソケット層の処理を表す。７０５はＴＣＰ／ＩＰ処理を行うソフトウェアであり、ＴＣＰ、ＵＤＰ、ＩＰ等のＴＣＰ／ＩＰプロトコル処理を実行する。７０６はイーサネットプロトコル処理であり、ネットワークの物理メディアがＩＥＥＥ８０２．３規格に準拠しているネットワークに対して、伝送フレームを作成・送受信するソフトウェア処理である。

図７の７０７から７０９はそれぞれ、７０４から７０６と同等の処理を表す。即ち、７０７は通信ソケット層の処理、７０８はＴＣＰ／ＩＰプロトコル処理、７０９はイーサネットプロトコル処理である。７０７から７０９の通信処理は、プロトコル処理部１０７の機能であり、ハードウェア回路によって高速に処理される。７１０はイーサネットの通信制御処理であり、前述した通信制御部１０５で実行される。

図７において、通常ソケットインタフェース７０２を利用するアプリケーション通信は、依存する下位のＴＣＰ／ＩＰ通信処理が、７０４から７０６のＴＣＰ／ＩＰ通信処理と、７０７から７０９のＴＣＰ／ＩＰ通信処理のいずれかで実行されることを示す。そして、高速ソケットインタフェース７０３の場合は、下位のＴＣＰ／ＩＰ通信処理が７０７から７０９のプロトコル処理部１０７の処理であることを表している。

本実施形態のネットワークカメラ６０１において、アプリケーション通信が利用するＴＣＰ／ＩＰ通信のプロトコル処理は、ＣＰＵ１１２で実行するソフトウェアによる処理と、プロトコル処理部１０７のハードウェアによる処理の２つの処理系が存在する。両者の違いは、特に処理速度である。プロトコル処理部１０７で実行するＴＣＰ／ＩＰプロトコル処理は、高スループットで低遅延であるＴＣＰ／ＩＰ通信を実現するものである。そして、本実施形態において、通常ソケットインタフェース７０２を利用するアプリケーション通信が、通常ソケットインタフェース７０２から利用するＴＣＰ／ＩＰ通信処理が、いずれかの処理系に自動的に切り替えられることになる。該切り替えの仕組み、及び切り替えについては前記第１の実施形態と同様である。

ネットワークカメラ６０１では、撮影映像のリアルタイムストリーミング配信において、高帯域且つ低遅延であるＴＣＰ／ＩＰ通信を必要とする。本実施形態では、このような通信を優先的にネットワーク通信部１０２でオフロード処理するように切り替えるので、ネットワークカメラの映像配信性能を向上させることが可能である。

（第３の実施形態）
次に、本発明の第３の実施形態について説明する。本実施形態のアプリケーション機器１０１の構成は、図１と共通である。本実施形態において、アプリケーション通信におけるＴＣＰ／ＩＰプロトコル処理と送受信データ処理がどのように実行されるかを説明する。図８は、アプリケーション通信におけるＴＣＰ／ＩＰ通信処理のデータフローを表している。

図８の１３０１は、アプリケーション機器１０１のＴＣＰ／ＩＰ通信処理の全体を表しており、１３０２〜１３０９の処理モジュールで構成される。なお、図８の１３０２〜１３０９において、アプリケーションシステム部１０３処理として破線で囲まれた処理モジュールについては、ソフトウェア処理モジュールであり、ＣＰＵ１１２で実行する処理である。一方、ネットワーク通信部１０２の処理として破線で囲まれた処理モジュールについては、ハードウェア処理又はソフトウェアとハードウェアの両処理である。すなわち、これらの処理モジュールは、プロトコル処理部１０７、ＤＭＡコントローラ１０８、内部制御プロセッサ１０９で実行する処理である。

図８の１３０２は、アプリケーション通信を行うアプリケーションを示している。例えばアプリケーションがファイル送信を行うＦＴＰ（ＦｉｌｅＴｒａｎｓｆｅｒＰｒｏｔｏｃｏｌ）サーバの場合は、そのサーバプログラムである。そして、ＦＴＰがＴＣＰ／ＩＰプロトコルを利用するアプリケーション層のプロトコルとなる。アプリケーション１３０２はアプリケーションシステム部１０３内で実行される。アプリケーション１３０２は、ソケットインタフェース１３０３を使用して、アプリケーション通信を行う。

ソケットインタフェース１３０３は、アプリケーション通信を行うソフトウェアが、データ送受信を行うためのインタフェースであり、アプリケーションシステム部１０３で実行されるソフトウェア処理モジュールである。ソケットＡＰＩともよばれる。ソケットインタフェース１３０３を使用する通信において、ＴＣＰ／ＩＰプロトコル処理は、ネットワーク通信部１０２によるオフロード処理と、アプリケーションシステム部１０３のＣＰＵ１１２によるソフトウェア処理のいずれかによって実行される。

図９の４０１の表は、本実施形態において、ＴＣＰ／ＩＰのプロトコル毎に、プロトコル処理を実行する処理部と、その主な処理内容を示した表である。この表に見られるように、プロトコル別にネットワーク通信部１０２とアプリケーションシステム部１０３の両方で、アプリケーション機器１０１のＴＣＰ／ＩＰ通信処理を実行する。本実施形態においては、アプリケーション通信の状態によってどちらの処理で実行するかを動的に切り替えている。アプリケーション１３０２は、どちらのＴＣＰ／ＩＰプロトコル処理が実行されているかを関知する必要がない。

図８の１３０４はソケット層の処理モジュールであり、１３０５はＴＣＰ／ＩＰプロトコル処理を行うモジュールである。１３０４と１３０５は共にアプリケーションシステム部１０３のＣＰＵ１１２で実行するソフトウェア処理モジュールである。

アプリケーション通信において１３０４及び１３０５の処理が実行される場合は、ＴＣＰを利用した通信であって、且つ、以下の場合である。すなわち、ＴＣＰプロトコル処理を１３０５でソフトウェア実行するように切り替えられている場合と、ＵＤＰを利用した通信である場合と、ＴＣＰ以外のプロトコルを利用した通信である場合である。

ＴＣＰ通信において、１３０５のＴＣＰプロトコル処理が行われるのは、図９の４０２の破線囲みで示すように、ＴＣＰコネクション確立時の通信と、ＴＣＰコネクション終了時の通信が実行されるときである。すなわち、本実施形において、ＴＣＰコネクションの確立フェーズと終了フェーズの通信処理は、アプリケーションシステム部１０３のＣＰＵ１１２で実行している。

１３０４は、アプリケーション通信のソケット層処理を行い、ソケットインタフェース１３０３を介してアプリケーションの送受信データの授受を実行する。また、ＴＣＰ通信処理が１３０５で処理されるときには、１３０４と１３０５間で通信データを授受する。１３０４でソケット層処理を実行するＴＣＰ通信では、各ＴＣＰソケットにおいて送受信するデータ量を計測する。この計測処理は、全てのアプリケーション通信について、一定時間毎でソケットの送受信バッファ（ＲＡＭ１１４内）の入出力データ量を計算し、１３１０のソケット切り替え処理モジュールに対して結果の通知を行う。

一方、アプリケーション通信がＵＤＰを利用した通信の場合は、１３０４でソケット層処理を行う。また、ＵＤＰパケット送信処理は、ＴＣＰ／ＩＰプロトコル処理モジュール１３０５において実行される。ＵＤＰパケットの受信処理については後述するが、処理モジュール１３０７において実行している。そのため、１３０４は、１３０７との間でＵＤＰパケットデータの授受を行う。

ＴＣＰ／ＩＰプロトコル処理モジュール１３０５は、主にＴＣＰ通信におけるＴＣＰプロトコル処理、及びＵＤＰ通信の送信処理、又はＴＣＰやＵＤＰ以外のＩＰ上位プロトコル処理を行う。また、ＩＣＭＰやＡＲＰ等、アプリケーション通信で直接的に使用しないが、ＴＣＰ／ＩＰ通信を行うために必要なプロトコルについても処理を行う。

さらに、１３０５では、ＴＣＰ通信のコネクション確立・終了フェーズにおける、ＴＣＰコネクションの状態遷移を監視する。ＴＣＰコネクションの状態とは、ＲＦＣ７９３に記載であるＴＣＰ通信の進行状態のことである。一般に、コネクション確立時のフェーズにおいてＴＣＰコネクションの状態は、ＳＹＮ＿ＳＥＮＴ、ＳＹＮ＿ＲＣＶＤと呼ばれる状態である。そして、コネクション終了時のフェーズにおいては、ＦＩＮ＿ＷＡＩＴ１、ＦＩＮ＿ＷＡＩＴ２、ＬＡＳＴ＿ＡＣＫ、ＣＬＯＳＩＮＧ、ＴＩＭＥ＿ＷＡＩＴ、ＣＬＯＳＥ＿ＷＡＩＴ、ＬＡＳＴ＿ＡＣＫと呼ばれる状態である。また、ＴＣＰソケットにコネクションが無い状態は、ＣＬＯＳＥＤとよばれる。すなわち、アプリケーション通信（ＴＣＰ通信）が、以上のようなＴＣＰコネクション状態においては、ＴＣＰプロトコル処理をＴＣＰ／ＩＰプロトコル処理モジュール１３０５で実行する。

また、１３０５では、ＥＳＴＡＢＬＩＳＨＥＤ状態の全てのＴＣＰコネクションにおいては、一定時間毎で送受信するＴＣＰパケット数を計測し、ソケット切り替え処理モジュール１３１０に通知を行う。

図８の１３０６から１３０９はネットワーク通信部１０２の処理モジュールを表し、１３０６から１３０８は１０７のプロトコル処理部において実行される。

１３０６はＴＣＰソケット層処理モジュールである。前述のソケット層処理モジュール１３０４はＣＰＵ１１２によるソフトウェア処理であるのに対し、ＴＣＰソケット層処理モジュール１３０６は、プロトコル処理部１０７による処理であり、高速な処理を可能としている。このＴＣＰソケット層処理は、アプリケーション通信がＴＣＰを利用した通信であって、且つＴＣＰコネクションが確立中のフェーズの場合に、実行される。このときＴＣＰコネクションは、ＥＳＴＡＢＬＩＳＨＥＤとよばれる状態である。１３０６はソケットインタフェース１３０３を介してアプリケーション通信の送受信データの授受を実行する。そして、１３０６でソケット層処理を実行するＴＣＰソケットにおいて送受信データ量を計測する。計測処理は、全てのアプリケーション通信について、一定時間毎でソケットの送受信バッファ（ローカルＲＡＭ１０６内）の入出力データ量を計算し、ソケット切り替え処理モジュール１３１０に対して結果の通知を行う。

１３０７では、主にＥＳＴＡＢＬＩＳＨＥＤ状態のＴＣＰプロトコル処理、またはＵＤＰパケット受信時のＵＤＰプロトコル処理を行う。また、上位層のソケット処理モジュールである１３０４又は１３０６のいずれかと通信データの授受を行う。ただし、１３０４とのデータ授受はＵＤＰパケットの受信の場合だけであり、１３０６とのデータ授受は、ＴＣＰ通信の場合のみである。アプリケーション通信の送信時は、１３０６から送信データを受け取り、逆に受信時には、１３０６に受信データを渡す。

また、１３０７で処理するＥＳＴＡＢＬＩＳＨＥＤ状態のＴＣＰ通信は、一定時間毎で送受信するＴＣＰパケット数を計測し、ソケット切り替え処理モジュール１３１０に通知を行う。

１３０８は、ネットワーク通信部１０２内で処理される処理モジュールである。１３０７のＴＣＰ処理モジュールでＴＣＰパケット送信する際に、１３０８においてＩＰヘッダを作成・付与してＩＰパケット作成を行う。ＩＰパケットの受信時には、受信パケットのヘッダ構造を解析し、１３０５か１３０７のいずれかの処理モジュールに受信パケットデータを渡す。

この受信パケットの解析処理では、通信制御部１０５から受信したフレームのデータ構造を識別し、ネットワーク層、トランスポート層のプロトコルヘッダ部分を読み出す。フレームデータがＩＰパケットを含むならば、上位のプロトコル種類と、送信先・送信元のＩＰアドレスを取得し、さらに上位プロトコルにＵＤＰやＴＣＰパケットを含むならば送信元・送信先に指定されたポート番号を取得する。そして、取得した情報から、所定の判定処理により、該フレームデータを１３０５か１３０７のどちらの受信処理であるか判定する。それとともに、１３０５で受信フレームデータを処理するためのバッファがあるＲＡＭ１１４か、１３０７で受信フレームデータを処理するバッファのあるローカルＲＡＭ１０６かのいずれかに転送する。

なお、ＡＲＰフレームのようなＩＰパケット形式のデータを含まないフレームデータは、ＴＣＰ／ＩＰプロトコル処理モジュール１３０５によって送受信処理が実行される。受信パケット解析処理によって、このようなフレームデータを受信した場合は、アプリケーションシステム部に、フレームデータを渡すことになる。

図８の１３０９の処理は、ネットワーク通信のリンク層の処理である。有線ＬＡＮ（例えばＩＥＥＥ８０２．３）や無線ＬＡＮ（例えばＩＥＥＥ８０２．１１ａ／ｂ／ｇ）等のプロトコルのフレーム送受信を行う。さらに、通信制御部１０５の制御を実行して、ネットワーク１１８に対してフレームデータを送受信する。

図８の１３１０はソケット切り替え処理モジュールであり、アプリケーション機器システム全体におけるＴＣＰ／ＩＰ通信の処理リソースの管理を行う。ネットワーク通信部が処理可能な通信数の割り当てを管理する。尚、本実施形態において、１３１０はネットワーク通信部１０２内の内部制御プロセッサ１０９によって実行するものとして説明する。しかしながら、プロトコル処理部１０７でハードウェア処理するものであってもよい。

１３１０では、ソケットインタフェース１３０３を利用するアプリケーション通信毎に、アプリケーションシステム部とネットワーク通信部のどちらのソケット層処理を行うべきかを判定し、その切り替え処理を行う。ソケット層処理の切り替えの判定に必要な情報は、１３０４、１３０５、１３０６、１３０７から通知される。アプリケーション通信がＴＣＰを下位プロトコルとする場合、１３０５と１３０７における処理において、ＴＣＰコネクションの状態を監視し、状態の変化をソケット切り替え処理１３１０に通知する。この通知を基に、ソケット切り替え処理１３１０は、各アプリケーション通信のＴＣＰプロトコル処理について、１３０４と１３０５のアプリケーションシステム部１０３による処理と、１３０６と１３０７のネットワーク通信部１０２による処理を切り替える。さらに、ネットワーク通信部１０２で通信処理が可能ＴＣＰコネクション数の管理を行う。この管理では、ネットワーク通信部１０２の１３０６と１３０７でＴＣＰプロトコル処理を実行している全てのＴＣＰソケット数について、あらかじめ決められた上限数を超えないように制限する。

次に、ＴＣＰ通信において、ネットワーク通信部１０２とアプリケーションシステム部１０３のＴＣＰプロトコル処理の切り替えについて、説明する。

図１０はＴＣＰ通信フローの一例を簡易に表した図である。図１０では、クライアント５０１と、サーバ５０２が、ＴＣＰコネクションを確立し、データの送受信を実行し、コネクションを終了するまでの通信を示している。また、クライアント５０１がＴＣＰコネクションの開設を要求する側として表現している。

クライアント５０１からＴＣＰコネクション確立要求５０３が送信され、サーバ５０２はこの要求を受信すると、確立要求に対する確認応答として（ＳＹＮ，ＡＣＫ）５０４を返信する。コネクション確立要求５０３は、ＴＣＰパケットヘッダの制御ビット（ＣｏｎｔｒｏｌＢｉｔｓ）フィールドにおいて、ＳＹＮビットが１であるパケットである。したがって、単純にＳＹＮパケットともよばれる。確立要求に対する確認応答は、同じくＴＣＰパケットヘッダの制御ビットフィールドにおいて、ＳＹＮとＡＣＫビットが１であるパケットである。クライアント５０１は、（ＳＹＮ，ＡＣＫ）パケット５０４を受信すると、確認応答（ＡＣＫ）５０５を送信する。この３つのＴＣＰパケット送受信のフェーズ５１２は、ＴＣＰの一般的なコネクション確立時の通信であり、３ウェイハンドシェイクとよばれる。

クライアント５０１とサーバ５０２の間でＴＣＰコネクションが確立中の場合において、両者はアプリケーションデータの送受信を行う。図の５０６〜５０８の矢印で、コネクション確立中のフェーズ５１３のデータ送受信を表している。

そして、クライアント５０１から、コネクション終了を要求するパケット５０９を送信する。パケット５０９は、ＴＣＰパケットヘッダの制御ビットフィールドにおいて、ＦＩＮビットが１であるパケットである。サーバ５０２は、コネクション終了要求としてパケット５０９を受信すると、サーバ５０２からも、クライアント５０１からの終了要求に対する確認応答とサーバ５０２側の終了要求を意味するＴＣＰパケット５１０を送信する。クライアント５０１は、（ＦＩＮ，ＡＣＫ）パケット５１０を受信すると、確認応答５１１を送信する。このような５１４の範囲の通信手順により、コネクション終了フェーズの通信が行われる。

本実施形態では、図１０のＴＣＰ通信フローの例で示したコネクション確立時のフェーズ５１２と、コネクション終了フェーズ５１４のＴＣＰプロトコル処理を、アプリケーションシステム部１０３で実行する。また、コネクション確立中フェーズ５１３では、ネットワーク通信部１０２又はアプリケーションシステム部１０３で実行する。つまり、ＴＣＰを利用するアプリケーション通信は、ＴＣＰコネクションの状態に応じて、ＴＣＰプロトコル処理を実行する処理部が切り替えることを行う。

図１０のＴＣＰ通信フローを例に挙げ、ＴＣＰ通信処理が、ネットワーク通信部１０２とアプリケーションシステム部１０３によって、どのように実行され、またＴＣＰコネクション毎のＴＣＰプロトコル処理がどのように切り替わるかを、説明する。この説明では、図１１から図２０の図を参照する。

最初に、アプリケーション機器１０１からＴＣＰコネクションの開設を要求する場合について、図１１を参照して述べる。図１１では、クライアント５０１のように、ＴＣＰコネクション確立を要求する側のフローチャートを表している。図１１の左側の「処理部」の欄は、フローチャートの各ステップの処理が、ネットワーク通信部１０２と、アプリケーションシステム部１０３のいずれの処理部で実行するかを示している。すなわち、図１１では全ての処理ステップが、アプリケーションシステム部１０３内だけで実行することを示している。また、ＴＣＰ通信は、ＲＦＣ７９３に見られる状態遷移が行われており、図１１の右側の「ＴＣＰ状態」の欄に、フローチャートに沿ったＴＣＰコネクションの状態遷移を示している。

ＴＣＰコネクションの確立要求の処理フローは、Ｓ６０１から始まり、Ｓ６０２において、ＴＣＰ通信を行うための新しいＴＣＰソケットを生成する。このとき、ＴＣＰソケットで使用する送信用と受信用の各々バッファは、ＲＡＭ１１４上に確保する。

次に、Ｓ６０３において、開始するＴＣＰ通信のＴＣＢ（ＴＣＰＣｏｎｔｒｏｌＢｌｏｃｋ）を生成する。ＴＣＢは、ＴＣＰ通信の制御を行うためのコンテキスト情報（ＴＣＰ制御情報）であり、数十個のパラメータの集合体データである。ＴＣＢはＴＣＰコネクション毎に生成し、ＴＣＰソケットと結び付けて管理される。そして、夫々のＴＣＰ通信処理を行う際に、各パラメータの値を参照・更新して利用される。アプリケーションシステム部１０３は、Ｓ６０３において、ＴＣＢをＲＡＭ１１４上に作成する。次に、Ｓ６０４でＴＣＰソケットテーブルに、ソケットペア情報を登録する。ソケットペア情報とは、ＴＣＰコネクションにおける両方のエンドポイントのＩＰアドレスと、ＴＣＰポート番号の組のことである。この場合は、ソケットペア情報とは、アプリケーション機器１０１における、ＩＰアドレス及びＴＣＰコネクションを開設するためのポート番号と、通信相手側のＩＰアドレス及びＴＣＰポート番号との組である。また、ＴＣＰソケットテーブルとは、アプリケーション機器１０１で処理している全てのＴＣＰ通信（ＴＣＰコネクション確立フェーズ／終了フェーズを含む）のソケットペアが登録されたデータベースである。

ＴＣＰソケットテーブルは、ネットワーク通信部１０２内のプロトコル処理部１０７で管理されている。ＴＣＰソケットテーブルには、ソケットペア情報と一緒に、各ソケットペアを使用しているＴＣＰソケットの番号と、ネットワーク通信部１０２とアプリケーションシステム部１０３のどちらで現在処理されているかを示す情報を記録している。

ＴＣＰソケットテーブルへのソケットペア情報の登録／削除は、アプリケーションシステム部１０３内のＣＰＵ１１２で実行するソフトウェア（ドライバ）で行う。さて、Ｓ６０４の段階では、新しく作成したＴＣＰソケットは未だコネクションを持たないので、ＴＣＰ状態がＣＬＯＳＥＤの状態である。次に、Ｓ６０５において、ＳＹＮパケットを送信し、ＴＣＰコネクションの開設を通信相手に要求する。すなわち、図１０の通信フローにおいて５０３の送信を行う。次に、Ｓ６０６に進んで処理フローは終了するが、Ｓ６０５のＳＹＮ送信によって、ＴＣＰ状態は、ＣＬＯＳＥＤからＳＹＮ＿ＳＥＮＴに遷移している。

続いて、コネクション確立要求（ＳＹＮ）を送信したＳＹＮ＿ＳＥＮＴ状態において、通信相手からＳＹＮに対する確認応答（ＳＹＮ，ＡＣＫ）パケットを受信するときの処理フローを、図１２のフローチャートを参照しながら説明する。

Ｓ７０１から始まり、ネットワーク通信部１０２は、Ｓ７０２において、受信したＴＣＰパケットのヘッダ構造を解析し、ソケットペア情報を取得して、ＴＣＰソケットテーブルの検索を実行する。そして、Ｓ７０３において、このパケットを受信するべきＴＣＰソケットが存在するかを調べる。このＳ７０２の処理は、図８の１３０７と１３０８の処理モジュールで実行する。すなわち、１３０８でＴＣＰパケットのヘッダ情報を読み出すことで、ソケットペア情報を取得し、１３０７に通知する。そして、処理モジュール１３０７においてＴＣＰソケットテーブルを検索し、受信すべきソケットが存在するかを判定し、１３０８に検索結果を返す。Ｓ７０３では、受信ＴＣＰパケットを受信可能なＴＣＰソケットが存在しない場合はＳ７０４の処理に進み、存在する場合は、Ｓ７０６への処理へと進む。

Ｓ７０４では、受信パケットを受理できないため、該ＴＣＰパケットの送信元であるＴＣＰソケットに対して、強制切断を意味する（ＲＳＴ，ＡＣＫ）パケットを送信する。このパケットは、ＴＣＰヘッダの制御ビットにおいて、ＲＳＴビットとＡＣＫビットを立てたパケットである。この返送するＴＣＰパケットは、図８の処理モジュール１３０７において作成する。Ｓ７０４で（ＲＳＴ，ＡＣＫ）パケットを送信した場合、Ｓ７０５に進んで終了する。

Ｓ７０３からＳ７０６へと進んだ場合は、受信したＴＣＰパケットを受信可能なＴＣＰソケットが存在する場合である。該ＴＣＰソケットは、ＳＹＮ＿ＳＥＮＴの状態であることから、アプリケーションシステム部１０３で受信処理されるので、Ｓ７０６において、該受信ＴＣＰパケットをアプリケーションシステム部１０３へ転送する。また、ＴＣＰソケットテーブル検索時にヒットしたソケット番号をＴＣＰ／ＩＰプロトコル処理モジュール１３０５に対して通知する。このＳ７０６は、図８の処理モジュール１３０８で処理し、アプリケーションシステム部１０３内のＲＡＭ１１４のパケット受信バッファに転送する。

次に、Ｓ７０７に進むと、ＴＣＰパケットの受信処理がなされ、Ｓ７０８に進んで確認応答（ＡＣＫ）パケットを送信する。この確認応答パケットの送信は、図１０における５０５のＡＣＫで示されるＴＣＰパケット送信である。Ｓ７０７とＳ７０８は、図８のＴＣＰ／ＩＰプロトコル処理モジュール１３０５で処理する。すなわちアプリケーションシステム部１０３内で実行される。

Ｓ７０８で確認応答パケットを送信すると、Ｓ７０９に進み、ソケット切り替え処理が行われる。Ｓ７０９では、図８のＴＣＰ／ＩＰプロトコル処理モジュール１３０５から、ソケット切り替え処理モジュール１３１０に通知を行い、以降において該ＴＣＰについて、ソケット層処理とＴＣＰプロトコル処理を、ネットワーク通信部１０２で実行されるように切り替える。ソケット切り替え処理モジュール１３１０への通知には、ＴＣＰソケット番号、及び該ＴＣＰソケットにリンクされる送信用バッファと受信用バッファのメモリアドレス、及びＴＣＢの情報が含まれる。ＴＣＢの通知方法としては、ＲＡＭ１１４上に存在するＴＣＢデータのメモリアドレスを通知するか、又はＴＣＢのデータ内容を通知するようにしてもよい。なお、以下の記述において、ソケット切り替え処理モジュール１３１０への通知とは、これらの情報が含まれる。

なお、ソケット切り替え処理モジュール１３１０の処理では、必ずしも該ＴＣＰソケットに関するプロトコル処理を、ネットワーク通信部１０２内で処理実行するように切り替えるわけでない。ネットワーク通信部１０２で処理可能なＴＣＰコネクション数が、上限に達している場合には、切り替え処理は実行されない。この場合、アプリケーションシステム部１０３内で、ＴＣＰ通信処理が実行される。

Ｓ７０９でＴＣＰソケットの処理モジュールの切り替え処理が終わると、Ｓ７１０に進んで該（ＳＹＮ，ＡＣＫ）パケット受信処理フローが正常に終了する。このとき、図１２の右側の欄に示されているように、該ＴＣＰコネクションのＴＣＰ状態は、ＳＹＮ＿ＳＥＮＴから、ＥＳＴＡＢＬＩＳＨＥＤへと遷移する。

ここまでで、図１１と図１２を参照しながら、図１０のＴＣＰコネクション確立フェーズ５１２において、アプリケーション機器１０１が、図１０のクライアント５０１側のようにコネクションの開設を要求する場合の処理内容について説明した。

次に、図１０のＴＣＰコネクション確立フェーズ５１２において、アプリケーション機器１０１が、図１０のサーバ５０２のようにＴＣＰコネクションの開設要求を受け付ける側である場合について説明する。一般に、ＴＣＰ通信では、通信相手からのコネクション確立要求を受け付けるために、ＬＩＳＴＥＮ状態のＴＣＰソケットで待ち受けている必要がある。本実施形態のアプリケーション機器１０１では、コネクションの確立要求（ＳＹＮ）を受け付け中の全てのＴＣＰソケットの情報を、ＬＩＳＴＥＮテーブルと呼ぶデータベースに保持している。このＬＩＳＴＥＮテーブルは、ネットワーク通信部１０２内のプロトコル処理部１０７で管理している。ＴＣＰ通信を行うアプリケーションは、ＴＣＰコネクションの確立要求を待ち受けるために、ＬＩＳＴＥＮ状態のＴＣＰソケットを作成する。この処理を図１３のフローチャートを参照しながら説明する。

図１３のＳ８０１から始まり、アプリケーションからのＴＣＰソケット生成と、コネクション待ち受け状態へ移行の指示に従い、Ｓ８０２において新しいＴＣＰソケットを生成する。Ｓ８０２で作成されたＴＣＰソケットは、ＣＬＯＳＥＤの状態である。作成したＴＣＰソケットをＬＩＳＴＥＮ状態にするために、図８のソケット切り替え処理モジュール１３１０に、ＬＩＳＴＥＮテーブルへの登録指示を通知する。この登録指示には、コネクション確立要求を受け付けるソケットの番号、及び待ち受けのための自局ＩＰアドレスとＴＣＰポート番号の組とを付加する。ここまでの処理は、アプリケーションシステム部１０３内のＴＣＰソケット層処理モジュール１３０４で実行される。

次に、Ｓ８０２からＳ８０３に進み、ソケット切り替え処理モジュール１３１０によって、生成された新ＴＣＰソケットの処理部が切り替えられ、ネットワーク通信部１０２内でＴＣＰプロトコル処理が行われるようになる。次に、Ｓ８０４において、図８のＴＣＰ処理１３０７モジュールにより、前述のＬＩＳＴＥＮテーブルに、ＴＣＰコネクションの確立要求を待ち受ける自局のＩＰアドレスとポート番号の組と、そのＴＣＰソケット番号を登録する。そして、Ｓ８０５に進んで終了する。このような処理により、新ＴＣＰソケットはＣＬＯＳＥＤ状態からＬＩＳＴＥＮ状態へ遷移する。

ＴＣＰコネクションを開設する要求を受信したときには、宛先ＩＰアドレスとポート番号の組をキーとしてＬＩＳＴＥＮテーブルを検索して、該宛先条件に一致するエントリが存在するかを判定することになる。すなわち、コネクション確立要求の宛先として指定された登録されたＴＣＰソケットが存在するかを判定し、存在するならばＴＣＰコネクションの確立が可能となる。

続いて、ＴＣＰ通信の通信相手から、コネクション確立要求のＴＣＰパケット（ＳＹＮパケット）を受信したときの処理フローを、図１４を参照しながら説明する。処理フローは、Ｓ９０１から始まり、まず、ネットワーク通信部１０２内で、Ｓ９０２において、受信したＴＣＰパケットのヘッダ構造を解析してソケットペア情報を取得し、ＬＩＳＴＥＮテーブルの検索を実行する。このＳ９０２の処理は、図８の１３０７と１３０８に処理モジュールで実行する。１３０８でＴＣＰパケットのヘッダ情報を読み出すことで、ソケットペア情報を取得し、１３０７に通知する。そして、１３０７の処理モジュールにおいてＬＩＳＴＥＮテーブルを検索し、受信すべきソケットが存在するかを判定し、１３０８に検索結果を返す。

Ｓ９０３では、受信ＴＣＰパケット（ＳＹＮパケット）を受信可能なＬＩＳＴＥＮ状態のＴＣＰソケットが存在しない場合、言い換えるとコネクション確立要求を受け入れるＴＣＰソケットが存在しない場合はＳ９０４の処理に進む。存在する場合は、Ｓ９０６への処理へと進む。Ｓ９０４では、受信パケットを受理できないので、該ＴＣＰパケットの送信元であるＴＣＰソケットに対して、強制切断を意味する（ＲＳＴ，ＡＣＫ）パケットを送信し、Ｓ９０５に進んで終了する。

Ｓ９０３からＳ９０６へと進んだ場合は、受信したＴＣＰパケット（ＳＹＮパケット）を受信可能なＴＣＰソケットが存在する場合である。Ｓ９０６では、該受信ＴＣＰパケットをアプリケーションシステム部１０３へと転送する。このＳ９０６は、図８の処理モジュール１３０８で処理し、アプリケーションシステム部１０３内のＲＡＭ１１４のパケット受信バッファに転送する。また、ＬＩＳＴＥＮテーブル検索時にヒットしたソケット番号をＴＣＰ／ＩＰプロトコル処理モジュール１３０５に対して通知する。

次に、Ｓ９０７に進む。Ｓ９０７からの処理フローは、アプリケーションシステム部１０３内で処理する。Ｓ９０７では確立するＴＣＰコネクションのための新しいＴＣＰソケットを作成し、次に、Ｓ９０８において、このＴＣＰソケットの通信に使用する新ＴＣＢを作成する。このとき、ＴＣＰソケットで使用する送信用と受信用の各々バッファは、ＲＡＭ１１４上に確保する。次に、Ｓ９０９でＴＣＰソケットテーブルに、新たに作成したＴＣＰソケットのソケットペア情報を登録する。Ｓ９０９のＴＣＰソケットテーブルへの登録処理は、アプリケーション機器１０１からＴＣＰコネクションの開設を要求する場合における図１１のＳ６０４の処理と同様であり、詳細な説明は省略する。Ｓ９０９の後、Ｓ９１０へと進み、ＴＣＰ処理モジュール１３０７で、コネクションの確立要求の確認応答であるＴＣＰパケット（ＳＹＮ，ＡＣＫ）を送信する。この送信されるＴＣＰパケットは、図１０の５０４に示されるものである。

以上のように、このＳ９１０の処理により、新たに生成されたＴＣＰコネクションは、ＣＬＯＳＥＤの状態から、ＳＹＮ＿ＲＣＶＤ状態へと遷移することになる。

続いて、（ＳＹＮ，ＡＣＫ）のＴＣＰパケットの送信で、ＳＹＮ＿ＲＣＶＤ状態へと遷移したＴＣＰコネクションにおいて、通信相手からの確認応答（ＡＣＫ）を受信した場合の処理フローを、図１５を参照しながら説明する。図１５の処理フローでは、受信するＴＣＰパケットが、図１０の通信フロー例における５０５の確認応答（ＡＣＫ）パケットを意味する。

図１５の処理フローはＳ１００１から開始し、ネットワーク通信部１０２内で、Ｓ１００２において、受信したＴＣＰパケットのヘッダ構造を解析し、ソケットペア情報を取得して、ＴＣＰソケットテーブルの検索を実行する。そして、Ｓ１００３において、このパケットを受信するべきＴＣＰソケットが存在するかを調べる。このＳ１００２の処理は、前述の図１２におけるＳ７０２の処理ステップと同処理を行う。Ｓ１００３では、受信ＴＣＰパケットを受信可能なＴＣＰソケットが存在しない場合はＳ１００４の処理に進み、存在する場合は、Ｓ１００６への処理へと進む。Ｓ１００４では、受信パケットを受理できないので、該ＴＣＰパケットの送信元であるＴＣＰソケットに対して、強制切断を意味する（ＲＳＴ，ＡＣＫ）パケットを送信し、Ｓ１００５に進んで終了する。

Ｓ１００３からＳ１００６へと進んだ場合は、受信したＴＣＰパケットを受信可能なＴＣＰソケットが存在する場合である。Ｓ１００６では、該受信ＴＣＰパケットをアプリケーションシステム部１０３へと転送する。Ｓ１００６は、前述した図１２のＳ７０６の処理ステップと同処理を実行する。次に、Ｓ１００７に進み、受信ＴＣＰパケットが受信処理される。

そして、Ｓ１００８に進み、ソケット切り替え処理が行われる。Ｓ１００８では、図８のＴＣＰ／ＩＰプロトコル処理モジュール１３０５から、ソケット切り替え処理モジュール１３１０に通知を行い、以降において該ＴＣＰについて、ソケット層処理とＴＣＰプロトコル処理を、ネットワーク通信部１０２で実行されるように切り替える。このＳ１００８の処理ステップについても、前述のＳ７０９の処理と同処理を実行する。

Ｓ１００８でＴＣＰソケットの処理モジュールの切り替え処理が完了すると、Ｓ１００９に進み、該受信ＴＣＰパケット（ＡＣＫ）の処理フローが正常に終了する。このとき、図１５の右側の欄に示されているように、該ＴＣＰコネクションのＴＣＰ状態は、ＳＹＮ＿ＲＣＶＤから、ＥＳＴＡＢＬＩＳＨＥＤへと遷移する。

図１３、図１４及び図１５を参照しながら、図１０のＴＣＰコネクション確立フェーズ５１２において、アプリケーション機器１０１が、図１０のサーバ５０２側のようにコネクションの開設を要求される場合の処理内容について説明した。

次に、ＴＣＰコネクションがＥＳＴＡＢＬＩＳＨＥＤ状態であるとき、データの送受信の処理内容について説明する。図１０に示す通信フロー例では、５１３のＴＣＰコネクション確立中フェーズの通信を意味する。ＴＣＰコネクションが確立中である状態は、ＥＳＴＡＢＬＩＳＨＥＤ状態とよばれている。本実施形態において、図１１〜図１５を参照して前述したように、各ＴＣＰのコネクションのＥＳＴＡＢＬＩＳＨＥＤ状態では、ネットワーク通信部１０２内でＴＣＰプロトコル処理が実行される。

図１６は、コネクション確立中のデータ送信の処理フローであり、ＥＳＴＡＢＬＩＳＨＥＤ状態のＴＣＰ通信のデータ送信処理を表している。図１６において、まず、Ｓ１１０１から始まり、Ｓ１１０２において、ＴＣＰソケット処理をネットワーク通信部１０２で実行するか否かを判定する。Ｓ１１０２の処理は、図８のソケットインタフェース１３０３で行われる。ソケット切り替え処理モジュール１３１０によって、該ＴＣＰ通信のＴＣＰソケット層処理を、ネットワーク通信部１０２内で処理するように切り替えられていた場合は、Ｓ１１０３に進む。そうでないならば、アプリケーションシステム部１０３で処理するようになっていることを意味し、Ｓ１１０５に進む。Ｓ１１０３とＳ１１０５は共にＴＣＰデータ送信処理である。図１６のＳ１１０３とＳ１１０５では、ＴＣＰ通信のデータ送信時における、送信フロー制御や輻輳制御、送信データのセグメント（分割）処理や、ＴＣＰパケットの再送処理等が実行される。そして、Ｓ１１０６で処理が終了する。

一方、図１７は、コネクション確立中のデータ受信時の処理フローである。この処理フローはＳ１２０１から始まり、ネットワーク通信部１０２は、まず、Ｓ１２０２において、受信したＴＣＰパケットのヘッダ構造を解析し、ソケットペア情報を取得して、ＴＣＰソケットテーブルの検索を実行する。そして、Ｓ１２０３において、このパケットを受信するべきＴＣＰソケットが存在するかを調べる。このＳ１２０２の処理は、前述の図１２の７０２の処理と同処理を実行する。Ｓ１２０３では、受信ＴＣＰパケットを受信可能なＴＣＰソケットが存在しない場合、Ｓ１２０４の処理に進み、存在する場合は、Ｓ１２０６への処理へと進む。Ｓ１２０４では、受信ＴＣＰパケットを受理できないので、該ＴＣＰパケットの送信元であるＴＣＰソケットに対して、強制切断を意味する（ＲＳＴ，ＡＣＫ）パケットを送信し、Ｓ１２０５に進んで終了する。

Ｓ１２０３からＳ１２０６へと進んだ場合は、受信したＴＣＰパケットを受信可能なＴＣＰソケットが存在する場合である。Ｓ１２０６では、受信したＴＣＰパケットを受信処理する処理部がネットワーク通信部１０２であるか否かを判定する。図８のソケット切り替え処理モジュール１３１０によって、該ＴＣＰ通信のＴＣＰソケット層処理を、ネットワーク通信部１０２内で処理するように切り替えられていた場合は、Ｓ１２０７に進む。そうでないならば、アプリケーションシステム部１０３で処理するようになっていることを意味し、Ｓ１２１２に進む。Ｓ１２０７からＳ１２１１では、ネットワーク通信部１０２の処理である。一方、Ｓ１２１２からＳ１２１６は、アプリケーションシステム部１０３の処理である。

Ｓ１２０７では、該受信ＴＣＰパケットについて、ＴＣＰプロトコル処理を実行する。Ｓ１２０７の処理のあと、Ｓ１２０８において受信ＴＣＰパケットのデータに対して、即ＡＣＫ送信が必要であるならば、Ｓ１２０９で受信確認応答（ＡＣＫ）パケットを送信し、Ｓ１２１０に進む。即ＡＣＫ送信が必要でなければＳ１２０８からＳ１２１０へと進む。Ｓ１２１０では、ＴＣＰソケット層の受信処理が実行される。この処理は、図８のＴＣＰソケット層処理モジュール１３０６で実行され、アプリケーションのソケットインタフェース１３０３を介したデータ受信要求に対し、アプリケーションの受信バッファメモリに受信データを転送する処理を実行する。そして、Ｓ１２１０からＳ１２１１に進み、処理フローは終了する。

Ｓ１２０６からＳ１２１２へ進んだ場合は、Ｓ１２１２において、該受信ＴＣＰパケットのＴＣＰプロトコル処理を実行する。Ｓ１２１２の処理のあと、Ｓ１２１３において受信ＴＣＰパケットのデータに対して、即ＡＣＫ送信が必要であるならば、Ｓ１２１４で受信確認応答（ＡＣＫ）パケットを送信し、Ｓ１２１５に進む。即ＡＣＫ送信が必要でなければ、Ｓ１２１３からＳ１２１５へと進む。Ｓ１２１５では、ＴＣＰソケット層の受信処理が実行される。この処理は、図８のＴＣＰソケット層処理モジュール１３０４で実行され、アプリケーションのソケットインタフェース１３０３を介したデータ受信要求に対し、アプリケーションの受信バッファメモリに受信データを転送する処理を実行する。そして、Ｓ１２１５からＳ１２１６に進み、処理フローは終了する。

尚、Ｓ１２０７とＳ１２１２では、受信パケットからの受信データのリオーダリング（再構成）処理や、受信データに対するＡＣＫ送信の判定処理や、通信相手からのＡＣＫ受信による送信ウィンドウ制御等が実行される。

ここまで、図１６と図１７を参照しながら、図１０のＴＣＰコネクション確立中フェーズ５１３において、アプリケーション機器１０１のデータ送受信の処理内容について説明した。

次に、アプリケーション機器１０１からＴＣＰコネクションの終了を要求する場合の処理内容を、図１８と図１９を参照して説明する。図１０の通信フロー例において、コネクション終了フェーズ５１４のクライアント５０１側の通信動作を行うこととして説明する。まず、ＴＣＰコネクションがＥＳＴＡＢＬＩＳＨＥＤである状態から、ＴＣＰコネクションの終了要求を送信する。そして、通信相手からの、送信した終了要求に対する確認応答と、通信相手からの終了要求を受信し、最後に通信相手からの終了要求に対する確認応答を送信する。

図１８の処理フローは、ＥＳＴＡＢＬＩＳＨＥＤ状態のＴＣＰソケットを使用するアプリケーションが、ソケットインタフェース１３０３を介して、ＴＣＰソケットのクローズを指示することで、開始する。処理フローはＳ１３０１から始まり、まず、Ｓ１３０２においてＴＣＰソケット処理をネットワーク通信部１０２で実行するか否かを判定する。Ｓ１３０２の処理は、図８のソケットインタフェース１３０３で行われる。ソケット切り替え処理モジュール１３１０によって、該ＴＣＰ通信のＴＣＰソケット層処理を、ネットワーク通信部１０２内で処理するように切り替えられていた場合は、Ｓ１１３０３に進む。そうでないならば、アプリケーションシステム部１０３で処理するようになっていることを意味し、Ｓ１３０６に進む。Ｓ１３０３からＳ１３０５は、ネットワーク通信部１０２内の処理であり、Ｓ１３０６からＳ１３０７はアプリケーションシステム部１０３の処理である。

Ｓ１３０３においてＴＣＰコネクションの終了を要求するＴＣＰパケットを送信する。これは図１０の通信フローの例で、５０９のＦＩＮ送信を意味する。ＴＣＰコネクションの終了要求の送信は、図８のＴＣＰ処理モジュール１３０７において実行する。送信ＴＣＰパケットは、ＴＣＰパケットヘッダの制御ビットフィールド中のＦＩＮビットが１である。

次に、Ｓ１３０４に進み、該ＴＣＰコネクションにおけるＴＣＰプロトコル処理を、以降においてアプリケーションシステム部１０３内で処理されるように、ＴＣＰソケットの切り替え処理を行う。図８の処理モジュール１３０７から、ソケット切り替え処理モジュール１３１０に通知を行い、該ＴＣＰソケットの処理を、ネットワーク通信部１０２からアプリケーションシステム部１０３に移す。これにより、該ＴＣＰソケットに関して、ＴＣＰプロトコル処理及びソケット層の処理を、図８の１３０４と１３０５の処理モジュールで行うことになる。そして、Ｓ１３０５に進んで終了する。ＴＣＰコネクションのＴＣＰ状態は、ＥＳＴＡＢＬＩＳＥＨＤからＦＩＮ＿ＷＡＩＴ１に遷移する。

Ｓ１３０２からＳ１３０６に進んだ場合は、まず、Ｓ１３０６において、ＴＣＰコネクションの終了を要求するＴＣＰパケットを送信する。これは図１０の通信フローの例で、５０９のＦＩＮ送信を意味する。ＴＣＰコネクションの終了要求の送信は、図８のＴＣＰ／ＩＰプロトコル処理モジュール１３０５において実行する。そして、Ｓ１３０７に進んで終了する。ＴＣＰコネクションのＴＣＰ状態は、ＥＳＴＡＢＬＩＳＥＨＤからＦＩＮ＿ＷＡＩＴ１に遷移する。

図１０の通信フロー例では、５１０の通信に示されるように、通信相手側から、先に送信したコネクション終了要求（ＦＩＮ）に対する確認応答と、通信相手からの終了要求の両方を意味するＴＣＰパケット（ＦＩＮ，ＡＣＫ）を受信する。このときの処理フローを、図１９で示している。図１８で示したように、アプリケーション機器１０１側から先にコネクション終了要求（ＦＩＮ）を送信していることから、図１９では、該ＴＣＰコネクションのＴＣＰ状態は、ＦＩＮ＿ＷＡＩＴ１の状態となっている。

図１９は、Ｓ１４０１から始まり、ネットワーク通信部１０２が、Ｓ１４０２において、受信したＴＣＰパケットのヘッダ構造を解析し、ソケットペア情報を取得して、ＴＣＰソケットテーブルの検索を実行する。そして、Ｓ１４０３において、このパケットを受信するべきＴＣＰソケットが存在するかを調べる。このＳ１４０２の処理は、前述の図１２のＳ７０２と同処理を実行する。Ｓ１４０３では、受信ＴＣＰパケットを受信可能なＴＣＰソケットが存在しない場合はＳ１４０４の処理に進み、存在する場合は、Ｓ１４０６への処理へと進む。Ｓ１４０４では、受信パケットを受理できないので、該ＴＣＰパケットの送信元であるＴＣＰソケットに対して、強制切断を意味する（ＲＳＴ，ＡＣＫ）パケットを送信し、Ｓ１４０５に進んで終了する。

Ｓ１４０３からＳ１４０６へと進んだ場合は、受信したＴＣＰパケットを受信可能なＴＣＰソケットが存在する場合である。Ｓ１４０６では、該受信ＴＣＰパケットをアプリケーションシステム部１０３内のＲＡＭ１１４のパケット受信バッファに転送する。また、ＴＣＰソケットテーブル検索時にヒットしたソケット番号を１３０５のＴＣＰ／ＩＰ処理モジュールに対して通知する。

次に、Ｓ１４０７に進む。Ｓ１４０７からＳ１４０９までの処理ステップは、アプリケーションシステム部１０３において実行される。Ｓ１４０７において、ＴＣＰパケットの受信処理を行い、該ＴＣＰパケットは通信相手からの（ＦＩＮ，ＡＣＫ）パケットであるので、Ｓ１４０８に進んで確認応答（ＡＣＫ）を送信する。この確認応答パケットの送信は、図１０における５１１のＡＣＫで示されるＴＣＰパケット送信である。ここまでの処理ステップにより、該ＴＣＰコネクションの状態は、ＦＩＮ＿ＷＡＩＴ１からＴＩＭＥ＿ＷＡＩＴへと遷移する。

Ｓ１４０９では、ＴＩＭＥ＿ＷＡＩＴ状態で２ＭＳＬ（ＭａｘＳｅｇｍｅｎｔＬｉｆｅｔｉｍｅ）時間だけタイムアウト待ちの状態となる。このタイムアウト後にＴＩＭＥ＿ＷＡＩＴ状態からＣＬＯＳＥＤ状態となり、該ＴＣＰコネクションは終了する。

図１８と図１９を参照しながら、図１０のＴＣＰコネクション終了フェーズ５１４において、アプリケーション機器１０１が、図１０のクライアント５０１側のように通信動作する場合の処理内容について説明した。５０９のＦＩＮ送信処理は、ＴＣＰコネクションはＥＳＴＡＢＬＩＳＨＥＤ状態であり、ネットワーク通信部１０２で実行する。そして、ＴＣＰプロトコル処理を実行する処理部を切り替え、５１０の（ＦＩＮ，ＡＣＫ）受信時と、及び５１１のＡＣＫ送信時の処理は、アプリケーションシステム部１０３において実行する。

次に、アプリケーション機器１０１の通信相手から、ＴＣＰコネクションの終了を要求される場合の処理内容を、図２０を参照して説明する。図１０の通信フロー例において、コネクション終了フェーズ５１４のサーバ５０２側の通信動作を行うこととして説明する。まず、ＴＣＰコネクションがＥＳＴＡＢＬＩＳＨＥＤである状態で、通信相手が送信したＴＣＰコネクションの終了要求を受信し、該終了要求に対する確認応答と、アプリケーション機器１０１側から終了要求を意味するＴＣＰパケットを送信することを実行する。

図２０の処理フローは、ＴＣＰコネクションが確立中であるＥＳＴＡＢＬＩＳＨＥＤ状態において、通信相手からＴＣＰコネクションの終了要求（ＦＩＮ）を受信することによって開始される。処理フローはＳ１５０１から開始し、まず、ネットワーク通信部１０２は、Ｓ１５０２において、受信したＴＣＰパケットのヘッダ構造を解析し、ソケットペア情報を取得して、ＴＣＰソケットテーブルの検索を実行する。そして、Ｓ１５０３において、このパケットを受信するべきＴＣＰソケットが存在するかを調べる。このＳ１５０２の処理は、図１２のＳ７０２と同処理を実行する。Ｓ１５０３では、受信ＴＣＰパケットを受信可能なＴＣＰソケットが存在しない場合はＳ１５０４の処理に進み、存在する場合は、Ｓ１５０６への処理へと進む。Ｓ１５０４では、受信パケットを受理できないので、該ＴＣＰパケットの送信元であるＴＣＰソケットに対して、強制切断を意味する（ＲＳＴ，ＡＣＫ）パケットを送信する。Ｓ１５０４で（ＲＳＴ，ＡＣＫ）パケットを送信した場合は、Ｓ１５０５に進んで終了する。

Ｓ１５０３からＳ１５０６へと進んだ場合は、受信したＴＣＰパケットを受信可能なＴＣＰソケットが存在する場合である。Ｓ１５０６では、受信したＴＣＰパケットを受信処理する処理部がネットワーク通信部１０２であるか否かを判定する。図８のソケット切り替え処理モジュール１３１０によって、該ＴＣＰ通信のＴＣＰソケット層処理を、ネットワーク通信部１０２内で処理するように切り替えられていた場合は、Ｓ１５０７に進む。そうでないならば、アプリケーションシステム部１０３で処理するようになっていることを意味し、Ｓ１５１１に進む。Ｓ１５０７からＳ１５１０では、ネットワーク通信部１０２の処理である。一方、Ｓ１５１１からＳ１５１３は、アプリケーションシステム部１０３の処理である。

Ｓ１５０７では、該ＴＣＰパケットの受信処理を行い、続いてＳ１５０８に進む。該ＴＣＰパケットは通信相手からのコネクション終了要求（ＦＩＮ）であるので、ＦＩＮに対する確認応答と、アプリケーション機器１０１側からのコネクション終了要求を合わせたＴＣＰパケット（ＦＩＮ，ＡＣＫ）を送信する。そして、Ｓ１５０９に進み、以降において、該ＴＣＰソケットの処理をアプリケーションシステム部１０３内で処理されるように、ソケット切り替え処理を行う。図８の処理モジュール１３０７から、ソケット切り替え処理モジュール１３１０に通知を行い、該ＴＣＰソケットの処理を、ネットワーク通信部１０２からアプリケーションシステム部１０３に移す。これにより、該ＴＣＰソケットに関して、ＴＣＰプロトコル処理及びソケット層の処理を、図８の１３０４と１３０５の処理モジュールで行うことになる。その後、Ｓ１５１０に進んで終了する。

Ｓ１５０６からＳ１５１１に進んだ場合は、Ｓ１５１１において、該ＴＣＰパケットの受信処理を行い、続いてＳ１５１２に進む。該ＴＣＰパケットは通信相手からのコネクション終了要求（ＦＩＮ）であるので、ＦＩＮに対する確認応答と、アプリケーション機器１０１側からのコネクション終了要求を合わせたＴＣＰパケット（ＦＩＮ，ＡＣＫ）を送信する。そして、Ｓ１５１３に進んで、処理フローが終了する。

図２０を参照しながら、図１０のＴＣＰコネクション終了フェーズ５１４において、アプリケーション機器１０１が、図１０のサーバ５０２側のように通信動作する場合の処理内容について説明した。５０９のＦＩＮの受信処理は、ＴＣＰコネクションがＥＳＴＡＢＬＩＳＨＥＤ状態であり、５１０の（ＦＩＮ，ＡＣＫ）送信までをネットワーク通信部１０２で実行する。ＴＣＰコネクションは終了され、ＣＬＯＳＥＤ状態に遷移する。同時に該ソケットについての処理はアプリケーションシステム部１０３内で実行されるように切り替えられる。

次に、本実施形態において、図８の１３１０のソケット切り替え処理モジュールでおけるＴＣＰ通信を処理実行する処理部の切り替えの判定方法について説明する。

ＴＣＰ通信が、アプリケーションシステム部１０３からネットワーク通信部１０２の処理に切り替えられるための条件は、まず、第１にＴＣＰコネクションの状態がＥＳＴＡＢＬＩＳＨＥＤであることである。この理由は、アプリケーション機器が高速なデータ送受信処理が必要とするのは、アプリケーション通信データを送受信するときであり、即ちＴＣＰコネクションが確立中のときだからである。

第２に、ネットワーク通信部１０２で処理可能なＴＣＰコネクション数が限界数以内であるときである。前述したように図１２のＳ７０９や、図１５のＳ１００８の処理ステップは、ＴＣＰコネクションがＥＳＴＡＢＬＩＳＨＥＤの状態に遷移するため、ＴＣＰプロトコル処理の処理部を切り替える処理を実行する。その時点においてネットワーク通信部１０２で処理可能なＴＣＰコネクション数が上限に達していないならば、該ＴＣＰ通信処理がネットワーク通信部１０２内で実行されるように切り替えが実行される。しかし、その時点においてネットワーク通信部１０２で処理可能なＴＣＰコネクション数が上限に達してしまっていた場合、ネットワーク通信部１０２の処理に切り替えを行わないで、以降においてアプリケーションシステム部１０３側でＴＣＰ通信処理を実行する。

本実施形態においては、前述の通り、図８の１３０５、１３０７の処理モジュールが、ＴＣＰプロトコル処理を行っているＥＳＴＡＢＬＩＳＨＥＤ状態ＴＣＰコネクションについて、一定時間毎に送受信パケット数を計測している。また、図８の１３０４、１３０６のＴＣＰソケット層処理のモジュールは、一定時間毎にアプリケーションが送受信するデータ量を計測している。図８のソケット切り替え処理モジュール１３１０では、１３０４、１３０５、１３０６、１３０７から計測結果の通知を受け取りながら、優先順位の情報を作成・更新する。ここでは、ＥＳＴＡＢＬＩＳＨＥＤ状態の全てのＴＣＰ通信において、送受信パケット数の多いＴＣＰ通信、あるいは送受信データ量の大きいＴＣＰ通信が、ネットワーク通信部１０２でＴＣＰプロトコル処理が実行されるように優先順位の情報を作成・更新する。

ネットワーク通信部１０２で処理しているＴＣＰ通信が上限数に達している状態において、ネットワーク通信部１０２でＴＣＰプロトコル処理していたＴＣＰ通信の状態が、ＥＳＴＡＢＬＩＳＨＥＤ状態から遷移すると、該ＴＣＰ通信は切り替えられる。すなわち、ここでは、該ＴＣＰ通信はアプリケーションシステム部１０３で処理されるように切り替えられる。したがって、アプリケーションシステム部１０３で処理実行されているＥＳＴＡＢＬＩＳＨＥＤ状態のＴＣＰ通信を、ネットワーク通信部１０２での処理に切り替える。この入れ替えの際に、先に述べた優先順位の情報を基に、ＴＣＰソケットを選択して入れ替える。

尚、ネットワーク通信部１０２で処理しているＴＣＰ通信が上限数に達している状態においては、ネットワーク通信部１０２とアプリケーションシステム部１０３の其々がＴＣＰプロトコル処理を実行するＴＣＰ通信を、定期的に入れ替え判定を行ってもよい。その際に、前記の優先順位の情報を基にして、入れ替え処理を行う。

また、特定のアプリケーション通信を識別し、該アプリケーション通信がＥＳＴＡＢＬＩＳＨＥＤ状態では、ネットワーク通信部１０２でのＴＣＰプロトコル処理で優先実行するように切り替えを行っても良い。これは、アプリケーション機器１０１の特定のＴＣＰポート番号をあらかじめ予約しておき、特定アプリケーションで使用するなどにより、実現可能である。さらに、優先度の高いＴＣＰ通信のコネクションがＥＳＴＡＢＬＩＳＨＥＤ状態に遷移し、ＴＣＰプロトコル処理の切り替え処理が発生したとき、ネットワーク通信部１０２で処理可能なＴＣＰコネクション数が上限に達していても、優先度の低いコネクションと交換する。

次に、図８のソケット切り替え処理モジュール１３１０でおけるＴＣＰ通信を処理実行する処理部の切り替えについて処理内容について、図２１を参照しながら説明する。

図２１の１６０１は、アプリケーションシステム部１０３のＴＣＰ／ＩＰ処理モジュールを示しており、図８の１３０５の処理モジュールと同義である。１６０２は、ネットワーク通信部１０２のＴＣＰ処理モジュールを示し、図８の１３０７の処理モジュールと同義である。１６０３は、ソケット切り替え処理モジュールを表し、図８の１３１０の処理モジュールと同義である。ＴＣＰソケット通信において、ＴＣＰプロトコル処理の切り替えは、１６０２と１６０３間で処理を実行する側を変更することを意味する。

また、１６０４と１６０５は、それぞれＴＣＰ通信処理の切り替え対象であるＴＣＰソケットの送信用バッファと受信用バッファ（ＴＣＰ送受信バッファ）を示しており、１６０６は、該ＴＣＰソケットに結び付けられたＴＣＢを示している。図１１のＳ６０２、Ｓ６０３や、図１４のＳ９０７やＳ９０８の処理ステップについて前述したように、１６０４、１６０５、１６０６のデータは、アプリケーションシステム部１０３内のＲＡＭ１１４上に確保される。本実施形態において、１６０１と１６０２の処理モジュール間でＴＣＰプロトコル処理を切り替えた場合でも、これらのデータバッファは、ＲＡＭ１１４上にそのまま据え置かれる。言い換えると、切り替えによってデータコピー等は行わず、切り替え後もＲＡＭ１１４上の同じデータに対してｒｅａｄ／ｗｒｉｔｅを行う。即ちこれらのデータをＲＡＭ１１４上で、１６０１と１６０２の両処理モジュール間で共有し、該ＴＣＰソケットを処理するモジュールが、データに対するアクセスを行う。

ＴＣＰソケット通信のプロトコル処理の切り替えは、１６０１と１６０２のどちらか一方から、ソケット切り替え処理モジュール１６０３に対して切り替えの通知を行う。通知内容には、ＴＣＰソケット番号、送信用・受信用のソケットバッファ１６０４、１６０５のメモリアドレス、ＴＣＢ１６０６のメモリアドレスを通知する。ソケット切り替え処理モジュール１６０３は、切り替え先である処理モジュールに対して、これらの情報を伝達する。

また、１６０７は、１６０１で処理するパケットが転送される受信バッファであり、１６０８は、１６０２で処理するパケットが転送される受信バッファである。１６０７は、ネットワーク通信部１０２内のローカルＲＡＭ１０６上に配置し、１６０８は、アプリケーションシステム部１０３内のＲＡＭ１１４内に配置する。前述のように、受信パケットについて、ＴＣＰソケットテーブルを検索し、該ＴＣＰパケットを受理するＴＣＰソケット番号と、どちらかのＴＣＰプロトコル処理モジュールで処理されるかを知るようになっている。そして、１６０７か１６０８のいずれかのパケット受信バッファにパケットデータが転送される。

そして、ソケット切り替え処理１６０３は、ＴＣＰソケット切り替え処理において、ＴＣＰソケットテーブルの該ＴＣＰソケットのエントリに、どちらで処理されるかの情報を書き換えることも行う。

以上、ＴＣＰ通信を利用したアプリケーション通信のＴＣＰプロトコル処理とＴＣＰソケット層処理について、ＴＣＰコネクションの状態遷移に応じて、ネットワーク通信部１０２とアプリケーションシステム部１０３で処理部を切り替えることを説明した。

アプリケーション通信を高速化するには、ＴＣＰ通信においてコネクション確立中の状態（ＥＳＴＡＢＬＩＳＨＥＤ）において、高速に通信処理が実行されればよい。従ってこのフェーズにおけるＴＣＰプロトコル処理をネットワーク通信部１０２内で実行することで、アプリケーション通信を高速化が可能となる。同時にアプリケーションシステム部のＣＰＵ１１２のＴＣＰ通信処理負荷をオフロードすることができる。

なお、本発明の実施形態は、例えばコンピュータがプログラムを実行することによって実現することができる。また、プログラムをコンピュータに供給するための手段、例えばかかるプログラムを記録したＣＤ−ＲＯＭ等のコンピュータ読み取り可能な記録媒体又はかかるプログラムを伝送するインターネット等の伝送媒体も本発明の実施形態として適用することができる。また、上記のプログラムも本発明の実施形態として適用することができる。上記のプログラム、記録媒体、伝送媒体及びプログラムプロダクトは、本発明の範疇に含まれる。

本発明の実施形態の一例を表すブロック図である。ＴＣＰ／ＩＰ通信におけるソフトウェア処理の階層モデル図である。アプリケーション通信のＴＣＰ／ＩＰ通信部分の処理フロー図である。ＴＣＰ／ＩＰプロトコル処理をネットワーク通信部とアプリケーションシステム部のいずれで実行するかを判定する手順を表すフローチャートである。図４のステップＳ４０２の手順を表すフローチャートである。アプリケーション機器の実施形態であるネットワークカメラのブロック図である。ネットワークカメラのアプリケーション通信処理の階層モデル図である。本発明の実施形態におけるＴＣＰ／ＩＰ通信の処理モジュール間の通信データフロー図である。ＴＣＰ／ＩＰのプロトコル毎に、プロトコル処理を実行する処理部と、その主な処理内容を示す表の図である。ＴＣＰ通信フローの一例を示す図である。ＴＣＰソケットがＣＬＯＳＥＤ状態におけるＳＹＮ送信処理を示す図である。ＴＣＰソケットがＳＹＮ＿ＳＥＮＴ状態における（ＳＹＮ，ＡＣＫ）受信処理を示す図である。ＴＣＰコネクション確立要求待ち受けソケットの作成処理を示す図である。ＬＩＳＴＥＮ状態におけるＳＹＮ受信処理を示す図である。ＴＣＰソケットがＳＹＮ＿ＲＥＣＶ状態における、ＡＣＫ受信処理を示す図である。ＴＣＰソケットがＥＳＴＡＢＬＩＳＨＥＤ状態におけるデータ送信処理を示す図である。ＴＣＰソケットがＥＳＴＡＢＬＩＳＨＥＤ状態におけるデータ受信処理を示す図である。ＴＣＰソケットがＥＳＴＡＢＬＩＳＨＥＤ状態におけるＦＩＮ送信処理を示す図である。ＴＣＰソケットがＦＩＮ＿ＷＡＩＴ１状態における（ＦＩＮ，ＡＣＫ）受信処理を示す図である。ＴＣＰソケットがＥＳＴＡＢＬＩＳＨＥＤ状態におけるＦＩＮ受信処理を示す図である。ソケット切り替え処理についての説明図である。

符号の説明

１０１アプリケーション機器
１０２ネットワーク通信部
１０３アプリケーションシステム部
１０４ローカルパス
１０５通信制御部
１０６ローカルＲＡＭ
１０７プロトコル処理部
１０８ＤＭＡコントローラ
１０９内部制御プロセッサ
１１０バスブリッジ
１１１システムバス
１１２ＣＰＵ

Claims

ネットワーク通信部と、
アプリケーションシステム部と、
を備え、
ＴＣＰ／ＩＰプロトコルを使用してアプリケーション通信を行う通信装置であって、
該アプリケーションシステム部は、該ネットワーク通信部による第１のＴＣＰ／ＩＰプロトコル処理と、該アプリケーションシステム部による第２のＴＣＰ／ＩＰプロトコル処理のいずれかを利用するアプリケーション通信を実行するとともに、
前記ネットワーク通信部は、アプリケーション通信の通信状態によって、第１のＴＣＰ／ＩＰプロトコル処理と第２のＴＣＰ／ＩＰプロトコル処理のいずれでアプリケーション通信を処理するかを切り替えることを特徴とする通信装置。
前記アプリケーションシステム部は、ＴＣＰ／ＩＰプロトコルを使用して複数のアプリケーション通信を行い、
前記アプリケーションシステム部は、各々のアプリケーション通信を、該ネットワーク通信部による第１のＴＣＰ／ＩＰプロトコル処理と、該アプリケーションシステム部による第２のＴＣＰ／ＩＰプロトコル処理のいずれかを利用して実行するとともに、
前記ネットワーク通信部は、各々のアプリケーション通信の通信状態によって、第１のＴＣＰ／ＩＰプロトコル処理と第２のＴＣＰ／ＩＰプロトコル処理のいずれで、各々のアプリケーション通信を処理するかを切り替えることを特徴とする請求項１に記載の通信装置。
前記第１のＴＣＰ／ＩＰプロトコル処理は、該ネットワーク通信部が内蔵する専用ハードウェア回路での処理、又は該ネットワーク通信部が内蔵するプロセッサによるソフトウェア処理と、ハードウェア回路による計算処理を組み合わせた処理であることを特徴とする請求項１に記載の通信装置。
前記第２のＴＣＰ／ＩＰプロトコル処理は、該アプリケーションシステム部内のプロセッサで実行するソフトウェア処理であることを特徴とする請求項１に記載の通信装置。
ＴＣＰ送受信バッファを、第１のＴＣＰ／ＩＰプロトコル処理と、第２のＴＣＰ／ＩＰプロトコル処理で共有することを特徴とする請求項１に記載の通信装置。
ＴＣＰ制御情報を、第１のＴＣＰ／ＩＰプロトコル処理と、第２のＴＣＰ／ＩＰプロトコル処理で共有することを特徴とする請求項１に記載の通信装置。
特定のアプリケーション通信の場合、優先的に第１のＴＣＰ／ＩＰプロトコル処理で実行することを特徴とする請求項２に記載の通信装置。
ネットワーク通信部と、アプリケーションシステム部とを備え、ＴＣＰ／ＩＰプロトコルを使用してアプリケーション通信を行う通信装置における通信方法であって、
該ネットワーク通信部による第１のＴＣＰ／ＩＰプロトコル処理と、該アプリケーションシステム部による第２のＴＣＰ／ＩＰプロトコル処理のいずれかを利用するアプリケーション通信を実行する工程と、
アプリケーション通信の通信状態によって、第１のＴＣＰ／ＩＰプロトコル処理と第２のＴＣＰ／ＩＰプロトコル処理のいずれでアプリケーション通信を処理するかを切り替える工程と、
を有することを特徴とする通信方法。
ＴＣＰ／ＩＰプロトコルを使用して複数のアプリケーション通信を行い、
各々のアプリケーション通信を、該ネットワーク通信部による第１のＴＣＰ／ＩＰプロトコル処理と、該アプリケーションシステム部による第２のＴＣＰ／ＩＰプロトコル処理のいずれかを利用して実行するとともに、
各々のアプリケーション通信の通信状態によって、第１のＴＣＰ／ＩＰプロトコル処理と第２のＴＣＰ／ＩＰプロトコル処理のいずれで、各々のアプリケーション通信を処理するかを切り替えることを特徴とする請求項８に記載の通信方法。
ネットワーク通信部と、アプリケーションシステム部とを備え、ＴＣＰ／ＩＰプロトコルを使用してアプリケーション通信を行う通信装置を制御するためのプログラムであって、
コンピュータに、
該ネットワーク通信部による第１のＴＣＰ／ＩＰプロトコル処理と、該アプリケーションシステム部による第２のＴＣＰ／ＩＰプロトコル処理のいずれかを利用するアプリケーション通信を実行する処理と、
アプリケーション通信の通信状態によって、第１のＴＣＰ／ＩＰプロトコル処理と第２のＴＣＰ／ＩＰプロトコル処理のいずれでアプリケーション通信を処理するかを切り替える処理と、
を実行させることを特徴とするプログラム。