game freezes when trying to connect to photon chat when internet connectivity is bad

[nevaben]

When I say game freezes, all the animation threads freeze (transition.to) and the touch events are no longer responsive.  It looks like the events  are captured and queued, because once connection gets restored all the events fire.

I think where things might be freezing is this call:  instance:connectToRegionFrontEnd

from their api docs.

http://doc-api.photonengine.com/en/chat/current/corona/doc/modules/chat.ChatClient.html#instance:connectToRegionFrontEnd

I wrapped the call in a timer.performWithDelay to put it in another thread, but, that didn’t seem to do the trick.

Has anyone experienced this situation?  Any tips on troubleshooting or fixing this?

[rob]

Hopefully the folks from Photon Cloud will respond, but generally speaking if the game freezes due to networking and you don’t want that to happen you need to wrap your network calls in a test to make sure the network is alive.  People can put their devices in airplane mode, turn off WiFi or Cellular Data, Drive through a tunnel or a host of other reasons. Your game needs to test to see if it has internet and respond accordingly (i.e. not make network requests including calls to services like Photon Cloud).

On OS-X and iOS we support the networkStatus events.  See:  https://docs.coronalabs.com/api/event/networkStatus/index.html

But for other things you have to do it the old fashioned day and ping a network server and see if you can reach it.  Such as:

local socket = require("socket") local http = require("socket.http") local ltn12 = require("ltn12") function testNetworkConnection()     print("testing connection")     if http.request( "http://google.com" ) == nil then         print("cant connect to google")         return false     end     print("got a connection")     return true end

This call is pretty fast if the network is up. I think it’s default timeout is one second, so if the network is down, you might have a momentary freeze.

I would check at startup, after a resume event and before I make a network call and popup a message telling them they need Internet to use the feature.

Rob

[nevaben]

Thanks for the reply Rob.  If the internet is not available, this problem does not happen.  Its only when the internet is on the borderline of availability, like having 1 bar of reception.  I was hoping that internet issues would not block the UI threads since for my purposes the internet is used for chatting, so ideally the chat can reconnect in the background while the user is playing the game.

I can try your suggestion to checking manually before using the photon api.  The photon api timeout seems a lot longer than 1 second so this might be an improvement.  

@rob

Hopefully the folks from Photon Cloud will respond, but generally speaking if the game freezes due to networking and you don’t want that to happen you need to wrap your network calls in a test to make sure the network is alive.  People can put their devices in airplane mode, turn off WiFi or Cellular Data, Drive through a tunnel or a host of other reasons. Your game needs to test to see if it has internet and respond accordingly (i.e. not make network requests including calls to services like Photon Cloud).

On OS-X and iOS we support the networkStatus events.  See:  https://docs.coronalabs.com/api/event/networkStatus/index.html

But for other things you have to do it the old fashioned day and ping a network server and see if you can reach it.  Such as:

local socket = require("socket") local http = require("socket.http") local ltn12 = require("ltn12") function testNetworkConnection()     print("testing connection")     if http.request( "http://google.com" ) == nil then         print("cant connect to google")         return false     end     print("got a connection")     return true end

This call is pretty fast if the network is up. I think it’s default timeout is one second, so if the network is down, you might have a momentary freeze.

I would check at startup, after a resume event and before I make a network call and popup a message telling them they need Internet to use the feature.

Rob

[ThePhotons]

Hi benchow,

Please try to pass 137.117.244.8:5058 instead of ns.exitgamescloud.com:5058 to LoadBalancingClient constructor.

I suspect that dns lookup blocks execution during socket initialization.

Note that you can’t rely on this ip in production because it can be changed anytime.

Also test if http.request( “http://google.com” ) call blocks. It have to look up dns as well.

[rob]

Hopefully the folks from Photon Cloud will respond, but generally speaking if the game freezes due to networking and you don’t want that to happen you need to wrap your network calls in a test to make sure the network is alive.  People can put their devices in airplane mode, turn off WiFi or Cellular Data, Drive through a tunnel or a host of other reasons. Your game needs to test to see if it has internet and respond accordingly (i.e. not make network requests including calls to services like Photon Cloud).

On OS-X and iOS we support the networkStatus events.  See:  https://docs.coronalabs.com/api/event/networkStatus/index.html

But for other things you have to do it the old fashioned day and ping a network server and see if you can reach it.  Such as:

local socket = require("socket") local http = require("socket.http") local ltn12 = require("ltn12") function testNetworkConnection()     print("testing connection")     if http.request( "http://google.com" ) == nil then         print("cant connect to google")         return false     end     print("got a connection")     return true end

This call is pretty fast if the network is up. I think it’s default timeout is one second, so if the network is down, you might have a momentary freeze.

I would check at startup, after a resume event and before I make a network call and popup a message telling them they need Internet to use the feature.

Rob

[nevaben]

Thanks for the reply Rob.  If the internet is not available, this problem does not happen.  Its only when the internet is on the borderline of availability, like having 1 bar of reception.  I was hoping that internet issues would not block the UI threads since for my purposes the internet is used for chatting, so ideally the chat can reconnect in the background while the user is playing the game.

I can try your suggestion to checking manually before using the photon api.  The photon api timeout seems a lot longer than 1 second so this might be an improvement.  

@rob

Hopefully the folks from Photon Cloud will respond, but generally speaking if the game freezes due to networking and you don’t want that to happen you need to wrap your network calls in a test to make sure the network is alive.  People can put their devices in airplane mode, turn off WiFi or Cellular Data, Drive through a tunnel or a host of other reasons. Your game needs to test to see if it has internet and respond accordingly (i.e. not make network requests including calls to services like Photon Cloud).

On OS-X and iOS we support the networkStatus events.  See:  https://docs.coronalabs.com/api/event/networkStatus/index.html

But for other things you have to do it the old fashioned day and ping a network server and see if you can reach it.  Such as:

local socket = require("socket") local http = require("socket.http") local ltn12 = require("ltn12") function testNetworkConnection()     print("testing connection")     if http.request( "http://google.com" ) == nil then         print("cant connect to google")         return false     end     print("got a connection")     return true end

This call is pretty fast if the network is up. I think it’s default timeout is one second, so if the network is down, you might have a momentary freeze.

I would check at startup, after a resume event and before I make a network call and popup a message telling them they need Internet to use the feature.

Rob

[ThePhotons]

Hi benchow,

Please try to pass 137.117.244.8:5058 instead of ns.exitgamescloud.com:5058 to LoadBalancingClient constructor.

I suspect that dns lookup blocks execution during socket initialization.

Note that you can’t rely on this ip in production because it can be changed anytime.

Also test if http.request( “http://google.com” ) call blocks. It have to look up dns as well.