From owner-freebsd-net Fri Mar 9 9:42: 6 2001 Delivered-To: freebsd-net@freebsd.org Received: from prism.flugsvamp.com (cb58709-a.mdsn1.wi.home.com [24.17.241.9]) by hub.freebsd.org (Postfix) with ESMTP id 49A5F37B71F for ; Fri, 9 Mar 2001 09:42:03 -0800 (PST) (envelope-from jlemon@flugsvamp.com) Received: (from jlemon@localhost) by prism.flugsvamp.com (8.11.0/8.11.0) id f29HdSk27992; Fri, 9 Mar 2001 11:39:28 -0600 (CST) (envelope-from jlemon) Date: Fri, 9 Mar 2001 11:39:28 -0600 From: Jonathan Lemon To: itojun@iijlab.net, net@freebsd.org Subject: Re: [itojun@iijlab.net: accept(2) behavior with tcp RST right after handshake] Message-ID: <20010309113928.I78851@prism.flugsvamp.com> References: <20010308161611.B78851@prism.flugsvamp.com> <25798.984117381@coconut.itojun.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i In-Reply-To: <25798.984117381@coconut.itojun.org> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, Mar 09, 2001 at 02:56:21PM +0900, itojun@iijlab.net wrote: > > >From the server's point of view: > > > > + TCP/IP handshake from client, allocate protocol control blocks > > + receive data from client > > + client resets connection, pcb is destroyed > > > >Exactly why the client resets the connection isn't my concern at > >the moment. Some stacks may place a timeout on the FIN_WAIT state, > >and forcibly reset the reset the connection when the timer expires. > >Alternatively, the client may crash, and then RST in response to > >an ACK transmitted by the server. Or the other end may have set > >SO_LINGER, which will cause close() to send a RST. > > > >The unix-domain bug is because we were treating sockets in the > >DISCONNECTED state identically across all protocols, which turns > >out not to be the case. > > > >As for any data that already exists in the socket buffer on the > >server when the connection is aborted, I believe that the correct > >thing to do is discard it. This is the historical precedent, and > >is supported by the current standards. > > > >Below is a patch that will fix the behavior for unix-domain sockets. > > from code inspection on netbsd, I guess you'd need to do something for > other sys/net* families. maybe we need another per-domain/per-socket > flag for this? That might be cleaner in the long run rather than putting the test into each protocol layer. However, since FreeBSD is coming up on a release, I don't want to make an immediate change. I've only changed tcp/tcp6 behavior. The only other protocols that I know of that might need changing are ipx and aal; these will probably return EINVAL instead of ECONNABORTED at the moment. I think that the correct long term behavior would be to make the peer name available to the socket regardless of the state of the protocol connection (either hold the protocol block, or copy the name up to the socket layer). Then, restore the previous behavior of always returning a valid fd for the socket, even if the peer is closed. This provides two things: 1. The application is able to get the address of the peer who connected (whowever briefly). I've seen some requests for this particular feature. Doing this fixes the bug with DNS and Apache, which assume the returned address is valid. 2. The app will still be able to retrieve any data that is sitting in the TCP socket buffers, which might be desired in the TCP case (just as it is in the unix-domain case) -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message