On Wednesday 09 January 2008 17:14, Robert Hailey wrote: > > On Jan 8, 2008, at 2:27 PM, Matthew Toseland wrote: > > > On Friday 04 January 2008 18:32, Robert Hailey wrote: > >> > >> Apparently until this revision 16886, (so long as any one node does > >> not timeout) a node will take as long as necessary to exhaust > >> routable > >> peers. Even long after the original requestor has given up on that > >> node. > > > > Is there any evidence that this happens in practice? Surely the HTL > > should > > prevent excessive searching in most cases? > > I have reverted r16886, as it appears to be based on a misunderstand > of how requests work against the topology of the network (r16980).
I was rather hoping to be talked into accepting 16886 ... we should at least have some logging in such cases IMHO. Requests really shouldn't be taking that long - maybe it's related to the HTL problem, maybe we have such a perverse network topology that we are resetting HTL time after time after time, I dunno, simulations would be interesting. > > Instead of canceling the search request, I have put similar logic in > RequestHandler to simply not respond to very old requests (r16982), Ok. Maybe this is where we should have such logging. > and not to hang onto the thread if no response is therefore necessary > (r16983). > > r16983, (given the timeout) makes extra calls to rejectedOverload(); I > imagine that at the timeout (every 2 minutes while the local request > is running) they are benign, but I can code up an infinite wait (as > before) if needed. Well it's not strictly infinite - it's 2min*peers at most. You reverted this in 16985. > > I'm going to try and stay away from high level changes for a while, > but at your suggestion I will look at the HTL code. You are more than welcome to continue to investigate the timeouts, they have been a problem for a long time. Do they still show up in simulation with the HTL problem fixed? I'm very happy to have somebody else working on core stuff, I'm equally happy to point out any obvious problems with their commits. :) -------------- 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/84cca761/attachment.pgp>
