JPH0659934U - サーバー拡張用アーキテクチャ - Google Patents

Abstract

(57)【要約】 （修正有） 【目的】 サーバ拡張用アーキテクチャーが、入力イベ
ント及び出力プロトコールリクエストを傍受する手段を
提供する。Ｘウィンドウ形システム上で遠隔端末エミュ
レーションが可能である。 【構成】 本発明のアーキテクチャは、サーバー１２内
のメモリー部分と同等なメモリー部分をサーバー拡張内
に有し、このサーバー内のメモリー部分には、入出力処
理ルーチンのアドレスを記憶する。これらのアドレスを
メモリーのサーバー拡張用部分内のメモリー部分のアド
レスとスワッピングすることにより、サーバー拡張は入
力及び出力を傍受して、サーバー又は応用プログラムを
監視し、ワークステーション１４を制御する。サーバー
拡張アーキテクチャーは応用プログラムの制御の下で作
動する。

Description

【考案の詳細な説明】

【００１】

【産業上の利用分野】

本考案は、コンピュータシステムに用いられるサーバー拡張用アーキテクチャ にかかり、特に応用プログラムによって発生した入力イベント及びプロトコル要 求を傍受するためのサーバー拡張用アーキテクチャに関するものである。傍受さ れた入力イベントおよびプロトコル要求は引き続いて種々の目的に、例えば、入 力イベントとプロトコルリクエストとの間の時間経過を測定してサーバーもしく は応用プログラムの性能を評価するのに用いられる。

【０００２】

【従来の技術】

サーバーはコンピュータシステムのアーキテクチャの一部であり、コンピュー タまたはセントラルプロセシングユニットとユーザーとの間のインタフェースと して機能する。サーバーの性能を試験あるいは評価することは種々の目的から必 要である。例えば、ユーザーの入力とシステムの応答間の長い遅れを検出し続い てこれを除去することができる。同様に、コンピュータのセントラルプロセシン グユニット上で動作する応用プログラムを試験し評価することは多くの目的で必 要である。

【０００３】 サーバーの性能をテストする通常の方法は、ビデオカメラまたはストップウォ ッチを用いることである。このような方法の１つでは、末端および端末スクリー ンで作業するユーザーまたはオペレータがビデオカメラで撮影される。その後で ビデオを機械にかけて再現させ、時間をフィルムスピードの関数として表示する 。次で、性能メトリックスが、フィルムイベントの開始とフィルムイベントの終 了の表示時間の差に基づいて計算される。次で各時間ごとのイベントに対する性 能メトリックスが記録される。もう１つの方法では、性能メトリックスを計算す るステップが、応答時間をストップウォッチを用いて手動で測定することを含ん でいる。いずれの方法でも、すべての時間的イベントに対する性能メトリックス が引続いて解析され、応用プログラムまたはサーバーの性能が求められる。これ と同じアプローチはまた、サーバーの単一または特定の入力イベントに対する性 能を求めるのにも使用される。しかしながら、この方法は時間がかかるばかりで なく、退屈なものであり、またエラーを生じ易い。さらにこの方法では、ユーザ ーがワークステーションで実際に操作する必要がある。従ってユーザーからのシ ミュレーション入力は不可能である。さらに、実際のユーザーからの入力は１つ の操作ごとに整合性をもっていないので、ランごとに整合性を保つことが不可能 である。

【０００４】 応用プログラムまたはサーバーの、入力イベントまたはプロトコル要求に対す る性能を試験するもう１つの方法は、遠隔端末エミュレーション（ＲＴＥ）を用 いることである。ＲＴＥは、サーバーや応用プログラムに入力を送るのにユーザ ー自身やオペレータを不用とし、オペレータの代りに、ソフトウェアで作成され る入力が用いられ、これがサーバーの入力イベント列にロードされる。しかしな がら、Ｘウィンドウ形システムのサーバーに対するＲＴＥの以前の試みでは、出 力で発生したプロトコール要求をサーバーまたは応用プログラムで傍受する方法 を提供するのに失敗した。さらに、これらの試みはいすれも遠隔ソース、すなわ ち入力を非Ｘの伝送リンク、例えば、ネートワークまたは非同期端末ラインを介 して入力を送るソースからシミュレーション入力を受信するのに支援になってい ない。従ってＲＴＥによるこれら従来の試みは、ネットワーク、モデル、および 他の周辺機器を含むシステム構造を試験することができない。

【０００５】

【考案の概要】

本考案は、コンピュータシステムで用いられるサーバー拡張用のアーキテクチ ャの中に存在する。拡張はサーバー機能を行うソフトウェアモジュールであり、 サーバー変数に対するアクセスは有するがサーバーの定常的な一部とはなってい ない。サーバー延長は、ユーザー入力イベントを、これらが応用プログラム（以 下、クライアントと呼ぶ）で受信される前に傍受し、入力に関する情報を、入力 の形式および傍受された時間を含み、クライアントで指定された場所に書込み、 あるいはストアする。クライアント指定の場所は、どんな形式の格納装置でもよ く、例えばシーケンシャルファィルでよい。格納装置はローカルなものでもよく 、あるいは遠隔位置にあってモデムライン、端末ライン、またはネットワークラ インで結合されるものでもよい。さらに、サーバー拡張は、応用プログラムで発 生された出力プロトコル要求を、端末のスクリーン表示への可視変換が行われる 前に傍受する。出力プロトコル要求は、応用プログラムで発生される信号であり 、サーバーへ送られてサーバーが端末のスクリーン上にテキストまたはグラフィ ックを描けるようにするものである。サーバー拡張はまた、出力プロトコル要求 に関する情報を、要求の形式およびこれが傍受された時間を含んで、クライアン トの指定した場合に書込み、またはストアする。クライアント指定の場所は、ど んな形式の格納装置でもよく、例えばシーケンシャルファイルでもよい。格納装 置はローカルなものでもよく、あるいは遠隔位置にあってモデムライン、端末ラ イン、またはネットワークラインで結合されるものでもよい。最終的にサーバー 拡張は、ワークステーションのマウスやキーボードなどのようなユーザ操作の入 力機器からの入力、または制御用クライアントからのシミュレーション入力を受 信することができる。

【０００６】 本考案は、その広い態様としては、セントラルプロセシングユニット、オペレ ーチングシステム、ユーザー指定入力をその端末位置でコンピュータに入力する １つ以上の入力ドライブ、テキストまたはグラフィック画像を表示する１つ以上 の出力ドライブ、対話モードで動くコンピュータプログラム、上記ユーザー指定 入力をユーザーによる入力と上記コンピュータプログラムによる受信との間で傍 受する手段（Ｘ Ｔｒａｐ）、および出力命令を上記コンピュータプログラムと 上記１つ以上の出力ドライブとの間で傍受する手段を備えたコンピュータシステ ムである。

【０００７】 ここで説明するサーバー拡張アーキテクチャは、入力イベントおよびプロトコ ル要求を傍受し、これを用いて制御クライアントがサーバーまたは応用プログラ ムをモニタしたり、ワークステーションを制御したりして、例えば、応用プログ ラム、システム構成、およびユーザーインターフェースの性能をテストできるよ うにするものである。サーバー拡張アーキテクチャのデータ構成は、メモリの部 分あるいはブロックとして構成され、メモリの種々の部分またはブロックで構成 されるサーバーのデータ構造と似ているか、あるいは基本的に同じである。さら に、本発明のサーバー拡張アーキテクチャは、クライアントまたは応用プログラ ムの制御によって動作する。従って、このサーバー拡張アーキテクチャは周知の Ｘサーバーオペレーチングシステムプログラムに関連して述べられているが、他 のオペレーチングシステムでも同様に実行できるものである。

【０００８】 このサーバー拡張アーキテクチャはまた、ＲＴＥすなわち遠隔末端エミュレー ションを備え、遠隔ソースからシミュレーション入力を受信することができる。 例えば、このサーバー拡張アーキテクチャは、Ｒ．Ｗ．Ｓｃｈｅｉｆｆｌｅｒ， Ｊ．Ｇｅｔｔｙｓ，およびＲ．Ｎｅｗｍａｎ，Ｘ Ｗｉｎｄｏｗ Ｓｙｓｔｅｍ ，Ｄｉｇｉｔａｌ Ｐｒｌｓｓ（１９８８）に報告されている有名なオペレーチ ングシステムであるＸウィンドウシステムに対するＲＴＥ能力をもっている。こ のサーバー拡張アーキテクチャはまた、ソフトウェアの回帰テスト、および異な るハードウェアおよびソフトウェアプラットフォーム間の応用プログラムの競合 性あるいは干渉性テストに対する迅速で安価な手段を提供する。このサーバー拡 張アーキテクチャはさらに、端末におけるユーザーの対話をモニタし、正しい対 話を立証できることが重要である場合に、コンピュータベースの命令を可能にす る。このアーキテクチャは、さらに、立証者が立証すべき応用プログラムを理解 する必要がない場合、あるいは立証よりも顧客に集中する必要がある場合に、ト レードショーによる立証を可能にする。上記の例から分るように、本考案による サーバー拡張アーキテクチャは、当業者にとって周知の幅広い種々の目的に利用 することが可能である。

【０００９】

【実施例】

以下、本考案を図面を参照して説明する。図１は、本考案によるサーバー拡張 アーキテクチャの好ましい一実施例を、コンピュータシステムの基本的なコンポ ーネントに対して用いた場合の一般的な動作を示している。ソフトウェア構成は 、Ｘサーバー１２と対話するセントラルプロセシングユニット１０上で動作する 。Ｘサーバーは周知のオペレーチングシステムプログラムであり、端末あるいは ワークステーション１４のユーザーインタフェースを制御すると共に、キーボー ド２０またはテキストのような標準のユーザインタフェース要素に加えて、ウィ ンドウ１６およびマウス１８を利用している。Ｘサーバー１２は、“拡張”、す なわちＸサーバーの各変数に対するアクセスを有すると共に、但しＸサーバーの 垣久的な一部ではないソフトウェアモジュールをサポートできる。本考案におけ る拡張２２は“Ｘ Ｔｒａｐ 拡張”と呼ばれるものである。なお、当業者にと って、本考案の記述が他のオペレーチングシステムおよびサーバーにどのように 適用されるかは容易に理解できることである。

【００１０】 複数の応用プログラム２４Ａ〜２４Ｎは、セントラルプロセシングユニット（ ＣＰＵ）１０上で動作できる。ＣＰＵ１０上で動作する応用プログラムまたはク ライアント２４Ｎは、Ｘサーバー１２のソフトウェア拡張である。Ｘ Ｔｒａｐ 拡張２２の制御クライアントとして動作する。オペレーチングシステム機能を実 行する既知のソフトウェアモジュール、あるいは拡張はサーバーで制御され、Ｘ Ｔｒａｐ 拡張２２は単一の応用プログラムあるいはクライアント２４Ｎで制 御される。制御クライアント２４ＮはＸ Ｔｒａｐ 拡張２２のパラメータをセ ットすると共に、Ｘ Ｔｒａｐ 拡張２２のオンオフを行う。マウス１８または キーボード２０からのユーザー入力は先ずＸサーバー１２で受信される。本発明 はまた、他の入力機器を用いたオペレーチングシステムのほかに１つのタイプの 入力機器を用いたオペレーチングシステムにも適用できる。Ｘ Ｔｒａｐ 拡張 ２２は、入力を傍受し、入力のコピーを、“書込”ルーチン用にフォーマットを 変更し（これについて下記に詳述する）、元の入力は通常のプロセシング用とし てサーバー１２に送る。最終的に、モニタまたは制御されているクライアント２ ４Ａ〜２４Ｎは元の入力を受信し、その特定の実施手順に従って処理する。

【００１１】 クライアント２４Ａ〜２４Ｎは何れも、プロトコル要求の形で出力を発生し、 これによって通常、ワークステーション１４における或る種類のスクリーン出力 を制御する。制御クライアント２４Ｎは同じ出力をもう１つのワークステーショ ン（図示せず）のスクリーン上に同時に表示する。これらの出力プロトコル要求 によって、サーバーは、ワークステーション１４の表示スクリーン上にテキスト 、ライン、あるいは他のグラフィック要素を描く。上記の実施例では、Ｘ Ｔｒ ａｐが傍受する応用プログラムとＸサーバー間の通信は、出力プロトコル要求で あるが、本考案は、サーバーとどのクライアントとの間の通信を傍受するのにも 用いることができる。Ｘサーバー１２は出力プロトコル要求を応用プログラム２ ４Ａ〜２４Ｎの１つから受信し、Ｘ Ｔｒａｐ 拡張２２がＸサーバー１２がこ れを処理する前にこれを傍受する。入力の場合と同じように、出力の場合もＸ Ｔｒａｐ 拡張２２はコピーのフォーマット変更を行い、元の出力はＸサーバー へ返送する。最終的に、出力はワークステーション１４のスクリーンに到達し、 テキスト、ライン、または消去の形式を制御する。

【００１２】 Ｘ Ｔｒａｐ 拡張２２は、拡張のコードの一部である“書込”サブルーチン を呼出す。Ｘ Ｔｒａｐ は各通信チャンネルごとに別々の“書込”ルーチンを 持っており、これを介してＸ Ｔｒａｐ が制御クライアントと通信する。制御 クライアントはＸ Ｔｒａｐ から遠隔のにあってもよく、例えばネットワーク ラインの終端でもよい。“書込”ルーチンは、入力および出力に関する集められ た情報を、制御クライアント２４Ｎまたはシーケンシャルファイル２６へ送る。

【００１３】 図２は、Ｘ Ｔｒａｐ 拡張とサーバーとのアーキテクチャを示したものであ る。本考案は、このタイプのアーキテクチャの使用に限定されるものではなく、 入力およびプロトコル要求を処理するサブルーチンを呼出すものであれば、どの ようなオペレーチングシステムのアーキテクチャ上でも作動できる。Ｘサーバー は、キーボードデータを、そのアドレスが“Ｋｅｙ Ｂｏａｒｄ Ｐｒｏｃｅｓ ｓ Ｉｎｐｕｔ ｐｒｏｃ”のストア位置２８にストアされているルーチンに送 ることによって処理する。また、サーバーはマウス入力を同じような方法で、す なわち“Ｐｏｉｎｔｅｒ Ｐｒｏｃｅｓｓ Ｉｎｐｕｔ Ｐｒｏｃ”ストア位置 ３０を参照することによって処理する。また、Ｘサーバーは、出力プロトコル要 求を、適当な情報を、そのアドレスが“Ｐｒｏｃ Ｖｅｃｔｏｒ”アレイ３２の 特定のエレメントにストアされているルーチンに送ることによって処理する。

【００１４】 Ｘ Ｔｒａｐ 拡張２２は、Ｘサーバーのデータ構成の半分以下のサイズのデ ータ構成をもっている。 Ｘ Ｔｒａｐ データ構成はまた、メモリ内に、Ｘサーバーのデータ構成と同 じ、またはほゞ同じ構成で配置されている。本考案の記述を用いて、他のオペレ ーチングシステムを模倣し、これによって、入力（あるいは出力）を自分に代っ て処理する拡張サブルーチンを呼出す手段を得ると共に、同時に、拡張の使用が 終った後にオペレーチングシステムを通常の状態に戻す手段を得ることは、当業 者にとって容易に理解できることである。

【００１５】 Ｘ Ｔｒａｐ がキーボード入力を傍受するように構成されているときは、Ｘ サーバーのストア位置、“Ｋｅｙｂｏａｒｄ Ｐｒｏｃｅｓｓ Ｉｎｐｕｔ Ｐ ｒｏｃ”２８はキーボード入力を処理するＸ Ｔｒａｐ ルーチンのアドレスを 含んでおり、またこのストアスペースの“Ｋｅｙｂｏａｒｄ＿ｉｎｐｕｔｐｒｏ ｃ”と呼ばれるＸ Ｔｒａｐ バージョン３４は、Ｘサーバーの入力処理ルーチ ンのアドレスをストアしている。またＸ Ｔｒａｐ がマウス入力を傍受するよ うに構成されているときは、Ｘサーバーのストア位置、“Ｐｏｉｎｔｅｒ Ｐｒ ｏｃｅｓｓ Ｉｎｐｕｔ Ｐｒｏｃ”３０は、マウス入力を処理するＸ Ｔｒａ ｐ ルーチンのアドレスを含んでおり、またこのストアスペースの、“Ｐｏｉｎ ｔｅｒ＿Ｉｎｐｕｔ Ｐｒｏｃ”と呼ばれるＸ Ｔｒａｐ バージョン３６は、 Ｘサーバーの入力処理ルーチンのアドレスをストアしている。

【００１６】 上記の構成から分るように、Ｘ Ｔｒａｐはキーボードおよびマウスからの入 力を傍受する。上述のように、Ｘサーバーはキーボード入力を受信するときは、 そのアドレスが“Ｋｅｙ Ｂｏａｒｄ Ｐｒｏｃｅｓｓ Ｉｎｐｕｔ Ｐｒｏｃ ”２８にストアされているルーチンを呼出し、またマウス入力を受信するときは 、そのアドレスが“Ｐｏｉｎｔｅｒ Ｐｒｏｃｅｓｓ Ｉｎｐｕｔ Ｐｒｏｃ” ３０にストアされているルーチンを呼出す。Ｘ Ｔｒａｐ の実行中は、これら のストア位置２８および３０はＸ Ｔｒａｐ ルーチンのアドレスを含んでいる ので、キーボードおよびマウスからの入力はＸ Ｔｒａｐ 拡張に送られる。

【００１７】 Ｘ Ｔｒａｐ 拡張は、クライアントで発生された出力プロトコル要求を、Ｘ Ｔｒａｐ 拡張出力処理ルーチンのアドレスを、“Ｐｒｏｃ Ｖｅｃｔｏｒ” という名称のデータ構成３２にストアされているＸサーバー出力処理ルーチンの アドレスとスワップすることによって傍受する。出力プロトコル要求を処理する ルーチンの各アドレスは４バイトの値になっている。好ましい実施例では、２５ ６個の４バイトアドレスがあるが、アレイ数がこれより小さいもの、または大き いものも本発明のスコープに入るものである。アレイエレメント４２は、“Ｉｍ ａｇｅ Ｔｅｘｔ ８”要求を処理するルーチン用のアドレスを含んでいる。こ のルーチンは、スクリーン上に、テキストの単一ストリング表示を行う。Ｘ Ｔ ｒａｐ が“Ｉｍａｇｅ Ｔｅｘ ８”出力プロトコル要求を傍受するように構 成されているときは、この位置にストアされている値が、スクリーン上にテキス トの単一ストリング表示を行うＸ Ｔｒａｐ ルーチンのアドレスとなる。この ルーチンは“ｅｘｔ＿ｉｍｇｅｔｅｘｔ ８”とよばれる。“Ｉｍａｇｅ Ｔｅ ｘｔ ８”ルーチンのアドレスは、Ｘサーバーの、“Ｐｒｏｃ Ｖｅｃｔｏｒ” データ構成３２のＸ Ｔｒａｐ のバージョンである“ｅｘｔ＿Ｐｒｏｖｅｃｔ ｏｒ”アレイ３８の対応するエレメント４４にストアされている。従って、Ｘサ ーバーが、何れかのクライアントからテキストのストリング表示の要求を受信し たものは、そのアドレスが“Ｐｒｏｃ Ｖｅｃｔｏｒ”３２のエレメント４２に ストアされているルーチンを呼出す。Ｘ Ｔｒａｐ がアクチブのときは、その アドレスは、通常はエレメント４４にストアされているＸ Ｔｒａｐ ルーチン “ｅｘｔ＿ｉｍａｇｅｔｅｘｔ ８”のアドレスとなる。

【００１８】 他の出力プロトコル要求は、例えば、スクリーン上にテキストを２ストリング 以上で表示するルーチン“Ｐｏｌｙ Ｔｅｘｔ ８”、スクリーン上にウィンド ウを描くようにサーバーを準備させるルーチン“Ｍａｐ Ｗｉｎｄｏｗ”、およ びスクリーンからウィンドウを消去するルーチン“Ｕｎｍａｐ Ｗｉｎｄｏｗ” を含んでいる。Ｘ Ｔｒａｐ データ構成３８内の対応するルーチンは、“ｅｘ ｔ＿Ｐｏｌｙｔｅｘ ８”、“ｅｘｔ＿Ｕｎｍａｐｗｉｎｄｏｗ”、および“ｅ ｘｔ＿ｍａｐｗｉｎｄｏｗ”、である。他の出力プロトコル要求も、同じような 方法でＸ Ｔｒａｐ 拡張によって傍受できる。

【００１９】 Ｘ Ｔｒａｐ 拡張は入力または出力を傍受したとき、入力または出力情報の コピーを作成し、クライアントで形成されたＸ Ｔｒａｐ の“書込”ルーチン で処理されうるようにフォーマットが与えられる。Ｘ Ｔｒａｐ が“ｎｏ”さ れると、“ｗｒｉｔｅ”ルーチンのアドレスは“ｘ ｔｒａｐ＿ｗｒｉｔｅ”ベ クトル４０にストアされる。ｘ Ｔｒａｐ が“ｏｆｆ”されると、“ｘ ｔｒ ａｐ＿ｗｒｉｔｅ”が、ヌルルーチン、すなわち制御をＸ Ｔｒａｐ に戻すだ けのルーチンのアドレスを保持する。何れの場合にも、Ｘ Ｔｒａｐ が入力ま た出力のどれをも傍受するように構成されていると、これがフォーマットされた 入力または出力のコピーを、そのアドレスが“ｘ ｔｒａｐ＿ｗｒｉｔｅ”にス トアされているルーチンへ送る。

【００２０】 データ構成“ｅｘｔ＿ｅｎｖｉｒｏｎ ｍｅｎｔ”４８はＸ Ｔｒａｐ の内 部変数を含んでいる。変数“Ｓｗａｐ Ｇｓｔａｔｅ”は、どの出力プロトコル 要求および入力イベントが傍受されているかを指示するビットフィールドである 。変数“ｇｅｎｆｌｇｓ”は、タイムスタンプ計算、“ｗｉｎｄｏｗ＿ｉｄ”処 理、および出力フォーマット（すなわちバイナリ、またはＡＳＣＩＩ）のような 種々のモードを可能および不能にする一般的な拡張フラグのビットフィールドで ある。“ｗｉｎｄｏｗ＿ｉｄ”処理は、可能されると、どのウィンドウが“Ｍａ ｐ Ｗｉｎｄｏｗ”または“Ｕｎｍａｐ Ｗｉｎｄｏｗ”出力プロトコル要求の 対象であるかをＸ Ｔｒａｐが報告するようにする。変数“ｏｓｆｌｇ”は実行 特定フラクのビットフィールドである。変数“ｉｍａｇｃｎｔ”は、Ｘ Ｔｒａ ｐ が“Ｉｍａｇｅ Ｔｅｘｔ”または“Ｐｏｌｙ Ｔｅｘｔ”要求を傍受した とき、Ｘ Ｔｒａｐ がテキストストリングからセーブしたキャラクタの最大数 を保持する。セーブされたキャラクタはＸ Ｔｒａｐ が“ｗｒｉｔｅ”ルーチ ンに送る出力プロトコル要求上の情報の一部となる。“ｉｍａｇｃｎｔ”がネガ チブであると、キャラクタはストリングの始まりからセーブされ、“ｉｍａｇｃ ｎｔ”がポジチブのときは、キャラクタはストリングの最終からセーブされる。

【００２１】 変数“ｐｏｌｙ ｃｕｔ”は、Ｘ Ｔｒａｐ が“ｐｏｌｙ Ｔｅｘｔ”要求 を傍受したときＸ Ｔｒａｐ が処理すべきストリングの最大数を保持する。ス トリングが処理されると、“Ｉｍａｇ ｃｕｔ”キャラクタが“ｗｒｉｔｅ”ル ーチンへ送られる。“ｐｏｌｙ ｃｕｔ”がポジチイブであると、ストリングが ストリングリストの最初から処理され、“ｐｏｌｙ ｃｕｔ”がネガチブである と、ストリングはストリングリストの終りから処理される。変数“ｉ＿ｃｏｍｍ ” は、Ｘ Ｔｒａｐへのシミュレーション入力に用いられる通信チャネル用の 識別子を含んでいる。変数“ｏ＿ｃｏｍｍ”は、Ｘ Ｔｒａｐ 拡張からの出力 に用いられる通信チャネル用の識別子を含んでいる。最終的に、変数“Ｗｒｉｔ ｅ＿ｉｏ”は、Ｘ Ｔｒａｐ がＳＴＡＲＴ＿ＩＯ要求を受信したとき“ｘ ｔ ｒａｐ＿ｗｒｉｔｅ”内に置かれる“ｗｒｉｔｅ”ルーチンに対するポインタを 含んでいる。

【００２２】 図３および図４は、応用プログラムまたは制御クライアントの構成、および２ つの異なった動作モードによるＸ Ｔｒａｐ サーバー拡張の使用方法を示す、 それぞれのプロセスフロー図である。すなわち図３は、記録入力イベントまたは 出力プロトコル要求がライブユーザーセッション中に発生したときの、記録モー ド動作と呼ばれる、Ｘ Ｔｒａｐ サーバー拡張の動作を示すプロセスフロー図 である。また図４は、ＲＴＥ、すなわち遠隔端末エミュレーション能力を用いて 、シミュレートされた入力イベントを用いると共に傍受された出力イベントを待 機してライブユーザーセッションのシミュレーションを行う、プレイバックモー ド動作と呼ばれる。Ｘ Ｔｒａｐ サーバー拡張の動作を示すプロセスフロー図 である。制御クライアントは、ＸＬ１Ｂ ｘｆｌｕｓｈ マクロを介してデータ 構成をサーバーに送ることによって、Ｘ Ｔｒａｐ 拡張と交信する。なお、こ れについては、Ｒ．Ｗ．Ｓｃｈ−ｅｉｆｆｌｅｒ，Ｊ．Ｃｅｔｔｙｓ，およびＲ ．Ｎｅｗｍａｎ，“ＸＷｉｎｄｏｗ Ｓｙｓｔｅｍ”，Ｄｉｇｉｔａｌ Ｐｒｅ ｓｓ 刊行（１９８８）に報告されている。サーバーは次で、データ構成を拡張 例へ送る。下記のテーブル１はデータ構成“ｘ Ｘｔａｐ Ｒｅｇ”のフォート マットを示したものである。

【００２３】 第１のフィールド、“ｒｅｑ Ｔｙｐｅ”は、データ構成“ｘ Ｘｔａｐ Ｒ ｅｑ”をどのＸ Ｔｒａｐ 拡張へ通すべきかを識別する。クライアントはこの アイデンチファイヤを、“ｘ Ｑｕｅｒｙ Ｅｘｔｅｎｓｉｏｎ”を呼出すこと によって集める。なお、これについては、Ｒ．Ｗ．Ｓｃｈｅｉ−ｆｆｌｅｒ，Ｊ ．Ｇｅｔｔｙ，およびＲ．Ｎｅｗｍａｎ，“Ｘｗｉｎｄｏｗ Ｓｙｓｔｅｍ”、 Ｄｉｇｉｔａｌ Ｐｒｅｓｓ（１９８８）に報告されている。第２のフィールド 、“ｍｉｎｏｒ＿ｏｐｃｏｄｅ”は、クライアントが送信中の特定のＸ Ｔｒａ ｐ 拡張要求に対して識別子を含んでいる。再び図２を参照すると、“ｅｘｔ＿ ｒｅｑｕｅｓｔ＿ｖｅｃｔｏｒ”アレイ４６はＸ Ｔｒａｐ が“ｍｉｎｏｒ＿ ｏｐ ｃｏｄｅ”をルックアップして適当な要求処理ルーチンを呼出すのに利用 するディスパッチテーブルを含んでいる。第３のフィールド“Ｉｅｎｇｔｈ”は 、Ｘ Ｔｒａｐ要求に対して常に９である。第４のフィールド、“ｄａｔａ”は 、各要求に対して異った構成をもったユニオンである。各ユニオンは送られる要 求に対する特定のデータを含んでいる。なお、本考案は、拡張との交信にｘ ｆ ｌｕｓｈを使用するものに限定されるものではない。

【００２４】 再び図３を参照すると、クライアントがＸ Ｔｒａｐ を構成する第１ステッ プは、“ｘ Ｑｕｅｒｙ Ｅｘｔｅｎｓｉｏｎ”を呼出することによって拡大用 アイデンチファイアを得ることであり、これについては、Ｒ．Ｗ．Ｓｃｈｅｉｆ ｆｌｅｒ，Ｊ．Ｇｅｔｔｙｓ，およびＲ．Ｎｅｗｍａｎｎ，“Ｘ Ｗｉｎｄｏｗ Ｓｙｓｔｅｍ”Ｄｉｇｉｔａｌ Ｐｒｅｓｓ（１９８８）に報告されている。 次に、クライアントは、ＸＴＲＡＰ＿ＲＥＳＥＴ要求を、“ｘ Ｘｔｒａｐ Ｒ ｅｑ”構成の種々のフィールドをセットし、これをｘｆｌｕｓｈ ｍａｃｒｏを 介してサーバーに送ることによって要求する。

【００２５】 ＸＴＲＡＰ＿ＲＥＳＥＴ要求は、拡張を新しいクライアントによる使用に対し て準備させる。あるクライアントがすでにこの拡張を使用中であり、かつすでに 制御クライアントとして構成されているときは、Ｘ Ｔｒａｐが要求内の“ｆｏ ｒｃｅ”フラグをチェックする。“ｆｏｒｃｅ”フラグは、“ｘＸ Ｔｒａｐ Ｒｅｑ”のユニオンフィールド“ＲＥＳＥＴ”内のＸ Ｔｒａｐに送られる要求 特定信号の一部である。 （テーブル２参照）

【００２６】 “ｆｏｒｃｅ”フラグがセットされると、Ｘ Ｔｒａｐ はリセットされ、他 のクライアントの制御から離脱する。“ｆｏｒｃｅ”フラグがセットされていな いと、Ｘ Ｔｒａｐ はエラーコードをクライアントに戻す。 各クライアントは、ＸＴＲＳＰ＿ＲＥＳＥＴ要求の間、“ｃｏｎｔｒｏｌ”フ ラグをセットすることによって、他のクライアントが或る拡張を偶発的に制御し ないように防ぐことができる。“ｃｏｎｔｒｏｌ”フラグがセットされると、Ｘ Ｔｒａｐ 拡張は、他のクライアントが“ｆｏｒｃｅ”フラグをセットしない 限り、他のクライアントからの後続するＸＴＲＡＰ＿ＲＥＳＥＴをすべて無視す る。“ｃｏｎｔｒｏｌ”フラグは、“ｆｏｒｃｅ”フラグと同じく“ＲＥＳＥＴ ”ユニオンの一部である。

【００２７】 Ｘ Ｔｒａｐ 拡張はＸＴＲＡＰ＿ＲＥＳＥＴ要求を受信すると、Ｘ Ｔｒａ ｐ の内部変数およびフラグをその無効値にリセットし、入力および出力の傍受 用の構成をすべて取消す。全部のクライアントプログラムが、それぞれストップ する前にＸＴＲＡＰ＿ＲＥＳＥＴを送信する。

【００２８】 Ｘ Ｔｒａｐ 拡張がリセットされると、その度にクライアントは、その拡張 が傍受しようとする入力および出力の種類をセットアップするＸＴＲＡＰ＿ＣＯ ＮＦＩＧ要求を送信する。ＸＴＲＡＰ＿ＣＯＮＦＩＧ要求用として、“ｘＸ Ｔ ｒａｐ Ｒｅｑ”の“ｄａｔａ”ユニオンは図３に示すような構成をもっている 。

【００２９】 “ｆｌａｇ”フィールドは入力および出力の傍受を可能および不能にするため に用いられ、テーブル４に示す通りである。

【００３０】 “ｖ＿ｋｂｄ”フラグがセットされると、Ｘ Ｔｒａｐは、キーボード入力の 傍受の状態を、“ｓ＿ｋｂｄ”フラグの状態に対応してセットする。“ｓ＿ｋｂ ｄ”がオンであると、キーボード入力傍受が可能となる。またオフであると、キ ーボード入力傍受が不能となる。マウス入力も同じように、“ｖ＿ｐｔｒ”フラ グおよび“ｓ＿ｐｔｒ”フラグを用いて制御される。１対のフラグ“ｖ＿ｏｐｃ ｏｄｅｓ“と”ｓ＿ｏｐｃｏｄｅｓ”は、同じような動作によって、テーブル３ に示す“ＣＯＮＦＩＧ”構成の“Ｉｃｓｔ”フィールド内にリストされた出力プ ロトコル要求の傍受を可能または不能にする。

【００３１】 ＸＴＲＡＰ＿ＣＯＮＦＩＧ要求はまた、拡張を、傍受された入力または出力プ ロトコル要求のすべてについてミリ秒のタイムスタンプを行うように形成するこ とができる。ＸＴＲＡＰ＿ＣＯＮＦＩＧはまた、Ｘ Ｔｒａｐ によって発生さ れる出力の形式に関する制御、すなわちＡＳＣＩＩフォーマットと二進フォーマ ットの間の選択に関する制御を行う。

【００３２】 Ｘ Ｔｒａｐ 拡大はＸＴＲＡＰ＿ＣＯＮＦＩＧ要求を受信すると、スワップ 動作を行って、クライアントによって選択された入力および出力プロトコル要求 の各タイプごとに、Ｘ Ｔｒａｐ の入力または出力処理ルーチンのアドレスを 、Ｘサーバーの入力または出力処理ルーチンのアドレスと交換する。例えば、ク ライアントが、そのＸＴＲＡＰ＿ＣＯＮＦＩＧ要求の中に２つのフラグ“ｖ＿ｋ ｂｄ ”および“ｓ＿ｋｂｄ”をセットすると、図２に示すように、Ｘ Ｔｒａ ｐ は、ベクトル“Ｋｅｙ Ｂｏａｒｄ Ｐｒｏｃｅｓｓ Ｉｎｐｕｔ Ｐｒｏ ｃ”２８内の“ｋｂｄ Ｐｒｏｃ”ポインタを“ｈｅｙｂｏａｒｄ＿ｉｎｐｕｔ ｐｒｏｃ”３４内のポインタ“Ｘ Ｔｒａｐ＿ｋｅｙｂｏａｒｄ”と交換する 。またクライアントがフラグ“ｖ＿ｋｂｄ”をセットすると共に、但しフラグ“ ｓ＿ｋｂｄ”をセットしないでおくと、２つのポインタはストップされない。Ｘ ＴＲＡＰ＿ＲＥＳＥＴ要求があると、Ｘ Ｔｒａｐ は“Ｋｅｙ Ｂｏａｒｄ Ｐｒｏｃｅｓｓ Ｉｎｐｕｔ Ｐｒｏｃ”と“Ｘ ｔｒａｐ＿Ｋｅｙｂｏａｒｄ ”とのスワップは行わない。

【００３３】 次に、クライアントはＣＯＮＦＩＧ＿ＩＯ要求をＸ Ｔｒａｐ に送り、集め られた入力および出力の情報をどの種類の通信チャネルを介して制御クライアン トに送信すべきかを指定する。Ｘ Ｔｒａｐ は、この要求を受信すると、その 内部変数“ｗｒｉｔｅ＿ｉｏ”（図２の４８）を“ｗｒｉｔｅ”ルーチンへのポ インタの値にセットする。このルーチンは、傍受された入力イベントおよび出力 プロトコル要求上の情報を、構成された通信チャネルを介して制御クライアント に送信するのに用いられる。記録モードでは、クライアントは情報をシーケンシ ャルファイルに記録する。またプレイバックモードでは制御クライアントは、構 成された“ｗｒｉｔｅ”ルーチンを介して受信した情報を用いて、シミュレート された入力がサーバーへ送信されたことを確認する。これによって、制御クライ アントは、安全やその他の理由で必要なとき、キーボードまたはマウスからの入 力をサーバーが無視するようにする。クライアントは、また、この情報を用いて 出力プロトコル要求をモニタし、最後の出力プロトコル要求の処理が終るまで、 次の入力イベントを送信するのを待機する。プレイバックモードでも制御クライ アントは情報をシーケンシャルファイルへ記録する。例えば、最後の出力プロト コル要求が“Ｓ”プロンプトに対する要求であると、クライアントは“Ｓ”がス クリーン上に現われるまで待ってから、次の入力イベントを送らなければならな い。

【００３４】 プレイバックモードでは、遠隔末端エミュレーション（ＲＴＥ）を実行するの にＣＯＮＦＩＧ＿ＩＯ要求を行う。テーブル５は、ＣＯＮＦＩＧ＿ＩＯ要求に対 する“ｘＸ Ｔｒａｐ Ｒｅｑ”の“ｄａｔａ”ユニオンの構成を示すものであ る。

【００３５】 “ｔｒａｎｓｐｏｒｔ”フィールドは、構成される通信チャネルのタイプを表 わす１０値を含んでいる。通信チャネルの例としては、非同期端末ライン、シー ケンシャルファイル、ＴＣＰ／ＩＰネットワーク、ＶＭＳメイルボックス接続、 ＸＬＩＢトランスポート、およびＤＥＣｎｅｔ Ｔａｓｋ−ｔｏ−Ｔａｓｋ 通 信などがある。ＸＬＩＢトランスポートを介して送られる信号は、ＳＩＭＵＬＡ ＴＥ＿ＸＥＶＥＮＴ要求、またはＭＯＶＥ＿ＰＯＩＮＴＥＲ要求（下記に詳述す る）を用いたｘｆｌｕｓｈ マクロを介して送信される。シーケンシャルファイ ルをキーボード入力およびマウス入力のソースとして用いることによって、応用 プログラムはライブユーザーなしに性能テストができる。さらに、ソフトウェア の回帰テストおよび比較テストも簡単になる。また“ｄｉｒｅｃｔｉｏｎ”フィ ールドはＣＯＮＦＩＧ＿ＩＯ要求が、入力に印加されているか、出力に印加され ているか、あるいはその両方であるかを指定する。

【００３６】 Ｘ Ｔｒａｐ 拡張が構成されるとその度に、クライアントは、ＳＴＡＲＴ＿ ＩＯ ｒｅｑｕｅｓｔＧｔｏ に、ＣＯＮＦＩＧ＿ＩＯ要求で構成された通信メ ディアを介してＩ／Ｏをスタートさせると共に、“ｗｒｉｔｅ”ルーチンを開始 させ、入力および出力情報を制御クライアントに送信する。この要求で指定され るデータは、（１）拡張が、出力プロトコル要求の一部である傍受されたテキス トストリングからセーブすべきキャラクタの数、および（２）拡張が、サーバー にテキストの１つ以上のストリングをスクリーン上に描くように要求する出力プ ロトコル要求、“ｐｏｌｙ Ｔｅｘｔ ８”を傍受するとき処理すべきテキスト スプリングの数、だけである。（テーブル６参照）

【００３７】 制御クライアントは、Ｘ Ｔｒａｐ 実行を要するワークステーションの遠隔 制御またはモニタを終了すると、ＳＴＯＰ＿ＩＯ要求をｘｆｌｕｓｈ マクロを 介してＸ Ｔｒａｐ サーバー拡張に送信する。これによって、ＩＯチャネルに 出入りするキャラクタの流れをストップさせる。クライアントは、実行をストッ プする準備ができない前は、ＸＴＲＡＰ＿ＲＥＳＥＴ要求をＸ Ｔｒａｐ 拡張 へ送信し、入力または出力の処理ルーチンのスワップがすべて行われないように する。

【００３８】 制御クライアントは、どの内部変数の値を知りたいときでも、ＸＴＲＡＰ＿Ｉ ＮＦＯ要求を送信することができる。

【００３９】 また制御クライアントは、プレイバックモードで、ＳＩＭＵＬＡＴＥ＿ＸＥＶ ＥＮＴ要求、およびＭＯＶＥ＿ＰＯＩＮＴＥＲ要求を使用し、入力をＸＬＬＢを 介してＸサーバーに送ることができる。テーブル７は、“ｘＸ Ｔｒａｐ Ｒｅ ｑ”構成における“ｄａｔａ”ユニオンのフォーマットを、ＳＩＭＵＬＡＴＥ＿ ＸＥＶＥＮＴおよびＭＯＶＥ＿ＰＯＩＮＴＥＲと一緒に使用する場合について示 したものである。ＳＩＭＵＬＡＴＥ＿ＸＥＶＥＮＴはキーボードイベントおよび マウスクリックイベントを送信するのに用いられる。

【００４０】 ＭＯＶＥ＿ＰＯＩＮＴＥＲはマウスモーションイベントを送信するのに用いら れる。変数“ｔｙｐｅ”は、送信されるイベントのタイプに対する識別子の値に セットされ、ＭＯＶＥ＿ＰＯＩＮＴＥＲ要求の場合、このタイプはマウスモーシ ョンイベントである。また、変数“ｄｅｔａｉｌ”はＳＩＭＵＬＡＴＥ＿ＸＥＶ ＥＮＴ要求のときに押されたり、放されたりするキーまたはマウスボタンに対す る識別子の値にセットされる。また、変数“Ｘ”および“ｙ”は、マウスカーソ ルの指定するスクリーン座標値にセットされる。

【００４１】 上記しか本考案の記述は、図解と説明のために行われたものである。従って、 本考案は開示した精細な形式に限定されるものではなく、上記の開示から多くの 改造や変形が可能であることは明白である。

【００４２】

【００４３】

【００４４】

【００４５】

【００４６】

【００４７】

【００４８】

【図面の簡単な説明】

【図１】本考案の一実施例によるサーバー拡張のコンピ
ュータシステムに用いた場合の一般的な機能を示す系統
図。

【図２】本考案によるサーバー拡張のデータ構成、なら
びに、この拡張がアクセスすべきＸサーバーデータ構成
を示す図。

【図３】 サーバー拡張の１つの動作モードにおける応
用プログラム実行を示すプロセスフロー図。

【図４】 サーバー拡張のもう１つの動作モードにおけ
る応用プログラム実行を示すプロセスフロー図。

【符号の説明】

１０ ＣＰＵ（セントラルプロセシングユニット） １２ サーバー（オペレーチングシステム） １４ ワークステーション １６ ウィンドウ １８ マウス ２０ キーボード ２２ サーバー拡張 ２４Ａ〜２４Ｎ クライアント（応用プログラム） ２６ シーケンシャルファイル ２８，３０ 入力ドライブ ４０ 出力ドライブ

フロントページの続き (72)考案者 ロバート トッド チェスラー アメリカ合衆国 ニューハンプシャー州 03063 ナシュア ケスラー ファーム ドライヴ 637−18 (72)考案者 アレン クウェンチン ジャミソン アメリカ合衆国 ニューハンプシャー州 03055 ミルフォード アッシュ ストリ ート ２エイ

Claims (3)

【実用新案登録請求の範囲】
1. 【請求項１】 セントラルプロセシングユニット（１
   ０）、ユーザーの指定した入力をその端末位置でコンピ
   ュータに入力する１つ以上の入力ドライブ（１８、２
   ０）、 テキストまたはグラフィック画像を表示する１つ以上の
   出力ドライブ（４０）上記セントラルプロセッシングユ
   ニットにより処理され、対話モードで動く応用プログラ
   ム（２４ａ、・・・、２４ｎ）を格納する記憶装置、 上記セントラルプロセシングユニット、上記１つ以上の
   入力ドライブ、上記１つ以上の出力ドライブ、及び上記
   記憶装置間での制御を行い、拡張入出力ルーチンのアド
   レスを記憶するサーバー用メモリブロックを有するオペ
   レーチングシステム（１２）、 上記サーバー用メモリブロックと対応し、サーバー入出
   力処理ルーチンのアドレスを記憶するサーバー拡張用メ
   モリブロックを有し、これによって上記入力ドライブに
   より入力された上記ユーザー指定の入力信号を、上記応
   用プログラムにより使用される以前に傍受し、上記入力
   信号に応答して上記応用プログラムから出力される出力
   命令を、上記１つ以上の出力ドライブに到達する以前に
   傍受するサーバー拡張（２２）、 上記サーバー用メモリブロック内のアドレスと上記サー
   バー拡張用メモリブロック内のアドレスとをスワップす
   る手段、及び 上記サーバー拡張により傍受された入力
   信号及び出力命令に関する情報を、これら入力信号及び
   出力命令が傍受された時間と共に格納する格納装置（２
   ６） を備えたことを特徴とするコンピュータシステ
   ム。
2. 【請求項２】 上記入力ドライブが、マウス又はキーボ
   ードであることを特徴とする請求項１記載のコンピュー
   タシステム。
3. 【請求項３】 上記入力ドライブが、遠隔端末エミュレ
   ター（ＲＴＥ）であることを特徴とする請求項１記載の
   コンピュータシステム。