[e2e] RST effect on socket buffers?

[Joe Touch]

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



Joe Touch wrote:
|
|
| Tapan Karwa wrote:
| |>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."
| |
| |
| | What about the following simultaneous close case :
| |
| | If I am a server in the ESTABLISHED state and I
| | perform a close() on the socket, I will send a FIN to
| | the other end and move to FIN_WAIT_1 state.
|
| Only after all outstanding data your side is sending is ACKd. Then the
| FIN is sent, etc...

Correction (thanks Ted) - the FIN doesn't wait for the data to be ACKd,
but it does wait for you to send all your pending data. Only then does
it enter FIN_WAIT_1.

Joe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFB3IsXE5f5cImnZrsRAgISAKDmOdJym9IN49+VnlvbjipPNn9LDwCfbXN1
Ct4YtCnKVwUK7fk+BZZ4w2g=
=+b4J
-----END PGP SIGNATURE-----