(57)【要約】  【課題】クライアント・サーバシステムに関し、員数外クライアントに対してより親切なサービスを行うことを可能にした、クライアントの受付方法を提供することを目的とする。【解決手段】  クライアントからの接続の要求を受け付けてサービスを提供するサーバが員数外のクライアントからの接続の要求を受け付けたときに、クライアントからサービスの提供を希望する時間を受け付けてクライアント・サービス予約テーブルに登録し、クライアント・サービス予約テーブルに登録した時間になると、サーバが現在アクセス数と最大アクセス数とから新たなクライアントを接続可能か否かを判断して新たなクライアントを接続可能と判断すると、サーバから、クライアント・サービス予約テーブルを参照して予約を行ったクライアントに接続の要求をするようにした。  【選択図】      図１
2006048712.tif 000002
【特許請求の範囲】
【請求項１】
クライアントからの接続の要求を受け付けてサービスを提供するサーバが員数外のクライアントからの接続の要求を受け付けたときに、クライアントからサービスの提供を希望する時間を受け付けてクライアント・サービス予約テーブルに登録し、
前記クライアント・サービス予約テーブルに登録した時間になると、サーバが現在アクセス数と最大アクセス数とから新たなクライアントを接続可能か否かを判断して新たなクライアントを接続可能と判断すると、サーバから、前記クライアント・サービス予約テーブルを参照して予約を行ったクライアントに接続の要求をすること、
を特徴とするクライアントの受付方法。
【請求項２】
前記サーバが、クライアントから新たな接続の要求を受け付けた際に、前記クライアント・サービス予約テーブルを参照して、接続を受け付けるか否かを判断すること、
を特徴とする請求項１に記載のクライアントの受付方法。
【請求項３】
前記サーバが、予約を行ったクライアントに接続の要求をした時に、該クライアントから他のサーバでのサービスの要求を受け付けると、他のサーバに処理を移行すること、
を特徴とする請求項１乃至請求項２に記載のクライアントの受付方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、クライアント・サーバシステムにおけるクライアントの受付方法に関する。
【０００２】
クライアント・サーバシステムは、異なるハードウェア上にある別々のソフトウェアが連携して一つのアプリケーションプログラムを効率的に実行するようなシステムであり、今日、データベース検索、パソコン通信などにおいてすでに実現されている。
今後は、双方向通信の目玉とも言えるＶＯＤ（ビデオ・オン・デマンド）、テレビショッピング、通信カラオケ等の分野でも幅広く使われていくことが予想される。
これらの利用分野は、いずれも、クライアント（ユーザ）に対して、より便利なサービスを提供するものである。
【背景技術】
【０００３】
一般に、サーバは、システムの性能上の制限により、ある数以上のクライアントからのアクセスを受け付けない。
クライアントからのアクセス数が、サーバの最大アクセス数を越えると、クライアントからアクセスがあっても、電話の話中と同様、アクセスを受け付けない。
サーバは、現在アクセス数が最大アクセス数以下となる員数内クライアントからアクセスがあった場合には所定のサービスを提供するが、現在アクセス数が最大アクセス数を越える員数外クライアントからアクセスがあった場合には、サービス提供もアクセス受付も行わない。
【発明の開示】
【発明が解決しようとする課題】
【０００４】
上記従来技術では、現在アクセス数が最大アクセス数に達すると、サーバは、それ以上のクライアント・アクセスを受け付けなくなる。
これは、パソコン通信において、センター（サーバ側）が混んでいると、話中状態になるのと同じ現象である。
このとき、サービスを拒否されたクライアントは、なぜサーバにアクセスできないのか、メンテナンス中でサービスを受け付けていないからなのか、それとも単に混んでいるだけなのか、など相手側のサーバの様子が分からない。
【０００５】
このような従来技術による対応は、サービスの観点から見ると、クライアントにとって非常に不親切であり、クライアントに対するサービス性に欠ける。
電話には、留守番電話や割り込みなどの機能があるように、クライアント・サーバシステムにおいても、たとえサーバがサービスを提供できない状態にあっても、サーバ側の状態をクライアントに伝えたり、クライアントの要求だけでもひとまず聞いておく、等の対応をすべきである。
【０００６】
本発明は、以上の点に鑑み、クライアント・サーバシステムにおいて、最大アクセス数を越える員数外クライアントに対して従来より行われてきたアクセス処理方法を改善し、より親切なサービスを行うことを可能にした、クライアントの受付方法を提供することを目的とする。
【課題を解決するための手段】
【０００７】
本発明によれば、上述の目的は、前記特許請求の範囲に記載した手段にて達成される。
【０００８】
すなわち、請求項１の発明は、いずれかのクライアントからサーバへアクセスがあったとき、まずコネクションを繋ぎ、クライアントが員数内クライアントであるか員数外クライアントであるかを判別し、クライアントが員数内クライアントである場合にはサービスを提供し、クライアントが員数外クライアントである場合には所定の応答を返すサービス前処理を行うクライアントの受付方法である。
【０００９】
また、請求項２の発明は、前記サービス前処理を行った後、時間をおいてからそのクライアントへサービスを提供するクライアントの受付方法である。
【００１０】
また、請求項３の発明は、クライアントからのアクセスを登録するクライアント・アクセス受付テーブルを設けると共に、このテーブルに少なくとも、サービス前処理中を示すフラグを設けるクライアントの受付方法である。
【００１１】
また、請求項４の発明は、サービス予約を表示するクライアントからサーバへアクセスがあったとき、まずコネクションを繋いで、所定の応答を返すサービス前処理を行った後、予約時間が来るのを待って予約されたサービスを提供するクライアントの受付方法である。
【発明の効果】
【００１２】
請求項１の発明では、員数外クライアントからアクセスがあった場合にも、サーバはまずコネクションを繋ぐ。
この時、サーバは員数外クライアントへのサービス提供ができないので、サービス前処理中となって所定の応答を返す。
その応答で、サーバはサービスを提供できない理由を示すことができる。
【００１３】
請求項２の発明では、サーバはサービス前処理中に移行した後、時間をおいて他のクライアントへのサービスが終了してから、サービス提供が可能な時に先のクライアントへサービスを提供する。
所定の応答には、サービス提供を一定時間遅らせるといった情報を含めることができる。
【００１４】
請求項３の発明では、員数内クライアント又は員数外クライアントからアクセスがあった場合は、そのクライアントをクライアント・アクセス受付テーブルに登録する。
そして、員数外クライアントに対してサービス前処理を行うと、サービス前処理を表示するフラグがオンに変わる。
【００１５】
請求項４の発明では、員数内クライアント又は員数外クライアントがサーバに対して予約を請求する。
サーバは、予約を受け付けるとサービス前処理に移行する。
その後、予約時間が来ると、サーバは、員数内クライアント又は員数外クライアントに対してサービスの提供を開始する。
【実施例１】
【００１６】
図１の実施例では、現在アクセス数が最大アクセス数を越えている場合にも、クライアントに対してアクションを起こす。
具体的には、最大アクセス数を越えてアクセスしてきた員数外クライアントに対しても、ひとまずセッションを受け付け、その後で員数外クライアントに対してはサービス前処理（ビジー通知）を行い、員数内クライアントに対しては、実際のサービス提供を行う。
【００１７】
サービス前処理では、定員いっぱいで実際のサービスは提供できないが、『混雑している』とか『メンテナンス中である』といった現在のサーバの状況をクライアントに通知したりできる。
その他、後述するように、クライアントからの次回のサービス予約や、サーバに対する要望を受け付けることもできる。
また、クライアントがサービス前処理中か、サービス提供中かを見分けるために、フラグを設けることも可能である。
【００１８】
処理の流れは、まず、テーブルや通信を初期化した後、クライアントにサービスを提供するための無限ループに入る。
そして、クライアントから新規アクセスが来ているかどうかを見にいく。
新規アクセスが来ている場合は、員数内クライアント又は員数外クライアントとのコネクションを繋いで、現在アクセス数をインクリメントする。
【００１９】
それから、現在アクセス数が最大アクセス数に達していないかどうかを調べる。
サーバは、現在アクセス数が最大アクセス数に達していなければサービス提供を行うが、最大アクセス数を越えている場合にはサービス前処理としてビジー通知を返す。
その後、サービス終了のメッセージを受け取ると、サーバは、クライアントとのコネクションを切断して、現在アクセス数をデクリメントする。
【実施例２】
【００２０】
図２の実施例では、サーバがクライアントの予約を受け付ける。
図示するように、サーバはクライアントとのコネクションを繋いだ後、クライアントからクライアント情報を取得する。
クライアント情報には、サービス提供を後の時間に行う旨を表示する予約情報を含ませることができる。
予約時間は日時で表現できるが、所定時間後といった表現方法もある。
【００２１】
新規アクセスが無い時、サーバはサービス予約を処理する。
サーバはまず、時間監視によって予約時間が経過していないかどうかを調べる。
そして、予約時間が来たときには、現在アクセス数が最大アクセス数に達していないことを確かめて、予約されたサービスを提供する。
なお、サービス予約がされた場合には、予約時間に合わせて他のクライアントからのアクセスを制限しても良い。
【００２２】
ところで、予約情報は、クライアント・サービス予約テーブルに登録することができる。
図８に、クライアント・サービス予約テーブルの構成例を示す。
図中、クライアント・サービス予約テーブルにおけるユーザ情報の欄は、サービス予約を行ってサービス前処理中にあるユーザを書き込む領域であり、予約情報の欄は、次回サービス日時と提供サービスの内容を書き込む領域である。
【実施例３】
【００２３】
図３〜５に、アクセス・フラグを制御するクライアント・アクセス受付テーブルを用いた実施例を示す。
当実施例では、クライアントからのアクセスを受け付けるルーチン（図３，４）と、クライアントにサービスを提供するルーチン（図５）とを分けて説明する。
アクセスのあったクライアントはクライアント・アクセス受付テーブルに全て登録する。
クライアント・アクセス受付テーブルの構造は、例えば、図７に示される。
【００２４】
図７において、各エントリーには識別番号が付されている。
‘０’から‘最大アクセス数＋α’までの識別番号は、新規アクセスの有無を調べるポーリングで使用される。
アクセス順に詰めて登録する場合、‘最大アクセス数−１’までが員数内クライアントになり、溢れたクライアントが員数外クライアントになる。
図７では、‘α＋１’個の員数外クライアントを登録できる。
【００２５】
クライアント・アクセス受付テーブルのアクセス・フラグ及びクライアント情報、並びに現在アクセス数は、アクセス受付及びサービス提供の両者のルーチンで共通のパラメータとする。
また、当実施例では、他サーバでのサービス提供もサポートするので、クライアント・アクセス受付テーブルにおけるアクセス・フラグを、以下の７種類に分類する。
０：アクセス無し
１：サービス前処理中
２：クライアント認証中
３：クライアント接続待ち
４：サービス提供中
５：他サーバアクセス中
６：サービス終了
図３のクライアント・アクセス受付ルーチンでは、初期処理でアクセス・フラグを‘０’に初期化する。
そして、クライアントからのアクセスが来ると、まず、クライアントとのコネクションを張り、現在アクセス数をインクリメントする。
このとき、現在アクセス数が最大アクセス数に達していない場合は、クライアントに認証受付可能であることを意味するハロー（Ｈｅｌｌｏ）メッセージを送信して、アクセス・フラグを‘２’に制御する。
最大アクセス数に達している場合は、サービス前処理モードになることを意味するビジー（Ｂｕｓｙ）メッセージを送信して、アクセス・フラグを‘１’に変える。
【００２６】
無限ループに戻り新規アクセスが無い場合は、クライアント・アクセス受付テーブルをポーリングし、アクセス・フラグが‘１’又は‘２’のクライアントからのメッセージを受信する。
アクセス・フラグとメッセージから認証モードを判別し、それが終了を意味するなら、終了要求を受け付けたことをクライアントに通知した後、一旦、クライアントとのコネクションを切断する。
ここで、認証処理が正しく終了しているなら、アクセスフラグを‘３’に制御し、そうでない場合は‘０’に戻す。
【００２７】
判別結果が終了でない時は、図４（ａ）に示すような認証モードに従い、サービス前処理、ユーザＩＤ認証、パスワード認証、サービスセットアップ処理、エラーセット処理の各処理を行い、処理結果をクライアントに通知する。
そのサービス前処理においては、図４（ｂ）に示すように、アクセス・フラグが‘１’であればビジー通知を返して、アクセス・フラグが‘２’であればハロー通知を返す。
なお、ビジー通知の後、予約の請求があった場合にはその登録を行う。
【００２８】
図５のサービス提供ルーチンでは、クライアント・アクセス受付テーブルをポーリングして、アクセス・フラグが‘３’であるポイントを見つける。
すると、クライアント・コネクト処理において、テーブル内のクライアント情報に記載された情報をもとにクライアントにコネクションを張りに行き、正しくコネクションが張られたら、アクセスフラグを‘４’に変える。
ここで、クライアントからのサービス要求を受け付け、サービス提供のステージに入る。
【００２９】
クライアントから他サーバにおけるサービスを要求された場合は、アクセス・フラグを‘５’に変えて、他サーバに処理を移行する。
クライアントからの要求が終了要求の場合は、アクセス・フラグを‘６’に変えて、サービス終了処理を行う。
サービス終了処理が終わると、アクセスフラグを‘０’に戻して、現在アクセス数から‘１’を減算する。
【実施例４】
【００３０】
図６に、クライアント・サーバシステムの構成例を示す。
図６において、クライアント・アクセス受付部６１は、クライアント９０〜９５からサーバ６０へのアクセスを受け付けるものである。
クライアントの情報は、クライアント・アクセス受付テーブル６７又は員数外クライアント・アクセス受付テーブル６８に登録される。
その際には、現在アクセス数カウンタ６９が制御される。
【００３１】
サービス前処理部６２は、クライアント・アクセスの受付処理を行うルーチンを持つが、クライアントからサービス予約があった場合には、サービス予約部６４によって、その予約情報をクライアント・サービス予約テーブル６５に登録する。
予約時間は、時計６６によって監視される。
【００３２】
サービス提供部６３は、クライアント９０〜９５へのサービス提供を行うルーチンを持つ。
サービス提供部６３は、全てのクライアントに対して同時にサービスを行う能力を持たないので、現在アクセス数が最大アクセス数を越えた場合には、サービスの提供開始を遅らせたり、サービスの予約をさせたりする。
なお、サービス予約部６４は、サービス提供部６３が行う個々のサービスについて、開始時刻を調整することができる。
【００３３】
以上説明したように、本発明では、員数内クライアントからのアクセスも員数外クライアントからのアクセスも受け付け、サーバがサービスできない状況にあっても、サーバとクライアントとの情報伝達を可能にする。
また、予約を受け付けることによって、アクセスを行う全てのクライアントに対して、サービス提供を可能にする。
【図面の簡単な説明】
【００３４】
【図１】本発明の第一実施例を示す図である。
【図２】本発明の第二実施例を示す図である。
【図３】クライアント・アクセス受付プロセスの実施例を示す図である。
【図４】認証処理の説明図である。
【図５】サービス提供プロセスの実施例を示す図である。
【図６】クライアント・サーバシステムの構成例を示す図である。
【図７】クライアント・アクセス受付テーブルの構成例を示す図である。
【図８】クライアント・サービス予約テーブルの構成例を示す図である。
【符号の説明】
【００３５】
６０  サーバ
６１  クライアント・アクセス受付部
６２  サービス前処理部
６３  サービス提供部
６４  サービス予約部
６５  クライアント・サービス予約テーブル
６６  時計
６７  クライアント・アクセス受付テーブル
６８  クライアント・アクセス受付テーブル
６９  現在アクセス数カウンタ
９０〜９５  クライアント
【図１】
2006048712.tif 000003
【図２】
2006048712.tif 000004
【図３】
2006048712.tif 000005
【図４】
2006048712.tif 000006
【図５】
2006048712.tif 000007
【図６】
2006048712.tif 000008
【図７】
2006048712.tif 000009
【図８】
2006048712.tif 000010