(57)【特許請求の範囲】
【請求項１】
送信側クライエントと受信側クライエントとの間でデータを転送するプルモデルデータ通信を提供する方法であって、
（ａ）受信側において、受信側クライエントによって少なくとも１つの受信バッファが指定されると、前記受信側クライエントの前記少なくとも１つの受信バッファのメモリアドレスを識別するためのデータ宛先記述子を含む第１のネットワークパケットを構築し、前記送信側クライエントに送信するステップと、
（ｂ）送信側において、前記少なくとも１つの受信バッファを識別する前記メモリアドレスと、送信側クライエントから転送されて前記少なくとも１つの受信バッファに記憶されるべきデータを含む第２のネットワークパケットを構築し、前記受信側クライエントに送信するステップとを含み、前記送信側クライエントは、前記少なくとも１つの受信バッファを識別するメモリアドレスに対する要求を前記受信側クライエントに対して最初に発行することなく前記第２のネットワークパケットを前記受信側クライエントに送信する、方法。
【請求項２】
前記構築するステップ（ａ）が、バッファで受信オペレーションについてダイアログ受信制御ブロックを構築するステップをさらに含み、前記ダイアログ受信制御ブロックが、データを記憶すべき少なくとも１つの受信バッファの受信メモリアドレスを含むデータ宛先記述子パラメータを有するバッファでダイアログ受信プリミティブを含む、請求項１に記載の方法。
【請求項３】
前記構築するステップ（ａ）が、バッファプールで受信オペレーションについてのダイアログ受信制御ブロックを構築するステップを含み、前記ダイアログ受信制御ブロックが、バッファプールを識別するためのデータ宛先記述子パラメータを有するバッファプールでダイアログ受信プリミティブを含む、請求項１に記載の方法。
【請求項４】
前記データ宛先記述子パラメータが、プールマネジャをリファレンスする、請求項３に記載の方法。
【請求項５】
受信および送信側クライアントが、同じメモリ空間を共有し、かつメモリコピーオペレーションを行って前記データを受信側と送信側との間で転送するステップをさらに含む、請求項３に記載の方法。
【請求項６】
前記構築するステップ（ａ）が、受信バッファの物理的メモリアドレスおよび受信バッファの長さに関する情報を含むデータ宛先記述子を有する第１のネットワークパケットを構築する、請求項１に記載の方法。
【請求項７】
前記構築するステップ（ａ）が、受信バッファの物理的メモリアドレスを含むデータ宛先記述子を有する第１のネットワークパケットを構築する、請求項１に記載の方法。
【請求項８】
前記構築するステップ（ａ）が、論理メモリアドレスを含むデータ宛先記述子を有する第１のネットワークパケットを構築する、請求項１に記載の方法。
【請求項９】
前記論理メモリアドレスが、仮想メモリアドレスおよびタグのうち少なくとも１つを含む、請求項８に記載の方法。
【請求項１０】
送信側クライエントと受信側クライエントとの間でデータを転送するプルモデルデータ通信を提供するためのシステムであって、
受信側において、受信側クライエントによって少なくとも１つの受信バッファが指定されると、前記受信側クライエントで前記少なくとも１つの受信バッファのメモリアドレスを識別するためのデータ宛先記述子を含む第１のネットワークパケットを構築するための第１の構築手段、および、前記第１のネットワークパケットを前記送信側クライエントに送信するための手段を含み、
送信側において、前記少なくとも１つの受信バッファを識別する前記メモリアドレスと送信側クライエントから転送されて前記少なくとも１つの受信バッファに記憶されるデータとを含む第２のネットワークパケットを構築するための第２の構築手段、および、前記第２のネットワークパケットを前記受信側クライエントに送信するための手段を含み、前記送信側クライエントは、前記少なくとも１つの受信バッファを識別するメモリアドレスに対する要求を前記受信側クライエントに対して最初に発行することなく前記第２のネットワークパケットを前記受信側クライエントに送信する、システム。
【請求項１１】
前記第１の構築手段が、バッファで受信オペレーションについてのダイアログ受信制御ブロックを構成する手段を含み、前記ダイアログ受信制御ブロックが、データが記憶されることになる少なくとも１つの受信バッファの受信メモリアドレスを含むデータ宛先記述子パラメータを有するバッファでダイアログ受信プリミティブを含む、請求項10に記載のシステム。
【請求項１２】
前記第１の構築手段が、バッファプールで受信オペレーションについてのダイアログ受信制御ブロックを構成するための手段を含む、請求項10に記載のシステム。
【請求項１３】
前記データ宛先記述子パラメータがプールマネジャをリファレンスする、請求項12に記載の、システム。
【請求項１４】
受信側および送信側クライアントが、同じメモリ空間を共有し、かつ受信側および送信側クライアントの間で前記データを転送するメモリコピーオペレーションを行うための手段をさらに含む、請求項10に記載のシステム。
【請求項１５】
前記第１の構築する手段が、受信バッファの物理的メモリアドレスと受信バッファの長さに関する情報を含むデータ記述子パラメータを有する第１のネットワークパケットを構築する、請求項10に記載のシステム。
【請求項１６】
前記第１の構築する手段が、受信バッファの物理的メモリアドレスを含むデータ宛先記述子を有する第１のネットワークパケットを構築する、請求項10に記載のシステム。
【請求項１７】
前記第１の構築するステップが、論理メモリアドレスを含むデータ宛先記述子を有する第１のネットワークパケットを構築する、請求項10に記載のシステム。
【請求項１８】
前記論理メモリアドレスが、仮想メモリアドレスおよびタグのうち少なくとも１つを含む、請求項17に記載のシステム。
【請求項１９】
送信側クライアントと受信側クライアントとの間にプルモデルデータ通信を提供するための方法であって、
受信側クライアントでバッファプールを創出するステップと、
送信側クライアントでバッファプールシャドウを創出するステップを含み、前記バッファプールシャドウが、受信側クライアントの前記バッファプールに対応する、方法。
【請求項２０】
受信側クライアントでプールマネジャを創出するステップと、
送信側クライアントでプールマネジャシャドウを創出するステップを含み、前記プールマネジャシャドウが受信側クライアントの前記プールマネジャに対応し、さらに、
前記プールマネジャを前記バッファプールと関連付けるステップと、
前記プールマネジャシャドウを前記バッファプールシャドウと関連付けるステップとを含む、請求項19に記載の方法。
【請求項２１】
前記バッファプールに対しバッファ領域を指定するクレジットを供給するステップと、
前記バッファプールを更新して、前記クレジット供給ステップにおいて供給される前記バッファ領域を識別するステップと、
前記バッファプールシャドウを更新して、前記クレジットを供給するステップにおいて前記バッファプールに供給される前記バッファ領域を識別するステップと、
前記プールマネジャと前記プールマネジャシャドウを更新して、前記更新されたバッファプールを表すステップとを含む、請求項20に記載の方法。
【請求項２２】
ダイアログ受信制御ブロックを構成するステップを含み、前記ダイアログ受信制御ブロックが、前記更新されたプールマネジャを識別するデータ宛先記述子パラメータを有するダイアログ受信プリミティブを含み、さらに、
受信側クライアントから受信内部接続フロントエンド（IFE）へ前記ダイアログ受信制御ブロック（RCB）を伝えるステップと、
前記ダイアログ受信制御ブロックにおけるパラメータに基づき受信制御ブロック（RCB）を構築するステップと、
送信IFEへ第１のネットワークパケットで前記RCBを送るステップとをさらに含む、請求項21に記載の方法。
【請求項２３】
送信側で、
前記送信IFEにおいて前記RCBを待ち合わせるステップと、
ダイアログ送信制御ブロックを構築するステップを含み、前記ダイアログ送信制御ブロックが、ダイアログ送信プリミティブを識別するダイアログ送信パラメータを有するダイアログ送信プリミティブと受信側クライアントへ送られるデータとを含み、さらに、
前記送信IFEへ前記ダイアログ送信制御ブロックを伝えるステップと、
前記ダイアログ送信制御ブロックと前記待ち合わせされるRCBとの間の一致を判別するステップと、
少なくとも１つの受信バッファの受信メモリアドレスと前記ダイアログ送信制御ブロックが識別する少なくとも１つの送信バッファからのデータを結合するステップを含み、前記少なくとも１つの受信バッファが、前記更新されたプールマネジャシャドウに関連する前記更新されたバッファプールシャドウにリストされ、前記データ宛先記述子パラメータにより識別される前記更新されたプールマネジャに対応し、
第２のネットワークパケットを構築するステップを含み、前記第２のネットワークパケットが、前記結合ステップにおいて結合された前記データと前記受信メモリアドレスを含み、さらに、
前記受信IFEへ前記第２のネットワークパケットを送るステップとを含む、請求項22に記載の方法。
【請求項２４】
バッファプールが有する利用可能なバッファの数が低水位標値を下回る場合、低水位標通知を発行するステップをさらに含む、請求項19に記載の方法。
【請求項２５】
前記バッファプール創出ステップが、バッファプール創出プリミティブを発行して前記バッファプールを創出しかつ前記バッファプールをノードと関連付けるステップを含み、前記バッファプール創出プリミティブが、バッファプールクレジットに関連するメモリ領域のサイズ、前記バッファプールに含まれるバッファアドレスを記憶するためのバッファプールクレジットスロットの数、および低水位標値を規定するパラメータを含む、請求項19に記載の方法。
【請求項２６】
受信側のバッファプールで利用可能なクレジットのカウントを表す未結合カウンタを維持するステップをさらに含み、前記未結合カウンタが、クレジットステップがクレジットスロットを加えた後増加し、結合ステップがクレジットスロットを使用した後減少する、請求項19に記載の方法。
【請求項２７】
受信側で受信される前記第２のネットワークパケットにおける前記受信メモリアドレスを比較して、前記受信メモリアドレスが許容可能な範囲にあるかどうかを確認するステップをさらに含む、請求項23に記載の方法。
【請求項２８】
送信側クライアントと受信側クライアントとの間のプルモデルデータ通信を提供するためのシステムであって、
受信側クライアントでバッファプールを創出するための手段と、
送信側クライアントでバッファプールシャドウを創出するステップとを含み、前記バッファプールシャドウが、受信側クライアントの前記バッファプールに対応する、システム。
【請求項２９】
受信側クライアントでプールマネジャを創出するための手段と、
送信側クライアントでプールマネジャを創出するための手段を含み、前記プールマネジャシャドウが、受信側クライアントのプールマネジャに対応し、
前記プールマネジャを前記バッファプールに関連付けるための手段と、
前記プールマネジャシャドウを前記バッファプールシャドウに関連付ける手段とを含む、請求項28に記載のシステム。
【請求項３０】
前記バッファプールにバッファ領域を指定するクレジットを供給する手段と、
前記バッファプールを更新して、前記クレジットを供給する手段により供給される前記バッファ領域を識別するための手段と、
前記バッファプールシャドウを更新して、前記クレジット供給手段により供給される前記バッファ領域を識別するための手段と、
前記プールマネジャと前記プールマネジャシャドウを更新して、前記更新されたバッファプールを表すための手段とを含む、請求項29に記載のシステム。
【請求項３１】
ダイアログ受信制御ブロックを構成するための手段を含み、前記ダイアログ受信制御ブロックが、前記更新されたプールマネジャを識別するデータ宛先記述子パラメータを有するダイアログ受信プリミティブを含み、さらに
受信側クライアントから受信内部接続フロントエンド（IFE）へ前記ダイアログ受信制御ブロックを伝えるための手段と、
前記ダイアログ受信制御ブロックにおけるパラメータに基づいて、受信制御ブロック（RCB）を構築する手段と、
前記RCBを第１のネットワークパケットで送信IFEへ送るための手段とを含む、請求項30に記載のシステム。
【請求項３２】
前記送信IFEにおいて前記RCBを待ち合わせるための手段と、
ダイアログ送信制御ブロックを構築するための手段を含み、前記アナログ送信制御ブロックが、ダイアログ送信プリミティブと受信側クライアントへ送られるべきデータとを識別するダイアログ送信パラメータを有するダイアログ送信プリミティブを含み、さらに、
少なくとも１つの受信バッファについての受信メモリアドレスと、前記ダイアログ送信制御ブロックが識別する少なくとも１つの送信バッファからのデータとを結合するための手段を含み、前記少なくとも１つの受信バッファが、前記更新されたプールマネジャシャドウに関連する前記更新されたバッファプールシャドウにリストされており、前記データ宛先記述子パラメータが識別する更新されたプールマネジャに対応し、さらに、
前記ダイアログ送信制御ブロックを前記送信IFEへ伝えるための手段と、
前記ダイアログ送信制御ブロックと前記待ち合わせされたRCBとの間の一致を判別するための手段と、
第２のネットワークパケットを構築するための手段を含み、前記第２のネットワークパケットが前記結合手段が結合する前記データと前記受信メモリアドレスを含み、さらに、前記受信IFEへ前記第２のネットワークパケットを送る手段とを含む、請求項31を含むシステム。
【請求項３３】
バッファプールが有する利用可能なバッファの数が低水位標値を下回る場合、低水位標値通知を発行するための手段をさらに含む、請求項28に記載のシステム。
【請求項３４】
前記バッファプール創出手段が、バッファプール創出プリミティブを発行して前記バッファプールを創出しかつ前記バッファプールをノードと関連付けるための手段を含み、前記バッファプール創出プリミティブがバッファプールクレジットと関連するメモリ領域のサイズ、前記バッファプールに含まれるバッファアドレスを記憶するためのバッファプールクレジットスロットの数、および低水位標値を規定するパラメータを含む、請求項28に記載のシステム。
【請求項３５】
受信側のバッファプールで利用可能なクレジットのカウントを表す未結合カウンタを維持するための手段をさらに含み、前記未結合カウンタが、クレジット手段がクレジットスロットを加えた後増加し、結合手段がクレジットスロットを使用した後減少する、請求項28に記載のシステム。
【請求項３６】
受信側で受信される前記第２のネットワークパケットで前記受信メモリアドレスを比較して、許容可能な範囲で前記受信メモリアドレスを確認するための手段をさらに含む、請求項32に記載のシステム。
【発明の詳細な説明】
発明の背景
1.発明の分野
この発明は、コンピュータネットワーク化およびデータ通信の分野に関する。
2.先行技術の説明
ダイアログ（仮想回線とも称される）は異なる応用プロセス間においてデータを搬送する。ダイアログはメッシュなどのコンピュータネットワーク上でデータを搬送するよう論理的に設定され得る。あるコンピュータネットワークでは、ダイアログは、異なる端末システムまたはホストで実行する応用プロセス間におけるデータ通信を与える。さらに、ダイアログは、同一のホストで実行する応用プロセス間でもデータを搬送し得る。
仮想回線（つまりダイアログ）を実現するために、異なるサービスおよび信頼性を提供するよう、あるデータ通信ネットワークにおいては、複数の機能層（たとえば、アプリケーション層、プレゼンテーション層、セッション層、トランスポート層、ネットワーク層、リンク層、および物理層）が用いられる。各層は、サービスを提供するよう、関連のプロトコルおよびプリミティブの範囲を有する。各層は、データおよび対応の層プロトコル制御情報を含む対応のプロトコルデータユニットを形成する。異なる端末システムにおける同じ層での同位プロトコルエンティティは、対応の層プロトコルデータユニットおよびプロトコル制御情報を管理することによってその層においてのサービスを提供する。データ通信ネットワークにおけるこのような複数機能層のオペレーション（たとえば、OSIまたは伝送制御プロトコル／インターネットプロトコル（Transmission  Control  Protocol/Internet  Protocol（TCP/IP））プロトコル群において用いられるようなアプリケーション層、プレゼンテーション層、セッション層、トランスポート層、ネットワーク層、リンク層および物理層）は周知なものであり、さらに詳細に記載する必要はないであろう。たとえば、Martin,J.,TCP/IP Networking:Architecture,Administration,and Programming,（TCP/IPネットワーク化：アーキテクチャ、管理およびプログラミング）、（PTR Prentice Hall:Englewood Cliffs,NJ 1994）,pp.29−30（ここに引用により援用される）およびF.Halsall,Data Communications,Computer Networks,and Open Systems（データ通信、コンピュータネットワークおよびオープンシステム）、第４版、（Addison−Wessley:U.S.A.1996）,p.663）（ここに引用により援用される）を参照されたい。層は、ソフトウェア、ファームウェア、および／またはハードウェアとして実現される。
従来の通信システムは今では高バンドパス能力を有する。高速ネットワーク化技術に対するデータスループットは、100メガビット／秒〜１ギガビット／秒のオーダの速度で生ずる。しかしながら、レイテンシは高い。レイテンシとは、トランザクションが発行される時間とそのトランザクションが完了されたものとして報告される時間との間の時間間隔である。高レイテンシを伴うシステムでは、通信を行なう２者のクライアントがデータ要求を完了するためのラウンドトリップ時間はミリ秒のオーダになり得る。
レイテンシは、従来の通信システムでは、トランスポート層およびトランスポート層よりも論理上下の層（たとえば、ネットワーク層、リンク層および物理層）を限定的にではないが含む通信層に関与するオーバヘッドにより一部生ずる。しかしながら、下位層ネットワークファシリティは進歩しており、あるネットワーク上でのメッセージの伝送および配信は現在でははるかにより効率的かつ信頼性があり、特に、重結合されたクラスタ化されたシステムにおいて特に効率がよくかつ信頼性がある。
トランスポート層ファシリティは実質的なレイテンシを与え続ける。一般に普及しているトランスポート層プロトコル、たとえばTCPなどは、下位層ビットレートは中位に高いが、信頼性は低く、さらに、下位のネットワーク層により誘導されるレイテンシが高い、といったローカルエリアおよびワイドエリアネットワーク（LAN/WAN）環境をサポートするよう開発された。トランスポートファシリティは、信頼性のある伝送および配信を保証するよう、従来のトランスポートプロトコルに含まれる。ATM、Fiber Channel、ServerNetTMといった高速・低レイテンシ通信ネットワークの出現により、これまでは信頼のある通信を達成すべくトランスポート層に組込まれていたファシリティが今では下位の通信ネットワーク自身によって提供されつつある。たとえば、ATM、Fiber Channel、ServerNetTMは、間順配信、検査合計、セグメント化および再アセンブル（SAR）といった、信頼性のある伝送および配信を保証するための特定の下位層ファシリティを含む。
従来の高レイテンシトランスポート層プロトコルおよびアーキテクチャは、しかしながら、下位のネットワーク化層（たとえばネットワーク層、リンク層および物理層）は信頼性がないものであるとする。したがって、高レイテンシトランスポート、たとえばTCP/IPプロトコル群などは、下位層データ伝送信頼性において進展を推進するようには位置付けられない。従来のトランスポート層プロトコルは、受信側がデータに対応し得るか否かにかかわらずそのデータが送られるという、プッシュデータモデルの通信にさらに制限される。このようなプッシュモデルデータ通信は、フロー制御問題および過剰なデータコピーを引起す。
必要とされるのは、効率のよいトランスポート層処理を有する高速・低レイテンシ内部接続アーキテクチャである。特に、重結合されたクラスタ化されたシステムに対するデータ伝送および配信の信頼性における改善点を向上させ得る標準トランスポート層プロトコルおよびアーキテクチャが必要とされる。データコピーを取除きかつ効果的なフロー制御を行なう高速・低レイテンシトランスポート内部接続アーキテクチャが必要とされる。
発明の概要
この発明に従うと、プルデータモデルを用いて通信行なうクライアント間において信頼性のありかつ効率のよいトランスポートサービスを提供するような通信内部接続アーキテクチャ（CIA）が特定化される。このプルデータモデルは、ダイアログの送信クライアントが受信クライアントにデータを送るため許可を待つという通信モデルである。受信クライアントは送信クライアントからのデータを「プル」する。受信クライアントは準備ができるとデータを要求するので、フロー制御はこのプルデータモデルによって処理される。さらに、この通信内部接続アーキテクチャは、この発明に従うと、プッシュデータモデルと同様に効率よくかつ信頼性をもってデータを転送するプッシュデータモデルを実現する。
この発明のCIAプルデータモデルは、送信側によってデータバイトを受信側メモリアドレスに結合することを必要とすることによって、受信オペレーションをサポートする。通信を行なう送信クライアントと受信クライアントとの間のデータ転送は、データをメモリに書込む“ライト・オンリ”オペレーションを実行することにより専ら行なわれ得る。高レイテンシを有する読出オペレーションは完全に回避され得る。
この発明の一実施例に従うと、ある方法およびコンピュータプログラム製品は、通信を行なうクライアント間におけるプルデータモデルに基づくトランスポート層データ通信を提供する。データを受信するため、受信クライアントは、ダイアログ受信（d_rcv）プリミティブに対するパラメータを含むCIA制御ブロック（CCB）を構築する。受信クライアントはこのCCBを受信側CIAトランスポート層ファシリティに送る。これらd_rcvパラメータは、宛先データ領域（つまりデータ宛先アドレス）と、各データ宛先アドレスにおいてどれだけのデータ空間が利用可能であるかとを規定する分散リストを識別する。たとえば、「バッファで受信」オペレーションでは、d_rcvパラメータは、特に、受信側バッファおよびそのバッファに対する所望の転送長を識別する。さらなるd_rcvパラメータを用いることによって、利用可能な受信サービス（たとえば自動受信サービスまたは部分受信サービス）を選択する。
受信側CIAトランスポートファシリティは、受信内部接続フロントエンド（IFE）とも称される。この受信IFEは、d_rcvプリミティブで受信クライアントにより送られるパラメータに基づいて受信制御ブロック（RCB）を構成する。受信IFEはこのRCBをネットワークパケットでメッシュ上を送信側CIAトランスポートファシリティへ、つまり、論理ダイアログに関連付けられる送信IFEに送る。
送信側では、送信IFEによって受信制御ブロック（RCB）が記憶される。このRCBの到着は、インターフェイスの送信側において合致処理を生じさせる。RCBは、分散リストを識別するフィールド（たとえば受信データ宛先アドレスならびに最大データ転送長およびバッファ長）を含む。このRCBは、d_rcv意味規則をサポートするような関連の他のフィールド（たとえば自動受信、バッファプールリファレンス）を含む。複数のRCBを送信側にて待ち行列に入れることにより、レイテンシを低減しかつデータに対する複数要求に対応し得る。
データを送信するため、送信クライアントはダイアログ送信（d_send）プリミティブに対するd_sendパラメータを制御ブロック（CCB）で送信IFEに送る。これらd_sendパラメータは論理ダイアログおよび収集リストを識別する。付加的なフィールドをさらに用いることにより、他のd_send意味規則（たとえば部分転送対メッセージの終り指示）をサポートする。
CIAインターフェイスの送信側のトランスポート層（換言すれば、送信IFE）は、RCBと未処理のd_send CCBとの間において合致がいつなされるかを判断する。データを転送するため、送信IFEは、d_send CCBによって特定化されるデータを、その合致するRCBによって特定化される宛先アドレスに結合する。
データがメッシュ上を転送されるネットワーク化環境では、送信IFEによってネットワークパケットが構築される。このネットワークパケットは送信者のデータおよび受信者メモリ宛先アドレスのコピーを含む。受信クライアントおよび送信クライアントが同じメモリ空間を共有する場合、送信IFEはメモリコピーを用いてデータ転送を実行する。
受信側では、受信IFEによって受信されたネットワークパケットが解体される。次いで、受信IFEは、送信側データを、ネットワークパケットから、その受信されたネットワークパケットにあるメモリ宛先アドレスによって特定される受信バッファ内に記憶させる。
この発明の別の特徴に従うと、アーリー・ファー・エンド（Early−Far−End）およびファー・エンド（Far−End）という２つの送信サービスクラスが提供される。ユーザがアーリー・ファー・エンドのサービスを要求する場合には、送信IFEが送信クライアントの資源を必要としなくなるとすぐに送信IFEは送信クライアントに「送信完了」指示を送る。
ユーザがファー・エンドのサービスを要求する場合には、送信IFEは受信IFEによって送信される「肯定応答」パケットを待つ。送信IFEによる「肯定応答」パケットの受信によって、送信クライアントへの「送信完了」指示が引起される。
この発明にはさらなる特徴および利点がある。複数の、全二重の、信頼性のある仮想回線接続（つまり多重論理ダイアログ）が各ノードごとに設けられ得る。複数のダイアログオブジェクトが１つのノードを参照し得る。複数の未処理のCIAプリミティブオペレーションが各ダイアログ上において許される。ダイアログはバイトストリームまたはメッセージ指向型データを処理し得る。
データオペレーションおよび特徴は、それらに限定されるものではないが、分散および収集サポート、アーリー・ファー・エンドおよびファー・エンドの送信サービスのクラス、自動繰返し受信オプション、send/rcv長に対する実質的な制限が全くない部分送信および受信メッセージ、および複数ダイアログ優先順位を含む。
この発明に従うと、ユーザレベル管理ダイアログを用いることによって他の論理ダイアログを確立することができる。タイプ１およびタイプ２ダイアログ確立サービスが提供される。
この発明のさらなる特徴に従うと、効率のよいかつ信頼性のあるトランスポートサービスを提供するようプルデータモデルにおいてバッファプールおよびプールマネージャを利用する通信アーキテクチャが提供される。バッファプールおよびプールマネージャオペレーションは、アドレス結合検査、バッファプールクレジット、低水位標通知、およびデータ結合を行なうことによって、データ転送性能をさらに最適化する。
この発明のさらなる特徴および利点、ならびにこの発明のさまざまな実施例の構造およびオペレーションを、添付の図面を参照しながら以下に詳細に説明する。
【図面の簡単な説明】
ここに組入れられかつ明細書の一部をなす添付の図面は、この発明を例示し、および、明細書の記載とともに、この発明の原理を説明し、さらに、当業者がこの発明を実施し利用できるようにするものである。
図1Aは、この発明に従う通信内部接続アーキテクチャ（CIA）インターフェイスを示す概略図である。
図1Bは、図1AのCIAインターフェイスのためのメッセージシステムの概略図である。
図1Cは、図1AのCIAインターフェイスのためのCIAプリミティブおよび意味規則の組の概略図である。
図２は、この発明に従うCIA内部接続の概略図である。
図３は、Windows NTTM環境において統合されるCIA意味規則を示す概略図である。
図４は、この発明に従うCIAアーキテクチャにおけるノードオブジェクトを示す概略図である。
図５は、この発明に従うCIAアーキテクチャにおけるDIALOGオブジェクトを示す概略図である。
図6Aおよび図6Bは、この発明に従う「バッファで受信」型のCIAデータ通信において用いられるCIAオブジェクトの例を示す概略図である。
図7Aおよび図7Bは、この発明に従うプルモデルデータ通信のルーチンを示すフローチャートである。
図８は、この発明に従う２つのサービスクラス（アーリー・ファー・エンドおよびファー・エンド）をさらに示すデータ転送を示す流れ図である。
図９は、送信要求が受信要求に先行する場合を除く図８のようなデータ転送に対する流れ図である。
図10は、この発明に従う複数受信および送信要求を示すデータ転送に対するフローである。
図11は、この発明に従う例示的自動受信プリミティブオペレーションを示す流れ図である。
図12は、この発明に従う部分メッセージを用いるデータ転送の一例を示す流れ図である。
図13は、この発明に従う部分メッセージおよびEOMメッセージの組合せを用いるデータ転送の一例を示す流れ図である。
図14Aは、この発明に従うタイプ１サービスにおける論理ダイアログを確立するための例示的ルーチンを示す。
図14は、この発明に従うタイプ２サービスにおける論理ダイアログを確立するための例示的ルーチンを示す。
図15Aは、この発明に従うユーザレベル管理ダイアログを確立するよう用いられる例示的状態図である。
図15Bおよび図15Cは、この発明に従うユーザレベル管理ダイアログを確立するための例示的ルーチンのフローチャートである。
図16および図17は、この発明に従う「バッファプールで受信」タイプのCIAデータ通信において用いられるCIAオブジェクトの例を示す概略図である。
図18は、この発明を実現する例示的コンピュータシステムのブロック図である。
図19は、この発明において用いるためのCIAプロバイダのブロック図を示す。
図20は、この発明において用いるためのさまざまなIFE接続機構スタイルのブロック図を示す。
図21は、この発明において用いるためのCIA代理ドライバのブロック図を示す。
図22は、この発明に従う例示的IFEアドレス指定のブロック図である。
図23は、この発明に従う例示的IFE接続機構群のブロック図である。
この発明は添付の図面を参照して説明される。図面において、同様の参照番号は同一であるかまたは機能的に同様である要素を示す。加えて、参照番号の左端の桁は、当該の参照番号が最初に現われる図面を識別するものである。
好ましい実施例の詳細な説明
目次
1.  外観および用語
2.  例示的環境
3.  通信内部接続アーキテクチャ（CIA）
a.  CIA内部接続モデル
b.  例示的Windows NTTM環境
4.  CIAデータ通信
a.  プルデータモデル
b.  オペレーション
1.  CIAオブジェクト
2.  データ転送
3.  収集
4.  分散
5.  サービスの送信クラス（アーリー・ファー・エンドおよびファー・エンド）
6.  送信および受信要求の順序付け
7.  複数の未処理の送信および受信要求
8.  自動受信および自動送信
9.  部分メッセージ（部分受信および部分送信）
10.  ダイアログ優先順位属性
5.  CIA管理
a.  ノードプリミティブおよび通知
b.  ダイアログ確立、終了および通知
1.  タイプ１
2.  タイプ２
c.  ユーザレベル管理ダイアログ
d.  IFE管理プリミティブおよび通知
6.  バッファプール（BP）およびプールマネージャ（PM）オペレーション
a.  バッファプールで受信オペレーション
b.  「バッファプールで受信」オペレーションをサポートするCIAオブジェクトおよびプリミティブの例示的説明
1.  BPオペレーションプリミティブ
2.  PMオペレーションプリミティブ
3.  データ結合アルゴリズム
4.  ダイアログオペレーションプリミティブ
5.  バッファプール
6.  プールマネージャ
7.  プールマネージャシャドウ
8.  バッファプールで受信のためのPCB
9.  ダイアログオブジェクト
10.  ノード
7.  例示的コンピュータシステム
8.  例示的CIA−IFEインターフェイス
a.  CIA−IFE初期設定
b.  CIAプロバイダ
c.  IFE接続機構スタイル
d.  CIA代理ドライバ
E.  IFEアドレス指定
9.  結論
1.  外観および用語
この発明は、プルモデルデータ通信を用いるデータ転送のための方法、システムおよびコンピュータプログラム製品を提供する。この発明は、通信を行なうクライアント間に効率のよいかつ信頼性のあるトランスポートサービスを提供するような通信内部接続アーキテクチャについて述べる。この通信内部接続アーキテクチャ（CIA）は、送信側が、送信されるべきデータを、そのデータが受信側においてどこに記憶されるべきかを示すデータ宛先記述子（メモリアドレス）とともに、受信側に結合するという、プルモデルに基づくデータ通信を含む。このような態様によって、受信されたデータはデータコピーを全く必要としないライトオンリオペレーションを用いて記憶され、フロー制御の問題が取除かれる。
この発明をより明確に記載するため、明細書中では、可能な限り整合性をもって以下の用語定義に従うよう努力がなされている。
「通信内部接続アーキテクチャ」「CIA」およびその等価語は、ここに記載されるこの発明に従う通信内部接続アーキテクチャを示すべく相互に入れ替え可能に用いられる。この通信内部接続アーキテクチャは、任意の２者のクライアント間においてトランスポートレベルのデータ通信を与えるものである。CIA機能性は、それに限定されるものではないが、トランスポート層を含む任意のネットワーク通信層において実現され得る。
「内部接続」は、２者のクライアント間におけるデータ通信を可能にする内部接続フロントエンド（IFE）間における論理接続を示す。内部接続は、広域ネットワーク上、重結合されたネットワーク上、または単一のシステム内においては共用メモリ環境において拡張し得る。
「内部接続フロントエンド」「IFE」およびその等価語は、通信モジュールをクライアント（システムおよび／またはアプリケーション）に接続するために用いられるモジュール（ソフトウェア、ファームウェア、および／またはハードウェアを介して実現される）を示す。この発明に従うIFEは、ここに記載されるように、１つ以上のCIAプリミティブおよびオペレーションならびにその均等物を有するCIAを含む。IFE機能性は、ホストプロセッサおよび／または別個のユニットにおいて実現され得る。
「CIA制御ブロック」、「CCB」、「制御ブロック」、およびその等価語は、クライアント（システムおよび／またはアプリケーション）とIFEとの間にてCIAプリミティブを含みおよび送るよう用いられるデータ構造を、相互に置換可能に示すよう用いられる。
「メッシュ」、「ネットワーク」、およびその等価語は、同種ノード間および／または異種ノード間における対称の二重通信を提供する物理リンクをサポートする任意の物理リンク技術を示す。
「ノード」、「ノードオブジェクト」、およびその等価語は、メッシュ、物理リンク、ループバックファシリティ、または共用メモリ構成を介して接続される他のIFEを表わすために用いられる、あるIFEによって維持されるデータ構造を、相互に置き換え可能に示すため用いられる。
「ダイアログ」、「ダイアログオブジェクト」、およびその等価語は、「論理ダイアログ」を表わすよう用いられる、あるIFEによって維持されるデータ構造を、相互に置き換え可能に示すため用いられる。「論理ダイアログ」およびその等価語は、クライアント（システムおよび／またはアプリケーション）間における全二重通信回線を示す。
「バッファ」およびその等価語は、バッファアドレスによってアドレス指定されるメモリ領域である。
「バッファプール」およびその等価語は、バッファアドレスおよびバッファプール属性を記憶するデータ構造である。
「プールマネージャ」およびその等価語は、バッファ優先パラメータを説明する。バッファ優先パラメータは、利用可能なバッファを転送長に合致させるための最もよく適合する能力を与えるものである。
2.  例示的環境
この発明は、例示的コンピュータネットワーク化環境に関連して記載される。これらの用語における記載な便宜上与えられるにすぎない。この発明はこの例示的環境における適用に限定されることが意図されるものではない。実際に、以下の記載を読めば、当業者にはこの発明を代替的環境において実施する方法が明らかとなるであろう。
3.  通信内部接続アーキテクチャ（CIA）
図1A、図1Bおよび図1Cはこの発明に従う通信内部接続アーキテクチャ（CIA）を示す。CIA1000は、トランスポートレベルの内部接続通信サービスを与える。CIA1000は、ネットワーク化または共用メモリ環境における任意のコンピュータ上のトランスポート層として実現され得る。図1Aはネットワーク化構成を示す。ホストコンピュータ100はCIA1000およびトランスポート層104を含む。次いで、ホスト100で実行するアプリケーション102がトランスポート層104を介してデータをネットワーク層106に転送する。このデータは次いでバス108または他のタイプのリンクを介してデータ通信ネットワーク110に送られる。
CIA100は、TCP/IPのような従来のトランスポート実現例よりも少ないプロトコルオーバヘッドでトランスポートレベルの通信サービスを提供するために、トランスポート層104に付加される。以下においてさらに詳細に記載されるように、CIA1000は、物理レベルにおいて通信技術における現在の進歩をさらに向上させることによってより高く最適化されたサービスを提供する（たとえば、順序および信頼性のある配信におけるセグメント化／再アセンブリ）。他の、サービス特徴の質も提供され得る。たとえば、保証されたダイアログバンド幅が与えられ得る。CIAの重要な特性は以下のようにまとめられる：
1.  物理的な内部技術に依存しない。
2.  ノード（つまりダイアログ）単位での、複数の、全二重の、信頼性のある仮想回線接続。
3.  各ダイアログにおいて複数の未処理オペレーションが許される。
4.  バイトストリームまたはメッセージ指向型データ転送。
5.  send/rcv長に対する制限が実質的に全くにない部分送信および受信。
6.  トランケーション選択肢を伴う受信。
7.  プログラマブルバッファ優先制御論理を含むバッファプールサポート。
8.  特定のメモリへの受信（カーネルコピーなし）がサポートされる。
9.  分散および収集サポート（バッファプールを特定のメモリアドレスと混合することを含む）。
10.  自動繰返し受信選択肢。
11.  ２つの送信サービスクラス（アーリー・ファー・エンド、ファー・エンド）。
12.  NetBIOS送信意味規則を伴う、強調型ダイアログに基づくフロー制御。
13.  複数のダイアログ優先順位。
図1Aに示されるように、CIA1000は、CIAインターフェイス1050と、メッセージシステム1100と、CIAプリミティブおよび意味規則の組1200とからなる。さらに、CIA管理サービス（CIA−MS）1300が、ファントムの破線で示され、以下にさらに説明される。
図1Bはメッセージシステム1100の要素を示す。メッセージシステム1100は、１つ以上のバッファ1110と、内部接続フロントエンドユニット（IFE）1120と、制御ブロック1130とからなる。各IFE1120は１つ以上の送信インターフェイス1121および受信インターフェイス1123からなる。各IFE1120は、さらに、０またはそれ以上のノード1140と、ダイアログ1150と、プールマネージャ1160と、バッファプール1170とからなる。各ダイアログ1150は０かまたはそれ以上の送信チャネル1180および受信チャネル1190からなる。このメッセージシステム1100における各要素の動作を以下にさらに詳細に記載する。
図1Cは、CIAプリミティブおよび意味規則の組1200からの要素を示す。このCIAプリミティブおよび意味規則の組1200は、ノードオペレーション1210と、ダイアログオペレーション1220と、バッファプールオペレーション1230と、プールマネージャオペレーション1240と、内部接続フロントエンド管理オペレーション1250とを含む。ノードオペレーション1210は以下のタイプのプリミティブ:ASSOCIATE（関連付け）,CREATE（作成）,DESTROY（破壊）,GREET（挨拶）,NOTIFY/RESTART（通知／再スタート）,INFO（情報）およびBOUND（結合）（たとえばn_associate,n_bound,n_create,n_destroy,n_greet,n_notify_restart,n_zinfo）を含み得る。ダイアログオペレーション1220は、以下のタイプのプリミティブ:ASSOCIATE,CREATE,DESTROY,INTERLOCK（インターロック）,RECEIVE（受信）,SEND（送信）,SHUTDOWN（遮断）およびINFO（たとえばd_associate,d_create,d_destroy,d_interlock,d_rcv,d_send,d_shutdown,d_zinfo）を含み得る。
バッファプールオペレーション1230は、以下のタイプのプリミティブ:CREATE,DESTROY,SET LOW WATER（低水設定）,SUPPLY CREDIT（クレジット供給），およびINFO（たとえばbp_create,bp_destroy,bp_set_low_water,bp_supply_credit,およびbp_zinfo）を含む。プールマネージャオペレーション1240は、以下のタイプのプリミティブ（CREATE,DESTROYおよびADD CONTROL（制御付加）（pm_create,pm_destroy,pm_add_control）を含む。内部接続フロントエンド管理オペレーション1250は、以下のタイプのプリミティブ:CANCEL（キャンセル）,RESET（リセット）（たとえばi_cancel,i_reset）を含む。
CIAプリミティブの完了は通知機構を介して報告される。IFE、ノード、ダイアログ、およびバッファプール管理に関連する非同期条件に対し定義されるさらなる通知事象も存在する。実際の通知実現例はホスト動作環境と相関関係にある。Windows NTTMアーキテクチャを伴うCIAの実施例では、通知は手続呼戻しとして実現される。
CIAプリミティブおよび意味規則の組1200のオペレーションを以下にさらに詳細に説明する。
a.  CIA内部接続モデル
図２は、CIAに基づく内部接続における構成要素を図示するハイレベル図である。論理的に、共通メッシュ（202）を介して接続されるシステム210、212、214の組が存在する。各システム210、212、214は、メッシュ202を介して接続されるシステム間にてCIA意味規則を実現するための、ハードウェアおよびソフトウェアからなる、システムに特有の組211、213、215をそれぞれ組入れる。システム210、212、214は、それに限定されるものではないが、企業サーバ、NTサーバ、UNIXサーバ、または他のコプロセシング要素を含む、任意のタイプのコンピュータシステムであり得る。それらに限定されるものではないが、共用メモリ、イーサネット、タンデムのサーバネットワーク（Tandem's ServerNet）、SCI物理、非同期転送モード（ATM）およびFiber Channelを含む、任意のメッシュ技術および下位層プロトコルが用いられ得る。実際には、CIA1000は任意の下位の物理内部接続メッシュ技術に依存しない。
図示されてはいないが、各システム210、212、214は複数のIFEを含み得、複数のメッシュに１つ以上のIFEを介して接続され得る。
b.  例示的Windows NTTM環境
図３は、Microsoft Windows NTTMによって利用されるネットワーク化プロトコル組織3000にCIA意味規則300がどのように統合され得るかを示す。CCIAは、A Seriesオペレーションシステム環境においてマスタコントロールプログラム（MCP）においても実現され得る。しかしながら、この発明は、この説明を与えられる当業者には容易に明らかとなることではあるが、Windows NTTMまたはMCP環境に限定されるものではない。
図３の例において、3000番台の参照番号は、Microsoft Windows NTTMオペレーティングシステムにおいて用いられるネットワーク化プロトコル組織3000の要素を示す。300番台の参照番号は、この発明に従うCIA要素を示す。
図３に示されるように、いくつかの異なるアプリケーションプログラミングインターフェイス（API）3111、3112が、ネットワーク化サービスを利用するためのアプリケーション3102にとって利用可能である。このWindowsソケットインターフェイス3112は、元々UNIXシステムにおいて開発されたBerkeleyソケットインターフェイスに因んでモデル化されたMicrosoft  Windows規格に従うものである。当初はWindowsソケットはTCP/IP3122上のネットワーク化をサポートしたが、最近の拡張によって他の固有ネットワーク（たとえば、NovellのIPXネットワークのためのNWLINK3124）がサポートされた。NETBIOSインターフェイス3111は、パーソナルコンピュータのために開発されたオリジナルのネットワーク化APIの１つであった。NBF3121およびNBT3113を含むいくつかのさまざまなNETBIOS互換性ネットワーク化実現例が開発された。NBF3121は、IMBM固有NETBEUIネットワーク化実現例の一実現例である。NBT3113は、TCP/IP3122上においてNETBIOS実現例を規定するインターネット規格の実現例（つまりRFC1001、1002）である。
Windows NTTMは、トランスポートドライバインターフェイス（TDI）3120と称される標準インターフェイスを規定する。これによって、既存のネットワーク実現例上で動作する新しいネットワーク化APIを展開するための十分に規定されたインターフェイスが与えられ、さらには、既存のネットワーク化APIのための新たなネットワーク化プロトコル実現例の組入れも斟酌される。
ストリームインターフェイス3123は、UNIXストリームプログラミングモデルに対して開発されたプロトコルドライバの移植を助けるよう互換層として開発された。NWLINK3124は、このカテゴリに適合するプロトコルドライバの一例である。
NDIS3130は、OSIプロトコルスタックの層２の上端（つまりリンク層）に対応するMicrosoft Windows標準プログラミングインターフェイスである。NDIS3130によって、ネットワークプロトコルは異なるベンダからのLANアダプタ3140で相互動作することが可能となる。LANハードウェアベンダは、それらの特定のLANアダプタ3140に対してNDISドライバ3131を展開する。
この発明に従うと、CIA−USER.SYS311は、アプリケーション3102が直接CIA1000の特徴を利用できるようにする新たなネットワーク化APIを与える。CIAトランスポートサービス321は、CIAに基づく内部接続上においてNETBIOS3111およびWindows Scoket3112をサポートするTDI適合性ネットワーク化インターフェイスである。仮想LAN構成要素331によって、NDIS適合性ネットワーク化プロトコルがCIAに基づく内部接続上で相互動作することが可能となる。
CIAプリミティブインターフェイス320は、CIAクライアント311、321、331およびIFE324、322、323に対する共通のプログラミングインターフェイスを与える。
IFE322およびIFE324は、CIAクライアントアプリケーション（たとえば１つの要求データ）およびCIAサーバアプリケーション（１つの供給データ）が同じシステムに存在することを可能にするようなループバックファシリティを実行している。この場合、IFE322、324はメモリコピーを用いてデータを転送し得る。IFE323は、内部接続アダプタ340によって与えられる外部メッシュ接続を介してCIA意味規則を実現する。IFE323および相互接続アダプタ340は、１つのIFEユニットとして組合せられ得、または図３に示されるように別個のユニットとして実現され得る。
4.  CIAデータ通信
CIAはデータ通信のプッシュデータモデルおよびプルデータモデルの両方をサポートする。プッシュデータモデルは、メッセージがメッシュから応答不要の状態で到着し、部分的にデコードされ、受信要求と同期され、宛先アドレスに結合され、その一方で、後のメッセージがメッシュから流れ込み続けるという点で、これまでのネットワーク化モデル、たとえばTCP/IPと同様である。対照的に、プルデータモデルでは、この発明に従うと、データを受取る準備ができたことを受信側が送信側に通知するまで、送信側は（ダイアログに対する）データを送信しない。CIA1000は、異なるタイプの受信オペレーション（バッファで受信、バッファプールで受信）をサポートするプルデータモデルを用いる。さらに、この発明のさらなる特徴に従うと、プルデータモデルをプッシュモデルと同程度に効率のよいものにするよう最適化する通信内部接続アーキテクチャが与えられる。
a.  プルデータモデル
この発明のCIAプルデータモデルは、送信側がデータバイトを受信側メモリアドレスに結合することを必要とすることによって、受信オペレーションをサポートする。通信を行なう送信クライアントと受信クライアントとの間のデータ転送は、メモリにデータを書込む“ライト・オンリ”オペレーションを実行することによって専ら行なわれ得る。高レイテンシを有する読出動作は完全に回避され得る。さらに、CIA1000のプルデータモデル実現例は、データ転送および制御をさらにより効率的にするよう、さらなる技術を利用してもよい。
CIAは、アプリケーションがダイアログに対し生じさせ得る２つの受信動作のカテゴリ、つまり「バッファで受信」および「バッファプールで受信」を規定する。「バッファで受信」オペレーションは、受信メッセージに対応するようCIAクライアントがメモリ空間（たとえばユーザにより特定されるメモリ領域またはバッファ）を割当てられている場合を可能にする。このメモリ空間は、IFEに対して認められるアクセスを有するCIAクライアントによって所有される。このことは、メッセージを受信するための資源割当がCIAクライアントによって管理されるという点で、IFEに恩恵を与える。このことは、データが置かれるべきメモリ場所をクライアントが知っているという点で、CIAクライアントに恩恵を与える。
「バッファプールで受信」オペレーションは、各ダイアログに対し１つ以上のバッファを前もって割当てるということに相対する意味での、（しばしば遊休状態となり得る）多数ダイアログにわたってメモリ資源を管理する手段を与える。IFEは、入来データを利用可能なバッファ空間に結合し、その結合をCIAクライアントに対し受信指示にて報告する。
CIA1000において用いられるプルデータモデルを、まず、「バッファで受信」オペレーションにて用いられるCIAオブジェクトを主に参照しながら詳細に説明する。次に、CIAダイアログおよびノード管理について説明する。その後、「バッファプールで受信」オペレーションにて用いられるCIAオブジェクトを参照しながら、CIA1000にて用いられるプルデータモデルについて詳細に説明する。
b.  オペレーション
1.  CIAオブジェクト
CIAは、アーキテクチャの一部であるいくつかのオブジェクトを定義する。図４は、CIAアーキテクチャにおけるノード401〜406の役割を示す。ノード401〜406は、対応のIFE211、213、215によって維持されるデータ構造である。矢印で示されるように、ノード401〜406は、メッシュ202を介して接続される他のIFE211、213、215を表現するよう用いられる。
たとえば、ノード406は、IFE215（「局所」IFEとも称される）によって維持される。しかしながら、ノード406はIFE213（「遠隔」IFEとも称される）を示す。図４において矢印で示されるように、ノード406は遠隔IFE213を指すリファレンスを記憶する。たとえば、このリファレンスは指示子（たとえば遠隔IFE213を識別するメディアアクセスコントロール識別情報（MAC  id）であり得る。同様に、IFE213はIFE215に戻って参照するノード404を維持する。
図５は、CIA通信システムにおけるダイアログオブジェクト501〜506の役割を示す。ダイアログオブジェクト501〜506は、アプリケーション510〜515間における全二重通信回線を表現するために用いられる対応のIFE211,213,215によって維持されるデータ構造である。たとえば、アプリケーション510は２つのダイアログオブジェクト501、502を開いた（たとえば作成した）システム212において実行する。
論理ダイアログ520、530および540は通信を行なうクライアント間において確立される。これら論理ダイアログ520、530、540は全二重通信回線を表現する。この発明のCIA通信システムに従うと、論理ダイアログは対応するダイアログオブジェクト間において確立される。たとえば、図５に示されるように、アプリケーション510およびアプリケーション512は、対応するダイアログオブジェクト501と503との間において確立される論理ダイアログ520を介して通信を行なう（たとえばデータを転送する）。IFE211は、IFE213内のダイアログオブジェクト503を介してのシステム214内のアプリケーション512とのデータの交換を調整するよう用いられるダイアログオブジェクト501内に情報を維持する。同様に、IFE213は、IFE211内のダイアログオブジェクト501を介してのシステム212内のアプリケーション510とのデータの交換を調整するよう用いられるダイアログオブジェクト503内に情報を維持する。
IFEは、２つ以上の論理ダイアログを介してデータ通信をサポートする。たとえば、論理ダイアログ530をサポートするために、IFE211は、IFE215内のダイアログオブジェクト505を介してのシステム216内のアプリケーション514とのデータの交換を調整するよう用いられるダイアログオブジェクト502内にも情報を維持する。複数のアプリケーションをサポートするシステムは、さらに、複数の論理ダイアログを介して通信を行ない得る。たとえば、論理ダイアログ540は、システム216内にて実行するアプリケーション515と、システム214内にて実行するアプリケーション513との間において、データ通信を与える。論理ダイアログ540をサポートするため、IFE215は、さらに、IFE213内のダイアログオブジェクト504を介してのアプリケーション513とのデータの交換を調整するよう用いられるダイアログオブジェクト506においても情報を維持する。
IFEは、以下にさらに論ずるように、それ自身の論理ダイアログを、内部において、CIA意味規則、たとえばシャドウオブジェクト（バッファプールシャドウおよびプールマネージャシャドウ）の作成および未処理のRCBの取消などをサポートするよう利用し得る。
2.  データ転送
CIAプルデータモデルを用いるデータ転送の例を、この発明に従って、図６〜図８を参照しながら以下に説明する。図6Aおよび図6Bは、便宜上受信クライアント601および送信クライアント603と符号付けされた二者の全二重通信を行なうクライアント間における例示的なCIAデータ通信において用いられる構成要素を示す概略図である。IFE211およびIFE213は、それらの対応のクライアント601、603に対する全二重CIAトランスポート層ファシリティを表わすが、便宜上、受信IFE211および送信IFE213と称される。図7Aおよび図7Bはプルモデルデータ通信に対するルーチン700を示すフローチャートである。図８は、２つのサービスクラス（アーリー・ファー・エンドおよびファー・エンド）をさらに示す図６の例示的CIA通信におけるCIAプリミティブおよびオペレーションの流れ図である。
受信クライアント601と送信クライアント603との間においてデータ通信を実行するため、論理ダイアログ520がまずダイアログオブジェクト501と503との間に確立される。CIAプリミティブ（たとえばn_createおよびd_associate）を用いてノード401、403およびダイアログオブジェクト501、503を作成する。さらにCIAプリミティブ（たとえばd_associate）を用いてダイヤオブジェクト501および503を論理ダイアログ520に関連付ける。ノードおよびダイアログオブジェクト作成のためのCIAプリミティブのオペレーションを以下にさらに詳細に説明する。２つのIFE間に論理ダイアログを確立するためのCIAプリミティブおよびルーチンについても以下にさらに詳細に説明する。
図6Aおよび図6Bにおいては、論理ダイアログ520がダイアログオブジェクト501と503との間に確立されている。したがって、ダイアログオブジェクト501は、送信IFE213においてダイアログオブジェクト503を識別するリファレンスを含む。さらに、ダイアログオブジェクト501は、送信IFE213に関連付けられるノード401を識別するリファレンスも含む。同様に、ダイアログオブジェクト503は、受信IFE211においてダイアログオブジェクト501を識別するリファレンスを含む。さらに、ダイアログオブジェクト503は、受信IFE211に関連付けられるノード403を識別するリファレンスも含む。
図1A〜図1Cに関連して上に述べたように、CIAプリミティブを用いて論理ダイアログ520を介してのデータ通信が実行される。受信および送信タイプのCIAプリミティブ（d_rcv、d_send）を用いてデータを転送する。所望されるデータ転送動作およびトランスポートサービスのタイプに依って、さまざまなタイプの受信CIAプリミティブが発行され得る。
CIAプルデータモデル通信のためのルーチン700は、図7Aに示されるように受信側にて主に実行されるステップと、図7Bに示されるように送信側にて主に実行されるステップとを含む。明確にするため、まず、ルーチン700について、ダイアログ受信CIAプリミティブの１タイプ（d_rcv）および１つのダイアログ送信プリミティブ（d_send）に言及しながら説明する。データをバッファプールに受信し、データをバッファおよび／またはバッファプールに分散するための他のタイプの受信プリミティブについては、後でさらに詳細に説明する。データ収集のための他のタイプの送信プリミティブについても、例示のルーチン700の後に説明する。
データを受信するため、受信クライアント601はd_rcvプリミティブを特定化するCIA制御ブロックCCB611を構築しそれを受信IFE211に送る（ステップ710）。下の表には、「バッファで受信」オペレーションのための例示的d_rcvプリミティブが、その原理パラメータおよびそれらの機能とともに記述される：
0003550402.tif 000002
オプコードパラメータはCCBのタイプを識別する。この例では、それはバッファプリミティブを伴うd_rcvに対するオプコード値となる。ダイアログハンドルは、受信データ動作に関連付けられる局所ダイアログオブジェクトを識別する。分散リストパラメータは、受信されたデータを記憶するための１つ以上のバッファ（つまりメモリ領域および容量）を特定する。たとえば、図6Bに示されるように、CCB611は、バッファプリミティブを伴うd_rcvを識別するオプコードフィールドと、ダイアログオブジェクト501を識別するダイアログハンドル641と、バッファ621を指しかつバッファ621の長さ（またはサイズ）（たとえば1MB）を識別する分散リスト644とを有するd_rcvプリミティブを含む。
結果記述子パラメータ643は結果場所を指す。この結果場所は、d_rcvプリミティブ結果情報を追尾する結果構造651が記憶される場所である。たとえば、この結果記述子は、送信IFE213によって更新される特定のメモリ領域（つまりバッファ651）を指し得る（図6Bを参照されたい）。下に説明されるバッファプールで受信オペレーションでは、この結果記述子は特定のバッファまたはプールマネージャリファレンスを介してバッファプールを参照し得る。
結果構造651は、d_rcvプリミティブの結果に関する情報を、rcv_resultフィールド672において送信側に既知のさらなる情報（たとえば、残りのデータ長、EOM、トークン）とともに記憶する。このようにして、送信IFE213は、（たとえば残りのデータ長に対してd_rcvプリミティブをポストすることによって）受信IFE211が知的データ転送要求をなすことを可能にするインターフェイスの送信側での条件について、受信IFE211に知らせることができる。さらに、この結果構造は、メッセージの終りが送信IFEによって信号送信されたかどうかを識別するよう、メッセージの終りフラグを含み得る。
この発明の他の特徴に従うと、結果構造651はトークン値をさらに含み得る。ダイアログ受信通知機構はこのトークン値を利用することによって通知方式をカスタマイズし得る。たとえば、クライアントは、トークン値（たとえば32ビットトークン）を用いることによって、複数の通信回線を単一のCIA論理ダイアログを介して多重化し得る。
属性ビットまたはフィールド642は、クライアントによって、データ転送のための特定の受信意味規則を選択するため用いられる。たとえば、「自動受信」属性は、以下にさらに詳細に記載されるように、自動受信意味規則を可能化するよう選択され得る。「メッセージの終り」フラグ（EOM）は、d_rcvオペレーションが受信メッセージを用いるべきかまたは部分受信意味規則を受信すべきかを示す。
ステップ720において、IFE211はCCB611を受信してそれを実行する。通常、この結果、IFE211は受信制御ブロックRCB633を構築する。一般に、RCB633はCCB611において送られるd_rcvパラメータを含む（ただしd_rcvオプコードは除く）。受信IFE211はRCB633をネットワークパケットにて送信IFE213に送信する（ステップ730）。受信IFE211は、送信IFE213における利用可能なRCB場所の宛先アドレスを知っている。この情報はダイアログ連想中に与えられたものである。これによって、受信IFE211は、RCBデータおよび送信IFE213におけるその目標場所（つまり宛先アドレス）とともにRCB633を含むネットワークパケットを構成することができる。
送信要求に対し、送信クライアント603は、d_sendプリミティブを識別するd_send CCB613を構築する（ステップ740）。d_send CCB613へのリファレンスが送信IFE213に送られる。下の表には、例示的d_sendプリミティブが、その主なパラメータおよびそれらの機能とともに記載される：
0003550402.tif 000003
オプコードは、データ送信オペレーションに対するd_sendプリミティブを識別する。ダイアログハンドル661は、データ送信オペレーションに関与する局所ダイアログオブジェクトを識別する。収集リストパラメータ663は、原始データを検索するための０個以上のバッファ（メモリ領域）を特定する収集リストである。
属性ビットまたはフィールド662（オプションである）は、クライアントによって、データ転送のための特定の送信意味規則を選択するため用いられる。たとえば、メッセージの終りフラグ（EOM）は、原始データの最後のバイトの転送と合致するEOMを送信IFEが示すべきか否かを示す。結果トークンパラメータは、受信側のCIA_RCV_RESULT651内に送られるべきトークン値を識別する。送信結果664は、どれだけのデータが送信されたかを判断するために送信クライアント603が見るものである。送信結果664は送信IFE213によって更新される。
バイトストリーム指向型トラフィックの場合、EOM区切り文字は必要ではなく、EOMフラグはセットされない。メッセージ指向型トラフィックの場合では、EOMフラグはセットされる。このようにして、CIA1000はメッセージ指向型トラフィックおよびバイトストリーム指向型トラフィックの両方をサポートし得る。この発明のさらなる特徴に従うと、図12を参照して以下にさらに詳細に記載されるように、「部分送信」および「部分受信」メッセージCIA1000においてさらに用いることによって、メッセージ指向型トラフィックおよびバイトストリーム指向型トラフィックの両方のサポートを最適化し得る。
ステップ750において、RCB633が到着すると、送信IFE213は、ダイアログ連想中にダイアログオブジェクト503に関連付けられるRCB633のための所定の領域に、RCB633を記憶させる。ステップ740およびステップ750は非同期であり、任意の順序で実行され得る。換言すれば、以下において図９を参照してさらに記載されるように、ステップ750は、さらに、CCB613がステップ740にて構築される時間より前にRCB633を記憶し得る。
説明を明確にするために、図6Aおよび図6Bは１つのRCB633のみを示す。しかしながら、図10を参照して下により詳細に記載されるように、データに対する複数の送信および受信要求が未処理であり得る。複数の未処理のRCBに対応するため、各RCBは送信IFE213にて待ち行列（図示せず）に入れられる。
ステップ760において、送信IFE213は、待ち行列に入れられたRCBと未処理のd_sendプリミティブとの間に合致がなされるかを判断する。合致は、未処理のRCBおよびd_sendプリミティブが共通の論理ダイアログを識別したときになされる。図6Aおよび図6Bに示される例では、RCB633およびd_sendプリミティブ613がともに論理ダイアログ520を参照するように存在する場合に合致がなされる。
ステップ770では、データを転送するために、データを記憶するための受信記述子（たとえばメモリアドレス）に原始データを結合するネットワークパケットを構築する。送信IFE213は、CCB613のd_sendプリミティブにおいて与えられる収集リストパラメータ663によって規定されるメモリ領域（たとえばバッファ623）からデータを集める（たとえば原始データをコピーする）。受信メモリアドレス（バッファ621）は、合致するRCB633から、特に分散リストパラメータ644から判断される。データがメッシュ202を介して転送されるネットワーク化環境では、下位のネットワーク化層（図示せず）がネットワークパケットを形成する。このネットワークパケットは、送信IFE213によって与えられる結合されたデータおよび受信側メモリ宛先アドレスを含む。
ステップ780において、ステップ770にて構築されたネットワークパケットは受信IFE211に送信される。受信IFE211はそのネットワークパケットからのデータをバッファ621に直接書込む（ステップ790）。このライトオンリオペレーションでは、データコピーは全く行なわれる必要がない。CIA1000は、アドレスを検証する任意のタイプの範囲検査をサポートし得る。受信IFE211は、ネットワークパケット内の記述子情報を用いることによって、書込データにより修飾されるべきアドレスの範囲が許可されることを検証することができる。
ステップ793において、送信IFE213はrcv_result672およびRCB完了指示を送信する。データ転送、結果転送およびRCB完了指示は、同じネットワークパケットにて送られ得る。ステップ795において、受信IFE211は、d_rcvプリミティブが完了していることを受信クライアント601（アプリケーション510および／またはシステム212）に通知する通知（「受信完了」指示とも称される）を送信する。
ステップ770〜790について、あるネットワーク化環境に言及しながら説明する。代替的に、受信および送信クライアントが同じメモリ空間を共有する場合には、送信IFE213（または他のシステム構成要素）は、メモリコピー動作を用いながら、集められたデータをバッファ623からバッファ621へ直接転送し得る。
したがって、下位の物理内部接続技術に頼らないトランスポートレベルのデータ通信サービスが提供される。換言すれば、CIA1000インターフェイス（ここに記載されるメッセージシステムならびにCIAプリミティブおよび意味規則の組）は、下位のネットワーク化層およびプロトコル、たとえば、ATM、Fiber Channel、ServerNetTMなどに依存することなく通信を行なうクライアント間にて動作する。CIAプルデータモデル通信を用いると、データは識別された受信メモリアドレス空間に送信されるにすぎない。予期されないデータの中間バッファ処理を全く必要としないので、フロー制御問題がなくなる。このCIAプルデータモデルによって、トランスポートレベルでの全体のレイテンシが低減され、ネットワーク伝送および配信システムの信頼性における改善点が増強される。
加えて、複数の、全二重の、信頼性のある仮想回線接続（つまり多重論理ダイアログ）が各ノードごとに与えられ得る。複数のダイアログオブジェクトが１つのノードを参照し得る。複数の未処理のCIAプリミティブオペレーションが各ダイアログにて許される。ダイアログはバイトストリーム指向型データまたはメッセージ指向型データを処理し得る。それらに限定されるものではないが、分散および収集サポート、アーリー・ファー・エンドおよびファー・エンドの送信サービスクラス、自動繰返し受信オプション、send/rcv長に対して実質的に制限が全くない部分送信および受信メッセージ、ならびに複数のダイアログ優先順位を含む、ダイアログオペレーションおよび特徴について、以下にさらに詳細に説明する。
3.  収集
ダイアログ送信プリミティブ（d_send）によって原始データが送信される。この原始データは複数のメモリ領域から１つのバイトストリームに集められ得る。d_sendプリミティブにおける「収集リスト」パラメータは、データ収集を実行するため用いられる要素の順序付けされたリストであり得る。各要素は、そこからデータを集めるユーザ特定メモリ領域（たとえばバッファ）を識別する。たとえば、順序リストにおける各要素は、あるデータ要素に対するメモリアドレスおよびメモリ長を特定する。次いで、送信IFEが、各データ要素を、順序付けられたリストパラメータによって特定されるシーケンスで集める。
この発明に従うと、異なるタイプのd_sendプリミティブの各々が、未処理のd_sendプリミティブ間における原始メッセージ領域の共有を可能にする。d_sendプリミティブは原始メモリ領域を（一時的にさえも）変更しない。
4.  分散
ダイアログ受信プリミティブ（d_rcv）は原始データが複数の別個のメモリ領域に受入れられ分散されるのを可能にする。d_rcvプリミティブにおける「分散リスト」パラメータは、データを分散するために用いられる要素の順序付けされたリストであり得る。各要素は、データを分散すべきユーザ特定メモリ領域（たとえばバッファ）を識別する。たとえば、分散リスト内の各要素はデータ要素に対するメモリアドレスおよびメモリ長（アドレス／長さの対）を特定する。
同様に、「バッファ分散」プリミティブを伴うd_rcvが発行されると、さらなる「分散リスト」フィールド（「領域リスト」とも称される）を含む対応の受信制御ブロック（RCB）構造が生ずる。この分散リストフィールドは「分散リスト」パラメータ、つまり、データを分散するために用いられる要素（たとえばアドレス／長さの対）の順序付けられたリストを記憶する。
次いで、送信IFEが、「分散リスト」パラメータにおける各要素によって特定される分散されたメモリ領域内にデータを結合する。このようにして、受信されたメッセージは、分散リストに示される長さおよびタイプに従ってメモリ領域（またはバッファプール内の自由なバッファ）内に受信IFEによって分散される。分散リストは任意の数の要素をサポートし得る。バッファプールオペレーションでは、現在の分散リスト要素が満足される前に自由なバッファが満たされると、別の自由なバッファを用いて分散リストのその部分を完了させる。結果構造は、バッファマッピングへの受信データを記述するバッファリストを含む。
5.  サービスの送信クラス（アーリー・ファー・エンドおよびファー・エンド）
図６および図7A〜7Bを参照して上で言及したように、論理ダイアログは、そのダイアログが関連付けられると特定化されるサービス属性の送信クラスを有する。アーリー・ファー・エンドおよびファー・エンドというサービスの送信クラスが与えられる。これら２つのサービスの送信クラスについて、例示的なプロセス流れ図（図８）を参照しながらさらに詳細に説明する。
図８は、データ要求（受信要求801）および送信要求（送信要求803）を処理するためのCIA処理ステップを示す流れ図である。図８は、図６および図7A〜図7Bの例示的CIA通信において上で説明された処理ステップ710〜797を示す。したがって、これら処理ステップの説明は繰返さない。
さらに、図８は、アーリー・ファー・エンドおよびファー・エンドのサービスにおいて送信完了を示すため用いられるステップ810〜830を示す。ユーザがアーリー・ファー・エンドのサービスを要求すると、送信IFE213は「送信完了」指示を送信クライアント603に送信する（ステップ810）。IFE213がもはや局所送信クライアント資源（任意の伝送再試行を含む）を用いていない限り、送信IFE213は、ネットワークパケットが送信側にて構築される前、同時または後に、「送信完了」指示を送信クライアント603に送信し得る。
ステップ820において、ユーザがファー・エンドのサービスを要求すると、受信IFE211は「受信完了」指示が発行されるとおおよそ同時または後に送信IFE213に「肯定応答」パケットを送信する。次いで、送信IFE213は「肯定応答」パケットの受信に応答して送信クライアント603に「送信完了」指示を送信する（ステップ830）。
これら２つのサービスクラス、アーリー・ファー・エンドおよびファー・エンドは、さまざまな整合性の度合をサポートし得る。データの損失が非常に稀であるかまたは無視される場合には、アーリー・ファー・エンドで十分である。したがって、アーリー・ファー・エンドのサービスは、メッシュのインフラストラクチャが極めて堅牢であるか、またはダイアログがデータグラムモードで動作している場合に適切である。対照的に、ファー・エンドのサービスの場合、「送信完了」指示はデータが成功裡に受信されたことを保証する。CIAインターフェイスの遠隔側は、CIAインターフェイスの局所側とは異なる送信サービスクラスを有し得る。
局所IFEは遠隔IFEからの明示的な肯定応答を必要としないため、アーリー・ファー・エンドはファー・エンドよりもよりよく実行される。これによって、局所的に開始される送信オペレーションがより早期に完了しその内部接続にわたってのトラフィックの量を低減することができる。
ダイアログに基づくフロー制御は各送信サービスクラスごとに省略される。アーリー・ファー・エンドおよびファー・エンドのサービスクラスの場合、受信端点がデータ転送を要求するまで、ダイアログは論理的に後方にプレッシャーを受ける。
6.  送信および受信要求の順序付け
図８に関して説明したデータ転送の例においては、受信要求801が送信要求803に先行した。一般に、論理ダイアログのための送信および受信要求は、任意の順序でクライアントと通信することによって、発行することが可能である。図９は、図８と同様のプロセスフロー図を示しているが、図９では、送信要求803が受信要求801の前に発行されるところが、図８とは異なる。
7.  複数の未処理の送信および受信要求
本発明のさらなる特徴に従えば、CIA1000は、複数の未処理の送信および受信要求を処理することができる。上述のように、送信IFEは、未処理のRCBおよびd_sendプリミティブを、待ち行列に入れる。送信IFE内の一致判定（matcher）モジュールは、いつ突合せがなされるかを決定する。好ましくは、ファーストイン・ファーストアウト型の待ち行列管理方法が使用されて、待ち行列の先頭におけるRCBおよびd_sendプリミティブが、最初に突合せられる。
複数のダイアログ送信プリミティブ（d_send）を、ダイアログに対してポストすることが可能である。同じダイアログにポストされるd_sendプリミティブは、通常、それらがそのダイアログにポストされたのと同じ順序で完了する。
複数のダイアログ受信プリミティブ（d_rcv）を、ダイアログに対してポストすることが可能である。d_rcvプリミティブは、通常、それらがダイアログにポストされたのと同じ順序で完了し、また、合致するd_sendプリミティブがポストされたのと同じメッセージ順で完了する。順序から外れたd_sendプリミティブおよびd_rcvプリミティブを処理する、付加的な機能を設けることも可能である。
図10は、CIAプルデータモデル内の内部待ち行列管理及び突合せが、どのように複数の未処理要求を処理するのかを示す例を図示する、プロセスフロー図である。この場合、２つの受信要求1001,1002および、２つの送信要求1011,1012が、発行される。
8.  自動受信および自動送信
CIAプリミティブ1200のセット内には、「自動受信（Auto Receive）」プリミティブ（RcvAuto）もまた設けられる。RcvAutoプリミティブは、ダイアログ受信プリミティブの、自動的に繰返す変形、たとえば、自動受信属性ビットセットを有する、上述のd_rcvプリミティブである。RcvAutoプリミティブは、繰返しデータ受信要求を発行することができるようにする。データはそこで、自動反復式に、ユーザ指定メモリ領域内に受信される。
RcvAutoプリミティブは、大量の受信待ち時間を排除する一方で、ダイアログ上のボトルネックを取除くのに有益である。受信側のクライアントは、ダイアログに対して単一のRcvAuto CCBをポストする。受信IFEは、そのRcvAuto CCBに対応して単一のRCBを生成して、それを送信IFEに転送する。送信IFEはその後、その単一のRCBを使用して、データを繰返し送信する。その後、受信IFEは、そのRCBによって特定された同じメモリ領域に、入来するデータパケットを連続的に受信する。これらのデータパケットは、後述するように、完全なおよび／または部分的なメッセージを含むことが可能である。ダイアログが自動受信を使用してデータを転送する場合、多くの「受信完了（Receive Complete）」表示が、同じCCBに対して表示され得る。ある意味で、単一のRcvAutoプリミティブが、何度も「完了する」のである。
自動受信オペレーションは、リアルタイムマルチメディア等の等時性データストリームを伝送するのに、特に有用である。「ストック−ティッカ（stock−ticker）」等の、連続更新が要求されるアプリケーションを、自動反復式に更新を書込むのに使用することも可能である。
図11は、自動受信プリミティブオペレーションの一例を示す、メッセージフロー図である。自動受信要求1100が、２つの連続する送信要求1101、1102を完了するものとして示されている。
データをバッファプール内に自動的に受信するためのさらなる変形を、下に、バッファプールオペレーションに関して説明する。特定的には、d_rcvの自動反復式の変形が、バッファプール内にのみ受信するために提供される。d_rcvの自動反復式の変形が、バッファプールおよびユーザ指定メモリ領域の任意の組合せに分散するために提供される。これについては、後述する。「自動受信」オペレーションを、プルデータモデル内のプッシュデータモデルをシミュレートして、さらに大量の受信待ち時間を排除するのに、使用することが可能である。
同様に、CIAプリミティブ1200のセット内に、auto_sendプリミティブ（任意選択）を提供することも可能である。このauto_sendプリミティブは、auto send属性ビットセットを有するダイアログ送信プリミティブの、自動的に繰返す変形である。auto_sendプリミティブは、反復式の送信要求を発行することができるようにする。同じソース領域のデータ内のデータを、その後、複数のデータ受信要求を満たすように、自動反復式に送信することが可能である。
9.  部分メッセージ（部分受信および部分送信）
CIA1000は、メッセージ指向型およびバイトストリーム指向型のデータ転送意味規則をサポートする。d_rcvプリミティブビットは、EOMと称される属性ビットを有する。このEOMビットがアサートされると、メッセージの終わりを表示するインジケータが送信側から受信されたときに、受信が完了する。そのEOM表示を受信する前に、分散リストによって示されるバッファ領域のキャパシティを越えて到着するデータは、送信側によって廃棄される。したがって、過剰なデータが送られることは決してない。しかし、超過データの損失を受信側に報告することは可能である。
d_rcvプリミティブは、EOMビットがアサートされていない場合には、分散リストによって示されたデータ領域が満杯になったとき、または、EOMが受信されたときに、受信が完了する。EOMビットがアサートされていないd_rcvプリミティブは、部分受信とも称される。
送信オペレーションについて見ると、送信オペレーションは、データの転送が終わったときに完了する。d_sendプリミティブは、EOMと称される属性ビットを有する。このd_send内のEOMビットがアサートされると、メッセージの終わりが、ソースデータ内の最終ビットと同時に送信される。送信IFEは、合致するRCBおよびd_send CCB内に特定されたEOM属性を使用して、正しいd_rcv意味規則を実現する。
d_sendプリミティブのEOMビットがアサートされていない場合、上記合致するRCBは、そのRCBが受信の一部でありかつ分散された領域が埋められているときにのみ、完了する。複数のRCBが未処理である場合があるため、受信の一部が完了すると、データ転送は、次に使用可能なRCBを使用して続けられる。EOMビットがアサートされていないd_sendプリミティブは、部分送信または送信の一部とも称される。
図12は、部分送信プリミティブ（SendPartial1201）および「メッセージの終わり」EOM送信プリミティブ（SendEOM1202）を含む、データ転送オペレーションの一例を示す、プロセスフロー図である。この例においては、受信データ要求1200は、部分送信プリミティブ1201およびEOM送信プリミティブ1202の組合せよりも長い全長でポストされる。したがって、受信要求1200は、送信プリミティブ1201および1202の両方に関連するデータ転送が起きない限り、完了しない。
本発明のさらなる特徴に従えば、SendPartial1201の「ファー・エンド」の完了動作は、SendPartialプリミティブの完了を優先するように修正される。RcvMsgは、SendEOMが送られるまで完了することができないため、SendPartialの「ファー・エンド」の完了は、不合理に遅延される場合がある。このSendPartialに対する遅延された完了動作は、「アーリー・ファー・エンド」（「パーシャル・ファー・エンド（Partial−Far−End）」とも称される）の態様ですべてのSendPartialを強制的に完了させることによって、許可されないようにされる。これを図12に示す。
図13は、部分受信プリミティブ（RcvPartial）と部分送信プリミティブ（SendPartial）との組合せを含む、データ転送オペレーションの一例を示す、プロセスフロー図である。部分受信要求1300およびRcvX（）要求1303は、部分送信1301およびEOM送信1302によって完了されるものとして示されている。
EOMなしのd_send（d_send w/o EOM）およびEOMなしのd_rcv（d_rcv w/o EOM）によって特定される転送長さは、互いに対して直接的な関係を有してはいない。すなわち、メッセージ内のデータは、バイトストリームとして処理される。送信側によってd_sendの部分送信の変形を使用して作成されるメッセージの中間部分は、受信側のクライアントによって区別することはできない。d_rcvの部分受信変形を使用して受信側によって受信されるメッセージの中間部分は、送信側クライアントによって区別することができない。
10.  ダイアログ優先順位属性
ダイアログは、ダイアログ優先順位属性を有する。多数の（たとえば15の）ダイアログ優先順位が存在し得る。複数の合致が存在する場合、送信IFEは、このダイアログ優先順位を使用して、競合するダイアログを処理する順序を決定する。公平性は、インターフェイスの送信側において裁定され、また、ダイアログの優先順位内で総当たりで裁定される。ダイアログの優先順位は、論理ダイアログの各側において個別に送信することが可能である。ダイアログ優先順位属性は、ダイアログオブジェクトの一部として記憶することもでき、または、d_sendプリミティブに対するパラメータとして特定することもできる。（たとえば、保証されたダイアログ帯域幅等の、）他の品質のサービス特徴もまた、提供することが可能である。
5.  CIA管理
図1Aに関連して説明したように、通信内部接続アーキテクチャ1000はさらに、CIA管理サービス（CIA−MS）1300を含む。CIA管理サービス1300は、CIAクライアント間で、共用されるCIAオブジェクトおよび共通のサービスの調整を行なう。たとえば、CIAクライアントは、IFEおよびNODEオブジェクトを共用することが可能である。というのも、個々のCIAクライアントが、同じNODEオブジェクトに関連する同じ局所IFE上に作成された、複数のダイアログを有し得るためである。
CIA−MS1300によって提供されるサービスは、ノードおよびダイアログの確立／終了および管理に関係する。IFE、ノードおよびダイアログオブジェクトの確立、終了および管理に関する、種々のCIAプリミティブのオペレーションについて、以下に説明する。
a.  ノードプリミティブおよび通知
ノード作成（n_create）プリミティブは、CIA−MS1300によって、ノードオブジェクトを作成するのに使用される。このプリミティブは、node_id（たとえば、MACid）および、そのノードオブジェクトが関連する（遠隔環境における）node_interfaceを示す。もしノードオブジェクトがうまく作成されれば、そのノードオブジェクトに一意のハンドルが返される。このノードのハンドルは、特定のIFE内において一意であるが、複数のIFEにわたって必ずしも一意であるとは限らない。
ノード破壊プリミティブ（n_destroy）は、ノードオブジェクトを破壊するのに使用される。このプリミティブは、ノードのハンドルを示す。このノードオブジェクトに関連する未処理のプリミティブ（たとえば、この同じノードに関連するダイアログに対するd_send/d_rcvプリミティブ）は、どれも取消される。このノードオブジェクトに関連していたバッファプール、プールマネージャおよびダイアログオブジェクトもまた、破壊される。
ノード再始動通知プリミティブ（n_notify_restart）は、遠隔IFEに対して局所IFEが再始動したことを通知するために発行される。このプリミティブは、通知されるべき遠隔IFEのノードハンドルを示す。局所IFEが（下に説明するi_resetプリミティブを介して）リセットされるたびに、局所ホストは、このプリミティブを、接続内の他のすべてのIFEに対して発行せねばならない（これは、先に関連付けられたことのあるノードのみに限定することもできる）。遠隔システムは、対応の通知を使用して、リセットされた遠隔IFEに対してポストしていた、すべての先の動作（すなわち、未処理のプリミティブ）を終了させる。
通知処理は、ホストの作業環境と相関関係にある。ノード再始動通知（CIA_NODE_RESTART_NOTIFICATION）が発行されるが、これは、遠隔IFEがこのシステムに対してn_notify_restartを発行したことを示す。この通知は、再始動を発行した遠隔IFEの、node_idおよびnode_interfaceを含む。
ノード挨拶プリミティブ（n_greet）は、IFE間の第１のレベルの挨拶として使用される。このプリミティブは、挨拶されるべき遠隔IFEのノードハンドルと、ユーザレベルの管理ダイアログとして使用されるべきダイアログのダイアログハンドルと、不調な挨拶を検知するのに使用される一意性値とを示す。このプリミティブは、遠隔システム上に通知（CIA_NODE_GREET_NOTIFICATION）（kind_associate＝FALSE）を生じさせるために使用される。１ノードオブジェクト当たり、最高で１つのn_greetプリミティブを発行することができる。そのプリミティブの初期化は、n_createプリミティブがそのノードオブジェクトに対して発行された後にのみ、有効である。
ノード関連付けプリミティブ（n_associate）は、ノードからノードへの通信を確立するのに使用される、IFE間の第２のレベルの挨拶として使用される。このプリミティブは、関連付けられるべき遠隔IFEのノードハンドルおよび、遠隔IFEから受信された挨拶の内容を示す。このプリミティブを使用して、遠隔システム上にCIA_NODE_GREET_NOTIFICATION（kind_associate＝TRUE）を生じさせる。１ノードオブジェクト当たり、最高で１つのn_associateプリミティブを発行することができる。プリミティブの初期化は、n_greetプリミティブがこのノードオブジェクトに対して発行され、かつ、挨拶表示が遠隔ノードから受信された後にはじめて、有効となる。
ノード結合プリミティブ（n_bound）は、遠隔ノードがノード関連付けを完了したこと（すなわち、局所ノードがkind_associate＝TRUEを有する挨拶を受信したこと）を局所IFEに対して表示するのに使用される。このプリミティブは、ノードの関連付けを完了した遠隔IFEのノードハンドルを示す。ノードオブジェクト当たり最高１つのn_boundプリミティブを発行することが可能である。このプリミティブの初期化は、n_associateプリミティブがそのノードオブジェクトに対して発行され、かつ、挨拶表示（kind_associate＝TRUE）が遠隔ノードから受信された後にのみ、有効となる。
ノード挨拶通知（CIA_NODE_GREET_NOTIFICATION）は、遠隔IFEがこのシステムに対して、n_greetまたはn_associateプリミティブを発行したことを示す。この通知は、挨拶を発行した遠隔IFEの、node_idおよびnode_interfaceを示す。これはまた、プール値（kind_associate）によって、遠隔IFEがn_greetまたはn_associateプリミティブを発行したかどうかを示す。この通知はまた、ユーザレベルの管理ダイアログおよびノードの関連付けを完了するのに使用される、挨拶の内容もまた示すが、これについては図15に関連して下にさらに詳細に説明する。
ノード障害通知（CIA_NODE_FAULT_NOTIFICATION）は、ノードオブジェクトに関連する遠隔IFEとの通信が失われたことを示すのに使用される。この通知は、node_id、node_interface、IFEに特有の理由コード、および、コンテキストパラメータを示す。このnode_idおよびnode_interface値は、失敗したNODEを表わす。理由コードは、ノード障害の原因を診断するのを助けるのに使用することができる。コンテキストパラメータ値は、このIFEのインスタンスを参照する、ホストの定義値である。このコンテキスト値は、i_resetプリミティブによってIFEに渡される。
b.  ダイアログの確立、終了、および通知
1.  タイプ１
１実施例においては、CIAクライアントは、タイプ１のダイアログ確立サービスに従って論理ダイアログを確立するために、選択されたCIAプリミティブを使用する。タイプ１のダイアログ確立サービスを使用するクライアントは、d_create、d_associate、d_shutdown、d_cestroy、d_zinfo、および、d_interlockといったCIAプリミティブを利用して、ダイアログオペレーションを実行する。最初に、これら各ダイアログプリミティブのパラメータおよびオペレーションを簡潔に要約することが有益であろう。
ダイアログ作成プリミティブ（d_create）は、局所IFE上にダイアログオブジェクトを作成するために発行される。d_createプリミティブは、新しく作成されたダイアログオブジェクトに対してダイアログ障害が示されたときに使用されねばならない、ダイアログ記述子を示す。他のダイアログ制御オプションを含むことも可能であるが、これは、優先順位、送信のサービスのクラス、ダイアログ障害オプションが動作可能／動作不能にされるかどうか、送信取消し意味規則、および、ダイアログ障害通知情報を含み得る。d_createプリミティブはまた、このダイアログの任意の１時点においてポストされる可能性のある、未処理のd_rcvプリミティブの数を表わすカウントを提供する。d_rcvプリミティブのAUTO変形（たとえば、RcvAuto等）を使用するダイアログに対しては、このカウントは通常、１であるべきである。ダイアログオブジェクトがうまく作成されれば、このダイアログオブジェクトに対して一意のダイアログハンドルが返され、ダイアログ関連情報（すなわち、ダイアログの内容）もまた返される。ダイアログハンドルは、特定のIFE内において一意であるが、複数のIFEにわたって必ずしも一意であるとは限らない。
ダイアログ関連プリミティブ（d_associate）は、局所ダイアログオブジェクトを遠隔ダイアログオブジェクトに関連付けるのに使用される。このd_associateプリミティブは、ダイアログハンドル、ノードハンドル、および遠隔ダイアログの内容を表わす。指示されるダイアログは、既に関連付けられていてはならない。関連付けがうまく完了したかどうかを示すステータスが返される。
ダイアログ停止プリミティブ（d_shutdown）は、ダイアログに関連する未処理のプリミティブを、優雅に終了させるために発行される。このプリミティブは、ダイアログハンドルを示す。このプリミティブは、指示されたダイアログに関連するすべての未処理のプリミティブの優雅な取消しを起動する。このプリミティブは、指示されたダイアログに関連する他のすべてのプリミティブが完了を知らせるまで、完了を知らせることはない。
ダイアログ破壊プリミティブ（d_destroy）は、ダイアログオブジェクトを破壊するために発行される。d_destroyプリミティブは、ダイアログハンドルを示す。このプリミティブは、ダイアログを優雅にクローズすることはない。なぜなら、指示されたダイアログに関連する未処理のd_rcvプリミティブに対して結合されているバッファプール資源が、正しく返されない場合があるためである。d_destroyプリミティブは、（このプリミティブ自身以外の）未だダイアログにポストされているすべてのプリミティブに対して取消されたステータスの表示をして、完了ルーチンを呼出す。指示されたダイアログオブジェクトは、削除される。
ダイアログ情報プリミティブ（d_zinfo）は、d_create結果パラメータから（後の関連付けのために）必要とされるダイアログ情報を検索するために発行される。CIAダイアログ障害通知CIA_DIALOG_FAULT_NOTIFICATIONは、ダイアログ障害条件が発生したことを示す通知である。この通知は、ホストコンテキストおよびダイアログ記述子値を、IFEの実装に特有の理由コードと共に示す。
ダイアログ破壊プリミティブおよび意味規則は、CIA_DIALOG_FAILURE_NOTIFICATIONが示されかつ、terminate_on_d_faultオプションが動作可能とされた場合に、ダイアログに対して自動的に実行される。ダイアログの属性（terminate_on_d_fault）は、データ転送ダイアログ障害がダイアログの失敗終了を引起こすかどうかを選択する（すなわち、d_destroy意味規則が、ダイアログ上で自動的に実行される）。
ダイアログに対するデータ転送障害は、ダイアログ障害通知によって示される。データ転送が失敗すると、活性なd_send/d_rcvプリミティブが、通知エンティティに対して「no−go」条件を示す。データ転送障害は、下位メッシュがすべての誤り回復および再伝送動作を試みたが成功しなかった場合に、発生する。
図14は、２つのクライアント（たとえば、局所クライアントと遠隔クライアント）の間でタイプ１のサービスに従って論理ダイアログを確立するための、例示的なルーチン1400を示す。タイプ１のダイアログ確立サービスにおいては、（たとえば、後述するCiaInitiate、CiaIfeEnum、CiaIfeOpenルーチン等によって）初期化が完了した後に、局所クライアントがd_createプリミティブを発行して、選択された局所IFE内にダイアログオブジェクトを作成する（ステップ1420）。局所クライアントは次に、後続の関連付けに必要とされるダイアログ情報を、d_create結果パラメータから、または、d_zinfoプリミティブの後続の呼出しを通じて、検索する（ステップ1430）。たとえば、この局所ダイアログ情報は、局所ダイアログオブジェクトを特定するフィールドを含み得るが、これに限定されるものではない。
ステップ1440において、局所クライアントは次に、この局所ダイアログ情報を、遠隔の相手側クライアントに通信する。タイプ１のダイアログ確立を使用する各クライアントは、このインターフェイス以外に専用の手段（おそらくは、既に確立されている別のCIAダイアログ）を有し、それによって、（ステップ1430において検索された局所ダイアログ情報等の）局所ダイアログ情報を、遠隔の相手側クライアントに通信する。
遠隔クライアントは同様に、ダイアログを作成し、かつ、遠隔のダイアログオブジェクトを特定する対応のダイアログ情報（遠隔ダイアログ情報と称される）を検索している。ステッピュ1450において、この遠隔クライアント（または、局所および受信側クライアントの両方に専用の、他のモジュール）が、ステップ1440において局所クライアントから送信されてきた局所ダイアログ情報および、遠隔クライアントにおいて生成された遠隔ダイアログ情報に基づいて、これらのダイアログのペアリング（合致）を判定する。合致が判定された後に、各クライアントは、d_associateプリミティブを呼出して、遠隔ダイアログ情報を局所ダイアログオブジェクトに提供する（ステップ1460）。関連付けの成功（または失敗）は、クライアントに専用の手段によって、クライアント間で通信される（ステップ1470）。この時点において、ダイアログは確立され、このダイアログを通じたデータ転送を進めることが可能となる。
タイプ１のダイアログ確立を使用するクライアントは、同様に、使用可能などのような手段を使用しても、そのダイアログの終了を調整する責任を負う。このダイアログに対する未処理のオペレーションを取消すために、d_shutdownおよびd_interlockを使用せねばならないこともあろう。クライアントはその後、d_destroyプリミティブを呼出して、対応するダイアログオブジェクトを破壊する。
2.  タイプ２
別の実施例においては、CIAクライアントは、タイプ２のダイアログ確立サービスに従って、論理ダイアログを確立することができる。タイプ２のダイアログ確立サービスを使用するクライアントは、d_create、d_destroy、d_zinfo、CiaDialogConnect、およびCiaDialogDisconnectのCIAプリミティブを利用して、ダイアログオペレーションを実行する。d_create、d_destroy、およびd_zinfoプリミティブは、タイプ１に関連して上述したのと同じパラメータを有する。CiaDialogConnectおよびCiaDialogDisconnect要求は、確立プロセスを開始および終了するのに使用される、ルーチンまたはプリミティブである。
（たとえばCiaInitiate、CiaIfeEnum、CiaIfeOpen等で）初期化を完了した後に、タイプ２のダイアログ確立を使用するクライアントは、d_createを呼出して、選択された局所IFE内にダイアログオブジェクトを作成する。クライアントはその後、CiaDialogConnectを呼出すことによって、確立プロセスを開始する。CIA−MS1300は、クライアントによって供給されたパラメータを使用して、指定された遠隔ノードとの合致機能を行なう。CIA−MS1300は、必要なダイアログ情報を交換し、ダイアログ関連付け機能を行なって、相手方ノードに知らせる。確立がうまく完了すると、それは、クライアントが特定した呼戻しルーチンを通じて報告される。この時点で、ダイアログは確立されて、そのダイアログを通じたデータ転送を進めることが可能となる。
タイプ２のダイアログ確立を使用するクライアントは、CiaDialogDisconnectを呼出すことによって、ダイアログの終了を開始する。そのダイアログに対する未処理のプリミティブはどれも終了され、また、そのクロージャの終結が、クライアントが特定した呼戻しルーチンを通じて報告される。クライアントはその後、d_destroyプリミティブを呼出す。
タイプ２のダイアログ確立は、簡単なダイアログ名前付けおよび突合せサービスを提供する。ダイアログの名前は、文字列比較または他の適切な突合わせ技術を使用して、突合せることができる。
CIA管理サービス1300は、以下のようにタイプ２のダイアログ確立を実現することが可能である。CiaDialogConnectは、ダイアログ基準値、ダイアログ名、NODE記述子（Node_id、Node_interface）および呼戻しルーチンアドレスといった入力パラメータで、規定することが可能である。ダイアログ基準値は、このダイアログに対する、クライアントの一意の基準値であって、接続サービスが完了した時点で呼戻しルーチンに返される。この呼戻しルーチン手順プロトタイプはまた、クライアントが接続オペレーションがうまく完了したかどうかを判定するのに使用する、接続ステータスを含む。図14Bは、CIA−MS1300がCiaDialogConnectを実現するのに使用することのできる、例示的なルーチン1400'を示す：
1.  ユーザレベルの管理ダイアログ（ULMD）が指示されたNODE記述子に対して確立されていない場合に、ユーザレベルの管理ダイアログ確立アルゴリズム1500を行なう（ステップ1410'）。
2.  新しいダイアログが作成されようとしておりかつ、特定の名前（この名前は、CiaDialogConnectに渡されたダイアログ名パラメータから導出される）が付けられたサービスに関連付けられようとしていることを、ユーザレベルの管理ダイアログを使用して遠隔CIA−MSに知らせる（ステップ1420'）。
3.  ダイアログの関連付けを完了する（ステップ1430'）。
4.  接続ステータスおよびクライアントのダイアログ基準値を示す、クライアントの呼戻しルーチンを呼出す（ステップ1440'）。
本発明は、タイプ１およびタイプ２のダイアログ確立サービスに限定されるものではない。他の種類のダイアログ確立サービスもまた、提供することが可能である。たとえば、Windowsソケット意味規則を実現する、ダイアログ確立サービスを使用することも可能である。この説明が向けられる当該技術分野における当業者には明らかなように、CIA1000は、CiaDialogConnectおよびCiaDialogDisconnectもまた、プリミティブとして実現することが可能である。他のダイアログ管理（プリミティブまたはルーチン）を、論理ダイアログの確立および廃止のために規定することも可能である。
c.  ユーザレベルの管理ダイアログ
本発明に従えば、CIA1000は、２つのノード間に最初のダイアログをセットアップするための機構を提供する。この最初のダイアログは、ユーザレベルの管理ダイアログ（ULMD）と呼ばれる。このユーザレベルの管理ダイアログは、CIA−MS1300によって、通信経路として使用されて、遠隔IFEにおける他のCIAクライアントのための付加的なダイアログを作成しかつ関連付けることができるULMDは、より進化したダイアログ確立サービス（たとえば、ダイアログタイプ２の確立）を実現するための通信経路を提供する。
（たとえば局所IFEおよび遠隔IFEの）２つのIFE間にユーザレベルの管理ダイアログを確立するためのルーチン1500について、図15Aから図15Cを参照して以下に説明する。図15Aは、CIA−MS1300が２つのIFE間にどのようにユーザレベルの管理ダイアログを確立するかを示す、状態図1501を示す、IFEは、各NODEオブジェクト（すなわち、遠隔IFE）について、異なるユーザレベルの管理ダイアログを有する。
図15Bに示すように、CIA−MS1300は、待ちステージ1502において、ユーザレベルの管理ダイアログの確立を開始する。CIA−MS1300は、CiaDialogConnect要求が局所で発行されるのを待つ（ステップ1504）か、または、greeting−１が発行されるのを待つ（ステップ1506）。CiaDialogConnectが発行されると、それは、関連するNODE記述子のための「完了されるべきリスト（to be completed list）」上の待ち行列に入れられる（ステップ1504）。greeting−１の発行は、ユーザレベルの管理ダイアログが確立された（または現時点において確立されつつある）NODEオブジェクトにマッピングしない、遠隔IFEから、CIA_NODE_GREET_NOTIFICATION（kind_associate＝FALSE）（すなわち、一意のnode_id、node_interface）が受信された状態に当てはまる。
ステップ1504または1506の後、表示されたNODE記述子のためのユーザレベルの管理ダイアログが確立されているか、または進行中、すなわち、現時点において確立されつつあるかを判定するチェックが行なわれる（ステップ1508）。特定されたNODE記述子に合致するNODEオブジェクトが未だ作成されていない場合には、CIA−MS1300は、n_createプリミティブを呼出す（ステップ1510）。特定されたNODE記述子に合致するNODEオブジェクトが既に存在する場合には、CIA−MS1300は、ステップ1509において、完了状態へと即座に移行する。なぜなら、その要求は既に待ち行列に入れられており、ステップ1595におけるノードの確立後に完了されることになるためである。
ステップ1510において、CIA−MS1300は、新しいNODEオブジェクトを作成するために、ｎ−createプリミティブを発行する。DIALOGオブジェクトが、d_createプリミティブを発行することによって作成される（ステップ1520）。ステップ1520において、CIA−MS1300は、d_createプリミティブを呼出して、ユーザレベルの管理ダイアログに対するダイアログオブジェクトを作成する。CIA−MS1300は、その後、そのユーザレベルの管理ダイアログのためのダイアログハンドルを、n_greetプリミティブに対するパラメータとして渡す。CIA−MS1300はn_greetプリミティブを、関連するNODE記述子に対して発行する（ステップ1540）。
ステップ1550において、ステップ1510〜1540が、greeting−１を受信することによって開始されたかどうかを判定するチェックが行なわれる。greeting−１がステッ1506において受信された場合、CIA−MS1300は、状態sync−Ａに進む（ステップ1565）。なぜなら、それは既にgreeting−１の表示を受信していたからである。そうでない場合には、CIA−MS1300は、greeting−１またはgreeting−２の表示を待って（ステップ1560）から、状態synch−Ａまたはsynch−Ｂに進む（ステップ1565）（図15C参照）。
状態sync−Ａまたはsync−Ｂに達すると、CIA−MS1300は、d_associateプリミティブを発行して、ULMDダイアログの関連付けを完了する（ステップ1570）。n_associateプリミティブが発行されて、NODEの関連付けが完了される（ステップ1580）。greeting−２の表示が受信される（ステップ1582）かまたは、それを待った（ステップ1584）後に、n_boundプリミティブが発行されて、NODEの確立が完了する（ステップ1590）。
ここで、NODEの確立が、greeting−１が遠隔ノードから受信されなくとも（すなわち、greeting−２が代わりに受信されても）、状態greet−Ｂから続けられることに着目されたい。これは、局所IFEが遠隔IFEからの通知を受取るよう準備される直前に、遠隔IFEがユーザレベルの管理ダイアログの確立を開始するような、競合状態を解決する。この場合のタイミングは、以下のようであり得る。すなわち、遠隔IFEがそのgreeting−１を送信するが、それは局所IFEによって途絶えさせられる（そのことを遠隔IFEは検知しない）。局所IFEはそのn_greetを行ない、それにより遠隔IFEがそのn_associateを完了することが可能となり、よって、greeting−２が（明確なgreeting−１の表示なしに）局所IFEによって受信されてしまう結果となる、という具合である。
最後に、関連するNODE記述子に対する、「完了されるべき」リスト上のすべてのCiaDialogConnect要求が完了される（ステップ1595）。ULMDを確立するためのルーチン1500が、その後、実行される（ステップ1599）。
d.  IFE管理プリミティブおよび通知
ダイアログおよびノードを確立しかつ管理するのに加えて、CIAは、内部接続フロントエンド（IFE）管理オペレーションを提供する。これらIFE管理オペレーションは、未処理のプリミティブの取消しおよび、IFEのリセットを含むが、これらに限定されるものではない。これらIFE管理オペレーションは、IFE管理プリミティブのセット（i_cancel、i_reset）によって、実行される。
内部接続取消しプリミティブ（i_cancel）は、未処理のプリミティブの取消しをサポートする。未処理のd_rcvプリミティブに対するi_cancelプリミティブが受信されると、IFEは、その未処理のd_rcvプリミティブをできるだけ早く終了する。指示されたd_rcvプリミティブは、その受信がi_cancelが効力を発揮する前にうまく完了した場合には、go表示を返す。そうでない場合には,d_rcvプリミティブは、no−go表示を返す。未処理のd_sendプリミティブに対するi_cancelプリミティブが受信されると、IFEは、即座にその未処理のd_sendプリミティブを終了する。指示されたd_sendプリミティブは、その取消しが効力を発する前にそのd_sendがうまく完了した場合には、go表示を返す。そうでなければ、d_sendプリミティブは、no−go表示を返す。
i_cancel_by_referenceプリミティブもまた、CIA1000に付加することができる。これは、CCB内の特定のフィールド（またはパラメータ）を識別するためのパラメータを有する。i_cancel_by_referenceプリミティブはそこで、CCBが合致するフィールドを有するか否かに基づいて、CCBを選択的に取消すことを可能にする。IFE管理プリミティブは、例示のためのみのものであって、本発明を限定するものではない。たとえば、IFEは、CIAオブジェクトおよびプリミティブに関する、セキュリティ方針を強化することもできる。
内部接続リセットプリミティブ（i_reset）は、IFEを初期化するのに使用される。このi_reset以前に発行された未処理のプリミティブはいずれも、no−go表示で完了される。この内部接続リセットプリミティブは、IFEに望まれる動作特性を示し、これは、このIFEからCIA_NODE_FAULT_NOTIFICATIONおよびCIA_IFE_FAULT_NOTIFICATIONに対して返されるべき、コンテキストパラメータを含む。
IFE障害指示通知（CIA_IFE_FAULT_NOTIFICATION）は、局所IFEが失敗したことを示す。この通知は、最も新しいi_resetプリミティブによって特定されるコンテキストパラメータ値を示し、また、IFEの障害の原因を診断するのに役立つよう使用され得る、IFEに特有の理由コードを示す。未処理のプリミティブの状態は、はっきりとはしないが、それらの完了を試みる目的で、CIA_FIE_FAULT_NOTIFICATIONの後に、後続のi_resetプリミティブを発行することが可能である。
6.  バッファプール（BP）およびプールマネージャ（PM）オペレーション
a.  「バッファプールで受信」オペレーション
上述の、「バッファで受信」ダイアログオペレーションに加えて、本発明はさらに、「バッファプールで受信」ダイアログオペレーションを提供する。CIA1000は、バッファプールおよびバッファプール管理を使用して、内部接続データ通信を提供する。バッファプールおよびプールマネージャオペレーションがCIA1000内に提供されて、それらが、プルデータモデルを、データ転送をプッシュデータモデルと同様に効率的に行なうことができるように、最適化する。
図16および17の例に示すように、CIA1000は、バッファプールおよびプールマネージャと称される、付加的なCIAオブジェクトを含む（BP1640およびPM1650を参照）。CIA1000は、バッファプール（BP）およびプールマネージャ（PM）オブジェクトを使用して、「バッファプールで受信」オペレーションをサポートする。プルモデルをサポートするために、CIA1000は、バッファプールシャドウおよびプールマネージャシャドウと称される。シャドウオブジェクトをさらに含む（BPS1740およびPMS1750を参照）。CIAプリミティブが使用されて、バッファプールおよび対応のバッファプールシャドウが作成されかつ管理される。CIAプリミティブが使用されて、プールマネージャおよび対応のプールマネージャシャドウが作成され管理される。CIAプリミティブ（およびパラメータ）がさらに使用されて、バッファプールおよびプールマネージャ（ならびにシャドウオブジェクト）に関連するパラメータおよびリファレンスが、CIAクライアントとIFEとの間で送られる。
図16は、IFE211内の、バッファプール1640およびプールマネージャ1650の例を示す。バッファプール1640およびプールマネージャ1650は、ノード401に関連している。明確さを期すために、この例は、上述のようにダイアログ501とダイアログ503との間に先に確立された、１つの論理ダイアログのためのデータ通信に関して説明するものとするが、本発明は、この例に限定されるものではない。１つのノードを、複数の論理ダイアログ（および対応のダイアログオブジェクト）に関連付けることが可能である。１つのプールマネージャを使用して、複数のバッファプールを管理することも可能である（たとえば、PM1650を使用して、16個のBPを管理することができる）。
CCB1611から1619は、アプリケーション510によって発行される。CCB1611は、bp_create（BUFFER_POOL_CREATE）プリミティブである。このbp_createプリミティブは、バッファプール（BP1640）を作成するのに使用される。バッファプールとは、バッファアドレスおよびバッファプールの属性を記憶する、データ構造またはオブジェクトである。１つのバッファプール内に記憶することのできるバッファアドレスの数は、CIAクライアントによって決定され、bp_createプリミティブに対するパラメータとして特定される。CIAクライアントはまた、各バッファアドレスに関連するバッファの（バイト単位の）サイズを、bp_createパラメータとして特定する。
プルモデルを有効にサポートするために、CIAは、クライアントがBPを、特定のNODEと関連付けることを要求する。プルモデルをサポートする相互接続定義のために、局所IFEは遠隔IFEに対して、BPS（BUFFER POOL SHADOW）オブジェクトが作成される必要があることを伝える。図17に示すように、BPS1740が遠隔IFEによって使用されて、そのバッファプールに対してクレジットされた、バッファアドレスおよびバッファのバッファサイズが記憶される。このバッファアドレスおよびサイズの可視性により、送信側（すなわち、遠隔IFE）が、データバイトを、バッファプールを参照する受信オペレーションのために受信側メモリアドレスに結合することが可能となる。遠隔IFEがそのBPSのためにメモリを割当てることができない場合には、bp_createプリミティブは失敗する場合もある。
BPS1740は、それがシャドウするBP1640に、非常によく似ている。この構造内のほとんどすべてのフィールドは、それがシャドウするBP内の同じフィールドと同様に利用される。BPS1740の１つの付加的なコンポーネントは、プールマネージョシャドウディレクトリ（PMS_DIRECTORYまたは、PMSD）である。PMSD内のエントリが使用されて、このBPS1640に関連するプールマネージャシャドウ（PMS）1750が覚えられる。各PMSに対して、PMSD内には、そのBPSを参照する制御項目を有する、エントリが存在する。ただし、PMSが同じBPSに対して複数のエントリを有する場合にも、そのPMSに対して１つのPMSDエントリのみが、PMSD内に発生することに留意されたい。
PMSDは、バッファプールのクレジットが先に空であったバッファプールに供給される場合に再スケジュールが必要とされる、REQ（送信または受信要求）のセットを発見する、メカニズムを提供する。クレジットが先に空であったバッファプールに供給される場合、バッファプール資源を待ってPMS待ち行列（pms_q）内で待ち行列に入れられているREQが存在し得る。PMSDは、立上りルーチンが、待っているREQを有するこのBPSに関連付けられているpmsを走査することができるようにする。
PMSディレクトリのサイズは可変である。最初に、PMS_DIRECTORY_SIZEエントリが、BPS構造それ自体内に割当てられる。付加的なエントリが必要である場合（たとえば、このBPSを参照するpm_createまたはpm_add_controlプリミティブが行われるとき）には、付加的なPMSDエントリを、BPS内の原PMSDサイズのエントリ上に、リンクすることが可能である。同様に、PMSが破壊された場合、関連するどのPMSD内におけるそのエントリも、取除かれる。
点線のリファレンス（1672）が示されるが、これは、新しいBP1640がNODE401に関連付けられるようになることを示す。ノード401を作成したCCBは、図16には示されていないが、ノード作成のためのCCBは、ノード作成のためには上述のように動作し、また、ダイアログおよび他のオブジェクトの作成のためには上述のCCBと同様に動作する。IFE211は、新しく作成されたBP1640に対するリファレンス（1673）を、CCB1611に関連する結果情報の一部として返す。アプリケーション510は、このリファレンスを、BP1640を参照する必要のある、後続のCCB（たとえば、1612）内に、パラメータ値として送る。
CCB1612は、bp_supply_credit（BUFFER_POOL_SUPPLY_CREDIT）プリミティブである。このbp_supply_creditプリミティブは、BPに対してバッファ領域を供給するのに使用される。プルモデルをサポートする相互接続定義のために、局所IFEは遠隔IFEに対して、そのBPに関連するBPSにクレジットされるべきバッファアドレスを知らせる。
CCB1612が、アプリケーションメモリスペース内のバッファ領域のセット1631〜1639を、リファレンス1674および1675によって参照するものとして示されている。バッファ領域の開始アドレスは、どのバイト境界線上にも位置合せすることができる。開始アドレスとは、そのバッファ内のすべてのバイトのうち、数値的に最下位のアドレスである。CCB1612はまた、先に作成されたBP1640を参照して、そのBPリファレンス（1676）をIFE211に対して、CCB1612内のbp_supply_creditパラメータの一部として渡す。IFE211は、バッファリファレンス（1674、1675）をBP1640に保持されるバッファリファレンスリストに（および、プルモデルのために遠隔IFEの関連のBPS内に）付加することによって、bp_supply_creditを処理する。IFE211は、BP（および、対応のBPSオブジェクト）にクレジットされたバッファリファレンスの実際の数を、CCB1612内に記憶される結果情報の一部として、表示する。
CCB1613は、pm_create（POOL_MANAGER_CREATE）プリミティブである。このpm_createプリミティブは、PM（POOL MANAGER）1650を作成するのに使用される。図17に示すように、PM1650は、バッファ優先パラメータを記述し、これが、利用可能なバッファを転送長さに合致させるための最良適合能力を提供する。この優先パラメータは、BPリファレンスおよび選択結合のリストとして保持される。アプリケーションによっては、複数のPMオブジェクトを作成することが可能であり、また、各PMオブジェクトが複数のバッファプールを参照することも可能である。「バッファプールで受信」オペレーションは実際に、PMオブジェクトを参照する。
プルモデルを有効にサポートするために、CIAは、クライアントがPMを特定のNODEと関連付けることを要求する。プルモデルをサポートする相互接続定義のために、局所IFEはそのPMに関連する遠隔IFEに対して、いつバッファ優先パラメータに変化がもたらされたかを知らせる。遠隔IFEは、PMS（POOL MANAGER SHADOW）1750と称される、自身の内部オブジェクト内に、バッファ優先パラメータを記憶する。このバッファ優先パラメータは、可視的に、送信側（すなわち、遠隔IFE）が、PMを参照する受信オペレーションのために、受信側メモリアドレスにデータバイトを正しく結合することを可能にする。
点線のリファレンス（1679）が示されるが、これは、新しく作成されたPM1650がMODE401と関連付けられるようになることを示す。第２の点線のリファレンス（1680）は、BP1640が、その新しく作成されたPM1650によって管理されるバッファプールとして付加されることを表わす。IFE211は、その作成されたPM1650に対するリファレンス（1681）を、CCB1613に関連する結果情報の一部として返す。アプリケーション510はこのリファレンスを、PM1650を参照する必要のある後続のCCB（たとえば、1616）内に、パラメータ値として送る。
CCB1614は、d_create（DIALOG_CREATE）プリミティブである。このd_createプリミティブは、局所IFE（211）上にDIALOG501を作成するのに使用される。IFE211は、その作成されたDIALOG501に対するリファレンス（1682）を、CCB1614に関連する結果情報の一部として返す。アプリケーション510は、このリファレンスを、DIALOG501を参照する必要のある後続のCCB（たとえば、1615、1616）内にパラメータ値として渡す。
CCB1615は、d_associate（DIALOG_ASSOCIATE）プリミティブである。このd_associateは、局所DIALOG501と、遠隔IFE213におけるダイアログ503との間に、終端間の関係を確立するのに使用される。CCB1615は、先に作成されたDIALOG501に、リファレンス（1683）を渡す。これはまた、DIALOG501がNODE401に関連付けられることを示す、リファレンス（1684）もまた渡す。付加的なパラメータ（図示せず）は、CCB1615内に渡されて、DIALOG501内に記憶される。これらの付加的なパラメータは、DIALOG501とDIALOG503との間のエンドツーエンドの関係を完了するための、結合情報を提供する。アプリケーション510は、IFE213から、先に作成されたダイアログを通じるデータ転送を介して、DIALOG503のための連結情報を検索する。CIAは、上述のように最初の「ユーザレベルの管理ダイアログ」を提供して、付加的なダイアログのための連結情報のやりとりをサポートする。
CCB1616は、d_rcv（DIALOG_RECEIVE）プリミティブである。このd_rcvプリミティブは、ダイアログのための入来データを受取るのに使用される。CCB1616は、それに対する入来データを受け入れようとしている、先に関連付けられたDIALOG501に対して、リファレンス（1687）を渡す。CCB1616はまた、このプリミティブの結果として受信されるデータのためのバッファ選択プロセスをPM1650が制御することを示す、リファレンス（1686）を渡す。このd_rcvプリミティブは、種々のデータ分散変形をサポートするよう規定される。アプリケーション510は、データがCCB1616内に渡されるパラメータによってアプリケーションメモリ内に取込まれる方法およびその最大量を制御する。CIAは、データを、バッファプール資源および特定のバッファ領域にわたって分散することができるようにする。「自動受信」d_rcvプリミティブオプションもまた規定されるが、これは、連続的な受信オペレーションの性能を向上させる。なぜなら、d_rcvプリミティブの発行が必要なのは、１回のみであるためである。
１例において、アプリケーションは、d_rcvプリミティブのための結果領域651を指す、結果記述子643を特定せねばならない。この結果領域651は、PMまたは明示的なバッファアドレスであり得る。d_rcvプリミティブのための結果領域651は、バッファアドレスおよび、そのデータ転送を完了するためにバッファプールから消費された転送長さを反映するよう、更新される。d_rcv結果領域651内のバッファアドレスおよび転送長さの最大数は通常、固定されているが、これは可変とすることも可能である。
自動的に反復するd_rcvプリイティブ（すなわち、d_rcvプリミティブのAUTOオプション）に対する一意の結果領域を正しくサポートするために、アプリケーションは、結果領域のためのPMリファレンスを特定せねばならない。windows NTインターフェイスについては、呼戻し通知メカニズムが使用されて、d_rcvの結果を保持するのに使用される結果領域のアドレスが報告される。MCPについては、SysQueueメカニズムが使用されて、結果領域が待ち行列に入れられる。
アプリケーションは、同じダイアログに対して異なるPMを参照する、異なるd_rcvプリミティブを発行することができる。アプリケーションはまた、（DIALOG）およびPMが同じNODEに関連付けられている限り）異なるダイアログに対して同じPMを参照する、d_rcvプリミティブを発行することもできる。すべてのBPおよびPMが同じノードに関連付けられている限り、複数のPMが同じBPを参照することが可能である。
CCB1619は、d_send（DIALOG_SEND）プリミティブである。このd_sendプリミティブは、データを遠隔ダイアログに転送するのに使用される。CCB1619は、その上でデータを転送したい、先に作成されたDIALOG502に対して、リファレンス（1689）を渡す。これはまた、局所DIALOG502に関連する遠隔DIALOG505に転送されるべきデータを含む、バッファ領域1630に対して、リファレンス（1688）を渡す。このd_sendプリミティブは、アプリケーション510がCCB1619内に渡されたパラメータを使用して制御する、データ収集の種々の変形をサポートするよう規定される。１つのd_sendプリミティブがポストされかつ繰返し自動的に処理されるのを可能にする、AUTO d_sendプリミティブもまた、規定することが可能である。
b.  「バッファプールで受信」オペレーションをサポートする、CIAオブジェクトおよびプリミティブの例示
以下に、送信および受信CIAクライアント間の論理ダイアログにわたって、内部接続データ通信を提供する際の、プールマネージャおよびバッファプールのオペレーションおよび管理について、以下に例示するオブジェクトおよびルールを参照して、より詳細に説明する。簡単に言えば、RCB、バッファプール、プールマネージャ、および、対応のシャドウオブジェクトについて、「バッファで受信」および「バッファプールで受信」の両方のオペレーションをサポートする、通信内部接続アーキテクチャに関して、以下に説明する。「バッファプールで受信」オペレーションについては、上述の、「アーリー・ファー・エンド」および「ファー・エンド」のサービスのクラス、分散、収集、自動受信、部分メッセージ、打切り、複数の未処理要求、およびアドレス結合検査等を含む、最適化のための特徴を含めて、さらに説明する。「バッファプールで受信」オペレーションに特有の他の最適化特徴もまた説明するが、これはさらに、バッファプールクレジット、低水位標通知、および、データ結合を含む。しかし、当業者には明らかなように、本発明は、これらのすべての特徴を含むものと限定されるものではない。CIAオブジェクト、プリミティブおよび意味規則を、所望の設計目標に従って修正することによって、これらの特徴の１または複数の何らかの組合せを利用する実装も可能である。
1.  BPオペレーションプリミティブ
1.  バッファプールオブジェクトを作成して、それを特定のNODEと関連付けるのに使用される、プリミティブが存在する（すなわち、bp_create）。このプリミティブは、そのNODEと、バッファプールクレジットに関連するメモリ領域のサイズ（バイト単位）と、（バッファアドレスを記憶するのに使用される）バッファプールクレジットスロットの数と、（プールオブジェクトがいつ、バッファプールクレジットの数が予め定められた限界を下回ったことを示す通知を発行するようにするかを表す）低水位標とを示す。このプリミティブの結果は、その特定された数のバッファプールクレジットスロットで、バッファプールオブジェクトを作成することができるか否かを示す、ステータスを含む。もしバッファプールオブジェクトがうまく作成されれば、このバッファプールオブジェクトに対するハンドルもまた返される。バッファプールハンドルは、特定のIFE内では一意であるが、複数のIFEにわたっては、必ずしも一意ではない。
2.  バッファプールオブジェクトを破壊するのに使用される、プリミティブが存在する（すなわち、bp_destroy）。このプリミティブは、バッファプールハンドルを示す。このプールを参照するすべてのプールマネージャの制御表は、そのバッファプールオブジェクトに対するすべてのリファレンスがその制御表から削除されるように、更新される（この制御表内には空きホールは作成されることはなく、リスト内のすべての後続の項目が繰上げられる）。このプリミティブは、すべてのプールマネージャが更新されて、このバッファプールからバッファに結合されていたすべてのデータの転送が完了すると、完了する。
3.  特定のバッファプールオブジェクトに対してバッファプールクレジットを供給するのに使用される、プリミティブが存在する（すなわち、bp_supply_credit）。このプリミティブは、バッファプールハンドル、および、そのプールにクレジットされるメモリ領域のリストを示す。このプリミティブは、指示されたメモリ領域を、指示されたバッファプールの空きバッファリストに付加する。メモリ領域は、それらが指示されたリスト内に現われるのと同じ順序で、クレジットされる。メモリ領域のリストが、未使用のプールクレジットスロットの数よりも多くの項目を含む場合には、そのリストの、その未使用のバッファプールクレジットスロットを埋める部分のみが適用される。このプリミティブの結果は、このプリミティブによってクレジットされたメモリ領域の数のカウント、および、クレジットが適用された後に残った未使用のプールクレジットスロットの数のカウントを含む。未使用のプールクレジットスロットの数に関する更新結果情報を得るためには、プリミティブがゼロのメモリ領域を供給することが有効である。
4.  クレジット上のバッファプールオブジェクトが残り少ないことを示すのに使用される、通知が存在する（CIA_LOW_WATER_NOTIFICATION）。この通知は、プールからのバッファが消費され、残りのクレジットの数がそのバッファプールオブジェクトに対する低水位標よりも１だけ少なくなると、発せられる。この通知は、資源不足の状況に陥っているバッファプールオブジェクトに対するホストバッファプール記述子を示す。定義上は、低水位標の属性がゼロに設定されている場合には、低水位標の通知が送信されることは決してない。
2.  PMオペレーションプリミティブ
1.  プールマネージャオブジェクトを作成して、それを特定のNODEに関連付けるのに使用される、プリミティブが存在する（すなわち、pm_create）。このプリミティブは、そのプールマネージャオブジェクトがその上に作成されるべきNODEを示す。プールマネージャオブジェクトは、そのプールマネージャオブジェクトを参照するd_rcvプリミティブのための空きバッファプールスペースへとデータをマッピングする結合アルゴリズムによって使用される、制御のセットを記述する。プールマネージャオブジェクトがうまく作成された場合には、そのプールマネージャオブジェクトに一意のハンドルが返される。このプールマネージャハンドルは、特定のIFE内では一意であるが、複数のIFEにわたって必ずしも一意ではない。
2.  プールマネージャオブジェクトを破壊するのに使用される、プリミティブが存在する（すなわち、pm_destroy）。このプリミティブは、プールマネージャハンドルを示す。指示されたプールマネージャオブジェクトを参照する、指示されたNODEに対するダイアログに関連する、ポストされたすべてのd_rcvプリミティブが、誤り表示で完了する。指示されたプールマネージャオブジェクトは削除される。
3.  プールマネージャオブジェクトの制御表に制御を付加するのに使用される、プリミティブが存在する（すなわち、pm_add_control）。このプリミティブは、プールマネージャハンドルと、バッファプールハンドルと、下限値および上限値とを示す。特定されたバッファプールは、プールマネージャまたは誤りが表示されるのと同じNODEに関連付けられねばならない。そうでない場合は、バッファプールハンドル、下限値および上限値は、指示されたプールマネージャの制御表において次に利用可能な項目内に配置される。制御表は典型的に、固定数の項目を保持する。プールマネージャが作成されると、制御表は空になる。
4.  バッファプールオブジェクトからのバッファは、ファーストイン・ファーストアウトの順（すなわち、それらがbp_supply_creditプリミティブによって供給されたのと同じ順）で、消費（すなわち、メッセージデータに結合）される。
3.  データ結合アルゴリズム
送信側IFEは、受信側および送信側が同期したときに、バッファプールスペースに宛てられるメッセージデータの結合を行なう。送信側は、できるだけ大量のデータを結合して、d_sendプリミティブまたはd_rcvプリミティブの終了条件のいずれか（小さい方）を完了する。もし送信側が空きバッファの不足によって結合を完了できない場合には、結合されたデータは結合されたままとされ、送信側は、付加的なバッファクレジットが利用可能となったときに、その結合アルゴリズムの完了を再スケジュールする。もし送信側が、d_rcvプリミティブの意味規則がEOMを待っているために結合を完了できない場合には、送信側は、そのダイアログのための次のd_sendプリミティブが処理されるときに、結合を再開する。
結合アルゴリズムは、データ転送のなんらかの部分がいつバッファプールにマッピングされねばならないかという、バッファ選択基準を判定するために、プールマネージャの制御表を参照する。この結合アルゴリズムは、UNBOUNDカウントを保持する。これは、データ転送のその部分における、未結合のデータバイトの数である。このUNBOUNDカウントは、制御表の要素によって参照されるバッファプールを使用してUNBOUNDカウントのなんらかの部分を充足することができるかどうかを判定するために、制御表内に記憶される範囲値と、比較される。
制御表は、順序付けられたセットである。結合アルゴリズムは、制御表内の第１の要素を最初に検討する。もしUNBOUNDカウントが上限および下限の範囲値（両端を含む）内であり、かつ、その制御表の要素によって参照されるバッファプール内に空きバッファが存在すれば、そのバッファプールの空きリストの先頭からバッファ領域が使用されて、データバイトのいくつかがマッピングされ、そのバッファ領域は空きリストの待ち行列から外され、低水位標条件がチェックされかつおそらくは表示され、そして、UNBOUNDカウントが更新される。もしUNBOUNDカウントがゼロであれば、データ転送のこの部分に関する結合が完了したことを表わす。そうでなければ、このアルゴリズムは、残りのUNBOUND部分について再開される（すなわち、制御表内の第１の要素が、次のUNBOUND部分について再び検討される）。
もしUNBOUNDカウントが特定された範囲外であれば、結合アルゴリズムは、制御表内の次の項目を検討する。制御表内のすべての項目が検討されてもまたUNBOUNDカウントがゼロにならない場合には、その結合は、付加的なバッファ資源が利用可能になったときに再スケジュールされる。
バッファプールの順序付けと範囲の例を、以下に示す。
0003550402.tif 000004
この例においては、1k、4k、および64kのバッファプールが存在する。長さが1Kバイトまでの未結合データ転送が、1kまたは4kのプールに結合され得る。1Kより長く32Kよりも短い未結合データは、もしそのデータが1Kよりも長いかまたは、そのデータが1Kよりも短い場合でも1kのバッファがもはや存在しない場合に、4kプールに結合される。32Kよりも長い未結合データは、利用できる64kのプールクレジットが不足していない限り、64kプールに結合されるが、64kプールクレジットが十分にない場合には、4kプールバッファが使用される。また、残りの32K領域を転送するのに十分な4kバッファが存在しない場合には、1kバッファを使用することが可能である。
4.  ダイアログオペレーションプリミティブ
データがダイアログに対して転送されるべきであることを示す、プリミティブが存在する（d_send）。このプリミティブは、ダイアログ、メモリアドレス、および、ソースメッセージデータの長さを表わす。これはまた、「メッセージの終了」（EOM）がデータ転送の最終バイトと同時に知らされるかどうかを示す。このプリミティブはまた、受信側に結果の一部として送られる、32ビットのトークン値を示す。このトークン値は、EOMが知らされる場合にのみ送られる。データは、送信側ホストの環境に固有のIOバイトの順に、転送される。このプリミティブの結果は、実際の受信メッセージの長さ（すなわち、打切りまたは取消しの前に、受信側によって受取られるデータの量）を含む。
d_sendプリミティブの変形例が存在するが、これは、データ収集を行なうのに使用される表示（アドレス、長さ）の順序リストをサポートする。
d_sendプリミティブは、未処理のd_sendプリミティブ間でソースメッセージ領域が共用されることを可能にする。
d_sendプリミティブは、ソースメモリ領域を（一時的にでさえも）修正することはない。
未処理のd_sendプリミティブの取消しをサポートする、i_cancelプリミティブが存在する。未処理のd_sendプリミティブに対してi_cancelプリミティブが受信されると、IFEは、その未処理のd_sendプリミティブをできるだけ早く終了させる。指示されたd_sendプリミティブは、取消しが有効となる前にd_sendがうまく完了した場合には、go表示を返す。さもなければ、d_sendプリミティブは、no−go表示を返す。
複数の受信が、１つのダイアログに対してポストされ得る。
受信は、それらがダイアログにポストされたのと同じ順序で、かつ、それらが合致する送信がポストされたのと同じメッセージ順で、完了する。
ダイアログに対する入来データを受取るプリミティブが存在する（すなわち、d_rcv）。このプリミティブは、ダイアログ、受け入れようとする入来データの最大長さ、プールマネージャリファレンス、結果ロケーション、および、そのプリミティブの完了前に送信側によってEOMが知らせられるまで、受信側が待つか否かを示すフラグを表わす。このEOMフラグがプリミティブによって示されると、指示された最大長さを越えるデータはすべて、打切られる（すなわち、最大長さを越えてあふれるデータは、打切りに先立って転送されるいかなるデータも上書きすることはない）。このEOMフラグが示されない場合には、プリミティブは、メモリ領域が埋まるか、または、EOMがデータ転送と同時に送信側によって知らされるときに、完了する。受信されたデータは、指示されたプールマネージャリファレンスに関連する、バッファプールからの空きバッファ内に書込まれかつマッピングされる。データは、受信側のIFEシステム環境に固有のI/Oバイト順に、バッファプールメモリ内に転送される。
結果ロケーションは、プリミティブ結果情報を収めるのに使用されるべき、特定のメモリ領域、または、プールマネージャリファレンスを選択する。このプリミティブは、完了時の結果構造の実際のロケーションを示す。この結果ロケーションが特定のメモリ領域を表わす場合、結果構造はそこに書き込まれる。そうでなければ、結果構造は、結果ロケーション表示によって参照される、プールマネージャによって管理される、空きバッファに書かれる。この結果構造は、受信データからバッファプールへのマッピングを記述する、バッファリストを含む。この結果構造は、送信側のメッセージの長さ、および、EOMが受信データと同時に送信側によって知らされたかどうかを示すフラグを含む。この結果構造はまた、送信側からの、32ビットのトークン値を含む。結果構造内のこのトークン値は、EOMフラグが真である場合にのみ有効である。また、EOMがメッセージ領域内の最終バイトと同時に知らされる場合には、EOMもまたプリミティブの結果内に知らされなければならないことに留意されたい。
ダイアログのための入来データを、特定のメモリ領域内に受入れる、d_rcvプリミティブの変形が存在する。このプリミティブは、ダイアログ、受信データが書かれるメモリ領域（すなわち、長さのアドレス）、結果ロケーション、および、プリミティブの完了前に送信側によってEOMが知らされるまで受信側が待つか否かを示すフラグ、を表わす。この結果構造は、送信側のメッセージの長さ、および、EOMが受信データと同時に送信側によって知らされたかどうかを示すフラグ、を含む。
ダイアログのための入来データを受取りかつ、ユーザが特定するメモリ領域およびバッファプールへと分散させる、d_rcvプリミティブの変形が存在する。このプリミティブは、ダイアログ、分散リスト、結果ロケーション、および、EOMがプリミティブの完了前に送信側によって知らされるまで受信側が待つかどうかを示すフラグ、を表わす。分散リスト内の要素は、特定のメモリ領域（長さのアドレス）、または、プールマネージャオブジェクトリファレンスを表わす。受信されたメッセージは、分散リストに示された長さおよび種類に従って、メモリ領域または空きバッファ内に分散される。分散リストは、１または複数の要素をサポートする。空きバッファが、現時点における分散リストの要素が満たされる前に埋まってしまった場合、別の空きバッファを使用して、分散リストのその部分が完了される。参照されたプールマネージャオブジェクトは、空きバッファを選択するのに使用される制御を適用する。結果構造は、受信データのバッファプールへのマッピングを記述するバッファリストを含む。結果構造はまた、送信側のメッセージの長さ、および、受信データと同時にEOMが送信側によって知らされたかどうかを示すフラグ、を含む。結果構造内のトークン値は、EOMが真である場合にのみ有効である。
d_rcvの自動的に反復する変形が、バッファプールのみに受信するために、提供される。d_rcvの自動的に反復する変形は、バッファプールおよびユーザに特定されるメモリ領域のいかなる組合せにも分散するために、提供される。
未処理のd_rcvプリミティブの取消しをサポートする、i_cancelプリミティブが存在する。未処理のd_rcvプリミティブに対するi_cancelプリミティブが受信されると、IFEはできるだけ早く未処理のd_rcvプリミティブを終了させる。指示されたd_rcvプリミティブは、i_cancelが有効となる前に受信がうまく完了した場合に、go表示を返す。さもなければ、d_rcvプリミティブは、no−go表示を返す。
IFEは常に、d_rcvプリミティブの完了について表示する。IFEは常に、d_sendプリミティブの完了を表示する。
通知方式は、より高いレベルのエンティティと相関関係にある。通知（CIA_DIALOG_FAULT_NOTIFICATION）が存在するが、これは、ダイアログ障害条件が生じたことを示すのに使用される。この通知は、ホストのコンテキストおよびダイアログ記述子値、ならびに、IFEの実装に特有の理由コードを表わす。ダイアログ破壊（d_destroy）意味規則は、CIA_DIALOG_FAILURE_NOTIFICATIONが示されかつ、terminate_on_d_faultオプションが動作可能とされると、ダイアログに対して自動的に実行される。ダイアログに対するデータ転送障害は、ダイアログ障害通知を通じて指示される。データ転送の失敗は、活性なd_send/d_rcvプリミティブが、通知エンティティに対して「no go」条件を示すようにする。データ転送障害は、下位クラウド（cloud）がすべての誤り回復および再伝送動作を試みて失敗した後に、発生する。
ダイアログオプション（terminate_on_d_fault）があるが、これは、データ転送ダイアログ障害がダイアログの失敗終了を引起こすかどうかを判定する（すなわち、d_destroy意味規則がダイアログに対して自動的に実行される）。
ダイアログオブジェクトを局所IFE上に作成するのに使用される、プリミティブが存在する（すなわち、d_create）。このプリミティブは、新しく作成されたダイアログオブジェクトに対してダイアログ障害が表示されたときに使用されねばならない、ダイアログ記述子を表わす。他のダイアログ制御オプションも、d_createプリミティブに含むことが可能である（たとえば、優先順位、送信のサービスのクラス、ダイアログ障害オプションが動作可能／動作不能にされるかどうか、送信取消し意味規則、ダイアログ障害通知情報）。このプリミティブはまた、このダイアログに対して任意の１時点で有する可能性のある、未処理のd_rcvプリミティブの数のカウントを提供する。d_rcvプリミティブのAUTO変形を使用するダイアログについては、このカウントは通常、１であるべきである。ダイアログオブジェクトがうまく作成された場合、このダイアログオブジェクトに一意のハンドルが返され、ダイアログ関連情報（すなわち、ダイアログの内容）もまた返される。このダイアログハンドルは、特定のIFE内では一意であるが、複数のIFEにわたって必ずしも一意であるわけではない。
局所ダイアログオブジェクトを遠隔ダイアログオブジェクトと関連付けるのに使用される、プリミティブが存在する（すなわち、d_associate）。このプリミティブは、ダイアログハンドル、ノードハンドル、および、遠隔ダイアログの内容を表わす。指示されるダイアログは、既に関連付けられていてはならない。関連付けがうまく完了したかどうかを示すステータスが返される。
ダイアログに関連する未処理のプリミティブを優雅に終了させるのに使用される、プリミティブが存在する（すなわち、d_shutdown）。このプリミティブは、ダイアログハンドルを表示する。このプリミティブは、指示されたダイアログに関連する、すべての未処理のプリミティブの優雅な取消しを起動する。このプリミティブは、指示されたダイアログに関連する他のすべてのプリミティブが完了を知らせない限り、完了を知らせない。
ダイアログオブジェクトを破壊するのに使用される、プリミティブが存在する（すなわち、d_destroy）。このプリミティブは、ダイアログハンドルを表わす。このプリミティブは、ダイアログを優雅にクローズすることはない。なぜなら、指示されたダイアログに関連する未処理のd_rcvプリミティブに結合されていたバッファプール資源が、正しく返されない場合があるためである。d_destroyプリミティブは、（このプリミティブ自身以外の）未だダイアログにポストされているプリミティブに対しては取消しステータスの表示を行なって、完了ルーチンを呼出す。この指示されたダイアログオブジェクトは削除される。
１つの好ましい実施の形態においては、ダイアログに対して以下の制限を加えることも可能であるが、これらは本発明を限定するものではない。ダイアログ間には、順序付けは何もない。同じ端点による同じダイアログ上の送信と受信との間には、何の順序付けもない（順序付けは一方方向である）。ダイアログが開いている間に、送信のサービスのクラスの変更をサポートする必要はない。
１つの好ましい実施の形態においては、ダイアログについて以下のことが言える。すなわち、ある簡単な形の収集が、d_sendの変形を使用して、端点によって明示的に行なわれ得る。また、簡単な形の分散が、d_rcvの変形を使用して、端点によって明示的に行なわれ得る。
5.  バッファプール
バッファプールは、ローカルで発生したバッファプール創出要求（bp_createプリミティブ）の結果作られる。プルデータモデルでは、バッファプール（BP）の創出には、局所バッファプールと関連するリモートノード上のバッファプールシャドウオブジェクト（BPS）の創出も必要である。バッファプールシャドウは、それがシャドウする元のバッファプールオブジェクトより多い状態情報を含み得る。IFEは、バッファプールおよびバッファプールシャドウ創出（bp_create）、削除（bp_destroy）、属性変更（bp_set_low_water標）ならびにクレジット（bp_supply_credit）についての、CIA意味規則を支持する独自の内部論理ダイアログを使用することができる。バッファプールオブジェクトおよびバッファプールシャドウオブジェクトの例を以下に挙げる。
0003550402.tif 000005
destroy（破壊）フィールド（debit,purged,purge_in_progress,destroy in_progress,req_bp_destroy）は、bp_destroyプリミティブのための正確な意味規則行動の実現を助ける。プールの規則によれば、bp_destroyオペレーションは、すべてのプールマネジャが更新されかつこのバッファプールからバッファ行きのデータの全転送が完了するまで完了として知らされない。
credit（クレジット）は、バッファプールにクレジットされたバッファアドレスの総数を記憶する。
dibit（デビット）は、「完了した」（pay_buffer_complete_payloadsにより示される）を有するバッファアドレスの総数をカウントする。
purged（パージド）は、bp_destroyオペレーションが進行中でないかぎり、普通はゼロである。purgedは、リモートノードが特定のbuffer_pool_shadowから未結合バッファをパージすることを要求する特定のmgr_threadオペレーションの結果である。リモートmgr_threadは、パージされたアドレスの数を表し、purged  count（パージドカウント）は、この値を記憶する。別個のフィールド（すなわちpurged）を使えば、pay_buffer_complete_payloadsを処理する際に、rcv frame_handlerにおいてロック状態を作る必要を回避できる。この他には、purgedフィールドを省略し、debitフィールドを変更することができる。
purge_in_progressは、rcv_frameハンドラへのbp_destroy完了処理を行わないという信号として使用される。bp_destroyオペレーションが完了したと知らせることができる時期について、３つのシナリオが存在する。バッファプールについて、未処理のクレジットが存在しなければ、mgr_threadは、リモートノードからmgr_bp_destroy応答を受け取った後、全くパージを行う必要なくbp destroyを完了する。未処理のクレジットが存在する場合、mgr_threadはmgr bp_purgeを発行して、未結合のバッファをパージし、応答を受けた後も、完了していないバッファがある場合には、mgr_threadはrcv_frame_handlerに依存して、bp_destory完了処理を行う。パージの結果が、すべてのバッファがリターンしたことを示す場合、mgr_threadは、bp_destroy完了処理自体を行う。
destroy_in_progressは、現在破壊が行われているバッファプールのための新しいオペレーションの実行を阻止するために使用するフラグである。
req_bp_destroyは、bp_destroyオペレーションに関連する元のreqを記憶する。
ペイロードコマンドフィールド（data_cmd,rslt_cmd）は、このバッファプールに関連するバッファアドレスへ記憶する際に、リモートノードにより使用される必要がある。バッファプールがデータの転送に使用される場合、data_cmdを使用する必要があり、かつバッファプールアドレスが結果転送に使用される際、rslt_cmdを使用する必要がある。
アドレスチェッキングフィールド（slot_count,slot_take,slot_put,slot）を使用して、このバッファプールに関連する入来の記憶についてアドレスチェックを行う。スロットアレイは、リモートノードバッファプールシャドウにクレジットされた現在のアドレスの組を記憶する。slot_countは、スロットアレイにおけるエントリの数である。slot_countは、付加的なスロットで現在クレジットされている（が必ずしもリモートノードにより受け入れられていない）クレジットを記憶する必要があるので、info.params.slotsより大きくなる。このことにより、スロットのリストにおいてどのアドレスがリモートノードにより「結合」されていて、ローカルノードによりまだ発見されていないかを必ずしも知っているわけではないので、ローカルノードがリモートノードより多くのスロットを必要とするという状況が発生する。
slot_takeおよびslot_putは、スロットアレイに関する呼び出しインデックスである。クレジットがバッファプールへ供給されると、slot_putが進められる。バッファアドレスが使われると、slot_takeが進められる。
6.  プールマネジャ
POOL  MANAGERは、ローカルで発生したpm_create要求の結果として創出される。プルモデルデータでは、プールマネジャの創出には、プールに関連するリモートノード上の類似するプールマネジャオブジェクトの創出も必要とする。リモートノード上の関連する構成（オブジェクト）は、POOL  MANAGER SHADOW（PMS）と呼ばれる。IFEは、独自の内部論理ダイアログを用いて、プールマネジャならびにプールマネジャシャドウ創出（pm_create）、削除（pm_destroy）、およびプール制御追加（pm_add_control）のためのCIA意味規則を支持することができる。
0003550402.tif 000006
7.  プールマネジャシャドウ
POOL_MANAGER_SHADOWは、これがシャドウするPOOL_MANAGERに非常に類似する。
0003550402.tif 000007
8.  バッファプールで受信するためのRCB
一般に、RCBは、CCB1614をパスしたd_rcvパラメータを含む（d_rcvのOPコードを除く）。
9.  ダイアログオブジェクト
この構成は、ダイアログオブジェクトを実現するのに必要な状態を規定する。
0003550402.tif 000008
0003550402.tif 000009
0003550402.tif 000010
0003550402.tif 000011
0003550402.tif 000012
10.  ノード
ノードの構造は、相互接続上のリモートノードに関連するすべてのオブジェクトを追跡するのに使用されるコンテナを規定する。また、このmgr_threadがリモートノード上のmgr_threadと通信するのに使用する特定マネジャデータ構造も規定する。
0003550402.tif 000013
0003550402.tif 000014
0003550402.tif 000015
7.  コンピュータシステムの例
本発明による通信内部接続アーキテクチャは、いずれのタイプのホストプロセッサ、マルチプロセッサ、ならびにそれに限られるわけではないが、ホストシステムおよびWindows NT互換性プログラミングインタフェースを含むプログラミングインタフェース上のトランスポート機能として実現できる。
図18は、本発明が機能するコンピュータシステム例18のブロック図である。コンピュータシステム1800は、プロセッサ1804等の１以上のプロセッサを含む。プロセッサ1804は、通信バス1802に接続される。
コンピュータシステム1800は、メインメモリ1808、好ましくはランダムアクセスメモリ（RAM）も含み、また二次メモリ1810を含み得る。二次メモリ1810は、たとえば、ハードディスクドライブ1812および／またはフロッピーディスクドライブ、磁気テープドライブ、光ディスクドライブ等の取り外し可能な記憶ドライブ1814を含み得る。取り外し可能な記憶ドライブ1814は、周知の態様で取り外し可能な記憶ユニット1818から／へ読み出し／書込みを行う。取り外し可能な記憶ユニット1818の代表がフロッピーディスク、磁気テープ、光ディスク等であり、これらは取り外し可能記憶ドライブ1814によって書込み／読出しが行われる。取り外し可能記憶ユニット1818が、コンピュータソフトウエアおよび／またはデータを内部に記憶したコンピュータが使用可能な媒体を含むことはもちろんである。
他の実施例としては、二次メモリ1810がコンピュータシステム1800にコンピュータプログラムや他の命令をロードできるようにする他の同様の手段を含み得る。そのような手段には、たとえば取り外し可能記憶ユニット1822およびインタフェース1820を含み得る。たとえば、プログラムのカートリッジとカートリッジインタフェース（ビデオゲーム装置に見られるようなもの）、取り外し可能なメモリチップ（EPROMまたはPROM等）と関連のソケット、およびソフトウエアおよびデータを取り外し可能な記憶ユニット1822からコンピュータシステム1800へ転送することができる他の取り外し可能な記憶ユニット1822とインタフェース1820が考えられる。
コンピュータシステム1800は、通信インタフェース1824も含み得る。通信インタフェース1824によりソフトウエアとデータを、通信経路1826を介してコンピュータシステム1800と外部の装置との間で転送することができる。通信インタフェース1824の例には、モデム、ネットワークインタフェース（イーサネットカード等）、通信ポート等が考えられる。通信インタフェース1824により転送されるソフトウエアとデータは、通信経路1826を介して、通信インタフェース1824が受信することのできる電子、電磁、光学および他の信号の信号形式のものである。通信インタフェース1824は、コンピュータシステム1800がインターネット等のネットワークにインターフェースできる手段を提供する。
本発明は、この例示的状況について記載されている。これらの条件における記載は、便宜上のものである。本発明は、この例示的状況における応用に限定されるものではない。実際、以下の説明を読めば、当業者には他の状況下においても本発明を実現する方法が明らかになるであろう。
本発明は、上記の説明に類似の環境で動作する（すなわち実行する）ソフトウエアを使用して実現され得る。本明細書においうては、「コンピュータプログラム製品」と言う語は、一般に取り外し可能記憶装置1818またはハードディスクドライブ1812にインストールしたハードディスクを指すものとして使用される。これらのコンピュータプログラム製品は、コンピュータシステム1800にソフトウエアを提供するための手段である。
コンピュータプログラム（コンピュータ制御論理とも呼ぶ）は、メインメモリおよび／または二次メモリ1810に記憶される。コンピュータプログラムも通信インタフェース1824を介して受信できる。これらコンピュータプログラムは、実行されるとコンピュータシステム1800を能動化して本明細書中に記載する発明の構成を実行する。したがって、これらのコンピュータプログラムは、コンピュータシステム1800のコントローラに相当する。
ソフトウエアを用いて発明を実現する実施例では、取り外し可能記憶ドライブ1814、ハードドライブ1812または通信インタフェース1824を使用して、ソフトウエアをコンピュータプログラム製品に記憶し、コンピュータシステム1800にロードする。この他、コンピュータプログラム製品を通信経路1826上でコンピュータシステム1800へダウンロードしてもよい。制御論理（ソフトウエア）をプロセッサ1804で実行すると、プロセッサ1804は、本明細書中に記載の発明の機能を実行する。
このコンピュータシステムの例に関して様々なソフトウエアの実施例を記載する。この説明を読めば、他のコンピュータシステムおよび／またはコンピュータアーキテクチャを使用して本発明を実現する方法が当業者には明らかになろう。
他の実施例では、本発明は、たとえば特定用途向け集積回路（ASIC）等のハードウエアコンポーネントを用いて、基本的にファームウエアおよび／またはハードウエアで実現される。本明細書に記載の機能を実現するためにハードウエアステートマシンを実現することは、当業者にとり自明であろう。
8.  CIA−IFEインタフェースの例
a.  CIA−IFE初期化
CIAのクライアント（ユーザクライアントおよび／またはカーネルクライアント）は、５つのインタフェース手続きを使用することができる。すなわちCiaInitiate、CiaTerminate、CiaIfeEnum、CiaIfeOpenおよびCiaIfeCloseである。CiaInitiateルーチンは、クライアントに状態情報を割当て初期化する。他のCIAインタフェース手続きのいずれかを呼び出す前に、各CIAクライアントは、CiaInitiateルーチンを一度呼び出す必要がある。このルーチンは、CIAの実現に、そのクライアントについてのCIA意味規則を適正に実現するために必要な状態情報を割当て、初期化するチャンスを与える。
CiaTerminateルーチンは、通常、CIAクライアントがCIAサービスをそれ以上必要をしない場合に、呼び出す。このルーチンは、CIAの実現に、そのクライアントに割当てられた状態を（割当て）解除するチャンスを与える。ユーザレベルに関連する状態情報は、ユーザプロセスがCiaTerminateを呼び出さず突然終了しても自動的に解除される。
CiaIfeEnumルーチンは、CIA Primitive Interfaceに登録したIFEのセットを決定するために使用できる。各IFEに関する属性もリターンされる。これには、名称、アドレス、バージョン、タイプおよび制御ブロックサイズ情報が含まれる。
CiaIfeOpenルーチンは、登録されたIFEを開き（名称）でかつそのリファレンスを取得するために使用可能である。必要なら、IFEを初期化する。このルーチンの出力パラメータは、開かれたIFE行きのCCBのIFEフィールドで使用すべきIFEハンドルを示す。クライアントは、IFEの最初期化を生じることなく、同じIFEを一度以上開くことができる。リターンされたIFEハンドルは、同じ名称のIFEの複数のオープンと同じ値でも良いし、同じでなくても良い。
CiaIfeCloseルーチンは、先に開かれたIFEに対するクライアントの参照を閉じる（クローズする）ために使用する。IFE処理の最後のクローズでは、そのIFEに関連する状態の割り当てが解除される。ユーザレベルクライアントが、開いた各IFEについてCiaIfeCloseを呼び出すことなく突然終了した場合、IFEは自動的に閉じられる。
CiaIfeOpルーチンは、IFEに対し、CIAプリミティブを発行するために使用可能である。このルーチンは、非ブロックで、プリミティブが完了したことをクライアントに知らせるロシージャコールバック機構を使用する。CCBは、プリミティブを記述するCiaIfeOpおよびIFEへ送られ、実行されることになる。ある例では、クライアントが割当てるCCBの実際のサイズは、少なくともIFEのCiaIfeEnumの結果においてリターンされる制御ブロックのサイズ以上である。制御ブロックの末端の追加スペースは、IFEの作業空間でありかつIFE特定の用途についてリザーブされる。
b.  CIAプロバイダ
図19は、２つのCIAプロバイダを示す。すなわちCIA MEM.SYSおよびCIA XXX.SYSである。この例では、CIAプロバイダは、１以上の内部接続に渡ってCIA意味規則を実現するNTドライバである。CIAプロバイダがレジスタするIFEのセットは以下のものと相関関係がある。すなわち、
1.  システムにインストールされたハードウエア。
2.  構成レジストリにおける特定のエントリの実現。
3.  プロバイダが支持するアタッチメントスタイル。
CIAプロバイダは、インタフェースを使って、IFEオブジェクトを創出しかつそれらをCIA Primitive Interfaceにレジスタまたはアンレジスタする。CIAプロバイダは、好ましくは、一意の名称（ローカルNTに一意）で各IFEオブジェクトをレジスタする。関連の内部接続アダプタがある場合には、CIAプロバイダは、IFEの名称の一部としてPCIバスおよび装置情報を使用することによって一意のIFE名称を発生し得る。CIAプロバイダは、ドライバがアンロードされなければ（sc stop＜driver＞等）、IFEをアンレジスタしない。そのIFEのすべてが閉じられなければ、ドライバはアンロードされない。
c.  IFEアタッチメントスタイル
図20に示すとおり、CIAは３つのアタッチメントスタイルを定義する。すなわち、ポイント・トゥー・ポイント（２点間）、ループバックおよびメッシュである。CIAプロバイダは、同時に複数のアタッチメントスタイルを支持してもよい。ポイント・トゥー・ポイントアタッチメントでは、異なるシステムからの２つのIFEオブジェクトを正確に結合する。ループバックアタッチメントは、同じシステムからの２つのIFEを接続する。ループバック接続は、同じシステム上で動作する２つのアプリケーション間のCIAアプリケーションを支持するために使用される。メッシュアタッチメントは、１以上のシステムからの１以上のIFEを接続する。
d.  CIA代理（プロキシ）ドライバ
Windows NT CIA実現は、非カーネルのCIAクライアントおよび他のシステム（MCP等）のIFEオブジェクトのホスティングを支持する。これらのサービスは、図21に示すCIA代理ドライバが提供する。CIA USER.SYSは、ローカルのWin32クライアントの代理ドライバとして使用する。これが提供するサービスは以下の通り。
1.  ユーザ／カーネル境界でCIA意味規則を実現するNT IOインタフェースおよびCIA.DLLへインターフェースする。
2.  CIAプリミティブが参照するユーザメモリ領域のメモリ管理（プローブ、ロック、アンロック）を行う。
3.  CIA Primitive Interfaceを実現する。なお、CIA USER.SYSは、実際のCIAプリミティブ（d_send等）は実現しない。プリミティブをIFEに向けるCiaIfeOpルーチンを実現する。
リモートホスト代理ドライバは、以下のサービスを提供する。
1.  リモートホストメモリ読出し・書込みサービス
2.  リモートホスト特定CCBから固有のNT CCBを創出（大から小エンディアンフォーマントへフィールドを変換する変換等）
3.  CIA固有NT CCB結果を特定ホストフォーマットへ変換する変換
4.  CIA固有通知機構（すなわちコールバック）をリモートホストに適切な機構に変換する変換
CIAは、複数のリモートホスト代理ドライバを支持する。リモートホスト代理ドライバも、複数のリモートホストインタフェースアダプタを支持することが可能である。各リモートホストインターフェースアダプタは一意のnode_interface値を割当てられる。node_interface値は、メッシュベースのCIAプロバイダが入来フレームを正しいIFEに向けるために必要とするアドレス指定情報を提供する（複数のIFEが同じ内部接続アダプタを共有する可能性あるので）。node_interface値の割当ては、CIA Primitive Interfaceにより複数の代理ドライバの間で調整される。
代理ドライバは、CiaInitiateの呼び出し者に割当てられたnode_interface値を示す。代理ドライバ（Win32、リモートホスト等）により行われるプログラミングインタフェースは、そのnode_interface値が、CiaInitiateによりリターンされるものに一致するIFEのみを開くことができる。このエンフォースメントは、代理ドライバの責任である。カーネルベースのCIAクライアントは、どのIFEオブジェクトでも開くことができる。代理ドライバでないカーネルベースのCIAクライアントは、そのnode_interface値がCiaInitiateがリターンするものに一致するIFEだけを開く必要がある。
e.  IFEアドレス指定
図22および図23は、IFEアドレス指定スキームの例を示す。図22は、２つの部分から成るアドレス（duple）を使用してアドレス指定されたメッシュベースのアタッチメント上のIFEを示す。第１の部分は、node_idと呼ばれ、IFEが論理的に付属するハードウエアアダプタのMACアドレスを指す。第２の部分は、node_interfaceと呼ばれ、そのIFEに対し作用する代理エージェントを指す。
図23に示すとおり、IFEのグループがアタッチメントグループを構成する。各IFEも、そのアタッチメントグループを指す属性を有する。CIAクライアントは、アタッチメントグループの値を調べて、図23に示すIFEの関連のセットを決定する。
9.  結論
本発明の様々な実施例について上に記載したが、これらは、例示の目的のみのものであって限定を意図するものではないことを理解されたい。当業者においては、添付の請求項に記載の発明の精神および範囲から逸脱することなく、形態および細部について様々な変更が可能であることを理解されるであろう。したがって、本発明の範囲は、上記の実施例のいずれかによっても限定されることなく、以下の請求項およびその均等物にしたがってのみ規定される。
【図１Ａ】
0003550402.tif 000016
【図１Ｂ】
0003550402.tif 000017
【図１Ｃ】
0003550402.tif 000018
【図２】
0003550402.tif 000019
【図４】
0003550402.tif 000020
【図３】
0003550402.tif 000021
【図５】
0003550402.tif 000022
【図６Ａ】
0003550402.tif 000023
【図６Ｂ】
0003550402.tif 000024
【図７Ａ】
0003550402.tif 000025
【図１９】
0003550402.tif 000026
【図７Ｂ】
0003550402.tif 000027
【図８】
0003550402.tif 000028
【図９】
0003550402.tif 000029
【図１０】
0003550402.tif 000030
【図１１】
0003550402.tif 000031
【図１２】
0003550402.tif 000032
【図１３】
0003550402.tif 000033
【図１４Ａ】
0003550402.tif 000034
【図１４Ｂ】
0003550402.tif 000035
【図１５Ａ】
0003550402.tif 000036
【図１５Ｂ】
0003550402.tif 000037
【図１５Ｃ】
0003550402.tif 000038
【図１６】
0003550402.tif 000039
【図１７】
0003550402.tif 000040
【図１８】
0003550402.tif 000041
【図２０】
0003550402.tif 000042
【図２１】
0003550402.tif 000043
【図２２】
0003550402.tif 000044
【図２３】
0003550402.tif 000045