http://en.wikipedia.org/wiki/Nagle's_algorithm

Even with Nagle’s algorithm disabled my points about TCP’s behavior under packet loss still stand. When a packet is lost TCP must wait for that packet to be resent. While waiting any other (out of order) packets received are held hostage in a queue so that the data transmission looks like a reliable ordered stream.

The only way to avoid this is to use UDP.

read the article or reliability and flow control later on in the series for more info about how to setup an ACK system over UDP

cheers

Dedicated servers generally run at fixed tick rates, but each player is in their own time stream (fps), and thus advance each player forward independently in time with (potentially) variable dt.

Clients typically run at whatever framerate they like, the exception being if you are synchronizing via deterministic lockstep therefore each player would need to have the same DT for everything to stay in sync, also, fixed dt (or at least, a multiple of a fixed base dt) is very useful for networking physics simulation

cheers

regarding two packets per-frame. it’s certainly “OK” but is not ideal. consider that each UDP packet has both a UDP header (8 bytes) and an IP header (20 bytes average) — if you group all of your data together in one packet per-frame, you get more payload bytes vs. packet header overhead

cheers

On UDP, can you guarantee that one recvfrom() matches exactly one sendto() ? I.e if a client sends 3 messages/frame at 30fps will they arrive in 3 recvfrom/frame? On TCP they will surely arrive concatenated by the TCP layer. The problem is code design for parsing the array received from the socket – if i expect a single UDP header(seq, ackbitfield) and more than one game headers( a server sends X*playerAction messages concatenated by me) ; or i must expect multiple udp headers.

For an action game, is it ok to have always 2 sendto/frame ? i.e. one for position(unreliable) one for actions(reliable) or the number of sendto/frame shoul be minimal?

Thanks a lot!

I am curious about something. You always refer to 30 packets/second so i am guessing that all multiplayer games must be tick based(i.e on tick X everything is the same on all machines).

The problem is that on slower machines(phones) you cannot limit the fps to it;s lower value because it would be too small. A way around it is to have constant 30 calls/sec to update and up to 30 calls to render. So each render will interpolate between the next update and the last one. Another way is to use everything time-based and have variable fps between machines. I think this may be a problem implementing lock-step games… what do you think?

Thank you again for sharing your knowledge!