(57)【特許請求の範囲】
【請求項１】
サーバ上のオブジェクトをクライアントがキャッシュするシステムにおいて、前記サーバによって管理されている元のオブジェクトと、前記クライアントによって管理されているキャッシュオブジェクトを同期させるコンピュータ方法であって、前記方法は、記憶装置に記憶されたコンピュータ実行可能命令を処理装置が実行することによって実施され、
前記クライアントが、前記元のオブジェクトから前記キャッシュオブジェクトを作成するステップと、
前記クライアントが、前記元のオブジェクトに関連する通知ボンドを前記サーバに対して要求するステップと、
前記クライアントが、通知ボンドを一意に識別するボンド番号を含む通知ボンドを受信するステップと、
前記クライアントが、前記通知ボンドに関連する状態を永続メディアの中に保持するステップであって、前記状態は、通知ボンドに関連するキャッシュオブジェクトのオブジェクト識別子およびボンド番号を含む、ステップと、
前記通知ボンドに関連付けられた前記元のオブジェクトに関連するオブジェクト関連イベントが前記サーバ上で生じた場合、前記通知ボンドを有する前記クライアントが、前記オブジェクト関連イベントに応答して作成される通知であって、ボンド番号を含む通知を前記サーバから受信するステップと、
前記クライアントが、前記通知に含まれるボンド番号に関連するキャッシュオブジェクトを更新するステップと、
前記クライアントが、リスタート後に前記クライアント上で前記状態を再確立するステップと、
前記クライアントが、前記クライアント上の通知ボンドと前記サーバ上の通知ボンドを比較することにより、欠落している通知ボンドが存在するかどうか判定し、前記クライアント上の前記状態と前記サーバ上の対応する状態を同期させるステップと
を含むことを特徴とするコンピュータ実行方法。
【請求項２】
前記オブジェクト関連イベントは、前記元のオブジェクトが変更された場合を含むことを特徴とする請求項１に記載のコンピュータ実行方法。
【請求項３】
前記通知ボンドを要求するステップが、前記キャッシュオブジェクトを作成するステップに応答して実行されることを特徴とする請求項１に記載のコンピュータ実行方法。
【請求項４】
前記クライアントが、接続解除されていた期間の後に前記サーバに再接続するステップと、
前記クライアントが、通知を含む通知ログを要求するステップと、
前記クライアントが、前記通知を使用して前記キャッシュオブジェクトを前記元のオブジェクトと同期させるステップと
をさらに含むことを特徴とする請求項１に記載のコンピュータ実行方法。
【請求項５】
前記状態は、前記クライアントに固有である集合ボンド番号を含むことを特徴とする請求項１に記載のコンピュータ実行方法。
【請求項６】
オブジェクトを共有するための分散ファイルシステムであって、
前記オブジェクトに関連するオブジェクト関連イベントをスキャンし、サービスコンポーネントに前記オブジェクト関連イベントを転送するフィルタコンポーネントと、
前記オブジェクトに関連する通知ボンドを要求するクライアントとの通知ボンドを確立するサービスコンポーネントと
を含み、前記クライアントに通知ボンドを一意に識別するボンド番号を含む通知ボンドを送信し、前記通知ボンドに従って、前記クライアント向けの通知を作成し、前記クライアントに提供するように構成されたボンドマネージャと、
通知ボンドに関連するオブジェクトのオブジェクト識別子、通知ボンドに関連するクライアントを識別するクライアント識別子およびボンド番号を含むサーバボンドテーブルと
を含むサーバと、
前記サーバからキャッシュオブジェクトを作成するクライアントであって、前記サーバと連携して前記オブジェクトに関連する通知ボンドを保持し、前記サーバから前記通知ボンドに関連する通知が提供されると、前記通知に従って前記キャッシュオブジェクトを更新するように構成された通知ハンドラであって、通知ボンドに関連するキャッシュオブジェクトのオブジェクト識別子およびボンド番号を含むクライアントボンドテーブルを保持する通知ハンドラを含むように構成されたクライアントと
を含み、前記クライアントは、リスタート後に前記サーバと再接続し、前記クライアント上の通知ボンドと前記サーバ上の通知ボンドを比較することにより、欠落している通知ボンドが存在するかどうか判定し、前記クライアントボンドテーブルと前記サーバボンドテーブルを同期させることを特徴とする分散ファイルシステム。
【請求項７】
前記サーバが、前記クライアント向けの通知を含む通知ログをさらに含むことを特徴とする請求項６に記載の分散ファイルシステム。
【請求項８】
前記通知ログは、複数の通知ボンドに関連する通知を含むことを特徴とする請求項７に記載の分散ファイルシステム。
【請求項９】
オブジェクトを共有するための分散ファイルシステムであって、
サーバによって管理されている元のオブジェクトをキャッシュするための手段と、
前記元のオブジェクトに関連する通知ボンドを前記サーバに対して要求するための手段と、
通知ボンドを一意に識別するボンド番号を含む通知ボンドを受信するための手段と、
前記通知ボンドに関連するクライアントボンド状態を保持するための手段であって、前記クライアントボンド状態は、通知ボンドに関連するキャッシュオブジェクトのオブジェクト識別子およびボンド番号を含む、手段と
前記サーバによって作成される通知を使用してキャッシュオブジェクトを更新するための手段と
を含むクライアントと、
前記クライアントから通知ボンドの要求を受信するための手段と、
前記元のオブジェクトに関して前記クライアントと通知ボンドを確立するための手段と、
前記通知ボンドに関連するサーバボンド状態を保持するための手段であって、前記サーバボンド状態は、通知ボンドに関連する元のオブジェクトのオブジェクト識別子、通知ボンドに関連するクライアントを識別するクライアント識別子およびボンド番号を含む、手段と、
前記クライアントに前記ボンド番号を含む通知ボンドを送信するための手段と、
前記通知ボンドに関連付けられた前記元のオブジェクトに関連するオブジェクト関連イベントを特定するための手段と、
前記通知ボンドに関連するクライアント向けの通知を作成するための手段と、
前記通知を前記クライアントに提供するための手段と
を含むサーバと
を含み、前記クライアントは、リスタート後に前記サーバと再接続し、前記クライアント上の通知ボンドと前記サーバ上の通知ボンドを比較することにより、欠落している通知ボンドが存在するかどうか判定し、前記クライアントボンド状態と対応する前記サーバボンド状態を同期させることを特徴とする分散ファイルシステム。
【請求項１０】
前記クライアントが、
接続解除されていた期間の後に前記サーバに再接続するための手段と、
通知を含む通知ログを要求するための手段と、
前記通知を使用して前記キャッシュオブジェクトを同期させるための手段と
をさらに含むことを特徴とする請求項９に記載の分散ファイルシステム。
【請求項１１】
前記サーバが、前記通知を通知ログに記録するための手段をさらに含むことを特徴とする請求項９に記載の分散ファイルシステム。
【請求項１２】
前記サーバが、
前記クライアントと接続を確立するための手段と、
前記通知ログを前記クライアントに送信するための手段と
をさらに含むことを特徴とする請求項９に記載の分散ファイルシステム。
【請求項１３】
前記クライアントが前記通知ボンドをドロップする手段をさらに含むことを特徴とする請求項９に記載の分散ファイルシステム。
【請求項１４】
前記サーバが前記通知ボンドをドロップする手段をさらに含むことを特徴とする請求項９に記載の分散ファイルシステム。
【請求項１５】
前記サーバが前記クライアントに関連するすべての通知ボンドをドロップする手段をさらに含むことを特徴とする請求項９に記載の分散ファイルシステム。
【請求項１６】
前記サーバが前記ドロップされた通知ボンドに関連するクリア状態をリセットする手段をさらに含むことを特徴とする請求項１５に記載の分散ファイルシステム。
【請求項１７】
通信リンクが存在しなかった期間の後に、前記クライアントが、前記サーバとの通信リンクを再確立するステップと、
前記クライアントが、前記期間中に前記元のオブジェクトの少なくとも１つに対して行われた変更についての通知を前記サーバから獲得するステップと、
前記クライアントが、前記キャッシュオブジェクトのすべてを同期させることなく、前記通知を使用して前記少なくとも１つの元のオブジェクトに対応するキャッシュオブジェクトを同期させるステップと
をさらに含むことを特徴とする請求項１に記載のコンピュータ実行方法。
【請求項１８】
サーバ上のオブジェクトをクライアントがキャッシュするシステムにおいて、前記サーバによって管理されている元のオブジェクトと、前記クライアントによって管理されているキャッシュオブジェクトを同期させるコンピュータ実行方法であって、前記方法は、記憶装置に記憶されたコンピュータ実行可能命令を処理装置が実行することによって実施され、
前記クライアントが、前記元のオブジェクトから前記キャッシュオブジェクトを作成するステップと、
前記クライアントが、前記元のオブジェクトに関連する通知ボンドを前記サーバに対して要求するステップと、
前記サーバが、前記クライアントから通知ボンドの要求を受信するステップと、
前記サーバが、前記元のオブジェクトに関して前記クライアントと通知ボンドを確立するステップであって、前記通知ボンドはボンド番号によって一意に識別される、ステップと、
前記サーバが、前記通知ボンドに関連するサーバボンド状態を永続メディアに保持するステップであって、前記サーバボンド状態は、通知ボンドに関連する元のオブジェクトのオブジェクト識別子、通知ボンドに関連するクライアントを識別するクライアント識別子およびボンド番号を含む、ステップと、
前記サーバが、前記クライアントに前記ボンド番号を含む通知ボンドを送信するステップと、
前記クライアントが、通知ボンドを受信するステップと、
前記クライアントが、前記サーバボンド状態に対応する、前記通知ボンドに関連するクライアントボンド状態を永続メディアに保持するステップであって、前記クライアントボンド状態は、通知ボンドに関連するキャッシュオブジェクトのオブジェクト識別子およびボンド番号を含む、ステップと、
前記サーバが、前記通知ボンドに関連付けられた前記元のオブジェクトに関連するオブジェクト関連イベントに応答して、前記通知ボンドに関連するクライアント向けの通知を作成するステップと、
前記サーバが、前記通知を前記クライアントに提供するステップと、
前記クライアントが、前記サーバによって作成された通知に含まれるボンド番号に関連するキャッシュオブジェクトを更新するステップと、
前記サーバが、サーバリブートまたはサーバリスタートの後に前記サーバボンド状態を再確立するステップと、
前記クライアントが、前記クライアント上の通知ボンドと前記サーバ上の通知ボンドを比較することにより、欠落している通知ボンドが存在するかどうか判定し、前記クライアントボンド状態と対応する前記サーバボンド状態を同期させるステップと
を含むことを特徴とするコンピュータ実行方法。
【請求項１９】
前記サーバが、通知ボンドをドロップすることを決定するステップと、
前記サーバが、前記通知ボンドをドロップする動作を実行するステップと、
前記サーバが、前記通知ボンドをドロップするために前記クライアントに通知を提供するステップと
をさらに含むことを特徴とする請求項１８に記載のコンピュータ実行方法。
【請求項２０】
前記動作を実行するステップは、前記通知ボンドをドロップすることに前記サーバをコミットさせることを特徴とする請求項１９に記載のコンピュータ実行方法。
【請求項２１】
前記動作を実行するステップが、前記通知を前記クライアントに提供する前に完了されることを特徴とする請求項２０に記載のコンピュータ実行方法。
【請求項２２】
前記サーバが、前記クライアントに関連するすべての通知ボンドをドロップすることを決定するステップと、
前記サーバが、前記通知ボンドをドロップする動作を実行するステップと、
前記サーバが、前記通知ボンドをドロップすることに関する通知を前記クライアントに提供するステップと
をさらに含むことを特徴とする請求項１８に記載のコンピュータ実行方法。
【請求項２３】
前記動作を実行するステップは、前記通知ボンドをドロップすることに前記サーバをコミットさせることを特徴とする請求項２２に記載のコンピュータ実行方法。
【請求項２４】
前記動作を実行するステップが、前記通知を前記クライアントに提供する前に完了されることを特徴とする請求項２３に記載のコンピュータ実行方法。
【請求項２５】
前記クライアントが、通知ボンドをドロップすることを決定するステップと、
前記クライアントが、前記通知ボンドをドロップする動作を実行するステップと、
前記通知ボンドをドロップするように前記サーバに要求するステップと
をさらに含むことを特徴とする請求項１８に記載のコンピュータ実行方法。
【請求項２６】
前記動作を実行するステップは、前記通知ボンドをドロップすることに前記クライアントをコミットさせることを特徴とする請求項２５に記載のコンピュータ実行方法。
【請求項２７】
前記動作を実行するステップが、前記通知ボンドをドロップするように前記サーバに要求する前に完了されることを特徴とする請求項２６に記載のコンピュータ実行方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はサーバに保管されているファイルを複数のクライアント（コンピュータ）で共有するシステムおよび方法に関する。
【背景技術】
【０００２】
今日の分散コンピューティング環境の多くでは、複数のクライアントによって共有されることが可能なファイルを一元的に保持することが、しばしば、望ましい。従来の分散ファイルシステムが、通常、ファイルの共有を実施するのに使用される。そのようなシステムでは、クライアントは、共有ファイルを保持するファイルサーバと能動的に対話することによって共有ファイルに対するアクセスを得ることができる。詳細には、クライアントは、ファイルサーバからファイルハンドルを獲得することができ、変更をファイルサーバに通信することによってそのファイルを変更することができる。そのようなファイル共有技術は、ライブシェアリング（ｌｉｖｅ  ｓｈａｒｉｎｇ）と一般に呼ばれる。このタイプのファイル共有にはファイルサーバとクライアントの間で大量の通信が必要であるため、ライブシェアリングに関連するリソースオーバーヘッドは、非常に大きい可能性がある。
【０００３】
現在、一部の分散ファイルシステムは、クライアントが、ファイルデータをクライアントのコンピュータメモリの中にキャッシュすることができるようにしている。詳細には、クライアントは、自らのメモリの中にファイルサーバによって管理されているファイルおよびディレクトリのローカルコピーを格納することができる。そのローカルコピーは、どのようなファイルおよびディレクトリがサーバ上に用意されているかをクライアントが容易に確かめることができるようにすることにより、ファイル共有を実施する。ただし、クライアントは、データが最新であることを確実にするため、サーバに定期的に接続してキャッシュされたファイルデータを同期させなければならない。キャッシュされたファイルデータを同期させることは、特にファイルデータをキャッシュする多数のクライアントを有するサーバの場合、費用が高くつくことである。例えば、クライアントが、ある期間にわたって接続解除されていた後にサーバに再接続した場合、クライアントは、そのサーバからキャッシュされたファイルデータ全体を同期させなければならない。とうのは、クライアントは、接続解除期間中にサーバ上のいずれのファイルまたはディレクトリが変更されたかを知らないからである。同期に関連する作業は、キャッシュされたファイルおよびディレクトリの数に正比例するので、一部のシステムは、各クライアントがキャッシュすることを許されるファイルおよびディレクトリの数を制限する。
【発明の開示】
【発明が解決しようとする課題】
【０００４】
近年、モバイルコンピューティング環境が、ますます普及してきている。そのような環境では、モバイルクライアントは、しばしば、長時間にわたってネットワークから接続解除されていることが可能である。これにより、特別な課題が分散ファイルシステムにもたらされる。例えば、必要とされる同期は、モバイルクライアントがネットワークに接続されていない間、行うことができない。さらに、ユーザは、クライアントがサーバファイルおよびサーバディレクトリの相当な部分をキャッシュすることをますます望んでいる。このキャッシュされたデータは、モバイルクライアントがネットワークに再接続された際に同期されなければならない。この大量のデータを同期させることは、相当な量のクライアント／サーバ通信およびコンピューティングリソースを必要とし、これは、多くのアプリケーションにおいて法外な状況である。
【０００５】
当分野の技術者は、分散ファイルシステムにおいてクライアントがファイルをキャッシュするための効果的で効率的な方法を見出せずにいる。
【課題を解決するための手段】
【０００６】
簡単に述べると、本発明は、通知ボンドを使用してキャッシュオブジェクトを管理するためのシステムおよび方法を提供する。一態様では、本発明は、クライアントが通知ボンドを使用してサーバと対話するコンピュータ実行方法を目的とする。サーバが、元のオブジェクトを管理する。クライアントが、元のオブジェクトからキャッシュオブジェクトを作成し、サーバとの通知ボンドを確立する。通知ボンドは、クライアントが、元のオブジェクトに関連するオブジェクト関連イベントに応答してサーバから通知を獲得することができるようにする。
【０００７】
別の態様では、本発明は、通知ボンドを使用してサーバがクライアントと対話するコンピュータ実行方法を対象とする。サーバが、クライアントとの通信ボンドを確立する。サーバは、クライアントがオブジェクトをキャッシュすることができるようにし、オブジェクト関連イベントが生じた場合、クライアントに通知を提供する。
【０００８】
さらに別の態様では、本発明は、通知ボンドを使用してオブジェクトを共有するための分散ファイルシステムを対象とする。分散ファイルシステムは、元のオブジェクトを管理するように構成されたサーバを含む。サーバは、通知ボンドをクライアントに対して発行するように構成されたボンドマネージャを含む。分散ファイルシステムは、元のオブジェクトに関連するキャッシュオブジェクトを作成するように構成されたクライアントも含む。クライアントは、サーバと連携して元のオブジェクトに関連する通知ボンドを保持するように構成された通知ハンドラを含む。
【０００９】
本発明の発明者は、クライアントが、サーバによって管理されているオブジェクトを効率的かつ効果的にキャッシュすることができるようにする分散ファイルシステムにより、システムのオブジェクト共有性能が大幅に向上することを突き止めた。本発明人は、クライアントがオフラインであった間にサーバ上のいずれのオブジェクトが変更されたかをクライアントが迅速に特定できるようにすることにより、クライアントのキャッシュオブジェクトを再検証することに関連する作業が大幅に減ることも認識している。したがって、本発明は、通知ボンドを使用してキャッシュオブジェクトを管理するためのシステムおよび方法を中心に扱う。キャッシュオブジェクトが本発明によって管理される仕方は、従来のファイルキャッシュ方法とは非常に異なる。例えば、一部の従来の方法は、それぞれのキャッシュファイルが、アイテムごとに更新されることを要求する。それらの方法は、相当な量のファイル管理リソースを要し、アプリケーションおよびユーザに陳腐なキャッシュファイルを渡すことになる可能性がある。他の従来の方法は、キャッシュファイルのすべてをサーバ上の対応するファイルと比較することにより、キャッシュファイルのすべてが同期されることを要する。比較によってキャッシュ内容全体を同期させることは、クライアント上、サーバ上、およびネットワーク上で相当な実行負荷を生じさせる。この問題は、クライアントがサーバから接続解除されている間のキャッシュ状態を活用する技術によって悪化させられる。というのは、オフラインになっている間に再検証を行うことが不可能だからである。
【００１０】
これとは対照的に、本発明は、クライアントが、サーバ上のいずれのオブジェクトが対応するキャッシュオブジェクトに対して変更されているかを迅速に特定することができるようにし、変更されたオブジェクトと一致するようにそれらのキャッシュオブジェクトを効率的に同期させることができるようにする。クライアントによってキャッシュされたオブジェクトに関して、そのオブジェクトに関連する通知ボンドが確立される。通知ボンドにより、クライアントは、オブジェクトに対して行われた変更の通知を受けることができるようになる。クライアントおよびサーバは、通知ボンドに関連する状態を保持する。この通知ボンド状態は、通常、永続メモリの中に格納され、永続メモリは、クライアントおよびサーバが、リスタートまたはリブートの後にその状態を再確立することができるようにする。この状態により、クライアントは、他のキャッシュオブジェクトのすべてを再検証する必要なしに、キャッシュオブジェクトを最新にすることができるようになる。本発明の以上の態様およびその他の態様は、以下の詳細な説明を読むことで明白となろう。
【発明を実施するための最良の形態】
【００１１】
図１は、本発明の一実施形態による本発明を実施する例示的なキャッシュオブジェクト管理システム１００の概略図である。他の構成では、キャッシュオブジェクト管理システム１００は、図示したよりも多い、または少ないコンポーネントを含むことが可能である。この図に示すとおり、キャッシュオブジェクト管理システム１００は、サーバ１０３上のコンポーネント、およびクライアント１２１〜１２３を含む。
【００１２】
サーバ１０３は、オブジェクトを管理し、クライアント１２１〜１２３のためにオブジェクトの共有を実施するように構成されたコンピューティングデバイスである。サーバ１０３は、１つまたは複数のコンピュータを含むことが可能である。各コンピュータは、通常、ＲＡＭ、ＲＯＭ、ハードドライブ、光ドライブなどのコンピュータ可読メディアを含むことが可能なメモリを備えて構成される。この実施形態では、メモリは、ボンドマネージャ１０５、ファイルシステムマネージャ１０７、および元のオブジェクト１０９を含む。ファイルシステムマネージャ１０７は、ファイルサーバ１０３のソフトウェアコンポーネントであり、サーバ１０３のために元のオブジェクト１０９を扱うように構成される。ファイルシステムマネージャ１０７の例が、マイクロソフトによって開発されたＮＴＦＳである。元のオブジェクト１０９は、クライアント１２１〜１２３によって共有されることが可能なサーバ１０３の中に格納されたデータ構造である。元のオブジェクト１０９は、ファイルディレクトリや、実行可能ファイル、データなどのあらゆる種類のファイルなどの任意のタイプのデータ構造であることが可能である。元のオブジェクト１０９は、通常、ハードドライブのような大容量データ記憶ユニットの中に格納される。そのような大容量データ記憶ユニットの中で、オブジェクトは、ボリュームＩＤ、ファイルＩＤ、ファイルパスなどのハードドライブの中の記憶場所で識別されることが可能である。
【００１３】
ボンドマネージャ１０５は、サーバ１０３のソフトウェアコンポーネントであり、クライアントによってキャッシュされたオブジェクトに対する変更をクライアントに通知するように構成される。ボンドマネージャ１０５は、ファイルシステムマネージャ１０７などの別のコンポーネントの一部として組み込まれることも、フィルタなどの別個のコンポーネントとして実装されることも可能である。ボンドマネージャ１０５は、通知ハンドラ１３１〜１３３と協調してキャッシュオブジェクト１４１〜１４３を最新に保つように構成される。ボンドマネージャ１０５は、図２に関連してより詳細に説明する。簡単に述べると、ボンドマネージャ１０５は、キャッシュオブジェクト１４１〜１４３に関連する通知を提供するために通知ハンドラ１３１〜１３３に対して通知ボンドを確立する。通知により、クライアント１２１〜１２３は、いずれのキャッシュオブジェクト１４１〜１４３が更新される必要があるかを特定することができるようになる。
【００１４】
サーバ１０３は、インターネットまたは任意のワイドエリアネットワーク（ＷＡＮ）、ローカルエリアネットワーク（ＬＡＮ）、無線ネットワークなどのいずれのタイプのネットワークであることも可能なネットワーク１１０を介してクライアント１２１〜１２３と通信するように構成される。サーバ１０３とクライアント１２１〜１２３の間における通信は、図３に関連してより詳細に説明する。簡単に述べると、サーバ１０３は、ボンドを確立すること、通知を送信すること、およびキャッシュオブジェクト１４１〜１４３を同期させることなどのためにクライアント１２１〜１２３と通信するように構成される。クライアントとサーバの間の通信は、コンピュータ可読メディアと見なされる。
【００１５】
クライアント１２１〜１２３は、サーバ１０３におけるオブジェクトにアクセスするように構成されたコンピューティングデバイスである。クライアント１２１〜１２３は、アクティブな通信接続を使用してサーバ１０３と対話することができる。クライアント１２１〜１２３は、サーバ１０３との接続なしでも機能することができる。クライアント１２１〜１２３は、ユーザが、クライアント１２１〜１２３上で直接に作業することを可能にするように、または他のコンピューティングデバイスのためのサーバとしての役割をするように構成される。クライアント１２１〜１２３のそれぞれは、任意のタイプのコンピュータ可読メディアを含むことが可能なメモリを備えて構成される。クライアント１２１〜１２３のメモリは、キャッシュオブジェクト１４１〜１４３、および通知ハンドラ１３１〜１３３を含む。キャッシュオブジェクト１４１〜１４３は、クライアント１２１〜１２３に役立つ元のオブジェクト１０９から複製される。キャッシュオブジェクト１４１〜１４３は、クライアント１２１〜１２３とサーバ１０３の間における接続が確立されていない場合、または失われた場合、サーバ１０３上の対応する元のオブジェクト１０９と同期されていない可能性がある。クライアント１２１〜１２３に役立つには、キャッシュオブジェクト１４１〜１４３は、対応する元のオブジェクト１０９と同期されていなければならない。本発明では、クライアント１２１〜１２３は、オブジェクトに対応する通知を使用してキャッシュオブジェクト１４１〜１４３を同期させることができる。
【００１６】
通知ハンドラ１３１〜１３３は、通知に関連する通信およびデータ管理を扱うクライアント１２１〜１２３のコンポーネントである。通知ハンドラ１３１〜１３３は、図２に関連して詳細に説明する。簡単に述べると、通知ハンドラ１３１〜１３３は、サーバ１０３と通知ボンドを確立し、クライアント１２１〜１２３のために通知およびキャッシュオブジェクト同期を扱うように構成される。
【００１７】
図２は、本発明の一実施形態による通知ハンドラ１３１およびボンドマネージャ１０５の概略図である。この実施形態では、ボンドマネージャ１０５は、フィルタコンポーネント２０５およびサービスコンポーネント２１０を含む。フィルタコンポーネント２０５は、サーバ１０３のファイルシステムマネージャに着信するオブジェクト関連イベント、およびこのマネージャから発信されるオブジェクト関連イベントをスキャンするように構成される。これらのオブジェクト関連イベントは、クライアント１２１のようなクライアントによってキャッシュされたオブジェクトに関わることが可能である。ボンドマネージャ１０５は、それらのイベントに応答してクライアント１２１向けの通知を作成するように構成されることが可能である。フィルタコンポーネント２０５は、フィルタテーブル２０７を使用していずれのオブジェクト関連イベントが通知を要するかを特定し、そのイベントをサービスコンポーネント２１０に転送するように構成される。フィルタテーブル２０７は、通知を要するオブジェクトを特定する。フィルタテーブル２０７の例示的なデータ構造は、図４に関連して詳細に説明する。
【００１８】
サービスコンポーネント２１０は、クライアントによってキャッシュされたオブジェクトの変更に関する通知を受け取るためにクライアントと通知ボンドを確立するように構成される。この実施形態では、サービスコンポーネント２１０は、通知ボンドに関連する状態を含むサーバボンドテーブル２１５を保持する。サーバボンドテーブル２１５は、通知を要するオブジェクトを特定し、クライアント向けの通知をサービスコンポーネント２１０が作成することができるようにする状態を含む。通知は、いくつかの異なる形でクライアントに提供されることが可能である。一実施形態では、サービスコンポーネント２１０は、通知ハンドラ１３１向けの通知を含む通知ログ２１７を保持するように構成される。この実施形態の１つの構成は、通知ハンドラ１３１が通知ログ２１７を取り出すことを可能にするようにサービスコンポーネント２１０を構成することを含む。別の構成は、所定の期間の満了、通知ログ２１７のサイズが閾値を超えたことなどのイベントに応答して通知ログ２１７を通知ハンドラ１３１に送信するようにサービスコンポーネント２１０を構成することを含む。
【００１９】
別の実施形態では、通知ハンドラ１３１は、アクティブな通信リンクが利用可能な場合に通知を通知ハンドラ１３１に送信するように構成されることが可能である。通知ハンドラ１３１は、アクティブな通信リンクが利用可能でない場合に通信ログ２１７に通信を記録し、通信リンクが再確立された場合に通知ログ２１７を通知ハンドラ１３１に提供するように構成されることが可能である。
【００２０】
通知ログ２１７は、多くの形で論理的に実装することができる。一実施形態では、通知ログ２１７は、複数のクライアント向けの通知をログの中に含めることができるように多重化されたログとして実装される。別の実施形態では、通知ログ２１７は、各クライアントが別個の通知ログを有するようにクライアント別のログとして実装される。サービスコンポーネント２１０は、多重化されたログのいずれの部分が特定のクライアントに関連しているか、またはいずれのクライアント別のログがクライアントに関連しているかを明らかにするためのデータを含むログテーブル２２４を保持することが可能である。サービスコンポーネント２１０は、通知ログ２１７全体、またはクライアント１２１に当てはまるログの部分だけを送信する、または供与するように構成されることが可能である。通知ログ２１７の中の妥当なデータが通知ハンドラ１３１によって使用されて、クライアント１２１のキャッシュオブジェクトが更新されることが可能である。
【００２１】
サービスコンポーネント２１０は、オブジェクトに対して変更を行ったクライアントが、そのオブジェクト上に通知ボンドを有するかどうかを特定し、そのクライアント向けの通知を作成することを回避するようにも構成される。サービスコンポーネント２１０は、オブジェクト変更イベントに関連するデータの中でクライアント識別子を検出し、そのクライアント識別子を通知ボンドに関連する各クライアントに関する識別情報を含むクライアントテーブル２２３の中の識別子と照合することによってこの特定を行うことができる。サービスコンポーネント２１０は、フィルタコンポーネント２０５に関するフィルタテーブル２０７を提供し、更新するようにも構成されることが可能である。
【００２２】
通知ハンドラ１３１は、ボンドマネージャ１０５と対話して、クライアント１２１によってキャッシュされたオブジェクト上で通知ボンドを確立するように構成される。この実施形態では、通知ハンドラ１３１は、確立済みの通知ボンドに関連する状態を含むクライアントボンドテーブル２２０を保持する。クライアントボンドテーブル２２０は、図６に関連してより詳細に説明する。簡単に述べると、クライアントボンドテーブル２２０は、１つまたは複数のサーバ上で確立済みである通知ボンドに関する状態を含む。理想的には、クライアントボンドテーブル２２０の中の状態は、サーバボンドテーブル２１５の中の対応するデータと一致しなければならない。ただし、状態は、接続解除およびクラッシュに起因して同じでない可能性がある。再接続時に、クライアントとサーバは、状態を再同期させる。これらのテーブルの中の状態を同期させることは、クライアント１２１の中のキャッシュオブジェクトを再検証する役割をすることが可能である。
【００２３】
図３は、本発明の一実施形態によるキャッシュオブジェクト管理システムにおけるクライアントとサーバの間の例示的な通信３００の概略図である。通信３００は、サーバ上でクライアントが開いたセッションを介して行われることが可能である。例示のため、通信がサーバ１０３とクライアント１２１の間で行われているのを示している。ただし、動作の際、通信は、実際には、通知ハンドラ１４１とボンドマネージャ１０５の間など、サーバのソフトウェアコンポーネントとクライアントのソフトウェアコンポーネントの間で行われる。
【００２４】
通信３０２は、通知ボンドを獲得することに関連し、メッセージ３０５および３１０を含む。この図に示すとおり、クライアント１２１が、通知ボンド要求を伴うメッセージ３０５を送信することによって通知ボンドを獲得することが可能である。通知ボンドは、サーバ１０３によって管理され、クライアント１２１によってキャッシュされたオブジェクトに関連する。通知ボンドにより、クライアント１２１は、オブジェクトの変更に関連するファイルシステムイベントに関する通知を獲得することができるようになる。メッセージ３０５は、オブジェクトを識別する識別子を含む。識別子は、サーバ１０３上のオブジェクトのファイルパスに関する情報を含むことが可能である。メッセージ３０５は、所望される通知ボンドのタイプも含むことが可能である。ボンドの各タイプにより、通知の中に含められるデータが指定されることが可能である。
【００２５】
メッセージ３０５に応答して、サーバ１０３が、通知ボンドを確立し、通知ボンドを伴うメッセージ３１０をクライアント１２１に送信することができる。メッセージ３１０は、ボンドに一意的に関連するボンド番号（ＢＮ）や、サーバ１０３に関してクライアント１２１に固有である単調に増加するサーバ集合ボンド番号（ＡＢＮ）などの通知ボンドに関連する状態を含むことが可能である。サーバ１０３とクライアント１２１はともに、ＡＢＮを保持する。クライアントＡＢＮとサーバＡＢＮを比較することにより、クライアント１２１およびサーバ１０３は、欠落しているボンドが存在するかどうかを確認することができる。
【００２６】
通信３２２は、クライアントプル（ｐｕｌｌ）構成を使用して通知をクライアント１２１に提供することに関連し、メッセージ３２５および３３０を含む。クライアントプル構成では、クライアント１２１は、サーバ１０３から通知ログの中の通知を取り出すように構成される。クライアント１２１は、通知ボンドに関連する通知ログの要求を含むメッセージ３２５を送信することができる。通知ログは、複数の通知ボンドに関連する通知を含むことが可能である。これに応答して、サーバ１０３は、通知ログを含むメッセージ３３０を送信することができる。通知ログは、通知ボンドに従って作成されたクライアント１２１向けの通知を含む。通知ログを受信した後、クライアント１２１は、通知ログの中の通知を使用してキャッシュオブジェクトを更新することができる。
【００２７】
通信３３０は、サーバプッシュ（ｐｕｓｈ）構成を使用して通知をクライアント１２１に提供することに関連し、メッセージ３３４および３３６を含む。通知ボンドを有するオブジェクトの変更に関連するファイルシステムイベントに応答して、サーバ１０３は、通知を決定し、その通知を伴うメッセージ３３４をクライアント１２１に送信する。メッセージ３１５は、オブジェクトを識別するＢＮを含むことが可能である。メッセージ３３４は、クライアント１２１が、サーバ１０３とのさらなる通信なしに対応するキャッシュオブジェクトを更新することができるように、変更に関するデータも含むことが可能である。これに応答して、クライアント１２１は、受信確認を伴うメッセージ３３６をサーバ１０３に送信することができる。
【００２８】
通信３４０は、再接続動作に応答して通知をクライアント１２１に提供することに関連し、メッセージ３３４および３３６を含む。再接続動作の一環として、クライアント１２１は、通知ボンドに関連する通知ログの要求を含むメッセージ３４２を送信することができる。これに応答して、サーバ１０３は、通知ログを含むメッセージ３４４を送信することができる。サーバ１０３は、自らがクライアント１２１に対して有する通知ボンドの状態を含むメッセージ３４６を送信することができる。クライアント１２１は、その状態を使用して、クライアント上およびサーバ１０３上で欠落している通知ボンドを検出し、欠落している通知ボンドを再獲得する、または再確立することができる。これに応答して、クライアント１２１は、受信確認を含むメッセージ３４８を送信することができる。
【００２９】
図４は、本発明の一実施形態による例示的なフィルタテーブル２０７の概略図である。フィルタテーブル２０７により、ボンドマネージャがオブジェクト関連イベントをスキャンする際、いずれのオブジェクトが通知ボンドに関連しているかを特定することができる。この図に示すとおり、フィルタテーブル４００は、オブジェクト識別子４１１〜４１４のようなオブジェクト識別子がインデックスとして付けられたデータ構造である。オブジェクト識別子４１１〜４１４は、ファイル名またはディレクトリ名、パス、名前またはパスのハッシュ、あるいは任意の他の識別値であることが可能である。オブジェクト識別子のそれぞれにより、オブジェクトが識別され、オブジェクトに関連するエントリにインデックスが付けられる。エントリは、オブジェクトに関連する様々なデータを含むことが可能である。この実施形態では、エントリは、オブジェクトが通知ボンドに関連しているかどうかを示すブール識別子を含む。別の実施形態では、フィルタテーブル２０７は、通知ボンドに関連するオブジェクトのオブジェクト識別子だけを含むことで単純化されることが可能である。図４に示すとおり、オブジェクト識別子４１１〜４１４により、オブジェクトＰ、Ｑ、Ｒ、およびＳが識別され、エントリにより、通知ボンドに関連するオブジェクトＰ、Ｑ、およびＳが示される。
【００３０】
図５は、本発明の一実施形態による例示的なサーバボンドテーブル２１５の概略図である。サーバボンドテーブル２１５は、通知ボンドを管理するためにサーバの中でボンドマネージャによって保持されるデータ構造である。この図に示すとおり、サーバボンドテーブル２１５には、オブジェクト識別子５１１〜５１３のようなオブジェクト識別子がインデックスとして付けられている。オブジェクト識別子のそれぞれにより、オブジェクトが識別され、エントリ５２０のようなオブジェクトに関連するエントリにインデックスが付けられる。エントリ５２０は、対応するエントリを特定のクライアントに関連付けるクライアント識別子５４１〜５４３、通知ボンドを一意的に識別するボンド番号５３１〜５３３、および対応するエントリに関連する通知ボンドのタイプを識別するボンドタイプ識別子５１１〜５５３を含むことが可能である。図５に示すとおり、ボンドテーブル２１５は、オブジェクトＰを識別するオブジェクト識別子５１１を含む。エントリ５２０は、クライアントａ、ｂ、およびｃがオブジェクトＰに関連する通知ボンドを有することを示している。
【００３１】
図６は、本発明の一実施形態による例示的なクライアントボンドテーブル２２０の概略図である。クライアントボンドテーブル２２０は、通知ボンドを管理するためにクライアントの中で通知ハンドラによって保持されるデータ構造である。この図に示すとおり、クライアントボンドテーブルは、サーバ識別子６１１〜６１２のようなサーバ識別子がインデックスとして付けられたデータ構造である。サーバ識別子６１１〜６１２により、クライアントとの通知ボンドを有するサーバが識別される。この図に示すとおり、サーバ識別子６１１により、ＡＢＮ識別子６１５、オフセット６１７、およびエントリ６２０に関連するサーバＲ１１が識別される。
【００３２】
ＡＢＮ識別子６１５により、サーバＲ１１に関連する集合ボンド番号が識別される。集合ボンド番号は、単調に増加し、クライアントが、欠落している通知ボンドが存在するかどうかを確認することを可能にする。オフセット６１７は、特定のサーバから通知が受信された前回の場所を通知ログの中で特定するのに使用することができる。オフセット６１７は、クライアントが、サーバから通知を受信した後にコミットする（ｃｏｍｍｉｔ）ことを可能にする。これにより、クライアントが既に受信した通知を通知ログが含む場合でも、クライアントがサーバ上の通知ログ全体を解析しなければならないことが防がれる。オフセット６１７は、クライアント別の通知ログまたは多重化された通知ログに対するポインタであることが可能である。
【００３３】
エントリ６２０は、クライアントが、通知ボンドを管理し、通知ボンドに関連するキャッシュオブジェクトを更新することができるようにするデータを含む。この実施形態では、エントリは、オブジェクト識別子６４１〜６４３、およびボンド番号６３１〜６３３を含む。オブジェクト識別子６４１〜６４３により、通知ボンドに対応するキャッシュオブジェクトが識別される。キャッシュオブジェクトに関するファイルパスをオブジェクト識別子６４１〜６４３の中に符号化することができる。ボンド番号６３１〜６３３のそれぞれにより、クライアントとサーバＲ１１の間の特定の通知ボンドが一意的に識別される。
【００３４】
図７は、本発明の一実施形態によるクライアントがサーバによって管理されているオブジェクトに関してサーバと通知ボンドを確立するプロセス７００の動作流れ図である。プロセスは、クライアントがオブジェクトをキャッシュした場合にはいつでも実施されること、あるいはクライアントによる別個の開始を要することが可能である。開始ブロックから進み、プロセス７００は、ブロック７１０に進んで、通知ボンドの要求がクライアントからサーバに送られる。ブロック７１５で、通知ボンドが、サーバから受信される。通知ボンドは、通知ボンドを一意的に識別するボンド番号（ＢＮ）を含むことが可能である。通知ボンドは、その通知ボンドに関連するオブジェクトのファイルパスなどのアクセス情報も含むことが可能である。ブロック７２０で、クライアントが、エントリをクライアントボンドテーブルに追加する。エントリは、通知ボンドに関するデータを含む。ブロック７２５で、クライアントが、サーバに関連する集合ボンド番号（ＡＢＮ）を更新する。この実施形態では、ＡＢＮは、通知ボンドのＢＮである。ブロック７３０で、クライアントが、通知ボンドに関連するオブジェクトをメモリの中にキャッシュする。その後、プロセス７００は、終了する。
【００３５】
図８は、本発明の一実施形態によるサーバがオブジェクトに関してクライアントと通知ボンドを確立するプロセス８００の動作流れ図である。プロセスは、クライアントがオブジェクトをキャッシュする要求を行った時点で、またはクライアントによる別個の開始に応答して実施されることが可能である。
【００３６】
開始ブロックから進み、プロセス８００は、ブロック８１０に進んで、ボンド要求がクライアントから受信される。ブロック８１５で、通知ボンドが確立される。ブロック８２０で、エントリがサーバボンドテーブルに追加される。エントリが、フィルタテーブルにも追加されることが可能である。ブロック８２５で、クライアントに固有のＡＢＮが更新される。ブロック８３０で、通知ボンドがクライアントに送信される。その後、プロセス８００は、終了する。
【００３７】
図９は、本発明の一実施形態によるサーバが通知をクライアントに送信するプロセス９００の動作流れ図である。開始ブロックから進み、プロセス９００は、ブロック９１０に進んで、オブジェクトに関連するオブジェクト関連イベントが特定される。判定ブロック９１５で、その通知イベントに関して通知が必要とされるかどうかの判定が行われる。この判定は、そのオブジェクトの参照がフィルタテーブルの中に存在するかどうかを調べることによって行うことができる。通知が不要である場合、プロセスは終了する。
【００３８】
判定ブロック９１５に戻ると、オブジェクト関連イベントに関して通知が必要とされる場合、プロセス９００は、ブロック９２０に進み、そのオブジェクトに関連する１つまたは複数の通知ボンドが特定される。この特定は、サーバボンドテーブルの中のエントリを調べることによって行うことができる。複数のクライアントがそのオブジェクトをキャッシュしており、通知ボンドを獲得している可能性があるため、複数の通知ボンドが存在することも可能である。以下に説明するプロセスは、通知ボンドを有する各クライアントに適用可能である。
【００３９】
判定ブロック９２３で、オブジェクト関連イベントが、そのオブジェクト上に通知ボンドを有するクライアントによって生じさせられたかどうかの判定が行われる。そのオブジェクト上に通知ボンドを有するクライアントによって生じさせられている場合、クライアントは、オブジェクト関連イベントについて既に知っており、そのクライアントにはまったく通知が送信されない。そのクライアントが通知ボンドを有する唯一のクライアントである場合、プロセス９００は終了する。そうでない場合、プロセスは、ブロック９２５に進む。
【００４０】
判定ブロック９２３に戻ると、オブジェクト関連イベントが、そのオブジェクト上に通知ボンドを有するクライアントによって生じさせられたものではない場合、プロセス９００は、ブロック９２５に進む。ブロック９２５で、サーバボンドテーブルの中のデータに基づいて通知が作成される。
【００４１】
判定ブロック９３０で、通知をクライアントに送信するかどうかの判定が行われる。この判定は、サーバが、すべての通知を通知ログに記録するように構成されている場合、必要ない。しかし、サーバが、ある条件下で通知をクライアントに直接に送信するように構成されている場合、それらの条件が存在する場合に判定は、肯定的である。判定は、通知が送信されている最中に接続解除が行われた場合には、否定的になることが可能である。
【００４２】
判定が肯定的であった場合、プロセス９００は、ブロック９３５に進み、通知がクライアントのそれぞれに送信されて、終了する。判定ブロック９３０に戻ると、判定が否定的であった場合、そのクライアントに関連する通知が、通知ログに送られる。ブロック９３５と９４０がともに行われることも可能であり、複数のクライアントに適用されることが可能である。その後、プロセス９００は終了する。
【００４３】
図１０は、本発明の一実施形態によるクライアントがサーバに再接続するプロセス１０００の概略図である。プロセス１０００は、ある期間にわたって接続解除されていた後にサーバに再接続した際にクライアントによって自動的に実施されることが可能である。プロセス１０００は、クライアントによる別個の開始に応答して、または通知ログのサイズが所定の値に達した時点でサーバによって指示されるなどの外部イベントに応答して実施されることも可能である。開始ブロックから進み、プロセス１０００は、ブロック１０２０に進んで、クライアントとサーバが互いの認証を行う。ブロック１０２５で、クライアント上の通知ボンドとサーバ上の通知ボンドが比較されて、欠落している通知ボンドが存在するかどうかが確かめられる。システムクラッシュまたはその他の障害に起因して通知ボンドに関するデータが失われている場合、通知ボンドが欠落している可能性がある。一実施形態では、この比較は、クライアントＡＢＮをサーバＡＢＮと比較することによって行われる。
【００４４】
判定ブロック１０３０で、サーバ上で欠落している通知ボンドが存在するかどうかの判定が行われる。クライアントＡＢＮがサーバＡＢＮより大きいことは、サーバ上で欠落している通知ボンドが存在することを示すものである。例えば、クライアントが、サーバによってアサートされるＡＢＮより大きいＢＮによって表される通知ボンドをアサートしている場合、クライアントによってアサートされているその通知ボンドが、サーバが知らない通知ボンドである。
【００４５】
欠落している通知ボンドが存在する場合、プロセス１０００は、ブロック１０５０に進み、欠落している通知ボンドがサーバから再獲得される。例えば、クライアントは、図７に関連して前述したプロセス７００を開始して、通知ボンドを再獲得することができる。クライアントは、それらの通知ボンド、およびそれらの通知ボンドに関連するキャッシュオブジェクトを破棄することもできる。プロセスは、ブロック１０４０に進む。
【００４６】
判定ブロック１０３０に戻ると、サーバ上で欠落しているボンドがまったく存在しない場合、プロセス１０００は、ブロック１０４０に進み、クライアント上で欠落しているボンドが存在するかどうかの判定が行われる。クライアントＡＢＮがサーバＡＢＮより小さいことは、クライアント上で欠落している通知ボンドが存在することを示すものである。例えば、サーバが、クライアントによってアサートされるＡＢＮより多きＢＮによって表される通知ボンドをアサートしている場合、サーバによってアサートされているその通知ボンドが、クライアントが知らない通知ボンドである。クライアント上で欠落しているボンドがまったく存在しない場合、プロセスは、終了する。クライアント上で欠落している通知ボンドが存在する場合、プロセス１０００は、ブロック１０４５に進み、クライアントボンドテーブルが、その欠落している通知ボンドを削除するように更新される。クライアントが、欠落している通知ボンドに関連するオブジェクトをキャッシュすること、またはそのボンドを破棄することも可能である。その後、プロセスは終了する。
【００４７】
図１１は、本発明の一実施形態によるクライアントが通知ボンドをドロップするプロセス１１００の概略図である。プロセス１１００は、クライアントが１つまたは複数の通知ボンドをドロップすることによって実施されることが可能である。例示のため、プロセス１１００は、単一の通知ボンドをドロップすることの文脈において説明する。開始ブロックから進み、プロセス１１００は、ブロック１１２０に進んで、通知ボンドをドロップする決定が行われる。クライアントは、いくつかの理由で通知ボンドをドロップすることを望む可能性がある。例えば、クライアントは、特定のキャッシュオブジェクトの必要性がもはや存在しないと判定した場合、そのキャッシュオブジェクトを削除し、関連する通知ボンドをドロップすることができる。ブロック１１２５で、クライアントは、通知ボンドをドロップする動作を実行する。例えば、クライアントは、通知ボンドを実装するための様々なテーブルから通知ボンドに関連するデータを削除することができる。ブロック１１３０で、クライアントは、通知ボンドをドロップする要求をサーバに送信する。整合性を保つため、クライアントは、ブロック１１２５の動作を実行して、通知ボンドをドロップすることにコミットしてから、ブロック１１３０で、ドロップ要求をサーバに送信することができる。これに応答して、サーバは、ブロック１１３５で示すとおり、その要求に対する受信確認を送信することができる。その後、プロセスは終了する。
【００４８】
図１２は、本発明の一実施形態によるサーバが通知ボンドをドロップするプロセス１２００の概略図である。プロセス１２００は、サーバが１つまたは複数の通知ボンドをドロップすることによって実施されることが可能である。開始ブロックから進み、プロセス１２００は、ブロック１２２０に進んで、通知ボンドをドロップする決定が行われる。サーバは、多くの異なる理由で通知ボンドをドロップすることを望む可能性がある。例えば、サーバは、あるオブジェクトを管理することをやめた場合、そのオブジェクトに関連する通知ボンドをドロップすることができる。サーバは、特定のクライアントが長期間にわたってサーバに接続しなかった場合、そのクライアントに関連する通知ボンドをドロップすることもできる。
【００４９】
判定ブロック１２２５で、特定のクライアントに関連するすべての通知ボンドがドロップされているかどうかの判定が行われる。ドロップされていない場合、プロセス１２００は、ブロック１２２９に進む。ブロック１２２９で、サーバは、通知ボンドをドロップするための動作を実行する。次に、プロセスは、ブロック１２３０に進む。
【００５０】
判定ブロック１２２５に戻ると、特定のクライアントに関連するすべての通知ボンドがドロップされている場合、プロセスは、ブロック１２２７に進み、そのクライアントに関連するＡＢＮが０に設定される。プロセス１２００は、ブロック１２２８に進み、サーバが、そのクライアントに関連するすべての通知ボンドをドロップするための動作を実行する。次に、プロセスは、ブロック１２３０に進む。
【００５１】
ブロック１２３０で、サーバは、特定の通知ボンド、またはクライアントの通知ボンドのすべてをドロップすることについての通知をクライアントに提供する。通知は、その通知を通知ログに記録することによって提供されることが可能である。整合性を保つため、クライアントは、ブロック１２２８またはブロック１２２９の動作を実行して、通知ボンドをドロップすることにコミットしてから、ブロック１２３０で、通知をクライアントに送信することができる。サーバは、ブロック１２３５に示すとおり、クライアントから受信確認を受信することができる。その後、プロセスは終了する。
【００５２】
結論として、本発明は、クライアントが、多数のオブジェクトをキャッシュし、キャッシュオブジェクトをサーバ上の対応するオブジェクトと迅速に同期させることを可能にする。本発明の能力および効率は、部分的には、キャッシュされたいずれのオブジェクトがサーバ上で変更され、更新されることを要するかをクライアントが知ることを可能にすることによって達せられる。通知ボンドを使用して、キャッシュされたオブジェクトに対して行われた変更がクライアントに通知されることを確実にする。永続的な共有通知ボンド状態により、サーバおよびクライアントは、クライアントおよびサーバのリスタートおよびリブートに耐えて通知ボンドを再確立することができる。また、本発明は、クライアントがサーバの中のコンテンツのほんの一部分をキャッシュすることにだけ関心がある状況において、トラフィックを最小限に抑える。
【００５３】
以上の詳細、例、およびデータが、本発明の完全な説明を提供している。本発明の趣旨および範囲を逸脱することなく、本発明の多数の実施形態を実施することができるので、本発明は、特許請求の範囲に帰される。
【図面の簡単な説明】
【００５４】
【図１】本発明を実施する例示的なキャッシュオブジェクト管理システムを示す概略図である。
【図２】通知ハンドラおよびボンドマネージャを示す概略図である。
【図３】キャッシュオブジェクト管理システムにおけるクライアントとサーバの間の例示的な通信を示す概略図である。
【図４】例示的なフィルタテーブルを示す概略図である。
【図５】例示的なサーバボンドテーブルを示す概略図である。
【図６】例示的なクライアントボンドテーブルを示す概略図である。
【図７】クライアントがサーバによって管理されているオブジェクトに関してサーバと通知ボンドを確立するプロセスを示す動作流れ図である。
【図８】サーバがオブジェクトに関してクライアントと通知ボンドを確立するプロセスを示す動作流れ図である。
【図９】サーバが通知をクライアントに送信するプロセスを示す動作流れ図である。
【図１０】クライアントが自らのキャッシュオブジェクトをサーバと同期させるプロセスを示す概略図である。
【図１１】クライアントが通知ボンドをドロップするプロセスを示す概略図である。
【図１２】本発明の実施形態によるサーバが通知ボンドをドロップするプロセスを示す概略図である。
【符号の説明】
【００５５】
１００  キャッシュオブジェクト管理システム
１０３  サーバ
１０５  ボンドマネージャ
１０７  ファイルシステムマネージャ
１０９  オブジェクト
１１０  ネットワーク
１２１、１２２、１２３  クライアント
１３１、１３２、１３３  通知ハンドラ
１４１、１４２、１４３  キャッシュオブジェクト
【図１】
0004794143.tif 000002
【図２】
0004794143.tif 000003
【図３】
0004794143.tif 000004
【図４】
0004794143.tif 000005
【図５】
0004794143.tif 000006
【図６】
0004794143.tif 000007
【図７】
0004794143.tif 000008
【図８】
0004794143.tif 000009
【図９】
0004794143.tif 000010
【図１０】
0004794143.tif 000011
【図１１】
0004794143.tif 000012
【図１２】
0004794143.tif 000013