Previous section.

Transport Provider Interface (TPI), Version 2 Draft 2
Copyright © 1999 The Open Group


STREAMS-based Transport Provider Interface

The Transport Provider Interface (TPI) is an interface for drivers that provide transport services. The TPI defines the set of messages and their formats that the driver must generate/process.

This chapter introduces the STREAMS-based Transport Provider Interface (TPI). TPI is a service interface that maps to strategic levels of the Open Systems Interconnection (OSI) Reference Model. TPI supports the services of the Transport Layer for connection-mode and connectionless-mode services.

One advantage to using TPI is its ability to hide implementation details of a particular service from the consumer of the service. This enables system programmers to develop software independent of the particular protocol that provides a specific service.

This chapter focuses on TPI as it is defined within the STREAMS environment. Although there are no formal standards for a STREAMS environment, extensive descriptions of STREAMS and STREAMS programming can be found in the referenced document TPI_SMD.

How TPI Works

TPI defines a message interface to a transport provider implemented under STREAMS. A user communicates to a transport provider via a full duplex path known as a stream (see Example of a Stream from a User to a Transport Provider). This stream provides a mechanism in which messages may be passed to the transport provider from the transport user and vice versa.

Figure: Example of a Stream from a User to a Transport Provider
The STREAMS messages that are used to communicate between the transport user and the transport provider may have one of the following formats:

TPI Message Formats contains descriptions of the transport primitives which define both a connection-mode and connectionless-mode transport service. There are also primitives that pertain to both transport modes.

For each type of transport service, two types of primitives exist:

For the connection-mode transport service, a connection is associated with a single stream and, except while processing inbound connections, a stream will have at most one connection associated with it.

Transport Primitives lists the primitive types along with the mapping of those primitives to the STREAMS message types and the transport primitives of the ISO IS 8072 and IS 8072/DAD transport service definitions (see referenced documents). The format of these primitives and the rules governing the use of them are described in Allowable Sequence of TPI Primitives.

Overview of Error Handling Capabilities

There are two error handling facilities available to the transport user:

Non-fatal Errors

The non-fatal errors are those that a transport user can correct, and are reported in the form of an error acknowledgment to the appropriate primitive in error. Only those primitives which require acknowledgments may generate a non-fatal error acknowledgment. These acknowledgments always report a syntactical error in the specified primitive when the transport provider receives the primitive. The primitive descriptions above define those primitives and rules regarding the acknowledgment of them. These errors are reported to the transport user via the T_ERROR_ACK primitive, and give the transport user the option of reissuing the transport service primitive that caused the error. The T_ERROR_ACK primitive also indicates to the transport user that no action was taken by the transport provider on receipt of the primitive which caused the error.

These errors do not change the state of the transport service interface as seen by the transport user. The state of the interface after the issuance of a T_ERROR_ACK primitive should be the same as it was before the transport provider received the interface primitive that was in error.

The allowable errors that can be reported on the receipt of a transport initiated primitive are presented in the description of the appropriate primitives.

Fatal Errors

Fatal errors are those which can not be corrected by the transport user, or those errors which result in an uncorrectable error in the interface or in the transport provider.

The most common of these errors are listed under the appropriate primitives. The transport provider should issue fatal errors only if the transport user can not correct the condition which caused the error or if the transport provider has no means of reporting a transport user correctable error. If the transport provider detects an uncorrectable non-protocol error internal to the transport provider, the provider should issue a fatal error to the user.

Fatal errors are indicated to the transport user via the STREAMS message type M_ERROR with an appropriate UNIX system error. EPROTO should be used if the user has broken the TPI protocol. The message M_ERROR will result in the failure of all the operating system service routines on the stream. The user must then close the stream and, if required, attempt to open a new stream to the provider. Note that some providers may reject the "open" if, for example, the reason for the fatal error is that the provider has been shut down.

Rules for Transport Service Interface Sequence of Primitives

The allowable sequence of primitives are described in the state diagrams and tables in Allowable Sequence of TPI Primitives, for both the connection-mode and connectionless-mode transport services. The following are rules regarding the maintenance of the state of the interface:

The following rules apply only to the connection-mode transport services:

Rules for Precedence of TPI Primitives on a Stream

The following rules apply to the precedence of transport interface primitives with respect to their position on a stream:

The stream queue which contains the transport user initiated primitives is referred to as the stream write queue. The stream queue which contains the transport provider initiated primitives is referred to as the stream read queue.

The following rule applies only to the connection-mode transport services:

Rules for Flushing Queues

The following rules pertain to flushing the stream queues. No other flushes should be needed to keep the queues in the proper condition.

The following rules pertain only to the connection-mode transport providers.

Receipt of Unknown Primitives

For compatability with older implementations, this specification does not mandate a particular response by a transport provider on receipt of an unknown TPI primitive.

Implementations have been known to:

It is recommended that implementations should send a T_ERROR_ACK with a TLI_error field set to TNOTSUPPORT.

Contents Next section Index