> > 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 <snip> > 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.
It would appear you are correct (I changed the attenuation value from 1 to 5 and then 15 in my node with no noticable effect on nodes passing me requests) > 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 the real issue is the thread per TCP connection; if we were in C I'd complain about the lack of using select when waiting on the TCP connections to avoid this and have us only give the connection a thread when the connection was actively receiving/sending data (eg large trailing fields); I don't know if Java has an equally efficient means of doing this that we just aren't using or if Java itself is impared from this sort of efficiency methods (unfortunately I don't really know enough Java/have enough experience yet to know which it is) > > 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 <snip> > 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 believe that there *is* a difference between local and forwarded requests; the node that forwarded the request can go off and use a different node if the local node cannot handle the request; the local request is stuck with the local node and hense why local requests can push a node over 100% capacity <snip> > > On my node I am actually fiddling with these ratios in the opposite > > direction... > 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) It is on a slow machine; so my numbers don't compare to yours but; in a *day* before changing the numbers I would handle ~1.8k of ~ 64k requests; after making the change it was handling 18k of ~ 64k Note that the thread count was adjusted upwards to counter the effect of the ratio going downwards - I suspect the increased capacity you are seeing is from the thread count not being lowered to counter the effect of the ratio going up and your machine wasn't configured to max capacity to start. I have compiled the node with the ratios more to the direction of your way; and lowering the thread count so that the machine doesn't get into cannot create process situations - but I don't expect it to be fair anymore as I have gone off and added an accepted requests histogram and key located for a request histogram to my node recently; so that has probably created an additional load which will disrupt my other numbers so they are probably not comparable (I will create diffs against the latest CVS version when I get a moment -- is this list an appropriate place to mail diffs to [I don't have CVS access; and I think it would be better to have my changes vetted by someone prior to applying them to the CVS in any case]) Trevor _______________________________________________ devl mailing list [EMAIL PROTECTED] http://hawk.freenetproject.org/cgi-bin/mailman/listinfo/devl
