Advise for p2p mobile game over 3G network?

Question

I have been making a mobile game that is similar to "Street Fighter" where two players play with each other via Internet.

The game sends out a small packet (controller status) to the other party every 30ms (a lot of packets going on).

I am currently using a server to connect two players and all communications are via TCP through the server. The server load increases a lot even for just 30 concurrent players. I know it sounds not wise to let the communication go through the server, so I think the best design should let these two players to communicate directly via UDP after the server hooks them up.

However, I have some questions when trying to move on to the new design:

Since it's a mobile game, players might be using 3G network a lot. Does UDP hole punching work well in 3G network? Does it matter when a player is actually moving physically (such as inside a car)? Do you think I should change the design or any recommendation of better design concepts?

Or, maybe a game that sends out packets like this is actually not a good idea for 3G network in the first place?

Answer 1

I know this is an old question but it is an interesting one, so in case anyone else wants to comment/discuss...

Its actually a very tough question and I think the answer will depend largely on your particular application - for example is it important that all the data arrives and that it is in the right order etc.

Take a look at the discussion here on this really useful Q&A for some background on UDP vs TCP and why it is not such a simple question:

• UDP vs TCP, how much faster is it?

At the data rates you are talking about, it is also worth noting that you are in the realm of VoIP type solutions so it would be worth looking at some of the discussion on VoIP, in particular focusing on RTP, which is the media stream - i.e. the actual voice packets as opposed to the SIP (for example) control messages which set up and control the call, and how it can be routed directly or via a server. This link has an excellent discussion on this in the VoIP/SIP realm:

• http://www.voip-info.org/wiki/view/Asterisk+sip+canreinvite

From your point of view it is worth remembering that having the traffic flow through your server gives you the option to analyse or modify it which may open up the possibility of new features now or in the future.

I'd also say that if all you are doing is forwarding the packets at this point you can probably find an architecture that will give you much better than 30 concurrent 'calls' on a pretty average server - again looking at architectures from the VoIP domain may be useful here (ones that proxy or forward RTP traffic, rather than the control servers which handle the signalling - e.g. SIP messages).

The VoIP work also has the same UDP 'hole punching' problem and there is quite a lot of documentation on this also, if you search for STUN and TURN protocols you'll get a good overview. Wikipedia links for both below:

• http://en.wikipedia.org/wiki/STUN
• http://en.wikipedia.org/wiki/Traversal_Using_Relays_around_NAT

If you did resolve this for your application it would be interesting to see the results here - maybe you can share it as an answer to the question also?

Answer 2

The problem is that in a 3G network, similar to public WiFi networks or other cheaper ISPs you end up with a mapped IP address behind a firewall. For example, on my device right now, my IP address of my phone is 100.116.200.55. But this cannot be pinged. Unfortunately I don't have a second phone of the same provider to see if at least the two phones could ping each other when on the same network. But once you are in a different cell, further away it is likely not to work any more, just like I can't ping my phone from my computer.

Whether UDP or TCP is not even the issue if you can't reach the phone directly. The only work-around to this is that the phones connect to a server which is publicly reachable. But that requires a server.