On Mon, 08 May 2000, Ian Clarke wrote: > Oskar Sandberg wrote: > > > > Broadcast updates are a really bad idea Ian, I didn't think I would see you > > of > > all people using the dreaded "B" word. > > It is not sufficient to firstly tar this proposal with the "broadcast" > brush (in itself inaccurate and misleading) and then to dismiss anything > that involves something that even looks like broadcast as "bad" without > a hint of justification. > > Rather than me try to defend this proposal against vague and > unsubstantiated criticism, I will first ask you to say exactly what is > wrong with this idea.
If you send from one node to many then you get exponential growth. You get a huge amount of redundant messages. Also, I don't see that this update would reach all the nodes holding the data at all. For example, if I run a local node, and I am particularly interested in a page (accessing it every few days) it is likely to be in my nodes cache. But what says that there would be any references to my node from another node that holds the data? Or that my local node would even be among the top N nodes where it sends the update? (my node doesn't have to cluster that data at all, one request every few days will hardly be enough to cause shifts in what my node "attracts"). And every time I attempt to Request the data, I would move the old document in my datastore to the top of the stack, meaning I would not be able to request new data for another several days. <snip> > Ergh - not sure I like this idea at all. Firstly there is the > assumption that there is a central "source" node for all data to which > all requests will be directed if not first intercepted by nodes caching > the data. This assumption is false. Secondly, even if there was such > central location, given that the vast majority of people, given the > choice, would want the latest version of the data, the whole caching > mechanism would basically end up not being used! > > So: A) This proposal probably wouldn't work > B) This proposal would prevent Freenet from functioning even as it > does right now! a) The situation is exactly the same as when the data is first Inserted. If a Follow-through Request does not at some point cross with the Updated data, then no Requests will cross paths with the inserted data when it is new either. The routing of the two is the same. b) Not at all. Why would it? The "heavy" operation is the sending of the data, and that is always done from the closest possible node, so in the case where a follow-through was used unnecessarily (the first node that had the data also had the latest version), the data is sent exactly as many hops. Yes, it would increase the number of messages, since the HTL would follow through, but that means going from maybe 5-10 to 20-30 messages for such a request, and they are very "light" operations, since more often then not, the a passed follow-through Request would not mean you had to send back any data. And even so, that is still a fixed number growing linearly with the number of requests and nodes, not any sort of exponentiel scheme. > > In this case the number of extra messages generated by the update would be > > relative to the number of people requesting the data, which is exactly what > > the > > number of places that the data is cached in is relative to. > > Yes, but all of these messages would be directed towards one > (potentially non-existent!) central source for the data, which would > probably fall-over immediately if the data was popular. A > double-failure! But it is exactly because such a node does not exist that it won't fall-over. The Update is not sent to one node but several, say 10-15 to begin with. And while it is possible that a follow-through request would not reach the same "cluster" is sent straight afterwards, some follow-through request would, and that would spread the update some more, and so on. Not an immediate process, but adequately fast. I have assumed that this is how we expect data to propogate after a normal Insert as well. And if it should prove that to many of the follow-throughs routed to the same place and put an unfair load on it, one could put some sort of timestamp with the update that gives a time before which it will definitely not be updated, so even follow throughs can end. In other words, if a follow-through comes along the data, it sees version 1.3, which is newer then anything it has seen earlier, but also sees a field that says "earliest-update-by" and then a time corresponding to several hours 20000409-1200GMT, it would know that this definitely the latest version, and it can stop looking. > Ian. > > _______________________________________________ > Freenet-dev mailing list > Freenet-dev at lists.sourceforge.net > http://lists.sourceforge.net/mailman/listinfo/freenet-dev -- Oskar Sandberg md98-osa at nada.kth.se #!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj $/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1 lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/) _______________________________________________ Freenet-dev mailing list Freenet-dev at lists.sourceforge.net http://lists.sourceforge.net/mailman/listinfo/freenet-dev
