Servidor Java de alta carga para multijugador

Question

Estoy haciendo un juego multijugador. Ahora estoy tratando de elegir la tecnología para conectar los dispositivos Android al servidor. Los clientes se ejecutan en Android, y el juego es MMORPG. Me gustaría escribir el servidor en Java. En este momento tengo solo 3 ideas para ello:

1) Creación de un entorno multithreading con java liso y sockets. De esta manera, será más fácil realizar una conexión dúplex completa entre el cliente del juego y el servidor. Pero tengo las siguientes preocupaciones:

1.1) El juego es MMORPG con una gran cantidad de objetos, y no estoy seguro de cómo se escalan dichas soluciones si hay, por ejemplo, 5000 personas jugando al mismo tiempo. ¿Cuántos hilos podré ejecutar en la máquina Java? ¿Cómo puedo calcular aproximadamente eso? En caso de que 1 hilo está leyendo para cada socket y 1 hilo está escribiendo en el zócalo (SO 2 THRENSOS PARA 1 JUGADOR).

1.2) Cuando crece el número de jugadores, ¿cómo podré escalar mi archivado jarra escrito para distribuir a través de varios servidores? Tal vez hay algún truco especial para hacer eso?

1.3) Una gran cantidad de programas de sobrecarga: las api son un nivel bastante bajo.

2) Creación de una interfaz de servlet para servir solicitudes HTTP.

2.1) Sesiones fáciles de controlar (y autorización) siempre que cada jugador tenga su propia sesión.

2.2) Puede conectarse a Java EE EJB o lo que sea: se quitan muchas complicaciones con la programación a nivel del sistema. Así que puedo concentrarme en escribir la lógica de negocios.

2.3) puede servir a todos los tipos de clientes con dispositivos HTTP - dispositivos móviles + navegadores.

2.4) Alta velocidad: incluso 1 contenedor de servillas puede servir a unos pocos miles de solicitudes por segundo, por lo que será realmente rápido.

2.4) Pero este enfoque no puede proporcionar una comunicación dúplex completa. Tendré que enviar solicitudes cada 1 segundo para verificar las actualizaciones. 1 segundo retraso no hace mucha diferencia para el juego, ya que se basa en el turno, pero aún así genera mucho tráfico. ¿Es factible cuando hay muchos jugadores jugando? Escuché sobre alguna tecnología de cometa, pero parece que si el servidor tiene que presionar muchos mensajes en la fila, todavía tendré que enviar solicitudes cada vez que esta tecnología aún no está bien establecida.

3) Creación de sockets y conectándolos a través de JMS al servidor Java EE.

3.1) Cool porque permite la comunicación dúplex completa entre los clientes y el servidor + proporciona todas las funciones geniales de Java EE. Más tarde se puede extender al navegador a través de la interfaz de Servlet.

3.2) Parece algún tipo de exceso de exceso. ¿Es realmente cómo la gente haría eso? Quiero decir, ¿es incluso la forma correcta? ¿Algún desarrollador sano lo hará así?

Me gustaría que me ayudes con la elección por favor. No tengo mucha experiencia con hacer algo de trabajo así. Y le gustaría seguir las mejores prácticas.

Answer 1

¿Por qué reescribir lo que puede bajar del estante?

¿Por qué no usarlo servidor de reddwarf (anteriormente Proyecto DarkStar )?

REDDWARF Server es una solución de middleware de código abierto para desarrollar el lado del servidor de los juegos en línea multijugador masivamente. Es la communante oficial de Project Darkstar, un proyecto de código abierto apoyado y administrado por Sun Microsystems. - de Artículo de Wikipedia de Reddwarf

El dominio de REDDWARF parece abajo hoy (2013-06-12), pero todavía hay una wiki , y son Migración a una github repo .

Reddward presenta su filosofía y objetivos como:

• Realice el código del juego del lado del servidor confiable, escalable, persistente y tolerante a fallas de una manera que sea transparente para el desarrollador del juego.
• Presente un simple modelo de programación impulsado por eventos de un solo hilo para el desarrollador. El desarrollador nunca debe tener su código de código debido a las interacciones entre el código que manejan diferentes eventos. (de la Tutorial de Reddwarf )

No es que esto no quiere decir que el código del servidor esté un solo roscado, pero que se abstrae de la perspectiva del desarrollador del juego. La Tutorial de RedDwarf proporciona mucha más información sobre lo que Reddwarf puede Hacer y aclarar muchas de sus decisiones de diseño.

Sin embargo,

un punto de preocupación por usted, sin embargo, fue que la capacidad de múltiples nodos no se implementó completamente la última vez que verifico (ca.11).

desde cero

Eso no debería evitar que intente hacer la mayoría de estas cosas desde cero, si vale la experiencia de aprendizaje. Sin embargo, este es un esfuerzo importante y lo consumirá bastante tiempo, y, como se señaló en su pregunta, algunas de estas cuestiones son bastante de bajo nivel en la pila de tecnología para tratar y aumentarán enormemente la complejidad del código que usted Tendremos que mantener.

Pero de todos modos, con respecto a sus 3 opciones, su primera vez me parece lo mejor para mí, si fuera para una implementación hecha en casa. La opción 2 (utilizando servlets HTTP) parece adaptarse solo para algunos juegos, aunque supongo que podría ser una alternativa relativamente decente para implementar algo usted mismo mientras sigue delegando a un middleware, y podría beneficiarse de muchas adiciones del servidor web para manejar la carga ( Módulos de caché, etc ...). La opción 3 (usando JMS + Jee) de hecho parece sobrecargada, pero es difícil saber con seguridad sin saber lo que tiene en mente.

Y si estás aquí para intentar aprender, entonces, obviamente, la opción 1 cubrirá mucho terreno. Pero va a ser una batalla bastante cuesta arriba.

Answer 2

1.1) you can't think in term of one Thread by user. Depending of machine configuration but you could load thousands of threads but it will not scale and lose a lot of time in Thread context switch. Better think NIO Netty like framework with few incoming and outcoming Thread pool executor that perform incoming messages under milli second execution.

1.2) You can simply scale by putting in front of you game server a loadbalancer component that can forward incoming player to right server according their load

1.3) NIO can handle thousands to to millions connection on a single box. Don't worry with this.

2.1) Manage your player sessions and 2.2) be away of EJB architecture. It will eat all your box power instead of allocating power to your game which is your goal.

2.3) HTTP can serve all clients but if you run realtime game i encourage to use binary socket and keep HTTP only for loadbalancing , login , stats and fallback when can't establish a socket connection.

2.4) Socket based server can handle hundred thousands incoming message per second. This is the property of low latency system

While it's very interesting to dive in building such system. What is your goal? Learn to build such system or succeed your game?

Many java multiplayer game server technology framework already exist. SmartFox Server, ElectroTank...

We have our own java high load Nuggeta multiplayer crossplatform java game server that addresses all points discussed above and much more. If you wanna try it it's free.

If your goal is to write a game server it's awesome venture that can takes long time but very exciting. If your goal is to succeed your game. Pick up among Java game server SDK already existing.