As long as I stay under MTU, the protocol as designed should be able to cope with 50% packet loss… but we’ll see. 50% packet loss when you exceed MTU can mean that you miss almost all of your messages if you are unlucky. Under MTU means you only miss some of your state… but since state is mostly redundant then it recovers. Also, exceeding MTU will increase latency since the final UDP message will be as slow as its slowest part.
I can send about 100 object state updates per “frame” and still fit under the standard MTU of 1500. Normally, I’d pack three frames in a message if I can fit them but at 100 objects I’d have to do a message per frame. The protocol also supports splitting frames. The worst case for me is when there are more than 100 objects moving in a user’s zone view and a consistent 50% packet loss that causes the second part of a split to consistently never arrive. It seems unlikely that a UDP channel would predictably lose every other message, though. Also unlikely to have 100 zone-local objects fully moving every frame.
5-10% packet loss overall often means there can be several seconds of 50% or more packet loss. Especially over wireless routers.
Anyway, the point would be to figure out where networking performance is so bad that playability degrades. I think latency will be more critical than dropped packets… which is good because in previous testing even low-latency connections can have periods of relatively high packet loss.
The interesting thing is that because of the double-ack parts I added to the protocol, not only can I accurately detect how many dropped packets there are but I could also detect when they are late, when it is consistently every second or third packet, etc… if I wanted to go that far. Hopefully I can provide feed back to users when their connection is too bad to play properly, based on this testing.
As an aside: if anyone is interested in my BitInputStream and BitOutputStream then I can post them to contrib or something. They are well tested at this point. It allows writing any size bit string (up to 64) to a stream and packs it all together as it goes. So you can write 1 bit, 1 bit, then 6 bits and get a byte, etc…