Type Members

1.  case class AwaitTimeRequest(domainIdO: Option[DomainId], timestamp: CantonTimestamp) extends Product with Serializable
2.  abstract class Clock extends TimeProvider with AutoCloseable with NamedLogging

   A clock returning the current time, but with a twist: it always returns unique timestamps.

   A clock returning the current time, but with a twist: it always returns unique timestamps. If two calls are made to the same clock instance at the same time (according to the resolution of this clock), one of the calls will block, until it can return a unique value.

   All public functions are thread-safe.

3.  class DelegatingSimClock extends SimClock

   This implementation allows us to control many independent sim clocks at the same time.

   This implementation allows us to control many independent sim clocks at the same time. Possible race conditions that might happen with concurrent start/stop of clocks are not being addressed but are currently unlikely to happen.

4.  class DomainTimeTracker extends NamedLogging with FlagCloseable with HasFlushFuture

   Provides a variety of methods for tracking time on the domain.

   Provides a variety of methods for tracking time on the domain.

   • fetchTime and fetchTimeProof allows for proactively asking for a recent time or time proof.
   • requestTick asks the tracker to ensure that an event is witnessed for the given time or greater (useful for timeouts).
   • awaitTick will return a future to wait for the given time being reached on the target domain.

   We currently assume that the domain and our host are roughly synchronized and typically won't expect to see a time on a domain until we have passed that point on our local clock. We then wait for observationLatency past the timestamp we are expecting to elapse on our local clock as transmission of an event with that timestamp will still take some time to arrive at our host. This avoids frequently asking for times before we've reached the timestamps we're looking for locally.

   We also take into account a patienceDuration that will cause us to defer asking for a time if we have recently seen events for the domain. This is particularly useful if we are significantly behind and reading many old events from the domain.

   If no activity is happening on the domain we will try to ensure that we have observed an event at least once during the minObservationDuration.

5.  case class DomainTimeTrackerConfig(observationLatency: NonNegativeFiniteDuration = NonNegativeFiniteDuration.ofMillis(250), patienceDuration: NonNegativeFiniteDuration = NonNegativeFiniteDuration.ofMillis(500), minObservationDuration: NonNegativeFiniteDuration = NonNegativeFiniteDuration.ofHours(24), timeRequest: TimeProofRequestConfig = TimeProofRequestConfig()) extends Product with Serializable

   Configuration for the domain time tracker.

   Configuration for the domain time tracker.

   observationLatency

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

   patienceDuration

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

   minObservationDuration

   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.

   timeRequest

   configuration for how we ask for a time proof.

6.  case class FetchTimeRequest(domainIdO: Option[DomainId], freshnessBound: NonNegativeFiniteDuration) extends Product with Serializable
7.  case class FetchTimeResponse(timestamp: CantonTimestamp) extends Product with Serializable
8.  class GrpcDomainTimeService extends DomainTimeService with NamedLogging

   Admin service to expose the time of domains to a participant and other nodes

9.  trait HasUptime extends AnyRef
10.  final case class NonNegativeFiniteDuration(duration: Duration) extends RefinedDuration with PrettyPrinting with Product with Serializable
11.  final case class NonNegativeSeconds(duration: Duration) extends RefinedDuration with PrettyPrinting with Product with Serializable
12.  class PeriodicAction extends NamedLogging with FlagCloseable
13.  final case class PositiveFiniteDuration(duration: Duration) extends RefinedDuration with PrettyPrinting with Product with Serializable
14.  final case class PositiveSeconds(duration: Duration) extends RefinedDuration with PrettyPrinting with Product with Serializable
15.  sealed trait RefinedDuration extends Ordered[RefinedDuration]
16.  trait RefinedDurationCompanion[RD <: RefinedDuration] extends AnyRef
17.  class RemoteClock extends Clock with NamedLogging
18.  class SimClock extends Clock with NamedLogging
19.  class TestingTimeService extends AnyRef
20.  trait TickTock extends AnyRef
21.  trait TimeAwaiter extends AnyRef

    Utility to implement a time awaiter

    Utility to implement a time awaiter

    Note, you need to invoke expireOnShutdown onClosed

22.  case class TimeProof extends PrettyPrinting with HasCryptographicEvidence with Product with Serializable

    Wrapper for a sequenced event that has the correct properties to act as a time proof:

    Wrapper for a sequenced event that has the correct properties to act as a time proof:

    • a deliver event with no envelopes
    • has a message id that suggests it was requested as a time proof (this is practically unnecessary but will act as a safeguard against future sequenced event changes)
23.  case class TimeProofRequestConfig(initialRetryDelay: NonNegativeFiniteDuration = NonNegativeFiniteDuration.ofMillis(200), maxRetryDelay: NonNegativeFiniteDuration = NonNegativeFiniteDuration.ofSeconds(5), maxSequencingDelay: NonNegativeFiniteDuration = NonNegativeFiniteDuration.ofSeconds(10)) extends Product with Serializable
    initialRetryDelay

    The initial retry delay if the request to send a sequenced event fails

    maxRetryDelay

    The max retry delay if the request to send a sequenced event fails

    maxSequencingDelay

    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.

24.  trait TimeProofRequestSubmitter extends AutoCloseable

    Use fetchTimeProof to fetch a time proof we observe from the sequencer via handleTimeProof.

    Use fetchTimeProof to fetch a time proof we observe from the sequencer via handleTimeProof. Will batch fetch calls so there is only a single request occurring at any point.

    The submission of this request to the sequencer is slightly more involved than usual as we do not rely at all on domain time as this component is primarily used when the domain time is likely unknown or stale. Instead we use the the local node clock for retries.

    Future optimizations:

    • Most scenarios don't need a time event specifically and instead just need any event to cause a "tick". In these cases we could short circuit and cancel a pending request when receiving any event with a timestamp. However this would only optimize our retry loop so the distinction doesn't currently feel anywhere near worthwhile.
25.  trait TimeProvider extends AnyRef
26.  class WallClock extends Clock with NamedLogging