Using a UDP socket is similar to using a TCP socket. First, you open and name the socket. We only named TCP sockets if we were going to listen on them for incoming connection requests. With UDP, we must bind a name to every socket that will receive data, whether or not it sends data first.
If the socket receives data first, we need to bind it to the address to which the sender is sending. If the socket sends data first, we need to bind to an address, even if we let the Net Library assign the port.
Connecting UDP sockets is optional, a programming convenience with no network implications. It provides a default address for send operations, allowing developers to call the Net Library send functions the same way as they would for a TCP connection.
There is, of course, no acknowledgment of this connection from the server. The server is not even aware that it has occurred; it only has meaning in the local host’s UDP stack. There are also no operations corresponding to listening or accepting connections; the server is completely oblivious to the connection. Multiple UDP sockets can connect to the same server socket.
UDP sockets can send to and receive from different remote hosts each time. There is little overhead in switching between remote hosts. The socket might exchange data with multiple remote sockets or only with one. The remote socket might send data only to our socket, it might send data to our socket and others, or it might not send data back to our socket ...