Issue #, if available:

None

Description of changes:

I found that you here use vector to get timestamps, IMO, these functions are highly frequently called, so it is better to use array instead of vector.

I wrote a simple benchmark below:

#![feature(test)]
extern crate test;
use test::{black_box, Bencher};
#[bench]
fn bench_vec(b: &mut Bencher) {
    b.iter(|| {
        for _ in 0..16 {
            let mut request: Vec<u8> = Vec::new();
            // Inner closure, the actual test
            for i in 0..4 {
                request.push(i);
            }
            black_box(request);
        }
    });
}
#[bench]
fn bench_vec_with_capacity(b: &mut Bencher) {
    b.iter(|| {
        for _ in 0..16 {
            let mut request: Vec<u8> = Vec::with_capacity(4);
            // Inner closure, the actual test
            for i in 0..4 {
                request.push(i);
            }
            black_box(request);
        }
    });
}
#[bench]
fn bench_array(b: &mut Bencher) {
    b.iter(|| {
        for _ in 0..16 {
            let mut request: [u8; 4] = [0; 4];
            // Inner closure, the actual test
            for i in 0..4 {
                request[i] = i as u8;
            }
            black_box(request);
        }
    });
}

The benchmark result is:

test bench_array            ... bench:           4 ns/iter (+/- 0)
test bench_vec               ... bench:       1,014 ns/iter (+/- 143)
test bench_vec_with_capacity ... bench:         977 ns/iter (+/- 70)

As you can see, using array gains a better performance.

Because this repo doesn't have any unit tests, I have to test it by myself, seem it can work well, like:

cargo run --example now /run/clockboundd/clockboundd.sock
The UTC timestamp 2021-12-14 14:24:20.048961000 has the following error bounds.
In nanoseconds since the Unix epoch: (1639491860040783810,1639491860057138190)
In UTC in date/time format: (2021-12-14 14:24:20.040783810, 2021-12-14 14:24:20.057138190)

cargo run --example before /run/clockboundd/clockboundd.sock
1639491872937419000 nanoseconds since the Unix Epoch is not before the current time's error bounds.
Waiting 1 second...
1639491872937419000 nanoseconds since the Unix Epoch is before the current time's error bounds.

cargo run --example after /run/clockboundd/clockboundd.sock
1639491883489757000 nanoseconds since the Unix Epoch is after the current time's error bounds.
Waiting 2 seconds...
1639491883489757000 nanoseconds since the Unix Epoch is not after the current time's error bounds.

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

Description of changes:

The current implementation assumes the client connects to the daemon using file system based socket. If the client uses [an abstract socket address], it fails to send back response.

The change allows the daemon to communicate back to the client irrespective to the type of socket it uses.

Bump versions and update Cargo.lock.

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

Description of changes:

The current now() API call is prone to TOCTOU (time-of-check to time-of-use) error. This adds an additional API call which accepts a callback to an execution that needs to be timestamped by the user and calculates the upper and lower bound based on that.

pub struct TimingResult {
    /// Callback began executing no earlier than this time
    pub earliest_start : SystemTime,
    /// Callback finished executing no later than this time
    pub latest_finish : SystemTime,
    /// No less than this amount of time elapsed from when timing() was called
    /// to when it returned.
    pub min_execution_time : Duration,
    /// No more than this amount of time elapsed when the callback was invoked
    /// to when it returned.
    pub max_execution_time : Duration
}

It also returns maximum and minimum execution time of the timing API call.

Overview of the execution steps taken by the API call

1. User calls the `timing(f)` API 
2. Collects the upper and lower bound at T1 
3. Executes the callback f
4. Collects the upper and lower bound at T2
5. Compares duration between T1 midpoint and T2 midpoint
6. Computes maximum and minimum duration by +/- clock frequency
7. Returns upper bound, lower bound, min execution, maximum execution

Sample output of running cargo run --example timing /run/clockboundd/clockboundd.sock

Earliest start time for the timing request: "2022-02-21 19:43:34.530780989"
Latest finish time for the timing request: "2022-02-21 19:43:34.552979011"
Minimum execution duration of timing request: 51µs
Maximum execution duration of timing request: 73µs

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

Bumped clock-bound-d version to 0.1.1 and ran cargo update in order to bring in chrony-candm-0.1.1 with https://github.com/aws/chrony-candm/pull/1

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

Description of changes:

Updates the crates.io badge of clock-bound-c to point to clock-bound-c instead of clock-bound-d.

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

Description of changes:

Includes the initial working version of ClockBound.

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

WIP while I add some example code.

This PR adds some functionality to the client library to periodically poll the daemon and trigger a callback if the clock error bound falls above or below user-provided thresholds.

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

Hello. I would like to run clock-bound-d on Docker, but there are probably two barriers.

1. clock-bound-d currently supports only syslog logging.

I wrote the following Dockerfile, but this gives me an error.

FROM rust:1.59.0-bullseye
RUN cargo install clock-bound-d --version 0.1.1
CMD ["clockboundd"]

thread 'main' panicked at 'could not connect to syslog: Error(Initialization, State { next_error: Some(Error(Io(Os { code: 2, kind: NotFound, message: "No such file or directory" }), State { next_error: None, backtrace: InternalBacktrace })), backtrace: InternalBacktrace })', /usr/local/cargo/registry/src/github.com-1ecc6299db9ec823/clock-bound-d-0.1.1/src/main.rs:65:42
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

2. clock-bound-d supports only 323 port.

When running clock-bound-d on Docker, I'm thinking of running chrony as a side car. For example, I'm thinking of using https://github.com/cturra/docker-ntp , which works with port 123. I think a workaround is possible, but it would be useful to be able to use a port other than 323.

Are there any plans to make these two points configurable?