You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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.
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.
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!
The text was updated successfully, but these errors were encountered:
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:
Thanks!
The text was updated successfully, but these errors were encountered: