[e2e] RST effect on socket buffers?

[Joe Touch]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Tristan Horn wrote:
| Hi all,
|
| I find myself wrestling with a vendor to get their HTTP proxy's
| half-closed connection handling fixed.
|
| One of the issues is that their hardware sends a spurious RST to the
| client after a 60 second timeout.  The effect is that any data remaining
| in the client TCP's receive buffer appears to vanish; the application is
| not able to read it.

There seems like a bunch of bugs here:

	- poor choice of timeout value
		i.e., 1/2 MSL is far too short

	- assuming a timeout is appropriate at all
		there's nothing in TCP that requires a timeout for
		a half-closed connection

	- sending a RST because of that timeout
		RSTs aren't there to clean-up state, UNLESS that
		state interferes with new connections (SYN to a
		CONNECTED session)

| My casual reading of RFC 793 suggests that this behavior is expected:
| * a connection in e.g. ESTABLISHED state will transition to CLOSED upon
|  the receipt of a valid RST,
| * "CLOSED" == "non-existent"

Yes. Segments are flushed (pg 71)

| The vendor doesn't agree.  I also seem to only be able to replicate the
| problem on Windows, not e.g. Linux...
|
| Can anyone shed light on what the expected behavior here is (if any)?

If the connection is half-closed, that means the receiver ACK'd the FIN.
That means all the data up to the seq number of the FIN has been
received successfully by TCP. The question is whether the application
has received the data yet. You know that only when the other side issues
a CLOSE; anything short of that, and you don't know whether the app has
the data or not.

Sending a RST to a connection when you're in FIN_WAIT1 is KNOWING that
you're trashing whatever data remains in the receive buffers; since you
can't know whether the data is in the receive buffers or the app, you're
taking your chances. If that's not what you intended, then wait for the
FIN-ACK and close like the spec says ;-)

The basic lesson here is "You can't force behavior on the other end of
the connection."

Joe

| (No need to convince me that the untimely RST itself is broken, BTW -- I
| think/hope we've agreed on that point already.)
|
| thanks!
|
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFB3DKdE5f5cImnZrsRAsaUAKDcfb/+qP2h7+RZQKTbCJGOuE28BACgq++q
hTcp7OR76r/M9lmqALh9heA=
=Xb5b
-----END PGP SIGNATURE-----