Question

Currently, my game works like this.

The user connects to the server using TCP.
At this point, the server has not allocated a player object and assigned it to the TCP client object.

When the user sends a LOGIN message with their username and password hash, the server checks the database to see if that all adds up and if it does it sends a LOGIN_ATTEMPT_RESULT message with true. The server then allocates a player then sends the player a state of the lobby and from then on, when the server gets a message from that user, it processes it and they communicate.

I don’t keep a session id or anything since it does not seem necessary.

Is this basically how a game like this would do authentication and communication or am I missing something important?

Thanks

Answer 1

Keeping a session ID is nice because it makes TCP packet injection attacks (sequence guessing) harder, and it allows continuity of login even if the TCP connection is lost for some reason. This way, a “session” and a “connection” are distinct and the latter can be reestablished as needed. Also, if you expand to multiple machines, the session ID can be used as a means of passing between hosts (the connection would be recreated but the session persists). Finally, a session ID can be used as a database key (again, for passing between servers).

If you need none of this, then you can ditch the session layer. Doesn’t seem like much of a savings, though.