You can call the synchronous query method or the asynchronous online /offline notification method to obtain the Message Queue for MQTT the current online status of the client.

Message Queue for MQTT Need to be combined with backend storage message queue products, such as Message Queue for Apache RocketMQ and workflow with applications (hereinafter referred to as service applications) deployed on cloud servers.

The main scenarios for retrieving the online status of the client are as follows:

  • The subsequent operation logic needs to be determined based on whether the client is online or not during the main service process.
  • The online status of a specific client needs to be determined during the O&M process.
  • Service applications need to trigger some predefined actions when a client goes online or offline.


Message Queue for MQTT The MQTT broker supports the following methods for retrieving the online status of the client:
  • Call the synchronous query SDK (coming soon)

    This method is relatively simple. In the future, we will provide an SDK to help you query the real-time status of a specific client. This method is suitable for determining the status of a single client.

    Note API operations over HTTP or HTTPS over public preview are no longer available.
  • Asynchronous online/offline notification

    This method uses notification messages. When a client goes online or offline, the MQTT broker pushes an online or offline message to backend MQ. Service applications are generally deployed on Alibaba Cloud ECS instances. Service applications can subscribe to this message from backend MQ to retrieve the online/offline events of all clients.

    This method perceives the client status asynchronously and detects the online and offline events rather than the online status of the client. Therefore, cloud-based applications need to analyze the client status based on the timeline of a series of events.

The differences between both methods are as follows:
  • The synchronous query method queries the real-time status of a client. Theoretically, it is more precise than the asynchronous notification method, but it only supports the status query of a single client at one time.
  • Asynchronous online/offline notification messages are based on message decoupling, so status determination is more complex and more likely to be incorrect. However, this method can analyze the running status traces of multiple clients based on events.

Asynchronous online/offline notification

As described in, if the asynchronous online /offline notification method is used, online /offline events are mapped to backend MQ.

The following is an example Message Queue for Apache RocketMQ message queue as the backend storage as an example.


  1. Create a topic that corresponds to online and offline events.

    The device with the Group ID that you want to pay attention to is in Message Queue for MQTT create a corresponding Topic in the console. For more information about how to create a Topic, see MQTT quick start.

    For example, if the target client type corresponds to the group ID GID_XXX, then the client ID and topic for this client type are GID_XXX@@@YYYYY and GID_XXX_MQTT, respectively.


    • GID_XXX yes Message Queue for MQTT the Group ID created in the console.
    • YYYYY indicates the device ID and is concatenated with the group ID to form the client ID in the format of <GroupID>@@@<DeviceID>.
    • _MQTT indicates the fixed suffix that is required in the name of the topic for this type of event notifications.

    For more information, see Terms.

  2. Service applications subscribe to this type of notifications.

    Use the Topic created in step 1 to receive the online /offline events of the target client. Message Queue for Apache RocketMQ See Subscribe to messages. For more information about sample code, see

    The event type is placed in Message Queue for Apache RocketMQ the message is an online or offline Tag. The data format is as follows:

    MQ Tag:connect/disconnect/tcpclean


    • A connect event indicates an online event of the client.
    • A disconnect event indicates that the client proactively disconnects from the MQTT broker. According to MQTT, the client sends a disconnect packet before proactively releasing the TCP connection. The MQTT broker triggers the disconnect message after receiving the disconnect packet. If a client SDK does not send the disconnect packet, the MQTT broker cannot receive the disconnect message.
    • A tcpclean event indicates that the current TCP connection is disconnected. If the current TCP connection is disconnected, a tcpclean event is triggered regardless of whether the client has explicitly sent a disconnect packet.

    A tcpclean message indicates that the network-layer connection of the client is disconnected. A disconnect message only indicates that the client proactively sends a disconnect packet. Some clients may fail to send a disconnect message due to unexpected exit. This is subject to the implementation on the clients. Therefore, determine whether a client is offline based on the tcpclean event.

    Data content is of the JSON type and related keys are as follows:

    • clientId indicates a specific device.
    • time indicates the event time.
    • eventType indicates the event type, which is used by clients to differentiate events.
    • channelId uniquely identifies each TCP connection.
    • clientIp indicates the Internet egress IP address used by a client.


    clientId: GID_XXX@@@YYYYY
    clientIp: 192.168.X.X:133XX     

    To determine whether a client is online, check the last received message while considering the context of online/offline notification messages.

    The determination rules are as follows:

    • The sequence of online and offline events generated by clients with the same client ID is determined by time. That is, a more recent event has a greater timestamp.
    • Clients with the same clientId may be transiently disconnected multiple times. Therefore, when an offline notification message is received, you need to check whether the message is related to the current TCP connection based on the channelId field. In short, an offline notification message can only overwrite an offline notification message with the same channelId. If channelIds of offline notification messages are different, the offline notification messages cannot be overwritten even if the value of time is more recent. A channelId indicates a TCP connection. Only one connect event and a close event.