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.