On Thu, Nov 21, 2002 at 04:19:14PM -0800, Ian Clarke wrote: > 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.
Questions: For proposal A, won't this result in the propagation of data that is not requested? Why is this desireable? Further, why should the network be transmitting data that wasn't requested and isn't going to be used? Is there some deeper magic I'm missing here? Because this kind of sounds just like needless traffic. As for proposal B, it's a good thing to spread references around the network, but why would my node want a reference that the query has proven doesn't have the data I'm looking for? If I issue a query and get a reference back, I would hope that my node would include that reference because it did something for me or because it has some information I might want that I don't have - not because the query has proved that it *doesn't* have what I want. > 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. What's the definition of a closer key? And given say a request at HTL 15 and thse probabilities, what are the chances of the original passed reference (or key) getting all the way back to the requester? (Or is this intended as a suggestion to also potentially strengthen other nodes in the request path, and not just the terminal node that made the request?) _______________________________________________ devl mailing list devl at freenetproject.org http://hawk.freenetproject.org/cgi-bin/mailman/listinfo/devl
