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 Hailey
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/20090423/760595ae/attachment.html>
