> Okay now my question is, how do you prevent node D > from sending the query back > to node C, thus wasting everyone's bandwidth and not > getting any closer to the > data, which is actually on node F? Oh ok, that's easy just store a small hash table of "key X request already processed" (actually it's message X), you'll only have to store a few entries in the table since a query should resolve in a "few" seconds and you can only recieve so many a second (bandwidth) anyway. When a node get's a request it has processed before it returns back a "failed" message which shouldn't decrement HTL.
> There is a very good paper which argues exactly this > kind of negative result: > > The Sybil Attack (2002), by John Douceur > http://citeseer.nj.nec.com/douceur02sybil.html Thanks I'm reading it. > There are two flaws in the premises of this paper, > and its conclusions do not > directly apply to networks like Mnet and Freenet, > but it is a paper that you > ought to read if you are thinking about these > issues! (Hint: IMHO one of the > two flawed premises is that the network is composed > of completely untrusted > nodes...) Think I just had a BIG idea on how to kick the securty problem's butt, so that we can use something simple like Chord. It involves cells of trusted or semi-trusted nodes acting as one to cover a keyspace. I'll think it through though before I post. > > > I thought this too at first glance but no. What > will > > happen is the first two points will come in toward > the > > middle of the hump. Once they get into the .004 > of > > the keyspace, queries just outside those two > points > > will yank the others in one by one. > > I don't think this will ever happen -- it takes > infinite time for > the other points to move inside. Oh wait -- do the > points move a fraction of > the remaining distance each time? (Zeno's Paradox) > Or do they move a fixed > distance? Yes, think about it: if the node's specialization was like a bar (or a hump) when queries from the middle suceeded they would pull the points inside the bar. As soon as that happened queries from the edge of the bar would start pulling on new points. > > Only problem and this counts for all of these > learning > > sytems: the uncertainty priciple. When we measure > how > > well another node is in a certain keyspace, by > giving > > it queries, we affect what we're messuring. > > Heh -- good point! I hadn't thought of that. > Doesn't seem like a real > problem in practice though, does it? If the learning process takes too long it will be a problem. This is the flipside to if the learning process is too short (forgetful) noise will be a problem. If a node specialized in 0.001 of the keyspace it'd take 1000 queries just to hit its area let alone learn it with some heuristic. I've suggested that nodes should just say what they're specialized in and then be judged by thier neighbors if they live up to it. Someone suggested there's a security risk when you let nodes decide where they want to specialize. Sure, but I would argue that they can do this anyway. They just have to act real good in the target area and delay responses elsewhere enough. __________________________________________________________________ Gesendet von Yahoo! Mail - http://mail.yahoo.de Logos und Klingelt�ne f�rs Handy bei http://sms.yahoo.de _______________________________________________ devl mailing list [EMAIL PROTECTED] http://hawk.freenetproject.org:8080/cgi-bin/mailman/listinfo/devl
