Hi,

I had a question about simultaneous close in TCP.
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.

Lets say the other end (client) sends back a FIN at
the same time (simultaneous close), thereby moving the
server to the CLOSING state. Lets say that after
sending this FIN, the client dies/disappears (for some
reason). 

The server will wait for the ACK which will move him
to the TIME_WAIT state but that ACK will never come. I
was looking at the code and there is NO timeout in the
CLOSING state. Does that mean that it will remain
stuck in that state in the scenario described above.

Is this by design ? Can this be taken care of ? Do we
need to change the TCP code or should the application
be using some socket option to take care of this
situation ?

I looked at the archives and found only one mention of
stuck in CLOSING that had to do with a window of 0
being advertised by the client. But, what about the
simple case of the client dying before sending the
final ACK. Also, it had enough space in its recv
buffer and hence did not need to advertise a window of
0 while sending its FIN.

In this case, the TCP code does not seem to be turning
on the PERSIST timer (or, for that matter, any other
timer) when we are moving from FIN_WAIT_1 state to
CLOSING state.

Any help will be really appreciated.

Thanks,
tapan.


		
_______________________________
Do you Yahoo!?
Win 1 of 4,000 free domain names from Yahoo! Enter now.
http://promotions.yahoo.com/goldrush