(第1の実施形態)
図1は、本発明における通信装置であるアプリケーション機器の実施形態の一例を表すブロック図である。図1の101は本実施形態のアプリケーション機器を表す。この通信装置であるアプリケーション機器は、ネットワーク通信部102と、アプリケーションシステム部103とを備え、TCP/IPプロトコルを使用してアプリケーション通信を行う。102はネットワーク通信部であり、103はアプリケーションシステム部を表す。ネットワーク通信部102のローカルバス104には、ネットワーク118に接続してフレームの送受信を行う通信制御部105、ネットワーク通信部102内の主記憶装置であるローカルRAM106が接続されている。また、TCP/IPプロトコル処理を実行するプロトコル処理部107、データのバス転送を行うためのDMAコントローラ108、ネットワーク通信部102内の制御プログラムを実行する内部制御プロセッサ(ローカルCPU)109が接続している。
アプリケーションシステム部103のシステムバス111には、CPU112、システムプログラムが格納されているROM113が接続されている。また、システムプログラム実行時に使用される主記憶装置であるRAM114が接続されており、ROM113からRAM114にシステムプログラムが読み込まれ、CPU112によって実行される。また、同じくシステムバス111に接続されている115や116は、アプリケーション機器の特徴的なアプリケーション機能を実現するために使用されるハードウェア処理装置を表している。アプリケーション機能部A(116)、アプリケーション機能部B(115)という名称で示している。また、図1の117は、ネットワーク通信部102とアプリケーションシステム部103に電力供給を制御する電源制御部である。
アプリケーション機器101は、通信制御部105にネットワーク118が物理的に接続される。ネットワーク118は、例えばイーサネット(登録商標)のような有線ネットワークであるが、無線ネットワークや、光ファイバーネットワーク等であってもよい。また、ネットワーク118は、アプリケーション機器101の利用者が遠隔地からTCP/IP通信によるアプリケーション通信を行えるように、他ネットワークやインターネットに繋がっていてもよい。
ネットワーク通信部102内にある通信制御部105は、ネットワーク118に対して伝送フレームの送受信を行う機能を持つ。例えばイーサネットの場合、通信制御部105はイーサネットのMAC処理(伝送メディア制御処理)やフレームデータの送受信を行う機能が実装される。
プロトコル処理部107は、通信プロトコル処理専用の処理装置であり、汎用的なTCP/IPプロトコル処理を行う機能を有する。具体的には、IPv4、IPv6、ICMP、UDP、TCPのパケット作成処理や、送信フロー制御や輻輳制御、通信エラー制御等を行う機能を有する。プロトコル処理部107は、特にハードウェア回路(すなわちLSI)で実装することにより、種々の処理を高速化することができる。このような処理としては、各プロトコルパケットのチェックサムの計算と検証処理や、IPパケットのフラグメント(断片化)とデフラグメント(再組み立て)処理が挙げられる。また、TCPにおける送信データのセグメント(分割)処理と受信パケットからのデフラグメント(再構成)処理も挙げられる。更に、TCPパケットの再送処理、TCP通信におけるACK(肯定応答)処理等、TCP/IPプロトコルのソフトウェア処理において計算時間がかかる処理が挙げられる。
プロトコル処理部107は、アプリケーションを実行するCPU112のTCP/IPプロトコル処理をオフロードすることで、アプリケーション通信の高スループット・低遅延を実現することが可能である。
内部制御プロセッサ109は、ネットワーク通信部102の制御プログラムを実行する。制御プログラムは、ネットワーク通信部102内の各装置の動作、装置間のデータフローを制御する。また、アプリケーションシステム部103からの制御命令を受信して内部制御を行うものである。ローカルRAM106は、通信制御部105やプロトコル処理部107や内部制御プロセッサ109の処理におけるデータの一時記憶領域に使用される。
また、ネットワーク通信部102内には、ローカルバス104とアプリケーションシステム部103のシステムバス111間のデータ転送を可能とするバスブリッジ回路110が備えられている。すなわちネットワーク通信部102とアプリケーションシステム部103は、それぞれのバス回路が相互に接続されており、通信データの入出力がバス転送によって行われる。そして、データのバス転送を行う装置がDMAコントローラ(DMAC)108である。また、DMAコントローラ108はネットワーク通信部102内の装置間でデータを転送する場合にも使用する。
アプリケーション機器101のアプリケーション機能は、アプリケーションシステム部103で実現される。CPU112は、アプリケーション機能部A(116)とアプリケーション機能部B(115)の動作制御や、アプリケーション機能の一部であるアプリケーション通信を実行する。アプリケーション通信はTCP/IPプロトコルを利用した通信である。RAM114はCPU112によるプログラム実行における一時記憶領域として利用され、またネットワーク通信部102やアプリケーション機能部115及び116が使用する入出力データバッファしても使用される。CPU112が実行するシステムプログラムは、TCP/IPプロトコル処理を行うことが可能である。すなわち、アプリケーションシステム部103においては、汎用のTCP/IP通信機能を、ソフトウェアで実行する。また、パケットの送受信は、ネットワーク通信部102内の通信制御部105を経由する。
以上のようなアプリケーション機器101の実施構成において、アプリケーション通信におけるTCP/IPプロトコル処理と送受信データ処理がどのように実行されるかを、図3を示しながら示す。図3は、アプリケーション通信におけるTCP/IP通信部分の処理フローである。図3の301〜309は、それぞれ処理モジュールを表す。
301は、アプリケーション通信を行うアプリケーションである。例えばアプリケーションがファイル送信を行うFTP(File Transfer Protocol)サーバの場合は、そのサーバプログラムである。そして、FTPがTCP/IPプロトコルを利用するアプリケーションプロトコルとなる。アプリケーション301はアプリケーションシステム部103(CPU112)内で実行される。アプリケーション301は、通常ソケットインタフェース302と高速ソケットインタフェース303のいずれかのソケットインタフェースを使用して、アプリケーション通信を行う。
通常ソケットインタフェース302を使用する場合、TCP/IPプロトコル処理が、ネットワーク通信部102によるオフロード処理とアプリケーションシステム部103のCPU112によるソフトウェア処理のいずれかによって実行される。本実施形態ではアプリケーション通信毎にどちらの処理で実行するかを動的に切り替える。アプリケーション301は、どちらのTCP/IPプロトコル処理(すなわち、上記のオフロード処理、または、ソフトウェア処理)が実行されているかを識別する必要がない。
一方、アプリケーション301が高速ソケットインタフェース303を利用してアプリケーション通信を実行する場合は、優先的にネットワーク通信部102でオフロード処理するTCP/IP通信を利用する。したがって、特定のアプリケーション通信のTCP/IPプロトコル処理を常に高速処理して優先的に高スループット・低遅延で通信を実行したい場合、高速ソケットインタフェース303を使用すればよい。
上記302、303のそれぞれのソケットインタフェースは、アプリケーションシステム部103で実行されるソフトウェア処理である。
図3の304はソケット層の処理であり、305はTCP/IPプロトコル及びリンク層プロトコル処理である。304と305は共にアプリケーションシステム部103のCPU112で実行するソフトウェア処理である。通常ソケットインタフェース302を介して304の処理が実行される場合は、TCP/IPプロトコル処理をソフトウェアで実行する。304は通常ソケットインタフェース302を利用するアプリケーション301の通信ソケット処理を行う。また、各ソケットにおいて送受信データ量を計測する。計測処理は、全てのアプリケーション通信について、一定時間毎で送受信バッファ(RAM114内)の入出力データ量を計算する。
次に、305はTCP/IP処理であり、トランスポート層のプロトコルであるTCPまたはUDP、ネットワーク層のプロトコルであるIPのプロトコル処理を行う。また、トランスポート層のプロトコルにTCPを使用する通信では、TCPコネクションの状態を監視する。TCPコネクションの状態とは、RFC793に記載であるTCP通信の進行状態のことである。また、305のTCP/IP処理は、一定時間毎に各々のアプリケーション通信においてパケットの送受信回数をカウントする。さらに305ではリンク層のプロトコル処理であり、有線LAN(例えばIEEE802.3)や無線LAN(例えばIEEE802.11a/b/g)のプロトコルのフレーム送受信処理を行う。
図3の306から309はネットワーク通信部102の処理を表し、306から308はプロトコル処理部107における処理である。通常ソケットインタフェース302を介して306の処理が実行されるときは、アプリケーション通信のTCP/IPプロトコル処理をネットワーク通信部102で実行するように切り替えられている場合である。
306はソケット層処理であり、上記の304と同機能を有するが、304のソケット層処理はCPU112によるソフトウェア処理であるのに対し、306は、プロトコル処理部107によるハードウェア回路処理であり、高速な処理を可能としている。同様に306はリンク層のプロトコル処理であり、上記の305の処理と同機能を有し、プロトコル処理部107による処理である。
308は、受信パケットの解析及び送受信パケットのデータパスを切り替える処理である。パケットの送信の場合、305ではRAM114上に送信フレームが作成され、307ではローカルRAM106上に送信フレームが作成される。したがって308は、305と307のどちらの送信であるかによって、フレームの読み出し位置を変更して通信制御部105にデータ転送を行う。
一方、パケットの受信の場合は、通信制御部105から受信したフレームのデータ構造を解析する。受信フレームのリンク層、ネットワーク層、トランスポート層のプロトコルヘッダ構造を読み出して、各層のプロトコル種類と、送信元のIPアドレスと、送信元・宛て先のポート番号を取得する。そして、取得した情報から、該フレームデータを305か307のいずれの受信処理であるか判別する。また、この判別と共に、305で受信フレームデータを処理するバッファのあるRAM114か、307で受信フレームデータを処理するバッファのあるローカルRAM106かのいずれかに転送する。
309は通信制御部105の通信制御処理であり、ネットワーク118とのデータ送受信制御を実行する。
図3の310はソケット切り替え制御であり、アプリケーション機器システム全体のTCP/IP通信の処理リソースの管理を行う処理である。ネットワーク通信部102が処理可能な通信数の割り当てを管理する。そして、アプリケーション通信毎に、前述の通常ソケットインタフェース302から、304と306のどちらのソケット層処理を行うかを判定し、その切り替えを動的に行う。尚、本実施形態において、310はネットワーク通信部102内の内部制御プロセッサ109によって実行するものとして説明する。しかしながら、プロトコル処理部107でハードウェア処理するものであってもよい。
310では、ソケット層処理の切り替えの判定に必要な情報を、304、305、306、307から受け取る。前述のように、304と306のソケット層処理は、各通信において、一定時間毎で送受信バッファの入出力データ量を計算する。また、305と307のTCP/IP処理では、一定時間毎で各TCP/IP通信の送受信パケット数をカウントする。さらにTCPを使用した通信の場合、TCPコネクションの状態を監視する。これらの結果の情報はソケット切り替え制御310に送られる。ソケット切り替え制御310は、これらの情報を受信して、アプリケーション通信が304と306のどちらのソケット層処理を実行するかの切り替えの判定及び切り替えを行う。
次に、ソケット切り替え制御310の上記切り替え判定について、図4と図5を参照しながら手順を説明する。図4は、アプリケーション通信のTCP/IPプロトコル処理をネットワーク通信部102とアプリケーションシステム部103のどちらで実行するかの判定手順を示したフローチャートである。また、図5は、図4のS402の内容を別チャートで示した図である。
切り替え判定は、S401から始まり、S402では、全てのアプリケーション通信において、TCP/IPプロトコル処理を実行する優先順位を、ネットワーク通信部102で決定する。
S403からS409は、全てのアプリケーション通信を対象とする繰り返しのステップであり、各アプリケーション通信のTCP/IPプロトコル処理をネットワーク通信部102が実行するか、又はアプリケーションシステム部103で実行するかを決定する。
尚、繰り返しのステップはS402で決定した優先順位の順番で実行する。繰り返しステップ中の最初のS404では、ネットワーク通信部102が処理する通信数が限界数(所定数)以内であるかを調べ、そうであるならS405へ進み、そうでないならばS408に進む。
S405では、繰り返しステップの現在の対象であるアプリケーション通信が、TCPを利用した通信であるかを調べる。TCP通信であるならばS406においてTCPコネクションの状態を調べる。
該TCPコネクションの状態が、ESTABLISHEDであるならば、S407において、該アプリケーション通信は、ネットワーク通信部102によるTCP/IPプロトコル処理対象として決定する。ネットワーク通信部102によるTCP/IPプロトコル処理は、例えば、ネットワーク通信部102が内蔵する専用ハードウェア回路(通信制御部105、プロトコル処理部107など)での処理である。又は、ネットワーク通信部102によるTCP/IPプロトコル処理は、例えば、ネットワーク通信部102が内蔵する内部制御プロセッサ109によるソフトウェア処理と、ハードウェア回路による計算処理を組み合わせた処理である。このハードウェア回路は、通信制御部105、プロトコル処理部107などである。
また、S406において、TCPではない通信の場合(すなわち主にUDP通信の場合)は、S408に進む。
S408は、該アプリケーション通信をアプリケーションシステム部103のTCP/IPプロトコル処理対象として決定する。アプリケーションシステム部103のTCP/IPプロトコル処理は、アプリケーションシステム部103内のプロセッサ(CPU112)で実行するソフトウェア処理である。
S403からS409の繰り返しステップによって、全てのアプリケーション通信のTCP/IPプロトコル処理が、ネットワーク通信部102とアプリケーションシステム部103のいずれで実行されるかを決定する。
以上のように、TCP/IP通信の同時通信数が、TCP/IPプロトコル処理をオフロードできる限界数までは、優先的にTCP/IPプロトコル処理のオフロード手段を使用するようにする。また、該限界数を超えるTCP/IP通信は、ソフトウェア処理によって実行する。
なお、本実施形態では、アプリケーション通信の通信状態によって、ネットワーク通信部102によるTCP/IPプロトコル処理又はアプリケーションシステム部103によるTCP/IPプロトコル処理のいずれでアプリケーション通信を処理するかを切り替える。例えば、TCPコネクションを確立するまでのネゴシエーション中であるTCP状態や、TCPコネクションの終了段階であるTCP状態においては、アプリケーションシステム部103によるTCP/IPプロトコル処理を実行する。
次に、S402のステップについて、図5を参照して説明する。
S402は、前述のように全てのアプリケーション通信において、TCP/IPプロトコル処理を実行する優先順位を、ネットワーク通信部102で決定する。
図5のS501から始まり、S502において優先順位付けの基準が通信データ量であるか、通信パケット数であるかを調べる。どちらの基準とするかは、アプリケーション機器のシステムであらかじめ静的に設定されてもよいし、又は運用途中で設定変更してもよいものである。
S502で通信データ量を基準とする場合はS503に進み、通信パケット数を基準とする場合はS504に進む。
S503では、304と306のそれぞれのソケット層処理におけるソケットバッファの入出力データ量計測処理の結果を元にして、データ量の多い通信の優先順位が高くなるように優先順位付けを行う。一方、S504では、305と307の各々のTCP/IP処理において、パケットの送受信数をカウントした結果を元にして、パケット数の多い通信の優先順位が高くなるように優先順位付けを行う。
次に、S505において、S503またはS504で作成した優先順位において、高速ソケットインタフェース303を利用するアプリケーション通信が優先順位の上位となるようにする。そして、S506で優先順位決定の手順の終了となる。
このような手順でS402のステップは実行される。
ソケット切り替え制御310は、以上の切り替え判定の結果に則り、アプリケーション通信のTCP/IPプロトコル処理をネットワーク通信部102で実行するならば、判定対象のアプリケーション通信をソケット層処理モジュール306で処理する。逆に、アプリケーションシステム部103で実行するならば、判定対象のアプリケーション通信をソケット層処理モジュール304で処理する。ソケット切り替え制御310の実行は、一定時間毎に定期的に実行される。なお、本実施形態では、アプリケーション通信の通信状態によって、例えば、アプリケーション通信に一定数以上の増減が生じたタイミングにおいても、実行される。
このようにして、アプリケーション通信のTCP/IPプロトコル処理を、ネットワーク通信部102によるオフロード処理と、アプリケーションシステム部103内のCPU112によるソフトウェア処理にいずれかに、自動的に切り替えることになる。
以上、本発明の第1の実施形態を説明した。本実施形態では、同時通信数がオフロード可能な通信数よりも多いときに、TCP/IPプロトコル処理をソフトウェア処理で実行する。したがって、同時に多数の通信コネクションを開設して通信できる。また、アプリケーション機器101は、高性能なTCP/IP通信を必要とするアプリケーション通信を、優先的にネットワーク通信部102でオフロード処理するように切り替えられるので、機器全体の通信性能を向上させることが可能となる。
(第2の実施形態)
次に、本発明の第2の実施形態について説明する。ネットワークカメラは、構内LAN等に接続されて、ネットワークを介して撮影映像を配信するアプリケーション機器である。以下、本発明の実施形態の一例として、アプリケーション機器がネットワークカメラである場合について説明する。
本実施形態のネットワークカメラは、撮影静止画データ又は撮影動画データをリアルタイムに配信する機能や、ネットワークカメラと離れた場所にいる利用者が撮影開始や撮影停止、パン/チルト/ズーム等の遠隔撮影操作を行う機能を備える。また、撮影した静止画や動画を蓄積するための二次記憶装置を備えており、以前に撮影した静止画や動画データを転送する機能を備える。さらに、組込みWebサーバを備えており、PCや携帯電話等のWebブラウザから、ネットワークカメラの撮影画像の表示や、管理者による撮影設定を行うことができる機能を備える。このような各機能は全てネットワークを介した通信によって、遠隔から利用されるものである。
図6は、ネットワークカメラにおいて本発明の実施形態の一例を示すブロック図である。本実施例のネットワークカメラのシステム構成は、第1の実施形態に記載のアプリケーション機器に準ずるものである。したがって図6は図1に依拠したブロック図になっている。図6において、図1と共通の構成要素には、共通の番号を付す。
図6の601は本実施形態のネットワークカメラを表す。603はアプリケーションシステム部103に相当するカメラシステム部である。カメラシステム部603は、ネットワーク通信部102を利用して数々のアプリケーション通信を実行する。
615は二次記憶装置を表し、例えばハードディスク装置、又はCFカードやSDカード等の記憶容量が大きな不揮発性メモリ装置である。二次記憶装置615はシステムバス111に接続されており、主にネットワークカメラ601が撮影する静止画や動画データをファイル保存するために使用する。616はネットワークカメラ601の撮像部であり、レンズ、CCD(光電変換素子)、CCD制御部等を含む。撮像部616では、レンズを通して投影される撮像を、CCDによってアナログ電気信号に変換する。また、アナログ電気信号に変換された撮像画像から、ノイズ除去等の処理を施し、デジタルデータに変換するA/D変換を行う画像処理部を備えている。
617はエンコーダであり、非圧縮デジタル画像データのエンコード(圧縮符号化)を実行する。撮像部616とエンコーダ617はシステムバス111に接続されており、撮像部616が一定の周期で非圧縮デジタル画像データを出力し、エンコーダ617がその画像データをエンコードすることにより、静止画データや動画データストリームを生成する。本実施形態におけるエンコーダ617は、画像データの高速なエンコード処理を実現するハードウェア装置であり、JPEGやMPEG4を含む複数のエンコード形式に対応している。電源制御部117は、カメラシステム部603内の111から114、615から617までの各装置に対して、電源投入と、リセット、及び、カメラシステム部603全体が保持データの損失なく電源をオフにするための停止処理を開始する制御等を行う。
CPU112は、カメラシステム部603内の各装置の制御や、カメラアプリケーションを実行する。RAM114は、CPU112によるプログラム実行のために使用する主記憶装置であり、ネットワーク通信部102や、カメラシステム部603の撮像部616やエンコーダ617が使用する入出力データ領域としても使用される。ネットワークカメラ601のカメラ機能は、カメラシステム部603で実現される。
また、CPU112で実行されるシステムプログラムは、アプリケーションの機能の一部であるアプリケーション通信を行う。例えば撮影映像のストリーミング配信の場合、撮像部616が撮影した非圧縮画像フレームデータをエンコーダ617でエンコードして、圧縮画像データをRAM114に出力する。CPU112で実行するシステムプログラムは、RAM114上の圧縮画像データからストリーミングプロトコルで送信可能な形式のストリーミングデータを作成し、TCP/IP通信を利用した送信を行う。ストリーミングデータの送信では、1人以上の受信相手に対して別々にTCP/IP通信処理を行う。
図7は、本実施形態のアプリケーション通信処理を階層モデルとして示した図である。図7において、上位層の処理は下位層の処理に依存すること又は下位層の処理を利用することを表す。
最上位階層はネットワークカメラ601のシステムプログラムによるアプリケーション通信のアプリケーションプロトコル通信処理701である。アプリケーションプロトコル通信処理701は通常ソケットインタフェース702又は高速ソケットインタフェース703を介して下位通信処理に依存する。702と703はCPU112で実行するシステムプログラムにおけるアプリケーションプログラムインタフェース(API)であり、具体的には一般的な通信ソケットインタフェース互換のプログラムインタフェースである。通常ソケットインタフェース702と高速ソケットインタフェース703は、利用する下位階層処理が異なる。
図7の704から706は、CPU112で実行するシステムプログラムの一部として実装されるソフトウェア処理である。704は通信ソケット層の処理を表す。705はTCP/IP処理を行うソフトウェアであり、TCP、UDP、IP等のTCP/IPプロトコル処理を実行する。706はイーサネットプロトコル処理であり、ネットワークの物理メディアがIEEE802.3規格に準拠しているネットワークに対して、伝送フレームを作成・送受信するソフトウェア処理である。
図7の707から709はそれぞれ、704から706と同等の処理を表す。即ち、707は通信ソケット層の処理、708はTCP/IPプロトコル処理、709はイーサネットプロトコル処理である。707から709の通信処理は、プロトコル処理部107の機能であり、ハードウェア回路によって高速に処理される。710はイーサネットの通信制御処理であり、前述した通信制御部105で実行される。
図7において、通常ソケットインタフェース702を利用するアプリケーション通信は、依存する下位のTCP/IP通信処理が、704から706のTCP/IP通信処理と、707から709のTCP/IP通信処理のいずれかで実行されることを示す。そして、高速ソケットインタフェース703の場合は、下位のTCP/IP通信処理が707から709のプロトコル処理部107の処理であることを表している。
本実施形態のネットワークカメラ601において、アプリケーション通信が利用するTCP/IP通信のプロトコル処理は、CPU112で実行するソフトウェアによる処理と、プロトコル処理部107のハードウェアによる処理の2つの処理系が存在する。両者の違いは、特に処理速度である。プロトコル処理部107で実行するTCP/IPプロトコル処理は、高スループットで低遅延であるTCP/IP通信を実現するものである。そして、本実施形態において、通常ソケットインタフェース702を利用するアプリケーション通信が、通常ソケットインタフェース702から利用するTCP/IP通信処理が、いずれかの処理系に自動的に切り替えられることになる。該切り替えの仕組み、及び切り替えについては前記第1の実施形態と同様である。
ネットワークカメラ601では、撮影映像のリアルタイムストリーミング配信において、高帯域且つ低遅延であるTCP/IP通信を必要とする。本実施形態では、このような通信を優先的にネットワーク通信部102でオフロード処理するように切り替えるので、ネットワークカメラの映像配信性能を向上させることが可能である。
(第3の実施形態)
次に、本発明の第3の実施形態について説明する。本実施形態のアプリケーション機器101の構成は、図1と共通である。本実施形態において、アプリケーション通信におけるTCP/IPプロトコル処理と送受信データ処理がどのように実行されるかを説明する。図8は、アプリケーション通信におけるTCP/IP通信処理のデータフローを表している。
図8の1301は、アプリケーション機器101のTCP/IP通信処理の全体を表しており、1302〜1309の処理モジュールで構成される。なお、図8の1302〜1309において、アプリケーションシステム部103処理として破線で囲まれた処理モジュールについては、ソフトウェア処理モジュールであり、CPU112で実行する処理である。一方、ネットワーク通信部102の処理として破線で囲まれた処理モジュールについては、ハードウェア処理又はソフトウェアとハードウェアの両処理である。すなわち、これらの処理モジュールは、プロトコル処理部107、DMAコントローラ108、内部制御プロセッサ109で実行する処理である。
図8の1302は、アプリケーション通信を行うアプリケーションを示している。例えばアプリケーションがファイル送信を行うFTP(File Transfer Protocol)サーバの場合は、そのサーバプログラムである。そして、FTPがTCP/IPプロトコルを利用するアプリケーション層のプロトコルとなる。アプリケーション1302はアプリケーションシステム部103内で実行される。アプリケーション1302は、ソケットインタフェース1303を使用して、アプリケーション通信を行う。
ソケットインタフェース1303は、アプリケーション通信を行うソフトウェアが、データ送受信を行うためのインタフェースであり、アプリケーションシステム部103で実行されるソフトウェア処理モジュールである。ソケットAPIともよばれる。ソケットインタフェース1303を使用する通信において、TCP/IPプロトコル処理は、ネットワーク通信部102によるオフロード処理と、アプリケーションシステム部103のCPU112によるソフトウェア処理のいずれかによって実行される。
図9の401の表は、本実施形態において、TCP/IPのプロトコル毎に、プロトコル処理を実行する処理部と、その主な処理内容を示した表である。この表に見られるように、プロトコル別にネットワーク通信部102とアプリケーションシステム部103の両方で、アプリケーション機器101のTCP/IP通信処理を実行する。本実施形態においては、アプリケーション通信の状態によってどちらの処理で実行するかを動的に切り替えている。アプリケーション1302は、どちらのTCP/IPプロトコル処理が実行されているかを関知する必要がない。
図8の1304はソケット層の処理モジュールであり、1305はTCP/IPプロトコル処理を行うモジュールである。1304と1305は共にアプリケーションシステム部103のCPU112で実行するソフトウェア処理モジュールである。
アプリケーション通信において1304及び1305の処理が実行される場合は、TCPを利用した通信であって、且つ、以下の場合である。すなわち、TCPプロトコル処理を1305でソフトウェア実行するように切り替えられている場合と、UDPを利用した通信である場合と、TCP以外のプロトコルを利用した通信である場合である。
TCP通信において、1305のTCPプロトコル処理が行われるのは、図9の402の破線囲みで示すように、TCPコネクション確立時の通信と、TCPコネクション終了時の通信が実行されるときである。すなわち、本実施形において、TCPコネクションの確立フェーズと終了フェーズの通信処理は、アプリケーションシステム部103のCPU112で実行している。
1304は、アプリケーション通信のソケット層処理を行い、ソケットインタフェース1303を介してアプリケーションの送受信データの授受を実行する。また、TCP通信処理が1305で処理されるときには、1304と1305間で通信データを授受する。1304でソケット層処理を実行するTCP通信では、各TCPソケットにおいて送受信するデータ量を計測する。この計測処理は、全てのアプリケーション通信について、一定時間毎でソケットの送受信バッファ(RAM114内)の入出力データ量を計算し、1310のソケット切り替え処理モジュールに対して結果の通知を行う。
一方、アプリケーション通信がUDPを利用した通信の場合は、1304でソケット層処理を行う。また、UDPパケット送信処理は、TCP/IPプロトコル処理モジュール1305において実行される。UDPパケットの受信処理については後述するが、処理モジュール1307において実行している。そのため、1304は、1307との間でUDPパケットデータの授受を行う。
TCP/IPプロトコル処理モジュール1305は、主にTCP通信におけるTCPプロトコル処理、及びUDP通信の送信処理、又はTCPやUDP以外のIP上位プロトコル処理を行う。また、ICMPやARP等、アプリケーション通信で直接的に使用しないが、TCP/IP通信を行うために必要なプロトコルについても処理を行う。
さらに、1305では、TCP通信のコネクション確立・終了フェーズにおける、TCPコネクションの状態遷移を監視する。TCPコネクションの状態とは、RFC793に記載であるTCP通信の進行状態のことである。一般に、コネクション確立時のフェーズにおいてTCPコネクションの状態は、SYN_SENT、SYN_RCVDと呼ばれる状態である。そして、コネクション終了時のフェーズにおいては、FIN_WAIT1、FIN_WAIT2、LAST_ACK、CLOSING、TIME_WAIT、CLOSE_WAIT、LAST_ACKと呼ばれる状態である。また、TCPソケットにコネクションが無い状態は、CLOSEDとよばれる。すなわち、アプリケーション通信(TCP通信)が、以上のようなTCPコネクション状態においては、TCPプロトコル処理をTCP/IPプロトコル処理モジュール1305で実行する。
また、1305では、ESTABLISHED状態の全てのTCPコネクションにおいては、一定時間毎で送受信するTCPパケット数を計測し、ソケット切り替え処理モジュール1310に通知を行う。
図8の1306から1309はネットワーク通信部102の処理モジュールを表し、1306から1308は107のプロトコル処理部において実行される。
1306はTCPソケット層処理モジュールである。前述のソケット層処理モジュール1304はCPU112によるソフトウェア処理であるのに対し、TCPソケット層処理モジュール1306は、プロトコル処理部107による処理であり、高速な処理を可能としている。このTCPソケット層処理は、アプリケーション通信がTCPを利用した通信であって、且つTCPコネクションが確立中のフェーズの場合に、実行される。このときTCPコネクションは、ESTABLISHEDとよばれる状態である。1306はソケットインタフェース1303を介してアプリケーション通信の送受信データの授受を実行する。そして、1306でソケット層処理を実行するTCPソケットにおいて送受信データ量を計測する。計測処理は、全てのアプリケーション通信について、一定時間毎でソケットの送受信バッファ(ローカルRAM106内)の入出力データ量を計算し、ソケット切り替え処理モジュール1310に対して結果の通知を行う。
1307では、主にESTABLISHED状態のTCPプロトコル処理、またはUDPパケット受信時のUDPプロトコル処理を行う。また、上位層のソケット処理モジュールである1304又は1306のいずれかと通信データの授受を行う。ただし、1304とのデータ授受はUDPパケットの受信の場合だけであり、1306とのデータ授受は、TCP通信の場合のみである。アプリケーション通信の送信時は、1306から送信データを受け取り、逆に受信時には、1306に受信データを渡す。
また、1307で処理するESTABLISHED状態のTCP通信は、一定時間毎で送受信するTCPパケット数を計測し、ソケット切り替え処理モジュール1310に通知を行う。
1308は、ネットワーク通信部102内で処理される処理モジュールである。1307のTCP処理モジュールでTCPパケット送信する際に、1308においてIPヘッダを作成・付与してIPパケット作成を行う。IPパケットの受信時には、受信パケットのヘッダ構造を解析し、1305か1307のいずれかの処理モジュールに受信パケットデータを渡す。
この受信パケットの解析処理では、通信制御部105から受信したフレームのデータ構造を識別し、ネットワーク層、トランスポート層のプロトコルヘッダ部分を読み出す。フレームデータがIPパケットを含むならば、上位のプロトコル種類と、送信先・送信元のIPアドレスを取得し、さらに上位プロトコルにUDPやTCPパケットを含むならば送信元・送信先に指定されたポート番号を取得する。そして、取得した情報から、所定の判定処理により、該フレームデータを1305か1307のどちらの受信処理であるか判定する。それとともに、1305で受信フレームデータを処理するためのバッファがあるRAM114か、1307で受信フレームデータを処理するバッファのあるローカルRAM106かのいずれかに転送する。
なお、ARPフレームのようなIPパケット形式のデータを含まないフレームデータは、TCP/IPプロトコル処理モジュール1305によって送受信処理が実行される。受信パケット解析処理によって、このようなフレームデータを受信した場合は、アプリケーションシステム部に、フレームデータを渡すことになる。
図8の1309の処理は、ネットワーク通信のリンク層の処理である。有線LAN(例えばIEEE802.3)や無線LAN(例えばIEEE802.11a/b/g)等のプロトコルのフレーム送受信を行う。さらに、通信制御部105の制御を実行して、ネットワーク118に対してフレームデータを送受信する。
図8の1310はソケット切り替え処理モジュールであり、アプリケーション機器システム全体におけるTCP/IP通信の処理リソースの管理を行う。ネットワーク通信部が処理可能な通信数の割り当てを管理する。尚、本実施形態において、1310はネットワーク通信部102内の内部制御プロセッサ109によって実行するものとして説明する。しかしながら、プロトコル処理部107でハードウェア処理するものであってもよい。
1310では、ソケットインタフェース1303を利用するアプリケーション通信毎に、アプリケーションシステム部とネットワーク通信部のどちらのソケット層処理を行うべきかを判定し、その切り替え処理を行う。ソケット層処理の切り替えの判定に必要な情報は、1304、1305、1306、1307から通知される。アプリケーション通信がTCPを下位プロトコルとする場合、1305と1307における処理において、TCPコネクションの状態を監視し、状態の変化をソケット切り替え処理1310に通知する。この通知を基に、ソケット切り替え処理1310は、各アプリケーション通信のTCPプロトコル処理について、1304と1305のアプリケーションシステム部103による処理と、1306と1307のネットワーク通信部102による処理を切り替える。さらに、ネットワーク通信部102で通信処理が可能TCPコネクション数の管理を行う。この管理では、ネットワーク通信部102の1306と1307でTCPプロトコル処理を実行している全てのTCPソケット数について、あらかじめ決められた上限数を超えないように制限する。
次に、TCP通信において、ネットワーク通信部102とアプリケーションシステム部103のTCPプロトコル処理の切り替えについて、説明する。
図10はTCP通信フローの一例を簡易に表した図である。図10では、クライアント501と、サーバ502が、TCPコネクションを確立し、データの送受信を実行し、コネクションを終了するまでの通信を示している。また、クライアント501がTCPコネクションの開設を要求する側として表現している。
クライアント501からTCPコネクション確立要求503が送信され、サーバ502はこの要求を受信すると、確立要求に対する確認応答として(SYN,ACK)504を返信する。コネクション確立要求503は、TCPパケットヘッダの制御ビット(Control Bits)フィールドにおいて、SYNビットが1であるパケットである。したがって、単純にSYNパケットともよばれる。確立要求に対する確認応答は、同じくTCPパケットヘッダの制御ビットフィールドにおいて、SYNとACKビットが1であるパケットである。クライアント501は、(SYN,ACK)パケット504を受信すると、確認応答(ACK)505を送信する。この3つのTCPパケット送受信のフェーズ512は、TCPの一般的なコネクション確立時の通信であり、3ウェイハンドシェイクとよばれる。
クライアント501とサーバ502の間でTCPコネクションが確立中の場合において、両者はアプリケーションデータの送受信を行う。図の506〜508の矢印で、コネクション確立中のフェーズ513のデータ送受信を表している。
そして、クライアント501から、コネクション終了を要求するパケット509を送信する。パケット509は、TCPパケットヘッダの制御ビットフィールドにおいて、FINビットが1であるパケットである。サーバ502は、コネクション終了要求としてパケット509を受信すると、サーバ502からも、クライアント501からの終了要求に対する確認応答とサーバ502側の終了要求を意味するTCPパケット510を送信する。クライアント501は、(FIN,ACK)パケット510を受信すると、確認応答511を送信する。このような514の範囲の通信手順により、コネクション終了フェーズの通信が行われる。
本実施形態では、図10のTCP通信フローの例で示したコネクション確立時のフェーズ512と、コネクション終了フェーズ514のTCPプロトコル処理を、アプリケーションシステム部103で実行する。また、コネクション確立中フェーズ513では、ネットワーク通信部102又はアプリケーションシステム部103で実行する。つまり、TCPを利用するアプリケーション通信は、TCPコネクションの状態に応じて、TCPプロトコル処理を実行する処理部が切り替えることを行う。
図10のTCP通信フローを例に挙げ、TCP通信処理が、ネットワーク通信部102とアプリケーションシステム部103によって、どのように実行され、またTCPコネクション毎のTCPプロトコル処理がどのように切り替わるかを、説明する。この説明では、図11から図20の図を参照する。
最初に、アプリケーション機器101からTCPコネクションの開設を要求する場合について、図11を参照して述べる。図11では、クライアント501のように、TCPコネクション確立を要求する側のフローチャートを表している。図11の左側の「処理部」の欄は、フローチャートの各ステップの処理が、ネットワーク通信部102と、アプリケーションシステム部103のいずれの処理部で実行するかを示している。すなわち、図11では全ての処理ステップが、アプリケーションシステム部103内だけで実行することを示している。また、TCP通信は、RFC793に見られる状態遷移が行われており、図11の右側の「TCP状態」の欄に、フローチャートに沿ったTCPコネクションの状態遷移を示している。
TCPコネクションの確立要求の処理フローは、S601から始まり、S602において、TCP通信を行うための新しいTCPソケットを生成する。このとき、TCPソケットで使用する送信用と受信用の各々バッファは、RAM114上に確保する。
次に、S603において、開始するTCP通信のTCB(TCP Control Block)を生成する。TCBは、TCP通信の制御を行うためのコンテキスト情報(TCP制御情報)であり、数十個のパラメータの集合体データである。TCBはTCPコネクション毎に生成し、TCPソケットと結び付けて管理される。そして、夫々のTCP通信処理を行う際に、各パラメータの値を参照・更新して利用される。アプリケーションシステム部103は、S603において、TCBをRAM114上に作成する。次に、S604でTCPソケットテーブルに、ソケットペア情報を登録する。ソケットペア情報とは、TCPコネクションにおける両方のエンドポイントのIPアドレスと、TCPポート番号の組のことである。この場合は、ソケットペア情報とは、アプリケーション機器101における、IPアドレス及びTCPコネクションを開設するためのポート番号と、通信相手側のIPアドレス及びTCPポート番号との組である。また、TCPソケットテーブルとは、アプリケーション機器101で処理している全てのTCP通信(TCPコネクション確立フェーズ/終了フェーズを含む)のソケットペアが登録されたデータベースである。
TCPソケットテーブルは、ネットワーク通信部102内のプロトコル処理部107で管理されている。TCPソケットテーブルには、ソケットペア情報と一緒に、各ソケットペアを使用しているTCPソケットの番号と、ネットワーク通信部102とアプリケーションシステム部103のどちらで現在処理されているかを示す情報を記録している。
TCPソケットテーブルへのソケットペア情報の登録/削除は、アプリケーションシステム部103内のCPU112で実行するソフトウェア(ドライバ)で行う。さて、S604の段階では、新しく作成したTCPソケットは未だコネクションを持たないので、TCP状態がCLOSEDの状態である。次に、S605において、SYNパケットを送信し、TCPコネクションの開設を通信相手に要求する。すなわち、図10の通信フローにおいて503の送信を行う。次に、S606に進んで処理フローは終了するが、S605のSYN送信によって、TCP状態は、CLOSEDからSYN_SENTに遷移している。
続いて、コネクション確立要求(SYN)を送信したSYN_SENT状態において、通信相手からSYNに対する確認応答(SYN,ACK)パケットを受信するときの処理フローを、図12のフローチャートを参照しながら説明する。
S701から始まり、ネットワーク通信部102は、S702において、受信したTCPパケットのヘッダ構造を解析し、ソケットペア情報を取得して、TCPソケットテーブルの検索を実行する。そして、S703において、このパケットを受信するべきTCPソケットが存在するかを調べる。このS702の処理は、図8の1307と1308の処理モジュールで実行する。すなわち、1308でTCPパケットのヘッダ情報を読み出すことで、ソケットペア情報を取得し、1307に通知する。そして、処理モジュール1307においてTCPソケットテーブルを検索し、受信すべきソケットが存在するかを判定し、1308に検索結果を返す。S703では、受信TCPパケットを受信可能なTCPソケットが存在しない場合はS704の処理に進み、存在する場合は、S706への処理へと進む。
S704では、受信パケットを受理できないため、該TCPパケットの送信元であるTCPソケットに対して、強制切断を意味する(RST,ACK)パケットを送信する。このパケットは、TCPヘッダの制御ビットにおいて、RSTビットとACKビットを立てたパケットである。この返送するTCPパケットは、図8の処理モジュール1307において作成する。S704で(RST,ACK)パケットを送信した場合、S705に進んで終了する。
S703からS706へと進んだ場合は、受信したTCPパケットを受信可能なTCPソケットが存在する場合である。該TCPソケットは、SYN_SENTの状態であることから、アプリケーションシステム部103で受信処理されるので、S706において、該受信TCPパケットをアプリケーションシステム部103へ転送する。また、TCPソケットテーブル検索時にヒットしたソケット番号をTCP/IPプロトコル処理モジュール1305に対して通知する。このS706は、図8の処理モジュール1308で処理し、アプリケーションシステム部103内のRAM114のパケット受信バッファに転送する。
次に、S707に進むと、TCPパケットの受信処理がなされ、S708に進んで確認応答(ACK)パケットを送信する。この確認応答パケットの送信は、図10における505のACKで示されるTCPパケット送信である。S707とS708は、図8のTCP/IPプロトコル処理モジュール1305で処理する。すなわちアプリケーションシステム部103内で実行される。
S708で確認応答パケットを送信すると、S709に進み、ソケット切り替え処理が行われる。S709では、図8のTCP/IPプロトコル処理モジュール1305から、ソケット切り替え処理モジュール1310に通知を行い、以降において該TCPについて、ソケット層処理とTCPプロトコル処理を、ネットワーク通信部102で実行されるように切り替える。ソケット切り替え処理モジュール1310への通知には、TCPソケット番号、及び該TCPソケットにリンクされる送信用バッファと受信用バッファのメモリアドレス、及びTCBの情報が含まれる。TCBの通知方法としては、RAM114上に存在するTCBデータのメモリアドレスを通知するか、又はTCBのデータ内容を通知するようにしてもよい。なお、以下の記述において、ソケット切り替え処理モジュール1310への通知とは、これらの情報が含まれる。
なお、ソケット切り替え処理モジュール1310の処理では、必ずしも該TCPソケットに関するプロトコル処理を、ネットワーク通信部102内で処理実行するように切り替えるわけでない。ネットワーク通信部102で処理可能なTCPコネクション数が、上限に達している場合には、切り替え処理は実行されない。この場合、アプリケーションシステム部103内で、TCP通信処理が実行される。
S709でTCPソケットの処理モジュールの切り替え処理が終わると、S710に進んで該(SYN,ACK)パケット受信処理フローが正常に終了する。このとき、図12の右側の欄に示されているように、該TCPコネクションのTCP状態は、SYN_SENTから、ESTABLISHEDへと遷移する。
ここまでで、図11と図12を参照しながら、図10のTCPコネクション確立フェーズ512において、アプリケーション機器101が、図10のクライアント501側のようにコネクションの開設を要求する場合の処理内容について説明した。
次に、図10のTCPコネクション確立フェーズ512において、アプリケーション機器101が、図10のサーバ502のようにTCPコネクションの開設要求を受け付ける側である場合について説明する。一般に、TCP通信では、通信相手からのコネクション確立要求を受け付けるために、LISTEN状態のTCPソケットで待ち受けている必要がある。本実施形態のアプリケーション機器101では、コネクションの確立要求(SYN)を受け付け中の全てのTCPソケットの情報を、LISTENテーブルと呼ぶデータベースに保持している。このLISTENテーブルは、ネットワーク通信部102内のプロトコル処理部107で管理している。TCP通信を行うアプリケーションは、TCPコネクションの確立要求を待ち受けるために、LISTEN状態のTCPソケットを作成する。この処理を図13のフローチャートを参照しながら説明する。
図13のS801から始まり、アプリケーションからのTCPソケット生成と、コネクション待ち受け状態へ移行の指示に従い、S802において新しいTCPソケットを生成する。S802で作成されたTCPソケットは、CLOSEDの状態である。作成したTCPソケットをLISTEN状態にするために、図8のソケット切り替え処理モジュール1310に、LISTENテーブルへの登録指示を通知する。この登録指示には、コネクション確立要求を受け付けるソケットの番号、及び待ち受けのための自局IPアドレスとTCPポート番号の組とを付加する。ここまでの処理は、アプリケーションシステム部103内のTCPソケット層処理モジュール1304で実行される。
次に、S802からS803に進み、ソケット切り替え処理モジュール1310によって、生成された新TCPソケットの処理部が切り替えられ、ネットワーク通信部102内でTCPプロトコル処理が行われるようになる。次に、S804において、図8のTCP処理1307モジュールにより、前述のLISTENテーブルに、TCPコネクションの確立要求を待ち受ける自局のIPアドレスとポート番号の組と、そのTCPソケット番号を登録する。そして、S805に進んで終了する。このような処理により、新TCPソケットはCLOSED状態からLISTEN状態へ遷移する。
TCPコネクションを開設する要求を受信したときには、宛先IPアドレスとポート番号の組をキーとしてLISTENテーブルを検索して、該宛先条件に一致するエントリが存在するかを判定することになる。すなわち、コネクション確立要求の宛先として指定された登録されたTCPソケットが存在するかを判定し、存在するならばTCPコネクションの確立が可能となる。
続いて、TCP通信の通信相手から、コネクション確立要求のTCPパケット(SYNパケット)を受信したときの処理フローを、図14を参照しながら説明する。処理フローは、S901から始まり、まず、ネットワーク通信部102内で、S902において、受信したTCPパケットのヘッダ構造を解析してソケットペア情報を取得し、LISTENテーブルの検索を実行する。このS902の処理は、図8の1307と1308に処理モジュールで実行する。1308でTCPパケットのヘッダ情報を読み出すことで、ソケットペア情報を取得し、1307に通知する。そして、1307の処理モジュールにおいてLISTENテーブルを検索し、受信すべきソケットが存在するかを判定し、1308に検索結果を返す。
S903では、受信TCPパケット(SYNパケット)を受信可能なLISTEN状態のTCPソケットが存在しない場合、言い換えるとコネクション確立要求を受け入れるTCPソケットが存在しない場合はS904の処理に進む。存在する場合は、S906への処理へと進む。S904では、受信パケットを受理できないので、該TCPパケットの送信元であるTCPソケットに対して、強制切断を意味する(RST,ACK)パケットを送信し、S905に進んで終了する。
S903からS906へと進んだ場合は、受信したTCPパケット(SYNパケット)を受信可能なTCPソケットが存在する場合である。S906では、該受信TCPパケットをアプリケーションシステム部103へと転送する。このS906は、図8の処理モジュール1308で処理し、アプリケーションシステム部103内のRAM114のパケット受信バッファに転送する。また、LISTENテーブル検索時にヒットしたソケット番号をTCP/IPプロトコル処理モジュール1305に対して通知する。
次に、S907に進む。S907からの処理フローは、アプリケーションシステム部103内で処理する。S907では確立するTCPコネクションのための新しいTCPソケットを作成し、次に、S908において、このTCPソケットの通信に使用する新TCBを作成する。このとき、TCPソケットで使用する送信用と受信用の各々バッファは、RAM114上に確保する。次に、S909でTCPソケットテーブルに、新たに作成したTCPソケットのソケットペア情報を登録する。S909のTCPソケットテーブルへの登録処理は、アプリケーション機器101からTCPコネクションの開設を要求する場合における図11のS604の処理と同様であり、詳細な説明は省略する。S909の後、S910へと進み、TCP処理モジュール1307で、コネクションの確立要求の確認応答であるTCPパケット(SYN,ACK)を送信する。この送信されるTCPパケットは、図10の504に示されるものである。
以上のように、このS910の処理により、新たに生成されたTCPコネクションは、CLOSEDの状態から、SYN_RCVD状態へと遷移することになる。
続いて、(SYN,ACK)のTCPパケットの送信で、SYN_RCVD状態へと遷移したTCPコネクションにおいて、通信相手からの確認応答(ACK)を受信した場合の処理フローを、図15を参照しながら説明する。図15の処理フローでは、受信するTCPパケットが、図10の通信フロー例における505の確認応答(ACK)パケットを意味する。
図15の処理フローはS1001から開始し、ネットワーク通信部102内で、S1002において、受信したTCPパケットのヘッダ構造を解析し、ソケットペア情報を取得して、TCPソケットテーブルの検索を実行する。そして、S1003において、このパケットを受信するべきTCPソケットが存在するかを調べる。このS1002の処理は、前述の図12におけるS702の処理ステップと同処理を行う。S1003では、受信TCPパケットを受信可能なTCPソケットが存在しない場合はS1004の処理に進み、存在する場合は、S1006への処理へと進む。S1004では、受信パケットを受理できないので、該TCPパケットの送信元であるTCPソケットに対して、強制切断を意味する(RST,ACK)パケットを送信し、S1005に進んで終了する。
S1003からS1006へと進んだ場合は、受信したTCPパケットを受信可能なTCPソケットが存在する場合である。S1006では、該受信TCPパケットをアプリケーションシステム部103へと転送する。S1006は、前述した図12のS706の処理ステップと同処理を実行する。次に、S1007に進み、受信TCPパケットが受信処理される。
そして、S1008に進み、ソケット切り替え処理が行われる。S1008では、図8のTCP/IPプロトコル処理モジュール1305から、ソケット切り替え処理モジュール1310に通知を行い、以降において該TCPについて、ソケット層処理とTCPプロトコル処理を、ネットワーク通信部102で実行されるように切り替える。このS1008の処理ステップについても、前述のS709の処理と同処理を実行する。
なお、ソケット切り替え処理モジュール1310の処理では、必ずしも該TCPソケットに関するプロトコル処理を、ネットワーク通信部102内で処理実行するように切り替えるわけでない。ネットワーク通信部102で処理可能なTCPコネクション数が、上限に達している場合には、切り替え処理は実行されない。この場合、アプリケーションシステム部103内で、TCP通信処理が実行される。
S1008でTCPソケットの処理モジュールの切り替え処理が完了すると、S1009に進み、該受信TCPパケット(ACK)の処理フローが正常に終了する。このとき、図15の右側の欄に示されているように、該TCPコネクションのTCP状態は、SYN_RCVDから、ESTABLISHEDへと遷移する。
図13、図14及び図15を参照しながら、図10のTCPコネクション確立フェーズ512において、アプリケーション機器101が、図10のサーバ502側のようにコネクションの開設を要求される場合の処理内容について説明した。
次に、TCPコネクションがESTABLISHED状態であるとき、データの送受信の処理内容について説明する。図10に示す通信フロー例では、513のTCPコネクション確立中フェーズの通信を意味する。TCPコネクションが確立中である状態は、ESTABLISHED状態とよばれている。本実施形態において、図11〜図15を参照して前述したように、各TCPのコネクションのESTABLISHED状態では、ネットワーク通信部102内でTCPプロトコル処理が実行される。
図16は、コネクション確立中のデータ送信の処理フローであり、ESTABLISHED状態のTCP通信のデータ送信処理を表している。図16において、まず、S1101から始まり、S1102において、TCPソケット処理をネットワーク通信部102で実行するか否かを判定する。S1102の処理は、図8のソケットインタフェース1303で行われる。ソケット切り替え処理モジュール1310によって、該TCP通信のTCPソケット層処理を、ネットワーク通信部102内で処理するように切り替えられていた場合は、S1103に進む。そうでないならば、アプリケーションシステム部103で処理するようになっていることを意味し、S1105に進む。S1103とS1105は共にTCPデータ送信処理である。図16のS1103とS1105では、TCP通信のデータ送信時における、送信フロー制御や輻輳制御、送信データのセグメント(分割)処理や、TCPパケットの再送処理等が実行される。そして、S1106で処理が終了する。
一方、図17は、コネクション確立中のデータ受信時の処理フローである。この処理フローはS1201から始まり、ネットワーク通信部102は、まず、S1202において、受信したTCPパケットのヘッダ構造を解析し、ソケットペア情報を取得して、TCPソケットテーブルの検索を実行する。そして、S1203において、このパケットを受信するべきTCPソケットが存在するかを調べる。このS1202の処理は、前述の図12の702の処理と同処理を実行する。S1203では、受信TCPパケットを受信可能なTCPソケットが存在しない場合、S1204の処理に進み、存在する場合は、S1206への処理へと進む。S1204では、受信TCPパケットを受理できないので、該TCPパケットの送信元であるTCPソケットに対して、強制切断を意味する(RST,ACK)パケットを送信し、S1205に進んで終了する。
S1203からS1206へと進んだ場合は、受信したTCPパケットを受信可能なTCPソケットが存在する場合である。S1206では、受信したTCPパケットを受信処理する処理部がネットワーク通信部102であるか否かを判定する。図8のソケット切り替え処理モジュール1310によって、該TCP通信のTCPソケット層処理を、ネットワーク通信部102内で処理するように切り替えられていた場合は、S1207に進む。そうでないならば、アプリケーションシステム部103で処理するようになっていることを意味し、S1212に進む。S1207からS1211では、ネットワーク通信部102の処理である。一方、S1212からS1216は、アプリケーションシステム部103の処理である。
S1207では、該受信TCPパケットについて、TCPプロトコル処理を実行する。S1207の処理のあと、S1208において受信TCPパケットのデータに対して、即ACK送信が必要であるならば、S1209で受信確認応答(ACK)パケットを送信し、S1210に進む。即ACK送信が必要でなければS1208からS1210へと進む。S1210では、TCPソケット層の受信処理が実行される。この処理は、図8のTCPソケット層処理モジュール1306で実行され、アプリケーションのソケットインタフェース1303を介したデータ受信要求に対し、アプリケーションの受信バッファメモリに受信データを転送する処理を実行する。そして、S1210からS1211に進み、処理フローは終了する。
S1206からS1212へ進んだ場合は、S1212において、該受信TCPパケットのTCPプロトコル処理を実行する。S1212の処理のあと、S1213において受信TCPパケットのデータに対して、即ACK送信が必要であるならば、S1214で受信確認応答(ACK)パケットを送信し、S1215に進む。即ACK送信が必要でなければ、S1213からS1215へと進む。S1215では、TCPソケット層の受信処理が実行される。この処理は、図8のTCPソケット層処理モジュール1304で実行され、アプリケーションのソケットインタフェース1303を介したデータ受信要求に対し、アプリケーションの受信バッファメモリに受信データを転送する処理を実行する。そして、S1215からS1216に進み、処理フローは終了する。
尚、S1207とS1212では、受信パケットからの受信データのリオーダリング(再構成)処理や、受信データに対するACK送信の判定処理や、通信相手からのACK受信による送信ウィンドウ制御等が実行される。
ここまで、図16と図17を参照しながら、図10のTCPコネクション確立中フェーズ513において、アプリケーション機器101のデータ送受信の処理内容について説明した。
次に、アプリケーション機器101からTCPコネクションの終了を要求する場合の処理内容を、図18と図19を参照して説明する。図10の通信フロー例において、コネクション終了フェーズ514のクライアント501側の通信動作を行うこととして説明する。まず、TCPコネクションがESTABLISHEDである状態から、TCPコネクションの終了要求を送信する。そして、通信相手からの、送信した終了要求に対する確認応答と、通信相手からの終了要求を受信し、最後に通信相手からの終了要求に対する確認応答を送信する。
図18の処理フローは、ESTABLISHED状態のTCPソケットを使用するアプリケーションが、ソケットインタフェース1303を介して、TCPソケットのクローズを指示することで、開始する。処理フローはS1301から始まり、まず、S1302においてTCPソケット処理をネットワーク通信部102で実行するか否かを判定する。S1302の処理は、図8のソケットインタフェース1303で行われる。ソケット切り替え処理モジュール1310によって、該TCP通信のTCPソケット層処理を、ネットワーク通信部102内で処理するように切り替えられていた場合は、S11303に進む。そうでないならば、アプリケーションシステム部103で処理するようになっていることを意味し、S1306に進む。S1303からS1305は、ネットワーク通信部102内の処理であり、S1306からS1307はアプリケーションシステム部103の処理である。
S1303においてTCPコネクションの終了を要求するTCPパケットを送信する。これは図10の通信フローの例で、509のFIN送信を意味する。TCPコネクションの終了要求の送信は、図8のTCP処理モジュール1307において実行する。送信TCPパケットは、TCPパケットヘッダの制御ビットフィールド中のFINビットが1である。
次に、S1304に進み、該TCPコネクションにおけるTCPプロトコル処理を、以降においてアプリケーションシステム部103内で処理されるように、TCPソケットの切り替え処理を行う。図8の処理モジュール1307から、ソケット切り替え処理モジュール1310に通知を行い、該TCPソケットの処理を、ネットワーク通信部102からアプリケーションシステム部103に移す。これにより、該TCPソケットに関して、TCPプロトコル処理及びソケット層の処理を、図8の1304と1305の処理モジュールで行うことになる。そして、S1305に進んで終了する。TCPコネクションのTCP状態は、ESTABLISEHDからFIN_WAIT1に遷移する。
S1302からS1306に進んだ場合は、まず、S1306において、TCPコネクションの終了を要求するTCPパケットを送信する。これは図10の通信フローの例で、509のFIN送信を意味する。TCPコネクションの終了要求の送信は、図8のTCP/IPプロトコル処理モジュール1305において実行する。そして、S1307に進んで終了する。TCPコネクションのTCP状態は、ESTABLISEHDからFIN_WAIT1に遷移する。
図10の通信フロー例では、510の通信に示されるように、通信相手側から、先に送信したコネクション終了要求(FIN)に対する確認応答と、通信相手からの終了要求の両方を意味するTCPパケット(FIN,ACK)を受信する。このときの処理フローを、図19で示している。図18で示したように、アプリケーション機器101側から先にコネクション終了要求(FIN)を送信していることから、図19では、該TCPコネクションのTCP状態は、FIN_WAIT1の状態となっている。
図19は、S1401から始まり、ネットワーク通信部102が、S1402において、受信したTCPパケットのヘッダ構造を解析し、ソケットペア情報を取得して、TCPソケットテーブルの検索を実行する。そして、S1403において、このパケットを受信するべきTCPソケットが存在するかを調べる。このS1402の処理は、前述の図12のS702と同処理を実行する。S1403では、受信TCPパケットを受信可能なTCPソケットが存在しない場合はS1404の処理に進み、存在する場合は、S1406への処理へと進む。S1404では、受信パケットを受理できないので、該TCPパケットの送信元であるTCPソケットに対して、強制切断を意味する(RST,ACK)パケットを送信し、S1405に進んで終了する。
S1403からS1406へと進んだ場合は、受信したTCPパケットを受信可能なTCPソケットが存在する場合である。S1406では、該受信TCPパケットをアプリケーションシステム部103内のRAM114のパケット受信バッファに転送する。また、TCPソケットテーブル検索時にヒットしたソケット番号を1305のTCP/IP処理モジュールに対して通知する。
次に、S1407に進む。S1407からS1409までの処理ステップは、アプリケーションシステム部103において実行される。S1407において、TCPパケットの受信処理を行い、該TCPパケットは通信相手からの(FIN,ACK)パケットであるので、S1408に進んで確認応答(ACK)を送信する。この確認応答パケットの送信は、図10における511のACKで示されるTCPパケット送信である。ここまでの処理ステップにより、該TCPコネクションの状態は、FIN_WAIT1からTIME_WAITへと遷移する。
S1409では、TIME_WAIT状態で2MSL(Max Segment Lifetime)時間だけタイムアウト待ちの状態となる。このタイムアウト後にTIME_WAIT状態からCLOSED状態となり、該TCPコネクションは終了する。
図18と図19を参照しながら、図10のTCPコネクション終了フェーズ514において、アプリケーション機器101が、図10のクライアント501側のように通信動作する場合の処理内容について説明した。509のFIN送信処理は、TCPコネクションはESTABLISHED状態であり、ネットワーク通信部102で実行する。そして、TCPプロトコル処理を実行する処理部を切り替え、510の(FIN,ACK)受信時と、及び511のACK送信時の処理は、アプリケーションシステム部103において実行する。
次に、アプリケーション機器101の通信相手から、TCPコネクションの終了を要求される場合の処理内容を、図20を参照して説明する。図10の通信フロー例において、コネクション終了フェーズ514のサーバ502側の通信動作を行うこととして説明する。まず、TCPコネクションがESTABLISHEDである状態で、通信相手が送信したTCPコネクションの終了要求を受信し、該終了要求に対する確認応答と、アプリケーション機器101側から終了要求を意味するTCPパケットを送信することを実行する。
図20の処理フローは、TCPコネクションが確立中であるESTABLISHED状態において、通信相手からTCPコネクションの終了要求(FIN)を受信することによって開始される。処理フローはS1501から開始し、まず、ネットワーク通信部102は、S1502において、受信したTCPパケットのヘッダ構造を解析し、ソケットペア情報を取得して、TCPソケットテーブルの検索を実行する。そして、S1503において、このパケットを受信するべきTCPソケットが存在するかを調べる。このS1502の処理は、図12のS702と同処理を実行する。S1503では、受信TCPパケットを受信可能なTCPソケットが存在しない場合はS1504の処理に進み、存在する場合は、S1506への処理へと進む。S1504では、受信パケットを受理できないので、該TCPパケットの送信元であるTCPソケットに対して、強制切断を意味する(RST,ACK)パケットを送信する。S1504で(RST,ACK)パケットを送信した場合は、S1505に進んで終了する。
S1503からS1506へと進んだ場合は、受信したTCPパケットを受信可能なTCPソケットが存在する場合である。S1506では、受信したTCPパケットを受信処理する処理部がネットワーク通信部102であるか否かを判定する。図8のソケット切り替え処理モジュール1310によって、該TCP通信のTCPソケット層処理を、ネットワーク通信部102内で処理するように切り替えられていた場合は、S1507に進む。そうでないならば、アプリケーションシステム部103で処理するようになっていることを意味し、S1511に進む。S1507からS1510では、ネットワーク通信部102の処理である。一方、S1511からS1513は、アプリケーションシステム部103の処理である。
S1507では、該TCPパケットの受信処理を行い、続いてS1508に進む。該TCPパケットは通信相手からのコネクション終了要求(FIN)であるので、FINに対する確認応答と、アプリケーション機器101側からのコネクション終了要求を合わせたTCPパケット(FIN,ACK)を送信する。そして、S1509に進み、以降において、該TCPソケットの処理をアプリケーションシステム部103内で処理されるように、ソケット切り替え処理を行う。図8の処理モジュール1307から、ソケット切り替え処理モジュール1310に通知を行い、該TCPソケットの処理を、ネットワーク通信部102からアプリケーションシステム部103に移す。これにより、該TCPソケットに関して、TCPプロトコル処理及びソケット層の処理を、図8の1304と1305の処理モジュールで行うことになる。その後、S1510に進んで終了する。
S1506からS1511に進んだ場合は、S1511において、該TCPパケットの受信処理を行い、続いてS1512に進む。該TCPパケットは通信相手からのコネクション終了要求(FIN)であるので、FINに対する確認応答と、アプリケーション機器101側からのコネクション終了要求を合わせたTCPパケット(FIN,ACK)を送信する。そして、S1513に進んで、処理フローが終了する。
図20を参照しながら、図10のTCPコネクション終了フェーズ514において、アプリケーション機器101が、図10のサーバ502側のように通信動作する場合の処理内容について説明した。509のFINの受信処理は、TCPコネクションがESTABLISHED状態であり、510の(FIN,ACK)送信までをネットワーク通信部102で実行する。TCPコネクションは終了され、CLOSED状態に遷移する。同時に該ソケットについての処理はアプリケーションシステム部103内で実行されるように切り替えられる。
次に、本実施形態において、図8の1310のソケット切り替え処理モジュールでおけるTCP通信を処理実行する処理部の切り替えの判定方法について説明する。
TCP通信が、アプリケーションシステム部103からネットワーク通信部102の処理に切り替えられるための条件は、まず、第1にTCPコネクションの状態がESTABLISHEDであることである。この理由は、アプリケーション機器が高速なデータ送受信処理が必要とするのは、アプリケーション通信データを送受信するときであり、即ちTCPコネクションが確立中のときだからである。
第2に、ネットワーク通信部102で処理可能なTCPコネクション数が限界数以内であるときである。前述したように図12のS709や、図15のS1008の処理ステップは、TCPコネクションがESTABLISHEDの状態に遷移するため、TCPプロトコル処理の処理部を切り替える処理を実行する。その時点においてネットワーク通信部102で処理可能なTCPコネクション数が上限に達していないならば、該TCP通信処理がネットワーク通信部102内で実行されるように切り替えが実行される。しかし、その時点においてネットワーク通信部102で処理可能なTCPコネクション数が上限に達してしまっていた場合、ネットワーク通信部102の処理に切り替えを行わないで、以降においてアプリケーションシステム部103側でTCP通信処理を実行する。
本実施形態においては、前述の通り、図8の1305、1307の処理モジュールが、TCPプロトコル処理を行っているESTABLISHED状態TCPコネクションについて、一定時間毎に送受信パケット数を計測している。また、図8の1304、1306のTCPソケット層処理のモジュールは、一定時間毎にアプリケーションが送受信するデータ量を計測している。図8のソケット切り替え処理モジュール1310では、1304、1305、1306、1307から計測結果の通知を受け取りながら、優先順位の情報を作成・更新する。ここでは、ESTABLISHED状態の全てのTCP通信において、送受信パケット数の多いTCP通信、あるいは送受信データ量の大きいTCP通信が、ネットワーク通信部102でTCPプロトコル処理が実行されるように優先順位の情報を作成・更新する。
ネットワーク通信部102で処理しているTCP通信が上限数に達している状態において、ネットワーク通信部102でTCPプロトコル処理していたTCP通信の状態が、ESTABLISHED状態から遷移すると、該TCP通信は切り替えられる。すなわち、ここでは、該TCP通信はアプリケーションシステム部103で処理されるように切り替えられる。したがって、アプリケーションシステム部103で処理実行されているESTABLISHED状態のTCP通信を、ネットワーク通信部102での処理に切り替える。この入れ替えの際に、先に述べた優先順位の情報を基に、TCPソケットを選択して入れ替える。
尚、ネットワーク通信部102で処理しているTCP通信が上限数に達している状態においては、ネットワーク通信部102とアプリケーションシステム部103の其々がTCPプロトコル処理を実行するTCP通信を、定期的に入れ替え判定を行ってもよい。その際に、前記の優先順位の情報を基にして、入れ替え処理を行う。
また、特定のアプリケーション通信を識別し、該アプリケーション通信がESTABLISHED状態では、ネットワーク通信部102でのTCPプロトコル処理で優先実行するように切り替えを行っても良い。これは、アプリケーション機器101の特定のTCPポート番号をあらかじめ予約しておき、特定アプリケーションで使用するなどにより、実現可能である。さらに、優先度の高いTCP通信のコネクションがESTABLISHED状態に遷移し、TCPプロトコル処理の切り替え処理が発生したとき、ネットワーク通信部102で処理可能なTCPコネクション数が上限に達していても、優先度の低いコネクションと交換する。
次に、図8のソケット切り替え処理モジュール1310でおけるTCP通信を処理実行する処理部の切り替えについて処理内容について、図21を参照しながら説明する。
図21の1601は、アプリケーションシステム部103のTCP/IP処理モジュールを示しており、図8の1305の処理モジュールと同義である。1602は、ネットワーク通信部102のTCP処理モジュールを示し、図8の1307の処理モジュールと同義である。1603は、ソケット切り替え処理モジュールを表し、図8の1310の処理モジュールと同義である。TCPソケット通信において、TCPプロトコル処理の切り替えは、1602と1603間で処理を実行する側を変更することを意味する。
また、1604と1605は、それぞれTCP通信処理の切り替え対象であるTCPソケットの送信用バッファと受信用バッファ(TCP送受信バッファ)を示しており、1606は、該TCPソケットに結び付けられたTCBを示している。図11のS602、S603や、図14のS907やS908の処理ステップについて前述したように、1604、1605、1606のデータは、アプリケーションシステム部103内のRAM114上に確保される。本実施形態において、1601と1602の処理モジュール間でTCPプロトコル処理を切り替えた場合でも、これらのデータバッファは、RAM114上にそのまま据え置かれる。言い換えると、切り替えによってデータコピー等は行わず、切り替え後もRAM114上の同じデータに対してread/writeを行う。即ちこれらのデータをRAM114上で、1601と1602の両処理モジュール間で共有し、該TCPソケットを処理するモジュールが、データに対するアクセスを行う。
TCPソケット通信のプロトコル処理の切り替えは、1601と1602のどちらか一方から、ソケット切り替え処理モジュール1603に対して切り替えの通知を行う。通知内容には、TCPソケット番号、送信用・受信用のソケットバッファ1604、1605のメモリアドレス、TCB1606のメモリアドレスを通知する。ソケット切り替え処理モジュール1603は、切り替え先である処理モジュールに対して、これらの情報を伝達する。
また、1607は、1601で処理するパケットが転送される受信バッファであり、1608は、1602で処理するパケットが転送される受信バッファである。1607は、ネットワーク通信部102内のローカルRAM106上に配置し、1608は、アプリケーションシステム部103内のRAM114内に配置する。前述のように、受信パケットについて、TCPソケットテーブルを検索し、該TCPパケットを受理するTCPソケット番号と、どちらかのTCPプロトコル処理モジュールで処理されるかを知るようになっている。そして、1607か1608のいずれかのパケット受信バッファにパケットデータが転送される。
そして、ソケット切り替え処理1603は、TCPソケット切り替え処理において、TCPソケットテーブルの該TCPソケットのエントリに、どちらで処理されるかの情報を書き換えることも行う。
以上、TCP通信を利用したアプリケーション通信のTCPプロトコル処理とTCPソケット層処理について、TCPコネクションの状態遷移に応じて、ネットワーク通信部102とアプリケーションシステム部103で処理部を切り替えることを説明した。
アプリケーション通信を高速化するには、TCP通信においてコネクション確立中の状態(ESTABLISHED)において、高速に通信処理が実行されればよい。従ってこのフェーズにおけるTCPプロトコル処理をネットワーク通信部102内で実行することで、アプリケーション通信を高速化が可能となる。同時にアプリケーションシステム部のCPU112のTCP通信処理負荷をオフロードすることができる。
なお、本発明の実施形態は、例えばコンピュータがプログラムを実行することによって実現することができる。また、プログラムをコンピュータに供給するための手段、例えばかかるプログラムを記録したCD−ROM等のコンピュータ読み取り可能な記録媒体又はかかるプログラムを伝送するインターネット等の伝送媒体も本発明の実施形態として適用することができる。また、上記のプログラムも本発明の実施形態として適用することができる。上記のプログラム、記録媒体、伝送媒体及びプログラムプロダクトは、本発明の範疇に含まれる。