Network applications that are either system-provided or developed in-house, require a programming interface to the network, such as Transmission Control Protocol/Internet Protocol (TCP/IP). The transport level programming interface provides application developers a means of getting to the network protocols without requiring the knowledge of protocol-specific semantics, the framework which the protocols are loaded, or the complexity of kernel interfaces.
Two libraries are provided for accessing well-known protocols such as TCP/IP. These libraries are:
These library interfaces are provided in addition to the existing socket system calls. Generally speaking, well-known protocols, such as TCP/IP and Open Systems Interconnection (OSI), are divided into two parts:
AIX supplies the socket-based TCP/IP protocol suites as a part of the base system. It also supplies the socket system calls and socket library calls (libc.a) for the existing application which have been developed using the sockets applications programming interface (API).
TLI is a library that is used for porting applications developed using the AT&T System V-based UNIX operating systems.
XTI is a library implementation, as specified by X/OPEN CAE Specification of X/Open Transport Interface and fully conformant to X/OPEN XPG4 Common Application Environment (CAE) specification. that defines a set of transport-level services that are independent of any specific transport provider's protocol or its framework.
The purpose of XTI is to provide a universal programming interface for the transport layer functions regardless of the transport layer protocols, how the framework of the transport layer protocols are implemented, or the type of UNIX operating system. For example, an application which writes to XTI should not have to know that the service provider is written using STREAMS or sockets. The application accesses the transport end point (using the returned handle, fd, of the t_open subroutine) and requests and receives indications from the well-known service primitives. If desired or necessary, applications can obtain any protocol-specific information by calls to the t_info subroutine.
Both TLI and XTI are implemented using STREAMS. This implementation includes the following members:
The TLI (libtli.a) and XTI (libxti.a) libraries are shared libraries. This means that applications can run without recompiling, even though the system may update the libraries in the future.
The TLI and XTI calls syntax is similar. For the most part, XTI is a superset of TLI in terms of definitions, clarification of usage, and robustness of return codes. For specific XTI usage and return codes see X/OPEN CAE Specification of X/Open Transport Interface and the "List of X/Open Transport Interface Library Subroutines."
TLI and XTI are the interfaces for providing the transport layer services. The semantics of these interfaces closely resemble those of sockets. Some of the characteristics of the interfaces are:
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.
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).
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 action required for client requests.
The following tables list the typical sequence of calls a user must issue for various connection types.
Note: These tables are provided as examples of typical sequences, rather than the exact order in which the transport providers are required.
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() |
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() |