JP4134357B2 - 分散データ管理方法 - Google Patents
分散データ管理方法 Download PDFInfo
- Publication number
- JP4134357B2 JP4134357B2 JP12524797A JP12524797A JP4134357B2 JP 4134357 B2 JP4134357 B2 JP 4134357B2 JP 12524797 A JP12524797 A JP 12524797A JP 12524797 A JP12524797 A JP 12524797A JP 4134357 B2 JP4134357 B2 JP 4134357B2
- Authority
- JP
- Japan
- Prior art keywords
- url
- server
- data
- servers
- request
- 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 - Fee Related
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/10—File systems; File servers
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Data Mining & Analysis (AREA)
- Databases & Information Systems (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Computer And Data Communications (AREA)
- Information Transfer Between Computers (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、計算機システムに関し、例えばネットワークによって接続された複数の計算機が、情報を流通・共有・変更するシステム（情報システム）内の情報を管理する分散データ管理方法に関し、特にＷｏｒｌｄ―Ｗｉｄｅ Ｗｅｂ（ＷＷＷ）に好適な分散データ管理方法に関する。
【０００２】
【従来の技術】
以下の記述に用いるいくつかの用語をまず説明する。
【０００３】
インターネット上のＷＷＷ、匿名ＦＴＰをはじめとする情報システムは、通常分散コンピュータ・システムの一形態である「クライアント・サーバ・システム」の形態で構築されている。クライアント・サーバ・システムでは、システム全体の処理は２種類に分割され、第１の部分を「サーバ」と呼ばれる実行中のプログラム（以下、プロセスという）で処理し、第２の部分を複数の「クライアント」と呼ばれるプロセスで処理する。情報システムのクライアントは通常、個人または企業内のユーザが操作するコンピュータで動作する。情報システムのサーバは、クライアントに提供する情報を格納する。情報システムのクライアントは、サーバに新たな情報を格納したり、サーバに要請して情報を取得する。
【０００４】
コンピュータ・システムでは、１つの情報を複数の場所に一時的にコピーしておくことにより、当該情報へのアクセスを高速にしたり、アクセスできる可能性を高めることが広く行なわれる。このようなコピーはヒント、キャッシュ、レプリカ、スタッシュ等と呼び分けられる（Ｓａｐｅ Ｍｕｌｌｅｎｄｅｒ編の文献”Ｄｉｓｔｒｉｂｕｔｅｄ Ｓｙｓｔｅｍｓ（１ｓｔ ｅｄ.）”ｐｐ.１３―１５，ＡＣＭ ｐｒｅｓｓ，１９８９参照）。以下ではこれらのコピーを総称して「キャッシュ」と呼ぶ。またキャッシュを作ることを「キャッシュする」と記す。
【０００５】
ＷＷＷでは、ＷＷＷサーバが、発信する情報を「ホームページ」と呼ばれる単位で保持している。ホームページは、それぞれＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒの略）と呼ばれる名前を持っている。ＵＲＬはＷＷＷで用いられるプロトコルと、情報源であるコンピュータのホスト名、および情報源において特定のデータを指定することが可能な文字列である。”ｈｔｔｐ：／／ｗｗｗ.ｈｉｔａｃｈｉ.ｃｏ.ｊｐ／ｉｎｄｅｘ.ｈｔｍｌ”は ＵＲＬの一例である。
【０００６】
なお、一般にＵＲＬは（ホームページのデータや画像データ等の）ひとかたまりのデータに対応づけられるが、以後このひとかたまりのデータのことを「ＵＲＬに対応する情報」または「ＵＲＬ内容」と記す。また、第１のＵＲＬに対応する情報中に含まれる第２のＵＲＬは「ハイパー・テキスト・リンク（または簡単にリンク）」とよばれる。第１のＵＲＬに対応する情報中に第２のＵＲＬが含まれることを、以下「第１のＵＲＬから第２のＵＲＬにリンクがある」と記す。
【０００７】
ＷＷＷで用いられている技術（公知例１）を説明する。
【０００８】
ＷＷＷクライアントのユーザは、アクセスしたいホームページのＵＲＬをＷＷＷクライアントに指定する。ＷＷＷのサーバとクライアントの第１の処理形態では、ＷＷＷクライアントは当該ＵＲＬの第２要素で指定されるＷＷＷサーバに対して、当該ＵＲＬに対応するホームページの送信を依頼する。当該ＷＷＷサーバは、この要求に応えて、当該ホームページを当該ＷＷＷクライアントに与える。
【０００９】
また第２の処理形態では、ＷＷＷクライアントが、ユーザが与えたＵＲＬの第２要素で指定されるＷＷＷサーバに依頼を行なうかわりに、「プロキシ・サーバ」と呼ばれる第２のサーバに依頼を行なう場合もある。当該第２のサーバは、当該ＷＷＷサーバから当該ＵＲＬに対応するホームページを得るか、さらに別のプロキシ・サーバに当該ＵＲＬに対応する情報取得を依頼する。このプロキシ・サーバの依頼が複数段階である場合、プロキシ・サーバは親子関係を持つ。親子関係を持つプロキシ・サーバに関しては、例えばＡ.Ｃｈａｎｋｈｕｎｔｈｏｄ他の文献”Ａ Ｈｉｅｒａｒｃｈｉｃａｌ Ｉｎｔｅｒｎｅｔ Ｏｂｊｅｃｔ Ｃａｃｈｅ”（１９９６ ＵＳＥＮＩＸ Ｔｅｃｈｎｉｃａｌ Ｃｏｎｆｅｒｅｎｃｅ，ｐｐ.１５３―１６３，１９９６）に記載されている。
【００１０】
なお、ＷＷＷのクライアントやプロキシ・サーバは、キャッシュを持つことができる。クライアントが持つキャッシュは、以前に当該クライアントが取得したホームページを保持しており、当該クライアントのみが利用する。プロキシ・サーバがもつキャッシュは、当該プロキシ・サーバが１つ以上のクライアントまたは他の１つ以上のプロキシ・サーバまたはその両方の依頼によって取得したホームページを保持しており、当該プロシキ・サーバを利用するクライアントおよびプロキシ・サーバによって共用される。
【００１１】
ネットワーク・ニュース・システム（以後公知例２と呼ぶ。Ｂ.Ｋａｎｔｏｒ他著の文献”Ｎｅｔｗｏｒｋ Ｎｅｗｓ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ：Ａ Ｐｒｏｐｏｓｅｄ Ｓｔａｎｄａｒｄ ｆｏｒ ｔｈｅ Ｓｔｒｅａｍ―Ｂａｓｅｄ Ｔｒａｎｓｍｉｓｓｉｏｎ ｏｆ Ｎｅｗｓ”Ｎｅｔｗｏｒｋ Ｗｏｒｋｉｎｇ Ｇｒｏｕｐ ＲＦＣ―９７７等に記載されている）は、１つ以上のサーバによって構成される。ユーザは通常、クライアントを用いて当該複数のサーバのうち１つを選択して利用する。ネットワーク・ニュース・システムにおける情報の単位は「ニュース記事」と呼ばれる。ユーザは通常、クライアントを用いてニュース記事をサーバに提供する操作と、ニュース記事をサーバから取り出す操作を行なう。ユーザがニュース記事が第１のサーバに提供すると、第１のサーバは１つ以上の第２のサーバに当該ニュース記事のコピーを送り、さらに第２のサーバが別のサーバに当該ニュース記事のコピーを送る、という具合で、最終的には上記複数のサーバすべてに当該ニュース記事がコピーされる。
【００１２】
公知例３として、広域名前サービスＤｏｍａｉｎ Ｎａｍｅ Ｓｙｓｔｅｍを説明する。（以下ＤＮＳと略す。例えばＰ.Ｍｏｃｋａｐｅｔｒｉｓ著の文献”Ｄｏｍａｉｎ Ｎａｍｅｓ―Ｉｍｐｌｅｍｅｎｔａｔｉｏｎ ａｎｄ Ｓｐｅｃｉｆｉｃａｔｉｏｎ”Ｎｅｔｗｏｒｋ Ｗｏｒｋｉｎｇ Ｇｒｏｕｐ ＲＦＣ―１０３５の特に第２節に記載されている）ＤＮＳは主にシンボリックなホスト名と、そのホスト名の付随情報（ＩＰアドレスやメールサーバ）とを対応づける。複数のＤＮＳサーバは木構造を構成する。クライアントの依頼は当該木構造をたどって、複数のサーバの間を転送され、処理される。ＤＮＳのクライアントであるｒｅｓｏｌｖｅｒは、あるホスト名に対応するホスト関連情報をサーバの１つに依頼する。この際当該サーバは、当該ホスト名に対応するホスト関連情報をクライアントに返すか、当該ＤＮＳサーバの親サーバ（ＤＮＳサーバの木構造において根に一段近いＤＮＳサーバ）に当該依頼を転送する。なお親サーバは、直接の子サーバ群がどのホスト関連情報を持つかを把握している。このため、木構造の根まで依頼が転送されると、今度は木構造を下って依頼を処理できるＤＮＳサーバの方に依頼を転送する。依頼は最終的に、ホスト関連情報を保持するＤＮＳサーバに到達して、クライアントにホスト関連情報が返されるか、木構造を下っていく段階で、当該依頼のホスト名に対応するホスト関連情報がどのＤＮＳサーバからも提供されていないことが判明して、クライアントに失敗が返される。
【００１３】
ローカル・エリア・ネットワーク（ＬＡＮ）内の分散ファイルシステムにおいて、キャッシュのための空間を複数のコンピュータで共有する方法も知られている（公知例４）。Ｍｉｃｈａｅｌ Ｄａｈｌｉｎ他著の文献”Ｃｏｏｐｅｒａｔｉｖｅ Ｃａｃｈｉｎｇ：Ｕｓｉｎｇ Ｒｅｍｏｔｅ Ｃｌｉｅｎｔ Ｍｅｍｏｒｙ ｔｏ Ｉｍｐｒｏｖｅ Ｆｉｌｅ Ｓｙｓｔｅｍ Ｐｅｒｆｏｒｍａｎｃｅ”（Ｆｉｒｓｔ ＵＳＥＮＩＸ Ｓｙｍｐｏｓｉｕｍ ｏｎ Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍｓ Ｄｅｓｉｇｎ ａｎｄ Ｉｍｐｌｅｍｅｎｔａｔｉｏｎ，ｐｐ.２６７―２８０，１９９４）では、クライアントはまず「マネージャ」と呼ばれるサーバに、ファイルブロックを依頼する。マネージャは、どのファイル・ブロックがどのコンピュータに格納されているかを保持しており、クライアントにファイル・ブロックが格納されているコンピュータを返答するか、当該コンピュータにクライアントの要求を転送する。同様の方法としては、Ｍ.Ｊ.Ｆｅｅｌｅｙ他著の文献”Ｉｍｐｌｅｍｅｎｔｉｎｇ Ｇｌｏｂａｌ Ｍｅｍｏｒｙ Ｍａｎａｇｅｍｅｎｔ ｉｎ ａｎ Ｗｏｒｋｓｔａｔｉｏｎ Ｃｌｕｓｔｅｒ”（ＡＣＭ １５ｔｈ Ｓｙｍｐｏｓｉｕｍ ｏｎ Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍｓ Ｐｒｉｎｃｉｐｌｅｓ，ｐｐ.２０１―２１２，１９９５）や Ｐ.Ｓａｒｋａｒ他著の文献”Ｅｆｆｉｃｉｅｎｔ Ｃｏｏｐｅｒａｔｉｖｅ Ｃａｃｈｉｎｇ Ｕｓｉｎｇ Ｈｉｎｔｓ”（Ｓｅｃｏｎｄ ＵＳＥＮＩＸ Ｓｙｍｐｏｓｉｕｍ ｏｎ Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍｓ Ｄｅｓｉｇｎ ａｎｄ Ｉｍｐｌｅｍｅｎｔａｔｉｏｎ，ｐｐ.３５―４６，１９９６）が知られている。マネージャは複数存在することができるが、ファイル・ブロックとマネージャとの対応関係はあらかじめ定められており、全クライアントおよびサーバがその対応関係を知っている。この対応関係はシステム動作中に変化しない。
【００１４】
公知例５および公知例６として、ｃａｃｈｅ―ｃｏｈｅｒｅｎｔ ｎｏｎ―ｕｎｉｆｏｒｍ ｍｅｍｏｒｙ ａｃｃｅｓｓ（ＣＣ―ＮＵＭＡ）やｃａｃｈｅ ｏｎｌｙ ｍｅｍｏｒｙ ａｃｃｅｓｓ（ＣＯＭＡ）と呼ばれる種類の計算機で用いられている技術を説明する。ＣＣ―ＮＵＭＡ計算機やＣＯＭＡ計算機では、メモリの断片（キャッシュライン）を多数のプロセッサの近くにキャッシュし、それらキャッシュの間の一貫性を保つ機構が含まれている。特に以下の２つの方法が知られている。
【００１５】
第１の方法（公知例５）は、上記マネージャに相当する「ホーム」と呼ばれる処理装置またはデータが、メモリの断片がどのプロセッサによってキャッシュされているかを把握しておく方法である。Ｊｅｆｆｒｅｙ Ｋｕｓｋｉｎ他著の文献”Ｔｈｅ Ｓｔａｎｆｏｒｄ ＦＬＡＳＨ Ｍｕｌｔｉｐｒｏｃｅｓｓｏｒ”（Ｐｒｏｃｅｅｄｉｎｇｓ ｏｆ ｔｈｅ ２１ｓｔ Ａｎｎｕａｌ Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｓｙｍｐｏｓｉｕｍ ｏｎ Ｃｏｍｐｕｔｅｒ Ａｒｃｈｉｔｅｃｔｕｒｅ，ｐｐ.３０２―３１４，ＡＣＭ，１９９４）に記載のシステム等で第１の方法が用いられている。
【００１６】
第２の方法（公知例６）は、キャッシュの作成と削除と通信方法に一定の制約を課すことによって、一定回数の通信（通常マルチキャストまたはブロードキャストを含む）でキャッシュの特定と一貫性の保持ができることを保証する方法である。Ｈｅｎｋ Ｌ.Ｍｕｌｌｅｒ他の文献”Ｔｈｅ Ｄａｔａ Ｄｉｆｆｕｓｉｏｎ Ｍａｃｈｉｎｅ ｗｉｔｈ ａ Ｓｃａｌａｂｌｅ Ｐｏｉｎｔ―ｔｏ―Ｐｏｉｎｔ Ｎｅｔｗｏｒｋ”（Ｔｅｃｈｎｉｃａｌ Ｒｅｐｏｒｔ ＣＳＴＲ―９３―１７，Ｄｅｐａｒｔｍｅｎｔ ｏｆ Ｃｏｍｐｕｔｅｒ Ｓｃｉｅｎｃｅ，Ｕｎｉｖｅｒｓｉｔｙ ｏｆ Ｂｒｉｓｔｏｌ，Ｏｃｔｏｂｅｒ １９９３）に記載のシステム等で第２の方法が用いられている。
【００１７】
【発明が解決しようとする課題】
現在のインターネット全体の通信性能はユーザの要求する速度に遠く及んでおらず、多くの不安定要因を抱えている。ＷＷＷの爆発的な普及により、多くのワイド・エリア・ネットワーク（ＷＡＮ）で混雑が起こっている。高速なバックボーン通信回線が日々増強されている一方で、家庭からのインターネット利用者は、一般的なＬＡＮよりも非常に遅い通信回線を用いてインターネットに接続している。現在でもＷＷＷサーバとインターネットのユーザ数は増加の一途をたどっており、１９９６年１月のある統計では、全世界のインターネット利用のコンピュータは９００万台、６ヶ月弱で２倍の速度で増加している。
【００１８】
このため、インターネットの通信回線には不均一性と不安定性がある。ここでの不均一性とは、様々な通信回線が混在していることを指す。例えば、通信回線によってスループット（単位時間当りの通信データ量）とレイテンシ（通信が受ける遅延時間）が異なることがあげられる。ここでの不安定性とは、通信回線のスループットとレイテンシが刻一刻と変化し、場合によっては通信不能になったりすることを指す。例えば、時間帯や曜日によって通信回線の混雑が変化したり、ある通信回線の増強によってルーティングのパターンが変更され、別の通信回線が混雑したり混雑が解消されたりすることを指す。
【００１９】
このような状況を鑑み、ユーザにより快適な情報システムのサービスを行なうために、ユーザがクライアントに要求を発してから、その要求が満たされるまで時間を短縮することが本発明の目的である。以下この目的を実現する上での課題と、公知の技術との隔たりを説明する。
【００２０】
第１に、公知の技術では、ある通信回線が不安定な状況下では、たとえ別の通信回線が正常に動作していてもクライアントの依頼を高速に処理できない場合があった。
【００２１】
公知例１のＷＷＷのクライアントやＷＷＷのプロキシ・サーバは、ＵＲＬによって指定された特定のＷＷＷサーバまたは特定のプロキシ・サーバと通信する。このため、当該サーバ（またはプロキシ・サーバ）への通信回線が混雑していたり、不通である場合には、たとえ別の通信回線が正常に動作していても、クライアント（またはプロキシ・サーバ）がホームページの入手に長時間を要したり、ホームページの入手ができない。また同じ理由で、ある時点で低速だった通信回線が増強等により高速になったとしても、その利益を享受することが困難だった。公知例２から公知例５でも、クライアントとサーバ、またはサーバと別のサーバの通信が、あらかじめ定められた相手とのみ行なわれる点は公知例１と共通しており、上記の問題がある。一方公知例６は、１つの計算機または物理的に密接に結び付いた複数の計算機で使用する技術であり、マルチキャストまたはブロードキャストが不具合なく動作することを前提としている。このためＬＡＮ環境やＷＡＮ環境にひろく適用することは困難である。また同じ理由で、特定の通信回線が混雑していたり、不通である場合には（たとえ別の通信回線が正常に動作していても）、キャッシュラインの入手に長時間を要したり、キャッシュラインの入手ができない。
【００２２】
第２に、公知の技術では通信回線が不安定な状況下でキャッシュの利用率をあげることが達成されていなかった。
【００２３】
公知例１、２、３、５では、複数のサーバ（またはクライアントとサーバ）がキャッシュを持つ場合、これら複数のキャッシュは階層構造をなす。クライアントが発する依頼には、当該依頼を処理する責任を持つ特定の第１のサーバが存在している。当該依頼は、当該第１のサーバに直接送信されるか、当該第１のサーバとクライアントの間の１つ以上の第２のサーバの間を順に転送される（この場合、当該１つ以上の第２のサーバは依頼の内容によって一意に決定される）。前者の場合、当該依頼は当該第１のサーバのキャッシュしか利用できない。また後者の場合には、当該１つ以上の第２のサーバのキャッシュしか利用できない。すなわち第１、第２のサーバの他のサーバのキャッシュは利用されず、キャッシュの利用率が低い。例えば公知例１のＷＷＷのプロキシ・サーバは親子関係を持つので、プロキシ・サーバＡ、Ｂ、Ｃが存在してＡが親、ＢとＣがＡの子として動作している場合、ＢはＡに依頼を転送することによってＡのキャッシュを利用することができるが、ＢがＣのキャッシュを利用することはできない。また公知例２では、各ニュース記事は、当該ニュース記事を必要とするすべてのサーバにコピーされる。このため、各サーバは他のサーバのキャッシュを全く利用せず、したがって各サーバが大規模な二次記憶を用意する必要がある。一方、公知例４はＬＡＮ環境を仮定しており、キャッシュの利用率をあげる目的で、１つのデータのコピーが複数のキャッシュ中でできるだけ少数になるような制御が行なう。しかし、通信回線が不安定な場合には、クライアントの依頼が少数のキャッシュに到達できない場合があり、逆にキャッシュの利用率が低くなる恐れがある。公知例６は、複数のキャッシュのうち最も短時間で利用できるキャッシュを選択するが、この際にマルチキャストまたはブロードキャストが用いられる。このため、公知例６の方法を通信回線が不安定になる可能性があるＬＡＮ環境やＷＡＮ環境にひろく適用することは困難である。
【００２４】
第３に、公知の技術ではデータとデータの間の参照関係の使用頻度を複数のサーバが交換する方法を持たなかった。
【００２５】
ＷＷＷのホームページとハイパー・テキスト・リンクに代表されるように、情報システムが提供するデータには参照関係があり、参照関係のなかでも頻繁にたどられる参照関係（使用頻度の高い参照関係）があることが多い。参照関係の使用頻度情報は、プリフェッチなどに利用できる。頻繁にたどられる参照関係で結ばれた一連の情報をクライアントからの依頼以前にプリフェッチしておけば、クライアントからの依頼があった時に通信回線が不安定でも、当該一連の情報の依頼は高速に処理することができるためである。特に複数のサーバが存在する場合、参照関係の使用頻度情報は、個々のサーバがそれぞれ収集するより、複数のサーバが収集した情報を交換して集計する方がより確からしい情報となる。しかし公知例１から６では、参照関係の使用頻度情報を複数のサーバが交換する方法を持たなかった。このため、参照関係の使用頻度情報の確からしさに限界があり、プリフェッチの効果も限られていた。
【００２６】
第４に、公知の技術ではキャッシュの入れ替えに通信回線の不均一性と不安定性が考慮されていなかったため、重要なキャッシュを破棄する恐れがあった。
【００２７】
公知例１、２、３では、各サーバ（またはクライアント）が、利用履歴等に基づいてそれぞれのキャッシュの入れ替えを行なう。公知例４はＬＡＮ環境での使用を想定しているため、キャッシュの入れ替えの際のキャッシュの優先度づけに、通信回線の状態は考慮されない。また、公知例５と６も、１つの計算機または物理的に密接に結び付いた複数の計算機で使用することを想定しているため、キャッシュの入れ替えの際のキャッシュの優先度づけに、通信回線の状態は考慮されない。この結果、公知例１から６のいずれでも、現在の通信状態では再び入手することができない、または入手に長時間を要するキャッシュを破棄する場合がある。
【００２８】
第５に、公知の技術ではいずれも、第１のサーバが１つ以上の第２のサーバからの依頼を受ける場合に、第２のサーバが第１のサーバを無制限に利用し、結果として第１のサーバを過負荷におとしいれることに対する対策がなかった。このため、複数のサーバが複数のユーザの組織を越えて依頼を行ないあうことが困難だった。公知例１、２、３は、クライアント・サーバ・システムであるため、サーバが依頼を拒否すると、クライアントの依頼が処理されない。一方、公知例４、５、６は限られた範囲の複数のサーバが依頼を行ないあうため、第１のサーバの過負荷を問題にする必要がなかった。
【００２９】
【課題を解決するための手段】
本発明では、複数のサーバを用い、複数のキャッシュを複数のサーバが保持することによって、１つの情報システムのサービスを提供する。
【００３０】
第１の課題を解決するため、以下の３つの手段を講じる。
【００３１】
（１）第１のサーバが必要とするデータ（以後必要データと呼ぶ）を入手しようとする際、当該必要データは本発明の方法で用いる複数のサーバのうち、２つ以上の第２のサーバにキャッシュされている可能性がある。この際第１のサーバは、第１のサーバと第２のサーバが過去に行なった通信履歴を保持し、当該通信履歴を用いて第２のサーバから１つ以上の第３のサーバを選択して、第３のサーバに必要データの送信を依頼する。この通信履歴から第１のサーバは、現時点で高速に必要データの入手が可能と予測される第３のサーバを選択できる。このため、高速に通信できる通信回線を選択的に用いてクライアントの依頼を処理可能となる。
【００３２】
（２）第１のサーバは、必要データを入手するための第３のサーバを２つ以上選択し、これら複数のサーバに対して同時に依頼を送信することにより、クライアントの依頼を高速に処理することを試みる。これだけでは当該複数のサーバからほぼ同時に依頼の返答が開始されて、却って通信の速度を下げる恐れがある。そこで、当該２つ以上の第２のサーバのうち、１つ以上の第３のサーバには必要データを直ちに送信することを依頼し、別の１つ以上の第４のサーバには、必要データの送信を待機することを依頼する。第３のサーバからの必要データの送信が長時間を要するか、不可能であることが判明した時点で、すでに待機している第４のサーバから直ちに必要データの送信を受けられる。このため、通信回線の状況が変化した場合にもクライアントの依頼を高速に処理可能となる。
【００３３】
（３）第１のサーバは、当該第１のサーバと１つ以上の他のサーバとの過去の通信に関する、第１の時間にわたる、第２の時間間隔毎の通信の履歴（時間毎通信履歴）を持つ。当該時間毎通信履歴は、通信回線の状況が周期的に変化する場合（例えば昼間は混雑しているが夜間は混雑していない通信回線を用いる場合等）に、第１のサーバが通信を行なう時刻の選択を可能にする。これら３つの手段によって本発明は、高速に通信できる通信回線を選択的に利用し、若しくは高速に通信できる時間帯に選択的に利用して、通信回線が不安定または不均一な状況下で、クライアントの依頼を高速に処理する。
【００３４】
第２の課題を解決するために、第１のサーバは、当該第１のサーバが持つキャッシュの一覧の一部または全部を、１つ以上の第２のサーバに通信する。この際当該１つ以上の他のサーバは前記通信回線の状況の履歴を用いて選択する。これにより、第１のサーバのキャッシュの一覧を、その時点で高速に通信できる第２のサーバに通信することができる。このため、第１のサーバと第２のサーバの間の通信回線が正常な場合には、他の通信回線が不安定でも、第２のサーバが第１のサーバのキャッシュを利用可能となる。
【００３５】
第３の課題を解決するために、クライアントが第１のデータを依頼した後に、１つ以上の第２のデータを依頼する可能性が高い場合に、第１のサーバは第１のデータと第２のデータの対応関係（参照関係情報）を持ち、かつ当該参照関係情報を１つ以上の第２のサーバに送信する。この手段を用いて本発明の複数のサーバは、参照関係情報を他のサーバと交換し、頻繁にたどられる参照関係の使用頻度の確からしさを向上させる。これにより頻繁に依頼される一連のデータをクライアントに高速に提供する。
【００３６】
また参照関係情報をプリフェッチに用いることによって、多数のデータを同時に依頼することが可能になる。この際本発明ではサーバが複数あることを利用して、複数のサーバが階層的なパイプライン状にプリフェッチを行ない、特定のサーバにボトルネックを生じたり、特定のネットワークが過負荷になってプリフェッチが効果的に行なわれない等の問題を避ける。
【００３７】
第４の課題を解決するために、第１のサーバは前記通信回線の状況の履歴を用いて情報の単位のアクセス頻度および最終アクセス時間、平均スループット、平均レイテンシ、他のサーバのキャッシュの内容から、キャッシュの優先度づけを行ない、この優先度に基づいてキャッシュの入れ替えを行なう。これにより、現在の通信状態では再び入手ことができない、または入手に長時間を要するキャッシュを破棄することを避けることが可能となる。
【００３８】
第５の課題を解決するために、第１のサーバが、１つ以上の第２のサーバの必要データの送信の全体を一定時間内に一定量以下、または一定時間内に一定回数以下に制限する手段を持ち、一方で第２のサーバの各々は、第１のサーバを含む２つ以上の第３のサーバに、必要データの送信を依頼する。これにより、第１のサーバが第２のサーバからの依頼によって過負荷になることを防ぎつつ、第２のサーバの処理を妨げないことが可能となる。本発明が複数のサーバからなっており、ひとつのサーバが依頼を拒否しても、他のサーバが依頼を処理することが可能なため、この手段が有効となる。
【００３９】
これらの手段によって、本発明は、インターネットの通信回線の不均一性と不安定性がある状況下でも、ユーザがクライアントに要求を発してから、その要求が満たされるまで時間を短縮する。また特定の通信回線が不通でも、できる限りクライアントの依頼を処理する。これによりユーザにより快適な情報システムのサービスを行なう。
【００４０】
【発明の実施の形態】
以下、本発明の実施の一形態を、図面を参照しながら説明する。なお、簡単のため、本明細書中では「発明の実施の形態」を、単に「実施例」と呼ぶことにする。
【００４１】
全体構成
本実施例は、他の情報システムから入手する情報とユーザが入力する情報を、分散した１つ以上のキャッシュに保持する分散データ管理方法を搭載した計算機システムである。図２に本実施例の全体を示す。本実施例の全体２０１は分散コンピュータ・システムであり、ネットワーク２０２と、ネットワーク２０２によって相互接続された１つ以上の計算機２０３、２０３’、２０３’’、…からなる。
【００４２】
ネットワーク２０２は、ある団体（企業や学校や類似の団体）の全体や位置部門でよく使用されるＬＡＮでもよく、また地理的に分散した複数の地点を結合するＷＡＮの一部または全部でもよい。またネットワーク２０２は、計算機間結合網や並列計算機内部のプロセッサ要素間の結合網でもよい。
【００４３】
計算機２０３、２０３’、２０３’’、…は、それぞれ１個以上のクライアントまたは１個以上のサーバまたはその両方を動作させる。本実施例の全体２０１で、少なくとも１つのサーバ２０５と少なくとも１つのクライアント２０４が存在する。なお以下で、本実施例の全体に含まれるサーバ群を「本システム」と呼ぶことがある。計算機２０３、２０３’、２０３’’、…は、いわゆるパーソナル・コンピュータ、ワークステーション、並列計算機、大型計算機等、任意のコンピュータでよい。また、クライアント２０４、２０４’、２０４’’、…を動作させる計算機２０３、２０３’、２０３’’、…は、サーバ２０５、２０５’、２０５’’、…と通信する機能をもっていればよい。すなわち各種コンピュータ端末装置、携帯通信端末（いわゆるパーソナル・デジタル・アシスタンスＰＤＡやハンドヘルド・パーソナル・コンピュータＨＰＣ）、ネットワーク・コンピュータなどでも差し支えない。なお、図２に示した計算機２０３、２０３’、２０３’’、…、クライアント２０４、２０４’、２０４’’、…、およびサーバ２０５、２０５’、２０５’’、…の数と構成は、例として示したもので、本発明の範囲を限定するものではない。
【００４４】
クライアント２０４は、ＷＷＷで使われる各種プロトコル、すなわちＨＴＴＰ（Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌの略）プロトコル、ＦＴＰ（Ｆｉｌｅ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌの略）プロトコル等を用いてサーバ２０５と通信を行なう。クライアント２０４は、グラフィック・ユーザ・インターフェースを備えたＷＷＷブラウザ、テキスト表示のみを行なうＷＷＷブラウザ、ワード・プロセッサや表計算ソフトウェアに内蔵されたＷＷＷのクライアント、ＷＷＷのプロキシ・サーバ等でよい。なお、クライアント２０４が用いるプロトコル、およびクライアント２０４の種類は例として示したもので、本発明の範囲を限定するものではない。
【００４５】
サーバ２０５、２０５’、２０５’’、…は、ＷＷＷサーバ、ＷＷＷプロキシ・サーバ、匿名ＦＴＰサーバ、ユーザの入力等の「情報源」から、クライアントに提供する情報を入手して、ＵＲＬと組にして保持する。サーバ２０５、２０５’、２０５’’、…は上記情報の入手を、上記情報源のそれぞれに定期的に（例えば１時間に一度）接続して新規情報を得る、上記情報源から新規情報の発生を通知して貰う、等の方法で行なう。なお、サーバ２０５、２０５’、２０５’’、…がクライアントに提供する情報を入手する情報源および方法は、例として示したもので、本発明の範囲を限定するものではない。また、本実施例のサーバ２０５、２０５’、２０５’’、…が持つ情報にはＵＲＬが付与されており、かつサーバはＵＲＬを用いてＵＲＬ内容の管理を行なうが、サーバが持つ情報を何らかの形式で指定することができればよく、ＵＲＬに限ることはない。このため、本発明の範囲を限定するものではない。さらに本発明の実施は、クライアントまたはサーバのオペレーティング・システム、サーバ間またはサーバ・クライアント間のネットワークの種類およびネットワークの物理層プロトコルやトランスポート層プロトコル、もしくはサーバとクライアントが単一のコンピュータ上にあるか異なるコンピュータ上にあるかには依存しない。
【００４６】
クライアントとサーバの動作の概略
図１を用いてクライアント２０４とサーバ２０５の動作の概略を説明する。なお、サーバ２０５とクライアント２０４、他のサーバ２０５’、２０５’’、…を繋いでいるネットワーク２０２はここには図示していない。また、図１中の矢印は主要なデータの流れである。
【００４７】
サーバ２０５は依頼処理部１０１、プリフェッチ部１０２、サーバ間メッセージ処理部１０３の各処理部分と、ホームページキャッシュ１０４、アクセス戦略表１０５、頻度ＤＢ１０６、ホームページグループ表１０７の各データ構造を持つ。
【００４８】
サーバ２０５のホームページキャッシュ１０４は、サーバ２０５が動作する計算機２０３の持つ不揮発性記憶装置（磁気ハードディスク、光ディスク等。以下「二次記憶」と記すことがある）または揮発性記憶装置（メインメモリ、キャッシュメモリ等。以下「主記憶」と記すことがある）またはその両方に格納される。なお、ホームページキャッシュ１０４は不揮発性記憶装置に格納される場合でも揮発性記憶装置に格納される場合でも、一個所に格納される必要はない。例えば、サーバ２０５が動作する計算機２０３が３つの磁気ハードディスクを持っていれば、ホームページキャッシュ１０４をこれら３つの磁気ハードディスクの一部または全部に分割して格納しても差し支えない。むしろ、複数の磁気ハードディスクを用いることは、磁気ハードディスクへのアクセスの並列性を増し、もってホームページキャッシュ１０４の読み書きを高速化するために、必須ではないが望ましい。また当該サーバ２０５は情報のキャッシュをすることが重要な役割であるため、当該サーバ２０５には大容量のホームページキャッシュ１０４を構成するのに十分な記憶装置が付属していることが、必須ではないが望ましい。
【００４９】
クライアント２０４が、本システムから第１のＵＲＬに対応する情報である第１のＵＲＬ内容を取得する際には、本システムの任意の第１のサーバ２０５に、第１のＵＲＬを含む依頼１２０を送信することによって、第１のＵＲＬ内容の取得を依頼する。
【００５０】
依頼１２０は依頼処理部１０１が受け取り、ホームページキャッシュ１０４に依頼されたＵＲＬ内容があるかどうかを検索する（１３０）。もしあれば、当該ホームページキャッシュ１０４をアクセスして、第１のＵＲＬ内容をクライアント２０４に返答１２１で送信する。
【００５１】
アクセス戦略表１０５は、本システムの他のサーバ２０５’、２０５’’、…がどのＵＲＬ内容を保持しているかの記録、及び第１のサーバ２０５から行なった過去の通信の速度（例えばスループットやレイテンシ）の記録を保持している。第１のＵＲＬ内容が第１のサーバ２０５のホームページキャッシュ１０４内になければ、第１のサーバ２０５はアクセス戦略表１０５を参照して依頼を転送すべき第２のサーバ２０５’、２０５’’、…を決定する（１３１）。そして第２のサーバ２０５’、２０５’’、…および第１のＵＲＬ内容の情報源のうち１つ以上に、依頼１２２により依頼１２０を転送する。第１のサーバ２０５は、依頼を転送した第２のサーバ２０５’、２０５’’、…または情報源の少なくとも１つから第１のＵＲＬ内容が返答１２３によって得られると、得られた第１のＵＲＬ内容をクライアント２０４に返答１２１によって送る。なお、上記依頼１２０、返答１２１、依頼１２２、返答１２３はいずれも、ネットワーク２０２を通じて行なわれてもかまわないし、計算機２０３、２０３’、２０３’’、…の持つ通信機能を用いて行なわれてもかまわない。
【００５２】
第１のサーバ２０５は返答１２３によって第１のＵＲＬ内容が得られると、第１のサーバ２０５のホームページキャッシュ１０４に第１のＵＲＬ内容を追加する（１３３）。この場合には、当該第１のＵＲＬ内容が追加されたことを伝えるホストＵＲＬメッセージ１２４が本システムの他のサーバ２０５’、２０５’’、…の一部または全部に送信される。またホームページキャッシュ１０４に第１のＵＲＬ内容を追加する際、別の第２のＵＲＬ内容がホームページキャッシュ１０４から削除される場合があるが、この場合には、当該第２のＵＲＬ内容が削除されたことを伝えるホストＵＲＬメッセージ１２４が本システムの他のサーバ２０５’、２０５’’、…の一部または全部に送信される。
【００５３】
頻度ＤＢ１０６は、後に述べるように、どのＵＲＬ内容がいつ参照されたかという頻度情報を記録している。ホームページグループ表１０７は、連続して依頼されたことが多かった複数のＵＲＬ内容の組を記録している。第１のサーバ２０５のプリフェッチ部１０２は返答１２１の後、依頼１２０による頻度情報の変化を頻度ＤＢ１０６に反映する（１３５）。頻度情報の変化は、頻度ＤＢ１０６の更新内容を伝えるホスト頻度メッセージ１２５によって本システムの他のサーバ２０５’、２０５’’、…の一部または全部に送信される。さらに、プリフェッチ部１０２は頻度ＤＢ１０６の内容に基づいてホームページグループ表１０７を更新する（１３６）。
【００５４】
次に、将来依頼されやすいと考えられるＵＲＬ内容を頻度ＤＢ１０６およびホームページグループ表１０７を用いて決定する（１３７および１３８）。当該ＵＲＬ内容が１個以上あれば、それらは依頼処理部１０１が上記依頼１２０と同様に受信する。
【００５５】
また、サーバ間メッセージ処理部１０３は、本システムの他のサーバ２０５’、２０５’’、…からホストＵＲＬメッセージ１２４’を受信するとアクセス戦略表１０５を書き換える（１４０）。また、本システムの他のサーバ２０５’、２０５’’、…からホスト頻度メッセージ１２５’を受信すると頻度ＤＢ１０６を書き換える（１４１）。
【００５６】
以上がクライアント２０４とサーバ２０５の動作の概略である。以下ではこれらをさらに詳しく説明する。
【００５７】
サーバの内部動作の詳細
図３に、サーバ２０５の内部構成を示す。依頼処理部１０１は、依頼入力部３０１、キャッシュ表参照部３０２、処理戦略部３０３、受信部３０４、返答部３０５、キャッシュ入れ替え部３１０からなる。プリフェッチ部１０２は、リンク統計更新部３０６、グループ更新部３０７、プリフェッチ戦略部３０８、プリフェッチスケジュール部３０９、タイマー３１１からなる（サーバ間メッセージ処理部１０３は図３には示していない）。
【００５８】
サーバ２０５のデータ構造は、ホームページキャッシュ１０４、アクセス戦略表１０５、頻度ＤＢ１０６（アクセス頻度表３２５、リンク頻度表３２６、外部アクセス頻度表３２７、外部リンク頻度表３２８からなる）、ホームページグループ表１０７、およびアクセス戦略表１０５を構成するためのキャッシュディレクトリ３２３と通信コスト表３２４、およびホスト表の各データ構造を持つ（ホスト表は図示していない）。これらのデータ構造はすべて、主記憶と二次記憶の片方または両方に存在してかまわない。なお、図３において、太い矢印は主要な制御の流れを、また細い矢印は主要なデータの流れを表わす。また、本実施例では請求項における必要データはＵＲＬ内容であり、請求項における通信履歴は、アクセス戦略表１０５と通信コスト表３２４に、データ保持確率はキャッシュディレクトリ３２３に、時間毎通信履歴は頻度ＤＢ１０６に、参照関係情報はホームページグループ表１０７に、それぞれ格納される。また、サーバ間で通信されるデータの一覧はホストＵＲＬメッセージ１２４の形式で通信される。
【００５９】
サーバ２０５内部の処理の説明に先立って、各データ構造の概略を説明する。各データ構造の詳細な説明は、サーバ２０５内部の処理の説明とあわせて行なう。図４に、ホームページキャッシュ１０４、アクセス戦略表１０５、キャッシュディレクトリ３２３、通信コスト表３２４、アクセス頻度表３２５、リンク頻度表３２６、外部アクセス頻度表３２７、外部リンク頻度表３２８の構成を示す。
【００６０】
ホームページキャッシュ１０４は、キャッシュの本体である。ＵＲＬ４０１と、ＵＲＬ４０１の内容であるＵＲＬ内容４０２を組にして保持する。この組は通常複数ある。
【００６１】
アクセス戦略表１０５は、下に述べるキャッシュディレクトリ３２３と通信コスト表３２４とを、現在の使用のために組み合わせたものである。ＵＲＬ４１１と、ホスト４１２と、通信コスト４１３と、ＵＲＬ存在確率４１４との組を保持する。この組は通常複数ある。ＵＲＬ４１１はＵＲＬである。ホスト４１２はサーバ２０５または情報源が存在するホスト名、通信コスト４１３には、通信のスループットとレイテンシを用いる。ＵＲＬ存在確率４１４は、ホスト４１２で指定されるコンピュータに、ＵＲＬ４１１で指定されるホームページが存在する確率である。サイズ４１５は前回アクセス時のＵＲＬ４１１のバイト数である。アクセス戦略表１０５は、第１のサーバ２０５が、依頼を転送する１つ以上の第２のサーバ２０５’、２０５’’、…を選定する際に使用する。
【００６２】
なお、ホスト名には、シンボリックなホスト名かＩＰアドレスを用いる。場合によってはホスト名に、シンボリックなホスト名かＩＰアドレスと、ＴＣＰ／ＩＰやＵＤＰ／ＩＰのポート番号とを組にしたものを用いる。ただしホスト名は通信相手のサーバまたはクライアントを指定し、通信路を開くことが目的であるため、この目的にかなえば、いかなる形態の表現をとっても差し支えない。特に、ここでＩＰアドレスやポート番号は例として出したものであり、本発明の範囲を限定するものではない。
【００６３】
キャッシュディレクトリ３２３は、ＵＲＬ４２１と、ホスト４２２と、ＵＲＬ存在確率４２３を含む組を保持する。この組は通常複数ある。ＵＲＬ４２１はＵＲＬである。ホスト４２２はサーバまたは情報源が存在するホスト名、ＵＲＬ存在確率４２３は、ホスト４２２で指定されるコンピュータに、ＵＲＬ４２１で指定されるホームページが存在する確率である。
【００６４】
通信コスト表３２４は、ホスト４３１と、時刻４３２と、通信コスト４３３と、通信回数４３４を含む組を保持する。この組は通常複数ある。ホスト４３１はサーバまたは情報源が存在するホスト名、時刻４３２は何曜日の何時かを格納する。通信コスト４３３は時刻４３２においてホスト４３１に対して行なわれた過去一定期間内の通信のスループット（単位時間当りの通信可能データ量）とレイテンシ（通信が受ける遅延時間）である。通信回数４３４は、時刻４３２においてホスト４３１に対して行なわれた過去一定期間内の通信の回数を格納する。
【００６５】
アクセス頻度表３２５は、ＵＲＬ４４１と、アクセス頻度４４２と、サイズ４４３を含む組を保持する。この組は通常複数ある。ＵＲＬ４４１はＵＲＬ、アクセス頻度４４２はＵＲＬ４４１で指定されるホームページを、過去の一定時間Ｃ１内に当該サーバ２０５がアクセスした回数である。本実施例のアクセス頻度４４２は、過去一週間の何曜日の何時に何回アクセスしたかを格納するカウンタ群である。サイズ４４３は前回アクセス時のＵＲＬ４４１のバイト数である。
【００６６】
リンク頻度表３２６は、参照元ＵＲＬ４５１と、参照先ＵＲＬ４５２と、アクセス頻度４５３を含む組を保持する。この組は通常複数ある。アクセス頻度４５３は参照元ＵＲＬ４５１から参照先ＵＲＬ４５２へのリンクを、過去の一定時間Ｃ２内に当該サーバ２０５がアクセスした回数である。本実施例のアクセス頻度４５３は、過去一週間の何曜日の何時に何回アクセスしたかを格納するカウンタ群である。
【００６７】
外部アクセス頻度表３２７は、ＵＲＬ４６１と、アクセス頻度４６２を含む組を保持する。この組は通常複数ある。ＵＲＬ４６１はＵＲＬ、アクセス頻度４６２はＵＲＬ４６１で指定されるホームページを、過去の一定時間Ｃ１内に本システムの他のサーバ２０５’、２０５’’、…がアクセスした回数である。本実施例のアクセス頻度４６２は、過去一週間の何曜日の何時に何回アクセスしたかを格納するカウンタ群である。
【００６８】
外部リンク頻度表３２８は、参照元ＵＲＬ４７１と、参照先ＵＲＬ４７２と、アクセス頻度４７３を含む組を保持する。この組は通常複数ある。アクセス頻度４７３は参照元ＵＲＬ４７１から参照先ＵＲＬ４７２へのリンクを、過去の一定時間Ｃ２内に他のサーバ２０５’、２０５’’、…がアクセスした回数である。本実施例のアクセス頻度４７３は、過去一週間の何曜日の何時に何回アクセスしたかを格納するカウンタ群である。
【００６９】
ホスト表は、ホスト名の組を保持する。ホスト表に現れるホスト名は、本システムに参加している計算機２０３、２０３’、２０３’’、…上のサーバ２０５、２０５’、２０５’’、…の全体である。
【００７０】
またサーバ２０５は、プリフェッチフラグ、新規ＵＲＬフラグ、前回アクセスＵＲＬの変数を用いる。プリフェッチフラグは、真偽値の変数であり、現在サーバ２０５がプリフェッチ中か、クライアント２０４（または他のサーバ２０５’、２０５’’、…）の依頼を処理中かを表わす。初期値は偽である。新規ＵＲＬフラグは、受信したＵＲＬ内容が新規にホームページキャッシュ１０４に付け加わったかどうかを示す真偽値の変数である。初期値は偽である。前回アクセスＵＲＬは、前回クライアントからの依頼に対して返答したＵＲＬである。初期値は「空」である。
【００７１】
図５に、ホームページグループ表１０７、ホストＵＲＬメッセージ１２４、ホスト頻度メッセージ１２５の構成を示す。
【００７２】
ホームページグループ表１０７は、先頭ＵＲＬ４８１とＵＲＬグループ４８２を含む組を保持する。この組は通常複数ある。各々の組は、連続してアクセスされることが多いＵＲＬの集合である。先頭ＵＲＬ４８１は１つのＵＲＬ、ＵＲＬグループ４８２は１つ以上のＵＲＬ４８３、ＵＲＬ４８３’、ＵＲＬ４８３’’、…である。
【００７３】
ホストＵＲＬメッセージ１２４は、ホスト５０１、ＵＲＬ５０２、フラグ５０３を含む組を内蔵したデータである。１つのホストＵＲＬメッセージ１２４にこの組が２つ以上内蔵されて構わない。ホスト５０１はホスト名、ＵＲＬ５０２は１つのＵＲＬ、フラグ５０３は真偽値である。ホストＵＲＬメッセージ１２４は、ホスト５０１で指定されるサーバがＵＲＬ５０２で指定されるＵＲＬを持っていること（フラグ５０３が真の場合）、または持っていないこと（フラグ５０３が偽の場合）を他のサーバに伝達する目的で用いられる。
【００７４】
ホスト頻度メッセージ１２５は、ホスト５１１、参照元ＵＲＬ５１２、参照先ＵＲＬ５１３、頻度５１４を含む組を内蔵したデータである。ホスト５１１はホスト名、参照元ＵＲＬ５１２は１つのＵＲＬ、参照先ＵＲＬ５１３は１つのＵＲＬまたは「空」、頻度５１４はカウンタである。ホスト頻度メッセージ１２５は、参照元ＵＲＬ５１２で指定されるＵＲＬまたは参照元ＵＲＬ５１２と参照先ＵＲＬ５１３の間のリンクを、過去の一定時間内にホスト５１１で指定されるサーバ２０５がアクセスした回数である頻度５１４を、他のサーバ２０５’、２０５’’、…に伝える目的で用いられる。なお、上記Ｃ１、Ｃ２の値はいずれも、サーバ２０５のコンパイル時または起動時または起動中に変更可能であって差し支えない。また、アクセス頻度４４２、アクセス頻度４５３、アクセス頻度４６２、アクセス頻度４７３、頻度５１４を過去一週間の何曜日の何時に何回アクセスしたかを格納するとしたのは、一例として示したものに過ぎず、本発明の範囲を限定するものではない。また、アクセス頻度表３２５、リンク頻度表３２６、外部アクセス頻度表３２７、外部リンク頻度表３２８の目的は、どのＵＲＬやどのリンクがどのくらいアクセスされたかを記録して利用することにあるので、この目的にかなえば、他の情報を記録することも考えられる。例えば、アクセス頻度４４２、アクセス頻度４５３、アクセス頻度４６２、アクセス頻度４７３、頻度５１４と併用して、または代りとして、最終アクセス時刻を記録しておき、ＬＲＵ（ｌｅａｓｔ ｒｅｃｅｎｔｌｙ ｕｓｅｄ）法によってどのＵＲＬやどのリンクがどのくらいアクセスされたかを見積もることも考えられる。
【００７５】
以下、図１、図３、図６、および図７を用いて、第１のサーバ２０５がクライアント２０４または他のサーバ２０５’、２０５’’、…からＵＲＬ内容の取得を依頼された際の、第１のサーバ２０５の処理の流れを説明する。第１のサーバ２０５は依頼入力部３０１でクライアント２０４または他のサーバの依頼を待ち、受け付ける（６０１、３５０）。当該クライアント２０４または他のサーバの依頼の中で、取得すべきＵＲＬ内容はＵＲＬで表現される。なおクライアント２０４または他のサーバからの依頼に含まれていたＵＲＬを以後「処理対象ＵＲＬ」と呼ぶ。第１のサーバ２０５において、処理対象ＵＲＬはキャッシュ表参照部３０２に渡される（３５１）。この際、プリフェッチフラグには「偽」を格納する。
【００７６】
キャッシュ表参照部３０２は、ホームページキャッシュ１０４内で処理対象ＵＲＬに等しいＵＲＬ４０１を持つ組を検索する（６０２、３８０）。もしそのような組が存在すれば（６０３）、返答部３０５に制御を移す（３６３）。一方そのような組が存在しなければ（６０４）、処理戦略部３０３に処理を移す（３５２）。
【００７７】
処理戦略部３０３は、アクセス戦略表１０５を用いて（３８１）、依頼を転送すべき１つ以上の第２のサーバ２０５’、２０５’’、…または情報源を選定する。まず、アクセス戦略表１０５内で処理対象ＵＲＬに等しいＵＲＬ４１１を持つ組を検索し（６０５）、そのような組が１つ以上存在するかどうかを調べる（６０６）。存在する場合（６０７）、後述の手順でこれら１つ以上の組の順位づけおよび選択を行ない（６０８）、当該順位づけおよび選択の結果選ばれた１つまたは複数の組のそれぞれに対して、算出した優先度の高い順にホスト４１２で指定されるサーバや情報源に依頼を転送する（６１０、３６５）。一方そのような組が１つも存在しない場合（６０９）、処理対象ＵＲＬの情報源に依頼を転送する（６１０、３６５）。なお、上記どちらの場合でも、依頼を転送したら受信部３０４に処理を移す（３５３）。依頼を転送したサーバ２０５’、２０５’’、…や情報源を、以後「依頼転送先」と呼ぶ。
【００７８】
順位づけおよび選択には、さまざまなアルゴリズムを使用しうるが、ネットワーク通信の効率面からの主要な指標はレイテンシとスループットと通信サイズである。また、依頼を転送した先に処理対象ＵＲＬに対応する情報が存在する確率も重要となる。本実施例では具体的には以下に示す順位づけと選択を行なう。なお、下で用いるＤ１、Ｄ２、Ｄ３、Ｄ４、Ｄ５、Ｄ６はいずれも定数であるが、これらの値はいずれもサーバ２０５のコンパイル時または起動時または起動中に変更可能であって差し支えない。また、ここで述べる順位づけを、サーバ２０５が保持する他の情報と合わせてもちいても何ら差し支えない。例えば、他の情報として、システム管理者がサーバ２０５に提供する情報、ＩＰアドレスの類似性、ルーティングのトポロジーやホップ数、通信回線の物理構成などを使うことが考えられる。
【００７９】
順序づけと選択の手順は以下の通りである。上記アクセス戦略表１０５内で処理対象ＵＲＬに等しいＵＲＬ４１１を持つ組から、通信コスト４１３に含まれるスループットが定数Ｄ１以下であるものを除外する。通信コスト４１３に含まれるレイテンシが定数Ｄ２以上であるものを除外する。ＵＲＬ存在確率４１４が定数Ｄ３以下であるものを除外する。各組の優先度（大きい方が高い）をレイテンシとスループットと通信サイズとＵＲＬの存在確率から、（ＵＲＬ存在確率４１４／（通信コスト４１３のレイテンシ＋サイズ４１５／通信コスト４１３のスループット））の式を用いて算出し、上位Ｄ４の組を選択する。次に、処理対象ＵＲＬに含まれる情報源のコンピュータがこの時点で選択に含まれていなければ、当該情報源を最も優先度が低くして選択に加える。以上が本実施例における順位づけおよび選択の手順である。
【００８０】
なお、上記で複数のホスト４１２にほぼ同時に依頼を転送すると、複数の依頼転送先からほぼ同時に返答が送られて、第１のサーバ２０５付近のネットワークが混雑する恐れがある。一方、複数のホスト４１２に順々に依頼を転送し、その都度返答を待っていると、結果的に取得すべきＵＲＬ内容の取得が遅くなる恐れがある。これらの問題を軽減するために、以下の通信プロトコルを用いることができる。図８を用いて説明する。この図では、サーバ２０５と依頼転送先との間の通信の様子を時間に沿って上から下に描いており、図の（ａ）と（ｂ）は、２つの異なる場面を示している。
【００８１】
図８の（ａ）で示すように依頼を転送する際に、上記優先度の上位Ｄ５個の依頼転送先（以後優先依頼転送先（８０１、８０１’、…）と呼ぶ）には、依頼を変更なしで転送する（８０３）。この依頼をうけた当該優先依頼転送先のそれぞれは、処理対象ＵＲＬに対応するＵＲＬ内容を保持していればすぐ第１のサーバ２０５への返答を開始する（８０４）。依頼を変更なしで転送することは、処理対象ＵＲＬがあればすぐに返答を開始せよ、という要求を意味する。
【００８２】
上記優先依頼転送先はそれぞれ、処理対象ＵＲＬに対応するＵＲＬ内容があれば当該ＵＲＬ内容を当該第１のサーバ２０５に返答し、なければ「処理対象ＵＲＬは存在しない」という返答を返す（８０５）。
【００８３】
一方第１のサーバ２０５は、上記優先依頼転送先以外の依頼転送先（以後非優先依頼転送先（８０２、８０２’、…）と呼ぶ）には、処理対象ＵＲＬの「返答待機依頼」（８０６）を送付する。返答待機依頼は、処理対象ＵＲＬが存在して、かつ後述する返答開始依頼が到着したら、返答を開始せよ、という意味をもつ。この際、非優先依頼転送先は、処理対象ＵＲＬに対応するＵＲＬ内容があれば待機し、なければ「処理対象ＵＲＬは存在しない」という返答を返す。
【００８４】
第１のサーバ２０５は図８の（ｂ）で示すように、上記優先依頼転送先のすべてから「処理対象ＵＲＬは存在しない」（８０５’）という返答が返ってきた場合（８０７）に、まだ「処理対象ＵＲＬは存在しない」という返答をしていない非優先依頼先の１つ以上に対して、「返答開始依頼」（８０８）を送る。当該依頼が非優先依頼先に届き、かつ当該非優先依頼先に処理対象ＵＲＬに対応するＵＲＬ内容があれば、当該非優先依頼先は当該第１のサーバ２０５に対して当該ＵＲＬ内容の返答を開始する（８０９）。なお、待機中の非優先依頼転送先のおのおのは、返答待機依頼から一定時間Ｄ６以内に返答開始依頼が到着しなければ、待機を中止して次の依頼に備える。
【００８５】
このプロトコルは、処理対象ＵＲＬに対応するＵＲＬ内容が優先依頼転送先の１つ以上に存在した場合に上記第１のサーバ２０５付近のネットワークの混雑を緩和する。なぜなら、依頼転送先を２つの集団に分けたことによって、同時に起こる返答の最大数を減らしているためである。また、処理対象ＵＲＬに対応するＵＲＬ内容が優先依頼転送先のどれにも存在しなかった場合にも、処理対象ＵＲＬに対応するＵＲＬ内容の取得が遅くなるのを防ぐ。なぜなら、第１のサーバ２０５は返答待機依頼に対する非優先依頼転送先からの返答を待たずに、返答開始依頼を流すことが可能であるからである。
【００８６】
なお、上述の本実施例における順位づけと選択の手順によれば、優先依頼転送先または非優先依頼転送先のいずれかに、処理対象ＵＲＬの情報源が含まれているので、依頼転送先のどこからも処理対象ＵＲＬに対応するＵＲＬ内容が転送されない場合は非常に稀であることに注意されたい。万一、処理対象ＵＲＬに対応するＵＲＬ内容が転送されなかった場合には、本実施例では処理対象ＵＲＬに対応するＵＲＬ内容の受信を断念する。なお本実施例の変形例として、この場合にさらに別の依頼転送先を選択して依頼を転送することが考えられる。また、別の変形例として、この場合に処理対象ＵＲＬに対応するＵＲＬ内容の受信を一定時間経過後に再度試みる方法が考えられる。
【００８７】
また本実施例におけるサーバ２０５は、当該サーバ２０５の設置者が利便性を享受させようとするクライアント２０４、２０４’、２０４’’、…以外に、他のサーバへの通信を行なう。他のサーバとの通信は、サーバ２０５のキャッシュの能力を発揮するために必要不可欠であるが、この通信によって元来の目的としたクライアント２０４、２０４’、２０４’’、…へのサービスが低下する恐れをはらんでいる。この問題を解決するためにサーバ２０５は、他のサーバからの依頼を一定時間内に一定量に抑える。本実施例のサーバ２０５は過去時間Ｔ１以内にＬ１バイト以上のＵＲＬ内容の転送が、他のサーバに行なわれた場合、以後当該Ｔ１内には他のサーバからの依頼を受け付けない。また、本発明の別の実施例としては、サーバ２０５が過去時間Ｔ１以内にＬ２回数以上のＵＲＬ内容の転送が、他のサーバに行なわれた場合、以後当該Ｔ１内には他のサーバからの依頼を受け付けない。なおここで、Ｔ１、Ｌ１、Ｌ２はコンパイル時または起動時または起動中に変更可能であって差し支えない。
【００８８】
受信部３０４では、処理対象ＵＲＬに対応するＵＲＬ内容が、１つ以上の依頼転送先から返答されてくるのを待ち、当該ＵＲＬ内容の受信を行ない（３６６）、通信コスト表３２４の更新を行なう。
【００８９】
処理対象ＵＲＬに対応する返答があるか、一定時間Ｔ２が経過するのを待つ。（６１１）。ここで返答があったかを調べ（６１２）、返答があった場合には（６１３）、返答に含まれるＵＲＬ内容は、ホームページキャッシュ１０４内の新規な組として格納される（６１４、３８２）。この際、処理対象ＵＲＬが当該新規な組のＵＲＬ４０１となり、当該受信されたＵＲＬ内容がＵＲＬ内容４０２となる。なお、処理対象ＵＲＬに対応するＵＲＬ内容の受信後（受信中でもかまわない）にホームページキャッシュ１０４の総量が定数Ｃ３を越えたかを調べる（６１５）。越えていた場合に限り後述するキャッシュ入れ替え部３１０に制御が移り、キャッシュ入れ替えの処理が行なわれる（６１６と６１７、図３の３５５と３５６）。そして下に述べるように通信コスト表３２４の更新を行ない（６１８）、返答部３０５に制御を移す（３５４）。一方、処理対象ＵＲＬに対応するＵＲＬ内容が受信されなかった場合（６１９）、すなわち、依頼転送先のすべてから「処理対象ＵＲＬは存在しない」という返答を得た場合には、ホームページキャッシュ１０４には何も操作を行なわなず返答部３０５に制御を移す（３５４）。なおここで、Ｔ２、Ｃ３はサーバ２０５のコンパイル時または起動時または起動中に変更可能であって差し支えない。
【００９０】
通信コスト表３２４の更新は、図９の手順で行なう。処理対象ＵＲＬに対応するＵＲＬ内容が、第１の依頼転送先から受信され始めた（９１０）時点で、通信コスト表３２４の第１の依頼転送先に対応する組を更新する。これは以下の手順で行なう。
【００９１】
（１）ホスト４３１が第１の依頼転送先に等しく、かつ時刻４３２が現在の時刻にあう組を検索する（９１１）。そして、通信コスト４３３のレイテンシを再計算するとともに、通信回数４３４を１増加する（９１２）。すなわち、９１１で該当する組が見つからなかった場合には、通信コスト表３２４に新たな組を作り、ホスト４３１を第１の依頼転送先で、時刻４３２を現在の時刻で、通信回数４３４を１で初期化する。そして、通信コスト４３３のレイテンシを今回のレイテンシ（すなわち当該第１の依頼転送先が優先依頼転送先ならば依頼を転送してから現在までの時間、また非優先依頼転送先ならば、転送開始依頼を送信してから現在までの時間）で初期化する。また９１１で該当する組が見つかった場合には、当該組の通信コスト４３３のレイテンシを、今回のレイテンシと、通信コスト４３３および通信回数４３４の値を用いて再計算するとともに、通信回数４３４に１を加える。
【００９２】
（２）次に、当該第１の依頼転送先からの受信の終了時刻ＥＮＤＴＩＭＥを予測して計算する（９１３）。これは以下の方法で行なう。アクセス戦略表１０５内で処理対象ＵＲＬに等しいＵＲＬ４１１を持ち、かつホスト４１２が当該第１の依頼転送先に等しい組を検索する。そのような組の通信コスト４１３とサイズ４１５とを用いて、ＥＮＤＴＩＭＥを（現在の時刻＋（サイズ４１５／通信コスト４１３のスループット））とする。
【００９３】
（３）次に、処理対象ＵＲＬに対応するＵＲＬ内容が第２の依頼転送先から受信され始めるか、第１の依頼転送先からの受信が終了するかのいずれかを待つ（９１４）。
【００９４】
（４）第１の依頼転送先からの受信が終了したかを調べる（９１５）。受信が終了しないうちに第２の依頼転送先から受信され始めた場合（９１６）、上記第１の依頼転送先の場合と同様の手順で、通信コスト表３２４の第２の依頼転送先に対応する組を更新するとともに（９１７）、上記第１の依頼転送先からの受信の終了時刻ＥＮＤＴＩＭＥと同様の手順で、第２の依頼転送先からの受信の終了時刻ＥＮＤＴＩＭＥ２を計算する（９１８）。そして、もしＥＮＤＴＩＭＥがＥＮＤＴＩＭＥ２＋定数Ｃ４よりも大きいかを調べ（９１９）、大きければ（９２０）、上記第１の依頼転送先からの受信を中止し（９２１）、第２の転送依頼先を第１の依頼転送先に置き換え（９２２）、ＥＮＤＴＩＭＥ２をＥＮＤＴＩＭＥとし（９２３）、９１４にもどる。なおここで、Ｃ４はサーバ２０５のコンパイル時または起動時または起動中に変更可能であって差し支えない。また、もしＥＮＤＴＩＭＥがＥＮＤＴＩＭＥ２＋定数Ｃ４以下であれば（９２４）、第２の依頼転送先からの受信を中止する（９２５）。
【００９５】
一方９１５において、第１の依頼転送先からの受信が終了した場合（９２６）には、通信コスト表３２４の第１の依頼転送先に対応する組の通信コスト４３３のスループットを、今回のスループット（すなわち、今回受信したＵＲＬ内容のサイズを、（当該第１の転送依頼先が優先依頼転送先ならば）依頼を転送してから現在までの時間または（非優先転送依頼先ならば）返答開始依頼を送信してから現在までの時間で割ったもの）と、通信コスト４３３および通信回数４３４の値を用いて再計算する（９２７）。そして新規ＵＲＬフラグを真を格納する（９２８）。以上が、通信コスト表３２４の更新手順である。
【００９６】
返答部３０５は以下の手順で動作する。プリフェッチフラグが「真」かどうかを調べる（６２０）。真ならば、プリフェッチ戦略部３０８に制御を移す（６２１、３６４）。プリフェッチフラグが「偽」であった場合（６２２）、処理対象ＵＲＬに対応するＵＲＬ内容が受信されたかどうか調べる（６２３）。受信されなかった場合（６２４）には、上記依頼を受けたクライアント２０４または他のサーバに「処理対象ＵＲＬは存在しない」を返答（３６７）した後（６２５）、依頼入力部３０１に制御を移して新たなクライアント２０４または他のサーバからの依頼を待つ（６２６）。一方処理対象ＵＲＬに対応するＵＲＬ内容が受信された場合（６２７）、そのＵＲＬ内容を上記依頼を受けたクライアント２０４または他のサーバに返答する（６２８、３６７）。
【００９７】
ここで、新規ＵＲＬフラグが真かどうかを調べる（６２９）。新規ＵＲＬフラグが真なら（６３０）、ホストＵＲＬメッセージ１２４の送信を行なったあと（６３１）、リンク統計更新部３０６に制御を移す（６３２、３５７）。新規ＵＲＬフラグが偽なら（６３３）、すぐにリンク統計更新部３０６に制御を移す（３５７）。
【００９８】
新規ＵＲＬフラグである場合、ホームページキャッシュ１０４に１つ以上の組が追加されたことを意味するので、ホストＵＲＬメッセージ１２４を行なう。まず新規ＵＲＬフラグに偽を格納してから、１つの組を持つホストＵＲＬメッセージ１２４を新たに作成し、当該組のホスト５０１に第１のサーバ２０５のホスト名を、ＵＲＬ５０２に処理対象ＵＲＬを、フラグ５０３に真をそれぞれ格納する。そして、当該組を持つホストＵＲＬメッセージ１２４をホスト表に含まれる他のサーバ２０５’、２０５’’、…のうち１つ以上に送信する。例えば、ホスト表中の組のうち、第１のサーバ２０５を含む組を検索する。この組から第１のサーバ２０５のホスト名を除いた１つ以上のホスト名のそれぞれに対して、上記手順で作成したホスト頻度メッセージ１２５を送信する方法が考えられる。また別の方法ではホスト表中の組に格納されているホスト名のそれぞれに対して、当該組を持つホストＵＲＬメッセージ１２４を送信する方法が考えられる。また、１つの組をもつホストＵＲＬメッセージ１２４をすぐに他のサーバ２０５’、２０５’’、…に送るのではなく、いくつかの組をまとめてから他のサーバ２０５’、２０５’’、…に送ることも考えられる。最初の方法では、比較的近いサーバ２０５’、２０５’’、…に通信範囲を限定することができ、また最後の方法では通信回数を削減することができる。
【００９９】
リンク統計更新部３０６では、アクセス頻度表３２５とリンク頻度表３２６を更新することにより、処理対象ＵＲＬのアクセス頻度と、処理対象ＵＲＬに至る特定のリンクがアクセスされる頻度を記録する（３８６）。以下にこの手順を述べる。
【０１００】
ステップ７０１で、アクセス頻度表３２５中の組のうち、ＵＲＬ４４１が処理対象ＵＲＬに等しい組を検索する。このような組がなければ、新たな組をアクセス頻度表３２５に作り、当該新たな組のＵＲＬ４４１を処理対象ＵＲＬで、アクセス頻度４４２のカウンタ群をすべて０で初期化する。そして検索で見つかった組または当該新たな組の、アクセス頻度４４２のうち現在時刻に対応するカウンタを１増加させ、サイズ４４３に処理対象ＵＲＬに対応するＵＲＬ内容のバイト数を格納する。
【０１０１】
次に、前回アクセスＵＲＬから処理対象ＵＲＬへのハイパー・テキスト・リンクがあるかを調べる（７０２）。関連があると判定した場合（７０３）、リンク頻度表３２６を更新する（７０４）。リンク頻度表３２６の更新は具体的には、リンク頻度表３２６中の組のうち、参照元ＵＲＬ４５１が前回アクセスＵＲＬに等しく、かつ参照先ＵＲＬ４５２が処理対象ＵＲＬに等しい組を検索する。このような組がなければ、新たな組をリンク頻度表３２６中に作り、当該新たな組の参照元ＵＲＬ４５１を前回アクセスＵＲＬで、参照先ＵＲＬ４５２を処理対象ＵＲＬで、アクセス頻度４５３のカウンタ群をすべて０で初期化する。そして検索で見つかった組または当該新たな組の、アクセス頻度４５３のうち現在時刻に対応するカウンタを１増加させる。そして、前回アクセスＵＲＬに処理対象ＵＲＬを格納してから、グループ更新部３０７に制御を移す（７０５、３５８）。
【０１０２】
一方、関連がないと判定した場合には（７０６）、前回アクセスＵＲＬに処理対象ＵＲＬを格納してから、プリフェッチ戦略部３０８に制御を移す。
【０１０３】
グループ更新部３０７では、ホームページグループ表１０７を更新する（７０７、３８７）。連続してアクセスされることが多いＵＲＬのひとつの集合を考えると、この集合をアクセスする際にはじめにアクセスされるＵＲＬが少数あると考えられる。本実施例ではこのような少数のＵＲＬを見つけた場合にのみリンク統計更新部３０６からグループ更新部３０７に制御を移すことを、すでに述べたリンク統計更新部３０６の場合わけにより行なっている。
【０１０４】
グループ更新部３０７は以下の手順で行なう。ホームページグループ表１０７中で、先頭ＵＲＬ４８１が処理対象ＵＲＬに等しい組を検索する。もしこのような組があれば、この組をホームページグループ表１０７中から削除する。次に、ホームページグループ表１０７中に新たな組を作成し、先頭ＵＲＬ４８１を処理対象ＵＲＬで、ＵＲＬグループ４８２を処理対象ＵＲＬから連続してアクセスされる確率が定数Ｃ５以上の１つ以上のＵＲＬで初期化する。処理対象ＵＲＬから連続してアクセスされる確率は、アクセス頻度表３２５と外部アクセス頻度表３２７とリンク頻度表３２６と外部リンク頻度表３２８を用いて計算することができる。なお、Ｃ５はサーバ２０５のコンパイル時または起動時または起動中に変更可能であって差し支えない。次に、第１のＵＲＬから第２のＵＲＬにリンクがある場合、第１のＵＲＬのアクセス頻度（アクセス頻度表３２５中ＵＲＬ４４１が第１のＵＲＬに等しい組のアクセス頻度４４２のカウンタ群の合計）が Ａ、第１のＵＲＬから第２のＵＲＬへのリンクのアクセス頻度（リンク頻度表３２６中参照元ＵＲＬ４５１が第１のＵＲＬに等しく、参照先ＵＲＬ４５２が第２のＵＲＬに等しい組のアクセス頻度４５３のカウンタ群の合計）が Ｂ、第１のＵＲＬの外部アクセス頻度（外部アクセス頻度表３２７中ＵＲＬ４６１が第１のＵＲＬに等しい組のアクセス頻度４６２のカウンタ）が Ｃ、第１のＵＲＬから第２のＵＲＬへのリンクの外部アクセス頻度（外部リンク頻度表３２８中参照元ＵＲＬ４７１が第１のＵＲＬに等しく、参照先ＵＲＬ４７２が第２のＵＲＬに等しい組のアクセス頻度４７３のカウンタの値）が Ｄとすると、第１のＵＲＬから第２のＵＲＬが連続してアクセスされる確率は（Ｂ／Ａ）×（Ｄ／Ｃ）と見積もる。もしＡとＢの値のどちらかが０の場合、第１のＵＲＬから第２のＵＲＬが連続してアクセスされる確率は０とする。またもしＣとＤの値のどちらかが０の場合、（Ｂ／Ａ）を第１のＵＲＬから第２のＵＲＬが連続してアクセスされる確率とする。
【０１０５】
また、第１のＵＲＬから第２のＵＲＬにリンクがない場合、第３、第４、…、第ＮのＵＲＬが存在して、第１のＵＲＬから第３のＵＲＬへのリンク、第３のＵＲＬから第４のＵＲＬへのリンク、…、第ＮのＵＲＬから第２のＵＲＬへのリンクがそれぞれある場合がある。この場合には、第１のＵＲＬから第３のＵＲＬが連続してアクセスされる確率、第３のＵＲＬから第４のＵＲＬが連続してアクセスされる確率、…、第ＮのＵＲＬから第２のＵＲＬが連続してアクセスされる確率をそれぞれｐ２、ｐ３、…、ｐＮとすると、第１のＵＲＬから第２のＵＲＬが連続してアクセスされる確率はｐ２×ｐ３×…×ｐＮとする。なお、このような推移閉包にかかわる計算には、例えばＡｈｏ他著の文献「データ構造とアルゴリズム」（１９８７年、培風館情報処理シリーズ１１）第６.３章に記載のダイクストラのアルゴリズム等良く知られた方法が利用できる。
【０１０６】
以上の処理の後、プリフェッチ戦略部３０８に制御を移す（３５９）。
【０１０７】
プリフェッチ戦略部３０８では、処理対象ＵＲＬがアクセスされた直後にアクセスされやすい１つ以上のプリフェッチＵＲＬ群に対応するＵＲＬ内容を決定し、当該プリフェッチＵＲＬ群をクライアント２０４または他のサーバからの依頼なしでホームページキャッシュ１０４に受信する。具体的には、以下の手順で処理を行なう。
【０１０８】
まず、この時点でクライアント２０４または他のサーバからの依頼が到着しているかを調べる（７０８）。到着していれば（７０９）、プリフェッチフラグに「偽」を格納し、依頼入力部３０１に制御を移す。
【０１０９】
一方依頼が到着していなければ（７１０）、プリフェッチフラグの値が真かを調べる（７１１）。
【０１１０】
プリフェッチフラグが「偽」ならば（７１２）、ホームページグループ表１０７で、処理対象ＵＲＬを含む組を検索し（３８８）、このような組に含まれる処理対象ＵＲＬ以外の１つ以上のＵＲＬをプリフェッチＵＲＬ群とする。（７１３）。ここでプリフェッチフラグに「真」を格納する。
【０１１１】
一方プリフェッチフラグが「真」ならば（７１４）、プリフェッチ中ＵＲＬをプリフェッチＵＲＬ群から削除する（７１５）。ここでプリフェッチＵＲＬ群が空になれば、プリフェッチフラグを「偽」にする。
【０１１２】
ここでプリフェッチＵＲＬ群に１つ以上のＵＲＬが含まれるかを調べる（７１６）。含まれるならば（７１７）、プリフェッチＵＲＬ群から１つのプリフェッチ中ＵＲＬを取り出して（７１８）、プリフェッチ中ＵＲＬを処理対象ＵＲＬとみなしてキャッシュ表参照部３０２に渡して（３６１）、すでに述べた手順でプリフェッチ中ＵＲＬの受信を開始する。含まれないならば（７１９）、プリフェッチスケジュール部３０９に制御を移す（３６０）。なおここまでの手順からも明らかなように、このプリフェッチは、クライアントのみならず他のサーバからの依頼によっても起動される。すなわち、多段に配置された複数のサーバが、一連のプリフェッチを行なうことが可能である。
【０１１３】
プリフェッチスケジュール部３０９では、今後アクセスされると考えられるＵＲＬで、現在ホームページキャッシュ１０４にないものを、将来ネットワークがすく時を狙って得るための準備を行なう。プリフェッチスケジュール部３０９は以下の手順で行なう。
【０１１４】
まず、ホームページグループ表１０７中で、先頭ＵＲＬ４８１が前回アクセスＵＲＬに等しい組を検索することによって、前回アクセスＵＲＬに対応するホームページグループ表１０７の組を選択する（７２０）。
【０１１５】
もしこのような組が存在すれば、ＵＲＬグループ４８２に格納されている１つ以上の第１のＵＲＬの各々について、プリフェッチする時刻をキャッシュディレクトリ３２３と通信コスト表３２４から決定する（７２１、３８４、３８５）。これは以下の手順で行なう。
【０１１６】
第１のＵＲＬに対応するＵＲＬ内容がホームページキャッシュ１０４にあれば何もしない。一方なければ、キャッシュディレクトリ３２３中の組で、ＵＲＬ４２１が第１のＵＲＬに等しいものを検索する。このような組がなければ何もしない。このような組が１つ以上存在する場合には、ＵＲＬ存在確率４２３が最も大きい組を１つ選択し、その組のホスト４２２を将来アクセスするホストとする。次に通信コスト表３２４中で、ホスト４３１が当該ホストに等しい第１の組を検索する。このような組がなければ、なにもしない。もしこのような第１の組が１つ以上あれば、アクセス頻度表３２５中で、ＵＲＬ４４１が当該第１のＵＲＬに等しい第２の組を検索する。もしこのような第２の組があれば、第１の組のうち、（（第２の組のサイズ４４３／第１の組の通信コスト４３３のスループット）＋第１の組の通信コスト４３３のレイテンシ）が最小な第３の組を１つ選ぶ。第２の組がなければ、（第１の組の通信コスト４３３のレイテンシ／第１の組の通信コスト４３３のスループット）が最小な第３の組を１つ選ぶ。
【０１１７】
この第３の組の時刻４３２に次に対応する時刻を「プリフェッチ時刻」と呼ぶ。例えば、時刻４３２が「水曜日２３：４０」で、現在時刻が１月３日火曜日の３：００であれば、プリフェッチ時刻は１月４日水曜日の２３：４０となる。
【０１１８】
次に、ステップ７２１で算出した、１つ以上の第１のＵＲＬのプリフェッチ時刻をタイマー３１１を設定する（７２２、３８９）。これにより、タイマー３１１は、すでに述べた手順で第１のＵＲＬの受信を行なうよう、時刻４３２の時刻に第１のＵＲＬの依頼をキャッシュ表参照部３０２に渡す。このタイマー３１１設定処理が終わったあとは、依頼入力部３０１に制御を移す（３６２）。
【０１１９】
以上がプリフェッチスケジュール部３０９の処理である。
【０１２０】
キャッシュ入れ替え
キャッシュ入れ替え部３１０では、ホームページキャッシュ１０４の部分的な削除を行なう（３８３）。ホームページキャッシュ１０４中の組の一部または全部のそれぞれについて、以下の「キャッシュ価値」を計算する。
【０１２１】
ある第１のＵＲＬのキャッシュ価値は、アクセス戦略表１０５とアクセス頻度表３２５を用いて計算する。アクセス戦略表１０５内で当該第１のＵＲＬに等しいＵＲＬ４１１を持つ１つ以上の第１の組を検索する。もしこのような組が複数あれば、それぞれの組の（通信コスト４１３のレイテンシ＋（サイズ４１５／通信コスト４１３のスループット））が最小の組を１つ選択し、第１の組とする。さらに、アクセス頻度表３２５中で、ＵＲＬ４４１が第１のＵＲＬに等しい第２の組を検索する。
【０１２２】
第１の組の（（サイズ４１５／通信コスト４１３のスループット）＋通信コスト４１３のレイテンシ）がＡ、第１のＵＲＬのアクセス頻度（すなわち第２の組のアクセス頻度４４２のカウンタ群の合計）が Ｂである場合、第１のＵＲＬのキャッシュ価値を（（Ａ×Ｂ）／第１の組のサイズ４１５）とする。万一第１の組または第２の組がなければ、第１のＵＲＬのキャッシュ価値は０とする。
【０１２３】
上記ホームページキャッシュ１０４中の組の一部または全部のそれぞれについて「キャッシュ価値」を計算したら、この「キャッシュ価値」が最も小さい組から順にホームページキャッシュ１０４から削除する。ホームページキャッシュ１０４からの削除は、ホームページキャッシュ１０４の総量が定数Ｃ３以下になるまで行なう。
【０１２４】
ホームページキャッシュ１０４から１つ以上の組が削除された場合、次に述べる手順でホストＵＲＬメッセージ１２４を送信する。ホストＵＲＬメッセージ１２４の送信は以下の手順で行なう。ホストＵＲＬメッセージ１２４を新たに作成し、上記ホームページキャッシュ１０４から削除された組のそれぞれに対して、ホストＵＲＬメッセージ１２４に新たな組を作成する。新たな組には、ホスト５０１に第１のサーバ２０５のホスト名、ＵＲＬ５０２に削除された組のＵＲＬ４０１、フラグ５０３に偽を格納する。そして作成したホストＵＲＬメッセージ１２４をホスト表に含まれる他のサーバ２０５’、２０５’’、…のうち１つ以上に送信する。送信相手の決定方法は、既にのべたホームページキャッシュ１０４に１つ以上の組が追加された場合のホストＵＲＬメッセージ１２４と同じである。
【０１２５】
タイマー処理
サーバ２０５は上記の一連の処理の他に、タイマー３１１によって一定時間ごとに行なわれる処理を行なう。なお以下に述べるタイマーによる各処理は、主フローとの競合を避ける目的で、依頼入力部３０１でクライアント２０４または他のサーバの依頼を待っている場合にのみ行なう。
【０１２６】
タイマー３１１は、定期的にアクセス戦略表１０５をキャッシュディレクトリ３２３と通信コスト表３２４とアクセス頻度表３２５から再構成する。これは主に、通信コスト表３２４の時刻４３２は何曜日の何時における各ホストへの通信コストを保持するのに対して、アクセス戦略表１０５は現在の各ホストへの通信コストを保持するためである。本実施例では時刻４３２が１時間毎の情報を保持するため、アクセス頻度表３２５の再構成は１時間に一度行なう。アクセス戦略表１０５、キャッシュディレクトリ３２３、通信コスト表３２４、アクセス頻度表３２５の内容から、再構成の手順は明らかである。
【０１２７】
タイマー３１１は、定期的にアクセス頻度表３２５とリンク頻度表３２６からホスト頻度メッセージ１２５を作成し、ホスト表に含まれる他のサーバ２０５’、２０５’’、…の１つ以上に送信する。これは以下の手順で行なう。
【０１２８】
まずホスト頻度メッセージ１２５を１つ作る。次にアクセス頻度表３２５中のすべての組に対して、当該ホスト頻度メッセージ１２５に新たな組を追加していく。追加する組のホスト５１１は第１のサーバ２０５のホスト名、参照元ＵＲＬ５１２はアクセス頻度表３２５の組のＵＲＬ４４１、参照先ＵＲＬ５１３は「空」、頻度５１４はアクセス頻度表３２５の組のアクセス頻度４４２のカウンタ群の合計をそれぞれ格納する。次にリンク頻度表３２６中のすべての組に対して、当該ホスト頻度メッセージ１２５に新たな組を追加していく。追加する組のホスト５１１は第１のサーバ２０５のホスト名、参照元ＵＲＬ５１２はリンク頻度表３２６の組の参照元ＵＲＬ４５１、参照先ＵＲＬ５１３はリンク頻度表３２６の組の参照先ＵＲＬ４５２、頻度５１４はリンク頻度表３２６の組のアクセス頻度４５３のカウンタ群の合計をそれぞれ格納する。次に、ホスト表中の組のうち、第１のサーバ２０５を含む組を検索する。この組から第１のサーバ２０５のホスト名を除いた１つ以上のホスト名のそれぞれに対して、上記手順で作成したホスト頻度メッセージ１２５を送信する。
【０１２９】
また、タイマー３１１は、上記第１のサーバ２０５を含む組へのホスト頻度メッセージ１２５の送信よりも粗い頻度（例えば上記送信１０回に１回の割合）で、ホスト表中の組のうち、第１のサーバ２０５を含まない組を検索し、この検索の結果である組からに格納されている１つ以上のホスト名のそれぞれに対して、上記手順で作成したホスト頻度メッセージ１２５を送信する。
【０１３０】
また、タイマー３１１は、キャッシュディレクトリ３２３の組のすべてについて、定期的にＵＲＬ存在確率４２３の再計算を行なう。これは以下の手順で行なう。キャッシュディレクトリ３２３中の組のそれぞれに対して、ＵＲＬ存在確率４２３を定数Ｃ６だけ減じたものをＵＲＬ存在確率４２３に格納する。もし減じた結果が定数Ｃ７以下なら、ＵＲＬ存在確率４２３にＣ７を格納する。なおここで、Ｃ６およびＣ７はサーバ２０５のコンパイル時または起動時または起動中に変更可能であって差し支えない。
【０１３１】
メッセージ処理
第１のサーバ２０５のサーバ間メッセージ処理部１０３が他のサーバ２０５’、２０５’’、…からホストＵＲＬメッセージ１２４を受け取ると、以下の手順でキャッシュディレクトリ３２３を更新する。ホストＵＲＬメッセージ１２４が内蔵する組のうちフラグ５０３が真の第１の組のそれぞれに対して、キャッシュディレクトリ３２３中の組で、ホスト４２２が第１の組のホスト５０１に等しくＵＲＬ４２１が第１の組のＵＲＬ５０２に等しい第２の組を検索する。このような第２の組があれば、当該第２の組のＵＲＬ存在確率４２３を１に設定する。また、このような第２の組がなければ、キャッシュディレクトリ３２３中に新たな組を作成し、ホスト４２２をホスト５０１で、ＵＲＬ４２１をＵＲＬ５０２で、ＵＲＬ存在確率４２３を１で初期化する。
【０１３２】
また、ホストＵＲＬメッセージ１２４が内蔵する組のうちフラグ５０３が偽の第３の組のそれぞれに対して、キャッシュディレクトリ３２３中の組で、ホスト４２２が第１の組のホスト５０１に等しくＵＲＬ４２１が第３の組のＵＲＬ５０２に等しい第４の組を検索する。このような第４の組があれば、当該第４の組を削除する。
【０１３３】
また、第１のサーバ２０５のサーバ間メッセージ処理部１０３が他のサーバ２０５’、２０５’’、…からホスト頻度メッセージ１２５を受け取ると、以下の手順で外部アクセス頻度表３２７と外部リンク頻度表３２８とを更新する。
【０１３４】
受け取ったホスト頻度メッセージ１２５が内蔵する組で参照先ＵＲＬ５１３が「空」の第１の組のそれぞれについて、外部アクセス頻度表３２７中で、ＵＲＬ４６１が第１の組の参照元ＵＲＬ５１２に等しい第２の組を検索する。このような第２の組が存在すれば、当該第２の組のアクセス頻度４６２に第１の組の頻度５１４を加え、再び当該第２の組のアクセス頻度４６２に格納する。一方このような第２の組が存在しなければ、外部アクセス頻度表３２７に新たな組を作成し、当該組のＵＲＬ４６１を第１の組の参照元ＵＲＬ５１２で、アクセス頻度４６２を第１の組の頻度５１４で初期化する。
【０１３５】
また、ホスト頻度メッセージ１２５が内蔵する組で参照先ＵＲＬ５１３が「空」以外の第３の組のそれぞれについて、外部リンク頻度表３２８中で、参照元ＵＲＬ４７１が第３の組の参照元ＵＲＬ５１２に等しく、参照先ＵＲＬ４７２が第３の組の参照先ＵＲＬ５１３に等しい第４の組を検索する。このような第４の組が存在すれば、当該第４の組のアクセス頻度４７３に第３の組の頻度５１４を加え、再び当該第４の組のアクセス頻度４７３に格納する。一方このような第４の組が存在しなければ、外部リンク頻度表３２８に新たな組を作成し、当該組の参照元ＵＲＬ４７１を第３の組の参照元ＵＲＬ５１２で、参照先ＵＲＬ４７２を第３の組の参照先ＵＲＬ５１３で、アクセス頻度４７３を第３の組の頻度５１４で初期化する。
【０１３６】
【発明の効果】
本発明によれば以下の効果が得られる。
【０１３７】
ユーザはクライアントを用いて任意の１つのサーバに接続して情報を依頼するだけで、複数のサーバが通信回線の不均一性と不安定性を隠蔽して情報を提供する。
【０１３８】
サーバ間の通信回線のスループットとレイテンシが異なっていても、サーバが相互に交換する情報により、各サーバは、最も高速に情報の取得が可能であると考えられるサーバを選択する。この結果、最も高速に情報の取得が可能であると考えられる通信回線を選択して利用することにより通信回線の不均一性が解決される。サーバが相互に交換する情報により、各サーバは例えば、時間帯や曜日によって回線の混雑が変化したり、ある通信回線の増強によってルーティングのパターンが変更され、別の回線が混雑したり混雑が解消されたりすることを考慮に入れる。この結果、各サーバは最も高速に情報の取得が可能であると考えられる他のサーバを、最も高速に情報の取得が可能であると考えられる通信回線を選択して利用する。これにより通信回線の不安定性を回避できる。
【図面の簡単な説明】
【図１】本実施例のサーバの内部構成の概略を示すブロック図。
【図２】本実施例の分散コンピュータ・システムを示す図。
【図３】サーバ２０５の内部構成を示すブロック図。
【図４】サーバ２０５内で用いられるデータ構造を示す図である。
【図５】サーバ２０５内で用いられるデータ構造を示す図（図５の続き）。
【図６】サーバ２０５内の処理手順を示すフローチャート。
【図７】サーバ２０５内の処理手順を示すフローチャート（図６の続き）。
【図８】サーバ２０５、２０５’、２０５’’、…が用いる混雑緩和のためのプロトコルを説明する図。
【図９】通信コスト表３２４の更新手順を示すフローチャート。
【符号の説明】
２０５ サーバ
２０４ クライアント
１０１ 依頼処理部
１０２ プリフェッチ部
１０３ サーバ間メッセージ処理部
１０４ ホームページキャッシュ
１０５ アクセス戦略表
１０６ 頻度ＤＢ
１０７ ホームページグループ表
１２４ ホストＵＲＬメッセージ
１２５ ホスト頻度メッセージ
３０１ 依頼入力部
３０２ キャッシュ表参照部
３０３ 処理戦略部
３０４ 受信部
３０５ 返答部
３０６ リンク統計更新部
３０７ グループ更新部
３０８ プリフェッチ戦略部
３０９ プリフェッチスケジュール部
３１０ キャッシュ入れ替え部
３２３ キャッシュディレクトリ
３２４ 通信コスト表
３２５ アクセス頻度表
３２６ リンク頻度表
３２７ 外部アクセス頻度表
３２８ 外部リンク頻度表。
【発明の属する技術分野】
本発明は、計算機システムに関し、例えばネットワークによって接続された複数の計算機が、情報を流通・共有・変更するシステム（情報システム）内の情報を管理する分散データ管理方法に関し、特にＷｏｒｌｄ―Ｗｉｄｅ Ｗｅｂ（ＷＷＷ）に好適な分散データ管理方法に関する。
【０００２】
【従来の技術】
以下の記述に用いるいくつかの用語をまず説明する。
【０００３】
インターネット上のＷＷＷ、匿名ＦＴＰをはじめとする情報システムは、通常分散コンピュータ・システムの一形態である「クライアント・サーバ・システム」の形態で構築されている。クライアント・サーバ・システムでは、システム全体の処理は２種類に分割され、第１の部分を「サーバ」と呼ばれる実行中のプログラム（以下、プロセスという）で処理し、第２の部分を複数の「クライアント」と呼ばれるプロセスで処理する。情報システムのクライアントは通常、個人または企業内のユーザが操作するコンピュータで動作する。情報システムのサーバは、クライアントに提供する情報を格納する。情報システムのクライアントは、サーバに新たな情報を格納したり、サーバに要請して情報を取得する。
【０００４】
コンピュータ・システムでは、１つの情報を複数の場所に一時的にコピーしておくことにより、当該情報へのアクセスを高速にしたり、アクセスできる可能性を高めることが広く行なわれる。このようなコピーはヒント、キャッシュ、レプリカ、スタッシュ等と呼び分けられる（Ｓａｐｅ Ｍｕｌｌｅｎｄｅｒ編の文献”Ｄｉｓｔｒｉｂｕｔｅｄ Ｓｙｓｔｅｍｓ（１ｓｔ ｅｄ.）”ｐｐ.１３―１５，ＡＣＭ ｐｒｅｓｓ，１９８９参照）。以下ではこれらのコピーを総称して「キャッシュ」と呼ぶ。またキャッシュを作ることを「キャッシュする」と記す。
【０００５】
ＷＷＷでは、ＷＷＷサーバが、発信する情報を「ホームページ」と呼ばれる単位で保持している。ホームページは、それぞれＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒの略）と呼ばれる名前を持っている。ＵＲＬはＷＷＷで用いられるプロトコルと、情報源であるコンピュータのホスト名、および情報源において特定のデータを指定することが可能な文字列である。”ｈｔｔｐ：／／ｗｗｗ.ｈｉｔａｃｈｉ.ｃｏ.ｊｐ／ｉｎｄｅｘ.ｈｔｍｌ”は ＵＲＬの一例である。
【０００６】
なお、一般にＵＲＬは（ホームページのデータや画像データ等の）ひとかたまりのデータに対応づけられるが、以後このひとかたまりのデータのことを「ＵＲＬに対応する情報」または「ＵＲＬ内容」と記す。また、第１のＵＲＬに対応する情報中に含まれる第２のＵＲＬは「ハイパー・テキスト・リンク（または簡単にリンク）」とよばれる。第１のＵＲＬに対応する情報中に第２のＵＲＬが含まれることを、以下「第１のＵＲＬから第２のＵＲＬにリンクがある」と記す。
【０００７】
ＷＷＷで用いられている技術（公知例１）を説明する。
【０００８】
ＷＷＷクライアントのユーザは、アクセスしたいホームページのＵＲＬをＷＷＷクライアントに指定する。ＷＷＷのサーバとクライアントの第１の処理形態では、ＷＷＷクライアントは当該ＵＲＬの第２要素で指定されるＷＷＷサーバに対して、当該ＵＲＬに対応するホームページの送信を依頼する。当該ＷＷＷサーバは、この要求に応えて、当該ホームページを当該ＷＷＷクライアントに与える。
【０００９】
また第２の処理形態では、ＷＷＷクライアントが、ユーザが与えたＵＲＬの第２要素で指定されるＷＷＷサーバに依頼を行なうかわりに、「プロキシ・サーバ」と呼ばれる第２のサーバに依頼を行なう場合もある。当該第２のサーバは、当該ＷＷＷサーバから当該ＵＲＬに対応するホームページを得るか、さらに別のプロキシ・サーバに当該ＵＲＬに対応する情報取得を依頼する。このプロキシ・サーバの依頼が複数段階である場合、プロキシ・サーバは親子関係を持つ。親子関係を持つプロキシ・サーバに関しては、例えばＡ.Ｃｈａｎｋｈｕｎｔｈｏｄ他の文献”Ａ Ｈｉｅｒａｒｃｈｉｃａｌ Ｉｎｔｅｒｎｅｔ Ｏｂｊｅｃｔ Ｃａｃｈｅ”（１９９６ ＵＳＥＮＩＸ Ｔｅｃｈｎｉｃａｌ Ｃｏｎｆｅｒｅｎｃｅ，ｐｐ.１５３―１６３，１９９６）に記載されている。
【００１０】
なお、ＷＷＷのクライアントやプロキシ・サーバは、キャッシュを持つことができる。クライアントが持つキャッシュは、以前に当該クライアントが取得したホームページを保持しており、当該クライアントのみが利用する。プロキシ・サーバがもつキャッシュは、当該プロキシ・サーバが１つ以上のクライアントまたは他の１つ以上のプロキシ・サーバまたはその両方の依頼によって取得したホームページを保持しており、当該プロシキ・サーバを利用するクライアントおよびプロキシ・サーバによって共用される。
【００１１】
ネットワーク・ニュース・システム（以後公知例２と呼ぶ。Ｂ.Ｋａｎｔｏｒ他著の文献”Ｎｅｔｗｏｒｋ Ｎｅｗｓ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ：Ａ Ｐｒｏｐｏｓｅｄ Ｓｔａｎｄａｒｄ ｆｏｒ ｔｈｅ Ｓｔｒｅａｍ―Ｂａｓｅｄ Ｔｒａｎｓｍｉｓｓｉｏｎ ｏｆ Ｎｅｗｓ”Ｎｅｔｗｏｒｋ Ｗｏｒｋｉｎｇ Ｇｒｏｕｐ ＲＦＣ―９７７等に記載されている）は、１つ以上のサーバによって構成される。ユーザは通常、クライアントを用いて当該複数のサーバのうち１つを選択して利用する。ネットワーク・ニュース・システムにおける情報の単位は「ニュース記事」と呼ばれる。ユーザは通常、クライアントを用いてニュース記事をサーバに提供する操作と、ニュース記事をサーバから取り出す操作を行なう。ユーザがニュース記事が第１のサーバに提供すると、第１のサーバは１つ以上の第２のサーバに当該ニュース記事のコピーを送り、さらに第２のサーバが別のサーバに当該ニュース記事のコピーを送る、という具合で、最終的には上記複数のサーバすべてに当該ニュース記事がコピーされる。
【００１２】
公知例３として、広域名前サービスＤｏｍａｉｎ Ｎａｍｅ Ｓｙｓｔｅｍを説明する。（以下ＤＮＳと略す。例えばＰ.Ｍｏｃｋａｐｅｔｒｉｓ著の文献”Ｄｏｍａｉｎ Ｎａｍｅｓ―Ｉｍｐｌｅｍｅｎｔａｔｉｏｎ ａｎｄ Ｓｐｅｃｉｆｉｃａｔｉｏｎ”Ｎｅｔｗｏｒｋ Ｗｏｒｋｉｎｇ Ｇｒｏｕｐ ＲＦＣ―１０３５の特に第２節に記載されている）ＤＮＳは主にシンボリックなホスト名と、そのホスト名の付随情報（ＩＰアドレスやメールサーバ）とを対応づける。複数のＤＮＳサーバは木構造を構成する。クライアントの依頼は当該木構造をたどって、複数のサーバの間を転送され、処理される。ＤＮＳのクライアントであるｒｅｓｏｌｖｅｒは、あるホスト名に対応するホスト関連情報をサーバの１つに依頼する。この際当該サーバは、当該ホスト名に対応するホスト関連情報をクライアントに返すか、当該ＤＮＳサーバの親サーバ（ＤＮＳサーバの木構造において根に一段近いＤＮＳサーバ）に当該依頼を転送する。なお親サーバは、直接の子サーバ群がどのホスト関連情報を持つかを把握している。このため、木構造の根まで依頼が転送されると、今度は木構造を下って依頼を処理できるＤＮＳサーバの方に依頼を転送する。依頼は最終的に、ホスト関連情報を保持するＤＮＳサーバに到達して、クライアントにホスト関連情報が返されるか、木構造を下っていく段階で、当該依頼のホスト名に対応するホスト関連情報がどのＤＮＳサーバからも提供されていないことが判明して、クライアントに失敗が返される。
【００１３】
ローカル・エリア・ネットワーク（ＬＡＮ）内の分散ファイルシステムにおいて、キャッシュのための空間を複数のコンピュータで共有する方法も知られている（公知例４）。Ｍｉｃｈａｅｌ Ｄａｈｌｉｎ他著の文献”Ｃｏｏｐｅｒａｔｉｖｅ Ｃａｃｈｉｎｇ：Ｕｓｉｎｇ Ｒｅｍｏｔｅ Ｃｌｉｅｎｔ Ｍｅｍｏｒｙ ｔｏ Ｉｍｐｒｏｖｅ Ｆｉｌｅ Ｓｙｓｔｅｍ Ｐｅｒｆｏｒｍａｎｃｅ”（Ｆｉｒｓｔ ＵＳＥＮＩＸ Ｓｙｍｐｏｓｉｕｍ ｏｎ Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍｓ Ｄｅｓｉｇｎ ａｎｄ Ｉｍｐｌｅｍｅｎｔａｔｉｏｎ，ｐｐ.２６７―２８０，１９９４）では、クライアントはまず「マネージャ」と呼ばれるサーバに、ファイルブロックを依頼する。マネージャは、どのファイル・ブロックがどのコンピュータに格納されているかを保持しており、クライアントにファイル・ブロックが格納されているコンピュータを返答するか、当該コンピュータにクライアントの要求を転送する。同様の方法としては、Ｍ.Ｊ.Ｆｅｅｌｅｙ他著の文献”Ｉｍｐｌｅｍｅｎｔｉｎｇ Ｇｌｏｂａｌ Ｍｅｍｏｒｙ Ｍａｎａｇｅｍｅｎｔ ｉｎ ａｎ Ｗｏｒｋｓｔａｔｉｏｎ Ｃｌｕｓｔｅｒ”（ＡＣＭ １５ｔｈ Ｓｙｍｐｏｓｉｕｍ ｏｎ Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍｓ Ｐｒｉｎｃｉｐｌｅｓ，ｐｐ.２０１―２１２，１９９５）や Ｐ.Ｓａｒｋａｒ他著の文献”Ｅｆｆｉｃｉｅｎｔ Ｃｏｏｐｅｒａｔｉｖｅ Ｃａｃｈｉｎｇ Ｕｓｉｎｇ Ｈｉｎｔｓ”（Ｓｅｃｏｎｄ ＵＳＥＮＩＸ Ｓｙｍｐｏｓｉｕｍ ｏｎ Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍｓ Ｄｅｓｉｇｎ ａｎｄ Ｉｍｐｌｅｍｅｎｔａｔｉｏｎ，ｐｐ.３５―４６，１９９６）が知られている。マネージャは複数存在することができるが、ファイル・ブロックとマネージャとの対応関係はあらかじめ定められており、全クライアントおよびサーバがその対応関係を知っている。この対応関係はシステム動作中に変化しない。
【００１４】
公知例５および公知例６として、ｃａｃｈｅ―ｃｏｈｅｒｅｎｔ ｎｏｎ―ｕｎｉｆｏｒｍ ｍｅｍｏｒｙ ａｃｃｅｓｓ（ＣＣ―ＮＵＭＡ）やｃａｃｈｅ ｏｎｌｙ ｍｅｍｏｒｙ ａｃｃｅｓｓ（ＣＯＭＡ）と呼ばれる種類の計算機で用いられている技術を説明する。ＣＣ―ＮＵＭＡ計算機やＣＯＭＡ計算機では、メモリの断片（キャッシュライン）を多数のプロセッサの近くにキャッシュし、それらキャッシュの間の一貫性を保つ機構が含まれている。特に以下の２つの方法が知られている。
【００１５】
第１の方法（公知例５）は、上記マネージャに相当する「ホーム」と呼ばれる処理装置またはデータが、メモリの断片がどのプロセッサによってキャッシュされているかを把握しておく方法である。Ｊｅｆｆｒｅｙ Ｋｕｓｋｉｎ他著の文献”Ｔｈｅ Ｓｔａｎｆｏｒｄ ＦＬＡＳＨ Ｍｕｌｔｉｐｒｏｃｅｓｓｏｒ”（Ｐｒｏｃｅｅｄｉｎｇｓ ｏｆ ｔｈｅ ２１ｓｔ Ａｎｎｕａｌ Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｓｙｍｐｏｓｉｕｍ ｏｎ Ｃｏｍｐｕｔｅｒ Ａｒｃｈｉｔｅｃｔｕｒｅ，ｐｐ.３０２―３１４，ＡＣＭ，１９９４）に記載のシステム等で第１の方法が用いられている。
【００１６】
第２の方法（公知例６）は、キャッシュの作成と削除と通信方法に一定の制約を課すことによって、一定回数の通信（通常マルチキャストまたはブロードキャストを含む）でキャッシュの特定と一貫性の保持ができることを保証する方法である。Ｈｅｎｋ Ｌ.Ｍｕｌｌｅｒ他の文献”Ｔｈｅ Ｄａｔａ Ｄｉｆｆｕｓｉｏｎ Ｍａｃｈｉｎｅ ｗｉｔｈ ａ Ｓｃａｌａｂｌｅ Ｐｏｉｎｔ―ｔｏ―Ｐｏｉｎｔ Ｎｅｔｗｏｒｋ”（Ｔｅｃｈｎｉｃａｌ Ｒｅｐｏｒｔ ＣＳＴＲ―９３―１７，Ｄｅｐａｒｔｍｅｎｔ ｏｆ Ｃｏｍｐｕｔｅｒ Ｓｃｉｅｎｃｅ，Ｕｎｉｖｅｒｓｉｔｙ ｏｆ Ｂｒｉｓｔｏｌ，Ｏｃｔｏｂｅｒ １９９３）に記載のシステム等で第２の方法が用いられている。
【００１７】
【発明が解決しようとする課題】
現在のインターネット全体の通信性能はユーザの要求する速度に遠く及んでおらず、多くの不安定要因を抱えている。ＷＷＷの爆発的な普及により、多くのワイド・エリア・ネットワーク（ＷＡＮ）で混雑が起こっている。高速なバックボーン通信回線が日々増強されている一方で、家庭からのインターネット利用者は、一般的なＬＡＮよりも非常に遅い通信回線を用いてインターネットに接続している。現在でもＷＷＷサーバとインターネットのユーザ数は増加の一途をたどっており、１９９６年１月のある統計では、全世界のインターネット利用のコンピュータは９００万台、６ヶ月弱で２倍の速度で増加している。
【００１８】
このため、インターネットの通信回線には不均一性と不安定性がある。ここでの不均一性とは、様々な通信回線が混在していることを指す。例えば、通信回線によってスループット（単位時間当りの通信データ量）とレイテンシ（通信が受ける遅延時間）が異なることがあげられる。ここでの不安定性とは、通信回線のスループットとレイテンシが刻一刻と変化し、場合によっては通信不能になったりすることを指す。例えば、時間帯や曜日によって通信回線の混雑が変化したり、ある通信回線の増強によってルーティングのパターンが変更され、別の通信回線が混雑したり混雑が解消されたりすることを指す。
【００１９】
このような状況を鑑み、ユーザにより快適な情報システムのサービスを行なうために、ユーザがクライアントに要求を発してから、その要求が満たされるまで時間を短縮することが本発明の目的である。以下この目的を実現する上での課題と、公知の技術との隔たりを説明する。
【００２０】
第１に、公知の技術では、ある通信回線が不安定な状況下では、たとえ別の通信回線が正常に動作していてもクライアントの依頼を高速に処理できない場合があった。
【００２１】
公知例１のＷＷＷのクライアントやＷＷＷのプロキシ・サーバは、ＵＲＬによって指定された特定のＷＷＷサーバまたは特定のプロキシ・サーバと通信する。このため、当該サーバ（またはプロキシ・サーバ）への通信回線が混雑していたり、不通である場合には、たとえ別の通信回線が正常に動作していても、クライアント（またはプロキシ・サーバ）がホームページの入手に長時間を要したり、ホームページの入手ができない。また同じ理由で、ある時点で低速だった通信回線が増強等により高速になったとしても、その利益を享受することが困難だった。公知例２から公知例５でも、クライアントとサーバ、またはサーバと別のサーバの通信が、あらかじめ定められた相手とのみ行なわれる点は公知例１と共通しており、上記の問題がある。一方公知例６は、１つの計算機または物理的に密接に結び付いた複数の計算機で使用する技術であり、マルチキャストまたはブロードキャストが不具合なく動作することを前提としている。このためＬＡＮ環境やＷＡＮ環境にひろく適用することは困難である。また同じ理由で、特定の通信回線が混雑していたり、不通である場合には（たとえ別の通信回線が正常に動作していても）、キャッシュラインの入手に長時間を要したり、キャッシュラインの入手ができない。
【００２２】
第２に、公知の技術では通信回線が不安定な状況下でキャッシュの利用率をあげることが達成されていなかった。
【００２３】
公知例１、２、３、５では、複数のサーバ（またはクライアントとサーバ）がキャッシュを持つ場合、これら複数のキャッシュは階層構造をなす。クライアントが発する依頼には、当該依頼を処理する責任を持つ特定の第１のサーバが存在している。当該依頼は、当該第１のサーバに直接送信されるか、当該第１のサーバとクライアントの間の１つ以上の第２のサーバの間を順に転送される（この場合、当該１つ以上の第２のサーバは依頼の内容によって一意に決定される）。前者の場合、当該依頼は当該第１のサーバのキャッシュしか利用できない。また後者の場合には、当該１つ以上の第２のサーバのキャッシュしか利用できない。すなわち第１、第２のサーバの他のサーバのキャッシュは利用されず、キャッシュの利用率が低い。例えば公知例１のＷＷＷのプロキシ・サーバは親子関係を持つので、プロキシ・サーバＡ、Ｂ、Ｃが存在してＡが親、ＢとＣがＡの子として動作している場合、ＢはＡに依頼を転送することによってＡのキャッシュを利用することができるが、ＢがＣのキャッシュを利用することはできない。また公知例２では、各ニュース記事は、当該ニュース記事を必要とするすべてのサーバにコピーされる。このため、各サーバは他のサーバのキャッシュを全く利用せず、したがって各サーバが大規模な二次記憶を用意する必要がある。一方、公知例４はＬＡＮ環境を仮定しており、キャッシュの利用率をあげる目的で、１つのデータのコピーが複数のキャッシュ中でできるだけ少数になるような制御が行なう。しかし、通信回線が不安定な場合には、クライアントの依頼が少数のキャッシュに到達できない場合があり、逆にキャッシュの利用率が低くなる恐れがある。公知例６は、複数のキャッシュのうち最も短時間で利用できるキャッシュを選択するが、この際にマルチキャストまたはブロードキャストが用いられる。このため、公知例６の方法を通信回線が不安定になる可能性があるＬＡＮ環境やＷＡＮ環境にひろく適用することは困難である。
【００２４】
第３に、公知の技術ではデータとデータの間の参照関係の使用頻度を複数のサーバが交換する方法を持たなかった。
【００２５】
ＷＷＷのホームページとハイパー・テキスト・リンクに代表されるように、情報システムが提供するデータには参照関係があり、参照関係のなかでも頻繁にたどられる参照関係（使用頻度の高い参照関係）があることが多い。参照関係の使用頻度情報は、プリフェッチなどに利用できる。頻繁にたどられる参照関係で結ばれた一連の情報をクライアントからの依頼以前にプリフェッチしておけば、クライアントからの依頼があった時に通信回線が不安定でも、当該一連の情報の依頼は高速に処理することができるためである。特に複数のサーバが存在する場合、参照関係の使用頻度情報は、個々のサーバがそれぞれ収集するより、複数のサーバが収集した情報を交換して集計する方がより確からしい情報となる。しかし公知例１から６では、参照関係の使用頻度情報を複数のサーバが交換する方法を持たなかった。このため、参照関係の使用頻度情報の確からしさに限界があり、プリフェッチの効果も限られていた。
【００２６】
第４に、公知の技術ではキャッシュの入れ替えに通信回線の不均一性と不安定性が考慮されていなかったため、重要なキャッシュを破棄する恐れがあった。
【００２７】
公知例１、２、３では、各サーバ（またはクライアント）が、利用履歴等に基づいてそれぞれのキャッシュの入れ替えを行なう。公知例４はＬＡＮ環境での使用を想定しているため、キャッシュの入れ替えの際のキャッシュの優先度づけに、通信回線の状態は考慮されない。また、公知例５と６も、１つの計算機または物理的に密接に結び付いた複数の計算機で使用することを想定しているため、キャッシュの入れ替えの際のキャッシュの優先度づけに、通信回線の状態は考慮されない。この結果、公知例１から６のいずれでも、現在の通信状態では再び入手することができない、または入手に長時間を要するキャッシュを破棄する場合がある。
【００２８】
第５に、公知の技術ではいずれも、第１のサーバが１つ以上の第２のサーバからの依頼を受ける場合に、第２のサーバが第１のサーバを無制限に利用し、結果として第１のサーバを過負荷におとしいれることに対する対策がなかった。このため、複数のサーバが複数のユーザの組織を越えて依頼を行ないあうことが困難だった。公知例１、２、３は、クライアント・サーバ・システムであるため、サーバが依頼を拒否すると、クライアントの依頼が処理されない。一方、公知例４、５、６は限られた範囲の複数のサーバが依頼を行ないあうため、第１のサーバの過負荷を問題にする必要がなかった。
【００２９】
【課題を解決するための手段】
本発明では、複数のサーバを用い、複数のキャッシュを複数のサーバが保持することによって、１つの情報システムのサービスを提供する。
【００３０】
第１の課題を解決するため、以下の３つの手段を講じる。
【００３１】
（１）第１のサーバが必要とするデータ（以後必要データと呼ぶ）を入手しようとする際、当該必要データは本発明の方法で用いる複数のサーバのうち、２つ以上の第２のサーバにキャッシュされている可能性がある。この際第１のサーバは、第１のサーバと第２のサーバが過去に行なった通信履歴を保持し、当該通信履歴を用いて第２のサーバから１つ以上の第３のサーバを選択して、第３のサーバに必要データの送信を依頼する。この通信履歴から第１のサーバは、現時点で高速に必要データの入手が可能と予測される第３のサーバを選択できる。このため、高速に通信できる通信回線を選択的に用いてクライアントの依頼を処理可能となる。
【００３２】
（２）第１のサーバは、必要データを入手するための第３のサーバを２つ以上選択し、これら複数のサーバに対して同時に依頼を送信することにより、クライアントの依頼を高速に処理することを試みる。これだけでは当該複数のサーバからほぼ同時に依頼の返答が開始されて、却って通信の速度を下げる恐れがある。そこで、当該２つ以上の第２のサーバのうち、１つ以上の第３のサーバには必要データを直ちに送信することを依頼し、別の１つ以上の第４のサーバには、必要データの送信を待機することを依頼する。第３のサーバからの必要データの送信が長時間を要するか、不可能であることが判明した時点で、すでに待機している第４のサーバから直ちに必要データの送信を受けられる。このため、通信回線の状況が変化した場合にもクライアントの依頼を高速に処理可能となる。
【００３３】
（３）第１のサーバは、当該第１のサーバと１つ以上の他のサーバとの過去の通信に関する、第１の時間にわたる、第２の時間間隔毎の通信の履歴（時間毎通信履歴）を持つ。当該時間毎通信履歴は、通信回線の状況が周期的に変化する場合（例えば昼間は混雑しているが夜間は混雑していない通信回線を用いる場合等）に、第１のサーバが通信を行なう時刻の選択を可能にする。これら３つの手段によって本発明は、高速に通信できる通信回線を選択的に利用し、若しくは高速に通信できる時間帯に選択的に利用して、通信回線が不安定または不均一な状況下で、クライアントの依頼を高速に処理する。
【００３４】
第２の課題を解決するために、第１のサーバは、当該第１のサーバが持つキャッシュの一覧の一部または全部を、１つ以上の第２のサーバに通信する。この際当該１つ以上の他のサーバは前記通信回線の状況の履歴を用いて選択する。これにより、第１のサーバのキャッシュの一覧を、その時点で高速に通信できる第２のサーバに通信することができる。このため、第１のサーバと第２のサーバの間の通信回線が正常な場合には、他の通信回線が不安定でも、第２のサーバが第１のサーバのキャッシュを利用可能となる。
【００３５】
第３の課題を解決するために、クライアントが第１のデータを依頼した後に、１つ以上の第２のデータを依頼する可能性が高い場合に、第１のサーバは第１のデータと第２のデータの対応関係（参照関係情報）を持ち、かつ当該参照関係情報を１つ以上の第２のサーバに送信する。この手段を用いて本発明の複数のサーバは、参照関係情報を他のサーバと交換し、頻繁にたどられる参照関係の使用頻度の確からしさを向上させる。これにより頻繁に依頼される一連のデータをクライアントに高速に提供する。
【００３６】
また参照関係情報をプリフェッチに用いることによって、多数のデータを同時に依頼することが可能になる。この際本発明ではサーバが複数あることを利用して、複数のサーバが階層的なパイプライン状にプリフェッチを行ない、特定のサーバにボトルネックを生じたり、特定のネットワークが過負荷になってプリフェッチが効果的に行なわれない等の問題を避ける。
【００３７】
第４の課題を解決するために、第１のサーバは前記通信回線の状況の履歴を用いて情報の単位のアクセス頻度および最終アクセス時間、平均スループット、平均レイテンシ、他のサーバのキャッシュの内容から、キャッシュの優先度づけを行ない、この優先度に基づいてキャッシュの入れ替えを行なう。これにより、現在の通信状態では再び入手ことができない、または入手に長時間を要するキャッシュを破棄することを避けることが可能となる。
【００３８】
第５の課題を解決するために、第１のサーバが、１つ以上の第２のサーバの必要データの送信の全体を一定時間内に一定量以下、または一定時間内に一定回数以下に制限する手段を持ち、一方で第２のサーバの各々は、第１のサーバを含む２つ以上の第３のサーバに、必要データの送信を依頼する。これにより、第１のサーバが第２のサーバからの依頼によって過負荷になることを防ぎつつ、第２のサーバの処理を妨げないことが可能となる。本発明が複数のサーバからなっており、ひとつのサーバが依頼を拒否しても、他のサーバが依頼を処理することが可能なため、この手段が有効となる。
【００３９】
これらの手段によって、本発明は、インターネットの通信回線の不均一性と不安定性がある状況下でも、ユーザがクライアントに要求を発してから、その要求が満たされるまで時間を短縮する。また特定の通信回線が不通でも、できる限りクライアントの依頼を処理する。これによりユーザにより快適な情報システムのサービスを行なう。
【００４０】
【発明の実施の形態】
以下、本発明の実施の一形態を、図面を参照しながら説明する。なお、簡単のため、本明細書中では「発明の実施の形態」を、単に「実施例」と呼ぶことにする。
【００４１】
全体構成
本実施例は、他の情報システムから入手する情報とユーザが入力する情報を、分散した１つ以上のキャッシュに保持する分散データ管理方法を搭載した計算機システムである。図２に本実施例の全体を示す。本実施例の全体２０１は分散コンピュータ・システムであり、ネットワーク２０２と、ネットワーク２０２によって相互接続された１つ以上の計算機２０３、２０３’、２０３’’、…からなる。
【００４２】
ネットワーク２０２は、ある団体（企業や学校や類似の団体）の全体や位置部門でよく使用されるＬＡＮでもよく、また地理的に分散した複数の地点を結合するＷＡＮの一部または全部でもよい。またネットワーク２０２は、計算機間結合網や並列計算機内部のプロセッサ要素間の結合網でもよい。
【００４３】
計算機２０３、２０３’、２０３’’、…は、それぞれ１個以上のクライアントまたは１個以上のサーバまたはその両方を動作させる。本実施例の全体２０１で、少なくとも１つのサーバ２０５と少なくとも１つのクライアント２０４が存在する。なお以下で、本実施例の全体に含まれるサーバ群を「本システム」と呼ぶことがある。計算機２０３、２０３’、２０３’’、…は、いわゆるパーソナル・コンピュータ、ワークステーション、並列計算機、大型計算機等、任意のコンピュータでよい。また、クライアント２０４、２０４’、２０４’’、…を動作させる計算機２０３、２０３’、２０３’’、…は、サーバ２０５、２０５’、２０５’’、…と通信する機能をもっていればよい。すなわち各種コンピュータ端末装置、携帯通信端末（いわゆるパーソナル・デジタル・アシスタンスＰＤＡやハンドヘルド・パーソナル・コンピュータＨＰＣ）、ネットワーク・コンピュータなどでも差し支えない。なお、図２に示した計算機２０３、２０３’、２０３’’、…、クライアント２０４、２０４’、２０４’’、…、およびサーバ２０５、２０５’、２０５’’、…の数と構成は、例として示したもので、本発明の範囲を限定するものではない。
【００４４】
クライアント２０４は、ＷＷＷで使われる各種プロトコル、すなわちＨＴＴＰ（Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌの略）プロトコル、ＦＴＰ（Ｆｉｌｅ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌの略）プロトコル等を用いてサーバ２０５と通信を行なう。クライアント２０４は、グラフィック・ユーザ・インターフェースを備えたＷＷＷブラウザ、テキスト表示のみを行なうＷＷＷブラウザ、ワード・プロセッサや表計算ソフトウェアに内蔵されたＷＷＷのクライアント、ＷＷＷのプロキシ・サーバ等でよい。なお、クライアント２０４が用いるプロトコル、およびクライアント２０４の種類は例として示したもので、本発明の範囲を限定するものではない。
【００４５】
サーバ２０５、２０５’、２０５’’、…は、ＷＷＷサーバ、ＷＷＷプロキシ・サーバ、匿名ＦＴＰサーバ、ユーザの入力等の「情報源」から、クライアントに提供する情報を入手して、ＵＲＬと組にして保持する。サーバ２０５、２０５’、２０５’’、…は上記情報の入手を、上記情報源のそれぞれに定期的に（例えば１時間に一度）接続して新規情報を得る、上記情報源から新規情報の発生を通知して貰う、等の方法で行なう。なお、サーバ２０５、２０５’、２０５’’、…がクライアントに提供する情報を入手する情報源および方法は、例として示したもので、本発明の範囲を限定するものではない。また、本実施例のサーバ２０５、２０５’、２０５’’、…が持つ情報にはＵＲＬが付与されており、かつサーバはＵＲＬを用いてＵＲＬ内容の管理を行なうが、サーバが持つ情報を何らかの形式で指定することができればよく、ＵＲＬに限ることはない。このため、本発明の範囲を限定するものではない。さらに本発明の実施は、クライアントまたはサーバのオペレーティング・システム、サーバ間またはサーバ・クライアント間のネットワークの種類およびネットワークの物理層プロトコルやトランスポート層プロトコル、もしくはサーバとクライアントが単一のコンピュータ上にあるか異なるコンピュータ上にあるかには依存しない。
【００４６】
クライアントとサーバの動作の概略
図１を用いてクライアント２０４とサーバ２０５の動作の概略を説明する。なお、サーバ２０５とクライアント２０４、他のサーバ２０５’、２０５’’、…を繋いでいるネットワーク２０２はここには図示していない。また、図１中の矢印は主要なデータの流れである。
【００４７】
サーバ２０５は依頼処理部１０１、プリフェッチ部１０２、サーバ間メッセージ処理部１０３の各処理部分と、ホームページキャッシュ１０４、アクセス戦略表１０５、頻度ＤＢ１０６、ホームページグループ表１０７の各データ構造を持つ。
【００４８】
サーバ２０５のホームページキャッシュ１０４は、サーバ２０５が動作する計算機２０３の持つ不揮発性記憶装置（磁気ハードディスク、光ディスク等。以下「二次記憶」と記すことがある）または揮発性記憶装置（メインメモリ、キャッシュメモリ等。以下「主記憶」と記すことがある）またはその両方に格納される。なお、ホームページキャッシュ１０４は不揮発性記憶装置に格納される場合でも揮発性記憶装置に格納される場合でも、一個所に格納される必要はない。例えば、サーバ２０５が動作する計算機２０３が３つの磁気ハードディスクを持っていれば、ホームページキャッシュ１０４をこれら３つの磁気ハードディスクの一部または全部に分割して格納しても差し支えない。むしろ、複数の磁気ハードディスクを用いることは、磁気ハードディスクへのアクセスの並列性を増し、もってホームページキャッシュ１０４の読み書きを高速化するために、必須ではないが望ましい。また当該サーバ２０５は情報のキャッシュをすることが重要な役割であるため、当該サーバ２０５には大容量のホームページキャッシュ１０４を構成するのに十分な記憶装置が付属していることが、必須ではないが望ましい。
【００４９】
クライアント２０４が、本システムから第１のＵＲＬに対応する情報である第１のＵＲＬ内容を取得する際には、本システムの任意の第１のサーバ２０５に、第１のＵＲＬを含む依頼１２０を送信することによって、第１のＵＲＬ内容の取得を依頼する。
【００５０】
依頼１２０は依頼処理部１０１が受け取り、ホームページキャッシュ１０４に依頼されたＵＲＬ内容があるかどうかを検索する（１３０）。もしあれば、当該ホームページキャッシュ１０４をアクセスして、第１のＵＲＬ内容をクライアント２０４に返答１２１で送信する。
【００５１】
アクセス戦略表１０５は、本システムの他のサーバ２０５’、２０５’’、…がどのＵＲＬ内容を保持しているかの記録、及び第１のサーバ２０５から行なった過去の通信の速度（例えばスループットやレイテンシ）の記録を保持している。第１のＵＲＬ内容が第１のサーバ２０５のホームページキャッシュ１０４内になければ、第１のサーバ２０５はアクセス戦略表１０５を参照して依頼を転送すべき第２のサーバ２０５’、２０５’’、…を決定する（１３１）。そして第２のサーバ２０５’、２０５’’、…および第１のＵＲＬ内容の情報源のうち１つ以上に、依頼１２２により依頼１２０を転送する。第１のサーバ２０５は、依頼を転送した第２のサーバ２０５’、２０５’’、…または情報源の少なくとも１つから第１のＵＲＬ内容が返答１２３によって得られると、得られた第１のＵＲＬ内容をクライアント２０４に返答１２１によって送る。なお、上記依頼１２０、返答１２１、依頼１２２、返答１２３はいずれも、ネットワーク２０２を通じて行なわれてもかまわないし、計算機２０３、２０３’、２０３’’、…の持つ通信機能を用いて行なわれてもかまわない。
【００５２】
第１のサーバ２０５は返答１２３によって第１のＵＲＬ内容が得られると、第１のサーバ２０５のホームページキャッシュ１０４に第１のＵＲＬ内容を追加する（１３３）。この場合には、当該第１のＵＲＬ内容が追加されたことを伝えるホストＵＲＬメッセージ１２４が本システムの他のサーバ２０５’、２０５’’、…の一部または全部に送信される。またホームページキャッシュ１０４に第１のＵＲＬ内容を追加する際、別の第２のＵＲＬ内容がホームページキャッシュ１０４から削除される場合があるが、この場合には、当該第２のＵＲＬ内容が削除されたことを伝えるホストＵＲＬメッセージ１２４が本システムの他のサーバ２０５’、２０５’’、…の一部または全部に送信される。
【００５３】
頻度ＤＢ１０６は、後に述べるように、どのＵＲＬ内容がいつ参照されたかという頻度情報を記録している。ホームページグループ表１０７は、連続して依頼されたことが多かった複数のＵＲＬ内容の組を記録している。第１のサーバ２０５のプリフェッチ部１０２は返答１２１の後、依頼１２０による頻度情報の変化を頻度ＤＢ１０６に反映する（１３５）。頻度情報の変化は、頻度ＤＢ１０６の更新内容を伝えるホスト頻度メッセージ１２５によって本システムの他のサーバ２０５’、２０５’’、…の一部または全部に送信される。さらに、プリフェッチ部１０２は頻度ＤＢ１０６の内容に基づいてホームページグループ表１０７を更新する（１３６）。
【００５４】
次に、将来依頼されやすいと考えられるＵＲＬ内容を頻度ＤＢ１０６およびホームページグループ表１０７を用いて決定する（１３７および１３８）。当該ＵＲＬ内容が１個以上あれば、それらは依頼処理部１０１が上記依頼１２０と同様に受信する。
【００５５】
また、サーバ間メッセージ処理部１０３は、本システムの他のサーバ２０５’、２０５’’、…からホストＵＲＬメッセージ１２４’を受信するとアクセス戦略表１０５を書き換える（１４０）。また、本システムの他のサーバ２０５’、２０５’’、…からホスト頻度メッセージ１２５’を受信すると頻度ＤＢ１０６を書き換える（１４１）。
【００５６】
以上がクライアント２０４とサーバ２０５の動作の概略である。以下ではこれらをさらに詳しく説明する。
【００５７】
サーバの内部動作の詳細
図３に、サーバ２０５の内部構成を示す。依頼処理部１０１は、依頼入力部３０１、キャッシュ表参照部３０２、処理戦略部３０３、受信部３０４、返答部３０５、キャッシュ入れ替え部３１０からなる。プリフェッチ部１０２は、リンク統計更新部３０６、グループ更新部３０７、プリフェッチ戦略部３０８、プリフェッチスケジュール部３０９、タイマー３１１からなる（サーバ間メッセージ処理部１０３は図３には示していない）。
【００５８】
サーバ２０５のデータ構造は、ホームページキャッシュ１０４、アクセス戦略表１０５、頻度ＤＢ１０６（アクセス頻度表３２５、リンク頻度表３２６、外部アクセス頻度表３２７、外部リンク頻度表３２８からなる）、ホームページグループ表１０７、およびアクセス戦略表１０５を構成するためのキャッシュディレクトリ３２３と通信コスト表３２４、およびホスト表の各データ構造を持つ（ホスト表は図示していない）。これらのデータ構造はすべて、主記憶と二次記憶の片方または両方に存在してかまわない。なお、図３において、太い矢印は主要な制御の流れを、また細い矢印は主要なデータの流れを表わす。また、本実施例では請求項における必要データはＵＲＬ内容であり、請求項における通信履歴は、アクセス戦略表１０５と通信コスト表３２４に、データ保持確率はキャッシュディレクトリ３２３に、時間毎通信履歴は頻度ＤＢ１０６に、参照関係情報はホームページグループ表１０７に、それぞれ格納される。また、サーバ間で通信されるデータの一覧はホストＵＲＬメッセージ１２４の形式で通信される。
【００５９】
サーバ２０５内部の処理の説明に先立って、各データ構造の概略を説明する。各データ構造の詳細な説明は、サーバ２０５内部の処理の説明とあわせて行なう。図４に、ホームページキャッシュ１０４、アクセス戦略表１０５、キャッシュディレクトリ３２３、通信コスト表３２４、アクセス頻度表３２５、リンク頻度表３２６、外部アクセス頻度表３２７、外部リンク頻度表３２８の構成を示す。
【００６０】
ホームページキャッシュ１０４は、キャッシュの本体である。ＵＲＬ４０１と、ＵＲＬ４０１の内容であるＵＲＬ内容４０２を組にして保持する。この組は通常複数ある。
【００６１】
アクセス戦略表１０５は、下に述べるキャッシュディレクトリ３２３と通信コスト表３２４とを、現在の使用のために組み合わせたものである。ＵＲＬ４１１と、ホスト４１２と、通信コスト４１３と、ＵＲＬ存在確率４１４との組を保持する。この組は通常複数ある。ＵＲＬ４１１はＵＲＬである。ホスト４１２はサーバ２０５または情報源が存在するホスト名、通信コスト４１３には、通信のスループットとレイテンシを用いる。ＵＲＬ存在確率４１４は、ホスト４１２で指定されるコンピュータに、ＵＲＬ４１１で指定されるホームページが存在する確率である。サイズ４１５は前回アクセス時のＵＲＬ４１１のバイト数である。アクセス戦略表１０５は、第１のサーバ２０５が、依頼を転送する１つ以上の第２のサーバ２０５’、２０５’’、…を選定する際に使用する。
【００６２】
なお、ホスト名には、シンボリックなホスト名かＩＰアドレスを用いる。場合によってはホスト名に、シンボリックなホスト名かＩＰアドレスと、ＴＣＰ／ＩＰやＵＤＰ／ＩＰのポート番号とを組にしたものを用いる。ただしホスト名は通信相手のサーバまたはクライアントを指定し、通信路を開くことが目的であるため、この目的にかなえば、いかなる形態の表現をとっても差し支えない。特に、ここでＩＰアドレスやポート番号は例として出したものであり、本発明の範囲を限定するものではない。
【００６３】
キャッシュディレクトリ３２３は、ＵＲＬ４２１と、ホスト４２２と、ＵＲＬ存在確率４２３を含む組を保持する。この組は通常複数ある。ＵＲＬ４２１はＵＲＬである。ホスト４２２はサーバまたは情報源が存在するホスト名、ＵＲＬ存在確率４２３は、ホスト４２２で指定されるコンピュータに、ＵＲＬ４２１で指定されるホームページが存在する確率である。
【００６４】
通信コスト表３２４は、ホスト４３１と、時刻４３２と、通信コスト４３３と、通信回数４３４を含む組を保持する。この組は通常複数ある。ホスト４３１はサーバまたは情報源が存在するホスト名、時刻４３２は何曜日の何時かを格納する。通信コスト４３３は時刻４３２においてホスト４３１に対して行なわれた過去一定期間内の通信のスループット（単位時間当りの通信可能データ量）とレイテンシ（通信が受ける遅延時間）である。通信回数４３４は、時刻４３２においてホスト４３１に対して行なわれた過去一定期間内の通信の回数を格納する。
【００６５】
アクセス頻度表３２５は、ＵＲＬ４４１と、アクセス頻度４４２と、サイズ４４３を含む組を保持する。この組は通常複数ある。ＵＲＬ４４１はＵＲＬ、アクセス頻度４４２はＵＲＬ４４１で指定されるホームページを、過去の一定時間Ｃ１内に当該サーバ２０５がアクセスした回数である。本実施例のアクセス頻度４４２は、過去一週間の何曜日の何時に何回アクセスしたかを格納するカウンタ群である。サイズ４４３は前回アクセス時のＵＲＬ４４１のバイト数である。
【００６６】
リンク頻度表３２６は、参照元ＵＲＬ４５１と、参照先ＵＲＬ４５２と、アクセス頻度４５３を含む組を保持する。この組は通常複数ある。アクセス頻度４５３は参照元ＵＲＬ４５１から参照先ＵＲＬ４５２へのリンクを、過去の一定時間Ｃ２内に当該サーバ２０５がアクセスした回数である。本実施例のアクセス頻度４５３は、過去一週間の何曜日の何時に何回アクセスしたかを格納するカウンタ群である。
【００６７】
外部アクセス頻度表３２７は、ＵＲＬ４６１と、アクセス頻度４６２を含む組を保持する。この組は通常複数ある。ＵＲＬ４６１はＵＲＬ、アクセス頻度４６２はＵＲＬ４６１で指定されるホームページを、過去の一定時間Ｃ１内に本システムの他のサーバ２０５’、２０５’’、…がアクセスした回数である。本実施例のアクセス頻度４６２は、過去一週間の何曜日の何時に何回アクセスしたかを格納するカウンタ群である。
【００６８】
外部リンク頻度表３２８は、参照元ＵＲＬ４７１と、参照先ＵＲＬ４７２と、アクセス頻度４７３を含む組を保持する。この組は通常複数ある。アクセス頻度４７３は参照元ＵＲＬ４７１から参照先ＵＲＬ４７２へのリンクを、過去の一定時間Ｃ２内に他のサーバ２０５’、２０５’’、…がアクセスした回数である。本実施例のアクセス頻度４７３は、過去一週間の何曜日の何時に何回アクセスしたかを格納するカウンタ群である。
【００６９】
ホスト表は、ホスト名の組を保持する。ホスト表に現れるホスト名は、本システムに参加している計算機２０３、２０３’、２０３’’、…上のサーバ２０５、２０５’、２０５’’、…の全体である。
【００７０】
またサーバ２０５は、プリフェッチフラグ、新規ＵＲＬフラグ、前回アクセスＵＲＬの変数を用いる。プリフェッチフラグは、真偽値の変数であり、現在サーバ２０５がプリフェッチ中か、クライアント２０４（または他のサーバ２０５’、２０５’’、…）の依頼を処理中かを表わす。初期値は偽である。新規ＵＲＬフラグは、受信したＵＲＬ内容が新規にホームページキャッシュ１０４に付け加わったかどうかを示す真偽値の変数である。初期値は偽である。前回アクセスＵＲＬは、前回クライアントからの依頼に対して返答したＵＲＬである。初期値は「空」である。
【００７１】
図５に、ホームページグループ表１０７、ホストＵＲＬメッセージ１２４、ホスト頻度メッセージ１２５の構成を示す。
【００７２】
ホームページグループ表１０７は、先頭ＵＲＬ４８１とＵＲＬグループ４８２を含む組を保持する。この組は通常複数ある。各々の組は、連続してアクセスされることが多いＵＲＬの集合である。先頭ＵＲＬ４８１は１つのＵＲＬ、ＵＲＬグループ４８２は１つ以上のＵＲＬ４８３、ＵＲＬ４８３’、ＵＲＬ４８３’’、…である。
【００７３】
ホストＵＲＬメッセージ１２４は、ホスト５０１、ＵＲＬ５０２、フラグ５０３を含む組を内蔵したデータである。１つのホストＵＲＬメッセージ１２４にこの組が２つ以上内蔵されて構わない。ホスト５０１はホスト名、ＵＲＬ５０２は１つのＵＲＬ、フラグ５０３は真偽値である。ホストＵＲＬメッセージ１２４は、ホスト５０１で指定されるサーバがＵＲＬ５０２で指定されるＵＲＬを持っていること（フラグ５０３が真の場合）、または持っていないこと（フラグ５０３が偽の場合）を他のサーバに伝達する目的で用いられる。
【００７４】
ホスト頻度メッセージ１２５は、ホスト５１１、参照元ＵＲＬ５１２、参照先ＵＲＬ５１３、頻度５１４を含む組を内蔵したデータである。ホスト５１１はホスト名、参照元ＵＲＬ５１２は１つのＵＲＬ、参照先ＵＲＬ５１３は１つのＵＲＬまたは「空」、頻度５１４はカウンタである。ホスト頻度メッセージ１２５は、参照元ＵＲＬ５１２で指定されるＵＲＬまたは参照元ＵＲＬ５１２と参照先ＵＲＬ５１３の間のリンクを、過去の一定時間内にホスト５１１で指定されるサーバ２０５がアクセスした回数である頻度５１４を、他のサーバ２０５’、２０５’’、…に伝える目的で用いられる。なお、上記Ｃ１、Ｃ２の値はいずれも、サーバ２０５のコンパイル時または起動時または起動中に変更可能であって差し支えない。また、アクセス頻度４４２、アクセス頻度４５３、アクセス頻度４６２、アクセス頻度４７３、頻度５１４を過去一週間の何曜日の何時に何回アクセスしたかを格納するとしたのは、一例として示したものに過ぎず、本発明の範囲を限定するものではない。また、アクセス頻度表３２５、リンク頻度表３２６、外部アクセス頻度表３２７、外部リンク頻度表３２８の目的は、どのＵＲＬやどのリンクがどのくらいアクセスされたかを記録して利用することにあるので、この目的にかなえば、他の情報を記録することも考えられる。例えば、アクセス頻度４４２、アクセス頻度４５３、アクセス頻度４６２、アクセス頻度４７３、頻度５１４と併用して、または代りとして、最終アクセス時刻を記録しておき、ＬＲＵ（ｌｅａｓｔ ｒｅｃｅｎｔｌｙ ｕｓｅｄ）法によってどのＵＲＬやどのリンクがどのくらいアクセスされたかを見積もることも考えられる。
【００７５】
以下、図１、図３、図６、および図７を用いて、第１のサーバ２０５がクライアント２０４または他のサーバ２０５’、２０５’’、…からＵＲＬ内容の取得を依頼された際の、第１のサーバ２０５の処理の流れを説明する。第１のサーバ２０５は依頼入力部３０１でクライアント２０４または他のサーバの依頼を待ち、受け付ける（６０１、３５０）。当該クライアント２０４または他のサーバの依頼の中で、取得すべきＵＲＬ内容はＵＲＬで表現される。なおクライアント２０４または他のサーバからの依頼に含まれていたＵＲＬを以後「処理対象ＵＲＬ」と呼ぶ。第１のサーバ２０５において、処理対象ＵＲＬはキャッシュ表参照部３０２に渡される（３５１）。この際、プリフェッチフラグには「偽」を格納する。
【００７６】
キャッシュ表参照部３０２は、ホームページキャッシュ１０４内で処理対象ＵＲＬに等しいＵＲＬ４０１を持つ組を検索する（６０２、３８０）。もしそのような組が存在すれば（６０３）、返答部３０５に制御を移す（３６３）。一方そのような組が存在しなければ（６０４）、処理戦略部３０３に処理を移す（３５２）。
【００７７】
処理戦略部３０３は、アクセス戦略表１０５を用いて（３８１）、依頼を転送すべき１つ以上の第２のサーバ２０５’、２０５’’、…または情報源を選定する。まず、アクセス戦略表１０５内で処理対象ＵＲＬに等しいＵＲＬ４１１を持つ組を検索し（６０５）、そのような組が１つ以上存在するかどうかを調べる（６０６）。存在する場合（６０７）、後述の手順でこれら１つ以上の組の順位づけおよび選択を行ない（６０８）、当該順位づけおよび選択の結果選ばれた１つまたは複数の組のそれぞれに対して、算出した優先度の高い順にホスト４１２で指定されるサーバや情報源に依頼を転送する（６１０、３６５）。一方そのような組が１つも存在しない場合（６０９）、処理対象ＵＲＬの情報源に依頼を転送する（６１０、３６５）。なお、上記どちらの場合でも、依頼を転送したら受信部３０４に処理を移す（３５３）。依頼を転送したサーバ２０５’、２０５’’、…や情報源を、以後「依頼転送先」と呼ぶ。
【００７８】
順位づけおよび選択には、さまざまなアルゴリズムを使用しうるが、ネットワーク通信の効率面からの主要な指標はレイテンシとスループットと通信サイズである。また、依頼を転送した先に処理対象ＵＲＬに対応する情報が存在する確率も重要となる。本実施例では具体的には以下に示す順位づけと選択を行なう。なお、下で用いるＤ１、Ｄ２、Ｄ３、Ｄ４、Ｄ５、Ｄ６はいずれも定数であるが、これらの値はいずれもサーバ２０５のコンパイル時または起動時または起動中に変更可能であって差し支えない。また、ここで述べる順位づけを、サーバ２０５が保持する他の情報と合わせてもちいても何ら差し支えない。例えば、他の情報として、システム管理者がサーバ２０５に提供する情報、ＩＰアドレスの類似性、ルーティングのトポロジーやホップ数、通信回線の物理構成などを使うことが考えられる。
【００７９】
順序づけと選択の手順は以下の通りである。上記アクセス戦略表１０５内で処理対象ＵＲＬに等しいＵＲＬ４１１を持つ組から、通信コスト４１３に含まれるスループットが定数Ｄ１以下であるものを除外する。通信コスト４１３に含まれるレイテンシが定数Ｄ２以上であるものを除外する。ＵＲＬ存在確率４１４が定数Ｄ３以下であるものを除外する。各組の優先度（大きい方が高い）をレイテンシとスループットと通信サイズとＵＲＬの存在確率から、（ＵＲＬ存在確率４１４／（通信コスト４１３のレイテンシ＋サイズ４１５／通信コスト４１３のスループット））の式を用いて算出し、上位Ｄ４の組を選択する。次に、処理対象ＵＲＬに含まれる情報源のコンピュータがこの時点で選択に含まれていなければ、当該情報源を最も優先度が低くして選択に加える。以上が本実施例における順位づけおよび選択の手順である。
【００８０】
なお、上記で複数のホスト４１２にほぼ同時に依頼を転送すると、複数の依頼転送先からほぼ同時に返答が送られて、第１のサーバ２０５付近のネットワークが混雑する恐れがある。一方、複数のホスト４１２に順々に依頼を転送し、その都度返答を待っていると、結果的に取得すべきＵＲＬ内容の取得が遅くなる恐れがある。これらの問題を軽減するために、以下の通信プロトコルを用いることができる。図８を用いて説明する。この図では、サーバ２０５と依頼転送先との間の通信の様子を時間に沿って上から下に描いており、図の（ａ）と（ｂ）は、２つの異なる場面を示している。
【００８１】
図８の（ａ）で示すように依頼を転送する際に、上記優先度の上位Ｄ５個の依頼転送先（以後優先依頼転送先（８０１、８０１’、…）と呼ぶ）には、依頼を変更なしで転送する（８０３）。この依頼をうけた当該優先依頼転送先のそれぞれは、処理対象ＵＲＬに対応するＵＲＬ内容を保持していればすぐ第１のサーバ２０５への返答を開始する（８０４）。依頼を変更なしで転送することは、処理対象ＵＲＬがあればすぐに返答を開始せよ、という要求を意味する。
【００８２】
上記優先依頼転送先はそれぞれ、処理対象ＵＲＬに対応するＵＲＬ内容があれば当該ＵＲＬ内容を当該第１のサーバ２０５に返答し、なければ「処理対象ＵＲＬは存在しない」という返答を返す（８０５）。
【００８３】
一方第１のサーバ２０５は、上記優先依頼転送先以外の依頼転送先（以後非優先依頼転送先（８０２、８０２’、…）と呼ぶ）には、処理対象ＵＲＬの「返答待機依頼」（８０６）を送付する。返答待機依頼は、処理対象ＵＲＬが存在して、かつ後述する返答開始依頼が到着したら、返答を開始せよ、という意味をもつ。この際、非優先依頼転送先は、処理対象ＵＲＬに対応するＵＲＬ内容があれば待機し、なければ「処理対象ＵＲＬは存在しない」という返答を返す。
【００８４】
第１のサーバ２０５は図８の（ｂ）で示すように、上記優先依頼転送先のすべてから「処理対象ＵＲＬは存在しない」（８０５’）という返答が返ってきた場合（８０７）に、まだ「処理対象ＵＲＬは存在しない」という返答をしていない非優先依頼先の１つ以上に対して、「返答開始依頼」（８０８）を送る。当該依頼が非優先依頼先に届き、かつ当該非優先依頼先に処理対象ＵＲＬに対応するＵＲＬ内容があれば、当該非優先依頼先は当該第１のサーバ２０５に対して当該ＵＲＬ内容の返答を開始する（８０９）。なお、待機中の非優先依頼転送先のおのおのは、返答待機依頼から一定時間Ｄ６以内に返答開始依頼が到着しなければ、待機を中止して次の依頼に備える。
【００８５】
このプロトコルは、処理対象ＵＲＬに対応するＵＲＬ内容が優先依頼転送先の１つ以上に存在した場合に上記第１のサーバ２０５付近のネットワークの混雑を緩和する。なぜなら、依頼転送先を２つの集団に分けたことによって、同時に起こる返答の最大数を減らしているためである。また、処理対象ＵＲＬに対応するＵＲＬ内容が優先依頼転送先のどれにも存在しなかった場合にも、処理対象ＵＲＬに対応するＵＲＬ内容の取得が遅くなるのを防ぐ。なぜなら、第１のサーバ２０５は返答待機依頼に対する非優先依頼転送先からの返答を待たずに、返答開始依頼を流すことが可能であるからである。
【００８６】
なお、上述の本実施例における順位づけと選択の手順によれば、優先依頼転送先または非優先依頼転送先のいずれかに、処理対象ＵＲＬの情報源が含まれているので、依頼転送先のどこからも処理対象ＵＲＬに対応するＵＲＬ内容が転送されない場合は非常に稀であることに注意されたい。万一、処理対象ＵＲＬに対応するＵＲＬ内容が転送されなかった場合には、本実施例では処理対象ＵＲＬに対応するＵＲＬ内容の受信を断念する。なお本実施例の変形例として、この場合にさらに別の依頼転送先を選択して依頼を転送することが考えられる。また、別の変形例として、この場合に処理対象ＵＲＬに対応するＵＲＬ内容の受信を一定時間経過後に再度試みる方法が考えられる。
【００８７】
また本実施例におけるサーバ２０５は、当該サーバ２０５の設置者が利便性を享受させようとするクライアント２０４、２０４’、２０４’’、…以外に、他のサーバへの通信を行なう。他のサーバとの通信は、サーバ２０５のキャッシュの能力を発揮するために必要不可欠であるが、この通信によって元来の目的としたクライアント２０４、２０４’、２０４’’、…へのサービスが低下する恐れをはらんでいる。この問題を解決するためにサーバ２０５は、他のサーバからの依頼を一定時間内に一定量に抑える。本実施例のサーバ２０５は過去時間Ｔ１以内にＬ１バイト以上のＵＲＬ内容の転送が、他のサーバに行なわれた場合、以後当該Ｔ１内には他のサーバからの依頼を受け付けない。また、本発明の別の実施例としては、サーバ２０５が過去時間Ｔ１以内にＬ２回数以上のＵＲＬ内容の転送が、他のサーバに行なわれた場合、以後当該Ｔ１内には他のサーバからの依頼を受け付けない。なおここで、Ｔ１、Ｌ１、Ｌ２はコンパイル時または起動時または起動中に変更可能であって差し支えない。
【００８８】
受信部３０４では、処理対象ＵＲＬに対応するＵＲＬ内容が、１つ以上の依頼転送先から返答されてくるのを待ち、当該ＵＲＬ内容の受信を行ない（３６６）、通信コスト表３２４の更新を行なう。
【００８９】
処理対象ＵＲＬに対応する返答があるか、一定時間Ｔ２が経過するのを待つ。（６１１）。ここで返答があったかを調べ（６１２）、返答があった場合には（６１３）、返答に含まれるＵＲＬ内容は、ホームページキャッシュ１０４内の新規な組として格納される（６１４、３８２）。この際、処理対象ＵＲＬが当該新規な組のＵＲＬ４０１となり、当該受信されたＵＲＬ内容がＵＲＬ内容４０２となる。なお、処理対象ＵＲＬに対応するＵＲＬ内容の受信後（受信中でもかまわない）にホームページキャッシュ１０４の総量が定数Ｃ３を越えたかを調べる（６１５）。越えていた場合に限り後述するキャッシュ入れ替え部３１０に制御が移り、キャッシュ入れ替えの処理が行なわれる（６１６と６１７、図３の３５５と３５６）。そして下に述べるように通信コスト表３２４の更新を行ない（６１８）、返答部３０５に制御を移す（３５４）。一方、処理対象ＵＲＬに対応するＵＲＬ内容が受信されなかった場合（６１９）、すなわち、依頼転送先のすべてから「処理対象ＵＲＬは存在しない」という返答を得た場合には、ホームページキャッシュ１０４には何も操作を行なわなず返答部３０５に制御を移す（３５４）。なおここで、Ｔ２、Ｃ３はサーバ２０５のコンパイル時または起動時または起動中に変更可能であって差し支えない。
【００９０】
通信コスト表３２４の更新は、図９の手順で行なう。処理対象ＵＲＬに対応するＵＲＬ内容が、第１の依頼転送先から受信され始めた（９１０）時点で、通信コスト表３２４の第１の依頼転送先に対応する組を更新する。これは以下の手順で行なう。
【００９１】
（１）ホスト４３１が第１の依頼転送先に等しく、かつ時刻４３２が現在の時刻にあう組を検索する（９１１）。そして、通信コスト４３３のレイテンシを再計算するとともに、通信回数４３４を１増加する（９１２）。すなわち、９１１で該当する組が見つからなかった場合には、通信コスト表３２４に新たな組を作り、ホスト４３１を第１の依頼転送先で、時刻４３２を現在の時刻で、通信回数４３４を１で初期化する。そして、通信コスト４３３のレイテンシを今回のレイテンシ（すなわち当該第１の依頼転送先が優先依頼転送先ならば依頼を転送してから現在までの時間、また非優先依頼転送先ならば、転送開始依頼を送信してから現在までの時間）で初期化する。また９１１で該当する組が見つかった場合には、当該組の通信コスト４３３のレイテンシを、今回のレイテンシと、通信コスト４３３および通信回数４３４の値を用いて再計算するとともに、通信回数４３４に１を加える。
【００９２】
（２）次に、当該第１の依頼転送先からの受信の終了時刻ＥＮＤＴＩＭＥを予測して計算する（９１３）。これは以下の方法で行なう。アクセス戦略表１０５内で処理対象ＵＲＬに等しいＵＲＬ４１１を持ち、かつホスト４１２が当該第１の依頼転送先に等しい組を検索する。そのような組の通信コスト４１３とサイズ４１５とを用いて、ＥＮＤＴＩＭＥを（現在の時刻＋（サイズ４１５／通信コスト４１３のスループット））とする。
【００９３】
（３）次に、処理対象ＵＲＬに対応するＵＲＬ内容が第２の依頼転送先から受信され始めるか、第１の依頼転送先からの受信が終了するかのいずれかを待つ（９１４）。
【００９４】
（４）第１の依頼転送先からの受信が終了したかを調べる（９１５）。受信が終了しないうちに第２の依頼転送先から受信され始めた場合（９１６）、上記第１の依頼転送先の場合と同様の手順で、通信コスト表３２４の第２の依頼転送先に対応する組を更新するとともに（９１７）、上記第１の依頼転送先からの受信の終了時刻ＥＮＤＴＩＭＥと同様の手順で、第２の依頼転送先からの受信の終了時刻ＥＮＤＴＩＭＥ２を計算する（９１８）。そして、もしＥＮＤＴＩＭＥがＥＮＤＴＩＭＥ２＋定数Ｃ４よりも大きいかを調べ（９１９）、大きければ（９２０）、上記第１の依頼転送先からの受信を中止し（９２１）、第２の転送依頼先を第１の依頼転送先に置き換え（９２２）、ＥＮＤＴＩＭＥ２をＥＮＤＴＩＭＥとし（９２３）、９１４にもどる。なおここで、Ｃ４はサーバ２０５のコンパイル時または起動時または起動中に変更可能であって差し支えない。また、もしＥＮＤＴＩＭＥがＥＮＤＴＩＭＥ２＋定数Ｃ４以下であれば（９２４）、第２の依頼転送先からの受信を中止する（９２５）。
【００９５】
一方９１５において、第１の依頼転送先からの受信が終了した場合（９２６）には、通信コスト表３２４の第１の依頼転送先に対応する組の通信コスト４３３のスループットを、今回のスループット（すなわち、今回受信したＵＲＬ内容のサイズを、（当該第１の転送依頼先が優先依頼転送先ならば）依頼を転送してから現在までの時間または（非優先転送依頼先ならば）返答開始依頼を送信してから現在までの時間で割ったもの）と、通信コスト４３３および通信回数４３４の値を用いて再計算する（９２７）。そして新規ＵＲＬフラグを真を格納する（９２８）。以上が、通信コスト表３２４の更新手順である。
【００９６】
返答部３０５は以下の手順で動作する。プリフェッチフラグが「真」かどうかを調べる（６２０）。真ならば、プリフェッチ戦略部３０８に制御を移す（６２１、３６４）。プリフェッチフラグが「偽」であった場合（６２２）、処理対象ＵＲＬに対応するＵＲＬ内容が受信されたかどうか調べる（６２３）。受信されなかった場合（６２４）には、上記依頼を受けたクライアント２０４または他のサーバに「処理対象ＵＲＬは存在しない」を返答（３６７）した後（６２５）、依頼入力部３０１に制御を移して新たなクライアント２０４または他のサーバからの依頼を待つ（６２６）。一方処理対象ＵＲＬに対応するＵＲＬ内容が受信された場合（６２７）、そのＵＲＬ内容を上記依頼を受けたクライアント２０４または他のサーバに返答する（６２８、３６７）。
【００９７】
ここで、新規ＵＲＬフラグが真かどうかを調べる（６２９）。新規ＵＲＬフラグが真なら（６３０）、ホストＵＲＬメッセージ１２４の送信を行なったあと（６３１）、リンク統計更新部３０６に制御を移す（６３２、３５７）。新規ＵＲＬフラグが偽なら（６３３）、すぐにリンク統計更新部３０６に制御を移す（３５７）。
【００９８】
新規ＵＲＬフラグである場合、ホームページキャッシュ１０４に１つ以上の組が追加されたことを意味するので、ホストＵＲＬメッセージ１２４を行なう。まず新規ＵＲＬフラグに偽を格納してから、１つの組を持つホストＵＲＬメッセージ１２４を新たに作成し、当該組のホスト５０１に第１のサーバ２０５のホスト名を、ＵＲＬ５０２に処理対象ＵＲＬを、フラグ５０３に真をそれぞれ格納する。そして、当該組を持つホストＵＲＬメッセージ１２４をホスト表に含まれる他のサーバ２０５’、２０５’’、…のうち１つ以上に送信する。例えば、ホスト表中の組のうち、第１のサーバ２０５を含む組を検索する。この組から第１のサーバ２０５のホスト名を除いた１つ以上のホスト名のそれぞれに対して、上記手順で作成したホスト頻度メッセージ１２５を送信する方法が考えられる。また別の方法ではホスト表中の組に格納されているホスト名のそれぞれに対して、当該組を持つホストＵＲＬメッセージ１２４を送信する方法が考えられる。また、１つの組をもつホストＵＲＬメッセージ１２４をすぐに他のサーバ２０５’、２０５’’、…に送るのではなく、いくつかの組をまとめてから他のサーバ２０５’、２０５’’、…に送ることも考えられる。最初の方法では、比較的近いサーバ２０５’、２０５’’、…に通信範囲を限定することができ、また最後の方法では通信回数を削減することができる。
【００９９】
リンク統計更新部３０６では、アクセス頻度表３２５とリンク頻度表３２６を更新することにより、処理対象ＵＲＬのアクセス頻度と、処理対象ＵＲＬに至る特定のリンクがアクセスされる頻度を記録する（３８６）。以下にこの手順を述べる。
【０１００】
ステップ７０１で、アクセス頻度表３２５中の組のうち、ＵＲＬ４４１が処理対象ＵＲＬに等しい組を検索する。このような組がなければ、新たな組をアクセス頻度表３２５に作り、当該新たな組のＵＲＬ４４１を処理対象ＵＲＬで、アクセス頻度４４２のカウンタ群をすべて０で初期化する。そして検索で見つかった組または当該新たな組の、アクセス頻度４４２のうち現在時刻に対応するカウンタを１増加させ、サイズ４４３に処理対象ＵＲＬに対応するＵＲＬ内容のバイト数を格納する。
【０１０１】
次に、前回アクセスＵＲＬから処理対象ＵＲＬへのハイパー・テキスト・リンクがあるかを調べる（７０２）。関連があると判定した場合（７０３）、リンク頻度表３２６を更新する（７０４）。リンク頻度表３２６の更新は具体的には、リンク頻度表３２６中の組のうち、参照元ＵＲＬ４５１が前回アクセスＵＲＬに等しく、かつ参照先ＵＲＬ４５２が処理対象ＵＲＬに等しい組を検索する。このような組がなければ、新たな組をリンク頻度表３２６中に作り、当該新たな組の参照元ＵＲＬ４５１を前回アクセスＵＲＬで、参照先ＵＲＬ４５２を処理対象ＵＲＬで、アクセス頻度４５３のカウンタ群をすべて０で初期化する。そして検索で見つかった組または当該新たな組の、アクセス頻度４５３のうち現在時刻に対応するカウンタを１増加させる。そして、前回アクセスＵＲＬに処理対象ＵＲＬを格納してから、グループ更新部３０７に制御を移す（７０５、３５８）。
【０１０２】
一方、関連がないと判定した場合には（７０６）、前回アクセスＵＲＬに処理対象ＵＲＬを格納してから、プリフェッチ戦略部３０８に制御を移す。
【０１０３】
グループ更新部３０７では、ホームページグループ表１０７を更新する（７０７、３８７）。連続してアクセスされることが多いＵＲＬのひとつの集合を考えると、この集合をアクセスする際にはじめにアクセスされるＵＲＬが少数あると考えられる。本実施例ではこのような少数のＵＲＬを見つけた場合にのみリンク統計更新部３０６からグループ更新部３０７に制御を移すことを、すでに述べたリンク統計更新部３０６の場合わけにより行なっている。
【０１０４】
グループ更新部３０７は以下の手順で行なう。ホームページグループ表１０７中で、先頭ＵＲＬ４８１が処理対象ＵＲＬに等しい組を検索する。もしこのような組があれば、この組をホームページグループ表１０７中から削除する。次に、ホームページグループ表１０７中に新たな組を作成し、先頭ＵＲＬ４８１を処理対象ＵＲＬで、ＵＲＬグループ４８２を処理対象ＵＲＬから連続してアクセスされる確率が定数Ｃ５以上の１つ以上のＵＲＬで初期化する。処理対象ＵＲＬから連続してアクセスされる確率は、アクセス頻度表３２５と外部アクセス頻度表３２７とリンク頻度表３２６と外部リンク頻度表３２８を用いて計算することができる。なお、Ｃ５はサーバ２０５のコンパイル時または起動時または起動中に変更可能であって差し支えない。次に、第１のＵＲＬから第２のＵＲＬにリンクがある場合、第１のＵＲＬのアクセス頻度（アクセス頻度表３２５中ＵＲＬ４４１が第１のＵＲＬに等しい組のアクセス頻度４４２のカウンタ群の合計）が Ａ、第１のＵＲＬから第２のＵＲＬへのリンクのアクセス頻度（リンク頻度表３２６中参照元ＵＲＬ４５１が第１のＵＲＬに等しく、参照先ＵＲＬ４５２が第２のＵＲＬに等しい組のアクセス頻度４５３のカウンタ群の合計）が Ｂ、第１のＵＲＬの外部アクセス頻度（外部アクセス頻度表３２７中ＵＲＬ４６１が第１のＵＲＬに等しい組のアクセス頻度４６２のカウンタ）が Ｃ、第１のＵＲＬから第２のＵＲＬへのリンクの外部アクセス頻度（外部リンク頻度表３２８中参照元ＵＲＬ４７１が第１のＵＲＬに等しく、参照先ＵＲＬ４７２が第２のＵＲＬに等しい組のアクセス頻度４７３のカウンタの値）が Ｄとすると、第１のＵＲＬから第２のＵＲＬが連続してアクセスされる確率は（Ｂ／Ａ）×（Ｄ／Ｃ）と見積もる。もしＡとＢの値のどちらかが０の場合、第１のＵＲＬから第２のＵＲＬが連続してアクセスされる確率は０とする。またもしＣとＤの値のどちらかが０の場合、（Ｂ／Ａ）を第１のＵＲＬから第２のＵＲＬが連続してアクセスされる確率とする。
【０１０５】
また、第１のＵＲＬから第２のＵＲＬにリンクがない場合、第３、第４、…、第ＮのＵＲＬが存在して、第１のＵＲＬから第３のＵＲＬへのリンク、第３のＵＲＬから第４のＵＲＬへのリンク、…、第ＮのＵＲＬから第２のＵＲＬへのリンクがそれぞれある場合がある。この場合には、第１のＵＲＬから第３のＵＲＬが連続してアクセスされる確率、第３のＵＲＬから第４のＵＲＬが連続してアクセスされる確率、…、第ＮのＵＲＬから第２のＵＲＬが連続してアクセスされる確率をそれぞれｐ２、ｐ３、…、ｐＮとすると、第１のＵＲＬから第２のＵＲＬが連続してアクセスされる確率はｐ２×ｐ３×…×ｐＮとする。なお、このような推移閉包にかかわる計算には、例えばＡｈｏ他著の文献「データ構造とアルゴリズム」（１９８７年、培風館情報処理シリーズ１１）第６.３章に記載のダイクストラのアルゴリズム等良く知られた方法が利用できる。
【０１０６】
以上の処理の後、プリフェッチ戦略部３０８に制御を移す（３５９）。
【０１０７】
プリフェッチ戦略部３０８では、処理対象ＵＲＬがアクセスされた直後にアクセスされやすい１つ以上のプリフェッチＵＲＬ群に対応するＵＲＬ内容を決定し、当該プリフェッチＵＲＬ群をクライアント２０４または他のサーバからの依頼なしでホームページキャッシュ１０４に受信する。具体的には、以下の手順で処理を行なう。
【０１０８】
まず、この時点でクライアント２０４または他のサーバからの依頼が到着しているかを調べる（７０８）。到着していれば（７０９）、プリフェッチフラグに「偽」を格納し、依頼入力部３０１に制御を移す。
【０１０９】
一方依頼が到着していなければ（７１０）、プリフェッチフラグの値が真かを調べる（７１１）。
【０１１０】
プリフェッチフラグが「偽」ならば（７１２）、ホームページグループ表１０７で、処理対象ＵＲＬを含む組を検索し（３８８）、このような組に含まれる処理対象ＵＲＬ以外の１つ以上のＵＲＬをプリフェッチＵＲＬ群とする。（７１３）。ここでプリフェッチフラグに「真」を格納する。
【０１１１】
一方プリフェッチフラグが「真」ならば（７１４）、プリフェッチ中ＵＲＬをプリフェッチＵＲＬ群から削除する（７１５）。ここでプリフェッチＵＲＬ群が空になれば、プリフェッチフラグを「偽」にする。
【０１１２】
ここでプリフェッチＵＲＬ群に１つ以上のＵＲＬが含まれるかを調べる（７１６）。含まれるならば（７１７）、プリフェッチＵＲＬ群から１つのプリフェッチ中ＵＲＬを取り出して（７１８）、プリフェッチ中ＵＲＬを処理対象ＵＲＬとみなしてキャッシュ表参照部３０２に渡して（３６１）、すでに述べた手順でプリフェッチ中ＵＲＬの受信を開始する。含まれないならば（７１９）、プリフェッチスケジュール部３０９に制御を移す（３６０）。なおここまでの手順からも明らかなように、このプリフェッチは、クライアントのみならず他のサーバからの依頼によっても起動される。すなわち、多段に配置された複数のサーバが、一連のプリフェッチを行なうことが可能である。
【０１１３】
プリフェッチスケジュール部３０９では、今後アクセスされると考えられるＵＲＬで、現在ホームページキャッシュ１０４にないものを、将来ネットワークがすく時を狙って得るための準備を行なう。プリフェッチスケジュール部３０９は以下の手順で行なう。
【０１１４】
まず、ホームページグループ表１０７中で、先頭ＵＲＬ４８１が前回アクセスＵＲＬに等しい組を検索することによって、前回アクセスＵＲＬに対応するホームページグループ表１０７の組を選択する（７２０）。
【０１１５】
もしこのような組が存在すれば、ＵＲＬグループ４８２に格納されている１つ以上の第１のＵＲＬの各々について、プリフェッチする時刻をキャッシュディレクトリ３２３と通信コスト表３２４から決定する（７２１、３８４、３８５）。これは以下の手順で行なう。
【０１１６】
第１のＵＲＬに対応するＵＲＬ内容がホームページキャッシュ１０４にあれば何もしない。一方なければ、キャッシュディレクトリ３２３中の組で、ＵＲＬ４２１が第１のＵＲＬに等しいものを検索する。このような組がなければ何もしない。このような組が１つ以上存在する場合には、ＵＲＬ存在確率４２３が最も大きい組を１つ選択し、その組のホスト４２２を将来アクセスするホストとする。次に通信コスト表３２４中で、ホスト４３１が当該ホストに等しい第１の組を検索する。このような組がなければ、なにもしない。もしこのような第１の組が１つ以上あれば、アクセス頻度表３２５中で、ＵＲＬ４４１が当該第１のＵＲＬに等しい第２の組を検索する。もしこのような第２の組があれば、第１の組のうち、（（第２の組のサイズ４４３／第１の組の通信コスト４３３のスループット）＋第１の組の通信コスト４３３のレイテンシ）が最小な第３の組を１つ選ぶ。第２の組がなければ、（第１の組の通信コスト４３３のレイテンシ／第１の組の通信コスト４３３のスループット）が最小な第３の組を１つ選ぶ。
【０１１７】
この第３の組の時刻４３２に次に対応する時刻を「プリフェッチ時刻」と呼ぶ。例えば、時刻４３２が「水曜日２３：４０」で、現在時刻が１月３日火曜日の３：００であれば、プリフェッチ時刻は１月４日水曜日の２３：４０となる。
【０１１８】
次に、ステップ７２１で算出した、１つ以上の第１のＵＲＬのプリフェッチ時刻をタイマー３１１を設定する（７２２、３８９）。これにより、タイマー３１１は、すでに述べた手順で第１のＵＲＬの受信を行なうよう、時刻４３２の時刻に第１のＵＲＬの依頼をキャッシュ表参照部３０２に渡す。このタイマー３１１設定処理が終わったあとは、依頼入力部３０１に制御を移す（３６２）。
【０１１９】
以上がプリフェッチスケジュール部３０９の処理である。
【０１２０】
キャッシュ入れ替え
キャッシュ入れ替え部３１０では、ホームページキャッシュ１０４の部分的な削除を行なう（３８３）。ホームページキャッシュ１０４中の組の一部または全部のそれぞれについて、以下の「キャッシュ価値」を計算する。
【０１２１】
ある第１のＵＲＬのキャッシュ価値は、アクセス戦略表１０５とアクセス頻度表３２５を用いて計算する。アクセス戦略表１０５内で当該第１のＵＲＬに等しいＵＲＬ４１１を持つ１つ以上の第１の組を検索する。もしこのような組が複数あれば、それぞれの組の（通信コスト４１３のレイテンシ＋（サイズ４１５／通信コスト４１３のスループット））が最小の組を１つ選択し、第１の組とする。さらに、アクセス頻度表３２５中で、ＵＲＬ４４１が第１のＵＲＬに等しい第２の組を検索する。
【０１２２】
第１の組の（（サイズ４１５／通信コスト４１３のスループット）＋通信コスト４１３のレイテンシ）がＡ、第１のＵＲＬのアクセス頻度（すなわち第２の組のアクセス頻度４４２のカウンタ群の合計）が Ｂである場合、第１のＵＲＬのキャッシュ価値を（（Ａ×Ｂ）／第１の組のサイズ４１５）とする。万一第１の組または第２の組がなければ、第１のＵＲＬのキャッシュ価値は０とする。
【０１２３】
上記ホームページキャッシュ１０４中の組の一部または全部のそれぞれについて「キャッシュ価値」を計算したら、この「キャッシュ価値」が最も小さい組から順にホームページキャッシュ１０４から削除する。ホームページキャッシュ１０４からの削除は、ホームページキャッシュ１０４の総量が定数Ｃ３以下になるまで行なう。
【０１２４】
ホームページキャッシュ１０４から１つ以上の組が削除された場合、次に述べる手順でホストＵＲＬメッセージ１２４を送信する。ホストＵＲＬメッセージ１２４の送信は以下の手順で行なう。ホストＵＲＬメッセージ１２４を新たに作成し、上記ホームページキャッシュ１０４から削除された組のそれぞれに対して、ホストＵＲＬメッセージ１２４に新たな組を作成する。新たな組には、ホスト５０１に第１のサーバ２０５のホスト名、ＵＲＬ５０２に削除された組のＵＲＬ４０１、フラグ５０３に偽を格納する。そして作成したホストＵＲＬメッセージ１２４をホスト表に含まれる他のサーバ２０５’、２０５’’、…のうち１つ以上に送信する。送信相手の決定方法は、既にのべたホームページキャッシュ１０４に１つ以上の組が追加された場合のホストＵＲＬメッセージ１２４と同じである。
【０１２５】
タイマー処理
サーバ２０５は上記の一連の処理の他に、タイマー３１１によって一定時間ごとに行なわれる処理を行なう。なお以下に述べるタイマーによる各処理は、主フローとの競合を避ける目的で、依頼入力部３０１でクライアント２０４または他のサーバの依頼を待っている場合にのみ行なう。
【０１２６】
タイマー３１１は、定期的にアクセス戦略表１０５をキャッシュディレクトリ３２３と通信コスト表３２４とアクセス頻度表３２５から再構成する。これは主に、通信コスト表３２４の時刻４３２は何曜日の何時における各ホストへの通信コストを保持するのに対して、アクセス戦略表１０５は現在の各ホストへの通信コストを保持するためである。本実施例では時刻４３２が１時間毎の情報を保持するため、アクセス頻度表３２５の再構成は１時間に一度行なう。アクセス戦略表１０５、キャッシュディレクトリ３２３、通信コスト表３２４、アクセス頻度表３２５の内容から、再構成の手順は明らかである。
【０１２７】
タイマー３１１は、定期的にアクセス頻度表３２５とリンク頻度表３２６からホスト頻度メッセージ１２５を作成し、ホスト表に含まれる他のサーバ２０５’、２０５’’、…の１つ以上に送信する。これは以下の手順で行なう。
【０１２８】
まずホスト頻度メッセージ１２５を１つ作る。次にアクセス頻度表３２５中のすべての組に対して、当該ホスト頻度メッセージ１２５に新たな組を追加していく。追加する組のホスト５１１は第１のサーバ２０５のホスト名、参照元ＵＲＬ５１２はアクセス頻度表３２５の組のＵＲＬ４４１、参照先ＵＲＬ５１３は「空」、頻度５１４はアクセス頻度表３２５の組のアクセス頻度４４２のカウンタ群の合計をそれぞれ格納する。次にリンク頻度表３２６中のすべての組に対して、当該ホスト頻度メッセージ１２５に新たな組を追加していく。追加する組のホスト５１１は第１のサーバ２０５のホスト名、参照元ＵＲＬ５１２はリンク頻度表３２６の組の参照元ＵＲＬ４５１、参照先ＵＲＬ５１３はリンク頻度表３２６の組の参照先ＵＲＬ４５２、頻度５１４はリンク頻度表３２６の組のアクセス頻度４５３のカウンタ群の合計をそれぞれ格納する。次に、ホスト表中の組のうち、第１のサーバ２０５を含む組を検索する。この組から第１のサーバ２０５のホスト名を除いた１つ以上のホスト名のそれぞれに対して、上記手順で作成したホスト頻度メッセージ１２５を送信する。
【０１２９】
また、タイマー３１１は、上記第１のサーバ２０５を含む組へのホスト頻度メッセージ１２５の送信よりも粗い頻度（例えば上記送信１０回に１回の割合）で、ホスト表中の組のうち、第１のサーバ２０５を含まない組を検索し、この検索の結果である組からに格納されている１つ以上のホスト名のそれぞれに対して、上記手順で作成したホスト頻度メッセージ１２５を送信する。
【０１３０】
また、タイマー３１１は、キャッシュディレクトリ３２３の組のすべてについて、定期的にＵＲＬ存在確率４２３の再計算を行なう。これは以下の手順で行なう。キャッシュディレクトリ３２３中の組のそれぞれに対して、ＵＲＬ存在確率４２３を定数Ｃ６だけ減じたものをＵＲＬ存在確率４２３に格納する。もし減じた結果が定数Ｃ７以下なら、ＵＲＬ存在確率４２３にＣ７を格納する。なおここで、Ｃ６およびＣ７はサーバ２０５のコンパイル時または起動時または起動中に変更可能であって差し支えない。
【０１３１】
メッセージ処理
第１のサーバ２０５のサーバ間メッセージ処理部１０３が他のサーバ２０５’、２０５’’、…からホストＵＲＬメッセージ１２４を受け取ると、以下の手順でキャッシュディレクトリ３２３を更新する。ホストＵＲＬメッセージ１２４が内蔵する組のうちフラグ５０３が真の第１の組のそれぞれに対して、キャッシュディレクトリ３２３中の組で、ホスト４２２が第１の組のホスト５０１に等しくＵＲＬ４２１が第１の組のＵＲＬ５０２に等しい第２の組を検索する。このような第２の組があれば、当該第２の組のＵＲＬ存在確率４２３を１に設定する。また、このような第２の組がなければ、キャッシュディレクトリ３２３中に新たな組を作成し、ホスト４２２をホスト５０１で、ＵＲＬ４２１をＵＲＬ５０２で、ＵＲＬ存在確率４２３を１で初期化する。
【０１３２】
また、ホストＵＲＬメッセージ１２４が内蔵する組のうちフラグ５０３が偽の第３の組のそれぞれに対して、キャッシュディレクトリ３２３中の組で、ホスト４２２が第１の組のホスト５０１に等しくＵＲＬ４２１が第３の組のＵＲＬ５０２に等しい第４の組を検索する。このような第４の組があれば、当該第４の組を削除する。
【０１３３】
また、第１のサーバ２０５のサーバ間メッセージ処理部１０３が他のサーバ２０５’、２０５’’、…からホスト頻度メッセージ１２５を受け取ると、以下の手順で外部アクセス頻度表３２７と外部リンク頻度表３２８とを更新する。
【０１３４】
受け取ったホスト頻度メッセージ１２５が内蔵する組で参照先ＵＲＬ５１３が「空」の第１の組のそれぞれについて、外部アクセス頻度表３２７中で、ＵＲＬ４６１が第１の組の参照元ＵＲＬ５１２に等しい第２の組を検索する。このような第２の組が存在すれば、当該第２の組のアクセス頻度４６２に第１の組の頻度５１４を加え、再び当該第２の組のアクセス頻度４６２に格納する。一方このような第２の組が存在しなければ、外部アクセス頻度表３２７に新たな組を作成し、当該組のＵＲＬ４６１を第１の組の参照元ＵＲＬ５１２で、アクセス頻度４６２を第１の組の頻度５１４で初期化する。
【０１３５】
また、ホスト頻度メッセージ１２５が内蔵する組で参照先ＵＲＬ５１３が「空」以外の第３の組のそれぞれについて、外部リンク頻度表３２８中で、参照元ＵＲＬ４７１が第３の組の参照元ＵＲＬ５１２に等しく、参照先ＵＲＬ４７２が第３の組の参照先ＵＲＬ５１３に等しい第４の組を検索する。このような第４の組が存在すれば、当該第４の組のアクセス頻度４７３に第３の組の頻度５１４を加え、再び当該第４の組のアクセス頻度４７３に格納する。一方このような第４の組が存在しなければ、外部リンク頻度表３２８に新たな組を作成し、当該組の参照元ＵＲＬ４７１を第３の組の参照元ＵＲＬ５１２で、参照先ＵＲＬ４７２を第３の組の参照先ＵＲＬ５１３で、アクセス頻度４７３を第３の組の頻度５１４で初期化する。
【０１３６】
【発明の効果】
本発明によれば以下の効果が得られる。
【０１３７】
ユーザはクライアントを用いて任意の１つのサーバに接続して情報を依頼するだけで、複数のサーバが通信回線の不均一性と不安定性を隠蔽して情報を提供する。
【０１３８】
サーバ間の通信回線のスループットとレイテンシが異なっていても、サーバが相互に交換する情報により、各サーバは、最も高速に情報の取得が可能であると考えられるサーバを選択する。この結果、最も高速に情報の取得が可能であると考えられる通信回線を選択して利用することにより通信回線の不均一性が解決される。サーバが相互に交換する情報により、各サーバは例えば、時間帯や曜日によって回線の混雑が変化したり、ある通信回線の増強によってルーティングのパターンが変更され、別の回線が混雑したり混雑が解消されたりすることを考慮に入れる。この結果、各サーバは最も高速に情報の取得が可能であると考えられる他のサーバを、最も高速に情報の取得が可能であると考えられる通信回線を選択して利用する。これにより通信回線の不安定性を回避できる。
【図面の簡単な説明】
【図１】本実施例のサーバの内部構成の概略を示すブロック図。
【図２】本実施例の分散コンピュータ・システムを示す図。
【図３】サーバ２０５の内部構成を示すブロック図。
【図４】サーバ２０５内で用いられるデータ構造を示す図である。
【図５】サーバ２０５内で用いられるデータ構造を示す図（図５の続き）。
【図６】サーバ２０５内の処理手順を示すフローチャート。
【図７】サーバ２０５内の処理手順を示すフローチャート（図６の続き）。
【図８】サーバ２０５、２０５’、２０５’’、…が用いる混雑緩和のためのプロトコルを説明する図。
【図９】通信コスト表３２４の更新手順を示すフローチャート。
【符号の説明】
２０５ サーバ
２０４ クライアント
１０１ 依頼処理部
１０２ プリフェッチ部
１０３ サーバ間メッセージ処理部
１０４ ホームページキャッシュ
１０５ アクセス戦略表
１０６ 頻度ＤＢ
１０７ ホームページグループ表
１２４ ホストＵＲＬメッセージ
１２５ ホスト頻度メッセージ
３０１ 依頼入力部
３０２ キャッシュ表参照部
３０３ 処理戦略部
３０４ 受信部
３０５ 返答部
３０６ リンク統計更新部
３０７ グループ更新部
３０８ プリフェッチ戦略部
３０９ プリフェッチスケジュール部
３１０ キャッシュ入れ替え部
３２３ キャッシュディレクトリ
３２４ 通信コスト表
３２５ アクセス頻度表
３２６ リンク頻度表
３２７ 外部アクセス頻度表
３２８ 外部リンク頻度表。
Claims (3)
- ネットワークに接続された複数のサーバが、複数のホームページなどのデータを分散して保持し、
前記複数のサーバの１つである第１のサーバが、ネットワークに接続された１つ以上のクライアントから、前記複数のデータのうちのいずれかに対応するURLの識別子を含む取得要求を受信し、
前記第１のサーバは、当該クライアントに、前記識別子に対応するデータを送信する分散データの管理方法であって、
前記クライアントから、第１のデータに対応する識別子を含む前記取得要求を受信した際に、前記取得要求に含まれる識別子に対応するデータを第１のサーバが保持していない場合に、第１のサーバ以外の前記サーバから、第１のデータを保持している確率の高い１つ以上の第２のサーバを、過去の第１のサーバ以外の前記サーバとの前記取得要求を受信した時点より前の通信履歴に基づいて選択するステップと、
前記選択した第２のサーバに、当該識別子を含む前記取得要求を送信するステップと、
前記取得要求を受信した時点より前の通信履歴に基づいて選択した第２のサーバから前記クライアントが取得要求した第１のデータを受信し、前記取得要求を送信したクライアントに当該第１のデータを送信するステップと、
を第１のサーバが実行することを特徴とする分散データの管理方法。 - 請求項１に記載の分散データの管理方法であって、
第１のデータを保持している確率の高い１つ以上の第２のサーバを、過去の第１のサーバ以外の前記サーバとの通信履歴に基づいて選択するステップにおいて、
前記取得要求を受信した時点より前の、第１のデータを第２のサーバから最後に取得した時刻と、現在の時刻との差に基づいて、前記確率を計算するステップ
を第１のサーバが実行することを特徴とする分散データの管理方法。 - 請求項１に記載の分散データの管理方法であって、
前記クライアントに送信した第１のデータの内容から、第１のデータがハイパーリンクなどの形式で参照している第１のデータとは別の第２のデータについて、
第２のデータに対応する識別子を取得するステップと、
第２のデータの識別子を、第１のデータの識別子と関連付けてリンク情報として格納するステップと、
第１のデータの識別子を含む前記クライアントからの前記取得要求を受信した回数を格納するステップと、
前記回数と、前記リンク情報に基づいて、第１のサーバが、前記クライアントから、第２のデータの識別子を含む取得要求を受信する確率を計算するステップと、
前記計算結果に基づいて、第２のデータの識別子を含む前記取得要求を、第１のサーバ以外の前記サーバに対し送信するステップ
を第１のサーバが実行することを特徴とする、分散データの管理方法。
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP12524797A JP4134357B2 (ja) | 1997-05-15 | 1997-05-15 | 分散データ管理方法 |
| US09/079,151 US6182111B1 (en) | 1997-05-15 | 1998-05-15 | Method and system for managing distributed data |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP12524797A JP4134357B2 (ja) | 1997-05-15 | 1997-05-15 | 分散データ管理方法 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JPH10320337A JPH10320337A (ja) | 1998-12-04 |
| JP4134357B2 true JP4134357B2 (ja) | 2008-08-20 |
Family
ID=14905416
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP12524797A Expired - Fee Related JP4134357B2 (ja) | 1997-05-15 | 1997-05-15 | 分散データ管理方法 |
Country Status (2)
| Country | Link |
|---|---|
| US (1) | US6182111B1 (ja) |
| JP (1) | JP4134357B2 (ja) |
Families Citing this family (158)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP3117003B2 (ja) * | 1997-07-03 | 2000-12-11 | 日本電気株式会社 | 広域分散ファイルシステム |
| JP3424907B2 (ja) * | 1998-07-02 | 2003-07-07 | 日本電気株式会社 | ネットワークコンテンツキャッシュ装置 |
| US8010627B1 (en) * | 1998-09-25 | 2011-08-30 | Sprint Communications Company L.P. | Virtual content publishing system |
| US6195696B1 (en) * | 1998-10-01 | 2001-02-27 | International Business Machines Corporation | Systems, methods and computer program products for assigning, generating and delivering content to intranet users |
| US6564216B2 (en) * | 1998-10-29 | 2003-05-13 | Nortel Networks Limited | Server manager |
| US8225002B2 (en) | 1999-01-22 | 2012-07-17 | Network Disk, Inc. | Data storage and data sharing in a network of heterogeneous computers |
| DE60044220D1 (de) * | 1999-01-26 | 2010-06-02 | Xerox Corp | Multimodaler Informationzugriff |
| US20070162420A1 (en) * | 2004-01-21 | 2007-07-12 | Oracle International Corporation | Techniques for automatically discovering a database device on a network |
| US8321457B2 (en) | 2000-09-08 | 2012-11-27 | Oracle International Corporation | Techniques for automatically developing a web site |
| US6434596B1 (en) * | 1999-01-29 | 2002-08-13 | Sony Corporation | Method and system for distributed queues in a multimedia network with proxies |
| JP3942760B2 (ja) * | 1999-02-03 | 2007-07-11 | 富士通株式会社 | 情報収集装置 |
| US6421762B1 (en) | 1999-06-30 | 2002-07-16 | International Business Machines Corporation | Cache allocation policy based on speculative request history |
| US6360299B1 (en) | 1999-06-30 | 2002-03-19 | International Business Machines Corporation | Extended cache state with prefetched stream ID information |
| US6393528B1 (en) * | 1999-06-30 | 2002-05-21 | International Business Machines Corporation | Optimized cache allocation algorithm for multiple speculative requests |
| US6496921B1 (en) | 1999-06-30 | 2002-12-17 | International Business Machines Corporation | Layered speculative request unit with instruction optimized and storage hierarchy optimized partitions |
| US6532521B1 (en) * | 1999-06-30 | 2003-03-11 | International Business Machines Corporation | Mechanism for high performance transfer of speculative request data between levels of cache hierarchy |
| US6510494B1 (en) * | 1999-06-30 | 2003-01-21 | International Business Machines Corporation | Time based mechanism for cached speculative data deallocation |
| US6801341B1 (en) * | 1999-07-26 | 2004-10-05 | Cisco Technology, Inc. | Network distributed fax device |
| JP3664917B2 (ja) * | 1999-08-06 | 2005-06-29 | シャープ株式会社 | ネットワーク情報の表示方法およびその方法をプログラムとして格納した記憶媒体ならびにそのプログラムを実行するコンピュータ |
| US6810411B1 (en) * | 1999-09-13 | 2004-10-26 | Intel Corporation | Method and system for selecting a host in a communications network |
| US6427152B1 (en) * | 1999-12-08 | 2002-07-30 | International Business Machines Corporation | System and method for providing property histories of objects and collections for determining device capacity based thereon |
| WO2001042990A2 (en) * | 1999-12-13 | 2001-06-14 | Inktomi Corporation | File transmission from a first web server agent to a second web server agent |
| US6829680B1 (en) * | 2000-01-05 | 2004-12-07 | Sun Microsystems, Inc. | Method for employing a page prefetch cache for database applications |
| US6848028B1 (en) * | 2000-01-05 | 2005-01-25 | Sun Microsystems, Inc. | Microprocessor having a page prefetch cache for database applications |
| US6728716B1 (en) * | 2000-05-16 | 2004-04-27 | International Business Machines Corporation | Client-server filter computing system supporting relational database records and linked external files operable for distributed file system |
| JP3674471B2 (ja) * | 2000-07-25 | 2005-07-20 | 日本電気株式会社 | コンテンツ転送方法及びネットワークシステム並びにプログラムを記録した機械読み取り可能な記録媒体 |
| US6678795B1 (en) * | 2000-08-15 | 2004-01-13 | International Business Machines Corporation | Method and apparatus for memory prefetching based on intra-page usage history |
| US6795830B1 (en) * | 2000-09-08 | 2004-09-21 | Oracle International Corporation | Techniques for providing off-host storage for a database application |
| US6993657B1 (en) | 2000-09-08 | 2006-01-31 | Oracle International Corporation | Techniques for managing database systems with a community server |
| US6782389B1 (en) * | 2000-09-12 | 2004-08-24 | Ibrix, Inc. | Distributing files across multiple, permissibly heterogeneous, storage devices |
| US8935307B1 (en) | 2000-09-12 | 2015-01-13 | Hewlett-Packard Development Company, L.P. | Independent data access in a segmented file system |
| JP3962563B2 (ja) | 2000-09-12 | 2007-08-22 | キヤノン株式会社 | 画像処理装置、出力データ生成方法及びプログラム |
| US7406484B1 (en) * | 2000-09-12 | 2008-07-29 | Tbrix, Inc. | Storage allocation in a distributed segmented file system |
| US6816980B1 (en) | 2000-09-15 | 2004-11-09 | Zeronines Technology, Inc. | Fault tolerant, state-compatible computer system and method |
| US6760861B2 (en) * | 2000-09-29 | 2004-07-06 | Zeronines Technology, Inc. | System, method and apparatus for data processing and storage to provide continuous operations independent of device failure or disaster |
| JP2002202927A (ja) | 2000-11-02 | 2002-07-19 | Sony Computer Entertainment Inc | エンタテインメントシステム、サーバ装置、コンテンツの配信方法、コンテンツ配信プログラム、及びコンテンツ配信プログラムが記憶された記憶媒体 |
| US6609126B1 (en) | 2000-11-15 | 2003-08-19 | Appfluent Technology, Inc. | System and method for routing database requests to a database and a cache |
| WO2002044915A1 (en) * | 2000-11-30 | 2002-06-06 | Appfluent Technology, Inc. | System and method for delivering dynamic content |
| US7177917B2 (en) * | 2000-12-27 | 2007-02-13 | Softwired Ag | Scaleable message system |
| US20020107835A1 (en) * | 2001-02-08 | 2002-08-08 | Coram Michael T. | System and method for adaptive result set caching |
| US6920477B2 (en) * | 2001-04-06 | 2005-07-19 | President And Fellows Of Harvard College | Distributed, compressed Bloom filter Web cache server |
| US6996674B2 (en) * | 2001-05-07 | 2006-02-07 | International Business Machines Corporation | Method and apparatus for a global cache directory in a storage cluster |
| JP2003122818A (ja) * | 2001-10-12 | 2003-04-25 | Ricoh Co Ltd | 情報共有化システム |
| US7336775B2 (en) | 2001-10-30 | 2008-02-26 | Nikon Corporation | Image storage apparatus, image storage supporting apparatus, image storage system, image management apparatus and image saving apparatus |
| US7096249B2 (en) * | 2002-03-29 | 2006-08-22 | Intel Corporation | Method and system for distributing applications |
| US20040011689A1 (en) * | 2002-07-18 | 2004-01-22 | Witold Bauer | Sterilization container filter system |
| US7180862B2 (en) | 2002-07-18 | 2007-02-20 | Intel Corporation | Apparatus and method for virtual output queue feedback |
| US7284030B2 (en) * | 2002-09-16 | 2007-10-16 | Network Appliance, Inc. | Apparatus and method for processing data in a network |
| US7552223B1 (en) | 2002-09-16 | 2009-06-23 | Netapp, Inc. | Apparatus and method for data consistency in a proxy cache |
| US7171469B2 (en) * | 2002-09-16 | 2007-01-30 | Network Appliance, Inc. | Apparatus and method for storing data in a proxy cache in a network |
| US8533401B2 (en) * | 2002-12-30 | 2013-09-10 | Intel Corporation | Implementing direct access caches in coherent multiprocessors |
| US7421492B1 (en) * | 2003-01-24 | 2008-09-02 | Unisys Corporation | Control arrangement for operating multiple computer systems |
| US20040193754A1 (en) * | 2003-03-27 | 2004-09-30 | International Business Machines Corporation | DMA prefetch |
| JP3637910B2 (ja) * | 2003-04-04 | 2005-04-13 | ソニー株式会社 | データ処理方法およびそのシステム |
| US7200689B2 (en) * | 2003-07-31 | 2007-04-03 | International Business Machines Corporation | Cacheable DMA |
| US7657667B2 (en) * | 2004-03-25 | 2010-02-02 | International Business Machines Corporation | Method to provide cache management commands for a DMA controller |
| JP4534555B2 (ja) * | 2004-03-31 | 2010-09-01 | ブラザー工業株式会社 | データ受信装置及びプログラム |
| US20070220010A1 (en) * | 2006-03-15 | 2007-09-20 | Kent Thomas Ertugrul | Targeted content delivery for networks |
| JP2007317028A (ja) * | 2006-05-26 | 2007-12-06 | Ns Solutions Corp | 情報処理装置、データベース管理システム、情報処理装置の制御方法及びプログラム |
| US20080056274A1 (en) * | 2006-08-31 | 2008-03-06 | Mastrogiulio Joseph V | Method and apparatus for dynamically maintaining a routing database for a SIP server |
| WO2008041302A1 (en) * | 2006-09-29 | 2008-04-10 | Fujitsu Limited | Server disposing program and server disposing method |
| US9203918B2 (en) | 2007-03-15 | 2015-12-01 | Nokia Technologies Oy | Pulling information from information sources via refer requests |
| 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 |
| US8601090B1 (en) | 2008-03-31 | 2013-12-03 | Amazon Technologies, Inc. | Network resource identification |
| US7962597B2 (en) | 2008-03-31 | 2011-06-14 | Amazon Technologies, Inc. | Request routing based on class |
| US8447831B1 (en) | 2008-03-31 | 2013-05-21 | Amazon Technologies, Inc. | Incentive driven content delivery |
| 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 |
| US8533293B1 (en) | 2008-03-31 | 2013-09-10 | Amazon Technologies, Inc. | Client side cache management |
| US8606996B2 (en) | 2008-03-31 | 2013-12-10 | Amazon Technologies, Inc. | Cache optimization |
| US7970820B1 (en) | 2008-03-31 | 2011-06-28 | Amazon Technologies, Inc. | Locality based content distribution |
| JP2008259215A (ja) * | 2008-04-14 | 2008-10-23 | Nikon Corp | 画像管理装置 |
| US9912740B2 (en) | 2008-06-30 | 2018-03-06 | Amazon Technologies, Inc. | Latency measurement in resource requests |
| 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 |
| 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 |
| US8732309B1 (en) | 2008-11-17 | 2014-05-20 | Amazon Technologies, Inc. | Request routing utilizing cost information |
| US8065417B1 (en) | 2008-11-17 | 2011-11-22 | Amazon Technologies, Inc. | Service provider registration by a content broker |
| US8073940B1 (en) | 2008-11-17 | 2011-12-06 | Amazon Technologies, Inc. | Managing content delivery network service providers |
| US8521851B1 (en) | 2009-03-27 | 2013-08-27 | Amazon Technologies, Inc. | DNS query processing using resource identifiers specifying an application broker |
| US8688837B1 (en) | 2009-03-27 | 2014-04-01 | Amazon Technologies, Inc. | Dynamically translating resource identifiers for request routing using popularity information |
| US8756341B1 (en) | 2009-03-27 | 2014-06-17 | Amazon Technologies, Inc. | Request routing utilizing popularity information |
| US8412823B1 (en) | 2009-03-27 | 2013-04-02 | Amazon Technologies, Inc. | Managing tracking information entries in resource cache components |
| US8782236B1 (en) | 2009-06-16 | 2014-07-15 | Amazon Technologies, Inc. | Managing resources using resource expiration data |
| WO2011018850A1 (ja) * | 2009-08-12 | 2011-02-17 | 三菱電機株式会社 | データ転送装置、データ転送方法及びデータ転送システム |
| 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 |
| US9495338B1 (en) | 2010-01-28 | 2016-11-15 | Amazon Technologies, Inc. | Content distribution network |
| EP2532137B1 (en) * | 2010-02-05 | 2015-08-12 | Telefonaktiebolaget L M Ericsson (PUBL) | Method and node entity for enhancing content delivery network |
| JP5497963B2 (ja) | 2010-04-20 | 2014-05-21 | ヒューレット−パッカード デベロップメント カンパニー エル．ピー． | 表面増強発光のための自己配列型発光強化装置 |
| 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 |
| US10097398B1 (en) | 2010-09-28 | 2018-10-09 | Amazon Technologies, Inc. | Point of presence management in request routing |
| US8819283B2 (en) | 2010-09-28 | 2014-08-26 | Amazon Technologies, Inc. | Request routing in a networked environment |
| US8938526B1 (en) | 2010-09-28 | 2015-01-20 | 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 |
| US9712484B1 (en) | 2010-09-28 | 2017-07-18 | Amazon Technologies, Inc. | Managing request routing information utilizing client identifiers |
| US8577992B1 (en) | 2010-09-28 | 2013-11-05 | Amazon Technologies, Inc. | Request routing management based on network components |
| US8924528B1 (en) | 2010-09-28 | 2014-12-30 | Amazon Technologies, Inc. | Latency measurement in resource requests |
| US8930513B1 (en) | 2010-09-28 | 2015-01-06 | Amazon Technologies, Inc. | Latency measurement in resource requests |
| US8468247B1 (en) | 2010-09-28 | 2013-06-18 | Amazon Technologies, Inc. | Point of presence management in request routing |
| WO2012054027A1 (en) | 2010-10-20 | 2012-04-26 | Hewlett-Packard Development Company, L.P. | Chemical-analysis device integrated with metallic-nanofinger device for chemical sensing |
| US9274058B2 (en) | 2010-10-20 | 2016-03-01 | Hewlett-Packard Development Company, L.P. | Metallic-nanofinger device for chemical sensing |
| 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 |
| JP5566320B2 (ja) * | 2011-03-02 | 2014-08-06 | Ｋｄｄｉ株式会社 | キャッシュ装置及び方法並びにプログラム |
| 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 |
| US9525659B1 (en) * | 2012-09-04 | 2016-12-20 | Amazon Technologies, Inc. | Request routing utilizing point of presence load information |
| US9135048B2 (en) | 2012-09-20 | 2015-09-15 | Amazon Technologies, Inc. | Automated profiling of resource usage |
| US9323577B2 (en) | 2012-09-20 | 2016-04-26 | Amazon Technologies, Inc. | Automated profiling of resource usage |
| US10205698B1 (en) | 2012-12-19 | 2019-02-12 | Amazon Technologies, Inc. | Source-dependent address resolution |
| US9294391B1 (en) | 2013-06-04 | 2016-03-22 | Amazon Technologies, Inc. | Managing network computing components utilizing request routing |
| JP6303300B2 (ja) * | 2013-06-25 | 2018-04-04 | 富士通株式会社 | 制御依頼方法、情報処理装置、システム、およびプログラム |
| US20150032798A1 (en) * | 2013-07-24 | 2015-01-29 | Alcatel-Lucent Canada Inc. | Method And Apparatus For Providing Redundant Data Access |
| JP2015170125A (ja) * | 2014-03-06 | 2015-09-28 | 富士通株式会社 | コンテンツ取得プログラム、装置、及び方法 |
| US10097448B1 (en) | 2014-12-18 | 2018-10-09 | Amazon Technologies, Inc. | Routing mode and point-of-presence selection service |
| US10033627B1 (en) | 2014-12-18 | 2018-07-24 | 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 |
| US9887932B1 (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 |
| US9832141B1 (en) | 2015-05-13 | 2017-11-28 | Amazon Technologies, Inc. | Routing based request correlation |
| 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 |
| 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 |
| US10156841B2 (en) | 2015-12-31 | 2018-12-18 | General Electric Company | Identity management and device enrollment in a cloud service |
| 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 |
| US10616250B2 (en) | 2016-10-05 | 2020-04-07 | Amazon Technologies, Inc. | Network addresses with encoded DNS-level information |
| US10831549B1 (en) | 2016-12-27 | 2020-11-10 | Amazon Technologies, Inc. | Multi-region request-driven code execution system |
| US10372499B1 (en) | 2016-12-27 | 2019-08-06 | Amazon Technologies, Inc. | Efficient region selection system for executing request-driven code |
| US10938884B1 (en) | 2017-01-30 | 2021-03-02 | Amazon Technologies, Inc. | Origin server cloaking using virtual private cloud network environments |
| 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 |
| US11157631B1 (en) * | 2017-12-19 | 2021-10-26 | Robert J. Whelton | System and method for securely indexing, storing, and retrieving data within a computer network |
| 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 |
Family Cites Families (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP1130848B1 (en) * | 1993-03-08 | 2004-10-06 | Hewlett-Packard Company (a Delaware corporation) | Network analysis method |
| US5548724A (en) * | 1993-03-22 | 1996-08-20 | Hitachi, Ltd. | File server system and file access control method of the same |
| JP3468868B2 (ja) * | 1994-09-26 | 2003-11-17 | 株式会社日立製作所 | 通信ネットワークシステムおよび情報処理端末 |
| US5915095A (en) * | 1995-08-08 | 1999-06-22 | Ncr Corporation | Method and apparatus for balancing processing requests among a plurality of servers based on measurable characteristics off network node and common application |
| US5764908A (en) * | 1996-07-12 | 1998-06-09 | Sofmap Future Design, Inc. | Network system containing program modules residing in different computers and executing commands without return results to calling modules |
| US5774660A (en) * | 1996-08-05 | 1998-06-30 | Resonate, Inc. | World-wide-web server with delayed resource-binding for resource-based load balancing on a distributed resource multi-node network |
| JPH10187525A (ja) * | 1996-10-28 | 1998-07-21 | Matsushita Electric Ind Co Ltd | 代理情報取得装置および情報転送管理装置 |
| US5913041A (en) * | 1996-12-09 | 1999-06-15 | Hewlett-Packard Company | System for determining data transfer rates in accordance with log information relates to history of data transfer activities that independently stored in content servers |
-
1997
- 1997-05-15 JP JP12524797A patent/JP4134357B2/ja not_active Expired - Fee Related
-
1998
- 1998-05-15 US US09/079,151 patent/US6182111B1/en not_active Expired - Lifetime
Also Published As
| Publication number | Publication date |
|---|---|
| US6182111B1 (en) | 2001-01-30 |
| JPH10320337A (ja) | 1998-12-04 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4134357B2 (ja) | 分散データ管理方法 | |
| US9602618B2 (en) | Method and system for dynamic distributed data caching | |
| US8271628B2 (en) | Method and system for community data caching | |
| EP2266043B1 (en) | Cache optimzation | |
| US7769823B2 (en) | Method and system for distributing requests for content | |
| US6760756B1 (en) | Distributed virtual web cache implemented entirely in software | |
| JP3481054B2 (ja) | ゲートウェイ装置、クライアント計算機およびそれらを接続した分散ファイルシステム | |
| US20030126122A1 (en) | Systems, methods and programming for routing and indexing globally addressable objects and associated business models | |
| JP2008090826A (ja) | 最適化されたネットワーク・リソース・ロケーション | |
| EP1313033A2 (en) | File system, control method, and program | |
| WO2002056182A2 (en) | Method and system for community data caching | |
| JPH11195048A (ja) | 分散検索システムおよび分散検索システムにおける検索装置 | |
| JP2007317107A (ja) | 情報処理システム、及び情報処理装置、並びに制御プログラム | |
| AU5756000A (en) | Distributed virtual web cache implemented entirely in software | |
| JP2004030690A (ja) | ゲートウェイ装置、クライアント計算機およびプロキシサーバ計算機 | |
| Chandranmenon | Reducing internet latency using precomputed hints |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20040330 |
|
| RD01 | Notification of change of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7421 Effective date: 20040330 |
|
| RD01 | Notification of change of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7421 Effective date: 20060417 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20061020 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20061107 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20070104 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20070417 |
|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20080205 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20080403 |
|
| A911 | Transfer to examiner for re-examination before appeal (zenchi) |
Free format text: JAPANESE INTERMEDIATE CODE: A911 Effective date: 20080410 |
|
| 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: 20080507 |
|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20080520 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110613 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110613 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120613 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120613 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130613 Year of fee payment: 5 |
|
| LAPS | Cancellation because of no payment of annual fees |