Content-type: text/html Man page of xti

xti

Section: Environments, Tables, and Troff Macros (7)
Index Return to Main Contents
 

NAME

xti - General information on XTI.  

DESCRIPTION

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 TCP and UDP, see the xti_internet(7) reference page. Those corresponding to commonly used subsets of higher-layer protocols that provide transport-like services, such as: Minimal fuctionality OSI (mOSI), that is, OSI ACSE/Presentation with the kernel and duplex functional units SNA LU6.2 subset Mixed-protocol providers that provide the appearance of one protocol over a different protocol, such as: ISO transport appearance (connection-oriented) over TCP

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.  

DEFINITIONS

This section provides definitions of XTI-related terms and concepts.  

Transport Endpoints

A transport endpoint specifies a communication path between a transport user and a specific transport provider, which is identified by a local file descriptor (fd). When you open a transport provider identifier, a local fd is returned which identifies the transport endpoint. A transport provider is defined to be the transport protocol that provides the services of the transport layer. All requests to the transport provider must pass through a transport endpoint. The fd is returned by the function t_open and is used as an argument to the subsequent functions to identify the transport endpoint. A transport endpoint (an fd and local address) can support only one established transport connection at a time.

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.  

Transport Providers

The transport layer may comprise one of more transport providers at the same time. The identifier parameter of the transport provider passed to the t_open function determines the required transport provider. To keep the applications portable, the identifier parameter of the transport provider should not be hard-coded into the application source code.

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.  

Association of a UNIX Process to an Endpoint

One process can simultaneously open several file descriptors. However, in synchronous mode, the process must manage the different actions of the associated transport connections sequentially. Conversely, several processes can share the same fd (by fork or dup operations) but they have to synchronize themselves to avoid issuing a function that is unsuitable to the current state of the transport endpoint.

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.  

Use of the Same Protocol Address

If several endpoints are bound to the same protocol address, only one at a time can be listening for incoming connections. However, others can be in data transfer state or establish a transport connection as initiators.  

Modes of Service

The transport service interface supports two modes of service: connection mode and connectionless mode. A single transport endpoint cannot support both modes of services simultaneously.

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.  

Error Handling

Two levels of error are defined for the transport interface. The first is the library error level. Each library function has one or more error returns. Failures are indicated by a return value of -1. An external integer, t_errno, which is defined in the header file <xti.h>, holds the specific error number when such a failure occurs. This value is set when errors occur but it is not cleared on successful library calls, so it should be tested only after an error has been indicated. A diagnostic function, t_error, prints out information on the current transport error. The state of the transport provider may change if a transport error occurs.

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.  

Synchronous and Asynchronous Execution Modes

The transport service interface is inherently asynchronous; various events can occur that are independent of the actions of a transport user. For example, a user may be sending data over a transport connection when an asynchronous disconnect indication arrives. The user must be informed that the connection has been broken.

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.  

Events and States in XTI

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  

XTI OPTIONS

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.  

RELATED INFORMATION

t_optmgmt(3), xti_internet(7)

Network Programmer's Guide, X/Open CAE Specification: Networking Services, Issue 4 delim off


 

Index

NAME
DESCRIPTION
DEFINITIONS
Transport Endpoints
Transport Providers
Association of a UNIX Process to an Endpoint
Use of the Same Protocol Address
Modes of Service
Error Handling
Synchronous and Asynchronous Execution Modes
Events and States in XTI
XTI OPTIONS
RELATED INFORMATION

This document was created by man2html, using the manual pages.
Time: 02:40:19 GMT, October 02, 2010