JP3592016B2 - Remote procedure call processing method - Google Patents
Remote procedure call processing method Download PDFInfo
- Publication number
- JP3592016B2 JP3592016B2 JP35048896A JP35048896A JP3592016B2 JP 3592016 B2 JP3592016 B2 JP 3592016B2 JP 35048896 A JP35048896 A JP 35048896A JP 35048896 A JP35048896 A JP 35048896A JP 3592016 B2 JP3592016 B2 JP 3592016B2
- Authority
- JP
- Japan
- Prior art keywords
- server
- rpc
- processing
- group
- request
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Landscapes
- Multi Processors (AREA)
- Computer And Data Communications (AREA)
Description
【0001】
【発明の属する技術分野】
本発明は、分散処理システムで用いられる通信処理技術、とりわけ依頼応答通信の1つであるリモートプロシジャコール(以下、RPCと略称)の処理技術に係わり、特に、サーバをグループした構成のシステムにおいて、サーバグループの構成を変更する方法に関する。
【0002】
【従来の技術】
RPCは特にクライアント・サーバシステムにおける通信技術として定着し、クライアントからサーバへの1対1の依頼・応答通信を行なうものである。たとえば、複数の情報処理装置がネットワークを介して相互に接続された分散処理システムにおいて、ある処理装置内に存在するクライアントが、自分の処理装置内に存在するプロシジャ呼び出しと同じ手法によって他の処理装置内に存在するサーバー側が提供するプロシジャを呼び出し、その実行結果を受けとる。代表的なRPCとしては、OSF(Open Software Foundation)のDCE(Distributed Computing Environment)での採用例がある。以下では、この例をDCE/RPCと呼ぶ。
【0003】
DCE/RPCでは、ディレクトリ・サーバと呼ばれるアプリケーションサーバが、分散処理システム内に存在するすべてのアドレス情報を管理している。クライアントはこのディレクトリ・サーバに問い合わせて呼び出したいサーバのアドレス情報を取得し、RPCによりこのアドレス情報のサーバを呼び出す。DCE/RPCでは、新しいサーバを分散処理システム内に追加する際に、まずディレクトリ・サーバに自分のアドレス情報を登録して、クライアントがサーバのアドレスを参照できるようにしている。
【0004】
【発明が解決しようとする課題】
DCE/RPCなど従来のPRC処理技術では、クライアントはディレクトリ・サーバを検索することでしか、新しいサーバの追加を検出できない。このため、同一処理を行なうサーバをグループ化して多重化サーバとし、クライアントがグループのすべてのサーバにアクセスするような場合(デュアル方式の多重化など)、オンラインでのサーバの追加が困難になる。
【0005】
すなわち、オンラインでの追加には、すべてのクライアントが常時ディレクトリ・サーバを検索していることが必要で、ネットワークやディレクトリ・サーバ、さらにはクライアントの負荷が増大してしまうからである。この結果、ディレクトリ・サーバへのアクセススループットが低下すると、サーバグループへのRPCの処理も遅くなる。
【0006】
この場合、ディレクトリ・サーバの検索周期を長くして負荷の低減をはかると、タイミングによりあるクライアントは追加サーバを呼び出せ、別のサーバは呼び出せないというように、多重化サーバの構成が不整合となる。たとえば多重化ファイルや多重化データベースが不整合な場合、RPC処理ひいてはシステムの信頼性が著しく低下する。
【0007】
サーバの変更をブロードキャスト通信を用いて、即座にすべてのクライアントに伝達する方法が考えられる。このためには、クライアントが常にネットワークからの受信準備をしている必要があり、メモリやマシン負荷が増大する。一般に、クライアント・サーバシステムは、クライアント側に比較的処理能力の低い計算機が用いられることが多く、かかる計算機の負担が大きい。また、ブロードキャストによる送信は必ず受信されるという保証がなく、メッセージ抜けが発生したり、クライアントがサーバの変更情報を受信しない可能性がある。たとえば、クライアントが動作不能状態の場合に変更情報は反映されない。
【0008】
本発明の目的は、従来技術の問題点に鑑み、複数のサーバによるサーバグループの構成の変更を、負荷を増大させることなくクライアント側が直ちに検知できるリモートプロシジャコール処理方法あるいは通信方法を提供することにある。
【0009】
【課題を解決するための手段】
上記の目的は、1つのリモートプロシジャコールの要求に対応し、グループ化された複数のサーバを呼び出すリモートプロシジャコール処理方法において、前記サーバグループの構成の変更に際し、追加または削除する変更サーバの変更情報を、前記サーバグループに所属する任意のサーバが保持し、このサーバが各々のリモートプロシジャコール要求元から出された実行要求に対応する実行結果を要求元に返すときに、前記実行結果に前記変更情報を付加することにより達成される。
【0010】
サーバグループの変更はグループの任意の1つに通知され、それを受け取ったサーバが前記変更情報を保持し、前記プロシジャの実行結果を応答メッセージとして前記要求元に返す際に前記変更情報を付加する。一方、前記要求元は自らが呼び出すサーバグループのメンバを前記変更情報に基づいて変更する。
【0011】
前記要求元は、予め自らが呼び出すサーバグループのアドレス情報と現在の変更情報を保持していて、前記応答メッセージの変更情報と自分の保持する変更情報を比較し、相違するときに自らのグループ情報を変更する。
【0012】
または、リモートプロシジャコール要求元はグループの各サーバに送信する要求メッセージに、各々のプロシジャ実行要求と、保持している現在の変更情報を付加し、それを受け取ったサーバが、プロシジャの実行結果を応答メッセージとして前記要求元に返す際に、自分の保持する変更情報と前記要求メッセージの変更情報が相違するとき、グループ構成変更フラグをセットする。前記要求元は応答メッセージに前記変更フラグがセットされているとき、自分が呼び出すサーバグループのメンバを変更する。
【0013】
他の発明として、前記サーバグループのメンバの中からリモートプロシジャコール要求元によって任意に選択した1つのサーバを代表して呼び出し、この呼び出された代表サーバは自らの処理を実行するとともに、前記要求元から要求された内容を複製して残りのメンバのサーバを呼び出すリモートプロシジャコール処理方法において、前記グループ構成の変更の通知を受け取りその変更情報を保持しているサーバは、前記要求元から前記代表サーバへプロシジャの実行要求が出され、前記代表サーバから複製の要求内容を転送されたとき、そのプロシジャ実行による実行結果に前記変更情報を付加した応答メッセージを前記代表サーバに返送し、前記代表サーバは自らが呼び出すサーバグループのメンバを前記変更情報に基づいて変更することを特徴とする。
【0014】
代表サーバは、メンバの変更を行なったとき、自らの保持する変更情報を更新し、この変更情報とグループ内の各サーバの実行結果を含む応答メッセージをリモートプロシジャコール要求元に送信する。要求元は、代表サーバからの応答メッセージの変更情報と自らの保持するそれを比較し、相違するときに自らのグループ情報を変更する。
【0015】
上記において、前記サーバグループの任意の1つにグループ構成の変更が通知される前に、システム内のサーバのアドレスを管理するネームサーバに対し変更サーバのアドレスを登録または削除し、リモートプロシジャコール要求元あるいは前記代表サーバが前記変更情報を受け取ったときに、前記ネームサーバからアドレス情報を取得し、自らが呼び出すサーバグループのメンバを変更することを特徴とする。
【0016】
このサーバグループのメンバを変更する際に、各サーバが具備するプロシジャの処理内容を識別するための識別子に基づいてグループ構成の制約をチエックし、前記メンバ変更の可否を判定する。たとえば、ある識別子のグループ内での追加または削除に制限がある場合、その制限を越える追加または削除を禁止する。
【0017】
上記サーバは、プロシジャとして提供されるプログラムである。あるいは、実行要求に従い自らの処理を実行しその結果を要求元に返す、または結果は返さないプログラムである。
【0018】
本発明の構成によれば、クライアントとサーバ間で行なわれるRPC処理に、サーバグループの構成変更を検知して、サーバの変更を自動的に行う機能を持たせているので、従来ユーザが行っていた、クライアントが呼び出し先サーバを変更するために必要な情報の収集処理や、この情報を全クライアントに反映するタイミングの制御といった処理を自動化できる。
【0019】
これによれば、多重化サーバグループに既存のサーバと同機能をもつサーバを追加し、多重化サーバの多重度をオンラインで可変することができる。または、前記サーバグループに新規サーバを追加し、前記新規サーバの追加を検知した各々のリモートプロシジャ要求元が、このときまで処理要求先としていたサーバと前記新規サーバのいずれかを新たな処理要求先とするか選択し、プロシジャ実行側が行う処理を前記グループ内のサーバ間で負荷分散させることができる。あるいは、前記サーバグループに新バージョンの新規サーバを追加し、前記新規サーバの追加を検知した各々のリモートプロシジャ実行要求元が、このときまで処理要求先としていたサーバの代わりに前記新規サーバを処理要求先として切り替え、オンラインのバージョンアップを行なうことができる。
【0020】
【発明の実施の形態】
以下、本発明の実施の形態を図面にしたがって詳細に説明する。実施例1は、サーバグループの変更を含むRPC処理、実施例2はサーバ側に変更処理を行なわせる代案、実施例3は間接マルチキャスト方式による代案を示す。また、実施例4はサーバグループの変更をRPCに代えて依頼応答通信によって処理する例を示し、各図を通し原則として、同等の要素には同一の符号を付している。
【0021】
〔実施例1〕
図1は、本発明の一実施例で、RPCを使用した分散システムの機能ブロック図を示す。処理装置2〜8は通信媒体1に接続されて、他の処理装置との間で通信を行う。通信媒体1としては、LAN(Local Area Network)やWAN(Wide Area Network)、あるいはWireless(無線)等の通信回線を用いる。バス型を例に示しているが、二重化バス型、一重ループ型、二重ループ型、リング型などの種々のネットワークを用いることができる。まず、RPCを使用した分散システムの構成について説明し、その後グループへの処理装置の追加を例にして、グループ構成の変更処理を説明する。
【0022】
処理装置2はクライアントとRPC処理部を具備しており、RPCを用いて他の処理装置に対して処理の実行を要求する。処理装置3〜6はサーバとRPC処理部20を具備しており、他の処理装置から要求された処理を実行し、その結果を要求元に返す。処理装置3〜5はグループ化されて多重化サーバ80を構成している。
【0023】
処理装置2のクライアント15は、ユーザによって作成、あるいは利用されるユーザプログラム、アプリケーションプログラム等であり、処理のために必要な情報の参照を、他の処理装置に提供されているサーバのプロシジャに要求するものである。クライアント15は、サーバのプロシジャの実行を要求する際、RPC要求をRPC処理部10に対して発行する。
【0024】
RPC処理部10は、クライアント15のRPC要求処理を代行する。RPC処理部10はクライアント15から発行されたRPC要求を受け、他の処理装置に対し、サーバのプロシジャ実行要求をRPC要求メッセージとして送信し、自らが送信したRPC要求メッセージに対応するプロシジャ実行結果が付されたRPC応答メッセージを受信し、要求元のクライアント15に返す機能を有する。
【0025】
処理装置3は、RPC処理部20とサーバ25とを具備しており、他の処理装置から要求された処理を実行し、その結果を要求元に返す。RPC処理部20は、他の処理装置から送信されたRPC要求メッセージを受信し、実行要求されたサーバのプロシジャを実行し、その実行結果を付したRPC応答メッセージを要求元の処理装置に対して送信する。
【0026】
サーバ25は、RPC処理部20からの要求に応じて自らを実行し、その実行結果をRPC処理部20に返すプログラムであって、プロシジャの形で提供される。サーバ25は、ユーザにより作成あるいは利用されるプログラムであって、クライアントの処理に必要な情報を提供するプログラムである。
【0027】
システム内には、その目的や用途に応じた複数のサーバが種々に組み合わされて存在する。各々のサーバには、自身がどのような内容の処理を行うかを示す処理識別子が付与され、その処理内容が識別される。処理識別子としては、例えば、サーバが提供するプロシジャのプロシジャ名や、プロシジャを一意に識別するID番号などを用いる。図示のサーバ25は、処理識別子がそれぞれ「QSORT」のサーバ401、「ASORT」のサーバ402及び「BSORT」のサーバ403が含まれている。
【0028】
処理装置4〜6も、処理装置3と同様の構成であり、それぞれサーバ35,45,55とRPC処理部30,40,50を具備する。RPC処理部30、40、50は、RPC処理部20と同様の機能を有する。また、サーバ35はサーバ25と同様に、サーバ411〜413からなる。サーバ45はサーバ421,422と、識別子が「CSORT」のサーバ423からなる。さらに、グループ外の処理装置6のサーバ55には、サーバ45と同じサーバ431,432及び433が含まれている。
【0029】
処理装置7は、アドレス管理部60を具備しており、システム内に存在するサーバを具備している処理装置3〜6のアドレスを管理している。アドレス管理部60は、他の処理装置からの要求に応じて、アドレス情報の追加、削除あるいは参照処理を行い、処理結果を要求元に返す。
【0030】
処理装置8は、グループ構成変更通知部70を具備しており、ユーザからのコマンド入力等により、サーバグループの構成変更すなわちサーバグループ80へのサーバの追加あるいは削除の要求を受けつけ、そのイベントをサーバグループ80のサーバへ通知する。
【0031】
本実施例では、サーバ25,35,45からなるサーバグループ80に対し、サーバ55を追加する変更処理を例に、本発明のリモートプロシジャコール処理方式を説明する。サーバのグループ化には種々の手法があるが、本実施例では同一の処理識別子をもつサーバを1つのグループとして扱う。この場合、同一グループ内のすべてのサーバがまったく同じ処理を行う必要はなく、図1の例のように処理内容が異なっていてもよい。
【0032】
次に、グループ化されたサーバへのRPC処理の概要について説明する。クライアント15は、RPC処理部10を介し、サーバグループ80にプロシジャの実行要求を送信する。ただし、RPC処理部10は、クライアント15が発行したRPC要求の内容から、それを処理できるサーバグループとそれに属するサーバを判定し、そのサーバを具備する処理装置すべてに対してRPC要求メッセージを送信する。この判定は、クライアント15がRPC処理部10に対してRPC要求を発行した際、クライアント15から渡された処理識別子を基に行う。
【0033】
サーバグループ80内の処理装置のうち、RPC要求メッセージを受け取った各処理装置のRPC処理部は、要求された処理の実行可能なサーバを実行し、その実行結果をRPC応答メッセージとして要求元の処理装置2に送信する。要求元のRPC処理部10は、RPC要求メッセージを送信した各処理装置からのRPC応答メッセージを受信し、その中から予め決められた論理に基づいて1つのRPC応答メッセージを選択し、そこに含まれているサーバの実行結果をクライアント15に返す。この選択に用いる論理としては、「ランダムに1つを選択する」、「応答内容を基に多数決論理に基づいて1つを選択する」、「最先着のものを選択する」などの論理を用いることができる。
【0034】
次に、各処理装置間で伝送されるRPCメッセージのフォーマットを説明する。図2は、サーバグループの構成変更を通知するRPCメッセージのフォーマットを示す。サーバー変更通知RPCメッセージ100は、グループ構成変更通知部70から送信され、RPC制御ヘッダ部101と変更サーバ処理識別子部103で構成される。RPC制御ヘッダ101にはRPC要求メッセージ、RPC応答メッセージの送受信に伴う処理の制御に必要な情報が格納される。その一部のエリアであるRPC要求内容識別子部102には、RPCで要求される処理内容を受信側のRPC処理部で識別できる処理識別子が格納される。また、送信先アドレス、送信元アドレス、送信通番、要求/応答の識別情報などが格納されるエリアも有している。変更サーバ処理識別子部103には、たとえばサーバグループ80に追加されるサーバ55の処理内容を表わす処理識別子が格納される。
【0035】
図3は、RPC要求メッセージのフォーマットを示す。RPC要求メッセージ110は、RPC処理部10がクライアント15のRPC要求に応じて送信するもので、RPC制御ヘッダ部101とクライアントの要求データ部111から構成される。クライアント要求データ部111には、サーバを実行するためのサーバプロシジャの入出力引数が格納される。
【0036】
図4は、RPC応答メッセージのフォーマットを示している。RPC応答メッセージ120は、RPC処理部20〜50が自処理装置のサーバの実行結果をクライアントへ送信するもので、RPC制御ヘッダ部101、サーバ実行結果データ部122と、グループ構成変更通番部121から構成される。サーバ実行結果データ部122にはサーバの実行結果が格納される。グループ構成変更通番部121は本実施例に特有なもので、サーバの追加などサーバグループの構成変更のたびにインクリメントされるグループ構成変更通番が格納される。
【0037】
グループ構成変更通番(以下、変更通番と呼ぶ)は、サーバを具備する各処理装置が独立に管理している変更通番である。1つの処理装置内には、自身が具備するサーバが所属するグループ毎に、対応する1つの変更通番が保持される。サーバグループの変更履歴を管理するために、サーバの追加や削除など、構成変更の種類に対応した種類別の変更通番が用意されてもよい。本実施例では、サーバを追加または削除する通知RPCメッセージ100を受信したとき、後述のようにこの変更通番がインクリメントされる。
【0038】
一方、RPC要求側は後述のように、予めRPC要求を発行する対象サーバグループの全サーバの変更通番を保持している。そして、RPC応答メッセージ120を受信したとき、メッセージに格納された変更通番と保持している変更通番を比較し、変更通番の不一致によってサーバグループの変更を検知する。
【0039】
以上、システム構成の概略とメッセージフォーマットを説明した。次に、本実施例のリモートプロシジャコールを実施するシステムの詳細な構成と、各部の処理について説明する。なお、処理装置1〜6が具備するRPC処理部、処理装置7が具備するアドレス管理部60、処理装置8が具備するグループ構成変更通知部70の順に説明する。
【0040】
図5は、処理装置の詳細な構成を示す。図示の処理装置2は一例を示したもので、他の処理装置3〜8においても同様な構成としてよい。処理装置2はRPC処理部10と共に、クライアント15とサーバ16の両方を具備している。RPC処理部10は、RPCクライアント処理部11、RPCサーバ処理部12、アドレス管理テーブル13、グループ管理テーブル14を具備している。アドレス管理テーブル13は、各処理装置がサーバグループに属するサーバの情報を格納する。アドレス管理テーブル13は、サーバの処理内容を表す処理識別子と、そのサーバを具備する処理装置のアドレスを格納する。
【0041】
なお、処理装置がクライアント処理専用であれば、サーバ16やRPCサーバ処理部12は不要となる。また、処理装置がサーバ処理専用の場合は、クライアント15とRPCクライアント処理部11は不要であり、本実施例の場合にはアドレス管理テーブル13も不要となる。
【0042】
また、複数のRPC処理部を設けて、クライアントやサーバからのRPC処理を分担してもよい。この場合、他の処理装置からRPC要求メッセージを送出する際の宛先アドレスは、宛先サーバの処理を担当するRPC処理部のアドレス(例えば、この処理装置のアドレスとこのRPC処理部の受信ポート番号)としてもよい。
【0043】
図6に、アドレス管理テーブルの構成を示す。処理識別子部131とアドレス部132とから構成され、各々に格納される情報は、RPC処理部10がアドレス管理部60に要求して取得する。図示は図1における構成の一部を示し、少なくとも3台の処理装置のアドレス情報を格納している。すなわち、「QSORT」で識別されるサーバを有する処理装置が3台で、各アドレスは「133.144.8.159:8080」、「133.144.8.160:8052」及び「133.144.8.161:8031」で与えられている。また、「ASORT」で識別されるサーバを有する処理装置があり、そのアドレス「133.144.9.120:6198」が格納されている。アドレスには、図示のようにIPアドレスと受信ポート番号との組を用いている。
【0044】
図7に、グループ管理テーブルの構成を示す。グループ管理テーブル14は、各処理装置がサーバグループの構成情報を格納している。同図のように、処理識別子部141、アドレス部142及びグループ構成変更通番部143から構成され、これら3つの情報が一組になって使用される。処理識別子部141、アドレス部142には、アドレス管理テーブル13と同様に、サーバの処理内容を表す処理識別子とその処理装置のアドレスが格納される。
【0045】
グループ構成変更通番部143には、サーバグループの構成の変更を管理する変更通番が格納される。図7(a)は図1のグループ構成による一部を示したもので、「QSORT」で識別されるサーバを有する処理装置が3台あり、各々のグループ構成変更通番はそれぞれ、「2」、「3」、「5」である。また、「AQORT」で識別されるサーバを有する処理装置が少なくとも1台あり、そのグループ構成変更通番は「2」である。ここで、同じQSORTに対する変更通番の値「2」,「3」などは、当該アドレスに対応する処理装置での変更回数を反映している。
【0046】
図8は、RPCクライアント処理部の処理を示すフローチャートである。RPCクライアント処理部11は、クライアント15からのRPC要求を代行して処理する。
【0047】
まず、クライアント15からRPC要求を受け付ける(S101)。このとき、RPCクライアント処理部11には、クライアン15から処理要求するサーバの処理識別子と、その処理に必要な引数が渡される。
【0048】
次に、RPC要求を実行できるサーバを具備する処理装置のアドレスを取得するため、アドレス管理テーブル13を検索するが、この際、最初のRPC要求でアドレス管理テーブル13に何も登録されていなかった場合(S102)、アドレス管理テーブル13の初期化処理を行う(S103)。
【0049】
図9は、初期化処理S103を示すフローチャートである。RPCクライアント処理部11はアドレス管理部60に対し、アドレス管理部60に格納された、処理識別子に対応する全てのアドレスの参照を要求するRPC要求メッセージを送信し、応答メッセージに付されたアドレス情報を取得する(S1031)。このアドレス情報をアドレス管理テーブル13に登録する(S1032)と共に、グループ管理テーブル14にも同様にアドレスを登録し、それに対応するグループ構成変更通番に「0」を設定する(S1033)。
【0050】
次に、RPCクライアント処理部11は、アドレス管理テーブル13を検索し、RPC要求を実行できるサーバを具備するすべての処理装置のアドレスを取得すし(S104)、その処理装置の数をカウントする(S105)。この検索は、クライアント15から渡された処理識別子をキーにして行われ、アドレステーブル15から、クライアントから渡された処理識別子と同じ処理識別子をもつ全ての処理装置のアドレスを取得する。そして、サーバグループの1つのサーバへ要求メッセージを送信する(S106)。すなわち、PRC要求メッセージ110のクライアント要求データ部111に、サーバ実行に必要な引数を書き込み、S104で取得したアドレスで与えられる処理装置を宛先に、このRPC要求メッセージ110を送信する。
【0051】
ところで、S104でアドレスを検索した結果、複数の処理装置のアドレスを取得した場合は、取得したすべての処理装置に対してRPC要求メッセージ110を送信する必要がある。そこで、RPC要求メッセージ110の送信後、メッセージ送信済みの処理装置の数をカウントし(S107)、そのカウント値と取得したサーバグループ内のサーバの数を比較する(S110)。比較の結果、カウント値の方が小さい場合は、S104の処理で取得したアドレスの中から、まだRPC要求メッセージ110を送信していないアドレスを選択し(S111)、RPC要求メッセージ110を送信する。このように、S106からS111までの送信処理を繰り返すことによって、サーバグループに属しRPC要求の処理識別子に対応するすべてのサーバに、RPC要求メッセージ110を送信する。
【0052】
以上が、クライアントからのRPC要求の送信処理である。RPC要求メッセージ110を送信すると、RPC要求先のサーバから応答メッセージが返送されてくる。RPCクライアント処理部11は、自らのRPC要求先のサーバからの応答メッセージの受信をチエックし(S108)、以下のように応答受信処理を行なう(S109)。
【0053】
図10に、応答受信処理(S109)のフローチャートを示す。RPCクライアント処理部11は、応答メッセージ120を受信すると(S201)、応答メッセージ120(図4)からメッセージ送信元のアドレスと、RPC要求内容識別子、グループ構成変更通番を取得する(S202)。そして、自己のグループ管理テーブル14を検索し、応答メッセージに付されていたアドレス及びRPC要求内容識別子の両方とも一致するアドレス情報を検出し、そのアドレス情報の変更通番と応答メッセージ120による変更通番を比較する(S203)。
【0054】
比較した結果、両者の値が同じ場合は、サーバグループに変更がなかったと判断し、応答受信処理を終了する。一方、応答メッセージ120による変更通番の値が大きい場合、つまりインクリメントされていた場合は、サーバグループに変更があったと判断し(S204)、応答メッセージ120によるグループ構成変更通番を、グループ管理テーブル14のアドレス情報のグループ構成変更通番部143に格納する(S205)。
【0055】
次に、RPCクライアント処理部11はネットワーク1を経由し、処理装置7のアドレス管理部60に、全てのサーバのアドレスを参照するRPC要求メッセージを送信し、応答メッセージに付されたアドレス情報を取得する(S206)。次に、取得したアドレス情報と自分のアドレス管理テーブル13の内容を比較し、前者に残る差分を追加サーバのアドレスとして取得する(S207)。
【0056】
ここで、アドレス管理部60から取得したアドレス情報は、処理識別子とそれに対応するアドレスの組の集合である。アドレス管理テーブル13も同様である。比較は両集合の構成要素である組単位に行ない、その差分を求める。グループ管理テーブル14以外にアドレス管理テーブル13を設けるのは、この差分処理を簡単にするためである。なお、サーバを削除する変更の場合は、自分のアドレス管理テーブル13の側に残る差分情報が削除サーバのアドレスとなる。
【0057】
次に、本実施例では、S207で取得した追加サーバを具備する処理装置のアドレス情報を、アドレス管理テーブル13に追加する(S208)。さらに、同様にグループ管理テーブル14にも追加し、このとき対応するグループ構成変更通番に初期値「0」を格納する(S209)。
【0058】
以上が応答受信処理(S109)であるが、S104で複数のアドレスが取得された場合、RPC要求メッセージは複数個送信されるため、応答メッセージも同じ数だけ返送されてくる。したがって、RPCクライアント処理部11は、すべての応答メッセージを受信するまで、応答受信処理を繰り返し(S112)、複数の応答メッセージに付されたサーバ実行結果データ122の1つを選択し、クライアント15に渡す(S113)。この選択は「ランダムに選択」、「先着で、1番最初に受信したもの」など、予め決められた論理に基づいて行われる。
【0059】
次に、RPCサーバ処理部12について説明する。RPCサーバ処理部12はサーバ16のRPC要求受付、および応答返送の代行処理を行うと共に、処理装置7のグループ構成変更通知部70から、サーバグループ構成変更を通知するRPCメッセージを受信し、サーバグループ構成の変更情報を保持する。
【0060】
図11は、RPCサーバ処理部の処理を示すフローチャートである。RPCサーバ処理部12は、他の処理装置から送信されたRPC要求メッセージ110を受信すると(S301)、受信メッセージの要求内容を判定する(S302)。この判定は、サーバ変更通知RPCメッセージ100の処理識別子部103を参照することで可能になる。
【0061】
受信メッセージがサーバグループの構成変更を通知するメッセージ場合は、自処理装置のグループ管理テーブル14におけるグループ構成変更通番部143の値をインクリメントする(S303)。これによって、RPC処理部10はサーバグループの構成変更の情報を保持する。そして、RPC要求元であるグループ構成変更通知部70に対し、グループ構成変更の情報を保持する処理の完了を知らせる応答を返す(S304)。
【0062】
一方、ステップS302の判定において、受信した要求メッセージがRPC要求メッセージ110の場合、RPCサーバ処理部12はサーバを実行する(S305)。すなわち、受信したRPC要求メッセージ110のクライアント要求データ部111からサーバの実行に必要な引数等を取得し、サーバ16に渡すと共に、サーバ16のプロシジャを実行する。処理装置内に同一処理識別子をもつサーバが複数ある場合には、ランダムに1つ選択して実行するものとする。
【0063】
サーバ16のプロシジャ実行後、RPCサーバ処理部12はサーバ16から実行結果を受け取り、RPC応答メッセージ120のサーバ実行結果データ部122に格納する。また、グループ構成変更通番部121のエリアには、グループ管理テーブル14のグループ構成変更通部143の値を格納する(S306)。このRPC応答メッセージ120を、RPC要求元であるクライアントへ送信する(S307)。したがって、このRPC要求時までに、グループ管理テーブル14の変更通番がインクリメントされていれば、この変更通番をRPC応答メッセージに格納して送信し、クライアントにサーバグループの変更を知らせることができる。
【0064】
以上、処理装置2〜6が具備するRPC処理部の詳細について、クライアントとサーバの両方を備える図5の処理装置の構成で説明した。上記で、図1のシステム構成におけるRPC処理は、クライアント側は処理装置2、グループサーバ側は処理装置3〜5に読み代えることで理解できる。
【0065】
次に、処理装置7が具備するアドレス管理部60について詳細に説明する。処理装置7のRPC処理部は図示を省略している。アドレス管理部60は、図1に示すシステム内のサーバのアドレスを一括管理しており、ある決められた範囲内(例えば1つのネットワークセグメント内)の処理装置が具備する全てのサーバの処理識別子とその処理装置のアドレスとの対応情報を、自身の管理テーブルに保持している。アドレス管理部60は、他の処理装置からのRPC要求メッセージに応じて、上記情報の追加、削除あるいは参照処理を行い、応答メッセージにより要求元に返す。
【0066】
図12は、アドレス管理部の処理を示すフローチャートである。まず、RPC処理要求を受信すると(S401)、その処理要求内容を判定し(S402)、サーバアドレスの追加、サーバアドレスの削除またはサーバアドレスの検索の何れかを処理する。
【0067】
サーバの追加時には、他の処理装置の要求元、例えばあるクライアントがアドレス管理部60に対して、追加サーバを具備する処理装置のアドレスと追加サーバの処理識別子を付したRPC要求メッセージを送信する。アドレス管理部60は要求内容がサーバアドレスの追加と判定すると、処理装置7が具備する管理テーブルに、RPC要求メッセージに付されていたアドレスと処理識別子を追加し(S403)、追加処理の成否を応答メッセージとして要求元に送信する(S404)。
【0068】
アドレス管理部60は同一の処理識別子をもつサーバを1つのサーバグループとして管理する。したがって、アドレスとサーバが属するサーバグループとを管理するため、アドレスと処理識別子を対応付けて追加する。
【0069】
次に、サーバの削除時には、他の処理装置内の要求元が、削除するアドレスとサーバの処理識別子を付したRPC要求メッセージを送信する。アドレス管理部60は削除要求であると判定すると(S402)、RPC要求メッセージに付された処理識別子とアドレスの組みと同一のアドレス情報を、自身が具備するテーブルから削除し(S405)、削除処理の成否を応答メッセージとして要求元へ送信する(S406)。
【0070】
次に、ある処理の実行可能なサーバを有する処理装置のアドレスを参照する際には、他の処理装置内の要求元がその処理の内容を示す処理識別子を付したRPC要求メッセージを、アドレス管理部60に送信する。要求内容がアドレスの参照と判定されると(S402)、アドレス管理部60が具備する管理テーブルを検索し、RPC要求メッセージに付された処理識別子と同じ処理識別子に対応付けられたアドレスを取り出し(S407)、RPC応答メッセージに付して要求元に送信する(S408)。
【0071】
ステップS407の検索よって、複数のアドレスが取得された場合は1つのアドレスをランダムに選択してもよいし、すべてのアドレスをRPC応答メッセージに付して送信してもよい。
【0072】
次に、処理装置8が具備するグループ構成変更通知部70について説明する。処理装置8のRPC処理部は図示を省略している。グループ構成変更通知部70は、ユーザからのコマンド入力等により指定のサーバグループの構成変更の要求を受け付ける。たとえば、コマンドによりサーバグループ80の構成変更の要求が行なわれ、このコマンドの引数として、追加または削除されるサーバを具備する処理装置のアドレスや、サーバの処理識別子などの情報が、グループ構成変更通知部70に与えられる。
【0073】
グループ構成変更通知部70は、このコマンドを受け付けると、処理装置7のアドレス管理部60に対して、アドレスの変更を要求するRPC要求メッセージを送信する。たとえば、新規サーバを具備する処理装置のアドレスの追加を要求するRPC要求メッセージを送信し、アドレス管理部60にアドレスを登録すると共に、サーバグループ構成変更を通知するRPCメッセージを、指定のサーバグループ80に送信する。サーバグループ80に属する処理装置3〜5は、このサーバグループ構成変更を通知するRPCメッセージを受信し、自身のアドレス管理テーブル13及びグループ管理テーブル14に、サーバグループ構成の変更情報を保持する。
【0074】
図13は、グループ構成変更通知部によるサーバ追加処理を示すフローチャートである。グループ構成変更通知部70は、サーバグループへのサーバの追加要求を受け取ると(S501)、アドレス管理部60に、追加対象となるサーバグループに属するサーバのアドレス参照を要求するRPC要求メッセージを送信し、アドレスを取得する(S502)。このとき、グループに属する任意の1つのサーバのアドレスを取得してもよいし、すべてのサーバのアドレスを取得してもよい。後者の場合、グループ構成変更通知部70が任意の1つを選択する。
【0075】
次に、グループ構成変更通知部70は、追加サーバのアドレスの登録を要求するRPC要求メッセージをアドレス管理部60に対して送信し、管理テーブルへのアドレス登録を依頼する(S503)。次に、ステップS502で取得したアドレスのサーバへ、サーバの追加を通知するRPCメッセージ100を送信し(S504)、そのサーバから追加情報を記憶する処理が完了したという応答を受信する(S505)。
【0076】
以上によって、本発明のリモートプロシジャコール処理を実現する、本実施例の基本的な構成と動作が明らかになった。次に、具体的なリモートプロシジャコールについて、グループサーバに対して新規サーバを追加する処理の例を説明する。この処理の全体的な流れは、サーバグループに対してサーバの追加を通知する処理、各クライアント側処理装置における追加サーバの検知処理に大別でき、この2つに分けて説明する。
【0077】
図14は、図1のシステムのRPC処理部を詳細にした構成図で、新規サーバを追加する処理の流れを矢線で示している。また、図15は、クライアント側とサーバ側の各々のグループ管理テーブルの具体的な格納内容を示す説明図である。さらに、図16は、本実施例によって新規サーバを追加するときの全体的な処理を示すフローチャートである。これらの図を参照しながら、本実施例によるサーバの追加処理を説明する。
【0078】
グループ構成変更通知部70は、ユーザから、サーバグループ80へのサーバ55の追加を受付けると、新規サーバ55を具備する処理装置6のアドレスをアドレス管理部60へ登録する。また、グループ構成変更通知部70は、アドレス管理部60からサーバグループ80内の任意の1つのサーバのアドレス、ここではサーバ45のアドレスを取得し、そのアドレスであるRPCサーバ処理部42宛に、矢印201aのようにサーバ追加の通知RPCメッセージ100を送信する(S601)。
【0079】
RPCサーバ処理部42は、サーバ追加の通知RPCメッセージを受信すると、RPCサーバ処理部42内にあるグループ管理テーブル44のグループ構成変更通番を5⇒6にインクリメントし、グループ構成変更通知部70に処理完了の応答メッセージを送信する(S602)。
【0080】
次に、クライアント側の処理装置における追加サーバの検知処理について説明する。図17に、クライアント側における追加サーバの検知処理のフローチャートを示す。
【0081】
クライアント15は、たとえば処理識別子「QSORT」を含むRPC要求メッセージ110をRPCクライアント処理部11に出す。RPCクライアント処理部11は、アドレス管理テーブル13を検索し、サーバグループ80に属する「QSORT」の実行可能なサーバを具備する処理装置3,4,5のアドレスを取得し、矢印205a,b,cのようにRPC要求メッセージを送信する(S701)。このとき、グループ管理テーブル14の「QSORT」をもつ各アドレスに対応する変更通番は、図15のように記憶されている。
【0082】
RPC要求メッセージを受信した処理装置3,4,5のRPCサーバ処理部22,32,42は、RPC要求に応じて矢印206a,b,cのようにサーバを実行し(S702)、サーバの実行結果を矢印207a,b,cと取得する。また、グループ管理テーブル24,34,44内の変更通番を矢印208a,b,cのように取得し、実行結果と変更通番を格納したRPC応答メッセージを矢印209a,b,cのように送信する(S703)。このとき、グループ管理テーブル24,34,44の「QSORT」の変更通番は図15の内容である。
【0083】
RPCクライアント処理部11は、処理装置3,4,5からのRPC応答メッセージを受信し(S704)、RPC応答メッセージ内の変更通番とグループ管理テーブル14内の変更通番を比較し、グループサーバの構成が変更されたか否かを判定する(S705)。この処理は、図10の応答受信処理のステップS204に相当する。
【0084】
ここでは、処理装置5が具備するRPCサーバ処理部42は、上記のようにサーバ追加の通知RPCメッセージを受信し、グループ管理テーブル44の「QSORT」のグループ構成変更通番を5⇒6にインクリメントし、応答メッセージに付加して矢印209cのように送信している。従って、RPCクライアント処理部11が、RPC応答メッセージの変更通番と、自分のグループ管理テーブル13の同一アドレスの変更通番を比較すると、新規サーバの追加が検知できる。
【0085】
新規サーバの追加を検知したRPCクライアント処理部11は、アドレス管理部60からすべてのサーバのアドレス情報を取得し、自分のアドレス管理テーブル13のアドレス情報と比較し、差分として得られるサーバ55のアドレス情報を、アドレス管理テーブル13、グループ管理テーブル14に追加する(S706)。次に、RPCクライアント処理部11は、処理装置3,4,5の各々から受信したRPC応答メッセージの1つを選択し、クライアント15にサーバの実行結果として渡す(S707)。
【0086】
なお、上記ではグループ構成変更通知部70が処理装置8によって具備される構成としているが、どの処理装置が具備していてもよい。例えば、処理装置6がグループ構成変更通知部70を具備していてもよい。このとき、サーバ55が自身の追加要求をグループ構成変更通知部70へ通知し、グループ構成変更通知部70へ追加処理要求を依頼するようにしてもよい。
【0087】
また、図11のステップS302の判定がサーバの追加要求の場合、指定のサーバグループに新規のサーバの追加の可否を判定してから、ステップS303で追加の処理をするようにしてもよい。
【0088】
たとえば、図1のサーバグループ80において、グループ80内で多重化できないサーバがあり、その処理識別子が「CSORT」であるとする。この場合に、サーバ55を追加すると、「CSORT」のサーバが多重化されてしまう。従って、RPCサーバ処理部42は、RPC通知メッセージ100の追加サーバの処理識別子を受け取ると、グループ管理テーブル14の処理識別子と対照し、「CSORT」サーバが多重化される場合には追加処理を中断する。あるいは、サーバグループが完全多重化の構成をとる場合は、グループ管理テーブル14の処理識別子と対照し、追加するサーバの処理識別子が同一であるか判定し、同一でなければ追加不可の応答を返す。
【0089】
このほかにも、追加処理が許されるユーザIDやプログラムIDや認証情報を予めRPCサーバ処理部内に記憶しておき、RPC通知メッセージに要求元のユーザID、プログラムIDまたは認証情報を付加して送信し、受信時にこれらの情報を比較して、追加の要否を判定するようにしてもよい。
【0090】
以上、本実施例の構成によれば、RPCを用いて1つの要求に対応して複数のサーバを並列的に呼び出すクライアント側の計算機は、各々が独立して非同期的に、複数のリモートプロシジャが構成するグループの構成変化を検出し、グループ構成変更処理を行う。また、この検出のための情報は、通常時のRPC応答に付加されてクライアント側に伝達される。したがって、グループ構成変更に際して、これに伴う追加処理メッセージがネットワーク上に集中することがなく、ネットワークの負荷、構成変更に伴い追加されたリモートプロシジャ側の計算機あるいはリモートプロシジャのアドレスを管理するネームサーバ等の負荷を時間的に分散できる。特に、クライアント側計算機がグループ構成の変更の有無を常に監視している必要がなく、自らのRPC要求時に対する応答内容から変更を検知できるので、クライアント側計算機の変更処理に伴う負荷の増大は少ない。
【0091】
また、本実施例によれば、リモートプロシジャ側が多重化サーバを構成し、クライアントが多重化サーバにアクセスしているときに、サーバ追加の前後で各サーバにアクセスするクライアント側計算機を同じにすることができ、グループ構成の変更を行なうことができるので、サーバの内部状態の整合性が保証され、多重化サーバの通信方式として有用である。さらに、サーバの多重度をオンラインに変化させることができる。
【0092】
本実施例では、クライアント側はグループ内の全てのサーバに対してRPC要求を発行している。しかし、グループ内の一部のサーバにRPCを発行するようにしてもよい。これによれば、クライアントが追加サーバを検知したとき、それまでRPCを発行していた要求先のサーバに代えて追加サーバを用い、サーバグループ内で処理の負荷分散を図ることができる。あるいは、要求先の旧バージョンに代えて新バージョンの追加サーバを用い、サーバのバージョンアップをオンラインで行うこともできる。
【0093】
また、サーバはプロシジャの形で提供されていなくてもよい。要求に対し自らの処理を実行し、その実行結果を依頼元に返すプログラムであってもよい。すなわち、実行結果を依頼元に返すタイミングが、必ずしも自らの処理の実行終了時である必要はなく、自らの処理の実行途中に何らかのデータを依頼元に返すプログラムであってもよい。さらに、サーバが処理要求に応じて実行するプログラムは、必ずしも処理結果を出力するものである必要はない。処理終了時あるいは処理開始時等に、サーバ側のRPC処理部が実行結果データ部にデータを何も格納しないで、RPC応答メッセージを返すようにしてもよい。
【0094】
さらに、本実施例では同一の処理識別子は同一の処理内容を表すものとして、図1のように多重化サーバのグループ構成を示したが、これに限られるものではない。RPCではサーバが保持するプロシジャの名前や処理内容に関わらず、異なる名前や処理を行なうプロシジャをもつサーバであっても、同一の処理識別子をもつことが可能である。このような識別子の付与を行なった場合、送信側はグループ内の各サーバが保持するプロシジャの内容を意識しないで送信メッセージを送ることができるので、送信側の負荷低減をはかれる等のメリットがある。
【0095】
〔第2の実施例〕
本実施例はグループ構成の変更の有無の検出を、第1の実施例とは異なりサーバ側で行なう。すなわち、クライアントがサーバへRPCを発行する際に、RPC要求メッセージにクライアントが保持している変更通番を格納して送出し、サーバ側がその変更通番と、自処理装置のグループ管理テーブルに記憶している変更通番を比較して、グループ構成の変更の有無を検出する。以下、第1の実施例と異なる部分を中心に説明する。なお、システム構成は第1の実施例と同じであり、以下では図14の構成を参照する。
【0096】
図18に、クライアント側の処理装置が送出するRPC要求メッセージのフォーマットを示す。第1の実施例におけるRPC要求メッセージ(図3)に、クライアントが保持している変更通番を格納する、グループ構成変更通番部112を追加している。
【0097】
図19に、サーバ側の処理装置がクライアント側へ実行結果を返すRPC応答メッセージのフォーマットを示す。第1の実施例のRPC応答メッセージ(図4)に、サーバグループにおける構成変更の有無を知らせる変更フラグ部123を追加している。
【0098】
RPCクライアント処理部11が行う処理について説明する。まず、第1の実施例による処理フロー(図8)のステップS106において、RPCクライアント処理部11がサーバへRPC要求メッセージを発行する際に、要求先サーバのアドレスに対応する変更通番をグループ管理テーブル14から取り出し、図18(b)のように、RPC要求メッセージのグループ構成変更通番部112に格納する。
【0099】
図20は、本実施例によるRPCクライアント処理部の応答受信処理のフローチャートである。RPCクライアント処理部11は、サーバからRPC応答メッセージ120を受信すると(S801)、変更フラグ部123を調べ、サーバグループに追加があったか否かを判定する(S802)。追加フラグがセット(ON)されていれば、サーバグループ80に変更があったと判断し、S803〜S807の処理を行う。ここで、ステップS803〜S807の処理は、第1の実施例の図10に示したステップS205〜S209の処理と同様である。
【0100】
次に、サーバー側のRPCサーバ処理部が行う処理について説明する。図21は、本実施例によるRPCサーバ処理部の応答受信処理のフローチャートで、例えば処理装置5のRPCサーバ処理部42によって実行される。同図で、ステップS901〜S904は、第1の実施例(図11)におけるS201〜S204と同様の処理となる。
【0101】
ステップS902の判定で、要求メッセージがサーバの変更でない場合、まずクライアントから要求されたサーバを実行する(S905)。そのサーバから実行結果を受け取ると、RPC要求メッセージ120に付加されていた変更通番を取得し(S906)、自処理装置5のグループ管理テーブル44に管理している変更通番と比較する(S907)。比較の結果、自分の変更通番の方が大きければ、図19(b)のようにRPC応答メッセージのサーバ追加フラグをONにし(S910)、RPC応答メッセージ120に自分の変更通番を付加して(S911)、サーバの実行結果と共にクライアント側の処理装置2へ返送する(S912)。
【0102】
一方、取得した変更通番が自分の変更通番以下であれば、RPC応答メッセージのサーバ追加フラグをOFFにし(S909)、RPC応答メッセージ120に自分の変更通番を付加し(S911)、サーバの実行結果と共に要求元の処理装置へ返送する。
【0103】
この後、RPCクライアント処理部11は、応答メッセージ120の追加フラグのON/OFFを判定し、ステップS803〜S807により、グループ管理テーブル14とアドレス管理テーブル13を更新する。
【0104】
なお、上記ではサーバ追加の例を説明したが、サーバ削除の場合はサーバ削除フラグを用意しそのON/OFFを判定する。あるいは、サーバの追加、削除に共用する変更フラグを用意し、ステップS907における比較の結果、取得したグループ構成変更通番が自分の保持する変更通番と相違する場合に、グループ構成に変更があると判定して、ステップS803〜S807の処理を行なうようにしてもよい。
【0105】
本実施例によれば、サーバグループ構成変更の有無の判定をサーバ側で行っているので、クライアントの処理が軽減できる。特に、不正なサーバの変更要求が連続するような場合に、クライアントのオーバーロードを回避できる。
【0106】
〔第3の実施例〕
次に、第3の実施例について説明する。第1、第2の実施例では、クライアントの処理装置がサーバグループのサーバを呼び出す際に、複数のサーバに対して直接RPC要求メッセージを送信するマルチキャスト方式を用いていた。これに対し、本実施例では、クライアントの処理装置はサーバグループの任意のサーバに対してRPC要求メッセージを送信し、このメッセージを受信した処理装置が宛先であるサーバを実行するとともに、グループの残りのすべてのサーバに対してRPC要求メッセージを転送し、その転送メッセージを受信した各処理装置が自身のサーバを実行する、という間接マルチキャスト方式を用いる。
【0107】
図22は、本実施例によるサーバ追加を説明するためのシステム構成図で、詳細は図14と同様になる。図23は、本実施例によるRPC要求メッセージと応答メッセージのフォーマットを示す。同図(a)のRPC要求メッセージでは、複製の転送による場合を区別するために、図3のRPC要求メッセージに、転送メッセージフラグ部113を追加している。また、同図(b)の応答メッセージでは、変更フラグ部123を設け、グループ構成変更通番部121は削除している。
【0108】
次に、本実施例でのサーバ追加の処理を説明する。この処理の全体的な流れは、サーバグループに対してサーバの追加を通知する処理と、各々のクライアント側処理装置における追加サーバの検知処理に分けることができる。前者の処理は第1の実施例と同様であるので、以下では後者の処理のみを説明する。
【0109】
RPCクライアント処理部11は、グループ内のマスタサーバとして予め設定されている任意の1つ、ここでは処理装置3のサーバ25に対してRPC要求メッセージを送信する。なお、マスターとなる処理装置3のグループ管理テーブル24には、グループ80のすべてのサーバを呼び出せるように、そのアドレスと変更通番を管理している。
【0110】
クライアントからのRPC要求メッセージを受け取った処理装置3のRPCサーバ処理部22は、転送メッセージフラグがOFFとなっていることから、転送メッセージでないと判断すると、グループ内の他のすべてのサーバ宛てに転送RPC要求メッセージを送信し、送信された転送RPC要求メッセージは、それぞれ処理装置4、5によって受信される。
【0111】
RPC要求メッセージを受信した処理装置4,5内のRPCサーバ処理部32,42は、RPC要求に応じてサーバを実行し、サーバの実行結果を取得し、また、グループ管理テーブル24,34,44内の変更通番を取得し、それらを格納したRPC応答メッセージを、転送RPC要求メッセージを送出したRPCサーバ処理部22へ送信する。
【0112】
RPCサーバ処理部22は、自分にグループ構成変更通知のあるときはグループ管理テーブル24を更新する。また、処理装置4,5からのRPC応答メッセージ内の変更通番とグループ管理テーブル24内の変更通番を比較し、グループ構成に変更が有るか否かを判定する。変更がある場合には、グループ管理テーブル24を更新する。
【0113】
RPCサーバ処理部20は、クライアントに自分のサーバ25の処理結果と他の転送先サーバ35,45からの実行結果を送信する際、先にグループ管理テーブル24を更新している場合は、変更フラグ部123に変更フラグをセット(ON)する。
【0114】
処理装置3からRPC応答メッセージを受信したRPCクライアント処理部11は、メッセージの変更フラグがONであればサーバーグループ80の構成に変更があると判断し、アドレス管理部60からすべてのサーバのアドレスを取得し、アドレス管理テーブル13のアドレスと比較する。その結果、差分となるサーバ55のアドレスを、アドレス管理テーブル13およびグループ管理テーブル14に追加する。次に、RPCクライアント処理部11は、RPC応答メッセージ内の処理装置3,4,5のサーバ実行結果から1つを選択し、クライアント15に渡す。なお、本実施例では、クライアント側にはグループ管理テーブルが不要となる。
【0115】
本実施例によれば、サーバグループにRPC要求を行なう場合に、グループ内で任意に選択した処理装置との間でのみ送受信が行なわれ、グループ内の他の処理装置の残りのすべてのサーバに対してRPC要求メッセージを転送して処理する間接マルチキャスト方式を用いるので、クライアントやネットワークの処理付加を低減できる。
【0116】
〔第4の実施例〕
次に、第4の実施例について説明する。第1、第2、第3の実施例では、クライアントとサーバとの通信方法としてRPCを用いた。RPCは複数の情報処理装置がネットワークを介して相互に接続された分散処理システムにおいて、ある処理装置内に存在するクライアントが、自分の処理装置内に存在するプロシジャ呼び出しと同じ手法によって他の処理装置内に存在するサーバ側が提供するプロシジャを呼び出し、その実行結果を受け取る処理手続を行う依頼応答通信方法である。しかしながら、RPCは内部的には、(1)クライアントからサーバへの依頼メッセージの通信、(2)サーバからクライアントへの応答メッセージの通信を組合せ、その上で、(3)サーバ側の実行可能なプログラムはプロシジャの形で提供され、(4)クライアントが、自分の処理装置内に存在するプロシジャ呼び出しと同じ手法によって他の処理装置内に存在するサーバ側が提供するプロシジャを呼び出すことができるように処理することを特徴とした、依頼応答通信の1つの形態である。
【0117】
本発明の主旨は、クライアントとサーバ間の通信方法として、特にRPCに限らなくとも、クライアントとサーバ間の通信方法が、前記リモートプロシジャコール要求/応答の代わりに、それぞれ少なくとも(1)クライアントからサーバへの実行依頼メッセージの通信、(2)サーバからクライアントへの応答メッセージの通信を組み合わせた依頼応答通信であれば適用可能である。
【0118】
第1、第2、第3のいずれの実施例においても、リモートプロシジャコール要求の代わりに依頼メッセージ、リモートプロシジャコール応答の代わりに応答メッセージを用いてもよい。この場合、第1、第2、第3の各実施例におけるシステム構成及び処理装置内の構成は、第4の実施例においても同様であり、処理内容についても同様でよい。また、RPCメッセージのフォーマットについても、RPC制御ヘッダ部を依頼応答通信のための制御情報を含む、依頼応答通信制御ヘッダ部に変更するだけでよい。
【0119】
以上のように、本発明の主旨は、クライアントとサーバとの通信方法を特にRPCに限らなくとも、クライアントとサーバとの通信方法が依頼応答通信であれば適用可能であり、RPCの場合と同様の効果を得ることができる。
【0120】
【発明の効果】
本発明によれば、クライアント側の計算機は動作中にサーバグループの構成変化を検知することができる。従って、システム管理者はアプリケーションシステムを稼働させながら、サーバグループにサーバを追加し、新たなサービスを追加したり、多重度を増やしたり、サーバのバージョンアップを行ったりすることができ、システムの拡張性、保守性、耐故障性を向上させることができる。また、アプリケーションシステムを稼働させながら、サーバグループからサーバを削除し、不要サーバを切り離すことができ、システムの縮小性、保守性を向上させることができる。
【0121】
また、グループの構成変化の検出情報は、RPC応答または依頼応答に付加されて送受信されるので、変更に伴うネットワーク上の負荷集中を生じない。さらに、クライアント側計算機がグループ構成の変更の有無を常に監視している必要はなく、自らのRPC要求または依頼通信時に対する応答内容から変更を検知できるので、クライアント側計算機の変更処理に伴う負荷の増大はない。
【0122】
また、本発明によれば、リモートプロシジャ側が多重化サーバを構成している場合、サーバ追加の前後で各サーバにアクセスするクライアント側計算機を同じにすることができ、サーバの内部状態の整合性が保証されるので、多重化サーバの通信方式として有用である。
【図面の簡単な説明】
【図1】本発明のリモートプロシジャコール処理方式を適用するシステム構成の一例を示すブロック図。
【図2】一実施例によるサーバ変更通知RPCメッセージのフォーマット図。
【図3】一実施例によるRPC要求メッセージのフォーマット図。
【図4】一実施例によるRPC応答メッセージのフォーマット図。
【図5】クライアントとサーバを併設する処理装置の構成図。
【図6】アドレス管理テーブルの内容を示すフォーマット図。
【図7】グループ管理テーブルの内容を示すフォーマット図。
【図8】第1の実施例によるRPCクライアント処理部の全体的な処理動作を示すフローチャート。
【図9】テーブル初期化処理の詳細を示すフローチャート。
【図10】RPCクライアント処理部の応答受信処理を示すフローチャート。
【図11】第1の実施例によるRPCサーバ処理部の処理動作を示すフローチャート。
【図12】アドレス管理部の処理動作を示すフローチャート。
【図13】グループ構成変更通知部の処理動作を示すフローチャート。
【図14】サーバ追加処理の流れを説明するシステム構成図。
【図15】図14のシステム構成において、各グループ管理テーブルの具体的な管理内容を示す説明図。
【図16】サーバ側でのサーバ追加処理の流れを説明するフローチャート。
【図17】クライアント側でのサーバ追加の検知処理を示すフローチャート。
【図18】第2の実施例におけるRPC要求メッセージを示すフォーマット図。
【図19】第2の実施例におけるRPC応答メッセージを示すフォーマット図。
【図20】第2の実施例におけるRPCクライアント処理部の応答受信処理の処理動作を示すフローチャート。
【図21】第2の実施例におけるRPCサーバ処理部の処理動作を示すフローチャート。
【図22】第3の実施例における間接マルチキャスト方式の処理の流れを説明するシステム構成図。
【図23】第3の実施例におけるRPC要求メッセージ及び応答メッセージを示すフォーマット図。
【符号の説明】
1…通信媒体(ネットワーク)、2〜8…処理装置(計算機)、10,20,30,43,50…RPC処理部、11…RPCクライアント処理部、12,22,32,42,52…RPCサーバ処理部、13…アドレス管理テーブル、14,24,34,44,54…グループ管理テーブル、143…グループ構成変更通番部、25,35,45,55,401,402,403,411,412,413,421,422,423,431,432,433…サーバ、60…アドレス管理部、70…グループ構成変更通知部、80…サーバグループ、100…サーバ変更通知RPCメッセージ、101…RPC制御ヘッダ部、102…RPC要求内容識別子部、103…変更サーバ処理識別子部、110…RPC要求メッセージ、111…クライアント要求データ部、120…RPC応答メッセージ、121…グループ構成変更通知部、122…サーバ実行結果データ部。[0001]
TECHNICAL FIELD OF THE INVENTION
The present invention relates to a communication processing technique used in a distributed processing system, particularly to a processing technique of a remote procedure call (hereinafter, abbreviated as RPC), which is one of request-response communication, and particularly to a system in which servers are grouped. It relates to a method of changing the configuration of a server group.
[0002]
[Prior art]
RPC is particularly established as a communication technique in a client-server system, and performs one-to-one request / response communication from a client to a server. For example, in a distributed processing system in which a plurality of information processing apparatuses are connected to each other via a network, a client existing in one processing apparatus uses another processing apparatus in the same manner as a procedure call existing in its own processing apparatus. Calls a procedure provided by the server side that exists in, and receives the execution result. As a typical RPC, there is an example of adoption in DCE (Distributed Computing Environment) of OSF (Open Software Foundation). Hereinafter, this example is referred to as DCE / RPC.
[0003]
In DCE / RPC, an application server called a directory server manages all address information existing in a distributed processing system. The client inquires of this directory server to obtain the address information of the server to be called, and calls the server of this address information by RPC. In DCE / RPC, when a new server is added to a distributed processing system, first, its own address information is registered in a directory server so that a client can refer to the address of the server.
[0004]
[Problems to be solved by the invention]
In a conventional PRC processing technique such as DCE / RPC, a client can detect the addition of a new server only by searching a directory server. For this reason, when servers that perform the same processing are grouped into a multiplexed server and a client accesses all servers in the group (such as dual multiplexing), it becomes difficult to add a server online.
[0005]
That is, online addition requires that all clients always search the directory server, which increases the load on the network, the directory server, and the clients. As a result, when the access throughput to the directory server decreases, the processing of the RPC to the server group also slows down.
[0006]
In this case, if the search period of the directory server is lengthened to reduce the load, the configuration of the multiplexing server becomes inconsistent, such that one client can call an additional server and another server cannot be called depending on the timing. . For example, if the multiplexed file or the multiplexed database is inconsistent, the reliability of the RPC process and the system is significantly reduced.
[0007]
A method is conceivable in which server changes are immediately transmitted to all clients using broadcast communication. For this purpose, the client must always prepare for reception from the network, and the memory and machine load increase. In general, in a client-server system, a computer having relatively low processing capacity is often used on the client side, and the load on such a computer is large. Further, there is no guarantee that the transmission by the broadcast is always received, and there is a possibility that a message may be missing or the client may not receive the change information of the server. For example, when the client is inoperable, the change information is not reflected.
[0008]
SUMMARY OF THE INVENTION An object of the present invention is to provide a remote procedure call processing method or a communication method in which a client can immediately detect a change in the configuration of a server group by a plurality of servers without increasing the load, in view of the problems of the related art. is there.
[0009]
[Means for Solving the Problems]
The object of the present invention is to provide a remote procedure call processing method for calling a plurality of grouped servers in response to a request of one remote procedure call. In the remote procedure call processing method, change information of a change server to be added or deleted when the configuration of the server group is changed. Is held by an arbitrary server belonging to the server group, and when the server returns an execution result corresponding to an execution request issued from each remote procedure call request source to the request source, the change is made to the execution result. This is achieved by adding information.
[0010]
Any change in the server group is notified to any one of the groups, and the server that has received the change holds the change information and adds the change information when returning the execution result of the procedure to the request source as a response message. . On the other hand, the request source changes the member of the server group to be called by itself based on the change information.
[0011]
The requester previously holds the address information and the current change information of the server group to be called by itself, compares the change information of the response message with the change information held by itself, and, when the difference is different, the own group information. To change.
[0012]
Alternatively, the remote procedure call request source appends each procedure execution request and the current change information held to the request message to be sent to each server in the group, and the server that has received it adds the procedure execution result to the request message. When the change information held by itself and the change information of the request message are different when returning to the request source as a response message, a group configuration change flag is set. When the change flag is set in the response message, the requester changes the member of the server group to call.
[0013]
According to another aspect of the present invention, a remote procedure call requester calls a server arbitrarily selected from members of the server group on behalf of the server group, and the called representative server executes its own processing and In the remote procedure call processing method for duplicating the contents requested from the above and calling the server of the remaining members, the server receiving the notification of the change in the group configuration and holding the change information is the representative server from the request source. When the execution request of the procedure is issued and the content of the request for copying is transferred from the representative server, a response message in which the change information is added to the execution result by the procedure execution is returned to the representative server, and the representative server returns Change the members of the server group that it calls based on the change information And wherein the door.
[0014]
When the representative server changes the member, the representative server updates its own change information, and transmits a response message including the change information and the execution result of each server in the group to the remote procedure call request source. The request source compares the change information of the response message from the representative server with that held by itself, and changes its own group information when there is a difference.
[0015]
In the above, before any one of the server groups is notified of the change in the group configuration, the address of the change server is registered or deleted from a name server that manages the address of the server in the system, and a remote procedure call request is made. When the original server or the representative server receives the change information, it acquires address information from the name server and changes the member of the server group to be called by itself.
[0016]
When the members of the server group are changed, the constraints of the group configuration are checked based on the identifiers for identifying the processing contents of the procedures provided in each server, and it is determined whether or not the members can be changed. For example, if there is a restriction on addition or deletion of a certain identifier within a group, addition or deletion exceeding the limit is prohibited.
[0017]
The server is a program provided as a procedure. Alternatively, it is a program that executes its own process in accordance with the execution request and returns the result to the request source, or does not return the result.
[0018]
According to the configuration of the present invention, the RPC process performed between the client and the server has a function of detecting a server group configuration change and automatically changing the server. Further, it is possible to automate a process of collecting information necessary for a client to change a called server and a process of controlling a timing of reflecting this information to all clients.
[0019]
According to this, a server having the same function as an existing server can be added to the multiplexing server group, and the multiplexing degree of the multiplexing server can be varied online. Alternatively, a new server is added to the server group, and each remote procedure request source that has detected the addition of the new server specifies one of the server that has been the processing request destination up to this point and the new server as the new processing request destination. , And the processing performed by the procedure execution side can be load-balanced among the servers in the group. Alternatively, a new version of a new server is added to the server group, and each remote procedure execution request source that has detected the addition of the new server requests the new server for processing in place of the server that has been the processing request destination until this time. You can switch to the first and upgrade online.
[0020]
BEST MODE FOR CARRYING OUT THE INVENTION
Hereinafter, embodiments of the present invention will be described in detail with reference to the drawings. The first embodiment illustrates an RPC process including a change of a server group, the second embodiment illustrates an alternative in which the server performs the change process, and the third embodiment illustrates an alternative using the indirect multicast method. Further, the fourth embodiment shows an example in which a server group change is processed by request / response communication instead of RPC, and in principle, equivalent elements are denoted by the same reference symbols throughout the drawings.
[0021]
[Example 1]
FIG. 1 is a functional block diagram of a distributed system using RPC according to an embodiment of the present invention. The
[0022]
The
[0023]
The
[0024]
The
[0025]
The
[0026]
The
[0027]
In the system, a plurality of servers corresponding to the purpose and use exist in various combinations. Each server is provided with a processing identifier indicating what kind of processing the server itself performs, and the processing contents are identified. As the process identifier, for example, a procedure name of a procedure provided by the server, an ID number for uniquely identifying the procedure, and the like are used. The illustrated
[0028]
The
[0029]
The processing device 7 includes an
[0030]
The
[0031]
In the present embodiment, a remote procedure call processing method according to the present invention will be described with an example of a change process of adding a
[0032]
Next, an outline of the RPC process for the grouped servers will be described. The
[0033]
Among the processing devices in the
[0034]
Next, the format of the RPC message transmitted between the processing devices will be described. FIG. 2 shows a format of an RPC message for notifying a server group configuration change. The server change
[0035]
FIG. 3 shows a format of the RPC request message. The
[0036]
FIG. 4 shows a format of the RPC response message. The
[0037]
The group configuration change serial number (hereinafter, referred to as a change serial number) is a change serial number managed independently by each processing device including the server. One processing apparatus holds one corresponding change serial number for each group to which the server of the processing apparatus belongs. In order to manage the change history of the server group, a change serial number for each type corresponding to the type of configuration change such as addition or deletion of a server may be prepared. In this embodiment, when the
[0038]
On the other hand, the RPC requesting side holds the change serial numbers of all servers in the target server group that issues the RPC request in advance, as described later. Then, when the
[0039]
The outline of the system configuration and the message format have been described above. Next, a detailed configuration of a system that executes a remote procedure call according to the present embodiment and a process of each unit will be described. The RPC processing units included in the
[0040]
FIG. 5 shows a detailed configuration of the processing apparatus. The illustrated
[0041]
If the processing device is dedicated to client processing, the
[0042]
Also, a plurality of RPC processing units may be provided to share RPC processing from clients and servers. In this case, the destination address when sending the RPC request message from another processing device is the address of the RPC processing unit in charge of processing of the destination server (for example, the address of this processing device and the reception port number of this RPC processing unit). It may be.
[0043]
FIG. 6 shows the configuration of the address management table. The
[0044]
FIG. 7 shows the configuration of the group management table. The group management table 14 stores the configuration information of each processing device in a server group. As shown in the figure, it is composed of a
[0045]
The group configuration change
[0046]
FIG. 8 is a flowchart illustrating the processing of the RPC client processing unit. The RPC
[0047]
First, an RPC request is received from the client 15 (S101). At this time, the processing identifier of the server requesting the processing and the arguments required for the processing are passed from the
[0048]
Next, the address management table 13 is searched in order to obtain the address of the processing device having the server that can execute the RPC request. At this time, nothing was registered in the address management table 13 in the first RPC request. In this case (S102), initialization processing of the address management table 13 is performed (S103).
[0049]
FIG. 9 is a flowchart showing the initialization processing S103. The RPC
[0050]
Next, the RPC
[0051]
By the way, when the addresses of a plurality of processing devices are obtained as a result of the address search in S104, it is necessary to transmit the
[0052]
The above is the process of transmitting an RPC request from a client. When the
[0053]
FIG. 10 shows a flowchart of the response receiving process (S109). Upon receiving the response message 120 (S201), the RPC
[0054]
As a result of the comparison, if the two values are the same, it is determined that the server group has not been changed, and the response receiving process ends. On the other hand, if the value of the change serial number according to the
[0055]
Next, the RPC
[0056]
Here, the address information acquired from the
[0057]
Next, in the present embodiment, the address information of the processing device including the additional server acquired in S207 is added to the address management table 13 (S208). Further, the same is added to the group management table 14, and the initial value “0” is stored in the corresponding group configuration change serial number at this time (S209).
[0058]
The above is the response receiving process (S109). When a plurality of addresses are acquired in S104, a plurality of RPC request messages are transmitted, and therefore, the same number of response messages are returned. Therefore, the RPC
[0059]
Next, the RPC
[0060]
FIG. 11 is a flowchart illustrating the processing of the RPC server processing unit. Upon receiving the
[0061]
If the received message is a message for notifying the server group configuration change, the value of the group configuration change
[0062]
On the other hand, if it is determined in step S302 that the received request message is the
[0063]
After the
[0064]
The details of the RPC processing units included in the
[0065]
Next, the
[0066]
FIG. 12 is a flowchart illustrating the processing of the address management unit. First, when an RPC processing request is received (S401), the contents of the processing request are determined (S402), and any of adding a server address, deleting a server address, or searching for a server address is performed.
[0067]
When a server is added, a request source of another processing device, for example, a client transmits an RPC request message to the
[0068]
The
[0069]
Next, when a server is deleted, a request source in another processing device transmits an RPC request message with an address to be deleted and a processing identifier of the server. If the
[0070]
Next, when referring to the address of a processing device having a server capable of executing a certain process, a request source in another processing device sends an RPC request message with a process identifier indicating the content of the process to an address management. Transmit to the
[0071]
If a plurality of addresses are obtained as a result of the search in step S407, one address may be selected at random, or all addresses may be added to the RPC response message and transmitted.
[0072]
Next, the group configuration
[0073]
Upon receiving this command, the group configuration
[0074]
FIG. 13 is a flowchart illustrating a server addition process by the group configuration change notification unit. Upon receiving the request to add a server to a server group (S501), the group configuration
[0075]
Next, the group configuration
[0076]
From the above, the basic configuration and operation of the present embodiment for realizing the remote procedure call processing of the present invention have been clarified. Next, an example of processing for adding a new server to a group server for a specific remote procedure call will be described. The overall flow of this process can be broadly divided into a process of notifying a server group of the addition of a server and a process of detecting an added server in each client-side processing device. The two processes will be described separately.
[0077]
FIG. 14 is a detailed configuration diagram of the RPC processing unit of the system of FIG. 1, and the flow of processing for adding a new server is indicated by an arrow. FIG. 15 is an explanatory diagram showing the specific storage contents of each of the group management tables on the client side and the server side. FIG. 16 is a flowchart illustrating the overall processing when a new server is added according to the present embodiment. The server addition processing according to the present embodiment will be described with reference to these drawings.
[0078]
When receiving the addition of the
[0079]
Upon receiving the server addition notification RPC message, the RPC
[0080]
Next, detection processing of an additional server in the processing device on the client side will be described. FIG. 17 shows a flowchart of a process of detecting an additional server on the client side.
[0081]
The
[0082]
Upon receiving the RPC request message, the RPC
[0083]
The RPC
[0084]
Here, the RPC
[0085]
Upon detecting the addition of the new server, the RPC
[0086]
In the above description, the group configuration
[0087]
Further, if the determination in step S302 in FIG. 11 is a server addition request, it may be determined whether or not a new server can be added to the specified server group, and then the additional processing is performed in step S303.
[0088]
For example, in the
[0089]
In addition, the user ID, program ID, and authentication information for which additional processing is permitted are stored in the RPC server processing unit in advance, and the RPC notification message is transmitted with the user ID, program ID, or authentication information of the request source added. Then, at the time of reception, these pieces of information may be compared to determine whether additional information is necessary.
[0090]
As described above, according to the configuration of the present embodiment, the client-side computers that call a plurality of servers in parallel in response to one request by using the RPC are independently and asynchronously executed by the plurality of remote procedures. A configuration change of a group to be configured is detected, and a group configuration change process is performed. The information for this detection is added to the normal RPC response and transmitted to the client side. Therefore, when the group configuration is changed, the additional processing message accompanying the change is not concentrated on the network, and the load on the network, the computer on the remote procedure side added with the configuration change or the name server for managing the address of the remote procedure, etc. Can be distributed over time. In particular, it is not necessary for the client computer to constantly monitor whether there is a change in the group configuration, and the client computer can detect the change from the content of the response to the RPC request, so that the increase in the load due to the change processing of the client computer is small. .
[0091]
Further, according to the present embodiment, when the remote procedure configures the multiplexing server and the client is accessing the multiplexing server, the client computer accessing each server before and after adding the server is the same. Since the group configuration can be changed, consistency of the internal state of the server is guaranteed, and this is useful as a communication system for a multiplex server. Further, the multiplicity of the server can be changed to online.
[0092]
In this embodiment, the client issues an RPC request to all servers in the group. However, the RPC may be issued to some servers in the group. According to this, when the client detects the additional server, the additional server can be used in place of the request destination server that has issued the RPC up to that time, and the processing load can be distributed within the server group. Alternatively, the server can be upgraded online using a new version of the additional server in place of the old version of the request destination.
[0093]
Also, the server need not be provided in the form of a procedure. It may be a program that executes its own process in response to a request and returns the execution result to the request source. That is, the timing of returning the execution result to the request source does not necessarily need to be at the end of the execution of the own process, and may be a program that returns some data to the request source during the execution of the own process. Further, the program executed by the server in response to the processing request does not necessarily need to output the processing result. At the end of processing or at the start of processing, the RPC processing unit on the server side may return an RPC response message without storing any data in the execution result data part.
[0094]
Furthermore, in the present embodiment, the same processing identifier represents the same processing content, and the group configuration of the multiplexing server is shown in FIG. 1, but the present invention is not limited to this. In RPC, a server having a different name or a procedure for performing a process can have the same process identifier irrespective of the procedure name or the process content held by the server. When such an identifier is assigned, the transmitting side can send a transmission message without being aware of the contents of the procedure held by each server in the group, so that there is an advantage that the load on the transmitting side can be reduced. .
[0095]
[Second embodiment]
This embodiment differs from the first embodiment in that the presence or absence of a change in the group configuration is detected on the server side. That is, when the client issues an RPC to the server, the change serial number held by the client is stored and transmitted in the RPC request message, and the server stores the change serial number and the group management table of its own processing device. The change sequence numbers are compared to detect whether the group configuration has changed. Hereinafter, a description will be given focusing on portions different from the first embodiment. The system configuration is the same as that of the first embodiment, and the configuration of FIG. 14 will be referred to below.
[0096]
FIG. 18 shows the format of an RPC request message sent by the processing device on the client side. A group configuration change
[0097]
FIG. 19 shows a format of an RPC response message in which the processing device on the server side returns an execution result to the client side. The RPC response message (FIG. 4) of the first embodiment is added with a
[0098]
The processing performed by the RPC
[0099]
FIG. 20 is a flowchart of the response receiving process of the RPC client processing unit according to the present embodiment. Upon receiving the
[0100]
Next, processing performed by the RPC server processing unit on the server side will be described. FIG. 21 is a flowchart of the response receiving process of the RPC server processing unit according to the present embodiment, which is executed by, for example, the RPC
[0101]
If it is determined in step S902 that the request message is not a server change, the server requested by the client is first executed (S905). When the execution result is received from the server, the change serial number added to the
[0102]
On the other hand, if the acquired change serial number is equal to or less than the own change serial number, the server addition flag of the RPC response message is turned off (S909), and the own change serial number is added to the RPC response message 120 (S911). Together with the requesting processing device.
[0103]
Thereafter, the RPC
[0104]
Although an example of server addition has been described above, in the case of server deletion, a server deletion flag is prepared and its ON / OFF is determined. Alternatively, a change flag commonly used for adding or deleting a server is prepared, and if the acquired group configuration change serial number is different from the own change serial number as a result of the comparison in step S907, it is determined that there is a change in the group configuration. Then, the processing of steps S803 to S807 may be performed.
[0105]
According to the present embodiment, since the server determines whether or not there is a change in the server group configuration, the processing of the client can be reduced. In particular, in the case where unauthorized server change requests continue, it is possible to avoid overloading the client.
[0106]
[Third embodiment]
Next, a third embodiment will be described. In the first and second embodiments, when the processing device of the client calls the server of the server group, the multicast method of transmitting the RPC request message directly to a plurality of servers is used. On the other hand, in the present embodiment, the processing device of the client transmits an RPC request message to an arbitrary server in the server group, executes the server to which the processing device that has received this message is the destination, and executes the remaining server in the group. The RPC request message is transferred to all the servers, and each processing device that has received the transfer message executes its own server.
[0107]
FIG. 22 is a system configuration diagram for explaining server addition according to the present embodiment, and details are the same as those in FIG. FIG. 23 shows the format of the RPC request message and the response message according to the present embodiment. In the RPC request message of FIG. 3A, a transfer
[0108]
Next, a server addition process according to the present embodiment will be described. The overall flow of this process can be divided into a process of notifying a server group of addition of a server and a process of detecting an additional server in each client-side processing device. Since the former process is the same as that of the first embodiment, only the latter process will be described below.
[0109]
The RPC
[0110]
Upon receiving the RPC request message from the client, the RPC
[0111]
The RPC
[0112]
The RPC
[0113]
When transmitting the processing result of its
[0114]
The RPC
[0115]
According to the present embodiment, when making an RPC request to a server group, transmission / reception is performed only with a processing device arbitrarily selected in the group, and is transmitted to all remaining servers of other processing devices in the group. On the other hand, since the indirect multicast method of transferring and processing the RPC request message is used, it is possible to reduce the processing load on the client and the network.
[0116]
[Fourth embodiment]
Next, a fourth embodiment will be described. In the first, second, and third embodiments, RPC is used as a communication method between the client and the server. In a distributed processing system in which a plurality of information processing devices are interconnected via a network, the RPC is a method in which a client in one processing device uses another method by the same method as a procedure call in its own processing device. This is a request-response communication method in which a procedure provided by a server existing in the server is called and a processing procedure for receiving the execution result is performed. However, the RPC internally combines (1) communication of a request message from the client to the server, (2) communication of a response message from the server to the client, and (3) executable on the server side. The program is provided in the form of a procedure. (4) Processing is performed so that a client can call a procedure provided by a server provided in another processing apparatus in the same manner as a procedure called in a processing apparatus of its own. This is one form of request / response communication characterized in that
[0117]
The gist of the present invention is that the communication method between the client and the server is not limited to the RPC, but the communication method between the client and the server is at least (1) a client to a server instead of the remote procedure call request / response. And (2) communication of a response message from the server to the client.
[0118]
In any of the first, second, and third embodiments, a request message may be used instead of the remote procedure call request, and a response message may be used instead of the remote procedure call response. In this case, the system configuration and the configuration in the processing device in each of the first, second, and third embodiments are the same in the fourth embodiment, and the processing contents may be the same. As for the format of the RPC message, it is only necessary to change the RPC control header section to a request / response communication control header section including control information for request / response communication.
[0119]
As described above, the gist of the present invention is not limited to the communication method between the client and the server, and is applicable as long as the communication method between the client and the server is the request response communication. The effect of can be obtained.
[0120]
【The invention's effect】
According to the present invention, a client computer can detect a change in the configuration of a server group during operation. Therefore, the system administrator can add servers to the server group while operating the application system, add new services, increase the multiplicity, upgrade the servers, and expand the system. Performance, maintainability, and fault tolerance can be improved. In addition, while operating the application system, the server can be deleted from the server group and unnecessary servers can be separated, so that the system can be reduced in size and maintainability can be improved.
[0121]
In addition, since the detection information of the change in the group configuration is transmitted and received in addition to the RPC response or the request response, the load does not concentrate on the network due to the change. Further, it is not necessary for the client-side computer to constantly monitor whether there is a change in the group configuration, and the change can be detected from its own RPC request or the response to the request communication. There is no increase.
[0122]
Further, according to the present invention, when the remote procedure configures a multiplex server, the client computers accessing each server before and after server addition can be made the same, and the consistency of the internal state of the server can be improved. Since it is guaranteed, it is useful as a communication system of the multiplex server.
[Brief description of the drawings]
FIG. 1 is a block diagram showing an example of a system configuration to which a remote procedure call processing method according to the present invention is applied.
FIG. 2 is a format diagram of a server change notification RPC message according to one embodiment;
FIG. 3 is a format diagram of an RPC request message according to one embodiment;
FIG. 4 is a format diagram of an RPC response message according to one embodiment.
FIG. 5 is a configuration diagram of a processing device provided with a client and a server.
FIG. 6 is a format diagram showing the contents of an address management table.
FIG. 7 is a format diagram showing the contents of a group management table.
FIG. 8 is a flowchart illustrating an overall processing operation of the RPC client processing unit according to the first embodiment.
FIG. 9 is a flowchart illustrating details of a table initialization process.
FIG. 10 is a flowchart showing a response receiving process of the RPC client processing unit.
FIG. 11 is a flowchart illustrating a processing operation of an RPC server processing unit according to the first embodiment.
FIG. 12 is a flowchart showing a processing operation of an address management unit.
FIG. 13 is a flowchart illustrating a processing operation of a group configuration change notification unit.
FIG. 14 is a system configuration diagram illustrating the flow of a server addition process.
FIG. 15 is an explanatory diagram showing specific management contents of each group management table in the system configuration of FIG. 14;
FIG. 16 is a flowchart illustrating the flow of a server addition process on the server side.
FIG. 17 is a flowchart showing a server addition detection process on the client side.
FIG. 18 is a format diagram illustrating an RPC request message according to the second embodiment.
FIG. 19 is a format diagram showing an RPC response message in the second embodiment.
FIG. 20 is a flowchart illustrating a processing operation of a response receiving process of the RPC client processing unit according to the second embodiment.
FIG. 21 is a flowchart illustrating a processing operation of an RPC server processing unit according to the second embodiment.
FIG. 22 is a system configuration diagram illustrating a flow of a process of an indirect multicast method in the third embodiment.
FIG. 23 is a format diagram showing an RPC request message and a response message in the third embodiment.
[Explanation of symbols]
DESCRIPTION OF
Claims (3)
前記サーバグループの任意の1つにグループ構成の変更が通知され、その通知を受け取ったサーバが自らが保持している変更通番の値をインクリメントして自らの変更情報を変更し、一方リモートプロシジャコール要求元は、グループ化された各サーバへ送信するプロシジャの実行要求に、呼び出すサーバ毎に記憶している現在の変更情報を付加して送信し、
前記サーバの各々は前記実行要求の1つを受信すると、それに対応するプロシジャの実行を行なうと共に、実行要求に付加されている変更情報と自らの保持する変更情報を比較して不一致のときに、前記要求元に返送する応答メッセージに前記実行結果と共に変更フラグをセットし、
前記応答メッセージを受信した要求元は、前記変更フラグがセットされているとき、自分が呼び出すサーバグループのメンバを変更することを特徴とするリモートプロシジャコール処理方法。In a remote procedure call processing method for responding to one remote procedure call request and calling a plurality of grouped servers,
Any one of the server groups is notified of the change in the group configuration, and the server that has received the notification increments the change serial number held by itself and changes its own change information. The request source adds the current change information stored for each server to be called to the execution request of the procedure to be sent to each grouped server, and sends the request.
When each of the servers receives one of the execution requests, the server executes the corresponding procedure, and compares the change information added to the execution request with the change information held by itself, and when there is no match, Setting a change flag together with the execution result in a response message returned to the request source,
The remote procedure call processing method, wherein the request source that has received the response message changes a member of a server group to be called when the change flag is set.
前記サーバグループの任意の1つにグループ構成の変更が通知され、その通知を受け取り追加または削除する変更サーバの変更情報を保持しているサーバは、前記要求元から前記代表サーバへプロシジャの実行要求が出され、前記代表サーバから複製の要求内容を転送されたとき、そのプロシジャ実行による実行結果に前記変更情報を付加した応答メッセージを前記代表サーバに返送し、前記代表サーバは、自分が呼び出すサーバグループのメンバを前記変更情報に基づいて変更することを特徴とするリモートプロシジャコール処理方法。In response to a request for one remote procedure call, when calling a plurality of grouped servers, one of the members of the server group is called on behalf of one server arbitrarily selected by a remote procedure call requester. In the remote procedure call processing method, the called representative server executes its own process and copies the contents requested by the request source and calls the remaining member servers.
Any one of the server groups is notified of the change in the group configuration, and the server holding the change information of the change server that receives the notification and adds or deletes the change request from the request source to the representative server. Is issued, and when the content of the copy request is transferred from the representative server, a response message in which the change information is added to the execution result of the execution of the procedure is returned to the representative server. A remote procedure call processing method, wherein a group member is changed based on the change information.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP35048896A JP3592016B2 (en) | 1996-12-27 | 1996-12-27 | Remote procedure call processing method |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP35048896A JP3592016B2 (en) | 1996-12-27 | 1996-12-27 | Remote procedure call processing method |
Publications (2)
Publication Number | Publication Date |
---|---|
JPH10187467A JPH10187467A (en) | 1998-07-21 |
JP3592016B2 true JP3592016B2 (en) | 2004-11-24 |
Family
ID=18410834
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP35048896A Expired - Fee Related JP3592016B2 (en) | 1996-12-27 | 1996-12-27 | Remote procedure call processing method |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP3592016B2 (en) |
Families Citing this family (21)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7047532B1 (en) | 1998-11-13 | 2006-05-16 | The Chase Manhattan Bank | Application independent messaging system |
US7058817B1 (en) | 1999-07-02 | 2006-06-06 | The Chase Manhattan Bank | System and method for single sign on process for websites with multiple applications and services |
AU3438401A (en) | 1999-11-04 | 2001-05-14 | Jp Morgan Chase Bank | System and method for automated financial project management |
US10275780B1 (en) | 1999-11-24 | 2019-04-30 | Jpmorgan Chase Bank, N.A. | Method and apparatus for sending a rebate via electronic mail over the internet |
US10185936B2 (en) | 2000-06-22 | 2019-01-22 | Jpmorgan Chase Bank, N.A. | Method and system for processing internet payments |
US6880156B1 (en) * | 2000-07-27 | 2005-04-12 | Hewlett-Packard Development Company. L.P. | Demand responsive method and apparatus to automatically activate spare servers |
US7320141B2 (en) * | 2001-03-21 | 2008-01-15 | International Business Machines Corporation | Method and system for server support for pluggable authorization systems |
US8849716B1 (en) | 2001-04-20 | 2014-09-30 | Jpmorgan Chase Bank, N.A. | System and method for preventing identity theft or misuse by restricting access |
US7103576B2 (en) | 2001-09-21 | 2006-09-05 | First Usa Bank, Na | System for providing cardless payment |
AU2002363138A1 (en) | 2001-11-01 | 2003-05-12 | First Usa Bank, N.A. | System and method for establishing or modifying an account with user selectable terms |
US7987501B2 (en) | 2001-12-04 | 2011-07-26 | Jpmorgan Chase Bank, N.A. | System and method for single session sign-on |
US20180165441A1 (en) | 2002-03-25 | 2018-06-14 | Glenn Cobourn Everhart | Systems and methods for multifactor authentication |
US7058660B2 (en) | 2002-10-02 | 2006-06-06 | Bank One Corporation | System and method for network-based project management |
US8190893B2 (en) | 2003-10-27 | 2012-05-29 | Jp Morgan Chase Bank | Portable security transaction protocol |
US8583926B1 (en) | 2005-09-19 | 2013-11-12 | Jpmorgan Chase Bank, N.A. | System and method for anti-phishing authentication |
US8793490B1 (en) | 2006-07-14 | 2014-07-29 | Jpmorgan Chase Bank, N.A. | Systems and methods for multifactor authentication |
US8473735B1 (en) | 2007-05-17 | 2013-06-25 | Jpmorgan Chase | Systems and methods for managing digital certificates |
US9608826B2 (en) | 2009-06-29 | 2017-03-28 | Jpmorgan Chase Bank, N.A. | System and method for partner key management |
US9419957B1 (en) | 2013-03-15 | 2016-08-16 | Jpmorgan Chase Bank, N.A. | Confidence-based authentication |
US10148726B1 (en) | 2014-01-24 | 2018-12-04 | Jpmorgan Chase Bank, N.A. | Initiating operating system commands based on browser cookies |
JP6289214B2 (en) * | 2014-03-31 | 2018-03-07 | 三菱プレシジョン株式会社 | Information processing system and method |
-
1996
- 1996-12-27 JP JP35048896A patent/JP3592016B2/en not_active Expired - Fee Related
Also Published As
Publication number | Publication date |
---|---|
JPH10187467A (en) | 1998-07-21 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP3592016B2 (en) | Remote procedure call processing method | |
US6418452B1 (en) | Network repository service directory for efficient web crawling | |
KR101150146B1 (en) | System and method for managing cached objects using notification bonds | |
US7035931B1 (en) | Volume location service for a distributed file system | |
CN100588172C (en) | System and method for realizing network reserved storage | |
US8140645B2 (en) | Index server support to file sharing applications | |
JP7270755B2 (en) | Metadata routing in distributed systems | |
JP4151322B2 (en) | Network management program and network management method | |
JPH09244940A (en) | Method for managing distributed computer resource | |
WO1989002631A1 (en) | Naming service for networked digital data processing system | |
CN111385325B (en) | File distribution system and method based on P2P | |
CN102375955A (en) | System and method for locking files in combined naming space in network file system | |
US8250176B2 (en) | File sharing method and file sharing system | |
US20240223655A1 (en) | Data processing system, data processing method, and related apparatus | |
JP6586174B2 (en) | Database system, transaction management node, method and program | |
JP4131781B2 (en) | Distributed processing database management system | |
CN112328560A (en) | File scheduling method and system | |
JP4129353B2 (en) | Distributed data management system, distributed data management method, and distributed data management program | |
JP2004302564A (en) | Name service providing method, execution device of the same, and processing program of the same | |
JP2000047890A (en) | Distributed object managing system, its object selecting method and storage medium recording its processing program | |
CN106407320B (en) | File processing method, device and system | |
JPH11331812A (en) | Acting server for moving image data distribution and moving image data distribution method | |
JPH0962602A (en) | Server information managing method and management system | |
CN114827283B (en) | Resource access method, device, medium and robot | |
CN116991333B (en) | Distributed data storage method, device, electronic equipment and storage medium |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20040525 |
|
A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20040721 |
|
TRDD | Decision of grant or rejection written | ||
A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20040817 |
|
A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20040824 |
|
R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20080903 Year of fee payment: 4 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20080903 Year of fee payment: 4 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090903 Year of fee payment: 5 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090903 Year of fee payment: 5 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100903 Year of fee payment: 6 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100903 Year of fee payment: 6 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110903 Year of fee payment: 7 |
|
LAPS | Cancellation because of no payment of annual fees |