Server Side Subscribe

[behrad]

To attach logic into message publishes on different topics, we have three options:

1) server.on( 'published', ...): This way your handlers should pattern match all input messages, not seem good in real world production.

2) Create a MQTT client, connect it to the local server and subscribe on desired topic to receive only needed messages...

3) server.subscribe which does the above but inside the broker, no need to create a separate client.

Should we add the last one into mosca? I want to hear your comments on the best solution @mcollina

[mcollina]

Hi @behrad, yes this functionality is needed. So needed that I added it in Aedes: https://github.com/mcollina/aedes#subscribe.

Here you can tap into the internal ascoltatore using server.ascoltatore. Let me know if that solves your problems.

[behrad]

Can you tell me the preferred specification of such a method?

server.subscribe( subs, cb );

where subs is:

{
  clientId: "clientId"
  subscriptions:[{topic: "someTopic", qos: 0 }]
}

is this OK?

[behrad]

I provided a PR adding a generic subscribe method. By that PR this topic shall be closed, however I faced up with another situation that I mentioned in comment above.

That is adding also a subscribe method to subscribe on behalf of a client at server side. I first want to hear @mcollina ideas about this however.

[behrad]

There's still something missing here, via published event you have the publisher context (client.id who is publishing), however with server.subscribe that is not available. So that is not replaceable as a more performant method of attaching app logic on message publishes on a specific topic (since app needs more detailed context about the message published)

server.on( 'published', (packet, client) =>{} );

However

server.subscribe(topic, (topic, message) =>{});

for this problem, It seems second approach is the best, aint?

[mcollina]

Yes, go for the second approach!

[behrad]

Yes, go for the second approach!

the just want to ask to ensure if second version works in a clustered (multi mosca instances + single redis) environment, so that when each MQTT client subscribes to it's own mosca instance, then it only receives publishes of the connected instance, so no message is processed in two subscribed workers, and also there's no SPOF, and also good work distribution when handling large traffic. right?

[mcollina]

No. Subscribe is an MQTT subscribe, so it's global (across the cluster). To avoid SPOF you need to used the published event.

If you just want a router for your on('published') events, just use qlobber or MQemitter or another (in-memory only) instance of Ascoltatori.

Matteo Il giorno sab 6 feb 2016 alle 15:43 Behrad notifications@github.com ha scritto:

Yes, go for the second approach!

the just want to ask to ensure if second version works in a clustered (multi mosca instances + single redis) environment, so that when each MQTT client subscribes to it's own mosca instance, then it only receives publishes of the connected instance, so no message is processed in two subscribed workers, and also there's no SPOF, and also good work distribution when handling large traffic. right?

— Reply to this email directly or view it on GitHub https://github.com/mcollina/mosca/issues/408#issuecomment-180779544.

[behrad]

If you just want a router for your on('published') events, just use qlobber or MQemitter or another (in-memory only) instance of Ascoltatori.

I think my current on('published') workers are OK then, I can enhance them performance by using one of above then (as mosca does) :+1: Thank you dude :)