- case class AwaitTimeRequest(domainIdO: Option[DomainId], timestamp: CantonTimestamp) extends HasProtoV0[domain.api.v0.AwaitTimeRequest] with Product with Serializable
- abstract class Clock extends AutoCloseable with NamedLogging
A clock returning the current time, but with a twist: it always returns unique timestamps.
- class DelegatingSimClock extends SimClock
This implementation allows us to control many independent sim clocks at the same time.
- class DomainTimeTracker extends NamedLogging with FlagCloseable with HasFlushFuture
Provides a variety of methods for tracking time on the domain.
- case class DomainTimeTrackerConfig(observationLatency: NonNegativeFiniteDuration = NonNegativeFiniteDuration.ofMillis(250), patienceDuration: NonNegativeFiniteDuration = NonNegativeFiniteDuration.ofMillis(500), minObservationDuration: NonNegativeFiniteDuration = NonNegativeFiniteDuration.ofHours(24), timeRequest: TimeProofRequestConfig = TimeProofRequestConfig()) extends HasProtoV0[time.admin.v0.DomainTimeTrackerConfig] with Product with Serializable
Configuration for the domain time tracker.
Even if the host and domain clocks are perfectly synchronized there will always be some latency for an event to be delivered (storage, transmission, processing). If the current host time exceeds the next expected timestamp by this observation latency then we will request a time proof (unless we have received a recent event within the patience duration described below).
We will only request a time proof if this given duration has elapsed since we last received an event (measured using the host clock). This prevents requesting timestamps when we are observing events from the domain (particularly if the local node is catching up on old activity).
We will try to ensure that we receive a time at least once during this duration (measured using the host clock). This is practically useful if there is no other activity on the domain as the sequencer client will then have an event to acknowledge allowing sequenced events to be pruned before this point. We may in the future use this to monitor clock skews between the host and domain.
configuration for how we ask for a time proof.
- case class FetchTimeRequest(domainIdO: Option[DomainId], freshnessBound: NonNegativeFiniteDuration) extends HasProtoV0[domain.api.v0.FetchTimeRequest] with Product with Serializable
- case class FetchTimeResponse(timestamp: CantonTimestamp) extends HasProtoV0[domain.api.v0.FetchTimeResponse] with Product with Serializable
- class GrpcDomainTimeService extends DomainTimeService with NamedLogging
Admin service to expose the time of domains to a participant and other nodes
- trait HasUptime extends AnyRef
- final case class NonNegativeFiniteDuration(duration: Duration) extends RefinedDuration with PrettyPrinting with Product with Serializable
- final case class NonNegativeSeconds(duration: Duration) extends RefinedDuration with PrettyPrinting with Product with Serializable
- final case class PositiveFiniteDuration(duration: Duration) extends RefinedDuration with PrettyPrinting with Product with Serializable
- final case class PositiveSeconds(duration: Duration) extends RefinedDuration with PrettyPrinting with Product with Serializable
- sealed trait RefinedDuration extends AnyRef
- trait RefinedDurationCompanion[RD <: RefinedDuration] extends AnyRef
- class RemoteClock extends Clock with NamedLogging
- class SimClock extends Clock with NamedLogging
- class TestingTimeService extends AnyRef
- trait TickTock extends AnyRef
- trait TimeAwaiter extends AnyRef
Utility to implement a time awaiter
- case class TimeProof extends PrettyPrinting with HasProtoV0[time.v0.TimeProof] with HasCryptographicEvidence with Product with Serializable
Wrapper for a sequenced event that has the correct properties to act as a time proof:
- case class TimeProofRequestConfig(initialRetryDelay: NonNegativeFiniteDuration = NonNegativeFiniteDuration.ofMillis(200), maxRetryDelay: NonNegativeFiniteDuration = NonNegativeFiniteDuration.ofSeconds(5), maxSequencingDelay: NonNegativeFiniteDuration = NonNegativeFiniteDuration.ofSeconds(10)) extends HasProtoV0[time.admin.v0.TimeProofRequestConfig] with Product with Serializable
The initial retry delay if the request to send a sequenced event fails
The max retry delay if the request to send a sequenced event fails
If our request for a sequenced event was successful, how long should we wait to observe it from the sequencer before starting a new request.
- trait TimeProofRequestSubmitter extends AutoCloseable
- class WallClock extends Clock with NamedLogging
- object AwaitTimeRequest extends Serializable
- object Clock extends ClockErrorGroup
- object DomainTimeTracker
- object DomainTimeTrackerConfig extends Serializable
- object FetchTimeRequest extends Serializable
- object FetchTimeResponse extends Serializable
- object GrpcDomainTimeService
- object NonNegativeFiniteDuration extends RefinedDurationCompanion[NonNegativeFiniteDuration] with Serializable
- object NonNegativeSeconds extends RefinedDurationCompanion[NonNegativeSeconds] with Serializable
- object PositiveFiniteDuration extends RefinedDurationCompanion[PositiveFiniteDuration] with Serializable
- object PositiveSeconds extends RefinedDurationCompanion[PositiveSeconds] with Serializable
- object TickTock
- object TimeProof extends Serializable
- object TimeProofRequestConfig extends Serializable
- object TimeProofRequestSubmitter
- object TimeProofRequestSubmitterImpl