qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] PATCH: enabling TCP keepalives - v3


From: Jamie Lokier
Subject: Re: [Qemu-devel] PATCH: enabling TCP keepalives - v3
Date: Tue, 5 May 2009 02:31:58 +0100
User-agent: Mutt/1.5.13 (2006-08-11)

David Ahern wrote:
> > You don't neccessarily always get a different IP for VPN connections,
> > as administrators may well choose to give users a fixed IP for their
> > VPN client. I'm not entirely against keepalives, but I thing making
> 
> Agreed, you don't always get a different IP on reconnects, but in my
> case you do. Also, VPN users have no control over that; they just
> see/cause dead connections.

Sometimes I use a VPN to keep connections going when the underlying
network changes.

E.g. when suspend the laptop at work, taking it home, resuming, my
personal VPN means some connections (such as SSH sessions) are not
broken despite a short commute with the laptop off, and waking up on a
different network :-)

This is also handy when switching between a house network and a mobile
3G network, or between wireless networks.  SSH sessions continue
working because of the stable VPN on top.

For this I don't care about the encryption aspect so much as the VPN's
ability to maintain a stable IP despite the underlying network
changing.

So it does get used that way.

> The parameters I put in cause a drop after 2 minutes of no response --
> 60 seconds of idle (no data through the socket) followed by 60 seconds
> of failed probes. The default parameters for linux are harsh: 7 hours of
> idle time before the first keepalive is sent.

Is 7 hours a problem worth overriding the kernel defaults for?  How
many old VNC sessions are likely to get accumulated in that time?

2 minutes is a bit fast for a truly idle session, but as I said in
another response, if you have data sent by either end, then the
session will be broken by the lack of response in about 2 minutes
anyway - without keepalives.

-- Jamie




reply via email to

[Prev in Thread] Current Thread [Next in Thread]