On 6/19/06, Matthew Toseland <toad at amphibian.dyndns.org> wrote: > On Sun, Jun 18, 2006 at 02:26:03PM -0500, David Sowder (Zothar) wrote: > > Florent Daigni?re (NextGen$) wrote: > > >* zothar at freenetproject.org <zothar at freenetproject.org> [2006-06-18 > > >19:02:38]: > > > > > >>Author: zothar > > >>Date: 2006-06-18 19:02:33 +0000 (Sun, 18 Jun 2006) > > >>New Revision: 9304 > > >> > > >>Modified: > > >> trunk/freenet/src/freenet/node/RequestSender.java > > >>Log: > > >>Mitigate "backoff hell" a bit by not routing to a peer if it's the only > > >>one not backed off and we have a few backed off peers. > > > > > >That's what we call alchemy, isn't it ? :) > > > > > >Well, I do see the point of not sending our requests when we have only > > >one online peer (even if there is plausible deniability) but why the > > >"backoff throwsold" ? to allow nodes with less than 4 peers to be usable > > >? > > >I'm not sure I agree to the concept, maybe I'm missing the point though, > > >may you explain ? :) > > > > > When I got back to my node after being away from it for 24 hours > > Saturday night, it was in what I call "backoff hell". I've seen > > "backoff hell" at least one other time. It's when all of your connected > > peers are backed off and every time one of them comes out of backoff, it > > goes right back into back off very quickly. I assume this is because my > > node is eager to send that node anything it has, no matter how misrouted > > it is. I don't recall from last time, but I must admit that this time, > > the reason was usually timeouts rather than overloads. You're right, > > the backoff threshold is so that nodes with fewer than 4 peers don't > > have this restriction. > > Are you sure that it wasn't due to some external factor, like high CPU > usage, or network saturation? > > > > I agree that this is alchemy, but I figure it'll give a node more of a > > fighting chance of recovering from "backoff hell" and since that's the > > only time it'd apply, the impact otherwise should be nil. Perhaps some > > of the SoC work this summer will make such alchemy unneeded. However, > > just because it's alchemy doesn't mean it can't be useful. > > Hmmm... I will have a look at it when I get around to reading the > commit... > --
> Matthew J Toseland - toad at amphibian.dyndns.org > Freenet Project Official Codemonkey - http://freenetproject.org/ > ICTHUS - Nothing is impossible. Our Boss says so. > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.1 (GNU/Linux) > > iD8DBQFEl2DTHzsuOmVUoi0RAllBAJsHcZqWAGUL7px786TEPHwAiILvygCeNpBg > paJQpkaU+nvh65HNOL+nf74= > =HBVS > -----END PGP SIGNATURE----- > > > _______________________________________________ > Devl mailing list > Devl at freenetproject.org > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl > > This does seem to make "some" sense in that a 50/50 choice between two routes should give better routing than no choice at all... It might be what's needed to prevent a complete routing collapse or a feedback loop, assuming everything else is bug-free. -- I may disagree with what you have to say, but I shall defend, to the death, your right to say it. - Voltaire
