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.:
It was a rhetorical question. I like Robert's suggestion to return
the socket but have the first operation on the socket fail.
If you want to positively verify the new socket you can do a
getpeername(), etc.
> 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.
IMHO the app is more likely to close the listen socket and stop
accepting new connections if it gets an error from accept().
For example, from an initial scan of sendmail (daemon.c:403) if
it gets an error from accept(2) it will close the (listen) socket
and reopen it. Sendmail is robust enough not to "break" but this
shows that if it gets an accept(2) error it assumes the problem is
with the *listening* socket, not the new socket.
-Archie
__________________________________________________________________________
Archie Cobbs * Packet Design * http://www.packetdesign.com
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
