[prev in list] [next in list] [prev in thread] [next in thread] 

List:       olpc-devel
Subject:    Re: presence information
From:       "Javier Cardona" <javier () cozybit ! com>
Date:       2007-05-21 19:23:37
Message-ID: 445f43ac0705211223x21d39413wed85632e950dccff () mail ! gmail ! com
[Download RAW message or body]

Hi Polychronis,

On 5/20/07, Polychronis Ypodimatopoulos <ypod@mit.edu> wrote:
> I'm not sure exactly how presence service decides whether an XO is still
> present in the mesh or not, but I'll propose something anyway.

> Every node waits for a period T (1sec?) to receive presence frames from
> its neighbors. At the end of T, it summarizes presence information from
> those frames into one or more frames (one frame fits around 100 entries)
> and appends its own presence (MAC+TTL). At each node TTLs are decreased
> and duplicate information on the same MAC is discarded, keeping the one
> with the largest TTL. Presence frames contain a list of [MAC,TTL].
>
> Each node calculates a rate at which presence information arrives from
> all other nodes and fits the expected time until the next arrival into a
> Poisson distribution and infers with some confidence (90% should be
> fine) whether some other node is still online or not.
>
> This scheme has the following advantages:
> 1) no broadcasting to whole mesh (communication only with neighbors), so
> it should scale very well.
> 2) confidence level is independent of network latency (different rates
> are calculated for different nodes, so no one-value-fits-all)
>
> disadvantages:
> 1) on average, it takes T * {# of hops}seconds to discover node
> arrivals/departures in the mesh (as opposed to just "network latency"
> time when using broadcast).

This is a nice approach.  We did write a similar application to
discover mesh nodes.  You can find it here:
http://www.cozybit.com/projects/lsmesh

The difference in our approach was that we wanted a snapshot of the
mesh on demand.  As you well say, your method takes a longer time to
discover nodes, but scales much better.  I don't think lsmesh would
work very well if many nodes were taking snapshots simultaneously.

I'm guessing that the TTL that you talk about is a TTL specific to
this presence protocol.  All broadcast traffic would be sent with Mesh
TTL set to one (as we do in lsmesh).  Is this correct?

If you see any advantage in modifying lsmesh vs. writing your presence
daemon from scratch, go for it.  I'll be glad to help.

Cheers,

Javier
_______________________________________________
Devel mailing list
Devel@laptop.org
http://mailman.laptop.org/mailman/listinfo/devel
[prev in list] [next in list] [prev in thread] [next in thread]