From owner-freebsd-net Thu Feb 8 10: 5:51 2001 Delivered-To: freebsd-net@freebsd.org Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by hub.freebsd.org (Postfix) with ESMTP id 7ECC237B69F; Thu, 8 Feb 2001 10:05:33 -0800 (PST) Received: from curve.dellroad.org (curve.dellroad.org [10.1.1.30]) by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id KAA61412; Thu, 8 Feb 2001 10:05:32 -0800 (PST) Received: (from archie@localhost) by curve.dellroad.org (8.9.3/8.9.3) id KAA56533; Thu, 8 Feb 2001 10:05:32 -0800 (PST) (envelope-from archie) From: Archie Cobbs Message-Id: <200102081805.KAA56533@curve.dellroad.org> Subject: Re: [itojun@iijlab.net: accept(2) behavior with tcp RST right after handshake] In-Reply-To: "from Robert Watson at Feb 8, 2001 11:45:16 am" To: Robert Watson Date: Thu, 8 Feb 2001 10:05:32 -0800 (PST) Cc: jlemon@flugsvamp.com, net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL77 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org 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