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

Rate Limiter features/discussion #132

Open
GeorgeF0 opened this issue Mar 11, 2022 · 1 comment
Open

Rate Limiter features/discussion #132

GeorgeF0 opened this issue Mar 11, 2022 · 1 comment
Labels

Comments

@GeorgeF0
Copy link

Hi Jan, thanks for all your work so far, I'm now using quite a few of your exchange libraries! 👍 I've noticed a couple of things about rate limiters, so I wanted your thoughts on these:

  1. Rate limiters assume they have exclusive access to the exchange. The rate limiters are configured with a weight and then rely only on the user's requests to determine if the user has passed the limit or not. This assumes that the process the rate limiter is running in is the only process that connects to the exchange. Some exchanges have limits per IP or API key, which are things that multiple processes can share (for example one C# service handles trading and another handles back-office stuff like withdrawals and transfers, both using the same API key or IP). To tackle this issue, some exchanges (Binance and Huobi for example) return a header indicating the current or remaining weight of their rate limits (including other things like the server time). The status code of the request can also be used to inform the rate limiters. I think it would be a good idea to make the rate limiters aware of feedback given by the exchange to correct their course.
  2. It would be nice if rate limiters fired events (a C# event or an Action) every time they "tick" or update, to indicate the current weight used, total weight used, and any other relevant information. This data can then be used to monitor the rate limits, for example they can be streamed to a UI or logged in a metric aggregator like Prometheus or InfluxDB and monitored on Grafana.
  3. The definition of a "time period" may be different from one exchange to another. If I understand correctly, your code assumes a rolling/sliding time window. I believe Binance for example, uses an absolute/tumbling window. For example, if you have a 1000 weight limit over 1 minute, you can do a bunch of requests at 10:00:59 that reach the limit and then at 10:01:00 you can go again, whereas with a sliding window you'd have to wait until 10:01:59 to try again. I think this makes the sliding window more conservative, which is arguably better or at least safer, but I thought I'd bring it up in case you have any thoughts on this.
    Thanks!
@github-actions
Copy link

No activity on this issue for 60 days. This issue will get closed if it receives no update within 14 more days.

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

No branches or pull requests

2 participants