Robert Watson writes:
> > 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 makes the most sense to me.
If you get an error from accept(), the implication (in my mind,
and I suspect many others) is that the error is with the *listening*
socket. If the error is really with the *new* socket then the error
should "wait" until a read(), getpeername(), etc.
-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
