JP2002521963A - 異種コンピュータシステム間の高速通信のための、仮想トランスポート層インターフェイスおよびメッセージ通信サブシステム - Google Patents

Abstract

(57)【要約】 直接相互接続されたそれぞれのコンピュータシステム上で実行するネットワークアプリケーションが、両システムがイーサネット等の従来のネットワーク通信経路を介してではなく、それら本来の機構を使用してそれらの機構を変更することなく互いに通信することができるように、アプリケーション間で相互接続を介して高速かつ待ち時間の短い通信を行なうことを可能にする、方法および装置。共存する、密結合された処理環境におけるアプリケーション間の通信は、従来のＴＣＰトランスポート層および従来のＩＰネットワーク層を、相互接続の通信プロトコルとは独立したインターフェイスを提供する、密結合されたシステム間でデータを転送するための信頼性の高いメッセージ通信サブシステム（「ＭＳＳ］）と、ネットワークアプリケーションに対してＴＣＰ／ＩＰ等の既知のトランスポート層プロトコルをシミュレートする仮想トランスポート層（「ＶＴＬ」）とに置換することによって提供される。ＭＳＳは、そのユーザに対して、種々の異種環境間でコントロール情報およびデータ情報を転送するための、多種多様の配信および通知機構を提示する、システムの、相互接続とは独立したメッセージ通信トランスポートである。ＶＴＬは、ＭＳＳ接続を使用して、セッション層への一貫性のある、相互接続とは独立したインターフェイスを提供する。ＶＴＬ／ＭＳＳプロトコルは、信頼性の高いデータ配信を行なうかまたは接続が利用できないことを表示する、同種のコネクション指向のインターフェイスを提供する。ＭＳＳがホストインターフェイスファンクションと直接インターフェイスするので、相互接続が変更されたときに必要となるのはＭＳＳインターフェイスの変更のみである。

Description

【発明の詳細な説明】

【０００１】

【著作権に関する注意】

この特許書類の開示の一部は、著作権の保護対象となる事項を含む。著作権者
は、米国特許商標庁のファイルまたは記録にある特許書類または特許開示につい
ては、何人による複写に対しても異議を唱えないが、それ以外の著作権について
は全て留保する。

【０００２】

【発明の分野】

本発明はコンピュータネットワーキングの分野に関し、より特定的には、２つ
の密結合された異種コンピュータシステムが、シミュレートされたまたは「仮想
」のトランスポート層インターフェイスを含む相互接続上でメッセージ通信シス
テムを介して互いに通信することを可能にする、装置および方法に関する。

【０００３】

【先行技術の説明】

異種のコンピュータシステムが、標準ＩＳＯおよび／または各企業独自のネッ
トワーキングプロトコルを使用してネットワークを介して互いに通信することの
できる機能は、よく知られている。ほとんどのコンピュータシステムは何らかの
形のネットワーキングアーキテクチャを有し、それらのプロトコルに従ってネッ
トワーキングを行なうことができる。たとえば、標準７層ＩＳＯ参照モデル（Re
ference Model）を含む汎用ネットワーキングプラットフォームは、ユーザの制
御下にあるアプリケーション、プレゼンテーションおよびセッションレベルと、
カーネル（オペレーティングシステム）の制御下にあるトランスポート、ネット
ワーク、データリンクおよび物理レベルとからなる、ネットワークスタックを含
む。典型的なネットワーキングアーキテクチャは、システムソフトウェアおよび
ハードウェアのどちらも含む。

【０００４】 図１は、ユニシスＡシリーズ（Unisys A Series）エンタープライズ・サーバ
１０がネットワーク１５上の他のホストまたはノードと通信するために使用する
、ネットワーキングアーキテクチャのコンポーネントを示すブロック図である。
このＡシリーズエンタープライズ・サーバ１０は、ユニシスＭＣＰオペレーティ
ングシステム１２を実行し、Ａシリーズのシャーシ内に格納された１または複数
のＩ／Ｏモジュール（I/O Modules、ＩＯＭ）１４を含むＩ／Ｏサブシステムを
有する。ＩＯＭ１４は、ＣＳ−ＢＵＳ ＩＩまたはＣＳ−ＢＵＳ ＩＩＩ（以後
、「ＣＳバス」と称する）と呼ばれる、ユニシス独自のＩ／Ｏバスアーキテクチ
ャを実装する。スロット１６ａ〜ｄ等の複数のカードスロットが、「チャネルア
ダプタ」と称されるインターフェイスカードをＣＳバスに接続するために設けら
れる。異なるグループまたはラックのチャネルアダプタスロットは、各々、チャ
ネルマネージャユニット（Channel Manager Unit、ＣＭＵ）（たとえば、ＣＭＵ
１８ａ、１８ｂ）によって制御される。ＩＯＭは、複数のＣＭＵを含み得るが、
その各々が、ＣＳバスを介して、異なるラックのチャネルアダプタカードスロッ
トを制御する。ＣＭＵは、ＣＳバスデータ転送プロトコルの物理層およびデータ
層を管理する。

【０００５】 チャネルアダプタカードは、各々、ＩＯＭ１４内の１または複数のチャネルア
ダプタカードスロットを占有し得るが、それらカードは、Ａシリーズエンタープ
ライズ・サーバ１０のためにさまざまなコネクティビティの解決手段を提供する
。たとえば、ユニシスは、スモールコンピュータシステムインターフェイス（Sm
all Computer System Interface、ＳＣＳＩ）の周辺機器をエンタープライズ・
サーバ１０に接続するためにＳＣＳＩプロトコルを実装する、チャネルアダプタ
カードを提供する。

【０００６】 ネットワークのコネクティビティのために、ユニシスは、さまざまな物理ネッ
トワーキングプロトコルをサポートする、いくつかのチャネルアダプタを提供す
る。これらのチャネルアダプタは通常、ネットワークプロセッサ（ＮＰ）と呼ば
れる。たとえば、ユニシスＩＣＰ２２およびＩＣＰ２６ネットワークプロセッサ
は、イーサネット（登録商標）（Ethernet）（登録商標）ネットワークプロトコ ルを実装するチャネルアダプタカードであって、これらは、Ａシリーズエンター プライズ・サーバ１０をイーサネットネットワークに接続するのに使用すること ができる。ユニシスはまた、ＦＤＤＩおよびＡＴＭネットワークへのコネクティ ビティのためのネットワークプロセッサを提供する。図１に示すように、種々の ネットワークコネクティビティ解決手段を提供するために、多種多様のネットワ ークプロセッサ（たとえば、ＮＰ２０ａ、２０ｂおよび２０ｃ）を、ＩＯＭ１４ のそれぞれのチャネルアダプタスロット（たとえば、スロット１６ｂ、１６ｃお よび１６ｄ）に組込むことができる。

【０００７】 （チャネルアダプタスロット１６ｄに組込まれた）ネットワークプロセッサ２
０ｃのより詳細な図に示されるように、ネットワークプロセッサは、たとえば、
Line0、Line1、…LineN等の、複数の異なるラインを含み得る。ここで、ライン
は、ネットワーク内の物理的なエンドポイントを表わす。たとえば、ユニシスＩ
ＣＰ２２ネットワークプロセッサは２つのラインを有し、その各々が、別個のイ
ーサネット接続を含む。すなわち、一方のラインが１つのイーサネットネットワ
ークに接続され、他方のラインが異なるイーサネットネットワークに接続され得
る。

【０００８】 ネットワークプロセッサの各ラインは、そのライン上に規定された１つのステ
ーショングループを有し得る。ステーショングループは、１または複数のステー
ションからなる。ステーションは、そのライン上の論理ダイアログを表わす、論
理的エンドポイントである。したがって、ネットワークプロセッサの任意のライ
ン上には２つ以上の論理ダイアログが存在し得るが、これは、多重化によって達
成される。たとえば、バロースネットワークアーキテクチャ・バージョン２プロ
トコル（Burroughs Network Architecture-Version 2 protocol、ＢＮＡｖ２）
等の、コネクション指向のネットワーキングプロトコルにおいては、１つのステ
ーションがネットワーク上の別のＢＮＡｖ２ホストとの論理ダイアログを表わし
、別のステーションが、異なるＢＮＡｖ２ホストとの論理ダイアログを表わし得
る。たとえば、図１に示すように、LineNのStation0は、ＢＮＡｖ２ホスト２２
との論理ダイアログを表わし、LineNのStation1はＢＮＡｖ２ホスト２４との論
理ダイアログを表わし得る。インターネットプロトコル（ＩＰ）のようなコネク
ション指向ではないネットワーキングプロトコルについては、そのプロトコルス
タックのためのすべての通信を扱うのに、１つのステーションしか定義する必要
はない。たとえば、図１において、LineNのStationNを、LineN上のすべてのＩＰ
トラフィックのための論理的エンドポイントとして定義することができる。ネッ
トワークプロセッサ２０ｃ上で実行するソフトウェアを含むローカルエリアネッ
トワークステーショングループ（Local Area Network Station Group、ＬＡＮＳ
Ｇ）モジュール２６は、ネットワークプロセッサ２０ｄの種々のライン上でステ
ーションおよびステーショングループを作成および維持してそれらにわたってデ
ータを送受信するための、呼出し可能な手続きを提供する。

【０００９】 ネットワークプロセッサ２０ｃ上で実行する他のソフトウェアコンポーネント
は、キューサービスプロバイダ（Queue Service Provider、ＱＳＰ）モジュール
２８を含み、これは、ＮＰサポート４０とチャネルアダプタとの間のメッセージ
の受け渡しを行なう。ＱＳＰモジュール２６はまた、任意のＮＰ上で規定された
すべてのステーションのために、データを多重化および逆多重化する。効率を高
めるためにいくつかのデータはブロック化され、他のデータはそのままである。
他のコンポーネントとしては、ネットワークサービスマネージャスタブ（Networ
k Services Manager Stub、ＮＳＭ−ＳＴＵＢ）３０と、リンク層マネージャス
タブ（Link Layer Manager Stub、ＬＬＭ−ＳＴＵＢ）３２との、２つのスタブ
モジュールを含む。これらは、ＭＣＰ環境内のモジュールに対して、コアネット
ワークサービス（Core Network Services、ＣＮＳ）ソフトウェアコンポーネン
ト３４の対応するモジュールとインターフェイスをとる。

【００１０】 通常、ネットワークプロセッサ（たとえば、ＮＰ２０ａ、２０ｂまたは２０ｃ
）は、７層ＩＳＯ参照モデルのデータリンク層および物理層を実装する。クライ
アントアプリケーション４６が、ＢＮＡｖ２およびＴＣＰ／ＩＰネットワーキン
グプロトコル等の、ネットワーク１５の異なるホスト上で実行するアプリケーシ
ョンと通信するために用いたいと望むであろう、より上位のネットワーキングプ
ロトコルは、Ａシリーズシステム１０上に、ネットワークプロトコルプロバイダ
として実装される。ネットワークプロトコルプロバイダは、これらのより上位の
ネットワーキングプロトコルを実装するソフトウェアモジュールである。たとえ
ば、ユニシスは、ＢＮＡｖ２のホスト常駐ネットワークプロバイダ（Host Resid
ent Network Provider、ＨＲＮＰ）モジュールおよびＴＣＰ／ＩＰのＨＲＮＰモ
ジュールのどちらも提供する。図１の例においては、ＢＮＡｖ２ ＨＲＮＰ４２
およびＴＣＰ／ＩＰ ＨＲＮＰ４４が示されている。

【００１１】 コアネットワークサービス（ＣＮＳ）ソフトウェア３４は、ネットワークプロ
トコルプロバイダ４２、４４をサポートし、ネットワークプロセッサおよびその
上に定義されたステーショングループの初期化および保守を行なう。具体的には
、ＣＮＳ３４は、システムに組込まれたネットワークプロセッサ（たとえば、２
０ａ、２０ｂ、２０ｃ）を初期化しかつ管理する、ネットワークサービスマネー
ジャ（Network Services Manager、ＮＳＭ）３６と、任意のネットワークプロセ
ッサ上に規定された各ステーショングループのアイデンティティおよび属性を初
期化しかつ維持する、リンク層マネージャ（Link Layer Manager、ＬＬＭ）３８
とを含む。ＣＮＳ３４の別のコンポーネント（図示せず）は、ネットワークプロ
セッサ上に作成されたステーショングループおよびステーションに関連する属性
の妥当性を検証する。これらの属性は、それらのステーションが規定されるとき
に、コントロールダイアログを介して、ネットワークプロセッサとＣＮＳ３４と
の間で受け渡しされる。ＮＳＭモジュール３６およびＬＬＭモジュール３８のた
めのスタブ手続きと同様に、ネットワークプロセッサは、ＣＮＳ３４の属性ハン
ドラに対応するスタブ手続き（ＬＬＡＨ、図示せず）もまた有する。ＮＰＳＵＰ
ＰＯＲＴソフトウェアライブラリ４０および、ＭＣＰオペレーティングシステム
１２の各部分は、ネットワークプロセッサとＣＮＳ３４とネットワークプロトコ
ルプロバイダ４２、４４との間のインターフェイスとしての役割を果たすルーチ
ンおよび手続きコールを提供し、また、ＮＰへのソフトウェアのローディングお
よびそれらの状態のダンピングを制御する。

【００１２】 各ネットワークプロセッサは、システム１０内のそのネットワークプロセッサ
を一意に識別する、関連する識別子を有する。ネットワークプロセッサが初期化
されてオンラインとされるとき、ネットワークプロセッサ内のＮＳＭ−ＳＴＵＢ
３０は、ＮＳＭ３６にその識別子を渡すために、コントロールダイアログを介し
てＣＮＳ３４のＮＳＭ３６とインターフェイスをとる。ＮＳＭ３６は、すべての
アクティブなネットワークプロセッサの識別子を管理する。

【００１３】 任意のネットワークプロセッサのために規定された各ステーショングループお
よびステーションはまた、それに関連する一意の識別子を有する。ネットワーク
プロセッサ上のＬＬＭ−ＳＴＵＢ３２とＣＮＳ３４のＬＬＭ３８との間に構築さ
れたコントロールダイアログを介して、ステーションおよびステーショングルー
プの識別子は、初期化中にＬＬＭ３８に渡される。ＬＬＭ３８内では、１つのス
テーションが１つの接続に対応し、１つのステーショングループが１つの接続グ
ループに対応する。

【００１４】 上述のように、ネットワークプロセッサの単一の物理ライン上の複数のステー
ション（すなわち、ステーショングループ）を定義する機能は、多重化によって
達成される。具体的には、ネットワークプロセッサ内のＱＳＰ２８は、任意のラ
イン上の複数のステーションに対する、入ってくるデータおよび出て行くデータ
を多重化する。さらに、ＱＳＰ２８は、ＮＳＭ３６とＮＳＭ−ＳＴＵＢ３０との
間、および、ＬＬＭ３８とＬＬＭ−ＳＴＵＢ３２との間で、要求および応答デー
タの分配を担当する。この目的のために、各ステーションを含むＭＣＰ１２、Ｎ
ＳＭ−ＳＴＵＢ３０およびＬＬＭ−ＳＴＵＢ３２から出て行くデータを受取る、
ネットワークプロセッサ上の各エンティティには、ＱＳＰ２８によって一意のリ
モートキューリファレンス（Remote Queue Reference、ＲＱＲ）が割当てられる
。ＮＳＭ−ＳＴＵＢのＲＱＲは、ＮＰがロードされるときに、ＮＰＳＵＰＰＯＲ
Ｔ４０を介してＣＮＳ３４内のＮＳＭ３６に報告される。ＬＬＭ−ＳＴＵＢのＲ
ＱＲは、ネットワークプロセッサが初期化するときに、ＮＳＭ−ＳＴＵＢ３０に
よってＮＳＭ３６を介してＬＬＭ３８に報告される。ステーションのＲＱＲはす
べて、ステーションが開くときに、ＨＲＮＰ４２、４４に報告される。

【００１５】 クライアントアプリケーションは、ネットワーク１５を介してネットワーク１
５上の別のホストまたはノード、たとえば別のＢＮＡｖ２ホスト２２、２４また
は別のＴＣＰ／ＩＰホスト２５へとデータを送信するように要求されると、適切
なネットワークプロトコルプロバイダ、たとえば４２、４４のサービスを呼出す
。ネットワークプロトコルプロバイダ４２、４４は、データを出力すべき適切な
ネットワークプロセッサおよびステーションを判定し、ネットワーク層の各々の
ためにプロトコルヘッダを追加して、ネットワークプロセッサの識別子およびス
テーションのＲＱＲを含む、ＭＣＰ１２への対応する要求を作成する。そのデー
タおよび関連のＲＱＲは、ＭＣＰ１２からネットワークプロセッサ（たとえば、
ネットワークプロセッサ２０ｃ）上のＱＳＰ２８へと渡され、そのネットワーク
プロセッサが、ＬＡＮＳＧモジュール２６と連動して、そのデータを適切なライ
ン（たとえば、Line0、Line1、…またはLineN）を介してネットワーク１５へと
、指定されたステーションによって表わされる論理ダイアログの一部として、送
り出す。

【００１６】 データが任意のライン上でネットワーク１５から受取られると、ＬＡＮＳＧモ
ジュール２６はそのデータに関連するヘッダの情報から、そのデータが向けられ
るべきステーション（すなわち、論理ダイアログ）を判断する。ＬＡＮＳＧモジ
ュール２６およびＱＳＰモジュール２８は、ＭＣＰ１２およびＮＰＳＵＰＰＯＲ
Ｔライブラリ４０の各部分と連動して、受信したデータをそのステーションに関
連する適切なネットワークプロトコルプロバイダ４２、４４へと、どのステーシ
ョンがそのデータを受取ったかを示す表示とともに渡す。たとえば、図１に示す
ネットワークプロセッサ２０ｃのLineN上のステーションのうちの１つ（たとえ
ば、Station0）が、ＢＮＡｖ２ ＨＲＮＰ４２のための論理的エンドポイントと
して定義され、異なるステーション（たとえば、Station1）が、ＴＣＰ／ＩＰ
ＨＲＮＰ４４のための、LineN上のすべてのＩＰトラフィックがその上で受取ら
れる、論理的エンドポイントとして定義され得る。データの１フレームがLineN
上でネットワークから受信されると、ＬＡＮＳＧモジュール２６は、ヘッダの情
報から、どのネットワークプロトコルプロバイダ（すなわち、ステーション）が
そのデータを受信すべきかを判断する。この判断は、（ジョンソン（Johnson）
他の）「ワークステーションを複数のコンピュータプラットフォームにインター
フェイスするための方法および装置（"Method and Apparatus for Interfacing
a Workstation to a Plurality of Computer Platforms"）」と題された、共通
に譲渡された米国特許番号第５，３７９，２９６号に記載されている方法に従っ
て行なわれる。

【００１７】 上述のネットワーキングアーキテクチャは、Ａシリーズコンピュータにおいて
使用されるのに加えて、ユニシスクリアパス（Unisys ClearPath）ＨＭＰ ＮＸ
エンタープライズ・サーバにおいても用いられる。クリアパスＨＭＰ ＮＸサー
バは、マイクロソフトウィンドウズＮＴ（Microsoft Windows NT）を実行するサ
ーバと密結合された、Ａシリーズエンタープライズ・サーバを含む。ここで、「
マイクロソフト（"Microsoft"）」、「ウィンドウズ（"Windows"）」および「ウ
ィンドウズＮＴ（"Windows NT"）」は、マイクロソフト・コーポレイション（Mi
crosoft Corporation）の登録商標である。上述のネットワーキングアーキテク
チャに関するさらなる情報は、以下の文献に見出される。これらの文献はすべて
、本発明の譲受人であるユニシス・コーポレイション（Unisys Corporation）か
ら入手可能であり、その全文がここに引用により援用される。

【００１８】 「ウィンドウズＮＴネットワークサービスを用いるクリアパスＨＭＰ ＮＸシ
リーズの実装ガイド（"ClearPath HMP NX Series with Windows NT Network Ser
vices Implementation Guide"）」(Part No. 4198 6670); 「ＢＮＡ／ＣＮＳネットワーク実装ガイド、第２巻：構成（"BNA/CNS Network
Implementation Guide, Volume 2: Configuration"）」(Part No. 3789 7014)
； 「ウィンドウズＮＴを用いるクリアパスＨＭＰ ＮＸシリーズの実装およびオ
ペレーションガイド（"ClearPath HMP NX Series with Windows NT Implementat
ions and Operation Guide"）」(Part No. 8807 6542)； 「ウィンドウズＮＴを用いるクリアパスＨＭＰ ＮＸシリーズのマイグレーシ
ョンガイド（"ClearPath HMP NX Series with Windows NT Migration Guide"）
」(Part No. 8807 7730)； 「ネットワーキング機能概要（"Networking Capabilities Overview"）」(Par
t No. 3789 7139)； 「ネットワーキングオペレーション参照マニュアル、第１巻および第２巻：コ
マンドおよび問合せ（"Networking Operations Reference Manual, Volumes 1 a
nd 2: Commands and Inquiries"）」(Part No. 3787 7917)；および、 「ネットワーキングプロダクツ導入ガイド（"Networking Products Installat
ion Guide"）」(Part No. 4198 4840)。

【００１９】 イーサネットベースのチャネルアダプタであるユニシスＩＣＰ２２ネットワー
クプロセッサを使用して、ユニシスＡシリーズエンタープライズ・サーバがネッ
トワークを介してワークステーションまたはパーソナルコンピュータ（ＰＣ）と
通信することは、過去においても可能であった。この機能の一例を図２に示す。
この例において、Ａシリーズエンタープライズ・サーバ１０は、マイクロソフト
ウィンドウズＮＴオペレーティングシステム（以後、「ＮＴサーバ」）を実行す
る、インテル（Intel）ベースのワークステーション４８と通信する。このＡシ
リーズエンタープライズ・サーバ１０は、たとえばユニシスＩＣＰ２２イーサネ
ットベースネットワークプロセッサであり得るネットワークプロセッサ２０ａを
介して、ネットワークに接続される。

【００２０】 ＮＴサーバ４８のＩ／Ｏサブシステムは、ＮＴオペレーティングシステムカー
ネル、ＥＩＳＡまたはＰＣＩバス５２、および、適切なデバイスドライバソフト
ウェアを含む。ネットワークのコネクティビティを提供するために、ネットワー
クインターフェイスカード（ＮＩＣ）５０がＮＴサーバ４８上の利用可能なバス
スロットに組込まれる。ＮＴサーバは、ＰＣIバス標準およびＥＩＳＡバス標準
の一方または両方をサポートし得る。ＮＩＣは、どちらのバス標準に対しても利
用可能である。

【００２１】 ＮＩＣカード５０とともに通常販売されるＮＩＣデバイスドライバ５４は、Ｎ
Ｔオペレーティングシステムのカーネル空間に組込まれる。ＮＩＣデバイスドラ
イバ５４は、トランスポート（ＴＣＰ）プロトコルならびにネットワークおよび
データリンク（ＩＰ）プロトコルの処理系等の、より上位のネットワークプロト
コルプロバイダとインターフェイスをとる。マイクロソフト・コーポレイション
は、ＴＣＰＩＰ．ＳＹＳ５８という名の、トランスポートプロトコルドライバと
も称される、カーネルレベルのデバイスドライバの形をとるＴＣＰ／ＩＰプロト
コルの処理系を提供する。ＴＣＰＩＰ．ＳＹＳ５８は、ＮＤＩＳ５６、すなわち
、マイクロソフト社と３Ｃｏｍ．によって共同開発された業界標準のネットワー
クドライバインターフェイス仕様（Network Driver Interface Specification）
を介して、ＮＩＣデバイスドライバ５４とインターフェイスをとる。ＮＤＩＳ５
６は、ＩＳＯモデルのデータリンク、ネットワークおよびトランスポート層を実
装する、ハードウェアとは独立したプロトコルドライバ、たとえばＴＣＰＩＰ．
ＳＹＳ５８と、ＮＩＣハードウェアに対するインターフェイスを提供しかつＩＳ
Ｏモデルの物理層に対応する、ハードウェアに依存したＮＩＣドライバ５４との
、通信のためのインターフェイスを規定する。ＮＴサーバ上のクライアントプロ
グラム６０は、ＮＴオペレーティングシステムを介してＴＣＰＩＰ．ＳＹＳプロ
トコルドライバ５８に対して好適なコールを発行することによって、ＴＣＰ／Ｉ
Ｐプロトコルに従ってネットワーク１５上で通信することが可能であり、Ａシリ
ーズサーバ１０とＮＴサーバ４８は、ネットワーク１５上で、ＩＳＯモデルの物
理層で通信する。

【００２２】 Ａシリーズエンタープライズ・サーバのようなユニシス独自のシステムのため
にＮＩＣカードを開発するのにかかるコストを避けるために、やはり本願の譲受
人に譲渡されその全文がここに引用により援用される、同時係属中の米国特許出
願連続番号第０９／０８８，４２１号において、Ａシリーズエンタープライズ・
サーバ１０とＮＴサーバ４８との間に直接の相互接続を設けて、両システムがＮ
Ｔサーバ上に組込まれた共用ネットワークインターフェイスカードを介してネッ
トワークに接続することができるようにすることが提案されている。この発明は
、ユニシスのクリアパスＨＭＰ ＮＸコンピュータシステム（「クリアパスシス
テム」）に配置される、協調型ネットワーキングプラットフォーム（Cooperativ
e Networking Platform、ＣＮＰ）の一部として実装される。今から説明するよ
うに、クリアパスシステムは、ユニシスＡシリーズエンタープライズ・サーバ１
００および、ウィンドウズＮＴ１０２を実行するインテルベースのサーバ１０２
（「ＮＴサーバ」）を含む。

【００２３】 図３、４および５に示すように、ＣＮＰは種々の形をとり得る。これらの図に
示すように、相互接続は、Ａシリーズサーバ１００のＩ／ＯサブシステムをＮＴ
サーバ１０２のＩ／Ｏサブシステムと結合して、システム間に比較的高速のデー
タ経路を提供する。この相互接続は、好ましくは、Ａシリーズエンタープライズ
・サーバ１００のＩ／ＯサブシステムとＮＴサーバ１０２のＩ／Ｏサブシステム
との間の物理的な接続、および、ＮＴサーバ１０２上の他のソフトウェアモジュ
ールによるその物理的な接続へのアクセスを制御する相互接続デバイスドライバ
を含む。

【００２４】 図３に示す実施例においては、この物理的な接続は、Ａシリーズサーバ１００
のチャネルアダプタスロットに組込まれたフィードスルーカード６２と、ＮＴサ
ーバ１０２のＩ／ＯバスのＥＩＳＡスロットに組込まれたＥＩＳＡパーソナルコ
ンピュータチャネルアダプタ（EISA Personal Computer Channel Adapter、ＥＰ
ＣＣＡ）カード６６と、Ａシリーズサーバ１００のＣＳ−ＢＵＳ ＩＩをフィー
ドスルーカード６２を介してＥＰＣＣＡカード６６に接続するＣＳ−ＢＵＳ Ｉ
Ｉケーブル６４とを含む。相互接続デバイスドライバ（ＩＣＤ）７０は、ＮＴオ
ペレーティングシステムのカーネル空間に組込まれて、ＮＴサーバ１０２上の他
のモジュールによる物理的接続（具体的にはＥＰＣＣＡカード６６）へのアクセ
スを制御する。図３に示した先行技術による実施例はまた、図１のＱＳＰ２８と
同様に機能するキューサービスプロバイダ（Queue Service Provider）モジュー
ル７６と、図１のＬＡＮＳＧモジュール２６と同様に機能するＬＡＮＳＧモジュ
ール７８と、図１の対応するコンポーネント３０、３２と同様に機能する、ＣＮ
Ｐ．ＥＸＥ８０のＮＳＭ−ＳＴＵＢモジュール８４およびＬＬＭ−ＳＴＵＢモジ
ュール８６とを含む。さらに、伝統的なユニシスのネットワーキングアーキテク
チャにおける同様のコンポーネント（図１には図示せず）と同様に機能する、Ｃ
ＮＰ．ＥＸＥ８０のＬＤＭモジュール８２およびＬＬＡＨモジュール８８が設け
られる。

【００２５】 図３において、ＰＣＣＡドライバ７２およびＯＰＥＮＣＡドライバを含む相互
接続デバイスドライバ７０と、フィードスルーカード６２、ケーブル６４および
ＥＰＣＣＡカード６６によって形成される物理的接続とが合せて、ホストインタ
ーフェイスファンクション（Host Interface Function、ＨＩＦ）を規定する。
ＱＳＰ７６と、ＮＩＦの相互接続デバイスドライバ７０との手続き的インターフ
ェイスは、ＱＳＰ７６をＨＩＦから分離するように設計される。このような設計
によって、以下の詳細な説明から明らかとなるように、本発明をＨＩＦの種々の
実装例とともに用いることが可能となる。具体的には、ＱＳＰ７６と相互接続デ
バイスドライバ７０との間の手続き的インターフェイスは、各モジュールがその
機能を実現する手続きへのエントリポイント（すなわち、ポインタ）を、必要と
される変数値とともに発行するプロセスを通して構築される。別のデバイスドラ
イバエンティティがこれらのエントリポイントの記録を維持する一方で、ＨＩＦ
の相互接続デバイスドライバ７０がエントリポイントおよびそれらの属性を登録
し、ＱＳＰ７６がエントリポイントを登録する。

【００２６】 エントリポイント関数のうち１つの関数を呼出すには、その関数に対して登録
されたエントリポイントがコールされる。このような間接的な方法の結果として
、ＨＩＦの異なる実装例につき異なる相互接続デバイスドライバが、ＱＳＰ７６
に対して完全にトランスペアレントな態様で組込まれる。

【００２７】 図４および図５は、ＨＩＦの２つの代替的な実施例を示す。これらは、手続き
的インターフェイスの設計によってもたらされるモジュール性を示している。図
４において、物理的接続（すなわち、フィードスルーカード６２、ケーブル６４
およびＥＰＣＣＡカード６６）は、ＰＣＩブリッジ（Bridge）カード６７に置換
されており、このカード６７がケーブル６５を介して、Ａシリーズサーバ１００
のＩＯＭ１４のＣＭＵ１８ｂのうちの１つ上のポートへと直接接続する。このよ
うにＣＭＵ１８ｂに直接接続することによって、ＣＳ−ＢＵＳ ＩＩプロトコル
に固有の待ち時間がいくぶん回避され、２つのサーバ１００、１０２のＩ／Ｏサ
ブシステム間に、より直接的な、より高速の接続が提供される。物理的接続が変
化するので、修正された相互接続デバイスドライバ７０′が提供される。この修
正された相互接続デバイスドライバ７０′は、ＱＳＰ７６とＰＣＩブリッジカー
ド６７上のハードウェアとのインターフェイスを提供する、単一のデバイスドラ
イバモジュール、ＰＸＮ７３を含むが、その手続き的インターフェイスおよび、
ＱＳＰ７６と相互接続デバイスドライバ７０′とがそのインターフェイスのそれ
ぞれの手続きに対するエントリポイントを登録する機構は、変化しない。したが
って、ＨＩＦに対する変更は、ＱＳＰ７６に対しても、協調型ネットワーキング
プラットフォーム（ＣＮＰ）を含む他のモジュールに対しても、トランスペアレ
ントである。

【００２８】 図５は、Ａシリーズサーバ１００がＮＴサーバ１０２内のソフトウェアによっ
てエミュレートされる実施例を示す。ユニシスは、このようなエミュレートされ
たシステムを、クリアパスＨＭＰ ＮＫ４２００シリーズのエンタープライズ・
サーバ内に提供する。この実施例において、物理的な接続は、エミュレートされ
たＩ／Ｏサブシステム１４′のメモリ空間と、ＮＴシステム１０２のメモリ空間
との、メモリ同士の接続６３となるようにエミュレートされる。このエミュレー
トされた接続６３は、図３のハードウェアの実装例におけるフィードスルーカー
ド６２、ケーブル６４、ＥＰＣＣＡカード６６およびＰＣＣＡ７２のコンポーネ
ントと同様に機能する。この実施例における相互接続デバイスドライバ７０″は
、図３の実装例におけるＯＰＥＮＣＡモジュール７４の修正された形７４′を含
むが、修正されたＯＰＥＮＣＡモジュール７４′とＱＳＰ７６との手続き的イン
ターフェイスはやはり変化しない。したがって、エミュレートされたＡシリーズ
サーバ１００および、そのサーバ１００とＮＴサーバ１０２とのエミュレートさ
れた接続６３は、ＱＳＰ７６に対しても、協調型ネットワーキングプラットフォ
ーム（ＣＮＰ）を含む本発明の他のモジュールに対しても、トランスペアレント
である。

【００２９】 また、やはり本願の譲受人に譲渡されその全文がここに引用により援用される
、同時係属中の米国特許出願連続番号第０９／０８８，５５２号に記載されてい
るように、「仮想」ＬＡＮデバイスドライバ７９およびＮＤＩＳミニポートイン
ターフェイスライブラリ（NDIS Miniport Interface Library）８１は、図３か
ら図５に示したシステム内のＬＡＮＳＧおよび残りの相互接続コンポーネントと
ともに、Ａシリーズサーバ１００とＮＴサーバ１０２との間に高速かつ待ち時間
の短い通信経路を提供する。そこに記載されているように、これらのモジュール
は、物理的な接続（たとえば、フィードスルーカード６２、ケーブル６４、ＥＰ
ＣＣＡカード６６および相互接続デバイスドライバ７０）と共同して、図１に示
しかつ上述したような、伝統的なチャネルアダプタベースのネットワークプロセ
ッサをシミュレートする。ＶＬＡＮ７９は、Ａシリーズエンタープライズ・サー
バ１００とＮＴサーバ１０２とが、相当低速であり得るイーサネット等の従来の
ネットワーク通信経路ではなく、それら本来の機構を使用して、互いに通信する
ことができるようにする。特定的には、ＶＬＡＮ７９は、ＨＩＦとの物理的レベ
ルをシミュレートすることによって、Ａシリーズエンタープライズ・サーバ１０
０とＮＴサーバ１０２とが、ＩＳＯネットワーク参照モデルのデータリンクレベ
ルで通信することができるようにする。

【００３０】 データをシステム間でデータリンクレベルではなくトランスポートレベルでポ
イントツーポイントで転送することができるように、相互接続を介したＡシリー
ズエンタープライズ・サーバ１００とＮＴサーバ１０２とのＴＣＰトランスポー
トプロトコルおよびＩＰネットワーキングプロトコルをシミュレートすることに
よって、クリアパスシステムの通信効率をさらに改善することが望まれる。トラ
ンスポート層プロトコルおよびネットワーク層プロトコルをシミュレートするこ
とで、データをネットワークプロトコル情報を前に付加した小さなデータチャン
クへと分解することなくより大きなブロックで伝送することのできる、より信頼
性の高いネットワーク接続を使用することによって、ＴＣＰ／ＩＰプロトコル固
有の限界を取除くこともまた望まれる。もちろん、これは、ユーザに対してトラ
ンスペアレントな態様で（すなわち、セッションレベルに影響を及ぼさないよう
に）行なわれることが望まれるが、本発明はこのような機能を提供する。

【００３１】

【発明の概要】

本発明は、第１のコンピュータシステム上で実行する第１のネットワークアプ
リケーションと、第１のコンピュータシステムに直接相互接続されかつ密結合さ
れた第２のコンピュータシステム上で実行する第２のネットワークアプリケーシ
ョンとが、両システムがＴＣＰ／ＩＰおよびイーサネット等の従来のネットワー
ク通信経路を介してではなくそれら本来の機構を使用してネットワークアプリケ
ーションに影響を及ぼすことなく互いに通信することができるように、それらア
プリケーション間の相互接続を介して高速かつ短い待ち時間で通信することを可
能にする、方法および装置に向けられる。本発明の好ましい実施例に従えば、本
発明は、第１のコンピュータシステムの入出力（Ｉ／Ｏ）サブシステムと第２の
コンピュータシステムのＩ／Ｏサブシステムとを結合しかつデータをそれにわた
ってネットワークインターフェイスカードとは独立してシステム間で伝送するこ
とのできる相互接続と、汎用トランスポートインターフェイスを提供しかつ第１
および第２のネットワークアプリケーションに対して既知のトランスポート層プ
ロトコルをシミュレートする、第１および第２のコンピュータシステム上で実行
する相互接続メッセージ通信システムとを含む。本発明は、第１および第２のネ
ットワークアプリケーションが、第１および第２のネットワークアプリケーショ
ンにトランスペアレントな態様で通信することができるようにする（たとえば、
データは、第１および第２のコンピュータシステム上のアプリケーション間で、
セッション層および該第１および第２のネットワークアプリケーションを含むよ
り上位層の通信プロトコルに影響を及ぼすことなく転送され得る）。

【００３２】 第１のコンピュータシステムのＩ／Ｏサブシステムと第２のコンピュータシス
テムのＩ／Ｏサブシステムとの間の相互接続は、好ましくは、データをその上で
伝送することのできる、Ｉ／Ｏサブシステム間の物理的接続を含む。本発明は、
第１および第２のコンピュータシステム間のこの相互接続についてどのような限
定も課しておらず、むしろ、改良された相互接続機構が利用可能となった時点で
その機構も利用することができるようにすることを意図している。相互接続メッ
セージ通信システムは、メッセージ通信サブシステム（「ＭＳＳ」）を含む。Ｍ
ＳＳは、該相互接続の通信プロトコルとは独立した汎用トランスポートインター
フェイスを提供し、さらに、その相互接続の両側に該相互接続の通信プロトコル
に依存するさらなるインターフェイスを提供する。これにより、相互接続に変更
が加えられた場合にも、そのさらなるインターフェイスのみを変更すればよくな
る。

【００３３】 好ましくは、ＭＳＳは、第１および第２の各コンピュータシステム上にＭＳＳ
コンポーネントを含み、各ＭＳＳコンポーネントには、相互接続とは独立したイ
ンターフェイスを介して、少なくとも１つのローカルＭＳＳユーザが接続されて
いる。第１のコンピュータシステム上のＭＳＳコンポーネントは、第２のコンピ
ュータシステム上の相補的な各リモートＭＳＳユーザとのダイアログを作成する
。各ＭＳＳコンポーネントは、相互接続を介してアクセス可能な相補的リモート
ＭＳＳユーザに関する情報をローカルＭＳＳユーザに対して提供するローカルＭ
ＳＳユーザのためのダイアログテーブルを構築しかつ相補的リモートＭＳＳユー
ザが追加されたり取除かれたりした場合にそのダイアログテーブルを更新するた
めの手段を含む。各ＭＳＳコンポーネントはまた、ローカルＭＳＳユーザが相互
接続を介して相補的リモートＭＳＳユーザとのダイアログを構築し、それに関す
る状態を受信しかつそのダイアログを無効にすることができるようにする、ダイ
アログ管理機能を行なうための手段を含む。各ＭＳＳコンポーネントはさらに、
ローカルＭＳＳユーザと相補的リモートＭＳＳユーザとが、用いられる相互接続
にかかわりなくコントロールメッセージを互いに受渡すことができるようにする
、メッセージ制御機能を行なうための手段を含む。各ＭＳＳコンポーネントはさ
らに、第１および第２のコンピュータシステム間のデータ転送を最適化するため
に、ローカルＭＳＳユーザとリモートＭＳＳユーザとの間で構築されたデータダ
イアログを介して、ローカルＭＳＳユーザとリモートＭＳＳユーザとの間でデー
タを転送するための手段を含む。

【００３４】 本発明のＭＳＳの主たる利点は、相互接続に依存する機構を単一のコンポーネ
ントから分離する機能である。これにより、相互接続とは独立したＭＳＳインタ
ーフェイスを介して（すなわち「ＭＳＳユーザ」として）システム間の通信を要
求するコンポーネントを実装することによって付加的な機能が加えられると、既
存の相互接続に対する変更および付加的な相互接続の組込みが、ＭＳＳユーザに
影響を与えることなく、もっぱらＭＳＳコンポーネントのみを介して、行なうこ
とができるようになる。

【００３５】 現時点において好ましい実施例においては、ローカルＭＳＳユーザの１つおよ
びリモートＭＳＳユーザの１つは、第１および第２のネットワークアプリケーシ
ョンが相互接続を介して第１および第２のネットワークアプリケーションに対し
てトランスペアレントな態様で互いに通信することができるように、既知のトラ
ンスポート層プロトコルをシミュレートする、相補的な仮想トランスポート層（
「ＶＴＬ」）コンポーネントである。これら相補的なＶＴＬコンポーネントが合
せて、ＭＳＳを用いて、トランスポートダイアログの構築、データ転送およびト
ランスポートダイアログの終了という従来のトランスポート機能を行なう。好ま
しくは、該ＶＴＬコンポーネントは、第１および第２のネットワークアプリケー
ションとインターフェイスをとり、また、好ましくは、第１および第２のコンピ
ュータシステム上に、ＭＳＳの相互接続とは独立したインターフェイスを通じて
ＭＳＳに接続される相補的なＭＳＳユーザとして実装される。ＭＳＳのメッセー
ジ制御機能は、ＶＴＬコンポーネントがデータダイアログの作成およびオープン
を調整するためにメッセージのシーケンスをそれを通じて交換することのできる
、信頼性の高いコントロールダイアログを作成する。

【００３６】 データが第１のネットワークアプリケーションから第２のネットワークアプリ
ケーションへと相互接続を介して転送される場合、第１のネットワークアプリケ
ーションとインターフェイスするＶＴＬコンポーネントが、その第２のネットワ
ークアプリケーションに転送されるべきデータにＶＴＬデータ転送ヘッダをアペ
ンドして、開いたダイアログを介してデータ転送を開始する。

【００３７】 本発明の範囲はまた、第１のコンピュータシステム上で実行する第１のネット
ワークアプリケーションと、第１のコンピュータシステムの入出力（Ｉ／Ｏ）サ
ブシステムと第２のコンピュータシステムのＩ／Ｏサブシステムとの間の相互接
続を介して第１のコンピュータシステムに直接相互接続されかつ密結合された第
２のコンピュータシステム上で実行する第２のネットワークアプリケーションと
が、ネットワークインターフェイスカートとは独立しかつ第１および第２のネッ
トワークアプリケーションの本来のプロトコルで、それらの間でデータを伝送す
ることができるようにする方法を含む。本発明に従えば、この方法は、 第１および第２の各コンピュータシステム上の第１および第２のネットワーク
アプリケーションに対して既知のトランスポート層プロトコルをシミュレートす
るステップと、 該相互接続を介して、第１および第２のネットワークアプリケーションがそれ
ら自身にトランスペアレントな態様で通信することのできるダイアログを作成す
るステップと、 第１および第２のネットワークアプリケーションの間でデータを転送するため
にそのダイアログを開くステップと、 転送されるべきデータにデータ転送ヘッダを付与するステップと、 開いたダイアログを介して相互接続にわたってデータおよびデータ転送ヘッダ
を転送するステップとを含む。

【００３８】 好ましい実施例においては、第１および第２のアプリケーションの複数対のた
めに相互接続にわたって複数のダイアログが作成されて、各対をなすアプリケー
ションが、その対における第１および第２のアプリケーションの本来のプロトコ
ルに対してトランスペアレントな態様で通信することができるようにされ、さら
に、その対におけるアプリケーション間のデータ転送のために使用されるべきダ
イアログが特定される。

【００３９】 本発明の仮想トランスポート層の主要な利点は、スループットが向上すること
と、プロセッサの消費が減じられることである。これらの改善は、（１）基礎と
なるすべての相互接続が概して、ネットワーキングのために典型的に使用される
よりもはるかに大きなメッセージ転送サイズをサポートすることが可能であるた
めに、伝統的なトランスポートプロトコルに関連するフラグメント化／リアセン
ブリにかかるオーバヘッドが最小に抑えられ、（２）基礎となる相互接続の信頼
性が概して高いために、本発明のメッセージ通信システムが伝統的なＴＣＰ／Ｉ
Ｐプロトコルの受信通知および再送信のアルゴリズムを実装する必要がない、と
いう、２つの重要な要因による。また、基礎となる相互接続の信頼性が低い場合
には、該メッセージ通信システムがそのコネクション指向のメッセージ通信プロ
トコルによって、高い信頼性を提供することが可能である。

【００４０】 本発明のさらなる特徴および利点は、以下の説明から明らかとなるであろう。 本発明の以上の概要および以下の好ましい実施例の詳細な説明は、添付の図面
と関連して読むことにより、よりよく理解されるであろう。本発明を図示する目
的で、図面にはいくつかの実施例を示す。これらは現時点において好ましい実施
例ではあるが、本発明は、開示された特定的な方法および手段に限定されるもの
ではないことを理解されたい。

【００４１】

【好ましい実施例の詳細な説明】

図６から図３７に関連して以下に説明するように、本発明は、第１のコンピュ
ータシステム上で実行する第１のネットワークアプリケーションと、該第１のコ
ンピュータシステムに直接相互接続されかつ密結合された第２のコンピュータシ
ステム上で実行する第２のネットワークアプリケーションとが、双方のシステム
が、ＴＣＰ／ＩＰおよびイーサネット等の従来のネットワーク通信経路を介して
ではなく、それら本来の機構を使用してネットワークアプリケーションに影響を
与えることなく互いに通信することができるように、それらアプリケーション間
の相互接続を介して高速かつ待ち時間の短い通信を行なうことを可能にする、方
法および装置に向けられる。本発明の好ましい実施例に従えば、本発明は、第１
のコンピュータシステムの入出力（Ｉ／Ｏ）システムを第２のコンピュータシス
テムのＩ／Ｏサブシステムと結合しかつそれにわたってデータをネットワークイ
ンターフェイスカードとは独立してシステム間で伝送することができる、相互接
続と、汎用トランスポートインターフェイスを提供する、第１および第２のコン
ピュータシステム上で実行する相互接続メッセージ通信システムと、第１および
第２のネットワークアプリケーションに対して既知のトランスポート層プロトコ
ルをシミュレートする、第１および第２のコンピュータシステム上で実行する仮
想トランスポート層とを含む。

【００４２】 以下により詳細に説明する一実施例において、本発明の方法および装置は、ユ
ニシスのクリアパスＨＭＰ ＮＸエンタープライズ・サーバの一特徴として提供
される、協調型ネットワーキングプラットフォーム（ＣＮＰ）（これはときに、
「ＮＸ／ネットワークサービス（NX/Network Services）」または「ＮＮＳ」と
も呼ばれる。）の一部として実装され得る。ここで、上述のように、ユニシスＡ
シリーズエンタープライズ・サーバは、マイクロソフトウィンドウズＮＴを実行
するインテルベースのサーバと密結合されている。この実施例では、Ａシリーズ
エンタープライズ・サーバが第１のコンピュータシステムを構成し、ＮＴサーバ
が第２のコンピュータシステムを構成する。このような環境で実装された場合、
本発明は、Ａシリーズサーバ上のネットワークアプリケーションが、ＮＴサーバ
上の同位のネットワークアプリケーションと、本来の機構を使用して、高速かつ
待ち時間の短い通信を行なうことができるようにする。

【００４３】 本発明の方法および装置、または、それらのある局面もしくは部分は、フロッ
ピー（登録商標）ディスケット、ＣＤ−ＲＯＭ、ハードドライブまたは他の機械 可読記憶媒体のような具体的な媒体内に実現される、プログラムコード（すなわ ち、命令）の形をとり得る。この場合、そのプログラムコードがコンピュータ等 の機械にロードされかつそれによって実行されるとき、その機械が、本発明を実 施する装置となる。また、本発明の方法および装置は、何らかの伝送媒体、たと えば電気配線もしくはケーブルを介して、光ファイバを通じて、または他の伝送 形状を介して伝送される、プログラムコードの形でも実現され得る。この場合、 そのプログラムコードがコンピュータ等の機械にロードされかつそれによって実 行されるとき、その機械が本発明を実施する装置となる。このプログラムコード が汎用プロセッサ上で実現される場合には、プログラムコードはプロセッサと共 同して、特定的な論理回路群と同様に動作する、独特の装置を提供する。

【００４４】 本発明の装置は、Ａシリーズサーバ１００のＩ／ＯサブシステムとＮＴサーバ
１０２のＩ／Ｏサブシステムとを結合してそれら２つのサーバ間のデータ伝送を
可能にする相互接続と、Ａシリーズサーバ１００とＮＴサーバ１０２との間に通
信経路を提供する「仮想」トランスポート層（「ＶＴＬ」）およびメッセージ通
信サブシステム（「ＭＳＳ」）とを含む。相互接続および、２つのサーバ間にデ
ータリンク層ネットワーク通信を提供する仮想ＬＡＮ（「ＶＬＡＮ」）通信経路
のさらなる詳細は、その内容がすでにここに引用により援用されている、１９９
８年６月１日に出願された上述の関連米国特許出願連続番号第０９／０８８，５
５２号に記載されている。本発明で実現される、Ａシリーズサーバ１００とＮＴ
サーバ１０２とのトランスポート層ネットワーク通信を可能にするＶＴＬ／ＭＳ
Ｓ通信システムについて、以下により詳細に説明する。当業者には、以下の詳細
な説明が例示のためのみのものであって、本発明の範囲を限定することを意図し
ないことが理解されるであろう。本発明の範囲は、前掲の請求の範囲から判断す
ることができる。

【００４５】 図中、同一の参照符号は同一の構成要素を表わす。図６から図８は、図３から
図５を参照して上に説明した相互接続のそれぞれのための、本発明の実施例を示
すブロック図である。それらの実施例においては、本発明の方法および装置は、
ユニシスクリアパスＨＭＰ ＮＸコンピュータシステム（「クリアパスシステム
」）に配置された協調型ネットワーキングプラットフォーム（ＣＮＰ）の一部と
して実装されている。各実施例において、第１のネットワークプロトコルプロバ
イダ４４、この場合ＴＣＰ／ＩＰ ＨＲＮＰが、Ａシリーズシステム１００上に
設けられている。ＴＣＰ／ＩＰ ＨＲＮＰ４４は、それに関連する複数のネット
ワークアドレス（すなわち、ＩＰアドレス）を有し、その各々がＡシリーズシス
テム１００の外部への各接続（たとえば、チャネルアダプタ）に対応する。下に
詳細に説明するように、Ａシリーズシステム１００はさらに、仮想トランスポー
ト層（「ＶＴＬ」）９０およびメッセージ通信サブシステム（「ＭＳＳ」）９２
を含み、これらによってＡシリーズシステム１００は、従来のＩＳＯネットワー
クプロトコルスタックをバイパスして、相互接続を介してＮＴサーバ１０２と通
信することができる。本発明の実施例において、ＶＴＬは（ＶＬＡＮと同様に）
、Ａシリーズシステム１００がそのＶＴＬが外部ではなく内部にあることがわか
るように、一意のＩＰアドレスを有する。

【００４６】 第２のネットワークプロトコルプロバイダ５８、この場合、（マイクロソフト
・コーポレーションから入手可能な）ＴＣＰＩＰ．ＳＹＳが、ＮＴサーバ１０２
上に設けられている。ＴＣＰＩＰ．ＳＹＳ５８は、各ネットワークインターフェ
イスカード（「ＮＩＣ」）に関連する自身のネットワークアドレス（すなわち、
ＩＰアドレス）を有し、これが、この実施例における第２のネットワークアドレ
スを規定する。やはり下に詳細に説明するように、ＮＴサーバ１０２もまた、仮
想トランスポート層（「ＶＴＬ」）９４およびメッセージ通信サブシステム（「
ＭＳＳ」）９６を含み、これらによってＮＴサーバ１０２は従来のＩＳＯネット
ワークプロトコルスタックをバイパスして、相互接続を介してＡシリーズサーバ
１００と通信することができる。ここで、ＶＴＬは、ＮＴサーバ１０２がそのＶ
ＴＬが外部ではなく内部にあるとわかるように、一意のＩＰアドレスを有する。
ＮＴサーバ１０２のＩ／Ｏバスのスロット内には、ウィンドウズＮＴと互換性が
あればどのようなＬＡＮタイプのＮＩＣ５０を用いることもできるが、好ましく
は、そのＮＩＣは、ファストイーサネット（Fast-Ethernet）ネットワーキング
プロトコル（たとえば、１００Ｂａｓｅ−Ｔ）をサポートする。この種のＮＩＣ
は、多くのベンダーおよび相手先商標による製造会社（ＯＥＭ）から入手可能で
ある。Ethernet/802.3、ＦＤＤＩ、またはギガビットイーサネット（Gigabit Et
hernet）等の、他の物理的媒体の種類をサポートするＮＩＣもまた、代替的に用
いることができる。通常、ＮＩＣのベンダーは、ＮＩＣとともにデバイスドライ
バを供給するが、そのデバイスドライバは、システム上の他のエンティティがそ
のＮＩＣのネットワーキング機能にアクセスすることができるように、オペレー
ティングシステムのカーネル空間にインストールされる。図６から図８に例示し
たシステムのＮＩＣ５０は、図示されるように、ウィンドウズＮＴのカーネル空
間にインストールされたデバイスドライバ５４（「<nicdrv>.sys」）を有する。

【００４７】 ＡシリーズサーバおよびＮＴサーバ上には、他のネットワークプロトコルプロ
バイダを設けることも可能である。たとえば、Ａシリーズサーバ上には、ＢＮＡ
ｖ２ ＨＲＮＰ４２を設けることができ、また、ＴＣＰ／ＩＰに加えて低信頼デ
ータグラムプロトコル（「ＵＤＰ」）を設けてもよい。しかし、ＢＮＡｖ２プロ
トコルはユニシス独自のプロトコルであって、ネットワークのエンドポイントの
ために別のアドレス指定方式を用いるので、このＢＮＡｖ２ ＨＲＮＰ４２がそ
れに関連するＩＰアドレスを有することはない。

【００４８】 図９Ａから図９Ｆは、図６から図８に示した実施例において、ＨＩＦの相互接
続デバイスドライバおよびＱＳＰモジュール７６を介してＡシリーズサーバ１０
０とＮＴサーバ１０２との間でどのようにデータが転送されるかをより詳細に示
す。図９Ａから図９Ｅに示した詳細は、図６、図７および図８に示したホストイ
ンターフェイスファンクション（「ＨＩＦ」）のＱＳＰベースのどの実施例に対
しても適用可能である。したがって、以下の説明に用いられる、相互接続デバイ
スドライバ（ＩＣＤ）という語は、これらの図に関連して説明される相互接続デ
バイスドライバの３つの実装例のいずれにもあてはまる。

【００４９】 ＱＳＰ７６は、ＩＣＤによってサポートされる通信経路を抽象化したものであ
る１または複数の転送ユニットを介した、複数のクライアントダイアログ（たと
えば、ＮＳＭ−ＳＴＵＢモジュール８４およびＬＬＭ−ＳＴＵＢモジュール８６
とのダイアログ、ならびに、ＬＡＮＳＧ７８によって規定される異なるステーシ
ョンとのダイアログ）を多重化する。ユニットは、論理ダイアログまたは物理的
デバイスであり得る。このユニットの資源をより十分に利用するために、ＱＳＰ
７６は、同じユニットを介して転送されるのを待っているメッセージを、単一の
動作で転送することのできる１ブロックにまとめてもよい。ＱＳＰ７６は、メッ
セージヘッダにメッセージ・カウント（Message-Count）フィールドを設けるこ
とによって、このようなブロック化をサポートする。ブロック内の最初のメッセ
ージヘッダのメッセージ・カウントフィールドには、そのブロックに含まれるメ
ッセージの数を入れ、同じブロック内の後続のメッセージヘッダのフィールドに
は、ゼロ値を入れる。

【００５０】 ＩＣＤは各ブロックを取って、そのブロックをＡシリーズサーバ１００に転送
するように物理的接続（すなわち、実装例に応じて、ＥＰＣＣＡボード６６、Ｐ
ＣＩブリッジカード６７または、エミュレートされたメモリ同士の接続６３）を
プログラムする。逆方向の場合、ＩＣＤは、メッセージが物理的接続を介してＮ
Ｔサーバ１０２のメモリ内に転送されたときに、（図６および図７のハードウェ
ア接続の場合には）割込みによって、または（図８のエミュレートされた接続６
３の場合には）関数呼出しによって、起こされる。ＩＣＤは、受信したメッセー
ジをＱＳＰ７６に配信する。ＱＳＰ７６はそのメッセージを、メッセージに関連
付けれらた宛先キューアドレス（リモートキューリファレンス（Remote Queue R
eference）または「ＲＱＲ」）に基づいて、適切なクライアントダイアログ（た
とえば、ＮＳＭ−ＳＴＵＢ８４、ＬＬＭ−ＳＴＵＢ８６、またはＬＡＮＳＧ７８
によって規定される任意のステーション）に分配する。本発明に従えば、ＮＴサ
ーバ１０２は、仮想トランスポート層（「ＶＴＬ」）９４およびメッセージ通信
サブシステム（「ＭＳＳ」）９６をさらに含み、これらが、ＮＴサーバ１０２が
従来のＩＳＯネットワークプロトコルスタックをバイパスして、相互接続を介し
てＡシリーズサーバ１００と通信することを可能にする。ＶＴＬインターフェイ
スおよびＭＳＳインターフェイスの動作は、下に詳細に説明する。

【００５１】 図９Ａから図９Ｄは、ＮＴサーバ１０２上のクライアント（たとえば、ＮＳＭ
−ＳＴＵＢ８４、ＬＬＭ−ＳＴＵＢ８６またはＬＡＮＳＧ７８によって規定され
るステーション）からＡシリーズサーバ１００へと物理的接続を介してメッセー
ジを転送するのに、ＱＳＰ７６およびＩＣＤによって行なわれる、ステップに関
するさらなる情報を提供する。この転送プロセスは、クライアント、たとえば、
ＴＣＰＩＰ．ＳＹＳ５８から受信したデータをＡシリーズサーバ１００に渡さね
ばならないＬＡＮＳＧモジュール７８が、ＱＳＰ７６を呼出して、メッセージ（
たとえば、ネットワークから受信したデータ）をＡシリーズサーバ１００へと転
送するように要求したときに、開始される。この場合、そのメッセージを構成す
る、連続していないメッセージセグメントをポイントするパラメータが、そのリ
クエストとともに渡される。ステップ１１２において、ＱＳＰ７６は、どのユニ
ット上でそのメッセージを転送すべきかを判断する。次に、ステップ１１４にお
いてＱＳＰ７６は、メッセージ内の連続していない各セグメントを調べることに
よって、そのメッセージの合計サイズを計算する。ステップ１１６において、そ
のメッセージのはじめにヘッダが追加され、そのヘッダおよびメッセージ内の各
セグメントをポイントする記述子のリストが構築される。次に、ステップ１１８
において、ＱＳＰ７６は、そのユニットに対してブロック化（上述のとおり）が
サポートされるかどうかを判断する。もしサポートされる場合には、ステップ１
２０において、ＱＳＰ７６は、現時点において転送を待っているブロックがある
かどうかを判断する。もしあれば、ステップ１２１においてＱＳＰ７６は、その
メッセージが処理待ちの最終ブロックに当てはまるかどうかを判断する。もし当
てはまれば、ステップ１２２においてＱＳＰ７６は、記述子リストをその最終の
処理待ちブロックに追加する。その後、制御はステップ１２７（図９Ｂ）に渡さ
れる。

【００５２】 ステップ１１８においてブロック化がそのユニットついてサポートされないと
判断された場合、ステップ１２０において現時点において転送を待っているブロ
ックがないと判断された場合、および、ステップ１２１においてメッセージが最
終の処理待ちブロックに当てはまらないと判断された場合の、３つの場合すべて
において、制御はステップ１２４に渡される。ステップ１２４において、ＱＳＰ
７６は、ステップ１１６において構築された記述子リストのみを含むブロックを
構築する。次に、ステップ１２６において、この新たに作成されたブロックが、
処理待ちブロックのリストに追加される。制御はその後、ステップ１２７（図９
Ｂ）に渡される。

【００５３】 図９Ｂにおいて、ＱＳＰ７６は、ステップ１２７において、処理待ちのブロッ
クがあるかどうかを判断する。もしなければ、ＱＳＰ７６は単にクライアントに
リターンする。しかし、もし転送されるべき処理待ちブロックがあれば、制御は
ステップ１２８に渡される。

【００５４】 ステップ１２８において、ＱＳＰ７６は、処理待ちブロックのリストにおける
最初のブロックを、ＩＣＤのHifSendBlockToHost()手続きを呼出すことによって
、ＩＤＣに送ろうと試みる。この手続きは、データのブロックをＭＣＰ１２へと
配信するように、ＱＳＰ７６によってコールされる。図９Ｂに「Ａ」を付した矢
印で示すように、ＩＣＤはこの時点で、リクエストの処理を開始する。ＩＣＤに
よって行なわれるステップは図９Ｃに示す。図９Ｂを参照して、ＱＳＰの処理は
ステップ１３０に続き、ここでＱＳＰ７６は、ＩＣＤが転送のためにそのブロッ
クを受入れたかどうかを判断する。受入れた場合には、そのブロックはステップ
１３２において処理待ちのリストから取除かれ、制御はステップ１２７に戻る。
ステップ１２７においてＱＳＰ７６は再び、転送されるべき処理待ちブロックが
残っているかどうかを判断し、そのようなブロックについて処理を続ける。しか
し、もしステップ１３０において、ＩＣＤが転送のために任意のブロックを受け
いれなかったと判断した場合には、ＱＳＰ７６はクライアントにリターンし、送
信されるべきメッセージを含むそのブロックは処理待ちリストに残される。

【００５５】 図９Ｃに示すように、ＩＣＤは、ＱＳＰからのHifSendBlockToHost()リクエス
トの処理をステップ１３４で開始する。ステップ１３４において、ＩＣＤは、物
理的接続がフロー制御モードにあるかどうかを判断する。フロー制御モードは、
Ａシリーズサーバ１００のＭＣＰオペレーティングシステム１２が、たとえば、
利用可能なバッファがないために、特定のユニット上でデータを受信する準備が
できていないことを示すモードである。物理的接続がフロー制御モードにある場
合には、ＩＣＤはＱＳＰ７６に対して「ＦＡＬＳＥ」の値を返し、この時点で転
送処理を停止する。物理的接続がフロー制御モードにない場合には、制御はステ
ップ１３６に渡され、そこで、ＩＣＤは、その物理的接続がギャザー（Gather）
ファンクションをサポートするかどうかを判断する。ギャザーは、データを１つ
の動作で、連続しないメモリ領域から転送することのできる機能である。その物
理的接続がギャザー機能をサポートしない場合には、制御はステップ１３８に渡
され、そこでＩＣＤは、（ＱＳＰ７６によって渡された）記述子リストによって
ポイントされるそのデータを、連続したバッファにコピーする。次に、ステップ
１４０においてＩＣＤは、その単一の、連続したバッファをポイントする、擬似
記述子リストを構築する。制御はその後、ステップ１４２に渡される。

【００５６】 （ギャザーがサポートされて）ステップ１３６から直接ステップ１４２に入っ
た場合にも、（ギャザーがサポートされずに）ステップ１４０からステップ１４
２に入った場合にも、ＩＣＤはステップ１４２において、物理的接続（すなわち
、特定的な実施例に応じて、ＥＰＣＣＡボード６６、ＰＣＩブリッジカード６７
またはエミュレートされたメモリ同士の接続６３）をプログラムして、（ギャザ
ーの場合には）ＱＳＰ７６から受信した記述子リストによって、（ギャザーでな
い場合には）ステップ１４０で作成された擬似記述子リストによって、そのいず
れかによってポイントされるデータを転送する。ＩＣＤはその後、ＱＳＰ７６に
対して「ＴＲＵＥ」の値を返す。

【００５７】 図９Ｄは、転送が完了したときにＩＣＤおよびＱＳＰ７６によって行なわれる
ステップを示す。図示するように、転送が完了すると、ＩＣＤが起こされる。ス
テップ１４４において、ＩＣＤは、その転送がうまく完了したかどうかの表示を
受取る。もしうまく完了しなかった場合には、制御はステップ１４６に渡され、
そこでＩＣＤは、たとえば、問題のブロックを再転送したり、物理的接続をリセ
ットしたりすることによって、その誤りを回復しようと試みる。転送がうまく完
了した場合には、制御はステップ１４８に渡される。ステップ１４８において、
ＩＣＤは、物理的接続のフロー制御状態を調節する。これは、上述の物理的接続
の実施例においては相互接続がポーリングされるために行なわれる。転送が完了
すると、相互接続は、それが再びポーリングされるまで別の転送を開始すること
ができない場合がある。そのため、ポーリングを反映するよう、フロー制御状態
を調節するのである。次に、ステップ１５０において、ＩＣＤは、QspAckBlockT
oHost()の手続きを呼出し、ＱＳＰに対して、ＭＣＰ１２への転送が完了したこ
と、および、どの記述子リストが転送されたかを知らせる。ステップ１５２にお
いて、ＩＣＤは、クリーンアップ手続きを行ない、その後リターンする。

【００５８】 図９Ｄにポイント「Ｂ」で示すように、ＱＳＰ７６がＩＣＤから、ＭＣＰ１２
への転送がうまく完了したことを知らせるQspAckBlockToHost()の表示を受取る
と、ＱＳＰ７６はステップ１５４に入る。ステップ１５４において、転送された
ブロック内のすべてのメッセージがリリースされて、メッセージを送信してきた
クライアントに、それらがうまく転送されたことが知らされる。ステップ１５６
において、メッセージヘッダおよび記述子リストを含むブロック構造が再利用さ
れて、後続の転送のために利用可能とされる。その後、制御は図９Ｂのステップ
１２７に戻って、後続のブロックの処理が行なわれる。

【００５９】 図９Ｅおよび図９Ｆは、Ａシリーズサーバ１００からＮＴサーバ１０２にメッ
セージを伝送するのにＩＣＤおよびＱＳＰ７６によって行なわれるステップを示
す。図示するように、ＩＣＤは、物理的接続を介してＡシリーズサーバ１００か
らメッセージを受取るのに先立って、その接続のために利用可能な空き受信バッ
ファを作る。メッセージがＡシリーズサーバ１００からＮＴサーバ１０２へと物
理的接続を介して（たとえば、図６の実施例においてはフィードスルーカード６
２、ケーブル６４およびＥＰＣＣＡカード６６を介して）転送されると、ＩＣＤ
は、メッセージがＩＣＤが指定した空き受信バッファのうちの１つに受信された
ことを示す表示によって起こされる。ステップ１５８において、ＩＣＤは、その
メッセージをＡシリーズサーバ１００からＱＳＰ７６へと、QspLRPut()関数を使
用して渡し、その後リターンする。

【００６０】 ステップ１６０において、ＱＳＰ７６は、そのメッセージがコントロールメッ
セージであるかどうかを判断する。もしそうであれば、ステップ１６４において
ＱＳＰ７６は、局所的にそのコントロールメッセージを処理し、その後、そのメ
ッセージをステップ１６６においてリリースしてからリターンする。そのメッセ
ージがコントロールメッセージでない場合には、制御はステップ１６２に渡され
る。ステップ１６２においてＱＳＰ７６は、メッセージヘッダ内のＲＱＲから、
どのステーションがそのメッセージを受取るべきかを判断する。次にステップ１
６８において、そのメッセージがその適切なステーションに渡される。

【００６１】 図９Ｆに示すように、ＱＳＰ７６またはそのクライアントのうちの１つがメッ
セージバッファを解放すると、ＩＣＤのフリーメッセージコールバック関数が呼
出される。ステップ１７０においてＩＣＤは、その解放されたバッファを利用可
能なバッファのリストに加える。物理的接続はその後そのバッファを使用して、
上述のような方法で後続のメッセージを受取ることができる。

【００６２】 上述したように、ＶＬＡＮ７９は、Ａシリーズサーバ１００とＮＴサーバ１０
２との間に高速の通信インターフェイスを提供する。図６から図８の各実施例に
示すように、仮想ＬＡＮミニポートドライバ（ＶＬＡＮ）７９が、Ａシリーズサ
ーバ１００とＮＴサーバ１０２との間の通信経路内に設けられる。一般に、ＶＬ
ＡＮ７９は、ＡシリーズのＴＣＰ／ＩＰネットワークプロバイダ（ＴＣＰ／ＩＰ
ＨＲＮＰ４４）とウィンドウズＮＴベースのＴＣＰ／ＩＰスタック（ＴＣＰＩ
Ｐ．ＳＹＳ５８）との両方に対して「仮想ＬＡＮ」として現われる、ＮＤＩＳデ
バイスドライバである。ＶＬＡＮ７９は、Ａシリーズサーバ１００とＮＴサーバ
１０２とがそれら本来の機構を使用して互いに通信することができるように、両
サーバの間に高速かつ待ち時間の短い経路を実装する。

【００６３】 ＶＬＡＮ７９は、ＮＴサーバ１０２上のＴＣＰＩＰ．ＳＹＳ５８に対してネッ
トワークドライバインターフェイス仕様（Network Driver Interface Specifica
tion、ＮＤＩＳ）ファイバ分散型データインターフェイス（Fiber Distributed
Data Interface、ＦＤＤＩ）ネットワークインターフェイスカード（ＮＩＣ）ミ
ニポートドライバをシミュレートし、かつ、Ａシリーズサーバ１００にデータを
配信しかつそれからデータを受取るために、ＬＡＮＳＧ７８とライン０との間で
データを交換する、ウィンドウズＮＴのＮＤＩＳドライバである。換言すれば、
ＶＬＡＮ７９は、ＴＣＰＩＰ．ＳＹＳ５８およびＬＡＮＳＧ７８に対して、ＦＤ
ＤＩ ＮＩＣとして現われる。しかし、実際には、ＶＬＡＮ７９は単に、ウィン
ドウズＮＴ ＮＤＩＳラッパー（Wrapper）に対してＦＤＤＩインターフェイス
カードをシミュレートする、ＮＤＩＳデバイスドライバにすぎない。ＶＬＡＮ７
９は、他のどのＮＤＩＳドライバとも同じ、外部インターフェイスを提供する。
ＶＬＡＮ７９は、より上位のプロトコルに対してトランスペアレントであり続け
るために、ＮＤＩＳミニポートドライバのためにマイクロソフトによって設定さ
れた標準に従う。ＶＬＡＮ７９は、厳格に強制されるインターフェイスの規定に
よっては縛られない、ＬＡＮＳＧモジュール７８との手続き的インターフェイス
を有する。一般に、ＬＡＮＳＧとのインターフェイスは、ＮＤＩＳラッパーによ
って強制される規則を、修正したものの組に基づく。

【００６４】 上述の、共通に所有される出願に示されるように、ＶＬＡＮ７９は、実際には
ＮＴサーバ１０２のメモリ内ではポイントツーポイントであるが、ＦＤＤＩのよ
うなＬＡＮをエミュレートする。ＦＤＤＩのような標準ＬＡＮがエミュレートさ
れるので、たとえば両サーバ上のＴＣＰ／ＩＰ等の通信プロトコルが、修正なし
に動作することが可能である。同様に、ＭＣＰ１２上のＴＣＰポートファイルお
よび、ＮＴサーバ１０２上のウィンソック（WinSock）ＴＣＰソケットを使用す
るすべてのプログラムが、変更なしに相互通信することが可能である。また、Ｌ
ＡＮ接続が実際にはＮＴサーバ１０２のメモリであるために、ＮＴサーバ１０２
からＭＣＰ１２にまたはその逆に移動するメッセージの待ち時間は短くて済み、
ＶＬＡＮ７９は、他のチャネルアダプタよりも速いトランザクション速度を維持
することができる。さらに、ＦＤＤＩ ＬＡＮをエミュレートすることによって
、イーサネット上でサポートすることのできるサイズよりも大きいセグメントサ
イズを使用することが可能となる（イーサネットの１５００バイトに対して４５
００バイト）。さらに、各セグメントのオーバヘッドがより大きなセグメントに
わたって分散されるので、全体としてのデータのスループットが対応して向上す
る。

【００６５】 本発明は、従来のＴＣＰトランスポート層およびより下位の層を、密結合され
たＭＣＰシステムとＮＴシステムとの間でデータを転送する仮想トランスポート
層（「ＶＴＬ」）およびメッセージ通信サブシステム（「ＭＳＳ」）と置換する
ことによって、共存する、密結合されたＭＣＰおよびＮＴの処理環境におけるア
プリケーション間に、性能が最適化された通信を提供する。本発明によれば、Ｖ
ＴＬ／ＭＳＳは、密結合されたシステムの他方側に対して信頼性の高いデータ配
信を行なうかまたは、接続が使用不可能であることを表示する、同種のコネクシ
ョン指向のインターフェイスを提供する。ＭＳＳは、システムの、相互接続とは
独立したメッセージ通信トランスポートであって、そのユーザに対して、種々の
異種環境間でコントロール情報およびデータ情報の信頼性の高い転送を行なうた
めの、多種多様な配信および通知機構を提供する。一方、ＶＴＬは、そのＭＳＳ
接続を使用して、セッション層への一貫性のある、相互接続とは独立したインタ
ーフェイスを提供する。好ましい実施例においては、基礎となる相互接続は、上
述のようなＱＳＰ相互接続か、エミュレートされた相互接続か、または、１９９
７年７月２日にすべて出願され本願の譲受人であるユニシス・コーポレーション
にすべて譲渡されている、米国特許出願連続番号第０８／８８７，２２８号、０
８／８８７，２９５号または０８／８８７，２９６号に記載されているような、
ＣＩＡ相互接続であり得る。なお、これらの出願の内容は、その全文が、ここに
引用により援用される。各相互接続について、ＭＳＳは、伝送されたデータが伝
送した側のシステムのメモリから取去られる前に、すべての受信通知が受取られ
るようにする。大きなサイズのメッセージもＬＡＮのセグメントサイズに分割す
ることなくそのまま送信することができるので、通信効率がさらに改善される。
ＭＳＳはホストインターフェイスファンクション（「ＨＩＦ」）と直接インター
フェイスするので、相互接続が変更された場合にも、ＨＩＦへのＭＳＳインター
フェイスのみを変更すればよく、他のすべてのソフトウェアの修正は不要である
。

【００６６】 図１０は、１つのＭＣＰ環境および１つのＮＴ環境を有するクリアパスＨＭＰ
ＮＸエンタープライズ・サーバ上の、本発明によるＶＴＬ／ＭＳＳ相互接続通
信インターフェイスを示す。図示されるように、この通信インターフェイスは、
メッセージ通信サブシステム（ＭＣＰ ＭＳＳ）９２およびそのＭＳＳ「ユーザ
」（ＭＣＰ ＶＴＬ９０）を含む。ＭＣＰ ＭＳＳ９２は複数のモジュール１７
２を含み、それらは、それぞれのホストインターフェイスファンクション（「Ｈ
ＩＦ」）へのインターフェイス、または、本発明の種々の実施例に従ってＡシリ
ーズサーバ１００とＮＴサーバ１０２との間に提供される、それぞれのユーザ環
境内の相互接続へのインターフェイスを含む。ＨＩＦは、たとえば、図６に示す
ＰＣＣＡ ＨＩＦ、図７に示すＰＣＩブリッジＨＩＦ、図８の相互接続エミュレ
ーション、上述の関連特許出願に記載された通信接続間アーキテクチャ（「ＣＩ
Ａ」）、または、今後開発されるであろう別の種類の相互接続を含む。ＭＳＳ−
ＮＴ９６は同様に、それぞれのＨＩＦとインターフェイスをとる、対応する複数
のモジュール１７４を含む。好ましくは、ＶＴＬ／ＭＳＳ経路は、相互接続のア
ーキテクチャが変更された場合に、ＨＩＦに対するＭＳＳインターフェイスモジ
ュール１７２、１７４のみが影響を受けるように設計される。最後に、ＭＳＳ−
ＮＴ９６は、そのＭＳＳ「ユーザ」（ＮＴ ＶＴＬ９４）とインターフェイスを
とり、ＭＳＳユーザが今度は、トランスポートドライバインターフェイスのクラ
イアント（「ＴＤＣ−ＣＬＩＥＮＴ」）９８とインターフェイスをとる。以下の
説明から明らかとなるように、図１０に示した通信インターフェイスは、（ここ
では「MSS＿Endpoint＿Dialog」と呼ばれる）データダイアログを作成し、これ
が、従来のＴＣＰ／ＩＰプロトコルで可能であったよりも大きなブロック（たと
えば、ＨＩＦの最大転送サイズによって規定した場合、６４Ｋバイト）での、信
頼性の高いデータ配信を可能にする。

【００６７】 本発明に従って従来のＴＣＰ／ＩＰプロトコルの代わりに上述のＨＩＦを介し
て通信するのに使用される、本発明のＶＴＬ／ＭＳＳプロトコルについて、以下
のセクションで説明する。メッセージ通信サブシステム（「ＭＳＳ」）の説明か
ら始めて、最後に「仮想」トランスポート層（ＶＴＬ）について説明する。

【００６８】 Ｉ． メッセージ通信サブシステム（「ＭＳＳ」） メッセージ通信サブシステム（「ＭＳＳ」）は、ＶＴＬまたは他のトランスポ
ート層プロトコル（「ＭＳＳユーザ」）によって従来のＴＣＰ／ＩＰプロトコル
の代わりに使用され、異なるメッセージ通信モデル（プルモデルおよびプッシュ
モデル）ならびにさまざまなサービスをそのユーザに提供する、システムの、相
互接続とは独立したメッセージ通信システムである。図１０に示すように、ＭＳ
Ｓは、どのようなネットワークで使用するのにも好適な、汎用メッセージ通信ア
ーキテクチャである。概して、ＭＳＳは、現時点におけるネットワークプロバイ
ダ（たとえば、ＴＣＰ／ＩＰおよびＢＮＡネットワークプロバイダ）の、ＭＣＰ
１２のネットワークプロセッサへのＩ／Ｏインターフェイスと同様であるが、こ
のＭＳＳは、複数のシステムプラットフォームおよびシステム相互接続パラダイ
ムにわたって同じインターフェイスを使用することができるようにする、実際の
Ｉ／Ｏインターフェイスからのある抽象化レベルを提供する。以下の説明から当
業者には理解されるように、ＭＳＳは、ＴＣＰ／ＩＰプロトコルとは異なって、
そのユーザに、信頼性の高いデータ配信を保証する。このユーザの一例が、次の
セクションで詳細に説明する、仮想トランスポート層（「ＶＴＬ」）である。

【００６９】 概して、ＭＳＳは、好ましい実施例においては、システムプラットフォームア
ーキテクチャによって提供されるシステムの相互接続にわたる、ＮＴ ＶＴＬコ
ンポーネント９４とＭＣＰ ＶＴＬコンポーネント９０との間の、ダイアログの
開始、データ転送およびダイアログの終了を担当する。ＭＳＳは、クライアント
・サーバ間で複数のデータダイアログを提供し、プラットフォームまたはシステ
ムの相互接続とは独立した特徴および特異性を、ＭＳＳ「ユーザ」から隠す。Ｍ
ＳＳは、これらのサービスを行なうためにそのユーザに対して手続き的インター
フェイス（コールバックを含む）を提示する。

【００７０】 すべてのシステム相互接続がＭＳＳ「ユーザ」に対して同じインターフェイス
を提示するので、ＭＳＳが原因でまたは相互接続における変化が原因で、ＭＣＰ
ＶＴＬコンポーネント９０またはＮＴ ＶＴＬコンポーネント９４を変更する
必要はない。しかし、ＭＳＳインターフェイスが「プルモデル」および「プッシ
ュモデル」の両方を提供するので、異なる環境におけるコンポーネントは、環境
に固有の理由のために、配信のために異なる意味規則を使用したいと願う場合も
あり得る。

【００７１】 ＴＣＰの代わりにＶＴＬ（「ＭＳＳユーザ」）を実装する、本発明の現時点に
おいて好ましい実施例においては、ＭＳＳはスタートアップ時に、MSS＿Initial
ize()のコールによって、ＮＴ ＶＴＬコンポーネント９４およびＭＣＰ ＶＴ
Ｌコンポーネント９０によって初期化される。これにより、ＭＳＳによって必要
とされる構造がすべて作成される。ＭＳＳは、初期化時に、すでに初期化されて
いる他のＭＳＳユーザのための相互接続をサーチする。ＭＳＳは、ローカルＭＳ
Ｓユーザに対して、相補的なすべてのＭＳＳユーザについて、USER-CHANGE-NOTI
FICATIONによって知らせる（たとえば、ＭＳＳは、ローカルＶＴＬコンポーネン
トに対して、相互接続内に発見された他のすべてのＶＴＬコンポーネントについ
て知らせる）。発見された各リモートＭＳＳユーザに対して１つのUSER-CHANGE-
NOTIFICATIONが用いられ、ローカルＭＳＳユーザはこれを使用して、各リモート
ＭＳＳユーザとの通信を初期化する（たとえば、ＩＰアドレスまたは他の構成情
報を交換する）ことができる。ローカルＭＳＳは、ＮＴ ＶＴＬコンポーネント
９４またはＭＣＰ ＶＴＬコンポーネント９０からの、MSS＿Terminate()のコー
ルによって終了される。これにより、この環境からのすべてのＭＳＳダイアログ
が終了する。このローカル環境へのダイアログを有するすべての遠隔環境は、（
エンドポイント（またはデータ）ダイアログについては）DIALOG-CHANGE-INDICA
TIONによって、および、（コントロールダイアログについては）USER-CHANGE-IN
DICATIONによって、通知される。

【００７２】 ユーザによる初期化に続いて、ＭＳＳは、遠隔の相補的な環境において実行す
る、その相手方すべてとの通信を初期化する。これは、ＭＣＰ ＭＳＳ９２がア
クティブであるすべてのＮＴ ＭＳＳ９６との通信を初期化せねばならないこと
を意味する。ＭＳＳはまた、遠隔環境から入ってくるメッセージ、および（出て
いくデータ要求とともに伝送される）出ていくコントロール情報に対して、ある
量のメモリを割当てかつリザーブする。この領域は、環境（ＭＣＰ対ＮＴ）によ
って、また、各システムの相互接続パラダイム（たとえば図６、７、８またはＣ
ＩＡ）によって、異なるであろう。

【００７３】 次に、ＭＳＳの動作を、以下の４つの主要領域において説明する。（１）リモ
ートＭＳＳユーザ管理（Remote MSS User Management）機能。これは、ＭＳＳが
そのユーザに対して、（共存する種々の環境における）リモートＭＳＳユーザの
ステータス変化を知らせることができるようにする。（２）エンドポイントダイ
アログ管理（Endpoint Dialog Management）機能。これは、ＭＳＳユーザが、リ
モートＭＳＳユーザとのＭＳＳエンドポイントダイアログ（Endpoint Dialog）
を構築し、それについてのステータスを受信しかつそれを無効にすることができ
るようにする。（３）コントロールメッセージ転送機能（Control Message Tran
sfer Functions）。これは、ＭＳＳユーザが、コントロールメッセージの内容が
ＭＳＳに対して完全にトランスペアレントとなるように、互いにコントロールメ
ッセージを転送することができるようにする。最後に（４）データ転送（Data T
ransfer）機能。これは、ＭＳＳユーザが、データ転送を最適化するために、デ
ータをコントロールメッセージ転送とは別に転送することができるようにする。

【００７４】 Ａ．リモートＭＳＳユーザ管理 ＭＳＳは、そのローカルユーザに対して、リモートユーザのステータス変化を
知らせる役割を果たす。リモートユーザのステータスは、「利用可能」または「
利用不可能」のいずれかとしてのみ区別される。ＭＳＳは、そのローカルユーザ
のうちの１つにとって関心のあるリモートユーザにおいてステータス変化を検出
するたびに、そのユーザ全員にUser-Change-Notificationを提供する。この通知
は、そのリモートユーザの現時点におけるステータスを示す。「利用可能」が表
示されるときは、ＭＳＳは、そのリモートユーザが位置する環境と、ＭＳＳユー
ザ同士を接続するＭＳＳコントロールダイアログと、そのリモートユーザのタイ
プ（たとえば、ＮＴ ＶＴＬコンポーネント９４、ＭＣＰ ＶＴＬコンポーネン
ト９０）とを特定する。これに応答して、ＭＳＳユーザは、その表示されたＭＳ
Ｓダイアログに対して、自身の局所参照値を提供する。ＭＳＳは、この局所参照
値を、同じコントロールダイアログ上の他のどのオペレーションにおいても含め
る。

【００７５】 ＭＳＳは、リモートユーザのステータスの「利用不可能」への変化や、ダイア
ログ上に発生したエラーを検出した場合にも、User-Change-Notificationを提供
する。リモートユーザが利用不可能であることが知らされると、対応するＭＳＳ
ダイアログはもはや使用することができなくなる。ダイアログが「利用不可能」
となれば、そのダイアログ上で実行されていた機能は機能しなくなり、誤った結
果をコールした側に返す。このダイアログは、「利用可能」を示すUser-Change-
NotificationがＭＳＳユーザに対して提示されると、再び使用することができる
ようになる。

【００７６】 Ｂ．エンドポイントダイアログ管理 ＭＳＳがそのユーザのために自動的に構築するコントロールダイアログに加え
て、ＭＳＳユーザもまた、自己の判断で、付加的なMSS＿Endpoint＿Dialogを構
築することができる。ＭＳＳは、この目的のために、Create-Endpoint-Dialogお
よびOpen-Endpoint-Dialogの、２つのオペレーションを提供する。MSS＿Endpoin
t＿Dialogの構築を完了するために、Create-Endpoint-Dialogオペレーションが
ＭＳＳユーザのうち１つによって行なわれ、Open-Endpoint-Dialogオペレーショ
ンが同位のＭＳＳユーザによって行なわれる。Open-Endpoint-Dialogオペレーシ
ョンは、Create-Endpoint-Dialogによって得られた情報を必要とする。この情報
は、コントロールダイアログ（または他の適用可能な機構）を介して、同位のユ
ーザに通信される。

【００７７】 Create-Endpoint-Dialogを行なうために、ＭＳＳユーザは、ダイアログが構築
されるべき相手方であるリモートＭＳＳユーザを一意に識別するのに十分な情報
を提供する。この情報は、そのリモートユーザが位置する環境、そのリモートユ
ーザのタイプ、および、そのリモートユーザの特定のインスタンスの識別子を含
む。ＭＳＳユーザは、さらに、ＭＳＳに対してそのリモートユーザへのデータ配
信をどのように行なってほしいかを示す、そのダイアログのためのオプションを
、ＭＳＳがそのダイアログについてＭＳＳユーザに対して通知を返すときに使用
すべき局所参照値とともに、表示する。Create-Endpoint-Dialogの完了時、ＭＳ
Ｓは、このＭＳＳダイアログのための、システム独自の識別子を提供する。この
プロセスを完了するには、同位のＭＳＳユーザに対して、Create-Endpoint-Dial
ogによって得られたダイアログの識別子の値が与えられねばならず、また、その
後、同位のＭＳＳユーザがOpen-Endpoint-Dialogを呼出して、その値を入力とし
て、（そのローカルＭＳＳのための、自身の局所参照値とともに）提供せねばな
らない。しかし、ＭＳＳユーザは、Create-Endpoint-DialogまたはOpen-Endpoin
t-Dialogをうまく完了した後でも、ダイアログを利用してはならない。これは、
そのダイアログが完全に構築されていないためである。ＭＳＳユーザがこのダイ
アログ上でのデータ送信を開始するには、「利用可能」を示すDialog-Change-No
tificationを待たねばならない。

【００７８】 通常、MSS＿Endpoint＿Dialogは、PENDING＿OPEN、OPEN、NOT＿READY、REMOTE
＿CLOSEDおよびCLOSEDの、５つの状態を有する。PENDING＿OPENは、ローカル環
境がMSS＿Endpoint＿Dialogの作成をうまく完了したが、遠隔環境が対応するオ
ープンを開始していないかまたはそのオープンが完全に終了していないことを示
す。このダイアログ上でデータを送受信することはできない。OPENは、MSS＿End
point＿Dialogがアクティブであって使用準備ができていることを示す。このダ
イアログ上ではデータを送受信することが可能である。NOT＿READYは、このダイ
アログがフロー制御状態にあることを示す。このダイアログ上ではデータの送信
はできないが、受信することは可能である。REMOTE＿CLOSEDダイアログは、閉じ
るまたは無効化するプロセス中にある。遠隔環境はこのダイアログを閉じ終え、
ユーザはそのクローズについて通知されている。このダイアログについては、Ｍ
ＳＳ内ではデータは未だ利用可能であるが、このダイアログを使用して新しいデ
ータを送信することはできない。最後に、CLOSEDは、このダイアログが閉じて、
このダイアログを介してデータを送受信することができないことを示す。

【００７９】 MSS＿Endpoint＿Dialogは、Close＿Endpoint＿DialogまたはDestroy＿Endpoin
t＿Dialogオペレーションを行なうことによって終了される。Close＿Endpoint＿
Dialogオペレーションが行なわれる場合、同位のＭＳＳユーザ同士がこのオペレ
ーションを個別に行ない、それらは互いに、遠隔クローズ表示によって遠隔側の
クローズを通知される。ローカルＭＳＳユーザがクローズした後は、リモートユ
ーザはそのダイアログ上でデータを送信することはできないが、リモートユーザ
は、そのダイアログの遠隔側を自身が閉じるまでは、そのダイアログ上の待ち行
列に入れられた入力データを検索することができる。Destroy＿Endpoint＿Dialo
gオペレーションが行なわれる場合には、リモートユーザは直ちに、そのダイア
ログが「CLOSED」となったことを知らされ、待っているデータはすべて廃棄され
る。

【００８０】 Ｃ．コントロールメッセージ転送 コントロールメッセージ転送機能は、ＭＳＳユーザが互いにコントロールメッ
セージを転送することができるようにする。コントロールメッセージの内容は、
ＭＳＳに対して完全にトランスペアレントである。ＭＳＳユーザは、Send-Contr
ol-Messageオペレーションを開始することによって、コントロールメッセージ転
送を開始する。コールする側は、メッセージを送信するのに使用するＭＳＳダイ
アログと、そのメッセージの長さと、そのメッセージの始めをポイントするポイ
ンタとを特定する。対象となるＭＳＳダイアログはコントロールダイアログでな
くてもよい。なぜなら、コントロールメッセージはMSS＿Endpoint＿Dialogを介
して送信することができるためである。MSS＿Endpoint＿Dialogを介して送信す
る場合、コントロールメッセージは、同じダイアログ上で送信される他のデータ
メッセージとともに、順に配信される。同位のＭＳＳコンポーネントは、Receiv
e-Control-MessageによってＭＳＳユーザに対してコントロールメッセージを配
信し、到着したＭＳＳダイアログデータのためのＭＳＳユーザの参照値と、その
データの長さと、そのデータに対するポインタとを提供する。コントロールメッ
セージは、連続したメモリ領域で、（ＭＳＳ内におよびそれから）送信および配
信されねばならない。

【００８１】 Ｄ．データ転送 データ転送機能は、ＭＳＳユーザが、効率的にデータを転送することができる
ようにする。ＭＳＳは、バイトストリーム指向のデータ転送およびメッセージ指
向のデータ転送の両方をサポートする。ＭＳＳユーザは、MSS＿Endpoint＿Dialo
gのメッセージ指向のオプションを設定する（または設定しない）ことによって
、オペレーションのモードを選択する。ＭＳＳは、MSS＿Endpoint＿Dialogの両
側が、メッセージ指向の同じオプション値を使用することを要求する。ＭＳＳユ
ーザはまた、データがローカル環境に到達したときにＭＳＳが使用すべき、デー
タ配信のモードを選択せねばならない。

【００８２】 ＭＳＳデータ転送には、以下に示すオペレーションが、ＭＳＳによって使用さ
れる。

【００８３】 Deliver-Dataオペレーションは、ＭＳＳがＭＳＳダイアログを介してデータを
配信することを要求する。データは、Data-NotificationまたはAccept-Dataオペ
レーションのいずれかによって、同位のＭＳＳユーザに配信される。このオペレ
ーションは、コントロールダイアログ上で実行されてはならない。しかし、この
リクエストは、アプリケーションデータのためにのみ使用される必要はない。な
ぜなら、ＭＳＳユーザは、この機構を使用してコントロール情報を送信するよう
選択することもできるためである。ＭＳＳに提示されるすべてのデータは、ＭＳ
Ｓヘッダを除けば、通常は連続したメモリ領域内に存在する。ＭＳＳは、信頼性
の高いかつ順序正しいデータ配信を担当する。バイトストリーム指向のダイアロ
グについてもメッセージ指向のダイアログについても、ＭＳＳは、同位のＭＳＳ
ユーザに対して、データを２つ以上の部分として配信するよう選択することがで
きる。データを複数の部分で配信する場合、その部分的な転送および最後の転送
は、その旨が、そのデータのその部分の長さおよび、元々のDeliver-Dataリクエ
ストの長さの表示を含めて、受信側に知らされる。メッセージ指向のダイアログ
については、ＭＳＳおよびＭＳＳユーザが協働してメッセージの意味規則を扱う
。Deliver-Dataには次の２つの変形例が存在し、それらはストリーム指向のダイ
アログにもメッセージ指向のダイアログにも適用可能である。（ａ）「共用バッ
ファ」の変形例。これは、データバッファの所有権がＭＳＳに渡されることを認
めるものである。（ｂ）「私用バッファ」の変形例。この場合、ＭＳＳは、それ
が獲得するバッファ内にデータをコピーせねばならない。ＭＳＳは、このリクエ
ストのいずれかの変形例を「資源なし」表示で拒絶することが許されている。こ
のリクエストの共用バッファの変形例については、ＭＳＳは、そのオペレーショ
ンが完了したときに、コールした側に対してDeliver-Data-Completed表示を提供
する。

【００８４】 Deliver-Data-Completeオペレーションは、ＭＳＳユーザに対して、先に開始
されたDeliver-Dataオペレーションが完了したことを表示する。この表示は、受
信側の環境における処理とは独立して発生し得る。これは、同位のＭＳＳユーザ
がそのデータを受信したことを示すものではなく、単に、ローカルＭＳＳコンポ
ーネントがその処理を完了したことを示し、配信を保証する（ダイアログの失敗
を防ぐ）ものである。ＭＳＳユーザには、ＭＳＳがその対応するDeliver-Dataオ
ペレーションにおいて提供した、（ＭＳＳに対して）トランスペアレントな参照
値が提供される。

【００８５】 Accept-Dataオペレーションは、受信側のＭＳＳユーザがAuto-Data-Delivery
ダイアログオプションを選択した場合に同位のＭＳＳユーザによって開始される
Deliver-Dataリクエストを完了する結果として行なわれる動作である。このリク
エストは常に、ＭＳＳからＭＳＳユーザに対するバッファの所有権の受渡しを含
むので、このオペレーションには私用バッファの変形例は存在しない。ＭＳＳユ
ーザは、その処理を完了した後に、ＭＳＳに対して、対応するAccept-Data-Comp
lete通知を提供する。

【００８６】 Accept-Data-Completeオペレーションは、ＭＳＳに対して、先に開始されたAc
cept-Dataオペレーションが完了したことを示す表示を提供する。ＭＳＳには、
その対応するAccept-DataオペレーションにおいてＭＳＳによって提供された（
ＭＳＳユーザに対して）トランスペアレントな参照値が提供される。

【００８７】 Data-Notificationオペレーションは、ＭＳＳユーザに対してデータが利用可
能であることを示す、ＭＳＳによって提供される表示である。これは、ＭＳＳユ
ーザがAuto-Data-Deliveryダイアログオプションを選択しなかった場合に、同位
のＭＳＳユーザによるDeliver-DataリクエストをＭＳＳが完了する結果として生
じる。ＭＳＳは、どれだけのデータが利用可能であるかを表示するが、この動作
においてはデータの転送やバッファの所有権の転送は行なわれない。

【００８８】 Retrieve-Dataオペレーションは、（先に、Data-Notificationによって表示さ
れた）ＭＳＳからのデータを取出すよう、ＭＳＳユーザによって発せられるリク
エストである。ＭＳＳユーザは、ＭＳＳがその中にデータをコピーすべきバッフ
ァを、最大データ長表示とともに、提供する。Retrieve-Dataオペレーションの
結果、Retrieve-Dataリクエストにおいて要求されるデータ量および、先に表示
されたデータのステータスに応じて、ＭＳＳ Ｉ／Ｏバッファの部分的な内容、
１または複数のＭＳＳ Ｉ／Ｏバッファの内容全体、または、それらの組合せか
らなるデータが転送され得る。メッセージ指向のダイアログについて、ＭＳＳが
単一のRetrieve-Dataオペレーションで転送するのは、最大でも１つの完全なメ
ッセージのみである。特定された最大データ長が、次に利用可能なメッセージの
長さよりも短い場合には、そのメッセージは打切られて、そのメッセージの残り
の部分は廃棄される。このステータスは、ＭＳＳユーザに戻される。

【００８９】 Ｅ．異なる相互接続上のＭＳＳ 上述のように、ＭＳＳは、種々の相互接続アーキテクチャに応じて異なる。上
述の相互接続パラダイムの各々に対するＭＳＳを、以下に説明する。

【００９０】 １．ＱＳＰ相互接続 通常、図１１に示すように、ＭＳＳは、相互接続アーキテクチャ（ＨＳＤＣ）
インターフェイス上のプロトコルとしてＱＳＰｖ２メッセージフォーマットを使
用して、各リモートＭＳＳと会話する。ＭＣＰ環境においては、各ＮＴ環境に対
して出ていくデータはすべて、そのデバイスのためのＮＰ／ＣＯＮＴＲＯＬＬＥ
Ｒスタック４０を介して送られる。ＮＴ環境から入ってくるコントロールデータ
は、ＮＰ／ＣＯＮＴＲＯＬＬＥＲスタック４０を通じて受信される。コントロー
ルダイアログのために入ってくるデータは、そのデバイスのためのＭＳＳ／ＣＯ
ＮＴＲＯＬスタックを通じて受信され、MSS＿Endpoint＿Dialogのために入って
くるデータは、そのデバイスのためのＭＳＳ／ＤＡＴＡスタックを通じて受取ら
れる。１つのＮＴ環境につき１つのスタックの組が存在する。ＭＳＳダイアログ
ＩＤは、ＱＳＰｖ２アドレスの範囲にわたって多重化される。出ていくMSS＿End
point＿Dialogアドレスは、ＩＤ♯２を使用して、ＮＴ ＭＳＳユーザを判断す
る。入ってくるMSS＿Endpoint＿Dialogは、ＩＤ♯１を使用してＭＣＰ ＭＳＳ
ユーザを判断する。

【００９１】 ＱＳＰベースの相互接続については、ＭＳＳは、非共有メモリモデルである。
したがって、ＭＳＳ入出力バッファがＭＣＰ環境およびＮＴ環境の双方に存在し
、ＭＳＳは、ＱＳＰ７６を利用して、メモリの内容をそれらのバッファ間で動か
す。この環境におけるＭＣＰ出力を、図１２にまとめて示す。図１２の上半分に
示すように、私用バッファのDeliver-Dataリクエストを処理する場合、ＭＣＰ
ＭＳＳ９２は、適切なサイズの利用可能なＭＳＳ ＭＣＰ出力バッファ２００を
得る。このバッファ内に、ＭＣＰ ＭＳＳ９２は、まず、そのオペレーションを
完了するのにＮＴ ＭＳＳ９６によって必要とされるコントロール情報を配置し
、その後、データ転送ヘッダ（Data Transfer Header）およびアプリケーション
データを、このＭＳＳ ＭＣＰ出力バッファ２００内にコピーする。ＭＣＰ Ｍ
ＳＳ９２はその後、その単一領域に対する書込みを開始する。大きなデータを転
送する場合には、複数のバッファ間で分割して行なわれ得る。

【００９２】 これに対し、図１２の下半分に示すように、共用バッファのDeliver-Dataリク
エストを処理する場合には、ＭＣＰ ＭＳＳ９２はそのオペレーションを完了す
るのにＭＳＳ−ＮＴ９６によって必要とされる情報およびデータ転送ヘッダを含
む、小さな「コントロール情報バッファ（Control Info Buffer）」２０３を構
築する。ＭＣＰ ＭＳＳ９２はその後、それら２つのバッファ領域（コントロー
ル情報バッファ２０３およびＣｏｏｐのアプリケーションのユーザ出力バッファ
２０８）に対する書込みを開始する。ＱＳＰ７６が対応するリクエストを完了し
、ＭＳＳ−ＮＴ９６が、ＮＴ ＶＴＬコンポーネント９４に対して、Accept-Dat
aリクエストを提供する。ＮＴ環境のＱＳＰが、複数のバッファを必要とするリ
クエストを受取る場合には、ＭＳＳ−ＮＴ９６が、最初のバッファに含まれるコ
ントロール情報を使用して、各バッファに対してAccept-Dataリクエストを発行
する。最後に、Accept-Dataが完了したことをＮＴ ＶＴＬコンポーネント９４
から通知されると、ＭＳＳ−ＮＴ９６は、対応するＭＳＳ−ＮＴ出力バッファ２
０２をその受信バッファプールに戻す。

【００９３】 この環境におけるＭＣＰ入力を、図１３に示す。図示されるように、正常な条
件下では、ＭＣＰ ＭＳＳ９２コンポーネントでは、バッファプールからのバッ
ファを使用する、未完了の読出しオペレーションが進行中である。図１３に示す
ように、私用バッファのDeliver-Dataリクエストを処理する場合には、ＭＳＳ−
ＮＴ９６は、適切なサイズのＭＳＳ ＮＴ入力バッファ２０４を得る（大量の送
信には複数のバッファが必要とされ得る）。この入力バッファ２０４に、ＭＳＳ
−ＮＴ９６は、まず、そのオペレーションを完了するのにＭＣＰ ＭＳＳ９２に
よって必要とされる情報を位置づけ、その後、データ転送ヘッダおよびアプリケ
ーションデータをそのバッファ（１または複数）内にコピーする。共用バッファ
のDeliver-Dataリクエストに対するＭＳＳ-ＮＴ９６の処理は、完了通知が戻さ
れることを除けば、上述の私用バッファの場合と全く同様である。ＱＳＰ７６が
対応のＭＳＳリクエストを完了し、ＭＣＰ ＭＳＳ９２はＭＣＰ ＶＴＬコンポ
ーネント９０に対して、Data-NotificationまたはAccept-Dataリクエストを提供
する。ＱＳＰが複数のバッファを必要とするリクエストを受取った場合には、Ｍ
ＣＰ ＭＳＳ９２が、最初のバッファ内に含まれるコントロール情報を使用して
、各バッファに対してData-NotificationまたはAccept-Dataリクエストを発行す
る。QSP＿Send＿Msg()からの暗黙の受信通知は存在しない（ＱＳＰ７６下のすべ
ての入力は非同期であって、データは、読出リクエストがホストから発行される
のを待つリスト上の待ち行列に入れられ、かつデータは、適切なサイズの読出に
関連づけられる）ので、ＭＣＰ ＭＳＳ９２は、バッファ２０６がその制御下に
戻されるのを待ち（バッファは転送がうまく行った場合に解放される）、その後
、その事象を完了通知として使用する。

【００９４】 ２．エミュレーション相互接続 図８に示すエミュレーション相互接続の実施例は、ＭＣＰ ＭＳＳ９２コンポ
ーネントが、ネイティブのＮＴコード内に直接（すなわち、ＮＴ ＭＳＳコンポ
ーネント９６内に直接）、手続き呼出しを行なうことができる機能に基づいてい
る。ＮＴ ＭＳＳコンポーネント９６は、これらの手続き呼出しにおいて提供さ
れるＭＣＰメモリスペースバッファに、直接アクセスすることができる。これら
のバッファは、ＭＳＳコンポーネント９２および９６の間で受渡されるユーザデ
ータおよびコントロールメッセージの双方のために使用される。

【００９５】 ＭＳＳダイアログは、簡単なデータ構造（コントロールダイアログ情報ブロッ
ク（Control Dialog Info Blocks）およびエンドポイントダイアログ情報ブロッ
ク（Endpoint Dialog Info Blocks））によって、ＭＣＰ ＭＳＳ９２コンポー
ネントおよびＭＳＳ−ＮＴ９６コンポーネント内に維持される。ＭＣＰ ＭＳＳ
のダイアログ情報ブロックとＭＳＳ−ＮＴのダイアログ情報ブロックとの間には
、１対１の対応がある。さらに、以下のＭＳＳ−ＮＴルーチンが、ＭＣＰ ＭＳ
Ｓ９２によってユーザ呼出し可能である。

【００９６】 １．MSS＿NT＿Rcv＿Msgは、ＭＣＰ環境からＮＴ環境にメッセージを配信する
のに使用される。ＭＣＰ ＭＳＳ９２は、該当するフィールドを「コントロール
情報バッファ」２０３内に集め、これがＭＳＳ ＮＴ手続きにおいて渡される。
ＭＣＰ ＭＳＳ９２は、ＭＳＳ−ＮＴ９６に直接アクセスすることができる。

【００９７】 ２．MSS＿NT＿Notify＿Inputは、ＮＴ環境からメッセージを取出すのに、ＭＣ
Ｐ環境によって使用される。MSS＿NT＿Notify＿Inputは、実際には出力を返すこ
とはなく、単に、入力が利用可能であることと、それがどのＭＳＳダイアログ上
で利用可能なのかを示す。MSS＿NT＿Notify＿Inputは、メッセージが利用可能に
なるか、何らかのエラー条件が検出されるまで、返信されることはない。

【００９８】 ３．MSS＿NT＿Retrieve＿Inputは、先にMSS＿NT＿Notify＿Inputによって表示
されたメッセージをＮＴ環境から取出すのに、ＭＣＰ環境によって使用される。
ＭＣＰ ＭＳＳ９２は、ＭＳＳ ＭＣＰ入力バッファ２０６またはＭＳＳユーザ
バッファ２０８を提供し、その中に、ＭＳＳ−ＮＴ９６が配信されるべきメッセ
ージを入れる。

【００９９】 この環境におけるＭＣＰ出力を、図１４にまとめて示す。Deliver-Dataリクエ
ストのいずれかの変形例（私用バッファ、共用バッファ）の処理時に、ＭＣＰ
ＭＳＳ９２は、そのオペレーションを完了するのにＭＳＳによって必要とされる
情報およびデータ転送ヘッダを含む、小さな「コントロール情報バッファ」２０
３を構築し、MSS＿NT＿Rcv＿Msgを呼出す。提供される情報の中に、ＭＳＳユー
ザの出力バッファ２０８が含まれる。MSS＿NT＿Rcv＿Msgは、Deliver-Dataメッ
セージをＭＳＳユーザの出力バッファ２０２から利用可能なＭＳＳ ＮＴ出力バ
ッファ２０２（１または複数）へとコピーすることによって、そのメッセージを
処理する（もし利用可能な出力バッファ２０２がなければ、そのルーチンの返信
結果において、否定応答がＭＳＳ−ＮＴ９６に返される）。データは、データの
コピーと同じオペレーションにおいて、エミュレートされたＭＣＰレイアウトか
らＮＴレイアウトに変換される。ＭＳＳ−ＮＴ９６は、ＮＴ ＶＴＬコンポーネ
ント９４に対して、Accept-Dataリクエストを提供する。ＭＳＳ−ＮＴ９６が複
数のバッファに対してＭＣＰ環境データをコピー／変換するよう要求する場合に
は、各バッファに対してAccept-Dataリクエストが発せられる。

【０１００】 この環境におけるＭＣＰ環境の入力を、図１５にまとめて示す。正常な条件下
では、MSS＿NT＿Notify＿Inputのコールが未完了である。Deliver-Dataリクエス
トのいずれかの変形例（私用バッファまたは共用バッファ）の処理時、ＭＳＳ−
ＮＴ９６は、適切なサイズの利用可能なＭＳＳ ＮＴ入力バッファ２０４を獲得
し、そのバッファ内に、そのオペレーションを完了するのにＭＳＳによって必要
とされる情報を構築し、かつ、データ転送ヘッダおよびユーザデータをコピーす
る（そのデータは、データコピーと同じオペレーションにおいて、ＮＴレイアウ
トからＭＣＰレイアウトに変換される）。その後、ＭＳＳ ＮＴ９６は、MSS＿N
T＿Notify＿InputがＭＣＰ ＭＳＳコンポーネント９２に戻るようにする。MSS
＿NT＿Notify＿Inputからの返信時の、ＭＣＰ ＭＳＳコンポーネント９２の処
理は、MSS＿Endpoint＿DialogのAuto-Data-Deliveryの、次のようなオプション
に依存する。すなわち、Auto-Data-Deliveryが設定されている場合には、MSS＿N
T＿Retrieve＿Dataが即座に呼出され、ＭＳＳ ＭＣＰ入力バッファ２０６に入
ってくるデータが取出され、それが、Accept-Dataオペレーションによって、Ｍ
ＳＳユーザに配信される。さもなければ（すなわち、Auto-Data-Deliveryが設定
されていない場合には）、データ通知（Data Notification）が発行されて、Ｍ
ＳＳユーザがRetrieve-Dataオペレーションを開始するときに処理が始まる。

【０１０１】 ３．ＣＩＡ相互接続 上述のように、相互接続はまた、上述の関連出願に説明された種類のＣＩＡで
もあり得る。ＣＩＡベースの実現例のＭＳＳは、ノードの各対間の通信のために
１または複数のＣＩＡダイアログを使用し、ＭＳＳの観点からは、実際のシステ
ム環境とはかかわりなく、共用されないメモリモデルである。したがって、ＭＳ
Ｓ入出力バッファは、ＭＣＰ環境とＮＴ環境のいずれにも存在し、ＭＳＳはＣＩ
Ａを使用して、それらバッファ間でメモリの内容を移動および変換する。ＣＩＡ
環境においては、ＭＳＳは、ＣＩＡノード間でバッファプール、プールマネージ
ャおよびダイアログを作成する、ＣＩＡクライアント（ユーザ）である。これは
、ＭＳＳユーザによって使用される、「プルモデル」および「プッシュモデル」
の双方を提示する。この環境におけるＭＣＰ出力を、図１６にまとめて示す。

【０１０２】 図１６に示すように、正常な条件下では、両方のＭＳＳコンポーネント（ＭＣ
Ｐ ＭＳＳ９２およびＭＳＳ−ＮＴ９６）が、バッファプールを使用する未完了
のＣＩＡ受信オペレーションを有する。私用バッファのDeliver-Dataリクエスト
の処理時、ＭＣＰ ＭＳＳ９２はデータを利用可能なＭＳＳ−ＭＣＰ出力バッフ
ァ２００内にコピーし、そのオペレーションを完了するのにＭＳＳによって必要
とされる情報およびデータ転送ヘッダを含む、小さな「コントロール情報バッフ
ァ」２０３を構築し、その後、それら２つのバッファ領域からのＣＩＡ送信を開
始する。共用バッファのDeliver-DataリクエストのためのＭＣＰ ＭＳＳ９２の
処理は同様であるが、ＣＩＡ送信リクエスト内にＣｏｏｐのアプリケーションの
出力バッファ２０８が使用される点のみが異なる。ＣＩＡが対応の送受信リクエ
ストを完了し、一方、ＭＳＳ−ＮＴ９６がＮＴ ＶＴＬコンポーネント９４に対
して、Accept-Dataリクエストを提供する。ＮＴ環境のＣＩＡが複数のバッファ
を必要とするリクエストを受取った場合には、ＭＳＳ−ＮＴ９６が、最初のバッ
ファに含まれるコントロール情報を使用して、各バッファに対してAccept-Data
リクエストを発行する。ＮＴ ＶＴＬコンポーネント９４からAccept-Dataが完
了したことが通知されると、ＭＳＳ−ＮＴ９６は対応するバッファ２０２をその
受信バッファプールに戻す。

【０１０３】 この環境におけるＭＣＰ入力を、図１７にまとめて示す。図示するように、正
常な条件下では、ＭＣＰ ＭＳＳ９２コンポーネントは、バッファプールを使用
する未完了のＣＩＡ受信オペレーションを有する。私用バッファのDeliver-Data
リクエストの処理時には、ＭＳＳ−ＮＴ９６はデータを利用可能なＭＳＳ ＮＴ
入力バッファ２０４内にコピーし、そのオペレーションを完了するのにＭＳＳに
よって必要とされる情報およびデータ転送ヘッダを含む、小さな「コントロール
情報バッファ」２０３を構築し、その後、それら２つのバッファ領域からのＣＩ
Ａ送信を開始する。共用バッファのDeliver-DataリクエストのためのＭＳＳ−Ｎ
Ｔ９６の処理も同様であるが、ＣＩＡ送信リクエストにおいてＴＤＩ−ＣＬＩＥ
ＮＴの出力バッファ２１０が使用される点のみが異なる。ＣＩＡが対応の送受信
リクエストを完了し、一方、ＭＣＰ ＭＳＳ９２がＭＣＰ ＶＴＬコンポーネン
ト９０に対して、Data-NotificationまたはAccept-Dataリクエストを提供する。
ＣＩＡが複数のバッファを必要とするリクエストを受取った場合には、ＭＣＰ
ＭＳＳ９２が、最初のバッファに含まれるコントロール情報を使用して、各バッ
ファに対してData-NotificationまたはAccept-Dataリクエストを発行する。

【０１０４】 Ｆ．ＭＳＳの初期化、終了、および回復 １．初期化 図１８に示すように、ＭＳＳの初期化は２つのステップで行なわれる。第１の
ステップは、ネットワーキング環境がMSS＿initialize()のコールによって開始
されるときに行なわれる。これは、ＭＣＰ環境においては、初期化時にＴＣＰＩ
ＰＳＵＰＰＯＲＴライブラリから行なわれ、ＮＴ環境においては、ＶＴＬソフト
ウェアがロードされて（ＮＴブート時に）初期化されたときに行なわれる。第２
のステップは、すべての相補的ＭＳＳに対してMSS＿HELLOパケットを送信するス
テップである。これは、ＭＣＰ環境においては、インターフェイスが利用可能と
なってＭＣＰ環境によって開始されるときに行なわれるが、ＮＴ環境においては
、ＭＳＳは、MSS＿HELLOが受信されるまで待って、その後、対応のMSS＿HELLOパ
ケットで応答する。ユーザが新しいユーザが利用可能であると通知されたときに
最初に行なわねばならないのは、その新しいリモートユーザと挨拶することであ
る。

【０１０５】 ２．回復 ＭＳＳによって付与されるこのあるレベルの抽象化の利点の１つは、ＭＳＳユ
ーザが遠隔環境における回復の管理について心配する必要がないことである。Ｍ
ＳＳが回復を扱い、そのユーザに対してリモート「ユーザ」環境における変化を
すべて通知する。ＭＳＳは、システム相互接続によって異なる論理を有するが、
これは、各システム相互接続が、その領域において、異なる通知および手続きを
提供するためである。

【０１０６】 ３．終了 ＭＳＳは、最後のユーザがＭＳＳとのリンクを終了したときに終了されねばな
らない。このプロセスは、MSS＿initialize()の逆を行なう。図１９に示すよう
に、アクティブなＭＳＳは、ＭＳＳの終了の結果として終了された各MSS＿Endpo
int＿Dialogについてダイアログ変更通知を受信すると、アクティビティを終了
する。ＭＣＰ環境においては、ＭＳＳの終了は、MSS＿GOODBYEメッセージの到着
か、遠隔環境とのすべてのダイアログを終了させるMSS＿Terminate()のコールか
、または、MSS＿Reset＿Remote＿User()のコールによって、開始される。これに
対し、ＮＴ環境においては、ＭＳＳの終了は、ウィンドウズＮＴ環境の停止（MS
S＿Terminate()のコール、または、NX/Network Servicesの停止）の結果として
起こる、ネットワーキングサービスの停止によって開始される。これは、遠隔環
境の異常終了を扱うものではない。そのような場合、ローカルＭＳＳは、他方の
環境が終了または故障したと判断する別の方法を有し得る。

【０１０７】 Ｇ．ＭＳＳ上のデータ伝送 ＭＳＳは、ユーザが遠隔の環境およびユーザに対して情報を送信するのに、バ
イトストリームおよび、信頼性の高いメッセージ指向のインターフェイスの、両
方を提供する。ＭＳＳはまた、受信側の環境において２つの異なる通知機構を備
える。すなわち、ＭＳＳがユーザに対して、データが読出に利用可能であること
を通知するか（「プル」モデル）、または、ＭＳＳが、新しいデータを受入れる
ためにユーザ規定の手続きを自動的に呼出すか（「プッシュ」モデル）、のいず
れかである。このように抽象化層が付加されることによって、ネットワークプロ
バイダは、ＴＣＰ／ＩＰプロトコルに存在するような、基礎となるＩ／Ｏの制約
および特異性について心配する必要がなくなる。この情報は、正しい順序で遠隔
環境へと配信されるが、性能上の理由またはシステム相互接続の限度によっては
、システム相互接続にわたって分割されることもあり得る。

【０１０８】 図２０は、遠隔環境へのデータ配信の両方のモデルを示す。図２０の上半分は
「プル」モデルを示す。このモデルでは、リモートＭＳＳユーザが、MSS＿Endpo
int＿Dialog上でデータが利用可能であることを示す通知を受信し、ＭＳＳユー
ザがそのデータを、ＭＳＳから取出さねばならない。図２０の下半分は「プッシ
ュ」モデルを示す。このモデルでは、遠隔ＭＳＳが、データをＭＳＳユーザに配
信するために予め規定されたユーザルーチンを呼出す。リモートＭＳＳユーザは
、データバッファの処理を終了したときに、それをＭＳＳに通知せねばならない
。

【０１０９】 メッセージベースではないダイアログ上では、MSS＿Deliver＿Dataに渡される
各バッファは、システム相互接続を介して転送するために、複数のMSS＿DATAパ
ケットに分割され得る。この分割は、システムの相互接続モジュール（ＨＩＦ）
に依存する。遠隔ＭＳＳはデータをまとめ直すことはしない。それらのデータを
１つのメッセージにまとめるのは、ＭＳＳユーザである。これに対し、メッセー
ジベースのダイアログ上では、ＭＳＳはデータを分割することはできず、システ
ム相互接続がそのデータメッセージのサイズを処理することができない場合には
、エラーを戻す。

【０１１０】 １．ＭＳＳエンドポイントダイアログ MSS＿Endpoint＿Dialogは、（一方がＭＣＰ環境内で実行し、他方がＮＴ環境
内で実行する）相補的なユーザ間の協調型手続きによって作成される。図２１は
、ＭＳＳの観点からの開始プロセスを示す。図２１に示すように、ユーザのMSS
＿Endpoint＿Dialogは、以下の手続きに従って構築される。

【０１１１】 １．ＭＳＳのあるユーザが、そのローカルＭＳＳに対して、MSS＿Create＿End
point＿Dialogのコールを開始する。ローカルＭＳＳはそのパラメータを検証し
、もし有効であれば、ローカルダイアログテーブル内にエントリを作成して、そ
のコールにおいて特定されたリモートＭＳＳに対して、MSS＿CREATE＿DIALOGパ
ケットを送信する。新しく作成されたローカルダイアログ識別子は、ユーザに戻
される。

【０１１２】 ２．リモートＭＳＳは、MSS＿CREATE＿DIALOGにおいて渡されたパラメータを
検証し、有効であれば、そのローカルダイアログテーブル内にエントリを作成す
る。新しいダイアログのＩＤは、MSS＿CREATE＿RESPONSEパケットを介して、開
始側のＭＳＳに戻される。パラメータまたはローカルエントリの作成のいずれか
に問題がある場合には、MSS＿ERRORパケットが開始側のＭＳＳに戻される。この
情報は、ローカルユーザがダイアログを開こうと試みたときに、ローカルユーザ
に戻される。

【０１１３】 ３．新しく作成されたローカルダイアログのＩＤは、開始側のユーザ（図の左
側のライン）から遠隔ユーザ（右側のライン）へと、何らかの外部機構を介して
渡される。このようなメカニズムの１つに、コントロールダイアログ上のMSS＿S
end＿Control＿Msgインターフェイスがある。

【０１１４】 ４．遠隔環境内のユーザは、MSS＿Open＿Endpoint＿DialogによってＭＳＳを
呼出し、それが開始側のユーザから受取ったダイアログのＩＤを渡す。ローカル
ＭＳＳはこのダイアログが有効であることを検証し、エラーが生じなかった場合
には、オリジナルの開始側ＭＳＳ（MSS＿Create＿Endpoint＿Dialogを行なった
側）にMSS＿OPEN＿DIALOGパケットを送信する。そのダイアログ上で先にエラー
が生じていた場合（またはそのダイアログが作成されなかった場合）には、この
エラーはここで、コールした側のユーザに戻される。

【０１１５】 ５．開始側のＭＳＳは、MSS＿OPEN＿DIALOGを受取ると、ダイアログを開いてM
SS＿OPEN＿RESPONSEを返し、そのローカルユーザに対して、そのダイアログがデ
ータに対して今や利用可能であることを、Dialog＿Change＿Notification（AVAI
LABLE）によって通知する。

【０１１６】 ６．遠隔ＭＳＳは、MSS＿OPEN＿RESPONSEを受信すると、そのローカルユーザ
に対してDialog＿Change＿Indication（AVAILABLE）を通知することによって、
オープンダイアログシナリオを完了する。

【０１１７】 ７．これにより、そのダイアログをデータ転送に使用することができるように
なる。

【０１１８】 ＭＳＳデータダイアログは、相補的なユーザ間で協調型の手続きを介して終了
される。それらはまた、環境障害の結果としても終了され得る。図２２は、ＭＳ
Ｓの観点からの終了プロセスを図示する。図２２に示すように、MSS＿Endpoint
＿Dialogの正常なクローズは以下のように行なわれる。

【０１１９】 １．ＭＳＳユーザが、あるMSS＿Endpoint＿Dialogに対するMSS＿Close＿Endpo
int＿Dialogをコールする。ローカルＭＳＳが、MSS＿CLOSE＿DIALOGパケットを
作成して、リモートＭＳＳに送る。ローカルＭＳＳはまた、ローカルユーザに対
して、そのダイアログがもはや使用できないことを（Dialog＿Change＿Notifica
tionを通じて）通知する。

【０１２０】 ２．リモートＭＳＳが、MSS＿CLOSE＿DIALOGを受取り、リモートユーザがその
ダイアログを閉じたことを、Dialog＿Change＿Notification（REMOTE＿CLOSED）
のコールによって、そのローカルユーザに通知する。そのダイアログ上で読出さ
れるのを待っているデータはすべて、ローカルユーザが検索するのに未だ利用可
能である。しかし、ローカルユーザは、このダイアログ上でデータをそれ以上送
信することはできない。ローカルＭＳＳは、MSS＿CLOSE＿RESPONSEパケットを送
信して、それがクローズパケットを処理し終わったことを知らせる。

【０１２１】 ３．そのしばらく後に、ローカルユーザがMSS＿Close＿Endpoint＿Dialogをコ
ールする（まだ読出されていない未処理のデータは廃棄される）。ローカルＭＳ
ＳはMSS＿CLOSE＿DIALOGを生成し、それを（応答する）リモートＭＳＳに送信す
る。ローカルＭＳＳはまた、ローカルＭＳＳに対してDialog＿Change＿Notifica
tion（UNAVAILABLE）を生成する。

【０１２２】 MSS＿Endpoint＿Dialogは、ユーザのうち１人によって破壊することも可能で
ある。図２３はそのような異常終了処理を示し、これは以下のステップを含む。

【０１２３】 １．ＭＳＳユーザが、MSS＿Destroy＿Endpoint＿Dialogをコールする。ローカ
ルＭＳＳは、そのダイアログ上で待っているすべてのデータを廃棄し、MSS＿DES
TROY＿DIALOGパケットをリモートＭＳＳに送信する。これはまた、ローカルユー
ザに対して、そのダイアログがもはや利用できないことを（Dialog＿Change＿No
tification（UNAVAILABLE）によって）通知する。

【０１２４】 ２．遠隔ＭＳＳが、MSS＿DESTROY＿DIALOGパケットを受取って、そのローカル
ユーザに対して、そのダイアログがもはや利用できないことを（Dialog＿Change
＿Notification（UNAVAILABLE）によって）通知し、まだ読出されていないすべ
てのデータを廃棄する。これは、この側においては暗黙のクローズである。

【０１２５】 ２．ＭＳＳコントロールダイアログ ＭＳＳはまた、相補的なユーザ間でコントロールメッセージを配信するための
、遠隔環境への経路を提供する。ＭＳＳユーザは、このコントロール経路（コン
トロールダイアログ）を介して、または他のＭＳＳダイアログを介して、コント
ロールメッセージを送信したいと望むかもしれない。この経路は、上述のデータ
経路と同様のものであるが、あるダイアログオプションが予め設定されている（
データは自動的にユーザに配信され、ダイアログはメッセージ指向であって、宛
先ＭＳＳはこのメッセージをユーザに提示するために別のバッファにコピーせね
ばならない）。

【０１２６】 Ｈ．ＭＳＳデータ構造 ＭＳＳにおいて宣言されるすべての変数はすべてのシステム相互接続に対して
グローバルなものであるため、ＭＳＳには内部データはない。ＭＳＳは、リモー
ト環境で実行されるＭＳＳの他のインスタンスとＭＳＳパケットの交換によって
通信する。これらのパケットはＭＳＳ環境間での制御およびユーザデータの両方
の転送と、ＭＳＳ制御情報の転送とに使用される。それらはＭＳＳコマンドヘッ
ダと、その直後にあるヘッダおよび実データとからなる。２つのＭＳＳ間の転送
を行うたびに、少なくともコマンド部分が使用される。

【０１２７】

【数１】

【０１２８】 フィールドとは下記のものである。 p＿version:ＭＳＳインターフェイスのバージョン。

【０１２９】 p＿command:ＭＳＳコマンド p＿seq＿num:このパケットのシーケンス番号。これは各対のＭＳＳ間に独特な
ものであり、MSS＿HELLOパケットにおいて特定された番号から開始し、パケット
が送信されるたびに１だけインクリメントされる。

【０１３０】 p＿src＿dialogid:このパケットに関するソースＭＳＳダイアログid。 p＿dst＿dialogid:このパケットに関する宛先ＭＳＳダイアログid。宛先シス
テム相互接続アドレスは、宛先環境で受信されたときにパケットに存在するシス
テム相互接続ヘッダにある。

【０１３１】 p＿cmd＿ptr:このパケットに存在するすべてのコマンドパラメータに対するポ
インタ。

【０１３２】 p＿cmd＿len:このＭＳＳパケットに存在するＭＳＳコマンドパラメータ情報の
長さ。

【０１３３】 p＿hdr＿len:このＭＳＳパケットに存在するユーザヘッダ情報の長さ。 p＿data＿len:このＭＳＳパケットに存在するユーザデータ情報の長さ。

【０１３４】 p＿flags:このパケットに関するビット情報 p＿local＿endpoint:システム相互接続アドレスにおけるローカルエンドポイ
ントでありデータの配信に有用である。このフィールドは、MSS＿DATAおよびMSS
＿CONTROL＿DATAメッセージに対してのみ有効である。

【０１３５】 p＿msg＿ptr:実データに対するポインタ。 これらのパケットのデータ部分はメッセージとして維持される。MSS＿MESSAGE
およびデータブロック構造は下記のフォーマットを有する。

【０１３６】

【数２】

【０１３７】 環境の中には、各メッセージが１つのデータブロックしか持たないことという
制約を強制し得るものもある（これは特に外に出ていくデータについて当てはま
る）。しかしながら、入来データについては、ＭＳＳはシステムの相互接続上の
制約のために１つまたは２つ以上のデータブロックにメッセージを分割する必要
があるだろう。

【０１３８】 Ｉ．ＭＳコマンドセット 以下に、（種々の環境で動作する）他のＭＳＳに対してデータを通信および転
送するためにＭＳＳが使用するコマンドおよびパケット構造について説明する。
各コマンドは、それがセットするＭＳＳパケットのフィールドを表わすだけであ
ろう。他のフィールドはすべて０に初期化される。パケットのシーケンス番号は
、MSS＿HELLOコマンドは例外であるが、次の有効なシーケンス番号である。すべ
ての場合において、ＭＳＳの送信側エンドポイントにはp＿src＿dialogidがセッ
トされ、p＿dst＿dialogidは宛先ダイアログidである。

【０１３９】 コマンド（たとえばMSS＿CREATE＿DIALOG）では、ローカルパラメータ（local
＿が前に付加される）はローカル環境（コマンドが発行された環境）を意味する
。リモートパラメータ（remote＿が前に付加される）はリモート環境（ダイアロ
グ生成のための対応する環境）を意味する。応答については逆のことが言える。
ローカルパラメータはリモート環境（命令が発行された環境）を意味し、リモー
トパラメータはローカル環境（応答を生成する環境）を意味する。たとえば、す
べての応答が生成される場合には、ＭＳＳはローカルではなくリモート属性を書
入れる。

【０１４０】 MSS＿HELLOは、ローカルＭＳＳが初期化を終了したときにすべてのリモートＭ
ＳＳと挨拶をするためにローカルＭＳＳが使用する。これは、この環境のＭＳＳ
に関するローカル情報をリモート環境に送る。リモートＭＳＳはそれらの情報を
持つMSS＿HELLOパケットによって応答する。

【０１４１】 p＿version＝このＭＳＳがサポートする最高レベル。 p＿command＝MSS＿HELLO; p＿seq＿num＝通常は１である開始シーケンス番号 p＿cmd＿len＝sizeof (mss＿hello＿params)

【０１４２】

【数３】

【０１４３】 このコマンドで送られたエンドポイントは、ＭＳＳのこのインスタンスとの通
信に使用するリモートＭＳＳに関するシステム相互接続アドレスを特定する。た
とえば、図６の相互接続実装例では、これらはＱＳＰヘッダに使用されるＲＱＲ
（リモートキューリファレンス）に相当する。これらは通常、その対応のホスト
プロセスによるスタブの初期化で交換される。

【０１４４】 各リモート環境のMSS＿HELLO応答が受信されると、このリモート環境が使用で
きる状態にあることを示すUSER＿DIALOG＿NOTIFICATIONがＭＳＳの各ユーザに送
信される。

【０１４５】 MSS＿GOODBYEは、それが終了することをすべてのリモートＭＳＳに知らせるの
にローカルＭＳＳによって使用される。リモート環境はこのコマンドに応答しな
い。リモート環境がMSS＿GOODBYEコマンドを受信すると、このリモート環境を持
つすべてのMSS＿Endpoint＿Dialogsが無効化され（ユーザにはDIALOG＿CHANGE＿
NOTIFICAIONによって通知される）、その後制御ダイアログが無効化される。こ
れにより、この環境がもはやアクティブではないことを示すUSER＿CHANGE＿NOTI
FICATIONがＭＳＳの各ユーザに送信される。

【０１４６】 MSS＿CREATE＿DIALOGは、（MSS＿Create＿Endpoint＿Dialogからの）ローカル
生成パラメータをリモートＭＳＳに通信するために使用される。パラメータは構
造体MSS＿create＿paramsを使用することにより転送される。

【０１４７】

【数４】

【０１４８】 リモート環境がこのコマンドを受信すると、それは送信元の制御ダイアログ(c
tl＿dialog＿id)に関連した環境に送られたパラメータに基づいてダイアログエ
ンドポイントを生成する。local＿addressはこのダイアログのために使用される
こととなる、システムの相互接続に依存するアドレスである。うまくいった場合
、それはMSS＿CREATE＿RESPONSEにおいて新規に作成されたエンドポイントに関
する情報を返す。うまくいかない場合にはMSS＿ERRORを返す。

【０１４９】 MSS＿CREATE＿RESPONSEはMSS＿CREATE＿DIALOGプリミティブに応答するために
使用される。それは、エンドポイントがうまく生成されたことを示す。この情報
はローカルダイアログテーブルにストアされる。

【０１５０】

【数５】

【０１５１】 応答においては、remote＿dialog＿idはリモート環境における新規に作成され
たエンドポイントである。Remote＿addressはリモート環境と通信するために使
用される、システムの相互接続に依存するアドレスである。

【０１５２】 MSS＿OPEN＿DIALOGは先に生成されたエンドポイントをオープンするために使
用される（エンドポイントはリモート環境で生成され、ダイアログidは制御ダイ
アログなどの何らかの他の手段によってこの環境に送られている）。

【０１５３】

【数６】

【０１５４】 リモート環境がこのコマンドを受信すると、それはダイアログをオープンする
。うまくいった場合、それはMSS＿OPEN＿RESPONSEを返し、エラーがあった場合
にはMSS＿ERRORを返す。

【０１５５】 MSS＿OPEN＿RESPONSEはMSS＿OPEN＿DIALOGコマンドに応答するために使用され
る。それはオープンの状態を返す。

【０１５６】

【数７】

【０１５７】 MSS＿CLOSE＿DIALOGは（ユーザがMSS＿Close＿Endpoint＿Dialogを呼出した結
果として）ダイアログをクローズするために使用される。うまくいった場合には
MSS＿CLOSE＿RESPONSEを返し、エラーがあった場合にはMSS＿ERRORを返す。

【０１５８】

【数８】

【０１５９】 MSS＿CLOSE＿RESPONSEはMSS＿CLOSE＿DIALOGコマンドに応答するために使用さ
れる。それはクローズの状態を返す。

【０１６０】

【数９】

【０１６１】 MSS＿DESTROY＿DIALOGは（ユーザがMSS＿Destroy＿Endpoint＿Dialogを呼出し
た結果として）ダイアログをクローズし、データを無効化するために使用される
。うまくいった場合にはMSS＿DESTROY＿RESPONSEを返し、エラーがあった場合に
はMSS＿ERRORを返す。

【０１６２】

【数１０】

【０１６３】 MSS＿DESTROY＿RESPONSEはMSS＿DESTROY＿DISLOGコマンドに応答するために使
用される。それは無効化の状態を返す。

【０１６４】

【数１１】

【０１６５】 MSS＿ERRORは１つのＭＳＳ環境から発信元のＭＳＳ環境にエラー応答が戻され
ることを示すために使用される。応答には、不当なコマンドとともにmss＿resul
tエラーコードが含まれる。

【０１６６】

【数１２】

【０１６７】 ＭＳＳは、現在のコマンドのうちどれが失敗したかを決定し、かつerror＿cod
eを呼出し側ユーザに返すためにこれを使用し得る。

【０１６８】 MSS＿DATAは１つのＭＳＳ環境から別のものにバイトストリームデータを転送
するために使用される。メッセージのデータ部分はコマンドヘッダにおいて特定
されたダイアログidに対する待ち行列に入れられることとなるユーザデータであ
る。

【０１６９】

【数１３】

【０１７０】 データはMSS＿DATAパケットヘッダに後続する。受信時に、ＭＳＳは、パケッ
トにおいて特定されたダイアログに対する待ち行列にデータを入れることとなる
。

【０１７１】 MSS＿CONTROL＿DATAは１つのＭＳＳ環境から別のものに制御情報を転送するた
めに使用される。それは、ユーザデータの代わりに制御情報を含むことを除いて
は、MSS＿DATAパケットと同一である。ユーザはユーザヘッダとして制御情報を
送信する。

【０１７２】

【数１４】

【０１７３】 MSS＿HEARTBEATは任意のリモート環境／ＭＳＳの状態をチェックするために使
用される。ハートビートは、予め定められた期間（たとえば１０秒）内にリモー
トＭＳＳから新規メッセージが送信されていない場合に送信される。長期間（た
とえば５分）にわたってハートビートが受信されない場合、制御ダイアログには
ＵＮＡＶＡＩＬＡＢＬＥがマークされ、その制御ダイアログを介するすべてのダ
イアログが終了する。ＡＶＡＩＬＡＢＬＥ制御ダイアログにMSS＿HEARTBEATが受
信される場合、リモート環境／ＭＳＳは依然として通信状態にあり、すべての非
アクティブ時間がリセットされる。一方、MSS＿HEARTBEATがＵＮＡＶＡＩＬＡＢ
ＬＥ制御ダイアログに受信される場合、それは無視される。

【０１７４】 Ｊ．ＭＳＳユーザ手順 本章では、リモートＭＳＳによって通信ダイアログなどを確立するためにＭＳ
Ｓのユーザが呼出し得る手順について説明する。次章で説明するが、ＶＴＬとは
発明の好ましい実施例におけるＭＳＳユーザである。

【０１７５】 MSS＿Initializeは、ＭＳＳとそのユーザとの間のインターフェイスを初期化
するルーチンである。それはプラットフォームに特有の初期化ルーチンから呼び
出され、すべての構造（テーブル空間、ヘッダ）を初期化する責任を負う。

【０１７６】

【数１５】

【０１７７】 MSS＿Terminateは、ユーザとＭＳＳとの間のインターフェイスを終了する手順
である。この手順によりすべてのダイアログ（異常終了）が無効化され、リモー
ト環境にそれが通知されることとなる。MSS＿Endpoint＿Dialogsに対する処理が
まず行なわれ、その後制御ダイアログに対するものが続く。これがＭＳＳの最後
のユーザである場合、ＭＳＳはすべての構造を終了させ解放する。

【０１７８】

【数１６】

【０１７９】 MSS＿RESET＿REMOTE＿USERは、ユーザとリモートユーザのＭＳＳとの間のイン
ターフェイスを終了させる手順である。まだクローズされていないダイアログが
ある場合、この手順によりそのようなダイアログがすべて無効化され（異常終了
）、そのことがリモート環境に通知される。MSS＿Endpoint＿Dialogsに対する処
理がまず行われ、その後制御ダイアログに対する処理が行なわれる。次いで、制
御ダイアログが（自動再初期化またはこの手順）によって再確立される。これは
１人のユーザに関するMSS＿terminate()およびMSS＿initialize()に等しい。

【０１８０】

【数１７】

【０１８１】 MSS＿Create＿Endpoint＿Dialogは、ローカル環境におけるMSS＿Endpoint＿Di
alogエンドポイントを生成し、かつこのダイアログをオープンするために使用さ
れ得るリモート環境からのダイアログＩＤを返す手順である。ＭＳＳは、何らか
の動作によってこのダイアログを介してパラメータlocal＿user＿referenceを返
すこととなる。パラメータmessage＿offsetは各バッファの初めにどれだけのス
ペースがあるかを特定する。うまくいった場合、この手順はMSS＿Endpoint＿Dia
logをオープンするプロセスを開始する。生成されたばかりのMSS＿Endpoint＿Di
alogはPENDING＿OPEN状態であり、オープンは、返されたDialog＿IDによってリ
モート環境がMSS＿Open＿Endpoint＿Dialogを行なうときに完了し得る。これが
行なわれると、このユーザには、MSS＿Endpoint＿Dialog変更通知による通知が
行なわれる。

【０１８２】

【数１８】

【０１８３】 MSS＿Open＿Endpoint＿Dialogは、先に生成されている（リモート環境からの
）MSS＿Endpoint＿Dialogをオープンする手順である。Local＿user＿reference
、options、message＿offsetはMSS＿Create＿Endpoint＿Dialog()と同じ意味を
持つ。うまく完了すると、ダイアログはまだPENDING＿OPENである。他の側がオ
ープンを確認すると、MSS＿Endpoint＿Dialog変更通知がユーザに送信されるこ
ととなる。

【０１８４】

【数１９】

【０１８５】 MSS＿Close＿Endpoint＿Dialogは、MSS＿Endpoint＿Dialogのクローズを開始
する手順である。ダイアログに対する待ち行列に依然として入れられているリモ
ート環境からの入来データはすべて消去される。リモート環境において待ち行列
に入れられた外に出ていくデータはすべて依然としてリモート環境で（NO＿DATA
＿AVAILABLEがＭＳＳによって返されるまで）取出され得る。ローカルダイアロ
グが直ちにクローズされ、DIALOG＿NOT＿OPENによって後の動作すべてがリター
ンする。一旦クローズされるとリモートダイアログはこれ以上データを送信する
ことができず、REMOTE＿CLOSEDの状態を持つDIALOG＿CHANGE＿INDICATIONを受信
する。リモートダイアログが一旦クローズされると、データが除去される。

【０１８６】

【数２０】

【０１８７】 MSS＿Destroy＿Endpoint＿DialogはMSS＿Endpoint＿Dialogをクローズしかつ
無効化する手順である。両環境において待ち行列に入れられたすべてのデータが
自動的に消去される（ＭＳＳによる後のデータ取出ではNO＿DATA＿AVAILABLEが
返される）。ローカルダイアログが直ちにクローズされ、DIALOG＿NOT＿OPENに
よって後の動作がすべてリターンする。リモートダイアログはCLOSEDの状態を持
つDAILOG＿CHANGE＿INDICAITONを受信する。リモートダイアログは一旦クローズ
されるとそれ以上データを送信することができない。

【０１８８】

【数２１】

【０１８９】 MSS＿Send＿Control＿Msgは、あるＭＳＳユーザから別のＭＳＳユーザにダイ
アログを介して制御メッセージを送信する手順である。制御メッセージは制御ダ
イアログまたはMSS＿Endpoint＿Dialogのいずれかによって送信され得る。OUT＿
OF＿RESOURCESが返された場合には、プラットフォームが非常に深刻な状態にあ
りフロー制御されていること（制御メッセージの方がデータメッセージよりも優
位であること）を意味する。MSS＿UNAVAILABLEが返された場合には、リモート環
境がシステム相互接続ともはや通信していないことを示す。ＳＵＣＣＥＳＳが返
された場合には、ダイアログがアクティブであり、この制御ダイアログによって
データが送受信され得ることを示す。それはまた、リモートユーザがアクティブ
でありMSS＿Endpoint＿Dialogがリモート環境によって生成され得ることも示す
。

【０１９０】

【数２２】

【０１９１】 MSS＿Deliver＿Dataは、MSS＿Endpoint＿Dialogによってデータメッセージを
送信する手順である。オプションSHARED＿BUFFERがセットされた場合、このバッ
ファは配送が完了するまでＭＳＳの所有物となる。さもなければ（プライベート
なものであれば）、ＭＳＳはバッファをＭＳＳ割当バッファにコピーして転送す
る必要がある。このオプションはデータのデータ部分だけに関するものであり、
ヘッダは常にＭＳＳ制御バッファにコピーされ、リモート環境に転送される。MS
S＿Deliver＿Dataに送られたオプションはダイアログ生成時に特定されたオプシ
ョンより優先順位が上である。OUT＿OF＿RESOURCESが呼出し側に返された場合に
は、これはこのダイアログに対する暗黙のNOT＿READYである。ダイアログが後に
利用可能になったときに、DIALOG＿CHANGE＿INDICATIONがこのダイアログに送信
されることとなる。この場合、このメッセージはリモートユーザには送信されて
いない。完了時に、ＭＳＳはALREADY＿COMPLETEDを返すか、または後のある時点
でDeliver＿Data＿Complete()を呼出すことによりこのことを示すこととなる。

【０１９２】

【数２３】

【０１９３】

【数２４】

【０１９４】 MSS＿Retrieve＿Data＿Msgは、ＭＳＳからのメッセージを取出すためにユーザ
によって呼出される手順である。このコマンドにはプライベート版しかない（デ
ータはユーザのバッファにコピーされる）。返信時に、ＭＳＳはユーザのポイン
タにコピーされたデータの長さを返す。ポインタはデータの始めにセットされる
（変化なし）。MESSAGE＿ORIENTEDがセットされ待ち行列の先頭におけるメッセ
ージのデータすべてがユーザのバッファに転送できなかった場合、データは切り
捨てられMESSAGE＿TRUNCATEDが返される。MSS＿Header＿Length=0である場合に
は、この手順はデータをコピーするだけでありヘッダは破棄されることとなる。
Max＿Data＿Length=0である場合には、この手順はヘッダをコピーするだけであ
り、データは後の呼出しに備えて保持されることとなる。Message＿Offset（こ
のダイアログの生成／オープンからのもの）は、データのコピーを希望するバッ
ファの場所へのポインタをユーザが渡すため、これは当てはまらない。ユーザは
message＿offsetに関するこのポインタを既に調節しているものとする。

【０１９５】

【数２５】

【０１９６】

【数２６】

【０１９７】

【数２７】

【０１９８】 MSS＿Receive＿Messageは、ＭＳＳパケットがシステムの相互接続からうまく
送られたときにシステムの相互接続に依存するモジュールによって呼出されるル
ーチンである。ＭＳＳパケットはＭＳＳユーザに配送されることとなる。システ
ムの相互接続は既にＩ／Ｏバッファを上述のMSS＿MESSAGE構造に変換している。
ＭＳＳパケットはＭＳＳによって所有されるようになる。このルーチンによって
もまた、内容に応じてメッセージの構造が変化し得る［データからのヘッダを取
出す］。

【０１９９】

【数２８】

【０２００】

【数２９】

【０２０１】 MSS＿Accept＿Data＿Completeは、データをうまく処理し終えたことを確認す
るためにＭＳＳユーザが呼出す手順である。バッファの所有がＭＳＳに返される
。バッファは例外なく返される。

【０２０２】

【数３０】

【０２０３】 MSS＿Event＿Handlerは、システムの相互接続に依存するモジュールが、ある
イベントがシステムの環境に起こったことをＭＳＳに知らせるために呼出すルー
チンである。

【０２０４】

【数３１】

【０２０５】 MSS＿Control＿Msg＿Handlerは、MSS＿Receive＿Message()が、ダイアログ管
理およびフロー制御プリミティブなどのＭＳＳ間制御情報を扱うために呼出すル
ーチンである。

【０２０６】

【数３２】

【０２０７】

【数３３】

【０２０８】

【数３４】

【０２０９】

【数３５】

【０２１０】 Ｋ．ＭＳＳダイアログ確立 上述のとおり、ＭＳＳは、上記関連出願に記載されている、ＱＳＰベースのＣ
ＮＰプラットフォームを介するインターフェイス、エミュレートされたインター
フェイス、またはＣＩＡインターフェイスを使用する。ＮＴ ＭＳＳインターフ
ェイスは、ＮＴ環境においてＭＳＳを実装するのに必要なすべてのＮＴ特有機能
に対する責任を負うＮＴサーバ１０２上にロードされたドライバである。これは
図６から図８に示される。一般的には、MSS-NTインターフェイスはＣＮＰ ＱＳ
Ｐ７６およびＬＤＭ８２と通信するのに必要な構造すべてを規定する必要がある
。それは上述のＭＣＰ ＭＳＳに対して相補的なアクションをとる。

【０２１１】 図２４（ａ）から図２４（ｆ）は、発明に従うＭＳＳダイアログ確立を示す。
図２４（ａ）に示されるように、ユーザのアプリケーションにより、ダイアログ
の生成が要求される。ステップ３００において、ＭＳＳユーザはこの要求をＭＳ
Ｓに送りダイアログを生成する。ステップ３０２において、ダイアログが生成さ
れ得るかどうかが決定され、これにはダイアログテーブルのエントリとＭＳＳ制
御ダイアログの利用可能性とが必要である。ステップ３０２においてダイアログ
の生成が不可能であると判断された場合、MSS＿ERRORメッセージが返される。し
かしながら、ステップ３０２でダイアログが生成できる場合には、ステップ３０
４においてダイアログテーブルのエントリを確保し、ローカルＩＤを割り当て、
ダイアログ状態をPENDING＿OPENに設定する。次に、ステップ３０６においてMSS
＿CREATE＿DIALOGメッセージがローカルＩＤでフォーマット化され、結果として
得られたメッセージがステップ３０８においてシステムの相互接続を介してリモ
ートＭＳＳに送信される。

【０２１２】 図２４（ｂ）に示されるように、ステップ３１０においてダイアログメッセー
ジがリモートＭＳＳに到達すると、ステップ３１２においてその有効性がチェッ
クされる。ダイアログメッセージがステップ３１２で信頼性に関するチェックに
合格しない場合、MSS＿ERRORパケットがステップ３１４において送信者に返信さ
れる。しかしながら、ダイアログメッセージに信頼性がある場合、ステップ３１
６において、ダイアログメッセージにMSS＿CREATE＿DIALOG要求が含まれるかど
うかが判断される。含まれない場合にはダイアログメッセージが他の場所で処理
される。しかしながらダイアログメッセージがMSS＿CREATE＿DIALOG要求である
場合にはローカルダイアログテーブルがステップ３１８でチェックされて、ＭＣ
Ｐ ＭＳＳ９２とMSS-NT９６との間でダイアログが生成され得るかどうかが判断
される。できない場合にはMSS＿ERRORパケットがステップ３２０において送信者
に返される。さもなければ、ＭＳＳはダイアログテーブルエントリを確保し、イ
ニシエータの（ダイアログメッセージからの）ローカルＩＤをストアし、ステッ
プ３２２において受信側のシステムのローカルＩＤによって応答メッセージをフ
ォーマット化する。その後ステップ３２４において応答メッセージが相互接続を
介してイニシエート側のシステムに返される。

【０２１３】 図２４（ｃ）に示されるように、ステップ３２６で応答メッセージが到着し、
その有効性がステップ３２８で評価される。応答メッセージが無効である場合に
はMSS＿ERRORパケットがステップ３３０で送信者に返信される。応答メッセージ
が有効である場合には、ステップ３３２において、応答メッセージがMSS＿CREAT
E＿RESPONSEメッセージであるかどうかが判断される。そうでなければメッセー
ジは他の場所で処理され、そうであればダイアログがリターンＩＤに基づいてス
テップ３３４で調べられ、要求されたダイアログが利用可能でありかつPENDING
＿OPEN状態であるかどうかが判断される。ダイアログが利用不可能であるか、ま
たは良好な状態でない場合、MSS＿ERRORパケットがステップ３３６で送信者に返
される。さもなければ、ローカルＩＤおよび情報がダイアログに与えられ、ＭＳ
Ｓは、ＭＳＳユーザがステップ３４０（図２４（ｄ））でダイアログのオープン
を要求するまで、ステップ３３８においてPENDING＿OPEN状態のまま維持される
。

【０２１４】 図２４（ｄ）に示されるように、ＭＳＳユーザがステップ３４０においてダイ
アログのオープンを要求すると、ステップ３４２においてメッセージのダイアロ
グが既に生成されているかどうかが判断される。そうでなければエラーコードが
返される。さもなければステップ３４４において、ダイアログが既にオープンさ
れているかどうかが判断される。そうであれば、要求されたダイアログが既にオ
ープンな状態であることを示すエラーコードがＭＳＳユーザに返される。さもな
ければ、ダイアログテーブルにおけるローカルおよびリモートＩＤがストアされ
、ステップ３４６でMSS＿OPEN＿DIALOGメッセージがフォーマット化され、ステ
ップ３４８で相互接続を介して送信される。

【０２１５】 図２４（ｅ）に示されるように、ステップ３５０でMSS＿OPEN＿DIALOGメッセ
ージが受信されると、その有効性がステップ３５２でチェックされ、無効である
場合にはMSS＿ERRORパケットがステップ３５４で送信者に返信される。MSS＿OPE
N＿DIALOGメッセージが有効である場合には、ステップ３５６において、MSS＿OP
EN＿DIALOGメッセージのＩＤがローカルダイアログテーブルのエントリと一致す
るかどうかが判断される。そうでなければステップ３５８でMSS＿ERRORパケット
が送信者に返される。さもなければＭＳＳの状態がステップ３６０で「ＯＰＥＮ
」にセットされ、ＭＳＳのユーザには、要求されたダイアログがオープンである
ことがステップ３６２で通知される。ステップ３６４でMSS＿OPEN＿RESPONSEメ
ッセージがフォーマット化され、ステップ３６６で相互接続を介して、近くに結
合された他のシステムに伝送される。

【０２１６】 図２４（ｆ）に示されるように、MSS＿OPEN＿RESPONSEメッセージがステップ
３６８で受信されると、その有効性がステップ３７０でチェックされ、無効であ
る場合にはMSS＿ERRORパケットがステップ３７２で送信者に返される。要求され
たダイアログがステップ３７４でダイアログテーブルに見られない場合には、ス
テップ３７６でMSS＿ERRORパケットが送信側に返される。さもなければダイアロ
グにはステップ３７８で「ＯＰＥＮ」とマークが付けられ、ＭＳＳユーザには、
要求されたダイアログがオープンであることがステップ３８０で通知される。Ｍ
ＳＳはこのときデータ転送ができる状態である。

【０２１７】 図２５（ａ）および図２５（ｂ）は、発明のＭＳＳダイアログを用いて相互接
続を介してＭＳＳユーザからデータを出力するための手順を示す。図２５（ａ）
に示されるように、ＭＳＳユーザはまず、ステップ４００でデータの伝送を要求
する。その後ステップ４０２で、要求されたダイアログが有効でありかつオープ
ンであるかどうかが判断される。そうでない場合にはエラーコードが返される。
さもなければ、ステップ４０４において、オープンされたダイアログが私用のも
のであるかまたは共有のデータバッファであるかどうかが判断される。データバ
ッファが私有のものである場合、ステップ４０６において、その制御ヘッダとと
もに伝送されることとなるデータのサイズを持つバッファが得られるかどうかが
判断される。そのようなバッファが利用可能でない場合、ＭＳＳユーザにリソー
スエラーが返される。さもなければ、ステップ４０８において、ユーザおよびＭ
ＳＳヘッダが、ユーザデータとともにプライベートデータバッファにフォーマッ
ト化される。その後、ステップ４１２で相互接続を介して１つのバッファを送信
する前に、ステップ４１０において適当なメッセージがダイアログの「進行中」
リストに付加される。一方、データバッファが共有のものである場合、ステップ
４１４において、制御ヘッダのサイズであるバッファが得られ得るかどうかが判
断される。そのようなバッファが利用可能でない場合、リソースエラーがＭＳＳ
ユーザに返される。さもなければ、ステップ４１６において制御ヘッダが共有デ
ータバッファにフォーマット化される。その後、ステップ４２０において相互接
続を介して制御データおよびユーザデータバッファを送信する前に、ステップ４
１８においてダイアログの「進行中」リストに適当なメッセージが付加される。

【０２１８】 データバッファが公共または私有のものであるかにかかわらず、ステップ４２
２（図２５（ｂ））においてＭＳＳには、送信／出力要求が完了したことが相互
接続を介して通知され、ユーザデータが送信されると、ステップ４２４において
ダイアログの進行中リストからデータバッファが除去される。その後、ステップ
４２６においてＭＳＳユーザには、そのバッファの送信がこれで完了したことが
通知される。

【０２１９】 図２６（ａ）および図２６（ｂ）は、発明のＭＳＳを用いて相互接続からＭＳ
Ｓユーザにデータを入力するための手順を示す。図２６（ａ）に示されるように
、ステップ５００でメッセージが相互接続からＭＣＰに到達すると、そのメッセ
ージにはステップ５０２で有効性のチェックが施される。メッセージが有効性の
チェックに合格しない場合、ステップ５０４でMSS＿ERRORパケットが送信者に戻
され、さもなければ、ステップ５０６において、入力データがダイアログに関す
るものであるか否かを判断する。そうでない場合にはデータは他の場所で処理さ
れる。データがMSS＿Endpoint＿Dialogに関するものである場合には、ステップ
５０８において、選択されたダイアログが自動配送をサポートするか否かが判断
される。そうでない場合、受信されたメッセージがステップ５１０でMSS＿Endpo
int＿Dialogダイアログの入来待ち行列に入れられ、ステップ５１２においてＭ
ＳＳユーザには、そのデータメッセージが待ち行列に入れられていることが通知
される。しかしながら、ダイアログが自動配送をサポートする場合、ＭＳＳユー
ザにはステップ５１４において、ダイアログに関する入力データがあることが通
知され、ＭＳＳユーザはデータメッセージを含む実データバッファを送っている
。ステップ５１６でＭＳＳユーザがデータバッファに対する処理を終えたと判断
されると、データバッファはステップ５１８で解放され、さもなければ、システ
ムは、ステップ５２０で、ＭＳＳユーザがデータバッファに対する処理を終え、
データバッファが解放され得る状態であることが示されるのを待機する。

【０２２０】 図２６（ｂ）は、入力データをユーザに与えるためにＭＳＳが行なう処理を示
す。ステップ５２２に示されるように、ユーザは、ＭＳＳが所定量のデータを、
ユーザの宛先アプリケーションがアクセス可能なデータバッファにコピーするこ
とを要求する。ステップ５２４においてMSS＿Endpoint＿Dialogが有効化され、
データが転送用待ち行列に入れられていることを確認する（図２６（ａ））。有
効化が失敗するとエラーコードが返され、さもなければステップ５２６において
、ユーザが要求したものと同量の最初に待ち行列に入れられたメッセージがユー
ザのデータバッファにコピーされる。ステップ５２８においてMSS＿Endpoint＿D
ialogメッセージが完全に検索されたと判断されると、ステップ５３０でメッセ
ージが待ち行列から外されて解放され、処理がステップ５３２で終わる。一方、
検索される入力データがまだある場合、ステップ５３４において、現在のメッセ
ージにおけるすべてのデータがコピーされているかどうかが判断される。そうで
あれば、ステップ５３６においてメッセージが待ち行列から外されて解放され、
処理がステップ５３８で終わる。しかしながら、コピーされることとなる入力メ
ッセージにまだデータがある場合、待ち行列から外されたデータはステップ５４
０で更新され、そのデータが検索されていないことを表わす。その後処理がステ
ップ５４２で終わる。

【０２２１】 図２７（ａ）から図２７（ｃ）は、発明に従って生成されたMSS＿Endpoint＿D
ialogのダイアログ終了処理を示す。図２７（ａ）に示されるように、終了処理
は、ＭＳＳユーザがＭＳＳがダイアログをクローズすることを要求したときにス
テップ６００で開始する。ステップ６０２において、クローズされるべきダイア
ログが存在しないかまたはオープンでないと判断された場合、エラーコードが返
され、さもなければ、クローズされるべきダイアログに関する待ち行列に入れら
れたデータがすべてステップ６０４で消去され、ＭＳＳの状態がステップ６０６
で「クローズ済み」に設定される。その後MSS＿CLOSE＿DIALOGメッセージがステ
ップ６０８でフォーマット化され、ステップ６１０で相互接続を介して送信され
る。MSS＿CLOSE＿DIALOGメッセージがステップ６１２（図２７（ｂ））で受信さ
れその有効性がステップ６１４でチェックされる。メッセージが無効である場合
、MSS＿ERRORパケットがステップ６１６で送信者に返され、さもなければステッ
プ６１８において、MSS＿CLOSE＿DIALOGメッセージにおいて特定されたダイアロ
グが存在しかつオープンな状態であるか否かが判断される。ダイアログが存在し
ないかまたはクローズされている場合には、MSS＿ERRORパケットがステップ６２
０で返される。ダイアログが存在しかつオープンである場合、ステップ６２２に
おいてＭＳＳの状態に「REMOTE＿CLOSED」というマークが付けられ、MSS＿CLOSE
＿RESPONSEメッセージがステップ６２４でフォーマット化され、ステップ６２６
で相互接続を介して送信される。

【０２２２】 さらに、図２７（ｃ）に示されるように、MSS＿CLOSE＿RESPONSEメッセージが
ステップ６２８で受信されると、その有効性がステップ６３０でチェックされ、
無効である場合にはMSS＿ERRORパケットがステップ６３２で送信者に返される。
要求されたダイアログがステップ６３４でダイアログテーブルに見付からない場
合には、MSS＿ERRORパケットがステップ６３６で送信者に返される。さもなけれ
ばダイアログテーブルのエントリがステップ６３８でクリーンアップされる。

【０２２３】 当業者には、発明のＭＳＳダイアログがトランスポートレイヤにおける多数の
ＭＳＳユーザによって利用され得ることが認められるであろう。しかしながら、
発明の好ましい実施例において、図に例示するように、ＭＳＳは、次章で説明す
るタイプのバーチャルトランスポートレイヤ（「ＶＴＬ」）プロトコルによって
呼出される。

【０２２４】 II．バーチャルトランスポートレイヤ（「ＶＴＬ」） 本章では、ＶＴＬの機能および動作を説明し、さらには、前章Ｉで詳述したユ
ーザおよびＭＳＳに対するその相互作用について説明する。ＶＴＬの説明は主に
３つの領域に分けて進めていく。すなわち、（１）ダイアログの確立、（２）デ
ータ転送、および（３）ダイアログの終了である。ＭＳＳとそのユーザとの間の
相互作用はすべて手順呼出しによって行なわれ、すなわち、ＭＳＳが上記ＭＳＳ
ユーザ手順を呼出し、この逆についても同じである。

【０２２５】 以下の説明から明らかとなるように、ＶＴＬは宛先に到達しリアセンブルされ
るためにはデータに付加される必要があるヘッダの量を最小限にする、信頼性の
高いコネクション指向トランスポートレイヤプロトコルを実装する。特に、ここ
で説明したメッセージ技術を採用して生成されるデータダイアログにより、各デ
ータブロックに対してアドレスデータを付与する必要性がなくなり、また、デー
タブロックをはるかに大きくできる。発明の技術の他の利点は以下の説明から明
らかとなるであろう。

【０２２６】 Ａ．ＶＴＬの初期化、リカバリおよび停止 VTL-NTおよびVTL-MCP環境は、他のいずれの環境からも独立して初期化、（正
規の態様での）停止または障害を発生する。しかしながら、プラットフォームに
よっては、すべてのアクションが独立することは不可能である。たとえば、エミ
ュレートされたプラットフォームでは、ＮＴ ＶＴＬコンポーネント９４に障害
が発生すると、必ずＭＣＰ ＶＴＬコンポーネント９０にも障害が発生する。な
ぜなら、ＮＴ ＶＴＬコンポーネント９４の障害はＮＴ環境全体の障害の原因と
なるからである。しかしながら、ＮＴ ＶＴＬコンポーネント９４はＮＴ初期化
／停止によって初期化および停止するだけであり、ＮＴ ＶＴＬコンポーネント
９４がＮＴ環境全体から独立して動作することはあり得ない。特に、ＮＴ ＶＴ
Ｌコンポーネント９４が終了し再初期化されると、必ずＮＴシステム１０２も再
初期化される。なぜなら、すべてのＴＣＰ／ＩＰダイアログはＮＴ ＶＴＬコン
ポーネント９４によって初期化されると仮定されており、したがってそれはＴＣ
Ｐ／ＩＰを用いるすべてのファイルを認識しているからである。これが当てはま
らずＮＴ ＶＴＬコンポーネント９４が未知のファイルに関する要求を受信する
場合、それは処理されない。ＮＴ ＴＣＰ／ＩＰ５８がＮＴの停止からは独立し
て終了する場合、ＮＴ ＶＴＬコンポーネント９４も終了することとなり、ＮＴ
の再起動なくして再初期化することはできない。

【０２２７】 １．初期化 ネットワークのアプリケーションに対してトランスペアレントであるためには
、ＶＴＬは何らかの適当なネットワーク化ＡＰＩ要求をインターセプトできるよ
うに配置される必要がある。明らかに、この機構はＶＴＬが存在する特定のシス
テム環境に依存する。好ましい実施例では、ＶＴＬ ＮＴ９４はＴＣＰＩＰ．Ｓ
ＹＳドライバ５８の上にフィルタドライバとしてそれ自体を挿入することにより
これを達成し、ＶＴＬ ＭＣＰ９０は、ＭＣＰ ＴＣＰ／ＩＰトランスポートプ
ロバイダ実装と密に結合されることによりこれを達成する。

【０２２８】 上述のとおり、リモート環境におけるそれに相当するものとの通信を確立し、
かつリモートＭＳＳユーザおよび環境の利用可能性についてそのローカルユーザ
に情報を与えることはＭＳＳの責任である。ＮＴ ＶＴＬコンポーネント９４の
利用可能性が知らされると、ＭＣＰ ＶＴＬコンポーネント９０はＮＴ ＶＴＬ
コンポーネント９４とのハンドシェイクを開始して、さらなる処理が起こるよう
にする責任を負う。それぞれのＶＴＬコンポーネント間のハンドシェイクにより
、２つのコンポーネント間の互換性が確認され、不可欠な初期化データの交換が
行なわれる。

【０２２９】 ２．リカバリ 「リカバリ」とは、リモート環境との通信が不意に失われた時に行なわれる処
理である。ＭＳＳはリモートＭＳＳユーザが利用できないことを検知し、このよ
うな事象を（User-Change-Notification手続きによって）ローカルＭＳＳユーザ
に知らせる責任を負う。この通知を受信すると、ＭＣＰ ＶＴＬコンポーネント
９０およびＮＴ ＶＴＬコンポーネント９４はリモート環境が失われたことに対
して適当な処理を行なう。特に、残ったＶＴＬコンポーネントは、利用できない
同位コンポーネント上のそれ自身との間のすべてのＶＴＬダイアログをクリーン
アップすることにより同位ＶＴＬコンポーネントが失われたことに対処する。こ
れには、十分に確立されたダイアログ、確立プロセスにあるダイアログ、および
終了プロセスにあるダイアログが含まれる。

【０２３０】 ３．停止（正規の） ＮＴ環境の停止時にはＭＣＰ ＶＴＬコンポーネント９０またはＮＴ ＶＴＬ
コンポーネント９４のいずれかによって行なわれる特別な処理はない。ＮＴ Ｖ
ＴＬコンポーネント９４はたとえば、それが停止することをＭＣＰ ＶＴＬコン
ポーネント９０に知らせない。その代わりに、所望の結果を達成するために他の
リカバリ処理に依存する。あるＶＴＬコンポーネントが停止すると、その同位の
コンポーネントには、適用可能な各ＭＳＳダイアログが利用できなくなくなった
ことが通知され、上記リカバリ処理が行なわれる。

【０２３１】 Ｂ．ＴＣＰダイアログ確立 本章では、いずれのタイプのオープン動作（受動的オープン対能動的オープン
）に基づくＶＴＬを使用するＴＣＰダイアログ確立が、発明の技術に従ってＶＴ
ＬによってＭＣＰ環境で開始されるかについて説明する。

【０２３２】 １．バーチャルトランスポート確立 図２８（ａ）は、発明に従うバーチャルトランスポートレイヤＴＣＰ確立を示
す。図２８（ａ）に示されるように、ステップ７００でＭＣＰまたはＮＴアプリ
ケーションがトランスポート接続を要求し、ステップ７０２において、要求が能
動的ＴＣＰオープンまたは受動的ＴＣＰオープントランスポート接続に関するも
のかが判断される。要求が受動的ＴＣＰオープンに関するものである場合、要求
はステップ７０４で受動的リストに記録され、ステップ７０６においてＴＣＰ／
ＩＰネットワークトランスポートプロバイダに転送される。一方、要求が能動的
ＴＣＰオープンに関するものである場合、ステップ７０８において要求が相互接
続を介して結合システム（すなわち図６から図８のＮＴサーバ１０２またはＡシ
リーズサーバ１００）に向けられるかどうかが判断される。そうでなければ、要
求はステップ７１０においてＴＣＰ／ＩＰネットワークトランスポートプロバイ
ダに転送される。しかしながら、要求が相互接続を介して結合システムに向けら
れる場合、ＭＳＳエンドポイントダイアログがステップ７１２で生成され、ステ
ップ７１４でオープン要求が相互接続を介して結合システムに発行される。その
後発行システムはステップ７１６においてオープン応答を待つ。ステップ７１８
において受信された応答がオープンがうまくいかなかったことを示す場合、ステ
ップ７２０で要求側アプリケーションに失敗が示され、さもなければオープンが
うまくいったことが要求側アプリケーションにステップ７２２で知らされる。結
合システムはこの場合、相互接続を介してオープン接続によって通信し得る。

【０２３３】 図２８（ｂ）はオープン要求を受信する結合システム側で行なわれるオープン
要求処理を示す。図示されるように、オープン要求はステップ７２４で結合シス
テムから受信され、ステップ７２６では、オープン要求が受信システムの受動的
リストエントリと一致するかどうかが判断される。そうでなければ、失敗を示す
応答がステップ７２８で返される。しかしながら、オープン要求が受動的リスト
エントリと一致する場合、ステップ７３０で受動的オープンが通常のネットワー
クトランスポートから取消され、ＭＳＳエンドポイントダイアログがステップ７
３２でオープンされる。オープン要求がうまく処理されたことを示す応答がステ
ップ７３４で戻され、ステップ７３６で要求側アプリケーションに「成功」表示
が返される。

【０２３４】 図２９は、発明に従うＭＣＰ環境受動的オープンの処理を示す。示されるよう
に、ＭＣＰ環境アプリケーションは既存のＡＰＩのうちの１つを介して受動的オ
ープンを要求することにより処理を開始する。図２８（ａ）のステップ７０４に
関して先に述べたとおり、この受動的オープン要求は後に使用できるようＭＣＰ
ＶＴＬ９０によって記録される。このシナリオでは、ＮＴ環境ＴＤＩクライア
ント９８は後に、ＭＣＰアプリケーションの受動的オープンと一致するDirected
Open（TDI-Connect）を要求する。その時点で、図２９に示されるように、ＮＴ
ＶＴＬコンポーネント９４はMSS＿Create＿Endpoint＿Dialogを呼出す。ＮＴ
ＶＴＬコンポーネント９４はその後オープン要求を（制御ダイアログを用いて
）ＭＣＰ ＶＴＬコンポーネント９０に送信する。ＭＣＰ ＶＴＬ９０は次いで
、ＭＳＳのOpen-Endpoint-DialogによってMSS＿Endpoint＿Dialogの側をオープ
ンする。その後ＭＳＳはＭＣＰ ＶＴＬコンポーネント９０およびＮＴ ＶＴＬ
コンポーネント９４にDialog-Change（Available）コマンドを発行する。ＭＣＰ
ＶＴＬコンポーネント９０はOpen-Response（Success）によってＮＴ ＶＴＬ
コンポーネント９４に応答し、OpenComplete（Success）をＭＣＰ環境アプリケ
ーションに発行する。Open-Response（Success）コマンドを受信すると、ＮＴ
ＶＴＬコンポーネント９４はTDI-Connect CompleteをＴＤＩクライアント９８に
発行し、オープン処理を完了する。

【０２３５】 図３０は、発明に従うＭＣＴ環境能動的オープンの処理を示す。示されるよう
に、ＡＰＩに依存する機構を除いては、このシナリオにおける処理はたった今述
べたＭＣＰ環境受動的オープンの場合と対称的である。

【０２３６】 ２．ＶＴＬデータ転送 背景知識として、ＬＩＯ／ポートインターフェイスといったユニシス独自のＡ
ＰＩモデルを使用するＭＣＰ環境アプリケーションへの入力については、アプリ
ケーション供給バッファにすべてのアプリケーションデータを入れておく必要が
あることに留意されたい。出力は、制御をアプリケーションに戻した後に参照で
きないアプリケーションにより供給されたバッファにおけるネットワーク化ソフ
トウェアに与えられる。好ましいＭＣＰ環境ＴＣＰ／ＩＰ実装例では、これには
、アプリケーションバッファとネットワーク化ソフトウェア制御バッファとの間
のすべての入出力アプリケーションメッセージをコピーする必要がある。さらに
、ユニシス独自のＡＰＩモデル協調型（Coop）サービスインターフェイスによっ
て与えられる重要な局面のうちの１つは、アプリケーションとネットワークトラ
ンスポートとの間のバッファの共有であることに留意すべきである。この機能に
より、上記タイプのＬＩＯ／ポートインターフェイスを用いる際に必要なデータ
コピーがいらなくなる。

【０２３７】 これもまた背景知識としてではあるが、ＴＤＩ出力はCoopインターフェイスと
同様に機能し、ＴＤＩクライアントによって供給されたバッファ領域は、ＴＤＩ
クライアント９８に出力（送信）動作が完了したことが通知されるまでトランス
ポートによって所有される。この完了の通知は、ＮＴトランスポートがＩ／Ｏ動
作を終えたときにＮＴ Ｉ／Ｏサブシステムからクライアント供給手順に、直接
呼出しにより行なわれる。ＴＤＩでは、ＴＣＰ入力が（ＴＤＩクライアント９８
の制御下で）下記の方法のいずれかによって行なわれ得る。

【０２３８】 １．ＴＤＩクライアント９８には、入力が利用可能であることが通知され得る
。この通知はＴＤＩプロバイダからＴＤＩクライアント９８への手順呼出しによ
って行なわれる。通知を受信すると、ＴＤＩクライアント９８は下記の動作のう
ち１つを行ない得る。すなわちａ）必要に応じて、コピーを含む、入力を受け入
れること、ｂ）その中にＴＤＩプロバイダが適量のデータをコピーするＴＤＩク
ライアントバッファをＴＤＩプロバイダに与えること、またはｃ）上記以外の動
作、である。ＴＤＩクライアントのアクションはリターンパラメータ値によって
示される。ＴＣＰデータについては、クライアントがアクションｃ）を示す場合
、ある時点で他の機構のうちの１つを呼出す必要がある。

【０２３９】 ２．ＴＤＩクライアント９８は非同期受信動作を呼出し、中にトランスポート
が入力データをコピーするバッファを提供し得る。ＴＤＩクライアント９８には
受信動作が完了したことが通知される。「非ブロック」受信動作はＴＤＩに規定
されるが、ＴＣＰ／ＩＰの実装は「非ブロック」セマンティクスをサポートする
ものとは思われない（すなわち、受信が呼出されたときにデータが存在しない場
合、適当な結果により受信を直ちに完了すること）。

【０２４０】 図３１は発明に従うＶＴＬデータ転送を示す。図３１の左側には出力が示され
、図３１の右側には入力が示される。簡単にするために、図３１ではＬＩＯ／ポ
ートＡＰＩの使用しか示していない。Coop APIを検討するにあたっては、ＭＳＳ
出力バッファ８０８として使用され得るアプリケーション出力バッファ８００の
共有と、Coopアプリケーションに直接送信され得るＭＳＳ入力バッファ８０６の
共有とを考慮する必要がある。

【０２４１】 図３１に示されるように、アプリケーション出力バッファ８００はCoopインタ
ーフェイスに対するＭＣＰ ＶＴＬコンポーネント９０に送られるバッファ、ま
たはＬＩＯ／バッファインターフェイス８０２からのバッファであり得るが、ア
プリケーション入力バッファ８０４は、アプリケーションの読出のためにＭＣＰ
ＶＴＬコンポーネント９０に与えられるバッファであり、かつＬＩＯ／ポート
インターフェイス８０２に対してのみ適用可能である。ＭＳＳ入力バッファ８０
６およびＭＳＳ出力バッファ８０８はＭＳＳによって所有および維持され、Coop
アプリケーションならびにＴＤＩクライアント９８のＴＤＩクライアント受信バ
ッファ８１２およびＴＤＩクライアント送信バッファ８１０を含む他のコンポー
ネントと機能を共有する。そのＮＴとＭＣＰ環境との間でメモリ空間を共有する
ことができるＭＳＳでは、ＭＳＳ内でのデータ移動は必要なく、入力／出力バッ
ファがＮＴおよびＭＣＰ環境間で共有され得る。これは共有が単方向である場合
にも可能である（たとえばＭＳＳ出力バッファ８０８は共有されるがＭＳＳ入力
バッファ８０６は共有されない）。バッファの共有が不可能であるかまたは非実
用的である場合、独特なＭＳＳ入力バッファ８０６およびＭＳＳ出力バッファ８
０８はＭＣＰおよびＮＴ環境の両方にあり、ＭＳＳが（その下位の相互接続を介
して）環境間のデータ移動を容易にする。ＭＳＳはデータの記憶に使用されるバ
ッファの管理責任を負うが、ＭＣＰ ＶＴＬコンポーネント９０およびＮＴ Ｖ
ＴＬコンポーネント９４は、フロー制御機能の責任を負い、他のコンポーネント
に対するデータ移動を管理する。

【０２４２】 図３２は、発明に従うＶＴＬデータ転送処理を示す。図３２に示されるように
、アプリケーションはステップ９００でＶＴＬデータ転送要求を開始し、ステッ
プ９０２でフロー制御が有効であるかどうか判断される。そうである場合システ
ムはステップ９０４でフロー制御からの解放を待つ。ステップ９０６においてＶ
ＴＬプロトコルヘッダが構築され、ステップ９０８でＭＳＳ配送データ要求が開
始する。ステップ９１０でAuto-Data-Deliveryがセットされたと判断されると、
受信システムはステップ９１２でAccept-Dataを呼出し、ステップ９１４でデー
タを適当なＡＰＩによって受信アプリケーションに配送して処理する。さもなけ
れば、Data＿Notificationがステップ９１６で呼出され、アプリケーションには
、適切なＡＰＩによってデータが配信されるべきことがステップ９１８において
通知される。その後ステップ９２０においてアプリケーション入力要求が受信さ
れ、ステップ９２２でMSS＿Retrieve＿Dataがイニシエートされる。その後デー
タがステップ９２４において呼出し側アプリケーションに返される。

【０２４３】 図３３は、ＭＣＰ環境からの出力データに関する通常のＶＴＬデータ転送処理
を示す。上部分にはＬＩＯ／ポートＡＰＩを用いるＭＣＰ環境出力が示され、下
部分にはCoopインターフェイスを使用する出力が示される。ＮＴ環境処理は使用
中のＭＣＰ環境ＡＰＩからは独立している。

【０２４４】 ＬＩＯ／ポートアプリケーション８０２については、ＭＣＰ ＶＴＬコンポー
ネント９０が長さ表示およびアプリケーション出力バッファ８００とともに呼出
され、Coopアプリケーションもまた長さ表示およびアプリケーション出力バッフ
ァ８００とともにＭＣＰ ＶＴＬコンポーネント９０を呼出し、バッファからＭ
ＣＰ ＶＴＬコンポーネント９０に所有権を移す。いずれの場合でも、ＭＣＰ
ＶＴＬコンポーネント９０はまずフロー制御条件をチェックする。フロー制御条
件のために出力が許可されない場合、要求はさらに処理されることなく拒絶され
る。フロー制御条件により出力が許可される場合、使用中のＡＰＩに依存する適
当な可変要素を用いて、Deliver-Data要求がＭＣＰ ＭＳＳ９２に発行される。
ＭＣＰ ＶＴＬコンポーネント９０はDeliver-Data要求におけるData-Transfer-
Headerを含む。Data-Transfer-Headerはデータを適切に処理するためにＮＴ Ｖ
ＴＬコンポーネント９４が必要とする情報を含む。ＭＣＰ ＭＳＳ９２がこの要
求を「リソースなし」条件で拒絶すると、アプリケーション要求はさらに処理さ
れることなく拒絶される。さもなければ（ＭＣＰ ＭＳＳ９２がリクエストを拒
絶しない場合）、Deliver-Data要求はＭＳＳ実装に依存した態様で完了する。sh
ared-buffer可変要素が要求された場合、ＭＣＰ ＭＳＳ９２は適当な時間にDel
iver-Data-Complete通知をＭＣＰ ＶＴＬコンポーネント９０に与える。Delive
r-Data-Completeを受信すると、ＭＣＰ ＶＴＬコンポーネント９０は出力バッ
ファ８００の所有権をCoopアプリケーションに返す。

【０２４５】 ＭＣＰ環境からのDeliver-Data要求を処理した結果、ＮＴ ＭＳＳ９６は１つ
または２つ以上のAccept-Data要求をＮＴ ＶＴＬコンポーネント９４に発行す
る。Accept-Data要求の数は元のデータの受信に要するバッファＭＳＳ９６の数
に依存する。各Accept-Data要求には、後に説明するが、ＮＴ ＶＴＬコンポー
ネント９４からの対応のAccept-Data-Complete通知が必要である。

【０２４６】 Accept-Data要求の処理を行なうＮＴ ＶＴＬコンポーネント９４は、同位Ｔ
ＤＩクライアントの要求動作および過去のData-Transfer要求の状態に依存する
。この説明では、ＴＤＩクライアント９８にはこれまでに拒絶されたデータはな
く、ＴＤＩ受信イベント通知を要求しており、これらのイベント通知に応答して
ＴＤＩ受信要求を返すものとする。このシナリオにおいて、ＮＴ ＶＴＬコンポ
ーネント９４は、Accept＿Data動作の全内容を示すネイティブＴＤＩクライアン
トの受信イベントハンドラーを呼出す。ＴＤＩクライアント９８は（定義上）示
されるすべてのデータの受信に適するＴＤＩ受信要求を返す。ＴＤＩ受信の処理
時に、ＮＴ ＶＴＬコンポーネント９４はデータの内容をＴＤＩクライアント９
８によって供給されたバッファにコピーし、ローカルＴＤＩクライアントの完了
ルーチンを（対応のＩ／Ｏサブシステム要求を完了させることにより）呼出し、
ＭＳＳのAccept＿Data＿Completeルーチンを呼出す。Accept-Data-Complete通知
を受信すると、ＮＴ ＭＳＳ９６はバッファのリサイクルを含む、実装に依存し
たアクションを行なう。

【０２４７】 図３４ではＶＴＬデータ入力をフロー図で要約する。上部分にはＬＩＯ／ポー
トＡＰＩ８０２を用いるＭＣＰ環境入力が示され、下部分にはCoopインターフェ
イスを用いる入力が示される。ＮＴ環境処理は使用中のＭＣＰ環境ＡＰＩからは
独立する。

【０２４８】 図３４に示されるように、ＭＣＰ環境入力は同位ＴＤＩクライアントによって
開始されるＴＤＩ送信動作から始まる。ＴＤＩ送信セマンティクスは、ＴＤＩプ
ロバイダ（ＮＴ ＶＴＬコンポーネント９４）が、ＴＤＩ送信が完了したことを
ＴＤＩクライアント９８に示すまで、アプリケーション出力バッファ８１０を所
有するようなものである。ＮＴ ＶＴＬコンポーネント９４はアプリケーション
出力バッファ８１０の所有者であるため、shared-buffer Deliver-Data要求がNT
-MSS９６に発行される。この場合、NT-MSS９６は後のある時点でDeliver-Data-C
omplete通知を配送し、この時点でＮＴ ＶＴＬコンポーネント９４はＴＤＩク
ライアント９８に、ＴＤＩ送信動作の完了を通知する。

【０２４９】 ＮＴ環境からのDeliver-Data要求を処理した結果、ＭＣＰ ＭＳＳ９２は、元
のデータを受信するのに要求されるバッファＭＳＳ９６の数に依存する１つまた
はそれ以上のAccept-DataまたはData-NotificationsをＭＣＰ ＶＴＬコンポー
ネント９０に発行する。

【０２５０】 ＭＳＳ９６からのData-Notificationsを処理した結果、ＬＩＯ／ポートにInpu
t-Notificationが発行されることとなる。ＬＩＯ／ポートの処理については、ア
プリケーションが対応の読出を行なう（またはＬＩＯ／ポートが待機読出を行な
う）ときに入力が続く。データが存在するときにアプリケーション読出が行われ
ると、ＬＩＯ／ポートによってＭＣＰ ＶＴＬ９０にRetrieve-Data要求が発行
される。このRetrieve-Data要求はユーザバッファおよび長さの表示を含み、結
果として、対応のprivate-buffer Retrieve-Data要求がＭＣＰ ＭＳＳ９２に発
行される。ＭＣＰ ＭＳＳ９２は待ち行列に入れられた適量の入力データをアプ
リケーションの入力バッファ８０４にコピーし、ＭＣＰ ＶＴＬコンポーネント
９０にリターンする。ＭＣＰ ＶＴＬコンポーネント９０はそれ自体の完了処理
を行ないＬＩＯ／ポートにリターンする。

【０２５１】 Accept-Data要求を受信すると、ＭＣＰ ＶＴＬコンポーネント９０はData-In
dicationを介して入力データをCoopアプリケーションに転送する。Coopアプリケ
ーションは後のある時点でＭＣＰ ＶＴＬコンポーネント９０を呼出しバッファ
の所有権を返す。ＭＣＰ ＶＴＬコンポーネント９０はAccept-Data動作が完了
したことをＭＣＰ ＭＳＳ９２に通知する。

【０２５２】 ３．正規のＴＣＰダイアログ終了 図３５（ａ）は、発明に従うバーチャルトランスポートレイヤ接続の終了を示
す。示されるように、アプリケーションは、ステップ９００において切断を要求
し、ステップ９０２でＭＳＳエンドポイントダイアログの結合システムにクロー
ズ要求を発行する。ステップ９０４において、要求側アプリケーションはクロー
ズ応答および結合システムからのクローズ要求の受信を待機する。クローズ応答
およびクローズ要求の受信時に、ステップ９０６でＭＳＳエンドポイントダイア
ログはクローズされ、クローズの完了がステップ９０８で要求側アプリケーショ
ンに示される。

【０２５３】 図３５（ｂ）はクローズ要求を受信するシステムによって行なわれるクローズ
要求処理を示す。示されるように、クローズ要求がステップ９１０で受信され、
対応のアプリケーションには相互接続用の適当なＡＰＩによってステップ９１２
で通知される。クローズ要求の受信がステップ９１４で記録され、クローズ応答
がステップ９１６で要求側アプリケーションに発行される。ＶＴＬ接続がその後
クローズされる。

【０２５４】 ＭＣＰ環境が開始する、正規のダイアログ終了の通常処理が図３６に示される
。ＡＰＩに依存する機構は例外として、終了処理がＮＴ環境によって開始される
場合の処理は対称的である。図３６に示されるように、ＭＣＰ環境アプリケーシ
ョンは既存のＡＰＩのうちの１つによって正規のクローズ動作を行なうことによ
り処理を開始する。ＭＣＰ ＶＴＬコンポーネント９０はトランスポート接続の
状態をClose＿Requestedに移行させ、クローズ（正規）要求をＮＴ ＶＴＬコン
ポーネント９４に発行する。クローズ要求はこのトランスポート接続に対応する
MSS＿Endpoint＿Dialogに発行され、現在のすべての出力が、クローズ要求の受
信に先立ってＮＴ ＶＴＬコンポーネント９４によって確実に受信されるように
しなければならない。ネットワーク化ＡＰＩの通常のセマンティクスによると、
ＭＣＰ環境アプリケーションは出力動作を行なうことはできず、受信された入力
はすべて、入力動作を引続き行なうことができるアプリケーションに配送されね
ばならない。クローズ要求の処理時に、ＮＴ ＶＴＬコンポーネント９４はＴＤ
Ｉクライアント９８にTDI-Disconnect-Eventを与え、これは通常のネットワーク
化ＡＰＩ定義にしたがって、リモートアプリケーションが規則正しいダイアログ
終了を要求したことをＴＤＩクライアント９８に通知する。ＮＴ ＶＴＬコンポ
ーネント９４はその後Close-ResponseをＭＣＰ ＶＴＬコンポーネント９０に発
行する。Close-Responseは、ＮＴ環境から発せられるデータと同じシーケンスで
ある必要はないため、ＭＳＳ Control-Dialogに発行される。Close-Responseの
処理時に、ＭＣＰ ＶＴＬコンポーネント９０は、Close-Responseが後に使用で
きるよう受信されたことを記録するだけである。通常のネットワークアプリケー
ション動作にしたがい、ＴＤＩクライアント９８は正規のダイアログ終了(TDI-D
isconnect)に関する対応の要求を発する。通常のネットワーク化ＡＰＩセマンテ
ィクスににしたがい、ＴＤＩクライアント９８はダイアログ終了の要求に先立っ
てさらなる出力動作を行ない得る。

【０２５５】 ＮＴ ＶＴＬコンポーネント９４は、規則正しい終了要求の処理時に、クロー
ズ（規則正しい）要求をＭＣＰ ＶＴＬコンポーネント９０に発行する。ＭＣＰ
ＶＴＬコンポーネントのClose-Requestの場合と同様に、このClose-Requestも
また、トランスポート接続に対応するＭＳＳ Endpoint-Dialogに対して発行され
る必要がある。Close-Requestの処理時に、ＭＣＰ ＶＴＬコンポーネント９０
はトランスポート接続の状態をＣＬＯＳＥＤに移行させ（したがってＭＣＰアプ
リケーションの終了要求を完了させ）、Close-ResponseをＮＴ ＶＴＬコンポー
ネント９４に発行する。ＭＣＰ ＶＹＴＬコンポーネント９０はその後、ＭＳＳ
を呼出し、このトランスポート接続に対応するMSS＿Endpoint＿Dialogの側をク
ローズする。

【０２５６】 ＭＣＰ ＶＴＬコンポーネント９０からのClose-Responseの処理時に、ＮＴ
ＶＴＬコンポーネント９４はＴＤＩクライアント９８に、その終了要求がうまく
完了したこと（TDI-Disconnect-Complete)を通知し、ＭＳＳを呼出して対応のEn
dpoint-Dialogをクローズする。各ＶＴＬコンポーネントには、MSS＿Endpoint＿D
ialogがクローズされたときに個別に通知が行なわれる。この通知により、リソ
ースの解放を含む最終的な処理がトリガされる。実際のタイミングに応じて、ロ
ーカル側がクローズを要求する前にリモート側によってMSS＿Endpoint＿Dialog
がクローズされたことをＭＳＳはＶＴＬコンポーネントに知らせる。

【０２５７】 上で説明を簡単にするために考慮にいれなかったことは、正規のダイアログ終
了時に生じるデータの流れである。フロー制御により、アプリケーションが正規
の終了を要求する際に出力データが処理中である場合がある。終了要求のセマン
ティクスによると、このデータは、終了プロセスの完了前に適切に配送されねば
ならない。同様に、入力データもClose-Requestの受信時に処理中である場合が
ある。通常のネットワーク化ＡＰＩにより、正規のダイアログ終了が進行中であ
るときにアプリケーションがこのデータを取出すことができるようになる。何ら
かのＶＴＬ実装により、これらのシナリオを適切に取扱う必要がある。

【０２５８】 ４．異常ＴＣＰダイアログ終了 ＮＴ環境によって開始するダイアログ異常終了の通常の処理が図３７に示され
る。ＡＰＩに依存する機構は例外として、終了がＭＣＰ環境によって開始する処
理は対称的である。図３７に示されるように、ＮＴ環境アプリケーションは、ダ
イアログ異常終了（Abortiveオプションを特定するTDI-Disconnect）を要求する
ことにより処理を開始する。この要求を処理する際、ＮＴ ＶＴＬコンポーネン
ト９４はClose-Request(Abortive)をＭＣＰ ＶＴＬコンポーネント９０に発行
する。このクローズ要求はＭＳＳ制御ダイアログに対して発行される。なぜなら
、（上述の正規の終了とは異なり）ダイアログ異常終了に関する通常のネットワ
ーク化ＡＰＩセマンティクスは、先のデータ転送要求を確実に完了しないからで
ある。ＮＴ ＶＴＬコンポーネント９４はまた、アプリケーションの要求(TDI-D
isconnect-Complete)を直ちに完了する。Close-Requestの処理時に、ＭＣＰ Ｖ
ＴＬコンポーネント９０はトランスポート接続の状態をDeactivation-Pendingに
移行させ、これは通常のネットワーク化ＡＰＩ定義によると、トランスポートダ
イアログが利用できないことをＭＣＰアプリケーションに知らせる。ＭＣＰ Ｖ
ＴＬコンポーネント９０はClose-ResponseをＮＴ ＶＴＬコンポーネント９４に
発行し、ＭＳＳを呼出してこのトランスポート接続に対応するMSS＿Endpoint＿D
ialogの側をクローズする。Close-Responseの処理時に、ＮＴ ＶＴＬコンポー
ネント９４はＭＳＳを呼出して、このトランスポート接続に対応するMSS＿Endpo
int＿Dialogの側をクローズする。各ＶＴＬコンポーネントには、MSS＿Endpoint
＿Dialogがクローズされたことが個別に通知される。この通知により、リソース
の解放を含む最終的な処理がトリガされる。実際のタイミングに応じて、ＭＳＳ
は、MSS＿Endpoint＿Dialogがローカル側がクローズを要求するのに先立ってリ
モート側によってクローズされたことをＶＴＬコンポーネントに知らせる。

【０２５９】 上では説明を簡単にするために下記のいくつかの重要な事項が記載されておら
ず、すべてのＶＴＬ実装例はこれらのシナリオを適切に取扱うべきである。

【０２６０】 （１） 処理中のデータフロー：正規の終了に関して述べたとおり、ダイアロ
グ異常終了が開始するときにデータが処理中であるかもしれない。しかしながら
、正規の終了とは異なり、処理中のデータはダイアログ異常終了の一部として破
棄されてもよい。

【０２６１】 （２） 部分的に確立されたダイアログ：異常終了はダイアログ確立時の任意
の時点で開始してもよい。さらに （３） 正規の終了のオーバーライド：異常終了は規則正しいダイアログ終了
のいかなる時点で開始してもよい。

【０２６２】 Ｃ．ＶＴＬプロトコル ユニシスのClearPath HMP NXエンタープライズサーバについて上で説明した発
明の好ましい実施例では、ＶＴＬプロトコルがＭＣＰコンポーネントの性能を最
適化するよう設計される（ＮＴコンポーネントの性能は劣化するかもしれない）
。このために、フィールドコンテナのサイズとアライメントとは、ＭＣＰ環境の
操作上好ましいものとなるよう選択される。

【０２６３】 １．共通ＶＴＬデータ構造 本章ではＶＴＬプロトコルに使用されるデータ構造を説明する。

【０２６４】 String−Structure 文字列は下記のフォーマットで送信される。

【０２６５】 フィールド：String-Length データ型：符号なし整数 長さ：２バイト 説明：後続するString−Valueフィールドのバイト数を特定する フィールド：String-Value データ型：文字の配列 長さ：String-Lengthフィールドによって特定される 説明：文字列の値IP-Address-Structure ＩＰアドレスがフォーマット化されるＩＰバージョンは下記のとおりである。

【０２６６】 フィールド：IP-Version データ型：符号なし整数 長さ：１バイト 説明：このＩＰアドレスがフォーマット化されたIP-Versionを特定する フィールド：Pad データ型：使用せず 長さ：１バイト 説明：このフィールドは、このデータ構造のＭＣＰ環境の解釈に好適なフィー
ルドのバイト配列を維持するために使用される。

【０２６７】 フィールド：IP-Address データ型：１バイト、符号なし整数の配列 長さ：IP-Versionが４である場合、長さは４バイト 説明：ＩＰアドレス ２．ＶＴＬコントロールメッセージインターフェイス すべての制御メッセージは、その始まりの部分に下記のヘッダを含む。

【０２６８】 ＶＴＬ制御メッセージヘッダ フィールド：Interface-Level データ型：符号なし整数 長さ：２バイト 説明：このメッセージが含むインターフェイスレベルを特定する。

【０２６９】 フィールド：Message-Class データ型：符号なし整数 長さ：２バイト 値：REQUEST=1; RESPONSE=2; NOTIFICATION=3 説明：このメッセージに関するクラスを特定する。ＲＥＱＵＥＳＴにはアクシ
ョンに関するリクエストが含まれる。ＲＥＳＰＯＮＳＥはＲＥＱＵＥＳＴの処理
の完了結果である。ＮＯＴＩＦＩＣＡＴＩＯＮにより、求めていない情報が与え
られる。

【０２７０】 フィールド：Message-Type データ型：符号なし整数 長さ：２バイト 値：要求／応答について：HANDSHAKE; OPEN-CONNECTION;CLOSE-CONNECTION; O
PEN-CONNEVTION-ABORT 通知について： 説明：クラスによりメッセージの型を特定し、一意の識別をすべてのメッセー
ジに付与する。ＲＥＱＵＥＳＴに対するＲＥＳＰＯＮＳＥには対応の要求と同じ
Message-Typeが含まれる。

【０２７１】 フィールド：Message-Length データ型：符号なし整数 長さ：６バイト 説明：このメッセージ（ヘッダを含む）のバイトで表わした長さ フィールド：Request-Reference データ型：符号なし整数 長さ：６バイト 説明：要求では、対応の応答で返信されることとなる、要求者が特定した値。
その値は、要求者を除くすべてのモジュールに対して完全にトランスペアレント
である。通知では、その値は無関係であるが、すべて０に設定される必要がある
。

【０２７２】 フィールド：Requester-Connection-Reference データ型：符号なし整数 長さ：６バイト 説明：個々の接続に使用可能なメッセージでは、このフィールドには、その接
続に関する要求者が割当てた基準値が含まれる。要求側ＶＴＬコンポーネントは
、応答側ＶＴＬコンポーネントに、そのOPEN-CONNECTION要求におけるこの値を
与える。メッセージが特定の接続に使用されない場合にはその値はすべて０でな
ければならない。

【０２７３】 フィールド：Responder-Connection-Reference データ型：符号なし整数 長さ：６バイト 説明：個々の接続に使用可能なメッセージでは、このフィールドには、その接
続に関する応答者が割当てた基準値が含まれる。応答側ＶＴＬコンポーネントは
、そのOPEN-CONNECTION応答におけるこの値を、要求側ＶＴＬコンポーネントに
与える。メッセージが特定の接続に使用されない場合、その値はすべて０でなけ
ればならない。また、OPEN-CONNECTIONおよびOPEN-CONNECTION-ABORT要求の両方
において、その値は０でなければならない。なぜなら、要求側ＶＴＬコンポーネ
ントはこの時点では応答者が割当てた値を認識していないからである。

【０２７４】 フィールド：Status データ型：符号なし整数 長さ：４バイト 説明：応答メッセージでは、要求された動作に関する応答／エラーコードを与
える。他のすべてのメッセージクラスに関しては、この値はすべて０でなければ
ならない。

【０２７５】 フィールド：Pad データ型：使用せず 長さ：２バイト 説明：このフィールドは、このヘッダに後続するフィールドのＭＣＰ環境解釈
に好適なフィールドのバイト配列を維持するために使用される。

【０２７６】 Close-Connection要求／応答 この要求はＶＴＬ接続をクローズ（無効化）するために発行される。クローズ
要求およびそれらの結果として生じた応答は例外なくMSS＿Endpoint＿Dialogsに
対して発行される。制御メッセージヘッダの他に、この要求は下記のフィールド
を含む。

【０２７７】 フィールド：Close-Type データ型：符号なし整数 長さ：１バイト 値：ＯＲＤＥＲＬＹ；ＡＢＯＲＴＩＶＥ 説明：正規のまたは異常クローズを行なうべきか否かを決める。

【０２７８】 下記の状態コードのうちいずれかが返されることとなる：STATUS-SUCCESSは要
求がうまく完了したことを示す；STATUS-ALREADY-CLOSEDは対象の接続が既にク
ローズされていることを示す；STATUS-ALREADY-CLOSINGはこのタイプ（正規の／
異常）のクローズ動作が既に開始しているか、または異常クローズが既に進行中
であるときに正規のクローズが要求されたことを示す。これらの応答のうちのい
ずれにも制御メッセージヘッダ以外のフィールドはない。

【０２７９】 ハンドシェイク要求／応答 この要求はＮＴ ＶＴＬコンポーネント９４との通信を初期化するためにＭＣ
Ｐ ＶＴＬコンポーネント９０によって発行される。制御メッセージヘッダの他
に、この要求は下記のフィールドを含む。

【０２８０】 フィールド：MCP-VLAN-IP-Address データ型：IP-Address-Structure 説明：このフィールドは、対象のＮＴ環境に対応するＭＣＰ環境のＶＬＡＮ
ＩＰアドレスをＮＴ ＶＴＬコンポーネント９４に与えるためにＭＣＰ ＶＴＬ
コンポーネント９０によって使用される。

【０２８１】 フィールド：ＭＣＰ ＶＴＬ Ｖersion データ型：String-Structure 説明：ＶＴＬコンポーネントのバージョン（たとえばソフトウェアレベル）を
特定する列。この値は診断目的としてのみ使用される。下記の状態コードのうち
のいずれかが返され得る：STATUS-SUCCESSはハンドシェイク要求がうまくいった
ことを示し、STATUS-INCOMPATIBLE-INTERFACE-LEVELはＮＴ ＶＴＬコンポーネ
ント９４が、所定のインターフェイスレベルを理解しないことを示す。STATUS-S
UCCESSが返される場合、下記のフィールドが制御メッセージヘッダの後に存在す
る。

【０２８２】 フィールド：NT-VLAN-IP-Address データ型：IP-Address-Structure 説明：このフィールドは、ＭＣＰ ＶＴＬコンポーネント９０にＮＴ環境のＶ
ＬＡＮ ＩＰアドレスを与えるためにＮＴ ＶＴＬコンポーネント９４によって
使用される。

【０２８３】 フィールド：ＮＴ ＶＴＬ Ｖersion データ型：String Structure 説明：ＮＴ ＶＴＬコンポーネント９４のバージョン（たとえばソフトウェア
レベル）を特定する列。この値は診断目的のためにのみ使用される。

【０２８４】 STATUS-INCOMPATIBLE-INTERFACE-LEVELが返される場合、制御メッセージのヘ
ッダの後には下記のフィールドが存在する。

【０２８５】 フィールド：Supported-Interface-Level データ型：符号なし整数 長さ：２バイト 値：応答者によってサポートされる要求者の所定のインターフェイスレベルよ
りも低い最高インターフェイスレベルを示す。ＭＣＰ ＶＴＬコンポーネント９
０はそのインターフェイスレベル以下で別のハンドシェイクを試みることができ
る。

【０２８６】 Open-Connection要求／応答 この要求は、ＶＴＬ接続を生成しオープンするために発行される。制御メッセ
ージヘッダに加えて、この要求は下記のフィールドを含む。

【０２８７】 フィールド：Pad データ型：使用せず 長さ：１バイト 説明：このフィールドは、このデータ構造のフィールドのＭＣＰ環境解釈に好
適なフィールドのバイト配列を維持するために使用される。１つまたは２つ以上
のパッドフィールドが含まれ得る。

【０２８８】 フィールド：Local-Port-Number データ型：符号なし整数 長さ：２バイト 説明：この接続のために使用されることとなるローカルポート番号を特定する
。すべての場合において、０の値が許可され、オープン動作の完了により、ロー
カルポート番号が選択される。

【０２８９】 フィールド：Remote-Port-Number データ型：符号なし整数 長さ：２バイト 説明：この接続のために使用され得るリモートポート番号を特定する。

【０２９０】 フィールド：Receive-Credit-Limit データ型：符号なし整数 長さ：４バイト 説明：応答者が最初に利用できる受信クレジット数。

【０２９１】 フィールド：My-MSS-Dialog-Id データ型：MSS-Dialog-Id 説明：接続とともに使用され得るEndpoint-Dialogに関する要求者のＭＳＳダ
イアログidを特定する。

【０２９２】 フィールド：Local-IP-Address データ型：IP-Address-Structure 説明：この接続のために使用され得るローカルＩＰアドレスを特定する。０の
値が許可され、オープン動作の完了により、ローカルＩＰアドレスが選択される
。

【０２９３】 フィールド：Remote-IP-Address データ型：IP-Address-Structure 説明：接続されるリモートシステムを特定する（これは常に応答者のＶＬＡＮ
ＩＰアドレスとなる）。

【０２９４】 下記の状態コードのうちのいずれかが返され得る：STATUS-SUCCESSは要求がう
まく完了したことを示す；STATUS-INSUFFICIENT-VTL-RESOURCESは、この要求を
完了するのに要するリソースをＶＴＬが、確保できなかったことを示す；STATUS
-INSUFFICIENT-RESOURCESは、何らかの下位のシステムコンポーネントがこの要
求を完了するのに要するリソースを確保できなかったことを示す；STATUS-CONNE
CTION-REFUSEDはトランスポート接続の試みがリモートシステムによって拒否さ
れたことを示す；STATUS-NETWORK-UNREACHABLEはリモートネットワークがトラン
スポートによって到達できないことを示す；STATUS-HOST-UNREACHABLEはリモー
トシステムがトランスポートによって到達できないことを示す。

【０２９５】 STATUS-SUCCESSが返される場合、制御メッセージヘッダ（他の応答のうちデー
タフィールドを含むものはない。）の後には下記のフィールドある。

【０２９６】 フィールド：Local-Port-Number データ型：符号なし整数 長さ：２バイト 説明：この接続に関するローカルポート番号を示す。

【０２９７】 フィールド：Remote-Port-Number データ型：符号なし整数 長さ：２バイト 説明：この接続に関するリモートポート番号を示す。

【０２９８】 フィールド：Pad データ型：使用せず 長さ：２バイト 説明：このフィールドはこのデータ構造におけるフィールドのＭＣＰ環境解釈
に好適なフィールドのバイトアライメントを維持するために使用される。１つま
たは２つ以上のパッドフィールドが存在し得る。

【０２９９】 フィールド：Send-Credit-Limit データ型：符号なし整数 長さ：４バイト 説明：要求者が最初に利用できる送信クレジット数。

【０３００】 フィールド：Local-IP-Address データ型：IP-Address-Structure 説明：この接続に関するローカルＩＰアドレスを示す。

【０３０１】 フィールド：Remote-IP-Address データ型：IP-Address-Structure 説明：この接続に関するリモートＩＰアドレスを示す。

【０３０２】 Open-Connection-Abort要求／応答 この要求は、進行中のOpen-Connection動作をアボートするために使用される
。Open-Connection動作は応答環境においては完了済みであるかもしれないが、
要求環境においてはまだ反映されないことに留意されたい。

【０３０３】 要求では、データフィールドはない（制御メッセージヘッダ以外）。要求がう
まく完了したことを示すSTATUS-SUCCESSだけが返されるだろう。STATUS-SUCCESS
が返される場合、制御メッセージヘッダの後には下記のフィールドがある。

【０３０４】 フィールド：Open-Completed データ型：ＢＯＯＬＥＡＮ 長さ：１バイト 値：０（＝＞ＦＡＬＳＥ） １（＝＞ＴＲＵＥ） 説明：応答者の環境において元のOpen-Connectionが完了したかどうかを示す
。

【０３０５】 ３．データ転送インターフェイス ＶＴＬコンポーネント間のデータ転送にはすべてデータ転送ヘッダが含まれる
。ＭＳＳが複数断片でのデータ転送を完了する場合、データ転送ヘッダは最初の
断片にしか含まれない。データ転送に関するデータ転送ヘッダには下記のフィー
ルドが含まれる。

【０３０６】 フィールド：Interface-Level データ型：符号なし整数 長さ：２バイト 説明：このメッセージが含むインターフェイスレベルを特定する。

【０３０７】 フィールド：Credited-Adjustment データ型：符号付き整数 長さ：４バイト 説明：ピギーバッククレジットの付与または低減を示す。符号（１が負）には
最上位ビットが使用され、残りのビットは付与／低減されたクレジットを示す。
この値は０であろう。

【０３０８】 フィールド：Sequence-Number データ型：符号なし整数 長さ：４バイト 説明：このデータ転送動作のシーケンス番号−各データ転送動作には、１から
始まり必要に応じてラップアラウンドされる番号が順次付与される。

【０３０９】 フィールド：Data-Flags データ型：ビットマスク 長さ：２バイト 説明：以下に規定する個々のフラグを含む。

【０３１０】 ENTIRE-MESSAGE−ＰＵＳＨフラグの使用へのマッピング。 URGENT-DATA−このデータ転送に緊急のデータが含まれることを示す。

【０３１１】 当業者には、本発明が各システムの１つのネットワークプロトコルプロバイダ
だけで使用されることに限定されないことが認められるであろう。本発明は各シ
ステム上の多数のネットワークプロトコルプロバイダに対するデータ転送に使用
され得る。さらに当業者には、本発明が２つまたはそれ以上のエンドポイントを
有する相互接続を介する通信を提供することに意図されることが認められるであ
ろう。たとえば、相互接続はＬＡＮ、または従来からのネットワークプロトコル
からは独立したいくつかの密に結合されたコンピュータシステムを接続する複数
の相互接続といったネットワークであってもよい。

【０３１２】 また、発明の広い概念から逸脱することなく上記実施例に変更が施され得るこ
とを理解されたい。たとえば、本発明はＡシリーズサーバおよびＮＴサーバを含
むシステムの場合として説明したが、本発明の方法および装置は同一または異な
ったタイプの密に結合されたいかなるコンピュータシステムに採用されてもよい
ことを理解されたい。さらに、本発明の相互接続は開示した特定の実施例に限定
されない。「相互接続」という用語は第１および第２のコンピュータシステムの
Ｉ／Ｏサブシステム間でデータ転送を行なうための他の方法および装置も包含す
ることが意図される。たとえば、他の実施例ではＱＳＰおよびＬＡＮＳＧコンポ
ーネントの機能が要求されないかもしれない。相互接続装置ドライバ（ＩＣＤ）
、ＭＳＳおよびＶＴＬ間にはより直接的なインターフェイスが採用されてもよい
。したがって、本発明は開示した特定的な実施例に限定されるのではなく、前掲
の特許請求の範囲によって規定される発明の精神および範囲内に入るすべての変
形をカバーすることが意図される。

【図面の簡単な説明】

【図１】 ユニシスＡシリーズエンタープライズ・サーバによって、ネット
ワーク上の他のホストまたはノードと通信するために用いられる、先行技術のネ
ットワーキングアーキテクチャのコンポーネントを示すブロック図である。

【図２】 ユニシスＡシリーズエンタープライズ・サーバがマイクロソフト
ウィンドウズＮＴを実行するサーバとネットワークを介して通信することができ
るようにする、先行技術の方法を示すブロック図である。

【図３】 ２つの密結合されたコンピュータシステムが仮想ＬＡＮを介して
通信することができるようにする、先行技術の装置を示すブロック図である。

【図４】 図３の先行技術の装置を、相互接続の代替例とともに示すブロッ
ク図である。

【図５】 図３の先行技術の装置を、相互接続の別の代替例とともに示すブ
ロック図である。

【図６】 ２つのコンピュータシステムが本発明に従ってＶＴＬ／ＭＳＳプ
ロトコルを使用して図３の相互接続を介して通信することができるようにする、
本発明の実施例を示すブロック図である。

【図７】 ２つのコンピュータシステムが本発明に従ってＶＴＬ／ＭＳＳプ
ロトコルを使用して図４の相互接続を介して通信することができるようにする、
本発明の実施例を示すブロック図である。

【図８】 ２つのコンピュータシステムが本発明に従ってＶＴＬ／ＭＳＳプ
ロトコルを使用して図５の相互接続を介して通信することができるようにする、
本発明の実施例を示すブロック図である。

【図９Ａ】 図３から図８に示した相互接続の一般的な動作を示すフロー図
の一部である。

【図９Ｂ】 図３から図８に示した相互接続の一般的な動作を示すフロー図
の一部である。

【図９Ｃ】 図３から図８に示した相互接続の一般的な動作を示すフロー図
の一部である。

【図９Ｄ】 図３から図８に示した相互接続の一般的な動作を示すフロー図
の一部である。

【図９Ｅ】 図３から図８に示した相互接続の一般的な動作を示すフロー図
の一部である。

【図９Ｆ】 図３から図８に示した相互接続の一般的な動作を示すフロー図
の一部である。

【図１０】 本発明のＶＴＬ／ＭＳＳ相互接続通信インターフェイスを示す
図である。

【図１１】 ＭＳＳがＱＳＰｖ２ダイアログを使用して、ＭＣＰ／ＮＰＳＵ
ＰＰＯＲＴインターフェイスを介して各ＭＳＳ−ＮＴ環境と通信する方法を示す
図である。

【図１２】 ＶＴＬ／ＭＳＳを使用したＭＣＰ出力のための、ＱＳＰベース
の出力データ転送フローを示す図である。

【図１３】 ＶＴＬ／ＭＳＳを使用したＭＣＰ入力のための、ＱＳＰベース
の入力データ転送フローを示す図である。

【図１４】 エミュレートされた相互接続の実施例における、ＶＴＬ／ＭＳ
Ｓを使用したＭＣＰ出力データ転送フローを示す図である。

【図１５】 エミュレートされた相互接続の実施例における、ＶＴＬ／ＭＳ
Ｓを使用したＭＣＰ入力データ転送フローを示す図である。

【図１６】 ＣＩＡ相互接続の実施例における、ＶＴＬ／ＭＳＳを使用した
ＭＣＰ出力データ転送フローを示す図である。

【図１７】 ＣＩＡ相互接続の実施例における、ＶＴＬ／ＭＳＳを使用した
ＭＣＰ入力データ転送フローを示す図である。

【図１８】 本発明に従ったＭＳＳの初期化を示す図である。

【図１９】 本発明に従ったＭＳＳの終了を示す図である。

【図２０】 本発明に従ったＭＳＳデータ転送を示す図である。

【図２１】 ＭＳＳの観点からの、MSS＿Endpoint＿Dialog作成プロセスを
示す図である。

【図２２】 ＭＳＳの観点からの、正常なクローズのためのMSS＿Endpoint
＿Dialog終了プロセスを示す図である。

【図２３】 ＭＳＳの観点からの、破壊的なクローズのためのMSS＿Endpoin
t＿Dialog終了プロセスを示す図である。

【図２４Ａ】 本発明に従ったMSS＿Endpoint＿Dialogの構築を示す図であ
る。

【図２４Ｂ】 本発明に従ったMSS＿Endpoint＿Dialogの構築を示す図であ
る。

【図２４Ｃ】 本発明に従ったMSS＿Endpoint＿Dialogの構築を示す図であ
る。

【図２４Ｄ】 本発明に従ったMSS＿Endpoint＿Dialogの構築を示す図であ
る。

【図２４Ｅ】 本発明に従ったMSS＿Endpoint＿Dialogの構築を示す図であ
る。

【図２４Ｆ】 本発明に従ったMSS＿Endpoint＿Dialogの構築を示す図であ
る。

【図２５Ａ】 本発明のＭＳＳを使用して、相互接続を介してＭＳＳユーザ
からデータを出力するための手続きを示す図である。

【図２５Ｂ】 本発明のＭＳＳを使用して、相互接続を介してＭＳＳユーザ
からデータを出力するための手続きを示す図である。

【図２６Ａ】 本発明のＭＳＳを使用して、相互接続からＭＳＳユーザへと
データを入力するための手続きを示す図である。

【図２６Ｂ】 本発明のＭＳＳを使用して、相互接続からＭＳＳユーザへと
データを入力するための手続きを示す図である。

【図２７Ａ】 本発明に従って作成されたMSS＿Endpoint＿Dialogのダイア
ログ終了を示す図である。

【図２７Ｂ】 本発明に従って作成されたMSS＿Endpoint＿Dialogのダイア
ログ終了を示す図である。

【図２７Ｃ】 本発明に従って作成されたMSS＿Endpoint＿Dialogのダイア
ログ終了を示す図である。

【図２８Ａ】 本発明に従った、仮想トランスポート層の構築を示す図であ
る。

【図２８Ｂ】 ＶＴＬダイアログオープンリクエスト（Dialog Open Reques
t）を受信する、結合されたシステムによって行なわれる、ＶＴＬダイアログオ
ープンリクエストの処理を示す図である。

【図２９】 本発明に従った、ＶＴＬ受動オープン（Passive Opens）のた
めのＴＣＰダイアログ構築フローを示す図である。

【図３０】 ＮＴ ＴＣＰ／ＩＰがＭＣＰ環境のＩＰアドレスを知らないた
めに、それらのＩＰアドレスをＮＴ環境におけるローカルＩＰアドレスとして使
用することができない場合における、ＭＣＰ環境からのＶＴＬ指令（能動）オー
プン（Directed (Active) Opens）のためのＴＣＰダイアログ構築フローを示す
図である。

【図３１】 本発明に従ったＶＴＬデータ転送を示す図である。

【図３２】 本発明に従ったＶＴＬデータ転送処理を示す図である。

【図３３】 ＭＣＰ環境からの正常なＶＴＬ出力データ転送フローを示す図
である。

【図３４】 ＭＣＰ環境への正常なＶＴＬ入力データ転送フローを示す図で
ある。

【図３５Ａ】 本発明に従った仮想トランスポート層接続の終了を示す図で
ある。

【図３５Ｂ】 ＶＴＬクローズ（Close）リクエストを受信する、密結合さ
れたシステムによって行なわれる、ＶＴＬクローズリクエスト処理を示す図であ
る。

【図３６】 本発明に従った、ＭＣＰ環境によって開始される、正常なＶＴ
Ｌダイアログ終了のための通常の処理を示す図である。

【図３７】 本発明に従った、ＭＣＰ環境によって開始される、ＶＴＬのダ
イアログの異常終了のための通常の処理を示す図である。

【手続補正書】特許協力条約第３４条補正の翻訳文提出書

【提出日】平成１２年８月１４日（２０００．８．１４）

【手続補正１】

【補正対象書類名】明細書

【補正対象項目名】特許請求の範囲

【補正方法】変更

【補正内容】

【特許請求の範囲】

───────────────────────────────────────────────────── フロントページの続き (72)発明者 ケイン，マイケル・ティ アメリカ合衆国、19425−8762 ペンシル バニア州、チェスター・スプリングス、シ ャノン・コート、5210 (72)発明者 サラモン，ギャリー アメリカ合衆国、19380 ペンシルバニア 州、ウェスト・チェスター、ゴーシェン・ ロード、812、ディ・23 (72)発明者 ジェニオン，スーザン アメリカ合衆国、19425 ペンシルバニア 州、チェスター・スプリングス、パイン・ ドライブ、15 (72)発明者 コイン，ロイス・ビィ アメリカ合衆国、19446 ペンシルバニア 州、ランズデイル、ウォーナー・ロード、 2263 Ｆターム(参考） 5B089 GA02 HB19 KA05 KB01 5K032 AA09 BA04 CA06 CC06 DA06 DB26 5K034 AA02 CC01 DD03 EE11 FF11 HH04 HH13 HH61 KK21 LL01 MM39 NN04 【要約の続き】 構を提示する、システムの、相互接続とは独立したメッ セージ通信トランスポートである。ＶＴＬは、ＭＳＳ接 続を使用して、セッション層への一貫性のある、相互接 続とは独立したインターフェイスを提供する。ＶＴＬ／ ＭＳＳプロトコルは、信頼性の高いデータ配信を行なう かまたは接続が利用できないことを表示する、同種のコ ネクション指向のインターフェイスを提供する。ＭＳＳ がホストインターフェイスファンクションと直接インタ ーフェイスするので、相互接続が変更されたときに必要 となるのはＭＳＳインターフェイスの変更のみである。

Claims (15)

【特許請求の範囲】
1. 【請求項１】 第１のコンピュータシステム上で実行する第１のネットワー
   クアプリケーションと、該第１のコンピュータシステムに直接相互接続されかつ
   密結合された第２のコンピュータシステム上で実行する第２のネットワークアプ
   リケーションとが、該第１および第２のネットワークアプリケーションに影響を
   及ぼすことなく互いに通信することができるようにする装置であって、 該第１のコンピュータシステムの入出力（Ｉ／Ｏ）サブシステムと該第２のコ
   ンピュータシステムのＩ／Ｏサブシステムとを結合しかつそれにわたって該第１
   および第２のコンピュータシステム間でネットワークインターフェイスカードと
   は独立してデータを伝送することのできる相互接続と、 汎用トランスポートインターフェイスを提供しかつ該第１および第２のネット
   ワークアプリケーションに対して既知のトランスポート層プロトコルをシミュレ
   ートして、前記第１および第２のネットワークアプリケーションが該第１および
   第２のネットワークアプリケーションにトランスペアレントな態様で通信するこ
   とができるようにする、該第１および第２のコンピュータシステム上で実行する
   相互接続メッセージ通信システムとを含む、装置。
2. 【請求項２】 該第１のコンピュータシステムのＩ／Ｏサブシステムと該第
   ２のコンピュータシステムのＩ／Ｏサブシステムとの間の該相互接続が、データ
   をその上で伝送することのできる、該Ｉ／Ｏサブシステム間の物理的接続を含む
   、請求項１に記載の装置。
3. 【請求項３】 該相互接続メッセージ通信システムは、該相互接続の通信プ
   ロトコルとは独立した前記汎用トランスポートインターフェイスを提供しかつ該
   相互接続の両側に該相互接続の通信プロトコルに依存するさらなるインターフェ
   イスを提供するメッセージ通信サブシステム（「ＭＳＳ」）を含み、よって、該
   相互接続が変更されたときには該さらなるインターフェイスの変更のみが必要と
   される、請求項１に記載の装置。
4. 【請求項４】 該ＭＳＳは、前記第１および第２のコンピュータシステムの
   各々上にＭＳＳコンポーネントを含み、各ＭＳＳコンポーネントには前記独立し
   たトランスポートインターネットを通じて少なくとも１つのローカルＭＳＳユー
   ザが接続され、該第１のコンピュータシステム上のＭＳＳコンポーネントは該第
   ２のコンピュータシステムの各相補的リモートＭＳＳユーザとのダイアログを作
   成する、請求項３に記載の装置。
5. 【請求項５】 各ＭＳＳコンポーネントは、該相互接続を介してアクセス可
   能なすべての相補的リモートＭＳＳユーザについての情報を該ローカルＭＳＳユ
   ーザに知らせる、ローカルＭＳＳユーザのためのダイアログテーブルを構築し、
   かつ、相補的リモートＭＳＳユーザが追加または除去されると前記ダイアログテ
   ーブルを更新するための手段を含む、請求項４に記載の装置。
6. 【請求項６】 各ＭＳＳコンポーネントは、該ローカルＭＳＳユーザが該相
   互接続を介して該相補的リモートＭＳＳユーザとのダイアログを構築し、それに
   ついてのステータスを受信しかつそのダイアログを無効にすることができるよう
   にする、ダイアログ管理機能を行なうための手段を含む、請求項４に記載の装置
   。
7. 【請求項７】 各ＭＳＳコンポーネントは、該ローカルＭＳＳユーザと該相
   補的リモートＭＳＳユーザとが該相互接続の通信プロトコルとは独立した態様で
   コントロールメッセージを互いに受渡しすることができるようにする、コントロ
   ールメッセージ機能を行なうための手段を含む、請求項４に記載の装置。
8. 【請求項８】 各ＭＳＳコンポーネントは、前記ローカルおよびリモートＭ
   ＳＳユーザ間に構築されたデータダイアログを介して、該ローカルおよび相補的
   リモートＭＳＳユーザ間でデータを転送するための手段を含む、請求項４に記載
   の装置。
9. 【請求項９】 前記ローカルＭＳＳユーザの１つおよび前記相補的リモート
   ＭＳＳユーザの１つは、該第１および第２のネットワークアプリケーションが該
   第１および第２のアプリケーションにトランスペアレントな態様で該相互接続を
   介して互いに通信することができるように前記既知のトランスポート層プロトコ
   ルをシミュレートする、相補的な仮想トランスポート層（「ＶＴＬ」）コンポー
   ネントである、請求項４に記載の装置。
10. 【請求項１０】 前記相補的なＶＴＬコンポーネントは、該ＭＳＳを使用し
    て、前記第１および第２のコンピュータシステム間のトランスポートダイアログ
    の構築、データ転送およびトランスポートダイアログの終了を提供する、請求項
    ９に記載の装置。
11. 【請求項１１】 前記ＶＴＬコンポーネントはそれぞれ、前記第１および第
    ２のネットワークアプリケーションとインターフェイスをとり、前記ＶＴＬコン
    ポーネントは、該第１および第２のコンピュータシステム上に、該ＭＳＳの独立
    したトランスポートインターフェイスを通じて該ＭＳＳに接続される相補的ＭＳ
    Ｓユーザとして実装される、請求項９に記載の装置。
12. 【請求項１２】 各ＭＳＳコンポーネントは、該ローカルＶＴＬコンポーネ
    ントおよび該相補的リモートＶＴＬコンポーネントとが、それら相補的なＶＴＬ
    コンポーネント同士でダイアログの作成およびオープンを調整するようメッセー
    ジのシーケンスを交換することのできる信頼性の高いコントロールダイアログを
    作成することができるようにする、メッセージ制御機能を行なうための手段を含
    む、請求項１１に記載の装置。
13. 【請求項１３】 データが前記第１のネットワークアプリケーションから前
    記第２のネットワークアプリケーションへと前記相互接続を介して転送されると
    き、前記第１のネットワークアプリケーションとインターフェイスする前記ＶＴ
    Ｌコンポーネントが、前記第２のネットワークアプリケーションに転送されるべ
    きデータにＶＴＬデータ転送ヘッダをアペンドしかつ前記オープンされたダイア
    ログ上でデータ転送を開始する、請求項１２に記載の装置。
14. 【請求項１４】 第１のコンピュータシステム上で実行する第１のネットワ
    ークアプリケーションと、該第１のコンピュータシステムの入出力（Ｉ／Ｏ）サ
    ブシステムと第２のコンピュータシステムのＩ／Ｏサブシステムとの間の相互接
    続を介して該第１のコンピュータシステムに直接相互接続されかつ密結合された
    該第２のコンピュータシステム上で実行する第２のネットワークアプリケーショ
    ンとが、ネットワークインターフェイスカードとは独立して該第１および第２の
    ネットワークアプリケーションの本来のプロトコルでデータを互いに伝送するこ
    とができるようにする方法であって、 該第１および第２のそれぞれのコンピュータシステム上の該第１および第２の
    ネットワークアプリケーションに対して既知のトランスポート層プロトコルをシ
    ミュレートするステップと、 該相互接続にわたって、該第１および第２のネットワークアプリケーションが
    該第１および第２のネットワークアプリケーションに対してトランスペアレント
    な態様で互いに通信することのできるダイアログを作成するステップと、 該第１および第２のネットワークアプリケーション間でデータを転送するため
    に該ダイアログを開くステップと、 転送されるべき該データにデータ転送ヘッダを付与するステップと、 該データおよび該データ転送ヘッダを該相互接続にわたって該開いたダイアロ
    グを介して転送するステップとを含む、方法。
15. 【請求項１５】 前記第１および第２のアプリケーションの複数対のために
    該相互接続上に複数のダイアログを作成して、アプリケーションの各対が該対を
    なす第１および第２のアプリケーションの該本来のプロトコルに対してトランス
    ペアレントな態様で通信することができるようにするステップと、該対をなすア
    プリケーション間のデータ転送のために使用されるべきダイアログを特定するス
    テップとをさらに含む、請求項１４に記載の方法。