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
Trying to handle a loss of network connection in our app I have found inconsistencies when trying to reconnect. The two ways I test loss of network are, using Apples "Network Link Conditioner" with 100% loss and pulling out the Ethernet cable. When my error delegate method (websocketDidDisconnect:error:) is called I just wait a small amount of time and call connect again on the same JFRWebSocket instance, I also call writePing: periodically when I have a connection to test its still connected. If the connection is broken by Network Link Conditioner, my error delegate method is called every time I try to reconnect until the network is restored and I can connect. But if I pull out the Ethernet cable, my error delegate method is called when the connection is broken, but when I try reconnecting again my error delegate is never called so there is no way for me to know the re-connection attempt failed and I should wait a bit and try again. I guess the second behaviour based on the method name websocketDidDisconnect:error: make senses, but then there isn't a way to an attempt to connect failed.
Is reusing the same JFRWebSocket after network loss OK or should I create a new instance all together? Maybe I should be calling disconnect on JFRWebSocket before I try reconnect? Maybe I have discovered a bug?
Thanks
The text was updated successfully, but these errors were encountered:
I have had a chance to look at this myself, the problem is a race condition with the instances variable didDisconnect, if you try to connect and it fails immediately, the method -[JFRWebSocket doDisconnect:] is called before the block to set self.didDisconnect = NO in -[JFRWebSocket connect] is called. Is setting self.didDisconnect in a queue for key value observing? If so the testing of self.didDisconnecting should occur in the queue as well.
I would provide the fix for this myself, but where I work I'm behind a very strict fire wall.
Trying to handle a loss of network connection in our app I have found inconsistencies when trying to reconnect. The two ways I test loss of network are, using Apples "Network Link Conditioner" with 100% loss and pulling out the Ethernet cable. When my error delegate method (websocketDidDisconnect:error:) is called I just wait a small amount of time and call connect again on the same JFRWebSocket instance, I also call writePing: periodically when I have a connection to test its still connected. If the connection is broken by Network Link Conditioner, my error delegate method is called every time I try to reconnect until the network is restored and I can connect. But if I pull out the Ethernet cable, my error delegate method is called when the connection is broken, but when I try reconnecting again my error delegate is never called so there is no way for me to know the re-connection attempt failed and I should wait a bit and try again. I guess the second behaviour based on the method name websocketDidDisconnect:error: make senses, but then there isn't a way to an attempt to connect failed.
Is reusing the same JFRWebSocket after network loss OK or should I create a new instance all together? Maybe I should be calling disconnect on JFRWebSocket before I try reconnect? Maybe I have discovered a bug?
Thanks
The text was updated successfully, but these errors were encountered: