Date: Thu, 8 Feb 2001 10:05:32 -0800 (PST) From: Archie Cobbs <archie@dellroad.org> To: Robert Watson <rwatson@FreeBSD.ORG> Cc: jlemon@flugsvamp.com, net@FreeBSD.ORG Subject: Re: [itojun@iijlab.net: accept(2) behavior with tcp RST right after handshake] Message-ID: <200102081805.KAA56533@curve.dellroad.org> In-Reply-To: <Pine.NEB.3.96L.1010208114105.30518A-100000@fledge.watson.org> "from Robert Watson at Feb 8, 2001 11:45:16 am"
next in thread | previous in thread | raw e-mail | index | archive | help
Robert Watson writes: > > 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 makes the most sense to me. If you get an error from accept(), the implication (in my mind, and I suspect many others) is that the error is with the *listening* socket. If the error is really with the *new* socket then the error should "wait" until a read(), getpeername(), etc. -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com 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?200102081805.KAA56533>