-
Notifications
You must be signed in to change notification settings - Fork 11
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
Leaked connections when trying to connect to a high latency server #7
Comments
@jlcvp I'm trying to test this library with one of my projects and I found that it is creating 6 connections at a time. Is this because of this code snippet? |
I think we need to remove the reconnect code. I will remove it and let the ios developer himself be responsible for this |
@nerzh Which reconnect code? |
disable reconnect
passing the parameter false. Next, implement the logic that suits you. You will need to monitor the connection and, in case of a break, reconnect manually by calling the connect method.
|
I’m using this for live chat, can you please give some basic idea for how to implement logic to monitor connection? |
you have a bunch of connection lifecycle callbacks. Implement your logic, what to do if the connection is broken or for some reason the ping stops coming, etc. All servers are different, they work differently, so it’s difficult to write a universal reconnection. At the moment you say you have 6 connections, I don't know how you counted that, but if that's the case, then implement the reconnection logic yourself that will do what you want. To do this, handle all situations in which the connection was interrupted |
these callbacks should help you
|
This following snippet of code in the project is creating multiple connections when connecting to high latency servers. The while loop calls
self.client?.connect
again (thus, creating another websocketclient) if the first call takes more than200 + self._checksDelay
millis to connect/failAction-Cable-Swift/Sources/ActionCableSwift/Helpers.swift
Lines 155 to 162 in ebb9986
The problem with this busy wait approach is that we don't have a way outside this library code to manage those connections and terminate the duplicates if needed.
I think we Should try to use a Lock before the
if !self.isConnected() {
check to do this verification only after the connection handshake itself. That way we would have only 2 states possible (connection successful or connection failed), hence avoiding the duplicatesThe text was updated successfully, but these errors were encountered: