Re: Spipe doesn't close when (established) connection times out (due to sleeping, network interruption, etc)

[Colin Percival <cperciva@tarsnap.com>]

On 11/18/12 13:47, Blake Rainwater wrote:
> The client connects to the server notification daemon by using spipe,
> and then pipes the output of spipe to the monitor-sync function, which
> has an infinite read loop in it. When the server daemon is killed, the
> socket is closed and then the client side program closes out properly
> (since spipe closes), however when it is disconnected (wifi turned
> off, network cable unplugged, client put to sleep, etc) for a very
> long time (e.g. overnight), and then (the network) is connected again,
> the client side daemon does not receive updates anymore, but spipe
> remains as if it were still connected. With short disconnections
> (tested up to the order of minutes, however I suspect that it may be
> up to a few hours) the client receives any updates that occurred
> during the disconnection, and the notifications work properly.

Ok, I'm guessing what's happening here is:
1. Your server daemon writes something to its socket;
2. This is read by spiped, which encrypts it and sends it to your netbook;
3. Either a network device sends back a RST because your netbook is not
connected, or your server gets tired of retransmitting, and the operating
system resets the connection;
4. On the server, spiped sees the connection reset, and closes the other
end of the connection.
5. When your laptop wakes up, it sees a lack of traffic and interprets
this as simply being a lack of traffic.

In this sense, spipe/spiped is acting exactly the same way as if you had
a direct TCP connection -- but a TCP connection without keepalives turned
on, whereas many programs enable them.

Probably the best solution here is for me to add SO_KEEPALIVE by default
and add a command-line option to disable it.  Ultimately it's a matter of
balancing dropping connections when you're really gone vs. not dropping
them in the event of temporary network glitches.

> If you have any suggestions for me, or further description of the
> conditions when the spipe and/or spiped daemon shuts down or triggers
> disconnections, they would be appreciated.

The connection handling of spipe/spiped is TCP-transparent: If one end of
the connection is shut down, a shutdown will be passed through; and the
connection is closed if it is shut down in both directions OR if there is
an error in either direction.

-- 
Colin Percival
Security Officer Emeritus, FreeBSD | The power to serve
Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid