Date: Thu, 8 Feb 2001 11:01:31 -0600 (CST) From: Jonathan Lemon <jlemon@flugsvamp.com> To: archie@dellroad.org, net@freebsd.org Subject: Re: [itojun@iijlab.net: accept(2) behavior with tcp RST right after handshake] Message-ID: <200102081701.f18H1Vp17229@prism.flugsvamp.com> In-Reply-To: <local.mail.freebsd-net/200102080524.VAA54629@curve.dellroad.org> References: <local.mail.freebsd-net/20010207194040.O650@prism.flugsvamp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In article <local.mail.freebsd-net/200102080524.VAA54629@curve.dellroad.org> you write: >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?? Because the connection may be broken between the point where we've notified the user that there is a valid connection, and when accept returns. E.g.: 1. SYN, SYN/ACK, ACK (connection accepted) 2. select/poll/kevent wakes up 3. RST arrives (connection aborted) 4. user calls accept() Now, (assuming there is no other pending connection), there's three choices: an error return, return with with a zero-sized addrlen, or block/EWOULDBLOCK. While the latter seems to be the most attractive, it would probably break the most semantics, since the select call did indicate there was a pending connection. So this means that the app must either test for ECONNABORTED, or test the addrlen before using the returned sockaddr. I would guess that code is more likely to check for an error return from accept() than it is to check the return size from the sockaddr, so this change will proabably not result in breaking a large amount of code. -- 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?200102081701.f18H1Vp17229>