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

Description

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

従来から、サーバ側で生じた情報をリアルタイムに端末に伝達するための様々な技術が知られている。たとえば、特開２０１０−２７７４９２号公報（特許文献１）には、電子会議サーバおよびコンピュータプログラムが開示されている。特開２０１０−２７７４９２号公報（特許文献１）によると、ウェブ・アプリケーションにて電子会議システムを提供する場合にリアルタイム性を確保可能とすること、および電子会議システムの運用に付随した未解決課題の管理などを実現する。具体的には、アプリケーションサーバは、コメットサーバが各電子機器からのＨＴＴＰリクエストを受信して保留状態となるように制御する。つぎに、アプリケーションサーバは、前述とは別の電子機器からメッセージデータを受信すると、このメッセージデータと会議データベースから引き出した必要データを、コメットサーバ経由で、ＨＴＴＰリクエストを出した電子機器へ送信し、保留を解除する。送信後は前記アプリケーションサーバが各電子機器からのＨＴＴＰリクエストを受信して再び保留状態となるように制御する。これにより、ＨＴＴＰリクエストを送信した電子機器は、アプリケーションサーバ側がデータを準備できた瞬間から間を置くことなくデータを得ることができる。

しかしながら、コメットでは、リクエストに対するレスポンスの送信を行う度に、新たにＨＴＴＰコネクションを確立する必要があった。そこで、近年では、常時接続を行い、接続を維持したまま、複数回の双方向の通信を行う方法が用いられる。

しかしながら、常時接続を用いた場合、サーバがメンテナンスや予期せぬ障害により停止した場合、それまで接続されていた全てのクライアントとサーバ間の常時接続が一旦切断され、その後、稼働を再開したサーバもしくは冗長構成され稼働を継続する他方のサーバに対し、これら多数のクライアントが一斉に常時接続を再開しようとして、サーバに対し過大なサーバ負荷を生じさせ、スムーズに再接続が行われないことがあった。

これを改善する手段として、特開２０１３−０５１５７１号公報（特許文献２）では、サーバと接続を確立して通信する通信手段と，前記通信によって前記サーバから取得する情報に基づいて所定の処理を実行する処理手段と，前記接続の切断を検知する切断検知手段と，前記接続の切断が検知された場合，試行する間隔の期待値が所定の一定値となる条件を満たしたランダムな第一タイミングにおいて前記サーバとの再接続を繰り返し試行する再接続手段と備えるクライアント側の技術が開示されており、再接続をサーバの負荷を分散しながら早期に確立することを可能としている。

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

しかしながら、特許文献２の手法では、再接続のタイミングは固定値であり、変更の仕組みがないため、システム運用後、事前に想定するよりサーバに接続するクライアントの数が増加した場合や、機能の追加などによりサーバの再接続の処理能力が低下した場合など、システムの運用環境に変化があった場合に、依然として、再接続にかかる処理がサーバの処理能力を超過し、サーバに過大な負荷を生じる可能性がある。

本発明は、かかる問題を解決するためになされたものであり、その目的は、常時接続サーバが停止したとき、システムの運用環境に変化があった場合でも、稼働を再開した常時接続サーバもしくは冗長構成され稼働を継続する他方の常時接続サーバに対し、課題な負荷をかけることなく、スムーズに常時接続状態に復帰できるネットワークシステム、常時接続方法、電子機器、サーバ、プログラムを提供することにある。

この発明のある態様に従うと、電子機器と、電子機器と常時接続可能な常時接続サーバとを備えるネットワークシステムが提供される。常時接続サーバは、常時接続サーバに関する再接続用間隔を含む情報を電子機器に送信する。電子機器は、再接続用間隔に基づいて算出される時間の待機後、常時接続サーバとの常時接続が成功するまで、常時接続するための処理を繰り返す。

好ましくは、常時接続サーバは、電子機器毎に再接続用間隔を上限とした待ち時間を作成し、電子機器に待ち時間を送信する。電子機器は、常時接続サーバとの常時接続が切断されたときに、待ち時間だけ待機してから常時接続するための処理を行う。

好ましくは、電子機器は、再接続用間隔を上限とした待ち時間を作成し、常時接続サーバとの常時接続が切断されたときに、待ち時間だけ待機してから常時接続するための処理を行う。

好ましくは、待ち時間は、電子機器と常時接続サーバとの常時接続によるデータの送受信の頻度に基づいて作成される。

好ましくは、常時接続サーバは、常時接続サーバと接続中の複数の電子機器の数と、１つの常時接続サーバの１秒当たりの再接続可能な電子機器の数と、に基づいて再接続用間隔を計算する。

好ましくは、ネットワークシステムは、常時接続サーバとして、電子機器と常時接続可能な複数の常時接続サーバを備える。複数の常時接続サーバの少なくとも１つは、複数の常時接続サーバに関する情報を電子機器に送信する。電子機器は、複数の常時接続サーバのいずれかとの常時接続が成功するまで、情報に基づいて複数の常時接続サーバに順に常時接続を試みる。

好ましくは、複数の常時接続サーバの少なくとも１つは、複数の常時接続サーバと接続中の複数の電子機器の数と、１つの常時接続サーバの１秒当たりの再接続可能な電子機器の数と、稼働中の常時接続サーバの個数とに基づいて再接続用間隔を計算する。

好ましくは、電子機器は、常時接続サーバとの常時接続が成功するまで、再接続用間隔をあけながら常時接続するための処理を繰り返す。

好ましくは、常時接続サーバは、他のサーバを介して、再接続用間隔を含む情報を電子機器に送信する。

好ましくは、電子機器は、電子機器に起因して常時接続が切断されたと判断した時に、待機を実行せずに即時に、常時接続するための処理を開始する。電子機器に起因せずに常時接続が切断されたと判断した時に、再接続用間隔に基づいて算出される時間の待機後、常時接続するための処理を開始する。

この発明の別の態様に従うと、電子機器と電子機器と常時接続可能な常時接続サーバとを含むネットワークシステムにおける常時接続方法が提供される。常時接続方法は、常時接続サーバが、再接続用間隔を含む情報を電子機器に送信するステップと、電子機器と常時接続サーバとの常時接続が切断されるステップと、電子機器が、情報を利用することによって、再接続用間隔に基づいて算出される時間の待機後、常時接続サーバとの常時接続が成功するまで、常時接続するための処理を繰り返すステップとを備える。

この発明の別の態様に従うと、常時接続サーバと常時接続可能な通信インターフェイスと、常時接続サーバに関する情報を利用することによって、常時接続サーバのいずれかから与えられた再接続用間隔に基づいて算出される時間の待機後、常時接続サーバとの常時接続が成功するまで、常時接続するための処理を繰り返すためのプロセッサとを備える、電子機器が提供される。

好ましくは、プロセッサは、電子機器に起因して常時接続が切断されたと判断した時に、待機を実行せずに即時に、常時接続するための処理を開始し、電子機器に起因せずに常時接続が切断されたと判断した時に、再接続用間隔に基づいて算出される時間の待機後、常時接続するための処理を開始する。

この発明の別の態様に従うと、電子機器と常時接続可能な通信インターフェイスと、通信インターフェイスを介して、常時接続サーバに関する再接続用間隔を含む情報を電子機器に送信するためのプロセッサとを備える、常時接続サーバが提供される。

この発明の別の態様に従うと、プロセッサと通信インターフェイスとを含む電子機器で利用されるプログラムが提供される。プログラムは、通信インターフェイスを介して、常時接続サーバから再接続用間隔を含む情報を受信するステップと、情報を利用することによって、再接続用間隔に基づいて算出された時間の待機後、常時接続サーバとの常時接続が成功するまで、常時接続サーバと常時接続するための処理を繰り返すステップとをプロセッサに実行させる。

この発明の別の態様に従うと、プロセッサと通信インターフェイスとを含むサーバで利用されるプログラムが提供される。プログラムは、通信インターフェイスを介して、電子機器からの要求を受け付けるステップと、当該要求に応じて、通信インターフェイスを介して常時接続サーバに関する再接続用間隔を含む情報を電子機器に送信するステップとをプロセッサに実行させる。

以上のように、この発明によれば、常時接続サーバがメンテナンスや予期せぬ障害により停止した場合でも、稼働を再開したサーバもしくは冗長構成され稼働を継続する他方のサーバに対し、課題な負荷をかけることなく、スムーズに常時接続状態に復帰できるネットワークシステム、常時接続方法、電子機器、サーバ、プログラムが提供される。

本実施の形態にかかるネットワークシステム１の全体構成と動作概要とを示す第１のイメージ図である。 本実施の形態にかかるネットワークシステム１の全体構成と動作概要とを示す第２のイメージ図である。 本実施の形態にかかるネットワークシステム１の全体構成と動作概要とを示す第３のイメージ図である。 本実施の形態にかかるクライアント１００が負荷分散装置６００にアクセスするタイミングを示すイメージ図である。 本実施の形態にかかるクライアント１００のハードウェア構成を表わすブロック図である。 本実施の形態にかかる常時接続サーバ２００のハードウェア構成を表わすブロック図である。 本実施の形態にかかるアプリケーションサーバ３００のハードウェア構成を表わすブロック図である。 本実施の形態にかかる常時接続補助サーバ４００のハードウェア構成を表わすブロック図である。 本実施の形態にかかる負荷分散装置６００のハードウェア構成を表わすブロック図である。 本実施の形態にかかるネットワークシステム１全体の機能構成を示すブロック図である。 本実施の形態にかかるネットワークシステム１における常時接続に関する装置間のデータのやり取りの処理手順を示すシーケンス図である。 本実施の形態にかかるクライアント１００における再接続処理の処理手順を示すフローチャートである。 本実施の形態にかかるクライアント１００における待機サブルーチンの処理手順を示すフローチャートである。 本実施の形態にかかる初回接続処理の処理手順を示すシーケンス図である。 本実施の形態にかかる再接続処理の処理手順を示すシーケンス図である。 本実施の形態にかかる対応関係ＤＢ５００のデータ構造を示すイメージ図である。

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

また、以下では、常時接続通信の一例として、Ｗｅｂソケットプロトコルを利用した通信について説明する。Ｗｅｂソケットは、主としてウェブサーバとウェブブラウザとの間の双方向通信を行うための技術規格であり、プロトコルの仕様はＲＦＣ（Request For Comment）６４５５に規定されている。Ｗｅｂソケットにおいては、常時接続であり、接続を維持したまま、複数回の双方向の通信を行うことができる。しかしながら、アプリケーションサーバから任意のタイミングでクライアントにデータをプッシュできればよく、本発明はＷｅｂソケットプロトコルを利用する常時接続に限定されるものではない。
＜第１の実施の形態＞
＜ネットワークシステムの全体構成＞

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

図１を参照して、ネットワークシステム１は、たとえば、遠隔から家電を操作するシステムを想定しており、住居またはオフィスなどに配置される複数の家電１００Ａ，１００Ｄと、ネットワークを介して家電１００Ａ，１００Ｄと接続される複数の常時接続サーバ２００Ａ，２００Ｂと、家電１００Ａ，１００Ｄに関する様々なサービスを提供する複数のアプリケーションサーバ３００Ａ，３００Ｂと、アプリケーションサーバ３００Ａ，３００Ｂからのデータを適切な常時接続サーバ２００Ａ，２００Ｂに送信する常時接続補助サーバ４００と、常時接続サーバ２００Ａ，２００Ｂにかかる負荷を分散するための負荷分散装置６００とを含む。

なお、以下では、常時接続サーバ２００Ａ，２００Ｂが２つの場合について説明するが、常時接続サーバは１つであってもよいし、３つ以上であっても良い。アプリケーションサーバも１つであってもよいし、３つ以上であっても良い。家電も１つであってもよいし、３つ以上であってもよい。負荷分散装置と常時接続補助サーバは２つ以上であってもよい。

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

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

そして、本実施の形態においては、掃除機１００Ａおよびエアコン１００Ｄの各々が、常時接続サーバ２００Ａ，２００Ｂのいずれかと常時接続される。これによって、掃除機用のアプリケーションサーバ３００Ａおよびエアコン用のアプリケーションサーバ３００Ｂは、常時接続サーバ２００Ａ，２００Ｂを介して任意のタイミングで掃除機１００Ａおよびエアコン１００Ｄにデータをプッシュ送信することができる。

すなわち、本実施の形態にかかるネットワークシステム１では、多数の家電の各々が、自身に適したサービスを提供する複数のアプリケーションサーバの全てと、直接的に常時接続する必要がない。また、逆に、複数のアプリケーションサーバの各々が、対応する複数の家電の全てと、直接的に常時接続する必要がない。
＜ネットワークシステムの動作概要＞

次に、本実施の形態にかかるネットワークシステム１の動作概要について説明する。なお、以下では、説明の重複をさけるために、掃除機１００Ａ、エアコン１００Ｄなどの家電を総称して、クライアント１００ともいう。同様に、ノード１の常時接続サーバ２００Ａと、ノード２の常時接続サーバ２００Ｂとを総称して、常時接続サーバ２００ともいう。同様に、掃除機用のアプリケーションサーバ３００Ａおよびエアコン用のアプリケーションサーバ３００Ｂなどのような、各種のサービスをクライアント１００およびユーザなどに提供するためのアプリケーションサーバを総称して、アプリケーションサーバ３００ともいう。

まず、図１を参照して、掃除機１００Ａは、常時接続サーバ２００Ａ，２００Ｂのいずれかと常時接続を開始するために、まず、ＨＴＴＰプロトコルを利用して、負荷分散装置６００を介して、稼働中の常時接続サーバ２００のいずれかに、複数の常時接続サーバ２００のアドレスが格納されたノードリストを要求する。ノードリストの例については、後述する。

掃除機１００Ａは、当該ノードリストに基づいて、Ｗｅｂソケットプロトコルを利用して、ノード１としての常時接続サーバ２００Ａと常時接続を開始する。

なお、本実施の形態においては、負荷分散装置６００は、掃除機１００Ａからノードリストの要求を受け付けたときに、常時接続サーバ２００Ａにノードリストを要求する。そして、常時接続サーバ２００Ａからの応答がない場合には、負荷分散装置６００は、他の常時接続サーバ２００Ｂにノードリストを要求する。

より詳細には、本実施の形態においては、クライアント１００からノードリスト要求を受けた常時接続サーバ２００Ａ，２００Ｂは、対応関係ＤＢ５００からノードリストを取得する。さらに、対応関係ＤＢ５００は、負荷分散装置６００からの要求を受け付けた際に、複数の常時接続サーバ２００Ａ，２００Ｂのいずれかに要求を転送する。このとき、常時接続サーバ２００Ａが要求を受けたとすると、常時接続サーバ２００Ａは、他方、すなわち常時接続サーバ２００Ｂに接続確認用データ（たとえばＩＣＭＰのping）を送信し、その応答があった場合、稼働しているとみなして常時接続サーバ２００Ｂを追加するか、あるいは応答が無かった場合は、稼働していないとみなして常時接続サーバ２００Ｂを削除するよう、対応関係ＤＢ５００にノードリストの更新を要求する。さらに、常時接続サーバ２００Ａは、更新されたノードリスト全体を対応関係ＤＢ５００から取得して、クライアント１００にノードリストを送信する。

このようにして、掃除機用のアプリケーションサーバ３００Ａは、常時接続サーバ２００Ａを介して、掃除機１００Ａにデータをプッシュすることができる。

同様に、エアコン１００Ｄは、Ｗｅｂソケットプロトコルを利用して、常時接続サーバ２００Ａまたは２００Ｂと常時接続している。すなわち、エアコン用のアプリケーションサーバ３００Ｂも、常時接続サーバ２００Ａまたは２００Ｂを介して、エアコン１００Ｄにデータをプッシュすることができる。

本実施の形態においては、常時接続サーバ２００Ａ，２００Ｂとアプリケーションサーバ３００Ａ，３００Ｂの間に、常時接続補助サーバ４００が配備される。常時接続補助サーバ４００は、アプリケーションサーバ３００Ａ，３００Ｂからクライアント１００宛のデータを受信したときに、複数の常時接続サーバ２００Ａ，２００Ｂのどちらに当該クライアント１００が接続されているかを特定するために利用される。

たとえば、常時接続補助サーバ４００は、アプリケーションサーバ３００Ａ，３００Ｂのいずれかから掃除機１００Ａ宛のデータを受信したときに、常時接続サーバ２００Ａ，２００Ｂのどちらに掃除機１００Ａが接続されているか調べる。そして、常時接続補助サーバ４００は、掃除機１００Ａが接続されている方の常時接続サーバ２００Ａに当該データを送信する。

換言すれば、本実施の形態においては、アプリケーションサーバ３００Ａ，３００Ｂのいずれかから常時接続補助サーバ４００がデータを受信したときに、当該データが常時接続サーバ２００Ａと常時接続中の家電に向けたものであるかを判断する。そして、当該データが常時接続サーバ２００Ａと常時接続中の家電（たとえば、掃除機１００Ａ）に向けたものである場合、常時接続補助サーバ４００は常時接続サーバ２００Ａにデータを送信する。常時接続サーバ２００Ａは、Ｗｅｂソケットプロトコルを利用して、当該データを掃除機１００Ａに送信する。

一方、当該データが常時接続サーバ２００Ａと常時接続中の家電に向けたものでない場合、常時接続補助サーバ４００は、当該データの送信先としての家電（たとえば、エアコン１００Ｄ）が常時接続中の常時接続サーバ２００Ｂを特定する。常時接続補助サーバ４００は、当該データを、送信先に指定されたエアコン１００Ｂが常時接続中の常時接続サーバ２００Ｂへと転送する。常時接続サーバ２００Ｂは、Ｗｅｂソケットプロトコルを利用して、当該データをエアコン１００Ｂに送信する。

図２を参照して、掃除機１００Ａと常時接続中の常時接続サーバ２００Ａが正常に稼働しなくなる場合がある。すなわち、常時接続サーバ２００Ａが、メンテナンスのために、一時停止したり、予期しない異常により稼働を停止した場合など、掃除機１００Ａが常時接続サーバ２００Ａと常時接続通信を行えなくなる場合がある。

このような場合は、図３を参照して、掃除機１００Ａは、他の常時接続サーバ２００と常時接続を開始するために、まず、ＨＴＴＰプロトコルを利用して、負荷分散装置６００を介して常時接続サーバ２００のいずれかに、稼働中の常時接続サーバ２００のアドレスが格納されたノードリストを要求する。たとえば、掃除機１００Ａは、当該ノードリストに基づいて、Ｗｅｂソケットプロトコルを利用して、稼働中のノード２としての常時接続サーバ２００Ｂと常時接続を開始するための処理を実行する。

しかしながら、掃除機１００Ａだけでなく、常時接続不能となった常時接続サーバ２００Ａと常時接続していた多数のクライアント１００が、一斉に負荷分散装置６００や他の常時接続サーバ２００Ｂにアクセスする可能性がある。このような事態を回避するために、本実施の形態にかかるネットワークシステム１においては、常時接続不能となった常時接続サーバ２００Ａに常時接続していた多数のクライアント１００が、同じタイミングで負荷分散装置６００や他の常時接続サーバ２００にアクセスする可能性を低減するように構成されている。

具体的には、本実施の形態においては、常時接続不能となった常時接続サーバ２００Ａに常時接続していた多数のクライアント１００が、互いに異なるタイミングで負荷分散装置６００を介して常時接続サーバ２００Ａ，２００Ｂのいずれかにノードリストを要求し、互いに異なるタイミングで常時接続サーバ２００との常時接続するための処理を実行する。図４は、クライアントが負荷分散装置６００にアクセスするタイミングを示すイメージ図である。

図４を参照して、本実施の形態においては、常時接続サーバ２００は、ノードリスト配信時にクライアント１００に再接続間隔Ｔ（秒）を与える。そして、クライアント１００は、１（秒）〜再接続間隔Ｔ（秒）までの間で、ランダムに待ち時間を決定する。ただし、後述の第３の実施の形態のように、常時接続サーバ２００が、待ち時間を決定してもよい。そして、常時接続サーバ２００が、クライアント１００に待ち時間を送信しても良い。

クライアント１００は、常時接続サーバ２００から与えられた再接続間隔に基づいた待ち時間だけ待機した後、負荷分散装置６００を介して常時接続サーバ２００にノードリストを要求する。そして、正常にノードリストが取得できない場合、クライアント１００は、常時接続サーバ２００から与えられた再接続間隔だけ待機した後、再度、負荷分散装置６００を介して常時接続サーバ２００にノードリストを要求する。正常にノードリストが取得できるまで、クライアント１００は、再接続間隔待機することとリストの要求とを繰り返す。

クライアント１００は、取得したノードリストから常時接続サーバ２００Ａを選択する。クライアント１００は、選択した常時接続サーバ２００Ａとの常時接続の開始処理を実行する。常時接続サーバ２００Ａに接続できない場合、クライアント１００は、常時接続サーバ２００のいずれかから与えられた再接続間隔だけ待機した後、ノードリストに記述されている他の常時接続サーバ２００Ｂとの常時接続の開始処理を実行する。正常に常時接続サーバ２００のいずれかへの接続が成功するまで、クライアント１００は、再接続間隔待機することと常時接続開始処理とを繰り返す。

このように、本実施の形態にかかるネットワークシステム１では、常時接続サーバ２００との常時接続が切断された多数のクライアント１００が待ち時間だけ待機してから、再接続処理を開始する。すなわち、多数のクライアント１００が一斉に負荷分散装置６００や常時接続サーバ２００にアクセスしてくることを防止することができる。その結果、クライアント１００と常時接続サーバ２００との再接続処理がスムーズに進行し、常時接続状態への復旧が速やかに行われる。

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

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

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

ＣＰＵ１１０は、メモリ１２０あるいは図示されていない外部の記憶媒体に記憶されているプログラムを実行することによって、クライアント１００の各部を制御する。より詳細には、ＣＰＵ１１０は、メモリ１２０のプログラムを実行することによって後述するクライアントＡＰＰ１１１（図１４および図１５を参照。）およびクライアントＡＰＩ１１２（図１０、図１１、図１４、図１５を参照。）として動作する。より詳細には、クライアントＡＰＰ１１１は、クライアント１００の各部を制御するものであって、いわゆる端末用のアプリケーションプログラムのことである。クライアントＡＰＩ１１２は、後述する通信インターフェイスを介して、ＨＴＴＰプロトコルを使用して通信したり、ＨＴＴＰプロトコル上で利用されるＷｅｂソケットプロトコルを使用して通信したりする。

メモリ１２０は、各種のＲＡＭ（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）などの記憶媒体などによっても実現される。

メモリ１２０は、ＣＰＵ１１０によって実行されるプログラムや、ＣＰＵ１１０によるプログラムの実行により生成されたデータ、ボタン１３０を介して入力されたデータ、掃除機またはエアコンなどのようなクライアントとして動作するＡＰＰ（Application software）データ、クライアントＡＰＰとデータをやり取りしながら常時接続サーバ２００と通信するためのＡＰＩ（Application Programming Interface）データを記憶する。具体的には、メモリ１２０は、常時接続サーバの接続先、アプリケーションサーバ接続先、サービス識別コード、サービス認証トークン、接続ＩＤ、クライアント識別ＩＤなどを記憶する。

ボタン１３０は、ユーザからの命令を受け付けて、当該命令をＣＰＵ１１０に入力する。

ディスプレイ１４０は、液晶パネルなどによって実現され、ＣＰＵ１１０からの信号に基づいて、文字や画像を出力する。

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

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

次に、常時接続サーバ２００のハードウェア構成の一態様について説明する。図６は、本実施の形態にかかる常時接続サーバ２００のハードウェア構成を表わすブロック図である。なお、常時接続サーバ２００は、apache、tomcat、mysqlなど、一般的なサーバモジュールで担保できる機能は標準的に利用可能である。

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

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

メモリ２２０は、ＣＰＵ２１０によって実行されるプログラムや、ＣＰＵ２１０によるプログラムの実行により生成されたデータ、キーボード２３０を介して入力されたデータ、サービスＩＤ、サービス名、アプリケーションサーバ３００の接続先ＵＲＬ、サービス認証トークン生成情報、認証情報（ワンタイムキー）、接続ＩＤなどを記憶する。
＜アプリケーションサーバ３００のハードウェア構成＞

次に、アプリケーションサーバ３００のハードウェア構成の一態様について説明する。図７は、本実施の形態にかかるアプリケーションサーバ３００のハードウェア構成を表わすブロック図である。なお、アプリケーションサーバ３００は、apache、tomcat、mysqlなど、一般的なサーバモジュールで担保できる機能は標準的に利用可能である。

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

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

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

メモリ３２０は、ＣＰＵ３１０によって実行されるプログラムや、ＣＰＵ３１０によるプログラムの実行により生成されたデータ、キーボード３３０を介して入力されたデータ、アプリケーションサーバ３００として動作するためのＡＰＰデータ、サーバＡＰＰとデータをやり取りしながら常時接続サーバ２００と通信するためのＡＰＩデータを記憶する。具体的には、メモリ３２０は、常時接続サーバのＵＲＬ、サービスＩＤとサービス認証トークン、認証情報（ワンタイムキー）生成情報、接続ＩＤ、待機サブルーチンの実行中を示す一時的なフラグ情報（後述）などを記憶する。
＜対応関係ＤＢ＞

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

図１６を参照して、対応関係ＤＢ５００は、クライアント１００とアプリケーションサービスとの組み合わせ毎に、クライアント１００を特定するための接続ＩＤと、アプリケーションサーバ３００が提供するサービスを特定するためのサービスＩＤ（アプリケーション定義データともいう。）と、常時接続サーバ２００を特定するためのノード名（常時接続サーバ２００のアドレスに対応付けられてもよいし、常時接続サーバ２００のアドレスそのものであってもよい。）と、常時接続の開示時刻と、常時接続の利用回数との対応関係を含む。そして、対応関係ＤＢ５００は、本実施形態にかかるネットワークシステム１に含まれる複数のアプリケーションサーバ３００、常時接続補助サーバ４００、および複数の常時接続サーバ２００から参照可能になっている。
＜常時接続補助サーバ４００のハードウェア構成＞

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

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

ＣＰＵ４１０は、メモリ４２０あるいは外部の記憶媒体に記憶されているプログラムを実行することによって、常時接続補助サーバ４００の各部を制御する。具体的には、ＣＰＵ４１０は、メモリ４２０に記憶されているプログラムを実行することによって、常時接続補助機能４１１（図１０を参照。）を実現する。常時接続補助機能４１１は、対応関係ＤＢ５００を参照して、アプリケーションサーバ３００からのデータの宛先であるクライアント１００がどの常時接続サーバ２００と常時接続中であるかを特定する。常時接続補助機能４１１は、通信インターフェイス４６０を介して、アプリケーションサーバ３００からのデータを特定された常時接続サーバ２００に転送する。

メモリ４２０は、ＣＰＵ４１０によって実行されるプログラムや、ＣＰＵ４１０によるプログラムの実行により生成されたデータ、キーボード４３０を介して入力されたデータ、を記憶する。
＜負荷分散装置６００のハードウェア構成＞

負荷分散装置６００のハードウェア構成の一態様について説明する。図９は、本実施の形態にかかる負荷分散装置６００のハードウェア構成を表わすブロック図である。

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

ＣＰＵ６１０は、メモリ６２０あるいは外部の記憶媒体に記憶されているプログラムを実行することによって、負荷分散装置６００の各部を制御する。具体的には、ＣＰＵ６１０は、メモリ６２０に記憶されているプログラムを実行することによって、ＨＴＴＰプロトコルを利用してクライアント１００および他の装置から受信したデータを複数の常時接続サーバ２００に割り振る。

メモリ６２０は、ＣＰＵ６１０によって実行されるプログラムや、ＣＰＵ６１０によるプログラムの実行により生成されたデータ、キーボード６３０を介して入力されたデータ、を記憶する。当該データとして、常時接続サーバ２００から収集した負荷状態を格納する。
＜ネットワークシステム１の機能構成＞

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

図１０を参照して、クライアント１００は、Ｗｅｂソケットプロトコルを使用してノード１としての常時接続サーバ２００Ａと常時接続する。他の多数のクライアント１００も、Ｗｅｂソケットプロトコルを使用してノード１としての常時接続サーバ２００Ａと常時接続する。さらに別の多数のクライアント１００は、Ｗｅｂソケットプロトコルを使用してノード２としての常時接続サーバ２００Ｂと常時接続する。なお、クライアント１００は、ＨＴＴＰプロトコルを使用して、アプリケーションサーバ３００Ａ，３００Ｂ、負荷分散装置６００を経由して、常時接続サーバ２００Ａ，２００Ｂと通信することができる。

より詳細には、クライアントＡＰＩ１１２は、常時接続サーバ２００のいずれかと常時接続を開始する際に、ＨＴＴＰプロトコルを利用して、通信インターフェイス１６０を介して負荷分散装置６００にノードリストを要求する。本実施の形態においては、クライアントＡＰＩ１１２は、ＨＴＴＰプロトコルを利用して、負荷分散装置６００を介して常時接続サーバ２００にノードリストを要求する。

すなわち、負荷分散装置６００は、クライアント１００からの要求に応じて、常時接続サーバ２００Ａ，または２００Ｂのいずれかに最新のノードリストの要求を転送する。

クライアントＡＰＩ１１２は、受信したノードリストの一番目の常時接続サーバ２００を選択する。あるいは、クライアントＡＰＩ１１２は、ノードリストからランダムに常時接続サーバ２００を選択する。あるいは、ノードリストに各常時接続サーバ２００の負荷または接続中のクライアントの数などが含まれている場合、クライアントＡＰＩ１１２は、負荷または接続中のクライアントの数が小さい常時接続サーバ２００を選択する。

クライアントＡＰＩ１１２は、通信インターフェイス１６０を介して、選択された常時接続サーバ２００と常時接続を開始する。

常時接続サーバ２００Ａ，２００ＢのＷＳサーバ２１２Ａ，２１２Ｂは、ＣＰＵ２１０によって実現されるものであって、Ｗｅｂソケットサーバとして、Ｗｅｂソケットプロトコルを利用して、通信インターフェイス２６０を介して、クライアント１００と常時接続する。ＷＳサーバ２１２Ａ，２１２Ｂは、ＨＴＴＰサーバとして、ＨＴＴＰプロトコルを利用して、通信インターフェイス２６０を介して、他の常時接続サーバ２００、アプリケーションサーバ３００、負荷分散装置６００などともデータ通信を行う。

常時接続サーバ２００Ａ，２００ＢのＷＳサーバ２１２Ａ，２１２Ｂは、負荷分散装置６００からの要求に応じて、通信インターフェイス２６０を利用することによって、対応関係ＤＢ５００に最新のノードリストを要求する。対応関係ＤＢ５００は、常時接続サーバ２００Ａ，２００Ｂのいずれかからの要求に応じて、複数の常時接続サーバ２００Ａ，２００Ｂに接続確認を行うことによってノードリストを更新する。

なお、本実施形態においては、常時接続サーバ２００は、ノードリストを含む、以下のようなデータをクライアント１００に送信する。
{"status":0,"reConInterval":600,"handshakeUrl":["ws://example01.com:18080/cpush-server/echo","ws://example02.com:18080/cpush-server/echo"]}

ここで、"reConInterval":600というは、再接続間隔が600秒であることを示す。"handshakeUrl":["ws://example01.com:18080/cpush-server/echo","ws://example02.com:18080/cpush-server/echo"]というのは、複数の常時接続サーバのアドレスを含むノードリストを示す。

そして、本実施の形態にかかる常時接続サーバ２００に関しては、ＷＳサーバ２１２が、定期的に、対応関係ＤＢ５００に格納されているデータから複数の常時接続サーバ２００に接続されているクライアント１００の全数、１つの常時接続サーバ２００の一秒当たりの再接続可能数、稼働中の常時接続サーバ２００の数を取得する。そして、ＷＳサーバ２１２は、以下の式（１）に基づいて再接続間隔Ｔ（秒）を計算する。
（再接続間隔）＝（接続済みクライアント数＋α）÷（１秒当たりの再接続可能数）÷（稼働中の常時接続サーバ数）…（１）

そして、ＷＳサーバ２１２は、通信インターフェイス２６０を介して、クライアント１００のノードリスト要求時に、再接続間隔を常時接続サーバ２００と常時接続しているクライアント１００に配信する。

本実施形態においては、常時接続サーバ２００がノードリストと同時に再接続間隔を送る。しかしながら、常時接続サーバ２００は、ノードリストと再接続間隔とを同時に送る必要はない。たとえば、常時接続サーバ２００は、予め、再接続間隔だけをクライアント１００に送信してもよい。
＜常時接続に関する装置間のデータのやり取り＞

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

まず、クライアントＡＰＩ１１２は、常時接続を開始する際に、通信インターフェイス１６０を利用することによって、負荷分散装置６００を介して常時接続サーバ２００にノードリストを要求する。クライアントＡＰＩ１１２は、ノードリストを参照して、常時接続する常時接続サーバ２００を選択する。

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

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

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

クライアントＡＰＩ１１２は、通信インターフェイス１６０を介して認証情報を常時接続サーバ２００に送信する（ステップＳ０１４）。ＷＳサーバ２１２は、クライアント１００からの認証情報と予め保存している認証情報とに基づいて、クライアント１００を認証する（ステップＳ０１６）。認証に成功すると、ＷＳサーバ２１２は、アプリケーションサーバ３００がクライアント１００を識別するための接続ＩＤを発行するとともに保存している認証情報を削除する。また、ＷＳサーバ２１２は、図１６に示すように、接続ＩＤと常時接続サーバ２００Ａを特定する情報とアプリケーションサービスを特定する情報とを対応付けて、通信インターフェイス２６０を介して当該対応関係を、対応関係ＤＢ５００に登録する。（ステップＳ０１８）。

クライアント１００は、接続ＩＤを受信して、記憶する（ステップＳ０２０）。アプリケーションサーバ３００も、接続ＩＤを受信して、クライアントＩＤと対応付けて記憶する（ステップＳ０２２）。

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

本実施の形態においては、ステップＳ０３３として、アプリケーションサーバ３００からのデータは、常時接続補助サーバ４００が受信する。常時接続補助サーバ４００のＣＰＵ４１０によって実現されるクライアント接続ノード転送機能４１１は、対応関係ＤＢ５００に登録されている接続ＩＤと常時接続サーバとの対応関係に基づいてデータを送信すべき常時接続サーバ２００を選択する。クライアント接続ノード転送４１１は、通信インターフェイス４６０を介して、選択された常時接続サーバ２００にデータを転送する。

常時接続サーバ２００は、常時接続補助サーバ４００からデータ本体と接続ＩＤとを受信する（ステップＳ０３４）。ＷＳサーバ２１２は、接続ＩＤに基づいてクライアント１００を特定する（ステップＳ０３６）。

ＷＳサーバ２１２は、Ｗｅｂソケットプロトコルを使用して、通信インターフェイス２６０を介して、特定されたクライアント１００にデータ本体を送信する（ステップＳ０３８）。クライアント１００は、データ本体を受信する（ステップＳ０４０）。

クライアント１００は、Ｗｅｂソケットプロトコルを使用して、受信結果を常時接続サーバ２００に送信する（ステップＳ０４２）。常時接続サーバ２００は、受信結果を受信すると、当該受信結果をアプリケーションサーバ３００に送信する（ステップＳ０４４）。アプリケーションサーバ３００は、受信結果を受信する（ステップＳ０４６）。

そして、本実施の形態においては、クライアントＡＰＩ１１２が、常時接続サーバ２００との常時接続通信が行えなくなったときに、待ち時間だけ待機してから、通信インターフェイス１６０を利用することによって負荷分散装置６００を介して常時接続サーバ２００に最新のノードリストを要求する。常時接続サーバ２００からのノードリストの取得に失敗した場合、もしくは、ノードリストの取得に成功したが、Ｗｅｂソケット接続に失敗した場合、クライアントＡＰＩ１１２は、再接続間隔待機してから、再度、通信インターフェイス１６０を介して、負荷分散装置６００に最新のノードリストを要求する。以降、ノードリストの取得とＷｅｂソケット接続に成功するまで、クライアントＡＰＩ１１２は、再接続間隔だけ待機してから、負荷分散装置６００を介して常時接続サーバ２００に最新のノードリストを要求する処理を繰り返す。

つまり、常時接続サーバ２００との常時接続通信が行えなくなったとき、クライアントＡＰＩ１１２は、待ち時間だけ待機してから、ステップＳ００２からの処理を繰り返す。ただし、後述する第２の実施の形態において説明するように、既に取得している接続ＩＤに基づいて、認証処理を簡略化することも可能である。

＜クライアント１００における再接続処理＞
次に、本実施の形態にかかるクライアント１００における再接続処理の処理手順について説明する。図１２は、本実施の形態にかかるクライアント１００における再接続処理の処理手順を示すフローチャートである。より詳細には、以下では、主に、クライアント１００のＣＰＵ１１０がプログラムを実行することによって実現されるクライアントＡＰＩ１１２の動作について説明する。

図１２を参照して、クライアントＡＰＩ１１２はクライアントＡＰＰ１１１からの接続開始要求を受け付ける（ステップＳ１０２）。クライアントＡＰＩ１１２は、当該要求に応じて、クライアントＡＰＰ１１１を特定するクライアントＩＤの設定が必要である場合、クライアントＩＤをメモリ１２０に格納する（ステップＳ１０４）。クライアントＡＰＩ１１２は、これから行う予定の常時接続処理が、通常の新たな常時接続処理（初回接続処理ともいう。）であるか、予期せぬ切断による再接続処理であるか否かを判断する（ステップＳ１０６）。

たとえば、クライアントＡＰＩ１１２は、クライアントＡＰＰ１１１から渡されるデータが、クライアントＩＤとして設定されているかどうかで、初回接続処理と再接続処理とを区別する。

本実施の形態においては、クライアントＡＰＩ１１２が初回接続である（あるいは、再接続でない）と判断した場合（ステップＳ１０６にてＹＥＳである場合）、初回接続処理として、クライアントＡＰＩ１１２は、ＷＳ接続用認証情報の取得処理を実施し、アプリケーションサーバ３００から認証情報を取得し、ステップＳ１３２からの処理を実行する（Ｓ１１０）。

一方、クライアントＡＰＩ１１２が再接続である（あるいは、初回接続でない）と判断した場合（ステップＳ１０６にてＮＯである場合）、クライアントＡＰＩ１１２は、再接続処理として、メモリ１２０から再接続間隔を読み出す（ステップＳ１１２）。

本実施の形態においては、上述したように、クライアント１００は、常時接続サーバ２００からノードリストを取得した時に、ノードリストとともに再接続間隔を取得する。ただし、クライアントＡＰＩ１１２は、再接続間隔を未だ取得していない場合、再接続間隔を自身に組み込まれたデフォルト値（たとえば６００秒）とする。

クライアントＡＰＩ１１２は、後述する待機サブルーチンを実行する（ステップＳ１２０）。その後、クライアントＡＰＩ１１２は、通信インターフェイス１６０を利用して、負荷分散装置６００を介して常時接続サーバ２００に、複数の常時接続サーバ２００の情報を含むノードリストと最新の再接続間隔とを要求する（ステップＳ１３２）。

クライアントＡＰＩ１１２は、常時接続サーバ２００からノードリストを取得できなかった場合（ステップＳ１３４にてＮＯの場合）、ステップＳ１０６からの処理を繰り返す。一方、クライアントＡＰＩ１１２は、常時接続サーバ２００からノードリストと再接続間隔を取得できた場合（ステップＳ１３４にてＹＥＳの場合）、メモリ１２０に最新の再接続間隔を記憶する（ステップＳ１３６）。このとき、クライアントＡＰＩ１１２は、後述する待機サブルーチンの実行中を示すフラグをＯＦＦする。

クライアントＡＰＩ１１２は、取得したノードリストに基づいて、常時接続する常時接続サーバ２００を選択する。クライアントＡＰＩ１１２は、通信インターフェイス１６０を介して、選択された常時接続サーバ２００との常時接続を開始するための処理を実行する（ステップＳ１３８、図１１のステップＳ０１０からの処理を参照。）。

クライアントＡＰＩ１１２は、最大で、ノードリストに含まれる常時接続サーバ２００の件数分だけ、上記処理を繰り返す。なお、本実施の形態においては、クライアントＡＰＩ１１２は、ステップＳ１３８において、ノードリスト上で未だ常時接続を試みていない常時接続サーバ２００との常時接続を試みる。

クライアントＡＰＩ１１２は、選択されたすべての常時接続サーバ２００との常時接続に失敗すると（ステップＳ１４０にてＮＯの場合）、ステップＳ１０６からの処理を繰り返す。

クライアントＡＰＩ１１２は、選択された常時接続サーバ２００との常時接続に成功すると（ステップＳ１４０にてＹＥＳである場合）、認証処理を実行する（ステップＳ１４２、図１１のステップＳ０１４からの処理を参照）。
＜クライアント１００における待機サブルーチン＞

次に、本実施の形態にかかるクライアント１００における待機サブルーチンの処理手順について説明する。図１３は、本実施の形態にかかるクライアント１００における待機サブルーチンの処理手順を示すフローチャートである。以下では、主に、クライアント１００のＣＰＵ１１０がプログラムを実行することによって実現されるクライアントＡＰＩ１１２の動作について説明する。

図１３を参照して、クライアントＡＰＩ１１２は、待機サブルーチンの実行が初めてか否かを判断する（ステップＳ１２２）。たとえば、クライアントＡＰＩ１１２は、待機サブルーチンの実行中を示すフラグがＯＮであるか否かを確認し、ＯＦＦの場合を１回目であるとし、ＯＮの場合は２回目以降であるとする。

待機サブルーチンの実行が１回目である場合（ステップＳ１２２にてＹＥＳである場合）、クライアントＡＰＩ１１２は、待機サブルーチンの実行中を示すフラグをＯＮする。クライアントＡＰＩ１１２は、待ち時間を生成する（ステップＳ１２４）。より詳細には、クライアントＡＰＩ１１２は、１秒から再接続間隔Ｔ秒までの間で、待ち時間をランダムに設定する。クライアントＡＰＩ１１２は、待ち時間だけ待機して（ステップＳ１２６）、待機サブルーチンから再接続処理に戻る。

待機サブルーチンの実行が２回目以降である場合（ステップＳ１２２にてＮＯである場合）、クライアントＡＰＩ１１２は、再接続間隔を待ち時間とする（ステップＳ１２８）。クライアントＡＰＩ１１２は、待ち時間だけ待機して（ステップＳ１２６）、待機サブルーチンから再接続処理に戻る。

このように、本実施の形態にかかるネットワークシステム１では、常時接続サーバ２００との常時接続が切断された多数のクライアント１００の各々が、待ち時間だけ待機してから、再接続処理を開始する。すなわち、多数のクライアント１００が一斉に負荷分散装置６００や常時接続サーバ２００にアクセスしてくることを防止することができる。その結果、クライアント１００と常時接続サーバ２００との再接続処理がスムーズに進行し、常時接続状態への復旧が速やかに行われる。
＜第２の実施の形態＞

次に、第２の実施の形態について説明する。第１の実施の形態にかかるネットワークシステム１では、再接続処理を行う際には、再度認証処理を行う必要があった。しかしながら、本実施の形態においては、接続ＩＤを利用することによって認証処理を簡略化するものである。

本実施の形態にかかるネットワークシステム１の全体構成や各部のハードウェア構成は、第１の実施の形態のそれと同様であるため、説明を繰り返さない。以下では、本実施の形態にかかるネットワークシステム１における初回接続処理の処理手順と再接続処理の処理手順とについて説明する。
＜初回接続処理の処理手順＞

まず、本実施の形態にかかる初回接続処理の処理手順について説明する。図１４は、本実施の形態にかかる初回接続処理の処理手順を示すシーケンス図である。

図１４を参照して、クライアントＡＰＰ１１１は、アプリケーションサーバ３００との常時接続を開始するための要求を、クライアントＡＰＩ１１２に受け渡す（ステップＳ２０２）。このとき、クライアントＡＰＰ１１１は、クライアントＡＰＩ１１２にクライアントＩＤを受け渡す。クライアントＡＰＩ１１２は、クライアントＩＤを受け取らなかったときは、以下のように、初期接続処理を実行する。

クライアントＡＰＩ１１２は、クライアントＡＰＰ１１１にアプリケーションサーバ３００への接続を要求する（ステップＳ２０４）。クライアントＡＰＰ１１１は、通信インターフェイス１６０を介して、ＨＴＴＰプロトコルを利用してアプリケーションサーバ３００に接続開始を要求する（ステップＳ２０６）。クライアントＡＰＰ１１１は、アプリケーションサーバ３００から認証情報を受信して、当該認証情報をクライアントＡＰＩ１１２に受け渡す。

クライアントＡＰＩ１１２は、通信インターフェイス１６０を利用することによって、負荷分散装置６００を介していずれかの常時接続サーバ２００にノードリストを要求する（ステップＳ２０８）。クライアントＡＰＩ１１２は、ノードリストに基づいて、常時接続を試みる常時接続サーバ２００を選択する。クライアントＡＰＩ１１２は、常時接続サーバ２００との常時接続を開始するための処理を実行するためにＷＳ接続スレッドを起動する（ステップＳ２１０）。

クライアントＡＰＩ１１２は、通信インターフェイス１６０を利用することによって、Ｗｅｂソケットプロトコルを使用して、常時接続サーバ２００にＷｅｂソケットハンドシェイク要求を送信する（ステップＳ２１２）。ＷＳサーバ２１２は、通信インターフェイス２６０を介して、ハンドシェイク応答をクライアント１００に返す（ステップＳ２１６）。これによって、クライアント１００と常時接続サーバ２００とのＷｅｂソケットプロトコルによる常時接続が開始される。

なお、クライアントＡＰＩ１１２は、常時接続サーバ２００とのハンドシェイクに失敗すると、再度ノードリストに基づいて、他の常時接続サーバ２００を選択する。そして、クライアントＡＰＩ１１２は、ステップＳ２１２からの処理を繰り返す。

クライアントＡＰＩ１１２は、通信インターフェイス１６０を介して、Ｗｅｂソケットプロトコルを使用して、常時接続サーバ２００に認証情報を送信する（ステップＳ２１８）。ＷＳサーバ２１２は、アプリケーションサーバ３００からの認証情報とクライアント１００からの認証情報とに基づいてクライアント１００を認証する。

認証に成功すると、ＷＳサーバ２１２は、接続ＩＤを発行する。ＷＳサーバ２１２は、通信インターフェイス２６０を介して、接続確立状況としてクライアント１００の接続ＩＤをアプリケーションサーバ３００とクライアント１００とに送信する（ステップＳ２２０）。

クライアントＡＰＩ１１２は、クライアントＡＰＰ１１１に常時接続が開始された旨を通知する（ステップＳ２２４）。なお、常時接続サーバ２００が認証に失敗した場合は、クライアントＡＰＩ１１２は、ステップＳ２０４からの処理を繰り返す。
＜再接続処理の処理手順＞

次に、本実施の形態にかかる再接続処理の処理手順について説明する。図１５は、本実施の形態にかかる再接続処理の処理手順を示すシーケンス図である。

図１５を参照して、クライアントＡＰＰ１１１は、アプリケーションサーバ３００との常時接続を開始するための要求を、クライアントＡＰＩ１１２に受け渡す（ステップＳ２５２）。このとき、クライアントＡＰＰ１１１は、クライアントＡＰＩ１１２にクライアントＩＤを受け渡す。クライアントＡＰＰ１１１は、クライアントＩＤを受け取ったときは、以下のように、再接続処理を実行する。

クライアントＡＰＩ１１２は、前述した待機サブルーチンを実行し、待ち時間だけ待機する（ステップＳ２５７）。クライアントＡＰＩ１１２は、待機後、通信インターフェイス１６０を利用することによって、負荷分散装置６００を介していずれかの常時接続サーバ２００にノードリストを要求する（ステップＳ２５８）。

クライアントＡＰＩ１１２は、ノードリストを取得できなかった場合、再接続間隔だけ待機してから、再度、通信インターフェイス１６０を利用することによって、負荷分散装置６００を介していずれかの常時接続サーバ２００にノードリストを要求する。

クライアントＡＰＩ１１２は、ノードリストを取得できた場合、ノードリストに含まれる再接続間隔を記憶し、ノードリストに含まれるノードのリストに基づいて、常時接続を試みる常時接続サーバ２００を選択する。クライアントＡＰＩ１１２は、常時接続サーバ２００との常時接続を開始するための処理を実行するためにＷＳ接続スレッドを起動する（ステップＳ２６０）。

クライアントＡＰＩ１１２は、通信インターフェイス１６０を利用することによって、Ｗｅｂソケットプロトコルを使用して、常時接続サーバ２００にハンドシェイク要求を送信する（ステップＳ２６２）。ＷＳサーバ２１２は、通信インターフェイス２６０を介して、ハンドシェイク応答をクライアント１００に返す（ステップＳ２６６）。これによって、クライアント１００と常時接続サーバ２００とのＷｅｂソケットプロトコルによる常時接続が開始される。

なお、クライアントＡＰＩ１１２は、常時接続サーバ２００とのハンドシェイクに失敗すると、再度ノードリストに基づいて、他の常時接続サーバ２００を選択する。そして、クライアントＡＰＩ１１２は、ステップＳ２６０からの処理を繰り返す。

クライアントＡＰＩ１１２は、通信インターフェイス１６０を介して、Ｗｅｂソケットプロトコルを使用して、常時接続サーバ２００にクライアントＩＤを送信する（ステップＳ２６８）。ＷＳサーバ２１２は、接続ＩＤをアプリケーションサーバ３００に送信することによって、クライアント１００を認証する。

認証に成功すると、ＷＳサーバ２１２は、認証に成功した旨をクライアント１００とアプリケーションサーバ３００とに通知する（ステップＳ２７０）。クライアントＡＰＩ１１２は、クライアントＡＰＰ１１１に常時接続が開始された旨を通知する（ステップＳ２７４）。

なお、常時接続サーバ２００が認証に失敗した場合は、クライアントＡＰＩ１１２は、初回接続処理のステップＳ２０４（図１４を参照。）からの処理を繰り返す。

このように、本実施の形態にかかるネットワークシステム１においても、常時接続サーバ２００との常時接続が切断された多数のクライアント１００の各々が、待ち時間だけ待機してから、再接続処理を開始する。すなわち、多数のクライアント１００が一斉に負荷分散装置６００や常時接続サーバ２００にアクセスしてくることを防止することができる。その結果、クライアント１００と常時接続サーバ２００との再接続処理がスムーズに進行し、常時接続状態への復旧が速やかに行われる。
＜第３の実施の形態＞

上記の第１および第２の実施の形態では、常時接続サーバ２００が再接続間隔を計算し、クライアント１００が再接続間隔に基づいて待ち時間を計算するものであった。つまり、常時接続サーバ２００が、再接続間隔をクライアント１００に配信するものであった。

しかしながら、第３の実施の形態にかかるネットワークシステムとして、常時接続サーバ２００が再接続間隔を計算し、再接続間隔に基づいて待ち時間までも計算してもよい。つまり、常時接続サーバ２００が、再接続間隔と一緒に、待ち時間もクライアント１００に配信してもよい。
＜第４の実施の形態＞

上記の第１から第３の実施の形態では、クライアント１００が、１（秒）〜再接続間隔Ｔ（秒）までの間で、ランダムに待ち時間を決定するものであった。

しかしながら、第４の実施の形態にかかるネットワークシステムとして、常時接続サーバ２００のＣＰＵ２１０、アプリケーションサーバ３００のいずれかが、常時接続によるデータ送受信の頻度に基づいて、待ち時間を決定してもよい。より詳細には、それらのＣＰＵは、クライアント１００と常時接続サーバ２００（あるいはサーバＡＰＰ）との組み合わせ毎の、単位時間当たりのＷｅｂソケットプロトコルを利用したデータ送受信の回数（頻度）を対応関係ＤＢ５００に格納する。そして、ＣＰＵは、Ｗｅｂソケットプロトコルを利用した送受信の頻度が高い組み合わせほど、待ち時間が短くなるように、待ち時間を設定する。たとえば、ＣＰＵは、存在するクライアント全数に対する当該クライアントの送受信の回数の相対度数を算出し、これと再接続間隔Ｔ（秒）との積を求めることにより、待ち時間を決定する。

これによって、常時接続によるデータの送受信を頻繁に行うクライアント１００と常時接続サーバ２００との組み合わせほど、常時接続が早く復旧する。その結果、常時接続が切断された場合に、アプリケーションサーバ３００からクライアント１００に情報をプッシュできないことによる不具合が生じる可能性を低減することができる。
＜第５の実施の形態＞

上記の第１および第２の実施の形態では、負荷分散装置６００が稼働中の常時接続サーバ２００のアドレスが格納されたノードリストをクライアント１００に送信するものであった。そして、クライアント１００が、ノードリストに基づいて、常時接続を開始する常時接続サーバ２００を選択するものであった。

しかしながら、第５の実施の形態として、常時接続サーバ２００が、稼働中の常時接続サーバ２００のアドレスが格納されたノードリストに基づいて、クライアント１００と常時接続すべき（たとえば、現在の負荷が小さい）常時接続サーバ２００を選択してもよい。この場合は、常時接続サーバ２００は、選択された常時接続サーバ２００のみを含むノードリストをクライアント１００に送信する。そして、クライアント１００は、ノードリストに指定された常時接続サーバ２００と常時接続を開始する。
＜第６の実施の形態＞

上記の第１および第２の実施の形態では、負荷分散装置６００は、クライアント１００からノードリストの要求を受け付けたときに、常時接続サーバ２００にノードリストを要求する。さらに、常時接続サーバ２００は、その他複数の常時接続サーバ２００に接続確認用データ（ping）を送信し、その応答に基づいて対応関係ＤＢ５００のノードリストを更新する。さらに、常時接続サーバ２００は、負荷分散装置６００から転送された要求に応じて対応関係ＤＢ５００からノードリストを取得する。

しかしながら、第６の実施の形態として、常時接続サーバ２００は、定期的に、その他複数の常時接続サーバ２００に接続確認用データ（ping）を送信し、その応答に基づいて対応関係ＤＢ５００のノードリストを更新しておく。そして、常時接続サーバ２００は、負荷分散装置６００からの要求に応じて対応関係ＤＢ５００からノードリストを取得してもよい。
＜第７の実施の形態＞

あるいは、第７の実施の形態として、常時接続サーバ２００が、定期的に、その他複数の常時接続サーバ２００に接続確認用データ（ping）を送信し、その応答に基づいてノードリストを更新し、更新した最新のノードリストをその他の常時接続サーバ２００に送信しておき、さらに、常時接続サーバ２００が、クライアント１００からの要求に応じて、予め受信していたノードリストをクライアント１００に送信してもよい。
＜第８の実施の形態＞

上記の実施の形態では、クライアント１００は、負荷分散装置６００を介して常時接続サーバ２００から再接続用間隔およびノードリストを取得するものであった。しかしながら、第８の実施の形態として、クライアント１００は、サービスを提供しているアプリケーションサーバ３００を介して、常時接続サーバ２００から再接続用間隔およびノードリストを取得してもよい。

具体的には、クライアント１００は、常時接続サーバ２００との常時接続が切断されると、ＨＴＴＰプロトコルを利用して、アプリケーションサーバ３００にノードリスト要求および／または再接続用間隔要求を送信する。アプリケーションサーバ３００は、複数の常時接続サーバ２００のいずれかまたは対応関係ＤＢ５００にノードリストおよび／または再接続間隔を要求する。複数の常時接続サーバ２００のいずれかまたは対応関係ＤＢ５００は、ノードリストおよび／または再接続間隔をアプリケーションサーバ３００に返す。アプリケーションサーバ３００は、ＨＴＴＰプロトコルを利用して、クライアント１００にノードリストおよび／または再接続間隔を送信する。
＜第９の実施の形態＞

上記の実施の形態では、クライアント１００は、常時接続サーバ２００との常時接続が切断されると、再接続時間待機してから、常時接続サーバ２００と再接続するための処理を開始するものであった。しかしながら、第９の実施の形態として、クライアント１００は、常時接続サーバ２００との常時接続が切断されると、所定の条件を満たした場合にのみ再接続時間待機してから常時接続サーバ２００と再接続するための処理を開始し、所定の条件を満たさない場合は待機せずに即時に常時接続サーバ２００と再接続するための処理を開始してもよい。

たとえば、常時接続サーバ２００を起因とする常時接続の切断の時だけ、クライアント１００は再接続用間隔待機する。逆に、クライアント１００が原因となって常時接続を切断した場合は、クライアント１００は即時に再接続のための処理を開始する。

具体例として、常時接続サーバ２００が常時接続を切断した場合以外の理由で常時接続が切断された場合（クライアントＡＰＩの再起動など）に、クライアント１００がフラグ情報を一時領域に記憶（フラグをＯＮ）する。そして、再接続時に、クライアント１００は、このフラグ情報がＯＮか否かを判断する。クライアント１００は、フラグ情報がＯＮの場合、即時に再接続のための処理を開始する。クライアント１００は、再接続に成功したときにフラグをＯＦＦする。一方、クライアント１００は、フラグ情報がＯＦＦの場合、再接続用間隔待機してから再接続のための処理を開始する。

換言すれば、クライアント１００が原因で常時接続が切断された場合（クライアントＡＰＩの再起動など）に、クライアント１００がフラグ情報を一時領域に記憶（フラグをＯＮ）する。

これにより、再接続を分散させる必要の無い時に、待ち時間、すなわち常時接続を利用した機能が利用できない時間を低減することが可能になる。
＜第１０の実施の形態＞

上記の実施の形態では、ネットワークシステム１が複数の常時接続サーバ２００を含むものであった。しかしながら、ネットワークシステム１は、１つの常時接続サーバ２００を含むものであってもよい。

この場合は、クライアント１００は、常時接続サーバ２００にノードリストを要求する必要がない。しかしながら、クライアント１００は、常時接続サーバ２００から再接続用間隔を受信する必要がある。すなわち、クライアント１００は、常時接続が切断された際に、１〜再接続用間隔（秒）の間の待ち時間または再接続用間隔だけ待機してから、ノードリストを要求することなく、以前に常時接続していた常時接続サーバ２００とハンドシェイク処理を開始する。

そして、本実施の形態にかかる常時接続サーバ２００に関しては、ＷＳサーバ２１２が、定期的に、対応関係ＤＢ５００または常時接続サーバ２００に格納されているデータから常時接続サーバ２００に接続されているクライアント１００の数、常時接続サーバ２００の一秒当たりの再接続可能数を取得する。そして、ＷＳサーバ２１２は、以下の式（２）基づいて再接続間隔Ｔ（秒）を計算する。
（再接続間隔）＝（接続済みクライアント数＋α）÷（１秒当たりの再接続可能数）…（２）
＜その他の応用例＞

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

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

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

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

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

１ ：ネットワークシステム
１００ ：クライアント
１１０ ：ＣＰＵ
１１１ ：クライアントＡＰＰ
１１２ ：クライアントＡＰＩ
１２０ ：メモリ
１５０ ：家電制御回路
１６０ ：通信インターフェイス
２００ ：常時接続サーバ
２１０ ：ＣＰＵ
２１２ ：ＷＳサーバ
２２０ ：メモリ
２６０ ：通信インターフェイス
３００ ：アプリケーションサーバ
３１０ ：ＣＰＵ
３１２ ：サーバＡＰＩ
３２０ ：メモリ
３６０ ：通信インターフェイス
４００ ：常時接続補助サーバ
４１０ ：ＣＰＵ
４２０ ：メモリ
４６０ ：通信インターフェイス
５００ ：対応関係ＤＢ
６００ ：負荷分散装置
６１０ ：ＣＰＵ
６１１ ：リスト提供機能
６２０ ：メモリ
６６０ ：通信インターフェイス

Claims (14)

1. 電子機器と、
   前記電子機器と常時接続可能な常時接続サーバとを備え、
   前記常時接続サーバは、前記常時接続サーバに関する再接続用間隔を含む情報を前記電子機器に送信し、
   前記電子機器は、
   前記電子機器に起因せずに常時接続が切断されたと判断した時に、前記再接続用間隔に基づいて算出される時間の待機後、前記常時接続サーバとの常時接続が成功するまで、常時接続するための処理を繰り返し、
   前記電子機器に起因して常時接続が切断されたと判断した時に、前記待機を実行せずに、常時接続するための処理を開始する、ネットワークシステム。
2. 前記常時接続サーバは、前記電子機器毎に前記再接続用間隔を上限とした待ち時間を作成し、前記電子機器に前記待ち時間を送信し、
   前記電子機器は、前記常時接続サーバとの常時接続が切断されたときに、前記待ち時間だけ待機してから常時接続するための処理を行う、請求項１に記載のネットワークシステム。
3. 前記電子機器は、前記再接続用間隔を上限とした待ち時間を作成し、前記常時接続サーバとの常時接続が切断されたときに、前記待ち時間だけ待機してから常時接続するための処理を行う、請求項１に記載のネットワークシステム。
4. 前記待ち時間は、前記電子機器と前記常時接続サーバとの常時接続によるデータの送受信の頻度に基づいて作成される、請求項２または３に記載のネットワークシステム。
5. 前記常時接続サーバは、前記常時接続サーバと接続中の複数の電子機器の数と、１つの常時接続サーバの１秒当たりの再接続可能な電子機器の数と、に基づいて前記再接続用間隔を計算する、請求項１から４のいずれか１項に記載のネットワークシステム。
6. 前記常時接続サーバとして、前記電子機器と常時接続可能な複数の常時接続サーバを備え、
   前記複数の常時接続サーバの少なくとも１つは、前記複数の常時接続サーバに関する情報を前記電子機器に送信し、
   前記電子機器は、前記複数の常時接続サーバのいずれかとの常時接続が成功するまで、前記情報に基づいて前記複数の常時接続サーバに順に常時接続を試みる、請求項１から４のいずれか１項に記載のネットワークシステム。
7. 前記複数の常時接続サーバの少なくとも１つは、前記複数の常時接続サーバと接続中の複数の電子機器の数と、１つの常時接続サーバの１秒当たりの再接続可能な電子機器の数と、稼働中の常時接続サーバの個数とに基づいて前記再接続用間隔を計算する、請求項６に記載のネットワークシステム。
8. 前記電子機器は、前記常時接続サーバとの常時接続が成功するまで、前記再接続用間隔をあけながら常時接続するための処理を繰り返す、請求項１から７のいずれか１項に記載のネットワークシステム。
9. 前記常時接続サーバは、他のサーバを介して、前記再接続用間隔を含む情報を前記電子機器に送信する、請求項１から８のいずれか１項に記載のネットワークシステム。
10. 前記電子機器は、前記電子機器が原因で常時接続が切断された際に、その旨を示すための情報を記憶する、請求項１から９のいずれか１項に記載の電子機器。
11. 電子機器と前記電子機器と常時接続可能な常時接続サーバとを含むネットワークシステムにおける常時接続方法であって、
    前記常時接続サーバが、再接続用間隔を含む情報を前記電子機器に送信するステップと、
    前記電子機器と前記常時接続サーバとの常時接続が切断されるステップと、
    前記電子機器が、前記電子機器に起因して常時接続が切断されたか否かを判断するステップと、
    前記電子機器が、前記電子機器に起因せずに常時接続が切断されたと判断した時に、前記情報を利用することによって、前記再接続用間隔に基づいて算出される時間の待機後、前記常時接続サーバとの常時接続が成功するまで、常時接続するための処理を繰り返し、前記電子機器に起因して常時接続が切断されたと判断した時に、前記待機を実行せずに、常時接続するための処理を開始するステップとを備える、常時接続方法。
12. 常時接続サーバと常時接続可能な通信インターフェイスと、
    電子機器に起因せずに常時接続が切断されたと判断した時に、前記常時接続サーバに関する情報を利用することによって、前記常時接続サーバのいずれかから与えられた再接続用間隔に基づいて算出される時間の待機後、前記常時接続サーバとの常時接続が成功するまで、常時接続するための処理を繰り返し、前記電子機器に起因して常時接続が切断されたと判断した時に、前記待機を実行せずに、常時接続するための処理を開始するためのプロセッサとを備える、電子機器。
13. メモリをさらに備え、
    前記プロセッサは、前記電子機器が原因で常時接続が切断された際に、その旨を示すための情報を前記メモリに記憶する、請求項１２に記載の電子機器。
14. プロセッサと通信インターフェイスとを含む電子機器で利用されるプログラムであって、
    前記通信インターフェイスを介して、常時接続サーバから再接続用間隔を含む情報を受信するステップと、
    前記電子機器に起因して常時接続が切断されたか否かを判断するステップと、
    前記電子機器に起因せずに常時接続が切断されたと判断した時に、前記情報を利用することによって、前記再接続用間隔に基づいて算出された時間の待機後、前記常時接続サーバとの常時接続が成功するまで、前記常時接続サーバと常時接続するための処理を繰り返し、前記電子機器に起因して常時接続が切断されたと判断した時に、前記待機を実行せずに、常時接続するための処理を開始するステップとを前記プロセッサに実行させる、プログラム。

Images