Mantener las conexiones TCP activas para rastrear qué clientes están en línea

En cuanto a mi comprensión de TCP, afirmar "Mantener conexiones TCP vivas" es engañoso, ya que no hay un mecanismo específico del protocolo TCP que maneje el tiempo de espera, cuando se refiere a conexiones ESTABLECIDAS. Es decir: una vez establecidas, pueden durar para siempre, hasta que ocurra un RESET, un FIN o un tiempo de espera al recibir un ACK (...siguiendo alguna transmisión que debe ser ACKnowledged, en este último caso).

En cuanto a mi experiencia, el 100% de los problemas del tipo "repentinamente interrumpidos debido al tiempo de espera inactivo", dependen de algún enrutador/firewall intermedio, a lo largo de la ruta de enrutamiento entre los dos hosts que se comunican. Es decir: como el firewall típicamente es un firewall "stateful", lleva un registro de las conexiones que está firewallando/administrando. Como tal, cada conexión que necesita rastrear significa cierto grado de recursos del sistema (del firewall, me refiero) que se consumen. Además, el firewall sabe perfectamente cuáles de las conexiones administradas están "funcionando" y cuáles, al contrario, están "inactivas", debido a la naturaleza misma del firewall (¡es un firewall stateful!). Como tal, muchas (¿todas?) las implementaciones de firewalls tienen un tiempo de espera definido y si las conexiones administradas están inactivas durante dicho valor de tiempo, el firewall envía un reset a ambos extremos (...de la conexión TCP) y libera sus propios recursos.

Basándome en tu pregunta, apuesto a que la conexión TCP será abierta por tu dispositivo IoT (actuando como cliente) frente a tu servidor de control (el servidor TCP). Por lo tanto... MUCHOS, si no TODOS, de los routers ADSL domésticos que realizarán NAT al tráfico de tu dispositivo IoT, seguramente actuarán como se describe.

Esto, al menos, basado en mi propia experiencia.

Pero como no soy Jon Postel, por favor no me culpes si me equivoco :-)

Como nota al margen: escribiste "...MUCHOS dispositivos IoT simples...". Ten en cuenta que hay un límite muy estricto en el número de conexiones TCP concurrentes que puedes manejar con tu único servidor grande, ya que... el "puerto" TCP es un valor de 16 bits. Por lo tanto, para cada dirección IP, no puedes exceder (por diseño intrínseco de TCP) las 64K conexiones. Cómo se pueden resolver estos problemas, está fuera del alcance de esta pregunta.

Finalmente, permíteme agregar que realmente no veo ningún problema en implementar una especie de protocolo de latido entre tu dispositivo IoT y el servidor/aplicación de gestión. Puede implementarse de forma muy "amigable con la red", sin impacto en términos de ancho de banda y con muchos beneficios, en términos de manejabilidad/control.

Tu idea es buena; de hecho, los dispositivos móviles modernos utilizan el mismo enfoque para sus notificaciones, mantienen una conexión permanente con el servidor del desarrollador del sistema operativo y ese servidor envía notificaciones a través de esa conexión (los desarrolladores de aplicaciones de terceros envían notificaciones al desarrollador del SO que a su vez las envía al dispositivo móvil correspondiente).

Un método alternativo se puede utilizar si tus dispositivos tienen garantizada una IP públicamente enrutada y pueden escuchar en un socket; en ese caso, los dispositivos notificarán a tu servidor cada vez que su IP cambie, pero cada vez que tu servidor necesite entregar datos al dispositivo, se conectará al socket del dispositivo y le enviará los datos. De esta manera, tu servidor no tendrá que manejar ninguna carga más que actualizar la dirección IP de cada dispositivo en su base de datos y conectarse ocasionalmente a un dispositivo para enviarle datos.

Sobre TCP vs UDP, creo que TCP es mejor para garantizar la accesibilidad de un dispositivo - con TCP, mientras la conexión esté abierta, tienes cierta garantía de que el dispositivo aún está ahí (de lo contrario, la conexión habría expirado). Con UDP, estás simplemente lanzando paquetes al aire sin siquiera saber si llegaron a su destino (a menos que implementes tu propio sistema de keep-alive, administración de conexiones y retransmisión, pero ¿por qué reinventar la rueda cuando ya tienes una implementación sólida y popular llamada TCP?). También debes pensar en los firewalls y NAT, con TCP una vez que se establece la conexión estás seguro de que lo que envíes llega al destino, mientras que con UDP no puedes estar tan seguro y debes abrir agujeros con diferentes grados de éxito.