Broadcast updates are a really bad idea Ian, I didn't think I would see you of
all people using the dreaded "B" word.

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.

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.

Notice that not all requests for updatable data should be follow-throughs
(though all InsertRequests for updates would have to follow through of
course). One might for example tag an "update by" field in the meta-data, and
have the client make a wager based on that. If we can get it so that the number
of follow-throughs becomes an exponential distribution restarting at every
update, it should lead to very good and fast propogation of updates.

Also, the PK stuff that is in place will not help at all for updates. EDH is
useless for that, it has to use DSA or RSA signatures. I also maintain that
updatable data should be small and only contain references to CHK data for each
new version. Everything needed to make CHKs work is required to make SVKs work
anyways.


On Mon, 08 May 2000, Ian Clarke wrote:
> > When those things are done, I'll take on a next project. There isn't
> > anything else which is sufficiently agreed upon for me to just go ahead
> > and code it.
> 
> Actually I am quite keen on getting updatable data in there - here is my
> proposal:
> 
> Basically we need to use PK crypto which is already being integrated
> into the code.  We then need to implement sensible behaviour for the
> DataUpdate message.  I suggest this should search for the data in the
> usual manner, but then once it finds it's data, it should spread like a
> virus to "infect" all nodes storing the relevant data.  This could be
> done by a node forwarding the message to the N closest nodes to the key
> being updated in the datastore.  If a node receives a message and it has
> the data in question, then it updates the data (assuming the update
> request is signed with the appropriate key), and repeats the process. 
> If a node receives a message and it doesn't store the data locally, then
> it drops the message.  The message should also be dropped if the data
> has already been updated.
> 
> This may seem like a drastic and wasteful way to do it - but think about
> it, remember that to update data we must ensure that *each* node storing
> the data receives the update. The mechanism I describe should achieve
> this without too much excess of messages, and thus I think it may be the
> most efficient way that we can do this.
> 
> Whether it will work in practice is a different question, but there is
> really only one good way to find out (ie. suck it and see - the strategy
> we employed with the original Freenet design!).
> 
> 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

Reply via email to