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.)
One should also specify the interval for the request. The search stops, if a
version
with an overlapping interval is found. Otherwise the youngest version before the
interval in the request is returned after a full search.
This allows the requestor to say:
1) I want an the version that was valid two days ago.
2) I'm happy with a one day old version, but if you find a newer version,
give me that!
This will usually not take a full search for daily updated keys.
3) I really what to be sure, that I get the newest version. Do a full search!
> This would make a request as long as a DNF only occur if the current time is
> after estimate update time and the publisher hasn't updated the content. If
> a publisher has new content by then, the nodes get the most recent version
> with the same time cost as a DBR. If it isn't updated, well then it takes
> longer, but you'd still get the last published version.
>
> any thoughts?
>
> -Scott Young
-Thomas Leske
_______________________________________________
devl mailing list
devl at freenetproject.org
http://hawk.freenetproject.org/cgi-bin/mailman/listinfo/devl
