ouroboros-network-0.1.0.1: A networking layer for the Ouroboros blockchain protocol
Safe Haskell None
Language Haskell2010

Ouroboros.Network.BlockFetch.Client

Synopsis

Block fetch protocol client implementation

blockFetchClient :: forall header block m. ( MonadSTM m, MonadThrow m, MonadTime m, HasHeader header, HasHeader block, HeaderHash header ~ HeaderHash block) => NodeToNodeVersion -> ControlMessageSTM m -> FetchedMetricsTracer m -> FetchClientContext header block m -> PeerPipelined ( BlockFetch block ( Point block)) AsClient BFIdle m () Source #

The implementation of the client side of block fetch protocol designed to work in conjunction with our fetch logic.

type BlockFetchClient header block m a = FetchClientContext header block m -> PeerPipelined ( BlockFetch block ( Point block)) AsClient BFIdle m a Source #

TODO: use a fetch client wrapper type rather than the raw PeerPipelined, and eliminate this alias. It is only here to avoid large types leaking into the consensus layer.

data FetchClientContext header block m Source #

The context that is passed into the block fetch protocol client when it is started.

data TraceFetchClientState header Source #

Tracing types for the various events that change the state (i.e. FetchClientStateVars ) for a block fetch client.

Note that while these are all state changes, the AddedFetchRequest occurs in the decision thread while the other state changes occur in the block fetch client threads.

newtype FetchRequest header Source #

Instances

Instances details
( StandardHash header, Show header) => Show ( FetchRequest header) Source #
Instance details

Defined in Ouroboros.Network.BlockFetch.ClientState

HasHeader header => Semigroup ( FetchRequest header) Source #

We sometimes have the opportunity to merge fetch request fragments to reduce the number of separate range request messages that we send. We send one message per fragment. It is better to send fewer requests for bigger ranges, rather than lots of requests for small ranges.

We never expect fetch requests to overlap (ie have blocks in common) but we do expect a common case that requests will "touch" so that two ranges could be merged into a single contiguous range.

This semigroup instance implements this merging when possible, otherwise the two lists of fragments are just appended.

A consequence of merging and sending fewer request messages is that tracking the number of requests in-flight a bit more subtle. To track this accurately we have to look at the old request as well a the updated request after any merging. We meed to account for the difference in the number of fragments in the existing request (if any) and in new request.

Instance details

Defined in Ouroboros.Network.BlockFetch.ClientState

data FetchClientStateVars m header Source #

A set of variables shared between the block fetch logic thread and each thread executing the client side of the block fetch protocol. That is, these are the shared variables per peer. The FetchClientRegistry contains the mapping of these for all peers.

The variables are used for communicating from the protocol thread to the decision making thread the status of things with that peer. And in the other direction one shared variable is for providing new fetch requests.

Exception types