Why does TCP socket programming need two sockets(one welcome socket and one connection socket) but UDP only needs one?

Question

Is this because a TCP connection is a persistent connection, so the server needs simultaneous process many request, therefore needing different connection sockets?

But if a UDP transfer finishes, the next connection will initiate to the same server socket, so UDP only needs one socket.

These are my conjectures. Is this correct?

Answer 1

The reason is that TCP has two different kinds of state that you want to control, whereas UDP has only one.

When listening for TCP connections on a port, the networking stack needs to keep track of the port number and interface(s) you are listening on with that socket, as well as the backlogged list of incoming TCP connection-requests for that socket, and it keeps that state in an internal data structure that is associated with the socket you pass to listen()/bind()/accept(). That data structure will be updated for as long as the socket exists, and will be discarded when you close() that socket.

Once you have accepted a TCP connection, on the other hand, the new TCP socket returned by accept() has its own connection-specific state that needs to be tracked separately -- this state consists of the client's IP address and source port, TCP packet ID sequences, TCP window size and send rate, the incoming data that has been received for that TCP connection, outgoing data that has been sent for that TCP connection (and may need to be resent later if a packet gets dropped), etc. All of this is stored in a separate internal data structure that is associated specifically with that new socket, which will be updated until that new socket is close()'d, at which point it will be discarded.

Note that the lifetimes of these two types of state are very much independent of each other -- for example, you might decide that you don't want to accept any more incoming TCP connections and therefore you want to close the first (connections-accepting) socket while continuing to use the second (TCP-connection-specific) socket to communicate with the already-connected client. Or you might do the opposite, and decide that you don't want to continue the conversation with that particular client, so you close the second socket, but you do want to continue accepting more TCP connections, so you leave the first socket open. If there was only a single socket present to handle everything, closing down just one context or the other would be impossible; your only option would be close() the single socket and with it lose all of the state, even the parts you actually wanted to keep. That would be awkward at best.

UDP, on the other hand, has no notion of "accepting connections", so there is only one kind of state, and that is the set of buffered sent and/or received packets (regardless of their source and/or destination). As such, there is generally no need to have more than one UDP socket.