Operation
TDI_DISCONNECT is a request message a client issues to indicate a disconnect request to close an established TDI connection or acknowledge connection closure by the remote node client.
Note TdiBuildDisconnect is the macro a client uses to fill in the IRP.
During a disconnect operation, the TDI driver refuses any incoming requests for the connection and stops all activity at the specified connection endpoint. However, the endpoint remains valid for reuse by the client. The client can provide a time-out value in a disconnect request and can specify several disconnect options, as described in the list below. If the client specifies no options, the operation defaults to the TDI_DISCONNECT_ABORT option. If the client specifies several options, the request fails without affecting the connection.
| Option | Meaning |
| TDI_DISCONNECT_ABORT | Specifies that the TDI driver should close the connection immediately without waiting for pending requests to finish. This option is the default. |
| The client can specify this option any time a connection is not idle. For example, the client might want to cancel a pending connect or listen operation. If an earlier disconnect request with the TDI_DISCONNECT_RELEASE option is pending on the connection, the client can issue another request for a second abnormal disconnect, which forces the connection closed immediately. | |
| TDI_DISCONNECT_ASYNC | Specifies an asynchronous disconnect request. The driver does not define the time when the connection will become available to the client. Therefore, the client should close the connection endpoint unless it knows by other means that the disconnect has finished. |
| TDI_DISCONNECT_RELEASE | Specifies that the TDI driver should initiate a controlled disconnect (see comments below). The remote node client also uses this option to confirm a controlled disconnect. |
| TDI_DISCONNECT_WAIT | Specifies that the client disconnect request is not causing a disconnect, but is acknowledging remote node client disconnection. This option is the only one for which the internal driver disconnect function writes disconnect data it has received from the remote node client, and possibly status information from the TDI driver. The local node client cannot retrieve disconnect data after it reuses the connection in a connect or listen request. |
Because the disconnect request takes time to complete, the connection can receive additional TSDUs before the Windows NT kernel formally completes the request. Therefore, the client assumes that the connection context is actually valid until the kernel positively notifies it of disconnect completion. Notification implies cessation of all activity (including receive indications) for the connection.
The client can also issue a disconnect request to reject an incoming request to connect. In this case, the client is responding to a completed listen operation (with TDI_QUERY_ACCEPT option) or receipt of a TDI_EVENT_CONNECT indication from the TDI driver at its ClientEventConnect function.
Along with the request message, the TDI client must provide input and output buffers for the IRP, as well as a status block structure the driver uses to write information about the request. These items are described below. For more information about the members of the IRP related to a disconnect request, see TdiBuildDisconnect.
Input
None
Output
None
I/O Status Block
The driver fills in the Status member of the IRP with one of the following TDI status codes:
STATUS_INVALID_CONNECTION
STATUS_PENDING
STATUS_REQUEST_TIMED_OUT
STATUS_SUCCESS
For more information about status codes, see Part II, Chapter 10.
Comments
By default, TDI_DISCONNECT provides a disconnect that is not controlled (meaning that it does not complete all outstanding requests normally before the internal driver disconnect function returns). Typically, the disconnect operation cancels outstanding requests, and the remote node client does not have to confirm the disconnect before the driver disconnect function is complete.
The local node client can request a controlled disconnect if the TDI driver supports it. In this case, the disconnect request informs the remote node or TDI_DISCONNECT client that it is closing the connection, and the client must confirm the disconnect before the driver disconnect function can return. The sequence of events for a controlled disconnect is:
1.The local node client makes a disconnect request with the TDI_DISCONNECT_RELEASE option selected. The client can no longer send data on the connection, but can continue to receive data. The TDI driver completes normally any send requests pending when the local node client makes its request.
2.The remote node TDI driver notifies the remote node client about the pending disconnect, either through a disconnect event or through an error code on an outstanding request. After notification, the remote node client can no longer receive data on the connection, but it can continue to send data. The remote node TDI driver completes any pending remote node client receive requests.
3.When the remote node client has finished sending data, it makes another disconnect request with the TDI_DISCONNECT_RELEASE option selected. All outstanding sends on the connection are completed normally. When the remote node driver disconnect function returns, the connection is closed from the point of view of the remote node client. The connection endpoint is still valid and the client can reuse it later.
4.The remote node TDI driver notifies the local node TDI driver to confirm the disconnect at the remote node. At this point, the disconnect request is completed for the local node and the connection closes from the point of view of the local node client. The connection endpoint is still valid and the client can reuse it.
See Also