Sockets with a client / server model ...
Basically, you and your friend create different client implementations.
The local client shows a visual representation of the game and saves the state of the figures (position, killed / not killed) and the rules that the pieces can / cannot do (what steps can be taken, with which pieces the state of the board is checked).
The remote server stores the status of the players (whose move, points are earned, won the game or not) and a list of moves that occurred.
When you make a move, your client checks the move against the rules of the game, and then sends a message to the server, which says I made this move, your move.
Another client sees that a turn has been made, pulls the last move from the server, calculates whether there was a place of movement, checks the move against the rules of the game and repeats the action locally. After that, everything is done, now it allows the user to make the next move (or not, if the game is over).
The most important part of the game communication between the client and the server is to send as little data as possible and save as few states as possible on the server. Thus, you can play it locally or around the world with little or no delay. As long as your client works under the same set of rules as your opponent’s client, everything should work.
If you want to make sure that no one can deceive by hacking your version of the client, you can do all the calculations of the position and rules on the server and just make the clients only simple playback mechanisms.
The reason sockets are the best means of communication:
- constraints on process communication are almost as complex as node cross-connectivity
- Widely supported network on all systems.
- there is little or no entry barrier to using this remotely if you choose
- Networking is reliable, flexible and proven.
This is part of the reason why many major systems, such as databases, use sockets as a network, as well as a local communications environment.