We all know what accounts and the login forms are for, right ? ...

To me it seems arcane, I get what it is for but technically speaking (client <>server <>database) what problem does it solve ? 

If I ask myself the question I end up with this: some way to know who is who so that the server knows to look for data about a specific character linked to a specific account and send it to the right client. 

But how does it work anyways under the hood ? Is it just some persistent info about users sitting on the DB or is there something like a "session", like how we connect to a socket...?

I just want to have a near clear idea about how this works, the why's and the how's.

This all might sound strange, but, bear with me please.

Thanks to making it to this final sentence

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.

Thanks for your input, things are less cloudy now.  It got me thinking.

Other opinions would also be much appreciated !

What I struggle now with are state-full sessions.

I can't imagine client & server holding hands(the connection) when there's no data send/received respectively. At my state of knowledge I can only imagine them holding hand when there's ongoing communication.

But I have an idea though: is state-fullness achieved by uniquely identifying a client, by socket & port, with the server listening on this specific pair ? If so, is threading involved here ?

And in case of a state-full session, the session token is exchanged only once, right ? As opposed to justifying client's identity by sending the token with each request to the server.

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.)