> > > From: > Ian Clarke <ian at freenetproject.org> > 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 devl at freenetproject.org http://hawk.freenetproject.org/cgi-bin/mailman/listinfo/devl
