smockron
smockron copied to clipboard
arodland
Distributed HTTP rate limiting for nginx and node.js using ZeroMQ and redis
ZeroMQ has done a great job so far, but it has a few issues. 1. The client library isn't completely trustworthy, and some people (@silas) aren't comfortable with embedding libzmq...
Support something like [this](http://amattn.com/p/weighted_credit_pools_for_api_rate_limiting.html) where you have an overall rate of tokens/sec, but different requests can cost different numbers of "tokens", so a client can make many cheap requests, or...
A gatekeeper should be able to ask the master to bring it up to date on _all_ outstanding blocks and the master should send it.
(like twitter `X-Rate-Limit-Remaining`). Requires the master to publish some kind of message other than `DELAY_UNTIL` on the control channel to interested parties.
At the cost of lots of extra control messages, we could enforce an absolute minimum time between requests from a client, which would place an upper limit on how bursty...
It would be possible for a gatekeeper to run part or all of the same throttling logic as the master, on the assumption that it is the only gatekeeper that...
If the server receives a bunch of DELAYED accounting messages for a client after it has already published a DELAY_UNTIL command for that client, it will send a new DELAY_UNTIL...
Add some means of finding out: [ ] Whether the server is responsive [ ] Whether the redis connection is up [ ] Other things I haven't thought of yet
Add some way of finding out identifiers of clients who have made the most requests to the domain over some period of time.