search

eclipse-hono / hono

Eclipse Hono™ Project
https://eclipse.dev/hono
Eclipse Public License 2.0
449 stars 137 forks source link

Setting device request qos-level header to messaging endpoint AMQP messages property header #2049

Closed DerSchwilk closed 4 years ago

DerSchwilk commented 4 years ago

Taking the qos-level header of a devices request, supported for telemetry messages, and setting it to the forwarded AMQP message as AMQP property header, would allow QoS-handling for, on messaging endpoint, connected systems.

Currently this is benetfitial for the Eclipse Hono <- Eclipse Ditto communication. A Ditto feature is currently in development, which has the aim to allow end-to-end acknowledgements from device sending a message via Hono to the users solution connected to Ditto: https://github.com/eclipse/ditto/issues/661

Since Ditto uses the Qpid JMS client which has no functionality to differentiate between presettled and not-settled messages via AMQP1.0 protocol specification, an AMQP property header for that differentiation is necessary. We would propose naming this property header the same as for incoming telemetry messages "qos-level".

sophokles73 commented 4 years ago

Just for clarification: even if the JMS client would allow you to determine if an incoming message was (pre-)settled or unsettled, that would not help at all because Hono sends all messages unsettled, regardless of the QoS level used by the device. We do this because it is much easier for the Dispatch Router to properly handle flow control for unsettled messages. When a device uses QoS 0 for a telemetry message, the protocol adapter sends an unsettled AMQP 1.0 message downstream but simply does not wait for the disposition from the downstream consumer. The protocol adapter simply acknowledges the uploaded data to the device but doesn't care if the downstream consumer accepts or rejects/releases the message. So, in order to allow a downstream consumer to determine the QoS level used by a device for uploading telemetry data, we have to include such a property explicitly.

sophokles73 commented 4 years ago

@fkaltner this might be a suitable issue for you to work on as well. Otherwise, I can do it as well. WDYT?

fkaltner commented 4 years ago

Yes, I actually thought also about taking over, so feel free to assign this to me.

DerSchwilk commented 4 years ago

Setting this property also to event messages (QoS 1 at all times, since QoS=0 not available for events), would allow us to implement both channels in one connection-source, while defaulting no qos-level property header to QoS=0 in our header mapping.

Will this header be included on both channels?/ Can you include it on both channels?

fkaltner commented 4 years ago

@DerSchwilk Technically we could do this but from my point of view this would be some sort of optimisation for the client you use. It is also slightly misleading to set this property as it isn't possible per Hono API/specification to set a device level QoS option for events at all. @sophokles73 WDYT?

@sophokles73 You also set the SigFox Adapter tag for this issue. As far as I can see the SigFox adapter doesn't support a QoS property? I am also not sure about the LoRa Adapter (especially since it is not in Hono's user guide yet). Technically both adapters are derived from the HTTP adapter, but I guess this doesn't mean that they should support the qos-levelheader, should they?

fkaltner commented 4 years ago

@DerSchwilk Regarding your question above: the property is set for event messages as well.