Is there any way to let MQTT server work as a p2p message sender instead of publish/subscriber mode

[Henry John]

Hi, all

    We are learing mosquitto as MQTT server. Our use case is that one broker will send messages to specified mobile clients, and that how to filter out those clients is  varied  for different messages. So we need to send message to some client ids instead of a fixed topic. Is there any suggestion?  We found that somebody made every registration of mobile client as a topic, but sometimes this seems to be poor efficiency.

Regards!

[Darren Clark]

A couple of suggestions...

1) Can the targets be grouped in some logical way that is known to the clients? i.e. Can they subscribe to topics to indicate a group of clients that will always receive that message? Then you can just set up topics where only the expected clients are subscribed.

2) If you don't know that beforehand, but can logically segregate groups, you could have a topic per client that tells that client what topics it should receive.

Both of those assume that you're not worried about unauthorized/malicious subscribers since the client CAN receive everything, it just chooses not to.

If you have to worry about security, then you'll need some sort of auth plugin, and smarts to decide what clients receive what messages somewhere. 

One option would still be the single topic per client, where a trivial auth plugin would only allow subscription to that topic or tree. Then the publisher of the messages would have to decide which clients to publish the message to. 

Another option would be to put that logic in the plugin, since message sending(at least in mosquitto) is authorized on a per message per client basis, you could publish once, then restrict delivery. That does mean that you're business logic is at least marginally tied to what MQTT broker you're using, since it's wrapped in a plugin and implemented in a compatible language. 

What you're not going to be able to do is have some mechanism to direct traffic to one particular client, MQTT just isn't designed for that use case.

-Darren

--
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 http://groups.google.com/group/mqtt.
For more options, visit https://groups.google.com/d/optout.

[Henry John]

If everay client subscribes a single topic, then where will be millions of topics  in the MQTT server, whould not it be very slow to push a message?

Regards!

[Henry John]

If the topic publishd is made of many pieces of  regular expressions, or it can access many subscribe rules,  Then  we can dynamically send message to our deamed clients?

Regular

On Tuesday, February 10, 2015 at 11:11:19 AM UTC+8, Darren Clark wrote:

[Doug Meredith]

I think you need to put aside your pre-conceived notions of how you want this to work, and get a better understanding of how MQTT works.  Perhaps you could think about groups of clients, probably with clients able to be in more than one group. These groups may map to topics.

If you can't make the concept of publishing to topics work for your application, then you may have a need that isn't met by a publish/subscribe architecture.

[Darren Clark]

Yes, if the main goal is bidirectional communication to and from a single device, then pub/sub isn't really the right metaphor. OTOH I don't see a huge problem with the topic per device pattern.

I think my use case is fairly typical, where I have clients out in the field, that will send messages and/or update retained topics with their activity and status. They also listen to various topics for command/control messages, including a topic with their id. My structure has their primary group in the topic too. e.g. <groupid>/<deviceid>/<stuff>, and they understand messages sent to <groupid>/<control>. They publish along the same lines. Personally I'm not concerned about scaling, since it's easy enough to partition across servers. Either by groups, or if by id then publish group messages to all servers. 

Pub/sub works well for me, because there are multiple listeners for status updates, some of them transient(like a web page) and others that forward some things to a database. They clients are also behind firewalls, so for communication TO the client I'd have to build another system, so I do that over MQTT as well.

-Darren 

--

[Henry John]

Yes.  Our request is not  pub/sub  mode at all. We need to make a service just like the GCM (Google Cloud Messaging for Android), We need to push messages from our platform to target android clients with of one-way communication.  GCM push service may lost some clients and the push delay is distinct, so we want to build our push platform.  MQTT is a mature protocol, But its pub/sub mode is not fit our needs.

Regards!

在 2015年2月11日星期三 UTC+8下午6:07:52，Darren Clark写道：

[Terry Wilkinson]

You might want to look at ZeroMQ (http://zeromq.org).  It implements quite a number of different messaging patterns.

Terry