On Thursday 31 January 2008 16:06, Michael Rogers wrote: > On Jan 30 2008, Matthew Toseland wrote: > >So I propose to implement weighted-coin-followed-by-HTL. This should cause > >very little disruption, as we won't have very short requests, in fact the > >code changes would be very minor. > > Sounds good - your arguments against parallel/repeated inserts are > convincing. What about automatic re-requests - if they're triggered by a > timeout or a DNF, could an attacker measure the fraction of re-requests > that reach his node and work out the likely distance to the originator? > Would randomising the re-request interval help?
At the moment, they are handled at the client layer. In fproxy for example we always try 3 times - and we start the second request immediately after the first one fails, if there is nothing else running. 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. > > >We can always change it later on to for > >example pure weighted coin (although I'm not convinced that will work well > >for inserts). > > Me neither - although we could use a lower pDrop for inserts if many of > them are failing to reach their targets. 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. Frost posts too, but then they'll be quite popular and well propagated through ULPRs. > > Alternatively, we could set pDrop very low (say 1%) but toss the coin > *before* trying each peer, which would count loops and overloads. If the > topology's any good, most searches will get close to the target and then > bounce around getting RejectedLoops until the coin comes up tails, which is > fairly cheap. But if the topology's broken and there are a lot of RNFs, > we'll have a higher chance of escaping dead ends. Also means that if there's a lot of load we visit fewer nodes per request. I dunno, sounds a bit messy, we'd need to simulate it. OTOH it'd be great to have something which leaks as little info as possible. > > 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/devl/attachments/20080131/0bf5a865/attachment.pgp>
