(57)【要約】【課題】効率のよいトランスポート層処理を有する高速・低レイテンシ内部接続アーキテクチャを提供する。【解決手段】それぞれのクライアントをトランスポート層１０４下のホストの論理ネットワーク層１０６へ結合するためのトランスポート層ファシリティは、メッセージシステム１００およびＣＩＡプリミティブとトランスポート層機能サービスを規定する意味規則の組１２００を含む通信内部接続アーキテクチャ（ＣＩＡ）１０００を含む。【選択図】　　　　図１Ａ
2004005661.tif 000002
【特許請求の範囲】
【請求項１】
それぞれのクライアントをトランスポート層下のホストの論理ネットワーク層へ結合するためのトランスポート層ファシリティであって、
メッセージシステムおよびＣＩＡプリミティブとトランスポート層機能サービスを規定する意味規則のセットを含む通信内部接続アーキテクチャ（ＣＩＡ）を含む、トランスポート層ファシリティ。
【請求項２】
前記メッセージシステムが、
少なくとも１つのバッファと、
少なくとも１つの内部接続フロントエンドユニット（ＩＦＥ）とを含み、各ＩＦＥが、以下のデータ構成のグループ、すなわちノード、ダイアログ、プールマネジャおよびプールバッファからなるグループから選択された少なくとも１つのデータ構成を含む、請求項１に記載の、ファシリティ。
【請求項３】
前記ＣＩＡプリミティブと意味規則のセットが、ノードオペレーション、ダイアログオペレーション、バッファプールオペレーション、プールマネジャオペレーション、および内部接続フロントエンド管理オペレーションを規定する、請求項２に記載のファシリティ。
【請求項４】
ローカルクライアントと遠隔パートナクライアントとの間で論理ダイアログを確立させるための方法であって、ローカルクライアントがダイアログオブジェクトを有し、
遠隔クライアントの側で、
ダイアログを創出し、遠隔ダイアログオブジェクトを識別する対応の遠隔ダイアログ情報を検索するステップと、
ローカルクライアントから受信したローカルダイアログ情報と遠隔ダイアログ情報に基づいてダイアログのペアリングを決定するステップと、
前期ペアリング決定の後、遠隔パートナクライアント側でダイアログアソシエィトプリミティブを呼び出し、それによりローカルクライアントもダイアログアソシエィトプリミティブを呼び出して、ローカルダイアログオブジェクトへ遠隔ダイアログ情報を与えることができるようにするステップとを含む、方法。
【請求項５】
ローカルクライアント側で、
ダイアログ創出プリミティブを発行して、選択されたローカル内部接続フロントエンド（ＩＦＥ）でローカルクライアントのダイアログオブジェクトを創出するステップと、
後で関連付けを行うのに必要なダイアログ情報を検索するステップと、
遠隔パートナクライアントへローカルダイアログ情報と通信するステップとを含む、請求項４に記載の方法。
【請求項６】
ローカルクライアントとの論理ダイアログを確立するためのシステムであって、ローカルクライアントがダイアログオブジェクトを有し、前記システムが、
ダイアログを創出し、遠隔ダイアログオブジェクトを識別する対応の遠隔ダイアログ情報を検索し、ローカルクライアントから受信したローカルダイアログ情報および遠隔ダイアログ情報に基づき、ダイアログのペアリングを決定し、ペアリングが決定した後にダイアログアソシエィとプリミティブと呼び出し、それによりローカルクライアントもダイアログアソシエィトプリミティブを呼び出して、ローカルダイアログオブジェクトへ遠隔ダイアログ情報を与えることが出来るようにする遠隔クライアントを含む、システム。
【請求項７】
ダイアログ創出プリミティブを発行して、選択されたローカル内部接続フロントエンド（ＩＦＥ）でローカルクライアントのダイアログオブジェクトを創出し、後の関連付けに必要なローカルダイアログ情報を検索し、かつローカルダイアログ情報を遠隔クライアントに通信する、ローカルクライアントを含む、請求項６に記載のシステム。
【発明の詳細な説明】
【０００１】
１．発明の分野
この発明は、コンピュータネットワーク化およびデータ通信の分野に関する。
【０００２】
２．先行技術の説明
ダイアログ（仮想回線とも称される）は異なる応用プロセス間においてデータを搬送する。ダイアログはメッシュなどのコンピュータネットワーク上でデータを搬送するよう論理的に設定され得る。あるコンピュータネットワークでは、ダイアログは、異なる端末システムまたはホストで実行する応用プロセス間におけるデータ通信を与える。さらに、ダイアログは、同一のホストで実行する応用プロセス間でもデータを搬送し得る。
【０００３】
仮想回線（つまりダイアログ）を実現するために、異なるサービスおよび信頼性を提供するよう、あるデータ通信ネットワークにおいては、複数の機能層（たとえば、アプリケーション層、プレゼンテーション層、セッション層、トランスポート層、ネットワーク層、リンク層、および物理層）が用いられる。各層は、サービスを提供するよう、関連のプロトコルおよびプリミティブの範囲を有する。各層は、データおよび対応の層プロトコル制御情報を含む対応のプロトコルデータユニットを形成する。異なる端末システムにおける同じ層での同位プロトコルエンティティは、対応の層プロトコルデータユニットおよびプロトコル制御情報を管理することによってその層においてのサービスを提供する。データ通信ネットワークにおけるこのような複数機能層のオペレーション（たとえば、ＯＳＩまたは伝送制御プロトコル／インターネットプロトコル（Ｔｒａｎｓｍｉｓｓｉｏｎ　ＣｏｎｔｒｏｌＰｒｏｔｏｃｏｌ　／　Ｉｎｔｅｒｎｅｔ　Ｐｒｏｔｏｃｏｌ（ＴＣＰ／ＩＰ））プロトコル群において用いられるようなアプリケーション層、プレゼンテーション層、セッション層、トランスポート層、ネットワーク層、リンク層および物理層）は周知なものであり、さらに詳細に記載する必要はないであろう。たとえば、Ｍａｒｔｉｎ，　Ｊ．，　ＴＣＰ／ＩＰ　Ｎｅｔｗｏｒｋｉｎｇ：　Ａｒｃｈｉｔｅｃｔｕｒｅ，　Ａｄｍｉｎｉｓｔｒａｔｉｏｎ，　ａｎｄ　Ｐｒｏｇｒａｍｍｉｎｇ，（ＴＣＰ／ＩＰネットワーク化：アーキテクチャ、管理およびプログラミング）、（ＰＴＲ　Ｐｒｅｎｔｉｃｅ　Ｈａｌｌ：Ｅｎｇｌｅｗｏｏｄ　Ｃｌｉｆｆｓ，　ＮＪ　１９９４），　ｐｐ．２９−３０（ここに引用により援用される）およびＦ．　Ｈａｌｓａｌｌ，　Ｄａｔａ　Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ，　Ｃｏｍｐｕｔｅｒ　Ｎｅｒｗｏｒｋｓ，　ａｎｄ　Ｏｐｅｎ　Ｓｙｓｔｅｍｓ（データ通信、コンピュータネットワークおよびオープンシステム）、第４版、（Ａｄｄｉｓｏｎ−Ｗｅｓｓｌｅｙ：　Ｕ．Ｓ．Ａ．　１９９６），ｐ．６６３）（ここに引用により援用される）を参照されたい。層は、ソフトウェア、ファームウェア、および／またはハードウェアとして実現される。
【０００４】
従来の通信システムは今では高バンドパス能力を有する。高速ネットワーク化技術に対するデータスループットは、１００メガビット／秒〜１ギガビット／秒のオーダの速度で生ずる。しかしながら、レイテンシは高い。レイテンシとは、トランザクションが発行される時間とそのトランザクションが完了されたものとして報告される時間との間の時間間隔である。高レイテンシを伴うシステムでは、通信を行なう２者のクライアントがデータ要求を完了するためのラウンドトリップ時間はミリ秒のオーダになり得る。
【０００５】
レイテンシは、従来の通信システムでは、トランスポート層およびトランスポート層よりも論理上下の層（たとえば、ネットワーク層、リンク層および物理層）を限定的にではないが含む通信層に関与するオーバヘッドにより一部生ずる。しかしながら、下位層ネットワークファシリティは進歩しており、あるネットワーク上でのメッセージの伝送および配信は現在でははるかにより効率的かつ信頼性があり、特に、重結合されたクラスタ化されたシステムにおいて特に効率がよくかつ信頼性がある。
【０００６】
トランスポート層ファシリティは実質的なレイテンシを与え続ける。一般に普及しているトランスポート層プロトコル、たとえばＴＣＰなどは、下位層ビットレートは中位に高いが、信頼性は低く、さらに、下位のネットワーク層により誘導されるレイテンシが高い、といったローカルエリアおよびワイドエリアネットワーク（ＬＡＮ／ＷＡＮ）環境をサポートするよう開発された。トランスポートファシリティは、信頼性のある伝送および配信を保証するよう、従来のトランスポートプロトコルに含まれる。ＡＴＭ、Ｆｉｂｅｒ　Ｃｈａｎｎｅｌ、ＳｅｒｖｅｒＮｅｔＴＭといった高速・低レイテンシ通信ネットワークの出現により、これまでは信頼のある通信を達成すべくトランスポート層に組込まれていたファシリティが今では下位の通信ネットワーク自身によって提供されつつある。たとえば、ＡＴＭ、Ｆｉｂｅｒ　Ｃｈａｎｎｅｌ、ＳｅｒｖｅｒＮｅｔＴＭは、間順配信、検査合計、セグメント化および再アセンブル（ＳＡＲ）といった、信頼性のある伝送および配信を保証するための特定の下位層ファシリティを含む。
【０００７】
従来の高レイテンシトランスポート層プロトコルおよびアーキテクチャは、しかしながら、下位のネットワーク化層（たとえばネットワーク層、リンク層および物理層）は信頼性がないものであるとする。したがって、高レイテンシトランスポート、たとえばＴＣＰ／ＩＰプロトコル群などは、下位層データ伝送信頼性において進展を推進するようには位置付けられない。従来のトランスポート層プロトコルは、受信側がデータに対応し得るか否かにかかわらずそのデータが送られるという、プッシュデータモデルの通信にさらに制限される。このようなプッシュモデルデータ通信は、フロー制御問題および過剰なデータコピーを引起す。
【０００８】
必要とされるのは、効率のよいトランスポート層処理を有する高速・低レイテンシ内部接続アーキテクチャである。特に、重結合されたクラスタ化されたシステムに対するデータ伝送および配信の信頼性における改善点を向上させ得る標準トランスポート層プロトコルおよびアーキテクチャが必要とされる。データコピーを取除きかつ効果的なフロー制御を行なう高速・低レイテンシトランスポート内部接続アーキテクチャが必要とされる。
【０００９】
発明の概要
この発明に従うと、プルデータモデルを用いて通信行なうクライアント間において信頼性のありかつ効率のよいトランスポートサービスを提供するような通信内部接続アーキテクチャ（ＣＩＡ）が特定化される。このプルデータモデルは、ダイアログの送信クライアントが受信クライアントにデータを送るため許可を待つという通信モデルである。受信クライアントは送信クライアントからのデータを「プル」する。受信クライアントは準備ができるとデータを要求するので、フロー制御はこのプルデータモデルによって処理される。さらに、この通信内部接続アーキテクチャは、この発明に従うと、プッシュデータモデルと同様に効率よくかつ信頼性をもってデータを転送するプッシュデータモデルを実現する。
【００１０】
この発明のＣＩＡプルデータモデルは、送信側によってデータバイトを受信側メモリアドレスに結合することを必要とすることによって、受信オペレーションをサポートする。通信を行なう送信クライアントと受信クライアントとの間のデータ転送は、データをメモリに書込む“ライト・オンリ”オペレーションを実行することにより専ら行なわれ得る。高レイテンシを有する読出オペレーションは完全に回避され得る。
【００１１】
この発明の一実施例に従うと、ある方法およびコンピュータプログラム製品は、通信を行なうクライアント間におけるプルデータモデルに基づくトランスポート層データ通信を提供する。データを受信するため、受信クライアントは、ダイアログ受信（ｄ＿ｒｃｖ）プリミティブに対するパラメータを含むＣＩＡ制御ブロック（ＣＣＢ）を構築する。受信クライアントはこのＣＣＢを受信側ＣＩＡトランスポート層ファシリティに送る。これらｄ＿ｒｃｖパラメータは、宛先データ領域（つまりデータ宛先アドレス）と、各データ宛先アドレスにおいてどれだけのデータ空間が利用可能であるかとを規定する分散リストを識別する。たとえば、「バッファで受信」オペレーションでは、ｄ＿ｒｃｖパラメータは、特に、受信側バッファおよびそのバッファに対する所望の転送長を識別する。さらなるｄ＿ｒｃｖパラメータを用いることによって、利用可能な受信サービス（たとえば自動受信サービスまたは部分受信サービス）を選択する。
【００１２】
受信側ＣＩＡトランスポートファシリティは、受信内部接続フロントエンド（ＩＦＥ）とも称される。この受信ＩＦＥは、ｄ＿ｒｃｖプリミティブで受信クライアントにより送られるパラメータに基づいて受信制御ブロック（ＲＣＢ）を構成する。受信ＩＦＥはこのＲＣＢをネットワークパケットでメッシュ上を送信側ＣＩＡトランスポートファシリティへ、つまり、論理ダイアログに関連付けられる送信ＩＦＥに送る。
【００１３】
送信側では、送信ＩＦＥによって受信制御ブロック（ＲＣＢ）が記憶される。このＲＣＢの到着は、インターフェイスの送信側において合致処理を生じさせる。ＲＣＢは、分散リストを識別するフィールド（たとえば受信データ宛先アドレスならびに最大データ転送長およびバッファ長）を含む。このＲＣＢは、ｄ＿ｒｃｖ意味規則をサポートするような関連の他のフィールド（たとえば自動受信、バッファプールリファレンス）を含む。複数のＲＣＢを送信側にて待ち行列に入れることにより、レイテンシを低減しかつデータに対する複数要求に対応し得る。
【００１４】
データを送信するため、送信クライアントはダイアログ送信（ｄ＿ｓｅｎｄ）プリミティブに対するｄ＿ｓｅｎｄパラメータを制御ブロック（ＣＣＢ）で送信ＩＦＥに送る。これらｄ＿ｓｅｎｄパラメータは論理ダイアログおよび収集リストを識別する。付加的なフィールドをさらに用いることにより、他のｄ＿ｓｅｎｄ意味規則（たとえば部分転送対メッセージの終り指示）をサポートする。
【００１５】
ＣＩＡインターフェイスの送信側のトランスポート層（換言すれば、送信ＩＦＥ）は、ＲＣＢと未処理のｄ＿ｓｅｎｄＣＣＢとの間において合致がいつなされるかを判断する。データを転送するため、送信ＩＦＥは、ｄ＿ｓｅｎｄＣＣＢによって特定化されるデータを、その合致するＲＣＢによって特定化される宛先アドレスに結合する。
【００１６】
データがメッシュ上を転送されるネットワーク化環境では、送信ＩＦＥによってネットワークパケットが構築される。このネットワークパケットは送信者のデータおよび受信者メモリ宛先アドレスのコピーを含む。受信クライアントおよび送信クライアントが同じメモリ空間を共有する場合、送信ＩＦＥはメモリコピーを用いてデータ転送を実行する。
【００１７】
受信側では、受信ＩＦＥによって受信されたネットワークパケットが解体される。次いで、受信ＩＦＥは、送信側データを、ネットワークパケットから、その受信されたネットワークパケットにあるメモリ宛先アドレスによって特定される受信バッファ内に記憶させる。
【００１８】
この発明の別の特徴に従うと、アーリー・ファー・エンド（Ｅａｒｌｙ−Ｆａｒ−Ｅｎｄ）およびファー・エンド（Ｆａｒ−Ｅｎｄ）という２つの送信サービスクラスが提供される。ユーザがアーリー・ファー・エンドのサービスを要求する場合には、送信ＩＦＥが送信クライアントの資源を必要としなくなるとすぐに送信ＩＦＥは送信クライアントに「送信完了」指示を送る。
【００１９】
ユーザがファー・エンドのサービスを要求する場合には、送信ＩＦＥは受信ＩＦＥによって送信される「肯定応答」パケットを待つ。送信ＩＦＥによる「肯定応答」パケットの受信によって、送信クライアントへの「送信完了」指示が引起される。
【００２０】
この発明にはさらなる特徴および利点がある。複数の、全二重の、信頼性のある仮想回線接続（つまり多重論理ダイアログ）が各ノードごとに設けられ得る。複数のダイアログオブジェクトが１つのノードを参照し得る。複数の未処理のＣＩＡプリミティブオペレーションが各ダイアログ上において許される。ダイアログはバイトストリームまたはメッセージ指向型データを処理し得る。
【００２１】
データオペレーションおよび特徴は、それらに限定されるものではないが、分散および収集サポート、アーリー・ファー・エンドおよびファー・エンドの送信サービスのクラス、自動繰返し受信オプション、ｓｅｎｄ／ｒｃｖ長に対する実質的な制限が全くない部分送信および受信メッセージ、および複数ダイアログ優先順位を含む。
【００２２】
この発明に従うと、ユーザレベル管理ダイアログを用いることによって他の論理ダイアログを確立することができる。タイプ１およびタイプ２ダイアログ確立サービスが提供される。
【００２３】
この発明のさらなる特徴に従うと、効率のよいかつ信頼性のあるトランスポートサービスを提供するようプルデータモデルにおいてバッファプールおよびプールマネージャを利用する通信アーキテクチャが提供される。バッファプールおよびプールマネージャオペレーションは、アドレス結合検査、バッファプールクレジット、低水位標通知、およびデータ結合を行なうことによって、データ転送性能をさらに最適化する。
【００２４】
この発明のさらなる特徴および利点、ならびにこの発明のさまざまな実施例の構造およびオペレーションを、添付の図面を参照しながら以下に詳細に説明する。
【００２５】
ここに組入れられかつ明細書の一部をなす添付の図面は、この発明を例示し、および、明細書の記載とともに、この発明の原理を説明し、さらに、当業者がこの発明を実施し利用できるようにするものである。
【００２６】
好ましい実施例の詳細な説明
目次
１．外観および用語
２．例示的環境
３．通信内部接続アーキテクチャ（ＣＩＡ）
ａ．ＣＩＡ内部接続モデル
ｂ．例示的Ｗｉｎｄｏｗｓ（Ｒ）　ＮＴＴＭ環境
４．ＣＩＡデータ通信
ａ．プルデータモデル
ｂ．オペレーション
１．ＣＩＡオブジェクト
２．データ転送
３．収集
４．分散
５．サービスの送信クラス（アーリー・ファー・エンドおよびファー・エンド）
６．送信および受信要求の順序付け
７．複数の未処理の送信および受信要求
８．自動受信および自動送信
９．部分メッセージ（部分受信および部分送信）
１０．ダイアログ優先順位属性
５．ＣＩＡ管理
ａ．ノードプリミティブおよび通知
ｂ．ダイアログ確立、終了および通知
１．タイプ１
２．タイプ２
ｃ．ユーザレベル管理ダイアログ
ｄ．ＩＦＥ管理プリミティブおよび通知
６．バッファプール（ＢＰ）およびプールマネージャ（ＰＭ）オペレーション
ａ．バッファプールで受信オペレーション
ｂ．「バッファプールで受信」オペレーションをサポートするＣＩＡオブジェクトおよびプリミティブの例示的説明
１．ＢＰオペレーションプリミティブ
２．ＰＭオペレーションプリミティブ
３．データ結合アルゴリズム
４．ダイアログオペレーションプリミティブ
５．バッファプール
６．プールマネージャ
７．プールマネージャシャドウ
８．バッファプールで受信のためのＲＣＢ
９．ダイアログオブジェクト
１０．ノード
７．例示的コンピュータシステム
８．例示的ＣＩＡ−ＩＦＥインターフェイス
ａ．ＣＩＡ−ＩＦＥ初期設定
ｂ．ＣＩＡプロバイダ
ｃ．ＩＦＥ接続機構スタイル
ｄ．ＣＩＡ代理ドライバ
Ｅ．ＩＦＥアドレス指定
９．結論
【００２７】
１．外観および用語
この発明は添付の図面を参照して説明される。図面において、同様の参照番号は同一であるかまたは機能的に同様である要素を示す。加えて、参照番号の左端の桁は、当該の参照番号が最初に現われる図面を識別するものである。
【００２８】
この発明は、プルモデルデータ通信を用いるデータ転送のための方法、システムおよびコンピュータプログラム製品を提供する。この発明は、通信を行なうクライアント間に効率のよいかつ信頼性のあるトランスポートサービスを提供するような通信内部接続アーキテクチャについて述べる。この通信内部接続アーキテクチャ（ＣＩＡ）は、送信側が、送信されるべきデータを、そのデータが受信側においてどこに記憶されるべきかを示すデータ宛先記述子（メモリアドレス）とともに、受信側に結合するという、プルモデルに基づくデータ通信を含む。このような態様によって、受信されたデータはデータコピーを全く必要としないライトオンリオペレーションを用いて記憶され、フロー制御の問題が取除かれる。
【００２９】
この発明をより明確に記載するため、明細書中では、可能な限り整合性をもって以下の用語定義に従うよう努力がなされている。
【００３０】
「通信内部接続アーキテクチャ」「ＣＩＡ」およびその等価語は、ここに記載されるこの発明に従う通信内部接続アーキテクチャを示すべく相互に入れ替え可能に用いられる。この通信内部接続アーキテクチャは、任意の２者のクライアント間においてトランスポートレベルのデータ通信を与えるものである。ＣＩＡ機能性は、それに限定されるものではないが、トランスポート層を含む任意のネットワーク通信層において実現され得る。
【００３１】
「内部接続」は、２者のクライアント間におけるデータ通信を可能にする内部接続フロントエンド（ＩＦＥ）間における論理接続を示す。内部接続は、広域ネットワーク上、重結合されたネットワーク上、または単一のシステム内においては共用メモリ環境において拡張し得る。
【００３２】
「内部接続フロントエンド」「ＩＦＥ」およびその等価語は、通信モジュールをクライアント（システムおよび／またはアプリケーション）に接続するために用いられるモジュール（ソフトウェア、ファームウェア、および／またはハードウェアを介して実現される）を示す。この発明に従うＩＦＥは、ここに記載されるように、１つ以上のＣＩＡプリミティブおよびオペレーションならびにその均等物を有するＣＩＡを含む。ＩＦＥ機能性は、ホストプロセッサおよび／または別個のユニットにおいて実現され得る。
【００３３】
「ＣＩＡ制御ブロック」、「ＣＣＢ」、「制御ブロック」、およびその等価語は、クライアント（システムおよび／またはアプリケーション）とＩＦＥとの間にてＣＩＡプリミティブを含みおよび送るよう用いられるデータ構造を、相互に置換可能に示すよう用いられる。
【００３４】
「メッシュ」、「ネットワーク」、およびその等価語は、同種ノード間および／または異種ノード間における対称の二重通信を提供する物理リンクをサポートする任意の物理リンク技術を示す。
【００３５】
「ノード」、「ノードオブジェクト」、およびその等価語は、メッシュ、物理リンク、ループバックファシリティ、または共用メモリ構成を介して接続される他のＩＦＥを表わすために用いられる、あるＩＦＥによって維持されるデータ構造を、相互に置き換え可能に示すため用いられる。
【００３６】
「ダイアログ」、「ダイアログオブジェクト」、およびその等価語は、「論理ダイアログ」を表わすよう用いられる、あるＩＦＥによって維持されるデータ構造を、相互に置き換え可能に示すため用いられる。「論理ダイアログ」およびその等価語は、クライアント（システムおよび／またはアプリケーション）間における全二重通信回線を示す。
【００３７】
「バッファ」およびその等価語は、バッファアドレスによってアドレス指定されるメモリ領域である。
【００３８】
「バッファプール」およびその等価語は、バッファアドレスおよびバッファプール属性を記憶するデータ構造である。
【００３９】
「プールマネージャ」およびその等価語は、バッファ優先パラメータを説明する。バッファ優先パラメータは、利用可能なバッファを転送長に合致させるための最もよく適合する能力を与えるものである。
【００４０】
２．例示的環境
この発明は、例示的コンピュータネットワーク化環境に関連して記載される。これらの用語における記載は便宜上与えられるにすぎない。この発明はこの例示的環境における適用に限定されることが意図されるものではない。実際に、以下の記載を読めば、当業者にはこの発明を代替的環境において実施する方法が明らかとなるであろう。
【００４１】
３．通信内部接続アーキテクチャ（ＣＩＡ）
図１Ａ、図１Ｂおよび図１Ｃはこの発明に従う通信内部接続アーキテクチャ（ＣＩＡ）を示す。ＣＩＡ１０００は、トランスポートレベルの内部接続通信サービスを与える。ＣＩＡ１０００は、ネットワーク化または共用メモリ環境における任意のコンピュータ上のトランスポート層として実現され得る。図１Ａはネットワーク化構成を示す。ホストコンピュータ１００はＣＩＡ１０００およびトランスポート層１０４を含む。次いで、ホスト１００で実行するアプリケーション１０２がトランスポート層１０４を介してデータをネットワーク層１０６に転送する。このデータは次いでバス１０８または他のタイプのリンクを介してデータ通信ネットワーク１１０に送られる。
【００４２】
ＣＩＡ１００は、ＴＣＰ／ＩＰのような従来のトランスポート実現例よりも少ないプロトコルオーバヘッドでトランスポートレベルの通信サービスを提供するために、トランスポート層１０４に付加される。以下においてさらに詳細に記載されるように、ＣＩＡ１０００は、物理レベルにおいて通信技術における現在の進歩をさらに向上させることによってより高く最適化されたサービスを提供する（たとえば、順序および信頼性のある配信におけるセグメント化／再アセンブリ）。他の、サービス特徴の質も提供され得る。たとえば、保証されたダイアログバンド幅が与えられ得る。ＣＩＡの重要な特性は以下のようにまとめられる：
１．物理的な内部技術に依存しない。
【００４３】
２．ノード（つまりダイアログ）単位での、複数の、全二重の、信頼性のある仮想回線接続。
【００４４】
３．各ダイアログにおいて複数の未処理オペレーションが許される。
４．バイトストリームまたはメッセージ指向型データ転送。
【００４５】
５．ｓｅｎｄ／ｒｃｖ長に対する制限が実質的に全くない部分送信および受信。
６．トランケーション選択肢を伴う受信。
【００４６】
７．プログラマブルバッファ優先制御論理を含むバッファプールサポート。
８．特定のメモリへの受信（カーネルコピーなし）がサポートされる。
【００４７】
９．分散および収集サポート（バッファプールを特定のメモリアドレスと混合することを含む）。
【００４８】
１０．自動繰返し受信選択肢。
１１．２つの送信サービスクラス（アーリー・ファー・エンド、ファー・エンド）。
【００４９】
１２．ＮｅｔＢＩＯＳ送信意味規則を伴う、強調型ダイアログに基づくフロー制御。
【００５０】
１３．複数のダイアログ優先順位。
図１Ａに示されるように、ＣＩＡ１０００は、ＣＩＡインターフェイス１０５０と、メッセージシステム１１００と、ＣＩＡプリミティブおよび意味規則の組１２００とからなる。さらに、ＣＩＡ管理サービス（ＣＩＡ−ＭＳ）１３００が、ファントムの破線で示され、以下にさらに説明される。
【００５１】
図１Ｂはメッセージシステム１１００の要素を示す。メッセージシステム１１００は、１つ以上のバッファ１１１０と、内部接続フロントエンドユニット（ＩＦＥ）１１２０と、制御ブロック１１３０とからなる。各ＩＦＥ１１２０は１つ以上の送信インターフェイス１１２１および受信インターフェイス１１２３からなる。各ＩＦＥ１１２０は、さらに、０またはそれ以上のノード１１４０と、ダイアログ１１５０と、プールマネージャ１１６０と、バッファプール１１７０とからなる。各ダイアログ１１５０は０かまたはそれ以上の送信チャネル１１８０および受信チャネル１１９０からなる。このメッセージシステム１１００における各要素の動作を以下にさらに詳細に記載する。
【００５２】
図１Ｃは、ＣＩＡプリミティブおよび意味規則の組１２００からの要素を示す。このＣＩＡプリミティブおよび意味規則の組１２００は、ノードオペレーション１２１０と、ダイアログオペレーション１２２０と、バッファプールオペレーション１２３０と、プールマネージャオペレーション１２４０と、内部接続フロントエンド管理オペレーション１２５０とを含む。ノードオペレーション１２１０は以下のタイプのプリミティブ：ＡＳＳＯＣＩＡＴＥ（関連付け），　ＣＲＥＡＴＥ（作成），　ＤＥＳＴＲＯＹ（破壊），　ＧＲＥＥＴ（挨拶），　ＮＯＴＩＦＹ／ＲＥＳＴＡＲＴ（通知／再スタート），　ＩＮＦＯ（情報）およびＢＯＵＮＤ（結合）（たとえばｎ＿ａｓｓｏｃｉａｔｅ，　ｎ＿ｂｏｕｎｄ，　ｎ＿ｃｒｅａｔｅ，　ｎ＿ｄｅｓｔｒｏｙ，　ｎ＿ｇｒｅｅｔ，　ｎ＿ｎｏｔｉｆｙ＿ｒｅｓｔａｒｔ，　ｎ＿ｚｉｎｆｏ）を含み得る。ダイアログオペレーション１２２０は、以下のタイプのプリミティブ：ＡＳＳＯＣＩＡＴＥ，　ＣＲＥＡＴＥ，　ＤＥＳＴＲＯＹ，　ＩＮＴＥＲＬＯＣＫ（インターロック），　ＲＥＣＥＩＶＥ（受信），　ＳＥＮＤ（送信），　ＳＨＵＴＤＯＷＮ（遮断）およびＩＮＦＯ（たとえばｄ＿ａｓｓｏｃｉａｔｅ，　ｄ＿ｃｒｅａｔｅ，　ｄ＿ｄｅｓｔｒｏｙ，　ｄ＿ｉｎｔｅｒｌｏｃｋ，　ｄ＿ｒｃｖ，　ｄ＿ｓｅｎｄ，　ｄ＿ｓｈｕｔｄｏｗｎ，　ｄ＿ｚｉｎｆｏ）を含み得る。
【００５３】
バッファプールオペレーション１２３０は、以下のタイプのプリミティブ：ＣＲＥＡＴＥ，　ＤＥＳＴＲＯＹ，　ＳＥＴ　ＬＯＷ　ＷＡＴＥＲ（低水設定），　ＳＵＰＰＬＹ　ＣＲＥＤＩＴ（クレジット供給），およびＩＮＦＯ（たとえばｂｐ＿ｃｒｅａｔｅ，　ｂｐ＿ｄｅｓｔｒｏｙ，　ｂｐ＿ｓｅｔ＿ｌｏｗ＿ｗａｔｅｒ，　ｂｐ＿ｓｕｐｐｌｙ＿ｃｒｅｄｉｔ，およびｂｐ＿ｚｉｎｆｏ）を含む。プールマネージャオペレーション１２４０は、以下のタイプのプリミティブ：ＣＲＥＡＴＥ，　ＤＥＳＴＲＯＹおよびＡＤＤ　ＣＯＮＴＲＯＬ（制御付加）（ｐｍ＿ｃｒｅａｔｅ，　ｐｍ＿ｄｅｓｔｒｏｙ，　ｐｍ＿ａｄｄ＿ｃｏｎｔｒｏｌ）を含む。内部接続フロントエンド管理オペレーション１２５０は、以下のタイプのプリミティブ：ＣＡＮＣＥＬ（キャンセル），　ＲＥＳＥＴ（リセット）（たとえばｉ＿ｃａｎｃｅｌ，　ｉ＿ｒｅｓｅｔ）を含む。
【００５４】
ＣＩＡプリミティブの完了は通知機構を介して報告される。ＩＦＥ、ノード、ダイアログ、およびバッファプール管理に関連する非同期条件に対し定義されるさらなる通知事象も存在する。実際の通知実現例はホスト動作環境と相関関係にある。Ｗｉｎｄｏｗｓ（Ｒ）　ＮＴＴＭアーキテクチャを伴うＣＩＡの実施例では、通知は手続呼戻しとして実現される。
【００５５】
ＣＩＡプリミティブおよび意味規則の組１２００のオペレーションを以下にさらに詳細に説明する。
【００５６】
ａ．ＣＩＡ内部接続モデル
図２は、ＣＩＡに基づく内部接続における構成要素を図示するハイレベル図である。論理的に、共通メッシュ（２０２）を介して接続されるシステム２１０、２１２、２１４の組が存在する。各システム２１０、２１２、２１４は、メッシュ２０２を介して接続されるシステム間にてＣＩＡ意味規則を実現するための、ハードウェアおよびソフトウェアからなる、システムに特有の組２１１、２１３、２１５をそれぞれ組入れる。システム２１０、２１２、２１４は、それに限定されるものではないが、企業サーバ、ＮＴサーバ、ＵＮＩＸ（Ｒ）サーバ、または他のコプロセシング要素を含む、任意のタイプのコンピュータシステムであり得る。それらに限定されるものではないが、共用メモリ、イーサネット（Ｒ）、タンデムのサーバネットワーク（Ｔａｎｄｅｍ’ｓ　ＳｅｒｖｅｒＮｅｔ）、ＳＣＩ物理、非同期転送モード（ＡＴＭ）およびＦｉｂｅｒ　Ｃｈａｎｎｅｌを含む、任意のメッシュ技術および下位層プロトコルが用いられ得る。実際には、ＣＩＡ１０００は任意の下位の物理内部接続メッシュ技術に依存しない。
【００５７】
図示されてはいないが、各システム２１０、２１２、２１４は複数のＩＦＥを含み得、複数のメッシュに１つ以上のＩＦＥを介して接続され得る。
【００５８】
ｂ．例示的Ｗｉｎｄｏｗｓ（Ｒ）　ＮＴＴＭ環境
図３は、Ｍｉｃｒｏｓｏｆｔ　Ｗｉｎｄｏｗｓ（Ｒ）　ＮＴＴＭによって利用されるネットワーク化プロトコル組織３０００にＣＩＡ意味規則３００がどのように統合され得るかを示す。ＣＣＩＡは、Ａ　Ｓｅｒｉｅｓオペレーションシステム環境においてマスタコントロールプログラム（ＭＣＰ）においても実現され得る。しかしながら、この発明は、この説明を与えられる当業者には容易に明らかとなることではあるが、Ｗｉｎｄｏｗｓ（Ｒ）　ＮＴＴＭまたはＭＣＰ環境に限定されるものではない。
【００５９】
図３の例において、３０００番台の参照番号は、Ｍｉｃｒｏｓｏｆｔ　Ｗｉｎｄｏｗｓ（Ｒ）　ＮＴＴＭオペレーティングシステムにおいて用いられるネットワーク化プロトコル組織３０００の要素を示す。３００番台の参照番号は、この発明に従うＣＩＡ要素を示す。
【００６０】
図３に示されるように、いくつかの異なるアプリケーションプログラミングインターフェイス（ＡＰＩ）３１１１、３１１２が、ネットワーク化サービスを利用するためのアプリケーション３１０２にとって利用可能である。このＷｉｎｄｏｗｓ（Ｒ）ソケットインターフェイス３１１２は、元々ＵＮＩＸ（Ｒ）システムにおいて開発されたＢｅｒｋｅｌｅｙソケットインターフェイスに因んでモデル化されたＭｉｃｒｏｓｏｆｔ　Ｗｉｎｄｏｗｓ（Ｒ）規格に従うものである。当初はＷｉｎｄｏｗｓ（Ｒ）ソケットはＴＣＰ／ＩＰ３１２２上のネットワーク化をサポートしたが、最近の拡張によって他の固有ネットワーク（たとえば、ＮｏｖｅｌｌのＩＰＸネットワークのためのＮＷＬＩＮＫ３１２４）がサポートされた。ＮＥＴＢＩＯＳインターフェイス３１１１は、パーソナルコンピュータのために開発されたオリジナルのネットワーク化ＡＰＩの１つであった。ＮＢＦ３１２１およびＮＢＴ３１１３を含むいくつかのさまざまなＮＥＴＢＩＯＳ互換性ネットワーク化実現例が開発された。ＮＢＦ３１２１は、ＩＭＢＭ固有ＮＥＴＢＥＵＩネットワーク化実現例の一実現例である。ＮＢＴ３１１３は、ＴＣＰ／ＩＰ３１２２上においてＮＥＴＢＩＯＳ実現例を規定するインターネット規格の実現例（つまりＲＦＣ１００１、１００２）である。
【００６１】
Ｗｉｎｄｏｗｓ（Ｒ）ＮＴＴＭは、トランスポートドライバインターフェイス（ＴＤＩ）３１２０と称される標準インターフェイスを規定する。これによって、既存のネットワーク実現例上で動作する新しいネットワーク化ＡＰＩを展開するための十分に規定されたインターフェイスが与えられ、さらには、既存のネットワーク化ＡＰＩのための新たなネットワーク化プロトコル実現例の組入れも斟酌される。
【００６２】
ストリームインターフェイス３１２３は、ＵＮＩＸ（Ｒ）ストリームプログラミングモデルに対して開発されたプロトコルドライバの移植を助けるよう互換層として開発された。ＮＷＬＩＮＫ３１２４は、このカテゴリに適合するプロトコルドライバの一例である。
【００６３】
ＮＤＩＳ３１３０は、ＯＳＩプロトコルスタックの層２の上端（つまりリンク層）に対応するＭｉｃｒｏｓｏｆｔ　Ｗｉｎｄｏｗｓ（Ｒ）標準プログラミングインターフェイスである。ＮＤＩＳ３１３０によって、ネットワークプロトコルは異なるベンダからのＬＡＮアダプタ３１４０で相互動作することが可能となる。ＬＡＮハードウェアベンダは、それらの特定のＬＡＮアダプタ３１４０に対してＮＤＩＳドライバ３１３１を展開する。
【００６４】
この発明に従うと、ＣＩＡ−ＵＳＥＲ．ＳＹＳ３１１は、アプリケーション３１０２が直接ＣＩＡ１０００の特徴を利用できるようにする新たなネットワーク化ＡＰＩを与える。ＣＩＡトランスポートサービス３２１は、ＣＩＡに基づく内部接続上においてＮＥＴＢＩＯＳ３１１１およびＷｉｎｄｏｗｓ（Ｒ）Ｓｏｃｋｅｔ３１１２をサポートするＴＤＩ適合性ネットワーク化インターフェイスである。仮想ＬＡＮ構成要素３３１によって、ＮＤＩＳ適合性ネットワーク化プロトコルがＣＩＡに基づく内部接続上で相互動作することが可能となる。
【００６５】
ＣＩＡプリミティブインターフェイス３２０は、ＣＩＡクライアント３１１、３２１、３３１およびＩＦＥ３２４、３２２、３２３に対する共通のプログラミングインターフェイスを与える。
【００６６】
ＩＦＥ３２２およびＩＦＥ３２４は、ＣＩＡクライアントアプリケーション（たとえば１つの要求データ）およびＣＩＡサーバアプリケーション（１つの供給データ）が同じシステムに存在することを可能にするようなループバックファシリティを実行している。この場合、ＩＦＥ３２２、３２４はメモリコピーを用いてデータを転送し得る。ＩＦＥ３２３は、内部接続アダプタ３４０によって与えられる外部メッシュ接続を介してＣＩＡ意味規則を実現する。ＩＦＥ３２３および相互接続アダプタ３４０は、１つのＩＦＥユニットとして組合せられ得、または図３に示されるように別個のユニットとして実現され得る。
【００６７】
４．ＣＩＡデータ通信
ＣＩＡはデータ通信のプッシュデータモデルおよびプルデータモデルの両方をサポートする。プッシュデータモデルは、メッセージがメッシュから応答不要の状態で到着し、部分的にデコードされ、受信要求と同期され、宛先アドレスに結合され、その一方で、後のメッセージはメッシュから流れ込み続けるという点で、これまでのネットワーク化モデル、たとえばＴＣＰ／ＩＰと同様である。対照的に、プルデータモデルでは、この発明に従うと、データを受取る準備ができたことを受信側が送信側に通知するまで、送信側は（ダイアログに対する）データを送信しない。ＣＩＡ１０００は、異なるタイプの受信オペレーション（バッファで受信、バッファプールで受信）をサポートするプルデータモデルを用いる。さらに、この発明のさらなる特徴に従うと、プルデータモデルをプッシュモデルと同程度に効率のよいものにするよう最適化する通信内部接続アーキテクチャが与えられる。
【００６８】
ａ．プルデータモデル
この発明のＣＩＡプルデータモデルは、送信側がデータバイトを受信側メモリアドレスに結合することを必要とすることによって、受信オペレーションをサポートする。通信を行なう送信クライアントと受信クライアントとの間のデータ転送は、メモリにデータを書込む“ライト・オンリ”オペレーションを実行することによって専ら行なわれ得る。高レイテンシを有する読出動作は完全に回避され得る。さらに、ＣＩＡ１０００のプルデータモデル実現例は、データ転送および制御をさらにより効率的にするよう、さらなる技術を利用してもよい。
【００６９】
ＣＩＡは、アプリケーションがダイアログに対し生じさせ得る２つの受信動作のカテゴリ、つまり「バッファで受信」および「バッファプールで受信」を規定する。「バッファで受信」オペレーションは、受信メッセージに対応するようＣＩＡクライアントがメモリ空間（たとえばユーザにより特定されるメモリ領域またはバッファ）を割当てられている場合を可能にする。このメモリ空間は、ＩＦＥに対して認められるアクセスを有するＣＩＡクライアントによって所有される。このことは、メッセージを受信するための資源割当がＣＩＡクライアントによって管理されるという点で、ＩＦＥに恩恵を与える。このことは、データが置かれるべきメモリ場所をクライアントが知っているという点で、ＣＩＡクライアントに恩恵を与える。
【００７０】
「バッファプールで受信」オペレーションは、各ダイアログに対し１つ以上のバッファを前もって割当てるということに相対する意味での、（しばしば遊休状態となり得る）多数ダイアログにわたってメモリ資源を管理する手段を与える。ＩＦＥは、入来データを利用可能なバッファ空間に結合し、その結合をＣＩＡクライアントに対し受信指示にて報告する。
【００７１】
ＣＩＡ１０００において用いられるプルデータモデルを、まず、「バッファで受信」オペレーションにて用いられるＣＩＡオブジェクトを主に参照しながら詳細に説明する。次に、ＣＩＡダイアログおよびノード管理について説明する。その後、「バッファプールで受信」オペレーションにて用いられるＣＩＡオブジェクトを参照しながら、ＣＩＡ１０００にて用いられるプルデータモデルについて詳細に説明する。
【００７２】
ｂ．オペレーション
１．ＣＩＡオブジェクト
ＣＩＡは、アーキテクチャの一部であるいくつかのオブジェクトを定義する。図４は、ＣＩＡアーキテクチャにおけるノード４０１〜４０６の役割を示す。ノード４０１〜４０６は、対応のＩＦＥ２１１、２１３、２１５によって維持されるデータ構造である。矢印で示されるように、ノード４０１〜４０６は、メッシュ２０２を介して接続される他のＩＦＥ２１１、２１３、２１５を表現するよう用いられる。
【００７３】
たとえば、ノード４０６は、ＩＦＥ２１５（「局所」ＩＦＥとも称される）によって維持される。しかしながら、ノード４０６はＩＦＥ２１３（「遠隔」ＩＦＥとも称される）を示す。図４において矢印で示されるように、ノード４０６は遠隔ＩＦＥ２１３を指すリファレンスを記憶する。たとえば、このリファレンスは指示子（たとえば遠隔ＩＦＥ２１３を識別するメディアアクセスコントロール識別情報（ＭＡＣ　ｉｄ）であり得る。同様に、ＩＦＥ２１３はＩＦＥ２１５に戻って参照するノード４０４を維持する。
【００７４】
図５は、ＣＩＡ通信システムにおけるダイアログオブジェクト５０１〜５０６の役割を示す。ダイアログオブジェクト５０１〜５０６は、アプリケーション５１０〜５１５間における全二重通信回線を表現するために用いられる対応のＩＦＥ２１１，２１３，２１５によって維持されるデータ構造である。たとえば、アプリケーション５１０は２つのダイアログオブジェクト５０１、５０２を開いた（たとえば作成した）システム２１２において実行する。
【００７５】
論理ダイアログ５２０、５３０および５４０は通信を行なうクライアント間において確立される。これら論理ダイアログ５２０、５３０、５４０は全二重通信回線を表現する。この発明のＣＩＡ通信システムに従うと、論理ダイアログは対応するダイアログオブジェクト間において確立される。たとえば、図５に示されるように、アプリケーション５１０およびアプリケーション５１２は、対応するダイアログオブジェクト５０１と５０３との間において確立される論理ダイアログ５２０を介して通信を行なう（たとえばデータを転送する）。ＩＦＥ２１１は、ＩＦＥ２１３内のダイアログオブジェクト５０３を介してのシステム２１４内のアプリケーション５１２とのデータの交換を調整するよう用いられるダイアログオブジェクト５０１内に情報を維持する。同様に、ＩＦＥ２１３は、ＩＦＥ２１１内のダイアログオブジェクト５０１を介してのシステム２１２内のアプリケーション５１０とのデータの交換を調整するよう用いられるダイアログオブジェクト５０３内に情報を維持する。
【００７６】
ＩＦＥは、２つ以上の論理ダイアログを介してデータ通信をサポートする。たとえば、論理ダイアログ５３０をサポートするために、ＩＦＥ２１１は、ＩＦＥ２１５内のダイアログオブジェクト５０５を介してのシステム２１６内のアプリケーション５１４とのデータの交換を調整するよう用いられるダイアログオブジェクト５０２内にも情報を維持する。複数のアプリケーションをサポートするシステムは、さらに、複数の論理ダイアログを介して通信を行ない得る。たとえば、論理ダイアログ５４０は、システム２１６内にて実行するアプリケーション５１５と、システム２１４内にて実行するアプリケーション５１３との間において、データ通信を与える。論理ダイアログ５４０をサポートするため、ＩＦＥ２１５は、さらに、ＩＦＥ２１３内のダイアログオブジェクト５０４を介してのアプリケーション５１３とのデータの交換を調整するよう用いられるダイアログオブジェクト５０６においても情報を維持する。
【００７７】
ＩＦＥは、以下にさらに論ずるように、それ自身の論理ダイアログを、内部において、ＣＩＡ意味規則、たとえばシャドウオブジェクト（バッファプールシャドウおよびプールマネージャシャドウ）の作成および未処理のＲＣＢの取消などをサポートするよう利用し得る。
【００７８】
２．データ転送
ＣＩＡプルデータモデルを用いるデータ転送の例を、この発明に従って、図６〜図８を参照しながら以下に説明する。図６Ａおよび図６Ｂは、便宜上受信クライアント６０１および送信クライアント６０３と符号付けされた二者の全二重通信を行なうクライアント間における例示的なＣＩＡデータ通信において用いられる構成要素を示す概略図である。ＩＦＥ２１１およびＩＦＥ２１３は、それらの対応のクライアント６０１、６０３に対する全二重ＣＩＡトランスポート層ファシリティを表わすが、便宜上、受信ＩＦＥ２１１および送信ＩＦＥ２１３と称される。図７Ａおよび図７Ｂはプルモデルデータ通信に対するルーチン７００を示すフローチャートである。図８は、２つのサービスクラス（アーリー・ファー・エンドおよびファー・エンド）をさらに示す図６の例示的ＣＩＡ通信におけるＣＩＡプリミティブおよびオペレーションの流れ図である。
【００７９】
受信クライアント６０１と送信クライアント６０３との間においてデータ通信を実行するため、論理ダイアログ５２０がまずダイアログオブジェクト５０１と５０３との間に確立される。ＣＩＡプリミティブ（たとえばｎ＿ｃｒｅａｔｅおよびｄ＿ａｓｓｏｃｉａｔｅ）を用いてノード４０１、４０３およびダイアログオブジェクト５０１、５０３を作成する。さらにＣＩＡプリミティブ（たとえばｄ＿ａｓｓｏｃｉａｔｅ）を用いてダイヤオブジェクト５０１および５０３を論理ダイアログ５２０に関連付ける。ノードおよびダイアログオブジェクト作成のためのＣＩＡプリミティブのオペレーションを以下にさらに詳細に説明する。２つのＩＦＥ間に論理ダイアログを確立するためのＣＩＡプリミティブおよびルーチンについても以下にさらに詳細に説明する。
【００８０】
図６Ａおよび図６Ｂにおいては、論理ダイアログ５２０がダイアログオブジェクト５０１と５０３との間に確立されている。したがって、ダイアログオブジェクト５０１は、送信ＩＦＥ２１３においてダイアログオブジェクト５０３を識別するリファレンスを含む。さらに、ダイアログオブジェクト５０１は、送信ＩＦＥ２１３に関連付けられるノード４０１を識別するリファレンスも含む。同様に、ダイアログオブジェクト５０３は、受信ＩＦＥ２１１においてダイアログオブジェクト５０１を識別するリファレンスを含む。さらに、ダイアログオブジェクト５０３は、受信ＩＦＥ２１１に関連付けられるノード４０３を識別するリファレンスも含む。
【００８１】
図１Ａ〜図１Ｃに関連して上に述べたように、ＣＩＡプリミティブを用いて論理ダイアログ５２０を介してのデータ通信が実行される。受信および送信タイプのＣＩＡプリミティブ（ｄ＿ｒｃｖ、ｄ＿ｓｅｎｄ）を用いてデータを転送する。所望されるデータ転送動作およびトランスポートサービスのタイプに依って、さまざまなタイプの受信ＣＩＡプリミティブが発行され得る。
【００８２】
ＣＩＡプルデータモデル通信のためのルーチン７００は、図７Ａに示されるように受信側にて主に実行されるステップと、図７Ｂに示されるように送信側にて主に実行されるステップとを含む。明確にするため、まず、ルーチン７００について、ダイアログ受信ＣＩＡプリミティブの１タイプ（ｄ＿ｒｃｖ）および１つのダイアログ送信プリミティブ（ｄ＿ｓｅｎｄ）に言及しながら説明する。データをバッファプールに受信し、データをバッファおよび／またはバッファプールに分散するための他のタイプの受信プリミティブについては、後でさらに詳細に説明する。データ収集のための他のタイプの送信プリミティブについても、例示のルーチン７００の後に説明する。
【００８３】
データを受信するため、受信クライアント６０１はｄ＿ｒｃｖプリミティブを特定化するＣＩＡ制御ブロックＣＣＢ６１１を構築しそれを受信ＩＦＥ２１１に送る（ステップ７１０）。下の表には、「バッファで受信」オペレーションのための例示的ｄ＿ｒｃｖプリミティブが、その原理パラメータおよびそれらの機能とともに記述される：
【００８４】
【表１】
2004005661.tif 000003
【００８５】
オプコードパラメータはＣＣＢのタイプを識別する。この例では、それはバッファプリミティブを伴うｄ＿ｒｃｖに対するオプコード値となる。ダイアログハンドルは、受信データ動作に関連付けられる局所ダイアログオブジェクトを識別する。分散リストパラメータは、受信されたデータを記憶するための１つ以上のバッファ（つまりメモリ領域および容量）を特定する。たとえば、図６Ｂに示されるように、ＣＣＢ６１１は、バッファプリミティブを伴うｄ＿ｒｃｖを識別するオプコードフィールドと、ダイアログオブジェクト５０１を識別するダイアログハンドル６４１と、バッファ６２１を指しかつバッファ６２１の長さ（またはサイズ）（たとえば１ＭＢ）を識別する分散リスト６４４とを有するｄ＿ｒｃｖプリミティブを含む。
【００８６】
結果記述子パラメータ６４３は結果場所を指す。この結果場所は、ｄ＿ｒｃｖプリミティブ結果情報を追尾する結果構造６５１が記憶される場所である。たとえば、この結果記述子は、送信ＩＦＥ２１３によって更新される特定のメモリ領域（つまりバッファ６５１）を指し得る（図６Ｂを参照されたい）。下に説明されるバッファプールで受信オペレーションでは、この結果記述子は特定のバッファまたはプールマネージャリファレンスを介してバッファプールを参照し得る。
【００８７】
結果構造６５１は、ｄ＿ｒｃｖプリミティブの結果に関する情報を、ｒｃｖ＿ｒｅｓｕｌｔフィールド６７２において送信側に既知のさらなる情報（たとえば、残りのデータ長、ＥＯＭ、トークン）とともに記憶する。このようにして、送信ＩＦＥ２１３は、（たとえば残りのデータ長に対してｄ＿ｒｃｖプリミティブをポストすることによって）受信ＩＦＥ２１１が知的データ転送要求をなすことを可能にするインターフェイスの送信側での条件について、受信ＩＦＥ２１１に知らせることができる。さらに、この結果構造は、メッセージの終りが送信ＩＦＥによって信号送信されたかどうかを識別するよう、メッセージの終りフラグを含み得る。
【００８８】
この発明の他の特徴に従うと、結果構造６５１はトークン値をさらに含み得る。ダイアログ受信通知機構はこのトークン値を利用することによって通知方式をカスタマイズし得る。たとえば、クライアントは、トークン値（たとえば３２ビットトークン）を用いることによって、複数の通信回線を単一のＣＩＡ論理ダイアログを介して多重化し得る。
【００８９】
属性ビットまたはフィールド６４２は、クライアントによって、データ転送のための特定の受信意味規則を選択するため用いられる。たとえば、「自動受信」属性は、以下にさらに詳細に記載されるように、自動受信意味規則を可能化するよう選択され得る。「メッセージの終り」フラグ（ＥＯＭ）は、ｄ＿ｒｃｖオペレーションが受信メッセージを用いるべきかまたは部分受信意味規則を受信すべきかを示す。
【００９０】
ステップ７２０において、ＩＦＥ２１１はＣＣＢ６１１を受信してそれを実行する。通常、この結果、ＩＦＥ２１１は受信制御ブロックＲＣＢ６３３を構築する。一般に、ＲＣＢ６３３はＣＣＢ６１１において送られるｄ＿ｒｃｖパラメータを含む（ただしｄ＿ｒｃｖオプコードは除く）。受信ＩＦＥ２１１はＲＣＢ６３３をネットワークパケットにて送信ＩＦＥ２１３に送信する（ステップ７３０）。受信ＩＦＥ２１１は、送信ＩＦＥ２１３における利用可能なＲＣＢ場所の宛先アドレスを知っている。この情報はダイアログ連想中に与えられたものである。これによって、受信ＩＦＥ２１１は、ＲＣＢデータおよび送信ＩＦＥ２１３におけるその目標場所（つまり宛先アドレス）とともにＲＣＢ６３３を含むネットワークパケットを構成することができる。
【００９１】
送信要求に対し、送信クライアント６０３は、ｄ＿ｓｅｎｄプリミティブを識別するｄ＿ｓｅｎｄＣＣＢ６１３を構築する（ステップ７４０）。ｄ＿ｓｅｎｄＣＣＢ６１３へのリファレンスが送信ＩＦＥ２１３に送られる。下の表には、例示的ｄ＿ｓｅｎｄプリミティブが、その主なパラメータおよびそれらの機能とともに記載される：
【００９２】
【表２】
2004005661.tif 000004
【００９３】
オプコードは、データ送信オペレーションに対するｄ＿ｓｅｎｄプリミティブを識別する。ダイアログハンドル６６１は、データ送信オペレーションに関与する局所ダイアログオブジェクトを識別する。収集リストパラメータ６６３は、原始データを検索するための０個以上のバッファ（メモリ領域）を特定する収集リストである。
【００９４】
属性ビットまたはフィールド６６２（オプションである）は、クライアントによって、データ転送のための特定の送信意味規則を選択するため用いられる。たとえば、メッセージの終りフラグ（ＥＯＭ）は、原始データの最後のバイトの転送と合致するＥＯＭを送信ＩＦＥが示すべきか否かを示す。結果トークンパラメータは、受信側のＣＩＡ＿ＲＣＶ＿ＲＥＳＵＬＴ６５１内に送られるべきトークン値を識別する。送信結果６６４は、どれだけのデータが送信されたかを判断するために送信クライアント６０３が見るものである。送信結果６６４は送信ＩＦＥ２１３によって更新される。
【００９５】
バイトストリーム指向型トラフィックの場合、ＥＯＭ区切り文字は必要ではなく、ＥＯＭフラグはセットされない。メッセージ指向型トラフィックの場合では、ＥＯＭフラグはセットされる。このようにして、ＣＩＡ１０００はメッセージ指向型トラフィックおよびバイトストリーム指向型トラフィックの両方をサポートし得る。この発明のさらなる特徴に従うと、図１２を参照して以下にさらに詳細に記載されるように、「部分送信」および「部分受信」メッセージをＣＩＡ１０００においてさらに用いることによって、メッセージ指向型トラフィックおよびバイトストリーム指向型トラフィックの両方のサポートを最適化し得る。
【００９６】
ステップ７５０において、ＲＣＢ６３３が到着すると、送信ＩＦＥ２１３は、ダイアログ連想中にダイアログオブジェクト５０３に関連付けられるＲＣＢ６３３のための所定の領域に、ＲＣＢ６３３を記憶させる。ステップ７４０およびステップ７５０は非同期であり、任意の順序で実行され得る。換言すれば、以下において図９を参照してさらに記載されるように、ステップ７５０は、さらに、ＣＣＢ６１３がステップ７４０にて構築される時間より前にＲＣＢ６３３を記憶し得る。
【００９７】
説明を明確にするために、図６Ａおよび図６Ｂは１つのＲＣＢ６３３のみを示す。しかしながら、図１０を参照して下により詳細に記載されるように、データに対する複数の送信および受信要求が未処理であり得る。複数の未処理のＲＣＢに対応するため、各ＲＣＢは送信ＩＦＥ２１３にて待ち行列（図示せず）に入れられる。
【００９８】
ステップ７６０において、送信ＩＦＥ２１３は、待ち行列に入れられたＲＣＢと未処理のｄ＿ｓｅｎｄプリミティブとの間に合致がなされるかを判断する。合致は、未処理のＲＣＢおよびｄ＿ｓｅｎｄプリミティブが共通の論理ダイアログを識別したときになされる。図６Ａおよび図６Ｂに示される例では、ＲＣＢ６３３およびｄ＿ｓｅｎｄプリミティブ６１３がともに論理ダイアログ５２０を参照するように存在する場合に合致がなされる。
【００９９】
ステップ７７０では、データを転送するために、データを記憶するための受信記述子（たとえばメモリアドレス）に原始データを結合するネットワークパケットを構築する。送信ＩＦＥ２１３は、ＣＣＢ６１３のｄ＿ｓｅｎｄプリミティブにおいて与えられる収集リストパラメータ６６３によって規定されるメモリ領域（たとえばバッファ６２３）からデータを集める（たとえば原始データをコピーする）。受信メモリアドレス（バッファ６２１）は、合致するＲＣＢ６３３から、特に分散リストパラメータ６４４から判断される。データがメッシュ２０２を介して転送されるネットワーク化環境では、下位のネットワーク化層（図示せず）がネットワークパケットを形成する。このネットワークパケットは、送信ＩＦＥ２１３によって与えられる結合されたデータおよび受信側メモリ宛先アドレスを含む。
【０１００】
ステップ７８０において、ステップ７７０にて構築されたネットワークパケットは受信ＩＦＥ２１１に送信される。受信ＩＦＥ２１１はそのネットワークパケットからのデータをバッファ６２１に直接書込む（ステップ７９０）。このライトオンリオペレーションでは、データコピーは全く行なわれる必要がない。ＣＩＡ１０００は、アドレスを検証する任意のタイプの範囲検査をサポートし得る。受信ＩＦＥ２１１は、ネットワークパケット内の記述子情報を用いることによって、書込データにより修飾されるべきアドレスの範囲が許可されることを検証することができる。
【０１０１】
ステップ７９３において、送信ＩＦＥ２１３はｒｃｖ＿ｒｅｓｕｌｔ６７２およびＲＣＢ完了指示を送信する。データ転送、結果転送およびＲＣＢ完了指示は、同じネットワークパケットにて送られ得る。ステップ７９５において、受信ＩＦＥ２１１は、ｄ＿ｒｃｖプリミティブが完了していることを受信クライアント６０１（アプリケーション５１０および／またはシステム２１２）に通知する通知（「受信完了」指示とも称される）を送信する。
【０１０２】
ステップ７７０〜７９０について、あるネットワーク化環境に言及しながら説明する。代替的に、受信および送信クライアントが同じメモリ空間を共有する場合には、送信ＩＦＥ２１３（または他のシステム構成要素）は、メモリコピー動作を用いながら、集められたデータをバッファ６２３からバッファ６２１へ直接転送し得る。
【０１０３】
したがって、下位の物理内部接続技術に頼らないトランスポートレベルのデータ通信サービスが提供される。換言すれば、ＣＩＡ１０００インターフェイス（ここに記載されるメッセージシステムならびにＣＩＡプリミティブおよび意味規則の組）は、下位のネットワーク化層およびプロトコル、たとえば、ＡＴＭ、ＦｉｂｅｒＣｈａｎｎｅｌ、ＳｅｒｖｅｒＮｅｔＴＭなどに依存することなく通信を行なうクライアント間にて動作する。ＣＩＡプルデータモデル通信を用いると、データは識別された受信メモリアドレス空間に送信されるにすぎない。予期されないデータの中間バッファ処理を全く必要としないので、フロー制御問題がなくなる。このＣＩＡプルデータモデルによって、トランスポートレベルでの全体のレイテンシが低減され、ネットワーク伝送および配信システムの信頼性における改善点が増強される。
【０１０４】
加えて、複数の、全二重の、信頼性のある仮想回線接続（つまり多重論理ダイアログ）が各ノードごとに与えられ得る。複数のダイアログオブジェクトが１つのノードを参照し得る。複数の未処理のＣＩＡプリミティブオペレーションが各ダイアログにて許される。ダイアログはバイトストリーム指向型データまたはメッセージ指向型データを処理し得る。それらに限定されるものではないが、分散および収集サポート、アーリー・ファー・エンドおよびファー・エンドの送信サービスクラス、自動繰返し受信オプション、ｓｅｎｄ／ｒｃｖ長に対して実質的に制限が全くない部分送信および受信メッセージ、ならびに複数ダイアログ優先順位を含む、ダイアログオペレーションおよび特徴について、以下にさらに詳細に説明する。
【０１０５】
３．収集
ダイアログ送信プリミティブ（ｄ＿ｓｅｎｄ）によって原始データが送信される。この原始データは複数のメモリ領域から１つのバイトストリームに集められ得る。ｄ＿ｓｅｎｄプリミティブにおける「収集リスト」パラメータは、データ収集を実行するため用いられる要素の順序付けされたリストであり得る。各要素は、そこからデータを集めるユーザ特定メモリ領域（たとえばバッファ）を識別する。たとえば、順序リストにおける各要素は、あるデータ要素に対するメモリアドレスおよびメモリ長を特定する。次いで、送信ＩＦＥが、各データ要素を、順序付けられたリストパラメータによって特定されるシーケンスで集める。
【０１０６】
この発明に従うと、異なるタイプのｄ＿ｓｅｎｄプリミティブの各々が、未処理のｄ＿ｓｅｎｄプリミティブ間における原始メッセージ領域の共有を可能にする。ｄ＿ｓｅｎｄプリミティブは原始メモリ領域を（一時的にさえも）変更しない。
【０１０７】
４．分散
ダイアログ受信プリミティブ（ｄ＿ｒｃｖ）は原始データが複数の別個のメモリ領域に受入れられ分散されるのを可能にする。ｄ＿ｒｃｖプリミティブにおける「分散リスト」パラメータは、データを分散するために用いられる要素の順序付けされたリストであり得る。各要素は、データを分散すべきユーザ特定メモリ領域（たとえばバッファ）を識別する。たとえば、分散リスト内の各要素はデータ要素に対するメモリアドレスおよびメモリ長（アドレス／長さの対）を特定する。
【０１０８】
同様に、「バッファ分散」プリミティブを伴うｄ＿ｒｃｖが発行されると、さらなる「分散リスト」フィールド（「領域リスト」とも称される）を含む対応の受信制御ブロック（ＲＣＢ）構造が生ずる。この分散リストフィールドは「分散リスト」パラメータ、つまり、データを分散するために用いられる要素（たとえばアドレス／長さの対）の順序付けられたリストを記憶する。
【０１０９】
次いで、送信ＩＦＥが、「分散リスト」パラメータにおける各要素によって特定される分散されたメモリ領域内にデータを結合する。このようにして、受信されたメッセージは、分散リストに示される長さおよびタイプに従ってメモリ領域（またはバッファプール内の自由なバッファ）内に受信ＩＦＥによって分散される。分散リストは任意の数の要素をサポートし得る。バッファプールオペレーションでは、現在の分散リスト要素が満足される前に自由なバッファが満たされると、別の自由なバッファを用いて分散リストのその部分を完了させる。結果構造は、バッファマッピングへの受信データを記述するバッファリストを含む。
【０１１０】
５．サービスの送信クラス（アーリー・ファー・エンドおよびファー・エンド）
図６および図７Ａ〜７Ｂを参照して上で言及したように、論理ダイアログは、そのダイアログが関連付けられると特定化されるサービス属性の送信クラスを有する。アーリー・ファー・エンドおよびファー・エンドというサービスの送信クラスが与えられる。これら２つのサービスの送信クラスについて、例示的なプロセス流れ図（図８）を参照しながらさらに詳細に説明する。
【０１１１】
図８は、データ要求（受信要求８０１）および送信要求（送信要求８０３）を処理するためのＣＩＡ処理ステップを示す流れ図である。図８は、図６および図７Ａ〜図７Ｂの例示的ＣＩＡ通信において上で説明された処理ステップ７１０〜７９７を示す。したがって、これら処理ステップの説明は繰返さない。
【０１１２】
さらに、図８は、アーリー・ファー・エンドおよびファー・エンドのサービスにおいて送信完了を示すため用いられるステップ８１０〜８３０を示す。ユーザがアーリー・ファー・エンドのサービスを要求すると、送信ＩＦＥ２１３は「送信完了」指示を送信クライアント６０３に送信する（ステップ８１０）。ＩＦＥ２１３がもはや局所送信クライアント資源（任意の伝送再試行を含む）を用いていない限り、送信ＩＦＥ２１３は、ネットワークパケットが送信側にて構築される前、同時または後に、「送信完了」指示を送信クライアント６０３に送信し得る。
【０１１３】
ステップ８２０において、ユーザがファー・エンドのサービスを要求すると、受信ＩＦＥ２１１は「受信完了」指示が発行されるとおおよそ同時または後に送信ＩＦＥ２１３に「肯定応答」パケットを送信する。次いで、送信ＩＦＥ２１３は「肯定応答」パケットの受信に応答して送信クライアント６０３に「送信完了」指示を送信する（ステップ８３０）。
【０１１４】
これら２つのサービスクラス、アーリー・ファー・エンドおよびファー・エンドは、さまざまな整合性の度合をサポートし得る。データの損失が非常に稀であるかまたは無視される場合には、アーリー・ファー・エンドで十分である。したがって、アーリー・ファー・エンドのサービスは、メッシュのインフラストラクチャが極めて堅牢であるか、またはダイアログがデータグラムモードで動作している場合に適切である。対照的に、ファー・エンドのサービスの場合、「送信完了」指示はデータが成功裡に受信されたことを保証する。ＣＩＡインターフェイスの遠隔側は、ＣＩＡインターフェイスの局所側とは異なる送信サービスクラスを有し得る。
【０１１５】
局所ＩＦＥは遠隔ＩＦＥからの明示的な肯定応答を必要としないため、アーリー・ファー・エンドはファー・エンドよりもよりよく実行される。これによって、局所的に開始される送信オペレーションがより早期に完了しその内部接続にわたってのトラフィックの量を低減することができる。
【０１１６】
ダイアログに基づくフロー制御は各送信サービスクラスごとに省略される。アーリー・ファー・エンドおよびファー・エンドのサービスクラスの場合、受信端点がデータ転送を要求するまで、ダイアログは論理的に後方にプレッシャーを受ける。
【０１１７】
６．送信および受信要求の順序付け
図８に関して説明したデータ転送の例においては、受信要求８０１が送信要求８０３に先行した。一般に、論理ダイアログのための送信および受信要求は、任意の順序でクライアントと通信することによって、発行することが可能である。図９は、図８と同様のプロセスフロー図を示しているが、図９では、送信要求８０３が受信要求８０１の前に発行されるところが、図８とは異なる。
【０１１８】
７．複数の未処理の送信および受信要求
本発明のさらなる特徴に従えば、ＣＩＡ１０００は、複数の未処理の送信および受信要求を処理することができる。上述のように、送信ＩＦＥは、未処理のＲＣＢおよびｄ＿ｓｅｎｄプリミティブを、待ち行列に入れる。送信ＩＦＥ内の一致判定（ｍａｔｃｈｅｒ）モジュールは、いつ突合せがなされるかを決定する。好ましくは、ファーストイン・ファーストアウト型の待ち行列管理方法が使用されて、待ち行列の先頭におけるＲＣＢおよびｄ＿ｓｅｎｄプリミティブが、最初に突合せられる。
【０１１９】
複数のダイアログ送信プリミティブ（ｄ＿ｓｅｎｄ）を、ダイアログに対してポストすることが可能である。同じダイアログにポストされるｄ＿ｓｅｎｄプリミティブは、通常、それらがそのダイアログにポストされたのと同じ順序で完了する。
【０１２０】
複数のダイアログ受信プリミティブ（ｄ＿ｒｃｖ）を、ダイアログに対してポストすることが可能である。ｄ＿ｒｃｖプリミティブは、通常、それらがダイアログにポストされたのと同じ順序で完了し、また、合致するｄ＿ｓｅｎｄプリミティブがポストされたのと同じメッセージ順で完了する。順序から外れたｄ＿ｓｅｎｄプリミティブおよびｄ＿ｒｃｖプリミティブを処理する、付加的な機能を設けることも可能である。
【０１２１】
図１０は、ＣＩＡプルデータモデル内の内部待ち行列管理および突合せが、どのように複数の未処理要求を処理するのかを示す例を図示する、プロセスフロー図である。この場合、２つの受信要求１００１，１００２および、２つの送信要求１０１１，１０１２が、発行される。
【０１２２】
８．自動受信および自動送信
ＣＩＡプリミティブ１２００のセット内には、「自動受信（Ａｕｔｏ　Ｒｅｃｅｉｖｅ）」プリミティブ（ＲｃｖＡｕｔｏ）もまた設けられる。ＲｃｖＡｕｔｏプリミティブは、ダイアログ受信プリミティブの、自動的に繰返す変形、たとえば、自動受信属性ビットセットを有する、上述のｄ＿ｒｃｖプリミティブである。ＲｃｖＡｕｔｏプリミティブは、繰返しデータ受信要求を発行することができるようにする。データはそこで、自動反復式に、ユーザ指定メモリ領域内に受信される。
【０１２３】
ＲｃｖＡｕｔｏプリミティブは、大量の受信待ち時間を排除する一方で、ダイアログ上のボトルネックを取除くのに有益である。受信側のクライアントは、ダイアログに対して単一のＲｃｖＡｕｔｏＣＣＢをポストする。受信ＩＦＥは、そのＲｃｖＡｕｔｏＣＣＢに対応して単一のＲＣＢを生成して、それを送信ＩＦＥに転送する。送信ＩＦＥはその後、その単一のＲＣＢを使用して、データを繰返し送信する。その後、受信ＩＦＥは、そのＲＣＢによって特定された同じメモリ領域に、入来するデータパケットを連続的に受信する。これらのデータパケットは、後述するように、完全なおよび／または部分的なメッセージを含むことが可能である。ダイアログが自動受信を使用してデータを転送する場合、多くの「受信完了（Ｒｅｃｅｉｖｅ　Ｃｏｍｐｌｅｔｅ）」表示が、同じＣＣＢに対して表示され得る。ある意味で、単一のＲｃｖＡｕｔｏプリミティブが、何度も「完了する」のである。
【０１２４】
自動受信オペレーションは、リアルタイムマルチメディア等の等時性データストリームを伝送するのに、特に有用である。「ストック−ティッカ（ｓｔｏｃｋ−ｔｉｃｋｅｒ）」等の、連続更新が要求されるアプリケーションを、自動反復式に更新を書込むのに使用することも可能である。
【０１２５】
図１１は、自動受信プリミティブオペレーションの一例を示す、メッセージフロー図である。自動受信要求１１００が、２つの連続する送信要求１１０１、１１０２を完了するものとして示されている。
【０１２６】
データをバッファプール内に自動的に受信するためのさらなる変形を、下に、バッファプールオペレーションに関して説明する。特定的には、ｄ＿ｒｃｖの自動反復式の変形が、バッファプール内にのみ受信するために提供される。ｄ＿ｒｃｖの自動反復式の変形が、バッファプールおよびユーザ指定メモリ領域の任意の組合せに分散するために提供される。これについては、後述する。「自動受信」オペレーションを、プルデータモデル内のプッシュデータモデルをシミュレートして、さらに大量の受信待ち時間を排除するのに、使用することが可能である。
【０１２７】
同様に、ＣＩＡプリミティブ１２００のセット内に、ａｕｔｏ＿ｓｅｎｄプリミティブ（任意選択）を提供することも可能である。このａｕｔｏ＿ｓｅｎｄプリミティブは、ａｕｔｏ＿ｓｅｎｄ属性ビットセットを有するダイアログ送信プリミティブの、自動的に繰返す変形である。ａｕｔｏ＿ｓｅｎｄプリミティブは、反復式の送信要求を発行することができるようにする。同じソース領域のデータ内のデータを、その後、複数のデータ受信要求を満たすように、自動反復式に送信することが可能である。
【０１２８】
９．部分メッセージ（部分受信および部分送信）
ＣＩＡ１０００は、メッセージ指向型およびバイトストリーム指向型のデータ転送意味規則をサポートする。ｄ＿ｒｃｖプリミティブビットは、ＥＯＭと称される属性ビットを有する。このＥＯＭビットがアサートされると、メッセージの終わりを表示するインジケータが送信側から受信されたときに、受信が完了する。そのＥＯＭ表示を受信する前に、分散リストによって示されるバッファ領域のキャパシティを越えて到着するデータは、送信側によって廃棄される。したがって、過剰なデータが送られることは決してない。しかし、超過データの損失を受信側に報告することは可能である。
【０１２９】
ｄ＿ｒｃｖプリミティブは、ＥＯＭビットがアサートされていない場合には、分散リストによって示されたデータ領域が満杯になったとき、または、ＥＯＭが受信されたときに、受信が完了する。ＥＯＭビットがアサートされていないｄ＿ｒｃｖプリミティブは、部分受信とも称される。
【０１３０】
送信オペレーションについて見ると、送信オペレーションは、データの転送が終わったときに完了する。ｄ＿ｓｅｎｄプリミティブは、ＥＯＭと称される属性ビットを有する。このｄ＿ｓｅｎｄ内のＥＯＭビットがアサートされると、メッセージの終わりが、ソースデータ内の最終ビットと同時に送信される。送信ＩＦＥは、合致するＲＣＢおよびｄ＿ｓｅｎｄＣＣＢ内に特定されたＥＯＭ属性を使用して、正しいｄ＿ｒｃｖ意味規則を実現する。
【０１３１】
ｄ＿ｓｅｎｄプリミティブのＥＯＭビットがアサートされていない場合、上記合致するＲＣＢは、そのＲＣＢが受信の一部でありかつ分散された領域が埋められているときにのみ、完了する。複数のＲＣＢが未処理である場合があるため、受信の一部が完了すると、データ転送は、次に使用可能なＲＣＢを使用して続けられる。ＥＯＭビットがアサートされていないｄ＿ｓｅｎｄプリミティブは、部分送信または送信の一部とも称される。
【０１３２】
図１２は、部分送信プリミティブ（ＳｅｎｄＰａｒｔｉａｌ１２０１）および「メッセージの終わり」ＥＯＭ送信プリミティブ（ＳｅｎｄＥＯＭ１２０２）を含む、データ転送オペレーションの一例を示す、プロセスフロー図である。この例においては、受信データ要求１２００は、部分送信プリミティブ１２０１およびＥＯＭ送信プリミティブ１２０２の組合せよりも長い全長でポストされる。したがって、受信要求１２００は、送信プリミティブ１２０１および１２０２の両方に関連するデータ転送が起きない限り、完了しない。
【０１３３】
本発明のさらなる特徴に従えば、ＳｅｎｄＰａｒｔｉａｌ１２０１の「ファー・エンド」の完了動作は、ＳｅｎｄＰａｒｔｉａｌプリミティブの完了を優先するように修正される。ＲｃｖＭｓｇは、ＳｅｎｄＥＯＭが送られるまで完了することができないため、ＳｅｎｄＰａｒｔｉａｌの「ファー・エンド」の完了は、不合理に遅延される場合がある。このＳｅｎｄＰａｒｔｉａｌに対する遅延された完了動作は、「アーリー・ファー・エンド」（「パーシャル・ファー・エンド（Ｐａｒｔｉａｌ−Ｆａｒ−Ｅｎｄ）」とも称される）の態様ですべてのＳｅｎｄＰａｒｔｉａｌを強制的に完了させることによって、許可されないようにされる。これを図１２に示す。
【０１３４】
図１３は、部分受信プリミティブ（ＲｃｖＰａｒｔｉａｌ）と部分送信プリミティブ（ＳｅｎｄＰａｒｔｉａｌ）との組合せを含む、データ転送オペレーションの一例を示す、プロセスフロー図である。部分受信要求１３００およびＲｃｖＸ（）要求１３０３は、部分送信１３０１およびＥＯＭ送信１３０２によって完了されるものとして示されている。
【０１３５】
ＥＯＭなしのｄ＿ｓｅｎｄ（ｄ＿ｓｅｎｄ　ｗ／ｏ　ＥＯＭ）およびＥＯＭなしのｄ＿ｒｃｖ（ｄ＿ｒｃｖ　ｗ／ｏ　ＥＯＭ）によって特定される転送長さは、互いに対して直接的な関係を有してはいない。すなわち、メッセージ内のデータは、バイトストリームとして処理される。送信側によってｄ＿ｓｅｎｄの部分送信の変形を使用して作成されるメッセージの中間部分は、受信側のクライアントによって区別することはできない。ｄ＿ｒｃｖの部分受信変形を使用して受信側によって受信されるメッセージの中間部分は、送信側クライアントによっては区別することができない。
【０１３６】
１０．ダイアログ優先順位属性
ダイアログは、ダイアログ優先順位属性を有する。多数の（たとえば１５の）ダイアログ優先順位が存在し得る。複数の合致が存在する場合、送信ＩＦＥは、このダイアログ優先順位を使用して、競合するダイアログを処理する順序を決定する。公平性は、インターフェイスの送信側において裁定され、また、ダイアログの優先順位内で総当たりで裁定される。ダイアログの優先順位は、論理ダイアログの各側において個別に送信することが可能である。ダイアログ優先順位属性は、ダイアログオブジェクトの一部として記憶することもでき、または、ｄ＿ｓｅｎｄプリミティブに対するパラメータとして特定することもできる。（たとえば、保証されたダイアログ帯域幅等の、）他の品質のサービス特徴もまた、提供することが可能である。
【０１３７】
５．ＣＩＡ管理
図１Ａに関連して説明したように、通信内部接続アーキテクチャ１０００はさらに、ＣＩＡ管理サービス（ＣＩＡ−ＭＳ）１３００を含む。ＣＩＡ管理サービス１３００は、ＣＩＡクライアント間で、共用されるＣＩＡオブジェクトおよび共通のサービスの調整を行なう。たとえば、ＣＩＡクライアントは、ＩＦＥおよびＮＯＤＥオブジェクトを共用することが可能である。というのも、個々のＣＩＡクライアントが、同じＮＯＤＥオブジェクトに関連する同じ局所ＩＦＥ上に作成された、複数のダイアログを有し得るためである。
【０１３８】
ＣＩＡ−ＭＳ１３００によって提供されるサービスは、ノードおよびダイアログの確立／終了および管理に関係する。ＩＦＥ、ノードおよびダイアログオブジェクトの確立、終了および管理に関する、種々のＣＩＡプリミティブのオペレーションについて、以下に説明する。
【０１３９】
ａ．ノードプリミティブおよび通知
ノード作成（ｎ＿ｃｒｅａｔｅ）プリミティブは、ＣＩＡ−ＭＳ１３００によって、ノードオブジェクトを作成するのに使用される。このプリミティブは、ｎｏｄｅ＿ｉｄ（たとえば、ＭＡＣｉｄ）および、そのノードオブジェクトが関連する（遠隔環境における）ｎｏｄｅ＿ｉｎｔｅｒｆａｃｅを示す。もしノードオブジェクトがうまく作成されれば、そのノードオブジェクトに一意のハンドルが返される。このノードのハンドルは、特定のＩＦＥ内において一意であるが、複数のＩＦＥにわたって必ずしも一意であるとは限らない。
【０１４０】
ノード破壊プリミティブ（ｎ＿ｄｅｓｔｒｏｙ）は、ノードオブジェクトを破壊するのに使用される。このプリミティブは、ノードのハンドルを示す。このノードオブジェクトに関連する未処理のプリミティブ（たとえば、この同じノードに関連するダイアログに対するｄ＿ｓｅｎｄ／ｄ＿ｒｃｖプリミティブ）は、どれも取消される。このノードオブジェクトに関連していたバッファプール、プールマネージャおよびダイアログオブジェクトもまた、破壊される。
【０１４１】
ノード再始動通知プリミティブ（ｎ＿ｎｏｔｉｆｙ＿ｒｅｓｔａｒｔ）は、遠隔ＩＦＥに対して局所ＩＦＥが再始動したことを通知するために発行される。このプリミティブは、通知されるべき遠隔ＩＦＥのノードハンドルを示す。局所ＩＦＥが（下に説明するｉ＿ｒｅｓｅｔプリミティブを介して）リセットされるたびに、局所ホストは、このプリミティブを、接続内の他のすべてのＩＦＥに対して発行せねばならない（これは、先に関連付けられたことのあるノードのみに限定することもできる）。遠隔システムは、対応の通知を使用して、リセットされた遠隔ＩＦＥに対してポストしていた、すべての先の動作（すなわち、未処理のプリミティブ）を終了させる。
【０１４２】
通知処理は、ホストの作業環境と相関関係にある。ノード再始動通知（ＣＩＡ＿ＮＯＤＥ＿ＲＥＳＴＡＲＴ＿ＮＯＴＩＦＩＣＡＴＩＯＮ）が発行されるが、これは、遠隔ＩＦＥがこのシステムに対してｎ＿ｎｏｔｉｆｙ＿ｒｅｓｔａｒｔを発行したことを示す。この通知は、再始動を発行した遠隔ＩＦＥの、ｎｏｄｅ＿ｉｄおよびｎｏｄｅ＿ｉｎｔｅｒｆａｃｅを含む。
【０１４３】
ノード挨拶プリミティブ（ｎ＿ｇｒｅｅｔ）は、ＩＦＥ間の第１のレベルの挨拶として使用される。このプリミティブは、挨拶されるべき遠隔ＩＦＥのノードハンドルと、ユーザレベルの管理ダイアログとして使用されるべきダイアログのダイアログハンドルと、不調な挨拶を検知するのに使用される一意性値とを示す。このプリミティブは、遠隔システム上に通知（ＣＩＡ＿ＮＯＤＥ＿ＧＲＥＥＴ＿ＮＯＴＩＦＩＣＡＴＩＯＮ）（ｋｉｎｄ＿ａｓｓｏｃｉａｔｅ＝ＦＡＬＳＥ）を生じさせるために使用される。１ノードオブジェクト当たり、最高で１つのｎ＿ｇｒｅｅｔプリミティブを発行することができる。そのプリミティブの初期化は、ｎ＿ｃｒｅａｔｅプリミティブがそのノードオブジェクトに対して発行された後にのみ、有効である。
【０１４４】
ノード関連付けプリミティブ（ｎ＿ａｓｓｏｃｉａｔｅ）は、ノードからノードへの通信を確立するのに使用される、ＩＦＥ間の第２のレベルの挨拶として使用される。このプリミティブは、関連付けられるべき遠隔ＩＦＥのノードハンドルおよび、遠隔ＩＦＥから受信された挨拶の内容を示す。このプリミティブを使用して、遠隔システム上にＣＩＡ＿ＮＯＤＥ＿ＧＲＥＥＴ＿ＮＯＴＩＦＩＣＡＴＩＯＮ（ｋｉｎｄ＿ａｓｓｏｃｉａｔｅ＝ＴＲＵＥ）を生じさせる。１ノードオブジェクト当たり、最高で１つのｎ＿ａｓｓｏｃｉａｔｅプリミティブを発行することができる。プリミティブの初期化は、ｎ＿ｇｒｅｅｔプリミティブがこのノードオブジェクトに対して発行され、かつ、挨拶表示が遠隔ノードから受信された後にはじめて、有効となる。
【０１４５】
ノード結合プリミティブ（ｎ＿ｂｏｕｎｄ）は、遠隔ノードがノード関連付けを完了したこと（すなわち、局所ノードがｋｉｎｄ＿ａｓｓｏｃｉａｔｅ＝ＴＲＵＥを有する挨拶を受信したこと）を局所ＩＦＥに対して表示するのに使用される。このプリミティブは、ノードの関連付けを完了した遠隔ＩＦＥのノードハンドルを示す。ノードオブジェクト当たり最高１つのｎ＿ｂｏｕｎｄプリミティブを発行することが可能である。このプリミティブの初期化は、ｎ＿ａｓｓｏｃｉａｔｅプリミティブがそのノードオブジェクトに対して発行され、かつ、挨拶表示（ｋｉｎｄ＿ａｓｓｏｃｉａｔｅ＝ＴＲＵＥ）が遠隔ノードから受信された後にのみ、有効となる。
【０１４６】
ノード挨拶通知（ＣＩＡ＿ＮＯＤＥ＿ＧＲＥＥＴ＿ＮＯＴＩＦＩＣＡＴＩＯＮ）は、遠隔ＩＦＥがこのシステムに対して、ｎ＿ｇｒｅｅｔまたはｎ＿ａｓｓｏｃｉａｔｅプリミティブを発行したことを示す。この通知は、挨拶を発行した遠隔ＩＦＥの、ｎｏｄｅ＿ｉｄおよびｎｏｄｅ＿ｉｎｔｅｒｆａｃｅを示す。これはまた、ブール値（ｋｉｎｄ＿ａｓｓｏｃｉａｔｅ）によって、遠隔ＩＦＥがｎ＿ｇｒｅｅｔまたはｎ＿ａｓｓｏｃｉａｔｅプリミティブを発行したかどうかを示す。この通知はまた、ユーザレベルの管理ダイアログおよびノードの関連付けを完了するのに使用される、挨拶の内容もまた示すが、これについては図１５に関連して下にさらに詳細に説明する。
【０１４７】
ノード障害通知（ＣＩＡ＿ＮＯＤＥ＿ＦＡＵＬＴ＿ＮＯＴＩＦＩＣＡＴＩＯＮ）は、ノードオブジェクトに関連する遠隔ＩＦＥとの通信が失われたことを示すのに使用される。この通知は、ｎｏｄｅ＿ｉｄ、ｎｏｄｅ＿ｉｎｔｅｒｆａｃｅ、ＩＦＥに特有の理由コード、および、コンテキストパラメータを示す。このｎｏｄｅ＿ｉｄおよびｎｏｄｅ＿ｉｎｔｅｒｆａｃｅ値は、失敗したＮＯＤＥを表わす。理由コードは、ノード障害の原因を診断するのを助けるのに使用することができる。コンテキストパラメータ値は、このＩＦＥのインスタンスを参照する、ホストの定義値である。このコンテキスト値は、ｉ＿ｒｅｓｅｔプリミティブによってＩＦＥに渡される。
【０１４８】
ｂ．ダイアログの確立、終了、および通知
１．タイプ１
１実施例においては、ＣＩＡクライアントは、タイプ１のダイアログ確立サービスに従って論理ダイアログを確立するために、選択されたＣＩＡプリミティブを使用する。タイプ１のダイアログ確立サービスを使用するクライアントは、ｄ＿ｃｒｅａｔｅ、ｄ＿ａｓｓｏｃｉａｔｅ、ｄ＿ｓｈｕｔｄｏｗｎ、ｄ＿ｄｅｓｔｒｏｙ、ｄ＿ｚｉｎｆｏ、および、ｄ＿ｉｎｔｅｒｌｏｃｋといったＣＩＡプリミティブを利用して、ダイアログオペレーションを実行する。最初に、これら各ダイアログプリミティブのパラメータおよびオペレーションを簡潔に要約することが有益であろう。
【０１４９】
ダイアログ作成プリミティブ（ｄ＿ｃｒｅａｔｅ）は、局所ＩＦＥ上にダイアログオブジェクトを作成するために発行される。ｄ＿ｃｒｅａｔｅプリミティブは、新しく作成されたダイアログオブジェクトに対してダイアログ障害が示されたときに使用されねばならない、ダイアログ記述子を示す。他のダイアログ制御オプションを含むことも可能であるが、これは、優先順位、送信のサービスのクラス、ダイアログ障害オプションが動作可能／動作不能にされるかどうか、送信取消し意味規則、および、ダイアログ障害通知情報を含み得る。ｄ＿ｃｒｅａｔｅプリミティブはまた、このダイアログの任意の１時点においてポストされる可能性のある、未処理のｄ＿ｒｃｖプリミティブの数を表わすカウントを提供する。ｄ＿ｒｃｖプリミティブのＡＵＴＯ変形（たとえば、ＲｃｖＡｕｔｏ等）を使用するダイアログに対しては、このカウントは通常、１であるべきである。ダイアログオブジェクトがうまく作成されれば、このダイアログオブジェクトに対して一意のダイアログハンドルが返され、ダイアログ関連情報（すなわち、ダイアログの内容）もまた返される。ダイアログハンドルは、特定のＩＦＥ内において一意であるが、複数のＩＦＥにわたって必ずしも一意であるとは限らない。
【０１５０】
ダイアログ関連プリミティブ（ｄ＿ａｓｓｏｃｉａｔｅ）は、局所ダイアログオブジェクトを遠隔ダイアログオブジェクトに関連付けるのに使用される。このｄ＿ａｓｓｏｃｉａｔｅプリミティブは、ダイアログハンドル、ノードハンドル、および遠隔ダイアログの内容を表わす。指示されるダイアログは、既に関連付けられていてはならない。関連付けがうまく完了したかどうかを示すステータスが返される。
【０１５１】
ダイアログ停止プリミティブ（ｄ＿ｓｈｕｔｄｏｗｎ）は、ダイアログに関連する未処理のプリミティブを、優雅に終了させるために発行される。このプリミティブは、ダイアログハンドルを示す。このプリミティブは、指示されたダイアログに関連するすべての未処理のプリミティブの優雅な取消しを起動する。このプリミティブは、指示されたダイアログに関連する他のすべてのプリミティブが完了を知らせるまで、完了を知らせることはない。
【０１５２】
ダイアログ破壊プリミティブ（ｄ＿ｄｅｓｔｒｏｙ）は、ダイアログオブジェクトを破壊するために発行される。ｄ＿ｄｅｓｔｒｏｙプリミティブは、ダイアログハンドルを示す。このプリミティブは、ダイアログを優雅にクローズすることはない。なぜなら、指示されたダイアログに関連する未処理のｄ＿ｒｃｖプリミティブに対して結合されているバッファプール資源が、正しく返されない場合があるためである。ｄ＿ｄｅｓｔｒｏｙプリミティブは、（このプリミティブ自身以外の）未だダイアログにポストされているすべてのプリミティブに対して取消されたステータスの表示をして、完了ルーチンを呼出す。指示されたダイアログオブジェクトは、削除される。
【０１５３】
ダイアログ情報プリミティブ（ｄ＿ｚｉｎｆｏ）は、ｄ＿ｃｒｅａｔｅ結果パラメータから（後の関連付けのために）必要とされるダイアログ情報を検索するために発行される。ＣＩＡダイアログ障害通知ＣＩＡ＿ＤＩＡＬＯＧ＿ＦＡＵＬＴ＿ＮＯＴＩＦＩＣＡＴＩＯＮは、ダイアログ障害条件が発生したことを示す通知である。この通知は、ホストコンテキストおよびダイアログ記述子値を、ＩＦＥの実装に特有の理由コードと共に示す。
【０１５４】
ダイアログ破壊プリミティブおよび意味規則は、ＣＩＡ＿ＤＩＡＬＯＧ＿ＦＡＩＬＵＲＥ＿ＮＯＴＩＦＩＣＡＴＩＯＮが示されかつ、ｔｅｒｍｉｎａｔｅ＿ｏｎ＿ｄ＿ｆａｕｌｔオプションが動作可能とされた場合に、ダイアログに対して自動的に実行される。ダイアログの属性（ｔｅｒｍｉｎａｔｅ＿ｏｎ＿ｄ＿ｆａｕｌｔ）は、データ転送ダイアログ障害がダイアログの失敗終了を引起こすかどうかを選択する（すなわち、ｄ＿ｄｅｓｔｒｏｙ意味規則が、ダイアログ上で自動的に実行される）。
【０１５５】
ダイアログに対するデータ転送障害は、ダイアログ障害通知によって示される。データ転送が失敗すると、活性なｄ＿ｓｅｎｄ／ｄ＿ｒｃｖプリミティブが、通知エンティティに対して「ｎｏ−ｇｏ」条件を示す。データ転送障害は、下位メッシュがすべての誤り回復および再伝送動作を試みたが成功しなかった場合に、発生する。
【０１５６】
図１４は、２つのクライアント（たとえば、局所クライアントと遠隔クライアント）の間でタイプ１のサービスに従って論理ダイアログを確立するための、例示的なルーチン１４００を示す。タイプ１のダイアログ確立サービスにおいては、（たとえば、後述するＣｉａＩｎｉｔｉａｔｅ、ＣｉａＩｆｅＥｎｕｍ、ＣｉａＩｆｅＯｐｅｎルーチン等によって）初期化が完了した後に、局所クライアントがｄ＿ｃｒｅａｔｅプリミティブを発行して、選択された局所ＩＦＥ内にダイアログオブジェクトを作成する（ステップ１４２０）。局所クライアントは次に、後続の関連付けに必要とされるダイアログ情報を、ｄ＿ｃｒｅａｔｅ結果パラメータから、または、ｄ＿ｚｉｎｆｏプリミティブの後続の呼出しを通じて、検索する（ステップ１４３０）。たとえば、この局所ダイアログ情報は、局所ダイアログオブジェクトを特定するフィールドを含み得るが、これに限定されるものではない。
【０１５７】
ステップ１４４０において、局所クライアントは次に、この局所ダイアログ情報を、遠隔の相手側クライアントに通信する。タイプ１のダイアログ確立を使用する各クライアントは、このインターフェイス以外に専用の手段（おそらくは、既に確立されている別のＣＩＡダイアログ）を有し、それによって、（ステップ１４３０において検索された局所ダイアログ情報等の）局所ダイアログ情報を、遠隔の相手側クライアントに通信する。
【０１５８】
遠隔クライアントは同様に、ダイアログを作成し、かつ、遠隔のダイアログオブジェクトを特定する対応のダイアログ情報（遠隔ダイアログ情報と称される）を検索している。ステップ１４５０において、この遠隔クライアント（または、局所および受信側クライアントの両方に専用の、他のモジュール）が、ステップ１４４０において局所クライアントから送信されてきた局所ダイアログ情報および、遠隔クライアントにおいて生成された遠隔ダイアログ情報に基づいて、これらのダイアログのペアリング（合致）を判定する。合致が判定された後に、各クライアントは、ｄ＿ａｓｓｏｃｉａｔｅプリミティブを呼出して、遠隔ダイアログ情報を局所ダイアログオブジェクトに提供する（ステップ１４６０）。関連付けの成功（または失敗）は、クライアントに専用の手段によって、クライアント間で通信される（ステップ１４７０）。この時点において、ダイアログは確立され、このダイアログを通じたデータ転送を進めることが可能となる。
【０１５９】
タイプ１のダイアログ確立を使用するクライアントは、同様に、使用可能などのような手段を使用しても、そのダイアログの終了を調整する責任を負う。このダイアログに対する未処理のオペレーションを取消すために、ｄ＿ｓｈｕｔｄｏｗｎおよびｄ＿ｉｎｔｅｒｌｏｃｋを使用せねばならないこともあろう。クライアントはその後、ｄ＿ｄｅｓｔｒｏｙプリミティブを呼出して、対応するダイアログオブジェクトを破壊する。
【０１６０】
２．タイプ２
別の実施例においては、ＣＩＡクライアントは、タイプ２のダイアログ確立サービスに従って、論理ダイアログを確立することができる。タイプ２のダイアログ確立サービスを使用するクライアントは、ｄ＿ｃｒｅａｔｅ、ｄ＿ｄｅｓｔｒｏｙ、ｄ＿ｚｉｎｆｏ、ＣｉａＤｉａｌｏｇＣｏｎｎｅｃｔ、およびＣｉａＤｉａｌｏｇＤｉｓｃｏｎｎｅｃｔのＣＩＡプリミティブを利用して、ダイアログオペレーションを実行する。ｄ＿ｃｒｅａｔｅ、ｄ＿ｄｅｓｔｒｏｙ、およびｄ＿ｚｉｎｆｏプリミティブは、タイプ１に関連して上述したのと同じパラメータを有する。ＣｉａＤｉａｌｏｇＣｏｎｎｅｃｔおよびＣｉａＤｉａｌｏｇＤｉｓｃｏｎｎｅｃｔ要求は、確立プロセスを開始および終了するのに使用される、ルーチンまたはプリミティブである。
【０１６１】
（たとえばＣｉａＩｎｉｔｉａｔｅ、ＣｉａＩｆｅＥｎｕｍ、ＣｉａＩｆｅＯｐｅｎ等で）初期化を完了した後に、タイプ２のダイアログ確立を使用するクライアントは、ｄ＿ｃｒｅａｔｅを呼出して、選択された局所ＩＦＥ内にダイアログオブジェクトを作成する。クライアントはその後、ＣｉａＤｉａｌｏｇＣｏｎｎｅｃｔを呼出すことによって、確立プロセスを開始する。ＣＩＡ−ＭＳ１３００は、クライアントによって供給されたパラメータを使用して、指定された遠隔ノードとの合致機能を行なう。ＣＩＡ−ＭＳ１３００は、必要なダイアログ情報を交換し、ダイアログ関連付け機能を行なって、相手方ノードに知らせる。確立がうまく完了すると、それは、クライアントが特定した呼戻しルーチンを通じて報告される。この時点で、ダイアログは確立されて、そのダイアログを通じたデータ転送を進めることが可能となる。
【０１６２】
タイプ２のダイアログ確立を使用するクライアントは、ＣｉａＤｉａｌｏｇＤｉｓｃｏｎｎｅｃｔを呼出すことによって、ダイアログの終了を開始する。そのダイアログに対する未処理のプリミティブはどれも終了され、また、そのクロージャの終結が、クライアントが特定した呼戻しルーチンを通じて報告される。クライアントはその後、ｄ＿ｄｅｓｔｒｏｙプリミティブを呼出す。
【０１６３】
タイプ２のダイアログ確立は、簡単なダイアログ名前付けおよび突合せサービスを提供する。ダイアログの名前は、文字列比較または他の適切な突合わせ技術を使用して、突合せることができる。
【０１６４】
ＣＩＡ管理サービス１３００は、以下のようにタイプ２のダイアログ確立を実現することが可能である。ＣｉａＤｉａｌｏｇＣｏｎｎｅｃｔは、ダイアログ基準値、ダイアログ名、ＮＯＤＥ記述子（Ｎｏｄｅ＿ｉｄ、Ｎｏｄｅ＿ｉｎｔｅｒｆａｃｅ）および呼戻しルーチンアドレスといった入力パラメータで、規定することが可能である。ダイアログ基準値は、このダイアログに対する、クライアントの一意の基準値であって、接続サービスが完了した時点で呼戻しルーチンに返される。この呼戻しルーチン手順プロトタイプはまた、クライアントが接続オペレーションがうまく完了したかどうかを判定するのに使用する、接続ステータスを含む。図１４Ｂは、ＣＩＡ−ＭＳ１３００がＣｉａＤｉａｌｏｇＣｏｎｎｅｃｔを実現するのに使用することのできる、例示的なルーチン１４００’を示す：
１．　ユーザレベルの管理ダイアログ（ＵＬＭＤ）が指示されたＮＯＤＥ記述子に対して確立されていない場合に、ユーザレベルの管理ダイアログ確立アルゴリズム１５００を行なう（ステップ１４１０’）。
【０１６５】
２．　新しいダイアログが作成されようとしておりかつ、特定の名前（この名前は、ＣｉａＤｉａｌｏｇＣｏｎｎｅｃｔに渡されたダイアログ名パラメータから導出される）が付けられたサービスに関連付けられようとしていることを、ユーザレベルの管理ダイアログを使用して遠隔ＣＩＡ−ＭＳに知らせる（ステップ１４２０’）。
【０１６６】
３．　ダイアログの関連付けを完了する（ステップ１４３０’）。
４．　接続ステータスおよびクライアントのダイアログ基準値を示す、クライアントの呼戻しルーチンを呼出す（ステップ１４４０’）。
【０１６７】
本発明は、タイプ１およびタイプ２のダイアログ確立サービスに限定されるものではない。他の種類のダイアログ確立サービスもまた、提供することが可能である。たとえば、Ｗｉｎｄｏｗｓ（Ｒ）ソケット意味規則を実現する、ダイアログ確立サービスを使用することも可能である。この説明が向けられる当該技術分野における当業者には明らかなように、ＣＩＡ１０００は、ＣｉａＤｉａｌｏｇＣｏｎｎｅｃｔおよびＣｉａＤｉａｌｏｇＤｉｓｃｏｎｎｅｃｔもまた、プリミティブとして実現することが可能である。他のダイアログ管理（プリミティブまたはルーチン）を、論理ダイアログの確立および廃止のために規定することも可能である。
【０１６８】
ｃ．ユーザレベルの管理ダイアログ
本発明に従えば、ＣＩＡ１０００は、２つのノード間に最初のダイアログをセットアップするための機構を提供する。この最初のダイアログは、ユーザレベルの管理ダイアログ（ＵＬＭＤ）と呼ばれる。このユーザレベルの管理ダイアログは、ＣＩＡ−ＭＳ１３００によって、通信経路として使用されて、遠隔ＩＦＥにおける他のＣＩＡクライアントのための付加的なダイアログを作成しかつ関連付けることができる。ＵＬＭＤは、より進化したダイアログ確立サービス（たとえば、ダイアログタイプ２の確立）を実現するための通信経路を提供する。
【０１６９】
（たとえば局所ＩＦＥおよび遠隔ＩＦＥの）２つのＩＦＥ間にユーザレベルの管理ダイアログを確立するためのルーチン１５００について、図１５Ａから図１５Ｃを参照して以下に説明する。図１５Ａは、ＣＩＡ−ＭＳ１３００が２つのＩＦＥ間にどのようにユーザレベルの管理ダイアログを確立するかを示す、状態図１５０１を示す。ＩＦＥは、各ＮＯＤＥオブジェクト（すなわち、遠隔ＩＦＥ）について、異なるユーザレベルの管理ダイアログを有する。
【０１７０】
図１５Ｂに示すように、ＣＩＡ−ＭＳ１３００は、待ちステージ１５０２において、ユーザレベルの管理ダイアログの確立を開始する。ＣＩＡ−ＭＳ１３００は、ＣｉａＤｉａｌｏｇＣｏｎｎｅｃｔ要求が局所で発行されるのを待つ（ステップ１５０４）か、または、ｇｒｅｅｔｉｎｇ−１が発行されるのを待つ（ステップ１５０６）。ＣｉａＤｉａｌｏｇＣｏｎｎｅｃｔが発行されると、それは、関連するＮＯＤＥ記述子のための「完了されるべきリスト（ｔｏ　ｂｅ　ｃｏｍｐｌｅｔｅｄ　ｌｉｓｔ）」上の待ち行列に入れられる（ステップ１５０４）。ｇｒｅｅｔｉｎｇ−１の発行は、ユーザレベルの管理ダイアログが確立された（または現時点において確立されつつある）ＮＯＤＥオブジェクトにマッピングしない、遠隔ＩＦＥから、ＣＩＡ＿ＮＯＤＥ＿ＧＲＥＥＴ＿ＮＯＴＩＦＩＣＡＴＩＯＮ（ｋｉｎｄ＿ａｓｓｏｃｉａｔｅ＝ＦＡＬＳＥ）（すなわち、一意のｎｏｄｅ＿ｉｄ、ｎｏｄｅ＿ｉｎｔｅｒｆａｃｅ）が受信された状態に当てはまる。
【０１７１】
ステップ１５０４または１５０６の後、表示されたＮＯＤＥ記述子のためのユーザレベルの管理ダイアログが確立されているか、または進行中、すなわち、現時点において確立されつつあるかを判定するチェックが行なわれる（ステップ１５０８）。特定されたＮＯＤＥ記述子に合致するＮＯＤＥオブジェクトが未だ作成されていない場合には、ＣＩＡ−ＭＳ１３００は、ｎ＿ｃｒｅａｔｅプリミティブを呼出す（ステップ１５１０）。特定されたＮＯＤＥ記述子に合致するＮＯＤＥオブジェクトが既に存在する場合には、ＣＩＡ−ＭＳ１３００は、ステップ１５０９において、完了状態へと即座に移行する。なぜなら、その要求は既に待ち行列に入れられており、ステップ１５９５におけるノードの確立後に完了されることになるためである。
【０１７２】
ステップ１５１０において、ＣＩＡ−ＭＳ１３００は、新しいＮＯＤＥオブジェクトを作成するために、ｎ＿ｃｒｅａｔｅプリミティブを発行する。ＤＩＡＬＯＧオブジェクトが、ｄ＿ｃｒｅａｔｅプリミティブを発行することによって作成される（ステップ１５２０）。ステップ１５２０において、ＣＩＡ−ＭＳ１３００は、ｄ＿ｃｒｅａｔｅプリミティブを呼出して、ユーザレベルの管理ダイアログに対するダイアログオブジェクトを作成する。ＣＩＡ−ＭＳ１３００は、その後、そのユーザレベルの管理ダイアログのためのダイアログハンドルを、ｎ＿ｇｒｅｅｔプリミティブに対するパラメータとして渡す。ＣＩＡ−ＭＳ１３００はｎ＿ｇｒｅｅｔプリミティブを、関連するＮＯＤＥ記述子に対して発行する（ステップ１５４０）。
【０１７３】
ステップ１５５０において、ステップ１５１０〜１５４０が、ｇｒｅｅｔｉｎｇ−１を受信することによって開始されたかどうかを判定するチェックが行なわれる。ｇｒｅｅｔｉｎｇ−１がステップ１５０６において受信された場合、ＣＩＡ−ＭＳ１３００は、状態ｓｙｎｃ−Ａに進む（ステップ１５６５）。なぜなら、それは既にｇｒｅｅｔｉｎｇ−１の表示を受信していたからである。そうでない場合には、ＣＩＡ−ＭＳ１３００は、ｇｒｅｅｔｉｎｇ−１またはｇｒｅｅｔｉｎｇ−２の表示を待って（ステップ１５６０）から、状態ｓｙｎｃｈ−Ａまたはｓｙｎｃｈ−Ｂに進む（ステップ１５６５）（図１５Ｃ参照）。
【０１７４】
状態ｓｙｎｃ−Ａまたはｓｙｎｃ−Ｂに達すると、ＣＩＡ−ＭＳ１３００は、ｄ＿ａｓｓｏｃｉａｔｅプリミティブを発行して、ＵＬＭＤダイアログの関連付けを完了する（ステップ１５７０）。ｎ＿ａｓｓｏｃｉａｔｅプリミティブが発行されて、ＮＯＤＥの関連付けが完了される（ステップ１５８０）。ｇｒｅｅｔｉｎｇ−２の表示が受信される（ステップ１５８２）かまたは、それを待った（ステップ１５８４）後に、ｎ＿ｂｏｕｎｄプリミティブが発行されて、ＮＯＤＥの確立が完了する（ステップ１５９０）。
【０１７５】
ここで、ＮＯＤＥの確立が、ｇｒｅｅｔｉｎｇ−１が遠隔ノードから受信されなくとも（すなわち、ｇｒｅｅｔｉｎｇ−２が代わりに受信されても）、状態ｇｒｅｅｔ−Ｂから続けられることに着目されたい。これは、局所ＩＦＥが遠隔ＩＦＥからの通知を受取るよう準備される直前に、遠隔ＩＦＥがユーザレベルの管理ダイアログの確立を開始するような、競合状態を解決する。この場合のタイミングは、以下のようであり得る。すなわち、遠隔ＩＦＥがそのｇｒｅｅｔｉｎｇ−１を送信するが、それは局所ＩＦＥによって途絶えさせられる（そのことを遠隔ＩＦＥは検知しない）。局所ＩＦＥはそのｎ＿ｇｒｅｅｔを行ない、それにより遠隔ＩＦＥがそのｎ＿ａｓｓｏｃｉａｔｅを完了することが可能となり、よって、ｇｒｅｅｔｉｎｇ−２が（明確なｇｒｅｅｔｉｎｇ−１の表示なしに）局所ＩＦＥによって受信されてしまう結果となる、という具合である。
【０１７６】
最後に、関連するＮＯＤＥ記述子に対する、「完了されるべき」リスト上のすべてのＣｉａＤｉａｌｏｇＣｏｎｎｅｃｔ要求が完了される（ステップ１５９５）。ＵＬＭＤを確立するためのルーチン１５００が、その後、実行される（ステップ１５９９）。
【０１７７】
ｄ．ＩＦＥ管理プリミティブおよび通知
ダイアログおよびノードを確立しかつ管理するのに加えて、ＣＩＡは、内部接続フロントエンド（ＩＦＥ）管理オペレーションを提供する。これらＩＦＥ管理オペレーションは、未処理のプリミティブの取消しおよび、ＩＦＥのリセットを含むが、これらに限定されるものではない。これらＩＦＥ管理オペレーションは、ＩＦＥ管理プリミティブのセット（ｉ＿ｃａｎｃｅｌ、ｉ＿ｒｅｓｅｔ）によって、実行される。
【０１７８】
内部接続取消しプリミティブ（ｉ＿ｃａｎｃｅｌ）は、未処理のプリミティブの取消しをサポートする。未処理のｄ＿ｒｃｖプリミティブに対するｉ＿ｃａｎｃｅｌプリミティブが受信されると、ＩＦＥは、その未処理のｄ＿ｒｃｖプリミティブをできるだけ早く終了する。指示されたｄ＿ｒｃｖプリミティブは、その受信がｉ＿ｃａｎｃｅｌが効力を発揮する前にうまく完了した場合には、ｇｏ表示を返す。そうでない場合には，ｄ＿ｒｃｖプリミティブは、ｎｏ−ｇｏ表示を返す。未処理のｄ＿ｓｅｎｄプリミティブに対するｉ＿ｃａｎｃｅｌプリミティブが受信されると、ＩＦＥは、即座にその未処理のｄ＿ｓｅｎｄプリミティブを終了する。指示されたｄ＿ｓｅｎｄプリミティブは、その取消しが効力を発する前にそのｄ＿ｓｅｎｄがうまく完了した場合には、ｇｏ表示を返す。そうでなければ、ｄ＿ｓｅｎｄプリミティブは、ｎｏ−ｇｏ表示を返す。
【０１７９】
ｉ＿ｃａｎｃｅｌ＿ｂｙ＿ｒｅｆｅｒｅｎｃｅプリミティブもまた、ＣＩＡ１０００に付加することができる。これは、ＣＣＢ内の特定のフィールド（またはパラメータ）を識別するためのパラメータを有する。ｉ＿ｃａｎｃｅｌ＿ｂｙ＿ｒｅｆｅｒｅｎｃｅプリミティブはそこで、ＣＣＢが合致するフィールドを有するか否かに基づいて、ＣＣＢを選択的に取消すことを可能にする。ＩＦＥ管理プリミティブは、例示のためのみのものであって、本発明を限定するものではない。たとえば、ＩＦＥは、ＣＩＡオブジェクトおよびプリミティブに関する、セキュリティ方針を強化することもできる。
【０１８０】
内部接続リセットプリミティブ（ｉ＿ｒｅｓｅｔ）は、ＩＦＥを初期化するのに使用される。このｉ＿ｒｅｓｅｔ以前に発行された未処理のプリミティブはいずれも、ｎｏ−ｇｏ表示で完了される。この内部接続リセットプリミティブは、ＩＦＥに望まれる動作特性を示し、これは、このＩＦＥからＣＩＡ＿ＮＯＤＥ＿ＦＡＵＬＴ＿ＮＯＴＩＦＩＣＡＴＩＯＮおよびＣＩＡ＿ＩＦＥ＿ＦＡＵＬＴ＿ＮＯＴＩＦＩＣＡＴＩＯＮに対して返されるべき、コンテキストパラメータを含む。
【０１８１】
ＩＦＥ障害指示通知（ＣＩＡ＿ＩＦＥ＿ＦＡＵＬＴ＿ＮＯＴＩＦＩＣＡＴＩＯＮ）は、局所ＩＦＥが失敗したことを示す。この通知は、最も新しいｉ＿ｒｅｓｅｔプリミティブによって特定されるコンテキストパラメータ値を示し、また、ＩＦＥの障害の原因を診断するのに役立つよう使用され得る、ＩＦＥに特有の理由コードを示す。未処理のプリミティブの状態は、はっきりとはしないが、それらの完了を試みる目的で、ＣＩＡ＿ＦＩＥ＿ＦＡＵＬＴ＿ＮＯＴＩＦＩＣＡＴＩＯＮの後に、後続のｉ＿ｒｅｓｅｔプリミティブを発行することが可能である。
【０１８２】
６．バッファプール（ＢＰ）およびプールマネージャ（ＰＭ）オペレーション
ａ．「バッファプールで受信」オペレーション
上述の、「バッファで受信」ダイアログオペレーションに加えて、本発明はさらに、「バッファプールで受信」ダイアログオペレーションを提供する。ＣＩＡ１０００は、バッファプールおよびバッファプール管理を使用して、内部接続データ通信を提供する。バッファプールおよびプールマネージャオペレーションがＣＩＡ１０００内に提供されて、それらが、プルデータモデルを、データ転送をプッシュデータモデルと同様に効率的に行なうことができるように、最適化する。
【０１８３】
図１６および１７の例に示すように、ＣＩＡ１０００は、バッファプールおよびプールマネージャと称される、付加的なＣＩＡオブジェクトを含む（ＢＰ１６４０およびＰＭ１６５０を参照）。ＣＩＡ１０００は、バッファプール（ＢＰ）およびプールマネージャ（ＰＭ）オブジェクトを使用して、「バッファプールで受信」オペレーションをサポートする。プルモデルをサポートするために、ＣＩＡ１０００は、バッファプールシャドウおよびプールマネージャシャドウと称される、シャドウオブジェクトをさらに含む（ＢＰＳ１７４０およびＰＭＳ１７５０を参照）。ＣＩＡプリミティブが使用されて、バッファプールおよび対応のバッファプールシャドウが作成されかつ管理される。ＣＩＡプリミティブが使用されて、プールマネージャおよび対応のプールマネージャシャドウが作成され管理される。ＣＩＡプリミティブ（およびパラメータ）がさらに使用されて、バッファプールおよびプールマネージャ（ならびにシャドウオブジェクト）に関連するパラメータおよびリファレンスが、ＣＩＡクライアントとＩＦＥとの間で送られる。
【０１８４】
図１６は、ＩＦＥ２１１内の、バッファプール１６４０およびプールマネージャ１６５０の例を示す。バッファプール１６４０およびプールマネージャ１６５０は、ノード４０１に関連している。明確さを期すために、この例は、上述のようにダイアログ５０１とダイアログ５０３との間に先に確立された、１つの論理ダイアログのためのデータ通信に関して説明するものとするが、本発明は、この例に限定されるものではない。１つのノードを、複数の論理ダイアログ（および対応のダイアログオブジェクト）に関連付けることが可能である。１つのプールマネージャを使用して、複数のバッファプールを管理することも可能である（たとえば、ＰＭ１６５０を使用して、１６個のＢＰを管理することができる）。
【０１８５】
ＣＣＢ１６１１から１６１９は、アプリケーション５１０によって発行される。ＣＣＢ１６１１は、ｂｐ＿ｃｒｅａｔｅ（ＢＵＦＦＥＲ＿ＰＯＯＬ＿ＣＲＥＡＴＥ）プリミティブである。このｂｐ＿ｃｒｅａｔｅプリミティブは、バッファプール（ＢＰ１６４０）を作成するのに使用される。バッファプールとは、バッファアドレスおよびバッファプールの属性を記憶する、データ構造またはオブジェクトである。１つのバッファプール内に記憶することのできるバッファアドレスの数は、ＣＩＡクライアントによって決定され、ｂｐ＿ｃｒｅａｔｅプリミティブに対するパラメータとして特定される。ＣＩＡクライアントはまた、各バッファアドレスに関連するバッファの（バイト単位の）サイズを、ｂｐ＿ｃｒｅａｔｅパラメータとして特定する。
【０１８６】
プルモデルを有効にサポートするために、ＣＩＡは、クライアントがＢＰを、特定のＮＯＤＥと関連付けることを要求する。プルモデルをサポートする相互接続定義のために、局所ＩＦＥは遠隔ＩＦＥに対して、ＢＰＳ（ＢＵＦＦＥＲ　ＰＯＯＬ　ＳＨＡＤＯＷ）オブジェクトが作成される必要があることを伝える。図１７に示すように、ＢＰＳ１７４０が遠隔ＩＦＥによって使用されて、そのバッファプールに対してクレジットされた、バッファアドレスおよびバッファのバッファサイズが記憶される。このバッファアドレスおよびサイズの可視性により、送信側（すなわち、遠隔ＩＦＥ）が、データバイトを、バッファプールを参照する受信オペレーションのために受信側メモリアドレスに結合することが可能となる。遠隔ＩＦＥがそのＢＰＳのためにメモリを割当てることができない場合には、ｂｐ＿ｃｒｅａｔｅプリミティブは失敗する場合もある。
【０１８７】
ＢＰＳ１７４０は、それがシャドウするＢＰ１６４０に、非常によく似ている。この構造内のほとんどすべてのフィールドは、それがシャドウするＢＰ内の同じフィールドと同様に利用される。ＢＰＳ１７４０の１つの付加的なコンポーネントは、プールマネージャシャドウディレクトリ（ＰＭＳ＿ＤＩＲＥＣＴＯＲＹまたは、ＰＭＳＤ）である。ＰＭＳＤ内のエントリが使用されて、このＢＰＳ１６４０に関連するプールマネージャシャドウ（ＰＭＳ）１７５０が覚えられる。各ＰＭＳに対して、ＰＭＳＤ内には、そのＢＰＳを参照する制御項目を有する、エントリが存在する。ただし、ＰＭＳが同じＢＰＳに対して複数のエントリを有する場合にも、そのＰＭＳに対して１つのＰＭＳＤエントリのみが、ＰＭＳＤ内に発生することに留意されたい。
【０１８８】
ＰＭＳＤは、バッファプールのクレジットが先に空であったバッファプールに供給される場合に再スケジュールが必要とされる、ＲＥＱ（送信または受信要求）のセットを発見する、メカニズムを提供する。クレジットが先に空であったバッファプールに供給される場合、バッファプール資源を待ってＰＭＳ待ち行列（ｐｍｓ＿ｑ）内で待ち行列に入れられているＲＥＱが存在し得る。ＰＭＳＤは、立上りルーチンが、待っているＲＥＱを有するこのＢＰＳに関連付けられているｐｍｓを走査することができるようにする。
【０１８９】
ＰＭＳディレクトリのサイズは可変である。最初に、ＰＭＳ＿ＤＩＲＥＣＴＯＲＹ＿ＳＩＺＥエントリが、ＢＰＳ構造それ自体内に割当てられる。付加的なエントリが必要である場合（たとえば、このＢＰＳを参照するｐｍ＿ｃｒｅａｔｅまたはｐｍ＿ａｄｄ＿ｃｏｎｔｒｏｌプリミティブが行われるとき）には、付加的なＰＭＳＤエントリを、ＢＰＳ内の原ＰＭＳＤサイズのエントリ上に、リンクすることが可能である。同様に、ＰＭＳが破壊された場合、関連するどのＰＭＳＤ内におけるそのエントリも、取除かれる。
【０１９０】
点線のリファレンス（１６７２）が示されるが、これは、新しいＢＰ１６４０がＮＯＤＥ４０１に関連付けられるようになることを示す。ノード４０１を作成したＣＣＢは、図１６には示されていないが、ノード作成のためのＣＣＢは、ノード作成のためには上述のように動作し、また、ダイアログおよび他のオブジェクトの作成のためには上述のＣＣＢと同様に動作する。ＩＦＥ２１１は、新しく作成されたＢＰ１６４０に対するリファレンス（１６７３）を、ＣＣＢ１６１１に関連する結果情報の一部として返す。アプリケーション５１０は、このリファレンスを、ＢＰ１６４０を参照する必要のある、後続のＣＣＢ（たとえば、１６１２）内に、パラメータ値として送る。
【０１９１】
ＣＣＢ１６１２は、ｂｐ＿ｓｕｐｐｌｙ＿ｃｒｅｄｉｔ（ＢＵＦＦＥＲ＿ＰＯＯＬ＿ＳＵＰＰＬＹ＿ＣＲＥＤＩＴ）プリミティブである。このｂｐ＿ｓｕｐｐｌｙ＿ｃｒｅｄｉｔプリミティブは、ＢＰに対してバッファ領域を供給するのに使用される。プルモデルをサポートする相互接続定義のために、局所ＩＦＥは遠隔ＩＦＥに対して、そのＢＰに関連するＢＰＳにクレジットされるべきバッファアドレスを知らせる。
【０１９２】
ＣＣＢ１６１２が、アプリケーションメモリスペース内のバッファ領域のセット１６３１〜１６３９を、リファレンス１６７４および１６７５によって参照するものとして示されている。バッファ領域の開始アドレスは、どのバイト境界線上にも位置合せすることができる。開始アドレスとは、そのバッファ内のすべてのバイトのうち、数値的に最下位のアドレスである。ＣＣＢ１６１２はまた、先に作成されたＢＰ１６４０を参照して、そのＢＰリファレンス（１６７６）をＩＦＥ２１１に対して、ＣＣＢ１６１２内のｂｐ＿ｓｕｐｐｌｙ＿ｃｒｅｄｉｔパラメータの一部として渡す。ＩＦＥ２１１は、バッファリファレンス（１６７４、１６７５）をＢＰ１６４０に保持されるバッファリファレンスリストに（および、プルモデルのために遠隔ＩＦＥの関連のＢＰＳ内に）付加することによって、ｂｐ＿ｓｕｐｐｌｙ＿ｃｒｅｄｉｔを処理する。ＩＦＥ２１１は、ＢＰ（および、対応のＢＰＳオブジェクト）にクレジットされたバッファリファレンスの実際の数を、ＣＣＢ１６１２内に記憶される結果情報の一部として、表示する。
【０１９３】
ＣＣＢ１６１３は、ｐｍ＿ｃｒｅａｔｅ（ＰＯＯＬ＿ＭＡＮＡＧＥＲ＿ＣＲＥＡＴＥ）プリミティブである。このｐｍ＿ｃｒｅａｔｅプリミティブは、ＰＭ（ＰＯＯＬ　ＭＡＮＡＧＥＲ）１６５０を作成するのに使用される。図１７に示すように、ＰＭ１６５０は、バッファ優先パラメータを記述し、これが、利用可能なバッファを転送長さに合致させるための最良適合能力を提供する。この優先パラメータは、ＢＰリファレンスおよび選択結合のリストとして保持される。アプリケーションによっては、複数のＰＭオブジェクトを作成することが可能であり、また、各ＰＭオブジェクトが複数のバッファプールを参照することも可能である。「バッファプールで受信」オペレーションは実際に、ＰＭオブジェクトを参照する。
【０１９４】
プルモデルを有効にサポートするために、ＣＩＡは、クライアントがＰＭを特定のＮＯＤＥと関連付けることを要求する。プルモデルをサポートする相互接続定義のために、局所ＩＦＥはそのＰＭに関連する遠隔ＩＦＥに対して、いつバッファ優先パラメータに変化がもたらされたかを知らせる。遠隔ＩＦＥは、ＰＭＳ（ＰＯＯＬ　ＭＡＮＡＧＥＲ　ＳＨＡＤＯＷ）１７５０と称される、自身の内部オブジェクト内に、バッファ優先パラメータを記憶する。このバッファ優先パラメータは、可視的に、送信側（すなわち、遠隔ＩＦＥ）が、ＰＭを参照する受信オペレーションのために、受信側メモリアドレスにデータバイトを正しく結合することを可能にする。
【０１９５】
点線のリファレンス（１６７９）が示されるが、これは、新しく作成されたＰＭ１６５０がＮＯＤＥ４０１と関連付けられるようになることを示す。第２の点線のリファレンス（１６８０）は、ＢＰ１６４０が、その新しく作成されたＰＭ１６５０によって管理されるバッファプールとして付加されることを表わす。ＩＦＥ２１１は、その作成されたＰＭ１６５０に対するリファレンス（１６８１）を、ＣＣＢ１６１３に関連する結果情報の一部として返す。アプリケーション５１０はこのリファレンスを、ＰＭ１６５０を参照する必要のある後続のＣＣＢ（たとえば、１６１６）内に、パラメータ値として送る。
【０１９６】
ＣＣＢ１６１４は、ｄ＿ｃｒｅａｔｅ（ＤＩＡＬＯＧ＿ＣＲＥＡＴＥ）プリミティブである。このｄ＿ｃｒｅａｔｅプリミティブは、局所ＩＦＥ（２１１）上にＤＩＡＬＯＧ５０１を作成するのに使用される。ＩＦＥ２１１は、その作成されたＤＩＡＬＯＧ５０１に対するリファレンス（１６８２）を、ＣＣＢ１６１４に関連する結果情報の一部として返す。アプリケーション５１０は、このリファレンスを、ＤＩＡＬＯＧ５０１を参照する必要のある後続のＣＣＢ（たとえば、１６１５、１６１６）内にパラメータ値として渡す。
【０１９７】
ＣＣＢ１６１５は、ｄ＿ａｓｓｏｃｉａｔｅ（ＤＩＡＬＯＧ＿ＡＳＳＯＣＩＡＴＥ）プリミティブである。このｄ＿ａｓｓｏｃｉａｔｅは、局所ＤＩＡＬＯＧ５０１と、遠隔ＩＦＥ２１３におけるダイアログ５０３との間に、終端間の関係を確立するのに使用される。ＣＣＢ１６１５は、先に作成されたＤＩＡＬＯＧ５０１に、リファレンス（１６８３）を渡す。これはまた、ＤＩＡＬＯＧ５０１がＮＯＤＥ４０１に関連付けられることを示す、リファレンス（１６８４）もまた渡す。付加的なパラメータ（図示せず）は、ＣＣＢ１６１５内に渡されて、ＤＩＡＬＯＧ５０１内に記憶される。これらの付加的なパラメータは、ＤＩＡＬＯＧ５０１とＤＩＡＬＯＧ５０３との間のエンドツーエンドの関係を完了するための、結合情報を提供する。アプリケーション５１０は、ＩＦＥ２１３から、先に作成されたダイアログを通じるデータ転送を介して、ＤＩＡＬＯＧ５０３のための連結情報を検索する。ＣＩＡは、上述のように最初の「ユーザレベルの管理ダイアログ」を提供して、付加的なダイアログのための連結情報のやりとりをサポートする。
【０１９８】
ＣＣＢ１６１６は、ｄ＿ｒｃｖ（ＤＩＡＬＯＧ＿ＲＥＣＥＩＶＥ）プリミティブである。このｄ＿ｒｃｖプリミティブは、ダイアログのための入来データを受取るのに使用される。ＣＣＢ１６１６は、それに対する入来データを受け入れようとしている、先に関連付けられたＤＩＡＬＯＧ５０１に対して、リファレンス（１６８７）を渡す。ＣＣＢ１６１６はまた、このプリミティブの結果として受信されるデータのためのバッファ選択プロセスをＰＭ１６５０が制御することを示す、リファレンス（１６８６）を渡す。このｄ＿ｒｃｖプリミティブは、種々のデータ分散変形をサポートするよう規定される。アプリケーション５１０は、データがＣＣＢ１６１６内に渡されるパラメータによってアプリケーションメモリ内に取込まれる方法およびその最大量を制御する。ＣＩＡは、データを、バッファプール資源および特定のバッファ領域にわたって分散することができるようにする。「自動受信」ｄ＿ｒｃｖプリミティブオプションもまた規定されるが、これは、連続的な受信オペレーションの性能を向上させる。なぜなら、ｄ＿ｒｃｖプリミティブの発行が必要なのは、１回のみであるためである。
【０１９９】
１例において、アプリケーションは、ｄ＿ｒｃｖプリミティブのための結果領域６５１を指す、結果記述子６４３を特定せねばならない。この結果領域６５１は、ＰＭまたは明示的なバッファアドレスであり得る。ｄ＿ｒｃｖプリミティブのための結果領域６５１は、バッファアドレスおよび、そのデータ転送を完了するためにバッファプールから消費された転送長さを反映するよう、更新される。ｄ＿ｒｃｖ結果領域６５１内のバッファアドレスおよび転送長さの最大数は通常、固定されているが、これは可変とすることも可能である。
【０２００】
自動的に反復するｄ＿ｒｃｖプリイティブ（すなわち、ｄ＿ｒｃｖプリミティブのＡＵＴＯオプション）に対する一意の結果領域を正しくサポートするために、アプリケーションは、結果領域のためのＰＭリファレンスを特定せねばならない。Ｗｉｎｄｏｗｓ（Ｒ）ＮＴインターフェイスについては、呼戻し通知メカニズムが使用されて、ｄ＿ｒｃｖの結果を保持するのに使用される結果領域のアドレスが報告される。ＭＣＰについては、ＳｙｓＱｕｅｕｅメカニズムが使用されて、結果領域が待ち行列に入れられる。
【０２０１】
アプリケーションは、同じダイアログに対して異なるＰＭを参照する、異なるｄ＿ｒｃｖプリミティブを発行することができる。アプリケーションはまた、（ＤＩＡＬＯＧおよびＰＭが同じＮＯＤＥに関連付けられている限り）異なるダイアログに対して同じＰＭを参照する、ｄ＿ｒｃｖプリミティブを発行することもできる。すべてのＢＰおよびＰＭが同じノードに関連付けられている限り、複数のＰＭが同じＢＰを参照することが可能である。
【０２０２】
ＣＣＢ１６１９は、ｄ＿ｓｅｎｄ（ＤＩＡＬＯＧ＿ＳＥＮＤ）プリミティブである。このｄ＿ｓｅｎｄプリミティブは、データを遠隔ダイアログに転送するのに使用される。ＣＣＢ１６１９は、その上でデータを転送したい、先に作成されたＤＩＡＬＯＧ５０２に対して、リファレンス（１６８９）を渡す。これはまた、局所ＤＩＡＬＯＧ５０２に関連する遠隔ＤＩＡＬＯＧ５０５に転送されるべきデータを含む、バッファ領域１６３０に対して、リファレンス（１６８８）を渡す。このｄ＿ｓｅｎｄプリミティブは、アプリケーション５１０がＣＣＢ１６１９内に渡されたパラメータを使用して制御する、データ収集の種々の変形をサポートするよう規定される。１つのｄ＿ｓｅｎｄプリミティブがポストされかつ繰返し自動的に処理されるのを可能にする、ＡＵＴＯ　ｄ＿ｓｅｎｄプリミティブもまた、規定することが可能である。
【０２０３】
ｂ．「バッファプールで受信」オペレーションをサポートする、
ＣＩＡオブジェクトおよびプリミティブの例示
以下に、送信および受信ＣＩＡクライアント間の論理ダイアログにわたって、内部接続データ通信を提供する際の、プールマネージャおよびバッファプールのオペレーションおよび管理について、以下に例示するオブジェクトおよびルールを参照して、より詳細に説明する。簡単に言えば、ＲＣＢ、バッファプール、プールマネージャ、および、対応のシャドウオブジェクトについて、「バッファで受信」および「バッファプールで受信」の両方のオペレーションをサポートする、通信内部接続アーキテクチャに関して、以下に説明する。「バッファプールで受信」オペレーションについては、上述の、「アーリー・ファー・エンド」および「ファー・エンド」のサービスのクラス、分散、収集、自動受信、部分メッセージ、打切り、複数の未処理要求、およびアドレス結合検査等を含む、最適化のための特徴を含めて、さらに説明する。「バッファプールで受信」オペレーションに特有の他の最適化特徴もまた説明するが、これはさらに、バッファプールクレジット、低水位標通知、および、データ結合を含む。しかし、当業者には明らかなように、本発明は、これらのすべての特徴を含むものと限定されるものではない。ＣＩＡオブジェクト、プリミティブおよび意味規則を、所望の設計目標に従って修正することによって、これらの特徴の１または複数の何らかの組合せを利用する実装も可能である。
【０２０４】
１．ＢＰオペレーションプリミティブ
１．バッファプールオブジェクトを作成して、それを特定のＮＯＤＥと関連付けるのに使用される、プリミティブが存在する（すなわち、ｂｐ＿ｃｒｅａｔｅ）。このプリミティブは、そのＮＯＤＥと、バッファプールクレジットに関連するメモリ領域のサイズ（バイト単位）と、（バッファアドレスを記憶するのに使用される）バッファプールクレジットスロットの数と、（プールオブジェクトがいつ、バッファプールクレジットの数が予め定められた限界を下回ったことを示す通知を発行するようにするかを表わす）低水位標とを示す。このプリミティブの結果は、その特定された数のバッファプールクレジットスロットで、バッファプールオブジェクトを作成することができるか否かを示す、ステータスを含む。もしバッファプールオブジェクトがうまく作成されれば、このバッファプールオブジェクトに対するハンドルもまた返される。バッファプールハンドルは、特定のＩＦＥ内では一意であるが、複数のＩＦＥにわたっては、必ずしも一意ではない。
【０２０５】
２．バッファプールオブジェクトを破壊するのに使用される、プリミティブが存在する（すなわち、ｂｐ＿ｄｅｓｔｒｏｙ）。このプリミティブは、バッファプールハンドルを示す。このプールを参照するすべてのプールマネージャの制御表は、そのバッファプールオブジェクトに対するすべてのリファレンスがその制御表から削除されるように、更新される（この制御表内には空きホールは作成されることはなく、リスト内のすべての後続の項目が繰上げられる）。このプリミティブは、すべてのプールマネージャが更新されて、このバッファプールからバッファに結合されていたすべてのデータの転送が完了すると、完了する。
【０２０６】
３．特定のバッファプールオブジェクトに対してバッファプールクレジットを供給するのに使用される、プリミティブが存在する（すなわち、ｂｐ＿ｓｕｐｐｌｙ＿ｃｒｅｄｉｔ）。このプリミティブは、バッファプールハンドル、および、そのプールにクレジットされるメモリ領域のリストを示す。このプリミティブは、指示されたメモリ領域を、指示されたバッファプールの空きバッファリストに付加する。メモリ領域は、それらが指示されたリスト内に現われるのと同じ順序で、クレジットされる。メモリ領域のリストが、未使用のプールクレジットスロットの数よりも多くの項目を含む場合には、そのリストの、その未使用のバッファプールクレジットスロットを埋める部分のみが適用される。このプリミティブの結果は、このプリミティブによってクレジットされたメモリ領域の数のカウント、および、クレジットが適用された後に残った未使用のプールクレジットスロットの数のカウントを含む。未使用のプールクレジットスロットの数に関する更新結果情報を得るためには、プリミティブがゼロのメモリ領域を供給することが有効である。
【０２０７】
４．クレジット上のバッファプールオブジェクトが残り少ないことを示すのに使用される、通知が存在する（ＣＩＡ＿ＬＯＷ＿ＷＡＴＥＲ＿ＮＯＴＩＦＩＣＡＴＩＯＮ）。この通知は、プールからのバッファが消費され、残りのクレジットの数がそのバッファプールオブジェクトに対する低水位標よりも１だけ少なくなると、発せられる。この通知は、資源不足の状況に陥っているバッファプールオブジェクトに対するホストバッファプール記述子を示す。定義上は、低水位標の属性がゼロに設定されている場合には、低水位標の通知が送信されることは決してない。
【０２０８】
２．ＰＭオペレーションプリミティブ
１．プールマネージャオブジェクトを作成して、それを特定のＮＯＤＥに関連付けるのに使用される、プリミティブが存在する（すなわち、ｐｍ＿ｃｒｅａｔｅ）。このプリミティブは、そのプールマネージャオブジェクトがその上に作成されるべきＮＯＤＥを示す。プールマネージャオブジェクトは、そのプールマネージャオブジェクトを参照するｄ＿ｒｃｖプリミティブのための空きバッファプールスペースへとデータをマッピングする結合アルゴリズムによって使用される、制御のセットを記述する。プールマネージャオブジェクトがうまく作成された場合には、そのプールマネージャオブジェクトに一意のハンドルが返される。このプールマネージャハンドルは、特定のＩＦＥ内では一意であるが、複数のＩＦＥにわたって必ずしも一意ではない。
【０２０９】
２．プールマネージャオブジェクトを破壊するのに使用される、プリミティブが存在する（すなわち、ｐｍ＿ｄｅｓｔｒｏｙ）。このプリミティブは、プールマネージャハンドルを示す。指示されたプールマネージャオブジェクトを参照する、指示されたＮＯＤＥに対するダイアログに関連する、ポストされたすべてのｄ＿ｒｃｖプリミティブが、誤り表示で完了する。指示されたプールマネージャオブジェクトは削除される。
【０２１０】
３．プールマネージャオブジェクトの制御表に制御を付加するのに使用される、プリミティブが存在する（すなわち、ｐｍ＿ａｄｄ＿ｃｏｎｔｒｏｌ）。このプリミティブは、プールマネージャハンドルと、バッファプールハンドルと、下限値および上限値とを示す。特定されたバッファプールは、プールマネージャまたは誤りが表示されるのと同じＮＯＤＥに関連付けられねばならない。そうでない場合は、バッファプールハンドル、下限値および上限値は、指示されたプールマネージャの制御表において次に利用可能な項目内に配置される。制御表は典型的に、固定数の項目を保持する。プールマネージャが作成されると、制御表は空になる。
【０２１１】
４．バッファプールオブジェクトからのバッファは、ファーストイン・ファーストアウトの順（すなわち、それらがｂｐ＿ｓｕｐｐｌｙ＿ｃｒｅｄｉｔプリミティブによって供給されたのと同じ順）で、消費（すなわち、メッセージデータに結合）される。
【０２１２】
３．データ結合アルゴリズム
送信側ＩＦＥは、受信側および送信側が同期したときに、バッファプールスペースに宛てられるメッセージデータの結合を行なう。送信側は、できるだけ大量のデータを結合して、ｄ＿ｓｅｎｄプリミティブまたはｄ＿ｒｃｖプリミティブの終了条件のいずれか（小さい方）を完了する。もし送信側が空きバッファの不足によって結合を完了できない場合には、結合されたデータは結合されたままとされ、送信側は、付加的なバッファクレジットが利用可能となったときに、その結合アルゴリズムの完了を再スケジュールする。もし送信側が、ｄ＿ｒｃｖプリミティブの意味規則がＥＯＭを待っているために結合を完了できない場合には、送信側は、そのダイアログのための次のｄ＿ｓｅｎｄプリミティブが処理されるときに、結合を再開する。
【０２１３】
結合アルゴリズムは、データ転送のなんらかの部分がいつバッファプールにマッピングされねばならないかという、バッファ選択基準を判定するために、プールマネージャの制御表を参照する。この結合アルゴリズムは、ＵＮＢＯＵＮＤカウントを保持する。これは、データ転送のその部分における、未結合のデータバイトの数である。このＵＮＢＯＵＮＤカウントは、制御表の要素によって参照されるバッファプールを使用してＵＮＢＯＵＮＤカウントのなんらかの部分を充足することができるかどうかを判定するために、制御表内に記憶される範囲値と、比較される。
【０２１４】
制御表は、順序付けられたセットである。結合アルゴリズムは、制御表内の第１の要素を最初に検討する。もしＵＮＢＯＵＮＤカウントが上限および下限の範囲値（両端を含む）内であり、かつ、その制御表の要素によって参照されるバッファプール内に空きバッファが存在すれば、そのバッファプールの空きリストの先頭からバッファ領域が使用されて、データバイトのいくつかがマッピングされ、そのバッファ領域は空きリストの待ち行列から外され、低水位標条件がチェックされかつおそらくは表示され、そして、ＵＮＢＯＵＮＤカウントが更新される。もしＵＮＢＯＵＮＤカウントがゼロであれば、データ転送のこの部分に関する結合が完了したことを表わす。そうでなければ、このアルゴリズムは、残りのＵＮＢＯＵＮＤ部分について再開される（すなわち、制御表内の第１の要素が、次のＵＮＢＯＵＮＤ部分について再び検討される）。
【０２１５】
もしＵＮＢＯＵＮＤカウントが特定された範囲外であれば、結合アルゴリズムは、制御表内の次の項目を検討する。制御表内のすべての項目が検討されてもまだＵＮＢＯＵＮＤカウントがゼロにならない場合には、その結合は、付加的なバッファ資源が利用可能になったときに再スケジュールされる。
【０２１６】
バッファプールの順序付けと範囲の例を、以下に示す。
【０２１７】
【表３】
2004005661.tif 000005
【０２１８】
この例においては、１ｋ、４ｋ、および６４ｋのバッファプールが存在する。長さが１Ｋバイトまでの未結合データ転送が、１ｋまたは４ｋのプールに結合され得る。１Ｋより長く３２Ｋよりも短い未結合データは、もしそのデータが１Ｋよりも長いかまたは、そのデータが１Ｋよりも短い場合でも１ｋのバッファがもはや存在しない場合に、４ｋプールに結合される。３２Ｋよりも長い未結合データは、利用できる６４ｋのプールクレジットが不足していない限り、６４ｋプールに結合されるが、６４ｋプールクレジットが十分にない場合には、４ｋプールバッファが使用される。また、残りの３２Ｋ領域を転送するのに十分な４ｋバッファが存在しない場合には、１ｋバッファを使用することが可能である。
【０２１９】
４．ダイアログオペレーションプリミティブ
データがダイアログに対して転送されるべきであることを示す、プリミティブが存在する（ｄ＿ｓｅｎｄ）。このプリミティブは、ダイアログ、メモリアドレス、および、ソースメッセージデータの長さを表わす。これはまた、「メッセージの終了」（ＥＯＭ）がデータ転送の最終バイトと同時に知らされるかどうかを示す。このプリミティブはまた、受信側に結果の一部として送られる、３２ビットのトークン値を示す。このトークン値は、ＥＯＭが知らされる場合にのみ送られる。データは、送信側ホストの環境に固有のＩＯバイトの順に、転送される。このプリミティブの結果は、実際の受信メッセージの長さ（すなわち、打切りまたは取消しの前に、受信側によって受取られるデータの量）を含む。
【０２２０】
ｄ＿ｓｅｎｄプリミティブの変形例が存在するが、これは、データ収集を行なうのに使用される表示（アドレス、長さ）の順序リストをサポートする。
【０２２１】
ｄ＿ｓｅｎｄプリミティブは、未処理のｄ＿ｓｅｎｄプリミティブ間でソースメッセージ領域が共用されることを可能にする。
【０２２２】
ｄ＿ｓｅｎｄプリミティブは、ソースメモリ領域を（一時的にでさえも）修正することはない。
【０２２３】
未処理のｄ＿ｓｅｎｄプリミティブの取消しをサポートする、ｉ＿ｃａｎｃｅｌプリミティブが存在する。未処理のｄ＿ｓｅｎｄプリミティブに対してｉ＿ｃａｎｃｅｌプリミティブが受信されると、ＩＦＥは、その未処理のｄ＿ｓｅｎｄプリミティブをできるだけ早く終了させる。指示されたｄ＿ｓｅｎｄプリミティブは、取消しが有効となる前にｄ＿ｓｅｎｄがうまく完了した場合には、ｇｏ表示を返す。さもなければ、ｄ＿ｓｅｎｄプリミティブは、ｎｏ−ｇｏ表示を返す。
【０２２４】
複数の受信が、１つのダイアログに対してポストされ得る。
受信は、それらがダイアログにポストされたのと同じ順序で、かつ、それらが合致する送信がポストされたのと同じメッセージ順で、完了する。
【０２２５】
ダイアログに対する入来データを受取るプリミティブが存在する（すなわち、ｄ＿ｒｃｖ）。このプリミティブは、ダイアログ、受け入れようとする入来データの最大長さ、プールマネージャリファレンス、結果ロケーション、および、そのプリミティブの完了前に送信側によってＥＯＭが知らせられるまで、受信側が待つか否かを示すフラグを表わす。このＥＯＭフラグがプリミティブによって示されると、指示された最大長さを越えるデータはすべて、打切られる（すなわち、最大長さを越えてあふれるデータは、打切りに先立って転送されるいかなるデータも上書きすることはない）。このＥＯＭフラグが示されない場合には、プリミティブは、メモリ領域が埋まるか、または、ＥＯＭがデータ転送と同時に送信側によって知らされるときに、完了する。受信されたデータは、指示されたプールマネージャリファレンスに関連する、バッファプールからの空きバッファ内に書込まれかつマッピングされる。データは、受信側のＩＦＥシステム環境に固有のＩ／Ｏバイト順に、バッファプールメモリ内に転送される。
【０２２６】
結果ロケーションは、プリミティブ結果情報を収めるのに使用されるべき、特定のメモリ領域、または、プールマネージャリファレンスを選択する。このプリミティブは、完了時の結果構造の実際のロケーションを示す。この結果ロケーションが特定のメモリ領域を表わす場合、結果構造はそこに書き込まれる。そうでなければ、結果構造は、結果ロケーション表示によって参照される、プールマネージャによって管理される、空きバッファに書かれる。この結果構造は、受信データからバッファプールへのマッピングを記述する、バッファリストを含む。この結果構造は、送信側のメッセージの長さ、および、ＥＯＭが受信データと同時に送信側によって知らされたかどうかを示すフラグを含む。この結果構造はまた、送信側からの、３２ビットのトークン値を含む。結果構造内のこのトークン値は、ＥＯＭフラグが真である場合にのみ有効である。また、ＥＯＭがメッセージ領域内の最終バイトと同時に知らされる場合には、ＥＯＭもまたプリミティブの結果内に知らされなければならないことに留意されたい。
【０２２７】
ダイアログのための入来データを、特定のメモリ領域内に受入れる、ｄ＿ｒｃｖプリミティブの変形が存在する。このプリミティブは、ダイアログ、受信データが書かれるメモリ領域（すなわち、長さのアドレス）、結果ロケーション、および、プリミティブの完了前に送信側によってＥＯＭが知らされるまで受信側が待つか否かを示すフラグ、を表わす。この結果構造は、送信側のメッセージの長さ、および、ＥＯＭが受信データと同時に送信側によって知らされたかどうかを示すフラグ、を含む。
【０２２８】
ダイアログのための入来データを受取りかつ、ユーザが特定するメモリ領域およびバッファプールへと分散させる、ｄ＿ｒｃｖプリミティブの変形が存在する。このプリミティブは、ダイアログ、分散リスト、結果ロケーション、および、ＥＯＭがプリミティブの完了前に送信側によって知らされるまで受信側が待つかどうかを示すフラグ、を表わす。分散リスト内の要素は、特定のメモリ領域（長さのアドレス）、または、プールマネージャオブジェクトリファレンスを表わす。受信されたメッセージは、分散リストに示された長さおよび種類に従って、メモリ領域または空きバッファ内に分散される。分散リストは、１または複数の要素をサポートする。空きバッファが、現時点における分散リストの要素が満たされる前に埋まってしまった場合、別の空きバッファを使用して、分散リストのその部分が完了される。参照されたプールマネージャオブジェクトは、空きバッファを選択するのに使用される制御を適用する。結果構造は、受信データのバッファプールへのマッピングを記述するバッファリストを含む。結果構造はまた、送信側のメッセージの長さ、および、受信データと同時にＥＯＭが送信側によって知らされたかどうかを示すフラグ、を含む。結果構造内のトークン値は、ＥＯＭが真である場合にのみ有効である。
【０２２９】
ｄ＿ｒｃｖの自動的に反復する変形が、バッファプールのみに受信するために、提供される。ｄ＿ｒｃｖの自動的に反復する変形は、バッファプールおよびユーザに特定されるメモリ領域のいかなる組合せにも分散するために、提供される。
【０２３０】
未処理のｄ＿ｒｃｖプリミティブの取消しをサポートする、ｉ＿ｃａｎｃｅｌプリミティブが存在する。未処理のｄ＿ｒｃｖプリミティブに対するｉ＿ｃａｎｃｅｌプリミティブが受信されると、ＩＦＥはできるだけ早く未処理のｄ＿ｒｃｖプリミティブを終了させる。指示されたｄ＿ｒｃｖプリミティブは、ｉ＿ｃａｎｃｅｌが有効となる前に受信がうまく完了した場合に、ｇｏ表示を返す。さもなければ、ｄ＿ｒｃｖプリミティブは、ｎｏ−ｇｏ表示を返す。
【０２３１】
ＩＦＥは常に、ｄ＿ｒｃｖプリミティブの完了について表示する。ＩＦＥは常に、ｄ＿ｓｅｎｄプリミティブの完了を表示する。
【０２３２】
通知方式は、より高いレベルのエンティティと相関関係にある。通知（ＣＩＡ＿ＤＩＡＬＯＧ＿ＦＡＵＬＴ＿ＮＯＴＩＦＩＣＡＴＩＯＮ）が存在するが、これは、ダイアログ障害条件が生じたことを示すのに使用される。この通知は、ホストのコンテキストおよびダイアログ記述子値、ならびに、ＩＦＥの実装に特有の理由コードを表わす。ダイアログ破壊（ｄ＿ｄｅｓｔｒｏｙ）意味規則は、ＣＩＡ＿ＤＩＡＬＯＧ＿ＦＡＩＬＵＲＥ＿ＮＯＴＩＦＩＣＡＴＩＯＮが示されかつ、ｔｅｒｍｉｎａｔｅ＿ｏｎ＿ｄ＿ｆａｕｌｔオプションが動作可能とされると、ダイアログに対して自動的に実行される。ダイアログに対するデータ転送障害は、ダイアログ障害通知を通じて指示される。データ転送の失敗は、活性なｄ＿ｓｅｎｄ／ｄ＿ｒｃｖプリミティブが、通知エンティティに対して「ｎｏ　ｇｏ」条件を示すようにする。データ転送障害は、下位クラウド（ｃｌｏｕｄ）がすべての誤り回復および再伝送動作を試みて失敗した後に、発生する。
【０２３３】
ダイアログオプション（ｔｅｒｍｉｎａｔｅ＿ｏｎ＿ｄ＿ｆａｕｌｔ）があるが、これは、データ転送ダイアログ障害がダイアログの失敗終了を引起こすかどうかを判定する（すなわち、ｄ＿ｄｅｓｔｒｏｙ意味規則がダイアログに対して自動的に実行される）。
【０２３４】
ダイアログオブジェクトを局所ＩＦＥ上に作成するのに使用される、プリミティブが存在する（すなわち、ｄ＿ｃｒｅａｔｅ）。このプリミティブは、新しく作成されたダイアログオブジェクトに対してダイアログ障害が表示されたときに使用されねばならない、ダイアログ記述子を表わす。他のダイアログ制御オプションも、ｄ＿ｃｒｅａｔｅプリミティブに含むことが可能である（たとえば、優先順位、送信のサービスのクラス、ダイアログ障害オプションが動作可能／動作不能にされるかどうか、送信取消し意味規則、ダイアログ障害通知情報）。このプリミティブはまた、このダイアログに対して任意の１時点で有する可能性のある、未処理のｄ＿ｒｃｖプリミティブの数のカウントを提供する。ｄ＿ｒｃｖプリミティブのＡＵＴＯ変形を使用するダイアログについては、このカウントは通常、１であるべきである。ダイアログオブジェクトがうまく作成された場合、このダイアログオブジェクトに一意のハンドルが返され、ダイアログ関連情報（すなわち、ダイアログの内容）もまた返される。このダイアログハンドルは、特定のＩＦＥ内では一意であるが、複数のＩＦＥにわたって必ずしも一意であるわけではない。
【０２３５】
局所ダイアログオブジェクトを遠隔ダイアログオブジェクトと関連付けるのに使用される、プリミティブが存在する（すなわち、ｄ＿ａｓｓｏｃｉａｔｅ）。このプリミティブは、ダイアログハンドル、ノードハンドル、および、遠隔ダイアログの内容を表わす。指示されるダイアログは、既に関連付けられていてはならない。関連付けがうまく完了したかどうかを示すステータスが返される。
【０２３６】
ダイアログに関連する未処理のプリミティブを優雅に終了させるのに使用される、プリミティブが存在する（すなわち、ｄ＿ｓｈｕｔｄｏｗｎ）。このプリミティブは、ダイアログハンドルを表示する。このプリミティブは、指示されたダイアログに関連する、すべての未処理のプリミティブの優雅な取消しを起動する。このプリミティブは、指示されたダイアログに関連する他のすべてのプリミティブが完了を知らせない限り、完了を知らせない。
【０２３７】
ダイアログオブジェクトを破壊するのに使用される、プリミティブが存在する（すなわち、ｄ＿ｄｅｓｔｒｏｙ）。このプリミティブは、ダイアログハンドルを表わす。このプリミティブは、ダイアログを優雅にクローズすることはない。なぜなら、指示されたダイアログに関連する未処理のｄ＿ｒｃｖプリミティブに結合されていたバッファプール資源が、正しく返されない場合があるためである。ｄ＿ｄｅｓｔｒｏｙプリミティブは、（このプリミティブ自身以外の）未だダイアログにポストされているプリミティブに対しては取消しステータスの表示を行なって、完了ルーチンを呼出す。この指示されたダイアログオブジェクトは削除される。
【０２３８】
１つの好ましい実施の形態においては、ダイアログに対して以下の制限を加えることも可能であるが、これらは本発明を限定するものではない。ダイアログ間には、順序付けは何もない。同じ端点による同じダイアログ上の送信と受信との間には、何の順序付けもない（順序付けは一方方向である）。ダイアログが開いている間に、送信のサービスのクラスの変更をサポートする必要はない。
【０２３９】
１つの好ましい実施の形態においては、ダイアログについて以下のことが言える。すなわち、ある簡単な形の収集が、ｄ＿ｓｅｎｄの変形を使用して、端点によって明示的に行なわれ得る。また、簡単な形の分散が、ｄ＿ｒｃｖの変形を使用して、端点によって明示的に行なわれ得る。
【０２４０】
５．バッファプール
バッファプールは、ローカルで発生したバッファプール創出要求（ｂｐｃｒｅａｔｅプリミティブ）の結果作られる。プルデータモデルでは、バッファプール（ＢＰ）の創出には、局所バッファプールと関連するリモートノード上のバッファプールシャドウオブジェクト（ＢＰＳ）の創出も必要である。バッファプールシャドウは、それがシャドウする元のバッファプールオブジェクトより多い状態情報を含み得る。ＩＦＥは、バッファプールおよびバッファプールシャドウ創出（ｂｐｃｒｅａｔｅ）、削除（ｂｐｄｅｓｔｒｏｙ）、属性変更（ｂｐｓｅｔｌｏｗｗａｔｅｒ標）ならびにクレジット（ｂｐｓｕｐｐｌｙｃｒｅｄｉｔ）についての、ＣＩＡ意味規則を支持する独自の内部論理ダイアログを使用することができる。バッファプールオブジェトおよびバッファプールシャドウオブジェクトの例を以下に挙げる。
【０２４１】
【表４】
2004005661.tif 000006
【０２４２】
ｄｅｓｔｒｏｙ（破壊）フィールド（ｄｅｂｉｔ，　ｐｕｒｇｅｄ，　ｐｕｒｇｅｉｎｐｒｏｇｒｅｓｓ，　ｄｅｓｔｒｏｙｉｎｐｒｏｇｒｅｓｓ，　ｒｅｑｂｐｄｅｓｔｒｏｙ）は、ｂｐｄｅｓｔｒｏｙプリミティブのための正確な意味規則行動の実現を助ける。プールの規則によれば、ｂｐｄｅｓｔｒｏｙオペレーションは、すべてのプールマネジャが更新されかつこのバッファプールからバッファ行きのデータの全転送が完了するまで完了として知らされない。
【０２４３】
ｃｒｅｄｉｔ（クレジット）は、バッファプールにクレジットされたバッファアドレスの総数を記憶する。
【０２４４】
ｄｅｂｉｔ（デビット）は、「完了した」（ｐａｙｂｕｆｆｅｒｃｏｍｐｌｅｔｅｐａｙｌｏａｄｓにより示される）を有するバッファアドレスの総数をカウントする。
【０２４５】
ｐｕｒｇｅｄ（パージド）は、ｂｐｄｅｓｔｒｏｙオペレーションが進行中でないかぎり、普通はゼロである。ｐｕｒｇｅｄは、リモートノードが特定のｂｕｆｆｅｒｐｏｏｌｓｈａｄｏｗから未結合バッファをパージすることを要求する特定のｍｇｒｔｈｒｅａｄオペレーションの結果である。リモートｍｇｒｔｈｒｅａｄは、パージされたアドレスの数を表し、ｐｕｒｇｅｄ　ｃｏｕｎｔ（パージドカウント）は、この値を記憶する。別個のフィールド（すなわちｐｕｒｇｅｄ）を使えば、ｐａｙｂｕｆｆｅｒｃｏｍｐｌｅｔｅ　ｐａｙｌｏａｄｓを処理する際に、ｒｃｖｆｒａｍｅｈａｎｄｌｅｒにおいてロック状態を作る必要を回避できる。この他には、ｐｕｒｇｅｄフィールドを省略し、ｄｅｂｉｔフィールドを変更することができる。
【０２４６】
ｐｕｒｇｅｉｎｐｒｏｇｒｅｓｓは、ｒｃｖｆｒａｍｅハンドラへのｂｐｄｅｓｔｒｏｙ完了処理を行わないという信号として使用される。ｂｐｄｅｓｔｒｏｙオペレーションが完了したと知らせることができる時期について、３つのシナリオが存在する。バッファプールについて、未処理のクレジットが存在しなければ、ｍｇｒｔｈｒｅａｄは、リモートノードからｍｇｒｂｐｄｅｓｔｒｏｙ応答を受け取った後、全くパージを行う必要なくｂｐｄｅｓｔｒｏｙを完了する。未処理のクレジットが存在する場合、ｍｇｒｔｈｒｅａｄはｍｇｒｂｐｐｕｒｇｅを発行して、未結合のバッファをパージし、応答を受けた後も、完了していないバッファがある場合には、ｍｇｒｔｈｒｅａｄはｒｃｖｆｒａｍｅｈａｎｄｌｅｒに依存して、ｂｐｄｅｓｔｏｒｙ完了処理を行う。パージの結果が、すべてのバッファがリターンしたことを示す場合、ｍｇｒｔｈｒｅａｄは、ｂｐｄｅｓｔｒｏｙ完了処理自体を行う。
【０２４７】
ｄｅｓｔｒｏｙｉｎｐｒｏｇｒｅｓｓは、現在破壊が行われているバッファプールのための新しいオペレーションの実行を阻止するために使用するフラグである。
【０２４８】
ｒｅｑｂｐｄｅｓｔｒｏｙは、ｂｐｄｅｓｔｒｏｙオペレーションに関連する元のｒｅｑを記憶する。
【０２４９】
ペイロードコマンドフィールド（ｄａｔａｃｍｄ，　ｒｓｌｔｃｍｄ）は、このバッファプールに関連するバッファアドレスへ記憶する際に、リモートノードにより使用される必要がある。バッファプールがデータの転送に使用される場合、ｄａｔａｃｍｄを使用する必要があり、かつバッファプールアドレスが結果転送に使用される際、ｒｓｌｔｃｍｄを使用する必要がある。
【０２５０】
アドレスチェッキングフィールド（ｓｌｏｔｃｏｕｎｔ，　ｓｌｏｔｔａｋｅ，　ｓｌｏｔｐｕｔ，　ｓｌｏｔ）を使用して、このバッファプールに関連する入来の記憶についてアドレスチェックを行う。スロットアレイは、リモートノードバッファプールシャドウにクレジットされた現在のアドレスの組を記憶する。ｓｌｏｔｃｏｕｎｔは、スロットアレイにおけるエントリの数である。ｓｌｏｔｃｏｕｎｔは、付加的なスロットで現在クレジットされている（が必ずしもリモートノードにより受け入れられていない）クレジットを記憶する必要があるので、ｉｎｆｏ．ｐａｒａｍｓ．ｓｌｏｔｓより大きくなる。このことにより、スロットのリストにおいてどのアドレスがリモートノードにより「結合」されていて、ローカルノードによりまだ発見されていないかを必ずしも知っているわけではないので、ローカルノードがリモートノードより多くのスロットを必要とするという状況が発生する。
【０２５１】
ｓｌｏｔｔａｋｅおよびｓｌｏｔｐｕｔは、スロットアレイに関する呼び出しインデックスである。クレジットがバッファプールへ供給されると、ｓｌｏｔｐｕｔが進められる。バッファアドレスが使われると、ｓｌｏｔｔａｋｅが進められる。
【０２５２】
６．プールマネジャ
ＰＯＯＬ　ＭＡＮＡＧＥＲは、ローカルで発生したｐｍ＿ｃｒｅａｔｅ要求の結果として創出される。プルモデルデータでは、プールマネジャの創出には、プールに関連するリモートノード上の類似するプールマネジャオブジェクトの創出も必要とする。リモートノード上の関連する構成（オブジェクト）は、ＰＯＯＬ　ＭＡＮＡＧＥＲ　ＳＨＡＤＯＷ（ＰＭＳ）と呼ばれる。ＩＦＥは、独自の内部論理ダイアログを用いて、プールマネジャならびにプールマネジャシャドウ創出（ｐｍ＿ｃｒｅａｔｅ）、削除　（ｐｍ＿ｄｅｓｔｒｏｙ）、およびプール制御追加（ｐｍ＿ａｄｄ＿ｃｏｎｔｒｏｌ）のためのＣＩＡ意味規則を支持することができる。
【０２５３】
【表５】
2004005661.tif 000007
【０２５４】
７．プールマネジャシャドウ
ＰＯＯＬＭＡＮＡＧＥＲＳＨＡＤＯＷは、これがシャドウするＰＯＯＬＭＡＮＡＧＥＲに非常に類似する。
【０２５５】
【表６】
2004005661.tif 000008
【０２５６】
８．バッファプールで受信するためのＲＣＢ
一般に、ＲＣＢは、ＣＣＢ１６１４をパスしたｄｒｃｖパラメータを含む（ｄｒｃｖのＯＰコードを除く）。
【０２５７】
９．ダイアログオブジェクト
この構成は、ダイアログオブジェクトを実現するのに必要な状態を規定する。
【０２５８】
【表７】
2004005661.tif 000009
【０２５９】
【表８】
2004005661.tif 000010
【０２６０】
【表９】
2004005661.tif 000011
【０２６１】
【表１０】
2004005661.tif 000012
【０２６２】
１０．ノード
ノードの構造は、相互接続上のリモートノードに関連するすべてのオブジェクトを追跡するのに使用されるコンテナを規定する。また、このｍｇｒ＿ｔｈｒｅａｄがリモートノード上のｍｇｒ＿ｔｈｒｅａｄと通信するのに使用する特定マネジャデータ構造も規定する。
【０２６３】
【表１１】
2004005661.tif 000013
【０２６４】
【表１２】
2004005661.tif 000014
【０２６５】
７．コンピュータシステムの例
本発明による通信内部接続アーキテクチャは、いずれのタイプのホストプロセッサ、マルチプロセッサ、ならびにそれに限られるわけではないが、ホストシステムおよびＷｉｎｄｏｗｓ（Ｒ）ＮＴ互換性プログラミングインタフェースを含むプログラミングインタフェース上のトランスポート機能として実現できる。
【０２６６】
図１８は、本発明が機能するコンピュータシステム例１８のブロック図である。コンピュータシステム１８００は、プロセッサ１８０４等の１以上のプロセッサを含む。プロセッサ１８０４は、通信バス１８０２に接続される。
【０２６７】
コンピュータシステム１８００は、メインメモリ１８０８、好ましくはランダムアクセスメモリ（ＲＡＭ）も含み、また二次メモリ１８１０を含み得る。二次メモリ１８１０は、たとえば、ハードディスクドライブ１８１２および／またはフロッピー（Ｒ）ディスクドライブ、磁気テープドライブ、光ディスクドライブ等の取り外し可能な記憶ドライブ１８１４を含み得る。取り外し可能な記憶ドライブ１８１４は、周知の態様で取り外し可能な記憶ユニット１８１８から／へ読み出し／書込みを行う。取り外し可能な記憶ユニット１８１８の代表がフロッピー（Ｒ）ディスク、磁気テープ、光ディスク等であり、これらは取り外し可能記憶ドライブ１８１４によって書込み／読出しが行われる。取り外し可能記憶ユニット１８１８が、コンピュ‐タソフトウエアおよび／またはデータを内部に記憶したコンピュータが使用可能な媒体を含むことはもちろんである。
【０２６８】
他の実施例としては、二次メモリ１８１０がコンピュータシステム１８００にコンピュータプログラムや他の命令をロードできるようにする他の同様の手段を含み得る。そのような手段には、たとえば取り外し可能記憶ユニット１８２２およびインタフェース１８２０を含み得る。たとえば、プログラムのカートリッジとカートリッジインタフェース（ビデオゲーム装置に見られるようなもの）、取り外し可能なメモリチップ（ＥＰＲＯＭまたはＰＲＯＭ等）と関連のソケット、およびソフトウエアおよびデータを取り外し可能な記憶ユニット１８２２からコンピュータシステム１８００へ転送することができる他の取り外し可能な記憶ユニット１８２２とインタフェース１８２０が考えられる。
【０２６９】
コンピュータシステム１８００は、通信インタフェース１８２４も含み得る。通信インタフェース１８２４によりソフトウエアとデータを、通信経路１８２６を介してコンピュータシステム１８００と外部の装置との間で転送することができる。通信インタフェース１８２４の例には、モデム、ネットワークインタフェース（イーサネット（Ｒ）カード等）、通信ポート等が考えられる。通信インタフェース１８２４により転送されるソフトウエアとデータは、通信経路１８２６を介して、通信インタフェース１８２４が受信することのできる電子、電磁、光学および他の信号の信号形式のものである。通信インタフェース１８２４は、コンピュータシステム１８００がインターネット等のネットワークにインターフェースできる手段を提供する。
【０２７０】
本発明は、この例示的状況について記載されている。これらの条件における記載は、便宜上のものである。本発明は、この例示的状況における応用に限定されるものではない。実際、以下の説明を読めば、当業者には他の状況下においても本発明を実現する方法が明らかになるであろう。
【０２７１】
本発明は、上記の説明に類似の環境で動作する（すなわち実行する）ソフトウエアを使用して実現され得る。本明細書においうては、「コンピュータプログラム製品」と言う語は、一般に取り外し可能記憶装置１８１８またはハードディスクドライブ１８１２にインストールしたハードティスクを指すものとして使用される。これらのコンピュータプログラム製品は、コンピュータシステム１８００にソフトウエアを提供するための手段である。
【０２７２】
コンピュータプログラム（コンピュータ制御論理とも呼ぶ）は、メインメモリおよび／または二次メモリ１８１０に記憶される。コンピュータプログラムも通信インタフェース１８２４を介して受信できる。これらコンピュータプログラムは、実行されるとコンピュータシステム１８００を能動化して本明細書中に記載する発明の構成を実行する。したがって、これらのコンピュータプログラムは、コンピュータシステム１８００のコントローラに相当する。
【０２７３】
ソフトウエアを用いて発明を実現する実施例では、取り外し可能記憶ドライブ１８１４、ハードドライブ１８１２または通信インタフェース１８２４を使用して、ソフトウエアをコンピュータプログラム製品に記憶し、コンピュータシステム１８００にロードする。この他、コンピュータプログラム製品を通信経路１８２６上でコンピュータシステム１８００へダウンロードしてもよい。制御論理（ソフトウエア）をプロセッサ１８０４で実行すると、プロセッサ１８０４は、本明細書中に記載の発明の機能を実行する。
【０２７４】
このコンピュータシステムの例に関して様々なソフトウエアの実施例を記載する。この説明を読めば、他のコンピュータシステムおよび／またはコンピュータアーキテクチャを使用して本発明を実現する方法が当業者には明らかになろう。
【０２７５】
他の実施例では、本発明は、たとえば特定用途向け集積回路（ＡＳＩＣ）等のハードウエアコンポーネントを用いて、基本的にファームウエアおよび／またはハードウエアで実現される。本明細書中に記載の機能を実現するためにハードウエアステートマシンを実現することは、当業者にとり自明であろう。
【０２７６】
８．ＣＩＡ−ＩＦＥインタフェースの例
ａ．ＣＩＡ−ＩＦＥ初期化
ＣＩＡのクライアント（ユーザクライアントおよび／またはカーネルクライアント）は、５つのインタフェース手続きを使用することができる。すなわちＣｉａＩｎｉｔｉａｔｅ、ＣｉａＴｅｒｍｉｎａｔｅ、ＣｉａＩｆｅＥｎｕｍ、ＣｉａＩｆｅＯｐｅｎおよびＣｉａＩｆｅＣｌｏｓｅである。ＣｉａＩｎｉｔｉａｔｅルーチンは、クライアントに状態情報を割当て初期化する。他のＣＩＡインタフェース手続きのいずれかを呼び出す前に、各ＣＩＡクライアントは、ＣｉａＩｎｉｔｉａｔｅルーチンを一度呼び出す必要がある。このルーチンは、ＣＩＡの実現に、そのクライアントについてのＣＩＡ意味規則を適正に実現するために必要な状態情報を割当て、初期化するチャンスを与える。
【０２７７】
ＣｉａＴｅｒｍｉｎａｔｅルーチンは、通常、ＣＩＡクライアントがＣＩＡサービスをそれ以上必要をしない場合に、呼び出す。このルーチンは、ＣＩＡの実現に、そのクライアントに割当てられた状態を（割当て）解除するチャンスを与える。ユーザレベルに関連する状態情報は、ユーザプロセスがＣｉａＴｅｒｍｉｎａｔｅを呼び出さず突然終了しても自動的に解除される。
【０２７８】
ＣｉａＩｆｅＥｎｕｍルーチンは、ＣＩＡ　Ｐｒｉｍｉｔｉｖｅ　Ｉｎｔｅｒｆａｃｅに登録したＩＦＥのセットを決定するために使用できる。各ＩＦＥに関する属性もリターンされる。これには、名称、アドレス、バージョン、タイプおよび制御ブロックサイズ情報が含まれる。
【０２７９】
ＣｉａＩｆｅＯｐｅｎルーチンは、登録されたＩＦＥを開き（名称で）かつそのリファレンスを取得するために使用可能である。必要なら、ＩＦＥを初期化する。このルーチンの出力パラメータは、開かれたＩＦＥ行きのＣＣＢのＩＦＥフィールドで使用すべきＩＦＥハンドルを示す。クライアントは、ＩＦＥの最初期化を生じることなく、同じＩＦＥを一度以上開くことができる。リターンされたＩＦＥハンドルは、同じ名称のＩＦＥの複数のオープンと同じ値でも良いし、同じでなくても良い。
【０２８０】
ＣｉａＩｆｅＣｌｏｓｅルーチンは、先に開かれたＩＦＥに対するクライアントの参照を閉じる（クローズする）ために使用する。ＩＦＥ処理の最後のクローズでは、そのＩＦＥに関連する状態の割り当てが解除される。ユーザレベルクライアントが、開いた各ＩＦＥについてＣｉａＩｆｅＣｌｏｓｅを呼び出すことなく突然終了した場合、ＩＦＥは自動的に閉じられる。
【０２８１】
ＣｉａＩｆｅＯｐルーチンは、ＩＦＥに対し、ＣＩＡプリミティブを発行するために使用可能である。このルーチンは、非ブロックで、プリミティブが完了したことをクライアントに知らせるプロシージャコールバック機構を使用する。ＣＣＢは、プリミティブを記述するＣｉａＩｆｅＯｐおよびＩＦＥへ送られ、実行されることになる。ある例では、クライアントが割当てるＣＣＢの実際のサイズは、少なくともＩＦＥのＣｉａＩｆｅＥｎｕｍの結果においてリターンされる制御ブロックのサイズ以上である。制御ブロックの末端の追加スペースは、ＩＦＥの作業空間でありかつＩＦＥ特定の用途についてリザーブされる。
【０２８２】
ｂ．ＣＩＡプロバイダ
図１９は、２つのＣＩＡプロバイダを示す。すなわちＣＩＡ　ＭＥＭ．ＳＹＳおよびＣＩＡ　ＸＸＸ．ＳＹＳである。この例では、ＣＩＡプロバイダは、１以上の内部接続に渡ってＣＩＡ意味規則を実現するＮＴドライバである。ＣＩＡプロバイダがレジスタするＩＦＥのセットは以下のものと相関関係がある。すなわち、
１．システムにインストールされたハードウエア。
２．構成レジストリにおける特定のエントリの実現。
３．プロバイダが支持するアタッチメントスタイル。
【０２８３】
ＣＩＡプロバイダは、インタフェースを使って、ＩＦＥオブジェクトを創出しかつそれらをＣＩＡ　Ｐｒｉｍｉｔｉｖｅ　Ｉｎｔｅｒｆａｃｅにレジスタまたはアンレジスタする。ＣＩＡプロバイダは、好ましくは、一意の名称（ローカルＮＴに一意）で各ＩＦＥオブジェクトをレジスタする。関連の内部接続アダプタがある場合には、ＣＩＡプロバイダは、ＩＦＥの名称の一部としてＰＣＩバスおよび装置情報を使用することによって一意のＩＦＥ名称を発生し得る。ＣＩＡプロバイダは、ドライバがアンロードされなければ（ｓｃ　ｓｔｏｐ＜ｄｒｉｖｅｒ＞等）、ＩＦＥをアンレジスタしない。そのＩＦＥのすべてが閉じられなければ、ドライバはアンロードされない。
【０２８４】
ｃ．ＩＦＥアタッチメントスタイル
図２０に示すとおり、ＣＩＡは３つのアタッチメントスタイルを定義する。すなわち、ポイント・トゥー・ポイント（２点間）、ループバックおよびメッシュである。ＣＩＡプロバイダは、同時に複数のアタッチメントスタイルを支持してもよい。ポイント・トゥー・ポイントアタッチメントでは、異なるシステムからの２つのＩＦＥオブジェクトを正確に結合する。ループバックアタッチメントは、同じシステムからの２つのＩＦＥを接続する。ループバック接続は、同じシステム上で動作する２つのアプリケーション間のＣＩＡアプリケーションを支持するために使用される。メッシュアタッチメントは、１以上のシステムからの１以上のＩＦＥを接続する。
【０２８５】
ｄ．ＣＩＡ代理　（プロキシ）ドライバ
Ｗｉｎｄｏｗｓ（Ｒ）　ＮＴ　ＣＩＡ実現は、非カーネルのＣＩＡクライアントおよび他のシステム（ＭＣＰ等）のＩＦＥオブジェクトのホスティングを支持する。これらのサービスは、図２１に示すＣＩＡ代理ドライバが提供する。ＣＩＡ　ＵＳＥＲ．ＳＹＳは、ローカルのＷｉｎ３２クライアントの代理ドライバとして作用する。これが提供するサービスは以下の通り。
１．ユーザ／カーネル境界でＣＩＡ意味規則を実現するＮＴ　ＩＯインタフェースおよびＣＩＡ．ＤＬＬへインターフェースする。
２．ＣＩＡプリミティブが参照するユーザメモリ領域のメモリ管理（プローブ、ロック、アンロック）を行う。
３．ＣＩＡ　Ｐｒｉｍｉｔｉｖｅ　Ｉｎｔｅｒｆａｃｅを実現する。なお、ＣＩＡ　ＵＳＥＲ．ＳＹＳは、実際のＣＩＡプリミティブ（ｄ＿ｓｅｎｄ等）は実現しない。プリミティブをＩＦＥに向けるＣｉａＩｆｅＯｐルーチンを実現する。
【０２８６】
リモートホスト代理ドライバは、以下のサービスを提供する。
１．リモートホストメモリ読出し・書込みサービス
２．リモートホスト特定ＣＣＢから固有のＮＴ　ＣＣＢを創出（大から小エンディアンフォーマットへフィールドを変換する変換等）
３．ＣＩＡ固有ＮＴ　ＣＣＢ結果を特定ホストフォーマットへ変換する変換
４．ＣＩＡ固有通知機構（すなわちコールバック）をリモートホストに適切な機構に変換する変換
ＣＩＡは、複数のリモートホスト代理ドライバを支持する。リモートホスト代理ドライバも、複数のリモートホストインタフェースアダプタを支持することが可能である。各リモートホストインターフェースアダプタは一意のｎｏｄｅ＿ｉｎｔｅｒｆａｃｅ値を割当てられる。ｎｏｄｅ＿ｉｎｔｅｒｆａｃｅ値は、メッシュベースのＣＩＡプロバイダが入来フレームを正しいＩＦＥに向けるために必要とするアドレス指定情報を提供する（複数のＩＦＥが同じ内部接続アダプタを共有する可能性あるので）。ｎｏｄｅ＿ｉｎｔｅｒｆａｃｅ値の割当ては、ＣＩＡ　Ｐｒｉｍｉｔｉｖｅ　Ｉｎｔｅｒｆａｃｅにより複数の代理ドライバの間で調整される。
【０２８７】
代理ドライバは、ＣｉａＩｎｉｔｉａｔｅの呼び出し者に割当てられたｎｏｄｅ＿ｉｎｔｅｒｆａｃｅ値を示す。代理ドライバ（Ｗｉｎ３２、リモートホスト等）により行われるプログラミングインタフェースは、そのｎｏｄｅ＿ｉｎｔｅｒｆａｃｅ値が、ＣｉａＩｎｉｔｉａｔｅによりリターンされるものに一致するＩＦＥのみを開くことができる。このエンフォースメントは、代理ドライバの責任である。カーネルベースのＣＩＡクライアントは、どのＩＦＥオブジェクトでも開くことができる。代理ドライバでないカーネルベースのＣＩＡクライアントは、そのｎｏｄｅ＿ｉｎｔｅｒｆａｃｅ値がＣｉａＩｎｉｔｉａｔｅがリターンするものに一致するＩＦＥだけを開く必要がある。
【０２８８】
ｅ．ＩＦＥアドレス指定
図２２および２３は、ＩＦＥアドレス指定スキームの例を示す。図２２は、２つの部分から成るアドレス（ｄｕｐｌｅ）を使用してアドレス指定されたメッシュベースのアタッチメント上のＩＦＥを示す。第１の部分は、ｎｏｄｅ＿ｉｄと呼ばれ、ＩＦＥが論理的に付属するハードウエアアダプタのＭＡＣアドレスを指す。第２の部分は、ｎｏｄｅ＿ｉｎｔｅｒｆａｃｅと呼ばれ、そのＩＦＥに対し作用する代理エージェントを指す。
【０２８９】
図２３に示すとおり、ＩＦＥのグループがアタッチメントグループを構成する。各ＩＦＥも、そのアタッチメントグループを指す属性を有する。ＣＩＡクライアントは、アタッチメントグループの値を調べて、図２３に示すＩＦＥの関連のセットを決定する。
【０２９０】
９．結論
本発明の様々な実施例について上に記載したが、これらは、例示の目的のみのものであって限定を意図するものではないことを理解されたい。当業者においては、添付の請求項に記載の発明の精神および範囲から逸脱することなく、形態および細部について様々な変更が可能であることを理解されるであろう。したがって、本発明の範囲は、上記の実施例のいずれによっても限定されることなく、以下の請求項およびその均等物にしたがってのみ規定される。
【図面の簡単な説明】
【図１Ａ】この発明に従う通信内部接続アーキテクチャ（ＣＩＡ）インターフェイスを示す概略図である。
【図１Ｂ】図１ＡのＣＩＡインターフェイスのためのメッセージシステムの概略図である。
【図１Ｃ】図１ＡのＣＩＡインターフェイスのためのＣＩＡプリミティブおよび意味規則の組の概略図である。
【図２】この発明に従うＣＩＡ内部接続の概略図である。
【図３】Ｗｉｎｄｏｗｓ（Ｒ）　ＮＴＴＭ環境において統合されるＣＩＡ意味規則を示す概略図である。
【図４】この発明に従うＣＩＡアーキテクチャにおけるノードオブジェクトを示す概略図である。
【図５】この発明に従うＣＩＡアーキテクチャにおけるＤＩＡＬＯＧオブジェクトを示す概略図である。
【図６Ａ】この発明に従う「バッファで受信」型のＣＩＡデータ通信において用いられるＣＩＡオブジェクトの例を示す概略図である。
【図６Ｂ】この発明に従う「バッファで受信」型のＣＩＡデータ通信において用いられるＣＩＡオブジェクトの例を示す概略図である。
【図７Ａ】この発明に従うプルモデルデータ通信のルーチンを示すフローチャートである。
【図７Ｂ】この発明に従うプルモデルデータ通信のルーチンを示すフローチャートである。
【図８】この発明に従う２つのサービスクラス（アーリー・ファー・エンドおよびファー・エンド）をさらに示すデータ転送を示す流れ図である。
【図９】送信要求が受信要求に先行する場合を除く図８のようなデータ転送に対する流れ図である。
【図１０】この発明に従う複数受信および送信要求を示すデータ転送に対するフローである。
【図１１】この発明に従う例示的自動受信プリミティブオペレーションを示す流れ図である。
【図１２】この発明に従う部分メッセージを用いるデータ転送の一例を示す流れ図である。
【図１３】この発明に従う部分メッセージおよびＥＯＭメッセージの組合せを用いるデータ転送の一例を示す流れ図である。
【図１４Ａ】この発明に従うタイプ１サービスにおける論理ダイアログを確立するための例示的ルーチンを示す。
【図１４Ｂ】この発明に従うタイプ２サービスにおける論理ダイアログを確立するための例示的ルーチンを示す。
【図１５Ａ】この発明に従うユーザレベル管理ダイアログを確立するよう用いられる例示的状態図である。
【図１５Ｂ】この発明に従うユーザレベル管理ダイアログを確立するための例示的ルーチンのフローチャートである。
【図１５Ｃ】この発明に従うユーザレベル管理ダイアログを確立するための例示的ルーチンのフローチャートである。
【図１６】この発明に従う「バッファプールで受信」タイプのＣＩＡデータ通信において用いられるＣＩＡオブジェクトの例を示す概略図である。
【図１７】この発明に従う「バッファプールで受信」タイプのＣＩＡデータ通信において用いられるＣＩＡオブジェクトの例を示す概略図である。
【図１８】この発明を実現する例示的コンピュータシステムのブロック図である。
【図１９】この発明において用いるためのＣＩＡプロバイダのブロック図を示す。
【図２０】この発明において用いるためのさまざまなＩＦＥ接続機構スタイルのブロック図を示す。
【図２１】この発明において用いるためのＣＩＡ代理ドライバのブロック図を示す。
【図２２】この発明に従う例示的ＩＦＥアドレス指定のブロック図である。
【図２３】この発明に従う例示的ＩＦＥ接続機構群のブロック図である。
【符号の説明】
１０２，５１０−５１５，３１０２　アプリケーション、１１０　データ通信ネットワーク、２０２　共通メッシュ、３４０　接続アダプタ、３１１，３２１，３３１　ＣＩＡクライアント、３２０　ＣＩＡプリミティブインターフェイス、３００　ＣＩＡ意味規則、２１５，３２２−３２４　ＩＦＥ、４０１−４０６，１１４０　ノード、５２０，５３０，５４０　論理ダイアログ、６１１−６１９　ＣＣＢ、１１２０　内部接続フロントエンドユニット、１２００　ＣＩＡプリミティブ、１７５０　プールマネージャシャドウ、１８１８　記憶ユニット、１８２０インターフェイス、５０１−５０６，１１５０　ダイアログ、１０００通信内部接続アーキテクチャ（ＣＩＡ）、１０５０　ＣＩＡインターフェイス、１１８０　送信チャネル、１３００　ＣＩＡ管理サービス、１５００　管理ダイアログ確立アルゴリズム、１１６０，１６５０　プールマネージャ、１７４０バッファプールシャドウ、１８０２　通信バス、１８０４　プロセッサ、１８０８　メインメモリ、１８１０　二次メモリ、１８１４　取り外し可能な記憶ドライブ、１８２０　コンピュータシステム，１８２４　通信インターフェイス、１８２６　通信経路、３０００　ネットワーク化プロトコル組織、３１４０　ＬＡＮアダプタ。
【図１Ａ】
2004005661.tif 000015
【図１Ｂ】
2004005661.tif 000016
【図１Ｃ】
2004005661.tif 000017
【図２】
2004005661.tif 000018
【図３】
2004005661.tif 000019
【図４】
2004005661.tif 000020
【図５】
2004005661.tif 000021
【図６Ａ】
2004005661.tif 000022
【図６Ｂ】
2004005661.tif 000023
【図７Ａ】
2004005661.tif 000024
【図７Ｂ】
2004005661.tif 000025
【図８】
2004005661.tif 000026
【図９】
2004005661.tif 000027
【図１０】
2004005661.tif 000028
【図１１】
2004005661.tif 000029
【図１２】
2004005661.tif 000030
【図１３】
2004005661.tif 000031
【図１４Ａ】
2004005661.tif 000032
【図１４Ｂ】
2004005661.tif 000033
【図１５Ａ】
2004005661.tif 000034
【図１５Ｂ】
2004005661.tif 000035
【図１５Ｃ】
2004005661.tif 000036
【図１６】
2004005661.tif 000037
【図１７】
2004005661.tif 000038
【図１８】
2004005661.tif 000039
【図１９】
2004005661.tif 000040
【図２０】
2004005661.tif 000041
【図２１】
2004005661.tif 000042
【図２２】
2004005661.tif 000043
【図２３】
2004005661.tif 000044