If a client is granted an exclusive oplock, it may buffer lock information, read-ahead data, and write data on the client because the client knows that it is the only accessor to the file. The basic protocol is that the redirector on the client opens the file requesting that an oplock be given to the client. If the file is open by anyone else, then the client is refused the oplock and no local buffering may be performed on the local client. This also means that no readahead may be performed to the file, unless the redirector knows that it has the read ahead range locked. If the server grants the exclusive oplock, the client can perform certain optimizations for the file such as buffering lock, read, and write data.
The exclusive oplock protocol is:
| Client | <-> | Server | |
| A ============== |
B =========== |
=== |
================================ |
| Open ("foo") | -> |
||
<- |
Open OK. Exclusive oplock granted. | ||
| Open("foo") | -> |
||
<- |
oplock break to A | ||
| lock(s) | -> |
||
<- |
lock(s) response(s) | ||
| write(s) | -> |
||
<- |
write(s) response(s) | ||
| close or done | -> |
||
<- |
open response to B | ||
As can be seen, when client A opens the file, it can request an exclusive oplock. Provided no one else has the file open on the server, then the oplock is granted to client A. If, at some point in the future, another client, such as client B, requests an open to the same file, then the server must have client A break its oplock. Breaking the oplock involves client A sending the server any lock or write data that it has buffered, and then letting the server know that it has acknowledged that the oplock has been broken. This synchronization message informs the server that it is now permissible to allow client B to complete its open.
Client A must also purge any readahead buffers that it has for the file. This is not shown in the above diagram since no network traffic is needed to do this.