Date: Sat, 5 Jun 1999 11:11:48 -0700 From: "David Schwartz" <davids@webmaster.com> To: "Peter Wemm" <peter@netplex.com.au> Cc: "Poul-Henning Kamp" <phk@critter.freebsd.dk>, <current@FreeBSD.ORG> Subject: RE: net.inet.tcp.always_keepalive on as default ? Message-ID: <000201beaf7e$e0e8dd10$021d85d1@whenever.youwant.to> In-Reply-To: <199906050644.XAA07499@peterw.yahoo.com>
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. It's trivial to do in userland, just wrap your read in a select. If the select times out, bail. In many cases, the one-size-fits-all approach of keepalives doesn't fit. Why should someone be allowed to stay connected to my web server for _two_hours_ without sending one byte of data? > 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. Most web servers implement two different time outs. One is a 'request' timeout that typically is in the 2 to 5 minute range. Another is an output timeout that limits how long a connection can go without receiving at least a certain amount of data. Hard session limits are generally not useful -- after all, someone might put a 600Mb file up there and someone might want to retrieve it over a 28.8Kbps connection. Keepalives do not eliminate the need for _either_ timeout. Two hours is too long to wait for a request. Since the TCP connection may work even though the remote end's userland program is not receiving any data, the send timeout is still needed as well. There is no logical reason for a well-designed web server to enable keepalives. Of course, they don't hurt anything. > - 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. There are very few server applications where 24 hour timeouts make sense. In the vast majortity of cases (again, telnetd excepted), timeouts are in the 1-5 minute range. Even web servers sending data use timeouts less than 10 minutes. The timeout, though, is on the current block of data, not the whole file. > > 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. Agreed. Telnetd is the exception, keepalives are great for it. For everything else, almost, data timeouts make far more sense. And keepalives will do nothing, but won't hurt anything. As I have said before, any application that does not implement data timeouts for all states, and does not enable keepalives is BROKEN. DS 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: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?000201beaf7e$e0e8dd10$021d85d1>