Turn-based mobile MMO over HTTP?

Question

Computer networks

Good day.
Need advice on the architecture of a mobile turn-based online game. Let's take the dice as an example:
Players roll the dice, clients send a request to the server with the information that the dice are rolled. The server waits for requests from all players, implements the game logic (actually, determines who threw how much) and sends the results to all clients.
Will I lose much in performance if I implement this via http compared to a constant warm lamp tcp connection? that is, requests come in, the server does not respond to them immediately, as soon as all requests have arrived and the logic has worked out, a response is sent to the requests.
It happened to me 1000 CCU - will such a decision be a mistake? 10000?
The game is turn-based, for mobile phones.

Answer 1

Will you lose much from a data wrapper in a couple of extra kilobytes? It's easy to calculate: 2 kb * 1e4 = 20 mb. For a game server, this is very small.
Why do it? You do not know how to work with tcp? You do not know how to maintain a connection on tcp? Are you making a browser game wrapped in a mobile app?

Answer 2

This is called long polling . You can google the features of the solution for this term.
Globally or on a physical server? Those are different things. As I understand it, all the same, based on a physical server. But the server-server is different, as well as the CCU itself, taking the "load profile" says little.
In general, it is easier to get answers to such questions experimentally (to assemble a simple prototype and set bots on it).
For a prototype and 1000 CCU, it will definitely be enough if the moves are not frequent. For example, I made a debugging matchmaker according to this principle.
If there were no multiplayer (when the user is just waiting for something), then it would work for the sale.
In the case of multiplayer (when users are waiting for each other), I see no advantages over supporting a regular connection, except for the time saved for MVP development. The downsides are crutches to support the connection and determine disconnects. For the case of low-level work with tcp, there are a lot of manuals and "standard" solutions. In the case of working at a level not lower than http, unforeseen problems may arise due to the middleware and the protocol itself.
In addition, with the simplest implementation of long polling, one of the connections will be busy processing one command and it will be impossible to send another. This means that you will need to make separate http requests for each additional command. Theoretically, you can drive and send several commands through such a connection, but this will no longer differ from your own protocol via tcp (except for additional brakes and crutches).
On the other hand, nothing prevents you from making two requests: one to send a command, the other (periodic) to get the result. A small delay can be provided in the request to send a command, in case the move is made almost immediately after receiving the command.
Summary:
- if there is expertise and time: do normal communication via tcp
- if the expertise is not very good and the deadlines are not burning, then do normal communication via http with two commands (send changes, get the current state)
- if you need it yesterday, then long polling will do.

Answer 3

you need a websocket. You can also make a reaction to the system through the http api, but the reaction of the system has the right to come only in this way