[Dev] Existing p2p systems for getting offline node back up to date?

[Mike C. Fletcher]

I'm getting convinced (I've been researching this for a while now) that 
the functionality _doesn't_ yet exist as Open-Source in the form I 
thought (stand-alone P2P messaging server mechanism with message queuing 
and re-routing).

    Spread doesn't allow queues to hold over while a host is offline, 
the messages don't get auto-shared to those re-joining the group.  The 
background deamon doesn't appear to do anything with auto-forwarding or 
queuing.

    The one that I was most sure about (game systems) are using failover 
server topologies (which don't really apply to our tasks, unless we want 
to create a temporarily designated server for each group and have the 
machines actively polling each other), and don't have mechanisms for 
inter-game persistence.  I've built these at Tpresence (and also worked 
with Eric when he built the production version in Holodesk) for our VR 
MUTechs... they're not hard to create.

As a note: Groove (proprietary p2p collab. system) uses dedicated "relay 
servers" when the peer is offline. (Something I hadn't realised until 
today, I'd thought it was requiring that at least one client be active).

In the real world (i.e. within business, with servers), the packages in 
the area appear to be:
    MQSeries, IBM
    MSMQ (Microsoft Message Queuing), Guess who ;)
    JMS (Java Message Services), Lots of providers of the 
implementations, part of the J2EE

So, my apologies, but it doesn't seem that the technology is there yet 
(despite my statement).  We could probably adapt the Groove model 
(preferably using a simple mail server instead of a dedicated server). 
However, without requiring that at least one client/host be alive to 
keep the queues alive (effectively creating a failover server for the 
messaging protocol) it does appear to be a problem that requires a 
server somewhere.  

My preference would be to use the users' mail/voice-mail servers (which 
are likely professionally maintained, and use known-good approaches for 
queue management) if we can't get a direct connection.  That, 
unfortunately, leads to a lot of out-of-band communication in the user's 
primary communications media (e.g. what happens if they browse their 
in-box before Chandler gets to read and sort it).  Preferences to allow 
the user to specify only direct-connect transmission of certain messages 
(e.g. large files) would be a minimal requirement in this scenario.

Alternately, if we're willing to ask the user to run a background 
daemon, we could use those daemons as failover servers (with the 
associated risks of having servers run by neophyte users).  This 
approach is what I'd assumed Spread was doing (it has, in my 
understanding, a background daemon to which the forground tasks connect, 
but apparently there's no message queuing/failover-routing support 
within that daemon).

Enjoy,
Mike


Ray Ryan wrote:

> This is an excerpt from a discussion on the Design list.  
> <http://lists.osafoundation.org/pipermail/design/2002-November/ 
> 000896.html>
>
> On Monday, November 11, 2002, at 02:36  PM, Jeremy Hylton wrote:
>
>>>>>>> "MCF" == Mike C Fletcher <mcfletch@rogers.com> writes:
>>>>>>
>>
>>   MCF> Regarding peer-to-peer sharing: There are a number of
>>   MCF> message-passing system (Spread and the like) which support
>>   MCF> synchronisation with hosts which may be offline at the moment
>>   MCF> the message is sent (without a centralised server).
>>
>> Spread is not such a system.  Spread will deliver a message to every
>> current group member and provides a variety of reliability
>> guarantees.  In all cases, a message is delivered to currently active
>> group members.  It does not store messages.
>>
>> Spread is a very nice package, regardless.
>
>
> If Spread doesn't support this kind of thing (catching up on messages  
> delivered while offline, or otherwise getting back in sync), what does?
>
> Ray
>
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> Open Source Applications Foundation "Dev" mailing list
> http://lists.osafoundation.org/mailman/listinfo/dev
>

-- 
_______________________________________
  Mike C. Fletcher
  Designer, VR Plumber, Coder
  http://members.rogers.com/mcfletch/