![]() If your round trip time is 100ms each message will be sent 6 times redundantly before being acked on average. But now if you have a high packet send rate (like 60 packets per-second) you are sending the same message multiple times until you get an ack for that message. You can avoid this by extending the system to have an upper bound on the number of messages included per-packet n. This is simple and easy to implement but if a large burst of packet loss occurs while you are sending messages you get a spike in packet size due to unacked messages. The receiver continually sends back the most recent received message id to the sender as an ack and only messages newer than the most recent acked message id are included in packets. Each outgoing packet includes the start message id followed by the data for n messages. It goes something like this: each message sent has an id that increments each time a message is sent. The easiest way to do this is to include all unacked messages in each packet sent. Reliable messages are simply included in outgoing packets until they are received. Sent messages are placed in a queue and each time a packet is sent some of the messages in the send queue are included in the outgoing packet. This way there are no reliable packets that need to be resent. lots of small messages included in each packet). This makes the most sense when the overhead of length prefixing and padding bitpacked messages up to the next byte is undesirable (eg. The way I prefer to think of it is that messages are smaller bitpacked elements that know how to serialize themselves. It’s not that bad, but you can do much better. This is the option that usually ends up looking a bit like TCP-lite for the reliable-packets. The basic idea is that the library resends reliable packets until they are received by the other side. You’ll see this approach in many network libraries. Different ApproachesĪ common approach to reliability in games is to have two packet types: reliable-ordered and unreliable. So let’s get creative and work out how we can implement a reliable message system that’s better and more flexible than TCP for real-time games. Many people will tell you that implementing your own reliable message system on top of UDP is foolish. After all, why reimplement TCP?īut why limit ourselves to how TCP works? But there are so many different ways to implement reliable-messages and most of them work nothing like TCP! ![]() Hi, I’m Glenn Fiedler and welcome to Building a Game Network Protocol.
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |