(57)【要約】【課題】複数の中継サーバのうち端末装置が接続を確立すべき中継サーバを適切に決定することができる接続管理装置、通信システム、接続管理方法およびプログラムを提供する。【解決手段】実施形態の接続管理装置は、第１記憶部と、更新部と、要求受付部と、決定部と、を備える。第１記憶部は、複数の中継装置それぞれについて、負荷状態と端末接続数との少なくとも一方を含む状態情報を記憶する。更新部は、所定の規則に従って前記第１記憶部を更新する。要求受付部は、任意の端末装置から、当該端末装置が接続を確立すべき中継装置の決定要求を受け付ける。決定部は、前記第１記憶部が記憶する前記状態情報に基づき、前記決定要求の要求元の端末装置が接続を確立すべき中継装置を決定する。【選択図】図３
2015170286.tif 000002
【特許請求の範囲】
【請求項１】
予め対応付けられた２つの端末装置間の通信を中継する中継装置が複数設けられた通信システムにおいて、端末装置が接続を確立すべき中継装置を決定して当該端末装置に通知する接続管理装置であって、
複数の中継装置それぞれについて、負荷状態と端末接続数との少なくとも一方を含む状態情報を記憶する第１記憶部と、
所定の規則に従って前記第１記憶部を更新する更新部と、
任意の端末装置から、当該端末装置が接続を確立すべき中継装置の決定要求を受け付ける要求受付部と、
前記第１記憶部が記憶する前記状態情報に基づき、前記決定要求の要求元の端末装置が接続を確立すべき中継装置を決定する決定部と、を備える接続管理装置。
【請求項２】
前記更新部は、前記状態情報を定期的に取得して前記第１記憶部を更新する第１更新部と、前記状態情報を不定期に取得して前記第１記憶部を更新する第２更新部と、を含む請求項１に記載の接続管理装置。
【請求項３】
前記第２更新部は、前記決定要求に中継装置の識別情報が含まれている場合に、当該識別情報で識別される中継装置から前記状態情報を取得して前記第１記憶部を更新し、
前記決定部は、前記第２更新部による更新後の前記第１記憶部が記憶する前記状態情報に基づき、前記決定要求の要求元の端末装置が接続を確立すべき中継装置を決定する、請求項２に記載の接続管理装置。
【請求項４】
前記第２更新部は、前記決定要求に前記状態情報の更新要求が含まれている場合に、前記状態情報を取得して前記第１記憶部を更新し、
前記決定部は、前記第２更新部による更新後の前記第１記憶部が記憶する前記状態情報に基づき、前記決定要求の要求元の端末装置が接続を確立すべき中継装置を決定する、請求項２に記載の接続管理装置。
【請求項５】
前記第２更新部は、さらに、中継装置との間の通信不良が検出されたときに前記第１記憶部を更新する、請求項３または４に記載の接続管理装置。
【請求項６】
前記第２更新部は、中継装置との間の接続の切断が検出されたときに前記第１記憶部を更新する、請求項５に記載の接続管理装置。
【請求項７】
前記第２更新部は、中継装置との間の疎通確認の失敗が検出されたときに前記第１記憶部を更新する、請求項５に記載の接続管理装置。
【請求項８】
前記決定部は、複数の中継装置のうち、負荷状態が低い中継装置または端末接続数が少ない中継装置を、前記決定要求の要求元の端末装置が接続を確立すべき中継装置として決定する、請求項１〜７のいずれか一項に記載の接続管理装置。
【請求項９】
すでに接続が確立されている端末装置と中継装置との対応関係を示す管理情報を記憶する第２記憶部をさらに備え、
前記決定部は、前記第１記憶部が記憶する前記状態情報および前記第２記憶部が記憶する前記管理情報に基づき、前記決定要求の要求元の端末装置が接続を確立すべき中継装置を決定する、請求項１〜８のいずれか一項に記載の接続管理装置。
【請求項１０】
前記決定部は、予め対応付けられた２つの端末装置のうちの一方の端末装置がすでに中継装置と接続を確立している状態で、他方の端末装置からの前記決定要求を前記要求受付部が受け付けた場合に、一方の端末装置が接続を確立している中継装置を、他方の端末装置が接続を確立すべき中継装置として決定する、請求項９に記載の接続管理装置。
【請求項１１】
前記決定部は、他方の端末装置からの前記決定要求を前記要求受付部が受け付けたときに、一方の端末装置が接続を確立している中継装置の負荷状態または端末接続数が閾値を超えている場合は、一方の端末装置が接続を確立している中継装置に対して一方の端末装置との接続の切断を指示し、中継装置との接続が切断された一方の端末装置からの前記決定要求を前記要求受付部が受け付けたときに、前記第１記憶部が記憶する前記状態情報に基づき、一方の端末装置と他方の端末装置とが接続を確立すべき中継装置として同一の中継装置を決定する、請求項１０に記載の接続管理装置。
【請求項１２】
請求項１〜１１のいずれか一項に記載の接続管理装置と、
複数の端末装置と、
複数の中継装置と、を含み、
前記端末装置は、
前記接続管理装置に対して前記決定要求を行う決定要求部と、
前記接続管理装置から通知された中継装置に対して接続要求を行う接続要求部と、を備え、
前記中継装置は、前記接続要求を受け付けて、端末装置との接続を確立する接続確立部を備える、通信システム。
【請求項１３】
前記接続確立部は、前記接続要求の要求元の端末装置とのＷｅｂＳｏｃｋｅｔによる接続を確立する、請求項１２に記載の通信システム。
【請求項１４】
前記接続管理装置は、請求項３に記載の接続管理装置であり、
前記決定要求部は、前記接続管理装置から通知された中継装置との接続に失敗したときに、当該中継装置の識別子を含む前記決定要求を前記接続管理装置に対して行う、請求項１２または１３に記載の通信システム。
【請求項１５】
前記決定要求部は、さらに、中継装置との接続が切断されたときに、当該中継装置の識別子を含む前記決定要求を前記接続管理装置に対して行う、請求項１４に記載の通信システム。
【請求項１６】
前記接続管理装置は、請求項４に記載の接続管理装置であり、
前記決定要求部は、前記接続管理装置から通知された中継装置との接続に失敗したときに、前記更新要求を含む前記決定要求を前記接続管理装置に対して行う、請求項１２または１３に記載の通信システム。
【請求項１７】
前記決定要求部は、さらに、中継装置との接続が切断されたときに、前記更新要求を含む前記決定要求を前記接続管理装置に対して行う、請求項１６に記載の通信システム。
【請求項１８】
予め対応付けられた２つの端末装置間の通信を中継する中継装置が複数設けられた通信システムにおいて、端末装置が接続を確立すべき中継装置を決定して当該端末装置に通知する接続管理装置により実行される接続管理方法であって、
前記接続管理装置は、複数の中継装置それぞれについて、負荷状態と端末接続数との少なくとも一方を含む状態情報を記憶する記憶部を備え、
所定の規則に従って前記記憶部を更新する工程と、
任意の端末装置から、当該端末装置が接続を確立すべき中継装置の決定要求を受け付ける工程と、
前記記憶部が記憶する前記状態情報に基づき、前記決定要求の要求元の端末装置が接続を確立すべき中継装置を決定する工程と、を含む接続管理方法。
【請求項１９】
予め対応付けられた２つの端末装置間の通信を中継する中継装置が複数設けられた通信システムにおいて、端末装置が接続を確立すべき中継装置を決定して当該端末装置に通知する接続管理装置として用いるコンピュータにより実行されるプログラムであって、
前記コンピュータは、複数の中継装置それぞれについて、負荷状態と端末接続数との少なくとも一方を含む状態情報を記憶する記憶部を備え、
前記コンピュータに、
所定の規則に従って前記記憶部を更新する機能と、
任意の端末装置から、当該端末装置が接続を確立すべき中継装置の決定要求を受け付ける機能と、
前記記憶部が記憶する前記状態情報に基づき、前記決定要求の要求元の端末装置が接続を確立すべき中継装置を決定する機能と、を実現させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明の実施形態は、接続管理装置、通信システム、接続管理方法およびプログラムに関する。
【背景技術】
【０００２】
従来、確立した通信接続を維持することで再接続コストをなくし、低遅延化を実現するＷｅｂ標準の通信プロトコルとして、ＷｅｂＳｏｃｋｅｔが知られている。ＷｅｂＳｏｃｋｅｔは、例えば、スマートフォンなどの携帯端末から中継サーバを介して、ネットワークに接続された宅内機器などに制御コマンドを送信して機器を制御する、いわゆるスマートリモコンなどのアプリケーションで利用されている。
【０００３】
このようなアプリケーションをサービスとして提供する事業者は、多数のクライアントによる同時接続に対応できるようにするために、中継サーバを複数台設けて、携帯端末や宅内機器などの端末装置との間のＷｅｂＳｏｃｋｅｔ接続を、複数の中継サーバに分散させる場合がある。この場合、端末装置による通信のパフォーマンスが接続先の中継サーバの負荷状態や端末接続数などに依存して変化することがある。このため、新たに接続を要求する端末装置をどの中継サーバに接続させるかを適切に決定する仕組みの構築が求められている。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２０１２−１７５６０６号公報
【特許文献２】特開２０１３−２１８４５２号公報
【特許文献３】特開２０１２−３７９４４号公報
【非特許文献】
【０００５】
【非特許文献１】I．Fette，A．Melnikov，“The  WebSocket  Protocol”，［online］，December  2011，IETF  RFC6455，［平成２６年２月２７日検索］，インターネット＜URL：http://tools.ietf.org/html/rfc6455＞
【非特許文献２】山口  秀夫，宮里  系一郎，“「ＷｅｂＳｏｃｋｅｔ」の活用でリモコンをスマートに”，日経エレクトロニクス  ｎｏ．１１０８，日本，日経ＢＰ社，２０１３年５月１３日，ｐ．７１−７９
【発明の概要】
【発明が解決しようとする課題】
【０００６】
本発明が解決しようとする課題は、複数の中継サーバのうち端末装置が接続を確立すべき中継サーバを適切に決定することができる接続管理装置、通信システム、接続管理方法およびプログラムを提供することである。
【課題を解決するための手段】
【０００７】
実施形態の接続管理装置は、予め対応付けられた２つの端末装置間の通信を中継する中継装置が複数設けられた通信システムにおいて、端末装置が接続を確立すべき中継装置を決定して当該端末装置に通知する。実施形態の接続管理装置は、第１記憶部と、更新部と、要求受付部と、決定部と、を備える。第１記憶部は、複数の中継装置それぞれについて、負荷状態と端末接続数との少なくとも一方を含む状態情報を記憶する。更新部は、所定の規則に従って前記第１記憶部を更新する。要求受付部は、任意の端末装置から、当該端末装置が接続を確立すべき中継装置の決定要求を受け付ける。決定部は、前記第１記憶部が記憶する前記状態情報に基づき、前記決定要求の要求元の端末装置が接続を確立すべき中継装置を決定する。
【図面の簡単な説明】
【０００８】
【図１】実施形態の通信システムの概要を説明する図。
【図２】ＷｅｂＳｏｃｋｅｔ接続を確立するまでの処理の概要を示すシーケンス図。
【図３】実施形態の通信システムの機能的な構成例を示すブロック図。
【図４】状態記憶部が記憶する状態情報の一例を示す図。
【図５】管理情報記憶部が記憶する管理情報の一例を示す図。
【図６】定期更新の概要を示すシーケンス図。
【図７】状態情報が書き換わる様子を示す図。
【図８】不定期更新を含む接続管理サーバの処理手順を示すフローチャート。
【図９】実施形態の通信システムにおける具体的な動作例を示すシーケンス図。
【図１０】実施形態の通信システムにおける具体的な動作例を示すシーケンス図。
【図１１】記憶装置を含まない通信システムの構成を説明する図。
【図１２】接続管理装置のハードウェア構成の一例を示す図。
【発明を実施するための形態】
【０００９】
図１は、本実施形態の通信システムの概要を説明する図である。本実施形態の通信システムは、図１に示すように、接続管理サーバ１００（接続管理装置）と、複数の中継サーバ２００Ａ，２００Ｂ，・・・（中継装置）と、複数の端末装置３００Ａ，３００Ｂ，・・・とを含む。なお、図１では２つの中継サーバ２００Ａ，２００Ｂおよび２つの端末装置３００Ａ，３００Ｂを図示しているが、中継サーバの数および端末装置の数は任意である。また、接続管理サーバ１００を複数設けて冗長性を持たせるようにしてもよい。
【００１０】
端末装置３００Ａと端末装置３００Ｂは、双方向通信を行うペアとして予め対応付けられているものとする。ここで、本実施形態の通信システムにおいて、端末装置３００Ａと端末装置３００ＢとがＷｅｂＳｏｃｋｅｔによる双方向通信を行う際の手順の概要を説明する。なお、以下では、複数の中継サーバ２００Ａ，２００Ｂ，・・・を総称する場合は中継サーバ２００と表記し、複数の端末装置３００Ａ，３００Ｂ，・・・を総称する場合は端末装置３００と表記する。
【００１１】
１つ目の端末装置３００Ａは、ウェブ上の中継サーバ２００Ａに対してＷｅｂＳｏｃｋｅｔによる接続確立を行い、接続された状態を維持する。２つ目の端末装置３００Ｂも同様に、中継サーバ２００Ａに対してＷｅｂＳｏｃｋｅｔによる接続を確立する。中継サーバ２００Ａは、これら２つの端末装置３００Ａ，３００Ｂの間で双方向通信を行うことを予め認識しているものとする。中継サーバ２００Ａは、２つの端末装置３００Ａ，３００Ｂの双方との接続が確立された後、一方の端末装置３００（例えば端末装置３００Ｂ）からＷｅｂＳｏｃｋｅｔ接続を介してデータが送出されると、このデータを他方の端末装置３００（例えば端末装置３００Ａ）との間のＷｅｂＳｏｃｋｅｔ接続へ転送する。転送されたデータを受信した端末装置３００（例えば端末装置３００Ａ）は、このデータを利用する。
【００１２】
このように、中継サーバ２００Ａにおいて端末装置３００Ａ，３００ＢのＷｅｂＳｏｃｋｅｔ接続の対を収容することにより、端末装置３００Ａ，３００ＢがＮＡＴ（Network  Address  Translation）の内側にいる場合など、端末装置３００Ａ，３００Ｂ同士の直接接続が困難な場合においても、端末装置３００Ａ，３００Ｂ間の双方向通信を実現することができる。このような仕組みは、例えば携帯端末から宅内機器を遠隔制御するスマートリモコンなどのアプリケーションに応用できる。
【００１３】
以上の説明では、端末装置３００Ａ，３００Ｂが、ＷｅｂＳｏｃｋｅｔ接続を確立すべき中継サーバ２００Ａを認識していることを前提としている。しかし、本実施形態の通信システムでは、多数のクライアント（端末装置３００）による同時接続に対応するために、複数の中継サーバ２００を設けている。このような構成では、端末装置３００はどの中継サーバ２００に対してＷｅｂＳｏｃｋｅｔ接続を確立すべきかを知る必要がある。そこで、本実施形態の通信システムでは、端末装置３００からの要求に応じて端末装置３００がＷｅｂＳｏｃｋｅｔ接続を確立すべき中継サーバ２００を決定し、例えばその中継サーバ２００の識別情報であるサーバＩＤを要求元の端末装置３００に通知する接続管理サーバ１００を設けている。
【００１４】
図２は、本実施形態の通信システムにおいて、端末装置３００が中継サーバ２００に対してＷｅｂＳｏｃｋｅｔ接続を確立するまでの処理の概要を示すシーケンス図である。
【００１５】
端末装置３００は、まず初めに接続管理サーバ１００に対して接続先決定要求を行い（ステップＳ１０１）、ＷｅｂＳｏｃｋｅｔ接続を確立すべき中継サーバ２００のサーバＩＤを取得する（ステップＳ１０２）。そして、端末装置３００は、取得したサーバＩＤによって識別される中継サーバ２００に対してＷｅｂＳｏｃｋｅｔ接続要求を行う（ステップＳ１０３）。これにより、中継サーバ２００は、端末装置３００からの接続要求に応じて、端末装置３００との間のＷｅｂＳｏｃｋｅｔ接続を確立する処理を行う（ステップＳ１０４）。
【００１６】
接続管理サーバ１００は、上記ステップＳ１０１における端末装置３００からの接続先決定要求を受け付けると、複数の中継サーバ２００のうち、端末装置３００がＷｅｂＳｏｃｋｅｔ接続を確立すべき中継サーバ２００を決定して、その中継サーバ２００のサーバＩＤを端末装置３００に通知する。この際、接続管理サーバ１００は、複数の中継サーバ２００それぞれについて、現時点での負荷状態（例えばリソース使用状況）や端末接続数（すでにＷｅｂＳｏｃｋｅｔ接続を確立している端末装置３００の数）などの情報（以下、状態情報という。）に応じ、特定の中継サーバ２００に負荷が集中しないよう配慮して、端末装置３００の接続先となる中継サーバ２００を決定する。これにより、多数の端末装置３００が通信システムを利用する場合であっても、負荷の分散を図ることが可能となる。
【００１７】
しかし、このような通信システムでは、複数の中継サーバ２００のいずれかに障害が生じた際に、接続管理サーバ１００がそのことを知らずに、障害が生じた中継サーバ２００を端末装置３００の接続先として決定してしまう可能性がある。ここで、接続管理サーバ１００が中継サーバ２００の状態情報を適当な時間間隔で取得することで、中継サーバ２００の異常を検出することは可能である。しかし、状態情報の取得と取得の間のタイミングで障害が生じたときに、接続管理サーバ１００は、次に状態情報を取得する時刻までは中継サーバ２００の障害を認識することができない。このため、それまでに端末装置３００から接続先決定要求があった場合に、その端末装置３００の接続先として障害のある中継サーバ２００を決定し、その中継サーバ２００のサーバＩＤを端末装置３００に通知してしまう可能性がある。また、接続管理サーバ１００が中継サーバ２００の状態情報を取得する時間間隔を小さくすることで、障害を認識するまでの時間を短縮することが可能となるが、この場合は、接続管理サーバ１００と中継サーバ２００双方の負荷増加を招いてしまう。
【００１８】
そこで、本実施形態では、接続管理サーバ１００が定期的に複数の中継サーバ２００の状態情報を取得することに加えて、必要に応じて中継サーバ２００の状態情報を不定期に取得して、記憶している状態情報を更新する。これにより、接続管理サーバ１００と中継サーバ２００の双方の負荷増加を抑えつつ、中継サーバ２００に障害が生じた際には接続管理サーバ１００がそのことを速やかに認識できるようにして、端末装置３００がＷｅｂＳｏｃｋｅｔ接続を確立すべき中継サーバ２００を適切に決定できるようにしている。
【００１９】
図３は、本実施形態の通信システムの機能的な構成例を示すブロック図である。本実施形態では、接続管理サーバ１００と中継サーバ２００および端末装置３００とが、ＨＴＴＰ（Hypertext  Transfer  Protocol）ベースの要求（ＨＴＴＰリクエスト）と応答（ＨＴＴＰレスポンス）のやり取りを行うことを想定する。また、本実施形態では、図３に示すように、接続管理サーバ１００および複数の中継サーバ２００のそれぞれがアクセス可能な記憶装置４００が設けられている。
【００２０】
まず、中継サーバ２００について説明する。複数の中継サーバ２００には、それぞれ固有の識別情報であるサーバＩＤが与えられている。本実施形態では、一例として、中継サーバ２００のＩＰ（Internet  Protocol）アドレスを、その中継サーバ２００のサーバＩＤとして用いるものとする。なお、サーバＩＤはＩＰアドレスに限らず、中継サーバ２００を一意に識別できる情報であればよい。
【００２１】
中継サーバ２００は、ＷｅｂＳｏｃｋｅｔサーバとして機能するものであり、例えば図３に示すように、状態取得部２１０と、取得要求受付部２２０と、接続確立部２３０とを備える。なお、複数の中継サーバ２００の構成は共通である。
【００２２】
状態取得部２１０は、予め定められた時間間隔で定期的に当該中継サーバ２００の状態情報を取得し、中継サーバ２００のサーバＩＤと対応付けて記憶装置４００に登録する。また、状態取得部２１０は、取得要求受付部２２０からの依頼に応じて当該中継サーバ２００の状態情報を不定期に取得し、取得した状態情報を取得要求受付部２２０に返す。
【００２３】
取得要求受付部２２０は、接続管理サーバ１００から状態情報の取得要求があったときに、この取得要求を受け付けて、状態取得部２１０に対して状態情報の取得を依頼する。そして、取得要求受付部２２０は、状態取得部２１０が取得要求受付部２２０からの依頼に応じて不定期に取得した状態情報を、取得要求に対する応答として接続管理サーバ１００に通知する。
【００２４】
接続確立部２３０は、端末装置３００からＷｅｂＳｏｃｋｅｔ接続要求があったときに、このＷｅｂＳｏｃｋｅｔ接続要求を受け付けて、ＲＦＣ６４５５で定められた手順により（非特許文献１参照）、要求元の端末装置３００との間のＷｅｂＳｏｃｋｅｔ接続を確立する。なお、接続確立部２３０は、要求元の端末装置３００との間のＷｅｂＳｏｃｋｅｔ接続の確立に失敗した場合、要求元の端末装置３００に対し、接続失敗を示すステータス情報を通知する。
【００２５】
次に、端末装置３００について説明する。複数の端末装置３００には、それぞれ固有の識別情報である端末ＩＤが与えられている。本実施形態では、一例として、端末装置３００のＩＰアドレスを、その端末装置３００の端末ＩＤとして用いるものとする。なお、端末ＩＤはＩＰアドレスに限らず、端末装置３００を一意に識別できる情報であればよい。なお、中継サーバ２００を介して双方向通信する端末装置３００のペアは、それらの端末装置３００の端末ＩＤが対応付けられて、接続管理装置１００および中継サーバ２００に予め登録されているものとする。
【００２６】
端末装置３００は、ＷｅｂＳｏｃｋｅｔクライアントとして機能するものであり、例えば図３に示すように、決定要求部３１０と、接続要求部３２０とを備える。なお、複数の端末装置３００は、ＷｅｂＳｏｃｅｔクライアントとしての機能については、共通の構成である。
【００２７】
決定要求部３１０は、接続管理サーバ１００に対して、当該端末装置３００がＷｅｂＳｏｃｋｅｔ接続を確立すべき中継サーバ２００の決定要求（接続先決定要求）を行う。そして、決定要求部３１０は、この接続先決定要求に対する応答として接続管理サーバ１００から通知された、ＷｅｂＳｏｃｋｅｔ接続を確立すべき中継サーバ２００のサーバＩＤを取得して、取得したサーバＩＤを接続要求部３２０に渡す。
【００２８】
接続要求部３２０は、決定要求部３１０から渡されたサーバＩＤをもとに、当該サーバＩＤで識別される中継サーバ２００に対してＷｅｂＳｏｃｋｅｔ接続要求を行って、中継サーバ２００に当該端末装置３００とのＷｅｂＳｏｃｋｅｔ接続を確立させる。この際、中継サーバ２００からＷｅｂＳｏｃｋｅｔ接続の確立に失敗したことを示す接続失敗のステータス情報が通知された場合、接続要求部３２０は、そのステータス情報を中継サーバ２００のサーバＩＤとともに決定要求部３１０に渡す。
【００２９】
接続要求部３２０から接続失敗のステータス情報を渡された決定要求部３１０は、接続管理サーバ１００に対して、接続先決定要求を再度行う。この際、決定要求部３１０は、接続管理サーバ１００に対して、接続要求部３２０からステータス情報とともに渡されたサーバＩＤ、つまり、ＷｅｂＳｏｃｋｅｔ接続の確立に失敗した中継サーバ２００のサーバＩＤを含む接続先決定要求を行う。
【００３０】
また、決定要求部３１０は、中継サーバ２００との間ですでに確立されていたＷｅｂＳｏｃｋｅｔ接続が切断された場合にも、接続管理サーバ１００に対して、ＷｅｂＳｏｃｋｅｔ接続が切断された中継サーバ２００のサーバＩＤを含む接続先決定要求を行う。このようなＷｅｂＳｏｃｋｅｔ接続の切断の要因としては、例えば、中継サーバ２００の障害発生や、端末装置３００と中継サーバ２００との間に介在するネットワーク機器の障害発生などが挙げられる。また、詳細を後述するように、接続管理サーバ１００から中継サーバ２００に対して切断要求が行われることによって、ＷｅｂＳｏｃｋｅｔ接続が切断される場合もある。
【００３１】
次に、接続管理サーバ１００について説明する。接続管理サーバ１００は、ＨＴＴＰサーバとして機能するものであり、例えば図３に示すように、状態記憶部１１０（第１記憶部）と、更新部１２０と、取得要求部１３０と、要求受付部１４０と、管理情報記憶部１５０（第２記憶部）と、決定部１６０とを備える。
【００３２】
状態記憶部１１０は、複数の中継サーバ２００それぞれの状態情報を記憶する。図４は、状態記憶部１１０が記憶する状態情報の一例を示す図である。状態記憶部１１０は、複数の中継サーバ２００それぞれの状態情報として、例えば図４に示すように、ＣＰＵ使用率および使用可能メモリ量などの負荷状態と端末接続数とを、中継サーバ２００のサーバＩＤに対応付けて記憶している。
【００３３】
更新部１２０は、所定の規則に従って状態記憶部１１０を更新する。本実施形態では、この更新部１２０が、定期更新部１２１（第１更新部）と、不定期更新部１２２（第２更新部）とを含んだ構成となっている。
【００３４】
定期更新部１２１は、予め定められた時間間隔で定期的に記憶装置４００にアクセスし、複数の中継サーバ２００のそれぞれが定期的に記憶装置４００に登録した状態情報を取得して、状態記憶部１１０を更新する。なお、定期更新部１２１が記憶装置４００にアクセスするタイミングや周期は、複数の中継サーバ２００が記憶装置４００に状態情報を登録するタイミングや周期と一致させる必要はない。
【００３５】
不定期更新部１２２は、例えば要求受付部１４０が端末装置３００から特定の中継サーバ２００のサーバＩＤを含む接続先決定要求を受け付けた場合など、不定期なタイミングで中継サーバ３００から状態情報を取得して、状態記憶部１１０を更新する。具体的には、不定期更新部１２２は、要求受付部１４０から例えばサーバＩＤを指定した状態情報の更新依頼があると、取得要求部１３０に対して、そのサーバＩＤで識別される中継サーバ２００に対する状態情報の取得要求を依頼する。そして、不定期更新部１２２は、取得要求部１３０が中継サーバ２００から通知された状態情報を受け取って、状態記憶部１１０を更新する。
【００３６】
取得要求部１３０は、不定期更新部１２２からの依頼に応じて、指定された中継サーバ２００に対して状態情報の取得要求を行う。そして、取得要求部１３０は、この取得要求に対する応答として中継サーバ２００から通知された状態情報を受け取り、不定期更新部１２２に渡す。
【００３７】
要求受付部１４０は、端末装置３００からの接続先決定要求を受け付けて、決定部１６０に対して、要求元の端末装置３００がＷｅｂＳｏｃｋｅｔ接続を確立すべき中継サーバ２００の決定を依頼する。そして、要求受付部１４０は、決定部１６０によって中継サーバ２００が決定されると、その中継サーバ２００のサーバＩＤを、接続先決定要求に対する応答として要求元の端末装置３００に通知する。
【００３８】
また、要求受付部１４０は、端末装置３００からの接続先決定要求に中継サーバ２００のサーバＩＤが含まれていた場合には、このサーバＩＤを指定して、不定期更新部１２２に対して状態情報の更新を依頼する。
【００３９】
管理情報記憶部１５０は、すでにＷｅｂＳｏｃｋｅｔ接続が確立されている端末装置３００と中継サーバ２００との対応関係を示す管理情報を記憶する。図５は、管理情報記憶部１５０が記憶する管理情報の一例を示す図である。管理情報記憶部１５０は、例えば図５に示すように、ＷｅｂＳｏｃｋｅｔ接続が確立されている端末装置３００の端末ＩＤと中継サーバ２００のサーバＩＤとを対応付けた管理情報を記憶している。この管理情報には、接続先決定要求を行った端末装置３００がＷｅｂＳｏｃｋｅｔ接続を確立すべき中継サーバ２００が決定部１６０によって決定されるたびに、その端末装置３００の端末ＩＤと中継サーバ３００のサーバＩＤとを対応付けた新たなレコードが追加される。また、端末装置３００と中継サーバ２００とのＷｅｂＳｏｃｋｅｔ接続の切断が端末装置３００または中継サーバ２００から通知されると、この管理情報の対応するレコードが削除される。
【００４０】
決定部１６０は、要求受付部１４０からの依頼を受けて、複数の中継サーバ２００のうち、接続先決定要求の要求元の端末装置３００がＷｅｂＳｏｃｋｅｔ接続を確立すべき中継サーバ２００を決定する。この際、決定部１６０は、状態記憶部１１０が記憶する状態情報と、管理情報記憶部１５０が記憶する管理情報とに基づき、端末装置３００がＷｅｂＳｏｃｋｅｔ接続を確立すべき中継サーバ２００を決定する。
【００４１】
具体的には、決定部１６０は、双方向通信を行う端末装置３００のペア（図１に示した端末装置３００Ａ，３００Ｂ）のうち、先に接続先決定要求を行った端末装置３００（端末装置３００Ａ）に対しては、状態記憶部１１０が記憶する状態情報を参照し、複数の中継サーバ２００のうち、負荷状態が低い中継サーバ２００または端末接続数が少ない中継サーバ２００を、ＷｅｂＳｏｃｋｅｔ接続を確立すべき中継サーバ２００として決定する。
【００４２】
一方、後に接続先決定要求を行った端末装置３００（端末装置３００Ｂ）に対しては、決定部１６０は、管理情報記憶部１５０が記憶する管理情報を参照し、先に接続先決定要求を行った端末装置３００（端末装置３００Ａ）がＷｅｂＳｏｃｋｅｔ接続を確立している中継サーバ２００を、後に接続先決定要求を行った端末装置３００（端末装置３００Ｂ）がＷｅｂＳｏｃｋｅｔ接続を確立すべき中継サーバ２００として決定する。つまり、双方向通信を行う端末装置３００のペアを同じ中継サーバ２００に接続させる。
【００４３】
また、このとき決定部１６０は、状態記憶部１１０が記憶する状態情報を参照して、先に接続先決定要求を行った端末装置３００（端末装置３００Ａ）がＷｅｂＳｏｃｋｅｔ接続を確立している中継サーバ２００の負荷状態または端末接続数を確認する。そして、この中継サーバ２００の負荷状態または端末接続数が予め定めた閾値を超えている場合は、決定部１６０は、この中継サーバ２００に対して、端末装置３００（端末装置３００Ａ）とのＷｅｂＳｏｃｋｅｔ接続の切断を指示する。そして、決定部１６０は、中継サーバ２００とのＷｅｂＳｏｃｋｅｔ接続が切断された端末装置３００（端末装置３００Ａ）からの接続先決定要求を要求受付部１４０が受け付けたときに、双方の端末装置３００（端末装置３００Ａ，３００Ｂ）がＷｅｂＳｏｃｋｅｔ接続を確立すべき中継サーバ２００として、負荷状態が低いまたは端末接続数が少ない同一の中継サーバ２００を決定する。
【００４４】
決定部１６０は、以上のように決定した中継サーバ２００のサーバＩＤを、要求受付部１４０に渡す。また、決定部１６０は、接続決定要求の要求元の端末装置３００の端末ＩＤと、決定した中継サーバ２００のサーバＩＤとを対応付けて、管理情報記憶部１５０が記憶する管理情報に、新たなレコードを追加する。
【００４５】
次に、本実施形態の通信システムにより行われる処理について、図面を適宜参照しながら具体的に説明する。以下では、端末装置３００と中継サーバ２００との間のＷｅｂＳｏｃｋｅｔ接続を確立する処理（接続確立）、接続管理サーバ１００が中継サーバ２００の状態情報を定期的に取得して状態記憶部１１０を更新する処理（定期更新）、接続管理サーバ１００が不定期に中継サーバ２００から状態情報を取得して状態記憶部１１０を更新する処理（不定期更新）の順に、各処理の説明を行う。
【００４６】
なお、以下では、端末装置３００Ａ（端末ＩＤ（ＩＰアドレス）＝１９２．１６８．０．３）と、端末装置３００Ｂ（端末ＩＤ（ＩＰアドレス）＝１９２．１６８．０．４）とが双方向通信を行うものとして説明する。これら双方向通信を行う端末装置３００Ａと端末装置３００Ｂとの対応関係は、上述したように、例えば端末ＩＤを対応付けた情報として、接続管理サーバ１００および中継サーバ２００に予め静的に登録されているものとする。なお、端末装置３００Ａと端末装置３００Ｂとの対応関係は、必ずしもこのような形態で接続管理サーバ１００および中継サーバ２００に認識させる必要はない。例えば、端末装置３００Ａと端末装置３００Ｂとの双方に同一のグループＩＤを割り当てることにより、これら端末装置３００Ａと端末装置３００Ｂとが双方向通信を行うペアであることを識別できる。この場合、端末装置３００と接続管理サーバ１００や中継サーバ２００との間の通信において、端末装置３００の端末ＩＤとは別にこのグループＩＤを合わせて通知することにより、双方向通信を行う端末装置３００の対応関係を接続管理サーバ１００や中継サーバ２００に認識させることができる。
【００４７】
（接続確立）
まず、端末装置３００Ａが接続管理サーバ１００によって決定された中継サーバ２００にＷｅｂＳｏｃｋｅｔ接続要求を行って、端末装置３００Ａと中継サーバ２００との間のＷｅｂＳｏｃｋｅｔ接続が確立されるまでの処理の流れを説明する。
【００４８】
端末装置３００Ａは、例えば端末装置３００Ａを使用するユーザによるユーザインタフェースの操作など、任意のタイミングを契機として処理を開始する。まず、端末装置３００Ａの決定要求部３１０が、接続管理サーバ１００に対して、接続先決定要求を表すＨＴＴＰリクエストを送出する。送出されたＨＴＴＰリクエストは、接続管理サーバ１００の要求受付部１４０によって受信される。要求受付部１４０は、端末装置３００ＡからのＨＴＴＰリクエストを受け取ると、決定部１６０に対して、端末装置３００ＡがＷｅｂＳｏｃｋｅｔ接続を確立すべき中継サーバ２００の決定を依頼する。
【００４９】
決定部１６０は、要求受付部１４０からの依頼を受けて、まず状態記憶部１１０に記憶された状態情報の読み出しを行う。状態記憶部１１０には、図４に示したように、複数の中継サーバ２００それぞれの状態情報（図４の例ではＣＰＵ使用率、使用可能メモリ量、および端末接続数）が、各中継サーバ２００のサーバＩＤ（図４の例ではＩＰアドレス）に対応付けて記憶されている。決定部１６０は、状態記憶部１１０から読み出した状態情報に基づき、複数の中継サーバ２００のうち、負荷状態が低い中継サーバ２００または端末接続数が少ない中継サーバ２００を、ＷｅｂＳｏｃｋｅｔ接続を確立すべき中継サーバ２００として決定する。
【００５０】
例えば、決定部１６０は、端末接続数が最小となる中継サーバ２００を、端末装置３００ＡがＷｅｂＳｏｃｋｅｔ接続を確立すべき中継サーバ２００として決定する。図４に示した例の場合、サーバＩＤ＝１９２．１６８．０．２の中継サーバ２００の方が、サーバＩＤ＝１９２．１６８．０．１の中継サーバ２００よりも端末接続数が少ないため、サーバＩＤ＝１９２．１６８．０．２の中継サーバ２００が選択される。
【００５１】
決定部１６０は、端末装置３００ＡがＷｅｂＳｏｃｋｅｔ接続を確立すべき中継サーバ２００を決定すると、その中継サーバ２００のサーバＩＤ＝１９２．１６８．０．２を、要求受付部１４０に渡す。また、決定部１６０は、端末装置３００Ａの端末ＩＤ＝１９２．１６８．０．３と、決定した中継サーバ２００のサーバＩＤ＝１９２．１６８．０．２とを対応付けて、管理情報記憶部１５０が記憶する管理情報のレコードに追加する。これにより、図５に示したように、端末ＩＤ＝１９２．１６８．０．３とサーバＩＤ＝１９２．１６８．０．２との組みが、管理情報として管理情報記憶部１５０に記憶される。
【００５２】
要求受付部１４０は、決定部１６０から中継サーバ２００のサーバＩＤ＝１９２．１６８．０．２が渡されると、このサーバＩＤを含むＨＴＴＰレスポンスを、端末装置３００Ａに対して応答する。
【００５３】
端末装置３００Ａの決定要求部３１０は、接続先決定要求を表すＨＴＴＰリクエストの応答として、サーバＩＤ＝１９２．１６８．０．２を含むＨＴＴＰレスポンスを受信すると、このＨＴＴＰレスポンスに含まれるサーバＩＤ＝１９２．１６８．０．２を接続要求部３２０に渡す。接続要求部３２０は、決定要求部３１０からサーバＩＤ＝１９２．１６８．０．２が渡されると、このサーバＩＤで識別される中継サーバ２００に対し、ＷｅｂＳｏｃｋｅｔ接続要求として、ＷｅｂＳｏｃｋｅｔ接続確立のためのハンドシェイク要求を送出する。以降、ＲＦＣ６４５５で定められた手順に従って接続確立の処理が行われ、端末装置３００Ａと中継サーバ２００との間のＷｅｂＳｏｃｋｅｔ接続が確立される。
【００５４】
次に、端末装置３００Ａと中継サーバ２００との間のＷｅｂＳｏｃｋｅｔ接続が確立されている状態で、端末装置３００Ｂが接続管理サーバ１００によって決定された中継サーバ２００にＷｅｂＳｏｃｋｅｔ接続要求を行って、端末装置３００Ｂと中継サーバ２００との間のＷｅｂＳｏｃｋｅｔ接続が確立されるまでの処理の流れを説明する。
【００５５】
端末装置３００Ｂは、端末装置３００Ａと同様の手順により、接続管理サーバ１００に対してＨＴＴＰリクエストを送出する。送出されたＨＴＴＰリクエストは、接続管理サーバ１００の要求受付部１４０によって受信される。要求受付部１４０は、端末装置３００ＢからのＨＴＴＰリクエストを受け取ると、決定部１６０に対して、端末装置３００ＢがＷｅｂＳｏｃｋｅｔ接続を確立すべき中継サーバ２００の決定を依頼する。
【００５６】
決定部１６０は、要求受付部１４０からの依頼を受けて、まず管理情報記憶部１５０を参照し、端末装置３００Ｂとペアとなる端末装置３００Ａの端末ＩＤ＝１９２．１６８．０．３を含むレコードが存在するかどうかを確認する。ここでは、管理情報記憶部１５０に、図５に示した管理情報が記憶されているものとする。そこで決定部１６０は、端末装置３００Ａの端末ＩＤ＝１９２．１６８．０．３と対応付けられているサーバＩＤ＝１９２．１６８．０．２を持つ中継サーバ２００を、端末装置３００ＢがＷｅｂＳｏｃｋｅｔ接続を確立すべき中継サーバ２００として決定する。
【００５７】
決定部１６０は、端末装置３００ＢがＷｅｂＳｏｃｋｅｔ接続を確立すべき中継サーバ２００を決定すると、その中継サーバ２００のサーバＩＤ＝１９２．１６８．０．２を、要求受付部１４０に渡す。また、決定部１６０は、端末装置３００Ｂの端末ＩＤ＝１９２．１６８．０．４と、決定した中継サーバ２００のサーバＩＤ＝１９２．１６８．０．２とを対応付けて、管理情報記憶部１５０が記憶する管理情報のレコードに追加する。
【００５８】
要求受付部１４０は、決定部１６０から中継サーバ２００のサーバＩＤ＝１９２．１６８．０．２が渡されると、このサーバＩＤを含むＨＴＴＰレスポンスを、端末装置３００Ｂに対して応答する。
【００５９】
端末装置３００Ｂの決定要求部３１０は、サーバＩＤ＝１９２．１６８．０．２を含むＨＴＴＰレスポンスを受信すると、このＨＴＴＰレスポンスに含まれるサーバＩＤ＝１９２．１６８．０．２を接続要求部３２０に渡す。接続要求部３２０は、決定要求部３１０からサーバＩＤ＝１９２．１６８．０．２が渡されると、このサーバＩＤで識別される中継サーバ２００に対し、ＷｅｂＳｏｃｋｅｔ接続要求として、ＷｅｂＳｏｃｋｅｔ接続確立のためのハンドシェイク要求を送出する。以降、ＲＦＣ６４５５で定められた手順に従って接続確立の処理が行われ、端末装置３００Ｂと中継サーバ２００との間のＷｅｂＳｏｃｋｅｔ接続が確立される。
【００６０】
（定期更新）
次に、接続管理サーバ１００が中継サーバ２００の状態情報を定期的に取得して状態記憶部１１０を更新する処理の流れを、図６を参照しながら説明する。図６は、定期更新の概要を示すシーケンス図である。なお、図６では一つの中継サーバ２００の処理のみを記載しているが、複数の中継サーバ２００で同様の処理が行われる。
【００６１】
中継サーバ２００の状態取得部２１０は、予め定められた定期的なタイミングで処理を開始し、任意の手段で自身の状態情報を取得する。例えば状態取得部２１０は、ＯＳ（Operating  System）が提供するＡＰＩ（Application  Programming  Interface）を利用してＣＰＵ使用率やメモリ使用量の値を取得したり、接続確立部２３０に対して問い合わせを行って現在接続状態にあるＷｅｂＳｏｃｋｅｔ接続の個数の値を取得したりする。
【００６２】
状態取得部２１０は、状態情報の取得を完了すると、取得した状態情報を自身のサーバＩＤとともに記憶装置４００に出力し、登録を依頼する。状態取得部２１０は、予め定められた定期的なタイミングで以上の処理を繰り返し行う（ステップＳ２０１−１、ステップＳ２０１−２、ステップＳ２０１−３）。記憶装置４００は、中継サーバ２００から状態情報登録の依頼を受けるたびに、中継サーバ２００から送られた状態情報をサーバＩＤと対応付けて記憶する。このとき、記憶装置４００は、中継サーバ２００から送られたサーバＩＤに対応する状態情報がすでに存在する場合は、この状態情報を新たに送られた状態情報で上書き更新する。
【００６３】
一方、接続管理サーバ１００の定期更新部１２１は、予め定められた定期的なタイミングで処理を開始し、記憶装置４００に対して状態情報の読み出しを要求する。そして、定期更新部１２１は、記憶装置４００から読み出された状態情報を取得して（ステップＳ２０２）、取得した状態情報により状態記憶部１１０を更新する（ステップＳ２０３）。定期更新部１２１は、予め定められた定期的なタイミングで以上の処理を繰り返し行う。定期更新部１２１が以上の処理を行うタイミングや周期は、中継サーバ２００が状態情報を記憶装置４００に登録するタイミングや周期と一致させる必要はない。定期更新部１２１が以上の処理を行う周期を長くすることで、接続管理サーバ１００の負荷を低減させることができる。
【００６４】
（不定期更新）
次に、接続管理サーバ１００が不定期に中継サーバ２００から状態情報を取得して状態記憶部１１０を更新する処理の流れを説明する。
【００６５】
接続管理サーバ１００の不定期更新部１２２は、例えば、端末装置３００と中継サーバ２００との間のＷｅｂＳｏｃｅｔ接続確立が失敗したことを契機として、不定期に処理を開始する。すなわち、端末装置３００の決定要求部３１０は、上述したように、中継サーバ２００から接続失敗のステータス情報が通知されると、接続管理サーバ１００に対して再度、接続先決定要求を表すＨＴＴＰリクエストを送出する。この際、決定要求部３１０は送出するＨＴＴＰリクエストに、先に接続確立失敗した中継サーバ２００のサーバＩＤ（上述した例ではサーバＩＤ＝１９２．１６８．０．２）を付加する。
【００６６】
接続管理サーバ１００の要求受付部１４０は、端末装置３００からのＨＴＴＰリクエストを受信した際に、このＨＴＴＰリクエストにサーバＩＤの情報が付加されているか否かを確認する。そして、受信したＨＴＴＰリクエストにサーバＩＤが付加されている場合、要求受付部１４０は、このサーバＩＤを不定期更新部１２２に渡して状態情報の更新を依頼する。これを受けて不定期更新部１２２は、サーバＩＤを取得要求部１３０に渡して状態情報の取得要求を依頼する。これを受けて取得要求部１３０は、当該サーバＩＤで識別される中継サーバ２００に対し、状態情報の取得要求を表すＨＴＴＰリクエストを送出する。
【００６７】
中継サーバ２００の取得要求受付部２２０は、接続管理サーバ１００からのＨＴＴＰリクエストを受信すると、状態取得部２１０に対して状態情報の取得を依頼する。これを受けて状態取得部２１０は、自身の状態情報を取得して取得要求受付部２２０に渡す。取得要求受付部２２０は、この状態情報を含むＨＴＴＰレスポンスを生成し、ＨＴＴＰリクエストに対する応答として接続管理サーバ１００に送出する。
【００６８】
接続管理装置１００の取得要求部１３０は、中継サーバ２００からのＨＴＴＰレスポンスを受信すると、このＨＴＴＰレスポンスから状態情報を取り出して不定期更新部１２２に渡す。そして、不定期更新部１２２は、取得要求部１３０から受け取った状態情報により状態記憶部１１０を更新する。この処理によって状態記憶部１１０が記憶する状態情報が書き換わる様子を図７に示す。図７の例では、不定期更新部１２２による状態情報の更新の結果、サーバＩＤ＝１９２．１６８．０２の中継サーバ２００の端末接続数に大幅な増加がみられ、ＣＰＵ使用率の余力や、使用可能メモリ量に低下が見られている様子が示されている。
【００６９】
以上述べた方法により、接続管理サーバ１００は、定期更新部１２１による状態記憶部１１０の定期的な更新とは別に、端末装置３００と中継サーバ２００との間のＷｅｂＳｏｃｅｔ接続確立が失敗したことを契機として、不定期更新部１２２による状態記憶部１１０の不定期な更新が行われる。このような不定期更新が行われた後は、サーバＩＤが付加されていないＨＴＴＰリクエストを受信した場合と同様に、決定部１６０による中継サーバ２００の決定が行われ、この中継サーバ２００のサーバＩＤを含むＨＴＴＰレスポンスが端末装置３００に対して送出される。このとき、例えば状態記憶部１１０が記憶する状態情報が図７のように更新されていたとすると、決定部１６０は、端末装置３００がＷｅｂＳｏｃｋｅｔ接続を確立すべき中継サーバ２００として、サーバＩＤ＝１９２．１６８．０．１の中継サーバ２００を選択する。その結果、端末装置３００は、サーバＩＤ＝１９２．１６８．０．１を含むＨＴＴＰレスポンスを受信し、サーバＩＤ＝１９２．１６８．０．１の中継サーバ２００に対してＷｅｂＳｏｃｋｅｔ接続要求を行う。
【００７０】
図８は、不定期更新を含む接続管理サーバ１００の処理手順を示すフローチャートである。以下、このフローチャートに沿って、接続管理サーバ１００におる処理の要点を説明する。
【００７１】
まず、要求受付部１４０が、端末装置３００からのＨＴＴＰリクエストを受信し（ステップＳ３０１）、受信したＨＴＴＰリクエストにサーバＩＤが付加されているか否かを確認する（ステップＳ３０２）。そして、ＨＴＴＰリクエストにサーバＩＤが付加されている場合には（ステップＳ３０２：Ｙｅｓ）、取得要求部１３０が、このサーバＩＤで識別される中継サーバ２００に対して状態情報の取得要求を行う（ステップＳ３０３）。そして、不定期更新部１２２が、状態情報の取得要求の応答として中継サーバ２００から送られた状態情報を取得し、状態記憶部１１０を更新する（ステップＳ３０４）。一方、ステップＳ３０１で受信したＨＴＴＰリクエストにサーバＩＤが付加されていない場合は（ステップＳ３０２：Ｎｏ）、ステップＳ３０３およびステップＳ３０４の処理は行われない。
【００７２】
次に、決定部１６０が、状態記憶部１１０が記憶する状態情報および管理情報記憶部１５０が記憶する管理情報に基づいて、ＨＴＴＰリクエストを送出した端末装置３００の接続先の中継サーバ２００を決定する（ステップＳ３０５）。このとき、ステップＳ３０３およびステップＳ３０３で状態記憶部１１０の不定期更新が行われていれば、決定部１６０は、この不定期更新により更新された状態記憶部１１０の状態情報に基づいて、端末装置３００の接続先の中継サーバ２００を決定することになる。その後、要求受付部１４０は、決定部１６０によって決定された中継サーバ２００のサーバＩＤを含むＨＴＴＰレスポンスを作成し、このＨＴＴＰレスポンスをＨＴＴＰリクエストに対する応答として端末装置３００に対して送出し（ステップＳ３０６）、一連の処理を終了する。
【００７３】
次に、本実施形態の通信システムにおける具体的な動作例について、図９および図１０を参照して説明する。
【００７４】
図９は、端末装置３００と中継サーバ２００ＢとのＷｅｂＳｏｃｋｅｔ接続の確立が失敗した後、中継サーバ２００Ａとの間でＷｅｂＳｏｃｋｅｔ接続が確立されるまでの動作例を示すシーケンス図である。
【００７５】
まず、端末装置３００が、接続管理サーバ１００に対して接続先決定要求を行う（ステップＳ４０１）。接続管理サーバ１００は、端末装置３００からの接続先決定要求に応じて、中継サーバ２００Ｂを端末装置３００の接続先として決定し、中継サーバ２００ＢのサーバＩＤ＝１９２．１６８．０２を端末装置３００に通知する（ステップＳ４０２）。
【００７６】
端末装置３００は、接続管理サーバ１００から通知されたサーバＩＤ＝１９２．１６８．０２で識別される中継サーバ２００Ｂに対して、ＷｅｂＳｏｃｋｅｔ接続要求を行う（ステップＳ４０３）。中継サーバ２００Ｂは、端末装置３００からのＷｅｂＳｏｃｋｅｔ接続要求に応じてＷｅｂＳｏｃｋｅｔ接続の確立を試みるが、接続に失敗したため接続失敗のステータス情報を端末装置３００に通知する（ステップＳ４０４）。
【００７７】
中継サーバ２００Ｂから接続失敗のステータス情報を受け取った端末装置３００は、接続管理サーバ１００に対して、中継サーバ２００ＢのサーバＩＤ＝１９２．１６８．０２を付加した接続先決定要求を行う（ステップＳ４０５）。接続管理サーバ１００は、端末装置３００からの接続先決定要求に中継サーバ２００ＢのサーバＩＤ＝１９２．１６８．０２が含まれているため、中継サーバ２００Ｂに対して、状態情報の取得要求を行う（ステップＳ４０６）。
【００７８】
中継サーバ２００Ｂは、接続管理サーバ１００からの状態情報の取得要求に応じて、自身の状態情報を取得し、接続管理サーバ１００に通知する（ステップＳ４０７）。接続管理サーバ１００は、中継サーバ２００Ｂから受け取った状態情報により状態記憶部１１０を更新した上で、ステップＳ４０５の接続先決定要求に応じて、端末装置３００の接続先となる中継サーバ２００を決定する処理を行う。その結果、接続管理サーバ１００は、中継サーバ２００Ａを端末装置３００の接続先として決定し、中継サーバ２００ＡのサーバＩＤ＝１９２．１６８．０１を端末装置３００に通知する（ステップＳ４０８）。
【００７９】
端末装置３００は、接続管理サーバ１００から通知されたサーバＩＤ＝１９２．１６８．０１で識別される中継サーバ２００Ａに対して、ＷｅｂＳｏｃｋｅｔ接続要求を行う（ステップＳ４０９）。中継サーバ２００Ａは、端末装置３００からのＷｅｂＳｏｃｋｅｔ接続要求に応じて、端末装置３００との間のＷｅｂＳｏｃｋｅｔ接続を確立する（ステップＳ４１０）。
【００８０】
図１０は、端末装置３００Ａと中継サーバ２００ＢとがＷｅｂＳｏｃｋｅｔ接続を確立している状態で、端末装置３００Ｂと中継サーバ２００ＢとのＷｅｂＳｏｃｋｅｔ接続の確立が失敗した場合に、端末装置３００Ａと端末装置３００Ｂとの双方と中継サーバ２００Ａとの間でＷｅｂＳｏｃｋｅｔ接続が確立されるまでの動作例を示すシーケンス図である。
【００８１】
まず、端末装置３００Ｂが、接続管理サーバ１００に対して接続先決定要求を行う（ステップＳ５０１）。接続管理サーバ１００は、端末装置３００Ｂからの接続先決定要求に応じて、端末装置３００Ａとの間ですでにＷｅｂＳｏｃｋｅｔ接続を確立している中継サーバ２００Ｂを端末装置３００の接続先として決定する。そして、接続管理サーバ１００は、中継サーバ２００ＢのサーバＩＤ＝１９２．１６８．０２を端末装置３００Ｂに通知する（ステップＳ５０２）。
【００８２】
端末装置３００Ｂは、接続管理サーバ１００から通知されたサーバＩＤ＝１９２．１６８．０２で識別される中継サーバ２００Ｂに対して、ＷｅｂＳｏｃｋｅｔ接続要求を行う（ステップＳ５０３）。中継サーバ２００Ｂは、端末装置３００ＢからのＷｅｂＳｏｃｋｅｔ接続要求に応じてＷｅｂＳｏｃｋｅｔ接続の確立を試みるが、接続に失敗したため接続失敗のステータス情報を端末装置３００Ｂに通知する（ステップＳ５０４）。
【００８３】
中継サーバ２００Ｂから接続失敗のステータス情報を受け取った端末装置３００Ｂは、接続管理サーバ１００に対して、中継サーバ２００ＢのサーバＩＤ＝１９２．１６８．０２を付加した接続先決定要求を行う（ステップＳ５０５）。接続管理サーバ１００は、端末装置３００Ｂからの接続先決定要求に中継サーバ２００ＢのサーバＩＤ＝１９２．１６８．０２が含まれているため、中継サーバ２００Ｂに対して、状態情報の取得要求を行う（ステップＳ５０６）。
【００８４】
中継サーバ２００Ｂは、接続管理サーバ１００からの状態情報の取得要求に応じて、自身の状態情報を取得し、接続管理サーバ１００に通知する（ステップＳ５０７）。接続管理サーバ１００は、中継サーバ２００Ｂから受け取った状態情報により状態記憶部１１０を更新する。また、接続管理サーバ１００は、中継サーバ２００Ｂに対して、すでに確立している端末装置３００ＡとのＷｅｂＳｏｃｋｅｔ接続を切断する旨の切断要求を行う（ステップＳ５０８）。接続管理サーバ１００から切断要求を受けた中継サーバ２００Ｂは、この切断要求に応じて、端末装置３００Ａとの間のＷｅｂＳｏｃｋｅｔ接続を切断する（ステップＳ５０９）。なお、ステップＳ５０８およびステップＳ５０９の処理は、ステップＳ５０６およびステップＳ５０７の処理よりも前に行われてもよい。
【００８５】
中継サーバ２００Ｂとの間のＷｅｂＳｏｃｋｅｔ接続が切断された端末装置３００Ａは、この切断を検知して、接続管理サーバ１００に対して接続先決定要求を行う（ステップＳ５１０）。接続管理サーバ１００は、端末装置３００Ａからの接続先決定要求に応じて、中継サーバ２００Ａを端末装置３００Ａの新たな接続先として決定し、中継サーバ２００ＡのサーバＩＤ＝１９２．１６８．０１を端末装置３００Ａに通知する（ステップＳ５１１）。
【００８６】
端末装置３００Ａは、接続管理サーバ１００から通知されたサーバＩＤ＝１９２．１６８．０１で識別される中継サーバ２００Ａに対して、ＷｅｂＳｏｃｋｅｔ接続要求を行う（ステップＳ５１２）。中継サーバ２００Ａは、端末装置３００ＡからのＷｅｂＳｏｃｋｅｔ接続要求に応じて、端末装置３００Ａとの間のＷｅｂＳｏｃｋｅｔ接続を確立する（ステップＳ５１３）。
【００８７】
また、接続管理サーバ１００は、中継サーバ２００Ａを端末装置３００Ａの新たな接続先として決定した後、ステップＳ５０５の端末装置３００Ｂからの接続先決定要求に応じて、端末装置３００Ｂの接続先を、端末装置３００Ａと同一の接続先となる中継サーバ２００Ａに決定し、中継サーバ２００ＡのサーバＩＤ＝１９２．１６８．０１を端末装置３００Ｂに通知する（ステップＳ５１４）。
【００８８】
端末装置３００Ｂは、接続管理サーバ１００から通知されたサーバＩＤ＝１９２．１６８．０１で識別される中継サーバ２００Ａに対して、ＷｅｂＳｏｃｋｅｔ接続要求を行う（ステップＳ５１５）。中継サーバ２００Ａは、端末装置３００ＢからのＷｅｂＳｏｃｋｅｔ接続要求に応じて、端末装置３００Ｂとの間のＷｅｂＳｏｃｋｅｔ接続を確立する（ステップＳ５１６）。
【００８９】
以上、具体的な例を挙げながら詳細に説明したように、本実施形態では、複数の中継サーバ２００それぞれの状態情報を記憶する状態記憶部１１０を接続管理サーバ１００に設けている。そして、接続管理サーバ１００が所定の規則に従って状態記憶部１１０を更新しながら、状態記憶部１１０が記憶する状態情報に基づいて、端末装置３００がＷｅｂＳｏｃｋｅｔ接続を確立すべき中継サーバ２００を決定する。したがって、本実施形態によれば、いずれかの中継サーバ２００に障害や急激な負荷の増加などが生じた際に接続管理サーバ１００がすみやかにそのことを認識し、障害や急激な負荷の増加などが生じた中継サーバ２００を選ばないようにして、端末装置３００がＷｅｂＳｏｃｋｅｔ接続を確立すべき中継サーバ２００を適切に決定することができる。
【００９０】
特に本実施形態では、定期更新部１２１による状態記憶部１１０の定期的な更新と、不定期更新部１２２による状態記憶部１１０の不定期な更新、例えば中継サーバ２００とのＷｅｂＳｏｃｋｅｔ接続の確立が失敗した端末装置３００から再度の接続先決定要求を受けたタイミングでの状態記憶部１１０の更新とを併用する。したがって、通常時は状態情報の取得に関わる接続管理サーバ１００および中継サーバ２００双方の負荷を抑えることができるとともに、中継サーバ２００に障害や急激な負荷の増加などが生じた場合には、接続管理サーバ１００がすみやかにそのことを認識して、端末装置３００がＷｅｂＳｏｃｋｅｔ接続を確立すべき中継サーバ２００を適切に決定することができる。
【００９１】
なお、上述した実施形態では、接続管理サーバ１００の不定期更新部１２２が中継サーバ２００から状態情報を直接取得するようにしているが、これに限らない。例えば、中継サーバ２００の状態取得部２１０が取得要求受付部２２０からの依頼に応じて不定期に取得した状態情報を記憶装置４００に格納し、接続管理サーバ１００の不定期更新部１２２が、定期更新部１２１と同様に、記憶装置４００から中継サーバ２００の状態情報を取得するようにしてもよい。
【００９２】
また、上述した実施形態では、接続管理サーバ１００の定期更新部１２１が記憶装置４００を介して中継サーバ２００の状態情報を取得するようにしているが、これに限らない。例えば、接続管理サーバ１００の定期更新部１２１は、複数の中継サーバ２００それぞれから直接、定期的に状態情報を取得するようにしてもよい。この場合の構成例を図１１に示す。図１１に示す構成例は、図３に示した構成例から記憶装置４００を除いたものである。この図１１に示す構成の場合、各中継サーバ２００の状態取得部２１０は、予め定められた定期的なタイミングで状態情報を取得し、取得した状態情報に自身のサーバＩＤを付加して、接続管理サーバ１００に送出する。接続管理サーバ１００の定期更新部１２１は、各中継サーバ２００からの状態情報を受信して、状態記憶部１１０を更新する。なお、中継サーバ２００から接続管理サーバ１００に状態情報を送る方法は、上述したようなプッシュ型に限らず、接続管理サーバ１００の定期更新部１２１が中継サーバ２００に対して定期的に状態情報の取得要求を行い、その応答として中継サーバ２００から送られる状態情報を取得するプル型であってもよい。
【００９３】
また、上述した実施形態では、中継サーバ２００と端末装置３００との間でＷｅｂＳｏｃｋｅｔによる接続を行うものとしたが、これに限らない。中継サーバ２００と端末装置３００との間の通信接続は、コネクション型の通信プロトコルによる任意の方式を適用することができる。また、上述した実施形態では、接続管理サーバ１００と中継サーバ２００および端末装置３００との間の種々の要求やその応答をＨＴＴＰリクエストとレスポンスで行うものとしたが、これに限らない。
【００９４】
また、上述した実施形態では、中継サーバ２００のＣＰＵ使用率、使用可能メモリ量、および端末接続数の組み合わせを状態情報としたが、これに限らない。中継サーバ２００の状態情報は、中継サーバ２００の負荷状態と端末接続数との少なくとも一方を含んだ情報であればよい。例えば、中継サーバ２００のネットワーク状況やディスク読み書き状況といった情報を状態情報に含めてもよい。また、状態取得部２１０が実行した中継サーバ２００のステータスチェックの結果（サービス提供可能か否かを表す真偽値など）を状態情報に含めてもよい。また、接続管理サーバ１００の取得要求部１３０が中継サーバ２００に対して状態情報の取得要求を行ったときの応答成否の真偽値を状態情報に含めてもよい。また、接続管理サーバ１００から中継サーバ２００に対して行うｐｉｎｇの試行結果を状態情報に含めてもよい。また、中継サーバ２００の端末接続数の過去一定期間内の増加数や減少数、過去の接続失敗の回数、接続済の端末装置３００との間で行われたｐｉｎｇの試行結果の統計値などの情報を状態情報に含めてもよい。
【００９５】
また、上述した実施形態では、接続管理サーバ１００の不定期更新部１２２が、端末装置３００と中継サーバ２００との間のＷｅｂＳｏｃｋｅｔ接続の確立が失敗したことを契機として状態記憶部１１０を更新するようにしているが、これに限らない。例えば、端末装置３００と中継サーバ２００との間でＷｅｂＳｏｃｋｅｔ接続が確立されたがその処理に時間がかかった場合、ＷｅｂＳｏｃｋｅｔ接続の確立に失敗したものとみなして、接続管理サーバ１００の不定期更新部１２２による状態記憶部１１０の更新が行われるように構成してもよい。
【００９６】
また、上述した実施形態では、中継サーバ２００とのＷｅｂＳｏｃｋｅｔ接続の確立に失敗した端末装置３００が接続管理サーバ１００に対して接続先決定要求を再度行う場合に、ＷｅｂＳｏｃｋｅｔ接続の確立に失敗した中継サーバ２００のサーバＩＤを付加したＨＴＴＰリクエストを送出するようにしているが、これに限らない。例えば、接続先決定要求とは異なる通知を接続管理サーバ１００と端末装置３００との間で定義し、接続先決定要求を表すＨＴＴＰリクエストとは別に、この通知によって、端末装置３００がＷｅｂＳｏｃｋｅｔ接続の確立に失敗した中継サーバ２００のサーバＩＤを接続管理サーバ１００に伝えるようにしてもよい。また、この場合、接続先決定要求を表すＨＴＴＰリクエストと、中継サーバ２００のサーバＩＤの通知とを、異なるタイミングで端末装置３００から接続管理サーバ１００に送出するようにしてもよい。
【００９７】
また、上述した実施形態では、接続管理サーバ１００の不定期更新部１２２が、端末装置３００からの接続先決定要求に中継サーバ２００のサーバＩＤが含まれている場合に、このサーバＩＤで識別される中継サーバ２００から不定期に状態情報を取得するようにしているが、これに限らない。例えば、端末装置３００が接続管理サーバ１００に対して接続先決定要求を行う場合に、状態記憶部１１０の更新が必要か否かを示す真偽値の情報を付加し、接続管理サーバ１００の不定期更新部１２２は、この接続先決定要求に含まれる値が真である場合、つまり接続先決定要求に状態記憶部１１０の更新要求が含まれている場合に、複数の中継サーバ２００それぞれから状態情報を取得して状態記憶部１１０を更新するように構成してもよい。また、中継サーバ２００とのＷｅｂＳｏｃｋｅｔ接続の確立に失敗した端末装置３００が接続管理サーバ１００に対して再度行う接続先決定要求を、通常の接続先決定要求と異なる形式とし、接続管理サーバ１００の不定期更新部１２２は、端末装置３００から再度の接続先決定要求があった場合に、複数の中継サーバ２００それぞれから状態情報を取得して状態記憶部１１０を更新するように構成してもよい。
【００９８】
また、上述した実施形態では、接続管理サーバ１００の不定期更新部１２２が、端末装置３００からの再度の接続先決定要求を契機として状態記憶部１１０の不定期な更新を行うようにしているが、これに限らない。例えば、接続管理サーバ１００から中継サーバ２００に対して例えば１秒間隔でｐｉｎｇを実行し、到達性の確認結果が失敗となったことを契機に、不定期更新部１２２がこの中継サーバ２００から状態情報を取得して状態記憶部１１０を更新するように構成してもよい。また、予め接続管理サーバ１００と各中継サーバ２００との間でＴＣＰ（Transmission  Control  Protocol）などのコネクション型の通信を確立しておき、ある中継サーバ２００との間の通信の切断通知を受けたことを契機として、不定期更新部１２２がこの中継サーバ２００から状態情報を取得して状態記憶部１１０を更新するように構成してもよい。
【００９９】
なお、上述した接続管理サーバ１００の各処理機能（更新部１２０、取得要求部１３０、要求受付部１４０および決定部１６０）は、例えば、汎用のコンピュータシステムを基本ハードウェアとして用いて実行されるプログラム（ソフトウェア）により実現することができる。また、上述した接続管理サーバ１００の状態記憶部１１０および管理情報記憶部１５０は、コンピュータシステムが備えるメモリ資源を利用して実現することができる。
【０１００】
図１２は、接続管理サーバ１００のハードウェア構成の一例を示す図である。接続管理サーバ１００は、図１２に示すように、ＣＰＵ１０と、主記憶部２０と、補助記憶部３０と、通信インタフェース４０と、各部を接続するバス５０とを含んだ汎用のコンピュータシステムとして構成される。なお、補助記憶装置３０は、有線または無線によるＬＡＮ（Local  Area  Network）などで各部に接続されてもよい。
【０１０１】
上述した接続管理サーバ１００の各処理機能は、例えば、ＣＰＵ１０が、主記憶部２０を利用して、補助記憶部３０などに格納されたプログラムを実行することによって実現される。このプログラムは、上述した接続管理サーバ１００の各処理機能（更新部１２０、取得要求部１３０、要求受付部１４０および決定部１６０）を含むモジュール構成となっており、ＣＰＵ１０がこのプログラムを適宜読み出して実行することにより、上述した接続管理サーバ１００の各処理機能が主記憶部２０上にロードされ、主記憶部２０上に生成されるようになっている。
【０１０２】
また、上述した中継サーバ２００の各処理機能（状態取得部２１０、取得要求受付部２２０および接続確立部２３０）は、接続管理サーバ１００と同様に、図１２に示すようなコンピュータシステムを基本ハードウェアとして用いて実行されるプログラム（ソフトウェア）により実現することができる。このプログラムは、上述した中継サーバ２００の各処理機能を含むモジュール構成となっており、ＣＰＵ１０がこのプログラムを適宜読み出して実行することにより、上述した中継サーバ２００の各処理機能が主記憶部２０上にロードされ、主記憶部２０上に生成されるようになっている。
【０１０３】
また、上述した端末装置３００の各処理機能（決定要求部３１０および接続要求部３２０）は、接続管理サーバ１００や中継サーバ２００と同様に、図１２に示すようなコンピュータシステムを基本ハードウェアとして用いて実行されるプログラム（ソフトウェア）により実現することができる。このプログラムは、上述した端末装置３００の各処理機能を含むモジュール構成となっており、ＣＰＵ１０がこのプログラムを適宜読み出して実行することにより、上述した端末装置３００の各処理機能が主記憶部２０上にロードされ、主記憶部２０上に生成されるようになっている。
【０１０４】
上記の各プログラムは、例えば、磁気ディスク（フレキシブルディスク、ハードディスクなど）、光ディスク（ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＣＤ−ＲＷ、ＤＶＤ−ＲＯＭ、ＤＶＤ±Ｒ、ＤＶＤ±ＲＷ、Ｂｌｕ−ｒａｙ（登録商標）Ｄｉｓｃなど）、半導体メモリ、またはこれに類する記録媒体に記録されて提供される。プログラムを記録する記録媒体は、コンピュータシステムが読み取り可能な記録媒体であれば、その記憶形式は何れの形態であってもよい。
【０１０５】
また、上記の各プログラムを、コンピュータシステムに予めインストールすることで実現してもよいし、ネットワークを介して配布される上記のプログラムをコンピュータシステムに適宜インストールするように構成してもよい。また、上記の各プログラムを外部のサーバコンピュータ上で実行させ、ネットワークを介してその結果をクライアントコンピュータとして構成された接続管理サーバ１００、中継サーバ２００、端末装置３００がそれぞれ受け取る構成としてもよい。
【０１０６】
なお、上述した接続管理サーバ１００の各処理機能は、プログラム（ソフトウェア）により実現するだけでなく、その一部または全部を、ＡＳＩＣ（Application  Specific  Integrated  Circuit）やＦＰＧＡ（Field-Programmable  Gate  Array）などの専用のハードウェアにより実現することもできる。同様に、中継サーバ２００の処理機能の一部または全部を、ＡＳＩＣやＦＰＧＡなどの専用のハードウェアにより実現することもできる。同様に、端末装置３００の処理機能の一部または全部を、ＡＳＩＣやＦＰＧＡなどの専用のハードウェアにより実現することもできる。
【０１０７】
以上、本発明の実施形態を説明したが、ここで説明した実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。ここで説明した新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。ここで説明した実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。
【符号の説明】
【０１０８】
１００  接続管理装置
１１０  状態記憶部
１２０  更新部
１２１  第１更新部
１２２  第２更新部
１３０  取得要求部
１４０  要求受付部
１５０  管理情報記憶部
１６０  決定部
２００（２００Ａ，２００Ｂ）  中継サーバ
２１０  状態取得部
２２０  取得要求受付部
２３０  接続確立部
３００（３００Ａ，３００Ｂ）  端末装置
３１０  決定要求部
３２０  接続要求部
【図１】
2015170286.tif 000003
【図２】
2015170286.tif 000004
【図３】
2015170286.tif 000005
【図４】
2015170286.tif 000006
【図５】
2015170286.tif 000007
【図６】
2015170286.tif 000008
【図７】
2015170286.tif 000009
【図８】
2015170286.tif 000010
【図９】
2015170286.tif 000011
【図１０】
2015170286.tif 000012
【図１１】
2015170286.tif 000013
【図１２】
2015170286.tif 000014