Date: Fri, 30 Nov 2007 12:52:22 +0000 From: "Bruce M. Simpson" <bms@FreeBSD.org> To: Andrew Alcheyev <buddy@telenet.ru> Cc: freebsd-net@freebsd.org Subject: Re: per-socket keep-alive options for TCP Message-ID: <47500786.9050902@FreeBSD.org> In-Reply-To: <1736192477.20071130155032@telenet.ru> References: <1736192477.20071130155032@telenet.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
Andrew Alcheyev wrote: > I have recently examined the keep-alive mechanism in FreeBSD's TCP > stack and found out that it has no tunable variables for keep-alive on > a per-socket basis. > Is anyone interested in a patch like this one? > http://mail-index.netbsd.org/tech-net/2007/06/19/0001.html > > Alternatively, a patch for FreeBSD may introduce a new kernel option. > I would appreciate any suggestions. > Seems reasonable. This thread talks about the Solaris implementation and the general background to keep-alives: http://jj.tingiris.net/archives/6-TCP_KEEPALIVE-and-SO_KEEPALIVE-on-Solaris.html And this thread mentions its use in PostgreSQL: http://qaix.com/postgresql-database-development/336-230-re-implement-support-for-tcp-keepcnt-tcp-keepidle-tcp-keepintvl-read.shtml I'm a bit wary of importing new features into a sensitive and heavily used module like TCP without regression tests, though, and it should probably default to the current sysctl defaults in use (default to keepalives on for each new tcp socket) for traversing stateful firewalls on the path. However in this case we are merely introducing new knobs for fine-tuning the keep-alive behaviour, so no big worry here. Being able to tune on a per-socket basis is *somewhat* useful, however what would be useful in the bigger picture is the ability to tune TCP behaviour based on path selection, where the path currently chosen has radically different characteristics from the general case (e.g. GPRS, UMTS, satellite systems). Cheers, BMS
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?47500786.9050902>