Skip to content

Conversation

ajtowns
Copy link
Contributor

@ajtowns ajtowns commented Oct 19, 2023

Move per-peer code from net into a new node/connection module. This is intended to capture logic that is lower-level than the p2p protocol (done in net_processing), but higher-level than raw bits-over-the-wire (handled by Sock).

@DrahtBot
Copy link
Contributor

DrahtBot commented Oct 19, 2023

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

Code Coverage

For detailed information about the code coverage, see the test coverage report.

Reviews

See the guideline for information on the review process.

Type Reviewers
ACK naumenkogs

If your review is incorrectly listed, please react with 👎 to this comment and the bot will ignore it on the next update.

Conflicts

Reviewers, this pull request conflicts with the following ones:

  • #28857 (test, refactor: Magic bytes array followup by TheCharlatan)
  • #28690 (build: Introduce internal kernel library by TheCharlatan)
  • #28455 (refactor: share and use GenerateRandomKey helper by theStack)
  • #28451 (refactor: Remove unused SER_DISK, SER_NETWORK, SER_GETHASH by maflcko)
  • #27600 (net: Add new permission forceinbound to evict a random unprotected connection if all slots are otherwise full by pinheadmz)
  • #27114 (p2p: Allow whitelisting outgoing connections by brunoerg)
  • #26697 (logging: use bitset for categories by LarryRuane)
  • #25832 (tracing: network connection tracepoints by 0xB10C)

If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.

@ajtowns
Copy link
Contributor Author

ajtowns commented Oct 19, 2023

The idea here is to restructure CNode / CConnman / PeerManager a bit. Currently, net.h combines all the p2p logic in between the very low-level socket stuff (sock.h) and the high-level protocol (net_processing.h). This splits that into two parts: node/node.h that now contains CNode, TransportV1, etc that focusses on dealing with a single peer; and leaves CConnman in net.h, with the idea that that focusses on coordinating amongst the many peers we have (so, opening new connections, choosing what to evict, working out which node to give cpu time to next, etc).

This PR just moves code around; the idea is that future PRs would improve the separation more (see https://github.com/ajtowns/bitcoin/commits/202308-netnode and #28252 (comment)) and, eventually, breaking the circular dependency between PeerManager and CConnman (ie, have PeerManager only deal with a single node at a time, eg see the PushMessage changes in the repo just mentioned).

@maflcko
Copy link
Member

maflcko commented Oct 19, 2023

node/node seems a bit confusing, because the two node refer to different things. node refers to this node and the other node refers to a peer, so node/peer may be better?

@ajtowns
Copy link
Contributor Author

ajtowns commented Oct 19, 2023

node/node seems a bit confusing, because the two node refer to different things. node refers to this node and the other node refers to a peer, so node/peer may be better?

I did think about that, but it's confusing in its own way: we have class Peer in net_processing that contains the per-peer protocol-level data for a particular connection. I guess we could decide to move towards calling them Peer (instead of CNode) and PeerLogic (instead of Peer), and PeerLogicManager (instead of PeerManager)?

@dergoegge
Copy link
Member

While we are bike-shedding the naming, I actually think node/connection would make sense. Connection would also seem like the appropriate name for CNode given that it is managed by something called connection manager.

@ajtowns
Copy link
Contributor Author

ajtowns commented Oct 19, 2023

While we are bike-shedding the naming, I actually think node/connection would make sense. Connection would also seem like the appropriate name for CNode given that it is managed by something called connection manager.

I like it! Done.

@ajtowns ajtowns changed the title refactor: Split per-peer parts of net module into new node/node module refactor: Split per-peer parts of net module into new node/connection module Oct 19, 2023
virtual bool ShouldReconnectV1() const noexcept = 0;
};

class V1Transport final : public Transport
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What do you think of moving the transport impls to net.cpp (or their own module)?. They aren't really part of this interface, more of a implementation detail.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The class info is exposed for unit tests, and you at least need class Transport in order to know what a CNode looks like. Separating out the V1/V2 implementation details alone doesn't seem like much of a win. (And wouldn't really be a win at all if we just had a concrete Transport class instead of the replaceable virtual setup, cf #28331 (comment))

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(The Transport stuff is all specific to a single connection, so it would go in node/connection.cpp rather than net.cpp per the logic of this PR)

Move per-peer code from net into a new node/connection module. This
is intended to capture logic that is lower-level than the p2p protocol
(done in net_processing), but higher-level than raw bits-over-the-wire
(handled by Sock).
@naumenkogs
Copy link
Member

Concept ACK. Good thing this separation doesn't require additional wrappers and fields.

@naumenkogs
Copy link
Member

ACK fb03ca1

@DrahtBot
Copy link
Contributor

🐙 This pull request conflicts with the target branch and needs rebase.

@maflcko
Copy link
Member

maflcko commented Nov 28, 2023

Are you still working on this?

@ajtowns
Copy link
Contributor Author

ajtowns commented Nov 28, 2023

Closing as up-for-grabs (will grab it myself in a while if no one else does first)

@ajtowns ajtowns closed this Nov 28, 2023
@bitcoin bitcoin locked and limited conversation to collaborators Nov 27, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants