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. > 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/ -------------- 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/02ced128/attachment.pgp>
