Si bien es justo decir que XML es detallado, eso debería atenuarse con la conciencia de que esta verbosidad no está "sobrecargada" en relación con el contenido, ya que encapsula la semántica; su sobrecarga es sintomática de cualquier protocolo que enfatiza una estructura dinámica en lugar de estática. Por ejemplo, HTML es realmente una forma relajada de XML que transmite contenido con una estructura dinámica, estructura que podría considerarse un aspecto del contenido. Puede distinguir el contenido de una tabla de la tabla en sí, pero el hecho de que el contenido sean datos tabulares con relaciones específicas es parte integral del contenido; Si solo tomé cada celda y la transmití como una cadena larga, esa estructura y esas relaciones se han ido, y entonces he perdido información y ¿no es ese contenido?
Consideremos un mensaje de 8 bytes que podría constituir algunos datos tabulares. Si uso un protocolo muy estático, podría, como mínimo, transmitirlo sin sobrecarga adicional simplemente definiendo un protocolo como este:
- Cada mensaje tiene exactamente 8 bytes, por lo que no necesitamos indicar la longitud ni incluir ninguna secuencia de terminación.
- Los ocho bytes siempre se toman para referirse a una cuadrícula de 2 x 2 donde cada celda contiene un valor de 16 bits.
Si todos mis mensajes son exactamente así, usar XML, HTML o XMPP podría considerarse una tontería: estoy desperdiciando el ancho de banda en componentes estructurales que siempre son iguales y predeterminados de todos modos, y desperdiciando el tiempo de cálculo correspondiente en ambos extremos para crearlo y analizarlo. Una página HTML adecuada y mínima que contenga solo una tabla de 2 x 2 con un par de caracteres en cada celda probablemente tendrá al menos 100 bytes para acomodar el formato y la sobrecarga del protocolo.
Sin embargo, si no todos mis mensajes son exactamente eso, entonces especificar qué tipo de mensaje es no puede ser una parte literal de la "carga útil", pero es un componente necesario, en cuanto al contenido. Podría hacerlo con solo dos bytes adicionales e introducir mucho más dinamismo:
- Los mensajes ahora son de longitud variable, 0-255 bytes, y el primer byte indica la longitud.
- Hay (hasta) 256 códigos para diferentes tipos de mensajes predefinidos, uno de los cuales es "tabla 2 x 2", ese es el segundo byte.
Ahora mis 8 bytes de contenido de tabla requieren 2 bytes de sobrecarga, pero hay un rango mucho más amplio de posibilidades en términos de qué tipo de mensajes se pueden enviar con este protocolo personalizado.
Todavía no está cerca de las posibilidades de una página HTML o una especificación de espacio de nombres XML (o conjunto de ellas, que es lo que XMPP es esencialmente ).
Entonces, en base a eso, si principalmente lo que está haciendo es enviar mensajes simples de 8 bytes, XMPP probablemente sea excesivo. Sin embargo, no necesariamente tanto. La afirmación de que "un solo intercambio de solicitud / respuesta para enviar un byte de datos de un DISPOSITIVO CONECTADO IOT al servidor es más de 0.5 kB" me parece, mirando al RFC relevante , una exageración potencial (pero no, todos Lo que hice fue echarle un vistazo, nunca he implementado o usado XMPP). No dudo que pueda construir un ejemplo de eso, pero probablemente no sea un ejemplo mínimo .
Dado que el protocolo está orientado a TCP, el establecimiento de "una secuencia XML calificada por el espacio de nombres 'jabber: client'" solo debe considerarse parte del mensaje si estamos haciendo una sola cosa: el dispositivo contacta a un servidor para enviar 8 bytes, envía los datos, se desconecta. Si la relación es más persistente, lo que a menudo sería en un contexto de IoT, entonces podemos suponer que el dispositivo ya tiene una conexión establecida con el destino. En este caso, si el destino final del mensaje es el servidor (a diferencia de otro cliente al que el servidor va a transmitir el mensaje), la sobrecarga del protocolo es potencialmente mínima.
<message><body>8 bytes.</body></message>
Un mísero 33 bytes de "gastos generales". Vale la pena señalar aquí que XML es texto, por lo que si sus mensajes son a menudo binarios, será mucho menos apropiado, ya que esos datos deben codificarse (por ejemplo, en base64 ), lo que agrega más gastos generales y computacionales. requisitos
Entonces, en última instancia:
¿XMPP tiene una gran sobrecarga para los dispositivos IoT que envían mensajes cortos y frecuentes?
Si hay una conexión persistente y los mensajes están en gran parte desestructurados, no lo creo. Sin embargo, si no necesita lo que ofrece (el dinamismo con respecto a la estructura), entonces probablemente haya metodologías más apropiadas.
Busque eso, si tenemos un contexto en el que un único servidor central está procesando y / o confiando mensajes entre una variedad de dispositivos, a pesar de que lo que esté haciendo cualquiera de esos dispositivos puede ser siempre simple y directo, un protocolo que puede encapsular un variedad de mensajes aún sería útil. Si un dispositivo cliente tiene recursos limitados, podemos codificar gran parte del protocolo, y ajustar cada mensaje desde ese extremo se convierte en una tarea muy simple; Creo que muchos dispositivos IoT que implementan servidores HTTP hacen eso (que es lo contrario de "clientes simples, servidor complejo"). Esos servidores no pueden manejar ningún tipo de solicitud HTTP (excepto a través del rechazo preformateado) y tienen un conjunto muy bien definido y enfocado de cosas que las cosas harán y las respuestas que enviarán, pero como no obstante funcionan correctamente como servidores HTTP,