Introduce block download timeout #5608

1. 
   sipa commented at 4:07 PM on January 6, 2015: member

   This is a simpler alternative to #5463, in order to solve #5588.

   Disconnect peers which take longer than block interval time to download a block from, with extra time given in case the block was requested with existing parallel downloads queued.

2. sipa force-pushed on Jan 6, 2015
3. sipa renamed this:
   Introduce 10 minute block download timeout
   Introduce block download timeout
   on Jan 6, 2015
4. 
   sipa commented at 4:30 PM on January 6, 2015: member

   Made the behaviour a bit less aggressive after discussing with @ajweiss on IRC.

5. sipa force-pushed on Jan 6, 2015
6. sipa force-pushed on Jan 6, 2015
7. laanwj added this to the milestone 0.10.0 on Jan 6, 2015
8. Introduce 10 minute block download timeout

   This will disconnect peers that do not transfer a block in 10 minutes, plus
   5 minutes for every previously queued block with validated headers
   (accomodating downstream bandwidth down to a few kilobytes per second - below
   that the node would have trouble staying synchronized anyway).

   916130348c
9. in src/main.cpp:None in a6a1a96ac9 outdated

   4528 | @@ -4522,6 +4529,10 @@ bool SendMessages(CNode* pto, bool fSendTrickle)
   4529 |              LogPrintf("Peer=%d is stalling block download, disconnecting\n", pto->id);
   4530 |              pto->fDisconnect = true;
   4531 |          }
   4532 | +        if (!pto->fDisconnect && state.vBlocksInFlight.size() > 0 && state.vBlocksInFlight.front().nTime < nNow - 500000 * Params().TargetSpacing() * (2 + state.vBlocksInFlight.front().nValidatedQueuedBefore)) {
   

   ---

   ---

   

   laanwj commented at 4:02 PM on January 7, 2015:

   This (complicated) conditional expression needs a comment on what the intent is

10. sipa force-pushed on Jan 7, 2015
11. 
    sipa commented at 4:09 PM on January 7, 2015: member

    Added a comment.

12. in src/main.cpp:None in 916130348c

    4533 | @@ -4527,6 +4534,15 @@ bool SendMessages(CNode* pto, bool fSendTrickle)
    4534 |              LogPrintf("Peer=%d is stalling block download, disconnecting\n", pto->id);
    4535 |              pto->fDisconnect = true;
    4536 |          }
    4537 | +        // In case there is a block that has been in flight from this peer for (1 + 0.5 * N) times the block interval
    

    ---

    ---

    

    laanwj commented at 9:20 AM on January 8, 2015:

    Nice, utACK

13. laanwj added the label P2P on Jan 8, 2015
14. 
    ajweiss commented at 3:47 PM on January 8, 2015: contributor

    I've been playing with this and it looks good to me for a short term fix, subject to the limitations discussed on IRC on 1/7 with respect to backoffs and ping timeouts being triggered at the hard 20m limit when ping replies get stuck behind a bunch of slow moving blocks. Ran a full sync and several catch-ups from -7d with no issues. Also verified that clients are indeed disconnected.

15. laanwj merged this on Jan 12, 2015
16. laanwj closed this on Jan 12, 2015

    ---

17. laanwj referenced this in commit de8b9ab757 on Jan 12, 2015
18. sipa referenced this in commit a3a73170a9 on Jan 12, 2015
19. 
    dgenr8 commented at 7:25 PM on January 12, 2015: contributor

    Post-armageddon, will this disconnect my last satellite block source for being too slow?

20. 
    gmaxwell commented at 7:59 PM on January 12, 2015: contributor

    yup. But you were doomed by the zombies before that point anyways. (more seriously: you're guaranteed to fall behind: better to see no connections than to think you're up to date)

21. reddink referenced this in commit 2ea6cdde9c on Jul 11, 2020
22. reddink referenced this in commit 271a5f5097 on Jul 14, 2020
23. MarcoFalke locked this on Sep 8, 2021

Contributors

sipalaanwjajweissdgenr8gmaxwell

Milestone
0.10.0