Although it's been awhile since I've read the paper, IIRC, Beehive's replication policy is very aggressive. If your goal is to replicate so that the data remains on the network under the harshest levels of churn imaginable, then Beehive would be a good idea. But if you're not expecting this sort of workload, and your primary goal for replication was to make retrieving the data quicker, it might be better to use a more "modest" but proven replication strategy, such as DHash, and then look into speeding up lookups using parallelism. (See Kademlia, Epichord, or Accordion.)
- Mike
On Jul 25, 2006, at 6:44 AM, Bob Harris wrote: Seems like replication is a constant topic around here. Beehive is the state of
the art in replication. They can turn a O(lg N) overlay like chord or pastry into
an O(1) overlay purely via replication.
Bob.
On 7/25/06, Matthew Leslie <[EMAIL PROTECTED]> wrote: Hi Julien,
Thanks for your comments! You are right to say that if you use N to mean
exact number of nodes in the network at any time, you will move replicas
around a lot, and that would really suck! The idea is that N is an
estimate of the number of nodes in the network, and there is no need for
it to be exact. The value of N is used to guess at a distance between
replica IDs such that those replica IDs are 'likely' to be owned by
separate nodes. Being out by a few percent is perfectly acceptable. If
your estimate of N is way off, you will get bad guesses at this
distance, and poor performance.
Of course, there are situations where you get large fluctuations in
membership, and you cannot pick a value of single value of N. In these
situations, the symmetric placement function may well be a good choice.
I have infact added symmetric replication to my analysis, and the
results will be available in the journal version of the DAS-P2P paper
you mentioned. I hope to make this available on my website real soon
now. There will also be a much fuller discussion of these issues in my
thesis, which is currently in the final draft stages.
In comparison to other placement functions, I have found that the
symmetric placement function will offer a reliability similar to
successor placement, but with fetch times slightly slower than those
offered by finger replication. I hope that answers some of your
questions, I'd be glad to hear if you have any more.
Matt
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto: [EMAIL PROTECTED]] On Behalf Of Julien Lociuro
Sent: 22 July 2006 11:16
To: theory and practice of decentralized computer networks
Subject: RE: [Fwd: [p2p-hackers] Dynamic replication - successor
placement]
> There was a discussion about this scheme a while back.
> There is another paper which described another scheme which was
> similar called "Symmetric Replication", which was intended for Chord.
> Maybe that paper answers your questions, it seemed kind of independent
> of the system size. It can be found here:
>
> http://dks.sics.se/pub/replication.pdf
>
> Andersen
Hello Andersen,
Yes I know about the symmetric replication, wich seems good.
But I would like to compare the different schemes.
The paper I provided last time does a comparison between different
schemes.
But there is the question I asked I don't understand and is not referred
in the paper.
So if someone has an idea, or can resend the discussion about it, it
would be great. I can't find it.
Thank you very much.
Julien.
_______________________________________________
p2p-hackers mailing list
[email protected]
http://lists.zooko.com/mailman/listinfo/p2p-hackers
_______________________________________________
p2p-hackers mailing list
[email protected]
http://lists.zooko.com/mailman/listinfo/p2p-hackers
_______________________________________________ p2p-hackers mailing list
|
