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

Download the topology state for a member up to including the topology transaction that made the member known on the synchronizer.

Return the currently known traffic state for a member. Callers must be authorized to request the traffic state.

Submit a request to the sequencer.

A request contains a batch, which is a sequence of envelopes. Every envelope consists of its content and a set of recipients, arranged in a forest. A synchronizer member is intended to receive those envelopes of a batch that contain the member as a recipient. A synchronizer member is supposed to learn about those recipients of an envelope that are (1) specified at a node that also specifies the member or (2) at a descendant thereof. (I.e., a node further down in the recipient forest.)

The sequencer may or may not accept a request. If an incoming request is valid (i.e., it can be parsed and every field meets its documented validity conditions) an honest sequencer will accept requests in a best effort manner, provided resource limits are met.

For every accepted request, the sequencer assigns a unique sequencing timestamp to the request. All honest sequencers of the synchronizer will deliver an event to the sender and to those synchronizer members that are intended to receive at least one envelope.

Honest sequencers may deliver to all sequencers of the synchronizer events that don't correspond to submitted requests. Sequencer implementations may leverage this mechanism for internal purposes.

An event for a synchronizer member contains only those envelopes of the batch of the request that the member is intended to receive and the recipients of an envelope contains only those that the member is supposed to learn about. A member will receive the envelopes of the same request within a single event. A member will receive events ordered by sequencing timestamp.

If a request is accepted, the sender will receive a corresponding event, called "receipt"; so that the sender is informed that the sequencer has accepted the request. If the sender is not a recipient of the request, the receipt has an empty batch.

If the request contains an aggregation rule, the sequencer will process requests in an aggregated fashion. A set of requests belong to the same aggregation, if they have essentially the same contents (details specified at SubmissionRequest.aggregationId). The sequencer validates and assigns sequencing timestamps to requests within an aggregation just as for requests without an aggregation rule. The sequencer emits events and receipts for an accepted request within an aggregation as follows: - As long as the number of accepted requests is strictly less than AggregationRule.threshold, the sequencer only emits a receipt with an empty batch to the sender of the request. It does not emit any other events. - As soon as the number of accepted requests equals AggregationRule.threshold, the sequencer emits events to the sender and the recipients of the request. The sequencing timestamp of the events is the sequencing timestamp of the last accepted request. - The sequencer will not accept more than AggregationRule.threshold requests. The sequencer will reject any further request that could otherwise be accepted. Consequently, events for the request are delivered only once even if the threshold is attained multiple times.

If the request does not contain an aggregation rule, even honest sequencers may deliver events for the request more than once (with different sequencing timestamps), as malicious sequencers may replay a request internally. Clients need to implement appropriate deduplication, if at-most-once delivery is needed. Once request.max_sequencing_time has elapsed (i.e. an event with an equal or higher timestamp has been emitted), an honest sequencer will not emit events corresponding to request anymore.

The sequencer may reject a request, e.g., because the request is invalid or the sequencer is overloaded. The sequencer will indicate a rejection (independently of whether there is an aggregation rule) in exactly one of the following ways: (1) synchronously, by returning an error in the response of this method (2) asynchronously, by emitting an error in the response to SubscribeVersioned to the sender and possibly an empty batch to non-sender recipients (3) by not emitting a receipt to the sender until request.max_sequencing_time Note that only (2) and (3) can be trusted. A malicious sequencer may synchronously return an error and still accept the request internally and therefore emit events later on.

Establishes a stream with the server to receive sequenced events from the synchronizer after the given counter. The delivered events will have a reference to the previous event (its timestamp) and a strictly monotonically increasing timestamp.

The call fails synchronously, if the request is invalid, i.e., some field violates a documented validity condition. The call fails asynchronously, if the sequencer does not have a key to sign the event; this may occur if event.topology_timestamp refers to a time before the sequencer has been onboarded.