On Thu, Mar 08, 2001 at 02:30:23PM -0800, Alfred Perlstein wrote:
> * Jonathan Lemon <[EMAIL PROTECTED]> [010308 14:19] wrote:
> > On Thu, Mar 08, 2001 at 01:00:48PM -0500, Wietse Venema wrote:
> > > Jonathan Lemon:
> > > > On Thu, Mar 08, 2001 at 10:38:17AM -0500, Wietse Venema wrote:
> > > > > If the result of connect() write() close() depends on whether
> > > > > accept() happens after or before close(), then the behavior is
> > > > > broken. The client has received a successful return from write()
> > > > > and close(). The system is not supposed to lose the data, period.
> > > >
> > > > What you seem to be missing here is that the behavior described
> > > > above is ONLY specific to UNIX-DOMAIN sockets. The description
> > > > above is generally (but not always) true for the TCP/IP protocol.
> > >
> > > The problem is observed with UNIX-domain sockets.
> > >
> > > > 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.
> >
> > Under normal circumstances, a connect(), write(), close() call
> > should work. However, the code that was added was to handle the
> > abnormal cases from the server's point of view.
>
> Just make sure your patch is ok with the unix file descriptor
> passing garbage collection code, it seems to rely on socket state
> to get things right.
It doesn't change any of the socket state, nor does it touch the
SS_NOFDREF flag, so the gc algorithm should be okay. Actually, all
I'm doing here is pushing the decision down to each protocol, rather
than short-circuiting the test at the socket layer.
--
Jonathan
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
