On Mon, Dec 31, 2001 at 12:47:29AM -0500, Tavin Cole wrote: > On Sun, Dec 30, 2001 at 05:47:04PM -0600, Edgar Friendly wrote: > > To fix this problem, I propose two things: > > (1) default maxNodeConnections to 70 > > (2) subtract maxNodeConnections from maximumThreads on transient nodes. > > Increasing maxNodeConnections I can go along with. It probably isn't > necessary to mess with the maximumThreads setting (at least, we should > fix the more obvious problems before making more subtle tweaks whose > effectiveness will be difficult to assess). > > But I was wondering why we don't just do away with maxNodeConnections > entirely (after all, arbitrary constants are bad), and let the > availability of threads be the sole determinant in whether a connection > will be accepted. It is not a 30-second hack of changing a constant > config value, but I believe it could be achieved fairly easily.
I believe that that setting is there because you wanted a limit to the incoming FNP connections that would not prevent the node from accepting FCP and HTTP queries. > Also, I think we should greatly reduce the idle connection timeout. It > is currently at 3 minutes. 10-15 seconds is sounding more reasonable to > me at this point (my intuition is that it should not be significantly > larger than the time it takes to set up a new connection). Remember the > value was effectively zero in the 0.3 network, which, if my sense of > history serves, had fewer problems with nodes rejecting connections. I agree. It is also possible that the threshhold idle() period when pruning connections should simply be set to zero. -- Oskar Sandberg oskar at freenetproject.org _______________________________________________ Devl mailing list Devl at freenetproject.org http://lists.freenetproject.org/mailman/listinfo/devl
