mesh portal discovery

Sjoerd Simons sjoerd at luon.net
Sat Jan 12 09:29:56 EST 2008


On Thu, Jan 10, 2008 at 02:29:15PM -0500, Benjamin M. Schwartz wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Morgan Collett wrote:
> > We'll add some API to PresenceService and sugar.presence, and put some
> > signal into Sugar similar to the buddy-left signal to indicate you were
> > disconnected, and ensure that the activity gets back into an unshared state.
> > 
> > If we find the shared activity ID in presence we can attempt to rejoin,
> > handing switching of one IP address to another without changing from
> > gabble to salut (or vice versa).
> > 
> > Then Activities will only need to hook the disconnected signal to clean
> > up state, if that is necessary.
> 
> This is not an acceptable long-term solution.  It means that whenever people
> are moving about the mesh in a multi-server environment, their activities
> will spontaneously disconnect, and possibly reconnect some time later.  This
> is hugely disruptive to activities with shared state, continuous action, or
> just about any other collaboration style.  From the users' perspective, it
> will inevitably render the sharing system unreliable and frustrating.

Activities need to cope with people coming going anyway. If your in a mesh only
environment, the mesh can be split into two or more parts at any point and
later on merge again. Salut will model that as people disconnecting and later
on connecting again, your application _must_ be able to synchronize the shared
state if needed in some way.

> As an example, consider two students using Distance (my activity) to measure
> out a distance of 15 meters.  As they move apart, one of them switches into
> the domain of another mesh-portal, and its IP address changes.  It suddenly
> drops out of the activity, and measurement stops.  Some time later, it may
> rejoin automatically, at which point the students will have to reinitiate
> measurement manually.
> 
> If IP address switches are triggered automatically, and silently, then they
> must be handled automatically, and silently.

That's mostly up to the application. Telepathy shouldn't hide the fact that
we're not actually connected anymore and applications should do something
usefull with that info. A better long term solution would probably to use
mobile IP, so you don't get disconnected when switching between networks.

  Sjoerd
-- 
A transistor protected by a fast-acting fuse will protect the fuse by
blowing first.



More information about the Devel mailing list