Steady state block download timeouts #5463

1. 
   ajweiss commented at 9:05 pm on December 11, 2014: contributor

   Once we’re BLOCK_DOWNLOAD_WINDOW (1024) blocks from a peer’s tip, stalled peer detection for IBD finishes. Add a 2x block interval (20m) download timeout that will only trigger when we’re at this stage and another peer is not transferring any blocks (a heuristic for whether or not we’re in a busy download state where we’re starved for bandwidth). In the event of a timeout trigger, re-request blocks elsewhere and apply a small ban penalty.

   This prevents lame or malicious peers from stalling synchronization either during the final synchronization stage or during steady state block relays.

2. Steady state block download timeouts

   Once we're BLOCK_DOWNLOAD_WINDOW (1024) blocks from a peer's tip,
   stalled peer detection for IBD finishes.  Add a 2x block interval (20m)
   download timeout that will only trigger when we're at this stage and
   another peer is not transferring any blocks (a heuristic for whether or
   not we're in a busy download state where we're starved for bandwidth).
   In the event of a timeout trigger, re-request blocks elsewhere and apply
   a small ban penalty.
   
   This prevents lame or malicious peers from stalling synchronization
   either during the final synchronization stage or during steady state
   block relays.

   8db8a91cb6
3. laanwj added the label P2P on Dec 12, 2014
4. in src/main.cpp: in 8db8a91cb6

   345+    if (itInFlight->second.second->nTime < nTimeout &&
   346+        itInFlight->second.first != newnode)
   347+    {
   348+        LogPrintf("Peer=%d failed to transfer block %s in twice the expected block interval, requesting elsewhere...\n",
   349+                  itInFlight->second.first, hash.ToString());
   350+        Misbehaving(itInFlight->second.first, 10);
   

   ---

   ---

   

   sipa commented at 2:40 pm on January 4, 2015:

   I think we want to disconnect such a node (but without raising banning score highly) immediately, to avoid having them think we still want the block (as there is no way to cancel a download request).
5. 
   sipa commented at 3:05 pm on January 4, 2015: member

   I think this approach will work, but it is easier and more obviously correct to just disconnect peers that have a very old outstanding request. The normal parallel block fetching mechanism should then request it in from other peers.
6. 
   ajweiss commented at 5:13 pm on January 6, 2015: contributor

   Closed in favor of #5608
7. ajweiss closed this on Jan 6, 2015

   ---

8. MarcoFalke locked this on Sep 8, 2021

Contributors
ajweiss sipa

Labels
P2P