JP2006033829A - ポーティング可能な分散アプリケーションフレームワーク - Google Patents

Abstract

【課題】外部の定義ファイルに基づいて、アプリケーションとインタフェイスする汎用のフレームワークを提供する。
【解決手段】本発明は、様々なアプリケーションとインタフェイスすると共にそれらを制御するべく容易に適合可能なポーティング可能な分散アプリケーションフレームワークに関するものである。一般に、このフレームワークは、アプリケーションとインタフェイスするハウジングと、１つ又は複数のクライアントインタフェイスメカニズム（ＧＵＩなど）とインタフェイスするプロキシと、プロキシとハウジング間における通信を円滑に実行するコントローラと、を有している。これらのハウジング、プロキシ、及びコントローラのそれぞれは、同一の記述ファイルを使用して設定されている。この記述ファイルには、アプリケーションとインタフェイスしてこれを制御するべくフレームワークが使用するデータ構造及び命令の記述が含まれている。
【選択図】図３

Description

本発明は、ネットワークシステムの試験デバイスに関する。

ルーターなどのネットワークデバイスは、誤伝送や致命的な誤りを極小化するべく集中的に試験される。市場においては、本出願の譲受人であるアジレント・テクノロジーズ（ＡＧＩＬＥＮＴ ＴＥＣＨＮＯＬＯＧＩＥＳ）社のＲＯＵＴＥＲ ＴＥＳＴＥＲを含む様々な試験デバイスを入手可能である。これらの試験デバイスは、通常、様々な模擬入力に対するルーターの応答を監視する。

ルーティングプロセスとは、一言でいえば、ノードがすべての可能な宛先に対する経路を見出すことであると要約可能である。ルーティングは、レイヤ１（物理レイヤ）から上位のすべてのレイヤに存在している。但し、大部分の人々が慣れ親しんでいるルーティングは、レイヤ３（ネットワークレイヤ）において実行されるものであり、従って、本明細書においても、レイヤ３の（並びに、更に具体的には）ＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）ルーティングのみを指すものとする。ルーターは、テーブルを使用し、パケットを転送する場所を判定する。これらのテーブルの更新は、ルーティングプロトコルによって実行される機能の１つである。それぞれのルーターは、１つ又は複数のプロトコルに応答して動作する。

ルーティング情報を交換するプロトコルにより、世界中の複数のルーターが接続され、それらの異質ではあるが一般的に一貫性を有しているルーティングテーブルによって、ネットワークの共通的なビューがそれらのルーターに提供される。ルーティングテーブルには、そのサイズとは無関係に、そのネットワーク上のすべての宛先に到達するためにルーターが必要とするすべての情報が保存されている。ネットワークのルーティングテーブルに寄与するべく使用されるルーティングプロトコルには、様々なものが存在している。ＢＧＰ、ＯＳＰＦ、ＲＩＰ、及びＩＳＩＳなどのプロトコルは、ネットワークの正しく且つ首尾一貫した構造をそのネットワーク上のすべてのルーターに対して伝達するのに有用である。

既存のルーターテスタにおいては、ネットワーク上に存在するライブデータの特色を示す特別に生成されたデータの「試験パケット」を使用してネットワークトラフィックをシミュレートしている。これらの試験パケットは、被検ネットワーク上においてネットワークデバイスに伝送される。トラフィックシミュレータシステム（これには、ＲＯＵＴＥＲ ＴＥＳＴＥＲが含まれる）によって試験されるパラメータには、ルーティングの検証、負荷下におけるＱｏＳ（Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ）レベルの達成状況、及びその他のデバイスとの適正な連携が含まれる。又、これらの所謂「パケットブラスタ（Ｐａｃｋｅｔ ｂｌａｓｔｅｒ）」の多くは、プロトコルに従ってデータを生成及び伝送することにより、そのプロトコルをそのネットワークデバイスが遵守する能力をも試験する。

図１は、トラフィックシミュレータ試験システム１００のブロックダイアグラムである。具体的には、このトライフィックシミュレータ試験システム１００は、アジレント・テクノロジーズ社が販売しているＲＯＵＴＥＲ ＴＥＳＴＥＲの概略的な表現になっている。ＲＯＵＴＥＲ ＴＥＳＴＥＲは、ルーター試験システムの一例であり、具体的には、エンタープライズ、メトロ／エッジ、コアルーティング、及び光学ネットワーキングデバイスの性能を検証するためのマルチポートトラフィック生成、プロトコルエミュレーション、及び分析試験システムとして宣伝されている。このシステムは、一般に、被検システム（これは、この場合には、ルーター１０４である）に接続された複数のプロトコルエミュレーションカード１０２ｎを有している。そして、これらのプロトコルエミュレーションカード１０２ｎのそれぞれは、一般に、関連するメモリ及びＩ／Ｏを具備するプロセッサを有している。これらのプロトコルエミュレーションカード１０２ｎは、ＷＩＮＤＯＷＳ環境が稼働するＰＣなどのコンピュータ１０６によって制御されている。そして、このコンピュータ１０６は、グラフィカルユーザーインタフェイスなどのインタフェイス１０８に応答して動作する。

プロトコルエミュレーションカード１０２ｎによって生成される試験パケットは、産業界の多くの規格団体によって定義されているものなどの通信プロトコルの規則及び解釈に従って構築される。使用されている通信プロトコルには、多くのものが存在しており、新しいプロトコルも継続的に開発されている。通常、新規のプロトコルは、当初、機器製造者によって開発され、その特性は、プロプライエタリ（proprietary、所有権を主張できる）である。そして、その後、多くの場合に、それらのプロトコルは、規格団体によって認可され、産業界において広範に実装されることになる。プロトコルエミュレーションカード１０２ｎは、プロトコル状態機械（protocol state machine）を使用して、対象のプロトコルに従って伝送用のデータを生成する。この状態機械の動作は、ルーター自体において使用されている状態機械と類似している。

トラフィックシミュレータ試験システムに関連する現在のソフトウェアアーキテクチャにおいては、グラフィカルユーザーインタフェイス、スクリプティングＡＰＩ、設定及び制御コンポーネント、並びにプロトコル状態機械自体を含むプロトコルエミュレーションソリューションのすべての部分をハードコーディングする必要がある。そして、このそれぞれのプロトコルに必要なハードコーディングのために、結果的に、大量のコードの生成に膨大な量の人的能力が使用されているのである。このコードの多くの部分は、コンピュータ１０６を、それぞれの新しいプロトコルエミュレーションカード１０２ｎとインタフェイスさせるために費やされている。

コンピュータ１０６をそれぞれの新しいプロトコルエミュレーションカード１０２ｎとインタフェイスさせる従来の方法においては、インタフェイスを作成しインタフェイス記述言語（Ｉｎｔｅｒｆａｃｅ Ｄｅｓｃｒｉｐｔｉｏｎ Ｌａｎｇｕａｇｅ：ＩＤＬ）によってハードコーディングする時点で、方法と関連パラメータが判明していることが必要である。そして、このような状況下において、新しいプロトコルエミュレーションが作成され、または古いプロトコルが拡張されるたびに、毎回、新しい方法及びパラメータが継続的に生成され、この結果、数百もの方法及びパラメータを含む巨大なＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）が生成され、結果的に、保守に費用を所要するコードの集合体が生成されているのである。又、既存の方法によれば、結果的に、ＡＰＩがいくつかの異なるレイヤにおいて複製されることになり、この結果、これらの問題が更に悪化することになる。即ち、ＡＰＩに対する個々の変更により、（それがどれほど小さなものであったとしても）システム内における大量のコード及び異なるレベルの更新が必要となるのである。又、この方法の副作用の１つは、それぞれのプロトコル及びそのそれぞれの更新ごとに、固有のＧＵＩ（Ｇｒａｐｈｉｃａｌ Ｕｓｅｒ Ｉｎｅｒｆａｃｅ）を生成しなければならないことである。即ち、ＡＰＩと同様に、プロトコルの数が増大するに伴って、必要なＧＵＩの実装も増大することになるのである。

上述の問題のいくつかを軽減する汎用システムを設計するべく、現在、努力が傾注されている。その一例が、「Ｂｕｉｌｄｉｎｇ ｐａｃｋｅｔｓ ｏｆ ｄａｔａ」という名称の同時係属中の特許文献１に記述されている。この特許文献１（この内容は、本引用により、本明細書に包含される）においては、外部のプロトコルエミュレーション記述を使用し、汎用のＰＤＵ（Ｐｒｏｔｏｃｏｌ Ｄａｔａ Ｕｎｉｔ）エンコード／デコードエンジンを駆動している。従って、次のステップは、それぞれの新しいエミュレータ又はそれらの変更のたびに、新しいコード又はハードコーディングされたインタフェイスの変更を必要としないプロトコルエミュレータに対する汎用インタフェイスの構築である。

これに対する１つのアプローチは、プロトコルを制御するためのプロプライエタリなコンパイル済みの言語を開発する方法である。言語ステートメントを作成してホストコンピュータ上においてコンパイルし、この結果生成されるオブジェクトファイルを組み込み型ソフトウェアモジュールに配布して実行するのである。しかしながら、この方法によれば、開発されるそれぞれのプロトコルごとに、新しい言語ステートメントが必要となる。そして、これには、コンパイラの継続的な再作業が必要であり、これは、その特性が複雑であって、高度な技術を必要とする作業である。又、大規模な継続作業として、それぞれのプロトコルごとに、ＧＵＩの開発も残されることになる。

更なるアプローチは、従来どおりの非汎用的なアプリケーションフレームワークを開発する方法である。しかしながら、この方法においては、固定された所定のＡＰＩの内部にプロトコルエミュレーションを構築するが必要となり、それぞれのプロトコルごとに、データ構造即ち、フレームワークを大幅にカスタマイズしなければならない。現実世界のプロトコルにおける経験によれば、これは、大規模なカスタマイズが必要であることを示すものであり、この方法は、結果的に満足のいくものではない。
米国特許出願第１０／２６６，５０７号明細書

このようなことから、本発明者らは、フレームワークの外部に位置する定義ファイルに基づいて、アプリケーションとインタフェイスする汎用のフレームワークに対するニーズを認識するに至った。このフレームワークを異なるアプリケーションに適合させる際に必要とされるのは、フレーム自体の作り直しではなく、新しい定義ファイルの生成のみである。そして、プロトコル状態機械の場合には、このようなフレームワークにより、すべてのプロトコルエミュレーションをサポートする能力を有する汎用のＧＵＩを含む複数のインタフェイス、汎用的な制御及び命令ホストコンポーネント、及び組み込み型デバイス上における汎用プロトコルハウジング（generic protocol housing）の使用が実現することになる。

本発明は、様々なアプリケーションとインタフェイスすると共にそれらを制御するべく容易に適合可能なポーティング可能な（portable、移植性のある）分散アプリケーションフレームワークに関するものである。一般に、このフレームワークは、アプリケーションとインタフェイスするハウジング（housing）と、１つ又は複数のクライアントインタフェイスメカニズム（ＧＵＩなど）とインタフェイスするプロキシと、プロキシとハウジング間における通信を円滑に実行するコントローラと、を有している。これらのハウジング、プロキシ、及びコントローラのそれぞれは、同一の（又は、恐らくその複写である）記述ファイルを使用して設定されている。この記述ファイルには、アプリケーションとインタフェイスしてこれを制御するべくフレームワークが使用するデータ構造及び命令の記述が含まれている。

添付の図面との関連で、本発明の特定の実施例に関する以下の詳細な説明を参照することにより、本発明について十分に理解することができよう。

尚、以下の説明においては、要素識別子に隣接して使用されている小文字の「ｎ」は、要素番号に隣接した非イタリック体の文字を有する図面に示されている（又は、本明細書に記述されている）特定の要素ではなく、要素のグループ内における要素の非特定の例を表すものである。共通要素識別子を共有する要素のグループの場合には、隣接する文字を伴わないそのような要素識別子の使用は、その要素のグループ全体を示している。

次に、本発明の実施例を参照するが、それらの例は、添付の図面に示されており、これらの図面においては、類似の参照符号によってすべて類似の要素を示している。以下の詳細な説明においては、コンピュータ読取り可能媒体、関連プロセッサ、データ生成及び取得カード、並びにこれらに類似するものにおいて、ルーチン及びデータビット操作のシンボル表現によって実施可能な方法を提示している。尚、本明細書においては（並びに、一般的には）、ルーチンとは、所望の結果をもたらすステップ又は動作のシーケンスであると考えられ、従って、これには、「プログラム」、「オブジェクト」、「関数」、「サブルーチン」、及び「手順」などの専門用語が含まれている。これらの記述及び表現は、当業者が自らの研究の内容をその他の当業者に効果的に伝達するべく使用する手段である。又、わかりやすくするべく、本明細書及び請求項においては、「ネットワーク」という用語は、通信ネットワーク、ネットワークデバイス、その他の通信デバイス、並びに、データの試験パケットを使用して試験可能な通信システムの１つ又は複数の側面の中の１つ又は複数のものを意味するべく使用されている。

又、ＡＧＩＬＥＮＴ ＲＯＵＴＥＲ ＴＥＳＴＥＲに類似した構成を具備するルーターテスタ上における実装を参照し、方法の実施例について説明するが、本明細書に開示する方法は、様々なルーターテスタの中のいずれのものにおいても動作可能である。より端的には、本明細書に開示されている方法は、特定のデバイスに関係した固有のものではなく、本明細書の開示内容によるルーチンと共に様々なデバイスを使用することができる。具体的には、デバイス間においてデータを転送するための本明細書に記述されている方法は、ルーターテスタ機能との関連において記述されているが、データ通信分野に一般的に適用することが可能である。又、本明細書に記述されている機能を実行可能な機械には、アジレント・テクノロジーズ社、ヒューレットパッカード社（ＨＥＷＬＥＴＴ ＰＡＣＫＡＲＤ）、及びテクトロニクス社（ＴＥＣＴＲＯＮＩＸ， ＩＮＣ．）、並びに通信機器のその他の製造者などの企業によって製造されるものが含まれる。

又、本明細書に記述されているソフトウェアに関連し、当業者であれば、本明細書に概説されている手順を実行するソフトウェアを生成するプラットフォーム及び言語には、様々なものが存在することを認識するであろう。本発明の実施例は、Ｃ^＋＋を含むＣの多数の変形のいずれを使用しても実装可能である。但し、当業者であれば、好適なプラットフォーム及び言語の選択肢は、しばしば、構築する実際のシステムの詳細によって決定され、この結果、あるタイプのシステムにおいて機能可能なものが、別のシステムにおいては効果的ではない場合があることをも認識するであろう。又、本明細書に記述されているルーチン及び演算は、コンピュータ上においてソフトウェアとして実行されるものに限定されるものではなく、ハードウェアプロセッサ内においても実装可能であることを理解されたい。例えば、ルーチン及び演算は、ＡＳＩＣＳ内においてＨＤＬ（Ｈａｒｄｗａｒｅ Ｄｅｓｉｇｎ Ｌａｎｇｕａｇｅ）により、或いは、様々な設計ツールを使用してＦＧＰＡ内において実装することができよう。

概要
本発明は、様々なアプリケーションとインタフェイスすると共にそれらを制御するべく容易に適合可能なポーティング可能な（portable、移植性のある）分散アプリケーションフレームワークに関するものである。一般に、このフレームワークは、アプリケーションとインタフェイスするハウジングと、１つ又は複数のクライアントインタフェイスメカニズム（ＧＵＩなど）とインタフェイスするプロキシと、プロキシとハウジング間における通信を円滑に実行するコントローラと、を有している。これらのハウジング、プロキシ、及びコントローラのそれぞれは、同一の（又は、恐らくその複写である）記述ファイルを使用して設定されている。この記述ファイルには、アプリケーションとインタフェイスしてこれを制御するべくフレームワークが使用するデータ構造及び命令の記述が含まれている。尚、以下の説明においては、プロトコルエミュレーションソフトウェアのセッションとのインタフェイス及びこの制御に使用する実装に絞って本発明について説明することとするが、本発明は、このようなプロトコルエミュレーションソフトウェアに対する使用に限定されるものではなく、様々な（特に、リモートアプリケーションの管理が望ましい）環境において使用するのに適したものである。

図２は、既存のプロトコルエミュレーションソフトウェアアーキテクチャ２００ａと、本発明の実施例によるプロトコルエミュレーションソフトウェアアーキテクチャ２００ｂの説明に有用なブロックダイアグラムである。はじめに、既存のプロトコルエミュレーションソフトウェアアーキテクチャ２００ａについて説明する。プロトコルエミュレーションソフトウェアは、一般に、制御メカニズムを提供するＧＵＩ（Ｇｒａｐｈｉｃａｌ Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ）２０２と、命令コンポーネントを提供するＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）２０４と、（例えば）カード１０２上においてプロトコルハウジングを形成する組み込み型ソフトウェア２０６と、という３つの別個の機能領域とやり取りする。既存のシステムにおいては、プロトコルエミュレーションソフトウェア２０８ｎには、特定のプロトコル用にカスタム作成されたコードの複合スイートが含まれている（例：ＯＳＰＦ（２０８ａ）、ＢＧＰ４（２０８ｂ）、ＲＩＰ（２０８ｃ）、及びＩＳ−ＩＳ（２０８ｄ））。換言すれば、それぞれのエミュレーション２０８ｎごとに、ＧＵＩ２０２、ＯＳ２０４、及び組み込み型ソフトウェア２０６に対するカスタムインタフェイスを生成し、これらを統合しなければならないということである。

引き続き図２を参照して、本発明の実施例によるプロトコルエミュレーションソフトウェアアーキテクチャ２００ｂについて説明する。本発明の実施例は、一般に、本明細書において汎用プロトコルフレームワーク（Generic Protocol Framework、ＧＰＦ）２１０と呼ぶソフトウェアルーチンのスイート２１０を有している。このＧＰＦ２１０は、ＧＵＩ２０２、ＯＳ２０４、及び組み込み型ソフトウェア２０６とインタフェイスしている。このＧＰＦ２１０は、すべてのプロトコルエミュレーション、汎用の制御及び命令ホストコンポーネント、及び組み込み型デバイス上における汎用のプロトコルハウジングをサポートする能力を有する汎用のＧＵＩを実現している。特定の実施例に応じて、例えば、プロトコル状態機械などの図２に要素２１２ｎとして示されているプロトコルの特定の要素をカスタムコーディングすることが有益であろう。このような実装においては、フレームワーク２１０は、プロトコルエミュレータをサポートするサービスとプロトコル状態機械上に存在する制御レイヤを一般化するものである。但し、後述するように、このフレームワーク２１０のみを使用することにより、要素２１２ｎなどの組み込み型のカスタムコーティングによるコンポーネントを必要とすることなしに、完全なプロトコルエミュレーションを生成することが可能である。

尚、本明細書において使用するこの「汎用（Ｇｅｎｅｒｉｃ）」という用語は、それぞれの汎用コンポーネントが、特定のプロトコルエミュレーションの知識なしに作成されているという意味において使用されるものである。この目標を達成する１つの方法は、プロトコルエミュレーション定義ファイル２１４内のコンポーネントの外部において命令とデータ構造を定義する方法である。好適な実施例においては、このプロトコルエミュレーション定義ファイル２１４には、入力データストリームからエミュレーションパケットを選択するのに必要なハードウェアパターンマッチャと、ソケットパラメータとソケットオプションを含むエミュレーションによって使用されるＴＣＰ／ＩＰソケットの詳細と、エミュレーションによって使用される命令、設定、及び結果データを記述するのに使用される汎用データ構造の組と、エミュレーションデータをユーザーに提示するためにＧＵＩが必要とするフォーマッティング情報と、が記述されている。このプロトコル定義ファイル２１４を使用してデータ構造を生成し、このデータ構造を実行時に使用してＧＰＦ２１０を設定することにより、特定のプロトコルとやり取りすることができる。

一実施例においては、プロトコルエミュレーション定義ファイル２１４は、ＸＭＬタグを使用してサービスと制御データを編成する。例えば、ハードウェアパターンマッチフィルタの設定は、ＸＭＬの＜ｆｉｌｔｅｒ＞タグを使用して記述することができる。同様に、エミュレーションに必要なＴＣＰ／ＩＰソケットの仕様は、＜ｓｏｃｋｅｔ＞タグを使用して作成可能である。エミュレータとの間で通信される命令及びデータ構造は、＜ｐａｒｃｅｌ＞タグを使用して記述することができる。そして、最後に、＜ｅｍｕｌａｔｉｏｎ＞タグを使用することにより、これらのタグによって参照されるデータをアセンブルすることができる。実行時には、このアセンブルされたデータを使用して、ＧＰＦ２１０の様々なコンポーネントがアクセス可能なデータ構造を生成する。尚、本明細書においては、このデータ構造を参照モデル（reference model）と呼ぶ。プロトコルエミュレーション定義ファイル２１４に静的な値を保存し、参照モデル内にプリロードすることができる。又、ユーザー入力を必要とする１つ又は複数の動的な値を外部から供給し、＜ｐａｒｃｅｌ＞セクションに記述されているデータ構造に基づいて通信プロセスを使用してＧＰＦ２１０の適切なコンポーネントに伝達することも可能である。このシステム上で稼働するそれぞれのプロトコルエミュレーションのインスタンス（これは、「セッション」と呼ばれる）は、一般に、１つ又は複数の参照モデルにアクセスし、設定及び制御データを取得する。このシステム上において実現されるプロトコルエミュレーションのそれぞれのタイプごとに、１つの参照モデル（又は、参照モデルの組）を定義し生成することが有益であろう。

「ＤＩＳＴＲＩＢＵＴＥＤ ＤＡＴＡ ＭＯＤＥＬ」という名称の同時係属中の米国特許出願第１０／８５１，３０３号明細書には、参照モデルの一般的な構造が適切なＸＭＬの構文と共に提示されている。この米国特許出願第１０／８５１，３０３号明細書は、＜ｐａｒｃｅｌｓ＞というタグに含まれるＸＭＬ構文の特定のサブセットの詳細について主に記述している（このタグは、命令及び通信データ構造を記述するのに使用される）。尚、２００４年５月２１日付けで出願されたこの米国特許出願第１０／８５１，３０３号は、本出願の譲受人に譲渡されており、本引用によって本明細書に包含される。本発明は、この米国特許出願第１０／８５１，３０３号明細書に記述されている概念のいくつかをプロトコルエミュレーションソフトウェアのスイート全体に拡張するものである。本発明の更なる態様については、以下の詳細な説明と添付の請求項を参照することにより、明らかとなろう。

一実施例においては、ＧＰＦ２１０は、汎用の自己文書化ＡＰＩを更に有している。このようなＡＰＩに関連する命令とパラメータは、ヘルプテキストと共に、プロトコルエミュレーション定義ファイル２１４内に記述することができる。この結果、フレームワークコードを作成することなしに、新しい命令を生成することが可能となる。Ｔｃｌ（Ｔｏｏｌ ｃｏｎｔｒｏｌ ｌａｎｇｕａｇｅ）などのツールを使用することにより、ＸＭＬ及びＴｃｌによってプロトコルエミュレーション全体を定義し、このフレームワーク内において稼働させることができる。この結果、ユーザー及びサポート技術者は、サプライヤからのカスタムプロトコルモジュール（例：モジュール２１２ｎ）の供給を待つことなしに、新しいプロトコルを即座に試験することができるようになる。このような汎用エミュレーションは、ＡＰＩ及びＧＵＩからは、通常のエミュレーションとまったく同一に見えることになる。尚、このような完全に汎用のソリューションには、性能の限界が存在しているが、「Ｔｉｍｅ−ｔｏ−ｍａｒｋｅｔ」ウィンドウが格段に改善されることになり、更に高い性能が必要な場合には、カスタムモジュールを提供することができる。

図３は、本発明の実施例によるターゲットプラットフォーム内に配備された汎用プロトコルフレームワーク３００のブロックダイアグラムである。汎用プロトコルフレームワーク３００（ＧＰＦ３００）は、一般に、エミュレーションコントローラ３０４、エミュレーションハウジング３０８ｎ、プロキシコントローラ３１４ｎという３つのコンポーネントを有している。エミュレーションコントローラ３０４は、プロトコルセッション（図示されてはいないが、後述する）を管理するものであり、ホスト３０２上に存在している。一般に、エミュレーションコントローラ３０４は、セッションを生成並びに除去する。ホスト３０２は、一般に、ＷＩＮＤＯＷＳオペレーティングシステムが稼働するＰＣなどのコンピュータを有している（但し、必ずしもこうである必要はない）。エミュレーションハウジング３０８ｎは、設定されたリソース及びセッションデータを提供するプロトコルセッションを収容する。このエミュレーションハウジング３０８ｎは、それぞれのプロトコルセッションごとに、エミュレーションコントローラ３０４に対する双方向のデータコンジット（conduit、経路）を提供する。そして、エミュレーションハウジングは、一般に、ポート３０６ｎ上に存在している。それぞれのポート３０６ｎは、通常、プロトコルエミュレーションカード（図示されてはいない。図１の要素１０２ｎを参照されたい）上に存在している。プロキシコントローラ３１４ｎは、エミュレーションコントローラの命令及びデータに対するアクセスを提供することにより、エミュレーションコントローラ３０４の遠隔制御を円滑に実行する。プロキシコントローラ３１４ｎは、図示されているＧＵＩ３１０及びＴｃｌ ＡＰＩ３１２を含む様々な機能コンポーネントに提供することができる。

それぞれのコンポーネントにプロトコルエミュレーション定義２１４ｎを提供する。一般に、これらのプロトコルエミュレーション定義２１４ｎは、あらゆる所与のプロトコルについて、すべて同一である。変化するのは、同一のプロトコルエミュレーション定義の組を特定のコンポーネントに提供するかどうかという点である。例えば、エミュレーションハウジング３０８ｎは、特定のポート３０６ｎ上において実行されないプロトコルのプロトコルエミュレーション定義２１４ｎを必要とはしない。

後程詳述するように、これらのコンポーネントは、これらの定義から参照モデル３１６ｎを生成する。参照モデル３１６ｎは、それぞれのコンポーネントがその他のコンポーネントを設定し、実行すると共に、それらと通信することができるようにするデータを保存する。このデータには、データ構造、設定データ、データ通信構造（及び、実際には、メソッド）、命令、及びこれらの使用を促進するための前述の記述が含まれている。

少なくとも１つの実施例においては、エミュレーションコントローラ３０４との間の通信は、この参照モデル３１６ｎ内に含まれている情報を使用して生成された（又は、インスタンス化された）メッセージを使用して実現されている。このようなメッセージ（これを「パーセル（parcel、小包、区画）」と呼ぶ）は、データ又は命令を格納することができる。この命令を使用してエミュレーションコントローラ３０４に指示することにより、プロトコルエミュレーションセッションの生成などの動作を実行する。そして、命令を遂行する情報や、エミュレーションコントローラ３０４との間でデータを報告するために必要な情報をデータとして含むことができる。具体的には、パーセルとは、データを伝達するために使用されるものであり、このデータには、参照モデルのその他のセグメント内において参照されているデータが含まれ、これには、例えば、＜ｆｉｌｔｅｒ＞及び＜ｓｏｃｋｅｔ＞タグに関連する情報が含まれている。

エミュレーションコントローラ
図４は、本発明の少なくとも１つの実施例によるエミュレーションコントローラ３０４の動作の説明に有用なブロックダイアグラムである。このエミュレーションコントローラ３０４は、例えば、ＧＵＩ３１０（図３を参照されたい）などのクライアント４２０とインタフェイスするべく、ＡＰＩ４１０を提供している。このＡＰＩ４１０は、クライアント４２０との間の命令とデータのやり取りのための主要コンジットを提供する。少なくとも１つの実施例によれば、クライアント４２０は、プロキシコントローラ３１４（図３を参照されたい）が提供されたデバイス又はソフトウェアを有することができる。

ＡＰＩ４１０は、一般に、クライアント４２０とエミュレーションコントローラ３０４間におけるメッセージの生成及び伝送の責任を担っている。同様に、ＡＰＩ４１２も、プロトコル状態機械４２２とエミュレーションコントローラ３０４間におけるコンジットとして機能するべく、エミュレーションハウジング３０８ｎ内に提供されている。少なくとも１つの実施例においては（後述するように）、プロトコルエミュレーション定義ファイル２１４内の＜ｐａｒｃｅｌ＞タグ内に含まれているデータに基づいて、メッセージを生成する。このメッセージ生成プロセス（これは、同時係属中の米国特許出願第１０／８５１，３０３号明細書に更に詳細に説明されている）は、基本的に、プロトコルエミュレーション定義ファイル２１４の内容に基づいた参照モデルの生成ステップと、これに続く参照モデル又はこの一部に基づいたオブジェクトのインスタンス化ステップと、を有している。そして、このオブジェクトに対して、プロトコルエミュレーション定義ファイル２１４、プロトコルエミュレーション定義ファイル２１４に基づいて生成された参照モデル、及びユーザーを含む任意の数のソースからのデータを入力する。ＡＰＩの外部に位置する文書内においてデータ構造を事前に定義することにより、エミュレーション固有の規定を必要とすることなしに、ＡＰＩを汎用的な方式で構築することができる。尚、汎用的なユーザーインタフェイスの実現やメッセージング帯域幅の低減などのその他の利益については、後述する。

ＡＰＩ４１０が形成して伝送するメッセージは、様々な機能を実行する。それらの機能の１つが、セッションの生成、設定、及び除去である。前述のように、本明細書において使用するこの「セッション」という用語は、一般に、プロトコルエミュレーションのインスタンスを意味している。表１は、プロキシコントローラ３１４ｎに加え、ＡＰＩ４１０及び４１２と共に使用するのに適したＡＰＩの一部を形成するエミュレーションコントローラに対する管理インタフェイスを記述する自己文書化Ｃ^＋＋コードの一部である。

エミュレーションコントローラ３０４とエミュレーションハウジング３０８間の通信などの通信を円滑に実行するために、一連のバッファ４０４ｎ（この例においては、バッファ４０４ａ〜４０４ｅ）をエミュレーションコントローラ３０４内に生成することができる。そして、ＡＰＩ４１２の管理下にあるエミュレーションハウジング３０８が、このエミュレーションコントローラ３０４内のバッファに対応する一連のバッファ４０４ｎ（この例においては、バッファ４０４ｆ〜４０４ｊ）を生成する。ポートによってホスティングされているそれぞれのプロトコル状態機械ごとに、類似した一連のバッファを生成する。使用するバッファのタイプは、パーセルタイプにより、参照モデル３１６内において指定することができる。例えば、バッファタイプは、ＸＭＬパーセル定義内に属性として示すことができる。或いは、この代わりに、これをプロキシコントローラ３１４ｎなどのクライアントアプリケーションによって設定できるようにすることも可能であろう。これらのバッファ４０４ｎは、一般にシリアル通信経路を有しているパーセルリンク４２４によって接続されている。尚、図４には、図示されているパーセルタイプのそれぞれごとにマッチングバッファを提供した状態が示されているが、データのフローが単一方向の場合には、受信バッファのみを提供することも好ましいであろう。

これらのバッファ４０４の正確な特性は、本発明の所与の実装によって異なることになるが、エミュレーションコントローラ３０４とエミュレーションハウジング３０８ｎ間において伝達されるパーセルのそれぞれのタイプごとに別個のバッファ４０４ｎを生成することが好ましいであろう。パーセルのタイプは、一般に、その中にカプセル化されるデータによって決定される。パーセル内のデータの使用方法に応じて有益なバッファのタイプには様々なものが存在する。従って、パーセルタイプごとに異なるバッファタイプを定義することが有益であろう。

一般に、バッファリングとは、受信（又は、送信）システムがパーセル内に含まれている情報を処理する準備が整うまで、パーセル（又は、そのセグメント）を一時的に保持することを意味している。例えば、クライアントは、ホストの負荷を極小化するべく、送信側のバッファからパーセルをプルすることができる。或いは、この代わりに、送信側は、受信側の様々なタイプのバッファにパーセルをプッシュすることにより、応答性を最適化することも可能である。バッファのタイプは、それぞれのパーセル及び／又はパーセルタイプごとに指定することができる。或いは、この代わりに、異なるバッファタイプからなるバンクを初期化し、バッファのタイプに基づいてメッセージをバッファ内に保管することも可能である。表２に、適切なバッファタイプのいくつかの例が示されている。

図４は、セッションデータ（Session Data）、統計（Statistics）、ルートプール（Route Pool）、ルートプールタイプ（Route Pool Type）、及びグローバル統計（Global Statistics）を含む特定のパーセルタイプごとのバッファの生成を示している。そして、表３には、いくつかの可能なパーセルタイプとそれらの適切なバッファタイプの更に詳細な説明が提供されている。

バッファとこれらのバッファの動作を円滑に実行するルーチンは、本明細書においては、パーセルストア（parcel store）４０２及び４０４と呼ぶ手順の組の一部を集合的に構成している。一実施例においては、これらのパーセルストア４０２及び４０４の機能コンポーネントは、それぞれＡＰＩ４１０及び４１２によって生成並びに維持されている。パーセルストアの更なる機能には、それからメッセージオブジェクトをインスタンス化することができるパーセル参照モデルの保存と維持も含まれている。パーセルオブジェクト自体をバッファ４０４に保存し、ここから取得する。表４は、パーセルストアの機能を記述する自己文書化Ｃ^＋＋コードの一部である。

パーセルストア４０２ａは、エミュレーションハウジング３０８ｎに送信されたそれぞれのパーセルの最新の複写を保持するべく設定可能である。この設定を利用すれば、最も新しく転送されたパーセルを含むパーセルをパーセルストア４０２ａ内に保存することにより、エミュレーションコントローラ３０４の現在の設定を保存するバックアップ機能を実装することができる。このバックアップは、それぞれのアクティブセッションをシリアライズすることによって実現される。それぞれのアクティブセッションは、パーセルストア内のすべてのパーセルをシリアライズすることによってシリアライズする。そして、それぞれの保存されているセッションを再生成し、このセッションに回復されたパーセルを入力することにより、設定を回復することができる。

エミュレーションハウジング
エミュレーションハウジング３０８は、一般に、ＧＰＦ２１０と、プロトコル状態機械３０８ｎなどの組み込み型カスタムコンポーネント間におけるインタフェイスとして機能する。エミュレーションハウジング３０８は、シリアライズされたパーセルの形態のメッセージを受信し、パーセルを再構築して、そのパーセル内のデータを組み込み型カスタムコンポーネントの各コンポーネントに配布する。同時に、エミュレーションハウジング３０８は、組み込み型カスタムコンポーネントの各コンポーネントからデータを受信し、それらに基づいてパーセルを生成し、このパーセルをエミュレーションコントローラ３０４に伝送する。プロトコルエミュレーションシステムの場合には、それぞれのセッションごとに、エミュレーションハウジング３０８ｎが提供され、次にこのハウジングが、エミュレーションコントローラ３０４と通信する。

図５は、本発明の実施例による汎用のプロトコルセッションモデルのブロックダイアグラムである。一般に、試験ポート上で稼働しているプロトコル状態機械（及び、関連するサポートコード）のインスタンスをセッションと呼ぶ。図５は、２つのポート３０６ｘ及び３０６ｙ上において稼働する８つのセッションＳ１〜Ｓ８を示している。これらのポート３０６ｎ及びセッションＳｎは、テーブル５０２を維持するエミュレーションコントローラ３０４に応答して個々のセッションを追跡する。

エミュレーションコントローラ３０４は、それぞれのセッションごとにＡＰＩサービスとバッファを提供する。前述のように、これらのＡＰＩ及びバッファは、エミュレーションコントローラ３０４とセッションＳｎ間における通信を円滑に実行する。エミュレーションハウジング３０８ｍ及び３０８ｎは、ポート３０６ｎ上において稼働するそれぞれのセッションＳｎごとにＡＰＩとバッファを提供する。エミュレーションハウジング３０８ｎは、指定されたポート３０６ｎ上におけるセッションの生成及び除去の責任を担っている。

それぞれのセッションＳｎは、動作のために、いくつかのリソースを必要とする。これらのリソースには、ハードウェアパターンマッチ、その上で動作するためのソケット（ＴＣＰ／ＩＰソケットなど）、及び通信及び制御用のＡＰＩが含まれる。図６は、本発明の実施例によるプロトコルインフラストラクチャのブロックダイアグラムである。この図６において、プロトコル状態機械６０２は、ＡＰＩ６０４（これは、図４に示されているＡＰＩ４１２のインスタンスであってよい）、ソケットマネージャ６０６、及びマッチャ（matcher）マネージャ６０８と通信状態にあるものとして示されている。これらのＡＰＩ６０４、ソケットマネージャ６０６、及びマッチャマネージャ６０８は、エミュレーションハウジング３０８の一実施例を集合的に形成している（図３及び図４を参照されたい）。

起動時に、ＡＰＩ６０４は、プロトコルエミュレーション定義ファイル６１０に基づいて参照モデルを生成する。このプロトコルエミュレーション定義ファイル６１０は、プロトコル定義ファイル２１４の複写であり、これは、ＡＰＩ６０４の制御下において生成された参照モデルが、ＡＰＩ４１０の制御下において生成された参照モデルと一致すること意味している。この結果、このＡＰＩ６０４は、インスタンス化されたパーセルのインスタンスを使用することにより、ホスト３０２上のエミュレーションコントローラ３０４（図３を参照されたい）と通信することができる。

ＡＰＩ６０４は、エミュレーションコントローラ３０４からデータを受信し、エミュレーションハウジング及びプロトコル状態機械６０２のその他のコンポーネントにデータを配布する。同時に、ＡＰＩ６０４は、エミュレーションハウジング３０８とプロトコル状態機械６０２のその他のコンポーネントからデータを受信し、エミュレーションコントローラ３０４に伝送する。このエミュレーションコントローラ３０４との通信は、前述の一連のパーセルストアとそれらに付随する前述のバッファを使用して実行することができる。

ＡＰＩ６０４は、プロトコル状態機械６０２、マッチャマネージャ６０８、及びソケットマネージャ６０６に対する設定データの管理も行っている。一実施例においては、参照モデルは、特定のエミュレーションタイプのすべてのセッションに属する静的な情報を保存するべく設定されている。ソケットマネージャ６０６は、例えば、セッションデータパーセルを使用し、エミュレーションコントローラ３０４から送信された値を読み取ることにより、静的な情報を特定のセッションに属する動的情報と組み合わせる。セッションデータパーセル内の値を相互参照するべく、参照モデル内のソケット定義を設定することができる。

ソケットマネージャ６０６は、通信チャネルをセットアップし、これを維持する。図４に示されている例においては、ソケットマネージャ６０６は、ＴＣＰ／ＩＰスタック６０６ａを維持している。エミュレーションハウジング３０８ｎ内においてプロトコルエミュレーションセッションが有効になると、ＡＰＩ６０４によって構築された参照モデルをチェックして、そのセッションに必要なソケット設定を検出する。そして、ソケットマネージャ６０６は、参照モデルを使用し、それぞれのソケットごとに、必要なソケットを構築する。ソケットは、セッション又はインタフェイスごとに個別に、或いは、そのハウジングについてグローバルに生成することができる。このため、ソケットマネージャ６０６は、複数のセッションによって共有されるソケットの参照カウントを維持している。例えば、グローバルソケットを使用する場合には、セッションによって最初に要求された際に、ソケットを生成する。そして、後続のセッションには、この既存のグローバルソケットを付与し、新しいものは生成しない。尚、このようなグローバルソケットは、そのソケットを使用しているすべてのセッションが無効になるか又は破棄された場合にのみ、破棄される。

エミュレーションマッチャマネージャ６０８は、ハードウェアマッチャを管理している（これは、「フィルタ」とも呼ばれる）。フィルタを使用することにより、被検ルーターからプロトコル状態機械６０２が受信したプロトコルメッセージの各メッセージ又はその一部を選択することができる。そして、選択したメッセージを分析及び報告のために保存することができる。２００４年６月１５日付けで出願された同時係属中の米国特許出願第１０／８６１，６１８号明細書には、このようなフィルタの可能な一実装について記述されており、この内容は、本引用により、本明細書に包含される。エミュレーションハウジング３０８ｎ内においてプロトコルエミュレーションセッションが有効になると、参照モデルをチェックし、セッションに必要なフィルタを検出する。マッチャマネージャ６０８（又は、フィルタマネージャ）は、それぞれのフィルタごとに、参照モデルを使用することにより、必要なフィルタを構築する。一般に、フィルタは、参照モデル内の静的情報によって完全に定義することができる。そして、フィルタは、同一タイプのすべてのセッションによって共有可能である。このため、マッチャマネージャ６０８は、参照カウントを維持し、特定のタイプの重複するフィルタを生成することによってハードウェアリソースが不必要に消費されないようにしている。そして、セッションが無効になった場合には、対応するフィルタは、そのフィルタを使用するすべてのセッションが無効になった場合にのみ除去される。

プロキシコントローラ
図３を参照すれば、プロキシコントローラ３１４ｎは、一般に、前述のものに類似したＡＰＩと関連プロトコルエミュレーション定義ファイルを有している。このＡＰＩにより、ホスト３０２上のエミュレーションコントローラ３０４との通信に便利なカプセル化されたソリューションが提供される。メッセージングがパーセルオブジェクトを使用して実現されることから、エミュレーションに対する制御は、パーセルオブジェクトを生成する能力を有するデバイス（例：適切なＡＰＩを有するデバイス）であれば、どのようなものの内部にも配置することができる。この図３に示されている例の場合には、プロキシコントローラ３１４ａ及び３１４ｂは、ＧＵＩ３１０及びＴｃｌ ＡＰＩ３１２に提供されている。この組み込みにより、Ｔｃｌスクリプトを使用したセッションの生成、設定、制御、及び削除を含むセッションの制御が可能となる。

これらのプロキシコントローラ３１４は、表１に示されているＩａｐｆＥｍｕｌａｔｉｏｎＣｏｎｔｒｏｌを実装することによって形成することができる。それぞれのプロキシコントローラ３１４ｎは、エミュレーションコントローラ３０４内のものと同一の参照モデル３１６ｎを維持している。そして、それぞれのプロキシコントローラ３１４ｎは、関連するエミュレーションコントローラ３０４に登録している。ハウジング３０８ｎからエミュレーションコントローラ３０４がパーセルを受信すると、パーセルは、そのまま、それぞれの登録されたプロキシコントローラ３１４ｎに転送される。同様に、プロキシコントローラ３１４ｎがパーセルをハウジング３０８ｎに送信した場合にも、それは、エミュレーションコントローラ３０４を介して送信されることになる。エミュレーションコントローラ３０４は、パーセルの複写を保持し、それを複写してその他のプロキシコントローラ３１４ｎに提供する。このようにして、エミュレーションコントローラ３０４及びすべてのプロキシコントローラ３１４ｎは、ミラーリングされたパーセルバッファの組４０４ｎを維持している（図４を参照されたい）。クライアントインタフェイスを駆動するのは、このパーセルバッファの組４０４ｎである。

Ｔｃｌインタフェイス
表５は、エミュレーションコントローラを介してポート上のセッションを制御するべくＴｃｌによって生成されたインタフェイスの使用法の例を示す画面ショットである。

Ｔｃｌなどのスクリプト言語を使用すれば、プロトコル状態機械３０８ｎによって実行される機能を複写することができる。基本的に、ＸＭＬタグを使用して様々なプロトコルの状態を定義し、Ｔｃｌ手順の組を定義２１４ｎ内に組み込んで状態の変化を処理することになろう。到来するＰＤＵストリームをデコードするためのデコードサービスライブラリと、送信するＰＤＵストリームをエンコードするためのエンコードサービスライブラリをＴｃｌインタープリタに提供することができる。表６は、適切なＴｃｌ機能（注釈行に記載されているもの）との関連で、ＧＰＦ２１０内のプロトコル状態機械の特定の機能を模倣するべく使用可能なＸＭＬファイルである。

簡単なエミュレーション及び適合試験を提供するＴｃｌスクリプトを生成可能である。ポートが受信したプロトコルパケットをＴｃｌ ＡＰＩ３１２のコントローラに伝達するべく、エミュレーションハウジング３０８ｎを設定する。同様に、Ｔｃｌ ＡＰＩ３１２が生成したプロトコルパケットを被検ネットワークに伝達するべく、エミュレーションハウジング３０８ｎを設定することができる。特許文献１に記述されているものなどのパケット構築ソフトウェアとインタフェイスするべく、このＴｃｌ ＡＰＩ３１２を設定可能である。或いは、この代わりに、定義に基づいて設定可能な状態機械のフォーマットをプロトコルエミュレーション定義２１４に類似したものにすることにより、本発明の特定の概念をプロトコル状態機械に拡張することも可能である。

ＧＵＩ
好適な実施例においては、ＧＵＩ３１０は、表示上の要素のレイアウトがメッセージ参照モデル及びオブジェクトの構造に応答して動作する汎用的な方式で構築されている。図３を参照すれば、このＧＵＩ３１０は、表示するそれぞれのデータ片ごとに、その表示をフォーマッティングする方法を記述した属性を生成可能なプロトコルエミュレーション定義２１４ｎを使用して駆動される。同様に、ユーザーからの入力が必要な場合には、その入力を要求するデータ要素の属性を使用することにより、その入力を要求する表示をフォーマッティングすることができる。ＧＵＩ３１０は、データのそれぞれの主要機能ブロックごとに、事前に設計及び構築されたダイアログを具備することが有利であろう。それぞれのブロックの表示のフォーマッティングは実装によって異なることになるが、それぞれのブロックにその独自のウィンドウを提供することが有利であろう。そして、ＧＰＦダイアログの具体的な内容（フィールドや列など）として、受信したデータが入力されることになる。

主要機能ブロックの適切なリストの一例には、セッションマネージャ、セッションエディタ、トポロジーエディタ、セッション統計、セッションログ、及びメッセージトレースが含まれる。セッションマネージャブロックには、セッションの生成、削除、有効化、及び無効化用のデータと、セッション状態及びサマリ情報のビューを含むことができよう。セッションエディタブロックには、ＳＵＴアドレス、オプション、及びタイマなどのセッショングローバルデータの生成、参照、及び編集用のデータを含むことができよう。トポロジーエディタブロックには、シミュレートされたルートまたはルーターなどのセッショントポロジーのビューを生成するためのデータを含むことができよう。又、トポロジーエディタブロックには、命令の送信やエミュレーションセッション内へのＰＤＵの注入の機能を含むこともできる。セッション統計ブロックは、それぞれのセッションタイプに関するリアルタイムの統計のビューを提供することができよう。セッションログブロックは、それぞれのセッションによって生成されたイベントメッセージのビューを提供することができよう。そして、最後に、メッセージトレースブロックは、それぞれのセッションによって送受信されるメッセージのライブメッセージトレースのビューを提供することができよう。

プロトコルエミュレーション定義
本発明の実施例の基礎をなす概念は、論理的にＧＰＦ２１０の外部においてプロトコルエミュレーション定義を使用するという点にあろう。図７は、本発明の実施例による汎用プロトコルフレームワークにおいて使用するのに適したＸＭＬタグ階層構造の図である。本発明の特定の実施例によれば、この図７に示されているＸＭＬタグ階層構造を使用することにより、プロトコルエミュレーション定義ファイルに基づいて参照モデルを形成している。尚、プロトコルエミュレーション定義は、ＸＭＬでフォーマッティングするものとして説明しているが、当業者であれば、その他のフォーマットも使用可能であることを認識するであろう。具体的には、その生成及び変更を円滑に実行するべく容易にアクセス可能なフォーマットでプロトコルエミュレーション記述をフォーマッティングすることが望ましい。

ファイルの好ましいデータ構造は、階層構造であり、この場合に、それぞれのノードは、値、サブノード、関数、値の配列、又は値の表を格納することができる。ＸＭＬが提供するネストタグ構造により、階層構造関係及び表構造の文書化が円滑に実行される。メッセージ定義は、機能ユニットのリストを提供すると共に、それぞれの機能ユニットを構成する要素（本明細書においては、これを「ノード」と呼ぶ）、それぞれのノードのタイプ、及びノードの相互関係を規定するテキストファイルと同程度に簡単なものであってよい。それぞれのノードには、記述属性を使用して注釈を付加することができる（この例について後述する）。

エミュレーション定義ファイルのそれぞれのセクションは、ヘッダと、要素の組を有することができる。要素は、一般に、構造を定義するコンテナ要素と、１つ又は一連の値を保存するデータ要素という２つのカテゴリに分けられる。ＸＭＬタグを使用することにより、これらのヘッダ及び要素を編成することができる。例えば、単一タイプのプロトコルエミュレーションに必要なデータ及び命令は、＜ｅｍｕｌａｔｉｏｎｓｅｔ＞タグ内においてカプセル化することができる。そして、＜ｅｍｕｌａｔｉｏｎｓｅｔ＞タグ内において、それらの要素をその機能に基づいて更に編成することができる。図７を参照すれば、１つの可能な組織体系が示されており、この場合には、要素は、＜ｐａｒｃｅｌ＞、＜ｃｏｍｍａｎｄ＞、＜ｆｉｌｔｅｒ＞、＜ｅｍｕｌａｔｉｏｎ＞、及び＜ｅｎｕｍｓｅｔ＞というタグを使用してカプセル化されている。

＜ｐａｒｃｅｌ＞セクションの形態とフォーマットについては、同時係属中の米国特許出願第１０／８５１，３０３号明細書に記述されている。そして、＜ｃｏｍｍａｎｄ＞セクションは、＜ｐａｒｃｅｌ＞セクションと同一の基本フォーマットを踏襲している。表７には、この＜ｐａｒｃｅｌ＞メッセージセグメント用の要素タイプの組の例が示されている。

ＡＰＩが使用する命令もＸＭＬ定義を使用して定義することができる。これは、間接化のレベルを追加することによって実現可能であり、この結果、数百もの多数のプロトコル固有の命令を具備するＡＰＩの代わりに、ＡＰＩ自体は、いくつかの汎用命令を提供することになる。例えば、表８に記述されている命令は、ユーザーがプロトコル定義内に定義されている命令を識別して起動することを可能にする最小限の命令の組を表している。

それぞれのエミュレーションごとに提供する命令は、プロトコルエミュレーション定義２１４ｎ内において定義可能である。この例については、表９を参照されたい。

この単純なケースにおいては、必要なパラメータは、１つ又は複数の値として定義されている。その他の状況においては、命令パラメータをパーセル内の表の行として定義することが有用である（例：表１０を参照されたい）。

この例の場合には、「ｒｏｕｔｅＰｏｏｌｓ」と呼ばれるパーセルが既に定義されていることを前提としている（このパーセルは、それぞれの行が個々のルートプールを表す表である）。この「ａｄｖｅｒｔｉｓｅ」命令は、ルートプールに対して作用するものであり、「ｒｏｗＲｅｆ」属性を使用することによって、これら２つを関連付けている。

この命令のスタイルによれば、ユーザーは、ルートプールテーブル内の行を選択し、「ａｄｖｅｒｔｉｓｅ」をクリックすることができる。このスタイルは、ＧＵＩに非常に有用であり、この命令定義によれば、適切な命令とパラメータを自動的に関連付けることができる。

同時係属中の米国特許出願第１０／８６１，６１８号明細書には、＜ｆｉｌｔｅｒ＞セクションの１つの可能な実装について記述されている。一実施例においては、＜ｆｉｌｔｅｒ＞用に、＜ｈｗＭａｔｃｈ＞という単一のタグを定義している。フィルタは、一般に、事前に定義されたビットストリームとしてフォーマッティングされるため、＜ｈｗＭａｔｃｈ＞は、実装されたエミュレーションマッチャに直接対応する（２進又は１６進の）ビットストリームを格納している。一例として、ＡＧＩＬＥＮＴ ＲＯＵＴＥＲＴＥＳＴＥＲ ９００用の＜ｈｗＭａｔｃｈ＞パラメータは、ＩＰプロトコルＩＤと、ＩＰペイロードの最初の３２ビット、並びに関連するマスクである。要すれば、＜ｈｗＭａｔｃｈ＞タグのペイロードは、ハードウェアインタフェイスをプログラムするのに必要なデータを格納しているに過ぎない。

＜ｅｍｕｌａｔｉｏｎ＞セクションは、特定のプロトコルエミュレーションに属する＜ｓｏｃｋｅｔ＞及び＜ｐａｒｃｅｌ＞タグを格納している。又、＜ｅｍｕｌａｔｉｏｎ＞は、＜ｅｍｕｌａｔｉｏｎ＞の外部において定義されている１つ又は複数のフィルタを参照することもできる。

表１１には、＜ｓｏｃｋｅｔ＞メッセージセグメントの要素タイプのサンプルの組が含まれている。

表１２には、＜ｆｉｌｔｅｒ＞及び＜ｓｏｃｋｅｔ＞セクションを示すプロトコルエミュレーション定義のセグメントが含まれている。

＜ｅｎｕｍＳｅｔ＞は、名前／値ペアの表であり、これは、有意な名前を特定の値又は値の範囲にマッピングするために使用する。これは、未加工の値を有意な値と並べて提示することが好ましいデータをＧＵＩで提示する際に、特に有用である。又、このｅｎｕｍＳｅｔの概念を拡張することにより、パーセル又はパーセル値が特定の値に基づいて相互参照できるようにすることも可能である。表１３には、＜ｅｎｕｍ＞の組の例が示されている。

ここでは、例えば、「１」という特定の値を「Ｒｏｕｔｅ Ｐｏｏｌ」という名前と、そして、パーセルにもマッピングしている。これは、例えば、トポロジーアイテムの要約表を一覧表示するＧＵＩにおいて使用することができよう。表内の行を選択することにより、ユーザーは、そのトポロジータイプに応じて参照されたパーセルから抽出された詳細なデータを見ることができる。

それぞれの要素には、記述属性を使用して注釈を付加することができる。この属性により、要素が文書化され、メッセージ定義を自己文書化することができる。この属性をメッセージ定義及び（場合によって）メッセージ参照モデルと共に保存することにより、メッセージの操作並びにこれらとのインタフェイスのために提供するルーチンの特性を汎用的なものにすることができる（例：ルーチン内においてデータ構造を定義するのではなく、データ構造を実行時に提供する）。例えば、これらの属性を使用することにより、汎用グラフィカルユーザーインタフェイスを使用してメッセージ又はセグメントを提示及び編集するのに必要なすべての情報を提供することができる。表１４には、可能な属性のいくつかの例が示されている。当業者であれば、表１４に含まれているリストがすべてを網羅するものではないことを認識するであろう（本発明の実装に応じて、その他の属性も有益であろう）。

一例として、表１５には、ＸＭＬによるプロトコルエミュレーション定義の例が含まれている。具体的には、この表１５には、サンプルｂｇｐ４定義ファイルが含まれている。

しばしば、定義の内外において指定されるその他の値によって変化する要素の既定値を設定することが必要となる。このようなケースにおいては、このタスクを実行するべく起動可能なＴＣＬ（Ｔｏｏｌ Ｃｏｍｍａｎｄ Ｌａｎｇｕａｇｅ）手順を内蔵することが有益であろう。この機能は、プロトコルエミュレーション定義ファイル内において指定することができる。尚、当業者であれば、このようなＴＣＬの内蔵を実行することは可能であるため、この内蔵の具体的な詳細については、本明細書においてはその説明を省略する。表１６には、ＴＣＬ機能を内蔵するパーセル定義の一部の例が示されている。

この例においては、ｋｅｅｐａｌｉｖｅの既定値は、ｈｏｌｄＴｉｍｅｒにどのような値が設定された場合にも、ｈｏｌｄＴｉｍｅｒの２倍になるように維持されている。これらのＴＣＬ機能は、パーセルをインスタンス化する際に（例：パーセルのインスタンスを生成する際に）実行することができる。又、メッセージ定義及び／又はモデルをレビューし、実行時にこの機能の影響を受けた値を更新するべく、ルーチンを生成することも可能である。

図３を参照すれば、プロトコルエミュレーション定義は、ホスト３０２上に保存しておき、エミュレーションコントローラ３０４によって実行時に取得することができる。同様に、ホスト３０２と通信するリモートプロセス（例：ポート３０６ｎ、ＧＵＩ３１０、及びＴｃｌ ＡＰＩ３１２）にも、これらのプロトコルエミュレーション定義の複写を提供可能である。

実行時には、プロトコルエミュレーション定義を解析して参照モデルを生成する。一般に、参照モデルは、Ｃ^＋＋などによるデータ構造である。この参照モデルは、２つの機能をサービスする。第１の機能は、システムの様々な機能要素が参照するデータを保持することである。そして、第２の機能は、エミュレーションコントローラ３０４との間のデータの伝達に使用するパーセルを生成するためのモデルとして機能することである。このようなパーセルは、プロトコルエミュレーション定義のインスタンス（又は、その１つ又は複数のセグメント）を有することができる。恐らく、参照モデルに最も近い類似の構造は、Ｃ^＋＋のジェネリックタイプ（Ｇｅｎｅｒｉｃ Ｔｙｐｅ）であろう。１つの違いは、ジェネリックタイプは、コンパイル時に定義しなければならないが、参照モデルの場合には、実行時に導入することができるという点にある。本発明の少なくとも１つの実施例においては、パーセルを導出する元となる参照モデルにおいてタイプを定義している。尚、使用の際には、稼働の際に必要となる可能性のあるすべての潜在的なパーセルの参照モデルを生成するべく、システムの起動時にすべてのプロトコルエミュレーション定義を解析することが有益であろう。但し、時間とストレージを考慮する必要がある場合には、現在のセッションに必要となる可能性が高い参照モデルのみを生成することを推奨する。

ＧＰＦ２１０のそれぞれの主要な要素（例：エミュレーションコントローラ３０４、エミュレーションハウジング３０６ｎ、及びプロキシコントローラ３１４ｎ）は、プロトコルエミュレーション定義２１４の複写を具備する必要がある。これは、プロトコルエミュレーション定義２１４を１つの要素（通常は、エミュレーションコントローラ３０４）に提供し、次いで、その複写をその他の要素に配布することによって実現することができる。これを実現可能な１つの方式は、パーセルストアの設定及び動作を実現するブートストラップ定義ファイルをＧＰＦ２１０のそれぞれの要素に対して手動で提供する方法である。その後、システムを初期化する際に、それらをパーセル内にカプセル化し、パーセルストア４０２ｎを使用して伝送することにより、パーセルストアを使用してプロトコルエミュレーション定義ファイル２１４の現在の組を伝送することができる。

パーセルリンク
前述のように、エミュレーションコントローラ３０４との間の通信は、好ましくは、同時係属中の米国特許出願第１０／８５１，３０３号明細書に記述されているパーセルの概念に基づいて事前定義されたメッセージングフォーマットによって実行される。そして、これらのパーセルは、パーセルリンク４２４（図４を参照されたい）の概念を使用して伝送可能である。

パーセルリンク４２４は、バイトストリングを単純に送受信する簡単なインタフェイスから構成することにより、必要に応じてシリアルインタフェイスやその他のタイプのネットワーク上に簡単に実装できるようにすることができる。尚、物理的な実装の詳細は、ＧＰＦにとってトランスペアレントにする必要があるが、更なる説明は省略する。

パーセルを伝送する１つの方法は、構造からデータを抽出することによってパーセル内のデータをシリアライズする方法である。受信側において、このバイナリストリームをデコードし、パーセルを再生成するのに使用可能な参照モデル（又は、この一部）を識別できるように、十分なデータ構造を提供する必要がある。この再構築の際には、参照モデル内に含まれている構造情報を使用し、バイナリストリーム内のデータを解析することができる。従って、このシリアライズされたメッセージの受信者には、適切なメッセージ定義の複写を提供する必要がある。受信者は、このメッセージ定義を解析し、参照モデルを生成しなければならない（この参照モデルは、参照モデル２０４ａの複写である）。そして、シリアライズされたメッセージを受信した際に、受信者は、この参照モデル（又は、その一部）をインスタンス化し、この結果生成されるデータ構造に対してそのバイナリデータを入力することによってメッセージオブジェクトを形成し、これにより、メッセージオブジェクトを再生成する。

表１７は、本発明の実施例によるメッセージの伝送に使用するのに適した通信リンクを記述する自己文書化Ｃ^＋＋コードの一部である。

結論
要すれば、本発明は、汎用プロトコルエミュレーションの可能性を実現するものであり、プロトコルエミュレーションの全体をＸＭＬ及びＴｃｌによって定義し、フレームワーク内において稼働させることができる。この結果、顧客及びサポート技術者は、サプライヤからのプロトコルモジュールの供給を待つことなしに、新しいプロトコルを即座に試験することができるようになる。このような汎用エミュレーションは、ＡＰＩ及びＧＵＩからは、組み込み型エミュレーションとまったく同一に見えることになるが、性能に限界が存在している。しかしながら、「Ｔｉｍｅ−ｔｏ−ｍａｒｋｅｔ」ウィンドウが改善され、必要に応じて、高性能の組み込み型エミュレーションソリューションによってフォローアップする機会を提供している。スタンドアロンフレームワークを様々なターゲットプラットフォーム内に容易に配備可能である。プロトコルモジュールは、自己完結型のＧＰＦ環境において開発及び試験し、ＧＰＦを配置するどのようなプラットフォームにも配置することができる。このＧＰＦは、３つのＧＰＦコンポーネントの柔軟なスター型の結線特性と、これらのコンポーネントを１つに接続するのに使用される非常に単純な非同期のｐａｒｃｅｌＬｉｎｋ ＡＰＩにより、様々なターゲットプラットフォームに、そして、場合によっては、分散環境にも容易に配備することが可能である。

トラフィックシミュレータ試験システムのブロックダイアグラムである。 既存のプロトコルエミュレーションソフトウェアアーキテクチャと、本発明の実施例によるプロトコルエミュレーションソフトウェアの制御に適したアーキテクチャの説明に有用なブロックダイアグラムである。 本発明の実施例によるターゲットプラットフォーム内に配備される汎用プロトコルフレームワークのブロックダイアグラムである。 本発明の少なくとも１つの実施例によるエミュレーションコントローラの動作の説明に有用なブロックダイアグラムである。 本発明の実施例による汎用プロトコルセッションモデルのブロックダイアグラムである。 本発明の実施例によるプロトコルインフラストラクチャのブロックダイアグラムである。 本発明の実施例による汎用プロトコルフレームワークにおいて使用するＸＭＬタグ階層構造の図である。

Claims (22)

1. プロトコルエミュレーション定義によって設定され、前記プロトコルエミュレーション定義ファイル内に含まれたデータに従ってプロトコルエミュレーションセッションを起動する少なくとも１つのエミュレーションハウジングと、
   前記プロトコルエミュレーション定義によって設定され、前記エミュレーションハウジングによって生成された前記セッションに関係するデータを表示し、ユーザーからの命令と設定データのエントリを円滑に実行するインタフェイスであって、前記命令及び設定データは、前記エミュレーションハウジングに伝送され、その挙動を変更する、インタフェイスと、
   プロトコルエミュレーション定義を配布し、前記エミュレーションハウジングと前記インタフェイス間におけるデータ及び命令のコンジットとして機能するエミュレーションコントローラと、
   を有するプロトコルエミュレーションシステム。
2. 前記エミュレーションハウジングは、前記プロトコルエミュレーション定義ファイルを使用し、動作の際に使用されるデータを保存するデータ構造を構築する、請求項１記載のプロトコルエミュレーションシステム。
3. 前記インタフェイスは、前記プロトコルエミュレーション定義ファイルを使用し、動作の際に使用されるデータを保存する参照モデルを構築する、請求項１記載のプロトコルエミュレーションシステム。
4. 前記エミュレーションハウジングは、前記プロトコルエミュレーション定義ファイルを使用し、動作の際にデータを保存する参照モデルを構築する、請求項３記載のプロトコルエミュレーションシステム。
5. 前記インタフェイスは、前記参照モデルを使用し、前記エミュレーションハウジング用のメッセージをインスタンス化する請求項４記載のプロトコルエミュレーションシステム。
6. 前記エミュレーションハウジングは、前記参照モデルを使用し、前記インタフェイス用のメッセージをインスタンス化する、請求項４記載のプロトコルエミュレーションシステム。
7. 前記エミュレーションハウジングと通信状態にあり、プロトコルメッセージを生成しこれに応答するプロトコル状態機械を更に有する、請求項１記載のプロトコルエミュレーションシステム。
8. プロトコルメッセージを生成しこれに応答する方法を記述するスクリプトを更に有し、
   前記エミュレーションハウジングは、受信したプロトコルメッセージを前記スクリプトに伝達すると共に、前記スクリプトによって生成された応答を被検ネットワークに伝送する、
   請求項１記載のプロトコルエミュレーションシステム。
9. 前記インタフェイスは、前記プロトコルエミュレーション定義内に含まれた情報に基づいて表示を生成するグラフィカルユーザーインタフェイスを有する、請求項１記載のプロトコルエミュレーションシステム。
10. 前記インタフェイスはテキストである、請求項１記載のプロトコルエミュレーションシステム。
11. 前記インタフェイスはスクリプト言語を使用して生成される、請求項１記載のプロトコルエミュレーションシステム。
12. ポーティング可能な分散アプリケーションフレームワークであって、
    前記フレームワークがアプリケーションとインタフェイスするために使用するデータ及び命令の構造を記述する定義ファイルと、
    前記定義ファイルに応答し、前記定義ファイルに基づいてメッセージを生成及び受信するプロキシであって、前記生成されたメッセージには、アプリケーションの制御に使用されるデータ及び命令が含まれており、前記受信されたメッセージには、前記アプリケーションからのデータが含まれている、プロキシと、
    前記定義ファイルに応答し、前記プロキシと前記アプリケーションの間でメッセージを中継するコントローラと、
    前記定義ファイルと、前記プロキシからの前記メッセージに応答し、前記アプリケーションに対して設定情報を提供すると共に、前記アプリケーションからデータを受信するハウジングと、
    を有する、ポーティング可能な分散アプリケーションフレームワーク。
13. 前記アプリケーションはプロトコル状態機械である、請求項１２記載のポーティング可能な分散アプリケーションフレームワーク。
14. 前記プロキシ、コントローラ、及びハウジングのそれぞれは、前記定義ファイルに基づいて内部データ構造を生成し、前記内部データ構造は、メッセージをインスタンス化するために使用される、請求項１２記載のポーティング可能な分散アプリケーションフレームワーク。
15. 前記プロキシ、コントローラ、及びハウジングのそれぞれには、メッセージを送受信するためのバッファが提供されており、前記バッファは、プッシュとプルを含む異なる通信タイプを実装するべく使用される、請求項１２記載のポーティング可能な分散アプリケーションフレームワーク。
16. 前記アプリケーションは、前記プロキシ、コントローラ、及びハウジングとは独立的に設計されている、請求項１２記載のポーティング可能な分散アプリケーションフレームワーク。
17. 前記フレームワークが第２アプリケーションとインタフェイスするために使用するデータ及び命令の構造を記述する第２定義ファイルと、
    前記定義ファイルと前記プロキシからの前記メッセージに応答し、前記第２アプリケーションに対して設定情報を提供すると共に、前記アプリケーションからデータを受信する第２ハウジングと、
    を更に有し、
    前記プロキシは、前記第２定義ファイルに応答し、前記定義ファイルに基づいてメッセージを生成及び受信し、前記生成されたメッセージには、前記第２アプリケーションを制御するために使用されるデータ及び命令が含まれており、前記受信されたメッセージには、前記第２アプリケーションからのデータが含まれており、前記コントローラは、前記第２定義ファイルに応答し、前記プロキシと前記第２アプリケーション間においてメッセージを中継する、
    請求項１２記載のポーティング可能な分散アプリケーションフレームワーク。
18. 定義ファイルに応答し、前記定義ファイルに基づいてメッセージを生成及び受信する第２プロキシをさらに有し、
    前記生成されたメッセージには、前記アプリケーションを制御するために使用されるデータ及び命令が含まれており、前記受信したメッセージには、前記アプリケーションからのデータが含まれている、
    請求項１２記載のポーティング可能な分散アプリケーションフレームワーク。
19. アプリケーションを制御する方法であって、
    前記アプリケーションとインタフェイスするためのデータ及び命令を記述する定義を生成するステップと、
    前記定義に基づいて構築されたメッセージを生成する汎用のインタフェイスを、前記定義を使用して設定するステップと、
    前記定義を使用して汎用のハウジングを設定するステップであって、前記ハウジングは、前記インタフェイスからメッセージを受信し、前記定義からデータと命令を抽出すると共に、前記データ及び命令を前記アプリケーションに提供し、前記ハウジングは、前記アプリケーションから受信したデータを前記定義に基づいてメッセージにカプセル化し、前記メッセージは、前記インタフェイスに伝送される、ハウジングを設定するステップと、
    を有する方法。
20. 前記アプリケーションはプロトコル状態機械である、請求項１８記載の方法。
21. リモートアプリケーションと通信する方法であって、
    前記リモートアプリケーションと通信するために使用するメッセージの構造を定義するステップと、
    前記定義された構造を中央コントローラと少なくとも２つのインタフェイスに提供するステップと、
    前記リモートアプリケーションに対してローカルな一連のバッファを生成し、前記インタフェイスからのメッセージを保持するステップであって、各バッファはメッセージのそれぞれのタイプごとに定義される、ステップと、
    前記インタフェイスに対してローカルな一連のバッファを生成し、前記リモートアプリケーションからのメッセージを保持するステップであって、各バッファは前記メッセージのそれぞれのタイプごとに定義される、ステップと、
    前記ユーザーインタフェイスに対してローカルに、前記定義されたメッセージ構造に基づいて、前記リモートアプリケーション用の第１メッセージを生成するステップと、
    前記リモートアプリケーションに対してローカルに、前記定義されたメッセージ構造に基づいて、前記インタフェイス用の第２メッセージを生成するステップと、
    前記第１メッセージを中央コントローラに伝送するステップと、
    前記第２メッセージを前記中央コントローラに伝送するステップと、
    前記メッセージのタイプに基づいて、前記中央コントローラ内において受信した前記メッセージをバッファリングするステップと、
    前記中央コントローラ内の前記バッファを、前記インタフェイスに対してローカルな前記バッファにミラーリングすることにより、それぞれのインタフェイス内の前記バッファの内容を前記中央コントローラ内の前記バッファと同期化させるステップと、
    前記中央コントローラが受信した前記第１メッセージを前記リモートアプリケーションに伝送するステップと、
    を有する方法。
22. 前記中央コントローラから前記リモートアプリケーションに送信された最近のメッセージの複写を保持するステップと、
    前記最近のメッセージの前記複写に加え、前記中央コントローラの前記バッファ内において前記メッセージをバックアップするステップと、
    必要な場合に、前記バックアップされたメッセージを回復するステップと、
    を更に有する、請求項２１記載の方法。
    

Images