Oskar Sandberg <md98-osa at nada.kth.se> wrote:
> > Updatable data should also be supplied with a timeout. This means that
> > when data is updated, locally cached versions of the data are likely to
> > die out allowing the requests to get through to the "core" nodes which
> > should be holding the updated data.
>
> The update-by field was meant to be meta-data in the content so as to
> give clients an idea of when they need to do follow-throughs.
>
> I think that having such a field in the data on the network that actually
> kills off the data is horrible. Not only does it really hurt usability
> that you have to know exactly when you will update, but it has major
> sustainability issues.
I agree - Freenet is supposed to be preserving data, not killing it off. =)
You don't know that there actually -are- any nodes out there with updated
data, or that you will be able to reach them. Nodes shouldn't delete data
unless they have a fresher version in hand to replace it with, although
they might provide a suggestion that this is probably an old version.
> I will take the appropriate step and make the same modification to my own
> proposal, but one that does not involve the pitfalls of actually killing
> off data on the network.
>
> We use a deep/follow-through request system. However, data contains a
> storable field that says how long the period it during which we are sure
> we will NOT get another update. During this period, even follow-through
> requests will terminate on finding the data.
I am concerned that we don't try to reinvent the wheel. =) The problem of
deciding when to follow-through on requests is exactly that of deciding
whether a cached item is fresh or not. There are many standard algorithms
for doing this.
For example, the Squid web cache uses the last-modified factor (LM factor),
which is calculated by:
LM factor = (time_now - time_stored) / (time_stored - time_last_modified)
= age_since_stored / age_when_stored
When the LM factor exceeds a certain percentage (determined by
configuration), the object is considered stale and a follow-through request
should be performed. time_stored is reset to the current time regardless
of whether a new version is found or not. This could be carried out
automatically by nodes whenever an updatable key is requested, removing the
responsibility from clients.
Additional configuration parameters can also be introduced -- the client
and/or node can set maximum/minimum ages (i.e. time_now - time_stored)
beyond which follow-through requests will always/never be performed.
Finally, the author can also set maximum/minimum validity times beyond which
follow-through requests will always/never be performed. (Maximum validity
= expiration time, minimum = Oskar's suggestion above.)
theo
_______________________________________________
Freenet-dev mailing list
Freenet-dev at lists.sourceforge.net
http://lists.sourceforge.net/mailman/listinfo/freenet-dev
