JP2004280826A - プロトコル独立型クライアント側キャッシュ（ｐｒｏｔｏｃｏｌ−ｉｎｄｅｐｅｎｄｅｎｔｃｌｉｅｎｔ−ｓｉｄｅｃａｃｈｉｎｇ）システムおよび方法 - Google Patents

Abstract

【課題】 リモートファイルハンドリングプロトコルから独立してネットワークファイルデータのクライアント側キャッシュを自動的かつ透過的に処理するシステムおよび方法を提供すること。
【解決手段】 プロトコル独立型クライアント側キャッシュ機構は、ネットワークへのファイル関連の要求を処理するサービスとして挿入され、クライアント側キャッシュストアを介して要求を満たそうと試みる。ファイル作成要求時の前処理および後処理の呼出しを介して、ＣＳＣ機構は、ファイル関連データ構造を作成しこれらの構造内の情報を上書きして、ネットワークリダイレクタにコールバックし、それ自体をネットワークリダイレクタとバッファリングサービスの間の通信フローに挿入する。いったん通信のフローに入ると、ネットワーク制御型ファイル読取りおよび書込み要求は、適切なときにクライアント側キャッシュ機構によって透過的に処理することができる。
【選択図】 図２

Description

本発明は一般にコンピュータネットワークに関し、より詳細にはネットワーク環境におけるデータストレージに関する。

ネットワークサーバーは、一般にアプリケーションプログラムのファイル関連の要求をアプリケーションサーバーにリダイレクトするリダイレクタの概念に基づく機構を含む様々な機構を使用してクライアントデータを格納し、クライアントデータにアクセスできるようにする。サーバーは、つまりエラー、アクセス権違反、または他の問題が生じない限り、各要求を受信し、要求されたファイル操作を実行する。次いでサーバーは、成功ステータス（ｓｕｃｃｅｓｓ ｓｔａｔｕｓ）を、アプリケーションプログラムがその要求に応答して受信する任意の対応するデータ、例えば作成／オープン要求の場合はファイルハンドル、読取り要求の場合はファイルデータなどとともに戻す。

コンピュータユーザーは、常にネットワークファイルサーバーに接続しているわけではないため、ネットワークの停止または故意の切断など、ファイルのネットワークバージョンがその他の方法では使用できないときに、ローカルファイルのコピーへのオフラインアクセスを可能にする様々なクライアント側キャッシュ機構が開発されている。こうしたキャッシュ機構の１つはブリーフケースと呼ばれており、ユーザーは、表示されているブリーフケースに、またはブリーフケースからファイルをドラッグし、本質的に手動でどのファイルをキャッシュするかを決定し、それらがキャッシュされるときに、任意のマージ（ファイルバージョンのコンフリクト）を解決することによってローカルファイルキャッシュを管理する。容易に理解できるように、ブリーフケース機構は、膨大な量のユーザーインタラクションを必要とし、ユーザーにとっては比較的不便となっている。さらに、ブリーフケース機構は、ファイルシステムの名前空間とは無関係のそれ自体の名前空間を有しており、例えばファイル名は、ブリーフケースの名前空間およびファイルシステムの名前空間の両方に存在している、または一方に存在し、もう一方には存在しないことがあり得る。アプリケーションは、ブリーフケース機構から利益を直接または透過的に得ることがない。というのは、ブリーフケースはシェルプログラムであり、ファイル関連の操作を実行するためにアプリケーションプログラムが依存するオペレーティングシステムおよび／またはファイルシステムの一部ではないからである。

米国特許出願第０９／１３４，７２０号に、クライアント側キャッシュの最近の改良について記載されている。これは一般にファイルの永続的なクライアント側のキャッシュを対象としている。この改良によって、ネットワーククライアントは、クライアントがネットワークに接続されているときと同じファイル名を使用し、同じ名前空間でローカルにキャッシュされたファイルのコピーにアクセスすることができる。自動キャッシュが提供され（ただし手動構成は依然として可能）、それによってユーザーインタラクションの必要性の多くが低減する。さらにこの改良では、クライアント側キャッシュ技術の大部分が、ＣＩＦＳ（Ｃｏｍｍｏｎ Ｉｎｔｅｒｎｅｔ Ｆｉｌｅ Ｓｙｓｔｅｍ）リダイレクタに組み込まれている。これは、よく知られているＳＭＢ（サーバーメッセージブロック）プロトコルの発行された拡張であるＣＩＦＳリモートファイルアクセスプロトコルを使用する。キャッシュはリダイレクタで処理されるため、アプリケーションプログラムは、キャッシュから透過的に利益を得る。例えば、ユーザーがネットワークから切断されているとき、要求されたファイル操作を、サーバーの代わりにファイルのキャッシュされたコピーに自動的にリダイレクトすることができる。

したがってこうしたクライアント側キャッシュ技術は、ネットワークから切断されたとき、またはネットワークがダウンしたとき、本質的に必要なファイルにアクセスできるようにすることによって多くの利益を提供するが、現在のクライアント側キャッシュ機構のいくつかの欠点が依然として存在する。こうした１つの欠点は、既存のキャッシュ技術がＣＩＦＳリダイレクタと密に一体化されていることである。したがって透過的なクライアント側キャッシュは、ＷｅｂＤＡＶベース（または単純なＤＡＶ、分散オーサリングおよびバージョン管理：Ｄｉｓｔｒｉｂｕｔｅｄ Ａｕｔｈｏｒｉｎｇ ａｎｄ Ｖｅｒｓｉｏｎｉｎｇ）、ＮＦＳベース（Ｎｅｔｗｏｒｋ Ｆｉｌｅ Ｓｙｓｔｅｍ）のサーバー／プロトコルなど他のプロトコルを有する他のサーバータイプには使用できない。同様のキャッシュ技術の各リダイレクタへの追加は、様々なリダイレクタ構成要素の変更を要することになる。これは、特にサードパーティのリダイレクタドライバを用いる場合、実現不可能ではないにしても望ましくない。

要約すれば、クライアント側ファイルキャッシュに関してプロトコルに依存せず、それによってサーバーのタイプにわたって均一なオフライン経験をユーザーに提供し、しかし実質的に既存のネットワーキング構成要素への変更は不要である方法およびシステムが必要である。この方法およびシステムは、ユーザーおよび既存のアプリケーションに対して透過であり、現在のクライアント側キャッシュに関連する他の欠点を克服すべきである。

簡単に言えば、本発明は、任意のリモートファイル処理プロトコルに依存しない、ネットワークファイルデータのクライアント側キャッシュを自動的かつ透過的に処理するキャッシュシステムおよび方法を提供する。プロトコル独立型クライアント側キャッシュ機構は、ネットワークに向けられるファイル関連の要求を処理し、クライアント側キャッシュ永続ストアを介して要求を満たそうと試みるサービスとして挿入される。このために、１つのアーキテクチャでは、オンライン時に、ネットワークリダイレクタ構成要素と、ダイレクタによって呼び出され、リファイル関連（例えば読取りまたは書込み）要求をバッファリングサービスのメモリ内バッファを介して処理することができるかどうかを決定するバッファリングサービスとの間の通信フローに代理プロバイダの形態のクライアント側キャッシュ機構が挿入される。一般にこのアーキテクチャでは、クライアント側キャッシュ機構は、クライアント側キャッシュ機構をバッファリングサービスからリダイレクタとして見えるようにし、さらにリダイレクタからバッファリングサービスのように見えるようにして、フィルタスタック内のフィルタドライバとして提供される。クライアント側キャッシュ機構の通信フローへの挿入は、部分的に、ファイル作成／オープン要求（ｏｐｅｎ ｒｅｑｕｅｓｔ）の終わりに、呼出し側プロバイダに戻るためにバッファリングサービスが使用するリダイレクタ装置オブジェクトデータ（ファイルのデータ構造に存在する）を上書きして、バッファリングサービスが代わりにクライアント側キャッシュ機構を呼び出すようにすることによって達成される。

クライアント側キャッシュ機構がネットワークファイル関連の入出力（Ｉ／Ｏ）要求を処理できるようにするために、クライアント側キャッシュ機構は、ネットワークファイル関連のＩ／Ｏ要求を受信するシステム構成要素に代理プロバイダとして登録する。これは、一実装形態ではＭｕｌｔｉｐｌｅ ＵＮＣ（汎用名前付け規則：Ｕｎｉｆｏｒｍ Ｎａｍｉｎｇ Ｃｏｎｖｅｎｔｉｏｎ）プロバイダまたはＭＵＰと呼ばれる。ＭＵＰは、任意のファイル関連の要求が他の任意の代理プロバイダまたは任意のリダイレクタに提供される前に、クライアント側キャッシュ機構の前処理ハンドラを呼び出す。またＭＵＰは、任意のファイル関連の要求が他の任意の代理プロバイダまたは任意のリダイレクタに提供された後に、クライアント側キャッシュ機構の後処理ハンドラも呼び出す。このように、ファイル作成の場合、クライアント側キャッシュ機構は、他の要求を扱うのに必要なデータ構造を生成し、構成することができる。

例えば、ファイル作成（またはオープン）の場合、Ｉ／Ｏマネージャは、ファイルオブジェクトを作成し、名前を解析し、そのファイルがリモートオブジェクトであることを名前が示しているときは、その要求をＭＵＰに転送する。作成要求を別の代理プロバイダまたは任意のリダイレクトに送信する前に、ＭＵＰは、前処理操作で、要求をクライアント側キャッシュ機構（代理プロバイダ）に送信する。クライアント側キャッシュ機構前処理ハンドラは、論理名前空間によるファイルコピーに関連する論理接続構造、およびファイルオブジェクトに関連付けられる関係のあるファイルベースデータ構造を含む、ファイルオブジェクトに関連付けられるデータ構造を作成し、オンラインの場合、クライアント側キャッシュ機構の構造およびリダイレクタの構造との間で共有することができる。（例えば前の作成要求から）オフラインであることがわかっている場合、クライアント側キャッシュ前処理ハンドラは要求を完了する。

オンライン時、または接続ステータスがわからない場合、クライアント側キャッシュ機構は、「さらに処理が必要」（ｍｏｒｅ ｐｒｏｃｅｓｓｉｎｇ ｒｅｑｕｉｒｅｄ）ステータスをＭＵＰに戻し、ＭＵＰは、一般に要求に関連する名前空間を論理から物理に変更するＤＦＳ代理プロバイダを呼び出す。ＭＵＰは、必要に応じてリダイレクタを呼び出し、リダイレクタの１つが、オンライン接続がある場合にパスを主張し、ネットワークサーバーでファイルに関連する物理接続ベースのデータ構造を作成できるようにする。クライアント側キャッシュ機構後処理ハンドラが呼び出されると、後処理ハンドラは、データ構造内の情報に基づいて必要に応じてその論理データ構造を完成させる。また、後処理ハンドラは、このファイルがオフラインかオンラインかを決定する（例えばリダイレクタによって主張される）。後処理ハンドラは、リダイレクタ関連のデータ（例えばファイル制御ブロックデータ構造内のリダイレクタディスパッチテーブルへのポインタ）を上書きし、オンライン時に、バッファリングサービスがリダイレクタの代わりにクライアント側キャッシュ機構を呼び出すようにする。クライアント側キャッシュ機構は、ファイルと関連するリダイレクタ（ポインタ）データのコピーを維持し、その結果クライアント側キャッシュ機構が必要に応じてリダイレクタと通信することができ、それによってそれ自体がバッファリングサービスとリダイレクタの間の通信フローに挿入される。リダイレクタがネットワーク関連のエラーを戻した場合、クライアント側キャッシュ後処理は、ファイルをオフラインとみなし、それによってリダイレクタを呼び出すことなく、ファイルに対する要求がクライアント側キャッシュから満たされるよう試行される。キャッシュが（サーバーによって）使用不可にされている場合、クライアント側キャッシュ機構後処理は、それ自体をファイルオブジェクトから引き離し、それによってＭＵＰはこのファイルオブジェクトに関連する任意の要求を転送しないようにすることができる。例えば、ファイル制御ブロック上のリダイレクタ関連のデータを上書きしないことによって、クライアント側キャッシュ機構は、このファイルオブジェクトに関連するその後のファイルＩ／Ｏの制御フローに関与しなくなる。

オフラインおよびオンラインの作成では、同じファイルへの作成要求がクライアント側キャッシュプロセスで同期される。このために、同じファイルに向けられる別の作成をクライアント側前処理に送信する場合、クライアント側キャッシュ前処理は、現在のものが完了するまで、後の各作成要求を保持する。

例えば、読取り、書込み、またはクローズなどの他の（非作成）ファイル要求の場合、オフライン時に、クライアント側キャッシュ機構は、その前処理で要求を最初に調べることができ、読取りおよび書込み要求などでの適切な場合に、バッファリングサービスを呼び出すことによってメモリ内で要求を満たそうと試みる。対応するデータがメモリ内にキャッシュされてない（キャッシュミスが発生した）場合、したがってバッファリングサービスはそのデータをすぐに読み取り、またはそこに書き込むことができない場合、バッファリングサービスは、第１の要求を保持し、（例えばバッファリングサービスのキャッシュマネージャ／メモリマネージャなどによって）別の第２の要求を生成する。この第２の要求は、クライアント側キャッシュ前処理に到達すると、バッファリングサービスを呼び出し、バッファリングサービスは、その要求をキャッシュミスによって生成されたものとして認識し、したがってキャッシュ内でデータを探さず、代わりにクライアント側キャッシュ機構を呼び出す。クライアント側キャッシュ機構は、要求を処理し、必要なデータを永続ストア内のオフラインキャッシュコピーから取得しようと試み、データをキャッシュマネージャ／メモリマネージャに戻す。次いでキャッシュマネージャ／メモリマネージャは、データをメモリ内キャッシュにコピーし、Ｉ／Ｏ要求を完了させ、例えば読取り要求の場合はデータを戻す、またはキャッシュメモリ内の書込み要求の場合はデータを変更することができる。このファイルでは接続がオフラインであるため、クライアント側キャッシュ機構がそのストアから必要なデータを取得することができない場合、クライアント側キャッシュ機構はエラーを戻す。したがって、キャッシュミスの場合、バッファリングサービスは、クライアント側キャッシュ機構の第２の要求（バッファリングサービス構成要素によって生成される）の処理からの結果に基づいて第１の要求を完了させ、メモリ内キャッシュにデータを提供する。

オンライン時の非作成ファイルＩ／Ｏ要求の場合、クライアント側キャッシュ機構前処理は、「さらに処理が必要」ステータスをＭＵＰに戻し、次いでＭＵＰは他の任意の代理プロバイダを呼び出し、要求を対応するリダイレクタに転送する。次に、リダイレクタは（例えばサービスのバッファサブシステムを呼び出すことによって）バッファリングサービスを呼び出し、メモリから要求を満たそうと試みる。対応するデータがメモリにキャッシュされていない場合、バッファリングサービスは、第１の要求を保持し、その構成要素（例えばキャッシュマネージャ／メモリマネージャ）が別の第２の要求を生成する。この第２の要求は、リダイレクタに到達すると、バッファリングサービスを再度呼び出すが、このときバッファリングサービスは、キャッシュミスによって生成されたものとして要求を認識し、したがって、キャッシュ中でデータを再度探さないことがわかっている。しかし、クライアント側キャッシュ後処理は、ディスパッチャテーブル内のリダイレクタポインタを上書きしたため、リダイレクタは、バッファリングサービスのバッファサブシステムを呼び出したが、バッファリングサービスは、クライアント側キャッシュ機構を呼び出す。永続ストア内のオフラインキャッシュコピーを使用して要求を満たすことができる場合、クライアント側キャッシュ機構は、要求を処理する。要求を満たすことができない場合、（リダイレクタポインタを保存した）クライアント側キャッシュ機構は、リダイレクタを呼び出してサーバーから取る要求を満たそうと試みる。リダイレクタは、リダイレクタによって戻されたデータをそれ自体の永続ストアにキャッシュすることができるクライアント側キャッシュ機構に戻り、次いで第２の要求を完了するバッファサブシステムに戻り、それによってバッファリングサービスのキャッシュ構成要素に到達する。キャッシュ構成要素は、次いで第１の要求を完了し、第２の要求のクライアント側キャッシュ機構（および場合によってはリダイレクタ）の処理からの結果に基づいて戻されたデータをメモリ内キャッシュにキャッシュする。概念上、クライアント側キャッシュ機構は、バッファリングサービスからリダイレクタへの呼出しをインターセプトするようにそれ自体を挿入し、特に、必要とされているデータをクライアント側キャッシュオフラインストアから満たすことができるかどうかを調べる。

オンライン接続を有するファイルに対してクローズが発行されると、ＭＵＰは、要求をクライアント側キャッシュ機構前処理に送信する。次いでクライアント側キャッシュ機構は、まだサーバーに送信されていないデータがあるかどうかをチェックする。データがある場合、クライアント側キャッシュ機構は、ダーティページをサーバーにフラッシュする。次いでクライアント側キャッシュ機構は、その接続に対してクローズ要求をリダイレクタに送信し、そのデータ構造を逆参照し、要求を完了する。他の要求は、同様に処理される。接続がオフラインの場合、クライアント側キャッシュ機構は、タスクをローカルに実行する。

わかるように、クライアント側キャッシュ機構は、リダイレクタの外部のネットワークファイル関連要求と連動するため、クライアント側キャッシュ機構は、プロトコルに依存せず、リダイレクタがバッファリングサービス（または同様の）アーキテクチャに参加している限り、任意のリダイレクタプロトコルと連動することができる。

他の利点は、以下の詳細な説明を図面と併せ読めば明らかになる。

動作環境の例
図１は、本発明を実施できる適したコンピューティングシステム環境１００の例を示している。コンピューティングシステム環境１００は、適したコンピューティング環境の一例にすぎず、本発明の使用または機能の範囲に関する限定を示唆するものではない。また、コンピューティングシステム環境１００を、コンピューティングシステム環境１００の例に示した構成要素のいずれか１つ、またはその組合せに関連する依存性または必要条件を有しているものと解釈すべきではない。

本発明は、他の多くの汎用または専用コンピューティングシステム環境または構成で動作可能である。本発明との使用に適したよく知られているコンピューティングシステム、環境、および／または構成の例には、それだけには限定されないが、パーソナルコンピュータ、サーバーコンピュータ、ハンドヘルドまたはラップトップ装置、タブレット装置、マルチプロセッサシステム、マイクロプロセッサベースのシステム、セットトップボックス、プログラム可能家庭用電化製品、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータ、上記の任意のシステムまたは装置を含む分散コンピューティング環境などがある。

本発明は、コンピュータによって実行されるプログラムモジュールなどのコンピュータ実行可能命令の一般的な文脈で説明することができる。一般にプログラムモジュールは、特定のタスクを実行する、または特定の抽象データ型を実装するルーチン、プログラム、オブジェクト、構成要素、データ構造などを含む。また本発明は、タスクが通信ネットワークによってリンクされているリモート処理装置によって実行される分散コンピューティング環境で実施することもできる。分散コンピューティング環境では、プログラムモジュールを、メモリ記憶装置を含むローカルおよびリモートのコンピュータ記憶媒体に置くことができる。

図１を参照すると、本発明を実施するシステムの例は、汎用コンピューティング装置をコンピュータ１１０の形で含んでいる。コンピュータ１１０の構成要素は、それだけには限定されないが、処理ユニット１２０、システムメモリ１３０、およびシステムメモリを含む様々なシステム構成要素を処理ユニット１２０に結合するシステムバス１２１を含む。システムバス１２１は、様々なバスアーキテクチャのうちの任意のものを使用するメモリバスまたはメモリコントローラ、周辺バス、およびローカルバスを含むいくつかのタイプのバス構造のうちどんなものでもよい。こうしたアーキテクチャには、それだけには限定されないが一例として、ＩＳＡ（Ｉｎｄｕｓｔｙ Ｓｔａｎｄａｒｄ Ａｒｃｈｉｔｅｃｔｕｒｅ）バス、ＭＣＡ（Ｍｉｃｒｏ Ｃｈａｎｎｅｌ Ａｒｃｈｉｔｅｃｔｕｒｅ）バス、ＥＩＳＡ（Ｅｎｈａｎｃｅｄ ＩＳＡ）バス、ＶＥＳＡ（Ｖｉｄｅｏ Ｅｌｅｃｔｒｏｎｉｃｓ Ｓｔａｎｄａｒｄ Ａｓｓｏｃｉａｔｉｏｎ）ローカルバス、およびメザニンバスとしても知られているＰＣＩ（Ｐｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔ Ｉｎｔｅｒｃｏｎｎｅｃｔ）バスなどがある。

コンピュータ１１０は、一般に様々なコンピュータ可読媒体を含む。コンピュータ可読媒体は、コンピュータ１１０からアクセスできる使用可能な任意の媒体とすることができ、揮発性および不揮発性媒体、リムーバブルおよび非リムーバブル媒体を含む。コンピュータ可読媒体は、それだけには限定されないが一例として、コンピュータ記憶媒体および通信媒体を含み得る。コンピュータ記憶媒体には、コンピュータ可読命令、データ構造、プログラムモジュール、他のデータなど、情報を記憶するための任意の方法または技術で実施される揮発性および不揮発性のリムーバブルおよび非リムーバブル媒体がある。コンピュータ記憶媒体には、それだけには限定されないが、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリまたは他のメモリ技術、ＣＤ−ＲＯＭ、デジタル多用途ディスク（ＤＶＤ）または他の光ディスク記憶装置、磁気カセット、磁気テープ、磁気ディスクストレージまたは他の磁気ストレージ、または所望の情報の格納に使用でき、コンピュータ１１０からアクセスできる他の任意の媒体などがある。通信媒体は一般に、コンピュータ可読命令、データ構造、プログラムモジュール、または他のデータを搬送波または他の移送機構などの変調されたデータ信号に組み込む。これには任意の情報配送媒体がある。「変調されたデータ信号」という用語は、信号内の情報を符号化するように設定または変更された１つまたは複数のその特徴を有する信号を意味する。通信媒体には、それだけには限定されないが一例として、有線ネットワーク、直接配線された通信などの有線媒体、および音響、ＲＦ、赤外線、その他の無線媒体などの無線媒体がある。また、上記のどんな組合せでもコンピュータ可読媒体の範囲内に含まれるものとする。

システムメモリ１３０は、読取り専用メモリ（ＲＯＭ）１３１やランダムアクセスメモリ（ＲＡＭ）１３２など、揮発性および／または不揮発性メモリの形態のコンピュータ記憶媒体を含む。ＢＩＯＳ（ｂａｓｉｃ ｉｎｐｕｔ／ｏｕｔｐｕｔ ｓｙｓｔｅｍ）１３３は、例えば起動中など、コンピュータ１１０内の要素間での情報の転送を助ける基本ルーチンを含み、一般にＲＯＭ１３１に格納される。ＲＡＭ１３２は一般に、処理ユニット１２０からすぐにアクセス可能な、かつ／または処理ユニット１２０が現在処理しているデータおよび／またはプログラムモジュールを含む。図１は、それだけには限定されないが一例として、オペレーティングシステム１３４、ファイルシステム１３５、アプリケーションプログラム１３６、他のプログラムモジュール１３７、およびプログラムデータ１３８を示している。

コンピュータ１１０は、他のリムーバブル／非リムーバブル、揮発性／不揮発性コンピュータ記憶媒体を含むこともできる。一例にすぎないが、図１は、非リムーバブル不揮発性磁気媒体から読み取り、あるいはそこに書き込むハードディスクドライブ１４１、リムーバブル不揮発性磁気ディスク１５２から読み取り、あるいはそこに書き込む磁気ディスクドライブ１５１、およびＣＤ−ＲＯＭや他の光媒体など、リムーバブル不揮発性光ディスク１５６から読み取り、あるいはそこに書き込む光ディスクドライブ１５５を示している。動作環境の例で使用できる他のリムーバブル／非リムーバブル、揮発性／不揮発性コンピュータ記憶媒体には、それだけには限定されないが、磁気テープカセット、フラッシュメモリカード、デジタル多用途ディスク、デジタルビデオテープ、半導体ＲＡＭ、半導体ＲＯＭなどがある。ハードディスクドライブ１４１は一般に、インターフェイス１４０などの非リムーバブルメモリインターフェイスを介してシステムバス１２１に接続され、磁気ディスクドライブ１５１および光ディスクドライブ１５５は一般に、インターフェイス１５０などのリムーバブルメモリインターフェイスによってシステムバス１２１に接続される。

上述し、図１に示したドライブおよびその関連のコンピュータ記憶媒体は、コンピュータ１１０のコンピュータ可読命令、データ構造、プログラムモジュール、および他のデータの記憶を提供する。図１では例えば、ハードディスクドライブ１４１は、オペレーティングシステム１４４、アプリケーションプログラム１４５、他のプログラムモジュール１４６、およびプログラムデータ１４７を記憶するものとして示されている。これらの構成要素は、オペレーティングシステム１３４、アプリケーションプログラム１３６、他のプログラムモジュール１３７、およびプログラムデータ１３８と同じであっても、異なっていてもよいことに注意されたい。オペレーティングシステム１４４、アプリケーションプログラム１４５、他のプログラムモジュール１４６、およびプログラムデータ１４７は少なくとも異なるコピーであることを示すために、ここではそれらに異なる番号を付している。ユーザーは、タブレット（電子デジタイザ）１６４、マイクロフォン１６３、キーボード１６２、および一般にマウス、トラックボール、またはタッチパッドと呼ばれるポインティング装置１６１などの入力装置を介してコマンドおよび情報をコンピュータ１１０に入力することができる。他の入力装置（図示せず）には、ジョイスティック、ゲームパッド、衛星放送受信アンテナ、スキャナなどがある。これらおよび他の入力装置は、しばしばシステムバスに結合されているユーザー入力インターフェイス１６０を介して処理ユニット１２０に接続されるが、パラレルポート、ゲームポート、ユニバーサルシリアルバス（ＵＳＢ）など他のインターフェイスおよびバス構造で接続してもよい。モニタ１９１または他のタイプの表示装置もまた、ビデオインターフェイス１９０などのインターフェイスを介してシステムバス１２１に接続される。モニタ１９１は、タッチスクリーンパネルなどと一体化することもできる。モニタおよび／またはタッチスクリーンパネルは、タブレット型パーソナルコンピュータなどのコンピューティング装置１１０が組み入れられるハウジングに物理的に結合できることに注意されたい。さらに、コンピューティング装置１１０などのコンピュータは、出力周辺インターフェイス１９４などを介して接続できるスピーカー１９５、プリンタ１９６などの他の周辺出力装置を含むこともできる。

コンピュータ１１０は、リモートコンピュータ１８０など１つまたは複数のリモートコンピュータへの論理接続を使用してネットワーク式環境で動作することができる。リモートコンピュータ１８０は、パーソナルコンピュータ、サーバー、ルーター、ネットワークＰＣ、ピア装置、または他の一般のネットワークノードでよく、一般にコンピュータ１１０に関連して上述した多くまたはすべての要素を含むが、図１にはメモリ記憶装置１８１のみを示している。図１に示した論理接続は、ローカルエリアネットワーク（ＬＡＮ）１７１および広域エリアネットワーク（ＷＡＮ）１７３を含むが、他のネットワークを含むこともできる。こうしたネットワーキング環境は、オフィス、全社規模のコンピュータネットワーク、イントラネット、およびインターネットではごく一般的である。例えば、本発明では、コンピュータシステム１１０は、データがそこからマイグレーションされるソースマシンを備え、リモートコンピュータ１８０は、宛先マシンを備えることができる。しかし、ソースマシンおよび宛先マシンは、ネットワークまたは他の任意の手段で接続する必要はなく、代わりに、ソースプラットフォームによって書き込むことができ、宛先プラットフォームによって読み取ることができる任意の媒体を介してデータをマイグレーションしてもよい。

ＬＡＮネットワーキング環境で使用する場合、コンピュータ１１０は、ネットワークインターフェイスまたはアダプタ１７０を介してＬＡＮ１７１に接続される。ＷＡＮネットワーキング環境で使用する場合、コンピュータ１１０は一般に、モデム１７２、またはインターネットなどＷＡＮ１７３にわたって通信を確立する他の手段を含む。モデム１７２は、内蔵のものでも外付けのものでもよく、ユーザー入力インターフェイス１６０または他の適切な機構を介してシステムバス１２１に接続することができる。ネットワーク式環境では、コンピュータ１１０に関連して示したプログラムモジュール、またはその一部をリモートメモリ記憶装置に格納することができる。図１は、それだけには限定されないが一例として、リモートアプリケーションプログラム１８５をメモリ装置１８１上に存在するものとして示している。図示したネットワーク接続は例であり、コンピュータ間の通信リンクを確立する他の手段を使用してもよいことは理解されよう。

クライアント側キャッシュシステムおよび方法
本発明は一般に、プロトコルベースのリダイレクタ、ＮＴＦＳファイルシステム、および他の構成要素（Ｉ／Ｏマネージャ、キャッシュマネージャ、およびメモリマネージャなど）を使用して、Ｍｉｃｒｏｓｏｆｔ社のＷｉｎｄｏｗｓ（登録商標）ＸＰオペレーティングシステムのコンテキストで説明する。ただし、本発明を事実上任意のオペレーティングシステムおよび／またはファイルシステムで実施できることは理解されよう。

図２を参照すると、本発明を実施するアーキテクチャ２００の例を示している。このアーキテクチャでは、ユーザーモードアプリケーションプログラム２０２は、アプリケーションプログラミングインターフェイス（ＡＰＩ）層２０４を介して様々なシステム機能を呼び出すことができる。ネットワークリソースにアクセスするために、ユーザーモードアプリケーションプログラム２０２は、Ｉ／Ｏマネージャ２０６を介してネットワークリソースに向けられるファイル入出力（Ｉ／Ｏ）ＡＰＩ呼出しを行う。例えば、Ｗｉｎｄｏｗｓ（登録商標）ベースのオペレーティングシステムでは、アプリケーションプログラムは、ＵＮＣ（汎用名前付け規則：Ｕｎｉｆｏｒｍ Ｎａｍｉｎｇ Ｃｏｎｖｅｎｔｉｏｎ）標準をＷｉｎ３２機能とともに使用してリモートリソースを例えば＼＼ｓｅｒｖｅｒ＼ｓｈａｒｅの形式で直接、またはネットワーク共有フォルダなどにマップされるドライブ名を介してアドレス指定することによってリモートシステム上のリソースを検査し、またはそれにアクセスすることができる。

アプリケーションからネットワークリソースへのアクセスが可能になる別の方法は、ネットワーキングＡＰＩ（Ｗｉｎｄｏｗｓ（登録商標）２０００オペレーティングシステムのＷｉｎ３２ Ｗｉｎｄｏｗｓ（登録商標）Ｎｅｔｗｏｒｋｉｎｇ（ＷＮｅｔ）ＡＰＩなど）を呼び出して、例えばブラウズ時にサーバーのファイルを列挙することによる。こうしたＷＮｅｔ ＡＰＩを介して、アプリケーションおよび／またはオペレーティングシステム構成要素は、共有のためにリモートコンピュータがエクスポートするコンピュータおよびリソースを列挙する。このため、ユーザーモードネットワークプロバイダ２１０〜２１３はそれぞれ、オペレーティングシステムをリモートネットワークサーバーのクライアントとして、または本発明ではクライアント側キャッシュのクライアント（一般にサーバーとして働く）として確立するソフトウェアコードを備える。例えば、ネットワークプロバイダが実行する一部の操作は、ネットワーク接続の確立および切断、およびネットワークリソースのステータスの問合せを含む。したがって、ネットワークプロバイダが提供する一般の機能には、呼出し元がネットワークプロバイダの能力を判定することができる能力機能、およびネットワークプロバイダがドライブ名、ＭＳ−ＤＯＳ（登録商標）装置、およびＬＰＴポートをリダイレクトすることができる装置リダイレクト機能（ｄｅｖｉｃｅ ｒｅｄｉｒｅｃｔｉｎｇ ｆｕｎｃｔｉｏｎ）がある。他の機能には、ネットワークプロバイダがネットワーク固有の情報を表示でき、またはそれに対して作用できるプロバイダ固有のダイアログ機能、ネットワークプロバイダが特殊なネットワークディレクトリを表示でき、またはそれに対して作用できる管理機能、およびネットワークリソースのブラウジングを可能にする列挙機能などがある。例えばオペレーティングシステムは、ＳＭＢネットワークプロバイダ２１１を介してネットワーク共有をＳＭＢサーバー３１１（図３）に列挙することができる。

アプリケーションがＡＰＩ層２０４のネットワーキングルーチンを呼び出すときに呼び出すべきネットワークプロバイダを決定するために、一実装形態では、呼が、ダイナミックリンクライブラリ（ＤＬＬ）としてインストールすることができる多重ネットワークプロバイダルーチン、すなわちＭＰＲ（多重プロバイダルータ）２１６に移動する。一般にＭＰＲ２１６は、どのユーザーモードネットワークプロバイダがアクセスされるリソースを認識するかを決定する。このため、ＭＰＲ２１６の下にあるインストールされている各ネットワークプロバイダは、まとめてネットワークプロバイダインターフェイスと呼ばれる１組の機能を提供し、これによってＭＰＲ２１６は、アプリケーションがアクセスしようとしているのがどのネットワークかを決定し、要求を適切なネットワークプロバイダソフトウェアに向けることができる。例えば、ＳＭＢのネットワークプロバイダは、システムレジストリキーなどで指定されるＬＡＮＭＡＮ（ローカルエリアネットワークマネージャ）ネットワークプロバイダ２１１を含む。

記載の実装形態では、リモートネットワークリソースに接続するために呼び出されると、ＭＰＲ２１６は、レジストリをチェックして、どのネットワークプロバイダがロードされているかを決定する。次いでＭＰＲ２１６は、例えば一度に１つ、構成可能なレジストリにリストされている順序でネットワークプロバイダをポーリングし、各ネットワークプロバイダ（例えばＤＡＶネットワークプロバイダ２１３）は、リソースが認識されるまで、または使用可能なネットワークプロバイダがポーリングされたときまでその対応するカーネルモード構成要素（例えばＤＡＶリダイレクタ２２５）とさらに通信することができる。したがって、例えば呼出しパラメータとしてＤＡＶサーバーに渡されたＵＲＬを介してネットワークリソースに向けられるネットワーキングＡＰＩ呼出しのイベントでは、ＭＰＲ２１６はＤＡＶネットワークプロバイダ２１３をポーリングし、ＤＡＶネットワークプロバイダ２１３はＲＰＣ（遠隔手続き呼出し）を介してサービスを呼び出し、カーネルモードのＤＡＶリダイレクタ２２５に連絡して、ＡＰＩを扱うことができるかどうか、例えば指定されたＤＡＶ共有が本当にアクセス可能なＤＡＶサーバー３１２（図３）であるかどうかを決定する。そうである場合、ＡＰＩがＤＡＶリダイレクタ構成要素２２５によって処理される。

また、アプリケーションは、リソースに以前マップされていたＵＮＣ名またはドライブ名を介してネットワークリソースに透過的にアクセスすることもできる。ファイルＩ／Ｏ ＡＰＩ（例えばファイル作成／オープン要求）がＵＮＣ名などリモートパス／ファイル名で呼び出されると、ファイルＩ／Ｏ要求は、Ｉ／Ｏマネージャ２０６で受信される。リモート名を処理するために、Ｉ／Ｏマネージャ２０６は、多重ＵＮＣプロバイダ、すなわちＭＵＰ（多重ＵＮＣプロバイダ）２３０（例えばカーネルモードドライブを備える）を呼び出す。これは、ＵＮＣプロバイダとしてシステムに登録される。一般にＭＵＰ２３０は、どの（例えばプロバイダ２１０〜２１３の組の）ネットワークプロバイダ、およびネットワークリダイレクタ２２３〜２２５の１つなどの対応するカーネル構成要素がその特定の名前を処理するかがわかる。この例ではリダイレクタは３つしか示していないが、所与のシステムでより少ない、または多いリダイレクタを使用できることに注意されたい。

要求されたファイル作成パスについての適切なリダイレクタを決定するために、ＭＵＰ２３０は、登録されているプロバイダ／リダイレクタの１つが作成要求で提供されたパスを主張するまで、本質的に登録されているプロバイダ／リダイレクタをポーリングする。一実装形態では、ＭＵＰ２３０は、非同期Ｉ／Ｏ要求パケット、すなわちＩＲＰを介してポーリングし、名前を処理することができる各リダイレクタが返答する。複数が肯定応答した場合、ＭＵＰ２３０は、優先順位（例えば少なくとも１つのシステムレジストリキーなどに維持されている）から、どれが要求を処理する優先権があるかを決定する。パスが主張されると、ユーザモードアプリケーションプログラムーがＩ／Ｏ ＡＰＩ呼出しを使用してリモートファイルにアクセスしたとき、ＭＵＰ２３０は、その要求を処理するためにどのリダイレクタを呼び出すかがわかる。

少なくとも１つのリダイレクタが応答し、パスを主張した場合、ＭＵＰドライバ２３０は、応答したリダイレクタに関連するパス情報をキャッシュ（複数の場合、優先権のあるものの情報をキャッシュ）し、それによってさらに、そのパス文字列で開始する要求が、ポーリング操作なしに、そのリダイレクタに直接送信される。ＭＵＰ２０６への応答の一部として、名前を認識する各リダイレクタは、名前のうちのどの程度がそれに固有であるかを識別する。例えば、名前がＵＮＣ名＼＼ＳＥＲＶＥＲ＼ＳＨＡＲＥ＼ｆｏｏ＼ｂａｒｌ．ｄｏｃであり、ＳＭＢリダイレクタ２２３が名前を処理できるものとして認識した場合、かつサーバーがＳＭＢサーバーである場合、ＳＭＢリダイレクタ２２３は、文字列「＼＼ＳＥＲＶＥＲ＼ＳＨＡＲＥ」をそれ自体として要求することによって応答する。したがって、このキャッシュされた文字列に対応するネットワーク共有に向けられる将来のＳＭＢ要求は、ポーリングなしにＳＭＢリダイレクタ２２３に渡され、ＳＭＢリダイレクタ２２３は、これらのＳＭＢ要求を、ネットワークを介してリモートＳＭＢサーバーに送信できるデータ構造にまとめる。

本発明の一態様によれば、適切な場合、代理プロバイダの形態のクライアント側キャッシュ（ＣＳＣ）機構２２１は、リダイレクタレベルで動作し、任意の特定のネットワークプロトコルに依存せず、ＣＳＣストア２１５からのネットワーク要求を透過的に処理する。一実装形態では、ＣＳＣ機構２２１は、開始から通信フローに関与する。このため、ＵＮＣまたはドライブ名ベースのネットワークＩ／Ｏ要求が受信されると、ＭＵＰ２３０は、リダイレクタのいずれかに連絡する前に、ＣＳＣ前処理ハンドラ２２６への前処理呼出しを介してＣＳＣ機構２２１と通信する。ＣＳＣ機構２２１は、後述するように、ステータス情報を備えて前処理呼出しから戻る。例えば、前処理ハンドラ２２６からは通信がオフラインであることがわかっている場合、つまり作成時にこのファイルのためにネットワークに接続されていないことがわかっている場合、クライアント側キャッシュ（ＣＳＣ）機構２２１は、パスを主張し、成功ステータスで呼び出しを完了する。そうでない場合、ＣＳＣは「さらに処理が必要」ステータスを戻すことができる。このイベントでは、ＭＵＰ２３０は同様に、リダイレクタ２２３〜２２５のうちの１つまたは複数を呼び出す前に、分散ファイルシステム（ＤＦＳ）代理プロバイダ２２２に前処理呼出しを行う。ＣＳＣ機構２２１は、図２の接続状態２５０に概略を示すように、例えば既存の接続データ構造を検査し、ネットワーク関連のイベントの登録を行うことによって、既知のやり方でネットワーク接続状態（他の構成要素と同様）を決定することができることに注意されたい。

したがってＣＳＣ機構２２１は、ネットワークに向けられる任意のＵＮＣおよびドライブ名ベースのＩ／Ｏのための前処理呼出しを受信する。ＭＵＰ２３０から呼び出されるために、ＣＳＣ機構２２１は、それ自体を代理プロバイダとして登録し、それによってＭＵＰ２３０は、ネットワークプロバイダおよび／またはその対応するリダイレクタに向けられるＩＲＰおよびＦＡＳＴＩＯ呼出しの場合、前処理呼出し、および後処理呼出しでＣＳＣ機構２２１を呼び出すことがわかっていることを注意されたい。

さらに処理が必要ステータスで戻る前処理呼出しでＣＳＣ機構２２１を呼び出した後、ＭＵＰ２３０は、ＤＦＳ代理プロバイダ２２２を呼び出す。一般にＤＦＳは、論理パス／ファイル名を物理パス／ファイル名に変換し、異なる多くのサーバーから単一の統一された名前空間を構築するシステムを提供する。次いでリダイレクタは、特定のリダイレクタが処理するファイルの適切に名づけられたパスを主張することができる。高レベルでは、ＤＦＳは、ＤＦＳ名前空間を備える個々のサーバーに、連絡点に応じて参照を提供するよう要求することによって動作する。一例によれば、ＤＦＳを使用して、１つの部の中にある異なるサーバーによって構築されるプログラムのリリースに単一の名前空間を提供することができる。例えば、名前＼＼ｐｒｏｇｂｕｉｌｄｓ＼ｒｅｌｅａｓｅ＼ｌａｂ０１＼ｒｅｌｅａｓｅ＼ｘ８６ｆｒｅは、＼＼ｒｏｂｖｂｌｌ＼ｒｅｌｅａｓｅへの連絡点である。この例で、＼＼ｐｒｏｇｂｕｉｌｄｓ＼ｒｅｌｅａｓｅ＼ｌａｂ０１＼ｒｅｌｅａｓｅ＼ｘ８６ｆｒｅ＼ｌａｔｅｓｔ＿ｔｅｓｔｅｄ＿ｂｕｉｌｄ．ｔｘｔを開くには、＼＼ｐｒｏｇｂｕｉｌｄｓサーバーは、＼＼ｒｏｂｖｂｌｌ＼ｒｅｌｅａｓｅ＼ｌａｔｅｓｔ＿ｔｅｓｔｅｄ＿ｂｕｉｌｄ．ｔｘｔとして参照を戻し、クライアントに要求を再試行するよう伝える。

理解できるように、連絡点を処理する一般のアルゴリズムは、名前の左部分を変更する。名前は、複数の連絡点をトラバースし、その結果、最終的に宛先サーバーに連絡する前に複数の名前のリビジョンがもたらされる。ファイル名識別子を右に配置することによって、たとえサーバーが連絡点を処理するためにクライアントが提供する名前を変更したとしても、識別子が名前に留まることができるようにする。

したがって、図２のアーキテクチャにおいて、また図３にも概略を示しているが、ＭＵＰ２３０がＵＮＣプロバイダとして登録されている状態で、ＭＵＰ２３０は、ＵＮＣ呼出しを処理し、適切な代理プロバイダの第１のもの、つまりＣＳＣ機構２２１にＵＮＣ呼出しを引き渡す。戻されたステータスに応じて、ＭＵＰ２３０は、ＵＮＣ呼出しを１つまたは複数の他の代理プロバイダ（符号２２２など）、およびリダイレクタ２２３〜２２５に引き渡すことができ、リダイレクタは、ネットワークトランスポート層３０１などを介して、リダイレクタプロトコルに対応するサーバー３１１〜３１３との間で通信を行う。前処理および後処理呼出しスキームのため、ＣＳＣ機構２２１は、ＭＵＰ２３０を通過する呼出しをフィルタ処理し、したがってＣＳＣ機構２２１は、適切であるとみなされるどんなパス名に対してもキャッシュ操作について判断することができる。概念上、ＣＳＣ機構２２１は、ＭＵＰ２３０が処理する全呼出しのパス上にあり、それによってＣＳＣ機構２１１は、以下で概説するように、ＣＳＣ機構２２１が適切なクライアント側キャッシュ機能を実行する必要があるどんな前処理および後処理でも行うことができる。さらに、このアーキテクチャでは、ＣＳＣ機構２２１は、前処理呼出しの場合はＤＦＳ代理プロバイダ２２２の前（および後処理呼出し時はＤＦＳの後）に動作するため、ＣＳＣ機構２２１が見る名前は物理名ではなく論理名なので、任意のＤＦＳ操作がＣＳＣに対して透過となる。図２のアーキテクチャで示したように、ＣＳＣ機構２２１およびＤＦＳ代理プロバイダ２２２は、ＭＵＰ２３０の一般レベルである。

本発明の別の態様によれば、クライアント側キャッシュ機能は、プロトコル独立型であり、例えば任意のリダイレクタと連動する。このため、クライアント側キャッシュ機能は、任意のプロトコル依存型リダイレクタ（すなわちＳＭＢリダイレクタ２２３）から出て行き、透過的に、リダイレクタとリダイレクトされたバッファサブシステム（ＲＤＢＳＳ）２３２との間の制御フローの一部になる。わかるように、リダイレクトされたバッファサブシステム２３２は、キャッシュマネージャ２４０およびメモリマネージャ２４２（メモリ内ＲＡＭキャッシュ２４４）サービスをリダイレクタ２２３〜２２５に提供する。これらはそれぞれ、適切な場合に、メモリ内ＲＡＭキャッシュ２４４を使用するためにＲＤＢＳＳ２３２に連絡する。後述するように、ＣＳＣ機構２２１を（ドライバとして）リダイレクタとリダイレクトされたバッファサブシステム２３２との間の制御フローに挿入することによって、クライアント側キャッシュ機能は、各リダイレクタにとって共通サービスとして使用可能となり、任意のネットワークから独立しているが、本質的にリダイレクタ２２３〜２２５およびリダイレクトされるバッファサブシステム２３２には透過である。本明細書で使用する場合、「バッファリングサービス」という用語は、このアーキテクチャの例における、ＲＤＢＳＳ２３２、キャッシュマネージャ２４０、メモリマネージャ２４２、およびメモリ内ＲＡＭキャッシュ２４４によってまとめて提供されるバッファリングサービスを含むファイル関連のデータバッファリングを処理する任意の構成要素を指すことに注意されたい。

ＣＳＣ機構２２１は、ユーザーが見る名前空間である論理名前空間に対して作用することに注意されたい。これは、データが格納される実際のサーバーに対応する物理名前空間に対して作用するリダイレクタとは対照的であることに注意されたい。関与するＤＦＳ連絡点がある場合を除いて、これら２つの名前空間は、例えばＳＭＢにとっては同一であることに注意されたい。

本発明の一態様によれば、図４は、論理名前空間および物理名前空間での論理接続ベースのデータ構造４００および物理接続ベースのデータ構造４２０、およびその関係を示している。ＣＳＣ機構２２１は、接続ベースのデータ構造４００を論理名前空間で維持し、各リダイレクタは、その接続ベースのデータ構造を物理名前空間４２０で維持している。

一般に、ＭＵＰ２３０が作成ファイル要求を受信し、ＣＳＣ前処理ハンドラ２２６を呼び出すと、ＣＳＣ機構２２１は、論理接続データ構造４００および共有ファイルベース構造４１０〜４２０を作成する。ファイルオブジェクト４１３は、Ｉ／Ｏマネージャ２０６（図２）によって作成されることに注意されたい。さらに、サーバーは、クライアント側キャッシュ機構がその後処理ハンドラ２２７を介して検出するクライアント側キャッシュを使用不可にすることができることに注意されたい。

ＣＳＣの論理接続データ構造４００は、例えば、論理的サーバー名、ＣＳＣ装置オブジェクト、ＣＳＣステータスフラグ、接続状態、およびスカベンジャマネージャを含めてサーバーの抽象を含むサーバー呼出しコンテキスト４０１を含む。（少なくとも１つの）ネットルート構造４０２はそれぞれ、共有名、共有タイプ、ＣＳＣ属性、アクセス権、オープンの数などを含む共有の抽象を含む。ネットルート構造の（少なくとも１つの）ビュー（ＶＮｅｔＲｏｏｔ）４０３はそれぞれ、セキュリティコンテキスト、およびユーザーセッション情報を含む共有のユーザーのビューの抽象を含む。

図４に示すように、共有データ構造は、ファイル制御ブロック４１０を、少なくとも１つのサーバー側オープンコンテキスト４１１、および少なくとも１つのファイルオブジェクト拡張データ構造４１２とともに含む。ファイル制御ブロック４１０は、本質的にファイルの抽象を備え、サイズデータ、タイムスタンプデータ、キャッシュマップなどのファイルの情報を含む。サーバー側オープンコンテキスト４１１は、サーバーに送信されたオープンの抽象、つまり所望され共有されるアクセス権を備えるサーバーファイルハンドルを含む。ＣＳＣ機構２２１は、この状況ではサーバーと似ており、例えばＣＳＣストア２１５内のファイルへのハンドルがこの構造内に維持される。ファイルオブジェクト拡張データ構造４１２は、ファイルオブジェクト４１３に関連する情報を含む。

図４にも示すように、システムがオンラインであり、クライアント側キャッシュが実行可能である場合、これらのデータ構造４１０〜４１３は、ＣＳＣ機構２１１とパスを主張したリダイレクタとの間で共有される。その結果、ファイルＩ／Ｏ要求は、以下に示す状況に基づいて、ＣＳＣ機構２２１またはファイルのパスを主張したリダイレクタのいずれかによって実行することができる。

図２のアーキテクチャに対応する一実装形態では、作成要求がＭＵＰ２３０に到達したとき、ＭＵＰ２３０は、ＣＳＣ機構２２１の前処理ハンドラ２２６（エントリポイント）を呼び出す。ＣＳＣ機構２２１は、作成要求で発行されたファイルオブジェクトの論理接続データ構造（サーバー呼出しコンテキスト４０１サーバー接続構造、ネットルート構造４０２、およびユーザーごと共有ＶＮｅｔＲｏｏｔ構造４０３）を見つけようと試みる。見つからなかった場合、ＣＳＣ機構２２１は、例えばＲＤＢＳＳ２３２を介してこれらの構造を作成する。接続がオフラインであることがわかっている場合、ＣＳＣ前処理ハンドラ２２６は、成功ステータス（または該当する場合はエラー）を戻し、そうでない場合は、「さらに処理が必要」ステータスを戻し、これによってＭＵＰ２３０は、ＤＦＳ代理プロバイダの前処理を呼び出し、次いでリダイレクタ２２３〜２２５のうちの１つまたは複数を呼び出してパスを開始しようと試みる。

パスが正常に開始すると（接続はオンライン）、接続ベースの物理構造４２０が適切なリダイレクタで確立され、ハンドルがファイルから使用可能になる。ＭＵＰ２３０は、ＣＳＣ後処理ハンドラ２２７を呼び出す。これは、ＦＣＢの物理的ネットルートを見ることによってファイル拡張子、サイズ、およびパスのキャッシュフラグを取得することができる。この情報を取得すると、例えばこのファイルにおいてキャッシュが実行可能であることを共有が示す場合（ファイルがキャッシュ可能な共有である、または、ＷｅｂＤＡＶの場合のように、キャッシュが常にオンであることをリダイレクタが示す場合）、ＣＳＣ機構２２１は、（その後処理において）このファイルオブジェクトを所有するかどうかを判定することができる。実行可能な場合、ＣＳＣ機構２２１は、所有権を主張し、このファイルオブジェクトによって表されるオープンインスタンス４１０〜４１２についてのファイルデータ構造を完成させる。共有がキャッシュ不可とマークされている場合、ＣＳＣ機構２２１は、ファイルオブジェクトからそれ自体を切り離し、任意のＣＳＣデータ構造をクリーンアップすることができ、その後このファイルオブジェクトに対する操作は表示されない。図５に、こうしたクライアント側キャッシュ使用不可動作モードの場合の残りのデータ構造の概略を示している。接続データ構造がキャッシュ不可なパスである場合でも、ＣＳＣ機構２２１は、ある程度の時間接続データ構造を維持する。それに対し、クライアント側キャッシュは使用可能であり、しかし接続がこのパスに関してオフラインである場合、図６に概略を示すように、物理的接続のデータ構造は存在しない。

サーバーは、（ロック機構などを介して）このファイルのファイル操作は、他に指示があるまで、例えばサーバーがロックのタイプを変更するまで、クライアント側キャッシュによって処理すべきであることを示すことができることに注意されたい。その後のファイルに対するＩ／Ｏ操作は、他に通知があるまで、例えば他のユーザーがファイルへのアクセスを要求しているため、サーバーがロック（便宜的ロック（ｏｐｐｏｒｔｕｎｉｓｔｉｃ ｌｏｃｋ）、すなわちｏｐｌｏｃｋ）のタイプを変更するまで、オフラインで実行される。

図７〜１３のフロー図に関連して本発明の動作の例を参照すると、図７は、図２のアーキテクチャの例における、ＭＵＰ２３０、ＣＳＣ、およびＤＦＳ代理プロパティ（それぞれ２２１および２２２）、およびリダイレクタ２２３〜２２５の間の概略的な制御フローを示している。ステップ７００で示し、上述したように、作成要求時、ＭＵＰ２３０は、第１の代理プロバイダ、この例ではＣＳＣ機構２２１を選択し、ステップ７０２によって前呼出し順序を論理的に追跡し、ステップ７０４で選択されたプロバイダの前処理ハンドラを呼び出す。作成要求に対するＣＳＣ前処理ハンドラ２２６操作について、図９との関連で以下で概説する。呼び出された代理プロバイダは、ステップ７０６で「さらに処理が必要」ステータスと検出されるのではなく、「成功」または「エラー」ステータスで要求を完了させない限り、ＭＵＰ２３０は、呼び出される代理プロバイダがなくなるまで、ステップ７０８および７１０（ステップ７０２に戻る）を経て他の代理プロバイダ、この例ではＤＦＳ代理プロバイダ２２２のみを呼び出す。ＣＳＣ機構２２１が（例えば接続状態データ２５０（図２）によって）接続がオフラインであることを検出する状況では、図４に示すようなデータ構造では、ＣＳＣ機構２２１は、ファイルＩ／Ｏ作成要求をオフラインで処理し、次いでさらに処理が必要以外のステータス、つまり成功またはエラーを戻し、その結果ネットワーク関連の構成要素にアクセスする必要がなくなる。

オンライン（未知の接続状態）状況では、代理プロバイダへの前処理呼出しの後、ステップ７０８は、リダイレクタの呼出しを表すステップ７１２に分岐する。ファイル作成／オープン要求時、上述したように、この作成のためのパスが前もって主張され、それによってＭＵＰ２３０がどのリダイレクタを呼び出すかをわかっていない限り、パスを主張するものを探し出すために複数のリダイレクタが呼び出されることに注意されたい。読取り操作または書込み操作に向けられるものを含めて、そのパスに関連するその後のＩ／Ｏ要求時、ＭＵＰ２３０は、そのパスを前もって主張した、またはそれを作成／オープン要求の一部として主張したリダイレクタ、この例ではＤＡＶリダイレクタ２２５を呼び出す。

図８は、前処理呼出し、およびリダイレクタの任意の呼出しに続く、ＭＵＰ２３０による代理プロバイダの後処理ハンドラの呼出しを表す。ステップ８００で、ＭＵＰ２３０は、前処理呼出し順序で最後に呼び出された代理プロバイダ、この（オンラインの）例ではＤＦＳ代理プロバイダ２２２を選択し、ステップ８０２でそれを呼び出す。ステップ８０４および８０６は、前処理呼出し順の逆の順序による他の代理プロバイダの後処理呼出しの繰返しを表す。この例では、呼び出されるべき残っている唯一の代理プロバイダがＣＳＣ機構２２１である。作成要求に対するＣＳＣ後処理ハンドラ２２７操作について、図１０に関連して以下で概説する。オフライン状況で、ＣＳＣ前処理ハンドラ２２６のみが呼び出された状態でステップ７０８はステップ７１２に分岐し、それによってステップ８０２は、ＣＳＣ後処理ハンドラ２２７を呼び出すが、ステップ８０４で呼び出すべき他の代理プロバイダがないと検出されることに注意されたい。

図９は、作成要求に応答してＭＵＰ２３０によって呼び出されたときのＣＳＣ前処理ハンドラ２２６の操作を表す。ステップ９００で開始し、ＣＳＣ前処理は、図４に関連して上述したように、論理構造４００を見つける、または作成する。ステップ９０２は、ファイルオブジェクト４１３に関連する共有構造４１０〜４１２（図４）の折りたたみまたは作成を表す。他のサーバーファイルと同様に、同じファイルに向けられる任意の作成／オープン要求は、ステップ９０４で表すように、例えばその後のオープン要求がサーバーに送信されることなくこのオープン要求上で折りたたまれるように、適切な順序で保持（同期）されることに注意されたい。ステップ９０６は、接続がオフラインであることがわかっているかどうかをテストする。このイベントでは、利用可能なＣＳＣストア２１５のみが存在し、ネットワークリソースを関与させる必要はなく、それによって前処理ハンドラがステップ９０８に分岐して、成功（またはエラー）を戻す。そうでない場合、前処理ハンドラは、ステップ９１０に分岐して「さらに処理が必要」ステータスを戻し、その結果ネットワーク関連の構成要素（ＤＦＳおよびリダイレクタ）に連絡し、上述したようにオンラインまたはオフライン状態が確立される。

オンラインまたはオフラインは、ファイルの作成／オープン要求の処理時にファイルごとに確立されることに注意されたい。オフライン接続は、後述するように、他の作成要求から既知である場合はＣＳＣ前処理で決定され、ＣＳＣ前処理中未知の場合は、リダイレクタが呼び出されたときに何が起こったかに基づいてＣＳＣ後処理で決定される。例えば、リダイレクタがパスを主張し、構造を作成し、ネットワークエラーを戻さなかった場合、オンライン接続が確立される。そうでない場合、オフラインが確立される。一実装形態では、ファイルの作成時に決定されたオフライン／オンラインのステータスは、その後のＩ／Ｏ要求中の実際の接続状態に関係なく（クローズし、再度オープンするまで）変わらない。したがって、後述するように、ネットワークはファイル作成／オープン時にはオンラインであったが、ファイルが開いている間にオフラインになった場合でさえ、ＭＵＰ２３０は、要求を引き続きそのパスのためのリダイレクタに渡す。バッファリングサービスおよび／またはクライアント側キャッシュのため、リダイレクタが実際に切断されたサーバーとの接続を要求されない限り、こうしたその後の要求の処理におけるエラーはない。あるいは、ネットワークはファイル作成／オープン時にはオフラインであったが、ファイルが開いている間にオンラインになった場合、クライアント側前処理はまるでオフラインであるかのように引き続き要求を処理するが、その理由の１つとしてＭＵＰ２３０がＤＦＳを関与させておらず、このファイルにはＭＵＰ２３０に知られているリダイレクタがないためである。

図１０は、オフラインの場合は前処理呼出しの直後、または接続状態が未知であった場合はリダイレクタ（および他の代理プロバイダ）が呼び出された後、作成要求に応答してＭＵＰ２３０によって呼び出されたときのＣＳＣ後処理ハンドラ２２７の操作を表す。図１０には示していないが、リダイレクタを（少なくとも１つ）関与させた後、このファイルのクライアント側キャッシュがサーバーによって使用不可にされている場合、ＣＳＣ機構２２１は本質的に、後処理によりそれ自体を以降のファイルに向けられる呼出しにおいて取り除く。

ステップ１０００で開始し、ＣＳＣ後処理ハンドラ２２７は、例えばＣＳＣストア２１５内のファイル用にローカルファイルシステムによって戻されたような、クライアント側キャッシュファイル用のハンドルを作成する。上述したように、ファイル構造の１つは、サーバー側オープンコンテキスト４１１（図４）を含み、ステップ１００２で、ＣＳＣ後処理ハンドラ２２７はハンドルをここに格納する、つまりＣＳＣ後処理ハンドラ２２７は、物理パスではなく論理パスを表すローカルキャッシュのハンドルを格納する。ステップ１００４で、構造は、例えば適切な構造に入れられる様々なデータなど、このファイル用に完成される。ステップ１００６は、（図９のステップ９０４で）保持されている他の作成のうちのいずれかをリリースすることを表す。

ＣＳＣ後処理２２７が呼び出されたとき、ＣＳＣ後処理ハンドラ２２７は、オフライン状況を示すリダイレクタ関連のエラーを探すことに注意されたい。これは、前処理ハンドラ２２６が接続がオンラインであるかオフラインであるかを知らなかった場合を扱う。このため、ＣＳＣ後処理２２７は、例えばデータ構造内で物理的接続情報を探す、および／または他の代理プロバイダまたはリダイレクタからの完了ステータスを探すことによって接続が現在オンラインであることがわかるかどうかを探すことができる。接続エラーがある場合、例えばどのリダイレクタもパスを主張しなかった場合、後処理ハンドラは、このファイルでは状態をオフラインに移行させ、つまりＣＳＣ後処理２２７は、データ構造で状態をオフラインに移行させ、その結果その後の要求は、後述するように、ＣＳＣ前処理ハンドラによって（リダイレクタの関与なしに）オフラインで完了する。言い換えれば、オフラインへの移行状況に続いて、その後のＩ／Ｏ要求はＣＳＣ代理プロバイダのプロセスハンドラ２２６によって完了され（かつＣＳＣはさらに処理が必要以外のステータスを戻し）、その結果ＭＵＰ２３０は、要求をリダイレクタに送信しない（任意のイベントではＭＵＰ２３０には知られていないことがある）。

ステップ１００８は、接続がオフラインであるかどうかのテストを表す。これは前もって知られていることも知られていないこともある。オフラインの場合、ステップ１０１０が実行される。ステップ１０１０は、オフラインへの移行を行うことを表す。これは、例えば存在し得る任意の物理的接続ベースのデータ構造をクリーンアップために必要となり得る。オンラインの場合、ステップ１０１２が実行される。ステップ１０１２は、パスを主張したリダイレクタではなく、ＣＳＣ機構２２１への参照でＦＣＢ４１０のディスパッチテーブル４１６を上書きすることを表す。

より詳細には、図１１〜１３に関連して後述するように、本発明のアーキテクチャでは、ＲＤＢＳＳ２３２およびリダイレクタがともに動作する方法に対するほんのわずかの変更によってプロトコル独立型クライアント側キャッシュを達成している。例えばＲＤＢＳＳ２３２およびリダイレクタ構成要素は実質的に、例えばリダイレクタはパスを主張し、ＲＤＢＳＳ２３２を呼び出して必要なデータがメモリにローカルにキャッシュされたかどうかを調べるなど、以前と同様に働く。また、ＲＤＢＳＳ２３２は本質的に、例えば要求通りに構造を作成し、キャッシュマネージャを呼び出して適切なときに書込みをキャッシュし、または読取り要求を満たすために要求されたデータをキャッシュするかどうかを調べ、キャッシュする場合はデータをもって戻るなど、以前と同様に動作する。しかし、後述するように、例えばＩ／Ｏ要求を満たすためにＲＤＢＳＳ２３２がファイルデータを必要とし、データがメモリ内ＲＡＭキャッシュ２４４にないときに、キャッシュマネージャ２４０／メモリマネージャ２４２は読取りＩＲＰを生成する。しかし、この読取りＩＲＰがＲＤＢＳＳ２３２に到達すると、データを取得するために制御をリダイレクタに渡すのではなく、ディスパッチテーブルエントリの上書きによってＲＤＢＳＳ２３２にＣＳＣ機構２２１を呼び出させ、したがってＣＳＣ機構２２１に、ＣＳＣストア２１５を使用してこの要求を満たす機会を与える。このように、ＣＳＣ機構２２１は、リダイレクタのネットワークプロトコルに関係なく、ＲＤＢＳＳ２３２とパスを主張したリダイレクタとの間の制御フローに透過的に関与する。

図１１〜図１３は、特にクライアント側キャッシュが許容されているときに、読取り要求をインターセプトするためにＣＳＣ機構２２１が透過的に挿入される方法について示している。簡潔にするために、図１１〜１３は、読取りキャッシュが許容されていないときを含めて他の動作状態を表していない。代わりにこの状態は、次のように表される。つまり、ＣＳＣストア２１５からの任意の読取りの前に、ＣＳＣ機構２２１は、ファイルのバッファ状態を知っている必要がある。というのは、読取りキャッシュが許容されていないようなバッファ状態（例えば一実装形態では、バッファ状態はＯＰＬＯＣＫ＿ＬＥＶＥＬ ＮＯＮＥの同等である）の場合、ＣＳＣ機構２２１は、ＣＳＣストア２１５からデータを戻さず、代わりに読取り要求を下にあるプロバイダに移動させるためである。一実装形態のバッファ状態情報は、ＦＣＢでＦＣＢ＿ＳＴＡＴＥ＿ＲＥＡＤＣＡＣＨＩＮＧ＿ＥＮＡＢＬＥＤフラグをチェックすることによって取得することができる。

ステップ１１００で、ＭＵＰ２３０がＩ／Ｏマネージャ２０６から要求、例えばＩＲＰを受信したときに全読取り要求処理が開始する。ステップ１１０２で、ＭＵＰ２３０は、ＣＳＣ前処理ハンドラ２２６を呼び出し、ステップ１１０４によるテストでオンラインとされると、その結果ステップ１１０６で「さらに処理が必要ステータス」が戻される。システムがオフラインである場合、ＣＳＣ前処理ハンドラ２２６は、図１１においてステップ１１０４がステップ１１１２へ分岐することで表すように、要求を処理することに注意されたい。

オンライン状態での読取り要求の場合、ステップ１１０６でＣＳＣ前処理ハンドラ２２６がさらに処理が必要ステータスを戻した場合、ステップ１１０８で、ＭＵＰ２３０がＤＦＳ前処理を呼び出して、例えばファイルＩ／Ｏ操作を記録するなど、そのＤＦＳ前処理操作のいずれかを行う。この呼出しの後、ステップ１１１０で、ＭＵＰ２３０は、この特定のファイルのために以前パスを主張したリダイレクタ（例えば符号２２５）を呼び出す。

ＣＳＣ前処理（オフライン）またはリダイレクタ（オンライン）が要求を有しているかどうかに関わらず、ステップ１１１２でＲＤＢＳＳ２３２が呼び出され、本質的に、例えば前の読取りまたは書込み要求のために、必要なデータがメモリ内ＲＡＭキャッシュ２４４にあるかどうかを判定する。データがメモリにローカルに存在していない場合（キャッシュミスが起こる）、後述するように、バッファリングサービス（キャッシュマネージャ２４０／メモリマネージャ２４２など）は、一般に別のエンティティにデータを取得させるために、ページングＩ／Ｏフラグが設定された状態で第２のＩＲＰを生成する。したがってＲＤＢＳＳ２３２は、例えばページングＩ／Ｏフラグ設定などによって、ＩＲＰがキャッシュミス状態によって生成されたかどうかをチェックする必要がある。そうである場合、見つからなかったときに再度ＩＲＰを発行することになる（本質的に無限ループとなる）ため、ＲＤＢＳＳ２３２は、以前行ったことを繰り返し、キャッシュマネージャを呼び出して同じデータをもう一度探してはならないことを意味するからである。代わりに、ＲＤＢＳＳ２３２はコールアウトして、データを他から取り出す必要がある。ステップ１１１４にこのテストを表している。ファイルは、バッファ付きＩ／Ｏを許可しないようにして開くことができることに注意されたい。このイベントでは、データは、同様にキャッシュされない。また、ステップ１１１４は、この状態を検出し、それに応じてステップ１１１８に分岐することができる。簡潔にするために、他に特記事項がある場合を除いて、この例は、バッファ付きＩ／Ｏとの関連で説明する。

この例では、この時点で、ＩＲＰがＩ／Ｏマネージャ２０６によって生成され、したがってステップ１１１４がステップ１１１６に分岐してキャッシュマネージャ２４０を呼び出す。キャッシュマネージャ２４０は、メモリマネージャ２４２と連動してメモリ内ＲＡＭキャッシュ２４４内で要求されたデータを探す。図１２のステップ１２００で表すように、キャッシュメモリ２４０／メモリマネージャ２４２はキャッシュヒットまたはキャッシュミスがあるかどうかについて決定を行い、データをバッファに入れ（ステップ１２０２）、キャッシュヒットではＲＤＢＳＳ２３２に成功を戻し（ステップ１２１２）、またはキャッシュミスでは、ステップ１２０４に表すように、第２のＩＲＰを生成する。第１のＩＲＰによるキャッシュヒットでは、ＲＤＢＳＳ２３２は、ステップ１２４０に表すように、また図１３に関連して後述するように、この（第１の）ＩＲＰを完了する。キャッシュミスでは、ステップ１２０４で第２のＩＲＰが生成され、第１のＩＲＰ同様、図１１のステップ１１００でＭＵＰ２３０で受信される。

図１１に戻って、ステップ１１００で第２のＩＲＰが受信されると、上述したように他のステップ（１１０２〜１１１２など）が実行され、最終的に、この場合もまたオフラインであるかオンラインであるかに関係なくステップ１１１４に到達する。ただし、このときのステップ１１１４は、読取りのためのこの（第２の）ＩＲＰのページングのＩ／Ｏフラグを検出する。

本発明の一態様によれば、上述したように、オンライン時、ファイル作成／オープン要求の場合のＣＳＣ後処理では、ＣＳＣ後処理ハンドラ２２７は、ステップ１１１８で表すように、ＲＤＢＳＳ２３２がこの状況でＤＡＶリダイレクタ２２５ではなくＣＳＣ機構２２１を呼び出すように、ファイル制御ブロック４１０（図４）のディスパッチテーブル４１６内のリダイレクタポインタを前もって上書きしている。このことによってＣＳＣ機構２２１は、まずＤＡＶリダイレクタ２２５がサーバーにデータを要求する代わりに、ＣＳＣストア２１５内で要求されたデータを探す機会を得る。これはＲＤＢＳＳ２３２には透過であり、単にファイル制御ブロックのディスパッチテーブル４１６内のポインタデータに基づいてＣＳＣ機構２２１が呼び出されることに注意されたい。このように、ＣＳＣ機構２２１は、本質的にリダイレクタから見ればＲＤＢＳＳ２３２への拡張のように動作し、さらにＲＤＢＳＳ２３２から見れば適切なリダイレクタとしても動作し、しかし本質的に両方から透過である。さらに、オフラインの場合、ＣＳＣ前処理ハンドラ２２６は、ＲＤＢＳＳ２３２を呼び出し（リダイレクタは関与していない）、したがってＲＤＢＳＳ２３２は、ステップ１１１８でＣＳＣ前処理ハンドラ２２６にコールバックする。したがって、オンラインの場合でも、オフラインの場合でも、ＣＳＣ機構２２１のコードが呼び出される。

このように、キャッシュミスでは、図１２のステップ１２２０が実行される。これは、ＣＳＣ機構２２１がそのＣＳＣストア２１５に要求されたデータがあるかどうかをチェックすることを表す。要求されたデータは、ファイルが疎でない限りそこに存在し、したがってステップ１２２０は、ファイルが疎であるかどうかに関するテストを含むことができる（あるいは疎である場合、ステップ１２２０は要求されたデータが偶然存在しているかどうかについてテストすることができる）ことに注意されたい。存在する場合、ＣＳＣ機構２２１はＲＤＢＳＳ２３２がロ―カルメモリから取得できなかったデータを取り出し、ステップ１２２２で、例えばＩＲＰに関連するバッファにデータを入れ、ステップ１２２２で表すように、ＲＤＢＳＳ２３２に成功ステータスを提供することなどによって呼出しに応答してデータを戻すので、ＣＳＣ機構２２１は、ＲＤＢＳＳ２３２から見るとリダイレクタのように働く。ＲＤＢＳＳ２３２は、ステップ１２４０で表すように、また図１３に関連して後述するように、この第２のＩＲＰを完了させる（イニシエータ（例えば後述するようにステップ１２０６でのキャッシュマネージャ２４０／メモリマネージャ２４２）に戻る）。

ステップ１２２０で、ＣＳＣ機構２２１が要求されたデータにアクセスできなかった場合、オンラインでは、ＣＳＣ機構２２１は、リダイレクタ（符号２２５など）にサーバーからデータを取得するよう要求することができる。しかし、ステップ１２２４でオフラインであると検出された場合、ステップ１２３４で、ＣＳＣ機構２２１は、ＲＤＢＳＳ２３２にエラー（例えばネットワークが切断されているなど）を戻す必要がある。これは、以前オンラインであったが切断された場合に任意のリダイレクタが戻すエラーに似ており、この場合もまたＣＳＣ機構２２１は、ＲＤＢＳＳ２３２から見るとリダイレクタをエミュレートすることに注意されたい。このためＣＳＣ機構２２１は、ステップ１２２６でまるでＲＤＢＳＳ２３２であったかのようにＤＡＶリダイレクタ２２５を呼び出す。次いでステップ１２２８で表すように、ＤＡＶリダイレクタ２２５は、適切なサーバーと通信して要求されたデータを取得しようと試みる。ステップ１２３０では、読取りが成功した場合、データはリダイレクタによってバッファ（ＩＲＰに関連するバッファ）に入れられ、リダイレクタは、成功をＣＳＣ機構２２１に戻し（まるでＣＳＣ機構２２１がＲＤＢＳＳ２３２であったかのように）、それによってＣＳＣ機構２２１は、ステップ１２３２でＣＳＣストアにデータをキャッシュし、成功ステータスをＲＤＢＳＳ２３２に提供してステップ１２４０でＩＲＰを完了する。読取りが成功しなかった場合、ＣＳＣ機構２２１がキャッシュすべきものはなく、したがってエラーステータスのみがリダイレクタによってＣＳＣ機構２２１に戻され、ＣＳＣ機構２２１からＲＤＢＳＳ２３２に戻される。

したがって、ステップ１２４０に従って、完了したＩＲＰ（完了が成功であろうと不成功であろうと、また第１のＩＲＰであろうと第２のＩＲＰであろうと）は、ドライバスタックを上方向に逆戻りし、ＭＵＰ２３０に到達する。しかし、ＩＲＰが移動するスタック順は、接続がオンラインであるかオフラインであるかに応じて異なる。この時点で、オフライン／オンラインの実際のテストはないが、ステップ１３００は、概念上、オフライン／オンラインに応じてＩＲＰがたどるスタックを通る２つの可能なパスを表す。例えば、オンラインの場合、ステップ１３０２および１３０８で表すように、ＩＲＰはＲＤＢＳＳ２３２からリダイレクタを経由してＭＵＰ２３０に移動する。リダイレクタが単にＩＲＰを通ってＭＵＰ２３０に移動することに注意されたい。

一方オフラインの場合、ＭＵＰは、ＣＳＣ前処理２２６のみを呼び出し、ＣＳＣ前処理がＲＤＢＳＳ２３２を呼び出している。したがってＩＲＰは、ステップ１３０４によって表すように、ＣＳＣ前処理２２６に戻される。次いでステップ１３０６および１３０８で表すように、ＣＳＣ前処理２２６は、ステータスは完了（またはエラー）をＭＵＰに戻す。このように、特に、ＭＵＰ２３０は、図７との関連で上述したように、リダイレクタを呼び出さない。

ステップ１３１０は、図７および図８に関連して上述したように、代理プロバイダの後処理の呼出しを開始するためのＭＵＰ２３０によるステータスのテストを表す。ステータスが成功（またはエラー）である場合、これは一般に図７のステップ７０６から図８への分岐に相当するが、図１３のこの例では、唯一の他の代理プロバイダがＤＦＳ代理プロバイダ２２２である。したがって、オンライン時、ＭＵＰ２３０は、ステップ１３１２でＤＦＳ代理プロバイダ２２２の後処理ハンドラを呼び出し、次いでステップ１３１４でＣＳＣ後処理ハンドラ２２７を呼び出し、ステップ１３１６で要求を完了させる。そうではなくオフライン時では、ＭＵＰは、ＣＳＣ後処理ハンドラ２２７のみを呼び出す。ＭＵＰは、ステップ１３１０でオンライン／オフラインを実際にテストする必要はないことに注意されたい。というのは、このテストは、後処理呼出しスタックに固有である、つまりコールバックするものがＣＳＣ後処理のみであるとき、本質的に図８のステップ８０６に対応することに注意されたい。

次いでＭＵＰ２３０は、ステップ１３１６で表すように要求を完了させる。しかし、ＩＲＰが戻されるところは、ＩＲＰがＩ／Ｏマネージャ２０６によって起動された第１のＩＲＰであるか、キャッシュミスによって起動された第２のＩＲＰであるかに依存する。ＩＲＰが第１のＩＲＰである場合は、Ｉ／Ｏマネージャ２０６に送信され、アプリケーションプログラムの読取り要求に応答してそこからデータが戻される。ＩＲＰがステップ１２０４で生成された第２のＩＲＰである場合、この第２のＩＲＰは、キャッシュマネージャ２４０／メモリマネージャ２４２、つまり、ステップ１２０６でそれを生成したエンティティに戻る。

ステップ１２０６は、第２のＩＲＰ（キャッシュミス状態）で作成された読取り要求が成功したかどうかのテストを表す。成功しなかった場合、エラーは、ステップ１２４０および図１３で関連して上述したように、アプリケーションプログラムからのＡＰＩ呼出しに応答して第１のＩＲＰでＩ／Ｏマネージャ２０６に戻される（ステップ１２０８）。読取りが成功であった場合、代わりにステップ１２１０が実行される。これは、キャッシュメモリ２４０／メモリマネージャ２４２がメモリ内ＲＡＭキャッシュ２４４を第２のＩＲＰ読取り要求によってバッファに入れられたデータで満たすことを表す。次いで、ステップ１２４０および図１３に関連して上述したように、データバッファがいっぱいになった状態で第１のＩＲＰがＩ／Ｏマネージャ２０６に（さらにそこからアプリケーションプログラムに）戻される。

このように、ＲＤＢＳＳ２３２およびリダイレクタは、それぞれから見ると読取り要求について以前と同じように動作し、さらにＣＳＣ機構２２１は、メモリ内キャッシュがデータを有していないときに読取り要求を満たすためにそれ自体を制御フローに透過的に挿入する。メモリ内ＲＡＭキャッシュ２４４がデータを有しているとき（キャッシュヒット）、ステップ１２１０で、データは第２のＩＲＰを介して最初にメモリ内ＲＡＭキャッシュ２４４に入り、したがってＣＳＣストア２１５から取得されているか、上述したようにステップ１２３２でＣＳＣ機構２２１によって（リダイレクタから）すでに格納されているため、ＣＳＣ機構２２１は、データをそのストア２１５に追加する必要がないことに注意されたい。したがってこのデータをＣＳＣストア２１５に再度コピーする必要はない。

クライアント側キャッシュが実行可能であるときの書込み要求について考えてみると、書込み要求は、キャッシュマネージャ２４０／メモリマネージャ２４２が最終的にメモリ内ＲＡＭキャッシュ２４４内のデータを変化させることを除いて、読取り要求とかなり似ている。変更されたメモリ内ＲＡＭキャッシュ２４４（例えばページごとに変更されたとみなされたかどうか）は、その変更された（ダーティになった）ページを、後述するように、様々な方法でＣＳＣストア２１５および／またはサーバーにフラッシュさせる。メモリ内ＲＡＭキャッシュ２４４内の書込み要求に関するデータを変更するために、変更するデータの各ページ（ページの一部分のみが変更される場合でも）は、メモリ内ＲＡＭキャッシュ２４４内にある必要がある。したがって、本明細書に記載した実装形態の例では、書込み要求についてのキャッシュミスでは、（例えばステップ１２０４の読取り要求の場合のように）第２のＩＲＰを生成することによってまず必要なデータがキャッシュに読み込まれる。

一般に、バッファ付きＩ／Ｏ（キャッシュマネージャ２４０を使用）の場合、書込みおよび読取りには図１１〜１３のフロー図が適用されるが、これらのページが最初にキャッシュマネージャ２４０にあったものであろうと、必要なページが上述した読取り用の第２のＩＲＰを介してキャッシュマネージャ２４０にフォルトされる（読み込まれる）必要があった場合であろうと、バッファをいっぱいにしてそれを戻す代わりに、書き込むべきデータのいっぱいになったバッファは、キャッシュマネージャ２４０内の適切なページを変更する。バッファなしＩ／Ｏの場合、ＲＤＢＳＳ２３２は、キャッシュマネージャ２４０を呼び出さなことを知っており（例えば作成時にＦＣＢにある情報に基づいて）、代わりに、オンライン時は例えばディスパッチテーブルを介してＣＳＣ機構２１１を呼び出し、またはオンライン時はＣＳＣ前処理に戻ることに注意されたい。したがって、バッファなしＩ／Ｏの書込みは本質的に、第１のＩＲＰで図１１のステップ１１１４を介してステップ１１１８に分岐し、これは第２のページングＩ／Ｏ ＩＲＰと類似している。

ＣＳＣ機構２２１が実際の書込み要求（単に対応する書込み要求に対してメモリ内ＲＡＭキャッシュ２４４を満たすためにキャッシュミス時に生成された読取り要求ではない）に関与している、例えばバッファなしＩ／Ｏなどの場合、またはキャッシュがフラッシュされるとき、書込み操作は、ライトスルーキャッシュ（ｗｒｉｔｅ−ｔｈｒｏｕｇｈ ｃａｃｈｅ）として働くＣＳＣ機構２２１によって処理され得る。一般に、ライトスルーキャッシュでは、データは最初にサーバーへの書込みが試行され、成功した場合、ＣＳＣ機構２２１は、コピーをその永続ストア２１５に書き込む。例えば、書込みキャッシュが使用不可である、またはファイルが疎である場合、ＣＳＣ機構２２１は、書込み要求を直接リダイレクタに送信し、要求がリダイレクタによって正常に完了した場合、次いでコピーをそのＣＳＣストア２１５に書き込むことによってＣＳＣ機構２２１によってデータを保存することができる。エラーがリダイレクタから戻された場合、ＣＳＣ機構２２１は、オフラインへの移行を試行し、成功した場合、オフラインで要求を完了する。

一代替では、ＣＳＣ機構２２１は代わりに、最初にサーバーに行くことなく書込みをキャッシュすることによって、ライトバックキャッシュ（ｗｒｉｔｅ−ｂａｃｋ ｃａｃｈｅ）として働くことができる。ライトバックキャッシュは、サーバーによって制御されることに注意されたい。つまり書込みキャッシュがサーバーによって許可されると、ＣＳＣ機構２２１は、ファイルハンドルが閉じるまで、またはファイルのｏｐｌｏｃｋ（ライトバックキャッシュ特権を許可）がサーバーによってブレークされるまで、書込みをキャッシュする。このため、書込みキャッシュが許容され、ファイルが疎でない場合、ＣＳＣ機構２２１は、要求されたデータをＣＳＣストア２１５に書き込み、成功（または不成功の場合はエラー）ステータスを呼出し元に戻す。ＣＳＣ機構２２１は、すべての書込みが実行される前に、ファイルのバッファ状態を決定することに注意されたい。バッファ状態がライトバックキャッシュを許容した場合、ＣＳＣ機構２２１は、上述したように、データをその永続キャッシュ２１５に書き込み、書込み状態（通常は成功）を戻す。しかし、書込みをキャッシュすべきではない、例えばサーバーがＯＰＬＯＣＫ＿ＬＥＶＥＬ＿ＩＩレベル以下でｏｐｌｏｃｋを設定しているようなバッファ状態の場合、上記で概説したように、ＣＳＣ機構２２１は、書込みをキャッシュせず、代わりに書込み要求を下にあるリダイレクタに移動させる。バッファ状態情報は、ＦＣＢのＦＣＢ＿ＳＴＡＴＥ＿ＷＲＩＴＥＣＡＣＨＩＮＧ＿ＥＮＡＢＬＥＤフラグをチェックすることによって取得することができる。

ファイルを閉じるとき、クローズ要求が、上述した一般的なやり方でＲＤＢＳＳ２３２を介してキャッシュマネージャ２４０に到達する。メモリ内ＲＡＭキャッシュ２４４中のデータをフラッシュする必要がある場合、例えば、メモリ内ＲＡＭキャッシュ２４４にこのクローズされたファイルについての少なくとも１つのダーティページがある場合、キャッシュマネージャ２４０／メモリは、少なくとも１つのページングＩ／Ｏ書込み要求（ＩＲＰまたはＩＲＰＳ）を生成し、それぞれは、上述したのと同じ一般的なやり方で、例えばＲＤＢＳＳ２３２が各書込みＩＲＰを受信したときにＲＤＢＳＳ２３２からの呼出しを介してＣＳＣ機構２１１に到達する。次いでＣＳＣ機構２１１は、このファイルのために受信された各ＩＲＰに基づいてＣＳＣストア２１５に書き込む。

サーバーにライトバックするために、一実装形態では、クローズ要求がＣＳＣ機構２１１に達すると、ＣＳＣ機構２１１は、このファイルに対する前の書込み要求からキャッシュされた任意のデータがあるかどうかをチェックする。データがあり、サーバーがオンラインの場合、ＣＳＣ機構２１１は、書込み要求を適切なリダイレクタに渡すことによって修正されたデータ（例えばダーティページ）を有するセクションをサーバーに送り返す。キャッシュされたデータがこのようにサーバーに押し戻された後、ＣＳＣ機構２１１はクローズ要求をリダイレクタに送信する。リダイレクタがクローズ要求を完了すると、ＣＳＣ前処理ハンドラ２２６は、サーバーからタイムスタンプを取得するために問合せを行い、それをキャッシュされたファイルに設定し、キャッシュファイルハンドルを閉じ、ＭＵＰ２３０に戻る。したがって書込みは、ファイルが閉じられるまでキャッシュすることができる。ファイルが閉じられた時点でファイルがこのように同期される。ファイルへのリモートハンドルがない場合、例えば、このファイルに関連する接続がオフラインであるとき、クローズ要求のみがローカルに実行されることに注意されたい。後で同期を実行することができる。

容易に理解できるように、既存のアプリケーションプログラムは、変更を加えることなく本発明で動作することができ、以前のようにファイルＩ／Ｏ要求を送信することができる。しかし、他のアプリケーションプログラムは、クライアント側キャッシュを認識し得る。このようなＣＳＣ認識アプリケーションは、例えばＣＳＣ関連ＡＰＩを使用してファイルのグループ分けを制御し、いくつかのファイルが常に確実にＣＳＣストア２１５に存在する（ピンされる）ようにし、同期周波数を制御し、他のＣＳＣの特徴にアクセスすることによってユーザー体験全体を向上させる。

さらに、一実装形態では、ＣＳＣ機構２２１は、可用性、コスト、速度などのネットワーク接続状態の特徴を認識し得る。理解できるように、クライアント側キャッシュ、同期、およびネットワーク接続の他の側面は、所与の時に現在のネットワーク接続の特徴によって制御することができる。

上記の詳細な説明から理解できるように、プロトコル独立型クライアント側キャッシュを透過的に提供する方法およびシステムが提供されている。この方法およびシステムは、既存のリダイレクタアーキテクチャに合い、オフライン時および／またはオンライン時に一貫性があるようにファイルへのアクセスを提供する。

本発明は、様々な変更および代替構成の余地があるが、その実施形態の例をいくつか図面に示しており、上記で詳述してきた。しかし、本発明を開示した特定の形態に限定する意図はなく、逆に、本発明は、すべての変更、代替構成、および本発明の趣旨および範囲内に含まれる均等物をカバーするものとすることを理解されたい。

本発明を組み込むことができるコンピュータシステムの例を表すブロック図である。 本発明の一態様に従ってクライアント側キャッシュの態様を実施する構成要素を表す概略ブロック図である。 本発明の一態様に従ってクライアント側キャッシュおよびサーバーへのリダイレクションを実施する構成要素を表す概略ブロック図である。 本発明の一態様に従って、クライアント側キャッシュがネットワークオンライン状態で実行可能なときに、クライアント側キャッシュを実施するデータ構造を表す概略ブロック図である。 本発明の一態様に従って、クライアント側キャッシュが使用不可であるときに、ネットワークを介してネットワークファイル関連要求を処理するデータ構造を表す概略ブロック図である。 本発明の一態様に従って、ネットワークオフライン状態で動作しているときにクライアント側キャッシュを実施するデータ構造を表す概略ブロック図である。 本発明の一態様に従って、前処理呼出しで、クライアント側キャッシュ機構（代理プロバイダ）を含む、登録されている代理プロバイダを呼び出すロジックの例を表す概略フロー図である。 本発明の一態様に従って、後処理呼出しで、クライアント側キャッシュ代理プロバイダを含む、登録されている代理プロバイダを呼び出すロジックの例を表す概略フロー図である。 本発明の一態様に従って、クライアント側キャッシュ機構の前処理ハンドラで作成呼出しを処理するロジックの例を表す概略フロー図である。 本発明の一態様に従って、クライアント側キャッシュ代理プロバイダ後処理ハンドラで作成呼出しを処理するロジックの例を表す概略フロー図である。 本発明の一態様に従って、読取り要求を処理するロジックの例を表す概略フロー図である。 本発明の一態様に従って、読取り要求を処理するロジックの例を表す概略フロー図である。 本発明の一態様に従って、読取り要求を処理するロジックの例を表す概略フロー図である。

符号の説明

１００ コンピューティングシステム環境
１１０ コンピュータ
１２０ 処理ユニット
１２１ システムバス
１３０ システムメモリ
１３１ 読取専用メモリ（ＲＯＭ）
１３２ ランダムアクセスメモリ（ＲＡＭ）
１３３ ＢＩＯＳ
１３４ オペレーティングシステム
１３５ ファイルシステム
１３６ アプリケーションプログラム
１３７ 他のプログラムモジュール
１３８ プログラムデータ
１４０ インターフェイス
１４１ ハードディスクドライブ
１４４ オペレーティングシステム
１４５ アプリケーションプログラム
１４６ 他のプログラムモジュール
１４７ プログラムデータ
１５０ インターフェイス
１５１ 磁気ディスクドライブ
１５２ リムーバブル不揮発性磁気ディスク
１５５ 光ディスクドライブ
１５６ リムーバブル不揮発性光ディスク
１６０ ユーザー入力インターフェイス
１６１ ポインティング装置
１６２ キーボード
１６３ マイクロフォン
１６４ タブレット（電子デジタイザ）
１７０ ネットワークインターフェイスまたはアダプタ
１７１ ローカルエリアネットワーク（ＬＡＮ）
１７２ モデム
１７３ 広域エリアネットワーク（ＷＡＮ）
１８０ リモートコンピュータ
１８１ メモリ記憶装置
１８５ リモートアプリケーションプログラム
１９０ ビデオインターフェイス
１９１ モニタ
１９４ 出力周辺インターフェイス
１９５ スピーカー
１９６ プリンタ
２００ アーキテクチャ
２０２ ユーザーモードアプリケーションプログラム
２０４ アプリケーションプログラミングインターフェイス（ＡＰＩ）層
２０６ Ｉ／Ｏマネージャ
２１０ ＤＦＳネットワークプロバイダ
２１１ ＳＭＢネットワークプロバイダ
２１２ ＮＦＳネットワークプロバイダ
２１３ ＤＡＶネットワークプロバイダ
２１５ ＣＳＣストア
２１６ ＭＰＲ
２１８ ＤＦＳ代理プロバイダ
２２１ クライアント側キャッシュ（ＣＳＣ）機構
２２２ ＤＦＳ代理プロバイダ
２２３ ＳＭＢリダイレクタ
２２４ ＮＦＳリダイレクタ
２２５ ＤＡＶリダイレクタ
２２６ 前処理ハンドラ
２２７ 後処理ハンドラ
２３０ ＭＵＰ
２３２ リダイレクトされたバッファシステム
２４０ キャッシュマネージャ
２４２ メモリマネージャ
２４４ メモリ内ＲＡＭキャッシュ
２５０ 接続状態
３０１ ネットワークトランスポート層
３１１ ＳＭＢサーバー
３１２ ＤＡＶサーバー
３１３ ＮＦＳサーバー
４００ 論理接続ベースのデータ構造
４０１ サーバー呼出しコンテキスト
４０２ ネットルート構造
４０３ ネットルート構造のビュー
４１０ ファイル制御ブロック
４１１ サーバー側オープンコンテキスト
４１２ ファイルオブジェクト拡張
４１３ ファイルオブジェクト
４１６ ディスパッチテーブル
４２０ 物理接続ベースのデータ構造

Claims (80)

1. コンピューティング環境において、
   サーバー上でネットワークファイルを作成する、または開くことに向けられる、アプリケーションプログラムから開始されるＩ／Ｏ要求を受信すること、
   論理名前空間による前記ネットワークファイルのコピーへのパスを主張するクライアント側キャッシュ前処理を呼び出すこと、
   物理名前空間による前記ネットワークファイルのコピーへのパスを主張し、リダイレクタによって呼び出されたときにバッファリングサービスが前記リダイレクタにコールバックできるように前記ネットワークファイルに関連するリダイレクタ情報を提供するリダイレクタを呼び出すこと、および
   前記リダイレクタによって呼び出されたとき前記バッファリングサービスが前記クライアント側キャッシュ機構にコールバックするように前記ネットワークファイルに関連する前記リダイレクタ情報を変更することを含めて、物理名前空間による前記パスを主張した前記リダイレクタと前記バッファリングサービスの間の通信フローにクライアント側キャッシュ機構を挿入するクライアント側キャッシュ後処理を呼び出すこと
   を含むことを特徴とする方法。
2. 前記クライアント側キャッシュ前処理は、論理名前空間による前記ネットワークファイルの前記コピーに関連する複数のデータ構造を作成することを特徴とする請求項１に記載の方法。
3. 前記クライアント側キャッシュ前処理は、前記ネットワークファイルを表すファイルオブジェクトに関連する複数の共有データ構造を作成することを特徴とする請求項１に記載の方法。
4. 前記共有データ構造の１つは、ファイル制御ブロックを備え、前記ネットワークファイルに関連する前記リダイレクタ情報は、前記クライアント側キャッシュ機構へのポインタを備えるために、前記ファイル制御ブロックで維持され、前記クライアント側キャッシュ後処理によって前記ファイル制御ブロックで変更されるポインタを備えることを特徴とする請求項１に記載の方法。
5. 前記リダイレクタは、前記サーバー上の前記ネットワークファイルに関連する複数のデータ構造を作成することを特徴とする請求項１に記載の方法。
6. 前記リダイレクタ情報を変更する前の前記ネットワークファイルに関連する前記リダイレクタ情報を保存して、その結果前記クライアント側キャッシュ機構が前記リダイレクタを呼び出すことができるようにすることをさらに含むことを特徴とする請求項１に記載の方法。
7. 前記ネットワークファイルからのデータの読取りに向けられるＩ／Ｏ読取り要求を受信すること、前記Ｉ／Ｏ読取り要求を前記リダイレクタに提供すること、およびメモリキャッシュ内で前記要求されたデータを探すキャッシュ／メモリ管理構成要素を含み、データが見つかった場合は前記読取り要求を完了し、見つからなかった場合は前記クライアント側キャッシュ機構を呼び出す前記バッファリングサービスを前記リダイレクタから呼び出すことをさらに含むことを特徴とする請求項１に記載の方法。
8. 前記クライアント側キャッシュ機構を介して前記要求されたデータを取得すること、および前記クライアント側キャッシュ機構から前記要求されたデータを前記バッファリングサービスに提供することをさらに含むことを特徴とする請求項７に記載の方法。
9. 前記クライアント側キャッシュ機構は、クライアント側永続ストア内で前記要求されたデータをシークし、見つからなかった場合は、前記サーバーに前記要求されたデータを要求するためにリダイレクタを呼び出すことを特徴とする請求項７に記載の方法。
10. リダイレクタは前記データを見つけ、前記クライアント側キャッシュは、前記バッファリングサービスの前記クライアントサービス機構の呼出しに応答してデータを前記バッファリングサービスに戻すことを特徴とする請求項９に記載の方法。
11. 前記読取り要求を前記リダイレクタに提供する前に前記クライアント側キャッシュ前処理を呼び出すことをさらに含むことを特徴とする請求項７に記載の方法。
12. 前記クライアント側キャッシュ機構を呼び出すことは、前記バッファリングサービスは前記要求されたデータを前記メモリキャッシュからシークする必要はないことを示す情報を含む第２の読取り要求を発行することを含むことを特徴とする請求項７に記載の方法。
13. 前記バッファリングサービスの前記キャッシュ／メモリ管理構成要素は、前記第２読取り要求を発行し、前記バッファリングサービスは前記メモリキャッシュから前記要求されたデータをシークする必要はないことを示す前記情報は、前記第２の読取り要求に関連するフラグを含むことを特徴とする請求項１２に記載の方法。
14. 前記クライアント側キャッシュ機構を呼び出すことは、前記バッファリングサービスで前記第２の読取り要求を受信すること、前記バッファリングサービスは前記メモリキャッシュから前記要求されたデータをシークする必要がないという前記情報から認識すること、および前記クライアント側キャッシュ後処理によって変更された前記ネットワークファイルに関連する前記情報に基づいて前記クライアント側キャッシュ機構を呼び出すことをさらに含むことを特徴とする請求項１２に記載の方法。
15. 前記クライアント側キャッシュ機構を介して前記要求されたデータを取得すること、および前記クライアント側キャッシュ機構から前記要求されたデータを前記バッファリングサービスに提供し、前記バッファリングサービスは前記第２の要求を完了することをさらに含むことを特徴とする請求項１２に記載の方法。
16. 前記第２の要求を完了することは、前記戻されたデータに基づいて前記第１の要求を完了する前記キャッシュ／メモリ管理構成要素にデータを戻すことを含むことを特徴とする請求項１５に記載の方法。
17. 前記キャッシュ／メモリ管理構成要素は、前記第２の要求から取得された前記要求されたデータを前記メモリキャッシュにさらに追加することを特徴とする請求項１６に記載の方法。
18. 前記ネットワークファイルへのデータの書込みに向けられる第１のＩ／Ｏ読取り要求を受信すること、前記書込み要求を前記リダイレクタに提供すること、およびメモリキャッシュ内に上書きすべき前記要求されたデータを探すキャッシュ／メモリ管理構成要素を含み、データが見つかった場合は前記書込み要求を完了し、見つからなかった場合は前記クライアント側キャッシュ機構を呼び出す前記バッファリングサービスを前記リダイレクタから呼び出すことをさらに含むことを特徴とする請求項１に記載の方法。
19. 前記クライアント側キャッシュ機構を介して上書きすべき前記要求されたデータを取得すること、および前記クライアント側キャッシュ機構から前記要求されたデータを前記バッファリングサービスに提供することをさらに含むことを特徴とする請求項１８に記載の方法。
20. 前記クライアント側キャッシュ機構は、クライアント側永続ストア内で前記要求されたデータをシークし、見つからなかった場合は、前記サーバーに前記要求されたデータを要求するためにリダイレクタを呼び出すことを特徴とする請求項１８に記載の方法。
21. リダイレクタは前記データを見つけ、前記クライアント側キャッシュは、前記バッファリングサービスの前記クライアントサービス機構の呼出しに応答してデータを前記バッファリングサービスに戻すことを特徴とする請求項２０に記載の方法。
22. 前記書込み要求を前記リダイレクタに提供する前に前記クライアント側キャッシュ前処理を呼び出すことをさらに含むことを特徴とする請求項１８に記載の方法。
23. 前記クライアント側キャッシュ機構を呼び出すことは、前記バッファリングサービスは前記要求されたデータを前記メモリキャッシュからシークする必要はないことを示す情報を含む、読取り要求に相当する第２の要求を発行することを含むことを特徴とする請求項１８に記載の方法。
24. 前記バッファリングサービスの前記キャッシュ／メモリ管理構成要素は、前記第２の要求を発行し、前記バッファリングサービスは前記メモリキャッシュから前記要求されたデータをシークする必要はないことを示す前記情報は、前記第２の要求に関連するフラグを含むことを特徴とする請求項２３に記載の方法。
25. 前記クライアント側キャッシュ機構を呼び出すことは、前記バッファリングサービスで前記第２の要求を受信すること、前記バッファリングサービスは前記メモリキャッシュから前記要求されたデータをシークする必要がないことを前記情報から認識すること、および前記クライアント側キャッシュ後処理によって変更された前記ネットワークファイルに関連する前記情報に基づいて前記クライアント側キャッシュ機構を呼び出すことをさらに含むことを特徴とする請求項２３に記載の方法。
26. 前記クライアント側キャッシュ機構を介して前記要求されたデータを取得すること、および前記クライアント側キャッシュ機構から前記要求されたデータを前記バッファリングサービスに提供し、前記バッファリングサービスは前記第２の要求を完了することをさらに含むことを特徴とする請求項２３に記載の方法。
27. 前記第２の要求を完了することは、前記戻されたデータに基づいて前記第１の要求を完了する前記キャッシュ／メモリ管理構成要素にデータを戻すことを含むことを特徴とする請求項２６に記載の方法。
28. 前記キャッシュ／メモリ管理構成要素は、前記第２の要求から取得された要求されたデータを前記メモリキャッシュに書き込むこと、および前記書込み要求に基づいて前記要求されたデータを変更することを含めて、前記第１の要求を完了させることを特徴とする請求項２７に記載の方法。
29. クローズ要求を受信することをさらに含むことを特徴とする請求項１８に記載の方法。
30. 前記クローズ要求に応答して、クライアント側永続ストア内の対応するデータに関連して変更される前記メモリキャッシュ内の任意のデータを前記クライアント側キャッシュ機構にフラッシュして、前記クライアント側永続ストアに書き込むことをさらに含むことを特徴とする請求項２９に記載の方法。
31. 前記任意のデータをフラッシュすることは書込み要求を発行することを含むことを特徴とする請求項３０に記載の方法。
32. 前記クライアント側永続ストア内の前記ネットワークファイルに対応するファイルのコピーを閉じることをさらに含むことを特徴とする請求項２９に記載の方法。
33. 前記クローズ要求に応答して、前記ネットワークファイルの対応するデータに関連して変更される前記クライアント側永続ストア内の任意のデ―タを前記サーバーにフラッシュして前記ネットワークファイルに書き込むために前記リダイレクタを呼び出すことをさらに含むことを特徴とする請求項２９に記載の方法。
34. 請求項１に記載の方法を実行するコンピュータ実行可能命令を有することを特徴とするコンピュータ可読媒体。
35. コンピュータシステムにおいて、
    ネットワークファイルのデータに対応するＩ／Ｏ要求を受信すること、
    前記コンピュータシステムがネットワークに接続されているかどうかを決定するクライアント側キャッシュ前処理を呼び出し、コンピュータシステムが接続されている場合は前記要求を満たすためにさらに処理が必要であることを示すステータス値を戻すこと、および
    前記ステータス値を評価し、ステータス値がさらに処理が必要であることを示す場合、
    ａ）前記ネットワークファイルを含むサーバーに関連するリダイレクタを呼び出すこと、
    ｂ）バッファリングサービスを呼び出して前記要求を前記コンピュータシステム上のメモリバッファ内で処理することができるかどうかを決定すること、
    ｃ）前記バッファリングサービスで前記要求に対応するファイルデータが前記コンピュータシステム上のメモリキャッシュにバッファされるかどうかを決定すること、
    １）バッファに入れられる場合、前記バッファリングサービスで前記Ｉ／Ｏ要求を完了すること、
    ２）バッファに入れられない場合、前記要求に対応するデータがクライアント側キャッシュストア内に存在するかどうかを決定するクライアント側キャッシュ機構を呼び出し、データが存在する場合は、
    前記クライアント側キャッシュストアから前記要求に対応するデータを取得し、データが存在しない場合は、前記サーバーを介して前記要求を処理するよう前記リダイレクタに要求すること
    を含むことを特徴とする方法。
36. 前記Ｉ／Ｏ要求を受信することは、読取り要求を受信することを含むことを特徴とする請求項３５に記載の方法。
37. 前記Ｉ／Ｏ要求を受信することは、書込み要求を受信することを含むことを特徴とする請求項３５に記載の方法。
38. 前記クライアント側キャッシュ前処理は、前記コンピュータシステムはネットワークに接続されていると判断し、前記Ｉ／Ｏ要求を受信することは、読取り要求を受信することを含み、前記バッファリングサービスは、前記要求されたデータが前記コンピュータシステム上の前記メモリキャッシュにバッファされることを決定し、前記読取り要求を完了し、前記読取り要求に応答してバッファを前記メモリキャッシュからのデータで満たすことを含めて前記データにアクセスできるようにすることをさらに含むことを特徴とする請求項３５に記載の方法。
39. 前記クライアント側キャッシュ前処理は、前記コンピュータシステムはネットワークに接続されていると判断し、前記Ｉ／Ｏ要求を受信することは、読取り要求を受信することを含み、前記バッファリングサービスは、前記要求されたデータが前記コンピュータシステム上の前記メモリキャッシュにバッファされないことを決定し、前記クライアント側キャッシュ機構を呼び出し、前記クライアント側キャッシュ機構は、前記クライアント側キャッシュストアから前記要求に対応する前記データを取得し、データを前記バッファリングサービスに戻すことを特徴とする請求項３５に記載の方法。
40. 前記クライアント側キャッシュ機構は第２の読取り要求を生成することを含むことを特徴とする請求項３５に記載の方法。
41. 前記第２の読取り要求は、前記バッファリングサービスのキャッシュ／メモリ管理構成要素によって生成され、前記バッファリングサービスのリダイレクトされたバッファサブシステムによって受信され、前記クライアント側キャッシュ機構を呼び出すことは、前記第２の要求を処理するために前記バッファサブシステムから前記クライアント側キャッシュ機構を呼び出すことをさらに含むことを特徴とする請求項４０に記載の方法。
42. 前記リダイレクトされたバッファサブシステムから前記クライアント側キャッシュ機構を呼び出すことは、前記ネットワークファイルに関連するディスパッチテーブル内のポインタを読み取ることを含むことを特徴とする請求項４１に記載の方法。
43. 前記クライアント側キャッシュ機構は、実行されると前記クライアント側キャッシュ機構を呼び出すように前記ディスパッチテーブル内の前記ポインタを上書きするコードを含むことを特徴とする請求項４２に記載の方法。
44. 前記クライアント側キャッシュ前処理は、前記コンピュータシステムはネットワークに接続されていると判断し、前記Ｉ／Ｏ要求を受信することは、書込み要求を受信することを含み、前記バッファリングサービスは、前記要求されたデータが前記コンピュータシステム上の前記メモリキャッシュにバッファされることを決定し、前記メモリキャッシュにデータを書き込むことを含めて前記書込み要求を完了することを特徴とする請求項３５に記載の方法。
45. 前記クライアント側キャッシュ前処理は、前記コンピュータシステムは前記ネットワークに接続されていると判断し、前記Ｉ／Ｏ要求を受信することは、書込み要求を受信することを含み、前記バッファリングサービスは、前記要求されたデータが前記コンピュータシステム上の前記メモリキャッシュにバッファされないことを決定し、前記クライアントキャッシュ機構を呼び出し、前記クライアント側キャッシュ機構は、前記クライアントキャッシュストアから前記要求に対応する前記データを取得し、前記対応するデータを戻し、前記バッファリングサービスは、前記クライアント側キャッシュ機構から、および前記書込み要求に関連する書込みデータからデータを前記メモリキャッシュに書き込むことによって前記要求を完了することを特徴とする請求項３５に記載の方法。
46. 前記クライアント側キャッシュ機構を呼び出すことは読取り要求を生成することを含むことを特徴とする請求項３５に記載の方法。
47. 前記読取り要求は、前記バッファリングサービスのキャッシュ／メモリ管理構成要素によって生成され、前記バッファリングサービスのリダイレクトされたバッファサブシステムによって受信され、前記クライアント側キャッシュ機構を呼び出すことは、前記バッファサブシステムから前記クライアント側キャッシュ機構を呼び出すことをさらに含むことを特徴とする請求項４６に記載の方法。
48. 前記リダイレクトされたバッファサブシステムから前記クライアント側キャッシュ機構を呼び出すことは、前記ネットワークファイルに関連するディスパッチテーブル内のポインタを読み取ることを含むことを特徴とする請求項４７に記載の方法。
49. 前記クライアント側キャッシュ機構は、実行されると前記クライアント側キャッシュ機構を呼び出すように前記ディスパッチテーブル内の前記ポインタを上書きするコードを含むことを特徴とする請求項４８に記載の方法。
50. 前記バッファリングサービスが前記リダイレクタの代わりに前記クライアント側キャッシュ機構を呼び出すように、前記ネットワークファイルに関連するデータ構造内のリダイレクタ情報を上書きすることをさらに含むことを特徴とする請求項３５に記載の方法。
51. 前記クライアント側キャッシュ前処理は、前記コンピュータシステムがネットワークに接続されていないと判断し、前記要求に対応するデータはメモリキャッシュ内に存在するかどうかを決定し、データが存在する場合は、前記メモリキャッシュ内の前記対応するデータを介して前記要求を処理することをさらに含むことを特徴とする請求項３５に記載の方法。
52. 前記クライアント側キャッシュ前処理は、前記コンピュータシステムがネットワークに接続されていないと判断し、前記要求されたデータに対応するデータはクライアント側キャッシュ永続ストア内に存在するかどうかを決定し、データが存在する場合は、前記クライアント側キャッシュ永続ストア内の前記対応するデータを介して前記要求を処理することをさらに含むことを特徴とする請求項３５に記載の方法。
53. 前記クライアント側キャッシュ前処理は、前記コンピュータシステムがネットワークに接続されていないと判断し、前記要求に対応するデータはメモリキャッシュ内に存在するかどうかを決定し、データが存在しない場合は、前記クライアント側キャッシュ機構を呼び出して前記要求に対応するデータが前記クライアント側キャッシュ永続ストア内に存在するかどうかを決定することをさらに含むことを特徴とする請求項３５に記載の方法。
54. 請求項３５に記載の方法を実行するコンピュータ実行可能命令を有することを特徴とするコンピュータ可読媒体。
55. コンピューティング環境において
    別のリダイレクタのプロトコルに対してそれぞれ別個のプロトコルに対応する複数のリダイレクタと、
    前記リダイレクタのそれぞれと通信するように接続されている、ネットワークファイルのファイルデータをバッファに入れるバッファリングサービスと、
    クライアント側キャッシュ前処理ハンドラおよびクライアント側キャッシュ後処理ハンドラを含むクライアント側キャッシュ機構と、
    ネットワークファイルに向けられた作成要求を受信し、それに応答して前記クライアント側キャッシュ前処理ハンドラ、前記複数のうちの少なくとも１つのリダイレクタ、および前記クライアント側キャッシュ後処理ハンドラを呼び出す多重プロバイダと
    を備えることを特徴とするシステム。
56. 前記クライアント側キャッシュ前処理ハンドラは、データ構造を論理名前空間による前記ネットワークファイルのコピーに関連付け、前記クライアント側キャッシュ後処理ハンドラは、前記ネットワークファイルに関して前記ネットワーク接続ステータスがオフラインであることを決定し、前記オフラインのネットワーク接続ステータスに基づいて前記データ構造を構成することを特徴とする請求項５５に記載のシステム。
57. 前記多重プロバイダは、前記ネットワークファイルに向けられるその後のＩ／Ｏ要求を受信し、前記データ構造から前記ネットワーク接続ステータスがオフラインであると判断する前記クライアント側キャッシュ前処理ハンドラを呼び出し、前記その後のＩ／Ｏ要求をローカルに満たそうと試みることを特徴とする請求項５６に記載のシステム。
58. 前記クライアント側キャッシュ前処理ハンドラは、前記その後のＩ／Ｏ要求を前記バッファリングサービスに提供することによって前記その後のＩ／Ｏ要求をローカルに満たそうと試みることを特徴とする請求項５７に記載のシステム。
59. 前記バッファリングサービスは、リダイレクトされたバッファサブシステムおよびメモリキャッシュを管理するキャッシュ／メモリマネージャ構成要素を備え、前記キャッシュ／メモリマネージャ構成要素は、前記その後のＩ／Ｏ要求に対応するデータが前記メモリキャッシュに存在するかどうかを決定し、その結果前記バッファリングサービスが前記その後のＩ／Ｏ要求を完了することができることを特徴とする請求項５８に記載のシステム。
60. 前記バッファリングサービスは、前記その後のＩ／Ｏ要求を直接満たすことができず、前記クライアント側キャッシュ機構を呼び出して前記その後のＩ／Ｏ要求に対応するデータが前記クライアント側キャッシュ機構に関連するオフラインストアに存在するかどうかを決定し、その結果前記クライアント側キャッシュ機構は前記データを提供して前記その後のＩ／Ｏ要求を完了することができることを特徴とする請求項５８に記載のシステム。
61. 前記バッファリングサービスは、リダイレクトされたバッファサブシステムおよびメモリキャッシュを管理するキャッシュ／メモリマネージャ構成要素を備え、前記キャッシュ／メモリマネージャ要素は、前記その後のＩ／Ｏ要求に対応するデータが前記メモリキャッシュに存在しないかどうかを決定し、ページングＩ／Ｏ読取り要求を発行することによって前記クライアント側キャッシュ機構を呼び出すことを特徴とする請求項６０に記載のシステム。
62. 前記リダイレクタされたバッファサブシステムは、前記ページングＩ／Ｏ要求を受信し、それに応答して前記ネットワークファイルに関連するディスパッチテーブル内のポインタに基づいてルーチンを呼び出すことを特徴とする請求項６０に記載のシステム。
63. 前記ディスパッチテーブル内の前記ポインタは、前記クライアント側キャッシュ機構のルーチンを示すことを特徴とする請求項６２に記載のシステム。
64. コンピューティング環境において
    サーバー上でネットワークファイルを作成する、または開くことに向けられる、アプリケーションプログラムから開始されるＩ／Ｏ要求を受信すること、
    論理名前空間による前記ネットワークファイルのコピーへのパスを主張し、データ構造および前記ネットワークファイルの前記コピーに対応するファイルベースのデータ構造に基づいて論理接続を作成または検索するクライアント側キャッシュ前処理を呼び出すこと、および
    ａ）クライアント側キャッシュ前処理によって接続がオフラインであることがわかっている場合、前記クライアント側キャッシュ前処理は、リダイレクタを呼び出すことなくクライアント側キャッシュ後処理が呼び出されるステータスを戻し、前記クライアント側キャッシュ後処理は、前記クライアント側キャッシュ後処理において前記その後のＩ／Ｏ要求がオフラインで処理されるように前記データ構造を準備すること、
    ｂ）接続がオフラインであることがわかっていない場合、
    １）少なくとも１つのリダイレクタが呼び出されるステータスを戻すこと、
    ２）少なくとも１つのリダイレクタを呼び出すこと、
    ｉ）リダイレクタが物理名前空間による前記ネットワークファイルのコピーへの前記パスを主張しない場合、前記クライアントキャッシュ後処理においてその後のＩ／Ｏ要求が処理されるように前記データ構造を準備する前記クライアント側キャッシュ後処理を呼び出すこと、
    ｉｉ）対応するリダイレクタが物理名前空間による前記ネットワークファイルへのコピーへのパスを主張する場合、前記リダイレクタは、前記リダイレクタによって呼び出されたときにバッファリングサービスが前記リダイレクタをコールバックできるように前記ネットワークファイルに関連するリダイレクタ情報を提供し、前記クライアント側キャッシュ後処理を呼び出し、前記クライアント側キャッシュ後処理は、前記リダイレクタによって呼び出されたとき前記バッファリングサービスが前記クライアント側キャッシュ機構にコールバックするように、前記ネットワークファイルに関連する前記リダイレクタ情報を変更することを含めて、前記パスを主張した対応する前記リダイレクタと前記バッファリングサービスとの間の通信フローにクライアント側キャッシュ機構を挿入すること
    を含むことを特徴とする方法。
65. 前記接続はオンラインであり、前記ネットワークファイルのデータに向けられるＩ／Ｏ要求を受信すること、前記Ｉ／Ｏ要求を前記リダイレクタに提供すること、およびメモリキャッシュ内で前記要求されたデータを探すキャッシュ／メモリ管理構成要素を含み、データが見つかった場合は前記要求を完了し、見つからなかった場合は前記クライアント側キャッシュ機構を呼び出す前記バッファリングサービスを前記リダイレクタから呼び出すことをさらに含むことを特徴とする請求項６４に記載の方法。
66. 前記クライアント側キャッシュ機構を介して前記要求されたデータを取得すること、および前記クライアント側キャッシュ機構から前記要求されたデータを前記バッファリングサービスに提供することをさらに含むことを特徴とする請求項６５に記載の方法。
67. 前記クライアント側キャッシュ機構は、クライアント側永続ストア内で前記要求されたデータをシークし、見つからなかった場合は、前記サーバーに前記要求されたデータを要求するために前記リダイレクタを呼び出すことを特徴とする請求項６５に記載の方法。
68. 前記リダイレクタは前記データを見つけ、前記クライアント側キャッシュは、前記バッファリングサービスの前記クライアントサービス機構の呼出しに応答してデータを前記バッファリングサービスに戻すことを特徴とする請求項６７に記載の方法。
69. 前記バッファリングサービスは、前記キャッシュ／メモリ管理構成要素によって生成される第２の要求を介して前記クライアント側キャッシュ機構を呼び出すことを特徴とする請求項６５に記載の方法。
70. 前記バッファリングサービスは、前記第２の要求を受信し、前記ネットワークファイルに関連するディスパッチテーブル内の情報を介して前記クライアント側キャッシュ機構を呼び出すことによって前記クライアント側キャッシュ機構を呼び出すことを特徴とする請求項６９に記載の方法。
71. 前記接続はオフラインであり、前記ネットワークファイルのデータに向けられるＩ／Ｏ要求を受信すること、前記Ｉ／Ｏ要求を前記クライアント側キャッシュ前処理に提供すること、前記クライアント側キャッシュ前処理からメモリキャッシュ内で前記要求されたデータを探すキャッシュ／メモリ管理構成要素を含む前記バッファリングサービスを呼び出すこと、およびデータが見つかった場合、前記バッファリングサービスは前記要求を完了し、データが見つからなかった場合、前記バッファリングサービスは前記クライアント側キャッシュ機構を呼び出すことをさらに含むことを特徴とする請求項６４に記載の方法。
72. 前記クライアント側キャッシュ機構を介して前記要求されたデータを取得すること、および前記クライアント側キャッシュ機構から前記要求されたデータを前記バッファリングサービスに提供することをさらに含むことを特徴とする請求項７１に記載の方法。
73. 前記バッファリングサービスは、前記キャッシュ／メモリ管理構成要素によって生成される第２の要求を介して前記クライアント側キャッシュ機構を呼び出すことを特徴とする請求項７１に記載の方法。
74. 前記バッファリングサービスは、前記第２の要求を受信し、前記ネットワークファイルに関連するディスパッチテーブル内の情報を介して前記クライアント側キャッシュ機構を呼び出すことによって前記クライアント側キャッシュ機構を呼び出すことを特徴とする請求項７３に記載の方法。
75. 請求項６４に記載の方法を実行するコンピュータ実行可能命令を有することを特徴とするコンピュータ可読媒体。
76. コンピューティング環境において
    ネットワークファイルのデータに対応するＩ／Ｏ要求を受信すること、および
    前記ネットワークファイルに関するネットワーク接続がオフラインとして確立されているかどうかを決定すること、
    ａ）前記ネットワークファイルに関する前記接続がオフラインとして確立されている場合、バッファリングサービスを呼び出して前記要求を前記コンピュータシステム上のメモリバッファ内で処理することができるかどうかを決定し、バッファに入れられる場合、前記バッファリングサービスで前記Ｉ／Ｏ要求を完了し、バッファに入れられない場合、クライアント側キャッシュ機構を呼び出し、前記クライアント側キャッシュ機構は、前記要求に対応するデータがクライアント側キャッシュストア内に存在しているかどうかを決定し、存在している場合、前記クライアント側キャッシュストアから前記要求に対応するデータを取得して前記Ｉ／Ｏ要求を完了すること、
    ｂ）前記ネットワークファイルに関する前記接続がオフラインとして確立されていない場合、バッファリングサービスを呼び出して前記要求を前記コンピュータシステム上のメモリバッファ内で処理することができるかどうかを決定するために、前記ネットワークファイルを含むサーバーに関連するリダイレクタを呼び出し、前記バッファリングサービスで、前記要求に対応するファイルデータが前記コンピュータシステム上のメモリキャッシュ内にバッファされるかどうかを決定し、バッファに入れられる場合は、前記バッファリングサービスで前記Ｉ／Ｏ要求を完了し、バッファに入れられない場合は、前記要求に対応するデータがクライアント側キャッシュストアに存在するかどうかを決定するクライアント側キャッシュ機構を呼び出し、データが存在する場合、前記クライアント側キャッシュストアから前記要求に対応するデータを取得し、存在しない場合は、前記サーバーを介して前記要求を処理するよう前記リダイレクタに要求すること
    を含むことを特徴とする方法。
77. 前記バッファリングサービスは、前記バッファリングサービスの前記キャッシュ／メモリ管理構成要素によって生成される第２の要求を介して前記クライアント側キャッシュ機構を呼び出すことを特徴とする請求項７６に記載の方法。
78. 前記バッファリングサービスは、前記第２の要求を受信し、前記ネットワークファイルに関連するディスパッチテーブル内の情報を介して前記クライアント側キャッシュ機構を呼び出すことによって前記クライアント側キャッシュ機構を呼び出すことを特徴とする請求項７７に記載の方法。
79. 前記ネットワークファイルに関する前記ネットワーク接続が確立されるかどうかを決定することは、前記ネットワークファイルに関連するデータ構造を評価することを含むことを特徴とする請求項７６に記載の方法。
80. 請求項７６に記載の方法を実行するコンピュータ実行可能命令を有することを特徴とするコンピュータ可読媒体。
    

Images