JP2006033829A - ポーティング可能な分散アプリケーションフレームワーク - Google Patents
ポーティング可能な分散アプリケーションフレームワーク Download PDFInfo
- Publication number
- JP2006033829A JP2006033829A JP2005199534A JP2005199534A JP2006033829A JP 2006033829 A JP2006033829 A JP 2006033829A JP 2005199534 A JP2005199534 A JP 2005199534A JP 2005199534 A JP2005199534 A JP 2005199534A JP 2006033829 A JP2006033829 A JP 2006033829A
- Authority
- JP
- Japan
- Prior art keywords
- emulation
- protocol
- message
- application
- data
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L43/00—Arrangements for monitoring or testing data switching networks
- H04L43/50—Testing arrangements
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/14—Network analysis or design
- H04L41/145—Network analysis or design involving simulating, designing, planning or modelling of a network
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer And Data Communications (AREA)
- Stored Programmes (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
【課題】外部の定義ファイルに基づいて、アプリケーションとインタフェイスする汎用のフレームワークを提供する。
【解決手段】本発明は、様々なアプリケーションとインタフェイスすると共にそれらを制御するべく容易に適合可能なポーティング可能な分散アプリケーションフレームワークに関するものである。一般に、このフレームワークは、アプリケーションとインタフェイスするハウジングと、1つ又は複数のクライアントインタフェイスメカニズム(GUIなど)とインタフェイスするプロキシと、プロキシとハウジング間における通信を円滑に実行するコントローラと、を有している。これらのハウジング、プロキシ、及びコントローラのそれぞれは、同一の記述ファイルを使用して設定されている。この記述ファイルには、アプリケーションとインタフェイスしてこれを制御するべくフレームワークが使用するデータ構造及び命令の記述が含まれている。
【選択図】図3
【解決手段】本発明は、様々なアプリケーションとインタフェイスすると共にそれらを制御するべく容易に適合可能なポーティング可能な分散アプリケーションフレームワークに関するものである。一般に、このフレームワークは、アプリケーションとインタフェイスするハウジングと、1つ又は複数のクライアントインタフェイスメカニズム(GUIなど)とインタフェイスするプロキシと、プロキシとハウジング間における通信を円滑に実行するコントローラと、を有している。これらのハウジング、プロキシ、及びコントローラのそれぞれは、同一の記述ファイルを使用して設定されている。この記述ファイルには、アプリケーションとインタフェイスしてこれを制御するべくフレームワークが使用するデータ構造及び命令の記述が含まれている。
【選択図】図3
Description
本発明は、ネットワークシステムの試験デバイスに関する。
ルーターなどのネットワークデバイスは、誤伝送や致命的な誤りを極小化するべく集中的に試験される。市場においては、本出願の譲受人であるアジレント・テクノロジーズ(AGILENT TECHNOLOGIES)社のROUTER TESTERを含む様々な試験デバイスを入手可能である。これらの試験デバイスは、通常、様々な模擬入力に対するルーターの応答を監視する。
ルーティングプロセスとは、一言でいえば、ノードがすべての可能な宛先に対する経路を見出すことであると要約可能である。ルーティングは、レイヤ1(物理レイヤ)から上位のすべてのレイヤに存在している。但し、大部分の人々が慣れ親しんでいるルーティングは、レイヤ3(ネットワークレイヤ)において実行されるものであり、従って、本明細書においても、レイヤ3の(並びに、更に具体的には)IP(Internet Protocol)ルーティングのみを指すものとする。ルーターは、テーブルを使用し、パケットを転送する場所を判定する。これらのテーブルの更新は、ルーティングプロトコルによって実行される機能の1つである。それぞれのルーターは、1つ又は複数のプロトコルに応答して動作する。
ルーティング情報を交換するプロトコルにより、世界中の複数のルーターが接続され、それらの異質ではあるが一般的に一貫性を有しているルーティングテーブルによって、ネットワークの共通的なビューがそれらのルーターに提供される。ルーティングテーブルには、そのサイズとは無関係に、そのネットワーク上のすべての宛先に到達するためにルーターが必要とするすべての情報が保存されている。ネットワークのルーティングテーブルに寄与するべく使用されるルーティングプロトコルには、様々なものが存在している。BGP、OSPF、RIP、及びISISなどのプロトコルは、ネットワークの正しく且つ首尾一貫した構造をそのネットワーク上のすべてのルーターに対して伝達するのに有用である。
既存のルーターテスタにおいては、ネットワーク上に存在するライブデータの特色を示す特別に生成されたデータの「試験パケット」を使用してネットワークトラフィックをシミュレートしている。これらの試験パケットは、被検ネットワーク上においてネットワークデバイスに伝送される。トラフィックシミュレータシステム(これには、ROUTER TESTERが含まれる)によって試験されるパラメータには、ルーティングの検証、負荷下におけるQoS(Quality of Service)レベルの達成状況、及びその他のデバイスとの適正な連携が含まれる。又、これらの所謂「パケットブラスタ(Packet blaster)」の多くは、プロトコルに従ってデータを生成及び伝送することにより、そのプロトコルをそのネットワークデバイスが遵守する能力をも試験する。
図1は、トラフィックシミュレータ試験システム100のブロックダイアグラムである。具体的には、このトライフィックシミュレータ試験システム100は、アジレント・テクノロジーズ社が販売しているROUTER TESTERの概略的な表現になっている。ROUTER TESTERは、ルーター試験システムの一例であり、具体的には、エンタープライズ、メトロ/エッジ、コアルーティング、及び光学ネットワーキングデバイスの性能を検証するためのマルチポートトラフィック生成、プロトコルエミュレーション、及び分析試験システムとして宣伝されている。このシステムは、一般に、被検システム(これは、この場合には、ルーター104である)に接続された複数のプロトコルエミュレーションカード102nを有している。そして、これらのプロトコルエミュレーションカード102nのそれぞれは、一般に、関連するメモリ及びI/Oを具備するプロセッサを有している。これらのプロトコルエミュレーションカード102nは、WINDOWS環境が稼働するPCなどのコンピュータ106によって制御されている。そして、このコンピュータ106は、グラフィカルユーザーインタフェイスなどのインタフェイス108に応答して動作する。
プロトコルエミュレーションカード102nによって生成される試験パケットは、産業界の多くの規格団体によって定義されているものなどの通信プロトコルの規則及び解釈に従って構築される。使用されている通信プロトコルには、多くのものが存在しており、新しいプロトコルも継続的に開発されている。通常、新規のプロトコルは、当初、機器製造者によって開発され、その特性は、プロプライエタリ(proprietary、所有権を主張できる)である。そして、その後、多くの場合に、それらのプロトコルは、規格団体によって認可され、産業界において広範に実装されることになる。プロトコルエミュレーションカード102nは、プロトコル状態機械(protocol state machine)を使用して、対象のプロトコルに従って伝送用のデータを生成する。この状態機械の動作は、ルーター自体において使用されている状態機械と類似している。
トラフィックシミュレータ試験システムに関連する現在のソフトウェアアーキテクチャにおいては、グラフィカルユーザーインタフェイス、スクリプティングAPI、設定及び制御コンポーネント、並びにプロトコル状態機械自体を含むプロトコルエミュレーションソリューションのすべての部分をハードコーディングする必要がある。そして、このそれぞれのプロトコルに必要なハードコーディングのために、結果的に、大量のコードの生成に膨大な量の人的能力が使用されているのである。このコードの多くの部分は、コンピュータ106を、それぞれの新しいプロトコルエミュレーションカード102nとインタフェイスさせるために費やされている。
コンピュータ106をそれぞれの新しいプロトコルエミュレーションカード102nとインタフェイスさせる従来の方法においては、インタフェイスを作成しインタフェイス記述言語(Interface Description Language:IDL)によってハードコーディングする時点で、方法と関連パラメータが判明していることが必要である。そして、このような状況下において、新しいプロトコルエミュレーションが作成され、または古いプロトコルが拡張されるたびに、毎回、新しい方法及びパラメータが継続的に生成され、この結果、数百もの方法及びパラメータを含む巨大なAPI(Application Programming Interface)が生成され、結果的に、保守に費用を所要するコードの集合体が生成されているのである。又、既存の方法によれば、結果的に、APIがいくつかの異なるレイヤにおいて複製されることになり、この結果、これらの問題が更に悪化することになる。即ち、APIに対する個々の変更により、(それがどれほど小さなものであったとしても)システム内における大量のコード及び異なるレベルの更新が必要となるのである。又、この方法の副作用の1つは、それぞれのプロトコル及びそのそれぞれの更新ごとに、固有のGUI(Graphical User Inerface)を生成しなければならないことである。即ち、APIと同様に、プロトコルの数が増大するに伴って、必要なGUIの実装も増大することになるのである。
上述の問題のいくつかを軽減する汎用システムを設計するべく、現在、努力が傾注されている。その一例が、「Building packets of data」という名称の同時係属中の特許文献1に記述されている。この特許文献1(この内容は、本引用により、本明細書に包含される)においては、外部のプロトコルエミュレーション記述を使用し、汎用のPDU(Protocol Data Unit)エンコード/デコードエンジンを駆動している。従って、次のステップは、それぞれの新しいエミュレータ又はそれらの変更のたびに、新しいコード又はハードコーディングされたインタフェイスの変更を必要としないプロトコルエミュレータに対する汎用インタフェイスの構築である。
これに対する1つのアプローチは、プロトコルを制御するためのプロプライエタリなコンパイル済みの言語を開発する方法である。言語ステートメントを作成してホストコンピュータ上においてコンパイルし、この結果生成されるオブジェクトファイルを組み込み型ソフトウェアモジュールに配布して実行するのである。しかしながら、この方法によれば、開発されるそれぞれのプロトコルごとに、新しい言語ステートメントが必要となる。そして、これには、コンパイラの継続的な再作業が必要であり、これは、その特性が複雑であって、高度な技術を必要とする作業である。又、大規模な継続作業として、それぞれのプロトコルごとに、GUIの開発も残されることになる。
更なるアプローチは、従来どおりの非汎用的なアプリケーションフレームワークを開発する方法である。しかしながら、この方法においては、固定された所定のAPIの内部にプロトコルエミュレーションを構築するが必要となり、それぞれのプロトコルごとに、データ構造即ち、フレームワークを大幅にカスタマイズしなければならない。現実世界のプロトコルにおける経験によれば、これは、大規模なカスタマイズが必要であることを示すものであり、この方法は、結果的に満足のいくものではない。
米国特許出願第10/266,507号明細書
このようなことから、本発明者らは、フレームワークの外部に位置する定義ファイルに基づいて、アプリケーションとインタフェイスする汎用のフレームワークに対するニーズを認識するに至った。このフレームワークを異なるアプリケーションに適合させる際に必要とされるのは、フレーム自体の作り直しではなく、新しい定義ファイルの生成のみである。そして、プロトコル状態機械の場合には、このようなフレームワークにより、すべてのプロトコルエミュレーションをサポートする能力を有する汎用のGUIを含む複数のインタフェイス、汎用的な制御及び命令ホストコンポーネント、及び組み込み型デバイス上における汎用プロトコルハウジング(generic protocol housing)の使用が実現することになる。
本発明は、様々なアプリケーションとインタフェイスすると共にそれらを制御するべく容易に適合可能なポーティング可能な(portable、移植性のある)分散アプリケーションフレームワークに関するものである。一般に、このフレームワークは、アプリケーションとインタフェイスするハウジング(housing)と、1つ又は複数のクライアントインタフェイスメカニズム(GUIなど)とインタフェイスするプロキシと、プロキシとハウジング間における通信を円滑に実行するコントローラと、を有している。これらのハウジング、プロキシ、及びコントローラのそれぞれは、同一の(又は、恐らくその複写である)記述ファイルを使用して設定されている。この記述ファイルには、アプリケーションとインタフェイスしてこれを制御するべくフレームワークが使用するデータ構造及び命令の記述が含まれている。
添付の図面との関連で、本発明の特定の実施例に関する以下の詳細な説明を参照することにより、本発明について十分に理解することができよう。
尚、以下の説明においては、要素識別子に隣接して使用されている小文字の「n」は、要素番号に隣接した非イタリック体の文字を有する図面に示されている(又は、本明細書に記述されている)特定の要素ではなく、要素のグループ内における要素の非特定の例を表すものである。共通要素識別子を共有する要素のグループの場合には、隣接する文字を伴わないそのような要素識別子の使用は、その要素のグループ全体を示している。
次に、本発明の実施例を参照するが、それらの例は、添付の図面に示されており、これらの図面においては、類似の参照符号によってすべて類似の要素を示している。以下の詳細な説明においては、コンピュータ読取り可能媒体、関連プロセッサ、データ生成及び取得カード、並びにこれらに類似するものにおいて、ルーチン及びデータビット操作のシンボル表現によって実施可能な方法を提示している。尚、本明細書においては(並びに、一般的には)、ルーチンとは、所望の結果をもたらすステップ又は動作のシーケンスであると考えられ、従って、これには、「プログラム」、「オブジェクト」、「関数」、「サブルーチン」、及び「手順」などの専門用語が含まれている。これらの記述及び表現は、当業者が自らの研究の内容をその他の当業者に効果的に伝達するべく使用する手段である。又、わかりやすくするべく、本明細書及び請求項においては、「ネットワーク」という用語は、通信ネットワーク、ネットワークデバイス、その他の通信デバイス、並びに、データの試験パケットを使用して試験可能な通信システムの1つ又は複数の側面の中の1つ又は複数のものを意味するべく使用されている。
又、AGILENT ROUTER TESTERに類似した構成を具備するルーターテスタ上における実装を参照し、方法の実施例について説明するが、本明細書に開示する方法は、様々なルーターテスタの中のいずれのものにおいても動作可能である。より端的には、本明細書に開示されている方法は、特定のデバイスに関係した固有のものではなく、本明細書の開示内容によるルーチンと共に様々なデバイスを使用することができる。具体的には、デバイス間においてデータを転送するための本明細書に記述されている方法は、ルーターテスタ機能との関連において記述されているが、データ通信分野に一般的に適用することが可能である。又、本明細書に記述されている機能を実行可能な機械には、アジレント・テクノロジーズ社、ヒューレットパッカード社(HEWLETT PACKARD)、及びテクトロニクス社(TECTRONIX, INC.)、並びに通信機器のその他の製造者などの企業によって製造されるものが含まれる。
又、本明細書に記述されているソフトウェアに関連し、当業者であれば、本明細書に概説されている手順を実行するソフトウェアを生成するプラットフォーム及び言語には、様々なものが存在することを認識するであろう。本発明の実施例は、C++を含むCの多数の変形のいずれを使用しても実装可能である。但し、当業者であれば、好適なプラットフォーム及び言語の選択肢は、しばしば、構築する実際のシステムの詳細によって決定され、この結果、あるタイプのシステムにおいて機能可能なものが、別のシステムにおいては効果的ではない場合があることをも認識するであろう。又、本明細書に記述されているルーチン及び演算は、コンピュータ上においてソフトウェアとして実行されるものに限定されるものではなく、ハードウェアプロセッサ内においても実装可能であることを理解されたい。例えば、ルーチン及び演算は、ASICS内においてHDL(Hardware Design Language)により、或いは、様々な設計ツールを使用してFGPA内において実装することができよう。
概要
本発明は、様々なアプリケーションとインタフェイスすると共にそれらを制御するべく容易に適合可能なポーティング可能な(portable、移植性のある)分散アプリケーションフレームワークに関するものである。一般に、このフレームワークは、アプリケーションとインタフェイスするハウジングと、1つ又は複数のクライアントインタフェイスメカニズム(GUIなど)とインタフェイスするプロキシと、プロキシとハウジング間における通信を円滑に実行するコントローラと、を有している。これらのハウジング、プロキシ、及びコントローラのそれぞれは、同一の(又は、恐らくその複写である)記述ファイルを使用して設定されている。この記述ファイルには、アプリケーションとインタフェイスしてこれを制御するべくフレームワークが使用するデータ構造及び命令の記述が含まれている。尚、以下の説明においては、プロトコルエミュレーションソフトウェアのセッションとのインタフェイス及びこの制御に使用する実装に絞って本発明について説明することとするが、本発明は、このようなプロトコルエミュレーションソフトウェアに対する使用に限定されるものではなく、様々な(特に、リモートアプリケーションの管理が望ましい)環境において使用するのに適したものである。
本発明は、様々なアプリケーションとインタフェイスすると共にそれらを制御するべく容易に適合可能なポーティング可能な(portable、移植性のある)分散アプリケーションフレームワークに関するものである。一般に、このフレームワークは、アプリケーションとインタフェイスするハウジングと、1つ又は複数のクライアントインタフェイスメカニズム(GUIなど)とインタフェイスするプロキシと、プロキシとハウジング間における通信を円滑に実行するコントローラと、を有している。これらのハウジング、プロキシ、及びコントローラのそれぞれは、同一の(又は、恐らくその複写である)記述ファイルを使用して設定されている。この記述ファイルには、アプリケーションとインタフェイスしてこれを制御するべくフレームワークが使用するデータ構造及び命令の記述が含まれている。尚、以下の説明においては、プロトコルエミュレーションソフトウェアのセッションとのインタフェイス及びこの制御に使用する実装に絞って本発明について説明することとするが、本発明は、このようなプロトコルエミュレーションソフトウェアに対する使用に限定されるものではなく、様々な(特に、リモートアプリケーションの管理が望ましい)環境において使用するのに適したものである。
図2は、既存のプロトコルエミュレーションソフトウェアアーキテクチャ200aと、本発明の実施例によるプロトコルエミュレーションソフトウェアアーキテクチャ200bの説明に有用なブロックダイアグラムである。はじめに、既存のプロトコルエミュレーションソフトウェアアーキテクチャ200aについて説明する。プロトコルエミュレーションソフトウェアは、一般に、制御メカニズムを提供するGUI(Graphical User Interface)202と、命令コンポーネントを提供するOS(Operating System)204と、(例えば)カード102上においてプロトコルハウジングを形成する組み込み型ソフトウェア206と、という3つの別個の機能領域とやり取りする。既存のシステムにおいては、プロトコルエミュレーションソフトウェア208nには、特定のプロトコル用にカスタム作成されたコードの複合スイートが含まれている(例:OSPF(208a)、BGP4(208b)、RIP(208c)、及びIS−IS(208d))。換言すれば、それぞれのエミュレーション208nごとに、GUI202、OS204、及び組み込み型ソフトウェア206に対するカスタムインタフェイスを生成し、これらを統合しなければならないということである。
引き続き図2を参照して、本発明の実施例によるプロトコルエミュレーションソフトウェアアーキテクチャ200bについて説明する。本発明の実施例は、一般に、本明細書において汎用プロトコルフレームワーク(Generic Protocol Framework、GPF)210と呼ぶソフトウェアルーチンのスイート210を有している。このGPF210は、GUI202、OS204、及び組み込み型ソフトウェア206とインタフェイスしている。このGPF210は、すべてのプロトコルエミュレーション、汎用の制御及び命令ホストコンポーネント、及び組み込み型デバイス上における汎用のプロトコルハウジングをサポートする能力を有する汎用のGUIを実現している。特定の実施例に応じて、例えば、プロトコル状態機械などの図2に要素212nとして示されているプロトコルの特定の要素をカスタムコーディングすることが有益であろう。このような実装においては、フレームワーク210は、プロトコルエミュレータをサポートするサービスとプロトコル状態機械上に存在する制御レイヤを一般化するものである。但し、後述するように、このフレームワーク210のみを使用することにより、要素212nなどの組み込み型のカスタムコーティングによるコンポーネントを必要とすることなしに、完全なプロトコルエミュレーションを生成することが可能である。
尚、本明細書において使用するこの「汎用(Generic)」という用語は、それぞれの汎用コンポーネントが、特定のプロトコルエミュレーションの知識なしに作成されているという意味において使用されるものである。この目標を達成する1つの方法は、プロトコルエミュレーション定義ファイル214内のコンポーネントの外部において命令とデータ構造を定義する方法である。好適な実施例においては、このプロトコルエミュレーション定義ファイル214には、入力データストリームからエミュレーションパケットを選択するのに必要なハードウェアパターンマッチャと、ソケットパラメータとソケットオプションを含むエミュレーションによって使用されるTCP/IPソケットの詳細と、エミュレーションによって使用される命令、設定、及び結果データを記述するのに使用される汎用データ構造の組と、エミュレーションデータをユーザーに提示するためにGUIが必要とするフォーマッティング情報と、が記述されている。このプロトコル定義ファイル214を使用してデータ構造を生成し、このデータ構造を実行時に使用してGPF210を設定することにより、特定のプロトコルとやり取りすることができる。
一実施例においては、プロトコルエミュレーション定義ファイル214は、XMLタグを使用してサービスと制御データを編成する。例えば、ハードウェアパターンマッチフィルタの設定は、XMLの<filter>タグを使用して記述することができる。同様に、エミュレーションに必要なTCP/IPソケットの仕様は、<socket>タグを使用して作成可能である。エミュレータとの間で通信される命令及びデータ構造は、<parcel>タグを使用して記述することができる。そして、最後に、<emulation>タグを使用することにより、これらのタグによって参照されるデータをアセンブルすることができる。実行時には、このアセンブルされたデータを使用して、GPF210の様々なコンポーネントがアクセス可能なデータ構造を生成する。尚、本明細書においては、このデータ構造を参照モデル(reference model)と呼ぶ。プロトコルエミュレーション定義ファイル214に静的な値を保存し、参照モデル内にプリロードすることができる。又、ユーザー入力を必要とする1つ又は複数の動的な値を外部から供給し、<parcel>セクションに記述されているデータ構造に基づいて通信プロセスを使用してGPF210の適切なコンポーネントに伝達することも可能である。このシステム上で稼働するそれぞれのプロトコルエミュレーションのインスタンス(これは、「セッション」と呼ばれる)は、一般に、1つ又は複数の参照モデルにアクセスし、設定及び制御データを取得する。このシステム上において実現されるプロトコルエミュレーションのそれぞれのタイプごとに、1つの参照モデル(又は、参照モデルの組)を定義し生成することが有益であろう。
「DISTRIBUTED DATA MODEL」という名称の同時係属中の米国特許出願第10/851,303号明細書には、参照モデルの一般的な構造が適切なXMLの構文と共に提示されている。この米国特許出願第10/851,303号明細書は、<parcels>というタグに含まれるXML構文の特定のサブセットの詳細について主に記述している(このタグは、命令及び通信データ構造を記述するのに使用される)。尚、2004年5月21日付けで出願されたこの米国特許出願第10/851,303号は、本出願の譲受人に譲渡されており、本引用によって本明細書に包含される。本発明は、この米国特許出願第10/851,303号明細書に記述されている概念のいくつかをプロトコルエミュレーションソフトウェアのスイート全体に拡張するものである。本発明の更なる態様については、以下の詳細な説明と添付の請求項を参照することにより、明らかとなろう。
一実施例においては、GPF210は、汎用の自己文書化APIを更に有している。このようなAPIに関連する命令とパラメータは、ヘルプテキストと共に、プロトコルエミュレーション定義ファイル214内に記述することができる。この結果、フレームワークコードを作成することなしに、新しい命令を生成することが可能となる。Tcl(Tool control language)などのツールを使用することにより、XML及びTclによってプロトコルエミュレーション全体を定義し、このフレームワーク内において稼働させることができる。この結果、ユーザー及びサポート技術者は、サプライヤからのカスタムプロトコルモジュール(例:モジュール212n)の供給を待つことなしに、新しいプロトコルを即座に試験することができるようになる。このような汎用エミュレーションは、API及びGUIからは、通常のエミュレーションとまったく同一に見えることになる。尚、このような完全に汎用のソリューションには、性能の限界が存在しているが、「Time−to−market」ウィンドウが格段に改善されることになり、更に高い性能が必要な場合には、カスタムモジュールを提供することができる。
図3は、本発明の実施例によるターゲットプラットフォーム内に配備された汎用プロトコルフレームワーク300のブロックダイアグラムである。汎用プロトコルフレームワーク300(GPF300)は、一般に、エミュレーションコントローラ304、エミュレーションハウジング308n、プロキシコントローラ314nという3つのコンポーネントを有している。エミュレーションコントローラ304は、プロトコルセッション(図示されてはいないが、後述する)を管理するものであり、ホスト302上に存在している。一般に、エミュレーションコントローラ304は、セッションを生成並びに除去する。ホスト302は、一般に、WINDOWSオペレーティングシステムが稼働するPCなどのコンピュータを有している(但し、必ずしもこうである必要はない)。エミュレーションハウジング308nは、設定されたリソース及びセッションデータを提供するプロトコルセッションを収容する。このエミュレーションハウジング308nは、それぞれのプロトコルセッションごとに、エミュレーションコントローラ304に対する双方向のデータコンジット(conduit、経路)を提供する。そして、エミュレーションハウジングは、一般に、ポート306n上に存在している。それぞれのポート306nは、通常、プロトコルエミュレーションカード(図示されてはいない。図1の要素102nを参照されたい)上に存在している。プロキシコントローラ314nは、エミュレーションコントローラの命令及びデータに対するアクセスを提供することにより、エミュレーションコントローラ304の遠隔制御を円滑に実行する。プロキシコントローラ314nは、図示されているGUI310及びTcl API312を含む様々な機能コンポーネントに提供することができる。
それぞれのコンポーネントにプロトコルエミュレーション定義214nを提供する。一般に、これらのプロトコルエミュレーション定義214nは、あらゆる所与のプロトコルについて、すべて同一である。変化するのは、同一のプロトコルエミュレーション定義の組を特定のコンポーネントに提供するかどうかという点である。例えば、エミュレーションハウジング308nは、特定のポート306n上において実行されないプロトコルのプロトコルエミュレーション定義214nを必要とはしない。
後程詳述するように、これらのコンポーネントは、これらの定義から参照モデル316nを生成する。参照モデル316nは、それぞれのコンポーネントがその他のコンポーネントを設定し、実行すると共に、それらと通信することができるようにするデータを保存する。このデータには、データ構造、設定データ、データ通信構造(及び、実際には、メソッド)、命令、及びこれらの使用を促進するための前述の記述が含まれている。
少なくとも1つの実施例においては、エミュレーションコントローラ304との間の通信は、この参照モデル316n内に含まれている情報を使用して生成された(又は、インスタンス化された)メッセージを使用して実現されている。このようなメッセージ(これを「パーセル(parcel、小包、区画)」と呼ぶ)は、データ又は命令を格納することができる。この命令を使用してエミュレーションコントローラ304に指示することにより、プロトコルエミュレーションセッションの生成などの動作を実行する。そして、命令を遂行する情報や、エミュレーションコントローラ304との間でデータを報告するために必要な情報をデータとして含むことができる。具体的には、パーセルとは、データを伝達するために使用されるものであり、このデータには、参照モデルのその他のセグメント内において参照されているデータが含まれ、これには、例えば、<filter>及び<socket>タグに関連する情報が含まれている。
エミュレーションコントローラ
図4は、本発明の少なくとも1つの実施例によるエミュレーションコントローラ304の動作の説明に有用なブロックダイアグラムである。このエミュレーションコントローラ304は、例えば、GUI310(図3を参照されたい)などのクライアント420とインタフェイスするべく、API410を提供している。このAPI410は、クライアント420との間の命令とデータのやり取りのための主要コンジットを提供する。少なくとも1つの実施例によれば、クライアント420は、プロキシコントローラ314(図3を参照されたい)が提供されたデバイス又はソフトウェアを有することができる。
図4は、本発明の少なくとも1つの実施例によるエミュレーションコントローラ304の動作の説明に有用なブロックダイアグラムである。このエミュレーションコントローラ304は、例えば、GUI310(図3を参照されたい)などのクライアント420とインタフェイスするべく、API410を提供している。このAPI410は、クライアント420との間の命令とデータのやり取りのための主要コンジットを提供する。少なくとも1つの実施例によれば、クライアント420は、プロキシコントローラ314(図3を参照されたい)が提供されたデバイス又はソフトウェアを有することができる。
API410は、一般に、クライアント420とエミュレーションコントローラ304間におけるメッセージの生成及び伝送の責任を担っている。同様に、API412も、プロトコル状態機械422とエミュレーションコントローラ304間におけるコンジットとして機能するべく、エミュレーションハウジング308n内に提供されている。少なくとも1つの実施例においては(後述するように)、プロトコルエミュレーション定義ファイル214内の<parcel>タグ内に含まれているデータに基づいて、メッセージを生成する。このメッセージ生成プロセス(これは、同時係属中の米国特許出願第10/851,303号明細書に更に詳細に説明されている)は、基本的に、プロトコルエミュレーション定義ファイル214の内容に基づいた参照モデルの生成ステップと、これに続く参照モデル又はこの一部に基づいたオブジェクトのインスタンス化ステップと、を有している。そして、このオブジェクトに対して、プロトコルエミュレーション定義ファイル214、プロトコルエミュレーション定義ファイル214に基づいて生成された参照モデル、及びユーザーを含む任意の数のソースからのデータを入力する。APIの外部に位置する文書内においてデータ構造を事前に定義することにより、エミュレーション固有の規定を必要とすることなしに、APIを汎用的な方式で構築することができる。尚、汎用的なユーザーインタフェイスの実現やメッセージング帯域幅の低減などのその他の利益については、後述する。
API410が形成して伝送するメッセージは、様々な機能を実行する。それらの機能の1つが、セッションの生成、設定、及び除去である。前述のように、本明細書において使用するこの「セッション」という用語は、一般に、プロトコルエミュレーションのインスタンスを意味している。表1は、プロキシコントローラ314nに加え、API410及び412と共に使用するのに適したAPIの一部を形成するエミュレーションコントローラに対する管理インタフェイスを記述する自己文書化C++コードの一部である。
エミュレーションコントローラ304とエミュレーションハウジング308間の通信などの通信を円滑に実行するために、一連のバッファ404n(この例においては、バッファ404a〜404e)をエミュレーションコントローラ304内に生成することができる。そして、API412の管理下にあるエミュレーションハウジング308が、このエミュレーションコントローラ304内のバッファに対応する一連のバッファ404n(この例においては、バッファ404f〜404j)を生成する。ポートによってホスティングされているそれぞれのプロトコル状態機械ごとに、類似した一連のバッファを生成する。使用するバッファのタイプは、パーセルタイプにより、参照モデル316内において指定することができる。例えば、バッファタイプは、XMLパーセル定義内に属性として示すことができる。或いは、この代わりに、これをプロキシコントローラ314nなどのクライアントアプリケーションによって設定できるようにすることも可能であろう。これらのバッファ404nは、一般にシリアル通信経路を有しているパーセルリンク424によって接続されている。尚、図4には、図示されているパーセルタイプのそれぞれごとにマッチングバッファを提供した状態が示されているが、データのフローが単一方向の場合には、受信バッファのみを提供することも好ましいであろう。
これらのバッファ404の正確な特性は、本発明の所与の実装によって異なることになるが、エミュレーションコントローラ304とエミュレーションハウジング308n間において伝達されるパーセルのそれぞれのタイプごとに別個のバッファ404nを生成することが好ましいであろう。パーセルのタイプは、一般に、その中にカプセル化されるデータによって決定される。パーセル内のデータの使用方法に応じて有益なバッファのタイプには様々なものが存在する。従って、パーセルタイプごとに異なるバッファタイプを定義することが有益であろう。
一般に、バッファリングとは、受信(又は、送信)システムがパーセル内に含まれている情報を処理する準備が整うまで、パーセル(又は、そのセグメント)を一時的に保持することを意味している。例えば、クライアントは、ホストの負荷を極小化するべく、送信側のバッファからパーセルをプルすることができる。或いは、この代わりに、送信側は、受信側の様々なタイプのバッファにパーセルをプッシュすることにより、応答性を最適化することも可能である。バッファのタイプは、それぞれのパーセル及び/又はパーセルタイプごとに指定することができる。或いは、この代わりに、異なるバッファタイプからなるバンクを初期化し、バッファのタイプに基づいてメッセージをバッファ内に保管することも可能である。表2に、適切なバッファタイプのいくつかの例が示されている。
図4は、セッションデータ(Session Data)、統計(Statistics)、ルートプール(Route Pool)、ルートプールタイプ(Route Pool Type)、及びグローバル統計(Global Statistics)を含む特定のパーセルタイプごとのバッファの生成を示している。そして、表3には、いくつかの可能なパーセルタイプとそれらの適切なバッファタイプの更に詳細な説明が提供されている。
バッファとこれらのバッファの動作を円滑に実行するルーチンは、本明細書においては、パーセルストア(parcel store)402及び404と呼ぶ手順の組の一部を集合的に構成している。一実施例においては、これらのパーセルストア402及び404の機能コンポーネントは、それぞれAPI410及び412によって生成並びに維持されている。パーセルストアの更なる機能には、それからメッセージオブジェクトをインスタンス化することができるパーセル参照モデルの保存と維持も含まれている。パーセルオブジェクト自体をバッファ404に保存し、ここから取得する。表4は、パーセルストアの機能を記述する自己文書化C++コードの一部である。
パーセルストア402aは、エミュレーションハウジング308nに送信されたそれぞれのパーセルの最新の複写を保持するべく設定可能である。この設定を利用すれば、最も新しく転送されたパーセルを含むパーセルをパーセルストア402a内に保存することにより、エミュレーションコントローラ304の現在の設定を保存するバックアップ機能を実装することができる。このバックアップは、それぞれのアクティブセッションをシリアライズすることによって実現される。それぞれのアクティブセッションは、パーセルストア内のすべてのパーセルをシリアライズすることによってシリアライズする。そして、それぞれの保存されているセッションを再生成し、このセッションに回復されたパーセルを入力することにより、設定を回復することができる。
エミュレーションハウジング
エミュレーションハウジング308は、一般に、GPF210と、プロトコル状態機械308nなどの組み込み型カスタムコンポーネント間におけるインタフェイスとして機能する。エミュレーションハウジング308は、シリアライズされたパーセルの形態のメッセージを受信し、パーセルを再構築して、そのパーセル内のデータを組み込み型カスタムコンポーネントの各コンポーネントに配布する。同時に、エミュレーションハウジング308は、組み込み型カスタムコンポーネントの各コンポーネントからデータを受信し、それらに基づいてパーセルを生成し、このパーセルをエミュレーションコントローラ304に伝送する。プロトコルエミュレーションシステムの場合には、それぞれのセッションごとに、エミュレーションハウジング308nが提供され、次にこのハウジングが、エミュレーションコントローラ304と通信する。
エミュレーションハウジング308は、一般に、GPF210と、プロトコル状態機械308nなどの組み込み型カスタムコンポーネント間におけるインタフェイスとして機能する。エミュレーションハウジング308は、シリアライズされたパーセルの形態のメッセージを受信し、パーセルを再構築して、そのパーセル内のデータを組み込み型カスタムコンポーネントの各コンポーネントに配布する。同時に、エミュレーションハウジング308は、組み込み型カスタムコンポーネントの各コンポーネントからデータを受信し、それらに基づいてパーセルを生成し、このパーセルをエミュレーションコントローラ304に伝送する。プロトコルエミュレーションシステムの場合には、それぞれのセッションごとに、エミュレーションハウジング308nが提供され、次にこのハウジングが、エミュレーションコントローラ304と通信する。
図5は、本発明の実施例による汎用のプロトコルセッションモデルのブロックダイアグラムである。一般に、試験ポート上で稼働しているプロトコル状態機械(及び、関連するサポートコード)のインスタンスをセッションと呼ぶ。図5は、2つのポート306x及び306y上において稼働する8つのセッションS1〜S8を示している。これらのポート306n及びセッションSnは、テーブル502を維持するエミュレーションコントローラ304に応答して個々のセッションを追跡する。
エミュレーションコントローラ304は、それぞれのセッションごとにAPIサービスとバッファを提供する。前述のように、これらのAPI及びバッファは、エミュレーションコントローラ304とセッションSn間における通信を円滑に実行する。エミュレーションハウジング308m及び308nは、ポート306n上において稼働するそれぞれのセッションSnごとにAPIとバッファを提供する。エミュレーションハウジング308nは、指定されたポート306n上におけるセッションの生成及び除去の責任を担っている。
それぞれのセッションSnは、動作のために、いくつかのリソースを必要とする。これらのリソースには、ハードウェアパターンマッチ、その上で動作するためのソケット(TCP/IPソケットなど)、及び通信及び制御用のAPIが含まれる。図6は、本発明の実施例によるプロトコルインフラストラクチャのブロックダイアグラムである。この図6において、プロトコル状態機械602は、API604(これは、図4に示されているAPI412のインスタンスであってよい)、ソケットマネージャ606、及びマッチャ(matcher)マネージャ608と通信状態にあるものとして示されている。これらのAPI604、ソケットマネージャ606、及びマッチャマネージャ608は、エミュレーションハウジング308の一実施例を集合的に形成している(図3及び図4を参照されたい)。
起動時に、API604は、プロトコルエミュレーション定義ファイル610に基づいて参照モデルを生成する。このプロトコルエミュレーション定義ファイル610は、プロトコル定義ファイル214の複写であり、これは、API604の制御下において生成された参照モデルが、API410の制御下において生成された参照モデルと一致すること意味している。この結果、このAPI604は、インスタンス化されたパーセルのインスタンスを使用することにより、ホスト302上のエミュレーションコントローラ304(図3を参照されたい)と通信することができる。
API604は、エミュレーションコントローラ304からデータを受信し、エミュレーションハウジング及びプロトコル状態機械602のその他のコンポーネントにデータを配布する。同時に、API604は、エミュレーションハウジング308とプロトコル状態機械602のその他のコンポーネントからデータを受信し、エミュレーションコントローラ304に伝送する。このエミュレーションコントローラ304との通信は、前述の一連のパーセルストアとそれらに付随する前述のバッファを使用して実行することができる。
API604は、プロトコル状態機械602、マッチャマネージャ608、及びソケットマネージャ606に対する設定データの管理も行っている。一実施例においては、参照モデルは、特定のエミュレーションタイプのすべてのセッションに属する静的な情報を保存するべく設定されている。ソケットマネージャ606は、例えば、セッションデータパーセルを使用し、エミュレーションコントローラ304から送信された値を読み取ることにより、静的な情報を特定のセッションに属する動的情報と組み合わせる。セッションデータパーセル内の値を相互参照するべく、参照モデル内のソケット定義を設定することができる。
ソケットマネージャ606は、通信チャネルをセットアップし、これを維持する。図4に示されている例においては、ソケットマネージャ606は、TCP/IPスタック606aを維持している。エミュレーションハウジング308n内においてプロトコルエミュレーションセッションが有効になると、API604によって構築された参照モデルをチェックして、そのセッションに必要なソケット設定を検出する。そして、ソケットマネージャ606は、参照モデルを使用し、それぞれのソケットごとに、必要なソケットを構築する。ソケットは、セッション又はインタフェイスごとに個別に、或いは、そのハウジングについてグローバルに生成することができる。このため、ソケットマネージャ606は、複数のセッションによって共有されるソケットの参照カウントを維持している。例えば、グローバルソケットを使用する場合には、セッションによって最初に要求された際に、ソケットを生成する。そして、後続のセッションには、この既存のグローバルソケットを付与し、新しいものは生成しない。尚、このようなグローバルソケットは、そのソケットを使用しているすべてのセッションが無効になるか又は破棄された場合にのみ、破棄される。
エミュレーションマッチャマネージャ608は、ハードウェアマッチャを管理している(これは、「フィルタ」とも呼ばれる)。フィルタを使用することにより、被検ルーターからプロトコル状態機械602が受信したプロトコルメッセージの各メッセージ又はその一部を選択することができる。そして、選択したメッセージを分析及び報告のために保存することができる。2004年6月15日付けで出願された同時係属中の米国特許出願第10/861,618号明細書には、このようなフィルタの可能な一実装について記述されており、この内容は、本引用により、本明細書に包含される。エミュレーションハウジング308n内においてプロトコルエミュレーションセッションが有効になると、参照モデルをチェックし、セッションに必要なフィルタを検出する。マッチャマネージャ608(又は、フィルタマネージャ)は、それぞれのフィルタごとに、参照モデルを使用することにより、必要なフィルタを構築する。一般に、フィルタは、参照モデル内の静的情報によって完全に定義することができる。そして、フィルタは、同一タイプのすべてのセッションによって共有可能である。このため、マッチャマネージャ608は、参照カウントを維持し、特定のタイプの重複するフィルタを生成することによってハードウェアリソースが不必要に消費されないようにしている。そして、セッションが無効になった場合には、対応するフィルタは、そのフィルタを使用するすべてのセッションが無効になった場合にのみ除去される。
プロキシコントローラ
図3を参照すれば、プロキシコントローラ314nは、一般に、前述のものに類似したAPIと関連プロトコルエミュレーション定義ファイルを有している。このAPIにより、ホスト302上のエミュレーションコントローラ304との通信に便利なカプセル化されたソリューションが提供される。メッセージングがパーセルオブジェクトを使用して実現されることから、エミュレーションに対する制御は、パーセルオブジェクトを生成する能力を有するデバイス(例:適切なAPIを有するデバイス)であれば、どのようなものの内部にも配置することができる。この図3に示されている例の場合には、プロキシコントローラ314a及び314bは、GUI310及びTcl API312に提供されている。この組み込みにより、Tclスクリプトを使用したセッションの生成、設定、制御、及び削除を含むセッションの制御が可能となる。
図3を参照すれば、プロキシコントローラ314nは、一般に、前述のものに類似したAPIと関連プロトコルエミュレーション定義ファイルを有している。このAPIにより、ホスト302上のエミュレーションコントローラ304との通信に便利なカプセル化されたソリューションが提供される。メッセージングがパーセルオブジェクトを使用して実現されることから、エミュレーションに対する制御は、パーセルオブジェクトを生成する能力を有するデバイス(例:適切なAPIを有するデバイス)であれば、どのようなものの内部にも配置することができる。この図3に示されている例の場合には、プロキシコントローラ314a及び314bは、GUI310及びTcl API312に提供されている。この組み込みにより、Tclスクリプトを使用したセッションの生成、設定、制御、及び削除を含むセッションの制御が可能となる。
これらのプロキシコントローラ314は、表1に示されているIapfEmulationControlを実装することによって形成することができる。それぞれのプロキシコントローラ314nは、エミュレーションコントローラ304内のものと同一の参照モデル316nを維持している。そして、それぞれのプロキシコントローラ314nは、関連するエミュレーションコントローラ304に登録している。ハウジング308nからエミュレーションコントローラ304がパーセルを受信すると、パーセルは、そのまま、それぞれの登録されたプロキシコントローラ314nに転送される。同様に、プロキシコントローラ314nがパーセルをハウジング308nに送信した場合にも、それは、エミュレーションコントローラ304を介して送信されることになる。エミュレーションコントローラ304は、パーセルの複写を保持し、それを複写してその他のプロキシコントローラ314nに提供する。このようにして、エミュレーションコントローラ304及びすべてのプロキシコントローラ314nは、ミラーリングされたパーセルバッファの組404nを維持している(図4を参照されたい)。クライアントインタフェイスを駆動するのは、このパーセルバッファの組404nである。
Tclなどのスクリプト言語を使用すれば、プロトコル状態機械308nによって実行される機能を複写することができる。基本的に、XMLタグを使用して様々なプロトコルの状態を定義し、Tcl手順の組を定義214n内に組み込んで状態の変化を処理することになろう。到来するPDUストリームをデコードするためのデコードサービスライブラリと、送信するPDUストリームをエンコードするためのエンコードサービスライブラリをTclインタープリタに提供することができる。表6は、適切なTcl機能(注釈行に記載されているもの)との関連で、GPF210内のプロトコル状態機械の特定の機能を模倣するべく使用可能なXMLファイルである。
簡単なエミュレーション及び適合試験を提供するTclスクリプトを生成可能である。ポートが受信したプロトコルパケットをTcl API312のコントローラに伝達するべく、エミュレーションハウジング308nを設定する。同様に、Tcl API312が生成したプロトコルパケットを被検ネットワークに伝達するべく、エミュレーションハウジング308nを設定することができる。特許文献1に記述されているものなどのパケット構築ソフトウェアとインタフェイスするべく、このTcl API312を設定可能である。或いは、この代わりに、定義に基づいて設定可能な状態機械のフォーマットをプロトコルエミュレーション定義214に類似したものにすることにより、本発明の特定の概念をプロトコル状態機械に拡張することも可能である。
GUI
好適な実施例においては、GUI310は、表示上の要素のレイアウトがメッセージ参照モデル及びオブジェクトの構造に応答して動作する汎用的な方式で構築されている。図3を参照すれば、このGUI310は、表示するそれぞれのデータ片ごとに、その表示をフォーマッティングする方法を記述した属性を生成可能なプロトコルエミュレーション定義214nを使用して駆動される。同様に、ユーザーからの入力が必要な場合には、その入力を要求するデータ要素の属性を使用することにより、その入力を要求する表示をフォーマッティングすることができる。GUI310は、データのそれぞれの主要機能ブロックごとに、事前に設計及び構築されたダイアログを具備することが有利であろう。それぞれのブロックの表示のフォーマッティングは実装によって異なることになるが、それぞれのブロックにその独自のウィンドウを提供することが有利であろう。そして、GPFダイアログの具体的な内容(フィールドや列など)として、受信したデータが入力されることになる。
好適な実施例においては、GUI310は、表示上の要素のレイアウトがメッセージ参照モデル及びオブジェクトの構造に応答して動作する汎用的な方式で構築されている。図3を参照すれば、このGUI310は、表示するそれぞれのデータ片ごとに、その表示をフォーマッティングする方法を記述した属性を生成可能なプロトコルエミュレーション定義214nを使用して駆動される。同様に、ユーザーからの入力が必要な場合には、その入力を要求するデータ要素の属性を使用することにより、その入力を要求する表示をフォーマッティングすることができる。GUI310は、データのそれぞれの主要機能ブロックごとに、事前に設計及び構築されたダイアログを具備することが有利であろう。それぞれのブロックの表示のフォーマッティングは実装によって異なることになるが、それぞれのブロックにその独自のウィンドウを提供することが有利であろう。そして、GPFダイアログの具体的な内容(フィールドや列など)として、受信したデータが入力されることになる。
主要機能ブロックの適切なリストの一例には、セッションマネージャ、セッションエディタ、トポロジーエディタ、セッション統計、セッションログ、及びメッセージトレースが含まれる。セッションマネージャブロックには、セッションの生成、削除、有効化、及び無効化用のデータと、セッション状態及びサマリ情報のビューを含むことができよう。セッションエディタブロックには、SUTアドレス、オプション、及びタイマなどのセッショングローバルデータの生成、参照、及び編集用のデータを含むことができよう。トポロジーエディタブロックには、シミュレートされたルートまたはルーターなどのセッショントポロジーのビューを生成するためのデータを含むことができよう。又、トポロジーエディタブロックには、命令の送信やエミュレーションセッション内へのPDUの注入の機能を含むこともできる。セッション統計ブロックは、それぞれのセッションタイプに関するリアルタイムの統計のビューを提供することができよう。セッションログブロックは、それぞれのセッションによって生成されたイベントメッセージのビューを提供することができよう。そして、最後に、メッセージトレースブロックは、それぞれのセッションによって送受信されるメッセージのライブメッセージトレースのビューを提供することができよう。
プロトコルエミュレーション定義
本発明の実施例の基礎をなす概念は、論理的にGPF210の外部においてプロトコルエミュレーション定義を使用するという点にあろう。図7は、本発明の実施例による汎用プロトコルフレームワークにおいて使用するのに適したXMLタグ階層構造の図である。本発明の特定の実施例によれば、この図7に示されているXMLタグ階層構造を使用することにより、プロトコルエミュレーション定義ファイルに基づいて参照モデルを形成している。尚、プロトコルエミュレーション定義は、XMLでフォーマッティングするものとして説明しているが、当業者であれば、その他のフォーマットも使用可能であることを認識するであろう。具体的には、その生成及び変更を円滑に実行するべく容易にアクセス可能なフォーマットでプロトコルエミュレーション記述をフォーマッティングすることが望ましい。
本発明の実施例の基礎をなす概念は、論理的にGPF210の外部においてプロトコルエミュレーション定義を使用するという点にあろう。図7は、本発明の実施例による汎用プロトコルフレームワークにおいて使用するのに適したXMLタグ階層構造の図である。本発明の特定の実施例によれば、この図7に示されているXMLタグ階層構造を使用することにより、プロトコルエミュレーション定義ファイルに基づいて参照モデルを形成している。尚、プロトコルエミュレーション定義は、XMLでフォーマッティングするものとして説明しているが、当業者であれば、その他のフォーマットも使用可能であることを認識するであろう。具体的には、その生成及び変更を円滑に実行するべく容易にアクセス可能なフォーマットでプロトコルエミュレーション記述をフォーマッティングすることが望ましい。
ファイルの好ましいデータ構造は、階層構造であり、この場合に、それぞれのノードは、値、サブノード、関数、値の配列、又は値の表を格納することができる。XMLが提供するネストタグ構造により、階層構造関係及び表構造の文書化が円滑に実行される。メッセージ定義は、機能ユニットのリストを提供すると共に、それぞれの機能ユニットを構成する要素(本明細書においては、これを「ノード」と呼ぶ)、それぞれのノードのタイプ、及びノードの相互関係を規定するテキストファイルと同程度に簡単なものであってよい。それぞれのノードには、記述属性を使用して注釈を付加することができる(この例について後述する)。
エミュレーション定義ファイルのそれぞれのセクションは、ヘッダと、要素の組を有することができる。要素は、一般に、構造を定義するコンテナ要素と、1つ又は一連の値を保存するデータ要素という2つのカテゴリに分けられる。XMLタグを使用することにより、これらのヘッダ及び要素を編成することができる。例えば、単一タイプのプロトコルエミュレーションに必要なデータ及び命令は、<emulationset>タグ内においてカプセル化することができる。そして、<emulationset>タグ内において、それらの要素をその機能に基づいて更に編成することができる。図7を参照すれば、1つの可能な組織体系が示されており、この場合には、要素は、<parcel>、<command>、<filter>、<emulation>、及び<enumset>というタグを使用してカプセル化されている。
<parcel>セクションの形態とフォーマットについては、同時係属中の米国特許出願第10/851,303号明細書に記述されている。そして、<command>セクションは、<parcel>セクションと同一の基本フォーマットを踏襲している。表7には、この<parcel>メッセージセグメント用の要素タイプの組の例が示されている。
APIが使用する命令もXML定義を使用して定義することができる。これは、間接化のレベルを追加することによって実現可能であり、この結果、数百もの多数のプロトコル固有の命令を具備するAPIの代わりに、API自体は、いくつかの汎用命令を提供することになる。例えば、表8に記述されている命令は、ユーザーがプロトコル定義内に定義されている命令を識別して起動することを可能にする最小限の命令の組を表している。
この単純なケースにおいては、必要なパラメータは、1つ又は複数の値として定義されている。その他の状況においては、命令パラメータをパーセル内の表の行として定義することが有用である(例:表10を参照されたい)。
この例の場合には、「routePools」と呼ばれるパーセルが既に定義されていることを前提としている(このパーセルは、それぞれの行が個々のルートプールを表す表である)。この「advertise」命令は、ルートプールに対して作用するものであり、「rowRef」属性を使用することによって、これら2つを関連付けている。
この命令のスタイルによれば、ユーザーは、ルートプールテーブル内の行を選択し、「advertise」をクリックすることができる。このスタイルは、GUIに非常に有用であり、この命令定義によれば、適切な命令とパラメータを自動的に関連付けることができる。
同時係属中の米国特許出願第10/861,618号明細書には、<filter>セクションの1つの可能な実装について記述されている。一実施例においては、<filter>用に、<hwMatch>という単一のタグを定義している。フィルタは、一般に、事前に定義されたビットストリームとしてフォーマッティングされるため、<hwMatch>は、実装されたエミュレーションマッチャに直接対応する(2進又は16進の)ビットストリームを格納している。一例として、AGILENT ROUTERTESTER 900用の<hwMatch>パラメータは、IPプロトコルIDと、IPペイロードの最初の32ビット、並びに関連するマスクである。要すれば、<hwMatch>タグのペイロードは、ハードウェアインタフェイスをプログラムするのに必要なデータを格納しているに過ぎない。
<emulation>セクションは、特定のプロトコルエミュレーションに属する<socket>及び<parcel>タグを格納している。又、<emulation>は、<emulation>の外部において定義されている1つ又は複数のフィルタを参照することもできる。
<enumSet>は、名前/値ペアの表であり、これは、有意な名前を特定の値又は値の範囲にマッピングするために使用する。これは、未加工の値を有意な値と並べて提示することが好ましいデータをGUIで提示する際に、特に有用である。又、このenumSetの概念を拡張することにより、パーセル又はパーセル値が特定の値に基づいて相互参照できるようにすることも可能である。表13には、<enum>の組の例が示されている。
ここでは、例えば、「1」という特定の値を「Route Pool」という名前と、そして、パーセルにもマッピングしている。これは、例えば、トポロジーアイテムの要約表を一覧表示するGUIにおいて使用することができよう。表内の行を選択することにより、ユーザーは、そのトポロジータイプに応じて参照されたパーセルから抽出された詳細なデータを見ることができる。
それぞれの要素には、記述属性を使用して注釈を付加することができる。この属性により、要素が文書化され、メッセージ定義を自己文書化することができる。この属性をメッセージ定義及び(場合によって)メッセージ参照モデルと共に保存することにより、メッセージの操作並びにこれらとのインタフェイスのために提供するルーチンの特性を汎用的なものにすることができる(例:ルーチン内においてデータ構造を定義するのではなく、データ構造を実行時に提供する)。例えば、これらの属性を使用することにより、汎用グラフィカルユーザーインタフェイスを使用してメッセージ又はセグメントを提示及び編集するのに必要なすべての情報を提供することができる。表14には、可能な属性のいくつかの例が示されている。当業者であれば、表14に含まれているリストがすべてを網羅するものではないことを認識するであろう(本発明の実装に応じて、その他の属性も有益であろう)。
しばしば、定義の内外において指定されるその他の値によって変化する要素の既定値を設定することが必要となる。このようなケースにおいては、このタスクを実行するべく起動可能なTCL(Tool Command Language)手順を内蔵することが有益であろう。この機能は、プロトコルエミュレーション定義ファイル内において指定することができる。尚、当業者であれば、このようなTCLの内蔵を実行することは可能であるため、この内蔵の具体的な詳細については、本明細書においてはその説明を省略する。表16には、TCL機能を内蔵するパーセル定義の一部の例が示されている。
この例においては、keepaliveの既定値は、holdTimerにどのような値が設定された場合にも、holdTimerの2倍になるように維持されている。これらのTCL機能は、パーセルをインスタンス化する際に(例:パーセルのインスタンスを生成する際に)実行することができる。又、メッセージ定義及び/又はモデルをレビューし、実行時にこの機能の影響を受けた値を更新するべく、ルーチンを生成することも可能である。
図3を参照すれば、プロトコルエミュレーション定義は、ホスト302上に保存しておき、エミュレーションコントローラ304によって実行時に取得することができる。同様に、ホスト302と通信するリモートプロセス(例:ポート306n、GUI310、及びTcl API312)にも、これらのプロトコルエミュレーション定義の複写を提供可能である。
実行時には、プロトコルエミュレーション定義を解析して参照モデルを生成する。一般に、参照モデルは、C++などによるデータ構造である。この参照モデルは、2つの機能をサービスする。第1の機能は、システムの様々な機能要素が参照するデータを保持することである。そして、第2の機能は、エミュレーションコントローラ304との間のデータの伝達に使用するパーセルを生成するためのモデルとして機能することである。このようなパーセルは、プロトコルエミュレーション定義のインスタンス(又は、その1つ又は複数のセグメント)を有することができる。恐らく、参照モデルに最も近い類似の構造は、C++のジェネリックタイプ(Generic Type)であろう。1つの違いは、ジェネリックタイプは、コンパイル時に定義しなければならないが、参照モデルの場合には、実行時に導入することができるという点にある。本発明の少なくとも1つの実施例においては、パーセルを導出する元となる参照モデルにおいてタイプを定義している。尚、使用の際には、稼働の際に必要となる可能性のあるすべての潜在的なパーセルの参照モデルを生成するべく、システムの起動時にすべてのプロトコルエミュレーション定義を解析することが有益であろう。但し、時間とストレージを考慮する必要がある場合には、現在のセッションに必要となる可能性が高い参照モデルのみを生成することを推奨する。
GPF210のそれぞれの主要な要素(例:エミュレーションコントローラ304、エミュレーションハウジング306n、及びプロキシコントローラ314n)は、プロトコルエミュレーション定義214の複写を具備する必要がある。これは、プロトコルエミュレーション定義214を1つの要素(通常は、エミュレーションコントローラ304)に提供し、次いで、その複写をその他の要素に配布することによって実現することができる。これを実現可能な1つの方式は、パーセルストアの設定及び動作を実現するブートストラップ定義ファイルをGPF210のそれぞれの要素に対して手動で提供する方法である。その後、システムを初期化する際に、それらをパーセル内にカプセル化し、パーセルストア402nを使用して伝送することにより、パーセルストアを使用してプロトコルエミュレーション定義ファイル214の現在の組を伝送することができる。
パーセルリンク
前述のように、エミュレーションコントローラ304との間の通信は、好ましくは、同時係属中の米国特許出願第10/851,303号明細書に記述されているパーセルの概念に基づいて事前定義されたメッセージングフォーマットによって実行される。そして、これらのパーセルは、パーセルリンク424(図4を参照されたい)の概念を使用して伝送可能である。
前述のように、エミュレーションコントローラ304との間の通信は、好ましくは、同時係属中の米国特許出願第10/851,303号明細書に記述されているパーセルの概念に基づいて事前定義されたメッセージングフォーマットによって実行される。そして、これらのパーセルは、パーセルリンク424(図4を参照されたい)の概念を使用して伝送可能である。
パーセルリンク424は、バイトストリングを単純に送受信する簡単なインタフェイスから構成することにより、必要に応じてシリアルインタフェイスやその他のタイプのネットワーク上に簡単に実装できるようにすることができる。尚、物理的な実装の詳細は、GPFにとってトランスペアレントにする必要があるが、更なる説明は省略する。
パーセルを伝送する1つの方法は、構造からデータを抽出することによってパーセル内のデータをシリアライズする方法である。受信側において、このバイナリストリームをデコードし、パーセルを再生成するのに使用可能な参照モデル(又は、この一部)を識別できるように、十分なデータ構造を提供する必要がある。この再構築の際には、参照モデル内に含まれている構造情報を使用し、バイナリストリーム内のデータを解析することができる。従って、このシリアライズされたメッセージの受信者には、適切なメッセージ定義の複写を提供する必要がある。受信者は、このメッセージ定義を解析し、参照モデルを生成しなければならない(この参照モデルは、参照モデル204aの複写である)。そして、シリアライズされたメッセージを受信した際に、受信者は、この参照モデル(又は、その一部)をインスタンス化し、この結果生成されるデータ構造に対してそのバイナリデータを入力することによってメッセージオブジェクトを形成し、これにより、メッセージオブジェクトを再生成する。
結論
要すれば、本発明は、汎用プロトコルエミュレーションの可能性を実現するものであり、プロトコルエミュレーションの全体をXML及びTclによって定義し、フレームワーク内において稼働させることができる。この結果、顧客及びサポート技術者は、サプライヤからのプロトコルモジュールの供給を待つことなしに、新しいプロトコルを即座に試験することができるようになる。このような汎用エミュレーションは、API及びGUIからは、組み込み型エミュレーションとまったく同一に見えることになるが、性能に限界が存在している。しかしながら、「Time−to−market」ウィンドウが改善され、必要に応じて、高性能の組み込み型エミュレーションソリューションによってフォローアップする機会を提供している。スタンドアロンフレームワークを様々なターゲットプラットフォーム内に容易に配備可能である。プロトコルモジュールは、自己完結型のGPF環境において開発及び試験し、GPFを配置するどのようなプラットフォームにも配置することができる。このGPFは、3つのGPFコンポーネントの柔軟なスター型の結線特性と、これらのコンポーネントを1つに接続するのに使用される非常に単純な非同期のparcelLink APIにより、様々なターゲットプラットフォームに、そして、場合によっては、分散環境にも容易に配備することが可能である。
要すれば、本発明は、汎用プロトコルエミュレーションの可能性を実現するものであり、プロトコルエミュレーションの全体をXML及びTclによって定義し、フレームワーク内において稼働させることができる。この結果、顧客及びサポート技術者は、サプライヤからのプロトコルモジュールの供給を待つことなしに、新しいプロトコルを即座に試験することができるようになる。このような汎用エミュレーションは、API及びGUIからは、組み込み型エミュレーションとまったく同一に見えることになるが、性能に限界が存在している。しかしながら、「Time−to−market」ウィンドウが改善され、必要に応じて、高性能の組み込み型エミュレーションソリューションによってフォローアップする機会を提供している。スタンドアロンフレームワークを様々なターゲットプラットフォーム内に容易に配備可能である。プロトコルモジュールは、自己完結型のGPF環境において開発及び試験し、GPFを配置するどのようなプラットフォームにも配置することができる。このGPFは、3つのGPFコンポーネントの柔軟なスター型の結線特性と、これらのコンポーネントを1つに接続するのに使用される非常に単純な非同期のparcelLink APIにより、様々なターゲットプラットフォームに、そして、場合によっては、分散環境にも容易に配備することが可能である。
Claims (22)
- プロトコルエミュレーション定義によって設定され、前記プロトコルエミュレーション定義ファイル内に含まれたデータに従ってプロトコルエミュレーションセッションを起動する少なくとも1つのエミュレーションハウジングと、
前記プロトコルエミュレーション定義によって設定され、前記エミュレーションハウジングによって生成された前記セッションに関係するデータを表示し、ユーザーからの命令と設定データのエントリを円滑に実行するインタフェイスであって、前記命令及び設定データは、前記エミュレーションハウジングに伝送され、その挙動を変更する、インタフェイスと、
プロトコルエミュレーション定義を配布し、前記エミュレーションハウジングと前記インタフェイス間におけるデータ及び命令のコンジットとして機能するエミュレーションコントローラと、
を有するプロトコルエミュレーションシステム。 - 前記エミュレーションハウジングは、前記プロトコルエミュレーション定義ファイルを使用し、動作の際に使用されるデータを保存するデータ構造を構築する、請求項1記載のプロトコルエミュレーションシステム。
- 前記インタフェイスは、前記プロトコルエミュレーション定義ファイルを使用し、動作の際に使用されるデータを保存する参照モデルを構築する、請求項1記載のプロトコルエミュレーションシステム。
- 前記エミュレーションハウジングは、前記プロトコルエミュレーション定義ファイルを使用し、動作の際にデータを保存する参照モデルを構築する、請求項3記載のプロトコルエミュレーションシステム。
- 前記インタフェイスは、前記参照モデルを使用し、前記エミュレーションハウジング用のメッセージをインスタンス化する請求項4記載のプロトコルエミュレーションシステム。
- 前記エミュレーションハウジングは、前記参照モデルを使用し、前記インタフェイス用のメッセージをインスタンス化する、請求項4記載のプロトコルエミュレーションシステム。
- 前記エミュレーションハウジングと通信状態にあり、プロトコルメッセージを生成しこれに応答するプロトコル状態機械を更に有する、請求項1記載のプロトコルエミュレーションシステム。
- プロトコルメッセージを生成しこれに応答する方法を記述するスクリプトを更に有し、
前記エミュレーションハウジングは、受信したプロトコルメッセージを前記スクリプトに伝達すると共に、前記スクリプトによって生成された応答を被検ネットワークに伝送する、
請求項1記載のプロトコルエミュレーションシステム。 - 前記インタフェイスは、前記プロトコルエミュレーション定義内に含まれた情報に基づいて表示を生成するグラフィカルユーザーインタフェイスを有する、請求項1記載のプロトコルエミュレーションシステム。
- 前記インタフェイスはテキストである、請求項1記載のプロトコルエミュレーションシステム。
- 前記インタフェイスはスクリプト言語を使用して生成される、請求項1記載のプロトコルエミュレーションシステム。
- ポーティング可能な分散アプリケーションフレームワークであって、
前記フレームワークがアプリケーションとインタフェイスするために使用するデータ及び命令の構造を記述する定義ファイルと、
前記定義ファイルに応答し、前記定義ファイルに基づいてメッセージを生成及び受信するプロキシであって、前記生成されたメッセージには、アプリケーションの制御に使用されるデータ及び命令が含まれており、前記受信されたメッセージには、前記アプリケーションからのデータが含まれている、プロキシと、
前記定義ファイルに応答し、前記プロキシと前記アプリケーションの間でメッセージを中継するコントローラと、
前記定義ファイルと、前記プロキシからの前記メッセージに応答し、前記アプリケーションに対して設定情報を提供すると共に、前記アプリケーションからデータを受信するハウジングと、
を有する、ポーティング可能な分散アプリケーションフレームワーク。 - 前記アプリケーションはプロトコル状態機械である、請求項12記載のポーティング可能な分散アプリケーションフレームワーク。
- 前記プロキシ、コントローラ、及びハウジングのそれぞれは、前記定義ファイルに基づいて内部データ構造を生成し、前記内部データ構造は、メッセージをインスタンス化するために使用される、請求項12記載のポーティング可能な分散アプリケーションフレームワーク。
- 前記プロキシ、コントローラ、及びハウジングのそれぞれには、メッセージを送受信するためのバッファが提供されており、前記バッファは、プッシュとプルを含む異なる通信タイプを実装するべく使用される、請求項12記載のポーティング可能な分散アプリケーションフレームワーク。
- 前記アプリケーションは、前記プロキシ、コントローラ、及びハウジングとは独立的に設計されている、請求項12記載のポーティング可能な分散アプリケーションフレームワーク。
- 前記フレームワークが第2アプリケーションとインタフェイスするために使用するデータ及び命令の構造を記述する第2定義ファイルと、
前記定義ファイルと前記プロキシからの前記メッセージに応答し、前記第2アプリケーションに対して設定情報を提供すると共に、前記アプリケーションからデータを受信する第2ハウジングと、
を更に有し、
前記プロキシは、前記第2定義ファイルに応答し、前記定義ファイルに基づいてメッセージを生成及び受信し、前記生成されたメッセージには、前記第2アプリケーションを制御するために使用されるデータ及び命令が含まれており、前記受信されたメッセージには、前記第2アプリケーションからのデータが含まれており、前記コントローラは、前記第2定義ファイルに応答し、前記プロキシと前記第2アプリケーション間においてメッセージを中継する、
請求項12記載のポーティング可能な分散アプリケーションフレームワーク。 - 定義ファイルに応答し、前記定義ファイルに基づいてメッセージを生成及び受信する第2プロキシをさらに有し、
前記生成されたメッセージには、前記アプリケーションを制御するために使用されるデータ及び命令が含まれており、前記受信したメッセージには、前記アプリケーションからのデータが含まれている、
請求項12記載のポーティング可能な分散アプリケーションフレームワーク。 - アプリケーションを制御する方法であって、
前記アプリケーションとインタフェイスするためのデータ及び命令を記述する定義を生成するステップと、
前記定義に基づいて構築されたメッセージを生成する汎用のインタフェイスを、前記定義を使用して設定するステップと、
前記定義を使用して汎用のハウジングを設定するステップであって、前記ハウジングは、前記インタフェイスからメッセージを受信し、前記定義からデータと命令を抽出すると共に、前記データ及び命令を前記アプリケーションに提供し、前記ハウジングは、前記アプリケーションから受信したデータを前記定義に基づいてメッセージにカプセル化し、前記メッセージは、前記インタフェイスに伝送される、ハウジングを設定するステップと、
を有する方法。 - 前記アプリケーションはプロトコル状態機械である、請求項18記載の方法。
- リモートアプリケーションと通信する方法であって、
前記リモートアプリケーションと通信するために使用するメッセージの構造を定義するステップと、
前記定義された構造を中央コントローラと少なくとも2つのインタフェイスに提供するステップと、
前記リモートアプリケーションに対してローカルな一連のバッファを生成し、前記インタフェイスからのメッセージを保持するステップであって、各バッファはメッセージのそれぞれのタイプごとに定義される、ステップと、
前記インタフェイスに対してローカルな一連のバッファを生成し、前記リモートアプリケーションからのメッセージを保持するステップであって、各バッファは前記メッセージのそれぞれのタイプごとに定義される、ステップと、
前記ユーザーインタフェイスに対してローカルに、前記定義されたメッセージ構造に基づいて、前記リモートアプリケーション用の第1メッセージを生成するステップと、
前記リモートアプリケーションに対してローカルに、前記定義されたメッセージ構造に基づいて、前記インタフェイス用の第2メッセージを生成するステップと、
前記第1メッセージを中央コントローラに伝送するステップと、
前記第2メッセージを前記中央コントローラに伝送するステップと、
前記メッセージのタイプに基づいて、前記中央コントローラ内において受信した前記メッセージをバッファリングするステップと、
前記中央コントローラ内の前記バッファを、前記インタフェイスに対してローカルな前記バッファにミラーリングすることにより、それぞれのインタフェイス内の前記バッファの内容を前記中央コントローラ内の前記バッファと同期化させるステップと、
前記中央コントローラが受信した前記第1メッセージを前記リモートアプリケーションに伝送するステップと、
を有する方法。 - 前記中央コントローラから前記リモートアプリケーションに送信された最近のメッセージの複写を保持するステップと、
前記最近のメッセージの前記複写に加え、前記中央コントローラの前記バッファ内において前記メッセージをバックアップするステップと、
必要な場合に、前記バックアップされたメッセージを回復するステップと、
を更に有する、請求項21記載の方法。
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US10/893,668 US7467078B2 (en) | 2004-07-16 | 2004-07-16 | Portable distributed application framework |
Publications (1)
Publication Number | Publication Date |
---|---|
JP2006033829A true JP2006033829A (ja) | 2006-02-02 |
Family
ID=34912808
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2005199534A Pending JP2006033829A (ja) | 2004-07-16 | 2005-07-08 | ポーティング可能な分散アプリケーションフレームワーク |
Country Status (6)
Country | Link |
---|---|
US (1) | US7467078B2 (ja) |
EP (1) | EP1617625A3 (ja) |
JP (1) | JP2006033829A (ja) |
CN (1) | CN1722681A (ja) |
DE (1) | DE102005016032A1 (ja) |
GB (1) | GB0514689D0 (ja) |
Families Citing this family (31)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7814198B2 (en) | 2007-10-26 | 2010-10-12 | Microsoft Corporation | Model-driven, repository-based application monitoring system |
US20080059954A1 (en) * | 2002-06-18 | 2008-03-06 | Martin Joseph B | Universal system component emulator with human readable output |
US9332069B2 (en) * | 2012-12-28 | 2016-05-03 | Wandisco, Inc. | Methods, devices and systems for initiating, forming and joining memberships in distributed computing systems |
US7793268B2 (en) * | 2006-08-28 | 2010-09-07 | International Business Machines Corporation | Method, system, and program product for composing a virtualized computing environment |
AU2008239477B2 (en) * | 2007-03-29 | 2010-08-05 | Irobot Corporation | Robot operator control unit configuration system and method |
US8024396B2 (en) * | 2007-04-26 | 2011-09-20 | Microsoft Corporation | Distributed behavior controlled execution of modeled applications |
US8316351B2 (en) * | 2007-05-07 | 2012-11-20 | Microsoft Corporation | Utilizing a schema for documenting managed code |
US8239505B2 (en) * | 2007-06-29 | 2012-08-07 | Microsoft Corporation | Progressively implementing declarative models in distributed systems |
US7970892B2 (en) * | 2007-06-29 | 2011-06-28 | Microsoft Corporation | Tuning and optimizing distributed systems with declarative models |
US8230386B2 (en) | 2007-08-23 | 2012-07-24 | Microsoft Corporation | Monitoring distributed applications |
US8099720B2 (en) | 2007-10-26 | 2012-01-17 | Microsoft Corporation | Translating declarative models |
US7974939B2 (en) | 2007-10-26 | 2011-07-05 | Microsoft Corporation | Processing model-based commands for distributed applications |
US7926070B2 (en) | 2007-10-26 | 2011-04-12 | Microsoft Corporation | Performing requested commands for model-based applications |
US8181151B2 (en) * | 2007-10-26 | 2012-05-15 | Microsoft Corporation | Modeling and managing heterogeneous applications |
US20090112932A1 (en) * | 2007-10-26 | 2009-04-30 | Microsoft Corporation | Visualizing key performance indicators for model-based applications |
US8225308B2 (en) * | 2007-10-26 | 2012-07-17 | Microsoft Corporation | Managing software lifecycle |
US8621198B2 (en) * | 2008-02-19 | 2013-12-31 | Futurewei Technologies, Inc. | Simplified protocol for carrying authentication for network access |
US8793117B1 (en) * | 2008-04-16 | 2014-07-29 | Scalable Network Technologies, Inc. | System and method for virtualization of networking system software via emulation |
US8264972B2 (en) * | 2008-05-30 | 2012-09-11 | Spirent Communications, Inc. | Method and apparatus for emulating network devices |
US7958387B2 (en) | 2008-05-30 | 2011-06-07 | Spirent Communications, Inc. | Realtime test result promulgation from network component test device |
US9292248B2 (en) * | 2011-06-22 | 2016-03-22 | Microsoft Technology Licensing, Llc | Span out load balancing model |
US8526470B2 (en) * | 2011-07-05 | 2013-09-03 | Ixia | Synchronized commands for network testing |
US9430345B2 (en) | 2011-09-23 | 2016-08-30 | Roche Diabetes Care, Inc. | Command interface for communication test framework |
US9489488B2 (en) | 2011-09-23 | 2016-11-08 | Roche Diabetes Care, Inc. | Protocol independent interface supporting general communications interface debugging and testing tool |
US9521062B2 (en) * | 2011-09-23 | 2016-12-13 | Roche Diabetes Care, Inc. | Communication test framework |
US9652264B2 (en) * | 2012-09-21 | 2017-05-16 | Ixia | Methods, systems, and computer readable media for providing a unified framework to support diverse data generation engines |
CA2938768C (en) | 2014-03-31 | 2020-03-24 | Wandisco, Inc. | Geographically-distributed file system using coordinated namespace replication |
WO2016170512A1 (en) * | 2015-04-24 | 2016-10-27 | Tager Sean | Universal game controller |
US11360942B2 (en) | 2017-03-13 | 2022-06-14 | Wandisco Inc. | Methods, devices and systems for maintaining consistency of metadata and data across data centers |
CN109116781A (zh) * | 2018-09-03 | 2019-01-01 | 中国汽车工程研究院股份有限公司 | 以太网高速数据采集系统 |
US11182399B2 (en) | 2018-09-04 | 2021-11-23 | Spirent Communications, Inc. | Effective correlation of multiple time-series result sets |
Family Cites Families (19)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5371736A (en) * | 1992-12-21 | 1994-12-06 | Abb Power T&D Company, Inc. | Universal protocol programmable communications interface |
US5448566A (en) * | 1993-11-15 | 1995-09-05 | International Business Machines Corporation | Method and apparatus for facilitating communication in a multilayer communication architecture via a dynamic communication channel |
JPH08180001A (ja) * | 1994-04-12 | 1996-07-12 | Mitsubishi Electric Corp | 通信方式及び通信方法及びネットワークインタフェース |
US5473599A (en) * | 1994-04-22 | 1995-12-05 | Cisco Systems, Incorporated | Standby router protocol |
US5774695A (en) * | 1996-03-22 | 1998-06-30 | Ericsson Inc. | Protocol interface gateway and method of connecting an emulator to a network |
US5857074A (en) * | 1996-08-16 | 1999-01-05 | Compaq Computer Corp. | Server controller responsive to various communication protocols for allowing remote communication to a host computer connected thereto |
US5946311A (en) * | 1997-05-27 | 1999-08-31 | International Business Machines Corporation | Method for allowing more efficient communication in an environment wherein multiple protocols are utilized |
JP3343054B2 (ja) * | 1997-07-01 | 2002-11-11 | ケイディーディーアイ株式会社 | インターネット対応リンクモニタ方法 |
JP2003526223A (ja) | 1997-09-12 | 2003-09-02 | コミュニケイション アンド コントロール エレクトロニクス リミテッド | 通信システム用開発およびテストツール |
US6317438B1 (en) * | 1998-04-14 | 2001-11-13 | Harold Herman Trebes, Jr. | System and method for providing peer-oriented control of telecommunications services |
US20050027870A1 (en) * | 1998-04-14 | 2005-02-03 | Trebes Harold Herman | System and method for providing peer-oriented control of telecommunication services |
US8078730B2 (en) * | 2000-12-22 | 2011-12-13 | Rockstar Bidco, LP | System, device, and method for maintaining communication sessions in a communication system |
US6996085B2 (en) * | 2000-12-22 | 2006-02-07 | Nortel Networks Limited | System, device, and method for providing network access in a communication system |
US20020156886A1 (en) * | 2001-04-23 | 2002-10-24 | Krieski William George | Protocol monitor |
US20020186697A1 (en) * | 2001-04-23 | 2002-12-12 | Thakkar Bina Kunal | Protocol encoder and decoder |
US20020156885A1 (en) * | 2001-04-23 | 2002-10-24 | Thakkar Bina Kunal | Protocol emulator |
US20020157041A1 (en) * | 2001-04-23 | 2002-10-24 | Bennett David Charles | Protocol parser-code generator |
US7107597B2 (en) * | 2001-09-10 | 2006-09-12 | Ericom Software 8 2001 Ltd. | Method of and system for controlling task-oriented systems utilizing an application programming interface |
US20040024580A1 (en) * | 2002-02-25 | 2004-02-05 | Oak Technology, Inc. | Server in a media system |
-
2004
- 2004-07-16 US US10/893,668 patent/US7467078B2/en active Active
-
2005
- 2005-04-07 DE DE102005016032A patent/DE102005016032A1/de not_active Withdrawn
- 2005-06-21 CN CN200510077480.2A patent/CN1722681A/zh active Pending
- 2005-07-08 JP JP2005199534A patent/JP2006033829A/ja active Pending
- 2005-07-18 EP EP05254472A patent/EP1617625A3/en not_active Withdrawn
- 2005-07-18 GB GBGB0514689.9A patent/GB0514689D0/en not_active Ceased
Also Published As
Publication number | Publication date |
---|---|
CN1722681A (zh) | 2006-01-18 |
GB0514689D0 (en) | 2005-08-24 |
US7467078B2 (en) | 2008-12-16 |
DE102005016032A1 (de) | 2006-02-09 |
EP1617625A3 (en) | 2007-06-27 |
EP1617625A2 (en) | 2006-01-18 |
US20060013252A1 (en) | 2006-01-19 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP2006033829A (ja) | ポーティング可能な分散アプリケーションフレームワーク | |
JP4509916B2 (ja) | Snmp基盤のネットワーク管理装置および方法 | |
US6832184B1 (en) | Intelligent work station simulation—generalized LAN frame generation simulation structure | |
JP2005339538A (ja) | 分散データモデル | |
US20030212776A1 (en) | Methods and systems for changing a topology of a network | |
JPH09326796A (ja) | コンピュータネットワーク通信をシミュレートするためのテストパケットの生成方法、及びその装置 | |
CN112292664A (zh) | 用于设计分布式异构计算和控制系统的方法和系统 | |
WO2010105146A1 (en) | Multiple related event handling based on xml encoded event handling definitions | |
CN114422010B (zh) | 一种基于网络虚拟化的卫星通信仿真平台的协议测试方法 | |
CN112527647B (zh) | 基于NS-3的Raft共识算法测试系统 | |
CN108833005B (zh) | 光网络通信设备及其组网业务的自动化测试工具包及方法 | |
US20050283674A1 (en) | Navigating breakpoints in a program in a debugging mode | |
US7526420B2 (en) | Method and system for virtual injection of network application codes into network simulation | |
US7051304B2 (en) | Distributed infiniband verification protocol | |
CN113162677B (zh) | 一种实物设备与虚拟网络仿真平台的通信方法及装置 | |
US20050281202A1 (en) | Monitoring instructions queueing messages | |
Taher | Testing of floodlight controller with mininet in sdn topology | |
CN112737815A (zh) | 一种动态配置网络模拟器事件队列的方法及系统 | |
CN116610516B (zh) | 一种基于设备数字孪生的物联网编程运维底座系统及方法 | |
Dinda | The minet tcp/ip stack | |
Garcia-Espallargas et al. | Distributed agents control system, a framework for programming distributed agents | |
Raheja | Enabling kubernetes for distributed ai processing on edge devices | |
Hołubowicz et al. | SPACEMAN: A SpaceWire network management tool | |
Magee et al. | The CONIC Support Environment for Distributed Systems | |
Xinhua et al. | Computer Network Simulation Modeling Based on an Object Oriented Petri Net. |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
RD02 | Notification of acceptance of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7422 Effective date: 20070511 |