-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tavin Cole <tcole at espnow.com> writes:
> 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). > Fair enough. I was just looking at the connection problem as a slot/tab imbalance, and increasing the number of slots while decreasing the number of tabs seems to be a good solution. > 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 just worry about a node recieving hella requests in a short time and not being able to route out because it can't make enough outgoing connections. I like having the incoming connections being a bit more than outgoing, but still allowing for (what should be) plenty of outgoing connections. > 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. > > -- > > :: tavin cole (tcole at espnow.com) :: I agree that the idle timeout should be decreased. I disagree with your analysis of the 0.3 network. The 0.3 network worked because there was no pre-requisite for contacting a node (like knowing its key is in 0.4), so you could contact nodes willy-nilly and you'd always connect. Now there's the problem of nodes changing identities and a host of other connection errors that can occur. - -- E-mail: thelema314 at bigfoot.com Raabu and Piisu GPG 1024D/36352AAB fpr:756D F615 B4F3 BFFC 02C7 84B7 D8D7 6ECE 3635 2AAB -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.6 and Gnu Privacy Guard <http://www.gnupg.org/> iD8DBQE8L/6R2NduzjY1KqsRAndVAJ9klb67jY8jJBLoLoJ6wATKQ3e6mwCgqQ1j c9FdMuNO+ibvyFv1rTSRIi8= =S1am -----END PGP SIGNATURE----- _______________________________________________ Devl mailing list Devl at freenetproject.org http://lists.freenetproject.org/mailman/listinfo/devl
