3 ms·

> For example, one of Glenn's earlier protocols kept a maximum of 32 previous message IDs, and operated at a rate of less than 30 UDP packets per second. Unackn

> For example, one of Glenn's earlier protocols kept a maximum of 32 previous message IDs, and operated at a rate of less than 30 UDP packets per second. Unacknowledged mandatory messages were given up on after 1 second of loss. That seems far more reasonable than what is described in this article. The protocol described in this article has terrible worst-case behaviour and should not be used. > I have good news for you. We game designers design these protocols to have a (low) maximum rate and a (low) maximum fixed length That doesn't help at all. You can pick any arbitrarily large or small per-stream data rate - it makes no different to the outcome. Let's suppose the arbitrary internet link under consideration has a capacity of X bits/sec, and your per-stream data rate is D bits/sec under zero packet loss. The number of users that this link can support is X/D. As the number of users approaches X/D, packet loss will begin to occur due to congestion. Suddenly this protocol causes the per-stream data rate to increase towards 120D. This means that X/D users are each sending 120D bits/sec towards the link, for a total of 120*X bits/sec. Now, recall that X is the capacity of the link, so we have just flooded it with 120 times its capacity. This link is now dropping approximately (1 - 1/119) == 99.2% of packets sent towards it. Consider: at no point did it matter whether X or D was large or small. The fatal behaviour is that when congestion is detected, the bandwidth usage increases by a significant factor relative to the norm. The factor of this increase will control the steady-state level of packet loss that the protocol converges on, when the network becomes congested.

felixgallo 12y ago
I don't think you understand what I wrote. Let me try to rephrase. All of these protocols are tightly bounded in size. There is no way for them to get to 120D over time. What we're talking about is, under packet loss conditions, moving from 20 (IP header) + 8 (UDP header) + 1 byte of command data + N bytes of state/overhead, to 20 + 8 + X bytes of command data + N bytes of state/overhead. N depends on the application, but for my implementation, generally it's around 20. So we're going from 49 bytes to, usually, around 50 bytes, and the absolute max for X is, say, 32; which would be 48 + 32 = 80 bytes, or a little less than 2D. Now, in a fictional universe where a game protocol operating at 20 updates per second and putting down 50 bytes is causing network congestion, I happen to agree with you. That would be terrible! Never, ever, ever happens, ever, not even .0001% of the time, ever; not ever. And further, never will. But I've only been doing this for 30 years.

felixgallo 12y ago

I don't think you understand what I wrote. Let me try to rephrase. All of these protocols are tightly bounded in size. There is no way for them to get to 120D over time. What we're talking about is, under packet loss conditions, moving from 20 (IP header) + 8 (UDP header) + 1 byte of command data + N bytes of state/overhead, to 20 + 8 + X bytes of command data + N bytes of state/overhead. N depends on the application, but for my implementation, generally it's around 20. So we're going from 49 bytes to, usually, around 50 bytes, and the absolute max for X is, say, 32; which would be 48 + 32 = 80 bytes, or a little less than 2D. Now, in a fictional universe where a game protocol operating at 20 updates per second and putting down 50 bytes is causing network congestion, I happen to agree with you. That would be terrible! Never, ever, ever happens, ever, not even .0001% of the time, ever; not ever. And further, never will. But I've only been doing this for 30 years.