 |
[Dev] Existing p2p systems for getting offline node back up to
date?
nitin at borwankar.com
Wed, 13 Nov 2002 12:44:05 -0800
> Mike C. Fletcher wrote:
> 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)
If I understand correctly what is being sought, A JXTA server that is
acting as a rendezvous server + router has this functionality. Any JXTA
peer may choose to run as a rendezvous server and/or a router assuming
it has the CPU/Disk
to spare.
Note that the JXTA protocol spec
a) allows peers to discard messages when peers get overloaded
b) allows for, but does not require, more reliable services than the
base JXTA spec defines - so you can
build these.
JXTA peer groups form a scoping mechanism for discovery and other
messages == a group context for services.
A peer group service is available from the peer group without need to
specify which peer it comes from (assuming multiple peers host the
service) which gives a "transparent failover". If ytou want to send a
message to a specific peer in a peer group and that peer may be down,
you can arrange for one (or more) of the peers in the group to
be rendezvous+router servers, this maps to your
If all peers in a peer group are down, then the service is unavailable
from that peer group.
But then what will you do when the "server" is down ?
What we are looking for is the probability of availability of a service
==> probability(at least one peer is up). In environments where this
probability is low (many peers coming and going) a "more reliably available"
peer is needed. The rendezvous server9s) in a peer group can provide
that functionality.
Nitin Borwankar
nitin@borwankar.com
> .
>
> 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
>>
>
--
------------------------------------------------------------
The more idiot-proof you make it, the smarter the idiots get.
Nitin Borwankar
nitin@borwankar.com
|
