JP3592016B2 - Remote procedure call processing method - Google Patents

Remote procedure call processing method Download PDF

Info

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
Application number
JP35048896A
Other languages
Japanese (ja)
Other versions
JPH10187467A (en
Inventor
富美子 小平
宣善 安東
茂樹 平澤
洋 綿谷
健二 松崎
清一 田村
淳 鈴木
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Hitachi Ltd
Original Assignee
Hitachi Ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Hitachi Ltd filed Critical Hitachi Ltd
Priority to JP35048896A priority Critical patent/JP3592016B2/en
Publication of JPH10187467A publication Critical patent/JPH10187467A/en
Application granted granted Critical
Publication of JP3592016B2 publication Critical patent/JP3592016B2/en
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

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 processing devices 2 to 8 are connected to the communication medium 1 and communicate with other processing devices. As the communication medium 1, a communication line such as a LAN (Local Area Network), a WAN (Wide Area Network), or a wireless (wireless) is used. Although the bus type is shown as an example, various networks such as a duplex bus type, a single loop type, a double loop type, and a ring type can be used. First, a configuration of a distributed system using RPC will be described, and then a process of changing a group configuration will be described using an example of adding a processing device to a group.
[0022]
The processing device 2 includes a client and an RPC processing unit, and requests another processing device to execute processing using RPC. Each of the processing devices 3 to 6 includes a server and an RPC processing unit 20, executes a process requested by another processing device, and returns a result to a request source. The processing devices 3 to 5 are grouped to form a multiplexing server 80.
[0023]
The client 15 of the processing device 2 is a user program or an application program created or used by a user, and requests a reference to information necessary for processing to a server procedure provided to another processing device. Is what you do. When the client 15 requests execution of the procedure of the server, the client 15 issues an RPC request to the RPC processing unit 10.
[0024]
The RPC processing unit 10 performs the RPC request processing of the client 15 on behalf of the client 15. The RPC processing unit 10 receives the RPC request issued from the client 15, transmits a procedure execution request of the server as an RPC request message to another processing device, and outputs a procedure execution result corresponding to the RPC request message transmitted by itself. It has a function of receiving the attached RPC response message and returning it to the requesting client 15.
[0025]
The processing device 3 includes an RPC processing unit 20 and a server 25, executes a process requested by another processing device, and returns a result to a request source. The RPC processing unit 20 receives the RPC request message transmitted from another processing device, executes the procedure of the server requested to execute, and sends an RPC response message attached with the execution result to the requesting processing device. Send.
[0026]
The server 25 is a program that executes itself in response to a request from the RPC processing unit 20 and returns the execution result to the RPC processing unit 20, and is provided in the form of a procedure. The server 25 is a program created or used by a user, and is a program that provides information necessary for processing by a client.
[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 server 25 includes a server 401 having a process identifier of “QSORT”, a server 402 of “ASORT”, and a server 403 of “BSORT”.
[0028]
The processing devices 4 to 6 have the same configuration as the processing device 3 and include servers 35, 45, and 55 and RPC processing units 30, 40, and 50, respectively. The RPC processing units 30, 40, and 50 have functions similar to those of the RPC processing unit 20. The server 35 includes servers 411 to 413 as in the server 25. The server 45 is composed of servers 421 and 422 and a server 423 whose identifier is “CSORT”. Further, the server 55 of the processing device 6 outside the group includes the same servers 431, 432, and 433 as the server 45.
[0029]
The processing device 7 includes an address management unit 60, and manages addresses of the processing devices 3 to 6 including servers existing in the system. The address management unit 60 adds, deletes, or refers to address information in response to a request from another processing device, and returns a processing result to the request source.
[0030]
The processing device 8 includes a group configuration change notification unit 70, which receives a request to change the configuration of a server group, that is, a request to add or delete a server to the server group 80, based on a command input or the like from a user, and The server of the group 80 is notified.
[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 server 55 to a server group 80 including servers 25, 35, and 45. Although there are various methods for grouping servers, in this embodiment, servers having the same processing identifier are treated as one group. In this case, it is not necessary that all servers in the same group perform exactly the same processing, and the processing contents may be different as in the example of FIG.
[0032]
Next, an outline of the RPC process for the grouped servers will be described. The client 15 transmits a procedure execution request to the server group 80 via the RPC processing unit 10. However, the RPC processing unit 10 determines a server group that can process the RPC request and a server belonging to the RPC request from the contents of the RPC request issued by the client 15, and transmits an RPC request message to all the processing apparatuses including the server. . This determination is made based on the processing identifier passed from the client 15 when the client 15 issues an RPC request to the RPC processing unit 10.
[0033]
Among the processing devices in the server group 80, the RPC processing unit of each processing device that has received the RPC request message executes a server capable of executing the requested processing, and uses the execution result as an RPC response message as the processing of the request source. Transmit to the device 2. The request source RPC processing unit 10 receives the RPC response message from each processing device that has transmitted the RPC request message, selects one RPC response message from the received RPC response messages based on a predetermined logic, and includes the RPC response message in the RPC response message. The execution result of the server is returned to the client 15. As the logic used for this selection, logics such as "select one randomly", "select one based on majority logic based on the response content", and "select the earliest one" are used. be able to.
[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 notification RPC message 100 is transmitted from the group configuration change notification unit 70 and includes an RPC control header unit 101 and a changed server processing identifier unit 103. The RPC control header 101 stores information necessary for controlling processing associated with transmission and reception of an RPC request message and an RPC response message. The RPC request content identifier unit 102, which is a part of the area, stores a process identifier by which the RPC processing unit on the receiving side can identify the process content requested by RPC. It also has an area for storing a destination address, a source address, a transmission serial number, request / response identification information, and the like. The change server processing identifier section 103 stores, for example, a processing identifier representing the processing content of the server 55 added to the server group 80.
[0035]
FIG. 3 shows a format of the RPC request message. The RPC request message 110 is transmitted by the RPC processing unit 10 in response to an RPC request from the client 15 and includes an RPC control header unit 101 and a client request data unit 111. The client request data section 111 stores input / output arguments of a server procedure for executing the server.
[0036]
FIG. 4 shows a format of the RPC response message. The RPC response message 120 is used by the RPC processing units 20 to 50 to transmit the execution result of the server of the own processing apparatus to the client. The RPC response message 120 includes the RPC control header unit 101, the server execution result data unit 122, and the group configuration change serial number unit 121. Be composed. The server execution result data section 122 stores the server execution result. The group configuration change serial number unit 121 is unique to the present embodiment, and stores a group configuration change serial number that is incremented each time a server group configuration is changed, such as when a server is added.
[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 notification RPC message 100 for adding or deleting a server is received, the change serial number is incremented as described later.
[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 RPC response message 120 is received, the change serial number stored in the message is compared with the stored change serial number, and a change in the server group is detected based on a mismatch between the change serial numbers.
[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 processing devices 1 to 6, the address management unit 60 included in the processing device 7, and the group configuration change notification unit 70 included in the processing device 8 will be described in this order.
[0040]
FIG. 5 shows a detailed configuration of the processing apparatus. The illustrated processing apparatus 2 is an example, and other processing apparatuses 3 to 8 may have the same configuration. The processing device 2 includes both the client 15 and the server 16 together with the RPC processing unit 10. The RPC processing unit 10 includes an RPC client processing unit 11, an RPC server processing unit 12, an address management table 13, and a group management table 14. The address management table 13 stores information on servers in which each processing device belongs to a server group. The address management table 13 stores a processing identifier indicating the processing content of the server and the address of a processing device having the server.
[0041]
If the processing device is dedicated to client processing, the server 16 and the RPC server processing unit 12 are not required. When the processing device is dedicated to server processing, the client 15 and the RPC client processing unit 11 are unnecessary, and in the case of the present embodiment, the address management table 13 is also unnecessary.
[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 RPC processing unit 10 requests the address management unit 60 to acquire the information stored in the processing identifier unit 131 and the address unit 132. The figure shows a part of the configuration in FIG. 1 and stores address information of at least three processing devices. That is, there are three processing devices having a server identified by “QSORT”, and each address is “133.144.8.159:8080”, “133.144.8.160:8052”, and “133.144”. .8.161: 8031 ". Further, there is a processing apparatus having a server identified by “ASORT”, and its address “133.144.9.120:6198” is stored. As the address, a set of an IP address and a reception port number is used as shown.
[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 process identifier section 141, an address section 142, and a group configuration change serial number section 143, and these three pieces of information are used as a set. As in the address management table 13, the processing identifier 141 and the address 142 store a processing identifier indicating the processing content of the server and the address of the processing device.
[0045]
The group configuration change serial number unit 143 stores a change serial number for managing a change in the configuration of the server group. FIG. 7A shows a part of the group configuration shown in FIG. 1, in which there are three processing devices having a server identified by “QSORT”, and each group configuration change serial number is “2”, "3" and "5". Also, there is at least one processing device having a server identified by “AQORT”, and its group configuration change serial number is “2”. Here, the change serial number values “2” and “3” for the same QSORT reflect the number of changes in the processing device corresponding to the address.
[0046]
FIG. 8 is a flowchart illustrating the processing of the RPC client processing unit. The RPC client processing unit 11 performs processing on behalf of the RPC request from the client 15.
[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 client 15 to the RPC client processing unit 11.
[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 client processing unit 11 transmits, to the address management unit 60, an RPC request message requesting a reference to all addresses corresponding to the processing identifier stored in the address management unit 60, and the address information attached to the response message Is acquired (S1031). This address information is registered in the address management table 13 (S1032), and an address is similarly registered in the group management table 14, and "0" is set to the corresponding group configuration change serial number (S1033).
[0050]
Next, the RPC client processing unit 11 searches the address management table 13, acquires the addresses of all the processing devices including the server that can execute the RPC request (S104), and counts the number of the processing devices (S105). ). This search is performed using the process identifier passed from the client 15 as a key, and the addresses of all the processing devices having the same process identifier as the process identifier passed from the client are acquired from the address table 15. Then, the request message is transmitted to one server of the server group (S106). That is, an argument necessary for server execution is written in the client request data section 111 of the PRC request message 110, and the RPC request message 110 is transmitted to the processing device given by the address acquired in S104.
[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 RPC request message 110 to all the obtained processing devices. Therefore, after transmitting the RPC request message 110, the number of processing devices that have transmitted the message is counted (S107), and the count value is compared with the number of servers in the acquired server group (S110). As a result of the comparison, when the count value is smaller, an address that has not yet transmitted the RPC request message 110 is selected from the addresses acquired in the processing of S104 (S111), and the RPC request message 110 is transmitted. Thus, by repeating the transmission processing from S106 to S111, the RPC request message 110 is transmitted to all servers belonging to the server group and corresponding to the processing identifier of the RPC request.
[0052]
The above is the process of transmitting an RPC request from a client. When the RPC request message 110 is transmitted, a response message is returned from the server of the RPC request destination. The RPC client processing section 11 checks the reception of a response message from its own RPC request destination server (S108), and performs a response reception process as follows (S109).
[0053]
FIG. 10 shows a flowchart of the response receiving process (S109). Upon receiving the response message 120 (S201), the RPC client processing unit 11 acquires the address of the message transmission source, the RPC request content identifier, and the group configuration change serial number from the response message 120 (FIG. 4) (S202). Then, it searches its own group management table 14 to detect address information that matches both the address attached to the response message and the RPC request content identifier, and determines the change serial number of the address information and the change serial number by the response message 120. A comparison is made (S203).
[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 response message 120 is large, that is, if the value has been incremented, it is determined that the server group has changed (S204), and the group configuration change serial number according to the response message 120 is stored in the group management table 14. The address information is stored in the group configuration change serial number unit 143 (S205).
[0055]
Next, the RPC client processing unit 11 transmits an RPC request message referring to the addresses of all servers to the address management unit 60 of the processing device 7 via the network 1, and acquires the address information attached to the response message. (S206). Next, the acquired address information is compared with the contents of its own address management table 13, and the difference remaining in the former is acquired as the address of the additional server (S207).
[0056]
Here, the address information acquired from the address management unit 60 is a set of a set of a process identifier and an address corresponding to the process identifier. The same applies to the address management table 13. The comparison is performed for each set, which is a component of both sets, and the difference is obtained. The reason why the address management table 13 is provided in addition to the group management table 14 is to simplify the difference processing. In the case of a change for deleting a server, the difference information remaining on the address management table 13 of the own server becomes the address of the deleted server.
[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 client processing unit 11 repeats the response receiving process until all the response messages are received (S112), selects one of the server execution result data 122 attached to the plurality of response messages, and Hand over (S113). This selection is made based on a predetermined logic such as "randomly selected", "first-come, first-served".
[0059]
Next, the RPC server processing unit 12 will be described. The RPC server processing unit 12 performs an RPC request reception and response return processing of the server 16, and receives an RPC message notifying the server group configuration change from the group configuration change notification unit 70 of the processing device 7, Holds configuration change information.
[0060]
FIG. 11 is a flowchart illustrating the processing of the RPC server processing unit. Upon receiving the RPC request message 110 transmitted from another processing device (S301), the RPC server processing unit 12 determines the request content of the received message (S302). This determination can be made by referring to the processing identifier section 103 of the server change notification RPC message 100.
[0061]
If the received message is a message for notifying the server group configuration change, the value of the group configuration change serial number 143 in the group management table 14 of the own processing device is incremented (S303). As a result, the RPC processing unit 10 holds information on the configuration change of the server group. Then, a response notifying the completion of the process of holding the information of the group configuration change is returned to the group configuration change notification unit 70 that is the RPC request source (S304).
[0062]
On the other hand, if it is determined in step S302 that the received request message is the RPC request message 110, the RPC server processing unit 12 executes the server (S305). That is, it acquires the arguments and the like necessary for execution of the server from the client request data section 111 of the received RPC request message 110, passes them to the server 16, and executes the procedure of the server 16. When there are a plurality of servers having the same processing identifier in the processing device, one is randomly selected and executed.
[0063]
After the server 16 executes the procedure, the RPC server processing unit 12 receives the execution result from the server 16 and stores it in the server execution result data unit 122 of the RPC response message 120. The value of the group configuration change communication unit 143 of the group management table 14 is stored in the area of the group configuration change serial number unit 121 (S306). This RPC response message 120 is transmitted to the client that is the RPC request source (S307). Therefore, if the change serial number of the group management table 14 has been incremented by the time of this RPC request, the change serial number can be stored and transmitted in the RPC response message to notify the client of the change of the server group.
[0064]
The details of the RPC processing units included in the processing devices 2 to 6 have been described above with reference to the configuration of the processing device in FIG. 5 including both the client and the server. As described above, the RPC process in the system configuration of FIG. 1 can be understood by reading the processing device 2 on the client side and the processing devices 3 to 5 on the group server side.
[0065]
Next, the address management unit 60 included in the processing device 7 will be described in detail. The illustration of the RPC processing unit of the processing device 7 is omitted. The address management unit 60 manages the addresses of the servers in the system shown in FIG. 1 collectively, and stores the processing identifiers of all the servers included in the processing devices within a predetermined range (for example, within one network segment). The information corresponding to the address of the processing device is held in its own management table. The address management unit 60 performs addition, deletion, or reference processing of the information in response to an RPC request message from another processing device, and returns the information to the request source in a response message.
[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 address management unit 60, in which the address of the processing device having the additional server and the processing identifier of the additional server are added. When determining that the request content is the addition of the server address, the address management unit 60 adds the address and the processing identifier attached to the RPC request message to the management table provided in the processing device 7 (S403), and determines whether the addition processing is successful or not. The response message is transmitted to the request source (S404).
[0068]
The address management unit 60 manages servers having the same process identifier as one server group. Therefore, in order to manage the address and the server group to which the server belongs, the address and the processing identifier are added in association with each other.
[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 address management unit 60 determines that the request is a deletion request (S402), the address management unit 60 deletes the same address information as the combination of the process identifier and the address attached to the RPC request message from its own table (S405), and executes the deletion process. Is transmitted to the requestor as a response message (S406).
[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 unit 60. When it is determined that the request content refers to the address (S402), the management table provided in the address management unit 60 is searched, and an address associated with the same processing identifier as the processing identifier added to the RPC request message is extracted ( S407), and transmits the message to the request source with the RPC response message attached (S408).
[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 change notification unit 70 included in the processing device 8 will be described. The illustration of the RPC processing section of the processing device 8 is omitted. The group configuration change notification unit 70 receives a request to change the configuration of a specified server group by a command input or the like from a user. For example, a command to change the configuration of the server group 80 is issued by a command, and information such as the address of a processing device having a server to be added or deleted and the processing identifier of the server is transmitted as an argument of the command. Provided to the unit 70.
[0073]
Upon receiving this command, the group configuration change notification unit 70 transmits an RPC request message requesting an address change to the address management unit 60 of the processing device 7. For example, an RPC request message requesting the addition of the address of the processing device having the new server is transmitted, the address is registered in the address management unit 60, and the RPC message notifying the server group configuration change is transmitted to the specified server group 80. Send to The processing devices 3 to 5 belonging to the server group 80 receive the RPC message for notifying the server group configuration change, and hold the change information of the server group configuration in the address management table 13 and the group management table 14 of the processing devices.
[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 change notification unit 70 transmits to the address management unit 60 an RPC request message requesting address reference of a server belonging to the server group to be added. The address is obtained (S502). At this time, the address of any one server belonging to the group may be obtained, or the addresses of all servers may be obtained. In the latter case, the group configuration change notification unit 70 selects an arbitrary one.
[0075]
Next, the group configuration change notification unit 70 transmits an RPC request message requesting registration of the address of the additional server to the address management unit 60, and requests registration of the address in the management table (S503). Next, an RPC message 100 notifying the addition of the server is transmitted to the server having the address acquired in step S502 (S504), and a response indicating that the processing for storing the additional information is completed is received from the server (S505).
[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 server 55 to the server group 80 from the user, the group configuration change notification unit 70 registers the address of the processing device 6 including the new server 55 in the address management unit 60. Further, the group configuration change notification unit 70 obtains the address of any one server in the server group 80, here, the address of the server 45 from the address management unit 60, and sends the address to the RPC server processing unit 42, which is the address. The server addition notification RPC message 100 is transmitted as indicated by an arrow 201a (S601).
[0079]
Upon receiving the server addition notification RPC message, the RPC server processing unit 42 increments the group configuration change serial number of the group management table 44 in the RPC server processing unit 42 from 5 to 6, and processes the group configuration change notification unit 70. A completion response message is transmitted (S602).
[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 client 15 sends an RPC request message 110 including the processing identifier “QSORT” to the RPC client processing unit 11, for example. The RPC client processing unit 11 searches the address management table 13 to obtain the addresses of the processing devices 3, 4, and 5 including the servers capable of executing “QSORT” belonging to the server group 80, and the arrows 205a, b, and c Is transmitted (S701). At this time, the change serial number corresponding to each address having “QSORT” in the group management table 14 is stored as shown in FIG.
[0082]
Upon receiving the RPC request message, the RPC server processing units 22, 32, and 42 of the processing devices 3, 4, and 5 execute the server as indicated by arrows 206a, b, and c in response to the RPC request (S702), and execute the server. The result is obtained as arrows 207a, b, and c. Also, the change serial numbers in the group management tables 24, 34, and 44 are acquired as shown by arrows 208a, b, and c, and the RPC response message storing the execution result and the change serial numbers is transmitted as shown by arrows 209a, b, and c. (S703). At this time, the change serial numbers of “QSORT” in the group management tables 24, 34, and 44 are as shown in FIG.
[0083]
The RPC client processing unit 11 receives the RPC response message from the processing devices 3, 4, and 5 (S704), compares the change serial number in the RPC response message with the change serial number in the group management table 14, and configures the group server. It is determined whether or not has been changed (S705). This process corresponds to step S204 of the response receiving process in FIG.
[0084]
Here, the RPC server processing unit 42 included in the processing device 5 receives the server addition notification RPC message as described above, and increments the group configuration change serial number of “QSORT” in the group management table 44 from 5 to 6. , Added to the response message and transmitted as indicated by an arrow 209c. Therefore, when the RPC client processing unit 11 compares the change serial number of the RPC response message with the change serial number of the same address in its own group management table 13, the addition of a new server can be detected.
[0085]
Upon detecting the addition of the new server, the RPC client processing unit 11 acquires the address information of all servers from the address management unit 60, compares it with the address information of its own address management table 13, and obtains the address of the server 55 obtained as a difference. The information is added to the address management table 13 and the group management table 14 (S706). Next, the RPC client processing unit 11 selects one of the RPC response messages received from each of the processing devices 3, 4, and 5 and passes it to the client 15 as a server execution result (S707).
[0086]
In the above description, the group configuration change notification unit 70 is provided by the processing device 8, but any processing device may be provided. For example, the processing device 6 may include the group configuration change notification unit 70. At this time, the server 55 may notify the group configuration change notification unit 70 of its own addition request and request the group configuration change notification unit 70 to perform an addition processing request.
[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 server group 80 of FIG. 1, there is a server that cannot be multiplexed in the group 80, and its processing identifier is “CSORT”. In this case, if the server 55 is added, the server of “CSORT” is multiplexed. Accordingly, upon receiving the processing identifier of the additional server in the RPC notification message 100, the RPC server processing unit 42 checks the processing identifier of the group management table 14, and suspends the additional processing when the "CSORT" server is multiplexed. I do. Alternatively, when the server group adopts a completely multiplexed configuration, it is determined whether the processing identifier of the server to be added is the same as the processing identifier in the group management table 14 and if not, a response indicating that addition is impossible is returned. .
[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 serial number unit 112 for storing the change serial number held by the client is added to the RPC request message (FIG. 3) in the first embodiment.
[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 change flag unit 123 for notifying the presence or absence of a configuration change in a server group.
[0098]
The processing performed by the RPC client processing unit 11 will be described. First, in step S106 of the processing flow (FIG. 8) according to the first embodiment, when the RPC client processing unit 11 issues an RPC request message to the server, the change serial number corresponding to the address of the request destination server is set in the group management table. 14 and stored in the group configuration change serial number section 112 of the RPC request message as shown in FIG.
[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 RPC response message 120 from the server (S801), the RPC client processing unit 11 checks the change flag unit 123 and determines whether or not there is an addition to the server group (S802). If the addition flag is set (ON), it is determined that the server group 80 has been changed, and the processing of S803 to S807 is performed. Here, the processing of steps S803 to S807 is the same as the processing of steps S205 to S209 shown in FIG. 10 of the first embodiment.
[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 server processing unit 42 of the processing device 5. In the figure, steps S901 to S904 are the same processing as S201 to S204 in the first embodiment (FIG. 11).
[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 RPC request message 120 is obtained (S906), and compared with the change serial number managed in the group management table 44 of the self-processing device 5 (S907). As a result of the comparison, if the own change serial number is larger, the server addition flag of the RPC response message is turned ON as shown in FIG. 19B (S910), and the own change serial number is added to the RPC response message 120 ( (S911), and sends it back to the processing device 2 on the client side together with the execution result of the server (S912).
[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 client processing unit 11 determines ON / OFF of the additional flag of the response message 120, and updates the group management table 14 and the address management table 13 in steps S803 to S807.
[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 message flag unit 113 is added to the RPC request message of FIG. In the response message shown in FIG. 9B, the change flag section 123 is provided, and the group configuration change serial number section 121 is deleted.
[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 client processing unit 11 transmits an RPC request message to an arbitrary one set in advance as a master server in the group, here, the server 25 of the processing device 3. Note that the group management table 24 of the master processing device 3 manages its addresses and change serial numbers so that all servers in the group 80 can be called.
[0110]
Upon receiving the RPC request message from the client, the RPC server processing unit 22 of the processing device 3 determines that the message is not a transfer message because the transfer message flag is OFF, and transfers the message to all other servers in the group. An RPC request message is transmitted, and the transmitted transfer RPC request message is received by the processing units 4 and 5, respectively.
[0111]
The RPC server processing units 32 and 42 in the processing devices 4 and 5 that have received the RPC request message execute the server in response to the RPC request, acquire the execution result of the server, and also execute the group management tables 24, 34 and 44. , And transmits an RPC response message storing the changed serial numbers to the RPC server processing unit 22 that has transmitted the transfer RPC request message.
[0112]
The RPC server processing unit 22 updates the group management table 24 when the RPC server processing unit 22 has a group configuration change notification. Further, the change serial number in the RPC response message from the processing devices 4 and 5 is compared with the change serial number in the group management table 24 to determine whether there is a change in the group configuration. If there is a change, the group management table 24 is updated.
[0113]
When transmitting the processing result of its own server 25 and the execution results from the other transfer destination servers 35 and 45 to the client, the RPC server processing unit 20 updates the group management table 24 first if the group management table 24 is updated. A change flag is set (ON) in the unit 123.
[0114]
The RPC client processing unit 11 that has received the RPC response message from the processing device 3 determines that there is a change in the configuration of the server group 80 if the change flag of the message is ON, and sends the addresses of all servers from the address management unit 60. The address is acquired and compared with the address in the address management table 13. As a result, the address of the server 55 that becomes the difference is added to the address management table 13 and the group management table 14. Next, the RPC client processing unit 11 selects one from the server execution results of the processing devices 3, 4, and 5 in the RPC response message, and passes it to the client 15. In this embodiment, the client does not need a group management table.
[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 SYMBOLS 1 ... Communication medium (network), 2-8 ... Processing apparatus (computer), 10, 20, 30, 43, 50 ... RPC processing part, 11 ... RPC client processing part, 12, 22, 32, 42, 52 ... RPC Server processing unit, 13: address management table, 14, 24, 34, 44, 54: group management table, 143: group configuration change serial number unit, 25, 35, 45, 55, 401, 402, 403, 411, 412 413, 421, 422, 423, 431, 432, 433: server, 60: address management unit, 70: group configuration change notification unit, 80: server group, 100: server change notification RPC message, 101: RPC control header unit 102: RPC request content identifier, 103: change server processing identifier, 110: RPC request message, 111 Client request data unit, 120 ... RPC reply message, 121 ... group configuration change notification unit, 122 ... server execution result data unit.

Claims (3)

1つのリモートプロシジャコールの要求に対応し、グループ化された複数のサーバを呼び出すリモートプロシジャコール処理方法において、
前記サーバグループの任意の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つのリモートプロシジャコールの要求に対応し、グループ化された複数のサーバを呼び出すにあたり、前記サーバグループのメンバの中からリモートプロシジャコール要求元によって任意に選択した1つのサーバを代表して呼び出し、この呼び出された代表サーバは自らの処理を実行するとともに、前記要求元から要求された内容を複製して残りのメンバのサーバを呼び出すリモートプロシジャコール処理方法において、
前記サーバグループの任意の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.
請求項1または2において、前記グループ構成の変更として、前記サーバグループに新規サーバを追加し、前記新規サーバの追加を検知したリモートプロシジャコールの各要求元が、このときまで処理要求先としていたサーバと前記新規サーバのいずれかを新たな処理要求先とするか選択し、プロシジャ実行側が行う処理を前記グループ内のサーバ間で分散させることを特徴とするリモートプロシジャコール処理方法。 3. The server according to claim 1 , wherein, as the change in the group configuration, a new server is added to the server group, and each request source of the remote procedure call that has detected the addition of the new server has been a processing request destination up to this time. And selecting one of the new server and the new server as a new processing request destination, and distributing the processing performed by the procedure executing side among the servers in the group.
JP35048896A 1996-12-27 1996-12-27 Remote procedure call processing method Expired - Fee Related JP3592016B2 (en)

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)

* Cited by examiner, † Cited by third party
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
WO2001033477A2 (en) 1999-11-04 2001-05-10 Jpmorgan 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
US7689504B2 (en) 2001-11-01 2010-03-30 Jpmorgan Chase 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

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
EP3127018B1 (en) Geographically-distributed file system using coordinated namespace replication
KR101150146B1 (en) System and method for managing cached objects using notification bonds
US7035931B1 (en) Volume location service for a distributed file system
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
WO2008131653A1 (en) A system and method for realizing network subscribing store and a subscribe server
US20060123121A1 (en) System and method for service session management
US20090077036A1 (en) Propagating a query in a federated database
CN102375955A (en) System and method for locking files in combined naming space in network file system
US20080010299A1 (en) File management system
CN111385325B (en) File distribution system and method based on P2P
US8250176B2 (en) File sharing method and file sharing system
JP6586174B2 (en) Database system, transaction management node, method and program
CN112328560A (en) File scheduling method and system
JP4131781B2 (en) Distributed processing database management 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

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