Re: Re: DHT usage and requirement lists

> Bill Pringlemeir wrote:
>> 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.
 
--- On Wed, 8/6/08, Michael Rogers <[email protected]> wrote:
> True, but the downside is that many of the GUIDs stored
> under a given key will refer to offline peers, and the searcher can't
> tell which ones are stale without doing a GUID->IP:port lookup. So it
> gets quite expensive for searchers, especially if peers typically
> spend a lot of time offline.

True, but alt-loc's and many other strategies can also have stale addresses.  A problem is that if a peer participates in several alt-loc meshes as they go offline, each mesh must discover this.

Also those sharing large libraries will have a high overhead to republish.  The amount of entries stored in the DHT will be equal or greater than the number of nodes in the network; assuming that the average node shares more than one file.

One problem mentioned by Raphaël mentoined was several bogus IP addresses being returned.  A stronger authentication mechanism for GUID would mean that the forger would have to own each kad node that the GUID would map to.  I guess a simpler solution is to verify that the publisher of a store operaton has the IP, but I think for most DHT this can not be the case.  Other nodes can spread the published results, with the intent to make popular lookups faster.  

I guess most for traditonal DHTs, the GUID is the DHT id so those lookups are kind of implicit.

fwiw,
Bill Pringlemeir.