JPH06139170A

JPH06139170A - 分散処理システム

Info

Publication number: JPH06139170A
Application number: JP4285674A
Authority: JP
Inventors: Satoru Murata; 悟村田; Takanori Yokoyama; 孝典横山; Masaru Shimada; 優島田; Masahiko Saito; 雅彦齊藤; Tomoaki Nakamura; 智明中村
Original assignee: Hitachi Ltd
Current assignee: Hitachi Ltd
Priority date: 1992-10-23
Filing date: 1992-10-23
Publication date: 1994-05-20

Abstract

(57)【要約】【目的】本発明は分散処理システムに関し、特に信頼
性，リアルタイム性に優れた通信機能を持つ分散処理シ
ステムを提供することにある。【構成】計算機２００内に、アプリケーションプログラ
ムモジュール２５１の実行状態と通信状態を記憶するメ
ッセージ情報記憶領域２３１とメッセージ情報記憶領域
の情報を用いてアプリケーションプログラムモジュール
２５１の通信を管理する通信管理プログラム２２１とメ
ッセージに付加された処理実行順序制御情報に従ってメ
ッセージを取り出すメッセージインターフェースプログ
ラム２４１を設ける。【効果】実行状態と通信状態の情報を転送することによ
り、通信状態を維持したままでアプリケーションプログ
ラムモジュールの計算機間移動を行うことができる。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は分散処理システムに関
し、信頼性，リアルタイム性に優れた通信機能を提供す
る分散処理システムに関するものである。

【０００２】

【従来の技術】分散処理システムは、複数の計算機を通
信回線で結合し、これらの計算機内にプログラムモジュ
ールを配置し、各プログラムモジュールが通信を行いな
がら処理を進めるシステムである。プログラムモジュー
ル間で送受信される情報をメッセージと呼ぶ。

【０００３】分散処理システムにおいては、通信の信頼
性が重要である。ところが、一般に、送信元プログラム
モジュールは、受信先プログラムモジュールが存在して
いるか、受信先プログラムモジュールがメッセージ受信
可能な状態であるか、メッセージが受信先プログラムモ
ジュールへ到達したか、メッセージに対応する処理が実
行されたかを何らかの通信を行うことなしに確認するこ
とはできない。

【０００４】このような分散処理システムにおいては、
通信の信頼性が重要となる。まず、受信先プログラムモ
ジュールが存在しメッセージ受信可能である場合に、メ
ッセージが到達したことを確認する必要がある。このよ
うな、メッセージの到達確認を行う通信をメッセージの
信頼性のある通信と呼ぶ。

【０００５】次に、メッセージの到達を確認したうえで
該メッセージに対応する処理が実行されたかを確認する
必要がある場合がある。このような、処理の実行確認を
行う通信を処理の信頼性のある通信と呼ぶ。

【０００６】さらに、受信先プログラムモジュールは、
あるメッセージの処理を実行中に他のメッセージを受信
することが可能でなければならない。なぜなら、メッセ
ージの送信に失敗した場合、送信元プログラムモジュー
ルは、失敗した原因が受信先プログラムモジュールが存
在しなかったためなのか受信先プログラムモジュールが
他のメッセージの処理を実行中だったためなのかを判断
することができない。このような、受信先プログラムモ
ジュールがあるメッセージの処理を実行中に他のメッセ
ージを受信することが可能な通信を受信の信頼性のある
通信と呼ぶ。

【０００７】また、メッセージに優先度等の処理実行優
先順位情報を付加し、受信側プログラムモジュールが該
処理実行優先順位情報に従ってメッセージの処理を実行
していくことをリアルタイム性のある通信と呼ぶ。

【０００８】さらに、分散処理システムにおいては、プ
ログラムモジュールが計算機間移動を行う可能性があ
る。他プログラムモジュールとの通信状態を維持したま
まで計算機間移動を行うことが可能な通信を移動透過な
通信と呼ぶ。

【０００９】［従来技術１］メッセージの信頼性のある
通信には、メッセージの送受信の際にメッセージ以外の
情報を送受信することによって、メッセージの到達確認
を行う方式がある。このような通信方式として、プレン
ティス・ホール社（Prentice-Hall，Inc）刊インターネ
ットワーキング・ウィズ・ティー・シー・ピー／アイ・
ピー，プリンシプルズ，プロトコルズ，アンド・アーキ
テクチャ（１９８８年）（Ｉｎｔｅｒｎｅｔｗｏｒｋｉ
ｎｇｗｉｔｈＴＣＰ／ＩＰ，ｐｒｉｎｃｉｐｌｅ
ｓ，ｐｒｏｔｏｃｏｌｓａｎｄａｒｃｈｉｔｅｃｔ
ｕｒｅ（１９８８））に記述された方法があり、その例
の実現法として、アジソン・ウェスリー社（Ａｄｄｉｓ
ｏｎ−ＷｅｓｅｌｙＰｕｂｌｉｓｈＣｏｍｐａｎ
ｙ）刊ザ・デザイン・アンド・インプリメンテーション
・オブ・ザ・４.３ビー・エス・ディー・ユニックス・
オペレーティング・システム（１９８９年）（The Desi
gn and Implementation ofthe ４.３BSD UNIX Operatin
g System(１９８９））(ユニックス（ＵＮＩＸ）は、ユ
ニックス・システム・ラボラトリー社（UNIX System La
boratories，Inc.）が開発しライセンスしているオペレ
ーティングシステムです）に記述された方法が知られて
いる。

【００１０】［従来技術２］メッセージの信頼性と処理
の信頼性および受信の信頼性のある通信方式として、処
理要求メッセージ送信から処理終了通知までの間、処理
の実行状況に関する情報を送受信することによって処理
の実行を確認するプレンティス・ホール社（Prentice-H
all，Inc）刊ネットワーク・コンピューティング・アー
キテクチャ（１９９０年）（Network Computing Archit
ecture (１９９０））およびプレンティス・ホール社
（Prentice-Hall，Inc）刊ネットワーク・コンピューテ
ィング・システム・リファレンス・マニュアル（１９８
９年）（Network Computing System Reference Manual
(１９８９)）に記述された方式が知られている（ネット
ワーク・コンピューティング・アーキテクチャ（Networ
k Computing Architecture（ＮＣＡ））及びネットワー
ク・コンピューティング・システム（Network Computin
g System（ＮＣＳ））はヒューレット・パッカード社
（Hewlett Packard Company）の商標です）。

【００１１】［従来技術３］受信の信頼性とリアルタイ
ム性のある通信を実現する方法として、優先度が付加さ
れた複数のメッセージを保存するメッセージキューを備
える特開平2−113362号に記述されている方法が知られ
ている。

【００１２】［従来技術４］メッセージの信頼性と受信
の信頼性のある通信とを実現する方法として、複数の処
理実行部にメッセージを割り振ることによって複数のメ
ッセージを受付可能とするプレンティス・ホール社（Pr
entice-Hall，Inc）刊ユニックス・ネットワーク・プロ
グラミング（１９９０年）（UNIX Network Programming
(１９９０))に記述されたコンカレントサーバー方式が
知られている。

【００１３】

【発明が解決しようとする課題】従来技術１は、メッセ
ージの信頼性のある通信を実現しているが、１つのメッ
セージを受信中はメッセージ受信のための資源が独占さ
れてしまうため、他のメッセージを受信することができ
ない。つまり、受信の信頼性がないという問題点があ
る。

【００１４】従来技術２は、メッセージの信頼性と処理
の信頼性および受信の信頼性のある通信を実現している
が、受信の信頼性に関して、実行される処理が副作用の
ない処理（データが加工されない処理）に限られるとい
う問題点がある。また、メッセージの実行優先順位を指
定することができないので、リアルタイム性がないとい
う問題点がある。

【００１５】従来技術３は、従来技術１とともに用いる
ことにより、メッセージの信頼性と受信の信頼性および
リアルタイム性のある通信を実現できるが、メッセージ
の実行状態情報はスケジューリング手段内に記憶されメ
ッセージ転送手段は該実行状態情報を知りえないため、
処理の信頼性のある通信を実現することができないとい
う問題点がある。

【００１６】従来技術４は、従来技術１とともに用いる
ことにより、メッセージの信頼性と受信の信頼性のある
通信を実現できるが、複数の処理実行部が同一の資源を
必要としている場合や要求されている処理が副作用のあ
る処理である場合には、それぞれの処理代行部間におい
て、排他制御，実行順序制御，データの一貫性制御等を
行う必要があり、処理実行部のプログラムが複雑になる
という問題点がある。さらに、複数の処理代行部を動的
に生成・消去するためのオーバーヘッドにより、処理の
実行効率が低下するという問題点がある。

【００１７】また、従来技術１から４のいづれの技術
も、移動透過ではないという問題点がある。

【００１８】本発明は、上記に鑑みてなされたもので、
プログラムモジュール内の処理記述を複雑にすることな
く、また、副作用のあるなしに関わらず、メッセージの
信頼性，処理の信頼性，受信の信頼性を可能とすること
を目的とする。また、これらの信頼性に加えてリアルタ
イム性のある通信を同時に可能とすることも目的とす
る。また、移動透過な通信を可能とすることも目的とす
る。

【００１９】

【課題を解決するための手段】上記目的を達成するため
に、本発明では、通信路により接続された複数の計算機
上に存在する複数のプログラムモジュールが、メッセー
ジを送受信しながら処理を進める分散処理システムにお
いて、各計算機に、プログラムモジュールの依頼を受け
てメッセージの送受信を行い、その際にメッセージの実
行状態や通信状態を表す管理情報を送受信することによ
り通信状態を管理する通信管理手段と、該計算機上のプ
ログラムモジュールに対して送られてきたメッセージを
該メッセージの実行状態情報と通信状態情報の管理情報
とともに複数記憶することのできるメッセージ情報記憶
手段とを設ける。また、メッセージに付加された処理実
行優先順位情報に従って、該メッセージ情報記憶手段内
からメッセージを取りだし、プログラムモジュールへ渡
すメッセージ取りだし手段を設ける。

【００２０】

【作用】本発明においては、メッセージ情報記憶手段内
にメッセージの実行状態情報を記憶することによって、
通信管理手段が、該実行状態情報を得ることを可能と
し、これにより処理の信頼性のある通信を可能とする。
また、メッセージ情報記憶手段内に複数のメッセージお
よびメッセージに関する情報を記憶することにより、信
頼性のある通信を行いながら複数のメッセージをうけつ
けることを可能とする。さらに、メッセージに処理実行
優先順位情報を付加し、メッセージ取りだし手段が該実
行優先順位情報に従ってメッセージをとりだすことによ
りリアルタイム性のある通信を可能とする。また、プロ
グラムモジュールが計算機間を移動する際に、メッセー
ジ情報記憶手段内に記憶されている情報を移動元通信管
理手段から移動先通信管理手段へ送信し、移動先通信管
理手段が移動元通信管理手段の通信状態を引き継ぐこと
により、移動透過な通信を可能とする。

【００２１】

【実施例】

（１）本発明の一実施例以下、本発明の一実施例を図を用いて詳細に説明する。

【００２２】まず、本発明の一実施例の概要を図１を用
いて説明する。本実施例では、計算機２００がネットワ
ーク１００に接続されており、計算機２００内に、ネッ
トワーク１００とのデータ送受信を行うネットワークア
ダプタ２０１と、計算を実行するプロセッサ２０２と、
プログラムやデータが格納されるメモリ２０３が存在す
る。

【００２３】メモリ２０３上にはオペレーティングシス
テム（ＯＳ）と呼ばれる基本ソフトウェア２１１が存在
し、これをプロセッサ２０２が読みだして実行すること
により、メモリ２０３上に存在するアプリケーションプ
ログラムモジュール２５１やメッセージインタフェース
プログラム２４１，通信管理プログラム２２１等の各種
プログラムの実行スケジューリングを行う。

【００２４】オペレーティングシステム２１１はネット
ワークアダプタ２０１の制御を行い、メモリ２０３上の
各種プログラムに対してネットワーク１００に対する入
出力等のサービスを提供している。ネットワーク１００
に対する入出力サービスには計算機指定の１対１通信と
ネットワーク１００に接続されているすべての計算機に
対する同報通信とがある。ネットワークアダプタ２０１
はネットワーク１００上を流れる信号の受信、プロセッ
サ２０２への通知、プロセッサ２０２からの指示により
信号をネットワーク１００へ送信を行う。

【００２５】また、通信管理プログラム２２１はアプリ
ケーションプログラムモジュール２５１のメッセージ通
信を管理する。メッセージインタフェイスプログラム24
1は、アプリケーションプログラムモジュール２５１の
実行状態を監視し、アプリケーションプログラムモジュ
ール２５１に対しメッセージ送受信サービスを提供す
る。

【００２６】ここで、メッセージインターフェースプロ
グラム２４１は、アプリケーションプログラムモジュー
ル２５１に対して関数呼出しの形のインターフェースを
提供しており、アプリケーションプログラムモジュール
間の通信は、遠隔手続き呼出しの形式となっている。

【００２７】またメモリ２０３上には、アプリケーショ
ンプログラムモジュール２５１に対して送られてきたメ
ッセージを該メッセージの実行状態情報と通信状態情報
とともに複数記憶するメッセージ情報記憶領域２３１が
存在する。

【００２８】本実施例においては、プログラムモジュー
ル間で送受信されるメッセージには、他プログラムモジ
ュールに処理を依頼する処理要求メッセージ、他プログ
ラムモジュールから依頼された処理の結果を返送する処
理結果メッセージ、プログラムモジュールの計算機間移
動の際にメッセージ情報記憶領域内の情報を転送する転
送メッセージ情報の３通りがある。

【００２９】本実施例においては、通信管理プログラム
間で送受信される情報は、すべて、図２に示すパケット
という形式で送受信される。

【００３０】図２は、本実施例で用いるパケットの形式
を示している。本実施例においては、パケット３００
は、一定の最大長を持ち、通信管理情報は１パケットに
収まる大きさである。１パケットに収まりきれない大き
さのメッセージは、複数のパケットに分割されて送信さ
れることになる。

【００３１】ここでいう通信管理情報とはメッセージを
構成するパケットに対する受信確認情報，処理状況の問
い合わせ情報，処理状況が処理実行中であることを示す
実行中情報，処理の終了情報，処理終了情報を受信した
ことを通知する終了確認情報，エラーが発生したことを
示すエラー情報等である。

【００３２】図２に示すように、パケット３００は、タ
イプフィールド３０１，属性フィールド３０２，通信タ
イプフィールド３０３，受信先識別番号フィールド３０
４，送信元識別番号フィールド３０５，要求番号フィー
ルド３０６，通し番号フィールド３０７，最後尾フラグ
フィールド３０８，優先度フィールド３０９，データフ
ィールド３１０から構成される。

【００３３】タイプフィールド３０１は、処理要求メッ
セージを構成するパケット，処理結果メッセージを構成
するパケット，転送メッセージを構成するパケット，メ
ッセージ以外の情報であるパケットを区別するために用
いられる。属性フィールド３０２は、メッセージを構成
するパケット，メッセージを構成するパケットに対する
受信確認パケット，処理状況の問い合わせパケット，処
理状況が処理実行中であることを示す実行中パケット，
処理が終了したことを示す処理終了パケット，処理終了
パケットを受信したことを通知する終了確認パケット，
エラーが発生したことを示すエラーパケットを区別する
ために用いられる。通信タイプフィールド３０３は、メ
ッセージの処理終了確認を行うか否かを示す。本実施例
では、通信タイプとして、メッセージを構成する全ての
パケットが正しく受信されたことを確認する受信確認通
信と、受信確認を行った後に該メッセージの処理実行終
了を確認する終了確認通信の２通りがある。受信先識別
番号フィールド３０４は、受信先プログラムモジュール
を一意に表し、メッセージ情報記憶領域内に複数のプロ
グラムモジュール宛のメッセージを記憶する場合に、メ
ッセージインターフェースプログラムがメッセージを渡
すべきプログラムモジュールを識別するために用いられ
る。送信元識別番号フィールド３０５は、送信元プログ
ラムモジュールを一意に表す番号が格納され、要求番号
フィールドは、各送信元プログラムモジュールが処理要
求メッセージ毎に一意に割り振った通し番号が格納され
る。送信元識別番号フィールド３０５と要求番号フィー
ルド３０６は、通信管理プログラムがメッセージを一意
に識別するために用いられる。通し番号フィールド３０
７は、メッセージが複数のパケットから構成される場合
に個々のパケットに一意に割り振られた番号で、通信管
理プログラムがメッセージの個々のパケットを識別する
ために用いられる。最後尾フラグフィールド３０８は、
メッセージを構成するパケットの最後尾パケットを示
し、通信管理プログラムが全てのパケットを受信したこ
とを確認するために用いられる。優先度フィールド３０
９は、メッセージの実行の優先度を示し、メッセージイ
ンターフェースプログラムがメッセージ情報記憶領域か
らメッセージを取り出す際に、優先度を用いたメッセー
ジ実行順序制御を行うために用いられる。データフィー
ルド３１０は、該パケットがメッセージを構成するパケ
ットである場合はメッセージ本体を格納し、該パケット
がエラーパケットである場合はエラーコードを格納する
領域である。

【００３４】図３は、本実施例のメッセージ情報記憶領
域内に記憶される情報であるエントリのフォーマットを
示す図である。

【００３５】エントリ４００は、メッセージタイプフィ
ールド４０１，実行可能フラグ402,実行状態フラグフィ
ールド４０３，終了通知フラグ４０４，受信パケット番
号フィールド４０５，優先度フィールド４０６，受信先
識別番号フィールド４０７，送信元識別番号フィールド
４０８，送信元通信アドレスフィールド４０９，先頭パ
ケット格納番地フィールド４１０，最後尾パケット格納
番地フィールド４１１，次エントリ格納番地フィールド
４１２から構成される。

【００３６】メッセージタイプフィールド４０１は、通
信管理プログラムにより設定され、該エントリに対応す
るメッセージが処理要求メッセージであるか処理結果メ
ッセージであるかを示す。転送メッセージ実行可能フラ
グ４０２は、通信管理プログラムにより設定され、該エ
ントリに対応するメッセージを構成するパケットが全て
揃った場合に実行可能、それ以外の場合に実行不可とな
る。実行状態フラグ４０３は、メッセージインターフェ
ースプログラムにより設定され、該エントリに対応する
メッセージの処理が未実行であるか実行中であるか実行
終了後であるかを示す。終了通知フラグ４０４は、通信
管理プログラムにより設定され、該エントリに対応する
メッセージの処理終了通知が必要であるか否かを示す。
受信パケット番号フィールド４０５は、通信管理プログ
ラムがパケットが正しい順序で受信されたかを判断する
ために用いられる。優先度フィールド４０６は、メッセ
ージに付加された優先度を示し、メッセージインターフ
ェースプログラムがメッセージを取り出す際に、優先度
を用いたメッセージ実行順序制御を行うために用いられ
る。受信先識別番号フィールド４０７は、通信管理プロ
グラムによって設定され、メッセージインターフェース
プログラムがメッセージを渡すべきアプリケーションプ
ログラムモジュールを調べる際に用いられる。送信元識
別番号フィールド４０８は、通信管理プログラムによっ
て設定され、メッセージインターフェースプログラムに
よってアプリケーションプログラムモジュールに渡され
る。送信元通信アドレスフィールド４０９は、メッセー
ジ送信元の通信管理プログラムの通信アドレスを示し、
送信元通信管理プログラムとパケット送受信を行う際に
用いられる。先頭パケット格納番地フィールド４１０
は、該エントリに対応するメッセージの先頭パケットを
記憶している領域の番地を保存する。最後尾パケット格
納番地フィールド４１１は、該エントリに対応するメッ
セージの最後尾のパケットを記憶している領域の番地を
保存する。次エントリ格納番地フィールド４１２は、次
のメッセージに関するエントリの格納番地を保存する。

【００３７】通信管理プログラムの動作を、通信管理プ
ログラムの処理を表すフローチャートである図４，図
５，図６，図７，図８，図９，図１０，図１１を用いて
説明する。

【００３８】図４は、通信管理プログラムの処理のおお
まかな流れを示している。通信管理プログラムは、パケ
ットの到着またはメッセージインターフェースプログラ
ムからのメッセージパケット送信要求またはメッセージ
インタフェースプログラムからのメッセージ処理終了通
知またはメッセージインターフェースプログラムからの
アプリケーションプログラムモジュール移動通知の待ち
状態に入る(５０１)。（５０１）において、アプリケー
ションプログラムモジュールによるメッセージ処理終了
通知を受け取ると、終了処理（５１０）を行い、再び待
ち状態(５０１)に戻る。（５０１）において、メッセー
ジインターフェースプログラムからのメッセージパケッ
ト送信要求を受け取ると、送信処理（５２０）を行い、
再び待ち状態（５０１）に戻る。（５０１）において、
パケットが到着すると、受信処理（５３０）を行い、再
び待ち状態（５０１）に戻る。（５０１）において、メ
ッセージインターフェースプログラムからのアプリケー
ションプログラムモジュール移動通知を受け取ると、転
送処理（５４０）を行い、再び待ち状態（５０１）に戻
る。

【００３９】図５は、終了処理（５１０）の処理の流れ
を示している。通信管理プログラムは、終了処理を開始
すると、まず、メッセージ情報記憶部のエントリの中で
実行状態フラグが実行終了となっているエントリを探し
該エントリの終了通知フラグを調べる（５１１）。（５
１１）において、終了通知フラグが不要となっている場
合は、該エントリをメッセージ情報記憶部から削除し
（５１７）、終了処理を終了する。（５１１）におい
て、終了通知フラグが必要となっている場合は、処理終
了パケットを送信してタイマーを設定し（５１２）、パ
ケットが到着するのを待つ（５１３）。待ち状態（５１
３）において、パケットが到着した場合、該パケットが
終了確認パケットであるかを調べ（５１５）、終了確認
パケットであれば、該エントリをメッセージ情報記憶部
から削除し（５１７）、終了処理を終了する。（５１
５）において、該パケットが終了確認パケットでない場
合は、受信処理（５３０）を行い、再び待ち状態（５１
３）に戻る。待ち状態（５１３）において、タイマーの
時間切れによるタイムアウトが発生した場合、処理終了
パケット送信回数を１増加し（５１４）、処理終了パケ
ット送信回数が設定値を越えたかを調べる（５１６）。
（５１６）において、処理終了パケット送信回数が設定
値を越えていれば、該エントリをメッセージ情報記憶部
から削除し(５１７）、終了処理を終了する（処理終了
パケット送信打切り）。（５１６）において、処理終了
パケット送信回数が設定値を越えていなければ、（５１
２）に戻り、処理終了パケットの再送信を行う。

【００４０】図６は、送信処理（５２０）の処理の流れ
を示している。通信管理プログラムは、送信処理を開始
すると、メッセージパケットを送信しタイマーを設定し
（５２１）、パケットが到着するのを待つ（５２２）。
待ち状態（５２２）において、パケットが到着した場
合、該パケットが受信確認パケットであるかを調べ（５
２６）、受信確認パケットであれば、メッセージを構成
するすべてのパケットの送信が終了したかを調べる（５
２７）。（５２７）において、メッセージを構成するす
べてのパケットを送信したのであれば、終了確認処理
（５４０）を行い、送信処理を終了する。（５２７）に
おいて、まだ送信していないパケットが存在する場合
は、メッセージパケット送信回数をクリアし（５２
８），（５２１)に戻り、次のメッセージパケットの送
信を行う。（５２６）において、該パケットがエラーパ
ケットであれば、送信エラーをメッセージインターフェ
ースプログラムへ通知し（５２５）、送信処理を終了す
る。（５２６）において、該パケットが受信確認パケッ
ト，エラーパケットのいずれでもない場合は、受信処理
（５３０）を行い、待ち状態（５２２）に戻る。待ち状
態（５２２）において、タイマーの時間切れによるタイ
ムアウトが発生した場合、メッセージパケット送信回数
を１増加し（５２３）、メッセージパケット送信回数が
設定値を越えたかを調べ（５２４）、設定値を越えてい
れば、メッセージインターフェースプログラムに送信エ
ラーを通知し（５２５）、設定値を越えていなければ、
（５２１）に戻り、メッセージパケットの再送信を行
う。

【００４１】図７は、終了確認処理（５５０）の流れを
示している。通信管理プログラムは、終了確認処理を開
始すると、該メッセージの処理の終了確認が必要か否か
を調べる（５５１）。（５５１）において、終了確認が
不要であれば、終了確認処理を終了する。（５５１）に
おいて、終了確認が必要であれば、タイマーを設定し
（５５２）、処理終了確認パケットを待つ（５５３）。
待ち状態（５５３）において、パケットが到着した場
合、該パケットの種類を調べる（５５６）。（556)にお
いて、該パケットが実行中パケットである場合、問い合
わせパケット送信回数をクリアし（５５７），（５５
２）に戻る。（５５６）において、該パケットがエラー
パケットである場合、メッセージインターフェースプロ
グラムへ送信エラーを通知し（５５９）、終了確認処理
を終了する。（５５６）において、該パケットが処理終
了パケットであれば、終了確認パケットを送信し(５５
８)、終了確認処理を終了する。（５５６）において、
該パケットが実行中パケット，エラーパケット，処理終
了パケット以外のパケットである場合は、受信処理(５
３０)を行い、待ち状態（５５３）に戻る。待ち状態
（５５３）において、タイマーの時間切れによるタイム
アウトが発生した場合、問い合わせパケットを送信して
問い合わせパケット送信回数を１増加し（５５４）、問
い合わせパケット送信回数が設定値を越えたかを調べる
（５５５）。（５５５）において、問い合わせパケット
送信回数が設定値を越えていれば、メッセージインター
フェースプログラムへ送信エラーを通知し（５５９）、
終了確認処理を終了する。（555)において、問い合わせ
パケット送信回数が設定値を越えていなければ、(５５
２)に戻る。

【００４２】図８は、受信処理（５３０）の流れを示し
ている。通信管理プログラムは、受信処理を開始する
と、受信したパケットがメッセージパケットであるかそ
の他のパケットであるかを調べる（５３１）。（５３
１）において、パケットがメッセージパケットであれ
ば、メッセージ情報記憶領域内に該パケットに該当する
エントリが存在するかを調べる（５３２）。（５３２）
において、メッセージ情報記憶領域内に該当するエント
リが存在しなければ、該パケットがメッセージを構成す
る先頭パケットであるかを調べる（５３３）。（５３
３）において、先頭パケットであれば、メッセージ情報
記憶部内にエントリを作成する（５３４）。ここで、該
パケットに対応するメッセージが転送メッセージであれ
ば、該メッセージのエントリを再構成し、処理要求メッ
セージまたは処理結果メッセージであれば、新しいエン
トリを作成する。エントリの作成が終了すると、該パケ
ットの保存処理（５７０）を行い、受信処理を終了す
る。（５３３）において、該パケットが先頭パケットで
なければ、該パケットの送信元へエラーパケットを送信
し（５３５）、受信処理を終了する。（５３２）におい
て、メッセージ情報記憶部内に該当するエントリが存在
する場合は、該パケットが既に受信したパケットである
かを調べ（５３６）、既に受信したパケットであれば、
受信確認パケットを送信し（５３８）、受信処理を終了
する。（５３６）において、該パケットが既に受信した
パケットでなければ、該パケットの通し番号とエントリ
の受信パケット番号を用いて該パケットが正しい順序で
受信されたかを調べ（５３７）、正しければ、保存処理
（５６０）を行い、受信処理を終了する。（５３７）に
おいて、該パケットの受信順序が正しくなければ、エラ
ーを送信し（５３５）、受信処理を終了する。（５３
１）において、パケットがメッセージ以外のパケットで
あれば、その他の処理（５６０）を行い、受信処理を終
了する。

【００４３】図９は、その他の処理（５６０）の流れを
示している。通信管理プログラム２２１は、その他の処
理を開始すると、受信したパケットが問い合わせパケッ
トであるかエラーパケットであるかを調べる（５６
１）。（５６１）において、該パケットが問い合わせパ
ケットであれば、メッセージ情報記憶部内に該当するエ
ントリが存在するかを調べ（５６３）、該当するエント
リが存在しなければ、キャッシュにアプリケーションプ
ログラムモジュールの移動先が保存されているかを調べ
る（５６７）。（５６７）において、キャッシュに移動
先が保存されていれば、該問い合わせパケットを移動先
へ転送し（５６８）、その他の処理を終了する。（５６
７）において、移動先が保存されていない場合、エラー
パケットを送信し（５６６）、その他の処理を終了す
る。（５６３）において、該当するエントリが存在すれ
ば、該エントリの実行可能フラグが実行可能であるかを
調べる（５６４）。（５６４）において、実行可能フラ
グが実行可能であれば、実行中パケットを送信し（５６
５）、その他の処理を終了する。（５６４）において、
実行可能フラグが実行不可であれば、エラーパケットを
送信し（５６６）、その他の処理を終了する。

【００４４】図１０は、保存処理（５７０）の流れを示
している。通信管理プログラム221は、保存処理を開始
すると、受信確認パケットを送信して保存すべきパケッ
トを保存し（５７１）、メッセージを構成する全てのパ
ケットがそろったかを調べる（５７２）。（５７２）に
おいて、全てのパケットがそろっていなければ、保存処
理を終了する。（５７２）において、全てのパケットが
そろっていれば、該パケットを保存したエントリの実行
可能フラグを実行可能に設定し（５７３）、該エントリ
のメッセージが処理結果メッセージまたはエラーメッセ
ージであるかを調べる（５７４）。（５７４）におい
て、該エントリのメッセージが処理結果メッセージまた
はエラーメッセージであれば、メッセージインターフェ
ースプログラム２４１に該メッセージが到着したことを
通知し（５７５）、保存処理を終了する。（５７４）に
おいて、該エントリのメッセージが処理結果メッセー
ジ，エラーメッセージのいずれでもない場合（処理要求
メッセージである場合）、保存処理を終了する。

【００４５】図１１は、転送処理（５４０）の流れを示
している。通信管理プログラム221は、転送処理を開始
すると、アプリケーションプログラムモジュールの移動
先をキャッシュし（５４１）、転送メッセージを設定し
（５４２）、移動先宛に送信する（５２０）。ここで、
送信処理（５２０）は、メッセージの受信確認のみを行
う。送信処理（５２０）が終了すると、該メッセージの
エントリを削除し、未だ転送されていないメッセージが
残っているかを調べる（５４４）。（５４４）におい
て、未転送のメッセージが存在すれば、（５４２）に戻
り転送を行う。

【００４６】（５４４）において、未転送のメッセージ
が残っていない（移動したアプリケーションプログラム
モジュールへのメッセージを全て転送した）場合、転送
処理を終了する。

【００４７】メッセージインターフェースプログラム２
４１の動作を、メッセージインターフェースプログラム
２４１の処理のフローチャートである図１２，図１３，
図１４，図１５を用いて説明する。

【００４８】図１２は、メッセージインターフェースプ
ログラム２４１の処理のおおまかな流れを示している。
メッセージインターフェースプログラム２４１は、処理
を開始すると、メッセージ情報記憶領域２３１に実行可
能な処理要求メッセージが存在するかを調べ（６０
１）、実行可能な処理要求メッセージが存在しなけれ
ば、（６０１）へ戻り、実行可能な処理要求メッセージ
が存在すれば、該処理要求メッセージをメッセージ情報
記憶領域２３１から取りだし、アプリケーションプログ
ラムモジュール２５１へ渡す。この時、メッセージ情報
記憶領域２３１に、実行可能な処理要求メッセージが複
数存在する場合は、エントリの優先度フィールドを参照
し、優先度が最も高い処理要求メッセージを取り出す。
処理要求メッセージをアプリケーションプログラムモジ
ュール２５１へ渡した後、メッセージインターフェース
プログラム２４１は、アプリケーションプログラムモジ
ュール２５１の処理終了、アプリケーションプログラム
モジュール２５１からの要求、通信管理プログラム２２
１からの通知のいずれかの待ち状態（６０３）となる。
（６０３）において、アプリケーションプログラムモジ
ュール２５１の処理が終了した場合、終了処理（６１
０）を行い、（６０１）へ戻る。（６０３）において、
アプリケーションプログラムモジュール２５１からの要
求があった場合、要求処理（６２０）を行い、（６０
３）に戻る。（６０３）において、通信管理プログラム
２２１からの通知があった場合、通知処理（６３０）を
行い、(６０３)へ戻る。

【００４９】図１３は、メッセージインターフェースプ
ログラム２４１の終了処理(６１０)の流れを示してい
る。メッセージインターフェースプログラム２４１は、
終了処理（６１０）を開始すると、アプリケーションプ
ログラムモジュール２５１の処理が正常終了であるかエ
ラーが生じたかを調べ（６１１）、エラーが生じていた
場合、エラーメッセージパケットを作成し、通信管理プ
ログラムに送信要求を送り（６１２）、通信管理プログ
ラムに処理終了を通知し（６１３）、終了処理を終了す
る。（６１１）において、正常終了であった場合、通信
管理プログラムに処理終了を通知し（６１３）、終了処
理を終了する。

【００５０】図１４は、メッセージインターフェースプ
ログラム２４１の要求処理(６２０）の流れを示してい
る。メッセージインターフェースプログラム２４１は、
要求処理を開始すると、アプリケーションプログラムモ
ジュール２５１からの要求がメッセージ送信要求である
か結果取りだし要求であるかを調べ（６２１）、メッセ
ージ送信要求であれば、該メッセージをメッセージパケ
ットへ変換し（６２２)、送信要求を通信管理プログラ
ムへ通知し（６２３）、要求処理を終了する。

【００５１】（６２１）において、アプリケーションプ
ログラムモジュール２５１からの要求が結果取りだし要
求である場合、該アプリケーションプログラムモジュー
ル251が要求している結果の受信通知を受けたかを調べ
（６２４）、受信通知を受けていた場合は、処理結果メ
ッセージをメッセージ情報記憶領域２３１から取りだし
てアプリケーションプログラムモジュール２５１へ渡し
（６２５）、要求処理を終了する。（６２４）におい
て、結果受信通知を受けていない場合、アプリケーショ
ンプログラムモジュール２５１からの結果取りだし要求
がブロック型であるかを調べ（６２６）、ブロック型で
ある場合、結果受信通知の待ち状態に入る（６２７）。
（６２６）において、アプリケーションプログラムモジ
ュール251からの結果取りだし要求がブロック型でない
場合、要求処理を終了する。ここで、ブロック型の結果
取りだし要求とは、処理結果メッセージが受信されるま
でアプリケーションプログラムモジュール２５１が処理
の実行を中断して待つ要求である。

【００５２】図１５は、メッセージインターフェースプ
ログラム２４１の通知処理(６３０)の流れを示してい
る。メッセージインターフェースプログラム２４１は、
通知処理を開始すると、通信管理プログラム２２１から
の通知が結果受信通知であるかエラー通知であるかを調
べ（６３１）、結果受信通知であれば、処理結果メッセ
ージが到着したことを記録し（６３２）、通知処理を終
了する。（６３１）において、エラー通知であれば、メ
ッセージ情報記憶領域２３１からエラーメッセージをと
りだしてアプリケーションプログラムモジュール２５１
へ渡し(６３３)、通知処理を終了する。

【００５３】図１６は、本発明の一実施例の動作例の概
要である。図１６は、あるアプリケーションプログラム
モジュール２５１から遠隔手続き呼出しの処理を実行中
のアプリケーションプログラムモジュール２５１に対
し、２つのアプリケーションプログラムモジュール２５
１が遠隔手続き呼出しを行った場合の動作を示してい
る。ここで、処理を実行するをサーバー，遠隔手続き呼
出しを行う２つのアプリケーションプログラムモジュー
ル２５１をそれぞれ、クライアント１，クライアント２
と呼ぶ。また、サーバー，クライアント１，クライアン
ト２のそれぞれに対応する通信管理プログラム２２１お
よびメッセージインターフェースプログラム２４１の処
理をまとめて通信管理機構と呼ぶ。図１６において、７
１０は、クライアント１の動作を表すタイムチャート、
７２０は、クライアント２の動作を表すタイムチャー
ト、７３０は、通信管理機構の動作を表すタイムチャー
ト、740は、サーバーの動作を表すタイムチャートであ
る。クライアント１は、優先度０のメッセージである処
理１要求メッセージの送信要求を通信管理機構に送り
（７１１）、処理１結果待ちとなる（７１２）。通信管
理機構内において、処理１要求メッセージは、クライア
ント１に対応する通信管理プログラムからサーバーに対
応する通信管理プログラム２２１へ送信される。サーバ
ーに対応する通信管理プログラムが処理１要求メッセー
ジを受信した時点では、サーバーは処理０を実行中（７
４１）であるので、サーバーに対応する通信管理プログ
ラム２２１は、処理１要求メッセージをサーバーに対応
するメッセージ情報記憶領域２３１に保存する。クライ
アント２は、優先度１のメッセージである処理２要求メ
ッセージの送信要求を通信管理機構に送り（７２１）、
処理２結果待ちとなる（722)。処理２要求メッセージ
は、クライアント２に対応する通信管理プログラムから
サーバーに対応する通信管理プログラム２２１へ送信さ
れる。サーバーに対応する通信管理プログラム２２１が
処理２要求メッセージを受信した時点では、サーバーは
処理０を実行中（７４１）であるので、サーバーに対応
する通信管理プログラム２２１は、処理２要求メッセー
ジをサーバーに対応するメッセージ情報記憶領域２３１
に保存する。サーバーにおける処理０の実行（７４１）
が終了すると、サーバーは、処理０結果を通信管理機構
へ渡す（７４２）。通信管理機構は、処理０結果を配送
し（７３１）、次にサーバーが処理すべき処理要求メッ
セージとして、処理１要求メッセージ７１１と処理２要
求メッセージ７２１とのなかから優先度の高いメッセー
ジである処理２要求メッセージを取り出し、サーバーへ
渡す（７３２）。サーバーにおける処理２の実行（７４
３）が終了すると、サーバーは、処理２結果を通信管理
機構へ渡す（７４４）。通信管理機構は、処理２結果を
クライアント２へ配送し、次にサーバーが処理すべき処
理要求メッセージとして、処理１要求メッセージを取り
出し、サーバーへ渡す（７３４）。クライアント２は、
処理２結果メッセージ７３３を受け取ると、次の処理へ
進む。サーバーにおける処理１の実行（７４５）が終了
すると、サーバーは、処理１結果を通信管理機構へ渡す
（７４６）。通信管理機構は、処理１結果をクライアン
ト１へ配送し、次の処理要求メッセージを待つ（７３
５）。

【００５４】図１７は、図１６における通信管理機構の
うち、通信管理プログラム２２１の詳細な動作を示して
いる。クライアント１の通信管理プログラムは、処理１
要求メッセージパケット８０１を送信し、受信確認パケ
ット待ちとなる。サーバーの通信管理プログラムは、処
理１要求メッセージパケット８０１を受信すると、受信
確認パケット８０２を送信する。クライアント１の通信
管理プログラム２２１は、受信確認パケット８０２を受
信すると、タイマーを設定し、タイムアウトが発生する
度に処理状況問い合わせパケットを送信する。ここで、
クライアント１とは独立に、クライアント２の通信管理
プログラム２２１は、処理２要求メッセージパケット８
１４を送信し、受信確認パケット待ちとなる。サーバー
の通信管理プログラム２２１は、処理２要求メッセージ
パケット８１４を受信すると、受信確認パケット８１５
を送信する。クライアント２の通信管理プログラム２２
１は、受信確認パケット８１５を受信すると、タイマー
を設定し、タイムアウトが発生する度に処理状況問い合
わせパケットを送信する。サーバーの通信管理プログラ
ム２２２１は、クライアント１およびクライアント２か
らの処理状況問い合わせパケット８０３，８０５，８０
７，８０９，８１６を受信すると、それぞれに対して実
行中パケット８０４，８０６，８０８，８１０，８１７
を送信する。クライアント１およびクライアント２は、
実行中パケットを受信すると、タイマーを再設定する。
サーバーの通信管理プログラム２２１は、サーバーから
渡された処理２の結果を処理２結果メッセージパケット
８１８として送信する。クライアント２の通信管理プロ
グラムは、処理２結果メッセージパケット８１８を受信
すると、受信確認パケット８１９を送信する。サーバー
の通信管理プログラム２２１は、サーバーによる処理２
の実行が終了すると、処理終了パケット８２０を送信す
る。サーバーの通信管理プログラム２２１は、サーバー
から渡された処理１の結果を処理１結果メッセージパケ
ット８１１として送信する。クライアント１の通信管理
プログラム２２１は、処理１結果メッセージパケット８
１１を受信すると、受信確認パケット８１２を送信す
る。サーバーの通信管理プログラム２２１は、サーバー
による処理２の実行が終了すると、処理終了パケット８
１３を送信する。このように、サーバーの通信管理プロ
グラム２２１は、複数のクライアントからの遠隔手続き
呼出しを受付けることができる。

【００５５】（２）本発明の一実施例の効果以上のように、本発明の一実施例によれば、メッセージ
情報記憶領域２３１に複数のメッセージを該メッセージ
の実行状態情報と通信状態情報とともに記憶することに
より、メッセージの信頼性のある通信，処理の信頼性の
ある通信，受信の信頼性のある通信を行うことが可能に
なるという効果がある。

【００５６】本発明の一実施例では、複数のメッセージ
の送受信に関する処理を通信管理プログラム２２１が行
うため、アプリケーションプログラムモジュール２５１
のプログラム内に通信に関する細かい記述をする必要が
なくなり、アプリケーションプログラムモジュール２５
１のプログラムが簡潔になるという効果がある。

【００５７】本発明の一実施例では、通信管理プログラ
ム２２１に対して通信タイプを指定することにより、メ
ッセージの受信確認のみを行う通信と処理の実行を確認
する通信を選択することができ、処理の内容に応じた柔
軟な通信を行うことができるという効果がある。

【００５８】本発明の一実施例では、メッセージに優先
度を付加し、優先度の高い順にメッセージを処理するこ
とによりリアルタイム性のある通信を行うことが可能と
なるという効果がある。

【００５９】本発明の一実施例では、アプリケーション
プログラムモジュール２５１が計算機間移動を行う場
合、該アプリケーションプログラムモジュール２５１宛
のメッセージを該メッセージの通信状態を維持したまま
で、移動元通信管理プログラム・移動先通信管理プログ
ラム間で転送することにより、信頼性の高い通信を維持
したままアプリケーションプログラムモジュールの計算
機間移動が可能となるという効果がある。

【００６０】本発明の一実施例では、メッセージの転送
処理を通信管理プログラム２２１間で行うことにより、
アプリケーションプログラムモジュール２５１における
計算機間移動処理が簡潔になるという効果がある。

【００６１】本発明の一実施例では、メッセージインタ
ーフェースプログラム２４１とアプリケーションプログ
ラムモジュール２５１のインターフェースを関数呼出し
の形にすることにより、信頼性，リアルタイム性のある
遠隔手続き呼出しを実現することができるという効果が
ある。

【００６２】本発明の一実施例では、サーバーが複数の
クライアントからの遠隔手続き呼出しを記憶することに
より、１つのサーバーに対しての複数のクライアントか
らの遠隔手続き呼出しを取こぼすことなく処理すること
ができるため、信頼性の高いクライアント・サーバー・
システムを構成することができるという効果がある。本
発明の一実施例では、遠隔手続き呼出しに優先度を付加
することにより、リアルタイム性のある遠隔手続き呼出
しを実現することが出来るという効果がある。

【００６３】（３）本発明の他の実施例上記本発明の一実施例では、メッセージに付加する実行
優先順位情報として優先度を用いていたが、メッセージ
に付加する実行優先順位情報として、処理終了期限を示
すタイムスタンプを用いてもよい。これにより、処理終
了期限が近い順にメッセージを処理することができると
いう効果がある。

【００６４】上記本発明の一実施例では、メッセージに
付加する実行優先順位情報として優先度を用いていた
が、メッセージに付加する実行優先順位情報として、処
理終了期限を示すタイムスタンプと優先度の両方を用い
てもよい。これにより、優先度と処理終了期限の両方を
考慮した、より柔軟な処理実行優先順位を行うことが可
能になるという効果がある。

【００６５】上記本発明の一実施例では、通信管理手段
とメッセージ取りだし手段は、オペレーティングシステ
ム２１１の外部に存在していたが、これらをオペレーテ
ィングシステム２１１の一部として実現してもよい。こ
の場合、メッセージ取りだし手段が、アプリケーション
プログラムモジュール２５１の実行スケジューリングを
行うことにより、分散リアルタイムオペレーティングシ
ステムを構築することが可能となるという効果がある。

【００６６】上記本発明の一実施例では、アプリケーシ
ョンプログラムモジュール２５１とメッセージ情報記憶
領域２３１が１対１に対応していたが、メッセージ情報
記憶領域２３１に複数のアプリケーションプログラムモ
ジュールに関するメッセージを記憶してもよい。これに
より、メッセージ情報記憶領域２３１に必要なメモリ容
量を低く抑さえながら信頼性のある通信を可能とするこ
とができるという効果がある。

【００６７】上記本発明の一実施例では、アプリケーシ
ョンプログラムモジュール２５１と通信管理プログラム
２２１とがそれぞれ１対１に対応していたが、１つのア
プリケーションプログラムモジュール２５１に複数の通
信管理プログラム２２１を対応させてもよい。これによ
り、１つのアプリケーションプログラムが複数のアプリ
ケーションプログラムにメッセージを送信しながら複数
のアプリケーションプログラムからのメッセージを受信
することができるという効果がある。

【００６８】上記本発明の一実施例では、１つの通信管
理プログラム２２１がメッセージの送信と受信を行って
いたが、メッセージ送信用の通信管理プログラム２２１
とメッセージ受信用の通信管理プログラム２２１とに分
けて構成してもよい。これにより、それぞれのプログラ
ムが簡潔になるという効果がある。

【００６９】本発明の一実施例では、メッセージインタ
ーフェースプログラム２４１が関数呼出しの形のインタ
ーフェースを提供していたが、処理要求メッセージ，処
理結果メッセージを明示的に送信する形のインターフェ
ースを提供してもよい。これにより、メッセージ通信型
のアプリケーションを実現できるという効果がある。

【００７０】

【発明の効果】本発明によれば、メッセージの信頼性の
ある通信，処理の信頼性のある通信，受信の信頼性のあ
る通信を実現できるという効果がある。

【００７１】本発明によれば、アプリケーションプログ
ラムの処理記述を複雑にすることなく、信頼性のある通
信を実現できるという効果がある。

【００７２】本発明によれば、メッセージに処理実行順
序制御情報を付加することによって、信頼性のある通信
に加えてリアルタイム性のある通信を行うことが可能と
なるという効果がある。

【００７３】本発明によれば、アプリケーションプログ
ラム間の信頼性のある通信状態を維持したままでアプリ
ケーションプログラムの計算機間移動を実現することが
できるという効果がある。

【００７４】本発明によれば、アプリケーションプログ
ラムの処理記述を複雑にすることなく、アプリケーショ
ンプログラムの計算機間移動が可能となるという効果が
ある。

【図面の簡単な説明】

【図１】本発明の一実施例の構成を示す図である。

【図２】本発明の一実施例のパケットフオーマットを示
す図である。

【図３】本発明の一実施例のメッセージ情報記憶領域内
のエントリを示す図である。

【図４】本発明の一実施例の通信管理プログラムの処理
の概要を示す図である。

【図５】本発明の一実施例の通信管理プログラムの終了
処理を示す図である。

【図６】本発明の一実施例の通信管理プログラムの送信
処理を示す図である。

【図７】本発明の一実施例の通信管理プログラムの終了
確認処理を示す図である。

【図８】本発明の一実施例の通信管理プログラムの受信
処理を示す図である。

【図９】本発明の一実施例の通信管理プログラムのその
他の処理を示す図である。

【図１０】本発明の一実施例の通信管理プログラムの保
存処理を示す図である。

【図１１】本発明の一実施例の通信管理プログラムの転
送処理を示す図である。

【図１２】本発明の一実施例のメッセージインターフェ
ースプログラムの処理の概要を示す図である。

【図１３】本発明の一実施例のメッセージインターフェ
ースプログラムの終了処理を示す図である。

【図１４】本発明の一実施例のメッセージインターフェ
ースプログラムの要求処理を示す図である。

【図１５】本発明の一実施例のメッセージインターフェ
ースプログラムの通知処理を示す図である。

【図１６】本発明の一実施例の一動作例を示す図であ
る。

【図１７】本発明の一実施例の一動作例の通信管理プロ
グラムの動作を示す図である。

【符号の説明】

１００…ネットワーク、２００…計算機、２０１…ネッ
トワークアダプタ、２０２…プロセッサ、２０３…メモ
リ、２１１…ＯＳ、２２１…通信管理プログラム、２３
１…メッセージ情報記憶領域、２４１…メッセージイン
ターフェースプログラム、２５１…アプリケーションプ
ログラムモジュール。

───────────────────────────────────────────────────── フロントページの続き (72)発明者齊藤雅彦茨城県日立市久慈町4026番地株式会社日立製作所日立研究所内 (72)発明者中村智明茨城県日立市大みか町五丁目２番１号株式会社日立製作所大みか工場内

Claims

【特許請求の範囲】

【請求項１】通信路に接続された複数の計算機上に存在
するプログラムモジュールがメッセージを送受信しなが
ら処理を進める分散処理システムにおいて、計算機に、プログラムモジュールからの依頼を受けてメ
ッセージの送受信を行う際メッセージ及び通信管理情報
を送受信する通信管理手段と、複数のメッセージ及びメ
ッセージ毎の通信状態や実行状態を表す状態情報を記憶
するメッセージ情報記憶手段とからなり、該通信管理手
段は該メッセージ情報記憶手段に記憶されたメッセージ
毎の状態情報に基づいて通信管理情報を作成し送受信す
ることにより通信状態を管理することを特徴とする分散
処理システム。
【請求項２】通信路に接続された複数の計算機上に存在
するプログラムモジュールが処理実行優先順位情報を付
加したメッセージを送受信しながら処理を進める分散処
理システムにおいて、計算機に、プログラムモジュールからの依頼を受けてメ
ッセージの送受信を行う際メッセージ及び通信管理情報
を送受信する通信管理手段と、複数のメッセージ及びメ
ッセージ毎の通信状態や実行状態を表す状態情報を記憶
するメッセージ情報記憶手段と、該メッセージ情報記憶
手段内から該メッセージに付加された該処理実行優先順
位情報に従って取り出してプログラムモジュールへ渡す
メッセージ取出手段からなり、該メッセージ情報記憶手
段に記憶されたメッセージ毎の状態情報に基づいて該通
信管理手段が、通信管理情報を作成し送受信することに
より通信状態を管理することを特徴とする分散処理シス
テム。
【請求項３】通信路に接続された複数の計算機上に存在
し、計算機間移動を行う複数のプログラムモジュール
が、メッセージを送受信しながら処理を進める分散処理
システムにおいて、計算機に、プログラムモジュールからの依頼を受けてメ
ッセージの送受信を行う際メッセージ及び通信管理情報
を送受信する通信管理手段と、複数のメッセージ及びメ
ッセージ毎の通信状態や実行状態を表す状態情報を記憶
するメッセージ情報記憶手段とを設け、該プログラムモ
ジュールが計算機間移動を行う際に、該プログラムモジ
ュールに対応する状態情報を移動元通信管理手段から移
動先通信管理手段へ送信することを特徴とする分散処理
システム。
【請求項４】請求項１乃至請求項３のいずれかにおい
て、該通信管理情報は該メッセージの実行状態又は通信
状態を示す情報であることを特徴とする分散処理システ
ム。