]> git.mxchange.org Git - quix0rs-apt-p2p.git/blobdiff - TODO
Refresh DHT values just before they are due to expire.
[quix0rs-apt-p2p.git] / TODO
diff --git a/TODO b/TODO
index 9cef5c7a2e2f8ff2a1326fdfdfddac2cce4119e5..ce33a7763381df0317bbc3f5e5ed78db22f6a579 100644 (file)
--- a/TODO
+++ b/TODO
@@ -1,10 +1,3 @@
-Use python-debian for parsing RFC 822 files.
-
-There are already routines for parsing these files, so there is no need 
-to write more. In the AptPackages, change the Release file parsing to 
-use the python-debian routines.
-
-
 Packages.diff files need to be considered.
 
 The Packages.diff/Index files contain hashes of Packages.diff/rred.gz 
@@ -85,16 +78,18 @@ downloads to peers. Pieces should be downloaded from the best peers
 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.