I am designing a mobile game, but I don't know much about it.
How do we differentiate HTTP, TCP and UDP in reference to mobile game?
closed as not a real question by Trevor Powell, bummzack, Byte56♦, Josh Petrie♦, Sean Middleditch Mar 24 '13 at 6:04
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center. If this question can be reworded to fit the rules in the help center, please edit the question.
HTTP is just another protocol on top of TCP, therefore I'll skip it in my answer. Use HTTP only for infrequent simple notifications like highscore uploads.
Beej has a good tutorial on TCP and UDP socket programming: http://beej.us/guide/bgnet/output/html/singlepage/bgnet.html
Basically TCP is a connection oriented protocol. A client connects to a server, they exchange some messages, one of them closes the connection. You can think of it as a bytestream flowing directly from one side to the other. TCP makes sure no byte gets lost and all of them arrive in order.
UDP doesn't provide anything of this. It is very low-level. You just send a bunch of bytes (message) to some destination (address). UDP will build a packet out of these and send it on its way. There is no guarantee it will ever arrive.
For high-performance multiplayer games you need UDP, because you can't afford the latency overhead of TCP. But you have to handle all of those cases where packets get lost, duplicated or reordered yourself.
If latency is not of concern go for TCP. It is much easier to use.
One key difference between UDP and TCP is, for lack of a better phrase, "ownership of receipt".
In UDP the receiver is responsible for guaranteeing receipt of all required messages. This is particularly useful for streaming media content, becuase in most cases if a message is lost the receiver doesn't care; the frame is past history and had a spot of snow. No harm no foul.
In TCP the sender is responsible for guaranteeing delivery, so if no acknowledement is received before timeout the message is resent. There is greater overhead on both sides, plus greater traffic in the form of all the acknowledgements; but the benefit is a more reliable delivery.
UDP is difficult; you can typically only use UDP for client-initiated messages.
Also, TCP is also particularly high latency for mobile. And its very bursty; it might be running very fast and suddenly it drops right off.
But TCP works pretty much across the board.
There is no widespread peer-to-peer networking for games; all gets bounced through a central server.
You can do fun peer-to-peer stuff using any platform-provided push mechanism e.g. C2DM on Android, but that only suits turn-based slow games.
On Stack Overflow there's an answer that says that mobile carriers don't allow UDP:
That would appear to make it open and shut: only TCP is viable, if that answer is correct.