CIFS TRANSACT and TRANSACT2 Commands
The CIFS transaction commands _TRANSACT_ and _TRANSACT2_ allow large amounts of data (greater than 64KB) to be transferred in a client request or server response. Parameters associated with the transaction commands allow the number of data bytes in a transaction to exceed the available buffer size.
Client Transaction Request
A client transaction request contains a _TRANSACT_ or _TRANSACT2_ command together with parameter bytes and data. The parameter bytes, with the setup bytes in the packet subheader, specify the transaction to be executed by the server. The values of the parameter bytes and setup bytes are implementation-dependent and outside the scope of the CIFS protocol.
If the total number of parameter bytes and data bytes is large, the size of the client transaction request may exceed the negotiated buffer size. In this case, the client sends a primary request that is acknowledged by an interim server response and then followed by multiple client secondary requests. For client primary and secondary requests, the transaction command packet subheader includes offset and length fields that enable the server to locate the parameter bytes and data bytes within each request.
A client that supports primary and secondary requests must implement the following fields in the transaction subcommand packet header.
| Fields | Description |
|---|---|
| WordCount | Count of parameter words. |
| TotalParameterCount | Total parameter bytes being sent for the complete client transaction request. The value is the sum of the primary and secondary request buffer ParameterCount fields. |
| TotalDataCount | Total data bytes being sent for the complete client transaction request. The value is the sum of the primary and secondary request buffer DataCount fields. |
| MaxParameterCount | Maximum acceptable count of server response parameter bytes. |
| MaxDataCount | Maximum acceptable count of server response data bytes. |
| MaxSetupCount | Maximum acceptable count of server response setup words. |
| ParameterCount | Parameter bytes sent to this buffer. |
| ParameterOffset | Offset in bytes from packet header start to Parameters[] field. |
| DataCount | Data bytes sent to this buffer. |
| DataOffset | Offset in bytes from packet header start to Data[] field. |
| SetupCount | Count of setup words. |
| Setup[SetupCount] | Setup words. |
| ByteCount | Count of data bytes. |
| Parameters[ParameterCount] | Parameter bytes. |
| Data[DataCount] | Data bytes. |
The client specifies the maximum amount of data bytes and parameter bytes in the server response by means of the MaxParameterCount and MaxDataCount fields. The server informs the client of the actual amounts being returned using each buffer of the server response (TotalParameterCount and TotalDataCount). In a server response, the server may reduce the expected bytes by lowering the total number of bytes expected (TotalParameterCount or TotalDataCount).
The client has received all the parameter bytes when the amount of parameter bytes received (total of each ParameterCount value) equals the total amount of parameter bytes (TotalParameterCount).
When the amount of data bytes received (total of each DataCount value) equals the total amount of data bytes expected (smallest TotalDataCount value) received, then the client has received all the data bytes.
Server Transaction Response
The parameter bytes should normally be returned first, followed by the data bytes. However, the client knows where each begins and ends in each buffer by the offset fields (ParameterOffset and DataOffset) and the length fields (ParameterCount and DataCount). The displacement of the bytes relative to the start of the complete server response is also known (ParameterDisplacement and DataDisplacement). The client is able to reassemble the parameter and data bytes should the server responses be received out of sequence.
Some servers may send Pad bytes to move the DataOffset field to a 2- or 4-byte boundary, even if there are no data bytes. In these cases, the actual message length can be determined from ByteCount, instead of ParameterOffset plus ParameterCount.
Some servers always return MaxParameterCount bytes even if the particular _TRANSACT2_ code has no parameter response.
To return an error to the client, some servers send a response with zero values for WordCount and ByteCount instead of sending a _TRANSACT2_ response packet.
Transaction Command Sequence
The complete transaction exchange includes client and server packets from the primary client transaction request through to the final server response. The TID, PID, UID and MID values are used by both server and client and remain constant. Other SMB requests may occur during the transaction exchange.
The primary client request identifies the total bytes of parameter words and data to be sent. The primary client request contains the setup words and as many of the parameter and data bytes as will fit in a buffer of the size negotiated. The request also identifies the maximum number of result bytes (setup, parameters, and data) the server is to return on transaction completion.
If the total size of the client request exceeds the negotiated buffer size, the server responds with either a single interim response requesting more client request bytes, or with an error response terminating the transaction. On receipt of the server interim response, a secondary client request sends another buffer full of bytes to the server. This step is repeated until all of the client request bytes are sent and received.
If all parameter bytes and data bytes fit into a single buffer, then no interim response is expected and no secondary request is sent.
Upon completion of the transaction, the server sends back as many result parameter and data bytes as will fit in the negotiated client buffer size. This step is repeated until all result bytes have been returned.
The following table shows the transaction flow for a multi-buffer request.
| Client | Server |
|---|---|
| Primary transaction request | |
| Interim server response | |
| Secondary transaction request 1 | |
| Secondary transaction request 2 | |
| Secondary transaction request n | |
| Transaction response 1 | |
| Transaction response 2 | |
| Transaction response n |
The following table shows the transaction flow for a single-buffer request.
| Client | Server |
|---|---|
| Primary transaction request | |
| Transaction response 1 | |
| Transaction response 2 | |
| Transaction response n |