Date: 07 Jun 1999 00:29:22 -0500 From: Joel Ray Holveck <joelh@gnu.org> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: current@FreeBSD.ORG Subject: Re: net.inet.tcp.always_keepalive on as default ? Message-ID: <861zfod1e4.fsf_-_@detlev.UUCP> In-Reply-To: Matthew Dillon's message of "Sat, 5 Jun 1999 23:14:02 -0700 (PDT)" References: <Pine.BSF.4.10.9906052010540.53878-100000@janus.syracuse.net> <199906060614.XAA17631@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
>> But remember that the idea is the keepalive would keep trying for a >> certain amount of time, and this would be finely configureable. > Adjusting the keepalive's retry period after activation is also > irrelevant. As they currently stand, keepalives operate in virtually [snip] I don't see why this is a point of discussion. The keepalive timers are all configurable via sysctl. Is this mechanism being considered as insufficient? > Unless the entire purpose of the connection is to simply be connected, > with no data flow ever, being able to finely tune keepalive values does > not really help. The existing rough tuning is as much as anyone will > ever need to mess with. With all due respect, Matt, the second biggest lesson my time with computers has taught me is to never think that X will be enough for all needs. 640k, 32 bit IP addresses, two-digit years, Ada, non 8-bit-clean text utilities, one-second granularity in the filesystem timestamps, yada yada. (Note that I have no objection to saying that we don't see a need to implement it at present. In this case, I sure don't see such a need, but I'm willing to be given a counterexample. We're not looking at making it impossible-- or even difficult-- to implement other keepalive timing strategies in the future, if the need arises, so I would suggest that we not concern ourselves with this discussion until the need arises.) Happy hacking, joelh -- Joel Ray Holveck - joelh@gnu.org Fourth law of programming: Anything that can go wrong wi sendmail: segmentation violation - core dumped 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?861zfod1e4.fsf_-_>