Client subscribed over multiple devices

[cristian-stoicescu]

Hello.

I was wondering how should I proceed if I wanted to publish a packet to a topic, and would want all the users to receive the publish ,except the devices the original users is connected on.

As a use case, I would want to implement a notifications system over MQTT, but if a user published a packet on a topic, I don't want him to receive the notification of the client's action on the users other connected devices

[mcollina]

What you want is https://github.com/mqtt/mqtt.github.io/wiki/bridge_protocol.

Unfortunately, this is not currently supported in Mosca.

[cristian-stoicescu]

I'm not so sure this would be a good fix. I'm referring to the possibility of ignoring certain subscribed clients which meet a specific criteria, when publishing a certain message from the broker ( all clients are connected to the same broker ) So basically, adding some sort of filter ( probably based on id, regex maybe ? ) when publishing a message from the broker to subscribed clients p.s.: I know this a bit far fetched. I`m just hypothetically asking if this could be done in Aedes

[mcollina]

In mosca there is authorizeForward. I will probably add the same thing here.

[stochris]

Ok. So, instead of directly forwarding, it should call the authorizeForward, which in turn may call the forward callback, right ?

[mcollina]

That's in Mosca, yes.

[cristian-stoicescu]

Yes, in mosca terms. In aedes terms, I`m thinking a callback should be added to the publishActions array ( https://github.com/mcollina/aedes/blob/master/lib/handlers/publish.js#L15 ) I'll have a look when I have some time, and submit a pr if I get anywhere. Is that ok ? :)

[cristian-stoicescu]

I looked around, and from what I can gather, Aedes.prototype.subscribe should recieve the client, in order to be able to do any fine grained filtering based on it and send it further down towards the notify function added in MQEmitter.prototype.on function. Then, more or less wrap every call to the matched topic methods to a authorizeForward function

However, I'd like to hear your input before I change anything, since this looks pretty since this way looks pretty hacky. le: Also, I`m thinking this could really affect perfomance, and given the low overhead of an mqtt packet, the clients could just handle their own filtering, instead of passing the responsibility on the broker.

[mcollina]

I agree with your evaluation on performance, and that's why I did not do it in the first place here.

However, if you can come up with a way that implements this without affecting performance and it's valid, I'll be more than happy to merge it.

I suggest you to put it in https://github.com/mcollina/aedes/blob/master/lib/client.js#L71-L86, and https://github.com/mcollina/aedes/blob/master/aedes.js#L204 (for QoS 1/2 and offline).

Doing it in MQEmitter will be wrong, as authorization is not one of its responsibilities.

[cristian-stoicescu]

Ok, I'll look into it and add some tests once I get it working

[mcollina]

Released in 0.16.0.