4 ms·

Can someone TLDR this? interesting question but not worth reading all this to find out. Can two IPs bind to the same IP / port on the server? Even if they come

Can someone TLDR this? interesting question but not worth reading all this to find out. Can two IPs bind to the same IP / port on the server? Even if they come from the same client, my intuition says no.

toast0 4y ago
I'm having a hard time understanding your question. But let me try. If none of these answer your question, you're going to need to provide some more concrete details. If your sever has IPs 192.0.2.1 and 192.0.2.2. You can bind to 192.0.2.1:80 on one socket and 192.0.2.2:80 on another and listen for connections on both (or use it for outgoing connections, whatever). Or you could bind to 0.0.0.0:80 and listen for connections on either, as long as they don't have more specific bindings. If your client has IP 198.51.100.1, it can connect from tcp 198.51.100.1:18490 to 192.0.2.1:80 in one socket, and from tcp 198.51.100.1:18490 to 192.0.2.2:80 in another. You could also do the same on UDP, UDP's ports are orthogonal to TCP's. If you have another client with IP 198.51.100.2, it can also use local port 18490 to connect to both servers on port 80. A server can accept a virtually unlimited number of connections on a given tcp port, but a maximum of 64k per client IP, and your operating system will have some limit on the number of sockets; you can often raise that to some function of physical memory (FreeBSD limits you to a maximum of one fd for each four pages of physical memory); although, it takes a very specific load to be able to max out the FDs. Something like HAProxy in tcp forwarding mode can do it, but most other applications are going to use enough CPU and memory that you'll run out of those before you run out of FDs.
- waynesonfire 4y ago
  i was thinking of "scenario #1" in the article. you explained in well and i was wrong. i dug in a bit more and it looks like the linux kernel represents a connection as 4-tuple: source ip, source port, destination ip, destination port which is what allows the kernel to accept multiple connections on the listening port.

toast0 4y ago

I'm having a hard time understanding your question. But let me try. If none of these answer your question, you're going to need to provide some more concrete details. If your sever has IPs 192.0.2.1 and 192.0.2.2. You can bind to 192.0.2.1:80 on one socket and 192.0.2.2:80 on another and listen for connections on both (or use it for outgoing connections, whatever). Or you could bind to 0.0.0.0:80 and listen for connections on either, as long as they don't have more specific bindings. If your client has IP 198.51.100.1, it can connect from tcp 198.51.100.1:18490 to 192.0.2.1:80 in one socket, and from tcp 198.51.100.1:18490 to 192.0.2.2:80 in another. You could also do the same on UDP, UDP's ports are orthogonal to TCP's. If you have another client with IP 198.51.100.2, it can also use local port 18490 to connect to both servers on port 80. A server can accept a virtually unlimited number of connections on a given tcp port, but a maximum of 64k per client IP, and your operating system will have some limit on the number of sockets; you can often raise that to some function of physical memory (FreeBSD limits you to a maximum of one fd for each four pages of physical memory); although, it takes a very specific load to be able to max out the FDs. Something like HAProxy in tcp forwarding mode can do it, but most other applications are going to use enough CPU and memory that you'll run out of those before you run out of FDs.

waynesonfire 4y ago
i was thinking of "scenario #1" in the article. you explained in well and i was wrong. i dug in a bit more and it looks like the linux kernel represents a connection as 4-tuple: source ip, source port, destination ip, destination port which is what allows the kernel to accept multiple connections on the listening port.