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
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());
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"},
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)
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
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.
No conflicts as of last run.
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.
crACK d930c7f
LGTM 🧉