(57)【要約】【課題】ＤＮＳラウンドロビンの欠点を補うことのできる新たな方法を提供すること。【解決手段】  まず、所望とするリソースに対するＵＲＬに含まれるドメイン名に対する名前解決をＤＮＳサーバに依頼した結果として（ステップＳ１００）、取得したＩＰアドレスが複数あった場合、当該複数のＩＰアドレスに順位付けをし、順位付けられた複数のＩＰアドレスからなるＩＰアドレスリストを作成する（ステップＳ２００）。次いで、そのＩＰアドレスリストに含まれるＩＰアドレスを順にチェックして、リスト中にリソースの取得先となり得るサーバ（取得先サーバ）が含まれているか否かを判断し（ステップＳ３００）、取得先サーバが見つかった場合には、その取得先サーバからリソースを取得する（ステップＳ４００）。【選択図】図２
2008010919.tif 000002
【特許請求の範囲】
【請求項１】
少なくともＤＮＳサーバを含むネットワーク上において所定ＵＲＬで示される所定リソースを取得する方法であって、
前記ＤＮＳサーバに名前解決を依頼して、前記所定ＵＲＬに含まれるドメイン名に対応するＩＰアドレスを取得するアドレス取得ステップと、
前記ドメイン名に対して取得したＩＰアドレスが複数あった場合、当該複数のＩＰアドレスに順位付けをし、該順位付けられた複数のＩＰアドレスからなるＩＰアドレスリストを作成するリスト作成ステップと、
前記ＩＰアドレスリストに掲げられている前記複数のＩＰアドレスで示される複数のサーバの中に前記所定リソースの取得先となり得るサーバが含まれていた場合、そのうちの一つのサーバを取得先サーバとして特定するサーバ特定ステップと、
該取得先サーバから前記所定リソースを取得するリソース取得ステップと
を備えるリソース取得方法。
【請求項２】
前記リスト作成ステップは、乱数を用いて前記取得した複数のＩＰアドレスを並べ替えることにより前記順位付けを行う、
請求項１記載のリソース取得方法。
【請求項３】
前記サーバ特定ステップは、
前記ＩＰアドレスリストからＩＰアドレスを一つ抽出するアドレス抽出ステップと、
該抽出したＩＰアドレスで指定されるサーバから前記所定リソースを取得可能か判断するリソース取得可否判断ステップと、
該リソース取得可否判断ステップにおいて前記所定リソースを取得可能であると判断した場合、当該サーバを前記取得先サーバとして選択するサーバ選択ステップと、
前記リソース取得可否判断ステップにおいて前記所定リソースを取得可能であると判断しなかった場合、当該サーバに対応するＩＰアドレスを抽出対象から外すべく前記ＩＰアドレスリストの更新を行なうリスト更新ステップと
を備え、当該リスト更新ステップにおいて更新されたＩＰアドレスリストに基づいて前記アドレス抽出ステップ以降の処理を実行する、請求項１又は請求項２記載のリソース取得方法。
【請求項４】
前記リスト作成ステップは、前記順位付けられた複数のＩＰアドレスのそれぞれにフラグフィールドを付加し且つ当該フラグフィールドに有効フラグを立てるようにして前記ＩＰアドレスリストを作成するものであり、
前記アドレス抽出ステップは、前記ＩＰアドレスリストを先頭から検索し、最初にヒットした有効フラグの立っているＩＰアドレスを抽出するものであり、
前記リスト更新ステップは、前記リソース取得可否判断ステップにおいて前記所定リソースを取得可能であると判断しなかった場合、前記ＩＰアドレスリストにおいて当該サーバに対応する前記ＩＰアドレスの前記フラグフィールドに立ててあった前記有効フラグを下げるものである、
請求項３記載のリソース取得方法。
【請求項５】
前記リソース取得可否判断ステップは、
前記抽出したＩＰアドレスで指定されるサーバに対して接続可否判断時間中に接続を完了できなかった場合に、前記所定リソースを取得可能ではないと判断する接続ベース判断ステップを備えている、
請求項３又は請求項４記載のリソース取得方法。
【請求項６】
前記リソース取得可否判断ステップは、
前記抽出したＩＰアドレスで指定されるサーバに対して前記所定リソースを要求するリソース要求ステップと、
ヘッダ読込可否判断時間中に、当該所定リソースの要求に対するレスポンスに含まれるヘッダ情報のみを先行して読み込めなかった場合に、前記所定リソースを取得可能ではないと判断するレスポンスベース判断ステップ
を備えている、請求項３乃至請求項５のいずれかに記載のリソース取得方法。
【請求項７】
プロセッサ、一時的な記憶領域としても動作する記憶部、及び前記プロセッサによる制御に基づいて外部とデータの送受信を行うための送受信部を備えたコンピュータにおいて前記プロセッサに対して所定の処理を実行させ、少なくともＤＮＳサーバを含むネットワーク上において所定ＵＲＬで示される所定リソースを取得させるためのコンピュータプログラムであって、
前記所定の処理は、
前記ＤＮＳサーバに名前解決を依頼して、前記所定ＵＲＬに含まれるドメイン名に対応するＩＰアドレスを取得するアドレス取得ステップと、
前記ドメイン名に対して取得したＩＰアドレスが複数あった場合、当該複数のＩＰアドレスに順位付けをし、該順位付けられた複数のＩＰアドレスからなるＩＰアドレスリストを作成するリスト作成ステップと、
前記ＩＰアドレスリストに掲げられている前記複数のＩＰアドレスで示される複数のサーバの中に前記所定リソースの取得先となり得るサーバが含まれていた場合、そのうちの一つのサーバを取得先サーバとして特定するサーバ特定ステップと、
該取得先サーバから前記所定リソースを取得するリソース取得ステップと
を含む、コンピュータプログラム。
【請求項８】
前記リスト作成ステップは、乱数を用いて前記取得した複数のＩＰアドレスを並べ替えることにより前記順位付けを行う、
請求項７記載のコンピュータプログラム。
【請求項９】
前記サーバ特定ステップは、
前記ＩＰアドレスリストからＩＰアドレスを一つ抽出するアドレス抽出ステップと、
該抽出したＩＰアドレスで指定されるサーバから前記所定リソースを取得可能か判断するリソース取得可否判断ステップと、
該リソース取得可否判断ステップにおいて前記所定リソースを取得可能であると判断した場合、当該サーバを前記取得先サーバとして選択するサーバ選択ステップと、
前記リソース取得可否判断ステップにおいて前記所定リソースを取得可能であると判断しなかった場合、当該サーバに対応するＩＰアドレスを抽出対象から外すべく前記ＩＰアドレスリストの更新を行なうリスト更新ステップと
を備えており、当該リスト更新ステップにおいて更新されたＩＰアドレスリストに基づいて前記アドレス抽出ステップ以降の処理を実行するように構成されている、請求項７又は請求項８記載のコンピュータプログラム。
【請求項１０】
前記リスト作成ステップは、前記順位付けられた複数のＩＰアドレスのそれぞれにフラグフィールドを付加し且つ当該フラグフィールドに有効フラグを立てるようにして前記ＩＰアドレスリストを作成するものであり、
前記アドレス抽出ステップは、前記ＩＰアドレスリストを先頭から検索し、最初にヒットした有効フラグの立っているＩＰアドレスを抽出するものであり、
前記リスト更新ステップは、前記リソース取得可否判断ステップにおいて前記所定リソースを取得可能であると判断しなかった場合、前記ＩＰアドレスリストにおいて当該サーバに対応する前記ＩＰアドレスの前記フラグフィールドに立ててあった前記有効フラグを下げるものである、
請求項９記載のコンピュータプログラム。
【請求項１１】
前記リソース取得可否判断ステップは、
前記抽出したＩＰアドレスで指定されるサーバに対して接続可否判断時間中に接続を完了できなかった場合に、前記所定リソースを取得可能ではないと判断する接続ベース判断ステップを備えている、
請求項９又は請求項１０記載のコンピュータプログラム。
【請求項１２】
前記リソース取得可否判断ステップは、
前記抽出したＩＰアドレスで指定されるサーバに対して前記所定リソースを要求するリソース要求ステップと、
ヘッダ読込可否判断時間中に、当該所定リソースの要求に対するレスポンスに含まれるヘッダ情報のみを先行して読み込めなかった場合に、前記所定リソースを取得可能ではないと判断するレスポンスベース判断ステップ
を備えている、請求項９乃至請求項１１のいずれかに記載のコンピュータプログラム。
【請求項１３】
請求項７乃至請求項１２のいずれかに記載のコンピュータプログラムを含むアプリケーションプログラムであって、Ｗｅｂとの連携を前提とし且つＷｅｂブラウザから独立したアプリケーションプログラム。
【請求項１４】
プロセッサ、一時的な記憶領域としても動作する記憶部、及び前記プロセッサによる制御に基づいて外部とデータの送受信を行うための送受信部を備えた端末であって、
前記記憶部には、前記プロセッサに対して所定の処理を実行させ、少なくともＤＮＳサーバを含むネットワーク上において所定ＵＲＬで示される所定リソースを取得させるためのプログラムが格納されており、
前記所定の処理は、
前記ＤＮＳサーバに名前解決を依頼して、前記所定ＵＲＬに含まれるドメイン名に対応するＩＰアドレスを取得するアドレス取得ステップと、
前記ドメイン名に対して取得したＩＰアドレスが複数あった場合、当該複数のＩＰアドレスに順位付けをし、該順位付けられた複数のＩＰアドレスからなるＩＰアドレスリストを作成するリスト作成ステップと、
前記ＩＰアドレスリストに掲げられている前記複数のＩＰアドレスで示される複数のサーバの中に前記所定リソースの取得先となり得るサーバが含まれていた場合、そのうちの一つのサーバを取得先サーバとして特定するサーバ特定ステップと、
該取得先サーバから前記所定リソースを取得するリソース取得ステップと
を含む、端末。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、所望とするリソースを取得するための手法に対する改良及びそれを実装してなるコンピュータプログラムに関する。
【背景技術】
【０００２】
従来、インターネットなどのネットワーク上における負荷分散技術として、ＤＮＳサーバを利用して容易に実現可能なＤＮＳラウンドロビン又は単にラウンドロビンと呼ばれる技術が知られている（例えば、特許文献１の００１３欄）。ＤＮＳラウンドロビンにおいては、まず、ＤＮＳサーバ上で一つのドメイン名と複数のＩＰアドレスとを対応付けておき、クライアントからＤＮＳサーバに名前解決の依頼があった場合、ＤＮＳサーバがその都度異なる順番でＩＰアドレスを回答する。クライアントは、受信したＩＰアドレスの最初のＩＰアドレスにアクセスを試みるので、ＤＮＳラウンドロビンによれば、アクセスされるサーバが分散する。
【０００３】
【特許文献１】特開２００４−２６０３３２号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
ＤＮＳサーバから指定されたサーバに何らかの障害が発生していた場合にはクライアントは当該サーバにアクセスできないこととなる。
【０００５】
しかしながら、ＤＮＳラウンドロビンではサーバの障害検知は考慮されていないことから、障害発生中のサーバにクライアントがリクエストを出すことも多々あり、その結果、タイムアウトエラーとなると、クライアントは、再度、ＤＮＳサーバに名前解決の依頼を行わなければならないといった問題が生じていた。
【０００６】
本発明は、ＤＮＳラウンドロビンの欠点を補うことのできる新たな方法並びにそれを実装してなるコンピュータプログラム及び当該プログラムを組み込まれた端末を提供することを目的とする。
【課題を解決するための手段】
【０００７】
本発明は、上記課題を解決するための手段として、少なくともＤＮＳサーバを含むネットワーク上において所定ＵＲＬで示される所定リソースを取得する方法であって、
前記ＤＮＳサーバに名前解決を依頼して、前記所定ＵＲＬに含まれるドメイン名に対応するＩＰアドレスを取得するアドレス取得ステップと、
前記ドメイン名に対して取得したＩＰアドレスが複数あった場合、当該複数のＩＰアドレスに順位付けをし、該順位付けられた複数のＩＰアドレスからなるＩＰアドレスリストを作成するリスト作成ステップと、
前記ＩＰアドレスリストに掲げられている前記複数のＩＰアドレスで示される複数のサーバの中に前記所定リソースの取得先となり得るサーバが含まれていた場合、そのうちの一つのサーバを取得先サーバとして特定するサーバ特定ステップと、
該取得先サーバから前記所定リソースを取得するリソース取得ステップと
を備えるリソース取得方法を提供する。
【０００８】
また、本発明は、プロセッサ、一時的な記憶領域としても動作する記憶部、及び前記プロセッサによる制御に基づいて外部とデータの送受信を行うための送受信部を備えたコンピュータにおいて前記プロセッサに対して所定の処理を実行させ、少なくともＤＮＳサーバを含むネットワーク上において所定ＵＲＬで示される所定リソースを取得させるためのコンピュータプログラムであって、
前記所定の処理は、
前記ＤＮＳサーバに名前解決を依頼して、前記所定ＵＲＬに含まれるドメイン名に対応するＩＰアドレスを取得するアドレス取得ステップと、
前記ドメイン名に対して取得したＩＰアドレスが複数あった場合、当該複数のＩＰアドレスに順位付けをし、該順位付けられた複数のＩＰアドレスからなるＩＰアドレスリストを作成するリスト作成ステップと、
前記ＩＰアドレスリストに掲げられている前記複数のＩＰアドレスで示される複数のサーバの中に前記所定リソースの取得先となり得るサーバが含まれていた場合、そのうちの一つのサーバを取得先サーバとして特定するサーバ特定ステップと、
該取得先サーバから前記所定リソースを取得するリソース取得ステップと
を含む、コンピュータプログラムを提供する。
【０００９】
更に、本発明は、プロセッサ、一時的な記憶領域としても動作する記憶部、及び前記プロセッサによる制御に基づいて外部とデータの送受信を行うための送受信部を備えた端末であって、
前記記憶部には、前記プロセッサに対して所定の処理を実行させ、少なくともＤＮＳサーバを含むネットワーク上において所定ＵＲＬで示される所定リソースを取得させるためのプログラムが格納されており、
前記所定の処理は、
前記ＤＮＳサーバに名前解決を依頼して、前記所定ＵＲＬに含まれるドメイン名に対応するＩＰアドレスを取得するアドレス取得ステップと、
前記ドメイン名に対して取得したＩＰアドレスが複数あった場合、当該複数のＩＰアドレスに順位付けをし、該順位付けられた複数のＩＰアドレスからなるＩＰアドレスリストを作成するリスト作成ステップと、
前記ＩＰアドレスリストに掲げられている前記複数のＩＰアドレスで示される複数のサーバの中に前記所定リソースの取得先となり得るサーバが含まれていた場合、そのうちの一つのサーバを取得先サーバとして特定するサーバ特定ステップと、
該取得先サーバから前記所定リソースを取得するリソース取得ステップと
を含む、端末を提供する。
【発明の効果】
【００１０】
前述したように、従来技術によれば、ＤＮＳサーバから一つのドメイン名に対応するＩＰアドレスが複数送られてきた場合であっても先頭の一つしか用いなかったため、使用したＩＰアドレスに対応するサーバに障害が発生していた場合には、ＤＮＳサーバに再度名前解決を依頼しなければならなかった。これに対して、本発明によれば、ＤＮＳサーバから一旦複数のＩＰアドレスを取得してしまった後は、複数のＩＰアドレスに対応するサーバの中に含まれる障害の発生していないサーバを特定して、その特定したサーバからリソースを取得することとしたため、再度、ＤＮＳサーバに名前解決を依頼する必要がなくなり、トラヒックを減ずることができる。
【００１１】
加えて、複数のＩＰアドレスに対応するサーバの中から障害の発生していないサーバを特定する処理を自動化することにより、ユーザが同一処理を繰り返す必要がなくなり、使い勝手が向上する。
【発明を実施するための最良の形態】
【００１２】
以下、図面を参照して、本発明の実施の形態によるリソース取得方法について詳細に説明する。
【００１３】
本発明の実施の形態によるリソース取得方法は、図１に示されるクライアント端末１００において実行されるものである。クライアント端末１００は、図１に示されるように、インターネット２００を介して、ＤＮＳサーバや各種リソースを有するサーバ４００，４１０，４２０と接続されている。
【００１４】
クライアント端末１００は、ＣＰＵ（又はプロセッサ）１０、主記憶２０、補助記憶３０及び送受信部（通信制御部）４０を備えている。このうち、主記憶２０は、例えば、ＤＲＡＭで構成され、補助記憶３０は、例えば、ＨＤＤで構成される。ＲＯＭやディスプレイ、入力デバイスなど、図示されていないコンピュータ要素については本実施の形態に直接的には関係しないため説明を省略する。
【００１５】
補助記憶３０には、本実施の形態によるリソース取得方法をＣＰＵ１０に対して実行させるためのプログラム（リソース取得プログラム）が格納されている。より具体的には、本実施の形態におけるリソース取得プログラムは、例えば、ウィジェット又はガジェットと呼ばれるＷｅｂとの連携を前提とし且つＷｅｂブラウザから独立した比較的小さなアプリケーションプログラムの一部として実装されている。しかしながら、本発明はこれに制限されるものではなく、例えば、Ｗｅｂブラウザのような比較的大きなプログラムの一部として実装されていても良い。リソース取得プログラムを含むアプリケーションプログラムは、主記憶２０上に展開され、ＣＰＵ１０によって実行される。また、主記憶２０上には、ＣＰＵ１０がプログラムに従って動作している間に生成したデータやＣＰＵ１０により利用されるデータが一時的に記憶される。なお、一般にはコンピュータシステム上で本発明を実現する場合、上記したように主記憶２０と補助記憶３０とを分ける構成が主として採用されるが、概念的には両者を一の記憶手段として捉えることも可能である。送受信部４０は、ＣＰＵ１０の制御の下、クライアント端末１００外部とのデータの送受信を行う。
【００１６】
このような構成を備えるクライアント端末１００において、上述したようにして、主記憶２０上に展開されたプログラムの各ステートメントをＣＰＵ１０が実行することにより、本実施の形態によるリソース取得方法が、概略、図２に示されるようにして行われる。本実施の形態において、取得したいリソースがネットワーク上のどこに存在しているかは、ＵＲＬにて特定されているものとする。また、リソースの例としては、例えば、ＸＭＬファイルやｊｐｅｇファイルなどが挙げられる。
【００１７】
まず、ＤＮＳサーバ３００に名前解決を依頼して、ＵＲＬに含まれるドメイン名に対応するＩＰアドレスを取得する（ステップＳ１００）。ここで、本実施の形態においては、所望とするリソースに関連したＩＰアドレスが複数個あったものとする。なお、ＤＮＳサーバから返ってきたＩＰアドレスが一つだけであった場合、従来技術と同様、そのＩＰアドレスを用いてリソース取得を試みるだけである。
【００１８】
次いで、複数のＩＰアドレスに順位付けをし、順位付けられた複数のＩＰアドレスからなるＩＰアドレスリストを作成する（ステップＳ２００）。
【００１９】
より具体的には、まず、図３に示されるように、取得したＩＰアドレスを取得順に並べ、且つ、各ＩＰアドレスにフラグフィールドを付加して、原ＩＰアドレスリストを作成する（ステップＳ２１０）。次に、乱数を用いて、その原ＩＰアドレスリストに含まれる複数のＩＰアドレスを並べ替えることによりＩＰアドレスリストを作成する（ステップＳ２２０）。このように、ローカル側でも乱数を用いたＩＰアドレスリストの並び替えを行うことにより、サーバに対する負荷の更なる分散を図ることができる。その後、ＩＰアドレスリスト内に含まれるすべてのフラグフィールドに有効フラグを立てる（ステップＳ２３０）。
【００２０】
従来のＤＮＳラウンドロビンの場合、クライアントは送られてきた複数のＩＰアドレスのうち先頭のＩＰアドレスのみを使用して、そのＩＰアドレスに対応するサーバにアクセスを試み、その結果、失敗した場合には、再度、ＤＮＳサーバに名前解決をしていた。ここで、通常であれば、すべてのサーバに障害が発生している可能性は極めて低いことから、先頭のＩＰアドレス以外のＩＰアドレスで示されるサーバの中にはアクセス可能なサーバも存在している。従来、先頭のＩＰアドレス以外のＩＰアドレスで示されるサーバへアクセスが可能か否かを検証することなく、ＤＮＳサーバに、再度の名前解決を依頼していたことから、いわば、不要なトラヒックが発生していた。本実施の形態においては、かかる不要なトラヒックの発生を抑えるべく、ＩＰアドレスリストに含まれるすべてのＩＰアドレスに対応するサーバの中に取得先サーバ（所望とするリソースを有するアクセス可能なサーバ）があるか否かを検討する（ステップＳ３００）。その結果、ＩＰアドレスリストに含まれるすべてのＩＰアドレスに対応するサーバの中に取得先サーバがあった場合には、その取得先サーバからリソースを取得し（ステップＳ４００）、逆に、ＩＰアドレスリストに含まれるすべてのＩＰアドレスに対応するサーバの中に取得先サーバが含まれていなかった場合には、エラー処理を行う（ステップＳ５００）。
【００２１】
ステップＳ３００について具体的に説明すると、図４に示されるように、まず、ＩＰアドレスリストの中からＩＰアドレスを一つ抽出し（ステップＳ３１０）、その抽出したＩＰアドレスで示されるサーバからリソースを取得可能か否か判断する（ステップＳ３２０）。ステップＳ３２０において、リソース取得可能と判断した場合には、前述のように、ステップＳ４００に進み、リソース取得を行う。一方、ステップＳ３２０において、リソース取得可能ではないと判断した場合には、判断対象であったＩＰアドレスを抽出済とするようにＩＰアドレスリストの更新を行い（ステップＳ３３０）、その後、ステップＳ３１０に戻る。ステップＳ３１０では、ＩＰアドレスリストに含まれるＩＰアドレスのうち、未だ抽出されていないＩＰアドレスがあればそれを抽出し、ステップＳ３２０以降の処理を続行する。もし、ＩＰアドレスリストに含まれていたＩＰアドレスがすべて抽出されてしまった場合（即ち、ステップＳ３１０においてＩＰアドレスの抽出に失敗した場合）、取得先サーバが存在しなかったということになるので、ステップＳ５００に進み、エラー処理を行う。
【００２２】
ここで、図３を用いて詳述したように、本実施の形態によるリソース取得方法のステップＳ２００ではＩＰアドレスリスト内の全ＩＰアドレスに有効フラグを立てており、本実施の形態においては、これを利用して、未抽出のＩＰアドレスがＩＰアドレスリスト内にあるか否かを判断している（ステップＳ３１０）。
【００２３】
即ち、ステップＳ３１０においては、まず、ＩＰアドレスリストを先頭から検索し、有効フラグの立っているＩＰアドレスで最初にヒットしたものを抽出する。次いで、ステップＳ３２０において、この抽出したＩＰアドレスで示されるサーバからはリソースを取得できないと判断した場合、ステップＳ３３０において、ＩＰアドレスリスト内に含まれるフラグフィールドのうち当該ＩＰアドレスのフラグフィールドに立ててあった有効フラグを下げ、当該ＩＰアドレスを抽出対象から外すようにしてから、ステップＳ３１０に進む。ステップＳ３１０では、このようにして更新されたＩＰアドレスリストを対象として、先の処理と同様に、当該ＩＰアドレスリストを先頭から検索し、有効フラグの立っているＩＰアドレスで最初にヒットしたものを抽出する。
【００２４】
上述したように、本実施の形態においては、有効フラグを使用して未抽出・既抽出ＩＰアドレスの区別を比較的容易に行っていたが、本発明はこれに制限されるものではなく、他の方法によって区別することとしても良い。例えば、ステップＳ２００においてフラグフィールドをＩＰアドレスリストに設けずに（即ち、複数のＩＰアドレスのみで）構成する一方、ステップＳ３２０においてリソースの取得先サーバとならないと判断されたＩＰアドレスをステップＳ３３０においてＩＰアドレスリストから削除するようにして更新することとしても良い。この場合、ステップＳ３１０においては、例えば、常にＩＰアドレスリストの先頭のＩＰアドレスを抽出して、ステップＳ３２０に進めばよい。なお、仮に当初のＩＰアドレスリストに含まれるすべてのＩＰアドレスについてチェックし終えたとすると、ステップＳ３３０を通過した後のＩＰアドレスリストにはＩＰアドレスが全く含まれていないこととなるので、その場合は、ＩＰアドレスの抽出に失敗したとしてステップＳ５００に進みエラー処理を行うこととなる（ステップＳ３１０）。
【００２５】
図５を参照すると、図４におけるステップＳ３２０に示されるリソース取得可能性の判断処理についての具体的な内容が示されている。
【００２６】
即ち、本実施の形態においては、まず、ステップＳ３１０において抽出したＩＰアドレスで指定されるサーバに対して接続を試みる。しかし、その結果、予め定められた時間（「接続可否判断時間」という）を経過しても当該サーバへの接続を完了できなかった場合には、ステップＳ３３０に進み、ＩＰアドレスリストに対して上述したような更新処理を行う。
【００２７】
一方、ステップＳ３２２において対象となっていたサーバに接続できた場合には、そのサーバに対してリソースの要求を行う（ステップＳ３２４）。
【００２８】
本実施の形態におけるプログラムは、サーバとの間でＨＴＴＰに従った会話を行うものであり、リソースの要求はＨＴＴＰに従って行われる。ＨＴＴＰに従ってリソースのリクエストを行うと、一般に、当該リクエストに対するレスポンスとしてヘッダ情報及びボディ（ここに所望としているリソースが含まれる）が返されてくる。このうち、ヘッダ情報はサイズが小さくかつアクセスごとにそれほど大小がないので、例えば回線速度が遅い場合などでも、サーバへのアクセスが混んでなければ、ある程度の時間の範囲で処理が完了することが期待できる。そこで、本実施の形態においては、ヘッダ情報のみを先読みすることとし、その先読みに要する時間をサーバが混んでいるか否かの指標として使用することする。
【００２９】
即ち、本実施の形態においては、サーバに対してリソース要求がなされた後（ステップＳ３２４）、予め定められた時間（「ヘッダ読込可否判断時間」という）内にヘッダ情報を読み込めたか否かを判断し（ステップＳ３２６）、その結果もリソース取得可能か否かの判断に利用している。もしステップＳ３２６においてヘッダ情報を先行して読み込めなかった場合、ステップＳ３３０に進み、ＩＰアドレスリストに対して前述したような更新処理を行う。このように、ＨＴＴＰヘッダの読込時間を取得先サーバの特定の材料の一つに用いていることから、アクセスの集中しているサーバへのリクエストを回避することができる。
【図面の簡単な説明】
【００３０】
【図１】本発明の実施の形態による装置構成を示す図である。
【図２】本発明の実施の形態によるリソース取得方法の概略を示すフローチャートである。
【図３】図２に示されるステップＳ２００の詳細を示すフローチャートである。
【図４】図２に示されるステップＳ３００の詳細を示すフローチャートである。
【図５】図４に示されるステップＳ３２０の詳細を示すフローチャートである。
【符号の説明】
【００３１】
１００        クライアント端末
１０        ＣＰＵ
２０        主記憶
３０        補助記憶
４０        送受信部
２００        インターネット
３００        ＤＮＳサーバ
４００        サーバ
４１０        サーバ
４２０        サーバ
【図１】
2008010919.tif 000003
【図２】
2008010919.tif 000004
【図３】
2008010919.tif 000005
【図４】
2008010919.tif 000006
【図５】
2008010919.tif 000007