License Management

Note

GW is Gateway, LM is License Manage.

How it works?

You should install the roq-tools package and then generate your own public/private keys using the roq-keygen (from roq-tools). You will have to communicate your public key to Roq so it can be associated with your license agreement.

These are the steps

  • GW computes SHA256 hash of the sorted set of configured logins

  • GW creates a sealed request using its private key

  • GW sends the request and your public key to LM

  • LM opens the sealed request using its private key

  • LM matches the public key to an existing license agreement

  • LM responds to GW with HTTP status code 200 and an access token if a license can be locked

  • LM responds to GW with HTTP code 400 if

    • there is no associated license agreement

    • there are no available licenses

  • GW will on success (200) replace the locally cached access token

Note

Logins are typically the API keys you use to identify yourself to an exchange. We only use the logins to hash the config file, NEVER secrets and passphrases.

Note

GW’s are currently allowed to start with all features enabled but will terminate after a pre-configured timeout period if no valid access token can be acquired.

Important

GW’s may indicate an ideal lock-period. This is only a hint and the LM is allowed to override.

If you change your config, and you have no more available licenses, please wait until a previously locked license becomes free.

This could have implications for up-time. In order to guarantee maxium up-time, you may wish to request a relatively long lock period, e.g. a day or a week.

However, you may not be able to restart your GW (with all features enabled) if you then find that you have to change an API key on the exchange. The only way to refresh the access token is then to contact Roq support.

Service interruption?

Internet services are unstable and the design should allow for gateways to function without being able to contact the license manager.

This is done by locally caching the acquired access token. Each access token contains a valid period which takes into account what empirically should be a safe margin for interruptions.

The gateway will use a cached access token to allow operation with all features enabled until the access token expires.

Note

GW’s will terminate after access token expiry if the token can not be refreshed.

Worst case?

Contact Roq support staff and request an access token.

Is it safe?

  • The request message contains a SHA256 of the sorted set of logins. This hash does not reveal any secrets from your configuration file.

  • You generate your own public/private key pair (using roq-keygen). Nobody else can request an access token using your license if you keep your private key safe.

  • GW’s access to the license manager provide some privacy by using TLS, but it will NOT validate the certificate. If you so wish, you can intercept all communication and verify what is being transmitted.

  • GW’s can be instructed to only fetch the access token. You can then specify the config file and leave out the secrets file, if you so wish. (The important thing is that the hash of the logins match what will be used in live mode.)

What exactly is being sent?

  • Public key

  • Package name, version, build number

  • API flag (if present)

  • Service name (optionally)

  • Config hash

  • PID

  • Host description (the HOST environment variable package was compiled)

  • Kernel and operating system (equivalent to the results from this command: uname -srv)