Multiple clients from same IP

Question

If you have a service that uses a specific port, and you have multiple computers on the same ip addess, how is this handled? Should the service specify to which computer on the ip address the information should be send? What if both computers on the same ip use the same service, but request different information?

Also, if a client is on a dynamic ip, how should the service detect that the ip has been changed, but the client (and the session) is the same? Should clients identify themselves for every request (much like cookies over http)?

Answer 1

I don't think I fully understand what you've said. There is no way that multiple computers will be on the same IP, this is not how the internet works.. There are protocols which hadels such things.

Did you mean that you're a server and multiple computers try connect to you? If so, you listen in a port and when you get a connection you open a new thread for the service of that computer and the main loop still listening

Answer 2

You have many questions, I'll try to respond to them one by one.

If you have a service that uses a specific port, and you have multiple computers on the same ip addess, how is this handled?

Someone mentioned that multiple computers cannot have the same IP address. In the original IP model, this is true, though today such address sharing (through NAT) is common. But even in the original model, your question makes sense if you reformulate it slightly:

"If you have a service that uses a specific port, and you have multiple clients on the same ip address, how is this handled?"

There can be multiple client processes on the same host (thus sharing the same IP address) trying to contact the same server (using the same destination address+port combination). This was natural at the time IP was developed, as most machines powerful enough to connect to the network were multi-user machines. That's why TCP (and UDP) have port numbers on both sides (source and destination, or client and server). Client processes typically don't specify the source port when contacting a server, but an "ephemeral" source port is allocated to the socket by the host operating system for the lifetime of the socket (connection). So this is how the server distinguishes between clients from the same address: by their source ports.

NAT maps different hosts (with different "internal" IP addresses) to the same "external" IP addresses, but it also allocates unique source ports to outgoing packets. So the server sees this just like the original case (multiple client processes from the same "host"/IP address). The NAT then "demultiplexes" the server's responses to the different internal hosts.

Should the service specify to which computer on the ip address the information should be send? What if both computers on the same ip use the same service, but request different information?

The server does this by sending responses to the same address+port combination that the different clients used as source address/port. This is mostly handled automatically by the socket API. As described above, the two clients will get separate connections, and the server hopefully handles these as separate "sessions" and doesn't confuse requests between these sessions.

Also, if a client is on a dynamic ip, how should the service detect that the ip has been changed, but the client (and the session) is the same? Should clients identify themselves for every request (much like cookies over http)?

Now, this is a whole can of worms. If a service wants to "survive" client IP address changes, then it will have to use some other identifier. HTTP (session) cookies are a good example. TCP connections are broken by address changes - this is normal, as such changes weren't envisioned as part of normal operation when TCP/IP was designed. There have been attempts at making TCP/IP more robust against such changes, such as Mobile IP, MPTCP, and possibly SCTP, but none of these have really entered the mainstream yet. Basing your protocol on HTTP(S) and using session cookies may be your best bet.