Typically, when a client first connects to a socket, the server doesn't know who that client is (what account/user.)

After the client/server agree on software and protocol versions, typically the first thing that happens is that the client authenticates to the server. This typically means sending a username ("this is who I claim to be") and a password ("this is how you know that I am actually who I say I am.")

The server then looks up name/password in a database (typically after hashing the password using scrypt() or bcrypt() or mcrypt()) and if the database comes back with "this player exists," then the server knows that the given connection, has the given player on the other end.

For TCP sockets, it's common to assume one TCP session is the duration for that authentication. If the client needs to disconnect and re-connect, name and password can be sent again. There are also various means by which you can first log in once, and get issued a secret token (only known by the server and you) which is good for some amount of time, identifying you as who you say you are. This allows the client to forget about the password the user typed in, sooner, which is slightly safer if the client gets hacked somehow.

For UDP sockets, there is no "session," so you typically have to build your own session handling on top of the protocol. Using the remote IP address and port number of the UDP packet is a good start; typically the server will also issue a secret value/id ("strong random session id") to the client, who will then include that ID at the head of each UDP packet to keep proving that the packet is part of the given session.

The server usually have states machine where it places the client in depending on what is going on.

When a client connects to a server, usually a persistent TCP socket is created that is kept open until the client closes or timeouts, the socket is kept open even when there is no data exchanged.

The server now have a few states the socket can be in (Not that this is just an example I am pulling out of my ass, but many MMO/multiplayer games have something like this):

1. Unauthorized -> Server requires the client to send username/password to go to the next state

2. Lobby -> The client has successfully sent username and password to the server, and the server found a username/password match, for the remainder of the session, the server knows who the client it. In this state the server waits for the client to pick an avatar (if available= and request to start playing.

3 -> Playing -> The client has selected an avatar (if available) and the server has started a playing session with that avatar.

In any of these states, the client (or server for that matter) can choose to shut down the session in which the client has start over, there are ways of recovering/reconnecting players currently in a game session during if that is a desirable behaviour.

Yes, stateful servers for UDP typically identify the remote client by remote IP:port. As I indicate above, you can also include an explicit session ID in your packet headers. This helps if, for example, the player is on mobile internet, and their IP address suddenly changes.

Threading is not needed to implement a stateful UDP session. The receicing server will typically call recvfrom() to get data from all clients that want to send it data, and then use a hash table from remote IP:port (and/or the session ID in the packet) mapping to established session information. There will typically also be a "cleanup" step that's run every so often, and removes sessions that haven't received data for some amount of time (i e, timeout.)