JP2505050B2 - 複数プロセツサ間で通信するためのシステム - Google Patents

Description

【発明の詳細な説明】 A.産業上の利用分野 本発明は、一般に複数のプロセッサを含むデータ処理
システムの通信プロトコルに関し、具体的には、クラス
タ形式の多重プロセッサ・データ処理システムにおける
複数のプロセッサのカーネル間での直接の通信を可能に
する、新しい軽量な通信プロトコルに関する。

B.従来の技術 多重プロセッサ・データ処理システム中のプロセッサ
が情報を共有するための通信プロトコルは、従来技術で
多数開示されている。どの通信プロトコルを使用するか
は、多重プロセッサ・システムの特定の設計及び動作上
の制約条件によって決まる。

多重プロセッサ・システム構成は、論理通信チャネル
を共有する複数の処理ユニットと考えることができる。
論理通信チャネルは、ある処理ユニットから別の処理ユ
ニットへのメッセージが記憶できる、処理ユニット間で
共有されるメモリの形を取ることができる。また、論理
通信チャネルは、処理ユニット間を移動するメッセージ
が通過する通信ネットワークの形を取ることもできる。

通信に関して、こうした従来技術の多重プロセッサ・
コンピュータ・システムは、全般的に密結合（tightely
−coupled）システム、近接結合（closely−coupled）
システム、及び疎結合（loosely−coupled）または分散
多重プロセッサ・システムに分類できる。

密結合システムとは、物理的に互いに極めて密接し、
同じメモリにアクセスでき、同じオペレーティング・シ
ステムを走らせることができる同一の処理ユニットを複
数個有するものである。処理ユニット間の通信媒体はき
わめて高速である。処理ユニットは、共有メモリから構
成されることもあり、専用バスを介する信号伝達や当該
のコンピュータ・システムに特有な他の方法を含むこと
もある。使用される通信プロトコルも非常に特殊な専用
プロトコルであり、そのプロトコルは、完全にハードウ
ェアで実施できることもあるが、いかなる場合でも、通
信には極めて僅かのオーバーヘッドしか加わらない。こ
うしたシステムの利点は、複数のプロセッサを一緒に使
用してシステム作業負荷を処理することができる点であ
る。

分散システムは、物理的にほんの数フィートしか離れ
ていないものもあり、数百マイルも離れているものもあ
る。通信媒体は通常、電話線、人工衛星、イーサネット
（Ethernet、ゼロックス（Xerox）社の座標）やトーク
ン・リング（Token Ring、IBM社の商標）、のようなロ
ーカル・エリア・ネットワークなど当業界で標準の媒体
である。分散システム中のプロセッサはすべて互いに異
なっていてもよい。こうしたシステムは、まったく異な
るオペレーティング・システムを走らせ、互いにまった
く独立していることもしばしばであるが、データが共有
できるように協働する。そうしたシステムを用いると、
データの増加量に応じてより多くのシステム上にデータ
が分散でき、可用性を高めるため複数のシステムでデー
タが複製できる。こうした分散システムで使用される通
信プロトコルは、システム・ネットワーク・アーキテク
チャ（“SNA"、IBM社の商標）や伝送制御プロトコル/In
ternetプロトコル（“TCP/IP"）など当業界の標準プロ
トコルになっているものが多い。

近接結合または「クラスタ化」システムは、他の２つ
の構成の利点を組み合わせようとしたものである。こう
したシステムは、同じ部屋でなくても、通常少なくとも
同じビル内にあり、イーサネットなどの標準通信媒体
や、ディジタル・エクイップメント（Digital Equipmen
t Corporation）社のクラスタ相互接続バスなどの専用
の媒体を使用することができる。これらのプロセッサは
通常互いに類似しており互換性がある。それらのプロセ
ッサは、各マシンで同じオペレーティング・システムを
走らせ、分散システムよりもはるかに緊密に協働して、
データ共有以外の機能を可能にする。その目標は、一般
にユーザに単一のシステムと思わせることである。

最近、複数の仮想メモリ・データ処理ユニットをクラ
スタ式構成で相互接続する提案が、カイリ（Kai Li）及
びパウル・フダク（Paul Hudak）の論文「共有仮想記憶
システムにおけるメモリ整合（Memory Coherence in Sh
ared Virtual Storage Systems）」、分散計算の原理に
基づく計算機シンポジウム第５回年会（the Fifth Annu
al Association for Computing Machinery Symposium o
n Principles of Distributed Computing）（1986年）
に提出された。提案されたマシン・クラスタでは、すべ
てのユニットが、同じ形式のオペレーティング・システ
ムをもち、同じ仮想メモリ空間にアドレスすることがで
きる。

したがって、クラスタ化構成の各ユニットは、その仮
想メモリ・システム内の１組のアドレスをその構成の他
のユニットと共有し、ページ不在処理機構が、他のユニ
ット並びにそのプロセッサの２次記憶装置からページを
取り出すように拡張される。こうしたクラスタ式システ
ムのユニットがページ不在に出会うと、２次記憶装置か
らではなく他の装置からページのコピーを要求すること
により、ページ不在を処理することができる。これは、
他のユニットがそのメモリにそのページを含み、２次記
憶装置よりもはるかに迅速に応答できるという利点があ
る。こうしたクラスタの複数のユニットに所与のページ
のコピーがあるので、ページ不在に出会ったユニット
は、ページのコピーをどこに要求するべきか知らないこ
とがある。さらに、特殊な措置を講じない限り、２つの
ユニットがあるページを同時に変更するなどの異常が発
生することがある。また、あるページを読み取るとき、
読取り側と書込み側が物理的に別々のプロセッサにいる
場合でも、最近の書込み動作の結果が見られるように保
証することが重要である。この種の共有を適切に働かせ
るため、ページ変更の許可を与える、ページの所有者を
見つける、ページをいつ所有者に戻すかを決定するなど
のことを行なう、システム・プロトコルを確立すること
ができる。この種のシステム・プロトコルは、システム
間の様々なユニット中で大量の通信を必要とする。

これまでに、IBM社が開発したSNAを含めて、遠隔プロ
セッサ間で情報を伝送するための多数の標準通信プロト
コル、ならびに米国特許第4648061号及び第4532588号に
記載された「ドキュメント交換プロトコル」など、SNA
と共に使用される多数の専用プロトコルが開発されてい
る。

通信プロトコルが対処しなければならない通信システ
ムの基本的問題は、受信側プロセッサのメモリにメッセ
ージを受信するのに十分なバッファ空間があるかどうか
である。従来分散システムで通常使用されていたプロト
コルでは、十分なバッファ空間がない場合でさえ、メッ
セージが首尾よく受信されたことを送信側プロセッサに
通知する通信リンク・レベルでの肯定応答（ACK）が、
受信側プロセッサから送信側プロセッサに送られてき
た。通信リンク・レベルの肯定応答“ACK"は、通常通信
リンク・アダプタなどのハードウェアまたは比較的低位
のソフトウェアによって送られる。受信側プロセッサが
首尾よくメッセージを受信したことを送信側プロセッサ
に通知するリンク・レベル“ACK"が送られた場合でさ
え、受け取ったメッセージを記憶する十分なバッファ空
間が受信側プロセッサにない場合は、受信側プロセッサ
はそのメッセージを捨てなければならない。すなわち、
より高位のソフトウェア・レベルで、メッセージを捨て
なければならない。あるいは受信したメッセージを記憶
するバッファがないという他のメッセージを、受信側プ
ロセッサが送信側プロセッサに送らなければならない。
この基本的問題から、特に分散データ処理システムにお
いて、SNAなどのハードウェア／ソフトウェア複合アー
キテクチャを利用する必要が生じた。

メッセージ・パス・モデルを利用する、従来技術で開
示された疎結合多重プロセッサ構成では、別々の処理ユ
ニット上で走行する個々のカーネルが、構成全体で共有
される資源を管理するサービス要求を含むメッセージ
を、構成内の他の処理ユニットに送信する。メッセージ
・パスは当然のことながら処理ユニット間の基本通信接
続に対応しているので、「メッセージ・パス」モデルへ
の依存は確かにあったが、それは、疎結合構成の主要な
性能上のボトルネックとなると一般に考えられる。しか
し、システム結合のモデルとしてのメッセージ・パスは
いくつかの欠点をもつ。

メッセージ・パス・システムにおいてプロセッサ間で
複雑なデータ構造（たとえば、ポインタを含む制御ブロ
ック）を直接共有するのが困難なことはよく知られてお
り、M.ヘルリヒ（Herlihy）及びB.リスコフ（Liskov）
の論文「抽象データ・タイプの値伝送方法（A Value Tr
asmission Method For Abstract Data Types）」、プロ
グラミング言語及びシステムに関するACM紀要（the ACM
Transactions on Programming Languages and System
s）、Vol.4、No.4、（1982年10月）に記載されている。
この主題は、B.ネルソン（Nelson）の博士論文「遠隔手
順呼出し（Remote Procedure Call）」、カーネギー・
メロン大学、1981年５月刊でも考察されている。

多重プロセッサ構成内の別々の処理ユニットで実行さ
れるオペレーティング・システムの２つの構成要素間で
要素のリストを共有することは、それ自体比較的一般的
な要件であるが、そのためには、それらの要素を送信側
構成要素で送信に適した書式にパックして、送信側構成
要素から受信側構成要素に送り、受信側構成要素でパッ
クを解除しなければならない。この動作シーケンスはプ
ロセッサの利用度の点で不十分である。

より重要なことであるが、この動作シーケンスは複雑
で扱いにくい。メッセージ・パスの主な欠点は、送信側
及び受信側構成要素が、使いにくく複雑なアーキテクチ
ャになり、コストが高くつき、実施、デバッグ、機能強
化及び保守が難しくなり勝ちなことである。代表的な汎
用オペレーティング・システムのカーネルは多くの相互
作用する構成要素から構成されることが多いので、メッ
セージ・パス・モデルの周囲の多重プロセッサ構成のオ
ペレーティング・システムが複雑になる傾向にある。

複数のユニットが密結合ユニットと同様の仮想メモリ
を共有するクラスタ型構成では、通信プロトコルは、様
々なユニットにおけるオペレーティング・システムのカ
ーネル間での迅速な転送を実行する必要がある。選択さ
れたプロトコルは、ページ不在の場合に共有仮想メモリ
からページを得ること、あるユニットがあるページから
読み取ろうとするとき、別のユニットがそのページに書
き込もうとする場合に同じページに対する同時要求を管
理する方法、及び記憶データを共有する機能に共通なそ
の他の様々な状況などのような問題に付随する高レベル
の通信トラフィックに対処しなければならない。前述の
ように、疎結合分散コンピュータ・システム用に過去に
開発された標準通信プロトコルは、ユニット間でデータ
を伝送するのに必要な命令の数の点で通信に大きなオー
バーヘッドを課し、したがってデータ・プロセッサの共
有仮想メモリ・クラスタのもつ潜在的な利点を打ち消す
ことがあり得る。

C.発明が解決しようとする課題 したがって、本発明は、クラスタ型多重プロセッサ・
システムにおけるプロセッサのオペレーティグ・システ
ムのトラステッド・カーネルが、高速通信リンクを介し
て制御情報及びデータを通信することができるように設
計された、新しい、軽量な通信プロトコルを対象とす
る。

D.課題を解決するための手段 本発明は、複数の個別プロセッサ間で通信するための
新しい改良された通信システムを開示する。このプロト
コルは、送信側プロセッサの構成要素から受信側プロセ
ッサの構成要素にメッセージを送るための送信側プロセ
ッサ内の機構、そのメッセージの受信時に、受信側プロ
セッサ内の宛先構成要素でバッファ空間が利用可能かど
うかを動的に決定するための受信側プロセッサ内の手
段、及びそのメッセージが受信側プロセッサによって受
信され、宛先構成要素でメッセージを記憶するのに十分
なバッファ空間が利用可能であるという肯定応答または
十分なバッファ空間がないという否定応答を送信側プロ
セッサに送るための受信側プロセッサの機構を含む。こ
のプロトコルはまた、受信側プロセッサでメッセージを
受信するのに十分なバッファ空間が利用可能であるとの
受信側プロセッサによる決定を、送信側構成要素に通知
するための送信側プロセッサ内のソフトウェアを含んで
いる。

送信側プロセッサによって送られるメッセージは、制
御セグメントとユーザからのデータ・セグメントとを含
む。メッセージが書式化された後、送信側プロセッサ
は、送信側プロセッサから受信側プロセッサに連続して
メッセージを送ることが好ましい。送信側プロセッサ内
のプロトコル機構は、肯定応答が受信側プロセッサから
受信されない場合、送信側構成要素への通知なしに、送
信側プロセッサでメッセージを待ち行列に入れるルーチ
ンを含む。受信側プロセッサも、バッファ空間が利用可
能になったとき、受信側構成要素が待ち行列メッセージ
を受け取るのに利用できるバッファ空間をもつことを、
送信側プロセッサに通知するための機構を含む。

受信側プロセッサ側のシステムは、受信側プロセッサ
に到着するメッセージを記憶するバッファ・プールを含
み、バッファ・プールの一部が受信側プロセッサ内の複
数の構成要素のそれぞれに割り当てられる。このシステ
ムはまた、各構成要素に割り当てられたバッファ空間
の、到着メッセージ用に利用可能な部分の記録を保持す
る。

通信システムが、受信側プロセッサ内の構成要素を、
第１クラスと第２クラスに分け、第１クラスの各構成要
素には第２クラスとは別のバッファ・プールを割り当て
ることが好ましい。「自由」クラスの特定の構成要素に
割り当てられた「自由」バッファ・プール内のバッファ
は、宛先構成要素に割り当てられた自由バッファ・プー
ルの部分にメッセージ用の十分な空間がないという決定
に応えて、自由クラス内の別の構成要素に割り当てられ
たバッファ空間に転送することができる。「厳格」クラ
スの特定の構成要素に割り当てられた「厳格」バッファ
・プール内のバッファは、別の構成要素に割り当てられ
たバッファ空間に転送できない。

受信側プロセッサでは、宛先構成要素向けの関連メッ
セージが受信側プロセッサに到着し、その宛先構成要素
に利用可能な十分な空間があるとき、複数のサービスに
アクセスするための手段をもつ割込みハンドラが、宛先
構成要素に関連する割込みハンドラ拡張部分を呼び出
す。

代替実施例では、通信プロトコルが、ネットワーク内
の中間プロセッサを介して送信側プロセッサと受信側プ
ロセッサの間で通信し、送信側プロセッサ内のプロトコ
ル機構が第１通信リンクを介してメッセージを中間プロ
セッサに送る。中間プロセッサはそのメッセージを受信
し、第２通信リンクを介してそのメッセージを受信側プ
ロセッサに再送信する。次に受信側プロセッサは、受信
側プロセッサの宛先構成要素でメッセージ用にバッファ
空間が利用可能かどうかを決定する。十分なバッファ空
間が利用可能な場合、受信側プロセッサに十分なバッフ
ァ空間があるという肯定応答が、受信側プロセッサから
中間プロセッサに送られる。中間プロセッサは、肯定応
答を受け取ると、受信側プロセッサで十分なバッファ空
間が利用可能であるという肯定応答を送信側プロセッサ
に送る。

受信側プロセッサで十分な記憶空間が利用可能でない
という否定応答を、受信側プロセッサが中間プロセッサ
に送る場合、中間プロセッサは、受信側プロセッサに十
分なバッファ空間がないという否定応答を送信側プロセ
ッサに送る。

E.実施例 第１図は、本発明の通信システムが有利に使用でき
る、多重プロセッサ・クラスタ構成データ処理システム
の構成図である。第１図では、多重プロセッサ・クラス
タは、複数のプロセッサ・ユニット10、スイッチ11、及
びそれぞれプロセッサ・ユニット10をスイッチ11に接続
する複数の通信リンク12を含んでいる。スイッチ11の機
能は、任意のプロセッサ・ユニット10が他のプロセッサ
・ユニット10と通信できるようにすることである。プロ
セッサ10A、10B、10C、10Dだけが図示してあるが、ネッ
トワーク内のプロセッサの実際の数はもっと多い。

本明細書で開示する通信システム及び多重プロセッサ
・クラスタと共に使用するのに適した高速スイッチの特
定の詳細は、本発明を理解するのに重要であるとは考え
られない。使用できる適切なスイッチ装置の例は、米国
特許第4635250号及び第4605928号に出ている。

第２図は、通信プロトコルが使用できるクラスタ構成
の多重プロセッサ・データ処理システムの代替構成を示
す。第２図では、複数のプロセッサ・ユニット10が通信
リンク14によって互いに接続されている。

第３図は、ユニット10が本発明の通信システムを利用
して他の非隣接ユニット10と有利に通信できる、たとえ
ば、後で詳しく説明するように、ユニット10Aがユニッ
ト10Bを介し、ユニット10Aから10Bへの通信リンク16と1
0Bから10Dへの別の通信リンク16を介して非隣接ユニッ
ト10Dと通信するという、多重プロセッサ・クラスタ別
の構成を示す。

第４図は、第１図、第２図、第３図に示すプロセッサ
・ユニット10をより詳細に示している。プロセッサ・ユ
ニット10は、高機能パーソナル・コンピュータまたはエ
ンジニアリング・ワークステーションでよく、IBM AIX
（IBM社の商標）オペレーティング・システムを走行さ
せ、801アーキテクチャをもつ。しかし、本発明を実施
する際、他のアーキテクチャとオペレーティング・シス
テムも利用できることに留意されたい。

プロセッサ・ユニット10は、プロセッサ17、主メモリ
18、プロセッサ17とメモり18の間でのデータの転送を制
御する記憶制御ユニット19、及び複数の入出力ポート20
A−20Eを含む。ポート20Aと20Bは、表示型端末21と22を
プロセッサ・ユニット10に接続する働きをする。ポート
20Cはプリンタ23をプロセッサ10に接続し、ポート20Dは
ディスク・ドライブ24をプロセッサに接続する。

通信入出力アダプタ15、好ましくは直列リンク・アダ
プタ（SLA）は、プロセッサが他のプロセッサに直接
（第２図）、またはスイッチを介して他のプロセッサに
（第１図）、または中間プロセッサを介して非隣接プロ
セッサ（第３図）に迅速にデータを転送できるように、
プロセッサ・ユニット10のポート20Eを、第１図の通信
リンク12、または第２図の通信リンク14、または第３図
の通信リンク16に接続する。以後、通信リンクと言うと
き、便宜上、通信リンク12を指すものとする。

好ましい通信リンク12は、関連特許出願に記載されて
いる直列リンクである。直列リンク12は、プロセッサ10
の各ポート20Eと相互接続するための、光ファイバ・ケ
ーブル13（第５図）とその両端部にあるSLA15を含む。
光ファイバ・ケーブルまたはリンク13は、最高64Kバイ
ト長のメッセージを、200Mビット／秒以上の速度で転送
する。リンク13は、あるプロセッサのメモリからデータ
を取り出して、それを他のプロセッサのメモリに置く。
メモリ・アクセスを制御するタグ・ワードが、64バイト
の境界上で分散／収集機能を実行する。直列リンク・ア
ダプタ15は、データ転送が正確に行なわれるようにする
ためのリンク・レベル装置プロトコルを実施したもので
ある。リンク13と共に使用できるプロトコルは２つあ
り、中間送信要求（RTSI）及び送信要求／受信要求（RT
S/RTR）と呼ばれる。

RTSIは、受信アダプタが前もってセットアップされる
場合、ソフトウェアの介入なしにデータがメモリに配送
されるという点でより効率的である。RTS/RTRを用いる
と、データが適切なメモリ位置に配送できるが、余分な
割込み、及び受信アダプタのソフトウェア・セットアッ
プが必要である。RTSIは、効率がより重要な、短いが頻
度の高いメッセージに適している。RTS/RTRは、余分の
オーバーヘッドが、比較的長いデータ転送の間に解消で
きる、比較的長いメッセージに適している。

プロセッサ・ユニット10は、米国特許出願第06/81945
8号に詳細に記載されている、仮想メモリ・データ処理
システムに全般的に対応している。上記出願に記載され
ているように、プロセッサは、32ビットの実効アドレス
をもつ。この実効アドレスは、４つの高位ビット31−28
を利用して16個のセグメント・レジスタのうちの１つを
選択することにより、40ビット仮想アドレスに変換され
る。各セグメント・レジスタは、4096個の固有セグメン
トのうちの１つを定義する、12ビットのセグメント・ア
ドレスを記憶する。各セグメントは、256メガバイトの
記憶域を含む。１ページが2Kバイトのデータを含む場
合、セグメントは128Kページを含む。一方、１ページが
4Kバイトのデータを含む場合、セグメントは、64Kペー
ジ、より正確には64Kの仮想アドレスをもつ。これらの
仮想アドレスを使って、現在そのセグメントに割り当て
られているデータのページを識別することができる。た
だし、本発明の通信プロトコルは、他のタイプのプロセ
ッサと共に動作するように適合させることもできること
に留意されたい。

第５図で、各プロセッサ10に関連するソフトウェア資
源は、オペレーティング・システム29中の複数のオペレ
ーティング・システム・サービス28の頂部に構築された
複数のアプリケーション・ソフトウェア26を含むことが
できる。これらのシステム・サービス28には、ユニット
10のハードウェア資源を割り当てる様々な資源マネージ
ャ30、ファイル・アクセルなどのサービスに対するアプ
リケーション・ソフトウェア26の要求にサービスするシ
ステム・コール32、及び入出力事象の完了など非同期事
象に反応する割込みハンドラ34が含まれる。資源マネー
ジャ30には、ロック・マネージャまたは仮想メモリ・マ
ネージャ31が含まれる。

こうした基本的システム・サービス28は、オペレーテ
ィング・システム29のカーネルの一部として一般に記載
されている。カーネルは、通常、それなしではオペレー
ティング・システムが利用できない、またはすべてのユ
ーザまたはシステム状態に影響を及ぼし、したがって特
権を与えられている、オペレーティング・システム29の
基本機能だけを含む。したがって、カーネルは信頼でき
るものでなければならず、カーネルへのアクセスは制御
されなければならない。コンパイラやユーティリティな
ど他のオペレーティング・システムは、そのサービスを
実行するのに特権が必要でない。したがって、それらは
カーネルの一部ではない。

第５図により詳しく示した共有仮想記憶多重プロセッ
サ・システムでは、ユニット10Aと10Bの様々な構成要素
は、ユニット10AのVMM31Aなど、各ユニットの名称に関
連する文字を使って区別してある。

ユニット10A上のアプリケーション・プログラム26Aな
どのクライエント・プログラムは、メモリからデータを
要求することができる。要求されたデータがユニット10
Aの主メモリ18AにはないとSCU19Aが決定した場合、ペー
ジ不在が発生し、SCU19Aは、仮想メモリ・マネージャ31
A内のページ不在処理機構に、ユニット10Aに関連するデ
ィスク・ドライブ24、、またはその主メモリ18、または
そのユニット10に関連するディスク24に記憶されたデー
タをもつ他のユニット10からデータを見つけさせ検索さ
せる。仮想メモリ・マネージャ31Aは、米国特許出願第0
7/127000号に記載されている方式でこのメモリを見つけ
る。

ユニット10Aの仮想メモリ・マネージャ31Aは、他のユ
ニット10の仮想メモリ・マネージャ31との通信を確立し
て、SNAやローカル・エリア・ネットワーク・プロトコ
ルなど高レベル通信プロトコルを使用して要求されたデ
ータを獲得することができるが、共有仮想記憶装置を利
用する多重プロセッサ・クラスタ型データ処理システム
を支援するのに大量のカーネル対カーネル・トラフィッ
クが必要だとすると、こうした高レベル通信プロトコル
の使用は複雑で遅すぎる。

本発明のシステム（第５図）では、各ユニット10のオ
ペレーティング・システム29は、新規なマシン間通信ソ
フトウェア・システム（“IMCS"）36を含む。IMCS36
は、仮想メモリ・マネージャ31などプロセッサ・ユニッ
ト10中のオペレーティング・システム29のカーネル構成
要素がそれを使用して、通信ドライバ38とSLA15を介し
直列リンク13を介してVMM31Bなど他のプロセッサ・ユニ
ット10Bの受信側構成要素により迅速にデータを送信し
またはそこから検索することができる。IMCS36の主な用
途は、クラスタ型データ処理システムの１つのユニット
10のオペレーティング・システム29のカーネル構成要素
が、そのクラスタ内の他のユニット10のオペレーティン
グ・システム29のカーネル構成要素との間でメッセージ
を送受することであるが、クラスタ内の他のシステム構
成要素は、IMCSのサービスへのトラステッド・インター
フェースをもつ場合、IMCSを使用してメッセージを送受
できることに留意されたい。

代表的なタイプのクラスタ間通信用のIMCSの実施に必
要なステップを、第8A図、第8B図、第8C図に示し、IMCS
と他のプロセッサ構成要素の関係を第7A図と第7B図に示
す。ステップ50（第８図）で、ユニット10A内のアプリ
ケーション26Aがメモリからのデータとページ不在を要
求し、または他のサービスを要求する。ステップ52で、
VMM31Aのページ不在ハンドラは、データがそのプロセッ
サ10Aに利用できず他のプロセッサ10Bによって制御され
ると決定する。ステップ54で、ページ不在ハンドラは、
IMCSのクライエント39になり、IMCS36Aが送信するメッ
セージを作成する。このIMCSメッセージは、クライエン
ト39、すなわちページ不在ハンドラからユニット10Bま
たはサーバ42の仮想メモリ・マネージャ31Bへのメッセ
ージと、ユニット10A内のクライエント39が要求したサ
ービスを実行するためにプロセッサ10B内のサーバ42が
必要とする、メッセージ及び関連するデータの転送を実
行するためにIMCS36Aが必要とする情報とを含む、標準
形式で作成しなければならない。このメッセージの書式
を、第6A図に示し、後で詳しく説明する。

メッセージがクライエントによって作成されると、ス
テップ56で、クライエント39はIMCS36Aを呼び出す。ス
テップ58で、IMCS36Aはメッセージの伝送経路を選択
し、選択された通信チャネルに対するプログラム命令を
準備する。ステップ60で、IMCS36Aは、後で詳しく説明
するように、同じサーバ42向けの前のメッセージの状況
に応じて、メッセージを選択された直列通信リンクの通
信チャネル・ドライバ38向けの待ち行列に入れるか、そ
れともメッセージを後の送信のための待ち行列に入れる
かを決定する。メッセージがドライバ38向けの待ち行列
に入れられた場合、ステップ64で、ドライバ38は、「直
接要求送信（RTSI）」直列リンク・レベル・プロトコル
を用いて、通信ポート20E、直列リンク・アダプタ（SL
A）15Bを介し直列リンク13を介して受信側プロセッサ・
ユニット10Bにメッセージを出力する。

RTSIリンク・レベルのプロトコルには、正確なデータ
転送が起こったとき、SLA15が自動的に生成できるACKが
含まれる。IMCS36BはSLA15Bに、ACKを自動的に生成しな
いように指令する。その代わりに、ユニット10B内のIMC
S36Bは、サーバ42で受信側プロセッサ10B内のバッファ
空間が利用可能かどうかの決定に基づいて、ACKまたはN
AKを生成し、それがSLA15Bによってリンク12を介して伝
送される。

IMCSは、単一メッセージで制御情報と関連データの両
方を転送させることができる。これは、「帯域内」信号
伝達技術であり、受信側プロセッサ10Bは制御情報とデ
ータを区別する必要がある。こうした制御情報には、た
とえば実行すべき動作を記述し、読み取るべきまたは書
込むべきデータを指すポインタを含む、ディスク読取り
要求、ディスク書込み要求または他の「要求」が含まれ
る。

ステップ68で、送信されたメッセージを受信側SLA15B
が受け取る。SLA15Bは、メッセージをバッファ40Bに配
送する。バッファ40Bは、受信側ユニットの様々なカー
ネル構成要素によって以前に受信側ユニット10BのIMCS3
6Bに割り当てられた、共通バッファ空間のプールを含ん
でいる。

メッセージが到着すると、ヘッダはバッファ40Bのカ
ーネル・データ・セグメント41Bの256バイトの区域を占
め、データは、SLA15Bに属するメモリのフレーム43Bを
占める。SLA15の分散／収集機能を使って、受信側プロ
セッサ10内でヘッダとデータが物理的に分割される。す
なわち、おそらくはページを構成するデータが、ページ
位置合せされる。

ステップ70で、SLA15Bはプロセッサ10Bへの割込みを
生成する。この割込みは通常通りプロセッサ10Bによっ
て処理される。ステップ72で、SLA15B用の第２レベル割
込みハンドラ（SLIH）が、IMCS36Bを呼び出す。

VMM31Bなどのサーバ42が、IMCS36Bにその存在知らせ
てからでないとメッセージは配送できない。各プロセッ
サ・ユニット10内のIMCS36は、サーバ表を維持する。サ
ーバ表は、各サーバごとに、そのヘッダ及びデータ・バ
ッファ・アカウント、メッセージが到着するときに呼び
出されるルーチンのアドレス、及びメッセージを取り出
すクライエントの範疇についての情報を含んでいる。各
ユニット内のIMCSはクラスタ・メンバのリストも維持す
る。

ステップ74で、IMCS36Bは、以前にバッファ40Bに記憶
されたメッセージのヘッダを読み取って、受信側プロセ
ッサ10B内のサーバ42の識別を決定し、そのサーバ表項
目及びクラスタ・メンバ・リストを検査して、送信側プ
ロセッサ10Aが受信側プロセッサ10B内のサーバにメッセ
ージを送信することを許されているかどうかを決定す
る。送信側プロセッサ10Aが許可を持っていない場合、
ステップ76で、IMCS36Bは、送信側プロセッサ10AにNAK
を送るようSLA15Bに指示する。許可がある場合、ステッ
プ78で、IMCS36Bは、サーバ42がそのメッセージを受け
入れるのに十分なバッファ記憶域をもつかどうか決定す
る。十分な記憶域がない場合、ステップ76で、IMCS36B
は、否定応答“NAK"を送るようSLA15Bに指示する。サー
バ42がIMCSに割り当てられた十分なバッファ空間をもつ
場合、ステップ82で、IMCS36Bは指定されたサーバのバ
ッファ「アカウント」を減分する。ステップ84で、IMCS
36Bは、送信側プロセッサ・ユニット10AにACKを送るよ
うSLA15Bに指示する。

バッファ空間がないため、または許可がないために、
受信側プロセッサ内のIMCS36が、NAKを送るようSLA15に
指示する場合、受信側プロセッサ内のバッファ空間40B
に記憶されたメッセージは捨てられる。

ステップ86で、IMCS36Bは、サーバ表で指定されたSLI
H拡張部分44と呼ばれる、特定のサーバ42のためのルー
チンを呼び出す。要約すると、SLIH拡張部分44は、IMCS
36Bのために予約されたバッファ空間40B中で受信したメ
ッセージの予備処理を実行する、サーバ42によって提供
される特殊ルーチンである。この予備処理は、後で詳し
く説明するように、メッセージの存在及び位置をサーバ
42に知らせるためのものである。

ステップ88で、プロセッサ10Bから送信されたACKが、
プロセッサ10AのSLA15Aで受信される。ステップ90で、S
LA15Aはプロセッサ・ユニット10Aに割り込む。

ステップ92で、SLA15A用の割込みハンドラがIMCS36A
を呼び出す。ステップ94で、IMCS36Aが送信されたメッ
セージ中で指定された通知ルーチン46を呼び出す。通知
ルーチン46は、IMCSを使ってメッセージを送る各クライ
エントから提供され、そのアドレスが各メッセージ中で
指定される。各通知ルーチンは、必要なクライエント特
有の処理、たとえば、ヘッダが占める空間の戻しや、以
前に送信されたデータ・ページのピン解除を実行する。

ステップ74（第7B図も参照）に戻ると、受信側プロセ
ッサ内のIMCS36Bが、送信側プロセッサ10Aはメッセージ
を受信側プロセッサ10B内のサーバ42に送ることを許さ
れていないと決定した場合、ステップ76で、IMCS36B
は、送信側プロセッサ10AにNAKを送るようにSLA15Bに指
示する。同様に、ステップ78で、IMCS36Bが、サーバ42
はメッセージを受け入れるのに十分なバッファをもたな
いと決定した場合、IMCS36Bは、やはりNAKを送るようSL
A15Bに指示する。

ステップ96で、第7B図に示すように、SLA15AはNAKを
受信し、プロセッサ・ユニット10Aに割り込む。ステッ
プ98で、SLA15A用の割込みハンドラがIMCS36Aを呼び出
す。ステップ100で、IMCS36Aは、メッセージのヘッダに
NAKが受信されたという指示を書き込み、後の送信のた
めにメッセージをセーブする。

ステップ60に戻って、IMCS36Aが、同じサーバ向けの
メッセージに対して以前にNAKを受信したという指示が
メッセージ・ヘッダに含まれていると決定した場合、ス
テップ62で、IMCS36Aはそのメッセージを待ち行列に入
れる。待機メッセージの向かうべきサーバ42でバッファ
が利用可能になった結果、受信側プロセッサ10A内のIMC
S36Bから非ブロック化メッセージを受信するまで、待機
メッセージは待ち行列中にある。こうしたバッファがど
のようにして利用可能になるかについては、「バッファ
・アカウント」の項で説明する。

本発明では、より高いレベルのソフトウェア、すなわ
ちIMCSが、バッファが利用可能かどうかを検査する機会
をもつまで、SLA15によるリンク・レベルACKの送信を延
期する。通信リンク12は、この検査中、使用中に保持さ
れる。ハードウェア・リンク・レベルACKの場合にはそ
うではない。しかし、「最後のメッセージを捨てなけれ
ばなりませんでした」または「最後のメッセージ用のバ
ッファがありました」というメッセージを送るためによ
り高いレベルを必要としないので、通信システム全体は
より効率的で簡単である。

Ｅ−1:メッセージ書式 送信側プロセッサ内のメッセージの書式を、第6A図に
示し、リンク12を介して送信中のメッセージの書式を第
6B図に示す。クライエント「要求」の書式は実行される
動作に特有である。具体的には、「要求」に含まれるデ
ータ・ポインタの位置と意味はクライエントとサーバし
か知らない。本発明のこの方法では、この問題は、各単
一メッセージの最初の256バイトまたはヘッダが制御情
報を含むという書式規約を採用することにより、部分的
に解決される。「ヘッダ」は通常、メッセージの最初の
128バイトにクライエント「要求ブロック」域を含む。
この要求の内容は、クライエントとサーバに対してのみ
意味をもち、したがって、IMCSにとっては意味がない。
ヘッダの次の128バイトは、IMCSと直列リンク・アダプ
タ用の制御情報を含む。ヘッダの「クライエント要求」
ブロックが128バイトより大きい場合には、クライエン
ト及びサーバは、メッセージのデータ部分にオーバフロ
ーを入れるための規約を確立しなければならない。

この解決方法の残りの部分は、クライエントがヘッド
のIMCS部分とSLA部分を作成する必要があることであ
る。ヘッダの後に、所与の送信中に4Kバイトのデータ・
ページが１ページ以上続くことがある。許容最大データ
・ページ数は15ページであるが、システムの特定の構成
または用途に応じて、異なる最大ページ数が適切なこと
もある。

メッセージ全体が１回の送信で送信されるので、デー
タ用のタグ・ワードを含めて、メッセージのすべての要
素を記述するタグ・ワードを作成し、ヘッダのSLA部分
に入れなければならない。ヘッダの諸要素は、タグ・ワ
ードが要素を記述すべく正確に作成されている限り、仮
想メモリまたはリアル・メモリ中で連続している必要は
ない。

前に説明した、メッセージの作成に関する第８図のス
テップ54で、「クライエント」は、「クライエント要
求」部分が以前に作成されていない場合、それを作成
し、ヘッダのIMCS部分は、クライエント供給の「IMCS作
成」ルーチンを使って作成される。「IMCS作成」ルーチ
ンは、「要求」ブロックのデータ構造、特にデータ・ポ
インタの所在を理解し、ヘッダ及び出力データ用のタグ
・ワード・イメージ域に記入する。クライエントはま
た、宛先、たとえば指定された受信側プロセッサ10B内
の特定のサーバ、送信されるデータ・ページ（どのペー
ジを固定しなければならないか）のリスト、及び転送完
了した時に呼び出される送信側プロセッサ10A内の通知
ルーチン46などの情報を指定する、IMCS制御域も記入す
る。このデータ構造は、（下記のような）「Ｃ」言語ま
たは他の適切な言語で書くことができる。

「要求」ブロックのデータ構造は、以下の通りであ
る。

ヘッダは（２つの非連続128バイト・チャンクから構
成でき）、カーネル・データ用に割り当てられた仮想記
憶セグメント41から割り振られる。801アドレッシング
・アーキテクチャを使用して、短い（32ビット）アドレ
スがポインタに使用できるようにするとき、ヘッダはす
べて同じセグメントになければならない。ヘッダ（及び
データ・ページ）は、IMCSが呼び出される前に固定しな
ければならない。ヘッダ中に以下のフィールドを設けな
ければならない。

imcs dest proc メッセージが送られる先のプロ
セッサ。IMCSはこの妥当性検査を行ない、経路を選択す
る。プロセッサが存在するが利用できない場合、IMCSは
メッセージを待ち行列に入れる。

imcs dest qtoken メッセージが送られる先の受信
側プロセッサにあるサーバを表す待ち行列識別。IMCSは
この妥当性検査を行なわない。

notify adoress 送信動作の完了時に割込みハンド
ラからIMCSによって呼び出されるルーチンのアドレス。
このルーチンはカーネル・テキスト・セグメント内にあ
り固定されている。

tags これらはヘッダ及び関連するデータ・ページを
表すように記入しなければならない。システム・サービ
スは仮想アドレスと長さを取り、タグ・ワードを戻す。

メッセージがクライエントによって作成されると、ク
ライエントはIMCSを呼び出す。メッセージが送信される
先のプロセッサが、IMCSが通信する相手のプロセッサ・
グループ中にない場合以外は、IMCSはメッセージを送信
する。グループ中にない場合は、IMCSは「エラー」戻り
コードを生成する。

メッセージを後の送信のために待ち行列に入れるべき
場合、IMCSはハッシュ方式を利用して、送信が実際行な
われるときに、待機メッセージが正しい順序で受信側プ
ロセッサ内の正しい待ち行列に送られるようにする。こ
の方式が必要なのは、送信側プロセッサと受信側プロセ
ッサの間で２つの物理通信リンクが利用できる場合、ま
たは受信側プロセッサが同じ待ち行列向けの前のメッセ
ージを否定応答した場合に起こる、メッセージが順序外
れで到着するのを防ぐためである。

Ｅ−２ バッファ・アカウントの処理 各プロセッサ内のIMCS36は、特定の受信側構成要素が
プロセッサ内のフレームを余りに多く多く使用しないよ
うにする、アカウント処理機構48を含む。機構48は、ヘ
ッダとデータ・ページに対して別々にアカウント処理を
行なう。

受信側プロセッサ10内のサーバは、バッファをデータ
・バッファ・プール43に寄与し、バッファ・アカウント
は、各サーバごとにアカウント処理機構48によって維持
される。特定のサーバ向けのメッセージが到着すると、
そのアカウントが適宜減分される。そのアカウントはよ
り多くのバッファを寄与することによって補充される。

そのアカウントがメッセージを受け入れるのに十分で
ないサーバ向けのメッセージが到着すると、問題が発生
するが、すべてのサーバによって与えられる空きバッフ
ァの総数は大きい。サーバの不足は一時的なので、その
サーバ向けのメッセージを拒否するよりも、そのサーバ
に大域プールからの空きバッファを「貸す」方がよい。

潜在的な各受信側サーバは、クラスタ内の他のプロセ
ッサ10からの到来メッセージ用に固定ページの「アカウ
ント」をもつ。各クラスごとにバッファ方針が異なる、
「サービス・クラス」という概念がある。あるユニット
内の各サーバは１つのクラスに属する。「厳格」クラス
では、サーバはそれらのアカウントを超過引出しできな
い。自由クラスでは、サーバは超過引出しができる（す
なわち、互いのバッファを使用できる）。自由クラス
は、すべての参加サーバの最高のニーズに必要なほど多
くないバッファ空間を維持しながら、変動を可能にす
る、ある種の大域バッファ・プールを提供する。しか
し、厳格クラスからのバッファを自由クラスが「借り
る」ことは決してできない。

アカウントに寄与するため、サーバは、特定のサーバ
待ち行列に対するバッファ・アカウントにメモリのフレ
ームを与える、IMCS中のルーチンを呼び出す。このルー
チンは、VMMの優先順位レベルで走行するVMM呼出しであ
る。VMM31によって資源制御が行なわれる場合、VMMは、
要求されたフレーム数に対する権限をサーバが与えられ
るようにする。システムがフレーム外れの場合、VMMは
エラー戻りコードを与える。非エラーの場合、VMMは空
きフレームを見つけて、これを再利用不能にし、IMCSの
ためにそのフレームを予約する。次いでVMMは、SLAの優
先順位レベルで走行するIMCSルーチンを呼び出し、SLA
バッファ・プールにそのフレームを追加し、サーバ待ち
行列のアカウントを増分する。

受信側プロセッサ10内のIMCS36は所定の待ち行列向け
にNAKを送るとき、サーバ表にそうしたという指示を保
持する。その待ち行列のサーバはある時点でバッファ・
アカウントを補充し、それが行なわれたとき、IMCS36
は、NAKを送った先のプロセッサに、送信を再開するよ
うにとのメッセージを送信する。送信側プロセッサ10に
あるIMCS36は、このメッセージを受信すると、その待ち
行列向けの最初のメッセージを通信装置ドライバ38への
待ち行列に入れ、したがってその待ち行列は有効に非ブ
ロック化される。この非ブロック化メッセージは、IMCS
間メッセージであることに留意されたい。これは到着す
るとすぐにIMCSによって処理されるので、バッファ・ア
カウントを必要としない。

このバッファ・アカウント処理方式の理由の１つは、
資源の涸渇を防ぐことである。それは、クライエントが
妥当な時間で処理できないメッセージでサーバのプロセ
ッサをあふれさせるのを防止するための機構である。

もう一つの理由は、デッドロックの回避に役立つこと
である。たとえば、プロセッサ10が自由ページ・フレー
ムも自由ヘッダももたず、したがってメッセージを受信
できないことがある。次の到来メッセージによって、プ
ロセッサ10はページ・フレームを解放することができる
が、新しいヘッドを割り振ることはできないので、この
メッセージを受信できない。このバッファ・アカウント
処理方式を用いると、特定のサーバがメッセージを受信
するのを妨げずに、仮想メモリ・マネージャ31が、IMCS
用に出力されたページ・フレームの数を制限することが
できる。サーバ待ち行列の数は基本的に制限されていな
いので、何らかの形でその到来メッセージを分離するた
め、サーバは実際には複数の待ち行列を有する。たとえ
ば、仮想メモリ・マネージャ31は、クライエントからペ
ージ・イン要求を受信するための１つの待ち行列と、そ
れ自体のページ・アウト要求に対する応答を受信するた
めの他の待ち行列を有することができる。こうしない
と、ページ・アウト応答が、ブロック化された待ち行列
中でいくつかのページ・イン要求の後に入って、前記の
種類のデッドロックを引き起こす可能性がある。

Ｅ−３ ヘッダ管理 受信側プロセッサ内のサーバがIMCS36にその存在を知
らせると、サーバはその待ち行列のに使用できるヘッダ
の数を指定する。その数はサーバがサービスする同時要
求の数の上限を表す。長いサービス待ち行列を構成する
必要はなく、それらの要求を（すでに実メモリ資源を使
用している）送信側プロセッサ中で待機させる方がよ
い。

ヘッダはIMCSによって管理される。初期設定の時に、
IMCSは、カーネル・データ空間からのページを割り振
り、それを概念上16個の256バイト・ヘッダに分解し、
ヘッダを固定する。SLA15が受信動作で使用するための
１組のタグ・ワードが作成される度に、こうしたヘッダ
の１つがそれに与えられる。メッセージが到来すると、
メッセージがアドレスされる先のサーバにそのヘッダが
与えられ、サーバのヘッダ・アカウントが減分される。
最終的に、サーバは要求を完了し、あるいは要求にサー
ビスする前に、ヘッダからその私用のデータ域に関連情
報をコピーすることができる。どちらの場合も、サーバ
はヘッダをIMCSに戻す。この時、サーバの待ち行列のヘ
ッダ・アカウントが増分され、ヘッダはIMCSのヘッダ・
プールに戻って、別の到来メッセージ中で再使用され
る。

IMCSのヘッダがなくなることがある。自由ヘッダの数
が、しきい値、たとえば４より少なくなると、IMCSは他
のページを割り振り、こうして得られたヘッダをそのヘ
ッダ・プールに追加する。ヘッダ・ページの割振りは１
回の処理で行なわれなければならない。というのはペー
ジを固定するとページ不在が起こる可能性があるからで
ある。

ヘッダ・アカウントがゼロである待ち行列向けのメッ
セージが到着すると、IMCSは「データ・バッファなし」
NAKとは区別されるNAKを送る。「ヘッダなし」NAKの場
合は、待ち行列を非ブロック化するのにIMCSメッセージ
を待つ代わりに、送信側IMCSはしばらくしてから再送信
できる。これは、ヘッダの不在が一過性の現象であるか
もしれないからである。ヘッダ及びバッファには異なる
方式も使用できるが、必ずしもそうする必要はない。

Ｅ−４ 待ち行列トークン管理 上述のように、クライエントによってそのサービスが
要求されているサーバ42は、メッセージ・ヘッダ中で待
ち行列トークンによって識別される。こうしたトークン
を指定する方法には様々なものがある。たとえば、VMM
などのシステム・サービスは、すべてのプロセッサで同
じ「周知の」トークン値をもつ。他の値はIMCSによって
指定されて、サーバとクライエントの間でそれ自体の機
構によって通信される。ただし、それらの機構は本発明
の一部ではない。

Ｅ−５ SLIH拡張部分 IMCSはメッセージ・ヘッダのdest qtokenフィールド
からサーバを識別し、割込みハンドラ環境でサーバのSL
IH拡張部分44を呼び出す。メッセージの存在と位置をそ
のサーバに通信することが、SLIH拡張部分44の役割であ
る。SLIH拡張部分44は、サーバの内部状態とそのデータ
構造にアクセスすることができ、到来メッセージをどこ
かで待ち行列に入れるかどうか、処理を通知する必要が
あるかどうかなどを知る。

たとえば、要求がページ・イン要求である場合、すな
わち、サーバからクライエントにページを送る要求であ
る場合、SLIH拡張部分44は、要求されたページがメモリ
内にあるかどうかを調べる。メモリ中にある場合、その
送出応答メッセージ用に到来メッセージの物理空間を使
って、ただちに要求にサービスすることができる。その
ページがメモリにない場合、そのページを他のシステム
またはディスクから取り出さなければならないが、どち
らの動作も遅い。したがって、SLIH拡張部分は後の処理
のためにサービスのスケジューリングを行なうことにな
る。

Ｅ−６ 中間ノード経路設定 スイッチ11を備えたクラスタ構成では、スイッチ11に
接続された任意の２つのプロセッサ10、たとえば10Aと1
0Dが、互いに直接接続できる。スイッチ11がない場合、
またはプロセッサ10がスイッチ11に接続されていない場
合は、第３図に示すように、２つのプロセッサ10Aと10D
が、１つまたは複数の中間プロセッサ10Bを介して互い
に通信することが必要になることがある。これは、中間
ノード経路設定（INR）と呼ばれる。

通信の基本的な問題は、受信側プロセッサ10Dが到来
メッセージを収容するのに十分なバッファ空間をもつか
どうかである。中間ノード経路設定の場合、中間プロセ
ッサ10Bはバッファ空間をもつが、宛先プロセッサ10Dは
もたないことがあり、その逆の場合もある。

プロセッサ10Aと10Dが直接接続されている場合、ACK
とNAKを使って、バッファが利用可能かどうか通知す
る。これは、INRの場合には不可能である。というの
は、ACKとNAKは中間プロセッサ内のバッファが利用可能
かどうかを通知することになるからである。

中間プロセッサ10Bは、それがバッファ空間をもつと
送信側プロセッサ10Aに伝える場合、宛先プロセッサ10D
が空間を持たないことがわかると、メッセージをそれ自
体のバッファに保持せざるを得なくなり、バッファ空間
及び管理の点でかなりの負担が生じる。

この問題を解決するために２つの代替解決方法が開発
された。どちらの解決方法も、通常の場合（非INR）がI
NRの場合の解決方法によって損なわれるべきでないこと
を認識したものである。

１つの代替解決法では、直列リンク12を利用して、中
間プロセッサ10Bを介して接続を行なう。具体的には、
メッセージが、他のプロセッサ10Dに向かう中間プロセ
ッサ10Bに到達すると、到来直列リンク12は、そのメッ
セージが別の直列リンク12を介してプロセッサ10Dに配
送されるまで、接続されたままに保持される。次に、プ
ロセッサ10Dは、適宜ACKまたはNAKをリンク12を介して
プロセッサ10Bに送り、プロセッサ10BはこのNAKまたはA
CKをリンク12を介してプロセッサ10Aに転送する。

さらに具体的には、中間プロセッサ10Bが、（それ自
体のバッファ中でのメッセージを受信したことを意味す
る）ソフトウェアACKを送る前に、プロセッサ10Bはその
メッセージを宛先プロセッサ10Dに転送しようとする。
宛先プロセッサ10Dは、バッファ空間を持たない場合、N
AKをプロセッサ10Bに送る。したがって、中間プロセッ
サ10Bはそのメッセージを捨て、NAKを発信元プロセッサ
10Aに送る。

宛先プロセッサ10DがACKを送る場合、中間プロセッサ
10Bはそのメッセージを捨て、ACKを発信元プロセッサ10
Aに送る。どちらの場合も、中間プロセッサ10Bのバッフ
ァは解放されて、他のメッセージを受け入れることがで
きるようになる。

この設計では、宛先プロセッサ10Dが応答するまで、
通信プロセッサ10Aと10Bの間の通信媒体が使用中に保た
れる。しかし、これは、代わりにより複雑なソフトウェ
アを使用するか、それとも中間プロセッサ内により多く
のバッファ空間を設けるかを考えると、妥当なトレード
オフである。この設計を拡張して複数の中間プロセッサ
を設けることができることに留意されたい。

別法として、IMCS間接続サービスを通常のIMCSの上端
に構築することもできる。そうすると、ACKとNAKが、ク
ライエントとサーバとの間の実メッセージであるかのよ
うに、この接続を介してメッセージとして送られる。こ
の実施例は、前の実施例より開発コストが高い。

直接接続した場合、IMCSが呼び出されて、メッセージ
を受信側プロセッサのサービス待ち行列（宛先サービス
待ち行列）に送る。INRの場合は、IMCSが呼び出され、
メッセージをローカルIMCS接続サービスの待ち行列に入
れる。この接続は、宛先プロセッサ上の相手方の接続と
（中間プロセッサを介して）セッションを行なう。

メッセージは、中間プロセッサを介して宛先プロセッ
サのIMCS接続サービスに渡される。IMCS接続サービス
は、それを宛先サービス待ち行列に渡す。これは、バッ
ファの欠如によりうまくいかないことがある。宛先プロ
セッサのIMCS接続サービスは、発信元プロセッサのIMCS
接続サービスに成否を示すメッセージを送る。

発信元プロセッサのIMCS接続サービスは、宛先IMCS接
続サービスからACKを受信するまで、後続のメッセージ
を宛先プロセッサ中の同じ待ち行列（「宛先待ち行
列」）には送らない。そのIMCS接続サービスがNAKを受
信した場合、後続の非ブロック化メッセージを待ってか
らその宛先待ち行列に送信する。

メッセージは接続サービス間を通過しなければならな
いので、プロセッサはそれらのメッセージ用の空間を予
約しなければならないが、こうしたメッセージは一時に
１つだけ流れる。さらに、受信側IMCS接続サービスに、
到来メッセージを宛先待ち行列に渡す前に保持するため
の一時的バッファが必要である。しかし、中間プロセッ
サでバッファ空間が必要なのは、ある直列リンクからメ
ッセージを受信してからそれを別のリンクに送出するま
での間だけである。

この機構は、所与の宛先待ち行列向けのメッセージが
一時に１つだけ飛行できるようにすることに留意された
い。IMCS接続サービスが、順序番号、待ち行列ごとに別
々の順序を与える場合には、この機構が改良できる。こ
の場合、NAKは、受信時に特定のメッセージを指定す
る。送信側プロセッサのIMCS接続サービスは、飛行中の
複数の未処理メッセージをもつことがある。すなわち、
そのIMCS接続サービスは、待ち行列が非ブロック化され
るときどこから再開すべきかを知っている。受信側プロ
セッサの接続サービスは、それが否定応答したメッセー
ジより順序番号が大きなメッセージを捨てる。その後、
その待ち行列が非ブロック化されるとき、それらのメッ
セージが送信側プロセッサから再送信される。

【図面の簡単な説明】

第１図は、本発明の通信プロトコルが有利に利用され
る、高速スイッチを介してクラスタ構成で相互接続され
た複数のプロセッサ・ユニットの機能構成図である。 第２図は、１つのプロセッサがクラスタ構成中の他のど
のプロセッサともに直接通信するという、通信リンクに
よって互いに接続された複数のプロセッサ・ユニットの
代替構成の機能構成図である。 第３図は、あるプロセッサが中間プロセッサを介して非
隣接プロセッサに通信するという、クラスタ構成で相互
接続された複数のプロセッサ・ユニットの代替構成の機
能構成図である。 第４図は、ユニットの１つに統合された様々なハードウ
ェア機能を示す、第１図、第２図、及び第３図に示した
プロセッサ・ユニットの構成図である。 第５図は、各ユニットに組み込まれた様々なソフトウェ
ア機能とそれらの間でメッセージを送信するための通信
リンクを示す、第１図に示したプロセッサ・ユニットの
うちの２つの構成図である。 第6A図は、本発明の通信プロトコルに従って送信側プロ
セッサに記憶されるメッセージのヘッダ及び別になった
データ部分のデータ構造を示す図である。 第6B図は、通信リンクを介して送信されるメッセージの
データ構造を示す図である。 第7A図と第7B図は、遠隔ユニットの構成要素間でメッセ
ージを送信する際の通信プロトコルの諸ステップを示す
図である。 第8A図、第8B図及び第8C図は、本発明の通信プロトコル
を使用する際にプロセッサによって実行される諸ステッ
プを記述する流れ図である。

───────────────────────────────────────────────────── フロントページの続き (72)発明者 カタリン・アナ・ベロニカ・ラダー アメリカ合衆国テキサス州オウスチン、 スモーキイー・ヴアレイ4903ビイー番地 (72)発明者 ロバート・ケント・ラダー アメリカ合衆国テキサス州オウスチン、 スモーキイー・ヴアレイ4903ビイー番地 (72)発明者 アモール・アーメツド・シヤーン‐ゴー ダ アメリカ合衆国テキサス州オウスチン、 スイートシヤドウ・レーン11502番地 (56)参考文献 特開 昭59−176952（ＪＰ，Ａ)

Claims (2)

(57)【特許請求の範囲】
1. 【請求項１】受信側プロセッサの受信側構成要素宛ての
   メッセージを、送信側プロセッサの構成要素から受信側
   プロセッサに送信する手段、 前記メッセージが受信側プロセッサで受信されたとき、
   前記の宛先の受信側構成要素が前記メッセージ用に利用
   可能なバッファ空間をもつかどうかを動的に決定する手
   段、 前記メッセージが受信側プロセッサで受信され、宛先の
   受信側構成要素でメッセージを記憶するのに十分なバッ
   ファ空間が利用可能であることを示す肯定応答、または
   十分なバッファ空間がないことを示す否定応答を前記送
   信側プロセッサに送付する手段、及び メッセージを受信するのに十分なバッファ空間が受信側
   構成要素で利用可能であることを送信側プロセッサに通
   知する手段 を含む、ネットワークに接続された複数のプロセッサ間
   で通信するためのシステム。
2. 【請求項２】ネットワークに接続された複数の処理シス
   テム内の複数の構成要素間で通信するためのシステムで
   あって、 前記構成要素のそれぞれにバッファ空間を割り振る手
   段、 前記構成要素の組を複数のクラス・タイプの１つに分類
   し、該分類されたクラス・タイプによって前記割り振ら
   れたバッファ空間をプールするバッファ・プール手段、 受信側プロセッサの受信側構成要素宛てのメッセージ
   を、送信側プロセッサの構成要素から受信側プロセッサ
   に送信する手段、 前記メッセージが受信側プロセッサで受信されたとき、
   前記宛先の受信側構成要素が前記メッセージ用に利用で
   きるバッファ空間をもつかどうかを動的に決定する手
   段、及び バッファ空間が前記宛先の受信側構成要素用に利用でき
   ない場合、前記宛先の受信側受信側構成要素の前記クラ
   ス・タイプの前記バッファ・プール手段から、新たなバ
   ッファ空間を前記送信されたメッセージ用に割り振る手
   段 を含む前記システム。