Incorporates review feedback in #22387.
Edit, could be considered separately: should a release note (or two) be added for 22.0? e.g. the new getpeerinfo fields in Updated RPCs and the rate-limiting itself in P2P and network changes.
Concept ACK
Will code-review tomorrow. At a first glance, most parts of the diff look straight-forward, the change in the rate-limiting logic (swapping the if conditions) needs probably most attention. To speed up review, adding links to each of the review comments in #22387 that are tackled in this PR could be a good idea.
(the AppVeyor CI build fail seems to be not caused by this PR's changes, by the way)
240 | @@ -241,14 +241,14 @@ struct Peer { 241 | std::atomic_bool m_wants_addrv2{false}; 242 | /** Whether this peer has already sent us a getaddr message. */ 243 | bool m_getaddr_recvd{false}; 244 | - /** Number of addr messages that can be processed from this peer. Start at 1 to 245 | + /** Number of addresses that can be processed from this peer. Start at 1 to
addresses the feedback here: https://github.com/bitcoin/bitcoin/pull/22387/files#r665882202
2824 | ++num_rate_limit;
2825 | continue;
2826 | }
2827 | + } else {
2828 | peer->m_addr_token_bucket -= 1.0;
2829 | }
2855 | - num_proc, 2856 | - num_rate_limit, 2857 | - pfrom.GetId(), 2858 | - fLogIPs ? ", peeraddr=" + pfrom.addr.ToString() : ""); 2859 | + LogPrint(BCLog::NET, "Received addr: %u addresses (%u processed, %u rate-limited) from peer=%d\n", 2860 | + vAddr.size(), num_proc, num_rate_limit, pfrom.GetId());
suggested here: https://github.com/bitcoin/bitcoin/pull/22387/files#r672414835
149 | @@ -150,6 +150,8 @@ static RPCHelpMan getpeerinfo() 150 | { 151 | {RPCResult::Type::NUM, "n", "The heights of blocks we're currently asking from this peer"}, 152 | }}, 153 | + {RPCResult::Type::NUM, "addr_processed", "The total number of addresses processed, excluding those dropped due to rate limiting"}, 154 | + {RPCResult::Type::NUM, "addr_rate_limited", "The total number of addresses dropped due to rate limiting"},
mentioned here: https://github.com/bitcoin/bitcoin/pull/22387/files#r672417898
300 | self.mocktime += 1000 301 | self.nodes[0].setmocktime(self.mocktime) 302 | peer.increment_tokens(100) 303 | 304 | - self.send_addrs_and_test_rate_limiting(peer, no_relay, 200, 1610) 305 | + self.send_addrs_and_test_rate_limiting(peer, no_relay, new_addrs=200, total_addrs=1610)
review feedback here: https://github.com/bitcoin/bitcoin/pull/22387/files#r671144448
Concept ACK
Concept ACK
Nice fixups! Looks like there's essentially only one functional change here with if (rate_limited) {....
review ACK b7c4b058ba2625a39666636253620bc08a41c501
Thanks!
Also reset appveyor run.
Looks like there's essentially only one functional change here with if (rate_limited) {....
I think it still counts as refactoring because the change shouldn't be observable by a user
<!--e57a25ab6845829454e8d69fc972939a-->
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.
<!--174a7506f384e20aa4161008e828411d-->
No conflicts as of last run.
Code-review ACK b7c4b058ba2625a39666636253620bc08a41c501
Rebased per git range-diff 2b06af1 b7c4b05 d930c7f
re-ACK d930c7f5b091687eb4208a5ffe8a2abe311d8054 🌮
Checked via git range-diff b7c4b058...d930c7f5 that the changes since my last ACK were only rebase-related.
review ACK d930c7f5b091687eb4208a5ffe8a2abe311d8054
crACK d930c7f
LGTM 🧉