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
