Reconnecting with the Same sessionToken in the SmartFoxServer 2X JS API

[ciaoamigos]

Hi everyone,

Is there an official, documented method in the SmartFoxServerJavaScript API to “reconnect” using the same sessionToken obtained during the initial connection?

For example, is there a call like:

resumeSession()

connectWithSessionToken()

or any other API specifically for resuming an HRC+ session?

I need to handle user reconnection while preserving the exact session state and all queued messages.

Thanks!

[Lapo]

Hi,
out reconnection system only works with our TCP/UDP socket engine. However the Javascript API use Websocket which is handled by a third party tool (Tomcat) which does not support transparent automatic reconnection.

Cheers

[ciaoamigos]

Hi,

I’m integrating SmartFoxServer 2X (v2.5+) into a React Native app via a WebView. However, I’ve run into two limitations:

WebSocket transport
The JavaScript API relies on WebSockets managed by Tomcat, which do not support the same transparent, automatic reconnection that SFS2X’s native TCP/UDP client offers.

WebView backgrounding
When the app moves to the background, the WebView is suspended—closing the WebSocket and preventing any reconnection logic from running.

I need a reliable, fully transparent reconnection strategy that:

Automatically re-establishes the WebSocket connection;

Restores the user’s SmartFox session (HRC+ “frozen” state, queued messages, room memberships);

Works even if the WebView is temporarily torn down or backgrounded.

Has anyone implemented a purely JS/WebSocket solution for this scenario? Alternatively, what best practices or architectural workarounds would you recommend to emulate HRC+-style reconnection behavior?

Any suggestions on extensions, implementation patterns, or React Native bridging approaches would be greatly appreciated. Thanks!

[Lapo]

It depends on the nature of the game/application.
If you take a turn based game such as Tic-Tac-Toe or something with 4 players (say Poker) the game state is typically on the server side.
When User X disconnects from the server, nothing about the game state is lost: the server side logic can keep going by alerting the other players but at the same time allowing the next player to take their turn until it's time for User X's turn.

At that point the server recognizes that User X is still not in the Room and wait for a certain amount of time, after which it can declare the game finished, or whatever is required to handle that particular situation.

Otherwise when the player comes back the server sends the complete state of the game and waits for the next move.
From the client side the application must recognize the disconnection "background state" (should be easy) and restart the connection when the app returns in foreground.

There's one extra piece of logic. Recognizing the User at login time (on the server side) and auto-join him/her back in the suspended game Room. This should also be easy to implement:
When the client disconnects during a game, interrupting it, you can keep track of the Room that was left. This can be done with a simple data structure that maps user names to suspended game Rooms.

When a user logs in you can check the data structure and see if the User has a matching suspended game. If so you can autojoin the client back in the Room.

Cheers