> > 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). > Hmm. Why is this helpful?
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. > It is of course a potential problem in that > nodes could use it to manipulate their perceived specialization in the > requesting node's routing table, although they can do that anyway by > selectively answering requests How? Either they put a key close to the requesting key in the DNF, which is what we want, or if they put a distant key in there, then one of the upstream nodes will quickly replace it. > Change step 1 to transfer the data for the key, not just send it on. And waste network bandwidth transferring unwanted data? Ian. -- Ian Clarke ian@[freenetproject.org|locut.us|cematics.com] Latest Project http://cematics.com/kanzi Personal Homepage http://locut.us/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 232 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20021121/b51e6c49/attachment.pgp>
