共用方式為


機會鎖定範例

下列範例顯示數據與SMB訊息移動,因為機會鎖定已建立和中斷。 請注意,用戶端可以快取檔案屬性數據和檔案數據。

另請注意,這些範例是以用戶端應用程式向遠端伺服器要求機會鎖定的情況為基礎。 這些程式會自動由網路重新導向器和遠端伺服器起始,用戶端應用程式或應用程式不會直接介入。 這些範例所述的程式可一般化為本機用戶端應用程式直接從本機文件系統要求機會鎖定的情況,但不包括透過網路交換數據的情況。

層級 1 機會主義鎖定

下圖顯示檔案上層級 1 機會鎖定的網路流量檢視。 箭號會指出數據移動的方向,如果有的話。

事件 用戶端 X 伺服器 用戶端 Y
1 開啟檔案,要求層級 1 鎖定 ==>
2 <== 授與層級 1 的機會鎖定
3 執行讀取、寫入和其他作業 ==>
4 <== 開啟檔案的要求
5 <== 中斷機會鎖定
6 捨棄預先讀取的數據
7 寫入數據 ==>
8 傳送 「close」 或 「done」 訊息 ==>
9 Oks open operation ==>
10 執行讀取、寫入和其他作業 ==> <== 執行讀取、寫入和其他作業

 

在事件 1 中,用戶端 X 會開啟檔案,並在開啟作業中要求檔案的第 1 層機會鎖定。 在事件 2 中,伺服器會授與層級 1 鎖定,因為沒有其他客戶端開啟檔案。 用戶端會在事件 3 中以一般方式繼續存取檔案。

在事件 4 中,用戶端 Y 嘗試開啟檔案,並要求機會鎖定。 伺服器看到用戶端 X 已開啟檔案。 當用戶端 X 排清任何寫入數據,並放棄檔案的讀取快取時,伺服器會忽略 Y 的要求。

伺服器會強制 X 藉由傳送至 X 中斷機會鎖定事件 5 的 SMB 訊息來清除。 用戶端 X 會「以無訊息方式」捨棄任何預先讀取的數據;換句話說,此程式不會產生任何網路流量。 在事件 7 中,用戶端 X 會將任何快取的寫入數據寫入伺服器。 當用戶端 X 將快取數據寫入伺服器時,用戶端 X 會將「關閉」或「完成」訊息傳送至伺服器,事件 8。

當伺服器收到通知后,用戶端 X 會將其寫入快取排清至伺服器或關閉檔案之後,伺服器就可以在事件 9 中開啟用戶端 Y 的檔案。 因為伺服器現在有兩個客戶端開啟相同的檔案,所以它不會授與機會鎖定給兩者。 這兩個客戶端都會繼續從檔案讀取,而其中一個或兩者都不會寫入檔案。

Batch 機會鎖定

下圖顯示批次機會鎖定的網路流量檢視。 箭號會指出數據移動的方向,如果有的話。

事件 用戶端 X 伺服器 用戶端 Y
1 開啟檔案,要求批次鎖定 ==>
2 <== 授與批次機會鎖定
3 讀取檔案 ==>
4 <== 傳送數據
5 關閉檔案
6 開啟檔案
7 搜尋數據
8 讀取資料 ==>
9 <== 傳送數據
10 關閉檔案
11 <== 開啟檔案
12 <== 中斷機會鎖定
13 關閉檔案 ==>
14 Oks open operation ==>
15 <== 執行讀取、寫入和其他作業

 

在批次機會鎖定中,用戶端 X 會開啟檔案、事件 1,而伺服器會在事件 2 中授與用戶端 X 批次鎖定。 用戶端 X 嘗試讀取伺服器以數據回應的數據事件 3 事件 4。

事件 5 顯示工作批次機會鎖定。 Client X 上的應用程式會關閉檔案。 不過,網路重新導向器會篩選出關閉作業,而不會傳輸關閉訊息,因此會執行「無訊息」關閉。 網路重新導向器可以這麼做,因為用戶端 X 擁有檔案的唯一擁有權。 稍後,在事件 6 中,應用程式會重新開啟檔案。 同樣地,不會跨網路流動任何數據。 就伺服器而言,此用戶端自事件 2 以來已開啟檔案。

事件 7、8 和 9 會顯示網路流量的一般過程。 在事件 10 中,會發生另一個無訊息關閉。

在事件 11 中,用戶端 Y 嘗試開啟檔案。 伺服器的檔案檢視是用戶端 X 已開啟,即使用戶端 X 上的應用程式已關閉它也一樣。 因此,伺服器會將中斷機會鎖定的訊息傳送給用戶端 X。用戶端 X 現在會透過網路傳送關閉訊息,事件 13。 事件 14 如下,因為伺服器會開啟用戶端 Y 的檔案。用戶端 X 上的應用程式已關閉檔案,因此不會再從該檔案的伺服器傳輸。 用戶端 Y 會在事件 15 中像往常一樣開始數據傳輸。

在用戶端 X 在事件 2 和事件 13 的最後關閉期間,用戶端快取的任何檔案數據都是有效的,儘管介入應用程式開啟和關閉作業,但用戶端已快取的任何檔案數據都是有效的。 不過,在機會鎖定中斷之後,無法將快取的數據視為有效。

篩選機會鎖定

下圖顯示篩選機會鎖定的網路流量檢視。 箭號會指出數據移動的方向,如果有的話。

事件 用戶端 X 伺服器 用戶端 Y
1 開啟沒有訪問許可權的檔案 ==>
2 <== 開啟檔案
3 要求篩選鎖定==>
4 <== 授與鎖定
5 開啟檔案以讀取 ==>
6 <== 重新開啟檔案
7 使用讀取句柄 ==> 讀取數據
8 <== 傳送數據
9 <== 傳送數據
10 <== 傳送數據
11 <== 開啟檔案
12 開啟檔案 ==>
13 <== 要求篩選鎖定
14 拒絕篩選鎖定==>
15 <== 讀取數據
16 傳送數據 ==>
17 讀取 (快取) 數據
18 關閉檔案 ==>
19 <== 關閉檔案

 

在篩選機會鎖定中,用戶端 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 會關閉檔案。 用戶端的網路重新導向器會放棄快取的數據。 伺服器會關閉檔案。