Date: Thu, 8 Feb 2001 11:45:16 -0500 (EST) From: Robert Watson <rwatson@FreeBSD.ORG> To: Archie Cobbs <archie@dellroad.org> Cc: Jonathan Lemon <jlemon@flugsvamp.com>, net@FreeBSD.ORG Subject: Re: [itojun@iijlab.net: accept(2) behavior with tcp RST right after handshake] Message-ID: <Pine.NEB.3.96L.1010208114105.30518A-100000@fledge.watson.org> In-Reply-To: <200102080524.VAA54629@curve.dellroad.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 7 Feb 2001, Archie Cobbs wrote: > Jonathan Lemon writes: > > Jayanth did make one point that an application could assume that > > the error return from accept was in regards to the listening socket > > instead of the new socket, so that may be a concern. > > Yes I have always assumed this to be true. If the connection is > already broken before I get it, why bother giving it to me?? Well, for the purposes of propagating information up to applications consistently on both sides of a connection, the ideal behavior from my perspective is: When a connection comes in and is reset/closed before accept() can occur, accept() should return success with a properly filled out sockaddr. When the first operation occurs on the socket, it should return an appropriate error message based on the close of the socket (ECONNRESET most likely). This allows the application to be notified of the event at the TCP level, log the address or the like, and continue. The only real issue with this behavior is that most applications assume that a successful accept() call returns a live socket, and may go through expensive overhead before their next socket operation -- for example, fork(). It seems that the ECONNABORTED is the "standard" way to address this scenario; it might be an interesting exercise for someone to look at the common application suites and see how they respond to various failure modes in accept(). It certainly appears that BIND9 expects that. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1010208114105.30518A-100000>