Disconnections and Reconnections v7 - nodeGame/nodegame GitHub Wiki

• status: complete
• version: 7.x
• follows from: Automated Players

Handling disconnections (i.e., dropouts) correctly is key. nodeGame offers a standard solution and many customization options.

The first thing is to decide whether reconnections are enabled in the channel.

Reconnections are enabled/disabled in file channel/channel.settings.js:

• enableReconnections: If TRUE, reconnections are enabled (default TRUE).

• sameStepReconnectionOnly: If TRUE, reconnections are enabled only within the same game step (default: FALSE).

• disposeFailedReconnections: If TRUE, clients that tried to reconnect but failed are disposed. If FALSE, failed reconnections are treated as new connections (default FALSE). A reconnection can fail for any reason, but in particular, if:

  • parameter enabledReconnections is FALSE,
  • parameter sameStepReconnectionOnly is TRUE and the client's stage and the logic's stage are different.
  • the room in which the client was before the disconnection is no longer existing.

If reconnections are enabled, the following methods are available:

• Size handlers: pauses the game and take custom actions when the number of connected players changes,
• Push Manager: force clients to go the next step, else disconnects them.
• Reconnect Callback: initialize reconnecting clients.

Each method is described in details in the next pages.

Below is an overview of how they interact when a client attempts to reconnect.

When a client reconnects after a disconnection the following steps are taken:

1. The game room in which the player was at the moment of disconnection is looked up. If no longer existing, the client is either disposed or treated as a new connection, depending on the channel settings described above.

2. The stage in which the player disconnected and the current logic's stage are compared. If sameStepReconnectionOnly is enabled in the channel settings (default FALSE), then the client is disposed if the stages are different.

3. The client is setup again (the node.game object is recreated). Language settings are also sent, if different from English.

4. The client is initialized, but the game is not started yet.

5. If a reconnect step property is set in the logic, it is executed. If it returns FALSE, the client is disposed.

6. The reconnection options, as prepared by the reconnect callback are sent to the client, including the current value of the step timer, any modification to the plot object.

7. The client is advanced to the proper reconnecting step: either the step of in which the disconnection had happened, or the current logic's step, whichever is more ahead in the game sequence.

8. If any size-handler is defined, it is evaluated. If the number of players is still not correct, the reconnecting client is immediately paused.

To test the if your reconnections are working correctly, you can simulate disconnections and reconnections inserting the following code in any step of player.js.

node.socket.disconnect();
node.game.stop();
node.timer.random(2000, 4000).exec(function() {
    node.socket.reconnect();
});

To conditionally execute disconnections, see how to create probabilistic events with the Timer API.

To replace a disconnected player with a bot refer to the Server API.

The widget DisconnectBox can handle disconnections and reconnections directly on the browser.

• Size Handlers

• Home