Oskar Sandberg <md98-osa at nada.kth.se> wrote:
> 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.

how do you know which node is the "first" node, though?  It's actually the
last node containing the good version as you go back to the user, and a
node has no way of knowing whether it's the last one or not.  (Unless you
accumulate node-version pairs in the request as it goes forward, which
doesn't sound too good.)  Also, even if we do implement it this way
somehow, it minimizes the number of nodes participating in the DataReply
chain, which sounds good but means minimizing the number of nodes whose old
versions will get updated.

How about this:

- the last node to see the Request (first node to see the TimedOut), i.e.
  furthest from user) that has the correct version turns it into a
  DataReply.

- it also sends the DataReply downstream as well (setting HTL as the Depth
  from the TimedOut message), so that those nodes can get updated too.

For example:

user       v1       v3       v2      v1     v3     v1     v2
Request-0->   -1->     -3->     -3->    -3->  -3->    -3->
                                              <-3-    <-3-TimedOut
       <---   <---     <---    <---DataReply  DataReply--->


(maybe that TimedOut should actually be some type of Request instead?)
theo


_______________________________________________
Freenet-dev mailing list
Freenet-dev at lists.sourceforge.net
http://lists.sourceforge.net/mailman/listinfo/freenet-dev

Reply via email to