Manage connection states

When users log in and out of Signaling, or when the network connection state changes, the connection between the Agora Signaling SDK and Agora Signaling switches between different states. The possible connection states are as follows:

• CONNECTION_STATE_DISCONNECTED - The user is not connected.

• CONNECTION_STATE_CONNECTING - The user is connecting.

• CONNECTION_STATE_CONNECTED - The user is connected.

• CONNECTION_STATE_RECONNECTING - The user is reconnecting.

• CONNECTION_STATE_ABORTED - The user is kicked out.

In the following figure, the solid lines show conditions where the SDK automatically switches states, and the dotted lines show conditions where the user needs to actively call APIs to switch states.

Whenever the connection state changes, the Signaling SDK returns the latest state (the ConnectionState enumeration) and the cause for the state change (the ConnectionStateReason enumeration) through the onConnectionStateChanged callback. You can manage connection states through this callback.

You can use the state and cause for the state change returned by the ConnectionStateChanged callback to actively call the API to change the connection state in the following situations.

When you call login to log in to Signaling, the connection state changes from DISCONNECTED to CONNECTING, and the cause for the state change is LOGIN. When the state is CONNECTING, the connection state automatically changes to one of the following states:

• DISCONNECTED: The login fails or times out (the user fails to log in within 12 seconds).

• CONNECTED: The login succeeds.

When the connection state turns to DISCONNECTED, you need to call login again to log in.

When the connection state is CONNECTED, if the connection with the Agora Signaling system is interrupted and cannot recover in four seconds due to network reasons, the connection state changes to RECONNECTING, and the cause for the state change is INTERRUPTED. When in the RECONNECTING state, the Signaling SDK continues to automatically reconnect to Signaling until the login is successful, so you do not need to perform any login operations. After successful reconnection, the connection state changes to CONNECTED.

The SDK resends messages that occurred during the disconnection period according to the following guidelines:

• Sender During the reconnection period, the SDK continues to send all channel and peer-to-peer messages until the message request times out.

• Receiver After the reconnection succeeds, Signaling resends all of the peer-to-peer messages sent during the disconnection period but only the channel messages from the 30-second period immediately before reconnection (up to a maximum of 32 messages) to the receiver.

If the reconnection keeps failing, the connection state remains at RECONNECTING. You can call logout to log out of the system first, and then call the login method to reconnect at an appropriate time.

Signaling responds differently per the length of time between the interruption of the connection and the successful reconnection:

• If the user successfully logs in again within 30 seconds of the interruption, the connection state changes to the CONNECTED. The user’s online state remains unchanged.

• If the user is still offline 30 seconds after the interruption, Signaling removes the user from the online user list and channel, and users in the same channel receive the MemberLeft callback. If the user successfully logs in later, the connection state changes to the CONNECTED. The SDK automatically adds the user to the previous channel, and users in the same channel receive the MemberJoined callback. Because Signaling has removed the user from the online list, the SDK will also automatically synchronize user attributes to Signaling.

In the RECONNECTING state, the SDK keeps reconnecting to the Agora Signaling system. If the token expires, the SDK returns the TokenExpired callback, which does not affect the connection state.

If the same user ID logs in to Signaling from another client instance, the user who is currently connected in the client instance gets kicked out by the Signaling system, and the connection state changes to ABORTED. You can call logout to log out of the system first, and then call the login method to reconnect in an appropriate time.

If you call logout to log out of the Signaling system, the connection state changes to DISCONNECTED. The Signaling system removes the user from the online user list and channel, and users in the same channel receive the MemberLeft callback.

Refer to the following sample code to monitor the connection state:

// Monitors the connection state

rtm.on('ConnectionStateChanged', (newState, reason) => {

console.log('reason', reason)

})

• ConnectionStateChanged
• ConnectionState
• ConnectionStateReason