Creating a server handling 20k connected users
-
Hello,
I am working on a card game software using Qt and C++. Now I'm taking on the networking part, I mean the server side. I am going to implement a server that will:
- take login requests
- provide each client with the list of connected users that are currently looking for an opponent, and update that list in real time
- allow each client to start "hosting", meaning looking for an opponent
- allow each client to join another client so that they can start playing together
- allow each client to watch an ongoing game, provided that the players have not forbidden it
- process each request sent by the players ("I want to draw", "I want to move this card to this spot", and so on) by approving or denying it
- make sure that all requests are performed in the same order for all clients (players and watchers)
My knowledge in networking is extremely, extremely limited. I was going to start this project with a QTcpServer, but it is my understanding that you can't really manage tens of thousands of connected sockets, that would be way too many.
So I think it might be better for the server to communicate with clients using HTTP requests. That would require using an QHttpServer and I have a few questions:
- How can I make sure that all messages sent to, and received by the server, are encrypted? There is the QSslSocket class available, but then again, if I used one for every client, that would be tens of thousands of sockets to manage simultaneously.
- The state of any game would evolve because either Player A or Player B requested it. Let's say it's Player A. How exactly should I make Player B perform the same thing on their computer, since they didn't send any HTTP request? (Only Player A did.)
Please feel free to articulate your reply in detail, because again, my knowledge in networking is
nonexistentextremely limited. Thank you! -
HTTP is done over TCP so that won't change much.
Tens of thousands of connections should be manageable by a TCP server.I would use gRPC or something similar for such a project. Note that the QGrpc module is not available on the LGPL license but only GPL and Commercial.
You can use gRPC with the official Google lib though if you want to use Qt under the LGPL license.
Both implementations offer SSL integration.Looking at the peak concurrent numbers from Steam for the last 24 hours, 20 k connected users would put you in the top 100. That's a high target to aim for.
-
HTTP is done over TCP so that won't change much.
Tens of thousands of connections should be manageable by a TCP server.I would use gRPC or something similar for such a project. Note that the QGrpc module is not available on the LGPL license but only GPL and Commercial.
You can use gRPC with the official Google lib though if you want to use Qt under the LGPL license.
Both implementations offer SSL integration.Looking at the peak concurrent numbers from Steam for the last 24 hours, 20 k connected users would put you in the top 100. That's a high target to aim for.
@GrecKo Thank you for your reply.
What objectives in the list I made earlier, would be better achieved if I'm using gRPC? What made you suggest it?
Regarding the encryption part, it is my understanding that I should subclass a QAbstractHTTPServer and bind it to a QSslServer. This way both the client and the server would communicate in an encrypted manner. Am I 100% correct?
-
gRPC seems well suited since it will ease the message definition part and it's a binary protocol. It supports both synchronous and asynchronous operations and also unary or streaming RPC.
If you use a raw TCP server you'd have to define the protocol from scratch yourselves and handle the parsing/serialization of the messages. gRPC handles that for you.
If you use a HTTP server, you will most likely use something like REST that is less ideal for high throughput exchanges or streaming exchanges. It will most likely still work though.
gRPC has the advantages of supporting multiple languages and platforms.
More info here : https://grpc.io/docs/what-is-grpc/ -
That's more or less what REST is, just not in json and with less conventions.
-
Thank you @GrecKo. After more consideration, it looks like QWebSockets would be a better fit for my project, because I need continuous connection between the clients (the players) and the server. So there will be no HTTP server in the end. I have a question regarding QWebSockets, but that'll be in another thread.
-
P Pippin has marked this topic as solved
-
Hi @Pippin,
You're right that managing 20k+ users with QTcpServer and raw sockets can be very resource-heavy. Instead of using plain HTTP, I'd recommend looking into WebSockets with QWebSocketServer, which allows real-time, two-way communication and scales better for game updates. For encryption, you can either use QSslSocket directly or offload SSL using a reverse proxy like Nginx to handle HTTPS/WSS and let your server deal with plain TCP internally.As for syncing game state: the server should act as the single source of truth. When Player A makes a move, the server processes it, validates it, then pushes the same update to Player B and any watchers using WebSocket messages. This way, all players receive the actions in the same order, keeping everything in sync. Starting with a small prototype using a few clients will help you get the architecture right before scaling up. Good luck!
