From owner-freebsd-current Sun Jun 6 22:29:26 1999 Delivered-To: freebsd-current@freebsd.org Received: from detlev.UUCP (tex-89.camalott.com [208.229.74.89]) by hub.freebsd.org (Postfix) with ESMTP id EFD6814F94 for ; Sun, 6 Jun 1999 22:29:22 -0700 (PDT) (envelope-from joelh@gnu.org) Received: (from joelh@localhost) by detlev.UUCP (8.9.3/8.9.3) id AAA73257; Mon, 7 Jun 1999 00:29:30 -0500 (CDT) (envelope-from joelh) To: Matthew Dillon Cc: current@FreeBSD.ORG Subject: Re: net.inet.tcp.always_keepalive on as default ? References: <199906060614.XAA17631@apollo.backplane.com> From: Joel Ray Holveck Date: 07 Jun 1999 00:29:22 -0500 In-Reply-To: Matthew Dillon's message of "Sat, 5 Jun 1999 23:14:02 -0700 (PDT)" Message-ID: <861zfod1e4.fsf_-_@detlev.UUCP> Lines: 37 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >> 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