From 560d950422ec0610ee5ec855c1774bd73ccdd8cb Mon Sep 17 00:00:00 2001 From: Cameron Dale Date: Mon, 31 Mar 2008 14:35:20 -0700 Subject: [PATCH] Retire one TODO and add another. --- TODO | 22 +++++++++++++++------- 1 file changed, 15 insertions(+), 7 deletions(-) diff --git a/TODO b/TODO index 2475df8..b0724b4 100644 --- a/TODO +++ b/TODO @@ -1,10 +1,3 @@ -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? - - Add all cache files to the database. All files in the cache should be added to the database, so that they can @@ -49,6 +42,21 @@ first piece, in which case it is downloaded from a 3rd peer, with 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 -- 2.30.2