I have two durable queues in two different VPN's , but both VPN's on same appliance. Client connects to VPN1 and post messages on durable queue. I want to send same messages to durable queue on VPN2. so the receiving client can consume the same messages. Is this possible using VPN bridges?
Note: Client can connect only to Durable queue to send/receive messages.
Is this possible using VPN bridges?
Yes. You can create a local loopback VPN bridge between the two VPNs to move messages from one VPN to another.
Instructions to configure a VPN bridge can be found over at http://docs.solace.com/Configuring-and-Managing-Routers/Configuring-VPN-Bridges.htm
Related
I am developing an application with MQTT and here i am facing same messages are coming multiple times to the same topic instead of one message.
I am using a mosquitto broker, which is also bridged to another cloud private mosquitto broker and client is one paho mqtt client and An android MQTT Application.
Can anyone tell me what could be the reason for above scenario. During publishing also we can experience multiple messages at the subscriber, just for one publish.
This is the Broker Configuration
connection GlowFY-GWY-b827eb83b211
address xx:xx:xx:xx:1883
topic GlowFY/# both 0
Imagine an MQTT broker with remote clients connected, which continuously send QoS 2 data - the standard situation. Clients are configured with "cleansession false" - they have a queue to send messages in case of a connection failure.
On the server, local clients subscribe to topics to receive messages.
Server load:
Launch the MQTT Broker
Running local clients
Connecting remote clients and receiving data from the queue
What if the third point occurs before the second? Are there standard solutions? How not to lose the first messages?
Assuming you are talking about all later reboots of the broker, not the very first time the system is started up then the broker should have stored the persistent subscription state of the clients to disk before it was shutdown and restored this when it restarted. This means that it should queue messages for the local clients.
Also you can always use a firewall to stop the remote client being able to connect until all the local clients have started, this would solve the very first startup issue as well.
We have an IoT based application device which is configured to communication with our Dashboard via MQTT bridge from Various service providers like Google, AWS and Azure.
So the flow is:
Device start TLS session with service provider.
Subscribe to a particular topic and wait for messages from the
service provider with 5 second timeout.
Dashboard publishes messages to same topic periodically.
IoT service provider broadcast it to all devices subscribed.
Publish and subscribe messages are with MQTT QOS 1 services.
Observation:
AWS and Azure works fine with above flow, but device stop receiving messages from Google MQTT bridge after 3-5 successful iterations even though our dashboard is publishing messages to Google IoT MQTT bridge.
For Google, we have identified that control flow is different when compared with Azure and AWS.
For Google, we need to subscribe and un-subscribe for a given topic every-time before waiting to receive message while for AWS and Azure we need to subscribe once during opening a MQTT connection.
Issue:
Sometime 5 sec device timeout occurs as it could not receive messages for subscribed topic from Google MQTT bridge. Adding multiple retries to overcome timeout issue was unsuccessful as issue still persist as device could not receive message from Google MQTT bridge after 45-60sec of device operation after powering on.
Is there is constraint with Google MQTT bridge to receive messages periodically without subscribing it every-time?
How can device receive messages without timing out (5 sec) from Google MQTT bridge?
Is there any workaround to recover a device once it got timed out with establishing MQTT reconnection?
I am using google iot core as well,the device side code for the mqtt client is golang while using paho mqtt package. this client package support OnConnect handler which while using this handler I achieve the recovery which I think you are looking for.
Via this handler I am re-subscribing to the "config" topic.
I think that google does not save the subscriptions which the clients are subscribed to and therefore the client needs to re-subscribe upon successful connection
Here's the golang code I've used (inspired by gingi007's answer, thank you!)
var onConn MQTT.OnConnectHandler
onConn = func(client MQTT.Client) {
fmt.Println("connected")
client.Subscribe(topic.Config, 1, handlerFunc)
}
mqttOpts.SetOnConnectHandler(onConn)
client := MQTT.NewClient(mqttOpts)
this way config updates keep flowing to my device, while if you subscribe outside of the onConnectHandler you'll just receive one config update when you connect.
I understand that I can consume messages from a Solace Durable Queue using either JCSMP or JMS API. I wonder whether I can consume messages from a Solace Durable Queue using MQTT. I tried but I never get it work. My MQTT client tried to subscribe to Durable Queue name but messages in the queue were not delivered to my MQTT Client.
My scenario is the following:
Clients from the Internet publish messages to some topics in Solace using MQTT while I have some Durable Queues subscribing to these topics to "attract" messages published to these MQTT topics so that I can process them later. I would like to standardize message exchanges to use only MQTT. Therefore, I would like use MQTT to consume messages stored in this Durable Queues too. Any advice how I can do that.
Thank you.
The MQTT protocol does not have the concept of queues.
For your use case, your MQTT clients will need to create a durable session, with QoS 1 subscriptions.
This will cause the Solace Appliance/VMR to create an internal durable queue that will spool messages for the client.
I am new to MQTT protocol. I tested the MQTT broker which facilitates the publishing from my android phone and subscription of my IOT actuators(Motors). But I am confused, as how to enable actuators to work only from a particular publisher. In otherwords, I want to control my MotorA from my PhoneA and MotorB from PhoneB and so on... I don't know how to get started outside the localhost(LAN) to make my broker work with the help of internet.
I am using Mosquitto broker and ESP8266 as client. Please share your views on how to get started with Mosquitto broker hosted on internet.
Hosted MQTT (e.g. https://www.cloudmqtt.com/) is no different than your local Mosquitto broker except that's in the cloud.
As for how to route publishers you can do that either based on an attribute of the published message e.g. something like motorId or you can publish to different queues. Hence, phone A could publish to queue motor-a and phone B could publish to queue motor-b. The application on the ESP8266 would subscribe to both and act accordingly.