[ Bottom of Page | Previous Page | Next Page | Contents | Index | Library Home |
Legal |
Search ]
Technical Reference: Communications, Volume 2
Options for the X/Open Transport Interface
Options are formatted according to the t_opthdr structure as described in "Use of Options
for the X/Open Transport Interface". A transport provider compliant to this specification
supports none, all, or any subset of the options defined in the following
sections: "TCP/IP-Level Options" to "IP-level Options". An implementation
may restrict the use of any of these options by offering them only in the
privileged or read-only mode.
TCP-Level Options
The protocol level is INET_TCP.
For this level, the following table shows the options that are defined.
TCP-Level Options
Option Name |
Type of Option Value |
Legal Option Value |
Meaning |
TCP_KEEPALIVE |
struct t_kpalive |
see text following table |
check if connections are live |
TCP_MAXSEG |
unsigned long |
length in octets |
get TCP maximum segment size |
TCP_NODELAY |
unsigned long |
T_YES T_NO |
don't delay send to coalesce packets |
TCP_KEEPALIVE |
If set, a keep-alive timer is activated to monitor idle connections
that may no longer exist. If a connection has been idle since the last keep-alive
timeout, a keep-alive packet is sent to check if the connection is still
alive or broken.
Keep-alive packets are not an explicit
feature of TCP, and this practice is not universally accepted. According
to RFC 1122:
"a keep-alive
mechanism should only be invoked in server applications that might otherwise
hang indefinitely and consume resources unnecessarily if a client crashes
or aborts a connection during a network failure."
The option value consists of a structure t_kpalive
declared as:
struct t_kpalive {
long kp_onoff;
long kp_timeout;
}
The t_kpalive fields
and the possible values are:
- kp_onoff
- Switches option on or off. Legal values for the field are:
- T_NO
- Switch keep-alive timer off.
- T_YES
- Activate keep-alive timer.
- T_YES | T_GARBAGE
- Activate keep-alive timer and send garbage octet.
Usually, an implementation should send a keep-alive
packet with no data (T_GARBAGE not set). If T_GARBAGE is set, the keep-alive packet contains one garbage octet for
compatibility with erroneous TCP implementations.
An implementation is, however, not obliged to support T_GARBAGE (see RFC 1122). Since the kp_onoff value is
an absolute requirement, the request "T_YES | T_GARBAGE" may therefore be rejected.
- kp_timeout
- Specifies the keep-alive timeout in minutes. This field determines
the frequency of keep-alive packets being sent, in minutes. The transport
user can request the default value by setting the field to T_UNSPEC. The default is implementation-dependent, but at least 120
minutes (see RFC 1122). Legal values for this field are T_UNSPEC and all positive numbers.
The timeout
value is not an absolute requirement. The implementation may pose upper and
lower limits to this value. Requests that fall short of the lower limit may
be negotiated to the lower limit.
The use of this
option might be restricted to privileged users.
|
TCP_MAXSEG |
Used to retrieve the maximum TCP segment size. This option is read-only. |
TCP_NODELAY |
Under most circumstances, TCP sends data as soon as it is presented.
When outstanding data has not yet been acknowledged, it gathers small amounts
of output to be sent in a single packet once an acknowledgment is received.
For a small number of clients, such as window systems (for example, Enhanced
AIXwindows) that send a stream of mouse events which receive no
replies, this packetization may cause significant delays. TCP_NODELAY is used to defeat this algorithm. Legal option values are:
- T_YES
- Do not delay.
- T_NO
- Delay.
|
These options are not association-related. The options
may be negotiated in all X/Open Transport Interface states except T_UNBIND and T_UNINIT. The options are read-only in the T_UNBIND state. See "The Use of Options
for the X/Open Transport Interface" for the differences between association-related
options and those options that are not.
Absolute Requirements
A request for TCP_NODELAY and
a request to activate TCP_KEEPALIVE is an absolute
requirement. TCP_MAXSEG is a read-only option.
UDP-level Options
The protocol level is INET_UDP.
The option defined for this level is shown in the following table.
UDP-Level Options
Option Name |
Type of Option Value |
Legal Option Value |
Meaning |
UDP_CHECKSUM |
unsigned long |
T_YES/T_NO |
checksum computation |
UDP_CHECKSUM |
Allows disabling and enabling of the UDP checksum computation. The
legal values are:
- T_YES
- Checksum enabled.
- T_NO
- Checksum disabled.
This option is association-related. It may be
negotiated in all XTI states except T_UNBIND and T_UNINIT. It is read-only in state T_UNBND.
If this option is returned with the t_rcvudata subroutine, its value indicates whether a checksum
was present in the received datagram or not.
Numerous cases of undetected errors have been reported when applications
chose to turn off checksums for efficiency. The advisability of ever turning
off the checksum check is very controversial. |
Absolute Requirements
A request for this option is an absolute requirement.
IP-level Options
The protocol level is INET_IP.
The options defined for this level are listed in the following table.
IP-Level Options
Option Name |
Type of Option Value |
Legal Option Value |
Meaning |
IP_BROADCAST |
unsigned int |
T_YES/T_NO |
permit sending of broadcast messages |
IP_DONTROUTE |
unsigned int |
T_YES/T_NO |
just use interface addresses |
IP_OPTIONS |
array of unsigned characters |
see text |
IP per-packet options |
IP_REUSEADDR |
unsigned int |
T_YES/T_NO |
allow local address reuse |
IP_TOS |
unsigned char |
see text |
IP per-packet type of service |
IP_TTL |
unsigned char |
time in seconds |
IP per packet time-to-live |
IF_BROADCAST |
Requests permission to send broadcast datagrams. It was defined to
make sure that broadcasts are not generated by mistake. The use of this option
is often restricted to privileged users. |
IP_DONTROUTE |
Indicates that outgoing messages should bypass the standard routing
facilities. It is mainly used for testing and development. |
IP_OPTIONS |
Sets or retrieves the OPTIONS field of each outgoing (incoming) IP
datagram. Its value is a string of octets composed of a number of IP options,
whose format matches those defined in the IP specification with one exception:
the list of addresses for the source routing options must include the first-hop
gateway at the beginning of the list of gateways. The first-hop gateway address
will be extracted from the option list and the size adjusted accordingly
before use.
The option is disabled if it is specified
with "no value," for example, with an option header only.
The t_connect (in synchronous mode), t_listen, t_rcvconnect and t_rcvudata subroutines return the OPTIONS field, if any, of the received IP datagram
associated with this call. The t_rcvuderr subroutine
returns the OPTIONS field of the data unit previously sent that produced
the error. The t_optmgmt subroutine with T_CURRENT set retrieves the currently effective IP_OPTIONS that is sent with outgoing datagrams.
Common
applications never need this option. It is mainly used for network debugging
and control purposes. |
IP_REUSEADDR |
Many TCP implementations do not allow the user to bind more than
one transport endpoint to addresses with identical port numbers. If IP_REUSEADDR is set to T_YES this
restriction is relaxed in the sense that it is now allowed to bind a transport
endpoint to an address with a port number and an underspecified internet
address ("wild card" address) and further endpoints to addresses with the
same port number and (mutually exclusive) fully specified internet addresses. |
IP_TOS |
Sets or retrieves the type-of-service field
of an outgoing (incoming) IP datagram. This field can be constructed by any
OR'ed combination of one of the precedence flags and the type-of-service
flags T_LDELAY, T_HITHRPT, and T_HIREL:
- Precedence:
These flags specify
datagram precedence, allowing senders to indicate the importance of each
datagram. They are intended for Department of Defense applications. Legal
flags are:
T_ROUTINE
T_PRIORITY
T_IMMEDIATE
T_FLASH
T_OVERRIDEFLASH
T_CRITIC_ECP
T_INETCONTROL
T_NETCONTROL Applications using IP_TOS but not
the precedence level should use the value T_ROUTINE
for precedence.
- Type of service:
These flags
specify the type of service the IP datagram desires. Legal flags are:
- T_NOTOS
- requests no distinguished type of service
- T_LDELAY
- requests low delay
- T_HITHRPT
- requests high throughput
- T_HIREL
- requests high reliability
The option value is set using the macro SET_TOS(prec, tos) where prec is set to one of the precedence flags and tos to one or an OR'ed combination of the type-of-service flags. SET_TOS returns the option value.
The t_connect, t_listen, t_rcvconnect and t_rcvudata subroutines return the type-of-service field of the received IP datagram associated with this
call. The t_rcvuderr subroutine returns the type-of-service field of the data unit previously sent that produced
the error.
The t_optmgmt
subroutine with T_CURRENT set retrieves the currently
effective IP_TOS value that is sent with outgoing datagrams.
The requested type-of-service cannot be guaranteed. It is a hint to the routing algorithm that helps
it choose among various paths to a destination. Note also, that most hosts
and gateways in the Internet these days ignore the type-of-service field. |
IP_TIL |
This option is used to set the time-to-live
field in an outgoing IP datagram. It specifies how long, in seconds, the
datagram is allowed to remain in the Internet. The time-to-live field of an incoming datagram is not returned by any function (since
it is not an association-related option). |
IP_OPTIONS and IP_TOS are both association-related options. All other options are not
association-related.
IP_REUSEADDR may be negotiated
in all XTI states except T_UNINIT. All other options
may be negotiated in all other XTI states except T_UNBND and T_UNINIT; they are read-only in the state T_UNBND.
Absolute Requirements
A request for any of these options in an absolute
requirement.
[ Top of Page | Previous Page | Next Page | Contents | Index | Library Home |
Legal |
Search ]