[freenet-dev] Why Freenet is so SLOW! / Finding data

[Robert Hailey]

On Dec 7, 2007, at 5:24 PM, Ed Tomlinson wrote:

> On December 7, 2007, Robert Hailey wrote:
>> [...]
>> Consider the following patch (completed to the furthest point that my
>> current freenet understand can take it).
>> - If a CHKBlock is evicted from the datastore (not cache), AND we are
>> not (as best we can tell) "close" to where it should be, THEN re-
>> insert that block.
>>
>> This approximates the decision (is this eviction OLD/UNPOPULAR or
>> UNFINDABLE), and brings with it a rather odd perk for having small
>> datastores (that they would find these misplaced blocks sooner).
>>
>> The major risk, of course, is renewing old data.
>> [...]
>
> This is an interesting way to tackle the problem.  Might I suggest  
> that instead of
> doing this for data that we are about to discard we do it select a  
> key from the DS
> at random and reinsert if its far from our current location.

That may be a good strategy for shrinking the datastore, to slowly  
reinsert it into the network. But the problem is one of finding the  
initiative, such a task would yield itself to occurring when we change  
locations, which (if that is the case; that we have a store full of  
stuff for a different location) means we probably shouldn't be  
swapping locations to begin with (your first point).

> One thing that may be happening that somewant offsets this problem  
> could be
> clustering of locations.  e.g. even though my nodes location changes  
> often it could
> be that it favours some subsets of the total location space.  It  
> would be worthing
> adding a metric to track how long a node spends in a given area of  
> the location
> space.

Hmm... that may be implementable as a running average of (location  
over time). i.e. every fixed interval (hour? / 5-minute) average one  
'location' into the running average. Which amounts to a location- 
shifting 'velocity' measurement, or 'average-location'.

--
Robert Hailey