Re: [mosquitto-dev] retained messages and bridges

[Dustin Sallings <dustin@xxxxxxx>]

This might make more sense on the mqtt list. I think it brings up some interesting points.

I have run my own bridge software for a while because of deficiencies in mosquitto's (mostly around v5).  I do send resend retained messages, but I carry expiration forward.

The protocol doesn't have any concept of when an original message was sent, but it might be possible to do something useful with user properties.  There's not really any room for vendor properties...

On Tue, Aug 11, 2020, 05:21 Greg Troxel <gdt@xxxxxxxxxx> wrote:

I have a setup, and projecting to the part that matters, it is:

  broker at site A
  Home Assistant (HA) at site A

  broker at site B
  code to read status of a UPS and inject messages

At B, the retain flag is set.


Currently, the code to publish status is not running.

So, in steady state, there is a retained message on broker B and one on
broke A, and HA has timed out the status and shows things as
Unavailable, which is correct.

Then, internet flakes at B and the bridge connection is re-made to A,
and the old message is reinjected.  HA sees that as fresh (which it is
not) and then times it out again.

There are multiple tings kind of wrong:

  mqtt is a message protocol, and users have to use it in a sound way,
  and publishing current state and using retain is not really sound.
  With retain, you have to have a timestamp and handle that, so you
  don't deal with old data as fresh data.  (very hard obviously)

  retain is ok for the originating broker; as long as it is up the
  message sits there, but it doesn't re-appear.  However, once a
  retained message has been sent over a bridge, arguably it should not
  be re-sent over that same bridge.  That requires bookkeeping somehow,
  perhaps a 'last sync' timestamp per bridge, and not sending messages
  that are earlier than this time.    Not clear what specs say, but I
  think this would be an improvement.


Overall I am concluding both that

  bridges should not send retained messages that were already sent.

  state information should not be retained, unless one of

     it has timestamps and processing code is timestamp and time
     semantics aware (which HA is not)

     recipients really treat the retained message as simply "current
     state" with no sense of expiration (which doesn't really make sense
     because when you don't have a message for 2 days you really have no
     idea what's going on)


Thougths?
_______________________________________________
mosquitto-dev mailing list
mosquitto-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/mosquitto-dev