WebSocket: Sending a user-id with every message

Question

I am writing a simple multiplayer browser game that uses WebSockets to send information between the client and server.

When I initially designed the protocol, I decided that every message header will contain a user-id (a randomly generated UUID). If the connection was dropped the client would try to reconnect and the server will be able to identify the client by the user-id.

I've only used the connectionless UDP protocol to send data over the network. I realised that WebSocket is build on top of TCP which means that the socket acts more like a stream of data instead of individual packets that may or may not reach their destination.

I am starting to have doubts about keeping track of user-ids in the messages. Since TCP is inherently connection based do I need to keep track of the user-id? Are there actually any advantages of keeping track of the user-id? If the connection is dropped will the server and client reconnect silently? I haven't got very far in implementing the game. Should I just drop the user-id idea all together?

Answer 1

Putting a unique id in every message seems like overkill. Your websocket server should keep track of connections for you as long as they stay connected. But you will want the user id if the client becomes disconnected to maintain continuity, so I would send the user-id to the client only once, the first time the client connects. Then the client can send it back if it has to reconnect, and your game can resume where it left off.

Of course, using a session provider with your websocket server would take care of this as well...

Answer 2

TCP connections are stateful connections - data packets are sent from source to destination and acknowledgement packets are received from the destination by the source (bi-directional - either side could be the source or the destination) - this is handled by the networking stack and is invisible to you.

Reconnections, however, are not automatic, and it will take intervention on your part (most likely on the client side) to reconnect.

If you track clients just by IP & port only then a user id is probably not needed, however, most people use the internet through some various chain of NAT systems, wherein one IP visible to the internet conceals a multiple unknown number of users and networks. In those cases I think it does make sense to continue to identify your clients by a specific ID you have generated instead of just by IP & port. The IP and port is not in itself guaranteed to be unique, as that connection could be dropped and then another user could claim the same unused source port.

All this is also theoretical guessing on my part - my advice to you is to just start iterating on the design and see what works. :) No real need to try and design and anticipate everything perfectly before you have even started.