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. Anyway, fix it - decrement with respect to the node we are routing to after an RNF. -------------- 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/20080111/7a367980/attachment.pgp>
