> > The data source node may answer with the query > > reject message, > > After having already incurred processing and latency costs - i.e. too late > to do anyone any good.
You exaggerate the problem. Unless the data on the data source node is really slashdotted, it won't be more likely to be overloaded than any other node. There are still other nodes with the data around, that have the data source reset to themselfs. > > And existing weak points in freenet are not an argument to open up even > > more. > > Indeed. However, this does not create a new weak point. Your suggestion > does. Hit-count information can be dropped the very instant the recipient > decides they don't have time to deal with it, and can at the very worst > create an inaccurate picture of document popularity. This absolutely pales > in comparison to the problems that might arise if a node started spewing > redirects (to either legitimate or non-existent addresses) in response to > every request they saw. This would be only little more harmful, then a node that always returns request failed messages. It would be dropped from the routing table after a while. The only extra cost would be a request with TTL=1 to a bogus node. You could reduce the TTL in the second request proportionately. > IIRC, the goal here was to increase the persistence of popular objects by > making popularity information more accurate. The Principle of Least Fucking > Around says that changing Freenet's entire caching/routing strategy and > introducing myriad new possibilities of error or attack is not the way to go > about it. I admit that the protocol is more complex. I have dealt with all the attacks, that I could think of, in my originial post and I doubt that there are more. -- Thomas Leske _______________________________________________ freenet-tech mailing list [EMAIL PROTECTED] http://lists.freenetproject.org/mailman/listinfo/tech
