According to "Computer networking: a top-down approach", Kurose et al., a UDP socket is fully identified by destination IP and destination port.
Why do we need destination IP here? I thought UDP only need the destination port for the demultiplexing.
The machine may have multiple IPs, and different sockets may be bound to the same port on different IPs. It needs to use the destination IP to know which of these sockets the incoming datagram should be sent to.
In fact, it's quite common to use a different socket for each IP. When sending the reply, we want to ensure that the source IP matches the request's destination IP, so that the client can tell that the response came from the same server it sent to. By using different sockets for each IP, and sending the reply out the same socket that the request came in on, this consistency is maintained. Some socket implementations have an extension to allow setting the source IP at the time the reply is being sent, so they can use a single socket for all IPs, but this is not part of the standard sockets API.
I think that you are confusing UDP with Mulitcast.
Multicast is a broadcast protocol that doesn't need a destination IP address. It only needs a port number because it is delivered to all IP's on the given port.
UDP, by contrast, is only delivered to one IP. This is why it needs that destination IP address.
Related
We know that TCP sockets can be identified by origin IP, origin PORT, destination IP, and destination PORT.
The origin IP is required to distinguish between requests from different clients
The origin PORT is required to distinguish between requests from different processes of one client
Destination PORT is required to distinguish which processes receive requests from a server.
However, destination IP seems to be only needed up to the network layer, so I wonder why it is included in the TCP socket identifier.
Given that: "The client is the one who sends the request to the server and makes the connection through a socket at first."
The destination IP should be specified to distinguish which server this request is for. So, the request will be routed through the network to arrive at the server.
A given server machine could be running multiple server sockets, potentially bound to different networks. So, once the network delivers a packet to the server machine, the OS's socket stack would still need to know the source IP/Port and destination IP/Port to deliver the packet to the correct socket buffer.
In my class, we learned that a TCP socket is uniquely identified by the 4-tuple consisting of source IP, destination IP, source port, and destination port.
Now suppose I have a web server running on port 80. It has 2 TCP sockets established to two clients that have different IP addresses but somehow both use the same source port, say 12345.
We also learned in class that the transport layer header adds only the source/destination ports whereas the network layer adds the source/destination IP addresses.
Now suppose the web server receives two packets, one from each client. As mentioned, the source port, destination port, destination IP addresses are the same in these packets, so the only difference is the source IP address.
However, if demultiplexing is done by the transport layer, how can the source IP address be used to move the packet to the right socket? After all, the source IP address is only part of the network header and, as far as I understand, that header is already stripped off before the packet is passed from the network layer up to the transport layer on the receiving side.
When a server want to create a socket, it will use a combination of its IP address and some well-known port, let us say 80. So, when a packet arrived, both the server IP and port 80 will be used to decide whether the packet goes to that socket or not.
The question is why do we need to check the IP address of the server, since the packet (aka datagram) passed the network layer check and was certainly destined for this server. In other words, the network layer will not pass the packet to transport layer if the destination IP is not the server IP, so why do we use the IP address in the socket?
And if a host (a client or a server) created multiple sockets (network processes) using both its IP and some port numbers, is there any case where the IP could be different in these sockets?
Thanks in advance!
Why do we need to check the IP address of the server, since the packet (aka datagram) passed the network layer?
The Data Link Layer uses Media Access Control (MAC) addresses to direct packets. When a packet arrives at your computer operating system (OS), it arrived either because the MAC address matched the hardware address or it was a broadcast (ff:ff:ff:ff:ff:ff).
Once the packet is received, your OS determines if it is destined for an IP address assigned to the computer. At this point, the OS has several options:
If the IP address matches an assigned IP, deliver to any waiting applications or reject the packet and handle any needed Internet Control Message Protocol (ICMP) required.
Should the IP not match an assigned, your OS checks if IP routing is enabled. Then either rejects the packet issuing any required reply or forwards the packet to the destination IP in the routing table by creating a new packet targeting the MAC address of the destination router.
If a host (a client or a server) created multiple sockets (network processes) using both its IP and some port numbers, is there any case where the IP could be different in these sockets?
If your OS assigns more than one IP address to an interface, all of those IP addresses would be available to be used. You can open sockets using any available IP (usually INADDR_ANY or similar). In a listening context, your port will be available to every IP address assigned. In a transmitting context, your IP will be set depending on the outbound interface.
I know there is an older answer to this question here, though it does not seem to answer my question. If in UDP two people with different IP and different ports send data to the same server (same IP) at the same socket (since in UDP there is only one socket per application - correct me if i am wrong), how does server recognises which person is who?
Does it change anything if the two people use (by luck or not) the same port as source port but with different source IP?
The server can receive UDP datagrams from two different IP/port pairs (IP could be same, port could be same, or both could be different) on the same port. The recvfrom() function returns the source IP/port of the datagram in addition to the data.
As mentioned in the question you referenced, a UDP socket is defined only by the local IP and local port. The remote IP and port can differ for both outgoing and incoming packets.
I have the following statement.
"In TCP, the receiver host uses all of source IP, source port, destination IP and destination port to direct datagram to appropriate socket. While in UDP, the receiver only checks destination port number to direct the datagram. "
Is the above statement true?
If yes, does it mean that in TCP the same port can be used for multiple socket in one process, while in UDP only one socket can use on a port in one process? What about sockets in different processes? Can multiple processes use the same port in TCP/UDP? (in programming language: C/C++/Java)
If not, why?
"In TCP, the receiver host uses all of source IP, source port, destination IP and destination port to direct datagram to appropriate socket. While in UDP, the receiver only checks destination port number to direct the datagram. "
Is the above statement true?
Yes.
If yes, does it mean that in TCP the same port can be used for multiple socket in one process,
Yes, under some circumstances.
while in UDP only one socket can use on a port in one process?
No, see below.
What about sockets in different processes? Can multiple processes use the same port in TCP/UDP? (in programming language: C/C++/Java)
Under some circumstances, yes. A UDP port has to be designated as reusable by all processes that want to share it. A TCP port can only be reused by sockets bound to different interfaces: there is no sharing.
What that means is, in TCP, a unique communication "channel" can be described as the four-tuple: (src-ip, src-port, dst-ip, dst-port).
In UDP, all packets destined to a certain port are delivered to the only UDP socket listening on that port, regardless of the source address and port of said packet. I like to think of it as a funnel.