From:
Ian Clarke <[EMAIL PROTECTED]>
Date:
Thu, 21 Nov 2002 16:19:14 -0800
At present, a node does nothing to refine or improve its routing table when a DNF is received - nodes only learn from announcements, and sucessful data replies.
I propose that we make DNFs more useful to the network. I have two proposals, call them A and B. A is pretty safe, B is more powerful but might help someone learn things about the network that we don't want them to know.
For both A and B, when a node initiates a DNF response, it includes in its response the closest key in its datastore to the one being sought. In proposal B, it also includes its own reference.
As the DNF passes back along the request chain, the nodes through which it is passed do several things:
1) Check to see if they have a key that is closer to the one being
sought than the one in the DNF message, if so they replace that key with
the closer one and forward on the DNF. In proposal B - they also
replace the reference with their own with, say, 90% probability if they
had a closer key, or 10% probability if they didn't.
2) The key in the entry in the datastore which was used to route the
failed request in the first place is then replaced by the key passed
back in the DNF (unless a closer reference was found locally in step 1).
In proposal B, the reference in that entry is also replaced by the reference passed back in the DNF, achieving a form of path compression similar to that in DataReplies.
Thoughts?
Ian.
Very interesting potential here. As Matt mentioned, this can be exploitable if it directly manipulates the routing table to point at a particular node without the node actually serving up some valid content. This can be avoided by hooking this in as an alternative response by the "repeated request rejection" mechanism. Instead of simply rejecting keys on the temporary blacklist outright, the references that get returned through Ian's mechanism could be attached to the recent keys blacklist and be searched via that reference while the key is "blacklisted". Only when valid data comes back will this temporary shortcut reference be made a real reference. This should set up a temporary path compression to virtually extend the HTL without actually involving more nodes then the global maxHTL and only allow the path compression to become permanent if the data is actually found.
Mike _______________________________________________ devl mailing list [EMAIL PROTECTED] http://hawk.freenetproject.org/cgi-bin/mailman/listinfo/devl
