Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[hono-dev] Handling bad messages on Telemetry and Event API

Hi list,

I was wondering if the current way of dealing with bad messages in the Telemetry and Event API should be changed.

Currently, both the Telemetry and Event endpoints close the link with a client if a message is received that does not comply with the spec in any way, e.g. the "device_id" application property is missing or there is no payload.

We originally thought that closing the link would be an appropriate means to deal with this kind of problem, basically trying to make the sender aware of its mis-behavior in kind of a harsh and drastic way (cutting him off).

However, since we now expect most of the "clients" connecting to a Hono Server to be protocol adapters, I wonder if it wouldn't be better to instead reject bad messages by returning an AMQP 1.0 REJECTED delivery state to the sender (the protocol adapter) but otherwise keeping the link open. The protocol adapter could then translate the rejected delivery state into some message/error code that is meaningful to the device in the context of the transport protocol used by the device to connect to the protocol adapter.

A protocol adapter will most likely use the same link to the Hono Server to forward all messages for devices of the same tenant, thus it seems more efficient to not require the protocol adapter to re-establish the link in order to e.g. forward (processable) messages from other devices of the same tenant.

On the other hand, keeping the original approach would probably encourage implementors of protocol adapters to make sure that messages are well-formed BEFORE sending them downstream to the Hono Server ...


Mit freundlichen Grüßen / Best regards

Kai Hudalla
Chief Software Architect

Bosch Software Innovations GmbH
Schöneberger Ufer 89-91
10785 Berlin

Registered office: Berlin, Register court: Amtsgericht Charlottenburg, HRB 148411 B;
Executives: Dr.-Ing. Rainer Kallenbach, Michael Hahn

Back to the top