Rust game server for turn-based game, how best to implement?

Question

Rust

Hello everyone, I recently started learning Rust, and I want to practice in parallel.
I decided to try to make a simple turn-based game with multiplayer, with a server in Rust and a Client in Unity (C#).
Prior to this, there was no experience in multiplayer solutions at all, I could do a simple web-api on Sharpe at most.

I don’t really want to write my own solution from scratch, and there is not much knowledge on this topic, but the number of libraries makes everyone’s eyes run wide.

I would like to make the game itself as simple as possible, in terms of architecture. Much like in chess. The two players take turns making one or two moves per round.

I would like to get a couple of answers to these questions:

1. What would be the best networking library in Rust to use? (For example, I saw tokio, but I don't know if async io is good for a networked game like chess, where players quickly make moves in turns)
   
2. Should the connection type be a socket? or what is right? I somehow did all sorts of chats on websockets, I don’t know how everything should be in game servers ...
   
3. Which protocol is better to use? (tcp seems to be the most adequate option for me, but you never know there are some pitfalls)
   
4. How it is better to make a message exchange between the client and the server? For example, I want the whole game to be only on the server, and only input comes from clients, how best to make communication between them? The very first thing that came to my mind was json or xml, but there is an array of bytes on the socket, like you have to serialize everything every time, and is it all the time, delays, or is it still a normal option?
   

Answer 1

1. Tokyo - practically no alternative.
2. No, the session with the client is just better to abstract from sockets. The client software must be able to terminate the tcp session and then reopen it. And all this should happen without losing the actual session.
3. Not necessarily. The protocol can also be implemented on udp. http/3 for example is quite udp-based.
4. Serialization-deserialization here in any case takes place. I think in this case json/xml is a normal option. As an alternative, you can also look at protobuf, here everything will definitely be faster to serialize-unpack than in json.