The Message Queue Telemetry Transport (MQTT) is an open standard application layer protocol for Message Oriented Middleware. MQTT is often used with a Broker that relays messages between applications that cannot communicate directly.
Publishers send MQTT messages to MQTT brokers. Subscribers subscribe to MQTT brokers for messages. A Broker may persist messages so they can be delivered even if the subscriber is not online. Brokers may also allow messages to be sent to multiple Subscribers.
The MQTT protocol defines a binary protocol used to send and receive messages from and to topics. The body is an opaque binary blob that can contain any data serialized using an encoding chosen by the application.
This specification defines two possible encodings for the message body: the binary encoded DataSetMessage defined in 7.2.2 and a JSON encoded DataSetMessage defined in 7.2.3. MQTT does not provide a mechanism for specifying the encoding of the MQTT message which means the Subscribers shall be configured in advance with knowledge of the expected encoding. Publishers should only publish NetworkMessages using a single encoding to a unique MQTT topic name.
Security with MQTT is primary provided by a TLS connection between the Publisher or Subscriber and the MQTT server, however, this requires that the MQTT server be trusted. For that reason, it may be necessary to provide end-to-end security. Applications that require end-to-end security with MQTT need to use the UADP NetworkMessages and binary message encoding defined in 7.2.2. JSON encoded message bodies must rely on the security mechanisms provided by MQTT and the MQTT server.
The syntax of the MQTT transporting protocol URL used in the Address parameter defined in 6.2.6.3 has the following form:
mqtts://<domain name>[:<port>][/<path>]
The default port is 8883.
The syntax for an MQTT URL over Web Sockets has the following form:
wss://<domain name>[:<port>][/<path>]
The default port is 443.
The current MQTT transport mapping only supports simple Username/Password authentication.
The current MQTT transport mapping does not support the concept of connection properties and any configured setting in the connection properties shall be silently discarded.
Implementations should attempt to reconnect to existing sessions (CleanSession=0) and attempt to resume message transfer at the specified QoS level.
The BrokerTransportQualityOfService values map to MQTT publish and subscribe QoS settings as follows:
- AtMostOnce_1 is mapped to MQTT QoS 0.
- AtLeastOnce_2 is mapped to MQTT QoS 1.
- ExactlyOnce_3 is mapped to MQTT Qos 2.
If the KeepAliveTime is set on a WriterGroup, a value slightly higher than the configured value of the group in seconds should be set as MQTT Keep Alive ensuring that the connection is disconnected if the keep alive message was not sent by any writer in the specified time.
The implmentation choses packet and message size limits depending on the capabilities of the OS or or the capabilities of the device the application is running on. They can be made configurable through configuration model extensions or by other means.
The current MQTT transport mapping does not support message headers. Any promoted field or additional fields defined on the WriterGroup or DataSetWriter shall be silently discarded. Implementations shall not set the MQTT RETAIN flag, except for meta data messages published to the MetaDataQueueName as described in 6.4.2.3.6.
A JSON body is encoded as defined for the JSON message mapping defined in 7.2.3.
A UADP body is encoded as defined for the UADP message mapping defined in 7.2.2.
It is expected that the software used to receive UADP NetworkMessage can process the body without needing to know how it was transported.
If the encoded MQTT message size exceeds the Broker limits it is broken into multiple chunks as described in 7.2.2.2.4.
It is recommended that the MetaDataQueueName as described in 6.4.2.3.6 is configured as a sub-topic of the related QueueName with the name $Metadata. The MQTT RETAIN flag shall be set for metadata messages.