Multiple Mosquitto brokers to exchange data between devices - ip

I have 3 devices each of them have Mosquitto broker running on them. Each of this device has subscriber and publisher.
I am using IP of each device to open port at 8883 and exchange messages --> subscribe/publish their messages. If the case happens to be that devices use dynamic IP., How can I publish new IP-PORT address to its clients that are already connected? How to tackle this problem. Is my approach correct? Is there any other way I can create my own private IP-PORT address to the broker?

Your broker needs to be reachable at a known location, be that fixed IP address or a DNS entry that points to it's current IP address.
Any clients connected at the time the IP address changes will be disconnected and will need to reconnect.
You've not said if these are all on the same LAN or spread across the internet, but either way you need some sort of dynamic DNS solution.
If the devices are all on the same LAN then you can use Avahi/mDNS/Bonjour to discover the current address of the device in the .local domain. Each broker will need to have a unique name.
If you are in a none lan environment then you will need to use a proper Dynamic DNS solution and have each broker have a unique fully qualified DNS name that the host machine can update when ever it's IP address changes.
Both of these solutions are more network admin solutions than programming questions so I suggest you ask on SuperUser if you have follow up questions.
There is a 3rd option, which is to have a 4th broker on a fixed IP address that acts as a central bridge for all the other brokers.

Related

Will DHCP server give me always same IP?

I have question on DHCP server in home router. I have founded, that I have same IP address in my notebook for some time. I don't know, how long it last, but it is probably few weeks at least. Will DHCP server ever change my local IP if i will still connecting to that Wi-Fi?
I am asking, because I am working on home automation system and I don't know if i had to keep care about checking if my devices has same IP...Because there will be server, which will remember IP of its clients (lets say ESP8266 modules). Must I periodically check IP address (in my modules) and send new IP to server (in case of change)? Or DHCP server will not change IP address of my modules, connected to that DHCP server? And what about situation when ESP8266 module will disconnect (lets say it will be off for few days) - is it common to get different or same IP from DHCP after connection again?
Thanks!
Simple solution would be reserving IP address for your ESP8266 modules in your DHCP server that they always receive the same IPs.
With regards to your questions:
My routers DHCP server saves clients and keep information about them unless it is deleted explicitly or number of saved clients gets larger than number of addresses available. It serves always the same IP to saved clients. Obviously it depends on the router and might be different in your case.
I'd not check for IPs manually, I'd rather reserve the IPs for the modules as said above.
If your DHCP server stores client information it will give the same IPs to your modules upon reconnect. Otherwise not it won't be necessary the case.
If you use or consider using MQTT server (my preferred way :) ) for your home automation (it has integration in many systems like e.g. Home Assistant) you won't need to care about IP addresses of your modules at all you'd only need to fix IP of the MQTT server.
Another option can be addressing your modules (or/and server) using host name instead of IPs. If you develop n Arduino this GitHub thread might be helpful.

Network communication without a centralized host. Is it possible?

I have a server and a few clients, software-wise, and I want the client to figure out the IP address of the server without actually referring to a specific database.
I had a misconception about UDP up until now that UDP only used the Port as a common identifier between servers and clients, but I was wrong apparently.
Requirement:
I want my server to broadcast a message to ALL devices on the network, once every 5 seconds or so.
That message will contain the IP of the server.
Software using such technique already:
A photo transfering app for iOS, called "Photo Transfer App" is really easy to use because it basically tells you to open the app on your Mac and on your iPhone, and then you press "Discover", and BAM! your devices have found each other.
But how?
How can my requirement be achieved?
EDIT
I googled a bit. Could server host on 255.255.255.255and clients connect to that address solve my problem?
According to this Wikipedia article, 255.255.255.255 is used for broadcasting.
Can someone confirm?
If you will use broadcast address (255.255.255.255) or network broadcast (like 192.168.1.255 for network 192.168.1.xxx or in the prefix notation 192.168.1.0/24). You will get essential limitation: your broadcast will NEVER leave that network. So all host inside the LAN will see your broadcast message but nobody else.
Multicast as mentioned by null is better because it can leave your network and pass through the IP routers. But this is feasible only by special network settings on that routers (and require multicast routing capability on that routers).
Another technology without such limitation can be use is dynamic DNS (server will register itself via DNS).
Multicast would be better than broadcast. See also: Bonjour, multicast DNS & SSDP.
More information on Bonjour is available here.

Networking Dilemma IP stack(Microcontrollers)

I basically have used the ethernet connection successfully with Microcontrollers to control real world aspects,The dilemma is of IP address I mean how can 192.168.0.155 be accessed from around the world without any specific MAC ID attached to it, I wanted to implement the same networking usage with a GSM module eliinating wires but that doesn't have MAC addressing so TCP connection from it towards a IP client won't reach?
I am not sure how you did your 'real world control' with Ethernet before, but the MAC address does not 'live' past the next recipient (which means after the next switch) so do not use it for anything.
Your 192.168.x.x address is private, so it will never appear beyond your internet gateway (i.e. your GSM modem if you used GPRS), and it cannot be used directly for anything on the internet. It is not easy to briefly explain here how the internet routing works, but you should either use port forwarding towards your private IP address given to you by hour DHCP server (in which you have to initiate request from the client so that other side would not the IP address and the port), or you have to either have fixed public IP address or you could use some dynamic DNS service (like http://www.noip.com/), or you can update data from the client on some server over which you have control (like if you updated data manually from your PC).
All summed up, it is not very clear what you are trying to achieve, but I would say you need to check out some things about internet routing before you proceed.

How do I make my game connect to a server without real IP address?

I'm making an XNA game. When I started, I had a broadband connection with real IP, so I could host servers of any kind without any problem, but now I don't have that connection any more and I want to be able to let players from outside my local network connect to my server again. How do I do that? How do big guys at studios do that?
Cheap option:
Configure your home router (it does have real, but probably dynamic, IP address) to forward connections on some port of your liking to your server on the local network. Read up on Network Address Translation - that's the trick routers use to hide a network behind a single routable IP.
Setup a DDNS account somewhere, so people can find your game server by name instead of changing IP address.
Expensive options:
Buy static IP package from your ISP (not always available).
Deploy your game at a Hosting Service.
Generally there are two ways to connect two clients:
Give each client other client's IP address and let them connect to each other.
Give each client a mid-server's IP address and tunnel the traffic through it.
First way assumes each client has a real IP address and they both can be a server to one another. Second way is for when one or both clients don't have real IP address.

what's needed to make hostname resolution work on a lan?

I am developing a networked application that runs on a few different computers on a LAN. One of the core needs is for the app to maintain a list of peers on the LAN with which it has communicated in the past, so that it can restore previous sessions. The naive solution would be to just remember the IP and store it in a table, but what happens when the IP of a peer changes?
Instead, I thought I'd store the hostname of the peers so even if the IP changes they will still be reachable via their hostname. (I know hostnames can change as well but that is good enough).
So my question is what exactly is needed to make hostname resolution work on a LAN with mixed Windows/Mac/Linux clients?
Without the use of a central authority the only reliable way to achieve this is through the use of zerconfiguration name resolution. This means that without a multicast router you will only be able to dynamically resolve peers on the same subnet as the resolving host. You could use something like bonjour for mac, netbios or ssdp for windows or avahi for linux but you can't assume that these are enabled. I may be overlooking some more popular protocols that perform this function well but I would personally throw together a quick udp broadcast name resolution protocol for your application. Take a look at these for some more ideas:
Zeroconf Name resolution
Universal local network name resolution method without DNS?
http://en.wikipedia.org/wiki/Zero_configuration_networking#Name_resolution
http://en.wikipedia.org/wiki/Broadcast_address#IP_networking
I would pick a specific udp port to listen on (lets say 12000) and then when you're ready to resolve hosts send a "hello" udp packet out to 255.255.255.255 on port 12000 and all of the other hosts on your network running your app should reply with a packet containing their hostname, possibly other information.

Resources