On Thursday 31 January 2008 17:13, Michael Rogers wrote: > On Jan 31 2008, Matthew Toseland wrote: > > It might be possible to do some stats, although I dunno exactly how; the > > second request would be routed differently with per-node failure tables. > > Right, but until failure tables are implemented an attacker can guess the > distance based on how many of the 3 retries reach him. Still, I suppose > it's an improvement over nearestLoc.
I'm assuming we make the choice once per peer per startup, for the sake of minimising the code changes. So it would go the same way - subject to backoff etc. Maybe he can do stats based on that? > > > Well for inserts subject to FEC, weighted coin might work. The concern is > > that not all inserts are subject to FEC - for example the top block of a > > splitfile. > > You could use a salted hash function to store redundant copies of the top > block under different keys (all derivable from the "main" key, eg the salt > values could be 1, 2, 3). But then even single-block inserts would be > vulnerable to predecessor attacks... It's an interesting tradeoff yeah... > > > Also means that if there's a lot of load we visit fewer nodes per > > request. > > True - in that case toss the coin before visiting each peer, unless the > previous peer gave us a RejectedOverload, in which case don't count it. But > I take your point, it is messy. :-) > > Cheers, > Michael
pgpQykgm5xdfJ.pgp
Description: PGP signature
_______________________________________________ Devl mailing list [email protected] http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
