[e2e] RST effect on socket buffers?

[Joe Touch]

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



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

| Lets say the other end (client) sends back a FIN at
| the same time (simultaneous close), thereby moving the
| server to the CLOSING state.

Agreed.

| Lets say that after
| sending this FIN, the client dies/disappears (for some
| reason, valid or invalid).

OK. Machine could just reboot.

| The server will wait for the ACK which would have
| moved him to the TIME_WAIT state but that ACK will
| never come. So, the server will be stuck in the
| CLOSING state, since there is no timeout associated
| with that state.

None with that state per se, but there's a retransmission timer. The
server should be resending its FIN because it hasn't received the
FIN-ACK yet. When one of these FINs reaches the other end (which is
rebooted and has no state), a RST will be generated in response. That'll
clean up both ends, as it's intended to do.

The more interesting case would be if the other end never comes back. In
that case, you'd stay retransmitting FINs forever, and stay in the
CLOSING state forever as well.

| Is that ok ?

I think there is a timeout, just not one that bumps you out of the state
if the other end isn't there. TCP doesn't clean up state to save memory;
it cleans up state when it interferes with a new connection.

Joe

| thanks,
| tapan.
|
|
| 		
| __________________________________
| Do you Yahoo!?
| Yahoo! Mail - Easier than ever with enhanced search. Learn more.
| http://info.mail.yahoo.com/mail_250
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFB3FmfE5f5cImnZrsRAtFlAJ0TTERdqN3xG2vAc4Sn7FUY2XKO8gCgzr4r
/UV+40DDzbOEVZRQmWOaNhk=
=Sgiz
-----END PGP SIGNATURE-----