Skip to Content.
Sympa Menu

bluesky - Re: the three-services model

bluesky AT lists.ibiblio.org

Subject: Global-Scale Distributed Storage Systems

List archive

Chronological Thread  
  • From: hal AT finney.org
  • To: bluesky AT franklin.oit.unc.edu
  • Subject: Re: the three-services model
  • Date: Mon, 19 Feb 2001 00:28:56 -0800


Wei wrote:
> Also note that the
> three services can be designed, implemented, and provided independently of
> each other, as long as we standardize the interfaces. So although
> MojoNation may not provide a name service, it can still take advantage of
> other name services.

Yes, it would be good to be able to slice up the services "vertically"
rather than just "horizontally" as we have them now. It still seems to
me that the most natural split is between levels 1 and 2. This is the
mapping from names (or perhaps search data) to content hashes. It is
a rather different (and perhaps harder) problem than the other layers.

I worry that the split between 2 and 3 makes too rigid an assumption about
the particular mechanism for finding data - look up the server, and then
query the server. I don't think we should preclude the possibility of
other ways of finding data.

> (Why does it use eight concatenated hashes instead of
> just one, btw?)

I think it is because MojoNation splits the files into 8 pieces using a
Shamir style sharing algorithm, and stores all 8 of the content hashes.
Then some number < 8 of them is needed to reconstruct the data.

> > This is a hard problem which has been much discussed on the
> > Freenet list. How do you trust the name to address mapping? Do you
> > need to introduce cryptography, a trust model, a PKI? Such systems
> > have never been successful, although it might be argued that P2P is the
> > "killer ap" for end-user PKI.
>
> I think a distributed trust model is the only thing that can work. But
> because the three services can be independent, there can actually be
> multiple name services, using different trust models or PKIs (or even
> insecure ones that don't use any cryptography).

This makes a lot of sense. Different projects can explore their own
approaches to handling the naming problem. If they could resolve to a
common format for the actual data it would let people mix and match.

> > These problems exist in Freenet, but they don't seem that severe.
> > Data objects in that system are considered fluid and don't have a
> > permanent home, flowing through the network. Any system which will avoid
> > the slashdot effect (what Adam calls flash crowds) needs to be able to
> > migrate and spread data according to demand.
>
> Freenet can't be considered a general purpose storage system either, since
> it doesn't provide any reliability. There is no way to make reasonably
> sure that if I publish a document on Freenet, it can be accessed from
> anywhere, and will be stored for at least a certain amount of time. In
> this regard it's even worse than the world wide web.

No system is perfectly reliable. Freenet will provide some level of
reliability. Whether it is able to evolve into a sufficiently reliable
system for general use remains to be seen.

The OceanStore system at http://oceanstore.cs.berkeley.edu is a more
complex and sophisticated system which has concepts similar to Freenet.
Here is an excerpt of their ideas on "nomadic" data:

In a system as large as OceanStore, locality is of extreme
importance. Thus, we have as a goal that data can be cached anywhere,
anytime. We call this policy promiscuous caching. Data which is
allowed to flow freely is called nomadic data. Note that nomadic data
is an extreme consequence of separating information from its physical
location. Although promiscuous caching complicates data coherence and
location, it provides great flexibility to optimize locality and to
trade off consistency for availability.

OceanStore keeps careful track of where data is located as it flows
through the network. This allows its data lookup algorithm to be highly
reliable and fault tolerant. My concern is that it may turn out to be
costly to keep location information up to date, and since they don't
have any code on their web page, it's hard to judge how the efficiency
tradeoffs will turn out.

> Perhaps servers not being able to choose what they store can be considered
> a feature, but the other side of that coin is that users can't choose
> which servers to store their data, which is certainly a bug. If servers
> are addressed by content-hash id, as a user I may be forced to store my
> data on a server that I know is unreliable or controlled by an attacker.
>
> The advantage of seperating the location service from the
> storage/transport service is to allow users to choose which servers to use
> for long-term guaranteed storage, while still allowing the data to be
> accessed from anywhere, and not preventing other servers from caching
> whatever data they deem most profitable.

I'm not sure I follow how this separation achieves these goals. How would
caching work in this system? Is it a feature of level 2 or level 3?
I thought in your model I would I do a lookup in level 2 with the CHK
to get a host, and from what you say here I gather that this would be
the host chosen by the author to hold the data inserted. Then I go to
level 3 and contact that host and request the data. There don't seem to
be opportunities for data caching in level 2 since no data flows there,
and not in level 3 since you talk directly to the machine where the data
was originally stored.

Hal




Archive powered by MHonArc 2.6.24.

Top of Page