Timeline for Acknowledgement reliability using UDP
Current License: CC BY-SA 4.0
14 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| May 30 at 14:04 | history | edited | DMGregory♦ | CC BY-SA 4.0 |
Adding link to source
|
| Jun 16, 2017 at 11:01 | history | edited | DMGregory♦ | CC BY-SA 3.0 |
added 46 characters in body
|
| Jun 16, 2017 at 10:59 | comment | added | DMGregory♦ | @JohnDvorak not quite. TCP sends the same old packet multiple times waiting for an acknowledgement, where this is describing sending the next update packet, with zero or more "back issues" included in the same packet as a bonus. I'll tweak the phrasing so it doesn't sound so similar. | |
| Jun 16, 2017 at 4:44 | comment | added | John Dvorak | "The client's updates can include the index number of the most recent update they've seen, so you can be minimally conservative in how many repeats you send." - hey, that's exactly what TCP does ;-) | |
| Jun 15, 2017 at 22:21 | comment | added | Kevin | Of course, TCP is built on top of a UDP-like interface (namely IP), so in principle the problem is soluble... but only to the extent that TCP solves it, which is less than the average developer may think. In particular, TCP connections can fail at any time, and there is no way to determine with certainty whether the last message arrived or was dropped. If you really wanted some kind of consensus between server and client, you'd have to use something like Paxos, but that's probably unsuitable for most gaming applications (both because of latency and because you need an odd number of peers). | |
| Jun 15, 2017 at 11:25 | comment | added | DMGregory♦ | @MSalters I'd say that's worth elaborating on in its own answer, if you're up for it. I'd upvote that. :) | |
| Jun 15, 2017 at 11:11 | comment | added | MSalters | It might also be useful to mention Forward Error Correction. Design your protocol such that the receiver can independently figure out that a packet was dropped when the next packet is received, adding some extra data to smooth out the required interpolation. This can be useful because often the UDP packets aren't full anyway, and you just send smaller packets more often to keep the latency down. Adding some extra bytes won't hurt the latency, and bandwidth is not an issue in these cases. | |
| Jun 15, 2017 at 7:04 | comment | added | Grimelios | That's extremely helpful and kind of validates my initial concern. Thank you very much. | |
| Jun 15, 2017 at 7:04 | vote | accept | Grimelios | ||
| Jun 15, 2017 at 5:48 | history | edited | DMGregory♦ | CC BY-SA 3.0 |
Adding a gif. Everything's better with gifs. And two-tier because complexity.
|
| Jun 15, 2017 at 5:42 | history | edited | DMGregory♦ | CC BY-SA 3.0 |
Adding a gif. Everything's better with gifs.
|
| Jun 15, 2017 at 5:32 | comment | added | DMGregory♦ | Yeah, for a turn-based game, I'd imagine one would use TCP rather than try to roll one's own reliability layer on top of UDP. ;) I'd still class the micro in an RTS as the type of gameplay with an exacting time horizon though - that hybrid approach may do well there, where you have both low-latency updates for the heat of the moment as well as a safety net to retroactively handle critical missed events like resource spending. | |
| Jun 15, 2017 at 5:27 | comment | added | Kromster | +1, well written. I would just highlight, that this is more relevant to action / real-time games. TBS and RTS games (and some action game's events) have a different view on "time horizon beyond which the information doesn't really matter". | |
| Jun 15, 2017 at 5:18 | history | answered | DMGregory♦ | CC BY-SA 3.0 |