Christos Zoulas wrote:
> On Jun 19, 10:01pm, darrenr@netbsd.org (Darren Reed) wrote:
> -- Subject: Re: keepalive per socket settings patch
>
> | Christos Zoulas wrote:
> | > Hi,
> | >
> | > This is pretty straight forward... The question is do we let setsockopt
> | > specify arbitrary values, or do we cap them to the global settings like
> | > I do now? Comments? If there are no disagreements I will commit this after
> | > I write the documentation. If there are, speak now and I won't bother
> | > with the docs.
> | >   
> | 
> | The most common criticism I've discussed with people about the
> | keep alive packets is the problem that you're addressing: different
> | applications want different keep alive values.
> | 
> | I don't think there should be an upper bound, as this reduces the
> | amount of extra traffic/work generated in a given period.
> | 
> | With IPFilter, the largest TCP idle timeout default is 5 days,
> | aimed at the ssh/telnet/etc window that you look at "every now
> | and then".  I don't know if that is a good suggestion for where
> | to start with an upper limit or not.
> | 
> | The bigger problem is the lower bound....
> | Is it too much to allow an application to specify it as being 500ms?
> | And what if apache does this for all n000 connections?
> | Should that just be a configuration error or ...?
>
> All good questions. The idea for the upper limit being the sysctl
> value seemed reasonable at the time. After I implemented it, I
> looked at linux and it does almost the same (for some of them it
> defines max = tcp_keepfoo / PR_SLOWHZ). Can large values be used
> as a DOS attack? What impact do small values have on the system?
> The other thing that we can do, and I have not done yet, is to
> define 0 as infinity (i.e. no timeout). Linux disallows 0; we accept
> it and timeout immediately.
>   

Can we make it behave differently if a NULL pointer is passed vs a value 
of 0
and mimic the behaviour of select?
However, I don't know if getsockopt() could return the difference, could it?

Given that you can simply turn off keep alives for a connection, I can't 
see how
large values could somehow introduce a new DoS vector that doesn't already
exist today.

Experimenting with small values and seeing what impact it has on both the
network and CPU when there are 1000s of connections could be of some
interest.

Darren