-
Notifications
You must be signed in to change notification settings - Fork 6
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
Excessive traffic during connection #17
Comments
The response from the server side would be a 429 error here. |
It might be so that when a connection error occurs this loop will just restart the negotiation without any delay:
Since the NegotiationTimeout exception is supressed and that is potentially the exception that is generated in this case it will not fall back out to any outer error handling, but stay in this loop indefinitely. See also where the exception is generated:
Would be great if someone who is familiar with how the lib works would comment on this... |
After reviewing the code in more detail, my conclusion is that it is probably not the negotiation process that is the issue, it is the websockets connection that probably is restarted without any delay if the socket is closed for some (unrelated) reason. pysignalr/src/pysignalr/__init__.py Line 47 in b207c6e
|
We are using this lib with https://github.com/nordicopen/pyeasee/tree/master/pyeasee which in turn is used by a HA component (i.e. home automation system) https://github.com/nordicopen/easee_hass.
We previously used another signalr lib that is really old and has requirements that are not anymore suitable, so we changed to this lib earlier this year.
Now we are getting reports from Easee (who owns the cloud we connect to) that we are generating excessive traffic to their servers during connection process. Which causes their firewall to react and rate-limit.
In our code, we have a newer ending connection loop that has an increasing delay to prevent excessive traffic in a situation where the server would refuse connection: https://github.com/nordicopen/pyeasee/blob/537d865d9671470b6bdbf03c3eced32f6ef91221/pyeasee/easee.py#L296
But I am not sure what happens inside this lib when this happens, does it have an internal retry logic? If so, can we control how it behaves somehow?
The text was updated successfully, but these errors were encountered: