JP4244572B2 - キャッシュ装置、およびキャッシュデータ管理方法、並びにコンピュータ・プログラム - Google Patents
キャッシュ装置、およびキャッシュデータ管理方法、並びにコンピュータ・プログラム Download PDFInfo
- Publication number
- JP4244572B2 JP4244572B2 JP2002195654A JP2002195654A JP4244572B2 JP 4244572 B2 JP4244572 B2 JP 4244572B2 JP 2002195654 A JP2002195654 A JP 2002195654A JP 2002195654 A JP2002195654 A JP 2002195654A JP 4244572 B2 JP4244572 B2 JP 4244572B2
- Authority
- JP
- Japan
- Prior art keywords
- cache
- data
- data block
- group
- list
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F12/00—Accessing, addressing or allocating within memory systems or architectures
- G06F12/02—Addressing or allocation; Relocation
- G06F12/08—Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
- G06F12/0802—Addressing of a memory level in which the access to the desired data or data block requires associative addressing means, e.g. caches
- G06F12/0806—Multiuser, multiprocessor or multiprocessing cache systems
- G06F12/0813—Multiuser, multiprocessor or multiprocessing cache systems with a network or matrix configuration
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F12/00—Accessing, addressing or allocating within memory systems or architectures
- G06F12/02—Addressing or allocation; Relocation
- G06F12/08—Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
- G06F12/12—Replacement control
- G06F12/121—Replacement control using replacement algorithms
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Mathematical Physics (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
- Information Transfer Between Computers (AREA)
- Memory System Of A Hierarchy Structure (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、キャッシュ装置、およびキャッシュデータ管理方法、並びにコンピュータ・プログラムに関する。さらに詳細には、ネットワークを通じて送受信されるデータ・キャッシュ処理において、キャッシュ装置内のデータ格納領域の効率的利用、およびヒット率向上を実現したキャッシュ装置、およびキャッシュデータ管理方法、並びにコンピュータ・プログラムに関する。
【０００２】
【従来の技術】
近年、インターネット等の通信ネットワークを介した画像、音声データ、各種プログラム等のデータ転送が盛んに行われている。ネットワークを通じてやりとりされるコンテンツの種類は、テキスト・静止画などから、動画・音声などのマルチメディアコンテンツへと移行が進み、コンテンツの大容量化、多種類化が著しく進んでいる。
【０００３】
また、近年は、ブロードバンドによる大容量コンテンツの配信が急速に広まり、これに応じて、ネットワークを介して流通するコンテンツ数が飛躍的に増加している。このようにコンテンツの種類が増加し、大容量コンテンツが増大すると、データ通信量の増大、すなわちネットワークのデータトラフィックの増大という問題が発生する。
【０００４】
ネットワークのデータトラフィックの増大という問題を解決する１つの手法にキャッシュシステムがある。キャッシュシステムは、例えばコンテンツ配信サイトからコンテンツ受信ユーザー側に至るネットワーク経路上にデータ蓄積手段としてのキャッシュを構成したシステムであり、ユーザー側から要求されたデータ（コンテンツ）がキャッシュに蓄積されている場合は、コンテンツ配信サイトから改めてデータ（コンテンツ）を送信することなく、データをキャッシュから取り出してユーザーに提供可能としたものである。
【０００５】
例えば、ユーザーがネットワークを介してコンテンツを取得し、ネットワーク上の一時的な記憶装置（キャッシュ）にコンテンツが格納された場合、キャッシュは一定の決まったルールでコンテンツ格納、削除処理を行なう。例えばキャッシュの記憶容量の越えない範囲で最新のコンテンツが入力される毎に、アクセスの頻度が古いコンテンツを書き換える処理を実行する。通常、このキャッシュにおけるコンテンツ管理ルールはコンテンツの配信側やユーザー側の直接的な管理とは無関係に実行される。
【０００６】
このように、インターネット・キャッシュのデータ領域管理において、データが満杯になると使われなくなったデータ領域を検出し、その領域をキャッシュから削除後に新しいデータで置き換える処理を行なう。これをキャッシュ・リプレースメント（Cache Replacement)と呼ぶ。
【０００７】
従来のインターネット・キャッシュのキャッシュ・リプレースメント（Cache Replacement）は、インターネット等のネットワークに複数のキャッシュが存在する場合であっても、各々の個別のキャッシュ装置内で独自なデータ管理を実行するのが一般的である。最も一般的なキャッシュ・リプレースメントの技法としては、ＬＲＵ(Least Recently Used)によるデータ管理方法がある。
【０００８】
ＬＲＵは、最近使用されていないデータ・ブロックを、ＬＲＵリストの後ろに回し、最近使われたデータ・ブロックを、ＬＲＵリストの先頭に設定するという管理方法であり、新しいデータをキャッシュするために古いデータを削除したい場合には、ＬＲＵリストの後ろにあるブロックから削除することで、キャッシュ内に新たなデータ格納領域を形成する方法である。
【０００９】
図１を参照してＬＲＵ(Least Recently Used)によるデータ管理方法について説明する。管理データとしては、利用頻度順にデータ・ブロックに対応するエントリを並べた（ａ）ＬＲＵリストと、キャッシュの空き領域ブロックを示す（ｂ）フリーブロックリストを有する。新たにキャッシュされたデータは、（ｂ）フリーブロックリストのエントリに示されるポインタによって特定されるメモリ領域としてのデータ格納ブロックに格納され、格納ブロックに対して設定されるブロック情報を格納したエントリが、（ａ）ＬＲＵリストの先頭エントリ１０１として設定される。
【００１０】
データの新規入力（キャッシュ）により、キャッシュのデータ格納領域が満杯になり、以前よりキャッシュされていたデータの中から、いずれかを削除する必要のあるときに、削除されるデータは、（ａ）ＬＲＵリストの末端にある最近使われていないデータ・ブロックと考えられるエントリ１０２に対応するデータ・ブロックであり、削除されたデータ・ブロックをポインタ情報として示すエントリが（ｂ）フリーブロックリストに設定されることで、所定のデータ格納ブロックが空き領域として設定される。
【００１１】
このようなキャッシュ用データ・ブロック管理の方法は、あくまで単独のキャッシュ装置に関する情報を元に処理されていた。また、近隣の複数のキャッシュ装置に対して要求元のキャッシュ装置の持っていないデータを要求するための手段としてＩＣＰ(Internet Cache Protocol : RFC-2186, RFC-2187)が提案されているが、コンテンツファイルのリソース情報としてのＵＲＬ(Uniform Resource Locator)を指定したＵＲＬ単位でのデータ要求処理であることや、複数のキャッシュ間でどのデータを消去または残すべきかの細かい調整機能が無い。このため、たまたま各キャッシュ装置の事情で要求したものと同じデータが他のキャッシュ装置に残っているときに、そのデータをサーバーからダウンロードしてくる代わりに他のキャッシュ装置から持ってくるという処理をしていただけである。
【００１２】
【発明が解決しようとする課題】
本発明は、上述したキャッシュ管理の現状に鑑みてなされたものであり、ネットワークに複数のキャッシュが接続された構成において、効率的なデータ格納領域の利用を実現したキャッシュ装置、およびキャッシュデータ管理方法、並びにコンピュータ・プログラムを提供することを目的とする。
【００１３】
例えば、ネットワーク接続されたキャッシュにおけるデータ領域管理方法において、データの削除を一時保留する「削除保留リスト」を使って管理することや、キャッシュグループという概念を導入することで、ビデオコンテンツのような大きなサイズのコンテンツをキャッシュするときに好適なデータ管理方法を実現する。
【００１４】
キャッシュグループとは、ネットワークに接続したキャッシュ装置のいくつかを組にしたものであり、このグループ内の複数のディスク間で同じコンテンツデータが管理されているものとする。このときに、あるデータ単位ごとにブロック化して各々のブロック単位で削除保留リストを使って管理するときに、ディスク別に削除保留すべき部分が異なるように処理することにより、キャッシュ・リプレースメントによって、ある程度のデータ削除処理が進んだ段階においても、キャッシュグループ内の近隣のキャッシュディスクからデータを集めることによって、元のコンテンツデータを迅速に再生することができる。短いコンテンツデータであれば、コンテンツ別に削除保留にすべきものをディスク別に異なるように設定することで、同様の管理が可能である。
【００１５】
【課題を解決するための手段】
本発明の第１の側面は、
ネットワークを介して受信したデータをキャッシュデータとして格納し、端末からのデータ要求に応じてキャッシュデータを取得して端末に送信するキャッシュ装置であり、
自キャッシュ装置およびネットワークに接続された他のキャッシュ装置によって構成され、コンテンツを構成する複数のデータ・ブロックを分散格納してコンテンツの共同管理を行うキャッシュグループに関するグループ設定情報を格納したテーブルであり、キャッシュグループが共同管理するコンテンツの識別子と、キャッシュグループを構成するキャッシュ装置数：Ｎと、各キャッシュ装置に対応して設定されるグループ・メンバー番号：ｍを格納したキャッシュグループ・テーブルと、
自キャッシュ装置に保持されたデータ・ブロックの管理データであるＬＲＵリストから削除予定データ・ブロックを検索し、削除予定データ・ブロックが前記キャッシュグループにおける自己の記憶担当データである保留データ・ブロックであるか否かを前記キャッシュグループ・テーブルの格納パラメータを適用した算出式の算出結果に基づいて決定し、削除予定データ・ブロックが保留データ・ブロックである場合は削除せずに削除保留リストによる管理対象として自キャッシュ装置に保持し管理する処理を行う制御手段と、
を有することを特徴とするキャッシュ装置にある。
【００１６】
さらに、本発明のキャッシュ装置の一実施態様において、前記制御手段は、共同管理するコンテンツを構成する複数のデータ・ブロックから、自キャッシュ装置における記憶保持対象とする保留データ・ブロックの決定処理を、以下の処理、すなわち、
判定対象データ・ブロックが構成要素となるコンテンツの先頭データ・ブロックからのオフセット情報としてのブロックオフセット番号：Ｃに基づいて、
Ｃ ｍｏｄ Ｎを算出し、
Ｃ ｍｏｄ Ｎ＝０の場合はＶ＝Ｎ、
Ｃ ｍｏｄ Ｎ≠０の場合はＶ＝（Ｃ ｍｏｄ Ｎ）として、
Ｖ＝ｍであるか否かを判定し、
Ｖ＝ｍである場合に、該データ・ブロックを保留データ・ブロックとして決定する処理、
を実行する構成であることを特徴とする。
【００１７】
さらに、本発明のキャッシュ装置の一実施態様において、前記制御手段は、記憶手段に格納したデータ・ブロックについての管理リストであるＬＲＵリストからの排除対象エントリに対応するデータ・ブロックについて、前記キャッシュグループによる共同管理が可能か否かをキャッシュ装置間のメッセージ送受信により判定し、共同管理可能であると判定した場合に、前記キャッシュグループ・テーブルを生成する構成であることを特徴とする。
【００１８】
さらに、本発明のキャッシュ装置の一実施態様において、前記制御手段は、記憶手段に格納したデータ・ブロックについての管理リストであるＬＲＵリストからの排除対象エントリに対応するデータ・ブロックについて、前記キャッシュグループ・テーブルの格納情報に基づいて、コンテンツを構成する複数のデータ・ブロック中から、自キャッシュ装置における記憶保持データとしての保留データ・ブロックを決定し、決定した保留データ・ブロック以外のデータ・ブロックについては、削除の許容されるデータ・ブロック管理リストとしてのフリーブロックリストにより管理する構成であることを特徴とする。
【００１９】
さらに、本発明のキャッシュ装置の一実施態様において、前記削除保留リストは、データ・ブロックの保存優先度に応じた複数のリストによって構成され、前記制御手段は、データ・ブロックの保存優先度を判定し、該判定結果に基づいて選択した削除保留リストに対して前記管理データ・ブロックに対応するエントリの設定を行なう構成であることを特徴とする。
【００２０】
さらに、本発明のキャッシュ装置の一実施態様において、前記制御手段は、端末からのコンテンツ取得要求が、前記キャッシュグループによる共同管理対象のコンテンツ取得要求である場合に、取得要求対象のコンテンツを構成するデータ・ブロックが前記キャッシュグループを構成するいずれのキャッシュ装置の保持対象データ・ブロックであるかを判定し、該判定結果に基づいてデータ・ブロックを自キャッシュ装置または、前記キャッシュグループを構成する他のキャッシュ装置から取得する処理を実行する構成であることを特徴とする。
【００２１】
さらに、本発明のキャッシュ装置の一実施態様において、前記制御手段は、取得要求対象のデータ・ブロックが構成要素となるコンテンツの先頭データ・ブロックからのオフセット情報としてのブロックオフセット番号：Ｃに基づいて、
Ｃ ｍｏｄ Ｎを算出し、
Ｃ ｍｏｄ Ｎ＝０の場合はＶ＝Ｎ、
Ｃ ｍｏｄ Ｎ≠０の場合はＶ＝（Ｃ ｍｏｄ Ｎ）として、
Ｖ＝ｍを算出し、
算出したｍをグループ・メンバー番号として有するキャッシュ装置からデータ・ブロックの取得処理を実行する構成であることを特徴とする。
【００２２】
さらに、本発明の第２の側面は、
ネットワークを介して受信したデータをキャッシュデータとして格納し、端末からのデータ要求に応じてキャッシュデータを取得して端末に送信するキャッシュ装置におけるキャッシュデータ管理方法であり、
前記キャッシュ装置の制御手段が、自キャッシュ装置に保持されたデータ・ブロックの管理データであるＬＲＵリストから削除予定データ・ブロックを検索するステップと、
前記制御手段が、自キャッシュ装置およびネットワークに接続された他のキャッシュ装置によって構成され、コンテンツを構成する複数のデータ・ブロックを分散格納してコンテンツの共同管理を行うキャッシュグループに関するグループ設定情報を格納したテーブルであり、キャッシュグループが共同管理するコンテンツの識別子と、キャッシュグループを構成するキャッシュ装置数：Ｎと、各キャッシュ装置に対応して設定されるグループ・メンバー番号：ｍを格納したキャッシュグループ・テーブルの格納パラメータを適用した算出式の算出結果に基づいて、前記削除予定データ・ブロックが前記キャッシュグループにおける自己の記憶担当データである保留データ・ブロックであるか否かを決定する保留データ・ブロック決定ステップと、
前記制御手段が、前記削除予定データ・ブロックが保留データ・ブロックである場合は削除せずに削除保留リストによる管理対象として自キャッシュ装置に保持し管理する処理を行うステップと、
を有することを特徴とするキャッシュデータ管理方法にある。
【００２３】
さらに、本発明のキャッシュデータ管理方法の一実施態様において、前記保留データ・ブロック決定ステップは、共同管理するコンテンツを構成する複数のデータ・ブロックから、自キャッシュ装置における記憶保持対象とする保留データ・ブロックの決定処理を、以下の処理、すなわち、
判定対象データ・ブロックが構成要素となるコンテンツの先頭データ・ブロックからのオフセット情報としてのブロックオフセット番号：Ｃに基づいて、
Ｃ ｍｏｄ Ｎを算出し、
Ｃ ｍｏｄ Ｎ＝０の場合はＶ＝Ｎ、
Ｃ ｍｏｄ Ｎ≠０の場合はＶ＝（Ｃ ｍｏｄ Ｎ）として、
Ｖ＝ｍであるか否かを判定し、
Ｖ＝ｍである場合に、該データ・ブロックを保留データ・ブロックとして決定する処理を実行することを特徴とする。
【００２４】
さらに、本発明のキャッシュデータ管理方法の一実施態様において、前記キャッシュデータ管理方法は、さらに、前記制御手段が、記憶手段に格納したデータ・ブロックについての管理リストであるＬＲＵリストからの排除対象エントリに対応するデータ・ブロックについて、前記キャッシュグループによる共同管理が可能か否かをキャッシュ装置間のメッセージ送受信により判定し、共同管理可能であると判定した場合に、前記キャッシュグループ・テーブルを生成する処理を実行することを特徴とする。
【００２５】
さらに、本発明のキャッシュデータ管理方法の一実施態様において、前記キャッシュデータ管理方法は、さらに、前記制御手段が、記憶手段に格納したデータ・ブロックについての管理リストであるＬＲＵリストからの排除対象エントリに対応するデータ・ブロックについて、前記キャッシュグループ・テーブルの格納情報に基づいて、コンテンツを構成する複数のデータ・ブロック中から、自キャッシュ装置における記憶保持データとしての保留データ・ブロックを決定し、決定した保留データ・ブロック以外のデータ・ブロックについては、削除の許容されるデータ・ブロック管理リストとしてのフリーブロックリストにより管理するステップを含むことを特徴とする。
【００２６】
さらに、本発明のキャッシュデータ管理方法の一実施態様において、前記削除保留リストは、データ・ブロックの保存優先度に応じた複数のリストによって構成され、前記キャッシュデータ管理方法は、さらに、前記制御手段が、データ・ブロックの保存優先度を判定し、該判定結果に基づいて選択した削除保留リストに対して前記管理データ・ブロックに対応するエントリの設定を行なうステップを含むことを特徴とする。
【００２７】
さらに、本発明のキャッシュデータ管理方法の一実施態様において、前記キャッシュデータ管理方法は、さらに、前記制御手段が、端末からのコンテンツ取得要求が、前記キャッシュグループによる共同管理対象のコンテンツ取得要求である場合に、取得要求対象のコンテンツを構成するデータ・ブロックが前記キャッシュグループを構成するいずれのキャッシュ装置の保持対象データ・ブロックであるかを判定し、該判定結果に基づいてデータ・ブロックを自キャッシュ装置または、前記キャッシュグループを構成する他のキャッシュ装置から取得するデータ・ブロック取得処理を実行するステップを含むことを特徴とする。
【００２８】
さらに、本発明のキャッシュデータ管理方法の一実施態様において、前記キャッシュグループ・テーブルは、キャッシュグループによって共同管理するコンテンツの識別子と、キャッシュグループを構成するキャッシュ装置数：Ｎと、各キャッシュ装置に対応して設定されるグループ・メンバー番号：ｍとを有し、前記データ・ブロック取得処理は、取得要求対象のデータ・ブロックが構成要素となるコンテンツの先頭データ・ブロックからのオフセット情報としてのブロックオフセット番号：Ｃに基づいて、
Ｃ ｍｏｄ Ｎを算出し、
Ｃ ｍｏｄ Ｎ＝０の場合はＶ＝Ｎ、
Ｃ ｍｏｄ Ｎ≠０の場合はＶ＝（Ｃ ｍｏｄ Ｎ）として、
Ｖ＝ｍを算出し、
算出したｍをグループ・メンバー番号として有するキャッシュ装置からデータ・ブロックを取得する処理として実行することを特徴とする。
【００２９】
さらに、本発明の第３の側面は、
ネットワークを介して受信したデータをキャッシュデータとして格納し、端末からのデータ要求に応じてキャッシュデータを取得して端末に送信するキャッシュ装置のプログラム実行部である制御手段にキャッシュデータ管理処理を実行させるコンピュータ・プログラムであり、
自キャッシュ装置に保持されたデータ・ブロックの管理データであるＬＲＵリストから削除予定データ・ブロックを検索させるステップと、
自キャッシュ装置およびネットワークに接続された他のキャッシュ装置によって構成され、コンテンツを構成する複数のデータ・ブロックを分散格納してコンテンツの共同管理を行うキャッシュグループに関するグループ設定情報を格納したテーブルであり、キャッシュグループが共同管理するコンテンツの識別子と、キャッシュグループを構成するキャッシュ装置数：Ｎと、各キャッシュ装置に対応して設定されるグループ・メンバー番号：ｍを格納したキャッシュグループ・テーブルの格納パラメータを適用した算出式の算出結果に基づいて、前記削除予定データ・ブロックが前記キャッシュグループにおける自己の記憶担当データである保留データ・ブロックであるか否かを決定させる保留データ・ブロック決定ステップと、
前記削除予定データ・ブロックが保留データ・ブロックである場合は削除せずに削除保留リストによる管理対象として自キャッシュ装置に保持し管理する処理を行わせるステップと、
を実行させることを特徴とするコンピュータ・プログラムにある。
【００３０】
【作用】
本発明の構成によれば、ネットワーク接続されたキャッシュ装置におけるキャッシュ・リプレースメント処理において、削除保留ブロックに関するリストを保持して、キャッシュグループ内のキャッシュ装置ごとに各々削除保留されるデータ・ブロックが異なるようにデータ管理を行なう構成としたので、各キャッシュ装置が単独でキャッシュ・リプレースメントの管理をしている場合に比べて効率的な記憶領域の利用が図れ、また、端末からのデータ要求に応じて複数のキャッシュ装置に記憶したデータ・ブロックを集めて送信することが可能となり、ネットワークトラフィックの軽減、キャッシュ装置のヒット率の向上が実現される。
【００３１】
さらに、本発明の多段の削除保留リストを適用したキャッシュ装置構成によれば、保持重要度の高いデータが削除されずにキャッシュに残る可能性が高くなるため、さらに、キャッシュヒット率の向上を達成することが可能となる。
【００３２】
なお、本発明のコンピュータ・プログラムは、例えば、様々なプログラム・コードを実行可能な汎用コンピュータ・システムに対して、コンピュータ可読な形式で提供する記憶媒体、通信媒体、例えば、ＣＤやＦＤ、ＭＯなどの記録媒体、あるいは、ネットワークなどの通信媒体によって提供可能なコンピュータ・プログラムである。このようなプログラムをコンピュータ可読な形式で提供することにより、コンピュータ・システム上でプログラムに応じた処理が実現される。
【００３３】
本発明のさらに他の目的、特徴や利点は、後述する本発明の実施例や添付する図面に基づくより詳細な説明によって明らかになるであろう。なお、本明細書においてシステムとは、複数の装置の論理的集合構成であり、各構成の装置が同一筐体内にあるものには限らない。
【００３４】
【発明の実施の形態】
以下、本発明のキャッシュ装置、およびキャッシュデータ管理方法について、図面を参照して、詳細に説明する。
【００３５】
［キャッシュ装置および処理概要］
図２は、本発明のキャッシュ装置を適用可能なネットワークシステムの全体構成例を示す図である。この図２に示す構成は、一般的なインターネット・キャッシュ装置、サーバー装置、端末装置から成るシステムと同様である。本発明のキャッシュ装置は、従来のネットワークシステム構成での適用が可能であり、ネットワーク内の複数のキャッシュ装置でグループ設定を行ない、グループ内においてキャッシュデータの管理を実行する。
【００３６】
各キャッシュ装置１（２１１）〜キャッシュ装置４（２１４）は、お互いにネットワークで接続されていると共に、コンテンツサーバー２０１から配信されるデータ（コンテンツ）を一時的に保存する機能を持つ。キャッシュ装置２１１〜２１４のネットワーク下流側には、コンテンツを受信する複数の端末装置、例えばユーザーＰＣ、携帯通信端末等の各種端末を接続できる構成となっている。
【００３７】
キャッシュ装置１（２１１）には、コンテンツ受信端末としての端末２２１ａ〜ｃ・・、キャッシュ装置２（２１２）には、端末２３１ａ〜ｃ・・、キャッシュ装置３（２１３）には、端末２４１ａ〜ｂ・・、キャッシュ装置４（２１４）には、端末２５１ａ〜ｃ・・がそれぞれ接続される。
【００３８】
ある端末からコンテンツデータの取得要求があると、コンテンツサーバー２０１からデータを読み出すか、中間にあるキャッシュ装置からデータを読み出す。端末からのコンテンツ要求は、例えば、コンテンツファイルのリソース情報としてのＵＲＬ(Uniform Resource Locator)を指定したコンテンンツ取得要求メッセージの送信によって行なわれる。
【００３９】
キャッシュ装置に端末から取得要求のあったコンテンツのＵＲＬに対応するデータが保存されている場合は、このキャッシュ装置からデータを読み出す。キャッシュからのデータ読み出しにより、コンテンツサーバー２０１からキャッシュ装置間におけるデータ転送が省略可能となり、ネットワーク上のデータトラフィックが緩和される。
【００４０】
本発明の構成では、ネットワークで接続された複数のキャッシュ装置、例えば、図２に示すキャッシュ装置１（２１１）〜キャッシュ装置４（２１４）を「キャッシュグループ」としてグループ化し、これら複数のキャッシュ装置１（２１１）〜キャッシュ装置４（２１４）間で、コンテンツの共同管理、すなわち複数のキャッシュ装置１（２１１）〜キャッシュ装置４（２１４）でのコンテンツの分散保持を実行する。以下、本発明におけるキャッシュ管理の構成、および方法について説明する。
【００４１】
図２のキャッシュグループに属する４つのキャッシュ装置１（２１１）〜キャッシュ装置４（２１４）に、例えば図３に示すように、同じコンテンツデータがキャッシュされているとする。コンテンツは、データ・ブロック１〜７からなる。図３のように各キャッシュ装置１（２１１）〜キャッシュ装置４（２１４）で同じデータ・ブロック１〜７を保存しているものとする。これらのデータ・ブロック１〜７は、それぞれのキャッシュ装置１（２１１）〜キャッシュ装置４（２１４）がそれぞれの接続端末からの要求に応じて、コンテンツサーバー２０１から受信し、一時記憶しているデータ、すなわちキャッシュデータである。
【００４２】
もし、従来と同様、個々のキャッシュ装置が単独で、キャッシュ・リプレースメント処理を実行すると、個々のキャッシュ装置は、新しく記憶手段に格納、すなわちキャッシュすべきデータを保存するために、端末からの取得要求頻度の低いデータ・ブロックを削除することになる。この削除したデータを再度提供する場合には、既にキャッシュ装置にデータが無いために、コンテンツサーバー２０１へデータを取りに行くことになる。
【００４３】
本発明のキャッシュ装置は、複数のキャッシュ装置１（２１１）〜キャッシュ装置４（２１４）で構成するキャッシュグループで、データを共同管理する。
【００４４】
本発明のキャッシュデータ管理方法では、同じコンテンツデータを持つ複数のキャッシュ装置を使ってキャッシュをグループ化してキャッシュするデータを管理する。本発明におけるキャッシュ装置のキャッシュ・リプレースメントは、キャッシュグループを構成する複数のキャッシュ装置１（２１１）〜キャッシュ装置４（２１４）を単位として実行する。
【００４５】
キャッシュグループを構成するキャッシュ装置ごとに削除されずに残っているデータが異なるデータとなるように制御されてデータ削除を実行する。従って、キャッシュ装置におけるデータ格納領域の効率的利用が可能となる。さらに、端末からのデータ要求に応答して、キャッシュグループの複数キャッシュ装置から各格納データを転送して端末に対する出力が可能となり、総合的にキャッシュ装置のヒット率を向上させることが可能となる。
【００４６】
具体例について、図を参照して説明する。図３のように、キャッシュグループを構成する複数のキャッシュ装置１（２１１）〜キャッシュ装置４（２１４）の各々が、同じコンテンツデータ・ブロック１〜７を格納していた場合、キャッシュグループを単位としたデータ管理により、キャッシュ装置ごとに削除されずに残っているデータが異なるデータとなるようにデータ削除、すなわちキャッシュ・リプレースメントを実行する。
【００４７】
このキャッシュグループを単位としたキャッシュ・リプレースメントの結果、図４に示すように、キャッシュ装置１（２１１）は、データ・ブロック１，５をキャッシュデータとして保持し、データ・ブロック２，３，４，６，７をフリーリスト（削除データ・ブロックに相当）に移動する。キャッシュ装置２（２１２）は、データ・ブロック２，６をキャッシュデータとして保持し、データ・ブロック１，３，４，５，７をフリーリストに移動する。キャッシュ装置３（２１３）は、データ・ブロック３，７をキャッシュデータとして保持し、データ・ブロック１，２，４，５，６をフリーリストに移動する。キャッシュ装置４（２１４）は、データ・ブロック４をキャッシュデータとして保持し、データ・ブロック１，２，３，５，６，７をフリーリストに移動する。
【００４８】
このように、キャッシュグループを構成する複数のキャッシュ装置１（２１１）〜キャッシュ装置４（２１４）全体としてキャッシュ・リプレースメントを行ない、コンテンツ共同管理を実行する。キャッシュグループ単位でのキャッシュ・リプレースメント処理の具体的処理態様について説明する。
【００４９】
あらかじめ決めた一定の時間間隔ごとに、各キャッシュ装置が独自に持っているＬＲＵリスト（図１参照）から、キャッシュ・リプレースメントによって近々に消去される可能性のある順にブロックをスキャンし、その消去予定のブロックに対応するコンテンツを持つキャッシュ装置が近隣にあるかどうかを問い合わせ、さらに、問い合わせ先のキャッシュ装置が消去予定のコンテンツを持っている場合には、相互にキャッシュグループを組めるか否かを確認する。
【００５０】
このような問い合わせに適用する送受信メッセージは、例えばネットワーク接続されたキャッシュ間のメッセージ送受信プロトコルとして定義されたＩＣＰ（Internet Cache Protocol）プロトコルが適用可能である。従来のＩＣＰの仕様中には、キャッシュグループに参加できるかどうかの確認機能についてまで規定されていないが、例えば、ＩＣＰ中のオペコードの１つとして定義されているＩＰ＿ＯＰ＿ＱＵＥＲＹメッセージ中のＯＰＴＩＯＮ Ｆｌａｇを拡張して、キャッシュグループに参加できるかどうかの確認メッセージを送受信することが可能である。
【００５１】
ネットワーク接続されたキャッシュ間のメッセージ送受信プロトコルとして定義されたＩＣＰ（Internet Cache Protocol）プロトコルのフォーマットを図５（ａ）に、ＩＣＰ中のオペコードの１つとして定義されているＩＰ＿ＯＰ＿ＱＵＥＲＹメッセージフォーマットを図５（ｂ）に示す。ＩＣＰフォーマットは、図５（ａ）に示すように、オペコード、バージョン、メッセージ長、リクエストＮｏ．、オプション、オプションデータ、送信側ホストアドレス、ペイロードの各データフィールドを有する。
【００５２】
特定のコンテンツデータを持っているか、およびキャッシュグループに参加できるかを、近隣のキャッシュ装置に問い合わせる際には、コンテンツファイルのリソース情報としてのＵＲＬ(Uniform Resource Locator)を指定して、近隣キャッシュ装置に問い合わせメッセージを送信する。この問い合わせメッセージの１形態として、ＩＣＰ（Internet Cache Protocol）プロトコルのＯＰＴＩＯＮ Ｆｌａｇの拡張を行ない、ＩＣＰ＿ＯＰ＿ＱＵＥＲＹで、コンテンツファイルのリソース情報としてのＵＲＬを指定するとともに、このコンテンツについてキャッシュグループのメンバーとして参加可能かの確認の意味を含むフラグ（例えば、０ｘ２０００００００（ＩＣＰ＿ＦＬＡＧ＿ＧＲＯＵＰ＿ＲＥＱ））を追加する。なお、この問い合わせメッセージは、この手法に限らず、他のフォーマット、プロトコルを使用することも可能である。
【００５３】
なお、このコンテンツ保持問い合わせは、問い合わせを行なうキャッシュ装置が、マルチキャスト（Ｍｕｌｔｉｃａｓｔ）を適用して、複数の近隣キャッシュ装置に一度に問い合わせることも可能である。
【００５４】
なお、本発明において、「近隣のキャッシュ装置」とは、ある１つのキャッシュ装置に対してキャッシュグループとして組む可能性のあるキャッシュ装置の候補であり、例えばデータ送受信処理を、あらかじめ定めた許容時間内に実行可能なキャッシュ装置として設定される。
【００５５】
「近隣のキャッシュ装置」の具体的な設定態様としては、例えば、キャッシュ装置の設定ファイルにキャッシュグループを組める可能性のある複数のキャッシュ装置を予め登録し、これらの登録キャッシュ装置にｐｉｎｇなどを使ってキャッシュ装置間のＲＴＴ（Ｒｏｕｎｄ Ｔｒｉｐ Ｔｉｍｅ）を測定し、ＲＴＴが許容時間範囲内にある複数のキャッシュ装置を「近隣のキャッシュ装置」として設定することが可能である。
【００５６】
キャッシュグループの設定を実行するキャッシュ装置は、「近隣のキャッシュ装置」に関するリストを保持する。リストは、対象となるキャッシュ装置に関するデータとして、ホスト名、ＩＰアドレス、ＩＣＰポート番号を保存したリストである。
【００５７】
キャッシュ装置リスト構成例を図６に示す。キャッシュ装置リストは、図６に示すように、近隣のキャッシュ装置として設定されたキャッシュ装置に関するデータとして、ホスト名、ＩＰアドレス、ＩＣＰポート番号を保存したリストである。
【００５８】
コンテンツ保持の有無および、グループ参加可否についての問い合わせを近隣のキャッシュ装置に対して実行しようとするキャッシュ装置は、例えば、ＩＣＰ＿ＯＰ＿ＱＵＥＲＹで、あるコンテンツデータに対応するＵＲＬを指定して問い合わせメッセージをブロードキャスト、マルチキャスト等により送信する。問い合わせを実行したキャッシュ装置は、問い合わせメッセージに対する答えを待つことになる。
【００５９】
しかし、応答を無限に待つことはできないし、マルチキャストで問い合わせした場合は、どれだけ返事が戻るか不明であるため、あらかじめ決めた一定時間の範囲内において、ヒット（ＨＩＴ）応答、すなわち問い合わせに係るＵＲＬに関連するコンテンツデータを持っているとの応答が何処からいくつ戻るかをカウントし内部のキャッシュグループ・テーブル（対象とするコンテンツデータの識別子（ＵＲＬ，コンテンツＩＤ等）、グループの構成メンバー数、グループＩＤ、キャッシュグループを構成するメンバーの（メンバー番号とＩＰアドレスリストの対データ））に記憶する。
【００６０】
応答メッセージは、問い合わせに係るＵＲＬに関連するコンテンツデータを持っているとの応答として、例えばＩＣＰメッセージのＩＣＰ＿ＯＰ＿ＨＩＴ、また、コンテンツデータを持っていない旨の応答として、ＩＣＰ＿ＯＰ＿ＭＩＳＳを用いた応答メッセージが適用可能である。
【００６１】
上述の問い合わせメッセージを受信したキャッシュ装置は、問い合わせを送信してきたキャッシュ装置とのキャッシュグループを構成するメンバーになることを承諾し、さらに、キャッシュグループ形成までの間、問い合わせのあったコンテンツに対応するデータ・ブロックを削除せずに保持できる能力を持つ場合に、ＨＩＴ応答を返す。
【００６２】
問い合わせメッセージを送信したキャッシュ装置と、ＨＩＴ応答を返した１以上のキャッシュ装置とによって、問い合わせメッセージの指定コンテンツに関するキャッシュグループを構成する。
【００６３】
問い合わせメッセージを送信し、応答メッセージを受信したキャッシュ装置が、１以上のＨＩＴ応答を受信してキャッシュグループを設定した場合は、キャッシュグループを構成するキャッシュ装置数（Ｎ），当該キャッシュ装置のキャッシュグループを構成するキャッシュ装置（メンバー）識別子としてのグループ・メンバー番号（ｍ）、キャッシュグループでの処理対象コンテンツデータ識別子（ＣＩＤ）などのグループ設定情報を、キャッシュグループを構成する各キャッシュ装置に伝える。
【００６４】
なお、キャッシュ装置（メンバー）識別子としてのグループ・メンバー番号（ｍ）は、キャッシュ装置のＩＰアドレスに対応して設定され、キャッシュグループを構成する全てのキャッシュ装置（メンバー）は、キャッシュグループを構成する他の全てのキャッシュ装置（メンバー）識別子としてのグループ・メンバー番号（ｍ）とＩＰアドレスの対応情報を取得する。
【００６５】
グループ設定情報の伝達には、上述の問い合わせメッセージと同様、ＩＣＰが適用可能である。例えば、ＩＣＰにおいて、情報通知のためのＩＣＰ＿ＯＰ＿ＮＯＴＩＦＹのようなオペコードを独自に追加し、ペイロード部分に図７のようなキャッシュ装置（メンバー）のグループ・メンバー番号と、ＩＰアドレスデータを格納してキャッシュグループを構成する各キャッシュ装置に送信し、通知することになる。なお、図７に示す例は、ＩＰアドレスとしてＩＰｖ４を適用した例である。
【００６６】
図７に示すように、ペイロード部には、キャッシュグループを構成する全て（Ｎ）のキャッシュ装置（メンバー）のグループ・メンバー番号（キャッシュ・メンバー＃１〜＃Ｎ）とＩＰアドレス情報が格納される。これらの情報を受領することにより、キャッシュグループを構成する全てのキャッシュ装置（メンバー）は、キャッシュグループを構成する他の全てのキャッシュ装置（メンバー）のグループ・メンバー番号とＩＰアドレスの対応を知ることができる。
【００６７】
グループ設定情報を伝達したキャッシュ装置、およびグループ設定情報を伝達された、キャッシュグループに属するキャッシュ装置は、図８に示すようなグループ設定情報を格納したキャッシュグループ・テーブルを自己の管理情報としてメモリに格納する。
【００６８】
キャッシュグループ・テーブルには、上述のグループ設定情報に基づいて取得される情報、すなわち、設定キャッシュグループにおいて共同管理するコンテンツの識別子、キャッシュグループの構成キャッシュ装置数［Ｎ］、キャッシュグループの識別子（ＩＤ）、およびキャッシュグループのメンバーリストとして、メンバー番号とＩＰアドレスの対応データとが格納される。
【００６９】
このようにして作成したキャッシュグループを構成する各キャッシュ装置は、単独のデータ（コンテンツ）管理ではなく、グループ全体でのコンテンツデータの管理を行なう。以下、キャッシュグループ内の各キャッシュ装置におけるコンテンツ管理方法について説明する。
【００７０】
キャッシュグループ内の各キャッシュ装置は、図９に示すように、利用頻度順にデータ・ブロックを並べた（ａ）ＬＲＵリストと、キャッシュの空き領域ブロックをポインタ情報として持つ（ｃ）フリーブロックリスト、さらに、（ｂ）削除保留リストを有する。
【００７１】
削除保留リストとは、ＬＲＵリストから排除、例えば削除対象ブロックとなったデータ・ブロックの内、一時的に削除保留状態に設定したデータ・ブロックを管理するリストである。ＬＲＵリストから排除するエントリに対応するデータ・ブロックを削除対象として、フリーブロックリストで管理するか、あるいは削除を保留すべきブロックとして、削除保留リストで管理するかの判定は、以下の処理手順によって行なう。
【００７２】
削除保留状態に設定するか否かの判定は、以下の処理手順について説明する。判定対象コンテンツの先頭からのブロックオフセット番号をＣ、キャッシュグループを構成するキャッシュ装置数をＮ、キャッシュグループにおける自己に設定されたグループ・メンバー番号をｍとしたときに、
（１） Ｃ ｍｏｄ Ｎを算出する。
（２） Ｃ ｍｏｄ Ｎ＝０の場合はＶ＝Ｎ、
Ｃ ｍｏｄ Ｎ≠０の場合はＶ＝（Ｃ ｍｏｄ Ｎ）として、
（３） Ｖ＝ｍであれば、削除保留状態に設定する。
Ｖ≠ｍであれば、削除保留状態に設定せず削除する。
【００７３】
上述の処理を、キャッシュグループを構成するキャッシュ装置の各々で実行することにより、先に図４を参照して説明したように、キャッシュ装置間で、重複の無いデータ・ブロックの格納構成が実現される。
【００７４】
すなわち、ｍ＝１であるキャッシュ装置１（２１１）は、データ・ブロック１，５を削除保留状態として保持し、削除保留リストの管理ブロックとし、データ・ブロック２，３，４，６，７を削除対象としてフリーリストで管理する。ｍ＝２であるキャッシュ装置２（２１２）は、データ・ブロック２，６を削除保留状態として保持し、削除保留リストの管理ブロックとし、データ・ブロック１，３，４，５，７をフリーリストで管理する。ｍ＝３であるキャッシュ装置３（２１３）は、データ・ブロック３，７を削除保留状態として保持し、削除保留リストの管理ブロックとし、データ・ブロック１，２，４，５，６をフリーリストで管理する。ｍ＝４であるキャッシュ装置４（２１４）は、データ・ブロック４を削除保留状態として保持し、削除保留リストの管理ブロックとし、データ・ブロック１，２，３，５，６，７をフリーリストで管理する構成が実現される。
【００７５】
上述の処理の詳細について、キャッシュグループ内の各キャッシュ装置の有するＬＲＵリスト、削除保留リスト、フリーブロックリストの内部構造を参照しながら説明する。
【００７６】
まず、ＬＲＵリストの構成について図１０を参照して説明する。図１０に示すように、各キャッシュ装置は、自己のキャッシュデータを格納する記憶手段としてのデータ格納領域３２０、およびデータ格納領域に格納したデータに対するリストとしてのＬＲＵリスト３１０を有する。
【００７７】
ＬＲＵリスト３１０は、各データ・ブロックに対応付けて生成される。ここでは、（ａ）〜（ｐ）のリストデータ（エントリ）が各データ・ブロックに対応付けられて保持されている。ＬＲＵリストの内部構造は、図１０に示すように、データ・ブロックヘのポインタ３１１、コンテンツ識別子３１２、ブロックオフセット３１３、ＬＲＵリストの前リストデータ（エントリ）のポインタ３１４、ＬＲＵリストの後続リストデータ（エントリ）のポインタ３１５を有する。
【００７８】
データ・ブロックヘのポインタ３１１は、各リストデータに対応する実コンテンツデータ・ブロックの、データ格納領域３２０における格納アドレスを示す。コンテンツ識別子３１２は、例えばＵＲＬ、または各データ・ブロックの識別データによって構成されるコンテンツＩＤである。ブロックオフセット３１３は、各コンテンツデータ・ブロックのコンテンツ先頭からのオフセットを示す。
【００７９】
オフセットは、例えばデータ格納領域におけるアドレス差分を用いることも可能であるが、ここでは、ある大きさごとにデータを区切ったブロックという単位で管理することにすると、先頭からのブロックオフセット番号Ｃの値が入る。（ａ）のリストに対して設定されるブロックオフセットは１、（ｂ）のリストに対して設定されるブロックオフセットは２となり、（ｐ）のリストに対して設定されるブロックオフセットは、コンテンツデータのブロックサイズがＮブロック分あるとすると、Ｎとなる。このようにブロックオフセットは、コンテンツ毎の、コンテンツ先頭からの位置識別データとしてのブロックオフセット番号Ｃとして設定される。
【００８０】
ＬＲＵリストの前リストデータ（エントリ）のポインタ３１４、ＬＲＵリスト後リストデータ（エントリ）のポインタ３１５は、それぞれ、リストの前後のエントリに対するポインタを示すデータである。従って、リスト先頭のリストデータ（ａ）の前リストデータのポインタはＮＵＬＬ、リスト最後尾のリストデータ（ｐ）の後リストデータのポインタもＮＵＬＬとして設定される。
【００８１】
ＬＲＵリスト中の各エントリが持つデータ・ブロックへのポインタに対応するコンテンツの識別子および先頭からのブロックオフセット番号：Ｃは、このエントリ中のデータを読むことで簡単に知ることが出来る。
【００８２】
次に、削除保留リストの構成について、図１１を参照して説明する。削除保留リストとは、前述したように、ＬＲＵリストで削除対象ブロックとなったデータ・ブロックの内、一時的に削除保留状態に設定したデータ・ブロックを管理するリストである。
【００８３】
図１１に示すように、キャッシュ装置の保有する削除保留リスト３３０は、削除保留状態に設定したデータ・データ・ブロックに対応付けて生成される。ここでは、（ａ）〜（ｐ）のリストデータ（エントリ）が削除保留状態に設定したデータ・データ・ブロックに対応付けられて保持されている。削除保留リストの内部構造は、図１１に示すように、データ・ブロックヘのポインタ３３１、コンテンツ識別子３３２、ブロックオフセット３３３、設定されたキャッシュグループのグループ識別子（ＧＰ）３３４、削除保留リストの前リストデータ（エントリ）のポインタ３３５、削除保留リストの後続リストデータ（エントリ）のポインタ３３６を有する。
【００８４】
キャッシュ装置の保有する削除保留リスト３３０の格納データは、先に説明したＬＲＵリストの格納データにグループ識別子（ＧＰ）３３４を付加した構成となる。グループ識別子（ＧＰ）３３４は、キャッシュグループ作成時に設定されるキャッシュグループを識別するグループＩＤである。キャッシュグループを設定したキャッシュ装置によって設定され、キャッシュグループを構成する他のキャッシュ装置は、キャッシュグループを設定したキャッシュ装置から送信されるグループ設定情報により通知され、キャッシュグループ・テーブル（図８参照）に記録されたＩＤである。
【００８５】
次に、フリーブロックリストの構成について、図１２を参照して説明する。フリーブロックリストとは、前述したように、ＬＲＵリストで削除対象ブロックとなったデータ・ブロックの内、削除保留状態に設定されずに削除対象となったデータ・ブロック、および削除保留状態に一旦、設定されたものの、その後、削除対象となったデータ・ブロックに対応する管理リストである。
【００８６】
図１２に示すように、キャッシュ装置の保有するフリーブロックリスト３５０は、データ格納領域３２０のデータ格納ブロック中、上書き、消去可能なデータ・ブロックへのポインタ３５１を持ち、フリーブロックリストの前リストデータ（エントリ）のポインタ３５２、フリーブロックリストの後続リストデータ（エントリ）のポインタ３５３を有する。
【００８７】
次に、キャッシュグループを構成する各キャッシュ装置において、新規入力データが発生し、データ・ブロックを削除保留リスト、あるいはフリーブロックリストの管理データに移行する際の処理手順について説明する。
【００８８】
まず、キャッシュ装置は、ＬＲＵリストから処理対象とするデータ・ブロックに対応するエントリ（リストデータ）を抽出し、抽出したＬＲＵリストのエントリからブロックオフセット番号：Ｃ（図１０：ブロックオフセット３１３）を読み出す。
【００８９】
次に、キャッシュ装置は、ブロックオフセット番号：Ｃの値に基づいて、上述した処理を実行する。すなわち、
（１） Ｃ ｍｏｄ Ｎを算出する。
（２） Ｃ ｍｏｄ Ｎ＝０の場合はＶ＝Ｎ、
Ｃ ｍｏｄ Ｎ≠０の場合はＶ＝（Ｃ ｍｏｄ Ｎ）、
として、
（３）Ｖ＝ｍであれば、削除保留状態に設定、すなわち、
対応するデータ・ブロックの管理リストデータを削除保留リストに移動する。このデータ・ブロックは、データ格納領域において消去されずに保持される。
（３’）一方、Ｖ≠ｍであれば、削除保留状態に設定しない。すなわち、
対応するデータ・ブロックの管理リストデータをフリーブロックリストに移動する。このデータ・ブロックは、データ格納領域において消去、上書き可能ブロックとして設定されることになる。
【００９０】
Ｖ＝ｍである場合は、設定したキャッシュグループにおいて、自装置がそのデータ・ブロックを保留すべきであると判定し、ＬＲＵリストからの削除予定エントリを削除保留リストに移動し、コンテンツデータ・ブロックを削除することなく、メモリに残し、削除保留リストでの管理を実行する。また、Ｖ≠ｍの場合は、設定したキャッシュグループにおいて、自装置がデータ・ブロックを保留する必要がない、すなわち、そのデータ・ブロックは、他のグループ・メンバーにおいて保持すべきデータ・ブロックであると判定し、ＬＲＵリストからの削除予定エントリをフリーブロックリストに移動して、対応データ・ブロックを削除可能状態とするものである。なお、削除されたデータ・ブロックは、キャッシュグループの他のメンバーが保持しており、これを取得して端末に送信可能となる。この処理については後述する。
【００９１】
リストに対するエントリの移動は、図９に示す処理となる。例えばキャッシュ装置１において、新規データ・ブロックの書き込み要求があると、（ｃ）フリーブロックリストの先頭エントリ２７１に設定されたデータ・ブロック・ポインタに対応するデータ格納領域のデータ記憶領域に新規データ・ブロックが書き込まれ、書き込まれたデータ・ブロックに関する情報は、図１０のＬＲＵリストの先頭エントリ２７２に移される。
【００９２】
その結果、もしＬＲＵリストの長さが許容リスト長を超えることになった場合は、ＬＲＵリストの末尾のエントリ２７３が、削除保留リストあるいは、フリーブロックリストに移動することになる。どちらに移動するかの判定は、前述の（１）〜（３）に示すＣ ｍｏｄ Ｎの算出、Ｖの値の判定に従う。
【００９３】
上述した判定処理の結果、ＬＲＵリストの末尾のエントリ２７３を削除保留リストに移動すると決定した場合は、ＬＲＵリストの末尾のエントリ２７３が削除保留リストの末尾のエントリ２７４として設定される。また、上述した判定処理の結果、フリーブロックリストに移動すると決定した場合は、ＬＲＵリストの末尾のエントリ２７３がフリーブロックリストの末尾のエントリ２７５として設定される。
【００９４】
また、削除保留リストに新たなエントリが加わり、削除保留リストが予め定められたリスト長を超えることとなった場合は、削除保留リストの先頭のエントリ２７６が、フリーブロックリストの末尾のエントリ２７５として設定される。
【００９５】
なお、フリーブロックリストに対応して確保すべきバッファ量が、予め定められており、これが、新規データの格納により不足することとなった場合は、ＬＲＵリストあるいは削除保留リストからのフリーブロックリストへの移動、すなわちデータ・ブロックの削除によるバッファ量確保処理が実行される。
【００９６】
フリーブロックリストへ移動されたエントリの指定するデータ・ブロック・ポインタの指定するメモリ領域は、新たな入力データの書き込みに適用され、データ・ブロックの内容が捨てられることになる。
【００９７】
［キャッシュグループ形成およびデータ管理処理］
次に、上述したキャッシュグループにおけるグループ形成、データ管理の手順について、フローチャートおよびシーケンス図を参照して説明する。
【００９８】
まず、キャッシュグループの生成処理、データ管理手順について、図１３および図１４を参照して説明する。
【００９９】
キャッシュグループは、自己のキャッシュ装置に格納したコンテンツのデータ・ブロックをＬＲＵリストから削除保留リストによる管理に移動して、グループでの共同管理を行なう場合に生成される。図１３のフローに従って、キャッシュグループの生成処理手順について説明する。
【０１００】
まず、ネットワーク接続されたキャッシュ装置は、事前準備処理として、キャッシュグループのメンバー候補の登録を行なう。これは、図１３におけるステップＳ１０１〜Ｓ１０４のステップである。
【０１０１】
ステップＳ１０１において、キャッシュグループを組む可能性のあるキャッシュ装置情報を登録する。これは、例えばオペレータが選択した１以上のキャッシュ装置のホスト名、ＩＰアドレス、ＩＣＰポート番号の登録情報である。
【０１０２】
次に、これらの登録情報から実際にキャッシュグループを設定可能なキャッシュ装置を判定する。これは、ステップＳ１０１において登録された各キャッシュ装置にｐｉｎｇなどを使ってキャッシュ装置間のＲＴＴ（Ｒｏｕｎｄ ＴｒｉｐＴｉｍｅ）を測定し、ＲＴＴが許容時間範囲内にある複数のキャッシュ装置を選択するものであり、ステップＳ１０２のＲＴＴ測定処理、ステップＳ１０３の判定処理によって、あらかじめ定めた閾値以下のＲＴＴを持つキャッシュ装置をステップＳ１０４において、「近隣のキャッシュ装置」として設定する。
【０１０３】
キャッシュ装置は、「近隣のキャッシュ装置」として設定されたキャッシュ装置リストを保持する。リストは、先に図６を参照して説明したように、近隣のキャッシュ装置に関するホスト名、ＩＰアドレス、ＩＣＰポート番号を保存したリストである。
【０１０４】
図１３のステップＳ１０２〜Ｓ１０４のステップに対応するデータ通信シーケンスが図１４の［処理Ｐ］に相当する。図１４のシーケンス図においては、キャッシュ装置Ａが処理主体となるキャッシュ装置であり、キャッシュ装置Ｂ，Ｃ，Ｄが図１３のステップＳ１０１において登録されたキャッシュ装置に相当する。
【０１０５】
図１４の［処理Ｐ］がＲＴＴ測定処理に相当する。キャッシュ装置Ａは、キャッシュ装置Ｂ，Ｃ，Ｄに対して登録された各キャッシュ装置Ｂ，Ｃ，Ｄにｐｉｎｇなどを使ってキャッシュ装置間のＲＴＴ（Ｒｏｕｎｄ Ｔｒｉｐ Ｔｉｍｅ）を測定し、ＲＴＴが許容時間範囲内にある複数のキャッシュ装置を選択する。
【０１０６】
図１３のフローに戻り、説明を続ける。図６に示す近隣のキャッシュ装置リストが生成されると、キャッシュ装置は、ステップＳ１０５において、所定時間毎に、キャッシュ・リプレースメントにより、自己の保有するＬＲＵリストから削除すべきコンテンツデータ・ブロックが発生したか否かの判定を実行する。
【０１０７】
ＬＲＵリストから削除すべきデータ・ブロックがあると判定すると、ステップＳ１０６に進み、ＬＲＵリスト中の削除予定のエントリを抽出し、ステップＳ１０７において、そのエントリに対応するコンテンツがキャッシュグループ・テーブルに登録ずみのコンテンツであるかを判定する。
【０１０８】
キャッシュグループ・テーブルは、先に、図８を参照して説明したように、設定キャッシュグループにおいて共同管理するコンテンツの識別子、キャッシュグループの構成キャッシュ装置数［Ｎ］、キャッシュグループの識別子（ＩＤ）、およびキャッシュグループのメンバーリストとして、メンバー番号とＩＰアドレスの対応データとが格納されたテーブルであり、キャッシュグループ・テーブルに登録されたコンテンツは、設定されたキャッシュグループにおいて共同管理が実行されていることを示す。
【０１０９】
ステップＳ１０７において、ＬＲＵリストから削除予定のコンテンツがキャッシュグループ・テーブルに登録されている場合は、設定されたキャッシュグループにおいて共同管理が実行されているコンテンツであり、共同管理処理として、ステップＳ１１５以下の処理を実行することになる。この処理の詳細については、後段で説明する。
【０１１０】
ステップＳ１０７において、ＬＲＵリストから削除予定のコンテンツがキャッシュグループ・テーブルに登録されていない場合は、ステップＳ１０８以下において、ＬＲＵリストから削除予定のコンテンツに対応する新たなキャッシュグループを生成する。
【０１１１】
ステップＳ１０８では、先のステップＳ１０４で設定したＲＴＴが閾値以下の近隣キャッシュ装置リスト（図６参照）に設定された各キャッシュ装置に対して、ＬＲＵリストから削除予定のコンテンツに関するキャッシュグループを組むことが可能か否かの問い合わせメッセージを送信する。
【０１１２】
この問い合わせメッセージは、ＬＲＵリストから削除予定のエントリに対応するコンテンツ保持の有無および、グループ参加可否についての問い合わせメッセージである。図１４のシーケンス図では、［処理Ｑ］のＩＣＰ＿ＯＰ＿ＱＵＥＲＹがこの問い合わせメッセージに相当する。
【０１１３】
図１３のステップＳ１０９で、キャッシュ装置は、問い合わせメッセージに対する応答を待機し、ステップＳ１１０で応答が、グループ構成可（ＨＩＴ）であるか否かを判定し、ステップＳ１１１において、グループ構成可（ＨＩＴ）であるキャッシュ装置について、のデータをキャッシュグループ・テーブル（図８参照）に登録する。ステップＳ１１２では、全てのグループ・メンバー候補（図６の近隣キャッシュ装置リストに登録されたキャッシュ装置）に対する返事の確認が終了したかを判定して、キャッシュグループの仮設定を終える。
【０１１４】
図１４のシーケンス図では、［処理Ｑ］のＩＣＰ＿ＯＰ＿ＱＵＥＲＹ（問い合わせメッセージ）に対して、グループ構成可（ＨＩＴ）のキャッシュ装置Ｂ，Ｃが、ＩＣＰメッセージのＩＣＰ＿ＯＰ＿ＨＩＴをキャッシュ装置Ａに対する応答メッセージとして送信し、グループ構成不可（ＭＩＳＳ）のキャッシュ装置Ｄが、ＩＣＰメッセージのＩＣＰ＿ＯＰ＿ＭＩＳＳをキャッシュ装置Ａに対する応答メッセージとして送信している。この場合、キャッシュ装置Ａは、キャッシュ装置Ｂ，Ｃと、キャッシュグループを構成する。
【０１１５】
図１３の処理フローのステップＳ１１３では、キャッシュグループ設定可能な数のキャッシュ装置からのＨＩＴ応答が取得できたかを判定する。例えば１以上のキャッシュ装置からＨＩＴ応答が得られればキャッシュグループ設定可能と判定することができる。キャッシュグループ設定可能な数のキャッシュ装置のＨＩＴ応答がなかった場合は、ステップＳ１１８に進み、キャッシュグループは設定せずにＬＲＵリストからの削除エントリをフリーブロックリストに移動する。この場合は、当エントリに対応するコンテンツのキャッシュグループでの共同管理は実行されない。
【０１１６】
ステップＳ１１３で、キャッシュグループ設定可能な数のキャッシュ装置からのＨＩＴ応答が取得できたと判定された場合は、ステップＳ１１４において、ＨＩＴ応答を返したキャッシュ装置であり、キャッシュグループ・テーブル（図８参照）にキャッシュグループのメンバーとして登録されたキャッシュ装置に対してグループ設定情報を送信する。
【０１１７】
グループ設定情報は、キャッシュグループを構成するキャッシュ装置数（Ｎ），当該キャッシュ装置のキャッシュグループを構成するキャッシュ装置（メンバー）識別子としてのグループ・メンバー番号（ｍ）、キャッシュグループでの処理対象コンテンツデータ識別子などの情報である。グループ・メンバー番号（ｍ）は、キャッシュ装置のＩＰアドレスに対応して設定され、キャッシュグループを構成する全てのキャッシュ装置（メンバー）は、キャッシュグループを構成する他の全てのキャッシュ装置（メンバー）識別子としてのグループ・メンバー番号（ｍ）とＩＰアドレスの対応情報を取得する。
【０１１８】
図１４のシーケンス図において、［処理Ｒ］のＩＣＰ＿ＯＰ＿ＮＯＴＩＦＹが、グループ設定情報の送信に相当し、この送信データフォーマットは、例えば先に図７を参照して説明したフォーマットに従ったものとなる。グループ設定情報を伝達したキャッシュ装置、およびグループ設定情報を伝達された、キャッシュグループに属するキャッシュ装置は、図８に示すようなグループ設定情報格納したキャッシュグループ・テーブルを自己の管理情報としてメモリに格納する。
【０１１９】
次にステップＳ１１５以下が、設定されたキャッシュグループにおけるコンテンツの共同管理処理として実行されるＬＲＵリストからの移動処理である。
【０１２０】
キャッシュ装置は、ステップＳ１１５において、ＬＲＵリストからの削除予定エントリについて、ブロックオフセット番号：Ｃ、キャッシュグループを構成するキャッシュ装置数：Ｎ、キャッシュグループにおける自己に設定されたグループ・メンバー番号：ｍの各値に基づいて、
（１） Ｃ ｍｏｄ Ｎを算出し、
（２） Ｃ ｍｏｄ Ｎ＝０の場合はＶ＝Ｎ、
Ｃ ｍｏｄ Ｎ≠０の場合はＶ＝（Ｃ ｍｏｄ Ｎ）として、
（３）Ｖ＝ｍであるか否かを判定する。
【０１２１】
Ｖ＝ｍである場合は、設定したキャッシュグループにおいて、自装置がコンテンツを保留すべきであると判定し、ステップＳ１１６において、ＬＲＵリストからの削除予定エントリを削除保留リストに移動する。すなわち、コンテンツデータ・ブロックを削除することなく、メモリに残し、削除保留リストでの管理を実行する。
【０１２２】
Ｖ＝ｍでない場合は、設定したキャッシュグループにおいて、自装置がコンテンツを保留する必要がない、すなわち、他のグループ・メンバーにおいて保持すべきデータ・ブロックであると判定し、ステップＳ１１８において、ＬＲＵリストからの削除予定エントリをフリーブロックリストに移動する。この場合は、対応データ・ブロックは、削除されることになる。削除された場合でも、キャッシュグループの他のメンバーが保持しており、これを取得して端末に送信可能となる。この処理については後述する。
【０１２３】
さらに、ステップＳ１１６におけるＬＲＵリストから削除保留リストに対するエントリ移動により、削除保留リストのリスト長が許容値を超えることとなったとき（Ｓ１１７でＹｅｓ）は、ステップＳ１１８において、削除保留リストのエントリをフリーブロックリストに移動する処理を実行する。
【０１２４】
次に、図１５乃至図１７を参照して、キャッシュグループによるコンテンツ管理を実行しているキャッシュ装置に、端末からのコンテンツ要求が発生した場合の処理について説明する。
【０１２５】
図１５のステップＳ２０１において、キャッシュ装置が端末からコンテンツ取得要求を受信すると、キャッシュ装置は、ステップＳ２０２において、要求コンテンツデータがキャッシュグループ・テーブル（図８参照）に登録されたコンテンツであるか否かを判定する。登録されていない場合は、グループ管理されていないコンテンツであり、通常の処理、すなわち自装置に格納されている場合は、コンテンツを取得して端末に送信し、自装置に格納されていない場合は、コンテンツをコンテンツサーバーから取得して端末に送信する。
【０１２６】
要求コンテンツデータがキャッシュグループ・テーブル（図８参照）に登録されたコンテンツである場合は、グループ管理されているコンテンツであり、ステップＳ２０３で、キャッシュグループ・テーブル（図８参照）からキャッシュグループの構成要素数Ｎと、自身のメンバー番号ｍ１を取得する。
【０１２７】
ステップＳ２０４において、端末からのコンテンツ取得要求中に含まれるコンテンツのオフセット情報に基づいて、ブロックオフセットを算出して、ブロックオフセット番号：Ｃを取得する。次に、ステップＳ２０５において、キャッシュグループを構成するキャッシュ装置数：Ｎ、キャッシュグループにおける自己に設定されたグループ・メンバー番号：ｍ１の各値に基づいて、
（１） Ｃ ｍｏｄ Ｎを算出し、
（２） Ｃ ｍｏｄ Ｎ＝０の場合はＶ＝Ｎ、
Ｃ ｍｏｄ Ｎ≠０の場合はＶ＝（Ｃ ｍｏｄ Ｎ）として、
（３）Ｖ＝ｍ１であるか否かを判定する。
【０１２８】
Ｖ＝ｍ１である場合は、要求されたコンテンツが自装置内に格納されていることになり、ステップＳ２０６に進み、ＬＲＵリストまたは削除保留リストのエントリに基づいて要求コンテンツ名、ブロックオフセット番号から自装置内のデータ格納領域情報を取得し、ステップＳ２０７において、データの読み出しを実行し、正常読み出し完了を確認（Ｓ２０８）し、ステップＳ２０９において、グループＩＤ（Ｇｐ）＝０であるか否かを判定する。
【０１２９】
グループＩＤ（Ｇｐ）＝０は、設定されたキャッシュグループのメンバー離脱が発生して、キャッシュグループの維持を行なわない際にキャッシュ装置が、キャッシュグループ・テーブルのグループＩＤ（Ｇｐ）を書き換えることにより設定される。グループＩＤ（Ｇｐ）が、０の場合は、キャッシュグループから離脱したメンバーが多くなってグループを構成できないことを示すエントリであるため、ステップＳ２１０において、エントリを削除保留リストではなくＬＲＵリストの先頭に移動させる。
【０１３０】
また、グループＩＤ（Ｇｐ）＝０でない場合は、ステップＳ２１１において、データ・ブロックがアクセスをされたことから、削除保留リストの先頭に該当のエントリを移す。
【０１３１】
さらに、ステップＳ２１２で、読み出しデータを要求端末に送信し、指定サイズデータの送信の完了を確認（Ｓ２１３）し、未終了である場合は、ステップＳ２１４において、ブロックオフセット番号：Ｃの更新処理（Ｃ＝Ｃ＋１）を実行して、ステップＳ２０５以下の処理を繰り返し実行して端末に対するコンテンツ送信を実行する。
【０１３２】
ステップＳ２０５において、キャッシュグループを構成するキャッシュ装置数：Ｎ、キャッシュグループにおける自己に設定されたグループ・メンバー番号：ｍ１の各値に基づく、Ｃ ｍｏｄ Ｎ算出、Ｖ＝ｍ１であるか否かの判定において、Ｖ＝ｍ１でない場合は、要求されたコンテンツが自装置内に格納されていないことになり、ステップＳ２１５に進み、算出したＶの値（ｍ２とする）に対応するグループ・メンバーをキャッシュグループ・テーブル（図８参照）から取得する。
【０１３３】
ステップＳ２１６において、算出したＶの値（ｍ２とする）に対応するグループ・メンバーのＩＰアドレスをキャッシュグループ・テーブル（図８参照）から取得する。ステップＳ２１７では、取得ＩＰアドレスが０．０．０．０か否かを判定する。ＩＰアドレスが０．０．０．０の場合は、キャッシュグループを離脱したメンバーのエントリを示す。この場合は、上流のキャッシュ装置またはコンテンツサーバーに要求をリダイレクトして発行（Ｓ２２１）する。
【０１３４】
ステップＳ２１７の判定において、取得ＩＰアドレスが０．０．０．０でない場合は、キャッシュグループのメンバーのエントリを示す。ステップＳ２１８に進み、コンテンツの読み出し要求（リダイレクト要求）をキャッシュグループのメンバー（ｍ２）に対応するＩＰアドレスに基づいて実行する。
【０１３５】
リダイレクト要求を受信したキャッシュ装置における処理について、図１６を参照して説明する。これは、キャッシュグループを構成するキャッシュ装置が、他のグループ・メンバーからのコンテンツ読み出し要求（リダイレクト要求）に応答する処理として実行される処理である。
【０１３６】
ステップＳ３０１において、コンテンツ読み出し要求（リダイレクト要求）を受信すると、ステップＳ３０２に進み、ＬＲＵリストまたは削除保留リストのエントリに基づいて要求コンテンツ名、ブロックオフセット番号から自装置内のデータ格納領域情報を取得し、ステップＳ３０３において、データの有無、エラー状態を判定し、消去されているかエラーである場合は、ステップＳ３０６において、コンテンツ読み出し要求（リダイレクト要求）を送信してきたキャッシュ装置に対してエラー提示コードを応答送信する。
【０１３７】
ステップＳ３０３において、データの有無、エラー状態を判定し、データが存在し、読み出し可能であると判定されると、ステップＳ３０４において、指定サイズのデータの読み出しを実行し、ステップＳ３０５で、読み出しデータを要求キャッシュ装置に、正常終了提示コードとともに送信する。
【０１３８】
図１５の処理フローに戻り、説明を続ける。ステップＳ２１９またはステップＳ２２２において、リダイレクト要求先からの応答を受信すると、ステップＳ２２０またはステップＳ２２３において、正常読み出しがなされたか否かを判定し、Ｙｅｓの場合は、ステップＳ２０９に進み、以下の処理、すなわち、リストエントリの移動、取得コンテンツの端末に対する送信等を実行する。なお、ステップＳ２０８、Ｓ２２０，Ｓ２２３において、データの正常読み出しに失敗した場合は、異常終了として処理を終了する。
【０１３９】
なお、異常終了として処理を終了する以前に、エラー応答受信後、リダイレクト先として上流のキャッシュ装置（サーバーへの経路途中にある、サーバーにより近いキャッシュ装置）がある場合は、上流の装置にリダイレクトし、無い場合は、直接コンテンツサーバーに要求をリダイレクトして、目的とするデータを得る処理を実行してもよい。
【０１４０】
上記処理における各キャッシュ装置間のデータ通信シーケンスの概要を、図１７を参照して説明する。なお、図１７において、左端から、
コンテンツ取得要求を送信する端末、
端末からのコンテンツ取得要求を受信するキャッシュ装置Ａ
キュッシュ装置Ａとキャッシュグループを構成するキャッシュ装置１
キュッシュ装置Ａとキャッシュグループを構成するキャッシュ装置２
キュッシュ装置Ａの上流キャシュ装置またはサーバー
である。
【０１４１】
［処理Ｓ］は、端末からの要求コンテンツデータを、キャッシュ装置Ａが、キャッシュグループ・メンバーとしてのキャッシュ装置１，２からそれぞれ取得して、端末に送信する処理シーケンスであり、ＵＲＬを指定したコンテンツ取得要求（ＨＴＴＰ ＧＥＴ （ＵＲＬ））を受信したキャッシュ装置が上述のＣ ｍｏｄ Ｎ算出、Ｖ＝ｍ１の算出に基づいて、コンテンツの対応データ・ブロックを保持していると予測されるキャッシュ装置１，２に対してコンテンツ取得要求（ＨＴＴＰ ＧＥＴ （ＵＲＬ） Ｒａｎｇｅ：ｂｙｔｅｓ＝ａａ−ｂｂ）を送信し、コンテンツのデータ・ブロックを取得（ＨＴＴＰ２０６）し、キャッシュ装置Ａは、取得コンテンツを端末に送信（ＨＴＴＰ ＯＫ）する処理シーケンスである。
【０１４２】
［処理Ｔ］は、端末からの要求コンテンツデータを、キャッシュ装置Ａが、キャッシュグループ・メンバーとしてのキャッシュ装置１，２からそれぞれ取得できなかった場合の処理シーケンスであり、ＵＲＬを指定したコンテンツ取得要求（ＨＴＴＰ ＧＥＴ （ＵＲＬ））を受信したキャッシュ装置が上述のＣ ｍｏｄＮ算出、Ｖ＝ｍ１の算出に基づいて、コンテンツの対応データ・ブロックを保持していると予測されるキャッシュ装置１に対してコンテンツ取得要求（ＨＴＴＰ ＧＥＴ （ＵＲＬ） Ｒａｎｇｅ：ｂｙｔｅｓ＝ａａ−ｂｂ）を送信し、コンテンツのデータ・ブロックが取得できない旨の応答（ＨＴＴＰ４０４（Ｎｏｔ Ｆｏｕｎｄ）または、ＨＴＴＰ４１０（Ｇｏｎｅ））を受信する。
【０１４３】
さらに、キャッシュ装置Ａは、キュッシュ装置Ａの上流キャシュ装置またはサーバーに、コンテンツ取得要求（ＨＴＴＰ ＧＥＴ （ＵＲＬ） Ｒａｎｇｅ：ｂｙｔｅｓ＝ａａ−ｂｂ）を送信し、コンテンツのデータ・ブロックを取得（ＨＴＴＰ２０６）し、キャッシュ装置Ａは、取得コンテンツを端末に送信（ＨＴＴＰＯＫ及び取得したコンテンツデータの送信）をする。
【０１４４】
なお、［処理Ｔ］のように、キャッシュグループの構成メンバーから予定のコンテンツが取得できなかった場合は、キャッシュグループの構成メンバーとして存続する意味がないので、グループ解消を行なう。この処理が［処理Ｕ］である。
【０１４５】
グループ解消処理は、キャッシュＡから、グループ解消通知（ＩＣＰ ＯＰ ＮＯＴＩＦＹ）を、グループを構成する各キャッシュ装置１，２に送信することによって行なわれる。キャッシュ装置Ａ，１，２はその後、キャッシュグループ・テーブルから対応するグループ情報を削除する。
【０１４６】
なお、上述した例では、ＨＴＴＰプロトコルを使ったリダイレクト手順を書いているが、ＦＴＰやＲＴＳＰなどの別のプロトコルであってもかまわない。また、キャッシュ装置間の通信プロトコルについても、ＩＣＰだけに限定する必要はなく、一般的に使われる装置間の通信手段を拡張することでも実現可能である。また、キャッシュ間通信プロトコルも、ＩＣＰだけには限らない。
【０１４７】
キャッシュグループを構成するグループ・メンバーｍ（ｍ＝１，２，．．．，Ｎ： Ｎはグループ構成メンバー数）がキャッシュグループから離脱することになるケースを以下に説明する。
【０１４８】
キャッシュグループを組むと宣言したコンテンツに関連するデータ・ブロックの全体数をＡとしたときに、グループ・メンバーとして保持しておくべきデータ・ブロック（Ｖ＝ｍのデータ・ブロック）の総数Ｓは、Ａ ｍｏｄ Ｎが零の場合はＶ＝Ｎ，非零の場合はＶ＝（Ａ ｍｏｄ Ｎ）としてｍ≦ＶのときＳ＝（Ａ＋Ｎ−１）／Ｎ，ｍ＞ＶのときＳ＝Ａ／Ｎと計算される。
【０１４９】
このＳの分のデータ・ブロックを永久に保持できればよいが、記憶資源は有限であるため、キャッシュ・リプレースメントが進むとグループ・メンバーとして保持しておくべきデータ・ブロックであったとしても、削除保留リストから削除されてしまうケースもある。このようにグループ・メンバーとして保持しておくべきデータ・ブロックも削除保留リストからも削除されてしまうような場合において、グループ・メンバーとして保持すべきデータ・ブロックにもかかわらず削除してしまったデータ・ブロックの数をＤとするとき、グループ離脱に至る閾値Ｔ（％）として、グループ・メンバーとして保持すべきデータ・ブロックの残存率：（Ｓ−Ｄ）／Ｓ×１００（％）を算出し、
データ・ブロックの残存率と閾値Ｔとの関係が、
（Ｓ−Ｄ）／Ｓ×１００（％）＜Ｔ（０＜＝Ｔ＜１００）となった場合に、そのコンテンツに関しキャッシュグループを組んでいるキャッシュ・メンバーに対して、グループ離脱を宣言する構成が可能である。
【０１５０】
キャッシュグループからの離脱を検知したときは、自分のキャッシュグループ・テーブルから該当するコンテンツに対応するエントリを削除すると共に、図１７の［処理Ｕ］に示すように、これを知らせるフラグ（説明のための例として０ｘ１０００００００（ＩＣＰ＿ＦＬＡＧ＿ＧＲＯＵＰ＿ＤＥＳＥＲＴＥＤ））を立てたＩＣＰ＿ＯＰ＿ＮＯＴＩＦＹメッセージを、該当するコンテンツについてキャッシュグループを組んでいる全グループ・メンバーに送る。
【０１５１】
さらに、各キャッシュ装置にあるキャッシュグループ・テーブルから、通知されたキャッシュ装置がキャッシュグループから離脱したことがわかるように、対応する部分のＩＰアドレスを≡０．０．０．０≡のように書き換える。
【０１５２】
ただし、メンバー数などの他の情報は、離脱メンバーが無い場合とのアルゴリズムの互換を保つ目的もあり、そのままの情報として保持してもよい。もし、離脱グループ・メンバーが保持しているべきデータ・ブロックをアクセスしたい場合には、オリジナルデータを持っているサーバーまたは上流のキャッシュ装置にアクセスすることになる。
【０１５３】
キャッシュグループを構成するメンバー数が、離脱メンバーを除いた実質数で１となった場合、キャッシュグループを組めないことになるため、グループを完全に消去する意味で、残った１台のキャッシュ装置のキャッシュグループ・テーブルから該当するコンテンツに対応するエントリを削除し、削除保留リストの対応するコンテンツに属するデータ・ブロックの“Ｇｐ”の項目を初期化（ゼロクリア）する。
【０１５４】
［多段構成の削除保留リスト］
次に、キャッシュ装置においてデータ管理リストとして生成する削除保留リストを多段構成とした実施例について説明する。
【０１５５】
上述した実施例において、キャッシュ装置は、図９を参照して説明したように、ＬＲＵリストと、キャッシュの空き領域ブロックを示すフリーブロックリスト、さらに、ＬＲＵリストで削除対象ブロックとなったデータ・ブロックの内、一時的に削除保留状態に設定したデータ・ブロックを管理するリストとしての削除保留リストを有しており、各リストは、先頭エントリからシーケンシャルに並べられたエントリを有する構成であった。
【０１５６】
本実施例のキャッシュ装置は、図１８に示すように、複数の削除保留リストを有する。キャッシュ装置は、利用頻度順にエントリを並べた（ａ）ＬＲＵリスト、キャッシュグループを構成したコンテンツのデータ・ブロックに対応して設定したエントリを格納した複数の（ｂ１）（ｂ２）削除保留リスト、空きブロック領域をポインタ情報として有する（ｃ）フリーブロックリストを有する。
【０１５７】
複数の削除保留リスト（ｂ１）（ｂ２）は、コンテンツデータ・ブロックの削除保留優先度の高低に基づいて振り分けられてエントリが各リストに格納される。ここでは、２つの削除保留リスト（ｂ１）（ｂ２）のうち、（ｂ１）のリストに保存優先度の高いコンテンツに対応するエントリを格納し、（ｂ２）のリストに保存優先度の低いコンテンツに対応するエントリを格納する例を示す。本例では、２つの削除保留リストの設定例を示しているが、保存優先度順に３以上の削除保留リストを設定する構成としてもよい。
【０１５８】
なお、データ・ブロックの重要性に応じた保存優先度の判定の態様は、様々な態様が可能である。例えば、新規に届いたコンテンツに対応するデータ・ブロックほど重要とする設定、あるいは、コンテンツデータの先頭部分やシーンチェンジ部分以降の特定区間だけは重要度の高いデータ・ブロックとして設定するなどの構成がある。なお、コンテンツデータの先頭部分やシーンチェンジ部分の検出は、既存のソフトウェアによる処理が可能である。
【０１５９】
リストに対するエントリの移動について説明する。例えばキャッシュ装置において、新規データ・ブロックの書き込み要求があると、（ｃ）フリーブロックリストの先頭エントリ５０１に設定されたデータ・ブロック・ポインタに対応するデータ格納領域のデータ記憶領域に新規データ・ブロックが書き込まれ、書き込まれたデータ・ブロックに関する情報は、図１０のＬＲＵリストの先頭エントリ５０２に移される。
【０１６０】
その結果、もしＬＲＵリストの長さが許容リスト長を超えることになった場合は、ＬＲＵリストの末尾のエントリ５０３が、削除保留リスト（ｂ１）または（ｂ２）あるいは、フリーブロックリスト（ｃ）に移動することになる。削除保留リストかフリーブロックリストのどちらに移動するかの判定は、前述のＣ ｍｏｄ Ｎの算出、Ｖの値によるエントリに対応するコンテンツデータ・ブロックの残留、削除判定に基づくことになる。
【０１６１】
上述した判定処理の結果、エントリを削除保留リストに移動すると決定した場合は、保存の重要度に応じて、重要度の高いデータ・ブロックに対するエントリは、削除保留リスト（ｂ１）の末尾のエントリ５０４として設定し、重要度の低いデータ・ブロックに対するエントリは、削除保留リスト（ｂ２）の末尾のエントリ５０５として設定する。
【０１６２】
また、削除保留リスト（ｂ１）に新たなエントリが加わり、削除保留リスト（ｂ１）が予め定められたリスト長を超えることとなった場合は、削除保留リスト（ｂ１）の先頭のエントリ５１１が、削除保留リスト（ｂ２）の末尾のエントリ５０５として設定される。
【０１６３】
同様に、削除保留リスト（ｂ２）に新たなエントリが加わり、削除保留リスト（ｂ２）が予め定められたリスト長を超えることとなった場合は、削除保留リスト（ｂ２）の先頭のエントリ５１２が、フリーブロックリストの末尾のエントリ５２１として設定される。
【０１６４】
なお、フリーブロックリストに対応して確保すべきバッファ量が、予め定められており、これが、新規データの格納により不足することとなった場合は、ＬＲＵリストあるいは削除保留リスト（ｂ２）からのフリーブロックリストへの移動、すなわちデータ・ブロックの削除によるバッファ量確保処理が実行される。
【０１６５】
フリーブロックリストへ移動されたエントリの指定するデータ・ブロック・ポインタの指定するメモリ領域は、新たな入力データの書き込みに適用され、データ・ブロックの内容が捨てられることになる。
【０１６６】
多段構成とした場合の削除保留リストの構成について、図１９を参照して説明する。削除保留リストとは、前述したように、ＬＲＵリストで削除対象ブロックとなったデータ・ブロックの内、一時的に削除保留状態に設定したデータ・ブロックを管理するリストである。
【０１６７】
図１９は、図１８の削除保留リスト（ｂ１）または（ｂ２）のいずれかに対応する削除保留リストの構成を示している。図１９のように、キャッシュ装置の保有する削除保留リスト６３０は、削除保留状態に設定したデータ・データ・ブロックに対応付けて生成される。ここでは、（ａ）〜（ｐ）のリストデータ（エントリ）が削除保留状態に設定したデータ・データ・ブロックに対応付けられて保持されている。削除保留リストの内部構造は、図１９に示すように、データ・ブロックヘのポインタ６３１、コンテンツ識別子６３２、ブロックオフセット６３３、設定されたキャッシュグループのグループ識別子（ＧＰ）６３４、さらに、削除保留リストの重要度指数値（Ｐｒｉｏｒｉｔｙ）６３５、および削除保留リストの前リストデータ（エントリ）のポインタ６３６、削除保留リストの後続リストデータ（エントリ）のポインタ６３７を有する。多段構成の削除保留リスト６３０の格納データには、削除保留リストの重要度指数値（Ｐｒｉｏｒｉｔｙ）６３５が付加されることになる。
【０１６８】
次に、多段構成の削除保留リストを持キャッシュ装置におけるキャッシュグループの生成処理、データ管理手順について、図２０を参照して説明する。
【０１６９】
図２０において、ステップＳ５０１乃至ステップＳ５１５は、前述の図１３を参照して説明した処理フローのステップＳ１０１乃至ステップＳ１１５と同様の処理であるので、説明を省略する。
【０１７０】
図２０のステップＳ５１５において、ＬＲＵリストからの削除予定エントリについて、ブロックオフセット番号：Ｃ、キャッシュグループを構成するキャッシュ装置数：Ｎ、キャッシュグループにおける自己に設定されたグループ・メンバー番号：ｍの各値に基づいて、 Ｃ ｍｏｄ Ｎを算出し、さらに、 Ｃ ｍｏｄ Ｎ＝０の場合はＶ＝Ｎ、Ｃ ｍｏｄ Ｎ≠０の場合はＶ＝（Ｃ ｍｏｄ Ｎ）として、Ｖ＝ｍであるか否かを判定した結果、Ｖ≠ｍである場合は、ステップＳ５２３に進みそのデータ・ブロックをフリーリストで管理する。Ｖ＝ｍである場合は、そのデータ・ブロックを削除保留として、自装置で管理することになる。
【０１７１】
この場合、ステップＳ５１６において、削除保留対象データ・ブロックの保持優先度の判定を実行する。この保持優先度判定は、キャッシュ装置において予め定められた基準、例えば、前述したように、新規に届いたコンテンツに対応するデータ・ブロックを重要、あるいは、コンテンツデータの先頭部分やシーンチェンジ部分以降の特定区間を重要とした設定情報に基づいて判定する。
【０１７２】
保存優先度の高いデータ・ブロックであると判定した場合は、ステップＳ５１７に進み、保存優先度の高い削除保留リスト（図１８の（ｂ１））にエントリを移動する。保存優先度の低いデータ・ブロックであると判定した場合は、ステップＳ５２０に進み、保存優先度の低い削除保留リスト（図１８の（ｂ２））にエントリを移動する。
【０１７３】
さらに、ステップＳ５１８において、保存優先度の高い削除保留リストから保存優先度の低い削除保留リストにエントリ移動が必要であるか否かを判定し、必要があると判定されると、ステップＳ５１９において、保存優先度の高い削除保留リストから保存優先度の低い削除保留リストにエントリを移動する。
【０１７４】
ステップＳ５２１において、保存優先度の低い削除保留リストからフリーブロックリストにエントリ移動が必要であるか否かを判定し、必要があると判定されると、ステップＳ５２２において、保存優先度の低い削除保留リストからフリーブロックリストにエントリを移動する。
【０１７５】
以上の処理に従って、多段構成を持つ削除保留リストを適用したデータ管理が実行される。
【０１７６】
［キャッシュ装置の構成］
次に、上述の実施例において説明したキャッシュ装置のハード構成例について説明する。
【０１７７】
図２１に、制御手段としてＣＰＵ(Central Processing Unit)を備えたキャッシュ装置例を示す。なお、図２１に示す構成例は１つの例であり、キャッシュ装置は、ここに示す構成以外のハードウェアを持つことも可能である。
【０１７８】
図２１に示す構成について説明する。ＣＰＵ(Central Processing Unit)７０１は、各種実行プログラム、ＯＳ（Operating System）を実行するプロセッサである。ＲＯＭ（Read-Only-Memory）７０２は、ＣＰＵ７０１が実行するプログラム、あるいは演算パラメータとしての固定データを格納する。ＲＡＭ（Random Access Memory）７０３は、ＣＰＵ７０１の処理において実行されるプログラム、およびプログラム処理において適宜変化するパラメータの格納エリア、ワーク領域として使用される。また、近隣キャッシュ装置リスト、キャッシュグループ・テーブルの格納領域として使用される。
【０１７９】
ＣＰＵ７０１，ＲＯＭ７０２，ＲＡＭ７０３はＣＰＵバス７１１によってデータ転送可能に接続され、バスブリッジ７０４を介してＩ／Ｏバス７１２に接続される。Ｉ／Ｏバス７１２には、ディスクインタフェース７０５、ネットワークインタフェース７０７，７０８が接続される。
【０１８０】
ディスクインタフェース７０５は、ハードディスク、フレキシブルディスク、ＣＤ−ＲＯＭ(Compact Disc Read Only Memory)，ＭＯ(Magneto optical)ディスク，ＤＶＤ(Digital Versatile Disc)、磁気ディスク等のディスク７０６に対するインタフェースであり、ディスク７０６には、キャッシュデータガ格納され、ＣＰＵ７０１の制御の下に必要データが取得、格納される。
【０１８１】
ネットワークインタフェース７０７は、外部ネットワークインタフェースであり、ネットワーク接続されたサーバー、他のキャッシュ装置とのデータ送受信用のインタフェースである。ネットワークインタフェース７０８は、内部ネットワークインタフェースであり、ネットワーク接続された端末とのデータ送受信用のインタフェースである。
【０１８２】
なお、明細書中において説明した各処理はハードウェア、またはソフトウェア、あるいは両者の複合構成によって実行することが可能である。一連の処理をソフトウェアにより実行させる場合には、そのソフトウェアを構成するプログラムが専用のハードウェアに組み込まれているコンピュータ、又は各種のプログラムをインストールすることで各種の機能を実行することが可能な、例えば汎用のパーソナルコンピュータなどに、フレキシブルディスクやＣＤ−ＲＯＭ等のプログラム読み取り可能な記録媒体にプログラムを格納して提供してもよいし、インターネットなどの通信網を介してプログラムをダウンロードしてもよい。
【０１８３】
具体的には、プログラムは記録媒体としてのハードディスクやＲＯＭ（Read Only Memory)に予め記録しておくことができる。あるいは、プログラムはフレキシブルディスク、ＣＤ−ＲＯＭ(Compact Disc Read Only Memory)，ＭＯ(Magneto optical)ディスク，ＤＶＤ(Digital Versatile Disc)、磁気ディスク、半導体メモリなどのリムーバブル記録媒体に、一時的あるいは永続的に格納（記録）しておくことができる。このようなリムーバブル記録媒体は、いわゆるパッケージソフトウエアとして提供することができる。
【０１８４】
また、プログラムは、上述したようなリムーバブル記録媒体からコンピュータにインストールする他、ダウンロードサイトから、コンピュータに無線転送したり、ＬＡＮ(Local Area Network)、インターネットといったネットワークを介して、コンピュータに有線で転送し、コンピュータでは、そのようにして転送されてくるプログラムを受信し、内蔵するハードディスク等の記録媒体にインストールすることができる。
【０１８５】
なお、明細書に記載された各種の処理は、記載に従って時系列に実行されるのみならず、処理を実行する装置の処理能力あるいは必要に応じて並列的にあるいは個別に実行されてもよい。また、本明細書においてシステムとは、複数の装置の論理的集合構成であり、各構成の装置が同一筐体内にあるものには限らない。
【０１８６】
以上、特定の実施例を参照しながら、本発明について詳解してきた。しかしながら、本発明の要旨を逸脱しない範囲で当業者が該実施例の修正や代用を成し得ることは自明である。すなわち、例示という形態で本発明を開示してきたのであり、限定的に解釈されるべきではない。本発明の要旨を判断するためには、冒頭に記載した特許請求の範囲の欄を参酌すべきである。
【０１８７】
【発明の効果】
以上、説明してきたように、本発明の構成によれば、ネットワーク接続されたキャッシュ装置におけるキャッシュ・リプレースメント処理において、削除保留ブロックに関するリストを保持して、キャッシュグループ内のキャッシュ装置ごとに各々削除保留されるデータ・ブロックが異なるようにデータ管理を行なう構成としたので、各キャッシュ装置が単独でキャッシュ・リプレースメントの管理をしている場合に比べて効率的な記憶領域の利用が図れ、また、端末からのデータ要求に応じて複数のキャッシュ装置に記憶したデータ・ブロックを集めて送信することが可能となり、ネットワークトラフィックの軽減、キャッシュ装置のヒット率の向上が実現される。
【０１８８】
さらに、本発明の多段の削除保留リストを適用したキャッシュ装置構成によれば、保持重要度の高いデータが削除されずにキャッシュに残る可能性が高くなるため、さらに、キャッシュヒット率の向上を達成することが可能となる。
【図面の簡単な説明】
【図１】従来のＬＲＵリストおよびフリーブロックリストによるキャッシュデータの管理構成について説明する図である。
【図２】本発明のキャッシュ装置が適用可能なネットワーク構成について説明する図である。
【図３】本発明のキャッシュ装置におけるデータ管理構成について説明する図である。
【図４】本発明のキャッシュ装置におけるデータ管理構成について説明する図である。
【図５】本発明のキャッシュ装置間における送受信メッセージのフォーマット例について説明する図である。
【図６】本発明のキャッシュ装置における近隣キャッシュ装置リストの構成データについて説明する図である。
【図７】本発明のキャッシュ装置間における送受信メッセージとしてのグループ設定情報メッセージのフォーマット例について説明する図である。
【図８】本発明のキャッシュ装置において格納するキャッシュグループ・テーブルのデータ例について説明する図である。
【図９】本発明のキャッシュ装置においてデータ管理に利用するリストについて説明する図である。
【図１０】本発明のキャッシュ装置においてデータ管理に利用するＬＲＵリストについて説明する図である。
【図１１】本発明のキャッシュ装置においてデータ管理に利用する削除保留リストについて説明する図である。
【図１２】本発明のキャッシュ装置においてデータ管理に利用するフリーブロックリストについて説明する図である。
【図１３】本発明のキャッシュ装置におけるグループ形成、データ管理処理について説明するフロー図である。
【図１４】本発明のキャッシュ装置におけるグループ形成、データ管理処理に際して送受信されるメッセージについて説明するシーケンス図である。
【図１５】本発明のキャッシュ装置におけるデータ取得送信処理について説明するフロー図である。
【図１６】本発明のキャッシュ装置におけるリダイレクト処理によるデータ取得送信処理について説明するフロー図である。
【図１７】本発明のキャッシュ装置におけるデータ取得送信処理に際して送受信されるメッセージについて説明するシーケンス図である。
【図１８】本発明のキャッシュ装置において多段構成の削除保留リストを持つ構成を説明する図である。
【図１９】本発明のキャッシュ装置における多段構成の削除保留リスト構成について説明する図である。
【図２０】本発明の多段構成の削除保留リストを持つキャッシュ装置におけるグループ形成、データ管理処理について説明するフロー図である。
【図２１】本発明のキャッシュ装置におけるハード構成例を示す図である。
【符号の説明】
２０１ コンテンツサーバー
２０２ ネットワーク
２１０ キャッシュグループ
２１１，２１２，２１３，２１４ キャッシュ装置
２２１，２３１，２５１ 端末
３１０ ＬＲＵリスト
３２０ データ格納領域
３３０ 削除保留リスト
３５０ フリーブロックリスト
６３０ 削除保留リスト
７０１ ＣＰＵ
７０２ ＲＯＭ
７０３ ＲＡＭ
７０４ バスブリッジ
７０５ ディスクインタフェース
７０６ ディスク
７０７ ネットワークインタフェース
７０８ ネットワークインタフェース
７１１ ＣＰＵバス
７１２ Ｉ／Ｏバス
【発明の属する技術分野】
本発明は、キャッシュ装置、およびキャッシュデータ管理方法、並びにコンピュータ・プログラムに関する。さらに詳細には、ネットワークを通じて送受信されるデータ・キャッシュ処理において、キャッシュ装置内のデータ格納領域の効率的利用、およびヒット率向上を実現したキャッシュ装置、およびキャッシュデータ管理方法、並びにコンピュータ・プログラムに関する。
【０００２】
【従来の技術】
近年、インターネット等の通信ネットワークを介した画像、音声データ、各種プログラム等のデータ転送が盛んに行われている。ネットワークを通じてやりとりされるコンテンツの種類は、テキスト・静止画などから、動画・音声などのマルチメディアコンテンツへと移行が進み、コンテンツの大容量化、多種類化が著しく進んでいる。
【０００３】
また、近年は、ブロードバンドによる大容量コンテンツの配信が急速に広まり、これに応じて、ネットワークを介して流通するコンテンツ数が飛躍的に増加している。このようにコンテンツの種類が増加し、大容量コンテンツが増大すると、データ通信量の増大、すなわちネットワークのデータトラフィックの増大という問題が発生する。
【０００４】
ネットワークのデータトラフィックの増大という問題を解決する１つの手法にキャッシュシステムがある。キャッシュシステムは、例えばコンテンツ配信サイトからコンテンツ受信ユーザー側に至るネットワーク経路上にデータ蓄積手段としてのキャッシュを構成したシステムであり、ユーザー側から要求されたデータ（コンテンツ）がキャッシュに蓄積されている場合は、コンテンツ配信サイトから改めてデータ（コンテンツ）を送信することなく、データをキャッシュから取り出してユーザーに提供可能としたものである。
【０００５】
例えば、ユーザーがネットワークを介してコンテンツを取得し、ネットワーク上の一時的な記憶装置（キャッシュ）にコンテンツが格納された場合、キャッシュは一定の決まったルールでコンテンツ格納、削除処理を行なう。例えばキャッシュの記憶容量の越えない範囲で最新のコンテンツが入力される毎に、アクセスの頻度が古いコンテンツを書き換える処理を実行する。通常、このキャッシュにおけるコンテンツ管理ルールはコンテンツの配信側やユーザー側の直接的な管理とは無関係に実行される。
【０００６】
このように、インターネット・キャッシュのデータ領域管理において、データが満杯になると使われなくなったデータ領域を検出し、その領域をキャッシュから削除後に新しいデータで置き換える処理を行なう。これをキャッシュ・リプレースメント（Cache Replacement)と呼ぶ。
【０００７】
従来のインターネット・キャッシュのキャッシュ・リプレースメント（Cache Replacement）は、インターネット等のネットワークに複数のキャッシュが存在する場合であっても、各々の個別のキャッシュ装置内で独自なデータ管理を実行するのが一般的である。最も一般的なキャッシュ・リプレースメントの技法としては、ＬＲＵ(Least Recently Used)によるデータ管理方法がある。
【０００８】
ＬＲＵは、最近使用されていないデータ・ブロックを、ＬＲＵリストの後ろに回し、最近使われたデータ・ブロックを、ＬＲＵリストの先頭に設定するという管理方法であり、新しいデータをキャッシュするために古いデータを削除したい場合には、ＬＲＵリストの後ろにあるブロックから削除することで、キャッシュ内に新たなデータ格納領域を形成する方法である。
【０００９】
図１を参照してＬＲＵ(Least Recently Used)によるデータ管理方法について説明する。管理データとしては、利用頻度順にデータ・ブロックに対応するエントリを並べた（ａ）ＬＲＵリストと、キャッシュの空き領域ブロックを示す（ｂ）フリーブロックリストを有する。新たにキャッシュされたデータは、（ｂ）フリーブロックリストのエントリに示されるポインタによって特定されるメモリ領域としてのデータ格納ブロックに格納され、格納ブロックに対して設定されるブロック情報を格納したエントリが、（ａ）ＬＲＵリストの先頭エントリ１０１として設定される。
【００１０】
データの新規入力（キャッシュ）により、キャッシュのデータ格納領域が満杯になり、以前よりキャッシュされていたデータの中から、いずれかを削除する必要のあるときに、削除されるデータは、（ａ）ＬＲＵリストの末端にある最近使われていないデータ・ブロックと考えられるエントリ１０２に対応するデータ・ブロックであり、削除されたデータ・ブロックをポインタ情報として示すエントリが（ｂ）フリーブロックリストに設定されることで、所定のデータ格納ブロックが空き領域として設定される。
【００１１】
このようなキャッシュ用データ・ブロック管理の方法は、あくまで単独のキャッシュ装置に関する情報を元に処理されていた。また、近隣の複数のキャッシュ装置に対して要求元のキャッシュ装置の持っていないデータを要求するための手段としてＩＣＰ(Internet Cache Protocol : RFC-2186, RFC-2187)が提案されているが、コンテンツファイルのリソース情報としてのＵＲＬ(Uniform Resource Locator)を指定したＵＲＬ単位でのデータ要求処理であることや、複数のキャッシュ間でどのデータを消去または残すべきかの細かい調整機能が無い。このため、たまたま各キャッシュ装置の事情で要求したものと同じデータが他のキャッシュ装置に残っているときに、そのデータをサーバーからダウンロードしてくる代わりに他のキャッシュ装置から持ってくるという処理をしていただけである。
【００１２】
【発明が解決しようとする課題】
本発明は、上述したキャッシュ管理の現状に鑑みてなされたものであり、ネットワークに複数のキャッシュが接続された構成において、効率的なデータ格納領域の利用を実現したキャッシュ装置、およびキャッシュデータ管理方法、並びにコンピュータ・プログラムを提供することを目的とする。
【００１３】
例えば、ネットワーク接続されたキャッシュにおけるデータ領域管理方法において、データの削除を一時保留する「削除保留リスト」を使って管理することや、キャッシュグループという概念を導入することで、ビデオコンテンツのような大きなサイズのコンテンツをキャッシュするときに好適なデータ管理方法を実現する。
【００１４】
キャッシュグループとは、ネットワークに接続したキャッシュ装置のいくつかを組にしたものであり、このグループ内の複数のディスク間で同じコンテンツデータが管理されているものとする。このときに、あるデータ単位ごとにブロック化して各々のブロック単位で削除保留リストを使って管理するときに、ディスク別に削除保留すべき部分が異なるように処理することにより、キャッシュ・リプレースメントによって、ある程度のデータ削除処理が進んだ段階においても、キャッシュグループ内の近隣のキャッシュディスクからデータを集めることによって、元のコンテンツデータを迅速に再生することができる。短いコンテンツデータであれば、コンテンツ別に削除保留にすべきものをディスク別に異なるように設定することで、同様の管理が可能である。
【００１５】
【課題を解決するための手段】
本発明の第１の側面は、
ネットワークを介して受信したデータをキャッシュデータとして格納し、端末からのデータ要求に応じてキャッシュデータを取得して端末に送信するキャッシュ装置であり、
自キャッシュ装置およびネットワークに接続された他のキャッシュ装置によって構成され、コンテンツを構成する複数のデータ・ブロックを分散格納してコンテンツの共同管理を行うキャッシュグループに関するグループ設定情報を格納したテーブルであり、キャッシュグループが共同管理するコンテンツの識別子と、キャッシュグループを構成するキャッシュ装置数：Ｎと、各キャッシュ装置に対応して設定されるグループ・メンバー番号：ｍを格納したキャッシュグループ・テーブルと、
自キャッシュ装置に保持されたデータ・ブロックの管理データであるＬＲＵリストから削除予定データ・ブロックを検索し、削除予定データ・ブロックが前記キャッシュグループにおける自己の記憶担当データである保留データ・ブロックであるか否かを前記キャッシュグループ・テーブルの格納パラメータを適用した算出式の算出結果に基づいて決定し、削除予定データ・ブロックが保留データ・ブロックである場合は削除せずに削除保留リストによる管理対象として自キャッシュ装置に保持し管理する処理を行う制御手段と、
を有することを特徴とするキャッシュ装置にある。
【００１６】
さらに、本発明のキャッシュ装置の一実施態様において、前記制御手段は、共同管理するコンテンツを構成する複数のデータ・ブロックから、自キャッシュ装置における記憶保持対象とする保留データ・ブロックの決定処理を、以下の処理、すなわち、
判定対象データ・ブロックが構成要素となるコンテンツの先頭データ・ブロックからのオフセット情報としてのブロックオフセット番号：Ｃに基づいて、
Ｃ ｍｏｄ Ｎを算出し、
Ｃ ｍｏｄ Ｎ＝０の場合はＶ＝Ｎ、
Ｃ ｍｏｄ Ｎ≠０の場合はＶ＝（Ｃ ｍｏｄ Ｎ）として、
Ｖ＝ｍであるか否かを判定し、
Ｖ＝ｍである場合に、該データ・ブロックを保留データ・ブロックとして決定する処理、
を実行する構成であることを特徴とする。
【００１７】
さらに、本発明のキャッシュ装置の一実施態様において、前記制御手段は、記憶手段に格納したデータ・ブロックについての管理リストであるＬＲＵリストからの排除対象エントリに対応するデータ・ブロックについて、前記キャッシュグループによる共同管理が可能か否かをキャッシュ装置間のメッセージ送受信により判定し、共同管理可能であると判定した場合に、前記キャッシュグループ・テーブルを生成する構成であることを特徴とする。
【００１８】
さらに、本発明のキャッシュ装置の一実施態様において、前記制御手段は、記憶手段に格納したデータ・ブロックについての管理リストであるＬＲＵリストからの排除対象エントリに対応するデータ・ブロックについて、前記キャッシュグループ・テーブルの格納情報に基づいて、コンテンツを構成する複数のデータ・ブロック中から、自キャッシュ装置における記憶保持データとしての保留データ・ブロックを決定し、決定した保留データ・ブロック以外のデータ・ブロックについては、削除の許容されるデータ・ブロック管理リストとしてのフリーブロックリストにより管理する構成であることを特徴とする。
【００１９】
さらに、本発明のキャッシュ装置の一実施態様において、前記削除保留リストは、データ・ブロックの保存優先度に応じた複数のリストによって構成され、前記制御手段は、データ・ブロックの保存優先度を判定し、該判定結果に基づいて選択した削除保留リストに対して前記管理データ・ブロックに対応するエントリの設定を行なう構成であることを特徴とする。
【００２０】
さらに、本発明のキャッシュ装置の一実施態様において、前記制御手段は、端末からのコンテンツ取得要求が、前記キャッシュグループによる共同管理対象のコンテンツ取得要求である場合に、取得要求対象のコンテンツを構成するデータ・ブロックが前記キャッシュグループを構成するいずれのキャッシュ装置の保持対象データ・ブロックであるかを判定し、該判定結果に基づいてデータ・ブロックを自キャッシュ装置または、前記キャッシュグループを構成する他のキャッシュ装置から取得する処理を実行する構成であることを特徴とする。
【００２１】
さらに、本発明のキャッシュ装置の一実施態様において、前記制御手段は、取得要求対象のデータ・ブロックが構成要素となるコンテンツの先頭データ・ブロックからのオフセット情報としてのブロックオフセット番号：Ｃに基づいて、
Ｃ ｍｏｄ Ｎを算出し、
Ｃ ｍｏｄ Ｎ＝０の場合はＶ＝Ｎ、
Ｃ ｍｏｄ Ｎ≠０の場合はＶ＝（Ｃ ｍｏｄ Ｎ）として、
Ｖ＝ｍを算出し、
算出したｍをグループ・メンバー番号として有するキャッシュ装置からデータ・ブロックの取得処理を実行する構成であることを特徴とする。
【００２２】
さらに、本発明の第２の側面は、
ネットワークを介して受信したデータをキャッシュデータとして格納し、端末からのデータ要求に応じてキャッシュデータを取得して端末に送信するキャッシュ装置におけるキャッシュデータ管理方法であり、
前記キャッシュ装置の制御手段が、自キャッシュ装置に保持されたデータ・ブロックの管理データであるＬＲＵリストから削除予定データ・ブロックを検索するステップと、
前記制御手段が、自キャッシュ装置およびネットワークに接続された他のキャッシュ装置によって構成され、コンテンツを構成する複数のデータ・ブロックを分散格納してコンテンツの共同管理を行うキャッシュグループに関するグループ設定情報を格納したテーブルであり、キャッシュグループが共同管理するコンテンツの識別子と、キャッシュグループを構成するキャッシュ装置数：Ｎと、各キャッシュ装置に対応して設定されるグループ・メンバー番号：ｍを格納したキャッシュグループ・テーブルの格納パラメータを適用した算出式の算出結果に基づいて、前記削除予定データ・ブロックが前記キャッシュグループにおける自己の記憶担当データである保留データ・ブロックであるか否かを決定する保留データ・ブロック決定ステップと、
前記制御手段が、前記削除予定データ・ブロックが保留データ・ブロックである場合は削除せずに削除保留リストによる管理対象として自キャッシュ装置に保持し管理する処理を行うステップと、
を有することを特徴とするキャッシュデータ管理方法にある。
【００２３】
さらに、本発明のキャッシュデータ管理方法の一実施態様において、前記保留データ・ブロック決定ステップは、共同管理するコンテンツを構成する複数のデータ・ブロックから、自キャッシュ装置における記憶保持対象とする保留データ・ブロックの決定処理を、以下の処理、すなわち、
判定対象データ・ブロックが構成要素となるコンテンツの先頭データ・ブロックからのオフセット情報としてのブロックオフセット番号：Ｃに基づいて、
Ｃ ｍｏｄ Ｎを算出し、
Ｃ ｍｏｄ Ｎ＝０の場合はＶ＝Ｎ、
Ｃ ｍｏｄ Ｎ≠０の場合はＶ＝（Ｃ ｍｏｄ Ｎ）として、
Ｖ＝ｍであるか否かを判定し、
Ｖ＝ｍである場合に、該データ・ブロックを保留データ・ブロックとして決定する処理を実行することを特徴とする。
【００２４】
さらに、本発明のキャッシュデータ管理方法の一実施態様において、前記キャッシュデータ管理方法は、さらに、前記制御手段が、記憶手段に格納したデータ・ブロックについての管理リストであるＬＲＵリストからの排除対象エントリに対応するデータ・ブロックについて、前記キャッシュグループによる共同管理が可能か否かをキャッシュ装置間のメッセージ送受信により判定し、共同管理可能であると判定した場合に、前記キャッシュグループ・テーブルを生成する処理を実行することを特徴とする。
【００２５】
さらに、本発明のキャッシュデータ管理方法の一実施態様において、前記キャッシュデータ管理方法は、さらに、前記制御手段が、記憶手段に格納したデータ・ブロックについての管理リストであるＬＲＵリストからの排除対象エントリに対応するデータ・ブロックについて、前記キャッシュグループ・テーブルの格納情報に基づいて、コンテンツを構成する複数のデータ・ブロック中から、自キャッシュ装置における記憶保持データとしての保留データ・ブロックを決定し、決定した保留データ・ブロック以外のデータ・ブロックについては、削除の許容されるデータ・ブロック管理リストとしてのフリーブロックリストにより管理するステップを含むことを特徴とする。
【００２６】
さらに、本発明のキャッシュデータ管理方法の一実施態様において、前記削除保留リストは、データ・ブロックの保存優先度に応じた複数のリストによって構成され、前記キャッシュデータ管理方法は、さらに、前記制御手段が、データ・ブロックの保存優先度を判定し、該判定結果に基づいて選択した削除保留リストに対して前記管理データ・ブロックに対応するエントリの設定を行なうステップを含むことを特徴とする。
【００２７】
さらに、本発明のキャッシュデータ管理方法の一実施態様において、前記キャッシュデータ管理方法は、さらに、前記制御手段が、端末からのコンテンツ取得要求が、前記キャッシュグループによる共同管理対象のコンテンツ取得要求である場合に、取得要求対象のコンテンツを構成するデータ・ブロックが前記キャッシュグループを構成するいずれのキャッシュ装置の保持対象データ・ブロックであるかを判定し、該判定結果に基づいてデータ・ブロックを自キャッシュ装置または、前記キャッシュグループを構成する他のキャッシュ装置から取得するデータ・ブロック取得処理を実行するステップを含むことを特徴とする。
【００２８】
さらに、本発明のキャッシュデータ管理方法の一実施態様において、前記キャッシュグループ・テーブルは、キャッシュグループによって共同管理するコンテンツの識別子と、キャッシュグループを構成するキャッシュ装置数：Ｎと、各キャッシュ装置に対応して設定されるグループ・メンバー番号：ｍとを有し、前記データ・ブロック取得処理は、取得要求対象のデータ・ブロックが構成要素となるコンテンツの先頭データ・ブロックからのオフセット情報としてのブロックオフセット番号：Ｃに基づいて、
Ｃ ｍｏｄ Ｎを算出し、
Ｃ ｍｏｄ Ｎ＝０の場合はＶ＝Ｎ、
Ｃ ｍｏｄ Ｎ≠０の場合はＶ＝（Ｃ ｍｏｄ Ｎ）として、
Ｖ＝ｍを算出し、
算出したｍをグループ・メンバー番号として有するキャッシュ装置からデータ・ブロックを取得する処理として実行することを特徴とする。
【００２９】
さらに、本発明の第３の側面は、
ネットワークを介して受信したデータをキャッシュデータとして格納し、端末からのデータ要求に応じてキャッシュデータを取得して端末に送信するキャッシュ装置のプログラム実行部である制御手段にキャッシュデータ管理処理を実行させるコンピュータ・プログラムであり、
自キャッシュ装置に保持されたデータ・ブロックの管理データであるＬＲＵリストから削除予定データ・ブロックを検索させるステップと、
自キャッシュ装置およびネットワークに接続された他のキャッシュ装置によって構成され、コンテンツを構成する複数のデータ・ブロックを分散格納してコンテンツの共同管理を行うキャッシュグループに関するグループ設定情報を格納したテーブルであり、キャッシュグループが共同管理するコンテンツの識別子と、キャッシュグループを構成するキャッシュ装置数：Ｎと、各キャッシュ装置に対応して設定されるグループ・メンバー番号：ｍを格納したキャッシュグループ・テーブルの格納パラメータを適用した算出式の算出結果に基づいて、前記削除予定データ・ブロックが前記キャッシュグループにおける自己の記憶担当データである保留データ・ブロックであるか否かを決定させる保留データ・ブロック決定ステップと、
前記削除予定データ・ブロックが保留データ・ブロックである場合は削除せずに削除保留リストによる管理対象として自キャッシュ装置に保持し管理する処理を行わせるステップと、
を実行させることを特徴とするコンピュータ・プログラムにある。
【００３０】
【作用】
本発明の構成によれば、ネットワーク接続されたキャッシュ装置におけるキャッシュ・リプレースメント処理において、削除保留ブロックに関するリストを保持して、キャッシュグループ内のキャッシュ装置ごとに各々削除保留されるデータ・ブロックが異なるようにデータ管理を行なう構成としたので、各キャッシュ装置が単独でキャッシュ・リプレースメントの管理をしている場合に比べて効率的な記憶領域の利用が図れ、また、端末からのデータ要求に応じて複数のキャッシュ装置に記憶したデータ・ブロックを集めて送信することが可能となり、ネットワークトラフィックの軽減、キャッシュ装置のヒット率の向上が実現される。
【００３１】
さらに、本発明の多段の削除保留リストを適用したキャッシュ装置構成によれば、保持重要度の高いデータが削除されずにキャッシュに残る可能性が高くなるため、さらに、キャッシュヒット率の向上を達成することが可能となる。
【００３２】
なお、本発明のコンピュータ・プログラムは、例えば、様々なプログラム・コードを実行可能な汎用コンピュータ・システムに対して、コンピュータ可読な形式で提供する記憶媒体、通信媒体、例えば、ＣＤやＦＤ、ＭＯなどの記録媒体、あるいは、ネットワークなどの通信媒体によって提供可能なコンピュータ・プログラムである。このようなプログラムをコンピュータ可読な形式で提供することにより、コンピュータ・システム上でプログラムに応じた処理が実現される。
【００３３】
本発明のさらに他の目的、特徴や利点は、後述する本発明の実施例や添付する図面に基づくより詳細な説明によって明らかになるであろう。なお、本明細書においてシステムとは、複数の装置の論理的集合構成であり、各構成の装置が同一筐体内にあるものには限らない。
【００３４】
【発明の実施の形態】
以下、本発明のキャッシュ装置、およびキャッシュデータ管理方法について、図面を参照して、詳細に説明する。
【００３５】
［キャッシュ装置および処理概要］
図２は、本発明のキャッシュ装置を適用可能なネットワークシステムの全体構成例を示す図である。この図２に示す構成は、一般的なインターネット・キャッシュ装置、サーバー装置、端末装置から成るシステムと同様である。本発明のキャッシュ装置は、従来のネットワークシステム構成での適用が可能であり、ネットワーク内の複数のキャッシュ装置でグループ設定を行ない、グループ内においてキャッシュデータの管理を実行する。
【００３６】
各キャッシュ装置１（２１１）〜キャッシュ装置４（２１４）は、お互いにネットワークで接続されていると共に、コンテンツサーバー２０１から配信されるデータ（コンテンツ）を一時的に保存する機能を持つ。キャッシュ装置２１１〜２１４のネットワーク下流側には、コンテンツを受信する複数の端末装置、例えばユーザーＰＣ、携帯通信端末等の各種端末を接続できる構成となっている。
【００３７】
キャッシュ装置１（２１１）には、コンテンツ受信端末としての端末２２１ａ〜ｃ・・、キャッシュ装置２（２１２）には、端末２３１ａ〜ｃ・・、キャッシュ装置３（２１３）には、端末２４１ａ〜ｂ・・、キャッシュ装置４（２１４）には、端末２５１ａ〜ｃ・・がそれぞれ接続される。
【００３８】
ある端末からコンテンツデータの取得要求があると、コンテンツサーバー２０１からデータを読み出すか、中間にあるキャッシュ装置からデータを読み出す。端末からのコンテンツ要求は、例えば、コンテンツファイルのリソース情報としてのＵＲＬ(Uniform Resource Locator)を指定したコンテンンツ取得要求メッセージの送信によって行なわれる。
【００３９】
キャッシュ装置に端末から取得要求のあったコンテンツのＵＲＬに対応するデータが保存されている場合は、このキャッシュ装置からデータを読み出す。キャッシュからのデータ読み出しにより、コンテンツサーバー２０１からキャッシュ装置間におけるデータ転送が省略可能となり、ネットワーク上のデータトラフィックが緩和される。
【００４０】
本発明の構成では、ネットワークで接続された複数のキャッシュ装置、例えば、図２に示すキャッシュ装置１（２１１）〜キャッシュ装置４（２１４）を「キャッシュグループ」としてグループ化し、これら複数のキャッシュ装置１（２１１）〜キャッシュ装置４（２１４）間で、コンテンツの共同管理、すなわち複数のキャッシュ装置１（２１１）〜キャッシュ装置４（２１４）でのコンテンツの分散保持を実行する。以下、本発明におけるキャッシュ管理の構成、および方法について説明する。
【００４１】
図２のキャッシュグループに属する４つのキャッシュ装置１（２１１）〜キャッシュ装置４（２１４）に、例えば図３に示すように、同じコンテンツデータがキャッシュされているとする。コンテンツは、データ・ブロック１〜７からなる。図３のように各キャッシュ装置１（２１１）〜キャッシュ装置４（２１４）で同じデータ・ブロック１〜７を保存しているものとする。これらのデータ・ブロック１〜７は、それぞれのキャッシュ装置１（２１１）〜キャッシュ装置４（２１４）がそれぞれの接続端末からの要求に応じて、コンテンツサーバー２０１から受信し、一時記憶しているデータ、すなわちキャッシュデータである。
【００４２】
もし、従来と同様、個々のキャッシュ装置が単独で、キャッシュ・リプレースメント処理を実行すると、個々のキャッシュ装置は、新しく記憶手段に格納、すなわちキャッシュすべきデータを保存するために、端末からの取得要求頻度の低いデータ・ブロックを削除することになる。この削除したデータを再度提供する場合には、既にキャッシュ装置にデータが無いために、コンテンツサーバー２０１へデータを取りに行くことになる。
【００４３】
本発明のキャッシュ装置は、複数のキャッシュ装置１（２１１）〜キャッシュ装置４（２１４）で構成するキャッシュグループで、データを共同管理する。
【００４４】
本発明のキャッシュデータ管理方法では、同じコンテンツデータを持つ複数のキャッシュ装置を使ってキャッシュをグループ化してキャッシュするデータを管理する。本発明におけるキャッシュ装置のキャッシュ・リプレースメントは、キャッシュグループを構成する複数のキャッシュ装置１（２１１）〜キャッシュ装置４（２１４）を単位として実行する。
【００４５】
キャッシュグループを構成するキャッシュ装置ごとに削除されずに残っているデータが異なるデータとなるように制御されてデータ削除を実行する。従って、キャッシュ装置におけるデータ格納領域の効率的利用が可能となる。さらに、端末からのデータ要求に応答して、キャッシュグループの複数キャッシュ装置から各格納データを転送して端末に対する出力が可能となり、総合的にキャッシュ装置のヒット率を向上させることが可能となる。
【００４６】
具体例について、図を参照して説明する。図３のように、キャッシュグループを構成する複数のキャッシュ装置１（２１１）〜キャッシュ装置４（２１４）の各々が、同じコンテンツデータ・ブロック１〜７を格納していた場合、キャッシュグループを単位としたデータ管理により、キャッシュ装置ごとに削除されずに残っているデータが異なるデータとなるようにデータ削除、すなわちキャッシュ・リプレースメントを実行する。
【００４７】
このキャッシュグループを単位としたキャッシュ・リプレースメントの結果、図４に示すように、キャッシュ装置１（２１１）は、データ・ブロック１，５をキャッシュデータとして保持し、データ・ブロック２，３，４，６，７をフリーリスト（削除データ・ブロックに相当）に移動する。キャッシュ装置２（２１２）は、データ・ブロック２，６をキャッシュデータとして保持し、データ・ブロック１，３，４，５，７をフリーリストに移動する。キャッシュ装置３（２１３）は、データ・ブロック３，７をキャッシュデータとして保持し、データ・ブロック１，２，４，５，６をフリーリストに移動する。キャッシュ装置４（２１４）は、データ・ブロック４をキャッシュデータとして保持し、データ・ブロック１，２，３，５，６，７をフリーリストに移動する。
【００４８】
このように、キャッシュグループを構成する複数のキャッシュ装置１（２１１）〜キャッシュ装置４（２１４）全体としてキャッシュ・リプレースメントを行ない、コンテンツ共同管理を実行する。キャッシュグループ単位でのキャッシュ・リプレースメント処理の具体的処理態様について説明する。
【００４９】
あらかじめ決めた一定の時間間隔ごとに、各キャッシュ装置が独自に持っているＬＲＵリスト（図１参照）から、キャッシュ・リプレースメントによって近々に消去される可能性のある順にブロックをスキャンし、その消去予定のブロックに対応するコンテンツを持つキャッシュ装置が近隣にあるかどうかを問い合わせ、さらに、問い合わせ先のキャッシュ装置が消去予定のコンテンツを持っている場合には、相互にキャッシュグループを組めるか否かを確認する。
【００５０】
このような問い合わせに適用する送受信メッセージは、例えばネットワーク接続されたキャッシュ間のメッセージ送受信プロトコルとして定義されたＩＣＰ（Internet Cache Protocol）プロトコルが適用可能である。従来のＩＣＰの仕様中には、キャッシュグループに参加できるかどうかの確認機能についてまで規定されていないが、例えば、ＩＣＰ中のオペコードの１つとして定義されているＩＰ＿ＯＰ＿ＱＵＥＲＹメッセージ中のＯＰＴＩＯＮ Ｆｌａｇを拡張して、キャッシュグループに参加できるかどうかの確認メッセージを送受信することが可能である。
【００５１】
ネットワーク接続されたキャッシュ間のメッセージ送受信プロトコルとして定義されたＩＣＰ（Internet Cache Protocol）プロトコルのフォーマットを図５（ａ）に、ＩＣＰ中のオペコードの１つとして定義されているＩＰ＿ＯＰ＿ＱＵＥＲＹメッセージフォーマットを図５（ｂ）に示す。ＩＣＰフォーマットは、図５（ａ）に示すように、オペコード、バージョン、メッセージ長、リクエストＮｏ．、オプション、オプションデータ、送信側ホストアドレス、ペイロードの各データフィールドを有する。
【００５２】
特定のコンテンツデータを持っているか、およびキャッシュグループに参加できるかを、近隣のキャッシュ装置に問い合わせる際には、コンテンツファイルのリソース情報としてのＵＲＬ(Uniform Resource Locator)を指定して、近隣キャッシュ装置に問い合わせメッセージを送信する。この問い合わせメッセージの１形態として、ＩＣＰ（Internet Cache Protocol）プロトコルのＯＰＴＩＯＮ Ｆｌａｇの拡張を行ない、ＩＣＰ＿ＯＰ＿ＱＵＥＲＹで、コンテンツファイルのリソース情報としてのＵＲＬを指定するとともに、このコンテンツについてキャッシュグループのメンバーとして参加可能かの確認の意味を含むフラグ（例えば、０ｘ２０００００００（ＩＣＰ＿ＦＬＡＧ＿ＧＲＯＵＰ＿ＲＥＱ））を追加する。なお、この問い合わせメッセージは、この手法に限らず、他のフォーマット、プロトコルを使用することも可能である。
【００５３】
なお、このコンテンツ保持問い合わせは、問い合わせを行なうキャッシュ装置が、マルチキャスト（Ｍｕｌｔｉｃａｓｔ）を適用して、複数の近隣キャッシュ装置に一度に問い合わせることも可能である。
【００５４】
なお、本発明において、「近隣のキャッシュ装置」とは、ある１つのキャッシュ装置に対してキャッシュグループとして組む可能性のあるキャッシュ装置の候補であり、例えばデータ送受信処理を、あらかじめ定めた許容時間内に実行可能なキャッシュ装置として設定される。
【００５５】
「近隣のキャッシュ装置」の具体的な設定態様としては、例えば、キャッシュ装置の設定ファイルにキャッシュグループを組める可能性のある複数のキャッシュ装置を予め登録し、これらの登録キャッシュ装置にｐｉｎｇなどを使ってキャッシュ装置間のＲＴＴ（Ｒｏｕｎｄ Ｔｒｉｐ Ｔｉｍｅ）を測定し、ＲＴＴが許容時間範囲内にある複数のキャッシュ装置を「近隣のキャッシュ装置」として設定することが可能である。
【００５６】
キャッシュグループの設定を実行するキャッシュ装置は、「近隣のキャッシュ装置」に関するリストを保持する。リストは、対象となるキャッシュ装置に関するデータとして、ホスト名、ＩＰアドレス、ＩＣＰポート番号を保存したリストである。
【００５７】
キャッシュ装置リスト構成例を図６に示す。キャッシュ装置リストは、図６に示すように、近隣のキャッシュ装置として設定されたキャッシュ装置に関するデータとして、ホスト名、ＩＰアドレス、ＩＣＰポート番号を保存したリストである。
【００５８】
コンテンツ保持の有無および、グループ参加可否についての問い合わせを近隣のキャッシュ装置に対して実行しようとするキャッシュ装置は、例えば、ＩＣＰ＿ＯＰ＿ＱＵＥＲＹで、あるコンテンツデータに対応するＵＲＬを指定して問い合わせメッセージをブロードキャスト、マルチキャスト等により送信する。問い合わせを実行したキャッシュ装置は、問い合わせメッセージに対する答えを待つことになる。
【００５９】
しかし、応答を無限に待つことはできないし、マルチキャストで問い合わせした場合は、どれだけ返事が戻るか不明であるため、あらかじめ決めた一定時間の範囲内において、ヒット（ＨＩＴ）応答、すなわち問い合わせに係るＵＲＬに関連するコンテンツデータを持っているとの応答が何処からいくつ戻るかをカウントし内部のキャッシュグループ・テーブル（対象とするコンテンツデータの識別子（ＵＲＬ，コンテンツＩＤ等）、グループの構成メンバー数、グループＩＤ、キャッシュグループを構成するメンバーの（メンバー番号とＩＰアドレスリストの対データ））に記憶する。
【００６０】
応答メッセージは、問い合わせに係るＵＲＬに関連するコンテンツデータを持っているとの応答として、例えばＩＣＰメッセージのＩＣＰ＿ＯＰ＿ＨＩＴ、また、コンテンツデータを持っていない旨の応答として、ＩＣＰ＿ＯＰ＿ＭＩＳＳを用いた応答メッセージが適用可能である。
【００６１】
上述の問い合わせメッセージを受信したキャッシュ装置は、問い合わせを送信してきたキャッシュ装置とのキャッシュグループを構成するメンバーになることを承諾し、さらに、キャッシュグループ形成までの間、問い合わせのあったコンテンツに対応するデータ・ブロックを削除せずに保持できる能力を持つ場合に、ＨＩＴ応答を返す。
【００６２】
問い合わせメッセージを送信したキャッシュ装置と、ＨＩＴ応答を返した１以上のキャッシュ装置とによって、問い合わせメッセージの指定コンテンツに関するキャッシュグループを構成する。
【００６３】
問い合わせメッセージを送信し、応答メッセージを受信したキャッシュ装置が、１以上のＨＩＴ応答を受信してキャッシュグループを設定した場合は、キャッシュグループを構成するキャッシュ装置数（Ｎ），当該キャッシュ装置のキャッシュグループを構成するキャッシュ装置（メンバー）識別子としてのグループ・メンバー番号（ｍ）、キャッシュグループでの処理対象コンテンツデータ識別子（ＣＩＤ）などのグループ設定情報を、キャッシュグループを構成する各キャッシュ装置に伝える。
【００６４】
なお、キャッシュ装置（メンバー）識別子としてのグループ・メンバー番号（ｍ）は、キャッシュ装置のＩＰアドレスに対応して設定され、キャッシュグループを構成する全てのキャッシュ装置（メンバー）は、キャッシュグループを構成する他の全てのキャッシュ装置（メンバー）識別子としてのグループ・メンバー番号（ｍ）とＩＰアドレスの対応情報を取得する。
【００６５】
グループ設定情報の伝達には、上述の問い合わせメッセージと同様、ＩＣＰが適用可能である。例えば、ＩＣＰにおいて、情報通知のためのＩＣＰ＿ＯＰ＿ＮＯＴＩＦＹのようなオペコードを独自に追加し、ペイロード部分に図７のようなキャッシュ装置（メンバー）のグループ・メンバー番号と、ＩＰアドレスデータを格納してキャッシュグループを構成する各キャッシュ装置に送信し、通知することになる。なお、図７に示す例は、ＩＰアドレスとしてＩＰｖ４を適用した例である。
【００６６】
図７に示すように、ペイロード部には、キャッシュグループを構成する全て（Ｎ）のキャッシュ装置（メンバー）のグループ・メンバー番号（キャッシュ・メンバー＃１〜＃Ｎ）とＩＰアドレス情報が格納される。これらの情報を受領することにより、キャッシュグループを構成する全てのキャッシュ装置（メンバー）は、キャッシュグループを構成する他の全てのキャッシュ装置（メンバー）のグループ・メンバー番号とＩＰアドレスの対応を知ることができる。
【００６７】
グループ設定情報を伝達したキャッシュ装置、およびグループ設定情報を伝達された、キャッシュグループに属するキャッシュ装置は、図８に示すようなグループ設定情報を格納したキャッシュグループ・テーブルを自己の管理情報としてメモリに格納する。
【００６８】
キャッシュグループ・テーブルには、上述のグループ設定情報に基づいて取得される情報、すなわち、設定キャッシュグループにおいて共同管理するコンテンツの識別子、キャッシュグループの構成キャッシュ装置数［Ｎ］、キャッシュグループの識別子（ＩＤ）、およびキャッシュグループのメンバーリストとして、メンバー番号とＩＰアドレスの対応データとが格納される。
【００６９】
このようにして作成したキャッシュグループを構成する各キャッシュ装置は、単独のデータ（コンテンツ）管理ではなく、グループ全体でのコンテンツデータの管理を行なう。以下、キャッシュグループ内の各キャッシュ装置におけるコンテンツ管理方法について説明する。
【００７０】
キャッシュグループ内の各キャッシュ装置は、図９に示すように、利用頻度順にデータ・ブロックを並べた（ａ）ＬＲＵリストと、キャッシュの空き領域ブロックをポインタ情報として持つ（ｃ）フリーブロックリスト、さらに、（ｂ）削除保留リストを有する。
【００７１】
削除保留リストとは、ＬＲＵリストから排除、例えば削除対象ブロックとなったデータ・ブロックの内、一時的に削除保留状態に設定したデータ・ブロックを管理するリストである。ＬＲＵリストから排除するエントリに対応するデータ・ブロックを削除対象として、フリーブロックリストで管理するか、あるいは削除を保留すべきブロックとして、削除保留リストで管理するかの判定は、以下の処理手順によって行なう。
【００７２】
削除保留状態に設定するか否かの判定は、以下の処理手順について説明する。判定対象コンテンツの先頭からのブロックオフセット番号をＣ、キャッシュグループを構成するキャッシュ装置数をＮ、キャッシュグループにおける自己に設定されたグループ・メンバー番号をｍとしたときに、
（１） Ｃ ｍｏｄ Ｎを算出する。
（２） Ｃ ｍｏｄ Ｎ＝０の場合はＶ＝Ｎ、
Ｃ ｍｏｄ Ｎ≠０の場合はＶ＝（Ｃ ｍｏｄ Ｎ）として、
（３） Ｖ＝ｍであれば、削除保留状態に設定する。
Ｖ≠ｍであれば、削除保留状態に設定せず削除する。
【００７３】
上述の処理を、キャッシュグループを構成するキャッシュ装置の各々で実行することにより、先に図４を参照して説明したように、キャッシュ装置間で、重複の無いデータ・ブロックの格納構成が実現される。
【００７４】
すなわち、ｍ＝１であるキャッシュ装置１（２１１）は、データ・ブロック１，５を削除保留状態として保持し、削除保留リストの管理ブロックとし、データ・ブロック２，３，４，６，７を削除対象としてフリーリストで管理する。ｍ＝２であるキャッシュ装置２（２１２）は、データ・ブロック２，６を削除保留状態として保持し、削除保留リストの管理ブロックとし、データ・ブロック１，３，４，５，７をフリーリストで管理する。ｍ＝３であるキャッシュ装置３（２１３）は、データ・ブロック３，７を削除保留状態として保持し、削除保留リストの管理ブロックとし、データ・ブロック１，２，４，５，６をフリーリストで管理する。ｍ＝４であるキャッシュ装置４（２１４）は、データ・ブロック４を削除保留状態として保持し、削除保留リストの管理ブロックとし、データ・ブロック１，２，３，５，６，７をフリーリストで管理する構成が実現される。
【００７５】
上述の処理の詳細について、キャッシュグループ内の各キャッシュ装置の有するＬＲＵリスト、削除保留リスト、フリーブロックリストの内部構造を参照しながら説明する。
【００７６】
まず、ＬＲＵリストの構成について図１０を参照して説明する。図１０に示すように、各キャッシュ装置は、自己のキャッシュデータを格納する記憶手段としてのデータ格納領域３２０、およびデータ格納領域に格納したデータに対するリストとしてのＬＲＵリスト３１０を有する。
【００７７】
ＬＲＵリスト３１０は、各データ・ブロックに対応付けて生成される。ここでは、（ａ）〜（ｐ）のリストデータ（エントリ）が各データ・ブロックに対応付けられて保持されている。ＬＲＵリストの内部構造は、図１０に示すように、データ・ブロックヘのポインタ３１１、コンテンツ識別子３１２、ブロックオフセット３１３、ＬＲＵリストの前リストデータ（エントリ）のポインタ３１４、ＬＲＵリストの後続リストデータ（エントリ）のポインタ３１５を有する。
【００７８】
データ・ブロックヘのポインタ３１１は、各リストデータに対応する実コンテンツデータ・ブロックの、データ格納領域３２０における格納アドレスを示す。コンテンツ識別子３１２は、例えばＵＲＬ、または各データ・ブロックの識別データによって構成されるコンテンツＩＤである。ブロックオフセット３１３は、各コンテンツデータ・ブロックのコンテンツ先頭からのオフセットを示す。
【００７９】
オフセットは、例えばデータ格納領域におけるアドレス差分を用いることも可能であるが、ここでは、ある大きさごとにデータを区切ったブロックという単位で管理することにすると、先頭からのブロックオフセット番号Ｃの値が入る。（ａ）のリストに対して設定されるブロックオフセットは１、（ｂ）のリストに対して設定されるブロックオフセットは２となり、（ｐ）のリストに対して設定されるブロックオフセットは、コンテンツデータのブロックサイズがＮブロック分あるとすると、Ｎとなる。このようにブロックオフセットは、コンテンツ毎の、コンテンツ先頭からの位置識別データとしてのブロックオフセット番号Ｃとして設定される。
【００８０】
ＬＲＵリストの前リストデータ（エントリ）のポインタ３１４、ＬＲＵリスト後リストデータ（エントリ）のポインタ３１５は、それぞれ、リストの前後のエントリに対するポインタを示すデータである。従って、リスト先頭のリストデータ（ａ）の前リストデータのポインタはＮＵＬＬ、リスト最後尾のリストデータ（ｐ）の後リストデータのポインタもＮＵＬＬとして設定される。
【００８１】
ＬＲＵリスト中の各エントリが持つデータ・ブロックへのポインタに対応するコンテンツの識別子および先頭からのブロックオフセット番号：Ｃは、このエントリ中のデータを読むことで簡単に知ることが出来る。
【００８２】
次に、削除保留リストの構成について、図１１を参照して説明する。削除保留リストとは、前述したように、ＬＲＵリストで削除対象ブロックとなったデータ・ブロックの内、一時的に削除保留状態に設定したデータ・ブロックを管理するリストである。
【００８３】
図１１に示すように、キャッシュ装置の保有する削除保留リスト３３０は、削除保留状態に設定したデータ・データ・ブロックに対応付けて生成される。ここでは、（ａ）〜（ｐ）のリストデータ（エントリ）が削除保留状態に設定したデータ・データ・ブロックに対応付けられて保持されている。削除保留リストの内部構造は、図１１に示すように、データ・ブロックヘのポインタ３３１、コンテンツ識別子３３２、ブロックオフセット３３３、設定されたキャッシュグループのグループ識別子（ＧＰ）３３４、削除保留リストの前リストデータ（エントリ）のポインタ３３５、削除保留リストの後続リストデータ（エントリ）のポインタ３３６を有する。
【００８４】
キャッシュ装置の保有する削除保留リスト３３０の格納データは、先に説明したＬＲＵリストの格納データにグループ識別子（ＧＰ）３３４を付加した構成となる。グループ識別子（ＧＰ）３３４は、キャッシュグループ作成時に設定されるキャッシュグループを識別するグループＩＤである。キャッシュグループを設定したキャッシュ装置によって設定され、キャッシュグループを構成する他のキャッシュ装置は、キャッシュグループを設定したキャッシュ装置から送信されるグループ設定情報により通知され、キャッシュグループ・テーブル（図８参照）に記録されたＩＤである。
【００８５】
次に、フリーブロックリストの構成について、図１２を参照して説明する。フリーブロックリストとは、前述したように、ＬＲＵリストで削除対象ブロックとなったデータ・ブロックの内、削除保留状態に設定されずに削除対象となったデータ・ブロック、および削除保留状態に一旦、設定されたものの、その後、削除対象となったデータ・ブロックに対応する管理リストである。
【００８６】
図１２に示すように、キャッシュ装置の保有するフリーブロックリスト３５０は、データ格納領域３２０のデータ格納ブロック中、上書き、消去可能なデータ・ブロックへのポインタ３５１を持ち、フリーブロックリストの前リストデータ（エントリ）のポインタ３５２、フリーブロックリストの後続リストデータ（エントリ）のポインタ３５３を有する。
【００８７】
次に、キャッシュグループを構成する各キャッシュ装置において、新規入力データが発生し、データ・ブロックを削除保留リスト、あるいはフリーブロックリストの管理データに移行する際の処理手順について説明する。
【００８８】
まず、キャッシュ装置は、ＬＲＵリストから処理対象とするデータ・ブロックに対応するエントリ（リストデータ）を抽出し、抽出したＬＲＵリストのエントリからブロックオフセット番号：Ｃ（図１０：ブロックオフセット３１３）を読み出す。
【００８９】
次に、キャッシュ装置は、ブロックオフセット番号：Ｃの値に基づいて、上述した処理を実行する。すなわち、
（１） Ｃ ｍｏｄ Ｎを算出する。
（２） Ｃ ｍｏｄ Ｎ＝０の場合はＶ＝Ｎ、
Ｃ ｍｏｄ Ｎ≠０の場合はＶ＝（Ｃ ｍｏｄ Ｎ）、
として、
（３）Ｖ＝ｍであれば、削除保留状態に設定、すなわち、
対応するデータ・ブロックの管理リストデータを削除保留リストに移動する。このデータ・ブロックは、データ格納領域において消去されずに保持される。
（３’）一方、Ｖ≠ｍであれば、削除保留状態に設定しない。すなわち、
対応するデータ・ブロックの管理リストデータをフリーブロックリストに移動する。このデータ・ブロックは、データ格納領域において消去、上書き可能ブロックとして設定されることになる。
【００９０】
Ｖ＝ｍである場合は、設定したキャッシュグループにおいて、自装置がそのデータ・ブロックを保留すべきであると判定し、ＬＲＵリストからの削除予定エントリを削除保留リストに移動し、コンテンツデータ・ブロックを削除することなく、メモリに残し、削除保留リストでの管理を実行する。また、Ｖ≠ｍの場合は、設定したキャッシュグループにおいて、自装置がデータ・ブロックを保留する必要がない、すなわち、そのデータ・ブロックは、他のグループ・メンバーにおいて保持すべきデータ・ブロックであると判定し、ＬＲＵリストからの削除予定エントリをフリーブロックリストに移動して、対応データ・ブロックを削除可能状態とするものである。なお、削除されたデータ・ブロックは、キャッシュグループの他のメンバーが保持しており、これを取得して端末に送信可能となる。この処理については後述する。
【００９１】
リストに対するエントリの移動は、図９に示す処理となる。例えばキャッシュ装置１において、新規データ・ブロックの書き込み要求があると、（ｃ）フリーブロックリストの先頭エントリ２７１に設定されたデータ・ブロック・ポインタに対応するデータ格納領域のデータ記憶領域に新規データ・ブロックが書き込まれ、書き込まれたデータ・ブロックに関する情報は、図１０のＬＲＵリストの先頭エントリ２７２に移される。
【００９２】
その結果、もしＬＲＵリストの長さが許容リスト長を超えることになった場合は、ＬＲＵリストの末尾のエントリ２７３が、削除保留リストあるいは、フリーブロックリストに移動することになる。どちらに移動するかの判定は、前述の（１）〜（３）に示すＣ ｍｏｄ Ｎの算出、Ｖの値の判定に従う。
【００９３】
上述した判定処理の結果、ＬＲＵリストの末尾のエントリ２７３を削除保留リストに移動すると決定した場合は、ＬＲＵリストの末尾のエントリ２７３が削除保留リストの末尾のエントリ２７４として設定される。また、上述した判定処理の結果、フリーブロックリストに移動すると決定した場合は、ＬＲＵリストの末尾のエントリ２７３がフリーブロックリストの末尾のエントリ２７５として設定される。
【００９４】
また、削除保留リストに新たなエントリが加わり、削除保留リストが予め定められたリスト長を超えることとなった場合は、削除保留リストの先頭のエントリ２７６が、フリーブロックリストの末尾のエントリ２７５として設定される。
【００９５】
なお、フリーブロックリストに対応して確保すべきバッファ量が、予め定められており、これが、新規データの格納により不足することとなった場合は、ＬＲＵリストあるいは削除保留リストからのフリーブロックリストへの移動、すなわちデータ・ブロックの削除によるバッファ量確保処理が実行される。
【００９６】
フリーブロックリストへ移動されたエントリの指定するデータ・ブロック・ポインタの指定するメモリ領域は、新たな入力データの書き込みに適用され、データ・ブロックの内容が捨てられることになる。
【００９７】
［キャッシュグループ形成およびデータ管理処理］
次に、上述したキャッシュグループにおけるグループ形成、データ管理の手順について、フローチャートおよびシーケンス図を参照して説明する。
【００９８】
まず、キャッシュグループの生成処理、データ管理手順について、図１３および図１４を参照して説明する。
【００９９】
キャッシュグループは、自己のキャッシュ装置に格納したコンテンツのデータ・ブロックをＬＲＵリストから削除保留リストによる管理に移動して、グループでの共同管理を行なう場合に生成される。図１３のフローに従って、キャッシュグループの生成処理手順について説明する。
【０１００】
まず、ネットワーク接続されたキャッシュ装置は、事前準備処理として、キャッシュグループのメンバー候補の登録を行なう。これは、図１３におけるステップＳ１０１〜Ｓ１０４のステップである。
【０１０１】
ステップＳ１０１において、キャッシュグループを組む可能性のあるキャッシュ装置情報を登録する。これは、例えばオペレータが選択した１以上のキャッシュ装置のホスト名、ＩＰアドレス、ＩＣＰポート番号の登録情報である。
【０１０２】
次に、これらの登録情報から実際にキャッシュグループを設定可能なキャッシュ装置を判定する。これは、ステップＳ１０１において登録された各キャッシュ装置にｐｉｎｇなどを使ってキャッシュ装置間のＲＴＴ（Ｒｏｕｎｄ ＴｒｉｐＴｉｍｅ）を測定し、ＲＴＴが許容時間範囲内にある複数のキャッシュ装置を選択するものであり、ステップＳ１０２のＲＴＴ測定処理、ステップＳ１０３の判定処理によって、あらかじめ定めた閾値以下のＲＴＴを持つキャッシュ装置をステップＳ１０４において、「近隣のキャッシュ装置」として設定する。
【０１０３】
キャッシュ装置は、「近隣のキャッシュ装置」として設定されたキャッシュ装置リストを保持する。リストは、先に図６を参照して説明したように、近隣のキャッシュ装置に関するホスト名、ＩＰアドレス、ＩＣＰポート番号を保存したリストである。
【０１０４】
図１３のステップＳ１０２〜Ｓ１０４のステップに対応するデータ通信シーケンスが図１４の［処理Ｐ］に相当する。図１４のシーケンス図においては、キャッシュ装置Ａが処理主体となるキャッシュ装置であり、キャッシュ装置Ｂ，Ｃ，Ｄが図１３のステップＳ１０１において登録されたキャッシュ装置に相当する。
【０１０５】
図１４の［処理Ｐ］がＲＴＴ測定処理に相当する。キャッシュ装置Ａは、キャッシュ装置Ｂ，Ｃ，Ｄに対して登録された各キャッシュ装置Ｂ，Ｃ，Ｄにｐｉｎｇなどを使ってキャッシュ装置間のＲＴＴ（Ｒｏｕｎｄ Ｔｒｉｐ Ｔｉｍｅ）を測定し、ＲＴＴが許容時間範囲内にある複数のキャッシュ装置を選択する。
【０１０６】
図１３のフローに戻り、説明を続ける。図６に示す近隣のキャッシュ装置リストが生成されると、キャッシュ装置は、ステップＳ１０５において、所定時間毎に、キャッシュ・リプレースメントにより、自己の保有するＬＲＵリストから削除すべきコンテンツデータ・ブロックが発生したか否かの判定を実行する。
【０１０７】
ＬＲＵリストから削除すべきデータ・ブロックがあると判定すると、ステップＳ１０６に進み、ＬＲＵリスト中の削除予定のエントリを抽出し、ステップＳ１０７において、そのエントリに対応するコンテンツがキャッシュグループ・テーブルに登録ずみのコンテンツであるかを判定する。
【０１０８】
キャッシュグループ・テーブルは、先に、図８を参照して説明したように、設定キャッシュグループにおいて共同管理するコンテンツの識別子、キャッシュグループの構成キャッシュ装置数［Ｎ］、キャッシュグループの識別子（ＩＤ）、およびキャッシュグループのメンバーリストとして、メンバー番号とＩＰアドレスの対応データとが格納されたテーブルであり、キャッシュグループ・テーブルに登録されたコンテンツは、設定されたキャッシュグループにおいて共同管理が実行されていることを示す。
【０１０９】
ステップＳ１０７において、ＬＲＵリストから削除予定のコンテンツがキャッシュグループ・テーブルに登録されている場合は、設定されたキャッシュグループにおいて共同管理が実行されているコンテンツであり、共同管理処理として、ステップＳ１１５以下の処理を実行することになる。この処理の詳細については、後段で説明する。
【０１１０】
ステップＳ１０７において、ＬＲＵリストから削除予定のコンテンツがキャッシュグループ・テーブルに登録されていない場合は、ステップＳ１０８以下において、ＬＲＵリストから削除予定のコンテンツに対応する新たなキャッシュグループを生成する。
【０１１１】
ステップＳ１０８では、先のステップＳ１０４で設定したＲＴＴが閾値以下の近隣キャッシュ装置リスト（図６参照）に設定された各キャッシュ装置に対して、ＬＲＵリストから削除予定のコンテンツに関するキャッシュグループを組むことが可能か否かの問い合わせメッセージを送信する。
【０１１２】
この問い合わせメッセージは、ＬＲＵリストから削除予定のエントリに対応するコンテンツ保持の有無および、グループ参加可否についての問い合わせメッセージである。図１４のシーケンス図では、［処理Ｑ］のＩＣＰ＿ＯＰ＿ＱＵＥＲＹがこの問い合わせメッセージに相当する。
【０１１３】
図１３のステップＳ１０９で、キャッシュ装置は、問い合わせメッセージに対する応答を待機し、ステップＳ１１０で応答が、グループ構成可（ＨＩＴ）であるか否かを判定し、ステップＳ１１１において、グループ構成可（ＨＩＴ）であるキャッシュ装置について、のデータをキャッシュグループ・テーブル（図８参照）に登録する。ステップＳ１１２では、全てのグループ・メンバー候補（図６の近隣キャッシュ装置リストに登録されたキャッシュ装置）に対する返事の確認が終了したかを判定して、キャッシュグループの仮設定を終える。
【０１１４】
図１４のシーケンス図では、［処理Ｑ］のＩＣＰ＿ＯＰ＿ＱＵＥＲＹ（問い合わせメッセージ）に対して、グループ構成可（ＨＩＴ）のキャッシュ装置Ｂ，Ｃが、ＩＣＰメッセージのＩＣＰ＿ＯＰ＿ＨＩＴをキャッシュ装置Ａに対する応答メッセージとして送信し、グループ構成不可（ＭＩＳＳ）のキャッシュ装置Ｄが、ＩＣＰメッセージのＩＣＰ＿ＯＰ＿ＭＩＳＳをキャッシュ装置Ａに対する応答メッセージとして送信している。この場合、キャッシュ装置Ａは、キャッシュ装置Ｂ，Ｃと、キャッシュグループを構成する。
【０１１５】
図１３の処理フローのステップＳ１１３では、キャッシュグループ設定可能な数のキャッシュ装置からのＨＩＴ応答が取得できたかを判定する。例えば１以上のキャッシュ装置からＨＩＴ応答が得られればキャッシュグループ設定可能と判定することができる。キャッシュグループ設定可能な数のキャッシュ装置のＨＩＴ応答がなかった場合は、ステップＳ１１８に進み、キャッシュグループは設定せずにＬＲＵリストからの削除エントリをフリーブロックリストに移動する。この場合は、当エントリに対応するコンテンツのキャッシュグループでの共同管理は実行されない。
【０１１６】
ステップＳ１１３で、キャッシュグループ設定可能な数のキャッシュ装置からのＨＩＴ応答が取得できたと判定された場合は、ステップＳ１１４において、ＨＩＴ応答を返したキャッシュ装置であり、キャッシュグループ・テーブル（図８参照）にキャッシュグループのメンバーとして登録されたキャッシュ装置に対してグループ設定情報を送信する。
【０１１７】
グループ設定情報は、キャッシュグループを構成するキャッシュ装置数（Ｎ），当該キャッシュ装置のキャッシュグループを構成するキャッシュ装置（メンバー）識別子としてのグループ・メンバー番号（ｍ）、キャッシュグループでの処理対象コンテンツデータ識別子などの情報である。グループ・メンバー番号（ｍ）は、キャッシュ装置のＩＰアドレスに対応して設定され、キャッシュグループを構成する全てのキャッシュ装置（メンバー）は、キャッシュグループを構成する他の全てのキャッシュ装置（メンバー）識別子としてのグループ・メンバー番号（ｍ）とＩＰアドレスの対応情報を取得する。
【０１１８】
図１４のシーケンス図において、［処理Ｒ］のＩＣＰ＿ＯＰ＿ＮＯＴＩＦＹが、グループ設定情報の送信に相当し、この送信データフォーマットは、例えば先に図７を参照して説明したフォーマットに従ったものとなる。グループ設定情報を伝達したキャッシュ装置、およびグループ設定情報を伝達された、キャッシュグループに属するキャッシュ装置は、図８に示すようなグループ設定情報格納したキャッシュグループ・テーブルを自己の管理情報としてメモリに格納する。
【０１１９】
次にステップＳ１１５以下が、設定されたキャッシュグループにおけるコンテンツの共同管理処理として実行されるＬＲＵリストからの移動処理である。
【０１２０】
キャッシュ装置は、ステップＳ１１５において、ＬＲＵリストからの削除予定エントリについて、ブロックオフセット番号：Ｃ、キャッシュグループを構成するキャッシュ装置数：Ｎ、キャッシュグループにおける自己に設定されたグループ・メンバー番号：ｍの各値に基づいて、
（１） Ｃ ｍｏｄ Ｎを算出し、
（２） Ｃ ｍｏｄ Ｎ＝０の場合はＶ＝Ｎ、
Ｃ ｍｏｄ Ｎ≠０の場合はＶ＝（Ｃ ｍｏｄ Ｎ）として、
（３）Ｖ＝ｍであるか否かを判定する。
【０１２１】
Ｖ＝ｍである場合は、設定したキャッシュグループにおいて、自装置がコンテンツを保留すべきであると判定し、ステップＳ１１６において、ＬＲＵリストからの削除予定エントリを削除保留リストに移動する。すなわち、コンテンツデータ・ブロックを削除することなく、メモリに残し、削除保留リストでの管理を実行する。
【０１２２】
Ｖ＝ｍでない場合は、設定したキャッシュグループにおいて、自装置がコンテンツを保留する必要がない、すなわち、他のグループ・メンバーにおいて保持すべきデータ・ブロックであると判定し、ステップＳ１１８において、ＬＲＵリストからの削除予定エントリをフリーブロックリストに移動する。この場合は、対応データ・ブロックは、削除されることになる。削除された場合でも、キャッシュグループの他のメンバーが保持しており、これを取得して端末に送信可能となる。この処理については後述する。
【０１２３】
さらに、ステップＳ１１６におけるＬＲＵリストから削除保留リストに対するエントリ移動により、削除保留リストのリスト長が許容値を超えることとなったとき（Ｓ１１７でＹｅｓ）は、ステップＳ１１８において、削除保留リストのエントリをフリーブロックリストに移動する処理を実行する。
【０１２４】
次に、図１５乃至図１７を参照して、キャッシュグループによるコンテンツ管理を実行しているキャッシュ装置に、端末からのコンテンツ要求が発生した場合の処理について説明する。
【０１２５】
図１５のステップＳ２０１において、キャッシュ装置が端末からコンテンツ取得要求を受信すると、キャッシュ装置は、ステップＳ２０２において、要求コンテンツデータがキャッシュグループ・テーブル（図８参照）に登録されたコンテンツであるか否かを判定する。登録されていない場合は、グループ管理されていないコンテンツであり、通常の処理、すなわち自装置に格納されている場合は、コンテンツを取得して端末に送信し、自装置に格納されていない場合は、コンテンツをコンテンツサーバーから取得して端末に送信する。
【０１２６】
要求コンテンツデータがキャッシュグループ・テーブル（図８参照）に登録されたコンテンツである場合は、グループ管理されているコンテンツであり、ステップＳ２０３で、キャッシュグループ・テーブル（図８参照）からキャッシュグループの構成要素数Ｎと、自身のメンバー番号ｍ１を取得する。
【０１２７】
ステップＳ２０４において、端末からのコンテンツ取得要求中に含まれるコンテンツのオフセット情報に基づいて、ブロックオフセットを算出して、ブロックオフセット番号：Ｃを取得する。次に、ステップＳ２０５において、キャッシュグループを構成するキャッシュ装置数：Ｎ、キャッシュグループにおける自己に設定されたグループ・メンバー番号：ｍ１の各値に基づいて、
（１） Ｃ ｍｏｄ Ｎを算出し、
（２） Ｃ ｍｏｄ Ｎ＝０の場合はＶ＝Ｎ、
Ｃ ｍｏｄ Ｎ≠０の場合はＶ＝（Ｃ ｍｏｄ Ｎ）として、
（３）Ｖ＝ｍ１であるか否かを判定する。
【０１２８】
Ｖ＝ｍ１である場合は、要求されたコンテンツが自装置内に格納されていることになり、ステップＳ２０６に進み、ＬＲＵリストまたは削除保留リストのエントリに基づいて要求コンテンツ名、ブロックオフセット番号から自装置内のデータ格納領域情報を取得し、ステップＳ２０７において、データの読み出しを実行し、正常読み出し完了を確認（Ｓ２０８）し、ステップＳ２０９において、グループＩＤ（Ｇｐ）＝０であるか否かを判定する。
【０１２９】
グループＩＤ（Ｇｐ）＝０は、設定されたキャッシュグループのメンバー離脱が発生して、キャッシュグループの維持を行なわない際にキャッシュ装置が、キャッシュグループ・テーブルのグループＩＤ（Ｇｐ）を書き換えることにより設定される。グループＩＤ（Ｇｐ）が、０の場合は、キャッシュグループから離脱したメンバーが多くなってグループを構成できないことを示すエントリであるため、ステップＳ２１０において、エントリを削除保留リストではなくＬＲＵリストの先頭に移動させる。
【０１３０】
また、グループＩＤ（Ｇｐ）＝０でない場合は、ステップＳ２１１において、データ・ブロックがアクセスをされたことから、削除保留リストの先頭に該当のエントリを移す。
【０１３１】
さらに、ステップＳ２１２で、読み出しデータを要求端末に送信し、指定サイズデータの送信の完了を確認（Ｓ２１３）し、未終了である場合は、ステップＳ２１４において、ブロックオフセット番号：Ｃの更新処理（Ｃ＝Ｃ＋１）を実行して、ステップＳ２０５以下の処理を繰り返し実行して端末に対するコンテンツ送信を実行する。
【０１３２】
ステップＳ２０５において、キャッシュグループを構成するキャッシュ装置数：Ｎ、キャッシュグループにおける自己に設定されたグループ・メンバー番号：ｍ１の各値に基づく、Ｃ ｍｏｄ Ｎ算出、Ｖ＝ｍ１であるか否かの判定において、Ｖ＝ｍ１でない場合は、要求されたコンテンツが自装置内に格納されていないことになり、ステップＳ２１５に進み、算出したＶの値（ｍ２とする）に対応するグループ・メンバーをキャッシュグループ・テーブル（図８参照）から取得する。
【０１３３】
ステップＳ２１６において、算出したＶの値（ｍ２とする）に対応するグループ・メンバーのＩＰアドレスをキャッシュグループ・テーブル（図８参照）から取得する。ステップＳ２１７では、取得ＩＰアドレスが０．０．０．０か否かを判定する。ＩＰアドレスが０．０．０．０の場合は、キャッシュグループを離脱したメンバーのエントリを示す。この場合は、上流のキャッシュ装置またはコンテンツサーバーに要求をリダイレクトして発行（Ｓ２２１）する。
【０１３４】
ステップＳ２１７の判定において、取得ＩＰアドレスが０．０．０．０でない場合は、キャッシュグループのメンバーのエントリを示す。ステップＳ２１８に進み、コンテンツの読み出し要求（リダイレクト要求）をキャッシュグループのメンバー（ｍ２）に対応するＩＰアドレスに基づいて実行する。
【０１３５】
リダイレクト要求を受信したキャッシュ装置における処理について、図１６を参照して説明する。これは、キャッシュグループを構成するキャッシュ装置が、他のグループ・メンバーからのコンテンツ読み出し要求（リダイレクト要求）に応答する処理として実行される処理である。
【０１３６】
ステップＳ３０１において、コンテンツ読み出し要求（リダイレクト要求）を受信すると、ステップＳ３０２に進み、ＬＲＵリストまたは削除保留リストのエントリに基づいて要求コンテンツ名、ブロックオフセット番号から自装置内のデータ格納領域情報を取得し、ステップＳ３０３において、データの有無、エラー状態を判定し、消去されているかエラーである場合は、ステップＳ３０６において、コンテンツ読み出し要求（リダイレクト要求）を送信してきたキャッシュ装置に対してエラー提示コードを応答送信する。
【０１３７】
ステップＳ３０３において、データの有無、エラー状態を判定し、データが存在し、読み出し可能であると判定されると、ステップＳ３０４において、指定サイズのデータの読み出しを実行し、ステップＳ３０５で、読み出しデータを要求キャッシュ装置に、正常終了提示コードとともに送信する。
【０１３８】
図１５の処理フローに戻り、説明を続ける。ステップＳ２１９またはステップＳ２２２において、リダイレクト要求先からの応答を受信すると、ステップＳ２２０またはステップＳ２２３において、正常読み出しがなされたか否かを判定し、Ｙｅｓの場合は、ステップＳ２０９に進み、以下の処理、すなわち、リストエントリの移動、取得コンテンツの端末に対する送信等を実行する。なお、ステップＳ２０８、Ｓ２２０，Ｓ２２３において、データの正常読み出しに失敗した場合は、異常終了として処理を終了する。
【０１３９】
なお、異常終了として処理を終了する以前に、エラー応答受信後、リダイレクト先として上流のキャッシュ装置（サーバーへの経路途中にある、サーバーにより近いキャッシュ装置）がある場合は、上流の装置にリダイレクトし、無い場合は、直接コンテンツサーバーに要求をリダイレクトして、目的とするデータを得る処理を実行してもよい。
【０１４０】
上記処理における各キャッシュ装置間のデータ通信シーケンスの概要を、図１７を参照して説明する。なお、図１７において、左端から、
コンテンツ取得要求を送信する端末、
端末からのコンテンツ取得要求を受信するキャッシュ装置Ａ
キュッシュ装置Ａとキャッシュグループを構成するキャッシュ装置１
キュッシュ装置Ａとキャッシュグループを構成するキャッシュ装置２
キュッシュ装置Ａの上流キャシュ装置またはサーバー
である。
【０１４１】
［処理Ｓ］は、端末からの要求コンテンツデータを、キャッシュ装置Ａが、キャッシュグループ・メンバーとしてのキャッシュ装置１，２からそれぞれ取得して、端末に送信する処理シーケンスであり、ＵＲＬを指定したコンテンツ取得要求（ＨＴＴＰ ＧＥＴ （ＵＲＬ））を受信したキャッシュ装置が上述のＣ ｍｏｄ Ｎ算出、Ｖ＝ｍ１の算出に基づいて、コンテンツの対応データ・ブロックを保持していると予測されるキャッシュ装置１，２に対してコンテンツ取得要求（ＨＴＴＰ ＧＥＴ （ＵＲＬ） Ｒａｎｇｅ：ｂｙｔｅｓ＝ａａ−ｂｂ）を送信し、コンテンツのデータ・ブロックを取得（ＨＴＴＰ２０６）し、キャッシュ装置Ａは、取得コンテンツを端末に送信（ＨＴＴＰ ＯＫ）する処理シーケンスである。
【０１４２】
［処理Ｔ］は、端末からの要求コンテンツデータを、キャッシュ装置Ａが、キャッシュグループ・メンバーとしてのキャッシュ装置１，２からそれぞれ取得できなかった場合の処理シーケンスであり、ＵＲＬを指定したコンテンツ取得要求（ＨＴＴＰ ＧＥＴ （ＵＲＬ））を受信したキャッシュ装置が上述のＣ ｍｏｄＮ算出、Ｖ＝ｍ１の算出に基づいて、コンテンツの対応データ・ブロックを保持していると予測されるキャッシュ装置１に対してコンテンツ取得要求（ＨＴＴＰ ＧＥＴ （ＵＲＬ） Ｒａｎｇｅ：ｂｙｔｅｓ＝ａａ−ｂｂ）を送信し、コンテンツのデータ・ブロックが取得できない旨の応答（ＨＴＴＰ４０４（Ｎｏｔ Ｆｏｕｎｄ）または、ＨＴＴＰ４１０（Ｇｏｎｅ））を受信する。
【０１４３】
さらに、キャッシュ装置Ａは、キュッシュ装置Ａの上流キャシュ装置またはサーバーに、コンテンツ取得要求（ＨＴＴＰ ＧＥＴ （ＵＲＬ） Ｒａｎｇｅ：ｂｙｔｅｓ＝ａａ−ｂｂ）を送信し、コンテンツのデータ・ブロックを取得（ＨＴＴＰ２０６）し、キャッシュ装置Ａは、取得コンテンツを端末に送信（ＨＴＴＰＯＫ及び取得したコンテンツデータの送信）をする。
【０１４４】
なお、［処理Ｔ］のように、キャッシュグループの構成メンバーから予定のコンテンツが取得できなかった場合は、キャッシュグループの構成メンバーとして存続する意味がないので、グループ解消を行なう。この処理が［処理Ｕ］である。
【０１４５】
グループ解消処理は、キャッシュＡから、グループ解消通知（ＩＣＰ ＯＰ ＮＯＴＩＦＹ）を、グループを構成する各キャッシュ装置１，２に送信することによって行なわれる。キャッシュ装置Ａ，１，２はその後、キャッシュグループ・テーブルから対応するグループ情報を削除する。
【０１４６】
なお、上述した例では、ＨＴＴＰプロトコルを使ったリダイレクト手順を書いているが、ＦＴＰやＲＴＳＰなどの別のプロトコルであってもかまわない。また、キャッシュ装置間の通信プロトコルについても、ＩＣＰだけに限定する必要はなく、一般的に使われる装置間の通信手段を拡張することでも実現可能である。また、キャッシュ間通信プロトコルも、ＩＣＰだけには限らない。
【０１４７】
キャッシュグループを構成するグループ・メンバーｍ（ｍ＝１，２，．．．，Ｎ： Ｎはグループ構成メンバー数）がキャッシュグループから離脱することになるケースを以下に説明する。
【０１４８】
キャッシュグループを組むと宣言したコンテンツに関連するデータ・ブロックの全体数をＡとしたときに、グループ・メンバーとして保持しておくべきデータ・ブロック（Ｖ＝ｍのデータ・ブロック）の総数Ｓは、Ａ ｍｏｄ Ｎが零の場合はＶ＝Ｎ，非零の場合はＶ＝（Ａ ｍｏｄ Ｎ）としてｍ≦ＶのときＳ＝（Ａ＋Ｎ−１）／Ｎ，ｍ＞ＶのときＳ＝Ａ／Ｎと計算される。
【０１４９】
このＳの分のデータ・ブロックを永久に保持できればよいが、記憶資源は有限であるため、キャッシュ・リプレースメントが進むとグループ・メンバーとして保持しておくべきデータ・ブロックであったとしても、削除保留リストから削除されてしまうケースもある。このようにグループ・メンバーとして保持しておくべきデータ・ブロックも削除保留リストからも削除されてしまうような場合において、グループ・メンバーとして保持すべきデータ・ブロックにもかかわらず削除してしまったデータ・ブロックの数をＤとするとき、グループ離脱に至る閾値Ｔ（％）として、グループ・メンバーとして保持すべきデータ・ブロックの残存率：（Ｓ−Ｄ）／Ｓ×１００（％）を算出し、
データ・ブロックの残存率と閾値Ｔとの関係が、
（Ｓ−Ｄ）／Ｓ×１００（％）＜Ｔ（０＜＝Ｔ＜１００）となった場合に、そのコンテンツに関しキャッシュグループを組んでいるキャッシュ・メンバーに対して、グループ離脱を宣言する構成が可能である。
【０１５０】
キャッシュグループからの離脱を検知したときは、自分のキャッシュグループ・テーブルから該当するコンテンツに対応するエントリを削除すると共に、図１７の［処理Ｕ］に示すように、これを知らせるフラグ（説明のための例として０ｘ１０００００００（ＩＣＰ＿ＦＬＡＧ＿ＧＲＯＵＰ＿ＤＥＳＥＲＴＥＤ））を立てたＩＣＰ＿ＯＰ＿ＮＯＴＩＦＹメッセージを、該当するコンテンツについてキャッシュグループを組んでいる全グループ・メンバーに送る。
【０１５１】
さらに、各キャッシュ装置にあるキャッシュグループ・テーブルから、通知されたキャッシュ装置がキャッシュグループから離脱したことがわかるように、対応する部分のＩＰアドレスを≡０．０．０．０≡のように書き換える。
【０１５２】
ただし、メンバー数などの他の情報は、離脱メンバーが無い場合とのアルゴリズムの互換を保つ目的もあり、そのままの情報として保持してもよい。もし、離脱グループ・メンバーが保持しているべきデータ・ブロックをアクセスしたい場合には、オリジナルデータを持っているサーバーまたは上流のキャッシュ装置にアクセスすることになる。
【０１５３】
キャッシュグループを構成するメンバー数が、離脱メンバーを除いた実質数で１となった場合、キャッシュグループを組めないことになるため、グループを完全に消去する意味で、残った１台のキャッシュ装置のキャッシュグループ・テーブルから該当するコンテンツに対応するエントリを削除し、削除保留リストの対応するコンテンツに属するデータ・ブロックの“Ｇｐ”の項目を初期化（ゼロクリア）する。
【０１５４】
［多段構成の削除保留リスト］
次に、キャッシュ装置においてデータ管理リストとして生成する削除保留リストを多段構成とした実施例について説明する。
【０１５５】
上述した実施例において、キャッシュ装置は、図９を参照して説明したように、ＬＲＵリストと、キャッシュの空き領域ブロックを示すフリーブロックリスト、さらに、ＬＲＵリストで削除対象ブロックとなったデータ・ブロックの内、一時的に削除保留状態に設定したデータ・ブロックを管理するリストとしての削除保留リストを有しており、各リストは、先頭エントリからシーケンシャルに並べられたエントリを有する構成であった。
【０１５６】
本実施例のキャッシュ装置は、図１８に示すように、複数の削除保留リストを有する。キャッシュ装置は、利用頻度順にエントリを並べた（ａ）ＬＲＵリスト、キャッシュグループを構成したコンテンツのデータ・ブロックに対応して設定したエントリを格納した複数の（ｂ１）（ｂ２）削除保留リスト、空きブロック領域をポインタ情報として有する（ｃ）フリーブロックリストを有する。
【０１５７】
複数の削除保留リスト（ｂ１）（ｂ２）は、コンテンツデータ・ブロックの削除保留優先度の高低に基づいて振り分けられてエントリが各リストに格納される。ここでは、２つの削除保留リスト（ｂ１）（ｂ２）のうち、（ｂ１）のリストに保存優先度の高いコンテンツに対応するエントリを格納し、（ｂ２）のリストに保存優先度の低いコンテンツに対応するエントリを格納する例を示す。本例では、２つの削除保留リストの設定例を示しているが、保存優先度順に３以上の削除保留リストを設定する構成としてもよい。
【０１５８】
なお、データ・ブロックの重要性に応じた保存優先度の判定の態様は、様々な態様が可能である。例えば、新規に届いたコンテンツに対応するデータ・ブロックほど重要とする設定、あるいは、コンテンツデータの先頭部分やシーンチェンジ部分以降の特定区間だけは重要度の高いデータ・ブロックとして設定するなどの構成がある。なお、コンテンツデータの先頭部分やシーンチェンジ部分の検出は、既存のソフトウェアによる処理が可能である。
【０１５９】
リストに対するエントリの移動について説明する。例えばキャッシュ装置において、新規データ・ブロックの書き込み要求があると、（ｃ）フリーブロックリストの先頭エントリ５０１に設定されたデータ・ブロック・ポインタに対応するデータ格納領域のデータ記憶領域に新規データ・ブロックが書き込まれ、書き込まれたデータ・ブロックに関する情報は、図１０のＬＲＵリストの先頭エントリ５０２に移される。
【０１６０】
その結果、もしＬＲＵリストの長さが許容リスト長を超えることになった場合は、ＬＲＵリストの末尾のエントリ５０３が、削除保留リスト（ｂ１）または（ｂ２）あるいは、フリーブロックリスト（ｃ）に移動することになる。削除保留リストかフリーブロックリストのどちらに移動するかの判定は、前述のＣ ｍｏｄ Ｎの算出、Ｖの値によるエントリに対応するコンテンツデータ・ブロックの残留、削除判定に基づくことになる。
【０１６１】
上述した判定処理の結果、エントリを削除保留リストに移動すると決定した場合は、保存の重要度に応じて、重要度の高いデータ・ブロックに対するエントリは、削除保留リスト（ｂ１）の末尾のエントリ５０４として設定し、重要度の低いデータ・ブロックに対するエントリは、削除保留リスト（ｂ２）の末尾のエントリ５０５として設定する。
【０１６２】
また、削除保留リスト（ｂ１）に新たなエントリが加わり、削除保留リスト（ｂ１）が予め定められたリスト長を超えることとなった場合は、削除保留リスト（ｂ１）の先頭のエントリ５１１が、削除保留リスト（ｂ２）の末尾のエントリ５０５として設定される。
【０１６３】
同様に、削除保留リスト（ｂ２）に新たなエントリが加わり、削除保留リスト（ｂ２）が予め定められたリスト長を超えることとなった場合は、削除保留リスト（ｂ２）の先頭のエントリ５１２が、フリーブロックリストの末尾のエントリ５２１として設定される。
【０１６４】
なお、フリーブロックリストに対応して確保すべきバッファ量が、予め定められており、これが、新規データの格納により不足することとなった場合は、ＬＲＵリストあるいは削除保留リスト（ｂ２）からのフリーブロックリストへの移動、すなわちデータ・ブロックの削除によるバッファ量確保処理が実行される。
【０１６５】
フリーブロックリストへ移動されたエントリの指定するデータ・ブロック・ポインタの指定するメモリ領域は、新たな入力データの書き込みに適用され、データ・ブロックの内容が捨てられることになる。
【０１６６】
多段構成とした場合の削除保留リストの構成について、図１９を参照して説明する。削除保留リストとは、前述したように、ＬＲＵリストで削除対象ブロックとなったデータ・ブロックの内、一時的に削除保留状態に設定したデータ・ブロックを管理するリストである。
【０１６７】
図１９は、図１８の削除保留リスト（ｂ１）または（ｂ２）のいずれかに対応する削除保留リストの構成を示している。図１９のように、キャッシュ装置の保有する削除保留リスト６３０は、削除保留状態に設定したデータ・データ・ブロックに対応付けて生成される。ここでは、（ａ）〜（ｐ）のリストデータ（エントリ）が削除保留状態に設定したデータ・データ・ブロックに対応付けられて保持されている。削除保留リストの内部構造は、図１９に示すように、データ・ブロックヘのポインタ６３１、コンテンツ識別子６３２、ブロックオフセット６３３、設定されたキャッシュグループのグループ識別子（ＧＰ）６３４、さらに、削除保留リストの重要度指数値（Ｐｒｉｏｒｉｔｙ）６３５、および削除保留リストの前リストデータ（エントリ）のポインタ６３６、削除保留リストの後続リストデータ（エントリ）のポインタ６３７を有する。多段構成の削除保留リスト６３０の格納データには、削除保留リストの重要度指数値（Ｐｒｉｏｒｉｔｙ）６３５が付加されることになる。
【０１６８】
次に、多段構成の削除保留リストを持キャッシュ装置におけるキャッシュグループの生成処理、データ管理手順について、図２０を参照して説明する。
【０１６９】
図２０において、ステップＳ５０１乃至ステップＳ５１５は、前述の図１３を参照して説明した処理フローのステップＳ１０１乃至ステップＳ１１５と同様の処理であるので、説明を省略する。
【０１７０】
図２０のステップＳ５１５において、ＬＲＵリストからの削除予定エントリについて、ブロックオフセット番号：Ｃ、キャッシュグループを構成するキャッシュ装置数：Ｎ、キャッシュグループにおける自己に設定されたグループ・メンバー番号：ｍの各値に基づいて、 Ｃ ｍｏｄ Ｎを算出し、さらに、 Ｃ ｍｏｄ Ｎ＝０の場合はＶ＝Ｎ、Ｃ ｍｏｄ Ｎ≠０の場合はＶ＝（Ｃ ｍｏｄ Ｎ）として、Ｖ＝ｍであるか否かを判定した結果、Ｖ≠ｍである場合は、ステップＳ５２３に進みそのデータ・ブロックをフリーリストで管理する。Ｖ＝ｍである場合は、そのデータ・ブロックを削除保留として、自装置で管理することになる。
【０１７１】
この場合、ステップＳ５１６において、削除保留対象データ・ブロックの保持優先度の判定を実行する。この保持優先度判定は、キャッシュ装置において予め定められた基準、例えば、前述したように、新規に届いたコンテンツに対応するデータ・ブロックを重要、あるいは、コンテンツデータの先頭部分やシーンチェンジ部分以降の特定区間を重要とした設定情報に基づいて判定する。
【０１７２】
保存優先度の高いデータ・ブロックであると判定した場合は、ステップＳ５１７に進み、保存優先度の高い削除保留リスト（図１８の（ｂ１））にエントリを移動する。保存優先度の低いデータ・ブロックであると判定した場合は、ステップＳ５２０に進み、保存優先度の低い削除保留リスト（図１８の（ｂ２））にエントリを移動する。
【０１７３】
さらに、ステップＳ５１８において、保存優先度の高い削除保留リストから保存優先度の低い削除保留リストにエントリ移動が必要であるか否かを判定し、必要があると判定されると、ステップＳ５１９において、保存優先度の高い削除保留リストから保存優先度の低い削除保留リストにエントリを移動する。
【０１７４】
ステップＳ５２１において、保存優先度の低い削除保留リストからフリーブロックリストにエントリ移動が必要であるか否かを判定し、必要があると判定されると、ステップＳ５２２において、保存優先度の低い削除保留リストからフリーブロックリストにエントリを移動する。
【０１７５】
以上の処理に従って、多段構成を持つ削除保留リストを適用したデータ管理が実行される。
【０１７６】
［キャッシュ装置の構成］
次に、上述の実施例において説明したキャッシュ装置のハード構成例について説明する。
【０１７７】
図２１に、制御手段としてＣＰＵ(Central Processing Unit)を備えたキャッシュ装置例を示す。なお、図２１に示す構成例は１つの例であり、キャッシュ装置は、ここに示す構成以外のハードウェアを持つことも可能である。
【０１７８】
図２１に示す構成について説明する。ＣＰＵ(Central Processing Unit)７０１は、各種実行プログラム、ＯＳ（Operating System）を実行するプロセッサである。ＲＯＭ（Read-Only-Memory）７０２は、ＣＰＵ７０１が実行するプログラム、あるいは演算パラメータとしての固定データを格納する。ＲＡＭ（Random Access Memory）７０３は、ＣＰＵ７０１の処理において実行されるプログラム、およびプログラム処理において適宜変化するパラメータの格納エリア、ワーク領域として使用される。また、近隣キャッシュ装置リスト、キャッシュグループ・テーブルの格納領域として使用される。
【０１７９】
ＣＰＵ７０１，ＲＯＭ７０２，ＲＡＭ７０３はＣＰＵバス７１１によってデータ転送可能に接続され、バスブリッジ７０４を介してＩ／Ｏバス７１２に接続される。Ｉ／Ｏバス７１２には、ディスクインタフェース７０５、ネットワークインタフェース７０７，７０８が接続される。
【０１８０】
ディスクインタフェース７０５は、ハードディスク、フレキシブルディスク、ＣＤ−ＲＯＭ(Compact Disc Read Only Memory)，ＭＯ(Magneto optical)ディスク，ＤＶＤ(Digital Versatile Disc)、磁気ディスク等のディスク７０６に対するインタフェースであり、ディスク７０６には、キャッシュデータガ格納され、ＣＰＵ７０１の制御の下に必要データが取得、格納される。
【０１８１】
ネットワークインタフェース７０７は、外部ネットワークインタフェースであり、ネットワーク接続されたサーバー、他のキャッシュ装置とのデータ送受信用のインタフェースである。ネットワークインタフェース７０８は、内部ネットワークインタフェースであり、ネットワーク接続された端末とのデータ送受信用のインタフェースである。
【０１８２】
なお、明細書中において説明した各処理はハードウェア、またはソフトウェア、あるいは両者の複合構成によって実行することが可能である。一連の処理をソフトウェアにより実行させる場合には、そのソフトウェアを構成するプログラムが専用のハードウェアに組み込まれているコンピュータ、又は各種のプログラムをインストールすることで各種の機能を実行することが可能な、例えば汎用のパーソナルコンピュータなどに、フレキシブルディスクやＣＤ−ＲＯＭ等のプログラム読み取り可能な記録媒体にプログラムを格納して提供してもよいし、インターネットなどの通信網を介してプログラムをダウンロードしてもよい。
【０１８３】
具体的には、プログラムは記録媒体としてのハードディスクやＲＯＭ（Read Only Memory)に予め記録しておくことができる。あるいは、プログラムはフレキシブルディスク、ＣＤ−ＲＯＭ(Compact Disc Read Only Memory)，ＭＯ(Magneto optical)ディスク，ＤＶＤ(Digital Versatile Disc)、磁気ディスク、半導体メモリなどのリムーバブル記録媒体に、一時的あるいは永続的に格納（記録）しておくことができる。このようなリムーバブル記録媒体は、いわゆるパッケージソフトウエアとして提供することができる。
【０１８４】
また、プログラムは、上述したようなリムーバブル記録媒体からコンピュータにインストールする他、ダウンロードサイトから、コンピュータに無線転送したり、ＬＡＮ(Local Area Network)、インターネットといったネットワークを介して、コンピュータに有線で転送し、コンピュータでは、そのようにして転送されてくるプログラムを受信し、内蔵するハードディスク等の記録媒体にインストールすることができる。
【０１８５】
なお、明細書に記載された各種の処理は、記載に従って時系列に実行されるのみならず、処理を実行する装置の処理能力あるいは必要に応じて並列的にあるいは個別に実行されてもよい。また、本明細書においてシステムとは、複数の装置の論理的集合構成であり、各構成の装置が同一筐体内にあるものには限らない。
【０１８６】
以上、特定の実施例を参照しながら、本発明について詳解してきた。しかしながら、本発明の要旨を逸脱しない範囲で当業者が該実施例の修正や代用を成し得ることは自明である。すなわち、例示という形態で本発明を開示してきたのであり、限定的に解釈されるべきではない。本発明の要旨を判断するためには、冒頭に記載した特許請求の範囲の欄を参酌すべきである。
【０１８７】
【発明の効果】
以上、説明してきたように、本発明の構成によれば、ネットワーク接続されたキャッシュ装置におけるキャッシュ・リプレースメント処理において、削除保留ブロックに関するリストを保持して、キャッシュグループ内のキャッシュ装置ごとに各々削除保留されるデータ・ブロックが異なるようにデータ管理を行なう構成としたので、各キャッシュ装置が単独でキャッシュ・リプレースメントの管理をしている場合に比べて効率的な記憶領域の利用が図れ、また、端末からのデータ要求に応じて複数のキャッシュ装置に記憶したデータ・ブロックを集めて送信することが可能となり、ネットワークトラフィックの軽減、キャッシュ装置のヒット率の向上が実現される。
【０１８８】
さらに、本発明の多段の削除保留リストを適用したキャッシュ装置構成によれば、保持重要度の高いデータが削除されずにキャッシュに残る可能性が高くなるため、さらに、キャッシュヒット率の向上を達成することが可能となる。
【図面の簡単な説明】
【図１】従来のＬＲＵリストおよびフリーブロックリストによるキャッシュデータの管理構成について説明する図である。
【図２】本発明のキャッシュ装置が適用可能なネットワーク構成について説明する図である。
【図３】本発明のキャッシュ装置におけるデータ管理構成について説明する図である。
【図４】本発明のキャッシュ装置におけるデータ管理構成について説明する図である。
【図５】本発明のキャッシュ装置間における送受信メッセージのフォーマット例について説明する図である。
【図６】本発明のキャッシュ装置における近隣キャッシュ装置リストの構成データについて説明する図である。
【図７】本発明のキャッシュ装置間における送受信メッセージとしてのグループ設定情報メッセージのフォーマット例について説明する図である。
【図８】本発明のキャッシュ装置において格納するキャッシュグループ・テーブルのデータ例について説明する図である。
【図９】本発明のキャッシュ装置においてデータ管理に利用するリストについて説明する図である。
【図１０】本発明のキャッシュ装置においてデータ管理に利用するＬＲＵリストについて説明する図である。
【図１１】本発明のキャッシュ装置においてデータ管理に利用する削除保留リストについて説明する図である。
【図１２】本発明のキャッシュ装置においてデータ管理に利用するフリーブロックリストについて説明する図である。
【図１３】本発明のキャッシュ装置におけるグループ形成、データ管理処理について説明するフロー図である。
【図１４】本発明のキャッシュ装置におけるグループ形成、データ管理処理に際して送受信されるメッセージについて説明するシーケンス図である。
【図１５】本発明のキャッシュ装置におけるデータ取得送信処理について説明するフロー図である。
【図１６】本発明のキャッシュ装置におけるリダイレクト処理によるデータ取得送信処理について説明するフロー図である。
【図１７】本発明のキャッシュ装置におけるデータ取得送信処理に際して送受信されるメッセージについて説明するシーケンス図である。
【図１８】本発明のキャッシュ装置において多段構成の削除保留リストを持つ構成を説明する図である。
【図１９】本発明のキャッシュ装置における多段構成の削除保留リスト構成について説明する図である。
【図２０】本発明の多段構成の削除保留リストを持つキャッシュ装置におけるグループ形成、データ管理処理について説明するフロー図である。
【図２１】本発明のキャッシュ装置におけるハード構成例を示す図である。
【符号の説明】
２０１ コンテンツサーバー
２０２ ネットワーク
２１０ キャッシュグループ
２１１，２１２，２１３，２１４ キャッシュ装置
２２１，２３１，２５１ 端末
３１０ ＬＲＵリスト
３２０ データ格納領域
３３０ 削除保留リスト
３５０ フリーブロックリスト
６３０ 削除保留リスト
７０１ ＣＰＵ
７０２ ＲＯＭ
７０３ ＲＡＭ
７０４ バスブリッジ
７０５ ディスクインタフェース
７０６ ディスク
７０７ ネットワークインタフェース
７０８ ネットワークインタフェース
７１１ ＣＰＵバス
７１２ Ｉ／Ｏバス
Claims (15)
- ネットワークを介して受信したデータをキャッシュデータとして格納し、端末からのデータ要求に応じてキャッシュデータを取得して端末に送信するキャッシュ装置であり、
自キャッシュ装置およびネットワークに接続された他のキャッシュ装置によって構成され、コンテンツを構成する複数のデータ・ブロックを分散格納してコンテンツの共同管理を行うキャッシュグループに関するグループ設定情報を格納したテーブルであり、キャッシュグループが共同管理するコンテンツの識別子と、キャッシュグループを構成するキャッシュ装置数：Ｎと、各キャッシュ装置に対応して設定されるグループ・メンバー番号：ｍを格納したキャッシュグループ・テーブルと、
自キャッシュ装置に保持されたデータ・ブロックの管理データであるＬＲＵリストから削除予定データ・ブロックを検索し、削除予定データ・ブロックが前記キャッシュグループにおける自己の記憶担当データである保留データ・ブロックであるか否かを前記キャッシュグループ・テーブルの格納パラメータを適用した算出式の算出結果に基づいて決定し、削除予定データ・ブロックが保留データ・ブロックである場合は削除せずに削除保留リストによる管理対象として自キャッシュ装置に保持し管理する処理を行う制御手段と、
を有することを特徴とするキャッシュ装置。 - 前記制御手段は、共同管理するコンテンツを構成する複数のデータ・ブロックから、自キャッシュ装置における記憶保持対象とする保留データ・ブロックの決定処理を、以下の処理、すなわち、
判定対象データ・ブロックが構成要素となるコンテンツの先頭データ・ブロックからのオフセット情報としてのブロックオフセット番号：Ｃに基づいて、
Ｃ ｍｏｄ Ｎを算出し、
Ｃ ｍｏｄ Ｎ＝０の場合はＶ＝Ｎ、
Ｃ ｍｏｄ Ｎ≠０の場合はＶ＝（Ｃ ｍｏｄ Ｎ）として、
Ｖ＝ｍであるか否かを判定し、
Ｖ＝ｍである場合に、該データ・ブロックを保留データ・ブロックとして決定する処理、
を実行する構成であることを特徴とする請求項１に記載のキャッシュ装置。 - 前記制御手段は、
記憶手段に格納したデータ・ブロックについての管理リストであるＬＲＵリストからの排除対象エントリに対応するデータ・ブロックについて、前記キャッシュグループによる共同管理が可能か否かをキャッシュ装置間のメッセージ送受信により判定し、
共同管理可能であると判定した場合に、前記キャッシュグループ・テーブルを生成する構成であることを特徴とする請求項１に記載のキャッシュ装置。 - 前記制御手段は、
記憶手段に格納したデータ・ブロックについての管理リストであるＬＲＵリストからの排除対象エントリに対応するデータ・ブロックについて、
前記キャッシュグループ・テーブルの格納情報に基づいて、コンテンツを構成する複数のデータ・ブロック中から、自キャッシュ装置における記憶保持データとしての保留データ・ブロックを決定し、決定した保留データ・ブロック以外のデータ・ブロックについては、削除の許容されるデータ・ブロック管理リストとしてのフリーブロックリストにより管理する構成であることを特徴とする請求項１に記載のキャッシュ装置。 - 前記削除保留リストは、データ・ブロックの保存優先度に応じた複数のリストによって構成され、
前記制御手段は、
データ・ブロックの保存優先度を判定し、該判定結果に基づいて選択した削除保留リストに対して前記管理データ・ブロックに対応するエントリの設定を行なう構成であることを特徴とする請求項１に記載のキャッシュ装置。 - 前記制御手段は、
端末からのコンテンツ取得要求が、前記キャッシュグループによる共同管理対象のコンテンツ取得要求である場合に、
取得要求対象のコンテンツを構成するデータ・ブロックが前記キャッシュグループを構成するいずれのキャッシュ装置の保持対象データ・ブロックであるかを判定し、該判定結果に基づいてデータ・ブロックを自キャッシュ装置または、前記キャッシュグループを構成する他のキャッシュ装置から取得する処理を実行する構成であることを特徴とする請求項１に記載のキャッシュ装置。 - 前記制御手段は、
取得要求対象のデータ・ブロックが構成要素となるコンテンツの先頭データ・ブロックからのオフセット情報としてのブロックオフセット番号：Ｃに基づいて、
Ｃ ｍｏｄ Ｎを算出し、
Ｃ ｍｏｄ Ｎ＝０の場合はＶ＝Ｎ、
Ｃ ｍｏｄ Ｎ≠０の場合はＶ＝（Ｃ ｍｏｄ Ｎ）として、
Ｖ＝ｍを算出し、
算出したｍをグループ・メンバー番号として有するキャッシュ装置からデータ・ブロックの取得処理を実行する構成であることを特徴とする請求項６に記載のキャッシュ装置。 - ネットワークを介して受信したデータをキャッシュデータとして格納し、端末からのデータ要求に応じてキャッシュデータを取得して端末に送信するキャッシュ装置におけるキャッシュデータ管理方法であり、
前記キャッシュ装置の制御手段が、自キャッシュ装置に保持されたデータ・ブロックの管理データであるＬＲＵリストから削除予定データ・ブロックを検索するステップと、
前記制御手段が、自キャッシュ装置およびネットワークに接続された他のキャッシュ装置によって構成され、コンテンツを構成する複数のデータ・ブロックを分散格納してコンテンツの共同管理を行うキャッシュグループに関するグループ設定情報を格納したテーブルであり、キャッシュグループが共同管理するコンテンツの識別子と、キャッシュグループを構成するキャッシュ装置数：Ｎと、各キャッシュ装置に対応して設定されるグループ・メンバー番号：ｍを格納したキャッシュグループ・テーブルの格納パラメータを適用した算出式の算出結果に基づいて、前記削除予定データ・ブロックが前記キャッシュグループにおける自己の記憶担当データである保留データ・ブロックであるか否かを決定する保留データ・ブロック決定ステップと、
前記制御手段が、前記削除予定データ・ブロックが保留データ・ブロックである場合は削除せずに削除保留リストによる管理対象として自キャッシュ装置に保持し管理する処理を行うステップと、
を有することを特徴とするキャッシュデータ管理方法。 - 前記保留データ・ブロック決定ステップは、
共同管理するコンテンツを構成する複数のデータ・ブロックから、自キャッシュ装置における記憶保持対象とする保留データ・ブロックの決定処理を、以下の処理、すなわち、
判定対象データ・ブロックが構成要素となるコンテンツの先頭データ・ブロックからのオフセット情報としてのブロックオフセット番号：Ｃに基づいて、
Ｃ ｍｏｄ Ｎを算出し、
Ｃ ｍｏｄ Ｎ＝０の場合はＶ＝Ｎ、
Ｃ ｍｏｄ Ｎ≠０の場合はＶ＝（Ｃ ｍｏｄ Ｎ）として、
Ｖ＝ｍであるか否かを判定し、
Ｖ＝ｍである場合に、該データ・ブロックを保留データ・ブロックとして決定する処理を実行することを特徴とする請求項８に記載のキャッシュデータ管理方法。 - 前記キャッシュデータ管理方法は、さらに、
前記制御手段が、記憶手段に格納したデータ・ブロックについての管理リストであるＬＲＵリストからの排除対象エントリに対応するデータ・ブロックについて、前記キャッシュグループによる共同管理が可能か否かをキャッシュ装置間のメッセージ送受信により判定し、共同管理可能であると判定した場合に、前記キャッシュグループ・テーブルを生成する処理を実行することを特徴とする請求項８に記載のキャッシュデータ管理方法。 - 前記キャッシュデータ管理方法は、さらに、
前記制御手段が、記憶手段に格納したデータ・ブロックについての管理リストであるＬＲＵリストからの排除対象エントリに対応するデータ・ブロックについて、前記キャッシュグループ・テーブルの格納情報に基づいて、コンテンツを構成する複数のデータ・ブロック中から、自キャッシュ装置における記憶保持データとしての保留データ・ブロックを決定し、決定した保留データ・ブロック以外のデータ・ブロックについては、削除の許容されるデータ・ブロック管理リストとしてのフリーブロックリストにより管理するステップを含むことを特徴とする請求項８に記載のキャッシュデータ管理方法。 - 前記削除保留リストは、データ・ブロックの保存優先度に応じた複数のリストによって構成され、
前記キャッシュデータ管理方法は、さらに、
前記制御手段が、データ・ブロックの保存優先度を判定し、該判定結果に基づいて選択した削除保留リストに対して前記管理データ・ブロックに対応するエントリの設定を行なうステップを含むことを特徴とする請求項８に記載のキャッシュデータ管理方法。 - 前記キャッシュデータ管理方法は、さらに、
前記制御手段が、端末からのコンテンツ取得要求が、前記キャッシュグループによる共同管理対象のコンテンツ取得要求である場合に、取得要求対象のコンテンツを構成するデータ・ブロックが前記キャッシュグループを構成するいずれのキャッシュ装置の保持対象データ・ブロックであるかを判定し、該判定結果に基づいてデータ・ブロックを自キャッシュ装置または、前記キャッシュグループを構成する他のキャッシュ装置から取得するデータ・ブロック取得処理を実行するステップを含むことを特徴とする請求項８に記載のキャッシュデータ管理方法。 - 前記データ・ブロック取得処理は、
取得要求対象のデータ・ブロックが構成要素となるコンテンツの先頭データ・ブロックからのオフセット情報としてのブロックオフセット番号：Ｃに基づいて、
Ｃ ｍｏｄ Ｎを算出し、
Ｃ ｍｏｄ Ｎ＝０の場合はＶ＝Ｎ、
Ｃ ｍｏｄ Ｎ≠０の場合はＶ＝（Ｃ ｍｏｄ Ｎ）として、
Ｖ＝ｍを算出し、
算出したｍをグループ・メンバー番号として有するキャッシュ装置からデータ・ブロックを取得する処理として実行することを特徴とする請求項１３に記載のキャッシュデータ管理方法。 - ネットワークを介して受信したデータをキャッシュデータとして格納し、端末からのデータ要求に応じてキャッシュデータを取得して端末に送信するキャッシュ装置のプログラム実行部である制御手段にキャッシュデータ管理処理を実行させるコンピュータ・プログ ラムであり、
自キャッシュ装置に保持されたデータ・ブロックの管理データであるＬＲＵリストから削除予定データ・ブロックを検索させるステップと、
自キャッシュ装置およびネットワークに接続された他のキャッシュ装置によって構成され、コンテンツを構成する複数のデータ・ブロックを分散格納してコンテンツの共同管理を行うキャッシュグループに関するグループ設定情報を格納したテーブルであり、キャッシュグループが共同管理するコンテンツの識別子と、キャッシュグループを構成するキャッシュ装置数：Ｎと、各キャッシュ装置に対応して設定されるグループ・メンバー番号：ｍを格納したキャッシュグループ・テーブルの格納パラメータを適用した算出式の算出結果に基づいて、前記削除予定データ・ブロックが前記キャッシュグループにおける自己の記憶担当データである保留データ・ブロックであるか否かを決定させる保留データ・ブロック決定ステップと、
前記削除予定データ・ブロックが保留データ・ブロックである場合は削除せずに削除保留リストによる管理対象として自キャッシュ装置に保持し管理する処理を行わせるステップと、
を実行させることを特徴とするコンピュータ・プログラム。
Priority Applications (4)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002195654A JP4244572B2 (ja) | 2002-07-04 | 2002-07-04 | キャッシュ装置、およびキャッシュデータ管理方法、並びにコンピュータ・プログラム |
| US10/520,427 US7287136B2 (en) | 2002-07-04 | 2003-06-24 | Cache device, and method and computer program for controlling cached data |
| CNB038208652A CN100383758C (zh) | 2002-07-04 | 2003-06-24 | 高速缓存设备和高速缓存数据管理方法 |
| PCT/JP2003/007971 WO2004006101A1 (ja) | 2002-07-04 | 2003-06-24 | キャッシュ装置、およびキャッシュデータ管理方法、並びにコンピュータ・プログラム |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002195654A JP4244572B2 (ja) | 2002-07-04 | 2002-07-04 | キャッシュ装置、およびキャッシュデータ管理方法、並びにコンピュータ・プログラム |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2004038627A JP2004038627A (ja) | 2004-02-05 |
| JP4244572B2 true JP4244572B2 (ja) | 2009-03-25 |
Family
ID=30112345
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2002195654A Expired - Fee Related JP4244572B2 (ja) | 2002-07-04 | 2002-07-04 | キャッシュ装置、およびキャッシュデータ管理方法、並びにコンピュータ・プログラム |
Country Status (4)
| Country | Link |
|---|---|
| US (1) | US7287136B2 (ja) |
| JP (1) | JP4244572B2 (ja) |
| CN (1) | CN100383758C (ja) |
| WO (1) | WO2004006101A1 (ja) |
Families Citing this family (97)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| KR101270737B1 (ko) * | 2003-11-04 | 2013-06-03 | 톰슨 라이센싱 | 서비스를 다운로딩하기 위한 핫 스폿에서의 캐시 서버 |
| JP4416603B2 (ja) * | 2004-08-20 | 2010-02-17 | キヤノン株式会社 | 画像処理装置及び画像処理装置の制御方法 |
| US7499996B1 (en) * | 2004-12-22 | 2009-03-03 | Google Inc. | Systems and methods for detecting a memory condition and providing an alert |
| CN100396059C (zh) * | 2006-03-03 | 2008-06-18 | 清华大学 | 分裂式网络处理器控制信息高速缓冲存储器 |
| US20080126352A1 (en) * | 2006-09-27 | 2008-05-29 | Rockwell Automation Technologies, Inc. | Client side state cache for industrial control systems |
| US8615635B2 (en) * | 2007-01-05 | 2013-12-24 | Sony Corporation | Database management methodology |
| US8087027B2 (en) * | 2007-03-29 | 2011-12-27 | International Business Machines Corporation | Computer program product and system for deferring the deletion of control blocks |
| US7991910B2 (en) | 2008-11-17 | 2011-08-02 | Amazon Technologies, Inc. | Updating routing information based on client location |
| US8028090B2 (en) | 2008-11-17 | 2011-09-27 | Amazon Technologies, Inc. | Request routing utilizing client location information |
| US7962597B2 (en) | 2008-03-31 | 2011-06-14 | Amazon Technologies, Inc. | Request routing based on class |
| US8321568B2 (en) * | 2008-03-31 | 2012-11-27 | Amazon Technologies, Inc. | Content management |
| US8601090B1 (en) | 2008-03-31 | 2013-12-03 | Amazon Technologies, Inc. | Network resource identification |
| US7970820B1 (en) | 2008-03-31 | 2011-06-28 | Amazon Technologies, Inc. | Locality based content distribution |
| US8447831B1 (en) | 2008-03-31 | 2013-05-21 | Amazon Technologies, Inc. | Incentive driven content delivery |
| US8606996B2 (en) | 2008-03-31 | 2013-12-10 | Amazon Technologies, Inc. | Cache optimization |
| US9407681B1 (en) | 2010-09-28 | 2016-08-02 | Amazon Technologies, Inc. | Latency measurement in resource requests |
| US8122098B1 (en) | 2008-11-17 | 2012-02-21 | Amazon Technologies, Inc. | Managing content delivery network service providers by a content broker |
| US8073940B1 (en) | 2008-11-17 | 2011-12-06 | Amazon Technologies, Inc. | Managing content delivery network service providers |
| US8782143B2 (en) * | 2008-12-17 | 2014-07-15 | Adobe Systems Incorporated | Disk management |
| EP2411918B1 (en) * | 2009-03-23 | 2018-07-11 | Riverbed Technology, Inc. | Virtualized data storage system architecture |
| US8756341B1 (en) | 2009-03-27 | 2014-06-17 | Amazon Technologies, Inc. | Request routing utilizing popularity information |
| US8688837B1 (en) | 2009-03-27 | 2014-04-01 | Amazon Technologies, Inc. | Dynamically translating resource identifiers for request routing using popularity information |
| US8412823B1 (en) | 2009-03-27 | 2013-04-02 | Amazon Technologies, Inc. | Managing tracking information entries in resource cache components |
| US9131004B2 (en) * | 2009-04-26 | 2015-09-08 | Jeffrey Alan Carley | Method and apparatus for network address resolution |
| US9076239B2 (en) * | 2009-04-30 | 2015-07-07 | Stmicroelectronics S.R.L. | Method and systems for thumbnail generation, and corresponding computer program product |
| US8782236B1 (en) | 2009-06-16 | 2014-07-15 | Amazon Technologies, Inc. | Managing resources using resource expiration data |
| US8397073B1 (en) | 2009-09-04 | 2013-03-12 | Amazon Technologies, Inc. | Managing secure content in a content delivery network |
| CN102025750A (zh) * | 2009-09-15 | 2011-04-20 | 天津七所信息技术有限公司 | 网络缓存代理服务系统 |
| US8433771B1 (en) | 2009-10-02 | 2013-04-30 | Amazon Technologies, Inc. | Distribution network with forward resource propagation |
| CN101707684B (zh) * | 2009-10-14 | 2014-04-30 | 北京东方广视科技股份有限公司 | 一种Cache调度的方法、设备及系统 |
| US9495338B1 (en) | 2010-01-28 | 2016-11-15 | Amazon Technologies, Inc. | Content distribution network |
| US8898181B2 (en) * | 2010-06-22 | 2014-11-25 | Microsoft Corporation | Subscription for integrating external data from external system |
| US8468247B1 (en) | 2010-09-28 | 2013-06-18 | Amazon Technologies, Inc. | Point of presence management in request routing |
| US9712484B1 (en) | 2010-09-28 | 2017-07-18 | Amazon Technologies, Inc. | Managing request routing information utilizing client identifiers |
| US10097398B1 (en) | 2010-09-28 | 2018-10-09 | Amazon Technologies, Inc. | Point of presence management in request routing |
| US9003035B1 (en) | 2010-09-28 | 2015-04-07 | Amazon Technologies, Inc. | Point of presence management in request routing |
| US10958501B1 (en) | 2010-09-28 | 2021-03-23 | Amazon Technologies, Inc. | Request routing information based on client IP groupings |
| KR101845110B1 (ko) * | 2010-10-06 | 2018-04-03 | 가부시끼가이샤 도시바 | 분산 캐쉬 일관성 프로토콜 |
| CN103154910A (zh) * | 2010-10-25 | 2013-06-12 | 马维尔国际贸易有限公司 | 群集高速缓冲存储器相干性协议 |
| US8452874B2 (en) | 2010-11-22 | 2013-05-28 | Amazon Technologies, Inc. | Request routing processing |
| US10467042B1 (en) | 2011-04-27 | 2019-11-05 | Amazon Technologies, Inc. | Optimized deployment based upon customer locality |
| US9691068B1 (en) * | 2011-12-15 | 2017-06-27 | Amazon Technologies, Inc. | Public-domain analyzer |
| US10623408B1 (en) | 2012-04-02 | 2020-04-14 | Amazon Technologies, Inc. | Context sensitive object management |
| US9154551B1 (en) | 2012-06-11 | 2015-10-06 | Amazon Technologies, Inc. | Processing DNS queries to identify pre-processing information |
| US9323577B2 (en) | 2012-09-20 | 2016-04-26 | Amazon Technologies, Inc. | Automated profiling of resource usage |
| US20140089778A1 (en) * | 2012-09-24 | 2014-03-27 | Amazon Technologies, Inc | Progressive Image Rendering Utilizing Data URI Enhancements |
| US9274954B1 (en) * | 2012-12-18 | 2016-03-01 | Netapp, Inc. | Caching data using multiple cache devices |
| US10205698B1 (en) | 2012-12-19 | 2019-02-12 | Amazon Technologies, Inc. | Source-dependent address resolution |
| US9893971B1 (en) * | 2012-12-31 | 2018-02-13 | Juniper Networks, Inc. | Variable timeouts for network device management queries |
| US9384208B2 (en) * | 2013-01-22 | 2016-07-05 | Go Daddy Operating Company, LLC | Configuring a cached website file removal using a pulled data list |
| US9294391B1 (en) | 2013-06-04 | 2016-03-22 | Amazon Technologies, Inc. | Managing network computing components utilizing request routing |
| CN104252391B (zh) * | 2013-06-28 | 2017-09-12 | 国际商业机器公司 | 用于在分布式计算系统中管理多个作业的方法和装置 |
| CN103412884B (zh) * | 2013-07-18 | 2016-12-28 | 华中科技大学 | 一种异构存储介质下嵌入式数据库的管理方法 |
| CN104580268A (zh) * | 2013-10-09 | 2015-04-29 | 南京中兴新软件有限责任公司 | 文件数据的传输方法及装置 |
| EP2963894A1 (en) * | 2014-07-04 | 2016-01-06 | Thomson Licensing | Method for operating a cache arranged along a transmission path between client terminals and at least one server, and corresponding cache. |
| US20160134929A1 (en) * | 2014-11-07 | 2016-05-12 | Qualcomm Incorporated | Collaborative Distributed/Unstructured Service Management Framework for Wireless-Display Platform |
| US10033627B1 (en) | 2014-12-18 | 2018-07-24 | Amazon Technologies, Inc. | Routing mode and point-of-presence selection service |
| US10097448B1 (en) | 2014-12-18 | 2018-10-09 | Amazon Technologies, Inc. | Routing mode and point-of-presence selection service |
| US10091096B1 (en) | 2014-12-18 | 2018-10-02 | Amazon Technologies, Inc. | Routing mode and point-of-presence selection service |
| US20230079078A1 (en) * | 2014-12-30 | 2023-03-16 | Arteris, Inc. | Cache coherent system implementing victim buffers |
| US10225326B1 (en) | 2015-03-23 | 2019-03-05 | Amazon Technologies, Inc. | Point of presence based data uploading |
| US9819567B1 (en) | 2015-03-30 | 2017-11-14 | Amazon Technologies, Inc. | Traffic surge management for points of presence |
| US9832141B1 (en) | 2015-05-13 | 2017-11-28 | Amazon Technologies, Inc. | Routing based request correlation |
| CN104933187B (zh) | 2015-07-06 | 2019-02-01 | 张兆琦 | 一种用于操作系统或者应用程序的临时文件管理方法 |
| US10097566B1 (en) | 2015-07-31 | 2018-10-09 | Amazon Technologies, Inc. | Identifying targets of network attacks |
| US9774619B1 (en) | 2015-09-24 | 2017-09-26 | Amazon Technologies, Inc. | Mitigating network attacks |
| US10270878B1 (en) | 2015-11-10 | 2019-04-23 | Amazon Technologies, Inc. | Routing for origin-facing points of presence |
| WO2017091984A1 (zh) * | 2015-12-01 | 2017-06-08 | 华为技术有限公司 | 数据缓存方法、存储控制装置、及存储设备 |
| US10257307B1 (en) | 2015-12-11 | 2019-04-09 | Amazon Technologies, Inc. | Reserved cache space in content delivery networks |
| US10049051B1 (en) | 2015-12-11 | 2018-08-14 | Amazon Technologies, Inc. | Reserved cache space in content delivery networks |
| US10348639B2 (en) | 2015-12-18 | 2019-07-09 | Amazon Technologies, Inc. | Use of virtual endpoints to improve data transmission rates |
| KR102610846B1 (ko) * | 2016-05-13 | 2023-12-07 | 한국전자통신연구원 | 고속 분산 저장 장치 및 방법 |
| US10075551B1 (en) | 2016-06-06 | 2018-09-11 | Amazon Technologies, Inc. | Request management for hierarchical cache |
| CN107506314B (zh) * | 2016-06-14 | 2021-05-28 | 伊姆西Ip控股有限责任公司 | 用于管理存储系统的方法和装置 |
| US10110694B1 (en) | 2016-06-29 | 2018-10-23 | Amazon Technologies, Inc. | Adaptive transfer rate for retrieving content from a server |
| CN106227679B (zh) * | 2016-07-25 | 2018-12-28 | 北京邮电大学 | 一种数据缓存替换方法及装置 |
| US9992086B1 (en) | 2016-08-23 | 2018-06-05 | Amazon Technologies, Inc. | External health checking of virtual private cloud network environments |
| US10033691B1 (en) | 2016-08-24 | 2018-07-24 | Amazon Technologies, Inc. | Adaptive resolution of domain name requests in virtual private cloud network environments |
| US10616250B2 (en) | 2016-10-05 | 2020-04-07 | Amazon Technologies, Inc. | Network addresses with encoded DNS-level information |
| US10831549B1 (en) | 2016-12-27 | 2020-11-10 | Amazon Technologies, Inc. | Multi-region request-driven code execution system |
| US10372499B1 (en) | 2016-12-27 | 2019-08-06 | Amazon Technologies, Inc. | Efficient region selection system for executing request-driven code |
| US10938884B1 (en) | 2017-01-30 | 2021-03-02 | Amazon Technologies, Inc. | Origin server cloaking using virtual private cloud network environments |
| US10547876B2 (en) * | 2017-02-08 | 2020-01-28 | Nanning Fugui Precision Industrial Co., Ltd. | Video cache rule generation system and method |
| US10503613B1 (en) | 2017-04-21 | 2019-12-10 | Amazon Technologies, Inc. | Efficient serving of resources during server unavailability |
| US11075987B1 (en) | 2017-06-12 | 2021-07-27 | Amazon Technologies, Inc. | Load estimating content delivery network |
| US10447648B2 (en) | 2017-06-19 | 2019-10-15 | Amazon Technologies, Inc. | Assignment of a POP to a DNS resolver based on volume of communications over a link between client devices and the POP |
| JP6638145B2 (ja) * | 2017-07-14 | 2020-01-29 | 国立大学法人電気通信大学 | ネットワークシステム、ノード装置、キャッシュ方法及びプログラム |
| CN107463398B (zh) * | 2017-07-21 | 2018-08-17 | 腾讯科技（深圳）有限公司 | 游戏渲染方法、装置、存储设备及终端 |
| US10742593B1 (en) | 2017-09-25 | 2020-08-11 | Amazon Technologies, Inc. | Hybrid content request routing system |
| US10592418B2 (en) * | 2017-10-27 | 2020-03-17 | Dell Products, L.P. | Cache sharing in virtual clusters |
| US10592578B1 (en) | 2018-03-07 | 2020-03-17 | Amazon Technologies, Inc. | Predictive content push-enabled content delivery network |
| US20190303037A1 (en) * | 2018-03-30 | 2019-10-03 | Ca, Inc. | Using sequential read intention to increase data buffer reuse |
| US10862852B1 (en) | 2018-11-16 | 2020-12-08 | Amazon Technologies, Inc. | Resolution of domain name requests in heterogeneous network environments |
| US11025747B1 (en) | 2018-12-12 | 2021-06-01 | Amazon Technologies, Inc. | Content request pattern-based routing system |
| CN112738148B (zh) * | 2019-10-28 | 2024-05-14 | 中兴通讯股份有限公司 | 缓存内容的批量删除方法、装置、设备和可读存储介质 |
| CN115053517A (zh) | 2020-01-26 | 2022-09-13 | 巴科股份有限公司 | 同步本地房间和远程共享 |
| TWI751580B (zh) * | 2020-06-10 | 2022-01-01 | 財團法人工業技術研究院 | 儲存空間暫存檔案的管理方法及用於儲存多個暫存檔案的記錄裝置 |
Family Cites Families (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5848241A (en) * | 1996-01-11 | 1998-12-08 | Openframe Corporation Ltd. | Resource sharing facility functions as a controller for secondary storage device and is accessible to all computers via inter system links |
| JPH10222411A (ja) * | 1997-02-05 | 1998-08-21 | Nippon Telegr & Teleph Corp <Ntt> | プロキシキャッシュサーバ制御方法及びプロキシキャッシュサーバ |
| US6073129A (en) * | 1997-12-29 | 2000-06-06 | Bull Hn Information Systems Inc. | Method and apparatus for improving the performance of a database management system through a central cache mechanism |
| JP3463803B2 (ja) | 1999-11-09 | 2003-11-05 | 松下電器産業株式会社 | クラスタサーバ装置 |
| JP4505977B2 (ja) * | 2000-11-10 | 2010-07-21 | ソニー株式会社 | データ蓄積装置およびその方法、ならびに記録媒体 |
| US7136885B2 (en) * | 2002-12-20 | 2006-11-14 | International Business Machines Corporation | Free space management |
-
2002
- 2002-07-04 JP JP2002195654A patent/JP4244572B2/ja not_active Expired - Fee Related
-
2003
- 2003-06-24 WO PCT/JP2003/007971 patent/WO2004006101A1/ja active Application Filing
- 2003-06-24 CN CNB038208652A patent/CN100383758C/zh not_active Expired - Fee Related
- 2003-06-24 US US10/520,427 patent/US7287136B2/en not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| US20050172080A1 (en) | 2005-08-04 |
| WO2004006101A1 (ja) | 2004-01-15 |
| JP2004038627A (ja) | 2004-02-05 |
| US7287136B2 (en) | 2007-10-23 |
| CN100383758C (zh) | 2008-04-23 |
| CN1679004A (zh) | 2005-10-05 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4244572B2 (ja) | キャッシュ装置、およびキャッシュデータ管理方法、並びにコンピュータ・プログラム | |
| JP4938092B2 (ja) | エッジネットワークにおけるデータ配信方法、データ配信システム、および関連装置 | |
| JP3768406B2 (ja) | 移動通信網における情報配信制御方法及びシステム、及び移動通信網における通信ノードでの情報蓄積方法 | |
| US7472143B2 (en) | File migration device | |
| JP4997950B2 (ja) | ネットワーク管理システム、ネットワーク管理プログラムおよびネットワーク管理方法 | |
| US20060265465A1 (en) | Method, apparatus and system for processing message bundles on a network | |
| JP2004172917A (ja) | パケット検索装置及びそれに用いるパケット処理検索方法並びにそのプログラム | |
| US9294397B1 (en) | Apparatus and method for forwarding packets based on approved associations between ports and addresses of received packets | |
| JP2000207370A (ja) | 分散ファイル管理装置及び分散ファイル管理システム | |
| CN103595808B (zh) | 一种文件更新信息推送方法及装置 | |
| US20070088854A1 (en) | Apparatus for searching TCP and UDP sockets | |
| JP2021519041A (ja) | Ｉｃｎメッセージの転送方法 | |
| JP2019180009A (ja) | 無線通信システムおよび無線通信方法 | |
| WO2023125380A1 (zh) | 一种数据管理的方法及相应装置 | |
| CN1829231A (zh) | 直接接收入站数据的方法和装置 | |
| JP2896394B2 (ja) | ファイルサーバ装置 | |
| US9348847B2 (en) | Data access control apparatus and data access control method | |
| KR20050024446A (ko) | 캐시 장치 및 캐시 데이터 관리 방법과 컴퓨터 프로그램 | |
| JP2005100007A (ja) | データファイル保存システムおよびアロケーション方法 | |
| JP4946906B2 (ja) | マルチキャストアドレス情報処理装置及びマルチキャストアドレス情報処理プログラム | |
| US7159019B2 (en) | Information collection apparatus and method | |
| US7487256B2 (en) | Dynamic management method for forwarding information in router having distributed architecture | |
| JP3709905B2 (ja) | ネットワークサーバ装置 | |
| JP4064162B2 (ja) | ファイル蓄積装置および方法 | |
| CN114157620B (zh) | 一种报文转发方法及装置 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20050701 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20080909 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20081110 |
|
| 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: 20081216 |
|
| 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: 20081229 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120116 Year of fee payment: 3 |
|
| LAPS | Cancellation because of no payment of annual fees |