-Evaluate and fix some errors in the ktable khashmir module.
+Add statistics gathering to the peer downloading.
-The KTable implementation has some possible errors in it. insertNode
-does not remove the original and use the new node when updating a node
-already in the table, as claimed by the comments. justSeenNode doesn't
-verify that the found node is the node that was being looked for, nor
-does it move the node to the end of the list of nodes (since they are
-supposed to be sorted by their lastSeen time) or update the bucket's
-last touched time.nodeFailed also doesn't verify the found node is the
-right node.
-
-
-Consider what happens when we are the closest node.
-
-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?
+Statistics are needed of how much has been uploaded, downloaded from
+peers, and downloaded from mirrors.
Add all cache files to the database.
The Packages.diff/Index files contain hashes of Packages.diff/rred.gz
files, which themselves contain diffs to the Packages files previously
downloaded. Apt will request these files for the testing/unstable
-distributions. They need to either be ignored, or dealt with properly by
+distributions. They need to be dealt with properly by
adding them to the tracking done by the AptPackages module.
+Retransmit DHT requests before timeout occurs.
+
+Currently, only a single transmission to a peer is ever attempted. If
+that request is lost, a timeout will occur after 20 seconds, the peer
+will be declared unreachable and the action will move on to the next
+peer. Instead, try to resend the request periodically using exponential
+backoff to make sure that lost packets don't delay the action so much.
+For example, send the request, wait 2 seconds and send again, wait 4
+seconds and send again, wait 8 seconds (14 seconds have now passed) and
+then declare the host unreachable. The same TID should be used in each
+retransmission, so receiving multiple responses should not be a problem
+as the extra ones will be ignored.
+
+
PeerManager needs to download large files from multiple peers.
The PeerManager currently chooses a peer at random from the list of
consensus revealing the misbehaving peer.
+Consider storing deltas of packages.
+
+Instead of downloading full package files when a previous version of
+the same package is available, peers could request a delta of the
+package to the previous version. This would only be done if the delta
+is significantly (>50%) smaller than the full package, and is not too
+large (absolutely). A peer that has a new package and an old one would
+add a list of deltas for the package to the value stored in the DHT.
+The delta information would specify the old version (by hash), the
+size of the delta, and the hash of the delta. A peer that has the same
+old package could then download the delta from the peer by requesting
+the hash of the delta. Alternatively, very small deltas could be
+stored directly in the DHT.
+
+
+Consider tracking security issues with packages.
+
+Since sharing information with others about what packages you have
+downloaded (and probably installed) is a possible security
+vulnerability, it would be advantageous to not share that information
+for packages that have known security vulnerabilities. This would
+require some way of obtaining a list of which packages (and versions)
+are vulnerable, which is not currently available.
+
+
Consider adding peer characteristics to the DHT.
Bad peers could be indicated in the DHT by adding a new value that is
projects / quix0rs-apt-p2p.git / blobdiff