Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How to gracefully know whether reconnection is successful and resubscribed topic? #1492

Open
lyx10101010 opened this issue Jun 11, 2024 · 1 comment
Labels

Comments

@lyx10101010
Copy link

Describe the bug

How to gracefully know whether reconnection is successful and resubscribed?

To Reproduce

1️⃣ Based on the paho_c_sub.c example, I removed all finished = 1; statements in failure type callbacks to prevent exit on failure.

2️⃣ I added a connectionLost callback function to this example. When MQTTAsync disconnects, I can know immediately that the network is disconnected.

void connectionLost(void* context, char* cause)
{
    if (!opts.quiet)
        printf("\nConnection lost\n");
    if (cause)
        printf("     cause: %s\n", cause);
    disconnected = 1;
}

rc = MQTTAsync_setCallbacks(client, client, connectionLost, messageArrived, NULL);
if (rc != MQTTASYNC_SUCCESS)
{
    if (!opts.quiet)
        fprintf(stderr, "Failed to set callbacks, return code: %s\n", MQTTAsync_strerror(rc));
    exit(EXIT_FAILURE);
}

3️⃣ Execute command to connect to an MQTT broker and subscribe to a topic. In the original example, upon successful connection, the MQTTAsync_subscribe operation is performed in the onConnect/onConnect5 callback, continuously receiving messages from the broker.

4️⃣ If the network disconnects, the connectionLost callback function is called; now, it's known that the network is disconnected.

5️⃣ Since MQTTAsync internally has a reconnection mechanism, the client can reconnect successfully when the network is normal, but there are no successful connection prints, and the callback function after successful reconnection is not executed;

🔖 We reviewed the code and found that the callback functions were set to null, which is why the callback functions are not executed again. We looked at many related issues, but still don't quite understand how to operate;

🔖 Because we are using the clean_session=true flag, and we perform MQTTAsync_subscribe operations in the callback, we won't receive messages on the topic after successful connection. Although we can temporarily solve this problem with the clean_session=false flag, it's not our expected solution, as I cannot fully rely on the broker's mechanism because some brokers might support keeping sessions in memory, and if the broker restarts, session information might be lost, which I cannot rely on clean_session=false;

🔖 Although it's not necessarily required to execute the MQTTAsync_subscribe function in the onConnect/onConnect5 callbacks to subscribe, since I cannot immediately know the current status after a successful reconnection, I also cannot gracefully perform MQTTAsync_subscribe elsewhere. The MQTTAsync_isConnected function can determine the current status, but it requires continuous looping to check, is there a more elegant way to know that it has successfully reconnected?

Expected behavior

1️⃣ How to gracefully know the current status? I removed all the code commented with /* Null out callback pointers so they aren't accidentally called again */, and I tested it, and it all worked successfully, the needed callbacks could be expectedly called, but I don't know if there are any other side effects, please clarify, thank you!

image

2️⃣ How to gracefully resubscribe after being reconnected to the broker with MQTTAsync library?

Environment (please complete the following information):

  • OS: Linux
  • Version 1.3.13
@icraggs
Copy link
Contributor

icraggs commented Jul 1, 2024

The best way is to call subscribe in the onConnect callback, if you haven't reconnected with cleansession=false.

The onConnect callback is the elegant way to know that the client has reconnected. No polling or looping, and is done in a timely manner.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants