Making an Endpoint-to-Endpoint Connection
TDI clients on separate nodes of the network and their respective transports cooperate to establish an endpoint-to-endpoint connection between them. Before such a connection can be attempted, each client on its own node must do the following:
Open a transport address, as described in Opening a Transport Address.
Open a connection endpoint, as described in Opening a Connection Endpoint.
Associate its open connection with the open address by submitting a TDI_ASSOCIATE_ADDRESS IOCTL request to its underlying transport, as mentioned in Opening a Connection Endpoint and described in Packaging and Submitting IOCTL Requests.
Then, one of the clients makes a connection offer to the other, while the other usually listens (passively) for the connection offer to come in.
Either client also might have registered its ClientEventConnect handler with its underlying transport (see Opening a Transport Address). The transport driver calls ClientEventConnectwhen any connection offer directed to its client's open transport address comes in from a remote node.
Requesting a Connection to a Remote Node
The following figure shows how a local-node TDI client initiates a connection offer to a remote-node peer process.
.png)
The local-node client makes a connection offer to a remote-node peer process by submitting a TDI_CONNECTrequest, set up with TdiBuildConnect, to its underlying transport.
The local-node transport determines the client-specified target remote-node address from its client's connect request and transmits the connection offer to the corresponding remote-node transport.
The remote-node transport notifies its client of the incoming connection offer, either by satisfying a TDI_LISTEN request previously submitted by its client or by calling the previously registered ClientEventConnect handler.
The local-node transport fails the connect IRP if the remote-node client is not listening or if the remote-node transport does not respond. The remote-node client can accept or reject the offered connection if both transports support delayed-connection acceptance, as described next.
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).
Accepting a Connection Offer from a Remote Node
The following figure shows how a local-node client listens for a connection offer from a remote-node peer process.
.png)
To establish an endpoint-to-endpoint connection, one client makes a connection offer, and the other indicates to its underlying transport that it is waiting for a connection offer to occur.
A local-node client can passively listen for such an incoming connection offer by submitting a TDI_LISTENrequest, set up with TdiBuildListen, to its underlying transport. The client can specify the remote-node transport address from which an acceptable offer can occur when it sets up the listen IRP. If the transports support delayed-connection acceptances, the client can direct the transport to either accept an offer from a particular remote-node address immediately or allow the client to inspect the offer and decide whether to accept it.
When the transport receives a TDI_LISTEN request, it monitors connection offers coming from remote nodes that are directed to the transport address opened by the client. When it receives such a connection offer from an acceptable remote-node address, the transport copies information transmitted with the offer into a buffer the local-node client supplied with its TDI_LISTEN request and completes the IRP back to the listening client.
If the client directed the transport to accept the incoming connection offer immediately, completion of the listen request occurs as the transport notifies the remote-node transport that an endpoint-to-endpoint connection has been established with the remote-node client. In effect, the local-node client has made an endpoint-to-endpoint connection with its remote-node peer even before it "knows" that its listen IRP has been completed, and the local-node client can receive data on that endpoint-to-endpoint connection at once. Otherwise, the transport's completion of the listen request notifies the local-node client of the offer to connect, and the client either accepts or rejects the request by issuing a TDI_ACCEPTor TDI_DISCONNECTrequest, respectively. The local-node client uses TdiBuildAcceptor TdiBuildDisconnectto set up the IRP it submits to its underlying transport for a delayed-connection acceptance operation.
Accepting a connection is even simpler if the local-node client is using event handling to communicate with the underlying TDI transport driver. When its transport receives a connection offer from a remote-node client that is directed to the open transport address of the local-node client, the transport calls the registered ClientEventConnecthandler of the local-node client, passing in the transport address of the offering client and any connect data the transport received with the connection offer. ClientEventConnect then accepts or rejects the connection offer immediately.
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).