On Thu, Apr 23, 2009 at 4:01 PM, Robert Hailey
<robert at freenetproject.org> wrote:
>
> On Apr 23, 2009, at 12:34 PM, Florent Daigniere wrote:
>
> Robert Hailey wrote:
>
> Perhaps there is an easier solution?
>
> How about extending the chk logic into an alternate-chk-key (ACK?);
>
> that simply adds 0.25 to the expected location (for routing and
>
> storage).
>
> So when you insert the top block, put it in as a chk and an ack (no
>
> extra uri's neccesary). When you go to fetch it, if the chk does not
>
> work, try the ack variant of the same key.
>
> At the moment each node on the path can verify that the data sent by
> previous hop corresponds to what it ought to; How would that work with
> your proposed solution?
>
> NextGen$
>
> Sorta like this...
> package freenet.keys;
> public class ASKKey extends NodeCHK {
> public double toNormalizedDouble() {
> return (super.toNormalizedDouble()+0.25)%1.0;
> }
> }
> The only difference is where any node would look for it. This would not be
> exposed to the client. My idea is that any chk could be converted to an
> alternate-location-finding-key just by type (which surely would mean a
> different fetch-command, e.g. fetchCHK/fetchACK...).
> There would be no difference in handling, the only difference would be how
> the target-routing-location is identified from the key (the same as CHK plus
> a constant [mod 1.0]). After all, the mapping from the key to the
> small-world location is open to interpretation...
> --
> Robert HaileyI suggested the obvious extension of this on IRC. Instead of simple searching at location + 0.25, you search at location + n/N, where n is which copy of the block you're looking for, and N is the number of copies inserted. Toad didn't like this because it makes top blocks identifiable to everyone on the routing path, and involves network-level changes. The other approaches can be implemented at a higher level as a translation before handing a normal CHK request to the network. Evan Daniel
