Programming with the X/Open Transport Interface (XTI)

Connection release

At any point during data transfer, either user may release the transport connection and end the conversation. As mentioned earlier, two forms of connection release are supported by the Transport Interface:

All transport providers must support the abortive release procedure, but orderly release is an optional facility that is not supported by all transport protocols.

The server

The client-server example in this section assumes that the transport provider supports the orderly release of a connection. When all the data has been transferred by the server, the connection may be released as follows:

   		if (t_sndrel(conn_fd) < 0) {
   			t_error("t_sndrel failed");
   		pause();	/* until orderly release indication arrives */
The orderly release procedure consists of two steps by each user. The first user to complete data transfer may initiate a release using t_sndrel, as illustrated in the example. This routine informs the client that no more data will be sent by the server. When the client receives this indication, it may continue sending data back to the server if desired. When all data have been transferred, however, the client must also call t_sndrel to indicate that it is ready to release the connection. The connection is released only after both users have requested an orderly release and received the corresponding indication from the other user.

In this example, data is transferred in one direction from the server to the client, so the server does not expect to receive data from the client after it has initiated the release procedure. Thus, the server simply calls pause(S) after initiating the release. Eventually, the remote user responds with its orderly release request, which generates a signal that will be caught by connrelease. Remember that the server earlier issued an I_SETSIG ioctl call to generate a signal on any incoming event. Since the only possible Transport Interface events that can occur in this situation are a disconnect indication or orderly release indication, connrelease terminates normally when the orderly release indication arrives. The exit call in connrelease will close the transport endpoint, freeing the bound address for another user. If a user process wants to close a transport endpoint without exiting, it may call t_close.

The client

The client's view of connection release is similar to that of the server. As mentioned earlier, the client continues to process incoming data until t_rcv fails. If the server releases the connection (using either t_snddis or t_sndrel), t_rcv will fail and set t_errno to TLOOK. The client then processes the connection release as follows:

   	if ((t_errno == TLOOK)  &&  (t_look(fd) == T_ORDREL)) {
   		if (t_rcvrel(fd) < 0) {
   			t_error("t_rcvrel failed");
   		if (t_sndrel(fd) < 0) {
   			t_error("t_sndrel failed");
   	t_error("t_rcv failed");
When an event occurs on the client's transport endpoint, the client checks whether the expected orderly release indication has arrived. If so, it proceeds with the release procedures by calling t_rcvrel to process the indication and t_sndrel to inform the server that it is also ready to release the connection. At this point the client exits, closing its transport endpoint.

Because not all transport providers support the orderly release facility just described, users may have to use the abortive release facility provided by t_snddis and t_rcvdis. However, steps must be taken by each user to prevent data loss. For example, a special byte pattern may be inserted in the data stream to show the end of a conversation. There are many possible routines for preventing data loss. Each application and high level protocol must choose an appropriate routine given the target protocol environment and requirements.

© 2005 The SCO Group, Inc. All rights reserved.
SCO OpenServer Release 6.0.0 -- 02 June 2005