X-Git-Url: https://git.mxchange.org/?p=quix0rs-apt-p2p.git;a=blobdiff_plain;f=TODO;h=b4951933a627a2d6a5b4d47e4f561401aaa4e188;hp=9b4f7483cf5030e6bfcb9a2087d3a010a4762024;hb=5ae15cb5cc24c1fd9a75ea7a8b416f733d1c79be;hpb=358d175e2ba5638ad2ff31f233b8fa23db5235dd

diff --git a/TODO b/TODO
index 9b4f748..b495193 100644
--- a/TODO
+++ b/TODO
@@ -1,34 +1,49 @@
-Upgrade the security in khashmir by using longer TIDs.
+Consider what happens when we are the closest node.
 
-The TIDs sent with every request that must be echoed on response are 
-very short (one char). They should be lengthened to 20 using the NewID() 
-function from khash.
+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?
 
 
-Hashes of files need to be stored permanently.
+Add all cache files to the database.
 
-A new database of files and their hashes is needed. It should store the 
-location and hash of the file as well as the modtime and other details 
-so we can check if a file needs to be rehashed on startup. The DB can 
-also be used to store info needed to manage the values stored in the DHT.
+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.
 
 
-Add ability to search and hash and DHT-store other directories.
+Packages.diff files need to be considered.
 
-The user should be able to specify a list of directories that will be 
-searched for files to hash and add to the DHT.
+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 
+adding them to the tracking done by the AptPackages module.
 
 
-Missing Kademlia implementation details are needed.
+PeerManager needs to download large files from multiple peers.
 
-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
+The PeerManager currently chooses a peer at random from the list of 
+possible peers, and downloads the entire file from there. This needs to 
+change if both a) the file is large (more than 512 KB), and b) there are
+multiple peers with the file. The PeerManager should then break up the 
+large file into multiple pieces of size < 512 KB, and then send requests 
+to multiple peers for these pieces.
+
+This can cause a problem with hash checking the returned data, as hashes 
+for the pieces are not known. Any file that fails a hash check should be 
+downloaded again, with each piece being downloaded from different peers 
+than it was previously. The peers are shifted by 1, so that if a peers 
+previously downloaded piece i, it now downloads piece i+1, and the first 
+piece is downloaded by the previous downloader of the last piece, or 
+preferably a previously unused peer. As each piece is downloaded the 
+running hash of the file should be checked to determine the place at 
+which the file differs from the previous download.
+
+If the hash check then passes, then the peer who originally provided the 
+bad piece can be assessed blame for the error. Otherwise, the peer who 
+originally provided the piece is probably at fault, since he is now 
+providing a later piece. This doesn't work if the differing piece is the 
+first piece, in which case it is downloaded from a 3rd peer, with 
+consensus revealing the misbehaving peer.