> 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.

> 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 still think the solution is to allow "Unrequest" only on reference entries.

How does that address the problem?

Ian.

_______________________________________________
Freenet-dev mailing list
Freenet-dev at lists.sourceforge.net
http://lists.sourceforge.net/mailman/listinfo/freenet-dev

Reply via email to