各个Iot Cloud对MQTT协议的支持
1. Aliyun
目前物联网平台支持MQTT标准协议接入,兼容5.0、3.1.1和3.1版本协议,具体的协议请参见MQTT 5.0、MQTT 3.1.1和 MQTT 3.1协议文档。
- 与标准MQTT的区别
- 支持MQTT的PUB、SUB、PING、PONG、CONNECT、DISCONNECT和UNSUB等报文。
- 支持clean session。
- 不支持will、retain msg。
- 支持QoS 0、QoS 1,不支持QoS 2。
- 不支持SUB QoS,消息QoS以发送方(PUB)指定为准。
- 基于原生的MQTT Topic上支持RRPC同步模式,服务器可以同步调用设备并获取设备回执结果
2. Azure
IoT 中心允许设备通过以下方式与 IoT 中心设备终结点通信:
-
在端口 8883 上使用 MQTT v3.1.1
-
在端口 443 上使用基于 WebSocket 的 MQTT v3.1.1。
IoT 中心不是功能完备的 MQTT 中转站,并未支持 MQTT v3.1.1 标准中指定的所有行为。 本文介绍设备如何使用受支持的 MQTT 行为来与 IoT 中心通信。
- 可设置的客户端最大 keep-alive 值为 1767 / 1.5 = 1177 秒。 任何流量都将重置 keep-alive。 例如,成功的 SAS 令牌刷新会重置 keep-alive。
- 成功建立连接后,设备可以使用 devices/{device_id}/messages/events/ 或 devices/{device_id}/messages/events/{property_bag} 作为 主题名称 将消息发送到 IoT 中心。
- IoT 中心不支持 QoS 2 消息。 如果设备应用使用 QoS 2 发布消息,IoT 中心将断开网络连接。
- IoT 中心不会保存 Retain 消息。 如果设备在 RETAIN 标志设置为 1 的情况下发送消息,则 IoT 中心会在消息中添加 mqtt-retain 应用程序属性 。 在此情况下,IoT 中心不会存储保留消息,而将其传递到后端应用。
- IoT 中心仅支持每个设备一个活动 MQTT 连接。 代表相同设备 ID 的任何新 MQTT 连接都会导致 IoT 中心删除现有连接,系统会将“400027 ConnectionForcefullyClosedOnNewConnection”记录到 IoT 中心日志中。
- 若要从 IoT 中心接收消息,设备应使用 devices/{device_id}/messages/devicebound/# 作为 主题筛选器 来进行订阅。 主题筛选器中的多级通配符 # 仅用于允许设备接收主题名称中的其他属性。
3. AWS
- AWS IoT supports MQTT quality of service (QoS) levels 0 and 1 only. AWS IoT doesn’t support publishing or subscribing with QoS level 2. When QoS level 2 is requested, the message broker doesn’t send a PUBACK or SUBACK.
- In AWS IoT, subscribing to a topic with QoS level 0 means that a message is delivered zero or more times. A message might be delivered more than once. Messages delivered more than once might be sent with a different packet ID. In these cases, the DUP flag is not set.
- When responding to a connection request, the message broker sends a CONNACK message. This message contains a flag to indicate if the connection is resuming a previous session.
- Before sending additional control packets or a disconnect request, the client must wait for the CONNACK message to be received on their device from the AWS IoT message broker.
- When a client subscribes to a topic, there might be a delay between the time the message broker sends a SUBACK and the time the client starts receiving new matching messages.
- The MQTT specification provides a provision for the publisher to request that the broker retain the last message sent to a topic and send it to all future topic subscribers. AWS IoT doesn’t support retained messages. If a request is made to retain messages, the connection 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.
- On rare occasions, the message broker might resend the same logical PUBLISH message with a different packet ID.
- The message broker doesn’t guarantee the order in which messages and ACK are received.