From owner-freebsd-net Thu Mar 8 13:18:31 2001 Delivered-To: freebsd-net@freebsd.org Received: from spike.porcupine.org (spike.porcupine.org [168.100.189.2]) by hub.freebsd.org (Postfix) with ESMTP id D432937B719 for ; Thu, 8 Mar 2001 13:18:24 -0800 (PST) (envelope-from wietse@porcupine.org) Received: by spike.porcupine.org (Postfix, from userid 1001) id EE154BC06D; Thu, 8 Mar 2001 16:18:23 -0500 (EST) Subject: Re: [itojun@iijlab.net: accept(2) behavior with tcp RST right after handshake] In-Reply-To: "from Jonathan Graehl at Mar 8, 2001 01:00:14 pm" To: Jonathan Graehl Date: Thu, 8 Mar 2001 16:18:23 -0500 (EST) Cc: Wietse Venema , Freebsd-Net X-Time-Zone: USA EST, 6 hours behind central European time X-Mailer: ELM [version 2.4ME+ PL82 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Message-Id: <20010308211823.EE154BC06D@spike.porcupine.org> From: wietse@porcupine.org (Wietse Venema) Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org 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