CODEWITHSUNDEEP
mobiletcpudpclient-server
ForeverNoobie
ForeverNoobie

Reputation: 531

Tiny packets with TCP a bad idea? Better with UDP

I've seen posts that say that TCP's throughput lessens when you break info up into smaller packets. But I'm making a game server that really only needs to send tiny bits of information. It's a turnbased strategy game so the number of players I can support with 1 server is more important than latency, having said that I want to learn about controlling latency for future projects anyway.

So for lots of small packets is UDP a better choice? I do need them to be reliable though so if I lose packets I'll have to resend... Also what's the the actual loss rate of UDP packets? Say the server is running in normal conditions would it be as high as 5-10%? I should mention the client will be on mobile devices... their loss rate is probably much higher than a pc?

Upvotes: 1

Views: 964

Answers (1)

twalberg
twalberg

Reputation: 62379

No matter what the protocol - TCP, UDP or anything else - many smaller packets will be less efficient than fewer larger packets. Each packet has a fixed size header (or more properly, a header that has a minimum size but might be larger in certain circumstances) and possibly a trailer as well, so for a network pipe with a limited throughput, filling it with packets that are header + trailer + 1 byte payload means that almost the entire capacity is being used by metadata, not by actual data. Sending larger chunks of data in each packet improves efficiency. That said, sometimes your application architecture just doesn't have much data to send, so your options are either small packets, or larger delays while you aggregate a bunch of packets to send at once. Figuring out which approach to take (or something in between, even) is part of designing your application. In your particular case, with a turn-based approach, if I understand what you mean by that correctly, the time period in between subsequent packets is already going to be significant (by a network time scale anyway), so small packets are probably the best route. With larger delays between packets, the impact your stream of small packets will have on overall throughput is probably negligible.

Reliability certainly adds to the complexity. Using TCP would make reliability "easy" from a coding standpoint, but depending on actual characteristics of the network, writing your own re-sending UDP code might end up being the better route, especially as the overall reliability of the channel decreases. TCP will recover in most cases, but the various timeouts and the way they are adjusted due to certain events can be problematic over less reliable channels (one of the main reasons many VPN solutions are UDP-based).

Predicting actual loss rate is highly network-dependent, but you're probably right that losses traversing LAN - internet - LAN - mobile network (or some similar topology) are significantly higher than local LAN losses.

Upvotes: 2

Related Questions