On Tue, Jun 01, 1999 at 03:02:47PM -0700, Matthew Dillon wrote:
> I think keepalive's could easily be turned on by default. At BEST, one
> of the first things I did 5 years ago was to turn them on permanently
> on all of our machines.
I'd like to disagree on the "by default" part, on the following
assumptions:
1. If you turn on keepalive by default, you will
have to increase the keepalive timeout value
well over the current 2 hours (at least that's what
most people suggest to alleviate the concerns
about having keepalives on)
2. Changing this default value of 2 hours will affect
ALL applications. Many of them (and their users)
are more or less expecting a 2 hours value. For
example that's the case for Telnet: probably you
don't want to wait for ONE WEEK before a connection
dies if you are currently using keepalives!
I don't see what this fuss is all about. If for _some_ big servers
there are many dead connections around after a while (*), why don't
THEY use a sysctl at boot-time to change the default state, rather
than impose on the rest of us a change that might not be as innocuous
as it looks?
(*) In theory, for a FTP server, most such connections will be
when the user does a PUT, not a GET. In a GET, the server has
data to push and will timeout anyway. In the case of the control
connection, there's a application timeout in most ftpds who
close the connection after some configurable amount of time.
> This used to be a HUGE argument in the days where networks were less
> reliable and dialup lines were scarse. It is not an argument now,
> however.
Go explain that to my cable provider :-). Keeping a long-lived
connection through them is a real challenge; keepalives on would
make my life even more difficult.
> Whatever we do, we should not start messing around with the internals
> of the kernel trying to 'fix' a non-problem. Keepalives work just dandy
> as they are currently implemented, we do not have to mess with it beyond
> possibly changing the default in rc.conf.
"possibly", but *only* as a last resort if there are good reasons
for it, IMHO. But I haven't seen any such reason yet.
I also think that having at least a kernel-wide (or better, having
it configurable on a per-socket basis), dynamically configurable
keepalive would be a good thing.
--
Pierre Beyssac p...@enst.fr
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message
