diff options
author | furszy <matiasfurszyfer@protonmail.com> | 2023-12-19 09:50:37 -0300 |
---|---|---|
committer | furszy <matiasfurszyfer@protonmail.com> | 2024-01-15 10:28:20 -0300 |
commit | 9f36e591c551ec2e58a6496334541bfdae8fdfe5 (patch) | |
tree | aac5d45e617133f5caa8db9f9dec5ea6b45af0cc /src/protocol.h | |
parent | f9ac96b8d6f4eba23c88f302b22a2c676e351263 (diff) |
net: move state dependent peer services flags
No behavior change. Just an intermediate refactoring.
By relocating the peer desirable services flags into the peer
manager, we allow the connections acceptance process to handle
post-IBD potential stalling scenarios.
In the follow-up commit(s), the desirable service flags will be
dynamically adjusted to detect post-IBD stalling scenarios (such
as a +48-hour inactive node that must prefer full node connections
instead of limited peer connections because they cannot provide
historical blocks). Additionally, this encapsulation enable us
to customize the connections decision-making process based on
new user's configurations in the future.
Diffstat (limited to 'src/protocol.h')
-rw-r--r-- | src/protocol.h | 34 |
1 files changed, 1 insertions, 33 deletions
diff --git a/src/protocol.h b/src/protocol.h index a3c472d098..e19560e33b 100644 --- a/src/protocol.h +++ b/src/protocol.h @@ -311,29 +311,6 @@ enum ServiceFlags : uint64_t { std::vector<std::string> serviceFlagsToStr(uint64_t flags); /** - * Gets the set of service flags which are "desirable" for a given peer. - * - * These are the flags which are required for a peer to support for them - * to be "interesting" to us, ie for us to wish to use one of our few - * outbound connection slots for or for us to wish to prioritize keeping - * their connection around. - * - * Relevant service flags may be peer- and state-specific in that the - * version of the peer may determine which flags are required (eg in the - * case of NODE_NETWORK_LIMITED where we seek out NODE_NETWORK peers - * unless they set NODE_NETWORK_LIMITED and we are out of IBD, in which - * case NODE_NETWORK_LIMITED suffices). - * - * Thus, generally, avoid calling with peerServices == NODE_NONE, unless - * state-specific flags must absolutely be avoided. When called with - * peerServices == NODE_NONE, the returned desirable service flags are - * guaranteed to not change dependent on state - ie they are suitable for - * use when describing peers which we know to be desirable, but for which - * we do not have a confirmed set of service flags. - */ -ServiceFlags GetDesirableServiceFlags(ServiceFlags services); - -/** * State independent service flags. * If the return value is changed, contrib/seeds/makeseeds.py * should be updated appropriately to filter for nodes with @@ -343,16 +320,7 @@ constexpr ServiceFlags SeedsServiceFlags() { return ServiceFlags(NODE_NETWORK | /** Set the current IBD status in order to figure out the desirable service flags */ void SetServiceFlagsIBDCache(bool status); - -/** - * A shortcut for (services & GetDesirableServiceFlags(services)) - * == GetDesirableServiceFlags(services), ie determines whether the given - * set of service flags are sufficient for a peer to be "relevant". - */ -static inline bool HasAllDesirableServiceFlags(ServiceFlags services) -{ - return !(GetDesirableServiceFlags(services) & (~services)); -} +bool GetServicesFlagsIBDCache(); /** * Checks if a peer with the given service flags may be capable of having a |