(57)【特許請求の範囲】
【請求項１】
パケット伝送モードを使用してデータネットワーク(3)のストリームを監視するためのデータ収集装置であって、
送信機、受信機、およびプロトコルによって定義されるストリームに属するパケットに含まれるデータの抽出装置(11)と、
前記抽出装置からリアルタイムで前記データを受信し、
前記プロトコルの構文規則に従って、前記受信したデータを要素に分解し、前記構文規則が前記要素をツリー構造として表すことができるようにし、
それぞれのツリー状態インジケータを前記要素の少なくとも一部と関連付け、要素と関連付けられた前記ツリー状態インジケータが前記ツリー構造において前記要素をラベル付け、要素と関連付けられた前記ツリー状態インジケータが、ツリー構造表現において前記要素を受信するサイトがアタッチされる前記ツリー構造の親ノードの識別子を含む
ように構成された構文解析器(13)と、
前記ツリー状態インジケータが関連付けられた要素と共に、前記ツリー状態インジケータを、ストリーム解析器(7)に送信するためのインタフェース(15)と
を備える、装置。
【請求項２】
前記構文解析器(13)がさらに、
前記構文規則により、前記ツリー構造表現において、前記ツリー構造のノードに位置するサイトで現在の要素が受信されることが決定された場合、前記現在の要素にノード識別子を割り当て、
前記現在の要素と関連付けられた前記ツリー状態インジケータの中に前記現在の要素に割り当てられた前記ノード識別子を含む
ように構成された、請求項1に記載の装置。
【請求項３】
前記構文解析器(13)が、要素およびその関連ツリー状態インジケータの伝送後の所与のストリームに対して、前記ツリー構造表現において前記要素を受信する前記サイトから前記ツリー構造を上方へ移動するとき遭遇する各ノード識別子をメモリに格納するだけであるように構成された、請求項2に記載の装置。
【請求項４】
請求項1から3のいずれか一項に記載のデータ収集装置(1)と、伝送された要素を関連ツリー状態インジケータと共に受信するストリーム解析器(7)とを備える、パケット伝送モードを使用してデータネットワーク(3)のストリームを監視するためのシステム。
【請求項５】
前記ストリーム解析器(7)が、前記関連ツリー状態インジケータと共に前記伝送された要素から前記ツリー構造の少なくとも一部を構築するように構成された、請求項4に記載のシステム。
【請求項６】
パケット伝送モードを使用してデータネットワーク(3)のストリームを監視するための方法であって、
送信機、受信機、およびプロトコルによって定義されるストリームに属するパケットに含まれるデータを取り出すステップ(25)と、
ツリー構造に従って要素を表すことができるようにする、前記プロトコルの構文規則に従って、受信したデータをリアルタイムで前記要素に分解するステップ(27)と、
それぞれのツリー状態インジケータを前記要素の少なくとも一部と関連付けるステップ(29)であって、要素と関連付けられた前記ツリー状態インジケータが、前記ツリー構造において前記要素をラベル付けし、要素と関連付けられた前記ツリー状態インジケータが、ツリー構造表現において前記要素を受信するサイトがアタッチされる前記ツリー構造の親ノードの識別子を含むステップと、
前記ツリー状態インジケータが関連付けられた前記要素と共に、ストリーム解析器(7)に前記ツリー状態インジケータを送信するステップ(31)と
を含む、方法。
【請求項７】
前記構文規則に従って、前記ツリー構造表現において、前記ツリー構造の1つのノードに位置するサイトで現在の要素が受信されると決定された場合、前記現在の要素にノード識別子を割り当てるステップと、
前記現在の要素と関連付けられた前記ツリー状態インジケータの中に前記現在の要素に割り当てられた前記ノード識別子を含むステップと
をさらに含む、請求項6に記載の方法。
【請求項８】
要素およびその関連ツリー状態インジケータの伝送後の所与のストリームについて、前記ツリー構造表現において前記要素を受信する前記サイトから前記ツリー構造を上に移動するとき、遭遇する各ノード識別子以外は保持されない、請求項7に記載の方法。
【請求項９】
前記ストリーム解析器(7)のレベルで、前記関連付けられたツリー状態インジケータを有する伝送された要素から、前記ツリー構造の少なくとも一部を構築することをさらに含む、請求項6から8のいずれか一項に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、データネットワークの通信ストリームを監視するための技法に関する。
【背景技術】
【０００２】
インターネットのようなデータネットワークのデータストリームを監視する状況では、機器は、多数の送信機/受信機に加えて、使用するプロトコルの数および伝送するデータの量の増加に直面している。
【０００３】
現在、このようなストリームの監視を行うための2つのタイプの装置がある。第1のタイプの装置は、設定された期間の間に一連のパケットを収集し、その後、後続ステップにおいて、収集したパケットを解析および処理する。このタイプの装置の一例は、商標Wireshark、以前の商標Etherealの下で配布されるソフトウェアに基づいている。
【０００４】
第2のタイプの装置は、ハードウェア機構を使用してデータを取り込み、その後これを解析装置に送信する。取り込み装置と解析装置との間の情報の送信は、RFC 3917を参照してIETF(Internet Engineering Task Force)によって標準化されたIPFIXプロトコルに基づくことが多い。
【０００５】
「Incorporation of Application Layer Protocol Syntax into Anomaly Detection」、Information Systems Security, Springer、188〜202頁、2008年12月、において、P. Dussel他が、電気通信ネットワークにおける異常を検出するためのプロセスにアプリケーション層プロトコル構文を組み込むことについて記載している。「Bro」と呼ばれる侵入検知システムが、ネットワーク上のパケットを取り込み、「binpac」と呼ばれる構文解析言語(yacc)を使用して着信パケットをプロトコル解析器に送信するために、TCPセグメントを再び組み立てる。
【０００６】
本出願人は、インターネット型のネットワークを監視するための技術を開発した。詳細には、複雑なプロトコルスタックからストリーム、すなわち、送信機と受信機との間で伝送される構造化されたデータセットを抽出するために、複雑なプロトコルスタックをリアルタイムで調べることができるようにようにするマルチレベルのアーキテクチャについて記載する特許出願EP 1 722 509 Alおよび特許出願EP 1 722 508 Alを出願した。
【０００７】
データ収集レベルで処理される情報の量を考えると、後者は関連情報、およびその情報のみを解析器に伝送するために絶対的に不可欠である処理を実行することに限定されなければならない。
【０００８】
いくつかの解決法は、構造化された情報および関連情報の伝送を可能にする処理動作をデータ収集装置に搭載する。しかしながら、こうした解決法は、データ収集装置によってリアルタイムで検査される情報の量を考慮に入れた、高性能のハードウェアアーキテクチャの開発を必要とする。
【０００９】
他のタイプの解決法は、冗長なデータおよび/または不必要なデータなどを含む、構造化されていないデータをデータ収集装置に伝送させることによって、データ収集装置によって行われる処理を限定し、これが解析器およびそのデータ収集装置とのインタフェースのレベルでの他の制約につながっている。
【００１０】
別の可能性は、解析器のレベルで延期された処理を実行することからなる。やはり、これによりストリームの監視を行うアプリケーションの反応度が低下する。
【００１１】
したがって、これらのデータの取り込みおよび編集を処理するために必要とされるハードウェアリソースを制限しながら、構造化されたデータおよび関連データのみを解析器へ伝送することができるデータ収集技法を提案することが有利である。
【発明の概要】
【課題を解決するための手段】
【００１２】
本発明によれば、パケット伝送モードを使用するデータネットワークのストリームを監視するためにデータ収集装置が提案される。この装置は、
・  送信機、受信機、およびプロトコルによって定義されるストリームに属するパケットに含まれるデータの抽出装置と、
・  構文解析器であって、
- リアルタイムで抽出装置からデータを受信し、
- 要素をツリー構造として表すことを可能にする、上記プロトコル構文規則に従って、受信したデータを上記要素に解体し、
- それぞれのツリー状態インジケータを上記要素の少なくとも一部と関連付け、1つの要素と関連付けられたツリー状態インジケータが、ツリー構造において上記要素をラベル付けする
ように構成された構文解析器と、
・  ツリー状態インジケータが関連付けられた要素と共にツリー状態インジケータをストリーム解析器に送信するためのインタフェースと
を備える。
【００１３】
この装置の一実施形態では、ある要素と関連するツリー状態インジケータは、ツリー構造表現において上記要素を受信するサイトがアタッチされるツリー構造の親ノードの識別子を含む。構文解析器は、
- 構文規則に従って、ツリー構造表現において、ツリー構造のノードに位置するサイトで現在の要素が受信されると決定された場合、現在の要素にノード識別子を割り当て、
- 現在の要素に割り当てられたノード識別子を、上記現在の要素と関連するツリー状態インジケータの中に含む
ように構成することができる。
【００１４】
有利な実施形態では、構文解析器は、要素およびその関連するツリー状態インジケータを送信した後の所与のストリームに対して、ツリー構造表現において上記要素を受信するサイトからツリー構造を上方へ移動するときに遭遇する各ノード識別子のみを、メモリに含むように構成される。
【００１５】
本発明の別の態様は、パケット伝送モードを使用してデータネットワークのストリームを監視するためのシステムに関する。このシステムは、上記のように定義されるデータ収集装置と、伝送された要素を関連するツリー状態インジケータと共に受信するストリーム解析器とを含む。
【００１６】
本発明のさらに別の態様は、パケット伝送モードを使用してデータネットワークのストリームを監視するための方法に関する。この方法は、
・  送信機、受信機、およびプロトコルによって定義されるストリームに属するパケットに含まれるデータを取り出すステップと、
・  ツリー構造に従って要素を表すことができるようにする、上記プロトコル構文規則に従って、受信したデータをリアルタイムで上記要素に分解するステップと、
・  それぞれのツリー状態インジケータを、上記要素の少なくとも一部に関連付けることであって、要素と関連付けられるツリー状態インジケータは、ツリー構造において上記要素をラベル付けするステップと、
・  関連付けられた要素と共にツリー状態インジケータをストリーム解析器に送信するステップと
を含む。
【００１７】
この方法はさらに、ストリーム解析器のレベルで、関連するツリー状態インジケータを有する伝送された要素から、少なくともツリー構造の一部を構築するステップを含むことができる。
【００１８】
添付の図面を参照した、非限定的な実施形態の次の説明の中で、本発明の他の特徴および利点が明らかになるであろう。
【図面の簡単な説明】
【００１９】
【図１】本発明の一実施形態によるデータネットワークにおける監視システムの線図である。
【図２】図1の監視システムのデータ収集装置の機能図である。
【図３】図2の収集装置の動作のフローチャートである。
【図４】本発明の一実施形態によりHTTPリクエストを動的ツリーに分解することの説明のための例を示す図である。
【図５】電子メールプロトコルの場合の例示的ツリー構造を示す図である。
【発明を実施するための形態】
【００２０】
図1を参照すると、監視システムが、例えばIP(インターネットプロトコル)パケット型プロトコルを使用する、インターネットなどのデータネットワーク3に直接接続され、このネットワークを流れるパケットを取り込む、データ収集装置1を含んでいる。このデータ収集装置1は、例えば特許出願EP 1 722 509 Alまたは特許出願EP 1 722 508 Alに詳述されているアーキテクチャを使用する。このデータ収集装置は、データネットワーク3を流れるパケットから抽出された構造化されたデータを、データ接続5を介して解析器7に送信する。
【００２１】
データネットワーク3上の伝送は、従来から伝送プロトコルスタックを使用する。したがって、例えばウェブサイト検索の状況では、IPパケットがTCP(伝送制御プロトコル)プロトコルのデータ構造を含んでおり、これ自体がHTTP(Hypertext Transfer Protocol)データ構造を含んでいる。電子メールの状況では、TCPデータ構造は、SMTP(Simple Mail Transfer Protocol)データ構造などを含む。当該のストリームのタイプに従って、IPネットワーク通信の分野でよく知られている他の多くのアプリケーション層またはトランスポート層のプロトコルが使用される。
【００２２】
所与のストリームの状況で流れている情報は、単一IPパケットに含まれていることはまれである。逆に、この情報は、いくつかの連続パケットで送信されるように分割される。こうしたIPパケットは、ネットワーク全体にわたって流れ、パケットヘッダは、ルーティング情報、詳細にはパケットのソースおよび宛先のIPアドレスを含んでいる。他のストリームに属する他のパケットが、これらの間に挿入される場合がある。パケットは、ネットワーク内の異なるルートをたどる可能性がある、および/または、パケットが送信された順序とは異なる順序で受信される可能性がある。
【００２３】
所与のストリームを監視するために、当該のストリームに属しているパケットを識別すること、パケットから関連情報を抽出し、当該の監視アプリケーションの要求に従ってこれを解析することが好都合である。図1のアーキテクチャでは、監視アプリケーション自体が解析器7によって実行される間に、識別および抽出はデータ収集装置1によって提供される。
【００２４】
図2を参照すると、データ収集装置1は、トラフィックを観察するために、ネットワーク3のノードまたはリンクに接続されたデータ抽出装置11を含んでいる。データ抽出装置11は、抽出器が接続されたノードまたはリンクレベルでネットワーク3によって使用される下位プロトコル層に適合されたネットワークインタフェースを有する。データ抽出装置11は、特定のストリームに属しているパケットに含まれたデータを抽出し、ストリームは、送信者、受信者、およびプロトコル(例えば、電子メール用のSMTP、ウェブブラウジング用のHTTPなど)によって定義される。
【００２５】
データ収集装置1はさらに、所与のストリームの抽出装置11によって抽出されたデータをリアルタイムで受信する構文解析器13を含む。構文解析器13は、当該のストリームの関連プロトコル構文規則を組み込んでいるソフトウェアリソースを有する。構文解析器13は、ストリームから抽出されたデータを、ストリームのプロトコル構文に関して、イベントとも呼ばれる要素に分解する。このように取得された要素は、これらの要素をツリー状態インジケータと共に外部の解析器7に送信することを担うインタフェース15に提供される。
【００２６】
ストリームのデータを要素に分解することは、ツリー構造に従ってこれらの要素を表すことを可能にする、そのプロトコルに適用できる構文規則に従って、構文解析器13によって行われる。実際には、ツリー構造は、データ収集装置1のレベルでは完全に格納されていない。アプリケーションによって要求される場合、ツリー構造は、構造化データ解析器7によって再構成される。データ収集装置1は、単にツリー状態を格納し、そのインジケータは、構文解析器13によって行われた分解の結果として生じる要素と、それぞれ関連付けられる。
【００２７】
要素と関連付けられたツリー状態インジケータは、ツリー構造においてこの要素をラベル付けし、構造化データ解析器7が監視されるストリームの中でこの要素を見つけることができるようにする。
【００２８】
ツリーとは、ルートデータ項目と、子データとを含む、グラフ理論の意味におけるデータ構造を意味し、子データ項目は、単一の上位の親データ項目にのみリンクされる。子データ項目へのリンクを有するデータ項目は、ツリーノード(tree node)と呼ばれ、子データのないデータ項目は、ツリーの葉(leaf)と呼ばれる。したがってツリーは、ループのないグラフである。
【００２９】
データ収集装置1の一般的動作は、図3の図に示している。設定ステップ21では、抽出装置11に必要であるパラメータが抽出装置に提供され、詳細には、
- 監視されるストリームの関連送信機、受信機、およびプロトコル
- 抽出されるデータタイプの表示(すべてのデータ、一定のメッセージのみ、種々の設定可能条件に一致するデータなど)。簡単な設定では、ストリームのすべてのデータが抽出され、解析器7のレベルで任意のフィルタリングが行われる。一定のタイプのデータのみが抽出されるように指定することにより、オプションとして、収集装置1の負荷および接続5を通じて伝送される情報の量を削減することができる。
- 実際には、抽出装置11および解析器13はいくつかのストリームを1度に調べることができるので、当該のストリームを処理する構文解析器13のインスタンスを識別すること。
【００３０】
ステップ23では、抽出装置11は、パケットがネットワーク3を通じて伝送されるときパケットを検査する。このために、抽出装置11は、例えば特許出願WO 2004/017595 A2に記載される認識およびプロトコル解析方法を使用する。したがって抽出装置11は、ステップ25において、設定中に指定されたプロトコルに属し、指定された送信機から指定された受信機へ流れているデータを抽出すること、およびこうしたデータをリアルタイムで構文解析器13に送信することができる。
【００３１】
図3に示す分解ステップ27における構文解析器13の機能を説明するために、特定の場合について、所与の送信機と受信機との間のHTTPプロトコルに準拠したストリームを考える。この説明の例では、抽出装置11はパケットを解析し、2つの連続パケットから、ヘッダを削除した後にTable I(表1)に示す情報を抽出する。
【００３２】
【表１】
0005866348.tif 000002
【００３３】
この特定の場合では、完全なHTTPリクエスト、すなわち
GET /search?hl=fr&q=brevet HTTP/1.0\nHost: google.fr\n
は、ペイロードサイズの点で下位レベル(TCP層1、IP層2)のプロトコルによって課される制限を守りながら伝送可能であるように、2つのパケットに分割された。
【００３４】
意味論的には、このHTTPメッセージは、「GET」リクエストコマンドと、URI(Uniform Resource Identifier)とに分解される。URI自体は、意味論的に適切な要素またはイベントに分解される。これらの要素は、当該のプロトコル(ここではHTTP)に適切な構文規則に従ってパケットに収容されるデータに配置される。
【００３５】
例えば、パケットP1からのデータは、Table II(表2)に示すように分解することができる。
【００３６】
【表２】
0005866348.tif 000003
【００３７】
一方、パケットP2からのデータは、Table III(表3)に示すように分解することができる。
【００３８】
【表３】
0005866348.tif 000004
【００３９】
イベント1.1は、「GET」コマンドの検出に対応する。次に、構文解析器13は、パケットP1の残部は、URI資源識別子の部分を形成すると決定し、これが次のイベント1.2を構成する。このイベント「uri=/search?hl=fr&」自体は、不完全である可能性がある、パラメータのリストを明らかにするイベントに分解されなければならない。この新規の分解は、URIパラメータを宣言するイベント1.3を追加するためにツリー構造において1レベル下ることを意味する。次に、イベント1.4および1.5が、この第1のパラメータの名前および値を与える。パケットP2を受信すると、URI(イベント2.1)後に別のパラメータ(2.2)が続き、その名前および値はイベント2.3および2.4によって与えられることは明らかである。最終的に、この例では無視することができるHTTPプロトコルのバージョン番号の後に、最後のイベントが、問い合わせられるサーバ、ここでは「google.fr」に関連付けられる。
【００４０】
構文解析器13は、抽出器11によって提供された生データをイベントに変換するために、解析されたプロトコル構文に従って、ステップ27においてこのタイプの分解を実行する。各アプリケーションプロトコル(SMTP、SIP、RTPなど)は、例で示したHTTPプロトコル構文とは一般的に異なる各アプリケーション独自の構文を使用する。構文解析器は、異なるストリーム上の異なるプロトコルを解析できるようにするモジュール構成を有することができる。したがって、新しいプロトコルは、その構文用の特定のモジュールを開発することによって、構文解析器によって解析することができる。
【００４１】
詳細にはツリー構造に従って、ただし最小限の追加情報で、ストリームを再構成することができるように、外部の解析器7に十分なデータを送信することが望ましい。データ収集装置1がTable IIおよびTable III(表2および表3)の右側の列に示すイベントの内容のみを送信する場合、曖昧さが残る。例えば、解析器7はイベント1.2、2.1、または2.5がイベント1.1と同じリクエストに関するかどうかを知ることができない。下位プロトコル層から生じる情報(例えばTCPセグメントの連続番号など)を送信する必要もなくこうした曖昧さを回避するために、イベントの内容は、ステップ29において構文解析器13によって関連付けられたツリー状態インジケータと共に、構造化された形式でステップ31においてデータ収集装置によって送信される。
【００４２】
ツリー状態は、既に上述した例では図4に示すように決定することができる。図4では、左側の列は、ストリームから抽出されたパケットP1、P2を、Table IIおよびTable III(表2および表3)中に概要を示したもののような要素またはイベントに分解することを示す。図4の中央の列は、ステップ31においてそのそれぞれのツリー状態インジケータと共にデータ収集装置1によって外部の解析器7に送信されたイベントを示し、右側の列は、分析器7が監視されるストリームを表すツリーをそのように再構成できることを示す。この右側の部分では、太字は、収集装置1から要素が受信されたとき解析器7がツリーに追加する要素を示す。
【００４３】
ツリーは、解析されるストリームに対応するルートノードから始まり、イベントが受信されるとき解析器7によって構築されることが可能である。ルートノードは、図4では「http」で示され、例えばノード識別子(id)15C4が記載されている。この例では、ツリーは、パケットP1およびP2によって搬送されたリクエストの前に、既に2つの受信済みリクエストを有し、右側の列の上部に、2つの「request」ノードとして示しているが、その枝(branches)は、図の載せすぎを回避するために示していない。
【００４４】
当該のストリームの新規リクエストを示すイベント1.1を受信すると、ルート「http」をその親ノードとする新しい「request」ノードがツリーに追加される。これは、HTTPプロトコルのルールに従って、子データが存在することを構文解析器13が認識しているイベントであるので、構文解析器はこれにノード識別子、この例ではid = 38FAを割り当てる。ステップ29において構文解析器13によってイベント1.1と関連付けられるツリー状態インジケータは、この場合、これに割り当てたばかりのノード識別子38FAと、ツリーの中のその親ノードの識別子(p)、ここではp = 15C4を含む。
【００４５】
インジケータ(id = 38FA / p = 15C4)を有するイベント1.1を受信すると、解析器7は、ツリーに新しいノードを追加することができ、そこからその位置(ルートノード15C4の子)に関連した識別子38FAを格納する。
【００４６】
分解のステップ27から生じる次のイベント(2.2)では、ツリー状態インジケータもまた、ステップ29において割り当てられ、ツリーの中のその親ノードの識別子、この場合はp = 38FAを含む。構文解析器13は、このイベントがツリーの葉に対応すると判断することができるので、これにノード識別子を割り当てる必要がなく、したがってそのツリー状態インジケータは、現在のHTTPリクエストを示しているその親ノードの識別子p = 38FAに限ることができる。
【００４７】
第3のイベント1.3は、以下にURIのパラメータを含むことを宣言する。したがってこれは、「request」ノード(38FA)の子ノードと表すことができ、他の子ノードとのリンクを有することになる。結果として構文解析器13は、これに一意の識別子、例えばid = 8B53を割り当て、したがってその関連するツリー状態インジケータは(id = 8B53 / p = 38FA)である。
【００４８】
このURIパラメータの名前および値を付与する次のイベント(1.4、1.5)は、ノード8B53への葉の形でアタッチされる。これらのツリー状態インジケータは、単にp = 8B53であり、いずれの新しいノード識別子も指定しない。
【００４９】
パケットP2から抽出されたイベント2.1〜2.5については、図4の下部に示す、解析器7によるツリーの構成の論理は、まさに説明した論理と同様である。したがって収集装置1の構文解析器13は、出現するノードに対して実行中に新しい識別子を割り当て(ツリーの葉についてはそうする必要はない)、その親ノードの一意の識別子を含んでいるツリー状態インジケータを伝送される各イベントと関連付け、それ自体が下位を有するノードで表される場合、識別子は新規にこのノードに割り当てられる。
【００５０】
URIは、例ではパケットの分割に続くパケットP1で末尾が切り捨てられているが、イベント2.1が解析器7によって受信された後に完成されたことに注意されたい。後者は、実際には、前の葉、「uri=/search?hl=fr&」に従って、URIは末尾を切り捨てられ、タイプURI(2.1)の新規のイベントを受信すると、新しい葉を作成することによってではなく、対応する葉への連結によって進むことを確認することができる。解析器7によるこの処理は、データ収集装置1によるいかなる特別なシグナリングも必要としない。
【００５１】
ツリー状態インジケータを使用してツリーを構築するための全処理を、図4に示す。解析されるHTTPリクエストは、図4の右下に示すツリーの形態で表すことができる。
【００５２】
この伝送は有利には、ノード識別子を使用して伝送されるデータの構造、または文脈を保持しながら、情報の要求される項目のみを送信できるようにする。この伝送は、パケットが収集装置1によって受信されるとき行われ、必要であれば即座に解析器7が監視されるストリームを再構成できるようにする。
【００５３】
別の利点は、最も厳しい処理速度の要求にさらされているデータ収集装置1が、現在のイベントからルートに戻るとき、ツリーで見つけられるノードの識別子に対応する最小限の動的情報のみをメモリに格納すればよいということである。当該のプロトコル構文規則は、ストリームの継続を調べることによって、適切なノードとの連結を可能にする。ツリーの現在のイベントの「兄弟」ノードまたは「従兄弟」ノードに関連する情報の項目は、収集装置1によって格納される必要がない。
【００５４】
本発明による方法および装置は、単に具体的な用語で実施形態を説明するために触れたHTTPプロトコルに、決して限定されないことに注意されたい。
【００５５】
別の例を挙げると、SMTPのような電子メールアプリケーションのプロトコルを考えることができる。送信者と受信者との間のこのプロトコルのストリームは、連続的なメッセージ(図5のツリー説明図中の電子メール(email))を生じ、それぞれが件名(subject)と、電子メールアドレス(sender_email)およびオプションの別名(sender_alias)を有する送信者(sender)と、それぞれが電子メールアドレス(receiver_email)およびオプションの別名(receiver_alias)を有する1人または複数の受信者(receiver)と、メッセージの本文(message)と、オプションでは他のフィールド(緊急性、機密性、(1つまたは複数の)添付物など)とを有する。使用されるプロトコルの適切な構文規則を提供される場合、構文解析器1はこうした異なるフィールドにラベル付けすることができる。送信者のレベルで使用される分割により、これらは異なるIPパケットで送信されることが多い。
【００５６】
図5は、2人の受信者を有する簡単なメッセージの例を表すために、構造化データ解析器7によって構築することができるツリーの枝について詳しく説明する。破線で囲まれた要素は第1のパケットP1'から抽出され、一点鎖線で囲まれた要素は、第2のパケットP2'(メッセージの本文、添付物などの続きを含む1つまたは複数のさらなるパケットが後に続く可能性がある)から抽出されると仮定する。
【００５７】
この例では、分解ステップ27は、第1のパケットP1'に7つのイベント1.1〜1.7を、第2のパケットP2'に4つのイベント2.1〜2.4を生じる。ステップ29では、構文解析器13は、正常に検出されたノード(図5では楕円で表す)に識別子を割り当て、これらのノードならびに葉(矩形で表す)をそれぞれの親ノードにアタッチする。これらの識別子およびこれらの付加物(attachments)は、ツリー状態インジケータとして外部の解析器7に送信され、アプリケーションがそのように要求する場合、外部の識別子が図5に示すツリーの全部または一部を再構築する。
【００５８】
受信者のアドレスで終わる第1のパケットP1'を処理した後(イベント1.7)に、データ収集装置1の構文解析器13は、後続パケットが当該の受信者の仮名を含む可能性がある場合は、このイベントの親ノード(1.6)の識別子のみを、ストリームの次のパケットがメッセージの本文から始まる場合は、祖父ノード(1.1)の識別子を、新しいメッセージがストリームに現れる可能性がある場合は、日付、添付物もしくは他のもの、およびルートノードの識別子を、メモリに格納すればよいことに注意されたい。
【００５９】
ストリームで伝送されるデータをツリー構造として表し、ツリーに配置することができる要素の最小限の構造記述を送信する上記の方法は、当該のプロトコルの関連する構文規則の記述に基づいていかなるタイプのプロトコルにも適用できる。
【００６０】
本発明について、図面および先の記述の中で明らかにし、詳細に説明した。先の記述は例示と考えられ、例として提供され、本発明の範囲をこの記述のみに限定しないものでなければならない。数多くの実施形態の変形が考えられる。
【符号の説明】
【００６１】
1  データ収集装置
3  データネットワーク
5  接続
7  解析器
11  データ抽出装置
13  構文解析器
15  インタフェース
【図１】
0005866348.tif 000005
【図２】
0005866348.tif 000006
【図３】
0005866348.tif 000007
【図４】
0005866348.tif 000008
【図５】
0005866348.tif 000009