On Wednesday 30 April 2008 09:34, you wrote: > On Apr 29 2008, Matthew Toseland wrote: > >Oh, so you didn't actually simulate true random replacement with an index? > > Sorry, I don't understand - what would the index contain if you were doing > random replacement?
Keys to block number. Block numbers to keys is handled by the on disk structure. So we can actually pick a random block number to dump - but at the cost of having to keep a key index. > > > The big question is whether it is safe to have an implementation that > > doesn't support rekeying. If we have to periodically rekey then an > > indirect implementation will be necessary, which works on the same > > principles but is much more complex. > > I guess the question is what we're trying to protect against by rekeying. > If it's an attacker pushing a single block out of our cache by inserting > other blocks and then requesting the target block with HTL=1 to see whether > it was pushed out, I don't think we should spend any effort trying to > prevent the attack. There are a hundred worse things an attacker could do > with a similar amount of effort. True, I suppose. I'm surprised that hashing works so well, it has some big disadvantages e.g. once the datastore is say half full, half of all new incoming keys will overwrite old data rather than being added to the end. So we end up storing less data: it takes a much longer time for the datastore to fill up. What is the approximate ratio of store filling rates for the same size store on LRU versus on a direct hashing implementation? Can you simulate this? This is another advantage of an indirect design: if we can separate the hashtable from the storage, we can make it bigger than the storage, and achieve store filling rates close to that with LRU. > > >I thought there were standard models? I assume they all suck? > > There are standard models for things like phone and web traffic, but the > question is how will people use Freenet - how much of the traffic will be > file sharing, messaging, web browsing, etc? IMHO most of it will be filesharing, just as a massive chunk of the total internet bandwidth is filesharing. SSK polling for messages obviously will also be huge, right now we have 2.5 SSKs for every CHK (but SSKs are ~ 10x than CHKs). That should reduce a bit in future with some new measures such as RecentlyFailed ... but it will increase as FMS is more widely adopted... So no idea really... I do know that if we spend all our bandwidth on SSK polling, filesharing will not work well. :| Also, SSKs are kept in a separate store from CHKs, this is not likely to change. > > Cheers, > Michael -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/tech/attachments/20080430/2e37cb4e/attachment.pgp>
