Ok good to know, and yes I agree with you, if you lost 64 packets in a row you're not gonna catch up.
In my experience, flow control doesn't work well for real-time games (just like it doesn't work for, say, IP telephony.)
If you run out of window space -- 64 packets in this case -- it's likely the client on the other end is either gone, or having a terrible experience already. At that point, it's not going to catch up. You might as well kick it; it won't be a productive part of the gaming session at that point. Unless the game has some very special semantics, such as a slow turn-based game. But then, why would you be using UDP? :-)
[quote name='fjholmstrom' timestamp='1347355549' post='4978838']
This confused me a bit, I realize that obviously how much data you can send/receive effects how fast you can ACK and what you ACK, etc. but the window size for me is artificial window over the sequenced packets you send, but it seems like you're talking about the window size as a receive buffer here? Maybe I'm just confused, but it's not clear on what you're trying to say to me at least!
No, I'm just saying that usually you have a fixed sized buffer (say, 64K) where you push data one end, and transmit to the client the other end (often done as a ring buffer), and if your buffer becomes full because your client hasn't acknowledged fast enough (trying to send faster than is received), then you need to deal with the case.
For example, if you call send() with TCP / IP, the function will return the number of bytes actually added to the buffer which may be less than the number of bytes you tried to send, because the buffer is running out of memory.
Not everyone cares though. It's nit picking. Some just use dynamic allocation with gemoetric growth and shrink to adapt for slow / lossy connections. Again, I would just kick them and not bother, but you may have 'spikes' at some points in the game, and where the buffer fills up in short amounts of time, so kicking a client because he hasn't acknowledged a X amount of bytes can be a rather arbitrary rule.
[/quote]Ok, good - was just double checking, maybe it's me not being native English but I couldn't quite make out what you were getting at in the original post, thanks for further explaining it!
