X-Git-Url: https://git.mxchange.org/?a=blobdiff_plain;ds=sidebyside;f=TODO;h=bd24953de2cffe8a2b5e2bafa86e05b7f9da20be;hb=f42a072b964146fcfb47c5235a29f155074b57e7;hp=ff65f9a12091ecfedd86a202f2082a108e6f1e57;hpb=b68a1ebc0bbe79c8f9d3981ed83ef0ffcf201752;p=quix0rs-apt-p2p.git

diff --git a/TODO b/TODO
index ff65f9a..bd24953 100644
--- a/TODO
+++ b/TODO
@@ -1,19 +1,16 @@
-Comply with the newly defined protocol on the web page.
+Consider what happens when we are the closest node.
 
-Various things need to done to comply with the newly defined protocol:
- - use the compact encoding of contact information
- - remove the originated time from the value storage
- - add the token to find_node responses
- - use the token in store_node requests
- - standardize the error messages (especially for a bad token)
+In some of the actions it is unclear what happens when we are one of the
+closest nodes to the target key. Do we store values that we publish
+ourself?
 
 
-Reduce the memory footprint by clearing the AptPackages caches.
+Add all cache files to the database.
 
-The memory usage is a little bit high due to keeping the AptPackages
-caches always. Instead, they should timeout after a period of inactivity
-(say 15 minutes), and unload themselves from meory. It only takes a few
-seconds to reload, so this should not be an issue.
+All files in the cache should be added to the database, so that they can
+be checked to make sure nothing has happened to them. The database would
+then need a flag to indicate files that are hashed and available, but
+that shouldn't be added to the DHT.
 
 
 Packages.diff files need to be considered.
@@ -94,27 +91,3 @@ These should be combined (multiplied) to provide a sort order for peers
 available to download from, which can then be used to assign new 
 downloads to peers. Pieces should be downloaded from the best peers 
 first (i.e. piece 0 from the absolute best peer).
-
-
-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).
-
-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.
-
-
-Missing Kademlia implementation details are needed.
-
-The current implementation is missing some important features, mostly 
-focussed on storing values:
- - values need to be republished (every hour?)