Menu
I am studying for my exams and found this question:
A typical UDP server can be implemented using a single socket. Explain why, for a TCP driven server, I find that two sockets are created - one where all clients approach the server, and one specific (socket) for each client for further communication between the server and client.
This is (in my understanding) driven by concurrency-issues (the wish not to communicate too much with a single client on the contact-point address). I know that UDP is connectionless, but can't illustrate it in my mind. I see that if a server is UDP-driven it can do a single action (pump a content repeatedly through/to a socket/port), which then could be listen to by multiple clients. If a server can react to two tasks - a get and a put. How can a client give an instruction without creating a connection? The client (in my mind) needs to send the get-request on a known port, and get the feedback on the same port. This would block the servers ability to communicate with multiple clients at the same time. Then would it be nicer to create a second socket to communicate on between the two parties so that potential communication between the server and other clients is not hindered? (as in the case with tcp)
297
UDP is a very simple protocol. Messages, so called datagrams, are sent to other hosts on an IP network without the need to set up special transmission channels or data paths beforehand. The UDP socket only needs to be opened for communication. It listens for incoming messages and sends outgoing messages on request.
int socket(int domain, int type, int protocol) Creates an unbound socket in the specified domain. Returns socket file descriptor. protocol – Protocol to be used by the socket.
Connected sockets have a full 4-tuple associated {source ip, source port, destination ip, destination port}, unconnected sockets have 2-tuple {bind ip, bind port}. Traditionally the connected sockets were mostly used for outgoing flows, while unconnected for inbound "server" side connections.
The reason is that TCP has two different kinds of state that you want to control, whereas UDP has only one.
For TCP, there's no choice, the socket API maps one TCP connection to one socket, which is between two endpoints.
For UDP, the socket API allows one socket to receive from many endpoints, and to send to many endpoints - so many servers use just one socket since there isn't any need for more.
In some cases, the protocol is a simple request and reply. There's no need to create another socket for that - just take note of the source address, and send the reply there - so that's what some servers do.
For others, the protocol might require longer lived data exchange where it's more convenient to create a new socket, so some servers do that.
This would block the servers ability to communicate with multiple clients at the same time.
Not necessarily. If the server CPU is busy executing instructions, it can't service anyone else regardless of whether it handles multiple clients on the same socket or not. If the server does blocking calls (e.g. a database query), or you want to exploit multiple cores, you can handle that in multiple threads, or use a threadpool pattern even with just 1 socket. The server just needs to keep track of the source IP address and port for each packet so it knows where to send the reply to.
But if it makes more sense for a particular protocol/application to use multiple sockets, e.g. one per client - there's noting wrong with doing so, the usual approach in that case is:
111
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
