Date: Thu, 8 Mar 2001 14:30:23 -0800 From: Alfred Perlstein <bright@wintelcom.net> To: Jonathan Lemon <jlemon@flugsvamp.com> Cc: Wietse Venema <wietse@porcupine.org>, itojun@iijlab.net, Arjan.deVet@adv.iae.nl, net@FreeBSD.ORG, postfix-users@postfix.org Subject: Re: [itojun@iijlab.net: accept(2) behavior with tcp RST right after handshake] Message-ID: <20010308143022.E18351@fw.wintelcom.net> In-Reply-To: <20010308161611.B78851@prism.flugsvamp.com>; from jlemon@flugsvamp.com on Thu, Mar 08, 2001 at 04:16:11PM -0600 References: <20010308095759.S41963@prism.flugsvamp.com> <20010308180048.CC09DBC06D@spike.porcupine.org> <20010308161611.B78851@prism.flugsvamp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
* Jonathan Lemon <jlemon@flugsvamp.com> [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. 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?20010308143022.E18351>