Date: Thu, 8 Feb 2001 11:08:07 -0600 (CST) From: Jonathan Lemon <jlemon@flugsvamp.com> To: rwatson@FreeBSD.ORG, net@FreeBSD.ORG Subject: Re: [itojun@iijlab.net: accept(2) behavior with tcp RST right after handshake] Message-ID: <200102081708.f18H87U17376@prism.flugsvamp.com> In-Reply-To: <local.mail.freebsd-net/Pine.NEB.3.96L.1010208114105.30518A-100000@fledge.watson.org> References: <local.mail.freebsd-net/200102080524.VAA54629@curve.dellroad.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In article <local.mail.freebsd-net/Pine.NEB.3.96L.1010208114105.30518A-100000@fledge.watson.org> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200102081708.f18H87U17376>