JPH076139A - リモートプロシジャコールシステム - Google Patents

Abstract

(57)【要約】 【目的】 リモートプロシジャコールがネスト形式にな
っている場合、エラーを発見したノードが、最初の要求
元と途中のノードに直接エラー報告することにより、関
連する資源をいち早く解放しようとするものである。 【構成】 アプリケーション２からプロシジャの要求を
ＲＰＣシステム３に出すと、その要求を他ノードへ転送
する。この時、ネットワークアドレス情報転送装置４
は、どのＲＰＣ処理に関係したかを示すネットワークア
ドレス情報をその要求先に送る。エラーが発生した場合
は、直接エラー送受信装置５がネットワークアドレス情
報転送装置４が保持している全てのアドレス先のノード
へ直接エラー報告を行う。直接エラー送受信装置５が、
直接エラーを受信するとＲＰＣ処理装置３を介してアプ
リケーション２にエラーを通知する。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は、情報の分散処理技術に
係り、特に分散しているシステムが他のシステムと通信
するためのリモートプロシジャコール（以下、ＲＰＣと
記す）システムに関するものである。

【０００２】

【従来の技術】従来のＲＰＣの技術は、処理を要求する
側（クライアント）と処理を実行する（サーバ）間の１
対１の関係でのみ実現された技術であり、クライアント
が実行要求（コール）し、サーバが結果を返す（リター
ン）ものである。

【０００３】これらのＲＰＣの従来技術についてはエイ
・シ・エム・トランザクション・オン・コンピュータ・
システムズ ボリューム２．ナンバー１（１９８４年２
月）第３９ページから５９ページ（ACM Transaction on
Computer Systems, Vol.2,NO.1, February 1984、 Pag
e39-59）、プレンティスホール社(PRENTICE HALL)が出
版したエーティアンドティ ユニックス システム フ
ァイブ リリース４プログラマーズガイド：ネットワー
キング インタフェース(AT&T UNIX SYSTEMV REREAS E4
Programmer's Guide:Networking Interfaces)及びＬザ
ーン著ネットワーク コンピューティング アーキテク
チャ（１９９１年）(L.Zahn Network Computing Archit
ecture 1991)で論じられている。

【０００４】従来技術でプロシジャコールのネストの場
合の処理は、１対１のＲＰＣ技術の組み合わせである。

【０００５】このような従来技術におけるプロシジャコ
ールのネストの場合のエラー処理を図１２に示す。ノー
ド１ｘはノード１ｙへの処理要求２２ｙを出し、ノード
１ｙは、ノード１ｚへの処理要求２２ｚを出す。ここ
で、ノード１ｚがエラーを検知した場合、ノード１ｚ
は、ノード１ｙへエラー報告２３ｚを送り、ノード１ｙ
が、ノード１ｘへエラー報告２３ｙを送る処理となる。

【０００６】そして、アプリケーションプログラム２
ｙ，２ｚを介し、エラー報告を行い、システム資源２１
ｙ，２１ｚを解放している。

【０００７】

【発明が解決しようとする課題】しかし、従来のＲＰＣ
の技術において、リモートプロシジャコールがネストの
形式になっている場合のエラーの報告は、途中のノード
を順々に経由して要求元のノードに送られるため、要求
元のノードの待ち時間が長くなり、要求元及び途中のノ
ードのシステム資源の開放がすぐにできないという問題
点がある。

【０００８】本発明の目的は、エラー時におけるＲＰＣ
処理に関するシステム資源の保持時間を短縮させること
である。

【０００９】

【課題を解決するための手段】前記の目的を達成するた
めに、プロシジャコールがネストする場合、ノードはプ
ロシジャ要求（以下、ＲＰＣ要求と記す）が経由した全
てのＲＰＣシステムのあるノードのネットワーク上のア
ドレス等の情報を持つネットワークアドレス関連情報の
リストを作成する手段と、前記ネットワークアドレス情
報リストを次のＲＰＣをコールするノードに渡す手段
と、要求処理中にエラーが発生したときに、ネットワー
クアドレス関連情報リスト先全てのノードにエラーを報
告する手段を設ける。

【００１０】また、前記手段にアプリケーションエラー
を報告する手段を設ける。

【００１１】

【作用】前記手段によれば、経由した全てのＲＰＣシス
テムのあるノードヘアドレス情報のリストを処理の要求
と共に転送し、エラーが発生したときにそのアドレス情
報のリストに記載されているノード全てにエラー報告を
行うようすることにより、エラー時におけるＲＰＣ処理
に関するシステム資源の保持時間を短縮させることが可
能になる。

【００１２】そして、アプリケーションエラーもアプリ
ケーションが関数をコールすることにより、ＲＰＣシス
テムにエラーを報告できる。

【００１３】

【実施例】以下、本発明の実施例を図面により詳細に説
明する。

【００１４】図１は本実施例のＲＰＣシステムの構成を
示すブロック図である。

【００１５】図１に示すようにノード１は、アプリケー
ションプログラム２、ＲＰＣシステム３、ネットワーク
インタフェース９から構成されている。

【００１６】そして、ＲＰＣシステム３は、ネットワー
クアドレス生成及び転送部４、直接エラー送受信部５、
アプリケーションエラー伝達部６、データ処理部７、プ
ロトコル処理部８からなる。

【００１７】次に、図２、図３を用い、本実施例のＲＰ
Ｃシステムのエラー時の処理動作を説明する。

【００１８】図２は、ノード１ａがノード１ｂに処理を
要求２２ａし、更にノード１ｂが、他のノード１ｃに処
理を要求２２ｂし、また更にノード１ｃがノード１ｄに
処理を要求する場合の例を示したものである。

【００１９】図３は、要求元のノードが生成するリモー
トプロシジャコール制御情報を示したものである。

【００２０】ＲＰＣ制御情報は、ＲＰＣ要求の場合のプ
ロトコルのデータ形式を表しており、先頭からこのプロ
トコルの形式のパケット種別３１、ＲＰＣバージョン情
報３２、要求の識別子３３、転送するネットワークアド
レス関連情報リスト３４からなる。

【００２１】要求の識別子３３は、要求を識別する２０
桁くらいの英数字の組み合わせからなるもので、図２の
要求元ノード１ａが生成する。要求元ノード１ａからＲ
ＰＣ要求を受けたノード１ｂのネットワークアドレス生
成及び転送部４は、ノード１ａのアドレス関連情報をネ
ットワークアドレス関連情報リスト３４に追記する。

【００２２】ノード１ｂのＲＰＣシステムは、これらの
情報と共にＲＰＣ要求２２ｂの内容をノード１ｃへ送
る。

【００２３】ノード１ｃが、更にＲＰＣの要求２２ｃを
ノード１ｄに行う場合も前記同様な処理でノード１ｂの
アドレスをネットワークアドレス関連情報リスト３４に
追記してノード１ｄへＲＰＣ要求する。この場合、要求
の識別子３３は、ノード１ａで生成したものと同じ値で
ある。また、プロシジャのネストが続く限り同様な処理
を続ける。

【００２４】ここで、ノード１ｄでエラーが発生した際
には、エラーを検知したノード１ｄの直接エラー送受信
部５が、ネットワークアドレス関連情報リスト３４に格
納されている全てのノードに対し、エラー報告を送る。
この場合、同じ要求の識別子３３を持つプロシジャに対
しエラーが通知される。

【００２５】この時送るエラーのプロトコルのデータ形
式を図４に示す。エラー報告のプロトコルのデータは、
エラー報告パケット３１ｂ、ＲＰＣバージョン情報３２
及び要求の識別子３３からなるＲＰＣ制御情報３０であ
る。

【００２６】このエラーを受け取った各ノード１ａ，１
ｂ，１ｃの直接エラー送受信部５は、ＲＰＣを発行した
アプリケーションプログラム２ａ，２ｂ，２ｃに対し、
エラー通知を行い、システム資源２１ａ，２１ｂ，２１
ｃを解放する。

【００２７】各ノード上のアプリケーションプログラム
２ヘのエラー通知方法には、エクセプション（例外通
知）として送る方法及びリターンコードにエラーをセッ
トする方法などがある。

【００２８】エクセプションで通知した場合、アプリケ
ーションプログラム２のエクセプションハンドラールー
ティンが対応する処理を行う。

【００２９】リターンコードを返す場合は、アプリケー
ションプログラム２がそのリターンコードを受信するこ
とでプロシジャが終了する。その後、このリターンコー
ドを後処理の目的に使用できる。

【００３０】また、アプリケーションエラーが発生した
場合には、アプリケーションエラーの発生をアプリケー
ションエラー伝達部６に通知するための通知関数を新た
に定義する。この通知関数は、正常に動作を行っている
ときは、一定の値が通知され、アプリケーションエラー
時には、違った値が通知される。

【００３１】したがって、アプリケーションエラー時に
アプリケーションプログラムがこのエラー通知関数をコ
ールすることにより、アプリケーションエラー伝達部６
にエラーの発生を報告する。

【００３２】そして、アプリケーションエラー伝達部６
は、直接エラー送受信部５を介し、前述と同様に、関連
するノードにエラー通知を行うことを要請する。

【００３３】次に、図５に示すようにＲＰＣが並行して
２つ以上のノードをコールした場合のエラー処理につい
て述べる。

【００３４】図５は、要求元ノード１ｅからＲＰＣの要
求２２ｄを受けたノード１ｆから、更にノード１ｇ、ノ
ード１ｉに対して同時にＲＰＣの要求２２ｅ、２２ｇを
行い、更にノード１ｇ、１ｉは、それぞれノード１ｈ、
１ｊに対してＲＰＣの要求２２ｆ、２２ｈを行った場合
の例を示したものであり、ここで、ノード１ｈにてエラ
ーが発生したとする。

【００３５】要求元ノード１ｅで生成されたネットワー
クアドレス関連情報リスト３４には、要求元ノード１ｅ
からエラーが発生したノード１ｈまで経由したノードの
アドレスが書き込まれている。このリストより、前述同
様に、ノード１ｈからノード１ｅ、１ｆ、１ｇへ直接エ
ラー報告２３ｄ、２３ｅ、２３ｆを送る。

【００３６】ここで、分岐したＲＰＣの要求２２ｇを出
したノード１ｆがエラー報告を受けた時には、ノード１
ｉに対してＲＰＣの処理のキャンセルの要求５０ａを出
す。そして、このキャンセルの要求５０ａを受けたノー
ド１ｉは、ＲＰＣの要求２２ｈを出したノード１ｊに対
して、キャンセルの要求５０ｂを出す。

【００３７】このキャンセルの要求のデータ形式を図６
に示す。キャンセルの要求は、キャンセル要求パケット
３１ｃ、ＲＰＣバージョン情報３２及び要求の識別子３
３からなるＲＰＣ制御情報３０である。

【００３８】キャンセルの要求は、ノード内で同じ要求
の識別子を持つプロシジャがそのコール先へ出す。ま
た、この分岐先のノードでＲＰＣがネストしている場合
は、キャンセル要求を先へ先へと出す。

【００３９】したがって、前述の図２の例と同様に、Ｒ
ＰＣのエラー時に全ての関連する資源を比較的早く開放
できるようになる。

【００４０】また、従来の方式と本発明のエラーリター
ン方式の採用の選択は、アプリケーションプログラムの
コンパイル時に指定したり、コマンド等により指定でき
るようにすることにより、従来方式と本発明の方式を双
方利用できる。

【００４１】次に、本実施例の処理手順について、図７
から図１１のフローチャートを用い説明する。

【００４２】まず、図７で最初の要求元のノードの処理
手順を示す。ＲＰＣでアプリケーションからＲＰＣシス
テムに要求が来ると、最初の要求元ノードのネットワー
クアドレス生成及び転送部４は、要求の識別子３３及び
経由ノードのネットワークアドレス情報リスト３４を生
成する（ステップ７０１，７０２）。そして、ネットワ
ークアドレス情報リストカウンター３４ｄに、０をセッ
トする（ステップ７０３）。

【００４３】以上３つの生成物を図３に示すようなプロ
トコルのデータ形式に代入（ステップ７０４）し、他の
ノードへこのプロトコルを送る（ステップ７０５）。

【００４４】次に、途中のノードの処理手順を図９に示
す。図３に示すようなプロトコルデータを受け取ったノ
ードは、他のノードへプロシジャを更にコールしている
かどうかを判断し（ステップ８０１）、コールしていな
い場合は、アプリケーションの実行結果を返す。他のノ
ードに対して、ＲＰＣの要求をしている場合は、ＲＰＣ
の要求元のノードから送られてきた経由ノードのネット
ワークアドレス関連情報リスト３４に要求元のネットワ
ークアドレスを追記し（ステップ８０２）、ネットワー
クアドレスリストカウンター３４ｄに１を加える（ステ
ップ８０３）。そして、プロトコルデータを他ノードへ
送出する（ステップ８０４）。これをＲＰＣの要求を行
った全てのノードに対して行う。

【００４５】そして、エラーを検知したノードの処理手
順を図９に示す。エラーがアプリケーションエラーであ
るか判断し（ステップ９０１）、アプリケーションのエ
ラーの場合は、アプリケーションプログラム２が、アプ
リケーションエラーを直接返す関数を発行（ステップ９
０２）し、それをアプリケーションエラー伝達部が受け
取る。ＲＰＣシステムエラーの場合は、ＲＰＣシステム
が検知する。

【００４６】そして、ネットワークアドレスリストカウ
ンター３４ｄの値を判定する（ステップ９０３）。

【００４７】リストカウンタ３４ｄの値が”０”の場合
は、エラー報告を要求元ノードに行い、”０”でない場
合は、ネットワークアドレス情報リスト３４からネット
ワークアドレス情報を１つ取り込む（ステップ９０
４）。

【００４８】そして、図４に示すようなプロトコルのデ
ータ形式に要求の識別子３３を代入し、ネットワークア
ドレス関連情報リスト３４にあるノードへ送出し（ステ
ップ９０５）、ネットワークアドレスリストカウンタ３
４ｄから１を引き（ステップ９０６）、同様の処理をネ
ットワークアドレスリストカウンタ３４ｄが”０”にな
るまで行い、”０”になると処理が終了する。

【００４９】次に、図４で示した形式のプロトコルを受
信したノードの処理手順を図１０に示す。エラー直接送
受信部５は、アプリケーションプログラム２にＲＰＣで
エラーがあったことを報告する（ステップ１００１）。
そして、ＲＰＣシステム３が他のノードに要求を出して
いるかどうかをを判定する（ステップ１００２）。

【００５０】要求を出している場合は、図６に示すよう
なプロトコルのデータ形式に要求の識別子３３を代入し
て、要求先に図６に示すキャンセルを通知するプロトコ
ルを送出（ステップ１００３）する。要求を出していな
い場合は、処理を終了する。

【００５１】最後に、図６で示した形式のプロトコルを
受信したノードの処理手順を図１１に示す。プロトコル
のキャンセルの要求を受信するとＲＰＣで要求された処
理をキャンセルする（ステップ１１０１）。そして、他
のノードに要求を出しているかを判定する（ステップ１
１０２）。

【００５２】要求を出している場合は、図６に示すプロ
トコルのデータ形式に要求の識別子３３を代入し、要求
先に図６に示すキャンセルを通知するプロトコルを送出
する（ステップ１１０３）。要求を出していない場合
は、処理を終了する。

【００５３】以上、説明したように、経由した全てのＲ
ＰＣシステムのあるノードヘアドレス情報のリストをＲ
ＰＣの要求とともに転送し、エラーが発生したときにそ
のアドレス情報のリストに記載されているノード全てに
エラー報告を行うようすることにより、エラー発生時に
要求元のＲＰＣの待ち時間が短くなり、経由ノードのＲ
ＰＣの待ち時間が短縮されるので、ＲＰＣに関係する資
源がいち早く解放されることにより、ＲＰＣ処理の全体
の性能向上の効果がある。

【００５４】

【発明の効果】以上説明したように、本発明によれば、
エラー発生時に要求元のＲＰＣの待ち時間が短くなり、
経由ノードのＲＰＣの待ち時間が短縮されるので、ＲＰ
Ｃに関係する資源がいち早く解放されることにより、Ｒ
ＰＣ処理の全体の性能向上の効果がある。

【００５５】また、アプリケーションのエラー時にアプ
リケーションプログラムがこのエラー通知関数をコール
することにより、エラーの報告ができる。

【図面の簡単な説明】

【図１】本発明の一実施例のＲＰＣシステムの構成を示
すブロック図である。

【図２】本実施例のＲＰＣシステムのエラー時の処理動
作を説明するための図である。

【図３】本実施例のプロシジャ要求のプロトコルのデー
タ形式を示した図である。

【図４】本実施例のエラーを報告するプロトコルのデー
タ形式を示した図である。

【図５】本実施例の分岐ノードを含むＲＰＣシステムの
エラー時の処理動作を説明するための図である。

【図６】本実施例のキャンセル要求のプロトコルのデー
タ形式を示した図である。

【図７】本実施例の最初の要求元ノードの処理手順を示
したフローチャートである。

【図８】本実施例の途中のノードの処理手順を示したフ
ローチャートである。

【図９】本実施例のエラーを検知したノードの処理手順
を示したフローチャートである。

【図１０】本実施例のエラーを直接受けたノードの処理
手順を示したフローチャートである。

【図１１】本実施例のキャンセルを受けたノードの処理
手順を示したフローチャートである。

【図１２】従来のＲＰＣシステムのエラー時の処理動作
を説明するための図である。

【符号の説明】

１…ノード、２…アプリケーションプログラム、３…Ｒ
ＰＣシステム、４…ネットワークアドレス生成及び転送
部、５…直接エラー送受信部、６…アプリケーションエ
ラー伝達部、７…データ処理部、８…プロトコル処理
部、９…ネットワークインタフェース、２１…資源、２
２…ＲＰＣ要求、２３…エラー報告、３０…ＲＰＣ制御
情報、３１…パケット種別、３２…ＲＰＣバージョン情
報、３３…要求の識別子、３４…ネットワークアドレス
情報リスト、４０…データ、５０…キャンセル要求。

Claims (2)

【特許請求の範囲】
1. 【請求項１】 分散している別のシステムのプロシジャ
   をコールするリモートプロシジャコールシステムにおい
   て、別のシステムによってプロシジャをコールされたシ
   ステムが、更にまた別システムへのプロシジャ要求を行
   うというプロシジャコールがネストする際に、プロシジ
   ャ要求が経由したリモートプロシジャコールシステムが
   設置されている全てのノードのネットワーク上のアドレ
   ス等の情報を持つネットワークアドレス関連情報のリス
   トを作成する手段と、前記ネットワークアドレス情報リ
   ストを次のＲＰＣをコールするノードに渡す手段と、要
   求処理中にエラーが発生したときに、ネットワークアド
   レス関連情報リスト先全てのノードにエラーを報告する
   手段とを設けたことを特徴とするリモートプロシジャコ
   ールシステム。
2. 【請求項２】 前記請求項１に記載されているリモート
   プロシジャコールシステムにおいて、アプリケーション
   エラーを報告する手段を設けたことを特徴とするリモー
   トプロシジャコールシステム。