Documentation

Pipelined chain sync client. It can only pipeline MsgRequestNext messages, while the MsgFindIntersect are non pipelined. This has a penalty cost of an RTT, but they are sent relatively seldom and their response might impact how many messages one would like to pipeline. It also simplifies the receiver callback.

Pipelined sender which starts in StIdle state. It can either

• Send MsgRequestNext (no pipelining), which might be useful when we are at the tip of the chain. It can only be send when there is no pipelined message in flight (all responses were collected);
• Pipeline MsgRequestNext;
• Send MsgFindIntersect (no pipelining); It can only be send when there is no pipelined message in flight (all responses were collected);
• Collect responses of pipelined message;
• Terminate the protocol with by sending MsgDone.

Callback for responses received after sending MsgRequestNext.

We could receive MsgAwaitReply. In this case we will wait for the next message which must be MsgRollForward or MsgRollBackward; thus we need only the two callbacks.

Callbacks for messages received after sending MsgFindIntersect.

We might receive either MsgIntersectFound or MsgIntersectNotFound.

Data received through pipelining: either roll forward or roll backward instruction. If the server replied with MsgAwaitReply the pipelined receiver will await for the next message which must come with an instruction how to update our chain.

Note: internal API, not exposed by this module.

Transform a ChainSyncClientPipelined by mapping over the tx header and the chain tip values.

Note the direction of the individual mapping functions corresponds to whether the types are used as protocol inputs or outputs (or both, as is the case for points).