MQTT standards and requirements
The IoT tool supports any content that is permitted by the MQ Telemetry Transport (MQTT) standard versions 5.0, 3.1.1, and 3.1.
MQTT is a lightweight event and message-oriented protocol hat allows devices to asynchronously communicate efficiently across constrained networks to remote systems. MQTT supports many different data formats, so it's possible to send images, texts that are in any encoding, encrypted data, and virtually every type of data in binary format.
For more information about the MQTT standard, see MQTT.org.
For more information about message payload size limits and format restrictions for specific use cases for the IoT tool, see MQTT messaging
MQTT version 5.0
MQTT version 5.0 has the following features:
- Oasis Standard
- Enhancements for scalability
- Improved error reporting
- Formulation of common patterns that include capability discovery and request response
- Extensibility mechanisms that include user properties
- Performance improvements and support for small clients
Use the new functionality by downloading an Eclipse client that is updated to support MQTT version 5.0 from the Eclipse Paho library. The IoT tool retains full compatibility with an earlier version for MQTT version 3.1 and MQTT version 3.1.1 clients. The following functionality is available as part of MQTT V5.0:
- Error reporting
- Enhancements to the information that is provided when an error occurs makes it easier to determine the cause of the failure.
- New clean start and session expiry interval support
- Clients can control the duration of a session by indicating whether to start a new session on connect and how long after a disconnect to keep a session.
- Message expiry
- Messages can be set to expire by including an expiration time in the message. If a message is not received by the destination before the expiration time, it is thrown away and is not delivered. This feature is useful if the message that is being sent to a device is only important if that device is online.
- Message properties that include user properties
- Message properties can now be included in the message header, for example, whether the content is text or binary, the content type, and application-defined user properties. Message properties enable rapid routing in the back-end application by removing the need to parse the message payload. If the payload is encrypted, the additional information that is contained in the header outside of the encrypted envelope can be used to maximize processing efficiency.
- Subscription identifiers
- Subscriptions can be tagged with an identifier, which is returned along with messages that are received by that subscription. This feature enables the routing of messages in the client application.
- Subscription options
- The addition of a *NoLocal* option makes it possible to not send messages that originate on a specified client and also includes options for handling retained messages when subscribing to a topic.
- Topic alias
- Topic alias is used to decrease the number of bytes that are sent across the network by encoding long topic names into a short integer encoding.
- Capability discovery
- Clients can discover the capabilities of the MQTT server, for example, the maximum packet size that is accepted. Many capabilities are handled by the client library but are now made available to the client application.
MQTT version 3.1.1
- OASIS Standard
- ISO standard (ISO/IEC PRF 20922) for V3.1.1
- Improved interoperability between various clients and servers because of a more precise definition of the protocol compared to V3.1.
- The maximum length of the MQTT client identifier (ClientId) is increased to 256 from the 23-character limit that is imposed by V3.1. The IoT tool often requires longer client IDs. Long client IDs are supported regardless of the MQTT protocol version. However, some V3.1 client libraries check the length of the ClientId value and enforce the 23 character limit.
MQTT version 3.1
MQTT version 3.1 of the protocol is the earliest version that is supported.