(57)【要約】【課題】本発明は、複数の宛先アドレスを持つサーバが用意される場合に、そのようなサーバの迅速かつ確実な利用を実現する新たな技術の提供を目的とする。【解決手段】複数の宛先アドレスを持つサーバが用意される場合に、サーバへの接続が可能な宛先アドレスを特定して、その宛先アドレスを指定してサーバへの接続を試みても、サーバを利用できない場合には、そのまま待つのではなくて、サーバへの接続が可能な別の宛先アドレスを特定して、その接続と並行する形で、その別の宛先アドレスを指定してサーバへの接続を試みるようにする。この構成に従って、クライアントとサーバとの間の回線に障害や輻輳が発生する場合にもサーバに接続できるようになるので、複数の宛先アドレスを持つサーバを迅速かつ確実に利用できるようになる。【選択図】図１
2005295477.tif 000002
【特許請求の範囲】
【請求項１】
複数の宛先アドレスを持つサーバにネットワークを介して接続されるネットワーク接続通信装置で実行される通信制御方法であって、
これまでのサーバへの接続結果に基づいて作成されて、各宛先アドレスを指定した場合のサーバへの接続の可否を示す記録情報を参照することで、サーバへの接続が可能な宛先アドレスを特定する過程と、
上記特定した宛先アドレスを指定してサーバへの接続を試みる過程と、
所定時間が経過してもサーバを利用できない場合には、上記記録情報を参照することで、サーバへの接続が可能な別の宛先アドレスを特定する過程と、
上記サーバへの接続と並行する形で、上記特定した別の宛先アドレスを指定してサーバへの接続を試みる過程とを備えることを、
特徴とする通信制御方法。
【請求項２】
複数の宛先アドレスを持つサーバにネットワークを介して接続されるネットワーク接続通信装置であって、
これまでのサーバへの接続結果に基づいて作成されて、各宛先アドレスを指定した場合のサーバへの接続の可否を示す情報を記憶する記憶手段と、
サーバへの接続要求がある場合に、上記記憶手段の記憶データに従ってサーバへの接続が可能な宛先アドレスを特定し、その宛先アドレスを指定してサーバへの接続を試みて、所定時間が経過してもサーバを利用できない場合には、上記記憶手段の記憶データに従ってサーバへの接続が可能な別の宛先アドレスを特定し、その接続と並行する形で、その別の宛先アドレスを指定してサーバへの接続を試みる接続手段と、
規定のタイムアウト時間が経過してもサーバを利用できない場合に、上記記憶手段の記憶データに従って、タイムアウトに係る宛先アドレスではサーバが利用不可能な状態にあるのか否かを判断して、その判断結果に従って上記記憶手段の記憶データを更新する実行手段とを備えることを、
特徴とするネットワーク接続通信装置。
【請求項３】
複数の宛先アドレスを持つサーバにネットワークを介して接続されるネットワーク接続通信装置であって、
宛先アドレス毎に、その宛先アドレスが有効状態にあるのか、異常状態にあるのか、使用中状態にあるのか、不明状態にあるのか、無効状態にあるのかを記憶する記憶手段と、
サーバへの接続要求がある場合に、上記記憶手段の記憶データに従って有効状態を示す宛先アドレスを特定できる場合には、その宛先アドレスを指定してサーバへの接続を試みて、その宛先アドレスの有効状態を使用中状態に変更し、一方、有効状態を示す宛先アドレスを特定できない場合には、異常状態を示す宛先アドレスを特定して、その宛先アドレスを指定してサーバへの接続を試みて、その宛先アドレスの異常状態を不明状態に変更し、さらに、所定時間が経過してもサーバを利用できない場合には、別の宛先アドレスを特定し、その接続と並行する形で、その別の宛先アドレスを指定してサーバへの接続を試みる接続手段と、
規定のタイムアウト時間が経過してもサーバを利用できない場合に、上記記憶手段の記憶データに従って、タイムアウトに係る宛先アドレスが使用中状態なのか不明状態なのかを判断して、使用中状態にある場合には、異常カウンタに初期値をセットして使用中状態を異常状態に変更し、一方、不明状態にある場合には、異常カウンタの値を１つインクリメントして、その値が上限値を超えていない場合には、不明状態を異常状態に変更し、上限値を超えた場合には、不明状態を無効状態に変更する実行手段とを備えることを、
特徴とするネットワーク接続通信装置。
【請求項４】
複数の宛先アドレスを持つサーバにネットワークを介して接続されるネットワーク接続通信装置の実現に用いられる通信制御プログラムであって、
これまでのサーバへの接続結果に基づいて作成されて、各宛先アドレスを指定した場合のサーバへの接続の可否を示す記録情報を参照することで、サーバへの接続が可能な宛先アドレスを特定する処理と、
上記特定した宛先アドレスを指定してサーバへの接続を試みる処理と、
所定時間が経過してもサーバを利用できない場合には、上記記録情報を参照することで、サーバへの接続が可能な別の宛先アドレスを特定する処理と、
上記サーバへの接続と並行する形で、上記特定した別の宛先アドレスを指定してサーバへの接続を試みる処理とをコンピュータに実行させるための通信制御プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、複数の宛先アドレスを持つサーバにネットワークを介して接続されるネットワーク接続通信装置と、そのネットワーク接続通信装置で実行される通信制御方法と、その通信制御方法の実現に用いられる通信制御プログラムとに関し、特に、サーバの迅速かつ確実な利用を実現できるようにするネットワーク接続通信装置と、そのネットワーク接続通信装置で実行される通信制御方法と、その通信制御方法の実現に用いられる通信制御プログラムとに関する。
【背景技術】
【０００２】
ネットワークを介して接続される多数のクライアントに対して、所定のサービスを提供するサーバが広く用いられている。
【０００３】
このようなサーバでは、プロバイダとの関係などにより複数のＵＲＬを持つようにして、クライアントから、それらのＵＲＬの中のいずれかのＵＲＬを指定してサービス提供要求が発行されると、それに応答して、規定のファイルを使った所定のサービスを提供するようにするという構成を採ることがある。
【０００４】
なお、本発明に関連する従来技術として、サーバ／クライアントシステムにおいて、クライアント側のルータに主回線と副回線の２回線を設け、障害が発生したら主回線から副回線に切り替えるようにするという技術がある（例えば、特許文献１参照）。
【特許文献１】特開２００３−２８３５４３
【発明の開示】
【発明が解決しようとする課題】
【０００５】
しかるに、従来技術では、サーバが複数のＵＲＬを持つようなことがあっても、クライアントは、ユーザが選んだある決められた１つのＵＲＬを指定してサーバに接続して、サービスの提供を受けるようにしていた。
【０００６】
すなわち、従来技術では、サーバが複数のＵＲＬを持つようなことがあっても、クライアントは、常に、ある決められた１つのＵＲＬを指定してサーバに接続して、サービスの提供を受けるようにしていたのである。
【０００７】
しかしながら、このような従来技術に従っていると、サーバが複数のＵＲＬを持つ場合に、サーバの迅速かつ確実な利用を実現できるようにする構成を採っていないという問題がある。
【０００８】
すなわち、サーバとクライアントとの間の回線については障害や輻輳の発生が避けられない。
【０００９】
これから、あるＵＲＬを指定してサーバに接続を試みた場合に、そのＵＲＬの接続に用いられる回線に障害が発生していると、サーバに接続できなくなってしまうことになるが、このとき、別のＵＲＬを指定してサーバに接続を試みると、別の回線を使用することになることからサーバに接続できる可能性がある。
【００１０】
同様に、あるＵＲＬを指定してサーバに接続を試みた場合に、そのＵＲＬの接続に用いられる回線が輻輳していると、サーバになかなか接続できなくなってしまうことになるが、このとき、別のＵＲＬを指定してサーバに接続を試みると、別の回線を使用することになることからサーバに迅速に接続できる可能性がある。
【００１１】
このことから分かるように、従来技術に従っていると、サーバが複数のＵＲＬを持つ場合に、サーバの迅速かつ確実な利用を実現できるようにする構成を採っていないという問題がある。
【００１２】
本発明はかかる事情に鑑みてなされたものであって、複数の宛先アドレスを持つサーバが用意される場合に、そのようなサーバの迅速かつ確実な利用を実現する新たな技術の提供を目的とする。
【課題を解決するための手段】
【００１３】
この目的を達成するために、本発明のネットワーク接続通信装置は、複数の宛先アドレスを持つサーバにネットワークを介して接続されるときにあって、（１）これまでのサーバへの接続結果に基づいて作成されて、各宛先アドレスを指定した場合のサーバへの接続の可否を示す情報を記憶する記憶手段と、（２）サーバへの接続要求がある場合に、記憶手段の記憶データに従ってサーバへの接続が可能な宛先アドレスを特定し、その宛先アドレスを指定してサーバへの接続を試みて、所定時間が経過してもサーバを利用できない場合には、記憶手段の記憶データに従ってサーバへの接続が可能な別の宛先アドレスを特定し、その接続と並行する形で、その別の宛先アドレスを指定してサーバへの接続を試みる接続手段と、（３）規定のタイムアウト時間が経過してもサーバを利用できない場合に、記憶手段の記憶データに従って、タイムアウトに係る宛先アドレスではサーバが利用不可能な状態にあるのか否かを判断して、その判断結果に従って記憶手段の記憶データを更新する実行手段とを備えるように構成する。
【００１４】
ここで、以上の各処理手段が動作することで実現される本発明の通信制御方法はコンピュータプログラムで実現できるものであり、このコンピュータプログラムは、半導体メモリなどのような適当な記録媒体に記録して提供されたり、ネットワークを介して提供され、本発明を実施する際にインストールされてＣＰＵなどの制御手段上で動作することにより本発明を実現することになる。
【００１５】
このように構成される本発明のネットワーク接続通信装置では、記憶手段は、宛先アドレス毎に、例えば、前回サーバへの接続に成功した状態にあることを示す有効状態にあるのか、前回サーバへの接続に失敗したものの、サーバへの接続が可能な状態に復帰している可能性のあることを示す異常状態にあるのか、有効状態からサーバへの接続要求に入ることで遷移する使用中状態にあるのか、異常状態からサーバへの接続要求に入ることで遷移する不明状態にあるのか、サーバへの接続が不可能な状態にあることを示す無効状態にあるのかを記憶する。
【００１６】
この記憶手段の記憶データを受けて、接続手段は、サーバへの接続要求があると、記憶手段の記憶データに従って有効状態を示す宛先アドレスを特定できる場合には、その宛先アドレスを指定してサーバへの接続を試みて、その宛先アドレスの有効状態を使用中状態に変更し、一方、有効状態を示す宛先アドレスを特定できない場合には、異常状態を示す宛先アドレスを特定して、その宛先アドレスを指定してサーバへの接続を試みて、その宛先アドレスの異常状態を不明状態に変更し、さらに、所定時間が経過してもサーバを利用できない場合には、別の宛先アドレスを特定し、その接続と並行する形で、その特定した別の宛先アドレスを指定してサーバへの接続を試みる。
【００１７】
この接続への試みが行われているときに、規定のタイムアウト時間が経過してもサーバを利用できない場合が起こると、実行手段は、記憶手段の記憶データに従って、そのタイムアウトに係る宛先アドレスが使用中状態なのか不明状態なのかを判断して、使用中状態にある場合には、異常カウンタに初期値をセットして使用中状態を異常状態に変更し、一方、不明状態にある場合には、異常カウンタの値を１つインクリメントして、その値が上限値を超えていない場合には、不明状態を異常状態に変更し、上限値を超えた場合には、不明状態を無効状態に変更する。
【００１８】
このようにして、本発明のネットワーク接続通信装置は、これまでのサーバへの接続結果に基づいて作成されて、各宛先アドレスを指定した場合のサーバへの接続の可否を示す記録情報を参照することで、サーバへの接続が可能な宛先アドレスを特定して、その宛先アドレスを指定してサーバへの接続を試みて、所定時間が経過してもサーバを利用できない場合には、その記録情報を参照することで、サーバへの接続が可能な別の宛先アドレスを特定して、その接続と並行する形で、その特定した別の宛先アドレスを指定してサーバへの接続を試みるように処理するのである。
【発明の効果】
【００１９】
以上に説明したように、本発明によれば、複数の宛先アドレスを持つサーバが用意される場合に、サーバへの接続が可能な宛先アドレスを特定して、その宛先アドレスを指定してサーバへの接続を試みても、サーバを利用できない場合には、そのまま待つのではなくて、サーバへの接続が可能な別の宛先アドレスを特定して、その接続と並行する形で、その別の宛先アドレスを指定してサーバへの接続を試みるようにすることから、クライアントとサーバとの間の回線に障害や輻輳が発生する場合にもサーバに接続できるようになるので、複数の宛先アドレスを持つサーバを迅速かつ確実に利用できるようになる。
【００２０】
そして、本発明によれば、この実現にあたって、サーバの持つ各宛先アドレスの状態を正確に把握できるようになることから、サーバへの接続が可能な宛先アドレスを正確に特定できるようになる。
【発明を実施するための最良の形態】
【００２１】
以下、実施の形態に従って本発明を詳細に説明する。
【００２２】
図１に、本発明の適用されるシステムの構成を図示する。
【００２３】
この図に示すように、本発明は、複数のＵＲＬを持つサーバ２とクライアント１とがインターネット３を介して接続されるシステムに適用されるものである。
【００２４】
本発明を具備するクライアント１は、複数のＵＲＬを持つサーバ２を迅速かつ確実に利用できるようにしつつ所定のデータ処理を実行するものであり、この図に示すように、サーバ２にアクセスして所定のデータ処理を実行するデータ処理部１０の他に、本発明を実現すべく、インターネット接続通信制御部１１とＵＲＬ管理テーブル１２とを備えるという構成を採る。
【００２５】
図２に、ＵＲＬ管理テーブル１２の管理するデータの一例を図示する。
【００２６】
ＵＲＬ管理テーブル１２は、サーバ２の持つ各ＵＲＬに対応付けて、そのＵＲＬを使用した場合のサーバ２への接続可否を示す状態情報（以下、ＵＲＬ状態情報と称することがある）と、サーバ２へコネクション要求を発行した時刻と、サーバ２からレスポンスが得られるまでの平均応答時間と、サーバ２へ送信したメッセージのＩＤ（メッセージが無効になった場合にはその旨の記録）と、サーバ２への接続ができなかった回数の累積値をカウントする異常カウンタのカウンタ値とを管理する。
【００２７】
以下に説明するように、本発明では、あるＵＲＬを指定してサーバ２に接続を試みてから、所定の時間が経過してもサーバ２を利用できない場合（接続できない場合やレスポンスが返信されてこない場合）には、別のＵＲＬを指定してサーバ２に接続を試みることになるが、その場合、同じメッセージＩＤを用いることになる。したがって、そのような場合には、ＵＲＬ管理テーブル１２に同じメッセージＩＤが複数記録されることになる。
【００２８】
ＵＲＬ管理テーブル１２に記録されるＵＲＬ状態情報としては、例えば図３に示すように、“有効”という状態と、“使用中”という状態と、“異常”という状態と、“不明”という状態と、“無効”という状態とが用いられる。
【００２９】
この“有効”という状態は、図３に示すように、前回、サーバ２へのコネクションの確立に成功した状態にあることを示すか、あるいは、電源投入時の初期状態にあることを示す。“使用中”という状態は、“有効”からコネクションの確立に入り、コネクション確立待ちあるいはレスポンス待ちで、一定時間経過した状態にあることを示す。“異常”という状態は、前回、サーバ２へのコネクションの確立に失敗した状態にあることを示すか、あるいは、タイムアウト設定時間内にレスポンスがなかった状態にあることを示す。“不明”という状態は、“異常”からコネクションの確立に入り、コネクション確立待ちあるいはレスポンス待ちの状態にあることを示す。“無効”という状態は、“異常”という状態が一定回数以上続いた状態にあることを示す。
【００３０】
ここで、“異常”という状態は、サーバ２への接続が可能な状態に復帰している可能性があることを示している。また、“無効”という状態になったＵＲＬについては、異常カウンタの値がリセットされるか、外部から“有効”に変更されない限り使用することはできない。
【００３１】
図４に、これらのＵＲＬ状態間の遷移関係を図示する。
【００３２】
この図に示すように、“有効”からコネクションの確立に入り、コネクション確立待ちあるいはレスポンス待ちで、一定時間経過した状態になると“使用中”に遷移する。そして、“使用中”のときにレスポンスを受信すると“有効”に遷移し、“使用中”のときにタイムアウトすると“異常”に遷移する。
【００３３】
一方、“異常”からコネクションの確立に入り、コネクション確立待ちあるいはレスポンス待ちの状態になると“不明”に遷移する。そして、“不明”のときにレスポンスを受信すると“有効”に遷移し、“不明”のときにタイムアウトすると、タイムアウトする回数が規定の上限値を超えない場合には“異常”に遷移し、上限値を超える場合には“無効”に遷移する。
【００３４】
図５ないし図９に、インターネット接続通信制御部１１の実行する処理フローの一例を図示する。
【００３５】
ここで、図５ないし図７は、データ処理部１０からサーバ２への接続要求が発行されるときにインターネット接続通信制御部１１が実行する処理フローを示し、図８は、インターネット接続通信制御部１１が“タイムアウト処理”の際に実行する処理フローを示し、図９は、インターネット接続通信制御部１１が“レスポンス受信処理”の際に実行する処理フローを示す。
【００３６】
次に、これらの処理フローに従って、本発明を具備するクライアント１の実行する処理について詳細に説明する。
【００３７】
インターネット接続通信制御部１１は、データ処理部１０からサーバ２への接続要求が発行されると、図５ないし図７の処理フローに示すように、先ず最初に、ステップ１０で、ＵＲＬ管理テーブル１２から“有効”な状態にあるＵＲＬを検索する。
【００３８】
続いて、ステップ１１で、“有効”な状態にあるＵＲＬを検索できたのか否かを判断して、“有効”な状態にあるＵＲＬを検索できたことを判断するときには、ステップ１２に進んで、ＵＲＬ管理テーブル１２の管理する平均応答時間に従って、その中から平均応答時間が最小のＵＲＬを特定する。
【００３９】
続いて、ステップ１３で、その特定したＵＲＬを指定してサーバ２に接続（コネクション）要求を行い、メッセージＩＤとコネクション要求時刻とをＵＲＬ管理テーブル１２に記録する。
【００４０】
続いて、ステップ１４で、一定時間が経過してもサーバ２に接続できないのか否かを判断して、一定時間が経過してもサーバ２に接続できないことを判断するときには、ステップ１５に進んで、ＵＲＬ管理テーブル１２の管理する対応のＵＲＬ状態情報を“有効”から“使用中”に変更して、タイムアウト監視タイマをスタートしてから、別のＵＲＬを指定してサーバ２に接続要求を行うべく、ステップ１０に戻る。
【００４１】
一方、ステップ１４で、一定時間が経過する前にサーバ２に接続できたことを判断するときには、ステップ１６に進んで、接続できたサーバ２に対してコマンドを送信してレスポンスが返信されてくるのを待つ。
【００４２】
続いて、ステップ１７で、一定時間（接続要求開始を時間経過の基準にしてもよいし、接続成功を時間経過の基準にしてもよい）が経過してもサーバ２からレスポンスが返信されてこないのか否かを判断して、一定時間が経過してもサーバ２からレスポンスが返信されてこないことを判断するときには、ステップ１８に進んで、ＵＲＬ管理テーブル１２の管理する対応のＵＲＬ状態情報を“有効”から“使用中”に変更して、タイムアウト監視タイマをスタートしてから、別のＵＲＬを指定してサーバ２に接続要求を行うべく、ステップ１０に戻る。
【００４３】
そして、ステップ１７で、一定時間が経過する前にサーバ２からレスポンスが返信されてきたことを判断するときには、後述する図９の処理フローの“レスポンス受信処理”に入る。
【００４４】
一方、ステップ１１で、“有効”な状態にあるＵＲＬを検索できないことを判断するときには、ステップ１９に進んで、ＵＲＬ管理テーブル１２から“異常”な状態にあるＵＲＬを検索する。
【００４５】
続いて、ステップ２０で、“異常”な状態にあるＵＲＬを検索できたのか否かを判断して、“異常”な状態にあるＵＲＬを検索できたことを判断するときには、ステップ２１に進んで、その検索したＵＲＬを指定してサーバ２に接続（コネクション）要求を行い、メッセージＩＤとコネクション要求時刻とをＵＲＬ管理テーブル１２に記録し、さらに、ＵＲＬ管理テーブル１２の管理する対応のＵＲＬ状態情報を“異常”から“不明”に変更する。
【００４６】
ここで、“異常”な状態にあるＵＲＬを複数検索できた場合には、例えば、その中から異常カウンタの値が最小のＵＲＬを特定して、それを指定してサーバ２に接続要求を行うようにする。
【００４７】
続いて、ステップ２２で、一定時間が経過してもサーバ２に接続できないのか否かを判断して、一定時間が経過してもサーバ２に接続できないことを判断するときには、ステップ２３に進んで、メッセージＩＤは有効であるのか否かを判断する。
【００４８】
ここで、メッセージＩＤについては、後述する図８の処理フローの“タイムアウト処理”や、後述する図９の処理フローの“レスポンス受信処理”により無効化されることになる。
【００４９】
この判断処理に従って、メッセージＩＤが無効であることを判断するときには、送信要求を終了し、一方、メッセージＩＤが有効であることを判断するときには、ステップ２４に進んで、タイムアウト監視タイマをスタートしてから、別のＵＲＬを指定してサーバ２に接続要求を行うべく、ステップ１９に戻る。
【００５０】
一方、ステップ２２で、一定時間が経過する前にサーバ２に接続できたことを判断するときには、ステップ２５に進んで、接続できたサーバ２に対してコマンドを送信してレスポンスが返信されてくるのを待つ。
【００５１】
続いて、ステップ２６で、一定時間（接続要求開始を時間経過の基準にしてもよいし、接続成功を時間経過の基準にしてもよい）が経過してもサーバ２からレスポンスが返信されてこないのか否かを判断して、一定時間が経過してもサーバ２からレスポンスが返信されてこないことを判断するときには、ステップ２７に進んで、メッセージＩＤは有効であるのか否かを判断する。
【００５２】
この判断処理に従って、メッセージＩＤが無効であることを判断するときには、送信要求を終了し、一方、メッセージＩＤが有効であることを判断するときには、ステップ２８に進んで、タイムアウト監視タイマをスタートしてから、別のＵＲＬを指定してサーバ２に接続要求を行うべく、ステップ１９に戻る。
【００５３】
そして、ステップ２６で、一定時間が経過する前にサーバ２からレスポンスが返信されてきたことを判断するときには、後述する図９の処理フローの“レスポンス受信処理”に入る。
【００５４】
一方、ステップ２０で、“異常”な状態にあるＵＲＬを検索できないことを判断するときには、ステップ２９に進んで、ＵＲＬ管理テーブル１２から“使用中”か“不明”の状態にあるＵＲＬを検索する。
【００５５】
続いて、ステップ３０で、“使用中”か“不明”の状態にあるＵＲＬを検索できたのか否かを判断して、検索できたことを判断するときには、接続要求を行っている最中なので、この時点における送信要求を終了し、検索できないことを判断するときには、送信エラーを出力して、処理を終了する。
【００５６】
このようにして、インターネット接続通信制御部１１は、データ処理部１０からサーバ２への接続要求が発行されると、ＵＲＬ管理テーブル１２の管理データに従って“有効”の状態にあるＵＲＬを特定できる場合には、そのＵＲＬを指定してサーバ２への接続を試みて、所定時間が経過してもサーバ２を利用できない場合（接続できない場合や、レスポンスが返信されてこない場合）には、そのＵＲＬの状態を“有効”から“使用中”に変更してから、別のＵＲＬを指定してサーバ２への接続を試み、一方、“有効”の状態にあるＵＲＬを特定できない場合には、“異常”の状態にあるＵＲＬを特定して、そのＵＲＬの状態を“異常”から“不明”に変更してから、そのＵＲＬを指定してサーバ２への接続を試みて、所定時間が経過してもそのサーバ２を利用できない場合には、別のＵＲＬを指定してサーバ２への接続を試みるように処理するのである。
【００５７】
次に、図８の処理フローに従って、タイムアウト監視タイマがタイムアウトしたときに実行する処理について説明する。
【００５８】
インターネット接続通信制御部１１は、タイムアウト監視タイマがタイムアウトすると、図８の処理フローに示すように、先ず最初に、ステップ４０で、タイムアウトした接続要求で指定したＵＲＬをＵＲＬ管理テーブル１２から探し出して、メッセージＩＤを無効に変更する。
【００５９】
続いて、ステップ４１で、ＵＲＬ管理テーブル１２の管理データに従って、タイムアウトした接続要求で指定したＵＲＬの状態情報が“使用中”であるのか“不明”であるのかをチェックする。
【００６０】
続いて、ステップ４２で、このチェックにより、タイムアウトした接続要求で指定したＵＲＬの状態情報が“使用中”であることを特定できたのかを判断して、“使用中”であることを判断するときには、ステップ４３に進んで、異常カウンタに初期値の１をセットし、続くステップ４４で、ＵＲＬ管理テーブル１２の管理する対応のＵＲＬ状態情報を“使用中”から“異常”に変更して、タイムアウト処理を終了する。
【００６１】
一方、ステップ４２で、タイムアウトした接続要求で指定したＵＲＬの状態情報が“使用中”でないことを判断するとき、すなわち、タイムアウトした接続要求で指定したＵＲＬの状態情報が“不明”であることを判断するときには、ステップ４５に進んで、異常カウンタの値を１つインクリメントする。
【００６２】
続いて、ステップ４６で、異常カウンタの値が上限値を超えたのか否かを判断して、上限値を超えたことを判断するときには、ステップ４７に進んで、ＵＲＬ管理テーブル１２の管理する対応のＵＲＬ状態情報を“不明”から“無効”に変更して、タイムアウト処理を終了する。
【００６３】
一方、ステップ４６で、異常カウンタの値が上限値を超えていないことを判断するときには、ステップ４８に進んで、ＵＲＬ管理テーブル１２の管理する対応のＵＲＬ状態情報を“不明”から“異常”に変更して、タイムアウト処理を終了する。
【００６４】
このようにして、インターネット接続通信制御部１１は、タイムアウト監視タイマがタイムアウトすると、そのタイムアウトした接続要求で指定したＵＲＬが“有効”から接続に入って“使用中”に遷移してタイムアウトしたのか、それとも“異常”から接続に入って“不明”に遷移してタイムアウトしたのかを判断して、前者の場合には、異常カウンタに初期値の１をセットして、ＵＲＬ状態情報を“異常”に変更し、後者の場合には、異常カウンタの値を１つインクリメントして、上限値を超えない場合にはＵＲＬ状態情報を“異常”に変更し、上限値を超えた場合にはＵＲＬ状態情報を“無効”に変更するように処理するのである。
【００６５】
次に、図９の処理フローに従って、“レスポンス受信処理”に入ったときに実行する処理について説明する。
【００６６】
インターネット接続通信制御部１１は、“レスポンス受信処理”に入ると、図９の処理フローに示すように、先ず最初に、ステップ５０で、受信したレスポンスに対応するＵＲＬ（そのレスポンスの元となった接続要求で指定したＵＲＬ）をＵＲＬ管理テーブル１２から探し出して、対応するタイムアウト監視タイマを停止するとともに、対応する異常カウンタの値を０にクリアする。
【００６７】
続いて、ステップ５１で、接続要求からレスポンス受信までの時間を元に、ＵＲＬ管理テーブル１２の管理する対応の平均応答時間の値を更新し、さらに、ＵＲＬ管理テーブル１２の管理する対応のＵＲＬ状態情報を“有効”に変更する。
【００６８】
続いて、ステップ５２で、ＵＲＬ管理テーブル１２の管理データに従って、受信したレスポンスに対応するＵＲＬに対応付けて記録されるメッセージＩＤが有効であるのか否かをチェックする。
【００６９】
続いて、ステップ５３で、このチェックにより、受信したレスポンスに対応するＵＲＬに対応付けて記録されるメッセージＩＤが有効であることを特定できたのかを判断して、このメッセージＩＤが有効であることを判断するときには、ステップ５４に進んで、レスポンスを受信できることになったことに対応させて、すべてのメッセージＩＤ（同じメッセージＩＤを持つ）を無効とし、続くステップ５５で、受信したレスポンスについての処理を行って、“レスポンス受信処理”を終了する。
【００７０】
一方、ステップ５３で、受信したレスポンスに対応するＵＲＬに対応付けて記録されるメッセージＩＤが無効であることを判断するときには、ステップ５４〜５５の処理を省略して、直ちに“レスポンス受信処理”を終了する。
【００７１】
このようにして、インターネット接続通信制御部１１は、“レスポンス受信処理”に入ると、対応するタイムアウト監視タイマを停止するとともに、ＵＲＬ管理テーブル１２の管理する異常カウンタの値を０にクリアし、ＵＲＬ管理テーブル１２の管理する平均応答時間の値を更新し、ＵＲＬ管理テーブル１２の管理するＵＲＬ状態情報を“有効”に変更し、ＵＲＬ管理テーブル１２の管理するメッセージＩＤを無効にするように処理するのである。
【００７２】
以上に説明したように、インターネット接続通信制御部１１は、複数のＵＲＬを持つサーバ２が用意される場合に、サーバ２への接続が可能なＵＲＬを特定して、そのＵＲＬを指定してサーバ２への接続を試みても、サーバ２を利用できない場合には、そのまま待つのではなくて、サーバ２への接続が可能な別のＵＲＬを特定して、その接続と並行する形で、その別のＵＲＬを指定してサーバ２への接続を試みるようにすることから、複数のＵＲＬを持つサーバ２を迅速かつ確実に利用できるようになる。
【００７３】
なお、以上に説明した処理に従ってサーバ２が利用できる状態になると、インターネット接続通信制御部１１は、その最初に利用できるようになった状態を使って処理を進めることになる。
【００７４】
図１では、サーバ２が１台で構成されて、そのサーバ２が複数のＵＲＬを持つシステムのものを示したが、図１０に示すように、同一のサービスを提供する複数のサーバ２-i（ｉ＝１〜ｎ）が用意されていて、その各々のサーバ２-iが別々のＵＲＬを持つシステムに対しても、本発明はそのまま適用できるものである。
【図面の簡単な説明】
【００７５】
【図１】本発明の適用されるシステムの説明図である。
【図２】ＵＲＬ管理テーブルの管理するデータの一例である。
【図３】サーバ状態情報の説明図である。
【図４】サーバ状態の遷移の説明図である。
【図５】インターネット接続通信制御部の実行する処理フローの一例である。
【図６】インターネット接続通信制御部の実行する処理フローの一例である。
【図７】インターネット接続通信制御部の実行する処理フローの一例である。
【図８】インターネット接続通信制御部の実行する処理フローの一例である。
【図９】インターネット接続通信制御部の実行する処理フローの一例である。
【図１０】本発明の適用される他のシステムの説明図である。
【符号の説明】
【００７６】
１    クライアント
２    サーバ
３    インターネット
１０  データ処理部
１１  インターネット接続通信制御部
１２  ＵＲＬ管理テーブル
【図１】
2005295477.tif 000003
【図２】
2005295477.tif 000004
【図３】
2005295477.tif 000005
【図４】
2005295477.tif 000006
【図５】
2005295477.tif 000007
【図６】
2005295477.tif 000008
【図７】
2005295477.tif 000009
【図８】
2005295477.tif 000010
【図９】
2005295477.tif 000011
【図１０】
2005295477.tif 000012