On Sat, Oct 26, 2002 at 01:32:18AM -0400, Michael Wiktowy wrote: > > > >Subject: > >[freenet-dev] Builds 524 and 600 > >From: > >Matthew Toseland <toad at amphibian.dyndns.org> > >Date: > >Sat, 26 Oct 2002 00:30:35 +0100 > >To: > >devl at freenetproject.org > > > > > >Trunk CVS is now build 600. Minor fix that should greatly reduce > >problems with RouteNotFound; we are increasing the build number to allow > >for changes to the stable version. The stable rel-0-5-0 branch is now > >build 524, with the same fix. Please upgrade, especially you Debolaz. > > > > > > > > > >Subject: > >[freenet-dev] rc2? > >From: > >Matthew Toseland <toad at amphibian.dyndns.org> > >Date: > >Sat, 26 Oct 2002 03:46:12 +0100 > >To: > >devl at freenetproject.org > > > > > >It turns out that the bug I just fixed with build 524/600 is fairly > >serious. As in, it leads to constant RNFs when trying to insert, even > >when using the desperation-mode-routing code I committed to the > >development branch CVS. And initially RNFs when trying to fetch too. We > >need a lot of nodes upgraded to 524 before 0.5.0 comes out. Thus we need > >to release 0.5rc2 IMHO. The questions remaining are: > >a) Do we include the desperation-mode-routing changes? This adds a > >second pass in TreeRouting if the first one fails, in which it will try > >backed off nodes and nodes with a low CP. > >b) Do we up the minimum build, now or soon? > > > >It's far too late for me to be doing things this important, so I am > >going to bed. But we need to deal with this tomorrow. > > > > I noticed quite a bit more RNFs when both requesting and inserting > things. I attributed it to a sudden surge of new nodes announcing > themselves and not having a clue where anything was. What makes No. The real reason is a delayed reaction from the 522ish builds. The network works so well for a few days that nodes are actually getting lots of references. The result is that there are concentrations of references to the same small group of nodes, and when a couple of them go down, when we search for a node to route to we see 20 of one bad node and 20 of another bad node and RNF because of maxRoutingSteps couting these duplicate refs when it shouldn't. This is the bug fixed in 524. > you think that this was actually something unknown and new to be > wrong in the code? Were there changes made between 522 and 523 > that screwed things up? Otherwise the build 522 way of doing things > seemed to work smoother if the RNFs are not traffic spike related. I > have not tried build 524/600 yet. > > Does a node that is rejecting a request know anything about the > request that it is rejecting (i.e. does it search its local store before > deciding it is too busy to forward it on or does it just reject any > incoming connections outright)? > > I know that there was a lot of talk about using HTL as a desision > making mechanism for biasing the choice to cache data or to reset > the datasource or not. Perhaps a more valuable use would be to > have a little bit softer edge on the desision to queryreject or not. We did this before, it didn't work. > If a request comes in with an HTL below some dynamic threshold > based on the average HTLs of the other queries in the queue, then > it is considered desperate and is handled. No, we didn't do exactly that, preferring low HTLs is silly it encourages bad behaviour. > > This has the double benefit of virtually eliminating RNFs and > encouraging using low HTLs (naturally discouraging high HTLs > rather then having a hard cap on the max HTL) > > Just a thought, > > Mike > > > _______________________________________________ > devl mailing list > devl at freenetproject.org > http://hawk.freenetproject.org/cgi-bin/mailman/listinfo/devl >
-- Matthew Toseland toad at amphibian.dyndns.org amphibian at users.sourceforge.net Freenet/Coldstore open source hacker. Employed full time by Freenet Project Inc. from 11/9/02 to 11/11/02. http://freenetproject.org/ -------------- 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/20021026/667af218/attachment.pgp>
