diff options
author | MarcoFalke <falke.marco@gmail.com> | 2020-12-16 20:29:26 +0100 |
---|---|---|
committer | MarcoFalke <falke.marco@gmail.com> | 2020-12-16 20:29:31 +0100 |
commit | ae9ee5bdb18c5babbfa2875ab694df118d6a1c1b (patch) | |
tree | 92251d5e6754f66990bfcdee9b7db8d51ccc0cfe /configure.ac | |
parent | 427f8c2cff0122bd614155f114b8b581e4b6e960 (diff) | |
parent | ea36a453e3d06657679459e1168347648fa7c5c0 (diff) | |
download | bitcoin-ae9ee5bdb18c5babbfa2875ab694df118d6a1c1b.tar.xz |
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
Diffstat (limited to 'configure.ac')
0 files changed, 0 insertions, 0 deletions