Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 04 Jun 1999 23:44:16 -0700
From:      Peter Wemm <peter@netplex.com.au>
To:        "David Schwartz" <davids@webmaster.com>
Cc:        "Poul-Henning Kamp" <phk@critter.freebsd.dk>, current@FreeBSD.ORG
Subject:   Re: net.inet.tcp.always_keepalive on as default ? 
Message-ID:  <199906050644.XAA07499@peterw.yahoo.com>
In-Reply-To: Your message of "Fri, 04 Jun 1999 22:48:17 PDT." <000101beaf17$026896f0$021d85d1@whenever.youwant.to> 

Next in thread | Previous in thread | Raw E-Mail | Index | Archive | Help
"David Schwartz" wrote:
> 
> > Well, we've heard various opinions and I think we can conclude that:
> >
> > 2.  That server applications should have keepalives enabled.
> 
> 	Well, I certainly don't agree with that. Many server applications (web
> servers, mail servers, etcetera) already have data timeouts, which makes
> keepalives redundant.

Huh?  The keepalive option *is* a kind of data timeout..  It's a failsafe
so that if nothing has been heard for a while then it explicitly does
a check to see if the network connection is still valid.  Of course a server
app is free to implement it's own data timeouts, but it shouldn't have
to reinvent what the kernel can do very well already and is very difficult
to do in userland.

There are several sorts of timeouts that server apps *may* want:
- Some sort of upper bound on a session time, eg: a fingerd session may not
last more than 1 hour, regardless of whether it's doing something.  Something
like a http server might put an upper limit of something like 24 hours - if it
is too small and it will interfere with large downloads.
- Some sort of idle timeout, eg: a smtp server may want to time out
after 10 minutes of not recieving a command.
- A way of detecting a stalled or rebooted client.  This is what keepalive 
does.  It lets you detect a lost connection before some other longer timeout
(eg: 24 hours) kicks in.

> 	In my opinion, in the vast majority of cases, data timeouts are more
> logical than keepalives. 'telnetd' being the most obvious exception.

Telnetd is the worst example. Just because I have not typed something for
two hours is no indication that the session should be closed.  Only the
kernel can test the validity of the network link in this case.  However, of
I drop a link or reboot, then I do want it cleaned up in a timely fashion.

> 	DS

Cheers,
-Peter



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message




Want to link to this message? Use this URL: <http://docs.FreeBSD.org/cgi/mid.cgi?199906050644.XAA07499>