Skip to Content.
Sympa Menu

bluesky - Re: market-based data location (was Scalability)

bluesky AT lists.ibiblio.org

Subject: Global-Scale Distributed Storage Systems

List archive

Chronological Thread  
  • From: Jim McCoy <mccoy AT io.com>
  • To: "Global-Scale Distributed Storage Systems" <bluesky AT franklin.oit.unc.edu>
  • Subject: Re: market-based data location (was Scalability)
  • Date: Mon, 05 Mar 2001 17:41:24 -0800


At 03:02 AM 2/28/01 +0100, Oskar Sandberg wrote:
[...]
I approached the Mojonation people regarding my concern that the whole
content tracking system was not really decentralized at all at the Peer to
Peer conference.

Actually our opinion is that our content tracking system is _too_ decentralized. It would have served us better to start off with a few centralized content trackers (a la Napster) that were specialists in a particular content type rather than the Gnutella-like indexing structure which we currently employ. A few handicappers exist within our current code to do keyword-hash based lookups (woe to the poor slob who gets stuck with "britanny" or "spears" :) but these have not really been tested very much.

It turned out however, that Mojonation's basic architecture isn't scalable
anyways. The content-trackers in MN do not map metadata onto a physical
address, they map metadata onto UIDs (the SHA1 hash for each part) of the
data. Apparently, to then find the data, MN simply expects each node to
keep a list of the IDs of every other node in the network [...]

This is incorrect. Each node keeps a set of phonebook entries for other brokers that it has contacted in the past (not the entire list, just the nodes you have communicated with). These entries contain information such as broker ID (to link to reputation information about that broker), contact information and connectin strategies (e.g. to contact Broker X send the message to relay server Y), and specific service info such as the block mask for a storage service agent. It is these masks which are used to determine who you will send a request to when looking for a blob of data.

If you can't find the blob you are looking for at any of the brokers you know who cover that range of the SHA1 address space then the Broker goes back to the centralized metatracker and asks it for a few more phonebook entries which cover the range of the address space it is interested in and caches these entries. This scales sufficiently well for our current prototype and when this starts to show scaling problems we will drop in the gossip-based mechanism to limit reliance on metatrackers for new block server phonebook entries.

In our gossip-based lookup system your Broker would send a phonebook lookup request to block servers that a Broker knows about which were closest to the desired range. These block servers would either answer the request as best they could with entries out of thier cache or direct the originator of the request to a few other block servers which were even closer to the correct mask range in the hope that they could provide useful phonebook info. Each Broker will hold on to phonebook entries that overlap or are near its mask range longer than it will for other ranges of the block address space. Each block server within a Broker will become a specialist in the metainfo about other blocks servers whose mask is a near-match, allowing us to replicate data blocks within the network easier and assisting other Brokers by being able to provide useful phonebook info.

Next time perhaps you could try to make sure that you actually understand how another system works before you start throwing stones...

jim mccoy
AZI/Mojo Nation





Archive powered by MHonArc 2.6.24.

Top of Page