From: Yohanes Santoso <ysantoso-rubytalk@...>
Date: 2005-07-08T07:36:52+09:00
Subject: Re: Socket Question - close

David Brady <ruby_talk@shinybit.com> writes:

> Yohanes Santoso wrote:
>
>>It is not straight forward for TCP connection. Other transport-level
>>protocol may have other mechanism to reliably detect and indicate
>>connection termination.
>>
>>
> I use some undocumented side-effects to detect if the remote has
> closed the connection.  On a TCPSocket, I find that select will
> immediately return the socket once the remote has closed, but
> socket#gets will return nil.  In any valid transmit condition, if
> select returns the socket, then gets will return valid data.

This is a documented behaviour. I covered this in my previous post:

<previous post>
1. Your OS receives the FIN packet generated when the remote end does
a close(). select() will say that there is data to be read (the FIN
packet), and when you do a read, it will return with 0 data (since the
FIN packet is a transport-level business and does not contain
app-level data). if you try to write to such socket, you'll get EPIPE.
</previous post>

Basically, you don't have to select(), just a read() is enough to read
in the FIN packet and trigger the TCP stack to realise the socket has
been closed by the other side. The select() is there to emphasize
there is data to be read, although that data is not app-level
data. Each time you do a non-zero read() and got a nil, then it means
the other side has closed down.

So, don't worry about using this. Use this liberally :) 

YS.