Dando uma breve análise no protocolo MQTT
O MQTT é um protocolo de mensagens (camada de aplicação) projetado para um baixo consumo de banda de rede e recursos de hardware, desenvolvido pela IBM e Eurotech na década de 90. O padrão utilizado é o publish/subscriber: quando um elemento da rede deseja receber uma determinada informação, é feita a subscrição para um outro elemento na rede (ex: servedouro, gateway…) capaz de gerir as publicações e subscrições — este elemento fica conhecido como broker. Da mesma forma, os nós que desejam publicar novas informações, o fazem por intermédio do broker.
Resumo do que é MQTT:
O principio de funcionamento do protocolo parte da utilização de um Servidor MQTT, também conhecido como Broker MQTT. Tal Servidor implementa estruturas de armazenamento de dados, referenciadas como tópicos. Cada tópico refere-se a uma estrutura de publicação (publisher) de dados, mas também possibilita a leitura (subscriber) dos dados [1].
Um dos fatores mais importantes do protocolo MQTT são os tópicos, que identifica todas as mensagens. O conceito é parecido com o de URI, com níveis separados por barras: os elementos da rede enviam diversos tópicos ara o broker, e os subscribers escolhem quais os tópicos que querem subscrever. Vamos imaginar uma aplicação, em que se deseja monitorar as condições ambientais de um datacenter. Para isso temos das áreas de sensores: sensores de umidade e de temperatura, que nesse caso serão os nossos ‘publishers”. As informações coletadas serão armazenadas no Broker sob os tópicos “/umidade” e “/temperatura”. Um terceiro nó, provavelmente pertencente a área de NOC da empresa, gostaria de ter essas informações, e portanto faz um subscriber para esses tópicos, como na imagem abaixo:
Ainda em cima do exemplo acima, imaginemos que no datacenter há duas áreas (ex: 10 e 20), com diferentes sensores (5000, 5001, 4000, 4001) e que um departamento da empresa quer saber informações de temperatura da área 10. Um exemplo de mensagens trocadas, tanto dos publishers, quanto dos subscribers seriam os seguintes
O MQTT possui uma estrutura de pacotes de controle própria, que basicamente é constituída de três partes principais: Cabeçalho fixo, cabeçalho variável e o payload.
Cabeçalho fixo — composto de ao menos [3] 2 bytes, possui 4 bits (posição byte 1, bits 7–4) designados para definir o tipo do pacote de controle, 3 bits para flags (posição byte 1, bits 3–0) e um byte adicional para suportar bits adicionais do cabeçalho variável e payload.
Principais tipos de pacotes: CONNECT (requisição de conexão ao servidor), PUBLISH (publicação de mensagem), SUBSCRIBE (subscrição)
Flags: atualmente a maior parte dos parâmetros de flag (CONNECT, CONNACK..) encontram-se reservados para usos futuros. Apenas o tipo PUBLISH possi funções próprias e possui definições para entrega DUP, qualidade de serviço QoS e opções de retenção RETAIN.
Cabeçalho variável — nem todos os tipos de mensagem MQTT possuem um cabeçalho variável, que basicamente trás informações da identificação do pacote. Os tipos de pacotes de controle que usam identificadores são PUBLISH se QoS > 0), SUBSCRIBE, UNSUBSCRIBE e todos os derivados de confirmação (PUBACK, SUBACK, UNSUBACK, PUBREC..). Possui um tamanho de até 2 bytes.
Payload — inclui a mensagem como um todo (normalmente os tópicos). Os pacotes de confirmação (CONNACK, PUBACK, SUBACK…) não necessitam de um payload.
I) Como se compara ao CoAP?
Uma das grandes diferenças entre as arquiteturas pensados sobre CoAP e MQTT está em relação a forma como é feito o acoplamento/conexão entre elementos produtores e consumidores, estes podem ser divididos em três dimensões [4]:
· Acoplamento de espaço — indica a referência (identidade, localização) que os produtores possuem dos consumidores. O MQTT é altamente desacoplado do espaço, uma vez que os sensores que produzem os dados não necessitam conhecer a identidade dos clientes que estão interessados naquela informação. Enquanto que no CoAP é o contrario, o consumidor entre em contato direto com o produtor, o que exige a identificação de ambas as partes;
· Acoplamento de tempo — indica o nível de interação em tempo real entre as partes. No MQTT, os produtores podem publicar mesmo que os consumidores estejam desconectados e, inversamente, os cosumidores podem ser notificados mesmo que não haja produtores. Enquanto que no CoAP a informação só fica disponível enquanto o produtor estiver disponível, e a interação entre os nós precisa ser ao mesmo tempo.
· Acoplamento de sincronização — indica o nível de sincronismo da realização de atividades em relação a outras. No MQTT, os produtores não são bloqueados enquanto produzem eventos e consumidores podem ser assincronamente notificados da ocorrência de um evento enquanto efetuam outra atividade, o que é exatamente oposto ao que ocorre no CoAP.
No trabalho do Denis [4] foram feitas simulações dos protocolos utilizam um Broker Eclipse e serviços na nuvem (Amazon) com os dois protocolos, e nas considerações finais do trabalho, foram observados os seguintes itens:
· O CoAP é mais eficiente quando falamos em uso da banda (50% menos tráfego do que o MQTT) e mais confiável (não deixou de entregar nenhum dos pacotes);
· O MQTT é melhor para qualidade de serviço — possui opções de QoS 2 (exactly send once) que o CoAP não oferece
· Ambos foram mais eficientes nas simulações do que o protocolo HTTP;
Ainda que existam diferenças, os protocolos podem ser usados em conjunto, com componentes brokers “poliglotas” e, por exemplo, produtores utilizando MQTT para publicar dados e consumidores utilizando CoAP — os clients só precisam saber a identificação do broker.
Ficou bem curioso com o protocolo e quer aprender mais para por a mão na massa? Dê uma olhada nesse vídeo (e em outros do canal Infortrônica para zumbis) para conhecer um pouco mais
REFERÊNCIAS
[1] Fiware Lab SP. “Apresentação do protocolo MQTT como alternativa para comunicação IoT”. Julho, 2016. Disponível em <http://fiwarelabsp.org/2016/07/apresentacao-do-protocolo-mqtt/ >
[2] Marcelo Barros. “MQTT — Protocolos para IoT”. Embarcados, junho de 2015. Disponível em < https://www.embarcados.com.br/mqtt-protocolos-para-iot/ >
[3] Oasis Standard. “MQTT Version 3.1.1”. Outubro, 2014. Disponível em < http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.pdf >.
[4] Denis Storti. “Comparação de Protocolos de Comunicação CoAP, MQTT e HTTP utilizando Eclipse Ponte e Amazon Web Services”. Monografia USP, São Paulo 2016. Disponível em < https://pt.slideshare.net/DenisStortidaSilva/monografiaawsprotocolosiotdenisstortiv11 >
