Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cleint limitations #13

Open
2 of 5 tasks
orbitlens opened this issue Oct 11, 2019 · 3 comments · Fixed by #37
Open
2 of 5 tasks

Cleint limitations #13

orbitlens opened this issue Oct 11, 2019 · 3 comments · Fixed by #37
Labels
feature New feature or request
Milestone

Comments

@orbitlens
Copy link
Contributor

orbitlens commented Oct 11, 2019

We need to implement basic rate-limiting features and max resource policy for clients.
Configuration options:

  • Max requests per 5 seconds timespan (e.g., max 10 requests per any 5s timespan).
  • Max requests per minute (e.g., no more than 30 requests per minute).
  • Max requests per hour (e.g., up to 1000 requests per hour).
  • Max open orders - maximum number of outstanding orders on exchanges.
  • Withdrawal requests limit per day (for example, no more than 50 withdrawals within any 24h timespan).
@orbitlens orbitlens added the feature New feature or request label Oct 11, 2019
@orbitlens orbitlens added this to the alpha milestone Oct 11, 2019
@s-a-y
Copy link

s-a-y commented Oct 13, 2019

Requests rate limiting is usually better done by reverse proxy, like nginx or even cloudflare.
Max open orders and withdrawal request limits are the real features here.

@orbitlens
Copy link
Contributor Author

@s-a-y

Requests rate limiting is usually better done by reverse proxy, like nginx or even cloudflare.
Max open orders and withdrawal request limits are the real features here.

Yep, it's the best option for HTTP or REST in most cases, but

  1. We are using WebSockets, and reverse proxy are usually only slow down things with such setups.
  2. This project is supposed to be used by different organizations, so we strive to minimize total number of dependencies and avoid third-party vendor locks.
  3. Those settings are supposed to be configurable in runtime. If constellation members agree on changing current limits, the system should automatically apply them, which may be problematic with external reverse proxy.
  4. Constellation members might want to set custom limits on per-account basis. For example, for market makers, payment systems, or HFT traders. It's one of the potential financial incentives to run a constellation.

Anyways, thanks for your suggestion, your professional opinion is much appreciated as always. Please let me know if you spot any other inconsistencies.

@s-a-y
Copy link

s-a-y commented Oct 17, 2019

Sure, they way you describe it - makes perfect sense.
I haven't initially thought you want control on account-level or system-wide settings.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants