c - Azure IoT 中心协议(protocol)开销和使用 AMQP 的批处理

Question

背景/动机

在大量阅读 Microsoft Azure IoT Hub 文档并试用示例之后，我仍然不清楚该技术是否适用于通过间歇性/不可靠且昂贵的网络(例如 GSM)连接的设备，以及在哪里最小化成本比最小化延迟重要得多。

特别是，我注意到在所有示例中，都没有关注消息的协议(protocol)开销。遥测数据始终作为小而简单的消息发送，e.g.

{
    "time": "2016-01-26T20:47:53.0000000",
    "dspl": "sensorE",
    "temp": 123,
    "hmdt": 34
}

大概假设实时交付是如此重要，以至于成本并不是真正的考虑因素。我还注意到 IoT 中心使用的主题/端点名称非常冗长，这肯定会增加开销。

C SDK documentation makes passing mention of "Batches messages to improve communication efficiency", 但没有进一步的细节，不清楚这是否只适用于 HTTP，或者也适用于 AMQP。也没有提及库如何决定将哪些消息一起批处理。

还有一个mention of a "SetBatching" option到 IoTHubClient_LL_SetOption(默认关闭)，但它没有说明这是否仅适用于 HTTP 或也适用于 AMQP。当我查看源代码时，此选项似乎不存在，因此链接文档可能已过时。

更新:“more about IoTHubClient”也提到了SetBatching，但目前还不清楚这是否仅适用于HTTP。 (也许批处理不会给 AMQP 带来任何优势 - 我想更好地理解这一点，这是我问题的核心。)

实际问题

我想知道，特别是关于 Azure IoT C SDK:

1. 使用 AMQP 的 Azure IoT 中心设备到云消息的典型协议(protocol)开销是多少？

2. 使用 AMQP 时，用于批处理消息的 C SDK 中包含什么？例如，如果应用程序快速连续发送 3 条消息(连接建立时)，SDK 会通过网络将它们组合成一个数据包吗？在 SDK 决定发送消息而不是等待查看是否有更多消息之前，应用程序向 SDK 提交消息之间必须经过多少时间？

3. 正在关闭的设备如何确定哪些消息仍在由 SDK 缓冲(尚未发送)，以便保存这些消息并在下次启动时尝试再次发送它们？ (这很简单 - IoTHubClient_LL_SendEventAsync() 有一个回调参数，它会告诉您消息何时实际发送。)

Answer 1

AMQP 的协议(protocol)开销非常低 - 它在设计时就考虑到了这一点。协商链接后，端点字符串不会随每条数据消息一起发送，因此这些在 Azure IoT 中心中非常冗长并不重要。

Chuck Rolke 写了一个例子，AMQP Illustrated ，显示了通用 AMQP 流量(不是特定的 IoT 中心)的数据包捕获。在示例中，传输帧包含“Hello World!”消息的总大小为 47 个字节 - 因此协议(protocol)开销为 35 个字节，至少在这种情况下是这样。 (这不包括 TCP、IP 和以太网 header 。)

Olivier Bloch of Microsoft has confirmed Microsoft Azure IoT Hub C SDK 中的 SetBatching 选项仅用于 HTTP 传输。如果设置了该选项，则 SDK 将在单个 HTTP 请求中发送尽可能多的缓冲消息。使用 HTTP 传输时，请求不应过于频繁，因此很可能会在 HTTP 请求之间缓冲多个传出消息。

最终的结论是 AMPQ 不支持批处理，但实际上也不需要。