Sorry for all these best practices questions, hopefully they are of use to others as well
I’ve been trying to figure out how to handle reconnecting in between play sessions (when the game isn’t terminated). And have narrowed it down to three approaches.
Always close the socket when the game loses focus, reconnect when it gets focus
Let the socket connections time out (not sure when a socket closes if you dont close it manually?), when the game gets focus, test the socket and reconnect if needed.
Always pretend the socket is working, reconnect only when it reports an error
If I can get a quick sanity check here that would be very appreciative, all the sample projects are great but none handle cases like these as far as I can tell, that are still common things mobile gamedevs deal with.
IMHO, your first approach might put extra pressure on your servers at scale and complicate your client logic if the interval between the two sessions is usually short; I assume that it is quite normal for a game to lose focus when a player, e.g, gets a text message and goes for a quick reply, and the socket may still be connected upon player return.
As for your next approaches, they both seem valid to me. But you might wanna get a second opinion on this.
Thanks for your input. Yeah, maybe we’ll go with option 2 or 3 for now. Trying to get the ideal setup going, kinda wished this was built into the unity plugin.
@nixarn The best approach to use is option 1. The determinism you create with the socket lifecycle when you manually disconnect and reconnect the socket is very useful.
It creates consistency that is otherwise very hard to achieve given that different device platforms (iOS, Android, various versions of Android) detect half-closed TCP sockets at different rates and even with the socket heartbeat messages we send to check the socket liveliness these can sometimes be delayed as they’re buffered at the netstack level of the operating system in the specific device platform.
your first approach might put extra pressure on your servers at scale and complicate your client logic if the interval between the two sessions is usually short
The first part of the advice that @Mahdad-Baghani gave (thanks for the help!) isn’t of concern I think because the game server is optimized for hundreds of thousands of socket connections and we’ve load tested it for some of the largest games companies in the world at massive scale.
The second part that was mentioned is the real challenge with option 1. It can be more complex to handle the intentional transient disconnect flow inside the game client logic than if you rely on the other options. IMHO though its worth the effort to get right and give a really graceful experience to the player.
