[Dev] Existing p2p systems for getting offline node back up to
ray.ryan at pobox.com
Thu Nov 14 11:31:13 PST 2002
Is it bad form to reply to yourself? I want to expand on something I
glossed over, in case anyone actually reads this.
On Thursday, November 14, 2002, at 10:26 AM, Ray Ryan wrote:
> On Wednesday, November 13, 2002, at 08:20 PM, Mike C. Fletcher wrote:
>> I may be mistaken, but don't distributed hashtables try to keep the
>> messages pressed into them for as long as possible w/out regard to
>> their delivery status? That is, rather than being able to retire an
>> item when it reaches it's recipient, the engine is trying to store a
>> document for as long as possible, but normally can't give any
>> guarantee that anyone has accessed it before it is dropped?
> Which seems reasonable.
> I'd expect that, once a node has left a Chandler group, the rest of
> the group forgets it ever existed. If every node has to remember every
> other node that it may eventually come into contact with again...that
> doesn't seem practical.
> I imagine it like this:
> A node wakes up and looks around for an existing Chandler pool. It
> finds one and asks an arbitrary member for the status of each
> "document" the new node subscribes to.
> For each document that is actually known by the pool, the new node
> absorbs whatever changes it has missed. At the same time, it announces
> any offline changes that the pool has never heard of. Once this
> syncing is accomplished, the new node is a full fledged peer.
This bit about "gathering changes it missed" and "announcing any
offline changes" sounds like exactly what I said I don't want: storing
up messages for nodes that go offline.
What I meant to imply was that some kind of diff operation is performed
on each of the subscribed documents, and that change messages necessary
to bring everything back into sync are broadcast around the pool as a
side effect of the offline node coming back online. I have thoughts on
how that might work, but I'll spare the list.
> The point is that no one has been storing up any delayed messages for
> the returning node while it has been away, or even remembers that it
> once existed.
> Now I'm very naive in this space. I have no idea if tools like this
> exist already, especially in the Open Source arena. I'd never even
> heard of distributed hash tables before joining this list (worth the
> price of admission right there!). But this is the tool that I'd love
> to have.
More information about the Dev