2011-05-09 19 views
10

Estoy planeando crear un servidor Java que manejará las comunicaciones de juegos en tiempo real entre los clientes. ¿Cuál es el mejor tipo de implementación de Java que podría comunicarse de manera eficiente y, con suerte, con precisión entre un cliente y un servidor a altas velocidades (digamos 5-15 paquetes por segundo)? Sé que hay muchos tipos de API de redes Java (es decir, ObjectInputStream y ObjectOutputStream, DatagramPacket, KyroNet, etc.), pero no estoy seguro de cuál es la implementación más efectiva y/o comúnmente utilizada para ese escenario. Supongo que la mayoría de los juegos en tiempo real usan métodos de comunicación UDP, pero entiendo los problemas de confiabilidad que conlleva. ¿Hay implementaciones UDP que tengan algún tipo de control de flujo? De todos modos, gracias de antemano!¿Cuál es la implementación Java más eficiente para un servidor de juegos en tiempo real?

+1

15 paquetes de un segundo no es de alta velocidad. 100k paquetes/seg es – Erik

+0

Estaba leyendo un artículo de Valve sobre cómo crearon sus servidores de origen, dijeron que el suyo era en promedio 20-30 paquetes por segundo. Como en realidad estoy construyendo un juego de menor escala, no necesito tantos. Creo que 100.000 paquetes en un segundo tomarían bastante ancho de banda ¿no crees? – Brian

+0

¿Está perdiendo un paquete de importancia? Si no, entonces iría por UDP (DatagramPacket) con una suma de comprobación muy simple y descartar los paquetes defectuosos. Sin embargo, podría ser una buena idea establecer la conexión con TCP. – veiset

Respuesta

12

Algunas cosas a tener en cuenta:

  • Java NIO es realmente bueno, y puede manejar el tipo de rendimiento/latencia que busca. No utilice ninguno de los más antiguos frameworks de redes/serialización y API
  • Latencia es realmente importante. Básicamente, desea una capa mínima sobre NIO que le permita enviar mensajes individuales, rápidos, pequeños y con una sobrecarga mínima.
  • Según el juego, es posible que desee TCP o UDP o ambos. Utilizar TCP para mensajes importantes, UDP para los mensajes que no sean estrictamente necesarios para el juego para continuar o va a ser subsumido por una futura actualización (por ejemplo, cambios de posición en un FPS)
  • Algunas personas implementar su propio protocolo de mensajería TCP-como sobre UDP para juegos en tiempo real. Esto es probablemente más problemas de lo que vale, pero sea consciente de ello como una opción si realmente necesita para optimizar para un tipo específico de comunicación
  • Para los juegos en tiempo real, que está casi siempre haciendo serialización personalizada (por ejemplo, Sólo el envío de los deltas en lugar de actualizaciones completas de posiciones de objetos) - así que asegúrese de que su estructura permite esta

Teniendo en cuenta esto, se lo recomiendo uno de los siguientes

  • Kryonet - lightwieght, personalizable , Diseñado para este tipo de propósito
  • Netty - un poco más orientado a la empresa, pero muy capaz, robusta y escalable
  • Roll-su-propio basado en NIO - difícil pero posible si se desea un control de grano muy fino. He hecho esto antes, pero en retrospectiva probablemente debería haber elegido Kryonet o Netty

¡Buena suerte!

+1

btw sincronización entre UDP + TCP es difícil de descifrar, y puede ser una fuente seria de problemas de 'piratería' para el servidor. IMO, NIO personalizado no es tan difícil, pero creo que la pregunta no se habría hecho en el primer lugar. Saber cuándo usar los buffers directos también requiere experiencia, mi toma es un búfer directo por cliente y la capacidad del tamaño del búfer y búfer. – bestsss

+0

Muchas gracias, eso fue más que informativo. – Brian

+0

Solo una pregunta más, ¿cuál es la principal ventaja de usar la nueva API de NIO? Por supuesto, es más nuevo, por lo que es probablemente mejor, pero ¿qué diferencia hay en comparación con el uso tradicional de Sockets y ServerSockets? – Brian

Cuestiones relacionadas