Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 09 Mar 2001 14:56:21 +0900
From:      itojun@iijlab.net
To:        Jonathan Lemon <jlemon@flugsvamp.com>
Cc:        Wietse Venema <wietse@porcupine.org>, 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:  <25798.984117381@coconut.itojun.org>
In-Reply-To: jlemon's message of Thu, 08 Mar 2001 16:16:11 CST. <20010308161611.B78851@prism.flugsvamp.com>

next in thread | previous in thread | raw e-mail | index | archive | help

>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?

itojun

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?25798.984117381>