Embora seja justo dizer que o XML é detalhado, isso deve ser moderado com a consciência de que essa verbosidade não é toda "sobrecarga" em relação ao conteúdo, uma vez que encapsula a semântica; é uma sobrecarga sintomática de qualquer protocolo que enfatize uma dinâmica em oposição à estrutura estática. Por exemplo, o HTML é realmente uma forma relaxada de XML que transmite conteúdo com uma estrutura dinâmica, estrutura que pode ser considerada um aspecto do conteúdo. Você pode distinguir o conteúdo de uma tabela da própria tabela, mas o fato de o conteúdo ser dados tabulares com relações específicas é essencial para o conteúdo; se eu pegasse cada célula e transmitisse tudo como uma cadeia longa, essa estrutura e esses relacionamentos desapareceriam, e então eu perdi informações e esse conteúdo não é?
Vamos considerar uma mensagem de 8 bytes que possa constituir alguns dados de tabela. Se eu usar um protocolo muito estático, eu poderia, no mínimo, transmitir isso sem sobrecarga adicional simplesmente definindo um protocolo como este:
- Cada mensagem tem exatamente 8 bytes, portanto, não precisamos indicar o comprimento ou incluir nenhuma sequência final.
- Os oito bytes são sempre usados para se referir a uma grade 2 x 2, em que cada célula contém um valor de 16 bits.
Se todas as minhas mensagens são exatamente assim, o uso de XML, HTML ou XMPP pode ser considerado bobo - estou desperdiçando largura de banda em componentes estruturais que são sempre os mesmos e predeterminados de qualquer maneira, e desperdiçando o tempo de computação correspondente nas duas extremidades, criando e analisando-o. Uma página HTML mínima e adequada que contenha apenas uma tabela 2 x 2 com alguns caracteres em cada célula provavelmente terá pelo menos 100 bytes para acomodar a sobrecarga de formatação e protocolo.
No entanto, se nem todas as minhas mensagens forem exatamente isso, especificar o tipo de mensagem que pode não ser uma parte literal da "carga útil", mas é um componente necessário em termos de conteúdo. Eu poderia fazer isso com apenas dois bytes extras e introduzir muito mais dinamismo:
- As mensagens agora têm comprimento variável, 0 a 255 bytes e o primeiro byte indica o comprimento.
- Existem (até) 256 códigos para diferentes tipos de mensagens predefinidos, um dos quais é "tabela 2 x 2", que é o segundo byte.
Agora, meus 8 bytes de conteúdo da tabela exigem 2 bytes de sobrecarga, mas há uma gama muito maior de possibilidades em termos de que tipos de mensagens podem ser enviadas com esse protocolo personalizado.
Ainda não está nem perto das possibilidades de uma página HTML ou especificação de namespace XML (ou conjunto dela, que é essencialmente o XMPP ).
Portanto, com base nisso, se você está enviando mensagens simples de 8 bytes, o XMPP provavelmente é um exagero. No entanto, não necessariamente tanto assim. A alegação de que "uma única troca de solicitação / resposta para enviar um byte de dados de um DISPOSITIVO IOT CONNECTED para o servidor é superior a 0,5 kB" parece-me, olhando para a RFC relevante , um exagero em potencial (mas nb, tudo Eu fiz é olhar para ele, eu nunca implementei ou usei XMPP). Não duvido que você possa construir um exemplo disso, mas esse provavelmente não é um exemplo mínimo .
Como o protocolo é orientado para TCP, o estabelecimento de "um fluxo XML qualificado pelo namespace 'jabber: client'" só precisa ser considerado parte da mensagem se estivermos fazendo uma coisa única - o dispositivo entra em contato com um servidor para enviar 8 bytes, envia os dados, desconecta. Se o relacionamento for mais persistente, o que normalmente ocorreria em um contexto de IoT, podemos assumir que o dispositivo já possui uma conexão estabelecida com o destino. Nesse caso, se o destino final da mensagem for o servidor (em oposição a outro cliente para o qual o servidor passará a mensagem), a sobrecarga do protocolo será potencialmente mínima.
<message><body>8 bytes.</body></message>
Um mísero 33 bytes de "overhead". Vale ressaltar aqui que XML é texto e, portanto, se suas mensagens são frequentemente binárias, isso se tornará muito menos apropriado, porque esses dados precisam ser codificados (por exemplo, para base64 ), o que adiciona mais sobrecarga e computação. requisitos.
Então, finalmente:
O XMPP possui uma grande sobrecarga para dispositivos de IoT que enviam mensagens curtas e frequentes?
Se houver uma conexão persistente e as mensagens não forem estruturadas, acho que não. No entanto, se você não precisa do que ele oferece (o dinamismo em relação à estrutura), provavelmente existem metodologias mais apropriadas.
Em busca disso, se tivermos um contexto em que um único servidor central está processando e / ou confiando mensagens entre uma variedade de dispositivos, mesmo que o que qualquer um desses dispositivos esteja fazendo possa ser sempre simples e direto, um protocolo que pode encapsular um uma variedade de mensagens ainda seria útil. Se um dispositivo cliente tiver recursos limitados, podemos codificar grande parte do protocolo, e agrupar cada mensagem com esse objetivo se tornará uma tarefa muito simples; Acredito que muitos dispositivos de IoT que implantam servidores HTTP fazem isso (que é o inverso de "clientes simples, servidor complexo"). Esses servidores não podem lidar com nenhum tipo de solicitação HTTP (exceto por rejeição pré-formatada) e têm um conjunto muito bem definido e focado de coisas que as coisas farão e respostas que eles enviarão, mas, como funcionam corretamente como servidores HTTP,