Garrett D'Amore wrote:
I'm submitting this fast-track for Kacheong Poon, timing out on
05/10/2010. The release binding is Patch, and the stability level of
new socket options is Committed.
This case introduces four TCP level socket options, TCP_RTO_INITIAL,
TCP_RTO_MIN, TCP_RTO_MAX, and TCP_LINGER2. This case also documents
the existing options TCP_CONN_ABORT_THRESHOLD and TCP_ABORT_THRESHOLD.
[...]
TCP_CONN_ABORT_THRESHOLD, TCP_ABORT_THRESHOLD
---------------------------------------------
An application can use these two options to change/retrieve the total
time a TCP connection spent doing retransmission without getting back
an acknowledgment. TCP_CONN_ABORT_THRESHOLD controls this interval
before a connection is established. TCP_ABORT_THRESHOLD controls the
interval after a connection is established. The option value is an
uint32_t and the unit is millisecond (actual value is rounded up to
the nearest clock tick interval). The lower bound of
TCP_CONN_ABORT_THRESHOLD is 1000ms and the upper bound is UINT32_MAX
ms. The lower bound of TCP_ABORT_THRESHOLD is 500ms and the upper
bound is UINT32_MAX ms.
These options correspond to the private TCP parameters
tcp_ip_abort_cinterval and tcp_ip_abort_interval, which control the
default values used in an IP stack. The lower and upper bound of
the options are the same as that of the private parameters.
I can see two cases where I would use these:
1) Where my application wants a short connection establishment timeout
or a quick connection failure detection, i.e. shorter in either case
than the default TCP values, because my application wants to take some
other action in these cases before TCP is likely to have timed out the
operation.
2) Where my application requires a permanent TCP connection, and I'm not
interested in knowing about timeouts - just keep trying.
Unfortunately, 2) is not quite handled in this case, as there are no
values which are interpreted as infinity (i.e. no timeout), so I still
have to handle the case where connect(), read(), write(), etc return
timeouts, even if they do it less often. Having an infinity value might
allow me to simplify my application coding (even though I still have to
handle the possibility of a RST). Is the value 'zero' free to be
interpreted as infinity?
TCP_LINGER2
-----------
[...] The default value of tcp_fin_wait_2_flush_interval is also
changed to 60s.
Just wondering if that's safe/acceptable for a patch binding?
Diff of tcp(7P)
I would add something to say that changing these new parameters requires
detailed knowledge of the application and the TCP protocol, and normally
there is no need to change them. We're giving the programmer some rope,
but it's worth warning him not to make a noose for himself.
--
Andrew Gabriel
_______________________________________________
opensolaris-arc mailing list
[email protected]
