getblocktemplate: longpolling support #2834

1. 
   luke-jr commented at 2:24 am on July 17, 2013: member

   Resubmission of #1355, since GitHub closed it on me.

   I have rebased it and addressed both of @jeremysawicki’s concerns:

   • Shutdown now disconnects all longpoll sessions with an error.
   • Longpolling now mimicks the behaviour of BitcoinMiner by returning a new template after a minute has passed and there are new transactions.

   These changes were not exactly trivial, so re-review of the code is probably necessary.

2. 
   gmaxwell commented at 7:58 pm on July 18, 2013: contributor

   Any ideas on how this could be usefully automatically tested?
3. 
   luke-jr commented at 3:28 am on July 19, 2013: member

   • Fetch a template with getblocktemplate()
   • Spawn a second thread which simulates a new block on the network after 5 seconds
   • Time a request to getblocktemplate with longpollid set to the value provided by previous reply
   • Ensure time is within 4-6 seconds.
   • Spawn a second thread which increments the “new transactions counter” after 5 seconds
   • Time a request to getblocktemplate with longpollid set to the value provided by previous reply
   • Ensure time is within 59-61 seconds.
   • Spawn a second thread which increments the “new transactions counter” after 65 seconds
   • Spawn a third thread which requests a new template (no longpollid) after 5 seconds, and ensure it returns immediately (to check longpoll doesn’t block RPC completely)
   • Time a request to getblocktemplate with longpollid set to the value provided by previous reply
   • Ensure time is within 64-121 seconds.
4. 
   yhaenggi commented at 6:56 am on August 7, 2013: none

   @luke-jr how about making changes so you can specify after which time X you get a new template?
5. 
   luke-jr commented at 7:30 am on August 7, 2013: member

   @K1773R That might make sense for a future pull request.
6. 
   jgarzik commented at 2:50 am on August 25, 2013: contributor

   Quick review seems OK… wants testing and additional review at a minimum
7. 
   gavinandresen commented at 2:03 am on October 21, 2013: contributor

   Rebase needed.
8. 
   luke-jr commented at 5:13 pm on February 21, 2014: member

   Rebased again
9. 
   CodeShark commented at 9:50 pm on March 11, 2014: contributor

   I’ve been testing this for the last couple days with BFGMiner, been having a problem with keep-alive.

   Basically, when a new block template becomes available, it’s sending it to BFGMiner which is then making a new request using a new connection while keeping the old connection open, so eventually we run out of RPC threads on the server.

   For now, I’ve just passed false as the third parameter to HTTPReply when flushing the stream in rpcserver.cpp: ServiceConnection(). This forces the earlier connections to close.

10. 
    luke-jr commented at 2:28 pm on June 26, 2014: member

    Rebased. @CodeShark Your experience sounds like a general limitation of the RPC server, not really related to this function itself. I agree BFGMiner could be improved to try to minimise connection count, but that’s an issue for BFGMiner.
11. getblocktemplate: longpolling support 01c8af13ae
12. 
    BitcoinPullTester commented at 8:05 pm on July 7, 2014: none

    Automatic sanity-testing: PASSED, see http://jenkins.bluematt.me/pull-tester/p2834_01c8af13ae65d314bb8cbef7cd51132ad93da294/ 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.
13. 
    laanwj commented at 9:07 am on July 10, 2014: member

    Closing in favor of #4503
14. laanwj closed this on Jul 10, 2014

    ---

15. Bushstar referenced this in commit 4af5ea8a7f on Apr 5, 2019
16. DrahtBot locked this on Sep 8, 2021

Contributors
luke-jr gmaxwell yhaenggi jgarzik gavinandresen CodeShark BitcoinPullTester laanwj