I would like to know if it is possible in a standard MQTT bridge configuration with Mosquitto the dynamic subscription of topics from the MQTT clients to the remote broker.
That is, only if a client requests the subscription to a certain topic, it is Mosquitto who requests to the remote broker the subscription to that topic.
From what I have seen in the configuration it is possible to set it statically when starting the Mosquitto service but not dynamically according to the requirements of the MQTT clients who can decide at runtime to which topics they want to subscribe.
Is it possible in a Mosquitto bridge, a dynamic subscription scenario in which the subscription request of the clients is forwarded to the remote broker?
It is not possible, the broker does not support dynamically changing the bridge subscription.
It's also doing dynamic subscription forwarding won't work well in a situation where usernames/password and ACLs are implemented because the bridge connection acts as any other client connection. This means that the bridge connection can only subscribe/publish to topics allowed by the user assigned to the bridge.
Both brokers are likely to have very different sets of users and ACLs in place
Related
I wanted to make use of Shared Subscription feature of MQTT v5. But currently I am using AKKA MQTT client which doesn't support MQTT v5 client. Can I still use v3 MQTT paho client and use Shared Subscription feature?
That should not be a problem as from the viewpoint of an MQTT v3 client a shared subscription is just like any subscription.
The broker has to do all the work regarding shared subscription logic.
The only hindrances I can see are:
that an MQTT broker might support v5 but not v3/v3.1.1
the broker doesn't support shared subscriptions in general (yes they exist)
the broker supports all MQTT versions but handles them as two different protocols (not sure if this is a thing)
Using paho client write an app(ensure that this will use MQTT v5) that will have two clients.
Client_v3 will subscribe to the topics from the source i.e. from the app that sends MQTT v3
Client_v5 will publish the received topics as it is received in the above step.
In your application where you want to use shared subscription(again ensure it uses MQTT v5) alter the topics $share/<topic> and make it to get the topics from the client_v5 publish
In simple word: make you paho client code to act as a broker between v3 and v5 apps.
There are 2 clients (A and B) that are connected to the ActiveMQ Artemis broker. The protocol we are using is MQTT. Both clients have different topic templates that they subscribe. For example client A has subscription topic template of school/readings/# and client B has subscription topic template of Domestic/readings/#.
There will be our server that subscribes all the topics with their respective template.
If client B decides to read all the incoming messages to the broker by subscribing with topic (# or school/#) then there could be a data leak. The requirement here is only our server should subscribe all the topics and other client should have restrictions in topic subscription.
Is there any way to restrict clients subscription or is there any way to avoid this type of data leak?
Both the clients should have the privilege to publish and subscribe to the broker, but one client should not subscribe to another client's topics.
There is no data leak, unless you configured authorization rules and they are not being enforced or you find a way to get unauthorized access when security is enabled (in that case open a bug here). Please, find out here the documentation on how to use security-settings to configure the authorization rules for your use case.
I have been able to set up a wireless mesh network using batman-adv running on a few Raspberry Pis. The Pis are able to detect each other on the mesh, communicate between each other, and share an internet connection if any Pi on the network is acting as a gateway.
The problem I am facing is that if multiple gateways exist on the network, the clients (devices which are receiving the internet connection by the gateway) will never switch to getting their internet connection from any other gateway than the one they initially obtained it from, even if the routing algorithm detects that they have a better connection to another gateway.
Each gateway is running a DHCP server to assign IP addresses to the clients accessing the internet through them. The DHCP server I am using is dnsmasq.
The expected behaviour is either:
the clients send a DHCP request to the gateway capable of providing the better connection and end their lease with their current DHCP server, or
the clients keep their assigned IP from the DHCP server and (magically?) start accessing the internet through the gateway capable of providing the better connection.
Neither of these scenarios are happening. If for whatever reason the gateway providing the internet to a client drops, the client will not attempt to create a new connection until the DHCP lease times out. However this is contradictory to what is claimed on the wiki for this package: https://www.open-mesh.org/projects/batman-adv/wiki/Gateways
Please advise on how to configure this mesh network so that either one of the expected behaviours will happen.
This is exactly the expected behavior at the IP layer.
If a DHCP server provides a default gateway, that gateway remains in place for the life of the lease. The DHCP client, by design, cannot definitively determine if the default gateway is down.
DHCP is a poll-based protocol; a DHCP server cannot proactively change the parameters of a lease until the DHCP client requests an update. The instructions in the link of your question indicates that (emphasis added):
To inform clients possessing a valid DHCP lease about a gateway
change (the link quality to the gateway could have dropped or the
client is roaming around) batman-adv will also inspect incoming DHCP
renewal packets. If their destination is not the currently selected
gateway and below a certain TQ threshold (currently defaulting to a TQ
of 50), the DHCP renewal packet is not forwarded, thereby forcing the
client to request a new DHCP lease from a better-connected gateway.
Note that the change happens by inspecting incoming renewal packets. Due to the nature of DHCP, you are stuck waiting for a lease renewal request to update the gateway.
You can set low lease times to increase the polling rate, but if you need real-time reaction to failed gateways, you will need to employ an actual routing protocol.
Does Solace support the idea of a client having multiple topic subscriptions that are multiplexed over a single tcp connection?
Yes, you can run multiple topic subscriptions over the same Solace session which connects to one Solace appliance's host and port. Most middleware providers implement this multiplexing however.
MQTT Broker can disconnect the existing client if the following condition is came up.
http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html#_Toc398718090
If the ClientId represents a Client already connected to the Server then the Server MUST disconnect the existing Client
[MQTT-3.1.4-2].
At this time, can broker send any specific message excluding "DISCONNECT" to client before server disconnect the existing client ?
Most brokers are going to follow the spec, if you want one to do something different then you will have to either write your own or modify one of the open source versions.