backport: Merge bitcoin#22423, 22096 #5884
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
vijaydasmp
changed the title
vijaydasmp
force-pushed
the
bp23_2
branch
7 times, most recently
from
f71025e
to
e17634c
Compare
vijaydasmp
changed the title
|
Hello @UdjinM6 @knst @PastaPastaPasta requesting review |
UdjinM6
requested changes
May 23, 2024
knst
reviewed
May 25, 2024
| @@ -0,0 +1,62 @@ | |||
| #!/usr/bin/env python3 | |||
There was a problem hiding this comment.
Consider to backport bitcoin#22568 in a follow-up PR. There are no any important/critical fix, just tests improvements, so, that's an out-of-scope of current PR
knst
approved these changes
May 25, 2024
…cements 5730a43 test: Add functional test for AddrFetch connections (Martin Zumsande) c34ad33 net, rpc: Enable AddrFetch connections for functional testing (Martin Zumsande) 533500d p2p: Add timeout for AddrFetch peers (Martin Zumsande) b6c5d1e p2p: AddrFetch - don't disconnect on self-announcements (Martin Zumsande) Pull request description: AddrFetch connections (old name: oneshots) are intended to be short-lived connections on which we ask a peer for addresses via `getaddr` and disconnect after receiving them. This is done by disconnecting after receiving the first `addr`. However, it is no longer working as intended, because nowadays, the first `addr` a typical bitcoin core node sends is its self-announcement. So we'll disconnect before the peer gets a chance to answer our `getaddr`. I checked that this affects both `-seednode` peers specified manually, and DNS seeds when AddrFetch is used as a fallback if DNS doesn't work for us. The current behavior of getting peers via AddrFetch when starting with an empty addrman would be to connect to the peer, receive its self-announcement and add it to addrman, disconnect, reconnect to the same peer again as a full outbound (no other addresses in addrman) and then receive more `addr`. This is silly and not in line with AddrFetch peer being intended to be short-lived peers. Fix this by only disconnecting after receiving an `addr` message of size > 1. [Edit] As per review discussion, this PR now also adds a timeout after which we disconnect if we haven't received any suitable `addr`, and a functional test. ACKs for top commit: amitiuttarwar: reACK 5730a43 naumenkogs: ACK 5730a43 jnewbery: ACK 5730a43 Tree-SHA512: 8a81234f37e827705138eb254223f7f3b3bf44a06cb02126fc7990b0d231b9bd8f07d38d185cc30d55bf35548a6fdc286b69602498d875b937e7c58332158bf9
|
22423 was already merged in #6021 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
bitcoin backports