Solution for Maintaining Room User List via Callbacks

Operation scenario

When developers frequently log in to and log out of rooms within a short period of time, the User Logged in Callback and User Logged out Callback provided by ZEGO do not guarantee that the order of results is consistent with the order of execution by the developer.

When developers need to rely on the User Logged in Callback and User Logged out Callback to maintain a local room user list, the inconsistency between the callback order and the execution order may cause some business errors.

For example, the user's behavior order is:

1. User u1 logs in to room r1, triggering user logged in callback c1;
2. User u2 logs in to room r1, triggering user logged in callback c2;
3. User u1 logs out of room r1, triggering user logged out callback c3;
4. User u1 logs in to room r1 again, triggering user logged in callback c4.

After passing through the callback service, the order of reaching the developer's server may become:

1. User logged in callback c1 when user u1 logs in;
2. User logged in callback c4 when user u1 logs in again;
3. User logged in callback c2 when user u2 logs in;
4. User logged out callback c3 when user u1 logs out.

The developer updates the local room user list information based on the order of callbacks. User u1 will be deleted, but in fact user u1 is still in room r1.

Operation steps

To solve the problems caused by the above callback out-of-order, ZEGO recommends that developers combine Solution for Maintaining Room List via Callbacks and refer to the following solution to maintain the local room user list.

Pay attention to key callback parameters

Pay attention to the key parameters of User Logged in Callback and User Logged out Callback.

Maintain local room user list

Maintain the local room user list based on user_account, session_id, login_time, and the corresponding room's room_id.

The data structure of the local room user list is as follows:

{
    RoomInfo: {//Refer to "Solution for Maintaining Room List via Callbacks"
        RoomID: room_id,
        RoomSessionId: room_session_id,
        RoomCreateTime:room_create_time,
        ...//Other data that needs to be saved for business
    },
    UserList:[
        {
            UserId:user_account_1,
            UserSessionId:session_id_1,
            UserLoginTime:login_time_1,
            ...//Other data that needs to be saved for business
        },{
            UserId:user_account_2,
            UserSessionId:session_id_2,
            UserLoginTime:login_time_2,
            ...//Other data that needs to be saved for business
        }
    ]
}

{
    RoomInfo: {//Refer to "Solution for Maintaining Room List via Callbacks"
        RoomID: room_id,
        RoomSessionId: room_session_id,
        RoomCreateTime:room_create_time,
        ...//Other data that needs to be saved for business
    },
    UserList:[
        {
            UserId:user_account_1,
            UserSessionId:session_id_1,
            UserLoginTime:login_time_1,
            ...//Other data that needs to be saved for business
        },{
            UserId:user_account_2,
            UserSessionId:session_id_2,
            UserLoginTime:login_time_2,
            ...//Other data that needs to be saved for business
        }
    ]
}

Processing judgment logic

After receiving the User Logged in Callback and User Logged out Callback, update the local room list.

The field descriptions in the images below are as follows:

• Room created callback processing flow:

• Room destroyed callback processing flow: