SFS2X Docs / GettingStarted / reconnection-hrc-plus
» Reconnecting with HRC+
Since SmartFoxServer 2X version 2.5 (and higher) we have introduced an improved version of the High Resilient Connection system, HRC+, which enables players to re-join the server after a sudden disconnection without loosing their current state.
In this article we're going to discuss the ways in which HRC+ can save a lot of development work, how it is done technically, and learn how to configure and test it.
NOTE: HRC is not available for HTML5/WebGL clients.
» Why was I disconnected?
Unexpected disconnections are a very rare occurrence when developing and testing in a local network but, as we finally go online, several nasty things can happen that may affect the game connection.
The main reason why a connection is dropped without notice is traffic congestion. The player connection usually travels through dozens of network nodes to get to his destination, and each of these links can be a potential point of failure. In fact, if any of these routers and gateways get overwhelmed with traffic they can either respond too slowly, be forced to drop packets or get reset, thus causing a stall and ultimately a disconnection.
If we add to the mix WIFI and mobile connections the scenario becomes even more delicate, as a drop in the strength of the signal can cause an abrupt disconnect from the game server.
All these situations are handled primarily at the low level, in the operating system's TCP stack which in turn dispatches events at the application level, where other programs can react. SmartFoxServer 2X is no exception in these regards, and it heavily depends on those low level notifications.
Later in this article we will see what might happen if some of those events are not fired in a timely fashion.
» HRC+ to the rescue
HRC+ is a unique feature provided by SmartFoxServer 2X, that helps building more robust multiuser games allowing players to transparently return in the game without loosing their state.
The diagram below illustrates what happens when a player is suddenly disconnected from the server:
Starting on the left side we have three users connected to SFS2X, all playing together as Player A, B, C in the same Zone. Suddenly User B looses its connection, the Player object on the server is frozen and all the messages that are being sent to him are stored in a queue.
Meanwhile the client side API are attempting to establish a new connection and the other Players can continue with their game, knowing that User B is trying to jump back in.
On the right side of the diagram Player B is finally reconnected. The new session is linked with the old Player object, the client is updated with all the queued messages, and the other players are notified that B is back. The exciting part is that during all these phases the game flow is not interrupted and all the complexity of the reconnection is hidden from the developer.
» What might go wrong
Not all disconnections are made equal. There can be a minority of cases in which the disconnection can remain in an incomplete state for some time, thus not triggering the reconnection system.
We have dedicated an entire section of our documentation to the problem of ghost connections, which is our way of calling an "half-closed" TCP connection. Without going into too much detail, the TCP protocol employs several message exchanges in order to disconnect the client and server. In case the network becomes suddenly unavailable to one side, this exchange cannot be completed and the TCP connection can remain in a "waiting" state for a certain amount of time.
Typical causes of this occurrence are pulling the network cable from the computer or a sudden loss of signal in the WIFI interface or mobile connection. In all these cases it is possible to end up with a ghost connection, where the TCP socket is still waiting for the close operation to be completed.
Why is this so relevant for the HRC+ function? It is critical because a TCP socket in this state won't notify any disconnection event at the application level, and therefore SmartFoxServer will remain unaware of this new condition. Eventually the TCP timeout, or the SmartFox idle socket timeout, will trigger (depending on which fires earlier) and the disconnection event will be dispatched.
» Proper ways of testing disconnections
Counterintuitively unplugging the network cable or shutting down the WiFi connection will not generate a sudden disconnection that can be used for testing.
In fact you can monitor your computer's connection using the netstat utility (available on Windows, Mac and Linux) before and after unplugging the cable and you will be surprised to see that nothing has changed!
IMPORTANT: do not attempt to test the reconnection system by pulling the ethernet cable or shutting down the WIFI connection. Both operations will not terminate your current socket connections and therefore the disconnection event will never be triggered.
Instead follow the directions that we provide in the article entitled "The Connection Phase" that is linked in the section below.
» Further readings
- More information on how to configure and test HRC+ are found in the article The connection phase, from our Development Basics section.
- In order to learn more about how the TCP/IP handles disconnections you can read this external article.