Sending one-to-one messages using MQTT

[Zvi]

Hi,

I read the MQTT 3.1 spec and didn't found a way to send one-to-one
messages.
The only way I see is to subscribe each client immediately after
CONNECT to topic "client/<CLIENT-ID>".
Depending on the broker implementation, this can be expensive
operation.
The other way is to create similar "system" or "virtual" topics, to
which each client automatically "subscribed" by server/broker. This of
course requires custom broker implementation and/or standard
convention for interoperability.
Any ideas?

BR,
Zvi

[Karl P]

On 12/25/2011 07:00 PM, Zvi wrote:
> Hi,
>
> I read the MQTT 3.1 spec and didn't found a way to send one-to-one
> messages.

It's been said before, this is pubsub, not direct messaging with support for
multicasting.

> The only way I see is to subscribe each client immediately after
> CONNECT to topic "client/<CLIENT-ID>".

Yep, that's pretty much exactly how we use it. But, although "<client-id>" is
the _intended_ recipient, it's just a topic. More people can listen in, see
what's being said, watch what's going on, graph which clients cause the most
requests, stats on ALLLL the things! If you don't want that, and you want
private encrypted channels, one to one, then a pub sub protocol is not really
what you're looking for.

Or, of course, you add that on top. There's nothing stopping you from public
key encrypting the message bodies, with HMAC signatures appended to the topic
for instance....

> Depending on the broker implementation, this can be expensive
> operation.

Sure, but that's not a protocol problem. That's like saying http is expensive
if the server is stupid. It's true, but so what?

Cheers,
Karl P

[andysc]

We've always erred on the side of simplicity for MQTT, and I've always
argued (perhaps slightly perversely ;) ) that point-to-point messaging
is just a degenerate case of pub/sub, using a pair of privately chosen
topics for talking between two clients via a broker.
Request-Response, similarly, can be implemented quite happily over pub/
sub, using a private topic as the "reply-to" topic in the request to a
service which subscribes to a "well-known" service topic.

We didn't want to go the whole JMS hog with MQTT - mainly so that we
can keep the code size of a full protocol implementation nice and
small :)

Andy

[andyp...@gmail.com]

Sounds like another technique worth adding to the wiki - if anyone has
a minute or two to do so.

Maybe a "tips and tricks" or "messaging techniques" section would be useful...

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

--
Andy Piper | Farnborough, Hampshire (UK)
blog: http://andypiper.co.uk   |   skype: andypiperuk
twitter: @andypiper  |  images: http://www.flickr.com/photos/andypiper

[Zvi]

Hi,

If MQTT's goal is inter-op between devices, then it would make sense
to have a standard convention for one-to-one messaging.
Otherwise each MQTT user will invent his/her own way of doing simple
things.
It's no doubt, that I can implement efficient and scalable one-to-one
messaging in my own MQTT broker, but it will be not compatible with
other brokers.

Zvi

[andyp...@gmail.com]

Well - it's not about the broker - it's between the clients.

I think the point that Andy (and Nick, in another thread) made is that
one-to-one is essentially just an agreed topic pair between clients?
That's all it needs to be, doesn't it?

[Zvi]

Andy,

in theory single client can be equated to topic with single
subscriber, but in practice it's not.
From the point of view of broker implementer it's hard to implement
scalable broker when you don't know if topic has only one subscriber
or multiple subscribers. I can do a lot of optimizations if I know
that specific topics supposed to have only zero or one subscriber.
Again I do not propose changes in MQTT spec, just a convention agreed
between all MQTT developers, how to encode single-client topics. It
similar how twitter users invented @-notation and #-notation.

BR,
Zvi

On Jan 9, 8:23 pm, "andypipe...@gmail.com" <andypipe...@gmail.com>
wrote:

> > To learn more about MQTT please visithttp://mqtt.org

[Nicholas O'Leary]

The version of RSMB that ships with MQ recently added the ability to
push a message to a client based on its client ID. I don't know if
this has filtered through to the version of RSMB on alphaWorks.

The convention used is:
publish to $SYS/client/<clientId>/<topic> (where <clientId> is the id
of the client you want to push to and <topic> is an optional extra
topic string)

The client will then receive the message even if it hasn't subscribed.

You can also publish to $SYS/all-clients to push a message to all
connected clients.

$SYS/ has always been considered a broker-specific topic space. In
RSMB, subscribing to # does not get you topics in the $SYS/ namespace,
you have to explicitly describe to $SYS/#. This is another one of
those unwritten conventions we have used over the years.

MQ also has the ability to push to a client if you put a message on a
queue with a specific name (can't remember the convention used there)
- but that's more a function of the MQTT support in MQ, rather than
that of a pure MQTT broker.

> From the point of view of broker implementer it's hard to implement
> scalable broker when you don't know if topic has only one subscriber
> or multiple subscribers.

I'd disagree with that, having worked on two separate broker
implementations (one in C and one in Java) - but it does depend on how
you've structured your subscription model.

Nick

Nick

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