Date: Fri, 9 Mar 2001 11:39:28 -0600 From: Jonathan Lemon <jlemon@flugsvamp.com> 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> In-Reply-To: <25798.984117381@coconut.itojun.org> References: <20010308161611.B78851@prism.flugsvamp.com> <25798.984117381@coconut.itojun.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010309113928.I78851>