Confusion over how UDP server sends the response back to UDP client

Question

I am writing a UDP based client server and have got pretty much the code, but I am confused about how UDP server sends the response back to UDP client, this is my understanding till now:

• Suppose a UDP client wants to communicate with a UDP server, so it will send a request to the UDP server (using the UDP socket opened at client's end), now this will reach the UDP module at the UDP server, where UDP module will identify the UDP service using the port number and will send that request to that UDP service/server.
• Now, since UDP is a connection-less protocol so unlike TCP, UDP server will not send response over some connection, instead, UDP server will extract the source IP address and source port from the request and send the response back to client.

My confusion is that at server side, there is a socket which is bound to a UDP port and "continuously" listening for any UDP client request, but this is not true at client side, UDP client will open a socket to send the request to UDP server and then that's it, I think it cannot keep that port hanging for UDP server to respond, and if that port closes then how client will receive the response back.

I mean ofcourse, UDP server's response will reach back the UDP client because IP address is there, but once that response has reached UDP module of the client, even though there will be a port but how UDP module can send it to the client who originally sent the request because it would have closed the socket bound to that port? Or it will not?

I am looking for answer which clearly describes the UDP communication (I am not interested in contrasting it with TCP or explaining TCP since I have already fair understanding of TCP), especially how the response will reach back the UDP client.

Solution 1

My confusion is that at server side, there is a socket which is bound to a UDP port and "continuously" listening for any UDP client request, but this is not true at client side, UDP client will open a socket to send the request to UDP server and then that's it, I think it cannot keep that port hanging for UDP server to respond, and if that port closes then how client will receive the response back.

I agree. This is your confusion. Why do you think can't keep the socket open and do a receive on it? It can.

I mean ofcourse, UDP server's response will reach back the UDP client because IP address is there, but once that response has reached UDP module of the client, even though there will be a port but how UDP module can send it to the client who originally sent the request because it would have closed the socket bound to that port?

Why?

Or it will not?

Not.

The client:

• creates a socket
• sends a datagram
• calls recvfrom() or friends to receive the response.

Of course if the client isn't interested in the response it can close the socket, but this is not the normal case.

I am looking for answer which clearly describes the UDP communication (I am not interested in contrasting it with TCP or explaining TCP since I have already fair understanding of TCP), especially how the response will reach back the UDP client.

So don't tag your question with the tcp tag.

Solution 2

Yes, UDP server can send back to client. Here is an example: https://www.cs.rutgers.edu/~pxk/417/notes/sockets/udp.html and code demo https://www.cs.rutgers.edu/~pxk/417/notes/sockets/demo-udp-04.html

We now have a client sending a message to a server. What if the server wants to send a message back to that client? There is no connection so the server cannot just write the response back. Fortunately, the recvfrom call gave us the address of the server. It was placed in remaddr:

recvlen = recvfrom(s, buf, BUFSIZE, 0, (struct sockaddr *)&remaddr, &addrlen);

The server can use that address in sendto and send a message back to the recipient's address.

sendto(s, buf, strlen(buf), 0, (struct sockaddr *)&remaddr, addrlen)

Comments

[pjj]

Ok, if that is true that UDP client will keep that socket open, then it would mean that same UDP client cannot send more than 65536 (I know 1024 are reserved ports etc., but lets take this as a max. number) requests to a UDP server? (lets us not debate on how much possible it is for a UDP client to send so many request, instead try to focus on concept/theory) .. And if a UDP client keeps that socket open then in a way it would be like a UDP server, only thing that no-one would know about it because the port would be a random port choosen by client OS, this is understanding right?

[user207421]

It doesn't mean anything of the sort. A UDP client only needs one socket. Not one socket per server, or per request.

[pjj]

Ok, but lets say I want to make requests to different UDP servers then I think at the client side I will need 2 different sockets which would be bound to 2 different UDP ports. Even I think if I am sending 'n' requests to same server then also I think I need 'n' sockets and 'n' UDP ports because there is no connection between UDP client and UDP server, so in order to uniquely identify each request at client side, there has to be a unique UDP port?

[user207421]

I've already answered every single part of that. You're just reiterating your misconceptions. I can only suggest you read what I wrote again, specifically the part about 'not one per server, or per message'. The response is already identifiied by who sent it, and if you've issued multiple requests to the same server before reading any responses you would normally have a request-id in the request that is returned in the response.

[user207421]

I don't see what your purpose is in posting that link. There's nothing there that disagrees with this answer.

[frakman1]

"So don't tag your question with the tcp tag" - Well said. I think the misunderstanding by the OP is that the client has to always close the socket after using it to send to the client. That's true if you're not interested in a response. However, as user207421 rightly said, the client could decide to listen on the same socket for a response from the server which is perfectly fine too. Don't let the words client and server confuse you. It's more like sender and receiver which either side can do.