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(3xti)
and
t_snddis(3xti)).
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.
© 2004 The SCO Group, Inc. All rights reserved.
UnixWare 7 Release 7.1.4 - 27 April 2004