我在嵌入式设备上使用IoTHub设备客户端SDK。应用程序将定期向iot hub发送遥测消息。 iot设备连接到无线路由器，并通过WAN端口无线连接到互联网。
当无线路由器丢失互联网连接时，iot设备将不会立即收到有关断开连接的通知。获得通知需要大约60秒，然后iot设备将继续使用IoTHubDeviceClient_LL_SendEventAsync（）发送遥测消息，所有这些消息都在SDK层排队并吃掉内存。由于它是在资源有限的嵌入式设备上，内存被吃掉并导致程序被较低的内存杀手应用程序杀死。
有没有办法指定iot消息的总大小可以在sdk层排队？如果超过此配额，IoTHubDeviceClient_LL_SendEventAsync（）将立即失败。
实际上，这也是正常情况所需要的。当iot设备发送消息时，似乎消息已在低层排队并在特定时间刷新。我没有看到任何可以控制刷新的API。这会产生另一个问题，即使有互联网连接，从应用程序级别，也无法控制已排队的邮件数量和排队时间，反过来，app无法控制进程使用了多少内存。在我的设备上，有一个系统监视器会杀死进程使用太多内存。
问题是，如果在队列已满的情况下发生消息失败，即使在这种情况下您又做了什么？由于存储容量不足，您是否丢失了信息？从物联网的角度来看，我建议在这种情况下考虑您的设备是否是可靠的物联网设备来处理这些边缘情况。并且了解设备的限制，并了解没有互联网连接可以有多长时间，这有助于从应用程序中缓解这些风险，而不是SDK。
在GitHub中，默认的sendMessageAsync方法会在您的消息发送失败时抛出超时异常，除非您实现了某种重试策略（根据文档C SDK不允许自定义重试策略https://docs.microsoft.com/en-us/azure/iot-hub/iot-hub-reliability-features-in-sdks）。
根据基于重试策略的连接失败的文档（如果已设置），SDK将尝试以这种方式或那种方式启动连接并对同时创建的消息进行排队：https://github.com/Azure/azure-iot-sdk-c/blob/master/doc/connection_and_messaging_reliability.md
所以，这里的期望是SDK不对内存限制负责。这取决于交易的应用程序。由于您的设备有一些限制，我建议您实施自己的排队机制（可能将no-retry设置为策略，这样可以避免排队）。这样你就可以控制在没有互联网连接并且受控制内存限制的情况下会发生什么。也许你的商业案例接受你计算一个平均值而不是50你在一段时间内存储1条消息等。
如果这个你不喜欢的东西，文档还说你设置了队列的超时 - 可能不是内存限制但是超时是的，所以也许你可以尝试更深入地研究这个：
“此系统中有两个超时控件.iothub_client_ll层中的原始控件 - 控制”等待发送“队列 - 以及协议传输层中的现有队列 - 适用于”进行中“列表。但是，由于IoTHubClient_LL_DoWork使遥测消息立即被处理，发送并移动到“进行中”列表，因此第一个超时控制实际上是不适用的。
用户可以通过IoTHubClient_LL_SetOption对这两者进行微调，因此删除原始控件可能会导致现有客户中断。出于这个原因，它一直保持原样，但当我们转向产品的下一个主要版本时，它将被重新设计。“