(57)【特許請求の範囲】
【請求項１】
複数のクライアントからのデータオブジェクトに対する要求をルート指定するシステムにおいて、
前記データオブジェクトに仕える複数のコンテントサーバと、
データオブジェクトに対する前記要求をルート指定するためのディレクタとを含み、前記ディレクタは、
前記複数のコンテントサーバから１つのコンテントサーバを選択するためのサーバ選択要素と、
前記コンテントサーバを要求しているクライアントからの複数のルートを識別するための識別要素と、
前記複数のルートの各々を伝送する時間を決定するための決定要素と、
前記要求しているクライアントからの前記伝送時間が最小である前記コンテントサーバへのルートを選択し、そして前記コンテントサーバに関連した複数のＩＰアドレスから、前記選択したルートに沿って前記コンテントサーバからコンテントを前記要求しているクライアントに指し向ける一つのＩＰアドレスを識別する、ルート選択要素と、
を含んでいるシステム。
【請求項２】
前記ディレクタ要素は、更に、前記複数のクライアントの中の一つからのデータオブジェクトに対する要求に対して、前記ルートに沿って前記選択されたコンテントサーバへ該要求を転送するように回答を行う回答要素を含む、請求項１のシステム。
【請求項３】
前記回答要素は、ＨＴＴＰ転送応答を使用する転送要素を含んでいる請求項１のシステム。
【請求項４】
前記決定要素は、ＩＣＭＰエコー応答を使用して前記ルートを伝送する時間を測定する測定要素を含んでいる請求項１のシステム。
【請求項５】
異なった経路に沿ってデータオブジェクトを伝送するように複数個のＩＰアドレスを有する複数のコンテントサーバと、クライアントからのオブジェクトに対する要求に基づきクライアントとコンテントサーバとの間をルート設定するように動作する複数のルータと、前記データオブジェクトに対する前記クライアントの要求を前記複数のコンテントサーバの一つにルート指定するように動作するディレクタとを使用して、複数のクライアントからのデータオブジェクトに対する要求をルート指定する方法において、
前記ディレクタは、
前記複数のクライアントのうちの特定のクライアントからのデータオブジェクトに対する要求を受信し、
前記特定のクライアントから前記複数のコンテントサーバへの複数のルートを識別し、
前記複数のルートの各々の伝送時間を決定し、
前記伝送時間のうちの最小時間を有する一つのルートを選択し、
前記特定のクライアントに、前記選択されたコンテントサーバからそのコンテントを前記ルートに沿ってクライアントに差し向ける前記選択されたコンテントサーバに関連した複数のＩＰアドレスの一つを通報する、段階を含む方法。
【請求項６】
前記特定のクライアントに通報する段階は、更に、データオブジェクトに対する要求に対して、前記特定のクライアントが前記選択されたコンテントサーバに対して前記要求を転送するようにと応答する段階を含む請求項５の方法。
【請求項７】
前記伝送時間はＩＣＭＰエコー応答により決定される請求項５の方法。
【請求項８】
前記転送はＨＴＴＰ転送応答である請求項５の方法。
【発明の詳細な説明】
［関連出願］
本出願は、下記の米国仮特許出願からの優先権を主張する。すなわち、１９９６年１２月９日付けにて出願された「A Distributed Computing System and Method for Distributing User Requests to Replicated Network Service」と題するRodney L.Joffle等の米国仮特許出願第60/032,484号。
［発明の背景］
本発明は、一般的に分散型コンピュータシステムの分野に関し、特定すると、基礎をなすネットワーク基礎構造体の速度のような最良の規準に基づいて複数のネットワークサーバの一つに要求を割り当てるコンピュータ（計算）システムおよび方法に関する。
世界規模のウェブの爆発的成長は、僅かの紹介しか必要としない。技術的共同体のメンバーが、World Wide Web上で入手し得る常時増大しつつある数の技術的および情報的資源を見出すだけでなく、主流である大衆は、好みのレストラン、車メーカ，教会を見つけて楽しんでいる。通信媒体としてのWorld Wide Webの人気は、その情報内容の豊富さと使用の容易さにある。この媒体における情報は、広く分散された一群のインターネットワーク接続されたサーバにおいてオブジェクトとして存在し、各オブジェクトはそれ自身の均一リソースロケータ（ＵＲＬ）により一意的にアドレス可能である。発足以来、Word Wide Webは、日常の生活や商取引において世界規模の突出性を示した。
しかしながら、この爆発的成長は、困難性なしにあったわけではない。商業的な応用の増大の結果、常時増大しつつある数のユーザが常時増大しつつある数の問合せを発することとなる。潜在性と帯域幅の制約の問題は、遅延と、情報の損失と、顧客の混乱をもたらすことは自明である。
ネットワーク設計者は、一連の解決策を使って応ずる。多くの回答は、より大きな計算パワを供給することに基づく解決法の範疇にある。これは、異なるウェブサーバソフトウェア、ウェブサーバハードウェアまたはプラットフォーム、サーバにおけるＲＡＭまたはＣＰＵの増加、アプリケーションの再書込み、またはハードウェアの更新によるネットワークハードウェアの増大のような代わりの問題を包含しよう。他の種類の解決方法は、複数のサーバを使用することまたはサーバを戦略的に位置づけることを包含する。この種類の一つの方法は、サーバをインターネットサービスプロバイダに位置づけることである。最適のペアリング能力を有するサービスプロバイダを選択することによって、サーバをサービスプロバイダ領域に一緒に配置することでインターネットの残部へのより良好な接続を生ずることができる。他の手法は、分散サーバの使用である。同一内容のサーバを世界中の戦略位置に置く。例えば、一つはニューヨークに、一つはサンフランシスコに、そして一つはロンドンに置く。これはロードを複数のサーバに分散し、トラフィックを要求者により近づけて保持する。他の手法はサーバをクラスタリングすることである。クラスタリングは、ハードドライブアレイを複数のサーバ間で共有することを可能にする。他の手法は、サーバファームである。これは、同一の内容を有する複数のウェブサーバの使用、または機能性に基づくセグメント化を包含する。例えば、ウェブ機能に対して二つのサーバが、ＦＴＰに対して二つ、データベースとして二つというように使用される。サーバファームの変形は分散サーバファームである。これは、サーバファームを戦略位置に置き、本質的にサーバファームを分散型サーバの手法と組み合わせる。
複数サーバの手法および分散型サーバの手法は、他の問題を生ずることを犠牲にして一つの問題を解決する。もしも複数のサーバがあれば、最終ユーザはどのようにして一つのサイトを見つけるのであろうか。現在のところ、ネームおよびユニバーサルリソースロケータ（ＵＲＬ）が、ドメインネームサービス（ＤＮＳ）により固有の単一のアドレスに分解される。ＤＮＳサーバは、個々のＩＰアドレスを相互参照するドメインネームを維持する。しかしながら、複数のウェブサーバまたはサーバファームが使用されると、ＤＮＳシステムは変更されねばならない。この問題に対する共通の手法は、ＤＮＳシステムをネーム対ＩＰアドレスの１対複数マッピングに変更することである。かくして、ＤＮＳは、任意特定のウェブオブジェクトに対してＩＰアドレスのリストを戻す。これらは、ラウンド−ロビン様式で種々のクライアントに送ることができる。しかしながら、この手法には数点の欠点がある。ラウンドロビン様式は、要求者またはサーバの位置にあまり関係なくＩＰアドレスを厳しい順序で戻す。この方式は、サーバアーキテクチャまたは負荷状態を認識しない。選択は、簡単なリストに沿って進行するだけである。一つのサーバはすべての重デューティユーザを受け付けることができる。さらに、再弱のリンクが全性能を決定するから、サーバプラットホームは比較的均等に維持されることが必要である。他の問題は、ＤＮＳが、アドレスが対応しているサーバが動作しているか否かに拘わりなくＩＰアドレスを単純に戻すことである。したがって、もしもラウンド−ロビンサーバの一つがたまたまメインテナンスのためにオフラインにあると、ＤＮＳは、アドレスを送出し続け、潜在的ユーザは、タイムアウトエラーを受信し続ける。かくして、ＤＮＳのラウンド−ロビン変更は、分散サーバの問題を解決しようとする広い試みを作り出す。しかしながら、その場合、そこではネットワークのトラフィックやサーバ間の平衡性が低いことや、忠実性の問題とは無関係である。
市場の数種の製品は、これらの問題を解決しようと目論んでいるが、これらの従来の努力はすべて、レプリカサーバ選択を容易化するためにユーザソフトウェア環境が変更されるべきことを必要とするという欠点を有した。ユーザソフトウェア変更を必要とするという方式は、広いソフトウェアの分布を保証するという実際的な問題に起因して望ましさが欠ける。この種の方式は、せいぜい最適化技術として有用であるに過ぎない。
一つのこの種の手法は、ユーザ要求をサーバに割り当てるために明白なユーザ選択に依存する手法である。ユーザアプリケーションは、それら自身のサーバ選択をなすに十分の情報、技巧および寛容性を有することをユーザに要求する追加のステップを含むことがある。この種の方式は、多数の理由のために必ずしも望ましくない。
選択的ホストルート指定に基づく技術は、ネットワークトポロジの異なる点に位置づけられすべて同じネットワークアドレスをもつ複数のレプリカサーバを使用する。各サーバと関連するルータは、共有されるサーバアドレスに対する到来ネットワークトラフィックを捕捉し、特定のサーバにトラフィックを送る。この技術は、クライアント要求負荷を近傍のサーバに静的にのみ送り、サーバの負荷または他のネットワーク特性を考慮しない。
ドメインネームシステムサーバのＢＩＮＤの実施形態は、サーバネームを異なるネットワークアドレスに結合する技術を含み得るが、この場合、一組の複数のアドレスの一つが逐次的にあるいはランダムに割り当てられる。サービスプロバイダは、異なるアドレスを各レプリカサーバに割り当て、ＢＩＮＤは、ユーザ要求を代わりのサーバに送る。この技術はクライアントの要求を任意のサーバに静的にのみ分配し、サーバ負荷やその他のネットワーク特性について考慮しない。
ＳＯＮＡＲは、特にトポロジカルクローズネスに対してネットワーク特性を分散するための出現しつつあるＩＥＴＦ（Internet Engineering Task Force）である。ＳＯＮＡＲは、問合せ要求および応答を表すデータフォーマットを含むが、ネットワーク特性を決定するための機構を特定しない。
Cisco Local Directorは、複数のローカルの正面に据えられるネットワークトラフィックとして働く製品で、サーバに流れるトラフィックの量に基づいて各サーバに新しいトランスポート接続を分配する。この製品は、その決定においてネットワーク特性を考慮せず、さらにレプリカサーバがコロケートされるべきことを要求する。Cisco Systemsは、カリフォルニヤ州、San Joseに本部を置く会社である。
Cisco Distributed Directorは、ネットワークルーティングプロトコルから得られる情報に基づいて接続形態的に遠隔のサーバにユーザ要求を転送する。Distributed Directorは、到来するＤＮＳ要求かＨＴＴＰ要求のいずれかを受け止め、転送のために適当な応答を供給する。この製品は、サーバ負荷を考慮せず、ルーティングプロトコルから入手できる限定された一組の情報だけを考慮する。この情報はまた、スケーリング可能なインターネットルーティングを可能にするに必要な集合技術により、正確度が制限される。
これらの製品は、一緒に捉えると、サーバ負荷およびネットワーク特性を考慮するが、統合されたサーバ選択を行わない。しかし、なお「世界規模の待ち」である、という評論家の批評がなお真実である。この理由のため、必要とされるものは、ユーザ要求および基礎にあるネットワークの能力およびトポロジに基づいてユーザに対するデータオブジェクトを検索すべき適当なサーバを自動的に選択するシステムである。
［発明の概要］
本発明は、複数のネットワークサーバ間のクライアントによりなされるデータオブジェクト要求を割り当てることを可能にする。特定のルート指定方針の目的に合致するような態様で、分散コンピュータシステムにより含まれるレプリカサーバにユーザ要求を割り当てる分散コンピュータ（計算）システムおよび方法を提供する。特定のルート指定方針は、要求が完成されるに要する時間量を最小化することを含んでよい。例えば、本発明に従うシステムは、最短の利用可能なネットワーク路に従いユーザにデータオブジェクトを分配するように構成できる。
詳述すると、本発明は、データオブジェクト要求を「最良サーバ」ルート指定方針に基づいて任意の数のクライアントから複数のコンテントサーバにルート指定するためのシステムを提供する。コンテントサーバは、ディレクタの決定に基づいて、クライアント要求に応じてデータオブジェクトを１または複数のネットワークアクセス点に分配する。ディレクタは、ルート指定方針に基づいてそのデータオブジェクト要求の特定のコンテントサーバへのルート指定を決定する。
本発明の特定の側面に従うと、ルート指定方針は、下記のもののいずれか、下記のものの任意の組合せを含んでよいし、下記のもののいずれも含まなくてもよい。すなわち、（１）最小数のオープンＴＣＰ接続、（２）もっとも利用可能なフリーＲＡＭ、（３）もっとも利用可能なフリーＳＷＡＰ（仮想メモリ）、（４）ＣＰＵ遊び時間の最大量、または（５）クライアントマシンへの最速ＩＣＭＰである。
本発明に従う手法の利点は、基礎となるハードウェアに起こるフォルトに関するトレランスの増大、従来形式のウェブサーバに優る信頼性である。
【図面の簡単な説明】
図１Ａは代表的なクライアントサーバ関係を示す線図である。
図１Ｂは代表的クライアントサーバ関係を示す機能的機能的な斜視図である。
図１Ｃは代表的インタネットワーク環境を示す線図である。
図１ＤはＴＣＰ／ＩＰプロトコルスーツの層を示す関係線図である。
図２Ａは本発明の特定の具体例に従う分散コンピュータ環境を示す線図である。
図２Ｂは本発明の代替具体例に従う分散コンピュータ環境を示す線図である。
図３Ａは本発明の代表的具体例に従うプロセスの関係を示す線図である。
図３Ｂは本発明の代替具体例に従うプロセスの関係を示す線図である。
図３Ｃは本発明の好ましい具体例に従うプロセスの関係を示す線図である。
図４Ａは本発明の特定の具体例に従うプロセスステップを示す線図である。
図４Ｂは本発明の代替具体例に従うプロセスステップを示す線図である。
図４Ｃは本発明の代替具体例に従うプロセスステップを示す線図である。
図５〜５Ｃは本発明の特定の具体例に従うディレクタ要素内の最適化プロセスを示すフローチャートである。
［特定の具体例の説明］
以下、図面を参照して本発明を好ましい具体例について説明する。
［1.0  イントロダクション］
サーバ負荷平衡化システムの好ましい具体例は、実施に移されており、「ＨＯＰＳＣＴＣＨ」成るトレードマークの下で入手可能である。
システムは、分散ネットワーク接続環境における複数のコンピュータ上における代替具体例に、あるいは同じコンピュータ上で仮想マシンまたはアドレススペースにおいてランされる複数のプロセスを含む。ネームの指数関数的な増加を制限するために、読取り可能性を高めるために下記の約束が採用されている。「ｘｙｚサーバ」は、ｘｙｚを構成する一群のプロセスを収容するコンピュータまたは仮想マシンである。「ｘｙｚ要素」は、集合的にｘｙｚとして言及される一組の機能を遂行する一群のプロセスである。「ｘｙｚ」は、ｘｙｚマシン上でｘｙｚ要素により遂行される一組の機能である。
［1.1  ハードウェアの概観］
本発明のサーバ負荷平衡化のための分散コンピュータシステム（「システム」）は、Ｐｅｒｌプログラミング言語で実施され、図１Ａに図示されるようなコンピュータシステム上で動作する。本発明は、クライアント−サーバ環境で実施できるが、クライアント−サーバ環境は必須ではない。図１Ａは、一つのサーバ２０および多数のクライアントを含む従来形式のクライアント−サーバシステムを図示している。クライアントはその一つがクライアント２５として図示されている。
「サーバ」成る用語は、本発明の概念において使用される。すなわち、サーバはクライアント（代表的には遠隔の）から問合せを受け、問合せに対する応答を形成するに必要なすべての処理をなし、これらの応答をクライアントに提供する。しかしながら、サーバ２０それ自体は、データベースサーバとして働く他のノードに位置する遠隔データベースにアクセスするときには、クライアントの資格で働くことができる。
ハードウェアの形態はほぼ標準にあるから、ここでは短く記述する。周知の実施形態に従うと、サーバ２０は、サブシステム３２を介して多数の周囲デバイスと通信する１または複数のプロセッサ３０を備える。これらの周辺デバイスは、普通メモリサブシステム３５ａとファイルメモリサブシステム３５ｂより成る記憶システム３５（コンピュータプログラム（例えばコードまたは命令）およびデータを保持する）、ユーザインターフェース入力および出力デバイスセット３７および外部ネットワークに対するインターフェースネットワークを備える。ネットワークは、Ｅｔｈｅｒｎｅｔ、Ｔｏｒｎ Ｒｉｎｇ、ＡＴＭ、ＩＥＥＥ ８０２．３、ＩＴＵ Ｘ．２５，Ｓｅｒｉａｌ Ｌｉｎｋ Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｋｏｌ（ＳＬＩＰ）または公衆電話交換網を採用し得る。このインターフェースは、「Network Interface」ブロック４０として略示されている。これは、ネットワーク接続４５を介してクライアントコンピュータ内の対応するインターレースデバイスに結合される。
クライアント２５は、普通記憶および処理能力はより小さいが同じ一般形態を有している。かくしてクライアントコンピュータは、端末またはローエンドパーソナルコンピュータでよいが、サーバコンピュータは、一般にSUN SPARCTMサーバのようなハイエンドワークステーションまたはメインフレームである。クライアントコンピュータ内の対応する要素およびサブシステムは、対応するがダッシュ付きの参照番号で示されている。
ユーザインターフェース入力デバイスは、普通キーボードを備え、さらにポインティングデバイスとスキャナを備えてよい。ポインティングデバイスは、マウス、トラックボール、タッチバッドまたはグラフィックタブレットのような間接的なポインティングデバイス、またはディスプレイに合体されるタッチスクリーンのような直接的ポインティングデバイスとしてよい。ボイス認識システムのような他の形式のユーザインターフェース入力デバイスも可能である。
ユーザインターフェース出力デバイスは、普通プリンタとディスプレイサブシステムを備えるが、このディスプレイサブシステムは、ディスプレイコントローラと、このコントローラに接続されるディスプレイデバイスを備える。ディスプレイデバイスは、陰極線管（ＣＲＴ）、液晶ディスプレイ（ＬＣＤ）のようなフラットパネルデバイスまたは投影デバイスでよい。ディスプレイコントローラは、ディスプレイデバイスに制御信号を供給し、通常、ディスプレイデバイス上に現れるピクセルを記憶するためのディスプレイメモリを備える。ディスプレイサブシステムはまた、音響出力のような非可視的ディスプレイを備えてよい。
メモリサブシステムは、普通、プログラミング実行中命令およびデータを記憶するための主ランダムアクセスメモリ（ＲＡＭ）と、固定命令を記憶するリードオンリーメモリ（ＲＯＭ）を備えるマッキントッシュコンパティブルパーソナルコンピュータの場合、ＲＯＭはオペレーティングシステムの一部を含む。ＩＢＭコンパティブルパーソナルコンピュータの場合、これはＢＩＯＳ（基本入力／出カシステム）となろう。
ファイル記憶サブシステムは、プログラムおよびデータファイルの持続的な（不揮発性）記憶を提供し、普通少なくとも一つのハードディスクドライブと少なくとも一つのフロッピディスクドライブ（関連する除去可能な媒体をもつ）を備える。ＣＤ−ＲＯＭドライブおよび光ドライブ（関連する除去可能な媒体をもつ）のような他のデバイスでもよい。代わりに、コンピュータシステムは、除去可能な媒体カートリッジを有する形式のデバイスを備えてよい。除去可能な媒体カートリッジは、例えば、ハードディスクカートリッジ（Syquestおよびその他により販売されるもの）およびディスクカートリッジ（例えばIomegaにより販売されるようなもの）を含んでよい。ドライブの１または複数を、ローカルエーリヤネットワーク上のサーバまたはインターネットワールドワイドウェブのサイトにおけるような遠隔位置に位置づけてもよい。
この明細書において、「バス」サブシステム成る用語は、種々の要素とサブシステムを意図されるとき相互に通信せしめる機構を含むものとして一般的に使用される。入力デバイスとディスプレイを除いて、他の要素は同じ物理的位置にあることを要しない。かくして、例えば、ファイル記憶システムの一部は、電話ラインを含め、種々のローカルエーリヤ媒体またはワイドエーリヤ媒体と接続されることもある。同様に、入力デバイスおよびディスプレイは、プロセッサと同じ位置にあることを要しないが、本発明は、ＰＣＳおよびワークステーションの意味で実施されるのがもっとも多いと予測される。
バスサブシステム３２は、単一のバスとして略示されているが、ローカルバスまたは１または複数の拡張バス（例えばＡＯＢ，ＳＣＳＩ，ＩＳＡ，ＥＩＳＡ，ＭＣＡ，ＮｕＢｕｓ，またはＰＣＩ）、ならびに直列および並列ポートを有する。ネットワーク接続は、普通、これらの拡張バスの一つのバス上のネットワークアダプタまたは直列ポート上のモデムを介して設定される。クライアントコンピュータは、デスクトップまたはポータブルシステムとし得る。
ユーザはインターフェースデバイス（またはスタンドアロンシステムのデバイス３７）を使用してシステムと対話する。例えば、クライアント問合せは、キーボードにより入力され、クライアントプロセッサ３０’に通信され、ついでバスサブシステム３２’を介してネットワークインターフェース４０’に送られる。問い合わせは、ついでネットワーク接続４５を介してサーバ２０に通信される。同様に、問合せの結果は、デバイス３７’上の一つにて出力のため（例えばディスプレイまたはプリンタ）ネットワーク接続４５を介してサーバからクライアントに通信されるか、または記憶サブシステム３５’上に記憶されてもよい。
図１Ｂは、図１Ａのコンピュータシステムの機能的ダイアグラムである。図１Ｂは、サーバ２０と複数のクライアントの代表的クライアント２５を描いているが、このクライアント２５は、インターネット４５または任意の他の通信法によりサーバ２０と対話し得る。サーバの右方のブロックは、サーバプログラムおよび図１Ａのブロック３５ａにより指示されるデータ記憶デバイスで行われる処理要素および機能を表している。ＴＣＰ／ＩＰ「スタック」４４は、オペレーティングシステム４２と一緒に働き、サーバ２０をネットワークまたはインターネット４５に取り付ける直列接続を介してプロセッサと通信する。ウエブサーバソフトウェア４６は、サーバ２０内の他の処理と同時かつ協同的に実行され、データオブジェクト５０および５１を要求中のクライアントに入手せしめる。Common Gateway Interface（ＣＧＩ）スクリプト５５は、ユーザクライアントからの情報がウエブサーバ４６により、あるいはサーバ２０内の他のプロセッサにより作用されることを可能にする。クライアントに対する応答は、Hypertext Markup Language（HTML）の形式でクライアントに戻され、そしてこれはついでインターネット４５を介してユーザに通信される。
図１Ｂのクライアント２５は、図１Ａのブロック３５ａ’により指示されるプログラムおよびデータ記憶装置に配置される機能的プロセスをインクリメントする。ＴＣＰ／ＩＰスタック４４’は、オペレーティングシステム４２’と関連して動作し、クライアント２５をネットワークまたはインターネット２５に取り付ける直列接続を介してプロセッサと通信する。ウエブブラウザ４６’の機能を実施するソフトウェアは、クライアント２５内の他の処理と同時かつ協同的に実行し、サーバ２０のデータオブジェクト５０および５１への要求を発する。クライアントのユーザは、ウエブブラウザ４６’を介して対話し、インターネット４５を介してサーバ２０へのこの要求を発し、ウエブブラウザ４６’上においてインターネット４５を介してのサーバ２０からの応答を見る。
［ネットワーク概観］
図１Ｃは、上述のような、図１Ａおよび図１Ｂのクライアント２５のような複数のクライアントと、図１Ａおよび図１Ｂのサーバ２０のような複数のサーバのインターネットワーク接続を例示するものである。図１Ｃにおいて、ネットワーク７０は、トークンリングまたはフレーム指向ネットワークの例である。ネットワーク７０は、ＡＩＸオペレーティングシステムをランさせてよいＩＢＭＲＳ６０００ＲＩＳＣのようなホスト７１を、Ｗｉｎｄｏｗｓ９５，ＩＢＭ ＯＳ／２またはＩ）０５オペレーティングシステムをランさせてよいパーソナルコンピュータであるホスト７２、およびおＳ／４００オペレーティングシステムをランさせてよいＩＢＭ ＡＳ／４００コンピュータでよいホスト６３にリンクする。ネットワーク７０は、システムゲートウエイを介してネットワーク６０にインターネットワーク接続されるが、システムゲートウエイは、ここではルータ７５として図示されているが、ファイヤウオールまたはネットワークブリッジを有するゲートウェイとしてもよい。ネットワーク６０は、ＳＵＮＯＳオペレーティングシステムをランさせてよいＳＰＡＲＣワークステーションであるホスト６１を、ＶＭＳオペレーティングシステムをランさせてよいＤｉｇｉｔａｌ Ｅｑｕｉｐｍｅｎｔ ＶＡＸ６０００コンピュータとしてよいホスト６２とインターネットワーク接続するＥｔｈｅｒｎｅｔネットワークの例である。
ルータ７５は、ネットワーク７０とネットワーク６０のネットワークアクセス点（ＮＡＰ）である。ルータ７５は、トータンリングアダプタおよびＥｔｈｅｒｎｅｔアダプタである。これにより、ルータ７５は、二つの不均質なネットワークとインターフェース接続できる。ルータ７５はまた、ＩＣＭＰ ＡＲＰおよびＲＩＰのようなインターネットワークプロトコルを意識している。このプロトコルについては後述する。
図１Ｄは、Transmission Control Protocol Internet Protocol（TCP/IP）プロトコルの構成要素の例示である。TCP/IPプロトコルスーツのベース層は、物理層８０であり、これは、例えば図１Ａのネットワーク接続４５のような通信媒体を介してのデータの物理的伝送のための機械的、電気的、機能的および手続き的標準を限定するものである。物理層は、ネットワークがパッケットスイッチングであるか、フレームスイッチングであるか、あるいはネットワークがCarrier Sene Multiple Access/Colision Detection（CSMA/CD）に基づくか、フレームリレーパラディム（系列）に基づくかのような電気的、機械的または機能的標準を含み得る。
物理層８０に重なっている物理層は、データリンク層８２である。データリンク層は、ネットワーク資源間においてデータを転送し、物理層に起こり得るエラーを検出するための機能およびプロトコルを提供する。データリンク層におけるオペレーティングモードは、IEE 802.3 Ethernet, IEEE802.5 Token Ring, ITU X.25またはserial（SLIP）プロトコルのような標準的ネットワークトポロジを包含する。
ネットワーク層プロトコル８４が、データリンク層に重なり、ネットワーク間に接続を設定するための手段を提供する。ネットワーク層プロトコルに対する標準は、通信をインターネットワーク接続し、情報を複数の不均質ネットワークを介してルート指定するための動作的制御手続きである。ネットワーク層プロトコルの例は、Internet Protocol（IP）およびInternet Control Message Protocol（ICMP）である。Address Resolution Protocol（ARP）は、インターネットアドレスと特定のホストのMedia Access Address（MAC）間を相関づけるのに使用される。Routing Information Protocol（RIP）は、ネットワーク上のホスト間においてルート指定情報を通すための動的ルート指定プロトコルである。INternet Control Message Protocol（ICMP）は、種々のネットワーク上のホスト間において制御メッセージを通すための内部的プロトコルである。ＩＣＭＰは、ネットワーク環境における事象についてフィードバックを提供し、あるいはネットワーク環境にある特定のホストに対してパスが存在するかどうかを決定するのを助ける。後者は、「Ｐｉｎｇ」と称される。Internet Protocol（IP）は、インターネットにおいて情報パケットをルート指定するための基本的メカニズムを提供する。ＩＰは、「最善努力」の供給サービスを提供するもので、ネットワーク資源を特定のトランザクションに委託しないし、再伝送を遂行することも確認を与えることもしない。
トランスポート層プロトコル８６は、複数の不均質ネットワーク間においてエンド−エンドトランスポートサービスを提供する。User Datagram Protocol（UDP）は、無接続のデータグラム指向のサービスを提供するが、これは情報ストリームに対する信頼性のない供給メカニズムである。Transmission Control Protocol（TCP）は、インターネットにおいて情報を逐次のパケットを供給するため信頼性のあるセッションベースのサービスを提供する。ＴＣＰは、情報供給のための接続指向の忠実性のあるメカニズムである。
セッションまたはアプリケーション層８８は、ネットワークアプリケーションおよびユーティリティのリストを提供するもので、その二三をここにリストする。例えば、File Transfer Protocol（FTP）は、ファイルを一つのマシンから他のマシンに転送するための標準ＴＣＰ／一プロトコルである。ＦＴＰクライアントは、ファイルを得るためにＴＣＰ接続を介してＦＴＰとセッションを設定する。Telnetは、遠隔端末接続のための標準的ＴＣＰ／ＩＰプロトコルである。Telnetクライアントは、端末エミュレータとして働き、トランスポートメカニズムとしてＴＣＰを使用してTelnetサーバとの接続を設定する。Simple Network Management Protocol（SNMP）は、ＴＣＰ／ＩＰネットワークを管理するための標準である。「エージェント」と称されるＳＮＭＰタスクが、ネットワーク状態パラメータを監視し、これらの状態パラメータを「マネージャ」と称されるＳＮＭＰタスクに伝送する。マネージャは関連するネットワークの状態を追跡する。Rmote Procedure Call（RPC）は、プログラムがサーバマシン上の遠隔機能を呼び出すことを可能にするプログラミングインターフェースである。Hypertext Transfer Protocol（HTTP）は、一様な資源インジケータ（ＵＲＩ）システムを介してネットワークを横切ってデータオブジェクトを転送することを容易にする。
Hypernet Transfer Protocolは、Transfer Cobtrol Protocol（TCP）の頂部上に形成された単純なプロトコルである。ＨＴＴＰは、ユーザが、インターネット上のサーバとして働く種々のホストからデータオブジェクトを得るための方法を提供する。データオブジェクトのユーザ要求は、ＨＴＴＰ ＧＥＴ要求によりなされる。以下に説明されるＧＥＴ要求は、（１）″http://″のＨＴＴＰヘッダ、それに続く（２）データオブジェクトが存在するサーバの識別子、それに続く（３）データオブジェクトの全パス、それに続く（４）データオブジェクトのネームである。以下に示されるＧＥＴ要求において、″/pub/″のパスネームおよび″MyData.html″のネームをもつデータオブジェクトに対してサーバ″www.w3.org″の要求がなされつつある。
GET http://www.w3.org/pub/MyData.html      （１）
ＧＥＴ要求の処理は，ＧＥＴ要求内のサーバネームとのＴＣＰ／ＩＰ接続の設定と、特定されたデータオブジェクトのサーバからの受信を伴う。要求メッセージの受信後、サーバはＨＴＴＰ ＲＥＳＰＯＮＳＥメッセージの形式で応答する。
応答メッセージはプロトコルバージョンとそれに続く数値状態コードおよび関連する文による（テクスチャルな）理由フレーズを含む状態ラインで始まる。これらの要素は、スペース符号で分離される。状態ラインのフォーマットは、ライン（２）に記述する。
Status-Line=HTTP-Version Status-Code Reason-Phrase      （２）
状態ラインはつねにプロトコルバージョンと状態コード例えば″HTTP/1.0200″で始まる。状熊コード要素は、前の要求メッセを理解し満足させようとする試みの３ディジット正数の結果コードである。理由フレーズは、状態コードの単文による記述を与えることが意図される。状態コードの第１のディジットは、応答の種類を定義する。第１のディジットに対して５つのカテゴリーがある。１ＸＸは情報応答であるが現在使用されていない。２ＸＸは成功応答であり、アクションは成功裏に受信され、理解され、容認されたとの応答である。３ＸＸは、要求を完成するために追加のアクションが採られねばならないことを指示する再転送応答である。本発明の特定の具体例により使用されるのはこの応答であり、クライアントを選択されたサーバサイトに転送せしめる。４ＸＸは、クライアントエラー応答である。これは、要求に悪いシンタクスがあることを意味する。最後に、５ＸＸはサーバエラーである。これは、サーバが明らかに有効な要求を実現しなかったことを意味する。
ＨＩＩＰメッセージの特定のフォーマットは、Croccker,D．著「Standard for the Format of ARPA Internet Text Messaged」, STD II, RFC 822, UDEL, 1982年１月発行に記載されている。この著書も参照されたい。
［2.0  特定の形態］
図２Ａは、本発明に従う代表的な分散コンピュータシステムの線図である。
図２Ａにおいて、ネットワーク２００は、複数のサーバマシンを相互にかつ外部のインターネットワーク接続環境と複数のネットワークアクセス点（ＮＡＰ）を介して相互接続する。この内部ネットワークのトポロジは、本発明に関して完全に任意である。Ethernet, Token Ring,Asynchronous transfer Mode（ATM）または他の従来のネットワークトポロジでよい。ネットワークアクセス点は、大きいネットワーク間の接続点であり、ルータ、ゲートウエイ、ブリッジ、その他特定のネットワークトポロジに従ってネットワークを接続する方法を含んでよい。
ネットワークアクセス点２０２、２０４、２０６および２０８は、複数の外部ネットワークパスを介してクライアントマシンと通信のため、外部ネットワークＡ，Ｂ，ＣおよびＤへのネットワークの達成を可能にする。特定の具体例において、これらのネットワークアクセス点は、ルーティング構成要素の一部を収容している。好ましい具体例において、これらのＮＡＰは他のネットワークと匹敵するルータ２２４，２２４，２２６および２２８であり、知られているOpen Shortest Path First（OSPF）ルーティングアルゴリズムである。ＯＳＰＦは、パケットをもっとも近いマシンにルート指定することによって、数種のマシンが正確に同じＩＰアドレスを有する場合を容認できる。これに比して、代わりのルーティングメカニズム、Routing Information Protocol（RIP）はこのケースを扱えないであろう。さらに、これらのルータは、当技術に精通したものに周知のＩＰトンネル化技術を採用し、方針ルート指定可能である、すなわちそれらパケットのソースアドレスに一部依存してパケットをルート指定できる。各々は，ＩＰトンネルを利用して、パケットのソースアドレスおよびサーバの利用可能性に基づいて、特定のＮＡＰにあるルータを介してパケットをネットワークから送り出すように構成できる。
図２Ａはまた、各ＮＡＰに一緒に位置づけられるフロントエンドサーバ２１２，２１４，２１６および２１８を示している。これらのフロントエントサーバは、フロントサーバ要素プロセスを収容している。好ましい具体例においては、フロントエンドサーバは、ＩＰリレーやプロセス要素を収容している。これらのプロセスの機能については後述する。
ディレクタサーバ２５０は、数種のソフトウェア要素を収容しているが、これらの要素は、好ましい具体例においては、ディレクタ要素、ピングマネジャ要素およびロードマネジャ要素を含んでいるが、これらの各々については後述する。
１または複数のコンテントサーバ２３２，２３４，２３６および２３８は、コンテントすなわちウェブページまたはＦＴＰファイルの実際の分配を遂行する。
各々は、それと関連して、出パケットがディレクタ要素により選択できるソースアドレスを有するようにデータを分配できるコンテントサーバ要素の１または複数のインスタンスを有している。
各コンテントサーバは、システムにより制御される各ルータに対するネットワークエアリアスＩＰアドレスを有している。例えば、４つのルータを有するシステムの場合、特定のコンテントサーバは、４つの別個のネットワークエアリアスＩＰアドレスを有するであろう。システム内のルート指定は、「方針ルート指定」（ＰｏｌｉｃｙＲｏｕｔｉｎｇ）すなわち、パケットのソースアドレスに基づくルート指定を行うように構成される。その結果、パケットがどのネットワークエアリアスＩＰアドレスから来るかに依存して、パケットはディレクタにより選ばれる特定のルータを経てルート指定される。一連の選択可能な、ＩＰトンネルは、コンテントサーバが、「最良の」ルートを使用してクライアントにデータを送出することを可能にする。ＩＰトンネルは、各サーバが選ばれたネットワークアクセス点を通ってデータを分配送出できるように構成される。これに対比して、斯界に周知のシステムは、データがデフォルトピアリング点を介して出るようにデータを分配する。すなわち、インターネットを構成する他のネットワークに導き得るネットワーク出口点からデータを分配する。普通、デフォルトピアリング点は、ネットワークに対する唯一のピアリング点である。各ＩＰトンネルは、全データを異なるピアルータに全データを送出するように構成される。各ＩＰトンネルは、一つのルータでスタートし、他の（遠隔）ルータで終わる。これにより、コンテントサーバファーム（一つまたは複数のコンテントサーバが同じ物理的位置にあり、ルータの後で作用する）は、ディレクタがこれが最適のパスにあることを決定すれば、データを異なるコンテントサーバファームルータを介して分配する。
ルータは、パケットがＩＰトンネルと関連するソースアドレスを有するとき、パケットをそのＩＰトンネルに沿って送出するように静的に構成される。例えば、三つのピアリング点を有するネットワークにおいて、第１のピアリング点にあるルータ（「Ａ」と呼ぶ）は二つのでトンネル、「トンネル１」と「トンネル２」を有することになろう。これらのでトンネルは、他の二つのルータに導かれる。しかして、この他の二つのルータは、各々他の二つのピアリング点ＢおよびＣの一つに存する。ピアリング点Ａに存するルータは、１．１．１．１のソースアドレスを有するすべてのパケットをトンネル１に沿ってルート指定し、２．２．２．２のソースアドレスを有するすべてのパケットをトンネル２に沿ってルート指定するように構成されるであろう。トンネル１は、すべてのパケットを第２のピア点Ｂに送出し、トンネル２はすべてのパケットを第３のピアリング点Ｃに送出する。これは、ソースベースのルート指定であり、一般に「方針ルート指定」として知られている。
ピアリング点Ａにあるルータと関連するコンテントサーバは、サーバソフトウェアをランするが、これがそのサーバソケットのローカル側をアドレス１．１．１．１および２．２．２．２に結合し、それがいずれかのアドレスから作用することを可能にする。ディレクタソフトウェアは、そのコンテントサーバについてのサーバアドレスを所有する。これにより、ディレクタは、コンテントサーバが１．１．１．１アドレスから作用する時点を決定でき、全パケットは、トンネル１を介してネットワークアクセス点Ｂに分配され、コンテントサーバが２．２．２．２アドレスから作用するとき、全パケットはトンネル２を介してネットワークアタセス点Ｃに分配される。ディレクタソフトウェアは、どの完全適正化ドメインネーム（ＩＰアドレスに対応している）にサービスのためアクセスすべきかをクライアントに知らせることによって各コンテントサーバがそのデータを分配するのに通るＮＡＰを選択できる。何故ならば、そのアドレスが要求の回答パケットのソースアドレスであるからである。回答のパケットは、ディレクタソフトウェアにより選ばれたＮＡＰを介して自動的にルート指定される。
この方針ルート指定形態は、設定中に各システムについて一度セットアップされる。ディレクタは、各コンテントサーバに対するＩＰアドレステーブルに対してアクセスでき、従って特定のコンテントサーバの各ＩＰアドレスに対応するシステムルータにアクセスできる。これにより、ディレクタは、ディレクタ選択のシステムルータを介してルート指定するコンテントサーバＩＰアドレスを選択できる。ディレクタはまず、どのコンテントサーバが最小の負荷を有するかを決定しなければならない。ディレクタは、負荷マネージャ（これは各ロードデーモンからデータを収集している）により与えられるデータからこれを構成することができる。一度ディレクタが最小負荷コンテントサーバマシンを選択したら、ディレクタは、ブラウズしつつあるクライアントに対して最良のＩＣＭＰワンウェイトリップ時間を有するルータを介してルート指定されるネットワークエイリヤスＩＰのマシンセットからアドレスを選択する。ディレクタは、ピングマネージャ（これはピングデーモンからそのデータを収集している）によりそれに与えられるデータに基づいてこの決定をなす。
図２Ｂは、本発明に従う分散コンピュータ（計算）システムの代わりの具体例を図示する。図２Ｂ図の具体例は、主として、この具体例が別個のディレクタサーバを有さないという点で図２Ａの具体例と相違する。図２の具体例においては、図２Ａにおいてディレクタ上に存在するプロセス要素が、図２Ｂにおいてはフロントエンドサーバ２１２，２１４，２１６および２１８間に分散されている。
［3.0  特定のプロセス要素］
図３Ａは、本発明に従う代表的具体例のプロセス要素を図示するものである。
フロントエンド  フロントエンド要素３６０の具体例はデータオブジェクトに対するクライアント要求を受信する。この要求は、好ましい具体例においては、到来ＨＴＴＰ要求とし得る。フロントエンドは、次に、直ちに走査検索中のクライアントＩＰアドレスをディレクタへ送り、そしてディレクタが「最良の」サーバを選択するのを待つことによって、もし利用可能ならばディレクタ要索３６２からの「アドバイス（通知）」を求める。最後に、フロントエンドは、クライアントが次の要求処理のため特定のサーバにコンタクトすべきことを指令する回答を要求中のクライアントに送る。フロントエンドは、クライアント要求のプロトコルを理解しなければならず、そしてアプリケーション固有のメカニズムを使用して、クライアントを特定のサーバに振り向ける。特定の具体例において、フロントエンドは、ブラウザ（走査検索）クライアントに最善サーバのＵＲＬに対するＨＴＴＰ転送応答を送る。本発明の１具体例では、１または複数のユーザレベルプロトコルを理解する複数のフロントエンド要素を含んでよい。
ディレクタ
ディレクタ要素３６２の具体例は、フロントエンド３６０からデータ問合せを受信し、クライアントのソースについてのデータ、好ましくは走査検索中のクライアントＩＰアドレス、ならびにレプリカサーバ状態およびネットワークパス特性、好ましくはＩＣＭＰエコー応答時間（これは好ましくはピングマネージャ３６４および負荷マネージャ３６６のようなコネクタ要素から受信される）を使用してフロントエンドがユーザ要求を直送することを可能にする情報を返す。この決定は、すべてのデータを考慮に入れ、「最良」サーバのＩＰアドレスをフロントエンドに送る。ディレクタ要素は、代替サーバを評価する決定方法を含んでおり、全システムに対する調整を行う。本発明の具体例では、１または複数のディレクタ要素を備える。
コレクタ要素  コレクタ要素の具体例は、ネットワークパスまたはコンテントサーバ負荷の１または複数の特性を監視し、ディレクタ要素がサーバ選択決定において使用のためこのデータを利用することを可能にする。本発明の具体例では、１または複数のコレクタ要素、好ましくは、ピングマネージャ要素３６４，ピングデーモン要素（図示せず）、負荷マネージャ要素３６６および負荷デーモン要素（図示せず）を備える。
ピングマネージャは、コンテントサーバが最速ＩＣＭＰエコーパスを有するかをディレクタに知らせる。このデータはピングマネージャ３６４により収集される。ピングマネージャは、そのピングタイムデータを個々のサーバマシンから受信するが、このマシンは、各々ＩＣＭＰピングを使用して、それ自体と走査検索中のクライアントマシン間のＩＣＰＭルートティング時間を決定する。ピングマネージャは、ついでこの情報を記憶し、それをディレクタに報告し、そしてディレクタはそれを使用して最良のルートについての決定をなす。
ピングデーモンは各コンテントサーバマシンクラスタと関連するサーバマシン上で実行する。コンテントサーバマシン（またはそのクラスタ）は各ネットワークアクセス点近くに存在する。ピングデーモンは、ピング要求（およびその対応するＩＰアドレス、これは走査検索中のクライアントＩＰアドレス）を待ち、ついで走査検索中のクライアントＩＰアドレスをピングし、それ自身の最も近いボーダールータ中のＩＣＭＰルーティング時間を記録する。ピングデーモンは、このデータをピングマネージャに送る。
負荷マネージャソフトウェアは、ピングマネージャに類似であるが、各コンテントサーバマシンの現在負荷についての負荷デーモンからの情報を報告し、記憶する。このデータをディレクタに同様に送る。
負荷デーモンは、各コンテントサーバ３６８と関連してランし、負荷マネージャに報告する。負荷デーモンは、現在オープンのＴＣＰ接続の数、フリーＲＡＭ、フリーＳＷＡＰおよびＣＰＵアイドル時間についてのデータを送る。
図３Ｂは、本発明に従う代替具体例のソフトウェア要素を図示する。図３Ｂの代替具体例のソフトウェア要素線図を図３Ａの具体例と比較すると、二つの具体例間の主たる差は、図３Ｂに図示される具体例においては、ディレクタプロセス３６２が種々のサーバ間において分散されていることである。かくして、図３Ｂにおいては、ディレクタプロセス３６３がディレクタプロセスの三つの別個のインスタンスとして示されている。他方、図３Ａにおいては、ディレクタプロセス３６２は、複数のサーバ上の他のプロセスとのインターフェースを有する単一のディレクタプロセスとして示されている。
図３Ｃは、本発明に従う好ましい具体例のソフトウェア要素を図示する。図３Ｂの具体例のソフトウェア要素線図を図３Ｃの具体例のそれと比較すると、二つの具体例間の主たる相違は、図３Ｃに示される具体例においてはフロントエンドプロセス３６０がＩＰリレーヤ機能を含むことである。
フロントエンド／ＩＰリレーヤ  フロントエンド／ＩＰリレーヤ要素３６０の具体例は、任意のＩＰトラフィックに対する到来するＩＰパケットを受信する。図３Ａおよび図３Ｂにおける具体例におけるように、フロントエンドは、直ちにクライアントＩＰアドレスをディレクタに送り、ディレクタが「最良」サーバを選択するのを待つことによって、ディレクタ要素３６２から「アドバイス」を求める。しかしながら、図３Ａおよび図３Ｂの具体例におけるフロントエンド要素により遂行されるように、クライアントがさらに要求処理のために特定のサーバとコンタクトするように指令するのではなく、ＩＲリレーヤは、ディレクタによりなされる決定にしたがって選ばれた「最良サーバ」にパケットを送る。本発明の具体例では、ＩＰリレーヤにて機能する複数のフロントエンド要素を含んでよい。
［3.2  要求を処理する段階］
図４Ａは、本発明の特定の実施例において、クライアントの要求を受け取り、評価し、回答する過程で起きる一連の段階を示す。段階４０２において、図２Ａの２３２のようなコンテントサーバに存在するロードデーモンは、ディレクタサーバ２５０に存在するロードマネージャ３６６を定期的に更新する情報を直接与える。次いで、段階４０４において、ロードマネージャ３６６はロードデーモンが有する全てのコンテントサーバから集めたロード情報を更新する。これはディレクタ３６２が段階４１０及び４１２のような入り要求に応答して最小負荷コンテントサーバを選択することを可能にする。
段階４１０において、入りクライアント要求は（例えばウェブブラウザのＨＴＴＰ要求、ＦＴＰクライアントからのＦＴＰ要求）、任意の外部経路を経てシステムボーダゲートウエイ、典型的にはネットワークアクセスポイントのルータへ送られる。この時点で、クライアントの要求は本発明のサーバーロード平衡分散型計算システムへの入力となる。それはこのＮＡＰに位置するルータに関連したルート表に従って動作するＩＰによりフロントエンドソフト要素３６０に送られる。段階４１２において、フロントエンドソフト要素は、クライアントアプリケーションの要求の到来に応じて、好ましいサーバに対する要求をディレクタソフト要素３６２に出す。ディレクタは、段階４１２においてクライアント要求に関する情報に対するフロントエンド要求を受け取ったら、段階４１３において、Ｐｉｎｇマネージャ要素３６４のような収集要素に、サーバとクライアントとの間の最も迅速な経路等の情報を要求する。図４Ａの実施例において、最も迅速な経路は、段階４１４においてシステムネットワーク中の種々のＮＡＰ内に共存しているＰｉｎｇデーモン要素と関連して動作するＰｉｎｇマネージャ収集要素３６４により決定される最速ＩＣＭＰエコー応答（Ｐｉｎｇ）を有する経路である。これらのＰｉｎｇデーモン要素はそれらの特定のフロントエンドサーバとクライアントの間の最速ＩＣＭＰエコー応答を、それらの特定のフロントエンドサーバの関連ＮＡＰを介して次々のＰｉｎｇをクライアントに伝送し、段階４１５に示したように応答のタイミングを取ること、により決定する。各Ｐｉｎｇデーモンは刻々に、段階４１６においてその特定のＮＡＰからＰｉｎｇマネージャへのルートを介して時間をクライアントへ送る。段階４１７においてＰｉｎｇマネージャはシステムのＮＡＰに関連した経路に対する周回値をクライアントに返す。特定の実施例では、Ｐｉｎｇマネージャは前進状態質問（pro-active status queries）（図示せず）を開始でき、或いは任意な時点でディレクタの明示の要求なしに状態情報を返すことができる。段階４１８においてディレクタはクライアントにより使用されるべき正しいコンテントサーバをフロントエンド要素に指示する。フロントエンド要素は段階４１９でクライアントをアプリケーションレイヤー・プロトコル（好ましくはＨＴＴＰ転送）を使用して正しいコンテントサーバに差し向ける。フロントエンド応答はＮＡＰを介して例えばＩＰプロトコルを使用するインターネットによりクライアント機に送る。次いで、段階４２０に示したように、クライアントからの要求が彼の機械への最良経路を介して最良コンテントサーバ例えば２３２に送られる（これはまたクライアント自身のネットワークプロバイダに達する外部ネットワークへの最良の入口箇所でもある）。
図４Ｂは本発明の他の実施例において、クライアントの要求を受け取り、評価し、そして回答する過程において生じる一組の段階を示す。図４Ｂに示された実施例の処理段階を図４Ａのそれと比較すると、特定の段階は共通であることが分かる。しかし、段階４１２、４１４、４１８は図４Ａとは違って、ネットワーク取引ではなく、一つのサーバ機内に共存する取引であることが分かる。
図４Ｃは本発明の好ましい実施例において、クライアントの要求を受け取り、評価し、そして応答する過程において生じる一組の段階を示す。図４Ｂに示された実施例の処理段階を図４Ｃのそれと比較すると、特定の段階は共通であることが分かる。しかし、図４Ｂの段階４１９と４２０（転送応答段階及びそれに続くＨＴＴＰ会話段階）が新たな段階４２２により置換されていることが主な違いである。段階４２２ではクライアントからのＩＰトラフィックをディレクタの決定による最良のサーバに中継する。これは図４Ｂにおけるフロントエンド処理によりなされる転送応答段階４１９に代わるものである。図４Ｃの段階４０２、４０４、４１０、４１２、４１３、４１４、４１５、４１６、４１７、及び４１８は図４Ａ、４Ｂの実施例と同一であることがわかる。
図４Ｃは好ましい実施例の処理を示す。段階４１０では、フロントエンド中継ソフト３６０がネットワークに入ってくるパケットに介在する。ＩＰヘッダに含まれているアドレス情報に基づいて、フロントエンドソフトはパケットの元の宛先サーバを決定する。次に、段階４１２において、フロントエンド中継ソフト３６０はディレクタ３６２を呼んで最良サーバルートの決定をする。段階４１３、４１４、４１６、４１７及び４１８では、ディレクタはロードマネージャ３６６、Ｐｉｎｇマネージャ３６４、ロードデーモン及びＰｉｎｇデーモンソフトに基づいてＩＰトラフィックに対する最良のサーバを決定し、この装置のアドレスをフロントエンド中継ソフトに連絡する。この決定過程は図４Ａ、４Ｂにおけるものと同一である。段階４２２において、フロントエンド中継ソフト３６０は全てのパケットをそのセンターから最良のサーバに送る。パケット中継はＬＰレベルで行われるので、ＬＰ層で動作している任意のサービスに対するパケットは本発明の方法によりルート決定し得る。
［4.0  決定方法］
［4.1  ディレクタ］
ディレクタはどのコンテントサーバ及びどのルータがクライアントの要求に対して最良（ベスト）であるかを決定する。図５Ａは本発明の具体的な実施例においてディレクタにより行われる処理段階のフローチャート５００を示す。段階５０１において、ネットワーク距離が各コンテントサーバと出力ルータの各組合せに対して計算される。これらの距離から次の形式を有する順序（ｓｏｒｔｅｄ）リストが作成される。
(sitel borderl metricl、...、siteN borderN metricN)      （３）
段階５０２で、最良サイトに対する候補サーバが上記の段階５０１で作成したリストから選択される。処理はリストを走査し、その中からトップランクの距離と、それからあるＸ％以内にある任意の候補を選択することである。各コンテントサーバはリスト中の出力ルータの全ての組合せと共にリストされていることに注意されたい。無意味なサーバールータ組合せを考慮する必要はないので、例えば、ＬＡボーダを通るＬＡサーバの組合せ（最良と考える）があればＮＹボーダを通るＬＡサーバは考慮する必要がない。例えば、Ｘ＝５とすると、組合せ（site,border,metric）（サイト、ボーダ、距離）の順序リストを文（４）のものとなる。
@network＝(ny ny 300 sj la 305 sj sj 312 ny sj 380 dc ny 400...)      （４）
最初の３つの要素は
ｎｙ ｎｙ ３００
ｓｊ ｌａ ３０５
ｓｊ ｓｊ ３１２
である。これらは全て互いに５％以内になるので、システムは全３つであると考えるであろう。しかし、サンホセ（ＳＪ）は２回リストされており、２回目にリストされたものの時間は１回目のものの時間よりも長いので、１回目のものが２回目のものよりも好ましく、従って、２回目のものは捨てられ、ＮＹ（ニューヨーク）またはＳＪのものが選択される。もしもＮＹが選択されたら、ＮＹのボーダも選択される。もしもＳＪのサーバが選択されたら、ＬＡのボーダが最良として選択される。
段階５０３において、最良サーバは候補の中から選択される。候補サーバに対する全ての距離（metrics）が作成され、統計アルゴリズムを適用して候補から最良のサーバを選択する。この段階の結果は選択されたサーバに対するサイト、及び当該特定サーバに対する識別子である（各サーバには複数のサイトがあり得る）。
段階５０４において、上記の選択されたサーバのサイトから、システムは段階５０２で保存したサイトに対してどのボーダが使用されるべきかを呼び出す。次に、サーバ識別子と出力ボーダから、内部方針ルート指定に対する適正なＩＰアドレスを有する、正しい完全に資格のあるドメイン名を決定する。
４．２  Ｐｉｎｇマネージャ
Ｐｉｎｇマネージャは常時Ｐｉｎｇ情報を一つ以上Ｐｉｎｇデーモンに要求する。Ｐｉｎｇマネージャはディレクタに全てのクライアントサイトからの周回時間を表す一連の値を送る。非応答クライアントサイトは、もしもＰｉｎｇデーモンが応答しない場合には任意の大きい値により表わされる。特定の実施例では、Ｐｉｎｇマネージャはディレクタに次の文（５）、（６）で表されるような列を送る。
”client_address metric_site_1 metric_site2...metric_site_Ｎ＼ｎ”      （５）
”128.9.192.44 3009999999 280 450＼ｎ”      （６）
好ましい実施例では、サイト距離（site metric）は次の文のように順序づけられる。
@incoming_metric_order=(’ny’,’la’,’dc’,’sj’)      （７）
図５Ｂは上記の（５）、（６）に示された情報シーケンスをＰｉｎｇマネージャから受け取るのに応じてディレクタにより実行される処理のフローチャート５１０を示す。段階５１２において、ディレクタはＰｉｎｇマネージャから入ってくる情報に基づいて処理を行い、以下の文（８）のプロトコルにより示される使用可能なフォーマットで情報を記憶する。
($addr,@metrics)=split(″,$incoming_pingmgr_message);      （８）
$ping_cache{addr}=$incoming_ping_message;
$ping_cache_time{$addr}=&get_current_time();
#有用なフォーマットの周回Ｐｉｎｇ距離を記憶する。
0004354532.tif 000002
次に、段階５１４において、フロントエンド処理から受け取った要求に応じて、ディレクタは答えるべき要求についての情報を検索する。形式（９）は段階５１４を処理するための擬似コードを表す。
#答えなければならない要求についての情報を検索
（９）
#
$request_frontend=$request_frontend{$addr};#応答を得る者
$contact_site=$request_contact{$addr};#経路計算に対する必要性
段階５１６において、ディレクタは文（１０）の擬似コードに従ってＰｉｎｇマネージャにより提供されるに方向距離から一方向距離を計算する。
（１０）；
#１方向距離の計算
0004354532.tif 000003
次に、段階５１８において、ディレクタは文（１１）の擬似コードに従って全てのサイトとボーダの組合せに対する経路距離を計算する。
##すべてのサイト／ボーダに対する経路距離を計算
0004354532.tif 000004
次に、段階５２６において、ディレクタは距離を検索して、次の文（１２）の擬似コードを使用して順序リストを作成する。
#距離（metirics）を検索し、そして必要とされるリストを順序構成する
0004354532.tif 000005
この時点で、variable@sortea_listは一対のサイトを選択し、そして候補サーバを選択するのに必要な全ての情報を含む。
［4.3  ロードマネージャ］
ロードマネージャは約２秒ごとにディレクタに文（１３）に示される形式でメッセージを送る。
″serverl loadl server2 load2...serverN loadN″;      （１３）
図５Ｃは、上記（１３）に示したロードマネージャから受け取った情報と文（５）、（６）に示したＰｉｎｇマネージャから受け取った情報を使用して、最良サーバを選択する際に、ディレクタにより実施される段階を示すフローチャート５２１を示す。
ディレクタは、次の、サーバロードの関連した配列とサーバ識別子を有する対ロード値とを含む数個の内部データ構造を維持する。
$load_array{$serverID}=$load;
各サイトのリストは次の通りである。
$servers{’la’}=″www.la1.test.com www.la2.test.com″;
$servers{’dc’}=″www.dc1.test.com www.dc2.test.com″;
対応したソースアドレスを有する正しい名称へのサーバとボーダのマッピングは次の通りである。
$server_map{″www.la1.test.com la″}=″www.la1-la.test.com″;
$server_map{″www.la1.test.com dc″}=″www.la1-dc.test.com″;
上記の生成した可変@sorted_listは、サイトと、ボーダと、経路距離との３つ組を含む。これらのデータ構造から、ディレクタは図５Ｃに記載した段階を使用して最適のサーバを決定できる。決定段階は@sorted_list中の全ての項目が処理されていないことを確認し、そして″best_metric″変数を@sorted_list中の最初の番号の距離に初期化する。これらの段階は次の擬似コードで示される。
%site_border=();
@server_list=();
##トップループは候補パス（及びサイト）の次の組を選択する。
##サーバを選択したときにはループを破る。
#
while(1){
break unless@sorted_list);
$best_metric=@sorted_list[2]*$fuzz_factor=1.05;
図５Ｃに示したように、決定段階５２２、段階５２４、決定段階５２６、及び段階５２８は@sorted_listからサイト、ボーダ及び距離（metric）の３つ組を選択し、ボーダ情報をサイト・ボーダリストに加え、サイトをサーバリストに加えるためのループ構造を実行する。これは次の擬似コードに表現されている。
0004354532.tif 000006
一旦このループが@sorted_listの全てのメンバーを処理したら、決定段階５２２はイェスの経路をたどり、処理は決定段階５３０、処理段階５３２、５３４により、前記の生成したサーバリスト中の全てのサーバを処理するためのループ構造を実行し、各サーバのロードをサーバロードリスとに加え、そして$total変数中の全サーバの負荷を合計する。これも又次の擬似コードにより表現される。
0004354532.tif 000007
一旦このループが@server_listの全てのメンバーを処理したら、図５Ｃの決定段階５３０はイェスの経路をたどり、処理は１と全サーバロードの間のランダム数を決定するための処理段階５３６に進む。次に処理は決定段階５３８及び５４４と処理段階５４０、５４２及び５４６とより形成されるループに続く。$server_listにおけるサーバを通るこのループ諸段階は、全数が段階５３６で選択されたランダム数を超えるまでそれらのロードを加算し、或いは@server_listの最後の数が処理されるまで続く。いずれかの場合に、これらの２つの条件のいずれかが成就されたときに調べられたサーバが最良サーバとしてディレクタに選択されるサーバである。これはまた次の擬似コードにより表現される。
#fencepost値を処理する方法。
#1と$total（この値含む）の間の値を返すべきか。
0004354532.tif 000008
一旦ディレクタが最良サーバを選択したら、処理は図５Ａの段階５０４に記述したように、次の擬似コードにより継続する。
#選択したサイトはどちらか？
$site=$get_site($the_server);
#このサイトに対する最良のボーダに関する情報を呼び出す。
$border=$site_border($site);
#必要とするソースアドレスを使用する正しいネームを取得する。
#
$response_to_request=$server_map{″$the_server$border″};
［5.0  結論］
まとめると、本発明は、データオブジェクトが、利用可能な最短ネットワークパスに従ってユーザに使えるような、インターネット作業システムを提供することが分かる。本発明による方法の更なる利点は、これらの方法が使用するハードウエアに起きる障害を許容することである。更に、本発明のシステムの信頼性は従来のウエッブサーバに比して増大する。本発明の他の実施例及びそれらの構成要素は当業者には上記の説明から容易に明らかになろう。本発明の実施例は本発明の実施に最良と思われる形態を例示する。当然本発明はすべてその範囲を逸脱しないで他の異なった実施例を可能にし、それらの詳細部分は自明な多数の面から修正が可能である。従って、図面及び本明細書が例示であり限定のためではないことを理解すべきである。従って、本発明は請求の範囲に属する限り制限を受けない。
【図１Ａ】
0004354532.tif 000009
【図１Ｂ】
0004354532.tif 000010
【図１Ｃ】
0004354532.tif 000011
【図１Ｄ】
0004354532.tif 000012
【図２Ａ】
0004354532.tif 000013
【図２Ｂ】
0004354532.tif 000014
【図３Ａ】
0004354532.tif 000015
【図３Ｂ】
0004354532.tif 000016
【図３Ｃ】
0004354532.tif 000017
【図４Ａ】
0004354532.tif 000018
【図４Ｂ】
0004354532.tif 000019
【図４Ｃ】
0004354532.tif 000020
【図５Ａ】
0004354532.tif 000021
【図５Ｂ】
0004354532.tif 000022
【図５Ｃ】
0004354532.tif 000023