|
|
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:
Either user may call t_snddis to generate an abortive release. Also, the transport provider may abort a connection if a problem occurs below the Transport Interface. t_snddis enables a user to send data to the remote user when aborting a connection. Although 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, t_rcvdis must be called to retrieve the disconnect indication. This call returns a reason code that identifies why the connection was aborted, and returns any user data that may have accompanied the disconnect indication (if the abortive release was initiated by the remote user). This reason code is specific to the underlying transport protocol, and should not be interpreted by protocol-independent software.
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");
exit(27);
}
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(2) 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'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");
exit(6);
}
if (t_sndrel(fd) < 0) {
t_error("t_sndrel failed");
exit(7);
}
exit(0);
}
t_error("t_rcv failed");
exit(8);
}
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.