Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

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?

share|improve this question

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.

5  
The title of your question doesn't match the content of your question. Could you rephrase and be more specific as to what exactly you are designing, and what you need to know? –  Kylotan Apr 12 '11 at 11:56
1  
This could be a great question with even better answers, but its so poorly asked. Someone please rescue it. –  deft_code Apr 12 '11 at 15:34
    
Hi at least try to give the answer of poorly asked Question.. –  GameBuilder Apr 12 '11 at 15:38
    
I think you should not distinguish between Mobile and Desktop. Protocols are the same everywhere, and I think that hardware performance is also pretty much the same. –  Ivan Kuckir Mar 21 '13 at 0:01
add comment

4 Answers 4

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.

share|improve this answer
    
Thanks of the answer.. I will tell more detail about the game. I have to design PONG game in android.There are 2 mobiles and 1 game server.Application is installed in mobile .In mobile1(M1) can see the movement of bat and ball of Mobile2(M2) an vice_versa.Suppose if M1 hits the ball,all the movements of the ball and bat of M1 can be seen in M2 Screen and viceversa. Now i want to know which protocol i should use and why. –  GameBuilder Apr 12 '11 at 15:28
1  
Why do you find TCP easier? A stream flow is logically more complex to handle than single definite packets. If you consider UDP difficult because you want it to actually be TCP, well, you should be using TCP in the first place instead. –  Lohoris Sep 29 '11 at 9:52
    
why would TCP have bigger latency? if you have an established TCP connection, latency should not be worse than UDP. Packet loss is the real concern (which is problematic in wireless environments), latency is in this case just a consequence in TCP because of the built in retry mechanism. But the real issue is loss, which is noticeable also for UDP (and should be handled) –  KillianDS Mar 20 '13 at 20:57
1  
@KillianDS UDP doesn't only mean packet loss. You also have to handle dup packets, out of order, spoofed, neatly constructed fragments trying to smash your protocol stack. Do you really want to do this? –  ott-- Mar 20 '13 at 21:33
    
@ott-- and where does this contradict what I say? I know UDP-based protocols are a disaster to get right (I work with them day-to-day). I just show that latency itself is not different between UDP and TCP, it is usually just the consequence of packet loss. Of course there are other reasons, if you set up a TCP connection for each message your latency will be bad too, but that's just plain stupid. –  KillianDS Mar 20 '13 at 21:47
show 1 more comment

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.

share|improve this answer
    
Thanks of the answer.. I will tell more detail about the game. I have to design PONG game in android.There are 2 mobiles and 1 game server.Application is installed in mobile .In mobile1(M1) can see the movement of bat and ball of Mobile2(M2) an vice_versa.Suppose if M1 hits the ball,all the movements of the ball and bat of M1 can be seen in M2 Screen and vice versa. Now i want to know which protocol i should use and why. –  GameBuilder Apr 12 '11 at 15:27
1  
What would be difficult about UDP? –  Lohoris Sep 29 '11 at 9:51
    
> you can typically only use UDP for client-initiated messages –  Will Sep 29 '11 at 10:18
    
Have you ever even used UDP? –  Panda Pajama Mar 21 '13 at 3:24
add comment

On Stack Overflow there's an answer that says that mobile carriers don't allow UDP:

http://stackoverflow.com/questions/5861009/realtime-multiplayer-game-over-mobile-network

That would appear to make it open and shut: only TCP is viable, if that answer is correct.

share|improve this answer
add comment

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.

share|improve this answer
add comment

Not the answer you're looking for? Browse other questions tagged or ask your own question.