5.5 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:

  1. Open a transport address, as already described in Section 5.1.

  2. Open a connection endpoint, as already described in Section 5.2.

  3. Associate its open connection with the open address by submitting a TDI_ASSOCIATE_ADDRESS IOCTL request to its underlying transport, as mentioned in Section 5.2 and described in Section 5.3.

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 Section 5.1). The transport driver calls ClientEventConnect when any connection offer directed to its client's open transport address comes in from a remote node.

Requesting a Connection to a Remote Node

Figure 5.5 shows how a local-node TDI client initiates a connection offer to a remote-node peer process.

Figure 5.5 Requesting a Connection

The local-node client makes a connection offer to a remote-node peer process by submitting a TDI_CONNECT request, 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.

Accepting a Connection Offer from a Remote Node

Figure 5.6 shows how a local-node client listens for a connection offer from a remote-node peer process.

Figure 5.6 Accepting a Connection (Listen Operation)

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_LISTEN request, 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 TDI_ACCEPT or TDI_DISCONNECT request, respectively. The local-node client uses TdiBuildAccept or TdiBuildDisconnect to 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 ClientEventConnect handler 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.