mesh portal discovery

[david at lang.hm]

On Sat, 12 Jan 2008, Benjamin M. Schwartz wrote:

> 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.  I understand that mesh splits are inevitable, but every
> effort should be undertaken to minimize their frequency.
>
>>> 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.


there are huge differences between the different scenerios that you 
mention.

moving around in the mesh is completely under the control of one entity 
and should be able to be completely transparent.

moving from one Internet-connected wireless network to another is much 
harder, almost impossible to do without the cooperation fo the different 
providers involved.

I think that a lot of the problem here is that the different scenerios 
keep getting mixed up, so we don't have solutions for the easy ones 
becouse those solutions won't solve everything.

the full solution to every scenrio is MobileIP, but that's a topic of 
research papers, nobody knows how to work out all the problems, even in 
theory, let alone in the real world.

David Lang