On Mon, Nov 17, 2003 at 06:52:49AM -0500, Edward J. Huff wrote: > On Sun, 2003-11-16 at 23:37, Ed Tomlinson wrote: > > On November 16, 2003 10:17 pm, Edward J. Huff wrote: > > > > I'm very confused by this. I was under the impression that a > > > > QR meant "DON'T back down the chain, just try another path" and > > > > that DNF meant "send a failure all the way back down the chain, > > > > as the HTL has been exhausted." > > > > > > ... Now I see. I only knew about QR's in the context of node > overload, not in their normal context, which occurs when the > key is found in the failure table or when (I guess) the node
Nope. We DNF when the key is in the failure table. > can't find a route. I've read only a small fraction of the code. > > QueryRejected.java: > > * This message is sent by a node which cannot locate a piece of data. > * If received by a node, it should either forward it back to whichever > * node sent the request to it, or should send another request to find > * the data. > > > But I saw other exchanges which make > > > much more sense if QR's do go all the way back. > > > > HTL does not get decremented until we can route. So a QR will not > > cause the cascade. For that to happen we need to find the data or > > get a DNF... > > I think you skipped a few steps in this proof. Apparently it must be > known that the only way to get a cascade is to find the data or to > exhaust HTL. So when a node QR's, HTL is not zero and the requester > will send another request unless it has no more nodes to send requests > to. In the latter case, you still don't cascade because the second > earlier node might have more routes to try. > > But, to return to the original subject..., there is an argument for > closing connections instead of QR-ing when load is high. If a node > closes connections, it continues to accept requests from the > connections it has. I argue that really, the node had too many > open connections to begin with, and probably it won't want to > open the connections again very soon. Also, when the backlog > is cleared, the node can open connections instead of sitting > idle until the QR back-off timers expire. Only if we blacklist nodes. And if the node has too many connections open and we close some, how will that slow down requesting anyway? It'd be a very weak effect - the definition of 'enough connections' means that it would be able to make lots of requests until it needed to send several trailers, at which point it would open more connections. Also multiplexing will mean it can send anything over one connection... > > Right now, my node has connections only to nodes which do > back-off. It has 148 connections to 82 different nodes, > (counting some old builds which got blocked at the firewall > within 5 minutes of connecting) but apparently all of them > are backed-off because it is getting only about 300 queries > per hour. It is completely idle, with no connections > transferring. If it had closed connections instead of > QR-ing, it would be able to re-open the connections now > and get more work. No, only if it blacklists them. However, there may be a problem with the backoff code: we only reset the backoff interval when we get a transfer failed, transfer succeeded, or DataNotFound. This may be insufficient because of the considerable time it may take for a request to reach that state. > > -- Ed Huff -- Matthew J Toseland - [EMAIL PROTECTED] Freenet Project Official Codemonkey - http://freenetproject.org/ ICTHUS - Nothing is impossible. Our Boss says so.
signature.asc
Description: Digital signature
_______________________________________________ Devl mailing list [EMAIL PROTECTED] http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl
