Echo

[Jeff R. Allen]

Hello,

When a PUBLISH for topic "foo" is sent on a connection which has an outstanding subscription for topic "foo", should the PUBLISH packet be echoed back onto the connection?

The standard does not mention this specific scenario as an exception. Naively following the standard results in getting an echo. I wrote a server and then a few years later when I finally put myself in the situation of getting echos, I was actually surprised that's what I'd implemented...

When writing an MQTT bridge, how do people deal with this? If the bridge uses one connection for both reading and writing, it puts itself in this echo situation, and it has no way to tell which are echos and which are legitmate messages coming from other publishers on the same server.

Thanks for your advice.

  -jeff

[Vitaly Baum]

Hello Jeff,

Formally, it is correct to get the message back if you subscribed to the same topic.

I think that this decision is up to the implementator of the broker and if you want to manage active-active bridge you can resolve infinite echo by splitting re-publishing flow, just like this:

if (package.sender.isLocal) {

  sendToLocalSubscribers();

  sendToBridges();

}

if (package.sender.isBridge) {

  sendToLocalSubscribers();

}

I think that get origination of the packet's sender is easy, for a reason - you have to track all of the connections in the broker.

Good luck!

[Hans Jespersen]

Setting of a "noLocal" flag is something common to many messaging systems at either the broker side or the client side, but it is not part of the MQTT spec as far as I know. There are several workarounds to this such as putting a unique source identifier into the topic name (i.e. topic = {{clientID}}/foo/bar") or into the message body, and then discarding all messages that are a local echo.

 

[Nicholas O'Leary]

The concept of a noLocal flag for subscriptions is being actively looked at for the next version of MQTT - https://issues.oasis-open.org/browse/MQTT-235

Nick

On 31 January 2016 at 20:12, Hans Jespersen <hans.je...@gmail.com> wrote:

Setting of a "noLocal" flag is something common to many messaging systems at either the broker side or the client side, but it is not part of the MQTT spec as far as I know. There are several workarounds to this such as putting a unique source identifier into the topic name (i.e. topic = {{clientID}}/foo/bar") or into the message body, and then discarding all messages that are a local echo.

 

--
To learn more about MQTT please visit http://mqtt.org
---
You received this message because you are subscribed to the Google Groups "MQTT" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mqtt+uns...@googlegroups.com.
To post to this group, send email to mq...@googlegroups.com.
Visit this group at https://groups.google.com/group/mqtt.
For more options, visit https://groups.google.com/d/optout.

[Roger Light]

Hi Jeff,

Outside of the spec, this has been approached in at least two brokers
by using the most significant bit of the version byte of the CONNECT
packet to indicate to the broker that the client connecting is a
bridge. When you are the broker initiating the bridge you already know
of course. In both cases, setting a bridge means implementing no-local
as described by the others, but also that the retained flag on
messages is propagated.

Cheers,

Roger