On Apr 23, 2009, at 3:09 PM, VolodyA! V Anarhist wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Robert Hailey wrote:
>>
>> 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
>
> But from the perspective of forwarding nodes top block is just
> another CHK
> block, just like any other one. So you'd have to forward the
> information that it
> is a special block through the network.
>
> - Volodya
>
True, I hadn't thought of that.
It is correctable, though, as via an option flag on the uri we can
inverted the standard fetching procedure to be mostly alternates, and
failover to the 'normal' routing location. Then the 'specialness' of
the alternate request would fall back into the noise of standard chk
fetching (eventually, after enough data is inserted, etc).
--
Robert Hailey
