Andrew Rodland wrote: > 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.
The author just has to set the expected update time to the current time, before the insertion. If you don't allow older versions in the request you will get the most current one. > 2) We can update later than expected, and the content will not disappear -- > users should be able to find the newest version that exists. :) I said that a request, should work like you want it: >>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. > 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. :) The expiration time is useful for performance, because one can abort the search, as soon as one knows that there can't be a more current version. The consequence of your two requirements is, that there is no useful expiration time and you always have to do a full search. If you think TRKs are worth a full search, please have a look at my earlier proposal: http://hawk.freenetproject.org/pipermail/tech/2002-November/000199.html The requests are inserts at the same time. This helps to propagate the new data, and is at the same time a defence against evil nodes that always return outdated data. - Thomas Leske _______________________________________________ devl mailing list devl at freenetproject.org http://hawk.freenetproject.org/cgi-bin/mailman/listinfo/devl
