AWS iot documentation change
Summary
Multiple documentation updates including: clarified CloudWatch metrics reference, added shared subscription queuing details, standardized RETAIN flag formatting with backticks, improved note formatting, and enhanced MQTT 5 feature descriptions with message queuing mechanics
Security assessment
Changes focus on documentation clarity, formatting improvements, and expanded feature explanations (e.g., shared subscription queuing behavior). No direct evidence of addressing security vulnerabilities or adding security-specific guidance. The queuing details relate to reliability rather than security controls.
Diff
diff --git a/iot/latest/developerguide/mqtt.md b/iot/latest/developerguide/mqtt.md index 2aa156d93..525a8eb60 100644 --- a//iot/latest/developerguide/mqtt.md +++ b//iot/latest/developerguide/mqtt.md @@ -131 +131 @@ Persistent sessions store a client’s subscriptions and messages, with a Qualit -The processing of the stored messages is recorded in CloudWatch and CloudWatch Logs. For information about the entries written to CloudWatch and CloudWatch Logs, see [Message broker metrics](./metrics_dimensions.html#message-broker-metrics) and [Queued log entry](./cwl-format.html#log-mb-queued). +The processing of the stored messages is recorded in CloudWatch metrics and CloudWatch Logs. For information about the entries written to CloudWatch and CloudWatch Logs, see [Message broker metrics](./metrics_dimensions.html#message-broker-metrics) and [Queued log entry](./cwl-format.html#log-mb-queued). @@ -163,0 +164,2 @@ After reconnection, the stored messages are sent to the client, at a rate that i +For shared subscribers, messages will be queued if at least one subscriber of a group uses a persistent session and no subscribers are online to receive the QoS 1 message. Dequeuing of messages is done at a maximum speed of 20 messages per second per active subscriber in a group. For more information, see [shared subscriptions message queuing](https://docs.aws.amazon.com/iot/latest/developerguide/mqtt.html#mqtt5-shared-subscription-queuing). + @@ -206 +208 @@ The default persistent session expiration time of one hour can be increased by u -AWS IoT Core supports the RETAIN flag described in the MQTT protocol. When a client sets the RETAIN flag on an MQTT message that it publishes, AWS IoT Core saves the message. It can then be sent to new subscribers, retrieved by calling the [`GetRetainedMessage`](https://docs.aws.amazon.com/iot/latest/apireference/API_iotdata_GetRetainedMessage.html) operation, and viewed in the [AWS IoT console](https://console.aws.amazon.com/iot/home#/retainedMessages). +AWS IoT Core supports the `RETAIN` flag described in the MQTT protocol. When a client sets the `RETAIN` flag on an MQTT message that it publishes, AWS IoT Core saves the message. It can then be sent to new subscribers, retrieved by calling the [`GetRetainedMessage`](https://docs.aws.amazon.com/iot/latest/apireference/API_iotdata_GetRetainedMessage.html) operation, and viewed in the [AWS IoT console](https://console.aws.amazon.com/iot/home#/retainedMessages). @@ -212 +214 @@ AWS IoT Core supports the RETAIN flag described in the MQTT protocol. When a cli -MQTT retained messages are sent to a client after the client subscribes to a topic. If you want all clients that subscribe to a topic to receive the MQTT retained message right after their subscription, you can publish a configuration message with the RETAIN flag set. Subscribing clients also receive updates to that configuration whenever a new configuration message is published. +MQTT retained messages are sent to a client after the client subscribes to a topic. If you want all clients that subscribe to a topic to receive the MQTT retained message right after their subscription, you can publish a configuration message with the `RETAIN` flag set. Subscribing clients also receive updates to that configuration whenever a new configuration message is published. @@ -216 +218 @@ MQTT retained messages are sent to a client after the client subscribes to a top -Devices can set the RETAIN flag on current-state messages so that AWS IoT Core will save them. When applications connect or reconnect, they can subscribe to this topic and get the last reported state right after subscribing to the retained message topic. This way they can avoid having to wait until the next message from the device to see the current state. +Devices can set the `RETAIN` flag on current-state messages so that AWS IoT Core will save them. When applications connect or reconnect, they can subscribe to this topic and get the last reported state right after subscribing to the retained message topic. This way they can avoid having to wait until the next message from the device to see the current state. @@ -236 +238 @@ Devices can set the RETAIN flag on current-state messages so that AWS IoT Core w -AWS IoT Core saves MQTT messages with the RETAIN flag set. These _retained messages_ are sent to all clients that have subscribed to the topic, as a normal MQTT message, and they are also stored to be sent to new subscribers to the topic. +AWS IoT Core saves MQTT messages with the `RETAIN` flag set. These _retained messages_ are sent to all clients that have subscribed to the topic, as a normal MQTT message, and they are also stored to be sent to new subscribers to the topic. @@ -244 +246 @@ This section describes common operations that involve retained messages. -The client determines whether a message is retained when it publishes an MQTT message. Clients can set the RETAIN flag when they publish a message by using a [Device SDK](./iot-sdks.html). Applications and services can set the RETAIN flag when they use the [`Publish` action](https://docs.aws.amazon.com/iot/latest/apireference/API_iotdata_Publish.html) to publish an MQTT message. +The client determines whether a message is retained when it publishes an MQTT message. Clients can set the `RETAIN` flag when they publish a message by using a [Device SDK](./iot-sdks.html). Applications and services can set the `RETAIN` flag when they use the [`Publish` action](https://docs.aws.amazon.com/iot/latest/apireference/API_iotdata_Publish.html) to publish an MQTT message. @@ -248 +250,3 @@ Only one message per topic name is retained. A new message with the RETAIN flag -**NOTE:** You can't publish to a [reserved topic](./reserved-topics.html) with the RETAIN flag set. +###### Note + +You can't publish to a [reserved topic](./reserved-topics.html) with the `RETAIN` flag set. @@ -252 +256 @@ Only one message per topic name is retained. A new message with the RETAIN flag -Clients subscribe to retained message topics as they would any other MQTT message topic. Retained messages received by subscribing to a retained message topic have the RETAIN flag set. +Clients subscribe to retained message topics as they would any other MQTT message topic. Retained messages received by subscribing to a retained message topic have the `RETAIN` flag set. @@ -258 +262,3 @@ Subscribing to a wild card topic filter that includes a retained message topic l -**NOTE:** To receive a retained message upon subscription, the topic filter in the subscription request must match the retained message topic exactly. +###### Note + +To receive a retained message upon subscription, the topic filter in the subscription request must match the retained message topic exactly. @@ -260 +266 @@ Subscribing to a wild card topic filter that includes a retained message topic l -Retained messages received upon subscribing to a retained message topic have the RETAIN flag set. Retained messages that are received by a subscribing client after subscription, don't. +Retained messages received upon subscribing to a retained message topic have the `RETAIN` flag set. Retained messages that are received by a subscribing client after subscription, don't. @@ -268 +274 @@ Services and apps can list and retrieve retained messages by calling [`ListRetai -A client is not prevented from publishing messages to a retained message topic _without_ setting the RETAIN flag. This could cause unexpected results, such as the retained message not matching the message received by subscribing to the topic. +A client is not prevented from publishing messages to a retained message topic _without_ setting the `RETAIN` flag. This could cause unexpected results, such as the retained message not matching the message received by subscribing to the topic. @@ -286 +292 @@ MQTT [_Will_ messages](http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/errata01/os/m -Devices, applications, and services can delete a retained message by publishing a message with the RETAIN flag set and an empty (0-byte) message payload to the topic name of the retained message to delete. Such messages delete the retained message from AWS IoT Core, are sent to clients with a subscription to the topic, but they are not retained by AWS IoT Core. +Devices, applications, and services can delete a retained message by publishing a message with the `RETAIN` flag set and an empty (0-byte) message payload to the topic name of the retained message to delete. Such messages delete the retained message from AWS IoT Core, are sent to clients with a subscription to the topic, but they are not retained by AWS IoT Core. @@ -308 +314 @@ The **Retained messages** page in the AWS IoT console provides a paginated list -The **MQTT test client** page in the AWS IoT console can subscribe and publish to MQTT topics. The publish option lets you set the RETAIN flag on the messages that you publish to simulate how your devices might behave. +The **MQTT test client** page in the AWS IoT console can subscribe and publish to MQTT topics. The publish option lets you set the `RETAIN` flag on the messages that you publish to simulate how your devices might behave. @@ -325 +331 @@ The sequence of retained message and subscribed message delivery is not guarante -Publishing messages with the RETAIN flag set from a client, by using AWS IoT console, or by calling [`Publish`](https://docs.aws.amazon.com/iot/latest/apireference/API_iotdata_Publish.html) incurs additional messaging charges described in [AWS IoT Core pricing - Messaging](https://aws.amazon.com/iot-core/pricing/#Messaging). +Publishing messages with the `RETAIN` flag set from a client, by using AWS IoT console, or by calling [`Publish`](https://docs.aws.amazon.com/iot/latest/apireference/API_iotdata_Publish.html) incurs additional messaging charges described in [AWS IoT Core pricing - Messaging](https://aws.amazon.com/iot-core/pricing/#Messaging). @@ -344 +350 @@ Retained messages and persistent sessions are standard features of MQTT that mak -**Data/session expiration** | In MQTT 3, retained messages do not expire. They are stored until they are replaced or deleted. In MQTT 5, retained messages expire after the message expiry interval you set. For more information, see Message Expiry. | Persistent sessions expire if the client doesn't reconnect within the timeout period. After a persistent session expires, the client's subscriptions and saved messages that were published with a QOS = 1 and subscribed to with a QOS =1 while the device was disconnected are deleted. Expired messages won't be delivered. For more information about session expirations with persistent sessions, see MQTT persistent sessions. +**Data/session expiration** | In MQTT 3, retained messages do not expire. They are stored until they are replaced or deleted. In MQTT 5, retained messages expire after the Message Expiry Interval you set. For more information, see Message Expiry. | Persistent sessions expire if the client doesn't reconnect within the timeout period. After a persistent session expires, the client's subscriptions and saved messages that were published with a QOS = 1 and subscribed to with a QOS =1 while the device was disconnected are deleted. Expired messages won't be delivered. For more information about session expirations with persistent sessions, see MQTT persistent sessions. @@ -348 +354 @@ For information about persistent sessions, see MQTT persistent sessions. -With Retained Messages, the publishing client determines whether a message should be retained and delivered to a device after it connects, whether it had a previous session or not. The choice to store a message is made by the publisher and the stored message is delivered to all current and future clients that subscribe with a QoS 0 or QoS 1 subscriptions. Retained messages keep only one message on a given topic at a time. +With Retained Messages, the publishing client determines whether a message should be retained and delivered to a device after it connects, whether it had a previous session or not. The choice to store a message is made by the publisher and the stored message is delivered to all current and future clients that subscribe to QoS 0 or QoS 1 subscriptions. Retained messages keep only one message on a given topic at a time. @@ -363 +369 @@ Retained messages and Device Shadows both retain data from a device, but they be -**Client receives message data upon subscription** | Client automatically receives a retained message after it subscribes to a topic with a retained message. | Clients can subscribe to Device Shadow updates, but they must request the current state deliberately. +**Client receives message data upon subscription** | The client automatically receives a retained message after it subscribes to a topic with a retained message. | Clients can subscribe to Device Shadow updates, but they must request the current state deliberately. @@ -398 +404 @@ AWS IoT Core support for MQTT 5 is based on the [MQTT v5.0 specification](http:/ - * Shared Subscriptions + * Shared subscriptions @@ -402 +408 @@ AWS IoT Core support for MQTT 5 is based on the [MQTT v5.0 specification](http:/ - * Reason Code on all ACKs + * Reason code on all ACKs @@ -404 +410 @@ AWS IoT Core support for MQTT 5 is based on the [MQTT v5.0 specification](http:/ - * Topic Aliases + * Topic aliases @@ -406 +412 @@ AWS IoT Core support for MQTT 5 is based on the [MQTT v5.0 specification](http:/ - * Message Expiry + * Message expiry @@ -413 +419,3 @@ AWS IoT Core support for MQTT 5 is based on the [MQTT v5.0 specification](http:/ -### Shared Subscriptions +### Shared subscriptions + +AWS IoT Core supports shared subscriptions for both MQTT 3.1.1 and MQTT 5. Shared subscriptions allow multiple clients to share a subscription to a topic and only one client will receive messages published to that topic using a random distribution. Shared subscriptions can effectively load balance MQTT messages across a number of subscribers. For example, say you have 1,000 devices publishing to the same topic, and 10 backend applications processing those messages. In that case, the backend applications can subscribe to the same topic, and each would randomly receive messages published by the devices to the shared topic. This is effectively "sharing" the load of those messages. Shared subscriptions also allow for better resiliency. When any backend application disconnects, the broker distributes the load to remaining subscribers in the group. When all the subscribers disconnect, messages are queued. @@ -415 +423 @@ AWS IoT Core support for MQTT 5 is based on the [MQTT v5.0 specification](http:/ -AWS IoT Core supports Shared Subscriptions for both MQTT 3 and MQTT 5. Shared Subscriptions allow multiple clients to share a subscription to a topic and only one client will receive messages published to that topic using a random distribution. Shared Subscriptions can effectively load balance MQTT messages across a number of subscribers. For example, say you have 1,000 devices publishing to the same topic, and 10 backend applications processing those messages. In that case, the backend applications can subscribe to the same topic and each would randomly receive messages published by the devices to the shared topic. This is effectively "sharing" the load of those messages. Shared Subscriptions also allow for better resiliency. When any backend application disconnects, the broker distributes the load to remaining subscribers in the group. +Message queuing capabilities are available for shared subscriptions on both MQTT 3.1.1 and MQTT 5 connections to enhance message delivery reliability. @@ -417 +425 @@ AWS IoT Core supports Shared Subscriptions for both MQTT 3 and MQTT 5. Shared Su -To use Shared Subscriptions, clients subscribe to a Shared Subscription's [topic filter](https://docs.aws.amazon.com/iot/latest/developerguide/topics.html#topicfilters) as follows: +To use shared subscriptions, clients subscribe to a shared subscription's [topic filter](https://docs.aws.amazon.com/iot/latest/developerguide/topics.html#topicfilters) as follows: @@ -424 +432 @@ To use Shared Subscriptions, clients subscribe to a Shared Subscription's [topic - * `{ShareName}` is a character string to specify the shared name used by a group of subscribers. A Shared Subscription's topic filter must contain a `ShareName` and be followed by the `/` character. The `{ShareName}` must not include the following characters: `/`, `+`, or `#`. The maximum size for `{ShareName}` is 128 bytes. + * `{ShareName}` is a character string to specify the shared name used by a group of subscribers. A shared subscription's topic filter must contain a `ShareName` and be followed by the `/` character. The `{ShareName}` must not include the following characters: `/`, `+`, or `#`. The maximum size for `{ShareName}` is 128 UTF-8 characters. @@ -426 +434 @@ To use Shared Subscriptions, clients subscribe to a Shared Subscription's [topic - * `{TopicFilter}` follows the same [topic filter](https://docs.aws.amazon.com/iot/latest/developerguide/topics.html#topicfilters) syntax as a Non-shared Subscription. The maximum size for `{TopicFilter}` is 256 bytes. + * `{TopicFilter}` follows the same [topic filter](https://docs.aws.amazon.com/iot/latest/developerguide/topics.html#topicfilters) syntax as a non-shared subscription. The maximum size for `{TopicFilter}` is 256 UTF-8 characters. @@ -433 +441 @@ To use Shared Subscriptions, clients subscribe to a Shared Subscription's [topic -Subscriptions that have the same `{ShareName}/{TopicFilter}` belong to the same Shared Subscription group. You can create multiple Shared Subscription groups and don't exceed the [Shared Subscriptions per group limit](https://docs.aws.amazon.com/general/latest/gr/iot-core.html#message-broker-limits). For more information, see [AWS IoT Core endpoints and quotas](https://docs.aws.amazon.com/general/latest/gr/iot-core.html) from the _AWS General Reference_. +Subscriptions that have the same `{ShareName}/{TopicFilter}` belong to the same shared subscription group. You can create multiple shared subscription groups and don't exceed the [Shared Subscriptions per group limit](https://docs.aws.amazon.com/general/latest/gr/iot-core.html#message-broker-limits). For more information, see [AWS IoT Core endpoints and quotas](https://docs.aws.amazon.com/general/latest/gr/iot-core.html) from the _AWS General Reference_. @@ -435 +443 @@ Subscriptions that have the same `{ShareName}/{TopicFilter}` belong to the same -The following tables compare Non-shared Subscriptions and Shared Subscriptions: +The following tables compare non-shared subscriptions and shared subscriptions: @@ -439 +447 @@ Subscription | Description | Topic filter examples -Non-shared Subscriptions | Each client creates a separate subscription to receive the published messages. When a message is published to a topic, all subscribers to that topic receive a copy of the message. | +Non-shared subscriptions | Each client creates a separate subscription to receive the published messages. When a message is published to a topic, all subscribers to that topic receive a copy of the message. | @@ -445 +453 @@ Non-shared Subscriptions | Each client creates a separate subscription to receiv -Shared Subscriptions | Multiple clients can share a subscription to a topic and only one client will receive messages published to that topic at a random distribution. | +Shared subscriptions | Multiple clients can share a subscription to a topic and only one client will receive messages published to that topic at a random distribution. | @@ -451 +459 @@ Shared Subscriptions | Multiple clients can share a subscription to a topic and -Non-shared Subscriptions flow | Shared Subscriptions flow +Non-shared subscriptions flow | Shared subscriptions flow @@ -455 +463 @@ Non-shared Subscriptions flow | Shared Subscriptions flow -**Important notes for using Shared Subscriptions** +**Important notes for using shared subscriptions** @@ -457 +465 @@ Non-shared Subscriptions flow | Shared Subscriptions flow - * When a publish attempt to a QoS0 subscriber fails, no retry attempt will happen, and the message will be dropped. + * If the shared subscriber group consists of any persistent session subscribers, when all the subscribers in the shared group are disconnected, or if any subscribers breach the Publish requests per second per connection limit, any unacknowledged QoS 1 messages and undelivered QoS 1 messages published to a shared subscription group will be queued. For more information, see shared subscriptions message queuing. @@ -459 +467 @@ Non-shared Subscriptions flow | Shared Subscriptions flow - * When a publish attempt to a QoS1 subscriber with clean session fails, the message will be sent to another subscriber in the group for multiple retry attempts. Messages that fail to be delivered after all the retry attempts will be dropped. + * QoS 0 messages published to a shared subscription group will be dropped upon any failure. @@ -461 +469 @@ Non-shared Subscriptions flow | Shared Subscriptions flow - * When a publish attempt to a QoS1 subscriber with persistent sessions fails because the subscriber is offline, the messages won't be queued and will be attempted to another subscriber in the group. Messages that fail to be delivered after all the retry attempts will be dropped. + * Shared subscriptions don't receive [retained messages](https://docs.aws.amazon.com/iot/latest/developerguide/mqtt.html#mqtt-retain) when subscribing to topic patterns as part of a shared subscriber group. Messages that are published on topics that have shared subscribers and have the `RETAIN` flag set are delivered to shared subscribers like any other publish message. @@ -463,3 +471 @@ Non-shared Subscriptions flow | Shared Subscriptions flow - * Shared Subscriptions don't receive [retained messages](https://docs.aws.amazon.com/iot/latest/developerguide/mqtt.html#mqtt-retain). - - * When Shared Subscriptions contain wildcard characters (# or +), there might be multiple matching Shared Subscriptions to a topic. If that happens, the message broker copies the publishing message and sends it to a random client in each matching Shared Subscription. The wildcard behavior of Shared Subscriptions can be explained in the following diagram. + * When shared subscriptions contain wildcard characters (# or +), there might be multiple matching shared subscriptions to a topic. If that happens, the message broker copies the publishing message and sends it to a random client in each matching shared subscription. The wildcard behavior of shared subscriptions can be explained in the following diagram. @@ -469 +475 @@ Non-shared Subscriptions flow | Shared Subscriptions flow -In this example, there are three matching Shared Subscriptions to the publishing MQTT topic `sports/tennis`. The message broker copies the published message and sends the message to a random client in each matching group. +In this example, there are three matching shared subscriptions to the publishing MQTT topic `sports/tennis`. The message broker copies the published message and sends the message to a random client in each matching group. @@ -480 +486,19 @@ Client 5 and client 6 share the subscription: `$share/consumer2/sports/tennis` -For more information about Shared Subscriptions limits, see [AWS IoT Core endpoints and quotas](https://docs.aws.amazon.com/general/latest/gr/iot-core.html) from the _AWS General Reference_. To test Shared Subscriptions using the AWS IoT MQTT client in the [AWS IoT console](https://console.aws.amazon.com/iot/home), see [Testing Shared Subscriptions in the MQTT client](./view-mqtt-messages.html#view-mqtt-shared-subscriptions). For more information about Shared Subscriptions, see [Shared Subscriptions](https://docs.oasis-open.org/mqtt/mqtt/v5.0/os/mqtt-v5.0-os.html#_Toc3901250) from the MQTTv5.0 specification. +For more information about shared subscriptions limits, see [AWS IoT Core endpoints and quotas](https://docs.aws.amazon.com/general/latest/gr/iot-core.html) from the _AWS General Reference_. To test shared subscriptions using the AWS IoT MQTT client in the [AWS IoT console](https://console.aws.amazon.com/iot/home), see [Testing Shared Subscriptions in the MQTT client](./view-mqtt-messages.html#view-mqtt-shared-subscriptions). For more information about shared subscriptions, see [Shared Subscriptions](https://docs.oasis-open.org/mqtt/mqtt/v5.0/os/mqtt-v5.0-os.html#_Toc3901250) from the MQTTv5.0 specification. + +#### Shared subscriptions message queuing + +To enhance message delivery reliability, shared subscriptions include message queuing capabilities that store messages when no online subscribers are available. When a shared subscription group contains at least one member with a persistent session, the queuing feature is enabled for the group. When distributing messages, online members are selected as recipients. QoS 1 messages are queued when no members are found online or when subscribers exceed the [`Publish requests per second per connection`](https://docs.aws.amazon.com/general/latest/gr/iot-core.html#message-broker-limits) limit. Queued messages are delivered when either existing members resume their persistent sessions, or new members join the group. Queued messages are delivered at up to 20 queued messages per second per active group subscriber, along with any other messages delivered to the subscriber as per the subscriptions. + +By default, queued message retention follows the [`Persistent Session expiry period`](https://docs.aws.amazon.com/general/latest/gr/iot-core.html#message-broker-limits) quota. However, if a Message Expiry Interval (MEI) is set in the inbound publish message, the MEI takes precedence. When MEI is present, it determines the message retention period, regardless of the Persistent Session expiry period. + +Message queue rates are limited according to the [`Queued messages per second per account`](https://docs.aws.amazon.com/general/latest/gr/iot-core.html#message-broker-limits) quota, and the number of messages is limited by the [`Maximum number of queued messages per shared subscription group`](https://docs.aws.amazon.com/general/latest/gr/iot-core.html#message-broker-limits) quota. + +When these limits are exceeded, only the messages that were already queued before reaching the limit are retained. New incoming messages that would exceed the limits are dropped. The system does not replace older queued messages with newer ones. + +The queuing of messages is recorded in CloudWatch metrics and CloudWatch Logs. For information about the entries written to CloudWatch and CloudWatch Logs, see [Message broker metrics](./metrics_dimensions.html#message-broker-metrics) and [Queued log entry](./cwl-format.html#log-mb-queued). Queued messages are still billed at the standard messaging rate. For more information about message pricing, see [AWS IoT Core Pricing](https://aws.amazon.com/iot-core/pricing). + +**Session lifecycle in shared subscription group** + +When a clean session subscribes to a group, it becomes an online member of the group. When it unsubscribes or disconnects, the clean session leaves the group. + +When a persistent session subscribes to a group, it becomes an online member of the group. When it disconnects, it still remains in the group, but becomes an offline member of the group. When it reconnects, it becomes an online member again. The persistent session leaves the group when it explicitly unsubscribes or when it expires after disconnect. @@ -486 +510 @@ You can use Clean Start and Session Expiry to handle your persistent sessions wi -### Reason Code on all ACKs +### Reason code on all ACKs @@ -490 +514 @@ You can debug or process error messages more easily using the reason codes. Reas -### Topic Aliases +### Topic aliases @@ -494 +518 @@ You can substitute a topic name with a topic alias, which is a two-byte integer. -### Message Expiry +### Message expiry @@ -496 +520 @@ You can substitute a topic name with a topic alias, which is a two-byte integer. -You can add message expiry values to published messages. These values represent the message expiry interval in seconds. If the messages haven't been sent to the subscribers within that interval, the message will expire and be removed. If you don't set the message expiry value, the message will not expire. +You can add message expiry values to published messages. These values represent the Message Expiry Interval (MEI) in seconds. If the messages haven't been sent to the subscribers within that interval, the message will expire and be removed. If you don't set the message expiry value, the message will not expire. @@ -500 +524 @@ On the outbound, the subscriber will receive a message with the remaining time l -In AWS IoT Core, the minimum message expiry interval is 1. If the interval is set to 0 from the client side, it will be adjusted to 1. The maximum message expiry interval is 604800 (7 days). Any values higher than this will be adjusted to the maximum value. +In AWS IoT Core, the minimum MEI is 1. If the interval is set to 0 from the client side, it will be adjusted to 1. The maximum message expiry interval is 604800 (7 days). Any values higher than this will be adjusted to the maximum value. @@ -537 +561 @@ Property | Description | Input type | Packet -Payload Format Indicator | A boolean value that indicates whether the payload is formatted as UTF-8. | Byte | PUBLISH, CONNECT +Payload Format Indicator | A Boolean value that indicates whether the payload is formatted as UTF-8. | Byte | PUBLISH, CONNECT @@ -542 +566 @@ User Property | A UTF-8 string pair. This property can appear multiple times in -Message Expiry Interval | A 4-byte integer that represents the message expiry interval in seconds. If absent, the message doesn't expire. | 4-byte integer | PUBLISH, CONNECT +Message Expiry Interval | A 4-byte integer that represents the Message Expiry Interval in seconds. If absent, the message doesn't expire. | 4-byte integer | PUBLISH, CONNECT @@ -546 +570 @@ Server Keep Alive | A 2-byte integer that represents the keep alive time assigne -Request Problem Information | A boolean value that indicates whether the Reason String or User Properties are sent in the case of failures. | Byte | CONNECT +Request Problem Information | A Boolean value that indicates whether the Reason String or User Properties are sent in the case of failures. | Byte | CONNECT @@ -550 +574 @@ Maximum QoS | The maximum value of QoS that AWS IoT Core supports. Default is 1. -Retain Available | A boolean value that indicates whether AWS IoT Core message broker supports retained messages. The default is 1. | Byte | CONNACK +Retain Available | A Boolean value that indicates whether AWS IoT Core message broker supports retained messages. The default is 1. | Byte | CONNACK @@ -552,2 +576,2 @@ Maximum Packet Size | The maximum packet size that AWS IoT Core accepts and send -Wildcard Subscription Available | A boolean value that indicates whether AWS IoT Core message broker supports Wildcard Subscription Available. The default is 1. | Byte | CONNACK -Subscription Identifier Available | A boolean value that indicates whether AWS IoT Core message broker supports Subscription Identifier Available. The default is 0. | Byte | CONNACK +Wildcard Subscription Available | A Boolean value that indicates whether AWS IoT Core message broker supports Wildcard Subscription Available. The default is 1. | Byte | CONNACK +Subscription Identifier Available | A Boolean value that indicates whether AWS IoT Core message broker supports Subscription Identifier Available. The default is 0. | Byte | CONNACK @@ -635 +659 @@ The message broker implementation is based on the [MQTT v3.1.1 specification](ht - * The message broker uses the client ID to identify each client. The client ID is passed in from the client to the message broker as part of the MQTT payload. Two clients with the same client ID can't be connected concurrently to the message broker. When a client connects to the message broker using a client ID that another client is using, the new client connection is accepted and the previously connected client is disconnected. + * The message broker uses the client ID to identify each client. The client ID is passed in from the client to the message broker as part of the MQTT payload. Two clients with the same client ID can't be connected concurrently to the message broker. When a client connects to the message broker using a client ID that another client is using, the new client connection is accepted, and the previously connected client is disconnected.