Another new TODO item.

[quix0rs-apt-p2p.git] / TODO

diff --git a/TODO b/TODO
index 2ff301ac1065758b7d606da98e2ce582e1df02d9..ff65f9a12091ecfedd86a202f2082a108e6f1e57 100644 (file)
--- a/TODO
+++ b/TODO
@@ -1,9 +1,19 @@
-Files for which a hash cannot be found should not be added to the DHT.
+Comply with the newly defined protocol on the web page.

 
 

-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.
+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)
+
+
+Reduce the memory footprint by clearing the AptPackages caches.
+
+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.

 
 
 Packages.diff files need to be considered.
 
 
 Packages.diff files need to be considered.


@@ -15,16 +25,6 @@ distributions. They need to either be ignored, or dealt with properly by
 adding them to the tracking done by the AptPackages module.
 
 
 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 
 PeerManager needs to download large files from multiple peers.
 
 The PeerManager currently chooses a peer at random from the list of 


@@ -96,16 +96,25 @@ downloads to peers. Pieces should be downloaded from the best peers
 first (i.e. piece 0 from the absolute best peer).
 
 
 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?)
 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?)

- - 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