JPH0525333B2 - - Google Patents

Description

【発明の詳細な説明】

以下の順序で本発明を説明する。 Ａ 産業上の利用分野 Ｂ 従来技術 Ｃ 発明が解決しようとする問題点 Ｄ 問題点を解決するための手段 Ｅ 実施例 Ｆ 発明の効果 Ａ 産業上の利用分野 本発明は、データ処理ネツトワーク中の異なる
ノードに位置するプロセスの間の通信に関するも
のである。その各ノードは、独立の動作をなし得
るプロセツサを有し、また端末装置、メモリ及び
Ｉ／Ｏ装置などの他のサービスを備えていてもよ
い。さらに、各プロセツサは多重処理、多重タス
ク能力を有していてもよい。より詳しく述べる
と、本発明は、プログラムが通信待ち行列のノー
ドを知ることを不要ならしめることによつてネツ
トワーク中の同一または異なるノードにある処理
装置間の、待ち行列に基づく通信を容易にするこ
とにある。本発明に係る記述においては、プロセ
ス間通信（IPC）待ち行列位置透過伝達機構が、
分散サービス環境中で実施されるものとして説明
される。 Ｂ 従来技術 M.J.Bach著、The Design of the UNIX
Operating System（UNIXは米国におけるAT＆
Ｔベル研究所の商標）、Prentice−Hall 1986の
356〜367ページには、システム在駐カーネル中で
メツセージ待ち行列のアレイを呼び出すキーによ
つてメツセージ取得（MSGGET）システム・コ
ールを呼び出し、その特定のキーに対応する一致
エントリが見出されない場合に、新しい待ち行列
構造を割振るとともにユーザにその識別子を戻す
ことによつて、プロセス間通信（IPC）が行なわ
れることが開示されている。そして、メツセージ
を送り受け取るためのシステム・コール
MSGSND及びMSGRCVに関連するアルゴリズ
ムが開示されている。しかし、その文献には、ネ
ツトワークの異なるノードに位置する処理装置間
のプロセス間通信を容易ならしめることの記述も
示唆もない。 IBM RT Personal Computer Technology
（型式番号SA23−1057）にはIBM RT（RTは米
国におけるIBM社の商標である）パーソナル・
コンピユータが記述されている。それには拡張対
話型実行（Advanced Interactive Executive：
AIX（AIXは米国におけるIBM社の商標である））
オペレーテイング・システムが、AT＆Ｔの
UNIXシステムＶの概念の拡張であるとして開示
されている。 このAIXカーネルは、アプリケーシヨン・プ
ログラム及びコマンドのためのオペレーテイング
環境を与える。尚、AIXのより詳しい説明につ
いては、AIX Operating System Technical
Reference（型式番号SV21−8009）を参照された
い。この技術は、複数のIBM RT PCシステム
が通信ネツトワークのノードとなることを可能な
らしめ、且ついくつかの追加的な特徴を与えるよ
うに拡張されたものである。 そのような特徴の１つとしてネツトワークに亘
る分散処理がある。そのような分散サービス環境
は、通信リンクまたはネツトワークによつて接続
された２またはそれ以上のノードを有する。ネツ
トワークは、ローカル・エリア・ネツトワーク
（LAN）、または他のノードまたは他のネツトワ
ークに対する遠隔処理接続を有する広域（wide
area）ネツトワーク（WAN）のどちらかでよ
い。分散サービスの主要な目的は、AIXオペレ
ーテイング・システムのフアイル・システム及び
プロセス間通信（IPC）サービスを用いるアプリ
ケーシヨンのために構内／遠隔透過伝達機構を与
えることにある。 Ｃ 発明が解決しようとする問題点 本発明の目的は、ノード位置透過伝達機構と、
待ち行列の名前を衝突させる割当てを防止するた
めの手段と、１つの待ち行列上で所与のサービス
供給者から複数の顧客へメツセージを切換える
（demultiplexing）ことを可能ならしめる手段を
もつ効率的なメツセージ待ち行列処理システムを
提供することにある。 Ｄ 問題点を解決するための手段 本発明は、通信リンクを介して接続された少く
とも２つのシステムを含むネツトワーク中の異な
るノードにあるプロセス間の通信を容易ならしめ
るものである。その各ノードは、多重処理及び多
重タスク動作をなしうるプロセツサを有する。
尚、前述のように、各ノード・プロセツサは独立
（standalone）モードでも同様に動作し得るもの
でもよい。 異なるノードに位置づけられたプロセスは、そ
の実際のノード位置が、通信を開始するプログラ
ムにとつて未知であるようなIPC待ち行列を使用
する他のプロセスと通信可能であるようになされ
ている。本発明は、AIX IPCメツセージ機構を、
異なるノードにおける待ち行列間で送受信をなし
得るように拡張することにより、同一のAIXシ
ステム中のプロセス間の通信のためのAIX IPC
メツセージ待ち行列機構よりも進歩している。
AIXは、メツセージ取得（msgget）、メツセージ
送信（msgsnd）及びメツセージ受信（msgrcv）
システム・コールを使用してIPCをサポートす
る。メツセージ取得は、メツセージ待ち行列を見
出しあるいは作成し、その識別子MSQIDを戻す
ために使用される。そしてそれ以降のメツセージ
送信及びメツセージ受信コールは、ターゲツト待
ち行列を識別するためにこのMSQIDを使用す
る。 本発明は、入力キーを特定の待ち行列の実際の
キーとノード位置と相関させるための予定のカー
ネル在駐テーブル中のルツク・アツプ機能に対す
る引数として特定の待ち行列のキーを使用するよ
うにするために、AIX msgget システム・コー
ルに対して修正を加えることから進む。メツセー
ジを配置すべき待ち行列のノード位置及びキー
は、通信しているプロセスに透過的である。 待ち行列が遠隔ノードにあるとき、２つのノー
ドは、待ち行列要素情報を渡すために、それらの
間に確立された通信リンクを使用する。本発明の
好適な実施例は、IBMシステム・ネツトワー
ク・アーキテクチヤ（SNA）レベル6.2の拡張プ
ログラム間通信を利用する。 IPCメツセージ待ち行列は、その待ち行列が作
成されたときに割振られたキー、すなわち数値に
よつて識別される。特定の待ち行列にアクセスを
所望する任意のプロセスは、参照が、実際の待ち
行列識別子に対して確定的（resolved）であり得
るような方法でキーを参照しなくてはならない。 後で述べるように、本発明に係る方法の好適な
実施例は、分散サービス機能が設けられているオ
ペレーテイング・システム・レベルで実施され
る。本発明は、ネツトワーク中の各システム・ノ
ードがキーのための自己のIPC待ち行列プロフア
イル名称空間をもつべきことを要求する。そし
て、アプリケーシヨンのコールからノード固有キ
ーが、ノード固有キーを、呼出し手によつて与え
られた待ち行列名に関連づけるライブラリ・ルー
チンに戻される。 本発明はまた、各システムのカーネルに在駐す
るキー・マツピング・テーブル（KMT）をも必
要とする。キー・マツピング・テーブル中の各エ
ントリは、特定の待ち行列を照会する局所キー
と、その待ち行列が実際に駐在するノードと、そ
の待ち行列が実際に駐在するノードで使用される
キーを含む。KMTはシステムのスタート・アツ
プ時に各ノードのカーネルにロードされる。 KTMデータは、ネツトワークを監視するネツ
トワーク管理者によつて保守される。そして、
KMTに対する変更は必要に応じてネツトワーク
管理者によつてなされる。この管理オペレータの
関与するのは、アプリケーシヨン・インターフエ
ースでメツセージ待ち行列の透過性を許容するこ
とである。 前述のM.J.Bachの書物に記述されているよう
な従来技術においては、プロセスはメツセージ待
ち行列を利用してメツセージを送受することによ
つて通信する。その呼プロセスは、受信するプロ
セスがメツセージを見出すことを期待する待ち行
列を識別しなくてはならない。単独
（standalone）多重処理システムにおいては、す
べての待ち行列の位置が既知である。しかし、分
散サービスをもつネツトワーク環境においては、
プロセスが、同一または異なるノードにあるメツ
セージ待ち行列を介して他のノードにあるプロセ
スと通信するこが望ましい。このとき、各プロセ
スがネツトワーク中のすべてのメツセージ待ち行
列の位置情報を暗黙的に知つていることが必要と
されるのであれば、そのことは許容し得ないであ
ろう。すなわち、もしこれが要求されるなら、各
呼プロセスは、実際のメツセージ待ち行列位置が
変わるたび毎にその変更を知る必要があることに
なるからである。 本発明はこの問題を、プロセツサ・ノードの待
ち行列キーを、メツセージ待ち行列の実際のキー
及びノードと相関させるカーネル在駐テーブルを
設けることによつて解決する。これらのテーブル
は、ネツトワーク管理者によつて、メツセージ待
ち行列の実際のノード位置における変更を反映す
るように変更することができる。しかし、呼プロ
セスによつて供給される入力パラメータは変わら
ない。それゆえ、メツセージ待ち行列の実際のノ
ード位置はアプリケーシヨン・プログラム・イン
ターフエースで透過性である。 メツセージ待ち行列の実際の識別子に対するア
ドレス確定（resolution）がカーネル・レベルで
生じる。KMTは入力としてキーを受け取り、所
望の待ち行列のキーとノードIDを与える。各ノ
ードのカーネルをそのように相関させたことによ
り、システム・コール・ルーチンは通信を開始し
たプロセスによつて与えられるキーを受け取り、
それに対応するキーとノードへ進む。このとき、
もしその識別子をもつメツセージ待ち行列がその
ノードの待ち行列ヘツダ・テーブル中で見出され
なかつたら、新しいメツセージ待ち行列が作成さ
れ、もし呼出し者（caller）が、待ち行列が作成
されるべきことを要求したなら、そのメツセージ
待ち行列の識別子が呼出しノードのカーネルに戻
される。呼出しノードのカーネルにおいて、実際
のノード位置とメツセージ待ち行列識別子を含む
新しい代理（surrogate）待ち行列ヘツダ・エン
トリが構成される。次にアプリケーシヨンは、自
己のメツセージを、意図するメツセージ待ち行列
に配置することが可能となる。 Ｅ 実施例 第１図は、本発明が実施されるネツトワークを
示す概要図である。ネツトワーク１０は、通信リ
ンク３０を介して接続された複数のノードＡ，Ｂ
及びＣを有するものとして示されている。各ノー
ドＡ，Ｂ，Ｃはそれぞれが、単独システムまたは
ネツトワーク１０の一部として作動し得る多重タ
スク、多重処理能力をもつ少くとも１つのプロセ
ツサ４０を含む。尚、第１図において参照番号４
０は各ノードＡ，Ｂ，Ｃでそれぞれ４０Ａ，４０
Ｂ，４０Ｃとして示され、これは参照番号４２以
下についても同様である。図示されているよう
に、通信ネツトワーク３０はローカル・エリア・
ネツトワーク（LAN）または広域ネツトワーク
（WAN）のどちらでもよいが、好適な実施例は
ノードＡ，Ｂ及びＣの間で通信リンクを確立する
ためのIBMシステム・ネツトワーク・アーキテ
クチヤ（SNA）を利用する。各ノードは、ユー
ザ・アプリケーシヨン４２が走ることになる少く
とも１つのプロセツサ４０を有する。プロセツサ
４０の内部には、好適にはIBMのAIXであるオ
ペレーテイング・システム（O.S.）４６の制御の
下にあるプロセス４４がある。 各プロセツサ４０には、番号48として示されて
いるさまざまな記憶媒体が接続されている。尚、
図示されていないけれどもネツトワーク構成１０
によつて意図されているものとして、ネツトワー
ク中の各プロセツサに接続可能な他のさまざまな
端末、記憶及び周辺Ｉ／Ｏ装置がある。各プロセ
ツサ４０のオペレーテイング・システム４６の内
部にはカーネル５０がある。 各独立ノードＡ，Ｂ，Ｃは、所与のタスクを実
行するために、互いのノードで利用可能な資源を
共有するために互いに協働することができる。そ
のような分散サービス環境においては、本発明に
よつて与えられるメツセージ待ち行列位置の透過
性を通じて処理する効率的なメツセージの能力を
利用するためにユーザはわずかの対話しか必要と
しない。また資源を共有することにより、ネツト
ワーク中の各ノードで情報を複写する必要性が減
少される。 通信待ち行列のノード位置がユーザ・プログラ
ムに対して透過的であるがゆえに、プロセス間の
通信はより効率的になり、ユーザが通信の詳細に
払うべき注意はより少なくなる。尚、所与の待ち
行列の実際のノード位置は変わり得るけれども、
所与のノードのユーザは、待ち行列の位置を追従
する責任から開放される。ネツトワーク管理者の
１つの任務は、待ち行列のキーと位置を相関させ
るプロフイールの最新のセツトを維持すること
と、適当な相関情報をネツトワークにおける各ノ
ードのカーネル５０中のKMTにロードすること
である。 ネツトワーク構成１０中の各プロセツサ・ノー
ドのオペレーテイング・システム４６には、予定
の待ち行列に必要な情報を維持するデイレクト
リ・サービス機能が含まれている。これらの機能
には、IPCキーの作成、キー位置の定義、特定の
メツセージ待ち行列のためのキーに対する外部
IPC待ち行列名の決定、及びメツセージが到来す
るノードからのネツトワーク位置及び遠隔待ち行
列の戻しがある。 待ち行列プロフアイル・レコードのフオーマツ
トが第１図の参照番号５２で示されており、アプ
リケーシヨンの導入プログラムによつてコールさ
れるライブラリ・ルーチン作成IPC−PROFの実
行の結果として作成される。このプログラムは、
長さ14キヤラクタまでの待ち行列名（QNAME）
を供給し、ライブラリ・ルーチンがプロフアイ
ル・レコードを作成し、そのノードに固有の数字
INKEY値を割当てる。システムのスタート・ア
ツプ時に、システムはプロフアイルを読み、第２
図に示すようなエントリをもつKMTを作成す
る。 KMTは、ライブラリ・ルーチンによつて割当
てられる局所キー（LKEY）と、実際のキー
（RKEY）と、LKEYによつて指定される待ち行
列のためのノード（RNODE）を含む。 第３図は、待ち行列ヘツダ・レコードのフオー
マツトを示す。スタート・アツプ時にサーバー・
プロセスがIPC PROFを見出すために待ち行列
名を入力し、その待ち行列に関連するキーを受け
取る。サーバー・プロセスは次にキーを与えるシ
ステム・コール、msggetを発行し、msggetが待
ち行列を作成する。 第３図中の待ち行列ヘツダ・レコードは、特定
の待ち行列が、待ち行列ヘツダ・テーブルが在駐
するノードに対して局所的(L)であるか、あるいは
遠隔(R)に位置しているかを示す表示子を含む。待
ち行列ヘツダ・テーブル・エントリの残りのフオ
ーマツトは局所／遠隔表示子の関数である。すな
わち、もし待ち行列が局所的であるなら、LKEY
が局所待ち行列エントリを含み、LMTYPEはそ
の待ち行列のために最も新しく使用されたメツセ
ージ・タイプの表示子の値である。 遠隔待ち行列の場合、RNODEがそのノードID
を含み、RMODE MSQIDが遠隔ノードにおける
メツセージ待ち行列IDを含む。RNODE
BOOTCNTというフイールドは、遠隔ノードの
電力サイクル状況をあらわす数を含む。 第４図は、メツセージ待ち行列エントリの内容
を示す。MTYPEはメツセージのメツセージ・タ
イプであり、MSGPTRは、メツセージ・テキス
トに対するポインタである。 第５図は、本発明に基づきIPCの間に実行され
る論理をあらわすフローチヤートである。これに
おいて、ノードLOCNODEでのプロセスが通信
を開始したとき、プロセスは、ブロツク８０で示
される入力としてLKEYを与えるmsggetシステ
ム・コールを発行する。そのキーは、
LOCNODEのカーネル在駐KMTにおけるルツク
アツプ関数に対する引数である。そして、ブロツ
ク８２でKMTが検索される。ブロツク８４で一
致が見出されると、ブロツク８６でIPC論理が、
LOCNODEとREMNODEの間に通信リンクが存
在するかどうかを判断する（この説明では、
RNODEがREMNODEのためのノードIDを含む
ものと仮定する）。もし通信リンクが存在しない
なら、ブロツク８８で通信リンクが確立され、ブ
ロツク９０で、KMT中で見出された相関キー
RKEYが関連するノードREMNODEに送られ
る。 もしKMT中で、msggetをコールするために使
用されるLKEYのためのエントリが見出されなか
つたら、メツセージ待ち行列はブロツク９２で局
所的であるとみなされ、慣用的な方法で通信が行
なわれる。 ブロツク９４で、REMNODEのmsggetトラン
ザクシヨン・プログラムがRKEYを受け取り、
ブロツク９６でREMNODEにおける待ち行列ヘ
ツダを検索する。このとき、ブロツク９８で一致
が見出されないなら、エラー条件が存在し、そこ
のことはブロツク１００で表示される。もし
REMNODEの待ち行列ヘツダがエントリ一致
RKEYを含むなら、ブロツク１０２で
REMNODEのブート・カウントであるRNODE
BOOTCNTとともにMSQIDがLOCNODEに戻
される。 次にブロツク１０４で示すようにLOCNODE
に戻つて、Ｒフオーマツト待ち行列ヘツダ・エン
トリ（第３図参照）がLOCNODE待ち行列ヘツ
ダ・リストに追加され、局所ノードMSQIDが呼
出し手に戻される。呼プロセスは次にmsgsndを
実行し、第５Ｂ図に知す論理が適用される。 第５Ｂ図を参照すると、LOCNODEにおいて、
MSQID（ブロツク１１０）が、LOCNODE待ち
行列ヘツダ・リストにインデツクスするために使
用される（ブロツク１１２）。ブロツク１１４で、
REMNODE（待ち行列ヘツダ中のRNODE）が既
にLOCNODEと接続されているかどうかの判断
がなされる。もしそうでなければ、ブロツク１１
６で接続が確立され、LOCNODEのmsgsndがメ
ツセージ・テキスト、MSQID、RNODE
BOOTCNTとMTYPEのREMNODEへの送信を
行なわせる（ブロツク１１８）。 REMNODEでは、ブロツク１２０でその
msgsndトランザクシヨン・プログラムがMSQID
とBOOTCNT MTYPEを受け取る。
REMNODEはこのデータを受け取り、ブロツク
１２２で先ず受け取つたデータと、REMNODE
における現在のブート・カウントとを比較する。
もしそれらが一致しないならエラー条件が存在
し、そのことはブロツク１２４でLOCNODEに
戻される。一方、それらのカウント値が一致する
とき、REMNODEmsgsndトランザクシヨン・プ
ログラムが、待ち行列ヘツダを選択し、MTYPE
とともにそのメツセージ待ち行列上にメツセー
ジ・テキスト・ポインタ、MSGPTRを配置する
ためにMSQIDを使用する（ブロツク１２６）。
ブロツク１２８でREMNODEは、LOCNODEに
応答し、呼出し者（caller）に、成功裡に完了し
たという状況を戻す。 第５Ｃ図は、msgrcvシステム・コールの動作
をあらわすフローチヤートである。LOCNODE
において、ブロツク１４０でmsgrcvはMSQIDと
MTYPEを受け取る。msgrcvは、その待ち行列
ヘツダ・リストへインデツクスし正しい待ち行列
ヘツダを見出すためにMSQIDを使用する。また
msgrcvは、そのヘツダに含まれているRNODE
情報を使用して、ブロツク１４４でREMNODE
との接続（リンク）が存在しているかどうかを判
断し、もしそうでなければ、ブロツク１４６で接
続を確立する。ブロツク１４８では、その確立さ
れたリンクを介してMSQIDと、RNODE
BOOTCNTと、MTYPEがREMNODEに送られ
る。 REMNODEのmsgrcvトランザクシヨン・プロ
グラムがブロツク１５０でこの情報を受け取つた
後、そのプログラムは受け取つたブート・カウン
ト値と現在のブート・カウント値を比較する（ブ
ロツク１５２）。もしそれらのブート・カウント
値が一致しないのならブロツク１５４でエラー条
件が表示されLOCNODEに戻される。 ブート・カウント値が一致したとき、ブロツク
１５６でREMNODEのmsgrcvトランザクシヨ
ン・プログラム論理が待ち行列ヘツダを選択する
ために、受け取つたMSQIDを使用する。論理は
次に、ブロツク１５８で一致するMTYPEをもつ
メツセージがあるか否かを判断するために待ち行
列のメツセージ・エントリをチエツクする。もし
REMNODEのメツセージ待ち行列上に一致する
MTYPEをもつメツセージが存在しないのなら、
論理はブロツク１６０でメツセージが到来するの
を待つ。もし一致するMTYPEをもつメツセージ
が見出されたなら、ブロツク１６２で、上記の既
に確立された同一の通信リンクによりメツセー
ジ・テキスト・ポインタがLOCNODEに戻され
る。ブロツク１６４で、LOCNODEは呼出し手
にメツセージ・テキストを戻す。 第６図は、第５Ａ，５Ｂ，５Ｃ図に関連する論
理を、特定の仮設的環境を使用して説明する図で
ある。ここでユーザが会議室を予定する
（scheduler）ためにコールするシエル・コマン
ド・プログラムがLOCNODEに存在すると仮定
しよう。このシエル・コマンドは、スケジユー
ラ・デーモン（daemon）IPCメツセージ待ち行
列のためにMSQIDを入手するべくその
LKEY71000のためにmsggetを発行する。また、
ネツトワーク管理者が、LOCNODEからの会議
室の要求がREMNODE中のデーモンによつてサ
ービスされるべきであると決定し、REMNODE
中のデーモンの待ち行列のためのキーが67000で
あると仮定する。この情報は、LOCNODEのカ
ーネルIPCKMT中にロードされている。 動作のシーケンスは次のとおりである。 (1) get roomがキー71000でMSGGETをコー
ル。 (2) MSGGETがキー71000のためのLOCNODE
KEYを参照する。 (3) KMTは、キー71000がRNODE REMNODE
中でRKEY67000に再マツプされたことを表示
する。 (4) MSGGETは今やREMNODE中でキー67000
を探すべきことを知つている。 (5) MSGGETはREMNODEとSNA接続を見出
し、あるいは確立し、キー67000のための
MSQIDを要求するネツトワーク・メツセージ
を送る。 (6) REMNODE中のMSGGETトランザクシヨ
ン・プログラムは、キーが67000である待ち行
列のためのメツセージ待ち行列ヘツダを探し出
す。この場合MSQIDは２である。 (7) REMNODE中のMSGGETトランザクシヨ
ン・プログラムは、LOCNODE中のMSGGET
に、MSQIDが２であることを述べるネツトワ
ーク応答を送る。 (8) MSGGETは、待ち行列ヘツダのリストにエ
ントリを追加する。ヘツダ・エントリはとりわ
けRNODE中のREMNODEと、２である
RNODE MSQIDと、これが遠隔待ち行列ヘツ
ダのための局所“代理”であることを記述する
タグＲとを含む。この例では、遠隔待ち行列の
ための代理ヘツダは、LOCNODEの待ち行列
ヘツダ・リストのスロツト１にあり、従つて
LOCNODE MSQIDは１である。 (9) MSGGETは呼出し者にMSQID＝１を戻す。 (10) get−roomは、会議室デーモンにIPCメツセ
ージを送るためにこのMSQIDを使用する。 以下に示すのは、第５Ａ，５Ｂ，５Ｃ及び６図
に関連して説明した論理フローチヤートの擬似コ
ード表現である。

【表】

【表】 長さバツフアの長さ

【表】 〓
〓
待ち行列の割当ては、“よく知られた”待ち行
列、すなわち多くの依頼人によつて使用されると
考えられる待ち行列には重複するキーが作成され
ないように管理されなくてはならない。本発明に
よれば、割当てキーの外部登録の必要なしでアプ
リケーシン・プロジエクトの作成者が大域的に固
有のキーを作成することを可能ならしめる方策が
与えられる。この方策の主要な要素は、待ち行列
プロフアイル（第１図、参照番号５２）のエント
リ中で14個のキヤラクタの文字数字
（alphanumeric）待ち行列名を使用することであ
る。 アプリケーシヨンの開発者は、一意的に表現す
るための14個のキヤラクタの名前を選択する。各
待ち行列プロフアイル・エントリは第１図に示さ
れているように、QNAME、LKEY、RNODE、
RKEYというフイールドをもつ。 ライブラリ・ルーチンcreate ipc prof
（QNAME、LKEY、RKEY、NICKNAME）が
待ち行列プロフアイルを作成する。すなわち、呼
出し者が名前を与え、このルーチンが待ち行列プ
ロフアイル・エントリを作成し、それに固有の局
所キーを割当て、その局所キーを呼出し者に戻
す。その後ネツトワーク管理者がRNODEを及び
RKEYのためのデータを与える。 さて、分散アプリケーシヨンがサーバ・デーモ
ンとサーバの要求を作成するコマンド・プログラ
ムから成つていると仮定する。サーバは特定のネ
ツトワーク・ノード上に在駐し、コマンド・プロ
グラムはネツトワークのいくつかのノードのどれ
かで実行することができる。そのようなアプリケ
ーシヨンの導入及び動作は次の例によつて示され
る。 すなわち、デーモンが走るべき位置でアプリケ
ーシヨンの導入プログラムがcreate ipc prof
(3)をコールし、“ACMEsfwr032686”という待ち
行列名を与える。create ipc prof(3)によつて
作成されるプロフアイルは次のものを含む： 名 前“ACMEsfwr032686” 局所キー Ox30000−OxFFFFFの範囲から
create ipc prof(3)によつて選択され、この
ノードにおける他のいかなるプロフアイルとも
衝突しない値。 遠隔ノード 空文字 遠隔キー ０ コマンド・プログラムが走るべき各位置で、ア
プリケーシヨンの導入プログラムはcreate ipc
prof(3)をコールし、“ACMEsfwr032686”の待
ち行列名を与える。create ipc prof(3)によつ
て作成されるプロフアイルは次のものを含む： 名 前 “ACMEsfwr032686” 局所キー create ipc prof(3)によつて
Ox30000−OxFFFFFの範囲から選択され、こ
のノードにおける他のいかなるプロフアイルと
も衝突しない値。 ネツトワーク管理者は、次のものを含むように
コマンド・ノードにおけるプロフアイルを変更す
るように指令される： 遠隔ノード デーモンのノード 遠隔キー デーモンのノードにおける待ち行列の
局所キー デーモンがスタート・アツプするとき、デーモ
ンはfind ipc prof(3)をコールして、待ち行列
名“ACMEsfwr032686”を与えてその名前に関
連するキーを見出す。デーモンは次にその待ち行
列のためのIDを入手するためにmsgget（キー、
０）をコールする。 この14キヤラクタの待ち行列名はソフトウエア
開発者に、待ち行列名を選択する際のきわめて大
きい自由度を与える。すなわち、これにおいて
は、アプリケーシヨン開発者らの間で打合わせが
なくとも、ある開発者によつて注意深く選択され
た名前が、別の開発者によつて選択された名前と
衝突することはきわめて起こり難いことである。
しかし、慎重な開発者といえども衝突が生じるよ
うな場合を有する設計を選択することが全くない
とは言えない。そのような衝突を扱うための例示
的な方策としては次のようなものがある： ＊好適な待ち行列名がアプリケーシヨン・プログ
ラム中に固定的にコード化されるが、デーモン
とコマンド・プログラムの両方上でコマンド引
数によつて無効（override）ストリングを供給
することもできる。 ＊デーモンはまたコマンド・プログラムが導入さ
れたとき、そのデーモンまたはコマンド・プロ
グラムは、必要な待ち行列プロフアイルを作成
するためにcreate ipc prof(3)を使用する。
もし名前の衝突のためその作成が失敗したな
ら、管理者が固有の待ち行列を入力するよう促
される。導入プログラムは次にプロフアイルを
作成するためにこの待ち行列名を使用する。 ＊導入プログラムまたは文書は管理者に、デーモ
ン及びコマンド・プログラムが常に待ち行列名
引数で呼び出されていることを確認するよう指
令する。 次に正しいメツセージの経路指定（routing）
を保証するために実施される技術について説明す
る。上述のBachの文献に述べられているような
単独アプリケーシヨンにおいては、カーネルに所
与のタイプの最初のメツセージを戻させるように
MTYPEパラメータが適宜セツトされる。もし待
ち行列上にこのタイプを満足するメツセージが存
在しないなら、カーネルはプロセスを休眠させ
る。複数のプロセスが１つのメツセージ待ち行列
上で多重チヤネルをセツト・アツプすることがで
き、以て各プロセスが、カーネルが適正な順序を
維持しつつ到来する特定タイプのメツセージを順
に抽出することになる。 分散サービス・ネツトワーク環境においては、
しかし、複数の要求者が同時に同一のサーバを扱
うことが可能である。本発明は、メツセージ・タ
イプを用いて応答メツセージのデマルチプレクス
機能を与える。 MTYPE値は、メツセージ待ち行列ヘツダ（第
３図）中に32ビツトのMTYPE値を与えることに
よつて一意的であるように割当てられる。この値
は、最も新しく使用されたMTYPE値に対応す
る。メツセージ制御（msgct１）のための新しい
コマンドは、待ち行列のメツセージ・タイプの現
在の値を戻させる。MTYPEはプロセスに戻され
る度毎に（第５Ｂ図、ブロツク１２８）直ちにイ
ンクレメントされる。 尚、要求及び応答が同一の待ち行列を流れる方
がより効率的であるので、双方向待ち行列を切換
する際にMTYPEのために確立された規約がさら
にネツトワークの処理能力を高める。 例えば、次のような筋書きにより、起こり得る
問題が描き出される。すなわち、待ち行列を作成
するプロセス中でサーバがパワー・オンすると、
その待ち行列の識別情報が最初の待ち行列ヘツ
ダ・スロツドに入る。そして依頼人がmsggetを
行い、MSQIDを受け取る。ところでサーバは電
源サイクルを通過する。その少し後にサーバにお
けるプロセスが別の待ち行列を作成し、その識別
情報を最初の待ち行列ヘツダ・スロツトに入れ
る。依頼人のプロセスは次にもとのMSQIDを用
いてmsgsndを行う。すると、依頼人からのメツ
セージは依頼人が期待した待ち行列には行かな
い。 本発明によれば、依頼人がメツセージを送る度
毎にブート・カウントの比較が行なわれるために
この問題が回避される。そしてもしブート・カウ
ントが等しくないなら、依頼人はエラー条件を通
知される。ここで第５Ｂ図のブロツク１２２，１
２４、及び第５Ｃ図のブロツク１５２，１５４を
再度参照されたい。 各ノードは、そのルート・デバイス・スーパ
ー・ブロツク（第１図参照番号５４）に、サーバ
のパワー・オン状態を示すカウンタ、
BOOTCNTを有する。このカウンタは、サーバ
がパワー・オフされ再びオンにされる度毎にイン
クレメントされる。このカウント値は第５Ｂ図及
び第５Ｃ図に述べられているようなメツセージ動
作に使用され、そのメツセージ動作は、サーバ
が、メツセージ待ち行列識別子を発行したときと
同じ状態にあることを保証するためにメツセージ
待ち行列識別子を使用する。 Ｆ 発明の効果 要約すると、本発明は、多重ノード・ネツトワ
ーク中の任意のノードにあるプロセツサ間のプロ
セス間通信のための、カーネル・レベルで動作可
能な手段を与える。そして通信は、ネツトワーク
中の任意のノードにある、キーで識別されたメツ
セージ待ち行列上に配置されたメツセージを通じ
てなされる。 アプリケーシヨン・レベルでは、メツセージ待
ち行列ノード位置を知る必要がない。というの
は、上述したキー・マツピング・テーブルとそれ
の使用により、メツセージ処理システム・コール
によつて使用するための実際のメツセージ待ち行
列アドレスへの、アプリケーシヨン供給キーの確
定が可能となるからである。また、メツセージ伝
達の完全性は、必要なシステム・コールにおける
ブート・カウント比較ステツプによつて向上され
る。さらに、異なるノードのためのメツセージの
多重化は、待ち行列のヘツダ・エントリ中により
記述的なMTYPEを与えることによつて促進され
る。さらにまた、上述した命名規約により、衝
突、すなわち分散サービス・ネツトワーク環境中
の異なるアプリケーシヨン及びメツセージ待ち行
列によつて同一の名前が使用されることの虞れが
実質的に解消される。

【図面の簡単な説明】

第１図は、本発明が実施される複数のノードを
もつネツトワークをあらわす概要図、第２図は、
KMTのフオーマツトを示す図、第３図は、待ち
行列ヘツダ・レコードのエントリを示す図、第４
図は、メツセージ待ち行列エントリのフオーマツ
トを示す図、第５Ａ，５Ｂ及び５Ｃ図は、プロセ
ス間通信の動作の論理フローチヤート、第６図
は、ある仮設的な値を与えた場合のプロセス間通
信の例を示す図である。

Claims (1)

1. 【特許請求の範囲】 １ メツセージを格納した待ち行列を有する複数
   のプロセツサノードを含み、アプリケーシヨン実
   行を要求したノードがアプリケーシヨンを実行す
   るノードをユーザに意識させることなく当該アプ
   リケーシヨン実行をすることができるネツトワー
   クシステムにおいて、 前記各ノードが、 前記要求ノードにおける参照のためのキーを、
   前記待ち行列が実際に駐在する実行ノードの名称
   と前記実行ノードにおける前記待ち行列固有のキ
   ーに相関させるテーブル手段と、 前記テーブル手段を参照し、前記要求ノードと
   前記実行ノードのリンクを確立するための手段
   と、 前記リンク確立後に前記実行ノードの待ち行列
   ヘツダの参照を経て、前記実行ノードの名称と前
   記実行ノードにおける前記待ち行列に割り当てら
   れた固有の識別子を前記要求ノードに格納するた
   めの手段と、 を含むネツトワークシステム。 ２ 前記待ち行列ヘツダは、前記待ち行列にそれ
   ぞれ独立な番号であつて、前記要求ノードが前記
   実行ノードにメツセージを要求するごとに増分す
   る番号を含むこと、 を特徴とする請求項１のネツトワークシステム。 ３ 前記待ち行列ヘツダは、前記各ノードの電源
   の投入の回数に対応するカウンタ情報を含むこ
   と、を特徴とする請求項１のネツトワークシステ
   ム。