On 05/ 6/10 03:23 AM, Andrew Gabriel wrote:
TCP_CONN_ABORT_THRESHOLD, TCP_ABORT_THRESHOLD
---------------------------------------------
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?
The value 0 is free and indeed can be used to mean infinity.
But is (2) really useful in practice? Having that only
eliminates a subset of errors. And the handling of this
subset of errors is probably similar to the handling of
its complement. If folks really think that it is a useful,
I can add this meaning assuming that there is no objection.
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?
Could you please elaborate your concern?
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.
OK, I can add those words to the man page.
--
K. Poon.
[email protected]
_______________________________________________
opensolaris-arc mailing list
[email protected]
