TCP connection with changing IP addresses
-
@Christian-Ehrlicher Let's say I have an application on my laptop. If I take my laptop to a different location with a different network, won't I have a different IP address? I remember that the last time I checked my IP address, it changed when I moved to a different network.
Even when I reboot my router, the IP addresses for each device change.
-
@Saviz said in TCP connection with changing IP addresses:
If I take my laptop to a different location with a different network, won't I have a different IP address?
You will but that's not 'all the time' - it's on reconnect/relocation.
But as I said - that's why DNS was invented. -
@Saviz
@Christian-Ehrlicher was saying you need some kind of DNS to allow look up by known name to find current IP address.However, the way you say it all your client PC IP addresses need to be known. Why do you need their IP addresses? Usually your application has a *server" which client PCs connect to, it doesn't matter what their IP addresses are. It is however the case that the server's IP address must be known or discoverable. but that would remove the need to know client addresses?
-
@JonB But I'm not using a server; I'm simply following this simple example. I want to then allow clients to communicate directly with each other. This means I need to know their IP addresses because clients send data directly to each other based on whom they decide to connect with.
-
@Saviz said in TCP connection with changing IP addresses:
IP addresses because clients send data directly to each other based on whom they decide to connect with.
Since I doubt those clients are directly connected to the internet this will not work until you use NAT to route between the internal and the internet adresses.
-
@Saviz said in TCP connection with changing IP addresses:
If I take my laptop to a different location with a different network, won't I have a different IP address?
Are you planning to run your app only in different LANs or do you want to connect over Internet?
If the latter is the case, then you idea is pretty naive.
IPv4 host addresses are private addresses which are non-routable. There is no way to make your approach work, if not set up correctly (firewall, router, NAT, static public IP... etc. etc.).
You could setup a DMZ in your home network to allow access to a "client" behind your NAT and make it act as "server". However then you still can't connect two random clients in any network directly.Almost every service, either online games or chat apps/software, etc has its own public servers where client connect to.
-
First of all, just like @Pl45m4 said, you need to have all computers on the same local network for this approach to work (one way to make them be on the 'same' local network is using a VPN (not the commercial products that let you choose a country, but your own VPN server at home; your router might provide that feature)). SoftEther VPN has solved most of the problems for you if you want to do this over the internet (never used it myself, but I think "It just works!").
Assuming you have solved the aforementioned problems and have some sort of local network (maybe by means of a VPN) as you mentioned the IP address can still change. This is where (usually) the MAC address comes in. It is supposed to be a world-wide unique hardware address for your network card. Some routers use it to assign the same IP address to the same computer over and over again. The original intention was for this to be a fixed address and thus should work for your problem. However, Apple decided that because it is a fixed address, it can be used to track you. Therefor, they will send out different MAC addresses for different networks (by default) so you cannot be tracked. (Furthermore, you can assign a specific MAC address to a VM and you can change your MAC address in Linux; this does not necessarily make your MAC address unique anymore.)
Modern systems use Apple's Bonjour or something similar to advertise their services on the network. A quick search for this also showed up multicast. This is most likely your best solution: When you want to discover computers already running the chat client (on the same local network) you send out a specific multicast message. Multicast means that all computers in the network receive the message. Each running client can then respond with their information. You should assign names to each client (maybe use a UUID that never changes) which is send out with the response. This way you can rediscover chat clients according to their names.
-
@SimonSchroeder said in TCP connection with changing IP addresses:
Some routers use it to assign the same IP address to the same computer over and over again
DHCP ;-)
also MAC-based, either dynamic or static DHCP where you can enforce e.g.192.168.0.101forA1-B2-C3-D4-E5-F6@Saviz said in TCP connection with changing IP addresses:
This means I need to know their IP addresses because clients send data directly to each other based on whom they decide to connect with.
Figure out what you really want to do and what is needed for that.
Connecting two client computers, which run your app, over the Internet, does not work just like that. -
You guys are seriously pessimistic about the state of end-to-end connectivity!
Yes, there are situations where an endpoint may be assigned a private address block address. There are plenty of devices out there that have public addresses.There are also situations where
NAT traversalwill work. I'll leave it to the reader to look that up.As for automatically finding the new address: DNS is useful. Perhaps a
dynamic dnsservice is an option.
If not, each node could attempt to keep track of its own IP address as well as the peer's. If the connection is broken, and the node discovers that its address has changed, it could attempt to send the peer an update message of some sort. Good luck if both sides change. -
@jeremy_k said in TCP connection with changing IP addresses:
You guys are seriously pessimistic about the state of end-to-end connectivity!
I am sysadmin with over 20y of experience. "I've seen things you people wouldn't believe", to quote a classic.
Serious note aside - the fact that something is possible doesn't mean one should try it. There's lots of "it depends on the use case" but I've had large enough share of commercial products with design compromising network security. That "pessimism" is perfectly warranted.More to the topic - I personally think the OP's design is abysmal in terms of security. Can they make it work? But of course. Would I allow such a solution in the network I manage? Under no circumstances.
My advice here would be for the clients to report to the server's API at certain intervals, doing push-pull (so server would need a queue). Let's leave p2p connections for the LAN games.Other than that I think one can make it using UPNP, where target IP is safely obtained from the server's API together with a shortlived key used to validate incoming connection on the other end, but that's borderline already.
