Merge #20651: net: Make p2p recv buffer timeout 20 minutes for all peers

ea36a453e3d06657679459e1168347648fa7c5c0 [net] Make p2p recv buffer timeout 20 minutes for all peers (John Newbery)

Pull request description:

  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.

ACKs for top commit:
  MarcoFalke:
    review ACK ea36a453e3d06657679459e1168347648fa7c5c0
  promag:
    Code review ACK ea36a453e3d06657679459e1168347648fa7c5c0.
  practicalswift:
    cr ACK ea36a453e3d06657679459e1168347648fa7c5c0: patch looks correct
  ajtowns:
    ACK ea36a453e3d06657679459e1168347648fa7c5c0
  sipa:
    utACK ea36a453e3d06657679459e1168347648fa7c5c0
  jonatack:
    Code review ACK ea36a453e3d06657679459e1168347648fa7c5c0

Tree-SHA512: df290bb32d2b5d9e59a0125bb215baa92787f9d01542a7437245f1c478c7f9b9831e5f170d3cd0db2811e1b11b857b3e8b2e03376476b8302148e480d81aab19

0 files changed, 0 insertions, 0 deletions