add Option for outgoing connection parameter #3709

pull Delta1977 wants to merge 1 commits into bitcoin:master from Delta1977:master changing 3 files +8 −4

Delta1977 commented at 10:12 PM on February 19, 2014: contributor

Change from fixed 8 Outgoing Connections in net.cpp to a value set with parameter
add Option for outgoing connection parameter 08406218b2
gmaxwell commented at 10:14 PM on February 19, 2014: contributor

NAK. If someone wants more connections they can enable inbound instead of abusing network resources. If they want fewer we already have max connections.
Delta1977 commented at 10:20 PM on February 19, 2014: contributor

sometime its heavy to got more inbound connections. eeg'with nonstatic IP / Lines. Every time on reconnect you go back to 8 connection.
int03h commented at 10:21 PM on February 19, 2014: none

oddly enough I did this last night based on http://roland.beyondweb.net/ .. I had the pleasure of exceeding my monthly limit with Comcast last night as I managed to create 50GB of traffic for myself. If I have any vote here I too would not accept this pull. I went to 100. Maybe a little crazy ;) but it highlighted the behaviour. I changed it back to 8 this morning. :)
sipa commented at 10:25 PM on February 19, 2014: member

NAK. Available connectable peer slots are a limited resource, no need to waste it. 8 connections is plenty to get a stable connection to the network.
BitcoinPullTester commented at 10:37 PM on February 19, 2014: none

Automatic sanity-testing: PASSED, see http://jenkins.bluematt.me/pull-tester/08406218b29a071c6ecb7ff54bf0d3c82c9e2c70 for binaries and test log. This test script verifies pulls every time they are updated. It, however, dies sometimes and fails to test properly. If you are waiting on a test, please check timestamps to verify that the test.log is moving at http://jenkins.bluematt.me/pull-tester/current/ Contact BlueMatt on freenode if something looks broken.
Eveiv commented at 11:40 PM on February 19, 2014: none

@int03h

static const int MAX_OUTBOUND_CONNECTIONS = 800;

Oh man, please don't do that. There's no need, you're just bogging up the listening capacity for absolutely no reason. You're using up 100 nodes worth of listening sockets right there.
gmaxwell commented at 11:42 PM on February 19, 2014: contributor

Wow what an irresponsible patch (the linked one).
int03h commented at 11:45 PM on February 19, 2014: none

HEY ! Don't get all hormonal on me :) I take no credit for it ... found it while trolling https://blockchain.info/hub-nodes in an effort to establish reliable and fast nodes.
Eveiv commented at 11:51 PM on February 19, 2014: none

@int03h Using up the listening capacity of the network is neither fast nor reliable, you're just preventing new nodes from joining the network in any reasonable time frame. A "reliable" node is one that listens rather than making 800 abusive outgoing connections.

That list isn't even anywhere near decent information, it's just a list of the nodes blockchain.info has decided to hammer with connections. Logically that list just contains the first peer which relayed an inventory item to them, which will inevitably the one closest to them.
int03h commented at 11:52 PM on February 19, 2014: none

@Eveiv dood .. its not my node, I voted against this. its obviously bad. leave me alone.
Delta1977 commented at 7:12 AM on February 20, 2014: contributor

You are all right. I could change the request and build in a rate between outand Ins with a minimum of 1:12. So you can only increase out if you increase in. Or close the request, and whoever wants to can compile with hard-coded values.
laanwj commented at 8:24 AM on February 20, 2014: member

Consensus seems clear, closing.
laanwj closed this on Feb 20, 2014
DrahtBot locked this on Sep 8, 2021

Contributors