| Safe Haskell | Safe-Inferred |
|---|---|
| Language | Haskell2010 |
Ouroboros.Network.Protocol.TxSubmission2.Type
Description
The type of the transaction submission protocol.
This is used to relay transactions between nodes.
Synopsis
- type TxSizeInBytes = Word32
- data TxSubmission2 txid tx where
- StInit ∷ TxSubmission2 txid tx
- StIdle ∷ TxSubmission2 txid tx
- StTxIds ∷ StBlockingStyle → TxSubmission2 txid tx
- StTxs ∷ TxSubmission2 txid tx
- StDone ∷ TxSubmission2 txid tx
- data StBlockingStyle where
- data TokBlockingStyle (k ∷ StBlockingStyle) where
- data BlockingReplyList (blocking ∷ StBlockingStyle) a where
Documentation
type TxSizeInBytes = Word32 Source #
Transactions are typically not big, but in principle in future we could have ones over 64k large.
data TxSubmission2 txid tx where Source #
The kind of the transaction-submission protocol, and the types of the states in the protocol state machine.
We describe this protocol using the label "client" for the peer that is submitting transactions, and "server" for the one receiving them. The protocol is however pull based, so it is typically the server that has agency in this protocol. This is the opposite of the chain sync and block fetch protocols, but that makes sense because the information flow is also reversed: submitting transactions rather than receiving headers and blocks.
Because these client/server labels are somewhat confusing in this case, we sometimes clarify by using the terms inbound and outbound. This refers to whether transactions are flowing towards a peer or away, and thus indicates what role the peer is playing.
Constructors
| StInit ∷ TxSubmission2 txid tx | Initial protocol message. |
| StIdle ∷ TxSubmission2 txid tx | The server (inbound side) has agency; it can either terminate, ask for transaction identifiers or ask for transactions. There is no timeout in this state. |
| StTxIds ∷ StBlockingStyle → TxSubmission2 txid tx | The client (outbound side) has agency; it must reply with a list of transaction identifiers that it wishes to submit. There are two sub-states for this, for blocking and non-blocking cases. |
| StTxs ∷ TxSubmission2 txid tx | The client (outbound side) has agency; it must reply with the list of transactions. |
| StDone ∷ TxSubmission2 txid tx | Nobody has agency; termination state. |
Instances
data StBlockingStyle where Source #
Constructors
| StBlocking ∷ StBlockingStyle | In this sub-state the reply need not be prompt. There is no timeout. |
| StNonBlocking ∷ StBlockingStyle | In this state the peer must reply. There is a timeout. |
data TokBlockingStyle (k ∷ StBlockingStyle) where Source #
The value level equivalent of StBlockingStyle.
This is also used in MsgRequestTxIds where it is interpreted (and can be
encoded) as a Bool with True for blocking, and False for non-blocking.
Constructors
| TokBlocking ∷ TokBlockingStyle StBlocking | |
| TokNonBlocking ∷ TokBlockingStyle StNonBlocking |
Instances
| Eq (TokBlockingStyle b) Source # | |
Defined in Ouroboros.Network.Protocol.TxSubmission2.Type Methods (==) ∷ TokBlockingStyle b → TokBlockingStyle b → Bool Source # (/=) ∷ TokBlockingStyle b → TokBlockingStyle b → Bool Source # | |
| Show (TokBlockingStyle b) Source # | |
data BlockingReplyList (blocking ∷ StBlockingStyle) a where Source #
We have requests for lists of things. In the blocking case the corresponding reply must be non-empty, whereas in the non-blocking case and empty reply is fine.
Constructors
| BlockingReply ∷ NonEmpty a → BlockingReplyList StBlocking a | |
| NonBlockingReply ∷ [a] → BlockingReplyList StNonBlocking a |
Instances
| Eq a ⇒ Eq (BlockingReplyList blocking a) Source # | |
Defined in Ouroboros.Network.Protocol.TxSubmission2.Type Methods (==) ∷ BlockingReplyList blocking a → BlockingReplyList blocking a → Bool Source # (/=) ∷ BlockingReplyList blocking a → BlockingReplyList blocking a → Bool Source # | |
| Show a ⇒ Show (BlockingReplyList blocking a) Source # | |