outboundRequestLimit is incremented in only two places.
SendAnnouncement.java line 129 and Pending.java line 352. Both of these
places are counting OUTBOUND requests. outboundRequestLimit does NOT
count inbound requests. It is at no time compared to inbound requests.
I'll say it again: "It doesn't care how many requests the node has
received." If "the problem this limit is meant to address is keeping
the number of outbound requests from exceeding by much the number of
inbound requests" it is in fact doing the opposite of what it was
intended to do. It is very effectively allowing outbound requests to
run rampant while limiting inbound requests.
Examining the past 12 hours with my node running maximumThreads=0 and
maxConnectionsPerMinute=1000 started with an empty DS yields some
interesting numbers:
Average of 257 outbound requests per minute
Handled an average of 84 inbound requests per minute
Sent QRej 43 times due to outboundRequestLimit
36 client requests
Average of 718 threads created per minute
Average of 3 successfully requested keys per minute
Can that last one be right? I'm not necessarily arguing against
limiting outbound requests based on inbound requests, I'm just not sure
why we would want to. I'm just trying to point out that currently we
are doing the opposite, that is to say, limiting inbound requests based
on outbound requests.
-Pascal
Gianni Johansson wrote:
>
> On Thursday 27 June 2002 01:16, you wrote:
> > That would make sense, unfortunately that's not how it's currently
> How what's implemented?
> > implemented. With default values, all outboundRequestLimit does is make
> > the node QRej requests not in it's DS or FT if it has sent more than 60
> > requests in a minute.
> Yes this is true. I picked the values 60 back when it looked like that was
> about the maximum number of requests a node could sustainably handle. Maybe
> this value needs to be increased. Get data to determine whether this is true.
>
> >It doesn't care how many requests the node has
> > received.
> err... it is counting them. So to that extent it cares.
> > Nor does it actually limit outbound requests.
> > outboundRequestLimit is basically limiting inbound requests based on the
> > number of outbound requests. This causes nodes to actually prefer to
> > handle locally generated requests and QRej incoming requests.
> You are right, it does only count inbound requests. Unless you are doing
> something evil. (i.e. running Frost 24/7 inserting huge files), inbound FNP
> requests should be much more significant than local requests.
>
> You could improve the code by counting the local requests too.
>
> > The
> > current implementation of outboundRequestLimit very effectively causes
> > the problem of which you speak.
> >
> I have no idea what you are talking about. The problem this limit is meant
> to address is keeping the number of outbound requests from exceeding by much
> the number of inbound requests the node can handle. This limit does not
> cause traffic...
>
> > Having said that, it seems kind of silly to leave outboundRequestLimit
> > in place as it's currently implemented. Is there a flaw in my thinking
> > or does outboundRequestLimit need to be pulled pending a rewrite?
> >
> See above.
>
> You have presented no convincing argument for removing this limit.
>
> You have correctly pointed out that a) maybe we need to rexamine the limit
> value and b) we should be counting the client requests.
>
> There should also be an explicit rate limit on client requests but that's a
> different issue.
>
> If you have time to fix any of these issues, that would be great.
>
> -- gj
>
> > -Pascal
> >
> > Gianni Johansson wrote:
> > > The reason these limits are there is to keep badly behaved nodes from
> > > DOSing the rest of freenet. There were situations where nodes would try
> > > to send hundreds of times more requests than they could answer.
> > >
> > > It isn't a good idea for nodes to try to send more outgoing requests than
> > > than they handle incoming ones. At least not on average across the entire
> > > network. Think of conservation arguments in physics...
> > >
> > > -- gj
> > >
> > > On Wednesday 26 June 2002 23:30, Pascal wrote:
> > > > If the diff below is complete, your changes have done nothing other
> > > > than remove the notification to you when incoming connections are being
> > > > rejected. The actual rejecting of connections is not handled by
> > > > rejectingRequests(). If you'd like to see what actually happens when
> > > > your node ignores the overload code you'll need to recompile from cvs
> > > > (or wait till the 6-27 snapshot comes out), change maximumThreads in
> > > > your config file to 0, and set maxConnectionsPerMinute to a high number
> > > > (I use 1000.)
> > > >
> > > > -Pascal
> > > >
> > > > Tril wrote:
> > > > > I setup a node on a fast connection. Pretty soon it started
> > > > > QueryRejecting all incoming requests half the time, even though the
> > > > > machine was still usable for other things. I wanted to see what sort
> > > > > of resources Freenet would use if it tried to handle all of the
> > > > > requests. So I went and found the place in the code where it was
> > > > > deciding when to QueryReject all incoming connections, and read it.
> > > > > It didn't seem to be doing anything that I wanted it to do, so I
> > > > > commented it out entirely.
> > > > >
> > > > > Patch below. This change does not seem to increase the CPU usage of
> > > > > Freenet noticeably, in fact it seems to me to have decreased it a
> > > > > small bit, but it could just be me. My node runs better with this
> > > > > change. It does not say "QueryRejecting all incoming connections"
> > > > > (except if the number of threads in use is equal to maximumThreads,
> > > > > so that must be done somewhere else that I didn't look into because
> > > > > that behavior is fine with me). More requests can therefore be
> > > > > handled.
> > > > >
> > > > > The node has been running for some time since this change with no
> > > > > apparent adverse effects.
> > > > >
> > > > > Can someone explain the purpose of the two checks I removed?
> > > > >
> > > > > 1. keeping a frequency count of *outgoing* requests and rejecting
> > > > > incoming ones if it is too high? Why is the default
> > > > > (maxConnectionsPerMinute) 60 per minute? Is performing this
> > > > > frequency count expensive, explaining why commenting this out reduced
> > > > > load?
> > > > >
> > > > > 2. looking for activeJobs 2/3 (now 3/5) of maximumThreads?
> > > > >
> > > > > It seems to me that these checks only serve to make nodes appear
> > > > > overloaded when they actually aren't. Is it possible Freenet is not
> > > > > overloaded at all?
> > > > >
> > > > > My machine is about 500MHz. I'd be curious what happens with this
> > > > > patch on a slower machine.
> > > > >
> > > > > Index: Node.java
> > > > > ===================================================================
> > > > > RCS file: /cvsroot/freenet/freenet/src/freenet/node/Node.java,v
> > > > > retrieving revision 1.25
> > > > > diff -u -r1.25 Node.java
> > > > > --- Node.java 26 Jun 2002 01:42:13 -0000 1.25
> > > > > +++ Node.java 26 Jun 2002 23:34:22 -0000
> > > > > @@ -950,11 +950,7 @@
> > > > > * @return true if the Node is QueryRejecting inbound requests,
> > > > > false otherwise.
> > > > > **/
> > > > > public boolean rejectingRequests() {
> > > > > - if (outboundRequestLimit.exceeded()) {
> > > > > - return true;
> > > > > - }
> > > > > -
> > > > > - return activeJobs() > (3 * maximumThreads / 5);
> > > > > + return false;
> > > > > }
> > > > >
> > > > > /**
> > > > >
> > > > > --
> > > > > Tril 0. Byte <[EMAIL PROTECTED]> http://tril.tunes.org/
> > > > > PGP key fingerprint: DADB ED32 6E54 80D0 7E69 7549 C3A3 446F CAA4
> > > > > 66C0 This message is placed in the public domain.
> > > > >
> > > > >
> > > > > ---------------------------------------------------------------------
> > > > >--- Part 1.2Type: application/pgp-signature
> > > >
> > > > _______________________________________________
> > > > devl mailing list
> > > > [EMAIL PROTECTED]
> > > > http://hawk.freenetproject.org/cgi-bin/mailman/listinfo/devl
> > >
> > > --
> > > Freesite
> > > (0.4) freenet:SSK@npfV5XQijFkF6sXZvuO0o~kG4wEPAgM/homepage//
> > >
> > > _______________________________________________
> > > devl mailing list
> > > [EMAIL PROTECTED]
> > > http://hawk.freenetproject.org/cgi-bin/mailman/listinfo/devl
> >
> > _______________________________________________
> > devl mailing list
> > [EMAIL PROTECTED]
> > http://hawk.freenetproject.org/cgi-bin/mailman/listinfo/devl
>
> --
> Freesite
> (0.4) freenet:SSK@npfV5XQijFkF6sXZvuO0o~kG4wEPAgM/homepage//
>
> _______________________________________________
> devl mailing list
> [EMAIL PROTECTED]
> http://hawk.freenetproject.org/cgi-bin/mailman/listinfo/devl
_______________________________________________
devl mailing list
[EMAIL PROTECTED]
http://hawk.freenetproject.org/cgi-bin/mailman/listinfo/devl
