Message that contains the list of accepted block/vertex IDs in response to
“get_accepted”. For instance, on receiving “get_accepted” that contains
the sender’s accepted frontier IDs, the X-chain engine responds only with
the accepted vertex IDs of the X-chain DAG.
Message that contains the list of accepted frontier in response to
“get_accepted_frontier”. For instance, on receiving “get_accepted_frontier”,
the X-chain engine responds with the accepted frontier of X-chain DAG.
Message to request for the accepted blocks/vertices of the “remote” peer.
The local node sends out this message during bootstrap, following “get_accepted_frontier”.
Basically, sending the list of the accepted frontier and expects the response of
the accepted IDs from the remote peer.
Message to request for the accepted frontier of the “remote” peer.
For instance, the accepted frontier of X-chain DAG is the set of
accepted vertices that do not have any accepted descendants (i.e., frontier).
Message that requests for the ancestors (parents) of the specified container ID.
The engine bootstrapper sends this message to fetch all accepted containers
in its transitive path.
Message that contains a list of peer information (IP, certs, etc.)
in response to “version” message, and sent periodically to a set of
validators.
ref. “avalanchego/network/network#Dispatch.runtTimers”
Message that contains a preferred container ID to query other peers
for their preferences of the container.
For example, when a new container is issued, the engine sends out
“push_query” and “pull_query” queries to ask other peers their preferences.
See “avalanchego/snow/engine/common#SendMixedQuery”.
Message that contains a preferred container ID and its container bytes
in order to query other peers for their preferences of the container.
For example, when a new container is issued, the engine sends out
“push_query” and “pull_query” queries to ask other peers their preferences.
See “avalanchego/snow/engine/common#SendMixedQuery”.
The first outbound message that the local node sends to its remote peer
when the connection is established. In order for the local node to be
tracked as a valid peer by the remote peer, the fields must be valid.
For instance, the network ID must be matched and timestamp should be in-sync.
Otherwise, the remote peer closes the connection.
ref. “avalanchego/network/peer#handleVersion”
ref. https://pkg.go.dev/github.com/ava-labs/avalanchego/network#Network “Dispatch”