Networking code for Zebra. 🦓
The Zcash network protocol is inherited from Bitcoin, which uses a stateful network protocol in which messages can arrive in any order (even before a handshake is complete!), and the same message may be a request or a response depending on context.
This crate translates the legacy Bitcoin/Zcash network protocol
into a stateless, request-response oriented protocol defined by
Response enums, and completely
encapsulates all peer handling code behind a single
tower::Service representing "the network" which load-balances
Requests over available peers.
Unlike the underlying legacy network protocol the provided
tower::Service guarantees that each
Request future will resolve to
Response, not a potentially random unrelated
Each peer connection is a distinct task, which interprets incoming
Bitcoin/Zcash messages either as
Responses to pending
Requests, or as an inbound
Requests to an internal
tower::Service representing "this node". All connection state
is isolated to the peer in question, so as a side effect the
design is structurally immune to the recent
tower::Services provide backpressure information, we
can dynamically manage the size of the connection pool according
to inbound and outbound demand. The inbound service can shed load
when it is not ready for requests, causing those peer connections
to close, and the outbound service can connect to additional peers
when it is overloaded.
Definitions of constants.
A database of peers, their advertised services, and information on when they were last seen.
Configuration for networking code.
A very basic retry policy that always retries failed requests.
A very basic retry policy with a limited number of retry attempts.
A network request, represented in internal format.
A response to a network request, represented in internal format.
Use the provided TCP connection to create a Zcash connection completely isolated from all other node state.
Initialize a peer set.
Type alias to make working with tower traits easier.