(57)【要約】【課題】通信システム全体における通信品質向上及び通信リソースの節約を図ることが可能な中間サーバ装置、送信サーバ装置、通信システム及び通信方法を提供する。【解決手段】送信サーバ装置１２、受信サーバ装置１６、及び送信サーバ装置１２と受信サーバ装置１６との間の要求信号及び応答信号の中継を行う中間サーバ装置Ａ１３を含み、中間サーバ装置Ａ１３が、受信サーバ装置の障害状態を取得する障害監視制御部２３と、送信サーバ装置１２からの要求信号を受信処理すると共に、受信サーバ装置１６の障害状態に基づいて、送信サーバ装置１２に対して要求信号の再送指示の信号、または送信不可の信号を応答信号として送信するＨＴＴＰ信号送受信部２０と、を備え、送信サーバ装置１２が、中間サーバ装置Ａ１３から通知される受信サーバ装置１６の障害状態に応じて、中間サーバ装置Ａ１３に対して要求信号再送処理を行うＨＴＴＰ信号送受信部１７を備える。【選択図】図１
2010273297.tif 000002
【特許請求の範囲】
【請求項１】
送信サーバ装置と受信サーバ装置との間の要求信号及び応答信号の中継を行う中間サーバ装置であって、
前記受信サーバ装置の障害状態を取得する障害状態取得手段と、
前記送信サーバ装置からの要求信号を受信処理する要求信号受信手段と、
前記受信サーバ装置の障害状態に基づいて、前記送信サーバ装置に対して要求信号の再送指示の信号、または送信不可の信号を応答信号として送信する応答信号送信手段と、を備えることを特徴とする中間サーバ装置。
【請求項２】
前記応答信号送信手段は、前記受信サーバ装置の障害の重度または種類に応じて前記送信サーバ装置に対して要求信号の再送指示の信号、または送信不可の信号を応答信号として送信することを特徴とする請求項１記載の中間サーバ装置。
【請求項３】
請求項１に記載された中間サーバ装置から通知される受信サーバ装置の障害状態に応じて、前記中間サーバ装置に対して要求信号再送処理を行う要求信号再送手段を備えることを特徴とする送信サーバ装置。
【請求項４】
前記要求信号再送処理は、異なる複数の前記中間サーバ装置に対してなされることを特徴とする請求項３記載の送信サーバ装置。
【請求項５】
前記要求信号再送処理において、再送間隔、再送回数は可変に制御されることを特徴とする請求項３記載の送信サーバ装置。
【請求項６】
送信サーバ装置、受信サーバ装置、及び前記送信サーバ装置と前記受信サーバ装置との間の要求信号及び応答信号の中継を行う中間サーバ装置を含む通信システムであって、
前記中間サーバ装置は、
前記受信サーバ装置の障害状態を取得する障害状態取得手段と、
前記送信サーバ装置からの要求信号を受信処理する要求信号受信手段と、
前記受信サーバ装置の障害状態に基づいて、前記送信サーバ装置に対して要求信号の再送指示の信号、または送信不可の信号を応答信号として送信する応答信号送信手段と、を備え、
前記送信サーバ装置は、
前記中間サーバ装置から通知される前記受信サーバ装置の障害状態に応じて、前記中間サーバ装置に対して要求信号再送処理を行う要求信号再送手段を備えることを特徴とする通信システム。
【請求項７】
送信サーバ装置と受信サーバ装置との間の要求信号及び応答信号の中継を行う中間サーバ装置を用いる通信方法であって、
前記中間サーバ装置が、前記受信サーバ装置の障害状態を取得する障害状態取得ステップと、
前記中間サーバ装置が、前記送信サーバ装置からの要求信号を受信処理する要求信号受信ステップと、
前記中間サーバ装置が、前記受信サーバ装置の障害状態に基づいて、前記送信サーバ装置に対して要求信号の再送指示の信号、または送信不可の信号を応答信号として送信する応答信号送信ステップと、
前記送信サーバ装置が、前記中間サーバ装置から通知される受信サーバ装置の障害状態に応じて、前記中間サーバ装置に対して要求信号再送処理を行う要求信号再送ステップと、を備えることを特徴とする通信方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、中間サーバ装置、送信サーバ装置、通信システム、及び通信方法に関する。
【背景技術】
【０００２】
従来の通信システムや通信方法においては、サーバ装置間の通信異常の監視方法として定期Pingによる監視、コネクション監視、信号応答の有無による監視、ルーティングプロトコルの使用といったさまざまな方法が知られている。各々の監視方法により通信先サーバ装置の異常を検出した場合、自身による回線閉塞、迂回による措置をとる事により呼損を回避することが可能である。また、ルーティングプロトコルを用いることにより通信先サーバまでの経路に中間サーバ装置が存在することでサーバ構成が多段となっている通信システムにおいて、送信サーバ装置と直接接続されていない受信サーバ装置の状態をルーティング情報から収集し、送信サーバ装置にて迂回措置等の呼損回避を図ることが可能である。(例えば、非特許文献1〜４参照)
【先行技術文献】
【非特許文献】
【０００３】
【非特許文献１】C. Hedrick, Routing Information Protocol,IETF RFC1058、［online］、June 1988、ＩＥＴＦ、［平成２１年５月７日検索］、インターネット＜URL：http://www.ietf.org/rfc/rfc1058.txt?number=1058)
【非特許文献２】J. Moy, OSPF Version 2, IETF RFC1583、［online］、March 1994、ＩＥＴＦ、［平成２１年５月７日検索］、インターネット＜URL：http://www.ietf.org/rfc/rfc1583.txt?number=1583)
【非特許文献３】F. Baker, Editor, Requirements for IP Version 4 Routers, IETF RFC1812、［online］、June 1995、ＩＥＴＦ、［平成２１年５月７日検索］、インターネット＜URL：http://www.ietf.org/rfc/rfc1812.txt?number=1812)
【非特許文献４】G. Malkin  RIP Version 2, IETF RFC2453、［online］、November 1998、ＩＥＴＦ、［平成２１年５月７日検索］、インターネット＜URL：http://www.ietf.org/rfc/rfc2453.txt?number=2453)
【発明の概要】
【発明が解決しようとする課題】
【０００４】
しかしながら、上述した通信システムや通信方法において、定期Pingによる監視などは、直接接続されているサーバ間でのみ有効であって、中間サーバ装置を経由する通信システムのように直接接続されておらず多段構成となっているサーバ構成に対しては有効ではない場合があった。上述の方法では、受信サーバ装置の状態異常があるにもかかわらず、送信サーバ装置が受信サーバ装置に向けて信号を送出し続けることによる呼損が発生する懸念がある為、高い信頼性が必要な通信システムにおいては必ずしも十分ではなく、通信の信頼性低下につながることもあった。
【０００５】
また、上述のルーティングプロトコルを使用することにより、多段サーバ構成における受信サーバ装置の状態を知ることはある程度可能である。すなわちルーティングプロトコルによりＩＰレイヤの経路情報をやりとりし、受信サーバ装置の物理レイヤもしくはＩＰレイヤにおける故障状態を把握し、その状況に応じて送信サーバ装置を動作させることが考えられる。しかしながら、ルーティングプロトコルで救済できるレベルは、あくまで「ＩＰレイヤ」であり、アプリケーションレイヤの把握は不可能であった。すなわち、物理レイヤもしくはＩＰレイヤの異常が無く、上位信号プロトコルにおける異常が発生している場合には上記課題と同様、送信サーバ装置が受信サーバ装置に向けて信号を送出し、呼損が発生するという問題点があった。
【０００６】
また、多段サーバ構成における受信サーバ装置の一定時間の故障(Failover等)のように、復旧が見込め、送信サーバ装置が信号送信のリトライ等の措置を行うことにより呼救済が望める場合においても、上述のルーティングプロトコルを使用した方法においては、物理レイヤもしくはＩＰレイヤの状態の把握にとどまり、受信サーバ装置の故障状態（上位プロトコルの状態）を正確に把握することが困難である為、呼救済の機会を喪失するという問題点があった。
【０００７】
以上のように、従来の通信システムや通信方法においては、通信システム全体における通信品質を向上させることや通信リソースの節約を図ることが求められていた。
【０００８】
そこで本発明では上記問題点を解決し、通信システム全体における通信品質向上及び通信リソースの節約を図ることが可能な中間サーバ装置、送信サーバ装置、通信システム及び通信方法を提供することを目的とする。
【課題を解決するための手段】
【０００９】
本発明に係る中間サーバ装置は、送信サーバ装置と受信サーバ装置との間の要求信号及び応答信号の中継を行う中間サーバ装置であって、受信サーバ装置の障害状態を取得する障害状態取得手段と、送信サーバ装置からの要求信号を受信処理する要求信号受信手段と、受信サーバ装置の障害状態に基づいて、送信サーバ装置に対して要求信号の再送指示の信号、または送信不可の信号を応答信号として送信する応答信号送信手段と、を備えることを特徴とする。
【００１０】
本発明に係る中間サーバ装置によれば、受信サーバ装置が障害状態となったときに、障害状態取得手段によって受信サーバ装置の障害状態を取得し、要求信号受信手段によって送信サーバ装置からの要求信号を受信処理した場合、応答信号送信手段は、受信サーバ装置の障害状態に基づいて、送信サーバ装置に対して要求信号の再送指示の信号や送信不可の信号などを応答信号として送信することができる。これによって、送信サーバ装置が受信サーバ装置の状態を把握することができるため、受信サーバ装置の状態に合わせて要求信号の再送を行うことによって呼救済を行うことができるようになり、あるいは、要求信号の再送を行っても救済することができない場合は再送を実施しないことによって、送信サーバ装置のリソースを節約することができるようになる。このように、通信システムにおいて送信サーバ装置と直接接続されていない受信サーバ装置の状態を監視し、アプリケーションレベルまで把握することができ、受信サーバ装置の状態に応じた動作をすることで呼損を自律的に回避することができる。以上により、本発明に係る中間サーバ装置によれば、受信サーバ装置の状態に応じて送信サーバ装置が最適な要求信号の送信方法をとることが可能となるため、通信システム全体における通信品質向上及び通信リソースの節約を図ることが可能となる。
【００１１】
また、本発明に係る中間サーバ装置において、応答信号送信手段は、受信サーバ装置の障害の重度または種類に応じて送信サーバ装置に対して要求信号の再送指示の信号、または送信不可の信号を応答信号として送信することが好ましい。これによって、受信サーバ装置の状態に応じて送信サーバ装置へ指示を行うことが可能となり、例えば、受信サーバ装置が一定時間の故障(Failover等)に陥った場合、中間サーバ装置が再送要求を促す信号を送信サーバ装置へ送信することにより、呼救済を図る事ができるため、通信の信頼性を向上させることができる。
【００１２】
本発明に係る送信サーバ装置は、請求項１に記載された中間サーバ装置から通知される受信サーバ装置の障害状態に応じて、中間サーバ装置に対して要求信号再送処理を行う要求信号再送手段を備えることを特徴とする。
【００１３】
本発明に係る送信サーバ装置によれば、要求信号再送手段が、受信サーバ装置の状態に合わせて要求信号の再送を行うことによって呼救済を行うことができるようになり、あるいは、要求信号の再送を行っても救済することができない場合は再送を実施しないことによって、送信サーバ装置のリソースを節約することができるようになる。このように、通信システムにおいて送信サーバ装置と直接接続されていない受信サーバ装置の状態を監視し、アプリケーションレベルまで把握することができ、受信サーバ装置の状態に応じた動作をすることで呼損を自律的に回避することができる。以上により、本発明に係る送信サーバ装置によれば、受信サーバ装置の状態に応じて最適な要求信号の送信方法をとることが可能となるため、通信システム全体における通信品質向上及び通信リソースの節約を図ることが可能となる。
【００１４】
また、本発明に係る送信サーバ装置において、要求信号再送処理は、異なる複数の中間サーバ装置に対してなされることが好ましい。これにより、中間サーバ装置と受信サーバ装置間の通信異常において、異常の要因が中間サーバ装置にあった場合は、送信サーバ装置が複数台設置の中間サーバ装置に対しリトライ信号を送信することにより、同一もしくは単一の中間サーバ装置に対する再送要求をする通信方法と比較し、通信の信頼性をより高めることが可能となる。
【００１５】
また、本発明に係る送信サーバ装置では、要求信号再送処理において、再送間隔、再送回数は可変に制御されることが好ましい。これにより、受信サーバ装置の故障の重度に応じ、再送回数を増減させたり、再送間隔を可変とすることで、通信品質を保ち、通信リソースを確保する最適な条件へと柔軟に変更することが可能となる。
【００１６】
本発明に係る通信システムは、送信サーバ装置、受信サーバ装置、及び送信サーバ装置と受信サーバ装置との間の要求信号及び応答信号の中継を行う中間サーバ装置を含む通信システムであって、中間サーバ装置は、受信サーバ装置の障害状態を取得する障害状態取得手段と、送信サーバ装置からの要求信号を受信処理する要求信号受信手段と、受信サーバ装置の障害状態に基づいて、送信サーバ装置に対して要求信号の再送指示の信号、または送信不可の信号を応答信号として送信する応答信号送信手段と、を備え、送信サーバ装置は、中間サーバ装置から通知される受信サーバ装置の障害状態に応じて、中間サーバ装置に対して要求信号再送処理を行う要求信号再送手段を備えることを特徴とする。
【００１７】
本発明に係る通信システムによれば、受信サーバ装置が障害状態となったときに、障害状態取得手段によって受信サーバ装置の障害状態を取得し、要求信号受信手段によって送信サーバ装置からの要求信号を受信処理した場合、応答信号送信手段は、受信サーバ装置の障害状態に基づいて、送信サーバ装置に対して要求信号の再送指示の信号や送信不可の信号などを応答信号として送信することができる。これによって、送信サーバ装置が受信サーバ装置の状態を把握し、送信サーバ装置の要求信号再送手段は、受信サーバ装置の状態に合わせて要求信号の再送を行うことによって呼救済を行うことができるようになり、あるいは、要求信号の再送を行っても救済することができない場合は再送を実施しないことによって、送信サーバ装置のリソースを節約することができるようになる。このように、通信システムにおいて送信サーバ装置と直接接続されていない受信サーバ装置の状態を監視し、アプリケーションレベルまで把握することができ、受信サーバ装置の状態に応じた動作をすることで呼損を自律的に回避することができる。以上により、本発明に係る通信システムによれば、受信サーバ装置の状態に応じて送信サーバ装置が最適な要求信号の送信方法をとることが可能となるため、通信システム全体における通信品質向上及び通信リソースの節約を図ることが可能となる。
【００１８】
本発明に係る通信方法は、送信サーバ装置と受信サーバ装置との間の要求信号及び応答信号の中継を行う中間サーバ装置を用いる通信方法であって、中間サーバ装置が、受信サーバ装置の障害状態を取得する障害状態取得ステップと、中間サーバ装置が、送信サーバ装置からの要求信号を受信処理する要求信号受信ステップと、中間サーバ装置が、受信サーバ装置の障害状態に基づいて、送信サーバ装置に対して要求信号の再送指示の信号、または送信不可の信号を応答信号として送信する応答信号送信ステップと、送信サーバ装置が、中間サーバ装置から通知される受信サーバ装置の障害状態に応じて、中間サーバ装置に対して要求信号再送処理を行う要求信号再送ステップと、を備えることを特徴とする。
【００１９】
本発明に係る通信方法によれば、受信サーバ装置が障害状態となったときに、障害状態取得ステップで中間サーバ装置が受信サーバ装置の障害状態を取得し、要求信号受信ステップで中間サーバ装置が送信サーバ装置からの要求信号を受信処理した場合、応答信号送信ステップで中間サーバ装置が受信サーバ装置の障害状態に基づいて、送信サーバ装置に対して要求信号の再送指示の信号や送信不可の信号などを応答信号として送信することができる。これによって、送信サーバ装置が受信サーバ装置の状態を把握し、要求信号再送ステップで送信サーバ装置は、受信サーバ装置の状態に合わせて要求信号の再送を行うことによって呼救済を行うことができるようになり、あるいは、要求信号の再送を行っても救済することができない場合は再送を実施しないことによって、送信サーバ装置のリソースを節約することができるようになる。このように、通信システムにおいて送信サーバ装置に直接接続されていない受信サーバ装置の状態を監視し、アプリケーションレベルまで把握することができ、受信サーバ装置の状態に応じた動作をすることで呼損を自律的に回避することができる。以上により、本発明に係る通信方法によれば、受信サーバ装置の状態に応じて送信サーバ装置が最適な要求信号の送信方法をとることが可能となるため、通信システム全体における通信品質向上及び通信リソースの節約を図ることが可能となる。
【発明の効果】
【００２０】
本発明に係る中間サーバ装置、送信サーバ装置、通信システム及び通信方法によれば、通信システム全体における通信品質向上及び通信リソースの節約を図ることが可能となる。
【図面の簡単な説明】
【００２１】
【図１】本発明の実施形態に係る通信システムのブロック構成を示す図である。
【図２】本発明の実施形態に係る通信システムによる制御処理の流れを説明するためのシーケンス図である。
【図３】本発明の実施形態に係る通信システムの他の制御処理の流れを説明するためのシーケンス図である。
【発明を実施するための形態】
【００２２】
以下、本発明に係る中間サーバ装置、送信サーバ装置、通信システム、及び通信方法の好適な実施形態を図面に基づいて説明する。なお、各図において、同一要素には同一符号を付して重複する説明を省略する。
【００２３】
図１は、本発明の実施形態に係る通信システム１０の構成を示す図である。この通信システム１０は、中間サーバ装置Ａ１３，Ｂ１３〜ｎ１３で中継することによって送信サーバ装置１２と受信サーバ装置１６との間の要求信号及び応答信号のやり取りを行う機能を有している。図１に示すように、通信システム１０は、送信サーバ装置１２、複数の中間サーバ装置Ａ１３，Ｂ１３〜ｎ１３、及び受信サーバ装置１６を備えて構成されており、各サーバ装置は相互にネットワークで接続されている。各サーバ装置は、情報の要求信号、応答信号の送受信を行う機能を有している。各サーバ装置は、物理的にはCPU、主記憶装置RAM及びROM、ハードディスク等の補助記憶装置、入力デバイスであるキーボード及びマウス等の入力装置、ディスプレイ等の出力装置、ネットワークカード等のデータ送受信デバイスである通信モジュールなどを含むコンピュータシステムとして構成されている。
【００２４】
送信サーバ装置１２は、ＨＴＴＰ信号送受信部（要求信号再送手段）１７、ＨＴＴＰ制御部１８、リトライ制御部１９を備えて構成されている。ＨＴＴＰ信号送受信部１７は、送信サーバ装置１２上における情報の要求信号の送信、応答信号の受信をＨＴＴＰ信号において行う機能を有している。また、ＨＴＴＰ信号送受信部１７は、リトライ制御部１９からのリトライ信号に基づき、中間サーバ装置Ａ１３，Ｂ１３〜ｎ１３から通知される受信サーバ装置１６の障害状態に応じて、中間サーバ装置Ａ１３，Ｂ１３〜ｎ１３に対して要求信号再送処理を行う機能を有している。
【００２５】
ＨＴＴＰ制御部１８は、ＨＴＴＰ信号送受信部１７で受信したＨＴＴＰ信号のステータスコードの解読を行う機能を有している。
【００２６】
リトライ制御部１９は、要求信号のリトライ回数、リトライ間隔を制御すると共に、当該リトライ回数及びリトライ間隔を登録する機能を有している。リトライ制御部１９は、ＨＴＴＰ制御部１８にてステータスコードの解読を行った結果、リトライを必要とするステータスコードであった場合に、登録された最大リトライ回数、リトライ間隔に従い、ＨＴＴＰ信号送受信部１７を介してリトライ信号を送信する機能を有している。また、リトライ制御部１９に設定する最大リトライ回数、リトライ間隔は受信サーバ装置１６の一時的障害が復旧する時間を見積もった上で設定できるように可変値とする。
【００２７】
中間サーバ装置A１３は、ＨＴＴＰ信号送受信部（要求信号受信手段、応答信号送信手段）２０、信号送受信部２１、ＨＴＴＰ制御部２２、障害監視制御部（障害状態取得手段）２３、障害管理DB２４を備えて構成されている。なお、中間サーバ装置B１３〜n１３も同様の構成とされており、複数台の設置が可能(1台でも可)である。
【００２８】
ＨＴＴＰ信号送受信部２０は、中間サーバ装置A１３において送信サーバ装置１２からのＨＴＴＰの要求信号を受信処理すると共に受信サーバ装置１６へ中継し、または受信サーバ装置１６からの応答信号を受信すると共に送信サーバ装置１２へ中継する機能を有している。また、ＨＴＴＰ信号送受信部２０は、障害監視制御部２３で取得した受信サーバ装置１６の障害状態に従って送信サーバ装置１２へＨＴＴＰ信号の応答を返送する機能を有している。更に、ＨＴＴＰ信号送受信部２０は、受信サーバ装置１６の障害の重度または種類に応じて送信サーバ装置１２に対して要求信号の再送指示の信号、または送信不可の信号を応答信号として送信する機能を有している。なお、異常の種類とは、ハード故障、メモリ故障、プロセス障害、機能追加によるファイル入れ替えなどの保守等である。
【００２９】
信号送受信部２１は受信サーバ装置１６へ要求信号応答信号を中継する機能を有しており、受信サーバ装置１６と送信サーバ装置１２とで使用プロトコルが異なる場合はプロトコル変換を行う機能も有している。
【００３０】
ＨＴＴＰ制御部２２は、中間サーバ装置Ａ１３において送信サーバ装置１２へのＨＴＴＰ応答信号に付加するステータスコードを設定する機能を有している。また、障害監視制御部２３は、受信サーバ装置１６との間の回線正常性の監視を行うと共に、障害状態を取得する機能を有している。障害監視制御部２３は、回線異常を検出した場合、受信サーバ装置１６の状態を障害と判断し、障害管理DB２４へ受信サーバ装置状態を障害状態と登録する機能を有している。なお、回線異常の検出とは、例えば、受信サーバ装置１６への定期Ｐｉｎｇによるヘルスチェック、受信サーバ装置と接続する物理ポート監視（ＮＷ機器などの基本機能）、受信サーバ装置１６とのアプリケーションレベル（ＨＴＴＰ電文など）によるヘルスチェックなどが挙げられる。障害管理DB２４は、受信サーバ装置状態を保持しておくデータベースである。
【００３１】
受信サーバ装置１６は、信号送受信部２５を備えて構成されている。この信号送受信部２５は、受信サーバ装置１６における要求信号受信、応答信号送信処理を行う機能を有しており、中間サーバ装置Ａ１３、Ｂ１３〜n１３との間で同一プロトコル(ＨＴＴＰ以外でも可)にて動作する。
【００３２】
なお、ＨＴＴＰ信号送受信部１７、ＨＴＴＰ制御部１８、リトライ制御部１９、ＨＴＴＰ信号送受信部２０、信号送受信部２１、ＨＴＴＰ制御部２２、障害監視制御部２３、障害管理DB２４、信号送受信部２５は、CPU、RAM等のハードウェア上に所定のコンピュータソフトウェアを読み込ませる事により、CPUの制御の元で通信モジュール、入力装置、出力装置を動作させるとともに、RAMや補助記憶装置におけるデータの読み出し書き込みを行う事で実現される。
【００３３】
次に、図２を参照して、本発明の実施形態に係る通信システム１０による通信方法について説明する。図２は、本発明の実施形態に係る通信システム１０の制御処理の流れを説明するためのシーケンス図である。図２では、受信サーバ装置１６の障害時における信号送受信動作の一例を示している。図２においては、複数の中間サーバ装置Ａ１３，Ｂ１３〜ｎ１３によって送信サーバ装置１２と受信サーバ装置１６とを中継する場合について説明する。なお、中間サーバ装置は1台のみでも可能であるが、後述する障害要因が中間サーバ装置側にあった場合に対する効果を望むべく、複数台とすることが好適である。
【００３４】
図２に示すように、受信サーバ装置１６が障害（Failover等）となった場合、中間サーバ装置Ａ１３、Ｂ１３〜ｎ１３の障害監視制御部２３は、受信サーバ装置１６との間の回線異常（ＴＣＰレイヤでのコネクション管理）をそれぞれ検出する（ステップＳ１０１）。次に、障害監視制御部２３は、受信サーバ装置１６の状態を障害と判断し、受信サーバ装置１６の状態を「障害」と設定して障害管理ＤＢ２４に登録する（ステップＳ１０２：障害状態取得ステップ）。
【００３５】
送信サーバ装置１２のＨＴＴＰ信号送受信部１７は、通信の開始として、受信サーバ装置１６へ中継させるために中間サーバ装置A１３へＨＴＴＰ Ｒｅｑｕｅｓｔ（情報要求）を送信し、中間サーバ装置Ａ１３のＨＴＴＰ信号送受信部２０がＨＴＴＰＲｅｑｕｅｓｔ（情報要求）を受信する（ステップＳ１０３：要求信号受信ステップ）。その際、ＨＴＴＰ制御部２２は、障害監視制御部２３へ受信サーバ装置１６の状態が「障害」となっているかどうかの問い合わせを行う（ステップＳ１０４）。そして、受信サーバ装置１６の状態が「障害」となっていた場合、ＨＴＴＰ制御部２２は、ＨＴＴＰのステータスコードに「５００」を設定する（ステップＳ１０５）。その後、ＨＴＴＰ信号送受信部２０は、送信サーバ装置１２へＨＴＴＰＲｅｓｐｏｎｓｅ（情報要求応答）として、「Ｓｔａｔｕｓ  Ｃｏｄｅ：５００」を返送する（ステップＳ１０６：応答信号送信ステップ）。
【００３６】
送信サーバ装置１２のＨＴＴＰ信号送受信部１７は、ＨＴＴＰＲｅｓｐｏｎｓｅを受信し、ＨＴＴＰ制御部１８は、ステータスコードを解読する（ステップＳ１０７）。ステータスコードが５００の場合、ＨＴＴＰ制御部１８は、受信サーバ装置１６が障害状態であると判断し、ＨＴＴＰ信号送受信部１７は、ＨＴＴＰリトライ制御部１９に設定されるリトライ間隔に従い、ＨＴＴＰＲｅｑｕｅｓｔ送信のリトライを行う（ステップＳ１０８：要求信号再送ステップ）。なお、この処理はＨＴＴＰＲｅｓｐｏｎｓｅ受信時から２０秒経過時になされる。この際、送信先の中間サーバ装置はＨＴＴＰＲｅｓｐｏｎｓｅを受信した中間サーバ装置Ａ１３以外の中間サーバ装置B１３とする。
【００３７】
リトライ回数及びリトライ間隔は送信サーバ装置１２のリトライ制御部１９にて管理する。リトライ制御部１９は、送信サーバ装置１２のＨＴＴＰＲｅｑｕｅｓｔ送信のリトライについて、受信サーバ装置１６の状態が復旧する時間を見積もった上でリトライ間隔(情報要求応答タイマ)及びリトライ回数を設定しておく。本実施形態では、リトライ間隔２０秒、リトライ回数１０回と設定しておき、２０秒×１０回＝２００秒間の一時的障害に対しては呼損なしに通信が可能となる。
【００３８】
中間サーバ装置Ｂ１３のＨＴＴＰ信号送受信部２０は、Ｓ１０８の送信サーバ装置１２からのＨＴＴＰＲｅｑｕｅｓｔ送信のリトライを受信し、ＨＴＴＰ制御部２２は、Ｓ１０４及びＳ１０５の処理によって構成されている処理αを行う（ステップＳ１０９）。その後、ＨＴＴＰ信号送受信部２０は、送信サーバ装置１２へＨＴＴＰＲｅｓｐｏｎｓｅ（情報要求応答）として、「Ｓｔａｔｕｓ  Ｃｏｄｅ：５００」を返送する（ステップＳ１１０：応答信号送信ステップ）。
【００３９】
一方、送信サーバ装置１２においては、受信サーバ装置１６が復旧せず、中間サーバ装置Ａ１３、Ｂ１３〜ｎ１３の障害管理DB２４にて保持する受信サーバ装置状態が「障害」のままである限り、ＨＴＴＰ信号送受信部１７はリトライ送信を繰り返す事となるが、リトライ送信をする度に送信サーバ装置１２のリトライ制御部１９は、リトライ回数を管理する。具体的には、リトライ制御部１９は、リトライ送信を行う度に管理するリトライ回数を＋１にする（ステップＳ１１１）。なお、中間サーバ装置Ｂ１３に対してリトライ送信を行い、Ｓ１０９〜Ｓ１１１の処理が行われると、次は中間サーバ装置Ａ１３，Ｂ１３以外の中間サーバ装置に対してリトライ送信を行い、以降、一度リトライ送信を行った以外の中間サーバ装置に対して順次リトライ送信を行う。なお、リトライが行われるたびに、リトライ送信が行われた中間サーバ装置でＳ１０９、Ｓ１１０の処理が行われると共に送信サーバ装置１２でＳ１１１の処理が行われる。また、送信サーバ装置１２は、リトライ回数が規定値（最大リトライ回数）となった時点でリトライ送信の実施を終了する。
【００４０】
一方、受信サーバ装置１６が一時的障害（本実施形態では、Failover完了時間を１８０秒とする)より復旧すると、中間サーバ装置Ａ１３、Ｂ１３〜ｎ１３の障害監視制御部２３は、回線状態復旧を検出（ＴＣＰレイヤにてコネクション復旧）する（ステップＳ１１２）。次に、障害監視制御部２３は、受信サーバ装置１６の状態を正常と判断し、受信サーバ装置１６の状態を「正常」と設定して障害管理ＤＢ２４に登録する（ステップＳ１１３）。
【００４１】
その後、送信サーバ装置１２のＨＴＴＰ信号送受信部１７は、ＨＴＴＰ Ｒｅｑｕｅｓｔのリトライ信号を中間サーバ装置ｎ１３に対して送信する（ステップＳ１１４：要求信号再送ステップ）。Ｓ１１４のリトライ信号を受信すると、中間サーバ装置ｎ１３のＨＴＴＰ制御部２２は、障害監視制御部２３へ受信サーバ装置１６の状態の問い合わせを行う（ステップＳ１１５）。Ｓ１１５において受信サーバ装置１６の状態が「正常」であると判断されると、中間サーバ装置ｎ１３の信号送受信部２１は、受信サーバ装置１６へ情報要求を送信する（ステップＳ１１６）。受信サーバ装置１６の信号送受信部２５は、Ｓ１１６の情報要求を受信すると、内容に応じて中間サーバ装置ｎ１３を経由し送信サーバ装置１２へ情報要求応答を返送する（ステップＳ１１７、ステップＳ１１８）。Ｓ１１８の処理が終了すると、図２に示す制御処理が終了する。
【００４２】
図２に示す制御処理においては、受信サーバ装置１６が一時的障害時(Failover等)である場合、中間サーバ装置Ａ１３（中間サーバ装置が複数台の場合は中間サーバ装置Ａ１３〜ｎ１３のいずれか1台）がリトライを促す信号を送信サーバ装置１２へ返送することにより、送信サーバ装置１２は受信サーバ装置１６の一時的障害要因より復旧する時間を見積もった最大リトライ回数、リトライ間隔の設定値に従い、受信サーバ装置１６へリトライ送信を実施することにより呼救済を図る事ができる。また、障害要因が中間サーバ装置Ａ１３にあるケースを考え、中間サーバ装置Ａ１３、Ｂ１３〜n１３と受信サーバ装置１６との間の回線状態を監視する事により、異なる中間サーバ装置へリトライを実施する。これによって、同一もしくは単一中間サーバ装置に対するリトライをする方法と比較し、より確実に呼救済を可能とする。
【００４３】
次に、図３を参照して本発明の実施形態に係る通信システム１０の他の制御処理について説明する。図３は、本発明の実施形態に係る通信システムの他の制御処理の流れを説明するためのシーケンス図である。図３は、受信サーバ装置１６の状態が障害とは別要因にて正常な返答を送信できず、リトライを実施しても正常応答が望めない場合で、送信サーバ装置１２にリトライの必要無しの旨を中間サーバ装置Ａ１３より通知するようにした場合の制御処理を示している。図３においては、中間サーバ装置として、中間サーバ装置Ａ１３を設置する例について説明する（ただし、複数台設置してもよい）。
【００４４】
図３に示すように、通信の開始として、送信サーバ装置１２のＨＴＴＰ信号送受信部１７は、受信サーバ装置１６へ中継させるために、中間サーバ装置Ａ１３へＨＴＴＰＲｅｑｕｅｓｔ（情報要求）を送信する（ステップＳ２０２：要求信号受信ステップ）。次に、中間サーバ装置Ａ１３の信号送受信部２１は、受信サーバ装置１６に対して情報要求を送信する（ステップＳ２０３）。
【００４５】
その際、受信サーバ装置１６がリトライを実施しても正常応答を見込めない障害（システム輻輳等）となっていた場合（ステップＳ２０１）、受信サーバ装置１６の信号送受信部２５は、システム輻輳である旨の信号（情報要求応答「輻輳」）を中間サーバ装置Ａ１３に対して返送し、中間サーバ装置Ａ１３の信号送受信部２１は、Ｓ２０３での情報要求応答を受信し、障害監視制御部２３は受信サーバ装置１６の状態を取得する（ステップＳ２０４：障害状態取得ステップ）。なお、システム輻輳とは、ＣＰＵ使用率やトラフィック輻輳が（まったく送受信できないレベルに達する前の）閾値以上となった場合などを想定している。
【００４６】
Ｓ２０４で取得した信号はシステム輻輳である旨の応答であるため、ＨＴＴＰ制御部２２は、ＨＴＴＰのステータスコードに「５０３」を設定して（ステップＳ２０５）、ＨＴＴＰ信号送受信部２０は、送信サーバ装置１２へＨＴＴＰＲｅｓｐｏｎｓｅ（Ｓｔａｔｕｓ  Ｃｏｄｅ：５０３）を返送する（ステップＳ２０６：応答信号送信ステップ）。
【００４７】
送信サーバ装置１２のＨＴＴＰ信号送受信部１７は、ＨＴＴＰＲｅｓｐｏｎｓｅを受信し、ＨＴＴＰ制御部１８は、ステータスコードを解読して受信サーバ装置１６の状態を把握する（ステップＳ２０７）。ステータスコードが５０３の場合、受信サーバ装置１６がシステム輻輳状態であり、リトライ送信を実施しても呼救済できないと判断し、リトライを実施しない（ステップＳ２０８）。Ｓ２０８の処理が終了すると、図３に示す制御処理は終了する。なお、図３に示す処理においては、必ずしも送信サーバ装置１２のリトライ制御部１９及び中間サーバ装置Ａ１３の障害監視制御部２３及び障害管理DB２４は必要ではない。
【００４８】
図３に示す処理では、中間サーバ装置Ａ１３が送信サーバ装置１２へ返送する信号に受信サーバ装置１６の状態を表すＨＴＴＰステータスコードを複数使用することにより、リトライを要求するか、要求しないかを送信サーバ装置１２へ判断させ、リトライ送信しても救えない場合（システム輻輳等）においては、送信サーバ装置１２にてリトライ送信を実施せずに、送信サーバ装置１２のリソースを節約することが可能である。
【００４９】
以上によって、本実施形態に係る通信システム１０、送信サーバ装置１２及び中間サーバ装置Ａ１３，Ｂ１３〜ｎ１３によれば、受信サーバ装置１６が障害状態となったときに、障害監視制御部２３によって受信サーバ装置１６の障害状態を取得し、ＨＴＴＰ信号送受信部２０によって送信サーバ装置１２からの要求信号を受信処理した場合、ＨＴＴＰ信号送受信部２０は、受信サーバ装置１６の障害状態に基づいて、送信サーバ装置１２に対して要求信号の再送指示の信号や送信不可の信号などを応答信号として送信することができる。これによって、送信サーバ装置１２が受信サーバ装置１６の状態を把握することができるため、ＨＴＴＰ信号送受信部１７は、受信サーバ装置１６の状態に合わせて要求信号の再送を行うことによって呼救済を行うことができるようになり、あるいは、要求信号の再送を行っても救済することができない場合は再送を実施しないことによって、送信サーバ装置１２のリソースを節約することができるようになる。このように、通信システム１０において直接接続していない受信サーバ装置１６の状態を監視し、アプリケーションレベルまで把握することができ、受信サーバ装置１６の状態に応じた動作をすることで呼損を自律的に回避することができる。以上により、受信サーバ装置１６の状態に応じて送信サーバ装置１２が最適な要求信号の送信方法をとることが可能となるため、通信システム全体における通信品質向上及び通信リソースの節約を図ることが可能となる。
【００５０】
また、本実施形態に係る中間サーバ装置Ａ１３，Ｂ１３〜ｎ１３において、ＨＴＴＰ信号送受信部２０は、受信サーバ装置１６の障害の重度または種類に応じて送信サーバ装置１２に対して要求信号の再送指示の信号、または送信不可の信号を応答信号として送信することができる。これによって、受信サーバ装置１６の状態に応じて送信サーバ装置１２へ指示を行うことが可能となり、例えば、受信サーバ装置１６が一定時間の故障(Failover等)に陥った場合、中間サーバ装置Ａ１３，Ｂ１３〜ｎ１３が再送要求を促す信号を送信サーバ装置１２へ送信することにより、呼救済を図る事ができるため、通信の信頼性を向上させることができる。
【００５１】
また、本実施形態に係る送信サーバ装置１２において、要求信号再送処理は、異なる複数の中間サーバ装置Ａ１３，Ｂ１３〜ｎ１３に対してなされている。これにより、中間サーバ装置と受信サーバ装置１６間の通信異常において、要因が中間サーバ装置にあった場合は、送信サーバ装置１２が複数台設置の中間サーバ装置Ａ１３，Ｂ１３〜ｎ１３に対しリトライ信号を送信することにより、同一もしくは単一の中間サーバ装置に対する再送要求をする通信方法と比較し、通信の信頼性をより高めることが可能となる。
【００５２】
また、本実施形態に係る送信サーバ装置１２では、要求信号再送処理において、再送間隔、再送回数は可変に制御される。これにより、受信サーバ装置１６の故障の重度に応じ、再送回数を増減させたり、再送間隔を可変とすることで、通信品質を保ち、通信リソースを確保する最適な条件へと柔軟に変更することが可能となる。
【００５３】
また、本実施形態に係る通信方法によれば、受信サーバ装置１６が障害状態となったときに、障害状態取得ステップＳ１０２で中間サーバ装置Ａ１３，Ｂ１３〜ｎ１３が受信サーバ装置１６の障害状態を取得し、要求信号受信ステップＳ１０３，Ｓ２０２で中間サーバ装置Ａ１３，Ｂ１３〜ｎ１３が送信サーバ装置１２からの要求信号を受信処理した場合、応答信号送信ステップＳ１０６，Ｓ１１０，Ｓ２０６で中間サーバ装置Ａ１３，Ｂ１３〜ｎ１３が受信サーバ装置１６の障害状態に基づいて、送信サーバ装置１２に対して要求信号の再送指示の信号や送信不可の信号などを応答信号として送信することができる。これによって、送信サーバ装置１２が受信サーバ装置１６の状態を把握し、要求信号再送ステップＳ１０８，Ｓ１１４で送信サーバ装置１２は、受信サーバ装置１６の状態に合わせて要求信号の再送を行うことによって呼救済を行うことができるようになり、あるいは、要求信号の再送を行っても救済することができない場合は再送を実施しないことによって、送信サーバ装置１２のリソースを節約することができるようになる。このように、通信システム１０において直接接続していない受信サーバ装置の状態を監視し、アプリケーションレベルまで把握することができ、受信サーバ装置１６の状態に応じた動作をすることで呼損を自律的に回避することができる。以上により、受信サーバ装置１６の状態に応じて送信サーバ装置１２が最適な要求信号の送信方法をとることが可能となるため、通信システム全体における通信品質向上及び通信リソースの節約を図ることが可能となる。
【００５４】
本発明は、上述した実施形態に限定されるものではない。例えば、上述の送信サーバ装置１２と受信サーバ装置１６とは入れ替えが可能である。すなわち、受信サーバ装置１６が要求元となり、サーバ／クライアントの関係を逆転することも可能である。ただし、その際、受信サーバ装置１６は、中間サーバ装置とのリトライ制御の為にＨＴＴＰ信号送受信部を実装する必要がある。
【符号の説明】
【００５５】
１０…通信システム、１２…送信サーバ装置、Ａ１３，Ｂ１３〜ｎ１３…中間サーバ装置、１６…受信サーバ装置、１７…ＨＴＴＰ信号送受信部（要求信号再送手段）、２０…ＨＴＴＰ信号送受信部（要求信号受信手段，応答信号送信手段）、２３…障害監視制御部（障害状態取得手段）。
【図１】
2010273297.tif 000003
【図２】
2010273297.tif 000004
【図３】
2010273297.tif 000005