Guidelines for protocol independence

By defining a set of services common to many transport protocols, the Transport Interface offers protocol independence for user software. However, not all transport protocols support the services supported by the Transport Interface. If software must be run in a variety of protocol environments, only the common services should be accessed. The following guidelines highlight services that may not be common to all transport protocols.

• In the connection-mode service, the concept of a transport service data unit (TSDU) may not be supported by all transport providers. The user should make no assumptions about the preservation of logical data boundaries across a connection. If messages must be transferred over a connection, a protocol should be implemented above the Transport Interface to support message boundaries.

• Protocol and implementation specific service limits are returned by the t_open and t_getinfo routines. These limits are useful when allocating buffers to store protocol-specific transport addresses and options. It is the responsibility of the user to access these limits and then adhere to the limits throughout the communication process.

• User data should not be transmitted with connect requests or disconnect requests (see t_connect(S) and t_snddis(S)). Not all transport protocols support this capability.

• The buffers in the t_call structure used for t_listen must be large enough to hold any information passed by the client during connection establishment. The server should use the T_ALL argument to t_alloc, which determines the maximum buffer sizes needed to store the address, options, and user data for the current transport provider.

• The user program should not look at or change options that are associated with any Transport Interface routine. These options are specific to the underlying transport protocol. The user should not pass options with t_connect or t_sndudata. In such cases, the transport provider will use default values. Also, a server should use the options returned by t_listen when accepting a connection.

• Protocol-specific addressing issues should be hidden from the user program. A client should not specify any protocol address on t_bind, but instead should allow the transport provider to assign an appropriate address to the transport endpoint. Similarly, a server should retrieve its address for t_bind in such a way that it does not require knowledge of the transport provider's address space. Such addresses should not be hard-coded into a program. A name server procedure could be useful in this situation, but the details for providing this service are outside the scope of the Transport Interface. Detailed information about Network Selection and Name-to-address Mapping can be found in ``Network selection'' and ``Name-to-address mapping''.

• The reason codes associated with t_rcvdis are protocol-dependent. The user should not interpret this information if protocol-independence is important.

• The error codes associated with t_rcvuderr are protocol-dependent. The user should not interpret this information if protocol-independence is a concern.

• The names of devices should not be hard-coded into programs, because the device node identifies a particular transport provider, and is not protocol independent.

• The optional orderly release facility of the connection-mode service (provided by t_sndrel and t_rcvrel) should not be used by programs targeted for multiple protocol environments. This facility is not supported by all connection-based transport protocols. In particular, its use will prevent programs from successfully communicating with ISO open systems.