Date: Thu, 8 Mar 2001 16:18:23 -0500 (EST) From: wietse@porcupine.org (Wietse Venema) To: Jonathan Graehl <jonathan@graehl.org> Cc: Wietse Venema <wietse@porcupine.org>, Freebsd-Net <freebsd-net@freebsd.org> Subject: Re: [itojun@iijlab.net: accept(2) behavior with tcp RST right after handshake] Message-ID: <20010308211823.EE154BC06D@spike.porcupine.org> In-Reply-To: <NCBBLOALCKKINBNNEDDLKECLDMAA.jonathan@graehl.org> "from Jonathan Graehl at Mar 8, 2001 01:00:14 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
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 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?20010308211823.EE154BC06D>