Skip to content
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

Disconnect callback not being triggered as soon as possible #401

Closed
hishnash opened this issue Oct 9, 2017 · 7 comments
Closed

Disconnect callback not being triggered as soon as possible #401

hishnash opened this issue Oct 9, 2017 · 7 comments

Comments

@hishnash
Copy link
Contributor

hishnash commented Oct 9, 2017

I have noticed that the didDisconect callback is only sent after I try to send another frame. However, if I pole isConnected i can detect that we have disconnected long before any notification is sent. Is this intended?

@fassko
Copy link
Collaborator

fassko commented Oct 10, 2017

I've seen this as well. Does it call didDisconnect for you if you PING the server?

@hishnash
Copy link
Contributor Author

hishnash commented Oct 10, 2017

yes if I send a ping or any frame I get the callback.

@acmacalister
Copy link
Collaborator

mmhm, I haven't seen that myself. Do a code example I can try? Also can you share what WebSocket server you are using?

@fassko
Copy link
Collaborator

fassko commented Oct 20, 2017

Here is my test case app https://github.com/fassko/websocket-test

There are schemes for Apple TV and iOS. Just start it up and disconnect WiFi and websocketDidDisconnect isn't fired.

@acmacalister Do you know in details how CFStream works and how it gets notified if network is lost for instance? Before I dig deeper into Apple docs.

@fassko
Copy link
Collaborator

fassko commented Oct 20, 2017

As far as I went is that if I disable WiFi on my computer StreamDelegate newBytesInStream nor streamDidError isn't being called. Could it be bug on Apple side? Or it shouldn't be called at all? And all the network interruption should be processed somehow differently?

@daltoniam
Copy link
Owner

Alright, I did some digging on this. The case I'm seeing is as @fassko describes, you are connected to a remote host, then disable the wifi on your device and it doesn't detect the network is down. I think this is by design from Apple because it won't know the difference between a temporary interruption (which can happen often) or the network being down. This is why disconnect then fails after a new frame is written, it attempts to stimulate the socket and finds it can no longer write to it then disconnects after the write timeout. This is a pretty specific edge case and I would either implement the reachability APIs and have preferred timeout of notifying a disconnect or just send a ping to the server on an interval you feel is appropriate for your app. That way you are only disconnected for the shortest time interval you expect.

@eliburke
Copy link

I was working on some reachability related issues just yesterday (in conjunction with ashleymills/Reachability.swift).

An issue to be aware of.. if you are using reachability to detect that the connection has gone away and call socket.disconnect, you should use the forceTimeout parameter to immediately close the socket. Otherwise, in cases when the network connection is re-established before the timeout expires, you can get a websocketDidDisconnect notification when the connection is actually online!
(this is not a problem with Starscream... just a pifall)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants