Unsolicited messages

[Jeremy Turner]

Hello 

I have a hardware device that uses unsolicited messages. 

I.E the device does not subscribe to a topic first. You send a message direct to the device. The device then replies to a topic.

This operation is supported in IBM MQ:

https://www.ibm.com/support/knowledgecenter/en/SSFKSJ_7.0.1/com.ibm.mq.amqtat.doc/tt20026_.htm

I am looking for an open source broker than can implement this.

Any suggestions.

Thank you

[Karl Palsson]

Jeremy Turner <jer...@fabcontrols.co.uk> wrote:
> Hello
>
> I have a hardware device that uses unsolicited messages.
>
> I.E the device does not subscribe to a topic first. You send a
> message direct to the device. The device then replies to a
> topic.

there's nothing that requires anyone to subscribe to anything
before they publish in MQTT. Any broker, and any client library
will support this out of the box.

mosquitto_pub, the command line utility for instance, does
exactly this.


Cheers,
Karl P

[Jeremy Turner]

Hi

I guess i didn't explain this clearly.

The I need to send to the device. Without the device first subscribing. 

The device will accept a unsolicited message but most brokers will only send to subscriptions.

[Andy Stanford-Clark]

interesting. 

I assume you can’t change the code on the device?

Does the device connect with clean session true?

Does it always use the same client ID when it connects?

… I might have an idea for a cunning hack, depending on the answers to these ;)

Andy

--
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.

[Andy Stanford-Clark]

note this behaviour is not supported in the MQTT spec - a client can only receive a message on a topic to which it has subscribed (either in the current session (for clean session true), or previously if it is using clean session false.

It is surprising that an MQTT-compatible device should rely on this oddity of the MQ-MQTT bridge.

Andy

On 25 Apr 2018, at 16:56, Jeremy Turner <jer...@fabcontrols.co.uk> wrote:

[ran...@bevywise.com]

@Jeremy : 

In real world scenario, from a client perspective, the unsolicited message can again be a solicited one with a perfectly predefined format and an already existing client side implementation.  

Unless you are building a highly intelligent robot as your client which can understand all the human nuances, sending unsolicited messages will not work. 

It is better to have an universal common topic to which every client subscribe to and publish message from the manager in the predefined format and client having the implementation in place

Interested in knowing the usage of the scneario. 

Cheers, 

Ranjith 

Bevywise Networks, 

www.bevywise.com 

[Dominik Obermaier]

Hi Andy,

I’m unable to find the part in the current 3.1.1 specification that says that it’s explicitly disallowed to deliver messages to clients that don’t have a matching subscription. As far as I see there’s no passage that explicitly disallows such an behavior.

I agree that this is a very uncommon use case to send messages without subscriptions but it seems that most clients support this, though.

Best,
Dominik

[Karl Palsson]

"Dominik Obermaier" <dominik....@gmail.com> wrote:
> Hi Andy,
>
> I’m unable to find the part in the current 3.1.1 specification
> that says that it’s explicitly disallowed to deliver messages
> to clients that don’t have a matching subscription. As far as I
> see there’s no passage that explicitly disallows such an
> behavior.
>
> I agree that this is a very uncommon use case to send messages
> without subscriptions but it seems that most clients support
> this, though.

Support in as much as they don't check incoming publishes against
subscriptions because they simply can't. They could have been
connected with cleansessino=false, ans the subscription was sent
in the past.

The bigger question is how would you configure this, and how
would it in any way be simpler than just having
cleansession=false? You still can't send anything until the
client connects, because you don't know where they are.

Cheers,
Karl P

> >> <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

> >> <mailto:mqtt+uns...@googlegroups.com>.

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

> >> <mailto:mq...@googlegroups.com>.

> >> Visit this group at https://groups.google.com/group/mqtt

> >> <https://groups.google.com/group/mqtt>.

> >> For more options, visit https://groups.google.com/d/optout

> >> <https://groups.google.com/d/optout>.

[Dominik Obermaier]

Hi Karl,

> Support in as much as they don't check incoming publishes against
> subscriptions because they simply can't. They could have been
> connected with cleansessino=false, ans the subscription was sent
> in the past.

That might be true that some clients may lose track of their own state
and that the subscriptions are “forgotten”. It is likely in such
cases that QoS message flow tracks are also lost, which is a dealbreaker
for QoS > 0 guarantees. Many environments I’ve seen have clients which
actually know their subscriptions even if the application restarts and
the broker returns a “sessionPresent” flag.

> The bigger question is how would you configure this, and how
> would it in any way be simpler than just having
> cleansession=false? You still can't send anything until the
> client connects, because you don't know where they are.

While I agree that it’s uncommon and not an elegant solution to
receive message no subscription was created for, I fail to see anything
in the specification which explicitly disallows such an behavior.

Best,
Dominik

[Sumeet Puri]

Hi, 

In my experience, the use case is not that uncommon after all, and applies in a variety of industries. Many a times, the device is “dumb” and even needs to know which topics it should subscribe to. 

While the spec does not talk about such behaviour, it also doesn’t disallow it. 

A device during bootstrap can be allocated unique topic based on a well known convention and that becomes an “inbox” topic for the device. So any messages published to that topic will get to the device. This is also useful in request reply scenarios, which also is common and useful, but not there in the MQTT spec. This unique “inbox” topic can also serve as a “reply To” topic for the device. A code example here: https://dev.solace.com/samples/solace-samples-mqtt/request-reply/

Take an example from another industry Stock Trading. MQTT, due to it’s lightweight and bidirectional nature, is getting more and more adopted in trading platforms to stream market data instead of vanilla web sockets. 

Now consider the scenario of watchlist management - if I have a watchlist of my 20 stocks, the watchlist is often stored on the server side, with my entitlements. So when I login, the server side subscribes me to my topics, each topic matching a stock I care about. It’s a very useful behaviour which greatly simplifies and secures subscription management and can work well with MQTT, if the broker supports it.

Thanks and Regards, 

Sumeet. 

[Jeremy Turner]

Hi

No cannot modify the code on the device.

Yes always the same client id.

[Jeremy Turner]

Hi Dominik

Can you please send me a PM I have been trying to reach you but your company will not put us in contact.

[Andy Stanford-Clark]

here was my idea:

This will only work if the device connects with clean session *false*…

Use another client, using the same client ID as the device, to connect (also with clean session false), subscribe to the topic the device expects to receive its unsolicited message on, then disconnect.

When the device reconnects (with clean session false) the subscription will already be on the broker for that client ID, and it will receive messages published to its topic.

*if* all the devices connect with clean session *true*, this won’t work, as the subscription won’t survive the reconnect of the fake client and the real device.

One possible hack, if you get really desperate, is to run a proxy in front of the broker, which either sets clean session false on incoming CONNECT packets, OR (if you’ve gone this far, you might as well do this…) sends in a subscribe on behalf of the device in the connection stream (and swallows the SUBACK), so the broker thinks the device did actually subscribe.

Andy

[Andy Stanford-Clark]

Hi Dominik

thanks to Richard Coppen for some studious research on this for me…

You are quite right, it doesn’t say you can’t do this in the 3.1.1. spec. In fact, in section 4.5, it says  you CAN:

A Client could also receive messages that do not match any of its explicit Subscriptions. This can happen if the Server automatically assigned a subscription to the Client.

The thinking behind this was “administrative subscriptions”, that is, a broker might allow an administrator to pre-subscribe certain devices to certain topics, so they didn’t have to do it themselves each time they connected.

Back in the mists of time, the use-case was a real one, and we put that clause in to allow it to happen.

This functionality also applies in v5.

You may be interested to note that in 3.3.2.1, it says the broker can also change the topic if it wants to.

"However, since the Server is permitted to override the Topic Name, it might not be the same as the Topic Name in the original PUBLISH Packet."

Andy