On Wednesday 16 January 2008 16:53, Matthew Toseland wrote: > 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?
I'm fairly convinced this is the right way to go. Conceptually, we send it to a node, the node gives us a route not found, we now treat it as a new request from the new node and therefore decide whether or not to accept it on the basis of the new node's decrement-at-full-htl flag (of course we don't do the usual triage, since we've already invested a fair amount of time in it, that's where the metaphor falls down). -------------- 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/b456ff7e/attachment.pgp>
