Network Engineering Stack Exchange is a question and answer site for network engineers. It only takes a minute to sign up.
Sign up to join this community
So my question is quite clear I think. If two applications use different transport layer protocols (e.g. TCP and UDP or something else) can they open the same port number?
How does the OS do the multiplexing if this is the case?
How many transport protocols can be in an OS networking stack? If the number of different protocols is unlimited does that mean that a computer can basically have unlimited open ports to communicate through?
Think of it this way: TCP is one street, UDP is another street, and port numbers are the addresses of the houses (ports) on the streets, just as they are layer-4 addresses. Each street has the same address numbers for the houses. An application can move into the house at 80 TCP St., but when another application wants to move into the same house, it finds the house already occupied, so it can't move in.
On the other hand, one application could move into 9876 TCP St., and a different application could move into 9876 UDP Ln. at the same time. The OS doesn't need to multiplex this since traffic destined for these houses travels on different streets.
There will be a practical limit to the number of transport protocols an OS can have, but that will vary by OS. In theory, there is no limit. Some transport layer protocols don't use addresses like ports.
Ports are an individual parameter of both UDP and TCP, so yes they are different. Because each transport protocol has its own stack, they operate independently.
To answer your second question, unless you are trying to stay within the OSI or TCP/IP model, you don't need a transport protocol -- or you can make up your own. You can use any mechanism you like to multiplex connections. Ports are just one such mechanism.
Yes, different applications can bind to the same port on different transport protocols. They can also open the same port on the same protocol but different IP addresses.
As the packet works it's way up the processing chain various bits of information are looked at.
Lets say a frame containing an IP packet containing a UDP datagram comes in on an Ethernet card.
First the host will look at the destination MAC address to see if it matches either it's own address or an appropriate broadcast or multicast address. This first level of checking is usually implemented in hardware.
Then it will need to determine what type of Ethernet frame it is dealing with (for historical reasons there are several).
Then it will need to determine which network layer protocol to pass the frame to. For an "Ethernet II" frame (the most common type) this is determined by the "ethertype" field.
Assuming our frame represents an IP packet it will then need to determine whether it is destined for an IP address that belongs to the local machine.
Assuming it is destined for the local machine then it will need to look at the protocol number and pass it up to the UDP implementation.
Finally it will need to compare the IP addresses and ports against it's table of sockets to determine which socket to pass the datagram to.
The number of possible transport protocols under IP is limited by the size of the protocol field. Similarly the number of possible network layer protocols for an "Ethernet II" frame is limited by the range of usable Ethertype values.
Furthermore using new transport protocols isn't a good way to get around port count limitations. Protocols other than TCP/UDP/ICMP will not be properly understood by many firewalls and NATs.
