MQTT API Reference
MQTT 3.1.1 client library
IotMqttPublishInfo_t Struct Reference

Information on a PUBLISH message. More...

#include <iot_mqtt_types.h>

Data Fields

IotMqttQos_t qos
 QoS of message. Must be 0 or 1.
 
bool retain
 MQTT message retain flag.
 
const char * pTopicName
 Topic name of PUBLISH.
 
uint16_t topicNameLength
 Length of IotMqttPublishInfo_t.pTopicName.
 
const void * pPayload
 Payload of PUBLISH.
 
size_t payloadLength
 Length of IotMqttPublishInfo_t.pPayload. For LWT messages, this is limited to 65535.
 
uint32_t retryMs
 If no response is received within this time, the message is retransmitted.
 
uint32_t retryLimit
 How many times to attempt retransmission.
 

Detailed Description

Information on a PUBLISH message.

Parameter for: IotMqtt_Connect, IotMqtt_PublishAsync

Passed to IotMqtt_PublishAsync as the message to publish and IotMqtt_Connect as the Last Will and Testament (LWT) message.

All instances of IotMqttPublishInfo_t should be initialized with IOT_MQTT_PUBLISH_INFO_INITIALIZER.

IotMqttPublishInfo_t.retryMs and IotMqttPublishInfo_t.retryLimit are only relevant to QoS 1 PUBLISH messages. They are ignored for QoS 0 PUBLISH messages and LWT messages. These members control retransmissions of QoS 1 messages under the following rules:

Retransmission follows a truncated exponential backoff strategy. The constant IOT_MQTT_RETRY_MS_CEILING controls the maximum time between retransmissions.

After IotMqttPublishInfo_t.retryLimit retransmissions are sent, the MQTT library will wait IOT_MQTT_RESPONSE_WAIT_MS before a final check for a PUBACK. If no PUBACK was received within this time, the QoS 1 PUBLISH fails with the code IOT_MQTT_RETRY_NO_RESPONSE.

Note
The lengths of the strings in this struct should not include the NULL terminator. Strings in this struct do not need to be NULL-terminated.
The AWS IoT MQTT server does not support the DUP bit. When using this library with the AWS IoT MQTT server, retransmissions will instead be sent with a new packet identifier in the PUBLISH packet. This is a nonstandard workaround. Note that this workaround has some flaws, including the following:
  • The previous packet identifier is forgotten, so if a PUBACK arrives for that packet identifier, it will be ignored. On an exceptionally busy network, this may cause excessive retransmissions when too many PUBACKS arrive after the PUBLISH packet identifier is changed. However, the exponential backoff retransmission strategy should mitigate this problem.
  • Log messages will be printed using the new packet identifier; the old packet identifier is not saved.

Example

Consider a situation where

A PUBLISH message will be retransmitted at the following times after the initial transmission if no PUBACK is received:

  • 2000 ms (2000 ms after previous transmission)
  • 6000 ms (4000 ms after previous transmission)
  • 14000 ms (8000 ms after previous transmission)
  • 30000 ms (16000 ms after previous transmission)
  • 62000 ms (32000 ms after previous transmission)
  • 122000 ms, 182000 ms, 242000 ms... (every 60000 ms until 20 transmissions have been sent)

After the 20th retransmission, the MQTT library will wait IOT_MQTT_RESPONSE_WAIT_MS before checking a final time for a PUBACK.


The documentation for this struct was generated from the following file: