JP2009230476A - メッセージを処理する装置、方法およびプログラム - Google Patents

Abstract

【課題】処理負荷の増大を抑止するメッセージ処理装置を提供すること。
【解決手段】メッセージの送信または受信に関する処理であるネットワーク処理を実行可能な第１演算部１３０と、ネットワーク処理と、ネットワーク処理に関連してメッセージに対して実行される予め定められた特定処理を実行可能な第２演算部１４０と、メッセージの種類を識別する識別情報と、ネットワーク処理および特定処理を連続して実行する制御命令列と、を対応づけた処理情報を記憶する代行処理管理表１２１と、を備え、第１演算部１３０は、メッセージから識別情報を検出する識別情報検出部１３２と、検出された識別情報に対応する制御命令列を代行処理管理表１２１から取得し、取得した制御命令列を第２演算部１４０で実行するように制御する制御部１３７と、を備えた。
【選択図】 図１

Description

この発明は、ネットワークを介して送受信するメッセージを複数の演算部によって処理する装置、方法およびプログラムに関する。

動画像処理や暗号処理には多くの計算資源を必要とする。このため、これらの処理を実行する装置を構成する際には、メインのプロセッサに加えて動画像処理や暗号処理を実行する専用のハードウェアを搭載し、そのハードウェアを使って処理を代行させることが一般的に行われている。さらに別の方法として、マルチコアプロセッサのような汎用的な演算部を複数備えるプロセッサを用い、動画像処理や暗号処理を特定の演算部に優先的または独占的に割り当てることで処理を代行させることも行われている。

近年は、ネットワークを介して、遠隔の装置との間で大量のデータを高速で交換する需要が高まっている。動画像処理や暗号処理と同様に、大容量のデータを高速に伝送するネットワーク処理も多くの計算資源を必要とする。このため、ネットワーク処理を行う専用のハードウェアを搭載する方法や、複数の演算部を備えるプロセッサの特定の演算部を優先的または独占的にネットワーク処理に割り当てる方法が用いられることがある。

また、近年は、暗号化された動画像を高速で伝送する需要も高まっている。このようなネットワークノードを実現するため、処理の内容が異なる複数の専用ハードウェアを連続して用いることで一連の処理を代行させる方法や、複数の処理を一つのハードウェアで実現した高機能な専用ハードウェアを用いて一連の処理を代行させる方法も広く行われている。

例えば、特許文献１では、ネットワークインターフェイスとネットワーク処理と動画像処理とを一つの専用ハードウェアデバイスとして実現し、メインのプロセッサの負荷を低減する技術が提案されている。

特開２００６−１０９０１６号公報

しかしながら、動画像処理とネットワーク処理のような一連の処理を、複数の専用ハードウェアを連続して用いて代行させる方法では、各専用ハードウェアをメインのプロセッサが制御する必要がある。このため、処理の複雑化やデータの移動に伴うオーバヘッドの増加が生じるという問題があった。これを解決するためには、一連の処理を一括して代行させる手法が有効である。しかし、一つの高機能な専用ハードウェアを用いて一括代行する方法では、代行できる処理が限定され、柔軟性を欠くという問題があった。

本発明は、上記に鑑みてなされたものであって、メインの演算部の処理を他の演算部に代行させる場合の処理負荷の増大を抑止できる装置、方法およびプログラムを提供することを目的とする。

上述した課題を解決し、目的を達成するために、本発明は、処理内容を定めた制御命令列を実行可能な第１演算部と、前記第１演算部と同一または異なる制御命令列を実行可能な第２演算部と、メッセージの種類を識別する識別情報と、前記メッセージの送信または受信に関する処理であるネットワーク処理および前記ネットワーク処理に関連して前記メッセージに対して実行される特定処理を連続して実行する制御命令列と、を対応づけた処理情報を記憶する記憶部と、を備え、前記第１演算部は、前記メッセージから前記識別情報を検出する識別情報検出部と、検出された前記識別情報に対応する制御命令列を前記記憶部から取得し、取得した制御命令列を実行するように前記第２演算部を制御する制御部と、を備えたことを特徴とする。

また、本発明は、上記装置を実行することができる方法およびプログラムである。

本発明によれば、メインの演算部の処理を他の演算部に代行させる場合の処理負荷の増大を抑止できるという効果を奏する。

以下に添付図面を参照して、この発明にかかる装置、方法およびプログラムの最良な実施の形態を詳細に説明する。

（第１の実施の形態）
第１の実施の形態にかかるメッセージ処理装置は、複数の汎用的な演算部を備え、メインの演算部（第１演算部）で実行されるネットワーク処理に伴って他の演算部（第２演算部）で代行して実行される暗号化処理などの特定処理を検出し、ネットワーク処理と特定処理とを連続して実行する制御命令列を生成して記憶部に保存する。そして、以降、該当するメッセージ（パケット）に対しては、第２演算部が、保存した制御命令列を用いてネットワーク処理と特定処理とを連続して実行する。

なお、第１の実施の形態では、（１）ネットワークインターフェイス（Ｉ／Ｆ）部でパケットを受信すると、ハードウェア割り込みが第１演算部に対して通知されること、（２）ハードウェア割り込みの通知を受けたメインの演算部は、受信パケットを処理するための割り込みハンドラ（以下の割込処理部）を実行する機構を備えること、を前提とする。

図１は、第１の実施の形態にかかるメッセージ処理装置１００の構成を示すブロック図である。図１に示すように、メッセージ処理装置１００は、ネットワークＩ／Ｆ部１１０と、メインメモリ１２０と、第１演算部１３０と、第２演算部１４０と、各構成部を接続するバス１５０と、を備えている。

ネットワークＩ／Ｆ部１１０は、メッセージ処理装置１００が外部の装置との間でパケットを送受信するためのデバイスである。

メインメモリ１２０は、各種プログラムやメッセージ処理で扱われる各種データを記憶するＲＡＭ（Random Access Memory）などの記憶装置である。なお、メインメモリ１２０はＲＡＭに限られるものではなく、メモリカード、光ディスク、ＨＤＤ（Hard Disk Drive）などの一般的に利用されているあらゆる記憶媒体により構成することができる。メインメモリ１２０は、パケットのフロー情報と、第２演算部１４０で代行処理される制御命令列との対応関係を管理する代行処理管理表１２１を格納する。

図２は、代行処理管理表１２１に格納されるデータのデータ構造の一例を示す図である。図２に示すように、代行処理管理表１２１は、フロー情報と、プロセス情報と、制御命令列と、付加情報とを対応づけたデータである処理情報（以下、代行処理情報という）を格納する。代行処理管理表１２１では、１行が１つのエントリ（代行処理情報）を形成している。

フロー情報は、パケットの種類を識別するための識別情報である。フロー情報は、パケットを構成する特定の情報の集合として構成される。例えば、パケットに含まれるＭＡＣアドレス、ＩＰアドレス、ＴＣＰポート番号またはＵＤＰポート番号、およびＩＰｓｅｃなどのプロトコルを識別するプロトコル情報、ＩＰｓｅｃのＳＰＩ（Security Parameter Index）などのプロトコルで使用するパラメータを識別する識別子のうち、少なくとも１つをフロー情報として利用できる。すなわち、これらの情報を単独でフロー情報として用いてもよいし、複数組み合わせてフロー情報としてもよい。フロー情報により、パケットをグループに分類することができる。

プロセス情報は、パケットを処理するプロセスのプロセスＩＤ、または代行処理を依頼するプロセスのプロセスＩＤなどの、各プロセスを識別する識別子である。なお、プロセス情報はプロセスＩＤに限られず、メッセージ処理装置１００中でプロセスを一意に識別可能な識別子であればあらゆる情報を利用できる。例えば、特定の処理を表す識別子と、特定の処理の内部で固有に定められる情報を結合したものを識別子として使うように構成してもよい。より具体的には、ＩＰｓｅｃ処理を特定する識別子（例えばプロトコル番号）とＩＰｓｅｃのＳＰＩを結合して識別子としてもよい。さらに、複数の識別子を使う場合には、識別子の種別を特定する情報（例えばプロセスＩＤ、ＩＰｓｅｃ ＳＰＩなどを示す値）を付け加えた上で各識別子を管理するように構成してもよい。

制御命令列は、ネットワーク処理と、データを処理する特定処理と、その他の付随する処理とを連続して実行するための命令列である。特定処理は、例えば、ネットワークを介して受信した一つ以上のパケットにデータとして含まれていたデータに対する復号処理などが該当する。また、付随する処理は、例えば、受信したデータのサイズが復号処理に必要なデータサイズに達しているか否かを判定する判定処理などが該当する。なお、付随する処理はこれに限られるものではない。また、制御命令列フィールドには、制御命令列自体を指定してもよいし、制御命令列が格納されているメモリのアドレスを指定するように構成してもよい。

付加情報は、代行処理依頼時に付加的に通知する情報である。付加情報には、例えば、暗号処理のアルゴリズムや、暗号・復号処理で使用する鍵情報が設定される。なお、付加情報フィールドには、付加情報自体を指定してもよいし、付加情報が格納されているメモリのアドレスを指定するように構成してもよい。

図２では、フロー情報として、パケットの送信元ＩＰアドレス（ＳｒｃＩＰ）、宛先ＩＰアドレス（ＤｓｔＩＰ）、プロトコル情報（Ｐｒｏｔｏ）、およびセキュリティプロトコルで使用するパラメータを識別する識別子（ＳＰＩ）を利用する例が示されている。これらの情報は、例えばＩＰｓｅｃのＳＡ（Security Association）から取得することができる。

なお、ＳＡは、ＳｒｃＩＰ＝１０．０．０．１、ＤｓｔＩＰ＝１０．１．１．１、Ｐｒｏｔｏ＝ＥＳＰ、ＳＰＩ＝１２３４５、Ａｌｇｏ＝ＤＥＳ（Data Encryption Standard）−ＣＢＣ（Cipher Block Chaining）、Ｋｅｙ＝０ｘ１１２２３３４４５５６６７７８８などの情報を含んでいる。ここで、Ａｌｇｏとは暗号アルゴリズムを意味し、Ｋｅｙとは暗号処理で使用する鍵情報を意味する。同図は、このようなＳＡから取得したフロー情報を設定した例を示している。

また、同図では、受信したパケットを処理するプロセスがＩＰｓｅｃ処理を実行するプロセスであり、ＩＰｓｅｃ処理であることを示す識別子ＩＰＳＥＣと、一意に定まるＳＰＩとを含む情報をプロセス情報として利用する例が示されている。また、同図の付加情報は、ＳＡのＡｌｇｏおよびＫｅｙで指定された各情報が保存されたバッファのアドレスを指定することを意味している。

制御命令列には、生成部１３５によって生成された制御命令列が設定される。制御命令列の詳細については後述する。

なお、代行処理管理表１２１に記載されたエントリは、プロセス情報で識別されるプロセスが消滅したとき、プロセスが更なるパケットの送受信を要求しなくなったとき、およびプロセスが一定時間パケットを送受信していないことを検出したときなどに削除する。エントリの削除処理は、ＯＳ（Operating System）のプロセス管理機構と連携して実行するように構成してもよい。例えば、ＯＳが該当するプロセスが消滅したことを検出したときに、対応するエントリを削除するように構成することができる。また、定期的に専用のガーベージコレクションを実行するように構成してもよい。

図１に戻り、第１演算部１３０は、メインの演算部に相当する演算部であり、主にパケットの送受信に関するネットワーク処理を実行する。また、第１演算部１３０は、第２演算部１４０で実行する処理の割り当て等の制御を行う。第１演算部１３０は、割込処理部１３１と、識別情報検出部１３２と、パケット処理部１３３と、プロセス検出部１３４と、生成部１３５と、保存部１３６と、制御部１３７と、を備えている。

割込処理部１３１は、ネットワークＩ／Ｆ部１１０によって通知されたハードウェア割り込みを検出したときに、パケットを受信する受信処理を実行する。

識別情報検出部１３２は、受信したパケットまたは送信したパケットからフロー情報を検出する。例えば、識別情報検出部１３２は、ネットワークＩ／Ｆ部１１０によってパケットが受信された場合に、受信したパケットに含まれるフロー情報を検出する。

より具体的には、識別情報検出部１３２は、データリンク層、ネットワーク層、およびトランスポート層などにそれぞれ対応するパケットのヘッダから、上述のＭＡＣアドレス、ＩＰアドレス、ＴＣＰポート番号、およびＵＤＰポート番号などのフロー情報を検出する。また、識別情報検出部１３２が、ＶＰＮ（Virtual Private Network）でトンネルを形成するために使用するヘッダなどを表す中間ヘッダからフロー情報を検出するように構成してもよい。さらに、識別情報検出部１３２が、ＩＰｓｅｃのＥＳＰヘッダ、ＡＨヘッダなどの付随するヘッダからフロー情報を検出するように構成してもよい。

パケット処理部１３３は、ネットワークＩ／Ｆ部１１０を介してパケットを送受信するための所定のパケット処理を実行する。例えば、パケット処理部１３３は、受信したパケットのヘッダ部分の解析や通信プロトコル処理、およびネットワークＩ／Ｆ部１１０から送信するためのパケットのヘッダ部分の作成や通信プロトコル処理を行う。

プロセス検出部１３４は、ネットワーク処理で処理されるパケットを入力するプロセスまたは出力するプロセスを検出する。具体的には、プロセス検出部１３４は、受信したパケットを利用するプロセス、または送信するパケットを生成するプロセスのプロセスＩＤを検出する。また、プロセス検出部１３４は、代行が依頼された処理（代行処理）を検出し、検出した代行処理の依頼元のプロセスのプロセスＩＤを検出する。

生成部１３５は、プロセス検出部１３４によって検出された、パケットを入出力するプロセスと、代行処理の依頼元のプロセスとが一致するか否かを判定し、一致する場合に、ネットワーク処理と代行処理とを連続して実行する制御命令列を生成する。なお、生成部１３５は、ネットワーク処理、およびプロセス検出部１３４によって検出された代行処理の実行順序を判定し、判定した実行順序で各処理を連続して実行する制御命令列を生成する。例えば、生成部１３５は、代行処理の前後に実行されたネットワーク処理の内容を記憶部等に保存しておき、保存した情報からネットワーク処理および代行処理の実行順序を判定する。ＩＰｓｅｃ処理のように代行処理の前後で実行するネットワーク処理が事前に定められている場合は、生成部１３５は、適切な処理と実行順序を仮定して制御命令列を生成するように構成してもよい。

ここで、生成部１３５によって生成される制御命令列の詳細について説明する。以下では、パケットを受信する場合を例に説明するが、パケットを送信する場合も同様の方法を適用できる。また、説明にあたって次の記法を導入する。
（１）Ｉｍ：第１演算部１３０で処理されるネットワーク処理のうち、割り込みハンドラ内で実行される処理
（２）Ｎｍ：第１演算部１３０で処理されるネットワーク処理のうち、割り込みハンドラ外で実行される処理
（３）Ｎｓ：第２演算部１４０で処理されるネットワーク処理
（４）Ｐ：受信したパケットの受信先となるプロセス
（５）Ｏｓ：第２演算部１４０で処理される代行処理
（６）Ｉｎｓ（＊）：上記各処理に対応する制御命令列（＊には、Ｉｍ、Ｎｍ、Ｎｓ、Ｐ、Ｏｓのいずれかが設定される）

第１の実施の形態では、少なくともネットワーク処理に関する制御命令列であるＩｎｓ（Ｎｓ）および代行処理に関する制御命令列であるＩｎｓ（Ｏｓ）を含む、代行処理すべき内容について記述された二つ以上の制御命令列が事前に定められていることを前提とする。

Ｉｎｓ（Ｎｓ）に対応するネットワーク処理が、プロトコルスタック内のいずれのネットワーク処理に対応するかについては、様々なケースが考えられる。例えば、ネットワーク処理全体を一つの制御命令列とする場合や、各プロトコルを個別の制御命令列とする場合などが考えられる。

ここでは、ネットワーク処理全体が一つの制御命令列として構成されていた場合を例に説明する。上述の通り、第２演算部１４０でネットワーク処理を実行するための制御命令列Ｉｎｓ（Ｎｓ）は事前に用意される。Ｉｎｓ（Ｎｓ）は、受信したパケットを処理するプロセスに無関係に静的に用意されるものとする。例えば、第１演算部１３０で実行するプロトコルスタックの実行コードをコンパイル等により生成するときに、合わせて第２演算部１４０で実行する実行コードをコンパイル等により生成する。これにより、制御命令列Ｉｎｓ（Ｎｓ）を事前に用意することができる。

このようにして生成される処理ごとの制御命令列は、実行環境に合わせた適切な形式で、常時実行可能な状態でＨＤＤ等の記憶部（図示せず）に保存される。例えば、動的にロード可能なカーネルモジュールやダイナミックリンクライブラリといった形式で保存することができる。また、他のプログラム等に対して静的に埋め込まれており、実行時にメモリ上に展開されるようにしてもよい。

以上のような方法を用いて、処理ごとの制御命令列は、第２演算部１４０に対して通知できる状態になっている。

このような前提で、ネットワーク処理（Ｎｍ）によって処理されたパケットを消費するプロセスと、代行処理（Ｏｓ）を依頼するプロセスが同一であることが分かると、生成部１３５は、各処理の制御命令列を結合した制御命令列Ｉｎｓ（Ｎｓ）｜Ｉｎｓ（Ｏｓ）を生成する。ここで記号「｜」は制御命令列を結合することを意味する。なお、ネットワーク処理Ｎｓとネットワーク処理Ｎｍとは、ノード内で一意に管理しなければならない値（例えばポート番号）などに対する扱いは異なると考えられるが、それ以外は原則として同じ処理である。

第２演算部１４０は、結合された制御命令列を解釈し、記号「｜」で区切られた各制御命令列を、左から順に連続して実行する。なお、生成部１３５が生成する制御命令列の形式はこれに限られず、第２演算部１４０が、各処理の制御命令列を連続して実行すること、および各制御命令列の実行順序を解釈できるものであればあらゆる形式を適用できる。例えば、生成部１３５が、各制御命令列に相当するダイナミックリンクライブラリをメモリ上の連続する領域にロードすることにより、複数の処理を連続して実行する制御命令列を生成するように構成してもよい。この場合、第２演算部１４０は、ロードしたメモリの先頭アドレスから処理を実行することにより、複数の処理を連続して実行することができる。

保存部１３６は、識別情報検出部１３２によってパケットから検出されたフロー情報と、生成部１３５によって生成された制御命令列とを含む代行処理情報を代行処理管理表１２１に保存する。なお、保存部１３６は、パケットを受信する場合は、まずパケット受信時にフロー情報とプロセス情報のみを含むエントリ（代行処理情報）を保存し、代行処理実行時に、生成された制御命令列を保存済みのエントリに追加する（詳細は後述）。また、保存部１３６は、パケットを送信する場合は、まず代行処理実行時に依頼元のプロセスのプロセス情報のみを含むエントリを保存し、パケット送信時に、フロー情報と制御命令列とを保存済みのエントリに追加する（詳細は後述）。

制御部１３７は、識別情報検出部１３２によって検出されたフロー情報に対応する制御命令列を代行処理管理表１２１から取得し、取得した制御命令列を第２演算部１４０で代行処理するように制御する。

第２演算部１４０は、第１演算部１３０からの要求等に応じて各種処理を実行する演算部である。第２演算部１４０は、上述のように、少なくともネットワーク処理Ｎｓおよび代行処理Ｏｓを実行することができる。第２演算部１４０は、第２演算部１４０内での処理で利用するデータ等を格納するローカルメモリ１４１と、代行処理を含む実際の演算処理を実行する演算処理部１４２とを備えている。

次に、このように構成された第１の実施の形態にかかるメッセージ処理装置１００によるメッセージ処理について説明する。メッセージ処理には、パケットを受信するときの処理であるパケット受信処理（図３）、および、パケット受信時に代行処理を検出して制御命令列を生成する命令列生成処理（図４）が含まれる。なお、パケットを送信するときの処理については後述する（図１５および図１６）。

図３は、第１の実施の形態におけるパケット受信処理の全体の流れを示すフローチャートである。

まず、ネットワークＩ／Ｆ部１１０にパケットが到着すると、ハードウェア割込みが通知され、割込処理部１３１が起動される。そして、割込処理部１３１は、パケットの受信処理を実行する（ステップＳ３０１）。

次に、識別情報検出部１３２は、受信したパケットからフロー情報を検出する（ステップＳ３０２）。次に、識別情報検出部１３２は、検出したフロー情報を含むエントリが、代行処理管理表１２１に記憶されているか否かを判断する（ステップＳ３０３）。

なお、ステップＳ３０２〜ステップＳ３０３を割込処理部１３１内で実行するように構成してもよい。すなわち、割込処理部１３１内でフロー情報の検出とエントリの確認を実行するように構成してもよい。

検出したフロー情報を含むエントリが代行処理管理表１２１に記憶されていない場合（ステップＳ３０３：ＮＯ）、パケット処理部１３３が、受信したパケットに対する通常のパケット処理を実行する（ステップＳ３０４）。

次に、プロセス検出部１３４が、パケットの受信先プロセスの識別子を検出する（ステップＳ３０５）。プロセス検出部１３４は、例えば、ＯＳが管理するプロセス管理情報から、受信先プロセスに対応するプロセスＩＤを検出することができる。

次に、生成部１３５が、ステップＳ３０２で検出されたフロー情報と、ステップＳ３０５で検出されたプロセスＩＤとを含むエントリ（代行処理情報）を作成する（ステップＳ３０６）。なお、生成部１３５は、エントリに含めるべき情報のうち、この時点で判明していない情報は空欄とする。そして、保存部１３６が、作成されたエントリを代行処理管理表１２１に保存する（ステップＳ３０７）。

ステップＳ３０３で、検出したフロー情報を含むエントリが代行処理管理表１２１に記憶されていると判断された場合（ステップＳ３０３：ＹＥＳ）、生成部１３５は、エントリ内に制御命令列が設定されているか否かを判断する（ステップＳ３０８）。

設定されている場合（ステップＳ３０８：ＹＥＳ）、制御部１３７は、第２演算部１４０に対して、設定済みの制御命令列による代行処理を依頼する（ステップＳ３０９）。例えば、制御部１３７は、受信したパケットを格納したメモリのアドレスと、制御命令列が格納されたメモリのアドレスとを通知することで代行処理を依頼する。なお、処理の依頼に伴って通知する情報はこれらに限られるものではない。例えば、これまでに処理されたパケットのサイズなどの付加情報を合わせて通知してもよい。このような付加情報は代行処理管理表１２１の付加情報フィールドに記録される。代行処理を依頼後、パケット受信処理を終了する。

ステップＳ３０８で、エントリ内に制御命令列が設定されていないと判断された場合（ステップＳ３０８：ＮＯ）、パケット処理部１３３が、受信したパケットに対する通常のパケット処理を実行する（ステップＳ３１０）。

ステップＳ３０７、ステップＳ３０９、またはステップＳ３１０の後、パケット処理部１３３は、処理後のパケットを、パケットを受信する受信先のプロセスに引き継ぎ（ステップＳ３１１）、パケット受信処理を終了する。引き継ぐプロセスは、パケットに含まれるポート番号等によって特定することができる。

次に、パケット受信時の命令列生成処理について説明する。図４は、第１の実施の形態におけるパケット受信時の命令列生成処理の全体の流れを示すフローチャートである。

なお、本処理はパケット受信処理とは無関係に開始される。例えば、ＯＳの起動時や代行を処理するデバイスドライバを有効化したときに開始するように構成することができる。また、図３のステップＳ３１０等で代行処理を依頼するときに開始するように構成してもよい。

まず、プロセス検出部１３４は、代行処理が実行されたか否かを判断する（ステップＳ４０１）。代行処理が実行されていない場合は（ステップＳ４０１：ＮＯ）、代行処理の実行が検出されるまで待機する。なお、プロセス検出部１３４は、例えば、代行処理に対応するダイナミックリンクライブラリ名などの代行処理を特定可能な情報を予め記憶しておき、ＯＳが管理するプロセス管理情報に当該情報が含まれることにより代行処理の実行を検出する。

代行処理が実行された場合は（ステップＳ４０１：ＹＥＳ）、プロセス検出部１３４は、代行処理の依頼元のプロセスのプロセスＩＤを検出する。例えば、プロセス検出部１３４は、ＯＳが管理するプロセス管理情報を参照することにより、ステップＳ４０１で検出した代行処理の依頼元のプロセスのプロセスＩＤを検出することができる。

次に、生成部１３５は、検出したプロセスＩＤに対応するエントリが代行処理管理表１２１に記憶されているか否かを判断する（ステップＳ４０３）。記憶されている場合（ステップＳ４０３：ＹＥＳ）、生成部１３５は、さらに、エントリ内に制御命令列が設定されているか否かを判断する（ステップＳ４０４）。

制御命令列が設定されていない場合（ステップＳ４０４：ＮＯ）、生成部１３５は、ステップＳ４０１で検出された代行処理の制御命令列と、別途保存されているネットワーク処理を代行させるための制御命令列とを、適切な実行順序で連続して実行する制御命令列を生成する（ステップＳ４０５）。実行順序は、上述のようにネットワーク処理の内容に応じて事前に決定されている順序を用いてもよいし、事前に実行順序を判定して保存した情報を参照して決定してもよい。

なお、ネットワーク処理や代行処理に付随する処理が存在する場合は、生成部１３５は、付随する処理の制御命令列を適切な実行順序で実行する制御命令列を生成する。付随する処理の制御命令列は、例えば対応するネットワーク処理の制御命令列に予め対応づけておくことなどにより取得することができる。

代行させるネットワーク処理は、すべてのプロセスに対応できる汎用的なものでもよいし、パケット受信処理のステップＳ３０４で実行したパケット処理の内容に限定するものであってもよい。いずれの場合であっても、ネットワークを介して受信したパケットに適したプロトコル処理が含まれていればよい。

次に、保存部１３６は、生成された制御命令列を代行処理管理表１２１の対応するエントリに設定する（ステップＳ４０６）。例えば、保存部１３６は、生成された制御命令列をメインメモリ１２０に保存し、保存したアドレスを代行処理管理表１２１のエントリに格納する。

ステップＳ４０３で、検出したプロセスＩＤに対応するエントリが代行処理管理表１２１に記憶されていないと判断された場合（ステップＳ４０３：ＮＯ）、または、ステップＳ４０４で、エントリ内に制御命令列が設定されていると判断された場合（ステップＳ４０４：ＹＥＳ）、パケット受信時の命令列生成処理を終了する。

なお、本処理は、同図に示すように代行処理を検出するごとに終了するようにしてもよいし、無限ループして終了しないように構成してもよい。

図３のフローチャートに示すように、一度、代行処理管理表１２１に制御命令列が登録されると、以降の処理の大半は第２演算部１４０に対して割り当てられる。これにより、第１演算部１３０の処理負荷を低減することができる。また、従来の方法ように専用ハードウェアと第１演算部１３０との間で頻繁に処理が移ることもないため、オーバヘッドが大きく削減される。一方、図４で示される命令列生成処理の実行回数は必要最低限となるため、大きな負荷要因にはならない。

ここで、第１の実施の形態の方法によって得られる効果についてさらに説明する。最初に、第１の実施の形態のメッセージ処理装置１００のハードウェア構成の変形例について説明する。

図１では、１つの第２演算部１４０を含む構成が示されているが、複数の第２演算部１４０を備えるように構成してもよい。図５は、このように構成されたメッセージ処理装置５００のハードウェア構成図である。図５に示すように、本変形例のメッセージ処理装置５００は、２つの第２演算部１４０ａ、１４０ｂを備えている。例えば、第２演算部１４０ａ、１４０ｂは、それぞれ予め定められた固有の代行処理を実行するように構成する。なお、第２演算部１４０を３つ以上備えるように構成してもよい。

また、図１の第２演算部１４０を、ネットワークＩ／Ｆ部内に備えるように構成することもできる。図６は、このように構成されたメッセージ処理装置６００のハードウェア構成図である。図６に示すように、本変形例のメッセージ処理装置６００は、第２演算部１４０をネットワークＩ／Ｆ部６１０内に備えている。

第１演算部１３０と、複数の第２演算部１４０とを備えたマルチコアプロセッサを利用するように構成してもよい。図７は、このように構成されたメッセージ処理装置７００のハードウェア構成図である。図７に示すように、本変形例のメッセージ処理装置７００は、マルチコアプロセッサ７６０内に、１つの第１演算部１３０と、４つの第２演算部１４０ａ〜１４０ｄとを備えている。なお、第２演算部１４０の個数は４つに限られるものではない。また、第１演算部１３０を複数備えるように構成してもよい。

図５〜図７のメッセージ処理装置は、第２演算部１４０の個数および設置箇所が異なるのみであるため、図１のメッセージ処理装置１００と同様の方法を適用できる。

次に、図１、図５または図６のようなハードウェア構成の装置で、第１の実施の形態の方法を適用しない場合のメッセージ処理の例について図８〜図１０を用いて説明する。

図８は、図１と同様に、１つの第１演算部と１つの第２演算部を用いて処理が実行される例を示す模式図である。横向きの矢印は時刻の変化を表しており、左から右に行くほど時刻が新しいことを示す。また、両矢印上に記された四角は、ある処理が実行されている部分を表している。四角の内部に記載されたアルファベットは、それぞれ上述した記法による処理を表している。

図８は、ネットワークＩ／Ｆ部がパケットを受信したことによって第１演算部に通知された割り込みを契機として実行される一連の処理の流れを示している。第１演算部の割り込みハンドラ（割込処理部１３１）は、規定の処理８１０（Ｉｍ）を実行すると、通常のネットワーク処理８１１（Ｎｍ）に処理を引き継ぐ。ネットワーク処理８１１（Ｎｍ）は、受信先のプロセスを特定する処理を含む。その結果、次の処理として処理８１２（Ｐ）が実行される。

ここで、受信先プロセスは、処理の途中で処理８１３（Ｏｓ）を代行処理するように実装されているとする。このため、処理の途中で処理８１３（Ｏｓ）を第２演算部で実行している。処理８１３（Ｏｓ）の実行が完了すると、第１演算部に戻り、受信先プロセスの残りの処理８１４（Ｐ）が再開される。なお、同図のシーケンスを実現するにあたり、第２演算部を動作させるための制御命令列Ｉｎｓ（Ｏｓ）は、実行可能なプログラムコードとして事前に準備されているものとする。

図９は、図５のように、１つの第１演算部と２つの第２演算部を用いて処理が実行される例を示す模式図である。この例では、ネットワーク処理９０１（Ｎｍ）の後に、ネットワーク処理の一部である処理９０２（Ｎｓ）が第２演算部のうちの１つで代行処理されている。処理９０３は、ネットワーク処理の残りの処理を表す。また、この例では、処理９０４（Ｏｓ）が、もう１つの第２演算部で代行処理されている。なお、同図のシーケンスを実現するにあたり、第２演算部を動作させるための制御命令列Ｉｎｓ（Ｎｓ）やＩｎｓ（Ｏｓ）は、実行可能なプログラムコードとして事前に準備されているとする。

図１０は、図６のように、１つの第１演算部とネットワークＩ／Ｆ部に備えられた第２演算部を用いて処理が実行される例を示す模式図である。この例では、ネットワークＩ／Ｆ部上に第２演算部が実装されるため、第２演算部で実行されるネットワーク処理１０１０（Ｎｓ）と代行処理１０１４（Ｏｓ）が連続して実行される。そして、ネットワーク処理１０１０（Ｎｓ）が完了した段階で割り込みハンドラ（割込処理部１３１）による処理１０１１（Ｉｍ）が第１演算部で実行される。その後、必要最小限のネットワーク処理１０１２（Ｎｍ）が実行される。事前に実行された代行処理１０１４（Ｏｓ）の結果は最後に実行される処理１０１３（Ｐ）によって利用される。

図８および図９の例は、プロセスの処理の間に代行処理が実行されることなどにより、処理の複雑化やデータの移動に伴うオーバヘッドの増加という問題が発生する。図１０の例は、プロセスの処理の間の代行処理は存在しないため、図８および図９の方法と比較すると効率的である。しかし、図１０を実現する構成である図６は、第２演算部を含んだ専用のネットワークＩ／Ｆ部を使用しなければならない。

これに対し、第１の実施の形態は、上述のように専用のネットワークＩ／Ｆ部を備えることなく、汎用の演算部のみを用いて、メインの演算部の処理を他の演算部に代行させる場合の処理負荷の増大を回避することが可能となる。図１１は、図１のように構成された第１の実施の形態のメッセージ処理装置１００によるメッセージ処理の一例を示す模式図である。図１１は、代行処理管理表１２１に登録された制御命令列を用いることにより、ネットワーク処理１１１１（Ｎｓ）と代行処理１１１３（Ｏｓ）とを第２演算部１４０で連続して実行する例を示している。図８と比較すると、図１１の例では、代行処理１１１３（Ｏｓ）が事前に実行され、これに伴いパケットの受信先プロセスが実行する処理１１１２（Ｐ）が途切れずに実行される。このように、第１の実施の形態によれば、専用のハードウェアを用いることなく、メインの演算部の処理を他の演算部に代行させる場合のオーバヘッドの増加を抑止できる。

次に、第１の実施の形態によるメッセージ処理の具体例について説明する。以下では、パケットを受信するネットワーク処理と、受信パケットを復号化するＳＳＬ（Secure Socket Layer）の共通鍵暗号処理とを代行する場合を例として説明する。ＳＳＬの共通鍵暗号処理に必要な暗号アルゴリズムの演算処理が予め第２演算部１４０によって代行されると決められているとする。

まず、メッセージ処理装置１００のネットワークＩ／Ｆ部１１０が、任意のタイミングでパケットを受信することによってパケット受信処理が開始される。ここで、送信元ＩＰアドレス＝「10.2.2.1」、宛先ＩＰアドレス＝「10.2.2.2」、プロトコル＝「TCP」、送信元ポート番号＝「80」、および宛先ポート番号＝「54321」のようなフロー情報を含むパケットを受信すると仮定する。

このパケットがネットワークＩ／Ｆ部１１０に到着すると、割り込み信号が第１演算部１３０に通知される。その結果、第１演算部１３０で割込処理部１３１が起動される。割込処理部１３１が適切な処理を実行した後（ステップＳ３０１）、識別情報検出部１３２が、パケットのフロー情報を抽出し、抽出したフロー情報に対応する代行処理管理表１２１を検索する（ステップＳ３０２、ステップＳ３０３）。上記フロー情報のパケットは初めて受信するため、この段階では、代行処理管理表１２１にエントリは存在しない。この結果、パケット処理部１３３が、通常のパケット処理を実行する（ステップＳ３０４）。

パケット処理の過程で、そのパケットを最終的に消費するプロセスが決定される。生成部１３５は、決定されたプロセスのプロセスＩＤと、検出したフロー情報とを合わせて、代行処理管理表１２１のエントリを作成する（ステップＳ３０６）。そして、保存部１３６が、作成されたエントリを代行処理管理表１２１に登録する（ステップＳ３０７）。登録が終わるとパケット受信処理の第一段階が終了する。

図１２は、この時点での代行処理管理表１２１に記憶されたエントリの一例を示す図である。フロー情報フィールドには、検出されたフロー情報が記載され、プロセス情報フィールドには、決定したプロセスのプロセスＩＤである「PID1」が記載される。その他の二つのフィールドは、この時点で情報が確定しないため、未記入のままにしておく。

次に、受信したパケットがそれを最終的に消費するプロセスに渡されたと仮定する。このプロセスは、ＳＳＬの処理が実行可能な量のデータが受信されたかどうかを確認する処理を行う。ここでは、まだ十分な量のデータを受信していないと仮定する。この場合、プロセスは再びパケットを受信するまで待機する。

さらに、ネットワークＩ／Ｆ部１１０に、上記フロー情報が表すフローに属するパケットが到着したと仮定する。同様にして割込処理部１３１が受信処理を実行し（ステップＳ３０１）、識別情報検出部１３２が、フロー情報に対応するエントリの確認処理を実行する（ステップＳ３０２、ステップＳ３０３）。この段階では、上述した処理でエントリが作成されているため、エントリが代行処理管理表１２１に存在すると判断される（ステップＳ３０３：ＹＥＳ）。

この場合、生成部１３５は、検索されたエントリ内に制御命令列が設定されているか否かを判断する（ステップＳ３０８）。図１２に示したように、この時点では同エントリに制御命令列は記載されていないと判断される（ステップＳ３０８：ＮＯ）。したがって、パケット処理部１３３が、通常のパケット処理を実行する（ステップＳ３１０）。

この後、再度、パケットを最終的に消費するプロセスに受信したパケットが渡されたと仮定する。プロセスは、これまでに受信した未処理のデータの長さを判定する処理を実行する。ここでは、ＳＳＬの処理が実行可能な量のデータが受信されたと判定されたと仮定する。

復号処理に必要なデータを受信したことが確認されたので、プロセスは、暗号化されたデータの復元を試みる。この処理は第２演算部１４０で代行されることが事前に設定されているため、代行のための制御命令列と入力データとを第２演算部１４０に通知し、代行を依頼する。

プロセスによる代行の依頼は、図４に示した命令列生成処理のステップＳ４０１で捕捉される。代行依頼が捕捉されると（ステップＳ４０１：ＹＥＳ）、プロセス検出部１３４が、代行依頼を発行したプロセスを特定する（ステップＳ４０２）。ここでは、プロセスＩＤ＝「PID1」が取得できたとする。

次に、生成部１３５は、取得したプロセスＩＤに対応するエントリを代行処理管理表１２１から検索する（ステップＳ４０３）。この時点の代行処理管理表１２１は、図１２に示した通り、プロセス情報として「PID1」が記載されたエントリが存在する。

そこで、生成部１３５は、エントリ内に制御命令列が設定されているか否かを判断する（ステップＳ４０４）。仮に制御命令列が記載済みであれば（ステップＳ４０４：ＹＥＳ）、新たに制御命令列を生成する必要がないため命令列生成処理を終了する。この段階では、図１２に示すように制御命令列が記載されていないため（ステップＳ４０４：ＮＯ）、生成部１３５は、制御命令列を生成する。

例えば、生成部１３５は、「Ｉｎｓ（Ｎｓ）|Ｉｎｓ（Ｃ）|Ｉｎｓ（Ｃｒｙｐｔ）」という制御命令列を生成する。ここで、Ｉｎｓ（Ｎｓ）は第２演算部１４０でネットワーク処理を行うための制御命令列である。また、Ｉｎｓ（Ｃｒｙｐｔ）はプロセスからの代行依頼によって第２演算部１４０に通知された暗号アルゴリズムを実行するための制御命令列である。

Ｉｎｓ（Ｃ）は、受信したデータのサイズを判定するためにプロセスが実行していた処理に相当する制御命令列である。Ｉｎｓ（Ｃ）は、Ｉｎｓ（Ｃｒｙｐｔ）を実行可能と判断する受信データのサイズの閾値αと、Ｉｎｓ（Ｎｓ）によって処理されたがＩｎｓ（Ｃｒｙｐｔ）で処理されていないデータの総量βとを入力として受け取る。そして、Ｉｎｓ（ｃ）は、βがαより大きい場合に、Ｉｎｓ（Ｃｒｙｐｔ）を実行可能と判定する。

なお、閾値αは、実行する暗号アルゴリズムに応じて予め定められており、制御部１３７が制御命令列の実行を第２演算部１４０に依頼するときに、第２演算部１４０に通知される。なお、制御部１３７が、暗号アルゴリズムを実行するプロセスに対して渡されたデータのサイズを事前に検出して保存しておき、保存したサイズを閾値αとして第２演算部１４０に通知するように構成してもよい。

制御命令列が作成されると、保存部１３６は、作成した制御命令列で該当するエントリを更新する（ステップＳ４０６）。このとき、保存部１３６は、閾値αをエントリの付加情報フィールドに記載する。なお、プロセスが発行した代行依頼に対する実際の代行処理は、命令列生成処理を実行している間に実行してもよいし、命令列生成処理の完了後に実行してもよい。

図１３は、この時点での代行処理管理表１２１に記憶されたエントリの一例を示す図である。同図に示すように、この時点では、制御命令列フィールドおよび付加情報フィールドに、それぞれ生成された制御命令列および閾値αの情報が追加されている。

次に、さらに同じフローに属するパケットを受信したとする。この場合、図３のようなパケット受信処理が実行される。この段階では、検出したフロー情報に対応するエントリが存在し（ステップＳ３０３：ＹＥＳ）、制御命令列も記載されているため（ステップＳ３０８：ＹＥＳ）、当該エントリに記載された制御命令列を伴う代行処理依頼が発行される（ステップＳ３０９）。

上述のように、ここで依頼される代行処理の制御命令列は、「Ｉｎｓ（Ｎｓ）|Ｉｎｓ（Ｃ）|Ｉｎｓ（Ｃｒｙｐｔ）」である。この段階では、１パケットしか受信していないためデータのサイズが小さい。このため、Ｉｎｓ（Ｃ）ではＩｎｓ（Ｃｒｙｐｔ）が実行できないと判定され、代行処理が終了する。

引き続き同じフローに属するパケットを受信し、Ｉｎｓ（Ｃ）で、十分な量のデータが受信済みであると判定されたとする。この場合、次の処理であるＩｎｓ（Ｃｒｙｐｔ）が実行される。なお、最初に受信したパケットに対してネットワーク処理を施した結果は、第２演算部１４０から即時アクセス可能なメモリ領域に保存される。そして、保存された結果と、次に受信したパケットをネットワーク処理した結果とが、Ｉｎｓ（Ｃｒｙｐｔ）によってまとめて処理される。

次に、第１の実施の形態によるメッセージ処理の他の具体例について説明する。以下では、図７のようなマルチコアプロセッサ７６０によって構成されたメッセージ処理装置７００に適用した例を説明する。

なお、メッセージ処理を実行するためのメッセージ処理プログラムは、実行可能なプログラムの形式でメインメモリ１２０に格納されている。そして、メッセージ処理プログラムは、状況に応じてマルチコアプロセッサ７６０にロードされ、実行される。

図１４は、この例でのメッセージ処理の概要を示すシーケンス図である。パケットがネットワークＩ／Ｆ部１１０に到着すると（ステップＳ１４０１）、ネットワークＩ／Ｆ部１１０は、受信したパケットをメインメモリ１２０に保存する（ステップＳ１４０２）。また、ネットワークＩ／Ｆ部１１０は、マルチコアプロセッサ７６０の第１演算部１３０に対して割り込みを通知する（ステップＳ１４０３）。

第１演算部１３０は、メインメモリ１２０から割り込みハンドラ（割込処理部１３１）のコードをロードして実行する。同様に識別情報検出部１３２の処理が実行され、受信したパケットからフロー情報が検出される（ステップＳ１４０４）。

その後、第１演算部１３０は、メインメモリ１２０に格納された代行処理管理表１２１を参照し（ステップＳ１４０５）、受信パケットに対応するエントリの存在と制御命令列の存在を確認する（ステップＳ１４０６）。このとき、必要に応じてメインメモリ１２０に格納されたパケットの内容を参照する。なお、対応するエントリまたは制御命令列のいずれかが存在しない場合は、引き続き第１演算部１３０が処理を続ける。

ここでは、エントリと制御命令列が共にが存在すると仮定して説明を続ける。第１演算部１３０は、対応するエントリに記載された制御命令列と付加情報とパケットが格納されたメインメモリ１２０のアドレスとを、第２演算部１４０のローカルメモリ１４１に格納する（ステップＳ１４０７）。その後、第２演算部１４０の演算処理部１４２に対して処理を行うように依頼する。

第２演算部１４０は、ローカルメモリ１４１に記載されたパケットのアドレスを参照し、パケットをメインメモリ１２０からローカルメモリ１４１に転送する（ステップＳ１４０８）。そして、ローカルメモリ１４１に格納された制御命令列に従って処理を実行する（ステップＳ１４０９）。実行完了後、第２演算部１４０は、必要に応じて、メインメモリ１２０への演算結果の書き戻し（ステップＳ１４１０）や、他の第２演算部１４０のローカルメモリ１４１への演算結果の転送を実行してもよい。

これまでは、主にパケットを受信する場合の代行処理について説明した。同様の処理は、パケットを送信する場合にも適用できる。以下に、パケットを送信するときのメッセージ処理の詳細について説明する。パケットを送信するときのメッセージ処理には、パケット送信時に代行処理を検出して制御命令列を生成する命令列生成処理（図１５）、および、パケットを送信するときの処理であるパケット送信処理（図１６）が含まれる。

図１５は、第１の実施の形態におけるパケット送信時の命令列生成処理の全体の流れを示すフローチャートである。

ステップＳ１５０１からステップＳ１５０３の、代行処理の検出処理、プロセスＩＤ検出処理、およびエントリ検索処理は、パケット受信時の命令列生成処理を表す図４のステップＳ４０１からステップＳ４０３までと同様の処理なので、その説明を省略する。

パケット送信時は、ネットワーク処理に先立って代行処理が実行される。このため、初めて実行される代行処理に対しては、代行処理管理表１２１に対応するエントリが存在しない。したがって、ステップＳ１５０３で、検出したプロセスＩＤに対応するエントリが代行処理管理表１２１に記憶されていないと判断された場合（ステップＳ１５０３：ＮＯ）、エントリを作成する処理が追加される（ステップＳ１５０４）。すなわち、生成部１３５が、検出したプロセスＩＤをプロセス情報として含むエントリを作成し（ステップＳ１５０５）、保存部１３６が、作成したエントリを代行処理管理表１２１に保存する。なお、この時点ではプロセス情報以外は特定できないため、その他のフィールドは空欄とする。

ステップＳ１５０３で、検出したプロセスＩＤに対応するエントリが代行処理管理表１２１に記憶されていると判断された場合（ステップＳ１５０３：ＹＥＳ）、生成部１３５は、エントリ内に完全な制御命令列が設定されているか否かを判断する（ステップＳ１５０５）。ここで、完全な制御命令列とは、ネットワーク処理と一つ以上の代行処理とを実行する制御命令列である。

完全な制御命令列が設定されている場合（ステップＳ１５０５：ＹＥＳ）、制御命令列を生成する必要がないため、パケット送信時の命令列生成処理を終了する。完全な制御命令列が設定されていない場合（ステップＳ１５０５：ＮＯ）、生成部１３５は、制御命令列を生成する（ステップＳ１５０６）。本ステップで生成される制御命令列には、二つの形式が存在する。

第一の形式は、送信のためのネットワーク処理（送信ネットワーク処理）を含まない制御命令列である。例えば、代行処理が初めて実行され、ステップＳ１５０４でエントリを登録した時点では、送信のためのネットワーク処理の内容が確定してない。このため、生成部１３５は、送信ネットワーク処理の制御命令列を含まず、代行処理に対する制御命令列のみを含む形式で仮の制御命令列を生成する。なお、この仮の制御命令列は、図１６のステップＳ１６０８（後述）で、送信ネットワーク処理の制御命令列と結合されて、完全な制御命令列となる。

第二の形式は、送信ネットワーク処理を含む完全な制御命令列である。例えば、通信は開始されたが代行処理を行わない送信処理が続いた場合には、先にエントリが作成される可能性がある。この場合は、生成部１３５は、作成済みの送信ネットワーク処理の制御命令列と代行処理の制御命令列とを含む完全な制御命令列を生成することができる。

最後に、保存部１３６が、生成された制御命令列を代行処理管理表１２１の対応するエントリに設定し（ステップＳ１５０７）、パケット送信時の命令列生成処理を終了する。

次に、パケット送信処理について説明する。図１６は、第１の実施の形態におけるパケット送信処理の全体の流れを示すフローチャートである。

まず、プロセス検出部１３４は、パケットの送信依頼元のプロセスのプロセスＩＤを検出する（ステップＳ１６０１）。次に、プロセス検出部１３４は、検出したプロセスＩＤを含むエントリが、代行処理管理表１２１に記憶されているか否かを判断する（ステップＳ１６０２）。

検出したプロセスＩＤを含むエントリが記憶されていない場合（ステップＳ１６０２：ＮＯ）、パケット処理部１３３が、送信するパケットに対する通常のパケット処理を実行し（ステップＳ１６０３）、パケット送信処理を終了する。

検出したプロセスＩＤを含むエントリが記憶されている場合（ステップＳ１６０２：ＹＥＳ）、生成部１３５は、エントリ内に完全な制御命令列が設定されているか否かを判断する（ステップＳ１６０４）。設定されている場合（ステップＳ１６０４：ＹＥＳ）、制御部１３７は、第２演算部１４０に対して、設定済みの制御命令列による代行処理を依頼し（ステップＳ１６０５）、パケット送信処理を終了する。

エントリ内に完全な制御命令列が設定されていないと判断された場合（ステップＳ１６０４：ＮＯ）、パケット処理部１３３が、受信したパケットに対する通常のパケット処理を実行する（ステップＳ１６０６）。次に、識別情報検出部１３２が、送信したパケットからフロー情報を検出する（ステップＳ１６０７）。次に、生成部１３５は、エントリ内の仮の制御命令列（代行処理の制御命令列）と、送信ネットワーク処理の制御命令列とを結合した完全な制御命令列を生成する（ステップＳ１６０８）。そして、保存部１３６が、生成された制御命令列と、検出されたフロー情報とを含むエントリで、代行処理管理表１２１のエントリを更新する（ステップＳ１６０９）。

以上のように、パケット送信処理は、以下の点で、図３に示すパケット受信処理と異なっている。
（１）代行処理管理表１２１にエントリが存在し、かつ完全な制御命令列が登録されていない場合（ステップＳ１６０４：ＮＯ）には、ネットワーク処理（通常の送信処理）とエントリの更新処理とが実行される
（２）割り込みハンドラ（割込処理部１３１）で動作する部分が存在しない
（３）代行処理管理表１２１にエントリが存在しない場合（ステップＳ１６０２：ＮＯ）、通常のネットワーク処理が実行される
（４）送信処理に続いて、送信するパケットのフローを検出する処理（ステップＳ１６０７）が追加される

次に、第１の実施の形態によるパケット送信時のメッセージ処理の具体例について説明する。以下では、ＳＳＬによる暗号処理を施したパケットをネットワークに送信する場合を例に説明する。なお、ＳＳＬの共通鍵暗号処理に必要な暗号アルゴリズムの演算処理は、予め第２演算部１４０によって代行されると決められているとする。

まず、あるプロセスが、ネットワークを介して送信すべきデータを生成する。この時点で、データはメインメモリ１２０に格納されている。このデータに対してネットワークに送信する前に暗号処理を施す。暗号処理は、第２演算部１４０により実行される代行処理であるため、プロセスは、暗号処理を実行する制御命令列とデータのアドレスとを、第２演算部１４０に通知する。

第２演算部１４０は、データをローカルメモリ１４１にロードし、暗号処理を実行する。この通知を契機に、第１演算部１３０では、命令列生成処理（図１５）が実行される。

この例では初めて実行する代行処理（暗号処理）であるため、暗号処理に対応する制御命令列からなる仮の制御命令列を含むエントリが代行処理管理表１２１に追加される（ステップＳ１５０６、ステップＳ１５０７）。なお、暗号処理が完了すると、データは第２演算部１４０のローカルメモリ１４１からメインメモリ１２０に書き出される。

全てのデータに対して暗号処理が終了すると、パケット送信処理（図１６）が実行される。この例では、代行処理管理表１２１に仮の制御命令列を含むエントリが登録されているため（ステップＳ１６０２：ＹＥＳ、ステップＳ１６０４：ＮＯ）、通常の送信ネットワーク処理が実行される（ステップＳ１６０６）。そして、フロー情報の検出（ステップＳ１６０７）、制御命令列の生成（ステップＳ１６０８）、およびエントリの更新（ステップＳ１６０９）を経て、パケット送信処理が完了する。

なお、パケット送信処理は第１演算部１３０で実行される。また、メインメモリ１２０に格納されていたデータは、送信ネットワーク処理（ステップＳ１６０６）の実行に伴ってメインメモリ１２０からネットワークＩ／Ｆ部１１０を介してネットワークに送信される。

プロセスが、後続のデータをさらに生成したとする。この後、プロセスが暗号処理を実行しようとすると再び命令列生成処理（図１５）が開始される。この段階では、代行処理管理表１２１に完全な制御命令列を含むエントリが登録されているため（ステップＳ１５０３：ＹＥＳ、ステップＳ１５０５：ＹＥＳ）、特別な処理を行うことなく命令列生成処理を終了する。ここでは、データに対する処理は実行されず、処理領域などの必要な情報が代行処理管理表１２１のエントリに保存される。

命令列生成処理に引き続き、パケット送信処理（図１６）が実行される。この時点では、代行処理管理表１２１に完全な制御命令列を含むエントリが登録されているため（ステップＳ１６０２：ＹＥＳ、ステップＳ１６０４：ＹＥＳ）、第２演算部１４０に代行処理を依頼する（ステップＳ１６０５）。このとき、制御命令列とデータが格納されたアドレスとに加えて、命令列生成処理（図１５）で保存された処理領域の情報を合わせて第２演算部１４０に通知する。

この通知を受けて、第２演算部１４０ではデータをローカルメモリ１４１にロードし、通知された領域に対して暗号処理を実行し、ネットワークへ送信する。このように、第２演算部１４０は、命令列生成処理（図１５）の時点で実行していない暗号処理と送信ネットワーク処理とを連続して実行する。

このように、パケットを受信する場合だけでなく、パケットを送信する場合にも、代行処理とネットワーク処理とを連続して実行することができる。すなわち、他の演算部に処理を代行させる場合の処理負荷の増大を回避することが可能となる。

（変形例）
これまでの説明では、生成部１３５は、ネットワーク処理の制御命令列（Ｉｎｓ（Ｎｓ））と代行処理の制御命令列（Ｉｎｓ（Ｏｓ））を機械的に結合することにより、両処理を連続して実行する制御命令列を生成していた。しかし、第２演算部１４０が、Ｉｎｓ（Ｎｓ）とＩｎｓ（Ｏｓ）とを機械的に結合した制御命令列により、処理Ｎｓと処理Ｏｓとを連続して同一データに対して実行できるかは個々の実行環境に依存する。

第２演算部１４０が機械的に結合した制御命令列を実行できない場合は、以下のように表形式で表した制御命令列を用いるように構成してもよい。この変形例では、第２演算部１４０は、制御命令列を解釈して実行するプログラムローダーを備える。プログラムローダーは、処理ごとの制御命令列と、各処理の実行順序と、各処理の入力データおよび出力データのアドレスとを特定可能な情報を対応づけた制御命令列である実行コードアドレス表を利用する。

図１７は、実行コードアドレス表のデータ構造の一例を示す図である。図１７に示すように、実行コードアドレス表は、実行可能な個々の制御命令列を格納したアドレス（制御命令列格納アドレス）と、入力データを格納したアドレス（入力データ格納アドレス）と、出力データを格納すべきアドレス（出力データ格納アドレス）とを対応づけたエントリを複数記憶している。同図は、表の先頭のエントリから順に制御命令列を実行することを表す実行コードアドレス表の例を表している。エントリ内に、実行順序を表す順序情報を格納し、順序情報に従って制御命令列が実行されるように構成してもよい。

なお、同図では、最初のエントリの制御命令列の出力データを次のエントリの制御命令列の入力データとして利用することを示す情報を、最初のエントリの出力データ格納アドレス、および、次のエントリの入力データ格納アドレスに設定した例が示されている。すなわち、最初のエントリの出力データ格納アドレスにはＰＡＳＳ（２）が設定され、次のエントリの入力データ格納アドレスにはＲＥＣＶ（１）が設定されている。

ＰＡＳＳ（ｎ）は、出力データをｎ行目のエントリの制御命令列に対応する処理の入力データとして渡すことを示している。また、ＲＥＣＶ（ｎ）は、ｎ行目のエントリの制御命令列に対応する処理の出力データを、入力データとして受け取ることを示している。この場合は、例えば予め定められたレジスタ等を介してデータを受け渡すように構成することができる。

なお、ＰＡＳＳやＲＥＣＶを利用せず、入力データ格納アドレスや出力データ格納アドレスに、メインメモリ１２０のアドレスを記載するように構成してもよい。

同図は、ネットワーク処理Ｎｓと代行処理Ｏｓを一つの処理にまとめ、第２演算部１４０にて実行させる場合の実行コードアドレス表の一例を示している。Ａｄｄｒ（Ｉｎｓ（Ｎｓ））は、ネットワーク処理Ｎｓの制御命令列Ｉｎｓ（Ｎｓ）が格納されたアドレスを意味する。また、Ａｄｄｒ（Ｐｋｔ）は、受信したパケットが格納されたアドレスを意味する。同様に、Ａｄｄｒ（Ｉｎｓ（Ｏｓ））およびＡｄｄｒ（Ｂｕｆ）は、それぞれ制御命令列Ｉｎｓ（Ｏｓ）が格納されたアドレスおよび処理結果を格納するバッファのアドレスを意味する。

プログラムローダーが第２演算部１４０で実行されると、プログラムローダーは、実行コードアドレス表に記載された順番に従って制御命令列を実行する。プログラムローダーは、各制御命令列に対する入力データを入力データ格納アドレスからロードし、各制御命令列による処理結果である出力データを、出力データ格納アドレスに保存する。全てのエントリを実行するとプログラムローダーは処理を終了し、一連の代行処理が完了する。

なお、制御命令列を実行コードアドレス表の形式で生成する場合は、代行処理管理表１２１の制御命令列フィールドには、例えば、実行コードアドレス表を識別する表ＩＤを設定する。図１８は、このように構成された代行処理管理表１２１に格納されるデータのデータ構造の一例を示す図である。図１８に示すように、この場合は、制御命令列フィールドに、図１７のような実行コードアドレス表を識別する表ＩＤを設定する。

また、制御命令列の生成方法は、複数の制御命令列を機械的に結合する方法、実行コードアドレス表のように表形式で生成する方法に限られるものではない。ネットワーク処理、および代行処理それぞれに対応する制御命令列を連続して実行可能な制御命令列を生成するものであれば、あらゆる方法を適用できる。

このように、第１の実施の形態にかかるメッセージ処理装置では、第１演算部で実行されるネットワーク処理に伴って第２演算部で実行される代行処理（特定処理）を検出し、ネットワーク処理と特定処理とを連続して実行する制御命令列を動的に生成して記憶部に保存し、それ以降に処理するパケットに対しては、保存した制御命令列を用いて第２演算部がネットワーク処理と特定処理とを連続して実行する。これにより、メインのプロセッサの負荷上昇を抑えるという本来の目的と達成するとともに、処理の複雑化やデータの移動に伴うオーバヘッドを削減することができる。

（第２の実施の形態）
第１の実施の形態では、ネットワーク処理と、関連する代行処理とを検出して動的に制御命令列を生成して利用していた。第２の実施の形態にかかるメッセージ処理装置は、各プロセスの要求に応じて事前に制御命令列を登録可能とし、事前に登録した制御命令列を用いて、第２演算部が複数の処理を連続して実行する。

図１９は、第２の実施の形態にかかるメッセージ処理装置１９００の構成を示すブロック図である。図１９に示すように、メッセージ処理装置１９００は、ネットワークＩ／Ｆ部１１０と、メインメモリ１２０と、第１演算部１９３０と、第２演算部１４０と、バス１５０と、を備えている。

第２の実施の形態では、第１演算部１９３０に受付部１９３８を追加したこと、および生成部１９３５の機能が第１の実施の形態と異なっている。その他の構成および機能は、第１の実施の形態にかかるメッセージ処理装置１００の構成を表すブロック図である図１と同様であるので、同一符号を付し、ここでの説明は省略する。

受付部１９３８は、パケットを受信するプロセス、または送信するパケットを生成するプロセスから、パケットのフロー情報と、当該フロー情報で特定されるフローに属するパケットに対して実行する特定処理を識別する処理識別情報と、を含む、制御命令列の登録依頼を受け付ける。

生成部１９３５は、受け付けた登録依頼に含まれる処理識別情報で識別される特定処理と、ネットワーク処理とを連続して実行する制御命令列を生成する。

次に、このように構成された第２の実施の形態にかかるメッセージ処理装置１９００による命令列生成処理について説明する。図２０は、第２の実施の形態における命令列生成処理の全体の流れを示すフローチャートである。

なお、第１の実施の形態では、パケットの受信時または送信時に動的に制御命令列を生成するため、命令列生成処理が、パケット受信時（図４）とパケット送信時（図１５）とで異なっていた。第２の実施の形態では、ネットワーク処理の実行前に、プロセスからの要求に応じて事前に制御命令列を生成するため、図２０に示す命令列生成処理のみが実行される。

まず、受付部１９３８が、パケットを受信するプロセス、またはパケットを送信するプロセスから、制御命令列の登録依頼を受け付ける（ステップＳ２００１）。登録依頼は、パケットのフロー情報と、パケットに対して施す特定処理を識別する処理識別情報とを含む。なお、ＩＰアドレスやＴＣＰポート番号、ＵＤＰポート番号などのように、通信を行うことで決定される情報については、フロー情報として通知しなくてもよい。

登録依頼が受け付けられた場合、生成部１９３５は、事前に用意してあるネットワーク処理に対応する制御命令列と、登録依頼に含まれる処理識別情報で識別される特定処理に対応する制御命令列と、付随する処理の制御命令列とを組み合わせて、複数の処理を連続して実行する制御命令列を生成する（ステップＳ２００２）。

なお、受付部１９３８が、ネットワーク処理と、特定処理と、付随する処理との実行順序を表す順序情報をプロセスから受け付け、生成部１９３５が、受け付けた順序情報にしたがって各処理を実行する制御命令列を生成するように構成してもよい。

次に、プロセス検出部１３４が、登録依頼を送信したプロセスのプロセスＩＤを取得する（ステップＳ２００３）。次に、生成部１９３５が、登録依頼に含まれるフロー情報と、生成した制御命令列と、検出されたプロセスＩＤとを対応づけたエントリを作成する（ステップＳ２００４）。そして、保存部１３６が、作成されたエントリを代行処理管理表１２１に登録し（ステップＳ２００５）、命令列生成処理を終了する。

次に、第２の実施の形態のパケット受信処理について説明する。図２１は、第２の実施の形態におけるパケット受信処理の全体の流れを示すフローチャートである。

第１の実施の形態のパケット受信処理を表す図３と比較すると、図２１では、パケット受信に起因する代行処理管理表１２１のエントリの作成処理（ステップＳ３０５からステップＳ３０７）が削除された点が異なっている。事前通知によって代行処理すべき内容が通知され、事前にエントリが作成されているため、パケット受信時にエントリを作成する必要がないためである。その他のステップは、図３と同様の処理なので、その説明を省略する。

次に、第２の実施の形態のパケット送信処理について説明する。図２２は、第２の実施の形態におけるパケット送信処理の全体の流れを示すフローチャートである。

パケット受信処理と同様に、第１の実施の形態のパケット送信処理を表す図１６と比較すると、図２２では、エントリの作成処理（ステップＳ１６０７からステップＳ１６０９）が削除された点が異なっている。その他のステップは、図３と同様の処理なので、その説明を省略する。

次に、第２の実施の形態によるメッセージ処理の具体例について説明する。以下では、パケットを受信するネットワーク処理と、ＩＰｓｅｃ暗号処理とを代行する場合を例として説明する。ＩＰｓｅｃに必要な暗号アルゴリズムの演算処理が予め第２演算部１４０によって代行されると決められているとする。

ＩＰｓｅｃを適用するためには、通信する装置間でＩＰｓｅｃ ＳＡを事前に確立する。ＳＡの情報はパケット処理部１３３に伝えられるため、この操作に合わせて命令列生成処理（図２０）が実行される。具体的には、ＩＰｓｅｃ ＳＡを構築する情報をフロー情報を含む登録依頼が通知されると（ステップＳ２００１）、対応する制御命令列が作成される（ステップＳ２００２）。そして、作成された制御命令列を含む代行処理管理表１２１のエントリが作成され登録される（ステップＳ２００４、ステップＳ２００５）。

この例では、作成される制御命令列は、事前に準備されていたネットワーク処理ＮｓおよびＮ２ｓと、予め代行することが決まっていた暗号アルゴリズム処理Ｃｒｙｐｔとを連続して実行する「Ｉｎｓ（Ｎｓ）|Ｉｎｓ（Ｃｒｙｐｔ）|Ｉｎｓ（Ｎ２ｓ）」である。ここで、Ｎｓは暗号アルゴリズム処理よりも前段階に実行されるネットワーク処理を表し、Ｎ２ｓは暗号アルゴリズム処理が完了した後に実行されるネットワーク処理を表す。

ＩＰｓｅｃ処理はネットワーク処理の途中に割り込む形になるため、この順序を維持した形で制御命令列を生成する必要がある。このため、代行すべき処理の前に行うネットワーク処理と、後に行うネットワーク処理とを特定するための情報を、フロー情報の通知と共に行ってもよい。このような情報が通知された場合は、生成部１９３５は、指定された順序を維持する形で制御命令列を生成する。

代行処理管理表１２１に対するエントリの追加が完了し、さらにＳＡが正しく確立されると、ＩＰｓｅｃで暗号化されたパケットが受信できるようになる。以下に、確立したＳＡに対応するパケットを受信した場合を例として、第２の実施の形態のパケット受信処理の具体例について説明する。ここでは、図２に示すようなエントリが代行処理管理表１２１に追加されたことを前提とする。

ＩＰｓｅｃで暗号化されたパケットがネットワークＩ／Ｆ部１１０に到着すると、割り込み信号が第１演算部１９３０に送られる。これを契機として、パケット受信処理（図２１）が開始される。

まず、第１演算部１９３０は、割り込みハンドラ（割込処理部１３１）を起動して適切な処理を行う（ステップＳ２１０１）。その後、識別情報検出部１３２が、パケットのフロー情報を抽出し、抽出したフロー情報に対応する代行処理管理表１２１を検索する（ステップＳ２１０２、ステップＳ２１０３）。

ここでは、受信したパケットから得られるフロー情報は、先に確立したＳＡで特定されるフロー情報と同じであるものとする。この例では、ＳＰＩまで含めてフロー情報としているが、代行される処理の内容によってはＳＰＩを特定しない形式でフロー情報を作成することも可能である。

識別情報検出部１３２は、受信したパケットから得られるフロー情報を含むエントリを代行処理管理表１２１から検索する（ステップＳ２１０３）。この例では、先のＳＡ確立処理に伴う命令列生成処理で、同じフロー情報を持つエントリが作成されている。したがって、対応するエントリが検索され（ステップＳ２１０３：ＹＥＳ）、生成部１９３５が、同エントリに対する制御命令列の有無を確認する（ステップＳ２１０５）。この例では、事前の登録処理により、制御命令列が作られて登録されている。したがって、制御命令列が設定されていると判断され（ステップＳ２１０５：ＹＥＳ）、制御命令列に渡す情報の準備などの処理を行った後、制御命令列とそれらの情報とを第２演算部１４０に通知することで代行処理を依頼する（ステップＳ２１０６）。

第２の実施の形態では、このような処理が、確立したＳＡが無効になるまで繰り返される。なお、ＳＡが無効になった場合は、登録を削除する処理により代行処理管理表１２１から対応するエントリが削除される。

次に、第２の実施の形態でパケットを送信する場合のメッセージ処理の具体例について説明する。この場合、命令列生成処理では、例えば、「Ｉｎｓ（Ｎ’ｓ１）｜Ｉｎｓ（Ｃｒｙｐｔ’）｜Ｉｎｓ（Ｎ’２ｓ）」という制御命令列を生成する。ここで、処理Ｎ’ｓ１は暗号処理を行う前の送信ネットワーク処理を表し、処理Ｃｒｙｐｔ’は暗号処理を表し、Ｎ’２ｓは暗号処理を行った後の送信ネットワーク処理を表す。

なお、第１の実施の形態では、代行処理（ＳＳＬによる暗号化）が送信ネットワーク処理の前に実行されるため、制御命令列が生成された後では、プロセスが代行を依頼するタイミングで処理領域等の情報を保存するだけに留め、実際の処理はスキップしていた。一方、第２の実施の形態では、代行すべき処理が送信ネットワーク処理の中に入るため、処理領域を保存するなどの特別な処理は不要である。

また、第１の実施の形態で、Ｉｎｓ（Ｃ）なる制御命令列を追加する具体例について説明した。複数の制御命令列を結合する際に、このような汎用的な条件判断だけでなく、特定の処理に固有の条件判断が要求される場合がある。そのような場合には、第２の実施の形態を適用し、事前に複数の制御命令列を登録するように構成することで対応可能である。

このように、第２の実施の形態にかかるメッセージ処理装置では、各プロセスの要求に応じて事前に制御命令列を登録し、事前に登録した制御命令列を用いて、第２演算部が複数の処理を連続して実行することができる。これにより、第１の実施の形態と同様に、メインのプロセッサの負荷上昇を抑えつつ、処理の複雑化やデータの移動に伴うオーバヘッドを削減することができる。

第１または第２の実施の形態にかかるメッセージ処理装置で実行されるメッセージ処理プログラムは、インストール可能な形式又は実行可能な形式のファイルでＣＤ−ＲＯＭ（Compact Disk Read Only Memory）、フレキシブルディスク（ＦＤ）、ＣＤ−Ｒ（Compact Disk Recordable）、ＤＶＤ（Digital Versatile Disk）等のコンピュータで読み取り可能な記録媒体に記録されて提供される。

また、第１または第２の実施の形態にかかるメッセージ処理装置で実行されるメッセージ処理プログラムを、インターネット等のネットワークに接続されたコンピュータ上に格納し、ネットワーク経由でダウンロードさせることにより提供するように構成してもよい。また、第１または第２の実施の形態にかかるメッセージ処理装置で実行されるメッセージ処理プログラムをインターネット等のネットワーク経由で提供または配布するように構成してもよい。

また、第１または第２の実施の形態のメッセージ処理プログラムを、ＲＯＭ等に予め組み込んで提供するように構成してもよい。

第１または第２の実施の形態にかかるメッセージ処理装置で実行されるメッセージ処理プログラムは、上述した各部（割込処理部、識別情報検出部、パケット処理部、プロセス検出部、生成部、保存部、制御部）を含むモジュール構成となっており、実際のハードウェアとしてはＣＰＵ５１（プロセッサ）が上記記憶媒体からメッセージ処理プログラムを読み出して実行することにより上記各部が主記憶装置上にロードされ、上述した各部が主記憶装置上に生成されるようになっている。

以上のように、本発明にかかる装置、方法およびプログラムは、複数の演算部を備えるマルチコアプロセッサなどを利用して、ネットワークを介して送受信するメッセージを処理する装置、方法、およびプログラムに適している。

第１の実施の形態にかかるメッセージ処理装置の構成を示すブロック図である。 代行処理管理表に格納されるデータのデータ構造の一例を示す図である。 第１の実施の形態におけるパケット受信処理の全体の流れを示すフローチャートである。 第１の実施の形態におけるパケット受信時の命令列生成処理の全体の流れを示すフローチャートである。 メッセージ処理装置のハードウェア構成図である。 メッセージ処理装置のハードウェア構成図である。 メッセージ処理装置のハードウェア構成図である。 １つの第１演算部と１つの第２演算部を用いて処理が実行される例を示す模式図である。 １つの第１演算部と２つの第２演算部を用いて処理が実行される例を示す模式図である。 １つの第１演算部とネットワークＩ／Ｆ部に備えられた第２演算部を用いて処理が実行される例を示す模式図である。 第１の実施の形態のメッセージ処理装置によるメッセージ処理の一例を示す模式図である。 代行処理管理表に記憶されたエントリの一例を示す図である。 代行処理管理表に記憶されたエントリの一例を示す図である。 メッセージ処理の概要を示すシーケンス図である。 第１の実施の形態におけるパケット送信時の命令列生成処理の全体の流れを示すフローチャートである。 第１の実施の形態におけるパケット送信処理の全体の流れを示すフローチャートである。 実行コードアドレス表のデータ構造の一例を示す図である。 代行処理管理表に格納されるデータのデータ構造の一例を示す図である。 第２の実施の形態にかかるメッセージ処理装置の構成を示すブロック図である。 第２の実施の形態における命令列生成処理の全体の流れを示すフローチャートである。 第２の実施の形態におけるパケット受信処理の全体の流れを示すフローチャートである。 第２の実施の形態におけるパケット送信処理の全体の流れを示すフローチャートである。

符号の説明

１００ メッセージ処理装置
１１０ ネットワークＩ／Ｆ部
１２０ メインメモリ
１２１ 代行処理管理表
１３０ 第１演算部
１３１ 割込処理部
１３２ 識別情報検出部
１３３ パケット処理部
１３４ プロセス検出部
１３５ 生成部
１３６ 保存部
１３７ 制御部
１４０ 第２演算部
１４１ ローカルメモリ
１４２ 演算処理部
１５０ バス
５００、６００、７００ メッセージ処理装置
６１０ ネットワークＩ／Ｆ部
７６０ マルチコアプロセッサ
１９００ メッセージ処理装置
１９３０ 第１演算部
１９３５ 生成部
１９３８ 受付部

Claims (14)

1. 処理内容を定めた制御命令列を実行可能な第１演算部と、
   前記第１演算部と同一または異なる制御命令列を実行可能な第２演算部と、
   メッセージの種類を識別する識別情報と、前記メッセージの送信または受信に関する処理であるネットワーク処理および前記ネットワーク処理に関連して前記メッセージに対して実行される特定処理を連続して実行する制御命令列と、を対応づけた処理情報を記憶する記憶部と、を備え、
   前記第１演算部は、
   前記メッセージから前記識別情報を検出する識別情報検出部と、
   検出された前記識別情報に対応する制御命令列を前記記憶部から取得し、取得した制御命令列を実行するように前記第２演算部を制御する制御部と、
   を備えたことを特徴とするメッセージ処理装置。
2. 前記第１演算部は、
   前記ネットワーク処理で処理する前記メッセージを入力するプロセスおよび前記ネットワーク処理で処理する前記メッセージを出力するプロセスの少なくとも一方を検出する第１プロセス検出部と、
   実行された前記特定処理を検出し、検出した前記特定処理の実行を依頼したプロセスを検出する第２プロセス検出部と、
   前記第１プロセス検出部が検出したプロセスと、前記第２プロセス検出部が検出したプロセスとが一致する場合に、前記ネットワーク処理および検出した前記特定処理を連続して実行する前記制御命令列を生成する生成部と、
   前記識別情報検出部によって検出された前記識別情報と、前記生成部によって生成された前記制御命令列とを対応づけた前記処理情報を前記記憶部に保存する保存部と、をさらに備えたこと、
   を特徴とする請求項１に記載のメッセージ処理装置。
3. 前記生成部は、さらに、前記ネットワーク処理および検出した前記特定処理の実行順序を判定し、前記ネットワーク処理および検出した前記特定処理を、判定した実行順序で実行する前記制御命令列を生成すること、
   を特徴とする請求項２に記載のメッセージ処理装置。
4. 前記第１演算部は、
   前記ネットワーク処理で処理する前記メッセージを入力するプロセスおよび前記ネットワーク処理で処理する前記メッセージを出力するプロセスの少なくとも一方を表す第１プロセスから、前記識別情報と、前記第１プロセスが実行を依頼する前記特定処理を識別する処理識別情報と、を含む前記処理情報の登録依頼を受け付ける受付部と、
   前記ネットワーク処理、および、受け付けた前記登録依頼に含まれる前記処理識別情報の前記特定処理を連続して実行する前記制御命令列を生成する生成部と、
   受け付けた前記登録依頼に含まれる前記識別情報と、生成された前記制御命令列とを対応づけた前記処理情報を前記記憶部に保存する保存部と、をさらに備えたこと、
   を特徴とする請求項１に記載のメッセージ処理装置。
5. 前記受付部は、さらに、前記ネットワーク処理および検出した前記特定処理の実行順序を表す順序情報を受け付け、
   前記生成部は、前記ネットワーク処理および受け付けた前記登録依頼に含まれる前記処理識別情報の前記特定処理を、受け付けた前記順序情報が表す実行順序で実行する前記制御命令列を生成すること、
   を特徴とする請求項４に記載のメッセージ処理装置。
6. 前記記憶部は、前記識別情報と、前記ネットワーク処理、予め定められた判定条件に基づいて前記特定処理の実行可否を判定する判定処理、および前記特定処理を連続して実行する前記制御命令列と、を対応づけた前記処理情報を記憶し、
   前記第２演算部は、前記判定処理の制御命令列を実行して前記特定処理が実行可能と判定されたときに、前記特定処理の制御命令列を実行すること、
   を特徴とする請求項１に記載のメッセージ処理装置。
7. 前記記憶部は、前記識別情報と、前記ネットワーク処理、前記特定処理の実行に必要なメッセージのデータサイズである前記判定条件に基づいて前記特定処理の実行可否を判定する前記判定処理、および前記特定処理を連続して実行する前記制御命令列と、を対応づけた前記処理情報を記憶し、
   前記第２演算部は、前記ネットワーク処理によって処理された前記メッセージのデータサイズが、前記特定処理の実行に必要なメッセージのデータサイズを表す予め定められた閾値より大きい場合に前記特定処理が実行可能であると判定すること、
   を特徴とする請求項６に記載のメッセージ処理装置。
8. 前記制御部は、さらに前記閾値を前記第２演算部に通知し、
   前記第２演算部は、前記ネットワーク処理によって処理された前記メッセージのデータサイズが、通知された前記閾値より大きい場合に前記特定処理が実行可能と判定すること、
   を特徴とする請求項７に記載のメッセージ処理装置。
9. 前記制御部は、前記特定処理の実行を依頼するプロセスに対して渡されたメッセージのデータサイズを前記閾値として前記第２演算部に通知すること、
   を特徴とする請求項８に記載のメッセージ処理装置。
10. 前記識別情報は、前記メッセージに含まれる送信元アドレス、宛先アドレス、送信元ポート番号、宛先ポート番号、適用するプロトコルを表すプロトコル情報、および前記プロトコルで使用するパラメータを識別する識別子の少なくとも１つであること、
    を特徴とする請求項１に記載のメッセージ処理装置。
11. 前記記憶部は、前記ネットワーク処理を実行する第１命令列のアドレスと前記特定処理を実行する第２命令列のアドレスと前記第１命令列および前記第２命令列の実行順序を表す順序情報とを含む前記制御命令列と、前記識別情報とを対応づけた前記処理情報を記憶し、
    前記第２演算部は、前記制御命令列に含まれる前記第１命令列のアドレスから前記第１命令列を取得し、前記制御命令列に含まれる前記第２命令列のアドレスから前記第２命令列を取得し、前記制御命令列に含まれる前記順序情報が表す実行順序で、取得した前記第１命令列および取得した前記第２命令列を実行すること、
    を特徴とする請求項１に記載のメッセージ処理装置。
12. 前記記憶部は、前記ネットワーク処理の入力データのアドレスを表す第１入力アドレスと、前記ネットワーク処理の出力データのアドレスを表す第１出力アドレスと、前記特定処理の入力データのアドレスを表す第２入力アドレスと、前記特定処理の出力データのアドレスを表す第２出力アドレスと、をさらに含む前記制御命令列と、前記識別情報とを対応づけた前記処理情報を記憶し、
    前記第２演算部は、前記第１入力アドレスの入力データに対して前記第１命令列を実行し、処理結果である出力データを前記第１出力アドレスに出力し、前記第２入力アドレスの入力データに対して前記第２命令列を実行し、処理結果である出力データを前記第２出力アドレスに出力すること、
    を特徴とする請求項１１に記載のメッセージ処理装置。
13. メッセージ処理装置で実行されるメッセージ処理方法であって、
    前記メッセージ処理装置は、
    処理内容を定めた制御命令列を実行可能な第１演算部と、
    前記第１演算部と同一または異なる制御命令列を実行可能な第２演算部と、
    メッセージの種類を識別する識別情報と、前記メッセージの送信または受信に関する処理であるネットワーク処理および前記ネットワーク処理に関連して前記メッセージに対して実行される特定処理を連続して実行する制御命令列と、を対応づけた処理情報を記憶する記憶部と、を備え、
    前記第１演算部が、前記メッセージから前記識別情報を検出する識別情報検出ステップと、
    前記第１演算部が、検出された前記識別情報に対応する制御命令列を前記記憶部から取得し、取得した制御命令列を実行するように前記第２演算部を制御する制御ステップと、
    を備えたことを特徴とするメッセージ処理方法。
14. メッセージ処理装置で実行されるメッセージ処理プログラムであって、
    前記メッセージ処理装置は、
    処理内容を定めた制御命令列を実行可能な第１演算部と、
    前記第１演算部と同一または異なる制御命令列を実行可能な第２演算部と、
    メッセージの種類を識別する識別情報と、前記メッセージの送信または受信に関する処理であるネットワーク処理および前記ネットワーク処理に関連して前記メッセージに対して実行される特定処理を連続して実行する制御命令列と、を対応づけた処理情報を記憶する記憶部と、を備え、
    前記第１演算部を、
    前記メッセージから前記識別情報を検出する識別情報検出部と、
    検出された前記識別情報に対応する制御命令列を前記記憶部から取得し、取得した制御命令列を実行するように前記第２演算部を制御する制御部と、
    として機能させるメッセージ処理プログラム。

Images