From: Jamie Lokier <jamie@shareable.org>
To: David Ahern <dsahern@gmail.com>
Cc: qemu-devel@nongnu.org, Paul Brook <paul@codesourcery.com>,
"Richard W.M. Jones" <rjones@redhat.com>
Subject: Re: [Qemu-devel] PATCH: enabling TCP keepalives - v3
Date: Tue, 5 May 2009 02:31:58 +0100 [thread overview]
Message-ID: <20090505013158.GB12731@shareable.org> (raw)
In-Reply-To: <49FB1979.1070706@gmail.com>
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
next prev parent reply other threads:[~2009-05-05 1:32 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-04-30 19:40 [Qemu-devel] PATCH: enabling TCP keepalives - v3 David Ahern
2009-05-01 11:32 ` Richard W.M. Jones
2009-05-01 12:23 ` Jamie Lokier
2009-05-01 12:49 ` David Ahern
2009-05-01 15:23 ` Daniel P. Berrange
2009-05-01 15:47 ` David Ahern
2009-05-01 17:21 ` Richard W.M. Jones
2009-05-05 1:31 ` Jamie Lokier [this message]
2009-05-05 2:59 ` David Ahern
2009-05-01 15:52 ` Avi Kivity
2009-05-01 16:11 ` John Haxby
2009-05-05 1:35 ` Jamie Lokier
2009-05-01 14:43 ` Anthony Liguori
2009-05-01 14:47 ` David Ahern
2009-05-01 14:51 ` Anthony Liguori
2009-05-01 15:16 ` Paul Brook
2009-05-01 15:57 ` Anthony Liguori
2009-05-01 16:04 ` Paul Brook
2009-05-01 16:11 ` David Ahern
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20090505013158.GB12731@shareable.org \
--to=jamie@shareable.org \
--cc=dsahern@gmail.com \
--cc=paul@codesourcery.com \
--cc=qemu-devel@nongnu.org \
--cc=rjones@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).