As far as I know, UDP ports and OS sockets are mapped only by the (local port, local address) pair. In other words, the receiver side's OS does not keep a state of (remote port, remote address) pair (although this information has been attached to the UDP header of the packet. My question is, when you respond to this packet (let's say a DNS response), how does the server know who to respond? Does some entity keep the (remote port, remote address) pair that has been obtained from the packet and somehow use it?

closed as off-topic by Ron Maupin Aug 20 '18 at 14:42

This question appears to be off-topic. The users who voted to close gave this specific reason:

  • "NE is a site for to ask and provide answers about professionally managed networks in a business environment. Your question falls outside the areas our community decided are on topic. Please visit the help center for more details. If you disagree with this closure, please ask on Network Engineering Meta." – Ron Maupin
If this question can be reworded to fit the rules in the help center, please edit the question.

  • Unfortunately, questions about applications, programming, and host OSes are off-topic here. You could try to ask about programming on Stack Overflow. – Ron Maupin Aug 20 '18 at 14:42

First of all: Sockets have nothing to do with network protocols but with network programming:

Indeed a if a DNS server software called the recv() function the information about the IP address of the sending computer would be lost.

The software would not be able to send a response.

Therefore the software calls the recvfrom() function instead of recv():

This function will return additional information about the UDP packet received; in the case of IPv4: The "source address" and the "source port" (in the case of IPv6 even more).

Using this information the software can send a response.

  • 1
    This is somewhat OS specific, presumably you're describing the Berkeley socket interface: as far as the protocol is concerned, the traffic goes beween a 4-tuple. It is also possible to have what Berkeley calls a "connected UDP socket", where there is a default address attached to the socket structure, where using connect() does indeed permit subsequent use of recv() and send() without the addresses required by recvfrom() and sendto() – jonathanjo Aug 20 '18 at 11:56

A UDP socket is defined by the (source address, source port, destination address, destination port) tuple. That way, the destination host knows where a request has originated from and where to send the reponse (where applicable).

  • This is correct: it's up to the OS to decide how to organise its system calls. RFC 768 says only that it is to allow "receive operations on the receive ports that return the data octets and an indication of source port and source address. – jonathanjo Aug 20 '18 at 11:49

Not the answer you're looking for? Browse other questions tagged or ask your own question.