The missing part. The client is also a service that must support a health check endpoint.

We must manage users based on a more traditional approach in cloud environments (AWS): we must remove HTTP Basic Auth and replace it with header-based ACCESS_KEY and SECRET_KEY authentication.

The server must use Etcd to access the authentication information. We already have the code implementing Etcd watched behavior: https://github.com/insight-platform/etcd_dynamic_state

Usage sample: https://github.com/insight-platform/savant-rs/blob/main/savant_core/src/eval_resolvers.rs#L256

This Etcd client implementation uses Etcd watch to get updates on all changes under the prefix and cache them locally. Thus, it can be used to implement such authentication.

Structure:

prefix
  - AC_1
  - AC_2

Value contains the following contents:

{
  "secret_key": "goes here", // salty, hash, not a plain value
  "allowed_source_ids": [..., ...], // globs (https://docs.rs/glob/latest/glob/)
  "allowed_routing_labels": ["ab", "cde", "label-1"]
}

Authentication must be implemented in a smart way to avoid running encryption functions when the same AK/SK is passed. For that, we can use the LRU cache (https://docs.rs/lru/latest/lru/) to keep the recalculated values in the memory.

The configuration file must configure the cache's size. The system must also support tracking LRU evicted keys, and a warning must be produced when more than X keys/sec are evicted.

It is unlikely to use both statistics strategies (by a frame period, by a timestamp period) at the same time. Moreover incorrectly configured history size might confuse the user as not all statistics will be reported to logs. E.g. with real FPS 3000, frame period 1000, timestamp period 1s, history size 4 statistics by timestamp will not be in logs at all.

history_size does not make sense for the user and might be removed if only one strategy is allowed.

Better lock contention for zmq reader.

This idea is inconvenient:

https://github.com/insight-platform/MediaGateway/blob/main/Dockerfile#L23C44-L23C70

Needs rework. It is absolutely not clear how the certificate lifecycle works. Why does CA require CRL? What about sequential numbers?

The manual MUST provide a self-containing guide on how to configure the client and server end-to-end without looking to external docs. Structured, with sections and steps.

The docs must be developed in the form of a tutorial.

1. how does it work;
2. structure of files and configurations;
3. how create a client certificate;
4. how to add a client certificate;
5. how to revoke a client certificate.

Why the client defines a number of signal handlers and server does not?

The quarantine time must be configured with the configuration file parameter.

When the system fails to send a message, the delay must increase twice until the upper bond is reached, e.g.,

1ms
2ms
4ms
16ms
increase while < configured cap

to avoid resource waste and log hell. When it fails, the system must log when the next retry will happen. After the successful delivery, the delay is reset.

Describe AAA models:

• TLS+basic (encryption)
• TLS+X509+CRL (encryption, authentication, revocation list)
• TLS+X509+CRL+basic (encryption, authentication, revocation list, AK/SK authentication)

CPU load by media gateway client is high.

Use cases:

• e2e_usage_video_loop_ao_rtsp 170%
• multisource benchmark (SYNC_OUTPUT=true, NUMBER_OF_STREAMS=128) 190%

In the current implementation CRL checks are mandatory if X509 client authentication is used. In some cases it is not required. Thus, it should be optional.