Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
node-discover for nodes which are not in the same LAN #17
Sorry for asking the question which is probably obvious, but - as I understand this discovery thing is working perfect, when all the nodes are located within one LAN network.
What if I want to run the nodes in the different LANs, but still want them to find each other. Is there anything which is possible to configure using
For example, using ElasticSearch, I am able to state the IPs (where I expect the other nodes to be run) in the configuration, so cluster will gather itself:
As far as I know node-discover will only work on the same network (sub-net?) where a broadcast/unicast packet can be picked up.
Also I was under the impression that AWS doesn't support broadcast/unicast packets, so I don't believe the node-discover style of module discovery will work?
More than happy to be proved wrong on this.
@PavelPolyakov, in its current incarnation, it is limited to the broadcast domain or however multicast works which may go beyond the lan depending on your router.
I have considered the idea of being able to specify an array of addresses to which messages should be sent. It actually would be very easy to implement. I'll give it a shot and you can try it out if you like.
@PavelPolyakov, v0.4.0 is on npm and has a unicast option. It takes a comma separated string or array of addresses.
This change would have been super quick, but I noticed some odd behavior when testing locally. I had to set up a virtual network interface so that my local machine had two IP addresses. If you test with examples/basic-argv.js you can do something like:
node examples/basic-argv --port=26364 --address=192.168.1.100 --unicast=192.168.1.100,192.168.1.101
node examples/basic-argv --port=26364 --address=192.168.1.101 --unicast=192.168.1.100,192.168.1.101
We have just tested it, and have the next issue (probably it's expected behaviour, but not for me).
I can only use the IP address which was provided for me by DHCP server, not the one which the server is available from the internet.
(in the example above, I can use the "inet addr").
Any thoughts is this right or wrong?
node examples/basic-argv --port=26364 --address=10.95.166.12 --unicast=54...
And you will need to make sure that the remote (54...) machine is allowing incoming UDP messages on port 26364. Likewise if you are running this same example on the remote (54...) pointing back at your local machine (via your public IP address), you would need to make sure your router/firewall is allowing incoming UDP on 26364 and forwarding that traffic to 10.95.166.12.
I'm not entirely sure of your setup, but let's pretend based on what I'm picturing with fake addresses
Machine IP: 10.1.1.1
node examples/basic-argv --port=55555 --address=10.1.1.1 --unicast=220.127.116.11,18.104.22.168
Machine IP: 10.100.100.100
node examples/basic-argv --port=55555 --address=10.100.100.100 --unicast=22.214.171.124,126.96.36.199
This scenario assumes both machines are behind a router/firewall doing NAT. Not sure how close this is to your setup.
Correct, this concept had worked for me, and I was connected to the remote:
Thanks for the library and for the quick support, all of this is really interesting!