JPH10187467A - リモートプロシジャコール処理方法 - Google Patents

Abstract

(57)【要約】 【課題】グループサーバを呼び出すＲＰＣ処理方式にお
いて、グループ構成の変更処理を軽減し、早期検出を可
能にする。 【解決手段】サーバグループ８０にサーバを追加する場
合、グループ構成変更通知部７０からグループ内のサー
バを具備する処理装置、たとえば処理装置５に追加通知
を出す。この通知を受信したＲＰＣ処理部５０は、新た
なプロシジャの追加を通知するグループ構成変更情報を
保持する。ＲＰＣ要求元、たとえば処理装置２のクライ
アント１５は、サーバグループ８０のサーバ２５，３
５，４５へ「ＱＳＯＲＴ」のＲＰＣ要求を発行し、グル
ープ内の対応サーバがそれぞれ実行される。処理装置５
はサーバ４２１を実行して実行結果を要求元に送信する
際に、前記グループ構成変更情報を付加する。要求元の
ＲＰＣ処理部１０は、応答メッセージからグループ構成
の変更を検出すると、アドレス管理部６０からすべての
アドレス情報を呼び出し、自らのアドレス情報を更新す
る。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、分散処理システム
で用いられる通信処理技術、とりわけ依頼応答通信の１
つであるリモートプロシジャコール（以下、ＲＰＣと略
称）の処理技術に係わり、特に、サーバをグループした
構成のシステムにおいて、サーバグループの構成を変更
する方法に関する。

【０００２】

【従来の技術】ＲＰＣは特にクライアント・サーバシス
テムにおける通信技術として定着し、クライアントから
サーバへの１対１の依頼・応答通信を行なうものであ
る。たとえば、複数の情報処理装置がネットワークを介
して相互に接続された分散処理システムにおいて、ある
処理装置内に存在するクライアントが、自分の処理装置
内に存在するプロシジャ呼び出しと同じ手法によって他
の処理装置内に存在するサーバー側が提供するプロシジ
ャを呼び出し、その実行結果を受けとる。代表的なＲＰ
Ｃとしては、ＯＳＦ（Open Software Foundation）のＤ
ＣＥ（DistributedComputing Environment）での採用例
がある。以下では、この例をＤＣＥ／ＲＰＣと呼ぶ。

【０００３】ＤＣＥ／ＲＰＣでは、ディレクトリ・サー
バと呼ばれるアプリケーションサーバが、分散処理シス
テム内に存在するすべてのアドレス情報を管理してい
る。クライアントはこのディレクトリ・サーバに問い合
わせて呼び出したいサーバのアドレス情報を取得し、Ｒ
ＰＣによりこのアドレス情報のサーバを呼び出す。ＤＣ
Ｅ／ＲＰＣでは、新しいサーバを分散処理システム内に
追加する際に、まずディレクトリ・サーバに自分のアド
レス情報を登録して、クライアントがサーバのアドレス
を参照できるようにしている。

【０００４】

【発明が解決しようとする課題】ＤＣＥ／ＲＰＣなど従
来のＰＲＣ処理技術では、クライアントはディレクトリ
・サーバを検索することでしか、新しいサーバの追加を
検出できない。このため、同一処理を行なうサーバをグ
ループ化して多重化サーバとし、クライアントがグルー
プのすべてのサーバにアクセスするような場合（デュア
ル方式の多重化など）、オンラインでのサーバの追加が
困難になる。

【０００５】すなわち、オンラインでの追加には、すべ
てのクライアントが常時ディレクトリ・サーバを検索し
ていることが必要で、ネットワークやディレクトリ・サ
ーバ、さらにはクライアントの負荷が増大してしまうか
らである。この結果、ディレクトリ・サーバへのアクセ
ススループットが低下すると、サーバグループへのＲＰ
Ｃの処理も遅くなる。

【０００６】この場合、ディレクトリ・サーバの検索周
期を長くして負荷の低減をはかると、タイミングにより
あるクライアントは追加サーバを呼び出せ、別のサーバ
は呼び出せないというように、多重化サーバの構成が不
整合となる。たとえば多重化ファイルや多重化データベ
ースが不整合な場合、ＲＰＣ処理ひいてはシステムの信
頼性が著しく低下する。

【０００７】サーバの変更をブロードキャスト通信を用
いて、即座にすべてのクライアントに伝達する方法が考
えられる。このためには、クライアントが常にネットワ
ークからの受信準備をしている必要があり、メモリやマ
シン負荷が増大する。一般に、クライアント・サーバシ
ステムは、クライアント側に比較的処理能力の低い計算
機が用いられることが多く、かかる計算機の負担が大き
い。また、ブロードキャストによる送信は必ず受信され
るという保証がなく、メッセージ抜けが発生したり、ク
ライアントがサーバの変更情報を受信しない可能性があ
る。たとえば、クライアントが動作不能状態の場合に変
更情報は反映されない。

【０００８】本発明の目的は、従来技術の問題点に鑑
み、複数のサーバによるサーバグループの構成の変更
を、負荷を増大させることなくクライアント側が直ちに
検知できるリモートプロシジャコール処理方法あるいは
通信方法を提供することにある。

【０００９】

【課題を解決するための手段】上記の目的は、１つのリ
モートプロシジャコールの要求に対応し、グループ化さ
れた複数のサーバを呼び出すリモートプロシジャコール
処理方法において、前記サーバグループの構成の変更に
際し、追加または削除する変更サーバの変更情報を、前
記サーバグループに所属する任意のサーバが保持し、こ
のサーバが各々のリモートプロシジャコール要求元から
出された実行要求に対応する実行結果を要求元に返すと
きに、前記実行結果に前記変更情報を付加することによ
り達成される。

【００１０】サーバグループの変更はグループの任意の
１つに通知され、それを受け取ったサーバが前記変更情
報を保持し、前記プロシジャの実行結果を応答メッセー
ジとして前記要求元に返す際に前記変更情報を付加す
る。一方、前記要求元は自らが呼び出すサーバグループ
のメンバを前記変更情報に基づいて変更する。

【００１１】前記要求元は、予め自らが呼び出すサーバ
グループのアドレス情報と現在の変更情報を保持してい
て、前記応答メッセージの変更情報と自分の保持する変
更情報を比較し、相違するときに自らのグループ情報を
変更する。

【００１２】または、リモートプロシジャコール要求元
はグループの各サーバに送信する要求メッセージに、各
々のプロシジャ実行要求と、保持している現在の変更情
報を付加し、それを受け取ったサーバが、プロシジャの
実行結果を応答メッセージとして前記要求元に返す際
に、自分の保持する変更情報と前記要求メッセージの変
更情報が相違するとき、グループ構成変更フラグをセッ
トする。前記要求元は応答メッセージに前記変更フラグ
がセットされているとき、自分が呼び出すサーバグルー
プのメンバを変更する。

【００１３】他の発明として、前記サーバグループのメ
ンバの中からリモートプロシジャコール要求元によって
任意に選択した１つのサーバを代表して呼び出し、この
呼び出された代表サーバは自らの処理を実行するととも
に、前記要求元から要求された内容を複製して残りのメ
ンバのサーバを呼び出すリモートプロシジャコール処理
方法において、前記グループ構成の変更の通知を受け取
りその変更情報を保持しているサーバは、前記要求元か
ら前記代表サーバへプロシジャの実行要求が出され、前
記代表サーバから複製の要求内容を転送されたとき、そ
のプロシジャ実行による実行結果に前記変更情報を付加
した応答メッセージを前記代表サーバに返送し、前記代
表サーバは自らが呼び出すサーバグループのメンバを前
記変更情報に基づいて変更することを特徴とする。

【００１４】代表サーバは、メンバの変更を行なったと
き、自らの保持する変更情報を更新し、この変更情報と
グループ内の各サーバの実行結果を含む応答メッセージ
をリモートプロシジャコール要求元に送信する。要求元
は、代表サーバからの応答メッセージの変更情報と自ら
の保持するそれを比較し、相違するときに自らのグルー
プ情報を変更する。

【００１５】上記において、前記サーバグループの任意
の１つにグループ構成の変更が通知される前に、システ
ム内のサーバのアドレスを管理するネームサーバに対し
変更サーバのアドレスを登録または削除し、リモートプ
ロシジャコール要求元あるいは前記代表サーバが前記変
更情報を受け取ったときに、前記ネームサーバからアド
レス情報を取得し、自らが呼び出すサーバグループのメ
ンバを変更することを特徴とする。

【００１６】このサーバグループのメンバを変更する際
に、各サーバが具備するプロシジャの処理内容を識別す
るための識別子に基づいてグループ構成の制約をチエッ
クし、前記メンバ変更の可否を判定する。たとえば、あ
る識別子のグループ内での追加または削除に制限がある
場合、その制限を越える追加または削除を禁止する。

【００１７】上記サーバは、プロシジャとして提供され
るプログラムである。あるいは、実行要求に従い自らの
処理を実行しその結果を要求元に返す、または結果は返
さないプログラムである。

【００１８】本発明の構成によれば、クライアントとサ
ーバ間で行なわれるＲＰＣ処理に、サーバグループの構
成変更を検知して、サーバの変更を自動的に行う機能を
持たせているので、従来ユーザが行っていた、クライア
ントが呼び出し先サーバを変更するために必要な情報の
収集処理や、この情報を全クライアントに反映するタイ
ミングの制御といった処理を自動化できる。

【００１９】これによれば、多重化サーバグループに既
存のサーバと同機能をもつサーバを追加し、多重化サー
バの多重度をオンラインで可変することができる。また
は、前記サーバグループに新規サーバを追加し、前記新
規サーバの追加を検知した各々のリモートプロシジャ要
求元が、このときまで処理要求先としていたサーバと前
記新規サーバのいずれかを新たな処理要求先とするか選
択し、プロシジャ実行側が行う処理を前記グループ内の
サーバ間で負荷分散させることができる。あるいは、前
記サーバグループに新バージョンの新規サーバを追加
し、前記新規サーバの追加を検知した各々のリモートプ
ロシジャ実行要求元が、このときまで処理要求先として
いたサーバの代わりに前記新規サーバを処理要求先とし
て切り替え、オンラインのバージョンアップを行なうこ
とができる。

【００２０】

【発明の実施の形態】以下、本発明の実施の形態を図面
にしたがって詳細に説明する。実施例１は、サーバグル
ープの変更を含むＲＰＣ処理、実施例２はサーバ側に変
更処理を行なわせる代案、実施例３は間接マルチキャス
ト方式による代案を示す。また、実施例４はサーバグル
ープの変更をＲＰＣに代えて依頼応答通信によって処理
する例を示し、各図を通し原則として、同等の要素には
同一の符号を付している。

【００２１】〔実施例１〕図１は、本発明の一実施例
で、ＲＰＣを使用した分散システムの機能ブロック図を
示す。処理装置２〜８は通信媒体１に接続されて、他の
処理装置との間で通信を行う。通信媒体１としては、Ｌ
ＡＮ（Local Area Network）やＷＡＮ（WideArea Netwo
rk）、あるいはWireless（無線）等の通信回線を用い
る。バス型を例に示しているが、二重化バス型、一重ル
ープ型、二重ループ型、リング型などの種々のネットワ
ークを用いることができる。まず、ＲＰＣを使用した分
散システムの構成について説明し、その後グループへの
処理装置の追加を例にして、グループ構成の変更処理を
説明する。

【００２２】処理装置２はクライアントとＲＰＣ処理部
を具備しており、ＲＰＣを用いて他の処理装置に対して
処理の実行を要求する。処理装置３〜６はサーバとＲＰ
Ｃ処理部２０を具備しており、他の処理装置から要求さ
れた処理を実行し、その結果を要求元に返す。処理装置
３〜５はグループ化されて多重化サーバ８０を構成して
いる。

【００２３】処理装置２のクライアント１５は、ユーザ
によって作成、あるいは利用されるユーザプログラム、
アプリケーションプログラム等であり、処理のために必
要な情報の参照を、他の処理装置に提供されているサー
バのプロシジャに要求するものである。クライアント１
５は、サーバのプロシジャの実行を要求する際、ＲＰＣ
要求をＲＰＣ処理部１０に対して発行する。

【００２４】ＲＰＣ処理部１０は、クライアント１５の
ＲＰＣ要求処理を代行する。ＲＰＣ処理部１０はクライ
アント１５から発行されたＲＰＣ要求を受け、他の処理
装置に対し、サーバのプロシジャ実行要求をＲＰＣ要求
メッセージとして送信し、自らが送信したＲＰＣ要求メ
ッセージに対応するプロシジャ実行結果が付されたＲＰ
Ｃ応答メッセージを受信し、要求元のクライアント１５
に返す機能を有する。

【００２５】処理装置３は、ＲＰＣ処理部２０とサーバ
２５とを具備しており、他の処理装置から要求された処
理を実行し、その結果を要求元に返す。ＲＰＣ処理部２
０は、他の処理装置から送信されたＲＰＣ要求メッセー
ジを受信し、実行要求されたサーバのプロシジャを実行
し、その実行結果を付したＲＰＣ応答メッセージを要求
元の処理装置に対して送信する。

【００２６】サーバ２５は、ＲＰＣ処理部２０からの要
求に応じて自らを実行し、その実行結果をＲＰＣ処理部
２０に返すプログラムであって、プロシジャの形で提供
される。サーバ２５は、ユーザにより作成あるいは利用
されるプログラムであって、クライアントの処理に必要
な情報を提供するプログラムである。

【００２７】システム内には、その目的や用途に応じた
複数のサーバが種々に組み合わされて存在する。各々の
サーバには、自身がどのような内容の処理を行うかを示
す処理識別子が付与され、その処理内容が識別される。
処理識別子としては、例えば、サーバが提供するプロシ
ジャのプロシジャ名や、プロシジャを一意に識別するＩ
Ｄ番号などを用いる。図示のサーバ２５は、処理識別子
がそれぞれ「ＱＳＯＲＴ」のサーバ４０１、「ＡＳＯＲ
Ｔ」のサーバ４０２及び「ＢＳＯＲＴ」のサーバ４０３
が含まれている。

【００２８】処理装置４〜６も、処理装置３と同様の構
成であり、それぞれサーバ３５，４５，５５とＲＰＣ処
理部３０，４０，５０を具備する。ＲＰＣ処理部３０、
４０、５０は、ＲＰＣ処理部２０と同様の機能を有す
る。また、サーバ３５はサーバ２５と同様に、サーバ４
１１〜４１３からなる。サーバ４５はサーバ４２１，４
２２と、識別子が「ＣＳＯＲＴ」のサーバ４２３からな
る。さらに、グループ外の処理装置６のサーバ５５に
は、サーバ４５と同じサーバ４３１，４３２及び４３３
が含まれている。

【００２９】処理装置７は、アドレス管理部６０を具備
しており、システム内に存在するサーバを具備している
処理装置３〜６のアドレスを管理している。アドレス管
理部６０は、他の処理装置からの要求に応じて、アドレ
ス情報の追加、削除あるいは参照処理を行い、処理結果
を要求元に返す。

【００３０】処理装置８は、グループ構成変更通知部７
０を具備しており、ユーザからのコマンド入力等によ
り、サーバグループの構成変更すなわちサーバグループ
８０へのサーバの追加あるいは削除の要求を受けつけ、
そのイベントをサーバグループ８０のサーバへ通知す
る。

【００３１】本実施例では、サーバ２５，３５，４５か
らなるサーバグループ８０に対し、サーバ５５を追加す
る変更処理を例に、本発明のリモートプロシジャコール
処理方式を説明する。サーバのグループ化には種々の手
法があるが、本実施例では同一の処理識別子をもつサー
バを１つのグループとして扱う。この場合、同一グルー
プ内のすべてのサーバがまったく同じ処理を行う必要は
なく、図１の例のように処理内容が異なっていてもよ
い。

【００３２】次に、グループ化されたサーバへのＲＰＣ
処理の概要について説明する。クライアント１５は、Ｒ
ＰＣ処理部１０を介し、サーバグループ８０にプロシジ
ャの実行要求を送信する。ただし、ＲＰＣ処理部１０
は、クライアント１５が発行したＲＰＣ要求の内容か
ら、それを処理できるサーバグループとそれに属するサ
ーバを判定し、そのサーバを具備する処理装置すべてに
対してＲＰＣ要求メッセージを送信する。この判定は、
クライアント１５がＲＰＣ処理部１０に対してＲＰＣ要
求を発行した際、クライアント１５から渡された処理識
別子を基に行う。

【００３３】サーバグループ８０内の処理装置のうち、
ＲＰＣ要求メッセージを受け取った各処理装置のＲＰＣ
処理部は、要求された処理の実行可能なサーバを実行
し、その実行結果をＲＰＣ応答メッセージとして要求元
の処理装置２に送信する。要求元のＲＰＣ処理部１０
は、ＲＰＣ要求メッセージを送信した各処理装置からの
ＲＰＣ応答メッセージを受信し、その中から予め決めら
れた論理に基づいて１つのＲＰＣ応答メッセージを選択
し、そこに含まれているサーバの実行結果をクライアン
ト１５に返す。この選択に用いる論理としては、「ラン
ダムに１つを選択する」、「応答内容を基に多数決論理
に基づいて１つを選択する」、「最先着のものを選択す
る」などの論理を用いることができる。

【００３４】次に、各処理装置間で伝送されるＲＰＣメ
ッセージのフォーマットを説明する。図２は、サーバグ
ループの構成変更を通知するＲＰＣメッセージのフォー
マットを示す。サーバー変更通知ＲＰＣメッセージ１０
０は、グループ構成変更通知部７０から送信され、ＲＰ
Ｃ制御ヘッダ部１０１と変更サーバ処理識別子部１０３
で構成される。ＲＰＣ制御ヘッダ１０１にはＲＰＣ要求
メッセージ、ＲＰＣ応答メッセージの送受信に伴う処理
の制御に必要な情報が格納される。その一部のエリアで
あるＲＰＣ要求内容識別子部１０２には、ＲＰＣで要求
される処理内容を受信側のＲＰＣ処理部で識別できる処
理識別子が格納される。また、送信先アドレス、送信元
アドレス、送信通番、要求／応答の識別情報などが格納
されるエリアも有している。変更サーバ処理識別子部１
０３には、たとえばサーバグループ８０に追加されるサ
ーバ５５の処理内容を表わす処理識別子が格納される。

【００３５】図３は、ＲＰＣ要求メッセージのフォーマ
ットを示す。ＲＰＣ要求メッセージ１１０は、ＲＰＣ処
理部１０がクライアント１５のＲＰＣ要求に応じて送信
するもので、ＲＰＣ制御ヘッダ部１０１とクライアント
の要求データ部１１１から構成される。クライアント要
求データ部１１１には、サーバを実行するためのサーバ
プロシジャの入出力引数が格納される。

【００３６】図４は、ＲＰＣ応答メッセージのフォーマ
ットを示している。ＲＰＣ応答メッセージ１２０は、Ｒ
ＰＣ処理部２０〜５０が自処理装置のサーバの実行結果
をクライアントへ送信するもので、ＲＰＣ制御ヘッダ部
１０１、サーバ実行結果データ部１２２と、グループ構
成変更通番部１２１から構成される。サーバ実行結果デ
ータ部１２２にはサーバの実行結果が格納される。グル
ープ構成変更通番部１２１は本実施例に特有なもので、
サーバの追加などサーバグループの構成変更のたびにイ
ンクリメントされるグループ構成変更通番が格納され
る。

【００３７】グループ構成変更通番（以下、変更通番と
呼ぶ）は、サーバを具備する各処理装置が独立に管理し
ている変更通番である。１つの処理装置内には、自身が
具備するサーバが所属するグループ毎に、対応する１つ
の変更通番が保持される。サーバグループの変更履歴を
管理するために、サーバの追加や削除など、構成変更の
種類に対応した種類別の変更通番が用意されてもよい。
本実施例では、サーバを追加または削除する通知ＲＰＣ
メッセージ１００を受信したとき、後述のようにこの変
更通番がインクリメントされる。

【００３８】一方、ＲＰＣ要求側は後述のように、予め
ＲＰＣ要求を発行する対象サーバグループの全サーバの
変更通番を保持している。そして、ＲＰＣ応答メッセー
ジ１２０を受信したとき、メッセージに格納された変更
通番と保持している変更通番を比較し、変更通番の不一
致によってサーバグループの変更を検知する。

【００３９】以上、システム構成の概略とメッセージフ
ォーマットを説明した。次に、本実施例のリモートプロ
シジャコールを実施するシステムの詳細な構成と、各部
の処理について説明する。なお、処理装置１〜６が具備
するＲＰＣ処理部、処理装置７が具備するアドレス管理
部６０、処理装置８が具備するグループ構成変更通知部
７０の順に説明する。

【００４０】図５は、処理装置の詳細な構成を示す。図
示の処理装置２は一例を示したもので、他の処理装置３
〜８においても同様な構成としてよい。処理装置２はＲ
ＰＣ処理部１０と共に、クライアント１５とサーバ１６
の両方を具備している。ＲＰＣ処理部１０は、ＲＰＣク
ライアント処理部１１、ＲＰＣサーバ処理部１２、アド
レス管理テーブル１３、グループ管理テーブル１４を具
備している。アドレス管理テーブル１３は、各処理装置
がサーバグループに属するサーバの情報を格納する。ア
ドレス管理テーブル１３は、サーバの処理内容を表す処
理識別子と、そのサーバを具備する処理装置のアドレス
を格納する。

【００４１】なお、処理装置がクライアント処理専用で
あれば、サーバ１６やＲＰＣサーバ処理部１２は不要と
なる。また、処理装置がサーバ処理専用の場合は、クラ
イアント１５とＲＰＣクライアント処理部１１は不要で
あり、本実施例の場合にはアドレス管理テーブル１３も
不要となる。

【００４２】また、複数のＲＰＣ処理部を設けて、クラ
イアントやサーバからのＲＰＣ処理を分担してもよい。
この場合、他の処理装置からＲＰＣ要求メッセージを送
出する際の宛先アドレスは、宛先サーバの処理を担当す
るＲＰＣ処理部のアドレス（例えば、この処理装置のア
ドレスとこのＲＰＣ処理部の受信ポート番号）としても
よい。

【００４３】図６に、アドレス管理テーブルの構成を示
す。処理識別子部１３１とアドレス部１３２とから構成
され、各々に格納される情報は、ＲＰＣ処理部１０がア
ドレス管理部６０に要求して取得する。図示は図１にお
ける構成の一部を示し、少なくとも３台の処理装置のア
ドレス情報を格納している。すなわち、「ＱＳＯＲＴ」
で識別されるサーバを有する処理装置が３台で、各アド
レスは「133.144.8.159:8080」、「133.144.8.160:805
2」及び「133.144.8.161:8031」で与えられている。ま
た、「ＡＳＯＲＴ」で識別されるサーバを有する処理装
置があり、そのアドレス「133.144.9.120:6198」が格納
されている。アドレスには、図示のようにＩＰアドレス
と受信ポート番号との組を用いている。

【００４４】図７に、グループ管理テーブルの構成を示
す。グループ管理テーブル１４は、各処理装置がサーバ
グループの構成情報を格納している。同図のように、処
理識別子部１４１、アドレス部１４２及びグループ構成
変更通番部１４３から構成され、これら３つの情報が一
組になって使用される。処理識別子部１４１、アドレス
部１４２には、アドレス管理テーブル１３と同様に、サ
ーバの処理内容を表す処理識別子とその処理装置のアド
レスが格納される。

【００４５】グループ構成変更通番部１４３には、サー
バグループの構成の変更を管理する変更通番が格納され
る。図７（ａ）は図１のグループ構成による一部を示し
たもので、「ＱＳＯＲＴ」で識別されるサーバを有する
処理装置が３台あり、各々のグループ構成変更通番はそ
れぞれ、「２」、「３」、「５」である。また、「ＡＱ
ＯＲＴ」で識別されるサーバを有する処理装置が少なく
とも１台あり、そのグループ構成変更通番は「２」であ
る。ここで、同じＱＳＯＲＴに対する変更通番の値
「２」，「３」などは、当該アドレスに対応する処理装
置での変更回数を反映している。

【００４６】図８は、ＲＰＣクライアント処理部の処理
を示すフローチャートである。ＲＰＣクライアント処理
部１１は、クライアント１５からのＲＰＣ要求を代行し
て処理する。

【００４７】まず、クライアント１５からＲＰＣ要求を
受け付ける（Ｓ１０１）。このとき、ＲＰＣクライアン
ト処理部１１には、クライアン１５から処理要求するサ
ーバの処理識別子と、その処理に必要な引数が渡され
る。

【００４８】次に、ＲＰＣ要求を実行できるサーバを具
備する処理装置のアドレスを取得するため、アドレス管
理テーブル１３を検索するが、この際、最初のＲＰＣ要
求でアドレス管理テーブル１３に何も登録されていなか
った場合（Ｓ１０２）、アドレス管理テーブル１３の初
期化処理を行う（Ｓ１０３）。

【００４９】図９は、初期化処理Ｓ１０３を示すフロー
チャートである。ＲＰＣクライアント処理部１１はアド
レス管理部６０に対し、アドレス管理部６０に格納され
た、処理識別子に対応する全てのアドレスの参照を要求
するＲＰＣ要求メッセージを送信し、応答メッセージに
付されたアドレス情報を取得する（Ｓ１０３１）。この
アドレス情報をアドレス管理テーブル１３に登録する
（Ｓ１０３２）と共に、グループ管理テーブル１４にも
同様にアドレスを登録し、それに対応するグループ構成
変更通番に「０」を設定する（Ｓ１０３３）。

【００５０】次に、ＲＰＣクライアント処理部１１は、
アドレス管理テーブル１３を検索し、ＲＰＣ要求を実行
できるサーバを具備するすべての処理装置のアドレスを
取得すし（Ｓ１０４）、その処理装置の数をカウントす
る（Ｓ１０５）。この検索は、クライアント１５から渡
された処理識別子をキーにして行われ、アドレステーブ
ル１５から、クライアントから渡された処理識別子と同
じ処理識別子をもつ全ての処理装置のアドレスを取得す
る。そして、サーバグループの１つのサーバへ要求メッ
セージを送信する（Ｓ１０６）。すなわち、ＰＲＣ要求
メッセージ１１０のクライアント要求データ部１１１
に、サーバ実行に必要な引数を書き込み、Ｓ１０４で取
得したアドレスで与えられる処理装置を宛先に、このＲ
ＰＣ要求メッセージ１１０を送信する。

【００５１】ところで、Ｓ１０４でアドレスを検索した
結果、複数の処理装置のアドレスを取得した場合は、取
得したすべての処理装置に対してＲＰＣ要求メッセージ
１１０を送信する必要がある。そこで、ＲＰＣ要求メッ
セージ１１０の送信後、メッセージ送信済みの処理装置
の数をカウントし（Ｓ１０７）、そのカウント値と取得
したサーバグループ内のサーバの数を比較する（Ｓ１１
０）。比較の結果、カウント値の方が小さい場合は、Ｓ
１０４の処理で取得したアドレスの中から、まだＲＰＣ
要求メッセージ１１０を送信していないアドレスを選択
し（Ｓ１１１）、ＲＰＣ要求メッセージ１１０を送信す
る。このように、Ｓ１０６からＳ１１１までの送信処理
を繰り返すことによって、サーバグループに属しＲＰＣ
要求の処理識別子に対応するすべてのサーバに、ＲＰＣ
要求メッセージ１１０を送信する。

【００５２】以上が、クライアントからのＲＰＣ要求の
送信処理である。ＲＰＣ要求メッセージ１１０を送信す
ると、ＲＰＣ要求先のサーバから応答メッセージが返送
されてくる。ＲＰＣクライアント処理部１１は、自らの
ＲＰＣ要求先のサーバからの応答メッセージの受信をチ
エックし（Ｓ１０８）、以下のように応答受信処理を行
なう（Ｓ１０９）。

【００５３】図１０に、応答受信処理（Ｓ１０９）のフ
ローチャートを示す。ＲＰＣクライアント処理部１１
は、応答メッセージ１２０を受信すると（Ｓ２０１）、
応答メッセージ１２０（図４）からメッセージ送信元の
アドレスと、ＲＰＣ要求内容識別子、グループ構成変更
通番を取得する（Ｓ２０２）。そして、自己のグループ
管理テーブル１４を検索し、応答メッセージに付されて
いたアドレス及びＲＰＣ要求内容識別子の両方とも一致
するアドレス情報を検出し、そのアドレス情報の変更通
番と応答メッセージ１２０による変更通番を比較する
（Ｓ２０３）。

【００５４】比較した結果、両者の値が同じ場合は、サ
ーバグループに変更がなかったと判断し、応答受信処理
を終了する。一方、応答メッセージ１２０による変更通
番の値が大きい場合、つまりインクリメントされていた
場合は、サーバグループに変更があったと判断し（Ｓ２
０４）、応答メッセージ１２０によるグループ構成変更
通番を、グループ管理テーブル１４のアドレス情報のグ
ループ構成変更通番部１４３に格納する（Ｓ２０５）。

【００５５】次に、ＲＰＣクライアント処理部１１はネ
ットワーク１を経由し、処理装置７のアドレス管理部６
０に、全てのサーバのアドレスを参照するＲＰＣ要求メ
ッセージを送信し、応答メッセージに付されたアドレス
情報を取得する（Ｓ２０６）。次に、取得したアドレス
情報と自分のアドレス管理テーブル１３の内容を比較
し、前者に残る差分を追加サーバのアドレスとして取得
する（Ｓ２０７）。

【００５６】ここで、アドレス管理部６０から取得した
アドレス情報は、処理識別子とそれに対応するアドレス
の組の集合である。アドレス管理テーブル１３も同様で
ある。比較は両集合の構成要素である組単位に行ない、
その差分を求める。グループ管理テーブル１４以外にア
ドレス管理テーブル１３を設けるのは、この差分処理を
簡単にするためである。なお、サーバを削除する変更の
場合は、自分のアドレス管理テーブル１３の側に残る差
分情報が削除サーバのアドレスとなる。

【００５７】次に、本実施例では、Ｓ２０７で取得した
追加サーバを具備する処理装置のアドレス情報を、アド
レス管理テーブル１３に追加する（Ｓ２０８）。さら
に、同様にグループ管理テーブル１４にも追加し、この
とき対応するグループ構成変更通番に初期値「０」を格
納する（Ｓ２０９）。

【００５８】以上が応答受信処理（Ｓ１０９）である
が、Ｓ１０４で複数のアドレスが取得された場合、ＲＰ
Ｃ要求メッセージは複数個送信されるため、応答メッセ
ージも同じ数だけ返送されてくる。したがって、ＲＰＣ
クライアント処理部１１は、すべての応答メッセージを
受信するまで、応答受信処理を繰り返し（Ｓ１１２）、
複数の応答メッセージに付されたサーバ実行結果データ
１２２の１つを選択し、クライアント１５に渡す（Ｓ１
１３）。この選択は「ランダムに選択」、「先着で、１
番最初に受信したもの」など、予め決められた論理に基
づいて行われる。

【００５９】次に、ＲＰＣサーバ処理部１２について説
明する。ＲＰＣサーバ処理部１２はサーバ１６のＲＰＣ
要求受付、および応答返送の代行処理を行うと共に、処
理装置７のグループ構成変更通知部７０から、サーバグ
ループ構成変更を通知するＲＰＣメッセージを受信し、
サーバグループ構成の変更情報を保持する。

【００６０】図１１は、ＲＰＣサーバ処理部の処理を示
すフローチャートである。ＲＰＣサーバ処理部１２は、
他の処理装置から送信されたＲＰＣ要求メッセージ１１
０を受信すると（Ｓ３０１）、受信メッセージの要求内
容を判定する（Ｓ３０２）。この判定は、サーバ変更通
知ＲＰＣメッセージ１００の処理識別子部１０３を参照
することで可能になる。

【００６１】受信メッセージがサーバグループの構成変
更を通知するメッセージ場合は、自処理装置のグループ
管理テーブル１４におけるグループ構成変更通番部１４
３の値をインクリメントする（Ｓ３０３）。これによっ
て、ＲＰＣ処理部１０はサーバグループの構成変更の情
報を保持する。そして、ＲＰＣ要求元であるグループ構
成変更通知部７０に対し、グループ構成変更の情報を保
持する処理の完了を知らせる応答を返す（Ｓ３０４）。

【００６２】一方、ステップＳ３０２の判定において、
受信した要求メッセージがＲＰＣ要求メッセージ１１０
の場合、ＲＰＣサーバ処理部１２はサーバを実行する
（Ｓ３０５）。すなわち、受信したＲＰＣ要求メッセー
ジ１１０のクライアント要求データ部１１１からサーバ
の実行に必要な引数等を取得し、サーバ１６に渡すと共
に、サーバ１６のプロシジャを実行する。処理装置内に
同一処理識別子をもつサーバが複数ある場合には、ラン
ダムに１つ選択して実行するものとする。

【００６３】サーバ１６のプロシジャ実行後、ＲＰＣサ
ーバ処理部１２はサーバ１６から実行結果を受け取り、
ＲＰＣ応答メッセージ１２０のサーバ実行結果データ部
１２２に格納する。また、グループ構成変更通番部１２
１のエリアには、グループ管理テーブル１４のグループ
構成変更通部１４３の値を格納する（Ｓ３０６）。この
ＲＰＣ応答メッセージ１２０を、ＲＰＣ要求元であるク
ライアントへ送信する（Ｓ３０７）。したがって、この
ＲＰＣ要求時までに、グループ管理テーブル１４の変更
通番がインクリメントされていれば、この変更通番をＲ
ＰＣ応答メッセージに格納して送信し、クライアントに
サーバグループの変更を知らせることができる。

【００６４】以上、処理装置２〜６が具備するＲＰＣ処
理部の詳細について、クライアントとサーバの両方を備
える図５の処理装置の構成で説明した。上記で、図１の
システム構成におけるＲＰＣ処理は、クライアント側は
処理装置２、グループサーバ側は処理装置３〜５に読み
代えることで理解できる。

【００６５】次に、処理装置７が具備するアドレス管理
部６０について詳細に説明する。処理装置７のＲＰＣ処
理部は図示を省略している。アドレス管理部６０は、図
１に示すシステム内のサーバのアドレスを一括管理して
おり、ある決められた範囲内（例えば１つのネットワー
クセグメント内）の処理装置が具備する全てのサーバの
処理識別子とその処理装置のアドレスとの対応情報を、
自身の管理テーブルに保持している。アドレス管理部６
０は、他の処理装置からのＲＰＣ要求メッセージに応じ
て、上記情報の追加、削除あるいは参照処理を行い、応
答メッセージにより要求元に返す。

【００６６】図１２は、アドレス管理部の処理を示すフ
ローチャートである。まず、ＲＰＣ処理要求を受信する
と（Ｓ４０１）、その処理要求内容を判定し（Ｓ４０
２）、サーバアドレスの追加、サーバアドレスの削除ま
たはサーバアドレスの検索の何れかを処理する。

【００６７】サーバの追加時には、他の処理装置の要求
元、例えばあるクライアントがアドレス管理部６０に対
して、追加サーバを具備する処理装置のアドレスと追加
サーバの処理識別子を付したＲＰＣ要求メッセージを送
信する。アドレス管理部６０は要求内容がサーバアドレ
スの追加と判定すると、処理装置７が具備する管理テー
ブルに、ＲＰＣ要求メッセージに付されていたアドレス
と処理識別子を追加し（Ｓ４０３）、追加処理の成否を
応答メッセージとして要求元に送信する（Ｓ４０４）。

【００６８】アドレス管理部６０は同一の処理識別子を
もつサーバを１つのサーバグループとして管理する。し
たがって、アドレスとサーバが属するサーバグループと
を管理するため、アドレスと処理識別子を対応付けて追
加する。

【００６９】次に、サーバの削除時には、他の処理装置
内の要求元が、削除するアドレスとサーバの処理識別子
を付したＲＰＣ要求メッセージを送信する。アドレス管
理部６０は削除要求であると判定すると（Ｓ４０２）、
ＲＰＣ要求メッセージに付された処理識別子とアドレス
の組みと同一のアドレス情報を、自身が具備するテーブ
ルから削除し（Ｓ４０５）、削除処理の成否を応答メッ
セージとして要求元へ送信する（Ｓ４０６）。

【００７０】次に、ある処理の実行可能なサーバを有す
る処理装置のアドレスを参照する際には、他の処理装置
内の要求元がその処理の内容を示す処理識別子を付した
ＲＰＣ要求メッセージを、アドレス管理部６０に送信す
る。要求内容がアドレスの参照と判定されると（Ｓ４０
２）、アドレス管理部６０が具備する管理テーブルを検
索し、ＲＰＣ要求メッセージに付された処理識別子と同
じ処理識別子に対応付けられたアドレスを取り出し（Ｓ
４０７）、ＲＰＣ応答メッセージに付して要求元に送信
する（Ｓ４０８）。

【００７１】ステップＳ４０７の検索よって、複数のア
ドレスが取得された場合は１つのアドレスをランダムに
選択してもよいし、すべてのアドレスをＲＰＣ応答メッ
セージに付して送信してもよい。

【００７２】次に、処理装置８が具備するグループ構成
変更通知部７０について説明する。処理装置８のＲＰＣ
処理部は図示を省略している。グループ構成変更通知部
７０は、ユーザからのコマンド入力等により指定のサー
バグループの構成変更の要求を受け付ける。たとえば、
コマンドによりサーバグループ８０の構成変更の要求が
行なわれ、このコマンドの引数として、追加または削除
されるサーバを具備する処理装置のアドレスや、サーバ
の処理識別子などの情報が、グループ構成変更通知部７
０に与えられる。

【００７３】グループ構成変更通知部７０は、このコマ
ンドを受け付けると、処理装置７のアドレス管理部６０
に対して、アドレスの変更を要求するＲＰＣ要求メッセ
ージを送信する。たとえば、新規サーバを具備する処理
装置のアドレスの追加を要求するＲＰＣ要求メッセージ
を送信し、アドレス管理部６０にアドレスを登録すると
共に、サーバグループ構成変更を通知するＲＰＣメッセ
ージを、指定のサーバグループ８０に送信する。サーバ
グループ８０に属する処理装置３〜５は、このサーバグ
ループ構成変更を通知するＲＰＣメッセージを受信し、
自身のアドレス管理テーブル１３及びグループ管理テー
ブル１４に、サーバグループ構成の変更情報を保持す
る。

【００７４】図１３は、グループ構成変更通知部による
サーバ追加処理を示すフローチャートである。グループ
構成変更通知部７０は、サーバグループへのサーバの追
加要求を受け取ると（Ｓ５０１）、アドレス管理部６０
に、追加対象となるサーバグループに属するサーバのア
ドレス参照を要求するＲＰＣ要求メッセージを送信し、
アドレスを取得する（Ｓ５０２）。このとき、グループ
に属する任意の１つのサーバのアドレスを取得してもよ
いし、すべてのサーバのアドレスを取得してもよい。後
者の場合、グループ構成変更通知部７０が任意の１つを
選択する。

【００７５】次に、グループ構成変更通知部７０は、追
加サーバのアドレスの登録を要求するＲＰＣ要求メッセ
ージをアドレス管理部６０に対して送信し、管理テーブ
ルへのアドレス登録を依頼する（Ｓ５０３）。次に、ス
テップＳ５０２で取得したアドレスのサーバへ、サーバ
の追加を通知するＲＰＣメッセージ１００を送信し（Ｓ
５０４）、そのサーバから追加情報を記憶する処理が完
了したという応答を受信する（Ｓ５０５）。

【００７６】以上によって、本発明のリモートプロシジ
ャコール処理を実現する、本実施例の基本的な構成と動
作が明らかになった。次に、具体的なリモートプロシジ
ャコールについて、グループサーバに対して新規サーバ
を追加する処理の例を説明する。この処理の全体的な流
れは、サーバグループに対してサーバの追加を通知する
処理、各クライアント側処理装置における追加サーバの
検知処理に大別でき、この２つに分けて説明する。

【００７７】図１４は、図１のシステムのＲＰＣ処理部
を詳細にした構成図で、新規サーバを追加する処理の流
れを矢線で示している。また、図１５は、クライアント
側とサーバ側の各々のグループ管理テーブルの具体的な
格納内容を示す説明図である。さらに、図１６は、本実
施例によって新規サーバを追加するときの全体的な処理
を示すフローチャートである。これらの図を参照しなが
ら、本実施例によるサーバの追加処理を説明する。

【００７８】グループ構成変更通知部７０は、ユーザか
ら、サーバグループ８０へのサーバ５５の追加を受付け
ると、新規サーバ５５を具備する処理装置６のアドレス
をアドレス管理部６０へ登録する。また、グループ構成
変更通知部７０は、アドレス管理部６０からサーバグル
ープ８０内の任意の１つのサーバのアドレス、ここでは
サーバ４５のアドレスを取得し、そのアドレスであるＲ
ＰＣサーバ処理部４２宛に、矢印２０１ａのようにサー
バ追加の通知ＲＰＣメッセージ１００を送信する（Ｓ６
０１）。

【００７９】ＲＰＣサーバ処理部４２は、サーバ追加の
通知ＲＰＣメッセージを受信すると、ＲＰＣサーバ処理
部４２内にあるグループ管理テーブル４４のグループ構
成変更通番を５⇒６にインクリメントし、グループ構成
変更通知部７０に処理完了の応答メッセージを送信する
（Ｓ６０２）。

【００８０】次に、クライアント側の処理装置における
追加サーバの検知処理について説明する。図１７に、ク
ライアント側における追加サーバの検知処理のフローチ
ャートを示す。

【００８１】クライアント１５は、たとえば処理識別子
「ＱＳＯＲＴ」を含むＲＰＣ要求メッセージ１１０をＲ
ＰＣクライアント処理部１１に出す。ＲＰＣクライアン
ト処理部１１は、アドレス管理テーブル１３を検索し、
サーバグループ８０に属する「ＱＳＯＲＴ」の実行可能
なサーバを具備する処理装置３，４，５のアドレスを取
得し、矢印２０５ａ，ｂ，ｃのようにＲＰＣ要求メッセ
ージを送信する（Ｓ７０１）。このとき、グループ管理
テーブル１４の「ＱＳＯＲＴ」をもつ各アドレスに対応
する変更通番は、図１５のように記憶されている。

【００８２】ＲＰＣ要求メッセージを受信した処理装置
３，４，５のＲＰＣサーバ処理部２２，３２，４２は、
ＲＰＣ要求に応じて矢印２０６ａ，ｂ，ｃのようにサー
バを実行し（Ｓ７０２）、サーバの実行結果を矢印２０
７ａ，ｂ，ｃと取得する。また、グループ管理テーブル
２４，３４，４４内の変更通番を矢印２０８ａ，ｂ，ｃ
のように取得し、実行結果と変更通番を格納したＲＰＣ
応答メッセージを矢印２０９ａ，ｂ，ｃのように送信す
る（Ｓ７０３）。このとき、グループ管理テーブル２
４，３４，４４の「ＱＳＯＲＴ」の変更通番は図１５の
内容である。

【００８３】ＲＰＣクライアント処理部１１は、処理装
置３，４，５からのＲＰＣ応答メッセージを受信し（Ｓ
７０４）、ＲＰＣ応答メッセージ内の変更通番とグルー
プ管理テーブル１４内の変更通番を比較し、グループサ
ーバの構成が変更されたか否かを判定する（Ｓ７０
５）。この処理は、図１０の応答受信処理のステップＳ
２０４に相当する。

【００８４】ここでは、処理装置５が具備するＲＰＣサ
ーバ処理部４２は、上記のようにサーバ追加の通知ＲＰ
Ｃメッセージを受信し、グループ管理テーブル４４の
「ＱＳＯＲＴ」のグループ構成変更通番を５⇒６にイン
クリメントし、応答メッセージに付加して矢印２０９ｃ
のように送信している。従って、ＲＰＣクライアント処
理部１１が、ＲＰＣ応答メッセージの変更通番と、自分
のグループ管理テーブル１３の同一アドレスの変更通番
を比較すると、新規サーバの追加が検知できる。

【００８５】新規サーバの追加を検知したＲＰＣクライ
アント処理部１１は、アドレス管理部６０からすべての
サーバのアドレス情報を取得し、自分のアドレス管理テ
ーブル１３のアドレス情報と比較し、差分として得られ
るサーバ５５のアドレス情報を、アドレス管理テーブル
１３、グループ管理テーブル１４に追加する（Ｓ７０
６）。次に、ＲＰＣクライアント処理部１１は、処理装
置３，４，５の各々から受信したＲＰＣ応答メッセージ
の１つを選択し、クライアント１５にサーバの実行結果
として渡す（Ｓ７０７）。

【００８６】なお、上記ではグループ構成変更通知部７
０が処理装置８によって具備される構成としているが、
どの処理装置が具備していてもよい。例えば、処理装置
６がグループ構成変更通知部７０を具備していてもよ
い。このとき、サーバ５５が自身の追加要求をグループ
構成変更通知部７０へ通知し、グループ構成変更通知部
７０へ追加処理要求を依頼するようにしてもよい。

【００８７】また、図１１のステップＳ３０２の判定が
サーバの追加要求の場合、指定のサーバグループに新規
のサーバの追加の可否を判定してから、ステップＳ３０
３で追加の処理をするようにしてもよい。

【００８８】たとえば、図１のサーバグループ８０にお
いて、グループ８０内で多重化できないサーバがあり、
その処理識別子が「ＣＳＯＲＴ」であるとする。この場
合に、サーバ５５を追加すると、「ＣＳＯＲＴ」のサー
バが多重化されてしまう。従って、ＲＰＣサーバ処理部
４２は、ＲＰＣ通知メッセージ１００の追加サーバの処
理識別子を受け取ると、グループ管理テーブル１４の処
理識別子と対照し、「ＣＳＯＲＴ」サーバが多重化され
る場合には追加処理を中断する。あるいは、サーバグル
ープが完全多重化の構成をとる場合は、グループ管理テ
ーブル１４の処理識別子と対照し、追加するサーバの処
理識別子が同一であるか判定し、同一でなければ追加不
可の応答を返す。

【００８９】このほかにも、追加処理が許されるユーザ
ＩＤやプログラムＩＤや認証情報を予めＲＰＣサーバ処
理部内に記憶しておき、ＲＰＣ通知メッセージに要求元
のユーザＩＤ、プログラムＩＤまたは認証情報を付加し
て送信し、受信時にこれらの情報を比較して、追加の要
否を判定するようにしてもよい。

【００９０】以上、本実施例の構成によれば、ＲＰＣを
用いて１つの要求に対応して複数のサーバを並列的に呼
び出すクライアント側の計算機は、各々が独立して非同
期的に、複数のリモートプロシジャが構成するグループ
の構成変化を検出し、グループ構成変更処理を行う。ま
た、この検出のための情報は、通常時のＲＰＣ応答に付
加されてクライアント側に伝達される。したがって、グ
ループ構成変更に際して、これに伴う追加処理メッセー
ジがネットワーク上に集中することがなく、ネットワー
クの負荷、構成変更に伴い追加されたリモートプロシジ
ャ側の計算機あるいはリモートプロシジャのアドレスを
管理するネームサーバ等の負荷を時間的に分散できる。
特に、クライアント側計算機がグループ構成の変更の有
無を常に監視している必要がなく、自らのＲＰＣ要求時
に対する応答内容から変更を検知できるので、クライア
ント側計算機の変更処理に伴う負荷の増大は少ない。

【００９１】また、本実施例によれば、リモートプロシ
ジャ側が多重化サーバを構成し、クライアントが多重化
サーバにアクセスしているときに、サーバ追加の前後で
各サーバにアクセスするクライアント側計算機を同じに
することができ、グループ構成の変更を行なうことがで
きるので、サーバの内部状態の整合性が保証され、多重
化サーバの通信方式として有用である。さらに、サーバ
の多重度をオンラインに変化させることができる。

【００９２】本実施例では、クライアント側はグループ
内の全てのサーバに対してＲＰＣ要求を発行している。
しかし、グループ内の一部のサーバにＲＰＣを発行する
ようにしてもよい。これによれば、クライアントが追加
サーバを検知したとき、それまでＲＰＣを発行していた
要求先のサーバに代えて追加サーバを用い、サーバグル
ープ内で処理の負荷分散を図ることができる。あるい
は、要求先の旧バージョンに代えて新バージョンの追加
サーバを用い、サーバのバージョンアップをオンライン
で行うこともできる。

【００９３】また、サーバはプロシジャの形で提供され
ていなくてもよい。要求に対し自らの処理を実行し、そ
の実行結果を依頼元に返すプログラムであってもよい。
すなわち、実行結果を依頼元に返すタイミングが、必ず
しも自らの処理の実行終了時である必要はなく、自らの
処理の実行途中に何らかのデータを依頼元に返すプログ
ラムであってもよい。さらに、サーバが処理要求に応じ
て実行するプログラムは、必ずしも処理結果を出力する
ものである必要はない。処理終了時あるいは処理開始時
等に、サーバ側のＲＰＣ処理部が実行結果データ部にデ
ータを何も格納しないで、ＲＰＣ応答メッセージを返す
ようにしてもよい。

【００９４】さらに、本実施例では同一の処理識別子は
同一の処理内容を表すものとして、図１のように多重化
サーバのグループ構成を示したが、これに限られるもの
ではない。ＲＰＣではサーバが保持するプロシジャの名
前や処理内容に関わらず、異なる名前や処理を行なうプ
ロシジャをもつサーバであっても、同一の処理識別子を
もつことが可能である。このような識別子の付与を行な
った場合、送信側はグループ内の各サーバが保持するプ
ロシジャの内容を意識しないで送信メッセージを送るこ
とができるので、送信側の負荷低減をはかれる等のメリ
ットがある。

【００９５】〔第２の実施例〕本実施例はグループ構成
の変更の有無の検出を、第１の実施例とは異なりサーバ
側で行なう。すなわち、クライアントがサーバへＲＰＣ
を発行する際に、ＲＰＣ要求メッセージにクライアント
が保持している変更通番を格納して送出し、サーバ側が
その変更通番と、自処理装置のグループ管理テーブルに
記憶している変更通番を比較して、グループ構成の変更
の有無を検出する。以下、第１の実施例と異なる部分を
中心に説明する。なお、システム構成は第１の実施例と
同じであり、以下では図１４の構成を参照する。

【００９６】図１８に、クライアント側の処理装置が送
出するＲＰＣ要求メッセージのフォーマットを示す。第
１の実施例におけるＲＰＣ要求メッセージ（図３）に、
クライアントが保持している変更通番を格納する、グル
ープ構成変更通番部１１２を追加している。

【００９７】図１９に、サーバ側の処理装置がクライア
ント側へ実行結果を返すＲＰＣ応答メッセージのフォー
マットを示す。第１の実施例のＲＰＣ応答メッセージ
（図４）に、サーバグループにおける構成変更の有無を
知らせる変更フラグ部１２３を追加している。

【００９８】ＲＰＣクライアント処理部１１が行う処理
について説明する。まず、第１の実施例による処理フロ
ー（図８）のステップＳ１０６において、ＲＰＣクライ
アント処理部１１がサーバへＲＰＣ要求メッセージを発
行する際に、要求先サーバのアドレスに対応する変更通
番をグループ管理テーブル１４から取り出し、図１８
（ｂ）のように、ＲＰＣ要求メッセージのグループ構成
変更通番部１１２に格納する。

【００９９】図２０は、本実施例によるＲＰＣクライア
ント処理部の応答受信処理のフローチャートである。Ｒ
ＰＣクライアント処理部１１は、サーバからＲＰＣ応答
メッセージ１２０を受信すると（Ｓ８０１）、変更フラ
グ部１２３を調べ、サーバグループに追加があったか否
かを判定する（Ｓ８０２）。追加フラグがセット（Ｏ
Ｎ）されていれば、サーバグループ８０に変更があった
と判断し、Ｓ８０３〜Ｓ８０７の処理を行う。ここで、
ステップＳ８０３〜Ｓ８０７の処理は、第１の実施例の
図１０に示したステップＳ２０５〜Ｓ２０９の処理と同
様である。

【０１００】次に、サーバー側のＲＰＣサーバ処理部が
行う処理について説明する。図２１は、本実施例による
ＲＰＣサーバ処理部の応答受信処理のフローチャート
で、例えば処理装置５のＲＰＣサーバ処理部４２によっ
て実行される。同図で、ステップＳ９０１〜Ｓ９０４
は、第１の実施例（図１１）におけるＳ２０１〜Ｓ２０
４と同様の処理となる。

【０１０１】ステップＳ９０２の判定で、要求メッセー
ジがサーバの変更でない場合、まずクライアントから要
求されたサーバを実行する（Ｓ９０５）。そのサーバか
ら実行結果を受け取ると、ＲＰＣ要求メッセージ１２０
に付加されていた変更通番を取得し（Ｓ９０６）、自処
理装置５のグループ管理テーブル４４に管理している変
更通番と比較する（Ｓ９０７）。比較の結果、自分の変
更通番の方が大きければ、図１９（ｂ）のようにＲＰＣ
応答メッセージのサーバ追加フラグをＯＮにし（Ｓ９１
０）、ＲＰＣ応答メッセージ１２０に自分の変更通番を
付加して（Ｓ９１１）、サーバの実行結果と共にクライ
アント側の処理装置２へ返送する（Ｓ９１２）。

【０１０２】一方、取得した変更通番が自分の変更通番
以下であれば、ＲＰＣ応答メッセージのサーバ追加フラ
グをＯＦＦにし（Ｓ９０９）、ＲＰＣ応答メッセージ１
２０に自分の変更通番を付加し（Ｓ９１１）、サーバの
実行結果と共に要求元の処理装置へ返送する。

【０１０３】この後、ＲＰＣクライアント処理部１１
は、応答メッセージ１２０の追加フラグのＯＮ／ＯＦＦ
を判定し、ステップＳ８０３〜Ｓ８０７により、グルー
プ管理テーブル１４とアドレス管理テーブル１３を更新
する。

【０１０４】なお、上記ではサーバ追加の例を説明した
が、サーバ削除の場合はサーバ削除フラグを用意しその
ＯＮ／ＯＦＦを判定する。あるいは、サーバの追加、削
除に共用する変更フラグを用意し、ステップＳ９０７に
おける比較の結果、取得したグループ構成変更通番が自
分の保持する変更通番と相違する場合に、グループ構成
に変更があると判定して、ステップＳ８０３〜Ｓ８０７
の処理を行なうようにしてもよい。

【０１０５】本実施例によれば、サーバグループ構成変
更の有無の判定をサーバ側で行っているので、クライア
ントの処理が軽減できる。特に、不正なサーバの変更要
求が連続するような場合に、クライアントのオーバーロ
ードを回避できる。

【０１０６】〔第３の実施例〕次に、第３の実施例につ
いて説明する。第１、第２の実施例では、クライアント
の処理装置がサーバグループのサーバを呼び出す際に、
複数のサーバに対して直接ＲＰＣ要求メッセージを送信
するマルチキャスト方式を用いていた。これに対し、本
実施例では、クライアントの処理装置はサーバグループ
の任意のサーバに対してＲＰＣ要求メッセージを送信
し、このメッセージを受信した処理装置が宛先であるサ
ーバを実行するとともに、グループの残りのすべてのサ
ーバに対してＲＰＣ要求メッセージを転送し、その転送
メッセージを受信した各処理装置が自身のサーバを実行
する、という間接マルチキャスト方式を用いる。

【０１０７】図２２は、本実施例によるサーバ追加を説
明するためのシステム構成図で、詳細は図１４と同様に
なる。図２３は、本実施例によるＲＰＣ要求メッセージ
と応答メッセージのフォーマットを示す。同図（ａ）の
ＲＰＣ要求メッセージでは、複製の転送による場合を区
別するために、図３のＲＰＣ要求メッセージに、転送メ
ッセージフラグ部１１３を追加している。また、同図
（ｂ）の応答メッセージでは、変更フラグ部１２３を設
け、グループ構成変更通番部１２１は削除している。

【０１０８】次に、本実施例でのサーバ追加の処理を説
明する。この処理の全体的な流れは、サーバグループに
対してサーバの追加を通知する処理と、各々のクライア
ント側処理装置における追加サーバの検知処理に分ける
ことができる。前者の処理は第１の実施例と同様である
ので、以下では後者の処理のみを説明する。

【０１０９】ＲＰＣクライアント処理部１１は、グルー
プ内のマスタサーバとして予め設定されている任意の１
つ、ここでは処理装置３のサーバ２５に対してＲＰＣ要
求メッセージを送信する。なお、マスターとなる処理装
置３のグループ管理テーブル２４には、グループ８０の
すべてのサーバを呼び出せるように、そのアドレスと変
更通番を管理している。

【０１１０】クライアントからのＲＰＣ要求メッセージ
を受け取った処理装置３のＲＰＣサーバ処理部２２は、
転送メッセージフラグがＯＦＦとなっていることから、
転送メッセージでないと判断すると、グループ内の他の
すべてのサーバ宛てに転送ＲＰＣ要求メッセージを送信
し、送信された転送ＲＰＣ要求メッセージは、それぞれ
処理装置４、５によって受信される。

【０１１１】ＲＰＣ要求メッセージを受信した処理装置
４，５内のＲＰＣサーバ処理部３２，４２は、ＲＰＣ要
求に応じてサーバを実行し、サーバの実行結果を取得
し、また、グループ管理テーブル２４，３４，４４内の
変更通番を取得し、それらを格納したＲＰＣ応答メッセ
ージを、転送ＲＰＣ要求メッセージを送出したＲＰＣサ
ーバ処理部２２へ送信する。

【０１１２】ＲＰＣサーバ処理部２２は、自分にグルー
プ構成変更通知のあるときはグループ管理テーブル２４
を更新する。また、処理装置４，５からのＲＰＣ応答メ
ッセージ内の変更通番とグループ管理テーブル２４内の
変更通番を比較し、グループ構成に変更が有るか否かを
判定する。変更がある場合には、グループ管理テーブル
２４を更新する。

【０１１３】ＲＰＣサーバ処理部２０は、クライアント
に自分のサーバ２５の処理結果と他の転送先サーバ３
５，４５からの実行結果を送信する際、先にグループ管
理テーブル２４を更新している場合は、変更フラグ部１
２３に変更フラグをセット（ＯＮ）する。

【０１１４】処理装置３からＲＰＣ応答メッセージを受
信したＲＰＣクライアント処理部１１は、メッセージの
変更フラグがＯＮであればサーバーグループ８０の構成
に変更があると判断し、アドレス管理部６０からすべて
のサーバのアドレスを取得し、アドレス管理テーブル１
３のアドレスと比較する。その結果、差分となるサーバ
５５のアドレスを、アドレス管理テーブル１３およびグ
ループ管理テーブル１４に追加する。次に、ＲＰＣクラ
イアント処理部１１は、ＲＰＣ応答メッセージ内の処理
装置３，４，５のサーバ実行結果から１つを選択し、ク
ライアント１５に渡す。なお、本実施例では、クライア
ント側にはグループ管理テーブルが不要となる。

【０１１５】本実施例によれば、サーバグループにＲＰ
Ｃ要求を行なう場合に、グループ内で任意に選択した処
理装置との間でのみ送受信が行なわれ、グループ内の他
の処理装置の残りのすべてのサーバに対してＲＰＣ要求
メッセージを転送して処理する間接マルチキャスト方式
を用いるので、クライアントやネットワークの処理付加
を低減できる。

【０１１６】〔第４の実施例〕次に、第４の実施例につ
いて説明する。第１、第２、第３の実施例では、クライ
アントとサーバとの通信方法としてＲＰＣを用いた。Ｒ
ＰＣは複数の情報処理装置がネットワークを介して相互
に接続された分散処理システムにおいて、ある処理装置
内に存在するクライアントが、自分の処理装置内に存在
するプロシジャ呼び出しと同じ手法によって他の処理装
置内に存在するサーバ側が提供するプロシジャを呼び出
し、その実行結果を受け取る処理手続を行う依頼応答通
信方法である。しかしながら、ＲＰＣは内部的には、
(１)クライアントからサーバへの依頼メッセージの通
信、(２)サーバからクライアントへの応答メッセージの
通信を組合せ、その上で、(３)サーバ側の実行可能なプ
ログラムはプロシジャの形で提供され、(４)クライアン
トが、自分の処理装置内に存在するプロシジャ呼び出し
と同じ手法によって他の処理装置内に存在するサーバ側
が提供するプロシジャを呼び出すことができるように処
理することを特徴とした、依頼応答通信の１つの形態で
ある。

【０１１７】本発明の主旨は、クライアントとサーバ間
の通信方法として、特にＲＰＣに限らなくとも、クライ
アントとサーバ間の通信方法が、前記リモートプロシジ
ャコール要求／応答の代わりに、それぞれ少なくとも
(１)クライアントからサーバへの実行依頼メッセージの
通信、(２)サーバからクライアントへの応答メッセージ
の通信を組み合わせた依頼応答通信であれば適用可能で
ある。

【０１１８】第１、第２、第３のいずれの実施例におい
ても、リモートプロシジャコール要求の代わりに依頼メ
ッセージ、リモートプロシジャコール応答の代わりに応
答メッセージを用いてもよい。この場合、第１、第２、
第３の各実施例におけるシステム構成及び処理装置内の
構成は、第４の実施例においても同様であり、処理内容
についても同様でよい。また、ＲＰＣメッセージのフォ
ーマットについても、ＲＰＣ制御ヘッダ部を依頼応答通
信のための制御情報を含む、依頼応答通信制御ヘッダ部
に変更するだけでよい。

【０１１９】以上のように、本発明の主旨は、クライア
ントとサーバとの通信方法を特にＲＰＣに限らなくと
も、クライアントとサーバとの通信方法が依頼応答通信
であれば適用可能であり、ＲＰＣの場合と同様の効果を
得ることができる。

【０１２０】

【発明の効果】本発明によれば、クライアント側の計算
機は動作中にサーバグループの構成変化を検知すること
ができる。従って、システム管理者はアプリケーション
システムを稼働させながら、サーバグループにサーバを
追加し、新たなサービスを追加したり、多重度を増やし
たり、サーバのバージョンアップを行ったりすることが
でき、システムの拡張性、保守性、耐故障性を向上させ
ることができる。また、アプリケーションシステムを稼
働させながら、サーバグループからサーバを削除し、不
要サーバを切り離すことができ、システムの縮小性、保
守性を向上させることができる。

【０１２１】また、グループの構成変化の検出情報は、
ＲＰＣ応答または依頼応答に付加されて送受信されるの
で、変更に伴うネットワーク上の負荷集中を生じない。
さらに、クライアント側計算機がグループ構成の変更の
有無を常に監視している必要はなく、自らのＲＰＣ要求
または依頼通信時に対する応答内容から変更を検知でき
るので、クライアント側計算機の変更処理に伴う負荷の
増大はない。

【０１２２】また、本発明によれば、リモートプロシジ
ャ側が多重化サーバを構成している場合、サーバ追加の
前後で各サーバにアクセスするクライアント側計算機を
同じにすることができ、サーバの内部状態の整合性が保
証されるので、多重化サーバの通信方式として有用であ
る。

【図面の簡単な説明】

【図１】本発明のリモートプロシジャコール処理方式を
適用するシステム構成の一例を示すブロック図。

【図２】一実施例によるサーバ変更通知ＲＰＣメッセー
ジのフォーマット図。

【図３】一実施例によるＲＰＣ要求メッセージのフォー
マット図。

【図４】一実施例によるＲＰＣ応答メッセージのフォー
マット図。

【図５】クライアントとサーバを併設する処理装置の構
成図。

【図６】アドレス管理テーブルの内容を示すフォーマッ
ト図。

【図７】グループ管理テーブルの内容を示すフォーマッ
ト図。

【図８】第１の実施例によるＲＰＣクライアント処理部
の全体的な処理動作を示すフローチャート。

【図９】テーブル初期化処理の詳細を示すフローチャー
ト。

【図１０】ＲＰＣクライアント処理部の応答受信処理を
示すフローチャート。

【図１１】第１の実施例によるＲＰＣサーバ処理部の処
理動作を示すフローチャート。

【図１２】アドレス管理部の処理動作を示すフローチャ
ート。

【図１３】グループ構成変更通知部の処理動作を示すフ
ローチャート。

【図１４】サーバ追加処理の流れを説明するシステム構
成図。

【図１５】図１４のシステム構成において、各グループ
管理テーブルの具体的な管理内容を示す説明図。

【図１６】サーバ側でのサーバ追加処理の流れを説明す
るフローチャート。

【図１７】クライアント側でのサーバ追加の検知処理を
示すフローチャート。

【図１８】第２の実施例におけるＲＰＣ要求メッセージ
を示すフォーマット図。

【図１９】第２の実施例におけるＲＰＣ応答メッセージ
を示すフォーマット図。

【図２０】第２の実施例におけるＲＰＣクライアント処
理部の応答受信処理の処理動作を示すフローチャート。

【図２１】第２の実施例におけるＲＰＣサーバ処理部の
処理動作を示すフローチャート。

【図２２】第３の実施例における間接マルチキャスト方
式の処理の流れを説明するシステム構成図。

【図２３】第３の実施例におけるＲＰＣ要求メッセージ
及び応答メッセージを示すフォーマット図。

【符号の説明】

１…通信媒体（ネットワーク）、２〜８…処理装置（計
算機）、１０，２０，３０，４３，５０…ＲＰＣ処理
部、１１…ＲＰＣクライアント処理部、１２，２２，３
２，４２，５２…ＲＰＣサーバ処理部、１３…アドレス
管理テーブル、１４，２４，３４，４４，５４…グルー
プ管理テーブル、１４３…グループ構成変更通番部、２
５，３５，４５，５５，４０１，４０２，４０３，４１
１，４１２，４１３，４２１，４２２，４２３，４３
１，４３２，４３３…サーバ、６０…アドレス管理部、
７０…グループ構成変更通知部、８０…サーバグルー
プ、１００…サーバ変更通知ＲＰＣメッセージ、１０１
…ＲＰＣ制御ヘッダ部、１０２…ＲＰＣ要求内容識別子
部、１０３…変更サーバ処理識別子部、１１０…ＲＰＣ
要求メッセージ、１１１…クライアント要求データ部、
１２０…ＲＰＣ応答メッセージ、１２１…グループ構成
変更通知部、１２２…サーバ実行結果データ部。

───────────────────────────────────────────────────── フロントページの続き (72)発明者 安東 宣善 神奈川県川崎市麻生区王禅寺1099番地 株 式会社日立製作所システム開発研究所内 (72)発明者 平澤 茂樹 神奈川県川崎市麻生区王禅寺1099番地 株 式会社日立製作所システム開発研究所内 (72)発明者 綿谷 洋 茨城県日立市大みか町五丁目２番１号 株 式会社日立製作所大みか工場内 (72)発明者 松崎 健二 茨城県日立市大みか町五丁目２番１号 日 立プロセスコンピュータエンジニアリング 株式会社内 (72)発明者 田村 清一 茨城県日立市大みか町五丁目２番１号 日 立プロセスコンピュータエンジニアリング 株式会社内 (72)発明者 鈴木 淳 茨城県日立市大みか町五丁目２番１号 日 立プロセスコンピュータエンジニアリング 株式会社内

Claims (5)

【特許請求の範囲】
1. 【請求項１】 １つのリモートプロシジャコールの要求
   に対応し、グループ化された複数のサーバを呼び出すリ
   モートプロシジャコール処理方法において、 前記サーバグループの構成の変更に際し、追加または削
   除する変更サーバの変更情報を、前記サーバグループに
   所属する任意のサーバが保持し、このサーバが各々のリ
   モートプロシジャコールの要求元から出された実行要求
   に対応する実行結果を要求元に返すときに、前記実行結
   果に前記変更情報を付加することを特徴とするリモート
   プロシジャコール処理方法。
2. 【請求項２】 １つのリモートプロシジャコールの要求
   に対応し、グループ化された複数のサーバを呼び出すリ
   モートプロシジャコール処理方法において、 前記サーバグループの任意の１つにグループ構成の変更
   が通知され、その通知を受け取ったサーバが追加または
   削除する変更サーバの変更情報を保持し、リモートプロ
   シジャコールの要求元からグループ化された複数のサー
   バへプロシジャ実行要求が出されると、前記変更情報を
   保持するサーバは前記実行要求の１つを受け取りそれに
   対応するプロシジャの実行結果を応答メッセージとして
   前記要求元に返す際に前記変更情報を付加し、前記要求
   元は自らが呼び出すサーバグループのメンバを前記変更
   情報に基づいて変更することを特徴とするリモートプロ
   シジャコール処理方法。
3. 【請求項３】 １つのリモートプロシジャコールの要求
   に対応し、グループ化された複数のサーバを呼び出すリ
   モートプロシジャコール処理方法において、 前記サーバグループの任意の１つにグループ構成の変更
   が通知され、その通知を受け取ったサーバが自らが保持
   している変更情報をインクリメントし、一方リモートプ
   ロシジャコール要求元は、グループ化された各サーバへ
   送信するプロシジャの実行要求に、呼び出すサーバ毎に
   記憶している現在の変更情報を付加して送信し、 前記サーバの各々は前記実行要求の１つを受信すると、
   それに対応するプロシジャの実行を行なうと共に、実行
   要求に付加されている変更情報と自らの保持する変更情
   報を比較して不一致のときに、前記要求元に返送する応
   答メッセージに前記実行結果と共に変更フラグをセット
   し、 前記応答メッセージを受信した要求元は、前記変更フラ
   グがセットされているとき、自分が呼び出すサーバグル
   ープのメンバを変更することを特徴とするリモートプロ
   シジャコール処理方法。
4. 【請求項４】 １つのリモートプロシジャコールの要求
   に対応し、グループ化された複数のサーバを呼び出すに
   あたり、前記サーバグループのメンバの中からリモート
   プロシジャコール要求元によって任意に選択した１つの
   サーバを代表して呼び出し、この呼び出された代表サー
   バは自らの処理を実行するとともに、前記要求元から要
   求された内容を複製して残りのメンバのサーバを呼び出
   すリモートプロシジャコール処理方法において、 前記サーバグループの任意の１つにグループ構成の変更
   が通知され、その通知を受け取り追加または削除する変
   更サーバの変更情報を保持しているサーバは、前記要求
   元から前記代表サーバへプロシジャの実行要求が出さ
   れ、前記代表サーバから複製の要求内容を転送されたと
   き、そのプロシジャ実行による実行結果に前記変更情報
   を付加した応答メッセージを前記代表サーバに返送し、
   前記代表サーバは、自分が呼び出すサーバグループのメ
   ンバを前記変更情報に基づいて変更することを特徴とす
   るリモートプロシジャコール処理方法。
5. 【請求項５】 請求項１〜４のいずれか１項において、 前記グループ構成の変更として、前記サーバグループに
   新規サーバを追加し、前記新規サーバの追加を検知した
   リモートプロシジャコールの各要求元が、このときまで
   処理要求先としていたサーバと前記新規サーバのいずれ
   かを新たな処理要求先とするか選択し、プロシジャ実行
   側が行う処理を前記グループ内のサーバ間で分散させる
   ことを特徴とするリモートプロシジャコール処理方法。