[p2p-hackers] Keep Alive and network performance

[David Barrett]

Well, in practice keep-alives seem to do well despite the theoretical worst
case.  Really it's a balance between the importance of fast dirty-disconnect
detection and bandwidth.  If the feature is critical to your application,
the bandwidth is worth it.  If the feature isn't, then the bandwidth is
wasted.

If you're writing an IM-like tool, the general standard seems to be to
detect coming online instantly (eg, you contact everyone on your buddy list
the moment you come online), detect clean disconnects instantly (eg, notify
everyone before you go offline), and then notice dirty disconnects after
several seconds or more (eg, using keepalives).  Thus IM-like presence in a
world where most clients disconnect in a clean fashion (which, incidentally,
is the world we live in) doesn't take much keep-alive traffic at all because
the ping frequencies are so low (10+ seconds?).

But another entirely separate (and more valuable?) use of keepalives is to
keep NAT mappings alive in a hole-punching scenario.  With iGlance (which is
being presented at CodeCon on Saturday) I use an adaptive approach where I
look for the slowest keepalive frequency that works.  Adaptiveness is
critical, as I've seen some NATs that start with 5-second windows, but grow
up to 256-second windows over time.

-david

> -----Original Message-----
> From: p2p-hackers-bounces at zgp.org [mailto:p2p-hackers-bounces at zgp.org] On
> Behalf Of Daniel B.
> Sent: Thursday, February 09, 2006 7:31 AM
> To: Peer-to-peer development.
> Subject: Re: [p2p-hackers] Keep Alive and network performance
> 
> In an optimistic communications should not use pings per say. My
> preference is just to write the data. To deal with optimism, in some
> cases, you do need feedback. A couple of choices are to use checksums
> or last-heard-from in your data.
> 
> There are many complex issues here. Many of them depend on the P2P
> network and your application. Speed of notification is only sometimes
> important. If you are sending data via relayed machines, it would be
> better to stop a send soon, when the destination disappears. If the
> relays store for a later forward, the source does not care that the
> destination is up or down because the destination will eventually get
> the message.
> 
> If we assume infinite bandwidth and computers that can never be
> flooded by bandwidth, its all cool. If we assume spotty wifi and 5
> year old computers, the solutions need to be carefully implemented to
> avoid failures.
> 
> On Feb 9, 2006, at 1:34 AM, Matthew Gertner wrote:
> 
> > Daniel B. wrote:
> >
> >> Keep alive is both a missing component in practical P2P and a
> >> reason  why P2P is also hard to make practical.
> >>
> >> The trap is that the keep-alive is between two machines. Imagine
> >> hundreds of thousands of machines!!!! Even with small signatures
> >> matching each machine, we are talking about a flooded network. A
> >> secondary trap is managing reliability. Reliability in P2P is not
> >> moving bytes back and forth, but also taking into account the
> >> machine  may be a laptop or other personal computer that has a
> >> pathetic uptime.
> >>
> >> The better choice is online/offline signaling and optimistic
> >> communications with good error control.
> >
> > I assume that by "optimistic communications" you mean that we
> > should assume a connection exists and confirm this using periodic
> > pings? Isn't this basically the equivalent of KA? It seems to me
> > that the fundamental tradeoff is speed of notification vs. extra
> > network traffic (i.e. you know more quickly when someone's network
> > connection is cut if you ping more often), and this is the case
> > both for KA and for a custom optimistic approach that uses pings.
> > Am I missing something?
> >
> > Cheers,
> > Matt
> > _______________________________________________
> > p2p-hackers mailing list
> > p2p-hackers at zgp.org
> > http://zgp.org/mailman/listinfo/p2p-hackers
> > _______________________________________________
> > Here is a web page listing P2P Conferences:
> > http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences
> >
> 
> _______________________________________________
> p2p-hackers mailing list
> p2p-hackers at zgp.org
> http://zgp.org/mailman/listinfo/p2p-hackers
> _______________________________________________
> Here is a web page listing P2P Conferences:
> http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences