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-- 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.
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)
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.
On my node I am actually fiddling with these ratios in the opposite
direction...
Trevor
> 1) my node will handle more requests before going into an overload state
and
>
> 2) there'll be a smaller window between being not-overloaded and
> refusing connections. Because of this smaller window, the node
> will be sending back fewer QueryRejected messages, and with the
> same load will refuse more connections.
_______________________________________________
devl mailing list
[EMAIL PROTECTED]
http://hawk.freenetproject.org/cgi-bin/mailman/listinfo/devl
