mirror of
https://github.com/bitcoin/bitcoin.git
synced 2025-11-11 22:50:59 +01:00
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.
This commit is contained in:
@@ -110,6 +110,29 @@ public:
|
||||
|
||||
/** This function is used for testing the stale tip eviction logic, see denialofservice_tests.cpp */
|
||||
virtual void UpdateLastBlockAnnounceTime(NodeId node, int64_t time_in_seconds) = 0;
|
||||
|
||||
/**
|
||||
* 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 'services' == NODE_NONE, unless
|
||||
* state-specific flags must absolutely be avoided. When called with
|
||||
* 'services' == 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.
|
||||
*/
|
||||
virtual ServiceFlags GetDesirableServiceFlags(ServiceFlags services) const = 0;
|
||||
};
|
||||
|
||||
#endif // BITCOIN_NET_PROCESSING_H
|
||||
|
||||
Reference in New Issue
Block a user