¿Cuál es el mejor protocolo para usar para la implementación de IOT: MQTT, CoAP, XMPP, SOAP, UPnP?

Para enmarcar mi respuesta: si tiene un servicio humano o basado en la nube en su sistema, ¿está seguro de que es el IoT? Porque, estoy viendo algunas de las otras respuestas y diciendo “acabas de describir Internet, así que no estás respondiendo la pregunta”.

UPnP y SOAP se basan en XML, que no es en tiempo real, lo que significa que no se debe usar en un entorno IoT.

El resto tienen problemas similares. MQTT, XMPP requieren un intermediario (al igual que la semántica de almacenamiento directo). CoAP es cliente-servidor, lo que nuevamente significa que requiere un intermediario (llamado Servidor, pero no discutamos la semántica). Los corredores no son deterministas, como lo es TCP (CoAP usa UDP, por lo que es menos no determinista que los demás … claro, es posible que no obtenga sus datos, pero si no lo hace, al menos sabe -cuando se suponía para conseguirlo).

Su lista no incluye DDS. DDS es un estándar de interoperabilidad de datos en tiempo real controlado por el OMG (organismo de estándares para UML, etc.). DDS utiliza UDP (u otras capas de transporte) y proporciona su propio protocolo QoS de confiabilidad, por lo que obtiene transmisiones confiables sobre transportes inherentemente poco confiables (radios, UDP, etc.).

DDS hará lo que necesita en un entorno IoT (ya sea que tenga humanos o servicios en la nube).

PERO: tiene una curva de aprendizaje significativamente más alta (me gusta llamarlo una curva de aprendizaje). Debe comprender las interfaces de datos (IDL), la calidad del servicio (DDS tiene> 20 configuraciones diferentes de QoS, cada una con sus propias configuraciones secundarias), la programación distribuida en tiempo real del sistema de sistemas, en resumen: traiga su juego, o te hará llorar.

En el lado positivo, es un estándar abierto, determinista *, anónimo, publicación / suscripción de igual a igual con descubrimiento automático y comportamiento definido para cuando no se pueden cumplir los contratos de QoS, o cuando se violan los contratos de QoS.

* dependiendo de la implementación. También dependiendo de la implementación, puede ejecutarse en 16, 32 y 64 bits, pequeño o big endian, Intel, PPC, Arm, C, C ++, Java, Lua, Python, Ada, y todos son independientes de los demás. Puede tener un dispositivo Ada / PPC de 32 bits que se comunica con un servidor Java / Arm de 64 bits en cuestión de minutos, suponiendo que sepa lo que está haciendo y suponiendo que incluso pueden “verse” entre sí en un transporte común.

Una vez que comience a rehacer sus datos en la nube (lo que solo necesitaría hacer para conocer el estado o cuando se le ocurran estrategias para el mantenimiento predictivo, por ejemplo), simplemente use una transacción RESTful, ya que ya no le preocupa tiempo real. También puede usar DDS aquí, pero significa ajustar la QoS para agregar una dirección IP no local y habilitar TCP como transporte, que aún no forma parte del estándar de interoperabilidad (solo UDP está predefinido en el estándar , las implementaciones son específicas del proveedor cuando se trata de transportes de memoria compartida, TCP, serie, radio, etc.

No existe el mejor protocolo en IoT, todo depende del caso de uso. Como IoT es un campo muy vasto que cubre todo, el tipo de protocolos a utilizar también está muy diversificado. Básicamente hay tres tipos de conexiones.

1. D2D (Dispositivo a dispositivo)
2. D2S (Dispositivo a servicio)
3. S2S (Servicio a Servicio)

Así que vamos a diferenciar entre los protocolos que ha mencionado.

• MQTT: un protocolo para recopilar datos del dispositivo y comunicarlo a los servidores (D2S)
• CoAP: un protocolo de transporte de documentos como HTPP pero para entorno de restricción (D2S).
• XMPP: un protocolo mejor para conectar dispositivos a personas, un caso especial de
  Patrón D2S, ya que las personas están conectadas a los servidores
• JABÓN: no es una opción muy popular en IoT.
• DDS: un bus rápido para integrar máquinas inteligentes (D2D)
• AMQP: un sistema de colas diseñado para conectar servidores entre sí (S2S) se puede usar también en casos D2S pero es un poco pesado y complicado.

Ahora, como ve diferentes capas, el caso de uso y las propiedades de cada protocolo son diferentes. Los criterios para elegir deben ser el direccionamiento, la calidad del servicio y la aplicación como “en tiempo real” no pueden ser el único parámetro a tener en cuenta al seleccionar un protocolo.

Frugal Labs ha presentado una capacitación avanzada sobre protocolos.

Curso avanzado de IoT | Protocolos de IoT

Sugeriría ir a REST sobre HTTP / HTTPS. Las razones son

• Es un mecanismo predeterminado de comunicación web. Por lo tanto, obtiene todos los recursos, servidores y controladores del lado del cliente que lo admiten. Para otros, tendrá que desarrollar piezas de ecosistema por su cuenta
• El costo de la comunicación se ha reducido significativamente, por lo que los gastos generales asociados a HTTP no son realmente una preocupación
• Obtiene Transport Layer Security [TLS] a través de HTTPS. Otros protocolos todavía están trabajando en un canal seguro.

El siguiente a tener en cuenta es MQTT. Veo una buena adopción y un desarrollo general del ecosistema que admite este protocolo. Algunas de las ventajas de esto son:

• Utiliza un submodelo de pub que se adapta perfectamente para construir soluciones IoT escalables.
• Puede admitir la comunicación en ambos sentidos, ya que mantiene una conexión de socket TCP subyacente. Para lograr esto en HTTP, necesitaría websockets o mantener su propio mecanismo de socket TCP que puede ser problemático.

Cubrimos esto y más en nuestro bootcamp IoT. Quizás quieras ver nuestro sitio

Gracias

Manish

Co Fundador – Axelta

Hemos realizado un par de proyectos IOT de extremo a extremo. En los proyectos iniciales usamos http para enviar paquetes de información desde el dispositivo a la nube. Funcionó bien
Pero fuera de lo normal, comenzamos a usar MQTT para los proyectos recientes en los que estamos involucrados ( eso involucra tanto módulos GSM y Wi-Fi como características para enviar información a la nube ). MQTT parece ser la mejor opción ya que proporciona más seguridad, confiabilidad y está hecho especialmente para la comunicación de máquina a máquina. Es un protocolo ligero de mensajes de publicación / suscripción originalmente para aplicaciones de sensores, pero también muy útil en entornos móviles debido al bajo consumo de energía, la simplicidad de la API y el pequeño ancho de banda utilizado

XMPP es el mejor en general. MQTT en sí contiene muchas fallas de protocolo, presentando muchas vulnerabilidades, como facilitar la inyección y la inhalación no autorizadas. El uso de contraseñas de texto sin cifrar es muy problemático y no se resuelve simplemente mediante el cifrado, ya que todo el software necesita almacenar contraseñas, en lugar de hashes de contraseña para la autenticación. La falta de tipo de contenido y las identidades reenviadas dificultan la toma de buenas decisiones de seguridad. Para superar todas estas vulnerabilidades, se pone mucha responsabilidad en cada implementación y en las soluciones patentadas / a medida. Si bien esto podría estar bien en redes cerradas donde controlas a cada actor / participante (M2M), es muy problemático para soluciones IoT abiertas e interoperables. Su falta de federación hace que sea muy difícil crear cualquier tipo de red troncal interoperable global basada en MQTT.

XMPP para IoT, por otro lado, se centra en ayudar a cada implementación con seguridad e interoperabilidad. Los servicios de seguridad proporcionados incluyen identidades globales, autenticación SASL, autorización, delegación de confianza y aprovisionamiento. Dado que XMPP está federado, proporciona un gran mecanismo para crear una red troncal global interoperable pero segura para el IoT.

Otra diferencia clave entre los dos es el soporte para patrones de comunicación. MQTT solo admite una versión simple del patrón Publicar suscripción. XMPP, por otro lado, admite una amplia gama de patrones de comunicación, que incluyen mensajes asíncronos, solicitud / respuesta, multidifusión, publicación, suscripción, eventos, etc.

En algunas plataformas de desarrollo IOT gratuitas, se utiliza el protocolo REST Learn REST: A Tutorial. Se prefiere principalmente debido a su simplicidad y facilidad de codificación

MQTT está encapsulado con REST, para facilitar la interfaz

ejemplo: la plataforma de desarrollo de aplicaciones de Internet de las cosas usa API REST

Puede ser un comentario trivial, pero desde la capa de servicio de IoT y las funciones comunes en varios dominios de UC de IoT (casos de uso), para poder presentar una comunicación de estándar abierto de IoT de extremo a extremo, también podría ser útil para enumerar el protocolo “LwM2M”, que en el nivel de protocolo es en realidad CoAP con arquitectura REST y nivel de seguridad de DTLS 3. De esta manera, con la utilización de LwM2M, también hay soporte implícito para las API de IoT de OMA.

También debe tener en cuenta los sensores IOT que no utilizarán una pila TCP / IP.

MQTT para redes de sensores (MQTT-SN) está dirigido a dispositivos integrados en redes que no son TCP / IP, mientras que MQTT espera explícitamente una pila TCP / IP.

Referencia:

MQTT