La mejor manera de enviar datos a un cliente sin ser bloqueado por un firewall

Consideraciones universales

Es común que la mayoría de los firewalls y cajas NAT permitan que un servidor responda a la máquina que envió un paquete desde el interior. Cualquier otra cosa es un caso extremo o un comportamiento insano. Por lo tanto, si un cliente del juego puede iniciar una conexión con usted, podemos asumir que puede responderle en ese canal. El objetivo entonces es mantener viva la conexión. Tanto con TCP como con UDP, las casillas NAT eventualmente agotarán el tiempo de espera de la aplicación si no se envía nada.

UDP

Simple y directo, la mayoría de los enrutadores NAT permitirán que los paquetes UDP vuelvan al host que los envió. En los juegos en tiempo real, este es el protocolo normal, por lo que la reordenación de cuadros no se realiza en paquetes descartados. El juego y su servidor son responsables de sincronizar sus estados desde dentro del protocolo. Espere que la conexión sea olvidada después de un minuto de silencio. Los cuadros DD-WRT tienen un valor predeterminado de 2 minutos.

TCP

La sobrecarga de mantener las conexiones ordenadas se desplaza del juego al sistema. Los paquetes llegan a la aplicación en orden, aunque esto puede crear algunos retrasos no deseados cuando los paquetes se caen o llegan a la computadora fuera de orden. Al menos por RFC, las cajas NAT deben mantener abierta una conexión TCP establecida durante al menos dos horas antes de olvidarlas. Siendo realistas, cuentan con no más de 5 minutos. Los enrutadores DD-WRT, por ejemplo, se olvidan en 10.

No envías paquetes de la nada; Tienes que saber quién es el cliente y dónde está. Entonces, el modelo normal es el siguiente: cada cliente abre una conexión TCP al servidor. La conexión se queda allí. Cuando el servidor tiene algo que decir al cliente, simplemente lo escribe en la conexión correspondiente.

Una conexión inactiva no implica ningún paquete. En realidad, desea enviar algunos paquetes de vez en cuando, porque algunos enrutadores / cortafuegos tienden a anular las conexiones que han estado inactivas durante demasiado tiempo (con "demasiado tiempo" a veces tan corto como "cinco minutos" ").

En algunas redes, se rechazan las conexiones TCP externas, y toda la actividad de la red debe pasar por un proxy bajo el protocolo HTTP (he visto que en algunas redes empresariales, exactamente la situación en la que se solicitan reglas de firewall especiales para jugar). un juego puede ser algo mal visto. La solución habitual es utilizar HTTPS (es decir, SSL), porque entonces el proxy funcionará como un reenviador TCP bidireccional genérico (con el comando de proxy CONNECT ). Si eso también está bloqueado, tendrá que recurrir a trampas, como enviar una solicitud HTTP falsa, y hacer que el servidor envíe una respuesta "ilimitada" (una respuesta sin un encabezado de 'Contenido-Longitud' explícita) por trozos pequeños. Consulte esta publicación del blog para una discusión.

RESPUESTA RÁPIDA:

El problema general para los enrutadores domésticos, o firewalls, es que permiten conexiones externas y no permiten entradas internas.

Cada marca / modelo tiene generalmente las mismas capacidades para permitir una derivación o un mapeo de puertos hacia adentro. Pero, el método exacto (GUI, configuración) puede ser bastante diferente (y por lo tanto complejo).

Sin duda, sería más seguro que los clientes se conecten (al servidor). Pero para seguir enviando principalmente (desde servidor ), puede hacer que cliente primero establezca una conexión externa y luego escuche los paquetes que se encuentran en esa ruta.

La respuesta breve es que va a necesitar que el cliente se comporte como un cliente, es decir, inicie la conexión para los datos 'enviados'.

Como usted dice, las conexiones UDP y TCP iniciadas en el extremo del "servidor" no cruzarán la mayoría de los firewalls y no cruzarán la mayoría de los enrutadores NAT.

De hecho, incluso con el socket iniciado en el extremo del usuario, obtendrá la mejor cobertura al usar el puerto 80, por lo que debería considerar al menos cometa

(Sin embargo, IME, la mayoría de los MORPG confían en que el usuario permita explícitamente las conexiones entrantes).

Este es uno de los problemas que websockets intentan resolver.

En ambas arquitecturas, se encontrará con graves problemas de escalabilidad al usar un modelo de servidor convencional con un subproceso / proceso por conexión. (vaya a leer en node.js).

No es sorprendente que node.js tenga muy buen soporte websocket.