In the example, a publish is executed up to 10 times. but for testing, I modified the loop to be infinite and not to go out of the loop as in the following code.
for (uint32_t i = 0; ;i++) {
// - for i in 0..9
// - wait up to 1 sec
// - if no message received Publish: "You have %d sec remaining to say hello...", 10-i
// - other wise, exit
// if (wait_sem.try_acquire_for(1000)) {
// break;
// }
time(&ts);
static char message[2048];
snprintf(message, 2048, \
"{\"timestamp\":\"%"PRIu64"\",\"int\":\"%"PRIi32"\",\"unsigned\":\"%"PRIu32"\"}" \
, ts, -1, i \
);
....
auto pub_status = IotMqtt_PublishSync(connection, &publish,
/* flags */ 0, /* timeout ms */ MQTT_TIMEOUT_MS);
if (pub_status != IOT_MQTT_SUCCESS) {
tr_warning("AWS Sdk: failed to publish message with %u.", pub_status);
}
ThisThread::sleep_for(500);
}
at first, it runs well. but after some time, it emits a timeout error or a socket error.
when QoS1 is set, I found the following truth.
in a normal state, the socket reads 33, 95 bytes in turn while in the timeout situation it reads 128 bytes at once
when I set QoS to 0, It isn't timed out but after a while, it eventually shows socket error and isn't recovered.
i am testing with STM DISCO IOT01A board though Wifi.
In the example, a publish is executed up to 10 times. but for testing, I modified the loop to be infinite and not to go out of the loop as in the following code.
at first, it runs well. but after some time, it emits a timeout error or a socket error.
when QoS1 is set, I found the following truth.
in a normal state, the socket reads 33, 95 bytes in turn while in the timeout situation it reads 128 bytes at once
when I set QoS to 0, It isn't timed out but after a while, it eventually shows socket error and isn't recovered.
i am testing with STM DISCO IOT01A board though Wifi.