JP2002511616A - 高性能オブジェクト・キャッシュ - Google Patents
高性能オブジェクト・キャッシュInfo
- Publication number
- JP2002511616A JP2002511616A JP2000543914A JP2000543914A JP2002511616A JP 2002511616 A JP2002511616 A JP 2002511616A JP 2000543914 A JP2000543914 A JP 2000543914A JP 2000543914 A JP2000543914 A JP 2000543914A JP 2002511616 A JP2002511616 A JP 2002511616A
- Authority
- JP
- Japan
- Prior art keywords
- cache
- key
- information object
- objects
- block
- 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.)
- Granted
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/56—Provisioning of proxy services
- H04L67/568—Storing data temporarily at an intermediate stage, e.g. caching
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/90—Details of database functions independent of the retrieved data types
- G06F16/95—Retrieval from the web
- G06F16/957—Browsing optimisation, e.g. caching or content distillation
- G06F16/9574—Browsing optimisation, e.g. caching or content distillation of access to content, e.g. by caching
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/953—Organization of data
- Y10S707/955—Object-oriented
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/99941—Database schema or data structure
- Y10S707/99944—Object-oriented database structure
Abstract
(57)【要約】
高性能キャッシュが開示されている。このキャッシュは、多種多様な範囲の情報オブジェクトのために、時間的及び空間的な効率化が図れるよう設計されている。オブジェクトは、実質的に連続してアリーナ内に配置され、タグ・テーブルへ名前キー及びコンテンツベースのオブジェクトキーによりマッピングされている。タグ・テーブルは、前記名前キーによってインデクス付けされ、ディレクトリ・テーブル内のセットへの参照を格納する。タグ・テーブルはコンパクトであるため、迅速なルックアップを可能にする高速メイン・メモリ内に格納することができる。ディレクトリ・テーブルは、少なくともその頻繁にアクセスされる部分が、通常は高速メイン・メモリ内に常駐するよう組織化され、これによってさらにルックアップを高速化する。タグ・テーブル及びディレクトリ・テーブルは、オブジェクトの不存在を素早く判断するよう組織化されている。大型のオブジェクトは断片に分断され、それらは機能的反復送り機構を用いて繋がれ、これによって、残っているディスク上のデータ構造の変化の必要性を避ける。ガーベージ・コレクションは、アクティブでないオブジェクトが削除され、またフリー・スペースが連続的になるように、１つのアリーナ内又は他のアリーナに渡って、周期的にオブジェクトを移動する。オブジェクトは、ほぼ連続的に配置されるので、一般的なオブジェクトの読み出し及び書き込みには、１か２のディスクヘッド・アクチュエータの移動で足り、したがって、キャッシュは、効率的且つ円滑にストレージ・デバイスからデータを流し、マルチメディア・オブジェクトの最適な配信を達成する。開示はまた、コンピュータ装置、コンピュータプログラム製品、及び搬送波に具現されたコンピュータ・データ信号を包含する。
Description
【０００１】
【発明の属する技術分野】本発明は情報配信に関し、より詳しく述べれば、ネ
ットワークを介して効率的かつ高速にクライアントに配信される情報オブジェク
ト用のキャッシュに関する。
ットワークを介して効率的かつ高速にクライアントに配信される情報オブジェク
ト用のキャッシュに関する。
【０００２】
【発明の背景】いくつもの重要なコンピュータ・テクノロジが、かなりの範囲
にわたって中央格納場所からリモート・デバイスへの迅速な情報の配信に頼って
いる。たとえば、クライアント／サーバ・モデルのコンピューティングにおいて
は、１ないしは複数のサーバが情報のストアに使用される。クライアント・コン
ピュータまたはプロセスは、サーバから分離されて、ネットワークを使用してこ
れらのサーバに接続される。クライアントは、必要な情報のネットワーク・アド
レスを指定することによって、これらのサーバの１つにその情報を要求する。サ
ーバは、指定されたネットワーク・アドレスに基づいて情報を見つけ出し、ネッ
トワークを介してそれをクライアントに送信し、トランザクションを完了する。
にわたって中央格納場所からリモート・デバイスへの迅速な情報の配信に頼って
いる。たとえば、クライアント／サーバ・モデルのコンピューティングにおいて
は、１ないしは複数のサーバが情報のストアに使用される。クライアント・コン
ピュータまたはプロセスは、サーバから分離されて、ネットワークを使用してこ
れらのサーバに接続される。クライアントは、必要な情報のネットワーク・アド
レスを指定することによって、これらのサーバの１つにその情報を要求する。サ
ーバは、指定されたネットワーク・アドレスに基づいて情報を見つけ出し、ネッ
トワークを介してそれをクライアントに送信し、トランザクションを完了する。
【０００３】 ワールド・ワイド・ウェブは、広く使用されているクライアン
ト／サーバ・コンピューティング・モデルの応用である。図１は、ウェブ・シス
テムにおいて使用されるエレメント間の関係を簡潔に示したブロック図である。
それぞれをコンピュータもしくはブラウザ等のソフトウエア・プロセスとする１
ないしは複数のウェブ・クライアント１０ａ、１０ｂが、直接もしくはインター
ネット・サービス・プロバイダ等の仲介者を介して、あるいはオンライン情報サ
ービスを介してインターネットと呼ばれるグローバル情報ネットワーク２０に接
続されている。
ト／サーバ・コンピューティング・モデルの応用である。図１は、ウェブ・シス
テムにおいて使用されるエレメント間の関係を簡潔に示したブロック図である。
それぞれをコンピュータもしくはブラウザ等のソフトウエア・プロセスとする１
ないしは複数のウェブ・クライアント１０ａ、１０ｂが、直接もしくはインター
ネット・サービス・プロバイダ等の仲介者を介して、あるいはオンライン情報サ
ービスを介してインターネットと呼ばれるグローバル情報ネットワーク２０に接
続されている。
【０００４】 ウェブ・サーバ４０は、ネットワーク・リンク４２によって同
様にインターネット２０に接続されている。ウェブ・サーバ４０は、中央のドメ
イン・ネーム・サーバ（ＤＮＳ）においてインデクス付けされた合意に基づくフ
ォーマットを用いて関連付けされている１ないしは複数のインターネット・ネッ
トワーク・アドレスならびに逐語的なホスト名を有する。サーバは、ドキュメン
トおよびイメージ等の、要求に応じてクライアントに提供するためのマルチメデ
ィア情報リソースを擁している。ウェブ・サーバ４０が、それに加えて、もしく
はそれに代えて、要求に応答してこの種のリソースを動的に生成するためのソフ
トウエアを有していることもある。
様にインターネット２０に接続されている。ウェブ・サーバ４０は、中央のドメ
イン・ネーム・サーバ（ＤＮＳ）においてインデクス付けされた合意に基づくフ
ォーマットを用いて関連付けされている１ないしは複数のインターネット・ネッ
トワーク・アドレスならびに逐語的なホスト名を有する。サーバは、ドキュメン
トおよびイメージ等の、要求に応じてクライアントに提供するためのマルチメデ
ィア情報リソースを擁している。ウェブ・サーバ４０が、それに加えて、もしく
はそれに代えて、要求に応答してこの種のリソースを動的に生成するためのソフ
トウエアを有していることもある。
【０００５】 クライアント１０ａ、１０ｂおよびウェブ・サーバ４０は、伝
達する情報のフォーマットを指定する、１ないしは複数の合意に基づくプロトコ
ルを使用して通信する。クライアント１０ａは、ＤＮＳを使用して特定のサーバ
のネットワーク・アドレスをルックアップし、ハイパーテキスト・トランスファ
・プロトコル（ＨＴＴＰ）と呼ばれる通信プロトコルを使用して当該サーバとの
接続を確立する。ユニフォーム・リソース・ロケータ（ＵＲＬ）は、ウェブ・サ
ーバ４０にストアされた、あるいはそれによって動的に生成されたそれぞれの情
報オブジェクトを固有識別する。ＵＲＬは、ネットワーク・アドレスの一形式で
あり、ネットワーク内にストアされた情報の場所を識別する。
達する情報のフォーマットを指定する、１ないしは複数の合意に基づくプロトコ
ルを使用して通信する。クライアント１０ａは、ＤＮＳを使用して特定のサーバ
のネットワーク・アドレスをルックアップし、ハイパーテキスト・トランスファ
・プロトコル（ＨＴＴＰ）と呼ばれる通信プロトコルを使用して当該サーバとの
接続を確立する。ユニフォーム・リソース・ロケータ（ＵＲＬ）は、ウェブ・サ
ーバ４０にストアされた、あるいはそれによって動的に生成されたそれぞれの情
報オブジェクトを固有識別する。ＵＲＬは、ネットワーク・アドレスの一形式で
あり、ネットワーク内にストアされた情報の場所を識別する。
【０００６】 ワールド・ワイド・ウェブのパフォーマンスを制限する主要な
要因は、インターネット２０を介してウェブ・サーバ４０からクライアントに情
報を供給し得る速度である。パフォーマンスは、インターネットを通るネットワ
ーク・ルートの速度、信頼性、および輻輳のレベルによって、地理的な距離がも
たらす遅延によって、さらにはサーバの負荷レベルによって制限を受ける。した
がって、サーバから地理的に離れたリポジトリ内に一般的な情報オブジェクトの
レプリカをストアしておくことにより、クライアントのトランザクション時間を
節約することができる。オブジェクトのレプリカのための各ローカル・リポジト
リは、一般にキャッシュと呼ばれている。クライアントがオリジナルのウェブ・
サーバにアクセスするより、位相的にもっとも近いキャッシュにあるレプリカに
アクセスする方が高速になるだけでなく、インターネット・サーバのトラフィッ
クを低減することができる。
要因は、インターネット２０を介してウェブ・サーバ４０からクライアントに情
報を供給し得る速度である。パフォーマンスは、インターネットを通るネットワ
ーク・ルートの速度、信頼性、および輻輳のレベルによって、地理的な距離がも
たらす遅延によって、さらにはサーバの負荷レベルによって制限を受ける。した
がって、サーバから地理的に離れたリポジトリ内に一般的な情報オブジェクトの
レプリカをストアしておくことにより、クライアントのトランザクション時間を
節約することができる。オブジェクトのレプリカのための各ローカル・リポジト
リは、一般にキャッシュと呼ばれている。クライアントがオリジナルのウェブ・
サーバにアクセスするより、位相的にもっとも近いキャッシュにあるレプリカに
アクセスする方が高速になるだけでなく、インターネット・サーバのトラフィッ
クを低減することができる。
【０００７】 一構成におけるキャッシュは、図１に示されるように、論理的
にウェブ・クライアント１０ａ、１０ｂと、ウェブ・サーバ４０の間に介挿され
るプロキシ・サーバ３０内に置かれる。プロキシ・サーバは、クライアントに対
してはサーバとして、サーバに対してはクライアントとして作用する「仲介人」
のゲートウエイ・サービスを提供する。キャッシュを備えたプロキシ・サーバは
、キャッシング・プロキシ・サーバもしくは、一般的に「プロキシ・キャッシュ
」と呼ばれている。
にウェブ・クライアント１０ａ、１０ｂと、ウェブ・サーバ４０の間に介挿され
るプロキシ・サーバ３０内に置かれる。プロキシ・サーバは、クライアントに対
してはサーバとして、サーバに対してはクライアントとして作用する「仲介人」
のゲートウエイ・サービスを提供する。キャッシュを備えたプロキシ・サーバは
、キャッシング・プロキシ・サーバもしくは、一般的に「プロキシ・キャッシュ
」と呼ばれている。
【０００８】 プロキシ・キャッシュ３０は、ウェブ・クライアント１０ａ、
１０ｂからウェブ・サーバ４０に向けられたリソースの要求をインターセプトす
る。プロキシ３０内のキャッシュが、要求されたリソースのレプリカを有し、そ
れが特定の新しさに関する制約に適合するとき、プロキシがウェブ・クライアン
ト１０ａ、１０ｂに応答してそのリソースを直接提供する。この構成においては
、リンク４２を介して行われるデータ転送の数ならびに量が大きく抑えられる。
この結果、ネットワーク・リソースまたはオブジェクトが、より迅速にウェブ・
クライアント１０ａ、１０ｂに提供されることになる。
１０ｂからウェブ・サーバ４０に向けられたリソースの要求をインターセプトす
る。プロキシ３０内のキャッシュが、要求されたリソースのレプリカを有し、そ
れが特定の新しさに関する制約に適合するとき、プロキシがウェブ・クライアン
ト１０ａ、１０ｂに応答してそのリソースを直接提供する。この構成においては
、リンク４２を介して行われるデータ転送の数ならびに量が大きく抑えられる。
この結果、ネットワーク・リソースまたはオブジェクトが、より迅速にウェブ・
クライアント１０ａ、１０ｂに提供されることになる。
【０００９】 この種のキャッシングにおける主要な問題は、キャッシュ内の
オブジェクトに関する効率的なストア、配置、および取り出しである。この明細
書は、キャッシュ内におけるマルチメディア・オブジェクトのストア、配置、お
よび取り出しに関連するテクノロジに関連する。キャッシュ内のオブジェクト用
ストレージ装備は、「キャッシュ・オブジェクト・ストア」もしくは「オブジェ
クト・ストア」と呼ばれている。
オブジェクトに関する効率的なストア、配置、および取り出しである。この明細
書は、キャッシュ内におけるマルチメディア・オブジェクトのストア、配置、お
よび取り出しに関連するテクノロジに関連する。キャッシュ内のオブジェクト用
ストレージ装備は、「キャッシュ・オブジェクト・ストア」もしくは「オブジェ
クト・ストア」と呼ばれている。
【００１０】 ワールド・ワイド・ウェブ等の重いトラフィック環境を効果的
に取り扱うために、キャッシュ・オブジェクト・ストアには、数千万ないしは数
億の異なるオブジェクトを取り扱えるだけでなく、同時にオブジェクトのストア
、削除、およびフェッチが可能であることが要求される。このため、キャッシュ
のパフォーマンスは、オブジェクトの数により大きく低下するようであってはな
らない。パフォーマンスは、キャッシュ・オブジェクト・ストアが目指す目標で
ある。
に取り扱うために、キャッシュ・オブジェクト・ストアには、数千万ないしは数
億の異なるオブジェクトを取り扱えるだけでなく、同時にオブジェクトのストア
、削除、およびフェッチが可能であることが要求される。このため、キャッシュ
のパフォーマンスは、オブジェクトの数により大きく低下するようであってはな
らない。パフォーマンスは、キャッシュ・オブジェクト・ストアが目指す目標で
ある。
【００１１】 キャッシュ内のオブジェクトを見つけ出すことは、もっとも一
般的なオペレーションであり、したがってキャッシュは、サーチの実行において
極めて高速でなければならない。キャッシュのパフォーマンスを制限する主要因
は、ルックアップ時間である。オブジェクトがキャッシュ内に存在するか（「ヒ
ット」）あるいは存在しないか（「ミス」）を可能な限り高速に決定し得るキャ
ッシュがあると望ましい。過去のアプローチにおいては、数百万のオブジェクト
をストアし得るキャッシュが、伝統的なファイル・システム・ストレージ構造に
使用されている。伝統的なファイル・システムは、マルチメディア・オブジェク
トのキャッシュに対する適合性が低いが、これはファイル・システムが特定のオ
ブジェクト・サイズに調整されていること、およびファイル・システムのメタデ
ータを調べるためには複数のディスク・ヘッドを動作させる必要があることを理
由とする。オブジェクト・ストアは、オブジェクトのルックアップ・タスクに専
用ＤＲＡＭメモリを使用することにより、より高いルックアップ・パフォーマン
スを得ることができるが、数千万ないしは数百万のオブジェクトが存在すること
から、メモリ・ルックアップ・テーブルを非常にコンパクトにしなければならな
い。
般的なオペレーションであり、したがってキャッシュは、サーチの実行において
極めて高速でなければならない。キャッシュのパフォーマンスを制限する主要因
は、ルックアップ時間である。オブジェクトがキャッシュ内に存在するか（「ヒ
ット」）あるいは存在しないか（「ミス」）を可能な限り高速に決定し得るキャ
ッシュがあると望ましい。過去のアプローチにおいては、数百万のオブジェクト
をストアし得るキャッシュが、伝統的なファイル・システム・ストレージ構造に
使用されている。伝統的なファイル・システムは、マルチメディア・オブジェク
トのキャッシュに対する適合性が低いが、これはファイル・システムが特定のオ
ブジェクト・サイズに調整されていること、およびファイル・システムのメタデ
ータを調べるためには複数のディスク・ヘッドを動作させる必要があることを理
由とする。オブジェクト・ストアは、オブジェクトのルックアップ・タスクに専
用ＤＲＡＭメモリを使用することにより、より高いルックアップ・パフォーマン
スを得ることができるが、数千万ないしは数百万のオブジェクトが存在すること
から、メモリ・ルックアップ・テーブルを非常にコンパクトにしなければならな
い。
【００１２】 オブジェクトを見つけた後は、クライアントにそれを効率的に
転送する必要がある。最近のディスク・ドライブは、連続データの読み出しおよ
び書き込みにおいて高いパフォーマンスを提供するが、ディスク・ヘッドがディ
スク上の各部に移動しなければならないとき、大きなパフォーマンスの遅れを招
く。これらのディスク・ヘッドの動きを「シーク」と呼んでいる。ディスクのパ
フォーマンスは、一般にドライブの１秒当たりの定格シーク数に拘束される。キ
ャッシュのパフォーマンスを最適化するためには、連続したデータのブロックの
読み出しおよび書き込みを行うことによって、ディスクのシーク数を最小化する
ことが望ましい。
転送する必要がある。最近のディスク・ドライブは、連続データの読み出しおよ
び書き込みにおいて高いパフォーマンスを提供するが、ディスク・ヘッドがディ
スク上の各部に移動しなければならないとき、大きなパフォーマンスの遅れを招
く。これらのディスク・ヘッドの動きを「シーク」と呼んでいる。ディスクのパ
フォーマンスは、一般にドライブの１秒当たりの定格シーク数に拘束される。キ
ャッシュのパフォーマンスを最適化するためには、連続したデータのブロックの
読み出しおよび書き込みを行うことによって、ディスクのシーク数を最小化する
ことが望ましい。
【００１３】 いずれにしても最終的にはオブジェクト・ストアが満杯になり
、特定のオブジェクトを消去して新しいコンテンツのためにスペースを開ける必
要が生じる。これが「ガーベジ・コレクション」と呼ばれるプロセスである。ガ
ーベジ・コレクションは、充分に効率的であり、システムのパフォーマンスを大
きく低下させることなく連続的に動作し、その一方で将来的なキャッシュのパフ
ォーマンスにおいてもっとも影響の少ないオブジェクトを削除し得るものでなけ
ればならない。
、特定のオブジェクトを消去して新しいコンテンツのためにスペースを開ける必
要が生じる。これが「ガーベジ・コレクション」と呼ばれるプロセスである。ガ
ーベジ・コレクションは、充分に効率的であり、システムのパフォーマンスを大
きく低下させることなく連続的に動作し、その一方で将来的なキャッシュのパフ
ォーマンスにおいてもっとも影響の少ないオブジェクトを削除し得るものでなけ
ればならない。
【００１４】
【過去のアプローチ】過去においてはキャッシュ・オブジェクト・ストアの構
成に４つのアプローチが使用されている：すなわち、ネイティブ・ファイル・シ
ステムの使用、メモリ‐ブロック「ページ」キャッシュの使用、データベースの
使用、および「サイクロン」の使用である。これらの従来的なアプローチのそれ
ぞれには、無視できない欠点が存在する。
成に４つのアプローチが使用されている：すなわち、ネイティブ・ファイル・シ
ステムの使用、メモリ‐ブロック「ページ」キャッシュの使用、データベースの
使用、および「サイクロン」の使用である。これらの従来的なアプローチのそれ
ぞれには、無視できない欠点が存在する。
【００１５】 ネイティブ・ファイル・システムを用いるアプローチは、サー
バ上で走るオペレーティング・システムのファイル・システムを使用してキャッ
シュを作成し、管理する。ファイル・システムは、そこで考慮されている特定の
アプリケーション用に、つまり、ユーザ・データ・ファイルおよびシステム・デ
ータ・ファイルのストアおよび取り出し用に設計されている。ファイル・システ
ムは、ファイル・マネジメント・アプリケーション用の設計および最適化がなさ
れる。これらは、代表的なデータ・ファイル・サイズ用に、かつ比較的少ないフ
ァイル数（合計および１フォルダ／ディレクトリ内の両方における数）用に最適
化される。伝統的なファイル・システムは、ファイルを開き、読み出し／書き込
みを行い、それを閉じるためのシーク数を最小化すべく最適化されてはいない。
多くのファイル・システムは、大量のファイルが存在するとき、ファイルを見つ
け出し、それを開く上で著しいパフォーマンスの低下を招く。代表的なファイル
・システムは、ドライブの表面に小さなディスク・ブロックが散在してしまうフ
ラグメンテーションを生じ、データのアクセスに必要なディスク・シーク数の増
加をもたらしているだけでなく、ストレージ空間の無駄を招いている。
バ上で走るオペレーティング・システムのファイル・システムを使用してキャッ
シュを作成し、管理する。ファイル・システムは、そこで考慮されている特定の
アプリケーション用に、つまり、ユーザ・データ・ファイルおよびシステム・デ
ータ・ファイルのストアおよび取り出し用に設計されている。ファイル・システ
ムは、ファイル・マネジメント・アプリケーション用の設計および最適化がなさ
れる。これらは、代表的なデータ・ファイル・サイズ用に、かつ比較的少ないフ
ァイル数（合計および１フォルダ／ディレクトリ内の両方における数）用に最適
化される。伝統的なファイル・システムは、ファイルを開き、読み出し／書き込
みを行い、それを閉じるためのシーク数を最小化すべく最適化されてはいない。
多くのファイル・システムは、大量のファイルが存在するとき、ファイルを見つ
け出し、それを開く上で著しいパフォーマンスの低下を招く。代表的なファイル
・システムは、ドライブの表面に小さなディスク・ブロックが散在してしまうフ
ラグメンテーションを生じ、データのアクセスに必要なディスク・シーク数の増
加をもたらしているだけでなく、ストレージ空間の無駄を招いている。
【００１６】 またファイル・システムは、ユーザのデータ・ファイル・マネ
ジメント用に設計されていることから、キャッシュ・オブジェクト・ストアに無
関係な装備を含み、この応用にとって反生産的であることは疑いようがない。例
を挙げると次のようなものがある：すなわち、ランダム・アクセスおよび選択的
修正のサポート、ファイル許可、ファイルの名称変更のサポート、および時間を
隔てたファイルに対する追加のサポートである。さらにファイル・システムは、
データの喪失を最小化するために、書き込み時および、障害後のファイル・シス
テムの再構築時に、パフォーマンスの犠牲の上に多大なエネルギを投資する。結
局ファイル・システムは、ウェブ・オブジェクトのキャッシュに存在し得る数百
万のファイルの取り扱いにあまり適していない。ファイル・システムは、サイズ
が大きく変動するインターネット・マルチメディア・オブジェクトを効率的にサ
ポートしない ―― 特に、非常に小さいオブジェクトもしくは非常に大きいオ
ブジェクトのサポートが一般に効率的でない。ファイル・システムは、メタデー
タの検索およびブロックのチェーニングに非常に多くのディスク・シークを必要
とし、ガーベジ・コレクションのサポートが貧弱であり、データ保全およびリス
タートに際してのファイル・システムのリペアに多くの時間を必要とする。
ジメント用に設計されていることから、キャッシュ・オブジェクト・ストアに無
関係な装備を含み、この応用にとって反生産的であることは疑いようがない。例
を挙げると次のようなものがある：すなわち、ランダム・アクセスおよび選択的
修正のサポート、ファイル許可、ファイルの名称変更のサポート、および時間を
隔てたファイルに対する追加のサポートである。さらにファイル・システムは、
データの喪失を最小化するために、書き込み時および、障害後のファイル・シス
テムの再構築時に、パフォーマンスの犠牲の上に多大なエネルギを投資する。結
局ファイル・システムは、ウェブ・オブジェクトのキャッシュに存在し得る数百
万のファイルの取り扱いにあまり適していない。ファイル・システムは、サイズ
が大きく変動するインターネット・マルチメディア・オブジェクトを効率的にサ
ポートしない ―― 特に、非常に小さいオブジェクトもしくは非常に大きいオ
ブジェクトのサポートが一般に効率的でない。ファイル・システムは、メタデー
タの検索およびブロックのチェーニングに非常に多くのディスク・シークを必要
とし、ガーベジ・コレクションのサポートが貧弱であり、データ保全およびリス
タートに際してのファイル・システムのリペアに多くの時間を必要とする。
【００１７】 ページ・キャッシュは、固定サイズのメモリ・バッファのセッ
トを用いてファイル・システムを拡張する。データは、ネットワークを介した送
信の前にこれらのバッファの内外に置かれる。このアプローチは、遅い接続を介
して大きなオブジェクトを送るとき、大量のメモリを無駄にする。
トを用いてファイル・システムを拡張する。データは、ネットワークを介した送
信の前にこれらのバッファの内外に置かれる。このアプローチは、遅い接続を介
して大きなオブジェクトを送るとき、大量のメモリを無駄にする。
【００１８】 データベース・システム・アプローチは、データベース・シス
テムをキャッシュとして使用する。一般に、データベースの構築により達成され
る目標は、オブジェクト・キャッシュとしての使用に適していない。たとえばデ
ータベースは、トランザクション処理を最適化するために構築される。各トラン
ザクションの保全性を確保するために、そこでは大規模なロックが使用される。
その結果、設計目標として、速度等のパフォーマンス要因よりデータ保全が優先
されることになる。これとは対照的に、オブジェクト・キャッシュにとっては、
データのオリジナルのソースであるサーバからデータを随時取り出すことができ
るため、キャッシュがオブジェクトを改ざんしない限り、まれに発生するデータ
の喪失は許容される。データベースは、書き込み速度がトランザクションの処理
速度を制限することから、高速書き込みパフォーマンス用に最適化されることが
少なくない。しかしながら、オブジェクト・キャッシュにおいては、読み出し速
度も同程度に重要である。さらに、データベースは、仮想メモリ内におけるスト
リーミング、パイプラインＩ／Ｏをサポートしつつ、広い範囲にわたって各種の
サイズを有するオブジェクトをストアすることを本質的に不得手としている。一
般に固定レコード・サイズに最適化されたデータベースは、一定の大きさのレコ
ードを作る。データベースが各種のレコード・サイズをサポートしている場合、
冗長なオブジェクト関係のサポートが含まれ、通常は遅い、仮想メモリ・ページ
ング技法を使用してストリーミング、パイプラインＩ／Ｏをサポートする。
テムをキャッシュとして使用する。一般に、データベースの構築により達成され
る目標は、オブジェクト・キャッシュとしての使用に適していない。たとえばデ
ータベースは、トランザクション処理を最適化するために構築される。各トラン
ザクションの保全性を確保するために、そこでは大規模なロックが使用される。
その結果、設計目標として、速度等のパフォーマンス要因よりデータ保全が優先
されることになる。これとは対照的に、オブジェクト・キャッシュにとっては、
データのオリジナルのソースであるサーバからデータを随時取り出すことができ
るため、キャッシュがオブジェクトを改ざんしない限り、まれに発生するデータ
の喪失は許容される。データベースは、書き込み速度がトランザクションの処理
速度を制限することから、高速書き込みパフォーマンス用に最適化されることが
少なくない。しかしながら、オブジェクト・キャッシュにおいては、読み出し速
度も同程度に重要である。さらに、データベースは、仮想メモリ内におけるスト
リーミング、パイプラインＩ／Ｏをサポートしつつ、広い範囲にわたって各種の
サイズを有するオブジェクトをストアすることを本質的に不得手としている。一
般に固定レコード・サイズに最適化されたデータベースは、一定の大きさのレコ
ードを作る。データベースが各種のレコード・サイズをサポートしている場合、
冗長なオブジェクト関係のサポートが含まれ、通常は遅い、仮想メモリ・ページ
ング技法を使用してストリーミング、パイプラインＩ／Ｏをサポートする。
【００１９】 サイクロン・ファイル・システムにおいては、データが環状ス
トレージ構造に割り当てられる。スペースがいっぱいになると、単純にもっとも
古いデータが削除される。このアプローチは迅速なオブジェクトの割り当てを考
慮しているが、大きなオブジェクトを最初にメモリ内に置くことなくこれらをサ
ポートすることが困難であり、データのフラグメンテーションを伴う問題を招き
、通常は、もっとも古いオブジェクトをその「人気」と無関係に削除するという
単純素朴なガーベジ・コレクションを伴う。多様なワーキング・セットを伴う中
程度のアクティブ・キャッシュの場合、この種のファースト‐イン‐ファースト
‐アウトのガーベジ・コレクションは、オブジェクトが再利用される前にそれを
破棄してしまう可能性がある。
トレージ構造に割り当てられる。スペースがいっぱいになると、単純にもっとも
古いデータが削除される。このアプローチは迅速なオブジェクトの割り当てを考
慮しているが、大きなオブジェクトを最初にメモリ内に置くことなくこれらをサ
ポートすることが困難であり、データのフラグメンテーションを伴う問題を招き
、通常は、もっとも古いオブジェクトをその「人気」と無関係に削除するという
単純素朴なガーベジ・コレクションを伴う。多様なワーキング・セットを伴う中
程度のアクティブ・キャッシュの場合、この種のファースト‐イン‐ファースト
‐アウトのガーベジ・コレクションは、オブジェクトが再利用される前にそれを
破棄してしまう可能性がある。
【００２０】 キャッシュ・オブジェクト・ストアの設計における上記のアプ
ローチに付随する基本的な問題は、問題の制約に関して解決策が最適化されない
ことである。これらのアプローチは、すべて、新しい応用に向けた、現存するテ
クノロジの再応用に過ぎない。上記の応用の中に、マルチメディア、ストリーミ
ング、オブジェクト・キャッシュに固有の制約に対して理想的に適合しているも
のはない。上記の解決策は、不完全な再応用に起因して本質的にオブジェクト・
キャッシュを妨げるだけでなく、マルチメディア・オブジェクト・キャッシュに
おける、より固有の要件の効率的なサポートを不可能にする。これらの固有の要
件には、同一であるが異なる名前を有する冗長なコンテンツを明確化し、かつ共
有する能力、またそれとは逆の、特定のクライアント、言語、データ型等に向け
られた、同一の名前を有するコンテンツの複数の変化型(variants)をストアする
能力が含まれる。
ローチに付随する基本的な問題は、問題の制約に関して解決策が最適化されない
ことである。これらのアプローチは、すべて、新しい応用に向けた、現存するテ
クノロジの再応用に過ぎない。上記の応用の中に、マルチメディア、ストリーミ
ング、オブジェクト・キャッシュに固有の制約に対して理想的に適合しているも
のはない。上記の解決策は、不完全な再応用に起因して本質的にオブジェクト・
キャッシュを妨げるだけでなく、マルチメディア・オブジェクト・キャッシュに
おける、より固有の要件の効率的なサポートを不可能にする。これらの固有の要
件には、同一であるが異なる名前を有する冗長なコンテンツを明確化し、かつ共
有する能力、またそれとは逆の、特定のクライアント、言語、データ型等に向け
られた、同一の名前を有するコンテンツの複数の変化型(variants)をストアする
能力が含まれる。
【００２１】 以上に基づくと、これらの従来アプローチの欠点を克服し、か
つマルチメディア・オブジェクト・キャッシュの固有の要件により理想的に適合
するオブジェクト・キャッシュを提供する必要があることは明らかである。 特に： １． 多様なサイズを有する数億のオブジェクト、およびテラバイトのコンテ
ンツ・サイズを効率的な態様でメモリ内にストアし得るオブジェクト・キャッシ
ュが必要とされている。 ２． 時間を要するファイル・ディレクトリ・ルックアップを必要とせずに、
迅速にドキュメントが「ヒット」であるか「ミス」であるかを決定できるオブジ
ェクト・キャッシュが求められている。 ３． オブジェクトの読み出しおよび書き込みのためのディスク・シーク数を
最小化するキャッシュが必要とされている。 ４． キャッシュからの、およびキャッシュへのデータの効率的なストリーミ
ングを可能にするオブジェクト・ストアが必要とされている。 ５． 同一の名前で指定された複数の異なるバージョンの選択肢をサポートす
るオブジェクト・ストアが必要とされている。 ６． コンテンツの重複を招くことなく大量のオブジェクトを効率的にストア
するオブジェクト・ストアが必要とされている。 ７． 影響を考慮して置換するドキュメントを選択しつつリアルタイムで迅速
かつ効率的なガーベジ・コレクションを行い、ユーザの応答速度を向上し、トラ
フィックを軽くすることができるオブジェクト・ストアが必要とされている。 ８． ソフトウエアもしくはハードウエアの障害後にリスタートしたとき、デ
ータの改ざんを招くことなく、かつデータの喪失を最小限にして数秒内に完全な
動作能力に復帰できるオブジェクト・ストアが必要とされている。
つマルチメディア・オブジェクト・キャッシュの固有の要件により理想的に適合
するオブジェクト・キャッシュを提供する必要があることは明らかである。 特に： １． 多様なサイズを有する数億のオブジェクト、およびテラバイトのコンテ
ンツ・サイズを効率的な態様でメモリ内にストアし得るオブジェクト・キャッシ
ュが必要とされている。 ２． 時間を要するファイル・ディレクトリ・ルックアップを必要とせずに、
迅速にドキュメントが「ヒット」であるか「ミス」であるかを決定できるオブジ
ェクト・キャッシュが求められている。 ３． オブジェクトの読み出しおよび書き込みのためのディスク・シーク数を
最小化するキャッシュが必要とされている。 ４． キャッシュからの、およびキャッシュへのデータの効率的なストリーミ
ングを可能にするオブジェクト・ストアが必要とされている。 ５． 同一の名前で指定された複数の異なるバージョンの選択肢をサポートす
るオブジェクト・ストアが必要とされている。 ６． コンテンツの重複を招くことなく大量のオブジェクトを効率的にストア
するオブジェクト・ストアが必要とされている。 ７． 影響を考慮して置換するドキュメントを選択しつつリアルタイムで迅速
かつ効率的なガーベジ・コレクションを行い、ユーザの応答速度を向上し、トラ
フィックを軽くすることができるオブジェクト・ストアが必要とされている。 ８． ソフトウエアもしくはハードウエアの障害後にリスタートしたとき、デ
ータの改ざんを招くことなく、かつデータの喪失を最小限にして数秒内に完全な
動作能力に復帰できるオブジェクト・ストアが必要とされている。
【００２２】 本明細書は、前述の目的の達成に向けられたテクノロジに関連
する。特に本明細書では、大きなオブジェクト・ストアにおいて時間効率が高く
かつ空間効率の高い、オブジェクトの格納、取り出しおよびメンテナンスに関連
する方法および装置について説明されている。ここで説明するテクノロジは、高
性能、高負荷の応用のためのキャッシュ・オブジェクト・ストアを提供し、これ
は次に示す一般的な特性を有している。 １．高性能：オブジェクトのストア操作に関して待ち時間が小さく、高いスル
ープットが得られ、かつ多数の同時操作が得られる。 ２．大型キャッシュのサポート：テラバイト台のキャッシュおよび数十億のオ
ブジェクトをサポートし、インターネットの指数関数的なコンテンツの増加レー
トを扱うことができる。 ３．メモリのストレージ空間の効率化：高価な半導体メモリを節約し、効果的
に使用する。 ４．ディスクのストレージ空間の効率化：オブジェクト・ストアの有限なディ
スク容量内に大量のインターネット・オブジェクトのレプリカをストアすること
ができる。 ５．エイリアスの自由度：名前は異なるが、コンテンツが等しい同一オブジェ
クト・コンテンツを有する複数のオブジェクトまたはオブジェクトの変化型は、
オブジェクト・コンテンツが１回だけキャッシュされ、異なる名前の間で共有さ
れる。 ６．マルチメディアの多様性をサポート：数百バイトからメガバイトに至る６
桁にわたるサイズ範囲で多数のタイプの多様なマルチメディア・オブジェクトを
効率的にサポートする。 ７．高速かつ用法を意識したガーベジ・コレクション：有用性の低いオブジェ
クトをオブジェクト・ストアから効率的に削除し、新しいオブジェクトのための
スペースを確保する。 ８．データの一貫性：プログラム上のエラーおよびハードウエアの障害により
データの信頼性を失うことがない。 ９．高速リスタートが可能：時間を要するデータベースまたはファイル・シス
テムのチェック・オペレーションを必要とすることなく、リスタート後数秒内に
オブジェクト・キャッシュが要求に対するサービスを開始することができる。 １０．ストリーミング：大きなオブジェクト全体をメモリ内に置くことなく、
オブジェクト・ストアから遅いクライアントに、効率的にパイプラインさせるこ
とができる。 １１．コンテンツ・ネゴシエーションのサポート：プロキシ・キャッシュは、
クライアントのブラウザ、言語、またはその他のクライアントの要求の属性に向
けられた、同一ＵＲＬのオブジェクトの変化型を効率的かつ柔軟にストアするこ
とができる。 １２．汎用適用可能性：オブジェクト・ストアのインターフェースは、充分に
柔軟であり、将来的なメディア・タイプおよびプロトコルに適合することができ
る。
する。特に本明細書では、大きなオブジェクト・ストアにおいて時間効率が高く
かつ空間効率の高い、オブジェクトの格納、取り出しおよびメンテナンスに関連
する方法および装置について説明されている。ここで説明するテクノロジは、高
性能、高負荷の応用のためのキャッシュ・オブジェクト・ストアを提供し、これ
は次に示す一般的な特性を有している。 １．高性能：オブジェクトのストア操作に関して待ち時間が小さく、高いスル
ープットが得られ、かつ多数の同時操作が得られる。 ２．大型キャッシュのサポート：テラバイト台のキャッシュおよび数十億のオ
ブジェクトをサポートし、インターネットの指数関数的なコンテンツの増加レー
トを扱うことができる。 ３．メモリのストレージ空間の効率化：高価な半導体メモリを節約し、効果的
に使用する。 ４．ディスクのストレージ空間の効率化：オブジェクト・ストアの有限なディ
スク容量内に大量のインターネット・オブジェクトのレプリカをストアすること
ができる。 ５．エイリアスの自由度：名前は異なるが、コンテンツが等しい同一オブジェ
クト・コンテンツを有する複数のオブジェクトまたはオブジェクトの変化型は、
オブジェクト・コンテンツが１回だけキャッシュされ、異なる名前の間で共有さ
れる。 ６．マルチメディアの多様性をサポート：数百バイトからメガバイトに至る６
桁にわたるサイズ範囲で多数のタイプの多様なマルチメディア・オブジェクトを
効率的にサポートする。 ７．高速かつ用法を意識したガーベジ・コレクション：有用性の低いオブジェ
クトをオブジェクト・ストアから効率的に削除し、新しいオブジェクトのための
スペースを確保する。 ８．データの一貫性：プログラム上のエラーおよびハードウエアの障害により
データの信頼性を失うことがない。 ９．高速リスタートが可能：時間を要するデータベースまたはファイル・シス
テムのチェック・オペレーションを必要とすることなく、リスタート後数秒内に
オブジェクト・キャッシュが要求に対するサービスを開始することができる。 １０．ストリーミング：大きなオブジェクト全体をメモリ内に置くことなく、
オブジェクト・ストアから遅いクライアントに、効率的にパイプラインさせるこ
とができる。 １１．コンテンツ・ネゴシエーションのサポート：プロキシ・キャッシュは、
クライアントのブラウザ、言語、またはその他のクライアントの要求の属性に向
けられた、同一ＵＲＬのオブジェクトの変化型を効率的かつ柔軟にストアするこ
とができる。 １２．汎用適用可能性：オブジェクト・ストアのインターフェースは、充分に
柔軟であり、将来的なメディア・タイプおよびプロトコルに適合することができ
る。
【００２３】
【発明の要約】以上のニーズおよびそこに示さなかった他のニーズは、本発明
によって解決され、それにおいては、１側面として、情報オブジェクトの名前に
基づくキー値によって識別される情報オブジェクト用のキャッシュ内に、当該キ
ー値に基づくセット・サブキー値を用いて情報オブジェクトをインデクス付けす
るタグ・テーブル、前述のキー値に基づく第２のサブキー値によって当該タグ・
テーブル内のセットにインデクス付けされた複数のブロックを有するディレクト
リ・テーブル、および、当該ディレクトリ・テーブル内のブロックによって参照
されるデータ・ストレージ・エリアを備え、要求のあった情報オブジェクトをサ
ーバのキャッシュからクライアントに配信する方法において：要求された情報オ
ブジェクトを識別する名前を受け取るステップ；前記名前に基づき、複数のサブ
キーからなる固定サイズのキー値を演算するステップ；ディレクトリ・テーブル
内において、前記サブキーをルックアップ・キーとして使用し、前記要求された
情報オブジェクトをルックアップするステップ；および、前記ディレクトリ・テ
ーブルの一致ブロック内に包含されている参照を使用して前記要求された情報オ
ブジェクトのコピーをデータ・ストレージ・エリアから取り出すステップ；を包
含することを特徴とする。
によって解決され、それにおいては、１側面として、情報オブジェクトの名前に
基づくキー値によって識別される情報オブジェクト用のキャッシュ内に、当該キ
ー値に基づくセット・サブキー値を用いて情報オブジェクトをインデクス付けす
るタグ・テーブル、前述のキー値に基づく第２のサブキー値によって当該タグ・
テーブル内のセットにインデクス付けされた複数のブロックを有するディレクト
リ・テーブル、および、当該ディレクトリ・テーブル内のブロックによって参照
されるデータ・ストレージ・エリアを備え、要求のあった情報オブジェクトをサ
ーバのキャッシュからクライアントに配信する方法において：要求された情報オ
ブジェクトを識別する名前を受け取るステップ；前記名前に基づき、複数のサブ
キーからなる固定サイズのキー値を演算するステップ；ディレクトリ・テーブル
内において、前記サブキーをルックアップ・キーとして使用し、前記要求された
情報オブジェクトをルックアップするステップ；および、前記ディレクトリ・テ
ーブルの一致ブロック内に包含されている参照を使用して前記要求された情報オ
ブジェクトのコピーをデータ・ストレージ・エリアから取り出すステップ；を包
含することを特徴とする。
【００２４】 本発明のこの側面の特徴は、前記キャッシュ内の、前記要求さ
れた情報オブジェクトの複数のバージョンのリストから、要求された情報オブジ
ェクトのバージョンを選択するステップ；前記キャッシュ内の、前記要求された
情報オブジェクトの格納場所を、最初のバージョンに関連して前記リスト内にス
トアされたオブジェクト・キーに基づいて識別するステップ；前記格納場所から
前記要求された情報オブジェクトを取り出すステップ；および、取り出した情報
オブジェクトをクライアントに配信するステップ；を含む。
れた情報オブジェクトの複数のバージョンのリストから、要求された情報オブジ
ェクトのバージョンを選択するステップ；前記キャッシュ内の、前記要求された
情報オブジェクトの格納場所を、最初のバージョンに関連して前記リスト内にス
トアされたオブジェクト・キーに基づいて識別するステップ；前記格納場所から
前記要求された情報オブジェクトを取り出すステップ；および、取り出した情報
オブジェクトをクライアントに配信するステップ；を含む。
【００２５】 別の特徴は、情報オブジェクトを連続させて大容量ストレージ
・デバイスにストアするステップを含む。さらに別の特徴は、それぞれの情報オ
ブジェクトを大容量ストレージ・デバイスの連続するプールにストアするステッ
プを含む。さらにまた別の特徴は、それぞれの情報オブジェクトを、前記プール
内のアリーナの１つにストアするステップを含む。さらに別の特徴は、それぞれ
の情報オブジェクトを、前記アリーナから割り当てられた１ないしは複数のフラ
グメントにストアするステップを含む。
・デバイスにストアするステップを含む。さらに別の特徴は、それぞれの情報オ
ブジェクトを大容量ストレージ・デバイスの連続するプールにストアするステッ
プを含む。さらにまた別の特徴は、それぞれの情報オブジェクトを、前記プール
内のアリーナの１つにストアするステップを含む。さらに別の特徴は、それぞれ
の情報オブジェクトを、前記アリーナから割り当てられた１ないしは複数のフラ
グメントにストアするステップを含む。
【００２６】 本発明の別の特徴によれば、情報オブジェクトを含むフラグメ
ントは、それより前のフラグメント・キーからリンクされる。別の特徴は、要求
された情報オブジェクトの、複数のバージョンのそれぞれとともにリストを連続
させてストアするステップ；ブロックのそれぞれに、当該ブロックに関連して要
求された情報オブジェクトのサイズ値であって、リストのストレージ・サイズを
示すサイズ値および情報オブジェクトの複数のバージョンをストアするステップ
；を含み、それにおいてステップ（Ｄ）は、リストおよび複数のバージョンを同
時に読み出すステップを含む。さらに別の特徴は、異なる速度のストリーミング
・データ転送を書き込み集成バッファ内に統合する。
ントは、それより前のフラグメント・キーからリンクされる。別の特徴は、要求
された情報オブジェクトの、複数のバージョンのそれぞれとともにリストを連続
させてストアするステップ；ブロックのそれぞれに、当該ブロックに関連して要
求された情報オブジェクトのサイズ値であって、リストのストレージ・サイズを
示すサイズ値および情報オブジェクトの複数のバージョンをストアするステップ
；を含み、それにおいてステップ（Ｄ）は、リストおよび複数のバージョンを同
時に読み出すステップを含む。さらに別の特徴は、異なる速度のストリーミング
・データ転送を書き込み集成バッファ内に統合する。
【００２７】 本発明のさらに別の特徴によれば、前記情報オブジェクトをス
トアするステップは、別の情報オブジェクトに関してステップ（Ａ）〜（Ｄ）を
実行しつつ同時に、情報オブジェクトを、前記大容量ストレージ・デバイスの連
続した使用可能なストレージ空間内に書き込むステップを含む。
トアするステップは、別の情報オブジェクトに関してステップ（Ａ）〜（Ｄ）を
実行しつつ同時に、情報オブジェクトを、前記大容量ストレージ・デバイスの連
続した使用可能なストレージ空間内に書き込むステップを含む。
【００２８】 また本発明は、前述の側面ならびにその他の側面に従って構成
された装置、コンピュータ・システム、コンピュータ・プログラム・プロダクト
、および搬送波に埋め込まれたコンピュータ・データ信号を包含している。
された装置、コンピュータ・システム、コンピュータ・プログラム・プロダクト
、および搬送波に埋め込まれたコンピュータ・データ信号を包含している。
【００２９】
【好ましい実施例の詳細な説明】次に、情報オブジェクトをキャッシュするた
めの方法および装置について説明する。以下の説明においては、本発明の完全な
理解を提供するため、説明を目的として、各種の具体的な詳細が説明されている
。しかしながら、当業者においては明らかになろうが、これらの特定の詳細を用
いなくとも本発明を実施することは可能である。一方、周知の構造およびデバイ
スについては、ブロック図形式により示し、本発明が不必要に不明瞭になること
を防止している。
めの方法および装置について説明する。以下の説明においては、本発明の完全な
理解を提供するため、説明を目的として、各種の具体的な詳細が説明されている
。しかしながら、当業者においては明らかになろうが、これらの特定の詳細を用
いなくとも本発明を実施することは可能である。一方、周知の構造およびデバイ
スについては、ブロック図形式により示し、本発明が不必要に不明瞭になること
を防止している。
【００３０】 （トラフィック・サーバ） 図２に、プロキシ３０の特定エレメントの一般的な構造をブロック図の形で示
す。一実施例においてプロキシ３０は、トラフィック・サーバと呼ばれ、詳細を
後述するタイプのコンピュータ・ワークステーション上で動作する１ないしは複
数のコンピュータ・プログラムまたはプロセスを含む。クライアント１０ａは、
インターネット２０を介してオブジェクトを求める要求５０をプロキシ３０に送
る。この関係において用語「オブジェクト」は、ネットワーク・リソースもしく
はサーバから配信される情報の任意の離散的エレメントを意味する。オブジェク
トの例としては、ウェブ・ページまたはドキュメント、グラフィック・イメージ
、ファイル、テキスト・ドキュメント、およびウェブ・アプリケーション・プロ
グラムによってプログラム実行間に作成されたオブジェクト、あるいはインター
ネット２０を介してアクセス可能なサーバ上にストアされたその他の要素が挙げ
られる。これとは別に、インターネット以外のネットワークを介してクライアン
ト１０ａがプロキシ３０に接続されることもある。
す。一実施例においてプロキシ３０は、トラフィック・サーバと呼ばれ、詳細を
後述するタイプのコンピュータ・ワークステーション上で動作する１ないしは複
数のコンピュータ・プログラムまたはプロセスを含む。クライアント１０ａは、
インターネット２０を介してオブジェクトを求める要求５０をプロキシ３０に送
る。この関係において用語「オブジェクト」は、ネットワーク・リソースもしく
はサーバから配信される情報の任意の離散的エレメントを意味する。オブジェク
トの例としては、ウェブ・ページまたはドキュメント、グラフィック・イメージ
、ファイル、テキスト・ドキュメント、およびウェブ・アプリケーション・プロ
グラムによってプログラム実行間に作成されたオブジェクト、あるいはインター
ネット２０を介してアクセス可能なサーバ上にストアされたその他の要素が挙げ
られる。これとは別に、インターネット以外のネットワークを介してクライアン
ト１０ａがプロキシ３０に接続されることもある。
【００３１】 到来した要求５０は、プロキシ３０の入力／出力（Ｉ／Ｏ）コ
ア６０に到達する。Ｉ／Ｏコア６０は、プロキシにより受け取られるデータまた
は配信されるデータのレートを調整し、クライアント１０ａとインターネット２
０の間におけるリンクのデータ転送速度に整合させる。好ましい実施例において
は、Ｉ／Ｏコア６０が、プロキシ３０およびインターネット２０に接続される、
入力バッファと出力バッファの間に配置された、循環式に配列されるバケットの
セットとして実装される。プロキシ３０と１ないしは複数のクライアント１０ａ
の間の接続は、これらのバケット内にストアされる。セット内の各バケットは、
連続して調べられ、バケット内の各接続がポーリングされる。ポーリングの間、
最後のポーリング以降に当該接続に関連付けされているバッファ内に蓄積された
情報の量が判断される。この量に基づいて、その接続に関連付けされた周期の値
が調整される。その後、概して現在のバケット数の合計および周期値によって識
別される別のバケット内に接続がストアされる。ポーリングは、次の接続および
次のバケットに続く。このようにして、連続する接続のポーリングの経過時間に
よって、実際の動作帯域幅、つまりその接続のデータ通信速度に自動的に調整さ
れる。
ア６０に到達する。Ｉ／Ｏコア６０は、プロキシにより受け取られるデータまた
は配信されるデータのレートを調整し、クライアント１０ａとインターネット２
０の間におけるリンクのデータ転送速度に整合させる。好ましい実施例において
は、Ｉ／Ｏコア６０が、プロキシ３０およびインターネット２０に接続される、
入力バッファと出力バッファの間に配置された、循環式に配列されるバケットの
セットとして実装される。プロキシ３０と１ないしは複数のクライアント１０ａ
の間の接続は、これらのバケット内にストアされる。セット内の各バケットは、
連続して調べられ、バケット内の各接続がポーリングされる。ポーリングの間、
最後のポーリング以降に当該接続に関連付けされているバッファ内に蓄積された
情報の量が判断される。この量に基づいて、その接続に関連付けされた周期の値
が調整される。その後、概して現在のバケット数の合計および周期値によって識
別される別のバケット内に接続がストアされる。ポーリングは、次の接続および
次のバケットに続く。このようにして、連続する接続のポーリングの経過時間に
よって、実際の動作帯域幅、つまりその接続のデータ通信速度に自動的に調整さ
れる。
【００３２】 Ｉ／Ｏコア６０は、この要求５０を、Ｉ／Ｏコア６０およびキ
ャッシュ８０に接続されたプロトコル・エンジン７０に渡す。プロトコル・エン
ジン７０は、要求５０を構文解釈し、要求５０内に埋め込まれている明文化され
たアクションのタイプを決定する。プロトコル・エンジン７０は、要求５０内の
情報に基づいて特定のオペレーションを実行するコマンドをキャッシュ８０に提
供する。一実施例においては、キャッシュ８０が、アプリケーション・プログラ
ミング・インターフェース（ＡＰＩ）を使用し、プロトコル・エンジン７０にア
クセス可能な１ないしは複数のコンピュータ・プログラム内に実装される。この
実施例の場合は、プロトコル・エンジンが要求５０をデコードし、キャッシュ８
０のＡＰＩに対してファンクション呼び出しを行う。このファンクション呼び出
しには、パラメータ値、要求５０から導き出した情報が含まれる。
ャッシュ８０に接続されたプロトコル・エンジン７０に渡す。プロトコル・エン
ジン７０は、要求５０を構文解釈し、要求５０内に埋め込まれている明文化され
たアクションのタイプを決定する。プロトコル・エンジン７０は、要求５０内の
情報に基づいて特定のオペレーションを実行するコマンドをキャッシュ８０に提
供する。一実施例においては、キャッシュ８０が、アプリケーション・プログラ
ミング・インターフェース（ＡＰＩ）を使用し、プロトコル・エンジン７０にア
クセス可能な１ないしは複数のコンピュータ・プログラム内に実装される。この
実施例の場合は、プロトコル・エンジンが要求５０をデコードし、キャッシュ８
０のＡＰＩに対してファンクション呼び出しを行う。このファンクション呼び出
しには、パラメータ値、要求５０から導き出した情報が含まれる。
【００３３】 キャッシュ８０は、プロトコル・エンジン７０に接続されてそ
れとの間において情報の送受を行い、また不揮発性大容量ストレージ・デバイス
９０ａ〜９０ｎに接続されてそれと双方向通信する。一実施例においては、大容
量ストレージ・デバイス９０ａ〜９０ｎが大容量高速ディスク・ドライブである
。キャッシュ８０は、データ・テーブル８２とも双方向通信するが、それについ
ての詳細は後述する。
れとの間において情報の送受を行い、また不揮発性大容量ストレージ・デバイス
９０ａ〜９０ｎに接続されてそれと双方向通信する。一実施例においては、大容
量ストレージ・デバイス９０ａ〜９０ｎが大容量高速ディスク・ドライブである
。キャッシュ８０は、データ・テーブル８２とも双方向通信するが、それについ
ての詳細は後述する。
【００３４】 （オブジェクト・キャッシュのインデクス化） （コンテンツのインデクス化） 好ましい実施例においては、キャッシュ８０がオブジェクトをストレージ・デ
バイス９０ａ〜９０ｎにストアする。「人気のある」オブジェクトについては、
キャッシュ内にもレプリカが作られる。この好ましい実施例の場合、キャッシュ
のサイズは有限であり、主としてプロキシ３０のメモリまたはＲＡＭにストアさ
れる。
バイス９０ａ〜９０ｎにストアする。「人気のある」オブジェクトについては、
キャッシュ内にもレプリカが作られる。この好ましい実施例の場合、キャッシュ
のサイズは有限であり、主としてプロキシ３０のメモリまたはＲＡＭにストアさ
れる。
【００３５】 ディスク上のオブジェクトは、キーと呼ばれる固定サイズのロ
ケータによってインデクス付けされる。キーは、ディレクトリ内にインデクス付
けするために使用され、ディスク上のオブジェクトの位置および当該オブジェク
トに関するメタデータをポイントする。キーには、それぞれ「名前キー」および
「オブジェクト・キー」と呼ばれる２つのタイプがある。名前キーは、名前付き
オブジェクトに関するメタデータをインデクス付けするために使用され、オブジ
ェクト・キーは、真のオブジェクトのコンテンツをインデクス付けするために使
用される。名前キーは、ＵＲＬならびにその他の情報リソースの名前を、そのオ
ブジェクト・データ用のオブジェクト・キーを含むメタデータ構造に変換するた
めに使用される。次に説明するように、この２レベルのインデクス構造は、複数
の代替オブジェクトを単一の名前に関連付けする機能を容易にする一方、同時に
、あらゆるオブジェクトのコンテンツのコピーを重複させることなくディスク上
で維持し、複数の異なる名前または選択肢の間でそれを共有する。
ケータによってインデクス付けされる。キーは、ディレクトリ内にインデクス付
けするために使用され、ディスク上のオブジェクトの位置および当該オブジェク
トに関するメタデータをポイントする。キーには、それぞれ「名前キー」および
「オブジェクト・キー」と呼ばれる２つのタイプがある。名前キーは、名前付き
オブジェクトに関するメタデータをインデクス付けするために使用され、オブジ
ェクト・キーは、真のオブジェクトのコンテンツをインデクス付けするために使
用される。名前キーは、ＵＲＬならびにその他の情報リソースの名前を、そのオ
ブジェクト・データ用のオブジェクト・キーを含むメタデータ構造に変換するた
めに使用される。次に説明するように、この２レベルのインデクス構造は、複数
の代替オブジェクトを単一の名前に関連付けする機能を容易にする一方、同時に
、あらゆるオブジェクトのコンテンツのコピーを重複させることなくディスク上
で維持し、複数の異なる名前または選択肢の間でそれを共有する。
【００３６】 名前またはＵＲＬをキーとして使用し、それによりオブジェク
トを参照するほかのキャッシュ・システムとは異なり、本発明の実施例は、オブ
ジェクト自体を構成する「指紋」を使用してオブジェクトを見出す。インデクス
済みのオブジェクトのコンテンツから生成されたキーを、ここではオブジェクト
・キーと呼んでいる。厳密に述べれば、オブジェクト・キー５６は、固有の指紋
、つまりオブジェクト５２のコンテンツの圧縮された表現である。好ましくは、
オブジェクト５２のコピーを入力としてハッシュ関数５４に与え、その出力をオ
ブジェクト・キー５６とする。たとえば、オブジェクト５２のファイルもしくは
その他の表現をハッシュ関数の入力として与えると、それが当該ファイルの各バ
イトを読み込み、ファイル全体の読み込みを完了するまで、オブジェクト・キー
５６の一部の生成を繰り返す。このようにしてオブジェクト・キー５６は、その
名前ではなく、オブジェクト５２のコンテンツ全体に基づいて生成される。キー
がコンテンツ・ベースであり、キャッシュ８０のテーブルに対するインデクスと
して機能することから、このキャッシュは、コンテンツ・インデクス付きキャッ
シュと呼ばれる。コンテンツの指紋キーが与えられれば、コンテンツを容易に見
つけることができる。
トを参照するほかのキャッシュ・システムとは異なり、本発明の実施例は、オブ
ジェクト自体を構成する「指紋」を使用してオブジェクトを見出す。インデクス
済みのオブジェクトのコンテンツから生成されたキーを、ここではオブジェクト
・キーと呼んでいる。厳密に述べれば、オブジェクト・キー５６は、固有の指紋
、つまりオブジェクト５２のコンテンツの圧縮された表現である。好ましくは、
オブジェクト５２のコピーを入力としてハッシュ関数５４に与え、その出力をオ
ブジェクト・キー５６とする。たとえば、オブジェクト５２のファイルもしくは
その他の表現をハッシュ関数の入力として与えると、それが当該ファイルの各バ
イトを読み込み、ファイル全体の読み込みを完了するまで、オブジェクト・キー
５６の一部の生成を繰り返す。このようにしてオブジェクト・キー５６は、その
名前ではなく、オブジェクト５２のコンテンツ全体に基づいて生成される。キー
がコンテンツ・ベースであり、キャッシュ８０のテーブルに対するインデクスと
して機能することから、このキャッシュは、コンテンツ・インデクス付きキャッ
シュと呼ばれる。コンテンツの指紋キーが与えられれば、コンテンツを容易に見
つけることができる。
【００３７】 この実施例においては、コンテンツのインデクス化が、キャッ
シュ８０による、名前は異なるが同一のコンテンツを有する複製オブジェクトの
検出を可能にする。まったく同じコンテンツを有するオブジェクトが、異なる名
前を有している場合であっても、ハッシュによりそれらが同一のキー値をもたら
すことから、この種の複製が検出される。
シュ８０による、名前は異なるが同一のコンテンツを有する複製オブジェクトの
検出を可能にする。まったく同じコンテンツを有するオブジェクトが、異なる名
前を有している場合であっても、ハッシュによりそれらが同一のキー値をもたら
すことから、この種の複製が検出される。
【００３８】 たとえばサーバ４０が、あるサブディレクトリ内に、「IE4.ex
e」という名前を付けたサイズが１０メガバイトの実行可能ファイルからなるソ
フトウエア・プログラムをストアしている場合を考える。それにおいて、さらに
サーバ４０が、同一ファイルのコピーに「Internet Explorer.exe」という名前
を付けて別のサブディレクトリ内にストアしているとする。サーバ４０は、匿名
ＦＴＰサーバであり、ＦＴＰプロトコルを使用し、ＨＴＴＰ接続を介してファイ
ルのコピーを配信することができる。過去のアプローチにおいては、１ないしは
複数のクライアントがこれら２つのファイルを要求すると、キャッシュがそれぞ
れのファイルのコピーをキャッシュ・ストレージにストアし、キャッシュ内の各
ファイルをそれぞれの名前を使用してインデクス付けするということが行われて
いる。この結果、キャッシュは、名前を除けばすべてが等しい２つのオブジェク
トのために、２０メガバイトを使用しなければならない。
e」という名前を付けたサイズが１０メガバイトの実行可能ファイルからなるソ
フトウエア・プログラムをストアしている場合を考える。それにおいて、さらに
サーバ４０が、同一ファイルのコピーに「Internet Explorer.exe」という名前
を付けて別のサブディレクトリ内にストアしているとする。サーバ４０は、匿名
ＦＴＰサーバであり、ＦＴＰプロトコルを使用し、ＨＴＴＰ接続を介してファイ
ルのコピーを配信することができる。過去のアプローチにおいては、１ないしは
複数のクライアントがこれら２つのファイルを要求すると、キャッシュがそれぞ
れのファイルのコピーをキャッシュ・ストレージにストアし、キャッシュ内の各
ファイルをそれぞれの名前を使用してインデクス付けするということが行われて
いる。この結果、キャッシュは、名前を除けばすべてが等しい２つのオブジェク
トのために、２０メガバイトを使用しなければならない。
【００３９】 本発明の実施例においては、さらに詳細に述べるが、これらの
オブジェクトのそれぞれについて、キャッシュが名前キーおよびオブジェクト・
キーを作成する。名前キーは、オブジェクトの名前にハッシュ関数を適用するこ
とによって作成される。オブジェクト・キーは、オブジェクトのコンテンツにハ
ッシュ関数を適用することによって作成される。この結果、上記の例に示した２
つのオブジェクトの場合であれば、作成された２つの名前キーは異なるが、オブ
ジェクト・キーは同一になる。最初のオブジェクトをキャッシュ内にストアする
とき、その名前キーおよびオブジェクト・キーをキャッシュ内にストアする。そ
の後２番目のオブジェクトをキャッシュ内にストアするとき、その名前キーをキ
ャッシュ内にストアする。しかしながらキャッシュは、以前のまったく等しいオ
ブジェクト・キーのエントリを検出し、重複するオブジェクト・キーのエントリ
をストアしない；それに代えてキャッシュは、同一のオブジェクト・キーのエン
トリに対する参照を、名前キーに関連させてストアし、新しい冗長なオブジェク
トを削除する。結果的に、オブジェクトのストアに必要となるストレージは１０
メガバイトだけになる。このようにキャッシュは、異なる名前を有するオブジェ
クトの複製を検出し、その種のオブジェクトに対して永続させるコピーを１つだ
けストアする。
オブジェクトのそれぞれについて、キャッシュが名前キーおよびオブジェクト・
キーを作成する。名前キーは、オブジェクトの名前にハッシュ関数を適用するこ
とによって作成される。オブジェクト・キーは、オブジェクトのコンテンツにハ
ッシュ関数を適用することによって作成される。この結果、上記の例に示した２
つのオブジェクトの場合であれば、作成された２つの名前キーは異なるが、オブ
ジェクト・キーは同一になる。最初のオブジェクトをキャッシュ内にストアする
とき、その名前キーおよびオブジェクト・キーをキャッシュ内にストアする。そ
の後２番目のオブジェクトをキャッシュ内にストアするとき、その名前キーをキ
ャッシュ内にストアする。しかしながらキャッシュは、以前のまったく等しいオ
ブジェクト・キーのエントリを検出し、重複するオブジェクト・キーのエントリ
をストアしない；それに代えてキャッシュは、同一のオブジェクト・キーのエン
トリに対する参照を、名前キーに関連させてストアし、新しい冗長なオブジェク
トを削除する。結果的に、オブジェクトのストアに必要となるストレージは１０
メガバイトだけになる。このようにキャッシュは、異なる名前を有するオブジェ
クトの複製を検出し、その種のオブジェクトに対して永続させるコピーを１つだ
けストアする。
【００４０】 図３Ａは、オブジェクト５２用のオブジェクト・キー５６を生
成するために使用されるメカニズムのブロック図を示している。クライアント１
０ａからオブジェクト５２の要求があったが、ここに述べるプロセスを使用して
キャッシュ８０内にそのオブジェクトが見つからないとき、キャッシュはサーバ
からそのオブジェクトを取り出し、キャッシュ内にそのオブジェクトをストアす
るためのオブジェクト・キー５６を生成する。
成するために使用されるメカニズムのブロック図を示している。クライアント１
０ａからオブジェクト５２の要求があったが、ここに述べるプロセスを使用して
キャッシュ８０内にそのオブジェクトが見つからないとき、キャッシュはサーバ
からそのオブジェクトを取り出し、キャッシュ内にそのオブジェクトをストアす
るためのオブジェクト・キー５６を生成する。
【００４１】 ディレクトリは、ディスク上の位置にキーをマップするデータ
構造である。高速ルックアップに備えるためには、ディレクトリのコンテンツの
すべて、もしくはそのほとんどをメモリ内に維持しておくことが望ましい。これ
には、大量のエントリが適当な量のメモリに収まるようにディレクトリのエント
リを小さくする必要がある。また、アクセスの５０％がキャッシュにストアされ
ないと予測されることから、貴重なディスク・シーク時間を費やすことなくキャ
ッシュのミスを迅速に判断したい。この種の迅速なキャッシュミスの最適化は、
実際のデータ転送に少ないディスク・ヘッドの動きをもたらし、成功を導かない
不確かなルックアップを抑える。最後に、ハッシュ・サーチ技法を介してルック
アップを高速にするため、ディレクトリのエントリを固定サイズにする。
構造である。高速ルックアップに備えるためには、ディレクトリのコンテンツの
すべて、もしくはそのほとんどをメモリ内に維持しておくことが望ましい。これ
には、大量のエントリが適当な量のメモリに収まるようにディレクトリのエント
リを小さくする必要がある。また、アクセスの５０％がキャッシュにストアされ
ないと予測されることから、貴重なディスク・シーク時間を費やすことなくキャ
ッシュのミスを迅速に判断したい。この種の迅速なキャッシュミスの最適化は、
実際のデータ転送に少ないディスク・ヘッドの動きをもたらし、成功を導かない
不確かなルックアップを抑える。最後に、ハッシュ・サーチ技法を介してルック
アップを高速にするため、ディレクトリのエントリを固定サイズにする。
【００４２】 キーは、前述の理由から小さく、固定されたサイズとなるよう
に慎重に構成される。さらにキーは、ストレージ効率および迅速なルックアップ
を目的としてサブキーに分割される。キーの小さな一部において相違を検出する
ことにより、迅速にキャッシュミスを識別することができる。この理由から、完
全なキーを収めた完全なディレクトリ・テーブルをサーチする代わりに、「タグ
・テーブル」と呼ばれる小さなサブキーのテーブルを使用して迅速にキャッシュ
ミスのフィルタリングを行う。さらに、大きなビット・ベクトルの統計プロパテ
ィを利用して空間効率の高いキーを作成することが可能であり、それにより小さ
い必要空間を用いて大量のキャッシュ・オブジェクトをサポートすることができ
る。
に慎重に構成される。さらにキーは、ストレージ効率および迅速なルックアップ
を目的としてサブキーに分割される。キーの小さな一部において相違を検出する
ことにより、迅速にキャッシュミスを識別することができる。この理由から、完
全なキーを収めた完全なディレクトリ・テーブルをサーチする代わりに、「タグ
・テーブル」と呼ばれる小さなサブキーのテーブルを使用して迅速にキャッシュ
ミスのフィルタリングを行う。さらに、大きなビット・ベクトルの統計プロパテ
ィを利用して空間効率の高いキーを作成することが可能であり、それにより小さ
い必要空間を用いて大量のキャッシュ・オブジェクトをサポートすることができ
る。
【００４３】 一実施例によれば、オブジェクト・キー５６はセット・サブキ
ー５８およびタグ・サブキー５９からなる。セット・サブキー５８およびタグ・
サブキー５９は、完全なオブジェクト・キー５６を構成するビットのサブセット
を構成する。たとえば、完全なオブジェクト・キー５６が１２８ビットの長さを
有するとき、サブキー５８、５９をそれぞれ１６ビット、２７ビットとし、ある
いは完全なキーの別の任意部分とすることができる。サブキー５８、５９は、後
述する特定の操作に使用され、それにおいてこれらのサブキーは、完全なキーを
使用した場合に近い正確な結果をもたらす。ただしこれにおいて「正確な」とは
、サブキーの使用が、完全なキーの使用時と同程度の頻度でキャッシュ内におけ
るヒットを導くことを意味している。
ー５８およびタグ・サブキー５９からなる。セット・サブキー５８およびタグ・
サブキー５９は、完全なオブジェクト・キー５６を構成するビットのサブセット
を構成する。たとえば、完全なオブジェクト・キー５６が１２８ビットの長さを
有するとき、サブキー５８、５９をそれぞれ１６ビット、２７ビットとし、ある
いは完全なキーの別の任意部分とすることができる。サブキー５８、５９は、後
述する特定の操作に使用され、それにおいてこれらのサブキーは、完全なキーを
使用した場合に近い正確な結果をもたらす。ただしこれにおいて「正確な」とは
、サブキーの使用が、完全なキーの使用時と同程度の頻度でキャッシュ内におけ
るヒットを導くことを意味している。
【００４４】 この精度プロパティは、「滑らかさ(smoothness)」として知ら
れ、ハッシュ関数の特定の好ましいサブセットにおける特性となる。実施例にお
ける使用に適したハッシュ関数の例としてＭＤ５があり、これについてはB. Sch
neier（Ｂ．シュナイザー）著「Applied Cryptography（応用暗号学）」（ニュ
ーヨーク：John Wiley & Sons, Inc.（ジョン・ウィリー・アンド・サンズ・イ
ンク）第２版，１９９６年）の４２９〜４３１ページおよび４３６〜４４１ペー
ジに解説されている。ＭＤ５ハッシュ関数は、任意長を有する入力データ・スト
リームから１２８ビットのキーを生成する。概してＭＤ５ハッシュ関数およびそ
のほかの一方向ハッシュ関数は、暗号分野において、安全なチャンネルを介して
送信する必要のあるメッセージまたはドキュメントのための安全キーを生成する
ために使用される。一般的なハッシュ・テーブルの構成およびサーチ技法につい
ては、D. Knuth（Ｄ．クナス）著「The Art of Computer Programming（コンピ
ュータ・プログラミングの技法）第３巻，Sorting and Searching（ソーティン
グおよびサーチ）」（マサチューセッツ州レディング：Addison-Wesley（アディ
ソン‐ウェズレー）１９７３年）の５０６〜５４９ページに詳しい解説がある。
れ、ハッシュ関数の特定の好ましいサブセットにおける特性となる。実施例にお
ける使用に適したハッシュ関数の例としてＭＤ５があり、これについてはB. Sch
neier（Ｂ．シュナイザー）著「Applied Cryptography（応用暗号学）」（ニュ
ーヨーク：John Wiley & Sons, Inc.（ジョン・ウィリー・アンド・サンズ・イ
ンク）第２版，１９９６年）の４２９〜４３１ページおよび４３６〜４４１ペー
ジに解説されている。ＭＤ５ハッシュ関数は、任意長を有する入力データ・スト
リームから１２８ビットのキーを生成する。概してＭＤ５ハッシュ関数およびそ
のほかの一方向ハッシュ関数は、暗号分野において、安全なチャンネルを介して
送信する必要のあるメッセージまたはドキュメントのための安全キーを生成する
ために使用される。一般的なハッシュ・テーブルの構成およびサーチ技法につい
ては、D. Knuth（Ｄ．クナス）著「The Art of Computer Programming（コンピ
ュータ・プログラミングの技法）第３巻，Sorting and Searching（ソーティン
グおよびサーチ）」（マサチューセッツ州レディング：Addison-Wesley（アディ
ソン‐ウェズレー）１９７３年）の５０６〜５４９ページに詳しい解説がある。
【００４５】 （名前のインデクス化） 残念ながら、一般にはオブジェクトの要求において、要求オブジェクトの識別
に、そのオブジェクト用のオブジェクト・キーが使用されることがない。むしろ
要求は、通常、名前によって要求オブジェクトを識別する。名前のフォーマット
は、キャッシュが使用される環境に応じて実装ごとに異なることがある。たとえ
ば、オブジェクト名にファイル・システムの名前、ネットワーク・アドレス、あ
るいはＵＲＬが使用されることもある。
に、そのオブジェクト用のオブジェクト・キーが使用されることがない。むしろ
要求は、通常、名前によって要求オブジェクトを識別する。名前のフォーマット
は、キャッシュが使用される環境に応じて実装ごとに異なることがある。たとえ
ば、オブジェクト名にファイル・システムの名前、ネットワーク・アドレス、あ
るいはＵＲＬが使用されることもある。
【００４６】 本発明の一側面によれば、要求オブジェクト用のオブジェクト
・キーが、オブジェクト名に基づいて生成された「名前キー」の下にインデクス
付けされる。つまり、要求に応答したオブジェクトの取り出しは、２段階プロセ
スとなり、それにおいては名前キーがオブジェクト・キーの発見に使用され、オ
ブジェクト・キーがオブジェクトそのものの発見に使用される。
・キーが、オブジェクト名に基づいて生成された「名前キー」の下にインデクス
付けされる。つまり、要求に応答したオブジェクトの取り出しは、２段階プロセ
スとなり、それにおいては名前キーがオブジェクト・キーの発見に使用され、オ
ブジェクト・キーがオブジェクトそのものの発見に使用される。
【００４７】 図３Ｂは、オブジェクト名５３に基づいて名前キー６２を生成
するとき使用されるメカニズムを示したブロック図である。一実施例によれば、
オブジェクト・キーに使用したものと同じハッシュ関数５４が名前キーの生成に
使用される。したがって、名前キーは、オブジェクト・キーと同じ長さおよび滑
らかさ特性を有することになる。
するとき使用されるメカニズムを示したブロック図である。一実施例によれば、
オブジェクト・キーに使用したものと同じハッシュ関数５４が名前キーの生成に
使用される。したがって、名前キーは、オブジェクト・キーと同じ長さおよび滑
らかさ特性を有することになる。
【００４８】 オブジェクト・キー５６と同様に、名前キー６２もセット・サ
ブキー６４およびタグ・サブキー６６からなる。サブキー６４、６６は、完全な
名前キー６２を構成するビットのサブセットを構成する。たとえば、完全な名前
キー６２が１２８ビットの長さを有するとき、第１および第２のサブキー６４、
６６をそれぞれ１６ビット、２７ビットとし、あるいは完全なキーの別の任意部
分とすることができる。
ブキー６４およびタグ・サブキー６６からなる。サブキー６４、６６は、完全な
名前キー６２を構成するビットのサブセットを構成する。たとえば、完全な名前
キー６２が１２８ビットの長さを有するとき、第１および第２のサブキー６４、
６６をそれぞれ１６ビット、２７ビットとし、あるいは完全なキーの別の任意部
分とすることができる。
【００４９】 （オブジェクト・キーまたは名前キーによるサーチ） 好ましくはキャッシュ８０が、コンピュータ・システムのメモリまたはその不
揮発性ストレージ、たとえばディスク等にストアされる特定のデータ構造からな
るものとする。図４は、キャッシュ８０の概略の構成を示すブロック図である。
キャッシュ８０は、概してタグ・テーブル１０２、ディレクトリ・テーブル１１
０、オープン・ディレクトリ・テーブル１３０、および一連のプール２００ａ〜
２００ｎを含み、次に詳細を述べるように論理参照を使用して互いに連結されて
いる。
揮発性ストレージ、たとえばディスク等にストアされる特定のデータ構造からな
るものとする。図４は、キャッシュ８０の概略の構成を示すブロック図である。
キャッシュ８０は、概してタグ・テーブル１０２、ディレクトリ・テーブル１１
０、オープン・ディレクトリ・テーブル１３０、および一連のプール２００ａ〜
２００ｎを含み、次に詳細を述べるように論理参照を使用して互いに連結されて
いる。
【００５０】 タグ・テーブル１０２およびディレクトリ・テーブル１１０は
、セット連想ハッシュ・テーブル(set associative hash tables)として組織化
されている。タグ・テーブル１０２、ディレクトリ・テーブル１１０、およびオ
ープン・ディレクトリ・テーブル１３０は、図２に示したテーブル８２に対応し
ている。ここでは説明の便宜から、インデクス・サーチがオブジェクト・キー５
６に基づいて実行されるものとする。しかしながらタグ・テーブル１０２および
ディレクトリ・テーブル１１０は、名前キー６２に基づいて検索を行った場合に
も同じ態様において動作する。
、セット連想ハッシュ・テーブル(set associative hash tables)として組織化
されている。タグ・テーブル１０２、ディレクトリ・テーブル１１０、およびオ
ープン・ディレクトリ・テーブル１３０は、図２に示したテーブル８２に対応し
ている。ここでは説明の便宜から、インデクス・サーチがオブジェクト・キー５
６に基づいて実行されるものとする。しかしながらタグ・テーブル１０２および
ディレクトリ・テーブル１１０は、名前キー６２に基づいて検索を行った場合に
も同じ態様において動作する。
【００５１】 タグ・テーブル１０２は、セット１０４ａ、１０４ｂ、．．．
１０４ｎのセット連想配列である。タグ・テーブルは、メイン・メモリに収まる
程度に充分小ささく設計されている。この目的は迅速にキャッシュミスを検出す
ることであり、キーを構成するビットの小さなサブセットのみを用いて、キーが
キャッシュ内にストアされていないことを判断できるようにする。なお、１０４
ｎという表示は、タグ・テーブル１０２内に必要なセット数が特定されていない
ことを示している。セット１０４ｎの例に示されているように、各セット１０４
ａ〜１０４ｎは、複数のブロック１０６からなる。
１０４ｎのセット連想配列である。タグ・テーブルは、メイン・メモリに収まる
程度に充分小ささく設計されている。この目的は迅速にキャッシュミスを検出す
ることであり、キーを構成するビットの小さなサブセットのみを用いて、キーが
キャッシュ内にストアされていないことを判断できるようにする。なお、１０４
ｎという表示は、タグ・テーブル１０２内に必要なセット数が特定されていない
ことを示している。セット１０４ｎの例に示されているように、各セット１０４
ａ〜１０４ｎは、複数のブロック１０６からなる。
【００５２】 好ましい実施例においては、オブジェクト・キー５６が１２８
ビットの長さを有する。セット・サブキー５８は、セット１０４ａ〜１０４ｎの
１つを識別して選択するために使用される。好ましくは、セット・サブキー５８
の長さを概略で１８ビットとする。タグ・サブキー５９は、選択したセット内の
エントリ１０６の１つを参照するために使用される。好ましくは、タグ・サブキ
ー５９の長さを概略で１６ビットとするが、多くのセットが存在する場合には、
ゼロ・ビットまで小さくすることができる。その場合、タグ・テーブルがビット
・ベクトルになる。
ビットの長さを有する。セット・サブキー５８は、セット１０４ａ〜１０４ｎの
１つを識別して選択するために使用される。好ましくは、セット・サブキー５８
の長さを概略で１８ビットとする。タグ・サブキー５９は、選択したセット内の
エントリ１０６の１つを参照するために使用される。好ましくは、タグ・サブキ
ー５９の長さを概略で１６ビットとするが、多くのセットが存在する場合には、
ゼロ・ビットまで小さくすることができる。その場合、タグ・テーブルがビット
・ベクトルになる。
【００５３】 エレメントの識別もしくは参照に使用されるメカニズムは、実
装ごとに異なることがあり、連想参照、ポインタ、またはこれらの組み合わせを
含んでいることもある。このため「参照」という用語は、あるエレメントが別の
エレメントを識別もしくは参照することを示す。残余サブキー５６'は、キー５
６の残りのビットからなる。これらのセット・サブキー、タグ・サブキー、およ
び残余サブキーを、それぞれｓ、ｔ、およびｒを用いて表すこともある。
装ごとに異なることがあり、連想参照、ポインタ、またはこれらの組み合わせを
含んでいることもある。このため「参照」という用語は、あるエレメントが別の
エレメントを識別もしくは参照することを示す。残余サブキー５６'は、キー５
６の残りのビットからなる。これらのセット・サブキー、タグ・サブキー、およ
び残余サブキーを、それぞれｓ、ｔ、およびｒを用いて表すこともある。
【００５４】 各エントリが比較的小さい情報量を含むタグ・テーブル１０２
の好ましい構造においては、ＲＡＭ等の揮発性メイン・メモリにタグ・テーブル
を高速にストアすることが可能になる。したがってこのタグ・テーブル１０２の
構造は、キャッシュの迅速な動作を促進する。一方、ディレクトリ・テーブル１
１０内のブロックは、以下述べるようにはるかに多くの情報を含んでおり、結局
ディレクトリ・テーブルの一部は、高速なＤＲＡＭメモリとは対照的となる磁気
ディスク・媒体上に常駐することになる。
の好ましい構造においては、ＲＡＭ等の揮発性メイン・メモリにタグ・テーブル
を高速にストアすることが可能になる。したがってこのタグ・テーブル１０２の
構造は、キャッシュの迅速な動作を促進する。一方、ディレクトリ・テーブル１
１０内のブロックは、以下述べるようにはるかに多くの情報を含んでおり、結局
ディレクトリ・テーブルの一部は、高速なＤＲＡＭメモリとは対照的となる磁気
ディスク・媒体上に常駐することになる。
【００５５】ディレクトリ・テーブル１１０は、複数のセット１１０ａ〜１
１０ｎを包含している。各セット１１０ａ〜１１０ｎは固定されたサイズを有し
、それぞれは複数のブロック１１２ａ〜１１２ｎからなる。好ましい実施例にお
いては、あらかじめ決定済みの一定数のセットが存在し、各セット内にはあらか
じめ決定済みの一定数のブロックが存在する。ブロック１１２ｎの例に示される
ように、ブロック１１２ａ〜１１２ｎのそれぞれは、第３の、残余サブキー値１
１６、ディスク・ロケーション値１１８、およびサイズ値１２０をストアしてい
る。この好ましい実施例においては、残余サブキー値１１６が、１２８ビットの
完全なオブジェクト・キー５６の２７ビット部分であり、セット・サブキー５８
またはタグ・サブキー５９を構成するビットと互いに素となって、完全なオブジ
ェクト・キー５６のビットを構成する。
１０ｎを包含している。各セット１１０ａ〜１１０ｎは固定されたサイズを有し
、それぞれは複数のブロック１１２ａ〜１１２ｎからなる。好ましい実施例にお
いては、あらかじめ決定済みの一定数のセットが存在し、各セット内にはあらか
じめ決定済みの一定数のブロックが存在する。ブロック１１２ｎの例に示される
ように、ブロック１１２ａ〜１１２ｎのそれぞれは、第３の、残余サブキー値１
１６、ディスク・ロケーション値１１８、およびサイズ値１２０をストアしてい
る。この好ましい実施例においては、残余サブキー値１１６が、１２８ビットの
完全なオブジェクト・キー５６の２７ビット部分であり、セット・サブキー５８
またはタグ・サブキー５９を構成するビットと互いに素となって、完全なオブジ
ェクト・キー５６のビットを構成する。
【００５６】 サーチにおいては、図４においてエントリ１０６をセット１１
０ｄに接続する矢印により示されるように、タグ・テーブル１０２のエントリ内
にストアされているサブキー値がセット１１０ａ〜１１０ｎの１つに一致するか
、それを参照する。一例として、前述したような１２ビットのキーおよび４ビッ
トの第１および第２のサブキーを考える。ここで、セット・サブキー値「１１１
１」がタグ・テーブル１０２のセット１０４ｎに一致し、タグ・サブキー値「０
０００」がセット１０４ｎのエントリ１０６に一致したとする。タグ・サブキー
値「００００」の一致は、キー・プレフィクス「１１１１００００」に関連付け
されたディレクトリ・テーブル１１０のセット１１０ｄ内に、対応するエントリ
が存在することを示す。このようにしてセット１１０ａ〜１１０ｎの１つを選択
すると、選択したセット内のブロックの線形サーチを行って、ブロック１１２ａ
等の、オブジェクト・キー５６の対応する部分に一致する残余サブキー値１１６
を含むブロックを見つけ出す。一致が見つかると、ほとんど必ずキャッシュ内に
ヒットが存在すると言える。ただし第１、第２および第３のサブキーが完全なキ
ーを構成しないときは、わずかではあるがミスの可能性がある。ヒットがあると
、ブロックに含まれている情報に基づいて参照オブジェクトを見つけ出し、スト
レージ・デバイス９０ａ〜９０ｎの１つからそれを取り出し、クライアント１０
ａに提供するが、それについては後述する。
０ｄに接続する矢印により示されるように、タグ・テーブル１０２のエントリ内
にストアされているサブキー値がセット１１０ａ〜１１０ｎの１つに一致するか
、それを参照する。一例として、前述したような１２ビットのキーおよび４ビッ
トの第１および第２のサブキーを考える。ここで、セット・サブキー値「１１１
１」がタグ・テーブル１０２のセット１０４ｎに一致し、タグ・サブキー値「０
０００」がセット１０４ｎのエントリ１０６に一致したとする。タグ・サブキー
値「００００」の一致は、キー・プレフィクス「１１１１００００」に関連付け
されたディレクトリ・テーブル１１０のセット１１０ｄ内に、対応するエントリ
が存在することを示す。このようにしてセット１１０ａ〜１１０ｎの１つを選択
すると、選択したセット内のブロックの線形サーチを行って、ブロック１１２ａ
等の、オブジェクト・キー５６の対応する部分に一致する残余サブキー値１１６
を含むブロックを見つけ出す。一致が見つかると、ほとんど必ずキャッシュ内に
ヒットが存在すると言える。ただし第１、第２および第３のサブキーが完全なキ
ーを構成しないときは、わずかではあるがミスの可能性がある。ヒットがあると
、ブロックに含まれている情報に基づいて参照オブジェクトを見つけ出し、スト
レージ・デバイス９０ａ〜９０ｎの１つからそれを取り出し、クライアント１０
ａに提供するが、それについては後述する。
【００５７】 ＲＡＭメモリの使用を最小に抑えて迅速にミスを除外すること
を役割とするタグ・テーブルと異なり、ディレクトリ・テーブル１１０内の各ブ
ロックは、ディスク・ロケーションに対する完全なポインタを包含している。デ
ィスク・ロケーション値１１８によって参照されるアイテムは、キーが生成され
たソースによって異なる。前述のようにオブジェクトのコンテンツに基づいて生
成されたキーの場合には、ディスク・ロケーション値１１８が、図４においてブ
ロック１１２ｂのキャッシュ内のストア済みオブジェクト１２４として示されて
ように、その（もしくはその最初のフラグメントの）位置を表す。キーが名前キ
ーの場合には、ブロック１１２ｎとして示されるように、ディスク・ロケーショ
ン値１１８は、１ないしは複数の選択肢のベクトル１２２の位置を示し、そのそ
れぞれは、名前キーの生成に使用した名前を持ったオブジェクトに対応する１な
いしは複数のオブジェクト・キーをストアしている。図４には、例として単一の
タグ・テーブル１０２および単一のディレクトリ・テーブル１１０を示した。し
かしながら、追加のストレージならびにインデクスのレベルを提供する追加のテ
ーブルを使用する別の実施例も考えられる。
を役割とするタグ・テーブルと異なり、ディレクトリ・テーブル１１０内の各ブ
ロックは、ディスク・ロケーションに対する完全なポインタを包含している。デ
ィスク・ロケーション値１１８によって参照されるアイテムは、キーが生成され
たソースによって異なる。前述のようにオブジェクトのコンテンツに基づいて生
成されたキーの場合には、ディスク・ロケーション値１１８が、図４においてブ
ロック１１２ｂのキャッシュ内のストア済みオブジェクト１２４として示されて
ように、その（もしくはその最初のフラグメントの）位置を表す。キーが名前キ
ーの場合には、ブロック１１２ｎとして示されるように、ディスク・ロケーショ
ン値１１８は、１ないしは複数の選択肢のベクトル１２２の位置を示し、そのそ
れぞれは、名前キーの生成に使用した名前を持ったオブジェクトに対応する１な
いしは複数のオブジェクト・キーをストアしている。図４には、例として単一の
タグ・テーブル１０２および単一のディレクトリ・テーブル１１０を示した。し
かしながら、追加のストレージならびにインデクスのレベルを提供する追加のテ
ーブルを使用する別の実施例も考えられる。
【００５８】 好ましい構成においては、キャッシュのサーチを行うとき、タ
グ・テーブル１０２内で非常に迅速にヒットもしくはミスが得られる。タグ・テ
ーブル１０２内にヒットが存在するときは、非常に高い確率で対応するエントリ
がディレクトリ・テーブル１１０内に存在する。この高い確率は、タグ・テーブ
ル１０２内のヒットが、キャッシュがオブジェクト、つまりその完全なキーが、
受け取ったキーとまったく等しいＸビットを共有しているオブジェクトを保持し
ていることを意味するという事実からもたらされ、それにおいてＸは、セット・
サブキー５８とタグ・サブキー５９を連結したビット数である。ミスが迅速に識
別され得ることから、またディレクトリ・テーブル１１０全体をメイン・メモリ
内に常駐させることを必要とせずにヒットおよびミスがメモリ内のタグ・テーブ
ル１０２を使用して迅速に検出されることから、キャッシュ８０が高速かつ効率
的に動作する。
グ・テーブル１０２内で非常に迅速にヒットもしくはミスが得られる。タグ・テ
ーブル１０２内にヒットが存在するときは、非常に高い確率で対応するエントリ
がディレクトリ・テーブル１１０内に存在する。この高い確率は、タグ・テーブ
ル１０２内のヒットが、キャッシュがオブジェクト、つまりその完全なキーが、
受け取ったキーとまったく等しいＸビットを共有しているオブジェクトを保持し
ていることを意味するという事実からもたらされ、それにおいてＸは、セット・
サブキー５８とタグ・サブキー５９を連結したビット数である。ミスが迅速に識
別され得ることから、またディレクトリ・テーブル１１０全体をメイン・メモリ
内に常駐させることを必要とせずにヒットおよびミスがメモリ内のタグ・テーブ
ル１０２を使用して迅速に検出されることから、キャッシュ８０が高速かつ効率
的に動作する。
【００５９】 キャッシュをオブジェクト・キー５６に基づいてサーチする場
合、セット・サブキー５８を使用してタグ・テーブル１０２内のセット１０４ａ
〜１０４ｎの１つをインデクス付けする。セット・サブキー５８に関連付けされ
たセットを識別した後は、セット内のエレメントに対する線形サーチを行って、
タグがタグ・サブキー５９に一致するエントリを識別する。
合、セット・サブキー５８を使用してタグ・テーブル１０２内のセット１０４ａ
〜１０４ｎの１つをインデクス付けする。セット・サブキー５８に関連付けされ
たセットを識別した後は、セット内のエレメントに対する線形サーチを行って、
タグがタグ・サブキー５９に一致するエントリを識別する。
【００６０】 キャッシュ８０からクライアント１０ａによって要求されたオ
ブジェクト５２を求めるサーチにおいては、セット・サブキー５８を用いてセッ
ト１０４ａ〜１０４ｎの１つを選択すると、そのセット内の全エレメント１０６
に対する線形サーチを実行する。このサーチは、タグ・サブキー５９とエントリ
の１つとの一致を求める。一致が見つかると、要求オブジェクトに関してタグ・
テーブル１０２内にヒットが存在することになり、キャッシュ８０は、先に進ん
でディレクトリ・テーブル１１０内のヒットを求める。
ブジェクト５２を求めるサーチにおいては、セット・サブキー５８を用いてセッ
ト１０４ａ〜１０４ｎの１つを選択すると、そのセット内の全エレメント１０６
に対する線形サーチを実行する。このサーチは、タグ・サブキー５９とエントリ
の１つとの一致を求める。一致が見つかると、要求オブジェクトに関してタグ・
テーブル１０２内にヒットが存在することになり、キャッシュ８０は、先に進ん
でディレクトリ・テーブル１１０内のヒットを求める。
【００６１】 ここで説明のために、オブジェクト・キーを、値「１１１１０
０００１０１０」を有する１２ビットのキーとし、セット・サブキーをオブジェ
クト・キーの最初の４ビット、つまり値「１１１１」からなるものとし、タグ・
サブキーをオブジェクト・キーの次の４ビット、つまり値「００００」からなる
ものとする。実際の使用においては、残余ビットがセット・ビットおよびタグ・
ビットよりはるかに大きくなり、メモリの節約に影響を及ぼす。キャッシュは、
セット「１５（１１１１）」を、タグ・テーブル１０２を調べるためのセットと
して識別する。キャッシュは、そのセット内の、タグ「００００」を含むエント
リをサーチする。その種のエントリが存在しなければ、タグ・テーブル１０２内
においてミスが発生する。その種のエントリが存在すれば、キャッシュは、ディ
レクトリ・テーブル１１０内の残りのビットの一致についてチェックする。
０００１０１０」を有する１２ビットのキーとし、セット・サブキーをオブジェ
クト・キーの最初の４ビット、つまり値「１１１１」からなるものとし、タグ・
サブキーをオブジェクト・キーの次の４ビット、つまり値「００００」からなる
ものとする。実際の使用においては、残余ビットがセット・ビットおよびタグ・
ビットよりはるかに大きくなり、メモリの節約に影響を及ぼす。キャッシュは、
セット「１５（１１１１）」を、タグ・テーブル１０２を調べるためのセットと
して識別する。キャッシュは、そのセット内の、タグ「００００」を含むエント
リをサーチする。その種のエントリが存在しなければ、タグ・テーブル１０２内
においてミスが発生する。その種のエントリが存在すれば、キャッシュは、ディ
レクトリ・テーブル１１０内の残りのビットの一致についてチェックする。
【００６２】 （マルチレベル・ディレクトリ・テーブル） 一実施例においては、ディレクトリ・テーブル１１０が、それぞれが固定数の
エレメントからなる複数のセットを含んでいる。各エレメントは、残余タグおよ
びディスク・ポインタを含む。大きなキャッシュは大量のオブジェクトを含み、
それによりディレクトリ・テーブル内に多数のエレメントが必要になる。これに
よってテーブルが非常に大きくなり、メイン・メモリ内においてコスト効果に関
して有利なストアが得られなくなる。
エレメントからなる複数のセットを含んでいる。各エレメントは、残余タグおよ
びディスク・ポインタを含む。大きなキャッシュは大量のオブジェクトを含み、
それによりディレクトリ・テーブル内に多数のエレメントが必要になる。これに
よってテーブルが非常に大きくなり、メイン・メモリ内においてコスト効果に関
して有利なストアが得られなくなる。
【００６３】 たとえば、キャッシュが１億２８００万のディレクトリ・テー
ブル・エントリからなり、それぞれのエレメントが控えめ値として８バイトのス
トレージによって表されるとき、ディレクトリ・テーブルのストアに１ギガバイ
トのメモリが必要になるが、これは現在のワークステーション・コンピュータに
一般的なメモリ容量を超えている。これらのオブジェクトのうち、実際に常時ア
クセスされるものがほとんどないことから、頻繁に使用されるエントリをメイン
・メモリ上に残し、使用頻度の低いエントリをディスクに移動することが望まし
い。
ブル・エントリからなり、それぞれのエレメントが控えめ値として８バイトのス
トレージによって表されるとき、ディレクトリ・テーブルのストアに１ギガバイ
トのメモリが必要になるが、これは現在のワークステーション・コンピュータに
一般的なメモリ容量を超えている。これらのオブジェクトのうち、実際に常時ア
クセスされるものがほとんどないことから、頻繁に使用されるエントリをメイン
・メモリ上に残し、使用頻度の低いエントリをディスクに移動することが望まし
い。
【００６４】 図４Ｃに、マルチレベル・ディレクトリ・メカニズムのブロッ
ク図を示す。ディレクトリ・テーブル１１０は、セグメント１１１ａ、１１１ｂ
、１１１ｃに分割されている。好ましい実施例においては、２ないしは３のセグ
メント１１１ａ〜１１１ｃが存在するが、それより多くのセグメントを使用して
もよい。最初のセグメント１１１ａはもっとも小さく、図１１に示した、詳細を
後述するコンピュータ・システムのメイン・メモリ１１０６等のメイン・メモリ
に適合する。第２および第３のセグメント１１１ｂ、１１１ｃは、順次大きくな
る。第２および第３のセグメント１１１ｂ、１１１ｃは、ページング・メカニズ
ムを介してディスク等の大容量ストレージ・デバイス１１１０に結合される。第
２および第３のセグメント１１１ｂ、１１１ｃは、要求データがメイン・メモリ
１１０６内に存在しないとき、ディスクとの間で動的にデータのページングを行
う。
ク図を示す。ディレクトリ・テーブル１１０は、セグメント１１１ａ、１１１ｂ
、１１１ｃに分割されている。好ましい実施例においては、２ないしは３のセグ
メント１１１ａ〜１１１ｃが存在するが、それより多くのセグメントを使用して
もよい。最初のセグメント１１１ａはもっとも小さく、図１１に示した、詳細を
後述するコンピュータ・システムのメイン・メモリ１１０６等のメイン・メモリ
に適合する。第２および第３のセグメント１１１ｂ、１１１ｃは、順次大きくな
る。第２および第３のセグメント１１１ｂ、１１１ｃは、ページング・メカニズ
ムを介してディスク等の大容量ストレージ・デバイス１１１０に結合される。第
２および第３のセグメント１１１ｂ、１１１ｃは、要求データがメイン・メモリ
１１０６内に存在しないとき、ディスクとの間で動的にデータのページングを行
う。
【００６５】 より頻繁にディレクトリ・エレメントがアクセスされるときは
、ディレクトリ・エレメントが、マルチレベル・ディレクトリのセグメント１１
１ａ〜１１１ｃの中を逐次より高いセグメントへと移動する。つまり、頻繁にア
クセスされたディレクトリ・エレメントは、メイン・メモリ１１０６内にストア
される可能性がより高くなる。もっとも「人気のある」エレメントは、ディレク
トリ内のもっとも高く、もっとも小さいセグメント１１１ａに現れ、常時メイン
・メモリ１１０６内に存在することになる。エントリの「人気」は、長さが数ビ
ットの小さいカウンタによって追跡される。このカウンタは、「スケーリング付
きカウンタの更新」セクションににおいて説明しているように更新される。この
マルチレベル・ディレクトリは、メモリ内ハッシュ・テーブルのパフォーマンス
に近く、その一方でアクティブでないエレメントをディスク上に置くことによっ
て、テラバイト・サイズのキャッシュに代わるコスト効果の高い総合ストレージ
容量を提供する。
、ディレクトリ・エレメントが、マルチレベル・ディレクトリのセグメント１１
１ａ〜１１１ｃの中を逐次より高いセグメントへと移動する。つまり、頻繁にア
クセスされたディレクトリ・エレメントは、メイン・メモリ１１０６内にストア
される可能性がより高くなる。もっとも「人気のある」エレメントは、ディレク
トリ内のもっとも高く、もっとも小さいセグメント１１１ａに現れ、常時メイン
・メモリ１１０６内に存在することになる。エントリの「人気」は、長さが数ビ
ットの小さいカウンタによって追跡される。このカウンタは、「スケーリング付
きカウンタの更新」セクションににおいて説明しているように更新される。この
マルチレベル・ディレクトリは、メモリ内ハッシュ・テーブルのパフォーマンス
に近く、その一方でアクティブでないエレメントをディスク上に置くことによっ
て、テラバイト・サイズのキャッシュに代わるコスト効果の高い総合ストレージ
容量を提供する。
【００６６】 （ディレクトリのページング） すでに述べたように、好ましい実施例においては、ディレクトリ・テーブル１
１０がマルチレベルのハッシュ・テーブルとして実装される。ディレクトリ・テ
ーブルの一部はメイン・メモリの外、つまりディスク上に常駐することもある。
ディレクトリ・テーブル用のデータは、要求に応じてディスクに、またディスク
からページングされる。このメカニズムの好ましい実施例は、ダイレクト・ディ
スクＩ／Ｏを使用してディスクへのページングならびにディスクからのページン
グを行うタイミング、およびページングする情報量を慎重にコントロールしてい
る。
１０がマルチレベルのハッシュ・テーブルとして実装される。ディレクトリ・テ
ーブルの一部はメイン・メモリの外、つまりディスク上に常駐することもある。
ディレクトリ・テーブル用のデータは、要求に応じてディスクに、またディスク
からページングされる。このメカニズムの好ましい実施例は、ダイレクト・ディ
スクＩ／Ｏを使用してディスクへのページングならびにディスクからのページン
グを行うタイミング、およびページングする情報量を慎重にコントロールしてい
る。
【００６７】 このアプローチの別の実施例においては、ＵＮＩＸタイプのオ
ペレーティング・システムの機能を利用して、ファイルを直接仮想メモリ・セグ
メントにマップする。このアプローチの場合、キャッシュがＵＮＩＸのmmap()機
能を使用してディレクトリ・テーブルを仮想メモリ内にマップする。たとえば、
ファイルもしくはディスクの位置に対するポインタをパラメータとして伴うmmap
要求がオペレーティング・システムに与えられる。mmap要求は、参照されたファ
イルもしくはディスクの位置をメモリ位置にマップする要求として機能する。そ
の後オペレーティング・システムは、必要に応じて、参照されたファイルもしく
はディスクの位置の部分をディスクからメモリに自動的にロードする。
ペレーティング・システムの機能を利用して、ファイルを直接仮想メモリ・セグ
メントにマップする。このアプローチの場合、キャッシュがＵＮＩＸのmmap()機
能を使用してディレクトリ・テーブルを仮想メモリ内にマップする。たとえば、
ファイルもしくはディスクの位置に対するポインタをパラメータとして伴うmmap
要求がオペレーティング・システムに与えられる。mmap要求は、参照されたファ
イルもしくはディスクの位置をメモリ位置にマップする要求として機能する。そ
の後オペレーティング・システムは、必要に応じて、参照されたファイルもしく
はディスクの位置の部分をディスクからメモリに自動的にロードする。
【００６８】 さらに、メモリ位置が更新され、もしくはアクセスされると、
そのオブジェクトのメモリ・バージョンが必要に応じてディスクに書き戻される
。このようにして、ネイティブ・オペレーティング・システム・メカニズムを使
用し、不揮発性デバイス内においてテーブルのバックアップ・ストレージを管理
する。しかしながら、メイン・メモリ内に常時存在するのは、通常、ディレクト
リ・テーブル１１０の一部だけとなる。
そのオブジェクトのメモリ・バージョンが必要に応じてディスクに書き戻される
。このようにして、ネイティブ・オペレーティング・システム・メカニズムを使
用し、不揮発性デバイス内においてテーブルのバックアップ・ストレージを管理
する。しかしながら、メイン・メモリ内に常時存在するのは、通常、ディレクト
リ・テーブル１１０の一部だけとなる。
【００６９】 典型的な実施例においては、ディレクトリ・テーブルおよびオ
ープン・ディレクトリは、「ストライピング」技法を使用してストアされる。テ
ーブルの各セットは、異なる物理的ディスク・ドライブ上にストアされる。たと
えば、ディレクトリ・テーブル１１０のセット１１０ａがストレージ・デバイス
９０ａにストアされ、セット１１０ｂがストレージ・デバイス１１０ｂにストア
されるといった形になる。この構成においては、セットに到達するまでのディス
ク・ドライブ・ヘッドに必要なシーク・オペレーションの数が抑えられ、その結
果、キャッシュの速度ならびに効率が向上する。
ープン・ディレクトリは、「ストライピング」技法を使用してストアされる。テ
ーブルの各セットは、異なる物理的ディスク・ドライブ上にストアされる。たと
えば、ディレクトリ・テーブル１１０のセット１１０ａがストレージ・デバイス
９０ａにストアされ、セット１１０ｂがストレージ・デバイス１１０ｂにストア
されるといった形になる。この構成においては、セットに到達するまでのディス
ク・ドライブ・ヘッドに必要なシーク・オペレーションの数が抑えられ、その結
果、キャッシュの速度ならびに効率が向上する。
【００７０】 ここで、ディスクとメモリの間においてデータのページングを
行う場合、ある種の保護が行われ、メモリ内にストアされている情報と不揮発性
ストレージ・デバイス内にストアされている対応する情報が矛盾しないことが保
証される点に注意されたい。オブジェクト・キャッシュ内に効率のよい一貫性を
もたらすために使用される技法ついては、「同期および一貫性の強化」セクショ
ンにおいて、ガーベジ・コレクションに関する説明に要約されている。
行う場合、ある種の保護が行われ、メモリ内にストアされている情報と不揮発性
ストレージ・デバイス内にストアされている対応する情報が矛盾しないことが保
証される点に注意されたい。オブジェクト・キャッシュ内に効率のよい一貫性を
もたらすために使用される技法ついては、「同期および一貫性の強化」セクショ
ンにおいて、ガーベジ・コレクションに関する説明に要約されている。
【００７１】 （選択肢のベクトル） 前述したように、単一のＵＲＬが多数のバージョンを有する１つのオブジェク
トをマップすることが可能である。これらのバージョンは、「選択肢(alternate
s)」と呼ばれる。オブジェクト・キャッシュを使用しないシステムにおいては、
バージョンが次のようにして選択される。クライアント１０ａがインターネット
２０を介してサーバ４０に対するＨＴＴＰ接続を確立する。クライアントは、サ
ーバからオブジェクトを要求するＨＴＴＰメッセージ内において、それ自体に関
する情報を提供する。たとえば、オブジェクトを求めるＨＴＴＰ要求は、クライ
アントによって使用されているウェブ・ブラウザを識別する情報、当該ブラウザ
のバージョン、クライアントによって好ましいとされる言語、およびクライアン
トによって好ましいとされるメディア内容のタイプを識別するヘッダを含んでい
る。サーバ４０は、このＨＴＴＰ要求を受け取ると、ヘッダ情報を抽出し、ヘッ
ダ情報の値に基づいてオブジェクト５２の変化型を選択する。選択された選択肢
は、応答メッセージ内においてクライアント１０ａに返される。このタイプの変
化型選択は、新生のＨＴＴＰ／１．１ハイパーテキスト・トランスファ・プロト
コルによって奨励されている。
トをマップすることが可能である。これらのバージョンは、「選択肢(alternate
s)」と呼ばれる。オブジェクト・キャッシュを使用しないシステムにおいては、
バージョンが次のようにして選択される。クライアント１０ａがインターネット
２０を介してサーバ４０に対するＨＴＴＰ接続を確立する。クライアントは、サ
ーバからオブジェクトを要求するＨＴＴＰメッセージ内において、それ自体に関
する情報を提供する。たとえば、オブジェクトを求めるＨＴＴＰ要求は、クライ
アントによって使用されているウェブ・ブラウザを識別する情報、当該ブラウザ
のバージョン、クライアントによって好ましいとされる言語、およびクライアン
トによって好ましいとされるメディア内容のタイプを識別するヘッダを含んでい
る。サーバ４０は、このＨＴＴＰ要求を受け取ると、ヘッダ情報を抽出し、ヘッ
ダ情報の値に基づいてオブジェクト５２の変化型を選択する。選択された選択肢
は、応答メッセージ内においてクライアント１０ａに返される。このタイプの変
化型選択は、新生のＨＴＴＰ／１．１ハイパーテキスト・トランスファ・プロト
コルによって奨励されている。
【００７２】 効率的にＵＲＬに関する選択肢のコピーを維持することは、キ
ャッシュ・オブジェクト・ストアにとって重要である。すべてのＵＲＬ要求に応
答してキャッシュから単一のオブジェクトが常に提供されるとすれば、ブラウザ
は、サーバから直接獲得したものと異なるコンテンツを受け取る可能性がある。
この理由から、ディレクトリ・テーブル１１０内のそれぞれの名前キーが選択肢
のベクトル１２２ａ〜１２２ｎの１つをマップし、それによってキャッシュ８０
が複数の関連バージョンの中からオブジェクトの特定のバージョンを選択できる
ようにしている。たとえば、オブジェクト５２をウェブ・ページとすれば、サー
バ４０は、英語、フランス語および日本語のバージョンのそのオブジェクトをス
トアすることができる。
ャッシュ・オブジェクト・ストアにとって重要である。すべてのＵＲＬ要求に応
答してキャッシュから単一のオブジェクトが常に提供されるとすれば、ブラウザ
は、サーバから直接獲得したものと異なるコンテンツを受け取る可能性がある。
この理由から、ディレクトリ・テーブル１１０内のそれぞれの名前キーが選択肢
のベクトル１２２ａ〜１２２ｎの１つをマップし、それによってキャッシュ８０
が複数の関連バージョンの中からオブジェクトの特定のバージョンを選択できる
ようにしている。たとえば、オブジェクト５２をウェブ・ページとすれば、サー
バ４０は、英語、フランス語および日本語のバージョンのそのオブジェクトをス
トアすることができる。
【００７３】 選択肢のベクトル１２２ａ〜１２２ｎのそれぞれは、複数の選
択肢レコード１２３ａ〜１２３ｎをストアする構造である。選択肢レコード１２
３ａ〜１２３ｎのそれぞれは、要求オブジェクト５２の選択肢バージョンを記述
する情報をストアしているデータ構造である。たとえば、この情報は、特定のブ
ラウザのバージョン、オブジェクトに用いられている人間の言語等を記述する。
選択肢レコードもまた、それぞれ選択肢バージョンを含むオブジェクトを識別す
る完全なオブジェクト・キーをストアしている。好ましい実施例においては、選
択肢レコード１２３ａ〜１２３ｎのそれぞれが要求情報、応答情報、およびオブ
ジェクト・キー５６をストアしている。
択肢レコード１２３ａ〜１２３ｎをストアする構造である。選択肢レコード１２
３ａ〜１２３ｎのそれぞれは、要求オブジェクト５２の選択肢バージョンを記述
する情報をストアしているデータ構造である。たとえば、この情報は、特定のブ
ラウザのバージョン、オブジェクトに用いられている人間の言語等を記述する。
選択肢レコードもまた、それぞれ選択肢バージョンを含むオブジェクトを識別す
る完全なオブジェクト・キーをストアしている。好ましい実施例においては、選
択肢レコード１２３ａ〜１２３ｎのそれぞれが要求情報、応答情報、およびオブ
ジェクト・キー５６をストアしている。
【００７４】 「人気のある」単一のオブジェクト名が多くの選択肢をマップ
していることがあるため、一実施例においては、キャッシュがオブジェクト名を
用いて明示的もしくは暗示的な要求のコンテキストを組み立て、ベクトルのエレ
メント数を低減している。たとえば、ウェブ・クライアント要求のユーザ‐エー
ジェント・ヘッダ（特定のブラウザ・アプリケーションを示す）をウェブＵＲＬ
と結合して名前キーを形成すればよい。コンテキスト情報をキー内に直接包含さ
せることによって、ディレクトリ・テーブル内のエントリ数が増加するが、各ベ
クトル内の選択肢の数は減少する。実際問題として、特定のヘッダおよび情報オ
ブジェクト名を結合させた暗示的なコンテキストは構成可能である。
していることがあるため、一実施例においては、キャッシュがオブジェクト名を
用いて明示的もしくは暗示的な要求のコンテキストを組み立て、ベクトルのエレ
メント数を低減している。たとえば、ウェブ・クライアント要求のユーザ‐エー
ジェント・ヘッダ（特定のブラウザ・アプリケーションを示す）をウェブＵＲＬ
と結合して名前キーを形成すればよい。コンテキスト情報をキー内に直接包含さ
せることによって、ディレクトリ・テーブル内のエントリ数が増加するが、各ベ
クトル内の選択肢の数は減少する。実際問題として、特定のヘッダおよび情報オ
ブジェクト名を結合させた暗示的なコンテキストは構成可能である。
【００７５】 これらの選択肢のベクトル１２２ａ〜１２２ｎは、ＨＴＴＰ／
１．１によってネゴシエーションが行われるコンテンツの適正な処理をサポート
する。ＨＴＴＰ／１．１メッセージのヘッダに含まれる要求情報および応答情報
は、特定の要求を満たすために使用する選択肢レコード１２３ａ〜１２３ｎのう
ちの１つを決定する上で使用される。キャッシュ８０がオブジェクトを求める要
求を受け取ったとき、その要求には通常、希望のオブジェクトの名前（またはＵ
ＲＬ）に加えてヘッダ情報が含まれている。すでに説明したように、名前は適切
な選択肢のベクトルを見つけ出すために使用される。適切な選択肢のベクトルが
見つかった後は、ヘッダ情報を使用し、その要求に適切な選択肢レコードを選択
する。
１．１によってネゴシエーションが行われるコンテンツの適正な処理をサポート
する。ＨＴＴＰ／１．１メッセージのヘッダに含まれる要求情報および応答情報
は、特定の要求を満たすために使用する選択肢レコード１２３ａ〜１２３ｎのう
ちの１つを決定する上で使用される。キャッシュ８０がオブジェクトを求める要
求を受け取ったとき、その要求には通常、希望のオブジェクトの名前（またはＵ
ＲＬ）に加えてヘッダ情報が含まれている。すでに説明したように、名前は適切
な選択肢のベクトルを見つけ出すために使用される。適切な選択肢のベクトルが
見つかった後は、ヘッダ情報を使用し、その要求に適切な選択肢レコードを選択
する。
【００７６】 より具体的に述べれば、キャッシュ８０内において、ヘッダ情
報が受け取られて解析される。キャッシュ８０は、ヘッダ情報内に見つかった値
と、選択肢レコード１２３ａ〜１２３ｎの１つの要求情報の一致を求める。たと
えば、キャッシュ８０がワールド・ワイド・ウェブとの関連において使用されて
いるとき、オブジェクトを求める要求がＨＴＴＰ要求の形式のキャッシュを含む
サーバに対して提供される。
報が受け取られて解析される。キャッシュ８０は、ヘッダ情報内に見つかった値
と、選択肢レコード１２３ａ〜１２３ｎの１つの要求情報の一致を求める。たと
えば、キャッシュ８０がワールド・ワイド・ウェブとの関連において使用されて
いるとき、オブジェクトを求める要求がＨＴＴＰ要求の形式のキャッシュを含む
サーバに対して提供される。
【００７７】 キャッシュ８０は、ＨＴＴＰ要求内の情報を調べ、選択肢レコ
ード１２３ａ〜１２３ｎのいずれを使用するかを決定する。たとえば、要求して
いるクライアント１０ａがバージョン３．０のNetscape Navigator（ネットスケ
ープ・ナビゲータ）ブラウザ・プログラムを走らせており、ドイツ語のテキスト
の選択を要求していることを示す要求情報がＨＴＴＰ要求に含まれていることが
考えられる。キャッシュ８０は、この情報を使用して選択肢レコード１２３ａ〜
１２３ｎをサーチし、要求情報から得たブラウザのバージョンおよびクライアン
トの場所に適合する応答情報を探す。一致が見つかると、一致した選択肢からオ
ブジェクト・キーを取り出し、そのオブジェクト・キーを使用して対応するオブ
ジェクトをキャッシュから取り出す。
ード１２３ａ〜１２３ｎのいずれを使用するかを決定する。たとえば、要求して
いるクライアント１０ａがバージョン３．０のNetscape Navigator（ネットスケ
ープ・ナビゲータ）ブラウザ・プログラムを走らせており、ドイツ語のテキスト
の選択を要求していることを示す要求情報がＨＴＴＰ要求に含まれていることが
考えられる。キャッシュ８０は、この情報を使用して選択肢レコード１２３ａ〜
１２３ｎをサーチし、要求情報から得たブラウザのバージョンおよびクライアン
トの場所に適合する応答情報を探す。一致が見つかると、一致した選択肢からオ
ブジェクト・キーを取り出し、そのオブジェクト・キーを使用して対応するオブ
ジェクトをキャッシュから取り出す。
【００７８】 キャッシュは、クライアントの要求の中で指定されている基準
との一致によって選択されるオブジェクトを最適化する。クライアントの要求に
おいては、最小受理基準（たとえば、ドキュメントはＪＰＥＧイメージでなけれ
ばならない、あるいはドキュメントはラテン語でなければならない等）が指定さ
れることもある。また、クライアントの要求が、一致に関する比較用重み付け基
準（たとえば、ＧＩＦイメージを受け入れる重み付けを０．５、それより好まし
いＪＰＥＧイメージを受け入れる重み付けを０．７５とする）を指定することも
ある。数字による重み付けは、すべての制限軸にわたって累算され、最適化され
た最終的な重み付けが作り出される。
との一致によって選択されるオブジェクトを最適化する。クライアントの要求に
おいては、最小受理基準（たとえば、ドキュメントはＪＰＥＧイメージでなけれ
ばならない、あるいはドキュメントはラテン語でなければならない等）が指定さ
れることもある。また、クライアントの要求が、一致に関する比較用重み付け基
準（たとえば、ＧＩＦイメージを受け入れる重み付けを０．５、それより好まし
いＪＰＥＧイメージを受け入れる重み付けを０．７５とする）を指定することも
ある。数字による重み付けは、すべての制限軸にわたって累算され、最適化され
た最終的な重み付けが作り出される。
【００７９】 オブジェクト・キーは、上記の態様においてオブジェクトを取
り出すために使用される。具体的には、オブジェクト・キーのサブキー部分を使
用してタグ・テーブル１０２およびディレクトリ・テーブル１１０の別のサーチ
を開始し、そのサブキー値に関するヒットを求める。タグ・テーブルおよびディ
レクトリ・テーブルのいずれにもヒットが存在するときは、サブキー値を使用し
て到達したディレクトリ・テーブル内のブロックは、常にストア済みのオブジェ
クト（たとえばストア済みのオブジェクト１２４）を参照する。つまりキャッシ
ュ８０は、選択肢のベクトル１２２を使用し、複数のバージョンを有するオブジ
ェクトに関する要求を処理することにより、要求しているクライアント１０ａに
対して適切なバージョンを配信することができる。
り出すために使用される。具体的には、オブジェクト・キーのサブキー部分を使
用してタグ・テーブル１０２およびディレクトリ・テーブル１１０の別のサーチ
を開始し、そのサブキー値に関するヒットを求める。タグ・テーブルおよびディ
レクトリ・テーブルのいずれにもヒットが存在するときは、サブキー値を使用し
て到達したディレクトリ・テーブル内のブロックは、常にストア済みのオブジェ
クト（たとえばストア済みのオブジェクト１２４）を参照する。つまりキャッシ
ュ８０は、選択肢のベクトル１２２を使用し、複数のバージョンを有するオブジ
ェクトに関する要求を処理することにより、要求しているクライアント１０ａに
対して適切なバージョンを配信することができる。
【００８０】 図４には、一例の選択肢のベクトル１２２が１つ、一例のスト
ア済みオブジェクト１２４が１つだけ示されている。しかしながら実際には、イ
ンデクス付けされているオブジェクトの数およびオブジェクトに関連付けされた
選択肢バージョンの数に応じて、キャッシュ８０が任意数のベクトルおよびディ
スク・ブロックを含むことになる。
ア済みオブジェクト１２４が１つだけ示されている。しかしながら実際には、イ
ンデクス付けされているオブジェクトの数およびオブジェクトに関連付けされた
選択肢バージョンの数に応じて、キャッシュ８０が任意数のベクトルおよびディ
スク・ブロックを含むことになる。
【００８１】 （先読み） 図４Ｂは、一例の選択肢のベクトル１２２ａ〜１２２ｎに関するストレージ構
成を示したブロック図である。システムは、メタデータの後に続けてデータ・オ
ブジェクトを統合しようと試みる。シークは時間を要するが、連続した読み出し
が読み出しを高速化することから、データとメタデータを整理統合し、メタデー
タに続いてデータの先読みを行うことによってパフォーマンスを向上することが
できる。
成を示したブロック図である。システムは、メタデータの後に続けてデータ・オ
ブジェクトを統合しようと試みる。シークは時間を要するが、連続した読み出し
が読み出しを高速化することから、データとメタデータを整理統合し、メタデー
タに続いてデータの先読みを行うことによってパフォーマンスを向上することが
できる。
【００８２】 ストレージ・デバイス９０ａ〜９０ｎの１つにおいては、選択
肢のベクトル１２２ａ〜１２２ｎのそれぞれが、ベクトル内に表された選択肢レ
コード１２３ａ〜１２３ｎに関連付けされているストア済みオブジェクト１２４
ａ〜１２４ｂに隣接する位置にストアされる。たとえば、選択肢のベクトル１２
２ａは、選択肢レコード１２３ａ〜１２３ｃをストアしている。選択肢レコード
１２３ａは、選択肢レコードに関連付けされたストア済みオブジェクト１２４ａ
が英語用に準備されていることを示す要求情報および応答情報をストアしている
。別の選択肢レコード１２３ｂは、関連するストア済みオブジェクト１２４ｂが
Microsoft Internet Explorer（マイクロソフト・インターネット・エクスプロ
ーラ）ブラウザとともに使用すべく意図されていることを示す情報をストアして
いる。選択肢レコード１２３ａ、１２３ｂによって参照されるストア済みオブジ
ェクト１２４ａ、１２４ｂは、選択肢のベクトル１２２ａ〜１２２ｎと隣接して
ストアされる。
肢のベクトル１２２ａ〜１２２ｎのそれぞれが、ベクトル内に表された選択肢レ
コード１２３ａ〜１２３ｎに関連付けされているストア済みオブジェクト１２４
ａ〜１２４ｂに隣接する位置にストアされる。たとえば、選択肢のベクトル１２
２ａは、選択肢レコード１２３ａ〜１２３ｃをストアしている。選択肢レコード
１２３ａは、選択肢レコードに関連付けされたストア済みオブジェクト１２４ａ
が英語用に準備されていることを示す要求情報および応答情報をストアしている
。別の選択肢レコード１２３ｂは、関連するストア済みオブジェクト１２４ｂが
Microsoft Internet Explorer（マイクロソフト・インターネット・エクスプロ
ーラ）ブラウザとともに使用すべく意図されていることを示す情報をストアして
いる。選択肢レコード１２３ａ、１２３ｂによって参照されるストア済みオブジ
ェクト１２４ａ、１２４ｂは、選択肢のベクトル１２２ａ〜１２２ｎと隣接して
ストアされる。
【００８３】 各選択肢レコード内のサイズ値１２０は、関連する選択肢のベ
クトル１２２ａ〜１２２ｎの１つとストア済みオブジェクト１２４の合計サイズ
をバイト数で表す。キャッシュ８０がディスク・ロケーション値１１８に基づい
て選択肢のベクトル１２２ａを参照するとき、キャッシュはサイズ値によって示
されるバイト数を読み出す。たとえば、図４Ｂに示した選択肢のベクトルのキャ
ッシュにおいて、サイズ値は、選択肢のベクトル１２２ａの長さに、関連するス
トア済みオブジェクト１２４ａの長さを加えた長さを表す。つまりキャッシュ８
０は、サイズ値を参照することによって、ベクトルだけでなくストア済みオブジ
ェクトを読み出す。この方法によりキャッシュ８０は、選択肢のベクトル１２２
の「先読み」を行い、ストレージ・デバイス９０ａ〜９０ｎからオブジェクト５
２をすべて取り出す。この結果、ストレージ・デバイスによる単一のシーク・オ
ペレーションを使用して、ストレージ・デバイスから選択肢のベクトルおよびオ
ブジェクト５２がともに読み出される。したがって、キャッシュ８０内にヒット
が存在するとき、大抵の場合（単一の選択肢が存在する場合）は、要求されたオ
ブジェクト５２が単一のシークを使用してストレージ・デバイスから取り出され
る。
クトル１２２ａ〜１２２ｎの１つとストア済みオブジェクト１２４の合計サイズ
をバイト数で表す。キャッシュ８０がディスク・ロケーション値１１８に基づい
て選択肢のベクトル１２２ａを参照するとき、キャッシュはサイズ値によって示
されるバイト数を読み出す。たとえば、図４Ｂに示した選択肢のベクトルのキャ
ッシュにおいて、サイズ値は、選択肢のベクトル１２２ａの長さに、関連するス
トア済みオブジェクト１２４ａの長さを加えた長さを表す。つまりキャッシュ８
０は、サイズ値を参照することによって、ベクトルだけでなくストア済みオブジ
ェクトを読み出す。この方法によりキャッシュ８０は、選択肢のベクトル１２２
の「先読み」を行い、ストレージ・デバイス９０ａ〜９０ｎからオブジェクト５
２をすべて取り出す。この結果、ストレージ・デバイスによる単一のシーク・オ
ペレーションを使用して、ストレージ・デバイスから選択肢のベクトルおよびオ
ブジェクト５２がともに読み出される。したがって、キャッシュ８０内にヒット
が存在するとき、大抵の場合（単一の選択肢が存在する場合）は、要求されたオ
ブジェクト５２が単一のシークを使用してストレージ・デバイスから取り出され
る。
【００８４】 ディスク・ロケーション値１１８が、選択肢のベクトル１２２
ではなく直接ストア済みオブジェクト１２４を参照しているときは、サイズ値１
２０がディスク・ブロック内にストアされたオブジェクトのサイズを示す。この
値は、ここで詳細を述べているように、単一シークによるオブジェクトの取り出
しを容易にするために使用される。
ではなく直接ストア済みオブジェクト１２４を参照しているときは、サイズ値１
２０がディスク・ブロック内にストアされたオブジェクトのサイズを示す。この
値は、ここで詳細を述べているように、単一シークによるオブジェクトの取り出
しを容易にするために使用される。
【００８５】 （オープン・ディレクトリ） 一実施例においては、キャッシュ８０がさらにオープン・ディレクトリ１３０
を備えている。このオープン・ディレクトリ１３０は、それぞれが複数のリスト
・エントリ１３１ａ〜１３１ｎからなる複数のリンクされたリスト１３２ａ〜１
３２ｎをストアしている。リンクされたリスト１３２ａ〜１３２ｎのそれぞれは
、ディレクトリ・テーブル１１０内のセット１１０ａ〜１１０ｎのいずれか１つ
に関連付けされている。オープン・ディレクトリ１３０は、揮発性のメイン・メ
モリにストアされる。好ましくは、オープン・ディレクトリ１３０のそれぞれの
リスト・エントリ１３１ａ〜１３１ｎが、情報オブジェクトの連想ルックアップ
を容易にするオブジェクト・キーをストアする。たとえば、リンクされたリスト
１３２ａ〜１３２ｎのそれぞれの中の各アイテムが、オブジェクト５２に関する
完全なオブジェクト・キー５６をストアする。
を備えている。このオープン・ディレクトリ１３０は、それぞれが複数のリスト
・エントリ１３１ａ〜１３１ｎからなる複数のリンクされたリスト１３２ａ〜１
３２ｎをストアしている。リンクされたリスト１３２ａ〜１３２ｎのそれぞれは
、ディレクトリ・テーブル１１０内のセット１１０ａ〜１１０ｎのいずれか１つ
に関連付けされている。オープン・ディレクトリ１３０は、揮発性のメイン・メ
モリにストアされる。好ましくは、オープン・ディレクトリ１３０のそれぞれの
リスト・エントリ１３１ａ〜１３１ｎが、情報オブジェクトの連想ルックアップ
を容易にするオブジェクト・キーをストアする。たとえば、リンクされたリスト
１３２ａ〜１３２ｎのそれぞれの中の各アイテムが、オブジェクト５２に関する
完全なオブジェクト・キー５６をストアする。
【００８６】 オープン・ディレクトリは、現在トランザクションを受けてい
るオブジェクトを捕まえて、衝突をもたらすオペレーションに抗する相互除外を
提供する。たとえば、現在読み出しが行われているオブジェクトに対する上書き
または削除に対する保護にオープン・ディレクトリが有用となる。またオープン
・ディレクトリは、ディレクトリ・テーブル１１０に対する変更がディレクトリ
・テーブル１１０内において固定される前に、それをバッファする。後述するよ
うに、適切なポイントにおいて同期オペレーションが実行され、オープン・ディ
レクトリ１３０内に反映されたこの変更がディレクトリ・テーブル１１０に移動
される。これにより、予期しないシステムの異常またはクラッシュが生じた場合
にディレクトリ・テーブル１１０の改ざんを防ぐことができる。
るオブジェクトを捕まえて、衝突をもたらすオペレーションに抗する相互除外を
提供する。たとえば、現在読み出しが行われているオブジェクトに対する上書き
または削除に対する保護にオープン・ディレクトリが有用となる。またオープン
・ディレクトリは、ディレクトリ・テーブル１１０に対する変更がディレクトリ
・テーブル１１０内において固定される前に、それをバッファする。後述するよ
うに、適切なポイントにおいて同期オペレーションが実行され、オープン・ディ
レクトリ１３０内に反映されたこの変更がディレクトリ・テーブル１１０に移動
される。これにより、予期しないシステムの異常またはクラッシュが生じた場合
にディレクトリ・テーブル１１０の改ざんを防ぐことができる。
【００８７】 さらに一実施例においては、キャッシュ８０からオブジェクト
が要求されたとき、最初にオープン・ディレクトリ１３０が調べられる；オープ
ン・ディレクトリには、もっとも最近に使用された情報オブジェクトに対する参
照が含まれていることから、それがヒットをもたらす可能性がもっとも高いと考
えられる。この形式のオープン・ディレクトリは、「人気のある」データに関す
るメイン・メモリ内のキャッシュとして機能する。
が要求されたとき、最初にオープン・ディレクトリ１３０が調べられる；オープ
ン・ディレクトリには、もっとも最近に使用された情報オブジェクトに対する参
照が含まれていることから、それがヒットをもたらす可能性がもっとも高いと考
えられる。この形式のオープン・ディレクトリは、「人気のある」データに関す
るメイン・メモリ内のキャッシュとして機能する。
【００８８】 （ディスク・データのレイアウトおよび集成） オープン・ディレクトリ１３０、タグ・テーブル１０２およびディレクトリ・
テーブル１１０がアクセスされてストア済みオブジェクト１２４の位置を決定し
た後は、ストレージからそのオブジェクトを読み出し、そのオブジェクトを要求
したユーザにそれを送信しなければならない。キャッシュ８０からオブジェクト
５２を取り出すために使用される読み出しオペレーションの効率を向上させるた
めに、最初にデータをストアするとき、一定のデータ集成技法が使用される。デ
ィスク上にデータを最初にストアするとき、ここに示すデータ集成技法に従って
いれば、その後の読み出しの効率が大きく改善される。 図６は、キャッシュ８
０およびストレージ・デバイス９０ａ〜９０ｎとともに使用するためのデータ・
ストレージ構成を示すブロック図である。ストレージ・デバイス９０ａは、ディ
スク・ドライブ等であり、複数のプール２００ａ〜２００ｎにデータをストアす
る。プールは、連続するディスク空間のセグメントまたはチャンクであり、好ま
しくは最大で４ギガバイトのサイズを有する。プールは、複数のファイルの断片
から、あるいは生のディスク・パーティションのセグメントから割り当てること
ができる。
テーブル１１０がアクセスされてストア済みオブジェクト１２４の位置を決定し
た後は、ストレージからそのオブジェクトを読み出し、そのオブジェクトを要求
したユーザにそれを送信しなければならない。キャッシュ８０からオブジェクト
５２を取り出すために使用される読み出しオペレーションの効率を向上させるた
めに、最初にデータをストアするとき、一定のデータ集成技法が使用される。デ
ィスク上にデータを最初にストアするとき、ここに示すデータ集成技法に従って
いれば、その後の読み出しの効率が大きく改善される。 図６は、キャッシュ８
０およびストレージ・デバイス９０ａ〜９０ｎとともに使用するためのデータ・
ストレージ構成を示すブロック図である。ストレージ・デバイス９０ａは、ディ
スク・ドライブ等であり、複数のプール２００ａ〜２００ｎにデータをストアす
る。プールは、連続するディスク空間のセグメントまたはチャンクであり、好ま
しくは最大で４ギガバイトのサイズを有する。プールは、複数のファイルの断片
から、あるいは生のディスク・パーティションのセグメントから割り当てること
ができる。
【００８９】 プール２００ｎ等の各プールは、ヘッダ２０２および、ここで
「アリーナ」と呼んでいる複数の固定サイズのストレージ空間２０４ａ〜２０４
ｎを含んでいる。アリーナのサイズは、好ましくは構成可能もしくは変更可能と
し、キャッシュ８０のパフォーマンスの最適化を可能にする。好ましい実施例に
おいては、アリーナ２０４ａ〜２０４ｎのそれぞれを概略で５１２キロバイトか
ら２メガバイトまでのサイズを有するブロックとしている。
「アリーナ」と呼んでいる複数の固定サイズのストレージ空間２０４ａ〜２０４
ｎを含んでいる。アリーナのサイズは、好ましくは構成可能もしくは変更可能と
し、キャッシュ８０のパフォーマンスの最適化を可能にする。好ましい実施例に
おいては、アリーナ２０４ａ〜２０４ｎのそれぞれを概略で５１２キロバイトか
ら２メガバイトまでのサイズを有するブロックとしている。
【００９０】 アリーナに書き込むデータは、メモリ内の「書き込み集成バッ
ファ」に置かれ、あるいは一時的にストアもしくは一時的に置かれる。このバッ
ファは、データを蓄積し、いっぱいになると、１回のシークにおいてディスク上
の１つのアリーナに連続的に書き込む。書き込み集成バッファは、書き込みのパ
フォーマンスを向上させ、データ・アイテムを生のディスク・ドライブから直接
読み出すことができるデータのセクタ配列を可能にする。
ファ」に置かれ、あるいは一時的にストアもしくは一時的に置かれる。このバッ
ファは、データを蓄積し、いっぱいになると、１回のシークにおいてディスク上
の１つのアリーナに連続的に書き込む。書き込み集成バッファは、書き込みのパ
フォーマンスを向上させ、データ・アイテムを生のディスク・ドライブから直接
読み出すことができるデータのセクタ配列を可能にする。
【００９１】 書き込み集成バッファは、アリーナの全コンテンツを保持する
充分な大きさを有する。データは、ディスク上の（空の）アリーナに落とされる
前に、まず書き込み集成バッファに置かれて整理統合される。また書き込み集成
バッファは、集成バッファを満たすとき、それ以外のストレージを割り当てるた
めに使用されるフリー・トップ・ポインタ、それがカバーしているアリーナに名
前を設定する識別名、およびそのアリーナのアクティブ・ユーザ数に関する参照
カウントを含んでいる。
充分な大きさを有する。データは、ディスク上の（空の）アリーナに落とされる
前に、まず書き込み集成バッファに置かれて整理統合される。また書き込み集成
バッファは、集成バッファを満たすとき、それ以外のストレージを割り当てるた
めに使用されるフリー・トップ・ポインタ、それがカバーしているアリーナに名
前を設定する識別名、およびそのアリーナのアクティブ・ユーザ数に関する参照
カウントを含んでいる。
【００９２】 各プール・ヘッダ２０２は、マジック・ナンバ、バージョン番
号値、アリーナ数の値、および１ないしは複数のアリーナ・ヘッダ２０６ａ〜２
０６ｎをストアしている。マジック・ナンバは、単独で内部の一貫性チェックに
使用される。バージョン番号値は、プール内にアリーナ２０６ａ〜２０６ｎを生
成したプログラムまたはプロセスのバージョン番号をストアする。これは、現在
実行中のキャッシュ８０のバージョンが適切にアリーナを読み書きできることを
保証するための一貫性チェックに使用される。アリーナ数の値は、プール内に含
まれているアリーナの数のカウント値をストアする。
号値、アリーナ数の値、および１ないしは複数のアリーナ・ヘッダ２０６ａ〜２
０６ｎをストアしている。マジック・ナンバは、単独で内部の一貫性チェックに
使用される。バージョン番号値は、プール内にアリーナ２０６ａ〜２０６ｎを生
成したプログラムまたはプロセスのバージョン番号をストアする。これは、現在
実行中のキャッシュ８０のバージョンが適切にアリーナを読み書きできることを
保証するための一貫性チェックに使用される。アリーナ数の値は、プール内に含
まれているアリーナの数のカウント値をストアする。
【００９３】 プール・ヘッダ２０２には、アリーナ・ヘッダ２０６ａ〜２０
６ｎのそれぞれに、プール内のそれぞれのアリーナに関する情報がストアされる
。各アリーナ・ヘッダは、対応するアリーナが空であるか否か、およびそのアリ
ーナの信頼性が失われているか否か（たとえば、物理的なディスク表面のダメー
ジ、あるいはアプリケーションのエラーによって）を示す２つの１ビット値をス
トアしている。
６ｎのそれぞれに、プール内のそれぞれのアリーナに関する情報がストアされる
。各アリーナ・ヘッダは、対応するアリーナが空であるか否か、およびそのアリ
ーナの信頼性が失われているか否か（たとえば、物理的なディスク表面のダメー
ジ、あるいはアプリケーションのエラーによって）を示す２つの１ビット値をス
トアしている。
【００９４】 図６にアリーナ２０４ａの場合を例に示したように、各アリー
ナは、１ないしは複数のデータのフラグメント２０８ａ〜２０８ｎを含む。それ
ぞれのフラグメント２０８ａ〜２０８ｎは、フラグメント・ヘッダ２０８ｄおよ
びフラグメント・データ２０８ｅを含んでいる。フラグメント・データ２０８ｅ
は、キャッシュ８０にストアされるオブジェクトに関する実際のデータである。
ストア済みオブジェクト全体に対応するデータは、単一のフラグメント内に存在
することもあれば、複数のフラグメントの中にストアされることもあり、またそ
れが複数のアリーナにわたって存在することもある。フラグメント・ヘッダ２０
８ｄは、マジック・ナンバ値２０６ｃ、キー値２０６ａおよび長さ値２０６ｂを
ストアしている。
ナは、１ないしは複数のデータのフラグメント２０８ａ〜２０８ｎを含む。それ
ぞれのフラグメント２０８ａ〜２０８ｎは、フラグメント・ヘッダ２０８ｄおよ
びフラグメント・データ２０８ｅを含んでいる。フラグメント・データ２０８ｅ
は、キャッシュ８０にストアされるオブジェクトに関する実際のデータである。
ストア済みオブジェクト全体に対応するデータは、単一のフラグメント内に存在
することもあれば、複数のフラグメントの中にストアされることもあり、またそ
れが複数のアリーナにわたって存在することもある。フラグメント・ヘッダ２０
８ｄは、マジック・ナンバ値２０６ｃ、キー値２０６ａおよび長さ値２０６ｂを
ストアしている。
【００９５】 長さ値２０６ｂは、フラグメント・ヘッダ２０８ｄおよびフラ
グメント・データ２０８ｅを含めたフラグメントの長さをバイト数で表す。キー
値２０６ａは、このフラグメント内にデータが含まれているオブジェクトのオブ
ジェクト・キーのコピーであり、その全体がストアされている。したがって、キ
ー値２０６ａを使用して、このフラグメント内にデータが含まれているオブジェ
クトのデータを保持している最初のフラグメントをポイントするディレクトリ・
ブロックをルックアップすることができる。
グメント・データ２０８ｅを含めたフラグメントの長さをバイト数で表す。キー
値２０６ａは、このフラグメント内にデータが含まれているオブジェクトのオブ
ジェクト・キーのコピーであり、その全体がストアされている。したがって、キ
ー値２０６ａを使用して、このフラグメント内にデータが含まれているオブジェ
クトのデータを保持している最初のフラグメントをポイントするディレクトリ・
ブロックをルックアップすることができる。
【００９６】 一実施例によれば、特定のオブジェクトに関連付けされた最後
のフラグメントに関連して、完全なオブジェクト・キー５６がストアされる。オ
ブジェクト５２を最初にキャッシュ８０にストアするとき、発信サーバ４０から
のオブジェクト・データの読み取りに従って漸増的にオブジェクト・キー５６を
演算する。つまり、オブジェクト・キー５６の最終値は、オブジェクト５２全体
の読み取りが完了するまで明らかにならない。オブジェクト・キー５６は、最後
のフラグメントの書き込みまでキーの値が明らかにならないことから、またディ
スク上の既存のデータに対する修正が時間を要することから、そのオブジェクト
のストアに使用されるフラグメントのチェーンの最後に書き込まれる。これとは
異なる実施例においては、フラグメント・ヘッダがフラグメントもしくはオブジ
ェクトを記述する別のメタデータをストアすることができる。
のフラグメントに関連して、完全なオブジェクト・キー５６がストアされる。オ
ブジェクト５２を最初にキャッシュ８０にストアするとき、発信サーバ４０から
のオブジェクト・データの読み取りに従って漸増的にオブジェクト・キー５６を
演算する。つまり、オブジェクト・キー５６の最終値は、オブジェクト５２全体
の読み取りが完了するまで明らかにならない。オブジェクト・キー５６は、最後
のフラグメントの書き込みまでキーの値が明らかにならないことから、またディ
スク上の既存のデータに対する修正が時間を要することから、そのオブジェクト
のストアに使用されるフラグメントのチェーンの最後に書き込まれる。これとは
異なる実施例においては、フラグメント・ヘッダがフラグメントもしくはオブジ
ェクトを記述する別のメタデータをストアすることができる。
【００９７】 書き込み集成バッファは、バッファ２０４ａのもっとも上の空
きエリアを示す「フリー・トップ・ポインタ」２１０を含んでいる。トップ・ポ
インタ２１０は、バッファ２０４ａ内における使用済み空間と使用可能空間の現
在の境界を示す。トップ・ポインタ２１０は、キャッシュ８０がバッファ内に追
加のフラグメントを書き込む位置を決定できるようにストアされている。トップ
・ポインタ２１０より下（図６においては、その左）は、すべて有効なデータを
含んでいるか、あるいはそれを受け取るためにすでに割り当てられている。トッ
プ・ポインタ２１０より上の（図６においてはその右の）アリーナ２０４ａのエ
リアは、他の情報オブジェクトを割り当てるために使用することができる。好ま
しくは、各フラグメントが最大３２キロバイトのデータを含む。フラグメントの
開始および終了は、ストレージ・デバイス９０ａの標準的な５１２バイト境界上
となる。ワールド・ワイド・ウェブの関係においては、ほとんどのオブジェクト
が比較的小さく、概してそのサイズは３２キロバイトに満たない。
きエリアを示す「フリー・トップ・ポインタ」２１０を含んでいる。トップ・ポ
インタ２１０は、バッファ２０４ａ内における使用済み空間と使用可能空間の現
在の境界を示す。トップ・ポインタ２１０は、キャッシュ８０がバッファ内に追
加のフラグメントを書き込む位置を決定できるようにストアされている。トップ
・ポインタ２１０より下（図６においては、その左）は、すべて有効なデータを
含んでいるか、あるいはそれを受け取るためにすでに割り当てられている。トッ
プ・ポインタ２１０より上の（図６においてはその右の）アリーナ２０４ａのエ
リアは、他の情報オブジェクトを割り当てるために使用することができる。好ま
しくは、各フラグメントが最大３２キロバイトのデータを含む。フラグメントの
開始および終了は、ストレージ・デバイス９０ａの標準的な５１２バイト境界上
となる。ワールド・ワイド・ウェブの関係においては、ほとんどのオブジェクト
が比較的小さく、概してそのサイズは３２キロバイトに満たない。
【００９８】 各アリーナは、必ず２つの状態のうちのいずれかになる：つま
り空状態または占有状態である。アリーナの現在の状態は、アリーナ・ヘッダ２
０６ａ〜２０６ｎにストアされるエンプティ値に反映される。占有状態は、その
アリーナのいずれかの部分に有効なデータがストアされている状態である。現在
エンプティであるアリーナ、つまり空いているすべてのアリーナのリストは、メ
モリ内にストアされている。たとえば、キャッシュ８０を走らせているワークス
テーションのメイン・メモリが、空のアリーナに対するポインタの配列をストア
している。別の実施例においては、各アリーナのヘッダ２０６ａ〜ｎに追加の情
報をストアすることができる。たとえばこれらのヘッダに、そのアリーナに包含
されていた削除済み情報オブジェクトの数、およびそのアリーナに対して最後に
ガーベジ・コレクションが実行された時を示すタイムスタンプを含めることが考
えられる。
り空状態または占有状態である。アリーナの現在の状態は、アリーナ・ヘッダ２
０６ａ〜２０６ｎにストアされるエンプティ値に反映される。占有状態は、その
アリーナのいずれかの部分に有効なデータがストアされている状態である。現在
エンプティであるアリーナ、つまり空いているすべてのアリーナのリストは、メ
モリ内にストアされている。たとえば、キャッシュ８０を走らせているワークス
テーションのメイン・メモリが、空のアリーナに対するポインタの配列をストア
している。別の実施例においては、各アリーナのヘッダ２０６ａ〜ｎに追加の情
報をストアすることができる。たとえばこれらのヘッダに、そのアリーナに包含
されていた削除済み情報オブジェクトの数、およびそのアリーナに対して最後に
ガーベジ・コレクションが実行された時を示すタイムスタンプを含めることが考
えられる。
【００９９】 図６には、例として３つのフラグメントを示したが、実際には
アリーナの容量に達するまで任意数のフラグメントを１つのアリーナにストアす
ることが許される。それに加えて、図６に示したプールの数およびアリーナの数
は、例示のみを目的としたものであり、これらには任意の数を使用することがで
きる。
アリーナの容量に達するまで任意数のフラグメントを１つのアリーナにストアす
ることが許される。それに加えて、図６に示したプールの数およびアリーナの数
は、例示のみを目的としたものであり、これらには任意の数を使用することがで
きる。
【０１００】 上記のアリーナの構造は、アリーナのフラグメントにストアさ
れるオブジェクトに関するデータ更新の特定の一貫性メカニズムおよび安全メカ
ニズムを容易にする。図７に、図６に示したアリーナ２０４ａ〜２０４ｎの１つ
の更新に関係するブロック図を示す。図７は、ヘッダ２０６およびデータ・フラ
グメント２０８ａ〜２０８ｃを有する第１の情報オブジェクト２０８ｂを包含す
るアリーナ２０４ａを示している。トップ・ポインタ２１０は、アリーナ２０４
ａのもっとも上のアクティブ部分、つまりデータ・セグメント２０８ｃの末尾を
ポイントする。好ましくは、１つのアリーナに対する完全な情報オブジェクトの
書き込みが完了した後に限り、かつアリーナのトップ・ポインタを異常なく移動
させた後に限ってディレクトリ・テーブルを更新する。たとえば、アリーナ２０
４ａのトップ・ポインタ２１０より上に完全な情報オブジェクトを書き込み、ト
ップ・ポインタを移動してアリーナの空き位置の新しいトップを表示させる。そ
の後初めてディレクトリ・テーブルを更新する。
れるオブジェクトに関するデータ更新の特定の一貫性メカニズムおよび安全メカ
ニズムを容易にする。図７に、図６に示したアリーナ２０４ａ〜２０４ｎの１つ
の更新に関係するブロック図を示す。図７は、ヘッダ２０６およびデータ・フラ
グメント２０８ａ〜２０８ｃを有する第１の情報オブジェクト２０８ｂを包含す
るアリーナ２０４ａを示している。トップ・ポインタ２１０は、アリーナ２０４
ａのもっとも上のアクティブ部分、つまりデータ・セグメント２０８ｃの末尾を
ポイントする。好ましくは、１つのアリーナに対する完全な情報オブジェクトの
書き込みが完了した後に限り、かつアリーナのトップ・ポインタを異常なく移動
させた後に限ってディレクトリ・テーブルを更新する。たとえば、アリーナ２０
４ａのトップ・ポインタ２１０より上に完全な情報オブジェクトを書き込み、ト
ップ・ポインタを移動してアリーナの空き位置の新しいトップを表示させる。そ
の後初めてディレクトリ・テーブルを更新する。
【０１０１】 ディレクトリ・テーブルの更新を遅らせることにより、それ以
外のステップのいずれかを行う間に、破局的なシステムの障害が生じた場合にお
いてもディレクトリ・テーブルの正確性が保証される。たとえば、いずれかのス
テップを完了する前に、ディスク・ドライブまたはその他のシステムのエレメン
トがクラッシュしたとしても悪影響は生じない。その場合、アリーナ２０４ａは
、信頼性のない、もしくは不完全なデータを含むことになるが、ディレクトリ・
テーブル１１０、インデクス、またはハッシュ・テーブル内に信頼性を失ったデ
ータに対する参照がまったく存在しないことから、キャッシュ８０は実質的にそ
れを無視する。それに加えて、信頼性のない、もしくは不完全なデータは、ここ
に述べるガーベジ・コレクション・プロセスを使用して最終的に再利用される。
外のステップのいずれかを行う間に、破局的なシステムの障害が生じた場合にお
いてもディレクトリ・テーブルの正確性が保証される。たとえば、いずれかのス
テップを完了する前に、ディスク・ドライブまたはその他のシステムのエレメン
トがクラッシュしたとしても悪影響は生じない。その場合、アリーナ２０４ａは
、信頼性のない、もしくは不完全なデータを含むことになるが、ディレクトリ・
テーブル１１０、インデクス、またはハッシュ・テーブル内に信頼性を失ったデ
ータに対する参照がまったく存在しないことから、キャッシュ８０は実質的にそ
れを無視する。それに加えて、信頼性のない、もしくは不完全なデータは、ここ
に述べるガーベジ・コレクション・プロセスを使用して最終的に再利用される。
【０１０２】 （マルチフラグメント・オブジェクト） 図３において、オブジェクト５２のオブジェクト・キーに基づいて到達したデ
ィレクトリ・テーブル・ブロック１１２ｂは、オブジェクト５２がストアされて
いるフラグメントに対するポインタ・ディレクトリを含んでいる。これには、オ
ブジェクト５２が単一のフラグメントにストアされていることが前提となる。
しかしながら大きなオブジェクトは、必ずしも単一のフラグメントに収まるわけ
ではなく、その理由は２つある。第１は、フラグメントは最大サイズが固定され
ている（好ましい値を３２ＫＢとする）ことである。したがって、３２ＫＢを超
えるオブジェクトは分断される。第２は、システムが、新しいオブジェクトのた
めに、書き込み集成バッファ内に空間をあらかじめ予約しなければならないこと
である。到来するオブジェクトのサイズがオブジェクト・ストアにとって未知で
あれば、推定を誤る可能性がある。サーバがオブジェクトの真の（実際には大き
い）サイズを誤って表すこともある。いずれの場合においてもオブジェクト・ス
トアは、フラグメントのチェーンを構成してオーバーフローを処理する。
ィレクトリ・テーブル・ブロック１１２ｂは、オブジェクト５２がストアされて
いるフラグメントに対するポインタ・ディレクトリを含んでいる。これには、オ
ブジェクト５２が単一のフラグメントにストアされていることが前提となる。
しかしながら大きなオブジェクトは、必ずしも単一のフラグメントに収まるわけ
ではなく、その理由は２つある。第１は、フラグメントは最大サイズが固定され
ている（好ましい値を３２ＫＢとする）ことである。したがって、３２ＫＢを超
えるオブジェクトは分断される。第２は、システムが、新しいオブジェクトのた
めに、書き込み集成バッファ内に空間をあらかじめ予約しなければならないこと
である。到来するオブジェクトのサイズがオブジェクト・ストアにとって未知で
あれば、推定を誤る可能性がある。サーバがオブジェクトの真の（実際には大き
い）サイズを誤って表すこともある。いずれの場合においてもオブジェクト・ス
トアは、フラグメントのチェーンを構成してオーバーフローを処理する。
【０１０３】 したがって、フラグメント間において分断されたオブジェクト
からのデータを含むフラグメントを追跡するためのメカニズムが提供されている
。図５は、関連するフラグメントを追跡するための好ましい構造を示したブロッ
ク図である。
からのデータを含むフラグメントを追跡するためのメカニズムが提供されている
。図５は、関連するフラグメントを追跡するための好ましい構造を示したブロッ
ク図である。
【０１０４】 説明のため、ここではオブジェクトＸがストレージ・デバイス
９０ａ〜９０ｎ上の３つのフラグメント２０８ａ、２０８ｂ、および２０８ｃに
ストアされているものと仮定する。キャッシュは、オブジェクトＸ用のオブジェ
クト・キーを使用してタグ・テーブルを調べ、ディレクトリ・テーブル１１０内
の特定のブロック１４１ａに到達する。ブロック１４１ａは、オブジェクトＸを
包含している連続するフラグメントを識別するブロックのヘッドである。ここに
示した例においては、このチェーンに、ブロック１４１ａ、１４１ｂ、１４１ｃ
、１４１ｄおよび１４１ｅが含まれ、ポインタ１２８ａ〜１２８ｄによってその
チェーンが形成されている。
９０ａ〜９０ｎ上の３つのフラグメント２０８ａ、２０８ｂ、および２０８ｃに
ストアされているものと仮定する。キャッシュは、オブジェクトＸ用のオブジェ
クト・キーを使用してタグ・テーブルを調べ、ディレクトリ・テーブル１１０内
の特定のブロック１４１ａに到達する。ブロック１４１ａは、オブジェクトＸを
包含している連続するフラグメントを識別するブロックのヘッドである。ここに
示した例においては、このチェーンに、ブロック１４１ａ、１４１ｂ、１４１ｃ
、１４１ｄおよび１４１ｅが含まれ、ポインタ１２８ａ〜１２８ｄによってその
チェーンが形成されている。
【０１０５】 一実施例によれば、ヘッド・ブロック１４１ａは、サブキー値
１２６およびブロック・ポインタ１２８ａを備える。好ましくは、サブキー値１
２６の長さを９６ビットとし、オブジェクトＸ用のオブジェクト・キー５６の値
のサブセットから構成する。ブロック・ポインタ１２８ａの値は、チェーン内の
次のブロック１４１ｂを参照する。
１２６およびブロック・ポインタ１２８ａを備える。好ましくは、サブキー値１
２６の長さを９６ビットとし、オブジェクトＸ用のオブジェクト・キー５６の値
のサブセットから構成する。ブロック・ポインタ１２８ａの値は、チェーン内の
次のブロック１４１ｂを参照する。
【０１０６】 ディレクトリ・テーブルのブロック１４１ｂは、フラグメント
・ポインタ１３０ａおよびブロック・ポインタ１２８ｂを含む。フラグメント・
ポインタ１３０ａは、フラグメント２０８ａを参照し、そこにはオブジェクトＸ
に関するデータの最初の部分がストアされている。ポインタ・ブロック１４１ｂ
のブロック・ポインタ１２８ｂは、このチェーン内の次のポインタ・ブロック１
４１ｃを参照する。ポインタ・ブロック１４１ｂと同様に、ポインタ・ブロック
１４１ｃも、フラグメント２０８ｂを参照するフラグメント・ポインタ１３０ｂ
を含む。ポインタ・ブロック１４１ｃのブロック・ポインタ１２８ｃは、このチ
ェーン内の次のポインタ・ブロック１４１ｄを参照する。ポインタ・ブロック１
４１ｃと同様に、ポインタ・ブロック１４１ｄも、フラグメント２０８ｃを参照
するフラグメント・ポインタ１３０ｂを含む。
・ポインタ１３０ａおよびブロック・ポインタ１２８ｂを含む。フラグメント・
ポインタ１３０ａは、フラグメント２０８ａを参照し、そこにはオブジェクトＸ
に関するデータの最初の部分がストアされている。ポインタ・ブロック１４１ｂ
のブロック・ポインタ１２８ｂは、このチェーン内の次のポインタ・ブロック１
４１ｃを参照する。ポインタ・ブロック１４１ｂと同様に、ポインタ・ブロック
１４１ｃも、フラグメント２０８ｂを参照するフラグメント・ポインタ１３０ｂ
を含む。ポインタ・ブロック１４１ｃのブロック・ポインタ１２８ｃは、このチ
ェーン内の次のポインタ・ブロック１４１ｄを参照する。ポインタ・ブロック１
４１ｃと同様に、ポインタ・ブロック１４１ｄも、フラグメント２０８ｃを参照
するフラグメント・ポインタ１３０ｂを含む。
【０１０７】 オブジェクト・ストアは、フラグメントを互いにつなぐための
メカニズムを必要とする。従来のディスク・ブロックのチェーニング・スキーム
は、ディスク上にすでに存在しているデータを修正し、直前のチェーン・リンク
・ポインタがその次の新しいブロック値をポイントするように変更する必要があ
る。すでに存在してディスク・データの修正は時間を要し、前もって終了が知ら
されないプロセスに抗して一貫性を確保することに関連する複雑性がもたらされ
る。
メカニズムを必要とする。従来のディスク・ブロックのチェーニング・スキーム
は、ディスク上にすでに存在しているデータを修正し、直前のチェーン・リンク
・ポインタがその次の新しいブロック値をポイントするように変更する必要があ
る。すでに存在してディスク・データの修正は時間を要し、前もって終了が知ら
されないプロセスに抗して一貫性を確保することに関連する複雑性がもたらされ
る。
【０１０８】 本発明の一実施例に従えば、「反復関数ポインタ」を使用する
ことによって新しいフラグメント・ポインタを現存するフラグメントにパッチす
る必要がなくなる。各フラグメントにはキーが割り当てられ、次のフラグメント
のキーが、直前のフラグメントのキーの単純な反復関数として割り当てられる。
この方法によれば、直前のフラグメントのポインタを修正するのではなく、次の
フラグメントのキーを定義するだけで単純にフラグメントをつなぐことができる
。
ことによって新しいフラグメント・ポインタを現存するフラグメントにパッチす
る必要がなくなる。各フラグメントにはキーが割り当てられ、次のフラグメント
のキーが、直前のフラグメントのキーの単純な反復関数として割り当てられる。
この方法によれば、直前のフラグメントのポインタを修正するのではなく、次の
フラグメントのキーを定義するだけで単純にフラグメントをつなぐことができる
。
【０１０９】 たとえばここで、サブキー１２６の値に関数を適用することに
よってブロック・ポインタ１２８ａを演算する。ブロック・ポインタ値１２８ｂ
は、ブロック・ポインタ１２８ａの値に関数を適用することによって演算される
。ポインタ値の演算に使用されるこの関数は、重大なものではなく、多くの各種
関数を使用し得る。この関数は、次のような単純な累加関数とすることができる
。
よってブロック・ポインタ１２８ａを演算する。ブロック・ポインタ値１２８ｂ
は、ブロック・ポインタ１２８ａの値に関数を適用することによって演算される
。ポインタ値の演算に使用されるこの関数は、重大なものではなく、多くの各種
関数を使用し得る。この関数は、次のような単純な累加関数とすることができる
。
【０１１０】 keyn = keyn-1 + 1 あるいは、この関数をＭＤ５ハッシュ関数等の複雑な関数とすることもできる。
【０１１１】 keyn = MD5(keyn-1) 唯一求められる要件は、可能性のあるキーの値の範囲が充分に大きく、その反復
に充分な選択があり、範囲の衝突または周期的なルーピングの可能性が小さいこ
とである。可能性は非常に低いがキーの衝突を生じた場合には、オブジェクトが
キャッシュから削除される。
に充分な選択があり、範囲の衝突または周期的なルーピングの可能性が小さいこ
とである。可能性は非常に低いがキーの衝突を生じた場合には、オブジェクトが
キャッシュから削除される。
【０１１２】 このチェーン内の最後のポインタ・ブロック１４１ｄは、テー
ル・ブロック１４１ｅをポイントするブロック・ポインタ１２８ｄを有している
。テール・ブロック１４１ｅは、このチェーン内の最初のブロック１４１ａに対
する参照を含む。一実施例によれば、テール・ブロック１４１ｅに包含されてい
る参照は、オブジェクトＸのオブジェクト・キーの、９６ビットのサブキー１３
２である。キャッシュは、この９６ビットのサブキー１３２を使用してヘッド・
ブロック１２８ａを見つけ出すことができる。テール・ブロック１４１ｅおよび
それによって提供されるポインタのループ構成により、キャッシュ８０は、チェ
ーン内の任意のブロックから開始してすべてのブロックを見つけ出すことができ
る。
ル・ブロック１４１ｅをポイントするブロック・ポインタ１２８ｄを有している
。テール・ブロック１４１ｅは、このチェーン内の最初のブロック１４１ａに対
する参照を含む。一実施例によれば、テール・ブロック１４１ｅに包含されてい
る参照は、オブジェクトＸのオブジェクト・キーの、９６ビットのサブキー１３
２である。キャッシュは、この９６ビットのサブキー１３２を使用してヘッド・
ブロック１２８ａを見つけ出すことができる。テール・ブロック１４１ｅおよび
それによって提供されるポインタのループ構成により、キャッシュ８０は、チェ
ーン内の任意のブロックから開始してすべてのブロックを見つけ出すことができ
る。
【０１１３】 図５に示した３つのフラグメント２０８ａ、２０８ｂ、および
２０８ｃは、単に例示のみを目的とする。実際には、情報オブジェクトが任意数
のフラグメントを占有し、あるいは参照し、そのそれぞれが、ディレクトリ・テ
ーブル１１０内のそれ独自のポインタ・ブロックによって識別されることになる
。
２０８ｃは、単に例示のみを目的とする。実際には、情報オブジェクトが任意数
のフラグメントを占有し、あるいは参照し、そのそれぞれが、ディレクトリ・テ
ーブル１１０内のそれ独自のポインタ・ブロックによって識別されることになる
。
【０１１４】 オブジェクト５２をストレージ・デバイスから読み出すとき、
最後のフラグメントにストアされているコンテンツのＭＤ５キーがディレクトリ
・キー値に一致することを保証するために、それが最初に読み出される。このテ
ストは、適正なオブジェクトが見つけ出されたことを保証するための「健全性」
チェックとして行われる。一致がなければ、衝突が生じ、異常が発生しているこ
とになる。
最後のフラグメントにストアされているコンテンツのＭＤ５キーがディレクトリ
・キー値に一致することを保証するために、それが最初に読み出される。このテ
ストは、適正なオブジェクトが見つけ出されたことを保証するための「健全性」
チェックとして行われる。一致がなければ、衝突が生じ、異常が発生しているこ
とになる。
【０１１５】 （空間割り当て） 図１０Ａは、新しくキャッシュに入れられたオブジェクトに空間を割り当て、
そのオブジェクトを割り当てた空間に書き込むための方法を示したフローチャー
トである。割り当ておよび書き込みの方法は、参照番号６４０によって包括的に
示されている。概して、図１０Ａに示したステップは、たとえば図８Ｆのステッ
プ８９８における場合のように、ディレクトリ・テーブルおよびタグ・テーブル
内においてミスが生じたときに実行される。
そのオブジェクトを割り当てた空間に書き込むための方法を示したフローチャー
トである。割り当ておよび書き込みの方法は、参照番号６４０によって包括的に
示されている。概して、図１０Ａに示したステップは、たとえば図８Ｆのステッ
プ８９８における場合のように、ディレクトリ・テーブルおよびタグ・テーブル
内においてミスが生じたときに実行される。
【０１１６】 つまり、情報オブジェクトがクライアントから要求されたがキ
ャッシュ内に見つからなかったとき、ステップ６４２においてその情報オブジェ
クトをルックアップし、その発信ロケーションからそれを取り出す。ネットワー
ク環境においては、発信ロケーションがサーバ４０、クラスタ、またはディスク
になる。オブジェクトを取り出すと、ステップ６４４において、そのオブジェク
トのタイプおよびサイズがキャッシュ内にストア可能か否か、つまり「キャッシ
ュ可能であるか」について評価する。
ャッシュ内に見つからなかったとき、ステップ６４２においてその情報オブジェ
クトをルックアップし、その発信ロケーションからそれを取り出す。ネットワー
ク環境においては、発信ロケーションがサーバ４０、クラスタ、またはディスク
になる。オブジェクトを取り出すと、ステップ６４４において、そのオブジェク
トのタイプおよびサイズがキャッシュ内にストア可能か否か、つまり「キャッシ
ュ可能であるか」について評価する。
【０１１７】 キャッシュ可能でないオブジェクトの例としては、サーバ・ア
プリケーションによって動的に生成されるウェブ・ページ、クライアント側アプ
レットによって生成されるウェブ・ページのペインまたは部分、データベースか
らの動的データに基づいて構築されるオブジェクト、およびその他の非静的オブ
ジェクトが挙げられる。そういったオブジェクトは、それらが生成されるごとに
そのフォームとコンテンツが変化することからキャッシュ内にストアすることが
できない。その種のオブジェクトをキャッシュ内にストアした場合には、キャッ
シュのアクセスとアクセスの間にその基礎をなす動的データが変更されると、オ
ブジェクトの信頼性が失われるか、正しくなくなる。プロセスは、サーバ４０ま
たはその他のオブジェクトのソースからのＨＴＴＰ応答内に含まれている情報を
調べて、そのオブジェクトがキャッシュ可能か否か判断する。
プリケーションによって動的に生成されるウェブ・ページ、クライアント側アプ
レットによって生成されるウェブ・ページのペインまたは部分、データベースか
らの動的データに基づいて構築されるオブジェクト、およびその他の非静的オブ
ジェクトが挙げられる。そういったオブジェクトは、それらが生成されるごとに
そのフォームとコンテンツが変化することからキャッシュ内にストアすることが
できない。その種のオブジェクトをキャッシュ内にストアした場合には、キャッ
シュのアクセスとアクセスの間にその基礎をなす動的データが変更されると、オ
ブジェクトの信頼性が失われるか、正しくなくなる。プロセスは、サーバ４０ま
たはその他のオブジェクトのソースからのＨＴＴＰ応答内に含まれている情報を
調べて、そのオブジェクトがキャッシュ可能か否か判断する。
【０１１８】 そのオブジェクトがキャッシュ可能であれば、この方法では、
ステップ６４６においてそのオブジェクトのバイト数で表される長さを獲得する
。たとえば、ワールド・ワイド・ウェブに関連して本発明の適用があるときは、
ＨＴＴＰトランザクションにおいて運ばれるメタデータ内に、そのウェブ・ペー
ジの長さを含ませることができる。その場合キャッシュは、情報オブジェクトを
含むＨＴＴＰメッセージ内の応答情報から、その情報オブジェクトの長さを抽出
する。長さが含まれていないときには、推定が行われる。この推定が正しくない
こともあり、それによってオブジェクトのフラグメント化を招くことになる。
ステップ６４６においてそのオブジェクトのバイト数で表される長さを獲得する
。たとえば、ワールド・ワイド・ウェブに関連して本発明の適用があるときは、
ＨＴＴＰトランザクションにおいて運ばれるメタデータ内に、そのウェブ・ペー
ジの長さを含ませることができる。その場合キャッシュは、情報オブジェクトを
含むＨＴＴＰメッセージ内の応答情報から、その情報オブジェクトの長さを抽出
する。長さが含まれていないときには、推定が行われる。この推定が正しくない
こともあり、それによってオブジェクトのフラグメント化を招くことになる。
【０１１９】 ブロック６４８として示したように、続いてメモリ常駐の書き
込み集成バッファ内に空間を割り当て、書き込みをおこなうオブジェクトを、割
り当てられたバッファ・ロケーション内に流し込む。好ましい実施例においては
、ブロック６４８が、充分な空間を有し、オブジェクトの保持に使用できる書き
込み集成バッファ内の空間割り当てを伴う。ブロック６５０においてキャッシュ
は、書き込み集成バッファに空き空間が残っているか否かを評価する。残ってい
れば、割り当ておよび書き込みプロセスを完了し、キャッシュ８０は別のタスク
を実行することが可能になる。書き込み集成バッファがいっぱいになると、ブロ
ック６５０の内容が肯定されてコントロールがブロック６５６に移される。
込み集成バッファ内に空間を割り当て、書き込みをおこなうオブジェクトを、割
り当てられたバッファ・ロケーション内に流し込む。好ましい実施例においては
、ブロック６４８が、充分な空間を有し、オブジェクトの保持に使用できる書き
込み集成バッファ内の空間割り当てを伴う。ブロック６５０においてキャッシュ
は、書き込み集成バッファに空き空間が残っているか否かを評価する。残ってい
れば、割り当ておよび書き込みプロセスを完了し、キャッシュ８０は別のタスク
を実行することが可能になる。書き込み集成バッファがいっぱいになると、ブロ
ック６５０の内容が肯定されてコントロールがブロック６５６に移される。
【０１２０】 ブロック６５６においてキャッシュは、集成バッファを、それ
がシャドーイング(shadowing)しているアリーナに書き込む。ステップ６６０に
おいては、ディレクトリが更新されて、新しい情報オブジェクトの位置が反映さ
れる。
がシャドーイング(shadowing)しているアリーナに書き込む。ステップ６６０に
おいては、ディレクトリが更新されて、新しい情報オブジェクトの位置が反映さ
れる。
【０１２１】 以上の一連のステップは、キャッシュに書き込まれる情報オブ
ジェクトの完全性が保証される形に整理されている。たとえば、ディレクトリは
、ヘッダおよびデータを含めて完全な情報オブジェクトがアリーナに書き込まれ
た後にのみ更新される。またたとえば、ステップ６５２またはステップ６５８の
完了前に、ディスク・ドライブまたはシステムのその他のエレメントがクラッシ
ュした場合にも悪影響が生じない。その場合アリーナは、信頼性のない、もしく
は不完全なデータを含むことになるが、インデクス、またはハッシュ・テーブル
内に信頼性を失ったデータに対する参照がまったく存在しないことから、実質的
にキャッシュによってそれが無視される。それに加えて、信頼性のない、もしく
は不完全なデータは、次に述べるガーベジ・コレクション・プロセスを使用して
最終的に再利用される。
ジェクトの完全性が保証される形に整理されている。たとえば、ディレクトリは
、ヘッダおよびデータを含めて完全な情報オブジェクトがアリーナに書き込まれ
た後にのみ更新される。またたとえば、ステップ６５２またはステップ６５８の
完了前に、ディスク・ドライブまたはシステムのその他のエレメントがクラッシ
ュした場合にも悪影響が生じない。その場合アリーナは、信頼性のない、もしく
は不完全なデータを含むことになるが、インデクス、またはハッシュ・テーブル
内に信頼性を失ったデータに対する参照がまったく存在しないことから、実質的
にキャッシュによってそれが無視される。それに加えて、信頼性のない、もしく
は不完全なデータは、次に述べるガーベジ・コレクション・プロセスを使用して
最終的に再利用される。
【０１２２】 （ガーベジ・コレクション） 図８Ａは、キャッシュ８０に使用可能なガーベジ・コレクションの方法を示し
たフローチャートである。図８Ｂは、図８Ａに示したステップの細部を示したフ
ローチャートであり、図８Ａとともに説明する。好ましくは、ガーベジ・コレク
ション方法を、キャッシュに関連のある別のプロセスと並行に走る独立なプロセ
スとして実装する。これにより、このガーベジ・コレクション方法は、キャッシ
ュのオペレーションに割り込み、あるいはそれに影響を与えることなく、定期的
にキャッシュのストレージ・エリアをクリーン・アップすることができる。
たフローチャートである。図８Ｂは、図８Ａに示したステップの細部を示したフ
ローチャートであり、図８Ａとともに説明する。好ましくは、ガーベジ・コレク
ション方法を、キャッシュに関連のある別のプロセスと並行に走る独立なプロセ
スとして実装する。これにより、このガーベジ・コレクション方法は、キャッシ
ュのオペレーションに割り込み、あるいはそれに影響を与えることなく、定期的
にキャッシュのストレージ・エリアをクリーン・アップすることができる。
【０１２３】 （１．全般プロセス） 好ましい実施例においては、「ガーベジ・コレクション」は、ターゲット・ア
リーナのスキャン、アクティブ・フラグメントの識別またはフラグメントを削除
すべきか否かの決定、隣接する新しいアリーナへのアクティブ・フラグメントの
書き込み、およびフラグメントの新しいロケーションを参照すべく行うディレク
トリ・テーブルの更新からなるプロセスを意味する。つまり、非常に広い意味で
この方法は「退避」タイプであり、それにおいては古いもしくは不必要なフラグ
メントが削除されてアクティブ・フラグメントが別の場所に書き込まれ、その結
果、特定のアリーナに対するガーベジ・コレクション・オペレーションが完了し
たとき、そのアリーナが空になる。好ましくは、ターゲット・アリーナおよび新
しいアリーナがともに、揮発性メモリ内においてストアされ、操作される。ガー
ベジ・コレクションが完了すると、同期化と呼ばれるプロセスにおいて、ディス
ク等の不揮発性ストレージにストアされる、対応するアリーナにガーベジ・コレ
クションにおいて生じた変更が書き込まれる。
リーナのスキャン、アクティブ・フラグメントの識別またはフラグメントを削除
すべきか否かの決定、隣接する新しいアリーナへのアクティブ・フラグメントの
書き込み、およびフラグメントの新しいロケーションを参照すべく行うディレク
トリ・テーブルの更新からなるプロセスを意味する。つまり、非常に広い意味で
この方法は「退避」タイプであり、それにおいては古いもしくは不必要なフラグ
メントが削除されてアクティブ・フラグメントが別の場所に書き込まれ、その結
果、特定のアリーナに対するガーベジ・コレクション・オペレーションが完了し
たとき、そのアリーナが空になる。好ましくは、ターゲット・アリーナおよび新
しいアリーナがともに、揮発性メモリ内においてストアされ、操作される。ガー
ベジ・コレクションが完了すると、同期化と呼ばれるプロセスにおいて、ディス
ク等の不揮発性ストレージにストアされる、対応するアリーナにガーベジ・コレ
クションにおいて生じた変更が書き込まれる。
【０１２４】 ステップ８０２において、プール２００ａ〜２００ｎの１つが
ガーベジ・コレクション・オペレーション用に選択される。好ましくは、ストレ
ージ・デバイス９０ａのそれぞれのプール２００ａ〜２００ｎごとに、キャッシ
ュが、現在アクティブ・データをストアしているプール内のディスク空間の量を
示す値をストアしているか、あるいはそれにアクセスできるものとする。またキ
ャッシュは、ブロック８０３に示されるように、一定の「低水位」および「高水
位」値をストアしている。特定プールのアクティブ・ストレージの量が「高水位
」値を超えると、ガーベジ・コレクションが開始され、そのプール内のアクティ
ブ・ストレージの量が「低水位」を下回るまで繰り返される。「低水位」値は、
ゼロより大きくなるように選択され、「高水位」値は、プールの合計容量より約
２０％少なくなるように選択される。このようにしてプールがオーバーフローす
る前に、あるいはストレージ・デバイス９０ａの容量超過を招く前にガーベジ・
コレクションが実行される。
ガーベジ・コレクション・オペレーション用に選択される。好ましくは、ストレ
ージ・デバイス９０ａのそれぞれのプール２００ａ〜２００ｎごとに、キャッシ
ュが、現在アクティブ・データをストアしているプール内のディスク空間の量を
示す値をストアしているか、あるいはそれにアクセスできるものとする。またキ
ャッシュは、ブロック８０３に示されるように、一定の「低水位」および「高水
位」値をストアしている。特定プールのアクティブ・ストレージの量が「高水位
」値を超えると、ガーベジ・コレクションが開始され、そのプール内のアクティ
ブ・ストレージの量が「低水位」を下回るまで繰り返される。「低水位」値は、
ゼロより大きくなるように選択され、「高水位」値は、プールの合計容量より約
２０％少なくなるように選択される。このようにしてプールがオーバーフローす
る前に、あるいはストレージ・デバイス９０ａの容量超過を招く前にガーベジ・
コレクションが実行される。
【０１２５】 （２．用法を意識したガーベジ・コレクション） ステップ８０４においては、ガーベジ・コレクションを実行するターゲットと
してアリーナの１つが選択される。このアリーナは、各種の要因を考慮した選択
アルゴリズムによって選択される。ブロック８０５として示したように、この要
因には、たとえばキャッシュ８０によってアクセスされた最後のアリーナである
か否か、およびそのアリーナに対する合計アクセス回数が含まれる。別の実施例
においては、この要因として、各アリーナから削除された情報オブジェクトの数
、また最後にそのアリーナが使用されたのはいつか、各アリーナに対して最後に
ガーベジ・コレクションが行われたのはいつか、さらに現在アリーナに読み出し
または書き込みのロックがセットされているか、といったことを含めてもよい。
ガーベジ・コレクション用にアリーナを選択した後は、そのオブジェクト内のす
べてのフラグメントをガーベジ・コレクションの対象として個別に考慮する。
してアリーナの１つが選択される。このアリーナは、各種の要因を考慮した選択
アルゴリズムによって選択される。ブロック８０５として示したように、この要
因には、たとえばキャッシュ８０によってアクセスされた最後のアリーナである
か否か、およびそのアリーナに対する合計アクセス回数が含まれる。別の実施例
においては、この要因として、各アリーナから削除された情報オブジェクトの数
、また最後にそのアリーナが使用されたのはいつか、各アリーナに対して最後に
ガーベジ・コレクションが行われたのはいつか、さらに現在アリーナに読み出し
または書き込みのロックがセットされているか、といったことを含めてもよい。
ガーベジ・コレクション用にアリーナを選択した後は、そのオブジェクト内のす
べてのフラグメントをガーベジ・コレクションの対象として個別に考慮する。
【０１２６】 ステップ８０６においては、選択したアリーナ内のフラグメン
トの１つをガーベジ・コレクションの対象として選択する。いずれのフラグメン
ト（１ないしは複数）を選択するかの決定において、キャッシュ８０は、ブロッ
ク８０７に示されるようにいくつかの選択要因を考慮する。好ましい実施例にお
いては、この要因に次のものが含まれる：すなわち、そのフラグメントに最後に
アクセスした時刻；そのフラグメント内にデータを有するオブジェクトに対して
発生したヒットの数；そのフラグメントからクライアントにデータをダウンロー
ドするために必要な時間；および、そのフラグメントを一部として構成されるオ
ブジェクトのサイズである。別の実施例においては別の要因が考慮される。これ
らの要因に関する値は、そのフラグメントがデータをストアしているオブジェク
トに関連付けされたブロック１１２ａ〜１１２ｎにストアされている。
トの１つをガーベジ・コレクションの対象として選択する。いずれのフラグメン
ト（１ないしは複数）を選択するかの決定において、キャッシュ８０は、ブロッ
ク８０７に示されるようにいくつかの選択要因を考慮する。好ましい実施例にお
いては、この要因に次のものが含まれる：すなわち、そのフラグメントに最後に
アクセスした時刻；そのフラグメント内にデータを有するオブジェクトに対して
発生したヒットの数；そのフラグメントからクライアントにデータをダウンロー
ドするために必要な時間；および、そのフラグメントを一部として構成されるオ
ブジェクトのサイズである。別の実施例においては別の要因が考慮される。これ
らの要因に関する値は、そのフラグメントがデータをストアしているオブジェク
トに関連付けされたブロック１１２ａ〜１１２ｎにストアされている。
【０１２７】 ブロック８０８においてキャッシュは、そのフラグメントを削
除すべきか否かを判断する。好ましい実施例においては、ブロック８０８が、あ
る種のパフォーマンス要因および最適化の考慮事項の評価を伴う。
除すべきか否かを判断する。好ましい実施例においては、ブロック８０８が、あ
る種のパフォーマンス要因および最適化の考慮事項の評価を伴う。
【０１２８】 キャッシュは、主に２つの理由から使用されるが、これらの理
由は衝突の可能性を抱えている。最初の理由は、クライアントのパフォーマンス
向上である。クライアントのパフォーマンスを向上させるためには、ガーベジ・
コレクタにとって、サーバのダウンロード時間を最小にするオブジェクトを保持
しておくことが望ましい。これは、遅い外部サーバから受け取ったドキュメント
をキャッシュさせる方向にガーベジ・コレクタを偏らせる傾向がある。第２の理
由は、サーバのネットワーク・トラフィックの最小化である。サーバ・トラフィ
ックを最小化するためには、ガーベジ・コレクタにとって、大きなオブジェクト
を保持しておくことが望ましい。これらの最適化はしばしば衝突する。
由は衝突の可能性を抱えている。最初の理由は、クライアントのパフォーマンス
向上である。クライアントのパフォーマンスを向上させるためには、ガーベジ・
コレクタにとって、サーバのダウンロード時間を最小にするオブジェクトを保持
しておくことが望ましい。これは、遅い外部サーバから受け取ったドキュメント
をキャッシュさせる方向にガーベジ・コレクタを偏らせる傾向がある。第２の理
由は、サーバのネットワーク・トラフィックの最小化である。サーバ・トラフィ
ックを最小化するためには、ガーベジ・コレクタにとって、大きなオブジェクト
を保持しておくことが望ましい。これらの最適化はしばしば衝突する。
【０１２９】 オブジェクトをダウンロードするために必要な時間、そのオブ
ジェクトのサイズ、およびキャッシュ内においてそのオブジェクトがヒットした
回数を識別する値をストアすることによって、ガーベジ・コレクタは、それぞれ
のオブジェクトについて、オリジナルのサーバからフェッチする代わりにキャッ
シュしたコピーを提供した結果、どの程度サーバのダウンロード時間が回避され
たか、またどの程度のサーバ・トラフィックが不要になったかを評価することが
できる。この測定は、キャッシュされたオブジェクトの「固有値」を評価する。
ジェクトのサイズ、およびキャッシュ内においてそのオブジェクトがヒットした
回数を識別する値をストアすることによって、ガーベジ・コレクタは、それぞれ
のオブジェクトについて、オリジナルのサーバからフェッチする代わりにキャッ
シュしたコピーを提供した結果、どの程度サーバのダウンロード時間が回避され
たか、またどの程度のサーバ・トラフィックが不要になったかを評価することが
できる。この測定は、キャッシュされたオブジェクトの「固有値」を評価する。
【０１３０】 キャッシュ・アドミニストレータは、続いて時間のセーブまた
はトラフィックのセーブのためにキャッシュを最適化する程度を表す０から１ま
での範囲のパラメータを設定する。上記の値は、そのアリーナ内の別のオブジェ
クトとの関連から、そのオブジェクトが消費している空間の量との関連から、お
よび最近ガーベジ・コレクションの対象となったオブジェクトとの関連から評価
される。この種の評価に基づいて、キャッシュ８０は、ステップ８０８に示され
るようにフラグメントを削除すべきか否かを判断する。
はトラフィックのセーブのためにキャッシュを最適化する程度を表す０から１ま
での範囲のパラメータを設定する。上記の値は、そのアリーナ内の別のオブジェ
クトとの関連から、そのオブジェクトが消費している空間の量との関連から、お
よび最近ガーベジ・コレクションの対象となったオブジェクトとの関連から評価
される。この種の評価に基づいて、キャッシュ８０は、ステップ８０８に示され
るようにフラグメントを削除すべきか否かを判断する。
【０１３１】 そのフラグメントを削除すべきと判断した場合には、ステップ
８１２において削除済みとマークを付け、そのフラグメント内にデータを上書き
することによってそれを削除する。オブジェクト５２が複数のフラグメント内に
ストアされており、ガーベジ・コレクション・プロセスがそのフラグメントの１
つを削除すべきであると判断したときは、プロセスは、そのオブジェクトに関連
付けされたすべてのフラグメントを削除する。これには、図５に示したタイプの
、別のアリーナに、さらには別のプールに続くフラグメントのチェーンが関係す
ることもある。
８１２において削除済みとマークを付け、そのフラグメント内にデータを上書き
することによってそれを削除する。オブジェクト５２が複数のフラグメント内に
ストアされており、ガーベジ・コレクション・プロセスがそのフラグメントの１
つを削除すべきであると判断したときは、プロセスは、そのオブジェクトに関連
付けされたすべてのフラグメントを削除する。これには、図５に示したタイプの
、別のアリーナに、さらには別のプールに続くフラグメントのチェーンが関係す
ることもある。
【０１３２】 そのフラグメントを削除すべきでないと判断した場合には、ス
テップ８１０においてそのフラグメントを新しいアリーナに書き込む。次に説明
する図８Ｂは、ステップ８１０の実行に関連する好ましいサブステップを示して
いる。
テップ８１０においてそのフラグメントを新しいアリーナに書き込む。次に説明
する図８Ｂは、ステップ８１０の実行に関連する好ましいサブステップを示して
いる。
【０１３３】 フラグメントを削除し、あるいは別のアリーナに移動した後は
、ステップ８１４においてディレクトリ・テーブル１１０を更新してフラグメン
トの新しい位置を反映させる。ステップ８１４は、そのフラグメントに関連付け
されているブロック１１２ａ〜１１２ｎをルックアップするために更新すべきフ
ラグメント２０８ｎに関連付けされたフラグメント・ヘッダ２０８ｄ内のキー値
２０６ａの使用を必要とする。適正なディレクトリ・テーブル・ブロック１１２
ａ〜１１２ｎが識別されると、ブロック内のディスク・ロケーション値１１８を
更新してフラグメントの新しい位置を反映させる。フラグメントを削除した場合
には、続いて対応するディレクトリ・テーブルのエントリを削除する。
、ステップ８１４においてディレクトリ・テーブル１１０を更新してフラグメン
トの新しい位置を反映させる。ステップ８１４は、そのフラグメントに関連付け
されているブロック１１２ａ〜１１２ｎをルックアップするために更新すべきフ
ラグメント２０８ｎに関連付けされたフラグメント・ヘッダ２０８ｄ内のキー値
２０６ａの使用を必要とする。適正なディレクトリ・テーブル・ブロック１１２
ａ〜１１２ｎが識別されると、ブロック内のディスク・ロケーション値１１８を
更新してフラグメントの新しい位置を反映させる。フラグメントを削除した場合
には、続いて対応するディレクトリ・テーブルのエントリを削除する。
【０１３４】 ステップ８１６は、この方法がディレクトリ・テーブル１１０
の更新後に完了することを示している。しかしながらここで、図８Ａに示したス
テップがすべてのプール、各プール内のすべてのアリーナ、さらに各アリーナ内
のすべてのフラグメントに対して実行されることを理解されたい。
の更新後に完了することを示している。しかしながらここで、図８Ａに示したス
テップがすべてのプール、各プール内のすべてのアリーナ、さらに各アリーナ内
のすべてのフラグメントに対して実行されることを理解されたい。
【０１３５】 （３．新しいアリーナへのフラグメントの書き込み） 図８Ｂは、ステップ８１０の実行に関連するステップ、つまり新しいアリーナ
への、保存すべきフラグメントの書き込みに関連するステップを表したフローチ
ャートである。退避するフラグメントを新しいアリーナに書き込むプロセスは、
オリジナルのフラグメントに書き込むプロセスと完全に類似している。データは
、書き込み集成バッファに書き込まれ、いっぱいになるとディスクのアリーナに
落とされる。
への、保存すべきフラグメントの書き込みに関連するステップを表したフローチ
ャートである。退避するフラグメントを新しいアリーナに書き込むプロセスは、
オリジナルのフラグメントに書き込むプロセスと完全に類似している。データは
、書き込み集成バッファに書き込まれ、いっぱいになるとディスクのアリーナに
落とされる。
【０１３６】 ステップ５９０においては、ディレクトリ・テーブルを更新し
、そのフラグメントの位置の変更を反映させる。好ましい実施例においては、ス
テップ５９０が、ディレクトリ・テーブル１１０に対する直接的な更新ではなく
、オープン・ディレクトリ１３０への更新情報の書き込みを伴う。その後、プロ
セスによって、そのフラグメント・データ２０８ｅが異常なくストレージ・デバ
イス９０ａ〜９０ｎの１つに書き込まれたことが確認できたとき、オープン・デ
ィレクトリ１３０内に反映されている変更をディレクトリ・テーブル１１０内に
書き込み、つまりそれを同期させる。
、そのフラグメントの位置の変更を反映させる。好ましい実施例においては、ス
テップ５９０が、ディレクトリ・テーブル１１０に対する直接的な更新ではなく
、オープン・ディレクトリ１３０への更新情報の書き込みを伴う。その後、プロ
セスによって、そのフラグメント・データ２０８ｅが異常なくストレージ・デバ
イス９０ａ〜９０ｎの１つに書き込まれたことが確認できたとき、オープン・デ
ィレクトリ１３０内に反映されている変更をディレクトリ・テーブル１１０内に
書き込み、つまりそれを同期させる。
【０１３７】 このプロセスは、ディレクトリ・テーブル１１０の完全性が常
に保護されることを保証するために使用される。前述したように、バッファされ
たストレージは、フラグメントのために使用される；つまり、フラグメントが更
新され、あるいは新しいフラグメントが書き込まれたとき、フラグメント・デー
タがバッファに書き込まれ、その後、将来においてディスクまたはその他のスト
レージ・デバイスに引き渡される。したがって、ガーベジ・コレクション・プロ
セスがディレクトリ・テーブルの更新の準備が整ったとき、ガーベジ・コレクシ
ョンの間に新しいアリーナに移動されたフラグメントが、実際にストレージ・デ
バイスの１つに書き込まれていないということがあり得る。そこで、変更がディ
スクに引き渡されるまで、変更に関する情報をオープン・ディレクトリ１３０内
にストアしておく。
に保護されることを保証するために使用される。前述したように、バッファされ
たストレージは、フラグメントのために使用される；つまり、フラグメントが更
新され、あるいは新しいフラグメントが書き込まれたとき、フラグメント・デー
タがバッファに書き込まれ、その後、将来においてディスクまたはその他のスト
レージ・デバイスに引き渡される。したがって、ガーベジ・コレクション・プロ
セスがディレクトリ・テーブルの更新の準備が整ったとき、ガーベジ・コレクシ
ョンの間に新しいアリーナに移動されたフラグメントが、実際にストレージ・デ
バイスの１つに書き込まれていないということがあり得る。そこで、変更がディ
スクに引き渡されるまで、変更に関する情報をオープン・ディレクトリ１３０内
にストアしておく。
【０１３８】 ステップ５９２においては、オリジナルのアリーナを調べて再
利用、もしくは新しいアリーナへの移動を必要とするフラグメントが残っている
か否かを評価する。ほかのオブジェクトが存在するときは、コントロールを図８
Ａのステップ８０６に戻し、その結果、次のオブジェクトの処理が可能になる。
現在のアリーナ内にほかのオブジェクトが存在しない場合には、ステップ５９４
において、現在のアリーナのトップ・ポインタをリセットする。
利用、もしくは新しいアリーナへの移動を必要とするフラグメントが残っている
か否かを評価する。ほかのオブジェクトが存在するときは、コントロールを図８
Ａのステップ８０６に戻し、その結果、次のオブジェクトの処理が可能になる。
現在のアリーナ内にほかのオブジェクトが存在しない場合には、ステップ５９４
において、現在のアリーナのトップ・ポインタをリセットする。
【０１３９】 （４．バッファリング） 好ましい実施例においては、読み出しおよび書き込みのオペレーションがキャ
ッシュ８０によって実行され、ガーベジ・コレクション・プロセスが２とおりに
バッファされる。
ッシュ８０によって実行され、ガーベジ・コレクション・プロセスが２とおりに
バッファされる。
【０１４０】 まず、キャッシュ８０と、ブラウザからオブジェクトを要求し
ているクライアント１０ａの間の通信が「Ｖコネクション（VConnection）」と
呼ばれるデータ構造のフロー・コントロール、ストリーミング、およびバッファ
リングを介してバッファされる。好ましい実施例においては、キャッシュ８０が
オブジェクト指向プログラム言語により準備されたコンピュータ・プログラムの
セット内において実装される。この実施例においてＶコネクションは、プログラ
ムの１つによって宣言されたオブジェクトであり、Ｖコネクションは、メモリ内
においてバッファをカプセル化する。好ましくはこのバッファはＦＩＦＯバッフ
ァであり、そのサイズを３２キロバイトとする。
ているクライアント１０ａの間の通信が「Ｖコネクション（VConnection）」と
呼ばれるデータ構造のフロー・コントロール、ストリーミング、およびバッファ
リングを介してバッファされる。好ましい実施例においては、キャッシュ８０が
オブジェクト指向プログラム言語により準備されたコンピュータ・プログラムの
セット内において実装される。この実施例においてＶコネクションは、プログラ
ムの１つによって宣言されたオブジェクトであり、Ｖコネクションは、メモリ内
においてバッファをカプセル化する。好ましくはこのバッファはＦＩＦＯバッフ
ァであり、そのサイズを３２キロバイトとする。
【０１４１】 クライアント１０ａ〜１０ｃがキャッシュ８０に接続すると、
キャッシュはそのクライアントをＶコネクションに割り当てる。クライアント１
０ａから受け取ったデータは、Ｖコネクションを介してキャッシュ８０に渡され
、キャッシュが情報をクライアント１０ａに送る必要があるときには、キャッシ
ュはその情報をＶコネクションに書き込む。Ｖコネクションは、キャッシュ８０
からのデータのフローを、クライアント１０ａによってキャッシュとの通信に使
用される送信速度と整合させるべく調整する。このようにして、Ｖコネクション
の使用は、メイン・メモリ・ストレージの不必要な無駄を回避する。この種の無
駄は、クライアント１０ａに送信するオブジェクトの全体をメモリにコピーし、
その後それをクライアントに送信する場合に生じ、遅いクライアントへの送信の
間、メイン・メモリが不必要に拘束される。これらのメカニズムを使用するバッ
ファ付きＩ／Ｏは、ディスクに対して実行される連続した読み出しおよび書き込
みのオペレーションの回数を低減する傾向にある。
キャッシュはそのクライアントをＶコネクションに割り当てる。クライアント１
０ａから受け取ったデータは、Ｖコネクションを介してキャッシュ８０に渡され
、キャッシュが情報をクライアント１０ａに送る必要があるときには、キャッシ
ュはその情報をＶコネクションに書き込む。Ｖコネクションは、キャッシュ８０
からのデータのフローを、クライアント１０ａによってキャッシュとの通信に使
用される送信速度と整合させるべく調整する。このようにして、Ｖコネクション
の使用は、メイン・メモリ・ストレージの不必要な無駄を回避する。この種の無
駄は、クライアント１０ａに送信するオブジェクトの全体をメモリにコピーし、
その後それをクライアントに送信する場合に生じ、遅いクライアントへの送信の
間、メイン・メモリが不必要に拘束される。これらのメカニズムを使用するバッ
ファ付きＩ／Ｏは、ディスクに対して実行される連続した読み出しおよび書き込
みのオペレーションの回数を低減する傾向にある。
【０１４２】 （５．同期および一貫性の強化） ガーベジ・コレクション・プロセスの間およびキャッシュ８０のオペレーショ
ンの間は、規則的に同期化プロセスが実行される。同期化プロセスは、オープン
・ディレクトリ１３０内に反映されている変更をディレクトリ・テーブル１１０
および、ストレージ・デバイス９０ａ〜９０ｎの１つもしくはいくつかに含まれ
る不揮発性ストレージ等の安定したストレージに渡す。その目的は、ディスク上
のデータの一貫性を常に維持することにある。つまり、任意の瞬間において、デ
ィスク上のデータ構造の状態が１００％無矛盾であり、キャッシュが、チェック
を必要とすることなくスタート・アップできることである。これは、ディスクに
対するデータならびにメタデータの書き込みおよび同期を慎重に定めることによ
って達成される。
ンの間は、規則的に同期化プロセスが実行される。同期化プロセスは、オープン
・ディレクトリ１３０内に反映されている変更をディレクトリ・テーブル１１０
および、ストレージ・デバイス９０ａ〜９０ｎの１つもしくはいくつかに含まれ
る不揮発性ストレージ等の安定したストレージに渡す。その目的は、ディスク上
のデータの一貫性を常に維持することにある。つまり、任意の瞬間において、デ
ィスク上のデータ構造の状態が１００％無矛盾であり、キャッシュが、チェック
を必要とすることなくスタート・アップできることである。これは、ディスクに
対するデータならびにメタデータの書き込みおよび同期を慎重に定めることによ
って達成される。
【０１４３】 説明のため、このセクションにおいては、キャッシュに対して
ストアが要求された実際のオブジェクトを「データ」とする。たとえば、キャッ
シュがＨＴＭＬドキュメントをストアしているとき、データはそのドキュメント
そのものとなる。「メタデータ」は、キャッシュが「データ」をインデクスし、
その後のｌｏｏｋｕｐ（）オペレーション（ルックアップ・オペレーション）の
間に見つけられるようにするためにストアを必要とする追加の情報、およびキャ
ッシュが「データ」用の空間を割り当てるために必要とする情報を指す。「メタ
データ」は、ディレクトリおよびプール・ヘッダからなる。ディレクトリは、キ
ー（名前）をディスク上の特定の位置（データ）に関連付けするためにキャッシ
ュによって使用されるインデクスである。キャッシュは、プール・ヘッダを使用
してキャッシュ内に割り当てられたディスク空間を追跡している。
ストアが要求された実際のオブジェクトを「データ」とする。たとえば、キャッ
シュがＨＴＭＬドキュメントをストアしているとき、データはそのドキュメント
そのものとなる。「メタデータ」は、キャッシュが「データ」をインデクスし、
その後のｌｏｏｋｕｐ（）オペレーション（ルックアップ・オペレーション）の
間に見つけられるようにするためにストアを必要とする追加の情報、およびキャ
ッシュが「データ」用の空間を割り当てるために必要とする情報を指す。「メタ
データ」は、ディレクトリおよびプール・ヘッダからなる。ディレクトリは、キ
ー（名前）をディスク上の特定の位置（データ）に関連付けするためにキャッシ
ュによって使用されるインデクスである。キャッシュは、プール・ヘッダを使用
してキャッシュ内に割り当てられたディスク空間を追跡している。
【０１４４】 キャッシュは、ディスク上のデータ構造の一貫性を維持するた
めに２つの規則を使用する。最初の規則は、メタデータを、必ずそれがポイント
しているデータの後に書き込むというものである。この最初の規則は、メタデー
タが書き込まれるまで、キャッシュがキャッシュ内のオブジェクトについて「不
変の」知識を持つことがないことを理論的根拠とする。キャッシュがデータに先
行してメタデータを書き込み、その時点でクラッシュした場合を考えると、その
メタデータは、ディスク上の無効なオブジェクト・データを伴うオブジェクト名
に関連付けされることになる。これによりキャッシュが、ヒューリスティック・
アプローチを使用して試行を繰り返し、良好なデータをポイントするメタデータ
および不良データをポイントするメタデータを決定しなければならなくなくこと
から、これは望ましくない。
めに２つの規則を使用する。最初の規則は、メタデータを、必ずそれがポイント
しているデータの後に書き込むというものである。この最初の規則は、メタデー
タが書き込まれるまで、キャッシュがキャッシュ内のオブジェクトについて「不
変の」知識を持つことがないことを理論的根拠とする。キャッシュがデータに先
行してメタデータを書き込み、その時点でクラッシュした場合を考えると、その
メタデータは、ディスク上の無効なオブジェクト・データを伴うオブジェクト名
に関連付けされることになる。これによりキャッシュが、ヒューリスティック・
アプローチを使用して試行を繰り返し、良好なデータをポイントするメタデータ
および不良データをポイントするメタデータを決定しなければならなくなくこと
から、これは望ましくない。
【０１４５】 ２番目の規則は、アリーナをポイントするすべてのディレクト
リ・メタデータが削除され、ディスクに書き込まれるまで、空であるとしてプー
ル・ヘッダ内においてプール・アリーナをマークすることができないというもの
である。これは、クラッシュによって、ディレクトリ・メタデータがポイントす
る空のアリーナが存在してしまうことを防止するために必要である。これによっ
てもたらされる可能性のある問題は、その空のアリーナが、それが空であること
から新しいデータによって満たすことができるようになり、その結果、それが新
しいデータの書き込みに使用できるようになることである。しかしながら「古い
」ディレクトリ・メタデータは、この新しいデータと同じ位置をポイントしてい
る。その場合、古いディレクトリ・メタデータへのアクセスが、古いデータもし
くはフェイルを返さずに新しいデータを返すことが起こり得る。
リ・メタデータが削除され、ディスクに書き込まれるまで、空であるとしてプー
ル・ヘッダ内においてプール・アリーナをマークすることができないというもの
である。これは、クラッシュによって、ディレクトリ・メタデータがポイントす
る空のアリーナが存在してしまうことを防止するために必要である。これによっ
てもたらされる可能性のある問題は、その空のアリーナが、それが空であること
から新しいデータによって満たすことができるようになり、その結果、それが新
しいデータの書き込みに使用できるようになることである。しかしながら「古い
」ディレクトリ・メタデータは、この新しいデータと同じ位置をポイントしてい
る。その場合、古いディレクトリ・メタデータへのアクセスが、古いデータもし
くはフェイルを返さずに新しいデータを返すことが起こり得る。
【０１４６】 図８Ｃは、上記の２つの規則を実装する好ましい同期化方法８
２０を示すフローチャートである。ブロック８２２において、オブジェクトをキ
ャッシュに書き込む。ブロック８２２は、ブロック８２４およびブロック８２６
に示したステップ、つまりオープン・ディレクトリ内にメタデータを作成するス
テップ、およびそのオブジェクト・データをディスクに書き込み、同期させるス
テップを伴う。
２０を示すフローチャートである。ブロック８２２において、オブジェクトをキ
ャッシュに書き込む。ブロック８２２は、ブロック８２４およびブロック８２６
に示したステップ、つまりオープン・ディレクトリ内にメタデータを作成するス
テップ、およびそのオブジェクト・データをディスクに書き込み、同期させるス
テップを伴う。
【０１４７】 ブロック８２８〜８２０'のステップは、周期的に実行される
。ブロック８２８に示されるようにオープン・ディレクトリ・テーブル内のメタ
データを個別に注目し、ブロック８２１に示されるように、それぞれのメタデー
タごとに、そのメタデータがポイントするデータがすでにディスクと同期されて
いるか否かを判断する。同期されていれば、ブロック８２３においてキャッシュ
は、安定したデータをポイントするそのメタデータをオープン・ディレクトリか
らディレクトリ・テーブルにコピーする。ブロック８２５においては、ディスク
に対してこの変更を同期させる。
。ブロック８２８に示されるようにオープン・ディレクトリ・テーブル内のメタ
データを個別に注目し、ブロック８２１に示されるように、それぞれのメタデー
タごとに、そのメタデータがポイントするデータがすでにディスクと同期されて
いるか否かを判断する。同期されていれば、ブロック８２３においてキャッシュ
は、安定したデータをポイントするそのメタデータをオープン・ディレクトリか
らディレクトリ・テーブルにコピーする。ブロック８２５においては、ディスク
に対してこの変更を同期させる。
【０１４８】 ブロック８２７においては、アリーナに対するガーベジ・コレ
クションを実行する。ブロック８２７は、図８Ａに示したステップを包含するも
のとすることができる。それに代えて、ガーベジ・コレクションを概してブロッ
ク８２９、ブロック８３１、およびブロック８２０'に示したステップを含むも
のとしてもよい。ブロック８２９においては、これに示されるようにアリーナ内
の各フラグメントについて、キャッシュが、そのセグメントをポイントするディ
レクトリ・メタデータを削除し、ディレクトリ・メタデータをディスクに書き込
む。ブロック８３１においては、そのアリーナが空であるとマークされるように
、メモリ内においてプール・ヘッダを修正する。ブロック８２０'においては、
プール・ヘッダをディスクに書き込み、同期させる。
クションを実行する。ブロック８２７は、図８Ａに示したステップを包含するも
のとすることができる。それに代えて、ガーベジ・コレクションを概してブロッ
ク８２９、ブロック８３１、およびブロック８２０'に示したステップを含むも
のとしてもよい。ブロック８２９においては、これに示されるようにアリーナ内
の各フラグメントについて、キャッシュが、そのセグメントをポイントするディ
レクトリ・メタデータを削除し、ディレクトリ・メタデータをディスクに書き込
む。ブロック８３１においては、そのアリーナが空であるとマークされるように
、メモリ内においてプール・ヘッダを修正する。ブロック８２０'においては、
プール・ヘッダをディスクに書き込み、同期させる。
【０１４９】 ディスクに対する情報の書き込みに関連するステップは、好ま
しくは、キャッシュ８０を走らせているワークステーションのオペレーティング
・システムに提供されている「フラッシュ」オペレーションを使用する。「フラ
ッシュ」オペレーションは、オブジェクト・データをストアするために使用され
たバッファ内の任意のデータを不揮発性ストレージ・デバイス９０ａ〜９０ｃに
書き込む。
しくは、キャッシュ８０を走らせているワークステーションのオペレーティング
・システムに提供されている「フラッシュ」オペレーションを使用する。「フラ
ッシュ」オペレーションは、オブジェクト・データをストアするために使用され
たバッファ内の任意のデータを不揮発性ストレージ・デバイス９０ａ〜９０ｃに
書き込む。
【０１５０】 上記の方法を用いると、変更を記述したデータがディスクまた
はその他の不揮発性ストレージに実際に書き込まれるまで、オープン・ディレク
トリ内の変更によってディレクトリ・テーブルが更新されることがない。またキ
ャッシュ８０は、ガーベジ・コレクション・プロセスによって行われた変更がデ
ィスクに渡されるまで、ディスク上のアリーナの更新を延期する。これは、オー
プン・ディレクトリからディレクトリ・テーブルを更新する前にシステムのクラ
ッシュを生じた場合にも、アリーナが継続的に有効なデータをストアすることを
保証する。
はその他の不揮発性ストレージに実際に書き込まれるまで、オープン・ディレク
トリ内の変更によってディレクトリ・テーブルが更新されることがない。またキ
ャッシュ８０は、ガーベジ・コレクション・プロセスによって行われた変更がデ
ィスクに渡されるまで、ディスク上のアリーナの更新を延期する。これは、オー
プン・ディレクトリからディレクトリ・テーブルを更新する前にシステムのクラ
ッシュを生じた場合にも、アリーナが継続的に有効なデータをストアすることを
保証する。
【０１５１】 （６．再更新） 好ましい実施例においては、キャッシュ内の古い情報オブジェクトを再更新し
、ガーベジ・コレクション・プロセスにおいてそれらが破壊されないようにする
方法が提供される。
、ガーベジ・コレクション・プロセスにおいてそれらが破壊されないようにする
方法が提供される。
【０１５２】 図１２は、好ましい再更新プロセスを示したフローチャートで
ある。ブロック１２０２においては、外部プログラムまたはプロセスがキャッシ
ュに要求を渡し、特定の情報オブジェクトが最近クライアントによってロードさ
れたか否かを問い合わせる。キャッシュは、この要求に応答して、ブロック１２
０４に示されるようにキャッシュ内のその情報オブジェクトを見つけ出す。ブロ
ック１２０６においては、ディレクトリ・テーブル内のその情報に関連付けされ
た読み出しカウンタ値を読み取る。ブロック１２０８においては、この読み出し
カウンタ値が高いか否かをキャッシュが評価する。
ある。ブロック１２０２においては、外部プログラムまたはプロセスがキャッシ
ュに要求を渡し、特定の情報オブジェクトが最近クライアントによってロードさ
れたか否かを問い合わせる。キャッシュは、この要求に応答して、ブロック１２
０４に示されるようにキャッシュ内のその情報オブジェクトを見つけ出す。ブロ
ック１２０６においては、ディレクトリ・テーブル内のその情報に関連付けされ
た読み出しカウンタ値を読み取る。ブロック１２０８においては、この読み出し
カウンタ値が高いか否かをキャッシュが評価する。
【０１５３】 読み出しカウンタ値が高いときは、最近その情報オブジェクト
のロードがあったことになる。その場合、ブロック１２１０において、要求を行
っているプロセスに対し、問い合わせ内容を肯定する応答メッセージを送る。読
み出しカウンタ値が高くないときは、ブロック１２１２に示されるように、その
情報オブジェクトは最近ロードされていない。したがって、ブロック１２１４に
示されるように、呼び出しを行っているプログラムまたはプロセスに対して、キ
ャッシュは問い合わせ内容を否定する応答メッセージを送る。ブロック１２１６
においてキャッシュは、その情報オブジェクトに関連してストアしている期限値
を更新し、現在の日付または時刻を反映させる。キャッシュが期限を更新するこ
とによって、更新後のそのオブジェクトが古いと見なされなくなることから、ガ
ーベジ・コレクション・プロセスにおいてそのオブジェクトの削除が回避される
ことが保証される。このようにしてキャッシュ内の古いオブジェクトをリフレッ
シュし、それによって発信元からそれを取り出し、キャッシュに書き込み、かつ
期限切れとなったそのオブジェクトのコピーを削除することを回避している。
のロードがあったことになる。その場合、ブロック１２１０において、要求を行
っているプロセスに対し、問い合わせ内容を肯定する応答メッセージを送る。読
み出しカウンタ値が高くないときは、ブロック１２１２に示されるように、その
情報オブジェクトは最近ロードされていない。したがって、ブロック１２１４に
示されるように、呼び出しを行っているプログラムまたはプロセスに対して、キ
ャッシュは問い合わせ内容を否定する応答メッセージを送る。ブロック１２１６
においてキャッシュは、その情報オブジェクトに関連してストアしている期限値
を更新し、現在の日付または時刻を反映させる。キャッシュが期限を更新するこ
とによって、更新後のそのオブジェクトが古いと見なされなくなることから、ガ
ーベジ・コレクション・プロセスにおいてそのオブジェクトの削除が回避される
ことが保証される。このようにしてキャッシュ内の古いオブジェクトをリフレッ
シュし、それによって発信元からそれを取り出し、キャッシュに書き込み、かつ
期限切れとなったそのオブジェクトのコピーを削除することを回避している。
【０１５４】 （スケーリング付きカウンタの更新） 図１０Ｂは、スケーリング付きカウンタを更新する方法を示したフローチャー
トである。好ましい実施例においては、図３Ａに示したディレクトリ・テーブル
のセット内の各ブロック１１２ａ〜１１２ｎにストアされる読み出しカウンタ値
を管理するために、図１０Ｂに示した方法が使用される。しかしながら、図１０
Ｂに示した方法をその範囲に限定する意図はない。図１０Ｂに示した方法は、そ
れぞれカウンタを有する複数オブジェクトの管理を含み、かつもっとも最近使用
されたオブジェクトないしは最近ほとんど使用されないオブジェクトを追跡する
ことが望ましい任意のアプリケーションに適用できる。過去のアプローチと比較
した図１０Ｂに示した方法の主な利点は、この方法によって小さなストレージ・
エリア内において大きなカウンタ値の追跡が可能になることである。
トである。好ましい実施例においては、図３Ａに示したディレクトリ・テーブル
のセット内の各ブロック１１２ａ〜１１２ｎにストアされる読み出しカウンタ値
を管理するために、図１０Ｂに示した方法が使用される。しかしながら、図１０
Ｂに示した方法をその範囲に限定する意図はない。図１０Ｂに示した方法は、そ
れぞれカウンタを有する複数オブジェクトの管理を含み、かつもっとも最近使用
されたオブジェクトないしは最近ほとんど使用されないオブジェクトを追跡する
ことが望ましい任意のアプリケーションに適用できる。過去のアプローチと比較
した図１０Ｂに示した方法の主な利点は、この方法によって小さなストレージ・
エリア内において大きなカウンタ値の追跡が可能になることである。
【０１５５】 好ましい実施例においては、ブロック１１２ａ〜１１２ｎにス
トアされる読み出しカウンタ値が、それぞれ３ビットの量としてストアされる。
キャッシュ８０のオペレーションの間、ブロックがアクセスされると、そのブロ
ックの読み出しカウンタ値が１つインクリメントされる。３ビットを用いて表す
ことができる最大の値を１０進数で表すと７である。したがって、読み出しカウ
ンタ値は、７回インクリメントされるとオーバーフローする。カウンタのオーバ
ーフローを回避しつつ、カウンタに、それをインクリメントするオペレーション
を無制限に追跡させるために、図１０Ｂに示した方法が周期的に実行される。
トアされる読み出しカウンタ値が、それぞれ３ビットの量としてストアされる。
キャッシュ８０のオペレーションの間、ブロックがアクセスされると、そのブロ
ックの読み出しカウンタ値が１つインクリメントされる。３ビットを用いて表す
ことができる最大の値を１０進数で表すと７である。したがって、読み出しカウ
ンタ値は、７回インクリメントされるとオーバーフローする。カウンタのオーバ
ーフローを回避しつつ、カウンタに、それをインクリメントするオペレーション
を無制限に追跡させるために、図１０Ｂに示した方法が周期的に実行される。
【０１５６】 以下に示す図１０Ｂのステップに関する説明は、次の表１を参
照することによってより明確に理解されよう。
照することによってより明確に理解されよう。
【０１５７】 表１ ― 連続的なカウンタ値 イベント カウンタ Ａ Ｂ Ｃ １：スタート １ １ １ ２：インクリメント ２ １ １ ３：インクリメント ７ ３ １ ４：デクリメント ６ ２ ０ ５：再利用 ６ ２ −
【０１５８】 表１においてイベント列は、一連のカウンタ値に影響を与える
連続的なイベントを識別し、そのイベントの性質を簡単に示している。カウンタ
の列タイトルは、カウンタ値Ａ、Ｂ、およびＣが表されている個別の列を示して
いる。各カウンタ値Ａ、Ｂ、およびＣは、それぞれディレクトリ・テーブル１１
０の異なるブロック１１２ａ〜１１２ｎにストアされるカウンタ値に対応する。
つまり、表１の各行は、時間的に連続するスナップショットにおける３つのカウ
ンタ値の内容を表している。
連続的なイベントを識別し、そのイベントの性質を簡単に示している。カウンタ
の列タイトルは、カウンタ値Ａ、Ｂ、およびＣが表されている個別の列を示して
いる。各カウンタ値Ａ、Ｂ、およびＣは、それぞれディレクトリ・テーブル１１
０の異なるブロック１１２ａ〜１１２ｎにストアされるカウンタ値に対応する。
つまり、表１の各行は、時間的に連続するスナップショットにおける３つのカウ
ンタ値の内容を表している。
【０１５９】 表１のイベント１は、時間的な任意のスタート・ポイントを表
し、それにおいてハッシュ・テーブルのカウンタ値Ａ、Ｂ、Ｃを含む各エントリ
は、１回だけアクセスされている。したがって、各カウンタＡ、Ｂ、Ｃの値は１
である。イベント２においては、キャッシュが、カウンタ値Ａをストアしている
ハッシュ・テーブルのエントリに対してアクセスした。この結果、カウンタＡが
インクリメントされてその値が２になるが、残りのカウンタＢおよびＣには変更
がない。その後ハッシュ・テーブルのエントリに対するアクセスが何回か行われ
、それぞれのアクセスごとにカウンタＡ、ＢまたはＣのいずれかがインクリメン
トされたとする。それにより、イベント３においてはカウンタＡ、Ｂ、Ｃの値が
、それぞれ７、３、あるいは１となっている。つまり、カウンタＡは、それが表
すことができる最大の値、すなわち２進数の１１１すなわち１０進数の７をスト
アしており、この値をさらにインクリメントしようとするとオーバーフローを生
じることになる。
し、それにおいてハッシュ・テーブルのカウンタ値Ａ、Ｂ、Ｃを含む各エントリ
は、１回だけアクセスされている。したがって、各カウンタＡ、Ｂ、Ｃの値は１
である。イベント２においては、キャッシュが、カウンタ値Ａをストアしている
ハッシュ・テーブルのエントリに対してアクセスした。この結果、カウンタＡが
インクリメントされてその値が２になるが、残りのカウンタＢおよびＣには変更
がない。その後ハッシュ・テーブルのエントリに対するアクセスが何回か行われ
、それぞれのアクセスごとにカウンタＡ、ＢまたはＣのいずれかがインクリメン
トされたとする。それにより、イベント３においてはカウンタＡ、Ｂ、Ｃの値が
、それぞれ７、３、あるいは１となっている。つまり、カウンタＡは、それが表
すことができる最大の値、すなわち２進数の１１１すなわち１０進数の７をスト
アしており、この値をさらにインクリメントしようとするとオーバーフローを生
じることになる。
【０１６０】 この時点において、図１０Ｂに示した方法がカウンタＡ、Ｂ、
Ｃに適用される。ステップ６２２においては、すべてのカウンタの値を読み取る
。ステップ６２４においては、すべてのカウンタ値の合計を計算する。表１の場
合であれば、この合計は７＋３＋１＝１１となる。ステップ６２６においては、
すべてのカウンタによって表すことができる最大の合計値を、カウンタ値のビッ
ト長に基づいて求める。３ビットの値の場合は、１つのカウンタが表すことがで
きる最大値は７であり、３つの３ビット・カウンタを合計した最大値は７×３＝
２１となる。ステップ６２６は省略することも可能であり、その場合は上記に代
えてスケーリング付きカウンタの方法６２０が使用できる定数として最大値をス
トアし、必要に応じてそれを取り出せばよい。
Ｃに適用される。ステップ６２２においては、すべてのカウンタの値を読み取る
。ステップ６２４においては、すべてのカウンタ値の合計を計算する。表１の場
合であれば、この合計は７＋３＋１＝１１となる。ステップ６２６においては、
すべてのカウンタによって表すことができる最大の合計値を、カウンタ値のビッ
ト長に基づいて求める。３ビットの値の場合は、１つのカウンタが表すことがで
きる最大値は７であり、３つの３ビット・カウンタを合計した最大値は７×３＝
２１となる。ステップ６２６は省略することも可能であり、その場合は上記に代
えてスケーリング付きカウンタの方法６２０が使用できる定数として最大値をス
トアし、必要に応じてそれを取り出せばよい。
【０１６１】 ステップ６２８においては、値（最大値／２）の小数点以下を
切り捨てた値を計算し、それと全カウンタの合計を比較する。前述の例であれば
、この関係は次のようになる。
切り捨てた値を計算し、それと全カウンタの合計を比較する。前述の例であれば
、この関係は次のようになる。
【０１６２】 合計＝１１ 最大値＝２１ 最大値／２＝１０ （合計＞最大値／２）＝真
【０１６３】 結果が真であることから、コントロールがステップ６３０に進
み、すべてのカウンタ値を１つデクリメントする。このステップの後のカウンタ
Ａ、Ｂ、Ｃの状態をイベント４の「デクリメント」として示す。ここで、最近ほ
とんど使用されていないハッシュ・テーブルのエントリを表すカウンタＣがゼロ
にデクリメントされていることに注意されたい。この時点において、対応するカ
ウンタ値をスキャンし、ゼロの値をサーチすることによって最近ほとんど使用さ
れていないハッシュ・テーブルのエントリを再利用、あるいは削除することがで
きる。表１においては、このステップの結果をイベント５の「再利用」として示
している。カウンタＡおよびＢの値には変更がないが、カウンタＣの値は、それ
に対応するハッシュ・テーブルのエントリがハッシュ・テーブルから削除された
ために未定義となる。
み、すべてのカウンタ値を１つデクリメントする。このステップの後のカウンタ
Ａ、Ｂ、Ｃの状態をイベント４の「デクリメント」として示す。ここで、最近ほ
とんど使用されていないハッシュ・テーブルのエントリを表すカウンタＣがゼロ
にデクリメントされていることに注意されたい。この時点において、対応するカ
ウンタ値をスキャンし、ゼロの値をサーチすることによって最近ほとんど使用さ
れていないハッシュ・テーブルのエントリを再利用、あるいは削除することがで
きる。表１においては、このステップの結果をイベント５の「再利用」として示
している。カウンタＡおよびＢの値には変更がないが、カウンタＣの値は、それ
に対応するハッシュ・テーブルのエントリがハッシュ・テーブルから削除された
ために未定義となる。
【０１６４】 図１０Ｂに示した方法を周期的、かつ規則的に繰り返すことに
より、「人気のある」カウンタの値がオーバーフローすることがない。また、値
がゼロのカウンタ値によって、最近ほとんど使用されていないエントリが迅速に
識別され、キャッシュから容易に削除することができる。カウンタ値は、ハッシ
ュ・テーブルのエントリに対するアクセスが１００万回に上るときでも数ビット
内に維持することができる。つまり、図１０Ｂに示した方法は、最近ほとんど使
用されていないエントリをリストから迅速かつ効率的に削除する方法を提供する
。
より、「人気のある」カウンタの値がオーバーフローすることがない。また、値
がゼロのカウンタ値によって、最近ほとんど使用されていないエントリが迅速に
識別され、キャッシュから容易に削除することができる。カウンタ値は、ハッシ
ュ・テーブルのエントリに対するアクセスが１００万回に上るときでも数ビット
内に維持することができる。つまり、図１０Ｂに示した方法は、最近ほとんど使
用されていないエントリをリストから迅速かつ効率的に削除する方法を提供する
。
【０１６５】 （キャッシュのオペレーション） 好ましい実施例においては、読み出しおよび書き込みのオペレーションをサポ
ートするＡＰＩを介して外部のプログラムがアクセス可能な１ないしは複数のコ
ンピュータ・プログラム内においてキャッシュ８０が実装される。読み出しおよ
び書き込みオペレーションは、外部のプログラムもしくはプロセスにとって「見
ることができる」キャッシュ８０内の唯一の構造であるオープン・ディレクトリ
１３０上で実行される。読み出しオペレーションは、キャッシュ内のオブジェク
トの発見を希望する外部プログラムによって起動される。書き込みオペレーショ
ンは、キャッシュ内へのオブジェクトのストアを希望する外部プログラムによっ
て起動される。
ートするＡＰＩを介して外部のプログラムがアクセス可能な１ないしは複数のコ
ンピュータ・プログラム内においてキャッシュ８０が実装される。読み出しおよ
び書き込みオペレーションは、外部のプログラムもしくはプロセスにとって「見
ることができる」キャッシュ８０内の唯一の構造であるオープン・ディレクトリ
１３０上で実行される。読み出しオペレーションは、キャッシュ内のオブジェク
トの発見を希望する外部プログラムによって起動される。書き込みオペレーショ
ンは、キャッシュ内へのオブジェクトのストアを希望する外部プログラムによっ
て起動される。
【０１６６】 キャッシュ８０を構成するプログラム内においては、ルックア
ップ、削除、チェックアウト（請け出し）、およびチェックイン（戻し）と呼ば
れるオペレーションがサポートされている。ルックアップ・オペレーションは、
キーに基づいてオープン・ディレクトリ内においてオブジェクトをルックアップ
する。削除オペレーションは、キーに基づいてオープン・ディレクトリからオブ
ジェクトを削除する。チェックアウト・オペレーションは、データの一貫性を保
証するように順序立てた方法を使用してディレクトリ・テーブル１１０からブロ
ックのコピーを獲得する。チェックイン・オペレーションは、ブロックのコピー
（別のオペレーションによってそれが修正されていることもある）をディレクト
リ・テーブル１１０に返す。これとは異なる実施例においては、単一のキャッシ
ュ・ルックアップ・オペレーションが、これらのオペレーションの側面を兼ねる
。
ップ、削除、チェックアウト（請け出し）、およびチェックイン（戻し）と呼ば
れるオペレーションがサポートされている。ルックアップ・オペレーションは、
キーに基づいてオープン・ディレクトリ内においてオブジェクトをルックアップ
する。削除オペレーションは、キーに基づいてオープン・ディレクトリからオブ
ジェクトを削除する。チェックアウト・オペレーションは、データの一貫性を保
証するように順序立てた方法を使用してディレクトリ・テーブル１１０からブロ
ックのコピーを獲得する。チェックイン・オペレーションは、ブロックのコピー
（別のオペレーションによってそれが修正されていることもある）をディレクト
リ・テーブル１１０に返す。これとは異なる実施例においては、単一のキャッシ
ュ・ルックアップ・オペレーションが、これらのオペレーションの側面を兼ねる
。
【０１６７】 （１．ルックアップ） 別の実施例においては、ルックアップ・オペレーションを使用して、特定の名
前によって識別された特定のオブジェクトが、現在のキャッシュ８０内にストア
されているか否かを判断する。図９Ａに、ルックアップ・オペレーションの一実
施例において実行されるステップのフローチャートを示すが、それにおいては番
号９０２を用いてこのオペレーションを包括的に示している。ルックアップ・オ
ペレーションは、クライアント１０ａからの要求メッセージが、特定のオブジェ
クトをサーバ４０から取り出すことを求めているとき、プロトコル・エンジン７
０からキャッシュ８０にコマンドを与えることによって開始される。クライアン
ト１０ａからのこの要求メッセージは、要求しているオブジェクトをその名前に
よって識別する。
前によって識別された特定のオブジェクトが、現在のキャッシュ８０内にストア
されているか否かを判断する。図９Ａに、ルックアップ・オペレーションの一実
施例において実行されるステップのフローチャートを示すが、それにおいては番
号９０２を用いてこのオペレーションを包括的に示している。ルックアップ・オ
ペレーションは、クライアント１０ａからの要求メッセージが、特定のオブジェ
クトをサーバ４０から取り出すことを求めているとき、プロトコル・エンジン７
０からキャッシュ８０にコマンドを与えることによって開始される。クライアン
ト１０ａからのこの要求メッセージは、要求しているオブジェクトをその名前に
よって識別する。
【０１６８】 ワールド・ワイド・ウェブに関してこのプロセスが適用される
場合は、その名前がユニフォーム・リソース・ロケータ（ＵＲＬ）になる。ステ
ップ９０４においては、キャッシュ８０がオブジェクトの名前をキー値に変換す
る。好ましい実施例においては、この変換ステップが図３Ｂに示した態様で実行
される。つまり、ＭＤ５一方向ハッシュ関数等のハッシュ関数にオブジェクト名
５３を渡す。このハッシュ関数の出力がオブジェクトの名前キー６２になる。オ
ブジェクトの名前キー６２は、１ないしは複数のサブキー６４、６６に分割する
ことができる。
場合は、その名前がユニフォーム・リソース・ロケータ（ＵＲＬ）になる。ステ
ップ９０４においては、キャッシュ８０がオブジェクトの名前をキー値に変換す
る。好ましい実施例においては、この変換ステップが図３Ｂに示した態様で実行
される。つまり、ＭＤ５一方向ハッシュ関数等のハッシュ関数にオブジェクト名
５３を渡す。このハッシュ関数の出力がオブジェクトの名前キー６２になる。オ
ブジェクトの名前キー６２は、１ないしは複数のサブキー６４、６６に分割する
ことができる。
【０１６９】 ステップ９０６においてキャッシュ８０は、要求キー値を用い
てオープン・ディレクトリ１３０内をルックアップする。オープン・ディレクト
リには、もっとも最近に要求されたオブジェクトがストアされており、したがっ
てクライアントの要求にあったオブジェクトが含まれている可能性がもっとも高
いと期待されることから、そこが最初に調べられる。好ましくは、ステップ９０
６に、ルックアップ・キーとしてサブキー値の１つの使用を含める。たとえば、
このルックアップに１７ビットもしくは１８ビットのサブキー値を使用すること
ができる。
てオープン・ディレクトリ１３０内をルックアップする。オープン・ディレクト
リには、もっとも最近に要求されたオブジェクトがストアされており、したがっ
てクライアントの要求にあったオブジェクトが含まれている可能性がもっとも高
いと期待されることから、そこが最初に調べられる。好ましくは、ステップ９０
６に、ルックアップ・キーとしてサブキー値の１つの使用を含める。たとえば、
このルックアップに１７ビットもしくは１８ビットのサブキー値を使用すること
ができる。
【０１７０】 ステップ９０８においては、キャッシュ８０によって、サブキ
ー値がオープン・ディレクトリ内に見つかったか否かが評価される。サブキー値
がオープン・ディレクトリ内に見つかった場合には、ステップ９１０において、
キャッシュ８０がストレージ・デバイスの１つからそのオブジェクトを取り出し
、そのオブジェクトをクライアントに配信する。この取り出しのサブステップに
は、ストレージ・デバイス９０ａ〜９０ｎ内の不揮発性ストレージのプール、ア
リーナ、およびフラグメントにあるオブジェクトの位置に関連して前述したサブ
ステップが含まれる。また配信するサブステップには、そのオブジェクトのデー
タを含む、クライアントに対するＨＴＴＰ応答の作成、クライアントに対するＨ
ＴＴＰ接続の開設、およびクライアントに対するＨＴＴＰ要求の送信が含まれる
。
ー値がオープン・ディレクトリ内に見つかったか否かが評価される。サブキー値
がオープン・ディレクトリ内に見つかった場合には、ステップ９１０において、
キャッシュ８０がストレージ・デバイスの１つからそのオブジェクトを取り出し
、そのオブジェクトをクライアントに配信する。この取り出しのサブステップに
は、ストレージ・デバイス９０ａ〜９０ｎ内の不揮発性ストレージのプール、ア
リーナ、およびフラグメントにあるオブジェクトの位置に関連して前述したサブ
ステップが含まれる。また配信するサブステップには、そのオブジェクトのデー
タを含む、クライアントに対するＨＴＴＰ応答の作成、クライアントに対するＨ
ＴＴＰ接続の開設、およびクライアントに対するＨＴＴＰ要求の送信が含まれる
。
【０１７１】 サブキー値がオープン・ディレクトリ内に見つからないとき、
キャッシュ８０は、ステップ９１２において要求サブキー値を用いてタグ・テー
ブル１０２内をルックアップする。ステップ９１４においてキャッシュ８０は、
そのサブキー値がタグ・テーブル１０２内に見つかったか否かを評価する。一致
が見つからなければ、ステップ９１６においてキャッシュ８０は、後述する後の
使用のために、一致が得られなかった事実についての情報をストアする。この情
報は、タグ・テーブル１０２内にミスが発生したことを示す１ビットとすること
ができる。
キャッシュ８０は、ステップ９１２において要求サブキー値を用いてタグ・テー
ブル１０２内をルックアップする。ステップ９１４においてキャッシュ８０は、
そのサブキー値がタグ・テーブル１０２内に見つかったか否かを評価する。一致
が見つからなければ、ステップ９１６においてキャッシュ８０は、後述する後の
使用のために、一致が得られなかった事実についての情報をストアする。この情
報は、タグ・テーブル１０２内にミスが発生したことを示す１ビットとすること
ができる。
【０１７２】 ステップ９１８においてキャッシュ８０は、そのサブキー値を
用いてディレクトリ・テーブル内をルックアップする。ステップ９１４の評価が
肯定的であった場合にキャッシュ８０は、タグ・テーブル１０２のエントリ１０
６の１つから、要求サブキー値に一致するサブキー値を取り出す。この値は、デ
ィレクトリ・テーブル内において要求キー値をルックアップするためのキーとし
て使用される。ステップ９２０においてキャッシュ８０は、ディレクトリ・テー
ブル内に要求キー値が見つかったか否かを評価する。ヒットが生じ、かつステッ
プ９１６においてストアされた情報によってタグ・テーブル内にミスが生じてい
ることが示されている場合、キャッシュ８０は、ステップ９２２において、ディ
レクトリ・テーブルのヒットに関連する情報を用いてオープン・ディレクトリを
更新する。この後、コントロールがステップ９１０に渡され、前述した方法に従
ってオブジェクトが獲得され、クライアントに配信される。
用いてディレクトリ・テーブル内をルックアップする。ステップ９１４の評価が
肯定的であった場合にキャッシュ８０は、タグ・テーブル１０２のエントリ１０
６の１つから、要求サブキー値に一致するサブキー値を取り出す。この値は、デ
ィレクトリ・テーブル内において要求キー値をルックアップするためのキーとし
て使用される。ステップ９２０においてキャッシュ８０は、ディレクトリ・テー
ブル内に要求キー値が見つかったか否かを評価する。ヒットが生じ、かつステッ
プ９１６においてストアされた情報によってタグ・テーブル内にミスが生じてい
ることが示されている場合、キャッシュ８０は、ステップ９２２において、ディ
レクトリ・テーブルのヒットに関連する情報を用いてオープン・ディレクトリを
更新する。この後、コントロールがステップ９１０に渡され、前述した方法に従
ってオブジェクトが獲得され、クライアントに配信される。
【０１７３】 ステップ９２０の評価が否定的である場合は、要求されたオブ
ジェクトはキャッシュ内になく、ステップ９２４に示されるように、キャッシュ
のミス条件が成立する。ミス条件に応答してキャッシュ８０は、ステップ９２６
において、要求されたオブジェクトのソースであるサーバからそのコピーを獲得
する。たとえば、ウェブ関連においては、キャッシュ８０が、クライアントの要
求に含まれていたＵＲＬに対するＨＴＴＰ接続を開き、オブジェクトをダウンロ
ードする。このオブジェクトは、続いてクライアントに提供されるとともに、後
の参照のためにキャッシュ内にストアされる。
ジェクトはキャッシュ内になく、ステップ９２４に示されるように、キャッシュ
のミス条件が成立する。ミス条件に応答してキャッシュ８０は、ステップ９２６
において、要求されたオブジェクトのソースであるサーバからそのコピーを獲得
する。たとえば、ウェブ関連においては、キャッシュ８０が、クライアントの要
求に含まれていたＵＲＬに対するＨＴＴＰ接続を開き、オブジェクトをダウンロ
ードする。このオブジェクトは、続いてクライアントに提供されるとともに、後
の参照のためにキャッシュ内にストアされる。
【０１７４】 好ましい実施例においては、キー値をパラメータとして受け取
る、オブジェクト指向プログラミング言語におけるオブジェクトのメソッドとし
てルックアップ・オペレーションが実装される。
る、オブジェクト指向プログラミング言語におけるオブジェクトのメソッドとし
てルックアップ・オペレーションが実装される。
【０１７５】 （２．キャッシュのオープン・リード・プロセス） 図９Ｅは、オブジェクト名（たとえばＵＲＬ等）によって識別されるオブジェ
クトをキャッシュから読み出す好ましいプロセスを示したフローチャートである
。好ましい実施例においては、図９Ｅに示したプロセスが「open_read（オープ
ン・リード）」と呼ばれ、キャッシュ８０が有する唯一の外部インターフェース
を表す。キャッシュ内のデータのコントロールおよび一貫性を保証するために、
外部プログラムに対して、オープン・ディレクトリ１３０を使用ないしは修正す
るオペレーションへのアクセスだけを許可するほうが有利である。好ましくは、
オブジェクト名、およびユーザの特定の要求に関する情報を入力パラメータとし
て受け取るプログラムもしくはプログラム・オブジェクトとして図９Ｅに示した
プロセスを実装する。この読み出しプロセスは、ルックアップ・プロセスの使用
によってキャッシュ内に見つかったキーに関連付けされたオブジェクトのコピー
を返す。つまりこの読み出しプロセスおよび、それによって起動されあるいは呼
び出されたそのほかのプロセスは、図９Ａとの関連から前述したルックアップ・
オペレーションに代わるものとなる。
クトをキャッシュから読み出す好ましいプロセスを示したフローチャートである
。好ましい実施例においては、図９Ｅに示したプロセスが「open_read（オープ
ン・リード）」と呼ばれ、キャッシュ８０が有する唯一の外部インターフェース
を表す。キャッシュ内のデータのコントロールおよび一貫性を保証するために、
外部プログラムに対して、オープン・ディレクトリ１３０を使用ないしは修正す
るオペレーションへのアクセスだけを許可するほうが有利である。好ましくは、
オブジェクト名、およびユーザの特定の要求に関する情報を入力パラメータとし
て受け取るプログラムもしくはプログラム・オブジェクトとして図９Ｅに示した
プロセスを実装する。この読み出しプロセスは、ルックアップ・プロセスの使用
によってキャッシュ内に見つかったキーに関連付けされたオブジェクトのコピー
を返す。つまりこの読み出しプロセスおよび、それによって起動されあるいは呼
び出されたそのほかのプロセスは、図９Ａとの関連から前述したルックアップ・
オペレーションに代わるものとなる。
【０１７６】 ステップ９６４においてプロセスは、選択肢のベクトルを請け
出し、ベクトル内の選択肢が読み出せるようにする。好ましくは、ステップ９６
４に、図８Ｄとの関連からここに述べる、オブジェクト名から導かれたキーをパ
ラメータとして提供するcheckout_read（チェックアウト＿リード）プロセスの
起動を包含する。ベクトルの請け出しには、そのベクトルに対するポインタを有
するオープン・ディレクトリからブロックを請け出し、またキャッシュからその
ブロックへ到達することが含まれる。
出し、ベクトル内の選択肢が読み出せるようにする。好ましくは、ステップ９６
４に、図８Ｄとの関連からここに述べる、オブジェクト名から導かれたキーをパ
ラメータとして提供するcheckout_read（チェックアウト＿リード）プロセスの
起動を包含する。ベクトルの請け出しには、そのベクトルに対するポインタを有
するオープン・ディレクトリからブロックを請け出し、またキャッシュからその
ブロックへ到達することが含まれる。
【０１７７】 チェックアウト・オペレーションが成功した場合にプロセスは
、ステップ９６６において要求情報を使用してベクトル内の選択肢の中から１つ
の選択肢を選択する。この選択は、選択肢のベクトル１２２に関連して説明した
前述の方法に従って行われる。一実施例においては、この選択が別のプログラム
またはプログラム・オブジェクトによって実行され、それによって適切な選択肢
が見つけ出されたか否かに応じて成功／失敗の表示が返される。選択が成功すれ
ば、ステップ９６８においてプロセスは選択肢のベクトルを戻す。ステップ９７
０においてプロセスは、選択した選択肢によってポイントされるオブジェクトを
読み出す。
、ステップ９６６において要求情報を使用してベクトル内の選択肢の中から１つ
の選択肢を選択する。この選択は、選択肢のベクトル１２２に関連して説明した
前述の方法に従って行われる。一実施例においては、この選択が別のプログラム
またはプログラム・オブジェクトによって実行され、それによって適切な選択肢
が見つけ出されたか否かに応じて成功／失敗の表示が返される。選択が成功すれ
ば、ステップ９６８においてプロセスは選択肢のベクトルを戻す。ステップ９７
０においてプロセスは、選択した選択肢によってポイントされるオブジェクトを
読み出す。
【０１７８】 ステップ９６４もしくはステップ９６６が失敗するときは、要
求されたドキュメントがキャッシュ内に存在しない。したがってプロセスは、ス
テップ９７２において「ドキュメントなし」エラー・メッセージを、このプロセ
スの呼び出しを行っているプログラムまたはプロセスに返す。
求されたドキュメントがキャッシュ内に存在しない。したがってプロセスは、ス
テップ９７２において「ドキュメントなし」エラー・メッセージを、このプロセ
スの呼び出しを行っているプログラムまたはプロセスに返す。
【０１７９】 （３．キャッシュのオープン・ライト・プロセス） 図９Ｆは、キャッシュ内にオブジェクトを書き込むプロセスを示すフローチャ
ートである。図９Ｅとの関連から説明した前述の読み出しプロセスの場合と同様
に、この書き込みプロセスも、好ましくは、キャッシュ内にオブジェクトのスト
アを必要とする外部プログラムに対してキャッシュ８０が有する唯一のインター
フェースである「open_write（オープン＿ライト）」メソッドとして実装する。
好ましくは、オブジェクト名、要求情報、および応答情報を入力パラメータとし
て受け取るプログラムもしくはメソッドとして図９Ｆに示したプロセスを実装す
る。オブジェクト名はキャッシュ内に書き込まれるオブジェクトを識別する；好
ましい実施例においては、このオブジェクト名を、図３Ｂに示したメカニズムを
使用してＵＲＬから導かれた名前キー６２とする。
ートである。図９Ｅとの関連から説明した前述の読み出しプロセスの場合と同様
に、この書き込みプロセスも、好ましくは、キャッシュ内にオブジェクトのスト
アを必要とする外部プログラムに対してキャッシュ８０が有する唯一のインター
フェースである「open_write（オープン＿ライト）」メソッドとして実装する。
好ましくは、オブジェクト名、要求情報、および応答情報を入力パラメータとし
て受け取るプログラムもしくはメソッドとして図９Ｆに示したプロセスを実装す
る。オブジェクト名はキャッシュ内に書き込まれるオブジェクトを識別する；好
ましい実施例においては、このオブジェクト名を、図３Ｂに示したメカニズムを
使用してＵＲＬから導かれた名前キー６２とする。
【０１８０】 書き込みプロセスは、クライアント１０ａがオブジェクト５２
を要求し、それがキャッシュ８０内に見つからなかったときに開始される。この
結果、キャッシュ８０は、そのオブジェクトをストアしているサーバ４０とのＨ
ＴＴＰトランザクションを開き、そこからそのオブジェクトのコピーを獲得する
。キャッシュ書き込みプロセスに提供される要求情報は、クライアントから到来
したＨＴＴＰ要求から導かれる。応答情報は、オブジェクトのコピーを供給する
サーバ４０からキャッシュ８０への応答から導かれる。
を要求し、それがキャッシュ８０内に見つからなかったときに開始される。この
結果、キャッシュ８０は、そのオブジェクトをストアしているサーバ４０とのＨ
ＴＴＰトランザクションを開き、そこからそのオブジェクトのコピーを獲得する
。キャッシュ書き込みプロセスに提供される要求情報は、クライアントから到来
したＨＴＴＰ要求から導かれる。応答情報は、オブジェクトのコピーを供給する
サーバ４０からキャッシュ８０への応答から導かれる。
【０１８１】 ステップ９７４においてこのプロセスは、選択肢のベクトルを
請け出す。このステップには、オブジェクト名に基づくキー値の演算、そのキー
値をマップしているオープン・ディレクトリ内のセットおよびブロックのルック
アップ、および、そのブロックに対応する選択肢のベクトルがある場合にはその
ロケートが含まれる。ベクトルが存在しない場合には、ステップ９８４に示した
ように、新しいベクトルが作られる。
請け出す。このステップには、オブジェクト名に基づくキー値の演算、そのキー
値をマップしているオープン・ディレクトリ内のセットおよびブロックのルック
アップ、および、そのブロックに対応する選択肢のベクトルがある場合にはその
ロケートが含まれる。ベクトルが存在しない場合には、ステップ９８４に示した
ように、新しいベクトルが作られる。
【０１８２】 ベクトルの請け出しに成功するか、あるいはそれを作成すると
、続いてステップ９７６においてプロセスは、要求情報を使用して新しい選択肢
レコード１２３ａ〜１２３ｎを現在の選択肢内に定義する。新しい選択肢レコー
ドは、このオブジェクトの位置を参照し、また、要求情報および応答情報のコピ
ーを含んでいる。新しい選択肢は、選択肢のベクトルに追加される。選択肢レコ
ードの複製は許容されている；つまり選択肢のベクトルは、同一の要求情報およ
び応答情報を含む複数の選択肢レコードを包含することができる。現存する選択
肢レコードを調べて複製を識別することは、複製の選択肢レコードによって占有
されるストレージの増加がほとんどわずかであることから、必要ないと考えられ
る。
、続いてステップ９７６においてプロセスは、要求情報を使用して新しい選択肢
レコード１２３ａ〜１２３ｎを現在の選択肢内に定義する。新しい選択肢レコー
ドは、このオブジェクトの位置を参照し、また、要求情報および応答情報のコピ
ーを含んでいる。新しい選択肢は、選択肢のベクトルに追加される。選択肢レコ
ードの複製は許容されている；つまり選択肢のベクトルは、同一の要求情報およ
び応答情報を含む複数の選択肢レコードを包含することができる。現存する選択
肢レコードを調べて複製を識別することは、複製の選択肢レコードによって占有
されるストレージの増加がほとんどわずかであることから、必要ないと考えられ
る。
【０１８３】 ステップ９７８においては、前述のステップを使用し、修正し
たベクトルをキャッシュに戻す。ステップ９８０においては、キー値を使用し、
前述した方法に従ってデータ・ストレージ・デバイス９０ａ〜９０ｃの１つにオ
ブジェクトを書き込む。ステップ９８０の間にそのキーが使用中であることがわ
かると、書き込みオペレーションが失敗する。これにより、キーによって識別さ
れる更新中のオブジェクトの上書きが回避される。
たベクトルをキャッシュに戻す。ステップ９８０においては、キー値を使用し、
前述した方法に従ってデータ・ストレージ・デバイス９０ａ〜９０ｃの１つにオ
ブジェクトを書き込む。ステップ９８０の間にそのキーが使用中であることがわ
かると、書き込みオペレーションが失敗する。これにより、キーによって識別さ
れる更新中のオブジェクトの上書きが回避される。
【０１８４】 （４．キャッシュの更新プロセス） 図９Ｇは、キャッシュの更新プロセスを示すフローチャートである。この更新
プロセスは、選択肢のベクトルを修正し、異なる要求情報または応答情報をスト
アするために使用される。概して更新プロセスは、キャッシュ８０がクライアン
ト１０ａからの要求に一致するオブジェクト５２を現在ストアしているが、プロ
トコル・エンジンによってそれが期限切れもしくはすでに有効でないと判断され
たとき、プロトコル・エンジン７０によって起動される。この種の状況において
は、プロトコル・エンジン７０がオリジナルのオブジェクト５２を提供したサー
バ４０とのＨＴＴＰトランザクションを開き、サーバ上でそのオブジェクトの変
更がなされているか否かについてサーバに問い合わせるメッセージを送る。この
プロセスは、オブジェクト５２の「再更新」と呼ばれている。サーバ４０がこの
問い合わせに対して否定的に応答する場合には、サーバから変更がないことを示
すヘッダとともに短いＨＴＴＰメッセージが提供され、さらに新しい応答情報が
提供される。その場合プロトコル・エンジン７０は、オブジェクト５２に関する
新しい応答情報をキャッシュ８０に移すためにキャッシュの更新プロセスを起動
する。
プロセスは、選択肢のベクトルを修正し、異なる要求情報または応答情報をスト
アするために使用される。概して更新プロセスは、キャッシュ８０がクライアン
ト１０ａからの要求に一致するオブジェクト５２を現在ストアしているが、プロ
トコル・エンジンによってそれが期限切れもしくはすでに有効でないと判断され
たとき、プロトコル・エンジン７０によって起動される。この種の状況において
は、プロトコル・エンジン７０がオリジナルのオブジェクト５２を提供したサー
バ４０とのＨＴＴＰトランザクションを開き、サーバ上でそのオブジェクトの変
更がなされているか否かについてサーバに問い合わせるメッセージを送る。この
プロセスは、オブジェクト５２の「再更新」と呼ばれている。サーバ４０がこの
問い合わせに対して否定的に応答する場合には、サーバから変更がないことを示
すヘッダとともに短いＨＴＴＰメッセージが提供され、さらに新しい応答情報が
提供される。その場合プロトコル・エンジン７０は、オブジェクト５２に関する
新しい応答情報をキャッシュ８０に移すためにキャッシュの更新プロセスを起動
する。
【０１８５】 キャッシュ８０内のそのオブジェクト５２の期限日または時刻
以降にその変更があり、問い合わせに対する肯定的な応答がサーバ４０からある
場合には、更新プロセスは起動されない。その場合サーバ４０は、更新済みのオ
ブジェクト５２のコピーを、新しい期限日およびその他の応答情報とともに返す
。一方プロトコル・エンジン７０は、上記に代えて前述したキャッシュの書き込
みプロセスおよび作成プロセスを起動し、新しいオブジェクト５２をキャッシュ
８０に追加する。
以降にその変更があり、問い合わせに対する肯定的な応答がサーバ４０からある
場合には、更新プロセスは起動されない。その場合サーバ４０は、更新済みのオ
ブジェクト５２のコピーを、新しい期限日およびその他の応答情報とともに返す
。一方プロトコル・エンジン７０は、上記に代えて前述したキャッシュの書き込
みプロセスおよび作成プロセスを起動し、新しいオブジェクト５２をキャッシュ
８０に追加する。
【０１８６】 更新プロセスは、図９Ｇに示したようにオブジェクト名、「古
い」識別名、要求情報および応答情報を含む入力パラメータを受け取る。このオ
ブジェクト名は、ＵＲＬもしくはＵＲＬから導かれたキーである。要求情報は、
キャッシュ８０からオブジェクト５２を求めるクライアントのＨＴＴＰ要求から
、また応答情報はキャッシュから更新済みのコピーをキャッシュが獲得したとき
の、サーバ４０の応答情報からそれぞれ導かれる。
い」識別名、要求情報および応答情報を含む入力パラメータを受け取る。このオ
ブジェクト名は、ＵＲＬもしくはＵＲＬから導かれたキーである。要求情報は、
キャッシュ８０からオブジェクト５２を求めるクライアントのＨＴＴＰ要求から
、また応答情報はキャッシュから更新済みのコピーをキャッシュが獲得したとき
の、サーバ４０の応答情報からそれぞれ導かれる。
【０１８７】 「古い」識別名は、要求情報と応答情報のペアを固有識別する
値である。好ましい実施例においては、キャッシュにミスが生じた結果としてキ
ャッシュ８０が新しいオブジェクトをキャッシュに書き込むとき、クライアント
からの要求情報と、そのオブジェクトのコピーを提供したサーバからの応答情報
をペアにする。各ペアには、固有の識別値が与えられる。
値である。好ましい実施例においては、キャッシュにミスが生じた結果としてキ
ャッシュ８０が新しいオブジェクトをキャッシュに書き込むとき、クライアント
からの要求情報と、そのオブジェクトのコピーを提供したサーバからの応答情報
をペアにする。各ペアには、固有の識別値が与えられる。
【０１８８】 ステップ９８６においてプロセスは、キャッシュからそのオブ
ジェクト名に対応する選択肢のベクトルを請け出す。好ましくはこれが、ここで
説明しているcheckout_write（チェックアウト＿ライト）プロセスを起動するこ
とによって行われるものとする。これは、オブジェクト名またはＵＲＬを使用し
たオープン・ディレクトリ、タグ・テーブルおよびディレクトリ・インデクスの
オブジェクトのルックアップを含み、その結果、対応する選択肢のベクトルが獲
得される。チェックアウト・プロセスがフェイルした場合には、ステップ９９６
においてプロセスが適切なエラー・メッセージを返す。
ジェクト名に対応する選択肢のベクトルを請け出す。好ましくはこれが、ここで
説明しているcheckout_write（チェックアウト＿ライト）プロセスを起動するこ
とによって行われるものとする。これは、オブジェクト名またはＵＲＬを使用し
たオープン・ディレクトリ、タグ・テーブルおよびディレクトリ・インデクスの
オブジェクトのルックアップを含み、その結果、対応する選択肢のベクトルが獲
得される。チェックアウト・プロセスがフェイルした場合には、ステップ９９６
においてプロセスが適切なエラー・メッセージを返す。
【０１８９】 チェックアウトが成功すると、ステップ９８８においてベクト
ルのコピーまたはクローンがメイン・メモリ内に作成される。要求／応答識別名
の値は、このプロセスに対する入力として受け取った古い識別名の値にそれを整
合させることによって、このベクトル内に配置される。それにおいては、古い識
別名の値が削除され、それに代えて新しい識別名が同じ場所に書き込まれる。こ
の新しい識別名は、入力としてこのプロセスに提供された新しい要求情報と応答
情報を固有に識別する。
ルのコピーまたはクローンがメイン・メモリ内に作成される。要求／応答識別名
の値は、このプロセスに対する入力として受け取った古い識別名の値にそれを整
合させることによって、このベクトル内に配置される。それにおいては、古い識
別名の値が削除され、それに代えて新しい識別名が同じ場所に書き込まれる。こ
の新しい識別名は、入力としてこのプロセスに提供された新しい要求情報と応答
情報を固有に識別する。
【０１９０】 ステップ９９０においては、新しいベクトルがストレージ・デ
バイス９０ａ〜９０ｃの１つに書き込まれ、ステップ９９２においては新しいベ
クトルがキャッシュに戻される。これらのステップの実行においては、ベクトル
のクローンを完全にストレージ・デバイスに書き込んだ後にそのベクトルを戻す
ことが望ましい。これは、書き込みオペレーションが成功した後にそのクローン
・ベクトルを参照すべくディレクトリ・テーブルが修正されることを保証する。
またこれは、古いベクトルへのアクセスを必要とするプロセスもしくはプログラ
ムがあるとき、それを使用可能にすることについても保証する。
バイス９０ａ〜９０ｃの１つに書き込まれ、ステップ９９２においては新しいベ
クトルがキャッシュに戻される。これらのステップの実行においては、ベクトル
のクローンを完全にストレージ・デバイスに書き込んだ後にそのベクトルを戻す
ことが望ましい。これは、書き込みオペレーションが成功した後にそのクローン
・ベクトルを参照すべくディレクトリ・テーブルが修正されることを保証する。
またこれは、古いベクトルへのアクセスを必要とするプロセスもしくはプログラ
ムがあるとき、それを使用可能にすることについても保証する。
【０１９１】 （５．ディレクトリのルックアップ） 図９Ｃは、好ましい実施例のオープン・ディレクトリ１３０内において行われ
る情報のルックアップのプロセスを示したフローチャートである。図９Ｃのプロ
セスは、入力パラメータとして名前キー６２のサブキー部分を受け取るプログラ
ム・プロセスまたはメソッドとして実装される。ここで、先行する図示していな
いステップにおいて、プロトコル・エンジン７０がＵＲＬ等のオブジェクト名を
受け取っていることを理解されよう。たとえば、クライアントからキャッシュを
動作させているサーバに対して発行されたＨＴＴＰ要求内においてＵＲＬが提供
される。プロトコル・エンジン７０は、このオブジェクト名に対してハッシュ関
数を適用する。このハッシュ関数は、その結果として、あるいはその出力として
キャッシュ内のセットを識別する名前キーを生じる。
る情報のルックアップのプロセスを示したフローチャートである。図９Ｃのプロ
セスは、入力パラメータとして名前キー６２のサブキー部分を受け取るプログラ
ム・プロセスまたはメソッドとして実装される。ここで、先行する図示していな
いステップにおいて、プロトコル・エンジン７０がＵＲＬ等のオブジェクト名を
受け取っていることを理解されよう。たとえば、クライアントからキャッシュを
動作させているサーバに対して発行されたＨＴＴＰ要求内においてＵＲＬが提供
される。プロトコル・エンジン７０は、このオブジェクト名に対してハッシュ関
数を適用する。このハッシュ関数は、その結果として、あるいはその出力として
キャッシュ内のセットを識別する名前キーを生じる。
【０１９２】 ステップ９４８においてこのプロセスは、ディレクトリ・イン
デクスからのサブキーによって識別される１ないしは複数のブロックの請け出し
を試みる。ブロックのチェックアウト・ステップは、好ましくはこれにおいて説
明しているcheckout_read（チェックアウト＿リード）プロセスの起動を含むも
のとする。すなわち：
デクスからのサブキーによって識別される１ないしは複数のブロックの請け出し
を試みる。ブロックのチェックアウト・ステップは、好ましくはこれにおいて説
明しているcheckout_read（チェックアウト＿リード）プロセスの起動を含むも
のとする。すなわち：
【０１９３】 チェックアウトの試みが失敗状態をもたらしたとき、ステップ
９５０においてプロセスは、それを呼び出したプログラムまたはプロセスに対し
て、入力サブキーに一致するブロックがキャッシュ内に見つからなかったことを
示すエラー・メッセージを返す。その後コントロールがステップ９５２に渡され
、それにおいてこのプロセスが終了する。
９５０においてプロセスは、それを呼び出したプログラムまたはプロセスに対し
て、入力サブキーに一致するブロックがキャッシュ内に見つからなかったことを
示すエラー・メッセージを返す。その後コントロールがステップ９５２に渡され
、それにおいてこのプロセスが終了する。
【０１９４】 チェックアウトの試みが成功した場合には、このプロセスを呼
び出したプログラムによるブロックのコピーの使用が可能になる。ステップ９５
４においては、請け出したブロックを再び戻す。ステップ９５６においてプロセ
スは、それを呼び出したプログラムに対し、要求されたブロックが見つかったこ
とを示すメッセージを返す。その後ステップ９５２においてこのプロセスが終了
する。
び出したプログラムによるブロックのコピーの使用が可能になる。ステップ９５
４においては、請け出したブロックを再び戻す。ステップ９５６においてプロセ
スは、それを呼び出したプログラムに対し、要求されたブロックが見つかったこ
とを示すメッセージを返す。その後ステップ９５２においてこのプロセスが終了
する。
【０１９５】 このように、キャッシュのサーチ・オペレーションは、オープ
ン・ディレクトリからキーによって識別されるブロックの請け出しを求める、よ
り基本的なプロセスの呼び出しを伴う。基本的なプロセスによりオープン・ディ
レクトリ内においてそのブロックが見つからなかったときは、ディレクトリ・イ
ンデクスがサーチされる。
ン・ディレクトリからキーによって識別されるブロックの請け出しを求める、よ
り基本的なプロセスの呼び出しを伴う。基本的なプロセスによりオープン・ディ
レクトリ内においてそのブロックが見つからなかったときは、ディレクトリ・イ
ンデクスがサーチされる。
【０１９６】 ブロックが見つかったときは、それがクライアントに配信され
る。たとえば、本発明をワールド・ワイド・ウェブ関連に適用する場合、クライ
アントに対するＨＴＴＰ接続を開き、ＨＴＴＰトランザクションを使用してデー
タ・ブロックをそのクライアントに送信することによって、そのデータ・ブロッ
クが配信される。このステップは、トランザクションを開く前にいくつかのデー
タ・ブロックのバッファリングを伴うこともある。
る。たとえば、本発明をワールド・ワイド・ウェブ関連に適用する場合、クライ
アントに対するＨＴＴＰ接続を開き、ＨＴＴＰトランザクションを使用してデー
タ・ブロックをそのクライアントに送信することによって、そのデータ・ブロッ
クが配信される。このステップは、トランザクションを開く前にいくつかのデー
タ・ブロックのバッファリングを伴うこともある。
【０１９７】 （６．キャッシュの削除プロセス） 図９Ｄは、キャッシュからオブジェクトに関連するブロックを削除するプロセ
スを示したフローチャートである。チェックアウト・オペレーションの場合と同
様に、キャッシュの削除プロセスは、入力としてキー値を受け取る。このプロセ
スは、ステップ９５８〜９６２からなる。これらのステップは、図９Ｃに示した
ステップ９４８、９５４および９５２のオペレーションと実質的に類似するオペ
レーションを実行する。しかしながら、キャッシュ内に見つかったブロックの削
除を行うためにこのプロセスは、ステップ９６０において、削除フラグをセット
し、削除フラグをセットした状態でそのブロックを戻す。チェックイン・プロセ
スに関連してここで述べているように（図９Ｂのステップ９３８および９４４）
、削除フラグがセットされているときは、そのブロックが削除済みとしてマーク
されることになる。その後、オープン・ディレクトリ内に反映された変更がディ
レクトリ・インデクスと同期されたとき、このブロックが最終的にディレクトリ
・インデクスから削除される。
スを示したフローチャートである。チェックアウト・オペレーションの場合と同
様に、キャッシュの削除プロセスは、入力としてキー値を受け取る。このプロセ
スは、ステップ９５８〜９６２からなる。これらのステップは、図９Ｃに示した
ステップ９４８、９５４および９５２のオペレーションと実質的に類似するオペ
レーションを実行する。しかしながら、キャッシュ内に見つかったブロックの削
除を行うためにこのプロセスは、ステップ９６０において、削除フラグをセット
し、削除フラグをセットした状態でそのブロックを戻す。チェックイン・プロセ
スに関連してここで述べているように（図９Ｂのステップ９３８および９４４）
、削除フラグがセットされているときは、そのブロックが削除済みとしてマーク
されることになる。その後、オープン・ディレクトリ内に反映された変更がディ
レクトリ・インデクスと同期されたとき、このブロックが最終的にディレクトリ
・インデクスから削除される。
【０１９８】 （７．チェックアウト・リード・オペレーション） 図８Ｄは、ディレクトリ・テーブル１１０に関連して使用されるcheckout_rea
d（チェックアウト＿リード）オペレーションを示すフローチャートである。こ
のcheckout_read（チェックアウト＿リード）オペレーションは、特定のキーに
一致するディレクトリ・テーブル１１０のブロックからコピーを獲得するために
使用される。ディレクトリ・テーブル１１０からそのブロックを請け出した後は
、そのブロックを請け出したプロセスに限って、それを読み出して使用すること
が可能、つまりほかのプロセスにはそれができない。その後、別のプロセスがそ
のブロックを使用できるようにするためには、そのブロックを戻す必要がある。
相補的なチェックアウト‐チェックイン（請け出しおよび戻し）のプロセスは、
ディレクトリ・テーブルのブロックを修正できるプロセスを１度に１つに限るこ
とを保証するために使用され、このメカニズムは、ディレクトリ・テーブルが常
にキャッシュ内のオブジェクトに関する正確な情報をストアしていることを保証
するために欠くことができない。つまり、いずれ明らかになろうが、チェックア
ウト・プロセスおよびチェックイン・プロセスは、特定のオブジェクトに関する
キャッシュのサーチを補助する基本的なプロセスである。
d（チェックアウト＿リード）オペレーションを示すフローチャートである。こ
のcheckout_read（チェックアウト＿リード）オペレーションは、特定のキーに
一致するディレクトリ・テーブル１１０のブロックからコピーを獲得するために
使用される。ディレクトリ・テーブル１１０からそのブロックを請け出した後は
、そのブロックを請け出したプロセスに限って、それを読み出して使用すること
が可能、つまりほかのプロセスにはそれができない。その後、別のプロセスがそ
のブロックを使用できるようにするためには、そのブロックを戻す必要がある。
相補的なチェックアウト‐チェックイン（請け出しおよび戻し）のプロセスは、
ディレクトリ・テーブルのブロックを修正できるプロセスを１度に１つに限るこ
とを保証するために使用され、このメカニズムは、ディレクトリ・テーブルが常
にキャッシュ内のオブジェクトに関する正確な情報をストアしていることを保証
するために欠くことができない。つまり、いずれ明らかになろうが、チェックア
ウト・プロセスおよびチェックイン・プロセスは、特定のオブジェクトに関する
キャッシュのサーチを補助する基本的なプロセスである。
【０１９９】 図８Ｄに示されるようにcheckout_read（チェックアウト＿リ
ード）オペレーションは、入力としてキー値を受け取る。好ましい実施例におい
ては、この入力キー値が、オブジェクト名に対応する名前キー６２のサブキー部
分になる。
ード）オペレーションは、入力としてキー値を受け取る。好ましい実施例におい
ては、この入力キー値が、オブジェクト名に対応する名前キー６２のサブキー部
分になる。
【０２００】 オブジェクト・ストアがメモリおよびディスクのデータ構造の
一部を修正しようとしていることから、一貫性のある結果を達成するために、キ
ャッシュ・データ構造のサブセットに対する短期間の相互排他を保証する必要が
ある。キャッシュ・データ構造は、２５６の仮想「スライス」に分割されており
、８ビットのキーによって選択される。各スライスは、関連するｍｕｔｅｘロッ
クを有している。ステップ８３２においてプロセスは、入力キー用のロックを探
してそれを獲得する。ロックが獲得できない場合、プロセスは、それが入手可能
になるまで短時間の待機を行う。別のトランザクションが、同一のスライスに至
るキーに関連付けされた小部分のメモリの状態を修正しているときは、ロックが
入手不可能となり得る。
一部を修正しようとしていることから、一貫性のある結果を達成するために、キ
ャッシュ・データ構造のサブセットに対する短期間の相互排他を保証する必要が
ある。キャッシュ・データ構造は、２５６の仮想「スライス」に分割されており
、８ビットのキーによって選択される。各スライスは、関連するｍｕｔｅｘロッ
クを有している。ステップ８３２においてプロセスは、入力キー用のロックを探
してそれを獲得する。ロックが獲得できない場合、プロセスは、それが入手可能
になるまで短時間の待機を行う。別のトランザクションが、同一のスライスに至
るキーに関連付けされた小部分のメモリの状態を修正しているときは、ロックが
入手不可能となり得る。
【０２０１】 ロックの獲得後は、別のプロセスによるこの入力キーの使用が
できなくなる。ステップ８３４においてプロセスは、ディレクトリ・テーブル１
１０のセット１１０ａ〜１１０ｎのうち、いずれがこのキーに対応するかを決定
する。続いてこのプロセスは、ディレクトリ・テーブル１１０のセットに対応す
るオープン・ディレクトリ１３０のブロック・リスト１３２ａ、１３２ｂのいず
れか１つを、入力キーのサブキーの値をブロック・リストの１つに関連付けする
ことによって見つける。このプロセスは、ステップ８３６においてオープン・デ
ィレクトリ１３０の選択したブロック・リスト内のブロックをスキャンし、入力
キーに一致するキーをストアしているブロックを探す。
できなくなる。ステップ８３４においてプロセスは、ディレクトリ・テーブル１
１０のセット１１０ａ〜１１０ｎのうち、いずれがこのキーに対応するかを決定
する。続いてこのプロセスは、ディレクトリ・テーブル１１０のセットに対応す
るオープン・ディレクトリ１３０のブロック・リスト１３２ａ、１３２ｂのいず
れか１つを、入力キーのサブキーの値をブロック・リストの１つに関連付けする
ことによって見つける。このプロセスは、ステップ８３６においてオープン・デ
ィレクトリ１３０の選択したブロック・リスト内のブロックをスキャンし、入力
キーに一致するキーをストアしているブロックを探す。
【０２０２】 一致が見つかるとこのプロセスは、ステップ８３８において、
一致したブロックが別のプロセスによって現在、作成中であるか、あるいは壊れ
ているか否かについて評価する。一致したブロックが現在、作成中もしくは壊れ
ている場合には、ステップ８４０において、現在のブロックは使用不可能である
ことを示すエラー・メッセージをプロトコル・エンジン７０に返す。
一致したブロックが別のプロセスによって現在、作成中であるか、あるいは壊れ
ているか否かについて評価する。一致したブロックが現在、作成中もしくは壊れ
ている場合には、ステップ８４０において、現在のブロックは使用不可能である
ことを示すエラー・メッセージをプロトコル・エンジン７０に返す。
【０２０３】 これに対して、一致したブロックが現在、作成中でなく、壊れ
ていなければ、そのブロックを使用することができる。その場合プロセスは、ス
テップ８４２において読み出しカウンタをインクリメントする。読み出しカウン
タは、そのブロックに関連付けされた内部変数であり、そのブロックを読み出し
ているプロセスもしくはプログラム・オブジェクトのインスタンスの数を示す。
この種のプロセスもしくはオブジェクトは、「リーダー」と呼ばれる。ステップ
８４４においてプロセスは、そのブロックのコピーを獲得し、呼び出しているプ
ログラムまたはプロセスにそれを返す。
ていなければ、そのブロックを使用することができる。その場合プロセスは、ス
テップ８４２において読み出しカウンタをインクリメントする。読み出しカウン
タは、そのブロックに関連付けされた内部変数であり、そのブロックを読み出し
ているプロセスもしくはプログラム・オブジェクトのインスタンスの数を示す。
この種のプロセスもしくはオブジェクトは、「リーダー」と呼ばれる。ステップ
８４４においてプロセスは、そのブロックのコピーを獲得し、呼び出しているプ
ログラムまたはプロセスにそれを返す。
【０２０４】 ステップ８３６のスキャンにおいて一致が見つからないと、こ
のプロセスは、ステップ８４６においてディレクトリ・テーブルのサーチを起動
し、ここで詳しく説明しているプロセスを使用してこのキーに一致するディレク
トリ・テーブルのセットおよびブロックを探す。このサーチにおいてもキーとの
一致が見つからなかったときは、ステップ８４８において、このプロセスから、
それを呼び出しているプログラムもしくはプロセスに対し、要求されたオブジェ
クトがキャッシュ内に存在しない旨を表すエラー・メッセージを返す。このプロ
セスを呼び出しているプログラムもしくはプロセスは、この種のメッセージに対
する具体的な応答を決定するが、ワールド・ワイド・ウェブに関して言えば、一
般にプロキシ３０がＨＴＴＰ要求を使用してオブジェクトをストアしているサー
バ４０にコンタクトし、要求されているオブジェクトのコピーを獲得する。
のプロセスは、ステップ８４６においてディレクトリ・テーブルのサーチを起動
し、ここで詳しく説明しているプロセスを使用してこのキーに一致するディレク
トリ・テーブルのセットおよびブロックを探す。このサーチにおいてもキーとの
一致が見つからなかったときは、ステップ８４８において、このプロセスから、
それを呼び出しているプログラムもしくはプロセスに対し、要求されたオブジェ
クトがキャッシュ内に存在しない旨を表すエラー・メッセージを返す。このプロ
セスを呼び出しているプログラムもしくはプロセスは、この種のメッセージに対
する具体的な応答を決定するが、ワールド・ワイド・ウェブに関して言えば、一
般にプロキシ３０がＨＴＴＰ要求を使用してオブジェクトをストアしているサー
バ４０にコンタクトし、要求されているオブジェクトのコピーを獲得する。
【０２０５】 ステップ８４６においてディレクトリ・インデクスをルックア
ップする間に一致が見つかると、ステップ８５０において対応するブロックをオ
ープン・ディレクトリに追加する。これにおいては、メイン・メモリ内に新しい
オープン・ディレクトリ・ブロックを作成し；対応するディレクトリ・インデク
スのブロックから情報をコピーすることによってそのブロックを初期化し；さら
に、新しいブロックに対する参照を対応するブロック１３２ａ、１３２ｂのリス
トに追加する。
ップする間に一致が見つかると、ステップ８５０において対応するブロックをオ
ープン・ディレクトリに追加する。これにおいては、メイン・メモリ内に新しい
オープン・ディレクトリ・ブロックを作成し；対応するディレクトリ・インデク
スのブロックから情報をコピーすることによってそのブロックを初期化し；さら
に、新しいブロックに対する参照を対応するブロック１３２ａ、１３２ｂのリス
トに追加する。
【０２０６】 （８．チェックアウト・ライト・オペレーション） 図８Ｅは、オープン・ディレクトリ１３０に関連して使用されるcheckout_wri
te（チェックアウト＿ライト）プロセスまたはオペレーションを示すフローチャ
ートである。checkout_write（チェックアウト＿ライト）オペレーションは、こ
のプロセスに渡されたキーに一致するブロックのコピーをオープン・ディレクト
リ１３０から獲得し、そのブロックのコンテンツ、またはそのブロックに関連付
けされたオブジェクトないしはベクトルを修正または更新するために使用される
。checkout_write（チェックアウト＿ライト）を使用してオープン・ディレクト
リ１３０からブロックを請け出した後は、別のプロセスがそのブロックまたは、
その関連オブジェクトないしはベクトルを修正することができる。その後ブロッ
クは、ここに説明のあるチェックイン・プロセスを使用して戻される。これらの
オペレーションを使用して、オープン・ディレクトリに変更がストアされ、続い
て規則に従ってそれがディレクトリ・テーブルに伝えられる。
te（チェックアウト＿ライト）プロセスまたはオペレーションを示すフローチャ
ートである。checkout_write（チェックアウト＿ライト）オペレーションは、こ
のプロセスに渡されたキーに一致するブロックのコピーをオープン・ディレクト
リ１３０から獲得し、そのブロックのコンテンツ、またはそのブロックに関連付
けされたオブジェクトないしはベクトルを修正または更新するために使用される
。checkout_write（チェックアウト＿ライト）を使用してオープン・ディレクト
リ１３０からブロックを請け出した後は、別のプロセスがそのブロックまたは、
その関連オブジェクトないしはベクトルを修正することができる。その後ブロッ
クは、ここに説明のあるチェックイン・プロセスを使用して戻される。これらの
オペレーションを使用して、オープン・ディレクトリに変更がストアされ、続い
て規則に従ってそれがディレクトリ・テーブルに伝えられる。
【０２０７】 図８Ｅに示すようにcheckout_write（チェックアウト＿ライト
）プロセスは、入力としてキー値を受け取る。好ましい実施例においては、この
入力キー値が、オブジェクト名に対応する名前キー６２のサブキー部分になる。
ステップ８５４においてこのプロセスは、指定されたキーに係るロックを探して
獲得する。ロックが獲得できない場合、プロセスは、それが入手可能になるまで
待機する。
）プロセスは、入力としてキー値を受け取る。好ましい実施例においては、この
入力キー値が、オブジェクト名に対応する名前キー６２のサブキー部分になる。
ステップ８５４においてこのプロセスは、指定されたキーに係るロックを探して
獲得する。ロックが獲得できない場合、プロセスは、それが入手可能になるまで
待機する。
【０２０８】 ロックの獲得後は、別のプロセスによるこのキーの使用ができ
なくなる。ステップ８５６においてプロセスは、ディレクトリ・テーブル１１０
のセット１１０ａ〜１１０ｎのうち、いずれがこのキーに対応するかを決定する
。続いてこのプロセスは、ディレクトリ・テーブル１１０のセットに対応するオ
ープン・ディレクトリ１３０のブロック・リスト１３２ａ、１３２ｂのいずれか
１つを見つける。ステップ８５８においてこのプロセスは、オープン・ディレク
トリ１３０の、選択したブロック・リスト内のブロックをスキャンし、入力キー
に一致するキーをストアしているブロックを探す。
なくなる。ステップ８５６においてプロセスは、ディレクトリ・テーブル１１０
のセット１１０ａ〜１１０ｎのうち、いずれがこのキーに対応するかを決定する
。続いてこのプロセスは、ディレクトリ・テーブル１１０のセットに対応するオ
ープン・ディレクトリ１３０のブロック・リスト１３２ａ、１３２ｂのいずれか
１つを見つける。ステップ８５８においてこのプロセスは、オープン・ディレク
トリ１３０の、選択したブロック・リスト内のブロックをスキャンし、入力キー
に一致するキーをストアしているブロックを探す。
【０２０９】 一致が見つかるとこのプロセスは、ステップ８６４において、
一致したブロックが別のプロセスによって現在、作成中であるか、あるいは壊れ
ているか否かについて評価する。それに該当する場合には、ステップ８６６にお
いて、現在のブロックは使用不可能であることを示すエラー・メッセージをプロ
トコル・エンジン７０またはキャッシュ８０に返す。一致したブロックが現在、
作成中でなく、壊されていなければ、そのブロックを使用することができる。そ
の場合このプロセスは、ステップ８６８において書き込みカウンタをインクリメ
ントする。この書き込みカウンタは、そのブロックに関連付けてストアされる内
部変数であり、そのブロックに書き込みを行っているプロセスもしくはプログラ
ム・オブジェクトの数を示す。ステップ８７０においてプロセスは、ブロックの
コピーを獲得し、呼び出しているプログラムまたはプロセスにそれを返すととも
に、そのコピーに修正中である旨のマークを付する。このマーク付けは、オープ
ン・ディレクトリをディレクトリ・インデクスに同期させるとき、そのブロック
に加えられた変更がディレクトリ・インデクス内に反映されることを保証する。
一致したブロックが別のプロセスによって現在、作成中であるか、あるいは壊れ
ているか否かについて評価する。それに該当する場合には、ステップ８６６にお
いて、現在のブロックは使用不可能であることを示すエラー・メッセージをプロ
トコル・エンジン７０またはキャッシュ８０に返す。一致したブロックが現在、
作成中でなく、壊されていなければ、そのブロックを使用することができる。そ
の場合このプロセスは、ステップ８６８において書き込みカウンタをインクリメ
ントする。この書き込みカウンタは、そのブロックに関連付けてストアされる内
部変数であり、そのブロックに書き込みを行っているプロセスもしくはプログラ
ム・オブジェクトの数を示す。ステップ８７０においてプロセスは、ブロックの
コピーを獲得し、呼び出しているプログラムまたはプロセスにそれを返すととも
に、そのコピーに修正中である旨のマークを付する。このマーク付けは、オープ
ン・ディレクトリをディレクトリ・インデクスに同期させるとき、そのブロック
に加えられた変更がディレクトリ・インデクス内に反映されることを保証する。
【０２１０】 ステップ８５８のスキャンにおいて一致が見つからないとき、
このプロセスはステップ８６０において、ここで詳しく説明しているプロセスを
使用したディレクトリ・インデクスのサーチを起動する。このサーチにおいても
一致が見つからなかったときは、ステップ８６２において、このプロセスから、
それを呼び出しているプログラムもしくはプロセスに対し、要求されたオブジェ
クトがキャッシュ内に存在しない旨を表すエラー・メッセージを返す。ワールド
・ワイド・ウェブに関して言えば、通常、呼び出しているプログラムがＨＴＴＰ
要求を使用してそのオブジェクトをストアしている発信サーバにコンタクトし、
要求されたオブジェクトのコピーを獲得する。
このプロセスはステップ８６０において、ここで詳しく説明しているプロセスを
使用したディレクトリ・インデクスのサーチを起動する。このサーチにおいても
一致が見つからなかったときは、ステップ８６２において、このプロセスから、
それを呼び出しているプログラムもしくはプロセスに対し、要求されたオブジェ
クトがキャッシュ内に存在しない旨を表すエラー・メッセージを返す。ワールド
・ワイド・ウェブに関して言えば、通常、呼び出しているプログラムがＨＴＴＰ
要求を使用してそのオブジェクトをストアしている発信サーバにコンタクトし、
要求されたオブジェクトのコピーを獲得する。
【０２１１】 ステップ８６０においてディレクトリ・インデクスをルックア
ップする間に一致が見つかると、ステップ８７４において対応するブロックをオ
ープン・ディレクトリに追加する。これにおいては、メイン・メモリ内に新しい
オープン・ディレクトリ・ブロックを作成し；対応するディレクトリ・インデク
スのブロックから情報をコピーすることによってそのブロックを初期化し；さら
に、新しいブロックに対する参照を対応するブロック１３２ａ、１３２ｂのリス
トに追加する。その後コントロールがステップ８６８に渡され、それにおいて書
き込みカウントがインクリメントされ、ステップ８６８〜８７０との関連で説明
したようにこのプロセスが継続される。
ップする間に一致が見つかると、ステップ８７４において対応するブロックをオ
ープン・ディレクトリに追加する。これにおいては、メイン・メモリ内に新しい
オープン・ディレクトリ・ブロックを作成し；対応するディレクトリ・インデク
スのブロックから情報をコピーすることによってそのブロックを初期化し；さら
に、新しいブロックに対する参照を対応するブロック１３２ａ、１３２ｂのリス
トに追加する。その後コントロールがステップ８６８に渡され、それにおいて書
き込みカウントがインクリメントされ、ステップ８６８〜８７０との関連で説明
したようにこのプロセスが継続される。
【０２１２】 （９．チェックアウト・クリエイト・オペレーション） 図８Ｆは、オープン・ディレクトリ１３０に関連して使用するためにサポート
されているcheckout_create（チェックアウト＿クリエイト）オペレーションを
示すフローチャートである。checkout_create（チェックアウト＿クリエイト）
オペレーションは、キャッシュに追加される新しいオブジェクトに対応する名前
キーに関して、オープン・ディレクトリ１３０内に新しいブロックを作成するた
めに使用される。オープン・ディレクトリ１３０内にブロックが作成された後は
、ユーザがオープン・ディレクトリ１３０を介してキャッシュからそのオブジェ
クトを獲得することができる。
されているcheckout_create（チェックアウト＿クリエイト）オペレーションを
示すフローチャートである。checkout_create（チェックアウト＿クリエイト）
オペレーションは、キャッシュに追加される新しいオブジェクトに対応する名前
キーに関して、オープン・ディレクトリ１３０内に新しいブロックを作成するた
めに使用される。オープン・ディレクトリ１３０内にブロックが作成された後は
、ユーザがオープン・ディレクトリ１３０を介してキャッシュからそのオブジェ
クトを獲得することができる。
【０２１３】 図８Ｆに示されるように、checkout_create（チェックアウト
＿クリエイト）プロセスは、入力としてキー値を受け取る。好ましい実施例にお
いては、この入力キー値が、オブジェクト名に対応する名前キー６２のサブキー
部分になる。ステップ８７６においてこのプロセスは、指定されたキーに係るロ
ックを探して獲得する。ロックが獲得できない場合、プロセスは、それが入手可
能になるまで待機する。
＿クリエイト）プロセスは、入力としてキー値を受け取る。好ましい実施例にお
いては、この入力キー値が、オブジェクト名に対応する名前キー６２のサブキー
部分になる。ステップ８７６においてこのプロセスは、指定されたキーに係るロ
ックを探して獲得する。ロックが獲得できない場合、プロセスは、それが入手可
能になるまで待機する。
【０２１４】 ロックの獲得後は、別のプロセスによるこのキーの使用ができ
なくなる。ステップ８７８においてプロセスは、ディレクトリ・テーブル１１０
のセット１１０ａ〜１１０ｎのうち、いずれがこのキーに対応するかを決定する
。続いてこのプロセスは、入力キーのセット・サブキー・ビットを使用して、デ
ィレクトリ・テーブル１１０のセットに対応するオープン・ディレクトリ１３０
のセットを見つける。ステップ８８０においてこのプロセスは、オープン・ディ
レクトリ１３０の選択したブロック・リスト内のブロックをスキャンし、入力キ
ーに一致するキーをストアしているブロックを探す。
なくなる。ステップ８７８においてプロセスは、ディレクトリ・テーブル１１０
のセット１１０ａ〜１１０ｎのうち、いずれがこのキーに対応するかを決定する
。続いてこのプロセスは、入力キーのセット・サブキー・ビットを使用して、デ
ィレクトリ・テーブル１１０のセットに対応するオープン・ディレクトリ１３０
のセットを見つける。ステップ８８０においてこのプロセスは、オープン・ディ
レクトリ１３０の選択したブロック・リスト内のブロックをスキャンし、入力キ
ーに一致するキーをストアしているブロックを探す。
【０２１５】 一致が見つかった場合には、すでに存在しているブロックの作
成を試みていることになる。そこでこのプロセスは、ステップ８８２において一
致したブロックが削除済みとしてマークされているか、また現在、それの読み出
しあるいは書き込みを行っているほかのプロセスがないかを評価する。リーダー
・カウンタおよびライター・カウンタの値がともにゼロであれば、ほかのプロセ
スによるそのブロックの読み出しあるいは書き込みはない。リーダー・カウンタ
およびライター・カウンタの値のいずれかがゼロでないとき、あるいは一致した
ブロックが削除済みとマークされていないとき、そのブロックはすでに現存する
有効なブロックであり、それを作成することはできない。その場合、ステップ８
８４において、現在のブロックを作成する要求に応じることができない旨を示す
エラー・メッセージをプロトコル・エンジン７０またはキャッシュ８０に返す。
成を試みていることになる。そこでこのプロセスは、ステップ８８２において一
致したブロックが削除済みとしてマークされているか、また現在、それの読み出
しあるいは書き込みを行っているほかのプロセスがないかを評価する。リーダー
・カウンタおよびライター・カウンタの値がともにゼロであれば、ほかのプロセ
スによるそのブロックの読み出しあるいは書き込みはない。リーダー・カウンタ
およびライター・カウンタの値のいずれかがゼロでないとき、あるいは一致した
ブロックが削除済みとマークされていないとき、そのブロックはすでに現存する
有効なブロックであり、それを作成することはできない。その場合、ステップ８
８４において、現在のブロックを作成する要求に応じることができない旨を示す
エラー・メッセージをプロトコル・エンジン７０またはキャッシュ８０に返す。
【０２１６】 一致したブロックが削除されており、それにアクセスしている
ライターないしはリーダーがまったくない場合、プロセスは、一致している、以
前作成されたブロックを作成し、初期化することによって、事実上、新しいブロ
ックを作成することができる。そこでこのプロセスは、ステップ８８６において
一致しているブロックをクリアする。ステップ８８８においてこのプロセスは、
特定のフィールドにゼロを書き込み、ブロックのキー値を現在のキーにセットす
ることによってクリアしたブロックを初期化する。ブロック８９０においてプロ
セスは、そのブロックに関連付けされているライター・カウンタをインクリメン
トし、そのブロックを作成済みとしてマークする。ステップ８９２においてプロ
セスは、それを呼び出しているプロセスまたはプログラム・オブジェクトにその
ブロックのコピーを返し、そのブロックを修正中としてマークする。
ライターないしはリーダーがまったくない場合、プロセスは、一致している、以
前作成されたブロックを作成し、初期化することによって、事実上、新しいブロ
ックを作成することができる。そこでこのプロセスは、ステップ８８６において
一致しているブロックをクリアする。ステップ８８８においてこのプロセスは、
特定のフィールドにゼロを書き込み、ブロックのキー値を現在のキーにセットす
ることによってクリアしたブロックを初期化する。ブロック８９０においてプロ
セスは、そのブロックに関連付けされているライター・カウンタをインクリメン
トし、そのブロックを作成済みとしてマークする。ステップ８９２においてプロ
セスは、それを呼び出しているプロセスまたはプログラム・オブジェクトにその
ブロックのコピーを返し、そのブロックを修正中としてマークする。
【０２１７】 ステップ８８０のスキャンにおいて一致が見つからなかった場
合は、現在、オープン・ディレクトリ１３０内に一致するブロックが存在してい
ない。その場合このプロセスは、ステップ８９４において、ここで詳しく説明し
ているプロセスを使用してディレクトリ・インデクスのサーチを行う。そのサー
チにより一致が見つかると、ステップ８９６においてプロセスは、それを呼び出
しているプログラムまたはプロセスに対し、作成しようとしているブロックがキ
ャッシュ内にすでに存在し、削除することができない旨を示すエラー・メッセー
ジを返す。
合は、現在、オープン・ディレクトリ１３０内に一致するブロックが存在してい
ない。その場合このプロセスは、ステップ８９４において、ここで詳しく説明し
ているプロセスを使用してディレクトリ・インデクスのサーチを行う。そのサー
チにより一致が見つかると、ステップ８９６においてプロセスは、それを呼び出
しているプログラムまたはプロセスに対し、作成しようとしているブロックがキ
ャッシュ内にすでに存在し、削除することができない旨を示すエラー・メッセー
ジを返す。
【０２１８】 一致が見つからなかったときは、キャッシュ全体にわたり、一
致するブロックがまったく存在しないことになる。そこでこのプロセスは、ステ
ップ８９８において、新しいオープン・ディレクトリのブロックを作成し、その
ブロックに対する参照を、ステップ８７８において演算したセット値に関連付け
されたリスト１３２ａ、１３２ｂに追加する。その後コントロールがステップ８
９０に渡され、ステップ８９０〜８９２に関連して前述した説明のとおりにステ
ップが継続される。
致するブロックがまったく存在しないことになる。そこでこのプロセスは、ステ
ップ８９８において、新しいオープン・ディレクトリのブロックを作成し、その
ブロックに対する参照を、ステップ８７８において演算したセット値に関連付け
されたリスト１３２ａ、１３２ｂに追加する。その後コントロールがステップ８
９０に渡され、ステップ８９０〜８９２に関連して前述した説明のとおりにステ
ップが継続される。
【０２１９】 （１０．チェックイン・プロセス） 図９Ｂにブロックのチェックイン・プロセスのフローチャートを示す。キャッ
シュ８０は、ブロックの読み出し、修正、または削除を行った後、図９Ｂに示し
たプロセスを実行してそのブロックをオープン・ディレクトリ１３０に戻す。一
実施例においては図９Ｂに示したプロセスが、ブロックの識別名をパラメータと
して受け取るプログラム・プロセスまたはオブジェクトとして実装される。この
キーが、請け出したブロック内に存在することから、引数としてこのキーを渡す
必要はない。
シュ８０は、ブロックの読み出し、修正、または削除を行った後、図９Ｂに示し
たプロセスを実行してそのブロックをオープン・ディレクトリ１３０に戻す。一
実施例においては図９Ｂに示したプロセスが、ブロックの識別名をパラメータと
して受け取るプログラム・プロセスまたはオブジェクトとして実装される。この
キーが、請け出したブロック内に存在することから、引数としてこのキーを渡す
必要はない。
【０２２０】 このプロセスは、ステップ９３０においてブロックに関連付け
されたキーに対応するロックの獲得を試みる。入手可能なロックが存在しないと
きは、プロセスが待機ループに入り、ロックが入手可能になるまでの待機を設定
する。ロックが入手できたとき、ステップ９３２においてこのプロセスは、その
ブロックが修正され、それを戻そうとしているか否かを評価する。それに該当す
るときは、ステップ９３４においてそのブロック用のライター・カウントをデク
リメントし、プロセスがそのブロックに対する書き込みを完了したことを示す。
されたキーに対応するロックの獲得を試みる。入手可能なロックが存在しないと
きは、プロセスが待機ループに入り、ロックが入手可能になるまでの待機を設定
する。ロックが入手できたとき、ステップ９３２においてこのプロセスは、その
ブロックが修正され、それを戻そうとしているか否かを評価する。それに該当す
るときは、ステップ９３４においてそのブロック用のライター・カウントをデク
リメントし、プロセスがそのブロックに対する書き込みを完了したことを示す。
【０２２１】 ステップ９３６においてプロセスは、チェックイン・プロセス
の実行が成功したか否かを評価する。このとき成功であると評価されるときは、
続いてステップ９４２においてプロセスは、現在のブロック内の情報を、オープ
ン・ディレクトリ内の対応するオリジナルのブロックにコピーする。このように
して、チェックアウト・プロセスにおいて獲得したブロックのコピーを修正する
プロセスによって実行された変更を用いてオープン・ディレクトリが更新される
。その後、あるいはステップ９３６の評価が否定であった場合に、プロセスは削
除チェックイン・フラグがセットされているか否かを評価する。この削除チェッ
クイン・フラグは、チェックインの後にそのブロックを削除することを示す。削
除フラグは、チェックイン・オペレーションに対する引数である。このフラグが
セットされているとき、ステップ９４４においてプロセスは、そのブロックを削
除済みとしてマークを付ける。このプロセスは、ステップ９４０において終了す
る。
の実行が成功したか否かを評価する。このとき成功であると評価されるときは、
続いてステップ９４２においてプロセスは、現在のブロック内の情報を、オープ
ン・ディレクトリ内の対応するオリジナルのブロックにコピーする。このように
して、チェックアウト・プロセスにおいて獲得したブロックのコピーを修正する
プロセスによって実行された変更を用いてオープン・ディレクトリが更新される
。その後、あるいはステップ９３６の評価が否定であった場合に、プロセスは削
除チェックイン・フラグがセットされているか否かを評価する。この削除チェッ
クイン・フラグは、チェックインの後にそのブロックを削除することを示す。削
除フラグは、チェックイン・オペレーションに対する引数である。このフラグが
セットされているとき、ステップ９４４においてプロセスは、そのブロックを削
除済みとしてマークを付ける。このプロセスは、ステップ９４０において終了す
る。
【０２２２】 ステップ９３２の評価が否定であった場合には、このブロック
は修正されていない。その結果、可能性のある唯一の状態は、このブロックが読
み出されたこととなる。したがって、ステップ９４６においてリーダー・カウン
トをデクリメントする。
は修正されていない。その結果、可能性のある唯一の状態は、このブロックが読
み出されたこととなる。したがって、ステップ９４６においてリーダー・カウン
トをデクリメントする。
【０２２３】 （方法の実装） 好ましい実施例においては、ここで説明している方法が図１１に示すタイプの
汎用プログラマブル・ディジタル・コンピュータ・システムを使用して実行され
る。これらの方法のそれぞれは、いくつかの異なるやり方で実装することができ
る。たとえば、シングル・プロセス、またはマルチスレッド、マルチプロセッシ
ング・システムにおいて、手続き型コンピュータ・プログラム、オブジェクト指
向プログラム、プロセス、アプレット等の形式によりこれらの方法を実装するこ
とができる。
汎用プログラマブル・ディジタル・コンピュータ・システムを使用して実行され
る。これらの方法のそれぞれは、いくつかの異なるやり方で実装することができ
る。たとえば、シングル・プロセス、またはマルチスレッド、マルチプロセッシ
ング・システムにおいて、手続き型コンピュータ・プログラム、オブジェクト指
向プログラム、プロセス、アプレット等の形式によりこれらの方法を実装するこ
とができる。
【０２２４】 好ましい実施例においては、プロセスのそれぞれが独立かつ再
入可能であり、したがってキャッシュが動作しているときは、各プロセスのイン
スタンスを複数回にわたって作ることができる。たとえば、ガーベジ・コレクシ
ョン・プロセスは、割り当ておよび書き込みプロセスと同時に、かつ独立させて
実行される。
入可能であり、したがってキャッシュが動作しているときは、各プロセスのイン
スタンスを複数回にわたって作ることができる。たとえば、ガーベジ・コレクシ
ョン・プロセスは、割り当ておよび書き込みプロセスと同時に、かつ独立させて
実行される。
【０２２５】 （ハードウエア概要） 図１１は、本発明の実施例が実装されると考えられるコンピュータ・システム
１１００を示したブロック図である。コンピュータ・システム１１００は、バス
１１０２もしくはその他の、情報を伝達するためのメカニズム、およびバス１１
０２に接続された、情報を処理するためのプロセッサ１１０４を備える。またコ
ンピュータ・システム１１００においては、ランダム・アクセス・メモリ（ＲＡ
Ｍ）もしくはその他の動的ストレージ・デバイス等とするメイン・メモリ１１０
６がバス１１０２に接続されており、そこには情報およびプロセッサ１１０４に
よって実行されるインストラクションがストアされている。メイン・メモリ１１
０６は、プロセッサ１１０４によるインストラクションの実行間に、一時変数も
しくはその他の中間情報をストアするために使用されることもある。さらにコン
ピュータ・システム１１００には、情報およびプロセッサ１１０４用の命令をス
トアするための読み出し専用メモリ（ＲＯＭ）１１０８もしくはその他の静的ス
トレージ・デバイスが備わり、バス１１０２に接続されている。ストレージ・デ
バイス１１１０は、磁気ディスクまたは光ディスク等であり、情報および命令を
ストアするために備えられ、バス１１０２に接続されている。
１１００を示したブロック図である。コンピュータ・システム１１００は、バス
１１０２もしくはその他の、情報を伝達するためのメカニズム、およびバス１１
０２に接続された、情報を処理するためのプロセッサ１１０４を備える。またコ
ンピュータ・システム１１００においては、ランダム・アクセス・メモリ（ＲＡ
Ｍ）もしくはその他の動的ストレージ・デバイス等とするメイン・メモリ１１０
６がバス１１０２に接続されており、そこには情報およびプロセッサ１１０４に
よって実行されるインストラクションがストアされている。メイン・メモリ１１
０６は、プロセッサ１１０４によるインストラクションの実行間に、一時変数も
しくはその他の中間情報をストアするために使用されることもある。さらにコン
ピュータ・システム１１００には、情報およびプロセッサ１１０４用の命令をス
トアするための読み出し専用メモリ（ＲＯＭ）１１０８もしくはその他の静的ス
トレージ・デバイスが備わり、バス１１０２に接続されている。ストレージ・デ
バイス１１１０は、磁気ディスクまたは光ディスク等であり、情報および命令を
ストアするために備えられ、バス１１０２に接続されている。
【０２２６】 コンピュータ・システム１１００には、バス１１０２を介して
陰極線管（ＣＲＴ）等の、コンピュータのユーザに情報を表示するためのディス
プレイ１１１２が接続されることもある。英数字キーおよびその他のキーを含む
入力デバイス１１１４は、バス１１０２に接続されて、プロセッサ１１０４に情
報およびコマンドの選択を伝える。別のタイプのユーザ入力デバイスとして、マ
ウス、トラックボール、あるいはカーソル移動キーといったカーソル・コントロ
ール１１１６も備わっており、方向情報およびコマンドの選択をプロセッサ１１
０４に伝え、またディスプレイ１１１２上のカーソルの動きをコントロールする
ために使用される。この入力デバイスは、通常、第１の軸（たとえばｘ軸）およ
び第２の軸（たとえばｙ軸）を含む２軸に自由度を有し、それによりこのデバイ
スを用いた平面内のポジションの指定が可能になる。
陰極線管（ＣＲＴ）等の、コンピュータのユーザに情報を表示するためのディス
プレイ１１１２が接続されることもある。英数字キーおよびその他のキーを含む
入力デバイス１１１４は、バス１１０２に接続されて、プロセッサ１１０４に情
報およびコマンドの選択を伝える。別のタイプのユーザ入力デバイスとして、マ
ウス、トラックボール、あるいはカーソル移動キーといったカーソル・コントロ
ール１１１６も備わっており、方向情報およびコマンドの選択をプロセッサ１１
０４に伝え、またディスプレイ１１１２上のカーソルの動きをコントロールする
ために使用される。この入力デバイスは、通常、第１の軸（たとえばｘ軸）およ
び第２の軸（たとえばｙ軸）を含む２軸に自由度を有し、それによりこのデバイ
スを用いた平面内のポジションの指定が可能になる。
【０２２７】 本発明は、情報オブジェクトをキャッシュするためのコンピュ
ータ・システム１１００の使用に関する。本発明の一実施例によれば、情報オブ
ジェクトのキャッシが、メイン・メモリ１１０６内に収められている１ないしは
複数の命令からなる１ないしは複数のシーケンスを実行するプロセッサ１１０４
に応答してコンピュータ・システム１１００によって提供される。この種の命令
は、ストレージ・デバイス１１１０等の別のコンピュータ読み取り可能な媒体か
ら、メイン・メモリ１１０６内に読み込むことができる。メイン・メモリ１１０
６内に含まれる命令のシーケンスの実行によってプロセッサ１１０４は、ここに
説明したプロセスのステップを実行する。別の実施例においては、ソフトウエア
命令に代えて、あるいはそれとの組み合わせによりハードワイヤード回路が使用
され、本発明が実装されることもある。つまり、本発明の実施は、いかなる特定
のハードウエア回路およびソフトウエアの組み合わせにも限定されない。
ータ・システム１１００の使用に関する。本発明の一実施例によれば、情報オブ
ジェクトのキャッシが、メイン・メモリ１１０６内に収められている１ないしは
複数の命令からなる１ないしは複数のシーケンスを実行するプロセッサ１１０４
に応答してコンピュータ・システム１１００によって提供される。この種の命令
は、ストレージ・デバイス１１１０等の別のコンピュータ読み取り可能な媒体か
ら、メイン・メモリ１１０６内に読み込むことができる。メイン・メモリ１１０
６内に含まれる命令のシーケンスの実行によってプロセッサ１１０４は、ここに
説明したプロセスのステップを実行する。別の実施例においては、ソフトウエア
命令に代えて、あるいはそれとの組み合わせによりハードワイヤード回路が使用
され、本発明が実装されることもある。つまり、本発明の実施は、いかなる特定
のハードウエア回路およびソフトウエアの組み合わせにも限定されない。
【０２２８】 「コンピュータ読み取り可能な媒体」という用語は、ここで用
いる限り、実行のためのプロセッサ１１０４へのインストラクションの提供に関
与する任意の媒体を指す。この種の媒体は各種の形式をとることがあり、限定す
る意図ではないが、それには不揮発性媒体、揮発性媒体、伝送媒体が含まれる。
不揮発性媒体には、たとえば、ストレージ・デバイス１１１０等の光または磁気
ディスクが含まれる。揮発性媒体には、メイン・メモリ１１０６等の動的メモリ
が含まれる。伝送媒体には、同軸ケーブル、銅線ワイヤおよび光ファイバが含ま
れ、バス１１０２を構成するワイヤもこれに含まれる。また伝送媒体は、音波ま
たは光の形式をとることも可能であり、たとえば電波および赤外線データ通信の
間にそれが生成される。
いる限り、実行のためのプロセッサ１１０４へのインストラクションの提供に関
与する任意の媒体を指す。この種の媒体は各種の形式をとることがあり、限定す
る意図ではないが、それには不揮発性媒体、揮発性媒体、伝送媒体が含まれる。
不揮発性媒体には、たとえば、ストレージ・デバイス１１１０等の光または磁気
ディスクが含まれる。揮発性媒体には、メイン・メモリ１１０６等の動的メモリ
が含まれる。伝送媒体には、同軸ケーブル、銅線ワイヤおよび光ファイバが含ま
れ、バス１１０２を構成するワイヤもこれに含まれる。また伝送媒体は、音波ま
たは光の形式をとることも可能であり、たとえば電波および赤外線データ通信の
間にそれが生成される。
【０２２９】 コンピュータ読み取り可能な媒体の一般的な形としては、たと
えばフロッピーディスク、フレキシブル・ディスク、ハードディスク、磁気テー
プ、もしくはその他の磁気媒体、ＣＤ−ＲＯＭ、もしくはその他の光媒体、パン
チカード、紙テープ、もしくはその他の鑽孔パターンを伴う物理媒体、ＲＡＭ、
ＰＲＯＭ、およびＥＰＲＯＭ、フラッシュＥＰＲＯＭ、その他のメモリ・チップ
もしくはカートリッジ、後述する搬送波、またはコンピュータが読み取ることが
できるこのほかのあらゆる媒体が挙げられる。
えばフロッピーディスク、フレキシブル・ディスク、ハードディスク、磁気テー
プ、もしくはその他の磁気媒体、ＣＤ−ＲＯＭ、もしくはその他の光媒体、パン
チカード、紙テープ、もしくはその他の鑽孔パターンを伴う物理媒体、ＲＡＭ、
ＰＲＯＭ、およびＥＰＲＯＭ、フラッシュＥＰＲＯＭ、その他のメモリ・チップ
もしくはカートリッジ、後述する搬送波、またはコンピュータが読み取ることが
できるこのほかのあらゆる媒体が挙げられる。
【０２３０】 各種形式のコンピュータ読み取り可能な媒体が関連して、実行
のための１ないしは複数の命令からなる１ないしは複数のシーケンスをプロセッ
サ１１０４に運ぶことができる。たとえば、当初命令がリモート・コンピュータ
の磁気ディスク上に乗っているとする。リモート・コンピュータは、この命令を
その動的メモリにロードし、さらにモデムを使用してその命令を、電話回線を介
して送ることができる。コンピュータ・システム１１００の近傍にあるモデムは
、電話回線上でそのデータを受け取り、赤外線送信機を使用してそのデータを赤
外線信号に変換することができる。バス１１０２に接続された赤外線検出器は、
赤外線信号内に含まれて運ばれてきたデータを受信し、データをバス１１０２に
渡すことができる。バス１１０２は、データをメイン・メモリ１１０６まで運び
、そこからプロセッサ１１０４が命令を取り出して実行する。メイン・メモリ１
１０６によって受け取られたインストラクションは、選択肢の１つとして、プロ
セッサ１１０４による実行の前もしくはその後に、ストレージ・デバイス１１１
０にストアしてもよい。
のための１ないしは複数の命令からなる１ないしは複数のシーケンスをプロセッ
サ１１０４に運ぶことができる。たとえば、当初命令がリモート・コンピュータ
の磁気ディスク上に乗っているとする。リモート・コンピュータは、この命令を
その動的メモリにロードし、さらにモデムを使用してその命令を、電話回線を介
して送ることができる。コンピュータ・システム１１００の近傍にあるモデムは
、電話回線上でそのデータを受け取り、赤外線送信機を使用してそのデータを赤
外線信号に変換することができる。バス１１０２に接続された赤外線検出器は、
赤外線信号内に含まれて運ばれてきたデータを受信し、データをバス１１０２に
渡すことができる。バス１１０２は、データをメイン・メモリ１１０６まで運び
、そこからプロセッサ１１０４が命令を取り出して実行する。メイン・メモリ１
１０６によって受け取られたインストラクションは、選択肢の１つとして、プロ
セッサ１１０４による実行の前もしくはその後に、ストレージ・デバイス１１１
０にストアしてもよい。
【０２３１】 コンピュータ・システム１１００は、バス１１０２に接続され
た通信インターフェース１１１８を包含している。通信インターフェース１１１
８は、ローカル・ネットワーク１１２２に接続された通信リンク１１２０を結合
する双方向データ通信を提供する。たとえば通信インターフェース１１１８を統
合ディジタル通信サービス網（ＩＳＤＮ）カードまたはモデムとし、対応するタ
イプの電話回線に対するデータ通信接続を提供することが考えられる。別の例に
おいて、通信インターフェース１１１８をローカル・エリア・ネットワーク（Ｌ
ＡＮ）カードとして、互換性のあるＬＡＮに対するデータ通信接続を提供しても
よい。ワイヤレス・リンクの実装も考えられる。これらの実装のいずれにおいて
も、通信インターフェース１１１８は、各種タイプの情報を表すディジタル・デ
ータ・ストリームを搬送する電気的、電磁気的あるいは光学的信号を送受する。
た通信インターフェース１１１８を包含している。通信インターフェース１１１
８は、ローカル・ネットワーク１１２２に接続された通信リンク１１２０を結合
する双方向データ通信を提供する。たとえば通信インターフェース１１１８を統
合ディジタル通信サービス網（ＩＳＤＮ）カードまたはモデムとし、対応するタ
イプの電話回線に対するデータ通信接続を提供することが考えられる。別の例に
おいて、通信インターフェース１１１８をローカル・エリア・ネットワーク（Ｌ
ＡＮ）カードとして、互換性のあるＬＡＮに対するデータ通信接続を提供しても
よい。ワイヤレス・リンクの実装も考えられる。これらの実装のいずれにおいて
も、通信インターフェース１１１８は、各種タイプの情報を表すディジタル・デ
ータ・ストリームを搬送する電気的、電磁気的あるいは光学的信号を送受する。
【０２３２】 ネットワーク・リンク１１２０は、通常、１ないしは複数のネ
ットワークを介してほかのデータ・デバイスに対するデータ通信を提供する。た
とえばネットワーク・リンク１１２０が、ローカル・ネットワーク１１２２を介
してホスト・コンピュータ１１２４への接続、あるいはインターネット・サービ
ス・プロバイダ（ＩＳＰ）１１２６への接続の接続を提供することがある。一方
ＩＳＰ１１２６は、現在一般的に「インターネット」１１２８と呼ばれているワ
ールド・ワイドなパケット・データ通信を介したデータ通信サービスを提供する
。ローカル・ネットワーク１１２２およびインターネット１１２８は、いずれも
ディジタル・データ・ストリームを搬送する電気的、電磁気的、あるいは光学的
信号を使用する。コンピュータ・システム１１００へ、またそこからディジタル
・データを運ぶ、これらの各種ネットワークを介した信号およびネットワーク・
リンク１１２０上の信号ならびに通信インターフェース１１１８を介した信号は
、情報を伝達する搬送波の形式の例である。
ットワークを介してほかのデータ・デバイスに対するデータ通信を提供する。た
とえばネットワーク・リンク１１２０が、ローカル・ネットワーク１１２２を介
してホスト・コンピュータ１１２４への接続、あるいはインターネット・サービ
ス・プロバイダ（ＩＳＰ）１１２６への接続の接続を提供することがある。一方
ＩＳＰ１１２６は、現在一般的に「インターネット」１１２８と呼ばれているワ
ールド・ワイドなパケット・データ通信を介したデータ通信サービスを提供する
。ローカル・ネットワーク１１２２およびインターネット１１２８は、いずれも
ディジタル・データ・ストリームを搬送する電気的、電磁気的、あるいは光学的
信号を使用する。コンピュータ・システム１１００へ、またそこからディジタル
・データを運ぶ、これらの各種ネットワークを介した信号およびネットワーク・
リンク１１２０上の信号ならびに通信インターフェース１１１８を介した信号は
、情報を伝達する搬送波の形式の例である。
【０２３３】 コンピュータ・システム１１００は、プログラム・コードを含
めて、ネットワーク（１ないしは複数）、ネットワーク・リンク１１２０、およ
び通信インターフェース１１１８を介してメッセージを送りデータを受け取るこ
とができる。インターネットの例においては、サーバ１１３０が、要求されたア
プリケーション・プログラム用のコードをインターネット１１２８、ＩＳＰ １
１２６、ローカル・ネットワーク１１２２および通信インターフェース１１１８
を介して送信することが考えられる。本発明によれば、この種のダウンロードさ
れたアプリケーションの１つが、ここで説明している情報オブジェクトのキャッ
シュを提供する。
めて、ネットワーク（１ないしは複数）、ネットワーク・リンク１１２０、およ
び通信インターフェース１１１８を介してメッセージを送りデータを受け取るこ
とができる。インターネットの例においては、サーバ１１３０が、要求されたア
プリケーション・プログラム用のコードをインターネット１１２８、ＩＳＰ １
１２６、ローカル・ネットワーク１１２２および通信インターフェース１１１８
を介して送信することが考えられる。本発明によれば、この種のダウンロードさ
れたアプリケーションの１つが、ここで説明している情報オブジェクトのキャッ
シュを提供する。
【０２３４】 受信したコードは、プロセッサ１１０４によってその受信時に
実行されることもあれば、それとともに、あるいはそれに代えて、後の実行のた
めにストレージ・デバイス１１１０もしくは別の不揮発性ストレージにストアさ
れることもある。このようにして１１００は、搬送波の形式においてアプリケー
ション・コードを獲得することができる。
実行されることもあれば、それとともに、あるいはそれに代えて、後の実行のた
めにストレージ・デバイス１１１０もしくは別の不揮発性ストレージにストアさ
れることもある。このようにして１１００は、搬送波の形式においてアプリケー
ション・コードを獲得することができる。
【０２３５】 以上のとおり、従来のアプローチに対して明確な利点を有する
オブジェクト・キャッシュについて説明してきた。特にここでは、オブジェクト
のストア・オペレーションについて遅れ時間が小さく、高いスループットが得ら
れ、かつ多数の同時オペレーションが得られるという意味において高いパフォー
マンスを提供するオブジェクト・キャッシュについて説明している。ここに説明
されているメカニズムは、テラバイト台の情報、およびその成長レートに比例し
て増える数十億のオブジェクトをストアする大きなオブジェクト・キャッシュに
適用することができる。
オブジェクト・キャッシュについて説明してきた。特にここでは、オブジェクト
のストア・オペレーションについて遅れ時間が小さく、高いスループットが得ら
れ、かつ多数の同時オペレーションが得られるという意味において高いパフォー
マンスを提供するオブジェクト・キャッシュについて説明している。ここに説明
されているメカニズムは、テラバイト台の情報、およびその成長レートに比例し
て増える数十億のオブジェクトをストアする大きなオブジェクト・キャッシュに
適用することができる。
【０２３６】 このオブジェクト・キャッシュは、メモリのストレージ空間を
効率的に利用することから、高価な半導体メモリが有効にかつ効果的に使用され
る。またこのキャッシュは、ディスク・ストレージ空間の効率性をもたらし、そ
の結果、オブジェクト・ストアの有限なディスク容量内に多数のインターネット
・オブジェクトのレプリカをストアすることができる。このキャッシュはエイリ
アス・フリーであり、名前はそれぞれ異なるが同一のオブジェクト・コンテンツ
を有する複数のオブジェクトもしくはオブジェクトのバリアントは、オブジェク
トのコンテンツを１回だけキャッシュし、異なる名前の間においてそれを共有す
る。
効率的に利用することから、高価な半導体メモリが有効にかつ効果的に使用され
る。またこのキャッシュは、ディスク・ストレージ空間の効率性をもたらし、そ
の結果、オブジェクト・ストアの有限なディスク容量内に多数のインターネット
・オブジェクトのレプリカをストアすることができる。このキャッシュはエイリ
アス・フリーであり、名前はそれぞれ異なるが同一のオブジェクト・コンテンツ
を有する複数のオブジェクトもしくはオブジェクトのバリアントは、オブジェク
トのコンテンツを１回だけキャッシュし、異なる名前の間においてそれを共有す
る。
【０２３７】 ここに説明したキャッシュは、マルチメディアの多様性に関す
るサポートを有し、数百バイトからメガバイトに至る６桁にわたるサイズ範囲で
多数のタイプの多様なマルチメディア・オブジェクトを効率的にサポートする。
このキャッシュは、高速かつ用法を意識したガーベジ・コレクションを備え、有
用性の低いオブジェクトをオブジェクト・ストアから効率的に削除し、新しいオ
ブジェクトのためのスペースを確保する。またこのキャッシュは、データの一貫
性を特徴とし、プログラム上のエラーおよびハードウエアの障害によりデータの
信頼性を失うことがない。
るサポートを有し、数百バイトからメガバイトに至る６桁にわたるサイズ範囲で
多数のタイプの多様なマルチメディア・オブジェクトを効率的にサポートする。
このキャッシュは、高速かつ用法を意識したガーベジ・コレクションを備え、有
用性の低いオブジェクトをオブジェクト・ストアから効率的に削除し、新しいオ
ブジェクトのためのスペースを確保する。またこのキャッシュは、データの一貫
性を特徴とし、プログラム上のエラーおよびハードウエアの障害によりデータの
信頼性を失うことがない。
【０２３８】 このキャッシュは、高速リスタートが可能であり、時間を要す
るデータベースまたはファイル・システムのチェック・オペレーションを必要と
することなく、リスタート後数秒内にオブジェクト・キャッシュが要求に対する
サービスを開始することができる。キャッシュは、ストリーミングＩ／Ｏを使用
しているため、大きなオブジェクト全体をメモリ内にステージすることなく、オ
ブジェクト・ストアから遅いクライアントに、効率的にパイプラインさせること
ができる。このキャッシュはまた、コンテンツ・ネゴシエーションのサポートを
有し、プロキシ・キャッシュは、クライアントのブラウザ、言語、またはその他
のクライアントの要求の属性に向けられた、同一ＵＲＬを有するオブジェクトの
バリアントを効率的かつ柔軟にストアすることができる。このキャッシュは汎用
であり、オブジェクト・ストアのインターフェースは、将来的なメディア・タイ
プおよびプロトコルに適合できる充分な柔軟性を有している。
るデータベースまたはファイル・システムのチェック・オペレーションを必要と
することなく、リスタート後数秒内にオブジェクト・キャッシュが要求に対する
サービスを開始することができる。キャッシュは、ストリーミングＩ／Ｏを使用
しているため、大きなオブジェクト全体をメモリ内にステージすることなく、オ
ブジェクト・ストアから遅いクライアントに、効率的にパイプラインさせること
ができる。このキャッシュはまた、コンテンツ・ネゴシエーションのサポートを
有し、プロキシ・キャッシュは、クライアントのブラウザ、言語、またはその他
のクライアントの要求の属性に向けられた、同一ＵＲＬを有するオブジェクトの
バリアントを効率的かつ柔軟にストアすることができる。このキャッシュは汎用
であり、オブジェクト・ストアのインターフェースは、将来的なメディア・タイ
プおよびプロトコルに適合できる充分な柔軟性を有している。
【０２３９】 これらの利点ならびに特性は、この明細書における技術的説明
の特徴として考えるべきである；しかしながら、この種の利点ならびに特性が、
本発明の一部を構成する必要はなく、またそれがこの明細書に述べる特許請求の
範囲のいずれかによって求められる必要もない。
の特徴として考えるべきである；しかしながら、この種の利点ならびに特性が、
本発明の一部を構成する必要はなく、またそれがこの明細書に述べる特許請求の
範囲のいずれかによって求められる必要もない。
【０２４０】 以上、この明細書においては、具体的な実施例を参照し、かつ
特定の目的ならびに利点を参照して本発明を説明した。しかしながら、より広い
本発明の真意ならびに範囲から逸脱することなく、各種の変更がそれに加え得る
ことは明らかである。したがって、この明細書の説明および図面は、限定を意味
するものではなく例示のみを提供するものと考えるべきである。
特定の目的ならびに利点を参照して本発明を説明した。しかしながら、より広い
本発明の真意ならびに範囲から逸脱することなく、各種の変更がそれに加え得る
ことは明らかである。したがって、この明細書の説明および図面は、限定を意味
するものではなく例示のみを提供するものと考えるべきである。
【図面の簡単な説明】 以下、本発明を添付図面に示した例により説明するが、これに限定する意図は
なく、また図面においては、類似の要素に類似の参照番号を使用している。
なく、また図面においては、類似の要素に類似の参照番号を使用している。
【図１】 図１は、クライアント／サーバ関係を示すブロック図である。
【図２】 図２は、トラフィック・サーバのブロック図である。
【図３Ａ】 図３Ａは、オブジェクトをキーに変換するステップを示すブロッ
ク図である。
ク図である。
【図３Ｂ】 図３Ｂは、オブジェクト名をキーに変換するステップを示すブロ
ック図である。
ック図である。
【図４Ａ】 図４Ａは、キャッシュのブロック図である。
【図４Ｂ】 図４Ｂは、「選択肢のベクトル」のためのストレージ・メカニズ
ムを示すブロック図である。
ムを示すブロック図である。
【図４Ｃ】 図４Ｃは、マルチセグメント・ディレクトリ・テーブルのブロッ
ク図である。
ク図である。
【図５】 図５は、データ・フラグメントに関連するポインタのブロック図で
ある。
ある。
【図６】 図６は、ストレージ・デバイスおよびそのコンテンツを示すブロッ
ク図である。
ク図である。
【図７】 図７は、プールの構成を示すブロック図である。
【図８Ａ】 図８Ａは、ガーベジ・コレクションのプロセスを示すフローチャ
ートである。
ートである。
【図８Ｂ】 図８Ｂは、ストレージ・デバイスに情報を書き込むプロセスを示
すフローチャートである。
すフローチャートである。
【図８Ｃ】 図８Ｃは、同期化のプロセスを示すフローチャートである。
【図８Ｄ】 図８Ｄは、「checkout_read」プロセスを示すフローチャートで
ある。
ある。
【図８Ｅ】 図８Ｅは、「checkout_write」プロセスを示すフローチャートで
ある。
ある。
【図８Ｆ】 図８Ｆは、「checkout_create」プロセスを示すフローチャート
である。
である。
【図９Ａ】 図９Ａは、キャッシュのルックアップ・プロセスを示すフロー
チャートである。
チャートである。
【図９Ｂ】 図９Ｂは、「checkin」プロセスを示すフローチャートである
。
。
【図９Ｃ】 図９Ｃは、キャッシュのルックアップ・プロセスを示すフロー
チャートである。
チャートである。
【図９Ｄ】 図９Ｄは、キャッシュの削除プロセスを示すフローチャートで
ある。
ある。
【図９Ｅ】 図９Ｅは、キャッシュの読み出しプロセスを示すフローチャー
トである。
トである。
【図９Ｆ】 図９Ｆは、キャッシュの書き込みプロセスを示すフローチャー
トである。
トである。
【図９Ｇ】 図９Ｇは、キャッシュの更新プロセスを示すフローチャートで
ある。
ある。
【図１０Ａ】 図１０Ａは、ストレージ・デバイス内におけるオブジェクト
の書き込みおよび割り当てを行うプロセスを示すフローチャートである。
の書き込みおよび割り当てを行うプロセスを示すフローチャートである。
【図１０Ｂ】 図１０Ｂは、スケーリングされたカウンタ更新のプロセスを
示すフローチャートである。
示すフローチャートである。
【図１１】 図１１は、本発明のインプリメンテーションに使用できるコン
ピュータ・システムのブロック図である。
ピュータ・システムのブロック図である。
【図１２】 図１２は、オブジェクトの再更新のプロセスを示すフローチャ
ートである。
ートである。
【手続補正書】特許協力条約第３４条補正の翻訳文提出書
【提出日】平成１２年４月１８日（２０００．４．１８）
【手続補正１】
【補正対象書類名】明細書
【補正対象項目名】特許請求の範囲
【補正方法】変更
【補正内容】
【特許請求の範囲】
【手続補正２】
【補正対象書類名】明細書
【補正対象項目名】００２０
【補正方法】変更
【補正内容】
【００２０】 キャッシュ・オブジェクト・ストアの設計における上記のア
プローチに付随する基本的な問題は、問題の制約に関して解決策が最適化されな
いことである。これらのアプローチは、すべて、新しい応用に向けた、現存する
テクノロジの再応用に過ぎない。上記の応用の中に、マルチメディア、ストリー
ミング、オブジェクト・キャッシュに固有の制約に対して理想的に適合している
ものはない。上記の解決策は、不完全な再応用に起因して本質的にオブジェクト
・キャッシュを妨げるだけでなく、マルチメディア・オブジェクト・キャッシュ
における、より固有の要件の効率的なサポートを不可能にする。これらの固有の
要件には、同一であるが異なる名前を有する冗長なコンテンツを明確化し、かつ
共有する能力、またそれとは逆の、特定のクライアント、言語、データ型等に向
けられた、同一の名前を有するコンテンツの複数の変化型(variants)をストアす
る能力が含まれる。 EP-A-0811939から、分散型ネットワークにおいて、ドキュメントをプロキシし
、転送変換(transcoding)することが知られており、ここでは、クライアントの
要求に応じて、遠隔サーバから取得されたウェブ・ドキュメントは、この要求ド
キュメントに関連した格納情報を用いて転送変換される。ドキュメントは、種々
の目的、すなわちドキュメント内で見つかるバグや不適当な記述(quirks)を回避
する、テレビの画面にドキュメントを合わせる、転送効率を改善する、待ち時間
を削減する等のために転送変換される。
プローチに付随する基本的な問題は、問題の制約に関して解決策が最適化されな
いことである。これらのアプローチは、すべて、新しい応用に向けた、現存する
テクノロジの再応用に過ぎない。上記の応用の中に、マルチメディア、ストリー
ミング、オブジェクト・キャッシュに固有の制約に対して理想的に適合している
ものはない。上記の解決策は、不完全な再応用に起因して本質的にオブジェクト
・キャッシュを妨げるだけでなく、マルチメディア・オブジェクト・キャッシュ
における、より固有の要件の効率的なサポートを不可能にする。これらの固有の
要件には、同一であるが異なる名前を有する冗長なコンテンツを明確化し、かつ
共有する能力、またそれとは逆の、特定のクライアント、言語、データ型等に向
けられた、同一の名前を有するコンテンツの複数の変化型(variants)をストアす
る能力が含まれる。 EP-A-0811939から、分散型ネットワークにおいて、ドキュメントをプロキシし
、転送変換(transcoding)することが知られており、ここでは、クライアントの
要求に応じて、遠隔サーバから取得されたウェブ・ドキュメントは、この要求ド
キュメントに関連した格納情報を用いて転送変換される。ドキュメントは、種々
の目的、すなわちドキュメント内で見つかるバグや不適当な記述(quirks)を回避
する、テレビの画面にドキュメントを合わせる、転送効率を改善する、待ち時間
を削減する等のために転送変換される。
【手続補正３】
【補正対象書類名】明細書
【補正対象項目名】０２４０
【補正方法】変更
【補正内容】
【０２４０】 以上、この明細書においては、具体的な実施例を参照し、かつ
特定の目的ならびに利点を参照して本発明を説明した。しかしながら、本発明か
ら逸脱することなく、各種の変更がそれに加え得ることは明らかである。したが
って、この明細書の説明および図面は、限定を意味するものではなく例示のみを
提供するものと考えるべきである。
特定の目的ならびに利点を参照して本発明を説明した。しかしながら、本発明か
ら逸脱することなく、各種の変更がそれに加え得ることは明らかである。したが
って、この明細書の説明および図面は、限定を意味するものではなく例示のみを
提供するものと考えるべきである。
【手続補正４】
【補正対象書類名】図面
【補正対象項目名】図４Ｃ
【補正方法】追加
【補正内容】
【図４Ｃ】
【手続補正書】
【提出日】平成１２年１０月２７日（２０００．１０．２７）
【手続補正１】
【補正対象書類名】明細書
【補正対象項目名】請求項２４
【補正方法】変更
【補正内容】
───────────────────────────────────────────────────── フロントページの続き (81)指定国 ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＣＹ， ＤＥ，ＤＫ，ＥＳ，ＦＩ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，Ｉ Ｔ，ＬＵ，ＭＣ，ＮＬ，ＰＴ，ＳＥ)，ＯＡ(ＢＦ，ＢＪ ，ＣＦ，ＣＧ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＧＷ，ＭＬ， ＭＲ，ＮＥ，ＳＮ，ＴＤ，ＴＧ)，ＡＰ(ＧＨ，ＧＭ，Ｋ Ｅ，ＬＳ，ＭＷ，ＳＤ，ＳＬ，ＳＺ，ＵＧ，ＺＷ)，Ｅ Ａ(ＡＭ，ＡＺ，ＢＹ，ＫＧ，ＫＺ，ＭＤ，ＲＵ，ＴＪ ，ＴＭ)，ＡＥ，ＡＬ，ＡＭ，ＡＴ，ＡＵ，ＡＺ，ＢＡ ，ＢＢ，ＢＧ，ＢＲ，ＢＹ，ＣＡ，ＣＨ，ＣＮ，ＣＺ， ＤＥ，ＤＫ，ＥＥ，ＥＳ，ＦＩ，ＧＢ，ＧＤ，ＧＥ，Ｇ Ｈ，ＧＭ，ＨＲ，ＨＵ，ＩＤ，ＩＬ，ＩＮ，ＩＳ，ＪＰ ，ＫＥ，ＫＧ，ＫＲ，ＫＺ，ＬＣ，ＬＫ，ＬＲ，ＬＳ， ＬＴ，ＬＵ，ＬＶ，ＭＤ，ＭＧ，ＭＫ，ＭＮ，ＭＷ，Ｍ Ｘ，ＮＯ，ＮＺ，ＰＬ，ＰＴ，ＲＯ，ＲＵ，ＳＤ，ＳＥ ，ＳＧ，ＳＩ，ＳＫ，ＳＬ，ＴＪ，ＴＭ，ＴＲ，ＴＴ， ＵＡ，ＵＧ，ＵＺ，ＶＮ，ＹＵ，ＺＡ，ＺＷ (72)発明者 ジョン・プレヴヤック アメリカ合衆国 カリフォルニア州 94117 サンフランシスコ ベーカースト リート 126 (72)発明者 マシュー・ヘインズ アメリカ合衆国 ワイオミング州 82070 ララミー コートヘルロード 35 (72)発明者 アダム・ベグエリン アメリカ合衆国 カリフォルニア州 94403 サンマテオ ホーランドストリー ト 2821 (72)発明者 ブライアン・トゥーティ アメリカ合衆国 カリフォルニア州 94404 フォスターシティ ナンバー３ カタマラン 715 (72)発明者 デビッド・ゴーレイ アメリカ合衆国 カリフォルニア州 94303 パロアルト ナンバー211 ミッド タウンコート 2721 Ｆターム(参考） 5B075 KK07 KK33 KK39 MM01 MM11 MM23 MM61 ND16 NK02 NK43 PP03 PQ02 UU40 5B082 EA01 FA12 GA05 HA05 【要約の続き】 ションは、アクティブでないオブジェクトが削除され、 またフリー・スペースが連続的になるように、１つのア リーナ内又は他のアリーナに渡って、周期的にオブジェ クトを移動する。オブジェクトは、ほぼ連続的に配置さ れるので、一般的なオブジェクトの読み出し及び書き込 みには、１か２のディスクヘッド・アクチュエータの移 動で足り、したがって、キャッシュは、効率的且つ円滑 にストレージ・デバイスからデータを流し、マルチメデ ィア・オブジェクトの最適な配信を達成する。開示はま た、コンピュータ装置、コンピュータプログラム製品、 及び搬送波に具現されたコンピュータ・データ信号を包 含する。
Claims (23)
- 【請求項１】 その名前に基づくキー値によって識別される情報オブジェク
トのためのキャッシュにおいて、前記キー値に基づくセット・サブキー値を用い
て前記情報オブジェクトをインデクス付けするタグ・テーブル、前記キー値に基
づく第２のサブキー値によって前記タグ・テーブル内のセットにインデクス付け
された複数のブロックを備えたディレクトリ・テーブル、及び前記ディレクトリ
・テーブル内の前記ブロックによって参照されるデータ・ストレージ・エリアを
備え、要求された情報オブジェクトをサーバの前記キャッシュからクライアント
へ配信する方法において、 （Ａ）要求された情報オブジェクトを識別する名前を受け取るステップと、 （Ｂ）前記名前に基づいて、複数のサブキーを備えた固定サイズのキー値を計
算するステップと、 （Ｃ）前記サブキーをルックアップキーとして用いて、ディレクトリ・テーブ
ル内の前記要求された情報オブジェクトをルックアップするステップと、 （Ｄ）前記ディレクトリ・テーブル内の一致したブロックに含まれる参照を用
いて、前記データ・ストレージ・エリアから前記要求された情報オブジェクトの
コピーを取り出すステップと、 を備えた方法。 - 【請求項２】 請求項１に記載の方法において、更に、 前記要求された情報オブジェクトの複数のバージョンの前記キャッシュ内のリ
ストから、前記要求された情報オブジェクトのバージョンを選択するステップと
、 最初のバージョンに関連付けられて前記リストにストアされたオブジェクトキ
ーに基づいて、前記キャッシュ内の前記要求された情報オブジェクトの格納場所
を特定するステップと、 前記格納場所から前記要求された情報オブジェクトを取り出すステップと、 前記要求された情報オブジェクトを前記クライアントへ配信するステップと、 を備えた方法。 - 【請求項３】 請求項１に記載の方法において、更に、前記情報オブジェク
トを、大容量ストレージ・デバイスに連続的にストアするステップを備えた方法
。 - 【請求項４】 請求項３に記載の方法において、更に、前記各情報オブジェ
クトを、前記大容量ストレージ・デバイスの連続したプールにストアするステッ
プを備えた方法。 - 【請求項５】 請求項４に記載の方法において、更に、前記各情報オブジェ
クトを、前記連続したプールにおける複数のアリーナの１つにストアするステッ
プを備えた方法。 - 【請求項６】 請求項５に記載の方法において、更に、前記各情報オブジェ
クトを、前記複数のアリーナから割り当てられた１又は複数のフラグメントにス
トアするステップを備えた方法。 - 【請求項７】 情報オブジェクトを備えた前記フラグメントが、前のフラグ
メントキーからリンクされている請求項６に記載の方法。 - 【請求項８】 請求項２に記載の方法において、更に、 前記要求された情報オブジェクトの前記複数のバージョンのそれぞれに連続し
て前記リストをストアするステップと、 前記各ブロックにおいて、前記要求された情報オブジェクトのサイズ値をその
ブロックに関連付けてストアするステップであって、前記サイズ値が前記リスト
及び前記情報オブジェクトの前記複数のバージョンの格納サイズを示すものと、 を備え、ステップ（Ｄ）において、前記リスト及び前記複数のバージョンを同
時に読み出すステップを備えた方法。 - 【請求項９】 請求項５に記載の方法において、更に、書き込み集成バッフ
ァに異なる速度のストリーミング・データ転送を統合するステップを備えた方法
。 - 【請求項１０】 請求項３に記載の方法において、前記情報オブジェクトを
ストアするステップは、別の情報オブジェクトに関してステップ（Ａ）〜（Ｄ）
を実行するのと並行して、前記情報オブジェクトを、前記大容量ストレージ・デ
バイスの連続した使用可能なストレージ空間内に書き込むステップを備えた方法
。 - 【請求項１１】 コンピュータメモリにストアされた複数のカウンタを管理
する方法において、 前記複数のカウンタのそれぞれにストアされた値の合計を計算するステップと
、 前記複数のカウンタにより表すことができる最大値を計算するステップと、 前記合計が前記最大値の半分を超えたときに、前記各カウンタをデクリメント
するステップと、 を備えた方法。 - 【請求項１２】 請求項１１に記載の方法において、更に、 キャッシュにストアされた複数の情報オブジェクトの１つについての記述に関
連付けて、前記複数のカウンタのそれぞれをストアするステップと、 前記カウンタがゼロにデクリメントされたときに、前記カウンタの１つに関連
付けられた前記情報オブジェクトの１つを削除するステップと、 を備えた方法。 - 【請求項１３】 請求項１に記載の方法において、ステップ（Ｂ）及び（Ｃ
）が、サブキー・パーティション及びテーブル組織を使用し、それによって低速
メモリを使用して高速キャッシュ・ミス判断を実現する方法。 - 【請求項１４】 情報オブジェクトをキャッシングするための１又は複数の
命令シーケンスを備えたコンピュータ読み取り可能な媒体であって、１又は複数
のプロセッサによる前記１又は複数の命令シーケンスの実行が、前記１又は複数
のプロセッサに、 その名前に基づくキー値によって識別される情報オブジェクトのためのキャッ
シュであって、前記キー値に基づくセット・サブキー値を用いて前記情報オブジ
ェクトをインデクス付けするタグ・テーブル、前記キー値に基づく第２のサブキ
ー値によって前記タグ・テーブル内のセットにインデクス付けされた複数のブロ
ックを備えたディレクトリ・テーブル、及び前記ディレクトリ・テーブル内の前
記ブロックによって参照されるデータ・ストレージ・エリアを備えたキャッシュ
を確立するステップと、 要求された情報オブジェクトをサーバの前記キャッシュからクライアントへ、
下記（Ａ）〜（Ｄ）により配信するステップと、 を生じさせる媒体。 （Ａ）要求された情報オブジェクトを識別する名前を受け取り、 （Ｂ）前記名前に基づいて、複数のサブキーを備えた固定サイズのキー値を計
算し、 （Ｃ）前記サブキーをルックアップキーとして用いて、ディレクトリ・テーブ
ル内の前記要求された情報オブジェクトをルックアップし、 （Ｄ）前記ディレクトリ・テーブル内の一致ブロックに含まれる参照を用いて
、前記データ・ストレージ・エリアから前記要求された情報オブジェクトのコピ
ーを取り出す。 - 【請求項１５】 請求項１４に記載のコンピュータ読み取り可能な媒体にお
いて、更に、 前記要求された情報オブジェクトの複数のバージョンの前記キャッシュ内のリ
ストから、前記要求された情報オブジェクトのバージョンを選択するステップと
、 最初のバージョンに関連付けられて前記リストに格納されたオブジェクトキー
に基づいて、前記キャッシュ内の前記要求された情報オブジェクトの格納場所を
特定するステップと、 前記格納場所から前記要求された情報オブジェクトを取り出すステップと、 前記要求された情報オブジェクトを前記クライアントへ配信するステップと、 を備えた媒体。 - 【請求項１６】 請求項１４に記載のコンピュータ読み取り可能な媒体にお
いて、更に、前記情報オブジェクトを、大容量ストレージ・デバイスに連続的に
ストアするステップを備えた媒体。 - 【請求項１７】 請求項１６に記載のコンピュータ読み取り可能な媒体にお
いて、更に、前記各情報オブジェクトを、前記大容量ストレージ・デバイスの連
続したプールにストアするステップを備えた媒体。 - 【請求項１８】 請求項１７に記載のコンピュータ読み取り可能な媒体にお
いて、更に、前記各情報オブジェクトを、前記連続したプールにおける複数のア
リーナの１つにストアするステップを備えた媒体。 - 【請求項１９】 請求項１８に記載のコンピュータ読み取り可能な媒体にお
いて、更に、前記各情報オブジェクトを、前記複数のアリーナから割り当てられ
た１又は複数のフラグメントにストアするステップを備えた媒体。 - 【請求項２０】 情報オブジェクトを備えた前記フラグメントが、前のフラ
グメントキーからリンクされている請求項１９に記載のコンピュータ読み取り可
能な媒体。 - 【請求項２１】 請求項１５に記載のコンピュータ読み取り可能な媒体にお
いて、更に、 前記要求された情報オブジェクトの前記複数のバージョンのそれぞれに連続し
て前記リストをストアするステップと、 前記各ブロックにおいて、前記要求された情報オブジェクトのサイズ値をその
ブロックに関連付けてストアするステップであって、前記サイズ値が前記リスト
及び前記情報オブジェクトの前記複数のバージョンの格納サイズを示すものと、 を備え、ステップ（Ｄ）において、前記リスト及び前記複数のバージョンを同
時に読み出すステップを備えた媒体。 - 【請求項２２】 請求項１８に記載のコンピュータ読み取り可能な媒体にお
いて、更に、書き込み集成バッファに異なる速度のストリーミング・データ転送
を統合するステップを備えた媒体。 - 【請求項２３】 請求項１６に記載のコンピュータ読み取り可能な媒体にお
いて、前記情報オブジェクトをストアするステップは、別の情報オブジェクトに
関してステップ（Ａ）〜（Ｄ）を実行するのと並行して、前記情報オブジェクト
を、前記大容量ストレージ・デバイスの連続した使用可能なストレージ空間内に
書き込むステップを備えた媒体。
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US09/060,866 | 1998-04-15 | ||
| US09/060,866 US6128623A (en) | 1998-04-15 | 1998-04-15 | High performance object cache |
| PCT/US1999/008281 WO1999053422A1 (en) | 1998-04-15 | 1999-04-15 | High performance object cache |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2002511616A true JP2002511616A (ja) | 2002-04-16 |
| JP4489292B2 JP4489292B2 (ja) | 2010-06-23 |
Family
ID=22032231
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2000543914A Expired - Lifetime JP4489292B2 (ja) | 1998-04-15 | 1999-04-15 | 高性能オブジェクト・キャッシュ |
Country Status (6)
| Country | Link |
|---|---|
| US (2) | US6128623A (ja) |
| EP (1) | EP1072004B1 (ja) |
| JP (1) | JP4489292B2 (ja) |
| AU (1) | AU754816B2 (ja) |
| DE (1) | DE69915462T2 (ja) |
| WO (1) | WO1999053422A1 (ja) |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US10419534B2 (en) | 2016-02-29 | 2019-09-17 | Fujitsu Limited | Relay method and relay apparatus |
| JP2021531562A (ja) * | 2018-07-24 | 2021-11-18 | インターナショナル・ビジネス・マシーンズ・コーポレーションInternational Business Machines Corporation | 大規模エンティティ解決のための２段階計算メモイング |
Families Citing this family (364)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6031995A (en) * | 1996-11-06 | 2000-02-29 | George; A. Chacko | Object-oriented sequencing using hierarchical configuration streams |
| US6760746B1 (en) | 1999-09-01 | 2004-07-06 | Eric Schneider | Method, product, and apparatus for processing a data request |
| US6915307B1 (en) * | 1998-04-15 | 2005-07-05 | Inktomi Corporation | High performance object cache |
| US6128623A (en) * | 1998-04-15 | 2000-10-03 | Inktomi Corporation | High performance object cache |
| US6289358B1 (en) * | 1998-04-15 | 2001-09-11 | Inktomi Corporation | Delivering alternate versions of objects from an object cache |
| US6389460B1 (en) * | 1998-05-13 | 2002-05-14 | Compaq Computer Corporation | Method and apparatus for efficient storage and retrieval of objects in and from an object storage device |
| US6591305B2 (en) * | 1998-06-30 | 2003-07-08 | Sun Microsystems, Inc. | Method and system for delivering data from a server object to a client object using a non-proprietary data transfer protocol |
| US6308214B1 (en) * | 1998-09-23 | 2001-10-23 | Inktomi Corporation | Self-tuning dataflow I/O core |
| US6957436B1 (en) * | 1999-01-29 | 2005-10-18 | Iona Technologies, Plc | Method and system for multi-threaded object loading and unloading |
| US6907609B1 (en) * | 1999-02-01 | 2005-06-14 | Iona Technologies Plc. | Object request dispatch using matching of a segmented object key |
| US6453321B1 (en) * | 1999-02-11 | 2002-09-17 | Ibm Corporation | Structured cache for persistent objects |
| US9141717B2 (en) | 1999-03-22 | 2015-09-22 | Esdr Network Solutions Llc | Methods, systems, products, and devices for processing DNS friendly identifiers |
| US6338082B1 (en) | 1999-03-22 | 2002-01-08 | Eric Schneider | Method, product, and apparatus for requesting a network resource |
| USRE43690E1 (en) | 1999-03-22 | 2012-09-25 | Esdr Network Solutions Llc | Search engine request method, product, and apparatus |
| US7188138B1 (en) | 1999-03-22 | 2007-03-06 | Eric Schneider | Method, product, and apparatus for resource identifier registration and aftermarket services |
| US8037168B2 (en) | 1999-07-15 | 2011-10-11 | Esdr Network Solutions Llc | Method, product, and apparatus for enhancing resolution services, registration services, and search services |
| US6701415B1 (en) * | 1999-03-31 | 2004-03-02 | America Online, Inc. | Selecting a cache for a request for information |
| US6542967B1 (en) * | 1999-04-12 | 2003-04-01 | Novell, Inc. | Cache object store |
| US6240313B1 (en) * | 1999-04-19 | 2001-05-29 | Cardiac Pacemakers, Inc. | Cardiac rhythm management system with prevention of double counting of events |
| US7313581B1 (en) * | 1999-04-29 | 2007-12-25 | International Business Machines Corporation | Method for deferred deletion of entries for a directory service backing store |
| US6745368B1 (en) | 1999-06-11 | 2004-06-01 | Liberate Technologies | Methods, apparatus, and systems for storing, retrieving and playing multimedia data |
| US6973505B1 (en) * | 1999-09-01 | 2005-12-06 | Eric Schneider | Network resource access method, product, and apparatus |
| USRE44207E1 (en) | 1999-09-01 | 2013-05-07 | Esdr Network Solutions Llc | Network resource access method, product, and apparatus |
| US6721780B1 (en) * | 1999-11-09 | 2004-04-13 | Fireclick, Inc. | Predictive pre-download of network objects |
| US6553461B1 (en) * | 1999-12-10 | 2003-04-22 | Sun Microsystems, Inc. | Client controlled pre-fetching of resources |
| US7243136B2 (en) * | 2000-01-18 | 2007-07-10 | Inktomi Corporation | Approach for managing and providing content to users |
| US6820133B1 (en) * | 2000-02-07 | 2004-11-16 | Netli, Inc. | System and method for high-performance delivery of web content using high-performance communications protocol between the first and second specialized intermediate nodes to optimize a measure of communications performance between the source and the destination |
| JP2001243079A (ja) * | 2000-03-02 | 2001-09-07 | Omron Corp | 情報処理システム |
| US7043641B1 (en) | 2000-03-08 | 2006-05-09 | Igt | Encryption in a secure computerized gaming system |
| US7988559B2 (en) | 2001-03-08 | 2011-08-02 | Igt | Computerized gaming system, method and apparatus |
| US6711595B1 (en) * | 2000-05-09 | 2004-03-23 | Openwave Systems Inc. | Method and apparatus for sharing standard template library objects among processes |
| US7013340B1 (en) | 2000-05-18 | 2006-03-14 | Microsoft Corporation | Postback input handling by server-side control objects |
| US6876997B1 (en) * | 2000-05-22 | 2005-04-05 | Overture Services, Inc. | Method and apparatus for indentifying related searches in a database search system |
| WO2001093106A2 (en) * | 2000-05-26 | 2001-12-06 | Infolibria, Inc. | High performance efficient subsystem for data object storage |
| US7673229B1 (en) | 2000-06-07 | 2010-03-02 | Ebay Inc. | Apparatus and method for generating sub-codes to a turbo-encoder |
| WO2001095331A2 (en) * | 2000-06-09 | 2001-12-13 | Koninklijke Philips Electronics N.V. | Method of implicit partitioning the storage space available on a storage medium |
| US7951002B1 (en) | 2000-06-16 | 2011-05-31 | Igt | Using a gaming machine as a server |
| JP2002002140A (ja) * | 2000-06-22 | 2002-01-08 | Riso Kagaku Corp | 微多孔性孔版原紙およびその利用 |
| US6941351B2 (en) | 2000-07-11 | 2005-09-06 | Microsoft Corporation | Application program caching |
| US7603407B2 (en) * | 2000-08-17 | 2009-10-13 | Sun Microsystems, Inc. | Method and system for registering binary data |
| US6694338B1 (en) * | 2000-08-29 | 2004-02-17 | Contivo, Inc. | Virtual aggregate fields |
| US20020059440A1 (en) * | 2000-09-06 | 2002-05-16 | Hudson Michael D. | Client-side last-element cache network architecture |
| US20020059499A1 (en) * | 2000-09-06 | 2002-05-16 | Hudson Michael D. | System and methods for performing last-element streaming |
| US6928466B1 (en) * | 2000-09-28 | 2005-08-09 | Emc Corporation | Method and system for identifying memory component identifiers associated with data |
| US6625591B1 (en) * | 2000-09-29 | 2003-09-23 | Emc Corporation | Very efficient in-memory representation of large file system directories |
| US6804763B1 (en) | 2000-10-17 | 2004-10-12 | Igt | High performance battery backed ram interface |
| US7111141B2 (en) * | 2000-10-17 | 2006-09-19 | Igt | Dynamic NV-RAM |
| US20020087798A1 (en) * | 2000-11-15 | 2002-07-04 | Vijayakumar Perincherry | System and method for adaptive data caching |
| US6721739B1 (en) | 2000-12-05 | 2004-04-13 | Silicon Graphics, Inc. | System and method for maintaining and recovering data consistency across multiple pages |
| US6751636B1 (en) * | 2000-12-05 | 2004-06-15 | Silicon Graphics, Inc. | System and method for maintaining and recovering data consistency across multiple instances of a database |
| US6993523B1 (en) | 2000-12-05 | 2006-01-31 | Silicon Graphics, Inc. | System and method for maintaining and recovering data consistency in a data base page |
| US8550922B2 (en) * | 2006-03-03 | 2013-10-08 | Igt | Game removal with game history |
| US7168089B2 (en) * | 2000-12-07 | 2007-01-23 | Igt | Secured virtual network in a gaming environment |
| US20070136817A1 (en) * | 2000-12-07 | 2007-06-14 | Igt | Wager game license management in a peer gaming network |
| US7515718B2 (en) * | 2000-12-07 | 2009-04-07 | Igt | Secured virtual network in a gaming environment |
| US7127069B2 (en) * | 2000-12-07 | 2006-10-24 | Igt | Secured virtual network in a gaming environment |
| US7972214B2 (en) | 2000-12-07 | 2011-07-05 | Igt | Methods and devices for downloading games of chance |
| US7730213B2 (en) * | 2000-12-18 | 2010-06-01 | Oracle America, Inc. | Object-based storage device with improved reliability and fast crash recovery |
| US6745285B2 (en) * | 2000-12-18 | 2004-06-01 | Sun Microsystems, Inc. | System and method for synchronizing mirrored and striped disk writes |
| US6931450B2 (en) | 2000-12-18 | 2005-08-16 | Sun Microsystems, Inc. | Direct access from client to storage device |
| US6990493B1 (en) * | 2000-12-22 | 2006-01-24 | Emc Corporation | File access system |
| US7269784B1 (en) * | 2001-01-22 | 2007-09-11 | Kasriel Stephane | Server-originated differential caching |
| US7921033B2 (en) * | 2001-01-29 | 2011-04-05 | Microsoft Corporation | System and method for high-density interactive voting using a computer network |
| US6721850B2 (en) | 2001-02-27 | 2004-04-13 | Lucent Technologies Inc. | Method of cache replacement for streaming media |
| EP1400053A2 (en) * | 2001-02-27 | 2004-03-24 | Visa International Service Association | Distributed quantum encrypted pattern generation and scoring |
| US7380250B2 (en) | 2001-03-16 | 2008-05-27 | Microsoft Corporation | Method and system for interacting with devices having different capabilities |
| US6754799B2 (en) * | 2001-05-16 | 2004-06-22 | Microsoft Corporation | System and method for indexing and retrieving cached objects |
| US7269608B2 (en) * | 2001-05-30 | 2007-09-11 | Sun Microsystems, Inc. | Apparatus and methods for caching objects using main memory and persistent memory |
| US20020184612A1 (en) * | 2001-06-01 | 2002-12-05 | Hunt Joseph R. | Runtime configurable caching for component factories |
| US7493397B1 (en) | 2001-06-06 | 2009-02-17 | Microsoft Corporation | Providing remote processing services over a distributed communications network |
| US6915454B1 (en) | 2001-06-12 | 2005-07-05 | Microsoft Corporation | Web controls validation |
| WO2002102484A1 (en) | 2001-06-15 | 2002-12-27 | Walker Digital, Llc | Method and apparatus for planning and customizing a gaming experience |
| US7185063B1 (en) * | 2001-06-22 | 2007-02-27 | Digital River, Inc. | Content delivery network using differential caching |
| US6877066B2 (en) * | 2001-06-29 | 2005-04-05 | International Business Machines Corporation | Method and system for adaptive caching in a network management framework using skeleton caches |
| US6854033B2 (en) * | 2001-06-29 | 2005-02-08 | Intel Corporation | Using linked list for caches with variable length data |
| US6880154B2 (en) * | 2001-06-29 | 2005-04-12 | Intel Corporation | Alias-free test for dynamic array structures |
| US8019789B2 (en) * | 2001-07-03 | 2011-09-13 | Research In Motion Limited | System and method of object-oriented persistence |
| US7594001B1 (en) * | 2001-07-06 | 2009-09-22 | Microsoft Corporation | Partial page output caching |
| US7761497B1 (en) * | 2001-07-13 | 2010-07-20 | Vignette Software, LLC | Storage medium having a manageable file directory structure |
| US6714934B1 (en) | 2001-07-31 | 2004-03-30 | Logika Corporation | Method and system for creating vertical search engines |
| US7092997B1 (en) | 2001-08-06 | 2006-08-15 | Digital River, Inc. | Template identification with differential caching |
| US7162036B2 (en) * | 2001-08-06 | 2007-01-09 | Igt | Digital identification of unique game characteristics |
| US7188214B1 (en) | 2001-08-07 | 2007-03-06 | Digital River, Inc. | Efficient compression using differential caching |
| US6685567B2 (en) | 2001-08-08 | 2004-02-03 | Igt | Process verification |
| US7428548B2 (en) | 2001-08-15 | 2008-09-23 | Bentley Systems, Inc. | Computer readable medium for storing large data files |
| EP1417800B1 (en) * | 2001-08-15 | 2017-10-04 | Bentley Systems, Incorporated | Method and system for storing large data files |
| US6890259B2 (en) | 2001-09-10 | 2005-05-10 | Igt | Modular tilt handling system |
| US7931533B2 (en) | 2001-09-28 | 2011-04-26 | Igt | Game development architecture that decouples the game logic from the graphics logics |
| US6902481B2 (en) * | 2001-09-28 | 2005-06-07 | Igt | Decoupling of the graphical presentation of a game from the presentation logic |
| US8708828B2 (en) | 2001-09-28 | 2014-04-29 | Igt | Pluggable modular gaming modifiers and configuration templates for gaming environments |
| US7269663B2 (en) * | 2001-09-28 | 2007-09-11 | Intel Corporation | Tagging packets with a lookup key to facilitate usage of a unified packet forwarding cache |
| TW512268B (en) * | 2001-11-05 | 2002-12-01 | Ind Tech Res Inst | Single-layered consistent data cache dynamic accessing method and system |
| US6829679B2 (en) * | 2001-11-09 | 2004-12-07 | International Business Machines Corporation | Different caching treatment of memory contents based on memory region |
| US6754800B2 (en) * | 2001-11-14 | 2004-06-22 | Sun Microsystems, Inc. | Methods and apparatus for implementing host-based object storage schemes |
| US7428725B2 (en) | 2001-11-20 | 2008-09-23 | Microsoft Corporation | Inserting devices specific content |
| IL162420A0 (en) * | 2001-12-11 | 2005-11-20 | C2Cure Inc | Apparatus, method and system for intravascular ph otographic imaging |
| US20030115421A1 (en) * | 2001-12-13 | 2003-06-19 | Mchenry Stephen T. | Centralized bounded domain caching control system for network edge servers |
| US7565402B2 (en) | 2002-01-05 | 2009-07-21 | Eric Schneider | Sitemap access method, product, and apparatus |
| US7316616B2 (en) * | 2002-01-16 | 2008-01-08 | Igt | Gaming system license management |
| US9167036B2 (en) | 2002-02-14 | 2015-10-20 | Level 3 Communications, Llc | Managed object replication and delivery |
| US7296051B1 (en) | 2002-02-19 | 2007-11-13 | Digital River, Inc. | Predictive predownload of templates with delta encoding |
| US7487261B1 (en) | 2002-02-22 | 2009-02-03 | Digital River, Inc. | Delta caching service |
| US8360838B2 (en) * | 2006-07-03 | 2013-01-29 | Igt | Detecting and preventing bots and cheating in online gaming |
| US8597116B2 (en) | 2002-03-12 | 2013-12-03 | Igt | Virtual player tracking and related services |
| US6997803B2 (en) * | 2002-03-12 | 2006-02-14 | Igt | Virtual gaming peripherals for a gaming machine |
| US7707287B2 (en) * | 2002-03-22 | 2010-04-27 | F5 Networks, Inc. | Virtual host acceleration system |
| US7680875B1 (en) | 2002-04-01 | 2010-03-16 | Novell, Inc. | Markers for cached objects |
| US6950838B2 (en) * | 2002-04-17 | 2005-09-27 | Sun Microsystems, Inc. | Locating references and roots for in-cache garbage collection |
| AU2003231305B2 (en) * | 2002-05-02 | 2009-01-08 | Intel Corporation | System and method for transformation of XML documents using stylesheets |
| US7676579B2 (en) * | 2002-05-13 | 2010-03-09 | Sony Computer Entertainment America Inc. | Peer to peer network communication |
| US7243141B2 (en) * | 2002-05-13 | 2007-07-10 | Sony Computer Entertainment America, Inc. | Network configuration evaluation |
| TWI240179B (en) * | 2002-06-06 | 2005-09-21 | Taiwan Semiconductor Mfg | Parsing method for recipe data |
| US7918730B2 (en) | 2002-06-27 | 2011-04-05 | Igt | Trajectory-based 3-D games of chance for video gaming machines |
| US8224985B2 (en) | 2005-10-04 | 2012-07-17 | Sony Computer Entertainment Inc. | Peer-to-peer communication traversing symmetric network address translators |
| US8060626B2 (en) | 2008-09-22 | 2011-11-15 | Sony Computer Entertainment America Llc. | Method for host selection based on discovered NAT type |
| US8083585B2 (en) | 2002-09-10 | 2011-12-27 | Igt | Apparatus and method for copying gaming machine configuration settings |
| US7552223B1 (en) * | 2002-09-16 | 2009-06-23 | Netapp, Inc. | Apparatus and method for data consistency in a proxy cache |
| US7287046B2 (en) * | 2002-09-30 | 2007-10-23 | Emc Corporation | Method and system of compacting sparse directories in a file system |
| US7574653B2 (en) | 2002-10-11 | 2009-08-11 | Microsoft Corporation | Adaptive image formatting control |
| AU2002952274A0 (en) * | 2002-10-24 | 2002-11-07 | Ideadata Pty Ltd | A computing device and method for recording data exchanged between electronic devices |
| US7162582B2 (en) * | 2002-11-18 | 2007-01-09 | Aristos Logic Corporation | Caching in a virtualization system |
| US20040106452A1 (en) * | 2002-12-02 | 2004-06-03 | Igt | Hosted game development environment |
| US7093099B2 (en) * | 2002-12-12 | 2006-08-15 | Alacritech, Inc. | Native lookup instruction for file-access processor searching a three-level lookup cache for variable-length keys |
| GB0229892D0 (en) * | 2002-12-21 | 2003-01-29 | Ibm | Method and apparatus for caching documents |
| US20040128329A1 (en) * | 2002-12-31 | 2004-07-01 | International Business Machines Corporation | Parallel incremental compaction |
| US7827282B2 (en) * | 2003-01-08 | 2010-11-02 | At&T Intellectual Property I, L.P. | System and method for processing hardware or service usage data |
| US7080060B2 (en) * | 2003-01-08 | 2006-07-18 | Sbc Properties, L.P. | System and method for intelligent data caching |
| US7797626B2 (en) * | 2003-02-12 | 2010-09-14 | Sap Ag | Managing different representations of information |
| US7975043B2 (en) | 2003-02-25 | 2011-07-05 | Hewlett-Packard Development Company, L.P. | Method and apparatus for monitoring a network |
| US20040167977A1 (en) * | 2003-02-25 | 2004-08-26 | Douglas Christopher Paul | Method and system for monitoring streaming media flow |
| US20040167981A1 (en) * | 2003-02-25 | 2004-08-26 | Douglas Christopher Paul | Method and system for monitoring relationships between content devices in a content delivery network |
| US7627552B2 (en) | 2003-03-27 | 2009-12-01 | Microsoft Corporation | System and method for filtering and organizing items based on common elements |
| US7421438B2 (en) | 2004-04-29 | 2008-09-02 | Microsoft Corporation | Metadata editing control |
| US7769794B2 (en) | 2003-03-24 | 2010-08-03 | Microsoft Corporation | User interface for a file system shell |
| US7712034B2 (en) | 2003-03-24 | 2010-05-04 | Microsoft Corporation | System and method for shell browser |
| US7409644B2 (en) | 2003-05-16 | 2008-08-05 | Microsoft Corporation | File system shell |
| US7823077B2 (en) | 2003-03-24 | 2010-10-26 | Microsoft Corporation | System and method for user modification of metadata in a shell browser |
| US7240292B2 (en) | 2003-04-17 | 2007-07-03 | Microsoft Corporation | Virtual address bar user interface control |
| US7827561B2 (en) | 2003-03-26 | 2010-11-02 | Microsoft Corporation | System and method for public consumption of communication events between arbitrary processes |
| US7890960B2 (en) | 2003-03-26 | 2011-02-15 | Microsoft Corporation | Extensible user context system for delivery of notifications |
| US7536386B2 (en) * | 2003-03-27 | 2009-05-19 | Microsoft Corporation | System and method for sharing items in a computer system |
| US7526483B2 (en) | 2003-03-27 | 2009-04-28 | Microsoft Corporation | System and method for virtual folder sharing including utilization of static and dynamic lists |
| US7587411B2 (en) | 2003-03-27 | 2009-09-08 | Microsoft Corporation | System and method for filtering and organizing items based on common elements |
| US7650575B2 (en) | 2003-03-27 | 2010-01-19 | Microsoft Corporation | Rich drag drop user interface |
| US7925682B2 (en) | 2003-03-27 | 2011-04-12 | Microsoft Corporation | System and method utilizing virtual folders |
| US7499925B2 (en) | 2003-03-27 | 2009-03-03 | Microsoft Corporation | File system for displaying items of different types and from different physical locations |
| US7430570B1 (en) | 2003-04-28 | 2008-09-30 | Ibrix, Inc. | Shadow directory structure in a distributed segmented file system |
| WO2004114529A2 (en) * | 2003-06-16 | 2004-12-29 | Mentat Inc. | Pre-fetch communication systems and methods |
| US7617203B2 (en) * | 2003-08-01 | 2009-11-10 | Yahoo! Inc | Listings optimization using a plurality of data sources |
| US7426525B2 (en) * | 2003-08-08 | 2008-09-16 | Hewlett-Packard Development Company, L.P. | Method and apparatus for identifying an object using an object description language |
| US8156122B2 (en) | 2003-09-30 | 2012-04-10 | Sony Corporation | Information reproduction device and method and program |
| US8512144B2 (en) | 2003-10-20 | 2013-08-20 | Tipping Point Group, Llc | Method and apparatus for providing secondary gaming machine functionality |
| US9564004B2 (en) | 2003-10-20 | 2017-02-07 | Igt | Closed-loop system for providing additional event participation to electronic video game customers |
| US7877390B2 (en) * | 2003-10-20 | 2011-01-25 | International Business Machines Corporation | Systems and methods for providing autonomous persistent storage systems |
| US8024335B2 (en) | 2004-05-03 | 2011-09-20 | Microsoft Corporation | System and method for dynamically generating a selectable search extension |
| US7181463B2 (en) * | 2003-10-24 | 2007-02-20 | Microsoft Corporation | System and method for managing data using static lists |
| US7171540B1 (en) * | 2003-10-31 | 2007-01-30 | Sun Microsystems, Inc. | Object-addressed memory hierarchy that facilitates accessing objects stored outside of main memory |
| US7076608B2 (en) * | 2003-12-02 | 2006-07-11 | Oracle International Corp. | Invalidating cached data using secondary keys |
| US7826600B2 (en) * | 2003-12-22 | 2010-11-02 | International Business Machines Corporation | Method and procedure for compiling and caching VoiceXML documents in a voice XML interpreter |
| US7418464B2 (en) * | 2004-01-27 | 2008-08-26 | International Business Machines Corporation | Method, system, and program for storing data for retrieval and transfer |
| KR101164788B1 (ko) * | 2004-03-23 | 2012-07-11 | 엔디에스 리미티드 | 이동 가입자 단말기 재생에 적합하게 순응하는 멀티미디어콘텐트 |
| US9092558B2 (en) * | 2004-04-05 | 2015-07-28 | International Business Machines Corporation | Grouping frequently referenced data items to co-locate for cache utilization |
| US7694236B2 (en) | 2004-04-23 | 2010-04-06 | Microsoft Corporation | Stack icons representing multiple objects |
| US7657846B2 (en) | 2004-04-23 | 2010-02-02 | Microsoft Corporation | System and method for displaying stack icons |
| US7992103B2 (en) | 2004-04-26 | 2011-08-02 | Microsoft Corporation | Scaling icons for representing files |
| US8707209B2 (en) | 2004-04-29 | 2014-04-22 | Microsoft Corporation | Save preview representation of files being created |
| US8108430B2 (en) | 2004-04-30 | 2012-01-31 | Microsoft Corporation | Carousel control for metadata navigation and assignment |
| US7496583B2 (en) * | 2004-04-30 | 2009-02-24 | Microsoft Corporation | Property tree for metadata navigation and assignment |
| US7890604B2 (en) | 2004-05-07 | 2011-02-15 | Microsoft Corproation | Client-side callbacks to server events |
| US9026578B2 (en) | 2004-05-14 | 2015-05-05 | Microsoft Corporation | Systems and methods for persisting data between web pages |
| US7464386B2 (en) | 2004-05-17 | 2008-12-09 | Microsoft Corporation | Data controls architecture |
| US7401102B2 (en) * | 2004-10-19 | 2008-07-15 | International Business Machines Corporation | Management of global counters in transactions |
| KR100654447B1 (ko) * | 2004-12-15 | 2006-12-06 | 삼성전자주식회사 | 지역별로 존재하는 컨텐츠를 글로벌로 공유하고 거래하는방법 및 시스템 |
| US9613491B2 (en) | 2004-12-16 | 2017-04-04 | Igt | Video gaming device having a system and method for completing wagers and purchases during the cash out process |
| JP2006185059A (ja) * | 2004-12-27 | 2006-07-13 | Fujitsu Ltd | コンテンツ管理装置 |
| US7383503B2 (en) * | 2005-02-23 | 2008-06-03 | Microsoft Corporation | Filtering a collection of items |
| US20070073678A1 (en) * | 2005-09-23 | 2007-03-29 | Applied Linguistics, Llc | Semantic document profiling |
| US20060236253A1 (en) * | 2005-04-15 | 2006-10-19 | Microsoft Corporation | Dialog user interfaces for related tasks and programming interface for same |
| US8490015B2 (en) | 2005-04-15 | 2013-07-16 | Microsoft Corporation | Task dialog and programming interface for same |
| US8522154B2 (en) | 2005-04-22 | 2013-08-27 | Microsoft Corporation | Scenario specialization of file browser |
| US8195646B2 (en) | 2005-04-22 | 2012-06-05 | Microsoft Corporation | Systems, methods, and user interfaces for storing, searching, navigating, and retrieving electronic information |
| AU2006243628B2 (en) * | 2005-05-03 | 2011-10-27 | Igt | Dynamically configurable user interface in a game of chance |
| US7752625B2 (en) * | 2005-06-17 | 2010-07-06 | International Business Machines Corporation | Caching resources requested by applications |
| US7966292B1 (en) | 2005-06-30 | 2011-06-21 | Emc Corporation | Index processing |
| US8156079B1 (en) | 2005-06-30 | 2012-04-10 | Emc Corporation | System and method for index processing |
| US8161005B1 (en) | 2005-06-30 | 2012-04-17 | Emc Corporation | Efficient index processing |
| US7665028B2 (en) | 2005-07-13 | 2010-02-16 | Microsoft Corporation | Rich drag drop user interface |
| US7887420B2 (en) | 2005-09-12 | 2011-02-15 | Igt | Method and system for instant-on game download |
| US8287379B2 (en) | 2005-09-12 | 2012-10-16 | Igt | Distributed game services |
| US20070073745A1 (en) * | 2005-09-23 | 2007-03-29 | Applied Linguistics, Llc | Similarity metric for semantic profiling |
| US20070094347A1 (en) * | 2005-09-27 | 2007-04-26 | Teamon Systems, Inc. | System for obtaining image using xslt extension and related method |
| US20070083599A1 (en) * | 2005-09-27 | 2007-04-12 | Teamon Systems, Inc. | System for transforming application data using xslt extensions to render templates from cache and related methods |
| US7752211B1 (en) * | 2005-09-30 | 2010-07-06 | Emc Corporation | Adaptive index processing |
| US7627609B1 (en) | 2005-09-30 | 2009-12-01 | Emc Corporation | Index processing using transformed values |
| US7698325B1 (en) | 2005-09-30 | 2010-04-13 | Emc Corporation | Index processing for legacy systems |
| US8326899B2 (en) * | 2005-11-09 | 2012-12-04 | Ca, Inc. | Method and system for improving write performance in a supplemental directory |
| US20070112812A1 (en) * | 2005-11-09 | 2007-05-17 | Harvey Richard H | System and method for writing data to a directory |
| US20070112791A1 (en) * | 2005-11-09 | 2007-05-17 | Harvey Richard H | Method and system for providing enhanced read performance for a supplemental directory |
| US8458176B2 (en) * | 2005-11-09 | 2013-06-04 | Ca, Inc. | Method and system for providing a directory overlay |
| US8321486B2 (en) * | 2005-11-09 | 2012-11-27 | Ca, Inc. | Method and system for configuring a supplemental directory |
| US7529780B1 (en) | 2005-12-30 | 2009-05-05 | Google Inc. | Conflict management during data object synchronization between client and server |
| US7951008B2 (en) * | 2006-03-03 | 2011-05-31 | Igt | Non-volatile memory management technique implemented in a gaming machine |
| US9028329B2 (en) | 2006-04-13 | 2015-05-12 | Igt | Integrating remotely-hosted and locally rendered content on a gaming device |
| US10026255B2 (en) | 2006-04-13 | 2018-07-17 | Igt | Presentation of remotely-hosted and locally rendered content for gaming systems |
| US8968077B2 (en) | 2006-04-13 | 2015-03-03 | Idt | Methods and systems for interfacing with a third-party application |
| US8784196B2 (en) | 2006-04-13 | 2014-07-22 | Igt | Remote content management and resource sharing on a gaming machine and method of implementing same |
| US8777737B2 (en) * | 2006-04-13 | 2014-07-15 | Igt | Method and apparatus for integrating remotely-hosted and locally rendered content on a gaming device |
| US8992304B2 (en) | 2006-04-13 | 2015-03-31 | Igt | Methods and systems for tracking an event of an externally controlled interface |
| US10324735B2 (en) | 2006-05-15 | 2019-06-18 | Avaya Inc. | Method invocation for persistent objects with dynamic multikeys |
| US10185579B2 (en) | 2006-05-15 | 2019-01-22 | Avaya Inc. | Dynamic multikeys for persistent objects |
| US10289728B2 (en) * | 2006-05-15 | 2019-05-14 | Avaya Inc. | Garbage collection of persistent objects with dynamic multikeys |
| US7720892B1 (en) * | 2006-06-30 | 2010-05-18 | Emc Corporation | Bulk updates and tape synchronization |
| EP2057821A1 (en) * | 2006-08-29 | 2009-05-13 | Nokia Corporation | Service identification optimization |
| US7963839B2 (en) * | 2006-09-19 | 2011-06-21 | Mudalla Technology, Inc. | Regulated gaming exchange |
| US9311774B2 (en) | 2006-11-10 | 2016-04-12 | Igt | Gaming machine with externally controlled content display |
| US20090156303A1 (en) | 2006-11-10 | 2009-06-18 | Igt | Bonusing Architectures in a Gaming Environment |
| US9830309B2 (en) | 2007-04-27 | 2017-11-28 | Oracle International Corporation | Method for creating page components for a page wherein the display of a specific form of the requested page component is determined by the access of a particular URL |
| US7995478B2 (en) | 2007-05-30 | 2011-08-09 | Sony Computer Entertainment Inc. | Network communication with path MTU size discovery |
| US7933273B2 (en) | 2007-07-27 | 2011-04-26 | Sony Computer Entertainment Inc. | Cooperative NAT behavior discovery |
| JP5064134B2 (ja) * | 2007-08-03 | 2012-10-31 | 株式会社日立製作所 | メモリ管理方法およびその方法を用いるコンピュータ |
| US7856501B2 (en) | 2007-12-04 | 2010-12-21 | Sony Computer Entertainment Inc. | Network traffic prioritization |
| US20090193210A1 (en) * | 2008-01-29 | 2009-07-30 | Hewett Jeffrey R | System for Automatic Legal Discovery Management and Data Collection |
| US20090198699A1 (en) * | 2008-01-31 | 2009-08-06 | International Business Machines Corporation | Remote space efficient repository |
| WO2009097586A1 (en) * | 2008-01-31 | 2009-08-06 | Bea Systems, Inc. | System and method for transactional cache |
| US7856506B2 (en) | 2008-03-05 | 2010-12-21 | Sony Computer Entertainment Inc. | Traversal of symmetric network address translator for multiple simultaneous connections |
| US10924573B2 (en) | 2008-04-04 | 2021-02-16 | Level 3 Communications, Llc | Handling long-tail content in a content delivery network (CDN) |
| US9762692B2 (en) | 2008-04-04 | 2017-09-12 | Level 3 Communications, Llc | Handling long-tail content in a content delivery network (CDN) |
| WO2009123868A2 (en) | 2008-04-04 | 2009-10-08 | Level 3 Communications, Llc | Handling long-tail content in a content delivery network (cdn) |
| US9456054B2 (en) | 2008-05-16 | 2016-09-27 | Palo Alto Research Center Incorporated | Controlling the spread of interests and content in a content centric network |
| US8578338B2 (en) * | 2008-06-02 | 2013-11-05 | Igt | Game production and regulatory approval systems |
| US8386494B2 (en) * | 2008-08-07 | 2013-02-26 | Hewlett-Packard Development Company, L.P. | Providing data structures for determining whether keys of an index are present in a storage system |
| US8620861B1 (en) | 2008-09-30 | 2013-12-31 | Google Inc. | Preserving file metadata during atomic save operations |
| US9934240B2 (en) * | 2008-09-30 | 2018-04-03 | Google Llc | On demand access to client cached files |
| US10235832B2 (en) | 2008-10-17 | 2019-03-19 | Igt | Post certification metering for diverse game machines |
| US7962502B2 (en) | 2008-11-18 | 2011-06-14 | Yahoo! Inc. | Efficient caching for dynamic webservice queries using cachable fragments |
| US8190844B2 (en) * | 2008-12-02 | 2012-05-29 | Lsi Corporation | Efficient alert mechanism for overutilization of storage resources |
| US8055841B2 (en) | 2009-02-19 | 2011-11-08 | International Business Machines Corporation | System and method for caching data on a hard disk drive |
| WO2010097942A1 (ja) * | 2009-02-27 | 2010-09-02 | 富士通株式会社 | 電子署名プログラム、電子署名装置、および電子署名方法 |
| US20100228906A1 (en) * | 2009-03-06 | 2010-09-09 | Arunprasad Ramiya Mothilal | Managing Data in a Non-Volatile Memory System |
| US9117071B2 (en) * | 2009-06-03 | 2015-08-25 | Apple Inc. | Methods and apparatuses for secure compilation |
| US8677329B2 (en) * | 2009-06-03 | 2014-03-18 | Apple Inc. | Methods and apparatuses for a compiler server |
| US8923293B2 (en) | 2009-10-21 | 2014-12-30 | Palo Alto Research Center Incorporated | Adaptive multi-interface use for content networking |
| US8156385B2 (en) * | 2009-10-28 | 2012-04-10 | International Business Machines Corporation | Systems and methods for backward-compatible constant-time exception-protection memory |
| US8577936B2 (en) | 2010-11-29 | 2013-11-05 | International Business Machines Corporation | Fixup cache tool for object memory compaction in an information handling system |
| US8463765B2 (en) | 2011-04-29 | 2013-06-11 | Zachary C. LESAVICH | Method and system for creating vertical search engines with cloud computing networks |
| US9400851B2 (en) * | 2011-06-23 | 2016-07-26 | Incapsula, Inc. | Dynamic content caching |
| US9378138B2 (en) | 2011-06-29 | 2016-06-28 | International Business Machines Corporation | Conservative garbage collection and access protection |
| US9524609B2 (en) | 2011-09-30 | 2016-12-20 | Igt | Gaming system, gaming device and method for utilizing mobile devices at a gaming establishment |
| US9466173B2 (en) | 2011-09-30 | 2016-10-11 | Igt | System and method for remote rendering of content on an electronic gaming machine |
| US9251086B2 (en) | 2012-01-24 | 2016-02-02 | SanDisk Technologies, Inc. | Apparatus, system, and method for managing a cache |
| US8938428B1 (en) | 2012-04-16 | 2015-01-20 | Emc Corporation | Systems and methods for efficiently locating object names in a large index of records containing object names |
| US10019371B2 (en) * | 2012-04-27 | 2018-07-10 | Hewlett Packard Enterprise Development Lp | Data caching using local and remote memory |
| US8898376B2 (en) | 2012-06-04 | 2014-11-25 | Fusion-Io, Inc. | Apparatus, system, and method for grouping data stored on an array of solid-state storage elements |
| US9229901B1 (en) * | 2012-06-08 | 2016-01-05 | Google Inc. | Single-sided distributed storage system |
| US9569356B1 (en) * | 2012-06-15 | 2017-02-14 | Emc Corporation | Methods for updating reference count and shared objects in a concurrent system |
| US8909808B2 (en) * | 2012-07-19 | 2014-12-09 | Cisco Technology, Inc. | Redundancy elimination for web caching |
| US10528262B1 (en) * | 2012-07-26 | 2020-01-07 | EMC IP Holding Company LLC | Replication-based federation of scalable data across multiple sites |
| US9164702B1 (en) * | 2012-09-07 | 2015-10-20 | Google Inc. | Single-sided distributed cache system |
| US9129469B2 (en) | 2012-09-11 | 2015-09-08 | Igt | Player driven game download to a gaming machine |
| US9213646B1 (en) | 2013-06-20 | 2015-12-15 | Seagate Technology Llc | Cache data value tracking |
| US10098051B2 (en) | 2014-01-22 | 2018-10-09 | Cisco Technology, Inc. | Gateways and routing in software-defined manets |
| US9954678B2 (en) | 2014-02-06 | 2018-04-24 | Cisco Technology, Inc. | Content-based transport security |
| US9836540B2 (en) | 2014-03-04 | 2017-12-05 | Cisco Technology, Inc. | System and method for direct storage access in a content-centric network |
| US9626413B2 (en) | 2014-03-10 | 2017-04-18 | Cisco Systems, Inc. | System and method for ranking content popularity in a content-centric network |
| US9716622B2 (en) | 2014-04-01 | 2017-07-25 | Cisco Technology, Inc. | System and method for dynamic name configuration in content-centric networks |
| US9473576B2 (en) | 2014-04-07 | 2016-10-18 | Palo Alto Research Center Incorporated | Service discovery using collection synchronization with exact names |
| US9992281B2 (en) | 2014-05-01 | 2018-06-05 | Cisco Technology, Inc. | Accountable content stores for information centric networks |
| US9609014B2 (en) | 2014-05-22 | 2017-03-28 | Cisco Systems, Inc. | Method and apparatus for preventing insertion of malicious content at a named data network router |
| US9699198B2 (en) | 2014-07-07 | 2017-07-04 | Cisco Technology, Inc. | System and method for parallel secure content bootstrapping in content-centric networks |
| US9430387B2 (en) * | 2014-07-16 | 2016-08-30 | ClearSky Data | Decoupling data and metadata in hierarchical cache system |
| US9621354B2 (en) | 2014-07-17 | 2017-04-11 | Cisco Systems, Inc. | Reconstructable content objects |
| US9590887B2 (en) | 2014-07-18 | 2017-03-07 | Cisco Systems, Inc. | Method and system for keeping interest alive in a content centric network |
| US9729616B2 (en) | 2014-07-18 | 2017-08-08 | Cisco Technology, Inc. | Reputation-based strategy for forwarding and responding to interests over a content centric network |
| US9535968B2 (en) * | 2014-07-21 | 2017-01-03 | Palo Alto Research Center Incorporated | System for distributing nameless objects using self-certifying names |
| US9882964B2 (en) | 2014-08-08 | 2018-01-30 | Cisco Technology, Inc. | Explicit strategy feedback in name-based forwarding |
| US9729662B2 (en) | 2014-08-11 | 2017-08-08 | Cisco Technology, Inc. | Probabilistic lazy-forwarding technique without validation in a content centric network |
| US9800637B2 (en) | 2014-08-19 | 2017-10-24 | Cisco Technology, Inc. | System and method for all-in-one content stream in content-centric networks |
| US10069933B2 (en) | 2014-10-23 | 2018-09-04 | Cisco Technology, Inc. | System and method for creating virtual interfaces based on network characteristics |
| US9710199B2 (en) | 2014-11-07 | 2017-07-18 | International Business Machines Corporation | Non-volatile memory data storage with low read amplification |
| US9590948B2 (en) | 2014-12-15 | 2017-03-07 | Cisco Systems, Inc. | CCN routing using hardware-assisted hash tables |
| US10237189B2 (en) | 2014-12-16 | 2019-03-19 | Cisco Technology, Inc. | System and method for distance-based interest forwarding |
| US10003520B2 (en) | 2014-12-22 | 2018-06-19 | Cisco Technology, Inc. | System and method for efficient name-based content routing using link-state information in information-centric networks |
| US10162700B2 (en) | 2014-12-23 | 2018-12-25 | International Business Machines Corporation | Workload-adaptive data packing algorithm |
| US9660825B2 (en) | 2014-12-24 | 2017-05-23 | Cisco Technology, Inc. | System and method for multi-source multicasting in content-centric networks |
| US9946743B2 (en) | 2015-01-12 | 2018-04-17 | Cisco Technology, Inc. | Order encoded manifests in a content centric network |
| US9832291B2 (en) | 2015-01-12 | 2017-11-28 | Cisco Technology, Inc. | Auto-configurable transport stack |
| US9954795B2 (en) | 2015-01-12 | 2018-04-24 | Cisco Technology, Inc. | Resource allocation using CCN manifests |
| US9916457B2 (en) | 2015-01-12 | 2018-03-13 | Cisco Technology, Inc. | Decoupled name security binding for CCN objects |
| US10333840B2 (en) | 2015-02-06 | 2019-06-25 | Cisco Technology, Inc. | System and method for on-demand content exchange with adaptive naming in information-centric networks |
| US10075401B2 (en) | 2015-03-18 | 2018-09-11 | Cisco Technology, Inc. | Pending interest table behavior |
| US10560543B2 (en) * | 2015-03-26 | 2020-02-11 | Fortinet, Inc. | Rule based cache processing in application delivery controller for load balancing |
| US10075402B2 (en) | 2015-06-24 | 2018-09-11 | Cisco Technology, Inc. | Flexible command and control in content centric networks |
| US9612754B1 (en) * | 2015-06-29 | 2017-04-04 | EMC IP Holding Company LLC | Data storage system with window allocation using window cache |
| US9916735B2 (en) | 2015-07-22 | 2018-03-13 | Igt | Remote gaming cash voucher printing system |
| US10701038B2 (en) | 2015-07-27 | 2020-06-30 | Cisco Technology, Inc. | Content negotiation in a content centric network |
| US9986034B2 (en) | 2015-08-03 | 2018-05-29 | Cisco Technology, Inc. | Transferring state in content centric network stacks |
| US10055930B2 (en) | 2015-08-11 | 2018-08-21 | Igt | Gaming system and method for placing and redeeming sports bets |
| US9832123B2 (en) | 2015-09-11 | 2017-11-28 | Cisco Technology, Inc. | Network named fragments in a content centric network |
| US10355999B2 (en) | 2015-09-23 | 2019-07-16 | Cisco Technology, Inc. | Flow control with network named fragments |
| US10313227B2 (en) | 2015-09-24 | 2019-06-04 | Cisco Technology, Inc. | System and method for eliminating undetected interest looping in information-centric networks |
| US9712190B2 (en) | 2015-09-24 | 2017-07-18 | International Business Machines Corporation | Data packing for compression-enabled storage systems |
| US9977809B2 (en) | 2015-09-24 | 2018-05-22 | Cisco Technology, Inc. | Information and data framework in a content centric network |
| US10440140B2 (en) * | 2015-09-29 | 2019-10-08 | Apple Inc. | Browser cache management |
| US10454820B2 (en) | 2015-09-29 | 2019-10-22 | Cisco Technology, Inc. | System and method for stateless information-centric networking |
| US10263965B2 (en) | 2015-10-16 | 2019-04-16 | Cisco Technology, Inc. | Encrypted CCNx |
| US9870285B2 (en) | 2015-11-18 | 2018-01-16 | International Business Machines Corporation | Selectively de-straddling data pages in non-volatile memory |
| US9912776B2 (en) | 2015-12-02 | 2018-03-06 | Cisco Technology, Inc. | Explicit content deletion commands in a content centric network |
| US10097346B2 (en) | 2015-12-09 | 2018-10-09 | Cisco Technology, Inc. | Key catalogs in a content centric network |
| US10257271B2 (en) | 2016-01-11 | 2019-04-09 | Cisco Technology, Inc. | Chandra-Toueg consensus in a content centric network |
| US10305864B2 (en) | 2016-01-25 | 2019-05-28 | Cisco Technology, Inc. | Method and system for interest encryption in a content centric network |
| US10043016B2 (en) | 2016-02-29 | 2018-08-07 | Cisco Technology, Inc. | Method and system for name encryption agreement in a content centric network |
| DE102016103882A1 (de) * | 2016-03-03 | 2017-09-07 | Cadami Ug (Haftungsbeschränkt) | Zuordnungsverfahren sowie Netzwerk mit einer Zuordnungsvorrichtung |
| DE102016108018A1 (de) * | 2016-03-03 | 2017-09-07 | Cadami Ug (Haftungsbeschränkt) | Kennungscodierungseinrichtung und Kennungsdecodierungseinrichtung zur Datenverteilung in Netzwerken sowie derartige Einrichtungen aufweisende Netzwerkelemente |
| US10003507B2 (en) | 2016-03-04 | 2018-06-19 | Cisco Technology, Inc. | Transport session state protocol |
| US10051071B2 (en) | 2016-03-04 | 2018-08-14 | Cisco Technology, Inc. | Method and system for collecting historical network information in a content centric network |
| US10742596B2 (en) | 2016-03-04 | 2020-08-11 | Cisco Technology, Inc. | Method and system for reducing a collision probability of hash-based names using a publisher identifier |
| US10264099B2 (en) | 2016-03-07 | 2019-04-16 | Cisco Technology, Inc. | Method and system for content closures in a content centric network |
| US10067948B2 (en) | 2016-03-18 | 2018-09-04 | Cisco Technology, Inc. | Data deduping in content centric networking manifests |
| US10091330B2 (en) | 2016-03-23 | 2018-10-02 | Cisco Technology, Inc. | Interest scheduling by an information and data framework in a content centric network |
| US10320760B2 (en) | 2016-04-01 | 2019-06-11 | Cisco Technology, Inc. | Method and system for mutating and caching content in a content centric network |
| US9930146B2 (en) | 2016-04-04 | 2018-03-27 | Cisco Technology, Inc. | System and method for compressing content centric networking messages |
| US10425503B2 (en) | 2016-04-07 | 2019-09-24 | Cisco Technology, Inc. | Shared pending interest table in a content centric network |
| US10084764B2 (en) | 2016-05-13 | 2018-09-25 | Cisco Technology, Inc. | System for a secure encryption proxy in a content centric network |
| US10063414B2 (en) | 2016-05-13 | 2018-08-28 | Cisco Technology, Inc. | Updating a transport stack in a content centric network |
| US10103989B2 (en) | 2016-06-13 | 2018-10-16 | Cisco Technology, Inc. | Content object return messages in a content centric network |
| US10305865B2 (en) | 2016-06-21 | 2019-05-28 | Cisco Technology, Inc. | Permutation-based content encryption with manifests in a content centric network |
| US10148572B2 (en) | 2016-06-27 | 2018-12-04 | Cisco Technology, Inc. | Method and system for interest groups in a content centric network |
| US10331561B1 (en) | 2016-06-29 | 2019-06-25 | Emc Corporation | Systems and methods for rebuilding a cache index |
| US10146438B1 (en) | 2016-06-29 | 2018-12-04 | EMC IP Holding Company LLC | Additive library for data structures in a flash memory |
| US10037164B1 (en) | 2016-06-29 | 2018-07-31 | EMC IP Holding Company LLC | Flash interface for processing datasets |
| US10089025B1 (en) | 2016-06-29 | 2018-10-02 | EMC IP Holding Company LLC | Bloom filters in a flash memory |
| US10261704B1 (en) | 2016-06-29 | 2019-04-16 | EMC IP Holding Company LLC | Linked lists in flash memory |
| US10055351B1 (en) * | 2016-06-29 | 2018-08-21 | EMC IP Holding Company LLC | Low-overhead index for a flash cache |
| US10009266B2 (en) | 2016-07-05 | 2018-06-26 | Cisco Technology, Inc. | Method and system for reference counted pending interest tables in a content centric network |
| US9992097B2 (en) | 2016-07-11 | 2018-06-05 | Cisco Technology, Inc. | System and method for piggybacking routing information in interests in a content centric network |
| US9588976B1 (en) * | 2016-07-22 | 2017-03-07 | Red Hat, Inc. | Delayed allocation for a direct access non-volatile file system |
| US9886449B1 (en) * | 2016-07-22 | 2018-02-06 | Red Hat, Inc. | Delayed allocation for data object creation |
| US10122624B2 (en) | 2016-07-25 | 2018-11-06 | Cisco Technology, Inc. | System and method for ephemeral entries in a forwarding information base in a content centric network |
| US10069729B2 (en) | 2016-08-08 | 2018-09-04 | Cisco Technology, Inc. | System and method for throttling traffic based on a forwarding information base in a content centric network |
| US10956412B2 (en) | 2016-08-09 | 2021-03-23 | Cisco Technology, Inc. | Method and system for conjunctive normal form attribute matching in a content centric network |
| US10033642B2 (en) | 2016-09-19 | 2018-07-24 | Cisco Technology, Inc. | System and method for making optimal routing decisions based on device-specific parameters in a content centric network |
| US10212248B2 (en) | 2016-10-03 | 2019-02-19 | Cisco Technology, Inc. | Cache management on high availability routers in a content centric network |
| US10447805B2 (en) | 2016-10-10 | 2019-10-15 | Cisco Technology, Inc. | Distributed consensus in a content centric network |
| US10135948B2 (en) | 2016-10-31 | 2018-11-20 | Cisco Technology, Inc. | System and method for process migration in a content centric network |
| US10243851B2 (en) | 2016-11-21 | 2019-03-26 | Cisco Technology, Inc. | System and method for forwarder connection information in a content centric network |
| US10289315B2 (en) | 2017-03-27 | 2019-05-14 | Western Digital Technologies, Inc. | Managing I/O operations of large data objects in a cache memory device by dividing into chunks |
| US20180336128A1 (en) * | 2017-05-22 | 2018-11-22 | Ge Aviation Systems, Llc | Methods, systems, and apparatus for safe memory object access in memory management mechanisms |
| US10366011B1 (en) | 2018-05-03 | 2019-07-30 | EMC IP Holding Company LLC | Content-based deduplicated storage having multilevel data cache |
| US10705753B2 (en) * | 2018-05-04 | 2020-07-07 | EMC IP Holding Company LLC | Fan-out asynchronous replication logical level caching |
| US10860239B2 (en) | 2018-05-04 | 2020-12-08 | EMC IP Holding Company LLC | Fan-out asynchronous replication caching |
| CN109033439B (zh) * | 2018-08-15 | 2019-11-19 | 中科驭数（北京）科技有限公司 | 流式数据的处理方法和装置 |
| CN110929186B (zh) * | 2018-08-29 | 2022-05-10 | 武汉斗鱼网络科技有限公司 | 一种客户端及信息显示方法、电子设备、介质 |
| US10936501B2 (en) | 2019-02-01 | 2021-03-02 | Kinaxis Inc. | Cache management for search optimization |
| US11556470B2 (en) | 2021-02-02 | 2023-01-17 | Kinaxis Inc. | Cache management for search optimization |
| US11775433B2 (en) | 2019-02-01 | 2023-10-03 | Kinaxis Inc. | Cache management for search optimization |
| US11144498B2 (en) * | 2019-03-08 | 2021-10-12 | Netapp Inc. | Defragmentation for objects within object store |
| US11016943B2 (en) | 2019-03-08 | 2021-05-25 | Netapp, Inc. | Garbage collection for objects within object store |
| US11899620B2 (en) | 2019-03-08 | 2024-02-13 | Netapp, Inc. | Metadata attachment to storage objects within object store |
| CN111930708B (zh) * | 2020-07-14 | 2023-07-11 | 上海德拓信息技术股份有限公司 | 基于Ceph对象存储的对象标签的扩展系统及方法 |
| US11582025B2 (en) | 2020-09-29 | 2023-02-14 | Amazon Technologies, Inc. | Efficient deduplication using block-based convergent encryption |
| US11329803B2 (en) | 2020-09-29 | 2022-05-10 | Amazon Technologies, Inc. | Redundancy controls in convergent encryption using dynamic salt values |
| US11341137B1 (en) * | 2020-12-04 | 2022-05-24 | Amadeus S.A.S. | Processing search requests |
| US11954022B2 (en) * | 2022-03-02 | 2024-04-09 | International Business Machines Corporation | Throttling host writes in a host buffer to a storage device |
| CN116467354B (zh) * | 2023-06-15 | 2023-09-12 | 本原数据(北京)信息技术有限公司 | 数据库的查询方法和装置、计算机设备、存储介质 |
Family Cites Families (47)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPS58177383A (ja) * | 1982-04-12 | 1983-10-18 | Hitachi Ltd | エンドレスカウント方法およびその装置 |
| US4918646A (en) | 1986-08-28 | 1990-04-17 | Kabushiki Kaisha Toshiba | Information retrieval apparatus |
| US4841433A (en) | 1986-11-26 | 1989-06-20 | American Telephone And Telegraph Company, At&T Bell Laboratories | Method and apparatus for accessing data from data attribute tables |
| US4853843A (en) | 1987-12-18 | 1989-08-01 | Tektronix, Inc. | System for merging virtual partitions of a distributed database |
| US5611049A (en) * | 1992-06-03 | 1997-03-11 | Pitts; William M. | System for accessing distributed data cache channel at each network node to pass requests and data |
| US5381539A (en) * | 1992-06-04 | 1995-01-10 | Emc Corporation | System and method for dynamically controlling cache management |
| US5649200A (en) | 1993-01-08 | 1997-07-15 | Atria Software, Inc. | Dynamic rule-based version control system |
| US5664106A (en) * | 1993-06-04 | 1997-09-02 | Digital Equipment Corporation | Phase-space surface representation of server computer performance in a computer network |
| US5542087A (en) * | 1993-10-15 | 1996-07-30 | Hewlett-Packard Company | Linear hashing for distributed records |
| US5586264A (en) | 1994-09-08 | 1996-12-17 | Ibm Corporation | Video optimized media streamer with cache management |
| US6029195A (en) | 1994-11-29 | 2000-02-22 | Herz; Frederick S. M. | System for customized electronic identification of desirable objects |
| EP0826181A4 (en) | 1995-04-11 | 2005-02-09 | Kinetech Inc | IDENTIFYING DATA IN A DATA PROCESSING SYSTEM |
| US5805809A (en) * | 1995-04-26 | 1998-09-08 | Shiva Corporation | Installable performance accelerator for maintaining a local cache storing data residing on a server computer |
| US5748954A (en) * | 1995-06-05 | 1998-05-05 | Carnegie Mellon University | Method for searching a queued and ranked constructed catalog of files stored on a network |
| JP2770786B2 (ja) * | 1995-06-05 | 1998-07-02 | 日本電気株式会社 | 構造化データの多重ａｔｍ／ｓｔｍ変換装置 |
| US5872969A (en) * | 1995-06-23 | 1999-02-16 | International Business Machines Corporation | System and method for efficiently synchronizing cache and persistent data in an object oriented transaction processing system |
| US6002667A (en) * | 1995-07-19 | 1999-12-14 | Fujitsu Network Communications, Inc. | Minimum guaranteed cell rate method and apparatus |
| US5732267A (en) * | 1995-08-02 | 1998-03-24 | Microsoft Corporation | Caching/prewarming data loaded from CD-ROM |
| US5751993A (en) * | 1995-09-05 | 1998-05-12 | Emc Corporation | Cache management system |
| US5592432A (en) * | 1995-09-05 | 1997-01-07 | Emc Corp | Cache management system using time stamping for replacement queue |
| US5774670A (en) * | 1995-10-06 | 1998-06-30 | Netscape Communications Corporation | Persistent client state in a hypertext transfer protocol based client-server system |
| US5774643A (en) | 1995-10-13 | 1998-06-30 | Digital Equipment Corporation | Enhanced raid write hole protection and recovery |
| US5701432A (en) * | 1995-10-13 | 1997-12-23 | Sun Microsystems, Inc. | Multi-threaded processing system having a cache that is commonly accessible to each thread |
| US5727159A (en) * | 1996-04-10 | 1998-03-10 | Kikinis; Dan | System in which a Proxy-Server translates information received from the Internet into a form/format readily usable by low power portable computers |
| US5864852A (en) * | 1996-04-26 | 1999-01-26 | Netscape Communications Corporation | Proxy server caching mechanism that provides a file directory structure and a mapping mechanism within the file directory structure |
| US5918013A (en) * | 1996-06-03 | 1999-06-29 | Webtv Networks, Inc. | Method of transcoding documents in a network environment using a proxy server |
| US5935207A (en) * | 1996-06-03 | 1999-08-10 | Webtv Networks, Inc. | Method and apparatus for providing remote site administrators with user hits on mirrored web sites |
| US6134583A (en) * | 1996-07-01 | 2000-10-17 | Sun Microsystems, Inc. | Method, system, apparatus and article of manufacture for providing identity-based caching services to a plurality of computer systems (#16) |
| US5850443A (en) | 1996-08-15 | 1998-12-15 | Entrust Technologies, Ltd. | Key management system for mixed-trust environments |
| US5852717A (en) * | 1996-11-20 | 1998-12-22 | Shiva Corporation | Performance optimizations for computer networks utilizing HTTP |
| US5909540A (en) | 1996-11-22 | 1999-06-01 | Mangosoft Corporation | System and method for providing highly available data storage using globally addressable memory |
| US5974421A (en) * | 1996-12-23 | 1999-10-26 | Microsoft Corporation | Cache-efficient object loader |
| US5895488A (en) * | 1997-02-24 | 1999-04-20 | Eccs, Inc. | Cache flushing methods and apparatus |
| US5870763A (en) * | 1997-03-10 | 1999-02-09 | Microsoft Corporation | Database computer system with application recovery and dependency handling read cache |
| US5924116A (en) * | 1997-04-02 | 1999-07-13 | International Business Machines Corporation | Collaborative caching of a requested object by a lower level node as a function of the caching status of the object at a higher level node |
| US5920876A (en) | 1997-04-23 | 1999-07-06 | Sun Microsystems, Inc. | Performing exact garbage collection using bitmaps that identify pointer values within objects |
| US6038572A (en) | 1997-04-23 | 2000-03-14 | Sun Microsystems, Inc. | Method and apparatus for localizing nodes in a garbage collected carded heap |
| US6049810A (en) | 1997-04-23 | 2000-04-11 | Sun Microsystems, Inc. | Method and apparatus for implementing a write barrier of a garbage collected heap |
| US6115782A (en) | 1997-04-23 | 2000-09-05 | Sun Micosystems, Inc. | Method and apparatus for locating nodes in a carded heap using a card marking structure and a node advance value |
| US5915255A (en) | 1997-04-23 | 1999-06-22 | Sun Microsystems, Inc. | Method and apparatus for referencing nodes using links |
| US6078994A (en) * | 1997-05-30 | 2000-06-20 | Oracle Corporation | System for maintaining a shared cache in a multi-threaded computer environment |
| US6026413A (en) | 1997-08-01 | 2000-02-15 | International Business Machines Corporation | Determining how changes to underlying data affect cached objects |
| US6000006A (en) * | 1997-08-25 | 1999-12-07 | Bit Microsystems, Inc. | Unified re-map and cache-index table with dual write-counters for wear-leveling of non-volatile flash RAM mass storage |
| US5950205A (en) * | 1997-09-25 | 1999-09-07 | Cisco Technology, Inc. | Data transmission over the internet using a cache memory file system |
| US5987233A (en) * | 1998-03-16 | 1999-11-16 | Skycache Inc. | Comprehensive global information network broadcasting system and implementation thereof |
| US6154769A (en) * | 1998-03-27 | 2000-11-28 | Hewlett-Packard Company | Scheduling server requests to decrease response time and increase server throughput |
| US6128623A (en) * | 1998-04-15 | 2000-10-03 | Inktomi Corporation | High performance object cache |
-
1998
- 1998-04-15 US US09/060,866 patent/US6128623A/en not_active Expired - Lifetime
-
1999
- 1999-04-15 WO PCT/US1999/008281 patent/WO1999053422A1/en active IP Right Grant
- 1999-04-15 JP JP2000543914A patent/JP4489292B2/ja not_active Expired - Lifetime
- 1999-04-15 EP EP99919847A patent/EP1072004B1/en not_active Expired - Lifetime
- 1999-04-15 AU AU37475/99A patent/AU754816B2/en not_active Expired
- 1999-04-15 DE DE69915462T patent/DE69915462T2/de not_active Expired - Lifetime
-
2000
- 2000-04-05 US US09/543,238 patent/US6453319B1/en not_active Expired - Lifetime
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US10419534B2 (en) | 2016-02-29 | 2019-09-17 | Fujitsu Limited | Relay method and relay apparatus |
| JP2021531562A (ja) * | 2018-07-24 | 2021-11-18 | インターナショナル・ビジネス・マシーンズ・コーポレーションInternational Business Machines Corporation | 大規模エンティティ解決のための２段階計算メモイング |
| JP7355403B2 (ja) | 2018-07-24 | 2023-10-03 | インターナショナル・ビジネス・マシーンズ・コーポレーション | 大規模エンティティ解決のための２段階計算メモイング |
Also Published As
| Publication number | Publication date |
|---|---|
| AU3747599A (en) | 1999-11-01 |
| DE69915462T2 (de) | 2005-03-03 |
| US6128623A (en) | 2000-10-03 |
| JP4489292B2 (ja) | 2010-06-23 |
| DE69915462D1 (de) | 2004-04-15 |
| US6453319B1 (en) | 2002-09-17 |
| WO1999053422A1 (en) | 1999-10-21 |
| EP1072004A1 (en) | 2001-01-31 |
| AU754816B2 (en) | 2002-11-28 |
| EP1072004B1 (en) | 2004-03-10 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4489292B2 (ja) | 高性能オブジェクト・キャッシュ | |
| US6128627A (en) | Consistent data storage in an object cache | |
| US6292880B1 (en) | Alias-free content-indexed object cache | |
| US6209003B1 (en) | Garbage collection in an object cache | |
| US6289358B1 (en) | Delivering alternate versions of objects from an object cache | |
| US6915307B1 (en) | High performance object cache | |
| US6754799B2 (en) | System and method for indexing and retrieving cached objects | |
| US7269608B2 (en) | Apparatus and methods for caching objects using main memory and persistent memory | |
| US9558201B2 (en) | Storage-network de-duplication | |
| US7373520B1 (en) | Method for computing data signatures | |
| US7647417B1 (en) | Object cacheability with ICAP | |
| US6157925A (en) | System and method for caching identification and location information in a computer network | |
| US7552223B1 (en) | Apparatus and method for data consistency in a proxy cache | |
| US8433735B2 (en) | Scalable system for partitioning and accessing metadata over multiple servers | |
| US20020032691A1 (en) | High performance efficient subsystem for data object storage | |
| US6553411B1 (en) | System and method for cache acceleration | |
| US6675214B2 (en) | Method and apparatus for efficient storage and retrieval of objects in and from an object storage device | |
| US7058783B2 (en) | Method and mechanism for on-line data compression and in-place updates | |
| US20160048476A1 (en) | Data managing system, data managing method, and computer-readable, non-transitory medium storing a data managing program | |
| US20100174690A1 (en) | Method, Apparatus and Computer Program Product for Maintaining File System Client Directory Caches with Parallel Directory Writes | |
| US20040148301A1 (en) | Compressed data structure for a database | |
| JPH11296426A (ja) | 記憶域空間の節約方法、オブジェクトの管理方法及び製造物 | |
| US20040148302A1 (en) | Compressed data structure for extracted changes to a database and method of generating the data structure | |
| US7249219B1 (en) | Method and apparatus to improve buffer cache hit rate | |
| US6654856B2 (en) | System and method for managing storage space of a cache |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20060201 |
|
| A711 | Notification of change in applicant |
Free format text: JAPANESE INTERMEDIATE CODE: A711 Effective date: 20070201 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A821 Effective date: 20070201 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20090519 |
|
| A601 | Written request for extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A601 Effective date: 20090818 |
|
| A602 | Written permission of extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A602 Effective date: 20090825 |
|
| A601 | Written request for extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A601 Effective date: 20090918 |
|
| A602 | Written permission of extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A602 Effective date: 20090930 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20091019 |
|
| RD02 | Notification of acceptance of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7422 Effective date: 20091109 |
|
| RD03 | Notification of appointment of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7423 Effective date: 20091109 |
|
| 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: 20100301 |
|
| 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: 20100331 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130409 Year of fee payment: 3 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130409 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20140409 Year of fee payment: 4 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| EXPY | Cancellation because of completion of term |