Content-type: text/html Man page of xti_internet

xti_internet

Section: Environments, Tables, and Troff Macros (7)
Index Return to Main Contents
 

NAME

xti_internet - Internet Protocol-specific information on XTI  

DESCRIPTION

This reference page provides protocol-specific information that is relevant for TCP and UDP transport providers. It includes information on the following: General notes Options Functions  

GENERAL NOTES

TSDU is not supported by a TCP transport provider, so the T_MORE flag is ignored when TCP is used. The TCP PUSH flag cannot be used through the XTI interface because the TCP Military Standard states the following:

Successive pushes may not be preserved because two or more units of pushed data may be joined into a single pushed unit by either the sending or receiving TCP. Pushes are not visible to the receiving Upper Level Protocol and are not intended to serve as a record boundary marker. TCP does not have a notion of expedited data in a sense comparable to ISO expedited data. TCP defines an urgent mechanism, by which in-line data is marked for urgent delivery. UDP has no urgent mechanism. See the TCP Military Standard for more detailed information. The orderly release functions t_sndrel and t_rcvrel were defined to support the orderly release facility of TCP. The specification of TCP states that only established connections may be closed with orderly release; that is, on an endpoint in T_DATAXFER or T_INREL state. TCP does not allow the possibility of refusing a connection indication. Each connect indication causes the TCP transport provider to establish the connection. Therefore, t_listen and t_accept have a semantic that is slightly different from that for ISO providers.
 

OPTIONS

Options are formatted according to the structure t_opthdr as described in the xti(7) reference page. A transport provider compliant to this specification supports none, all, or any subset of the options defined in this section. An implementation can 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. The following table shows the options that are defined for this level:

Option Name Type of Option Value Legal Option Value Meaning

TCP_KEEPALIVEstruct t_kpaliveSee text Check if connections are alive.
TCP_MAXSEGUnsigned long Length in octets Get TCP maximum segment size.
TCP_NODELAYUnsigned longT_YES/T_NO Do not delay send to coalesce packets.

These options are not association-related. They can be negotiated in all XTI states except T_UNBND and T_UNINIT. They are read-only in the T_UNBND state. See the xti(7) reference page for the difference between options that are association-related and those that are not.

A request for TCP_NODELAY and a request to activate TCP_KEEPALIVE is an absolute requirement. TCP_MAXSEG is a read-only option. If this option is set, a keep-alive timer is activated to monitor idle connections that might 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. RFC1122 states the following:
... 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 follows: struct t_kpalive {
    long kp_onoff;    /* switch option on or off */
    long kp_timeout;  /* keepalive timeout in minute */ }
Legal values for the kponoff field are: T_NO - Switch keep-alive time 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 not obliged to support T_GARBAGE. Since the kp_onoff value is an absolute requirement, the request T_YES | T_GARBAGE can therefore be rejected.
The kp_timeout field determines the frequency in minutes of keep-alive packets being sent. 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. Legal values for this field are T_UNSPEC and all positive numbers.
The timeout value is not an absolute requirement. The implementation can pose upper and lower limits to this value. Requests that fall short of the lower limit can be negotiated to the lower limit.
The use of this option might be restricted to privileged users. This option is read-only. It is used to retrieve the maximum TCP segment size. 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 acknowledgement is received. For a small number of clients, such as window systems (for example, MIT X Window System) that send a stream of mouse events that receive no replies, this packetisation can cause significant delays. TCP_NODELAY is used to defeat this algorithm. Legal option values are T_YES, which indicates do not delay, and T_NO, which indicates delay.
 

UDP-level Options

The protocol level is INET_UDP. The following table shows the option defined for this level:

Option Name Type of Option Value Legal Option Value Meaning

UDP_CHECKSUMUnsigned longT_YES/T_NOChecksum computation.

This option is association-related. It can be negotiated in all XTI states except T_UNBND and T_UNINIT. It is read-only in the T_UNBND state. See the xti(7) reference page for the difference between options that are association-related and those that are not.

A request for UDP_CHECKSUM is an absolute requirement. The option allows enabling and disabling of the UDP checksum computation. The legal values are T_YES, checksum enabled, and T_NO, checksum disabled.

If this option is returned with the t_rcvudata function, its value indicates whether a checksum was present in the received datagram.
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 controversial.
 

IP-level Options

The protocol level is INET_IP. The following table shows the options defined for this level:


Option Name Type of Option Value Legal Option Value Meaning

IP_BROADCASTUnsigned intT_YES/T_NO Permit sending of broadcast messages.
IP_DONTROUTEUnsigned intT_YES/T_NO Just use interface addresses.
IP_OPTIONS Array of unsigned characters See text IP per-packet options.
IP_REUSEADDRUnsigned intT_YES/T_NO Allow local address reuse.
IP_TOSUnsigned charSee text IP per-packet type of service.
IP_TTLUnsigned charTime in seconds IP per-packet time-to-live.

IP_OPTIONS and IP_TOS are association-related options. All other options are not association-related. See the xti(7) reference page for the difference between options that are association-related and those that are not.

IP_REUSEADDR can be negotiated in all XTI states except T_UNINIT. All other options can be negotiated in all other XTI states except T_UNBND and T_UNINIT; they are read-only in the T_UNBND state.

A request for any of these options is an absolute requirement. This option 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. This option indicates that outgoing messages should bypass the standard routing facilities. It is mainly used for testing and development. This option is used to set (retrieve) 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 is extracted from the option list and the size adjusted accordingly before use.

The option is disabled if it is specified with no value; that is, with an option header only.
The t_connect (in synchronous mode), t_listen, t_rcvconnect, and t_rcvudata functions return the OPTIONS field, if any, of the received IP datagram associated with this call. The t_rcvuderr function returns the OPTIONS field of the data unit previously sent that produced the error. The t_optmgmt function with T_CURRENT set retrieves the currently effective IP_OPTIONS that is sent with out going datagrams.
Common applications never need this option. It is mainly used for network debugging and control purposes. 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. This option is used to set (retrieve) 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, as follows: Precedence
These flags specify datagram precedence, allowing senders to indicate the importance of each datagram. They are intended for Department of Defense applications. The following are legal flags: 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 T_ROUTINE value for precedence. Type of service
These flags specify the type of service the IP datagram requests. The following are legal flags: 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 functions return the type-of-service field of the received IP datagram associated with this call. The t_rcvuderr function returns the type-of-service field of the data unit previously sent that produced the error.
The t_optmgmt function 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. This option is used to set the time-to-live field in an outgoing IP datagram. It specifies in seconds how long 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).
 

FUNCTIONS

Issuing t_accept assigns an already established connection to resfd.

Since user data cannot be exchanged during the connection establishment phase, call->udata.len must be set to zero (0). Also, resfd must be bound to the same address as fd. A potential restriction on binding of endpoints to protocol addresses is described under the t_bind function.
If association-related options (IP_OPTIONS and IP_TOS) are to be sent with the connect confirmation, the values of these options must be set with the t_optmgmt function before the T_LISTEN event occurs. When the transport user detects a T_LISTEN, TCP has already established the connection. Association-related options passed with t_accept become effective at once, but since the connection is already established, they are transmitted with subsequent IP datagrams sent out in the T_DATAXFER state. The addr field of the t_bind structure represents the local socket; that is an address that specifically includes a port identifier.
In the connection-oriented mode (that is, TCP), the t_bind function can only bind one transport endpoint to any particular protocol address. If that endpoint was bound in passive mode; that is qlen > 0, other endpoints will be bound to the passive endpoint's protocol address through the t_accept function only. That is, if fd refers to the passive endpoint and resfd refers to the new endpoint on which the connection is to be accepted, resfd will be bound to the same protocol address as fd after the successful completion of the t_accept function. The sndcall->addr structure specifies the remote socket. In the present version, the returned address set in rcvcall->addr will have the same value. Since user data cannot be exchanged during the connection establishment phase, sndcall->udata.len must be set to zero (0).
Note that the peer TCP, and not the peer transport user, confirms the connection. Upon successful return, t_listen indicates an existing connection and not a connection indication.
Since user data cannot be exchanged during the connection establishment phase, call->udata.maxlen must be set to zero (0) before the call to t_listen. The call->addr structure contains the remote calling socket. As soon as a segment with the TCP urgent pointer set enters the TCP receive buffer, the event T_EXDATA is indicated. T_EXDATA remains set until all data up to the byte pointed to by the TCP urgent pointer has been received. If the urgent pointer is updated, and the user has not yet received the byte previously pointed to by the urgent pointer, the update is invisible to the user. The t_open function is called as the first step in the initialization of a transport endpoint. This function returns various default characteristics of the underlying transport protocol by setting fields in the t_info structure.
The following should be the values returned by the call to t_open and t_getinfo with the indicated transport providers:

Parameters Before Call After Call TCP/IP After Call UDP/IP

namex//
oflagx//
info->addr/xx
info->options/xx
info->tsdu/0x
info->etsdu/-1-2
info->connect/-2-2
info->discon/-2-2
info->servtype/ T_COTS/T_COTS_ORD T_CLTS
info->flags/T_SNDZEROT_SNDZERO
Table Notes:
x equals -2 or an integral number greater than zero (0). The T_MORE flag should be ignored if normal data is delivered. If the TCP urgent pointer points to a byte in the data stream, as many bytes as possible preceding this marked byte and the marked byte itself are denoted as urgent data and are received with the T_EXPEDITED flag set. If the buffer supplied by the user is too small to hold all urgent data, the T_MORE flag is set, indicating that urgent data still remains to be read. Note that the number of bytes received with the T_EXPEDITED flag set is not necessarily equal to the number of bytes sent by the peer user with the T_EXPEDITED flag set. Since user data cannot be exchanged during the connection establishment phase, call->udata.maxlen must be set to zero (0) before the call to t_rcvconnect. On return, the call->addr structure contains the remote calling socket. Since data cannot be sent with a disconnect, the discon->udata structure will not be meaningful. If t_snd is called with more than one byte specified and with the T_EXPEDITED flag set, the TCP urgent pointer points to the last byte of the buffer. If the T_EXPEDITED flag is set, at least one byte must be sent. Data for a t_snd call with the T_EXPEDITED flag set may not pass data sent previously. Since data cannot be sent with a disconnect, the call->udata.len must be set to zero (0). Be aware that the maximum size of a connectionless TSDU varies among implementations.
 

RELATED INFORMATION

t_optmgmt(3), xti(7)

Network Programmer's Guide, X/Open CAE Specification: Networking Services, Issue 4 delim off


 

Index

NAME
DESCRIPTION
GENERAL NOTES
OPTIONS
TCP-level Options
UDP-level Options
IP-level Options
FUNCTIONS
RELATED INFORMATION

This document was created by man2html, using the manual pages.
Time: 02:40:27 GMT, October 02, 2010