mesh portal discovery

[Sjoerd Simons]

On Sat, Jan 12, 2008 at 12:00:02PM -0500, Benjamin M. Schwartz wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Sjoerd Simons wrote:
> > 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.
> 
> "cope" is exactly the right word.  It is simply impossible, in many cases, to
> handle a mesh split without disruption.  For example, any code that creates a
> distributed lock will fail if the group splits and rejoins.  If your Activity
> uses this common structure, then there will inevitably be a major
> discontinuity when the group rejoins.

Distributed locks aren't a good design to use in activities even without the
splitting problem, their usually very sensitive to latency. Which is something
you shouldn't assume to be low in any case. Especially in case of temporary
network issues, it can easily take multiple minutes for a message to arrive at
one or all your nodes.

>I understand that mesh splits are inevitable, but every effort should be
>undertaken to minimize their frequency.

Ofcourse. And we do try to minimise it. But your application really should be
designed to cope with splitting and merging, because it will happen in the
field. I would recommend everyone to take this as a basic requirement when
designing your protocols. And don't hesitate to ask us (the Collabora) people
for advise in specific cases.

> >> 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.
> 
> This is precisely what I am saying.  Telepathy should only register a
> disconnect if there is no way to route between two XOs.  The mesh system
> should be designed so that moving about within the mesh, or handing off
> between Salut and Gabble, or switching from one internet-connected wireless
> network to another, does not cause a Telepathy disconnect.
> In each of these cases, the path between XOs remains routable, with a gap of
> at most a few seconds.  I understand that this is not easy, and that it will
> not be implemented immediately, but we should not profess ourselves satisfied
> with anything less reliable.

Well. The simplest way to do that is to have some nice helper classes, that
will can reconnect and reshare your activity if you get disconnected.

But it is still up to the application to recover from this nicely, which is
basically recovering seeing from everyone splitting away from you and coming
back again.... Hmmm, that does look a lot like the mesh-splitup issue, we
mentioned earlier on.. :)

  Sjoerd
-- 
The price of success in philosophy is triviality.
		-- C. Glymour.