Disconnection issues on iOS

[rafaelb149]

Hi

I looked for iOS disconnection issues while coming back from background after a short time, and I found long threads in the forum about it, but I didn't see an answer.

My issues is that our iOS clients face frequent lost connections when go to background for a short time (less than idle time). I'm using sfx objective-c version 1.7.10 (I see that there a newer version, but it seems the fixes are not relevant for our issue).

In addition, I've enabled HRC+, so when we back from BG, onConnectionRetry is first called, and onConnectioLost. I suspect server disconnect iOS only client. BTW, same test simultaneously on Android clients works perfectly (as already reported in old topics in the forum).

Please let me know if this issue was fixed and need special handling in iOS clients

Thanks!

[Lapo]

Hi,
as regards iOS vs Android behavior, it's mostly due to the OS as you can imagine which ultimately is what manages the connections and decide whether or not a connection from a background application should live or not.

Typically we recommend to keep alive the connection by sending "pings" at constant intervals. A "ping" can be just an empty Extension request. This is enough to keep a connection indefinitely unless "something else" decides to shut it down, namely the OS.
It this happens there's not much you can do other than ditching the old connection and creating a new one.

Hope it helps

[Lapo]

As regards the reconnection issues, there are cases that can't be handled.
I would recommend reading these articles on the subject, to get a better understanding of what happens behind the scenes:
https://smartfoxserver.com/blog/what-re ... tworkwifi/
https://smartfoxserver.com/blog/handlin ... e-devices/

In addition, I've enabled HRC+, so when we back from BG, onConnectionRetry is first called, and onConnectioLost. I suspect server disconnect iOS only client

No the server does not disconnect anyone. If you test in a local environment you will never see the problem happen. Typically this is due to a disconnection somewhere between client and sever (e.g. any node between the two ends)

Let me know if something is unclear

[rafaelb149]

Hi

Thanks for the quick response.
By saying send ping, you mean to develop a keepAlive mechanism, but I think that when my app goes to BG this mechanism will not keep work, no?

What about the the retry callback? do we have an indication that we have already connected but didn't get onServerConnectionLost yet, so. I will not report "retry connection"? it ruin my statistics.


Thanks

[Lapo]

Hi

Thanks for the quick response.
By saying send ping, you mean to develop a keepAlive mechanism, but I think that when my app goes to BG this mechanism will not keep work, no?

Honestly... I don't know. It depends on the OS and its version. We tested this several years ago and it did work, and so have done some of our clients. Also it depends on how the the OS manages background apps. I am not familiar with all the fine details of Android and iOS, especially since these mechanism may change from one release to another.

I'd say the only way to know exactly is to test, and you may need to test on all supported OS versions... if you want to have a complete picture.

What about the the retry callback? do we have an indication that we have already connected but didn't get onServerConnectionLost yet, so. I will not report "retry connection"? it ruin my statistics.

I am not entirely sure what you mean by this.
You're already connected but didn't get the disconnection event?

The reasons for a failure during the reconnection can be many, and it's not easy to find them out. E.g.: the half-connected situations that can occur (see the article I linked for the details of this aspect).

I'll give a simple example. Client app goes in the background and looses connection. The server notices and freezes the connection for the allowed time, however the client app is now frozen and is not going to reconnect right now, thus the server side timeout will kick in.
The client app is finally brought back to the foreground, it realizes that it needs to reconnect but it's too late and it ultimately triggers a connection lost.

[milesstone]

Hi,
as regards iOS vs Android behavior, it's mostly due to the OS as you can imagine which ultimately is what manages the connections and decide whether or not a connection from a background application should live or not.

Typically we recommend to keep alive the connection by sending "pings" at constant intervals. A "ping" can be just an empty Extension request. This is enough to keep a connection indefinitely unless "something else" decides to shut it down, namely the OS.
It this happens there's not much you can do other than ditching the old connection and creating a new one.

Hope it helps

Hi Admin, if we allow app to run in the background then can this problem be solved?

[Lapo]

Probably, but I can't guarantee, as we've never tested this specific scenario.

Let us know your findings.
Cheers

[rafaelb149]

Hi milesstone, How do you do that?

[kirito]

Hi,
as regards iOS vs Android behavior, it's mostly due to the OS as you can imagine which ultimately is what manages the connections and decide whether or not a connection from a background application should live or not..

Typically we recommend to keep alive the connection by sending "pings" at constant intervals. A "ping" can be just an empty Extension request. This is enough to keep a connection indefinitely unless "something else" decides to shut it down, namely the OS.
It this happens there's not much you can do other than ditching the old connection and creating a new one.

Hope it helps

Thanks for sharing. now i get the reason of dissconnection in the background.

[john42471]

Hi

I looked for iOS disconnection issues while coming back from background after a short time, and I found long threads in the forum about it, but I didn't see an answer.

My issues is that our iOS clients face frequent lost connections when go to background for a short time (less than idle time). I'm using sfx objective-c version 1.7.10 (I see that there a newer version, but it seems the fixes are not relevant for our issue).

In addition, I've enabled HRC+, so when we back from BG, onConnectionRetry is first called, and onConnectioLost. I suspect server disconnect iOS only client. BTW, same test simultaneously on Android clients works perfectly (as already reported in old topics in the forum).

Please let me know if this issue was fixed and need special handling in iOS clients

Thanks!

I am facing same issue form a long time so i reset my system one time. But this issue still here so if you guys found any better solution tell me here.KineMaster Mods

[lok90]

Hi

I looked for iOS disconnection issues while coming back from background after a short time, and I found long threads in the forum about it, but I didn't see an answer.

My issues is that our iOS clients face frequent lost connections when go to background for a short time (less than idle time). I'm using sfx objective-c version 1.7.10 (I see that there a newer version, but it seems the fixes are not relevant for our issue).

In addition, I've enabled HRC+, so when we back from BG, onConnectionRetry is first called, and onConnectioLost. I suspect server disconnect iOS only client. BTW, same test simultaneously on Android clients works perfectly (as already reported in old topics in the forum).GBWhatsApp


Please let me know if this issue was fixed and need special handling in iOS clients

Thanks!

Am facing the same issue..

[Lapo]

The problem with sleep mode and TCP/Websocket connections is that iOS doesn't want apps in the background to drain the battery.
Working around this issue may (or may not) be possible depending on how you design your app and what it does:

I would highly recommend reading this post from StackOverflow:
https://stackoverflow.com/questions/438 ... -ios-swift

Cheers

[kirito278]

On the stackoverflow question, the backgroundwhatsapp mod disconnection's solution is shared. Thanks for the link, Lapo. Meow. A great help.

[Lucas brown]

Hi,
as regards iOS vs Android behavior, it's mostly due to the OS as you can imagine which ultimately is what manages the connections and decide whether or not a connection from a background application should live or not.

Typically we recommend to keep alive the connection by sending "pings" at constant intervals. A "ping" can be just an empty Extension request. This is enough to keep a connection indefinitely unless "something else" decides to shut it down, namely the OS.
It this happens there's not much you can do other than ditching the old connection and creating a new one.

Hope it helps

Hi Admin, if we allow app to run in the background then can this problem be solved?

Yes,i am also using this trick .Allow this to work in background and hope problem will be solved.

[arddk]

Sometimes the server keeps getting corrupted in the iOS operating system, But right now you will not have any problem in iOS.You need to cover the phone update. WhatsApp Plus Download