Escenario
Dispositivo IoT (actualmente dispositivo IPv4) que envía a través del socket TCP una carga útil a un servidor una vez al día. El servidor tiene una dirección IP pública, el dispositivo está detrás de un enrutador / NAT. Voy a usar un módulo basado en ESP8266 (es decir, Olimex uno)
Objetivo
El servidor debe poder enviar datos a cualquier cliente cuando sea necesario. No estoy interesado en la comunicación directa de cliente a cliente (es decir, conectarme a un dispositivo desde mi teléfono inteligente) como se supone que debe hacer la perforación.
Otros requisitos
Los dispositivos IoT pueden crecer hasta varios miles. Su conexión a Internet es proporcionada por muchos enrutadores / módems con capacidad 4G. Cada uno manejará 10-20 clientes.
Solución propuesta
Hasta donde yo entiendo, una solución común es MQTT. Los clientes envían periódicamente datos al agente (es decir, Mosquitto que se ejecuta en el servidor de alojamiento), que a su vez actualiza la aplicación web principal que se ejecuta en el mismo servidor.
Pregunta
¿El enfoque MQTT es adecuado para un "gran" número de dispositivos (más de 1000) la mayoría de ellos detrás de un enrutador 4G?
Respuestas:
1,000 clientes pueden ser manejados fácilmente por cualquier agente decente de MQTT; hay un punto de referencia de Scalagent que muestra que una PC con:
podría manejar a 60,000 editores con Mosquitto. Esto es muy superior a los 1,000 publicadores requeridos, por lo que incluso en un servidor relativamente débil, aún debería poder manejar el número requerido.
Algunos otros corredores afirman un rendimiento aún mejor (con una potencia de servidor correspondientemente mayor, por supuesto), como HiveMQ , que afirmó manejar 10 millones de editores.
Los corredores MQTT generalmente esperan una conexión persistente, y agotarán el tiempo de espera de los clientes que no envían respuestas de ping (u otra actividad) periódicamente. Puede desconectarse de la red después de la publicación, pero, obviamente, no podrá recibir nada si se desconecta.
MQTT admite el concepto de mensajes 'retenidos' que podrían ser útiles. El cliente web puede publicar algo en un tema con el indicador retenido, y el intermediario almacenará este mensaje. Cada vez que sus clientes se vuelvan a conectar y se suscriban al tema, recibirán el mensaje retenido (incluso si fue publicado hace horas). El mensaje retenido se publica cada vez que un cliente se suscribe a ese tema, por lo que podría ayudarlo si tiene una conexión irregular y necesita que se almacene un mensaje hasta que el cliente se vuelva a conectar.
fuente
Puede usar sesiones persistentes de los clientes, por ejemplo, el indicador limpio establecido en falso al conectarse. En ese caso, cuando su cliente está fuera de línea, el agente lo almacenará en su propia memoria caché y lo entregará una vez que el dispositivo se conecte.
Sobre la cantidad: 10K es una cantidad relativamente baja incluso para un servidor. Puede configurar el servidor Linux para mantener 500K conexiones activas y si su agente estará basado en la nube, por ejemplo, proporcionado como servicio por algún proveedor, puede mantener incluso millones de conexiones activas.
Por cierto, creo que Mosquitto o cualquier otra instalación local es la opción perfecta para el desarrollo y las pruebas, pero cuando entre en producción necesita el agente SaaS MQTT con todas las características como HA, redundancia, conmutación por error, etc.
fuente