Small game example using tokio for networking.

[angelorodem]

Hello Everyone,
I'm trying to make a simple example of a small online game using tokio, basically exchange and processing of UDP packets in real-time, the idea is to have a simple Tokio client/server example designed for a high quantity of peers while having low latency under high load.

So I have some questions that I would like to have some opinions on, both regarding the best way to get the behavior mentioned above.

My idea is (if endorsed by the tokio community) make it available here for other people to have easy access to this knowledge.

Server Side

1. What is the best way on the framework to receive a high quantity of UDP packets from a high number of peers, process, it and answer the peers as fast as possible.
2. What is the best way on the framework to broadcast data to specific group peers using UDP?
3. What is the best way to share data between peers?

Client-Side

1. What is the best way to send UDP data without blocking the UI?
2. what is the best way to receive UDP data without blocking the UI.

The idea is to have 8k peers sending 64/128 UDP Packets/S to the server and versa.

[Darksonn]

Here are my thoughts for the approach I would try first.

Server side

1. For receiving packets, I would spawn a single Tokio task with an UdpSocket that receives messages in a loop. This task wouldn't do much besides peeking into the packet to figure out which peer it came from and sending it on a channel to some other task.
   For sending packets, I would spawn a Tokio task for each peer, and each peer would have an UdpSocket it uses to send messages to that peer.
   I would likely have additional tasks beyond the above, and those would probably talk to each other with channels. I like channels. For example, you might want to run the game loop on its own task, or even on its own dedicated thread.
2. Ultimately I think you're going to have to send it to the task that sends udp messages to the peers individually, but you could have an intermediate step using Tokio's broadcast channel. Check out the pub/sub feature in mini-redis for inspiration.
3. Depending on the nature of the data, I would either have a single task own it, and have all other tasks talk to it through messages, or I would use an ordinary mutex around the data. Check out the shared state chapter in our tutorial. See also the db.rs file in mini-redis.

Client-side

1. and 2. Don't do networking in the UI thread. Your user interface should go on its own dedicated thread. Networking can happen in a Tokio runtime that runs next to the UI thread.