The timeout interval for the send and recv buffers was changed from 90 minutes to 20 minutes in commit f1920e86 in 2013, except for peers that did not support the pong message (where the recv buffer timeout remained at 90 minutes). A few observations:
- for peers that support BIP 31 (pong messages), this recv buffer timeout is almost redundant with the ping timeout. We send a ping message every two minutes, and set a timeout of twenty minutes to receive the pong response. If the recv buffer was really timing out, then the pong response would also time out.
- BIP 31 is supported by all nodes of p2p version 60000 and higher, and has been in widespread use since 2013. I’d be very surprised if there are many nodes on the network that don’t support pong messages.
- The recv buffer timeout is not specified in any p2p BIP. We’re free to set it at any value we want.
- A peer that doesn’t support BIP 31 and hasn’t sent any message to us at all in 90 minutes is unlikely to be useful for us, and is more likely to be evicted AttemptToEvictConnection() since it’ll have the worst possible ping time and isn’t providing blocks/transactions.
Therefore, we remove this check, and set the recv buffer timeout to 20 minutes for all peers. This removes the final p2p version dependent logic from the net layer, so all p2p version data can move into the net_processing layer.
Alternative approaches:
- Set the recv buffer timeout to 90 minutes for all peers. This almost wouldn’t be a behaviour change at all (pre-BIP 31 peers would still have the same recv buffer timeout, and we can’t ever reach a recv buffer timeout higher than 21 minutes for post-BIP31 peers, because the pong timeout would be hit first).
- Stop supporting peers that don’t support BIP 31. BIP 31 has been in use since 2012, and implementing it is trivial.
