On Fri, Nov 22, 2002 at 12:55:24AM +0000, Matthew Toseland wrote: > On Thu, Nov 21, 2002 at 04:19:14PM -0800, Ian Clarke wrote: > > 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). > Hmm. Why is this helpful? 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 (but that is crude and risky given that > they have to stay in the routing table - being able to choose where > their ref ends up could be much more powerful for an attacker). And all > this without ever transferring any valid data. > > > > 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. > > > Just for sake of argument, another possibility: > Change step 1 to transfer the data for the key, not just send it on. But > later nodes should still replace it with a closer key if they can. Then > with a probability determined mainly by the absolute closeness of the > key, and the fullness of the datastore, add a reference and keep the > data (the common case is to forget both). We can't unconditionally do > this, because the key might be from anywhere, and might be made up. But > if the key is very close to the one we are seeking, say it shares the > first 32 bits (40? 50?), then presumably it hasn't been specially > manufactured for the occasion, so we can _add_ a reference, with high > (but not 1.0) probability. Also if the store is relatively empty it > would be good to store the file.
Also, normally updating the reference would move it (and the node) to the top of the LRU list. If we don't get a transfer of _the data we originally wanted_, we should not do this. > > Thoughts? > > > > Ian. > > > > -- > > Ian Clarke ian@[freenetproject.org|locut.us|cematics.com] > > Latest Project http://cematics.com/kanzi > > Personal Homepage http://locut.us/ > > > > -- > Matthew Toseland > toad at amphibian.dyndns.org > amphibian at users.sourceforge.net > Freenet/Coldstore open source hacker. > Employed full time by Freenet Project Inc. from 11/9/02 to 11/1/03 > http://freenetproject.org/ -- Matthew Toseland toad at amphibian.dyndns.org amphibian at users.sourceforge.net Freenet/Coldstore open source hacker. Employed full time by Freenet Project Inc. from 11/9/02 to 11/1/03 http://freenetproject.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20021122/0fed8070/attachment.pgp>
