Cómo túnel de datos multi-jugador del juego a través de HTTP con IIS para minimizar la latencia?

Question

Me gustaría crear un juego de red basado en un navegador. Para asegurarse de que puede ser utilizado por tantas personas como sea posible, me gustaría integrar todo el tráfico en paquetes HTTP estándar.

Suponiendo que utilizo mi IIS como parte final, ¿cómo debería codificar esta para minimizar la latencia?

¿Es razonable comenzar con una aplicación ASP de algún tipo (ASP.NET MVC tal vez) con el estado en la memoria compartida? O debería planificar desde el principio en la escritura de algún tipo de complemento IIS de mi propia? O debería abandonar IIS y escribir un servidor personalizado en su lugar?

¿Es razonable para iniciar la consulta con cada cliente en varias ocasiones, por ejemplo diez veces por segundo, o debería hacer que los datos más corriente similar de alguna manera (y si es así cómo)?

Answer 1

Esto puede funcionar bien, pero vas a tener que hacer algo menos "convencional".

Para realizar este trabajo, no hacen peticiones individuales, mantener la solicitud de apertura y luego transmitir datos con la conexión abierta.

Se podría tratar de usar un protocolo como Bayeux , pero no hay reglas aquí.

He aquí un ejemplo con ASP.NET utilizando COMET .

Answer 2

El diseño de una aplicación para golpear un servidor web 10 veces por segundo no es una buena idea. Los servidores web están diseñados para las solicitudes de clientes de menos frecuentes, y los tiempos de procesamiento, probablemente, más grandes y tamaños RÉPONSE que su juego va a utilizar. Eso no quiere decir que un servidor web no sería capaz de hacer frente sólo que no sería un partido eficaz cliente-servidor.

Para cualquier tipo de aplicación que requiere múltiples paquetes por segundo que realmente debe pensar en un protocolo más ligero que el HTTP, que es bastante detallado. Por ejemplo, si el juego tiene que enviar 4 bytes para registrar acorazado coordenadas de un usuario que realmente no desea transmitir un extra de unos pocos cientos de bytes de las cabeceras HTTP.

Me gustaría recomendar una tecnología plug-in de navegador como Siverlight de flash. Tanto de los que soportan conexiones de socket TCP. Lo que se necesita para escribir su propio servidor para sentarse en el otro extremo del socket TCP. Con ese enfoque también tendría la ventaja de ser capaz de pasar los datos a los clientes sin tener que depender de mecanismos de votación cliente que se requieren con HTTP, por ejemplo AJAX.

Answer 3

Uno de los problemas que se enfrentará con mensajes HTTP estándar es el tamaño (y la falta de control) sobre los datos de cabecera.

Yo estaba involucrado en el diseño de un juego flash que fue interpretado por varios millones de personas. Necesitábamos para comunicarse con el servidor cada pocos segundos y terminamos utilizando mensajes JSON ultra ligeros para ahorrar ancho de banda y mantenerlo ágil.

Tamaño del mensaje JSON: 16 bytes

Tamaño de encabezado HTTP: más de 200 bytes

HTTP no es realmente un buen protocolo para el alto tráfico, requisitos de baja latencia. Fue diseñado para solicitar menos frecuente modelos más grandes, / respuesta y tiene códigos de estado como 304 Not Modified por esta misma razón.

Es probable que desea bajar a un TCP personalizado / IP aplicación.