Instead of killing a connection when the receive buffer overflows, just temporarily halt receiving before that happens. Also, no matter what, always allow at least one full message in the receive buffer (otherwise blocks larger than the configured buffer size would pause indefinitely).
Fixes #2597.
Tested with -maxreceivebuffer=3 (yes, that means 3 kilobytes).
It seems like this creates a remotely trigger-able state, whereby someone would not be selected for read or write, yet the socket and CNode would remain, using system resources.
It seems the current code actually has a minor bug, as it means not setting have_fds / hSocketMax if the lock on cs_vSend cannot be acquired.
I restructured the flow a bit, so now send and recv locks are both tried separately, and only as long as necessary.
I also added some comment explaining the reasoning and why it cannot cause a deadlock.
Instead of killing a connection when the receive buffer overflows,
just temporarily halt receiving before that happens. Also, no
matter what, always allow at least one full message in the receive
buffer (otherwise blocks larger than the configured buffer size
would pause indefinitely).
Automatic sanity-testing: PASSED, see http://jenkins.bluematt.me/pull-tester/a9d9f0f5f72ab1f9ebc2f76bfe3b7921fa2826d7 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.
ACK.
ACK (code looks ok, and tested downloading the testnet block chain using a very small receive buffer)
ACK