Questions

[SUNsung]

You lack a Discord server for contact, github isn't as community friendly.

I'm a little confused by the documentation and the NATS server configuration options.
Here's a list of questions:

1. Is it possible to authorize connections by an arbitrary key? Not to enter each user in the settings and reboot the server every time, but some mechanism that allows adding and removing keys at any time without requiring a server restart (ideally if it applies to the whole cluster).
2. How exactly to make multiple channels for synchronization between servers (cluster)? To make nodes communicate with each other not through one adr:port, but through several, which would increase the width of the synchronization channel.
3. What are the options for encrypting traffic other than TLS?
4. How exactly does JetStream store data on disk? Is it possible to use such storage method as a cold cache for data (up to 10Mb) that may be requested in the next 24 hours or is it better to write your own solution using a database?

[neilalexander]

We have a public NATS Slack instead of Discord: https://slack.nats.io/

1. I think you're looking for decentralised auth: https://docs.nats.io/running-a-nats-service/configuration/securing_nats/auth_intro/jwt
2. Using routes v2 in 2.10.x: https://docs.nats.io/running-a-nats-service/configuration/clustering/v2_routes
3. TLS is industry-standard, what other options do you have in mind?
4. JetStream has a custom file store implementation with subject-based indexing and in-memory caching for hot blocks, there is also optional memory-based/volatile storage if you want to keep certain assets in memory only

[SUNsung]

Slack is not the most convenient and can at any moment “disappear” (I observed how once “public” Slack on computer vision for microcontrollers with 300+ users in one day simply “ceased to exist”).

1. That is, nothing different that I didn't see in the documentation((

   • The first reason why it doesn't fit is the format for storing and accessing keys dir: “/path/to/store/jwt”
   • The second reason is that to authorize a user to have access to each node in the cluster you need to perform a “user add” via nsc on each node. The documentation says that they are “synchronized” but does not explain the mechanism and “depth”. That is, to be sure that all the necessary nodes visible to the user will be available to him, it is necessary to “add” manually.

2. Thanks, I'll experiment with it.

3. TLS is not the most optimal in terms of resources. Handshake can be done using TLS, but stream exchange will be processed faster using symeric algorithms. Plus, if used in low-loaded systems (IoT), TLS is redundant, and open transmission is dangerous (I made that the transmission would be encrypted, and from the server side decrypting proxy, but as I suspect this is not the most optimal solution).

4. Everything is clear with hot storage. I was asking specifically for non-volatile memory based storage. It is expected that 1M records of key:[]byte(file) format may be “waiting” in it, and therefore I would like to understand how optimized search and selection on this storage is. If this is expected to be a problem, it is better to use an external caching service, from which NATS will take data.

[SUNsung]

I'll explain the storage methods. Both keys and cold cache.

File access with first-character sharding is good only for small and medium volumes.
If we have 2M users with add/delete fluctuation of 100K per minute, then search, read/write and other operations will take quite a lot of time (if there are many queries in parallel)

NATS is expected to have a load of up to 100K users (ideally up to 60K), but the buffer storage should be one for all (or per group)
Even if there are less than 10K requests per node, a buffer of a billion files will be processed for a certain amount of time.

Therefore, for cold storage it would be nice to be able to select different databases.
For authorization keys, a complete solution is needed - hot storage for active keys and cold storage for long-term storage.