My mistake.
I rechecked, and "lordsoth"'s reply is the correct one. Sorry about the
unnecessary noise.
Shachar
Shachar Shemesh wrote:
> 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]
>
>
>
=================================================================
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]
