JPH10320337A

JPH10320337A - 分散データ管理方法

Info

Publication number: JPH10320337A
Application number: JP9125247A
Authority: JP
Inventors: Shigekazu Inohara; 茂和猪原; Toyohiko Kagimasa; 豊彦鍵政; Yoshimasa Masuoka; 義政増岡; Fumio Noda; 文雄野田; Kiyouka Bin; 京華閔
Original assignee: Hitachi Ltd
Current assignee: Hitachi Ltd
Priority date: 1997-05-15
Filing date: 1997-05-15
Publication date: 1998-12-04
Anticipated expiration: 2017-05-15
Also published as: JP4134357B2; US6182111B1

Abstract

(57)【要約】【課題】インターネット使用人口の増加によるインタ
ーネットの不均一性と不安定性を低減し、ユーザに対し
てより快適な情報システムのサービスを行なうために、
ユーザがクライアントに要求を発してから、その要求が
満たされるまでの時間を短縮することが本発明の目的で
ある。【解決手段】複数のサーバ（２０５’、２０５”）が
全体で１つのサービスを提供する際、各サーバは過去の
通信回線の状況（スループットやレイテンシ）を蓄積
し、この蓄積情報をもとに任意のサーバ間で、通信回線
の状況に応じたキャッシュ参照およびプリフェッチを行
なう。【効果】インターネットの通信回線の不均一性と不安
定性がある状況下でも、ユーザがクライアントに要求を
発してから、その要求が満たされるまでの時間を短縮
し、また特定の通信回線が不通でも、できる限りクライ
アントの依頼を処理することによりユーザにより快適な
情報システムのサービスを行なう。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、計算機システムに
関し、例えばネットワークによって接続された複数の計
算機が、情報を流通・共有・変更するシステム（情報シ
ステム）内の情報を管理する分散データ管理方法に関
し、特にＷｏｒｌｄ―ＷｉｄｅＷｅｂ（ＷＷＷ）に好
適な分散データ管理方法に関する。

【０００２】

【従来の技術】以下の記述に用いるいくつかの用語をま
ず説明する。

【０００３】インターネット上のＷＷＷ、匿名ＦＴＰを
はじめとする情報システムは、通常分散コンピュータ・
システムの一形態である「クライアント・サーバ・シス
テム」の形態で構築されている。クライアント・サーバ
・システムでは、システム全体の処理は２種類に分割さ
れ、第１の部分を「サーバ」と呼ばれる実行中のプログ
ラム（以下、プロセスという）で処理し、第２の部分を
複数の「クライアント」と呼ばれるプロセスで処理す
る。情報システムのクライアントは通常、個人または企
業内のユーザが操作するコンピュータで動作する。情報
システムのサーバは、クライアントに提供する情報を格
納する。情報システムのクライアントは、サーバに新た
な情報を格納したり、サーバに要請して情報を取得す
る。

【０００４】コンピュータ・システムでは、１つの情報
を複数の場所に一時的にコピーしておくことにより、当
該情報へのアクセスを高速にしたり、アクセスできる可
能性を高めることが広く行なわれる。このようなコピー
はヒント、キャッシュ、レプリカ、スタッシュ等と呼び
分けられる（ＳａｐｅＭｕｌｌｅｎｄｅｒ編の文献”
ＤｉｓｔｒｉｂｕｔｅｄＳｙｓｔｅｍｓ（１ｓｔｅ
ｄ.）”ｐｐ.１３―１５，ＡＣＭｐｒｅｓｓ，１９８
９参照）。以下ではこれらのコピーを総称して「キャッ
シュ」と呼ぶ。またキャッシュを作ることを「キャッシ
ュする」と記す。

【０００５】ＷＷＷでは、ＷＷＷサーバが、発信する情
報を「ホームページ」と呼ばれる単位で保持している。
ホームページは、それぞれＵＲＬ（ＵｎｉｆｏｒｍＲ
ｅｓｏｕｒｃｅＬｏｃａｔｏｒの略）と呼ばれる名前
を持っている。ＵＲＬはＷＷＷで用いられるプロトコル
と、情報源であるコンピュータのホスト名、および情報
源において特定のデータを指定することが可能な文字列
である。”ｈｔｔｐ：／／ｗｗｗ.ｈｉｔａｃｈｉ.ｃ
ｏ.ｊｐ／ｉｎｄｅｘ.ｈｔｍｌ”はＵＲＬの一例であ
る。

【０００６】なお、一般にＵＲＬは（ホームページのデ
ータや画像データ等の）ひとかたまりのデータに対応づ
けられるが、以後このひとかたまりのデータのことを
「ＵＲＬに対応する情報」または「ＵＲＬ内容」と記
す。また、第１のＵＲＬに対応する情報中に含まれる第
２のＵＲＬは「ハイパー・テキスト・リンク（または簡
単にリンク）」とよばれる。第１のＵＲＬに対応する情
報中に第２のＵＲＬが含まれることを、以下「第１のＵ
ＲＬから第２のＵＲＬにリンクがある」と記す。

【０００７】ＷＷＷで用いられている技術（公知例１）
を説明する。

【０００８】ＷＷＷクライアントのユーザは、アクセス
したいホームページのＵＲＬをＷＷＷクライアントに指
定する。ＷＷＷのサーバとクライアントの第１の処理形
態では、ＷＷＷクライアントは当該ＵＲＬの第２要素で
指定されるＷＷＷサーバに対して、当該ＵＲＬに対応す
るホームページの送信を依頼する。当該ＷＷＷサーバ
は、この要求に応えて、当該ホームページを当該ＷＷＷ
クライアントに与える。

【０００９】また第２の処理形態では、ＷＷＷクライア
ントが、ユーザが与えたＵＲＬの第２要素で指定される
ＷＷＷサーバに依頼を行なうかわりに、「プロキシ・サ
ーバ」と呼ばれる第２のサーバに依頼を行なう場合もあ
る。当該第２のサーバは、当該ＷＷＷサーバから当該Ｕ
ＲＬに対応するホームページを得るか、さらに別のプロ
キシ・サーバに当該ＵＲＬに対応する情報取得を依頼す
る。このプロキシ・サーバの依頼が複数段階である場
合、プロキシ・サーバは親子関係を持つ。親子関係を持
つプロキシ・サーバに関しては、例えばＡ.Ｃｈａｎｋ
ｈｕｎｔｈｏｄ他の文献”ＡＨｉｅｒａｒｃｈｉｃａ
ｌＩｎｔｅｒｎｅｔＯｂｊｅｃｔＣａｃｈｅ”
（１９９６ＵＳＥＮＩＸＴｅｃｈｎｉｃａｌＣｏ
ｎｆｅｒｅｎｃｅ，ｐｐ.１５３―１６３，１９９６）
に記載されている。

【００１０】なお、ＷＷＷのクライアントやプロキシ・
サーバは、キャッシュを持つことができる。クライアン
トが持つキャッシュは、以前に当該クライアントが取得
したホームページを保持しており、当該クライアントの
みが利用する。プロキシ・サーバがもつキャッシュは、
当該プロキシ・サーバが１つ以上のクライアントまたは
他の１つ以上のプロキシ・サーバまたはその両方の依頼
によって取得したホームページを保持しており、当該プ
ロシキ・サーバを利用するクライアントおよびプロキシ
・サーバによって共用される。

【００１１】ネットワーク・ニュース・システム（以後
公知例２と呼ぶ。Ｂ.Ｋａｎｔｏｒ他著の文献”Ｎｅｔ
ｗｏｒｋＮｅｗｓＴｒａｎｓｆｅｒＰｒｏｔｏｃ
ｏｌ：ＡＰｒｏｐｏｓｅｄＳｔａｎｄａｒｄｆｏ
ｒｔｈｅＳｔｒｅａｍ―ＢａｓｅｄＴｒａｎｓｍ
ｉｓｓｉｏｎｏｆＮｅｗｓ”ＮｅｔｗｏｒｋＷｏ
ｒｋｉｎｇＧｒｏｕｐＲＦＣ―９７７等に記載され
ている）は、１つ以上のサーバによって構成される。ユ
ーザは通常、クライアントを用いて当該複数のサーバの
うち１つを選択して利用する。ネットワーク・ニュース
・システムにおける情報の単位は「ニュース記事」と呼
ばれる。ユーザは通常、クライアントを用いてニュース
記事をサーバに提供する操作と、ニュース記事をサーバ
から取り出す操作を行なう。ユーザがニュース記事が第
１のサーバに提供すると、第１のサーバは１つ以上の第
２のサーバに当該ニュース記事のコピーを送り、さらに
第２のサーバが別のサーバに当該ニュース記事のコピー
を送る、という具合で、最終的には上記複数のサーバす
べてに当該ニュース記事がコピーされる。

【００１２】公知例３として、広域名前サービスＤｏｍ
ａｉｎＮａｍｅＳｙｓｔｅｍを説明する。（以下Ｄ
ＮＳと略す。例えばＰ.Ｍｏｃｋａｐｅｔｒｉｓ著の文
献”ＤｏｍａｉｎＮａｍｅｓ―Ｉｍｐｌｅｍｅｎｔａ
ｔｉｏｎａｎｄＳｐｅｃｉｆｉｃａｔｉｏｎ”Ｎｅ
ｔｗｏｒｋＷｏｒｋｉｎｇＧｒｏｕｐＲＦＣ―１
０３５の特に第２節に記載されている）ＤＮＳは主にシ
ンボリックなホスト名と、そのホスト名の付随情報（Ｉ
Ｐアドレスやメールサーバ）とを対応づける。複数のＤ
ＮＳサーバは木構造を構成する。クライアントの依頼は
当該木構造をたどって、複数のサーバの間を転送され、
処理される。ＤＮＳのクライアントであるｒｅｓｏｌｖ
ｅｒは、あるホスト名に対応するホスト関連情報をサー
バの１つに依頼する。この際当該サーバは、当該ホスト
名に対応するホスト関連情報をクライアントに返すか、
当該ＤＮＳサーバの親サーバ（ＤＮＳサーバの木構造に
おいて根に一段近いＤＮＳサーバ）に当該依頼を転送す
る。なお親サーバは、直接の子サーバ群がどのホスト関
連情報を持つかを把握している。このため、木構造の根
まで依頼が転送されると、今度は木構造を下って依頼を
処理できるＤＮＳサーバの方に依頼を転送する。依頼は
最終的に、ホスト関連情報を保持するＤＮＳサーバに到
達して、クライアントにホスト関連情報が返されるか、
木構造を下っていく段階で、当該依頼のホスト名に対応
するホスト関連情報がどのＤＮＳサーバからも提供され
ていないことが判明して、クライアントに失敗が返され
る。

【００１３】ローカル・エリア・ネットワーク（ＬＡ
Ｎ）内の分散ファイルシステムにおいて、キャッシュの
ための空間を複数のコンピュータで共有する方法も知ら
れている（公知例４）。ＭｉｃｈａｅｌＤａｈｌｉｎ
他著の文献”ＣｏｏｐｅｒａｔｉｖｅＣａｃｈｉｎ
ｇ：ＵｓｉｎｇＲｅｍｏｔｅＣｌｉｅｎｔＭｅｍ
ｏｒｙｔｏＩｍｐｒｏｖｅＦｉｌｅＳｙｓｔｅ
ｍＰｅｒｆｏｒｍａｎｃｅ”（ＦｉｒｓｔＵＳＥＮ
ＩＸＳｙｍｐｏｓｉｕｍｏｎＯｐｅｒａｔｉｎｇ
ＳｙｓｔｅｍｓＤｅｓｉｇｎａｎｄＩｍｐｌｅ
ｍｅｎｔａｔｉｏｎ，ｐｐ.２６７―２８０，１９９
４）では、クライアントはまず「マネージャ」と呼ばれ
るサーバに、ファイルブロックを依頼する。マネージャ
は、どのファイル・ブロックがどのコンピュータに格納
されているかを保持しており、クライアントにファイル
・ブロックが格納されているコンピュータを返答する
か、当該コンピュータにクライアントの要求を転送す
る。同様の方法としては、Ｍ.Ｊ.Ｆｅｅｌｅｙ他著の文
献”ＩｍｐｌｅｍｅｎｔｉｎｇＧｌｏｂａｌＭｅｍ
ｏｒｙＭａｎａｇｅｍｅｎｔｉｎａｎＷｏｒｋｓ
ｔａｔｉｏｎＣｌｕｓｔｅｒ”（ＡＣＭ１５ｔｈ
ＳｙｍｐｏｓｉｕｍｏｎＯｐｅｒａｔｉｎｇＳｙ
ｓｔｅｍｓＰｒｉｎｃｉｐｌｅｓ，ｐｐ.２０１―２
１２，１９９５）やＰ.Ｓａｒｋａｒ他著の文献”Ｅ
ｆｆｉｃｉｅｎｔＣｏｏｐｅｒａｔｉｖｅＣａｃｈ
ｉｎｇＵｓｉｎｇＨｉｎｔｓ”（ＳｅｃｏｎｄＵ
ＳＥＮＩＸＳｙｍｐｏｓｉｕｍｏｎＯｐｅｒａｔ
ｉｎｇＳｙｓｔｅｍｓＤｅｓｉｇｎａｎｄＩｍ
ｐｌｅｍｅｎｔａｔｉｏｎ，ｐｐ.３５―４６，１９９
６）が知られている。マネージャは複数存在することが
できるが、ファイル・ブロックとマネージャとの対応関
係はあらかじめ定められており、全クライアントおよび
サーバがその対応関係を知っている。この対応関係はシ
ステム動作中に変化しない。

【００１４】公知例５および公知例６として、ｃａｃｈ
ｅ―ｃｏｈｅｒｅｎｔｎｏｎ―ｕｎｉｆｏｒｍｍｅ
ｍｏｒｙａｃｃｅｓｓ（ＣＣ―ＮＵＭＡ）やｃａｃｈ
ｅｏｎｌｙｍｅｍｏｒｙａｃｃｅｓｓ（ＣＯＭ
Ａ）と呼ばれる種類の計算機で用いられている技術を説
明する。ＣＣ―ＮＵＭＡ計算機やＣＯＭＡ計算機では、
メモリの断片（キャッシュライン）を多数のプロセッサ
の近くにキャッシュし、それらキャッシュの間の一貫性
を保つ機構が含まれている。特に以下の２つの方法が知
られている。

【００１５】第１の方法（公知例５）は、上記マネージ
ャに相当する「ホーム」と呼ばれる処理装置またはデー
タが、メモリの断片がどのプロセッサによってキャッシ
ュされているかを把握しておく方法である。Ｊｅｆｆｒ
ｅｙＫｕｓｋｉｎ他著の文献”ＴｈｅＳｔａｎｆｏ
ｒｄＦＬＡＳＨＭｕｌｔｉｐｒｏｃｅｓｓｏｒ”
（Ｐｒｏｃｅｅｄｉｎｇｓｏｆｔｈｅ２１ｓｔ
ＡｎｎｕａｌＩｎｔｅｒｎａｔｉｏｎａｌＳｙｍｐ
ｏｓｉｕｍｏｎＣｏｍｐｕｔｅｒＡｒｃｈｉｔｅ
ｃｔｕｒｅ，ｐｐ.３０２―３１４，ＡＣＭ，１９９
４）に記載のシステム等で第１の方法が用いられてい
る。

【００１６】第２の方法（公知例６）は、キャッシュの
作成と削除と通信方法に一定の制約を課すことによっ
て、一定回数の通信（通常マルチキャストまたはブロー
ドキャストを含む）でキャッシュの特定と一貫性の保持
ができることを保証する方法である。ＨｅｎｋＬ.Ｍ
ｕｌｌｅｒ他の文献”ＴｈｅＤａｔａＤｉｆｆｕｓ
ｉｏｎＭａｃｈｉｎｅｗｉｔｈａＳｃａｌａｂ
ｌｅＰｏｉｎｔ―ｔｏ―ＰｏｉｎｔＮｅｔｗｏｒ
ｋ”（ＴｅｃｈｎｉｃａｌＲｅｐｏｒｔＣＳＴＲ―
９３―１７，ＤｅｐａｒｔｍｅｎｔｏｆＣｏｍｐｕ
ｔｅｒＳｃｉｅｎｃｅ，Ｕｎｉｖｅｒｓｉｔｙｏｆ
Ｂｒｉｓｔｏｌ，Ｏｃｔｏｂｅｒ１９９３）に記載
のシステム等で第２の方法が用いられている。

【００１７】

【発明が解決しようとする課題】現在のインターネット
全体の通信性能はユーザの要求する速度に遠く及んでお
らず、多くの不安定要因を抱えている。ＷＷＷの爆発的
な普及により、多くのワイド・エリア・ネットワーク
（ＷＡＮ）で混雑が起こっている。高速なバックボーン
通信回線が日々増強されている一方で、家庭からのイン
ターネット利用者は、一般的なＬＡＮよりも非常に遅い
通信回線を用いてインターネットに接続している。現在
でもＷＷＷサーバとインターネットのユーザ数は増加の
一途をたどっており、１９９６年１月のある統計では、
全世界のインターネット利用のコンピュータは９００万
台、６ヶ月弱で２倍の速度で増加している。

【００１８】このため、インターネットの通信回線には
不均一性と不安定性がある。ここでの不均一性とは、様
々な通信回線が混在していることを指す。例えば、通信
回線によってスループット（単位時間当りの通信データ
量）とレイテンシ（通信が受ける遅延時間）が異なるこ
とがあげられる。ここでの不安定性とは、通信回線のス
ループットとレイテンシが刻一刻と変化し、場合によっ
ては通信不能になったりすることを指す。例えば、時間
帯や曜日によって通信回線の混雑が変化したり、ある通
信回線の増強によってルーティングのパターンが変更さ
れ、別の通信回線が混雑したり混雑が解消されたりする
ことを指す。

【００１９】このような状況を鑑み、ユーザにより快適
な情報システムのサービスを行なうために、ユーザがク
ライアントに要求を発してから、その要求が満たされる
まで時間を短縮することが本発明の目的である。以下こ
の目的を実現する上での課題と、公知の技術との隔たり
を説明する。

【００２０】第１に、公知の技術では、ある通信回線が
不安定な状況下では、たとえ別の通信回線が正常に動作
していてもクライアントの依頼を高速に処理できない場
合があった。

【００２１】公知例１のＷＷＷのクライアントやＷＷＷ
のプロキシ・サーバは、ＵＲＬによって指定された特定
のＷＷＷサーバまたは特定のプロキシ・サーバと通信す
る。このため、当該サーバ（またはプロキシ・サーバ）
への通信回線が混雑していたり、不通である場合には、
たとえ別の通信回線が正常に動作していても、クライア
ント（またはプロキシ・サーバ）がホームページの入手
に長時間を要したり、ホームページの入手ができない。
また同じ理由で、ある時点で低速だった通信回線が増強
等により高速になったとしても、その利益を享受するこ
とが困難だった。公知例２から公知例５でも、クライア
ントとサーバ、またはサーバと別のサーバの通信が、あ
らかじめ定められた相手とのみ行なわれる点は公知例１
と共通しており、上記の問題がある。一方公知例６は、
１つの計算機または物理的に密接に結び付いた複数の計
算機で使用する技術であり、マルチキャストまたはブロ
ードキャストが不具合なく動作することを前提としてい
る。このためＬＡＮ環境やＷＡＮ環境にひろく適用する
ことは困難である。また同じ理由で、特定の通信回線が
混雑していたり、不通である場合には（たとえ別の通信
回線が正常に動作していても）、キャッシュラインの入
手に長時間を要したり、キャッシュラインの入手ができ
ない。

【００２２】第２に、公知の技術では通信回線が不安定
な状況下でキャッシュの利用率をあげることが達成され
ていなかった。

【００２３】公知例１、２、３、５では、複数のサーバ
（またはクライアントとサーバ）がキャッシュを持つ場
合、これら複数のキャッシュは階層構造をなす。クライ
アントが発する依頼には、当該依頼を処理する責任を持
つ特定の第１のサーバが存在している。当該依頼は、当
該第１のサーバに直接送信されるか、当該第１のサーバ
とクライアントの間の１つ以上の第２のサーバの間を順
に転送される（この場合、当該１つ以上の第２のサーバ
は依頼の内容によって一意に決定される）。前者の場
合、当該依頼は当該第１のサーバのキャッシュしか利用
できない。また後者の場合には、当該１つ以上の第２の
サーバのキャッシュしか利用できない。すなわち第１、
第２のサーバの他のサーバのキャッシュは利用されず、
キャッシュの利用率が低い。例えば公知例１のＷＷＷの
プロキシ・サーバは親子関係を持つので、プロキシ・サ
ーバＡ、Ｂ、Ｃが存在してＡが親、ＢとＣがＡの子とし
て動作している場合、ＢはＡに依頼を転送することによ
ってＡのキャッシュを利用することができるが、ＢがＣ
のキャッシュを利用することはできない。また公知例２
では、各ニュース記事は、当該ニュース記事を必要とす
るすべてのサーバにコピーされる。このため、各サーバ
は他のサーバのキャッシュを全く利用せず、したがって
各サーバが大規模な二次記憶を用意する必要がある。一
方、公知例４はＬＡＮ環境を仮定しており、キャッシュ
の利用率をあげる目的で、１つのデータのコピーが複数
のキャッシュ中でできるだけ少数になるような制御が行
なう。しかし、通信回線が不安定な場合には、クライア
ントの依頼が少数のキャッシュに到達できない場合があ
り、逆にキャッシュの利用率が低くなる恐れがある。公
知例６は、複数のキャッシュのうち最も短時間で利用で
きるキャッシュを選択するが、この際にマルチキャスト
またはブロードキャストが用いられる。このため、公知
例６の方法を通信回線が不安定になる可能性があるＬＡ
Ｎ環境やＷＡＮ環境にひろく適用することは困難であ
る。

【００２４】第３に、公知の技術ではデータとデータの
間の参照関係の使用頻度を複数のサーバが交換する方法
を持たなかった。

【００２５】ＷＷＷのホームページとハイパー・テキス
ト・リンクに代表されるように、情報システムが提供す
るデータには参照関係があり、参照関係のなかでも頻繁
にたどられる参照関係（使用頻度の高い参照関係）があ
ることが多い。参照関係の使用頻度情報は、プリフェッ
チなどに利用できる。頻繁にたどられる参照関係で結ば
れた一連の情報をクライアントからの依頼以前にプリフ
ェッチしておけば、クライアントからの依頼があった時
に通信回線が不安定でも、当該一連の情報の依頼は高速
に処理することができるためである。特に複数のサーバ
が存在する場合、参照関係の使用頻度情報は、個々のサ
ーバがそれぞれ収集するより、複数のサーバが収集した
情報を交換して集計する方がより確からしい情報とな
る。しかし公知例１から６では、参照関係の使用頻度情
報を複数のサーバが交換する方法を持たなかった。この
ため、参照関係の使用頻度情報の確からしさに限界があ
り、プリフェッチの効果も限られていた。

【００２６】第４に、公知の技術ではキャッシュの入れ
替えに通信回線の不均一性と不安定性が考慮されていな
かったため、重要なキャッシュを破棄する恐れがあっ
た。

【００２７】公知例１、２、３では、各サーバ（または
クライアント）が、利用履歴等に基づいてそれぞれのキ
ャッシュの入れ替えを行なう。公知例４はＬＡＮ環境で
の使用を想定しているため、キャッシュの入れ替えの際
のキャッシュの優先度づけに、通信回線の状態は考慮さ
れない。また、公知例５と６も、１つの計算機または物
理的に密接に結び付いた複数の計算機で使用することを
想定しているため、キャッシュの入れ替えの際のキャッ
シュの優先度づけに、通信回線の状態は考慮されない。
この結果、公知例１から６のいずれでも、現在の通信状
態では再び入手することができない、または入手に長時
間を要するキャッシュを破棄する場合がある。

【００２８】第５に、公知の技術ではいずれも、第１の
サーバが１つ以上の第２のサーバからの依頼を受ける場
合に、第２のサーバが第１のサーバを無制限に利用し、
結果として第１のサーバを過負荷におとしいれることに
対する対策がなかった。このため、複数のサーバが複数
のユーザの組織を越えて依頼を行ないあうことが困難だ
った。公知例１、２、３は、クライアント・サーバ・シ
ステムであるため、サーバが依頼を拒否すると、クライ
アントの依頼が処理されない。一方、公知例４、５、６
は限られた範囲の複数のサーバが依頼を行ないあうた
め、第１のサーバの過負荷を問題にする必要がなかっ
た。

【００２９】

【課題を解決するための手段】本発明では、複数のサー
バを用い、複数のキャッシュを複数のサーバが保持する
ことによって、１つの情報システムのサービスを提供す
る。

【００３０】第１の課題を解決するため、以下の３つの
手段を講じる。

【００３１】（１）第１のサーバが必要とするデータ
（以後必要データと呼ぶ）を入手しようとする際、当該
必要データは本発明の方法で用いる複数のサーバのう
ち、２つ以上の第２のサーバにキャッシュされている可
能性がある。この際第１のサーバは、第１のサーバと第
２のサーバが過去に行なった通信履歴を保持し、当該通
信履歴を用いて第２のサーバから１つ以上の第３のサー
バを選択して、第３のサーバに必要データの送信を依頼
する。この通信履歴から第１のサーバは、現時点で高速
に必要データの入手が可能と予測される第３のサーバを
選択できる。このため、高速に通信できる通信回線を選
択的に用いてクライアントの依頼を処理可能となる。

【００３２】（２）第１のサーバは、必要データを入手
するための第３のサーバを２つ以上選択し、これら複数
のサーバに対して同時に依頼を送信することにより、ク
ライアントの依頼を高速に処理することを試みる。これ
だけでは当該複数のサーバからほぼ同時に依頼の返答が
開始されて、却って通信の速度を下げる恐れがある。そ
こで、当該２つ以上の第２のサーバのうち、１つ以上の
第３のサーバには必要データを直ちに送信することを依
頼し、別の１つ以上の第４のサーバには、必要データの
送信を待機することを依頼する。第３のサーバからの必
要データの送信が長時間を要するか、不可能であること
が判明した時点で、すでに待機している第４のサーバか
ら直ちに必要データの送信を受けられる。このため、通
信回線の状況が変化した場合にもクライアントの依頼を
高速に処理可能となる。

【００３３】（３）第１のサーバは、当該第１のサーバ
と１つ以上の他のサーバとの過去の通信に関する、第１
の時間にわたる、第２の時間間隔毎の通信の履歴（時間
毎通信履歴）を持つ。当該時間毎通信履歴は、通信回線
の状況が周期的に変化する場合（例えば昼間は混雑して
いるが夜間は混雑していない通信回線を用いる場合等）
に、第１のサーバが通信を行なう時刻の選択を可能にす
る。これら３つの手段によって本発明は、高速に通信で
きる通信回線を選択的に利用し、若しくは高速に通信で
きる時間帯に選択的に利用して、通信回線が不安定また
は不均一な状況下で、クライアントの依頼を高速に処理
する。

【００３４】第２の課題を解決するために、第１のサー
バは、当該第１のサーバが持つキャッシュの一覧の一部
または全部を、１つ以上の第２のサーバに通信する。こ
の際当該１つ以上の他のサーバは前記通信回線の状況の
履歴を用いて選択する。これにより、第１のサーバのキ
ャッシュの一覧を、その時点で高速に通信できる第２の
サーバに通信することができる。このため、第１のサー
バと第２のサーバの間の通信回線が正常な場合には、他
の通信回線が不安定でも、第２のサーバが第１のサーバ
のキャッシュを利用可能となる。

【００３５】第３の課題を解決するために、クライアン
トが第１のデータを依頼した後に、１つ以上の第２のデ
ータを依頼する可能性が高い場合に、第１のサーバは第
１のデータと第２のデータの対応関係（参照関係情報）
を持ち、かつ当該参照関係情報を１つ以上の第２のサー
バに送信する。この手段を用いて本発明の複数のサーバ
は、参照関係情報を他のサーバと交換し、頻繁にたどら
れる参照関係の使用頻度の確からしさを向上させる。こ
れにより頻繁に依頼される一連のデータをクライアント
に高速に提供する。

【００３６】また参照関係情報をプリフェッチに用いる
ことによって、多数のデータを同時に依頼することが可
能になる。この際本発明ではサーバが複数あることを利
用して、複数のサーバが階層的なパイプライン状にプリ
フェッチを行ない、特定のサーバにボトルネックを生じ
たり、特定のネットワークが過負荷になってプリフェッ
チが効果的に行なわれない等の問題を避ける。

【００３７】第４の課題を解決するために、第１のサー
バは前記通信回線の状況の履歴を用いて情報の単位のア
クセス頻度および最終アクセス時間、平均スループッ
ト、平均レイテンシ、他のサーバのキャッシュの内容か
ら、キャッシュの優先度づけを行ない、この優先度に基
づいてキャッシュの入れ替えを行なう。これにより、現
在の通信状態では再び入手ことができない、または入手
に長時間を要するキャッシュを破棄することを避けるこ
とが可能となる。

【００３８】第５の課題を解決するために、第１のサー
バが、１つ以上の第２のサーバの必要データの送信の全
体を一定時間内に一定量以下、または一定時間内に一定
回数以下に制限する手段を持ち、一方で第２のサーバの
各々は、第１のサーバを含む２つ以上の第３のサーバ
に、必要データの送信を依頼する。これにより、第１の
サーバが第２のサーバからの依頼によって過負荷になる
ことを防ぎつつ、第２のサーバの処理を妨げないことが
可能となる。本発明が複数のサーバからなっており、ひ
とつのサーバが依頼を拒否しても、他のサーバが依頼を
処理することが可能なため、この手段が有効となる。

【００３９】これらの手段によって、本発明は、インタ
ーネットの通信回線の不均一性と不安定性がある状況下
でも、ユーザがクライアントに要求を発してから、その
要求が満たされるまで時間を短縮する。また特定の通信
回線が不通でも、できる限りクライアントの依頼を処理
する。これによりユーザにより快適な情報システムのサ
ービスを行なう。

【００４０】

【発明の実施の形態】以下、本発明の実施の一形態を、
図面を参照しながら説明する。なお、簡単のため、本明
細書中では「発明の実施の形態」を、単に「実施例」と
呼ぶことにする。

【００４１】全体構成本実施例は、他の情報システムから入手する情報とユー
ザが入力する情報を、分散した１つ以上のキャッシュに
保持する分散データ管理方法を搭載した計算機システム
である。図２に本実施例の全体を示す。本実施例の全体
２０１は分散コンピュータ・システムであり、ネットワ
ーク２０２と、ネットワーク２０２によって相互接続さ
れた１つ以上の計算機２０３、２０３’、２０３’’、
…からなる。

【００４２】ネットワーク２０２は、ある団体（企業や
学校や類似の団体）の全体や位置部門でよく使用される
ＬＡＮでもよく、また地理的に分散した複数の地点を結
合するＷＡＮの一部または全部でもよい。またネットワ
ーク２０２は、計算機間結合網や並列計算機内部のプロ
セッサ要素間の結合網でもよい。

【００４３】計算機２０３、２０３’、２０３’’、…
は、それぞれ１個以上のクライアントまたは１個以上の
サーバまたはその両方を動作させる。本実施例の全体２
０１で、少なくとも１つのサーバ２０５と少なくとも１
つのクライアント２０４が存在する。なお以下で、本実
施例の全体に含まれるサーバ群を「本システム」と呼ぶ
ことがある。計算機２０３、２０３’、２０３’’、…
は、いわゆるパーソナル・コンピュータ、ワークステー
ション、並列計算機、大型計算機等、任意のコンピュー
タでよい。また、クライアント２０４、２０４’、２０
４’’、…を動作させる計算機２０３、２０３’、２０
３’’、…は、サーバ２０５、２０５’、２０５’’、
…と通信する機能をもっていればよい。すなわち各種コ
ンピュータ端末装置、携帯通信端末（いわゆるパーソナ
ル・デジタル・アシスタンスＰＤＡやハンドヘルド・パ
ーソナル・コンピュータＨＰＣ）、ネットワーク・コン
ピュータなどでも差し支えない。なお、図２に示した計
算機２０３、２０３’、２０３’’、…、クライアント
２０４、２０４’、２０４’’、…、およびサーバ２０
５、２０５’、２０５’’、…の数と構成は、例として
示したもので、本発明の範囲を限定するものではない。

【００４４】クライアント２０４は、ＷＷＷで使われる
各種プロトコル、すなわちＨＴＴＰ（Ｈｙｐｅｒｔｅｘ
ｔＴｒａｎｓｆｅｒＰｒｏｔｏｃｏｌの略）プロト
コル、ＦＴＰ（ＦｉｌｅＴｒａｎｓｆｅｒＰｒｏｔ
ｏｃｏｌの略）プロトコル等を用いてサーバ２０５と通
信を行なう。クライアント２０４は、グラフィック・ユ
ーザ・インターフェースを備えたＷＷＷブラウザ、テキ
スト表示のみを行なうＷＷＷブラウザ、ワード・プロセ
ッサや表計算ソフトウェアに内蔵されたＷＷＷのクライ
アント、ＷＷＷのプロキシ・サーバ等でよい。なお、ク
ライアント２０４が用いるプロトコル、およびクライア
ント２０４の種類は例として示したもので、本発明の範
囲を限定するものではない。

【００４５】サーバ２０５、２０５’、２０５’’、…
は、ＷＷＷサーバ、ＷＷＷプロキシ・サーバ、匿名ＦＴ
Ｐサーバ、ユーザの入力等の「情報源」から、クライア
ントに提供する情報を入手して、ＵＲＬと組にして保持
する。サーバ２０５、２０５’、２０５’’、…は上記
情報の入手を、上記情報源のそれぞれに定期的に（例え
ば１時間に一度）接続して新規情報を得る、上記情報源
から新規情報の発生を通知して貰う、等の方法で行な
う。なお、サーバ２０５、２０５’、２０５’’、…が
クライアントに提供する情報を入手する情報源および方
法は、例として示したもので、本発明の範囲を限定する
ものではない。また、本実施例のサーバ２０５、２０
５’、２０５’’、…が持つ情報にはＵＲＬが付与され
ており、かつサーバはＵＲＬを用いてＵＲＬ内容の管理
を行なうが、サーバが持つ情報を何らかの形式で指定す
ることができればよく、ＵＲＬに限ることはない。この
ため、本発明の範囲を限定するものではない。さらに本
発明の実施は、クライアントまたはサーバのオペレーテ
ィング・システム、サーバ間またはサーバ・クライアン
ト間のネットワークの種類およびネットワークの物理層
プロトコルやトランスポート層プロトコル、もしくはサ
ーバとクライアントが単一のコンピュータ上にあるか異
なるコンピュータ上にあるかには依存しない。

【００４６】クライアントとサーバの動作の概略図１を用いてクライアント２０４とサーバ２０５の動作
の概略を説明する。なお、サーバ２０５とクライアント
２０４、他のサーバ２０５’、２０５’’、…を繋いで
いるネットワーク２０２はここには図示していない。ま
た、図１中の矢印は主要なデータの流れである。

【００４７】サーバ２０５は依頼処理部１０１、プリフ
ェッチ部１０２、サーバ間メッセージ処理部１０３の各
処理部分と、ホームページキャッシュ１０４、アクセス
戦略表１０５、頻度ＤＢ１０６、ホームページグループ
表１０７の各データ構造を持つ。

【００４８】サーバ２０５のホームページキャッシュ１
０４は、サーバ２０５が動作する計算機２０３の持つ不
揮発性記憶装置（磁気ハードディスク、光ディスク等。
以下「二次記憶」と記すことがある）または揮発性記憶
装置（メインメモリ、キャッシュメモリ等。以下「主記
憶」と記すことがある）またはその両方に格納される。
なお、ホームページキャッシュ１０４は不揮発性記憶装
置に格納される場合でも揮発性記憶装置に格納される場
合でも、一個所に格納される必要はない。例えば、サー
バ２０５が動作する計算機２０３が３つの磁気ハードデ
ィスクを持っていれば、ホームページキャッシュ１０４
をこれら３つの磁気ハードディスクの一部または全部に
分割して格納しても差し支えない。むしろ、複数の磁気
ハードディスクを用いることは、磁気ハードディスクへ
のアクセスの並列性を増し、もってホームページキャッ
シュ１０４の読み書きを高速化するために、必須ではな
いが望ましい。また当該サーバ２０５は情報のキャッシ
ュをすることが重要な役割であるため、当該サーバ２０
５には大容量のホームページキャッシュ１０４を構成す
るのに十分な記憶装置が付属していることが、必須では
ないが望ましい。

【００４９】クライアント２０４が、本システムから第
１のＵＲＬに対応する情報である第１のＵＲＬ内容を取
得する際には、本システムの任意の第１のサーバ２０５
に、第１のＵＲＬを含む依頼１２０を送信することによ
って、第１のＵＲＬ内容の取得を依頼する。

【００５０】依頼１２０は依頼処理部１０１が受け取
り、ホームページキャッシュ１０４に依頼されたＵＲＬ
内容があるかどうかを検索する（１３０）。もしあれ
ば、当該ホームページキャッシュ１０４をアクセスし
て、第１のＵＲＬ内容をクライアント２０４に返答１２
１で送信する。

【００５１】アクセス戦略表１０５は、本システムの他
のサーバ２０５’、２０５’’、…がどのＵＲＬ内容を
保持しているかの記録、及び第１のサーバ２０５から行
なった過去の通信の速度（例えばスループットやレイテ
ンシ）の記録を保持している。第１のＵＲＬ内容が第１
のサーバ２０５のホームページキャッシュ１０４内にな
ければ、第１のサーバ２０５はアクセス戦略表１０５を
参照して依頼を転送すべき第２のサーバ２０５’、２０
５’’、…を決定する（１３１）。そして第２のサーバ
２０５’、２０５’’、…および第１のＵＲＬ内容の情
報源のうち１つ以上に、依頼１２２により依頼１２０を
転送する。第１のサーバ２０５は、依頼を転送した第２
のサーバ２０５’、２０５’’、…または情報源の少な
くとも１つから第１のＵＲＬ内容が返答１２３によって
得られると、得られた第１のＵＲＬ内容をクライアント
２０４に返答１２１によって送る。なお、上記依頼１２
０、返答１２１、依頼１２２、返答１２３はいずれも、
ネットワーク２０２を通じて行なわれてもかまわない
し、計算機２０３、２０３’、２０３’’、…の持つ通
信機能を用いて行なわれてもかまわない。

【００５２】第１のサーバ２０５は返答１２３によって
第１のＵＲＬ内容が得られると、第１のサーバ２０５の
ホームページキャッシュ１０４に第１のＵＲＬ内容を追
加する（１３３）。この場合には、当該第１のＵＲＬ内
容が追加されたことを伝えるホストＵＲＬメッセージ１
２４が本システムの他のサーバ２０５’、２０５’’、
…の一部または全部に送信される。またホームページキ
ャッシュ１０４に第１のＵＲＬ内容を追加する際、別の
第２のＵＲＬ内容がホームページキャッシュ１０４から
削除される場合があるが、この場合には、当該第２のＵ
ＲＬ内容が削除されたことを伝えるホストＵＲＬメッセ
ージ１２４が本システムの他のサーバ２０５’、２０
５’’、…の一部または全部に送信される。

【００５３】頻度ＤＢ１０６は、後に述べるように、ど
のＵＲＬ内容がいつ参照されたかという頻度情報を記録
している。ホームページグループ表１０７は、連続して
依頼されたことが多かった複数のＵＲＬ内容の組を記録
している。第１のサーバ２０５のプリフェッチ部１０２
は返答１２１の後、依頼１２０による頻度情報の変化を
頻度ＤＢ１０６に反映する（１３５）。頻度情報の変化
は、頻度ＤＢ１０６の更新内容を伝えるホスト頻度メッ
セージ１２５によって本システムの他のサーバ２０
５’、２０５’’、…の一部または全部に送信される。
さらに、プリフェッチ部１０２は頻度ＤＢ１０６の内容
に基づいてホームページグループ表１０７を更新する
（１３６）。

【００５４】次に、将来依頼されやすいと考えられるＵ
ＲＬ内容を頻度ＤＢ１０６およびホームページグループ
表１０７を用いて決定する（１３７および１３８）。当
該ＵＲＬ内容が１個以上あれば、それらは依頼処理部１
０１が上記依頼１２０と同様に受信する。

【００５５】また、サーバ間メッセージ処理部１０３
は、本システムの他のサーバ２０５’、２０５’’、…
からホストＵＲＬメッセージ１２４’を受信するとアク
セス戦略表１０５を書き換える（１４０）。また、本シ
ステムの他のサーバ２０５’、２０５’’、…からホス
ト頻度メッセージ１２５’を受信すると頻度ＤＢ１０６
を書き換える（１４１）。

【００５６】以上がクライアント２０４とサーバ２０５
の動作の概略である。以下ではこれらをさらに詳しく説
明する。

【００５７】サーバの内部動作の詳細図３に、サーバ２０５の内部構成を示す。依頼処理部１
０１は、依頼入力部３０１、キャッシュ表参照部３０
２、処理戦略部３０３、受信部３０４、返答部３０５、
キャッシュ入れ替え部３１０からなる。プリフェッチ部
１０２は、リンク統計更新部３０６、グループ更新部３
０７、プリフェッチ戦略部３０８、プリフェッチスケジ
ュール部３０９、タイマー３１１からなる（サーバ間メ
ッセージ処理部１０３は図３には示していない）。

【００５８】サーバ２０５のデータ構造は、ホームペー
ジキャッシュ１０４、アクセス戦略表１０５、頻度ＤＢ
１０６（アクセス頻度表３２５、リンク頻度表３２６、
外部アクセス頻度表３２７、外部リンク頻度表３２８か
らなる）、ホームページグループ表１０７、およびアク
セス戦略表１０５を構成するためのキャッシュディレク
トリ３２３と通信コスト表３２４、およびホスト表の各
データ構造を持つ（ホスト表は図示していない）。これ
らのデータ構造はすべて、主記憶と二次記憶の片方また
は両方に存在してかまわない。なお、図３において、太
い矢印は主要な制御の流れを、また細い矢印は主要なデ
ータの流れを表わす。また、本実施例では請求項におけ
る必要データはＵＲＬ内容であり、請求項における通信
履歴は、アクセス戦略表１０５と通信コスト表３２４
に、データ保持確率はキャッシュディレクトリ３２３
に、時間毎通信履歴は頻度ＤＢ１０６に、参照関係情報
はホームページグループ表１０７に、それぞれ格納され
る。また、サーバ間で通信されるデータの一覧はホスト
ＵＲＬメッセージ１２４の形式で通信される。

【００５９】サーバ２０５内部の処理の説明に先立っ
て、各データ構造の概略を説明する。各データ構造の詳
細な説明は、サーバ２０５内部の処理の説明とあわせて
行なう。図４に、ホームページキャッシュ１０４、アク
セス戦略表１０５、キャッシュディレクトリ３２３、通
信コスト表３２４、アクセス頻度表３２５、リンク頻度
表３２６、外部アクセス頻度表３２７、外部リンク頻度
表３２８の構成を示す。

【００６０】ホームページキャッシュ１０４は、キャッ
シュの本体である。ＵＲＬ４０１と、ＵＲＬ４０１の内
容であるＵＲＬ内容４０２を組にして保持する。この組
は通常複数ある。

【００６１】アクセス戦略表１０５は、下に述べるキャ
ッシュディレクトリ３２３と通信コスト表３２４とを、
現在の使用のために組み合わせたものである。ＵＲＬ４
１１と、ホスト４１２と、通信コスト４１３と、ＵＲＬ
存在確率４１４との組を保持する。この組は通常複数あ
る。ＵＲＬ４１１はＵＲＬである。ホスト４１２はサー
バ２０５または情報源が存在するホスト名、通信コスト
４１３には、通信のスループットとレイテンシを用い
る。ＵＲＬ存在確率４１４は、ホスト４１２で指定され
るコンピュータに、ＵＲＬ４１１で指定されるホームペ
ージが存在する確率である。サイズ４１５は前回アクセ
ス時のＵＲＬ４１１のバイト数である。アクセス戦略表
１０５は、第１のサーバ２０５が、依頼を転送する１つ
以上の第２のサーバ２０５’、２０５’’、…を選定す
る際に使用する。

【００６２】なお、ホスト名には、シンボリックなホス
ト名かＩＰアドレスを用いる。場合によってはホスト名
に、シンボリックなホスト名かＩＰアドレスと、ＴＣＰ
／ＩＰやＵＤＰ／ＩＰのポート番号とを組にしたものを
用いる。ただしホスト名は通信相手のサーバまたはクラ
イアントを指定し、通信路を開くことが目的であるた
め、この目的にかなえば、いかなる形態の表現をとって
も差し支えない。特に、ここでＩＰアドレスやポート番
号は例として出したものであり、本発明の範囲を限定す
るものではない。

【００６３】キャッシュディレクトリ３２３は、ＵＲＬ
４２１と、ホスト４２２と、ＵＲＬ存在確率４２３を含
む組を保持する。この組は通常複数ある。ＵＲＬ４２１
はＵＲＬである。ホスト４２２はサーバまたは情報源が
存在するホスト名、ＵＲＬ存在確率４２３は、ホスト４
２２で指定されるコンピュータに、ＵＲＬ４２１で指定
されるホームページが存在する確率である。

【００６４】通信コスト表３２４は、ホスト４３１と、
時刻４３２と、通信コスト４３３と、通信回数４３４を
含む組を保持する。この組は通常複数ある。ホスト４３
１はサーバまたは情報源が存在するホスト名、時刻４３
２は何曜日の何時かを格納する。通信コスト４３３は時
刻４３２においてホスト４３１に対して行なわれた過去
一定期間内の通信のスループット（単位時間当りの通信
可能データ量）とレイテンシ（通信が受ける遅延時間）
である。通信回数４３４は、時刻４３２においてホスト
４３１に対して行なわれた過去一定期間内の通信の回数
を格納する。

【００６５】アクセス頻度表３２５は、ＵＲＬ４４１
と、アクセス頻度４４２と、サイズ４４３を含む組を保
持する。この組は通常複数ある。ＵＲＬ４４１はＵＲ
Ｌ、アクセス頻度４４２はＵＲＬ４４１で指定されるホ
ームページを、過去の一定時間Ｃ１内に当該サーバ２０
５がアクセスした回数である。本実施例のアクセス頻度
４４２は、過去一週間の何曜日の何時に何回アクセスし
たかを格納するカウンタ群である。サイズ４４３は前回
アクセス時のＵＲＬ４４１のバイト数である。

【００６６】リンク頻度表３２６は、参照元ＵＲＬ４５
１と、参照先ＵＲＬ４５２と、アクセス頻度４５３を含
む組を保持する。この組は通常複数ある。アクセス頻度
４５３は参照元ＵＲＬ４５１から参照先ＵＲＬ４５２へ
のリンクを、過去の一定時間Ｃ２内に当該サーバ２０５
がアクセスした回数である。本実施例のアクセス頻度４
５３は、過去一週間の何曜日の何時に何回アクセスした
かを格納するカウンタ群である。

【００６７】外部アクセス頻度表３２７は、ＵＲＬ４６
１と、アクセス頻度４６２を含む組を保持する。この組
は通常複数ある。ＵＲＬ４６１はＵＲＬ、アクセス頻度
４６２はＵＲＬ４６１で指定されるホームページを、過
去の一定時間Ｃ１内に本システムの他のサーバ２０
５’、２０５’’、…がアクセスした回数である。本実
施例のアクセス頻度４６２は、過去一週間の何曜日の何
時に何回アクセスしたかを格納するカウンタ群である。

【００６８】外部リンク頻度表３２８は、参照元ＵＲＬ
４７１と、参照先ＵＲＬ４７２と、アクセス頻度４７３
を含む組を保持する。この組は通常複数ある。アクセス
頻度４７３は参照元ＵＲＬ４７１から参照先ＵＲＬ４７
２へのリンクを、過去の一定時間Ｃ２内に他のサーバ２
０５’、２０５’’、…がアクセスした回数である。本
実施例のアクセス頻度４７３は、過去一週間の何曜日の
何時に何回アクセスしたかを格納するカウンタ群であ
る。

【００６９】ホスト表は、ホスト名の組を保持する。ホ
スト表に現れるホスト名は、本システムに参加している
計算機２０３、２０３’、２０３’’、…上のサーバ２
０５、２０５’、２０５’’、…の全体である。

【００７０】またサーバ２０５は、プリフェッチフラ
グ、新規ＵＲＬフラグ、前回アクセスＵＲＬの変数を用
いる。プリフェッチフラグは、真偽値の変数であり、現
在サーバ２０５がプリフェッチ中か、クライアント２０
４（または他のサーバ２０５’、２０５’’、…）の依
頼を処理中かを表わす。初期値は偽である。新規ＵＲＬ
フラグは、受信したＵＲＬ内容が新規にホームページキ
ャッシュ１０４に付け加わったかどうかを示す真偽値の
変数である。初期値は偽である。前回アクセスＵＲＬ
は、前回クライアントからの依頼に対して返答したＵＲ
Ｌである。初期値は「空」である。

【００７１】図５に、ホームページグループ表１０７、
ホストＵＲＬメッセージ１２４、ホスト頻度メッセージ
１２５の構成を示す。

【００７２】ホームページグループ表１０７は、先頭Ｕ
ＲＬ４８１とＵＲＬグループ４８２を含む組を保持す
る。この組は通常複数ある。各々の組は、連続してアク
セスされることが多いＵＲＬの集合である。先頭ＵＲＬ
４８１は１つのＵＲＬ、ＵＲＬグループ４８２は１つ以
上のＵＲＬ４８３、ＵＲＬ４８３’、ＵＲＬ４８
３’’、…である。

【００７３】ホストＵＲＬメッセージ１２４は、ホスト
５０１、ＵＲＬ５０２、フラグ５０３を含む組を内蔵し
たデータである。１つのホストＵＲＬメッセージ１２４
にこの組が２つ以上内蔵されて構わない。ホスト５０１
はホスト名、ＵＲＬ５０２は１つのＵＲＬ、フラグ５０
３は真偽値である。ホストＵＲＬメッセージ１２４は、
ホスト５０１で指定されるサーバがＵＲＬ５０２で指定
されるＵＲＬを持っていること（フラグ５０３が真の場
合）、または持っていないこと（フラグ５０３が偽の場
合）を他のサーバに伝達する目的で用いられる。

【００７４】ホスト頻度メッセージ１２５は、ホスト５
１１、参照元ＵＲＬ５１２、参照先ＵＲＬ５１３、頻度
５１４を含む組を内蔵したデータである。ホスト５１１
はホスト名、参照元ＵＲＬ５１２は１つのＵＲＬ、参照
先ＵＲＬ５１３は１つのＵＲＬまたは「空」、頻度５１
４はカウンタである。ホスト頻度メッセージ１２５は、
参照元ＵＲＬ５１２で指定されるＵＲＬまたは参照元Ｕ
ＲＬ５１２と参照先ＵＲＬ５１３の間のリンクを、過去
の一定時間内にホスト５１１で指定されるサーバ２０５
がアクセスした回数である頻度５１４を、他のサーバ２
０５’、２０５’’、…に伝える目的で用いられる。な
お、上記Ｃ１、Ｃ２の値はいずれも、サーバ２０５のコ
ンパイル時または起動時または起動中に変更可能であっ
て差し支えない。また、アクセス頻度４４２、アクセス
頻度４５３、アクセス頻度４６２、アクセス頻度４７
３、頻度５１４を過去一週間の何曜日の何時に何回アク
セスしたかを格納するとしたのは、一例として示したも
のに過ぎず、本発明の範囲を限定するものではない。ま
た、アクセス頻度表３２５、リンク頻度表３２６、外部
アクセス頻度表３２７、外部リンク頻度表３２８の目的
は、どのＵＲＬやどのリンクがどのくらいアクセスされ
たかを記録して利用することにあるので、この目的にか
なえば、他の情報を記録することも考えられる。例え
ば、アクセス頻度４４２、アクセス頻度４５３、アクセ
ス頻度４６２、アクセス頻度４７３、頻度５１４と併用
して、または代りとして、最終アクセス時刻を記録して
おき、ＬＲＵ（ｌｅａｓｔｒｅｃｅｎｔｌｙｕｓｅ
ｄ）法によってどのＵＲＬやどのリンクがどのくらいア
クセスされたかを見積もることも考えられる。

【００７５】以下、図１、図３、図６、および図７を用
いて、第１のサーバ２０５がクライアント２０４または
他のサーバ２０５’、２０５’’、…からＵＲＬ内容の
取得を依頼された際の、第１のサーバ２０５の処理の流
れを説明する。第１のサーバ２０５は依頼入力部３０１
でクライアント２０４または他のサーバの依頼を待ち、
受け付ける（６０１、３５０）。当該クライアント２０
４または他のサーバの依頼の中で、取得すべきＵＲＬ内
容はＵＲＬで表現される。なおクライアント２０４また
は他のサーバからの依頼に含まれていたＵＲＬを以後
「処理対象ＵＲＬ」と呼ぶ。第１のサーバ２０５におい
て、処理対象ＵＲＬはキャッシュ表参照部３０２に渡さ
れる（３５１）。この際、プリフェッチフラグには
「偽」を格納する。

【００７６】キャッシュ表参照部３０２は、ホームペー
ジキャッシュ１０４内で処理対象ＵＲＬに等しいＵＲＬ
４０１を持つ組を検索する（６０２、３８０）。もしそ
のような組が存在すれば（６０３）、返答部３０５に制
御を移す（３６３）。一方そのような組が存在しなけれ
ば（６０４）、処理戦略部３０３に処理を移す（３５
２）。

【００７７】処理戦略部３０３は、アクセス戦略表１０
５を用いて（３８１）、依頼を転送すべき１つ以上の第
２のサーバ２０５’、２０５’’、…または情報源を選
定する。まず、アクセス戦略表１０５内で処理対象ＵＲ
Ｌに等しいＵＲＬ４１１を持つ組を検索し（６０５）、
そのような組が１つ以上存在するかどうかを調べる（６
０６）。存在する場合（６０７）、後述の手順でこれら
１つ以上の組の順位づけおよび選択を行ない（６０
８）、当該順位づけおよび選択の結果選ばれた１つまた
は複数の組のそれぞれに対して、算出した優先度の高い
順にホスト４１２で指定されるサーバや情報源に依頼を
転送する（６１０、３６５）。一方そのような組が１つ
も存在しない場合（６０９）、処理対象ＵＲＬの情報源
に依頼を転送する（６１０、３６５）。なお、上記どち
らの場合でも、依頼を転送したら受信部３０４に処理を
移す（３５３）。依頼を転送したサーバ２０５’、２０
５’’、…や情報源を、以後「依頼転送先」と呼ぶ。

【００７８】順位づけおよび選択には、さまざまなアル
ゴリズムを使用しうるが、ネットワーク通信の効率面か
らの主要な指標はレイテンシとスループットと通信サイ
ズである。また、依頼を転送した先に処理対象ＵＲＬに
対応する情報が存在する確率も重要となる。本実施例で
は具体的には以下に示す順位づけと選択を行なう。な
お、下で用いるＤ１、Ｄ２、Ｄ３、Ｄ４、Ｄ５、Ｄ６は
いずれも定数であるが、これらの値はいずれもサーバ２
０５のコンパイル時または起動時または起動中に変更可
能であって差し支えない。また、ここで述べる順位づけ
を、サーバ２０５が保持する他の情報と合わせてもちい
ても何ら差し支えない。例えば、他の情報として、シス
テム管理者がサーバ２０５に提供する情報、ＩＰアドレ
スの類似性、ルーティングのトポロジーやホップ数、通
信回線の物理構成などを使うことが考えられる。

【００７９】順序づけと選択の手順は以下の通りであ
る。上記アクセス戦略表１０５内で処理対象ＵＲＬに等
しいＵＲＬ４１１を持つ組から、通信コスト４１３に含
まれるスループットが定数Ｄ１以下であるものを除外す
る。通信コスト４１３に含まれるレイテンシが定数Ｄ２
以上であるものを除外する。ＵＲＬ存在確率４１４が定
数Ｄ３以下であるものを除外する。各組の優先度（大き
い方が高い）をレイテンシとスループットと通信サイズ
とＵＲＬの存在確率から、（ＵＲＬ存在確率４１４／
（通信コスト４１３のレイテンシ＋サイズ４１５／通信
コスト４１３のスループット））の式を用いて算出し、
上位Ｄ４の組を選択する。次に、処理対象ＵＲＬに含ま
れる情報源のコンピュータがこの時点で選択に含まれて
いなければ、当該情報源を最も優先度が低くして選択に
加える。以上が本実施例における順位づけおよび選択の
手順である。

【００８０】なお、上記で複数のホスト４１２にほぼ同
時に依頼を転送すると、複数の依頼転送先からほぼ同時
に返答が送られて、第１のサーバ２０５付近のネットワ
ークが混雑する恐れがある。一方、複数のホスト４１２
に順々に依頼を転送し、その都度返答を待っていると、
結果的に取得すべきＵＲＬ内容の取得が遅くなる恐れが
ある。これらの問題を軽減するために、以下の通信プロ
トコルを用いることができる。図８を用いて説明する。
この図では、サーバ２０５と依頼転送先との間の通信の
様子を時間に沿って上から下に描いており、図の（ａ）
と（ｂ）は、２つの異なる場面を示している。

【００８１】図８の（ａ）で示すように依頼を転送する
際に、上記優先度の上位Ｄ５個の依頼転送先（以後優先
依頼転送先（８０１、８０１’、…）と呼ぶ）には、依
頼を変更なしで転送する（８０３）。この依頼をうけた
当該優先依頼転送先のそれぞれは、処理対象ＵＲＬに対
応するＵＲＬ内容を保持していればすぐ第１のサーバ２
０５への返答を開始する（８０４）。依頼を変更なしで
転送することは、処理対象ＵＲＬがあればすぐに返答を
開始せよ、という要求を意味する。

【００８２】上記優先依頼転送先はそれぞれ、処理対象
ＵＲＬに対応するＵＲＬ内容があれば当該ＵＲＬ内容を
当該第１のサーバ２０５に返答し、なければ「処理対象
ＵＲＬは存在しない」という返答を返す（８０５）。

【００８３】一方第１のサーバ２０５は、上記優先依頼
転送先以外の依頼転送先（以後非優先依頼転送先（８０
２、８０２’、…）と呼ぶ）には、処理対象ＵＲＬの
「返答待機依頼」（８０６）を送付する。返答待機依頼
は、処理対象ＵＲＬが存在して、かつ後述する返答開始
依頼が到着したら、返答を開始せよ、という意味をも
つ。この際、非優先依頼転送先は、処理対象ＵＲＬに対
応するＵＲＬ内容があれば待機し、なければ「処理対象
ＵＲＬは存在しない」という返答を返す。

【００８４】第１のサーバ２０５は図８の（ｂ）で示す
ように、上記優先依頼転送先のすべてから「処理対象Ｕ
ＲＬは存在しない」（８０５’）という返答が返ってき
た場合（８０７）に、まだ「処理対象ＵＲＬは存在しな
い」という返答をしていない非優先依頼先の１つ以上に
対して、「返答開始依頼」（８０８）を送る。当該依頼
が非優先依頼先に届き、かつ当該非優先依頼先に処理対
象ＵＲＬに対応するＵＲＬ内容があれば、当該非優先依
頼先は当該第１のサーバ２０５に対して当該ＵＲＬ内容
の返答を開始する（８０９）。なお、待機中の非優先依
頼転送先のおのおのは、返答待機依頼から一定時間Ｄ６
以内に返答開始依頼が到着しなければ、待機を中止して
次の依頼に備える。

【００８５】このプロトコルは、処理対象ＵＲＬに対応
するＵＲＬ内容が優先依頼転送先の１つ以上に存在した
場合に上記第１のサーバ２０５付近のネットワークの混
雑を緩和する。なぜなら、依頼転送先を２つの集団に分
けたことによって、同時に起こる返答の最大数を減らし
ているためである。また、処理対象ＵＲＬに対応するＵ
ＲＬ内容が優先依頼転送先のどれにも存在しなかった場
合にも、処理対象ＵＲＬに対応するＵＲＬ内容の取得が
遅くなるのを防ぐ。なぜなら、第１のサーバ２０５は返
答待機依頼に対する非優先依頼転送先からの返答を待た
ずに、返答開始依頼を流すことが可能であるからであ
る。

【００８６】なお、上述の本実施例における順位づけと
選択の手順によれば、優先依頼転送先または非優先依頼
転送先のいずれかに、処理対象ＵＲＬの情報源が含まれ
ているので、依頼転送先のどこからも処理対象ＵＲＬに
対応するＵＲＬ内容が転送されない場合は非常に稀であ
ることに注意されたい。万一、処理対象ＵＲＬに対応す
るＵＲＬ内容が転送されなかった場合には、本実施例で
は処理対象ＵＲＬに対応するＵＲＬ内容の受信を断念す
る。なお本実施例の変形例として、この場合にさらに別
の依頼転送先を選択して依頼を転送することが考えられ
る。また、別の変形例として、この場合に処理対象ＵＲ
Ｌに対応するＵＲＬ内容の受信を一定時間経過後に再度
試みる方法が考えられる。

【００８７】また本実施例におけるサーバ２０５は、当
該サーバ２０５の設置者が利便性を享受させようとする
クライアント２０４、２０４’、２０４’’、…以外
に、他のサーバへの通信を行なう。他のサーバとの通信
は、サーバ２０５のキャッシュの能力を発揮するために
必要不可欠であるが、この通信によって元来の目的とし
たクライアント２０４、２０４’、２０４’’、…への
サービスが低下する恐れをはらんでいる。この問題を解
決するためにサーバ２０５は、他のサーバからの依頼を
一定時間内に一定量に抑える。本実施例のサーバ２０５
は過去時間Ｔ１以内にＬ１バイト以上のＵＲＬ内容の転
送が、他のサーバに行なわれた場合、以後当該Ｔ１内に
は他のサーバからの依頼を受け付けない。また、本発明
の別の実施例としては、サーバ２０５が過去時間Ｔ１以
内にＬ２回数以上のＵＲＬ内容の転送が、他のサーバに
行なわれた場合、以後当該Ｔ１内には他のサーバからの
依頼を受け付けない。なおここで、Ｔ１、Ｌ１、Ｌ２は
コンパイル時または起動時または起動中に変更可能であ
って差し支えない。

【００８８】受信部３０４では、処理対象ＵＲＬに対応
するＵＲＬ内容が、１つ以上の依頼転送先から返答され
てくるのを待ち、当該ＵＲＬ内容の受信を行ない（３６
６）、通信コスト表３２４の更新を行なう。

【００８９】処理対象ＵＲＬに対応する返答があるか、
一定時間Ｔ２が経過するのを待つ。（６１１）。ここで
返答があったかを調べ（６１２）、返答があった場合に
は（６１３）、返答に含まれるＵＲＬ内容は、ホームペ
ージキャッシュ１０４内の新規な組として格納される
（６１４、３８２）。この際、処理対象ＵＲＬが当該新
規な組のＵＲＬ４０１となり、当該受信されたＵＲＬ内
容がＵＲＬ内容４０２となる。なお、処理対象ＵＲＬに
対応するＵＲＬ内容の受信後（受信中でもかまわない）
にホームページキャッシュ１０４の総量が定数Ｃ３を越
えたかを調べる（６１５）。越えていた場合に限り後述
するキャッシュ入れ替え部３１０に制御が移り、キャッ
シュ入れ替えの処理が行なわれる（６１６と６１７、図
３の３５５と３５６）。そして下に述べるように通信コ
スト表３２４の更新を行ない（６１８）、返答部３０５
に制御を移す（３５４）。一方、処理対象ＵＲＬに対応
するＵＲＬ内容が受信されなかった場合（６１９）、す
なわち、依頼転送先のすべてから「処理対象ＵＲＬは存
在しない」という返答を得た場合には、ホームページキ
ャッシュ１０４には何も操作を行なわなず返答部３０５
に制御を移す（３５４）。なおここで、Ｔ２、Ｃ３はサ
ーバ２０５のコンパイル時または起動時または起動中に
変更可能であって差し支えない。

【００９０】通信コスト表３２４の更新は、図９の手順
で行なう。処理対象ＵＲＬに対応するＵＲＬ内容が、第
１の依頼転送先から受信され始めた（９１０）時点で、
通信コスト表３２４の第１の依頼転送先に対応する組を
更新する。これは以下の手順で行なう。

【００９１】（１）ホスト４３１が第１の依頼転送先に
等しく、かつ時刻４３２が現在の時刻にあう組を検索す
る（９１１）。そして、通信コスト４３３のレイテンシ
を再計算するとともに、通信回数４３４を１増加する
（９１２）。すなわち、９１１で該当する組が見つから
なかった場合には、通信コスト表３２４に新たな組を作
り、ホスト４３１を第１の依頼転送先で、時刻４３２を
現在の時刻で、通信回数４３４を１で初期化する。そし
て、通信コスト４３３のレイテンシを今回のレイテンシ
（すなわち当該第１の依頼転送先が優先依頼転送先なら
ば依頼を転送してから現在までの時間、また非優先依頼
転送先ならば、転送開始依頼を送信してから現在までの
時間）で初期化する。また９１１で該当する組が見つか
った場合には、当該組の通信コスト４３３のレイテンシ
を、今回のレイテンシと、通信コスト４３３および通信
回数４３４の値を用いて再計算するとともに、通信回数
４３４に１を加える。

【００９２】（２）次に、当該第１の依頼転送先からの
受信の終了時刻ＥＮＤＴＩＭＥを予測して計算する（９
１３）。これは以下の方法で行なう。アクセス戦略表１
０５内で処理対象ＵＲＬに等しいＵＲＬ４１１を持ち、
かつホスト４１２が当該第１の依頼転送先に等しい組を
検索する。そのような組の通信コスト４１３とサイズ４
１５とを用いて、ＥＮＤＴＩＭＥを（現在の時刻＋（サ
イズ４１５／通信コスト４１３のスループット））とす
る。

【００９３】（３）次に、処理対象ＵＲＬに対応するＵ
ＲＬ内容が第２の依頼転送先から受信され始めるか、第
１の依頼転送先からの受信が終了するかのいずれかを待
つ（９１４）。

【００９４】（４）第１の依頼転送先からの受信が終了
したかを調べる（９１５）。受信が終了しないうちに第
２の依頼転送先から受信され始めた場合（９１６）、上
記第１の依頼転送先の場合と同様の手順で、通信コスト
表３２４の第２の依頼転送先に対応する組を更新すると
ともに（９１７）、上記第１の依頼転送先からの受信の
終了時刻ＥＮＤＴＩＭＥと同様の手順で、第２の依頼転
送先からの受信の終了時刻ＥＮＤＴＩＭＥ２を計算する
（９１８）。そして、もしＥＮＤＴＩＭＥがＥＮＤＴＩ
ＭＥ２＋定数Ｃ４よりも大きいかを調べ（９１９）、大
きければ（９２０）、上記第１の依頼転送先からの受信
を中止し（９２１）、第２の転送依頼先を第１の依頼転
送先に置き換え（９２２）、ＥＮＤＴＩＭＥ２をＥＮＤ
ＴＩＭＥとし（９２３）、９１４にもどる。なおここ
で、Ｃ４はサーバ２０５のコンパイル時または起動時ま
たは起動中に変更可能であって差し支えない。また、も
しＥＮＤＴＩＭＥがＥＮＤＴＩＭＥ２＋定数Ｃ４以下で
あれば（９２４）、第２の依頼転送先からの受信を中止
する（９２５）。

【００９５】一方９１５において、第１の依頼転送先か
らの受信が終了した場合（９２６）には、通信コスト表
３２４の第１の依頼転送先に対応する組の通信コスト４
３３のスループットを、今回のスループット（すなわ
ち、今回受信したＵＲＬ内容のサイズを、（当該第１の
転送依頼先が優先依頼転送先ならば）依頼を転送してか
ら現在までの時間または（非優先転送依頼先ならば）返
答開始依頼を送信してから現在までの時間で割ったも
の）と、通信コスト４３３および通信回数４３４の値を
用いて再計算する（９２７）。そして新規ＵＲＬフラグ
を真を格納する（９２８）。以上が、通信コスト表３２
４の更新手順である。

【００９６】返答部３０５は以下の手順で動作する。プ
リフェッチフラグが「真」かどうかを調べる（６２
０）。真ならば、プリフェッチ戦略部３０８に制御を移
す（６２１、３６４）。プリフェッチフラグが「偽」で
あった場合（６２２）、処理対象ＵＲＬに対応するＵＲ
Ｌ内容が受信されたかどうか調べる（６２３）。受信さ
れなかった場合（６２４）には、上記依頼を受けたクラ
イアント２０４または他のサーバに「処理対象ＵＲＬは
存在しない」を返答（３６７）した後（６２５）、依頼
入力部３０１に制御を移して新たなクライアント２０４
または他のサーバからの依頼を待つ（６２６）。一方処
理対象ＵＲＬに対応するＵＲＬ内容が受信された場合
（６２７）、そのＵＲＬ内容を上記依頼を受けたクライ
アント２０４または他のサーバに返答する（６２８、３
６７）。

【００９７】ここで、新規ＵＲＬフラグが真かどうかを
調べる（６２９）。新規ＵＲＬフラグが真なら（６３
０）、ホストＵＲＬメッセージ１２４の送信を行なった
あと（６３１）、リンク統計更新部３０６に制御を移す
（６３２、３５７）。新規ＵＲＬフラグが偽なら（６３
３）、すぐにリンク統計更新部３０６に制御を移す（３
５７）。

【００９８】新規ＵＲＬフラグである場合、ホームペー
ジキャッシュ１０４に１つ以上の組が追加されたことを
意味するので、ホストＵＲＬメッセージ１２４を行な
う。まず新規ＵＲＬフラグに偽を格納してから、１つの
組を持つホストＵＲＬメッセージ１２４を新たに作成
し、当該組のホスト５０１に第１のサーバ２０５のホス
ト名を、ＵＲＬ５０２に処理対象ＵＲＬを、フラグ５０
３に真をそれぞれ格納する。そして、当該組を持つホス
トＵＲＬメッセージ１２４をホスト表に含まれる他のサ
ーバ２０５’、２０５’’、…のうち１つ以上に送信す
る。例えば、ホスト表中の組のうち、第１のサーバ２０
５を含む組を検索する。この組から第１のサーバ２０５
のホスト名を除いた１つ以上のホスト名のそれぞれに対
して、上記手順で作成したホスト頻度メッセージ１２５
を送信する方法が考えられる。また別の方法ではホスト
表中の組に格納されているホスト名のそれぞれに対し
て、当該組を持つホストＵＲＬメッセージ１２４を送信
する方法が考えられる。また、１つの組をもつホストＵ
ＲＬメッセージ１２４をすぐに他のサーバ２０５’、２
０５’’、…に送るのではなく、いくつかの組をまとめ
てから他のサーバ２０５’、２０５’’、…に送ること
も考えられる。最初の方法では、比較的近いサーバ２０
５’、２０５’’、…に通信範囲を限定することがで
き、また最後の方法では通信回数を削減することができ
る。

【００９９】リンク統計更新部３０６では、アクセス頻
度表３２５とリンク頻度表３２６を更新することによ
り、処理対象ＵＲＬのアクセス頻度と、処理対象ＵＲＬ
に至る特定のリンクがアクセスされる頻度を記録する
（３８６）。以下にこの手順を述べる。

【０１００】ステップ７０１で、アクセス頻度表３２５
中の組のうち、ＵＲＬ４４１が処理対象ＵＲＬに等しい
組を検索する。このような組がなければ、新たな組をア
クセス頻度表３２５に作り、当該新たな組のＵＲＬ４４
１を処理対象ＵＲＬで、アクセス頻度４４２のカウンタ
群をすべて０で初期化する。そして検索で見つかった組
または当該新たな組の、アクセス頻度４４２のうち現在
時刻に対応するカウンタを１増加させ、サイズ４４３に
処理対象ＵＲＬに対応するＵＲＬ内容のバイト数を格納
する。

【０１０１】次に、前回アクセスＵＲＬから処理対象Ｕ
ＲＬへのハイパー・テキスト・リンクがあるかを調べる
（７０２）。関連があると判定した場合（７０３）、リ
ンク頻度表３２６を更新する（７０４）。リンク頻度表
３２６の更新は具体的には、リンク頻度表３２６中の組
のうち、参照元ＵＲＬ４５１が前回アクセスＵＲＬに等
しく、かつ参照先ＵＲＬ４５２が処理対象ＵＲＬに等し
い組を検索する。このような組がなければ、新たな組を
リンク頻度表３２６中に作り、当該新たな組の参照元Ｕ
ＲＬ４５１を前回アクセスＵＲＬで、参照先ＵＲＬ４５
２を処理対象ＵＲＬで、アクセス頻度４５３のカウンタ
群をすべて０で初期化する。そして検索で見つかった組
または当該新たな組の、アクセス頻度４５３のうち現在
時刻に対応するカウンタを１増加させる。そして、前回
アクセスＵＲＬに処理対象ＵＲＬを格納してから、グル
ープ更新部３０７に制御を移す（７０５、３５８）。

【０１０２】一方、関連がないと判定した場合には（７
０６）、前回アクセスＵＲＬに処理対象ＵＲＬを格納し
てから、プリフェッチ戦略部３０８に制御を移す。

【０１０３】グループ更新部３０７では、ホームページ
グループ表１０７を更新する（７０７、３８７）。連続
してアクセスされることが多いＵＲＬのひとつの集合を
考えると、この集合をアクセスする際にはじめにアクセ
スされるＵＲＬが少数あると考えられる。本実施例では
このような少数のＵＲＬを見つけた場合にのみリンク統
計更新部３０６からグループ更新部３０７に制御を移す
ことを、すでに述べたリンク統計更新部３０６の場合わ
けにより行なっている。

【０１０４】グループ更新部３０７は以下の手順で行な
う。ホームページグループ表１０７中で、先頭ＵＲＬ４
８１が処理対象ＵＲＬに等しい組を検索する。もしこの
ような組があれば、この組をホームページグループ表１
０７中から削除する。次に、ホームページグループ表１
０７中に新たな組を作成し、先頭ＵＲＬ４８１を処理対
象ＵＲＬで、ＵＲＬグループ４８２を処理対象ＵＲＬか
ら連続してアクセスされる確率が定数Ｃ５以上の１つ以
上のＵＲＬで初期化する。処理対象ＵＲＬから連続して
アクセスされる確率は、アクセス頻度表３２５と外部ア
クセス頻度表３２７とリンク頻度表３２６と外部リンク
頻度表３２８を用いて計算することができる。なお、Ｃ
５はサーバ２０５のコンパイル時または起動時または起
動中に変更可能であって差し支えない。次に、第１のＵ
ＲＬから第２のＵＲＬにリンクがある場合、第１のＵＲ
Ｌのアクセス頻度（アクセス頻度表３２５中ＵＲＬ４４
１が第１のＵＲＬに等しい組のアクセス頻度４４２のカ
ウンタ群の合計）がＡ、第１のＵＲＬから第２のＵＲ
Ｌへのリンクのアクセス頻度（リンク頻度表３２６中参
照元ＵＲＬ４５１が第１のＵＲＬに等しく、参照先ＵＲ
Ｌ４５２が第２のＵＲＬに等しい組のアクセス頻度４５
３のカウンタ群の合計）がＢ、第１のＵＲＬの外部ア
クセス頻度（外部アクセス頻度表３２７中ＵＲＬ４６１
が第１のＵＲＬに等しい組のアクセス頻度４６２のカウ
ンタ）がＣ、第１のＵＲＬから第２のＵＲＬへのリン
クの外部アクセス頻度（外部リンク頻度表３２８中参照
元ＵＲＬ４７１が第１のＵＲＬに等しく、参照先ＵＲＬ
４７２が第２のＵＲＬに等しい組のアクセス頻度４７３
のカウンタの値）がＤとすると、第１のＵＲＬから第
２のＵＲＬが連続してアクセスされる確率は（Ｂ／Ａ）
×（Ｄ／Ｃ）と見積もる。もしＡとＢの値のどちらかが
０の場合、第１のＵＲＬから第２のＵＲＬが連続してア
クセスされる確率は０とする。またもしＣとＤの値のど
ちらかが０の場合、（Ｂ／Ａ）を第１のＵＲＬから第２
のＵＲＬが連続してアクセスされる確率とする。

【０１０５】また、第１のＵＲＬから第２のＵＲＬにリ
ンクがない場合、第３、第４、…、第ＮのＵＲＬが存在
して、第１のＵＲＬから第３のＵＲＬへのリンク、第３
のＵＲＬから第４のＵＲＬへのリンク、…、第ＮのＵＲ
Ｌから第２のＵＲＬへのリンクがそれぞれある場合があ
る。この場合には、第１のＵＲＬから第３のＵＲＬが連
続してアクセスされる確率、第３のＵＲＬから第４のＵ
ＲＬが連続してアクセスされる確率、…、第ＮのＵＲＬ
から第２のＵＲＬが連続してアクセスされる確率をそれ
ぞれｐ２、ｐ３、…、ｐＮとすると、第１のＵＲＬから
第２のＵＲＬが連続してアクセスされる確率はｐ２×ｐ
３×…×ｐＮとする。なお、このような推移閉包にかか
わる計算には、例えばＡｈｏ他著の文献「データ構造と
アルゴリズム」（１９８７年、培風館情報処理シリーズ
１１）第６.３章に記載のダイクストラのアルゴリズム
等良く知られた方法が利用できる。

【０１０６】以上の処理の後、プリフェッチ戦略部３０
８に制御を移す（３５９）。

【０１０７】プリフェッチ戦略部３０８では、処理対象
ＵＲＬがアクセスされた直後にアクセスされやすい１つ
以上のプリフェッチＵＲＬ群に対応するＵＲＬ内容を決
定し、当該プリフェッチＵＲＬ群をクライアント２０４
または他のサーバからの依頼なしでホームページキャッ
シュ１０４に受信する。具体的には、以下の手順で処理
を行なう。

【０１０８】まず、この時点でクライアント２０４また
は他のサーバからの依頼が到着しているかを調べる（７
０８）。到着していれば（７０９）、プリフェッチフラ
グに「偽」を格納し、依頼入力部３０１に制御を移す。

【０１０９】一方依頼が到着していなければ（７１
０）、プリフェッチフラグの値が真かを調べる（７１
１）。

【０１１０】プリフェッチフラグが「偽」ならば（７１
２）、ホームページグループ表１０７で、処理対象ＵＲ
Ｌを含む組を検索し（３８８）、このような組に含まれ
る処理対象ＵＲＬ以外の１つ以上のＵＲＬをプリフェッ
チＵＲＬ群とする。（７１３）。ここでプリフェッチフ
ラグに「真」を格納する。

【０１１１】一方プリフェッチフラグが「真」ならば
（７１４）、プリフェッチ中ＵＲＬをプリフェッチＵＲ
Ｌ群から削除する（７１５）。ここでプリフェッチＵＲ
Ｌ群が空になれば、プリフェッチフラグを「偽」にす
る。

【０１１２】ここでプリフェッチＵＲＬ群に１つ以上の
ＵＲＬが含まれるかを調べる（７１６）。含まれるなら
ば（７１７）、プリフェッチＵＲＬ群から１つのプリフ
ェッチ中ＵＲＬを取り出して（７１８）、プリフェッチ
中ＵＲＬを処理対象ＵＲＬとみなしてキャッシュ表参照
部３０２に渡して（３６１）、すでに述べた手順でプリ
フェッチ中ＵＲＬの受信を開始する。含まれないならば
（７１９）、プリフェッチスケジュール部３０９に制御
を移す（３６０）。なおここまでの手順からも明らかな
ように、このプリフェッチは、クライアントのみならず
他のサーバからの依頼によっても起動される。すなわ
ち、多段に配置された複数のサーバが、一連のプリフェ
ッチを行なうことが可能である。

【０１１３】プリフェッチスケジュール部３０９では、
今後アクセスされると考えられるＵＲＬで、現在ホーム
ページキャッシュ１０４にないものを、将来ネットワー
クがすく時を狙って得るための準備を行なう。プリフェ
ッチスケジュール部３０９は以下の手順で行なう。

【０１１４】まず、ホームページグループ表１０７中
で、先頭ＵＲＬ４８１が前回アクセスＵＲＬに等しい組
を検索することによって、前回アクセスＵＲＬに対応す
るホームページグループ表１０７の組を選択する（７２
０）。

【０１１５】もしこのような組が存在すれば、ＵＲＬグ
ループ４８２に格納されている１つ以上の第１のＵＲＬ
の各々について、プリフェッチする時刻をキャッシュデ
ィレクトリ３２３と通信コスト表３２４から決定する
（７２１、３８４、３８５）。これは以下の手順で行な
う。

【０１１６】第１のＵＲＬに対応するＵＲＬ内容がホー
ムページキャッシュ１０４にあれば何もしない。一方な
ければ、キャッシュディレクトリ３２３中の組で、ＵＲ
Ｌ４２１が第１のＵＲＬに等しいものを検索する。この
ような組がなければ何もしない。このような組が１つ以
上存在する場合には、ＵＲＬ存在確率４２３が最も大き
い組を１つ選択し、その組のホスト４２２を将来アクセ
スするホストとする。次に通信コスト表３２４中で、ホ
スト４３１が当該ホストに等しい第１の組を検索する。
このような組がなければ、なにもしない。もしこのよう
な第１の組が１つ以上あれば、アクセス頻度表３２５中
で、ＵＲＬ４４１が当該第１のＵＲＬに等しい第２の組
を検索する。もしこのような第２の組があれば、第１の
組のうち、（（第２の組のサイズ４４３／第１の組の通
信コスト４３３のスループット）＋第１の組の通信コス
ト４３３のレイテンシ）が最小な第３の組を１つ選ぶ。
第２の組がなければ、（第１の組の通信コスト４３３の
レイテンシ／第１の組の通信コスト４３３のスループッ
ト）が最小な第３の組を１つ選ぶ。

【０１１７】この第３の組の時刻４３２に次に対応する
時刻を「プリフェッチ時刻」と呼ぶ。例えば、時刻４３
２が「水曜日２３：４０」で、現在時刻が１月３日火曜
日の３：００であれば、プリフェッチ時刻は１月４日水
曜日の２３：４０となる。

【０１１８】次に、ステップ７２１で算出した、１つ以
上の第１のＵＲＬのプリフェッチ時刻をタイマー３１１
を設定する（７２２、３８９）。これにより、タイマー
３１１は、すでに述べた手順で第１のＵＲＬの受信を行
なうよう、時刻４３２の時刻に第１のＵＲＬの依頼をキ
ャッシュ表参照部３０２に渡す。このタイマー３１１設
定処理が終わったあとは、依頼入力部３０１に制御を移
す（３６２）。

【０１１９】以上がプリフェッチスケジュール部３０９
の処理である。

【０１２０】キャッシュ入れ替えキャッシュ入れ替え部３１０では、ホームページキャッ
シュ１０４の部分的な削除を行なう（３８３）。ホーム
ページキャッシュ１０４中の組の一部または全部のそれ
ぞれについて、以下の「キャッシュ価値」を計算する。

【０１２１】ある第１のＵＲＬのキャッシュ価値は、ア
クセス戦略表１０５とアクセス頻度表３２５を用いて計
算する。アクセス戦略表１０５内で当該第１のＵＲＬに
等しいＵＲＬ４１１を持つ１つ以上の第１の組を検索す
る。もしこのような組が複数あれば、それぞれの組の
（通信コスト４１３のレイテンシ＋（サイズ４１５／通
信コスト４１３のスループット））が最小の組を１つ選
択し、第１の組とする。さらに、アクセス頻度表３２５
中で、ＵＲＬ４４１が第１のＵＲＬに等しい第２の組を
検索する。

【０１２２】第１の組の（（サイズ４１５／通信コスト
４１３のスループット）＋通信コスト４１３のレイテン
シ）がＡ、第１のＵＲＬのアクセス頻度（すなわち第２
の組のアクセス頻度４４２のカウンタ群の合計）がＢ
である場合、第１のＵＲＬのキャッシュ価値を（（Ａ×
Ｂ）／第１の組のサイズ４１５）とする。万一第１の組
または第２の組がなければ、第１のＵＲＬのキャッシュ
価値は０とする。

【０１２３】上記ホームページキャッシュ１０４中の組
の一部または全部のそれぞれについて「キャッシュ価
値」を計算したら、この「キャッシュ価値」が最も小さ
い組から順にホームページキャッシュ１０４から削除す
る。ホームページキャッシュ１０４からの削除は、ホー
ムページキャッシュ１０４の総量が定数Ｃ３以下になる
まで行なう。

【０１２４】ホームページキャッシュ１０４から１つ以
上の組が削除された場合、次に述べる手順でホストＵＲ
Ｌメッセージ１２４を送信する。ホストＵＲＬメッセー
ジ１２４の送信は以下の手順で行なう。ホストＵＲＬメ
ッセージ１２４を新たに作成し、上記ホームページキャ
ッシュ１０４から削除された組のそれぞれに対して、ホ
ストＵＲＬメッセージ１２４に新たな組を作成する。新
たな組には、ホスト５０１に第１のサーバ２０５のホス
ト名、ＵＲＬ５０２に削除された組のＵＲＬ４０１、フ
ラグ５０３に偽を格納する。そして作成したホストＵＲ
Ｌメッセージ１２４をホスト表に含まれる他のサーバ２
０５’、２０５’’、…のうち１つ以上に送信する。送
信相手の決定方法は、既にのべたホームページキャッシ
ュ１０４に１つ以上の組が追加された場合のホストＵＲ
Ｌメッセージ１２４と同じである。

【０１２５】タイマー処理サーバ２０５は上記の一連の処理の他に、タイマー３１
１によって一定時間ごとに行なわれる処理を行なう。な
お以下に述べるタイマーによる各処理は、主フローとの
競合を避ける目的で、依頼入力部３０１でクライアント
２０４または他のサーバの依頼を待っている場合にのみ
行なう。

【０１２６】タイマー３１１は、定期的にアクセス戦略
表１０５をキャッシュディレクトリ３２３と通信コスト
表３２４とアクセス頻度表３２５から再構成する。これ
は主に、通信コスト表３２４の時刻４３２は何曜日の何
時における各ホストへの通信コストを保持するのに対し
て、アクセス戦略表１０５は現在の各ホストへの通信コ
ストを保持するためである。本実施例では時刻４３２が
１時間毎の情報を保持するため、アクセス頻度表３２５
の再構成は１時間に一度行なう。アクセス戦略表１０
５、キャッシュディレクトリ３２３、通信コスト表３２
４、アクセス頻度表３２５の内容から、再構成の手順は
明らかである。

【０１２７】タイマー３１１は、定期的にアクセス頻度
表３２５とリンク頻度表３２６からホスト頻度メッセー
ジ１２５を作成し、ホスト表に含まれる他のサーバ２０
５’、２０５’’、…の１つ以上に送信する。これは以
下の手順で行なう。

【０１２８】まずホスト頻度メッセージ１２５を１つ作
る。次にアクセス頻度表３２５中のすべての組に対し
て、当該ホスト頻度メッセージ１２５に新たな組を追加
していく。追加する組のホスト５１１は第１のサーバ２
０５のホスト名、参照元ＵＲＬ５１２はアクセス頻度表
３２５の組のＵＲＬ４４１、参照先ＵＲＬ５１３は
「空」、頻度５１４はアクセス頻度表３２５の組のアク
セス頻度４４２のカウンタ群の合計をそれぞれ格納す
る。次にリンク頻度表３２６中のすべての組に対して、
当該ホスト頻度メッセージ１２５に新たな組を追加して
いく。追加する組のホスト５１１は第１のサーバ２０５
のホスト名、参照元ＵＲＬ５１２はリンク頻度表３２６
の組の参照元ＵＲＬ４５１、参照先ＵＲＬ５１３はリン
ク頻度表３２６の組の参照先ＵＲＬ４５２、頻度５１４
はリンク頻度表３２６の組のアクセス頻度４５３のカウ
ンタ群の合計をそれぞれ格納する。次に、ホスト表中の
組のうち、第１のサーバ２０５を含む組を検索する。こ
の組から第１のサーバ２０５のホスト名を除いた１つ以
上のホスト名のそれぞれに対して、上記手順で作成した
ホスト頻度メッセージ１２５を送信する。

【０１２９】また、タイマー３１１は、上記第１のサー
バ２０５を含む組へのホスト頻度メッセージ１２５の送
信よりも粗い頻度（例えば上記送信１０回に１回の割
合）で、ホスト表中の組のうち、第１のサーバ２０５を
含まない組を検索し、この検索の結果である組からに格
納されている１つ以上のホスト名のそれぞれに対して、
上記手順で作成したホスト頻度メッセージ１２５を送信
する。

【０１３０】また、タイマー３１１は、キャッシュディ
レクトリ３２３の組のすべてについて、定期的にＵＲＬ
存在確率４２３の再計算を行なう。これは以下の手順で
行なう。キャッシュディレクトリ３２３中の組のそれぞ
れに対して、ＵＲＬ存在確率４２３を定数Ｃ６だけ減じ
たものをＵＲＬ存在確率４２３に格納する。もし減じた
結果が定数Ｃ７以下なら、ＵＲＬ存在確率４２３にＣ７
を格納する。なおここで、Ｃ６およびＣ７はサーバ２０
５のコンパイル時または起動時または起動中に変更可能
であって差し支えない。

【０１３１】メッセージ処理第１のサーバ２０５のサーバ間メッセージ処理部１０３
が他のサーバ２０５’、２０５’’、…からホストＵＲ
Ｌメッセージ１２４を受け取ると、以下の手順でキャッ
シュディレクトリ３２３を更新する。ホストＵＲＬメッ
セージ１２４が内蔵する組のうちフラグ５０３が真の第
１の組のそれぞれに対して、キャッシュディレクトリ３
２３中の組で、ホスト４２２が第１の組のホスト５０１
に等しくＵＲＬ４２１が第１の組のＵＲＬ５０２に等し
い第２の組を検索する。このような第２の組があれば、
当該第２の組のＵＲＬ存在確率４２３を１に設定する。
また、このような第２の組がなければ、キャッシュディ
レクトリ３２３中に新たな組を作成し、ホスト４２２を
ホスト５０１で、ＵＲＬ４２１をＵＲＬ５０２で、ＵＲ
Ｌ存在確率４２３を１で初期化する。

【０１３２】また、ホストＵＲＬメッセージ１２４が内
蔵する組のうちフラグ５０３が偽の第３の組のそれぞれ
に対して、キャッシュディレクトリ３２３中の組で、ホ
スト４２２が第１の組のホスト５０１に等しくＵＲＬ４
２１が第３の組のＵＲＬ５０２に等しい第４の組を検索
する。このような第４の組があれば、当該第４の組を削
除する。

【０１３３】また、第１のサーバ２０５のサーバ間メッ
セージ処理部１０３が他のサーバ２０５’、２０
５’’、…からホスト頻度メッセージ１２５を受け取る
と、以下の手順で外部アクセス頻度表３２７と外部リン
ク頻度表３２８とを更新する。

【０１３４】受け取ったホスト頻度メッセージ１２５が
内蔵する組で参照先ＵＲＬ５１３が「空」の第１の組の
それぞれについて、外部アクセス頻度表３２７中で、Ｕ
ＲＬ４６１が第１の組の参照元ＵＲＬ５１２に等しい第
２の組を検索する。このような第２の組が存在すれば、
当該第２の組のアクセス頻度４６２に第１の組の頻度５
１４を加え、再び当該第２の組のアクセス頻度４６２に
格納する。一方このような第２の組が存在しなければ、
外部アクセス頻度表３２７に新たな組を作成し、当該組
のＵＲＬ４６１を第１の組の参照元ＵＲＬ５１２で、ア
クセス頻度４６２を第１の組の頻度５１４で初期化す
る。

【０１３５】また、ホスト頻度メッセージ１２５が内蔵
する組で参照先ＵＲＬ５１３が「空」以外の第３の組の
それぞれについて、外部リンク頻度表３２８中で、参照
元ＵＲＬ４７１が第３の組の参照元ＵＲＬ５１２に等し
く、参照先ＵＲＬ４７２が第３の組の参照先ＵＲＬ５１
３に等しい第４の組を検索する。このような第４の組が
存在すれば、当該第４の組のアクセス頻度４７３に第３
の組の頻度５１４を加え、再び当該第４の組のアクセス
頻度４７３に格納する。一方このような第４の組が存在
しなければ、外部リンク頻度表３２８に新たな組を作成
し、当該組の参照元ＵＲＬ４７１を第３の組の参照元Ｕ
ＲＬ５１２で、参照先ＵＲＬ４７２を第３の組の参照先
ＵＲＬ５１３で、アクセス頻度４７３を第３の組の頻度
５１４で初期化する。

【０１３６】

【発明の効果】本発明によれば以下の効果が得られる。

【０１３７】ユーザはクライアントを用いて任意の１つ
のサーバに接続して情報を依頼するだけで、複数のサー
バが通信回線の不均一性と不安定性を隠蔽して情報を提
供する。

【０１３８】サーバ間の通信回線のスループットとレイ
テンシが異なっていても、サーバが相互に交換する情報
により、各サーバは、最も高速に情報の取得が可能であ
ると考えられるサーバを選択する。この結果、最も高速
に情報の取得が可能であると考えられる通信回線を選択
して利用することにより通信回線の不均一性が解決され
る。サーバが相互に交換する情報により、各サーバは例
えば、時間帯や曜日によって回線の混雑が変化したり、
ある通信回線の増強によってルーティングのパターンが
変更され、別の回線が混雑したり混雑が解消されたりす
ることを考慮に入れる。この結果、各サーバは最も高速
に情報の取得が可能であると考えられる他のサーバを、
最も高速に情報の取得が可能であると考えられる通信回
線を選択して利用する。これにより通信回線の不安定性
を回避できる。

【図面の簡単な説明】

【図１】本実施例のサーバの内部構成の概略を示すブロ
ック図。

【図２】本実施例の分散コンピュータ・システムを示す
図。

【図３】サーバ２０５の内部構成を示すブロック図。

【図４】サーバ２０５内で用いられるデータ構造を示す
図である。

【図５】サーバ２０５内で用いられるデータ構造を示す
図（図５の続き）。

【図６】サーバ２０５内の処理手順を示すフローチャー
ト。

【図７】サーバ２０５内の処理手順を示すフローチャー
ト（図６の続き）。

【図８】サーバ２０５、２０５’、２０５’’、…が用
いる混雑緩和のためのプロトコルを説明する図。

【図９】通信コスト表３２４の更新手順を示すフローチ
ャート。

【符号の説明】

２０５サーバ２０４クライアント１０１依頼処理部１０２プリフェッチ部１０３サーバ間メッセージ処理部１０４ホームページキャッシュ１０５アクセス戦略表１０６頻度ＤＢ１０７ホームページグループ表１２４ホストＵＲＬメッセージ１２５ホスト頻度メッセージ３０１依頼入力部３０２キャッシュ表参照部３０３処理戦略部３０４受信部３０５返答部３０６リンク統計更新部３０７グループ更新部３０８プリフェッチ戦略部３０９プリフェッチスケジュール部３１０キャッシュ入れ替え部３２３キャッシュディレクトリ３２４通信コスト表３２５アクセス頻度表３２６リンク頻度表３２７外部アクセス頻度表３２８外部リンク頻度表。

───────────────────────────────────────────────────── フロントページの続き (72)発明者野田文雄東京都国分寺市東恋ケ窪一丁目280番地株式会社日立製作所中央研究所内 (72)発明者閔京華東京都国分寺市東恋ケ窪一丁目280番地株式会社日立製作所中央研究所内

Claims

【特許請求の範囲】

【請求項１】１つ以上のプロセスを動作させる２つ以上
の計算機がネットワークで接続されたコンピュータ・シ
ステム上で、１つ以上のデータを利用するクライアント
対応のプロセスと、１つ以上のデータを保持し、クライ
アントからの依頼により指定されたデータを提供する２
つ以上のサーバ対応のプロセスが用いる分散データ管理
方法であって、第１のサーバが必要とする必要データを１つ以上の第２
のサーバが持つ可能性がある場合に、第１のサーバが、
第１のサーバと第２のサーバが過去に行なった通信履歴
を用いて第２のサーバから１つ以上の第３のサーバを選
択して、第３のサーバに必要データの送信を依頼する分
散データ管理方法。
【請求項２】前記通信履歴として、前記第１のサーバと
前記１つ以上の第２のサーバとの通信の、単位時間当り
の通信可能データ量であるスループットと通信の遅延時
間であるレイテンシを含む請求項１記載の分散データ管
理方法。
【請求項３】前記通信履歴として、前記必要データの大
きさを含む請求項１記載の分散データ管理方法。
【請求項４】前記通信履歴として、前記１つ以上の第２
のサーバが前記必要データを保持しているかどうかを前
記第１のサーバが予測したデータ保持確率を含む請求項
１記載のデータ管理方法。
【請求項５】前記必要データの通信完了時間を前記通信
履歴から予測して、通信完了時間が短いことを基準とし
て、前記１つ以上の第２のサーバから前記１つ以上の第
３のサーバを選択する請求項１記載の分散データ管理方
法。
【請求項６】前記通信完了時間の予測を（前記レイテン
シ＋（前記必要データの大きさ／前記スループット））
の式を用いて行なう請求項５記載の分散データ管理方
法。
【請求項７】前記データ保持確率と、前記第１の通信完
了時間の積が小さいことを基準として、前記１つ以上の
第２のサーバから前記１つ以上の第３のサーバを選択す
る請求項４記載の分散データ管理方法。
【請求項８】２つ以上のサーバから通信が行なわれた際
に、前記通信履歴中の該２つ以上のサーバの通信履歴の
両方を更新する請求項１記載の分散データ管理方法。
【請求項９】１つ以上のプロセスを動作させる２つ以上
の計算機がネットワークで接続されたコンピュータ・シ
ステム上で、２つ以上のサーバ対応のプロセスが用いる
分散データ管理方法であって、第１のサーバの必要デー
タを２つ以上の第２のサーバが持つ可能性があり、第１
のサーバが該２つ以上の第２のサーバに対して必要デー
タの送信を依頼する場合に、第１のサーバが、該２つ以
上の第２のサーバから１つ以上の第３のサーバを選択
し、該第３のサーバには前記必要データを直ちに送信す
ることを依頼し、第３のサーバ以外の第２のサーバには
前記必要データの送信を待機することを依頼する分散デ
ータ管理方法。
【請求項１０】第１のサーバが、第１のサーバと第２の
サーバが過去に行った通信履歴を用いて、前記第２のサ
ーバから前記第３のサーバを選択する請求項９記載の分
散データ管理方法。
【請求項１１】前記第３のサーバの一部または全部か
ら、前記必要データが送信できない旨が前記第１のサー
バに対して通信された際に、前記第１のサーバが、前記
第３のサーバに含まれない前記第２のサーバの一部また
は全部に対して、前記必要データを直ちに送信すること
を依頼する請求項１０記載の分散データ管理方法。
【請求項１２】前記第２のサーバのうち２つ以上のサー
バから、前記必要データの送信が開始された際に、当該
２つ以上のサーバのうち１つ以上の第４のサーバからの
送信のみを継続し、他のサーバからの送信を中止するこ
とにより、不要な必要データの送信を抑制する請求項１
１記載の分散データ管理方法。
【請求項１３】前記通信履歴を用いて、前記第３のサー
バの選択と第４のサーバの選択を行なう請求項１２記載
の分散データ管理方法。
【請求項１４】１つ以上のプロセスを動作させる２つ以
上の計算機がネットワークで接続されたコンピュータ・
システム上で、１つ以上のクライアント対応のプロセス
と２つ以上のサーバ対応のプロセスが用いる分散データ
管理方法であって、第１のサーバが、該第１のサーバと
１つ以上の第２のサーバとの過去の通信に関する、第１
の時間にわたる第２の時間間隔毎の通信の履歴である時
間毎通信履歴を持つ分散データ管理方法。
【請求項１５】前記時間毎通信履歴として、前記第１の
サーバと前記第２のサーバの間の、第１の時間にわたる
第２の時間間隔毎の通信のスループットの履歴と、第１
の時間にわたる第２の時間間隔毎のレイテンシの履歴を
含む請求項１４記載の分散データ管理方法。
【請求項１６】第１のサーバが、今後クライアントから
依頼される可能性が高いと判断されるプリフェッチ対象
データをクライアントからの依頼以前に他のサーバに依
頼してプリフェッチする際に、プリフェッチ対象データ
を持つ可能性がある１つ以上の第２のサーバが存在する
場合、前記時間毎通信履歴を用いて当該第２のサーバか
らプリフェッチ対象データが高速に入手可能な時刻を予
測して、当該時刻に第１のサーバが、第２のサーバの一
部または全部である第３のサーバに対してプリフェッチ
対象データの送信を依頼する請求項１４記載の分散デー
タ管理方法。
【請求項１７】１つ以上のプロセスを動作させる２つ以
上の計算機がネットワークで接続されたコンピュータ・
システム上で、２つ以上のサーバ対応のプロセスが用い
る分散データ管理方法であって、第１のサーバが、第１
のサーバと第２のサーバが過去に行った通信履歴を用い
て第１のサーバが知る第２のサーバから１つ以上の第３
のサーバを選択し、第１のサーバが持つデータの一覧の
一部または全部を、第３のサーバに通信する分散データ
管理方法。
【請求項１８】前記一覧の通信が行なわれた時刻と現在
時刻の差から、前記データ保持確率を決定する請求項１
７記載の分散データ管理方法。
【請求項１９】前記一覧の通信が行なわれた時刻に、前
記データ保持確率を１とし、以後一定時刻毎に、前記デ
ータ保持確率を減少させる請求項１８記載の分散データ
管理方法。
【請求項２０】１つ以上のプロセスを動作させる２つ以
上の計算機がネットワークで接続されたコンピュータ・
システム上で、１つ以上のクライアント対応のプロセス
と２つ以上のサーバ対応のプロセスが用いる分散データ
管理方法であって、第１のサーバが、クライアントから
の依頼の履歴から、第１のデータの依頼に続けて依頼さ
れる頻度が高かった１つ以上の第２のデータを決定し
て、該第１のデータの名前と該１つ以上の第２のデータ
の名前を組にしたデータを参照関係情報として保持する
とともに、第１のサーバの参照関係情報と、第１のサー
バと同じく参照関係情報を保持する１つ以上の第２のサ
ーバの参照関係情報とを交換する分散データ管理方法。
【請求項２１】前記第１のサーバが、クライアントから
第１のデータの依頼を受けた際に、前記参照関係情報を
用いて当該第１のデータに続いて依頼される可能性が高
い１つ以上の第２のデータを決定し、当該第２のサーバ
を持つ可能性のある１つ以上の第２のサーバに対して第
２のデータのプリフェッチを行なう請求項２０記載の分
散データ管理方法。
【請求項２２】前記１つ以上の第２のサーバを、前記第
１のサーバが知る１つ以上の第３のサーバから、第１の
サーバと第２のサーバが過去に行った通信履歴を用いて
選択する請求項２１記載の分散データ管理方法。
【請求項２３】１つ以上のプロセスを動作させる２つ以
上の計算機がネットワークで接続されたコンピュータ・
システム上で、１つ以上のクライアント対応のプロセス
と２つ以上のサーバ対応のプロセスが用いる分散データ
管理方法であって、第１のサーバが、他のサーバから第１のデータの依頼を
受けた際に、該第１のデータに続いて依頼される可能性
の高い第２のデータがある場合に、該第２のデータを持
つ可能性のある１つ以上の第２のサーバに対して、該第
２のデータの送信を依頼することにより、プリフェッチ
をあるサーバから１つ以上の他のサーバへ階層的に行な
う分散データ管理方法。
【請求項２４】前記１つ以上の第２のサーバを、前記第
１のサーバが知る１つ以上の第３のサーバから、第１の
サーバと第２のサーバが過去に行った通信履歴を用いて
選択する請求項２３記載の分散データ管理方法。
【請求項２５】１つ以上のプロセスを動作させる２つ以
上の計算機が、ネットワークで接続されたコンピュータ
・システム上で、１つ以上のクライアント対応のプロセ
スと２つ以上のサーバ対応のプロセスが用いる分散デー
タ管理方法であって、第１のサーバの保持している２つ以上のデータの一部を
破棄する際に、該データを他のサーバから得るのに必要
とする時間の予測を用いて、該２つ以上のデータを順位
づけする分散データ管理方法。
【請求項２６】前記第１のサーバの保持している２つ以
上のデータの一部を破棄する際に、該データを他のサー
バから得るのに必要とする時間の予測と、該データが過
去の一定時間内にクライアントから依頼された回数とを
用いて、該２つ以上のデータを順位づけする請求項２５
記載の分散データ管理方法。
【請求項２７】前記データのそれぞれを他のサーバから
得るのに必要とする時間の予測を、サーバ間で過去に行
った通信履歴を用いて行なう請求項２５記載の分散デー
タ管理方法。
【請求項２８】１つ以上のサーバ対応のプロセスを動作
させる２つ以上の計算機がネットワークで接続されたコ
ンピュータ・システム上で、第１のサーバの必要データ
を１つ以上の第２のサーバが持つ可能性がある場合に、
第１のサーバが、第２のサーバを含む複数のサーバに必
要データの送信を依頼する分散データ管理方法であっ
て、第２のサーバが、他のサーバの依頼を一定時間内に一定
回数以下のみ受け付けるか、または依頼に対するデータ
の送信を一定時間内に一定量以下のみ行なうことにより
第２のサーバが過負荷になることを避ける分散データ管
理方法。