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.

Pipeline decision: we can do either one of these:

• non-pipelined request
• pipeline a request
• collect or pipeline, but only when there are pipelined requests
• collect, as above, only when there are pipelined requests

There might be other useful pipelining scenarios: collect a given number of requests (which also can be used to collect all outstanding requests).

The callback gets the following arguments:

• how many requests are not yet collected (in flight or already queued)
• block number of client's tip
• block number of server's tip

Client's tip block number and server's tip block number can only be equal (from the client's perspective) when both the client's and the server's tip headers agree. If they would not agree (server forked), then the server sends MsgRollBackward, which rolls back one block and causes the client's tip and the server's tip to differ.

In this module we implement three pipelining strategies:

• pipelineDecisionMax
• pipelineDecisionMin
• pipelineDecisionLowHighMark

Present maximal pipelining of at most omax requests. Collect responses either when we are at the same block number as the server or when we sent more than omax requests.

If omax = 3 this pipelining strategy will generate a sequence: Pipeline Pipeline Pipeline Collect Pipeline Collect .... Pipeline Collect Collect Collect

Present minimum pipelining of at most omax requests, collect responses eagerly.

Pipelining strategy which pipelines up to highMark requests; if the number of pipelined messages exceeds the high mark, it collects messages until there are at most lowMark outstanding requests.

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).