在仔细阅读了Microsoft Azure IoT Hub文档并使用示例后，我仍然对该技术是否适用于通过间歇性/不可靠且昂贵的网络（例如GSM）连接的设备以及最小化成本比最小化延迟更重要。
特别是，我注意到在所有示例中，没有注意消息上的协议开销。遥测数据始终以小而简单的消息e.g.
发送{
"time": "2016-01-26T20:47:53.0000000",
"dspl": "sensorE",
"temp": 123,
"hmdt": 34
}
可能假设实时交付是如此高优先级，成本并不是真正的考虑因素。我还注意到IoT Hub使用的主题/端点名称非常冗长，必须增加开销。
C SDK documentation提及＆＃34;批量消息以提高通信效率＆＃34;，但没有进一步的细节，并且不清楚这是否仅适用于HTTP，或者也是AMQP。还没有提到库如何决定批处理哪些消息。
IoTHubClient_LL_SetOption还有一个mention of a "SetBatching" option（默认情况下已关闭），但它不会说这是仅适用于HTTP还是仅适用于AMQP。当我查看源代码时，此选项似乎不存在，因此链接文档可能已过期。
更新：＆＃34; more about IoTHubClient＆＃34;还提到SetBatching，但如果这只是HTTP，它仍然不清楚。 （也许批处理不会给AMQP带来任何好处 - 我想更好地理解这一点，这是我问题的核心。）
我想知道，特别是关于Azure IoT C SDK：
使用AMQP，Azure IoT Hub设备到云消息的典型协议开销是什么？
使用AMQP时，用于批处理邮件的C SDK中包含哪些内容？例如，如果应用程序快速连续发送3条消息（连接已启动），SDK是否会通过网络将它们合并为一个数据包？在SDK决定发送消息之前，应用程序在向SDK提交消息之间必须经过多长时间，而不是等待查看是否还有更多时间？
关闭的设备如何确定哪些消息仍由SDK缓存（尚未发送），以便保存这些消息并尝试在下次启动时再次发送消息？< / strike> （这个很容易 - 有IoTHubClient_LL_SendEventAsync()的回调参数，它告诉你何时实际发送了一条消息。）
答案 0 :(得分：0)
AMQP的协议开销非常低 - 它的设计考虑到了这一点。在协商链接之后，不会在每个数据消息中发送端点字符串，因此在Azure IoT Hub中这些字符串非常详细并不重要。
Chuck Rolke编写了一个示例AMQP Illustrated，显示了通用AMQP流量（不是专门的IoT Hub）的数据包捕获。在示例中，Transfer框架包含“Hello World！”消息的总大小为47字节 - 因此协议开销为35字节，至少在这种情况下。 （这不包括TCP，IP和以太网标头。）
Olivier Bloch of Microsoft has confirmed Microsoft Azure IoT Hub C SDK中的SetBatching选项仅用于HTTP传输。如果设置了该选项，则SDK将在单个HTTP请求中尽可能多地发送缓冲消息。使用HTTP传输时，不应该过于频繁地进行请求，因此很可能在HTTP请求之间缓冲多个传出消息。
最终的结论是AMPQ不支持批处理，但实际上也不需要。