ouroboros-network
Safe HaskellNone
LanguageHaskell2010

Ouroboros.Network.TxSubmission.Inbound.V2

Synopsis

TxSubmission Inbound client

txSubmissionInboundV2 :: forall txid tx idx (m :: Type -> Type) err. (MonadDelay m, MonadTimer m, MonadThrow m, Ord txid, Show txid, Typeable txid) => Tracer m (TraceTxSubmissionInbound txid tx) -> TxSubmissionInitDelay -> TxDecisionPolicy -> TxSubmissionMempoolWriter txid tx idx m err -> (tx -> SizeInBytes) -> PeerTxAPI m txid tx -> TxSubmissionServerPipelined txid tx m () Source #

A tx-submission inbound side (server, sic!).

Each call to runNextPeerAction atomically inspects the shared state and this peer's local protocol state and returns one of: submit buffered bodies to the mempool, request bodies, request txids (blocking or pipelined), or do nothing. When idle, the server parks on awaitSharedChange until the shared-state generation moves or an optional wake delay expires, then re-evaluates. Body requests are pipelined; in pipelined mode txid requests become non-blocking and the server collects replies via handleReplies.

V2 server state machine.

Depth n tracks outstanding pipelined replies (type-level Nat).

States (non-pipelined, n = 0): serverIdle - park on awaitSharedChange or pick next action serverReqTxIds 0 - send a txid request (blocking or pipelined) submitBufferedTxs - submit buffered bodies, run continuation requestTxBodies - send a pipelined body request, depth + 1

States (pipelined, n > 0): continueAfterReplies - post-reply pick; dispatch action or DoNothing continueAfterBodyRequests - post-body-request pick; same dispatch handleReplies n - block on CollectPipelined for the next reply handleReply (n-1) - apply received txids or bodies, then continueAfterReplies (n-1)

Transitions:

serverIdle [PeerDoNothing] --> awaitSharedChange --> serverIdle [PeerSubmitTxs ks] --> submitBufferedTxs ks serverIdle [PeerRequestTxs ks] --> requestTxBodies 0 ks --> continueAfterBodyRequests 1 [PeerRequestTxIds] when unack queue empty --> blocking wire request, wait for reply --> serverIdle [PeerRequestTxIds] otherwise --> pipelined wire request --> handleReplies 1

handleReplies n --> handleReply (n-1) handleReply [CollectTxIds] --> applyReceivedTxIds --> continueAfterReplies (n-1) [CollectTxs] --> applyReceivedTxs --> continueAfterReplies (n-1)

continueAfterReplies 0 = serverIdle continueAfterReplies n@(>0), continueAfterBodyRequests n [PeerSubmitTxs ks] --> submitBufferedTxs ks (continueAfterReplies n) [PeerRequestTxs ks] --> requestTxBodies n ks [PeerRequestTxIds] --> serverReqTxIds n [PeerDoNothing] --> handleReplies n

Supporting types and APIs

data TxDecisionPolicy Source #

Policy for making decisions

Constructors

TxDecisionPolicy 

Fields

  • txsSizeInflightPerPeer :: !SizeInBytes

    a limit of tx size in-flight from a single peer. It can be exceed by max tx size.

  • txsSizePerBatch :: !SizeInBytes

    Hard limit on the total advertised transaction size in one body request batch, except for the first tx in a batch, which is requested even if it is larger. Hence a batch is at most `max txsSizePerBatch max_TX_SIZE`. The default reserves space for reply framing and for the const_MAX_TX_SIZE_DISCREPANCY tolerance of each tx. It MUST be positive, and the reply to the largest batch MUST fit within the StTxs size limit (see saneTxDecisionPolicy). It can be smaller than max_TX_SIZE: a larger tx is requested in a batch on its own.

  • maxOutstandingTxBatchesPerPeer :: !Int

    a limit of outstanding tx-body request batches from a single peer.

  • txInflightMultiplicity :: !Int

    from how many peers download the txid simultaneously

  • bufferedTxsMinLifetime :: !DiffTime

    how long TXs that have been added to the mempool will be kept in the bufferedTxs cache.

  • scoreRate :: !Double

    rate at which "rejected" TXs drain. Unit: TX/seconds.

  • scoreMax :: !Double

    Maximum number of "rejections". Unit: seconds

  • scoreAcceptDecrement :: !Double

    amount subtracted from the peer's score for each tx body the peer delivered that the mempool accepted.

  • interTxSpace :: !DiffTime

    space between actual requests for the same TX. This the time a peer has soul ownership of their TX lease. When it expires other peers may issue additional requests.

  • inflightTimeout :: !DiffTime

    Maximum time a peer's attempt may sit between claim and entering submission before the per-entry inflight-multiplicity cap is bumped, allowing another peer to attempt in parallel.

  • maxPeerClaimDelay :: !DiffTime

    Maximum delay penalty for poor performing peers.

  • disablePipelinedTxIdRequests :: !Bool

    When True, the txid picker never issues pipelined MsgRequestTxIds messages; only blocking requests fire (and only when the unack window has been fully drained). Used by some benchmarks.

mkTxDecisionPolicy :: TxSubmissionConfig -> Either TxConfigurationError TxDecisionPolicy Source #

The default policy for the given config. Returns a TxConfigurationError if it isn't sane (see saneTxDecisionPolicy); the node should then report it and halt.

data TxConfigurationError Source #

Why a TxDecisionPolicy with a TxSubmissionConfig isn't sane, see saneTxDecisionPolicy. Each constructor carries the offending values.

Constructors

NumUnacknowledgedTxIdsTooSmall NumTxIdsToAck

maxNumUnacknowledgedTxIds must be positive

NumUnacknowledgedTxIdsTooLarge NumTxIdsToAck

a MsgRequestTxs with maxNumUnacknowledgedTxIds txids of size max_TXID_SIZE doesn't fit within the StIdle size limit

MaxNumTxIdsToRequestTooSmall NumTxIdsToReq

maxNumTxIdsToRequest must be positive

MaxNumTxIdsToRequestTooLarge NumTxIdsToReq

max_TX_SIZE * maxNumTxIdsToRequest doesn't fit in SizeInBytes

TxsSizeInflightPerPeerTooSmall SizeInBytes

txsSizeInflightPerPeer must be positive

TxsSizePerBatchTooSmall SizeInBytes

txsSizePerBatch must be positive

TxsSizePerBatchTooLarge SizeInBytes NumTxIdsToAck

the reply to the largest batch, with maxNumUnacknowledgedTxIds txs each up to const_MAX_TX_SIZE_DISCREPANCY larger than advertised, doesn't fit within the StTxs size limit

MaxOutstandingTxBatchesPerPeerTooSmall Int

maxOutstandingTxBatchesPerPeer must be positive

TxInflightMultiplicityTooSmall Int

txInflightMultiplicity must be positive

BufferedTxsMinLifetimeTooSmall DiffTime

bufferedTxsMinLifetime must be non-negative

ScoreRateTooSmall Double

scoreRate must be non-negative

ScoreMaxTooSmall Double

scoreMax must be non-negative

ScoreAcceptDecrementTooSmall Double

scoreAcceptDecrement must be non-negative

InterTxSpaceTooSmall DiffTime

interTxSpace must be non-negative

InflightTimeoutTooSmall DiffTime DiffTime

inflightTimeout (the first field) must be at least interTxSpace (the second field)

MaxPeerClaimDelayTooSmall DiffTime

maxPeerClaimDelay must be non-negative

data TxSubmissionConfig Source #

Shared options between the inbound and outbound side.

Constructors

TxSubmissionConfig 

Fields

  • maxNumUnacknowledgedTxIds :: !NumTxIdsToAck

    maximum number of unacknowledged txids; it MUST be positive, and small enough for a MsgRequestTxs with that many txids to fit within the StIdle size limit (see max_TXID_SIZE). Before NodeToNodeV_16 it is a protocol parameter and must not be changed; since NodeToNodeV_16 it is a local setting.

  • maxNumTxIdsToRequest :: !NumTxIdsToReq

    maximum number of txids an inbound client can request at a time.