>> 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 - jo...@gnu.org Fourth law of programming: Anything that can go wrong wi sendmail: segmentation violation - core dumped To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
