TDI_ACCEPT
When a kernel-mode client makes a TDI_ACCEPT request, it asks the underlying TDI transport driver to accept an incoming connection offer from a remote-node peer and, thereby, to enable network data transfers on the endpoint-to-endpoint connection between that local-node client and its remote-node peer.
IRP
The transport calls IoGetCurrentIrpStackLocation with the given Irpto get a pointer to its own I/O stack location in the IRP, shown in the following list as IrpSp. The pointer to the IRP is shown in the following list as Irp. IRP members relevant to this request include the following:
Irp->IoStatus.Status
Specifies the final status of the accept request. The transport sets this member before it completes the IRP, possibly to one of the following:
STATUS_SUCCESS
STATUS_INVALID_CONNECTION
IrpSp->MajorFunction
Specifies IRP_MJ_INTERNAL_DEVICE_CONTROL. The transport can ignore this member if it exports a TdiDispatchInternalDeviceControl routine that handles only TDI_XXX requests.
IrpSp->MinorFunction
Specifies TDI_ACCEPT.
IrpSp->FileObject
Pointer to an open file object representing the connection endpoint at which a listen request has completed. The transport uses the FsContext and, possibly, FsContext2 fields to access the state it maintains about this connection.
IrpSp->Parameters
Specifies a TDI_REQUEST_KERNEL_ACCEPT structure, defined as follows:
struct _TDI_REQUEST_KERNEL_ACCEPT {
PTDI_CONNECTION_INFORMATION RequestConnectionInformation;
PTDI_CONNECTION_INFORMATION ReturnConnectionInformation;
} TDI_REQUEST_KERNEL_ACCEPT, *PTDI_REQUEST_KERNEL_ACCEPT;
The transport uses the members of this structure as follows:
RequestConnectionInformation
Pointer to a TDI_CONNECTION_INFORMATION structure, possibly containing connection information supplied by the client. This information can include a pointer (in the UserData member) to a buffer of client-supplied accept data to be sent to the remote node when the transport notifies the remote-node transport that the offered connection is accepted.ReturnConnectionInformation
Pointer to a client-supplied variable of type TDI_CONNECTION_INFORMATION in which the transport returns connection information, if any, to the client. This member is NULL if the transport does not return information for delayed-connection acceptances.
Comments
In normal operation, a client submits an accept request in response to a return from a preceding listen request in which it set the TDI_QUERY_ACCEPT flag. If the client did not set this flag in its TDI_LISTEN request for this connection, the transport should fail this accept request.
The transport can call already registered ClientEvent(Chained)Receive(Expedited) handlerbecause with incoming receives from the remote node on this connection before the I/O manager formally completes its processing of the client's accept IRP.
Most TDI transport drivers have a time-out feature to prevent communication sequences from hanging when a remote node is not responding. Therefore, a TDI client must either accept or reject a connection as soon as possible after completion of its listen request. As a general rule, a transport-determined time-out interval between client notification of an offered connection and the local-node client's connection acceptance or rejection should be less than one second.
TdiBuildAcceptis the macro a client uses to fill in this IRP.
Note The TDI feature is deprecated and will be removed in future versions of Microsoft Windows. Depending on how you use TDI, use either the Winsock Kernel (WSK) or Windows Filtering Platform (WFP). For more information about WFP and WSK, see Windows Filtering Platform and Winsock Kernel. For a Windows Core Networking blog entry about WSK and TDI, see Introduction to Winsock Kernel (WSK).
See Also
ClientEventChainedReceive, ClientEventChainedReceiveExpedited, ClientEventReceive, ClientEventReceiveExpedited, TdiBuildAccept, TDI_CONNECTION_INFORMATION, TdiDispatchInternalDeviceControl, TDI_LISTEN, TDI_RECEIVE
Requirements
Header |
TdiKrnl.h (include TdiKrnl.h) |