DHT usage and requirement lists
"pwang708" <[email protected]>
| Newsgroups | gmane.network.gnutella.devel |
|---|---|
| Message-ID | <[email protected]> |
Updated based on Arne and Michael's comments. Some of them will be hard to achieve but we still put them here for completeness. Please feel free to edit and/or put new sections. Usage: 1) magnet links 2) push-proxies 3) alt-locs 4) searching for files by hash. 5) Searching for file metadata by its hash. 6) serving as distributed trackers for bittorrent enabled clients. A DHT can also be used to search torrent files. 7) helping Gnutella for rare keyword searches. 8) serving as a decentralized contact-list so that one can search for specific users 9) searching for my friends' addresses or their Ultrapeers' addresses. Connecting to the same ultrapeers as my friends (and their friends) might allow me to find interesting files in fewer hops, which is good for two reasons: less bandwidth used, and fewer non-friends (potential spammers) reached by the query. 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. Requirements: 1) Good user experience 2) Low overhead. 3) Hotspot mitigation. 4) Write Quota system. A user can only publish a certain number of data items, to each DHT node. 5) Data security. E.g., only I can modify my push proxy information. 6) Mitigation of "traditional" spams. I quote a line from Arne's previous post: "Spam, in the way it is used today, is a means to make it harder for people to reach some popular files for whose "protection" the spammers get paid." I think we should use some other name (such as targeted file poisoning/pollution attack) to distinguish it from "traditional" spams. 7) Index poisoning/pollution attack mitigation. 8) Routing security. I.e., always be able to find the replica roots. 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. 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... 11) Identification system.