From owner-freebsd-bugs Thu Feb 28 13:30:10 2002 Delivered-To: freebsd-bugs@hub.freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id CCFEB37B41A for ; Thu, 28 Feb 2002 13:30:00 -0800 (PST) Received: (from gnats@localhost) by freefall.freebsd.org (8.11.6/8.11.6) id g1SLU0i30522; Thu, 28 Feb 2002 13:30:00 -0800 (PST) (envelope-from gnats) Received: from segfault.monkeys.com (246.dsl6660157.rstatic.surewest.net [66.60.157.246]) by hub.freebsd.org (Postfix) with ESMTP id 8783B37B400 for ; Thu, 28 Feb 2002 13:21:47 -0800 (PST) Received: by segfault.monkeys.com (Postfix, from userid 1237) id 1E168660C; Thu, 28 Feb 2002 13:21:42 -0800 (PST) Message-Id: <20020228212142.1E168660C@segfault.monkeys.com> Date: Thu, 28 Feb 2002 13:21:42 -0800 (PST) From: rfg@monkeys.com Reply-To: rfg@monkeys.com To: FreeBSD-gnats-submit@freebsd.org X-Send-Pr-Version: 3.113 Subject: kern/35429: select(2)/poll(2)/kevent(2) can't/don't notice lost connections Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org >Number: 35429 >Category: kern >Synopsis: select(2)/poll(2)/kevent(2) can't/don't notice lost connections >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: change-request >Submitter-Id: current-users >Arrival-Date: Thu Feb 28 13:30:00 PST 2002 >Closed-Date: >Last-Modified: >Originator: Ronald F. Guilmette >Release: FreeBSD 4.3-RELEASE i386 >Organization: Infinite Monkeys & Co. >Environment: FreeBSD 4.3-RELEASE #0 >Description: Certain server processes that accept input from multiple TCP stream sockets (but which do not customarily write to those sockets) and which use the select(2), poll(2), or kevent(2) kernel calls to monitor the state of their own ends of these stream sockets may find it desirable to optimize usage of both socket descriptors and file descriptors (either of which may be in short supply) by closing sockets / file descriptors as soon as possible when and if the connections associated with those sockets have been lost or broken. In cases where connections are broken, voluntarily, by the relevant peers performing normal socket close operations, the select(2), poll(2), and kevent(2) kernel functions can and do signal these events back to user- level processes immediately. However in cases where connections to peers are simply lost (e.g. due to network lossage or unexpected power failures on the peers) there currently appears to be no mechanism whereby user-level processes (in particular server processes that do not customarily write to their client peers) may be made aware of these connection losses, either in near-real-time (which would be optimal) or at all. Intutively, the SO_KEEPALIVE option for sockets would seem to provide at least a low-level mechanism via which the kernel can become aware of the sudden loss of any socket connection for which this option has been set. However the man page for setsockopt(2) says: SO_KEEPALIVE enables the periodic transmission of messages on a connected socket. Should the connected party fail to respond to these messages, the connection is con- sidered broken and processes using the socket are notified via a SIGPIPE signal when attempting to send data. It is clear from this description of the semantics of SO_KEEPALIVE that unless and until an attempt is made, by the user-level process, to write to a socket for which the connection has been lost (and for which the SO_KEEPALIVE option has been set) the user-level process will not be made aware... either in near-real-time, or at all... that a given socket connection which it has opened has lost its connection to the relevant peer, even if the kernel already has that information. This is clearly unfortunate, given that a user-level process which is attempting to optimize its use of socket descriptors and/or file descriptors could clearly benefit from being informed, by the kernel, of cases of dropped socket connections, ideally in near-real-time, and without the need to attempt a write to each socket for which this information is desired. (Note that certain protocols may even prohibit the server process from performing any writes to its ends of the socket connections.) It would seem to make a great deal of sense to alter the current behavior of the select(2), poll(2), and kevent(2) kernel calls in cases involving sockets for which the SO_KEEPALIVE option has been set and for which the kernel's keepalive mechanism has already determined that the socket con- nection has indeed been lost. Such cases could be, and should be treated as being functionally equivalent to the remote peer having performed a normal close of its end of the socket connection... at least with respect to the select(2), poll(2), and kevent(2) kernel calls. Note: Concerns about the effects on backward compatability of this change could be avoided by defining a new socket option code and associated symbol to be used where either the new behavior or, alternatively, the old behavior is desired. For example, a symbol like `SO_KEEPALIVE_ORIG' might be created for use when the original behavior is desired. Alternatively, a new symbol (e.g. `SO_KEEPWATCH') and an associated new socket option code could be defined and used when the new and more useful behavior is desired. >How-To-Repeat: This is an enhancement request. There is nothing to repeat. >Fix: See above. This is an enhancement request. >Release-Note: >Audit-Trail: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message