[reader's note: I have a proposal taking into account some of the concerns which Oskar raises, please scroll down to the bottom (past my bickering with LDC) to read it
> I had to go back and look up this thread because it was mistitled, > but I don't buy your argument at all. Contrary to your assertion, > Oskar did in fact address your points directly, and convincingly. Yes, I have just read his answer, but it is your opinion that he addressed my points convincingly, not mine! > If others didn't respond, maybe it was because we know that Oskar > has more experience and a reputation for being right. Er, more experience than who? I started this project in September 1998, 9 months before anyone else did - it is hard to get more experience than that! Yes Oskar is frequently right, but he is occasionally wrong too. This is true of most of the core developers. I prefer to base my opinions on facts rather than reputation. As I will outline towards the end of this email, I think Oskar does make some good points, but I think his proposal avoids the tough issues which my proposal tackled head-on making it vulnerable to attack (remind anyone of the KHK/CHK debate? ;) Oskar's suggestion about sending the update to 10-15 nodes is dubious at best, where do we get these nodes from? The datastore? But the DataStore is likely to be filled with nodes that are already in our part of information space, so they will probably just take the same route to the "epi-center" of the data anyway. > I'm not > entirely convinced that the idea will work well Haven't you just contradicted your earlier assertion that Oskar is always right? ;-) > You assert that his probing-request update mechanism makes the > assumption of a central location for the data. That's not true-- > the data can be inserted from anywhere as usual, and stored at > any node as usual. All he suggests is changing the request from > "do a directed hunt for the first matching document in this part > of the network" to "do a directed hunt for the latest matching > document on this (slightly larger) part of the network". We are > not proposing a mechanism that guarantees the latest version--but > neither are you. That's just the Freenet way of things; not a > guarantee, just a likelihood of success. My proposal is a little > more reliable in that it begins the request with a specified > minimum revision, but it otherwise similar. The problem with your's/Oskar's proposal is that I don't see how the updates will be propogated to a sufficient number of nodes so that even where requests can "slip through" nodes where they would normally be answered, they eventually get to the updated version of the data. In fact, unless I am missing something, this isn't really addressed by Oskar's proposal at all! This is the issue that my idea addresses, and moreover, I can't think of any more sensible way to do it. Your idea is not without merit, however, read on and I will outline a compromise. > Secondly, you assert > that this will interfere with the existing caching mechanism. > This is so far from the truth I can't imagine how you can say it > with a straight face. You would be amazed by what I can say with a straight face. The caching mechanism depends on caches actually answering requests when they receive a request which is locally cached - if this doesn't happen, then the caching mechanism will break down. > It doesn't change any existing behavior at > all for any other key type, and the extension for updatable documents > is so minor (especially compared to alternatives) that it doesn't > seem likely to have any major impact. Er, not sure what you mean here. It is my suspicion that most people will want to be able to update their documents, thus this will indeed have a major impact. > I also agree with Oskar that updatable documents ought to be small > to further minimize any possible impact of these extended fetches > and inserts; making them all empty redirects to CHK documents is a > great way to do that, so we can even dispense with message bodies > entirely if we want to. I agree here too - once we have implemented CHKs! Ok, here is my proposal - which will hopefully placate Oskar and LDC. 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. 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. Updatable data should also be supplied with a timeout. This means that when data is updated, locally cached versions of the data are likely to die out allowing the requests to get through to the "core" nodes which should be holding the updated data. This addresses the same problem which I think Oskar was worried about when he made his proposal and is related to his "update-by" suggestion. Howzat? Ian. _______________________________________________ Freenet-dev mailing list Freenet-dev at lists.sourceforge.net http://lists.sourceforge.net/mailman/listinfo/freenet-dev
