I am building an MMO and someone told me I should never have my application interfacing directly with the net, and that I should have a local proxy. This makes sense, with security issues and scaling simplicity (add more servers behind proxy). But I'm not sure of the best way to implement this.

My gameserver is written in java, and I'd like to write my proxy in Python.

These are the methods I can think of to communicate between proxy and server:

A) Game Client <-> UDP Protocol <-> Python Proxy <-> MySql Database <-> Java Server

I like this because it would force me to constantly save and store game server information (player and npc position, rotation, and health, item's and backpacks...). I would need to do this anyway, but maybe not every time I get a packet. Only issue I can see is performance with making all the database queries on both proxy and server.

B) Client <-> UDP Protocol <-> Python Proxy <-> TCP Protocol <-> Java Server

I don't want to use UDP locally because UDP has packet loss and it's not worth doing locally *. TCP would work and be easy to implement but may have performance issues since TCP has a lot of overhead.

* not entirely sure if true.

I plan to go with option A) but would like to know what you guys think, and if there are any other viable options to look into. So what do you think A, B or something else?

Thanks in advance.

  • 2
    \$\begingroup\$ For populations of any size or complexity you're going to want to work with important state variables like position in memory and only periodically persist, the drag on the system otherwise is too much. You definitely need to separate states requiring ACID transactions (item transfers, money) from transient and non-critical states like position. So B is my call from those two choices. Your friend is 100% right when it comes to the databases, others will chime in on other server designs - I'm less familiar with those. \$\endgroup\$ Commented Mar 6, 2012 at 7:31

1 Answer 1


First of all, if you are doing a MMO, do that first and worry about issues you don't need now and you can "bolt on afterwards" later.

But if you insist, here are my 50 cents:

If you want to use MySQL as an interface between a proxy and the game mechanics server written in java then you will have a (very very) high latency between the moment a client asks for something and the time it gets an answer.

Secondly, the java server would probably do some polling scheme which will add further latency.

Third, when an UDP packet gets lost (and that will happen, trust me), you need to have some sort of timer that refires the packet which means even more latency.

This makes the setup clearly out of the range for a real time application (well, that's my opinion anyway).

If you don't want to go with a more simple setup, I'd advice this:

Game Client <-> TCP Protocol <-> Python Proxy <-> Java Server <-> MySql Database

or the simpler / better:

Game Client <-> TCP Protocol <-> Java Server <-> MySql Database

UDP is rarely needed nowadays, may it be for latency or bandwith, and as far as I can tell, the only bonus would be to be able to deflect some kind of attacks but for that you'd need even more proxies and a smart scheme to reroute data (you don't need that now though).

  • 1
    \$\begingroup\$ I failed to mention this but, I have a prototype client (no final art assets) and a functioning game server that handles the NPCs. Current communication between game client and server is via UDP with no proxy. So your saying a not to have a proxy, and have communications via TCP. From what I've read UDP is standard for realtime games. Well interesting. I'll have to try out TCP and do some benchmarks. Thanks. \$\endgroup\$ Commented Mar 6, 2012 at 18:53
  • 1
    \$\begingroup\$ Some modern clients mix and match UDP and TCP, you're not just stuck with one means of communication you know =) \$\endgroup\$ Commented Mar 6, 2012 at 19:54
  • 4
    \$\begingroup\$ Strongly disagree RE: recommending TCP over UDP for game usage. TCP packets get lost and need to be re-sent just as often as UDP packets. Additionally, when this happens in TCP, the whole network communication stream gets backed up while that re-send happens. Under UDP, a single lost packet doesn't block your communication channel, and other packets can still make it through. For many types of data ("I'm here now. Now I'm here. Now I'm here. etc.") you'd rather keep getting updates than have everything stop and wait because one packet got lost. \$\endgroup\$ Commented Mar 6, 2012 at 20:49

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .