OK, let''s look at a worst case scenario... you have 10 clients connected to your server and you are sending out 100 bytes in an update If you do this in order, then the last client has to wait for 9 * 100 = 900 bytes to hit the wire before his even starts. On a 28.8 modem, that''s a good portion of a second, so obviously his data will be stale. He would certainly benefit from staggered sends.

That said, your server had better be on a decent network connection if you are sending 10 updates / second (~10k/sec), because you will be receiving about that much as well. Once you assume the server is on broadband, so that latency is not a problem, then it''s fine to just queue them all up at the same time -- and trust the network stack to get them on the wire as soon as possible. It''s simpler to design and a more efficient use of resources.

Besides, if you timestamp the update, then the remote host knows exactly how stale it is and can use prediction to compensate.

Also, keep in mind that people tend to play games with others who are close, often on the same wire. If you can lump updates into a multicast packet to all clients, or a subnet broadcast to some of them, you reduce both the bandwidth and the latency.