I see that this question has been asked before but the context around the questions are usually vague. I’m looking to build an Android multiplayer real-time game where there is global state that needs to be shared amongst all the clients. Thus, I have a tendency to believe that UDP might not suffice. TCP gives reliability but with the inherent overhead. However, since this is the first time I have tackled such a problem, I’m looking for some feedback from other peoples experiences.
Therefore, (generally) in the context of a multiplayer real-time game on an android smart phone, is the overhead associated with TCP acceptable enough such that the user experience is not affected to such an adverse extent? Also it’s worth mentioning that the TCP connection would have to be a persistent connection. Also, would UDP coupled with some reliable custom developed mechanisms be a better approach? Any input would really help me out & would be greatly appreciated.
many thanks indeed
The best answer is probably “try it and see”.
I’m of the opinion that TCP overhead isn’t really that big of a deal for most applications. Header size is on the order of 10 bytes larger, and ack messages have to be sent back and forth for each message.
The real killer for a real-time game is going to be latency. UDP is fire-and-forget. That means each message just lags by the transit time between the two nodes. Since TCP requires an ack, a message isn’t really considered “sent” until the other side is heard back from.
Generally, the issue between them boils down to error detection. If a message gets lost in the interwebs somehow, how would you like it handled? If every message is fairly vital, then if you use UDP you’d just end up having to implement your own TCP-like protocol on top of it. You might as well use TCP and let the network hardware help you. However, if old messages after the time it takes for several retries (each at network latency) are going to be garbage anyway with new updates coming in, then TCP is a waste of bandwith for you.