JP4040292B2 - サーバ選択方法、サーバ選択装置、サーバ選択プログラム、および、記録媒体 - Google Patents
サーバ選択方法、サーバ選択装置、サーバ選択プログラム、および、記録媒体 Download PDFInfo
- Publication number
- JP4040292B2 JP4040292B2 JP2001366538A JP2001366538A JP4040292B2 JP 4040292 B2 JP4040292 B2 JP 4040292B2 JP 2001366538 A JP2001366538 A JP 2001366538A JP 2001366538 A JP2001366538 A JP 2001366538A JP 4040292 B2 JP4040292 B2 JP 4040292B2
- Authority
- JP
- Japan
- Prior art keywords
- server
- client
- server selection
- information
- access
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Lifetime
Links
Images
Description
【０００１】
【発明の属する技術分野】
本発明は、サーバ選択方法、サーバ選択装置、サーバ選択プログラム、および、記録媒体に係わり、特に、分散サーバの中からクライアントにアクセスさせるのに適切なサーバを選択する際に、クライアントの位置及びサーバの設置位置に基づき、選択候補とするサーバのリストを生成する技術に関する。
【０００２】
【従来の技術】
近年のインターネットトラヒック増大に伴い、１台のサーバにアクセスするクライアントが増大し、アクセス集中によって安定したサービスの提供が困難となっている。
このような問題を解決するため、同じサービスを提供する複数台のサーバを用意し、クライアントのアクセスをそれらのサーバに分散することで負荷分散を実施しようとする負荷分散方法が数多く考案され、この方法を実現するサーバ選択装置もさまざまな種類のものが発明、実用化されている。
通常のサーバ選択装置は、利用者の識別情報とサーバリストを入力とし、選択されたサーバの識別情報を出力とする。
一般的には、サーバリストに記載のすべてのサーバについて、サーバ負荷、サーバ−クライアント間の距離などのメトリックを測定し、これに基づき最適なサーバを選択する方式が用いられる。
また、近年では、前述したサーバ選択装置とキャッシュサーバ、ミラーサーバを用いたＣＤＮ（Content Delivery Network）に注目が集まり、サービスが開始され始めている。
ＣＤＮとは、ネットワーク内部にキャッシュサーバやミラーサーバ（以下、ＣＤＮサーバと称する。）を分散配置し、サーバ選択装置によって、クライアントに最寄りのキャッシュサーバや、ミラーサーバにアクセスさせることで、高品質なサービスを提供しようとする仕組みである。
前述したＣＤＮは、専用のネットワークを持たなくても実現できるため、複数のネットワーク運営者によって管理されているネットワーク上にＣＤＮサーバを配置してサービスを提供することが可能である。
【０００３】
【発明が解決しようとする課題】
複数のネットワーク運営者が管理する複数のネットワーク上にＣＤＮサーバを配置し、コンテンツ配信サービスを提供することを考える。
ネットワーク運営者がＣＤＮサーバを自ネットワーク内に配置する目的は、（１）自ネットワークに属するユーザの利便性向上、（２）自ネットワークに属するユーザによる外部ネットワークへ向けたトラヒック低減などが考えられる。
このようなＣＤＮサーバを配置する一方で、ネットワーク運営者は自ネットワークのクライアントや回線を保護するために、独自にＣＤＮサーバに対するサーバ利用ポリシを定めることが多いと考えられる。
例えば、ネットワーク運営者は、自ネットワーク上に配置したＣＤＮサーバに他ネットワークに属するユーザをアクセスさせないようなアクセスポリシを設定するかも知れない。
その理由は、このアクセスポリシによって、他ネットワークに属するユーザのアクセスによる回線負荷、サーバ負荷の増加を抑制できると期待しているからである。
【０００４】
一方で、自ネットワーク上のＣＤＮサーバに障害が発生した場合は、外部ネットワーク上に配置されたＣＤＮサーバに、自ネットワークのクライアントをアクセスさせることを望むかもしれない。
また、あるネットワーク運営者は、非常に複雑なＣＤＮサーバ利用ポリシ、あるいは、そのネットワーク運営者が外部に漏洩してはならない情報に基づいて、ＣＤＮサーバ利用ポリシを設定するかもしれない。
例えば、顧客の契約形態に応じてサーバを選択する場合などがこれに相当する。
このような場合、ＣＤＮサービスで共通に用いられるサーバ選択装置では、サーバ選択処理が行えないため、サーバ選択処理を該ネットワーク運営者が配置するサーバ選択装置に委譲しなければならない。
さらには、ＣＤＮ事業者側の観点からは、ＣＤＮサーバを配置していないネットワーク上のクライアントからのＣＤＮサーバヘのアクセスを拒むケースも考えられる。
これは、ＣＤＮサーバを数多く配置するための戦略であったり、未知のネットワークからのアクセスによって著作権保護が困難になることを防くためと考えられる。
【０００５】
このような各ネットワーク運営者が設定するＣＤＮサーバ利用ポリシ、ＣＤＮ事業者が設定するサーバ選択装置に対するアクセスポリシなどを、ＣＤＮサービスを提供するサーバ選択装置はすべて満たさなければならない。
前述したような、ＣＤＮを実現するサーバ選択装置に求められる課題は、下記の２通りに分類できる。
（課題１）クライアントの属性情報に応じて、選択候補とするサーバをサーバ選択処理の前に絞り込む機能を実現する。
（課題２）クライアントの属性情報に応じて、他のサーバ選択装置に処理を委譲する、あるいは、サーバ選択処理そのものを行わないことを判断する機能を実現する。
しかしながら、従来のいかなるサーバ選択装置においても、これらの課題を実現する機能を有していなかった。
したがって、前述のＣＤＮサービスを提供する場合のサーバ選択装置としては不十分であり、ＣＤＮサービス展開の阻害要因となっている。
【０００６】
本発明は、前記従来技術の問題点を解決するためになされたものであり、本発明の目的は、サーバ選択方法及びサーバ選択装置において、クライアント属性に基づき、選択候補サーバを絞り込む、あるいはサーバ選択の受付可否判断、他のサーバ選択サーバヘサーバ選択処理を委譲することを判断することが可能となる技術を提供することにある。
また、本発明の他の目的は、前述のサーバ選択方法をコンピュータに実行させるサーバ選択プログラムを記録する記録媒体を提供することにある。
また、本発明の他の目的は、前述のサーバ選択プログラムを記録した記録媒体を提供することにある。
本発明の前記ならびにその他の目的と新規な特徴は、本明細書の記述及び添付図面によって明らかにする。
【０００７】
【課題を解決するための手段】
本願において開示される発明のうち、代表的なものの概要を簡単に説明すれば、下記の通りである。
本発明の参考例のサーバ選択装置の概略構成を図１に示す。
図１に示すサーバ選択装置は、サービス識別情報（ＩＰ（Internet Protocol）アドレス、ホスト名、ＵＲＬ（Uniform Resource Locators）など）と、そのサービスを提供可能な複数のサーバの識別情報（ＩＰアドレス、ホスト名、ＵＲＬなど）および位置情報（ＩＰアドレスの領域などで示される）との対応関係について記述したサーバリストテーブル２１と、サーバの位置情報と、当該位置情報を持つサーバにアクセスしても良いクライアントの位置情報（ＩＰアドレスの領域などで示される）、あるいは、アクセスしてはならないクライアントの位置情報（ＩＰアドレスの領域などで示される）との対応関係について記述したアドミッションコントロールリストテーブル２２とを備える。
図１に示すサーバ選択装置では、サーバ選択要求情報受信手段１で、クライアント属性情報及びサービス識別情報を含むサーバ選択要求情報を受信した後、サーバリスト取得手段２で、前記サーバ選択要求情報に含まれるサービス識別情報に基づき前記サーバリストテーブル２１を参照し、前記サービス識別情報に対応したサーバと当該サーバの位置情報のリストを取得し、サーバ選択処理候補絞り込み手段３で、前記取得したサーバの各々について、前記アドミッションコントロールリストテーブル２２を参照し、前記クライアントの位置情報および前記サーバの位置情報に基づき、当該サーバに当該クライアントをアクセスさせて良いか否か判定し、アクセスさせて良いサーバのみをサーバ選択候補とし、サーバ選択手段５で、前記絞り込まれたサーバ選択候補の中からクライアントにアクセスさせるサーバを選択するので、クライアントの位置情報に応じて選択候補とするサーバをサーバ選択処理の前に絞り込むことが可能となる。
【０００８】
本発明のサーバ選択装置の一例の概略構成を図２に示す。
図２に示すサーバ選択装置では、サービス識別情報と、そのサービスを提供可能な複数のサーバの識別情報および位置情報との対応関係について記述したサーバリストテーブル２１と、クライアントの位置情報と、当該位置情報を持つクライアントに対しサーバ選択処理を継続するか中断するか、あるいは、他のサーバ選択装置に処理を委譲するかをサービス識別情報毎に指定したアドミッションコントロールリストテーブル２２を備える。アドミッションコントロールリストテーブル２２は、回線の細いネットワークに接続している拠点に属するクライアントからサーバへのアクセスを禁止し、または、多くのサーバを有する拠点に属するクライアントから他の拠点のサーバへのアクセスを禁止し、あるいは、サーバが無いか少ない拠点に属するクライアントから、自拠点から１リンクでたどり着け、かつ、そのリンクの帯域が最も大きい拠点のサーバへのアクセスを許可するというアクセスポリシに基づき記述される。
図２に示すサーバ選択装置では、サーバ選択要求情報受信手段１で、クライアント位置情報及びサービス識別情報を含むサーバ選択要求情報を受信した後、サーバ選択処理受付可否判断手段６で、前記サーバ選択要求情報に含まれるクライアント位置情報、およびサービス識別情報に基づき、前記アドミッションコントロールリストを参照し、当該クライアントに対する処理を判断し、前記サーバ選択処理受付可否判断手段において、サーバ選択処理を継続すると判断された場合、サーバリスト取得手段２で、前記サービス識別情報に基づき、前記サーバリストを参照し、前記サービス識別情報に対応したサーバ識別情報のリストを取得し、サーバ選択手段５で、前記サーバ識別情報のリストに記載のサーバの中から前記クライアントにアクセスさせるサーバを選択する。
また、前記サーバ選択処理受付可否判断手段において、サーバ選択処理を中断すると判断された場合、あるいは、サーバ選択処理を他のサーバ選択装置に委譲すると判断された場合、サーバ選択結果情報通知手段で、クライアントに対しサーバ選択処理を中断したことを示すサーバ選択結果情報、あるいは、前記クライアントに対し他のサーバ選択装置にアクセスするよう促すサーバ選択結果情報を通知するようにしたので、クライアントの属性情報に応じて他のサーバ選択装置に処理を委譲する、あるいはサーバ選択処理そのものを行わないことを判断する機能を実現することが可能となる。
【０００９】
また、本発明のサーバ選択装置は、サービス識別情報と、当該サービスを提供する複数のサーバの識別情報および位置情報との対応関係について記述したサーバリストテーブルと、サーバの位置情報と、当該位置情報を持つサーバに対してアクセスしても良いクライアントの位置情報、あるいはアクセスしてはならないクライアントの位置情報との対応関係について記述した第１のアドミッションコントロールリストテーブルと、クライアントの位置情報と、該位置情報を持つクライアントに対して、サーバ選択処理を継続するか否か、あるいは、他のサーバ選択装置に処理を委譲するかを、サービス識別情報毎に指定した第２のアドミッションコントロールリストテーブルとを備える。
第１及び第２のアドミッションコントロールリストテーブルは、回線の細いネットワークに接続している拠点に属するクライアントからサーバへのアクセスを禁止し、または、多くのサーバを有する拠点に属するクライアントから他の拠点のサーバへのアクセスを禁止し、あるいは、サーバが無いか少ない拠点に属するクライアントから、自拠点から１リンクでたどり着け、かつ、そのリンクの帯域が最も大きい拠点のサーバへのアクセスを許可するというアクセスポリシに基づき記述される。
本発明のサーバ選択装置では、サーバ選択要求情報受信手段で、クライアント位置情報、およびサービス識別情報を含むサーバ選択要求情報を受信した後、サーバ選択処理受付可否判断手段で、前記サーバ選択要求情報に含まれるクライアント位置情報およびサービス識別情報に基づき、前記第２のアドミッションコントロールリストテーブルを参照し、当該クライアントに対する処理を判断し、前記サーバ選択処理受付可否判断手段において、サーバ選択処理を継続すると判断された場合、サーバリスト取得手段で、前記サーバ選択要求情報に含まれるサービス識別情報に基づき、前記サーバリストテーブルを参照し、前記サービス識別情報に対応した位置情報を持つサーバを取得し、サーバ選択処理候補絞り込み手段で、前記取得されたサーバの各々について、前記第１のアドミッションコントロールリストテーブルを参照し、前記クライアント位置情報および前記サーバ位置情報に基づき、当該サーバに当該クライアントをアクセスさせて良いか否か判定し、アクセスさせて良いサーバのみをサーバ選択候補とした後、サーバ選択手段で、前記絞り込まれた前記サーバ選択候補の中からクライアントにアクセスさせるサーバを選択する。
また、前記サーバ選択処理受付可否判断手段において、サーバ選択処理を中断すると判断された場合、あるいは、サーバ選択処理を他のサーバ選択装置に委譲すると判断された場合、サーバ選択結果情報通知手段で、クライアントに対しサーバ選択処理を中断したことを示すサーバ選択結果情報、あるいは、前記クライアントに対し他のサーバ選択装置にアクセスするよう促すサーバ選択結果情報を通知するようにしたので、サーバ選択装置に対する想定したアクセスポリシを守ることが可能となる。
【００１０】
【発明の実施の形態】
以下、図面を参照して本発明の実施の形態を詳細に説明する。
なお、実施の形態を説明するための全図において、同一機能を有するものは同一符号を付け、その繰り返しの説明は省略する。
また、すべての実施の形態において、サーバ選択装置、サーバ、クライアントは、すべて汎用コンピュータ上のソフトウェアで実現されるものとする。
さらに、ネットワークはＩＰネットワークとし、サーバ選択装置、サーバ、クライアントはすべてＩＰネットワーク上で通信可能な機器であるとする。
［実施の形態１］
図３は、本発明の実施の形態１のＤＮＳ（Domain Name System）サーバの概略構成を示すブロック図である。
本実施の形態において、サーバ選択装置はＤＮＳサーバとして動作するものとする。即ち、ホスト名を表す文字列が入力され、その文字列に対応するＩＰアドレスを出力する機能を有するものである。
なお、通常のＤＮＳでは、一つのホスト名に対し一つのＩＰアドレスが対応しているが、本実施の形態におけるＤＮＳは、一つのホスト名に対し複数のＩＰアドレスが対応づけられ、同じホスト名に対する名前解決を要求した場合でもクライアントの位置に応じて返されるＩＰアドレスが異なるものとする。
図３に示すように、本実施の形態のＤＮＳサーバは、サーバリストテーブル２１と、アドミッションコントロールリストテーブル２２、位置リストテーブル２３と、ＤＮＳクエリ受信部１０と、サーバリスト取得部１１、サーバ選択処理絞り込み取得部１２と、サーバ選択部１３と、ＤＮＳレスポンス送信部１５とで構成される。
【００１１】
図４は、図３に示すサーバリストテーブル２１の一例を示す図である。
サーバリストテーブル２１は、ホスト名（本発明のサービス識別情報）と、そのホスト名に対応する複数のサーバのＩＰアドレス（本発明のサーバ識別情報）、およびサーバの位置を示す文字列（本発明のサーバ属性情報）が格納される。
図５は、図３に示すアドミッションコントロールリストテーブル２２の一例を示す図である。
アドミッションコントロールリストテーブル２２は、ある位置に存在するサーバに対する、ある位置に存在するクライアントのアクセス可否について記述されたリストである。
アドミッションコントロールリストテーブル２２の情報要素は、ホスト名、処理内容（アクセスさせるか否か）、サーバの位置（本発明のサーバ属性情報）、クライアントの位置（本発明のクライアント属性情報）である。
あるサーバの位置とクライアントの位置の組における処理内容にａｌｌｏｗと記載された場合、該サーバの位置に存在するサーバに対し、該クライアントの位置に存在するクライアントによるアクセスを許可する。
また、あるサーバの位置とクライアントの位置の組における処理内容にｄｅｎｙと記載された場合、該サーバの位置に存在するサーバに対し該クライアントの位置に存在するクライアントによるアクセスを許可しない。
また、サーバ、クライアントの位置に「＊」印が記される場合は「すべての位置」を意味するものとする。
【００１２】
あるサーバの位置、およびクライアントの位置の組が与えられた時、当リストの先頭から検索し、初めに合致した組における処理内容を実行する。
また、各ホスト名毎のリストの末尾には、明示されないが処理内容がｄｅｎｙ、サーバの位置が「＊」、クライアントの位置が「＊」である組が記載されているものと見なす。
図６は、図３に示す位置リストテーブル２３の一例を示す図である。
位置リストテーブル２３は、位置名と、その位置に存在する装置のアドレス帯との対応表である。
アドレス帯の記述方法は（ＩＰアドレス）／（ビットマスク）であるとする。
例えば、１００．００．０／８と記載される場合、ＩＰアドレスを３２ｂｉｔの二進数に展開した時の、上位８ビットが位置を識別する部分であることを意味する。
それ以外のビットは、どのような値でも当該位置に属するものとする。
例えば、図６において、１００．１．２．３という装置も、１００．２５４．２５４．２３３という装置も等しくＴＯＫＹＯという位置に存在することを意味する。
【００１３】
次に、図３に記載の各処理部について説明する。
ＤＮＳクエリ受信部１０は、ＤＮＳプロトコルに基づき、リクエストされたホスト名と、リクエストしたクライアントのＩＰアドレスを取得する。
サーバリスト取得部１１では、ＤＮＳクエリ受信部１０で受信したホスト名に対応するサーバのＩＰアドレスと、サーバの位置リストをサーバリストテーブル２１から取得する。
サーバ選択処理絞り込み取得部１２のシーケンスを図７に示す。
始めに、ＤＮＳクエリ受信部１０で受信したクライアントのＩＰアドレスから位置リストテーブル２３を用い、クライアントの位置を特定する（ステップ１０１）。
次に、アドミッションコントロールリストテーブル２２の中で前記ホスト名に関する部分を参照し、サーバリスト取得部１１で取得したサーバのＩＰアドレスとサーバの位置リストに記載のすべてのサーバについて、サーバの位置とクライアントの位置とからアクセス可否判断を行う（ステップ１０２、ステップ１０３）。
次に、アクセス可とされたサーバを、選択候補サーバとする（ステップ１０４）。
サーバ選択部１３では、前記サーバ選択処理絞り込み取得部１２のアクセス可否判断において、アクセス可とされたサーバを選択対象サーバとし、その中から当該クライアントにアクセスさせるサーバを選択する。
ＤＮＳレスポンス送信部１５では、ＤＮＳプロトコルに基づき、前記サーバ選択部１３で選択されたサーバのＩＰアドレスをクライアントに送信する。
【００１４】
以上示してきた構成をもつＤＮＳサーバの動作例について以下に示す。
初めに、ＤＮＳクエリ受信部１０で、クライアント（ＩＰアドレス２００．１．２．３）からのホスト名ｓｅｒｖｅｒ２．ｃｏｍに対するＤＮＳ解決要求を受信する。
サーバリスト取得部１１では、ｓｅｒｖｅｒ２．ｃｏｍに対応するサーバのＩＰアドレスおよび位置名を取得する。
サーバリストテーブル２１を図４に記載したものと仮定すると、図８に示すリストが取得できたサーバリストとなる。以下、本実施の形態において、サーバリストとは図８のリストを指すものとする。
次に、サーバ選択処理絞り込みを実施する。
クライアントのＩＰアドレスが２００．１．２．３であり、図６に示す位置リストテーブル２３から上位８ビットが２００である装置は、すべてＯＳＡＫＡという位置に存在するものとしていることから、当該クライアントの位置名もＯＳＡＫＡと判断される。
次に、ホスト名ｓｅｒｖｅｒ２．ｃｏｍに対応するアドミッションコントロールリストテーブル２２を取得する。
アドミッションコントロールリストテーブル２２が図５に示すものとすると、図９に示すリストが取得できたアドミッションコントロールリストとなる。
以下、本実施の形態において、アドミッションコントロールリストとは図９に示すリストを指すものとする。
【００１５】
次に、図８に示すサーバリストに記載のサーバすべてについて、図９に示すアドミッションコントロールリストを参照しながらサーバ選択候補とするかどうか決定する。
ＩＰアドレス１００．２０．１．１０であるサーバは、ＴＯＫＹＯという位置に存在する。一方、クライアントは、ＯＳＡＫＡという位置に存在する。
図９に示すアドミッションコントロールリストによれば、上一行目にサーバの位置＝ＴＯＫＹＯ、クライアントの位置＝＊（何でも良い）、また、この場合の処理内容はａｌｌｏｗと記されている。
この上一行目の記述が当該サーバに当てはまり、処理内容がａｌｌｏｗであることから当サーバは選択候補となる。
次に、ＩＰアドレス２００．２０．５．１０のサーバはＯＳＡＫＡという位置に存在する。クライアントは、同じくＯＳＡＫＡという位置に存在する。
図９に示すアドミッションコントロールリストによれば、上２行目にサーバの位置＝ＯＳＡＫＡ、クライアントの位置＝ＯＳＡＫＡ、また、この場合の処理内容はａｌｌｏｗと記されている。
これが当該サーバに当てはまり、処理内容がａｌｌｏｗであることから当サーバは選択候補となる。
【００１６】
次に、ＩＰアドレス２２５．２０．５．１０のサーバは、ＨＩＲＯＳＨＩＭＡという位置に存在する。クライアントは、同じくＯＳＡＫＡという位置に存在する。
図９に示すアドミッションコントロールリストによれば、上３行目にサーバの位置＝ＨＩＲＯＳＨＩＭＡ、クライアントの位置＝ＨＩＲＯＳＨＩＭＡ、また、この場合の処理内容はａｌｌｏｗと記されている。しかし、これは当該サーバには当てはまらない。
その他に、サーバの位置＝ＨＩＲＯＳＨＩＭＡ、あるいは＊（何でも良い）とする記述が、図９に示すアドミッションコントロールリスト内に存在しない。
従って、当該サーバについては、明示されていないサーバの位置＝＊（何でも良い）、クライアントの位置＝＊（何でも良い）が適用され、この時の処理内容はｄｅｎｙであることから、サーバ選択候補としては扱わない。
従って、この場合サーバ選択候補としては、ＩＰアドレス１００．２０．１．１０．２００．２０．５．１０であるサーバが取得できる。サーバ選択部１３では、この２つのサーバの中から適切なサーバを１つ選択する。
選択のポリシとしてクライアントの位置と同じ位置にあるサーバを優先的に選択するものとする。
クライアントの位置は、ＯＳＡＫＡであるから、同じＯＳＡＫＡに属するサーバ２００．２０．５．１０が優先的に選択され、ＤＮＳレスポンス送信部１５からクライアントに送信される。
【００１７】
前述の説明では、ＤＮＳサーバに本発明を適用した実施の形態について説明したが、ユーザがリクエストするＵＲＬに基づいて、サーバ選択を行うＵＲＬベースサーバ選択装置にも本発明を適用することが可能である。
ここでは、ｈｔｔｐによって受信したコンテンツ取得要求に基づき、コンテンツを提供するサーバに該要求を転送するｈｔｔｐリダイレクタに本発明を適用する例について述べる。
ＤＮＳの時と異なる点は、以下の通りである。
（１）サーバリストテーブル２１に記載されるホスト名、およびサーバのＩＰアドレスをＵＲＬに変更する。
（２）アドミッションコントロールリストテーブル２２に記載されるホスト名をＵＲＬに変更する。
（３）ＤＮＳクエリ受信部１０を、ｈｔｔｐリクエスト受信部に変更する。
（４）ＤＮＳレスポンス送信部１５を、ｈｔｔｐリダイレクトメッセージ送信部に変更する。
【００１８】
変更されたコンポーネントの説明を下記に示す。
変更後のサーバリストテーブル２１の一例を図１０に示す。
ここで、代表ＵＲＬとは、クライアントが、初めに当ｈｔｔｐリダイレクタにアクセスする際のＵＲＬであり、サーバのＵＲＬとは実際のコンテンツを提供するサーバ群のＵＲＬであるものとする。
変更後のアドミッションコントロールリストテーブル２２の一例を図１１に示す。
ｈｔｔｐリクエスト受信部は、ｈｔｔｐのＧＥＴメッセージを受信し、そこから代表ＵＲＬとクライアントのＩＰアドレスを取得する。
ｈｔｔｐリダイレクトメッセージ送信部は、ｈｔｔｐのリダイレクト（転送）メッセージを図１２に示すフォーマットで送信する。
以上の変更を加えることで、本発明をＵＲＬベースサーバ選択装置に適用することも可能となる。
前述の実施の形態により、ユーザの位置に基づき選択対象サーバを絞り込むことが可能となる。
【００１９】
［実施の形態２］
図１３は、本発明の実施の形態２のＤＮＳ（Domain Name System）サーバの概略構成を示すブロック図である。
本実施の形態においても、サーバ選択装置はＤＮＳサーバとして動作するものとする。即ち、ホスト名を表す文字列が入力され、その文字列に対応するＩＰアドレスを出力する機能を有するものである。
なお、通常のＤＮＳでは一つのホスト名に対し一つのＩＰアドレスが対応しているが、本実施の形態におけるＤＮＳは、一つのホスト名に対し複数のＩＰアドレスが対応づけられ、同じホスト名に対する名前解決を要求した場合でもクライアントの位置に応じて返されるＩＰアドレスが異なるものとする。
図１３に示すように、本実施の形態のＤＮＳサーバは、サーバリストテーブル２１と、アドミッションコントロールリストテーブル２２、位置リストテーブル２３と、ＤＮＳクエリ受信部１０と、サーバリスト取得部１１、サーバ選択処理受付可否判断部１６と、サーバ選択部１３と、ＤＮＳレスポンス送信部１５とで構成される。
なお、本実施の形態において、ＤＮＳサーバには、３種類のリストテーブルが既に記憶されているものとする。ここで、サーバリストテーブル２１、および位置リストテーブル２３は、前述の実施の形態１の場合と同じとする。
【００２０】
図１４は、図１３に示すアドミッションコントロールリストテーブル２２の一例を示す図である。
アドミッションコントロールリストテーブル２２は、ある位置に存在するクライアントに対しサーバ選択処理を行うか否か、処理を他のサーバ選択装置に委譲するかが記述される。
アドミッションコントロールリストテーブル２２の情報要素は、ホスト名、処理内容（サーバ選択処理を行うか否か、あるいは他のサーバ選択装置に処理を委譲するか）、クライアントの位置（本発明のクライアント属性情報）である。
あるクライアントの位置について処理内容がａｌｌｏｗであった場合、その位置に存在するクライアントに対してはサーバ選択処理を行うものとする。
また、処理内容がｄｅｎｙであった場合、その位置に存在するクライアントに対してはサーバ選択処理を行わないものとする。
また処理内容がａｌｌｏｗ、ｄｅｎｙ以外の文字列であった場合、その位置に存在するクライアントに対しては、その文字列を入力されたホスト名の別名として返すことで、その別名を解決するＤＮＳサーバにサーバ選択処理を委譲するものとする。
また、クライアントの位置に「＊」印が記される場合は「すべての位置」を意味するものとする。
また、各ホスト名毎のリストの末尾には、明示されないが処理内容がｄｅｎｙ、クライアントの位置が＊が記載されていると見なす。
【００２１】
次に、図１３に記載の各処理部について説明する。
ＤＮＳクエリ受信部１０は、実施の形態１と同様の処理を行う。
サーバ選択処理受付可否判断部１６では、初めに、ＤＮＳクエリ受信部１０で取得したクライアントのアドレスおよび位置リストテーブル２３を用いクライアントの位置名を取得する。
次に、ＤＮＳクエリ受信部１０で取得したホスト名と前記クライアント位置名とからアドミッションコントロールリストテーブル２２を参照し、サーバ選択処理の受付可否判断を実施する。
サーバリスト取得部１１は、実施の形態１と同様であるが、前記サーバ選択処理受付可否判断部１６でサーバ選択処理を実行することになった場合にのみ実行される点が異なる。
サーバ選択部１３は、サーバリスト取得部１１によって取得されたサーバリストに記載のサーバの中からクライアントにアクセスさせるサーバを選択する。
ＤＮＳレスポンス送信部１５は、サーバ選択処理受付可否判断部１６における判断内容によって処理が異なる。
サーバ選択処理受付可否判断部１６において、サーバ選択処理を行うと判断された場合、サーバ選択部１３によって選択されたサーバをＤＮＳのレスポンスとしてクライアントに返す。
また、サーバ選択処理受付可否判断部１６において、サーバ選択処理を行わないと判断された場合、ホスト名に対応するＩＰアドレスが存在しない旨を通知するＤＮＳレスポンスメッセージをクライアントに返す。
さらに、サーバ選択処理受付可否判断部１６において、他のＤＮＳサーバに処理を委譲すると判断された場合、アドミッションコントロールリストテーブル２２に記載の委譲先のホスト名が、ＤＮＳクエリ受信部１０で取得したホスト名の別名である旨を示すＤＮＳレスポンスメッセージをクライアントに返す。
【００２２】
以上示してきた構成をもつＤＮＳサーバの動作例について説明する。
いくつかのクライアント（クライアントＡ（ＩＰアドレス：１００．５０．３．２２）、クライアントＢ（ＩＰアドレス：２００．１．２．３）、クライアントＣ（ＩＰアドレス：２２５．２０．１．２）が、ＤＮＳサーバにホスト名ｓｅｒｖｅｒ１．ｃｏｍに対するＤＮＳ解決要求を行ったものとする。
初めに、ＤＮＳクエリ受信部１０でこれらのクライアントからのＤＮＳ解決要求を受信する。
サーバ選択処理受付可否判断部１６において、先ず、クライアントのＩＰアドレスからクライアントの位置名を取得する。
図１３に示す位置リストテーブル２３が図６に示すものであると仮定すると、上位８ビットが１００である装置はすべてＴＯＫＹＯ、上位８ビットが２００である装置はすべてＯＳＡＫＡ、上位１６ビットが２２５．２０である装置はすべてＨＩＲＯＳＨＩＭＡという位置に存在することになる。
したがって、クライアントＡの位置名はＴＯＫＹＯ、クライアントＢの位置名はＯＳＡＫＡ、クライアントＣの位置名はＨＩＲＯＳＨＩＭＡとそれぞれ判断される。
次に、ホスト名ｓｅｒｖｅｒ１．ｃｏｍに対応するアドミッションコントロールリストテーブル２２を取得する。
図１３に示すアドミッションコントロールリストテーブル２２が、図１４に示すものであると仮定すると、図１５が取得できたアドミッションコントロールリストとなる。以下、本実施の形態において、アドミッションコントロールリストとは、図１５に示すリストを指すものとする。
【００２３】
次に、これらのクライアントすべてについて、図１５に示すアドミッションコントロールリストを参照しながら、サーバ選択処理受付可否判断を行う。
クライアントＡの位置名はＴＯＫＹＯであるため、図１５に示すアドミッションコントロールリストから処理内容がａｌｌｏｗであり、サーバ選択処理を継続すると判断する。
クライアントＢの位置名はＯＳＡＫＡであるため、図１５に示すアドミッションコントロールリストに記載されるホスト名ｓｅｒｖｅｒ１００．ｃｏｍを別名として返すことで、この別名を解決するＤＮＳサーバにサーバ選択処理を委譲すると判断する。
クライアントＣの位置名はＨＩＲＯＳＨＩＭＡであるため、図１５に示すアドミッションコントロールリストから処理内容がｄｅｎｙであり、サーバ選択処理を行わないと判断する。
以上を受けクライアントＡについてはサーバリストを取得し、サーバ選択を実施、サーバ選択結果をＤＮＳレスポンス送信部１５を介して送信する。
クライアントＢについては、ｓｅｒｖｅｒ１００．ｃｏｍがｓｅｒｖｅｒ１．ｃｏｍの別名であるとしてＤＮＳレスポンス送信部１５を介して送信する。
クライアントＣについては、該当するＩＰアドレスが存在しなかったものとしてＤＮＳレスポンス送信部１５を介して送信する。
【００２４】
前述の説明では、ＤＮＳサーバに本発明を適用した実施の形態について説明したが、ユーザがリクエストするＵＲＬに基づいてサーバ選択を行うＵＲＬベースサーバ選択装置にも本発明を適用することが可能である。
ここでは、ｈｔｔｐによって受信したコンテンツ取得要求に基づき、コンテンツを提供するサーバに該要求を転送するｈｔｔｐリダイレクタに本発明を適用する例について述べる。
ＤＮＳの時と異なる点は、以下の通りである。
（１）サーバリストテーブル２１に記載されるホスト名、およびサーバのＩＰアドレスをＵＲＬに変更する。
（２）アドミッションコントロールリストテーブル２２に記載されるホスト名をＵＲＬに変更する。
（３）ＤＮＳクエリ受信部１０を、ｈｔｔｐリクエスト受信部に変更する。
（４）ＤＮＳレスポンス送信部１５を、ｈｔｔｐリダイレクトメッセージ送信部に変更する。
変更されたコンポーネントの説明を下記に示す。
変更後のサーバリストテーブル２１の例は、前述の図１０に示すものと同じであり、前述の実施の形態１の時と同様である。
変更後のアドミッションコントロールリストテーブル２２の一例を図１６に示す。
【００２５】
ｈｔｔｐリクエスト受信部は、前述の実施の形態１の場合と同様である。
ｈｔｔｐリダイレクトメッセージ送信部は、サーバ選択処理受付可否判断部１６における判断内容によって処理が異なる。
サーバ選択処理受付可否判断部１６において、サーバ選択処理を行うと判断された場合、サーバ選択部１３によって選択されたサーバを図１２に示すｈｔｔｐのリダイレクトメッセージとしてクライアントに返す。
サーバ選択処理受付可否判断部１６においてサーバ選択処理を行わないと判断された場合、図１７に示す要求されたＵＲＬが存在しない旨を通知するｈｔｔｐｐのレスポンスメッセージをクライアントに返す。
サーバ選択処理受付可否判断部１６において、他のｈｔｔｐリダイレクタに処理を委譲すると判断された場合、アドミッションコントロールリストに記載の委譲先のホスト名を図１２に示すｈｔｔｐのリダイレクトメッセージとしてクライアントに返す。
以上の変更を加えることで、本発明をＵＲＬベースサーバ選択装置に適用することも可能となる。
以上説明したように、本実施の形態により、ユーザの位置に基づきサーバ選択処理の受付可否を判断することが可能となる
【００２６】
［実施の形態３］
図１８は、本発明の実施の形態３のサーバ選択装置が適用されるネットワーク構成を示すブロック図である。この図１８に示すネットワークは、広域なサーバ負荷分散システムを構成する。
図１８に示すネットワークでは、サーバやクライアントが存在し得る拠点は、ＴＯＫＹＯ、ＮＡＧＯＹＡ、ＯＳＡＫＡ、ＨＩＲＯＳＨＩＭＡ、ＳＥＡＴＬＥの５個所にあり、それぞれがルータ（Ｒ１〜Ｒ５）を介して接続されている。
また、系内には、サーバ選択装置として機能する、二つのＤＮＳサーバ（ＤＮＳ１，ＤＮＳ２）がＴＯＫＹＯ、ＯＳＡＫＡの両拠点に配備されている。
ＤＮＳサーバ（ＤＮＳ１）は、拠点ＴＯＫＹＯ、ＮＡＧＯＹＡ、ＳＥＡＴＬＥのクライアントやサーバにおけるローカルＤＮＳサーバとして動作する。
ＤＮＳサーバ（ＤＮＳ２）は、拠点ＯＳＡＫＡ、ＨＩＲＯＳＨＩＭＡのクライアントやサーバにおけるローカルＤＮＳサーバとして動作する。
また、ＴＯＫＹＯ、ＮＡＧＯＹＡ、ＯＳＡＫＡには、それぞれ３つ、１つ、２つのコンテンツ配信サーバ（Ｓ１−１，Ｓ１−２，Ｓ１−３，Ｓ２−１，Ｓ３−１，Ｓ３−２）が配置されているものとする。
【００２７】
ここで、それぞれのＤＮＳサーバ（ＤＮＳ１，ＤＮＳ２）のアクセスポリシを図１９に定義するものとする。
このアクセスポリシは、下記のような基本的な考え方に基づいて作成されている。
（１）回線の細いネットワークに接続している拠点に属するクライアントにはサーバにアクセスさせない。（ＳＥＡＴＬＥが相当）
（２）多くのサーバを有する拠点に属するクライアントは他の拠点のサーバにアクセスしてはならない。（ＴＯＲＹＯが相当）
（３）自拠点にサーバがないか少ない場合、自拠点から１リンクでたどり着け、かつ、そのリンクの帯域がもっとも大きい拠点のサーバにアクセスすることを許可する。（ＮＡＧＯＹＡ、ＯＳＡＫＡ、ＨＩＲＯＳＨＩＭＡが相当）
このようなアクセスポリシを設けることで、サービスを提供する領域を制限できたり、ネットワークトラヒックやサーバ負荷を低減することが可能となる。
【００２８】
このアクセスポリシを実現するためのＤＮＳサーバ（ＤＮＳ１，ＤＮＳ２）を用いたシーケンスを図２０に示す。
前提として、最初のサーバ選択は、ＤＮＳサーバ（ＤＮＳ１）にて実施するものとする。
まず、拠点ＴＯＫＹＯ、ＮＡＧＯＹＡ、ＳＥＡＴＬＥに属するクライアントのＤＮＳシーケンスについて説明する。
これらの拠点は、プライマリＤＮＳサーバとして、ＤＮＳサーバ（ＤＮＳ１）を使用しているため、クライアントからの名前解決要求を受信し（図２０のイ）、ＤＮＳサーバ（ＤＮＳ１）のサーバ選択処理１１０によってクライアントにアクセスさせるサーバのＩＰアドレスを決定しクライアントに返す（図２０のロ）。
次に、拠点ＯＳＡＫＡ、ＨＩＲＯＳＨＩＭＡに属するクライアントのＤＮＳシーケンスについて説明する。
これらの拠点は、プライマリＤＮＳとして、ＤＮＳサーバ（ＤＮＳ２）を使用しているため、クライアントからの名前解決要求を受信する（図２０のハ）と、この要求をＤＮＳサーバ（ＤＮＳ１）に転送する（図２０のニ）。
ＤＮＳサーバ（ＤＮＳ１）では、名前解決要求をＤＮＳサーバ（ＤＮＳ２）から受信するため、本当のクライアントのアドレスは認識できず、ＤＮＳサーバ（ＤＮＳ２）のアドレスをクライアントのアドレスと認識してしまう。
これでは、クライアントの位置によるサーバ選択が実施できないため、サーバ選択処理１１０で、サーバ選択処理をＤＮＳサーバ（ＤＮＳ２）に委譲し、再度ＤＮＳサーバ（ＤＮＳ２）でサーバ選択を実行できるよう、別のホスト名をＤＮＳサーバ（ＤＮＳ２）に渡す（図２０のホ）。
ＤＮＳサーバ（ＤＮＳ２）が、クライアントにこのホスト名を返すと（図２０のヘ）、クライアントは、再度このホスト名を解決するためのＤＮＳクエリメッセージをＤＮＳサーバ（ＤＮＳ２）に対し発行する（図２０のト）。
ＤＮＳサーバ（ＤＮＳ２）のサーバ選択処理１１１によってクライアントにアクセスさせるサーバのＩＰアドレスを決定しクライアントに返す（図２０のチ）。
【００２９】
このシーケンスを実現するため、ＤＮＳサーバ（ＤＮＳ１）には、前述の実施の形態１および実施の形態２に記載のサーバ選択機能を実装し、ＤＮＳサーバ（ＤＮＳ２）には、前述の実施の形態１に記載のサーバ選択機能を実装する。
ＤＮＳサーバ（ＤＮＳ１）、およびＤＮＳサーバ（ＤＮＳ２）は、ともに通常のＤＮＳサーバとしても動作する必要があるため、図２１に示すような構成をとる。
通常のＤＮＳサーバは、マスターファイル３３を参照することで名前解決が可能であるものとする。マスターファイル参照部３１において、名前が解決できない時のみ、サーバ選択処理部３５でサーバ選択を実施する。
このサーバ選択処理部３５でのサーバ選択は、ＤＮＳサーバ（ＤＮＳ１）ならば後述の図２２に示すＤＮＳサーバによるサーバ選択を、ＤＮＳサーバ（ＤＮＳ２）ならば実施の形態１に記載のサーバ選択装置を利用したサーバ選択を実施する。
図２２は、本発明の実施の形態のサーバ選択装置（即ち、ＤＮＳサーバ（ＤＮＳ１））の概略構成を示すブロック図である。
図２２に示すサーバ選択装置は、前述の実施の形態１のサーバ選択装置と、前述の実施の形態２のサーバ選択装置とをマージしたような構成となっている。
従って、個々の構成部分についての説明は省略するが、アドミッションコントロールリストテーブル１（２５）は、前述の実施の形態２のアドミッションコントロールリストテーブル２２であり、アドミッションコントロールリストテーブル２（２６）は、前述の実施の形態１のアドミッションコントロールリストテーブル２２であることを付け加えておく。
ここで、ＴＯＫＹＯ、ＮＡＧＯＹＡ、ＯＳＡＫＡ、ＨＩＲＯＳＨＩＭＡ、ＳＥＡＴＬＥの各拠点のサブネットアドレスを表１に示す。
また、ＴＯＫＹＯ、ＮＡＧＯＹＡ、ＯＳＡＫＡに存在する各サーバのＩＰアドレスを表２に示す。
【００３０】
【表１】
【００３１】
【表２】
【００３２】
以上を前提として、前述のアクセスポリシを実現するための設定方法について述べる。
初めに、ＤＮＳサーバ（ＤＮＳ１）の設定について説明する。
ＤＮＳサーバ（ＤＮＳ１）においては、サーバリストテーブル２１、アドミッションコントロールリストテーブル１（２５）、アドミッションコントロールリストテーブル２（２６）、および位置リストテーブル２３を設定する必要がある。
図２３は、ＤＮＳサーバ（ＤＮＳ１）のサーバリストテーブル２１の一例を示す図である。
図２４は、ＤＮＳサーバ（ＤＮＳ１）のアドミッションコントロールリストテーブル１（２５）の一例を示す図である。
図２５は、ＤＮＳサーバ（ＤＮＳ１）のアドミッションコントロールリストテーブル２（２６）の一例を示す図である。
図２６は、ＤＮＳサーバ（ＤＮＳ１）の位置リストテーブル２３の一例を示す図である。
上記のリスト中で、拠点ＨＩＲＯＳＨＩＭＡに関する記述を行ってない。
これは、以下の理由による。
【００３３】
図２０に示すＤＮＳサーバのシーケンスによれば、ＤＮＳサーバ（ＤＮＳ２）をローカルＤＮＳとしている拠点（ＯＳＡＫＡ、ＨＩＲＯＳＨＩＭＡ）に属するクライアントからの名前解決は、ＤＮＳサーバ（ＤＮＳ２）を経由して、ＤＮＳサーバ（ＤＮＳ１）にアクセスされ、その際、ＤＮＳサーバ（ＤＮＳ１）がクライアントのアドレスとして認識するのは、ＤＮＳサーバ（ＤＮＳ２）のアドレス（２００．１５０．１．１００）である。
表１によれば、ＤＮＳサーバ（ＤＮＳ２）は拠点ＯＳＡＫＡに属するため、ＯＳＡＫＡ、ＨＩＲＯＳＨＩＭＡどちらに属するクライアントからの名前解決要求もＤＮＳサーバ（ＤＮＳ１）から見ると、すべてＤＮＳサーバ（ＤＮＳ２）からの名前解決要求に見えるため、ＤＮＳサーバ（ＤＮＳ１）においてＨＩＲＯＳＨＩＭＡに関する設定は不要である。
また、図２３に示すサーバリストテーブル２１において、拠点ＯＳＡＫＡに属するサーバが記載されていないが、これはＤＮＳサーバ（ＤＮＳ１）をローカルＤＮＳとしている拠点（ＴＯＫＹＯ、ＮＡＧＯＹＡ、ＳＥＡＴＬＥ）に対して拠点ＯＳＡＫＡに存在するサーバを選択することが、アクセスポリシ上有り得ないため省略している。
【００３４】
続いて、ＤＮＳサーバ（ＤＮＳ２）の設定について説明する。
ＤＮＳサーバ（ＤＮＳ２）においては、サーバリストテーブル２１、アドミッションコントロールリストテーブル２２、および位置リストテーブル２３を設定する必要がある。
図２７は、ＤＮＳサーバ（ＤＮＳ２）のサーバリストテーブル２１の一例を示す図である。
図２８は、ＤＮＳサーバ（ＤＮＳ２）のアドミッションコントロールリストテーブル２２の一例を示す図である。
図２９は、ＤＮＳサーバ（ＤＮＳ２）の位置リストテーブル２３の一例を示す図である。
上記のリスト中でホスト名がｓｅｒｖｅｒ１００．ｃｏｍとなっているが、これはＤＮＳサーバ（ＤＮＳ１）のアドミッションコントロールリストテーブル２（２６）（図２４参照）において、ＤＮＳサーバ（ＤＮＳ２）にサーバ選択処理を委譲されるものについては、ホスト名ｓｅｒｖｅｒ１．ｃｏｍの別名としてｓｅｒｖｅｒ１００．ｃｏｍが与えられるような設定になっているためである。
ここで、当システムの動作例を示す。
表３に動作例を説明するためのクライアントを定義する。
【００３５】
【表３】
【００３６】
まず、クライアントＣ１が、ホスト名ｓｅｒｖｅｒ１．ｃｏｍの名前解決要求を行った場合の処理について説明する。
クライアントＣ１は、拠点ＴＯＫＹＯに属するため、名前解決のため、初めにＤＮＳサーバ（ＤＮＳ１）に問い合わせる。
ＤＮＳサーバ（ＤＮＳ１）において、クライアントＣ１の拠点（ＩＰアドレス：１００．１５０．１．３４）を、図２６に示す位置リストテーブル２３から取得する。その結果、クライアントＣ１は、拠点ＴＯＫＹＯに属すると判断される。
ＤＮＳサーバ（ＤＮＳ１）において、ホスト名ｓｅｒｖｅｒ１．ｃｏｍに対応するアドミッションコントロールリスト１を抽出し、クライアントの位置がＴＯＫＹＯ、または＊（どれでも良い）で記述されているエントリーを検索する。
図２４に示すアドミッションコントロールリストテーブル１（２５）の上１行目に、クライアント位置＝ＴＯＫＹＯ、処理内容＝ａｌｌｏｗとあるので、クライアントＣ１に対しては、ＤＮＳサーバ（ＤＮＳ１）でサーバ選択処理を実施すると判断される。
次に、図２３に示すサーバリストテーブル２１に記載のサーバすべてについて、図２５に示すアドミッションコントロールリストテーブル２（２６）により、クライアントＣ１にアクセスさせて良いサーバか否かを判断する。
【００３７】
図２３に示すサーバリストテーブル２１に記載されている、コンテンツ配信サーバ（Ｓ１−１，Ｓ１−２，Ｓ１−３）は、共に拠点ＴＯＫＹＯに属するコンテンツ配信サーバである。
図２５に示すアドミッションコントロールリストテーブル２（２６）の上１行目によれば、サーバの位置＝ＴＯＫＹＯ、クライアントの位置＝ＴＯＫＹＯの場合処理内容＝ａ１１ｏｗとなっているため、これら３つのサーバは選択候補であると判断される。
図２３に示すサーバリストテーブル２１に記載されている、コンテンツ配信サーバ（Ｓ２−１）は、拠点ＮＡＧＯＹＡに属するコンテンツ配信サーバである。
アドミッションコントロールリストテーブル２（２６）によれば、サーバの位置＝ＮＡＧＯＹＡ、クライアントの位置＝ＴＯＫＹＯであるエントリーが存在しないため、明示されていないサーバの位置＝＊、クライアントの位置＝＊、処理内容＝ｄｅｎｙが適用される。従って、このサーバは選択候補から除外される。
即ち、クライアントＣ１に対しては、コンテンツ配信サーバ（Ｓ１−１，Ｓ１−２，Ｓ１−３）がサーバ選択候補となる。
サーバ選択部１３において、これら３つのサーバの中から１つのコンテンツ配信サーバを選択し、クライアントに選択されたサーバのＩＰアドレスを返す。
【００３８】
次に、クライアントＣ２が、ホスト名ｓｅｒｖｅｒ１．ｃｏｍの名前解決要求を行った場合の処理について説明する。
クライアントＣ２は、拠点ＨＩＲＯＳＨＩＭＡに属するため、名前解決のため初めにＤＮＳサーバ（ＤＮＳ２）に問い合わせる。
ＤＮＳサーバ（ＤＮＳ２）では、ｓｅｒｖｅｒ１．ｃｏｍについて解決できないため、ＤＮＳサーバ（ＤＮＳ２）が、ＤＮＳサーバ（ＤＮＳ１）に対しｓｅｒｖｅｒ１．ｃｏｍについて問い合わせる。
ＤＮＳサーバ（ＤＮＳ１）からみると、この問い合わせはあくまでＤＮＳサーバ（ＤＮＳ２）からの問い合わせであるため、ＤＮＳサーバ（ＤＮＳ２）のＩＰアドレス（２００．１５０．１．１００）の拠点を、図２６に示す位置リストテーブル２３から取得する。その結果、ＤＮＳサーバ（ＤＮＳ２）は、拠点ＯＳＡＫＡに属すると判断される。
続いて、ＤＮＳサーバ（ＤＮＳ１）において、ホスト名ｓｅｒｖｅｒ１．ｃｏｍに対応するアドミッションコントロールリスト１を抽出し、クライアントの位置がＯＳＡＫＡまたは＊（どれでも良い）で記述されているエントリーを検索する。
【００３９】
図２４に示すアドミッションコントロールリストテーブル１（２５）の上４行目に、クライアント位置＝ＯＳＡＫＡ、処理内容＝ｓｅｒｖｅｒ１００．ｃｏｍとあるので、クライアントＣ２に対しては、ＤＮＳサーバ（ＤＮＳ１）でサーバ選択処理を行わず、他のサーバ選択装置にてサーバ選択処理を実施すると判断される。
この処理内容に記載された文字列ｓｅｒｖｅｒ１００．ｃｏｍをｓｅｒｖｅｒ１．ｃｏｍの別名としてＤＮＳサーバ（ＤＮＳ２）に返す。
ＤＮＳサーバ（ＤＮＳ２）は、受け取ったホスト名ｓｅｒｖｅｒ１００．ｃｏｍをクライアントＣ２に返信する。
クライアントＣ２は、ホスト名ｓｅｒｖｅｒ１００．ｃｏｍの名前解決を行うためにＤＮＳサーバ（ＤＮＳ２）にアクセスする。
ＤＮＳサーバ（ＤＮＳ２）では、図２９に示す位置リストテーブル２３からクライアントＣ２の拠点名がＨＩＲＯＳＨＩＭＡであると判定される。
次に、図２７に示すサーバリストテーブル２１に記載されている、ホスト名ｓｅｒｖｅｒ１００．ｃｏｍに対応するサーバすべてについて、図２８に示すアドミッションコントロールリストテーブル２２により、クライアントＣ２にアクセスさせて良いサーバが否かを判断する。
【００４０】
図２７に示すサーバリストテーブルに記載のサーバは、拠点ＴＯＫＹＯにあるか拠点ＯＳＡＫＡにあるかのいずれかである。
図２８に示すアドミッションコントロールリストテーブル２２の３行目に、クライアントの位置＝ＨＩＲＯＳＨＩＭＡ、サーバの位置＝ＯＳＡＫＡ、処理内容＝ａｌｌｏｗと記載されているが、それ以外にクライアントの位置＝ＨＩＲＯＳＨＩＭＡであるエントリーは存在しないため、明示されていないサーバの位置＝＊、クライアントの位置＝＊、処理内容＝ｄｅｎｙが適用される。
従って、サーバの位置＝ＯＳＡＫＡである、コンテンツ配信サーバ（Ｓ３−１，Ｓ３−２）については、サーバ選択候補と判断され、サーバの位置＝ＴＯＫＹＯである、コンテンツ配信サーバ（Ｓ１−１，Ｓ１−２，Ｓ１−３）は、サーバ選択候補から除外されると判断される。
即ち、クライアントＣ２に対しては、コンテンツ配信サーバ（Ｓ３−１，Ｓ３−２）がサーバ選択候補となる。
サーバ選択部１３において、これら２つのコンテンツ配信サーバの中から１つのコンテンツ配信サーバが選択され、クライアントＣ２に、選択されたコンテンツ配信サーバのＩＰアドレスが返送される。
【００４１】
次に、クライアントＣ３が、ホスト名ｓｅｒｖｅｒ１．ｃｏｍの名前解決要求を行った場合の処理について説明する。
クライアントＣ３は、拠点ＳＥＡＴＬＥに属するため、名前解決のため初めにＤＮＳサーバ（ＤＮＳ１）に問い合わせる。
ＤＮＳサーバ（ＤＮＳ１）において、クライアントＣ３の拠点（ＩＰアドレス：１０．１０．５．５６）を、図２６に示す位置リストテーブル２３から取得する。その結果、クライアントＣ３は拠点ＳＥＡＴＬＥに属すると判断される。
ＤＮＳサーバ（ＤＮＳ１）において、ホスト名ｓｅｒｖｅｒ１．ｃｏｍに対応するアドミッションコントロールリスト１を抽出し、クライアントの位置がＳＥＡＴＬＥまたは＊（どれでも良い）で記述されているエントリーを検索する。
図２４に示すアドミッションコントロールリストテーブル１（２５）の上３行目に、クライアント位置＝ＳＥＡＴＬＥ、処理内容＝ｄｅｎｙとあるので、クライアントＣ３に対しては、ＤＮＳサーバ（ＤＮＳ１）でサーバ選択処理を実施しないと判断される。
【００４２】
従って、クライアントＣ１に対しては、ｓｅｒｖｅｒ１．ｃｏｍの名前解決が行えなかった旨を通知する。
上記の例からもわかる通り、実施の形態３の構成で適切に設定を行うことにより、想定したアクセスポリシを守ることが可能であることがわかる。
なお、前述したように、本発明のサーバ選択装置は、汎用コンピュータ上のソフトウェアで実現されるものである。
即ち、サーバ選択プログラムを、コンピュータのＣＰＵが実行することにより、前述の各実施の形態のサーバ選択方法の処理が行われる。ここで、このサーバ選択プログラムは、ＣＤ−ＲＯＭ等の記録媒体、あるいは、ネットワークを介したダウンロードにより供給される。
以上、本発明者によってなされた発明を、前記実施の形態に基づき具体的に説明したが、本発明は、前記実施の形態に限定されるものではなく、その要旨を逸脱しない範囲において種々変更可能であることは勿論である。
【００４３】
【発明の効果】
本願において開示される発明のうち代表的なものによって得られる効果を簡単に説明すれば、下記の通りである。
本発明によれば、クライアント位置情報に基づき選択候補サーバを絞り込む、あるいはサーバ選択の受付可否判断、他のサーバ選択サーバヘサーバ選択処理を委譲することが可能となり、複雑なアクセスポリシに対応した動作が可能となる。
【図面の簡単な説明】
【図１】 本発明の参考例のサーバ選択装置の概略構成を示すブロック図である。
【図２】 本発明のサーバ選択装置の一例の概略構成を示すブロック図である。
【図３】本発明の実施の形態１のサーバ選択装置の概略構成を示すブロック図である。
【図４】図３に示すサーバリストテーブルの一例を示す図である。
【図５】図３に示すアドミッションコントロールリストテーブルの一例を示す図である。
【図６】図３に示す位置リストテーブルの一例を示す図である。
【図７】図３に示すサーバ選択処理絞り込み取得部の処理手順を示すフローチャートである。
【図８】本発明の実施の形態１において、抽出されたサーバリストの一例を示す図である。
【図９】本発明の実施の形態１において、抽出されたアドミッションコントロールリストの一例を示す図である。
【図１０】本発明の実施の形態１のサーバ選択装置の変形例の、サーバリストテーブルの一例を示す図である。
【図１１】本発明の実施の形態１のサーバ選択装置の変形例の、アドミッションコントロールリストテーブルの一例を示す図である。
【図１２】本発明の実施の形態１のサーバ選択装置の変形例の、ｈｔｔｐリダイレクトメッセージの一例を示す図である。
【図１３】本発明の実施の形態２のサーバ選択装置の概略構成を示すブロック図である。
【図１４】図１３に示すアドミッションコントロールリストテーブルの一例を示す図である。
【図１５】本発明の実施の形態２において、抽出されたアドミッションコントロールリストの一例を示す図である。
【図１６】本発明の実施の形態２のサーバ選択装置の変形例の、アドミッションコントロールリストテーブルの一例を示す図である。
【図１７】本発明の実施の形態２のサーバ選択装置の変形例の、ｈｔｔｐリダイレクトメッセージの一例を示す図である。
【図１８】本発明の実施の形態３のサーバ選択装置が適用されるネットワーク構成を示すブロックである。
【図１９】本発明の実施の形態３のサーバ選択装置のアクセスポリシの一例を示す図である。
【図２０】本発明の実施の形態３におけるＤＮＳシーケンスを示す図である。
【図２１】本発明の実施の形態３における通常のＤＮＳサーバを説明するためのブロック図である。
【図２２】本発明の実施の形態のサーバ選択装置（ＤＮＳサーバ（ＤＮＳ１））の概略構成を示すブロック図である。
【図２３】本発明の実施の形態３のサーバ選択装置のサーバリストテーブルの一例を示す図である。
【図２４】本発明の実施の形態３のサーバ選択装置のアドミッションコントロールリストテーブル１の一例を示す図である。
【図２５】本発明の実施の形態３のサーバ選択装置のアドミッションコントロールリストテーブル２の一例を示す図である。
【図２６】本発明の実施の形態３のサーバ選択装置の位置リストテーブルの一例を示す図である。
【図２７】本発明の実施の形態３のＤＮＳサーバ（ＤＮＳ２）のサーバリストテーブルの一例を示す図である。
【図２８】本発明の実施の形態３のＤＮＳサーバ（ＤＮＳ２）のアドミッションコントロールリストテーブルの一例を示す図である。
【図２９】本発明の実施の形態３のＤＮＳサーバ（ＤＮＳ２）の位置リストテーブルの一例を示す図である。
【符号の説明】
１…サーバ選択要求情報受信手段、２…サーバリスト取得手段、３…サーバ選択処理候補絞り込み手段、５…サーバ選択手段、６…サーバ選択処理受付可否判断手段、７…サーバ選択結果情報通知手段、１０，３０…ＤＮＳクエリ受信部、１１…サーバリスト取得部、１２…サーバ選択処理候補絞り込み取得部、１３…サーバ選択部、１５，３２…ＤＮＳレスポンス送信部、１６…サーバ選択処理受付可否判断部、２１…サーバリストテーブル、２２…アドミッションコントロールリストテーブル、２３…位置リストテーブル、２５…アドミッションコントロールリストテーブル１、２６…アドミッションコントロールリストテーブル２、３１…マスターファイル参照部、３３…マスターファイル、３５…サーバ選択処理部、Ｒ１〜Ｒ５…ルータ、ＤＮＳ１，ＤＮＳ２…ＤＮＳサーバ、Ｓ１−１，Ｓ１−２，Ｓ１−３，Ｓ２−１，Ｓ３−１，Ｓ３−２…コンテンツ配信サーバ。
【発明の属する技術分野】
本発明は、サーバ選択方法、サーバ選択装置、サーバ選択プログラム、および、記録媒体に係わり、特に、分散サーバの中からクライアントにアクセスさせるのに適切なサーバを選択する際に、クライアントの位置及びサーバの設置位置に基づき、選択候補とするサーバのリストを生成する技術に関する。
【０００２】
【従来の技術】
近年のインターネットトラヒック増大に伴い、１台のサーバにアクセスするクライアントが増大し、アクセス集中によって安定したサービスの提供が困難となっている。
このような問題を解決するため、同じサービスを提供する複数台のサーバを用意し、クライアントのアクセスをそれらのサーバに分散することで負荷分散を実施しようとする負荷分散方法が数多く考案され、この方法を実現するサーバ選択装置もさまざまな種類のものが発明、実用化されている。
通常のサーバ選択装置は、利用者の識別情報とサーバリストを入力とし、選択されたサーバの識別情報を出力とする。
一般的には、サーバリストに記載のすべてのサーバについて、サーバ負荷、サーバ−クライアント間の距離などのメトリックを測定し、これに基づき最適なサーバを選択する方式が用いられる。
また、近年では、前述したサーバ選択装置とキャッシュサーバ、ミラーサーバを用いたＣＤＮ（Content Delivery Network）に注目が集まり、サービスが開始され始めている。
ＣＤＮとは、ネットワーク内部にキャッシュサーバやミラーサーバ（以下、ＣＤＮサーバと称する。）を分散配置し、サーバ選択装置によって、クライアントに最寄りのキャッシュサーバや、ミラーサーバにアクセスさせることで、高品質なサービスを提供しようとする仕組みである。
前述したＣＤＮは、専用のネットワークを持たなくても実現できるため、複数のネットワーク運営者によって管理されているネットワーク上にＣＤＮサーバを配置してサービスを提供することが可能である。
【０００３】
【発明が解決しようとする課題】
複数のネットワーク運営者が管理する複数のネットワーク上にＣＤＮサーバを配置し、コンテンツ配信サービスを提供することを考える。
ネットワーク運営者がＣＤＮサーバを自ネットワーク内に配置する目的は、（１）自ネットワークに属するユーザの利便性向上、（２）自ネットワークに属するユーザによる外部ネットワークへ向けたトラヒック低減などが考えられる。
このようなＣＤＮサーバを配置する一方で、ネットワーク運営者は自ネットワークのクライアントや回線を保護するために、独自にＣＤＮサーバに対するサーバ利用ポリシを定めることが多いと考えられる。
例えば、ネットワーク運営者は、自ネットワーク上に配置したＣＤＮサーバに他ネットワークに属するユーザをアクセスさせないようなアクセスポリシを設定するかも知れない。
その理由は、このアクセスポリシによって、他ネットワークに属するユーザのアクセスによる回線負荷、サーバ負荷の増加を抑制できると期待しているからである。
【０００４】
一方で、自ネットワーク上のＣＤＮサーバに障害が発生した場合は、外部ネットワーク上に配置されたＣＤＮサーバに、自ネットワークのクライアントをアクセスさせることを望むかもしれない。
また、あるネットワーク運営者は、非常に複雑なＣＤＮサーバ利用ポリシ、あるいは、そのネットワーク運営者が外部に漏洩してはならない情報に基づいて、ＣＤＮサーバ利用ポリシを設定するかもしれない。
例えば、顧客の契約形態に応じてサーバを選択する場合などがこれに相当する。
このような場合、ＣＤＮサービスで共通に用いられるサーバ選択装置では、サーバ選択処理が行えないため、サーバ選択処理を該ネットワーク運営者が配置するサーバ選択装置に委譲しなければならない。
さらには、ＣＤＮ事業者側の観点からは、ＣＤＮサーバを配置していないネットワーク上のクライアントからのＣＤＮサーバヘのアクセスを拒むケースも考えられる。
これは、ＣＤＮサーバを数多く配置するための戦略であったり、未知のネットワークからのアクセスによって著作権保護が困難になることを防くためと考えられる。
【０００５】
このような各ネットワーク運営者が設定するＣＤＮサーバ利用ポリシ、ＣＤＮ事業者が設定するサーバ選択装置に対するアクセスポリシなどを、ＣＤＮサービスを提供するサーバ選択装置はすべて満たさなければならない。
前述したような、ＣＤＮを実現するサーバ選択装置に求められる課題は、下記の２通りに分類できる。
（課題１）クライアントの属性情報に応じて、選択候補とするサーバをサーバ選択処理の前に絞り込む機能を実現する。
（課題２）クライアントの属性情報に応じて、他のサーバ選択装置に処理を委譲する、あるいは、サーバ選択処理そのものを行わないことを判断する機能を実現する。
しかしながら、従来のいかなるサーバ選択装置においても、これらの課題を実現する機能を有していなかった。
したがって、前述のＣＤＮサービスを提供する場合のサーバ選択装置としては不十分であり、ＣＤＮサービス展開の阻害要因となっている。
【０００６】
本発明は、前記従来技術の問題点を解決するためになされたものであり、本発明の目的は、サーバ選択方法及びサーバ選択装置において、クライアント属性に基づき、選択候補サーバを絞り込む、あるいはサーバ選択の受付可否判断、他のサーバ選択サーバヘサーバ選択処理を委譲することを判断することが可能となる技術を提供することにある。
また、本発明の他の目的は、前述のサーバ選択方法をコンピュータに実行させるサーバ選択プログラムを記録する記録媒体を提供することにある。
また、本発明の他の目的は、前述のサーバ選択プログラムを記録した記録媒体を提供することにある。
本発明の前記ならびにその他の目的と新規な特徴は、本明細書の記述及び添付図面によって明らかにする。
【０００７】
【課題を解決するための手段】
本願において開示される発明のうち、代表的なものの概要を簡単に説明すれば、下記の通りである。
本発明の参考例のサーバ選択装置の概略構成を図１に示す。
図１に示すサーバ選択装置は、サービス識別情報（ＩＰ（Internet Protocol）アドレス、ホスト名、ＵＲＬ（Uniform Resource Locators）など）と、そのサービスを提供可能な複数のサーバの識別情報（ＩＰアドレス、ホスト名、ＵＲＬなど）および位置情報（ＩＰアドレスの領域などで示される）との対応関係について記述したサーバリストテーブル２１と、サーバの位置情報と、当該位置情報を持つサーバにアクセスしても良いクライアントの位置情報（ＩＰアドレスの領域などで示される）、あるいは、アクセスしてはならないクライアントの位置情報（ＩＰアドレスの領域などで示される）との対応関係について記述したアドミッションコントロールリストテーブル２２とを備える。
図１に示すサーバ選択装置では、サーバ選択要求情報受信手段１で、クライアント属性情報及びサービス識別情報を含むサーバ選択要求情報を受信した後、サーバリスト取得手段２で、前記サーバ選択要求情報に含まれるサービス識別情報に基づき前記サーバリストテーブル２１を参照し、前記サービス識別情報に対応したサーバと当該サーバの位置情報のリストを取得し、サーバ選択処理候補絞り込み手段３で、前記取得したサーバの各々について、前記アドミッションコントロールリストテーブル２２を参照し、前記クライアントの位置情報および前記サーバの位置情報に基づき、当該サーバに当該クライアントをアクセスさせて良いか否か判定し、アクセスさせて良いサーバのみをサーバ選択候補とし、サーバ選択手段５で、前記絞り込まれたサーバ選択候補の中からクライアントにアクセスさせるサーバを選択するので、クライアントの位置情報に応じて選択候補とするサーバをサーバ選択処理の前に絞り込むことが可能となる。
【０００８】
本発明のサーバ選択装置の一例の概略構成を図２に示す。
図２に示すサーバ選択装置では、サービス識別情報と、そのサービスを提供可能な複数のサーバの識別情報および位置情報との対応関係について記述したサーバリストテーブル２１と、クライアントの位置情報と、当該位置情報を持つクライアントに対しサーバ選択処理を継続するか中断するか、あるいは、他のサーバ選択装置に処理を委譲するかをサービス識別情報毎に指定したアドミッションコントロールリストテーブル２２を備える。アドミッションコントロールリストテーブル２２は、回線の細いネットワークに接続している拠点に属するクライアントからサーバへのアクセスを禁止し、または、多くのサーバを有する拠点に属するクライアントから他の拠点のサーバへのアクセスを禁止し、あるいは、サーバが無いか少ない拠点に属するクライアントから、自拠点から１リンクでたどり着け、かつ、そのリンクの帯域が最も大きい拠点のサーバへのアクセスを許可するというアクセスポリシに基づき記述される。
図２に示すサーバ選択装置では、サーバ選択要求情報受信手段１で、クライアント位置情報及びサービス識別情報を含むサーバ選択要求情報を受信した後、サーバ選択処理受付可否判断手段６で、前記サーバ選択要求情報に含まれるクライアント位置情報、およびサービス識別情報に基づき、前記アドミッションコントロールリストを参照し、当該クライアントに対する処理を判断し、前記サーバ選択処理受付可否判断手段において、サーバ選択処理を継続すると判断された場合、サーバリスト取得手段２で、前記サービス識別情報に基づき、前記サーバリストを参照し、前記サービス識別情報に対応したサーバ識別情報のリストを取得し、サーバ選択手段５で、前記サーバ識別情報のリストに記載のサーバの中から前記クライアントにアクセスさせるサーバを選択する。
また、前記サーバ選択処理受付可否判断手段において、サーバ選択処理を中断すると判断された場合、あるいは、サーバ選択処理を他のサーバ選択装置に委譲すると判断された場合、サーバ選択結果情報通知手段で、クライアントに対しサーバ選択処理を中断したことを示すサーバ選択結果情報、あるいは、前記クライアントに対し他のサーバ選択装置にアクセスするよう促すサーバ選択結果情報を通知するようにしたので、クライアントの属性情報に応じて他のサーバ選択装置に処理を委譲する、あるいはサーバ選択処理そのものを行わないことを判断する機能を実現することが可能となる。
【０００９】
また、本発明のサーバ選択装置は、サービス識別情報と、当該サービスを提供する複数のサーバの識別情報および位置情報との対応関係について記述したサーバリストテーブルと、サーバの位置情報と、当該位置情報を持つサーバに対してアクセスしても良いクライアントの位置情報、あるいはアクセスしてはならないクライアントの位置情報との対応関係について記述した第１のアドミッションコントロールリストテーブルと、クライアントの位置情報と、該位置情報を持つクライアントに対して、サーバ選択処理を継続するか否か、あるいは、他のサーバ選択装置に処理を委譲するかを、サービス識別情報毎に指定した第２のアドミッションコントロールリストテーブルとを備える。
第１及び第２のアドミッションコントロールリストテーブルは、回線の細いネットワークに接続している拠点に属するクライアントからサーバへのアクセスを禁止し、または、多くのサーバを有する拠点に属するクライアントから他の拠点のサーバへのアクセスを禁止し、あるいは、サーバが無いか少ない拠点に属するクライアントから、自拠点から１リンクでたどり着け、かつ、そのリンクの帯域が最も大きい拠点のサーバへのアクセスを許可するというアクセスポリシに基づき記述される。
本発明のサーバ選択装置では、サーバ選択要求情報受信手段で、クライアント位置情報、およびサービス識別情報を含むサーバ選択要求情報を受信した後、サーバ選択処理受付可否判断手段で、前記サーバ選択要求情報に含まれるクライアント位置情報およびサービス識別情報に基づき、前記第２のアドミッションコントロールリストテーブルを参照し、当該クライアントに対する処理を判断し、前記サーバ選択処理受付可否判断手段において、サーバ選択処理を継続すると判断された場合、サーバリスト取得手段で、前記サーバ選択要求情報に含まれるサービス識別情報に基づき、前記サーバリストテーブルを参照し、前記サービス識別情報に対応した位置情報を持つサーバを取得し、サーバ選択処理候補絞り込み手段で、前記取得されたサーバの各々について、前記第１のアドミッションコントロールリストテーブルを参照し、前記クライアント位置情報および前記サーバ位置情報に基づき、当該サーバに当該クライアントをアクセスさせて良いか否か判定し、アクセスさせて良いサーバのみをサーバ選択候補とした後、サーバ選択手段で、前記絞り込まれた前記サーバ選択候補の中からクライアントにアクセスさせるサーバを選択する。
また、前記サーバ選択処理受付可否判断手段において、サーバ選択処理を中断すると判断された場合、あるいは、サーバ選択処理を他のサーバ選択装置に委譲すると判断された場合、サーバ選択結果情報通知手段で、クライアントに対しサーバ選択処理を中断したことを示すサーバ選択結果情報、あるいは、前記クライアントに対し他のサーバ選択装置にアクセスするよう促すサーバ選択結果情報を通知するようにしたので、サーバ選択装置に対する想定したアクセスポリシを守ることが可能となる。
【００１０】
【発明の実施の形態】
以下、図面を参照して本発明の実施の形態を詳細に説明する。
なお、実施の形態を説明するための全図において、同一機能を有するものは同一符号を付け、その繰り返しの説明は省略する。
また、すべての実施の形態において、サーバ選択装置、サーバ、クライアントは、すべて汎用コンピュータ上のソフトウェアで実現されるものとする。
さらに、ネットワークはＩＰネットワークとし、サーバ選択装置、サーバ、クライアントはすべてＩＰネットワーク上で通信可能な機器であるとする。
［実施の形態１］
図３は、本発明の実施の形態１のＤＮＳ（Domain Name System）サーバの概略構成を示すブロック図である。
本実施の形態において、サーバ選択装置はＤＮＳサーバとして動作するものとする。即ち、ホスト名を表す文字列が入力され、その文字列に対応するＩＰアドレスを出力する機能を有するものである。
なお、通常のＤＮＳでは、一つのホスト名に対し一つのＩＰアドレスが対応しているが、本実施の形態におけるＤＮＳは、一つのホスト名に対し複数のＩＰアドレスが対応づけられ、同じホスト名に対する名前解決を要求した場合でもクライアントの位置に応じて返されるＩＰアドレスが異なるものとする。
図３に示すように、本実施の形態のＤＮＳサーバは、サーバリストテーブル２１と、アドミッションコントロールリストテーブル２２、位置リストテーブル２３と、ＤＮＳクエリ受信部１０と、サーバリスト取得部１１、サーバ選択処理絞り込み取得部１２と、サーバ選択部１３と、ＤＮＳレスポンス送信部１５とで構成される。
【００１１】
図４は、図３に示すサーバリストテーブル２１の一例を示す図である。
サーバリストテーブル２１は、ホスト名（本発明のサービス識別情報）と、そのホスト名に対応する複数のサーバのＩＰアドレス（本発明のサーバ識別情報）、およびサーバの位置を示す文字列（本発明のサーバ属性情報）が格納される。
図５は、図３に示すアドミッションコントロールリストテーブル２２の一例を示す図である。
アドミッションコントロールリストテーブル２２は、ある位置に存在するサーバに対する、ある位置に存在するクライアントのアクセス可否について記述されたリストである。
アドミッションコントロールリストテーブル２２の情報要素は、ホスト名、処理内容（アクセスさせるか否か）、サーバの位置（本発明のサーバ属性情報）、クライアントの位置（本発明のクライアント属性情報）である。
あるサーバの位置とクライアントの位置の組における処理内容にａｌｌｏｗと記載された場合、該サーバの位置に存在するサーバに対し、該クライアントの位置に存在するクライアントによるアクセスを許可する。
また、あるサーバの位置とクライアントの位置の組における処理内容にｄｅｎｙと記載された場合、該サーバの位置に存在するサーバに対し該クライアントの位置に存在するクライアントによるアクセスを許可しない。
また、サーバ、クライアントの位置に「＊」印が記される場合は「すべての位置」を意味するものとする。
【００１２】
あるサーバの位置、およびクライアントの位置の組が与えられた時、当リストの先頭から検索し、初めに合致した組における処理内容を実行する。
また、各ホスト名毎のリストの末尾には、明示されないが処理内容がｄｅｎｙ、サーバの位置が「＊」、クライアントの位置が「＊」である組が記載されているものと見なす。
図６は、図３に示す位置リストテーブル２３の一例を示す図である。
位置リストテーブル２３は、位置名と、その位置に存在する装置のアドレス帯との対応表である。
アドレス帯の記述方法は（ＩＰアドレス）／（ビットマスク）であるとする。
例えば、１００．００．０／８と記載される場合、ＩＰアドレスを３２ｂｉｔの二進数に展開した時の、上位８ビットが位置を識別する部分であることを意味する。
それ以外のビットは、どのような値でも当該位置に属するものとする。
例えば、図６において、１００．１．２．３という装置も、１００．２５４．２５４．２３３という装置も等しくＴＯＫＹＯという位置に存在することを意味する。
【００１３】
次に、図３に記載の各処理部について説明する。
ＤＮＳクエリ受信部１０は、ＤＮＳプロトコルに基づき、リクエストされたホスト名と、リクエストしたクライアントのＩＰアドレスを取得する。
サーバリスト取得部１１では、ＤＮＳクエリ受信部１０で受信したホスト名に対応するサーバのＩＰアドレスと、サーバの位置リストをサーバリストテーブル２１から取得する。
サーバ選択処理絞り込み取得部１２のシーケンスを図７に示す。
始めに、ＤＮＳクエリ受信部１０で受信したクライアントのＩＰアドレスから位置リストテーブル２３を用い、クライアントの位置を特定する（ステップ１０１）。
次に、アドミッションコントロールリストテーブル２２の中で前記ホスト名に関する部分を参照し、サーバリスト取得部１１で取得したサーバのＩＰアドレスとサーバの位置リストに記載のすべてのサーバについて、サーバの位置とクライアントの位置とからアクセス可否判断を行う（ステップ１０２、ステップ１０３）。
次に、アクセス可とされたサーバを、選択候補サーバとする（ステップ１０４）。
サーバ選択部１３では、前記サーバ選択処理絞り込み取得部１２のアクセス可否判断において、アクセス可とされたサーバを選択対象サーバとし、その中から当該クライアントにアクセスさせるサーバを選択する。
ＤＮＳレスポンス送信部１５では、ＤＮＳプロトコルに基づき、前記サーバ選択部１３で選択されたサーバのＩＰアドレスをクライアントに送信する。
【００１４】
以上示してきた構成をもつＤＮＳサーバの動作例について以下に示す。
初めに、ＤＮＳクエリ受信部１０で、クライアント（ＩＰアドレス２００．１．２．３）からのホスト名ｓｅｒｖｅｒ２．ｃｏｍに対するＤＮＳ解決要求を受信する。
サーバリスト取得部１１では、ｓｅｒｖｅｒ２．ｃｏｍに対応するサーバのＩＰアドレスおよび位置名を取得する。
サーバリストテーブル２１を図４に記載したものと仮定すると、図８に示すリストが取得できたサーバリストとなる。以下、本実施の形態において、サーバリストとは図８のリストを指すものとする。
次に、サーバ選択処理絞り込みを実施する。
クライアントのＩＰアドレスが２００．１．２．３であり、図６に示す位置リストテーブル２３から上位８ビットが２００である装置は、すべてＯＳＡＫＡという位置に存在するものとしていることから、当該クライアントの位置名もＯＳＡＫＡと判断される。
次に、ホスト名ｓｅｒｖｅｒ２．ｃｏｍに対応するアドミッションコントロールリストテーブル２２を取得する。
アドミッションコントロールリストテーブル２２が図５に示すものとすると、図９に示すリストが取得できたアドミッションコントロールリストとなる。
以下、本実施の形態において、アドミッションコントロールリストとは図９に示すリストを指すものとする。
【００１５】
次に、図８に示すサーバリストに記載のサーバすべてについて、図９に示すアドミッションコントロールリストを参照しながらサーバ選択候補とするかどうか決定する。
ＩＰアドレス１００．２０．１．１０であるサーバは、ＴＯＫＹＯという位置に存在する。一方、クライアントは、ＯＳＡＫＡという位置に存在する。
図９に示すアドミッションコントロールリストによれば、上一行目にサーバの位置＝ＴＯＫＹＯ、クライアントの位置＝＊（何でも良い）、また、この場合の処理内容はａｌｌｏｗと記されている。
この上一行目の記述が当該サーバに当てはまり、処理内容がａｌｌｏｗであることから当サーバは選択候補となる。
次に、ＩＰアドレス２００．２０．５．１０のサーバはＯＳＡＫＡという位置に存在する。クライアントは、同じくＯＳＡＫＡという位置に存在する。
図９に示すアドミッションコントロールリストによれば、上２行目にサーバの位置＝ＯＳＡＫＡ、クライアントの位置＝ＯＳＡＫＡ、また、この場合の処理内容はａｌｌｏｗと記されている。
これが当該サーバに当てはまり、処理内容がａｌｌｏｗであることから当サーバは選択候補となる。
【００１６】
次に、ＩＰアドレス２２５．２０．５．１０のサーバは、ＨＩＲＯＳＨＩＭＡという位置に存在する。クライアントは、同じくＯＳＡＫＡという位置に存在する。
図９に示すアドミッションコントロールリストによれば、上３行目にサーバの位置＝ＨＩＲＯＳＨＩＭＡ、クライアントの位置＝ＨＩＲＯＳＨＩＭＡ、また、この場合の処理内容はａｌｌｏｗと記されている。しかし、これは当該サーバには当てはまらない。
その他に、サーバの位置＝ＨＩＲＯＳＨＩＭＡ、あるいは＊（何でも良い）とする記述が、図９に示すアドミッションコントロールリスト内に存在しない。
従って、当該サーバについては、明示されていないサーバの位置＝＊（何でも良い）、クライアントの位置＝＊（何でも良い）が適用され、この時の処理内容はｄｅｎｙであることから、サーバ選択候補としては扱わない。
従って、この場合サーバ選択候補としては、ＩＰアドレス１００．２０．１．１０．２００．２０．５．１０であるサーバが取得できる。サーバ選択部１３では、この２つのサーバの中から適切なサーバを１つ選択する。
選択のポリシとしてクライアントの位置と同じ位置にあるサーバを優先的に選択するものとする。
クライアントの位置は、ＯＳＡＫＡであるから、同じＯＳＡＫＡに属するサーバ２００．２０．５．１０が優先的に選択され、ＤＮＳレスポンス送信部１５からクライアントに送信される。
【００１７】
前述の説明では、ＤＮＳサーバに本発明を適用した実施の形態について説明したが、ユーザがリクエストするＵＲＬに基づいて、サーバ選択を行うＵＲＬベースサーバ選択装置にも本発明を適用することが可能である。
ここでは、ｈｔｔｐによって受信したコンテンツ取得要求に基づき、コンテンツを提供するサーバに該要求を転送するｈｔｔｐリダイレクタに本発明を適用する例について述べる。
ＤＮＳの時と異なる点は、以下の通りである。
（１）サーバリストテーブル２１に記載されるホスト名、およびサーバのＩＰアドレスをＵＲＬに変更する。
（２）アドミッションコントロールリストテーブル２２に記載されるホスト名をＵＲＬに変更する。
（３）ＤＮＳクエリ受信部１０を、ｈｔｔｐリクエスト受信部に変更する。
（４）ＤＮＳレスポンス送信部１５を、ｈｔｔｐリダイレクトメッセージ送信部に変更する。
【００１８】
変更されたコンポーネントの説明を下記に示す。
変更後のサーバリストテーブル２１の一例を図１０に示す。
ここで、代表ＵＲＬとは、クライアントが、初めに当ｈｔｔｐリダイレクタにアクセスする際のＵＲＬであり、サーバのＵＲＬとは実際のコンテンツを提供するサーバ群のＵＲＬであるものとする。
変更後のアドミッションコントロールリストテーブル２２の一例を図１１に示す。
ｈｔｔｐリクエスト受信部は、ｈｔｔｐのＧＥＴメッセージを受信し、そこから代表ＵＲＬとクライアントのＩＰアドレスを取得する。
ｈｔｔｐリダイレクトメッセージ送信部は、ｈｔｔｐのリダイレクト（転送）メッセージを図１２に示すフォーマットで送信する。
以上の変更を加えることで、本発明をＵＲＬベースサーバ選択装置に適用することも可能となる。
前述の実施の形態により、ユーザの位置に基づき選択対象サーバを絞り込むことが可能となる。
【００１９】
［実施の形態２］
図１３は、本発明の実施の形態２のＤＮＳ（Domain Name System）サーバの概略構成を示すブロック図である。
本実施の形態においても、サーバ選択装置はＤＮＳサーバとして動作するものとする。即ち、ホスト名を表す文字列が入力され、その文字列に対応するＩＰアドレスを出力する機能を有するものである。
なお、通常のＤＮＳでは一つのホスト名に対し一つのＩＰアドレスが対応しているが、本実施の形態におけるＤＮＳは、一つのホスト名に対し複数のＩＰアドレスが対応づけられ、同じホスト名に対する名前解決を要求した場合でもクライアントの位置に応じて返されるＩＰアドレスが異なるものとする。
図１３に示すように、本実施の形態のＤＮＳサーバは、サーバリストテーブル２１と、アドミッションコントロールリストテーブル２２、位置リストテーブル２３と、ＤＮＳクエリ受信部１０と、サーバリスト取得部１１、サーバ選択処理受付可否判断部１６と、サーバ選択部１３と、ＤＮＳレスポンス送信部１５とで構成される。
なお、本実施の形態において、ＤＮＳサーバには、３種類のリストテーブルが既に記憶されているものとする。ここで、サーバリストテーブル２１、および位置リストテーブル２３は、前述の実施の形態１の場合と同じとする。
【００２０】
図１４は、図１３に示すアドミッションコントロールリストテーブル２２の一例を示す図である。
アドミッションコントロールリストテーブル２２は、ある位置に存在するクライアントに対しサーバ選択処理を行うか否か、処理を他のサーバ選択装置に委譲するかが記述される。
アドミッションコントロールリストテーブル２２の情報要素は、ホスト名、処理内容（サーバ選択処理を行うか否か、あるいは他のサーバ選択装置に処理を委譲するか）、クライアントの位置（本発明のクライアント属性情報）である。
あるクライアントの位置について処理内容がａｌｌｏｗであった場合、その位置に存在するクライアントに対してはサーバ選択処理を行うものとする。
また、処理内容がｄｅｎｙであった場合、その位置に存在するクライアントに対してはサーバ選択処理を行わないものとする。
また処理内容がａｌｌｏｗ、ｄｅｎｙ以外の文字列であった場合、その位置に存在するクライアントに対しては、その文字列を入力されたホスト名の別名として返すことで、その別名を解決するＤＮＳサーバにサーバ選択処理を委譲するものとする。
また、クライアントの位置に「＊」印が記される場合は「すべての位置」を意味するものとする。
また、各ホスト名毎のリストの末尾には、明示されないが処理内容がｄｅｎｙ、クライアントの位置が＊が記載されていると見なす。
【００２１】
次に、図１３に記載の各処理部について説明する。
ＤＮＳクエリ受信部１０は、実施の形態１と同様の処理を行う。
サーバ選択処理受付可否判断部１６では、初めに、ＤＮＳクエリ受信部１０で取得したクライアントのアドレスおよび位置リストテーブル２３を用いクライアントの位置名を取得する。
次に、ＤＮＳクエリ受信部１０で取得したホスト名と前記クライアント位置名とからアドミッションコントロールリストテーブル２２を参照し、サーバ選択処理の受付可否判断を実施する。
サーバリスト取得部１１は、実施の形態１と同様であるが、前記サーバ選択処理受付可否判断部１６でサーバ選択処理を実行することになった場合にのみ実行される点が異なる。
サーバ選択部１３は、サーバリスト取得部１１によって取得されたサーバリストに記載のサーバの中からクライアントにアクセスさせるサーバを選択する。
ＤＮＳレスポンス送信部１５は、サーバ選択処理受付可否判断部１６における判断内容によって処理が異なる。
サーバ選択処理受付可否判断部１６において、サーバ選択処理を行うと判断された場合、サーバ選択部１３によって選択されたサーバをＤＮＳのレスポンスとしてクライアントに返す。
また、サーバ選択処理受付可否判断部１６において、サーバ選択処理を行わないと判断された場合、ホスト名に対応するＩＰアドレスが存在しない旨を通知するＤＮＳレスポンスメッセージをクライアントに返す。
さらに、サーバ選択処理受付可否判断部１６において、他のＤＮＳサーバに処理を委譲すると判断された場合、アドミッションコントロールリストテーブル２２に記載の委譲先のホスト名が、ＤＮＳクエリ受信部１０で取得したホスト名の別名である旨を示すＤＮＳレスポンスメッセージをクライアントに返す。
【００２２】
以上示してきた構成をもつＤＮＳサーバの動作例について説明する。
いくつかのクライアント（クライアントＡ（ＩＰアドレス：１００．５０．３．２２）、クライアントＢ（ＩＰアドレス：２００．１．２．３）、クライアントＣ（ＩＰアドレス：２２５．２０．１．２）が、ＤＮＳサーバにホスト名ｓｅｒｖｅｒ１．ｃｏｍに対するＤＮＳ解決要求を行ったものとする。
初めに、ＤＮＳクエリ受信部１０でこれらのクライアントからのＤＮＳ解決要求を受信する。
サーバ選択処理受付可否判断部１６において、先ず、クライアントのＩＰアドレスからクライアントの位置名を取得する。
図１３に示す位置リストテーブル２３が図６に示すものであると仮定すると、上位８ビットが１００である装置はすべてＴＯＫＹＯ、上位８ビットが２００である装置はすべてＯＳＡＫＡ、上位１６ビットが２２５．２０である装置はすべてＨＩＲＯＳＨＩＭＡという位置に存在することになる。
したがって、クライアントＡの位置名はＴＯＫＹＯ、クライアントＢの位置名はＯＳＡＫＡ、クライアントＣの位置名はＨＩＲＯＳＨＩＭＡとそれぞれ判断される。
次に、ホスト名ｓｅｒｖｅｒ１．ｃｏｍに対応するアドミッションコントロールリストテーブル２２を取得する。
図１３に示すアドミッションコントロールリストテーブル２２が、図１４に示すものであると仮定すると、図１５が取得できたアドミッションコントロールリストとなる。以下、本実施の形態において、アドミッションコントロールリストとは、図１５に示すリストを指すものとする。
【００２３】
次に、これらのクライアントすべてについて、図１５に示すアドミッションコントロールリストを参照しながら、サーバ選択処理受付可否判断を行う。
クライアントＡの位置名はＴＯＫＹＯであるため、図１５に示すアドミッションコントロールリストから処理内容がａｌｌｏｗであり、サーバ選択処理を継続すると判断する。
クライアントＢの位置名はＯＳＡＫＡであるため、図１５に示すアドミッションコントロールリストに記載されるホスト名ｓｅｒｖｅｒ１００．ｃｏｍを別名として返すことで、この別名を解決するＤＮＳサーバにサーバ選択処理を委譲すると判断する。
クライアントＣの位置名はＨＩＲＯＳＨＩＭＡであるため、図１５に示すアドミッションコントロールリストから処理内容がｄｅｎｙであり、サーバ選択処理を行わないと判断する。
以上を受けクライアントＡについてはサーバリストを取得し、サーバ選択を実施、サーバ選択結果をＤＮＳレスポンス送信部１５を介して送信する。
クライアントＢについては、ｓｅｒｖｅｒ１００．ｃｏｍがｓｅｒｖｅｒ１．ｃｏｍの別名であるとしてＤＮＳレスポンス送信部１５を介して送信する。
クライアントＣについては、該当するＩＰアドレスが存在しなかったものとしてＤＮＳレスポンス送信部１５を介して送信する。
【００２４】
前述の説明では、ＤＮＳサーバに本発明を適用した実施の形態について説明したが、ユーザがリクエストするＵＲＬに基づいてサーバ選択を行うＵＲＬベースサーバ選択装置にも本発明を適用することが可能である。
ここでは、ｈｔｔｐによって受信したコンテンツ取得要求に基づき、コンテンツを提供するサーバに該要求を転送するｈｔｔｐリダイレクタに本発明を適用する例について述べる。
ＤＮＳの時と異なる点は、以下の通りである。
（１）サーバリストテーブル２１に記載されるホスト名、およびサーバのＩＰアドレスをＵＲＬに変更する。
（２）アドミッションコントロールリストテーブル２２に記載されるホスト名をＵＲＬに変更する。
（３）ＤＮＳクエリ受信部１０を、ｈｔｔｐリクエスト受信部に変更する。
（４）ＤＮＳレスポンス送信部１５を、ｈｔｔｐリダイレクトメッセージ送信部に変更する。
変更されたコンポーネントの説明を下記に示す。
変更後のサーバリストテーブル２１の例は、前述の図１０に示すものと同じであり、前述の実施の形態１の時と同様である。
変更後のアドミッションコントロールリストテーブル２２の一例を図１６に示す。
【００２５】
ｈｔｔｐリクエスト受信部は、前述の実施の形態１の場合と同様である。
ｈｔｔｐリダイレクトメッセージ送信部は、サーバ選択処理受付可否判断部１６における判断内容によって処理が異なる。
サーバ選択処理受付可否判断部１６において、サーバ選択処理を行うと判断された場合、サーバ選択部１３によって選択されたサーバを図１２に示すｈｔｔｐのリダイレクトメッセージとしてクライアントに返す。
サーバ選択処理受付可否判断部１６においてサーバ選択処理を行わないと判断された場合、図１７に示す要求されたＵＲＬが存在しない旨を通知するｈｔｔｐｐのレスポンスメッセージをクライアントに返す。
サーバ選択処理受付可否判断部１６において、他のｈｔｔｐリダイレクタに処理を委譲すると判断された場合、アドミッションコントロールリストに記載の委譲先のホスト名を図１２に示すｈｔｔｐのリダイレクトメッセージとしてクライアントに返す。
以上の変更を加えることで、本発明をＵＲＬベースサーバ選択装置に適用することも可能となる。
以上説明したように、本実施の形態により、ユーザの位置に基づきサーバ選択処理の受付可否を判断することが可能となる
【００２６】
［実施の形態３］
図１８は、本発明の実施の形態３のサーバ選択装置が適用されるネットワーク構成を示すブロック図である。この図１８に示すネットワークは、広域なサーバ負荷分散システムを構成する。
図１８に示すネットワークでは、サーバやクライアントが存在し得る拠点は、ＴＯＫＹＯ、ＮＡＧＯＹＡ、ＯＳＡＫＡ、ＨＩＲＯＳＨＩＭＡ、ＳＥＡＴＬＥの５個所にあり、それぞれがルータ（Ｒ１〜Ｒ５）を介して接続されている。
また、系内には、サーバ選択装置として機能する、二つのＤＮＳサーバ（ＤＮＳ１，ＤＮＳ２）がＴＯＫＹＯ、ＯＳＡＫＡの両拠点に配備されている。
ＤＮＳサーバ（ＤＮＳ１）は、拠点ＴＯＫＹＯ、ＮＡＧＯＹＡ、ＳＥＡＴＬＥのクライアントやサーバにおけるローカルＤＮＳサーバとして動作する。
ＤＮＳサーバ（ＤＮＳ２）は、拠点ＯＳＡＫＡ、ＨＩＲＯＳＨＩＭＡのクライアントやサーバにおけるローカルＤＮＳサーバとして動作する。
また、ＴＯＫＹＯ、ＮＡＧＯＹＡ、ＯＳＡＫＡには、それぞれ３つ、１つ、２つのコンテンツ配信サーバ（Ｓ１−１，Ｓ１−２，Ｓ１−３，Ｓ２−１，Ｓ３−１，Ｓ３−２）が配置されているものとする。
【００２７】
ここで、それぞれのＤＮＳサーバ（ＤＮＳ１，ＤＮＳ２）のアクセスポリシを図１９に定義するものとする。
このアクセスポリシは、下記のような基本的な考え方に基づいて作成されている。
（１）回線の細いネットワークに接続している拠点に属するクライアントにはサーバにアクセスさせない。（ＳＥＡＴＬＥが相当）
（２）多くのサーバを有する拠点に属するクライアントは他の拠点のサーバにアクセスしてはならない。（ＴＯＲＹＯが相当）
（３）自拠点にサーバがないか少ない場合、自拠点から１リンクでたどり着け、かつ、そのリンクの帯域がもっとも大きい拠点のサーバにアクセスすることを許可する。（ＮＡＧＯＹＡ、ＯＳＡＫＡ、ＨＩＲＯＳＨＩＭＡが相当）
このようなアクセスポリシを設けることで、サービスを提供する領域を制限できたり、ネットワークトラヒックやサーバ負荷を低減することが可能となる。
【００２８】
このアクセスポリシを実現するためのＤＮＳサーバ（ＤＮＳ１，ＤＮＳ２）を用いたシーケンスを図２０に示す。
前提として、最初のサーバ選択は、ＤＮＳサーバ（ＤＮＳ１）にて実施するものとする。
まず、拠点ＴＯＫＹＯ、ＮＡＧＯＹＡ、ＳＥＡＴＬＥに属するクライアントのＤＮＳシーケンスについて説明する。
これらの拠点は、プライマリＤＮＳサーバとして、ＤＮＳサーバ（ＤＮＳ１）を使用しているため、クライアントからの名前解決要求を受信し（図２０のイ）、ＤＮＳサーバ（ＤＮＳ１）のサーバ選択処理１１０によってクライアントにアクセスさせるサーバのＩＰアドレスを決定しクライアントに返す（図２０のロ）。
次に、拠点ＯＳＡＫＡ、ＨＩＲＯＳＨＩＭＡに属するクライアントのＤＮＳシーケンスについて説明する。
これらの拠点は、プライマリＤＮＳとして、ＤＮＳサーバ（ＤＮＳ２）を使用しているため、クライアントからの名前解決要求を受信する（図２０のハ）と、この要求をＤＮＳサーバ（ＤＮＳ１）に転送する（図２０のニ）。
ＤＮＳサーバ（ＤＮＳ１）では、名前解決要求をＤＮＳサーバ（ＤＮＳ２）から受信するため、本当のクライアントのアドレスは認識できず、ＤＮＳサーバ（ＤＮＳ２）のアドレスをクライアントのアドレスと認識してしまう。
これでは、クライアントの位置によるサーバ選択が実施できないため、サーバ選択処理１１０で、サーバ選択処理をＤＮＳサーバ（ＤＮＳ２）に委譲し、再度ＤＮＳサーバ（ＤＮＳ２）でサーバ選択を実行できるよう、別のホスト名をＤＮＳサーバ（ＤＮＳ２）に渡す（図２０のホ）。
ＤＮＳサーバ（ＤＮＳ２）が、クライアントにこのホスト名を返すと（図２０のヘ）、クライアントは、再度このホスト名を解決するためのＤＮＳクエリメッセージをＤＮＳサーバ（ＤＮＳ２）に対し発行する（図２０のト）。
ＤＮＳサーバ（ＤＮＳ２）のサーバ選択処理１１１によってクライアントにアクセスさせるサーバのＩＰアドレスを決定しクライアントに返す（図２０のチ）。
【００２９】
このシーケンスを実現するため、ＤＮＳサーバ（ＤＮＳ１）には、前述の実施の形態１および実施の形態２に記載のサーバ選択機能を実装し、ＤＮＳサーバ（ＤＮＳ２）には、前述の実施の形態１に記載のサーバ選択機能を実装する。
ＤＮＳサーバ（ＤＮＳ１）、およびＤＮＳサーバ（ＤＮＳ２）は、ともに通常のＤＮＳサーバとしても動作する必要があるため、図２１に示すような構成をとる。
通常のＤＮＳサーバは、マスターファイル３３を参照することで名前解決が可能であるものとする。マスターファイル参照部３１において、名前が解決できない時のみ、サーバ選択処理部３５でサーバ選択を実施する。
このサーバ選択処理部３５でのサーバ選択は、ＤＮＳサーバ（ＤＮＳ１）ならば後述の図２２に示すＤＮＳサーバによるサーバ選択を、ＤＮＳサーバ（ＤＮＳ２）ならば実施の形態１に記載のサーバ選択装置を利用したサーバ選択を実施する。
図２２は、本発明の実施の形態のサーバ選択装置（即ち、ＤＮＳサーバ（ＤＮＳ１））の概略構成を示すブロック図である。
図２２に示すサーバ選択装置は、前述の実施の形態１のサーバ選択装置と、前述の実施の形態２のサーバ選択装置とをマージしたような構成となっている。
従って、個々の構成部分についての説明は省略するが、アドミッションコントロールリストテーブル１（２５）は、前述の実施の形態２のアドミッションコントロールリストテーブル２２であり、アドミッションコントロールリストテーブル２（２６）は、前述の実施の形態１のアドミッションコントロールリストテーブル２２であることを付け加えておく。
ここで、ＴＯＫＹＯ、ＮＡＧＯＹＡ、ＯＳＡＫＡ、ＨＩＲＯＳＨＩＭＡ、ＳＥＡＴＬＥの各拠点のサブネットアドレスを表１に示す。
また、ＴＯＫＹＯ、ＮＡＧＯＹＡ、ＯＳＡＫＡに存在する各サーバのＩＰアドレスを表２に示す。
【００３０】
【表１】
【表２】
以上を前提として、前述のアクセスポリシを実現するための設定方法について述べる。
初めに、ＤＮＳサーバ（ＤＮＳ１）の設定について説明する。
ＤＮＳサーバ（ＤＮＳ１）においては、サーバリストテーブル２１、アドミッションコントロールリストテーブル１（２５）、アドミッションコントロールリストテーブル２（２６）、および位置リストテーブル２３を設定する必要がある。
図２３は、ＤＮＳサーバ（ＤＮＳ１）のサーバリストテーブル２１の一例を示す図である。
図２４は、ＤＮＳサーバ（ＤＮＳ１）のアドミッションコントロールリストテーブル１（２５）の一例を示す図である。
図２５は、ＤＮＳサーバ（ＤＮＳ１）のアドミッションコントロールリストテーブル２（２６）の一例を示す図である。
図２６は、ＤＮＳサーバ（ＤＮＳ１）の位置リストテーブル２３の一例を示す図である。
上記のリスト中で、拠点ＨＩＲＯＳＨＩＭＡに関する記述を行ってない。
これは、以下の理由による。
【００３３】
図２０に示すＤＮＳサーバのシーケンスによれば、ＤＮＳサーバ（ＤＮＳ２）をローカルＤＮＳとしている拠点（ＯＳＡＫＡ、ＨＩＲＯＳＨＩＭＡ）に属するクライアントからの名前解決は、ＤＮＳサーバ（ＤＮＳ２）を経由して、ＤＮＳサーバ（ＤＮＳ１）にアクセスされ、その際、ＤＮＳサーバ（ＤＮＳ１）がクライアントのアドレスとして認識するのは、ＤＮＳサーバ（ＤＮＳ２）のアドレス（２００．１５０．１．１００）である。
表１によれば、ＤＮＳサーバ（ＤＮＳ２）は拠点ＯＳＡＫＡに属するため、ＯＳＡＫＡ、ＨＩＲＯＳＨＩＭＡどちらに属するクライアントからの名前解決要求もＤＮＳサーバ（ＤＮＳ１）から見ると、すべてＤＮＳサーバ（ＤＮＳ２）からの名前解決要求に見えるため、ＤＮＳサーバ（ＤＮＳ１）においてＨＩＲＯＳＨＩＭＡに関する設定は不要である。
また、図２３に示すサーバリストテーブル２１において、拠点ＯＳＡＫＡに属するサーバが記載されていないが、これはＤＮＳサーバ（ＤＮＳ１）をローカルＤＮＳとしている拠点（ＴＯＫＹＯ、ＮＡＧＯＹＡ、ＳＥＡＴＬＥ）に対して拠点ＯＳＡＫＡに存在するサーバを選択することが、アクセスポリシ上有り得ないため省略している。
【００３４】
続いて、ＤＮＳサーバ（ＤＮＳ２）の設定について説明する。
ＤＮＳサーバ（ＤＮＳ２）においては、サーバリストテーブル２１、アドミッションコントロールリストテーブル２２、および位置リストテーブル２３を設定する必要がある。
図２７は、ＤＮＳサーバ（ＤＮＳ２）のサーバリストテーブル２１の一例を示す図である。
図２８は、ＤＮＳサーバ（ＤＮＳ２）のアドミッションコントロールリストテーブル２２の一例を示す図である。
図２９は、ＤＮＳサーバ（ＤＮＳ２）の位置リストテーブル２３の一例を示す図である。
上記のリスト中でホスト名がｓｅｒｖｅｒ１００．ｃｏｍとなっているが、これはＤＮＳサーバ（ＤＮＳ１）のアドミッションコントロールリストテーブル２（２６）（図２４参照）において、ＤＮＳサーバ（ＤＮＳ２）にサーバ選択処理を委譲されるものについては、ホスト名ｓｅｒｖｅｒ１．ｃｏｍの別名としてｓｅｒｖｅｒ１００．ｃｏｍが与えられるような設定になっているためである。
ここで、当システムの動作例を示す。
表３に動作例を説明するためのクライアントを定義する。
【００３５】
【表３】
まず、クライアントＣ１が、ホスト名ｓｅｒｖｅｒ１．ｃｏｍの名前解決要求を行った場合の処理について説明する。
クライアントＣ１は、拠点ＴＯＫＹＯに属するため、名前解決のため、初めにＤＮＳサーバ（ＤＮＳ１）に問い合わせる。
ＤＮＳサーバ（ＤＮＳ１）において、クライアントＣ１の拠点（ＩＰアドレス：１００．１５０．１．３４）を、図２６に示す位置リストテーブル２３から取得する。その結果、クライアントＣ１は、拠点ＴＯＫＹＯに属すると判断される。
ＤＮＳサーバ（ＤＮＳ１）において、ホスト名ｓｅｒｖｅｒ１．ｃｏｍに対応するアドミッションコントロールリスト１を抽出し、クライアントの位置がＴＯＫＹＯ、または＊（どれでも良い）で記述されているエントリーを検索する。
図２４に示すアドミッションコントロールリストテーブル１（２５）の上１行目に、クライアント位置＝ＴＯＫＹＯ、処理内容＝ａｌｌｏｗとあるので、クライアントＣ１に対しては、ＤＮＳサーバ（ＤＮＳ１）でサーバ選択処理を実施すると判断される。
次に、図２３に示すサーバリストテーブル２１に記載のサーバすべてについて、図２５に示すアドミッションコントロールリストテーブル２（２６）により、クライアントＣ１にアクセスさせて良いサーバか否かを判断する。
【００３７】
図２３に示すサーバリストテーブル２１に記載されている、コンテンツ配信サーバ（Ｓ１−１，Ｓ１−２，Ｓ１−３）は、共に拠点ＴＯＫＹＯに属するコンテンツ配信サーバである。
図２５に示すアドミッションコントロールリストテーブル２（２６）の上１行目によれば、サーバの位置＝ＴＯＫＹＯ、クライアントの位置＝ＴＯＫＹＯの場合処理内容＝ａ１１ｏｗとなっているため、これら３つのサーバは選択候補であると判断される。
図２３に示すサーバリストテーブル２１に記載されている、コンテンツ配信サーバ（Ｓ２−１）は、拠点ＮＡＧＯＹＡに属するコンテンツ配信サーバである。
アドミッションコントロールリストテーブル２（２６）によれば、サーバの位置＝ＮＡＧＯＹＡ、クライアントの位置＝ＴＯＫＹＯであるエントリーが存在しないため、明示されていないサーバの位置＝＊、クライアントの位置＝＊、処理内容＝ｄｅｎｙが適用される。従って、このサーバは選択候補から除外される。
即ち、クライアントＣ１に対しては、コンテンツ配信サーバ（Ｓ１−１，Ｓ１−２，Ｓ１−３）がサーバ選択候補となる。
サーバ選択部１３において、これら３つのサーバの中から１つのコンテンツ配信サーバを選択し、クライアントに選択されたサーバのＩＰアドレスを返す。
【００３８】
次に、クライアントＣ２が、ホスト名ｓｅｒｖｅｒ１．ｃｏｍの名前解決要求を行った場合の処理について説明する。
クライアントＣ２は、拠点ＨＩＲＯＳＨＩＭＡに属するため、名前解決のため初めにＤＮＳサーバ（ＤＮＳ２）に問い合わせる。
ＤＮＳサーバ（ＤＮＳ２）では、ｓｅｒｖｅｒ１．ｃｏｍについて解決できないため、ＤＮＳサーバ（ＤＮＳ２）が、ＤＮＳサーバ（ＤＮＳ１）に対しｓｅｒｖｅｒ１．ｃｏｍについて問い合わせる。
ＤＮＳサーバ（ＤＮＳ１）からみると、この問い合わせはあくまでＤＮＳサーバ（ＤＮＳ２）からの問い合わせであるため、ＤＮＳサーバ（ＤＮＳ２）のＩＰアドレス（２００．１５０．１．１００）の拠点を、図２６に示す位置リストテーブル２３から取得する。その結果、ＤＮＳサーバ（ＤＮＳ２）は、拠点ＯＳＡＫＡに属すると判断される。
続いて、ＤＮＳサーバ（ＤＮＳ１）において、ホスト名ｓｅｒｖｅｒ１．ｃｏｍに対応するアドミッションコントロールリスト１を抽出し、クライアントの位置がＯＳＡＫＡまたは＊（どれでも良い）で記述されているエントリーを検索する。
【００３９】
図２４に示すアドミッションコントロールリストテーブル１（２５）の上４行目に、クライアント位置＝ＯＳＡＫＡ、処理内容＝ｓｅｒｖｅｒ１００．ｃｏｍとあるので、クライアントＣ２に対しては、ＤＮＳサーバ（ＤＮＳ１）でサーバ選択処理を行わず、他のサーバ選択装置にてサーバ選択処理を実施すると判断される。
この処理内容に記載された文字列ｓｅｒｖｅｒ１００．ｃｏｍをｓｅｒｖｅｒ１．ｃｏｍの別名としてＤＮＳサーバ（ＤＮＳ２）に返す。
ＤＮＳサーバ（ＤＮＳ２）は、受け取ったホスト名ｓｅｒｖｅｒ１００．ｃｏｍをクライアントＣ２に返信する。
クライアントＣ２は、ホスト名ｓｅｒｖｅｒ１００．ｃｏｍの名前解決を行うためにＤＮＳサーバ（ＤＮＳ２）にアクセスする。
ＤＮＳサーバ（ＤＮＳ２）では、図２９に示す位置リストテーブル２３からクライアントＣ２の拠点名がＨＩＲＯＳＨＩＭＡであると判定される。
次に、図２７に示すサーバリストテーブル２１に記載されている、ホスト名ｓｅｒｖｅｒ１００．ｃｏｍに対応するサーバすべてについて、図２８に示すアドミッションコントロールリストテーブル２２により、クライアントＣ２にアクセスさせて良いサーバが否かを判断する。
【００４０】
図２７に示すサーバリストテーブルに記載のサーバは、拠点ＴＯＫＹＯにあるか拠点ＯＳＡＫＡにあるかのいずれかである。
図２８に示すアドミッションコントロールリストテーブル２２の３行目に、クライアントの位置＝ＨＩＲＯＳＨＩＭＡ、サーバの位置＝ＯＳＡＫＡ、処理内容＝ａｌｌｏｗと記載されているが、それ以外にクライアントの位置＝ＨＩＲＯＳＨＩＭＡであるエントリーは存在しないため、明示されていないサーバの位置＝＊、クライアントの位置＝＊、処理内容＝ｄｅｎｙが適用される。
従って、サーバの位置＝ＯＳＡＫＡである、コンテンツ配信サーバ（Ｓ３−１，Ｓ３−２）については、サーバ選択候補と判断され、サーバの位置＝ＴＯＫＹＯである、コンテンツ配信サーバ（Ｓ１−１，Ｓ１−２，Ｓ１−３）は、サーバ選択候補から除外されると判断される。
即ち、クライアントＣ２に対しては、コンテンツ配信サーバ（Ｓ３−１，Ｓ３−２）がサーバ選択候補となる。
サーバ選択部１３において、これら２つのコンテンツ配信サーバの中から１つのコンテンツ配信サーバが選択され、クライアントＣ２に、選択されたコンテンツ配信サーバのＩＰアドレスが返送される。
【００４１】
次に、クライアントＣ３が、ホスト名ｓｅｒｖｅｒ１．ｃｏｍの名前解決要求を行った場合の処理について説明する。
クライアントＣ３は、拠点ＳＥＡＴＬＥに属するため、名前解決のため初めにＤＮＳサーバ（ＤＮＳ１）に問い合わせる。
ＤＮＳサーバ（ＤＮＳ１）において、クライアントＣ３の拠点（ＩＰアドレス：１０．１０．５．５６）を、図２６に示す位置リストテーブル２３から取得する。その結果、クライアントＣ３は拠点ＳＥＡＴＬＥに属すると判断される。
ＤＮＳサーバ（ＤＮＳ１）において、ホスト名ｓｅｒｖｅｒ１．ｃｏｍに対応するアドミッションコントロールリスト１を抽出し、クライアントの位置がＳＥＡＴＬＥまたは＊（どれでも良い）で記述されているエントリーを検索する。
図２４に示すアドミッションコントロールリストテーブル１（２５）の上３行目に、クライアント位置＝ＳＥＡＴＬＥ、処理内容＝ｄｅｎｙとあるので、クライアントＣ３に対しては、ＤＮＳサーバ（ＤＮＳ１）でサーバ選択処理を実施しないと判断される。
【００４２】
従って、クライアントＣ１に対しては、ｓｅｒｖｅｒ１．ｃｏｍの名前解決が行えなかった旨を通知する。
上記の例からもわかる通り、実施の形態３の構成で適切に設定を行うことにより、想定したアクセスポリシを守ることが可能であることがわかる。
なお、前述したように、本発明のサーバ選択装置は、汎用コンピュータ上のソフトウェアで実現されるものである。
即ち、サーバ選択プログラムを、コンピュータのＣＰＵが実行することにより、前述の各実施の形態のサーバ選択方法の処理が行われる。ここで、このサーバ選択プログラムは、ＣＤ−ＲＯＭ等の記録媒体、あるいは、ネットワークを介したダウンロードにより供給される。
以上、本発明者によってなされた発明を、前記実施の形態に基づき具体的に説明したが、本発明は、前記実施の形態に限定されるものではなく、その要旨を逸脱しない範囲において種々変更可能であることは勿論である。
【００４３】
【発明の効果】
本願において開示される発明のうち代表的なものによって得られる効果を簡単に説明すれば、下記の通りである。
本発明によれば、クライアント位置情報に基づき選択候補サーバを絞り込む、あるいはサーバ選択の受付可否判断、他のサーバ選択サーバヘサーバ選択処理を委譲することが可能となり、複雑なアクセスポリシに対応した動作が可能となる。
【図面の簡単な説明】
【図１】 本発明の参考例のサーバ選択装置の概略構成を示すブロック図である。
【図２】 本発明のサーバ選択装置の一例の概略構成を示すブロック図である。
【図３】本発明の実施の形態１のサーバ選択装置の概略構成を示すブロック図である。
【図４】図３に示すサーバリストテーブルの一例を示す図である。
【図５】図３に示すアドミッションコントロールリストテーブルの一例を示す図である。
【図６】図３に示す位置リストテーブルの一例を示す図である。
【図７】図３に示すサーバ選択処理絞り込み取得部の処理手順を示すフローチャートである。
【図８】本発明の実施の形態１において、抽出されたサーバリストの一例を示す図である。
【図９】本発明の実施の形態１において、抽出されたアドミッションコントロールリストの一例を示す図である。
【図１０】本発明の実施の形態１のサーバ選択装置の変形例の、サーバリストテーブルの一例を示す図である。
【図１１】本発明の実施の形態１のサーバ選択装置の変形例の、アドミッションコントロールリストテーブルの一例を示す図である。
【図１２】本発明の実施の形態１のサーバ選択装置の変形例の、ｈｔｔｐリダイレクトメッセージの一例を示す図である。
【図１３】本発明の実施の形態２のサーバ選択装置の概略構成を示すブロック図である。
【図１４】図１３に示すアドミッションコントロールリストテーブルの一例を示す図である。
【図１５】本発明の実施の形態２において、抽出されたアドミッションコントロールリストの一例を示す図である。
【図１６】本発明の実施の形態２のサーバ選択装置の変形例の、アドミッションコントロールリストテーブルの一例を示す図である。
【図１７】本発明の実施の形態２のサーバ選択装置の変形例の、ｈｔｔｐリダイレクトメッセージの一例を示す図である。
【図１８】本発明の実施の形態３のサーバ選択装置が適用されるネットワーク構成を示すブロックである。
【図１９】本発明の実施の形態３のサーバ選択装置のアクセスポリシの一例を示す図である。
【図２０】本発明の実施の形態３におけるＤＮＳシーケンスを示す図である。
【図２１】本発明の実施の形態３における通常のＤＮＳサーバを説明するためのブロック図である。
【図２２】本発明の実施の形態のサーバ選択装置（ＤＮＳサーバ（ＤＮＳ１））の概略構成を示すブロック図である。
【図２３】本発明の実施の形態３のサーバ選択装置のサーバリストテーブルの一例を示す図である。
【図２４】本発明の実施の形態３のサーバ選択装置のアドミッションコントロールリストテーブル１の一例を示す図である。
【図２５】本発明の実施の形態３のサーバ選択装置のアドミッションコントロールリストテーブル２の一例を示す図である。
【図２６】本発明の実施の形態３のサーバ選択装置の位置リストテーブルの一例を示す図である。
【図２７】本発明の実施の形態３のＤＮＳサーバ（ＤＮＳ２）のサーバリストテーブルの一例を示す図である。
【図２８】本発明の実施の形態３のＤＮＳサーバ（ＤＮＳ２）のアドミッションコントロールリストテーブルの一例を示す図である。
【図２９】本発明の実施の形態３のＤＮＳサーバ（ＤＮＳ２）の位置リストテーブルの一例を示す図である。
【符号の説明】
１…サーバ選択要求情報受信手段、２…サーバリスト取得手段、３…サーバ選択処理候補絞り込み手段、５…サーバ選択手段、６…サーバ選択処理受付可否判断手段、７…サーバ選択結果情報通知手段、１０，３０…ＤＮＳクエリ受信部、１１…サーバリスト取得部、１２…サーバ選択処理候補絞り込み取得部、１３…サーバ選択部、１５，３２…ＤＮＳレスポンス送信部、１６…サーバ選択処理受付可否判断部、２１…サーバリストテーブル、２２…アドミッションコントロールリストテーブル、２３…位置リストテーブル、２５…アドミッションコントロールリストテーブル１、２６…アドミッションコントロールリストテーブル２、３１…マスターファイル参照部、３３…マスターファイル、３５…サーバ選択処理部、Ｒ１〜Ｒ５…ルータ、ＤＮＳ１，ＤＮＳ２…ＤＮＳサーバ、Ｓ１−１，Ｓ１−２，Ｓ１−３，Ｓ２−１，Ｓ３−１，Ｓ３−２…コンテンツ配信サーバ。
Claims (13)
- 複数のサーバの中からクライアントにアクセスさせるサーバを選択するサーバ選択方法であって、
サービス識別情報と、当該サービスを提供する複数のサーバの識別情報および位置情報との対応関係について記述したサーバリストテーブルと、
回線の細いネットワークに接続している拠点に属するクライアントからサーバへのアクセスを禁止し、または、多くのサーバを有する拠点に属するクライアントから他の拠点のサーバへのアクセスを禁止し、あるいは、サーバが無いか少ない拠点に属するクライアントから、自拠点から１リンクでたどり着け、かつ、そのリンクの帯域が最も大きい拠点のサーバへのアクセスを許可するというアクセスポリシに基づき記述され、クライアントの位置情報と、当該位置情報を持つクライアントに対して、サーバ選択処理を継続するか否か、あるいは、他のサーバ選択装置に処理を委譲するかを、サービス識別情報毎に指定したアドミッションコントロールリストテーブルとを備え、
クライアント位置情報、およびサービス識別情報を含むサーバ選択要求情報を受信する第１のステップと、
前記第１のステップで受信した前記サーバ選択要求情報に含まれるクライアント位置情報、およびサービス識別情報に基づき、前記アドミッションコントロールリストテーブルを参照し、当該クライアントに対する処理を判断する第２のステップと、
前記第２のステップにおいて、サーバ選択処理を継続すると判断された場合、前記サーバ選択要求情報に含まれるサービス識別情報に基づき、前記サーバリストテーブルを参照し、前記サービス識別情報に対応した位置情報を持つサーバを取得する第３のステップと、
前記第３のステップで取得されたサーバの中から、前記クライアントにアクセスさせるサーバを選択する第４のステップと、
前記第２のステップにおいて、サーバ選択処理を中断すると判断された場合、あるいは、サーバ選択処理を他のサーバ選択装置に委譲すると判断された場合、前記クライアントに対しサーバ選択処理を中断したことを示すサーバ選択結果情報、あるいは、前記クライアントに対し他のサーバ選択装置にアクセスするよう促すサーバ選択結果情報を通知する第５のステップとを有することを特徴とするサーバ選択方法。 - 複数のサーバの中からクライアントにアクセスさせるサーバを選択するサーバ選択方法であって、
サービス識別情報と、当該サービスを提供する複数のサーバの識別情報および位置情報との対応関係について記述したサーバリストテーブルと、
多くのサーバを有する拠点に属するクライアントから他の拠点のサーバへのアクセスを禁止し、あるいは、サーバが無いか少ない拠点に属するクライアントから、自拠点から１リンクでたどり着け、かつ、そのリンクの帯域が最も大きい拠点のサーバへのアクセスを許可するというアクセスポリシに基づき記述され、サーバの位置情報と、当該位置情報を持つサーバに対してアクセスしても良いクライアントの位置情報、あるいはアクセスしてはならないクライアント位置情報との対応関係について記述した第１のアドミッションコントロールリストテーブルと、
回線の細いネットワークに接続している拠点に属するクライアントからサーバへのアクセスを禁止し、または、多くのサーバを有する拠点に属するクライアントから他の拠点のサーバへのアクセスを禁止し、あるいは、サーバが無いか少ない拠点に属するクライアントから、自拠点から１リンクでたどり着け、かつ、そのリンクの帯域が最も大きい拠点のサーバへのアクセスを許可するというアクセスポリシに基づき記述され、クライアントの位置情報と、当該位置情報を持つクライアントに対して、サーバ選択処理を継続するか否か、あるいは、他のサーバ選択装置に処理を委譲するかを、サービス識別情報毎に指定した第２のアドミッションコントロールリストテーブルとを備え、
クライアント位置情報、およびサービス識別情報を含むサーバ選択要求情報を受信する第１のステップと、
前記第１のステップで受信した前記サーバ選択要求情報に含まれるクライアント位置情報およびサービス識別情報に基づき、前記第２のアドミッションコントロールリストテーブルを参照し、当該クライアントに対する処理を判断する第２のステップと、
前記第２のステップにおいて、サーバ選択処理を継続すると判断された場合、前記サーバ選択要求情報に含まれるサービス識別情報に基づき、前記サーバリストテーブルを参照し、前記サービス識別情報に対応した位置情報を持つサーバを取得する第３のステップと、
前記第３のステップで取得されたサーバの各々について、前記第１のアドミッションコントロールリストテーブルを参照し、前記クライアント位置情報および前記サーバ位置情報に基づき、当該サーバに当該クライアントをアクセスさせて良いか否か判定し、アクセスさせて良いサーバのみをサーバ選択候補とする第４のステップと、
前記第４のステップで絞り込まれた前記サーバ選択候補の中からクライアントにアクセスさせるサーバを選択する第５のステップと、
前記第２のステップにおいて、サーバ選択処理を中断すると判断された場合、あるいは、サーバ選択処理を他のサーバ選択装置に委譲すると判断された場合、前記クライアントに対しサーバ選択処理を中断したことを示すサーバ選択結果情報、あるいは、前記クライアントに対し他のサーバ選択装置にアクセスするよう促すサーバ選択結果情報を通知する第５のステップとを有することを特徴とするサーバ選択方法。 - 複数のサーバの中からクライアントにアクセスさせるサーバを選択するサーバ選択装置であって、
サービス識別情報と、当該サービスを提供する複数のサーバの識別情報および位置情報との対応関係について記述したサーバリストテーブルと、
回線の細いネットワークに接続している拠点に属するクライアントからサーバへのアクセスを禁止し、または、多くのサーバを有する拠点に属するクライアントから他の拠点のサーバへのアクセスを禁止し、あるいは、サーバが無いか少ない拠点に属するクライアントから、自拠点から１リンクでたどり着け、かつ、そのリンクの帯域が最も大きい拠点のサーバへのアクセスを許可するというアクセスポリシに基づき記述され、クライアントの位置情報と、当該位置情報を持つクライアントに対して、サーバ選択処理を継続するか否か、あるいは、他のサーバ選択装置に処理を委譲するかを、サービス識別情報毎に指定したアドミッションコントロールリストテーブルと、
クライアント位置情報、およびサービス識別情報を含むサーバ選択要求情報を受信するサーバ選択要求情報受信手段と、
前記サーバ選択要求情報受信手段で受信した前記サーバ選択要求情報に含まれるクライアント位置情報、およびサービス識別情報に基づき、前記アドミッションコントロールリストテーブルを参照し、当該クライアントに対する処理を判断するサーバ選択処理受付可否判断手段と、
前記サーバ選択処理受付可否判断手段において、サーバ選択処理を継続すると判断された場合、前記サーバ選択要求情報に含まれるサービス識別情報に基づき、前記サーバリストテーブルを参照し、前記サービス識別情報に対応した位置情報を持つサーバを取得するサーバリスト取得手段と、
前記リスト取得手段で取得されたサーバの中から、前記クライアントにアクセスさせるサーバを選択するサーバ選択手段と、
前記サーバ選択処理受付可否判断手段において、サーバ選択処理を中断すると判断された場合、あるいは、サーバ選択処理を他のサーバ選択装置に委譲すると判断された場合、前記クライアントに対しサーバ選択処理を中断したことを示すサーバ選択結果情報、あるいは、前記クライアントに対し他のサーバ選択装置にアクセスするよう促すサーバ選択結果情報を通知するサーバ選択結果情報通知手段とを有することを特徴とするサーバ選択装置。 - 前記アドミッションコントロールリストに記載のクライアント位置情報は、ＩＰアドレスの領域で示されることを特徴とする請求項４に記載のサーバ選択装置。
- 複数のサーバの中からクライアントにアクセスさせるサーバを選択するサーバ選択装置であって、
サービス識別情報と、当該サービスを提供する複数のサーバの識別情報および位置情報との対応関係について記述したサーバリストテーブルと、
多くのサーバを有する拠点に属するクライアントから他の拠点のサーバへのアクセスを禁止し、あるいは、サーバが無いか少ない拠点に属するクライアントから、自拠点から１リンクでたどり着け、かつ、そのリンクの帯域が最も大きい拠点のサーバへのアクセスを許可するというアクセスポリシに基づき記述され、サーバの位置情報と、当該位置情報を持つサーバに対してアクセスしても良いクライアントの位置情報、あるいはアクセスしてはならないクライアントの位置情報との対応関係について記述した第１のアドミッションコントロールリストテーブルと、
回線の細いネットワークに接続している拠点に属するクライアントからサーバへのアクセスを禁止し、または、多くのサーバを有する拠点に属するクライアントから他の拠点のサーバへのアクセスを禁止し、あるいは、サーバが無いか少ない拠点に属するクライアントから、自拠点から１リンクでたどり着け、かつ、そのリンクの帯域が最も大きい拠点のサーバへのアクセスを許可するというアクセスポリシに基づき記述され、クライアントの位置情報と、当該位置情報を持つクライアントに対して、サーバ選択処理を継続するか否か、あるいは、他のサーバ選択装置に処理を委譲するかを、サービス識別情報毎に指定した第２のアドミッションコントロールリストテーブルと、
クライアント位置情報、およびサービス識別情報を含むサーバ選択要求情報を受信するサーバ選択要求情報受信手段と、
前記サーバ選択要求情報受信手段で受信した前記サーバ選択要求情報に含まれるクライアント位置情報およびサービス識別情報に基づき、前記第２のアドミッションコントロールリストテーブルを参照し、当該クライアントに対する処理を判断するサーバ選択処理受付可否判断手段と、
前記サーバ選択処理受付可否判断手段において、サーバ選択処理を継続すると判断された場合、前記サーバ選択要求情報に含まれるサービス識別情報に基づき、前記サーバリストテーブルを参照し、前記サービス識別情報に対応した位置情報を持つサーバを取得するサーバリスト取得手段と、
前記サーバリスト取得手段で取得されたサーバの各々について、前記第１のアドミッションコントロールリストテーブルを参照し、前記クライアント位置情報および前記サーバ位置情報に基づき、当該サーバに当該クライアントをアクセスさせて良いか否か判定し、アクセスさせて良いサーバのみをサーバ選択候補とするサーバ選択処理候補絞り込み手段と、
前記サーバ選択処理候補絞り込み手段によって絞り込まれた前記サーバ選択候補の中からクライアントにアクセスさせるサーバを選択するサーバ選択手段と、
前記サーバ選択処理受付可否判断手段において、サーバ選択処理を中断すると判断された場合、あるいは、サーバ選択処理を他のサーバ選択装置に委譲すると判断された場合、前記クライアントに対しサーバ選択処理を中断したことを示すサーバ選択結果情報、あるいは、前記クライアントに対し他のサーバ選択装置にアクセスするよう促すサーバ選択結果情報を通知するサーバ選択結果情報通知手段とを有することを特徴とするサーバ選択装置。 - 前記第１のアドミッションコントロールリストに記載のサーバ位置情報は、ＩＰアドレスの領域で示されることを特徴とする請求項５に記載のサーバ選択装置。
- 前記第１および第２のアドミッションコントロールリストに記載のクライアントの位置情報は、ＩＰアドレスの領域で示されることを特徴とする請求項５または請求項６に記載のサーバ選択装置。
- サーバ識別情報は、ＩＰアドレス、ホスト名、あるいはＵＲＬであることを特徴とする請求項３ないし請求項７のいずれか１項に記載のサーバ選択装置。
- サービス識別情報は、ＩＰアドレス、ホスト名、あるいはＵＲＬであることを特徴とする請求項３ないし請求項８のいずれか１項に記載のサーバ選択装置。
- クライアント位置情報は、ＩＰアドレスであることを特徴とする請求項３ないし請求項９のいずれか１項に記載のサーバ選択装置。
- 複数のサーバの中からクライアントにアクセスさせるサーバを選択するサーバ選択方法をコンピュータに実行させるサーバ選択プログラムであって、
前記サーバ選択プログラムは、コンピュータに、クライアント位置情報、およびサービス識別情報を含むサーバ選択要求情報を受信させる手順１と、
前記手順１で受信させた前記サーバ選択要求情報に含まれるクライアント位置情報、およびサービス識別情報に基づき、回線の細いネットワークに接続している拠点に属するクライアントからサーバへのアクセスを禁止し、または、多くのサーバを有する拠点に属するクライアントから他の拠点のサーバへのアクセスを禁止し、あるいは、サーバが無いか少ない拠点に属するクライアントから、自拠点から１リンクでたどり着け、かつ、そのリンクの帯域が最も大きい拠点のサーバへのアクセスを許可するというアクセスポリシに基づき記述され、クライアントの位置情報と、当該位置情報を持つクライアントに対して、サーバ選択処理を継続するか否か、あるいは、他のサーバ選択装置に処理を委譲するかを、サービス識別情報毎に指定したアドミッションコントロールリストテーブルを参照させ、当該クライアントに対する処理を判断させる手順２と、
前記手順２において、サーバ選択処理を継続すると判断された場合、前記サーバ選択要求情報に含まれるサービス識別情報に基づき、サービス識別情報と、当該サービスを提供する複数のサーバの識別情報および位置情報との対応関係について記述したサーバリストテーブルを参照させ、前記サービス識別情報に対応した位置情報を持つサーバを取得させる手順３と、
前記手順３で取得させたサーバの中から、前記クライアントにアクセスさせるサーバを選択させる手順４と、
前記手順２において、サーバ選択処理を中断すると判断された場合、あるいは、サーバ選択処理を他のサーバ選択装置に委譲すると判断された場合、前記クライアントに対しサーバ選択処理を中断したことを示すサーバ選択結果情報、あるいは、前記クライアントに対し他のサーバ選択装置にアクセスするよう促すサーバ選択結果情報を通知させる手順５とを実行させることを特徴とするサーバ選択プログラム。 - 複数のサーバの中からクライアントにアクセスさせるサーバを選択するサーバ選択方法をコンピュータに実行させるサーバ選択プログラムであって、
前記サーバ選択プログラムは、コンピュータに、クライアント位置情報、およびサービス識別情報を含むサーバ選択要求情報を受信させる手順１と、
前記手順１で受信させた前記サーバ選択要求情報に含まれるクライアント位置情報およびサービス識別情報に基づき、回線の細いネットワークに接続している拠点に属するクライアントからサーバへのアクセスを禁止し、または、多くのサーバを有する拠点に属するクライアントから他の拠点のサーバへのアクセスを禁止し、あるいは、サーバが無いか少ない拠点に属するクライアントから、自拠点から１リンクでたどり着け、かつ、そのリン クの帯域が最も大きい拠点のサーバへのアクセスを許可するというアクセスポリシに基づき記述され、クライアントの位置情報と、当該位置情報を持つクライアントに対して、サーバ選択処理を継続するか否か、あるいは、他のサーバ選択装置に処理を委譲するかを、サービス識別情報毎に指定した第２のアドミッションコントロールリストテーブルを参照させ、当該クライアントに対する処理を判断させる手順２と、
前記手順２において、サーバ選択処理を継続すると判断された場合、前記サーバ選択要求情報に含まれるサービス識別情報に基づき、サービス識別情報と、当該サービスを提供する複数のサーバの識別情報および位置情報との対応関係について記述したサーバリストテーブルを参照させ、前記サービス識別情報に対応した位置情報を持つサーバを取得させる手順３と、
前記手順３で取得させたサーバの各々について、多くのサーバを有する拠点に属するクライアントから他の拠点のサーバへのアクセスを禁止し、あるいは、サーバが無いか少ない拠点に属するクライアントから、自拠点から１リンクでたどり着け、かつ、そのリンクの帯域が最も大きい拠点のサーバへのアクセスを許可するというアクセスポリシに基づき記述され、サーバの位置情報と、当該位置情報を持つサーバに対してアクセスしても良いクライアントの属性情報、あるいはアクセスしてはならないクライアントの属性情報との対応関係について記述した第１のアドミッションコントロールリストテーブルを参照させ、前記クライアント位置情報および前記サーバ位置情報に基づき、当該サーバに当該クライアントをアクセスさせて良いか否か判定させ、アクセスさせて良いサーバのみをサーバ選択候補とさせる手順４と、
前記手順４で絞り込まれた前記サーバ選択候補の中からクライアントにアクセスさせるサーバを選択させる手順５と、
前記手順２において、サーバ選択処理を中断すると判断された場合、あるいは、サーバ選択処理を他のサーバ選択装置に委譲すると判断された場合、前記クライアントに対しサーバ選択処理を中断したことを示すサーバ選択結果情報、あるいは、前記クライアントに対し他のサーバ選択装置にアクセスするよう促すサーバ選択結果情報を通知させる手順６とを実行させることを特徴とするサーバ選択プログラム。 - 請求項１１または請求項１２に記載されたサーバ選択プログラムを記録した記録媒体。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2001366538A JP4040292B2 (ja) | 2001-11-30 | 2001-11-30 | サーバ選択方法、サーバ選択装置、サーバ選択プログラム、および、記録媒体 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2001366538A JP4040292B2 (ja) | 2001-11-30 | 2001-11-30 | サーバ選択方法、サーバ選択装置、サーバ選択プログラム、および、記録媒体 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2003167810A JP2003167810A (ja) | 2003-06-13 |
| JP4040292B2 true JP4040292B2 (ja) | 2008-01-30 |
Family
ID=19176417
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2001366538A Expired - Lifetime JP4040292B2 (ja) | 2001-11-30 | 2001-11-30 | サーバ選択方法、サーバ選択装置、サーバ選択プログラム、および、記録媒体 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP4040292B2 (ja) |
Families Citing this family (100)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8458754B2 (en) | 2001-01-22 | 2013-06-04 | Sony Computer Entertainment Inc. | Method and system for providing instant start multimedia content |
| CN100389575C (zh) * | 2005-07-13 | 2008-05-21 | 华为技术有限公司 | 一种实现网上设备接入管理的方法 |
| JP4689638B2 (ja) * | 2007-03-30 | 2011-05-25 | 日本電信電話株式会社 | シナリオ分割制御方法、シナリオサーバ装置及びシナリオサーバプログラム |
| US8028090B2 (en) | 2008-11-17 | 2011-09-27 | Amazon Technologies, Inc. | Request routing utilizing client location information |
| US7991910B2 (en) | 2008-11-17 | 2011-08-02 | Amazon Technologies, Inc. | Updating routing information based on client location |
| US9483405B2 (en) | 2007-09-20 | 2016-11-01 | Sony Interactive Entertainment Inc. | Simplified run-time program translation for emulating complex processor pipelines |
| EP2241087A1 (en) * | 2008-01-23 | 2010-10-20 | Telefonaktiebolaget L M Ericsson (publ) | Method and apparatus for pooling network resources |
| US7970820B1 (en) | 2008-03-31 | 2011-06-28 | Amazon Technologies, Inc. | Locality based content distribution |
| US8321568B2 (en) | 2008-03-31 | 2012-11-27 | Amazon Technologies, Inc. | Content management |
| US8156243B2 (en) * | 2008-03-31 | 2012-04-10 | Amazon Technologies, Inc. | Request routing |
| US8606996B2 (en) | 2008-03-31 | 2013-12-10 | Amazon Technologies, Inc. | Cache optimization |
| US8601090B1 (en) | 2008-03-31 | 2013-12-03 | Amazon Technologies, Inc. | Network resource identification |
| US8447831B1 (en) | 2008-03-31 | 2013-05-21 | Amazon Technologies, Inc. | Incentive driven content delivery |
| US8533293B1 (en) | 2008-03-31 | 2013-09-10 | Amazon Technologies, Inc. | Client side cache management |
| US7962597B2 (en) | 2008-03-31 | 2011-06-14 | Amazon Technologies, Inc. | Request routing based on class |
| US7925782B2 (en) | 2008-06-30 | 2011-04-12 | Amazon Technologies, Inc. | Request routing using network computing components |
| US9407681B1 (en) | 2010-09-28 | 2016-08-02 | Amazon Technologies, Inc. | Latency measurement in resource requests |
| US9912740B2 (en) | 2008-06-30 | 2018-03-06 | Amazon Technologies, Inc. | Latency measurement in resource requests |
| US8732309B1 (en) | 2008-11-17 | 2014-05-20 | Amazon Technologies, Inc. | Request routing utilizing cost information |
| US8073940B1 (en) | 2008-11-17 | 2011-12-06 | Amazon Technologies, Inc. | Managing content delivery network service providers |
| US8060616B1 (en) | 2008-11-17 | 2011-11-15 | Amazon Technologies, Inc. | Managing CDN registration by a storage provider |
| US8122098B1 (en) | 2008-11-17 | 2012-02-21 | Amazon Technologies, Inc. | Managing content delivery network service providers by a content broker |
| US8521880B1 (en) | 2008-11-17 | 2013-08-27 | Amazon Technologies, Inc. | Managing content delivery network service providers |
| US8065417B1 (en) | 2008-11-17 | 2011-11-22 | Amazon Technologies, Inc. | Service provider registration by a content broker |
| US8688837B1 (en) | 2009-03-27 | 2014-04-01 | Amazon Technologies, Inc. | Dynamically translating resource identifiers for request routing using popularity information |
| US8412823B1 (en) | 2009-03-27 | 2013-04-02 | Amazon Technologies, Inc. | Managing tracking information entries in resource cache components |
| US8756341B1 (en) | 2009-03-27 | 2014-06-17 | Amazon Technologies, Inc. | Request routing utilizing popularity information |
| US8521851B1 (en) | 2009-03-27 | 2013-08-27 | Amazon Technologies, Inc. | DNS query processing using resource identifiers specifying an application broker |
| KR101560185B1 (ko) * | 2009-03-27 | 2015-10-15 | 삼성전자주식회사 | Ｕｒｌ을 이용한 분산 컨트롤 방법 및 장치 |
| US8782236B1 (en) | 2009-06-16 | 2014-07-15 | Amazon Technologies, Inc. | Managing resources using resource expiration data |
| US8433814B2 (en) * | 2009-07-16 | 2013-04-30 | Netflix, Inc. | Digital content distribution system and method |
| US8397073B1 (en) | 2009-09-04 | 2013-03-12 | Amazon Technologies, Inc. | Managing secure content in a content delivery network |
| US8433771B1 (en) | 2009-10-02 | 2013-04-30 | Amazon Technologies, Inc. | Distribution network with forward resource propagation |
| US8126987B2 (en) * | 2009-11-16 | 2012-02-28 | Sony Computer Entertainment Inc. | Mediation of content-related services |
| US9495338B1 (en) | 2010-01-28 | 2016-11-15 | Amazon Technologies, Inc. | Content distribution network |
| US8756272B1 (en) | 2010-08-26 | 2014-06-17 | Amazon Technologies, Inc. | Processing encoded content |
| US9003035B1 (en) | 2010-09-28 | 2015-04-07 | Amazon Technologies, Inc. | Point of presence management in request routing |
| US8938526B1 (en) | 2010-09-28 | 2015-01-20 | Amazon Technologies, Inc. | Request routing management based on network components |
| US8577992B1 (en) | 2010-09-28 | 2013-11-05 | Amazon Technologies, Inc. | Request routing management based on network components |
| US10958501B1 (en) | 2010-09-28 | 2021-03-23 | Amazon Technologies, Inc. | Request routing information based on client IP groupings |
| US8468247B1 (en) | 2010-09-28 | 2013-06-18 | Amazon Technologies, Inc. | Point of presence management in request routing |
| US10097398B1 (en) | 2010-09-28 | 2018-10-09 | Amazon Technologies, Inc. | Point of presence management in request routing |
| US8924528B1 (en) | 2010-09-28 | 2014-12-30 | Amazon Technologies, Inc. | Latency measurement in resource requests |
| US8819283B2 (en) | 2010-09-28 | 2014-08-26 | Amazon Technologies, Inc. | Request routing in a networked environment |
| US9712484B1 (en) | 2010-09-28 | 2017-07-18 | Amazon Technologies, Inc. | Managing request routing information utilizing client identifiers |
| US8930513B1 (en) | 2010-09-28 | 2015-01-06 | Amazon Technologies, Inc. | Latency measurement in resource requests |
| US8452874B2 (en) | 2010-11-22 | 2013-05-28 | Amazon Technologies, Inc. | Request routing processing |
| US8626950B1 (en) | 2010-12-03 | 2014-01-07 | Amazon Technologies, Inc. | Request routing processing |
| US9391949B1 (en) | 2010-12-03 | 2016-07-12 | Amazon Technologies, Inc. | Request routing processing |
| JP2012203430A (ja) * | 2011-03-23 | 2012-10-22 | Ricoh Co Ltd | 遠隔管理装置、遠隔管理システムおよび遠隔管理プログラム |
| US10467042B1 (en) | 2011-04-27 | 2019-11-05 | Amazon Technologies, Inc. | Optimized deployment based upon customer locality |
| US8904009B1 (en) | 2012-02-10 | 2014-12-02 | Amazon Technologies, Inc. | Dynamic content delivery |
| US10021179B1 (en) | 2012-02-21 | 2018-07-10 | Amazon Technologies, Inc. | Local resource delivery network |
| US9172674B1 (en) | 2012-03-21 | 2015-10-27 | Amazon Technologies, Inc. | Managing request routing information utilizing performance information |
| US10623408B1 (en) | 2012-04-02 | 2020-04-14 | Amazon Technologies, Inc. | Context sensitive object management |
| US9154551B1 (en) | 2012-06-11 | 2015-10-06 | Amazon Technologies, Inc. | Processing DNS queries to identify pre-processing information |
| JP2014026470A (ja) * | 2012-07-26 | 2014-02-06 | Toppan Printing Co Ltd | 情報管理サーバ、情報提供システム、情報提供方法、及び、情報提供プログラム |
| US9525659B1 (en) | 2012-09-04 | 2016-12-20 | Amazon Technologies, Inc. | Request routing utilizing point of presence load information |
| US9323577B2 (en) | 2012-09-20 | 2016-04-26 | Amazon Technologies, Inc. | Automated profiling of resource usage |
| US9135048B2 (en) | 2012-09-20 | 2015-09-15 | Amazon Technologies, Inc. | Automated profiling of resource usage |
| US10205698B1 (en) | 2012-12-19 | 2019-02-12 | Amazon Technologies, Inc. | Source-dependent address resolution |
| JP5940998B2 (ja) * | 2013-03-05 | 2016-06-29 | 日本電信電話株式会社 | メッセージ配信システムおよびその動作方法 |
| US9294391B1 (en) | 2013-06-04 | 2016-03-22 | Amazon Technologies, Inc. | Managing network computing components utilizing request routing |
| US10033627B1 (en) | 2014-12-18 | 2018-07-24 | Amazon Technologies, Inc. | Routing mode and point-of-presence selection service |
| US10097448B1 (en) | 2014-12-18 | 2018-10-09 | Amazon Technologies, Inc. | Routing mode and point-of-presence selection service |
| US10091096B1 (en) | 2014-12-18 | 2018-10-02 | Amazon Technologies, Inc. | Routing mode and point-of-presence selection service |
| US10225326B1 (en) | 2015-03-23 | 2019-03-05 | Amazon Technologies, Inc. | Point of presence based data uploading |
| US9887931B1 (en) | 2015-03-30 | 2018-02-06 | Amazon Technologies, Inc. | Traffic surge management for points of presence |
| US9819567B1 (en) | 2015-03-30 | 2017-11-14 | Amazon Technologies, Inc. | Traffic surge management for points of presence |
| US9887932B1 (en) | 2015-03-30 | 2018-02-06 | Amazon Technologies, Inc. | Traffic surge management for points of presence |
| JP6523768B2 (ja) * | 2015-04-28 | 2019-06-05 | Kddi株式会社 | 名前解決装置、名前解決方法及び名前解決プログラム |
| US9832141B1 (en) | 2015-05-13 | 2017-11-28 | Amazon Technologies, Inc. | Routing based request correlation |
| JP6251702B2 (ja) | 2015-05-26 | 2017-12-20 | エヌ・ティ・ティ・コミュニケーションズ株式会社 | 接続先サーバ指示装置、サービス利用システム、接続先サーバ指示方法、及びプログラム |
| US10616179B1 (en) | 2015-06-25 | 2020-04-07 | Amazon Technologies, Inc. | Selective routing of domain name system (DNS) requests |
| US10097566B1 (en) | 2015-07-31 | 2018-10-09 | Amazon Technologies, Inc. | Identifying targets of network attacks |
| CN105162665B (zh) * | 2015-08-31 | 2019-01-11 | 小米科技有限责任公司 | 服务器接入方法及装置 |
| US9774619B1 (en) | 2015-09-24 | 2017-09-26 | Amazon Technologies, Inc. | Mitigating network attacks |
| US9742795B1 (en) | 2015-09-24 | 2017-08-22 | Amazon Technologies, Inc. | Mitigating network attacks |
| US9794281B1 (en) | 2015-09-24 | 2017-10-17 | Amazon Technologies, Inc. | Identifying sources of network attacks |
| US10270878B1 (en) | 2015-11-10 | 2019-04-23 | Amazon Technologies, Inc. | Routing for origin-facing points of presence |
| US10049051B1 (en) | 2015-12-11 | 2018-08-14 | Amazon Technologies, Inc. | Reserved cache space in content delivery networks |
| US10257307B1 (en) | 2015-12-11 | 2019-04-09 | Amazon Technologies, Inc. | Reserved cache space in content delivery networks |
| US10348639B2 (en) | 2015-12-18 | 2019-07-09 | Amazon Technologies, Inc. | Use of virtual endpoints to improve data transmission rates |
| CN105871591A (zh) * | 2015-12-21 | 2016-08-17 | 乐视云计算有限公司 | 一种分发cdn地址的方法及装置 |
| US10075551B1 (en) | 2016-06-06 | 2018-09-11 | Amazon Technologies, Inc. | Request management for hierarchical cache |
| US10110694B1 (en) | 2016-06-29 | 2018-10-23 | Amazon Technologies, Inc. | Adaptive transfer rate for retrieving content from a server |
| US9992086B1 (en) | 2016-08-23 | 2018-06-05 | Amazon Technologies, Inc. | External health checking of virtual private cloud network environments |
| US10033691B1 (en) | 2016-08-24 | 2018-07-24 | Amazon Technologies, Inc. | Adaptive resolution of domain name requests in virtual private cloud network environments |
| US10469513B2 (en) | 2016-10-05 | 2019-11-05 | Amazon Technologies, Inc. | Encrypted network addresses |
| US10372499B1 (en) | 2016-12-27 | 2019-08-06 | Amazon Technologies, Inc. | Efficient region selection system for executing request-driven code |
| US10831549B1 (en) | 2016-12-27 | 2020-11-10 | Amazon Technologies, Inc. | Multi-region request-driven code execution system |
| US10938884B1 (en) | 2017-01-30 | 2021-03-02 | Amazon Technologies, Inc. | Origin server cloaking using virtual private cloud network environments |
| JP6569692B2 (ja) | 2017-02-09 | 2019-09-04 | 日本電気株式会社 | 管理サーバ、通信システム、管理サーバの制御方法、及びプログラム |
| US10503613B1 (en) | 2017-04-21 | 2019-12-10 | Amazon Technologies, Inc. | Efficient serving of resources during server unavailability |
| US11075987B1 (en) | 2017-06-12 | 2021-07-27 | Amazon Technologies, Inc. | Load estimating content delivery network |
| US10447648B2 (en) | 2017-06-19 | 2019-10-15 | Amazon Technologies, Inc. | Assignment of a POP to a DNS resolver based on volume of communications over a link between client devices and the POP |
| US10742593B1 (en) | 2017-09-25 | 2020-08-11 | Amazon Technologies, Inc. | Hybrid content request routing system |
| US10592578B1 (en) | 2018-03-07 | 2020-03-17 | Amazon Technologies, Inc. | Predictive content push-enabled content delivery network |
| US10862852B1 (en) | 2018-11-16 | 2020-12-08 | Amazon Technologies, Inc. | Resolution of domain name requests in heterogeneous network environments |
| US11025747B1 (en) | 2018-12-12 | 2021-06-01 | Amazon Technologies, Inc. | Content request pattern-based routing system |
-
2001
- 2001-11-30 JP JP2001366538A patent/JP4040292B2/ja not_active Expired - Lifetime
Also Published As
| Publication number | Publication date |
|---|---|
| JP2003167810A (ja) | 2003-06-13 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4040292B2 (ja) | サーバ選択方法、サーバ選択装置、サーバ選択プログラム、および、記録媒体 | |
| US7747720B2 (en) | Arrangement for selecting a server to provide distributed services from among multiple servers based on a location of a client device | |
| US20210021692A1 (en) | Translation of resource identifiers using popularity information upon client request | |
| US20200195753A1 (en) | Request routing utilizing client location information | |
| JP5404766B2 (ja) | ルーティングをリクエストするための方法とシステム | |
| US7499998B2 (en) | Arrangement in a server for providing dynamic domain name system services for each received request | |
| JP6146950B2 (ja) | ネットワークコンピューティングコンポーネントを使用してルーティングをリクエストする方法およびシステム | |
| US7447798B2 (en) | Methods and systems for providing dynamic domain name system for inbound route control | |
| US9712422B2 (en) | Selection of service nodes for provision of services | |
| EP1303109B1 (en) | Resolving virtual network names | |
| US9871722B2 (en) | Content delivery network routing method, system and user terminal | |
| US7228359B1 (en) | Methods and apparatus for providing domain name service based on a client identifier | |
| US7043563B2 (en) | Method and system for redirection to arbitrary front-ends in a communication system | |
| US8412764B1 (en) | Methods and apparatus for processing client requests in a content distribution network using client lists | |
| US9954816B2 (en) | Delegation of content delivery to a local service | |
| US11252127B2 (en) | Systems and methods for processing requests for content of a content distribution network | |
| JP2008522464A (ja) | 端末要求をエージェントがリダイレクトする方法及びシステム | |
| CN106254576B (zh) | 一种报文转发方法及装置 | |
| JP2004310458A (ja) | 個人情報流通方法および個人情報管理システム並びにポリシー判定システム | |
| CN112565305B (zh) | 一种使用域名访问局域网设备的方法、系统及存储介质 | |
| KR100347985B1 (ko) | 인터넷 주소 부가정보 제공 시스템 및 방법 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20040316 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20061207 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20061219 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20070219 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20071106 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20071107 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20101116 Year of fee payment: 3 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 Ref document number: 4040292 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20101116 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20111116 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20111116 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20121116 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20121116 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20131116 Year of fee payment: 6 |
|
| S531 | Written request for registration of change of domicile |
Free format text: JAPANESE INTERMEDIATE CODE: R313531 |
|
| R350 | Written notification of registration of transfer |
Free format text: JAPANESE INTERMEDIATE CODE: R350 |
|
| EXPY | Cancellation because of completion of term |