[p2p-hackers] p2p in some place or other

[Michael Parker]

Hmmm,

Emin Sirer was on this list talking about Beehive [1] not too long ago. 
I read the paper, from NSDI 04, and it seems to fit your description 
very well. They use an analytical model to derive how hard to push 
replication of a key-value pair such that it can be found in a 
(configurable) constant number of hops. It assumes that the data set 
has a zipf-like distribution.

You could also try to borrow ideas from something like Glacier [2], 
from NSDI 05, which replicates to maintain high fault-tolerance, and 
try to exploit the replication for performance gains instead. (From 
what I can remember, data-survivability is the first priority of 
Glacier, not performance... As implied by the name.)

Just my two cents.

- Mike

[1] http://www.cs.cornell.edu/People/egs/papers/beehive.pdf
[2] http://www.cs.rice.edu/~druschel/publications/Glacier-NSDI.pdf


Quoting Travis Kalanick <travis at redswoosh.net>:

> One of the more interesting topics that came up from our sushi-get-together
> was a fairly rigorous discussion about the merits (or lack thereof) of
> Proactive Caching.
>
> Let's define Proactive Caching as a mechanism where a P2P network sends
> content to a user's machine for the sole purpose of improving network
> performance and availability.  For instance, imagine that a given network
> proactively caches "long tail" content to improve availability, or
> alternatively, proactively caches content during a sudden surge of demand
> for a particular file.
>
> Deep in this discussion at the dinner (this took place in the hours after
> most folks left) was Sergei, David Barrett, myself, and others, and I
> thought it would be good to bring this topic to the list.
>
> So far, in my opinion, proactive caching on open p2p networks would provide
> little temporal benefit in availability and performance, given the inherent
> costs of such a scheme, and given the availability of high-performance,
> high-reliability p2p architectures.
>
> Travis
>