Please enable JavaScript.
Coggle requires JavaScript to display documents.
stellar-core overlay 思维导图 (StellarMessage (:star: Messages directed to or…
stellar-core overlay 思维导图
BanManager
Manages list of banned nodes.
FloodGate
FloodGate keeps track of which peers have sent us which broadcast messages, in order to ensure that for each broadcast message M and for each peer P, we either send M to P once (and only once), or receive M
from
P (thereby inhibit sending M to P at all).
The broadcast message types are
TRANSACTION
SCP_MESSAGE
All messages are marked with the ledger sequence number to which they relate, and all flood-management information for a given ledger number is purged from the FloodGate when the ledger closes.
ItemFetcher
The ItemFetcher keeps instances of the Tracker class. There exists exactly one Tracker per item. The tracker is used to maintain the state of the search.
LoadManager
This class monitors system load, and attempts to assign blame for the origin of load to particular peers, including the transactions we inject ourselves.
The purpose is ultimately to offer a diagnostic view of the peer when and if it's overloaded, as well as to support an automatic load-shedding action of disconnecting the "worst" peers and/or rejecting traffic due to load.
This is all very heuristic and speculative; if it turns out not to work, or to do more harm than good, it ought to be disabled/removed.
OverlayManager
maintains a virtual broadcast network, consisting of a set of remote TCP peers (TCPPeer), a mechanism for flooding messages to all peers (
FloodGate
(see
FloodGate
)), and a mechanism for sending and receiving anycast request/reply pairs (
ItemFetcher
(see
ItemFetcher
)).
Overlay network messages are defined as the XDR structure type
StellarMessage
(see
StellarMessage
), in the file src/xdr/Stellar-overlay.x
:pen:
The overlay subsystem manages a virtual "broadcast network" composed of a set of peer-to-peer TCP connections, as well as mechanisms for managing distribution of broadcast messages, anycast request/reply message pairs, and peer-to-peer control messages to and from those peers.
Within the local process, the overlay subsystem primarily delivers messages to, and accepts them from, the
Herder
, as well as propagating through the network any transactions injected from public API servers.
StellarMessage
:star: Messages directed to or from a specific peer, with or without a response:
HELLO
GET_PEERS
PEERS
DONT_HAVE
ERROR_MSG
:star: One-way broadcast messages informing other peers of an event:
TRANSACTION
SCP_MESSAGE
:star: Two-way anycast messages requesting a value (by hash) or providing it
GET_TX_SET
TX_SET
GET_SCP_QUORUMSET
SCP_QUORUMSET
GET_SCP_STATE
Anycast
[任播]
Anycasts are initiated and serviced two instances of
ItemFetcher
(see
ItemFetcher
) (mTxSetFetcher and mQuorumSetFetcher).
Anycast messages are sent to directly-connected peers, in sequence until satisfied. They are not flooded between peers.
Broadcast
[广播]
Broadcasts are initiated by the Herder and sent to both the Herder
and
the local
FloodGate
(see
FloodGate
), for propagation to other peers.