JPH0797323B2

JPH0797323B2 - 名前付きパイプを用いるプロセス間通信の方法及びプロセス

Info

Publication number: JPH0797323B2
Application number: JP4199504A
Authority: JP
Inventors: リチャード・ジョセフ・ハービック; クリストファー・ジョン・レノン; ティモシー・ネルソン・スカグス; フィリップ・アンソニー・スミス
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 1991-09-30
Filing date: 1992-07-27
Publication date: 1995-10-18
Anticipated expiration: 2010-10-18
Also published as: JPH05204673A; BR9203584A; EP0536073A2; US5448734A; EP0536073A3

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は一般に多重タスク処理又
は多重処理コンピュータ・システムにおけるプロセス間
通信に関する。詳しくは、本発明は前記システム内のプ
ロセスにより名前付きパイプを介して他のメッセージ受
取りプロセスに、全てメッセージ・タイプに従って、か
つ前記受取りプロセスのテーブル登録を用いずに、メッ
セージを選択的に配布する方法及び装置に関する。

【０００２】

【従来の技術】本発明は、コンピュータ・システム内の
プロセス間通信(IPC) のために、共有メモリ、セマフォ
ア(semaphore)、キュー(queue)、パイプ及び名前付きパ
イプを含み、基本的な方法の大部分に名前を付ける。こ
れらのIPC の種々の方法の特性は論文TALKING TASKS, b
eginning at page 403 in BYTE magazine, November 19
90 issueに要約されている。

【０００３】この開示は、名前付き通信チャネル即ち名
前付きパイプの使用に関連する。プロセス間通信のため
の名前付きパイプの使用に関する１つのシナリオはメッ
セージ配布である。例えば、あるシステムでは、メッセ
ージ・サーバーはそのシステムで実行中の他のプロセス
からのメッセージを受信し、更にそのメッセージを、そ
のメッセージの受信を望む他のプロセスに配布する。こ
の手法は一般にデスクトップ・コンピュータのウィンド
ウ・オペレーティングシステム例えばOS/2(IBM社の商
標) オペレーティングシステムで用いられる。このよう
なオペレーティングシステムで名前付きパイプを用いる
一般的な手法の１つは、メッセージ・サーバーがメッセ
ージを、システム内のあらゆるプロセスに配布し、その
メッセージが関連する情報を含むかどうかを、それを受
信する各プロセスが判定することである。これは同報通
信(broadcast) 手法と呼ばれる。もう１つの一般的な手
法は、プロセス及びその各々が受信することを望む特定
のタイプのメッセージを登録することである。これは登
録アプローチと呼ばれることがある。明らかに、同報通
信手法はコンピュータ内に大量のトラフィックの無駄を
生じる。後者の登録アプローチの実施例は、Software-P
ractice and Experience, Vol.20(S1), pagesS1/3-S1/1
7,June 1990 に発表された別の論文 INTERPROCESS COMM
UNICATION INTHE NINTH EDITION UNIX SYSTEM by David
Presotto and Dennis Ritchieに記述されている。例え
ば、登録アプローチを用いる接続サーバーはこの論文の
ページS1/10 から記述されている。この例では、サーバ
ー・プロセスはパイプを生成し、そのサービス及びその
パイプを他のプロセスに公示する。顧客プロセスは、そ
れがサービスを利用したいとき、前記パイプに接続し、
登録及び要求するサービスのタイプの標識を前記サーバ
ーに伝達する。このタイプのサービスは一定のタイプの
システム・メッセージを受信する要求かも知れない。

【０００４】論文 PORTABLE IPC ON VANILLA UNIX,Mark
Rain,Penobscot Research Center,Deer Isle,Maine 04
627に前記登録方法の変形が記載されている。この論文
はIPCチャネルを与えかつ顧客プロセスのサーバー登録
として動作するサービスを有するチャネル・サーバーに
ついて記述している。サーバーはチャネル・サービスか
らIPC チャネル(パイプ)を取得する。そしてサーバーは
チャネル・サービスによりそれ自身をそれが提供するサ
ービスの表示と共に登録する。

【０００５】

【発明が解決すべき課題】このような登録アプローチは
それを維持していくのに不便なことがある。例えば、も
し登録されたプロセスが異常に終了すれば、その登録を
維持するサーバー・プロセスによる登録は、この状態を
トラップ(trap)する特別の構成なしには自動的には除去
されない。更に、同報通信手法及び登録手法はどちら
も、かなりの資源を消費するが、これは減らすことが望
まれる。

【０００６】

【課題を解決するための手段】本発明はコンピュータ・
システム内のメッセージ送信プロセスとメッセージ受信
プロセスの間でメッセージを伝達するための方法及び装
置である。一定のタイプのメッセージの受信を望むプロ
セスは通信チャネルすなわち、名前付きパイプを生成す
る。このパイプは受信プロセスにおいて終端するととも
にそのコンピュータのオペレーティングシステムにより
管理される。プロセスがそのチャネルをアドレス指定で
きる名前は、前記生成プロセスが受信することを望むメ
ッセージ・タイプに対応して割当てられる。換言すれ
ば、メッセージ・タイプの識別はチャネル名を特定す
る。選択されたタイプのメッセージをシステム内の他の
プロセスに送信するプロセスは、前記選択されたメッセ
ージ・タイプに対応する名前を持つ通信チャネルをオー
プンする。そして送信プロセスはその目的のために提供
されたシステム機能呼出しを用いて前記チャネルへのメ
ッセージを記述する。このチャネルに書込むプロセスは
前記チャネルの他端における受信プロセスに警告を発
し、それに応答して前記受信プロセスは送信チャネルか
らメッセージを読取る。

【０００７】良好な実施例では、受信プロセスが通信チ
ャネルを生成した後、受信プロセスは、送信プロセスが
前記チャネルへのメッセージの書込みによってシステム
により再活動化されるまで非活動状態に置かれる。受信
プロセスによりメッセージがチャネルから読取られた
後、受信プロセスは別のプロセスが前記チャネルに書込
むまで再び非活動状態を取り戻す。しかしながら、受信
プロセスは、もしそれが希望すれば活動状態に留まり、
オペレーティングシステムによって送られたセマフォア
の使用によりそのパイプにメッセージが存在する時期を
判定することができる。

【０００８】名前付き通信チャネルが使用できるタイプ
のシステムでは、即ち、OS/2オペレーティングシステム
のようなシステムでは、同じ名前を有するチャネルの多
くのインスタンス(instance)は同時に存在できる。従っ
て、本発明で用いられるように、タイプＸのメッセージ
を受信したい各アプリケーションはそれぞれ名前Ｘのチ
ャネルのインスタンスを生成する。システム内の全ての
プロセスにメッセージを送信したい送信プロセスは、送
信されるメッセージ・タイプに対応する同じ名前を持
つ、前記システム内の通信チャネルの全てのインスタン
スを単にオープンするだけである。

【０００９】従って、選択的メッセージ配布機能又はサ
ービスは、名前付きパイプのようなチャネルを用いかつ
登録機構を用いることなく、容易にシステムに組込みで
きることが分かる。メッセージ配布は送信されるメッセ
ージのタイプ識別だけを知るプロセスにより実行しかつ
指定されたタイプのメッセージを受信したい全てのプロ
セスにより受信することができる。送信プロセスはメッ
セージを受信するプロセスを知らなくてもよい。送信プ
ロセスは送信されるメッセージ・タイプの名前付きシス
テム・チャネルをオープンしてそのチャネルに前記メッ
セージを書込むだけである。同様に、メッセージを受信
するプロセスはそのメッセージを送信するプロセスを知
らなくてもよい。

【００１０】

【実施例】名前付きパイプは多重タスク処理コンピュー
タのオペレーティングシステムにある通信手段であり、
前記システムにおいて実行中のプロセスの間又は更に異
なるシステムにおけるプロセスの間でデータ及びメッセ
ージを送受信するのに用いることができる。名前付きパ
イプは現在では技術的によく知られている。下記は前記
名前付きパイプの特徴である。パイプはプロセスが要求
したときシステム機能により構築される。パイプはそれ
を生成するプロセスが所有し、その一端は前記生成する
プロセスより開始する。一般に、名前付きパイプの生成
者及び所有者はそのパイプの他端にあるもう１つのプロ
セスへのデータ等の送信者である。しかしながら、パイ
プの所有者はデータを受信することもできる。実際、こ
の動作モードを用いることは後で説明するように本発明
の利点である。パイプは２重動作のために生成すること
もできる。すなわち、パイプはプロセス間のパイプに沿
って両方向にデータを送信するのに用いることができ
る。各パイプは名前を有し、名前によってパイプをアド
レス指定できる（システムによっては名前をハンドル、
番号に変換し、それによって装置はアドレス指定され
る）。名前付きパイプの複数のインスタンスが許され、
関心のあるプロセスによりアドレス指定できる。

【００１１】セマフォアと呼ばれるIPC のもう１つの形
式は一般に、送信者がパイプをオーバフローしないよう
にかつ受信者がパイプからデータを読取る時期を知るよ
うに、パイプ上のデータを送信する動作と受信する動作
とを同期させるために用いられる。これらのセマフォア
は一般にパイプに対するアトミック書込み／読取り動作
を保証するためにも用いられる。

【００１２】パイプを所有するプロセスはいつでもその
パイプを終了させることができる。もしプロセス自身が
終了すれば、そのプロセスが所有する全ての名前付きパ
イプも終了される。換言すれば、名前付きパイプはどれ
もその生成者よりも長くは続かない。これらの名前付き
パイプ上の動作、データの生成、送受信及び終了は他の
プロセスの要求でシステム機能により実行される。例え
ば、OS/2オペレーティングシステムは下記を含むシステ
ム呼出しのセットを介して名前付きパイプの操作を可能
にする： DosCallNmPipe：名前付きパイプに書込む動作の完全な
セットを実行する。これは名前付きパイプのオープン、
書込み及びクローズを含む。 DosClose：ファイル、装置又はパイプをクローズす
る。 DosConnectNmPipe：アプリケーションを名前付きパイプ
と接続し、そのアプリケーションがそのパイプから読取
りそのパイプに書込むことを可能にする。 DosDisConnectNmPipe：アプリケーションが読取り又は
書込みを行なったのちアプリケーションを名前付きパイ
プから切離す。 DosMakeNmPipe：アプリケーションにより供給された名
前を用いる名前付きパイプを生成してそのアプリケーシ
ョンをアドレス指定できるハンドルを返送し、読取り、
書込み、オープン及びクローズのような名前付きパイプ
の機能を実行する。 DosOpen：ファイル又は名前付きパイプをオープンす
る。 DosPeekNmPipe：アプリケーションは名前付きパイプを
介して到着するデータを前記パイプからそのデータを移
転することなく調べることができる。 DosNmPHandState：アプリケーションはパイプの特徴(例
えば、メッセージ・タイプ対ブロック・タイプ)につい
て質問することができる。 DosONmPipeInfo：アプリケーションは名前付きパイプに
関する統計（例えば、現在のインスタンス数、可能なイ
ンスタンスの最大数）について質問することができる。 DosONmPipeSemState：アプリケーションはパイプの状態
（例えば、パイプ内のデータ、パイプ内のデータの量）
について質問することができる。 DosRead：ファイル又は名前付きパイプから読出す。 DosReadAsync：アプリケーションは指定された量のデー
タをパイプ又はファイルからバッファに非同期で転送す
ることができる。 DosSetNmPHandState：名前付きパイプの読取り及びブロ
ッキング・モデルをセットする。（呼出しが行なわれた
ときもしパイプ内に使用できるデータがなければ、ブロ
ッキングはデータがパイプに到着するまでのアプリケー
ションの停止を指示する）。 DosSetNmPipeSem：システム・セマフォアを名前付きパ
イプに接続する。そしてこのセマフォアはアプリケーシ
ョンによりそのパイプでデータが到着する時期の標識と
して用いられる。 DosWaitNmPipe：アプリケーションは名前付きパイプ生
成が可能になるのを待つことができる。 DosWrite：ファイル又は名前付きパイプに書込む。 DosWriteAsync：アプリケーションは指定された量のデ
ータをバッファからパイプ又はファイルに非同期で転送
することができる。

【００１３】これらの機能及びそれらの使用はプログラ
ミング技術分野の当業者に広く知られている。それらは
特にOS/2 Programmers Reference Guide, Document Num
ber64F0275, September 1989 に詳細に記述されてい
る。

【００１４】図１はプロセス間のメッセージ伝達を実行
するために従来の技術で名前付きパイプを用いる従来技
術による方法を示す。これは単一の多重タスク処理コン
ピュータ・システム100 を含む簡略化された例である。
この例では、少なくとも４つの別々のアプリケーション
・プロセスＡ〜Ｄが関連あるときシステム内で実行中で
あると仮定する。図１には、メッセージ・サーバー102
及び登録テーブル104も示されている。例えば、アプリ
ケーション・プログラムＡは、もしそれがシステム又は
他のアプリケーションにより生成された一定のクラス又
はタイプのメッセージを受信したいと望めば、メッセー
ジ・サーバー102 により適切なシステム呼出しによって
それ自身を登録する。登録要求はメッセージのタイプの
登録プロセスからの、受信に関連する指示を含む。アプ
リケーションＡはメッセージ・サーバー102 が受信した
タイプＸのメッセージを全て調べることを要求すると仮
定する。同様に、ある時点で、アプリケーションＣもメ
ッセージ・サーバー102 からタイプＸのメッセージを受
信することを要求している。アプリケーションＤはタイ
プＹのメッセージを受信することを要求している。登録
を可能にするシステム機能が実行されると、その結果と
して登録テーブル104 に要求プロセスが含まれる。この
特定の実施例に従って、登録テーブル104 は、各アプリ
ケーションが受信したいメッセージのタイプ毎の指示と
ともに、アプリケーションＡ、Ｃ及びＤの別々のエント
リを含むことが分かる。

【００１５】メッセージ・サーバー102で登録要求が受
信されかつ登録テーブル104に適切なエントリが生成さ
れると、メッセージ・サーバー102 からそのアプリケー
ションにつながる名前付きパイプも生成される。図示の
ように、所与の要求元の特定のパイプ名及び要求タイプ
が登録テーブル104 に入れられる。例えば、アプリケー
ションＡがタイプＸのメッセージの受信に登録されるこ
とを要求すると、 (もしアプリケーションＡへのパイプ
がまだなかったならば)メッセージ・サーバー102からア
プリケーションＡへのパイプ106 が生成される。これら
のパイプの識別は任意であり、登録テーブル104 を経由
する以外は、それらを介して送信されるメッセージのタ
イプ又は受信プロセスとは無関係である。配布するメッ
セージをメッセージ・サーバー102 に送信するために、
例えば、アプリケーションからメッセージ・サーバー10
2へのパイプ108又は他の通信チャネルも生成することが
できる。この簡略化された実施例では、アプリケーショ
ンからメッセージ・サーバー102 への通信の詳細は省略
されている。

【００１６】ここで、図１のアプリケーションＤは、タ
イプＸのメッセージを受信したい全ての他のシステム・
プロセスに配布するために、タイプＸのメッセージを生
成すると仮定する。メッセージはチャネル又はパイプ10
8 によりメッセージ・サーバー102に送信される。メッ
セージ・サーバー102はメッセージを受信し、そのメッ
セージに含まれているタイプを書留め、タイプＸのメッ
セージを受信したい全ての登録されたプロセスを識別す
るために登録テーブル104 を探索する。この実施例で
は、メッセージ・サーバー102 はメッセージのタイプＸ
として登録されたアプリケーションＡ及びＣを発見す
る。従って、メッセージ・サーバー102 はアプリケーシ
ョンＡ及びＣに関連したパイプ識別を登録テーブル104
から取得し、前記受取ったメッセージをこれらのパイプ
を介したアプリケーションＤからアプリケーションＡ及
びＣへの経路を指定する。アプリケーションＡの場合、
メッセージは登録テーブル104のPIPENAME(パイプ名)フ
ィールドで識別されるパイプ106による経路を指定す
る。

【００１７】既に簡単に説明したように、この典型的な
タイプのメッセージ配列には一定の欠点がある。第一の
欠点は登録テーブル104 の管理が必要なことである。第
二の欠点はこの管理が必ずしも自動ではないことであ
る。例えば、なにかの理由でアプリケーションＡがシス
テムから消えると仮定する。それはシステムの誤動作、
プログラムのバグ又はその他のいくつかの原因によるも
のであろう。このようなケースでは、登録テーブル104
は自動的には更新されず、アプリケーションＡは登録テ
ーブル104に留まる。メッセージ・サーバー102がテーブ
ル・エントリにより識別されたアプリケーションと通信
しようと試みたとき、エラー発生を検出しそのテーブル
・エントリが最終的にシステムから取り除かれる。しか
しながら、登録テーブル104 は通信から生じる１又はよ
り多くの誤り状態の処理後にのみ正しい状態に復元され
る。

【００１８】図２は本発明に従って設計されたシステム
における類似のメッセージ伝達の実施例を示す。この実
施例では、明白なメッセージ・サーバーはない。このよ
うな例は後で簡単に説明する。この例においても、図２
の実施例ではコンピュータ・システム200 内の４つのア
プリケーションＡ乃至Ｄが活動状態であると仮定する。
パイプを操作するために提供されるシステム機能は１つ
のブロック202 として概念的に示される。図中の破線は
アプリケーションによるシステム機能の呼出しを表わ
す。各アプリケーションはRECEIVE(受信) モジュール及
びSEND(送信)モジュール、例えばアプリケーションＡに
関連した206及び208を含む。アプリケーションが他のア
プリケーションから所与のタイプのメッセージを受信し
たいとき、そのアプリケーションのRECEIVE モジュール
は名前付きパイプを生成し、生成されたパイプは生成ア
プリケーションのRECEIVE モジュールの一端を担う。ア
プリケーションＡ乃至ＤのRECEIVEモジュールでの終端
を示す名前付きパイプ210は一例である。本発明に従っ
て、各パイプは、そのパイプを介して送信されるメッセ
ージ・タイプを識別する名前が付けられる。よって、例
えば、もしアプリケーションＡが２つのメッセージ・タ
イプＸ及びＹの受信を望むならば、その RECEIVEモジュ
ールはそのRECEIVE モジュールで終端する２つのパイプ
の各々のインスタンスを呼出す。インスタンスは各メッ
セージのタイプに関するものであり、それぞれがその関
連するメッセージ・タイプを識別するシステム機能によ
り名付けられる。アプリケーションは名前付きパイプを
生成するので、パイプがメッセージ・サーバー102 によ
り所有される図１の一般的な状況と異なり、アプリケー
ションが名前付きパイプを所有する。この構成の１つの
利点は、もしアプリケーションがなにかの理由で終了す
れば、システム機能は自動的にパイプを終了することで
ある。例えば、OS/2オペレーティングシステムは、プロ
セスの通常又は異常終了の間にプロセスにより所有され
た全てのファイル及びパイプ・ハンドルをクローズする
DosClose機能を用いる。後で明らかになるように、この
構成は登録を不要にする。

【００１９】図２に示すように、名前付きパイプの各々
はシステム機能202 のブロックで他端が終端される。こ
の終端はもちろん概念的なものである。実際には、これ
らのパイプの各々は単にシステム内に存在し、特定のタ
イプのメッセージを有するパイプの各インスタンスに関
連する首尾一貫した命名規約によりオペレーティングシ
ステムに識別される。そしてこの命名規約により、Ａ乃
至Ｄのようなプロセスはメッセージ送信のシステム機能
を介してパイプ及びパイプのインスタンスをアクセスで
きる。

【００２０】アプリケーションが、一定のタイプのメッ
セージを、このタイプのメッセージを調べたい全ての他
のアプリケーションに送信したいとき、送信アプリケー
ションはパイプ名のようなメッセージ・タイプを用いて
適切なシステム呼出しを行なう。システム呼出しはその
メッセージ・タイプに対応する名前のパイプの各インス
タンスを見つけ、適切なRECEIVE モジュールへのパイプ
を介してメッセージを送信する。図２の破線は、アプリ
ケーションのSENDモジュールがそのようなメッセージを
他の関連する受信プロセスに送信するためにシステム呼
出しを実行する通信プロセスを表わす。

【００２１】図３及び図４は各アプリケーションのRECE
IVE モジュール及びSENDモジュールにより実行される主
要なステップをそれぞれ示す。これらのステップに対応
するソース・コードは付録Ａ及び付録Ｂにそれぞれ示
す。

【００２２】ここで、RECEIVE モジュールを図３及び付
録Ａに関連して説明する。このモジュールはアプリケー
ションが指定されたタイプのメッセージを受信するため
にそれ自身を設定したいとき実行される。ステップ310
はアプリケーションが受信したいメッセージのタイプに
従ってパイプ名を生成する。パイプ名を生成する種々の
方法がある。これは自明の機能であるのでその動作の詳
細は説明を要しない。唯一の要求は、所与のタイプのメ
ッセージについて、同じパイプ名が全ての関連アプリケ
ーションにより生成されることである。良好な実施例で
は、名前を生成するコードがソース・ライブラリに含ま
れている。このライブラリは各アプリケーションのRECE
IVE モジュールのコードに含まれ、前記モジュールにコ
ンパイルされる。付録Ａで、このライブラリ・コードは
PIPENAME.C と呼ばれ、ライン８でRECEIVEモジュール
に包含される。RECEIVEモジュールの本体部分はライン1
0で始まる。ライン13のシステム機能呼出しDosMakeNmPi
pe は生成アプリケーションにより所有されかつ生成ア
プリケーションで終端するパイプを実際に生成する。こ
れは図３のステップ320に対応する。DosMakeNmPipeはパ
イプの名前を生成するもう１つの機能 "build_pipe_nam
e"を呼出す。パイプ名はそのパイプの生成を必要とする
メッセージのタイプに基づいて予め決定される。関数Do
sMakeNmPipe はパラメータの数である。最初のパラメー
タは、ライブラリ・ソース・プログラムPIPENAME.Cに含
まれる "build_pipe_name(X)" を識別する。前述のよう
に、この機能はDosMakeNmPipeのパイプ名を生成する。
これは図３のステップ310に対応する。DosMakeNmPipeは
パイプを生成し、"pipe_handle"を返送する。それによ
ってパイプは他のシステム機能呼出しを介してアドレス
指定される。DosMakeNmPipeの引数、Ｘは生成されるタ
イプのメッセージ・タイプを表わす。ライン14でのパイ
プ生成の成否はライン14にある戻りコード変数 "rc" 内
のDosMakeNmPipe により返送される。この例はブロッキ
ング・モードのパイプを生成する。これはメッセージが
パイプに現われるまでオペレーティングシステムが Dos
ConnectNmPipe 機能呼出しを実行するプロセスの動作を
延期すること（ときには休眠プロセスと呼ばれる）を意
味する。メッセージがパイプに現われた時点で、付録Ａ
のライン16でメッセージの読取りを開始するように、オ
ペレーティングシステムは延期されたプロセスの動作を
再開始（プロセスを再喚起）する。もしパイプが非ブロ
ッキング・モードで生成されたならば、RECEIVE プロセ
スはパイプ動作自身を、例えば、DosSetNmPipeSem 機能
呼出しの使用により管理しなくてもよい。

【００２３】パイプに関連するメッセージ・タイプを反
映する一貫したパイプ名を生成する代替方法は、その目
的のためのシステム機能呼出しを提供することである。

【００２４】NO_ERRORに等しくセットされているrcで示
すように、パイプが首尾よく生成された後、RECEIVE モ
ジュールはパイプ上でそのパイプに対応するメッセージ
の受信を待つ。これは例示された実施例では "休眠" に
相当する。この動作は図３のステップ330 及び付録Ａの
ライン14で起きる。もしアプリケーションが他のタイプ
のメッセージの受信を望むならば、RECEIVE モジュール
はこれらのメッセージのタイプのパイプを生成し更にそ
れらのパイプ上で待つ必要がある。もしメッセージが送
信されれば、ループ動作及び検査で又は他の手段でシス
テム資源を消費せずに、そのメッセージを受信するオペ
レーティングシステムにより待機中のアプリケーション
が喚起される。この良好な実施例では、RECEIVE モジュ
ールはシステム機能呼出しDosConnectNmPipeを用いる。
前記機能はメッセージ送信者からのDosOpen システム呼
出しを受け入れるパイプを準備する。指定されたメッセ
ージ・タイプのDosOpen機能を別のアプリケーションが
実行するまで、RECEIVEモジュールは休眠状態のままで
ある。

【００２５】メッセージ送信者が名前付きパイプと結合
する(指定されたパイプ名のDosOpenシステム機能を実行
する) と、送信者はパイプに接続される。実際には、送
信者は同じ名前の名前付きパイプのあらゆるインスタン
スに接続される。SENDモジュールに関連して説明する送
信アプリケーションはそれが別のシステム呼出しにより
伝達したいメッセージを送信する。正しいメッセージ・
タイプのパイプ・インスタンスに接続されたあらゆるRE
CEIVE モジュールはそのパイプからのメッセージを受信
する。この動作は図３の340 及び付録Ａのライン16で起
きる。システム機能DosRead は付録Ａのライン16で実際
にパイプからのメッセージ読取りを実行する。メッセー
ジは前記機能内で指定されたパラメータ"buffer(バッフ
ァ)"に読取られる。"buffer"への実際の書込みはライン
25で起きる。パイプからのメッセージ・バイトの読取書
込はライン21でのパラメータ "bytes_read" がこれ以上
のバイトは来ないことを表わすまで続く。これはメッセ
ージの終了を知らせる。この時点で、パイプは次の他の
メッセージに備えてリセットせねばならない。この動作
は図３のステップ350 及び付録Ａのライン22で起きる。
システム機能呼出しDosDisConnectNmPipe はライン22で
この動作を実行する。パイプがリセットされた後、RECE
IVEモジュールは次のメッセージを受信するためにステ
ップ330に戻って待機する。

【００２６】RECEIVE モジュールはまたメッセージが読
取られ前記バッファに記憶されたのち前記メッセージを
操作できるように適切な機能を活動化する。しかしなが
ら、この機能は本発明に特に関連しないので図示しな
い。

【００２７】アプリケーションSENDモジュールは図４及
び付録Ｂに示す。SENDモジュールは、それが全ての他の
関連アプリケーションへのタイプＸのメッセージの送信
を実行するとき、RECEIVE モジュールに関して既に説明
した方法と同じようにメッセージ・タイプに対応するパ
イプ名を生成する。この動作は図４のステップ410 及び
付録Ｂのライン15で起きる。次に、ライン16(及びステ
ップ420) で、SENDモジュールはシステム内のメッセー
ジ・タイプに対応する名前を持つ名前付きパイプの全て
のインスタンスに結合するループを開始する。各ループ
でシステム機能により次のパイプ名のインスタンスがオ
ープンされる。これ以上はパイプ・インスタンスがない
とき、オペレーティングシステムはSENDモジュールに戻
りコードを知らせる。ライン18で、システム機能呼出し
DosOpen により各名前付きパイプとの結合が実際に行な
われる。各パイプへのメッセージ書込みを実行するルー
プは付録ｂのライン21で起きる。ライン24(図４のステ
ップ430) で、DosWriteシステム呼出しを介してパイプ
へのメッセージの実際の書込みが起きる。各ループで、
DosWrite機能は名前付きパイプの次のインスタンスに自
動的に書込む。各々がパイプに書込んだ後、DosCloseシ
ステム機能呼出しは、ライン25 (図４のステップ440)で
送信アプリケーションをパイプから切離し、パイプに結
合されたアプリケーションのRECEIVEモジュールのライ
ン18におけるDosRead機能にパラメータbyte_read内の０
バイト表示を受取らせる。SENDモジュールによるパイプ
切離し(クローズ)はそのパイプ・インスタンスに対する
"send"動作の終了を示す。ループは図４のステップ430
及び440で名前付きパイプの全てのインスタンスへのメ
ッセージの書込みを反復する。その後、この特定のSEND
モジュールの実行は終了し、アプリケーションが他のメ
ッセージの送信を望むまでその動作を停止する。

【００２８】前述の方法により、メッセージ送信アプリ
ケーションはどのアプリケーションが特定のメッセージ
を受信したいかを知る必要はない。受信アプリケーショ
ンもどのアプリケーションがメッセージを送信するかを
知らなくてもよい。そして、重要なことは、メッセージ
は柔軟かつ強力に全システムに伝達され、目的達成に要
するシステム・オーバーヘッドは大幅に減少する。一貫
したパイプ命名規約は、アプリケーションを識別し又は
それらを登録する必要なしに、受信アプリケーションが
受信したいメッセージのタイプを識別し、送信アプリケ
ーションが指定されたタイプのメッセージを欲する全て
の他のアプリケーションと通信することを可能にする。
名前付きパイプへのメッセージ読取書込動作は自動的な
アトミック動作である。すなわち、ひとたび２つのパイ
プの端がメッセージを送信するために結合されれば、前
記パイプによる書込読取動作はそれらのパイプが切離さ
れるまで他のどの送信アプリケーションも割込むことが
できない。これはメッセージの実際の転送を管理するシ
ステム機能を用いる自動特性である。

【００２９】図５は本発明を用いる１つの特定の実施例
を示す。この実施例はデスクトップ・コンピュータ上で
実行中の他のプロセスにメッセージ・サービスを提供す
る１つのデスクトップ・コンピュータ・プロセスの使用
を必要とする。例えば、このサービスはコンピュータの
ユーザに対するロギング(logging) 及び画面表示のため
の背景プロセスから操作可能メッセージを転送するため
に用いることができる。メッセージ・サービスは、コン
ピュータ表示画面をアクセスしないプロセスの選択され
たタイプのメッセージの統合された表示を、ユーザに提
供する。例えば、この例示のメッセージ・サービスを用
いてOS/2(IBMの商標) オペレーティングシステム内の分
離したソフトウェア・プロセスの問題に対する解決方法
を提供することができる。分離したプロセスは現時点で
はコンピュータの動作を中断せずに画面を出力すること
はできない。定義により、分離したプロセスはユーザの
入出力動作のための "screen(画面)"又は "keyboard(キ
ーボード)"を与えられない。これはシステム・オーバー
ヘッドを減少させる。しかしながら、分離したプロセス
は、異常な状態がユーザとの通信を必要とするときで
も、画面の大きさを制御せずにはユーザと通信すること
ができない問題を生じるので、他のアプリケーションの
画面伝達にかなり干渉する。このメッセージ・サービス
は、前記干渉なしに、前記分離したプロセスがユーザに
画面メッセージを表示することを可能にする。システム
・コンソール・プロセス500 は画面にウィンドウを重ね
るだけで干渉せずにメッセージを表示する。

【００３０】詳しくは、システム・コンソール・プロセ
ス500 の目的は指定されたタイプ、例えばタイプＺのメ
ッセージをそのコンピュータで動作する他のプロセスＡ
乃至Ｄから受信し、それらを表示画面510 に知能的にか
つ干渉せずに表示することである。例えば、システム・
コンソール・プロセス500 は、受信したメッセージを受
信した順序で表示するとともに、同時に画面に表示され
る他の情報に干渉しない画面ウィンドウにだけそれらを
表示するように設計されていると仮定されることがあ
る。コンピュータがオンになると、システム・コンソー
ル・プロセス500はそのコンピュータ内の背景プロセス
としてロードされる。その最初の動作の１つはパイプ名
Ｚを生成することである。パイプ名Ｚはそれが受信した
いメッセージ・タイプに対応する。そのパイプの一端は
システム・コンソール・プロセス500 で終端する。他の
端は、図２の場合のように、システム機能520 のブロッ
クで概念的に終端する。設計により、システム内の全て
のプロセスＡ乃至Ｄは、もしそれらが誤り、ロギング及
び一般的な情報メッセージをユーザに表示したければ、
メッセージ・タイプＺによりそれが可能なことが分か
る。よって、プロセス内で、たとえ分離したプロセス内
でも、このような事象が起きると、そのプロセスはタイ
プＺとして所望のメッセージを単に生成し、適切なシス
テム呼出しを名前付きパイプＺに対して行ない、メッセ
ージをそのパイプで送信する。その結果、システム・コ
ンソール・プロセス500 はメッセージを受信し、表示画
面510 に表示ウィンドウを生成する適切な動作を行な
う。そしてシステム・コンソール・プロセス500 はその
ウィンドウにメッセージを表示し、必要なら、トーン信
号によりユーザに警告し、そしてユーザからの要求でウ
ィンドウを除去する。これらは全て表示プロセスが既知
その他の任意のプロセスから受信するタイプＺの全ての
メッセージについてこのプロセスを管理している間に行
なわれる。

【００３１】付録Ａ /********************************************************************/ /* */ /* RECEIVE.C */ /* */ /********************************************************************/ 1)#define INCL_DOS 2)#define INCL_DOSNMPIPES 3)#define INCL_DOSERRORS 4)#include <os2.h> 5)#include <stdio.h> 6)#define PIPE_SIZE 1024 7)#define MAX_PIPE_INSTANCES 5 8)#define X 3 9)#include "pipename.c" 10)int main ( void ) { 11) USHORT rc; 12) HPIPE pipe_handle; /* 名前付きパイプを生成 */ 13) rc ＝ DosMakeNmPipe( /* パイプのインスタンスを生成 */ build_pipe_name(Ｘ),/* データ・タイプＸのパイプ名を取得 */ &pipe_handle, /* パイプ・ハンドルを返送 */ 0Ｕ, /* OpenMode: 内方向 (顧客からサーバーへ) */ /*子は受継ぎ可能 */ MAX_PIPE_INSTANCES, /* ブロッキング・モードでオープン */ 0Ｕ, /* 外向性バッファ・サイズを助言 */ PIPE_SIZE, /* 内向性バッファ・サイズを助言 */ 0x5000u1); /* DosWaitNmPipeの省略時タイムアウト */ ／＊パイプでのメッセージ待ち */ 14) while ( rc == NO_ERROR ) { 15) rc ＝ DosConnectNmPipe ( pipe_handle ); /* 送信者からのDosOpenを */ /* 受け入れるパイプを準備 */ /* OS/2は送信者がこのパイプ・インスタンスを */ /* DosOpenするまでこの動作をブロック */ /* 受信したメッセージとその読取り */ 16) while ( rc == NO_ERROR ) { /* 全てのデータの読取りが完了するまで */ /* 送信者からの読取りを保持 */ 17) USHORT bytes_read; 18) static BYTE buffer [ PIPE_SIZE ]; 19) rc ＝ DosRead ( pipe_handle, buffer, sizeof buffer, &bytes_read ); /* パイプからデータを読取る */ 20) if ( rc == NO_ERROR ) { 21) if ( bytes_read == 0 ) /* 送信者からのデータはこれ以上はない */ { /* パイプをリセット */ 22) rc ＝ DosDisConnectNmPipe ( pipe_handle ); 23) break; /* 現在の送信者を切離す */ } 24) else /* 受信したデータを表示 */ { 25) write ( 1,buffer,byte_read ); /* 普通の出力装置 #1 に書込む */ } }/* if */ }/* while */ }/* while */ return 0; }/* main */ /* -------------------- end of file -------------------- */

【００３２】付録Ｂ /********************************************************************/ /* */ /* SEND.C */ /* */ /********************************************************************/ 1)#define INCL_DOS 2)#define INCL_DOSNMPIPES 3)#define INCL_DOSERRORS 4)#include <os2.h> 5)#include <stdio.h> 6)#define PIPE_SIZE 1024 7)#define MAX_PIPE_INSTANCES 5 8)#define X 3 9)#include "pipename.c" 10)int main ( void ) { 11) HPIPE pipe_handle [ MAX_PIPE_INSTANCES ]; 12) USHORT rc; 13) PSZ pipename; 14) int i,number_of_instances ＝ 0; /* PIPENAMEを取得 */ 15) pipename ＝ build_pipe_name(X);/* データ・タイプＸのパイプ名を取得 */ /* このパイプ名の全てのインスタンスを結合 */ /* 全ての使用できるパイプ・インスタンスを */ /* 結合するループ */ 16) for ( i ＝ 0; i < MAX_PIPE_INSTANCES; + +i){ 17) USHORT action_taken; 18) rc ＝ DosOpen ( /* パイプ・インスタンスを結合 */ pipename, &(pipe_handle[number_of_instances]), &action_taken, 0ＵＬ, /* ファイル・サイズ */ 1Ｕ, /* ファイル属性 */ 1Ｕ, /* フラグをオープン:パイプがあればオープン */ /* それが存在しない場合は失敗 */ 0x0041Ｕ, /* 子は受継ぎ可能, どれも拒否せず */ /* Write-only access */ 0ＵＬ /* 予備 ULONG */ ); 19) if ( rc == NO_ERROR ) { + + number_of_instances; } } /* for */ 20) printf ( "Number of instances ＝％u/n", number_of_instances ); /* このパイプ名の各インスタンスにメッセージを書込む */ 21) for ( i ＝ 0 ; i < number_of_instances; + + i){ /* パイプ・インスタンス毎に: */ /* 書込みそして切離す */ 22) USHORT bytes_written; 23) static BYTE data [] ＝ "Test Data"; 24) DosWrite ( pipe_handle [i], data, sizeof data, &byte_written ); /* このパイプ名のインスタンスを切離す */ 25) DosClose ( pipe_handle [i] ); /* パイプ・インスタンスを切離す */ }/* for */ 26) return 0; }/* main */ /* -------------------- end of file -------------------- */

【図面の簡単な説明】

【図１】登録アプローチを用いる従来技術のメッセージ
配布システムを示すブロック図である。

【図２】本発明による名前付き通信チャネルを使用する
システムを示すブロック図である。

【図３】付録Ａに示すコードを有するメッセージ受信モ
ジュールの流れ図である。

【図４】付録Ｂに示すコードを有するメッセージ送信モ
ジュールの流れ図である。

【図５】本発明によるメッセージ配布サービスの実施例
を示す図である。

【符号の説明】

100 コンピュータ・システム 102 メッセージ・サーバー 104 登録テーブル 106 パイプ 108 パイプ 200 コンピュータ・システム 202 システム機能 206 RECEIVEモジュール 208 SENDモジュール 210 名前付きパイプ

───────────────────────────────────────────────────── フロントページの続き (72)発明者クリストファー・ジョン・レノンアメリカ合衆国27511、ノースカロライナ州キャリー、イースト・ゲレル・コート 104番他 (72)発明者ティモシー・ネルソン・スカグスアメリカ合衆国27707、ノースカロライナ州ダーラム、ペンリスナンバー・イー 5323番地 (72)発明者フィリップ・アンソニー・スミスアメリカ合衆国27604、ノースカロライナ州ラレー、ビーコン・ヒル・コート 7308 番地 (56)参考文献特開平３−90937（ＪＰ，Ａ) 特開平１−134534（ＪＰ，Ａ) 日経バイト、Ｎｏ．37、1987．９、日経マグロウヒル社、ＯＳ／２の全貌第６部ダスク間通信、Ｐ．160−170 日経バイト、Ｎｏ．44、1988．４、日経マグロウヒル社、ＯＳ／２時代のＬＡＮ／ＤＢＭＳ環境第２部新世代パソコンＬＡＮ、Ｐ．124−137

Claims

【特許請求の範囲】

【請求項１】オペレーティング・システムを有するコン
ピュータ・システム内のメッセージ送信プロセスとメッ
セージ受信プロセスの間でメッセージを伝達する方法で
あって、受信プロセスが所望するメッセージのメッセージ・タイ
プ（メッセージの種類）に応じた通信チャネル名を作成
するステップと、一端が前記生成された通信チャネル名を有する受信プロ
セスで終端し、各々の送信プロセスに選択的に接続可能
であり、前記コンピュータ・システムのオペレーティン
グ・システムにより管理される通信チャネルを生成する
ステップと、各々の受信プロセスによって所望される各々のメッセー
ジ・タイプ毎に、前記作成するステップと生成するステ
ップを繰り返すステップと、送信プロセスによって送られるメッセージのメッセージ
・タイプに応じた送信通信チャネル名を前記送信プロセ
スによって作成するステップと、前記送信通信チャネル名を有する前記コンピュータ・シ
ステム内で生成された全ての通信チャネルに対する接続
を開放するステップと、前記送信プロセスにより、各々の開放された通信チャネ
ルにメッセージを書込むステップと、各々の開放された通信チャネルが終端である受信プロセ
スにより、前記開放された通信チャネルから前記メッセ
ージを読取るステップとを含み、前記チャネルを生成し、開放し、書込みかつ読取るステ
ップは前記プロセスによるシステム機能呼出しに応答し
て前記オペレーティング・システムにより実行され、与
えられるメッセージタイプに応じて、前記コンピュータ
・システムの各々のプロセスが通信チャネル名を個別に
作成するメッセージ送受信プロセス間のメッセージ伝達
方法。
【請求項２】前記通信チャネルを生成するステップに続
いて、受信プロセスをメッセージを待つ所定の状態にす
るステップを含む請求項１のメッセージ送受信プロセス
間のメッセージ伝達方法。
【請求項３】前記受信プロセスを所定の状態にするステ
ップは受信プロセスによるシステム機能呼出しに対応し
て前記オペレーティング・システムにより実行され、前
記チャネルの一端を受信プロセスで終端し、そして前記
オペレーティング・システムが送信プロセスからのチャ
ネル・オープン機能呼出しの受入れに対して待機するス
テップを更に含む請求項２のメッセージ送受信プロセス
間のメッセージ伝達方法。
【請求項４】前記通信チャネルを介してメッセージの送
信に応答してシステム・セマフォアにより前記受信プロ
セスに警告するステップを更に含む請求項２又は請求項
３のメッセージ送受信プロセス間のメッセージ伝達方
法。
【請求項５】受信プロセスにより前記チャネルから読取
る前記ステップは、警告された後、システム機能呼出し
に応答する毎に、前記チャネルからメッセージ情報ブロ
ックを空のブロックを受取るまで読取るステップを更に
含む請求項４のメッセージ送受信プロセス間のメッセー
ジ伝達方法。
【請求項６】メッセージ送信プロセスとメッセージ受信
プロセスの間でメッセージを伝達する、オペレーティン
グ・システムを有するコンピュータ・システムの機構で
あって、受信プロセスが所望するメッセージのメッセージ・タイ
プ（メッセージの種類）に応じた通信チャネル名を作成
する手段と、一端が前記生成された通信チャネル名を有する受信プロ
セスで終端し、各々の送信プロセスに選択的に接続可能
であり、前記コンピュータ・システムのオペレーティン
グ・システムにより制御される通信チャネルを生成する
手段と、各々の受信プロセスによって所望される各々のメッセー
ジ・タイプ毎に、前記作成する手段と生成する手段を繰
り返す手段と、送信プロセスによって送られるメッセージのメッセージ
・タイプに応じた送信通信チャネル名を前記送信プロセ
スによって作成する手段と、前記送信通信チャネル名を有する前記コンピュータ・シ
ステム内で生成された全ての通信チャネルに対する接続
を開放する手段と、前記送信プロセスにより、各々の開放された通信チャネ
ルにメッセージを書込む手段と、各々の開放された通信チャネルが終端である受信プロセ
スにより、前記開放された通信チャネルから前記メッセ
ージを読取る手段とを含み、前記チャネルを生成し、開放し、書込みかつ読取る手段
は前記プロセスによるシステム機能呼出しに応答して前
記オペレーティング・システムの制御下で実行され、与
えられるメッセージ・タイプに応じて、前記コンピュー
タ・システムの各々のプロセスが通信チャネル名を個別
に作成するメッセージ送受信プロセス間のメッセージ伝
達機構。
【請求項７】受信プロセスが、送信プロセスが後のメッ
セージをそのチャネルを使用して送信できるようにする
ために、受信プロセスが、先のメッセージを受信したの
ち前記チャネルをリセットする手段を更に備える請求項
６のメッセージ送受信プロセス間でメッセージを伝達す
る機構。