🚀 go-pugleaf

> I'm not sure that I follow your examples, Julian.
>  
> > A client opens a connection and asks questions of it. The server replies.
> > The client goes away and does something with this information
>  
> If the server has this connection open, it must occasionally poll
> (i.e. select()) the socket, or it must dedicate a process to perfrom
> a blocking read() on the socket.  In either case, if the client end
> blows up, the server end will be notified:  either the read() will return
> an error, or the select() will return TRUE with an indication that the
> connection is gone.
No - you have the wrong idea I think - according to my understanding
of TCP anyway.

If you open a TCP connection, the only way you can find if it goes
away is if the remote machine sends a disconnect sequence or you can't
reach it after several retries. However, if the remote machines
crashes it will not send a disconnect - it won't send anything at all.
If you send a packet to the machine when it reboots it can tell that
the sequence number is wrong and shut the connection and everyones
happy. If you never send anything to it though, you don't know if its
up or down. So, if the remote side crashes, and the connection was
idle at that point and you do not send any more data (e.g. you are
waiting for another request) you don;t know if the remote client is up
or down or what. At the unix level, a read will block for ever, and a
select will never select it for reading.
You can see this behaviour with X windows, you have an xterm on a
remote host that crashes, the window stays up. As soon as you type a
character in though, it attempts to send this, finds the host is dead
or rebooted and the window connection breaks.

Of course if the *application* crashes (and the machine doesn't), the
kernel detects this and initiates a close/abort.


Julian.