特許 5955943 ＩＰネットワーク上を移動するデータストリームからデータを抽出する方法および装置

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】5955943

(24)【登録日】2016年6月24日

(45)【発行日】2016年7月20日

(54)【発明の名称】ＩＰネットワーク上を移動するデータストリームからデータを抽出する方法および装置

(51)【国際特許分類】

   H04L 12/70 20130101AFI20160707BHJP

【ＦＩ】

   H04L12/70 100Z

【請求項の数】8

【全頁数】13

(21)【出願番号】特願2014-500449(P2014-500449)

(86)(22)【出願日】2012年3月21日

(65)【公表番号】特表2014-511073(P2014-511073A)

(43)【公表日】2014年5月1日

(86)【国際出願番号】FR2012050585

(87)【国際公開番号】WO2012131229

(87)【国際公開日】20121004

【審査請求日】2015年3月6日

(31)【優先権主張番号】1152475

(32)【優先日】2011年3月25日

(33)【優先権主張国】FR

(73)【特許権者】

【識別番号】512331142

【氏名又は名称】コスモス

(74)【代理人】

【識別番号】100108453

【弁理士】

【氏名又は名称】村山 靖彦

(74)【代理人】

【識別番号】100064908

【弁理士】

【氏名又は名称】志賀 正武

(74)【代理人】

【識別番号】100089037

【弁理士】

【氏名又は名称】渡邊 隆

(74)【代理人】

【識別番号】100110364

【弁理士】

【氏名又は名称】実広 信哉

(72)【発明者】

【氏名】ジェローム・アベラ

【審査官】 安藤 一道

(56)【参考文献】

【文献】 特開２００８−１９２１２２（ＪＰ，Ａ）

【文献】 特開２００９−１５２９５３（ＪＰ，Ａ）

【文献】 特開２０００−３０７６４３（ＪＰ，Ａ）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｈ０４Ｌ １２／７０

(57)【特許請求の範囲】

【請求項1】

IPネットワーク(1)上を流れるデータストリームからデータを抽出する方法であって、前記ストリームの前記データがアプリケーションレイヤプロトコルに従って編成され、前記方法が、
前記ストリームから抽出しようとする少なくとも1つのタイプのデータに従って構成される状態および遷移で状態機械(20)が構成される構成段階であって、状態間の前記遷移は、前記アプリケーションレイヤプロトコルに従って前記ストリームの前記データを編成するための規則に応じて定義されたそれぞれの条件によって起動され、少なくとも1つの状態(30、31)は、前記ストリームからの前記データ抽出のために選択される、構成段階と、
前記データストリームのリアルタイム解析段階と
を含み、前記リアルタイム解析段階が、
前記ネットワーク上を続けて流れるIPパケットに由来する前記ストリームの前記データを観測するステップ、
前記状態機械が現在の状態にあるときに、前記現在の状態からターゲット状態への遷移の起動条件が前記ストリームの前記観測されたデータによって満たされるかどうかを判定し、この起動条件が満たされたときに、前記状態機械を前記ターゲット状態に変更するステップ、
前記状態機械が前記構成段階において前記ストリームからの前記データ抽出のために選択された状態にあるときに、前記ストリームから前記データを抽出するステップ、および
前記状態機械が前記構成段階において非選択状態の状態にあるときに、前記ストリームの前記データを無視するステップを含み、
前記状態機械(20)の前記遷移の起動条件が、前記ストリームの前記データにそれぞれの語彙素が存在することを含み、前記データストリームの前記リアルタイム解析段階は、前記状態機械が現在の状態にあるときに、
Nが、前記現在の状態からの前記遷移に対応する前記語彙素の最大文字数である場合、バッファメモリ(26)に、IPパケットで観測された前記ストリームの前記データの終わりに位置する少なくともN-1文字を格納するステップ、および
前記ネットワーク上を続いて流れるIPパケットに由来する前記ストリームの次のデータを受信する際に、2つのパケット間で分割された語彙素の考えられる存在を検索するために、前記バッファメモリのコンテンツを、受信された前記データの直前に配置するステップをさらに含む、
方法。

【請求項2】

前記状態機械(20)の前記選択された状態は、前記ストリームから抽出された前記データが外部処理器(14)に直接転送される状態(30)を含む、請求項1に記載の方法。

【請求項3】

前記状態機械(20)の前記選択された状態が、前記ストリームから抽出された前記データが、バッファメモリ(27)に格納され、次いで前記状態機械が前記選択された状態を離れると外部処理器(14)に転送される状態(31)を含む、請求項1または2に記載の方法。

【請求項4】

前記状態機械(20)の前記選択された状態(31)で、前記ストリームから抽出された前記データを受信する前記バッファメモリ(27)のサイズが、構成可能な文字数に限定されている、請求項3に記載の方法。

【請求項5】

IPネットワーク(1)上を流れるデータストリームからデータを抽出する装置であって、前記ストリームの前記データがアプリケーションレイヤプロトコルに従って編成され、前記装置が、
前記ストリームから抽出しようとする少なくとも1つのタイプのデータに従って構成される状態および遷移を有する状態機械(20)であって、状態間の前記遷移は、前記アプリケーションレイヤプロトコルに従って前記ストリームの前記データを編成するための規則に応じて定義されたそれぞれの条件によって起動され、前記状態機械の少なくとも1つの状態(30、31)は、前記ストリームからの前記データ抽出のために選択される、状態機械と、
前記ネットワーク上を続いて流れるIPパケットに由来する前記ストリームの前記データをリアルタイムで受信する入力部(24)と、
前記状態機械が現在の状態にあるときに、前記現在の状態からターゲット状態への遷移の起動条件が前記入力部で受信された前記ストリームの前記データによって満たされるかどうかを判定し、前記起動条件が満たされたときに、前記状態機械を前記ターゲット状態に変更する、遷移検出器(21)とを備え、
前記ストリームの前記データは、前記状態機械が前記ストリームからの前記データ抽出のために選択された状態にあるときに、抽出され、前記状態機械が前記ストリームからの前記データ抽出のために選択されなかった状態にあるときに、無視され、
前記状態機械(20)の前記遷移の起動条件が、前記ストリームの前記データにそれぞれの語彙素が存在することを含み、前記遷移検出器(21)が、前記状態機械が現在の状態にあるときに、Nが、前記現在の状態からの前記遷移に対応する前記語彙素の最大文字数である場合、IPパケットで観測された前記ストリームの前記データの終わりに位置する少なくともN-1文字を受信するように制御されたバッファメモリ(26)と関連付けられ、前記遷移検出器が、前記ネットワーク(1)上を続いて流れるIPパケットに由来する前記ストリームの次のデータを受信する際に、2つのパケット間で分割された語彙素の考えられる存在を検索するために、前記バッファメモリのコンテンツを、受信された前記データの直前に配置することにより、構成される、
装置。

【請求項6】

前記状態機械(20)の前記選択された状態は、前記ストリームから抽出された前記データが外部処理器(14)に直接転送される状態(30)を含む、請求項5に記載の装置。

【請求項7】

前記状態機械(20)の前記選択された状態は、前記ストリームから抽出された前記データが、バッファメモリ(27)に格納され、次いで前記状態機械が前記選択された状態を離れると外部処理器(14)に転送される状態(31)を含む、請求項5または6に記載の装置。

【請求項8】

前記状態機械(20)の前記選択された状態(31)で、前記ストリームから抽出された前記データを受信する前記バッファメモリ(27)のサイズが、構成可能な文字数に限定されている、請求項7に記載の装置。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、通信ネットワーク上をIP(「インターネットプロトコル」)パケットで流れるデータストリームに関連する解析技法に関する。より詳細には、この場合、ネットワーク上を流れる膨大な量のデータを処理する必要なしに、リアルタイムで、1つまたは複数の指定されたカテゴリから、データを抽出できるようにする。

【背景技術】

【0002】

Wiresharkの名称で販売されているものなどのIPパケット解析器は、データを運ぶパケットのコンテンツのストリームから包括的な抽出を実行して、次に、それに対して、このコンテンツを構成する様々な要素のそれぞれを識別することを可能にする完全な解析を行う。この手法は、その解析のためにリアルタイムでストリームのすべてを抽出する必要があるので、複数のストリームをリアルタイムで観測するためにはうまく適合されていない。さらに、それに従ってストリームが構成されるプロトコルに変更が生じた場合、たとえ変更が軽微であったり、探索する情報に関連しないプロトコルの側面に関連したりする場合でも、解析器を修正する必要がある。

【先行技術文献】

【特許文献】

【0003】

【特許文献1】WO 2004/017595 A2

【特許文献2】WO 2006/120039 A1

【発明の概要】

【発明が解決しようとする課題】

【0004】

IPタイプのネットワーク上のデータストリームに存在する対象情報の効率的な抽出と共時的なマッピングを可能にする技法が必要とされている。

【課題を解決するための手段】

【0005】

ストリームのデータがアプリケーションレイヤプロトコル(OSIモデルのレイヤ7)に従って編成されている、IPネットワーク上を流れるデータストリームからデータを抽出する方法が提案される。このような文脈の中で、またアプリケーションレイヤの観点から、ストリームは、ネットワーク(IP)レイヤおよび/またはトランスポート(TCP、UDPなど)レイヤのプロセスによって、事実上ランダムな形で分断される。しかしながら、トラフィックがIPネットワーク上を超高速で流れることを考えれば、ストリームに含まれる特定のデータを処理のために抽出する能力を備えることが望ましい。この方法は、以下、すなわち、
- ストリームから抽出しようとする少なくとも1つのタイプのデータに従って構成される状態および遷移で状態機械が構成される構成段階であって、状態間の遷移は、アプリケーションレイヤプロトコルに従ってストリームのデータを編成するための規則に応じて定義されたそれぞれの条件によって起動され、少なくとも1つの状態は、ストリームからのデータの抽出のために選択される、構成段階と、
- データストリームのリアルタイム解析段階と
を含む。

【0006】

リアルタイム解析段階は、以下、すなわち、
・ ネットワーク上を続けて流れるIPパケットに由来するストリームのデータを観測するステップ、
・ 状態機械が現在の状態にあるときに、現在の状態からターゲット状態への遷移の起動条件がストリームの観測されたデータによって満たされるかどうかを判定し、さらにこの起動条件が満たされたときに、状態機械をターゲット状態に変更する、ステップ、
・ 状態機械が構成段階においてストリームからのデータの抽出のために選択された状態にあるときに、ストリームからデータを抽出するステップ、および
・ 状態機械が構成段階において選択されなかった状態にあるときに、ストリームのデータを無視するステップ
を含む。

【0007】

状態機械は、そのノードがプロトコルの文法の関連構造要素を示しているが、意味および包摂(subsumption)の有用な情報がストリームに現れたときに、その情報の抽出を可能にする。状態機械は、状態および遷移から構成される。遷移は、ある状態から別の状態への移動を可能にし、通常、データストリームの観測中、語彙素(lexeme)によって起動される。

【0008】

使用される状態機械はデータストリームに作用するが、そのデータストリームは、構文論が必ずしも完全には知られていない非常に変動しやすいコンテンツ(テキストまたはバイナリ)を有する場合があり、エラーを含む可能性があり、時間内のすべての瞬間で完全な状態で入手できるわけではない。

【0009】

ストリームのすべてを抽出する必要なしに、こうしたデータストリームへの作用を行うために、この方法では、ストリームのデータをリアルタイムで解析することで別々の遷移の起動を可能にする条件を検索する。遷移の起動、および2つの状態間に存在するデータは、別々に管理することができる。

【0010】

さらに、この方法は、データの断片化が存在するところで遷移の起動条件を検索するのに必要な、ストリームのその一部のみをバッファメモリに格納することを管理できるようにする。そのような一実施形態では、状態機械の遷移の起動条件は、ストリームのデータにそれぞれの語彙素が存在することを含み、データストリームのリアルタイム解析段階は、状態機械が現在の状態にあるときに、以下、すなわち、
・ Nが、現在の状態からの遷移に対応する語彙素の最大文字数である場合、バッファメモリに、IPパケットで観測されたストリームのデータの終わりに位置する少なくともN-1文字を格納するステップ、および
・ ネットワーク上を続いて流れるIPパケットに由来するストリームの次のデータを受信する際に、2つのパケット間で分割された語彙素の考えられる存在を検索するために、バッファメモリのコンテンツを、受信されたデータの直前に配置するステップ
を含む。

【0011】

構成段階で選択される状態機械の状態は、ストリームから抽出されたデータが外部処理器に直接転送される1つまたは複数の状態を含むことができる。

【0012】

状態機械の選択される状態は、ストリームから抽出されたデータが、バッファメモリに格納され、次いで状態機械がこの選択された状態を離れると外部処理器に転送される1つまたは複数の状態も含むことができる。状態機械のそのような選択された状態で、ストリームから抽出されたデータを受信するバッファメモリのサイズは、構成可能な文字数に限定されていることが好ましい。

【0013】

本発明の別の態様は、上記方法の実施に適した装置に関する。この装置は、以下、すなわち、
- アプリケーションレイヤプロトコルに従ってストリームのデータを編成するための規則に応じて定義されたそれぞれの条件によって状態間の遷移が起動される、ストリームから抽出しようとする少なくとも1つのタイプのデータに従って構成される状態および遷移を有する状態機械であって、状態機械の少なくとも1つの状態が、ストリームからのデータの抽出のために選択される状態機械と、
- ネットワーク上を続いて流れるIPパケットに由来するストリームのデータをリアルタイムで受信する入力部と、
- 状態機械が現在の状態にあるときに、現在の状態からターゲット状態への遷移の起動条件が入力部で受信されたストリームのデータによって満たされるかどうかを判定し、さらに前記起動条件が満たされたときに、状態機械をターゲット状態に変更する、遷移検出器と
を備える。ストリームのデータは、状態機械がストリームからのデータの抽出のために選択された状態にあるときに、抽出され、また状態機械がストリームからのデータの抽出のために選択されなかった状態にあるときに、無視される。

【0014】

本発明の他の機能および利点は、以下の添付の図面を参照して、非限定的な実施形態の以下の記述から明らかになるであろう。

【図面の簡単な説明】

【0015】

【図1】本発明を適用することができるIPネットワークの簡略図である。

【図2】本発明を実施するために図1のネットワークに接続することができる機器のブロック図である。

【図3】本発明によるデータ抽出装置の一例のブロック図である。

【図4】例証として示す特定のケースで使用することができる状態機械の線図である。

【発明を実施するための形態】

【0016】

図1を参照すると、インターネットなどのIPネットワーク1は、標準的な方式で様々なルーティング機器を備えており、ネットワークの内部にあるもの(2)もあれば、ユーザ終端装置3、ユーザコンピュータ装置4、ネットワーク事業者が加入者を管理するサーバ、他のネットワークへのゲートウェイなど、様々な装置を接続するために周辺部に位置するもの(3)もある。

【0017】

ルータ2とルータ3との間のリンクは、例えば、光ファイバ回線によって提供される超高速接続によって実現される。代表的なビットレート値は、数十ギガビット/秒である。

【0018】

こうした高速リンクによって実行される様々なデータストリーム内で、ある種のアプリケーションは、例えば、請求書作成、セキュリティ、QoSの管理などのための特定のデータを抽出する必要がある。

【0019】

このようにして抽出されるデータを受信する装置は、IPネットワーク1上を流れる、潜在的に膨大な量のデータにも対処できることが望ましい。この目的を達成するために、図2において示されているような機器10を使用できる。

【0020】

この機器10は典型的には、ルータ2とルータ3との間の高速リンクのうちの1つとインタフェースをとることができるように、ルータ2、ルータ3のレベルに取り付けられる。しかし、機器10は、エンドルータ3とゲートウェイまたはユーザ装置との間に位置するリンクにも取り付け可能であることが理解されよう。

【0021】

図2に示した機器10は、機器が取り付けられるリンクの物理レイヤおよび下位のプロトコルレイヤに適応するネットワークインタフェース11を備える。ネットワークインタフェース11によって認識されるトラフィックは、このトラフィックを構成する連続するIPパケットが属するデータストリームを識別することができる分類器12にかけられる。分類器12は、例えばWO 2004/017595 A2に記述されているような認識およびプロトコル解析技法を実施する。そのアーキテクチャは、WO 2006/120039 A1に記述されているように、任意選択で分散させることができる。

【0022】

トラフィック分類器12は、システム管理者によって指定された1つまたは複数のデータストリームから取り出されたIPパケットを、データ抽出装置13に選択的に提示するように構成されている。これらのストリームのそれぞれに対して、抽出器13は、関連データを、ユーザによって実施された構成に応じて選択し、それらをストリームから抽出し、さらに抽出されたデータに関する必要な処理(例えば、請求書作成のための処理、セキュリティまたはQoSアプリケーションのための処理など)を実行する外部処理器14に伝達する。この場合に照会されるユーザは、外部処理器14によって実行されるアプリケーションを管理するユーザである。このユーザを、抽出すべきデータストリームを指定するシステム管理者と集約することができる。別のサービス指向アーキテクチャにおいて、システム管理者が、データ抽出サービスを、様々なタイプの実行すべき処理を担当する何人かの人々に提供する場合、ユーザは、同様にシステム管理者から分離することができる。

【0023】

データ抽出器13は、図3によって示されているようなアーキテクチャを備えることができる。このアーキテクチャでは、ユーザが、人とマシンとの間の適切なインタフェース22を介して構成する、状態機械20および遷移検出器21が中心となる。構成段階で、ユーザは、インタフェース22を介して、状態機械20の状態および遷移、ならびに状態間の遷移の起動条件を定義する。インタフェース22は、構成作業でユーザを支援するために、プロトコルの文法の知識を組み込んでいることができる。

【0024】

データ抽出器13は、IPパケットに由来するストリームのデータをリアルタイムで受信する入力部24を有し、IPパケットはトラフィック分類器12によって入力部に提示される。インタフェース22を介して実施された構成に従ってこのストリームから抽出されたデータは、データ出力部25によって外部処理器14に伝達される。

【0025】

IPタイプのネットワークの場合、状態機械を使用すると、動作上の制約を受けることになる。実際、この場合、ストリームは断片化し、IPパケットに由来するそれぞれの断片のサイズは一様でない。この断片化は、プロトコルの文法において、いつでも起こりうる。次の2つのケースを考慮すべきである:
- 遷移の条件の起動に必要なデータが、あるパケットの終わりと次のパケットの始まりとの間で分割される場合がある。
- ある状態で処理されるべき有用なデータが、いくつかのパケットにわたって現れる場合があるのに対して、ユーザは、データが断片化された形で処理されないように要求する場合がある。

【0026】

これらの2つのケースを考慮するために、データ抽出器13は、2つのバッファメモリ26、27(実際には、これらのバッファ26、バッファ27は、単一のメモリプレーン内に製作することができる)を備える。

【0027】

バッファメモリ26は、遷移検出器21によって探索された語彙素が、入力部24で続けて受信された2つのIPパケット間で分割されていることが見つかった状況を管理する働きをする。状態機械20の所与の状態で、この状態から利用できる遷移の考えられる起動のため、いくつかの語彙素を探索することができる。Nがこれらの語彙素の最大文字数を意味する場合、状態機械がこの所与の状態であるときに受信された各IPパケットで受信されたデータストリームの最後のN-1文字をバッファメモリ26に書き込むことが、都合がよい。ストリームのデータを含む次のIPパケットを受信する際、遷移検出器21が、探索された語彙素のうちの1つの考えられる存在を観測できるように、バッファメモリ26のコンテンツが、入力部24で受信されたデータの最初の文字の直前に配置される。遷移検出器21とバッファメモリ26との連携は、探索された語彙素がIPレベルでのストリームの分断によって失われないようにする。バッファメモリ26は、任意選択で、N-1文字より若干多く含むことができるが、それでもそのサイズは、抽出しようとするデータのサイズより依然としてかなり少ないはずであることに留意されたい。

【0028】

状態機械20は、ストリームの文法構造に従って確立された状態のリストを備える。各状態は、遷移検出器21によって探索される遷移の起動条件が典型的には、データストリームで受信される語彙素が存在することである遷移のリストを含む。各状態はさらに、状態機械20がこの状態にある間に受信されるデータを処理する方法を示す手続きが関連付けられている。

【0029】

状態のそれぞれの遷移は、起動条件および関連付けられたターゲット状態、ならびに条件の動作を確実にするために解析に必要な最小データ長を指定する。起動条件は、状態および状態が依存する遷移に固有であり、以下の形態のうちの1つをとることができる:
- 例えばボイヤムーア検索アルゴリズムを使用することによる、所与の文字列の発見
- 探索木(プレフィックス木または順序木データ構造)を使用することによる、所与の文字列の発見
- ストリームにおける所与のバイト数の進行
- 前のケースの一般化である、ストリームにおける可変のバイト数の進行。このケースでは、ホップのサイズは、状態機械の記述には示されていないが、そこから遷移が存在することになる状態の入力部で付与される。
- 包括的な条件。実際には、この条件が、遷移の発見を可能にする機能を介して状態機械に通知され、これにより、上記のケースをすべて包含する、条件の一般化が行われる。

【0030】

条件は、一般に、入力部24で受信されたデータストリームの読取りの進行を受けて起動される。このように遷移が起動されると、次の状態への遷移を可能にする遷移の起動の前に存在するデータを利用することができる。ユーザが要求した構成に従って、2つの状態変化と状態変化との間に存在するデータには、以下のいずれかが行われる:
- 無視されること、または
- 処理の最初の状態と連結された機能に転送されること(この機能は、典型的には、出力部25を介して、直ちにデータを送信するものである。)、または
- バッファメモリ27に格納され、次いで処理の最初の状態と連結された機能に転送されること。(この機能は、典型的には、出力部25を介して、状態機械20が現在の状態を離れる瞬間にデータを送信するものである。バッファメモリ27は、文字数に関して最大サイズを有するように構成することができる。状態機械20は、この最大文字数がバッファメモリ27に蓄積されると、現在の状態を離れざるをえないようにすることができる。これにより、このバッファメモリのオーバーフローを回避することができる。)

【0031】

以下に、例証を使用して、本発明の実施の特定の例を、XML言語(「Extensible Markup Language」)に基づく、JabberすなわちXMPP(「Extensible Messaging and Presence Protocol」)として知られる、インスタントメッセージプロトコルの場合で示す。これらの例は、Jabber/XMPPプロトコルの他の拡張または他のプロトコルに容易に一般化することができる。

【0032】

パフォーマンス(テキストの解析に関する記憶空間および処理時間)ならびに堅牢性のために、Jabberプロトコルの文法は、すべては記述されない。抽出が望まれる情報の周辺の不変条件(invariant)を含むマーカのみが考慮される。

【0033】

実施例1においては、ユーザは、Jabberプロトコルで転送されるメッセージのコンテンツを抽出しようとする。

【0034】

実施例2においては、抽出が、Jabberプロトコルで転送される連絡先(eメールアドレス)に関連する。

【0035】

状態機械20は、これらの実施形態を実装するために、図4によって示される線図に従って構成可能である。データの抽出を実行するための状態機械20では、2つのタイプの状態がユーザによって選択されている。第1のタイプ(「NODE_BODY」と呼ばれる状態30)では、メッセージのコンテンツは、非常に容量が大きくなる可能性があるので、抽出装置13に記憶されない。第2のタイプ(「TR_CONTACT_ENTRY」と呼ばれる状態31)では、eメールアドレスは、外部処理器14に1回で転送されるように、バッファメモリ27に格納することができる。

【0036】

2つのケースでは、選択された状態でのデータ転送のコールバック手続きの間、抽出器13は、処理器14に、データを正しく解釈するために必要な意味および包摂の情報を付与する、現在の状態(NODE_BODYまたはTR_CONTACT_ENTRY)に関する情報を、抽出されたデータと共に提供する。

【0037】

「NODE_BASE」と呼ばれるノード32、すなわち状態機械20の最初の位置から、状態機械について記述するグラフの1つの分岐は、語彙素<messageを検出することでメッセージのコンテンツの始まりを検出し、一方で他の分岐は、語彙素:iq:rosterによって指定される信号データのみに存在する情報項目を検索する。

【0038】

図4に示す状態機械20の状態および遷移は、構成段階で、以下のように定義される。
{ノード:NODE_BASE,次のノード:NODE_MESSAGE,開始:"<message"},
{ノード:NODE_BASE,次のノード:NODE_CONTACT_LIST,開始:":iq:roster"},
{ノード:NODE_MESSAGE, 次のノード:NODE_BODY, 開始:"<body>"},
{ノード:NODE_BODY,次のノード:NODE_BASE,開始:"</body>"},
{ノード:NODE_CONTACT_LIST,次のノード:NODE_BASE,開始:"</query>"},
{ノード:NODE_CONTACT_LIST,次のノード:NODE_CONTACT_ENTRY,開始:"<item"},
{ノード:NODE_CONTACT_ENTRY,トランスノード:TR_CONTACT_ENTRY,開始:"jid='",終了:"'/>",フラグ:SM_TRUNCATE},
{ノード:NODE_CONTACT_ENTRY,次のノード:NODE_BASE,開始:"</query>"}
ここでは、
・ 「ノード」は、現在の状態の名前であり、
・ 「次のノード」は、遷移条件が起動されたときの次の状態の名前であり、
・ 「開始」は、この遷移を起動するためにストリーム内を検索するマーカを意味する。

【0039】

バッファメモリ27の記憶装置に連結された一時的な状態が状態機械によって使用される場合、2つの追加の情報項目が存在する。
・ 「トランスノード」(一時的ノード):高速遷移の一時的な状態の名前
・ 「終了」:高速遷移を離れるために探索されるマーカ
・ 「フラグ」:任意選択のマーカ。今回の場合、バッファメモリ27がいっぱいになるときに終了マーカが見つからない場合の、データの切捨てを示す

【実施例1】

【0040】

語彙素<messageの検出後、第1の分岐は、状態機械20を、抽出がまだ実行されていないNODE_MESSAGE(33)状態に導く。NODE_MESSAGE状態での語彙素<body>の検出は、次いで、状態機械20をNODE_BODY状態に導く。この状態30では、最初の状態32に直接戻る終了マーカ</body>が検出されるまで、コールバックが、連続するIPパケットから受信されたデータをすべて出力部25に送信する。

【0041】

そうして、データ抽出器13は、プロトコルで定義されているXMLタグ<body>と</body>との間に含まれた、ストリームのメッセージの任意のコンテンツを分離する。メッセージのコンテンツは、容量が大きくなる可能性があるので、バッファメモリ27を通過しない。コンテンツは、IPパケットの連続する受信の中で、1回でまたは複数回で転送される。

【0042】

アプリケーションストリームは、例えば、以下のように提示される場合がある。
<message xmlns="jabber:client" type="chat" to="[e-mail]" id="aac3a">
<body>Bonjour Eric</body>
<active xmlns="http://jabber.org/protocol/chatstates"/>
<nick xmlns="http://jabber.org/protocol/nick">sir swiss</nick>
</message>

【0043】

抽出器13は、その結果、メッセージの本文「Bonjour Eric」を外部処理器14に提供する。

【0044】

開始マーカが、例えば以下のように、2つのIPパケットに分断されることが起こりうる。
A. <message xmlns="jabber:client"type="chat"to="[e-mail]" id="aac3a"><b
B. ody>Bonjour Eric</body><active xmlns="http://jabber.org/protocol/chatstates"/><nick xmlns="http://jabber.org/protocol/nick">sir swiss</nick>

【0045】

状態機械20がパケットAの終わりにあるNODE_MESSAGE状態では、最長語彙素の長さ(<body>=6文字)が遷移を起動し、1文字(1バイト)短い、すなわち5文字がバッファメモリ26に格納される。パケットAの終わりで、この場合、メモリ26は「a"><b」を包含する。パケットBを受信する際、「<b」および「ody>」の文字列が再組み立てされ、メッセージが、パケット2で完全であるように1回で転送される。ストリームの残りは、抽出器13によって無視される。

【0046】

メッセージのコンテンツが、例えば以下のように、いくつかのIPパケットに分断されることも起こりうる。
C. <message xmlns="jabber:client" type="chat" to="[e-mail]" id="aac3a"><body>Bonjour
D. Eric</body><active xmlns="http://jabber.org/protocol/chatstates"/><nick xmlns="http://jabber.org/protocol/nick">sir swiss</nick></message>

【0047】

状態機械20がパケットCの終わりにあるNODE_BODY状態では、最長語彙素の長さ(</body>=7文字)が遷移を起動し、1文字短い、すなわち6文字がバッファメモリ26に格納される。このパケットCを受信する際、「B」のみが処理器14に転送され、「onjour」はメモリ26に収容される。パケットDを受信する際、終了マーカ</body>が検出され、これにより、メモリ26のデータ、および終了マーカの前に位置する新しいパケットのデータ、すなわち全体で「onjour Eric」が、出力部25に送信される。処理器14は、次いで、抽出器13から続けて受信された「B」および「onjour Eric」の文字列の再組立てを実行することができる。

【0048】

終了マーカ</body>が、例えば以下のように、2つのIPパケットに分断されることも起こりうる。
E. <message xmlns="jabber:client" type="chat" to="[e-mail]" id="aac3a"><body>Bonjour Eric</bo
F. dy><active xmlns="http://jabber.org/protocol/chatstates"/><nick xmlns="http://jabber.org/protocol/nick">sir swiss</nick></message>

【0049】

状態機械20がパケットEの終わりにある状態NODE_BODYでは、6文字が、各IPパケットの終わりでバッファメモリ26に格納される。パケットEの終わりで、この場合、メモリ26は「ic</bo」を包含する。このパケットEの受信中、「Bonjour Er」のみが処理器14に転送される。パケットFを受信する際、終了マーカ</body>が再組み立てされて検出され、これにより、検出されたマーカと一致するデータを除くメモリ26のデータ、すなわち「ic」が、出力部25に送信される。

【0050】

本明細書で述べた、2つのパケットC、DまたはE、Fに対する方法は、データストリームのどの分割にとっても一般的なものである。メッセージの本文のサイズよりも小さいいくつかのパケットが続けて受信された場合、現在の状態30からの最大の遷移を検索することを可能にするために、それらのパケットは、受信される限り、ストリームの次のパケットを受信するまで、バッファメモリ26に保持された最後の6文字を除いて転送される。

【実施例2】

【0051】

語彙素:iq:rosterの検出後、図4のグラフの第2の分岐は、状態機械20を、抽出がまだ実行されていないNODE_CONTACT_LIST状態(34)に導く。語彙素<itemがNODE_CONTACT_LIST状態のストリームで検出された場合、状態機械20は、同じく抽出がまだ実行されていないNODE_CONTACT_ENTRY状態(35)に移動する。遷移検出器21は次いで、TR_CONTACT_ENTRY状態に移動するために、語彙素jid='をストリームで観測しなければならない。この状態31では、入力部24で受信されたストリームのコンテンツが、NODE_CONTACT_ENTRY状態35への再送信のための終了マーカ'/>が検出されるまで、バッファメモリ27に書き込まれる。語彙素</queryが状態34または状態35(NODE_CONTACT_LISTまたはNODE_CONTACT_ENTRY)のストリームで検出された場合、状態機械20は、ベースの状態32に戻る。TR_CONTACT_ENTRY状態への遷移は、状態機械20が、開始マーカjid='と終了マーカ'/>の2つのマーカ間のコンテンツをバッファメモリに格納する要件のためだけにこの状態31にとどまることができることから、高速遷移と呼ばれる。終了マーカ'/>が検出されると、状態機械20は、状態NODE_CONTACT_ENTRYに戻る。遷移検出器21は、この場合、信号の終わりのマーカ</queryが検出されるまで、連絡先のeメールアドレスを読み取り続ける。

【0052】

その結果、データ抽出器13は、XMLトークン<item>内で、属性jidのコンテンツ、すなわちjid='と'/>との間に含まれるテキストを検索する。メールアドレスは本質的には比較的小さいので、それがいくつかのパケットに分断される場合、1回で転送することが要求される場合がある。状態機械は、終了マーカ'/>を受信するまで、任意選択でコンテンツをバッファメモリ27に置かなければならない。

【0053】

アプリケーションストリームは、例えば、以下のように提示される場合がある。
<iq from='[e-mail]/dev1' type='result' id='aab6a'>
<query xmlns='jabber:iq:roster'>
<item subscription='both' jid='[e-mail]'/>
<item subscription='both' name='babydaisy' jid='[e-mail]'/>
<item subscription='to' jid='[e-mail]'/>
<item subscription='to' jid='[e-mail]'/>
</query></iq>

【0054】

eメールアドレスが断片化されていないと、開始マーカjid='と終了マーカ'/>の2つがストリームの同じパケットに存在するので、アドレスの抽出および処理器14への転送が、バッファメモリ27を使用することなしに、1回で実施される。

【0055】

開始マーカjid='が2つのIPパケット間で分断されている場合、その手続きは、実施例1と同じであり、第1の遷移の長さの1バイト短いものをバッファメモリ26に書き込む。第2のパケットを受信する際、一時的なTR_CONTACT_ENTRY状態に入るために、マーカjid='が再構成され、遷移が起動される。

【0056】

eメールアドレスは、例えば以下のように、2つのIPパケット間で分断される可能性がある。
G. <iq from='[e-mail]/dev1' type='result' id='aab6a'><query xmlns='jabber:iq:roster'><item subscription='both' jid='qosmojab@im
H. .apinc.org'/><item subscription='both' name='babydaisy' jid='[e-mail]'/><item subscription='to' jid='[e-mail]'/><item subscription='to' jid='[e-mail]'/></query></iq>

【0057】

マーカjid='の遷移が起動すると、状態機械20は、終了の遷移'/>までバッファメモリ27にデータが書き込まれる一時的なTR_CONTACT_ENTRY状態に入る。このバッファメモリ27は、サイズが限られているので、その最大値は、例えば、50バイト(構成可能)に、探索される終了マーカ'/>のサイズを加えたもの(すなわち、全体で53バイト)である。パケットGでは、文字列「qosmojab@im」がメモリに格納される。次いで、パケットHでは、先に計算した最大サイズに達するまで、このメモリ27にデータが追加される。終了マーカ'/>が見つかると、メモリ27に書き込まれたデータはすべて出力部25に転送され、状態機械20は、状態35のNODE_CONTACT_ENTRYに戻るために、TR_CONTACT_ENTRY状態を離れる。

【0058】

終了マーカが見つからないと、2つの可能性があり、その選択は、構成中に、遷移のオプションを使用して行われる。一般的なケースでは、最も古い格納データを、ストリームで読み取られるデータに置き換えることにより、終了マーカ'/>の検索を継続する。この場合、マーカが見つかったときに転送されるデータは、マーカより前の50バイトである。もう一方の可能性は、格納しうる最大サイズでデータを切り捨てることと、状態の変更を要求するために終了の遷移を起動することからなる(SM_TRUNCATEオプション)。

【0059】

上述の実施形態は、本発明の例証である。この実施形態に対する様々な修正形態が、添付の特許請求の範囲から明らかである本発明の範囲から逸脱することなく、実現されうる。

【符号の説明】

【0060】

10 機器
11 ネットワークインタフェース
12 分類器、トラフィック分類器
13 データ抽出装置、抽出器、データ抽出器、抽出装置
14 外部処理器、処理器
20 状態機械
21 遷移検出器
22 インタフェース
24 入力部
25 データ出力部、出力部
26 バッファメモリ、メモリ
27 バッファメモリ、メモリ
30 状態
31 状態
32 ノード、状態
33 状態
34 状態
35 状態

【図1】

【図2】

【図3】

【図4】