Re: DHT usage and requirement lists

--- In [email protected], "pwang708" <wang.peng@...> wrote:

> Please feel free to edit and/or put new sections.
 
> Usage:

> 3) alt-locs

Doesn't alt-loc become obsolete or at least replicated by the DHT?  If
sources can be located by hash, then it would seem that you could
locate many sources assuming that all nodes are using the DHT.

It seems that publishing GUID and file properties (file name, bit
rate, mime type, etc) to hash key would be better than IP:port pairs.
 A node doing a lookup by HASH would have to provide a filespec to
match would return a list of GUIDs.

The rational would be that a two tiered lookup of GUID to IP:port
would simplify ip changes which can happen frequently.  It would also
be  possible for a clean shutdown to mark the GUID as offline.  This
would save running through an entire library to update results.

Perhaps some of the alt-loc design could be used to update the storing
nodes GUID cache.  Ie, a successful hit would bump GUIDs up or down. 
  Maybe this should come as part of the node lookup protocol (ie, only
republish GUID's who have hits).  I don't know if that is spelled out
explicitly in Kademlia. 

Storing GUIDs in this way would need to use a public key to validate
IP:port (and/or push proxy) updates. (just proving that subsequent
GUID updates are from the original node).  The main goal of this
suggestion is to provide an easy way to deal with node churn.  The
lifetimes of published results could probably be extended if this was
to work.  However, this didn't deal with churn at the published
location.  I am also unsure of details of how neighbours deal with new
arrivals to update results that the new node should own.

This doesn't say anything about key word searches. 

fwiw,
Bill Pringlemeir.