Bridging retained messages

[Roger Light]

Hi,

I've had a query about retained messages. If a broker receives a
message to be retained, any clients that are currently connected and
subscribed will be sent the message without the retain flag sent. If a
new client connects and subscribes to a topic, any existing retained
messages will be sent with the retained flag set. This essentially
means that the retained flag has two meanings. From a client to the
broker it means "retain this message". From the broker to a client it
means "this is message is not fresh".

This means that for a bridge, assuming it is always connected, the
messages it receives are always fresh and so will never have the
retained flag set. Any client then connecting to the remote broker
will not receive retained messages. The person making the query thinks
this is incorrect behaviour and I'm inclined to agree.

If I as the broker and creating the bridge then any messages I pass
outwards can be modified to have the retain flag set because I know
that the connection is a bridge. Is this appropriate behaviour?

In the other direction it is not quite so easy. If I could determine
that a client connected to me is a bridge then the problem is solved.
I could do this by adding something to the protocol to indicate that a
client is a bridge or by monitoring for incoming messages that are in
the topic $SYS/broker/connections/, assuming the bridging broker
supports that feature. I could also use my own protocol version number
to deal with inter broker communication - I believe that this is what
rsmb does, presumably for these kinds of reasons.

To end with a question - should there be some way of determining if a
client is a bridge and how should this be done? Should I be
propagating messages to bridges with the retained flag set even if
they aren't stale?

Thanks,

Roger

[Andy Piper]

My own understanding is that bridging does not currently have a way of determining that a client is a broker acting as a bridge.

I suspect Ian C or Nick would be best placed to describe expected behaviours. Hoping that Ian might want to contribute to the discussion :-)

-- 
Andy Piper

Sent with Sparrow

--

To learn more about MQTT please visit http://mqtt.org

To post to this group, send email to mq...@googlegroups.com

To unsubscribe from this group, send email to

mqtt+uns...@googlegroups.com

For more options, visit this group at

http://groups.google.com/group/mqtt

[Ian Craggs]

You are right, RSMB recognizes when another RSMB connects to it via a
bridge by using a different protocol version number (when try_private
is true, which is the default). If that connect fails, then the
bridge will fall back to MQTT 3.1. This internal protocol is the
same as MQTT 3.1 except that:

1) the retained flags are propagated on publish packets, and
2) the subscriptions are nolocal (in the JMS sense), to reduce the
chances of infinite message loops.

The goal was to make linking one or more RSMBs together more useful -
MQTT bridges weren't thought of when the protocol was devised.

Ian Craggs

[Roger Light]

Hi Ian,

Thanks for the explanation. I think it's something worth formalising
because it's something that will affect every bridge. I'm certainly
intending implementing the bits that don't already exist in mosquitto.

From a quick investigation rsmb is setting the protocol number to 131,
or 3 (the protocol version) with bit 8 set. That scheme will last
until MQTT v127 which should be fine :)

I've put a bit on the wiki about it:
http://mqtt.org/wiki/doku.php/bridge_protocol

Cheers,

Roger