On Monday 15 Sep 2003 16:57, Todd Walton wrote: > On Mon, 15 Sep 2003, Gordan wrote: > > On Monday 15 Sep 2003 11:29, Some Guy wrote: > > [routing] > > > > > One solution that was proposed to do this was to do > > > "light insertions" or "inverse passive requests". The > > > idea is to make a new insertion message which says the > > > sender has a trail to key X. This message follows > > > the regular routing path for a normal HTL. Every node > > > on the way stores the key and from which node it got > > > the message. When a request comes along it has a good > > > chance of finding a node which knows about the trail. > > > Such a node forwards the request back along the trail > > > to your "read only node". > > > > Unless I am mistaking, this would completely destroy anonymity. If > > there is a trail from a file to the inserting node, then a file can be > > conclusively associated with the node that is believed to have inserted > > it, and anonymity is nullified. > > There's the same kind of trail to a file now. Any given node knows only > that one other node knows where the file is. It doesn't ever know that > the node itself has it, or that the node it knows about has it. That's > the way it is now, and that's the way it would be with the above idea.
There is a difference between being able to guess which part of the network to route the request into and being able to follow the bread-crumb trail back to the node designated to "always make the files available". My understanding was that the latter describes the proposal put forth, but as always, I reserve the right to be wrong. > > Probabalistically caching 404 results for keys for a while may be a > > reasonably effective hack-solution, but it would not be perfect, e.g. > > the node could say "I received X requests for key Y in the past time > > interval Z. If X(Y)==404, then remember that for a while, and don't try > > to forward, just immediately say 404 without bothering other nodes. > > However, I am not sure what that would do to routing, especially with > > the new NG routing implementation. > > If I don't misunderstand you, that's what we do now. If you request > something, and the request comes back DNF, then an immediate request for > the same thing will stop right at your node. Your node, and any other > node that passed on the DNF, will see that it's already failed to find > the data, and won't even bother looking (for a specified period of time). > I don't know if there's any probabilistic caching going on, though. > > Is that what you meant? I think so, but a little bit more open ended. It often happens that hitting re-try on a 404 actually manages to find the key. This is probably a good thing, but what I was thinking about was a trade-off between allowing re-tries and stopping network abuse by constantly issuing requests for non-existant keys. In other words 2, maybe even 3 retries are OK, but 30 are definitely to be avoided. From what you said, I take it that nodes keep track of all DNFs they request/proxy, and respond based on that? Then there is the whole HTL issue thrown into the mix, too, but a DNF for HTL=X should probably also immediately return a DNF for HTL<X. For HTL>X, there should probably be some kind of a probabalistic DNF return, depending on how big HTL is... Gordan _______________________________________________ Devl mailing list [EMAIL PROTECTED] http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl
