Some background first. I have a .net client agent installed on each of the machines in the lan. They are interacting with my central server [website] also on the same lan.
It is important for my website to figure out which of the machines can talk to each other. For example, machines of one subnet cannot directly talk to machines of another subnet without configuring the routers and such. But machines in the same subnet should be able to talk to each other directly.
The problem I am facing is when the lan setup is like in Figure 1.
Because Comp1, Comp2 and Comp3 are behind a router, they have got the ipaddress 192.168.1.2 till 192.168.1.4. My client agent on these machines report the same ipaddress back to the server. However, machines Comp4, Comp5 also have the same ipaddresses.
Thus, as far as my server is concerned, there are 2 machines with the same ipaddress. Not just that, because the subnet mask is 255.255.255.0 for all machines, my server is fooled into thinking that Comp1 can directly talk to Comp5, which is not possible.
So, how do I solve this? What do I need to change in my client or in my server, so that I can support this scenario. These two are the only things in my control.
EDIT: Seems that the network diagram
is over simplified and there could be
multiple router/subnet levels. My
original answer will not handle this
scenario. Also, with the restriction
of modifying only the client app or server
app and not tampering with the
routers and firewalls makes
it more difficult.
EDIT2: Using 'arp -a' you can extract
the MAC address of the router. If the
client apps can manage to do this then
the puzzle is solved!
The client app knows the local machine address and passes it to the server app.
The server app knows the remote address when a connection comes in. This would be machine address or a router address.
From these two values you can work out what you ask.
For example:
Server app receives connection from 10.10.10.2 with client supplying 192.168.1.2
Server app receives connection from 10.10.10.3 with client supplying 192.168.1.3
The 'remote address' distinguishes the subnets.
So, all you need to figure out is how to extract the remote address of a client connection. If you are using any of the popular web technologies for your server app then this is very easy.
One approach is for the individual client machines to determine who they can see using a broadcast message. Have each client listen on some particular UDP port, and each client broadcast its presence to whatever the local broadcast domain is. When clients can see each other in this way, they can probably also make TCP connections to each other.
If the server needs to know which clients can talk to each other, just have the clients tell the server.
If the network diagram is complicated enough I think if would be very difficuilt to find what you need.
You should also take into account that Comp1 can establish direct connection to Comp6.
The solution I can suggest is probing. Client receives list of all other clients from server and tries to establish connection to each of them. I think that would be the only way to know which clients are REALLY accessible assuming any number of routers/firewalls/NATs in the network. Doesn'r scale much for a big number of computers of course.
Related
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.
I am working on a program related to network, and there's a situation that the client has to connect to a server which is inside a LAN.
As I know, when establishing a TCP connection, the port the server is listening on has to be accessable to the client. If the server is inside a LAN, port accesses are blocked by the router. One solution I know is to use UPnP to perform a port mapping on the router. However, in some cases, the router does not support UPnP, are there other solutions?
IM applications came up into my mind. Many IM applications have the functionality that users can send files to each other, whatever the network environment is, as long as you can access to the internet. I don't think a public server is used as a file data exchanger between the two, the connection has to be a direct one. How do they actually do to enable the client to connect to a "hidden" server?
Typically such programs try a series of steps:
A connect directly to B
B connect directly to A
A tries to connect to a firewall (uPnP) forwarded port to B
B tries to connect to a firewall (uPnP) forwarded port to A
A and B both connect to a central server and exchange data through that
The last step is obviously the least preferred because the provider has to have sufficient resources to manage all simultaneous transfers. Rate-limiting is common.
Since IM has central management anyway, it's not too difficult to coordinate all this.
If uPnP or an open port can't be done at one end or the other then the only option left would seem to be passing it via a server in the middle
I found a tutorial that shows you how to create server and client programs, and make them communicate over a network.
http://www.win32developer.com/tutorial/winsock/winsock_tutorial_1.shtm
I can make a client program connect to, for example, 192.168.0.4 on my local network, and I can make it connect to 74.125.225.96. But what if I wanted to make it communicate with 192.168.0.4 on the network of 74.125.225.96, instead of just the default server on 74.125.225.96? I'm having a difficult time finding the answer with Google.
Is there even a way to do this? If not, then how are Gnutella and Bittorrent, able to connect computers directly together to share files?
To do what you are asking, 74.125.225.96 would have to be assigned to a router that is configured to forward inbound connections on the target server port to the machine that is running 192.168.0.4.
BitTorrent and other file sharing apps use various techniques, like NAT traversal, hole punching, etc to get connections through routers and firewalls. For example, if one party is behind a router/firewall and the other party is not, then the two apps first try to connect to each other in one direction, and if that fails then they reverse roles - client becomes server and server becomes client - and they try again. If that still fails, they could then connect to a middleman server that both parties have access to, and let it delegate the connections.
I've noticed recently that I don't have to forward ports for mmorpg's that I play.
I'm thinking about working on a game that people can play online and had a question.
Why is this the case given its a two way socket connection that is constantly sending data back and forth? Doesn't their server need to get through my firewall in order to connect to me?
TCP crash lesson: TCP is a two-way protocol. The challenge is that at least one host needs to initiate. Since within an MMORPG, your own computer is never acting as a server, nobody has to connect to it. All the information about game state is passed through the company's public facing servers that have public facing IP addresses (and hey, maybe they actually use port forwarding there, just to confuse my explanation... but you never have to see their pretty network internals, proxies, and other wizardry.).
Anyway, when you connect to Stackoverflow, you're making one outbound connection that requests data from the server, and then over that same connection you're receiving it back. Same exact scenario, only with a webserver instead of a game.
UPnP allows you to tackle many routers. There's also NAT Punch-Through if you have access to a third party that isn't behind a router.
Either way, port forwarding is only necessary if you wish to act as a server (or the sender in a P2P relationship). A client does not need to forward ports.
You don't need to forward ports to access the web either, despite data coming in as well.
When you make an outgoing TCP connection, your NAT router puts the connection in a table, so that when data comes in, it knows what machine in your LAN to send the packet to.
Everyone mentions TCP, but NAT works for UDP as well: The first outgoing UDP packet associates that source port with the internal IP address, and your NAT device will forward incoming traffic to that port to the correct host on the internal network.
In other words, if your computer requests the connection (outbound) first, the router opens up the port automatically, on the assumption that you're going to want data back. But if you want remote users to connect to your computer without your computer requesting it, the router would normally drop the packets since it wouldn't know where to send them (they were unsolicited). So instead, you need to tell the router to deliver any unsolicited packets at port N to your computer.
Sorry to add another answer so late, and I know one was already accepted, but I personally found the other answers to be more confusing than this simple explanation.
In short: How to reliably discover a server running somewhere on a (presumably multi-segmented) local area network with zero client configuration
My client application has to locate the server application without knowing the server IP address. It has to work on a local LAN that may be split into segments with hubs or other switching devices.
I already have a working solution, but it is a bit cumbersome to get it working on multi-segment networks. It works as follows:
When the client starts up, it sends UDP broadcasts on its own network segment. If the server is running on the same segment, it works without any issues - the server responds with the appropriate messages.
If the server and client are running on networks separated by a hub / switch that won't forward UDP (the most likely case), then I have a server instance running on each segment, and they forward client requests to each other via TCP - but I need to configure this for the server instances (simple, but still a pain for tech support.) This is the main problem that I need to address. There are sites where we have hundreds of clients running on 5 or 6 separate segments.
The problems I'm facing:
1. Although my application installer enables the appropriate ports on the firewall, sometimes I come across situations where this doesn't seem to happen correctly.
2. Having to run multiple server instances (and therefore configure and maintain them) on hub/switched networks that won't forward UDP
Finally I need a solution that will work without maintenance on a minimal Windows network (XP / 2000 / Vista) that probably doesn't have Active Directory or other lookup services configured.
I don't want to tag on any runtime stuff for this - should be able to do it with plain VC++ or Delphi.
What approaches do commercial apps usually take? I know that SQL Server uses a combination of broadcast and NetBEUI calls (I may be wrong about this).
Thanks in advance.
You have a few terminology issues:
Where you say "network segment" you appear to mean "IP subnet". Devices on the same network segment can see the same IP broadcasts.
Where you say "hub/switch" you appear mean "IP router".
Where you say "won't forward UDP", the problem is actually "won't forward IP broadcasts".
Once we get past that, you have a few options:
Your servers could register themselves under a well-known name in DNS, if you have a DNS server that allows dynamic DNS updates. You should probably use a SRV record as specified in RFC2782. The clients then do a DNS lookup to find the server(s).
You could statically assign your server(s) well-known names in the organisation's DNS, perhaps with a SRV record as with the previous option.
Your servers could join an IP multicast group, if your routers support IP multicast. The clients then send their initial discovery request as a UDP packet to the (pre-ordained) multicast address.
If you have domain server, I would go with small service on it. You can connect with other services to it and use it as distribution point.
Why domain server? It is relatively easy to find it's name (DsGetDcName).
Other choices would include DHCP server, DNS server or something of that kind that needs to be filled by maintenance staff anyhow.