(57)【要約】【課題】アプリケーション側がコマンド境界を検索する必要が無く、ＣＰＵへの負荷を軽減することのできるネットワーク通信システムを提供する。【解決手段】アプリケーション処理サーバ１は、ＣＰＵ３と、対向ホストから送出されたパケットを受信し、該受信パケットに基づいてメッセージストリームを再構築し、該再構築したメッセージストリームを主記憶部５に書き込むネットワークインタフェースカード２とを有する。ＣＰＵ３上で動作するアプリケーションは、主記憶部５に書き込まれたメッセージストリームをコマンドとして解釈して対向ホストとの通信処理を実行する。ネットワークインタフェースカード２は、再構築したメッセージストリーム中に予め登録された検知用パターンに適合するパターンがある場合に、該適合パターンをコマンドの区切りと判断して、再構築したメッセージストリームをコマンド毎に主記憶部５に書き込む。【選択図】図１
2008219252.tif 000002
【特許請求の範囲】
【請求項１】
主記憶部と、
対向ホストから送出されたパケットを受信し、該受信パケットに基づいてメッセージストリームを再構築し、該再構築したメッセージストリームを前記主記憶部に書き込むネットワークインタフェース部と、
前記主記憶部に書き込まれたメッセージストリームをコマンドとして解釈して前記対向ホストとの通信処理を実行するアプリケーション実行部と、を有し、
前記ネットワークインタフェース部は、前記再構築したメッセージストリーム中に予め登録された検知用パターンに適合するパターンがある場合に、該適合パターンを前記コマンドの区切りと判断して、前記再構築したメッセージストリームを前記コマンド毎に前記主記憶部に書き込むことを特徴とするネットワーク通信システム。
【請求項２】
前記ネットワークインタフェース部は、
前記再構築したメッセージストリームを保持する受信メッセージ保持部と、
前記受信メッセージ保持部で保持したメッセージストリーム中に前記適合パターンがあるか否かを調べるパターン検知部と、を有し、
前記パターン検知部により前記適合パターンが検知されると、前記受信メッセージ保持部で保持したメッセージストリームの、先頭から前記適合パターンまでのデータが、前記主記憶部に書き込まれる、請求項１に記載のネットワーク通信システム。
【請求項３】
前記検知用パターンは、前記コマンドの開始および終了をそれぞれ示す開始パターンおよび終了パターンを含み、
前記ネットワークインタフェース部は、
前記再構築したメッセージストリームを保持する受信メッセージ保持部と、
前記受信メッセージ保持部で保持したメッセージストリーム中に前記開始パターンおよび終了パターンにそれぞれ適合するパターンがあるか否かを調べるパターン検知部と、を有し、
前記パターン検知部により前記開始パターンおよび終了パターンにそれぞれ適合するパターンが検知されると、前記受信メッセージ保持部で保持したメッセージストリームの、前記開始パターンに適合するパターンから前記終了パターンに適合するパターンまでのデータが、前記主記憶部に書き込まれる、請求項１に記載のネットワーク通信システム。
【請求項４】
前記開始パターンに適合するパターンが検知されると有効とされ、前記終了パターンに適合するパターンが検知されると無効とされる内部フラグをさらに有し、
前記パターン検知部は、前記内部フラグを参照して、前記開始パターンに適合するパターンから前記終了パターンに適合するパターンまでのデータを判断する、請求項３に記載のネットワーク通信システム。
【請求項５】
前記対向ホストとの通信が開始される際に、前記検知用パターンが前記アプリケーション実行部によって前記パターン検知部に通知される、請求項１から４のいずれか１項に記載のネットワーク通信システム。
【請求項６】
前記検知用パターンは任意のパターンである、請求項１から５のいずれか１項に記載のネットワーク通信システム。
【請求項７】
前記検知用パターンは、文字列を予め定められた１つの形式で表現する正規表現で表されたパターンであり、
前記パターン検知部は、前記正規表現でのパターン検知が可能な正規表現検索ロジックを有する、請求項１から６のいずれか１項に記載のネットワーク通信システム。
【請求項８】
前記検知用パターンは、固定パターンをさらに含み、
前記パターン検知部は、前記固定パターンでのパターン検知が可能な固定パターン検索ロジックをさらに有し、
前記アプリケーション実行部から通知された前記検知用パターンが前記固定パターンである場合に、前記正規表現検索ロジックから前記固定パターン検索ロジックに動的に切り替わる、請求項７に記載のネットワーク通信システム。
【請求項９】
主記憶部、ネットワークインタフェース部およびＣＰＵを有するサーバ装置において行われるアプリケーション通知方法であって、
前記ネットワークインタフェース部が、対向ホストから送出されたパケットを受信し、該受信パケットに基づいてメッセージストリームを再構築し、該再構築したメッセージストリームを前記主記憶部に書き込む第１のステップと、
前記ＣＰＵ上で動作するアプリケーションが、前記主記憶部に書き込まれたメッセージストリームをコマンドとして解釈して前記対向ホストとの通信処理を実行する第２のステップと、を含み、
前記第１のステップは、前記ネットワークインタフェース部が、前記再構築したメッセージストリーム中に予め登録された検知用パターンに適合するパターンがある場合に、該適合パターンを前記コマンドの区切りと判断して、前記再構築したメッセージストリームを前記コマンド毎に前記主記憶部に書き込むステップを含む、アプリケーション通知方法。
【請求項１０】
前記第１のステップは、前記ネットワークインタフェース部が、前記再構築したメッセージストリームを保持し、該保持したメッセージストリーム中に前記適合パターンがあるか否かを調べ、前記適合パターンがある場合に、前記保持したメッセージストリームの、先頭から前記適合パターンまでのデータを前記主記憶部に書き込むステップをさらに含む、請求項９に記載のアプリケーション通知方法。
【請求項１１】
前記検知用パターンは、前記コマンドの開始および終了をそれぞれ示す開始パターンおよび終了パターンを含み、
前記第１のステップは、前記ネットワークインタフェース部が、前記再構築したメッセージストリームを保持し、該保持したメッセージストリーム中に前記開始パターンおよび終了パターンにそれぞれ適合するパターンがあるか否かを調べ、前記開始パターンおよび終了パターンにそれぞれ適合するパターンがある場合に、前記保持したメッセージストリームの、前記開始パターンに適合するパターンから前記終了パターンに適合するパターンまでのデータを前記主記憶部に書き込むステップをさらに含む、請求項９に記載のアプリケーション通知方法。
【請求項１２】
前記開始パターンに適合するパターンが検知されると有効とされ、前記終了パターンに適合するパターンが検知されると無効とされる内部フラグが、前記ネットワークインタフェース部に設けられており、
前記第１のステップは、前記ネットワークインタフェース部が、前記内部フラグを参照して、前記開始パターンに適合するパターンから前記終了パターンに適合するパターンまでのデータを判断するステップをさらに含む、請求項１１に記載のアプリケーション通知方法。
【請求項１３】
前記対向ホストとの通信が開始される際に、前記アプリケーションが、前記検知用パターンを前記ネットワークインタフェース部に通知するステップをさらに含む、請求項９から１２のいずれか１項に記載のアプリケーション通知方法。
【請求項１４】
前記検知用パターンは任意のパターンである、請求項９から１３のいずれか１項に記載のアプリケーション通知方法。
【請求項１５】
前記検知用パターンは、文字列を予め定められた１つの形式で表現する正規表現で表されたパターンである、請求項９から１４のいずれか１項に記載のアプリケーション通知方法。
【請求項１６】
前記検知用パターンは、固定パターンをさらに含み、
前記第１のステップは、前記アプリケーションから通知された前記検知用パターンが前記固定パターンである場合に、前記正規表現でのパターン検知が可能な正規表現検索ロジックから前記固定パターンでのパターン検知が可能な固定パターン検索ロジックに動的に切り替えるステップをさらに含む、請求項１５に記載のアプリケーション通知方法。
【請求項１７】
対向ホストから送出されたパケットを受信し、該受信パケットに基づいてメッセージストリームを再構築し、該再構築したメッセージストリームを主記憶部に書き込む第１の処理を、ネットワークインタフェースカードに実行させ、
前記主記憶部に書き込まれたメッセージストリームをコマンドとして解釈して前記対向ホストとの通信処理を実行する第２の処理を、ＣＰＵに実行させるプログラムであって、
前記第１の処理は、前記再構築したメッセージストリーム中に予め登録された検知用パターンに適合するパターンがある場合に、該適合パターンを前記コマンドの区切りと判断して、前記再構築したメッセージストリームを前記コマンド毎に前記主記憶部に書き込む処理を含む、プログラム。
【請求項１８】
主記憶部と、該主記憶部に書き込まれたメッセージストリームをコマンドとして解釈して対向ホストとの通信処理を実行するアプリケーション実行部と、を有するサーバ装置に搭載されるネットワークインタフェースカードであって、
前記対向ホストから送出されたパケットを受信するパケット受信部と、
前記パケット受信部で受信したパケットに基づいてメッセージストリームを再構築するメッセージ再構築部と、
前記メッセージ再構築部で再構築したメッセージストリームを保持する受信メッセージ保持部と、
前記受信メッセージ保持部に保持されたメッセージストリーム中に予め登録された検知用パターンに適合する適合パターンがあるか否かを調べるパターン検知部と、を有し、
前記パターン検知部により前記適合パターンが検知されると、前記受信メッセージ保持部で保持したメッセージストリームの、先頭から前記適合パターンまでのデータが、前記主記憶部に書き込まれる、ネットワークインタフェースカード。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＴＣＰ（Transmission Control Protocol）に代表される、パケットの再送やメッセージのリアセンブル（再構築）処理に対応したプロトコルの上位層で、ＳＯＡＰ（Simple Object Access Protocol）、ＳＭＴＰ（Simple Mail Transfer Protocol）、ＳＩＰ（Session Initiation Protocol）といった、メッセージベースのアプリケーションプロトコルを用いて通信を行うネットワーク通信システムに関する。より具体的には、本発明は、ネットワーク通信システム上のネットワークインタフェースカードで対向ホストよりパケットを受信し、受信パケットから再構築されたメッセージストリームをネットワーク通信システム上のアプリケーションへ通知する方式に関し、特に、再構築後のメッセージストリームを主記憶メモリへ書き込み及び複製する際のアクセス方式に関する。
【背景技術】
【０００２】
従来、ＴＣＰに代表される、対向ホストまで到達されるまでに廃棄されたパケットの再送処理や、受信パケットのデータシーケンス番号情報を元にメッセージストリームの再構築を行うプロトコルを基盤として、上位層で、ＳＯＡＰ、ＳＩＰ、ＳＭＴＰなどのアプリケーションプロトコルを使用する通信システムが提供されているが、その多くは、ネットワークインタフェースカードとＣＰＵ（Central Processing Unit）と主記憶メモリとから構成されたサーバ装置である。
【０００３】
ネットワークインタフェースカードは、パケットを受信する毎に、受信したパケットを主記憶メモリに書き込み、ＣＰＵ上で動作するＯＳ（Operating System）に対して、書き込んだパケットに関する情報を通知する。ＯＳは、受信したパケットのシーケンス番号の情報からメッセージストリームの再構築を行い、ソケットバッファに格納する。
【０００４】
アプリケーションは、read()システムコールを発行することにより、ソケットバッファからアプリケーションのユーザ領域にデータを読み出してプロトコル処理を行う。POSIXというUNIXのシステムコールの規定によれば、read()システムコールは、以下の引数からなる。
【０００５】
（返り値：実際に読み出した長さ） = read(ファイルディスクリプタ, 取得データの先頭アドレスのポインタ, 要求するデータの長さ)
ＴＣＰセッションの確立後にread()システムコールを発行することで、ＯＳは、そのread()システムコールに応じて、read()システムコールで要求されるデータの長さ分までのデータをソケットバッファ中から読み出してアプリケーションのユーザ領域のポインタで示されたアドレスに書き込み、ソケットバッファから読み出した長さを返り値としてアプリケーションに渡す。
【０００６】
また、多くのネットワークインタフェースカードは、パケットを受信したタイミングで主記憶メモリへの書き込みを実施し、ＴＣＰのメッセージストリームの再構築処理及びＴＣＰの応答処理と言ったプロトコル処理は、ＣＰＵ上で動作するＯＳに任せる。この場合、ＣＰＵは、ＴＣＰ処理及び上位層処理の両方を行う必要があるため、上位層のアプリケーション処理を行うための十分なＣＰＵリソースが割り当てられない場合がある。
【０００７】
また、ネットワークインタフェースカードが、パケットを受信したタイミングで主記憶メモリに書き出す場合、主記憶メモリにおけるメモリアクセス遅延が大きいため、メモリアクセスの回数を削減することが要求される。
【０００８】
ＣＰＵ負荷及びメモリアクセスの問題を解決するために、ＴＣＰ ChimneyのようなＴＯＥ(TCP Offload Engine)アーキテクチャでは、受信したＴＣＰパケットをネットワークインタフェースカード上でメッセージストリームの形に再構築し、再構築したメッセージストリームをソケットバッファに書き込む形式を採用している。これにより、ＴＣＰ処理のＣＰＵ負荷及び主記憶メモリへのアクセス回数を削減し、性能向上を図っている。
【０００９】
ＴＣＰ Chimneyでは、以下の３条件のいずれかが満たされれば、上位層にメッセージストリームを渡して完了通知を送る(非特許文献１参照)。
【００１０】
（１）PSHフラグ付きのパケットを受信
（２）受信バッファが一杯
（３）タイムアウト(200msec)発生
しかし、これらの転送条件は、上位層であるアプリケーション層が必要とするコマンド区切りを考慮していない。そのため、アプリケーションは、read()システムコールによりメッセージストリームをソケットバッファから読み込んだ後、アプリケーションのコマンド区切りを検索する必要がある。文字列検索は、アプリケーション処理において負荷が大きいため、文字列検索負荷の軽減が求められる。
【非特許文献１】" Scalable Networking: Network Protocol Offload-Introducing TCP Chimney "、Microsoft Corporation 、WinHEC 2004 Version - April 9, 2004（Page 19、"Receive Completions"参照）
【発明の開示】
【発明が解決しようとする課題】
【００１１】
ネットワークインタフェースカードが受信パケットからメッセージストリームを再構築してアプリケーション側に通知する従来の方式においては、アプリケーションに通知されるメッセージストリームの通知単位は、アプリケーションが必要とするコマンド境界が考慮されていないために、アプリケーション側でコマンド境界を検索するための文字列検索処理を行う必要があり、その分、ＣＰＵへの負荷が増大する。
【００１２】
本発明の目的は、上記の問題を解決し、アプリケーション側がコマンド境界を検索する必要が無く、ＣＰＵへの負荷を軽減することのできるネットワーク通信システムを提供することにある。
【課題を解決するための手段】
【００１３】
上記目的を達成するため、本発明のネットワーク通信システムは、
主記憶部と、
対向ホストから送出されたパケットを受信し、該受信パケットに基づいてメッセージストリームを再構築し、該再構築したメッセージストリームを前記主記憶部に書き込むネットワークインタフェース部と、
前記主記憶部に書き込まれたメッセージストリームをコマンドとして解釈して前記対向ホストとの通信処理を実行するアプリケーション実行部と、を有し、
前記ネットワークインタフェース部は、前記再構築したメッセージストリーム中に予め登録された検知用パターンに適合するパターンがある場合に、該適合パターンを前記コマンドの区切りと判断して、前記再構築したメッセージストリームを前記コマンド毎に前記主記憶部に書き込むことを特徴とする。
【００１４】
上記の構成によれば、ネットワークインタフェース部は、再構築したメッセージストリームをアプリケーション実行部が必要とするコマンド毎に主記憶部に書き込み、アプリケーション実行部は、主記憶部から、コマンド毎にメッセージストリームを読み出す。このように、再構築したメッセージストリームのアプリケーションへの通知単位は、アプリケーションが必要とするコマンド単位で行われる。よって、アプリケーション側でコマンド境界を検索するための文字列検索処理を行う必要はない。
【発明の効果】
【００１５】
本発明によれば、アプリケーション側でアプリケーションプロトコルのコマンド境界を探索する必要が無いので、その分、ＣＰＵの負荷を軽減することができ、高速にプロトコル処理を行う事が出来る。
【発明を実施するための最良の形態】
【００１６】
次に、本発明の実施の形態について図面を参照して説明する。
【００１７】
（第１の実施形態）
図１は、本発明の第１の実施形態であるアプリケーション処理サーバの構成を示すブロック図である。通信プロトコルとしては、トランスポート層において、ＴＣＰ（Transmission Control Protocol）を想定しており、上位層においては、ＳＯＡＰ（Simple Object Access Protocol）やＳＭＴＰ（Simple Mail Transfer Protocol）、ＳＩＰ（Session Initiation Protocol）などのテキストベースのアプリケーションプロトコルを想定している。
【００１８】
図１を参照すると、アプリケーション処理サーバ１は、ネットワーク通信システムまたは監視システムを構成するものであって、対向ネットワーク１０を通じた対向ホストからのパケット受信処理及びプロトコル処理を行うネットワークインタフェースカード２と、アプリケーションやＯＳ（Operating System）が動作するＣＰＵ（中央演算部）３と、ＮｏｒｔｈＢｒｉｄｇｅチップに相当し、ＣＰＵ３とネットワークインタフェースカード２の主記憶部５に対する読み書きの処理の調停を行うアクセス調停部４と、パケットデータやアプリケーションデータ（プログラムを含む）が格納される主記憶部５と、を有する。
【００１９】
ネットワークインタフェースカード２は、ネットワークインタフェース部であって、受信したＴＣＰデータのセッション解決、シーケンス番号の整合性チェック、応答ＡＣＫパケットの送出（通信システムの場合）といったＴＯＥ(TCP Offload Engine)としてのプロトコル処理を行ったり、受信ＴＣＰパケットからメッセージストリームの再構築を行い、主記憶部５にデータを保存したりする機能を有する。
【００２０】
ネットワークインタフェースカード２は、受信パケットの正常性チェックとプロトコル処理を行うパケット受信部２１と、受信ＴＣＰパケットからメッセージストリームの再構築処理を行うメッセージ再構築部２２と、再構築されたメッセージストリームを格納する受信メッセージ保持部２３と、メッセージストリームからアプリケーションが必要とするパターンを検知するパターン検知部２４とから構成される。検知用パターンは予め登録されており、アプリケーションプログラムによって、対向ホストとの通信時にその登録された検知用パターンがパターン検知部２４に通知される。パターン検知部２４は、その通知された検知用パターンを記憶する。検知用パターンは、開始パターン及び終了パターンを含む。
【００２１】
主記憶部５は、ＤＤＲ（Double Data Rate）メモリに代表されるメインメモリであって、より具体的には、ＤＤＲ  ＤＩＭＭ（Dual In-line Memory Module）などにより構成される。主記憶部５は、ネットワークインタフェースコマンド受信部５１と、プロトコル処理用データ記憶部５２と、アプリケーションユーザ用データ記憶部５３とから構成される。
【００２２】
ネットワークインタフェースコマンド受信部５１は、ネットワークインタフェースカード２から受信したメッセージストリームの情報を管理する。ネットワークインタフェースカード２は、メッセージストリームをプロトコル処理用データ記憶部５１に書き込んだ後に、送信完了したメッセージストリームに関しての情報をネットワークインタフェースコマンド受信部５１に書き込む。
【００２３】
プロトコル処理用データ記憶部５２は、ＯＳでいうところのソケットバッファに相当する。プロトコル処理用データ記憶部５２は、アプリケーションから直接参照することが出来ず、アプリケーション側が発行したread()システムコールに応じてデータをアプリケーションユーザ用データ記憶部５３へコピーする。
【００２４】
次に、プリケーション処理サーバ１の動作について説明する。
【００２５】
図２および図３は、ネットワークインタフェースカード２の動作を説明するためのフローチャートである。便宜上、動作の流れを図２および図３の２つに分けているが、これらの動作は一連の動作である。以下、図１から図３を参照してネットワークインタフェースカード２の動作を説明する。
【００２６】
対向ネットワーク１０からＴＣＰパケットを受信すると（図２のステップＡ１）、パケット受信部２１が、ＴＣＰパケットのプロトコルの整合性（ＴＣＰのフィールドの整合性）をチェックし（図２のステップＡ２）、ＴＣＰパケット情報からＴＣＰのフロー情報を識別する（図２のステップＡ３）。さらに、パケット受信部２１は、シーケンス番号を参照して、ＴＣＰパケットの到着順序がIn-Order（対向ホストから送信された順序で受信される）なのか、Out-of-Order（対向ホストから送信された時とは違う順序で受信される）なのかを判定する（図２のステップＡ４）。なお、プリケーション処理サーバ１がＴＣＰデータを終端する通信装置である場合は、ネットワークインタフェースカード２は、ＡＣＫパケットの送出処理などを行う。
【００２７】
ＴＣＰパケットのプロトコル処理後、メッセージ再構築部２２は、受信したＴＣＰパケットのシーケンス情報に基づいて、ＴＣＰパケットからメッセージストリームを再構築する（図２のステップＡ５）。そして、メッセージ再構築部２２は、その再構築したメッセージストリームを受信メッセージ保持部２３に書き込む（図２のステップＡ６）。
【００２８】
メッセージストリームが受信メッセージ保持部２３に書き込まれた後、ネットワークインタフェースカード２では、アプリケーションからパターン検知部２４に検知用のパターンが登録されているかのチェックが行われる（図３のステップＡ７）。検知用のパターンとしては、アプリケーションが必要とするデータの開始パターン、終了パターンの２種のパターンがある。開始パターンおよび終了パターンは、ＴＣＰのソケット確立時に、ソケットオプションを登録するsetsockopt()システムコール等のソケットパラメータ登録用関数を用いて登録される。これらパターンは、いくつかの文字列を予め定められた１つの形式で表現する正規表現で登録可能である。
【００２９】
パターン検知部２４は、正規表現パターン検索ロジックで構成されており、入力メッセージストリームに対して登録されたパターンが存在するか否かを判定する検索処理を実行する。検索中のメッセージストリームが開始パターンに適合していると判定した場合は、内部パラーメータであるパターン適合中フラグがＯＮとなる。パターン適合中フラグの初期値はＯＦＦとする。
【００３０】
ステップＡ７で、検知用のパターンが登録されていると判断された場合は、パターン検知部２４は、パターン適合中フラグがＯＮであるか否かを調べる（図３のステップＡ８）。ステップＡ７で、検知用のパターンがまだ登録されていないと判断された場合は、図３のＡ１６のステップに移行する。
【００３１】
ステップＡ８で、パターン適合中フラグがＯＦＦであると判断された場合は、パターン検知部２４は、まず、登録されている開始パターンについて、メッセージストリームを検索する(図３のＡ９)。メッセージストリーム中に開始パターンが見つかった場合は、パターン検知部２４は、パターン適合中フラグをＯＮとする（図３のＡ１１）。その後、図３のＡ１２のステップに移行する。メッセージストリーム中に開始パターンが見つからなかった場合は、図３のＡ１５のステップに進む。
【００３２】
ステップＡ８で、パターン適合中フラグがＯＮであると判断された場合は、受信メッセージ保持部２３に登録されているメッセージストリームもしくは、過去のメッセージストリームにおいて、開始パターンが見つかったことを示す。
【００３３】
ステップＡ８で、パターン適合中フラグがＯＮであると判断された場合、または、ステップＡ１１でパターン適合中フラグがＯＮであると判断された場合は、パターン検知部２４は、登録されている終了パターンについて、メッセージストリームを検索する（図３のステップＡ１２）。終了パターンが見つかった場合は、パターン検知部２４は、アプリケーションデータとして、開始パターンから終了パターンまでのメッセージストリームを、受信メッセージ保持部２３からプロトコル処理用データ記憶部５２へ転送させ、同時にパターン適合中フラグをＯＦＦとする（図３のステップＡ１４）。
【００３４】
ここで、注意点として、開始パターンと終了パターンの双方が、受信メッセージ保持部２３に格納されているメッセージストリームの内部に存在する場合で、メッセージストリームをアプリケーションメッセージとして転送する場合は、ストリームの順序として、開始パターンが終了パターンよりも前に位置しなければならない。また、パターン適合中フラグがＯＮであり、メッセージストリームの内部に終了パターンのみが存在する場合は、受信メッセージ保持部２３に格納されている受信メッセージストリームの先頭から終了パターンまでの領域をプロトコル処理用データ記憶部５２に転送する。
【００３５】
メッセージストリーム転送後、パターン検知部２４は、転送したメッセージストリームについての情報（コマンド）を主記憶部５上のネットワークインタフェースコマンド受信部５１に書き込む（図３のステップＡ１５）。その後、データ受信処理に戻る。
【００３６】
ステップＡ７、Ａ１０、Ａ１３のいずれかの判定で「Ｎｏ」となった場合は、ネットワークインタフェースカード２では、以下の３つの条件Ｃ１〜Ｃ３のいずれかを満たすか否かの判定が行われる（図３のＡ１６）。
【００３７】
Ｃ１：受信パケットのＰＳＨフラグがＯＮ
Ｃ２：受信バッファがＦＵＬＬの状態
Ｃ３：タイムアウト（２００ｍｓｅｃ）発生
条件Ｃ１〜Ｃ３のいずれかを満たす場合は、受信バッファ（受信メッセージ保持部２３）に存在するメッセージストリームをプロトコル処理用データ記憶部５２に転送し（図３のステップＡ１７）、転送したメッセージストリームに関する情報（コマンド）をネットワークインタフェースコマンド受信部５１に書き込む（図３のステップＡ１８）。その後、データ受信処理に戻る。
【００３８】
条件Ｃ１〜Ｃ３のいずれも満たさない場合は、次のパケット処理を行うため、データ受信処理に戻る。
【００３９】
次に、ＣＰＵ３の動作を説明する。図４に、ＣＰＵ３の動作フローを示す。以下、図１、図４を参照して動作説明を行う。
【００４０】
ＯＳ及びアプリケーションはＣＰＵ３上で動作しており、主記憶部５をＯＳ及びアプリケーションの実行領域及びデータ領域として使用する。ＯＳは、プロトコル処理を行うが、その際、ソケットバッファとしてプロトコル処理用データ記憶部５２を使用する。アプリケーションは、アプリケーション用ユーザ領域としてアプリケーションユーザ用データ記憶部５３を使用する。ＯＳによる書き込み保護のため、アプリケーションは、ソケットバッファに相当するプロトコル処理用データ記憶部５２を参照することが出来ない。これは、Linux、BSDを初めとする汎用ＯＳの制限となっている。
【００４１】
図４において、太枠で示されたステップＢ１、Ｂ２、Ｂ７がアプリケーション側の処理、細枠で示されたステップＢ３〜Ｂ６がＯＳ側の処理である。
【００４２】
アプリケーションは、まず、アプリケーションがプロトコル処理に必要とするコマンドについてsetsockopt()システムコールもしくは、独自関数を用いて、アプリケーションコマンドの開始を示すパターン及び、終了を示すパターンを登録する（図４のステップＢ１）。登録されたパターンは、ネットワークインタフェースカード２のパターン検知部２４に登録される。その後、アプリケーションは、ＯＳからのプロトコルデータを取得するため、read()システムコールを発行し、ＯＳからのデータ待ちの状態（待機状態）となる（図４のステップＢ２）。
【００４３】
ＯＳは、主記憶部５上のネットワークインタフェースコマンド受信部５１を参照し（図４のステップＢ３）、ネットワークインタフェースカード２がプロトコル処理用データ記憶部５２に転送したメッセージストリームに関する情報（コマンド）が到着したか否かを判断する（図４のステップＢ４）。このコマンドの到着により、メッセージストリームがプロトコル処理用データ記憶部５２に転送されたと判断することができる。ＯＳは、コマンドが到着するまで待機する。
【００４４】
コマンドが到着すると、ＯＳは、ネットワークインタフェースカード２からプロトコル処理用データ記憶部５２に転送されたメッセージストリームの領域をアプリケーションユーザ用データ記憶部５３にコピーし（図４のステップＢ５）、その旨をアプリケーションに通知する（図４のステップＢ６）。
【００４５】
通知を受けたアプリケーションは、read()システムコールを終了する（図４のステップＢ７）。アプリケーションは、ＯＳからの通知を受けて、read()システムコールにより得られたデータを使用することができる。その後、次のパケット処理を行うために、ＣＰＵ処理に戻る。
【００４６】
従来は、上位層のアプリケーションにメッセージストリームを転送する際に、上位層であるアプリケーション層が必要とするコマンド区切りを考慮していないため、アプリケーションはread()システムコールによりメッセージストリームをソケットバッファから読み込んだ後、アプリケーションのコマンド区切りを検索する必要があった。これに対して、本実施形態によれば、予めアプリケーションの処理単位のパターンを登録しておくことで、ネットワークインタフェースカードがアプリケーションの処理単位のデータを受信した時点でアプリケーションに通知するため、アプリケーション側は、コマンド区切り毎にデータを受信することになる。よって、アプリケーションが処理単位のコマンド区切りを検索する必要がなくなり、その分、ＣＰＵの負荷が軽減され、高速にプロトコル処理を行う事が出来る。特に、複数クライアントからのアプリケーション処理を受け付ける、ＳＩＰ、ＳＯＡＰサーバに本実施形態のサーバを適用した場合に、ＣＰＵの負荷軽減およびプロトコル処理の高速化について大きな効果が得られる。
【００４７】
（第２の実施形態）
電子メールで一般的に使用されているＳＭＴＰといったアプリケーションプロトコル処理を行う場合、ＳＭＴＰコマンドの一単位は必ず改行コード（<CR>+<LF>）で区切られる。つまり、ＳＭＴＰ処理に関しては、コマンド終了パターンは、必ず改行コードのパターンになる。ここでは、ＳＭＴＰ処理の様な改行毎にコマンド処理を実行するシステムに最適な実施形態について述べる。
【００４８】
本発明の第２の実施形態であるアプリケーション処理サーバの基本構成は、図１に示した構成と同様であるので、各部の詳細な説明は省略する。但し、アプリケーションに登録されている検知用パターンは、改行コードのみとする。検知用パターンが一種類だけの場合、メッセージストリーム中に検知用パターンにマッチするパターンが見つかる度に上位層に通知するものとする。
【００４９】
対向ホストからデータを受信してからそのデータを受信メッセージ保持部２３に書き込むまでの処理は図２に示したフローのとおりであるが、ステップＡ７以降の処理が、第１の実施形態のものと異なる。図５に、本実施形態のアプリケーション処理サーバの動作フローを示す。以下、図１および図５を参照して、動作説明を行う。
【００５０】
ステップＡ７にて、ネットワークインタフェースカード２において、改行コード(<CR>+<LF>)が検知用パターンとしてパターン検知部２４に登録されているか否かの判断が行われる。改行コードが登録されていない場合は、図５のＡ１２−１のステップに移行する。
【００５１】
改行コードが登録されている場合は、パターン検知部２４が、改行コードについて、受信メッセージ保持部２３に保持されているメッセージストリームを検索し(図５のステップＡ８−１)、改行コードが見つかったか否かの判断を行う(図５のステップＡ９−１)。
【００５２】
改行コードが見つかった場合、パターン検知部２４は、受信メッセージ保持部２３に保持されているメッセージストリームの先頭から改行コードまでのメッセージをプロトコル処理用データ記憶部５２に転送させる（図５のステップＡ１０−１）。メッセージストリーム転送後、パターン検知部２４は、転送したメッセージストリームについての情報（コマンド）を主記憶部５上のネットワークインタフェースコマンド受信部５１に書き込む（図５のステップＡ１１−１）。その後、データ受信処理に戻る。
【００５３】
ステップＡ７、Ａ９−１のいずれかの判定で「Ｎｏ」となった場合は、ネットワークインタフェースカード２では、上述の条件Ｃ１〜Ｃ３のいずれかを満たすか否かの判定が行われる（図５のＡ１２−１）。
【００５４】
条件Ｃ１〜Ｃ３のいずれかを満たす場合は、受信バッファ（受信メッセージ保持部２３）に存在するメッセージストリームをプロトコル処理用データ記憶部５２に転送し（図５のステップＡ１３−１）、転送したメッセージストリームに関する情報（コマンド）をネットワークインタフェースコマンド受信部５１に書き込む（図５のステップＡ１４−１）。その後、データ受信処理に戻る。
【００５５】
条件Ｃ１〜Ｃ３のいずれも満たさない場合は、次のパケット処理を行うため、データ受信処理に戻る。
【００５６】
本実施形態によれば、ＳＭＴＰの様な改行単位でコマンド処理を行うプロトコルに関しては、改行パターンを予め登録しておくことで、アプリケーションはread()システムコールから改行毎にデータを受信することが出来、アプリケーション側で改行区切りを検索する処理負荷を削減することができる。
【００５７】
（第３の実施形態）
いくつかの文字列を１つの形式で表現する正規表現検索に対して、固定パターン検索では、特定パターンがメッセージストリームに含まれているか否かを判断するだけでよい。したがって、パターン検索ロジックに固定パターン検索を適用することで、ロジック数を削減することができ、高速検索が可能となる。ここでは、固定パターン検索を適用した実施形態について説明する。
【００５８】
図６は、本発明の第３の実施形態であるアプリケーション処理サーバの構成を示すブロック図である。図６を参照すると、アプリケーション処理サーバ１００は、パターン検知部２４内に、固定パターンの検索に特化したロジックを有する固定パターン検知部２５を備えており、この点が、第１の実施形態のものと異なる。
【００５９】
アプリケーションから通知されたパターンが固定パターンであった場合、パターン検索部２４の検索ロジックから固定パターン検索部２５の検索ロジックに動的に切り替わる。そして、パターン検索部２４による正規表現検索の代わりに固定パターン検索部２５による固定パターン検索が行われる。これ以外の動作は、第１の実施形態の場合と同じである。
【００６０】
このように、パターン検索部２４の検索ロジックから固定パターン検索部２５の検索ロジックに動的に切り替わることで、高速に検索することが可能となり、その結果、受信メッセージストリームのパターン検知に要する時間が短縮される。
【００６１】
以下、本発明のアプリケーション処理サーバの具体的な動作例について説明する。
【実施例１】
【００６２】
ここでは、ＳＯＡＰに適用した場合の動作例について説明する。
【００６３】
ＳＯＡＰは、ソフトウェア同士がメッセージ（オブジェクト）を交換する（リモートプロシージャコール−遠隔手続呼び出し）ためのプロトコルである。一般に、ＳＯＡＰプロトコルを実装したアプリケーション処理サーバでは、複数のクライアントから遠隔手続きのためのＳＯＡＰメッセージが送られてくるが、ＳＯＡＰのプロトコル処理がボトルネックになるために、サーバアプリケーションの負荷軽減が求められている。
【００６４】
ショッピングサイトの場合、以下のようなＳＯＡＰメッセージがクライアントからアプリケーション処理サーバへ送られてくる。
[ＳＯＡＰメッセージ]
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Body> 
<getProductDetails xmlns="http://warehouse.example.com/ws"> 
<productId>827635</productId> 
</getProductDetails>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
上記のとおり、ＳＯＡＰメッセージは、<SOAP-ENV:Envelope> ・・・</SOAP-ENV:Envelope>の文字列で囲まれたパターンとなっている。この文字列は、およそ２７０バイトのデータである。このメッセージが、セッション開設後に、対向ネットワークから届いたと仮定する。従来のネットワークインタフェースでは、ＳＯＡＰメッセージがネットワークインタフェースカードまで到着しても、
（１）ＴＣＰのＰＳＨフラグがＯＮ、
（２）受信バッファがＦＵＬＬ
（３）タイムアウト発生
といった３つの条件のうちのいずれかの条件が適合するまでは、ネットワークインタフェースカードは、到着したＳＯＡＰメッセージを主記憶部へ転送しない。例えば、受信パケットのＴＣＰフラグは、通常、データのＡＣＫのみ、受信バッファのサイズが６４Ｋバイトとされるが、その場合、次のメッセージを受信して受信バッファがＦＵＬＬになるか、タイムアウト（ＴＣＰ Chimneyでは２００ｍｓｅｃ）が発生するまでは、受信パケットはネットワークインタフェースカード中に蓄積されたままである。
【００６５】
これに対して、本発明のアプリケーション処理サーバは、以下のように動作する。
【００６６】
アプリケーション処理サーバにおいて、あらかじめ、setsockopt()関数などを使用して、開始パターン、終了パターンを以下の正規表現で登録しておく。
【００６７】
開始パターン： /\<SOAP-ENV\:Envelope*/
終了パターン /\<\/SOAP-ENV\:Envelope\>/
上記の場合、setsockopt()関数としては、以下のようなものが挙げられる。
setsockopt()関数
setsockopt(socket,SOL_SOCKET,SO_REGX,&rcv_regx,sizeof(struct rcv_regx));
struct rcv_regx [
char start_reg [STR_LEN]; => "/\<SOAP-ENV\:Envelope*/"
char end_reg [STR_LEN]; => "/\<\/SOAP-ENV\:Envelope\>/"
];
開始パターンは、ＳＯＡＰメッセージの最初の行にマッチし、終了パターンは、ＳＯＡＰメッセージの最後の行にマッチする。ネットワークインタフェースカード２が、このメッセージストリームをペイロードとして有するＴＣＰパケットを対向ネットワーク１０から受信すると、まず、パケット受信部２１が、受信ＴＣＰパケットのチェック及び、ＴＣＰのプロトコル処理を行う。その後、メッセージ再構築部２２に処理が渡る。
【００６８】
メッセージ再構築部２２は、今回受信したＴＣＰパケットとその前に受信したＴＣＰデータを参照してメッセージストリームを構築する。今回受信したＴＣＰパケットは、それより前に受信したパケットと結合されて、メッセージストリームとして、受信メッセージ保持部２３に格納される。
【００６９】
パターン検知部２４には、アプリケーションによって、あらかじめ登録されたアプリケーションデータの開始および終了のパターンが登録される。パターン検知対象であるメッセージストリーム（以下、検知対象メッセージストリームと称す）が受信メッセージ保持部２３に格納された時点において、その検知対象メッセージストリームより前に格納されたメッセージストリームについて、パターン検知中では無い場合は、内部パラーメータのパターン検知フラグはＯＦＦになっている。
【００７０】
パターン検知フラグがＯＦＦである場合、パターン検知部２４が、検知対象メッセージストリームについて、登録済みの開始パターンが存在するか否かを調べる。この場合、検知対象メッセージストリームについては、開始パターンが見つかるので、パターン適合中フラグがＯＮになる。その後、検知対象メッセージストリームについて、登録済みの終了パターンが存在するか否かを調べる。検知対象メッセージストリームについては、開始パターンよりも後ろの位置で終了パターンが検知されるので、ネットワークインタフェースカード２は、受信メッセージ保持部２３に保持された検知対象メッセージストリームの先頭から終了パターンまでのメッセージをプロトコル処理用データ記憶部５２に転送し、転送したメッセージに関する情報（コマンド）をネットワークインタフェースコマンド受信部５１に書き込む。
【００７１】
一方、ＣＰＵ３は、ネットワークインタフェースカード２から送られて来たメッセージを受信するため、read()システムコールを発行してデータ待ちの状態（待機状態）になっている。この待機状態において、ＣＰＵ３は、ネットワークインタフェースコマンド受信部５１をポーリングして、コマンドが到着しているかを調べる。このポーリング処理に代えて、ネットワークインタフェース２が、コマンドを転送後に、ＣＰＵ３に対して割り込み通知を行う形式を用いることも可能である。ポーリング処理の場合、主記憶部５にメッセージストリームが書き込まれた際に、ネットワークインタフェースコマンド受信部５１が更新されるので、ＣＰＵ３は、その更新に基づいてパケット受信を認識することができる。
【００７２】
ＣＰＵ３によるパケット受信認識がなされると、ＯＳは、ネットワークインタフェースコマンド受信部５１の情報に基づいて、ネットワークインタフェースカード２からプロトコル処理用データ記憶部５２に転送されたメッセージストリームが、パターン適合したものであるか否かを判断する。パターン適合したものである場合は、ＯＳは、プロトコル処理用データ記憶部５２に格納されたメッセージストリームをアプリケーションユーザ用データ記憶部５３にコピーする。パターン適合したものでは無い場合は、ＯＳは、システムコールの引数を参照し、プロトコル処理用データ記憶部５２に格納されたメッセージストリームのうちの、アプリケーションから要求を受けた長さのメッセージストリームを、アプリケーションユーザ用データ記憶部５３にコピーする。
【００７３】
アプリケーションユーザ用データ記憶部５３へのメッセージストリームのコピーが完了した後、ＯＳは、その旨をアプリケーションに通知する。アプリケーションは、ＯＳから通知を受けて、read()システムコールから返ったデータを参照することが出来る。
【００７４】
このようにして、アプリケーションのプロトコルコマンド境界を意識したメッセージ転送を行うことで、アプリケーション側のコマンド境界検索の処理負荷（ＣＰＵ負荷）が軽減される。
【実施例２】
【００７５】
ここでは、ＳＭＴＰに適用した場合の動作例について説明する。
【００７６】
ＳＭＴＰプロトコルは、改行単位でコマンドの送受信処理を行う。ここでは、アプリケーション処理サーバ１をＳＭＴＰ処理を行うメールサーバとし、クライアント側からは、以下の順でパケット１−６が送られてくるものとする。
[パケット１]
HELO [クライアント側のホストネーム]
[パケット２]
MAIL FROM:<送信者のメールアドレス >
[パケット３]
RCPT TO:<宛先のメールアドレス >
[パケット４]
DATA
[パケット５]
メールコンテンツ
[パケット６]
QUIT
上記のパケット１−６の例において、パケット５のメールコンテンツ以外は、全て改行コード区切りのＳＭＴＰコマンドである。通常、ＳＭＴＰコマンドは、ＰＳＨフラグが付属したまま送られるが、ＴＣＰの実装や、通過地点途中にＴＣＰを終端するプロクシ及びアプリケーションファイアウォールがあった場合、ＰＳＨフラグが消えてしまう場合がある。本実施例は、そのようなＰＳＨフラグの存在しないＳＭＴＰコマンドを受信し、改行単位でコマンド処理を行うプロトコル処理に効果を発揮する。
【００７７】
以下に、具体的な動作を説明する。ここでは、検知用パターンとして改行コード（<CR>+<LF>）が登録されているものとする。
【００７８】
ネットワークインタフェースカード２では、対向ネットワーク１０からＳＭＴＰコマンドの入ったＴＣＰデータを受信し、受信ＴＣＰデータからメッセージストリームを再構築して受信メッセージ保持部２３へ格納する。この処理は、基本的には実施例１における処理と同じである。
【００７９】
続いて、パターン検知部２４が、改行コードについて、受信メッセージ保持部２３に保持されているメッセージストリームを検索する。改行コードが見つかった場合は、受信メッセージ保持部２３に保持されているメッセージストリームの先頭から改行コードまでのメッセージが、ネットワークインタフェースカード２からプロトコル処理用データ記憶部５２へ転送される。メッセージストリーム転送後、ネットワークインタフェースカード２によって、転送メッセージストリームについての情報（コマンド）が主記憶部５上のネットワークインタフェースコマンド受信部５１に書き込まれる。
【００８０】
ＣＰＵ３は、ネットワークインタフェースコマンド受信部５１を参照してパケット受信を認識する。パケット受信認識がなされると、ＯＳが、プロトコル処理用データ記憶部５２に格納されたメッセージストリームをアプリケーションユーザ用データ記憶部５３へコピーし、その旨をアプリケーションに通知する。このようにして、改行区切りでアプリケーションに受信通知が行われる。
【００８１】
ＳＭＴＰの様な改行単位でコマンド処理される事が分かっているようなアプリケーションプロトコルにおいては、改行コードのみをパターン登録させることで、アプリケーション側では、改行コードの検索負荷を軽減することが可能となる。
【実施例３】
【００８２】
ここでは、ＳＩＰに適用した場合の動作例について説明する。
【００８３】
ＳＩＰプロトコルでは、ＳＩＰヘッダフィールドと、空行と、ＳＩＰボディとからなるＳＩＰメッセージを処理する。ネットワークインタフェースカード２には、以下の様な形式のＳＩＰメッセージがＳＩＰリクエストとして対向ネットワーク１０から送られてくる。
[ＳＩＰメッセージ]
INVITE sip:bob@biloxi.com SIP/2.0 
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bK776asdhds 
Max-Forwards: 70
To: Bob <sip:bob@biloxi.com>
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710@pc33.atlanta.com
CSeq: 314159 INVITE 
Contact: <sip:alice@pc33.atlanta.com> 
Content-Type: application/sdp 
Content-Length: 142 
(空行) 
(以下、送信データの詳細情報フィールド)
上記ＳＩＰメッセージにおいて、空行より前のフィールドがＳＩＰコマンド情報である。空行より後のフィールドには、送信するデータの詳細情報（例えば音声ファイルの圧縮Codec、サンプリングレート）などが続く。
【００８４】
ＳＩＰサーバは、クライアントからＳＩＰメッセージを受信した後、ＳＩＰメッセージの宛先が自分宛なのか別ホストなのかを判断する処理等を含むアプリケーション処理を行う。ここでは、アプリケーション処理サーバ１をＳＩＰサーバとする。
【００８５】
図７に、ＳＩＰサーバに搭載されるネットワークインタフェースカード２の動作フローを示す。この例では、検知用パターンとして、以下のパターンが登録されているものとする。
・開始パターン(行頭にINVITE文字列が入っているか？) "/^\INVITE/"
・終了パターン（空行 <CR>+<LF>+<CR>+<LF>） "/\r\n\r\n /"
ネットワークインタフェースカード２では、対向ネットワーク１０からＳＩＰメッセージの入ったＴＣＰデータを受信し、受信ＴＣＰデータからメッセージストリームを再構築して受信メッセージ保持部２３へ格納する。この処理は、基本的には実施例１における処理と同じである。
【００８６】
続いて、検知用パターンとして開始パターンおよび終了パターンがパターン検知部２４に登録されているか否かが判断される（図７のステップＡ７）。検知用パターンの登録がなされていない場合は、図７のＡ１６〜Ａ１８のステップが実行される。これらステップＡ１６〜Ａ１８は、図３に示したフローと同じステップである。
【００８７】
検知用パターンの登録がなされている場合は、パターン適合中フラグがＯＮになっているか否かが判断される。パターン適合中フラグがＯＦＦである場合は、パターン検知部２４が、受信メッセージ保持部２３に保持されたメッセージストリーム中に開始パターンにマッチする文字列があるかを調べる（図７のステップＡ９、Ａ１０）。メッセージストリームが上記のＳＩＰメッセージだった場合、最初の"INVITE sip:bob@biloxi.com SIP/2.0"の行が開始パターンにマッチする。
【００８８】
開始パターンのマッチが確認された後、パターン検知部２４は、パターン適合フラグをＯＮにし（図７のステップＡ１１）、図７のＡ１２−２のステップに移行する。開始パターンのマッチが確認されなかった場合は、ステップＡ１６〜Ａ１８が実行される。
【００８９】
ステップＡ８の判定で「Ｙｅｓ」になった場合、または、ステップＡ１１が実行された場合は、パターン検知部２４は、メッセージストリーム中に終了パターンにマッチする文字列があるかを調べる（図７のステップ１２−２、Ａ１３−２）。メッセージストリームが上記のＳＩＰメッセージだった場合、空行が終了パターンにマッチする。このパターンマッチング処理は、開始パターンより後ろで空行があるかを調べる処理である。
【００９０】
終了パターンのマッチが確認された後、パターン検知部２４は、受信メッセージ保持部２３に保持されているメッセージストリームの、先頭保持位置から空行までのデータ領域を、受信メッセージ保持部２３から主記憶部５のプロトコル処理用データ記憶部５２に転送させ、パターン適合中フラグをＯＦＦにする（図７のステップＡ１４−２）。
【００９１】
メッセージストリーム転送後、ネットワークインタフェースカード２によって、転送メッセージストリームについての情報（コマンド）が主記憶部５上のネットワークインタフェースコマンド受信部５１に書き込まれる（図７のステップＡ１５）。
【００９２】
ＣＰＵ３は、ネットワークインタフェースコマンド受信部５１を参照してパケット受信を認識する。パケット受信認識がなされると、ＯＳが、プロトコル処理用データ記憶部５２に格納されたメッセージストリームをアプリケーションユーザ用データ記憶部５３へコピーし、その旨をアプリケーションに通知する。このようにして、ＳＩＰコマンドのパターン区切りでアプリケーションに受信通知が行われる。
【００９３】
以上の動作により、アプリケーション側のＳＩＰコマンドのパターン区切りの検索負荷を軽減することが出来る。
【００９４】
以上説明した本発明のネットワーク通信システム（アプリケーション処理サーバ）において、アプリケーションやＯＳの動作およびネットワークインタフェース部の動作は、基本的には、プログラムによって実現することが可能である。ＣＰＵおよびネットワークインタフェース部は、プログラムに従ってそれぞれの動作に対応する処理を実行する。プログラムは、ＣＤ−ＲＯＭやＤＶＤなどの記録媒体によって提供されてもよい。
【００９５】
また、ユーザは、ネットワーク通信システム（アプリケーション処理サーバ）の入力装置（キーボードやマウスなど）を通じて、必要な情報を入力したり登録したりすることができる。具体的には、ユーザは、検知用パターンとして任意のパターンを登録することができる。また、ユーザは、パケット受信中に任意に検知用パターンを再登録することができる。
【図面の簡単な説明】
【００９６】
【図１】本発明の第１の実施形態であるアプリケーション処理サーバの構成を示すブロック図である。
【図２】図１に示すネットワークインタフェースカードの動作を説明するためのフローチャートである。
【図３】図１に示すネットワークインタフェースカードの動作を説明するためのフローチャートである。
【図４】図１に示すＣＰＵの動作を説明するためのフローチャートである。
【図５】本発明の第２の実施形態であるアプリケーション処理サーバの動作を説明するためのフローチャートである。
【図６】本発明の第３の実施形態であるアプリケーション処理サーバの構成を示すブロック図である。
【図７】本発明のネットワーク通信システムをＳＩＰサーバに適用した場合のネットワークインタフェースカードの動作を説明するためのフローチャートである。
【符号の説明】
【００９７】
１  アプリケーション処理サーバ
２  ネットワークインタフェースカード
３  ＣＰＵ
４  アクセス調停部
５  主記憶部
１０  対向ネットワーク
２１  パケット受信部
２２  メッセージ再構築部
２３  受信メッセージ保持部
２４  パターン検知部
５１  ネットワークインタフェースコマンド受信部
５２  プロトコル処理用データ記憶部
５３  アプリケーションユーザ用データ記憶部
【図１】
2008219252.tif 000003
【図２】
2008219252.tif 000004
【図３】
2008219252.tif 000005
【図４】
2008219252.tif 000006
【図５】
2008219252.tif 000007
【図６】
2008219252.tif 000008
【図７】
2008219252.tif 000009