Estoy escribiendo un servidor de juegos para un juego por turnos en Java. Estos son los hechos:Qué protocolo elegir para un servidor de juegos por turnos
- La velocidad del juego es lento, por lo que los clientes necesitan para enviar datos digamos que cada 8 segundos, y que los datos es que la mayoría de las veces sólo una pequeña actualización incremental (algunas decenas de bytes), aparte de situaciones como unirse al juego o enumerar juegos disponibles, etc.
- El servidor debe admitir una gran cantidad de jugadores que, digamos 1000, que jueguen uno de los cientos de juegos
- Cuando el jugador da vuelta , otros jugadores en el mismo juego deben ser notificados del movimiento. La cantidad máxima de jugadores en el juego es de alrededor de 10
En primer lugar, excluí UDP de mi lista de opciones porque necesito un protocolo confiable porque en raras ocasiones necesito enviar algunos datos que no caben en uno paquete y no quiero molestarme con la fusión de paquetes y cosas similares, el seguimiento del orden de los paquetes recibidos y otras cosas de bajo nivel.
Entonces el dilema es si usar TCP o HTTP.
intento TCP # 1
La conexión desde el cliente al servidor (y viceversa) se abre todo el tiempo. De esta manera, cuando un jugador hace un movimiento, el servidor puede notificar fácilmente a otros jugadores en el juego que se realizó el movimiento. Lo principal que me molesta con este enfoque es si es aconsejable o incluso posible tener hasta 1000 conexiones y tomas de corriente abiertas todo el tiempo.
intento TCP # 2
la alternativa que pensé es decir, a utilizar para establecer una conexión separada/hembra en cada petición de un cliente. Un cliente abriría una conexión, enviaría algunos datos pequeños al servidor y cerraría esa conexión. Con este enfoque, puedo tener un grupo de subprocesos de tamaño fijo de digamos 10 y procesar las solicitudes del cliente en cada subproceso por separado para que haya, como máximo, 10 connectinos/sockets abiertos en cualquier momento. Pero hay dos cosas que me molestan con este enfoque:
- elevado coste de abrir/cerrar la conexión con el cliente
- la forma de notificar a otros jugadores en el juego, ya que la conexión con ellos es más probable cerrada . Cada uno de ellos debería en ese caso "sondear" el servidor para la actualización, digamos cada segundo.
¿Cuál es el costo de establecer un socket/conexión TCP? ¿Es esta una operación costosa o esto se hace solo en unos pocos ms (o menos)?
HTTP
- Habría un montón de gastos generales si que sería el envío de un nuevo GET/POST sólo para enviar unos pocos bytes?
- ¿Puedo mantener 1000 conexiones HTTP a clientes simultáneamente y luego usar AJAX o cosas similares para reducir sobrecarga?En ese caso, ¿tendría 1000 conexiones simultáneas un problema significativo con respecto al ancho de banda ?
Estoy abierto a sugerencias/consejos de cualquier tipo.
sobre # 2: Usted tiene que autenticar al jugador cada vez que se establece la conexión ... Este proceso puede ser lento, así !? – opatut
¿Están el cliente y el servidor escritos en Java? – Kylotan
Hay varios clientes, uno de los cuales está en Java, pero estoy buscando una solución general. – eold