Re: DHT usage and requirement lists

"pwang708" <[email protected]> Mon, 04 Aug 2008 21:03:28 -0000
Newsgroups gmane.network.gnutella.devel
Message-ID <[email protected]>
> I have some comments again, though. 

That's great! Keep them coming. :-)

> > > 6) serving as distributed trackers for bittorrent enabled clients. A
> > > DHT can also be used to search torrent files.
> 
> Where's the merit in searching for torrent files over the DHT? 
> 
> A search for a torrent file is most probably a keyword query, so
it's in the 
> domain of Gnutella. 

Yes, we search torrent files as we do for other files. 

> 
> How high is the cost of using the DHT as a distributed tracker
compared to 
> traditional searches? 
> 
> Update-interval and amount of data come to mind for me. 
> 


Good point! I am not sure about the cost. This is what I am thinking
though: the DHT distributed tracker is a backup of a traditional
tracker. Besides, once a peer connects to others in the swarm, they
can start to use peer exchange protocol to learn more peers in the
swarm. A distributed tracker can be sloppy in this case...  Need more
analysis... Any idea?


> > > 10) We can group peers having common interests and tag the groups. A
> > > group can publish the tags and a subset of current ultrapeers in the
> > > group into the DHT. A node can search the tags to join the group
or to
> > > find files available under the tags.
> 
> Careful with this! 
> 
> It can have the advantage of making the Query routing protocol more
efficient 
> (if peers have more keywords in common, their query routing tables
will be 
> smaller), but as noted by Raphael it can lead to islands and to making 
> Gnutella less efficient. 


Will be careful about this. Please also see my reply to Raphael's post
and Michael's reply.


> 
> Do friends share similar content? The small world paradigm says yes,
but I'm 
> not perfectly sure. 
> 
> At least among my friends, it doesn't hold true. 
> 
> I think that to make clustering around friends useful, the clients
should 
> rather interface directly with IM clients or similar to optain
friend lists 
> (or at least offer the user to cluster via jabber), else there won't be 
> enough friends. 
> 


Not true for my friends either. :-) 

How about we change it to all the friends + people from who we
downloaded files before. 


> > > 7) Index poisoning/pollution attack mitigation.
> 
> Please remember that the DHT isn't needed for popular keywords, so only 
> popular sha1 remain, and there _one_ valid sha1 hash suffices to
kickstart 
> the Download Mesh. 
> 
> So the necessary level of security might not be too high. 
> 
> > > 9) A richer API. The DHT can be used for several things which
may have
> > > different requirements. E.g., allow users to define their data's
life
> > > time in [MIN, MAX], which are network wide parameters.
> 
> How about just allowing for arbitrary private extensions, but
defining a small 
> and stable shared subset first? 
> 
> > > 10) fixable lookup. For example, for lookups we don't care about
> > > speed, parallelism = 1, else parallelism = 3; exhaustive or not
(find
> > > all replica root or find a node who answers a query); caching
replica
> > > sets so that republishes consume less bandwidth...
> 
> Isn't that a detail which only needs to be dealt with inside the
clients? 
> 
> Or does it have to be adhered by the different clients to make the
network 
> efficient? 
> 


Yes, lots of them are details in the clients. Some might not be. When
lookuping up a key, a node A sends find_node requests to many nodes
including say an intermediate node B and a replica root R. I think it
make sense to allow A to specify the number of contacts that B and R
need to return, since the purposes of the find_node requests are
different. Another example, when a node uses parallelism = 1, it may
want more contacts returned from a intermediate hop than when it uses
parallelism = 3, so that the probability of stuck is small in both cases. 

 
> > > 11) Identification system.
> 
> What exactly do you mean by that? 
 
To be able to authenticate a node. NodeID generated randomly or NodeID
= hash(IP/port), or = hash(public key), or = hash(public key,
IP/port), etc. It would be better if we can have a certificate
authenticity. If I remembered correctly, Credence needs a certificate
authenticity.


Best,
Peng