Join Log in
Score:11
S.B avatar Server

What happens if two local systems download the same resource on same port?

cn flag
S.B

I'm aware of NAT table. I just want to know what happens if two clients in a private local area network want to download exactly the same resource on the same port? In other words , When a packet comes from the server, how can the router decide which client is supposed to get this packet?

If I'm not wrong, the incoming packet from the server has destination IP address of the router which is public and is the same for both, and also the destination's port number which happens to be the same as well in this case.

Is there any mechanism in router or server to detect this ? or is this behavior even possible at the first place?

I've searched questions like this, which makes sense that the error raises because the port is busy but I'm asking about two separate systems.

Update : From comments I realized that I wasn't clear enough so let me say it again with an example:

I just care about devices' "source" port. Assume I have two laptops (192.168.2.10 and 192.168.2.11), both of them are downloading same file from the same server somewhere in the internet. Each of them has an operating system which generates a random port so the source IP and source port would be something like: 192.168.2.10:6321 and 192.168.2.11:7132. I thought that in NAT, router will set it's (public)IP address along with the ports from laptops so if the public IP address of the home router is 65.82.23.32, these two packages will get these source IP and source port respectively : 65.82.23.32:6321 and 65.82.23.32:7132.

Now when the response gets back, router can figure out which packet is for which laptop from the port numbers right ? so far so good. But what happens if accidentally or intentionally two laptops generate exactly the same source port? for example : 192.168.2.10:6000 and 192.168.2.11:6000. Now router will set it's public IP address as the source IP address just as before, but now if it tries to use those port numbers, those packages will have exactly the same source IP and source port number, like : 65.82.23.32:6000 and 65.82.23.32:6000.

This is where I got confused that when the response comes back, how router can decide which packet is for which laptop ?

After @mfinni's answer, I noticed that this is not how PAT works! The NAT device (here router) will assign unique ports to each individual laptop(private IP address), then the packets sent out with these unique ports(for example 7777 and 7778). So when response gets back, it's clear that which packet is for which laptop from the ports, then router will convert these 65.82.23.32:7777, 65.82.23.32:7778 to --> 192.168.2.10:6000, 192.168.2.11:6000 respectively.

6524
4 + 5
nat
se flag
slebetman
The router would recognize that the IP address is different. Remember. An IP packet is identified by 4 pieces on data, not 3, not 2 and not 1: source IP, source port, destination IP, destination port
1
Reply
S.B avatar
cn flag
S.B
@slebetman I know but when the same file is downloaded from the same url( if we connect to the same webserver), destination IP and destination port is the same for both packages. Source IP is also the same because it is router's IP address. So the last piece of those 4 data is source "port". Am I right ?
0
Reply
se flag
slebetman
They cannot be the same. The NAT service in your router must make sure that they are not the same. The source port going out from the NAT is random anyway so the NAT just need to make sure that it internally maps the packet with the incoming source port to the correct PC
6
Reply
se flag
slebetman
Unless you write your own NAT but that would be considered a bug in your NAT implementation
4
Reply
RonJohn avatar
id flag
RonJohn
"Is there any mechanism in router or server to detect this ?" You've **GOT** to know that someone else has thought of this **some time** in the past 22 years.
0
Reply
Score:44
jcaron avatar Server
co flag
jcaron

A TCP connection (which underlies HTTP and many other protocols) is uniquely (at a given point in time) defined by 4 parameters:

  • The local IP
  • The local port
  • The remote IP
  • The remote port

Even if you make the same request twice simultaneously from the same computer, even with the two IP addresses identical and the destination port identical, the source port will be different.

Likewise, if you have two requests coming from two devices going through the same NAT device, the NAT device will use different source ports. Depending on the device, it may either keep the original source ports (and only change one if there's a conflict), or always assign a new source port independently of the original source port.

The NAT device will then keep for each connection a mapping in its translation table which states that external connection (external IP, external source port, destination IP, destination port) is mapped to internal connection (internal host IP, internal host source port, destination IP, destination port).

0 + 7
S.B avatar
cn flag
S.B
Well explained. I'm gonna accept this as the answer. It's comprehensive and easy to understand.
1
Reply
cn flag
TomTom
As simple and basic as it is - the fact that there is a SOURCE port for every client connection is regularly overlooked by beginners (and experienced programmers, to that). I actually have had people assuming the source port would be identical to the target port, which obviously does not work at all (i.e. a web server making a http call to another web server). Basic fact of TCP, well explained.
6
Reply
cn flag
Tonny
@TomTom There are actually a few niche protocols that use the same port for source and destination. They are a rarity and usually designed by programmers that didn't really understood the finer points of networking.
0
Reply
cn flag
TomTom
@Tonny They also can not be mainstream because otherwise they would have an assigned port - that falls in the controlled space of low ports ;) Can you name me some of those offenders? Never heard of them, actually - sounds like programmers being stupid.
0
Reply
cn flag
Tonny
@TomTom They are really niche. I've encountered a couple in control applications for industrial equipment. Nothing recent (as in "this millennium") though. I can't really remember any names. It was 2 decades ago. And stupid is too mild a term for that insanity...
0
Reply
jcaron avatar
co flag
jcaron
@HagenvonEitzen that would be contrary to the whole TCP paradigm. A TCP connection is defined by the 4-tuple, not any 3. Also I'm not quite sure I understand what is the case you are referring to. If you are in a failover situation (without sync of the NAT tables) then the standard mechanism for a TCP packet which can't be matched is as RST, not an ICMP unreachable.
0
Reply
Hagen von Eitzen avatar
cn flag
Hagen von Eitzen
@jcaron Sorry, my bad. It seems I got confused because high-level displays of ICMP unreachables tend to only mention the destination address and port - when they actually *do* contain the full internet header including sending ip plus 64 bits of the datagram (and thereby the TCP ports involved) of the offending packet *precisely* in order to allow finding out what attempt really failed.
0
Reply
Score:11
mfinni avatar Server
cn flag
mfinni

The NAT table knows that the source port on each client is different, so it won't accidentally send the wrong packet to the wrong internal client. The NAT device also assigns different outbound ports, and those are NOT the same between different internal clients.

0 + 9
S.B avatar
cn flag
S.B
Oh Thank you, I'm afraid did you mean `ip` instead of `port` in your first sentence ? because the ports are assumed to be the same.
0
Reply
mfinni avatar
cn flag
mfinni
No. The source port from a client is not assumed to be the same. When a client makes a request, the source port for most protocols is going to be a random free port in the ephemeral port range.
2
Reply
S.B avatar
cn flag
S.B
Yes it's true but I specifically ask about exactly that situation where the source ports are the same, for example I intentionally open the same port with python socket.
0
Reply
mfinni avatar
cn flag
mfinni
Well, you're being silly by doing that, but the NAT table knows the source IPs are different, so the same applies. The outbound NAT ports will definitely be different, those will come from the ephemeral port range on the NAT device.
1
Reply
S.B avatar
cn flag
S.B
Lol, it was because of curiosity. thanks for your information
0
Reply
se flag
slebetman
@SorousHBakhtiary Your OS will prevent you from opening the same port twice with a "port in use" error (usually EADDRINUSE in normal implementations of IP). What you CAN do is have one process open ONE source port and communicate with two other processes via pipes or shared memory etc. and the two processes proxy their request via the first process. But in which case the routing will 100% be up to you because this is now outside the IP protocol.
0
Reply
se flag
slebetman
@SorousHBakhtiary It looks like python does not even have an API where you can set the port for the client. You can only specify the server port in the `.connect()` method. The client port is randomly assigned to your socket. So you can't do what you plan to do in python. It's possible to do it in C by manually editing the socket struct (spoofing) but it's non-standard
0
Reply
S.B avatar
cn flag
S.B
@slebetman You're right, it's my fault that I wasn't clear enough. I updated the question with an example. Please see the "update" section.
0
Reply
user49822 avatar
pl flag
user49822
@slebetman At least on linux you can set the source port when connecting by calling the `.bind()` method before `.connect()`
1
Reply
Score:6
avatar Server
in flag
NiKiZe

When you refer to NAT you are probably actually referring to NAPT. Which changes the source port (at least if needed) in the NAT device. As such the source port will change.

For example iptables MASQUERADE

When doing NAT in this case there is also a need for "connection tracking" which simply keeps track of which "external port" relates to which "internal client and port". In iptables you will often see the rule RELATED,ESTABLISHED which uses. You will also find that if a router that does NAPT is restarted, it will drop all connections. While a router without any NAT usually will just resume any connections. (assuming that it completes restarts before client times out)

0 + 2
S.B avatar
cn flag
S.B
Yes, My problem was: for example, when we use port 6000 in our application, I thought that port will be placed in the packet along with the (public)IP of the router... but the true story is because of PAT, another port which is generated by NAT device(here router) is assigned to our private IP address. That's how router can easily distinguish which packet is for which IP address even if they initially used same ports. Am I right ?
1
Reply
se flag
slebetman
@SorousHBakhtiary When you say port 6000 do you mean on the server or the client? You do realize that every packet in the IP protocol is identified by 4 bits of information right? Not just 2. client(source) port, client(source) IP, destination(server - I think this is what you mean by 6000) port, destination IP. So even if two clients on the same PC make connection to (destination) port 6000 they will be randomly assigned different source ports by your OS. This is what routers (and NAT) use to determine routing - source port, source IP, dest port, dest IP
1
Reply
Score:5
Larry Spencer avatar Server
ru flag
Larry Spencer

The router doesn't use the same source port number that the laptops generate in its outgoing requests to the WAN, it generates its own unique source ports. The NAT table in the router converts laptop1:6000 into publicip:N and laptop2:6000 into publicip:M. Then it knows where to route incoming packets by which port the traffic arrives on from the Internet.

0 + 0
ธงชาติไทย
Elon Musk
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.