(57)【要約】      （修正有）【課題】ネットワークにおいて分散サービスにアクセスする方法を提供する。【解決手段】各サーバが、（ａ）名前または他の識別子を有するサービスを提供し、（ｂ）組内の他のサーバのネットワーク・アドレスとは異なるネットワーク・アドレスを有し、（ｃ）クライアントから受信されたサービスの名前または他の識別子を、解決機構に対してローカルなネットワーク・アドレスにマップする解決機構と同じ位置に配置される、1組の複数のサーバ。解決機構は、クライアントが、現在、クライアントにサービスを提供するように作動しており、および／またはアクセス可能であるサーバの1つを選択し、かつクライアントが最初に、選択されるサーバにアクセスする必要のない、そのようなサーバを選択することを可能にするように操作される。【選択図】図４
2007207231.tif 000002
【特許請求の範囲】
【請求項１】
各サーバが、（a）名前または他の識別子を有するサービスを提供し、（b）組内の他のサーバのネットワーク・アドレスとは異なるネットワーク・アドレスを有し、（c）クライアントから受信された名前または他の識別子を、解決機構に対してローカルなネットワーク・アドレスにマップする解決機構と同じ位置に配置される、1組の複数のサーバについての、以下の段階を含む方法：
クライアントが、現在、クライアントにサービスを提供するように作動しており、および／またはアクセス可能であるサーバの1つを選択し、かつクライアントが最初に、選択されるサーバにアクセスする必要のない、そのようなサーバを選択することを可能にするように解決機構を操作する段階。
【請求項２】
サーバの選択は、解決機構によって使用されるプロトコルによって決まる、請求項1記載の方法。
【請求項３】
サーバの選択は、1つまたは複数のサーバの1つまたは複数の性能属性によって決まる、請求項1記載の方法。
【請求項４】
性能属性には、測定された応答時間またはクライアントへの解決機構の相対的な近さの尺度を含めてよい、請求項3記載の方法。
【請求項５】
サーバの性能属性は、クライアントに格納され時々に更新される、請求項3記載の方法。
【請求項６】
性能属性の更新は、自然に生じた解決要求から導かれる、請求項4記載の方法。
【請求項７】
クライアントによって選択されるサーバは、クライアントからの解決要求に最初に応答するサーバである、請求項1記載の方法。
【請求項８】
解決機構は、それと同じ位置に配置されているサーバと同じアドレスを有する、請求項1記載の方法。
【請求項９】
サービスへのアクセスは、任意の1つのサーバおよびそれと同じ位置に配置された解決機構が作用しており、および／またはアクセス可能である場合にクライアントによって得られる、請求項1記載の方法。
【請求項１０】
同じ位置に配置された解決機構およびサーバのいくつかはクラスタ化され、単一のネットワーク・アドレスを使用してアクセスすることができる、請求項1記載の方法。
【請求項１１】
サービスへのアクセスは、クラスタ内の少なくとも1つの解決機構およびクラスタ内の1つのサーバが作用しており、および／またはアクセス可能である場合にクライアントによって得られる、請求項8記載の方法。
【請求項１２】
サーバは、プロキシ・サーバを含む、請求項1記載の方法。
【請求項１３】
プロキシ・サーバはバックエンド・サービスにアクセスする、請求項11記載の方法。
【請求項１４】
ネーム・サービス・レジストリは、解決機構を妨げずにサーバのネットワーク・アドレスを手動で削除するのを可能にする、請求項1記載の方法。
【請求項１５】
所与のサーバと同じ位置に配置された解決機構は、サーバの状況をチェックし、サーバが利用不能であるときには、クライアントからの解決要求に対する応答を終了する、請求項1記載の方法。
【請求項１６】
解決機構が、クライアントからの妥当な入力コードを要求する、請求項1記載の方法。
【請求項１７】
妥当な入力コードを使用して、解決機構が応答すべきかどうかが判定される、請求項16記載の方法。
【請求項１８】
各サーバが名前または他の識別子を有するサービスを提供する1組の複数のサーバを含み、
各サーバは、組内の他のサーバのネットワーク・アドレスとは異なるネットワーク・アドレスを有し、クライアントから受信された名前または他の識別子を、解決機構に対してローカルなネットワーク・アドレスにマップする解決機構と同じ位置に配置され、
解決機構は、クライアントが、現在、クライアントにサービスを提供するように作動しており、およびアクセス可能であるサーバの1つを選択し、かつクライアントが最初に、選択されるサーバにアクセスする必要のない、そのようなサーバを識別するのを可能にするシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワークにおける分散サービスへのアクセスに関する。
【背景技術】
【０００２】
図1に示されているように、インターネット10は、ネットワーク、コンピュータ、およびサービスの分散システムである。インターネット内では、他の位置のサーバ28から提供されるサービスを必要とするクライアント12は、（これらの他の位置を識別する）インターネット・プロトコル（IP）アドレスを使用してサービス要求26をこれらのサーバに送信する。代表的なIPアドレスは、長さが32ビット（IPv4プロトコル）または128ビット（IPv6プロトコル）のどちらか一方である数である。
【０００３】
IPアドレスは、一般に任意の値であるものの、意味を有するドメイン／サブドメイン名に関連付けることができる。たとえば、hdl.handle.netなどのサブドメイン／ドメイン名をIPアドレスに関連付けることができる。ドメイン／サブドメイン名をIPアドレスに関連付けるためにインターネットで使用されるシステムは、ドメイン名システム（DNS）20と呼ばれる。インターネット内には現在、様々な命名システムおよびその他の識別子システムが存在しているが、この一例としてDMSが挙げられる。以下では、ドメイン名という用語は、任意のレベルのサブドメイン名を含め、使用される。
【０００４】
DNSクライアント12（単にクライアントと呼ぶこともである）は、hdl.handle.netというサービスを提供するサーバ28に到達するために、ドメイン名handle.netを含む要求14をDNS内の「.net」レジストリ18に呈示することができる。レジストリは、「.net」で終わる対応するドメイン名にIPアドレスを関連付けるエントリ22を含む。レジストリは、handle.netのエントリ23および1つまたは複数のネーム・サーバ（NS）25に関連するアドレスを見つける。NSは、DNSの一部であり、handle.netで終わるようなサブドメイン名を対応するサーバのIPアドレスに関連付けるエントリ27を含む。レジストリは、NSのIPアドレスをクライアントに返す。
【０００５】
クライアントは次に、レジストリから与えられたIPアドレスの識別されたNS 25に解決要求24を送信する。解決要求24は、サブドメイン名hdl.handle.netを含む。各NSは、1つのNSがhdl.handle.net 29のIPアドレスをクライアントに返すまで順次試行される。他の方式では、各NSを並行にまたは他の選択基準を使用して試行することができる。クライアントは、このIPアドレスを使用してそのサービス要求26をhdl.handle.netサーバ28に送信する。hdl.handle.netサーバが実際にそのIPアドレスに存在しており、かつ機能していると仮定すると、サーバはクライアントの要求を満たすように働く（31）。
【０００６】
各ドメインおよびサブドメイン名は通常、複数のNSを有する。この構成は、クライアントによる1つのNSへの信頼できるアクセスを提供する。しかし、選択されたNSが、機能しており、および／またはクライアントによってアクセス可能なサーバのIPアドレスをクライアントに提供するとは限らない。これは、NSがサーバのIPアドレスをクライアントに与える前にサーバの可用性を試験せず、かつNSが、クライアントとサーバとの間の接続性を試験しないからである。
【０００７】
サーバが誤動作するかまたはそのサービスがその他の理由で利用できないときに、クライアントによるサービスへの信頼できる同等のアクセスを提供するための様々な技術が開発されている。
【０００８】
図2に示されているように、1つのアプローチは、所与のサービスについてサーバの複数の冗長な事例(instances)28A、28B...を設けることである。各サーバは、負荷分散装置40またはゲートウェイの後方に配置することができる。この場合には、クラスタと呼ばれる、負荷分散装置またはゲートウェイのIPアドレスは、DNSが通常サブドメイン／ドメイン名に関連付けるアドレスである。クライアントがクラスタについて指定されたIPアドレスに対してサービス要求26を行うと、要求は負荷分散装置またはゲートウェイによって受信され、サーバの1つに転送される。負荷分散装置は、複数のサーバ間で要求を分散させて負荷の釣合いをとり、1つのサーバに障害が起こった場合、すべての要求を障害が起こったサーバから遠ざけることができる。クラスタ全体に障害が起こるかまたはクラスタ全体が利用不可能になった場合、クライアントには、そのクラスタからのサービスは提供されない。
【０００９】
図3に示されているように、他のアプローチでは、サーバ28の複数の冗長な事例は、それぞれの異なるIPアドレスを有し、所望のサービスのドメイン名をこれらのIPアドレスのうちのどれかに解決することができる。各NS 25は、冗長なサーバ28のすべてのIPアドレス34のリスト32を維持しており、解決要求24が受信されたときにすべてのアドレス（または選択されたアドレスのみ）をクライアントに返すことができる。クライアントは次いで、利用可能であり機能しており、かつ（理想的には）ネットワーク上のクライアントの位置に近接しているサーバを選択することができる。多くの場合、クライアント・ソフトウェアは、そのアドレスが最適な選択肢であるかどうか、またはクライアントにアクセス可能であるかどうかすら検証を試みずに、単純に解決機構から返された第1のアドレスを使用する。
【００１０】
機能していないか、またそうでなければ利用不能であるサーバにNSがクライアントを導く機会を減らすために、各IPアドレスのリアルタイム・チェックを行い、サービスが実際に利用可能でありかつ機能しているかを確認しているシステムもある。たとえば、リアルタイム・チェックは、ユーザ・データグラム・プロトコル（UDP）またはピング（目標に送信されるICMPエコー要求パケット、リターン・パケットは、ノード間の往復時間およびパケット喪失率の推定を可能にする）メッセージ37によって行うことができる。DNSではこのような試験を義務付けていないが、NSにこの試験を行わせると、DNSの信頼性を利用して、確実にクライアントにサービスが提供される。
【００１１】
他の構成では、各サーバは、専用ネットワーク・サーバ（SNS）と対にされる。所与のドメイン名に使用されるNSは、それと対になったサーバの可用性を追跡するようにカスタム化される。SNSは、ドメイン名解決要求を受信すると、何らかの方法を使用して、ネットワークにおいて利用可能なサーバのうちのどれがクライアントの最も近くにあるかを判定し、そのサーバのIPアドレスをクライアントに返す。クライアントへのネットワーク・パスまたはNSからのネットワーク・パスがないSNSは、NS解決応答として使用出来うるIPアドレスのリストから外される。
【００１２】
所望のサービスを提供するサーバは、それが提供するサービスに関連する様々なプロトコルに適合することができる。たとえば、ハイパー・テキスト転送プロトコル（http）サーバから提供されるサービスの場合、要求は一般に、ユニフォーム・リソース・ロケータ（URL）、たとえば、http://hdl.handle.net/<resourceid>として表される。ここで、hdl.handle.netは公知の1組のサーバのドメイン名であり、<resourceid>は、その1組のサーバのうちの任意のサーバで利用可能なサービスまたはその他のリソースを示す。
【発明の開示】
【発明が解決しようとする課題】
【００１３】
本発明は、ネットワークにおいて分散サービスにアクセスする方法を提供することを課題とする。
【課題を解決するための手段】
【００１４】
一般に、一局面では、1組の複数のサーバの各サーバは、（a）名前または他の識別子を有するサービスを提供し、（b）組内の他のサーバの各々のネットワーク・アドレスとは異なるネットワーク・アドレスを有し、（c）クライアントから受信された名前または他の識別子を、解決機構に対してローカルなネットワーク・アドレスにマップする解決機構と同じ位置に配置される。解決機構は、クライアントが、現在、クライアントにサービスを提供するように作動しており、および／またはアクセス可能であるサーバの1つを選択し、かつクライアントが最初に、選択されるサーバにアクセスする必要のない、そのようなサーバを選択することを可能にするように操作される。
【００１５】
いくつかの例では、様々なサーバによって異なるバージョンのサービスを提供することができ、他の例では、サービスは様々なサーバで同一のサービスとして提供される。
【００１６】
実現態様は、以下の特徴のうちの1つまたは複数を含んでよい。サーバの選択は、解決機構によって使用されるプロトコルによって決まる。サーバの選択は、1つまたは複数のサーバの1つまたは複数の性能属性によって決まる。性能属性には、測定された応答時間またはクライアントへの解決機構の相対的な近さの尺度を含めてよい。サーバの性能属性は、クライアントに格納され時々に更新される。性能属性のいくつかの更新は、生じた解決要求から導かれる。クライアントによって選択されるサーバは、クライアントからの解決要求に最初に応答するサーバである。解決機構は、それと同じ位置に配置されているサーバと同じアドレスを有する。サービスへのアクセスは、任意の1つのサーバおよびそれと同じ位置に配置された解決機構が作用しており、および／またはアクセス可能である場合にクライアントによって得られる。同じ位置に配置されたNSおよびサーバのいくつかはクラスタ化され、単一のネットワーク・アドレスを使用してアクセスすることができる。サービスへのアクセスは、クラスタ内の少なくとも1つの解決機構およびクラスタ内の1つのサーバが作用しており、および／またはアクセス可能である場合にクライアントによって得られる。サーバは、プロキシ・サーバを含む。プロキシ・サーバはバックエンド・サービスにアクセスする。ネーム・サービス・レジストリは、解決機構を妨げずにサーバのネットワーク・アドレスを手動で削除することを可能にする。所与のサーバと同じ位置に配置された解決機構は、サービスの状況をチェックし、サービスが機能していないときには、クライアントからの解決要求に対する応答を終了する。解決機構は、クライアントからの妥当な入力コードを要求する。妥当な入力コードを使用して、解決機構が応答すべきかどうかが判定される。たとえば、ネットワーク上に複数組のサーバが配置されている場合、複数組のサーバのうちの1組を使用することが特に許可されたクライアントは、クライアントの入力コードを使用して、許可されたサービスを使用可能にする。
【００１７】
他の局面には、方法、装置、システム、プログラム製品として、および他の点で表される、上述の特徴および他の特徴の他の組合せを含んでもよい。
【００１８】
他の利点および特徴は、以下の説明および特許請求の範囲から明らかになろう。
【００１９】
本発明(1)は、各サーバが、（a）名前または他の識別子を有するサービスを提供し、（b）組内の他のサーバのネットワーク・アドレスとは異なるネットワーク・アドレスを有し、（c）クライアントから受信された名前または他の識別子を、解決機構に対してローカルなネットワーク・アドレスにマップする解決機構と同じ位置に配置される、1組の複数のサーバについての、以下の段階を含む方法であって、
クライアントが、現在、クライアントにサービスを提供するように作動しており、および／またはアクセス可能であるサーバの1つを選択し、かつクライアントが最初に、選択されるサーバにアクセスする必要のない、そのようなサーバを選択することを可能にするように解決機構を操作する段階を含む方法である。
本発明(2)は、サーバの選択は、解決機構によって使用されるプロトコルによって決まる、本発明(1)の方法である。
本発明（3）は、サーバの選択は、1つまたは複数のサーバの1つまたは複数の性能属性によって決まる、本発明(1)の方法である。
本発明（4）は、性能属性には、測定された応答時間またはクライアントへの解決機構の相対的な近さの尺度を含めてよい、本発明(3)の方法である。
本発明（5）は、サーバの性能属性は、クライアントに格納され時々に更新される、本発明(3)の方法である。
本発明（6）は、性能属性の更新は、自然に生じた解決要求から導かれる、本発明(4)の方法である。
本発明（7）は、クライアントによって選択されるサーバは、クライアントからの解決要求に最初に応答するサーバである、本発明(1)の方法である。
本発明（8）は、解決機構は、それと同じ位置に配置されているサーバと同じアドレスを有する、本発明(1)の方法である。
本発明（9）は、サービスへのアクセスは、任意の1つのサーバおよびそれと同じ位置に配置された解決機構が作用しており、および／またはアクセス可能である場合にクライアントによって得られる、本発明(1)の方法である。
本発明（10）は、同じ位置に配置された解決機構およびサーバのいくつかはクラスタ化され、単一のネットワーク・アドレスを使用してアクセスすることができる、本発明(1)の方法である。
本発明（11）は、サービスへのアクセスは、クラスタ内の少なくとも1つの解決機構およびクラスタ内の1つのサーバが作用しており、および／またはアクセス可能である場合にクライアントによって得られる、本発明(8)の方法である。
本発明（12）は、サーバは、プロキシ・サーバを含む、本発明(1)の方法である。
本発明（13）は、プロキシ・サーバはバックエンド・サービスにアクセスする、請求項11記載の方法である。
本発明（14）は、ネーム・サービス・レジストリは、解決機構を妨げずにサーバのネットワーク・アドレスを手動で削除するのを可能にする、本発明(1)の方法である。
本発明（15）は、所与のサーバと同じ位置に配置された解決機構は、サーバの状況をチェックし、サーバが利用不能であるときには、クライアントからの解決要求に対する応答を終了する、本発明(1)の方法である。
本発明（16）は、解決機構が、クライアントからの妥当な入力コードを要求する、本発明(1)の方法である。
本発明（17）は、妥当な入力コードを使用して、解決機構が応答すべきかどうかが判定される、本発明（16）の方法である。
本発明（18）は、各サーバが名前または他の識別子を有するサービスを提供する1組の複数のサーバを含み、
各サーバは、組内の他のサーバのネットワーク・アドレスとは異なるネットワーク・アドレスを有し、クライアントから受信された名前または他の識別子を、解決機構に対してローカルなネットワーク・アドレスにマップする解決機構と同じ位置に配置され、
解決機構は、クライアントが、現在、クライアントにサービスを提供するように作動しており、およびアクセス可能であるサーバの1つを選択し、かつクライアントが最初に、選択されるサーバにアクセスする必要のない、そのようなサーバを識別するのを可能にするシステムである。
【発明の効果】
【００２０】
本発明により、ネットワークにおいて分散サービスにアクセスする方法が提供された。
【発明を実施するための最良の形態】
【００２１】
図4に示されているように、1組の冗長なサーバ102a、102b...（これらはすべて、名前または識別子、たとえば、hdl.handle.netを有するサービスを冗長に提供する）の各々と同じ位置に配置された解決機構（たとえば、NS）100a、100b...を設け、解決機構の固有の最適化および冗長性を使用して高い信頼性を提供することによって、より複雑で高価な解決策と同様の利点をより簡単におよびより廉価に得ることができる。「同じ位置に配置された」という用語を使用する際、たとえば、単一のコンピュータおよびオペレーティング・システム上で動作するか、または単一のIPアドレスを使用して、たとえばサーバのクラスタにアクセスできる、2つのプロセスを含める。
【００２２】
図4では、各NSは、それがサービスを提供するドメイン、たとえばhdl.handle.netのネーム・サーバとして指定される。NSのIPアドレスは、DNSレジストリ18内のドメイン名、たとえばhdl.handle.netのIPアドレスのリストに含められる。NSのIPアドレスは、サーバのIPアドレスと同じに設定される。ただし、DNSは通常、この情報を直接は使用せず、むしろクライアントが、この一致を知らないまま（後述の）クライアントの所定の一連のステップを実行する。
【００２３】
いくつかの実現態様では、各NSは従来のNSであるが、クライアント106から、指定されたドメイン名、たとえばhdl.handle.netについての名前解決要求104を受信すると、NS自体のIPアドレスをクライアントに返す。そのとき、クライアント106がNSのIPアドレスを使用してNSに接続できることが分かっているので、クライアントが、単にNSのIPアドレスを使用し、NSに、同じサーバ・マシン上に配置されたサーバのIPアドレスを返させることによって、同じサーバ・マシン上に配置されたサーバによりそのサービス要求107を首尾よく完了させるのは容易なはずである。複数のサービス（各々が同じ位置に配置されたNSを有する）を有するクラスタの場合、NSはゲートウェイのIPアドレスをクラスタに返す。
【００２４】
逆に、クライアントが1つのNSに接続できない場合、クライアントは、到達可能なNSが見つかるまで、最初にDNSレジストリから与えられたIPアドレスのリスト内の次のNSにクライアントの解決要求を送信する。クライアントは、それ自体のNS IPアドレス・リスト、およびネットワークにおいてどのNSが到達可能であり、かつクライアントに最も近いかに関する情報を維持することができる。多数の要求の後、クライアントは通常、解決要求を送信するのに最適に機能しているNSを自動的に判定することができる。
【００２５】
各NSは、同じ位置に配置されたサーバの状況をチェックする（106）ように構成することもできる。サーバが応答しない場合、NSは、クライアント応答要求に対する応答を控える。クライアントはこの場合、その解決要求を他のNSに送信させられる。各NSは、他のNSによるサービスの供給を妨げずにそのNSの保守のため、循環から取り出すことを可能とするように構成することもできる。
【００２６】
このアプローチは、クライアントが機能していないNSのIPアドレスをキャッシュしているときを除いて、一般に高速のフェイルオーバを含むネットワーク・ベースのサービスへの信頼できるアクセス手段を提供する。このような場合、クライアントは、異なるNSに出力先を変更する前にN分（NSのIPアドレス・レコードの生存時間（TTL））待たなければならない。
【００２７】
図4の各NSのIPアドレスは、同じ位置に配置されたサーバのIPアドレスと同じであってよいが、この代わりに（またはこれに加えて）、すべてが同じサービスを冗長に提供するという点で名目上同一である複数のサーバを、機能している1つのサーバを選択するにはどうすればよいかを知っているゲートウェイの後方にクラスタ化することができる。このような設計では、ゲートウェイのIPアドレスがクライアントに与えられ、したがって、このIPアドレスはNSのIPアドレスとは異なる。DNSレジストリはすべての指定されているNSをリストしているので、あるNSが作動している場合、クライアントにはそのサーバに使用すべきIPアドレスが通知され、クライアントは、その時点でそのサーバがアクセス可能である可能性が高いことを知る。このようなクラスタ化環境では、クラスタ内の1つのサーバが機能していることが報告された後にこのサーバに障害が起こった場合、ゲートウェイは自動的に、クライアントをクラスタ内の機能している他のサーバに導く。NSが応答しない場合、同じ位置に配置されているサーバも機能していない可能性が高い。
【００２８】
いくつかの実現態様では、クライアントによってアドレス指定すべきサーバは、ウェブ・クエリを他のウェブ・サイトへの出力先変更コマンドにマップするプロキシ・サーバである。出力先変更コマンドは、信頼性の高いバックエンド・システムからの、プロキシ・サーバがアクセスする情報に基づいてプロキシ・サーバによって与えられる。
【００２９】
前述のこのようなプロキシ・サーバの一例は、それぞれ、たとえばhdl.handle.netと呼ばれる多数のプロキシ・サーバをインターネット上に（信頼性を向上させるために）配置することによって、代わりとなる識別子および／または解決システムへの信頼できるアクセスを提供する。どのプロキシ・サーバも、識別子を含む正しい対応するURLを、クライアントのサービス要求に対する答えとして与える。各プロキシ・サーバは、DNSインタフェース仕様を実現し、かつそのサーバのIPアドレス（サーバがクラスタ化され、返されるIPアドレスがクラスタに対するゲートウェイのアドレスである場合を除いて、名目上NSのIPアドレスと同一である）のみを返す単純なカスタム化されたNSと対になっている。クライアントは、NSに接続することができるので、特にクライアントが同じマシン上に存在するか、またはNSがプロキシ・サーバの可用性についてローカル試験を行った場合、同じ位置に配置されたプロキシ・サーバにも接続できるはずである。
【００３０】
すべてのNSのIPアドレスは、DNSレジストリにNSレコードとしてリストされる。クライアントが最初にIPアドレスで応答したNSを使用する場合、通常、関連付けされたサーバが使用するのに最良のサーバである。なぜなら、このサーバが最も速く応答したからである。しかし、クライアントのソフトウェアは各NSからの応答時間を記録している。後で、このNSが過去に他のNSよりも応答に時間がかかっていた場合、サーバの選択を動的に変更することができる。プロキシ・サーバへの信頼できる効率的なアクセスが達成される。
【００３１】
より信頼性の高い実現態様では、応答の前にプロキシ・サーバを試験するようにNSを修正することができる。プロキシ・サーバが応答しない場合、NSは応答を停止し、それによって、クライアントは異なるNSと通信する。リソースの選択された事例を、プロキシ・サービスを妨げることなく、保守のため循環から手動で取り出すことができるように、各NSにある機構が付加されている。
【００３２】
プロキシ・サーバIPアドレスの生存時間（TTL）値を小さな値に設定すると有用である場合がある。TTL値が大きければ大きいほど、各クライアントが、あるプロキシ・サーバに接続した後そのプロキシ・サーバと通信を継続する時間が長くなる。前述のプロキシ・サーバに関しては、5分〜15分の範囲のTTL値が適切な選択肢である。
【００３３】
分散NSの使用を含むNS解決機構を呼び出した後、クライアントは、NSに対応するプロキシ・サーバのうちで、クライアントが最初に首尾よく通信したプロキシ・サーバに導かれる。クライアントは同じマシン上のNSと通信することができるので、クライアントがプロキシ・サーバとも通信できることはほぼ確実である。このシステムは、DNSの信頼性および性能上の利点を、まだ信頼性機構（たとえば、現在のウェブ・ブラウザによって使用されているhttpプロトコル）を組み込んでいないサービスに利用する。
【００３４】
このアプローチでは、あらゆるサーバにNSを設置し、DNSレジストリを常に更新する必要がある。あるサーバに障害が起こった場合、特定のクライアントは、そのNSに対してタイムアウトした後に次のNSに移ることができる（しかし、NSレコードTTLが24時間であると仮定すると、これらのクライアントは24時間に一度しかタイムアウトしないはずである）。さらに、サーバにはめったに障害が起こらない可能性が高く、したがって、通常顕著な遅延は起こらない。
【００３５】
機能しているサーバに確実に到達するIPアドレスをDNSクライアントに与えることに関してDNSクライアントに依存するアプリケーションでは、DNSがそのようなアドレスを与えることができなかった場合、障害が起こる。上述の技術は、DNSがその仕様に応じて適切に作動しており、かつ少なくとも1つのNS/サーバ対がネット上で適切に作動していると仮定した場合に、既存のDNSが適切なアドレスを与えることに失敗しないよう保証する。
【００３６】
このようにDNSに依存しない実現態様も可能である。
【００３７】
たとえば、代わりの解決システムを、識別されているデジタル・オブジェクトに関する情報に識別子をマップするため使用してもよい。いくつかの実現態様では、この情報が、デジタル・オブジェクトを含むレポジトリへのアクセスに使用される。多くの場合、デジタル・オブジェクトを格納するレポジトリは1つだけであり、クライアントがこのレポジトリにアクセスできない場合、クライアント上で動作しているアプリケーションに障害が起こる。しかし、他のアプリケーションについては、（信頼性を向上させ、アクセスを容易にするために）複数のレポジトリ内にデジタル・オブジェクトが複製され、デジタル・オブジェクトにアクセスするにはこのうちの1つのレポジトリで十分である。アプリケーションが、考えられるすべてのレポジトリを、どのレポジトリがアクセス可能であるかについて試験することができない場合、限られた形態の解決システム・ソフトウェアを各レポジトリまたは各レポジトリ・クラスタ内に配置することができる。解決システム・ソフトウェアは、クエリを受けた場合、同じ位置に配置されたレポジトリが機能しておりかつアクセス可能である場合にのみ応答する。したがって、アプリケーションは、受信する応答に応じて、作用しており、および／またはアクセス可能であるレポジトリを首尾よく見つけ出す可能性が非常に高い。
【００３８】
他の実現態様も特許請求の範囲内である。
【図面の簡単な説明】
【００３９】
【図１】インターネットの図である。
【図２】ドメイン名解決機構を示すブロック図である。
【図３】ドメイン名解決機構を示すブロック図である。
【図４】ドメイン名解決機構を示すブロック図である。
【符号の説明】
【００４０】
10  インターネット
12  クライアント
14  要求
18  DNSレジストリ
20  ドメイン名システム（DNS)
22 「.net」で終わる対応するドメイン名にIPアドレスを関連付けるエントリ
23  エントリ
24  解決要求
25  ネーム・サーバ（NS）
26  サービス要求
27  エントリ
28  サーバ
29  IPアドレス
31  サーバはクライアントの要求を満たすように働く
32  リスト
34  IPアドレス
37  HDPまたはピング・メッセージ
40  負荷分散装置
100a、100b...解決機構
102a、102b...サーバ
104  名前解決要求
106  クライアント
107  サービス要求
【図１】
2007207231.tif 000003
【図２】
2007207231.tif 000004
【図３】
2007207231.tif 000005
【図４】
2007207231.tif 000006