How to organize the synchronization of the game world between the client and the server?

Question

Data synchronization

I decided to write a network game and came across an area little known to me - synchronization of the client with the server.
Important data:

• The game takes place in real time, so speed matters.
• The game world consists of a number of two-dimensional maps (they consist of cells) that remain unchanged during the game. Each card is 512x512 cells.
• The cell consists of (in order of drawing):
  In parentheses - significant data for the player.
  1. "Earth" (picture, non-unique name, unique id) - 1 pc.
  2. "Movable" objects (picture, non-unique name, unique id) - 0:30 pcs.
  3. Earth effect (picture) - 1 pc.
  The client has all the images, there is no need to transfer them over the network.
• "Mobile" object - an object capable of moving an indefinite number of cells.
• Each player has a limited field of view (20x20), data about objects outside the field of view should not be known to the player. The player can move around the map, either by moving one cell, or by jumping an unknown number of cells (this rarely happens).
• It is assumed that all calculations take place on the server, the client is only rendering and transferring the player's actions to the server.

What is the best way to organize the synchronization of worlds between the server and clients?
Please either suggest an algorithm for such synchronization, or advise a book / article (English or Russian) that would help deal with this issue.
UPD1:
A couple of clarifications:

• On average there will be 30 players.
• The most important part of the question: the organization of data transfer during the game.
  Everything is clear with initialization and termination.
• Here and now there is interaction between the players and nothing more. No bots, mobs, etc.

Answer 1

Look at the question https://toster.ru/q/142555, it contains some points that will be useful to you. I'm including a few links to "read".
And the solution to your problem will very much depend on the number of players in one location. If there are few of them (say, less than a couple of dozen), then each such location is likely to be independent of the others, and the synchronization task will become much easier - fewer objects will require synchronization. And on one server several such locations will fit.
If there are many players (a hundred or more), then the architecture will become very complicated. So much so that it makes no sense to start studying on such a project. Read the question I posted above about this.
What technology is planned on the server and on the client? (programming language, platform)

Answer 2

A very broad topic. Books are written about it. Here are a couple of general tips

• Make the client in the browser, less hassle, wider audience. This choice limits the transport to websocket and the data format to JSON (well, also msgpack).
• When synchronizing the distributed state, check not the entire array, but only its step-by-step changes as git and rsync do (if possible, use not shared state , but message passing) The entire array can sometimes be checked for consistency by its hash sum.
• Accumulate state on the server as a sequence of changes addressed by a hash sum, just like git does. (Google content addressable store here)
• When seeking consensus, use 'he knows that I know' rather than 'who's first'. (google protocol consensus here)
• Determine what degree of data duplication on the server and clients is sufficient for the consistency of the game and is acceptable for the price of resources. (google sharding replication here)

Answer 3

Why the hell sync them?
TCP for the quest accepted, gave the quest, and for the unit, the tryam ran here.
UDP if you want to do packet bombing.
Caching for "hot" things, database for "warm" and more or less static. You don't need to render the map on the server. Read about thick-thin client.

Answer 4

1. The client requests an update from the server only when it is active (not minimized, the modal window with settings is not open).
2. For authorization, the request to the server contains the session identifier created when entering the game.
3. The server returns information only about visible cells and the player himself. Do not trust user data - you should not send the current position of the player in the request, it must be stored in the database (this is also required to implement 1 point).
4. Calculate the movement of mobs only for those locations where the players are (or have been recently), generate maps only when the player moves to this location.
In general, try not to calculate extra data on the server, not to request data from the client when it is not necessary, and not to transfer data to the client in excess of what is needed.

Answer 5

Everything here is simple:
1. Polling for events from clients in a circle ("round robin")
2. Order: batch-> check-> set values ​​on the stack (or discard)-> move to the next event (and so on until the delay limit will not be reached) -> sending the final result of the "world" to everyone who sent the event -> the next portion, etc.
Thus, the rule is achieved: "everyone knows about everyone synchronized and without delay, and they are also checked on the server."