Hi all

If I send 60,000 data packets of 20 bytes each using send() and TCP, how much header overhead am I gonna get? I mean, I hope not every send() warrants its own TCP packet with a full header, does TCP aggregate send()s and waits for data to pile up before forming a packet? How long does it wait before sending a packet if no more data is sent()?

Thanks

Thanks, you saved me tons of trouble by pointing me in this direction.

Now I see that it *is* necessary to send each data packet in its own TCP packet, otherwise timing gets thrown off.

So for a real-time game with movement orders and object positions being sent in a flux of 20-byte packets, you'd have to set the TCP_NODELAY option, to disable nagle's. Is it also necessary to set SO_SNDBUF to 0 and disable Winsock buffering? it seems so, otherwise you still get disrupted timing from buffering.

Keep in mind that even if you disable Nagle, there's no guarantee that every send() call will be a single packet.

Now I see that it *is* necessary to send each data packet in its own TCP packet, otherwise timing gets thrown off.

So for a real-time game with movement orders and object positions being sent in a flux of 20-byte packets, you'd have to set the TCP_NODELAY option, to disable nagle's. Is it also necessary to set SO_SNDBUF to 0 and disable Winsock buffering? it seems so, otherwise you still get disrupted timing from buffering.

Relying on network packets for timing is a bad idea. Basically, it won't work.

Any traffic on the network can throw off the timings horribly. Any network congestion, network rerouting, dropped packets, electrical storms with lightning in the air, solar flares, or just about anything else can throw it off. These are entirely outside your control.

For example, you may be running with almost exactly 30ms latency for the first thousand packets, but then the next one has 47ms latency, another has 3124ms latency, then 54, then drift to a new stable timing of 37ms latency.

This is true regardless of your choice of using TCP, UDP, or other protocols.


The time it takes to travel the network is entirely outside the scope of socket programming. All you know is that it will probably get there eventually. It may travel by fiber, satellite around the world multiple times, copper cable around a room, or it may travel by messages strapped to pigeons, wireless Pringles-can antenna, or even bongo drums. That takes place at a network layer far below those you control.


Do not make assumptions about how long it takes, because it is highly variable and completely outside your control.

@frob: LOL maybe I'll try the bongo drums method to improve latency

But seriously now, I'm having big problems with latency. When I run it on loopback it's perfect, but when I try it on a 170ms latency broadband WAN, I get tons of trouble. Most obviously, animation becomes jumpy and totally not smooth. Why is it? is it because I'm using TCP? I would have thought high latency only causes a delayed response time for the first packet, but then it's supposed to be smooth cause there's a stream of packets keeping it going. But it seems as if the client waits the 170ms for every packet seperately.

My networking & rendering are tightly knit, via the data object that keeps object position, gets updated by the network and gets redrawn much quicker than network-updated. What paces the whole thing is the rate at which the network updates the object, and somehow latency slows that down to ~5-6 times per second, instead of 30 or so.