From owner-freebsd-net Thu Feb 8 9: 7:32 2001 Delivered-To: freebsd-net@freebsd.org Received: from prism.flugsvamp.com (cb58709-a.mdsn1.wi.home.com [24.17.241.9]) by hub.freebsd.org (Postfix) with ESMTP id F09C637B6AD; Thu, 8 Feb 2001 09:07:02 -0800 (PST) Received: (from jlemon@localhost) by prism.flugsvamp.com (8.11.0/8.11.0) id f18H87U17376; Thu, 8 Feb 2001 11:08:07 -0600 (CST) (envelope-from jlemon) Date: Thu, 8 Feb 2001 11:08:07 -0600 (CST) From: Jonathan Lemon Message-Id: <200102081708.f18H87U17376@prism.flugsvamp.com> To: rwatson@FreeBSD.ORG, net@FreeBSD.ORG Subject: Re: [itojun@iijlab.net: accept(2) behavior with tcp RST right after handshake] X-Newsgroups: local.mail.freebsd-net In-Reply-To: References: Organization: Cc: Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In article you write: > >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). The difficulty with this is that the peer address is being held in the inpcb, which is released by tcp_close upon receipt of a RST. So at the moment, there isn't anywhere to retrieve the sockaddr from. -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message