On Sunday 30 December 2007 13:19, Michael Rogers wrote: > Matthew Toseland wrote: > > - Not compatible afaics with ULPRs / failure tables. ULPRs stop requests if > > we've routed them already (for some period), with the same HTL or less. > > Good point, and I guess the same would be true of request coalescing. > Maybe we could get a similar effect by using the weighted coin to decide > whether to coalesce or forward the new request. > > > - Load management issues maybe. > > Do we currently use the hop counter for any load management decisions?
No, but it would make the request time variance much higher, especially for inserts and unsuccessful requests (which can potentially visit the entire network). > > > - It's a good "invisible" DoS on a single request. > > Sorry, I don't see what you mean - the hop counter can be tampered with > but a weighted coin can't, making it harder to influence how other nodes > handle the request. A lot more requests will naturally timeout than do now, and therefore a node can silently drop a request without arousing much concern or suspicion. Per node failure tables can't reroute that key until the timeout happens, and if the timeout is larger than it is now, that takes longer. > > > - The current counter is reset when we get closer to the target, so to some > > degree it adapts to the network size. We'd lose this, so we may have to set > > the probability of termination quite low, and fiddle with it... > > Good point, I didn't realise that resetting the counter had that function. > > > Why can we not analyse how much information the current counter leaks? Because > > of the uncertain topology/average number of resets? > > I shouldn't have said we can't analyse it, but I wouldn't know where to > start because so much depends on the topology. For example, the > closest-location-so-far obviously leaks information, but how do we > quantify it? Isn't it similar to the situation with keys? -------------- 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/20080103/c21df9d9/attachment.pgp>
