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

背景/动机
在阅读了大量的微软Azure IoT Hub文档并使用这些示例之后，我仍然对该技术是否适用于通过间歇性/不可靠和昂贵的网络（如GSM）连接的设备，以及在哪些地方，最小化成本比最小化延迟要重要得多，一无所知。
特别是，我注意到在所有的示例中，没有注意到消息上的协议开销。遥测数据总是以小而简单的消息发送，e.g.

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

假设实时交付是如此高的优先级，所以成本并不是真正的考虑因素。我还注意到IoT集线器使用的主题/端点名称非常冗长，这必须增加开销。
C SDK documentation提到了“批处理消息以提高通信效率”，但没有进一步的细节，也不清楚这是否仅适用于HTTP，或者也适用于AMQP。也没有提到库如何决定将哪些消息批处理在一起。
还有一个mention of a "SetBatching" optionto IoTHubClient_LL_SetOption（默认为off），但它没有说明这是否仅适用于HTTP或AMQP。当我查看源代码时，这个选项似乎不存在，所以链接文档可能过时了。
更新：“more about IoTHubClient”也提到了SetBatching，但仍不清楚这是否只是HTTP。（也许批处理不会给AMQP带来任何好处——我想更好地理解这一点，这是我的问题的核心。）
实际问题
我想知道，特别是关于Azure IoT C SDK：
使用AMQP的Azure物联网中心设备到云消息的典型协议开销是多少？
当使用AMQP时，C SDK中包含了什么用于批处理消息？例如，如果应用程序连续快速发送3条消息（在连接启动时），SDK是否会通过网络将它们合并为一个数据包？在应用程序向SDK提交消息之前，SDK必须经过多长时间才能决定发送消息，而不是等待是否有更多消息？
正在关闭的设备如何确定SDK仍在缓冲哪些消息（尚未发送），以便保存这些消息并在下次启动时再次尝试发送它们？（这一个很简单-有一个回调参数IoTHubClient_LL_SendEventAsync()告诉您消息实际上是什么时候发送的。）

最佳答案

AMQP的协议开销非常低-它是在考虑到这一点的情况下设计的。在链接协商之后，端点字符串不会随每个数据消息一起发送，因此在Azure IoT Hub中这些字符串相当冗长并不重要。
Chuck Rolke编写了一个示例AMQP Illustrated，显示了通用AMQP流量（不是特别的物联网集线器）的数据包捕获。在本例中，传输帧包含“Hello World！”消息的总大小为47字节，因此协议开销为35字节，至少在本例中是这样。（这不包括TCP、IP和以太网报头。）
Olivier Bloch of Microsoft has confirmedMicrosoft Azure IoT Hub C SDK中的SetBatching选项仅用于HTTP传输。如果设置了该选项，那么SDK将在单个HTTP请求中发送尽可能多的缓冲消息。在使用HTTP传输时，请求不应太频繁，因此很可能会在HTTP请求之间缓冲几个传出消息。
最终的结论是AMPQ不支持批处理，但实际上也不需要。

关于c - Azure IoT中心协议(protocol)开销和AMQP批处理，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/37675150/