New -limitgetblock option to limit max number of blocks returned in getblocks #3889

hno commented at 10:36 PM on March 16, 2014: none

primarily for slow connections to throttle blockchain transmissions which otherwise easily chokes the whole connection.

rebroad commented at 6:50 AM on March 17, 2014: contributor

I think there is more than one change here, since you're also changing the default from 500 to 200. How about a separate pull for that? (although, rather than change the default to a fixed number, I think it would make more sense that this adapts based upon the block sizes - for example, the earlier blocks were very small, and so 500 was a suitable number to request in one go).

laanwj commented at 7:38 AM on March 17, 2014: member

I'm fine with adding an option but don't change the default.

in src/init.cpp:None in a027010266 outdated

 474 | @@ -474,6 +475,9 @@ bool AppInit2(boost::thread_group& threadGroup)
 475 |      if (nFD - MIN_CORE_FILEDESCRIPTORS < nMaxConnections)
 476 |          nMaxConnections = nFD - MIN_CORE_FILEDESCRIPTORS;
 477 |  
 478 | +    // Limit number of blocks that may be requested in one go.
 479 | +    nMaxGetBlock = GetArg("-limitgetblock", 200);

laanwj commented at 7:39 AM on March 17, 2014:

Please document the new option in init.cpp as well.

hno commented at 1:20 AM on March 21, 2014: none

It was not my intention to change default in this pull request.

New -limitgetblock option to limit max number of blocks returned in getblocks

primarily for slow connections to throttle blockchain transmissions which
otherwise easily chokes the whole connection.

73d18bcb46

BitcoinPullTester commented at 2:34 AM on March 21, 2014: none

Automatic sanity-testing: PASSED, see http://jenkins.bluematt.me/pull-tester/73d18bcb46c10323405faafedf3420ebeb5d9316 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.

laanwj commented at 8:58 AM on March 31, 2014: member

~~ACK~~

sipa commented at 9:24 AM on March 31, 2014: member

Unsure about this.

Right now, any throttling solution will just hurt the one downloading from you, and I doubt you'll notice the difference (that's a guess; I would like to hear evidence otherwise). We already break during the actual sending of block data when the output buffer is full.

Once we have actual parallel downloading and smarter selection of peers, throttling won't hurt peers as much anymore, as they can switch to faster ones. When that is the case, an actual -throttleupload option or something seems fine to me, and far superior to this.

Also, this option will lose its meaning when headers-first is implemented, as it will use getheaders instead of getblocks.

laanwj commented at 9:39 AM on March 31, 2014: member

Good point @sipa. I was somehow under the wrong impression that this limited the number of blocks in outgoing requests, but as it affects incoming requests I have to take back my ACK as well.

hno commented at 9:02 AM on April 15, 2014: none

The purpose of this was to throttle the ones downloading from you.

It was tested successfully on a slow Internet connection. Without limiting to a smaller size the peers requesting chain download easily overloaded the connection. With limiting the bandwidth usage was under control and it could continue to service both bitcoin and other uses.

hno commented at 9:24 AM on April 15, 2014: none

@sipa, understood. Will propose a entirely different patch shortly, using the TCP buffer instead.

hno closed this on Apr 15, 2014

sipa commented at 10:09 AM on April 15, 2014: member

@hno You may have misunderstood me. As long as we don't have parallel block downloading, I think that any throttling of peers downloading from you hurts both more than it helps.

As it's unclear when we'll have parallel downloading, maybe a temporarily solution is detecting when you're over some user-configurable limit, and after that stop serving blocks to new peers (i.e., just disconnect them, so you lose the bandwidth, and they can go find a better peer to download from).

DrahtBot locked this on Sep 8, 2021