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:

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.

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.

• 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.