On Friday 11 January 2008 18:24, Matthew Toseland wrote: > On Wednesday 09 January 2008 19:59, Robert Hailey wrote: > > > > On Jan 8, 2008, at 2:39 PM, Matthew Toseland wrote: > > > > >> In either case, resuming a request after we know that the upstream > > >> peer has forgotten about it could be very bad. Assuming 20 peers (ala > > >> opennet), the theoretical worst-case-per-node is that the last new > > >> request will leave the node about 40 minutes from when it entered the > > >> node. > > > > > > Not possible because of HTL. We will DNF (or timeout) before we've > > > visited all > > > 20 nodes. We don't allow RNFs to increase the HTL or change the > > > nearest-loc-found, but we do allow them to decrease the HTL. And we > > > decrement > > > the HTL unless nearestLoc improves (the HTL decrement/reset code > > > really needs > > > to be looked at, it's far from clear and may be wrong in places). > > > One caveat: > > > at HTL=10 or HTL=1, whether or not the node decrements is determined > > > probabilistically (the decision is made once per source node). > > > > It looks like the htl is decremented with respect to the source of the > > node (not the node we are routing to), so at 10 or 1 if the request > > came from a node w/o the probabalitic decrement (or if prob. decrement > > is disabled!) then the standard request search will try all it's peers. > > Ah. Yes, you are right. On the other hand, each of the nodes we route to and > get an RNF from should itself reduce the HTL, in almost all cases, so I'm not > sure that this fully explains it.
This hasn't been fixed yet. Comments on the proposed fix? -------------- 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/20080116/e116fa15/attachment.pgp>
