Connection Release

At any time during data transfer, either user can release the transport connection and end the conversation. There are two forms of connection release.

• The first way, abortive release, breaks the connection immediately and discards any data that has not been delivered to the destination user.

  Either user can call t_snddis(3NSL) to perform an abortive release. The transport provider can abort a connection if a problem occurs below XTI/TLI. t_snddis(3NSL) lets a user send data to the remote user when aborting a connection. The abortive release is supported by all transport providers, the ability to send data when aborting a connection is not.

  When the remote user is notified of the aborted connection, call t_rcvdis(3NSL) to receive the disconnect request. The call returns a code that identifies why the connection was aborted, and returns any data that can have accompanied the disconnect request (if the abort was initiated by the remote user). The reason code is specific to the underlying transport protocol, and should not be interpreted by protocol-independent software.

• The second way, orderly release, ends a connection so that no data is lost. All transport providers must support the abortive release procedure, but orderly release is an option not supported by all connection-oriented protocols.

See "Transport Selection" for information on how to select a transport that supports orderly release.

Server

This example assumes that the transport provider supports orderly release. When all the data has been sent by the server, the connection is released as follows:

if (t_sndrel(conn_fd) == -1) {
   t_error("t_sndrel failed");
   exit(27);
}
pause(); /* until orderly release request arrives */

Orderly release requires two steps by each user. The server can call t_sndrel(3NSL). This routine sends a disconnect request. When the client receives the request, it can continue sending data back to the server. When all data have been sent, the client calls t_sndrel(3NSL) to send a disconnect request back. The connection is released only after both users have received a disconnect request.

In this example, data is transferred only from the server to the client. So there is no provision to receive data from the client after the server initiates release. The server calls pause(2) after initiating the release.

The client responds with its orderly release request, which generates a signal caught by connrelease(). (In Example 3-7, the server issued an I_SETSIG ioctl(2) to generate a signal on any incoming event.) The only XTI/TLI event possible in this state is a disconnect request or an orderly release request, so connrelease exits normally when the orderly release request arrives. exit(2) from connrelease closes the transport endpoint and frees the bound address. To close a transport endpoint without exiting, call t_close(3NSL).

Client

The client releases the connection similar to the way the server releases it. The client processes incoming data until t_rcv(3NSL) fails. When the server releases the connection (using either t_snddis(3NSL) or t_sndrel(3NSL)), t_rcv(3NSL) fails and sets 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) == -1) {
      t_error("t_rcvrel failed");
      exit(6);
 	}
 	if (t_sndrel(fd) == -1) {
      t_error("t_sndrel failed");
      exit(7);
 	}
 	exit(0);
 }

Each event on the client's transport endpoint is checked for an orderly release request. When one is received, the client calls t_rcvrel(3NSL) to process the request and t_sndrel(3NSL) to send the response release request. The client then exits, closing its transport endpoint.

If a transport provider does not support the orderly release, use abortive release with t_snddis(3NSL) and t_rcvdis(3NSL). Each user must take steps to prevent data loss. For example, use a special byte pattern in the data stream to indicate the end of a conversation.