xti - General information on XTI.
The X/Open Transport Interface (XTI) specification defines an independent transport-service interface that allows multiple users to communicate at the transport level of the Open Systems Interconnect (OSI) reference model (other transport providers are also supported). The specification describes transport-layer characteristics that are supported by a wide variety of transport-layer protocols. Supported characteristics include: Connection establishment State change support Event handling Data transfer Option manipulation
Although all transport-layer protocols support these characteristics, they vary in their level of support and their interpretation and format. For example, there are transport-level options that remain constant across all transport providers while there are other options that are transport-provider specific or have different values or names for different transport providers.
While XTI gives transport users considerable independence from the underlying transport provider, the differences between providers are not entirely hidden. You can write transport-provider-independent software primarily by using only functions supported by all providers, avoiding option management, and using a provider-independent means of acquiring addresses.
Transport providers can be divided into the following categories: Those corresponding to traditional transport providers, such as: ISO Transport (connection-oriented or connectionless) TCP UDP NetBIOS
For more information on XTI, see the X/Open CAE Specification, Networking Services, Issue 4, Network Programmer's Guide , and the reference pages for the XTI functions.
This section provides definitions of XTI-related terms and concepts.
To be active, a transport endpoint must have a transport address associated with it by the t_bind function. A transport connection is characterized by the association of two active endpoints. This association is made by using the functions of establishment of transport connection. The fd is a communication path to a transport provider. There is no direct assignation of the processes to the transport provider, so multiple processes, which obtain the fd by open, fork, or dup operation, may access a given communication path. Note that the open function works only if the opened character string is a pathname.
Note that, to guarantee portability, the only operations that the applications can perform on any fd returned by t_open are those defined by XTI and fcntl, dup, or dup2. Any other operations will have system-dependent results.
An application that wants to manage multiple transport providers must call t_open for each provider. For example, a server application that is waiting for incoming connect indications from several transport providers must open a transport endpoint for each provider and listen for connect indications on each of the associated fds.
It is important to remember that the transport provider treats all users of a transport endpoint as a single user. If multiple processes are using the same endpoint, they should coordinate their activities so as not to violate the state of the provider. The t_sync function returns the current state of the provider to the user, thereby enabling the user to verify the state before taking further action. This coordination is only valid among cooperating processes; it is possible that a process or an incoming event could change the provider's state after a t_sync is issued.
A process can listen for an incoming connect indication on one fd and accept the connection on a different fd which has been bound with the qlen parameter (see t_bind) set to zero. This facilitates the writing of a listener application whereby the listener waits for all incoming connect indications on a given Transport Service Access Point (TSAP). The listener accepts the connection on a new fd and forks a child process to service the request without blocking other incoming connect indications.
The connection-mode transport service is circuit-oriented and enable data to be transferred over an established connection in a reliable, sequenced manner. This service enables the negotiation of the parameters and options that govern the transfer of data. It provides and identification mechanism that avoids the overhead of address transmission and resolution during the data transfer phase. It also provides a context in which successive units of data, transferred between peer users, are logically related. This service facilitates applications that require relatively long-lived, data stream-oriented interactions.
In contrast, the connectionless-mode transport service is message-oriented and supports data transfer in self-contained units with no logical relationship required among multiple units. These units are also known as datagrams. This service requires a preexisting association between the peer users involved, which determines the characteristics of the data to be transmitted. No dynamic negotiation of parameters and options is supported by this service. All the information required to deliver a unit of data (for example, destination address) is presented to the transport provider, together with the data to be transmitted, in a single service access which need not relate to any other service access. Also, each unit of data transmitted is entirely self-contained, and can be independently routed by the transport provider. This service is attractive to application that involve short-term request and response interactions, exhibit a high level of redundancy, are dynamically reconfigurable, or do not require guaranteed, in-sequence delivery of data.
The second level of error is the operating system service routine lever. A special library level error number has been defined called TSYSERR which is generated by each library function when an operating system service routine fails or some general error occurs. When a function sets t_errno to TSYSERR, the specific system error may be accessed through the external variable errno.
For example, a system error can be generate by the transport provider when a protocol error has occurred. If the error is severe, it may cause the file descriptor and transport endpoint to be unusable. To continue in this case, all users of the fd must close it. Then the transport endpoint may be reopened and initialized.
The transport service interface supports two execution modes for handling asynchronous events: synchronous mode and asynchronous mode. In the synchronous mode of operation, the transport primitives wait for specific events before returning control to the user. While waiting, the user cannot perform other tasks. For example, a function that attempts to receive data in synchronous mode waits until data arrives before returning control to the user. Synchronous mode is the default mode of execution. It is useful for user processes that maintain only a single transport connection. Note that if a signal arrives, blocking calls are interrupted and return a negative return code with t_errno set to TSYSERR and errno set to EINTR. In this case the call will have no effect.
The asynchronous mode of operation provides a mechanism for notifying a user of some event without forcing the user to wait for the event. The handling of networking events in an asynchronous manner is a desirable capability of the transport interface. This enables users to perform useful work while waiting for a particular event. For example, a function that attempts to receive data in asynchronous mode immediately returns control to the user if no data is available. The user can then periodically poll for incoming data until it arrives. The asynchronous mode is intended for those applications that expect long delays between events and have other tasks that they can perform in the meantime or handle multiple connections concurrently.
The two execution modes are not provided through separate interfaces or different functions. Instead, functions that process incoming events have two modes of operation: synchronous and asynchronous. The desired mode is specified through the O_NONBLOCK flag, which can be set when the transport provider is initially opened, or at any time after opening using the fcntl operating system service routine. The effect of this flag is local to this process and is completely specified in the description of each function.
A process that issues functions in synchronous mode must still be able to recognize certain asynchronous events and act on them, if necessary. This is handled through a special transport error, TLOOK, which is returned by a function when an asynchronous event occurs. The t_look function is then invoked to identify the specific event that has occurred when this error is returned.
Another means to notify a process that an asynchronous event has occurred is polling. The polling capability enables processes to do useful work and periodically poll for one of the above asynchronous events. This facility is provided by setting O_NONBLOCK for the appropriate primitives.
All events that occur at a transport endpoint are stored by XTI. These events are retrievable one at a time using the t_look function. If multiple events occur, the order in which t_look returns the events is implementation-dependent. An event is outstanding on a transport endpoint until it is consumed. Every event has a corresponding consuming function that handles the event and clears it. For example, both T_DATA and T_EXDATA events are consumed when the corresponding consuming function has read all the corresponding data associated with that event. The intention is that T_DATA should always indicate that there is data to receive. Two events, T_GODATA and T_GOEXDATA, are also cleared as they are returned by t_look. For more information, see the Network Programmer's Guide.
Nine (eight, if orderly release is not supported) asynchronous events are defined in the transport service interface to cover both connection-mode and connectionless-mode service. They are represented as separate bits in a bit-mask using the following defined symbolic names: T_LISTEN T_CONNECT T_DATA T_EXDATA T_DISCONNECT T_ORDREL T_UDERR T_GODATA T_GOEXDATA
XTI manages a transport endpoint by using the following states: T_UNINIT T_UNBND T_IDLE T_OUTCON T_INCON T_DATAXFER T_INREL T_OUTREL
The T_OUTREL and T_INREL states are significant only if the optional orderly release function is both supported and used. These are described in more detail in the Network Programmer's Guide.
Given a current state and event, the transition to the next state is shown, as well as any actions that must be taken by the transport user.
The following support function can be issued from any state except the uninitialized state: t_getprotaddr t_getstate t_getinfo t_alloc t_free t_look t_sync
The following functions contain an opt argument of the type struct netbuf as an input or output parameter. This argument is used to convey options between the transport user and the transport provider: t_accept t_connect t_listen t_optmgmt t_rcvconnect t_rcvudata t_rcvuderr t_sndudata
There is no general definition about the possible contents of options. There are general XTI options and those that are specific for each transport provider. Some options allow the user to tailor his communication needs, for instance by asking for high throughput or low delay. Others allow the fine-tuning of the protocol behavior so that communication with unusual characteristics can be handled more effectively. Other options are for debugging purposes.
All options have default values. Their values have meaning to and are defined by the protocol level in which they apply. However, their values can be negotiated by a transport user. This includes the simple case where the transport user can simply enforce its use. Often, the transport provider or even the remote transport user can have the right to negotiate a value of lesser quality than the proposed one, that is, a delay can become longer, or a throughput may become lower.
For more information on using XTI options, see the Network Programmer's Guide.
Network Programmer's Guide, X/Open CAE Specification: Networking Services, Issue 4 delim off