HTTPServer responds correctly to requests for torrent strings.

[quix0rs-apt-p2p.git] / TODO

diff --git a/TODO b/TODO
index ec9a6ceef5362e91f840f5a9ed52dce320049bb4..bd24953de2cffe8a2b5e2bafa86e05b7f9da20be 100644 (file)
--- a/TODO
+++ b/TODO
@@ -1,11 +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?
+
+
+Add all cache files to the database.
+
+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.
@@ -86,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?)