Figure 5.12 shows how TDI clients release an endpoint-to-endpoint connection.
Figure 5.12 Disconnecting an Endpoint-to-Endpoint Connection
Disconnection behavior is transport-specific in nature. Depending on the transport, when a connection-oriented TDI client initiates a disconnect between nodes, both nodes might need to participate in the disconnection operation. That is, when one client initiates a disconnect, the remote-node client possibly must respond to it.
During a disconnect operation, the TDI transport driver usually refuses incoming requests on the open connection endpoint and stops all activity at the specified connection endpoint unless both transports support controlled disconnects and the initiating client requests one.
As Figure 5.12 shows, one client on an endpoint-to-endpoint connection can initiate a disconnection operation by submitting a TDI_DISCONNECT request, set up with TdiBuildDisconnect, to its underlying transport. When that transport finishes processing the initiating client’s request, it notifies the remote-node transport driver that a disconnection is in progress, and this transport begins returning an appropriate status code for client-submitted I/O requests on the endpoint-to-endpoint connection.
If the responding client registered its ClientEventDisconnect handler, the TDI transport driver notifies the client when the disconnect occurs by calling this handler. Then, ClientEventDisconnect acknowledges the disconnection by making a TDI_DISCONNECT request to its underlying transport. This notification allows the responding client to clean up client-allocated state for the endpoint-to-endpoint connection promptly.
However, a disconnection operation does not close either client's open connection endpoints or transport addresses. After TDI_DISCONNECT requests have been satisfied, both clients can reuse the file objects representing these open resources in their underlying transports. For example, either client might make a subsequent connection offer to another remote node on the network, as already described in Section 5.5. Until each client closes the file objects representing its respective connection endpoint and the associated transport address as described in Section 5.12 and Section 5.13, respectively, these resources remain allocated to the client and available for client-submitted IOCTL requests to the underlying transport.