Allows a member to acknowledge that they have read all events up to and including the provided timestamp, and that they will never re-read these events again. This information is currently only used for informational purposes and to provide a watermark for which it is safe to prune earlier events from the sequencer data stores. There is no requirement for every event to be individually acknowledged, and in fact callers are encouraged to only periodically record acknowledgements (at an interval of minutes is expected to be more than sufficient for pruning).

Newer version of acknowledgements. To be active for protocol versions >= 4. The argument here is an AcknowledgeRequest wrapped in SignedContent. The signature is checked on the server side to avoid that malicious sequencers create fake acknowledgements in multi-writer architectures where writers don't fully trust each other.

Allows a member to acknowledge that they have read all events up to and including the provided timestamp, and that they will never re-read these events again. This information is currently only used for informational purposes and to provide a watermark for which it is safe to prune earlier events from the sequencer data stores. There is no requirement for every event to be individually acknowledged, and in fact callers are encouraged to only periodically record acknowledgements (at an interval of minutes is expected to be more than sufficient for pruning).

Submit a send request to the sequencer for sequencing asynchronously. The rpc request may return an error if the request cannot be processed at all - see SendAsyncResponse for these scenarios. The sequencer may emit a Deliver or DeliverError event from this send, if the subscriber witnesses an event greater or equal to the supplied maxSequencingTime, the sequencer guarantees not to publish a future Deliver event for this send. The sequencer implementation may however publish a future DeliverError (typically used to indicate maxSequencingTime exceeded). Used in protocol version 3

Newer version of request submission (for authenticated members). To be active for protocol versions 4. The argument here is a SubmissionRequest wrapped in SignedContent. The signature is checked on the server side to avoid that malicious sequencers create fake submission requests in multi-writer architectures where writers don't fully trust each other.

Submit a send request to the sequencer for sequencing asynchronously. The rpc request may return an error if the request cannot be processed at all - see SendAsyncResponse for these scenarios. The sequencer may emit a Deliver or DeliverError event from this send, if the subscriber witnesses an event greater or equal to the supplied maxSequencingTime, the sequencer guarantees not to publish a future Deliver event for this send. The sequencer implementation may however publish a future DeliverError (typically used to indicate maxSequencingTime exceeded).

Submit a send request to the sequencer for sequencing asynchronously exactly like SendAsyncVersioned, except that this meant to be used only by unauthenticated members for very specific operations that do not require authentication such as requesting that a participant's topology data gets accepted by the topology manager

Used in protocol version 5 or higher

Submit a send request to the sequencer for sequencing asynchronously. The rpc request may return an error if the request cannot be processed at all - see SendAsyncResponse for these scenarios. The sequencer may emit a Deliver or DeliverError event from this send. If the subscriber witnesses an event greater or equal to the supplied maxSequencingTime, the sequencer guarantees not to publish a future Deliver event for this send. The sequencer implementation may however publish a future DeliverError (typically used to indicate maxSequencingTime exceeded).

The signature is checked on the server side to avoid that malicious sequencers create fake submission requests in multi-writer architectures where writers don't fully trust each other.

Used in protocol version 5 or higher

Establishes a stream with the server to receive sequenced events from the domain after the given counter. The delivered events will have a sequential counter and monotonically increasing timestamp. TBD: Message TTL - How far back should it go when the participant initiate a subscription ?