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 onConnectionStateChanged 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 CONNECTION_STATE_DISCONNECTED to CONNECTION_STATE_CONNECTING, and the cause for the state change is CONNECTION_CHANGE_REASON_LOGIN. When the state is CONNECTION_STATE_CONNECTING, the connection state automatically changes to one of the following states:

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

• CONNECTION_STATE_CONNECTED: The login succeeds.

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

When the connection state is CONNECTION_STATE_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 CONNECTION_STATE_RECONNECTING, and the cause for the state change is CONNECTION_CHANGE_REASON_INTERRUPTED. When in the CONNECTION_STATE_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 CONNECTION_STATE_CONNECTED, but the SDK does not return the onLoginSuccess callback.

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 CONNECTION_STATE_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 CONNECTION_STATE_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 onMemberLeft callback. If the user successfully logs in later, the connection state changes to the CONNECTION_STATE_CONNECTED. The SDK automatically adds the user to the previous channel, and users in the same channel receive the onMemberJoined callback. Because Signaling has removed the user from the online list, the SDK will also automatically synchronize user attributes to Signaling.

In the CONNECTION_STATE_RECONNECTING state, the SDK keeps reconnecting to the Agora Signaling system. If the token expires, the SDK returns the onTokenExpired 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 CONNECTION_STATE_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 CONNECTION_STATE_DISCONNECTED. The Signaling system removes the user from the online user list and channel, and users in the same channel receive the onMemberLeft callback.

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

_5

// Monitors the connection state

_5

public void onConnectionStateChanged(int state, int reason)

_5

{

_5

System.out.println("on connection state changed to "+ state + " reason: " + reason);

_5

}

• onConnectionStateChanged
• ConnectionState
• ConnectionChangeReason