Integration API for the broker

It is clearly a common use-case to embed the broker in a larger application (Issue #41, #33, #21, #38) that has some functionality, and attempt to talk back to the clients. People keep re-writing the same thing again and again.

Instead of trying to use client and server library withing one application, or using loopback (which is impossible in UWP) we can design an API into the broker that would enable it to create a “virtual” client and talk to other clients on the network.

It would be trivial to implement an event-based API to notify the parent application of new messages, and with a bit of through we can put together an API to “talk back” to the clients.

Integration API

• Presense - See how many clients are connected
• Management Events - Client Joined / Client left events
• Observe - see messages that are being exchanged
• Publish - let the broker send messages. Mosquitto does that on the topic $SYS/, but that’s just a convention
• Subscription Permissions - Not all clients can be trusted entirely. We must have a way to reject a client subscribing to messages they are not entitled to. Here is how Mosquitto implements an Access Control File. In this case we must return 0x80.
• Publish Permissions - Again, not all clients should be allowed to publish anywhere they feel like. However MQTT protocol is not great at dealing with this. As per official spec

If a Server implementation does not authorize a PUBLISH to be performed by a Client; it has no way of informing that Client. It MUST either make a positive acknowledgement, according to the normal QoS rules,or closethe Network Connection [MQTT-3.3.5-2]

[dtflx01]

@VladimirAkopyan I already added ‘ClientJoined / Client Left’ event. feature, see commit 2afb198 . You can merge it, I’m using it into my application. Regards

[dkkriste]

Sending a message should be as simple as calling Publish(MqttMsgPublish publish) in the MqttPublisher manager (you of course would need a reference to that). Observe messages which are exchanged/received could probably be done by subscribing to an event which for instance gets called inside the PublishThread loop (say around line 282 where the incoming messages are dequeued). And querying/exposing the MqttClientCollection clients in MqttBroker.cs should give you a indication on the number of active connections.