¿Cuáles son los pros y los contras de los protocolos MQTT versus STOMP como IoT (Internet de las cosas)?

Los siguientes factores deciden encontrar los protocolos adecuados:

Escalado, seguridad, interoperabilidad, ancho de banda.

MQTT es ligero. Es muy rápido. Funciona bien incluso si no tiene suficiente ancho de banda como dial-ups y anchos de banda lentos. Facebook utiliza MQTT.

Las fortalezas de MQTT son la simplicidad (solo cinco métodos API), una carga útil de paquetes binarios compactos (sin propiedades de mensaje, encabezados comprimidos, mucho menos detallada que algo basado en texto como HTTP), y se adapta bien a escenarios simples de mensajes push como la temperatura actualizaciones, cotizaciones de precios de acciones, alimentación de presión de aceite o notificaciones móviles. También es muy útil para conectar máquinas entre sí, como conectar un dispositivo Arduino a un servicio web con MQTT.

El protocolo STOMP es simple y basado en texto y es muy similar a HTTP bajo el capó y puede conectarse a un agente STOMP incluso con Telnet.

STOMP , sin embargo, no trata colas y temas, sino que utiliza una semántica ENVIAR con una cadena de “destino”. El corredor debe mapear algo que entienda internamente, como un tema, una cola o un intercambio. Los consumidores se SUSCRIBEN a esos destinos. Dado que esos destinos no son obligatorios en la especificación, los diferentes corredores pueden admitir diferentes sabores de destino. Por lo tanto, no siempre es sencillo portar código entre corredores.

Ambos son protocolos de mensajería basados ​​en TCP / IP y ambos protocolos son compatibles con RabbitMQ. Pero, MQTT es el mejor protocolo adecuado para IoT.

Respuesta similar en comparación con M. Anon I. Ratón. No te molestes con STOMP, no es un protocolo IoT.

STOMP tiene los mismos problemas que tiene con XML y JSON RESTful sobre HTTPS: está optimizado para la legibilidad humana, el análisis tolerante a fallas y / o los datos autodescritos.

No es de ninguna manera eficiente en el cable, pero la eficiencia en el cable no era uno de sus objetivos de diseño. Cualquier cosa que sea de baja potencia, que funcione con batería, “SWAP” restringido no considerará STOMP.

Abajo, en el borde, debe mirar MQTT, COaP u OMG-DDS (el conjunto de características con limitaciones de micro o recursos). Dentro de la puerta de enlace (hubs <-> gateway) mire DDS o MQTT completo. Encima de la puerta de enlace (puerta de enlace <-> nube) mire DDS (sin HMI) o RESTful / HTTPS (HMI).

Cada vez que formatee shift (MQTT -> DDS, DDS -> RESTful, por ejemplo) necesitará un puente y esos usarán recursos.

El problema con los middlewares orientados a mensajes, como STOMP, es que la estructura y el formato del mensaje están definidos por una aplicación, lo que obliga al editor y al suscriptor a estar a la par. Si cambia uno, debe cambiar el otro.

El middleware orientado a datos como DDS promueve la estructura de los datos, convirtiéndolo en una entidad en el sistema. Puede cambiar cualquier editor, o cualquier suscriptor, en cualquier momento, individualmente, sin molestar a los otros puntos finales, porque el formato de datos (el idioma y la gramática en el cable) son fijos.