-Files for which a hash cannot be found should not be added to the DHT.
-
-If the hash can't found, it stands to reason that other peers will not
-be able to find the hash either. So adding those files to the DHT will
-just clutter it with useless information. Examples include Release.gpg,
-Release, Translation-de.bz2, and Contents.gz.
-
-
Packages.diff files need to be considered.
The Packages.diff/Index files contain hashes of Packages.diff/rred.gz
adding them to the tracking done by the AptPackages module.
-Change file identifier from path to hash.
-
-Some files can change without changing the path, since the file was
-added to the DHT by the peer. Examples are Release, Packages.gz, and
-Sources.bz2. This would cause problems when requesting these files by
-path. Instead, share the files by hash, then the request would be for
-http://127.3.45.9:9977/~<urlencodedHash>, and it would always work. This
-will require a database lookup for every request.
-
-
PeerManager needs to download large files from multiple peers.
The PeerManager currently chooses a peer at random from the list of
first (i.e. piece 0 from the absolute best peer).
-Missing Kademlia implementation details are needed.
+When looking up values, DHT should return nodes and values.
+
+When a key has multiple values in the DHT, returning a stored value may not
+be sufficient, as then no more nodes can be contacted to get more stored
+values. Instead, return both the stored values and the list of closest
+nodes so that the peer doing the lookup can decide when to stop looking
+(when it has received enough values).
-The current implementation is missing some important features, mostly
-focussed on storing values:
- - values need to be republished (every hour?)
- - original publishers need to republish values (every 24 hours)
- - when a new node is found that is closer to some values, replicate the
- values there without deleting them
- - when a value lookup succeeds, store the value in the closest node
- found that didn't have it
- - make the expiration time of a value exponentially inversely
- proportional to the number of nodes between the current node and the
- node closest to the value
+Instead of returning both, a new method could be added, "lookup_value".
+This method will be like "get_value", except that every node will always
+return a list of nodes, as well as the number of values it has for that
+key. Once a querying node has found enough values (or all of them), then
+it would send the "get_value" method to the nodes that have the most
+values. The "get_value" query could also have a new parameter "number",
+which is the maximum number of values to return.