On Thu, Nov 21, 2002 at 07:39:54AM -0600, Edgar Friendly wrote: > Tyler Riddle <triddle_1999 at yahoo.com> writes: > > > This is only a bad idea if you enjoy having RNF and > > DNF ruin your freenet using experience. I suggest you > > actualy try the patch and see how effective it is at > > pulling pages through that DNF at HTL 25 after 3 or 4 > > attempts (just leave your page open over night and you > > run a good chance of having it waiting for you in the > > morning). > > > First, if your node is RNFing, retrying the request is among the last > things you want to do. RNF can be a sign that your internet > connection is down (and your node can't contact any others to forward > requests to). When this is the case, auto-requesting until you find a > key will not only never find the key, but it'll empty your routing > table as every node in it fails connection requirements time and > again. That doesn't empty your routing table, does it? If so, it's a bug. References are deleted only when the table fills up (now), AFAIK. > > If a page has DNFed at HTL=25 after 3 or 4 attempts, it should be > "not-retrievable", and given up on. If the key is in freenet and Maybe so. But IMHO exponential backoff is cleaner. > isn't being found, the solution is *not* to add a auto-retry "feature" > into fproxy; that's just patching over the symptom of the problem. > The real problem is that the key isn't being found, and it's this that > needs to be worked on, either by tweaking routing table settings so > that nodes (in general) use more information to route, or by making Oh yes, making nodes route to hosts less likely to find the key just because they are faster is obviously going to improve network performance. This is the line you have always advocated, it may work in terms of speed for successful requests but it certainly doesn't for reliability. > requests more lightweight so that higher HTLs can be supported. HAH. How? Also: what makes you think that a max HTL of 25 is insufficient for the current network, given a bit more time to evolve? DNF does not necessarily mean the request visited that many nodes - it only means that it ran out of HTL. The request can lose a hop by not connecting somewhere, or being rejected, or whatever. > > > > Regarding the "flood the network" switch, we allready > > have frost which does a plenty good job of flooding > > the network. I'm no freenet expert but I suspect the > > ammount of trafic this will generate (one request > > every couple to 10 minutes at high HTL) is minimal > > compared to the load that frost places on the network. > > > > Tyler > > <SNIP> > > Frost is *not* distributed as part of the node. Yes, many people are > using frost to flood the network, but that doesn't mean we should make > people flood the network each time they browse to an edition-based Given exponential backoff I would argue that this is not flooding in any meaningful sense. > site. Yes, I'm talking about the links to future editions, which will > set fproxy working forever trying to find data that's not in the > network. As for your characterization of "one request ever couple to Only if you click the link. The broken images will NOT cause a retry. It's in the HTML, not the headers. > 10 minutes", I see that number easily becoming *much* larger after a > short amount of browsing. > > Thelema > -- > E-mail: thelema314 at swbell.net Raabu and Piisu > GPG 1024D/36352AAB fpr:756D F615 B4F3 BFFC 02C7 84B7 D8D7 6ECE 3635 2AAB >
-- 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/1/03 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/20021121/bb0c83e1/attachment.pgp>
