2.1.2.1 Direct IPX Transport
Direct IPX Transport (also known as Direct Hosting IPX) carries CIFS over IPX protocol without the use of the NetBIOS interface layer.
Unlike other transport protocols used with CIFS, the Direct IPX Transport protocol is asymmetric. Wherever possible, processing is moved from the server to the client so that the server can scale to a large number of clients efficiently. For example, the server does not initiate retransmission of lost responses. It is entirely up to the client to resend the request in the case of lost packets in either direction.
IPX is also a connectionless protocol, so CIFS itself provides mechanisms for ensuring sequential delivery of messages between the client and server, and for detecting and recovering from failures of either the client node or server node. To accomplish these goals, the SMB Header (section 2.2.3.1) is modified to include a connection identifier (CID) and a sequence number (SequenceNumber). The CID value is generated by the server and returned to the client in the SMB_COM_NEGOTIATE Response (section 2.2.4.52.2). The client MUST use this CID in all future SMB exchanges with this server during this resource sharing session.
The SequenceNumber value is provided by the client. If the sequence number is zero, the command is known as an "unsequenced command" and the client MUST use the PID and MID fields to match a response message to the client process that generated the request. In particular, the client MUST ensure that it never has more than one distinct outstanding unsequenced request with the same MID.
Sequenced commands have nonzero SequenceNumber values. Sequenced commands are used for operations that cause state changes on the server which cannot be repeated. For example, file open, file close, or byte-range locking. Unsequenced commands are used for operations that can be performed as many times as necessary with the same result each time. For example, reading or writing to a disk file.
CIFS servers using Direct IPX Transport MUST maintain a small buffer for each client. This buffer is used to temporarily store the response information from the most recent sequenced command. If the client does not receive a response to a sequenced request it SHOULD resend the request. If the server has already processed the request, the response MUST still be in the buffer and can be resent. If the server did not receive the original request, it is able to process the retransmitted request. When the client sends the next sequenced command request, it signals that the previous sequenced response was received and that the buffer can be reused.
Because of the asymmetric nature of the Direct IPX Transport, the server allocates a limited amount of space for the response buffer. Therefore, the client MUST send all commands that have a "large" response size as unsequenced. Such commands include file read and directory search operations. If the response to a sequenced command is too large for the response buffer, the server MUST fail the request with ERRSRV/ERRerror.
SMB Transactions are capable of transferring large amounts of data from the server to the client. Transactions can be used to change server state and so MUST NOT be sent as unsequenced commands. There are ways for clients to organize the commands to work around this limitation. Transactions can contain multi-part requests and/or multi-part responses. The sizes of the response messages can be adjusted to fit within the response buffer. Therefore, SMB Transactions are handled as a set of sequenced commands.
Section 3.2.4.1.5 describes SMB Transactions as used over connection-oriented transports. Transaction processing is modified when CIFS is carried over a connectionless transport, such as Direct IPX Transport.
When transactions are carried over a connectionless transport, each request message is sent as a sequenced command. Each message MUST have a consistent MID value and a nonzero SequenceNumber value that increases by one with each new message in the transaction. The server MUST respond to each request message, except the last one, with a response indicating that the server is ready for the next secondary request. For the initial transaction request message and all subsequent transaction secondary requests, except for the last request message, the server MUST send an interim response.
Figure 1: CIFS transaction messages over connectionless transport
When the last transaction request has been received by the server, the server MUST respond with a final response message, as described in section 3.2.4.1.5. However, if the there are multiple final response messages, then the client MUST respond to each of the final response messages, except the last one, by sending an empty secondary request message. No parameters or data are transferred to the server in these messages. They are used only as acknowledgments to indicate that the response message has been received. These acknowledgment messages contain the following information:
ParameterDisplacement is set to the number of parameter bytes that the client has received from the server so far in this transaction.
DataDisplacement is set to the number of data bytes that the client has received from the server so far in this transaction.
ParameterCount, ParameterOffset, DataCount, and DataOffset MUST be set to zero.
When the transaction has been completed, the client MUST send another sequenced command to the server. This indicates to the server that all of the transaction final response messages have been received and that the parameter and data transfer is complete. Resources allocated to the transaction command can then be released by the server.
Figure 2: CIFS transaction completion messages over connectionless transport
For sequenced commands, the server requires that the sequence numbers are nonzero, start at 1, and increase by one for each new sequenced command. At 65535 (216 - 1), the sequence wraps to 0x0001, not 0x0000. Sequenced command requests that have an incorrect sequence number MUST be ignored.
If the CID value is incorrect, the server MUST fail the request with ERRSRV/ERRinvsess. If the server is currently processing a command that matches either the sequence number (for sequenced commands) or the MID (for unsequenced commands) of a new request, the server MUST respond with ERRSRV/ERRworking. The values of ERRinvsess (0x0010) and ERRworking (0x0011) are defined only for the Direct IPX Transport.
The server waits to receive commands from the client periodically; if no commands are received, the server treats the client as no longer running and closes the SMB session. This includes closing file handles and releasing any resources allocated on behalf of the client. Clients SHOULD, at minimum, send an SMB_COM_ECHO (section 2.2.4.39) to the server every few minutes. The server MUST NOT disconnect clients that have been inactive less than 5 minutes.<6>
Direct IPX Transport can be used in situations in which multiple low-bandwidth connections are multiplexed together (for example, by using multiple telephone modems in parallel). CIFS provides special SMB commands, such as SMB_COM_READ_MPX (section 2.2.4.23), for these environments. These commands, and the Direct IPX Transport itself, are obsolescent.
See [MSFT-IPXWAN] for more information on Direct IPX Transport.