日和見ロックの例

次の例は、日和見ロックが行われ、破損した場合のデータと SMB メッセージの移動を示しています。 クライアントは、ファイル属性データとファイル データをキャッシュできることに注意してください。

また、これらの例は、クライアント アプリケーションがリモート サーバーから日和見ロックを要求している状況に基づいていることにも注意してください。 これらのプロセスは、ネットワーク リダイレクターとリモート サーバーによって自動的に開始されます。クライアント アプリケーションやアプリケーションが直接関与する必要はありません。 これらの例で説明されているプロセスは、ローカル クライアント アプリケーションがローカル ファイル システムに対して日和見ロックを直接要求する状況に一般化できます。ただし、ネットワーク経由でのデータ交換は関係しません。

レベル 1 の日和見ロック

次の図は、ファイルのレベル 1 の日和見ロックのネットワーク トラフィック ビューを示しています。 矢印は、データ移動の方向 (ある場合) を示します。

イベント 1 では、クライアント X はファイルを開き、開いている操作の一環として、ファイルに対してレベル 1 の日和見ロックを要求します。 イベント 2 では、他のクライアントがファイルを開いないため、サーバーはレベル 1 のロックを付与します。 クライアントは、イベント 3 で通常の方法でファイルへのアクセスを続行します。

イベント 4 では、クライアント Y はファイルを開こうとし、日和見ロックを要求します。 サーバーは、クライアント X にファイルが開かれていることを確認します。 クライアント X が書き込みデータをフラッシュし、ファイルの読み取りキャッシュを破棄している間、サーバーは Y の要求を無視します。

サーバーは、日和見ロックであるイベント 5 を中断する SMB メッセージを X に送信して、X にクリーンアップを強制します。 クライアント X は、先行読み取りデータを "サイレント" で破棄します。つまり、このプロセスではネットワーク トラフィックは生成されません。 イベント 7 では、クライアント X はキャッシュされた書き込みデータをサーバーに書き込みます。 クライアント X がキャッシュされたデータのサーバーへの書き込みを完了すると、クライアント X は"close" または "done" メッセージをサーバーに送信します。イベント 8。

クライアント X がサーバーへの書き込みキャッシュのフラッシュが完了したことをサーバーに通知した後、またはファイルを閉じた後、サーバーはイベント 9 でクライアント Y のファイルを開くことができます。 サーバーには同じファイルを持つ 2 つのクライアントが開かれているため、どちらのクライアントにも日和見ロックが付与されません。 どちらのクライアントもファイルからの読み取りを続行し、1 つまたは両方がファイルに書き込みます。

Batch Opportunistic Lock

次の図は、バッチの日和見ロックのネットワーク トラフィック ビューを示しています。 矢印は、データ移動の方向 (ある場合) を示します。

バッチ日和見ロックでは、クライアント X はファイル、イベント 1 を開き、サーバーはイベント 2 でクライアント X にバッチ ロックを付与します。 クライアント X は、サーバーがデータ (イベント 4) で応答するデータ (イベント 3) の読み取りを試みます。

イベント 5 は、作業中のバッチの日和見ロックを示しています。 クライアント X 上のアプリケーションがファイルを閉じます。 ただし、ネットワーク リダイレクターは閉じる操作を除外し、閉じるメッセージを送信しないため、"サイレント" クローズを実行します。 ネットワーク リダイレクターは、クライアント X がファイルの唯一の所有権を持っているため、これを行うことができます。 その後、イベント 6 で、アプリケーションによってファイルが再度開きます。 ここでも、ネットワークを経由するデータ フローはありません。 サーバーに関する限り、このクライアントはイベント 2 以降にファイルを開いています。

イベント 7、8、および 9 は、ネットワーク トラフィックの通常のコースを示しています。 イベント 10 では、別のサイレント クローズが発生します。

イベント 11 では、クライアント Y がファイルを開こうとします。 ファイルのサーバービューは、クライアントX上のアプリケーションがそれを閉じているにもかかわらず、クライアントXがそれを開いているということです。 そのため、サーバーは、日和見ロックを解除するメッセージをクライアント X に送信します。クライアント X は、ネットワーク (イベント 13) を介して閉じるメッセージを送信するようになりました。 イベント 14 は、サーバーがクライアント Y のファイルを開くと続きます。クライアント X 上のアプリケーションはファイルを閉じたため、そのファイルのサーバーとの間の転送は行われません。 クライアント Y は、イベント 15 で通常どおりデータ転送を開始します。

イベント 2 のファイルのロックがクライアント X に付与されてからイベント 13 で最後に閉じるまでの間、クライアントがキャッシュしたファイル データは、アプリケーションのオープン操作とクローズ操作が間に合わず有効になります。 ただし、日和見ロックが解除された後は、キャッシュされたデータを有効と見なすことはできません。

フィルターの日和見ロック

次の図は、フィルターの日和見ロックのネットワーク トラフィック ビューを示しています。 矢印は、データ移動の方向 (ある場合) を示します。

フィルターの日和見ロックでは、クライアント X はファイル、イベント 1 を開き、サーバーはイベント 2 で応答します。 その後、クライアントはイベント 3 でフィルターの日和見ロックを要求した後、サーバーがイベント 4 で日和見ロックを許可します。 クライアント X は、イベント 5 で読み取るためにファイルを再度開き、サーバーがイベント 6 で応答します。 その後、クライアントはデータの読み取りを試みます。サーバーがデータで応答するイベント 8。

イベント 9 は、作業中のフィルターの日和見ロックを示しています。 クライアントが要求していない場合でも、サーバーはクライアントより先に読み取り、ネットワーク経由でデータを送信します。 クライアントはデータをキャッシュします。 イベント 10 では、サーバーはデータの将来の要求を予測し、クライアントがキャッシュするためにファイルの別の部分を送信します。

イベント 11 と 12 では、別のクライアント Y がファイルを開きます。 クライアント Y は、フィルターの日和見ロックも要求します。 イベント 14 では、サーバーはそれを拒否します。 イベント 15 では、クライアント Y は、サーバーがイベント 16 で送信するデータを要求します。 いずれの場合も、クライアント X には影響しません。別のクライアントは、いつでもこのファイルを開いて読み取りアクセスできます。 他のクライアントは、クライアント X のフィルター ロックに影響しません。

イベント 17 は、データを読み取るクライアント X を示しています。 ただし、サーバーは既にデータを送信しており、クライアントがデータをキャッシュしているため、トラフィックはネットワークを通過しません。

この例では、クライアント X はファイル内のすべてのデータを読み取ろうとしないため、イベント 9 と 10 で示される先行読み取りは "無駄" になります。つまり、データは実際には使用されません。 先行読み取りによってアプリケーションが高速化されたため、これは許容される損失です。

イベント 18 では、クライアント X はファイルを閉じます。 クライアントのネットワーク リダイレクターは、キャッシュされたデータを破棄します。 サーバーがファイルを閉じます。