In UE, our customers MUST specify a UserSlot as the "Main" slot (the owner of the game). That player’s connectivity defines the connectivity for the entire local client.
Connectivity is tracked through our WebSocket connection established at sign in time. If the connection fails to connect OR gets closed due to connection issues, we try and verify that we CAN reach some open endpoint (typically google, selected from a list of configurable high-availability endpoints). If that fails, we go into our Connectivity Loss Handling with “No Internet Connection”. Otherwise, we fail with “Beamable Server could not be reached“. The Connectivity Handling flow is the same either way, but its nice for us to be able to differentiate between these.
Connectivity Loss Handling
Users should be able to configure how they want to handle connectivity losses in the SDK. Options are:
Offline Mode: When offline mode is supported, the SDK will enter offline mode (see below for details); two hooks are exposed, before entering Offline mode and after the mode was successfully entered and configured. Recovery is an async process that makes requests which means you can end up entering offline mode during the recovery from Offline mode. This means we need a Concat-able DAG of actions that is aware of how much of it has been applied to and accepted by the backend; we also need ways to invalidate future requests in case one of them fails (due to something other than connection issues).
Trigger Callback: When Offline Mode is disabled for your game, you just get an exposed hook in UBeamRuntime for handling this connection loss. After entering no-connection mode, any request that is poised to be enqueued for retry should fail instead.
Connection loss is handled as part of a UBeamBackend connectivity tick function --- UBeamNotification system that manages the websocket connections will flag connectivity as lost when it closes due to a connection failure and the beam backend's tick function listens for that kind of thing of both the OwnerPlayer User Slot as well as the MainEditorDeveloper User Slot. Editor systems care about connectivity from the perspective of the MainEditorDeveloper user and UBeamRuntime from the OwnerPlayer one.
Connectivity Semantics
In UE, our customers MUST specify a UserSlot as the "Main" slot (the owner of the game). That player’s connectivity defines the connectivity for the entire local client.
Connectivity is tracked through our WebSocket connection established at sign in time. If the connection fails to connect OR gets closed due to connection issues, we try and verify that we CAN reach some open endpoint (typically google, selected from a list of configurable high-availability endpoints). If that fails, we go into our Connectivity Loss Handling with “No Internet Connection”. Otherwise, we fail with “Beamable Server could not be reached“. The Connectivity Handling flow is the same either way, but its nice for us to be able to differentiate between these.
Connectivity Loss Handling
Users should be able to configure how they want to handle connectivity losses in the SDK. Options are:
Connection loss is handled as part of a
UBeamBackend
connectivity tick function ---UBeamNotification
system that manages the websocket connections will flag connectivity as lost when it closes due to a connection failure and the beam backend's tick function listens for that kind of thing of both theOwnerPlayer
User Slot as well as theMainEditorDeveloper
User Slot. Editor systems care about connectivity from the perspective of theMainEditorDeveloper
user andUBeamRuntime
from theOwnerPlayer
one.