On Fri, 19 May 2000, Ian Clarke wrote: > > Which results in: > > > > a) Weakening the benefits of the "Unrequest" since, presumably, the node > > will > > reply with the bad data during this period, allowing it to spread (and > > remember, > > if you are using KHKs then you are fucked ones you got the bad data, you > > can't > > request again and hope for better luck). > > Er, but if there is another request for the bad data, then chances are > it would wind up on this node again anyway, so the only difference is > that the request is answered immediately. We could also set a "do not > cache" flag on data pending an unrequest.
Which is exactly the reason I have had all the time to believe that unrequesting is too weak to combat cancers. And this does make things worse, because a node is obviously not the epi-center of all requests it receives, so requests for some of the bad data the node sends would not necessarily be routed back to it again should the new reference be destroyed right away. But if the unrequest is delayed, it gets several hours of free reign over the keyspace until the clients rejection kicks in. > > I think that with a little luck a > > cancer node could do massive damage within a few hours. > > > > b) Making Unrequest much moe difficult to implement, since the longer time > > since the request, the more difficult it will be to reset things (what was > > the > > old reference? where should it be in the stack?). > > This is purely a question of how good we are at coding - you never > struck me as someone who would shy away from a challenge ;-) I'm not against bad code, but I am resistant to creating functionality that I know from the beginning will not work smoothly. Trying to "undo" an event is inherently a clumsy and imperfect operation - and more so the longer time you allow between the events. There is even a law of physics about that... We do need some sort of feedback on search results however, so something like this will be necessary, I just want to keep as simple and light as possible. > > I still think the solution is to allow "Unrequest" only on reference > > entries. > > How does that address the problem? Because the Request-Unrequest-Request flood would not be worth while, seeing as the bandwidth costs is more or less the same as a simple Request-Request-Request (for a non existent key value varying from a targeted key by only the least significant bit). > Ian. > > _______________________________________________ > Freenet-dev mailing list > Freenet-dev at lists.sourceforge.net > http://lists.sourceforge.net/mailman/listinfo/freenet-dev -- Oskar Sandberg md98-osa at nada.kth.se _______________________________________________ Freenet-dev mailing list Freenet-dev at lists.sourceforge.net http://lists.sourceforge.net/mailman/listinfo/freenet-dev
