Jonathan Graehl:
> > > Data CAN be lost if the TCP connection is RST. It has nothing to
> > > do with the ordering of accept() with respect to close().
> >
> > Please educate me: how would RST come into this discussion at all?
> > The client does connect() write() close(), there is no forced
> > connection termination involved at all.
>
> If you set the SO_LINGER socket option, a close() may generate RST and discard
> socket buffers/TCP state, as opposed to the standard behavior of keeping the
> data around and resending until the data and the FIN are acknowleged by the
> other end. I am not sure why this is supposed to be a good idea, though, but
> obviously, if you set that option, you are unconcerned about data loss, or you
> have already guarded against it with application-level acknowledgment.
The discussion is about connect() write() close(). My intention is
not to lose data after write() and close() return success. This is
how all reasonable UNIX-domain socket implementations (*) have worked
under Postfix for the past couple years.
(*) This does not include Solaris UNIX-domain sockets. Postfix
never worked reliably with those, and I had to use a different
local IPC method for Solaris.
> Let's agree: it is okay for accept to return an error code indicating the
> connection has already been terminated, so long as any data sent by the client
> (such that the client had every indication that it was received) is still
> available for the acceptor to read.
As in, accept() returns a valid descriptor AND sets errno at the
same time? Why can't it just succeed, and have read() return EOF
as appropriate? I mean, you don't blow away server-side buffered
data whenever the client closes a socket.
Wietse
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
