diff options
author | Anthony Towns <aj@erisian.com.au> | 2023-05-08 17:14:53 +1000 |
---|---|---|
committer | fanquake <fanquake@gmail.com> | 2023-05-11 14:24:19 +0100 |
commit | 128da6e41fc2acc5bd1f4e2bddf2953f2fa62a68 (patch) | |
tree | e880b8785dcc67a31954ac1d633327ec83b06a29 | |
parent | a9a861af2b4b1c0a17b8abda34cb741170e12d7d (diff) |
net_processing: Boost inv trickle rate
If transactions are being added to the mempool at a rate faster than 7tx/s
(INVENTORY_BROADCAST_PER_SECOND) then peers' inventory_to_send queue can
become relatively large. If this happens, increase the number of txids
we include in an INV message (normally capped at 35) by 5 for each 1000
txids in the queue.
This will tend to clear a temporary excess out reasonably quickly; an
excess of 4000 invs to send will be cleared down to 1000 in about 30
minutes, while an excess of 20000 invs would be cleared down to 1000 in
about 60 minutes.
Github-Pull: #27610
Rebased-From: 5b3406094f2679dfb3763de4414257268565b943
-rw-r--r-- | src/net_processing.cpp | 4 |
1 files changed, 3 insertions, 1 deletions
diff --git a/src/net_processing.cpp b/src/net_processing.cpp index 6de5ed1c00..7954dbf912 100644 --- a/src/net_processing.cpp +++ b/src/net_processing.cpp @@ -5594,7 +5594,9 @@ bool PeerManagerImpl::SendMessages(CNode* pto) // especially since we have many peers and some will draw much shorter delays. unsigned int nRelayedTransactions = 0; LOCK(tx_relay->m_bloom_filter_mutex); - while (!vInvTx.empty() && nRelayedTransactions < INVENTORY_BROADCAST_MAX) { + size_t broadcast_max{INVENTORY_BROADCAST_MAX + (tx_relay->m_tx_inventory_to_send.size()/1000)*5}; + broadcast_max = std::min<size_t>(1000, broadcast_max); + while (!vInvTx.empty() && nRelayedTransactions < broadcast_max) { // Fetch the top element from the heap std::pop_heap(vInvTx.begin(), vInvTx.end(), compareInvMempoolOrder); std::set<uint256>::iterator it = vInvTx.back(); |