CIFS Batching Requests (ANDX Commands)
LANMAN1.0 and later dialects of the SMB protocol including CIFS allow multiple client requests to be sent as one packet to the server. Commands chained together in this way are called ANDX commands.
A server file may be both unlocked and accessed using a single client request using the ANDX command SMB_COM_LOCKING_ANDX, which permits the addition of the following I/O commands to a file lock/unlock command:
- SMB_COM_READ
- SMB_COM_READ_ANDX
- SMB_COM_WRITE
- SMB_COM_WRITE_ANDX
- SMB_COM_FLUSH
For both send and receive, the entire message including any chained commands must fit in the maximum transfer size negotiated by the client in an earlier NEGOTIATE command.
Client Request Packet
The client request is a single packet containing the chained ANDX commands. Chained ANDX commands do not repeat the SMB packet header information. Each chained ANDX command starts at the WordCount field.
All chained ANDX commands must fit within the negotiated transmit buffer size. This limits the maximum size of the command chain.
Each chained ANDX command in the combined client request packet references the same FID and TID. The chained commands perform a single (multi-part) operation on the same resource.
Server Response Packet
The server responds once to the client request packet and may not elect to send separate responses to each of the chained ANDX commands.
The server chained responses must also fit within the negotiated transmit size. This limits the maximum value on an embedded SMB_COM_READ command, for example. It is the client responsibility to not request more bytes than will fit within the multiple response.
The server implicitly uses the result of the first command in the chained command. For example the TID obtained using SMB_COM_TREE_CONNECT_ANDX would be used in a chained SMB_COM_OPEN_ANDX command, and the FID obtained using SMB_COM_OPEN_ANDX would be used in a chained SMB_COM_READ command.
The server response packet must be truncated to the maximum number of 512 byte blocks which will fit (starting at a 32-bit boundary) in the negotiated buffer size.
Error Handling
The first command to encounter an error will stop all further processing of chained commands. The server will not back out commands that succeeded. Thus, if a chained request contains an open command SMB_COM_OPEN_ANDX and a read command SMB_COM_READ, and the server opens the file successfully but the read request encounters an error, the file remains open. This result is the same as if the requests had been sent separately.
If an error occurs while processing chained commands, the last response (of the chained commands in the buffer) will be to the command that encountered the error. Other unprocessed chained commands are ignored and will not be represented in the chained response. If no valid ANDX command is processed, then the error occurred on the first command and the packet header field Command contains the command which failed. In all cases, error information is returned in the SMB header at the start of the response buffer.
Offsets
Each chained command contains the offset from the start of the SMB header to the next chained request/response. There may be space between the end of the previous request (as defined by WordCount and ByteCount) and the start of the next chained request. This simplifies the building of chained protocol requests.
The offset is contained in the AndXOffset field.