Disconnect callback not being triggered as soon as possible

[hishnash]

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]

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

[hishnash]

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

[acmacalister]

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]

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]

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]

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]

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)