|Skip Navigation Links|
|Exit Print View|
|Programming Interfaces Guide Oracle Solaris 11.1 Information Library|
The tables in the following sections describe all state transitions associated with XTI/TLI.
The following table defines the states used in XTI/TLI state transitions, along with the service types.
Table 8-1 XTI/TLI State Transitions and Service Types
The outgoing events described in the following table correspond to the status returned from the specified transport routines, where these routines send a request or response to the transport provider. In the table, some events, such as “accept,” are distinguished by the context in which they occur. The context is based on the values of the following variables:
ocnt – Count of outstanding connect requests
fd – File descriptor of the current transport endpoint
resfd – File descriptor of the transport endpoint where a connection is accepted
Table 8-2 Outgoing Events
The incoming events correspond to the successful return of the specified routines. These routines return data or event information from the transport provider. The only incoming event not associated directly with the return of a routine is pass_conn, which occurs when a connection is transferred to another endpoint. The event occurs on the endpoint that is being passed the connection, although no XTI/TLI routine is called on the endpoint.
In the following table, the rcvdis events are distinguished by the value of ocnt, the count of outstanding connect requests on the endpoint.
Table 8-3 Incoming Events
The state tables describe the XTI/TLI state transitions. Each box contains the next state, given the current state (column) and the current event (row). An empty box is an invalid state/event combination. Each box can also have an action list. Actions must be done in the order specified in the box.
You should understand the following when studying the state tables:
t_close(3NSL) terminates an established connection for a connection-oriented transport provider. The connection termination will be either orderly or abortive, depending on the service type supported by the transport provider. See the t_getinfo(3NSL) man page.
If a transport user issues a interface call out of sequence, the interface fails and t_errno is set to TOUTSTATE. The state does not change.
The error codes TLOOK or TNODATA after t_connect(3NSL) can result in state changes. The state tables assume correct use of XTI/TLI.
Any other transport error does not change the state, unless the man page for the interface says otherwise.
The support interfaces t_getinfo(3NSL), t_getstate(3NSL), t_alloc(3NSL), t_free(3NSL), t_sync(3NSL), t_look(3NSL), and t_error(3NSL) are excluded from the state tables because they do not affect the state.
Some of the state transitions listed in the tables below offer actions the transport user must take. Each action is represented by a digit derived from the list below:
Set the count of outstanding connect requests to zero
Increment the count of outstanding connect requests
Decrement the count of outstanding connect requests
Pass a connection to another transport endpoint, as indicated in thet_accept(3NSL) man page
The following table shows endpoint establishment states.
Table 8-4 Connection Establishment State
The following table shows data transfer in connection mode.
Table 8-5 Connection Mode State: Part 1
The following table shows connection establishment/connection release/data transfer in connection mode.
Table 8-6 Connection Mode State: Part 2
The following table shows connectionless mode states.
Table 8-7 Connectionless Mode State