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