From owner-freebsd-net Thu Feb 8 8:45:42 2001 Delivered-To: freebsd-net@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id B15B737B491 for ; Thu, 8 Feb 2001 08:45:22 -0800 (PST) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.1/8.11.1) with SMTP id f18GjGh31127; Thu, 8 Feb 2001 11:45:16 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Thu, 8 Feb 2001 11:45:16 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: Archie Cobbs Cc: Jonathan Lemon , net@FreeBSD.ORG Subject: Re: [itojun@iijlab.net: accept(2) behavior with tcp RST right after handshake] In-Reply-To: <200102080524.VAA54629@curve.dellroad.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org 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