"Trevor Smith" <[EMAIL PROTECTED]> writes: > Interesting observation and thought; > > I wonder though if that is really the desired method of controlling the > traffic; from my (brief) reading of the code; it appears that the query > rejected message is able to indicate to the caller how much it wants the > node to back off. If we were to have the node adjust this value upwards the > longer that it stays in the overload state; then the nodes would back off > sufficient for the node to function--
The queryRejected message is in theory able to do that, but as far as I know, there's no mechanism in place for this to actually happen. If a node gets a QRej with the reason being node overload, the only thing it does is stop contacting the overloaded node for a minute. It'd probably be better to have a more complicated mechanism for allowing the overloaded node to say how long to back off for, or to backoff for longer periods if a node is overloaded on consecutive requests. But at the moment there's nothing going on like that. > I am concerned with a node refusing > incoming connections (which may contain answers) as I have been watching my > logs; and to me I am seeing numerous requests getting answered and then not > leaving my node because it is unable to re-establish communication with the > initiating node. > This is a problem, and honestly I don't think there's much of a solution to it in an overloaded network. (at least with the message layer like it is, where TCP connections between nodes an be made and broken at any time) More messages being passed around means that nodes have to either be able to handle greater load or refuse some connections. > I think we have to remember that there are multiple usages that the nodes > are running in: > 1) a node to handle requests; little or no client usage > 2) a node to handle requests and client usage > 3) a node for client usage; transient > > Tuning of parameters that might be useful for one of these usages; might not > give good results for other usages; I am all for getting as many of the > constants that are useful to adjust for different loads out of the code and > into the config files; and possibly altering defaults from time to time; but > I personally rather not see constants being altered in the source files as a > way of tuning the network (please note that I know very little about what is > best for freenet; so while I am expressing my opinion; please note that I > also will defer to people like gj if they wish to indicate a desired > direction) > I disagree; there's just one parameter, the number of requests going through a node. There's really no difference between a request generated locally (by a client) and a request forwarded from another node. Transient nodes have a lot lower request load because they're only carrying one person's load and not a share of the network load, but that's the only distinction that can be drawn. There's *no* difference between your cases 1 and 2. I agree that many of these constants should be in config files, and as soon as I figure out how to make that happen, I've got a large number of them to move. > One thought in regards to all of this; I haven't noted anywhere in the code > any sort of flag to indicate to the transport layer the importance of the > message (eg for a query reject; I see no reason to establish a connection if > necessary to send the message unless the query reject is for a query that > was already accepted) while for other types of messages it does make sense > to do so. > Support for it at lower levels would be more difficult than just adding it to the transport layer. > On my node I am actually fiddling with these ratios in the opposite > direction... > > Trevor > Interesting; I'd like to find out how many requests your node is recieving and how many it's handling. (Diagnostics variables inboundAggregateRequests and inboundAggregateRequestsHandled) Thelema -- E-mail: [EMAIL PROTECTED] Raabu and Piisu GPG 1024D/36352AAB fpr:756D F615 B4F3 BFFC 02C7 84B7 D8D7 6ECE 3635 2AAB _______________________________________________ devl mailing list [EMAIL PROTECTED] http://hawk.freenetproject.org/cgi-bin/mailman/listinfo/devl
