Ian Clarke:
> Because when a node forwards a request for a key to a particular
> reference, it is saying "I think this key will be found if it send it to
> this node". This will improve the node's impression of what keys it is
> actually likely to get by forwarding the request to that node, as well
> as "punishing" that reference for the DNF.
I don't think this is true. Consider:
Ref (key X -> node Y)
|........................X........................|
<- Y's KEYSPACE ->
We route a request for Kreq:
self -> Y -> N1 -> N2 -> N3 -> N4 -> N5
and N5 returns DNF, appending the closest key in its store, Z, which is in
the center of its keyspace graph:
|........................Z........................|
<- N5's KEYSPACE ->
Where does Z fall on Y's keyspace graph? Maybe:
|..Z..............................................|
<- Y's KEYSPACE ->
We change (key X -> node Y) to (key Z -> node Y). See? Now we're routing
worse than before. In effect, we've replaced key X with a random other key
Z, subject to the constraint that Z is closer to X than any other key in our
store. Now imagine this happening, repeatedly, to every key. They start to
wiggle and drift around.
Anyway, these keyspace graphs are pretty silly, and probably don't
correspond much to reality. The key objection I have is:
* Failure of node Y to succeed for key Kreq does not imply that key
X is 'bad' with respect to node Y.
* Key Z is not likely to be 'good' with respect to node Y.
Moving on, your other proposed strategy is roughly, "If we can't put a
(key -> node) reference in our store normally - one that ties a found key to
the node that found it - we'll settle for a nearby key."
Consider what happens when one of these (key -> node) references, which was
put in the store as a result of a failed request for Kreq, is used to route
a request for Kreq in the future. That's right: it fails just like the first
time. So, as I commented in #freenet, we have path compression, alright, but
the path leads straight to failure.
_______________________________________________
devl mailing list
devl at freenetproject.org
http://hawk.freenetproject.org/cgi-bin/mailman/listinfo/devl
