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