-Files for which a hash cannot be found should not be added to the DHT.
+Consider what happens when we are the closest node.
-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.
+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?
-Use python-debian for parsing RFC 822 files.
+Add all cache files to the database.
-There are already routines for parsing these files, so there is no need
-to write more. In the AptPackages, change the Release file parsing to
-use the python-debian routines.
+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.
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).
-
-
-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