Switching from Wifi to 3G data
Options
Hi,
we are testing using iPhone devices. When player played the game in a wifi network, and then slowly walk away from the wifi spot, the phone switches to the cellular data network. In this case, photon gives a SC_SEND_ERROR(1030) error. However, we never receive any SC_TIMEOUT_DISCONNECT or disconnect error, as a result our game logic goes into this weird state where it thinks it's still connected but it couldn't send any outgoing command or receive any event.
should we also get a disconnect error in this case as well? or should I treat SC_SEND_ERROR as a disconnect error as well?
KevinB
we are testing using iPhone devices. When player played the game in a wifi network, and then slowly walk away from the wifi spot, the phone switches to the cellular data network. In this case, photon gives a SC_SEND_ERROR(1030) error. However, we never receive any SC_TIMEOUT_DISCONNECT or disconnect error, as a result our game logic goes into this weird state where it thinks it's still connected but it couldn't send any outgoing command or receive any event.
should we also get a disconnect error in this case as well? or should I treat SC_SEND_ERROR as a disconnect error as well?
KevinB
0
Comments
-
Are you able to send and receive again without a reconnect after the OS has switched to cellular?0
-
no,
when I try to send again, I got this error log
ERROR PeerBase.cpp opCustom() line: 236 - failed - call Connect() first!
looks like the Photon library internally thinks it's disconnected, but the disconnect msg isn't propagate all the way up?
KevinB0 -
in fact, I can repro this by simply using iphone simulator, run the app, then turn off wifi on my mac.
K0 -
Not sure about the native lib's connect() but in DotNet we return true/false. If connect returns false, there won't be a disconnect callback (as it failed to even try to connect).
Stefan will be here in a while and fill in the gaps I have with native code
0 -
That's also true for the native clients, but it isnt' relevant here, as KevinB can successfully connect and send data around and then later on, when leaving the range of the Wifi to which he is connected, gets this SEND_ERROR.Tobias wrote:Not sure about the native lib's connect() but in DotNet we return true/false. If connect returns false, there won't be a disconnect callback (as it failed to even try to connect).
Stefan will be here in a while and fill in the gaps I have with native code
@KevinB:
I will try to reproduce this and have a look whats going on.0 -
Just checked with the demo and the simulator turn off wifi procedure:
I am immediately getting send errors and after 10 seconds (the default client side retry time) I am getting a timeout disconnect and disconnectReturn() gets called.
EDIT:
We have now built in that (at least for the simulator repro-case, didn't test on device) an immediate disconnect gets triggered when the wifi-connection gets lost.
That fix will be available together with the one for the gethostname() issues with the next release.
Are you fine with updating to 3.2 for those fixes?0 -
did you mean the next release is 3.3? coz 3.2 is the current available version.
i am definitely not seeing disconnectReturn gets called for the simulator wifi turn off scenario. did u mean the current version will encounter this issue while the next release will have this fixed?
if u can send me the pre-release sdk, I can help u test the gethostname issue and the wifi issue as well just to confirm these are fixed.
Thanks!
K0 -
Afaik you are currently on 3.0.4.4, aren't you? There have quite some changes been made between 3.0.4.x and 3.2.0.x, thats why I am asking.
The next public release will probably be 3.2.4.0, which will also include all the changes between 3.0.4.4 and the current public version 3.2.2.0 + some not yet released changes.
It would save us some work if we don't have to merge those fixes into a 3.0.4.5 release.
"i am definitely not seeing disconnectReturn gets called for the simulator wifi turn off scenario. did u mean the current version will encounter this issue while the next release will have this fixed?"
I have seen it getting called 10 seconds after the sendError with the code before implementing that fix, but I have tested with 3.2.2.1, so maybe some older change has already fixed that part. With the fixed version it will get called immediately after the connectError as which the sendError will get treated in that case from now on.
I will see if I can supply you with a prerelease early next week.0
