Timeline for Acknowledgement reliability using UDP
Current License: CC BY-SA 3.0
16 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Nov 28, 2017 at 22:35 | comment | added | Brian | Packet Level Acknowledgements on top of UDP. In the header include a Sequence (current packet id), Ack (ID for most recent received), ack_bit (bitfield encoding the set of acked packets). If bit n is set in ack_bits, then ack - n is acknowledged. Each ack is sent a multiple of times. If one packet is lost, there’s xx other packets with the same ack. Use the same logic on both ends (client/server). | |
| Jun 16, 2017 at 13:51 | comment | added | CubicleSoft | TCP isn't entirely reliable. It is, after all, built on IP. TCP merely gives the perception of reliability. Packets drop on TCP all the time but that's mostly invisible to users under non-realtime scenarios. Even still, I recommend maintaining an active TCP connection in addition to UDP. Note that some firewall setups may actively block all UDP traffic but allow TCP just fine. Not all transports support UDP packet fragmentation so ideally attempt to fit all data into 512 byte packets. Depending on the network, UDP may also be QoS'ed to the bottom of the priority chain. | |
| Jun 16, 2017 at 9:14 | answer | added | Stig Hemmer | timeline score: 4 | |
| Jun 15, 2017 at 23:28 | comment | added | Grimelios | I agree @jrh. It's that initial connection problem where I ran into this problem in the first place. Still a good thing to keep in mind going forward, though. | |
| Jun 15, 2017 at 18:03 | comment | added | jrh | This isn't a direct answer to your question, but I strongly recommend only requiring an acknowledge in a real time game when they are absolutely necessary (e.g., on initial connection). It is far simpler (and robust) to design both the client and the server so that they "work with what they have" until they get a new packet in a stateless system if you can. Quake 3 did this incredibly well with a snapshot-based system. Also libraries like Enet can send only certain packets reliably, for those cases when you really need it | |
| Jun 15, 2017 at 15:52 | history | tweeted | twitter.com/StackGameDev/status/875380449828376577 | ||
| Jun 15, 2017 at 12:10 | answer | added | Peter | timeline score: 7 | |
| Jun 15, 2017 at 11:20 | answer | added | Stack Exchange Broke The Law | timeline score: 9 | |
| Jun 15, 2017 at 9:27 | comment | added | Polygnome | Use TCP when reliability is needed, use UDP when it doesn't matter. For example, the coordinates of the player are sent in my game via UDP. I use interpolation & smoothing to smoothe out any missing packets. works like a charm. things that really need to be reliable but can be a bit slower are sent via TCP. If you have state wehere newer state invalidates old state, UDP is a good choice becuase it doesn't matter when something in between was dropped 8e.g. player position). | |
| Jun 15, 2017 at 7:04 | vote | accept | Grimelios | ||
| Jun 15, 2017 at 5:19 | history | edited | Kromster | CC BY-SA 3.0 | deleted 96 characters in body |
| Jun 15, 2017 at 5:18 | answer | added | DMGregory♦ | timeline score: 33 | |
| Jun 15, 2017 at 5:14 | comment | added | Kromster | No guarantees at all. Right. Don't ever include "hope" in your algorithms. They must handle ANY unlucky combinations. P.S. We simply switched to TCP in our RTS, where eberything is taken care of, since we need reliable communication (for lockstep simulation). | |
| Jun 15, 2017 at 4:55 | comment | added | Grimelios | I might be, sure. You're suggesting my logic is correct and, not to sound too negative, but while network programming, I can assume no guarantees on virtually any piece of networked information? During the course of a real-time game, that's a ton of potentially dropped information, which is fine, but I just want to make sure I understand the issue. | |
| Jun 15, 2017 at 4:44 | comment | added | Kromster | Perhaps you are missing an idea of "timeouts" and "retries". | |
| Jun 15, 2017 at 4:38 | history | asked | Grimelios | CC BY-SA 3.0 |