This section describes the base CIFS protocol and how RiOS performs CIFS optimization. For example, for a client to access a file on a CIFS server, the following steps generally occur on the client:

After a connection to the server is established, client systems tend to leave the connection open for some amount of time, even when there are no open files by the client. This has an impact on CIFS optimization, because RiOS can optimize CIFS connections only when it detects the beginning of the CIFS connection. This is due to the negotiation of SMB options and SMB dialect that allow RiOS to understand what client and server operating systems are in use, which revision of the CIFS protocol is in use, and other options relevant to optimizing the connection.

The following table shows CIFS protocol commands that traverse the network during a session set up and subsequent simple file read.

This sequence represents the example protocol flow for a specific use case. Notice that SMB_COM_SESSION_SETUP_ANDX contains the user's authentication information. This is also particularly relevant when there are signed SMB sessions and Windows domains as part of the client-server environment. For details, see Windows Security Concepts.

READ_ANDX and other commands can be used (in some cases) several hundreds of times before the end of file is reached. There are many additional round trips across a WAN link that contribute to the overall performance degradation compared to the same operation across a LAN.

The CIFS protocol allows for different types of file locking and concurrent access to be used by client and servers. Separately, the CIFS protocol allows servers to notify clients (when requested) when they are the only client accessing a file, or when all clients for a file are performing only reads.

Requesting an oplock is when a client opens a potentially shared file and requests to be notified by the server when it is the only client accessing the file, or when it is accessing the file with other clients that are performing only reads (and no writes). When a client is granted an oplock on a file, it can perform some types of actions on the file completely locally, without notifying the server. Oplock breaks occur when servers notify a client if additional clients request access to the file and remote operations performed at the client must be synchronized with the server before granting that access.

The following types of oplocks are available:

Clients can request a specific type of shared-access control for a file when they open it. Examples of the types of shared access are do not share, share for read only, share for write only, or share for read/write. Clients can also apply more granular control by requesting locks on specific portions of a file, known as byte-range locks. The CIFS server tracks all of the access requests that it detects, and grants or denies operations based on the requests from live clients. The shared access control, or Shared mode access, is the most prevalent in most user applications. Typically, only database and similar applications can make use of byte range locks.

RiOS registers these concurrency controls—file locks, share access controls, and oplocks. The RiOS CIFS module tracks the state of every file opened between the client and server, and uses this state to determine what types of optimized connections can safely be applied to file requests on the clients.

For example, when a client is granted an exclusive oplock on a file, RiOS can safely perform read-ahead and write-behind of file data because it is the only client accessing the file. Some of the CIFS features in RiOS enable more in-depth recognition of concurrency control, like the overlapping open optimization and the applock optimization feature.

The concurrency controls—file locks, shared-access controls, and oplocks—ensure that clients can coordinate their reads and writes in an orderly fashion. In particular, when a client wants to read from a file, it knows that reading from a local cache is safe (for example, through oplocks), or that its reads and writes are coordinated with other clients (for example, through byte range locks).

When a client wants to write data to a file, there are two modes of writing that are supported in CIFS environments: write-through and write-back. The application using CIFS can decide which of these two modes to use every time it needs to write.

For write-through mode, the process falls into a pattern in which the client sends data to the server for writing, waits for an acknowledgment from the server, sends some more data, waits, and so on, until all the data is written and acknowledged. At this point the client sends a CIFS command to close the file on the server. The acknowledgment from the server that the file is closed signals that all data is safely written to disk. The server releases any lock on the file and makes it available for read-write access to other clients. Although this might be the safest way when writing data, when sending data across the WAN, it is not the most efficient method because the round-trip time across the WAN is typically several magnitudes higher than across the LAN.

Write-back mode is a form of optimization in which the client does not need to wait until the write is acknowledged before proceeding with the next operation. Synchronization is forced by the client flushing its cache or closing the file. Microsoft Word and Excel are good examples of applications that use CIFS in a write-back mode. If for any reason there is a problem when the file is closed, the user is informed and the data is recovered using the automatic save mechanism.

In write-back mode, there are several places where data can linger on its way to the disk: the client machine can gather writes, the server file system can delay pushing to disk, and even the server's physical disk subsystem can cache writes in RAID cards or on memory in the disk itself. RiOS provides another place for this temporary buffering between client and long-term storage to occur during write-back mode.

RiOS honors the client-specified write-back or write-through mode for each write operation. In general, most clients use write-back mode, because the performance of write-through mode—even on local disks, without the added performance impact of WAN based usage—is unacceptable to end users. RiOS can deliver fast write performance over the WAN in a way that is analogous to how file servers and network attached storage (NAS) appliances deliver fast write performance.

The CIFS protocol includes a feature to cryptographically sign every CIFS protocol datagram between the client and server. The file data that traverses the network is still sent in the clear, even when this option is used, so this CIFS feature does not protect against network snooping. However, it does protect against man-in-the-middle attacks.

The security signature feature is typically controlled through Windows group policy settings, with a separate client-side and server-side three-way setting that controls whether signing is used or not. This policy setting is then used during the initial CIFS session by the client and server to determine whether or not to sign their CIFS sessions. The following table shows the result when a client attempts to connect to a server—either the connection fails due to incompatible settings, or the session can sign the CIFS datagrams.

Several options are available for RiOS to optimize connections that are signed:

Since the initial release of SMB, Microsoft has continued to change and enhance the SMB protocol. These changes have usually coincided with the release of a new version of the Windows client and server operating system:

Using the appropriate version of RiOS, you can configure your environment so that full-latency and bandwidth optimizations are possible regardless of the SMB version.

Not all SMB features are relevant when considering optimizing SMB traffic with RiOS; however, consider the following features:

For more information about SMB3, see SMB3 Optimization with Windows 8 Clients and Windows 2012 Server.

Although the low-level detail of the CIFS protocol is beyond the scope of this document, there are many public reference materials available. For a starting point, go to http://media.server276.com/codefx/CIFS_Explained.pdf.