> I still think some form of *constrained* broadcast is essential to the > initial propogation of the update - it is not sufficient to simply > update one node, or just the nodes in a direct line between you and > whatever node is closest to the data in information space, a shotgun > approach is essential here.
No single strategy for either the update or subsequent fetch will work by itself; one must specify both sides of the operation and how they will work together. Oskar and I believe that a deep-probing fetch along with a simpler update will work. You propose a more thorough update, but a simpler fetch (you don't really specify the fetch, but I assume you intend something simpler). If your method will really work, it would be more optimal for fetches and less for inserts, which is a good thing. We should probably try both. The current Freenet works with unique-keyed documents because the simple fetch knows exactly when it has succeeded. That's not true for updatable docs. It might be possible to rectify that by shifting some of the burden on to the insert--but it might not be. > The DataUpdate should be routed like a data request, until it reaches a > node which stores the data. The DataUpdate will continue past this > (until it's HTL runs out) but will also spawn a "virus" version of a > DataUpdate which will be sprayed out to surrounding nodes with a very > low HTL. These nodes will only forward the dataupdate if they > themselves have the data being updated. This prevents the huge > explosion of messages which Oskar fears. As long as "very low" means 1 or 2, I might agree that this isn't bad. > Updatable data should also be supplied with a timeout. I think you mean Expiry (the term "timeout" is already a bit overloaded). That's really orthogonal to this--any document can have an expiry time, and some updatable documents might not want one. Certainly adding this information makes the system perform better, but _relying_ on that is a big mistake. We also need to make clear that if these SVKs are redirects to CHK full documents, expiry of the two is independent. Expiry on the SVK means that it no longer point to an "up-to-date" document, though some still may want to retrieve older versions by CHK. CHK documents should never expire, really, just fall into disuse. Perhaps some combination of the two might be best--your slightly expanded update, plus a slightly expanded fetch (say, a fetch that begins sending the data found, then makes 1 or 2 extra hops to tell the neighboring nodes it has done so, allowing them to send update messages if they happen to have a newer version. -- Lee Daniel Crocker <lee at piclab.com> <http://www.piclab.com/lcrocker.html> "All inventions or works of authorship original to me, herein and past, are placed irrevocably in the public domain, and may be used or modified for any purpose, without permission, attribution, or notification."--LDC _______________________________________________ Freenet-dev mailing list Freenet-dev at lists.sourceforge.net http://lists.sourceforge.net/mailman/listinfo/freenet-dev
