Skip to Content.
Sympa Menu

bluesky - Re: Content based addressing

bluesky AT lists.ibiblio.org

Subject: Global-Scale Distributed Storage Systems

List archive

Chronological Thread  
  • From: Wei Dai <weidai AT eskimo.com>
  • To: Global-Scale Distributed Storage Systems <bluesky AT franklin.oit.unc.edu>
  • Subject: Re: Content based addressing
  • Date: Thu, 15 Feb 2001 18:44:42 -0800


On Thu, Feb 15, 2001 at 11:31:14AM -0800, hal AT finney.org wrote:
> Freenet uses the content hash as not only an identifier, but as an
> address for the data. The idea is conceptually simple: each node holds
> not only data, but pointers to the nodes from which that data came.
> When data is requested from the net by hash, if a node does not have
> the data it forwards it to the node which holdes the closest hash.
> The same forwarding rule is used when data is inserted into the net.
> The effect is that data with close hashes tends to congregate together
> on certain nodes, and you can follow a path through the network that
> leads you to the data you want. No broadcasting is necessary, and you
> can find data with a limited number of hops.
>
> At least, that's what the simulations show. The network in actual use
> seems to be somewhat fragmented and balky, but there are few people using
> it and the code is still buggy, so the hope and expectation is that the
> mature network will work well.

I think there are fundamental problems with the Freenet content
location system. I posted these concerns to freenet-chat, but never got
a meaningful response. I'll copy it here:

Freenet's search algorithm is characterized as "steepest-ascent hill
climbing search with backtracking". I wonder how it deals with landscapes
that doesn't have a single hill top. There seem to be two problems.

First is multiple hill tops, or multiple nodes that specialize in nearby
keys. When you insert a document with a key near these keys, the insert
request will be attracted to one of these nodes. But requests for the
document may be initially attracted to the other nodes. Is there some
provision for quickly going back downhill when the document you're
looking for is not at the local hilltop, instead of wasting time
searching the slopes of the hill?

The second problem is a flat landscape. Suppose you insert a document
with a key near the key of a very popular document that is cached
everywhere. The insert request and subsequent data requests for this
document will then be routed randomly and probably no one will be able to
find it.




Archive powered by MHonArc 2.6.24.

Top of Page