Actually, that is not correct
Replies to the original questions and to the replies are in the body.
Lord Soth wrote:
>On Sunday 01 September 2002 14:03, Michael Sternberg wrote:
>
>
>>Sorry if I'm starting a long thread with this letter :)
>>I digged through the Google and did not find anything that
>>will fully answer me to the next questions:
>>
>>1. How can I reproduce situation that my code will leave
>> sockets in CLOSE_WAIT state ?
>>
Close_wait happens when you closed the connection before the other side
did, or you both closed it together (not as rare as it may seem). It is
used by the TCP layer to keep track of the state in case the ACK that
confirmed the last FIN was lost, and needs to be retransmitted. This
state goes away by itself after 2 MSLs (usually, around two minutes).
>>
>>2. What measures can I take to prevent them to appear ?
>>
For all practical purposes, nothing. They are necessary. You can make
sure you never close the connection first ;-). If the connection was
closed using a RST instead of a FIN, that would not happen, but I know
of little non-priveleged user mode ways of doing that (mostly - killing
the app that held the socket would do that, but I doubt this is what you
want).
>>
>>3. Why can't I release them from outside with some utility ?
>>
You can try a packet generator to send a RST to the connection. I doubt
that is worth it, though.
>>
>>4. (Optional question) I got the feeling that situation in M$ world
>> with sockets hanging around is a little better. Am I right and
>> why is that ?
>>
>>
I wouldn't presume.
>
>1. As you may or may not know, a CLOSE_WAIT state happens when
>your side (be it server/client) receives a FIN while the connection is
>established. This tells the TCP driver that the other side no longer wishes
>to send data through the connection. It responds with an ACK to the other
>side. If the other side sent a FIN and it was ACKed, the conneciton goes
>to CLOSE_WAIT and your application receives EOF when using read()
>from the socket's file descriptor.
>
No, the connection goes to "FIN_WAIT1" or "FIN_WAIT2", depending on
which is the side that sent the FIN first.
>The next obvious thing to do on most normal situations it to call close()
>to send a FIN as well as flush any remaining data (usually attempted to be
>sent). If you want to be able to generate CLOSE_WAITs, make sure the
>other side closes the connection but yours remains open (intercepting the
>EOF and doing whatever you fancy..)
>
>2. Detect read() returning EOF naturally... :)
>
>
Like I said, that is not relevant for CLOSE_WAIT. During "CLOSE_WAIT"
the OS is the only one keeping the socket alive. The application has
already released it.
You may also want to attempt strange tricks, such as sending FIN only on
one end of the connection using "shutdown" instead of "close". RTFM for
more details. In general, using shutdown and then close is preferable to
using close immediatly. You can control flushes, for one thing.
Shachar
=================================================================
To unsubscribe, send mail to [EMAIL PROTECTED] with
the word "unsubscribe" in the message body, e.g., run the command
echo unsubscribe | mail [EMAIL PROTECTED]
