>>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.
For those who're wondering, what this does is tell requesting nodes "I don't have the key you wanted, but I do have this one." Knowing which keys are where is central to Freenet routing. The requesting node, when it gets this DNF back, will effectively say, "OK, the data I wanted isn't where I thought it might be, but if ever I wanted data that looks like this returned reference, I now know where to look." >>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. Obviously numbers can be tweaked, but as the network grows (and therefore HTL's and request chains grow) this would become increasingly good at hiding the actual reference for the data from the initiator. And is definately an excellent way of learning about more nodes. >>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). Following on from my earlier explanation, the node takes the reference that cause the original search (which failed), and says, "That's no good for the search I wanted, but I do know what searches it is good for now." >>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. Same as above, but with the added benefit of skipping over some of the earlier nodes in the request chain, making the request quicker. >>Thoughts? Nice idea, especially if the refinement below can be made to work. >>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. Would certainly alleviate the problem, but can we rely on there being a a repeated request rejection (RRR) for that key? Or do you mean adding another RRR with the returned key? If you replaced the RRR of the requested key, then requests for that key would no longer be blocked, and if you attached the new reference to the requested keys RRR, then you'd simply get the same DNF, but quicker? But certainly having a "pending table" of suggested (but unconfirmed) references of some kind would work. Wait, isn't that what the routing table largely is, anyway? :P [ cruise / casual-tempest.net / transference.org ] _______________________________________________ devl mailing list devl at freenetproject.org http://hawk.freenetproject.org/cgi-bin/mailman/listinfo/devl
