Question Regarding HCR Reconnection Behavior After Upgrading to SFS 2.16

[Flyingfish01]

Hello,

We are currently upgrading our legacy SmartFoxServer from version 2.9 to 2.16, and we have encountered an issue related to HCR (High-Availability Connection Recovery).

In the new 2.16 version, the “User Reconnection Time” is configured to 60 seconds, the same as in version 2.9.

In version 2.9, when we disabled Wi-Fi and then re-enabled it, the client was able to reconnect successfully within the reconnection window. However, after upgrading to 2.16, the client is no longer able to reconnect using the same Wi-Fi disable/enable test.

We have seen the official documentation mentioning that turning off Wi-Fi should not be used to test reconnection. However, it is unclear why this method worked correctly in 2.9 but does not work in 2.16.

Could you please clarify whether this behavior is expected in 2.16? Has there been any change in session handling or HCR implementation between these versions?

Code: Select all

This is the server log.
8 Feb 2026 | 23:51:08,085 | INFO  | SocketReader | bitswarm.sessions.DefaultSessionManager |     | Session created: { Id: 2, Type: DEFAULT, Logged: No, IP: 10.122.81.51:27931 } on Server port: 9871 <---> 27931
08 Feb 2026 | 23:51:08,086 | WARN  | SFSWorker:Sys:4 | controllers.v290.SystemReqController |     | com.smartfoxserver.bitswarm.exceptions.SessionReconnectionException: Session Reconnection failure. The passed Session is not managed by the ReconnectionManager: java.nio.channels.SocketChannel[connected local=/10.122.80.103:9871 remote=/10.122.81.51:27931]
        com.smartfoxserver.bitswarm.sessions.DefaultReconnectionManager.reconnectSession(DefaultReconnectionManager.java:155)
        com.smartfoxserver.bitswarm.sessions.DefaultSessionManager.reconnectSession(DefaultSessionManager.java:373)
        com.smartfoxserver.v2.controllers.system.Handshake.execute(Handshake.java:68)
        com.smartfoxserver.v2.controllers.v290.SystemReqController.processRequest(SystemReqController.java:172)
        com.smartfoxserver.v2.controllers.v290.SystemReqController.enqueueRequest(SystemReqController.java:127)
        com.smartfoxserver.bitswarm.io.protocols.AbstractProtocolCodec.dispatchRequestToController(AbstractProtocolCodec.java:39)
        com.smartfoxserver.v2.protocol.SFSProtocolCodec.dispatchRequest(SFSProtocolCodec.java:133)
        com.smartfoxserver.v2.protocol.SFSProtocolCodec.onPacketRead(SFSProtocolCodec.java:90)
        com.smartfoxserver.v2.protocol.binary.BinaryIoHandler$1.run(BinaryIoHandler.java:477)
        java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
        java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
        java.lang.Thread.run(Thread.java:748)

Code: Select all

This is the reconnection log from the client demo test.

17697 [New I/O client worker #1-1] INFO sfs2x.client.bitswarm.BitSwarmClient - Reconnection attempt:1 - time left:60
17710 [Thread-1] ERROR sfs2x.client.core.sockets.TCPSocketLayer - TCPSocketLayer: Socket error: Connection reset
17710 [Thread-1] INFO sfs2x.client.bitswarm.BitSwarmClient - Reconnection attempt:1 - time left:59
18714 [Thread-1] WARN sfs2x.client.core.sockets.TCPSocketLayer - TCPSocketLayer: Calling connect when the socket is not disconnected
28789 [Thread-4] ERROR sfs2x.client.core.sockets.TCPSocketLayer - TCPSocketLayer: Socket error: connection timed out
28789 [Thread-4] INFO sfs2x.client.bitswarm.BitSwarmClient - Reconnection attempt:3 - time left:48
39918 [Thread-6] ERROR sfs2x.client.core.sockets.TCPSocketLayer - TCPSocketLayer: Socket error: connection timed out
39918 [Thread-6] INFO sfs2x.client.bitswarm.BitSwarmClient - Reconnection attempt:4 - time left:37
40960 [New I/O client worker #4-1] INFO sfs2x.client.controllers.SystemController - Message: ResReconnectionFailure { Message id: 1006 }
{ Dump: }
[ Empty SFSObject ]

Thank you for your assistance.

[Lapo]

Hi,

We have seen the official documentation mentioning that turning off Wi-Fi should not be used to test reconnection. However, it is unclear why this method worked correctly in 2.9 but does not work in 2.16.

Most of this depends on "luck", but generally speaking it will not work.
As outlined in the documentation, the act of turning off Wifi (or unplugging a physical ethernet cord) will not result in a disconnection, because an actual TCP disconnection consists of a multi message exchange between the two parties. Since no communication can occur when shutting down the WiFi, nothing happens on both sides. Both client and server think the connection is still open and active. In fact if you turn WiFi back on fast enough, you will find that previous open connections still work as if nothing happened.

On the other hand if too much time passes the OS will shut down the connection since no traffic is detected.
This OS-level timeout mechanism is not synchronized, especially on different operating systems. Meaning that it is very likely that one side will shut down its connection earlier or later than the other, adding extra issues to the possibility of re-establishing a connection.

That's why we emphasize that our reconnection system will likely not work under these conditions. What is best is to detect the network shutdown from the application itself, if possible and handle it as a separate case: by closing the current connection and starting a new one when the network comes back. This should be possibile on most mobile devices, via their native API.

Cheers