Communications Programming Concepts

Transport Service Library Interface Overview

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:

• Transport Library Interface (TLI)
• X/OPEN Transport Library Interface (XTI)

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:

• Transport layer and below are in the kernel space
• Session layer and above services are in the user space.

The operating system 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 applications 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:

• Transport Library - libtli.a
• X/OPEN Transport Library - libxti.a
• STREAMS driver - Sends STREAMS messages initiated from the XTI or TLI library to the sockets-based network protocol (as in the case of TCP/IP) or to other STREAMS drivers (as in the case of Netware).

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 the X/OPEN CAE Specification of X/Open Transport Interface and the list of X/Open Transport Interface Library Subroutines.

TLI and XTI Characteristics

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:

• 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.

Note: These tables are provided as examples of typical sequences, rather than the exact order in which the transport providers are required.

Connection oriented calls:

Connectionless calls: