@@ -578,11 +578,6 @@ class CNode
578
578
assert (false );
579
579
}
580
580
581
- protected:
582
- mapMsgCmdSize mapSendBytesPerMsgCmd GUARDED_BY (cs_vSend);
583
- mapMsgCmdSize mapRecvBytesPerMsgCmd GUARDED_BY (cs_vRecv);
584
-
585
- public:
586
581
struct TxRelay {
587
582
mutable RecursiveMutex cs_filter;
588
583
// We use fRelayTxes for two purposes -
@@ -647,50 +642,6 @@ class CNode
647
642
CNode (const CNode&) = delete ;
648
643
CNode& operator =(const CNode&) = delete ;
649
644
650
- private:
651
- const NodeId id;
652
- const uint64_t nLocalHostNonce;
653
- const ConnectionType m_conn_type;
654
- std::atomic<int > m_greatest_common_version{INIT_PROTO_VERSION};
655
-
656
- // ! Services offered to this peer.
657
- // !
658
- // ! This is supplied by the parent CConnman during peer connection
659
- // ! (CConnman::ConnectNode()) from its attribute of the same name.
660
- // !
661
- // ! This is const because there is no protocol defined for renegotiating
662
- // ! services initially offered to a peer. The set of local services we
663
- // ! offer should not change after initialization.
664
- // !
665
- // ! An interesting example of this is NODE_NETWORK and initial block
666
- // ! download: a node which starts up from scratch doesn't have any blocks
667
- // ! to serve, but still advertises NODE_NETWORK because it will eventually
668
- // ! fulfill this role after IBD completes. P2P code is written in such a
669
- // ! way that it can gracefully handle peers who don't make good on their
670
- // ! service advertisements.
671
- const ServiceFlags nLocalServices;
672
-
673
- std::list<CNetMessage> vRecvMsg; // Used only by SocketHandler thread
674
-
675
- mutable RecursiveMutex cs_addrName;
676
- std::string addrName GUARDED_BY (cs_addrName);
677
-
678
- // Our address, as reported by the peer
679
- CService addrLocal GUARDED_BY (cs_addrLocal);
680
- mutable RecursiveMutex cs_addrLocal;
681
-
682
- // ! Whether this peer is an inbound onion, e.g. connected via our Tor onion service.
683
- const bool m_inbound_onion{false };
684
-
685
- // Challenge sent in VERSION to be answered with MNAUTH (only happens between MNs)
686
- mutable Mutex cs_mnauth;
687
- uint256 sentMNAuthChallenge GUARDED_BY (cs_mnauth);
688
- uint256 receivedMNAuthChallenge GUARDED_BY (cs_mnauth);
689
- uint256 verifiedProRegTxHash GUARDED_BY (cs_mnauth);
690
- uint256 verifiedPubKeyHash GUARDED_BY (cs_mnauth);
691
-
692
- public:
693
-
694
645
NodeId GetId () const {
695
646
return id;
696
647
}
@@ -835,6 +786,51 @@ class CNode
835
786
LOCK (cs_mnauth);
836
787
verifiedPubKeyHash = newVerifiedPubKeyHash;
837
788
}
789
+
790
+ private:
791
+ const NodeId id;
792
+ const uint64_t nLocalHostNonce;
793
+ const ConnectionType m_conn_type;
794
+ std::atomic<int > m_greatest_common_version{INIT_PROTO_VERSION};
795
+
796
+ // ! Services offered to this peer.
797
+ // !
798
+ // ! This is supplied by the parent CConnman during peer connection
799
+ // ! (CConnman::ConnectNode()) from its attribute of the same name.
800
+ // !
801
+ // ! This is const because there is no protocol defined for renegotiating
802
+ // ! services initially offered to a peer. The set of local services we
803
+ // ! offer should not change after initialization.
804
+ // !
805
+ // ! An interesting example of this is NODE_NETWORK and initial block
806
+ // ! download: a node which starts up from scratch doesn't have any blocks
807
+ // ! to serve, but still advertises NODE_NETWORK because it will eventually
808
+ // ! fulfill this role after IBD completes. P2P code is written in such a
809
+ // ! way that it can gracefully handle peers who don't make good on their
810
+ // ! service advertisements.
811
+ const ServiceFlags nLocalServices;
812
+
813
+ std::list<CNetMessage> vRecvMsg; // Used only by SocketHandler thread
814
+
815
+ mutable RecursiveMutex cs_addrName;
816
+ std::string addrName GUARDED_BY (cs_addrName);
817
+
818
+ // Our address, as reported by the peer
819
+ CService addrLocal GUARDED_BY (cs_addrLocal);
820
+ mutable RecursiveMutex cs_addrLocal;
821
+
822
+ // ! Whether this peer is an inbound onion, e.g. connected via our Tor onion service.
823
+ const bool m_inbound_onion{false };
824
+
825
+ // Challenge sent in VERSION to be answered with MNAUTH (only happens between MNs)
826
+ mutable Mutex cs_mnauth;
827
+ uint256 sentMNAuthChallenge GUARDED_BY (cs_mnauth);
828
+ uint256 receivedMNAuthChallenge GUARDED_BY (cs_mnauth);
829
+ uint256 verifiedProRegTxHash GUARDED_BY (cs_mnauth);
830
+ uint256 verifiedPubKeyHash GUARDED_BY (cs_mnauth);
831
+
832
+ mapMsgCmdSize mapSendBytesPerMsgCmd GUARDED_BY (cs_vSend);
833
+ mapMsgCmdSize mapRecvBytesPerMsgCmd GUARDED_BY (cs_vRecv);
838
834
};
839
835
840
836
/* *
0 commit comments