C API should allow asynchronous acknowledgement of incoming messages

[alaendle]

The C API design leads to poor performance and therefore isn't suitable for high throughput/streaming scenarios.

Let me explain the problem in more detail: Currently the message handler callback (https://docs.microsoft.com/en-us/azure/iot-hub/iot-c-sdk-ref/iothub-client-core-common-h#iothubclientmessagecallbackasync) needs to return the result in a synchronous way. But think of use cases where handling the incoming message involves (heavy) I/O (like storing in a database or transferring to a message broker) - in almost any cases you would use a asynchronous API to do the I/O and provide some kind of completion callback to get the information if the operation completed successfully. And here the problem arises, with the current C API design you need to wait for the completion callback to determine the correct return value for the C SDK callback.

So please add methods that allow the ack/nack of messages independently from the message handler callback and remove the result value from the callback signature (or at least add a value like NONE to indicate that information about the success will be given at a later time).

At least conceptually I see no problems to provide an asynchronous API that enables windowing, because the underlying transport protocol works inherently in a asynchronous way - and also the C# SDK provides corresponding methods (e.g. https://docs.microsoft.com/en-us/dotnet/api/microsoft.azure.devices.client.moduleclient.completeasync?view=azure-dotnet).

For now I keep short, but please don't hesitate to contact me if I was unclear or if I could contribute more/other information that may help you to understand/solve the problem. Thanks in advance.

Please note that I'm unsure if this is a bug report or a feature request, because on the one hand the performance that can be achieved with the current API is worse, on the other hand this issue requests changes to the design that could be seen as a feature. And also note that I've addressed the same problem at feedback.azure.com; not to double the work at Microsoft, but because I hope that the different platforms trigger different support levels that might lead to different interpretations (e.g. a more technical perspective here at github and more a product management view on feedback.azure.com).

[danewalton]

Hi @alaendle quick question here.
As an alternative design, would it be possible to use the callback as is and queue the processing of the messages. IE decouple the acknowledgement that the message is coming in and the actual handling of the message itself? (I might be saying the same thing as you here).

Just to clarify I think: You would like to acknowledge the message at the MQTT level and at the IoT Hub layer at different points of execution?

[alaendle]

Hi @danewalton - Thanks for asking. I think we are basically talking about the same idea here. Unfortunately I'm not 100% sure what you mean by "queue the processing"; but decoupling the acknowledgment from the control flow is exactly the point.

So I hope the following pictures make my concern clearer:

At the moment you have to wait for the async result of a completion callback to return the control flow to the SDK - Diagram: current flow

But my hope is that something like that would become possible - Diagram: requested flow.

Hope this narrows the room for interpretation; and please don't hesitate to ask if I was still unclear about my intentions regarding this issue.

[ewertons]

Relates to #1437

[danewalton]

Hey @alaendle
For C2D messages, we currently don't have that ability and do not have plans to add it.

In the linked issue above, the flow is theoretically possible with methods. However there is currently a limitation on acquiring one of the parameters which we became aware of. For now this is blocked and we are looking at plans to add support. We have no timeline to give at this time though.

Might not be the answer you were looking for (sorry about that) but hopefully that helps!

[az-iot-builder-01]

@danewalton, @alaendle, thank you for your contribution to our open-sourced project! Please help us improve by filling out this 2-minute customer satisfaction survey

[alaendle]

Hi @danewalton, thanks for your statement. However I would like to add that I'm not focusing C2D messages; C2D messages are normally relatively rare (and have no special constraints regarding their latency), compared to Edge Hub to Device/Module messages. So my real concern is the performance bottleneck for such messages. My guess is that your concerns are still the same as for C2D messages, but I hope that the focus on "inner-edge" communication, where traffic and latency requirements are much higher, might make clear the priority of this feature (at least for high frequency, low-latency, reliable, inner-edge communication - which from my point of view is one of the basic requirements of edge service - at least for manufacturing IT).

[jspaith]

@alaendle - To set expectations this type of enhancement isn't any sort of work plan, but... the ask does make sense so I'd rather track this formally here. Reactivating.

[jspaith]

Also note that we have IoTHubDeviceClient_DeviceMethodResponse lying around already to kind of do this. We'd need some more work to make this real. See #1437.

If we add this enhancement, we need to either (a) use IoTHubDeviceClient_DeviceMethodResponse as basis if it makes sense. Or if we create a new API we should mark IoTHubDeviceClient_DeviceMethodResponse as deprecated and point to the new mechanisms.

[Malibushko]

Are there any updates on this issue? It has become a bottleneck in our project, and I would like to know if there is any work in this direction?

[ericwolz]

issue fixed in #1422

[alaendle]

@ericwol-msft - not sure what you mean by fixed, this was definitely not changed with PR #1876 (the corresponding PR that has fixed issue #1422); if other fixes are in place I'm more than happy, otherwise could you please reopen that issue?

[ewertons]

Hi @alaendle and @Malibushko, we are reopening and assessing this request. Will update you soon.