JP5940566B2 - ネットワークシステム、常時接続方法、サーバ、電子機器、プログラム - Google Patents

Description

本発明は、常時接続の技術に関し、特にクライアントが常時接続サーバを介してサービスを利用するネットワークシステム、常時接続方法、電子機器、サーバ、プログラムに関する。

従来から、通信機器が互いに相手にデータを送信するための様々な技術が知られている。たとえば、特開２０１０−２７７４９２号公報（特許文献１）には、電子会議サーバおよびコンピュータプログラムが開示されている。特開２０１０−２７７４９２号公報（特許文献１）によると、ウェブ・アプリケーションにて電子会議システムを提供する場合にリアルタイム性を確保可能とすること、および電子会議システムの運用に付随した未解決課題の管理などを実現する。具体的には、アプリケーションサーバは、Ｃｏｍｅｔサーバが各電子機器からのＨＴＴＰリクエストを受信して保留状態となるように制御する。ある電子機器からメッセージデータをアプリケーションサーバが受信したら、アプリケーションサーバが会議データベースから必要データを引き出してメッセージデータとともに該当する電子機器へＣｏｍｅｔサーバから送信する。送信後は前記アプリケーションサーバが各電子機器からのＨＴＴＰリクエストを受信して再び保留状態となるように制御する。

しかしながら、Ｃｏｍｅｔでは、通信のたびにＨＴＴＰセッションが必要となるため、クライアントとサーバとの間で何度も同じデータをやり取りする必要があった。そこで、近年では、ＴＣＰ（Transmission Control Protocol）上で動作するＷｅｂＳｏｃｋｅｔという技術が開発されている。ＷｅｂＳｏｃｋｅｔは、インターネットの標準化団体であるＷ３ＣとＩＥＴＦがウェブサーバとウェブブラウザとの間の双方向通信用の技術規格である。ＷｅｂＳｏｃｋｅｔプロトコルの仕様はＲＦＣ（Request For Comment）６４５５に規定されている。

特開２０１０−２７７４９２号公報

一般的にネットワークシステムの可用性を高めるためにネットワークシステムの各部の冗長化を行うことが多い。しかしながら、常時接続サーバを冗長化した場合には、通常のサーバを冗長化した場合とは異なる問題が生じる。たとえば、１つのアプリケーションサービスに関するクライアントとの常時接続を複数の常時接続サーバが受け持っていたり、１つの常時接続サーバが複数のアプリケーションサービスに関するクライアントとの常時接続を受け持っていたりするため、システム全体または一部の常時接続サーバのメンテナンス・運用などが複雑なものになってしまう。

本発明は、かかる問題を解決するためになされたものであり、その目的は、常時接続サーバを冗長化した場合に生じる問題を解決することにある。たとえば、システムまたは常時接続サーバのメンテナンスまたは運用を従来よりも容易にすることができる。

この発明のある態様に従うと、複数の常時接続サーバと、複数の常時接続サーバのいずれかを介してサービスを利用するためのクライアントと、クライアントと通信可能なサーバと、を備えるネットワークシステムが提供される。サーバは、クライアントからの要求に応じて、複数の常時接続サーバのうちの少なくとも１つの常時接続サーバに関するリストをクライアントに送信する。クライアントは、リストに基づいてサービスに対応する常時接続サーバとの常時接続を開始する。

好ましくは、要求がサービスを特定するためのサービス情報を含む。サーバが、サービス情報に基づいて、リストとして、サービスに対応する少なくとも１つの常時接続サーバに関するリストを作成する。

好ましくは、要求がクライアントを特定するためのクライアント情報を含む。サーバが、クライアント情報に対応するサービスを特定し、リストとして、サービスに対応する少なくとも１つの常時接続サーバに関するリストを作成する。

好ましくは、サーバおよび他のサーバのいずれかが、複数の常時接続サーバそれぞれが接続中のクライアントの数に基づいて、複数の常時接続サーバそれぞれに割り振るサービスを変更する。

好ましくは、サーバおよび他のサーバのいずれかが、複数の常時接続サーバそれぞれからのデータのＰＵＳＨの頻度に基づいて、複数の常時接続サーバそれぞれに割り振るサービスを変更する。

好ましくは、サーバおよび他のサーバのいずれかが、複数の常時接続サーバそれぞれからのデータ量に基づいて、複数の常時接続サーバそれぞれに割り振るサービスを変更する。

好ましくは、サーバおよび他のサーバのいずれかが、複数の常時接続サーバそれぞれの負荷に基づいて、複数の常時接続サーバそれぞれに割り振るサービスを変更する。

好ましくは、複数の常時接続サーバは、稼働中の常時接続サーバと非稼働中の常時接続サーバとを含む。サーバおよび他のサーバのいずれかが、所定の条件に基づいて、複数の常時接続サーバの各々の稼働および非稼働を切り替える。

好ましくは、サーバが、複数の常時接続サーバのいずれかである。

この発明の別の態様に従うと、サービスを利用するためのクライアントがサーバに要求を送るステップと、サーバが、クライアントからの要求に応じて、複数の常時接続サーバのうちの少なくとも１つの常時接続サーバに関するリストをクライアントに送信するステップと、クライアントが、リストに基づいてサービスに対応する常時接続サーバとの常時接続を開始するステップとを備える、常時接続方法が提供される。

この発明の別の態様に従うと、クライアントと通信するための通信インターフェイスと、通信インターフェイスを介して、クライアントからの要求を受信し、クライアントが利用するためのサービスに対応する少なくとも１つの常時接続サーバに関するリストをクライアントに送信するためのプロセッサとを備える、サーバが提供される。

この発明の別の態様に従うと、プロセッサと通信インターフェイスとを含むサーバで利用されるプログラムが提供される。プログラムは、通信インターフェイスを介して、クライアントからの要求を受け付けるステップと、通信インターフェイスを介して、クライアントが利用するためのサービスに対応する少なくとも１つの常時接続サーバに関するリストをクライアントに送信するステップとをプロセッサに実行させる。

この発明の別の態様に従うと、サーバと通信するための通信インターフェイスと、通信インターフェイスを介して、サーバから少なくとも１つの常時接続サーバに関するリストを受信し、リストに基づいてサービスに対応する常時接続サーバとの常時接続を開始するためのプロセッサとを備える、電子機器が提供される。

この発明の別の態様に従うと、プロセッサと通信インターフェイスとを含む電子機器で利用されるプログラムが提供される。プログラムは、通信インターフェイスを介して、サーバから少なくとも１つの常時接続サーバに関するリストを受信するステップと、通信インターフェイスを介して、リストに基づいてサービスに対応する常時接続サーバとの常時接続を開始するステップとをプロセッサに実行させる。

以上のように、この発明によれば、常時接続サーバを冗長化した場合に生じる問題を解決できる。たとえば、システムまたは一部の常時接続サーバのメンテナンスまたは運用を従来よりも容易にすることができる。

本実施の形態にかかるネットワークシステム１の全体構成を示すイメージ図である。 本実施の形態にかかるクライアント１００のハードウェア構成を表わすブロック図である。 本実施の形態にかかる常時接続サーバ２００のハードウェア構成を表わすブロック図である。 本実施の形態にかかるアプリケーションサーバ３００のハードウェア構成を表わすブロック図である。 本実施の形態にかかる第１の補助サーバ４００のハードウェア構成を表わすブロック図である。 本実施の形態にかかるサービス／ノード対応関係ＤＢ６００に含まれるデータの構造を示すイメージ図である。 本実施の形態にかかる第２の補助サーバ５００のハードウェア構成を表わすブロック図である。 本実施の形態にかかる接続ＩＤ／ノード対応関係ＤＢ７００に含まれるデータの構造を示すイメージ図である。 本実施の形態にかかる監視サーバ８００のハードウェア構成を表わすブロック図である。 第１の実施の形態にかかるネットワークシステム１全体の機能構成を示す第１のブロック図である。 第１の実施の形態にかかるネットワークシステム１全体の機能構成を示す第２のブロック図である。 第１の実施の形態にかかるネットワークシステム１全体の機能構成を示す第３のブロック図である。 本実施の形態にかかるネットワークシステム１における常時接続に関する装置間のデータのやり取りの処理手順を示すシーケンス図である。 第１の実施の形態にかかるネットワークシステム１全体の機能構成を示す第４のブロック図である。 第１の実施の形態にかかるネットワークシステム１全体の機能構成を示す第５のブロック図である。 本実施の形態にかかるクライアント１００におけるノード選択処理を示すフローチャートである。 本実施の形態にかかるクライアント１００におけるノード選択処理を示すフローチャートである。 本実施の形態にかかる監視サーバ８００における対応関係変更処理を示すフローチャートである。 第２の実施の形態にかかるネットワークシステム１全体の機能構成を示すブロック図である。 第３の実施の形態にかかるネットワークシステム１全体の機能構成を示すブロック図である。 第４の実施の形態にかかるネットワークシステム１全体の機能構成を示すブロック図である。 第５の実施の形態にかかるネットワークシステム１全体の機能構成を示す第１のブロック図である。 第５の実施の形態にかかるネットワークシステム１全体の機能構成を示す第２のブロック図である。 第６の実施の形態にかかるネットワークシステム１全体の機能構成を示す第１のブロック図である。 第６の実施の形態にかかるネットワークシステム１全体の機能構成を示す第２のブロック図である。 第７の実施の形態にかかるネットワークシステム１全体の機能構成を示す第１のブロック図である。 第７の実施の形態にかかるネットワークシステム１全体の機能構成を示す第２のブロック図である。 第８の実施の形態にかかるネットワークシステム１全体の機能構成を示す第１のブロック図である。 第８の実施の形態にかかるネットワークシステム１全体の機能構成を示す第２のブロック図である。

以下、図面を参照しつつ、本発明の実施の形態について説明する。以下の説明では、同一の部品には同一の符号を付してある。それらの名称および機能も同じである。したがって、それらについての詳細な説明は繰り返さない。

また、以下では、常時接続の一例として、ＷｅｂＳｏｃｋｅｔプロトコルを利用した通信について説明する。しかしながら、アプリケーションサーバから任意のタイミングでクライアントにデータをプッシュできればよく、本発明はＷｅｂＳｏｃｋｅｔプロトコルを利用する常時接続に限定されるものではない。
＜第１の実施の形態＞
＜ネットワークシステムの全体構成＞

まず、本実施の形態にかかるネットワークシステム１の全体構成について説明する。図１は、本実施の形態にかかるネットワークシステム１の全体構成を示すイメージ図である。

図１を参照して、本実施の形態にかかるネットワークシステム１は、住居またはオフィスなどに配置される複数の家電１００Ａ，１００Ｂ，１００Ｃと、ネットワークを介して家電１００Ａ，１００Ｂ，１００Ｃと接続される複数の常時接続サーバ２００Ａ，２００Ｂ，２００Ｃ，２００Ｄと、家電１００Ａ，１００Ｂ，１００Ｃに関する様々なサービスを提供する複数のアプリケーションサーバ３００Ａ，３００Ｂ，３００Ｃと、複数の家電１００Ａ，１００Ｂ，１００Ｃに常時接続サーバ２００Ａ，２００Ｂ，２００Ｃ，２００Ｄに関するリストを提供する第１の補助サーバ４００と、アプリケーションサーバ３００Ａ，３００Ｂ，３００Ｃからのデータを常時接続サーバ２００Ａ，２００Ｂ，２００Ｃ，２００Ｄに割り振るための第２の補助サーバ５００とを含む。

なお、以下では家電１００Ａ，１００Ｂ，１００Ｃを総称してクライアント１００ともいう。また、常時接続サーバ２００Ａ，２００Ｂ，２００Ｃ，２００Ｄを総称して常時接続サーバ２００ともいう。また、アプリケーションサーバ３００Ａ，３００Ｂ，３００Ｃを総称してアプリケーションサーバ３００ともいう。

ここで、クライアント１００としては、たとえば、掃除機１００Ａ、エアコン１００Ｂ、テレビ１００Ｃ、洗濯機、冷蔵庫、炊飯器、空気清浄器、床暖房、ＩＨ（Induction Heating）クッキングヒーター、などが挙げられる。さらに、クライアント１００は、住居内またはオフィス内の通信機器であればよく、たとえば、パーソナルコンピュータ、テレビ以外のＡＶ機器、インターホンシステムなどを含んでもよい。また、常時接続サーバ２００とアプリケーションサーバ３００と第１の補助サーバ４００と第２の補助サーバ５００とは、クライアント１００と同じ住居内、オフィス内、ビル内、会社あるいは学校の構内に存在するサーバなどであってもよい。

また、クライアント１００と各サーバ間は、光ファイバ等の回線を経由して接続されており、途中に、光回線終端装置、無線ＬＡＮ通信を行うためのアクセスポイント、ルータ等が接続されてもよい。家電は、ネットワークに接続する手段として、ＩＥＥＥ８０２．１１ａ／ｂ／ｇ／ｎ／ａｃなどの無線ＬＡＮ通信、あるいは、有線ＬＡＮなどが用いられるが、接続方法はこれらに限定されるものではない。

本実施の形態においては、１つのアプリケーションサーバ３００または１つのサービスに対して、１つ以上の常時接続サーバ２００が対応付けられている。そして、１つの常時接続サーバ２００にして、１つ以上のアプリケーションサーバ３００または１つ以上のサービスが対応付けられている。つまり、本実施形態にかかるネットワークシステム１は、サービス対常時接続サーバがＮ対Ｎであってもよい。

ただし、１つのアプリケーションサーバ３００または１つのサービスに対して、複数の常時接続サーバ２００が対応付けられ、１つの常時接続サーバ２００に対しては１つだけのアプリケーションサーバ３００または１つだけのサービスが対応付けられるものであってもよい。つまり、サービス対常時接続サーバが１対Ｎは許容されるが、サービス対常時接続サーバがＮ対Ｎは許容されないシステムであってもよい。

逆に、１つのアプリケーションサーバ３００または１つのサービスに対して、１つだけの常時接続サーバ２００が対応付けられ、１つの常時接続サーバ２００に対しては複数のアプリケーションサーバ３００または複数のサービスが対応付けられるものであってもよい。つまり、サービス対常時接続サーバがＮ対１は許容されるが、サービス対常時接続サーバがＮ対Ｎは許容されないシステムであってもよい。

本実施の形態においては、そして、サービスと常時接続サーバ２００が実現するノードに関する情報との対応関係がサービス／ノード対応関係ＤＢ６００に格納されている。そして、クライアント１００の各々は、サービス／ノード対応関係ＤＢ６００からのデータを利用して、自身が利用するサービスに対応する常時接続サーバ２００のいずれかと常時接続する。

以下では、説明のために、１つのアプリケーションサーバ３００が１つのサービスを提供するものとし、１つのサービスは１つのアプリケーションサーバ３００から提供されるものとする。すなわち、本実施の形態においては、アプリケーションサーバ３００とサービスとが１対１で対応するものとする。

なお、ここでのノードに関する情報は、常時接続サーバ２００のアドレスであってもよいし、常時接続サーバ２００を特定するＩＤであってもよい。ノードに関する情報が、常時接続サーバ２００を特定するＩＤである場合には、サービス／ノード対応関係ＤＢ６００は、常時接続サーバ２００を特定するＩＤと常時接続サーバ２００のアドレスとの対応関係を記憶する。

たとえば、第１のアプリケーションサーバ３００Ａが掃除機１００Ａに掃除機用のサービスを提供し、第２のアプリケーションサーバ３００Ｂがエアコン１００Ｂにエアコン用のサービスを提供し、第３のアプリケーションサーバ３００Ｃがテレビ１００Ｃにテレビ用のサービスを提供する場合を想定する。そして、ある時点において、第１のアプリケーションサーバ３００Ａが第１の常時接続サーバ２００Ａと第２の常時接続サーバ２００Ｂとに対応付けられており、第２のアプリケーションサーバ３００Ｂが第３の常時接続サーバ２００Ｃと第４のアプリケーションサーバとに対応付けられており、第３のアプリケーションサーバ３００Ｃが第３の常時接続サーバ２００Ｃと第４の常時接続サーバ２００Ｄとに対応付けられているとする。

この状況において、掃除機１００Ａが掃除機用のサービスの利用を試みる場合、すなわち掃除機１００Ａが常時接続の開始を試みる場合、掃除機１００Ａは第１の補助サーバ４００から掃除機用のサービスに対応する常時接続サーバ２００のリストを取得する。掃除機１００Ａは、当該リストを参照して、掃除機用のサービスに対応する第１の常時接続サーバ２００Ａまたは第２の常時接続サーバ２００Ｂとの常時接続を行う。これによって、第１のアプリケーションサーバ３００Ａは、第１の常時接続サーバ２００Ａまたは第２の常時接続サーバ２００Ｂを介して、掃除機１００Ａに各種のデータをＰＵＳＨすることができるようになる。すなわち、掃除機用のサービスを利用する複数のクライアント１００は、第１の常時接続サーバ２００Ａまたは第２の常時接続サーバ２００Ｂを介して、第１のアプリケーションサーバ３００ＡからのデータＰＵＳＨを受け付ける。

同様に、エアコン１００Ｂがエアコン用のサービスの利用を試みる場合、すなわちエアコン１００Ｂが常時接続の開始を試みる場合、エアコン１００Ｂは第１の補助サーバ４００からエアコン用のサービスに対応する常時接続サーバ２００のリストを取得する。エアコン１００Ｂは、当該リストを参照して、エアコンのサービスに対応する第３の常時接続サーバ２００Ｃまたは第４の常時接続サーバ２００Ｄとの常時接続を行う。これによって、第２のアプリケーションサーバ３００Ｂは、第３の常時接続サーバ２００Ｃまたは第４の常時接続サーバ２００Ｄを介して、エアコン１００Ｂに各種のデータをＰＵＳＨすることができるようになる。すなわち、エアコン用のサービスを利用する複数のクライアント１００は、第３の常時接続サーバ２００Ｃまたは第４の常時接続サーバ２００Ｄを介して、第２のアプリケーションサーバ３００ＢからのデータＰＵＳＨを受け付ける。

同様に、テレビ１００Ｃがテレビ用のサービスの利用を試みる場合、すなわちテレビ１００Ｃが常時接続の開始を試みる場合、テレビ１００Ｃは第１の補助サーバ４００からテレビ用のサービスに対応する常時接続サーバ２００のリストを取得する。テレビ１００Ｃは、当該リストを参照して、テレビのサービスに対応する第３の常時接続サーバ２００Ｃまたは第４の常時接続サーバ２００Ｄとの常時接続を行う。これによって、第３のアプリケーションサーバ３００Ｃは、第３の常時接続サーバ２００Ｃまたは第４の常時接続サーバ２００Ｄを介して、テレビ１００Ｃに各種のデータをＰＵＳＨすることができるようになる。すなわち、テレビ用のサービスを利用する複数のクライアント１００は、第３の常時接続サーバ２００Ｃまたは第４の常時接続サーバ２００Ｄを介して、第３のアプリケーションサーバ３００ＣからのデータＰＵＳＨを受け付ける。

このようにして、クライアント１００は、自身が利用するサービスに対応する常時接続サーバ２００を介して、アプリケーションサーバ３００とデータをやりとりする。本実施の形態においては、クライアント１００とアプリケーションサーバ３００との組み合わせに対して接続ＩＤが設定される。そして、接続ＩＤと常時接続サーバ２００との対応関係が、接続ＩＤ／ノード対応関係ＤＢ７００に格納され。

さらに、本実施の形態においては、監視サーバ８００が、接続ＩＤ／ノード対応関係ＤＢ７００を参照することによって、一部の常時接続サーバ２００だけに負荷が集中していないか監視している。換言すれば、監視サーバ８００は、一部のサービスに関する負荷が、当該一部のサービスに割り当てられている常時接続サーバ２００の数に対して、大き過ぎないか否かを判断する。

そして、監視サーバ８００は、負荷が集中している常時接続サーバ２００に対応するサービス（たとえば、第１のサービス）に割り当てられる常時接続サーバ２００の数を増やし、負荷が集中していない常時接続サーバ２００に対応するサービス（第２のサービス）に割り当てられる常時接続サーバ２００の数を減らす。本実施の形態においては、監視サーバ８００は、サービス／ノード対応関係ＤＢ６００における、第２のサービスに割り当てられていた常時接続サーバ２００の対応先を第１のサービスに変更する。

すなわち、本実施の形態にかかるネットワークシステム１では、アプリケーションサーバ３００またはサービスと常時接続サーバ２００とが対応づけられているため、一部のサービスのみに対応する常時接続サーバ２００をスリープさせたりメンテナンスしたり、一部のサービスのみに対応する常時接続サーバ２００のスペックを高くしたり低くしたり、一部のサービスのみに対応する常時接続サーバ２００の台数を増やしたり減らしたりすることができる。

そして、動的に、アプリケーションサーバ３００またはサービスと常時接続サーバ２００との関係を変更することができるため、人気のサービスのみにアクセスが集中することによってクライアント１００がサービスを利用できなくなる可能性や、常時接続によるデータの送受信がスムーズに行えなくなる可能性を低減することができる。つまり、本実施の形態にかかるネットワークシステム１では、サービス毎に常時接続サーバ２００をメンテナンスすることを可能にしつつ、一部の常時接続サーバ２００のみに負荷が集中する可能性を低減することができる。

以下、このような機能を実現するためのネットワークシステム１の具体的な構成について詳述する。
＜クライアント１００のハードウェア構成＞

まず、クライアント１００のハードウェア構成の一態様について説明する。図２は、本実施の形態にかかるクライアント１００のハードウェア構成を表わすブロック図である。

図２を参照して、クライアント１００は、主たる構成要素として、ＣＰＵ１１０と、メモリ１２０と、入出力部１３０と、家電制御回路１５０と、通信インターフェイス１６０とを含む。

ＣＰＵ１１０は、メモリ１２０あるいは外部の記憶媒体に記憶されているプログラムを実行することによって、クライアント１００の各部を制御する。より詳細には、ＣＰＵ１１０は、メモリ１２０のプログラムを実行することによって後述するクライアントＡＰＰ（Application software）およびクライアントＡＰＩ（Application Programming Interface）１１２（図１３を参照。）として動作する。より詳細には、クライアントＡＰＰは、家電制御回路１５０を介してクライアント１００の各部を制御する。クライアントＡＰＩ１１２は、後述する通信インターフェイスを介して、ＨＴＴＰプロトコルを使用して通信したり、ＨＴＴＰプロトコル上で利用されるＷｅｂＳｏｃｋｅｔプロトコルを使用して通信したりする。

メモリ１２０は、各種のＲＡＭ（Random Access Memory）、各種のＲＯＭ（Read-Only Memory）や、フラッシュメモリーなどによって実現される。なお、メモリ１２０は、インターフェイスを介して利用される、ＵＳＢ（Universal Serial Bus）（登録商標）メモリ、ＣＤ（Compact Disc）、ＤＶＤ（Digital Versatile Disk）、メモリカード、ハードディスク、ＩＣ（Integrated Circuit）カード、光カード、マスクＲＯＭ、ＥＰＲＯＭ（Erasable Programmable Read Only Memory）、ＥＥＰＲＯＭ（Electronically Erasable Programmable Read-Only Memory）などの記憶媒体などによっても実現される。

メモリ１２０は、ＣＰＵ１１０によって実行されるプログラムや、ＣＰＵ１１０によるプログラムの実行により生成されたデータ、入出力部１３０を介して入力されたデータ、掃除機・エアコン・テレビなどの家電として動作するＡＰＰデータ、クライアントＡＰＰとデータをやり取りしながら常時接続サーバ２００と通信するためのＡＰＩデータを記憶する。ＡＰＰデータは、アプリケーションサーバ３００と情報を送受信するためのサービス接続情報を含む。ＡＰＩデータは、ＷｅｂＳｏｃｋｅｔクライアントＡＰＩ設定情報と、認証情報と、接続先サービス設定情報と、接続状態情報とを含む。

入出力部１３０は、ユーザからの命令を受け付けて、当該命令をＣＰＵ１１０に入力する。また、入出力部１３０は、ＣＰＵ１１０からの信号に基づいて、文字や画像や音声を出力する。

家電制御回路１５０は、ＣＰＵ１１０からの信号に基づいて、掃除機１００Ａ・エアコン１００Ｂ・テレビ１００Ｃなどの家電としてのクライアント１００の各部（モータなど）を制御する。

通信インターフェイス１６０は、ＩＥＥＥ８０２．１１ａ／ｂ／ｇ／ｎ／ａｃなどの無線ＬＡＮ通信、ＺｉｇＢｅｅ(登録商標)、ＢｌｕｅＴｏｏｔｈ（登録商標）、あるいは、イーサネット（登録商標）などの有線ＬＡＮなどの通信モジュールによって実現される。通信インターフェイス１６０は、有線通信あるいは無線通信によって他の装置との間でデータをやり取りする。ＣＰＵ１１０は、通信インターフェイス１６０を介して、他の装置からプログラム、制御命令、画像データ、テキストデータ、音声データなどを受信したり、他の装置に画像データ、テキストデータ、音声データなどを送信したりする。
＜常時接続サーバ２００のハードウェア構成＞

次に、常時接続サーバ２００のハードウェア構成の一態様について説明する。図３は、本実施の形態にかかる常時接続サーバ２００のハードウェア構成を表わすブロック図である。

図３を参照して、常時接続サーバ２００は、主たる構成要素として、ＣＰＵ２１０と、メモリ２２０と、入出力部２３０と、通信インターフェイス２６０とを含む。常時接続サーバ２００のハードウェア構成は、クライアント１００のハードウェア構成と比較して、家電の各部を制御するための家電制御回路１５０を有さない点、ＣＰＵ２１０の動作、メモリ２２０に格納されているデータに関して異なる。よって、以下では主に、ＣＰＵ２１０の動作とメモリ２２０が記憶するデータとについて説明するものとし、その他のハードウェア構成については説明を繰り返さない。

ＣＰＵ２１０は、メモリ２２０あるいは外部の記憶媒体に記憶されているプログラムを実行することによって、常時接続サーバ２００の各部を制御する。具体的には、ＣＰＵ２１０は、メモリ２２０に記憶されているプログラムを実行することによって、後述するＷＳサーバコア２１２（図１３を参照。）として動作する。ＷＳサーバコア２１２は、ソフトウェアとしての常時接続サーバのことを言い、ＷｅｂＳｏｃｋｅｔプロトコルを使用してクライアント１００との常時接続通信を制御したり、ＨＴＴＰプロトコルを使用して第１の補助サーバ４００、第２の補助サーバ５００、複数のアプリケーションサーバ３００との通信を制御したりする。

メモリ２２０は、ＣＰＵ２１０によって実行されるプログラムや、ＣＰＵ２１０によるプログラムの実行により生成されたデータ、入出力部２３０を介して入力されたデータ、サービスマスタ情報、一時認証情報、接続状態管理情報、接続グループ情報、接続グループ参加情報などを記憶する。
＜アプリケーションサーバ３００のハードウェア構成＞

次に、アプリケーションサーバ３００のハードウェア構成の一態様について説明する。図４は、本実施の形態にかかるアプリケーションサーバ３００のハードウェア構成を表わすブロック図である。

図４を参照して、アプリケーションサーバ３００は、主たる構成要素として、ＣＰＵ３１０と、メモリ３２０と、入出力部３３０と、通信インターフェイス３６０とを含む。アプリケーションサーバ３００のハードウェア構成は、常時接続サーバ２００のハードウェア構成と比較して、ＣＰＵ３１０の動作、メモリ３２０に格納されているデータに関して異なる。よって、以下では主に、ＣＰＵ３１０の動作と、メモリ３２０が記憶するデータとについて説明するものとし、その他のハードウェア構成については説明を繰り返さない。

ＣＰＵ３１０は、メモリ３２０あるいは外部の記憶媒体に記憶されているプログラムを実行することによって、アプリケーションサーバ３００の各部を制御する。具体的には、ＣＰＵ３１０は、メモリ３２０に記憶されているプログラムを実行することによって、後述するサーバＡＰＰおよびサーバＡＰＩ３１２（図１３を参照。）として動作する。

サーバＡＰＰは、ソフトウェアとしてのアプリケーションサーバのことを言い、クライアント１００やスマートフォンなどにサービスを提供する。サーバＡＰＩ３１２は、ＨＴＴＰプロトコルを利用して、第２の補助サーバ５００または常時接続サーバ２００との通信を制御する。

メモリ３２０は、ＣＰＵ３１０によって実行されるプログラムや、ＣＰＵ３１０によるプログラムの実行により生成されたデータ、入出力部３３０を介して入力されたデータ、アプリケーションサーバ３００として動作するＡＰＰデータ、サーバＡＰＰとデータをやり取りしながら常時接続サーバ２００と通信するためのＡＰＩデータを記憶する。ＡＰＰデータは、自身が管理すべきクライアント１００に関する情報を含むクライアント情報と、常時接続中のクライアント１００との接続に関するクライアント接続情報と、新たに常時接続を開始するための接続確率テンポラリ情報とを含む。ＡＰＩデータは、ＷｅｂＳｏｃｋｅｔサーバＡＰＩ設定情報と、認証管理情報と、サービス設定情報と、クライアント接続状態情報とを含む。
＜第１の補助サーバ４００のハードウェア構成＞

次に、第１の補助サーバ４００のハードウェア構成の一態様について説明する。図５は、本実施の形態にかかる第１の補助サーバ４００のハードウェア構成を表わすブロック図である。

図５を参照して、第１の補助サーバ４００は、主たる構成要素として、ＣＰＵ４１０と、メモリ４２０と、入出力部４３０と、通信インターフェイス４６０とを含む。第１の補助サーバ４００のハードウェア構成は、常時接続サーバ２００のハードウェア構成と比較して、ＣＰＵ４１０の動作、メモリ４２０に格納されているデータに関して異なる。よって、以下では主に、ＣＰＵ４１０の動作と、メモリ４２０が記憶するデータとについて説明するものとし、その他のハードウェア構成については説明を繰り返さない。

ＣＰＵ４１０は、メモリ４２０あるいは外部の記憶媒体に記憶されているプログラムを実行することによって、第１の補助サーバ４００の各部を制御する。具体的には、ＣＰＵ４１０は、メモリ４２０に記憶されているプログラムを実行することによって、ノードリスト提供機能を実現する。たとえば、ＣＰＵ１１０は、サービス／ノード対応関係ＤＢ６００を参照することによってノードリストを作成する。また、ＣＰＵ１１０は、通信インターフェイス４６０を介して、作成されたノードリストをクライアント１００に送信する。

メモリ４２０は、ＣＰＵ４１０によって実行されるプログラムや、ＣＰＵ４１０によるプログラムの実行により生成されたデータ、入出力部４３０を介して入力されたデータなどを記憶する。
＜サービス／ノード対応関係ＤＢ＞

次に、本実施の形態にかかるネットワークシステム１で利用されるサービス／ノード対応関係ＤＢ６００について説明する。図６は、本実施の形態にかかるサービス／ノード対応関係ＤＢ６００に含まれるデータの構造を示すイメージ図である。

図６を参照して、サービス／ノード対応関係ＤＢ６００は、アプリケーションサーバ３００が提供するサービスと常時接続サーバ２００のノードに関する情報との対応関係６２０を含む。

ここで、ノードに関する情報は、常時接続サーバ２００のアドレスであってもよいし、常時接続サーバ２００を特定するＩＤであってもよい。ノードに関する情報が、常時接続サーバ２００を特定するＩＤである場合には、サービス／ノード対応関係ＤＢ６００Ｂは、常時接続サーバ２００を特定するＩＤと常時接続サーバ２００のアドレスとの対応関係も記憶する。

これによって、第１の補助サーバ４００が、サービス／ノード対応関係ＤＢ６００を参照することにより、クライアント１００からの要求に応じてクライアント１００が利用しようとするサービスに対応するノードのリストを作成することができる。本実施の形態においては、第１の補助サーバ４００は、クライアント１００から指定されたサービスに対応する常時接続サーバ２００のアドレスをサービス／ノード対応関係ＤＢ６００から抽出することによって、ノードリストを作成する。

そして、第１の補助サーバ４００は、ノードリストとして、たとえば、"handshakeUrl":["ws://example01.com:18080/cpush-server/echo","ws://example02.com:18080/cpush-server/echo"]というデータをクライアント１００に送信する。
＜第２の補助サーバ５００のハードウェア構成＞

次に、第２の補助サーバ５００のハードウェア構成の一態様について説明する。図７は、本実施の形態にかかる第２の補助サーバ５００のハードウェア構成を表わすブロック図である。

図７を参照して、第２の補助サーバ５００は、主たる構成要素として、ＣＰＵ５１０と、メモリ５２０と、入出力部５３０と、通信インターフェイス５６０とを含む。第２の補助サーバ５００のハードウェア構成は、常時接続サーバ２００のハードウェア構成と比較して、ＣＰＵ５１０の動作、メモリ５２０に格納されているデータに関して異なる。よって、以下では主に、ＣＰＵ５１０の動作と、メモリ５２０が記憶するデータとについて説明するものとし、その他のハードウェア構成については説明を繰り返さない。

ＣＰＵ５１０は、メモリ５２０あるいは外部の記憶媒体に記憶されているプログラムを実行することによって、第２の補助サーバ５００の各部を制御する。具体的には、ＣＰＵ５１０は、メモリ５２０に記憶されているプログラムを実行することによって、後述するデータ割り振り機能５１１（図１３を参照。）を実現する。

メモリ５２０は、ＣＰＵ５１０によって実行されるプログラムや、ＣＰＵ５１０によるプログラムの実行により生成されたデータ、入出力部５３０を介して入力されたデータなどを記憶する。
＜接続ＩＤ／ノード対応関係ＤＢ＞

次に、本実施の形態にかかるネットワークシステム１で利用される接続ＩＤ／ノード対応関係ＤＢ７００について説明する。図８は、本実施の形態にかかる接続ＩＤ／ノード対応関係ＤＢ７００に含まれるデータの構造を示すイメージ図である。

図８を参照して、接続ＩＤ／ノード対応関係ＤＢ７００は、常時接続においてクライアント１００を特定するための接続ＩＤと常時接続サーバ２００が実現するノードとの対応関係７２０を含む。これによって、第２の補助サーバ５００は、複数のクライアント１００の各々がどの常時接続サーバ２００と常時接続しているかを認識することができる。つまり、第２の補助サーバ５００は、接続ＩＤ／ノード対応関係ＤＢ７００を参照することによって、アプリケーションサーバ３００からのクライアント１００へのＰＵＳＨデータをどの常時接続サーバ２００に割り振るべきか特定することができる。
＜監視サーバ８００のハードウェア構成＞

次に、監視サーバ８００のハードウェア構成の一態様について説明する。図９は、本実施の形態にかかる監視サーバ８００（８００Ｂ，８００Ｃ，８００Ｄ，８００Ｅ）のハードウェア構成を表わすブロック図である。

図９を参照して、監視サーバ８００は、主たる構成要素として、ＣＰＵ８１０と、メモリ８２０と、入出力部８３０と、通信インターフェイス８６０とを含む。監視サーバ８００のハードウェア構成は、常時接続サーバ２００のハードウェア構成と比較して、ＣＰＵ８１０の動作、メモリ８２０に格納されているデータに関して異なる。よって、以下では主に、ＣＰＵ８１０の動作と、メモリ８２０が記憶するデータとについて説明するものとし、その他のハードウェア構成については説明を繰り返さない。

ＣＰＵ８１０は、メモリ８２０あるいは外部の記憶媒体に記憶されているプログラムを実行することによって、監視サーバ８００の各部を制御する。具体的には、ＣＰＵ８１０は、メモリ８２０に記憶されているプログラムを実行することによって、複数の常時接続サーバ２００の各々の接続クライアントの個数、ＰＵＳＨ頻度、送信データ量、負荷などを測定したり取得したりする。そして、ＣＰＵ８１０は、複数の常時接続サーバ２００の各々の接続クライアントの個数、ＰＵＳＨ頻度、送信データ量、負荷などが所定値を超えているか否かを判断する。ＣＰＵ８１０は、複数の常時接続サーバ２００の各々の接続クライアントの個数、ＰＵＳＨ頻度、送信データ量、負荷などが所定値を超えている場合、サービス／ノード対応関係ＤＢ６００におけるサービスとノードとの組み合わせを変更する。

メモリ５２０は、ＣＰＵ５１０によって実行されるプログラムや、ＣＰＵ５１０によるプログラムの実行により生成されたデータ、入出力部５３０を介して入力されたデータなどを記憶する。
＜常時接続開始に関するネットワークシステム１の機能構成＞

次に、本実施の形態にかかる常時接続開始に関するネットワークシステム１全体の機能構成について説明する。図１０は、第１の実施の形態にかかるネットワークシステム１全体の機能構成を示す第１のブロック図である。図１１は、第１の実施の形態にかかるネットワークシステム１全体の機能構成を示す第２のブロック図である。図１２は、第１の実施の形態にかかるネットワークシステム１全体の機能構成を示す第３のブロック図である。

図１０を参照して、クライアント１００Ａ〜１００Ｃの各々は、常時接続を開始する際に、ＨＴＴＰプロトコルを利用して、第１の補助サーバ４００にノードリストを要求する。具体的には、第１のサービスを利用しようとするクライアント１００Ａは、第１のサービスを特定するサービスＩＤを第１の補助サーバ４００に送信する。

第１の補助サーバ４００は、サービス／ノード対応関係ＤＢ６００を参照して、第１のサービスに関するノードリストを作成する。ノードリストは、第１のサービスに対応する常時接続サーバ２００のアドレスを含む。第１の補助サーバ４００は、ノードリストをクライアント１００Ａに送信する。たとえば、第１の補助サーバは、ノードリストとして、"handshakeUrl":["ws://example01.com:18080/cpush-server/echo","ws://example02.com:18080/cpush-server/echo"]というデータをクライアント１００に送信する。

図１１に示すように、クライアント１００Ａは、ノードリストを参照して、第１のサービスに対応する常時接続サーバ２００Ａに接続を試みる。常時接続の開始時の処理については、後述する。

同様にして、図１０を参照して、第２のサービスを利用しようとするクライアント１００Ｂは、第２のサービスを特定するサービスＩＤを第１の補助サーバ４００に送信する。第１の補助サーバ４００は、サービス／ノード対応関係ＤＢ６００を参照して、第２のサービスに関するノードリストを作成する。ノードリストは、第２のサービスに対応する常時接続サーバ２００のアドレスを含む。第１の補助サーバ４００は、ノードリストをクライアント１００Ｂに送信する。たとえば、第１の補助サーバは、ノードリストとして、"handshakeUrl":["ws://example03.com:18080/cpush-server/echo"]というデータをクライアント１００に送信する。図１１に示すように、クライアント１００Ｂは、ノードリストを参照して、第２のサービスに対応する常時接続サーバ２００Ｄに接続を試みる。常時接続の開始時の処理については、後述する。

同様にして、図１０を参照して、第３のサービスを利用しようとするクライアント１００Ｃは、第３のサービスを特定するサービスＩＤを第１の補助サーバ４００に送信する。第１の補助サーバ４００は、サービス／ノード対応関係ＤＢ６００を参照して、第３のサービスに関するノードリストを作成する。ノードリストは、第３のサービスに対応する常時接続サーバ２００のアドレスを含む。第１の補助サーバ４００は、ノードリストをクライアント１００Ｃに送信する。たとえば、第１の補助サーバは、ノードリストとして、"handshakeUrl":["ws://example04.com:18080/cpush-server/echo"]というデータをクライアント１００に送信する。図１１に示すように、クライアント１００Ｃは、ノードリストを参照して、第３のサービスに対応する常時接続サーバ２００Ｃに接続を試みる。常時接続の開始時の処理については、後述する。

このようにして、複数のクライアント１００の各々は、自身が利用するサービスに対応する常時接続サーバ２００との常時接続を確立する。たとえば、図１２に示すように、複数のクライアント１００Ａ〜１００Ｇの各々が、複数の常時接続サーバ２００のうちのクライアント１００Ａ〜１００Ｇの各々が利用するサービスに対応する常時接続サーバ２００との常時接続を確立する。

ここでは、第１のサービスに第１の常時接続サーバ２００Ａと第２の常時接続サーバ２００Ｂとが対応付けられている。そして、第１のサービスを利用するクライアント１００Ａ，１００Ｄ，１００Ｅが、第１の常時接続サーバ２００Ａまたは第２の常時接続サーバ２００Ｂのいずれかと常時接続する。これによって、第１のサービスを提供するアプリケーションサーバ３００Ａは、第１の常時接続サーバ２００Ａまたは第２の常時接続サーバ２００Ｂを介して、クライアント１００Ａ，１００Ｄ，１００ＥにデータをＰＵＳＨすることができる。

同様に、第２のサービスに第３の常時接続サーバ２００Ｃと第４の常時接続サーバ２００Ｄとが対応付けられている。そして、第２のサービスを利用するクライアント１００Ｂ，１００Ｆが、第３の常時接続サーバ２００Ｃまたは第４の常時接続サーバ２００Ｄのいずれかと常時接続する。これによって、第２のサービスを提供するアプリケーションサーバ３００Ｂは、第３の常時接続サーバ２００Ｃまたは第４の常時接続サーバ２００Ｄを介して、クライアント１００Ｂ，１００ＦにデータをＰＵＳＨすることができる。

同様に、第３のサービスに第３の常時接続サーバ２００Ｃと第４の常時接続サーバ２００Ｄとが対応付けられている。そして、第３のサービスを利用するクライアント１００Ｃ，１００Ｇが、第３の常時接続サーバ２００Ｃまたは第４の常時接続サーバ２００Ｄのいずれかと常時接続する。これによって、第３のサービスを提供するアプリケーションサーバ３００Ｃは、第３の常時接続サーバ２００Ｃまたは第４の常時接続サーバ２００Ｄを介して、クライアント１００Ｃ，１００ＧにデータをＰＵＳＨすることができる。
＜常時接続に関する装置間のデータのやり取り＞

ここで、本実施の形態にかかるネットワークシステム１における常時接続に関する装置間のデータのやり取りについて詳細に説明する。なお、図１３は、本実施の形態にかかるネットワークシステム１における常時接続に関する装置間のデータのやり取りの処理手順を示すシーケンス図である。

図１３を参照して、クライアント１００によって実現されるクライアントＡＰＩ１１２は、ＨＴＴＰプロトコルを使用して、通信インターフェイス１６０を介して、アプリケーションサーバ３００に認証情報を要求する（ステップＳ００２）。このとき、クライアントＡＰＩ１１２は、アプリケーションサーバ３００に、認証に利用されるクライアントＩＤを送信する。アプリケーションサーバ３００のサーバＡＰＩ３１２は、当該要求に応じてＨＴＴＰプロトコルを使用して、通信インターフェイス３６０を介してクライアント１００に認証情報を送信する（ステップＳ００４）。

サーバＡＰＩ３１２は、通信インターフェイス３６０を介して、常時接続サーバ２００にも認証情報を送信する（ステップＳ００６）。常時接続サーバ２００のＷＳサーバコア２１２は、アプリケーションサーバ３００から受信した認証情報を保存する（ステップＳ００８）。

クライアント１００は、第１の補助サーバ４００からノードリストを取得する（ステップＳ００９）。より詳細には、クライアント１００は、ＨＴＴＰプロトコルを利用して、第１の補助サーバ４００にサービスＩＤを送信する。第１の補助サーバ４００は、サービス／ノード対応関係ＤＢを参照して、サービスに対応するノードリストを作成し、当該ノードリストをクライアント１００に送信する。クライアント１００は、ノードリストから１つの常時接続サーバ２００を選択する。

クライアント１００に選択された常時接続サーバ２００とクライアント１００とは、ＨＴＴＰプロトコルを使用して、ＷｅｂＳｏｃｋｅｔを利用した常時接続状態を確立する（ステップＳ０１０、ステップＳ０１２）。具体的には、クライアントＡＰＩ１１２は、ＨＴＴＰプロトコルを使用して、通信インターフェイス１６０を介して常時接続サーバ２００にハンドシェイク要求を送る。ＷＳサーバコア２１２は、通信インターフェイス２６０を介してクライアント１００にハンドシェイク応答を返す。これによって、クライアント１００と常時接続サーバ２００との間で、ＷｅｂＳｏｃｋｅｔプロトコルによる常時接続が有効になる。

クライアントＡＰＩ１１２は、通信インターフェイス１６０を介して認証情報を常時接続サーバ２００に送信する（ステップＳ０１４）。ＷＳサーバコア２１２は、クライアント１００からの認証情報と予め保存している認証情報とに基づいて、クライアント１００を認証する（ステップＳ０１６）。認証に成功すると、ＷＳサーバコア２１２は、アプリケーションサーバ３００がクライアント１００を識別するための接続ＩＤを発行する（ステップＳ０１８）。

すなわち、ＷＳサーバコア２１２は、常時接続中のクライアント１００と接続ＩＤとの対応関係を、接続状態管理情報として記憶する。クライアント１００は、接続ＩＤを受信して、記憶する（ステップＳ０２０）。アプリケーションサーバ３００も、接続ＩＤを受信して、記憶する（ステップＳ０２２）。このとき、ＷＳサーバコア２１２は、通信インターフェイス２６０を介して、接続ＩＤと常時接続サーバ２００を特定する情報（ノードに関する情報）とアプリケーションサービスを特定する情報との対応関係を接続ＩＤ／ノード対応関係ＤＢ７００に登録する。

その後、サーバＡＰＩ３１２は、サーバＡＰＰ３１１からの要求に応じて、データ本体と送り先のクライアント１００を特定するための接続ＩＤとを通信インターフェイス３６０を介して常時接続サーバ２００に送信する（ステップＳ０３２）。

本実施の形態においては、ステップＳ０３３として、アプリケーションサーバ３００からのデータは、第２の補助サーバ５００が受信する。第２の補助サーバ５００の割り振り機能５１１は、接続ＩＤ／ノード対応関係ＤＢ７００を参照して、送信先のクライアント１００に対応する常時接続サーバ２００を特定する。第２の補助サーバ５００のＣＰＵ５１０は、通信インターフェイス５６０を介して、特定された常時接続サーバ２００にデータを送信する。

常時接続サーバ２００は、第１の補助サーバ４００からデータ本体と接続ＩＤとを受信する（ステップＳ０３４）。ＷＳサーバコア２１２は、接続状態管理情報を参照して、接続ＩＤに基づいてクライアント１００を特定する（ステップＳ０３６）。ＷＳサーバコア２１２は、通信インターフェイス２６０を介して、データ本体をクライアント１００にＰＵＳＨ送信する（ステップＳ０３８）。

クライアント１００は、データ本体を受信する（ステップＳ０４０）。クライアント１００は、ＷｅｂＳｏｃｋｅｔプロトコルを使用して、受信結果を常時接続サーバ２００に送信する（ステップＳ０４２）。常時接続サーバ２００は、受信結果を受信すると、当該受信結果をアプリケーションサーバ３００に送信する（ステップＳ０４４）。アプリケーションサーバ３００は、受信結果を受信する（ステップＳ０４６）。
＜サービス／ノード対応関係の変更に関するネットワークシステム１の機能構成＞

次に、本実施の形態にかかるサービス／ノード関係の変更に関するネットワークシステム１全体の機能構成について説明する。図１４は、第１の実施の形態にかかるネットワークシステム１全体の機能構成を示す第４のブロック図である。図１５は、第１の実施の形態にかかるネットワークシステム１全体の機能構成を示す第５のブロック図である。

図１４を参照して、第１のサービスに対応する第１の常時接続サーバ２００Ａと第２の常時接続サーバ２００Ｂが多くのクライアント１００と常時接続し、第２のサービスに対応する第３の常時接続サーバ２００Ｃと第４の常時接続サーバ２００Ｄとが少ないクライアント１００と常時接続する場合がある。換言すれば、第１のサービスに対応する常時接続サーバ２００一台当たりの常時接続中のクライアント１００の個数と、第２のサービスに対応する常時接続サーバ２００一台当たりの常時接続中のクライアント１００の個数とが大きく異なる場合がある。

本実施の形態にかかる監視サーバ８００は、接続ＩＤ／ノード対応関係ＤＢ７００を参照することによって、接続中のクライアント１００の個数が常時接続サーバ２００によって大きく異なっているか否かを判断する。そして、監視サーバ８００は、判断結果に基づいて、接続中のクライアントの個数が常時接続サーバ２００間で大きく異ならないように、サービス／ノードの対応関係を変更する。

たとえば、監視サーバ８００は、複数の常時接続サーバ２００毎に接続中のクライアント１００の個数が所定値よりも多いか否かを判断してもよい。そして、いずれかの常時接続サーバ２００の接続中のクライアントの個数が所定値よりも多い場合に、監視サーバ８００は、サーバ／ノード対応関係Ｄ６００において、接続中のクライアントの個数が所定値よりも多い第１の常時接続サーバ２００Ａに対応するサービスに対応する常時接続サーバ２００を増やす。具体的には、接続中のクライアント１００の個数が少ない第３の常時接続サーバ２００Ｃに対応するサービスを、接続中のクライアントの個数が所定値よりも多い第１の常時接続サーバ２００Ａに対応するサービスへと変更する。あるいは、監視サーバ８００は、休止中の常時接続サーバ２００を起動させて、当該常時接続サーバ２００に対応するサービスを接続中のクライアントの個数が所定値よりも多い第１の常時接続サーバ２００Ａに対応するサービスに設定する。

あるいは、監視サーバ８００は、接続中のクライアント１００の個数が多い第１の常時接続サーバ２００Ａと、接続中のクライアント１００の個数が少ない第３の常時接続サーバ２００とに関して、第１の常時接続サーバ２００の接続中のクライアントの個数が第３の常時接続サーバ２００Ｃの接続中のクライアント１００の個数の２倍以上であるか否かを判断してもよい。そして、第１の常時接続サーバ２００Ａの接続中のクライアントの個数が第３の常時接続サーバ２００Ｃの接続中のクライアント１００の個数の２倍以上である場合に、監視サーバ８００は、サーバ／ノード対応関係Ｄ６００において、第３の常時接続サーバ２００Ｃに対応するサービスに対応する常時接続サーバ２００を減らし、第１の常時接続サーバ２００Ａに対応するサービスに対応する常時接続サーバ２００を増やしてもよい。

これによって、図１５に示すように、第１のサービスを利用するクライアント１００が第３の常時接続サーバ２００Ｃの方に流れ、第２および第３のサービスを利用するクライアント１００が第４の常時接続サーバ２００Ｄに集まる。すなわち、人気のサービス（たとえば、第１のサービス）に対応する常時接続サーバ２００（たとえば、第１の常時接続サーバ２００Ａと第２の常時接続サーバ２００Ｂ）だけ、接続中のクライアント１００の個数が増え過ぎることを防止することができる。
＜クライアントにおけるノード選択処理＞

次に、本実施の形態にかかるクライアント１００におけるノード選択処理について説明する。図１６は、本実施の形態にかかるクライアント１００におけるノード選択処理を示すフローチャートである。

図１６を参照して、ＣＰＵ１１０は、メモリ１２０に格納されているプログラムに含まれる指示に基づいて、以下の処理を実行する。ＣＰＵ１１０は、サービスを利用するための常時接続を開始する際に、当該サービスを特定する情報、たとえばサービスＩＤ、を含むノードリスト要求を通信インターフェイス１６０を介して第１の補助サーバ４００に送信する（ステップＳ１０２）。ＣＰＵ１１０は、通信インターフェイス１６０を介して、第１の補助サーバ４００からノードリストを受信したか否かを判断する（ステップＳ１０４）。ＣＰＵ１１０は、第１の補助サーバ４００からノードリストを受信していないとき（ステップＳ１０４にてＮＯの場合）、ステップＳ１０２からの処理を繰り返す。

ＣＰＵ１１０は、第１の補助サーバ４００からノードリストを受信したとき（ステップＳ１０４にてＹＥＳである場合）、当該ノードリストから１つの常時接続サーバ２００を選択する（ステップＳ１０６）。ＣＰＵ１１０は、Ｗｅｂソケットプロトコルを利用して、通信インターフェイス１６０を介して、選択された常時接続サーバ２００との常時接続を開始する（ステップＳ１０８）。すなわち、ＣＰＵ１１０は、図１３におけるステップＳ０１０からの処理を実行する。
＜第１の補助サーバ４００におけるノードリスト提供処理＞

次に、本実施の形態にかかる第１の補助サーバ４００におけるノードリスト提供処理について説明する。図１７は、本実施の形態にかかるクライアント１００におけるノードリスト提供処理を示すフローチャートである。

図１７を参照して、ＣＰＵ４１０は、メモリ４２０に格納されているプログラムに含まれる指示に基づいて、以下の処理を実行する。ＣＰＵ４１０は、通信インターフェイス４６０を介して、クライアント１００からのノードリスト要求を受け付けたか否かを判断する（ステップＳ２０２）。ＣＰＵ４１０は、クライアント１００からノードリスト要求を受信するまで（ステップＳ２０２にてＮＯの場合）、ステップＳ２０２の処理を繰り返す。

ＣＰＵ４１０は、クライアント１００からのノードリスト要求を受信すると（ステップＳ２０２にてＹＥＳである場合）、サービス／ノード対応関係ＤＢ６００を参照することによって、ノードリスト要求に含まれるサービスＩＤに対応する常時接続サーバ２００のアドレスのリストをノードリストとして作成する（ステップＳ２０４）。ＣＰＵ４１０は、通信インターフェイス４６０を介して、ノードリストをクライアント１００に送信する（ステップＳ２０６）。
＜監視サーバ８００におけるサービス/ノード対応関係変更処理＞

次に、本実施の形態にかかる監視サーバ８００におけるサービス／ノード対応関係変更処理について説明する。図１８は、本実施の形態にかかる監視サーバ８００における対応関係変更処理を示すフローチャートである。

図１８を参照して、ＣＰＵ８１０は、メモリ８２０に格納されているプログラムに含まれる指示に基づいて、以下の処理を実行する。ＣＰＵ８１０は、図示しない時計を参照して、前回の対応関係の変更の要否の判断時から所定時間が経過したか否かを判断する（ステップＳ３０２）。ＣＰＵ８１０は、所定時間が経過するまで（ステップＳ３０２にてＮＯの場合）、ステップＳ３０２の処理を繰り返す。

ＣＰＵ８１０は、所定時間が経過した場合（ステップＳ３０２にてＹＥＳである場合）、接続ＩＤ／ノード対応関係ＤＢ７００のデータを取得する（ステップＳ３０４）。ＣＰＵ８１０は、サービスと常時接続サーバ２００と対応関係を変更する必要があるか否かを判断する（ステップＳ３０６）。ここでは、ＣＰＵ８１０は、接続中のクライアント１００の個数が多過ぎる常時接続サーバ２００が無いか否かを判断する。ただし、後述するように、ＣＰＵ８１０は、１つの常時接続サーバ２００当たりのＰＵＳＨ頻度、１つの常時接続サーバ２００当たりの送信データ量、１つの常時接続サーバ２００当たりの負荷などに基づいて、対応関係の変更の要否を判断しても良い。

ＣＰＵ８１０は、サービスと常時接続サーバ２００と対応関係を変更する必要がないと判断した場合（ステップＳ３０８にてＮＯである場合）、ステップＳ３０２からの処理を繰り返す。

ＣＰＵ８１０は、サービスと常時接続サーバ２００と対応関係を変更する必要があると判断した場合（ステップＳ３０８にてＹＥＳである場合）、通信インターフェイス１６０を介して、サービス／ノード対応関係ＤＢ６００におけるサービスＩＤと常時接続サーバ２００との対応関係を変更する（ステップＳ３１０）。ＣＰＵ８１０は、ステップＳ３０２からの処理を繰り返す。

このように、本実施の形態にかかるネットワークシステム１では、アプリケーションサーバ３００またはサービスと常時接続サーバ２００とが対応づけられているため、一部のアプリケーションサーバ３００または一部のサービスのみに関する常時接続サーバ２００をメンテナンスしたり、一部のアプリケーションサーバ３００または一部のサービスのみの常時接続サーバ２００のスペックを高くしたり、一部のアプリケーションサーバ３００または一部のサービスのみに対応する常時接続サーバ２００を増やしたり減らしたりすることができる。

また、動的に、アプリケーションサーバ３００またはサービスと常時接続サーバ２００との関係を変更することができるため、人気のサービスのみにアクセスが集中することによってクライアント１００がサービスを利用できなくなる可能性や、常時接続によるデータの送受信がスムーズに行えなくなる可能性を低減することができる。つまり、本実施の形態にかかるネットワークシステム１では、サービス毎に常時接続サーバ２００をメンテナンスすることを可能にしつつ、一部の常時接続サーバ２００のみに負荷が集中する可能性を低減することができる。
＜第２の実施の形態＞

次に、第２の実施の形態について説明する。第１の実施の形態にかかるネットワークシステム１は、単純にサービス／ノードの対応関係を利用するものであった。しかしながら、本実施の形態にかかるネットワークシステム１は、サービスと課金の有無とで常時接続サーバ２００が異なるものである。

なお、ネットワークシステムの全体構成と、クライアント１００のハードウェア構成と、常時接続サーバ２００のハードウェア構成と、アプリケーションサーバ３００のハードウェア構成と、第１の補助サーバ４００のハードウェア構成と、第２の補助サーバ５００のハードウェア構成と、接続ＩＤ／ノード対応関係ＤＢ７００と、監視サーバ８００のハードウェア構成と、常時接続に関する装置間のデータのやり取りとに関しては、第１の実施の形態のそれらと同様であるため、ここでは説明を繰り返さない。
＜サービス／ノード対応関係ＤＢ＞

まず、本実施の形態にかかるネットワークシステム１で利用されるサービス／ノード対応関係ＤＢ６００Ｂについて説明する。なお、図１９は、第２の実施の形態にかかるネットワークシステム１全体の機能構成を示すブロック図である。

図１９を参照して、サービス／ノード対応関係ＤＢ６００Ｂは、アプリケーションサーバ３００が提供するサービスと常時接続サーバ２００が実現するノードに関する情報と有料サービスか否かを示す情報との対応関係６２０Ｂを含む。さらに、サービス／ノード対応関係ＤＢ６００Ｂは、クライアントを特定するための情報、すなわちクライアントＩＤと課金の有無を示す情報との対応関係６２０Ｃも含む。

なお、ここでのノードに関する情報は、常時接続サーバ２００のアドレスであってもよいし、常時接続サーバ２００を特定するＩＤであってもよい。ノードに関する情報が、常時接続サーバ２００を特定するＩＤである場合には、サービス／ノード対応関係ＤＢ６００Ｂは、常時接続サーバ２００を特定するＩＤと常時接続サーバ２００のアドレスとの対応関係を記憶する。

これによって、第１の補助サーバ４００は、クライアント１００からの要求に応じて、クライアント１００が利用しようとするサービスに対応するノードのリストを作成することができる。本実施の形態においては、第１の補助サーバ４００は、クライアント１００から指定されたサービスに対応する常時接続サーバ２００のアドレスのリストを、サービス／ノード対応関係ＤＢ６００Ｂから抽出する。
＜常時接続開始に関するネットワークシステム１の機能構成＞

次に、本実施の形態にかかる常時接続開始に関するネットワークシステム１全体の機能構成について説明する。

図１９を参照して、クライアント１００Ａ〜１００Ｃの各々は、ＨＴＴＰプロトコルを利用して、第１の補助サーバ４００にノードリストを要求する。具体的には、有料の第１のサービスを利用しようとするクライアント１００Ａは、第１のサービスを特定するサービスＩＤとクライアントＩＤとを第１の補助サーバ４００に送信する。

第１の補助サーバ４００は、サービス／ノード対応関係ＤＢ６００Ｂの対応関係６２０Ｃを参照して、クライアントＩＤに基づいて課金サービスか否かを判断する。第１の補助サーバ４００は、サービス／ノード対応関係ＤＢ６００Ｂの対応関係６２０Ｂを参照して、サービスＩＤと課金の有無とに基づいて、第１のサービスのうちの有料サービス用のノードリストを作成する。第１の補助サーバ４００は、ノードリストをクライアント１００Ａに送信する。たとえば、第１の補助サーバは、ノードリストとして、"handshakeUrl":["ws://example01.com:18080/cpush-server/echo","ws://example02.com:18080/cpush-server/echo"]というデータをクライアント１００に送信する。

クライアント１００Ａは、ノードリストを参照して、有料の第１のサービスに対応する常時接続サーバ２００Ａに接続を試みる。常時接続の開始処理については、第１の実施の形態のそれと同様であるため、ここでは説明を繰り返さない。

同様にして、無料の第１のサービスを利用しようとするクライアント１００Ｂは、第１のサービスを特定するサービスＩＤとクライアントＩＤとを第１の補助サーバ４００に送信する。第１の補助サーバ４００は、サービス／ノード対応関係ＤＢ６００Ｂの対応関係６２０Ｃを参照して、クライアントＩＤに基づいて課金サービスか否かを判断する。第１の補助サーバ４００は、サービス／ノード対応関係ＤＢ６００Ｂの対応関係６２０Ｂを参照して、サービスＩＤと課金の有無とに基づいて、第１のサービスのうちの無料サービス用のノードリストを作成する。

第１の補助サーバ４００は、ノードリストをクライアント１００Ｂに送信する。たとえば、第１の補助サーバは、ノードリストとして、"handshakeUrl":["ws://example03.com:18080/cpush-server/echo"]というデータをクライアント１００に送信する。クライアント１００Ｂは、ノードリストを参照して、無料の第１のサービスに対応する常時接続サーバ２００Ｄに接続を試みる。常時接続の開始処理については、第１の実施の形態のそれと同様であるため、ここでは説明を繰り返さない。

同様にして、無料の第２のサービスを利用しようとするクライアント１００Ｃは、第２のサービスを特定するサービスＩＤとクライアントＩＤとを第１の補助サーバ４００に送信する。第１の補助サーバ４００は、サービス／ノード対応関係ＤＢ６００Ｂの対応関係６２０Ｃを参照して、クライアントＩＤに基づいて課金サービスか否かを判断する。第１の補助サーバ４００は、サービス／ノード対応関係ＤＢ６００Ｂの対応関係６２０Ｂを参照して、サービスＩＤと課金の有無とに基づいて、第２のサービスのうちの無料サービス用のノードリストを作成する。第１の補助サーバ４００は、ノードリストをクライアント１００Ｃに送信する。たとえば、第１の補助サーバは、ノードリストとして、"handshakeUrl":["ws://example04.com:18080/cpush-server/echo"]というデータをクライアント１００に送信する。クライアント１００Ｃは、ノードリストを参照して、無料の第２のサービスに対応する常時接続サーバ２００Ｄに接続を試みる。常時接続の開始処理については、第１の実施の形態のそれと同様であるため、ここでは説明を繰り返さない。

このようにして、複数のクライアント１００の各々は、利用するサービスに対応する常時接続サーバ２００との常時接続を確立する。常時接続開始後の機能および処理は、第１の実施の形態のそれらと同様であるため、ここでは説明を繰り返さない。

換言すれば、第１の実施に形態における第１のサービスが本実施の形態における有料の第１のサービスに対応し、第１の実施に形態における第２のサービスが本実施の形態における無料の第１のサービスに対応し、第１の実施に形態における第３のサービスが本実施の形態における無料の第２のサービスに対応している。
＜第３の実施の形態＞

次に、第３の実施の形態について説明する。第１の実施の形態にかかるネットワークシステム１は、クライアント１００が第１の補助サーバ４００にサービスＩＤを送るものであった。そして、第１の補助サーバ４００が、サービスＩＤに対応するノードリストを作成するものであった。しかしながら、本実施の形態においては、クライアント１００は、サービスＩＤを送らずに、クライアントＩＤを送る。すなわち、第１の補助サーバ４００が、クライアントＩＤに対応するサービスを特定して、当該サービスに対応するノードリストを作成するものである。

なお、ネットワークシステムの全体構成と、クライアント１００のハードウェア構成と、常時接続サーバ２００のハードウェア構成と、アプリケーションサーバ３００のハードウェア構成と、第１の補助サーバ４００のハードウェア構成と、第２の補助サーバ５００のハードウェア構成と、接続ＩＤ／ノード対応関係ＤＢ７００と、監視サーバ８００のハードウェア構成と、常時接続に関する装置間のデータのやり取りとに関しては、第１の実施の形態のそれらと同様であるため、ここでは説明を繰り返さない。
＜サービス／ノード対応関係ＤＢ＞

まず、本実施の形態にかかるネットワークシステム１で利用されるサービス／ノード対応関係ＤＢ６００Ｃについて説明する。なお、図２０は、第３の実施の形態にかかるネットワークシステム１全体の機能構成を示すブロック図である。

図２０を参照して、サービス／ノード対応関係ＤＢ６００Ｃは、アプリケーションサーバ３００が提供するサービスと常時接続サーバ２００が実現するノードに関する情報との対応関係６２０を含む。さらに、サービス／ノード対応関係ＤＢ６００Ｃは、クライアントを特定するための情報、すなわちクライアントＩＤとアプリケーションサーバ３００が提供するサービスとの対応関係６２０Ｄも含む。

なお、ここでのノードに関する情報は、常時接続サーバ２００のアドレスであってもよいし、常時接続サーバ２００を特定するＩＤであってもよい。ノードに関する情報が、常時接続サーバ２００を特定するＩＤである場合には、サービス／ノード対応関係ＤＢ６００Ｃは、常時接続サーバ２００を特定するＩＤと常時接続サーバ２００のアドレスとの対応関係を記憶する。

これによって、第１の補助サーバ４００は、クライアント１００からの要求に応じて、クライアント１００が利用しようとするサービスに対応するノードのリストを作成することができる。本実施の形態においては、第１の補助サーバ４００は、クライアント１００が利用するサービスに対応する常時接続サーバ２００のアドレスのリストを、サービス／ノード対応関係ＤＢ６００Ｃから抽出する。
＜常時接続開始に関するネットワークシステム１の機能構成＞

次に、本実施の形態にかかる常時接続開始に関するネットワークシステム１全体の機能構成について説明する。

図２０を参照して、クライアント１００Ａ〜１００Ｃの各々は、ＨＴＴＰプロトコルを利用して、第１の補助サーバ４００にノードリストを要求する。具体的には、第１のサービスを利用しようとするクライアント１００Ａは、クライアントを特定するためのクライアントＩＤを第１の補助サーバ４００に送信する。

第１の補助サーバ４００は、サービス／ノード対応関係ＤＢ６００Ｃの対応関係６２０Ｄを参照して、クライアントＩＤに対応するサービスＩＤを特定する。そして、第１の補助サーバ４００は、サービス／ノード対応関係ＤＢ６００Ｃの対応関係６２０を参照して、当該サービスＩＤに対応するノードリストを作成する。第１の補助サーバ４００は、ノードリストをクライアント１００Ａに送信する。たとえば、第１の補助サーバは、ノードリストとして、"handshakeUrl":["ws://example01.com:18080/cpush-server/echo","ws://example02.com:18080/cpush-server/echo","ws://example03.com:18080/cpush-server/echo"]というデータをクライアント１００に送信する。

クライアント１００Ａは、ノードリストを参照して、第１のサービスに対応する常時接続サーバ２００Ａに接続を試みる。常時接続の開始処理については、第１の実施の形態のそれと同様であるため、ここでは説明を繰り返さない。

同様にして、第２のサービスを利用しようとするクライアント１００Ｂは、クライアントＩＤを第１の補助サーバ４００に送信する。第１の補助サーバ４００は、サービス／ノード対応関係ＤＢ６００Ｃの対応関係６２０Ｄを参照して、クライアントＩＤに対応するサービスＩＤを特定する。第１の補助サーバ４００は、サービス／ノード対応関係ＤＢ６００Ｃの対応関係６２０を参照して、当該サービスＩＤに対応するノードリストを作成する。第１の補助サーバ４００は、ノードリストをクライアント１００Ｂに送信する。たとえば、第１の補助サーバは、ノードリストとして、"handshakeUrl":["ws://example04.com:18080/cpush-server/echo"]というデータをクライアント１００に送信する。クライアント１００Ｂは、ノードリストを参照して、第２のサービスに対応する常時接続サーバ２００Ｄに接続を試みる。常時接続の開始処理については、第１の実施の形態のそれと同様であるため、ここでは説明を繰り返さない。

同様にして、第３のサービスを利用しようとするクライアント１００Ｃは、クライアントＩＤを第１の補助サーバ４００に送信する。第１の補助サーバ４００は、サービス／ノード対応関係ＤＢ６００Ｂの対応関係６２０Ｄを参照して、クライアントＩＤに対応するサービスＩＤを特定する。第１の補助サーバ４００は、サービス／ノード対応関係ＤＢ６００Ｃの対応関係６２０を参照して、当該サービスＩＤに対応するノードリストを作成する。ここでは、ノードリストは、第３のサービスに対応する第５の常時接続サーバ（図示せず。）のアドレスを含む。第１の補助サーバ４００は、ノードリストをクライアント１００Ｃに送信する。たとえば、第１の補助サーバは、ノードリストとして、"handshakeUrl":["ws://example05.com:18080/cpush-server/echo"]というデータをクライアント１００に送信する。クライアント１００Ｃは、ノードリストを参照して、第３のサービスに対応する第５の常時接続サーバに接続を試みる。常時接続の開始処理については、第１の実施の形態のそれと同様であるため、ここでは説明を繰り返さない。

このようにして、複数のクライアント１００は、複数の常時接続サーバ２００との常時接続を確立する。常時接続開始後の機能および処理は、第１の実施の形態のそれらと同様であるため、ここでは説明を繰り返さない。
＜第４の実施の形態＞

次に、第４の実施の形態について説明する。第２の実施の形態にかかるネットワークシステム１は、クライアント１００が第１の補助サーバ４００にサービスＩＤとクライアントＩＤとを送るものであった。そして、第１の補助サーバ４００が、サービスＩＤとクライアントＩＤに対応するノードリストを作成するものであった。しかしながら、本実施の形態においては、クライアント１００は、サービスＩＤを送らずに、クライアントＩＤを送る。すなわち、第１の補助サーバ４００が、クライアントＩＤに対応するサービスを特定して、当該サービスに対応するノードリストを作成するものである。

なお、ネットワークシステムの全体構成と、クライアント１００のハードウェア構成と、常時接続サーバ２００のハードウェア構成と、アプリケーションサーバ３００のハードウェア構成と、第１の補助サーバ４００のハードウェア構成と、第２の補助サーバ５００のハードウェア構成と、接続ＩＤ／ノード対応関係ＤＢ７００と、監視サーバ８００のハードウェア構成と、常時接続に関する装置間のデータのやり取りとに関しては、第１の実施の形態のそれらと同様であるため、ここでは説明を繰り返さない。
＜サービス／ノード対応関係ＤＢ＞

まず、本実施の形態にかかるネットワークシステム１で利用されるサービス／ノード対応関係ＤＢ６００Ｃについて説明する。なお、図２１は、第４の実施の形態にかかるネットワークシステム１全体の機能構成を示すブロック図である。

図２１を参照して、サービス／ノード対応関係ＤＢ６００Ｄは、アプリケーションサーバ３００が提供するサービスと常時接続サーバ２００が実現するノードに関する情報と有料サービスか否かを示す情報との対応関係６２０Ｂを含む。さらに、サービス／ノード対応関係ＤＢ６００Ｄは、クライアントを特定するための情報、すなわちクライアントＩＤとアプリケーションサーバ３００が提供するサービスと課金の有無を示す情報との対応関係６２０Ｅも含む。

なお、ここでのノードに関する情報は、常時接続サーバ２００のアドレスであってもよいし、常時接続サーバ２００を特定するＩＤであってもよい。ノードに関する情報が、常時接続サーバ２００を特定するＩＤである場合には、サービス／ノード対応関係ＤＢ６００Ｄは、常時接続サーバ２００を特定するＩＤと常時接続サーバ２００のアドレスとの対応関係を記憶する。

これによって、第１の補助サーバ４００は、クライアント１００からの要求に応じて、クライアント１００が利用しようとするサービスに対応するノードのリストを作成することができる。本実施の形態においては、第１の補助サーバ４００は、クライアント１００が利用するサービスに対応する常時接続サーバ２００のアドレスのリストを、サービス／ノード対応関係ＤＢ６００Ｄから抽出する。
＜常時接続開始に関するネットワークシステム１の機能構成＞

次に、本実施の形態にかかる常時接続開始に関するネットワークシステム１全体の機能構成について説明する。

図２１を参照して、クライアント１００Ａ〜１００Ｃの各々は、ＨＴＴＰプロトコルを利用して、第１の補助サーバ４００にノードリストを要求する。具体的には、有料の第１のサービスを利用しようとするクライアント１００Ａは、クライアントを特定するためのクライアントＩＤを第１の補助サーバ４００に送信する。

第１の補助サーバ４００は、サービス／ノード対応関係ＤＢ６００Ｄの対応関係６２０Ｅを参照して、クライアントＩＤに対応するサービスＩＤと課金の有無とを特定する。そして、第１の補助サーバ４００は、サービス／ノード対応関係ＤＢ６００Ｄの対応関係６２０Ｂを参照して、当該サービスＩＤと課金の有無に対応するノードリストを作成する。ここでは、ノードリストは、有料の第１のサービスに対応する第１の常時接続サーバ２００Ａのアドレスと、第２の常時接続サーバ２００Ｂのアドレスとを含む。第１の補助サーバ４００は、ノードリストをクライアント１００Ａに送信する。たとえば、第１の補助サーバは、ノードリストとして、"handshakeUrl":["ws://example01.com:18080/cpush-server/echo","ws://example02.com:18080/cpush-server/echo"]というデータをクライアント１００に送信する。

クライアント１００Ａは、ノードリストを参照して、有料の第１のサービスに対応する常時接続サーバ２００Ａに接続を試みる。常時接続の開始処理については、第１の実施の形態のそれと同様であるため、ここでは説明を繰り返さない。

同様にして、無料の第１のサービスを利用しようとするクライアント１００Ｂは、クライアントＩＤを第１の補助サーバ４００に送信する。第１の補助サーバ４００は、サービス／ノード対応関係ＤＢ６００Ｄの対応関係６２０Ｅを参照して、クライアントＩＤに対応するサービスＩＤと課金の有無とを特定する。第１の補助サーバ４００は、サービス／ノード対応関係ＤＢ６００Ｄの対応関係６２０Ｂを参照して、当該サービスＩＤと課金の有無に対応するノードリストを作成する。ここでは、ノードリストは、無料の第１のサービスに対応する第３の常時接続サーバ２００Ｃのアドレスを含む。第１の補助サーバ４００は、ノードリストをクライアント１００Ｂに送信する。たとえば、第１の補助サーバは、ノードリストとして、"handshakeUrl":["ws://example03.com:18080/cpush-server/echo"]というデータをクライアント１００に送信する。クライアント１００Ｂは、ノードリストを参照して、無料の第１のサービスに対応する常時接続サーバ２００Ｃに接続を試みる。常時接続の開始処理については、第１の実施の形態のそれと同様であるため、ここでは説明を繰り返さない。

同様にして、無料の第２のサービスを利用しようとするクライアント１００Ｃは、クライアントＩＤを第１の補助サーバ４００に送信する。第１の補助サーバ４００は、サービス／ノード対応関係ＤＢ６００Ｄの対応関係６２０Ｅを参照して、クライアントＩＤに対応するサービスＩＤと課金の有無とを特定する。第１の補助サーバ４００は、サービス／ノード対応関係ＤＢ６００Ｄの対応関係６２０Ｂを参照して、当該サービスＩＤと課金の有無とに対応するノードリストを作成する。ここでは、ノードリストは、無料の第２のサービスに対応する第４の常時接続サーバ２００のアドレスを含む。第１の補助サーバ４００は、ノードリストをクライアント１００Ｃに送信する。たとえば、第１の補助サーバは、ノードリストとして、"handshakeUrl":["ws://example04.com:18080/cpush-server/echo"]というデータをクライアント１００に送信する。クライアント１００Ｃは、ノードリストを参照して、無料の第２のサービスに対応する常時接続サーバ２００Ｄに接続を試みる。常時接続の開始処理については、第１の実施の形態のそれと同様であるため、ここでは説明を繰り返さない。

このようにして、複数のクライアント１００は、複数の常時接続サーバ２００との常時接続を確立する。常時接続開始後の機能および処理は、第１の実施の形態のそれらと同様であるため、ここでは説明を繰り返さない。

換言すれば、第３の実施に形態における第１のサービスが本実施の形態における有料の第１のサービスに対応し、第３の実施に形態における第２のサービスが本実施の形態における無料の第１のサービスに対応し、第３の実施に形態における第３のサービスが本実施の形態における無料の第２のサービスに対応している。
＜第５の実施の形態＞

次に、第５の実施の形態について説明する。第１の実施の形態では、常時接続サーバ２００と常時接続中のクライアント１００の個数によって、サービスとノードとの対応関係を変更するものであった。しかしながら、第１の実施の形態において簡単に例示したが、本実施の形態にかかるネットワークシステム１は、常時接続サーバ２００のＰＵＳＨ頻度に基づいて、サービスとノードとの対応関係を変更するものである。

なお、ネットワークシステムの全体構成と、クライアント１００のハードウェア構成と、常時接続サーバ２００のハードウェア構成と、アプリケーションサーバ３００のハードウェア構成と、第１の補助サーバ４００のハードウェア構成と、サービス／ノード対応関係ＤＢ６００と、第２の補助サーバ５００のハードウェア構成と、接続ＩＤ／ノード対応関係ＤＢ７００と、監視サーバ８００のハードウェア構成と、常時接続開始に関するネットワークシステム１の機能構成と、常時接続に関する装置間のデータのやり取りと、クライアントにおけるノード選択処理と、第１の補助サーバ４００におけるノードリスト提供処理と、監視サーバ８００における対応関係変更処理とに関しては、第１の実施の形態のそれらと同様であるため、ここでは説明を繰り返さない。
＜サービス／ノード関係変更に関するネットワークシステム１の機能構成＞

以下では、主に、サービス／ノード関係変更に関するネットワークシステム１の機能構成について説明する。図２２は、第５の実施の形態にかかるネットワークシステム１全体の機能構成を示す第１のブロック図である。図２３は、第５の実施の形態にかかるネットワークシステム１全体の機能構成を示す第２のブロック図である。

図２２を参照して、第１のサービスに対応する第１の常時接続サーバ２００Ａと第２の常時接続サーバ２００ＢとのデータＰＵＳＨの頻度が高く、第２のサービスに対応する第３の常時接続サーバ２００Ｃと第４の常時接続サーバ２００ＤとのデータＰＵＳＨの頻度が低い場合がある。それは、第１のサービスに対応する常時接続サーバ２００のうちの一台当たりの常時接続中のクライアント１００の個数が多く、第２のサービスに対応する常時接続サーバ２００のうちの一台当たりの常時接続中のクライアント１００の個数が少ないことが原因かもしれない。あるいは、第１のサービスが頻繁にデータのＰＵＳＨを必要とするものであって、第２のサービスは時々しかデータのＰＵＳＨを必要としないかもしれない。

本実施の形態においては、ネットワークシステム１が、サービスＩＤ毎の単位時間当たりのＰＵＳＨ回数を格納する監視用ＤＢ９００Ｂを含む。そして、本実施の形態にかかる監視サーバ８００Ｂが、サービス毎のＰＵＳＨ回数を参照することによって、サービス／ノードの対応関係の変更が必要か否かを判断する。

たとえば、監視サーバ８００Ｂは、サービスＩＤ毎の単位時間当たりのＰＵＳＨ回数を当該サービスに対応する常時接続サーバ２００の個数で割る。そして、単位時間当たりの１つの常時接続サーバ２００のＰＵＳＨ回数が多いサービスに対応する常時接続サーバ２００を増やし、単位時間当たりの１つの常時接続サーバ２００のＰＵＳＨ回数が少ないサービスに対応する常時接続サーバ２００を減らすように、監視サーバ８００Ｂはサービス／ノード対応関係ＤＢ６００を更新する。すなわち、図２３に示すように、監視サーバ８００Ｂは、ＰＵＳＨ頻度が高かった第１のサービスに対応する常時接続サーバ２００の個数を増やし、ＰＵＳＨ頻度が低かった第２のサービスに対応する常時接続サーバ２００の個数を減らす。

なお、後述するように、監視サーバ８００Ｂは、単位時間当たりの１つの常時接続サーバ２００のＰＵＳＨ回数が少ないサービスに対応する常時接続サーバ２００のいずれかをスリープまたは電源ＯＦＦさせてもよい。これによって、ネットワークシステム１のランニングコストを低減することができる。
＜第６の実施の形態＞

第５の実施の形態においては、複数の常時接続サーバ２００の各々のＰＵＳＨ頻度に応じてサービスとノードとの対応関係を変更するものであった。しかしながら、第１の実施の形態において簡単に例示したが、本実施の形態のように、ＰＵＳＨ頻度の代わりに複数の常時接続サーバ２００の各々がＷｅｂＳｏｃｋｅｔプロトコルを利用して送信するデータ量に応じてサービスとノードとの対応関係を変更するものであってもよい。

なお、ネットワークシステムの全体構成と、クライアント１００のハードウェア構成と、常時接続サーバ２００のハードウェア構成と、アプリケーションサーバ３００のハードウェア構成と、第１の補助サーバ４００のハードウェア構成と、サービス／ノード対応関係ＤＢ６００と、第２の補助サーバ５００のハードウェア構成と、接続ＩＤ／ノード対応関係ＤＢ７００と、監視サーバ８００のハードウェア構成と、常時接続開始に関するネットワークシステム１の機能構成と、常時接続に関する装置間のデータのやり取りと、クライアントにおけるノード選択処理と、第１の補助サーバ４００におけるノードリスト提供処理と、監視サーバ８００における対応関係変更処理とに関しては、第１の実施の形態のそれらと同様であるため、ここでは説明を繰り返さない。
＜サービス／ノード関係変更に関するネットワークシステム１の機能構成＞

以下では、主に、サービス／ノード関係変更に関するネットワークシステム１の機能構成について説明する。図２４は、第６の実施の形態にかかるネットワークシステム１全体の機能構成を示す第１のブロック図である。図２５は、第６の実施の形態にかかるネットワークシステム１全体の機能構成を示す第２のブロック図である。

図２４を参照して、第１のサービスに対応する第１の常時接続サーバ２００Ａと第２の常時接続サーバ２００Ｂからの送信データ量が多く、第２のサービスに対応する第３の常時接続サーバ２００Ｃと第４の常時接続サーバ２００Ｄからの送信データ量が少ない場合がある。それは、第１のサービスに対応する常時接続サーバ２００のうちの一台当たりの常時接続中のクライアント１００の個数が多く、第２のサービスに対応する常時接続サーバ２００のうちの一台当たりの常時接続中のクライアント１００の個数が少ないことが原因かもしれない。あるいは、第１のサービスが頻繁にデータのＰＵＳＨを必要とするものであって、第２のサービスは時々しかデータのＰＵＳＨを必要としないかもしれない。あるいは、第１のサービスが大容量のデータのＰＵＳＨを必要とするものであって、第２のサービスは小容量のデータのＰＵＳＨだけで足りるのかもしれない。

本実施の形態においては、ネットワークシステム１が、サービスＩＤ毎の単位時間当たりの送信データ量を格納する監視用ＤＢ９００Ｃを含む。そして、本実施の形態にかかる監視サーバ８００Ｃが、サービス毎の送信データ量を参照することによって、サービス／ノードの対応関係の変更が必要か否かを判断する。

たとえば、監視サーバ８００Ｃは、サービスＩＤ毎の単位時間当たりの送信データ量を当該サービスに対応する常時接続サーバ２００の個数で割る。そして、単位時間当たりの１つの常時接続サーバ２００の送信データ量が多いサービスに対応する常時接続サーバ２００を増やし、単位時間当たりの１つの常時接続サーバ２００の送信データ量が少ないサービスに対応する常時接続サーバ２００を減らすように、監視サーバ８００Ｃはサービス／ノード対応関係ＤＢ６００を更新する。すなわち、図２５に示すように、監視サーバ８００Ｃは、送信データ量が多かった第１のサービスに対応する常時接続サーバ２００の個数を増やし、送信データ量が少なかった第２のサービスに対応する常時接続サーバ２００の個数を減らす。

なお、後述するように、監視サーバ８００Ｃは、単位時間当たりの１つの常時接続サーバ２００の送信データ量が少ないサービスに対応する常時接続サーバ２００のいずれかをスリープまたは電源ＯＦＦさせてもよい。これによって、ネットワークシステム１のランニングコストを低減することができる。
＜第７の実施の形態＞

第６の実施の形態においては、複数の常時接続サーバ２００の各々の送信データ量に応じてサービスとノードとの対応関係を変更するものであった。しかしながら、第１の実施の形態において簡単に例示したが、本実施の形態のように、ＰＵＳＨ頻度の代わりに複数の常時接続サーバ２００の各々にかかる負荷に応じてサービスとノードとの対応関係を変更するものであってもよい。

なお、ネットワークシステムの全体構成と、クライアント１００のハードウェア構成と、常時接続サーバ２００のハードウェア構成と、アプリケーションサーバ３００のハードウェア構成と、第１の補助サーバ４００のハードウェア構成と、サービス／ノード対応関係ＤＢ６００と、第２の補助サーバ５００のハードウェア構成と、接続ＩＤ／ノード対応関係ＤＢ７００と、監視サーバ８００のハードウェア構成と、常時接続開始に関するネットワークシステム１の機能構成と、常時接続に関する装置間のデータのやり取りと、クライアントにおけるノード選択処理と、第１の補助サーバ４００におけるノードリスト提供処理と、監視サーバ８００における対応関係変更処理とに関しては、第１の実施の形態のそれらと同様であるため、ここでは説明を繰り返さない。
＜サービス／ノード関係変更に関するネットワークシステム１の機能構成＞

以下では、主に、サービス／ノード関係変更に関するネットワークシステム１の機能構成について説明する。図２６は、第７の実施の形態にかかるネットワークシステム１全体の機能構成を示す第１のブロック図である。図２７は、第７の実施の形態にかかるネットワークシステム１全体の機能構成を示す第２のブロック図である。

図２６を参照して、第１のサービスに対応する第１の常時接続サーバ２００Ａと第２の常時接続サーバ２００Ｂにかかる負荷が重く、第２のサービスに対応する第３の常時接続サーバ２００Ｃと第４の常時接続サーバ２００Ｄにかかる負荷が軽い場合がある。それは、第１のサービスに対応する常時接続サーバ２００のうちの一台当たりの常時接続中のクライアント１００の個数が多く、第２のサービスに対応する常時接続サーバ２００のうちの一台当たりの常時接続中のクライアント１００の個数が少ないことが原因かもしれない。あるいは、第１のサービスが頻繁にデータのＰＵＳＨを必要とするものであって、第２のサービスは時々しかデータのＰＵＳＨを必要としないかもしれない。あるいは、第１のサービスが大容量のデータのＰＵＳＨを必要とするものであって、第２のサービスは小容量のデータのＰＵＳＨだけで足りるのかもしれない。

本実施の形態においては、ネットワークシステム１が、サービスＩＤ毎の負荷を格納する監視用ＤＢ９００Ｄを含む。そして、本実施の形態にかかる監視サーバ８００Ｄが、サービス毎の負荷を参照することによって、サービス／ノードの対応関係の変更が必要か否かを判断する。

たとえば、監視サーバ８００Ｄは、サービスＩＤ毎の負荷を当該サービスに対応する常時接続サーバ２００の個数で割る。そして、１つの常時接続サーバ２００の負荷が重いサービスに対応する常時接続サーバ２００を増やし、１つの常時接続サーバ２００の負荷が軽いサービスに対応する常時接続サーバ２００を減らすように、監視サーバ８００Ｄはサービス／ノード対応関係ＤＢ６００を更新する。すなわち、図２７に示すように、監視サーバ８００Ｄは、負荷が重かった第１のサービスに対応する常時接続サーバ２００の個数を増やし、負荷が軽かった第２のサービスに対応する常時接続サーバ２００の個数を減らす。

なお、後述するように、監視サーバ８００Ｄは、１つの常時接続サーバ２００の負荷が軽いサービスに対応する常時接続サーバ２００のいずれかをスリープまたは電源ＯＦＦさせてもよい。これによって、ネットワークシステム１のランニングコストを低減することができる。
＜第８の実施の形態＞

第１〜７の実施の形態においては、複数のサービスと複数の常時接続サーバ２００と組み合わせを変更するものであった。しかしながら、第１の実施の形態において簡単に例示したが、本実施の形態のように、状況に応じて稼働する常時接続サーバ２００の全体の個数を変更してもよい。すなわち、常時接続によるデータの送受信が少ないときに、複数の常時接続サーバ２００の一部をスリープ状態または電源ＯＦＦ状態にするものであってもよい。

なお、ネットワークシステムの全体構成と、クライアント１００のハードウェア構成と、常時接続サーバ２００のハードウェア構成と、アプリケーションサーバ３００のハードウェア構成と、第１の補助サーバ４００のハードウェア構成と、サービス／ノード対応関係ＤＢ６００と、第２の補助サーバ５００のハードウェア構成と、接続ＩＤ／ノード対応関係ＤＢ７００と、監視サーバ８００のハードウェア構成と、常時接続開始に関するネットワークシステム１の機能構成と、常時接続に関する装置間のデータのやり取りと、クライアントにおけるノード選択処理と、第１の補助サーバ４００におけるノードリスト提供処理と、監視サーバ８００における対応関係変更処理とに関しては、第１の実施の形態のそれらと同様であるため、ここでは説明を繰り返さない。
＜サービス／ノード関係変更に関するネットワークシステム１の機能構成＞

以下では、主に、サービス／ノード関係変更に関するネットワークシステム１の機能構成について説明する。図２８は、第８の実施の形態にかかるネットワークシステム１全体の機能構成を示す第１のブロック図である。図２９は、第８の実施の形態にかかるネットワークシステム１全体の機能構成を示す第２のブロック図である。

図２８を参照して、５つの常時接続サーバ２００Ａ、２００Ｂ，２００Ｃ，２００Ｄ，２００Ｅのうちの、１つの常時接続サーバ２００Ｅがスリープ状態になっている。すなわち、４つの常時接続サーバ２００Ａ，２００Ｂ，２００Ｃ，２００Ｄによって、３つのサービスに関する常時接続処理を十分に賄えている。たとえば、４つの常時接続サーバ２００Ａ，２００Ｂ，２００Ｃ，２００Ｄの各々について、接続中のクライアント１００の個数が１０００以下である。

監視サーバ８００Ｄは、１つの常時接続サーバ２００当たりの常時接続中のクライアント１００の数、または１つの常時接続サーバ２００当たりのＰＵＳＨ頻度、または１つの常時接続サーバ２００当たりの送信データ量、または１つの常時接続サーバ２００当たりの負荷を監視している。そして、１つの常時接続サーバ２００当たりの常時接続中のクライアント１００の数が所定値を超えたり、または１つの常時接続サーバ２００当たりのＰＵＳＨ頻度が所定値を超えたり、または１つの常時接続サーバ２００当たりの送信データ量が所定値を超えたり、または１つの常時接続サーバ２００当たりの負荷が所定値を超えたりした場合に、監視サーバ８００Ｄは、それまで待機していた第５の常時接続サーバ２００Ｅを起動させる。

それと同時に、図２９に示すように、監視サーバ８００Ｄは、サービス／ノード対応関係ＤＢ６００において、起動させた第５の常時接続サーバ２００Ｅのノードを、常時接続中のクライアント１００の数が所定値を超えた常時接続サーバ２００に対応するサービスに対応付ける。あるいは、監視サーバ８００Ｄは、サービス／ノード対応関係ＤＢ６００において、起動させた第５の常時接続サーバ２００Ｅのノードを、ＰＵＳＨ頻度が所定値を超えた常時接続サーバ２００に対応するサービスに対応付ける。あるいは、監視サーバ８００Ｄは、サービス／ノード対応関係ＤＢ６００において、起動させた第５の常時接続サーバ２００Ｅのノードを、送信データ量が所定値を超えた常時接続サーバ２００に対応するサービスに対応付ける。あるいは、監視サーバ８００Ｄは、サービス／ノード対応関係ＤＢ６００において、起動させた第５の常時接続サーバ２００Ｅのノードを、負荷が所定値を超えた常時接続サーバ２００に対応するサービスに対応付ける。これによって、これ以降に、当該サービスの利用を試みるクライアント１００が、第５の常時接続サーバ２００Ｅと常時接続するようになる。

なお、第５の常時接続サーバ２００は、ホットスタンバイ状態で待機するものであっても良いし、コールドスタンバイ状態で待機するものであってもよい。本実施の形態においては、第５の常時接続サーバ２００を常時接続サーバノード群に加える際は、監視サーバ８００Ｄが単にサービス／ノード対応関係を更新するだけとしている。しかしながら、第５の常時接続サーバ２００を常時接続サーバノード群に加える際は、監視サーバ８００Ｄが、サービス／ノード対応関係を更新しつつＤＮＳ（Domain Name System）サーバの常時接続サーバ２００のアドレスも変更するものであってもよい。

逆に、１つの常時接続サーバ２００当たりの常時接続中のクライアント１００の数が別の所定値を下回ったり、または１つの常時接続サーバ２００当たりのＰＵＳＨ頻度が別の所定値を下回ったり、または１つの常時接続サーバ２００当たりの送信データ量が別の所定値を下回ったり、または１つの常時接続サーバ２００当たりの負荷が別の所定値を下回ったりすると、監視サーバ８００Ｅは、人気が無いサービスに対応する常時接続サーバ２００（たとえば、第５の常時接続サーバ２００Ｅ）をスリープ状態に移行させたり、電源をＯＦＦにしたりする。

図２８に示すように、監視サーバ８００Ｅは、サービス／ノード対応関係ＤＢ６００において、スリープ状態または電源をＯＦＦにした第５の常時接続サーバ２００Ｅのノードとサービスとのレコードを削除する。
＜第９の実施の形態＞

第２および第４の実施の形態においては、課金の有無によって常時接続サーバ２００を分けるものであった。

本実施の形態においては、それに加えて、有料サービスには高いスペックな常時接続サーバ２００を対応付けて、無料サービスには通常の常時接続サーバ２００を対応付けてもよい。これによって、有料サービスを利用するクライアント１００は、よりスムーズな常時接続のデータ送受信を行うことができる。
＜第１０の実施の形態＞

第２および第４の実施の形態においては、課金の有無によって常時接続サーバ２００を分けるものであった。

本実施の形態においては、それに加えて、有料サービスには１つの常時接続サーバ２００当たりの接続クライアントの個数の上限が低く、無料サービスには１つの常時接続サーバ２００当たりの接続クライアントの個数の上限が高く、設定されてもよい。すなわち、監視サーバ８００が、有料サービスに関しては、１つの常時接続サーバ２００当たりの接続クライアントの個数が増えると、対応する常時接続サーバ２００の個数を早めに増加させる。逆に、監視サーバ８００は、無料サービスに関しては、１つの常時接続サーバ２００当たりの接続クライアントの個数が増えても、対応する常時接続サーバ２００の個数をなかなか増加させない。

あるいは、有料サービスには１つの常時接続サーバ２００当たりの接続クライアントの個数の上限が設定されて、無料サービスには１つの常時接続サーバ２００当たりの接続クライアントの個数の上限が設定されないものであってもよい。
＜第１１の実施の形態＞

第１〜第１０の実施の形態においては、第２の補助サーバ５００が、アプリケーションサーバ３００からのデータを常時接続サーバ２００に割り振る際に、接続ＩＤ／ノード対応関係ＤＢ７００を参照することによって、ＰＵＳＨ先のクライアント１００と常時接続中の常時接続サーバ２００にデータを割り振るものであった。

しかしながら、本実施の形態においては、第２の補助サーバ５００が、アプリケーションサーバ３００からのデータを常時接続サーバ２００に割り振る際に、サービス／ノード対応関係ＤＢ６００を参照して、アプリケーションサーバ３００に対応する常時接続サーバ２００のうちのいずれかにデータを割り振る。たとえば、第２の補助サーバ５００は、アプリケーションサーバ３００に対応する常時接続サーバ２００のうちの負荷が少ない常時接続サーバ２００にデータを割り振る。

そして、常時接続サーバ２００のＣＰＵ２１０が、通信インターフェイス２６０を利用することによって、接続ＩＤ／ノード対応関係ＤＢ７００を参照することによって、ＰＵＳＨ先のクライアント１００と常時接続中の常時接続サーバ２００にデータを転送する。当然に、常時接続サーバ２００のＣＰＵ２１０は、自身と常時接続中のクライアント１００に対しては、ＷｅｂＳｏｃｋｅｔプロトコルを利用することによって、通信インターフェイス２６０を介してデータを直接ＰＵＳＨする。
＜第１２の実施の形態＞

第１〜第１１の実施の形態においては、第１の補助サーバ４００が、クライアント１００からのデータに基づいて、クライアント１００が利用するサービスに対応する常時接続サーバ２００のリストを作成するものであった。

しかしながら、第１の補助サーバ４００は、全ての常時接続サーバ２００のアドレスのリストをクライアント１００に提供しても良い。たとえば、第１の補助サーバ４００は、対応関係６２０（６２０Ｂ，６２０Ｃ，６２０Ｄ，６２０Ｅ）をクライアント１００に送信する。そして、クライアント１００のＣＰＵ１１０が、対応関係６２０を参照して、自身が利用するサービスに対応する常時接続サーバ２００を選択する。このとき、ＣＰＵ１１０は、一旦、ノードリストを作成してもよいし、しなくてもよい。ＣＰＵ１１０は、ＷｅｂＳｏｃｋｅｔプロトコルを利用して、通信インターフェイス１６０を介して選択された常時接続サーバ２００と常時接続を行う。
＜第１３の実施の形態＞

第１〜第１２の実施の形態においては、第１の補助サーバ４００が、常時接続サーバ２００とアプリケーションサーバ３００とは別の装置であった。

しかしながら、第１の補助サーバ４００が、常時接続サーバ２００のいずれか、またはアプリケーションサーバ３００のいずれかと同じ装置であってもよい。すなわち、常時接続サーバ２００のいずれか、またはアプリケーションサーバ３００のいずれかが、第１の補助サーバ４００の役割を兼ねてもよい。
＜第１４の実施の形態＞

第１〜第１３の実施の形態においては、監視サーバ８００が、常時接続サーバ２００とアプリケーションサーバ３００と第１の補助サーバ４００とは別の装置であった。

しかしながら、監視サーバ８００が、常時接続サーバ２００のいずれか、またはアプリケーションサーバ３００のいずれか、または第１の補助サーバ４００と同じ装置であってもよい。すなわち、常時接続サーバ２００のいずれか、またはアプリケーションサーバ３００のいずれか、または第１の補助サーバ４００が、監視サーバ８００の役割を兼ねてもよい。
＜第１５の実施の形態＞

第１〜第１４の実施の形態においては、アプリケーションサーバ３００が１つのサービスを提供し、１つのサービスは１つのアプリケーションサーバ３００から提供されるものであった。

しかしながら、１つのサービスが、複数のアプリケーションサーバ３００から提供されても良い。この場合も、第１〜第１４の実施の形態と同じように、常時接続サーバ２００が、アプリケーションサーバ３００に対応付けられていても良いし、サービスに対応付けられても良い。

逆に、アプリケーションサーバ３００が、複数のサービスに対応付けられていても良い。この場合も、第１〜第１４の実施の形態と同じように、常時接続サーバ２００が、アプリケーションサーバ３００に対応付けられていても良いし、サービスに対応付けられても良い。
＜第１６の実施の形態＞

第１〜第１５の実施の形態においては、図１０のステップＳ００９に示すように、クライアント１００と常時接続サーバ２００とが常時接続を開始する際に、クライアント１００が、認証情報とは別に、第１の補助サーバ４００からサービスに対応するノードリストを取得するものであった。

しかしながら、クライアント１００は、クライアント１００と常時接続サーバ２００とが常時接続を開始する際に、認証情報とは別に、常時接続サーバ２００またはアプリケーションサーバ３００からサービスに対応するノードリストを取得してもよい（図１０におけるステップＳ００９）。すなわち、常時接続サーバ２００またはアプリケーションサーバ３００が、第１の補助サーバ４００の役割の一部を兼ねてもよい。

より詳細には、常時接続サーバ２００またはアプリケーションサーバ３００は、クライアント１００からノードリストの要求を受けた際に、サービスに対応するノードリストを作成する役割とノードリストをクライアント１００に提供する役割とを負っても良い。あるいは、クライアント１００からノードリストの要求を受けた際に、第１の補助サーバ４００がノードリストの作成を行い、常時接続サーバ２００またはアプリケーションサーバ３００が、第１の補助サーバ４００からノードリストを取得して、当該ノードリストをクライアント１００へ提供する役割を負っても良い。
＜第１７の実施の形態＞

第１〜第１５の実施の形態においては、図１０のステップＳ００９に示すように、クライアント１００と常時接続サーバ２００とが常時接続を開始する際に、クライアント１００が、認証情報とは別に、第１の補助サーバ４００からサービスに対応するノードリストを取得するものであった。

しかしながら、クライアント１００と常時接続サーバ２００とが常時接続を開始する際に、アプリケーションサーバ３００が、認証情報と共に、サービスに対応するノードリストをクライアント１００に送信しても良い（図１０におけるステップＳ００４）。この場合は、図１０におけるステップＳ００９が不要である。

より詳細には、アプリケーションサーバ３００は、クライアント１００から認証情報の要求を受けた際に、サービスに対応するノードリストを作成する役割とノードリストをクライアント１００に提供する役割とを負っても良い。あるいは、クライアント１００から認証情報の要求を受けた際に、第１の補助サーバ４００がノードリストの作成を行い、常時接続サーバ２００またはアプリケーションサーバ３００が、第１の補助サーバ４００からノードリストを取得して、当該ノードリストをクライアント１００へ提供する役割を負っても良い。
＜その他の応用例＞

本発明は、システム或いは装置にプログラムを供給することによって達成される場合にも適用できることはいうまでもない。そして、本発明を達成するためのソフトウェアによって表されるプログラムを格納した記憶媒体（あるいはメモリ）を、システム或いは装置に供給し、そのシステム或いは装置のコンピュータ（又はＣＰＵやＭＰＵ）が記憶媒体に格納されたプログラムコードを読出し実行することによっても、本発明の効果を享受することが可能となる。

この場合、記憶媒体から読出されたプログラムコード自体が前述した実施の形態の機能を実現することになり、そのプログラムコードを記憶した記憶媒体は本発明を構成することになる。

また、コンピュータが読出したプログラムコードを実行することにより、前述した実施の形態の機能が実現されるだけでなく、そのプログラムコードの指示に基づき、コンピュータ上で稼動しているＯＳ（オペレーティングシステム）などが実際の処理の一部または全部を行い、その処理によって前述した実施の形態の機能が実現される場合も含まれることは言うまでもない。

さらに、記憶媒体から読み出されたプログラムコードが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わる他の記憶媒体に書き込まれた後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部または全部を行い、その処理によって前述した実施の形態の機能が実現される場合も含まれることは言うまでもない。

今回開示された実施の形態はすべての点で例示であって制限的なものではないと考えられるべきである。本発明の範囲は、上記した説明ではなく、特許請求の範囲によって示され、特許請求の範囲と均等の意味および範囲内でのすべての変更が含まれることが意図される。

１ ：ネットワークシステム
１００ ：クライアント
１１０ ：ＣＰＵ
１２０ ：メモリ
１６０ ：通信インターフェイス
２００ ：常時接続サーバ
２１０ ：ＣＰＵ
２２０ ：メモリ
２６０ ：通信インターフェイス
３００ ：アプリケーションサーバ
３１０ ：ＣＰＵ
３２０ ：メモリ
３６０ ：通信インターフェイス
４００ ：第１の補助サーバ
４１０ ：ＣＰＵ
４２０ ：メモリ
４６０ ：通信インターフェイス
５００ ：第２の補助サーバ
５１０ ：ＣＰＵ
５２０ ：メモリ
５６０ ：通信インターフェイス
６００ ：サービス／ノード対応関係ＤＢ
７００ ：接続ＩＤ／ノード対応関係ＤＢ
８００ ：監視サーバ
８１０ ：ＣＰＵ
８２０ ：メモリ
８６０ ：通信インターフェイス

Claims (14)

1. 複数のサービスを提供するための少なくとも１つのサービスサーバと、
   複数の常時接続サーバと、
   前記複数の常時接続サーバのいずれかを介して前記複数のサービスのうち少なくとも１つのサービスを利用するためのクライアントと、を備えるネットワークシステムであって、
   前記少なくとも１つのサービスサーバと、前記複数の常時接続サーバと、前記クライアントと通信可能な更に別のサーバ、のいずれかは、前記クライアントからの前記サービスを特定するためのサービス情報を含む要求に応じて、前記サービスに対応する前記複数の常時接続サーバのうちの少なくとも１つの常時接続サーバに関するリストを前記クライアントに送信し、
   前記クライアントは、前記リストに基づいて前記サービスに対応する常時接続サーバとの常時接続を開始する、ネットワークシステム。
2. 前記少なくとも１つのサービスサーバと前記複数の常時接続サーバと前記クライアントと通信可能な更に別のサーバのいずれかは、前記サービスに対応する常時接続サーバが複数である場合には当該複数の常時接続サーバに関するリストを前記クライアントに送信し、前記サービスに対応する常時接続サーバが１つである場合には当該１つの常時接続サーバに関するリストを前記クライアントに送信する、請求項１に記載のネットワークシステム。
3. 前記要求が前記クライアントを特定するためのクライアント情報を含み、
   前記サーバが、前記クライアント情報に対応する前記サービスを特定し、前記リストとして、前記サービスに対応する少なくとも１つの常時接続サーバに関するリストを作成する、請求項１または２に記載のネットワークシステム。
4. 前記サーバおよび他のサーバのいずれかが、前記複数の常時接続サーバそれぞれが接続中のクライアントの数に基づいて、前記複数の常時接続サーバそれぞれに割り振るサービスを変更する、請求項１から３のいずれかに記載のネットワークシステム。
5. 前記サーバおよび他のサーバのいずれかが、前記複数の常時接続サーバそれぞれからのデータのＰＵＳＨの頻度に基づいて、前記複数の常時接続サーバそれぞれに割り振るサービスを変更する、請求項１から４のいずれかに記載のネットワークシステム。
6. 前記サーバおよび他のサーバのいずれかが、前記複数の常時接続サーバそれぞれからのデータ量に基づいて、前記複数の常時接続サーバそれぞれに割り振るサービスを変更する、請求項１から５のいずれかに記載のネットワークシステム。
7. 前記サーバおよび他のサーバのいずれかが、前記複数の常時接続サーバそれぞれの負荷に基づいて、前記複数の常時接続サーバそれぞれに割り振るサービスを変更する、請求項１から６のいずれかに記載のネットワークシステム。
8. 前記複数の常時接続サーバは、稼働中の常時接続サーバと非稼働中の常時接続サーバとを含み、
   前記サーバおよび他のサーバのいずれかが、所定の条件に基づいて、複数の常時接続サーバの各々の稼働および非稼働を切り替える、請求項１から７のいずれかに記載のネットワークシステム。
9. 前記サーバが、前記複数の常時接続サーバのいずれかである、請求項１から８のいずれかに記載のネットワークシステム。
10. サービスサーバから提供される複数のサービスのいずれかを利用するために、クライアントが前記サービスサーバに要求を送るステップと、
    前記クライアントからの前記サービスを特定するためのサービス情報を含む要求に応じて、前記サービスに対応する複数の常時接続サーバのうちの少なくとも１つの常時接続サーバに関するリストを、前記サービスサーバと前記複数の常時接続サーバと前記クライアントと通信可能な更に別のサーバのいずれかが、前記クライアントに送信するステップと、
    前記クライアントが、前記リストに基づいて前記サービスに対応する常時接続サーバとの常時接続を開始するステップとを備える、常時接続方法。
11. クライアントと通信するための通信インターフェイスと、
    前記通信インターフェイスを介して、前記クライアントからのサービスを特定するためのサービス情報を含む要求を受信し、前記クライアントが利用するためのサービスに対応する少なくとも１つの常時接続サーバに関するリストを作成し、前記クライアントに送信するためのプロセッサとを備える、サービスサーバ。
12. プロセッサと通信インターフェイスとを含むサービスサーバで利用されるプログラムであって、
    前記通信インターフェイスを介して、クライアントからのサービスを特定するためのサービス情報を含む要求を受け付けるステップと、
    前記通信インターフェイスを介して、前記クライアントが利用するためのサービスに対応する少なくとも１つの常時接続サーバに関するリストを作成し、前記クライアントに送信するステップとを前記プロセッサに実行させる、プログラム。
13. 通信インターフェイスと、
    前記通信インターフェイスを介して、サービスを特定するためのサービス情報を含む要求を送信し、前記サービスに対応する少なくとも１つの常時接続サーバに関するリストを受信し、前記リストに基づいてサービスサーバから提供されるサービスに対応する常時接続サーバとの常時接続を開始するためのプロセッサとを備える、電子機器。
14. プロセッサと通信インターフェイスとを含む電子機器で利用されるプログラムであって、
    前記通信インターフェイスを介して、サービスを特定するためのサービス情報を含む要求を送信するステップと、
    前記通信インターフェイスを介して、前記サービスに対応する少なくとも１つの常時接続サーバに関するリストを受信するステップと、
    前記通信インターフェイスを介して、前記リストに基づいてサービスサーバから提供されるサービスに対応する常時接続サーバとの常時接続を開始するステップとを前記プロセッサに実行させる、プログラム。

Images