Azure IoT 中心协议开销和使用 AMQP 的批处理
Azure IoT Hub protocol overhead and batching with AMQP
Background/Motiviation
在大量阅读 Microsoft Azure IoT Hub 文档并试用示例后，我仍然不清楚该技术是否适用于通过 intermittent/unreliable 和昂贵网络（例如 GSM）连接的设备，并且最小化成本比最小化延迟更重要。
特别是，我注意到在所有示例中，都没有注意消息的协议开销。遥测数据始终作为小而简单的消息发送，e.g.
{
"time": "2016-01-26T20:47:53.0000000",
"dspl": "sensorE",
"temp": 123,
"hmdt": 34
}
大概是假设实时交付是如此重要，以至于成本并不是真正的考虑因素。我还注意到 IoT 中心使用的 topic/endpoint 名称非常冗长，这肯定会增加开销。
C SDK documentation 顺便提到了 "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：
使用 AMQP 的 Azure IoT 中心设备到云消息的典型协议开销是多少？
使用AMQP时批处理消息的C SDK包含什么？例如，如果应用程序快速连续发送 3 条消息（连接建立时），SDK 会通过网络将它们组合成一个数据包吗？在 SDK 决定发送消息而不是等待查看是否有更多消息之前，应用程序向 SDK 提交消息之间必须经过多少时间？
正在关机的设备如何判断SDK还在缓存哪些消息（还没有发送），以便保存这些消息，下次再尝试发送什么时候开始？ （这个很简单 - IoTHubClient_LL_SendEventAsync() 有一个回调参数，它会告诉您消息实际发送的时间。）
AMQP 的协议开销非常低 - 它在设计时就考虑到了这一点。协商链接后，端点字符串不会随每条数据消息一起发送，因此这些在 Azure IoT 中心中非常冗长并不重要。
Chuck Rolke 编写了一个示例，AMQP Illustrated，显示了通用 AMQP 流量（不是特定的 IoT 中心）的数据包捕获。在示例中，包含 "Hello World!" 消息的传输帧的总大小为 47 字节 - 因此协议开销为 35 字节，至少在这种情况下是这样。 （这不包括 TCP、IP 和以太网 headers。）
Olivier Bloch of Microsoft has confirmed Microsoft Azure IoT Hub C SDK 中的 SetBatching 选项仅用于 HTTP 传输。如果设置了该选项，则 SDK 将在单个 HTTP 请求中发送尽可能多的缓冲消息。使用 HTTP 传输时，不应过于频繁地发出请求，因此很可能会在 HTTP 请求之间缓冲多个传出消息。
最终的结论是 AMPQ 不支持批处理，但实际上也不需要。
Background/Motiviation
在大量阅读 Microsoft Azure IoT Hub 文档并试用示例后，我仍然不清楚该技术是否适用于通过 intermittent/unreliable 和昂贵网络（例如 GSM）连接的设备，并且最小化成本比最小化延迟更重要。
特别是，我注意到在所有示例中，都没有注意消息的协议开销。遥测数据始终作为小而简单的消息发送，e.g.
{
"time": "2016-01-26T20:47:53.0000000",
"dspl": "sensorE",
"temp": 123,
"hmdt": 34
}
大概是假设实时交付是如此重要，以至于成本并不是真正的考虑因素。我还注意到 IoT 中心使用的 topic/endpoint 名称非常冗长，这肯定会增加开销。
C SDK documentation 顺便提到了 "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：
使用 AMQP 的 Azure IoT 中心设备到云消息的典型协议开销是多少？
使用AMQP时批处理消息的C SDK包含什么？例如，如果应用程序快速连续发送 3 条消息（连接建立时），SDK 会通过网络将它们组合成一个数据包吗？在 SDK 决定发送消息而不是等待查看是否有更多消息之前，应用程序向 SDK 提交消息之间必须经过多少时间？
正在关机的设备如何判断SDK还在缓存哪些消息（还没有发送），以便保存这些消息，下次再尝试发送什么时候开始？（这个很简单 -IoTHubClient_LL_SendEventAsync()有一个回调参数，它会告诉您消息实际发送的时间。）
AMQP 的协议开销非常低 - 它在设计时就考虑到了这一点。协商链接后，端点字符串不会随每条数据消息一起发送，因此这些在 Azure IoT 中心中非常冗长并不重要。
Chuck Rolke 编写了一个示例，AMQP Illustrated，显示了通用 AMQP 流量（不是特定的 IoT 中心）的数据包捕获。在示例中，包含 "Hello World!" 消息的传输帧的总大小为 47 字节 - 因此协议开销为 35 字节，至少在这种情况下是这样。 （这不包括 TCP、IP 和以太网 headers。）
Olivier Bloch of Microsoft has confirmed Microsoft Azure IoT Hub C SDK 中的 SetBatching 选项仅用于 HTTP 传输。如果设置了该选项，则 SDK 将在单个 HTTP 请求中发送尽可能多的缓冲消息。使用 HTTP 传输时，不应过于频繁地发出请求，因此很可能会在 HTTP 请求之间缓冲多个传出消息。
最终的结论是 AMPQ 不支持批处理，但实际上也不需要。