Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
The MSDTC Connection Manager: OleTx Multiplexing Protocol (CMP) allows partners to multiplex any number of two-way connections over the transport session between them, as specified in [MS-CMPO]. To do this, this protocol defines a small number of messages to manage connections and uses the transport protocol resource requests to allocate connection-related resources. To facilitate higher-level protocols, this protocol defines a single user message and allows associating a connection type with a connection.
To illustrate these concepts, the following figure depicts typical messages of this protocol to initiate, use, and terminate two connections between partners labeled A and B.
Figure 1: Messages used to manage two connections between partners
As the first message of the preceding figure depicts, to initiate a connection, either partner sends a Connect message (MTAG_CONNECTION_REQ) to the other partner over their session.
A Connect message includes an identifier for the new connection (abbreviated ID in the figure). To simplify connection management, connections are identified by two pieces of information: the partner that initiated the connection and an identifier assigned by that partner. This scheme allows each partner to assign identifiers without the risk of collision with the other partner. In effect, each partner maintains two tables of connections: those initiated by itself (called "outgoing" connections) and those initiated by the other partner (called "incoming" connections). Either partner has the option to send messages to the other by using any open connection. To correlate a message with its connection, the message includes a flag (fIsMaster) indicating which table the connection belongs to, in addition to the initiator-assigned identifier (dwConnectionId) for the connection.
Though not depicted in the figure, a Connect message also includes a type to identify the higher-level protocol for the connection's messages. Specifically, this connection type typically implies which types of User messages are expected over the connection.
As depicted in the preceding figure, a Connect message is assumed to succeed. If the receiving partner does not want to accept the connection, it sends a not-acknowledged message (MTAG_CONNECTION_REQ_DENIED).
After a connection is open, either partner has the option to send any number of User messages (MTAG_USER_MESSAGE) to the other partner by using that connection. User messages include their connection, a message type handled by a higher-level protocol, and the message payload. As the receiving partner never sends positive acknowledgment to a Connect message, the sending partner is free to send User messages to the connection along with the Connect message. If the receiving partner does not accept the connection, it will ignore these extraneous User messages.
A partner receives messages in the order in which they were sent over the connection.
To close a connection, the partner that initiated the connection sends a Disconnect message (MTAG_DISCONNECT) to the other partner; either partner has the option to initiate a connection, but only the partner that initiated a connection is allowed to close it. Unlike the Connect message, the Disconnect message is assumed to fail. As the preceding figure depicts, if the receiving partner has the option to close the connection, it does so and sends a Disconnect acknowledgment message (MTAG_DISCONNECTED). Finally, on receipt of the Disconnected message, the initiating partner closes the connection on its side. This asymmetric design allows the receiving partner to send any outstanding messages to the initiating partner before acknowledging the Disconnect message.
For efficiency, the CMP batches messages by using Boxcar objects (section 3.1.1.2) that contain one or more messages for one or more connections. A Boxcar includes the number of messages it encloses, their total size, and the messages themselves. Typically, the fact that messages are enclosed in a Boxcar is transparent to connection management and User messages in the CMP. One exception occurs when a partner receives an unrecognized message type and discards the rest of the messages in the Boxcar.