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
See #335 for more information about implementing rpc v0.8.0-rc0 in Madara.
Request
Add a cmd-line option to set a cooldown time for websocket re-connections coming from the same IP, with the option for no cooldown (defaults to some cooldown). This should work in the following way:
When a client ends their connection, they need to wait a set time t before they can re-connect.
After t has elapsed, they are unblocked and can request a new ws connection for that method.
This should work on a per-method basis, so a client subscribing to a new ws rpc method A does not activate the cooldown for another method B, but when they unsubscribe from A they need to wait for a duration of t before they can subscribe to A again. This acts as a simple form of rate limiting, preventing excessive re-connections.
Note
It might also be worth considering banning IPs which repeatedly request to connect within their cooldown period, in which case this should be toggled via a separate cmd-line flag
Solution
Solution should be integrated into a separate param struct along with other websocket rpc arguments. See #341 and #342 for more information.
Are you willing to help with this request?
Yes!
The text was updated successfully, but these errors were encountered:
Is there an existing issue?
Motivation
See #335 for more information about implementing rpc v0.8.0-rc0 in Madara.
Request
Add a cmd-line option to set a cooldown time for websocket re-connections coming from the same IP, with the option for no cooldown (defaults to some cooldown). This should work in the following way:
t
before they can re-connect.t
has elapsed, they are unblocked and can request a new ws connection for that method.This should work on a per-method basis, so a client subscribing to a new ws rpc method
A
does not activate the cooldown for another methodB
, but when they unsubscribe fromA
they need to wait for a duration oft
before they can subscribe toA
again. This acts as a simple form of rate limiting, preventing excessive re-connections.Note
It might also be worth considering banning IPs which repeatedly request to connect within their cooldown period, in which case this should be toggled via a separate cmd-line flag
Solution
Solution should be integrated into a separate param struct along with other websocket rpc arguments. See #341 and #342 for more information.
Are you willing to help with this request?
Yes!
The text was updated successfully, but these errors were encountered: