On Friday 29 November 2002 05:00 am, Thomas Leske wrote:
> Scott Young wrote:
> > Actually, I just got another idea on how to handle them with a new key
> > type. Let's call it a Time Redirection Key (TRK).  The key is designed so
> > that it will always route to the same part of the keyspace for a specific
> > updatable file.  When someone initially uploads a document, they point to
> > this routing keyspace, and a request goes in that direction.   This
> > keytype has an unencrypted meta-value that is basically an estimate for
> > the next update time.  If a request reaches a node with a key that has a
> > next-update-estimate time less than the current time, it continues on
> > until the search finds a node with a next-update-estimate that is greater
> > than the current time.  If the request fails, it returns with the most
> > recent value for the key found in the request chain.
>
> You should send the "current time" with the request for two reasons:
>   1) The clocks of the nodes are not synchronized.
>   2) Older versions can be kept available that way.
>
> A node should not replace the old content with the new one, but keep old
> versions until they fall off. The unencrypted metadata of each version
> specifies an interval in time for that the data is valid. (If the interval
> of two versions overlap during an insert, this is treated as a key
> collision.)

But this doesn't really buy us much of anything over DBR. The two requirements 
for a useful TRK, as I see them, would be

1) We can update sooner than expected, and users will have a decent chance of 
seeing the newest version anyway.
2) We can update later than expected, and the content will not disappear -- 
users should be able to find  the newest version that exists. :)

Although having metadata about when a key is _expected_ to expire does seem 
like it could be useful for performance purposes, treating uploads before 
then as collisions fails 1) horribly. :)

My $0.019999
--Hobbs


_______________________________________________
devl mailing list
devl at freenetproject.org
http://hawk.freenetproject.org/cgi-bin/mailman/listinfo/devl

Reply via email to