-
Notifications
You must be signed in to change notification settings - Fork 117
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 Limit Module #124
Comments
I have been trying to implement this feature, but it looks like AutobahnJS doesn't allow setting extra parameters during connection. However, I believe, we can set this for individual procedure registrations. Does this make sense? |
What are the use-cases for rate-limiting? Is this a limitation of caller or the callee? How does this interact with with different invoke types? |
One use case (that I could think of) is where we have callees with different capabilities. They would register by effectively defining their own processing capabilities. As far as the interaction with the invoke types are concerned, I believe these are disparate. Rate-Limiting (Throttling?) is valid for a single Registration. Invoke types are only valid till the Procedure layer. Individual Registration objects will throttle their own calls and won't be concerned with the rest of the system. I believe, they should only be responsible for making sure that the Callee is not overwhelmed with calls beyond what is specified. |
There are two areas: 1 - Prevent the router from being overloaded. For example, if an RPC makes a call to itself, it'll cause an endless loop. At the very least, we can set some global limits that drop connections if a session exceeds the limit. 2 - The client should be able to set their own limits when they register an RPC, since it's most aware of their own system resources. |
As far as protecting the router from overload - this should be done in the router at router startup and it should maybe be a global RPC limitation. If the Callee wants to rate limit, adding an option to the registration is the place to do it. I do think that there is some consideration for how it interacts with the invoke type. If a Callee is rate limited on a round-robin invoke type, wouldn't you want the RPC to go to the next Callee that is not rate-limited? |
Taking the round robin example, wouldn't that beat the purpose of a round robin registration? I think this stands for the others as well. _thruway registrations are rate limited by default owing to their invocation logic. For random something like this may work as a camouflage over random invocations. |
Implementing at the Registration level sounds good to me for rate limiting on the Callee side. |
Add the ability to rate limit all WAMP actions per session. We should be able to reject or throttle calls depending on the circumstances. If an action is rejected, a WAMP error should be returned to the user.
Limits can be something like:
'rpc_limit' => 100
- 100 calls to any one RPC procedure in one minute for a session'all_rpc_limit' => 500
- 500 calls to any RPC procedure in one minute for a sessionMight also be good to have some global limits.
The text was updated successfully, but these errors were encountered: