TLI and XTI Characteristics
TLI and XTI are the interfaces for providing the transport layer services.
- Transport end points - A transport end point specifies
a communication path between a transport user and a specific transport
provider. Similar to the socket subroutine (which returns the
file descriptor, s), calls to the TLI and XTI t_open subroutines return the file descriptor, fd, as a handle to
be used with subsequent calls.
A transport end point can support only one established transport connection at a time, though a transport provider, such as TCP/IP, serves the multiple transport end points. To activate and bind the local transport port, a transport end point must have a transport address associated with it by t_bind subroutine calls. To make a end-to-end connection between two active transport end points, the t_connect subroutine must follow. For a transport end point that needs a connectionless service, such as User Datagram Protocol/Internet Protocol (UDP/IP), a connect phase is skipped and the t_rcvudata subroutine can be called after the t_bind subroutine is issued.
- Ownership of transport end points - Once a transport end
point is acquired from the transport provider (by getting the file
descriptor, fd, from the t_open calls), the handle as
specified by fd can be shared by multiple processes, such as
the fork subroutine. However, the transport provider treats
the processes sharing the same fd as a single return point.
These processes must coordinate their activities to not violate the
state of provider.
The t_sync subroutine calls return the state of the transport provider, allowing users to verify the transport provider state before taking further action. An application that wants to manage multiple transport providers, such as a server application, must call the t_open subroutine for each provider. For example, a server application that is waiting for incoming connect indications from several transport providers, such as TCP/IP and OSI, must open multiple t_open subroutines and listen for connection indications on each of the associated handles (fd).
- Synchronous and asynchronous execution of calls - TLI and
XTI provide synchronous and asynchronous execution of calls. In the
synchronous mode of operation, the calls block until a specific event
is satisfied. Synchronous mode is the default mode of operation. In
the asynchronous mode of operation (t_open subroutine with
the O_NONBLOCK flag set), the call is returned immediately
and the specified event is notified by either or both the poll and select system calls some time later.
Users are advised to choose a mode of execution based on the nature of its function. For example, a typical server application should exploit the asynchronous execution to facilitate multiple concurrent actions required for client requests.
- Event Management - For connection-oriented mode, it is important for users to know the state of the current connection or the change of any state caused by calls issued to that state. The TLI and XTI event management allows the state of event either by return code (TLOOK) or a call (t_look subroutine) to request the current state information.
The following tables list the typical sequence of calls a user must issue for various connection types.
Connection oriented calls:
| Server | Client |
|---|---|
| t_open() | t_open() |
| | | | |
| t_bind() | t_bind() |
| | | | |
| t_alloc() | t_alloc() |
| | | | |
| t_listen() | t_connect() |
| : | <—————————-: |
| : | : |
| t_accept() | : |
| | | : |
| t_rcv()/t_snd() | t_snd()/t_rcv() |
| | | | |
| t_snddis()/t_rcvdis() | t_rcvdis()/t_snddis() |
| | | | |
| t_unbind() | t_unbind() |
| | | | |
| t_close() | t_close() |
Connectionless calls:
| Server | Client |
|---|---|
| t_open() | t_open() |
| | | | |
| t_bind() | t_bind() |
| | | | |
| t_alloc() | t_alloc() |
| | | | |
| t_rcvudata()/t_sndudata | t_sndudata/t_rcvudata |
| | | | |
| t_unbind() | t_unbind() |
| | | | |
| t_close() | t_close() |