----- Original Message ----- From: "fish" <[email protected]> To: <devl at freenetproject.org> Sent: Thursday, November 28, 2002 12:09 AM Subject: Re: [freenet-dev] Freenet Updating
> > > On Wed, 27 Nov 2002 Erendil at aol.com wrote: > > > The idea of updating is similar to DBR. I was not sure of the exact > > mechanism. > > > > Yes, I know you may not get the new version. But, the old versions > > will not supress the new ones long. Whenever a new one is encountered, > > it takes precedence, thus being propogated. And it doesn't go the > > other way. (old taking over the newer) > > Firstly, you can't update CHK keys, because they're content hash's. But > you knew that :). > > I actully tried implenting this once ;). The problem with it is, > primarily, that now every request will take the same amount of time as a > DNF takes, because you can't just use the version in the local node > anymore - you have to search through the entire network for the content in > question. Another problem is that different (i.e. updated) files will route to different parts of the network, so a request for the most recent file won't know where to go. The reason DBRs work is because they have a determinable request key. > > there are possible workarounds that you can use, for example retrieving at > HTL=5 first, and then only retrieving at HTL=15/25 if there is a DNF, but > this, of course, has it's own performance issues. and, using this varient > on the scheme, the updated key will only traverse the network if it's a > popular key - so, while it'd work for cruft, tfe, nubile, you'd probably > still be looking at a fishland from weeks ago ;). > > the scheme I actully ended up settling on, to make this work on a freenet > style network (I actully later resigned my test network to work > differnetly, but that's antoher failure story for another day ;), is > having the node activly update SSK and KSK keys - that is, inside the > node, you have code that says something like: > > for j in metakeys: > if ( lastTouched < updateTime ): > find all versions accessable to me at HTL=whatever > sort > if later version exists: > remove key from datastore > > this way, it wasn't transferring keys around until they were required by > the user, in order to avoid wasteing bandwidth, but was still keeping the > node up to date. However, obviously this has ramifications for > propagation. > > There are also several issues with this scheme, one of which is bandwidth > usage for large nodes. It's obviously up to someone other than me to > decide wether this is worth it for freenet. > > - fish > 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. 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 _______________________________________________ devl mailing list devl at freenetproject.org http://hawk.freenetproject.org/cgi-bin/mailman/listinfo/devl
