High-load java server

Question

I am making a multiplayer game. Now I am trying to choose the technology to connect the android devices to the server. The clients run on Android, and the game is MMORPG. I would like to write the server in java. Right now I have only 3 ideas for it:

1) creating multithreading environment with plain java and sockets. In this way it will be easier to perform full-duplex connection between the game client and the server. But I have the following concerns:

1.1) The game is MMORPG with a large number of objects, and I am not sure how such solutions are scaled if there are for example 5000 people playing at the same time. How many threads will I be able to run on java Machine? How can I approximately calculate that? In case 1 thread is reading for each socket and 1 thread is writing to the socket (so 2 threads for 1 player).

1.2) When the number of players grows, how will I be able to scale my self-written jar-archive to distribute over several servers? Maybe there is some special trick to do that?

1.3) A lot of programming overhead - sockets API is quite low level.

2) Creating a Servlet-interface for serving HTTP requests.

2.1) Easy to control sessions (and authorization) as long as each player has his/her own session.

2.2) can connect to java EE EJB or whatever - a lot of complications with system-level programming are taken away. So I can concentrate on writing business logic.

2.3) Can serve all types of clients with HTTP - mobile devices + browsers.

2.4) High-speed - even 1 servlet container can serve a few thousand requests per second so it will be really fast.

2.4) But this approach cant provide a full-duplex communication. I will have to send requests every 1 second to check for updates. 1 second delay does not make a lot of difference for the game as it is turn-based, but still it generates a lot of traffic. Is it feasible when there are many players playing? I heard about some COMET technology, but it seems like if the server has to push many messages in row, I will still have to send requests every time + this technology is not well established yet.

3) Creating sockets and connecting them through JMS to the java EE server.

3.1) Cool because allows for full duplex communication between clients and server + provides all cool features of java EE. Later can be extended to browser through servlet interface.

3.2) It seems like some kind of overengineering. Is it really how people would do that? I mean is it even the correct way? Would any sane developer do it like that?

I would like you to help me out with the choice please. I dont have much experience with doing some work like that. And would like to stick to the best practices.

Answer 1

I do not think that Idea 3 would be over engineering, and I'd hit that road.

Building @MessageDriven Bean "adapter" that handles incoming socket connections in the onMessage method is easy to develop and from there you're in the well scaling EE world.

You your case, you might even want to rely on UDP. See following example: http://www.apprigger.com/2011/06/javaee-udp-resource-adapter-example/

But from my point of view there are other important reasons to go this way. Some pointers:

1.) As you've already mentioned. Building an own Socket Server handling threads and requests is a lot of work, and at the end you might build your own little "application server".

2.) Don't be afraid of using an application server. Of course people tend to call such a platform "overhead". Though when I did measure the amount of time to call other services or ebbs, using local interfaces did cost less than 10 microseconds a call. Having your own thread pools & workers and handling them yourself might be faster, although also not close to 0 microseconds ;-)

3.) Having an AS you're able to configure your instance boundaries very easily. Even more important you may scale your application a lot easier than self made software. Imagine having a cluster run on 2+ servers (and you will if your MMO is a success ). A network loadbalancer works for all kind of architectures, though having the possibility to share session informations (probably not for gamers connections, though why not for logged in users sessions) or entity mangers over clustered nodes is just "free" in the EE package.

All these EE tools & patterns give you time to develop the game instead of a framework ;-)