On Thu, Jun 07, 2001 at 09:26:10AM -0700, Ray Heasman wrote: > Hi Stefan, > > > > The fix for this is trivial, and will be left as an exercise for the > > reader. > > > :-) > > > > Reader stupid - author explain! > > The solution is to limit the percentage of the datastore that can be > affected by reads, as explained further in my reply to Ian on the "Another > possible bug" thread. Essentially you have two datastores, one for caching. > > I can't get anyone to comment on this proposal though. :-(
Here's a different approach to containing the volatility of freenet caches.. There have been a few efforts to define an elusive quantity called "P" which measures the popularity of a key in the cache. It's basically considered to have some kind of requests/time units, perhaps adjusted by file size. When you have to delete keys from the cache you kill the ones with the lowest P. The main advantage of doing this over an LRU cache is that the memory effect will tend to prevent the cache getting flooded out by short-term trends in popularity or some coordinated flood attack. The problem has always been lack of agreement on a good way to define P, and the fact that no such algorithm has been simulated. Usually the definition involves counting the number of hits on each key, and decrementing it somehow over time or by deliberately remembering no more than N hits. I have a new suggestion for this: just count the number of hits on each key and call that P, and whenever P reaches a certain limit, delete the key. This would probably be best handled by a certain random chance of deletion that increases with P. Otherwise, when you have to delete a key you delete the ones with lowest P. The question of how to deal with time is avoided by expiring the keys, which has the added effect of occasionally relaying the request upstream. We have reason to believe this may be a Good Thing :) -- # tavin cole # # "Technology is a way of organizing the universe so that # man doesn't have to experience it." # # - Max Frisch _______________________________________________ Devl mailing list Devl at freenetproject.org http://lists.freenetproject.org/mailman/listinfo/devl
