On Sun, Jun 20, 2010 at 10:41 PM, Florian Pflug <fgp@phlo.org> wrote:
> Yeah, especially since there is no such thing as a special "keepalive" packet in TCP. Keepalive simply sends packets
withzero bytes of payload every once in a while if the connection is otherwise inactive. If those aren't acknowledged
(likeevery other packet would be) by the peer, the connection is assumed to be broken. On a reasonably active
connection,keepalive neither causes additional transmissions, nor altered transmissions.
Actualy keep-alive packets contain one byte of data which is a
duplicate of the last previously acked byte.
>
> Keepalive is therefore extremely unlikely to break things - in the very worst case, a (really, really stupid)
firewallmight decide to drop packets with zero bytes of payload, causing inactive connections to abort after a while.
AFAIKwalreceiver will simply reconnect in this case.
Stateful firewalls whole raison-d'etre is to block packets which
aren't consistent with the current TCP state -- such as packets with a
sequence number earlier than the last acked sequence number.
Keepalives do in fact violate the basic TCP spec so they wouldn't be
entirely crazy to block them. Of course a firewall that blocked them
would be pretty criminally stupid given how ubiquitous they are.
> Plus, the postmaster enables keepalive on all incoming connections
*already*, so any problems ought to have caused bugreports about
dropped client connections.
Really? Since when? I thought there was some discussion about this
about a year ago and I made it very clear this had to be an optional
feature which defaulted to off.
Keepalives introduce spurious disconnections in working TCP
connections that have transient outages which is basic TCP
functionality that's supposed to work. There are cases where that's
what you want but it isn't the kind of thing that should be on by
default, let alone on unconditionally.
--
greg
