[Interest] MQTT Client Message Routing

[Maurice Kalinowski]

Hi Andrew,

The answer is as usually: It depends.

Generally most people use it in a way to keep the subscription (and its messages) close to where the application logic happens.
In your described scenario, it'd be appropriate to handle separate subscription objects for each client. That way you spare one level of filtering.

You could consider using the '#' wildcard though instead of the '+' for this setup, "app/users/$user/$client/#". Usually you use the + only for subitems, as in "get all conversations" app/users/+/$client/conversations.
Furthermore it helps when you introduce additional levels to the subscription. Using + you would not get any notification, while for # it continues to work.

Maurice


> -----Original Message-----
> From: Interest [mailto:interest-bounces+maurice.kalinowski=qt.io at qt-
> project.org] On Behalf Of Tony Rietwyk
> Sent: Monday, January 29, 2018 12:58 PM
> To: interest at qt-project.org
> Subject: Re: [Interest] MQTT Client Message Routing
> 
> Hi Andrew,
> 
> I haven't used QMqtt.  Nonetheless, I would suggest a hybrid - using a
> separate subscription object for each folder in the hierarchy.  So the client
> subscription only needs to match on the terminal symbol and coordinates all
> of the actions relating to clients.
> 
> Regards, Tony
> 
> 
> On 29/01/2018 10:21 PM, Andrew Ialacci wrote:
> 
> > Hello Qt Friends!
> >
> > When using the QMqtt library, I've noticed there are two possible ways to
> inspect messages received by the client from the broker.
> >
> > 1. QMqttClient::messageReceived(const QByteArray &message, const
> > QMqttTopicName &topic) 2. QMqttSubscription::messageReceived(const
> > QMqttMessage & message)
> >
> > I understand that the first will be a firehose of all messages being received
> by the client. The second is to only see messages having to do with a specific
> subscription.
> >
> > Consider the following scenario:
> >
> > // Example Topic Hierarchy
> > - app/users/$user/$client/friends
> > - app/users/$user/$client/conversations
> > - app/users/$user/$client/events
> >
> > // Questions:
> >
> > - Is it better to maintain individual QMqttSubscription objects for all
> possible topics a client is interested in and connect to each
> QMqttSubscription::messageReceived signal?
> >
> > - Or does it make more sense to have a single subscription to a root topic
> (where applicable, in this case: "app/users/$user/$client/+" ), a bunch of IFs,
> and QMqttTopicFilter::match(const QMqttTopicName &name) to handle
> each case?
> >
> > - It feels like maintaining a huge list of subscription objects will get
> annoying. However, is doing so worth it in terms of performance? Does it
> somehow reduce the overhead of matching strings all over (either internally
> in the QMqttClient or by my calling QMqttTopicFilter::match)?
> >
> > // Example of "switching" on topic in a
> > QMqttSubscription::messageReceived handler // using
> QMqttTopicFilter::match.
> > // Note:
> > //   Please ignore syntax / coding / technical errors.
> > //   This was written freehand purely to illustrate my point.
> >
> > void AppMessageRouter::handleMQTTMessageReceived(const
> QMqttMessage
> > &mqttMessage) {
> >      if
> (QMqttTopicFilter("app/users/$user/$client/friends").match(mqttMessage.t
> opic()) == true)
> >      {
> >          this->routeFriendsMessage(mqttMessage);
> >          return;
> >      }
> >
> >      if
> (QMqttTopicFilter("app/users/$user/$client/conversations").match(mqttMe
> ssage.topic()) == true)
> >      {
> >          this-> routeConversationsMessage(mqttMessage);
> >          return;
> >      }
> >
> >      if (QMqttTopicFilter("app/users/$user/$client/ events
> ").match(mqttMessage.topic()) == true)
> >      {
> >          this->routeEventMessage(mqttMessage);
> >          return;
> >      }
> > }
> >
> > Thanks for your time!
> > 🍍
> >
> >
> >
> >
> >
> > _______________________________________________
> > Interest mailing list
> > Interest at qt-project.org
> > http://lists.qt-project.org/mailman/listinfo/interest
> 
> _______________________________________________
> Interest mailing list
> Interest at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest