I have established a MQTT bridge connection between Mosquitto and EMQ.
1) Is the bridge connection between 2 MQTTs always stable?
2) If not, how does it handle the Data Communication when the bridge is down?!
We have no idea how stable your network is, so we can't comment on how stable a bridge connection will be. But just like other MQTT connections they are a persistent connection (not per message)
It depends... on many things, such as what QOS the messages are published/consumed at. But with the right settings the messages should be queued on the which ever end of the broker they arrive at and then be pushed over the bridge when it is re-established.
The stability of emqx depends on the network status between two mqtt brokers. In the implementation of the emqx bridge, if the connection between emqx and mosquitto is broken, the messages which would be forwarded to mosquitto will be cached in disk or memory, and when the connection is resumed, the cached offline messages will be forwarded to mosquitto.
Related
If I was using thinsboard.cloud then I was putting MQTT broker name as thingsboard.cloud . But as of now I have deployed things board at GKE so what MQTT broker I can use to communicate. I tried to put public Ip address of the same but not working
The Public IP Address should be correct. Unless you changed it, the default port for MQTT in ThingsBoard is 1883.
Probably there are network restrictions, which not allow you to make connections via MQTT port 1883.
I've read that two applications/processes cannot listen to the same port at the same time. I'm wondering if unix based systems simply "deny" creating a new socket and allocating new memory(duplex) for the socket whenever App2 requests a socket with the same port number as App1.
So does it "deny" App2 like I suspect or does it go ahead and create a new socket and allocate the required socket memory for App2 anyway.
If it does allocate new memory, then how does it prevent App2 from listening. And how does the client know which socket to receive the information that the server sends since both of them use the same port. I need a lengthy explanation if possible because I'm pretty confused. Thanks
I've read that two applications/processes cannot listen to the same port at the same time.
They cannot listen on the same port on the same network interface at the same time, unless the SO_REUSEADDR/SO_REUSEPORT socket options are used. Otherwise, it is possible for them to listen on the same port on different network interfaces.
So does it "deny" App2 like I suspect
Yes, the 2nd app will get an EADDRINUSE error from bind() if it cannot bind the socket to the specified interface/port.
or does it go ahead and create a new socket and allocate the required socket memory for App2 anyway
The socket will have been created before the bind() attempt, so yes. The socket just won't be bound to the port that is in use.
If it does allocate new memory, then how does it prevent App2 from listening.
listen() will fail if the socket is not bind()'ed to a port.
I have three VMs (VirtualBox, Ubuntu 18.04). All of them with Mosquitto broker (configured as default localhost:1883). Two VMs are PUB with private IPs and a "server" is a SUB (assigned via DHCP -bridged-). What I have is:
VM1 (PUB) [192.168.1.66]
VM (SUB) [192.168.1.55]
VM2 (PUB) [192.168.1.74]
The idea is the SUB to receive MQTT from all PUBs, however, it only works if the MQTT client is configured as following
VM1 [192.168.1.66:1883] --> VM [192.168.1.66:1883] <-- VM2 [192.168.1.74:1883]
So, the SUB will only receive messages from VM1 but not from VM2 neither other VMs (PUB). How can I configure the mosquitto and the client at the SUB to receive messages from all PUBs?
A MQTT client instance can only connect to a single MQTT Broker.
You have 2 options.
Run just one broker on any of the 3 machines and have all the publishing clients just publish to that broker and likewise the subscriber .
You can configure one of the brokers to bridge to all the other brokers and subscribe to any messages published on those broker so they they will appear in the topic hierarchy of that single broker.
Details of how to configure mosquitto bridges can be found in the man page here
I'm working in mqtt broker bridge, I have to connect local mosquitto to remote mosquitto.
connection remote-mosquitto-bridge
address 10.1.0.9:1883
topic test both 1
Above code is added in mosquitto.conf file for connect remote machine(10.1.0.9 is my remote)
its enough for message sharing to local to remote
You need config the listener port
ex:
if your diagram is like that
broker 1 => broker 2
Broker 1 mosquitto.config:
connection remote-mosquitto-bridge
address 10.1.0.9:1883
topic # both 0
Broker 2 mosquitto.config:
port 1883
listener 8883
This work for me.
source:
https://medium.com/jungletronics/mosquitto-bridge-5b44e9687fb3
I need to be able to read/write to an Azure Service Bus Queue and for that, the hostname and ports need to be white-listed by my IT team.
The connection string is: "Endpoint=sb://[myappname].servicebus.windows.net;...".
I have tried the hostname with port 443 (assuming here), but that hasn't worked after white-listing. So now I tried writing to queue while capturing the traffic from Wireshark, but I am getting lost in all the network packet details there.
Can anyone please help me with this?
Thank you
TCP port is used by default for transport operations. Please have a try to open the port 5671 and 5672. We could get more information from AMQP 1.0 in Azure Service Bus and Event Hubs protocol guide.
Azure Service Bus requires the use of TLS at all times. It supports connections over TCP port 5671, whereby the TCP connection is first overlaid with TLS before entering the AMQP protocol handshake, and also supports connections over TCP port 5672 whereby the server immediately offers a mandatory upgrade of connection to TLS using the AMQP-prescribed model. The AMQP WebSockets binding creates a tunnel over TCP port 443 that is then equivalent to AMQP 5671 connections.
If you use a library, please have a try to set the ConnectivityMode to https (443 port)
ServiceBusEnvironment.SystemConnectivity.Mode = ConnectivityMode.Https