gzz-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gzz] hemppah's research problems document


From: hemppah
Subject: Re: [Gzz] hemppah's research problems document
Date: Mon, 16 Dec 2002 11:44:21 +0200
User-agent: Internet Messaging Program (IMP) 3.1

Quoting "B. Fallenstein" <address@hidden>:


> > 
> > DHT storing the *data*.
> > 
> > Note that the ones you mention above seem to be pretty unstable.
> 
> If the data is mappings of, say, ~20 byte keys to ~50 byte values, I
> think that is pretty well understood, yes. If the data is mappings to
> file-sized values, like 1MB or so, I don't think that's understood at
> all, except possibly for a network of *servers*. Asking peers to store
> small mappings is quite manageable; they can be served through a small
> link, and they can quickly be pushed onto a new node joining the network
> (from the other replicas of that data); and they don't take a lot of
> storage on the peer. Asking peers to store arbitrarily large data for
> other peers is far less understood, I think.
> 
> Also, DHTs often replicate data along the routing path. Sending 100
> bytes to all computers to log(n) computers for replication isn't much of
> a problem; sending 1MB to log(n) computers is.

Yes, I agree.

> > 
> > ?? This would of course happen incrementally.
> 
> A DHT node cannot start working until it has all the mappings it is
> responsible for. The point of a DHT is to return complete data, so a
> node can only start to act when it has received all the data it is
> responsible for. I think nodes will go on- and offline far more
> frequently than the amount of data they have to store can be pushed on
> them.

Um...this is a new thing to me. Does this mean, in theory, when a system is in a
flux-state (nodes constantly arriving and departing), node's availability
deteriorates because of this requirement ? 

> 
> Freenet stores the data in the network, but there a node can go offline
> and online again and serve the same data it did before going offline.
> DHTs are not designed to be able to do this.

How this has been implemented ?

>> The thing I'm looking for is some guarantees about performance. For DHTs,
>> they seem to be there, but for DHT + IP-based fetch I don't think so.
 
>> Or can you point me somewhere where that has been analyzed?
 
> Again, I'm asking for pointers about *any* system that works as you
> said, for transient peers (joining & leaving regularly).

There seems to be some misunderstanging in the research community also. For
example, in "Peer-to-Pere Computing"
(http://www.hpl.hp.com/techreports/2002/HPL-2002-57.pdf), the authors say that
"..each peer will route the *document* towards the peer with the ID that is most
similar to the document ID".  This implies the authors have understood that DHT
actually *stores* the data. 

Or am I missing something here ?


-Hermanni



-------------------------------------------------
This mail sent through IMP: http://horde.org/imp/



reply via email to

[Prev in Thread] Current Thread [Next in Thread]