JPH07121468A - サーバー選択装置 - Google Patents

Abstract

(57)【要約】 【目的】かな漢字変換サーバーと、かな漢字変換サービ
スを受けるクライアントが接続するネットワークシステ
ムおいて、クライアントに常に安定したかな漢字変換サ
ービスを提供し、同時に全体的な処理効率を向上させ
る。 【構成】問合せ受付手段１１でクライアントからのかな
漢字変換要求を受け付け、サーバー選択手段１４でサー
バー情報保持手段を調べ、その時点で最も処理負担の少
ないサーバーを選択し、送信手段１５で前記選択された
サーバー名を問い合わせのあったクライアントに通知す
る。また、問合せ受付手段１１でサーバーからの状態変
化の通知を受け付け、情報更新手段１３でサーバー情報
保持手段１２の該当するサーバーの利用状況に関する情
報を更新する。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】この発明は、かな漢字変換サーバ
ーと、かな漢字変換サービスを受けるクライアントが接
続するネットワークシステムに関し、詳しくはクライア
ントからの問い合わせに応じて最適なサーバーを選択
し、そのサーバー名をクライアントに通知するサーバー
選択装置に関する。

【０００２】

【従来の技術】従来、ネットワークを利用したかな漢字
変換では、かな漢字変換サービスを提供するサーバーに
接続することにより、クライアント（かな漢字変換装
置）は自身で単語辞書にアクセスすることなしに、かな
漢字変換サービスを受けことができる。かな漢字変換サ
ービスを受けようとするクライアントがかな漢字変換サ
ービスを提供するサーバーと通信しようとするときは、
サーバー名を特定して指定したり、いくつかの候補を記
述して順番に接続を試みたりしていた。

【０００３】

【発明が解決しようとする課題】ところで、このような
ネットワークを利用したかな漢字変換では、クライアン
ト側はサーバー名を知らなければ目的とするサーバーに
接続することはできなかった。また、サーバー名を知っ
ている場合でも、そのサーバーが何らかの理由によりダ
ウンしていたり、サーバー自身が立ち上がっていないよ
うな場合も接続することはできないため、クライアント
はかな漢字変換ができないという問題点があった。さら
に、従来はクライアントのスケジューリングについては
何ら考慮されていなかったため、例えばあるサーバーで
はクライアントの接続数が多く、あるサーバーではクラ
イアントの接続がほとんどない、というように特定のサ
ーバーにクライアントが集中した場合には、全体的な処
理効率が悪くなるという問題点があった。

【０００４】この発明は、サーバー名あるいはその状態
を知らない場合でも、常に安定したかな漢字変換サービ
スを提供するとともに、負荷を適切に分散することによ
り、全体的な処理効率を向上させるようにしたサーバー
選択装置を提供することを目的とする。

【０００５】

【課題を解決するための手段】この発明に係わるサーバ
ー選択装置は、かな漢字変換サービスを提供するサーバ
ーと、当該サーバーに接続してかな漢字変換サービスを
受けるクライアントにより構成されるネットワークシス
テムに適用されるものであり、ネットワークを通じてク
ライアントからサーバーの問い合わせを受け付ける問い
合わせ受付手段と、ネットワーク上に接続されたサーバ
ーの利用状況に関する情報を保持するサーバー情報保持
手段と、前記サーバーの状態変化に応じて、該当するサ
ーバーの利用状況に関する情報を更新する情報更新手段
と、前記問い合わせ受付手段で受け付けたサーバーの問
い合わせに応じて前記サーバー情報保持手段を参照し、
その時点で最も処理負担の少ないサーバーを選択するサ
ーバー選択手段と、前記サーバー選択手段で選択された
サーバー名を、問い合わせのあったクライアントに送信
する送信手段とを具えたことを特徴とする。

【０００６】

【作用】問合わせ受付手段でクライアントからサーバー
についての問い合わせを受け付けると、サーバー選択手
段はサーバー情報保持手段を調べ、その時点で最も処理
負担の少ないサーバーを選択する。送信手段１５はサー
バー選択手段で選択されたサーバー名を問い合わせのあ
ったクライアントに通知する。また、問合わせ受付手段
でサーバーからの状態変化の通知を受け付けると、情報
更新手段はサーバー情報保持手段の該当するサーバーの
利用状況に関する情報を更新する。

【０００７】これによれば、クライアントがサーバー名
を知らなくても、サーバー選択装置で選択された最適な
サーバー名が通知されるため、クライアントはサーバー
名を覚える必要はない。また、特定のサーバーがダウン
または立ち上がっていないような場合でも、正常に稼動
している他のサーバー名が通知されるため、クライアン
トはサーバー候補のリストに従って順番に接続を試みる
などの操作を行う必要がない。したがって、サーバーの
状態にかかわらず安定したかな漢字変換サービスを得る
ことができる。また、処理負担の少ないサーバーから順
に選択されるため、特定のサーバーにクライアントの接
続が集中することがない。すなわち、処理負荷の分散が
図られるため、全体的な処理効率を向上させることがで
きる。

【０００８】

【実施例】以下、この発明に係わるサーバー選択装置の
一実施例を図面を参照しながら詳細に説明する。

【０００９】図２は、この発明に係わるサーバー選択装
置をマスタサーバーとして接続したネットワークシステ
ムの構成図である。図２において、１（〜Ｍ）はかな漢
字変換サービスを提供するサーバー、２（〜Ｎ）は前記
サーバーに接続してかな漢字変換サービスを受けるクラ
イアント、３はこの発明に係わるサーバー選択装置を適
用したマスタサーバーであり、これらは一つのネットワ
ーク４上に接続されている。なお、この発明に係わるサ
ーバー選択装置の機能は、他のサーバーあるいはクライ
アント上で実現してもよい。

【００１０】図１は、上記マスタサーバー３の機能的な
構成を示すブロック図である。このマスタサーバー３
は、機能的に、問合せ受付手段１１、サーバー情報保持
手段１２、情報更新手段１３、サーバー選択手段１４、
送信手段１５により構成されている。

【００１１】問合せ受付手段１１は、ネットワーク４と
接続しており、このネットワーク４を通じてクライアン
トあるいはサーバーからのパケットを受け付け、その内
容を解釈する。

【００１２】サーバー情報保持手段１２は、ネットワー
ク上に接続されたサーバーの利用状況に関する情報を保
持する。サーバーの利用状況に関する情報としては、例
えばサーバーが接続しているクライアント数、サーバー
のＣＰＵコストとクライアント数の積（トータルコス
ト）、あるいはそのサーバーの単位時間当たりの平均変
換文字数などが考えられる。これらの情報は、後述する
かな漢字変換サーバー利用状況テーブルで管理される。

【００１３】情報更新手段１３は、ネットワーク上にあ
るサーバーの状態変化に応じて前記テーブルの内容を更
新する。この実施例では、サーバーの利用状況に関する
情報を状態変化が生じたサーバーからネットワークを通
じて得るようにしているが、マスタサーバーからサーバ
ー側に定期的に利用状況の問い合わせを行うようにして
もよいし、サーバーの利用状況に関する情報のみを管理
する他のサーバーから情報を得るようにしてもよい。

【００１４】サーバー選択手段１４は、問合せ受付手段
１１で受け付けたクライアントからの問い合わせに応じ
てサーバー情報保持手段１２のかな漢字変換サーバー利
用状況テーブルを参照し、その時点で最も処理負担の少
ないサーバーを選択して送信手段１５に通知する。例え
ば利用状況をクライアント数で評価した場合には、クラ
イアント数の最も少ないサーバーを選択し、トータルコ
ストで評価した場合には、コストの最も少ないサーバー
を選択する。また、サーバーの単位時間当たりの平均変
換文字数で評価した場合には、最も最近の単位時間にお
ける平均変換文字数が最も少ないサーバーを選択する。

【００１５】送信手段１５は、サーバー選択手段１４で
選択されたサーバー名を、問い合わせのあったクライア
ントに送信する。

【００１６】なお、このマスタサーバー３は通常のサー
バーとしての機能も具えているが、ここでは説明を省略
する。

【００１７】図３は、図１に示したマスタサーバー３を
実現するための具体例を示したものであり、例えばネッ
トワークを利用したかな漢字変換機能を有するワークス
テーションのハードウェア構成を示している。

【００１８】表示装置２１は、ＣＲＴなどのディスプレ
イ画面を具え、画面上にかな漢字変換処理の対象となる
文章などを表示する。表示装置２１での表示は表示装置
制御部２２により制御されている。

【００１９】キーボード２３は、コマンドや文字列など
のデータ入力用の入力装置であり、画面上で指示選択を
行うためのマウス２４が接続されている。キーボード２
３やマウス２４から入力された各種のデータや指示は、
キーボード／マウス制御部２５を通じてプロセッサ部２
９に送られる。

【００２０】ディスク装置２６は、磁気ディスクなどの
２次記憶装置で構成され、かな漢字変換サーバー利用状
況テーブルをファイル形式で格納している。ディスク装
置２６でのデータの入出力はディスク装置制御部２７で
制御されている。ディスク装置２６は、図１のサーバー
情報保持手段１２の機能を実現している。

【００２１】主記憶装置２８は、ＲＡＭなどのメモリ装
置で構成されるバッファ記憶であり、各種プログラムの
ほか、キーボード２３及びマウス２４から入力された各
種のデータや命令などを一時的に記憶する。

【００２２】プロセッサ部２９は、ＣＰＵおよびその周
辺回路により構成される中央処理装置であり、制御プロ
グラムに従って上記各部の動作を管理し、また所定のデ
ータに対する演算処理などを実行する。プロセッサ部２
９は、図１の情報更新手段１３およびサーバー選択手段
１４の機能を実現している。

【００２３】また、このワークステーションは図示せぬ
通信制御部を通じてネットワークに接続されている。通
信制御部は、図１の問合せ受付手段１１および送信手段
１５の機能を実現している。

【００２４】次に、図２のネットワークシステムにおい
て、クライアントがネットワークを利用してかな漢字変
換を行う場合の基本的な動作について説明する。

【００２５】図４は、クライアントがサーバーへ接続す
る際の手順を示すフローチャートである。まず、クライ
アントはかな漢字変換サービスを提供するサーバーに接
続するために、これからかな漢字変換を始める旨の要求
をネットワークに対してブロードキャストを行う（ステ
ップ１０１、１０２）。この時、クライアントはサーバ
ー名を知っている必要はない。ブロードキャストを受け
取ったたマスタサーバーは、かな漢字変換サーバー利用
状況テーブルを調べ、その時点で最も処理負担の少ない
サーバーを選択し、その名をブロードキャストしたクラ
イアントに返す（ステップ１０３）。サーバー名を返さ
れたクライアントは、その名前のサーバーに接続する
（ステップ１０４、１０５）。

【００２６】図５は、クライアントがマスタサーバーか
ら通知されたサーバーに接続した際と、接続終了した際
の手順を示すフローチャートである。ここでは、サーバ
ーに接続するクライアント数の変化をサーバーの状態変
化とする。サーバーは接続開始（または終了）要求を受
けたとき、すなわち自身に接続するクライアント数に変
化が生じたときは、マスタサーバーに対してブロードキ
ャストを行い、クライアント数の変更を通知する（ステ
ップ２０１、２０２）。ブロードキャストを受け取った
たマスタサーバーは、かな漢字変換サーバー利用状況テ
ーブルのクライアント数を更新する（ステップ２０３、
２０４）。

【００２７】図６は、サーバーがブートアップされた際
の手順を示すフローチャートである。ブートアップと
は、サーバーがダウンした状態から復帰した状態、ある
いは立ち上がった状態をいう。サーバーは自身がブート
アップした際に、ネットワークに対してブロードキャス
トを行う（ステップ３０１、３０２）。ブロードキャス
トを受け取ったマスタサーバーは、かな漢字変換サーバ
ー利用状況テーブルにブートアップされたサーバーに関
する情報を登録する（ステップ３０３、３０４）。 次
に、上記図４〜図６の処理を実施する際のマスタサーバ
ーの処理手順を図１を参照しながら、図７のフローチャ
ートにより説明する。

【００２８】問合わせ受付手段１１は、クライアントま
たはサーバーからのパケットを監視し（ステップ４０
１）、パケットを受信したときは、それがクライアント
からのかな漢字変換要求かどうかを判断する（ステップ
４０２）。パケットがかな漢字変換要求であるならば、
サーバー選択手段１４はサーバー情報保持手段１２のか
な漢字変換サーバー利用状況テーブルを調べ、その時点
で最も処理負担の少ないサーバーを選択する（ステップ
４０３）。送信手段１５は、サーバー選択手段１４で選
択されたサーバー名を問い合わせのあったクライアント
に通知する（ステップ４０４）。ステップ４０２でかな
漢字変換要求でないときは、サーバーからのクライアン
ト数の変更通知かどうかを判断する（ステップ４０
５）。クライアント数の変更通知であるならば、情報更
新手段１３はかな漢字変換サーバー利用状況テーブルを
調べ、該当するサーバーのクライアント数を更新する
（ステップ４０６）。ステップ４０５でクライアント数
の変更通知でないときは、サーバーからのブートアップ
の通知かどうかを判断する（ステップ４０７）。ブート
アップの通知でなければ対応するその他の処理を行う
（ステップ４０８）。また、ブートアップの通知である
ならば、情報更新手段１３はかな漢字変換サーバー利用
状況テーブルにブートアップされたサーバーに関する情
報を登録する（ステップ４０９）。

【００２９】次に、かな漢字変換サーバー利用状況テー
ブルの具体例を挙げて、テーブル情報の更新やサーバー
の選択に方法について説明する。

【００３０】図８〜図１１は、かな漢字変換サーバー利
用状況テーブルの構成例であり、サーバーの利用状況を
クライアント数で評価した例を示している。今、図８の
状態でクライアントからサーバーの問合わせがあった場
合、マスタサーバーでは最も処理負担の少ないサーバー
として、クライアント数の最も少ないサーバーであるKs
erver2を選択し、サーバー名を問合わせのあったクライ
アントに通知する。サーバー名を返されたクライアント
が該当のサーバーに接続すると、クライアントの接続し
たサーバーからマスタサーバーに対してクライアント数
の変更が通知される。マスタサーバーは、図９に示すよ
うに該当するサーバーのクライアント数を更新する。図
９は、Kserver2に新たにクライアントが追加され、クラ
イアント数が１つ増えた状態を示している。

【００３１】図８の状態でクライアントからKserver1に
操作終了が通知されると、Kserver1からマスタサーバー
に対してクライアント数の変更が通知される。マスタサ
ーバーは、図１０に示すように該当するサーバーのクラ
イアント数を更新する。図１０は、図８の状態からKser
ver1に接続していたクライアントが操作を終了し、クラ
イアント数が１つ減った状態を表している。

【００３２】図８の状態からKserver4がブートアップさ
れた場合、マスタサーバーは、図１１に示すように該当
するサーバーの項目を新たに設定する。ブートアップ直
後ではクライアント数は０となる。

【００３３】上述した実施例では、サーバーの利用状況
をクライアント数で評価したが、ＣＰＵコスト（処理速
度）、ＣＰＵパワー、ＣＰＵ利用率などで評価すること
もできる。

【００３４】図１２〜図１５は、かな漢字変換サーバー
利用状況テーブルの他の構成例であり、サーバーの利用
状況をＣＰＵコストとクライアント数の積であるトータ
ルコストで評価した例を示している。マスタサーバーは
ＣＰＵコストとクライアント数を管理し、そのコストの
積に基づいて最も処理負荷の少ないサーバーを選択す
る。ＣＰＵコストは数値が少ないほど処理速度が高いこ
とを示している。したがって、トータルコストの少ない
サーバーが最も処理負荷の少ないサーバーとなる。
今、図１２の状態でクライアントからサーバーの問合わ
せがあった場合、マスタサーバーでは最も処理負担の少
ないサーバーとして、トータルコストの最も少ないサー
バーであるKserver2を選択し、サーバー名を問合わせの
あったクライアントに通知する。サーバー名を返された
クライアントが該当のサーバーに接続すると、クライア
ントの接続したサーバーからマスタサーバーに対してク
ライアント数の変更が通知される。マスタサーバーは、
図１３に示すように該当するサーバーのクライアント数
とトータルコストを更新する。図１３は、Kserver2に新
たにクライアントが追加され、トータルコストが２４か
ら３２に更新された状態を示している。

【００３５】図１２の状態でクライアントからKserver1
に操作終了が通知されると、Kserver1からマスタサーバ
ーに対してクライアント数の変更が通知される。マスタ
サーバーは、図１４に示すように該当するサーバーのク
ライアント数とトータルコストを更新する。図１４は、
図１２の状態からKserver1に接続していた１つのクライ
アントが操作を終了し、トータルコストが２７から２４
に更新された状態を表している。

【００３６】図１２の状態からKserver4がブートアップ
された場合、マスタサーバーは図１５に示すように、Ks
erver4の項目を新たに設定する。Kserver4はＣＰＵコス
ト６を持つが、クライアント数が０であるためトータル
コストも０となっている。この状態で次にクライアント
から問合わせがあった場合は、トータルコストの最も少
ないKserver4が選択されることになる。

【００３７】上述した実施例では、いずれもブートアッ
プされた直後はクライアント数を０としているが、新し
いサーバーがブートアップされた時点で、マスタサーバ
ーによりクライアントの処理負荷の均衡を保つためのス
ケジューリングを行うようにしてもよい。例えば図１５
の状態で、最もトータルコストの大きなKserver2からク
ライアント数「２」、次にトータルコストの大きなKser
ver3からクライアント数「１」をとり、図１６に示すよ
うにKserver4にクライアント数「３」を割り当てる操作
を行う。図１６は、Kserver4がブートアップ直後にスケ
ジューリングされた状態を表している。このようなスケ
ジューリングを行うことにより、サーバーの処理負荷が
分散されるため、ネットワークの負担低減や処理速度の
向上を図ることが可能となる。なお、クライアントの割
り当てにより、接続するサーバーが変更されたクライア
ントに対しては、かな漢字変換処理の合間にサーバーの
接続変更を促すようにする。

【００３８】さらに、他の実施例としてサーバーの利用
状況をサーバーの単位時間当たりの平均変換文字数で評
価した例について説明する。各サーバーはそれぞれ単位
時間辺りの平均変換文字数の記録を定期的にマスタサー
バーに通知し、現状のかな漢字変換にかかる付加を逐次
報告する。図１７は各単位時間当たりの平均変換文字数
を記録したかな漢字変換サーバー利用状況テーブルの構
成例を表している。右から、順に１分前（ｔ）、２分前
から１分間（ｔ−１）、３分前から１分間（ｔ−３）、
４分前から１分間（ｔ−４）のそれぞれにおける平均変
換文字数を示しており、これらの値は定期的に逐次更新
されていく。新たにクライアントがサーバーに接続する
際は、一番新しい単位時間当たりの平均変換文字数の少
ないサーバーが選択される。例えば図１７の状態におい
て、新たにクライアントから接続要求が来たときは、最
も最近の単位時間であるｔでの平均変換文字数が最も少
ないKserver2に接続することになる。なお、図１７では
時間ｔから時間ｔ−３における平均変換文字数を記録し
ているが、実際には最も最近の単位時間であるｔでの平
均変換文字数がわかれば、処理負担の少ないサーバーを
判定することは可能である。

【００３９】このように、サーバーの利用状況を評価す
る方法としては、クライアント数やトータルコストなど
幾つかの条件が考えられるが、これらは単独で実施して
もよいし、例えばクライアント数と単位時間当たりの平
均変換文字数というように、複数の条件を組み合わせて
判断してもよい。

【００４０】

【発明の効果】以上説明したように、この発明に係わる
サーバー選択装置においては、ネットワークに接続され
たサーバーの利用状況に関する情報を管理し、クライア
ントのかな漢字変換要求に対しては前記サーバーの利用
状況に関する情報を元に、その時点で最も処理負担の少
ないサーバーを選択してクライアントに通知し、またサ
ーバーから状態変化の通知があったときは、該当するサ
ーバーの利用状況に関する情報を適宜更新するようにし
たため、クライアントは常に最適なサーバーへ接続する
ことができるようになり、サーバー名、またはサーバー
の状態を知らなくても、常に安定したかな漢字変換サー
ビスを得ることができる。また、サーバーの処理負荷の
適切な分散が図られるので、全体的な処理効率を向上さ
せることが可能となる。

【図面の簡単な説明】

【図１】マスタサーバーの機能的な構成を示すブロック
図。

【図２】この発明に係わるサーバー選択装置をマスタサ
ーバーとして接続したネットワークシステムの構成図。

【図３】マスタサーバーを実現するための具体例を示す
図。

【図４】クライアントがサーバーへ接続する際の手順を
示すフローチャート。

【図５】クライアントがマスタサーバーから通知された
サーバーに接続（または接続終了）した際の手順を示す
フローチャート。

【図６】サーバーがブートアップされた際の手順を示す
フローチャート。

【図７】マスタサーバーの処理手順を示すフローチャー
ト。

【図８】かな漢字変換サーバー利用状況テーブルの構成
例を示す図。

【図９】図８でクライアントが新たに追加された状態を
示す図。

【図１０】図８でクライアントが操作終了した状態を示
す図。

【図１１】図８でサーバーが新たにブートアップされた
状態を示す図。

【図１２】かな漢字変換サーバー利用状況テーブルの他
の構成例を示す図。

【図１３】図１２でクライアントが新たに追加された状
態を示す図。

【図１４】図１２でクライアントが操作終了した状態を
示す図。

【図１５】図１２でサーバーが新たにブートアップされ
た状態を示す図。

【図１６】図１５でスケジューリングが行われた状態を
示す図。

【図１７】かな漢字変換サーバー利用状況テーブルのさ
らに他の構成例を示す図。

【符号の説明】

１（〜Ｎ）…クライアント、２（〜Ｍ）…サーバー、３
…マスタサーバー、１１…問合わせ受付手段、１２…サ
ーバー情報保持手段、１３…情報更新手段、１４…サー
バー選択手段、１５…送信手段

Claims (1)

【特許請求の範囲】
1. 【請求項１】 ネットワークを通じてクライアントから
   の問い合わせを受け付ける問い合わせ受付手段と、 ネットワーク上に接続されたサーバーの利用状況に関す
   る情報を保持するサーバー情報保持手段と、 前記サーバーの状態変化に応じて、該当するサーバーの
   利用状況に関する情報を更新する情報更新手段と、 クライアントからの問い合わせに応じて前記サーバー情
   報保持手段を参照し、その時点で最も処理負担の少ない
   サーバーを選択するサーバー選択手段と、 前記サーバー選択手段で選択されたサーバー名を、問い
   合わせのあったクライアントに送信する送信手段と、 を具えたことを特徴とするサーバー選択装置。