クラアイントサーバシステムにおけるサーバ負荷軽減方法
【課題】クライアントサーバシステム形態のネットワークおいて，クライアントの数を増やしてもサーバの負担を極力あげることなく，サーバからクライアントへのレスポンスも良いクライアントサーバシステムを提供する。
【解決手段】クライアントからのアクセスを受信する手段と，クライアント毎に管理され，それぞれの当該クライアントに通知すべき通知情報を管理する手段と，「所定の内容を当該通知情報の対象となるクライアントへ送信せよ」との依頼内容を，受信した前記アクセスの応答として送信元クライアントに向けて送信する応答手段と，を備えるサーバを含むクライアントサーバシステム。
【解決手段】クライアントからのアクセスを受信する手段と，クライアント毎に管理され，それぞれの当該クライアントに通知すべき通知情報を管理する手段と，「所定の内容を当該通知情報の対象となるクライアントへ送信せよ」との依頼内容を，受信した前記アクセスの応答として送信元クライアントに向けて送信する応答手段と，を備えるサーバを含むクライアントサーバシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本願発明はクライアントサーバ形態のネットワークシステムに関するものであり，特にサーバの負荷を軽減するものに関するものである。
【背景技術】
【０００２】
一般に，クライアントサーバシステムでは，クライアントの数が多くなるとサーバの負担が増す。例として，図１に示すようなネットワーク環境で，クライアント１０１〜クライアント１０３が所定時間ごとにサーバ１０４にアクセス（ポーリング）し，自身に対するイベントがあるかないかを確認する状況を想定する。
【０００３】
図２に示すシーケンスは，ポーリング間隔を１０ｓ（１０秒）とした場合のものである。図示するように，クライアント１０１がサーバ１０４に最初にポーリング（通信１１１および通信１２１）を行ってから，次のポーリング（通信１１２および通信１２２）を行うまでの時間間隔が１０ｓとなっている。これは他のクライアントにおいても同様である。図では，サーバ１０４にて発生したクライアント１０２に対するイベントを，クライアント１０２が検知するまでの様子を示している。
【０００４】
このように，図２にて例示するクライアントサーバシステムでは，サーバ１０４にて，あるクライアントに対してイベントが発生していた場合，そのクライアントが当該イベントを検知できるまで最大１０ｓ必要となる。つまり，ポーリング間隔の長さに比例して，イベントを検知するまでの平均時間も長くなるわけである。
【０００５】
ところで，クライアントサーバシステムにおいて，１台のサーバが管理するクライアントの数は多ければ多いほど良いのは言うまでもない。しかし，上記のシステムにおいてクライアントの数を増やすと，それに応じて単位時間当たりのポーリング回数が増え，サーバには大きな負担となる。
【０００６】
これを改善する最も簡単な方法は，クライアントのポーリング間隔を大きくすることである。例えば上述した１０ｓではなく３０ｓなどとするわけである。当然，ポーリング間隔が３倍に増えると，１０ｓの場合と同じサーバの負担で，理論上は３倍の数のクライアント数を管理することが可能になる。つまり，ポーリング間隔を大きくすると，理論上は無限ともいえるクライアントを管理することが可能になる。クライアント数に応じて，ポーリング間隔を大きく取ればよいだけだからである。
【０００７】
しかしこれには次のような問題がある。例えば，ポーリング間隔を３６００ｓ(１時間)に設定すると，サーバ内で発生したクライアント向けのイベントを当該クライアントが検知できるまで最大３６００ｓかかるということになる。つまり，クライアントへのレスポンスがそれだけ遅くなるわけである。特に，緊急性の高いイベントが発生していた場合には大きな問題となる。
【０００８】
このような問題を改善する発明が特許文献１に開示されている。これは，サーバを介してクライアント同士が通信する場合において，サーバが管理すべき情報とそうでない情報とを分類し，サーバが管理すべき情報はサーバを介して通信し，そうでない情報は，クライアント同士で直接通信するというものである。これによりサーバの負担を軽減しつつ，サーバを介したクライアント同士の通信をレスポンスよく行うことが可能になる。
【０００９】
しかし，特許文献１に開示の発明は，サーバが管理しなくてもよい情報，即ち一般的には重要度の低い情報が存在する場合を前提としている。このため，サーバが管理すべき情報（重要度が高い情報）が多くを占めるようなシステムの場合には，当然にサーバへの通信が多くなり，従来からの課題と同様，サーバへの負担が重くなる。
【先行技術文献】
【特許文献】
【００１０】
【特許文献１】国際公開第ＷＯ０１／０５７５７８号パンフレット
【発明の概要】
【発明が解決しようとする課題】
【００１１】
本願発明はこのような問題を解決するものである。すなわち，クライアントサーバシステム形態のネットワークおいて，クライアントの数を増やしてもサーバの負担を極力あげることなく，サーバからクライアントへのレスポンスも良いクライアントサーバシステムを提供することである。
【課題を解決するための手段】
【００１２】
本願発明にかかる第１の形態は，サーバと複数のクライアントとがネットワーク接続されており，クライアントは所定の時間間隔にて当該サーバへのアクセスを行うクライアントサーバシステムにおける当該サーバであって，クライアントからのアクセスを受信する手段と，クライアント毎に管理され，それぞれの当該クライアントに通知すべき通知情報を管理する手段と，「所定の内容を当該通知情報の対象となるクライアントへ送信せよ」との内容を含む依頼を，受信したアクセスの応答として送信元クライアントに向けて送信する応答手段と，を備えるサーバである。
【００１３】
好ましくは，所定の内容は「通知情報の対象となるクライアントが，サーバにアクセスし，通知情報を取得する」という動作のトリガである。
【００１４】
本願発明にかかる第２の形態は，サーバと複数のクライアントとがネットワーク接続されており，クライアントは所定の時間間隔にて当該サーバへのアクセスを行うクライアントサーバシステムにおける当該サーバであって，クライアントからのアクセスを受信する手段と，クライアント毎に管理され，それぞれの当該クライアントに通知すべき通知情報を管理する手段と，通知情報の数が複数の場合，所定の条件に基づき通知情報の順位を決定し，受信したアクセスに対する応答として，当該順位の最上位から所定数の通知情報に関し，受信したアクセスの応答として「所定の内容を当該通知情報の対象となるクライアントへ送信せよ」との内容を含む依頼を送信元クライアントに向けて送信する応答手段と，を備えるサーバである。
【００１５】
好ましくは，所定の条件は「通知情報の対象となるクライアントにとっての優先度」および／または「サーバにおける通知情報の未処理時間」である。
【００１６】
好ましくは，所定の内容は「通知情報の対象となるクライアントが，サーバにアクセスし，通知情報を取得する」という動作のトリガである。
【００１７】
本願発明にかかる第３の形態は，サーバと複数のクライアントとがネットワーク接続されており，クライアントは所定の時間間隔にて当該サーバへのアクセスを行うクライアントサーバシステムであって，サーバは，所定のクライアントからのアクセスを受信する手段と，クライアント毎に管理され，それぞれの当該クライアントに通知すべき通知情報を管理する手段と，「所定の内容を当該通知情報の対象となるクライアントへ送信せよ」との依頼内容を，受信したアクセスの応答として送信元クライアントに向けて送信する応答手段と，を備えるクライアントサーバシステムである。
【００１８】
本願発明にかかる第４の形態は，サーバと複数のクライアントとがネットワーク接続されており，クライアントは所定の時間間隔にて当該サーバへのアクセスを行うクライアントサーバシステムあって，サーバは，クライアントからのアクセスを受信する手段と，クライアント毎に管理され，それぞれの当該クライアントに通知すべき通知情報を管理する手段と，通知情報の数が複数の場合，所定の条件に基づき通知情報の順位を決定し，受信したアクセスに対する応答として，当該順位の最上位から所定数の通知情報に関し，受信したアクセスの応答として「所定の内容を当該通知情報の対象となるクライアントへ送信せよ」との内容を含む依頼を送信元クライアントに向けて送信する応答手段と，を備えるクライアントサーバシステムである。
【００１９】
本願発明にかかる第５の形態は，サーバと複数のクライアントとがネットワーク接続されており，クライアントは所定の時間間隔にて当該サーバへのアクセスを行うクライアントサーバシステムにおける当該サーバを，クライアントからのアクセスを受信する手段と，クライアント毎に管理され，それぞれの当該クライアントに通知すべき通知情報を管理する手段と，「所定の内容を当該通知情報の対象となるクライアントへ送信せよ」との依頼内容が含まれた応答を，受信したアクセスの応答として送信元クライアントに向けて送信する応答手段と，して機能させるプログラムである。
【００２０】
好ましくは，所定の内容は「通知情報の対象となるクライアントが，サーバにアクセスし，通知情報を取得する」という動作のトリガである。
【００２１】
本願発明にかかる第６の形態は，サーバと複数のクライアントとがネットワーク接続されており，クライアントは所定の時間間隔にて当該サーバへのアクセスを行うクライアントサーバシステムにおける当該サーバを，クライアントからのアクセスを受信する手段と，クライアント毎に管理され，それぞれの当該クライアントに通知すべき通知情報を管理する手段と，通知情報の数が複数の場合，所定の条件に基づき通知情報の順位を決定し，受信したアクセスに対する応答として，当該順位の最上位から所定数の通知情報に関し，受信したアクセスの応答として「所定の内容を当該通知情報の対象となるクライアントへ送信せよ」との内容を含む依頼を送信元クライアントに向けて送信する応答手段と，して機能させるプログラムである。
【００２２】
好ましくは，所定の条件は「通知情報の対象となるクライアントにとっての優先度」および／または「サーバにおける通知情報の未処理時間」である。
【００２３】
好ましくは，所定の内容は「通知情報の対象となるクライアントが，サーバにアクセスし，通知情報を取得する」という動作のトリガである。
【発明の効果】
【００２４】
本願発明の第１の形態によれば，サーバで発生した特定クライアント向けのイベント発生通知依頼を，他のクライアントのポーリング応答に含めることで，サーバへの負担を軽減するためクライアントの数を増やしポーリング間隔を大きくしたとしても，当該特定のクライアントは自身に対するイベント発生を遅滞なく検知することができる。さらに，イベント発生通知を受信した当該特定クライアント自身が，この受信をトリガとして，サーバにアクセスを行い自身に対して発生したイベントの内容を取得することで，重要度が高いものや，秘匿性を有するようなイベントであっても，良好なレスポンスを維持しつつ内容を取得することができる。
【００２５】
さらに本願発明の第２の形態によれば，サーバから送信されるイベント発生通知依頼は，イベントの重要度およびイベントの未処理時間に基づいて送信順序が決定されるため，クライアントの数が増加し，イベントが多数発生したとしても，効率よくクライアントに通知することができる。
【００２６】
また，その他の形態によれば，イベントの未処理時間に応じて優先度を変化させることで，優先度の低いイベントが長期間にわたって通知されないという問題を回避することができる。
【００２７】
また，その他の形態によれば，ポーリングしてきたクライアントに通知するイベント数を，当該クライアントの処理能力等に応じて変化させることで，イベントが発生しているクライアントへのイベント発生通知を，より効率的に行うことができる。
【発明を実施するための形態】
【００２８】
以下では図面を参照し本願発明に係る実施例を説明する。
［実施例１］
【００２９】
図３は本実施例にかかるシーケンス図である。図示するように本実施例ではポーリング間隔を３０ｓにしている。図２の説明では１０ｓであったが，これよりも長い間隔としている。こうすることで，クライアントの数を３倍に増やしても，理論上，サーバへの負担は図２の場合と同じである。
【００３０】
本願発明では，ポーリング間隔を長くしたことによる，サーバからクライアントへのレスポンス低下を防ぐため，任意のクライアント（必ずしもそのクライアントにイベントが発生している必要はない）からのポーリングに対する応答の中に，イベントが発生したクライアントに向けたイベント発生通知の依頼を含めている。この応答を受信したクライアントは，イベントが発生しているクライアントに対してイベント発生通知をする。こうすることで，当該イベントが発生しているクライアントは，自身のポーリング間隔に関係なく，他のクライアントからイベント発生通知を受信しイベントの発生を検知することができる。すなわち，イベントが発生しているクライアントにとって，他のクライアントから送信されたイベント発生通知の受信は，サーバにアクセスし当該イベントの内容を取得するためのトリガとなっている。
【００３１】
図３は，クライアント１０２へのイベントがサーバ１０４にて発生した場合を図示している。図からわかるように，クライアント１０２は，自身のポーリング時間の到来を待たずしてイベント発生を検知できる。結果として，クライアント１０２がイベントを検知するまでの平均時間を，ポーリング間隔よりも大幅に短くすることが可能である。
［ブロック図］
【００３２】
図４は本実施例にかかるサーバ１０４のブロック図である。
【００３３】
イベント管理手段４０４は，クライアントに対するイベントが発生すると，これをイベント保存領域４０６に登録する。
【００３４】
アクセス受信手段４０２は，ネットワークインタフェース４０１を介してクライアントからのポーリングを受信する手段である。
【００３５】
イベント存否判断手段４０３は，クライアントからのアクセスがあると，当該クライアント以外のクライアントに対するイベントが存在するかどうかを，イベント保存領域４０６を参照して判断する。判断の結果，イベントが存在していれば，後述する応答手段４０５にその旨通知する。
【００３６】
応答手段４０５は，アクセス受信手段４０２が受信したクライアントからのポーリングに対して応答するものであるが，応答の際，前述のイベント存否判断手段４０３からの通知を受信していれば，イベント保存領域４０６からイベント情報を読み出し，その情報とともにクライアントに応答する。イベントが複数ある場合はすべてを読み出して応答する。
［サーバの動作フロー］
【００３７】
図５はサーバ１０４の動作フローである。
【００３８】
ステップ５０１にて，クライアントからのアクセスがあるかどうかを判断する。判断の結果，アクセスがあれば，次のステップに進み，そうでなければ受信判断を繰り返す。
【００３９】
ステップ５０２にて，イベントがあるかどうかを，イベント保存領域４０６を参照して判断する。判断の結果，存在すれば，次のステップに進み，そうでなければ受信判断に戻る。
【００４０】
ステップ５０３にて，イベント保存領域４０６から，イベントを読み出し，これをステップ５０１にて受信したアクセスに対する応答内容に含めて応答する。
［実施例２］
【００４１】
すでに述べたように，クライアントのポーリング間隔を大きくすることで，サーバ１０４の負担を高めることなくクライアントの数を増やすことができる。しかし，クライアント数を増やせば，それに応じてイベント発生数も多くなる。
【００４２】
発生したすべてのイベントを，ポーリングしてきたクライアントに一時に通知すると，当該クライアントにとっては大きな負担となる。そこで，本実施例では，サーバ１０４が，クライアントに通知するイベントの順位付けを行い，ポーリングしてきた１つのクライアントに対して上位から順に１件ずつ通知することで，クライアントの負荷を軽減しつつ，効率的なイベント通知を行う。
【００４３】
上述した動作を示したのが図６である。これは，サーバ１０４がイベント保存領域４０６にて管理するイベントのリストである。図示するとおり，各イベントには，通知対象となるクライアント名，イベント優先度，および未処理時間の属性が与えられる。
【００４４】
イベント優先度は，クライアントにとっての緊急度や重要度を意味し，優先度が高いほど即時処理を期待されるものである。優先度はイベントの種類に対応した所定のもの（図では優先度が高い順にＳ，Ａ，Ｂ，Ｃ）が予め定められている。一方，未処理時間は，イベントがサーバ１０４で発生してからの経過時間である。一般には，未処理時間が長いものほど，即時処理が求められると考えられる。
【００４５】
サーバ１０４のイベント管理手段４０４は，発生したイベントをイベント保存領域４０６に登録する際，イベント優先度を第１キーとして登録する。次いで，同じイベント優先度の中での順位は，未処理時間の長いものほど上位になるようにソートして登録する。
【００４６】
クライアントからのポーリングを受信すると，１件のポーリングに対し１件ずつイベントを上位から通知する。これにより，最も重要度・緊急度が高いと推測されるイベント順に，対象となるクライアントに通知することができる。
［ブロック図］
【００４７】
図７は実施例２におけるサーバ１０４のブロック図である。図示するように，イベント管理手段４０４には，優先度および未処理時間をキーとしてイベントをソートする手段であるイベントソート手段７０１が備えられている。残りの手段は実施例１と同じであるため説明を省略する。
【００４８】
図８は実施例２におけるサーバ１０４の動作フローである。図示するように，イベント管理タスクのステップ８０２にて，発生したイベントを優先度・未処理時間順にソートして，イベント保存領域４０６に登録する。
【００４９】
次いで，メインタスクのステップ８０３にて，イベント保存領域４０６に保存されているイベントを，最上位から順にポーリングしてきたクライアントに通知する。
［その他の実施例］
実施例２では，イベントを，優先度および未処理時間にて管理したが，この未処理時間が所定の閾値を超えると，優先度を上げるというようにしてもよい。例えば，優先度Ａのイベントの未処理時間が１００ｓを超えると，優先度Ｓに変えるなどである。この場合，未処理時間をいったん０（ゼロ）にリセットすることが望ましい。
【００５０】
実施例２では，サーバ１０４にて発生したイベントをポーリングしてきたクライアントに１件ずつ通知したが，クライアントの処理能力等を考慮し，優先度が高いものから順に，数件のイベントをまとめて通知することもできる。例えば，クライアントの処理能力が高い場合は，複数のイベントを通知することができる。
［まとめ］
【００５１】
本願発明の第１の形態によれば，サーバで発生した特定クライアント向けのイベント発生通知依頼を，他のクライアントのポーリング応答に含めることで，サーバへの負担を軽減するためクライアントの数を増やし，ポーリング間隔を大きくしたとしても，当該特定のクライアントは自身に対するイベント発生を遅滞なく検知することができる。さらに，イベント発生通知を受信した当該特定クライアント自身が，この受信をトリガとして，サーバにアクセスを行い自身に対して発生したイベントの内容を取得することで，重要度が高いものや，秘匿性を有するようなイベントであっても，良好なレスポンスを維持しつつ内容を取得することができる。
【００５２】
さらに本願発明の第２の形態によれば，サーバから送信されるイベント発生通知依頼は，イベントの重要度およびサーバによるイベントの未処理時間に基づいて送信順序が決定されるため，クライアントの数が増加し，イベントが多数発生したとしても，効率よくクライアントに通知することができる。
【００５３】
また，その他の形態によれば，イベントの未処理時間に応じて優先度を変化させることで，優先度の低いイベントが長期間にわたって通知されないという問題を回避することができる。
【００５４】
また，その他の形態によれば，ポーリングしてきたクライアントに通知するイベント数を，当該クライアントの処理能力等に応じて変化させることで，イベントが発生しているクライアントへのイベント発生通知を，より効率的に行うことができる。
【図面の簡単な説明】
【００５５】
【図１】システム全体図
【図２】従来技術のシーケンス図
【図３】実施例１ シーケンス図
【図４】実施例１ サーバのブロック図
【図５】実施例１ サーバの動作フロー
【図６】実施例２ サーバ側でのイベント通知依頼送信順序
【図７】実施例２ サーバのブロック図
【図８】実施例２ サーバの動作フロー
【符号の説明】
【００５６】
４０２ アクセス受信手段
４０４ イベント管理手段
４０５ 応答手段
【技術分野】
【０００１】
本願発明はクライアントサーバ形態のネットワークシステムに関するものであり，特にサーバの負荷を軽減するものに関するものである。
【背景技術】
【０００２】
一般に，クライアントサーバシステムでは，クライアントの数が多くなるとサーバの負担が増す。例として，図１に示すようなネットワーク環境で，クライアント１０１〜クライアント１０３が所定時間ごとにサーバ１０４にアクセス（ポーリング）し，自身に対するイベントがあるかないかを確認する状況を想定する。
【０００３】
図２に示すシーケンスは，ポーリング間隔を１０ｓ（１０秒）とした場合のものである。図示するように，クライアント１０１がサーバ１０４に最初にポーリング（通信１１１および通信１２１）を行ってから，次のポーリング（通信１１２および通信１２２）を行うまでの時間間隔が１０ｓとなっている。これは他のクライアントにおいても同様である。図では，サーバ１０４にて発生したクライアント１０２に対するイベントを，クライアント１０２が検知するまでの様子を示している。
【０００４】
このように，図２にて例示するクライアントサーバシステムでは，サーバ１０４にて，あるクライアントに対してイベントが発生していた場合，そのクライアントが当該イベントを検知できるまで最大１０ｓ必要となる。つまり，ポーリング間隔の長さに比例して，イベントを検知するまでの平均時間も長くなるわけである。
【０００５】
ところで，クライアントサーバシステムにおいて，１台のサーバが管理するクライアントの数は多ければ多いほど良いのは言うまでもない。しかし，上記のシステムにおいてクライアントの数を増やすと，それに応じて単位時間当たりのポーリング回数が増え，サーバには大きな負担となる。
【０００６】
これを改善する最も簡単な方法は，クライアントのポーリング間隔を大きくすることである。例えば上述した１０ｓではなく３０ｓなどとするわけである。当然，ポーリング間隔が３倍に増えると，１０ｓの場合と同じサーバの負担で，理論上は３倍の数のクライアント数を管理することが可能になる。つまり，ポーリング間隔を大きくすると，理論上は無限ともいえるクライアントを管理することが可能になる。クライアント数に応じて，ポーリング間隔を大きく取ればよいだけだからである。
【０００７】
しかしこれには次のような問題がある。例えば，ポーリング間隔を３６００ｓ(１時間)に設定すると，サーバ内で発生したクライアント向けのイベントを当該クライアントが検知できるまで最大３６００ｓかかるということになる。つまり，クライアントへのレスポンスがそれだけ遅くなるわけである。特に，緊急性の高いイベントが発生していた場合には大きな問題となる。
【０００８】
このような問題を改善する発明が特許文献１に開示されている。これは，サーバを介してクライアント同士が通信する場合において，サーバが管理すべき情報とそうでない情報とを分類し，サーバが管理すべき情報はサーバを介して通信し，そうでない情報は，クライアント同士で直接通信するというものである。これによりサーバの負担を軽減しつつ，サーバを介したクライアント同士の通信をレスポンスよく行うことが可能になる。
【０００９】
しかし，特許文献１に開示の発明は，サーバが管理しなくてもよい情報，即ち一般的には重要度の低い情報が存在する場合を前提としている。このため，サーバが管理すべき情報（重要度が高い情報）が多くを占めるようなシステムの場合には，当然にサーバへの通信が多くなり，従来からの課題と同様，サーバへの負担が重くなる。
【先行技術文献】
【特許文献】
【００１０】
【特許文献１】国際公開第ＷＯ０１／０５７５７８号パンフレット
【発明の概要】
【発明が解決しようとする課題】
【００１１】
本願発明はこのような問題を解決するものである。すなわち，クライアントサーバシステム形態のネットワークおいて，クライアントの数を増やしてもサーバの負担を極力あげることなく，サーバからクライアントへのレスポンスも良いクライアントサーバシステムを提供することである。
【課題を解決するための手段】
【００１２】
本願発明にかかる第１の形態は，サーバと複数のクライアントとがネットワーク接続されており，クライアントは所定の時間間隔にて当該サーバへのアクセスを行うクライアントサーバシステムにおける当該サーバであって，クライアントからのアクセスを受信する手段と，クライアント毎に管理され，それぞれの当該クライアントに通知すべき通知情報を管理する手段と，「所定の内容を当該通知情報の対象となるクライアントへ送信せよ」との内容を含む依頼を，受信したアクセスの応答として送信元クライアントに向けて送信する応答手段と，を備えるサーバである。
【００１３】
好ましくは，所定の内容は「通知情報の対象となるクライアントが，サーバにアクセスし，通知情報を取得する」という動作のトリガである。
【００１４】
本願発明にかかる第２の形態は，サーバと複数のクライアントとがネットワーク接続されており，クライアントは所定の時間間隔にて当該サーバへのアクセスを行うクライアントサーバシステムにおける当該サーバであって，クライアントからのアクセスを受信する手段と，クライアント毎に管理され，それぞれの当該クライアントに通知すべき通知情報を管理する手段と，通知情報の数が複数の場合，所定の条件に基づき通知情報の順位を決定し，受信したアクセスに対する応答として，当該順位の最上位から所定数の通知情報に関し，受信したアクセスの応答として「所定の内容を当該通知情報の対象となるクライアントへ送信せよ」との内容を含む依頼を送信元クライアントに向けて送信する応答手段と，を備えるサーバである。
【００１５】
好ましくは，所定の条件は「通知情報の対象となるクライアントにとっての優先度」および／または「サーバにおける通知情報の未処理時間」である。
【００１６】
好ましくは，所定の内容は「通知情報の対象となるクライアントが，サーバにアクセスし，通知情報を取得する」という動作のトリガである。
【００１７】
本願発明にかかる第３の形態は，サーバと複数のクライアントとがネットワーク接続されており，クライアントは所定の時間間隔にて当該サーバへのアクセスを行うクライアントサーバシステムであって，サーバは，所定のクライアントからのアクセスを受信する手段と，クライアント毎に管理され，それぞれの当該クライアントに通知すべき通知情報を管理する手段と，「所定の内容を当該通知情報の対象となるクライアントへ送信せよ」との依頼内容を，受信したアクセスの応答として送信元クライアントに向けて送信する応答手段と，を備えるクライアントサーバシステムである。
【００１８】
本願発明にかかる第４の形態は，サーバと複数のクライアントとがネットワーク接続されており，クライアントは所定の時間間隔にて当該サーバへのアクセスを行うクライアントサーバシステムあって，サーバは，クライアントからのアクセスを受信する手段と，クライアント毎に管理され，それぞれの当該クライアントに通知すべき通知情報を管理する手段と，通知情報の数が複数の場合，所定の条件に基づき通知情報の順位を決定し，受信したアクセスに対する応答として，当該順位の最上位から所定数の通知情報に関し，受信したアクセスの応答として「所定の内容を当該通知情報の対象となるクライアントへ送信せよ」との内容を含む依頼を送信元クライアントに向けて送信する応答手段と，を備えるクライアントサーバシステムである。
【００１９】
本願発明にかかる第５の形態は，サーバと複数のクライアントとがネットワーク接続されており，クライアントは所定の時間間隔にて当該サーバへのアクセスを行うクライアントサーバシステムにおける当該サーバを，クライアントからのアクセスを受信する手段と，クライアント毎に管理され，それぞれの当該クライアントに通知すべき通知情報を管理する手段と，「所定の内容を当該通知情報の対象となるクライアントへ送信せよ」との依頼内容が含まれた応答を，受信したアクセスの応答として送信元クライアントに向けて送信する応答手段と，して機能させるプログラムである。
【００２０】
好ましくは，所定の内容は「通知情報の対象となるクライアントが，サーバにアクセスし，通知情報を取得する」という動作のトリガである。
【００２１】
本願発明にかかる第６の形態は，サーバと複数のクライアントとがネットワーク接続されており，クライアントは所定の時間間隔にて当該サーバへのアクセスを行うクライアントサーバシステムにおける当該サーバを，クライアントからのアクセスを受信する手段と，クライアント毎に管理され，それぞれの当該クライアントに通知すべき通知情報を管理する手段と，通知情報の数が複数の場合，所定の条件に基づき通知情報の順位を決定し，受信したアクセスに対する応答として，当該順位の最上位から所定数の通知情報に関し，受信したアクセスの応答として「所定の内容を当該通知情報の対象となるクライアントへ送信せよ」との内容を含む依頼を送信元クライアントに向けて送信する応答手段と，して機能させるプログラムである。
【００２２】
好ましくは，所定の条件は「通知情報の対象となるクライアントにとっての優先度」および／または「サーバにおける通知情報の未処理時間」である。
【００２３】
好ましくは，所定の内容は「通知情報の対象となるクライアントが，サーバにアクセスし，通知情報を取得する」という動作のトリガである。
【発明の効果】
【００２４】
本願発明の第１の形態によれば，サーバで発生した特定クライアント向けのイベント発生通知依頼を，他のクライアントのポーリング応答に含めることで，サーバへの負担を軽減するためクライアントの数を増やしポーリング間隔を大きくしたとしても，当該特定のクライアントは自身に対するイベント発生を遅滞なく検知することができる。さらに，イベント発生通知を受信した当該特定クライアント自身が，この受信をトリガとして，サーバにアクセスを行い自身に対して発生したイベントの内容を取得することで，重要度が高いものや，秘匿性を有するようなイベントであっても，良好なレスポンスを維持しつつ内容を取得することができる。
【００２５】
さらに本願発明の第２の形態によれば，サーバから送信されるイベント発生通知依頼は，イベントの重要度およびイベントの未処理時間に基づいて送信順序が決定されるため，クライアントの数が増加し，イベントが多数発生したとしても，効率よくクライアントに通知することができる。
【００２６】
また，その他の形態によれば，イベントの未処理時間に応じて優先度を変化させることで，優先度の低いイベントが長期間にわたって通知されないという問題を回避することができる。
【００２７】
また，その他の形態によれば，ポーリングしてきたクライアントに通知するイベント数を，当該クライアントの処理能力等に応じて変化させることで，イベントが発生しているクライアントへのイベント発生通知を，より効率的に行うことができる。
【発明を実施するための形態】
【００２８】
以下では図面を参照し本願発明に係る実施例を説明する。
［実施例１］
【００２９】
図３は本実施例にかかるシーケンス図である。図示するように本実施例ではポーリング間隔を３０ｓにしている。図２の説明では１０ｓであったが，これよりも長い間隔としている。こうすることで，クライアントの数を３倍に増やしても，理論上，サーバへの負担は図２の場合と同じである。
【００３０】
本願発明では，ポーリング間隔を長くしたことによる，サーバからクライアントへのレスポンス低下を防ぐため，任意のクライアント（必ずしもそのクライアントにイベントが発生している必要はない）からのポーリングに対する応答の中に，イベントが発生したクライアントに向けたイベント発生通知の依頼を含めている。この応答を受信したクライアントは，イベントが発生しているクライアントに対してイベント発生通知をする。こうすることで，当該イベントが発生しているクライアントは，自身のポーリング間隔に関係なく，他のクライアントからイベント発生通知を受信しイベントの発生を検知することができる。すなわち，イベントが発生しているクライアントにとって，他のクライアントから送信されたイベント発生通知の受信は，サーバにアクセスし当該イベントの内容を取得するためのトリガとなっている。
【００３１】
図３は，クライアント１０２へのイベントがサーバ１０４にて発生した場合を図示している。図からわかるように，クライアント１０２は，自身のポーリング時間の到来を待たずしてイベント発生を検知できる。結果として，クライアント１０２がイベントを検知するまでの平均時間を，ポーリング間隔よりも大幅に短くすることが可能である。
［ブロック図］
【００３２】
図４は本実施例にかかるサーバ１０４のブロック図である。
【００３３】
イベント管理手段４０４は，クライアントに対するイベントが発生すると，これをイベント保存領域４０６に登録する。
【００３４】
アクセス受信手段４０２は，ネットワークインタフェース４０１を介してクライアントからのポーリングを受信する手段である。
【００３５】
イベント存否判断手段４０３は，クライアントからのアクセスがあると，当該クライアント以外のクライアントに対するイベントが存在するかどうかを，イベント保存領域４０６を参照して判断する。判断の結果，イベントが存在していれば，後述する応答手段４０５にその旨通知する。
【００３６】
応答手段４０５は，アクセス受信手段４０２が受信したクライアントからのポーリングに対して応答するものであるが，応答の際，前述のイベント存否判断手段４０３からの通知を受信していれば，イベント保存領域４０６からイベント情報を読み出し，その情報とともにクライアントに応答する。イベントが複数ある場合はすべてを読み出して応答する。
［サーバの動作フロー］
【００３７】
図５はサーバ１０４の動作フローである。
【００３８】
ステップ５０１にて，クライアントからのアクセスがあるかどうかを判断する。判断の結果，アクセスがあれば，次のステップに進み，そうでなければ受信判断を繰り返す。
【００３９】
ステップ５０２にて，イベントがあるかどうかを，イベント保存領域４０６を参照して判断する。判断の結果，存在すれば，次のステップに進み，そうでなければ受信判断に戻る。
【００４０】
ステップ５０３にて，イベント保存領域４０６から，イベントを読み出し，これをステップ５０１にて受信したアクセスに対する応答内容に含めて応答する。
［実施例２］
【００４１】
すでに述べたように，クライアントのポーリング間隔を大きくすることで，サーバ１０４の負担を高めることなくクライアントの数を増やすことができる。しかし，クライアント数を増やせば，それに応じてイベント発生数も多くなる。
【００４２】
発生したすべてのイベントを，ポーリングしてきたクライアントに一時に通知すると，当該クライアントにとっては大きな負担となる。そこで，本実施例では，サーバ１０４が，クライアントに通知するイベントの順位付けを行い，ポーリングしてきた１つのクライアントに対して上位から順に１件ずつ通知することで，クライアントの負荷を軽減しつつ，効率的なイベント通知を行う。
【００４３】
上述した動作を示したのが図６である。これは，サーバ１０４がイベント保存領域４０６にて管理するイベントのリストである。図示するとおり，各イベントには，通知対象となるクライアント名，イベント優先度，および未処理時間の属性が与えられる。
【００４４】
イベント優先度は，クライアントにとっての緊急度や重要度を意味し，優先度が高いほど即時処理を期待されるものである。優先度はイベントの種類に対応した所定のもの（図では優先度が高い順にＳ，Ａ，Ｂ，Ｃ）が予め定められている。一方，未処理時間は，イベントがサーバ１０４で発生してからの経過時間である。一般には，未処理時間が長いものほど，即時処理が求められると考えられる。
【００４５】
サーバ１０４のイベント管理手段４０４は，発生したイベントをイベント保存領域４０６に登録する際，イベント優先度を第１キーとして登録する。次いで，同じイベント優先度の中での順位は，未処理時間の長いものほど上位になるようにソートして登録する。
【００４６】
クライアントからのポーリングを受信すると，１件のポーリングに対し１件ずつイベントを上位から通知する。これにより，最も重要度・緊急度が高いと推測されるイベント順に，対象となるクライアントに通知することができる。
［ブロック図］
【００４７】
図７は実施例２におけるサーバ１０４のブロック図である。図示するように，イベント管理手段４０４には，優先度および未処理時間をキーとしてイベントをソートする手段であるイベントソート手段７０１が備えられている。残りの手段は実施例１と同じであるため説明を省略する。
【００４８】
図８は実施例２におけるサーバ１０４の動作フローである。図示するように，イベント管理タスクのステップ８０２にて，発生したイベントを優先度・未処理時間順にソートして，イベント保存領域４０６に登録する。
【００４９】
次いで，メインタスクのステップ８０３にて，イベント保存領域４０６に保存されているイベントを，最上位から順にポーリングしてきたクライアントに通知する。
［その他の実施例］
実施例２では，イベントを，優先度および未処理時間にて管理したが，この未処理時間が所定の閾値を超えると，優先度を上げるというようにしてもよい。例えば，優先度Ａのイベントの未処理時間が１００ｓを超えると，優先度Ｓに変えるなどである。この場合，未処理時間をいったん０（ゼロ）にリセットすることが望ましい。
【００５０】
実施例２では，サーバ１０４にて発生したイベントをポーリングしてきたクライアントに１件ずつ通知したが，クライアントの処理能力等を考慮し，優先度が高いものから順に，数件のイベントをまとめて通知することもできる。例えば，クライアントの処理能力が高い場合は，複数のイベントを通知することができる。
［まとめ］
【００５１】
本願発明の第１の形態によれば，サーバで発生した特定クライアント向けのイベント発生通知依頼を，他のクライアントのポーリング応答に含めることで，サーバへの負担を軽減するためクライアントの数を増やし，ポーリング間隔を大きくしたとしても，当該特定のクライアントは自身に対するイベント発生を遅滞なく検知することができる。さらに，イベント発生通知を受信した当該特定クライアント自身が，この受信をトリガとして，サーバにアクセスを行い自身に対して発生したイベントの内容を取得することで，重要度が高いものや，秘匿性を有するようなイベントであっても，良好なレスポンスを維持しつつ内容を取得することができる。
【００５２】
さらに本願発明の第２の形態によれば，サーバから送信されるイベント発生通知依頼は，イベントの重要度およびサーバによるイベントの未処理時間に基づいて送信順序が決定されるため，クライアントの数が増加し，イベントが多数発生したとしても，効率よくクライアントに通知することができる。
【００５３】
また，その他の形態によれば，イベントの未処理時間に応じて優先度を変化させることで，優先度の低いイベントが長期間にわたって通知されないという問題を回避することができる。
【００５４】
また，その他の形態によれば，ポーリングしてきたクライアントに通知するイベント数を，当該クライアントの処理能力等に応じて変化させることで，イベントが発生しているクライアントへのイベント発生通知を，より効率的に行うことができる。
【図面の簡単な説明】
【００５５】
【図１】システム全体図
【図２】従来技術のシーケンス図
【図３】実施例１ シーケンス図
【図４】実施例１ サーバのブロック図
【図５】実施例１ サーバの動作フロー
【図６】実施例２ サーバ側でのイベント通知依頼送信順序
【図７】実施例２ サーバのブロック図
【図８】実施例２ サーバの動作フロー
【符号の説明】
【００５６】
４０２ アクセス受信手段
４０４ イベント管理手段
４０５ 応答手段
【特許請求の範囲】
【請求項１】
サーバと複数のクライアントとがネットワーク接続されており，クライアントは所定の時間間隔にて当該サーバへのアクセスを行うクライアントサーバシステムにおける当該サーバであって，
クライアントからのアクセスを受信する手段と，
クライアント毎に管理され，それぞれの当該クライアントに通知すべき通知情報を管理する手段と，
「所定の内容を当該通知情報の対象となるクライアントへ送信せよ」との内容を含む依頼を，受信した前記アクセスの応答として送信元クライアントに向けて送信する応答手段と，を備えるサーバ。
【請求項２】
前記所定の内容は「通知情報の対象となる前記クライアントが，前記サーバにアクセスし，前記通知情報を取得する」という動作のトリガであることを特徴とする請求項１に記載のサーバ。
【請求項３】
サーバと複数のクライアントとがネットワーク接続されており，クライアントは所定の時間間隔にて当該サーバへのアクセスを行うクライアントサーバシステムにおける当該サーバであって，
クライアントからのアクセスを受信する手段と，
クライアント毎に管理され，それぞれの当該クライアントに通知すべき通知情報を管理する手段と，
前記通知情報の数が複数の場合，所定の条件に基づき前記通知情報の順位を決定し，受信した前記アクセスに対する応答として，当該順位の最上位から所定数の通知情報に関し，受信した前記アクセスの応答として「所定の内容を当該通知情報の対象となるクライアントへ送信せよ」との内容を含む依頼を送信元クライアントに向けて送信する応答手段と，を備えるサーバ。
【請求項４】
前記所定の条件は「前記通知情報の対象となるクライアントにとっての優先度」および／または「前記サーバにおける前記通知情報の未処理時間」であることを特徴とする請求項３に記載のサーバ。
【請求項５】
前記所定の内容は「通知情報の対象となる前記クライアントが，前記サーバにアクセスし，前記通知情報を取得する」という動作のトリガであることを特徴とする請求項３または４に記載のサーバ。
【請求項６】
サーバと複数のクライアントとがネットワーク接続されており，クライアントは所定の時間間隔にて当該サーバへのアクセスを行うクライアントサーバシステムであって，
前記サーバは，
所定のクライアントからのアクセスを受信する手段と，
クライアント毎に管理され，それぞれの当該クライアントに通知すべき通知情報を管理する手段と，
「所定の内容を当該通知情報の対象となるクライアントへ送信せよ」との依頼内容を，受信した前記アクセスの応答として送信元クライアントに向けて送信する応答手段と，
を備えるクライアントサーバシステム。
【請求項７】
サーバと複数のクライアントとがネットワーク接続されており，クライアントは所定の時間間隔にて当該サーバへのアクセスを行うクライアントサーバシステムあって，
前記サーバは，
クライアントからのアクセスを受信する手段と，
クライアント毎に管理され，それぞれの当該クライアントに通知すべき通知情報を管理する手段と，
前記通知情報の数が複数の場合，所定の条件に基づき前記通知情報の順位を決定し，受信した前記アクセスに対する応答として，当該順位の最上位から所定数の通知情報に関し，受信した前記アクセスの応答として「所定の内容を当該通知情報の対象となるクライアントへ送信せよ」との内容を含む依頼を送信元クライアントに向けて送信する応答手段と，
を備えるクライアントサーバシステム。
【請求項８】
サーバと複数のクライアントとがネットワーク接続されており，クライアントは所定の時間間隔にて当該サーバへのアクセスを行うクライアントサーバシステムにおける当該サーバを，
クライアントからのアクセスを受信する手段と，
クライアント毎に管理され，それぞれの当該クライアントに通知すべき通知情報を管理する手段と，
「所定の内容を当該通知情報の対象となるクライアントへ送信せよ」との依頼内容が含まれた応答を，受信した前記アクセスの応答として送信元クライアントに向けて送信する応答手段と，して機能させるプログラム。
【請求項９】
前記所定の内容は「通知情報の対象となる前記クライアントが，前記サーバにアクセスし，前記通知情報を取得する」という動作のトリガであることを特徴とする請求項８に記載のプログラム。
【請求項１０】
サーバと複数のクライアントとがネットワーク接続されており，クライアントは所定の時間間隔にて当該サーバへのアクセスを行うクライアントサーバシステムにおける当該サーバを，
クライアントからのアクセスを受信する手段と，
クライアント毎に管理され，それぞれの当該クライアントに通知すべき通知情報を管理する手段と，
前記通知情報の数が複数の場合，所定の条件に基づき前記通知情報の順位を決定し，受信した前記アクセスに対する応答として，当該順位の最上位から所定数の通知情報に関し，受信した前記アクセスの応答として「所定の内容を当該通知情報の対象となるクライアントへ送信せよ」との内容を含む依頼を送信元クライアントに向けて送信する応答手段と，して機能させるプログラム。
【請求項１１】
前記所定の条件は「前記通知情報の対象となるクライアントにとっての優先度」および／または「前記サーバにおける前記通知情報の未処理時間」であることを特徴とする請求項１０に記載のプログラム。
【請求項１２】
前記所定の内容は「通知情報の対象となる前記クライアントが，前記サーバにアクセスし，前記通知情報を取得する」という動作のトリガであることを特徴とする請求項１０または１１に記載のプログラム。
【請求項１】
サーバと複数のクライアントとがネットワーク接続されており，クライアントは所定の時間間隔にて当該サーバへのアクセスを行うクライアントサーバシステムにおける当該サーバであって，
クライアントからのアクセスを受信する手段と，
クライアント毎に管理され，それぞれの当該クライアントに通知すべき通知情報を管理する手段と，
「所定の内容を当該通知情報の対象となるクライアントへ送信せよ」との内容を含む依頼を，受信した前記アクセスの応答として送信元クライアントに向けて送信する応答手段と，を備えるサーバ。
【請求項２】
前記所定の内容は「通知情報の対象となる前記クライアントが，前記サーバにアクセスし，前記通知情報を取得する」という動作のトリガであることを特徴とする請求項１に記載のサーバ。
【請求項３】
サーバと複数のクライアントとがネットワーク接続されており，クライアントは所定の時間間隔にて当該サーバへのアクセスを行うクライアントサーバシステムにおける当該サーバであって，
クライアントからのアクセスを受信する手段と，
クライアント毎に管理され，それぞれの当該クライアントに通知すべき通知情報を管理する手段と，
前記通知情報の数が複数の場合，所定の条件に基づき前記通知情報の順位を決定し，受信した前記アクセスに対する応答として，当該順位の最上位から所定数の通知情報に関し，受信した前記アクセスの応答として「所定の内容を当該通知情報の対象となるクライアントへ送信せよ」との内容を含む依頼を送信元クライアントに向けて送信する応答手段と，を備えるサーバ。
【請求項４】
前記所定の条件は「前記通知情報の対象となるクライアントにとっての優先度」および／または「前記サーバにおける前記通知情報の未処理時間」であることを特徴とする請求項３に記載のサーバ。
【請求項５】
前記所定の内容は「通知情報の対象となる前記クライアントが，前記サーバにアクセスし，前記通知情報を取得する」という動作のトリガであることを特徴とする請求項３または４に記載のサーバ。
【請求項６】
サーバと複数のクライアントとがネットワーク接続されており，クライアントは所定の時間間隔にて当該サーバへのアクセスを行うクライアントサーバシステムであって，
前記サーバは，
所定のクライアントからのアクセスを受信する手段と，
クライアント毎に管理され，それぞれの当該クライアントに通知すべき通知情報を管理する手段と，
「所定の内容を当該通知情報の対象となるクライアントへ送信せよ」との依頼内容を，受信した前記アクセスの応答として送信元クライアントに向けて送信する応答手段と，
を備えるクライアントサーバシステム。
【請求項７】
サーバと複数のクライアントとがネットワーク接続されており，クライアントは所定の時間間隔にて当該サーバへのアクセスを行うクライアントサーバシステムあって，
前記サーバは，
クライアントからのアクセスを受信する手段と，
クライアント毎に管理され，それぞれの当該クライアントに通知すべき通知情報を管理する手段と，
前記通知情報の数が複数の場合，所定の条件に基づき前記通知情報の順位を決定し，受信した前記アクセスに対する応答として，当該順位の最上位から所定数の通知情報に関し，受信した前記アクセスの応答として「所定の内容を当該通知情報の対象となるクライアントへ送信せよ」との内容を含む依頼を送信元クライアントに向けて送信する応答手段と，
を備えるクライアントサーバシステム。
【請求項８】
サーバと複数のクライアントとがネットワーク接続されており，クライアントは所定の時間間隔にて当該サーバへのアクセスを行うクライアントサーバシステムにおける当該サーバを，
クライアントからのアクセスを受信する手段と，
クライアント毎に管理され，それぞれの当該クライアントに通知すべき通知情報を管理する手段と，
「所定の内容を当該通知情報の対象となるクライアントへ送信せよ」との依頼内容が含まれた応答を，受信した前記アクセスの応答として送信元クライアントに向けて送信する応答手段と，して機能させるプログラム。
【請求項９】
前記所定の内容は「通知情報の対象となる前記クライアントが，前記サーバにアクセスし，前記通知情報を取得する」という動作のトリガであることを特徴とする請求項８に記載のプログラム。
【請求項１０】
サーバと複数のクライアントとがネットワーク接続されており，クライアントは所定の時間間隔にて当該サーバへのアクセスを行うクライアントサーバシステムにおける当該サーバを，
クライアントからのアクセスを受信する手段と，
クライアント毎に管理され，それぞれの当該クライアントに通知すべき通知情報を管理する手段と，
前記通知情報の数が複数の場合，所定の条件に基づき前記通知情報の順位を決定し，受信した前記アクセスに対する応答として，当該順位の最上位から所定数の通知情報に関し，受信した前記アクセスの応答として「所定の内容を当該通知情報の対象となるクライアントへ送信せよ」との内容を含む依頼を送信元クライアントに向けて送信する応答手段と，して機能させるプログラム。
【請求項１１】
前記所定の条件は「前記通知情報の対象となるクライアントにとっての優先度」および／または「前記サーバにおける前記通知情報の未処理時間」であることを特徴とする請求項１０に記載のプログラム。
【請求項１２】
前記所定の内容は「通知情報の対象となる前記クライアントが，前記サーバにアクセスし，前記通知情報を取得する」という動作のトリガであることを特徴とする請求項１０または１１に記載のプログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【公開番号】特開２０１３−３７６５６（Ｐ２０１３−３７６５６Ａ）
【公開日】平成２５年２月２１日（２０１３．２．２１）
【国際特許分類】
【出願番号】特願２０１１−１７５７３４（Ｐ２０１１−１７５７３４）
【出願日】平成２３年８月１１日（２０１１．８．１１）
【出願人】（５００１１２１４６）サイレックス・テクノロジー株式会社 (74)
【公開日】平成２５年２月２１日（２０１３．２．２１）
【国際特許分類】
【出願日】平成２３年８月１１日（２０１１．８．１１）
【出願人】（５００１１２１４６）サイレックス・テクノロジー株式会社 (74)
[ Back to top ]