nodes rely on other nodes to send a block inv before sending getblocks #4387

1. 
   rebroad commented at 2:14 am on June 22, 2014: contributor

   This assumption will fail if modified clients don’t send the block inv after the last block being sent.

   It is possible that a modified client may want to send only a limited number of blocks and not have the requesting node send more requests. In this case, the modified node will not send the inv of the next block to prompt the requesting node to send a further getblocks.

   A solution to this is to make nodes able to detect when the sending node has stopped sending blocks (e.g. a block isn’t being sent immediately after the last block was received). In this case, it can determine that the SyncNode is no longer a SyncNode and re-select a SyncNode to which to send the next getblocks.

2. 
   sipa commented at 12:08 pm on July 29, 2014: member

   The whole getblocks/inv/getdata/inv mechanism is a hack. In headersfirst we get rid of it entirely (doing a getheaders/headers exchange, and a another separate getdata/block exchange).
3. laanwj added the label P2P on Jul 31, 2014
4. rebroad closed this on Jun 13, 2015

   ---

5. DrahtBot locked this on Sep 8, 2021

Contributors
rebroad sipa

Labels
P2P