3.2.4.15.2 Client Requests Multiplexed Write
SMB_COM_WRITE_MPX is used to maximize the performance of large block writes of data from the client to the server. This command is valid only when using a multiplexed session (multiple transport connections bound to a single SMB connection) over a connectionless transport. To perform a multiplexed write, the client MUST send multiple SMB_COM_WRITE_MPX requests (each containing data to be written and the offset, in the ByteOffsetToBeginWrite field, at which the packet data is to be written) before the server responds with a single SMB_COM_WRITE_MPX response.
The client identifies the last request in the write sequence by also setting the SMB Header SecurityFeatures.SequenceNumber field to a nonzero value. This indicates to the server that the client indicates that it has completed sending all of the requests that need to be processed. After receiving the nonzero SMB Header SecurityFeatures.SequenceNumber, the server MUST respond with a single SMB_COM_WRITE_MPX response.
The client request RequestMask values are saved by the server and bitwise OR-ed into a value that is returned to the client in the ResponseMask field of the server's SMB_COM_WRITE_MPX response. If a problem occurred with the SMB transport and one or more of the client's SMB_COM_WRITE_MPX requests was not successfully received and processed by the server, the bit for that request MUST NOT be set in the server's SMB_COM_WRITE_MPX response ResponseMask field. The client MUST use the ResponseMask received in the SMB_COM_WRITE_MPX response to determine which client requests, if any, MUST be retransmitted. The client MUST use this behavior to send only the missing parts in the next write sequence when resending the lost requests.
When all of the request messages have been successfully received by the server, and a final SMB_COM_WRITE_MPX response received, the client MAY perform another write operation using the SMB_COM_WRITE_MPX request. The next SMB_COM_WRITE_MPX sequence sent MUST use a new SMB Header SecurityFeatures.SequenceNumber value to uniquely identify the set of requests, or the server can incorrectly respond with the mask from the previous SMB_COM_WRITE_MPX command. The server MUST NOT impose any restrictions on the value of RequestMask, nor upon the order or contiguity of the requests being sent.
The FID MUST be identical in all requests in a given SMB_COM_WRITE_MPX exchange. The TID, PID, UID, MID, and CID MUST be identical in all requests and responses in a given SMB_COM_WRITE_MPX exchange.
Other requests MAY be issued on the same session while the SMB_COM_WRITE_MPX exchange is in progress.
An example dialog flow is:
Figure 9: Multiplexed Write request/response message flow
At the time of the request, the client designates the number of data bytes to be sent and passes this information to the server in TotalByteCount field of the request. The server MAY use this information to reserve buffer space.
Some systems provide no way for a process to block until the local file cache has actually flushed to the disk, but simply indicate that a flush has been scheduled and MUST complete soon. A server SHOULD nonetheless take steps to maximize the probability that the data is truly on disk before the client is notified.
Server support of this command is optional. If the server supports this command it MUST set the CAP_MPX_MODE (0x00000002) bit in the Capabilities field of the response to SMB Protocol negotiation. Support for MPX mode excludes support for SMB signing and RAW read/write SMBs.
This command is supported on connectionless transports only; consequently, bit 0x0080 of WriteMode in all request messages in the exchange MUST be set. The FID in the request(s) MUST refer to either a regular file or a spooled printer file. This command does not support named pipes or I/O devices.