Rate Limiting of Queries to SD, UT, etc.

if one does several queries via skywire-cli to service discovery or uptime tracker (or any http endpoint of any service) in short succession, it's likely that a rate-limit will be hit.

One thing we could do is to remove the rate limit for queries that come from visors

i.e. if skywire-cli proxy list or skywire-cli ut makes an rpc call to the running visor, and the visor queries SD or UT then don't rate limit the request.

However; the rate limit may not be directly configured in the SD, UT, etc. currently. it may be part of the load balancing setup or otherwise not directly configured.

Cached Responses

Another alternative would be to cache responses to such queries for a period of time, in such a way that subsequent queries will fall back on the cached response until the rate-limit is no longer expected to be encountered.

The visor may need to handle this, as it's running as a daemon.

But if the cli is used apart from a running visor, there would be no way to clean up any cached file which was created except for it to be manually removed.

The dataset in question is so small that i doubt it should cause any concern to leave files in the userspace.

Perhaps a better alternative, a temporary file may be written by the cli to /tmp and it will be removed on the next boot automatically.

Perhaps it's best to implement this as a flag which specifies to --cache the response, and the duration or age of the cache to be used, in minutes. Default to the query interval of the visor to the uptime tracker (5 minutes)

Note: this behavior should not be the default behavior.

if the --cache flag is used with no argument, default to 5 minutes. (?)
if the --cache flag is not used, do not cache the response
if the --cache flag specifies an integer, update the existing cached response if it is older than that integer in minutes

Overview of Proposed Behavior

A query is made to SD via skywire-cli

$ skywire-cli proxy list -c US --cache 5

the raw response must be written to a specific temporary file with a hardcoded filename in a hardcoded named subdirectory of /tmp
the whole dataset must be fetched, not a partial response as we do currently via filtering
skywire-cli then filters the cached response appropriately, according to any other flags.

Then, on any subsequent query:

$ skywire-cli proxy list -c US --cache 5

check the age / existence of the temporary file containing the response.
if the file containing the cached response is not older than the time specified by the --cache flag: read the cached response from file
if the file is older than the time specified by the --cache flag: make a new query and update the cached file
do not look for or read from cached response if --cache flag is not set

Custom SD / UT address or file

For service discovery queries, we need a flag for setting an alternative service discovery address to query. We currently have this for the uptime tracker only
For any service or service discovery, we should be able to specify a file which represents the response that would be given by that query.

Then the user can manage keeping those files synced on their own, if desired.

skycoin / skywire

Address rate limiting of queries to SD, UT, etc. via response caching #1713

Rate Limiting of Queries to SD, UT, etc.

Cached Responses

Overview of Proposed Behavior

Custom SD / UT address or file

Related issues