socketDidDisconnect not to be call on iOS6

[momor]

It always be called on iOS5,but when I test it on iOS6 ,it doesn't work.
I tried connect to a TCP sever using GCDAsyncSocket,when I stop sharing Internet over WIFI,I found CFReadStreamCallback and CFWriteStreamCallback not to be call.There is not any error event.

[ObjColumnist]

It seems to be that the CFReadStreamCallback and CFWriteStreamCallback don't get called on iOS 6 but I cannot work out why.

[bluemoon]

I noticed this as well, is it something that was introduced in iOS6?

[ObjColumnist]

That could be the reason, but my suspicion is that the callbacks are being removed.

[adozenlines]

Reading from the Apple Docs the call back method is non-static & callback parameter of "CFRead|WriteStreamSetClient" doesn't take the address of the callback function via the ampersand.

https://developer.apple.com/library/mac/#documentation/Networking/Conceptual/CFNetwork/CFStreamTasks/CFStreamTasks.html

CFOptionFlags registeredEvents =...;

CFReadStreamSetClient(myReadStream, registeredEvents, myCallBack, &myContext)

//non-static
void myCallBack (CFReadStreamRef stream, CFStreamEventType event, void *myPtr)

** tested with client & server ** works like a charm when the small changes above are made.

[bluemoon]

That seems to work, but what's interesting is the fact that even as a reference hasbytesavailable will still call it

[adozenlines]

on "onDidConnect" (line:2455) =>No but for a TLS (line:6614) connection "kCFStreamEventHasBytesAvailable" is make part of the call back condition.

[ObjColumnist]

For me (using the XMPPFramework) simply changing the callbacks to be non static and passing in the callback function without & didn't fix the issue for me.

Is there something that I have missed?

Also something I have noticed, if I successfully connect to my XMPP Server, turn on Airplane mode, turn off Airplane mode, then send a XMPP Element the server receives it correctly as if socket never lost its connection.

[adozenlines]

The test here was based on targeted iOS 6 vs the behaviour of targeted iOS 5 build were on random instances the callback will sometimes work correctly under iOS 6.

Sent from my iPhone

On 2013-03-19, at 6:18 AM, Spencer MacDonald notifications@github.com wrote:

For me (using the XMPPFramework) simply changing the callbacks to be non static and passing in the callback function without & didn't fix the issue for me.

Is there something that I have missed?

Also something I have noticed, if I successfully connect to my XMPP Server, turn on Airplane mode, turn off Airplane mode, then send a XMPP Element the server receives it correctly as if socket never lost its connection.

—
Reply to this email directly or view it on GitHub.

[jonasman]

So what did you change to make the socket to work in ios6?

I also changed this line: CFReadStreamSetClient(readStream, readStreamEvents, &CFReadStreamCallback, &streamContext)
to : CFReadStreamSetClient(readStream, readStreamEvents, CFReadStreamCallback, &streamContext)

But still the connection takes a lot to realise it was disconnected

I did the same change to CFWriteStreamSetClient(writeStream, writeStreamEvents, &CFWriteStreamCallback, &streamContext)

[ArcasGuo]

hi,momor have u got the reason why it doesn't work on iOS6.
it still not callback on my proj.

thx

[jonasman]

any news on this?

[akashrastogi2]

Anyone solved this issue?

[robbiehanson]

Some thoughts on this matter:

This may be solve-able using a bit of network reachability code within GCDAsyncSocket.

As it stands right now, GCDAsyncSocket always creates a CFReadStream & CFWriteStream. One of the main reasons for this (if I remember correctly) was simply to get these specific disconnect notifications. As in, if the socket is closed normally (via TCP mechanisms, e.g. server closes socket, sends FIN), then we get the disconnect via the normal dispatch event(s). However, if the socket was closed abnormally (via loss of WiFi, or iOS force closed it because app was backgrounded, etc) then we didn't get the normal disconnect via dispatch event. And the code was dependent upon the CFStream event to notify it.

Which means that if this is no longer working, we can skip creating the CFStreams, and potentially speed up the socket. (And we'll use network reachability in its place to notify us of abnormal events such as loss of WiFi.)

(Obviously, we'd still need to create the CFStreams for certain situations, like for backgrounded sockets.)

Please keep in mind that I'm theorizing all this. It would require a fair amount of testing to determine if this would actually be a valid solution...

[gresrun]

@robbiehanson Any love for this bug? I believe we're experiencing this in low WiFi signal environments.

[buffpojken]

@gresrun I believe we are too.

We're seeing very odd behaviour (using GDAsyncSocket for communication over STOMP), and in some conditions (i.e. when wifi signal is dropping below a yet undetermined threshold), the socket is properly closed (as determined by the server) - but the delegate is never informed that the socket has been closed, and thus can not trigger a reconnect or similar.

[github-actions]

This issue has been marked as stale, it will be closed automatically if there is no further activity.