Client subscribed over multiple devices about aedes HOT 10 CLOSED

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

Unfortunately, this is not currently supported in Mosca.

from aedes.

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

from aedes.

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

from aedes.

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

from aedes.

That's in Mosca, yes.

from aedes.

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 ? :)

from aedes.

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.

from aedes.

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.

from aedes.

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

from aedes.

Released in 0.16.0.

from aedes.