High speed java server

I am making a multiplayer game. Now I'm trying to choose the technology for connecting Android devices to the server. Clients work on Android, and the game is MMORPG. I would like to write a server in java. Right now I have only 3 ideas:

1) creating a multi-threaded environment with simple Java and sockets. Thus, it will be easier to make a full duplex connection between the game client and server. But I have the following problems:

1.1) MMORPG game with a large number of objects, and I'm not sure how such solutions scale if 5000 people play at the same time. How many threads can I run on java Machine? How can I calculate this? In case 1 thread is read for each socket and 1 thread writes to the socket (so 2 ​​threads for 1 player).

1.2) When the number of players grows, how can I scale my self-written jar archive to be distributed across several servers? Maybe there is some special trick?

1.3) Many service data APIs are pretty low.

2) Creating a servlet interface for serving HTTP requests.

2.1) It is easy to control sessions (and authorization) if each player has his own session.

2.2) can connect to java EE EJB or whatever - many complications when programming at the system level are selected. Therefore, I can focus on writing business logic.

2.3) It can serve all types of clients using HTTP mobile devices + browsers.

2.4) High-speed - even one servlet container can handle several thousand requests per second, so it will be very fast.

2.4) But this approach cannot provide full duplex communication. I will need to send requests every 1 second to check for updates. A delay of 1 second does not matter much for the game, since it is based on turn-based mode, but it also generates a lot of traffic. Is it possible when many players play? I heard about some COMET technology, but it seems that if the server has to write a lot in a line, I still have to send requests every time this technology is not yet installed.

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

3.1) Cool because it allows full duplex communication between clients and server + provides all the interesting features of java EE. It can later be expanded to a browser through the servlet interface.

3.2) It seems to be a bit of a reevaluation. Is it really so people? I mean, is that even the right way? Can any sane developer do that?

I would like you to help me with the choice, please. I do not have much experience working with such work. And I would like to adhere to best practices.

+4
source share
1 answer

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

The Building @MessageDriven Bean "adapter", which handles incoming socket connections in the onMessage method, is easy to develop, and from there you are in the world of EE scaling.

You, your business, can even rely on UDP. See the following example: http://www.apprigger.com/2011/06/javaee-udp-resource-adapter-example/

But, from my point of view, there are other important reasons. Some pointers:

1.) As you already mentioned. Creating your own Socket server to handle streams and requests is a lot of work, and in the end you can create your own "application server".

2.) Do not be afraid to use the application server. Of course, people tend to call such a platform "overhead." Although, when I measured the amount of time to call other services or ebbs, using local interfaces cost less than 10 microseconds per call. The presence of their own pools of threads and workers and their processing can be faster, although not close to 0 microseconds; -)

3.) With AS, you can easily customize the boundaries of your instances. More importantly, you can scale the application much easier than home-made software. Imagine a cluster running on servers with two servers (and you will if your MMO is successful). The network loadbalancer works for all types of architectures, although it has the ability to share information about the session (perhaps not for connecting gamers, although why not for entering user sessions), or managing entities over cluster nodes is simply "free" in the EE package.

All of these tools and EE templates give you time to develop a game instead of a framework; -)

+2
source

Source: https://habr.com/ru/post/1485695/


All Articles