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

Abstract

(57)【要約】 【構成】同じサービス要求を処理できるサーバプロセス
を複数有し、もっとも早くサービス処理を開始できるサ
ーバプロセスがサービス要求を受け、サービス処理が行
われていないサービス要求の個数と、サーバプロセスの
個数に応じサーバプロセスを起動・停止する手段１０５
０，１０６０を備え、クライアントプロセス１０１０か
ら同じサービス要求を複数回送った場合、複数のサーバ
プロセス１０２０，１０２１，１０２２のいずれかのサ
ーバプロセスが複数のサービス要求の全てを処理しない
かぎり、サーバプロセスの停止を行わないリモートプロ
シジャコール方法。 【効果】サーバプロセスが負荷分散を行い、負荷分散を
行うサーバプロセスの個数を特定の範囲内で増減するこ
とができる。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は、プログラムの実行単位
であるプロセスを複数並列に処理できる計算機システム
に係り、特に、クライアントプロセスがサーバプロセス
にサービス要求を送り、サーバプロセスが前記サービス
要求に従ったサービス処理を行う、リモートプロシジャ
コール方法に関する。

【０００２】

【従来の技術】クライアント−サーバ型のシステム構成
が注目されるにつれ、リモートプロシジャコール（以下
ＲＰＣ）を用いた比較的大きなシステムが構築されつつ
ある。クライアントプロセス数はシステム規模とともに
増加するため、大規模なシステムでは同じサービスを処
理するサーバプロセスを複数用意し、これら複数のサー
バプロセスでＲＰＣを分散して処理する必要が生じる。

【０００３】複数のサーバプロセスでＲＰＣを分散して
処理する場合、同じサービス要求を処理するサーバプロ
セスを複数用意し、これらのサーバプロセス間で負荷分
散を行う方法が一般的である。このような同じサービス
を処理する複数のサーバプロセスを有するＲＰＣシステ
ムの従来技術としてSunRPCを利用したＮＦＳシステムが
ある。また、ＲＰＣシステムではないが、複数のサーバ
プロセスを有し、クライアント−サーバ型のシステム構
成を取る従来技術としてインターネットサービスのinet
d がある。

【０００４】「マネージング エヌエフエス アンド
エヌアイエス」ハル スターン著(「Managing NFS and
NIS」Hal Stern著ISBN4−7561−0273−5)によると、ＮＦ
Ｓシステムはnfsdサーバプロセスを複数もつ事ができ
る。nfsdはＲＰＣのサーバプロセスであり、ＲＰＣプロ
グラム番号で識別されるサービス要求をクライアントか
ら受け、サービス処理を行う。全てのnfsdは同じサービ
ス要求（ＲＰＣプログラム番号）のサービス処理を行
う。サービス要求をクライアントプロセスから受け取る
ために、全てのnfsdは一つのＵＤＰ通信ポートを共有
し、サービス処理を行っていないサーバプロセスがＵＤ
Ｐポート内のキューからサービス要求を取り出すことに
より、サーバプロセス間の負荷分散を行っている。

【０００５】全てのサーバプロセスが一つのキューより
サービス要求を取り出すため、クライアントプロセスが
特定のサーバプロセスを指定してサービス要求を送るこ
とができない。このため、nfsdは、サービス処理のうち
クライアント、サービス等の状態に関係のない処理のみ
を行い、サーバとしての状態を持つことが出来ない。

【０００６】サービス処理のうち状態に関する処理は、
rpc.statd サーバプロセスが行い、rpc.statd サーバプ
ロセスに対し、それぞれのnfsdサーバプロセスからＲＰ
Ｃを出すことで処理する。rpc.statd を複数プロセス構
成にして負荷分散を行う事はできない。また、nfsdサー
バプロセスの個数は、起動時にパラメータとして与えら
れ、クライアントからのサービス要求の頻度に応じて変
更する事ができない。

【０００７】「ユニックス ネットワーキング プログ
ラミング」ダブリュ リチャードスチブンス著(「UNIX
NETWORKING PROGRAMING」W.RICHARD STEVENS著ISBN0−13
−949876−1）によると、inetdは、通信ポート番号によ
って識別されるサービス要求をクライアントプロセスよ
り受け取り、サービス要求に対応したサービスの処理を
行うサーバプロセスを起動し、サーバプロセスにクライ
アントからのサービス要求を中継するプロセスである。

【０００８】inetd プロセスは、クライアントからサー
ビス要求を受ける度にサーバプロセスを起動する。サー
バプロセスは、サービス要求を送ったクライアントに関
するサービスの処理を終えた後、新たなサービス要求を
受け取らずに終了する。サービス要求とサーバプロセス
が一対一に対応するため、一つのサービス処理の中でサ
ーバプロセスが状態を持つことは可能であるが、複数の
サービス要求にわたってサーバプロセスが状態を保存す
る事はできない。

【０００９】

【発明が解決しようとする課題】このように、ＮＦＳシ
ステムが有する従来技術では、サーバプロセスの個数が
固定であり、クライアントからのサービス要求が頻繁に
送られてくると、前もって用意されたサーバプロセスの
個数ではサービスの処理が間に合わなくなる。逆にサー
ビス要求の送られる頻度が少ない場合には、処理を行わ
ないサーバプロセスが複数あることにより、サーバプロ
セスに付随するメモリ等のリソースが無駄に使用され
る。

【００１０】また、inetd の持つ従来技術では、サーバ
プロセスの個数がクライアントからのサービス要求の頻
度に合わせて変化するが、サーバプロセスの個数がサー
ビス要求の個数と一致するため、サーバプロセスの個数
に上限がなく、サービス要求が頻繁に送られてくるとサ
ーバプロセスの個数が極端に増加し、ＣＰＵ，メモリ等
のリソースを使い果たしてしまう。さらに、inetd の持
つ従来技術では、サーバプロセスが一つのサービス要求
しか処理しないため、サービス要求毎にサーバプロセス
の起動・停止処理が発生し、サービス処理が重くなる。

【００１１】ＮＦＳシステムが有する従来技術、inetd
の持つ従来技術ともに、クライアントプロセスが複数の
サーバプロセスのいずれかを指定してサービス要求を送
ることができない。このため、複数のサーバプロセスに
より負荷分散する場合、サーバプロセスは状態を持つこ
とができない。ＮＦＳシステムが有する従来技術では、
サーバプロセスを一つに限定する時に限り、そのサーバ
プロセスで状態を持てるが、inetd の持つ従来技術で
は、サーバプロセスが複数のサービス要求にわたる状態
を持つ事ができない。

【００１２】本発明の目的は、同じサービス要求を処理
できるサーバプロセスが複数存在し、これらのサーバプ
ロセスが負荷分散を行うＲＰＣにおいて、サーバプロセ
スが状態を持てず、負荷分散を行うサーバプロセスの個
数を特定の範囲内で増減することができていない事を解
決することにある。

【００１３】

【課題を解決するための手段】これらの課題を解決する
ために本発明は、同じサービス要求を処理できるサーバ
プロセスを複数有し、前記複数のサーバプロセスのうち
もっとも早くサービス処理を開始できるサーバプロセス
が前記サービス要求を受け取るＲＰＣ方法において、前
記サービス要求のうち、まだサーバプロセスでサービス
処理が行われていないサービス要求の個数を求める手段
と、前記複数のサーバプロセスの個数を求める手段と、
前記複数のサーバプロセスと同じサービス要求を処理で
きるサーバプロセスを新たに起動する手段と、サービス
処理完了後に前記複数のサーバプロセス内のいくつかの
サーバプロセスを停止する手段と、前記サービス要求の
個数と前記サーバプロセスの個数に応じ前記サーバプロ
セスを起動・停止する手段を備える。

【００１４】さらに、本発明は、クライアントプロセス
から同じサービス要求を複数回送った場合、前記複数の
サーバプロセスの内いずれかのサーバプロセスが前記ク
ライアントプロセスの停止時まで、前記クライアントプ
ロセスに括り付けられる、すなわち、前記クライアント
プロセスからのサービス要求を全て受け取り、前記クラ
イアントプロセス以外のクライアントプロセスからのサ
ービス要求を一切受け取らない手段と、前記クライアン
トプロセスに括り付けられたサーバプロセスで、前記ク
ライアントプロセスが停止し、括り付けが解かれるま
で、個々のサービス処理完了後であっても自サーバプロ
セスの停止を禁止する手段を備える。

【００１５】

【作用】本発明の持つ、サービス要求のうち、まだサー
バプロセスでサービス処理が行われていないサービス要
求の個数を求める手段と、複数のサーバプロセスの個数
を求める手段と、複数のサーバプロセスと同じサービス
要求を処理できるサーバプロセスを新たに起動する手段
と、サービス処理完了後に複数のサーバプロセス内のい
くつかのサーバプロセスを停止する手段と、サービス要
求の個数とサーバプロセスの個数に応じサーバプロセス
を起動・停止する手段は、サービス要求の頻度を表すパ
ラメタであるサービス処理の行われていないサービス要
求の個数に従い、サーバプロセスの個数を制限された一
定の範囲内で変化させる作用を与える。

【００１６】さらに、本発明は、クライアントプロセス
から同じサービス要求を複数回送った場合、複数のサー
バプロセスの内いずれかのサーバプロセスがクライアン
トプロセスの停止時まで、クライアントプロセスに括り
付けらる、すなわち、クライアントプロセスからのサー
ビス要求を全て受け取とり、クライアントプロセス以外
のクライアントプロセスからのサービス要求を一切受け
取らない手段と、クライアントプロセスに括り付けられ
たサーバプロセスにて、クライアントプロセスが停止
し、括り付けが解かれるまで、個々のサービス処理完了
後であっても自サーバプロセスの停止を禁止する手段
は、それぞれのサーバプロセスがクライアントやサービ
ス要求に応じて状態を持つことを可能にする作用を与え
る。

【００１７】

【実施例】図１に、本発明の第１の実施例のシステム構
成の説明図を示す。図１のシステムは、クライアントプ
ロセス１０１０と、クライアントプロセス１０１０が行
うＲＰＣのサービス要求を処理する複数のサーバプロセ
ス１０２０−１０２２と、サービス要求単位に複数のサ
ーバプロセスで共有する共有キュー１０３０と、個々の
サーバプロセスがそれぞれ持つ固有キュー１０４０−１
０４２と、共有キューに存在するサービス要求の個数を
示すサービス要求カウンタ１０５０と、サーバプロセス
の個数を示すサーバプロセスカウンタ１０６０と、サー
ビス要求がどのサーバプロセス１０２０−１０２２で処
理されたかを示すサービステーブル１０７０から構成さ
れる。

【００１８】クライアントプロセス１０１０は、共有キ
ュー１０３０、または、固有キュー１０４０−１０４２
にサービス要求を入れることでＲＰＣを行う。サーバプ
ロセス１０２０−１０２２は、共有キュー１０３０、も
しくは、固有キュー１０４０−１０４２からサービス要
求を取り出しサービス処理を行う。また、サービス要求
カウンタ１０５０、及び、サーバプロセスカウンタ１０
６０の値により起動・停止される。

【００１９】図２に、図１のシステムのクライアントプ
ロセス１０１０がＲＰＣの要求をサーバプロセスに送信
する方法を示す。

【００２０】クライアントプロセス１０１０は、ＲＰＣ
のサービス要求をキーにサービステーブル１０７０を検
索する（ステップ２０１０）。

【００２１】求めるエントリがサービステーブル１０７
０内に見つかった場合、クライアントプロセス１０１０
から同じサービス要求によるＲＰＣが既に行われている
事を示している、検索の結果得られたサービス要求に対
応する固有キュー名は、以前に行われたＲＰＣを処理し
たサーバプロセスの固有キュー名を示す。したがって、
得られた固有キュー１０４０−１０４２を用いてサーバ
プロセスにサービス要求を送る（ステップ２０２０）こ
とで同じサービス要求のＲＰＣを同じサーバプロセス１
０２０−１０２２で処理することができる。

【００２２】求めるエントリがサービステーブル１０７
０に見つからなかった場合、クライアントプロセス１０
１０から同じサービス要求によるＲＰＣは、まだ行われ
ていないことを示し、必要ならばサーバプロセス１０２
０−１０２２の起動・停止を行う必要がある。

【００２３】サーバプロセスカウンタと１０６０と、サ
ーバプロセスの上限値，下限値を比較し（ステップ２０
３０）、サーバプロセスカウンタ１０６０の値が上限値
を超えている場合は、サーバプロセスの停止（ステップ
２０４０）を、サーバプロセスカウンタ１０６０の値が
下限値を下回っている場合は、サーバプロセスの起動
（ステップ２０５０）を、それぞれサーバプロセスカウ
ンタ１０６０の値が上限値と下限値の間に収まるまで繰
り返す。

【００２４】サーバプロセスカウンタ１０６０の値が下
限値から上限値までの間に収まっている場合は、サービ
ス要求カウンタ１０５０と、処理を待つサービス要求の
上限値，下限値を比較し（ステップ２０６０）、サービ
ス要求カウンタ１０５０の値が上限値を超えている場合
は、サーバプロセスカウンタ１０６０の値が上限値未満
であるかどうかを比較し（ステップ２０７０）、サーバ
プロセスカウンタ1050の値が上限値未満の場合はサーバ
プロセス１０２０−１０２２の起動（ステップ２０８
０）を繰り返す。

【００２５】サービス要求カウンタ１０６０の値が下限
値を下回っている場合は、サーバプロセスカウンタ１０
５０の値が下限値より大きいかどうかを比較し（ステッ
プ２０９０）、サーバプロセスカウンタ１０６０の値が
下限値より大きい場合は、サーバプロセス１０２０−１
０２２の停止（ステップ２１００）を繰り返す。

【００２６】サービス要求カウンタ１０６０の値が下限
値から上限値の間、または、サービス要求カウンタ１０
６０の値とサーバプロセスカウンタ１０６０の値が共に
それぞれの上限以上、または、サービス要求カウンタ１
０６０とサーバプロセスカウンタ１０６０の値が共にそ
れぞれの下限以下の場合は、共有キュー１０３０を用い
て任意のサーバプロセス１０２０−１０２２にサービス
要求を送り、サービス要求カウンタ１０５０をカウント
アップする（ステップ２１１０）。

【００２７】クライアントプロセス１０１０は、どのサ
ーバプロセス１０２０−１０２２でサービスが処理され
たのかを知るために、サーバプロセスからの固有キュー
名の通知を受け、サービス要求と固有キュー名の対をサ
ービステーブル１０７０に登録する（ステップ２１２
０）。

【００２８】図３に、図１のシステムのクライアントプ
ロセス１０１０の起動の方法を示す。

【００２９】クライアントプロセス１０１０は、起動時
にサービステーブル１０７０を作成し、全エントリを初
期化する（ステップ３０１０）。

【００３０】図４に、図１のシステムのクライアントプ
ロセス１０１０の停止の方法を示す。

【００３１】クライアントプロセス１０１０は、停止時
にサービステーブル１０７０に登録されている固有キュ
ー名を用いクライアント停止通知をサーバプロセス１０
２０−１０２２に送る（ステップ４０１０）。

【００３２】サービステーブル１０７０に登録されてい
る全ての固有キューにクライアント停止通知を送ること
を繰り返し（ステップ４０２０）たのち、サービステー
ブル１０７０を廃棄し自分プロセスを停止する（ステッ
プ４０３０）。

【００３３】図５に、図１のシステムのサーバプロセス
１０２０−１０２２の起動の方法を示す。

【００３４】サーバプロセス１０２０−１０２２は、起
動時にサーバプロセスカウンタ1060をカウントアップす
る（ステップ５０１０）。

【００３５】図６に、図１のシステムのサーバプロセス
１０２０−１０２２のサービス要求の受け取りと停止の
方法を示す。

【００３６】サーバプロセス１０２０−１０２２は、共
有キュー１０３０よりなんらかの要求を取り出せるまで
待ち、要求を取り出す（ステップ６０１０）。

【００３７】要求を判定し（ステップ６０２０）、要求
がサーバ停止要求の場合は、サーバプロセスカウンタ１
０６０をカウントダウンし、自サーバプロセス１０２０
−１０２２を終了する（ステップ６０３０）。

【００３８】要求がサービス要求であった場合、このサ
ービス要求はクライアント１０１０からの最初のサービ
ス要求を意味する。従って、サービス要求カウンタ１０
５０をカウントダウンし、サービス要求を送ったクライ
アント１０１０に対し自サーバプロセス１０２０−１０
２２の固有キュー名をクライアントプロセス１０１０に
通知する（ステップ６０４０）。

【００３９】サービス処理を行い、必要ならばクライア
ントプロセス１０１０にサービスの応答を返す（ステッ
プ６０５０）。

【００４０】サーバプロセス１０２０−１０２２は、一
つのサービス要求に関する処理を終了したので次のサー
ビス要求を待つ。固有キュー１０４０−１０４２よりな
んらかの要求、または、通知を取り出せるまで待ち、要
求、または、通知を取り出す（ステップ６０６０）。

【００４１】固有キュー１０４０−１０４２よりクライ
アント完了通知を取り出した場合、以後、そのクライア
ント１０１０から固有キュー１０４０−１０４２を用い
てサービス要求が送られてくることが無いので、再度、
共有キュー１０３０からの要求を待つ（ステップ６０７
０）。

【００４２】固有キュー１０４０−１０４２からサービ
ス要求を取り出した場合は、再度サービス処理を行う。

【００４３】図７に、本発明の第２の実施例のシステム
の説明図を示す。図７のシステムは、クライアントプロ
セス１０１０と、クライアントプロセス１０１０が行う
RPCのサービス要求を処理する複数のサーバプロセス１
０２０−１０２２と、個々のサーバプロセス１０２０−
１０２２がそれぞれ持つ固有キュー１０４０−1042と、
個々のサーバプロセス１０２０−１０２２がそれぞれ持
ち、個々のサーバプロセスが受け持っているクライアン
トプロセス１０１０の個数を表すクライアントカウンタ
７０１０−７０１２と、個々のサーバプロセス１０２０
−１０２２がそれぞれ持ち個々の固有キュー１０４０−
１０４２に存在するサービス要求の個数を示すサービス
要求カウンタ７０２０−７０２２と、サービス要求が、
どのサーバプロセスで処理されたかを示すサービステー
ブル１０７０から構成される。

【００４４】クライアントプロセス１０１０は、固有キ
ュー１０４０−１０４２にサービス要求を入れることで
ＲＰＣを行う。サーバプロセス１０２０−１０２２は、
固有キュー１０４０−１０４２からサービス要求を取り
出しサービス処理を行う。また、サーバプロセス１０２
０−１０２２は、サービス要求カウンタ７０２０−７０
２２、及び、クライアントカウンタ７０１０−７０１２
の値により起動・停止される。

【００４５】図８に、図７のシステムにおけるクライア
ントプロセス１０１０がＲＰＣの要求をサーバプロセス
に送信する方法を示す。

【００４６】以下、図１のシステムにおける方法との相
違点に重点を置き図７のシステムの処理を示す。

【００４７】図７のシステムは、図１のシステムに対
し、サーバプロセスカウンタ１０６０がなく、サービス
要求カウンタ１０５０が各サーバプロセス単位に分かれ
ている。このため、サーバプロセスの個数、まだ、サー
ビス処理を行っていないサービス要求の個数を求める必
要がある。

【００４８】図７のシステムにおいて、サーバプロセス
の個数はサービス要求カウンタ7020−７０２２の個数と
して表される（ステップ８０３０，８０７０，８０９
０）。

【００４９】また、まだサービス処理を行っていないサ
ービス要求の個数は、それぞれのサービス要求カウンタ
７０２０−７０２２の値を合計することで表される（ス
テップ８０６０）。

【００５０】図７のシステムは、共有キュー１０３０を
持たないため図１のシステムにおいて共有キュー１０３
０にサービス要求を入れる処理を行えないため、全ての
サービス要求カウンタ７０２０−７０２２とクライアン
トカウンタ７０１０−7012の値を比較し、クライアント
カウンタの値が０で、もっとも値の少ないサービス要求
カウンタ７０２０−７０２２に対応する固有キュー１０
４０−１０４２を見つけ、（ステップ８１１０）、この
固有キューにクライアント開始通知と、サービス要求を
入れ（ステップ８１２０）、サービス要求カウンタ７０
２０−７０２２をカウントアップする処理を行う（ステ
ップ８１３０）。

【００５１】クライアントプロセスは、任意のサーバプ
ロセス１０２０−１０２２を選択し、対応する固有キュ
ー１０４０−１０４２にサーバ停止要求を入れる（ステ
ップ８０５０，８１００）。

【００５２】図７のシステムにおけるクライアントプロ
セス１０１０の起動及び、停止時の方法は図１のシステ
ムにおけるクライアントプロセス１０１０の起動及び停
止の方法と同一である。

【００５３】図９に、図７のシステムのサーバプロセス
１０２０−１０２２の起動の方法を示す。

【００５４】サーバプロセス１０２０−１０２２は、起
動時にサービス要求カウンタ7020−７０２２、および、
クライアントカウンタ７０１０−７０１２を作成し初期
化する（ステップ９０１０）。

【００５５】図１０に、図７のシステムのサーバプロセ
ス１０２０−１０２２のサービス要求の受け取りと停止
の方法を示す。

【００５６】図１のシステムは、共有キュー１０３０
と、固有キュー１０４０−１０４２を使いわけることで
停止するサーバプロセス１０２０−１０２２の制限を行
っているが、図７のシステムは共有キュー１０３０を持
たないため、サーバプロセス１０２０−１０２２でクラ
イアントカウンタ７０１０−７０１２を利用する。

【００５７】サーバプロセス１０２０−１０２２は、固
有キュー１０４０−１０４２より、なんらかの要求・通
知を取り出せるまで待ち、これを取り出す（ステップ10
010)。

【００５８】要求・通知を判定し（ステップ１００２
０）、サーバ停止要求の場合は、自サーバプロセス１０
２０−１０２２内に持つ停止要求フラグを立てる（ステ
ップ１００３０）。

【００５９】クライアント開始通知を取り出した場合、
クライアント１０１０からの最初のサービス要求が送ら
れる事を示す。従って、サービス要求を送ったクライア
ント１０１０に対し自サーバプロセス１０２０−１０２
２の固有キュー名をクライアントプロセス１０１０に通
知し（ステップ１００４０）、クライアントカウンタ７
０１０−７０１２をカウントアップする（ステップ１０
０５０）。

【００６０】サービス要求であった場合サービス要求カ
ウンタ７０２０−７０２２をカウントダウンし（ステッ
プ１００６０）、サービス処理を行い、必要ならばクラ
イアントプロセス１０１０にサービスの応答を返す（ス
テップ１００５０）。

【００６１】クライアント完了通知を取り出した場合、
以後そのクライアント１０１０から固有キュー１０４０
−１０４２を用いてサービス要求が送られてくることが
無いので、クライアントカウンタ７０１０−７０１２を
カウントダウンし（ステップ１００７０）、クライアン
トカウンタ７０１０−７０１２を判定し（ステップ１０
０９０）、０の場合、停止要求フラグを調べ（ステップ
１０１００）、フラグがたっている場合、サーバ停止要
求が送られてきているので自サーバプロセスを停止する
（ステップ１０１１０）。各要求・通知に従った処理完
了の後は、再度固有キューから要求・通知を取り出せる
まで待つ。

【００６２】図１１に、本発明の第３の実施例のシステ
ムの説明図を示す。図１１のシステムは、クライアント
プロセス１０１０と、クライアントプロセス１０１０が
行うＲＰＣのサービス要求を処理する複数のサーバプロ
セス１０２０−１０２２と、複数のサーバプロセス１０
２０−１０２２を代表し、クライアントプロセス1010か
らのサービス要求を受け取る中継プロセス１１０１０
と、サービス要求単位に複数のサーバプロセス１０２０
−１０２２で共有する共有キュー１０３０と、個々のサ
ーバプロセス１０２０−１０２２がそれぞれ持つ固有キ
ュー１０４０−１０４２と、共有キュー１０３０に存在
するサービス要求の個数を示すサービス要求カウンタ１
０５０と、サーバプロセスの個数を示すサーバプロセス
カウンタ１０６０と、サービス要求がどのサーバプロセ
スで処理されたかを示すサービステーブル１０７０から
構成される。

【００６３】中継プロセス１１０１０は、複数のサーバ
プロセス１０２０−１０２２の種類、すなわち、サーバ
プロセス１０２０−１０２２が処理するサービスのサー
ビス要求の種類に対応し、複数の共有キュー１０３０，
サービス要求カウンタ1050,サーバプロセスカウンタ１
０６０を持つ。

【００６４】クライアントプロセス１０１０は、中継プ
ロセス１１０１０にサービス要求を送る、または、固有
キュー１０３０にサービス要求を入れることでＲＰＣを
行う。サーバプロセス１０２０−１０２２は、共有キュ
ー１０３０、もしくは、固有キュー１０４０−１０４２
からサービス要求を取り出しサービス処理を行う。ま
た、サービス要求カウンタ１０５０、及び、サーバプロ
セスカウンタ１０６０の値により起動・停止される。

【００６５】図１２に、図１１のシステムにおいてクラ
イアントプロセス１０１０がＲＰＣの要求をサーバプロ
セス１０２０−１０２２に送信する方法を示す。

【００６６】クライアントプロセス１０１０は、ＲＰＣ
のサービス要求をキーにサービステーブル１０７０を検
索する（ステップ１２０１０）。

【００６７】求めるエントリがサービステーブル１０７
０内に見つかった場合、クライアントプロセス１００１
から同じサービス要求によるＲＰＣが既に行われている
事を示している、検索の結果得られたサービス要求に対
応する固有キュー名は、以前に行われたＲＰＣを処理し
たサーバプロセス１０２０−１０２２の固有キュー名を
示す。したがって、得られた固有キュー１０４０−１０
４２を用いてサーバプロセス１０２０−１０２２にサー
ビス要求を送る（ステップ１２０２０）ことで、サーバ
プロセスことで同じサービス要求のＲＰＣを同じサーバ
プロセス1020−１０２２で処理することができる。

【００６８】求めるエントリがサービステーブル１０７
０に見つからなかった場合、クライアントプロセス１０
１０から同じサービス要求によるＲＰＣは、まだ行われ
ていないことを示し、中継プロセス１１０１０へサービ
ス要求を送り（ステップ１２０３０）、どのサーバプロ
セス１０２０−１０２２でサービスが処理されたのかを
知るために、サーバプロセス１０２０−１０２２からの
固有キュー名の通知を受け、サービス要求と固有キュー
名の対をサービステーブル１０７０に登録する（ステッ
プ１２０４０）。

【００６９】図１３に、図１１のシステムにおいて中継
プロセス１１０１０がＲＰＣの要求をサーバプロセス１
０２０−１０２２へ中継する方法を示す。

【００７０】クライアントプロセス１０１０から受け取
ったサービス要求に従い、サービスを処理する複数のサ
ーバプロセス１０２０−１０２２を決定し、サーバプロ
セスカウンタと１０６０、サーバプロセスの上限値，下
限値を比較し（ステップ１３０３０）、サーバプロセス
カウンタ１０６０の値が上限値を超えている場合は、サ
ーバプロセスの停止（ステップ１３０４０）を、サーバ
プロセスカウンタ１０６０の値が下限値を下回っている
場合は、サーバプロセスの起動（ステップ１３０５０
を、それぞれサーバプロセスカウンタ１０６０の値が上
限値と下限値の間に収まるまで繰り返す。

【００７１】サーバプロセスカウンタ１０６０の値が下
限値から上限値までの間に収まっている場合は、サービ
ス要求カウンタ１０５０と、処理を待つサービス要求の
上限値，下限値を比較し（ステップ１３０６０）、サー
ビス要求カウンタ１０５０の値が上限値を超えている場
合は、サーバプロセスカウンタ１０６０の値が上限値未
満であるかを比較し(ステップ１３０７０)、サーバプロ
セスカウンタ１０５０の値が上限値未満の場合はサーバ
プロセス１０２０−１０２２の起動（ステップ１３０８
０）を繰り返す。

【００７２】サービス要求カウンタ１０６０の値が下限
値を下回っている場合は、サーバプロセスカウンタ１０
５０の値が下限値より大きいかを比較し（ステップ1309
0)、サーバプロセスカウンタ１０６０の値が下限値より
大きい場合は、サーバプロセス１０２０−１０２２の停
止（ステップ１３１００）を繰り返す。

【００７３】サービス要求カウンタ１０６０の値が下限
値から上限値の間、または、サービス要求カウンタ１０
６０の値とサーバプロセスカウンタ１０６０の値が共に
それぞれの上限以上、または、サービス要求カウンタ１
０６０とサーバプロセスカウンタ１０６０の値が共にそ
れぞれの下限以下の場合は、共有キュー１０３０を用い
て任意のサーバプロセス１０２０−１０２２にサービス
要求を送り、サービス要求カウンタ１０５０をカウント
アップする（ステップ１３１１０）。

【００７４】図１１のシステムにおいて、クライアント
プロセス１０１０の起動及び、停止時、サーバプロセス
の処理は、図１のシステムの方法と同一である。また、
図１１のシステムにおいて、サーバプロセス１０２０−
１０２２の起動、サービス要求の受け取りと停止の処理
も、図１のシステムの方法と同一である。

【００７５】図１４に、本発明の第４の実施例のシステ
ム構成図を示す。図１４のシステムは、クライアントプ
ロセス１０１０と、クライアントプロセス１０１０が行
うＲＰＣのサービス要求を処理する複数のサーバプロセ
ス１０２０−１０２２と、複数のサーバプロセス１０２
０−１０２２を代表し、クライアントプロセス1010から
のサービス要求を受け取る中継プロセス１１０１０と、
サービス要求単位に複数のサーバプロセス１０２０−１
０２２で共有する共有キュー１０３０と、個々のサーバ
プロセス１０２０−１０２２がそれぞれ持つ固有キュー
１０４０−１０４２と、共有キュー１０３０に存在する
サービス要求の個数を示すサービス要求カウンタ１０５
０と、サーバプロセスの個数を示すサーバプロセスカウ
ンタ１０６０と、サービス要求がどのサーバプロセスで
処理されたかを示すサービステーブル１４０１０−１４
０１２から構成される。

【００７６】中継プロセス１１０１０は、複数のサーバ
プロセス１０２０−１０２２の種類、すなわち、サーバ
プロセス１０２０−１０２２が処理するサービスのサー
ビス要求の種類に対応し、複数の共有キュー１０３０，
サービス要求カウンタ1050，サーバプロセスカウンタ１
０６０を持ち、クライアントプロセス１０１０に対応し
て、複数のサービステーブル１４０１０−１４０１２を
持つ。

【００７７】図１４のシステムにおいて、クライアント
プロセス１０１０は、ＲＰＣを行う毎に中継プロセス１
１０１０にサービス要求を送信する。中継プロセス1101
0 は、サービス要求を送ったクライアント１０１０に対
応するサービステーブル１４０１０−１４０１２を見つ
け、自中継プロセスが、図１のシステムにおけるクライ
アントプロセスと同一の処理を行うことでサーバプロセ
スにサービス要求を中継する。

【００７８】また、図１４のシステムにおいて、クライ
アントプロセス１０１０の停止は、クライアントプロセ
ス１０１０が、中継プロセス１１０１０にクライアント
停止通知を送り、中継プロセス１１０１０が図１のシス
テムにおけるクライアントプロセスと同一の処理を行う
ことでサーバプロセスにクライアント停止通知を中継す
る。図１４のシステムにおいて、サーバプロセス１０２
０−１０２２の起動，サービス要求の受け取りと停止の
処理は、図１のシステムの方法と同一である。

【００７９】

【発明の効果】本発明によれば、同じサービス要求を処
理できるサーバプロセスが複数存在する計算機システム
において、これらのサーバプロセスが負荷分散を行い、
サーバプロセスが状態を持って、負荷分散を行うサーバ
プロセスの個数を特定の範囲内で増減することができ
る。

【図面の簡単な説明】

【図１】第１の実施例のシステム構成の説明図。

【図２】クライアントプロセスのＲＰＣサービス要求送
信処理を表すフローチャート。

【図３】クライアントプロセスの開始処理を表すフロー
チャート。

【図４】クライアントプロセスの停止処理を表すフロー
チャート。

【図５】サーバプロセスの起動処理を表すフローチャー
ト。

【図６】サーバプロセスのサービス要求の受け取りと停
止処理を表すフローチャート。

【図７】第２の実施例のシステムの説明図。

【図８】クライアントプロセスのＲＰＣサービス要求送
信処理を表すフローチャート。

【図９】サーバプロセスの起動処理を表すフローチャー
ト。

【図１０】サーバプロセスのサービス要求の受け取りと
停止処理を表すフローチャート。

【図１１】第３の実施例のシステムの説明図。

【図１２】クライアントプロセスのＲＰＣサービス要求
送信処理を表すフローチャート。

【図１３】中継プロセスのサービス要求処理を表すフロ
ーチャート。

【図１４】第４の実施例のシステムの説明図。

【符号の説明】

１０１０…クライアントプロセス、１０２０−１０２２
…サーバプロセス、１０３０…共有キュー、１０４０−
１００４２…固有キュー、１０５０…サービス要求カウ
ンタ、１０６０…サーバプロセスカウンタ、１０７０…
サービステーブル。

Claims (9)

【特許請求の範囲】
1. 【請求項１】プログラムの実行単位であるプロセスを複
   数並列に処理できる計算機システムで、クライアントプ
   ロセスがサーバプロセスにサービス要求を送り、サーバ
   プロセスが前記サービス要求に従ったサービス処理を行
   う、同じサービス要求を処理できるサーバプロセスを複
   数もち、前記複数のサーバプロセスのうちもっとも早く
   サービス処理を開始できるサーバプロセスが前記サービ
   ス要求を受け取るリモートプロシジャコール方法におい
   て、 前記サービス要求のうちまだサーバプロセスでサービス
   処理が行われていないサービス要求の個数を求める手段
   と、前記複数のサーバプロセスの個数を求める手段と、
   前記複数のサーバプロセスと同じサービス要求を処理で
   きるサーバプロセスを新たに起動する手段と、サービス
   処理完了後に前記複数のサーバプロセス内のいくつかの
   サーバプロセスを停止する手段と、前記サービス要求の
   個数と前記サーバプロセスの個数に応じ前記サーバプロ
   セスを起動・停止する手段を備えることを特徴とするリ
   モートプロシジャコール方法。
2. 【請求項２】請求項１において、前記クライアントプロ
   セスから同じサービス要求を複数回送った場合、前記複
   数のサーバプロセスの内いずれかのサーバプロセスが前
   記クライアントプロセスの停止時まで、前記クライアン
   トプロセスに括り付けられる、すなわち、前記クライア
   ントプロセスからのサービス要求を全て受けとり、前記
   クライアントプロセス以外のクライアントプロセスから
   のサービス要求を一切受け取らない手段と、前記クライ
   アントプロセスに括り付けられたサーバプロセスで、前
   記クライアントプロセスが停止し、括り付けが解かれる
   まで、個々のサービス処理完了後であっても自サーバプ
   ロセスの停止を禁止する手段を備えたリモートプロシジ
   ャコール方法。
3. 【請求項３】請求項１において、前記複数のサーバプロ
   セスで共有するキューと、前記共有キューに対応し、前
   記複数のサーバプロセスから更新可能で、前記クライア
   ントプロセスから参照可能なサーバプロセスカウンタ
   と、前記共有キューに対応し、前記複数のサーバプロセ
   スと前記クライアントプロセスの双方から更新可能なサ
   ービス要求カウンタと、前記サーバプロセスカウンタ
   を、前記複数のサーバプロセスのそれぞれが起動したと
   きにカウントアップし、前記複数のサーバプロセスのそ
   れぞれが停止したときにカウントダウンすることで、前
   記サーバプロセスカウンタにより動作中の前記複数のサ
   ーバプロセスの個数を求める手段と、前記サービス要求
   カウンタを、前記クライアントプロセスがサービス要求
   を送った時にカウントアップし、前記複数のサーバプロ
   セスのいずれかがサービス処理を開始する時にカウント
   ダウンすることで、前記サービス要求カウンタにより、
   サービス処理がまだ開始されていないサービス要求の個
   数を求める手段と、前記クライアントプロセスがサービ
   ス要求を前記共有キューに入れ、前記複数のサーバプロ
   セスのうちサービス処理が完了したいずれかのサーバプ
   ロセスが前記共有キューからサービス要求を取り出すこ
   とによりクライアントプロセスからサーバプロセスへサ
   ービス要求を送る手段と、前記共有キュー単位に、前記
   複数のサーバプロセスの個数と、前記サービス処理がま
   だ開始されていないサービス要求の個数に、それぞれ、
   上限と、下限を設定し、前記サービス要求カウンタが設
   定された上限以上であり、かつ、前記サーバプロセスカ
   ウンタが上限未満のとき、新たに前記複数のサーバプロ
   セスと同じサービス要求を処理できるサーバプロセスを
   起動する手段と、前記サービス要求カウンタが設定され
   た下限以下であり、かつ、前記サーバプロセスカウンタ
   が下限より大きいとき、新たに前記複数のサーバプロセ
   スのいずれかをサービス処理完了後に停止する手段を備
   える事を特徴としたリモートプロシジャコール方法。
4. 【請求項４】請求項２または３において、前記共有キュ
   ーとは別に、前記複数のサーバプロセスが個々のサーバ
   プロセス単位に固有キューを有し、 前記複数のサーバプロセスのいずれかが前記共有キュー
   よりサービス要求を取り出しサービス処理を行う時に、
   前記クライアントプロセスに前記サーバプロセスの固有
   キューを識別するための名称を前記クライアントプロセ
   スへ通知する手段と、前記いずれかのサーバプロセス
   が、前記共有キューよりサービス処理を取り出したのち
   は、前記固有キューからのみサービス要求を取り出す手
   段と、前記クライアントプロセスが前記サービス要求と
   前記いずれかのサーバプロセスから通知された固有キュ
   ーの名称の対を記録するサービステーブルを有し、前記
   クライアントプロセスがサービス要求を送る時に、送る
   サービス要求をキーに前記サービステーブルをサーチ
   し、サービス要求と対をなす固有キュー名称が見つかっ
   た場合、固有キューにサービス要求を入れ、前記サービ
   ス要求と対をなす固有キュー名称が見つからない場合
   に、共有キューにサービス要求を入れる手段と、前記い
   ずれかのサーバプロセスが固有キューからサービス要求
   を取り出しサービス処理を行う手段と、前記クライアン
   トプロセスで全てのリモートプロシジャコールが完了し
   たときに、前記サービステーブルに記録された全ての固
   有キューにクライアント完了通知を入れる手段と、 前記いずれかのサーバプロセスが固有キューからクライ
   アント完了通知を取り出した場合、前記共有キューから
   のみサービス要求を取り出す手段を有することを特徴と
   するリモートプロシジャコール方法。
5. 【請求項５】請求項３または４において、停止すべきサ
   ーバプロセスの個数分サーバ停止要求を前記共有キュー
   に入れる手段と、前記複数のサーバプロセスのいずれか
   が共有キューからサーバ停止要求を取り出した場合に、
   自サーバプロセスを停止する手段とを有するリモートプ
   ロシジャコール方法。
6. 【請求項６】請求項１において、前記複数のサーバプロ
   セスが個々に固有キューを有し、前記固有キューに対応
   し、それぞれのサーバプロセスのみ更新可能でクライア
   ントプロセスから参照可能なサービス要求カウンタを有
   し、前記サービス要求カウンタを前記それぞれのサーバ
   プロセス起動時に有効に、前記それぞれのサーバプロセ
   ス停止時に無効にする。前記サービス要求カウンタのう
   ち有効なカウンタの個数を得ることで前記複数のサーバ
   プロセスの個数を求める手段と、前記サービス要求カウ
   ンタを前記それぞれのサーバプロセスにサービス要求が
   きた時カウントアップし、サーバプロセスがサービス要
   求を処理したときにカウントダウンすることにより、前
   記それぞれのサーバプロセスに送られているがまだサー
   ビス処理を行っていないサービス要求の個数を求める手
   段と、前記クライアントプロセスがサービス要求を送る
   とき、前記サービス要求カウンタの全てを参照し、もっ
   とも値の小さいサービス要求カウンタに対応するサーバ
   プロセスの固有キューにサービス要求を入れる手段と、
   前記複数のサーバプロセス単位に、前記複数のサーバプ
   ロセスの個数と、前記サービス処理が開始されていない
   サービス要求の個数の合計に、それぞれ、上限と、下限
   を設定し、前記サービス要求カウンタの合計が前記設定
   されたサービス要求の上限以上のとき、かつ、前記有効
   なサービス要求カウンタの個数が前記設定されたサーバ
   プロセスの上限未満のとき、新たに前記複数のサーバプ
   ロセスと同じサービス要求を処理できるサーバプロセス
   を起動する手段と、前記サービス要求カウンタの合計が
   前記設定されたサービス要求の下限以下のとき、かつ、
   前記有効なサービス要求カウンタの個数が前記設定され
   たサーバプロセスの下限より大きいとき、新たに前記複
   数のサーバプロセスのいずれかをサービス処理完了後に
   停止する手段を備える事を特徴とするリモートプロシジ
   ャコール方法。
7. 【請求項７】請求項２または６において、前記複数のサ
   ーバプロセスのうちそれぞれのサーバプロセスに対応
   し、前記それぞれのサーバプロセスのみ更新可能なクラ
   イアントカウンタを複数有し、前記クライアントカウン
   タを、クライアント開始通知を受けたときにカウントア
   ップし、クライアント停止要求を受けたときにカウント
   ダウンすることで、現在いくつのクライアントからサー
   ビス要求を受けているのかを求める手段と、前記クライ
   アントプロセスが前記サービス要求とサーバプロセスか
   ら通知された固有キューの名称の対を記録するサービス
   テーブルを有し、前記クライアントプロセスがサービス
   要求を送る時に、送るサービス要求をキーに前記サービ
   ステーブルをサーチし、サービス要求と対をなす固有キ
   ュー名称が見つかった場合、見つかった固有キューにサ
   ービス要求を入れ、前記サービス要求と対をなす固有キ
   ュー名称が見つからない場合に、前記サービス要求カウ
   ンタおよび前記クライアントカウンタの全てを参照し、
   クライアントカウンタの値が０で、もっとも値の小さい
   サービス要求カウンタに対応するサーバプロセスの固有
   キューにクライアント開始通知と、サービス要求をいれ
   る手段と、前記サーバプロセスが固有キューからサービ
   ス要求を取り出しサービス処理を行う手段と、前記クラ
   イアントプロセスで全てのリモートプロシジャコールが
   完了したときに、前記サービステーブルに記録された全
   ての固有キューにクライアント完了通知を入れる手段
   と、 前記サーバプロセスが固有キューからクライアント開始
   通知を取り出した場合、前記クライアントカウンタをカ
   ウントアップする手段と、前記サーバプロセスが固有キ
   ューからクライアント完了通知を取り出した場合、前記
   クライアントカウンタをカウントダウンする手段と、前
   記クライアントカウンタが０のサーバプロセスに限りサ
   ーバプロセス停止要求を送る手段を有するリモートプロ
   シジャコール方法。
8. 【請求項８】請求項２，４，５または７において、前記
   クライアントプロセスと、前記複数のサーバプロセスの
   間に、前記サービス要求を前記クライアントプロセスか
   ら前記複数のサーバプロセスへ中継する中継プロセスを
   有し、前記クライアントプロセスの代わりに、前記中継
   プロセスが、前記サーバプロセスカウンタ、または、前
   記サービス要求カウンタ、または、前記クライアントカ
   ウンタを参照・更新する手段と、前記クライアントプロ
   セスが前記サービステーブルを検索してサービス要求に
   対応する前記固有キュー名を得られなかった場合、前記
   クライアントプロセスは、サービス要求の種類にかかわ
   らず、前記中継プロセスにサービス要求を送る手段と、
   クライアントプロセスからのサービス要求を受け取った
   前記中継プロセスは、サービス要求を判定し、前記サー
   ビス要求を処理するサーバプロセスにサービス要求を送
   る手段を有するリモートプロシジャコール方法。
9. 【請求項９】請求項８において、前記クライアントプロ
   セスの代わりに、前記中継プロセスが前記クライアント
   プロセス毎に前記サービステーブルを有し、前記クライ
   アントプロセスがリモートプロシジャコールを行う毎
   に、サービス要求を前記中継プロセスへ送る手段と、前
   記中継プロセスは、サービス要求を送ったクライアント
   プロセスに対応する前記サービステーブルを検索してサ
   ービス要求に対応する前記固有キュー名を得られた場
   合、見つかった固有キューを用いてサービス要求を送る
   手段と、サービス要求に対応する前記固有キュー名を得
   られなかった場合、サービス要求を判定し、前記サービ
   ス要求を処理するサーバプロセスにサービス要求を送る
   手段を有するリモートプロシジャコール方法。