Batch Oplocks

Batch oplocks are used where common programs on a client behave in such a way that causes the amount of network traffic on a wire to go beyond an acceptable level for the functionality provided by the program.

For example, the command processor executes commands from within a command procedure by performing the following steps:

Opening the command procedure.
Seeking to the "next" line in the file.
Reading the line from the file.
Closing the file.
Executing the command.

This process is repeated for each command executed from the command procedure file. As is obvious, this type of programming model causes an inordinate amount of processing of files, thereby creating a lot of network traffic that could otherwise be curtailed if the program were to simply open the file, read a line, execute the command, and then read the next line.

Batch oplocking curtails the amount of network traffic by allowing the client to skip the extraneous open and close requests. When the command processor then asks for the next line in the file, the client can either ask for the next line from the server, or it may have already read the data from the file as readahead data. In either case, the amount of network traffic from the client is greatly reduced.

If the server receives either a rename or a delete request for the file that has a batch oplock, it must inform the client that the oplock is to be broken. The client can then change to a mode where the file is repeatedly opened and closed.

The batch oplock protocol is:

Client		<->	Server
A ===========	B ============	====	===============================
Open("foo")		`->`
		`<-`	Open OK. Batch oplock granted.
Read		`->`
		`<-`	data
<close>
<open>
<seek>
		`->`	read
		`<-`	data
<close>
	Open("foo")	`->`
		`<-`	Oplock break to A
Close		`->`
		`<-`	Close OK to A
		`<-`	Open OK to B

When client A opens the file, it can request an oplock. Provided no one else has the file open on the server, then the oplock is granted to client A. Client A, in this case, keeps the file open for its caller across multiple open/close operations. Data may be read ahead for the caller and other optimizations, such as buffering locks, can also be performed.

When another client requests an open, rename, or delete operation to the server for the file, however, client A must cleanup its buffered data and synchronize with the server. Most of the time this involves actually closing the file, provided that client A's caller actually believes that he has closed the file. Once the file is actually closed, client B's open request can be completed.