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.
> The way to update data over the entire network is to do a "follow through"
> request. Such a request would be the equivalent of the form of HTTP request
> that tells proxies do go back and check the web server for a new version even
> if they have the data.
> When one requests or inserts updatable data, one could simply choose between
> a normal request (speed), or a follow-through (ensurance that you get the
> newest data). Unlike a normal Request, the follow through would not stop when
> it runs into data, instead, it would put the timestamp or revision number of
> the
> data in a field of the request Message (if that field did not already include
> a
> newer timestamp or revision number), and then send the Request on. When the
> "Follow-through" request runs out of htl, it would simply send back a TimedOut
> containing the field with the newest version found, and the first node (least
> hops to the user) that had that version would turn the TimedOut into a
> DataReply, allowing any nodes with earlier versions "earlier" in the chain to
> get updated.
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!
> 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!
Ian.
_______________________________________________
Freenet-dev mailing list
Freenet-dev at lists.sourceforge.net
http://lists.sourceforge.net/mailman/listinfo/freenet-dev
