ee4b7305a2
This PR adds all the guides from [Visual Guides](https://bytebytego.com/guides/) section on bytebytego to the repository with proper links. - [x] Markdown files for guides and categories are placed inside `data/guides` and `data/categories` - [x] Guide links in readme are auto-generated using `scripts/readme.ts`. Everytime you run the script `npm run update-readme`, it reads the categories and guides from the above mentioned folders, generate production links for guides and categories and populate the table of content in the readme. This ensures that any future guides and categories will automatically get added to the readme. - [x] Sorting inside the readme matches the actual category and guides sorting on production
1.7 KiB
title, description, image, createdAt, draft, categories, tags
| title | description | image | createdAt | draft | categories | tags | |||
|---|---|---|---|---|---|---|---|---|---|
| TCP vs UDP for Online Gaming | Explore TCP and UDP protocols in online gaming for data transmission. | https://assets.bytebytego.com/diagrams/0315-reliable-udp.png | 2024-03-10 | false |
|
|
A common practice is to use RUDP (Reliable UDP). It adds a reliable mechanism on top of UDP to provide much lower latency than TCP and guarantee accuracy.
The diagram below shows how reliable data delivery is implemented in online gaming to get eventually-synchronized states.
Suppose there is a big fight in a simulation shooter game. Characters A, B, and C open fires in sequence. How does the game server transmit the states from the game server to the game client?
-
Steps 1 and 2 - Character A opens fires. The packet (packet 0) is sent to the client. The client acknowledges the server.
-
Step 3 - Character B opens fire. The packet is lost during transmission.
-
Steps 4 and 5 - Character C opens fire. The packet (packet 2) is sent to the client. Since the last successfully delivered packet is packet 0, the client knows that packet 1 is lost, so packet 2 is buffered on the client side. The client acknowledges the server for the reception of packet 2.
-
Steps 6 and 7 - The server doesn’t receive the ack for packet 1 for a while, so it resends packet 1. When the client receives packet 1, all the subsequent packets become effective, so packets 1 and 2 become “delivered”. The client then acknowledges the server for the reception of packet 1. No packets are buffered at this point.