MQTT

MQTT(Message Queuing Telemetry Transport) é um protocolo de comunicação máquina para máquina (M2M - Machine to Machine) com foco em Internet of Things (IoT) que funciona em cima do protocolo TCP/IP. Um sistema MQTT se baseia na comunicação entre cliente e servidor, em que o primeiro pode realizar tanto “postagens” quanto “captação” de informação e o segundo administra os dados a serem recebidos e enviados. Para isso, é utilizado um Paradigma chamado Publish-Subscribe, que será melhor explicado nos próximos tópicos. O protocolo se popularizou pela simplicidade, baixo consumo de dados e pela possibilidade comunicação bilateral.

Como Surgiu

Nos anos 90 a IBM criou o protocolo MQTT. Sua origem se deu à necessidade de um protocolo simples e leve que conseguisse comunicar várias máquinas entre si, uma comunicação que ocorreria utilizando microcontroladores para a obtenção de dados que tivesse uma taxa de transmissão leve para a comunicação entre as máquinas e os sensores.

Devido à tão importante funcionalidade de “criar uma conexão” entre pequenos sensores e as máquinas onde esses dados serão tratados, o MQTT é visto como uma das principais tecnologias que podem tanto participar quanto impulsionar o desenvolvimento de uma nova “rede”, a chamada Internet das Coisas (IoT), que já está mostrando sua importância há muito tempo e, com certeza, ganhará ainda mais foco nos próximos anos.

Publish-subscribe

Para entendermos o padrão Publish-Subscribe, iremos compará-lo com os padrões Request-Response e Observer.

No padrão Request-Response nós possuímos dois atores: Cliente e Servidor. Nesse protocolo o servidor fica o tempo todo ouvindo requisições que podem chegar dos seus cliente, porém ele estabelece uma conexão apenas temporária com o servidor, a medida que for realizando as requisições e obtendo as respostas, após isso a conexão é quebrada e o cliente não será notificado de nenhuma modificação.

No padrão Observer possuímos dois atores principais: os observadores (observer) e o sujeito (subject). Os observadores irão realizar uma requisição para se inscrever no subject e dessa forma ser notificado quando houver alguma mudança de estado, o sujeito irá possuir uma lista dos seus observadores para que ele saiba para quem enviar as notificações quando houver a mudança de estado. Caso não seja mais interessante ao sujeito enviar informações para um observador específico ou o observador não se interessa mais pelo estado do sujeito, a inscrição pode ser desfeita.

O Padrão Publish-Subscribe é muito parecido com o padrão Observe, porém nesse caso adicionamos o papel do Broker, que é responsável por filtrar as mensagens e saber exatamente para quem enviar. Dessa forma, o publisher e subscriber não precisam se conhecer diretamente e apenas precisam conhecer o Broker, que é quem fará a notificação da mudança de estados e enviará essa informação para aqueles que tiverem inscritos no tópico referenciado. Por fim, o publish precisa se preocupar apenas com enviar as informações e estabelecer a conexão exclusivamente com o Broker.

É comum em alguns casos os sistemas terem atuações tanto de Publisher quanto de Subscriber. Considerando um caso de sistema que possui um sensor de temperatura e está ligado a um ar-condicionado e um sistema que acompanha a temperatura e envia o sinal para ligar o ar, os dois terão as duas situações, considerando que o sistema 1 precisa publicar as mudanças de temperatura e receber o sinal para ligar o ar, enquanto o sistema 2 precisa receber as informações da temperatura e enviar o sinal para ligar o ar.

Como funciona

• Atores do Sistema

  • Broker

  O Broker é o servidor intermediário da informação. É ele quem recebe os dados enviados pelos sensores e é nele onde esses dados são tratados e passados adiante. Podem existir mais de um broker em um sistema, que vão compartilhar os dados recebidos entre si baseado nos clientes que possuem e nos dados requisitados por eles.

  • Cliente

  O Cliente possui duas áreas de atuação sobre a informação: Postagem e Recebimento, "publish" e "subscriber", respectivamente. Ele pode escolher em qual área atuar, sendo possível trabalhar na Postagem, no Recebimento ou nos dois ao mesmo tempo. Mas independente de qual caso ele escolha, sempre será necessária a presença de um Broker para realizar a intermediação dos dados entre todos os clientes.

• Relação Cliente x Broker

Todas as informações recebidas pelo Broker e passadas adiante são organizadas em um formato hierárquico, de acordo com seus tópicos. Isso significa que um dado captado e enviado para o broker fará parte de apenas 1 tópico, enquanto um outro dado diferente fará parte de um outro tópico, e assim por diante. Um exemplo que podemos dar é o seguinte:

“Foram posicionados dois sensores numa plantação. Um deles é utilizado para medir a umidade do solo enquanto que o outro mede a temperatura local. Ambos estão conectados a um servidor para onde enviarão os dados captados a cada 30 minutos.”

Nesse exemplo ambos os sensores são publishers, ou seja, enviam seus dados para um broker que realiza o armazenamento e controle desses dados. Entretanto, eles não serão armazenados no mesmo local (sob o mesmo tópico). Os dados referentes à temperatura local serão guardados em um tópico “Temperatura”, por exemplo, enquanto que os dados referentes à umidade do solo serão guardados em um tópico “Umidade”. Além desses 2 clientes, também teremos outros clientes, agora subscribers. Esses serão, por exemplo, Raspberry Pis conectados ao sistema de irrigação do local. O raspberry receberá, do broker, os dados referentes à umidade do solo e temperatura do local e realizará sua tarefa.

Quanto a esse “receber os dados do broker”, é exatamente isso. Não é o cliente quem pede ao servidor pelos dados. Como ele já está listado em um devido tópico, o broker sabe que deve mandar esses novos dados para esse receptor, excluindo a necessidade de uma requisição. E além desse benefício, esse método também permite que clientes publishers não necessitem saber para quem esses dados devem ser mandados, já que é um trabalho do Broker.

• Transmissão de Dados

  O protocolo MQTT utiliza outro protocolo chamado TCP para a transmissão de dados. Além do TCP, também é usado o MQTT-SN, que é usado para outros tipos de transporte como UDP ou Bluetooth.

• Header

  O Header do MQTT pode variar de 2 a 5 bytes. Em relação ao primeiro byte obrigatório, os 4 primeiros bits referem-se ao tipo de mensagem, o bit seguinte refere-se ao indicador de mensagem duplicada, dois bits para identificar o QoS(qualidade de serviço) do pacote e bit para indicar de se a mensagem deve ser retida ou não para quando alguém se conectar receber a última mensagem enviada. Os próximos 4 bytes irão definir o tamanho do resto do pacote, podendo ir de 0 a 268 435 455 bits. O restante são informações que podem variar e não existe um padrão.



Tipos de mensagens

Primeiramente iremos falar dos 3 principais tipos de mensagem e em seguida teremos uma tabela com todos os tipos de mensagens disponiveis no protocolo e repestivos valores que devem ser enviados no header para identificar a mensagem.

• • Connect

  Tenta criar uma conexão com o Broker e espera até que a conexão seja estabelecida, começando a escutar as mensagens publicadas.

  • Disconnect

  Espera que até o cliente terminar alguma ação que esteja realizado e finaliza a conexão TCP/IP, parando assim de escutar as mensagens que serão publicadas.

  • Publish

  Retorna a informação que foi enviada pelo cliente MQTT.





Tabela de mensagens

Valor	Nome	Direção	Descrição
0	Reservado	Proibido	Reservado
1	CONNECT	Cliente para Servidor	Requisição do cliente para conectar ao servidor
2	CONNACK	Servidor para Cliente	Reconhecimento da conexão
3	PUBLISH	Cliente para Servidor ou Servidor para cliente	Publicar mensagem
4	PUBACK	Cliente para Servidor ou Servidor para cliente	Reconhecimento da publicação
5	PUBREC	Publicação recebida	Publicação recebida(parte 2 do QoS=1)
6	PUBREL	Cliente para Servidor ou Servidor para cliente	Publicação lançada(parte 2 do QoS=2)
7	PUBCOMP	Cliente para Servidor ou Servidor para cliente	Publicação completa(parte 3 do QoS=2)
8	SUBSCRIBE	Cliente para Servidor	Pedido de inscrição
9	SUBACK	Servidor para cliente	Reconhcimento de inscrição
10	UNSUBSCRIBE	Cliente para Servidor	Pedido de desinsção
11	UNSUBACK	Servidor para cliente	Reconhecimento desinscrição
12	PINGREQ	Requisição	Requisição PING
13	PINGRESP	Servidor para cliente	Resposta PING
14	DISCONNECTy	Cliente para Servidor	Cliente esta desconectado
15	Reservado	Proibido	Reservado





• Casos Específicos

  Caso um tópico não possua nenhum subscriber e o Broker receber uma informação referente a este tópico, tal informação será deletada. Isso só não acontecerá caso seja especificado pelo publisher que tal dado deve ser armazenado, o que é uma prática muito usada, pois permite que os subscribers possam ter a informação mais atualizada sem ter que esperar o publisher enviar a nova informação.

  Um outro caso é quando um publisher se conecta pela primeira vez a um Broker. Durante essa primeira conexão ele tem a oportunidade de definir uma mensagem padrão que será enviada aos subscribers caso o Broker perceba que esse publisher se desconectou dele.

Como usar o protocolo MQTT

Assim como já foi comentado, o protocolo MQTT é principalmente utilizado em aplicações de IoT, devido a sua simplicidade e facilidade de implementação. Além de aplicações de IoT, alguns usos muito comuns são para a obetenção de dados em tempo real.

Podemos citar o exemplo apresentado no tópico acima "Como funciona", onde o protocolo MQTT é utilizado para se obter informações da temperatura e nível de umidade do solo. Caso o solo esteja pouco úmido e a temperatura esteja alta, por exemplo, o sistema de irrigação será ativado.

Os usos desse protocolo depende apenas da criatividade do desenvolvedor. Podem ser criados sistemas de controle de mercadorias, automação de processos, controle de fluxo de pessoas, controle para eficiência energética, entre muitos outros.

Como começar a usar o protocolo MQTT

Atualmente existem inúmeras implementações tanto para brokers como para clientes MQTT em diversas linguagens, tais como Python, JavaScript, C#, entre outros. Podemos encontrar facilmente várias dessas implementações na internet, sendo boa parte delas open source e de fácil acesso e download pelo público.

Uma dessas implementações é o broker Mosquitto. Sendo um dos brokers mais utilizados atualmente devido à sua simplicidade e facilidade de implementação, esta tecnologia open source ganhou um grande espaço no mercado de IoT por estar intimamente relacionado com o protocolo MQTT.

Nós utilizaremos o Mosquitto para exemplificar alguns métodos e mostraremos também como instalá-lo e como começar a implementá-lo em uma aplicação real. Caso você tenha interesse em outros exemplos de Brokers, listaremos ao final algumas opções que podem ser utilizadas.

O "Mosquitto" pode ser facilmente baixado para vários sistemas operacionais. Os arquivos de download podem ser encontrados na página oficial do broker, na aba de downloads. Ao baixar o broker escolhido, este vai ser utilizado para rodar o servidor onde o sistema e o relacionamento entre os clientes e o broker será hospedado.

A partir deste momento já é possível testar seu broker. Este teste pode ser realizado pelo próprio prompt de comando do computador, onde podem ser feitas as inscrições de clientes em certos tópicos. Ao mesmo tempo, caso você já possua uma aplicação web é possível relacioná-la ao seu broker (ao seu servidor), adicionando a aplicação tanto como um cliente subscriber como um cliente publisher.

Como já foi citado anteriormente, vários sistemas podem ser utilizados como clientes deste protocolo. Podemos utilizar sensores, que pegariam alguns dados do ambiente e os enviariam pro broker, por exemplo. Podemos usar um RaspberryPi, que pegaria esses dados do broker - que foram enviados pelos sensores - para controlar alguma máquina. Também podemos ter um sistema, como foi apontado acima, que usaria esses mesmos dados enviados ao broker pelos sensores, mas com um objetivo que pode ser diferente ou não do RaspberryPi.

Outros tipos de Brokers

• Brokers

Qualidade de serviço

No protocolo MQTT nós temos 3 qualidades de serviço(QoS) e cada conexão com o broker pode especificar qual será utilizada., sendo estas: "no máximo uma vez", "no mínimo uma vez" e "exatamente uma vez".

• QoS 0 - No máximo uma vez

Conhecido como fire and forgot (atirar e esquecer), nesse QoS a mensagem é enviada apenas uma vez e não haverá passos seguintes, dessa forma a mensagem não será armazenada, nem haverá um feedback para saber se ela chegou ao destinatário.

Esse modo de transferência é o mais rápido, porém o menos seguro já que a mensagem será perdida caso o envio falhe ou o cliente esteja desconectado.



• QoS 1 - Pelo menos uma vez

Nesse modo de transferência, a mensagem é entregue pelo menos uma vez, havendo uma espera da recepção de feedback da entrega da mensagem, o chamado PUBACK. Não recebendo o PUBACK, a mensagem continuará sendo enviado até que haja o feedback. Nesse QoS pode acontecer da mensagem ser enviada diversas vezes e ser processada diversas vezes.

Para que haja o envio da mensagem mais de uma vez, a mensagem precisa ser armazenada. Ela será excluída do receptor após ter recebido o feedback de confirmação do envio.



• QoS 2 - Exatamente uma vez

Nesse modo de transferência, a mensagem é entregue exatamente uma vez, necessitando que a mensagem seja armazenada localmente no emissor e no receptor até que seja processada. Para garantir a segurança desse QoS é necessário o envio de 2 pares de request-response(chamado de four-part handshake), onde temos o envio da mensagem(PUBLISH), a resposta de recepção(PUBREC), o aviso do recebimento do PUBREC(PUBREL) e a confirmação de que o processo foi concluído e pode ser feita a exclusão(PUBCOMP). Após o recebimento do PUBREL, o receiver pode excluir a mensagem e ao sender receber o PUBCOMP ele poderá excluir a mensagem.

Vantagens

Em relação às vantagens, três ficam muito claras, o baixo consumo de memória, baixa necessidade de processamento para o envio de mensagem e baixo consumo de banda. Como o publisher não envia a informação direto para os subscribers, ele não precisa guardar a informação de todos os seus subscritores e nem precisa fazer várias envios de informação(uma para cada subscriber).

Apenas é necessário que ele realize um envio de informação para o broker com a informação que ele quer que seja enviada daquele tópico, dessa forma o processamento realizado e o consumo de memória do Publisher pode ser reduzido. Além disso, o header de uma mensagem no protocolo MQTT é muito menor do que um Header no protocolo HTTP, o que economiza muito o consumo de banda.

Perguntas

Quais as vantagens do MQTT sobre o HTTP?

As vantagens são: baixo consumo de memória, a baixa necessidade de processamento para o envio de mensagem e o baixo consumo de banda. A primeira referente a necessidade de armazenar apenas a informação dos brokers que estão conectados e os tópicos e ao envio de pacotes pequenos, considerando que o mqtt possui um header mais enxuto.

Explique o paradigma Publish-subscribe.

Nesse paradigma possuímos três papéis, o broker, o publisher e o subscriber. Nesse paradigma o Publisher enviará mensagens referentes a tópicos, o subscribe irá assinar tópicos para receber mensagens sobre ele e o Broker receberá as mensagens dos publishers e será responsável em enviar as mensagens para os subscribers que tenham interesse nesse assunto específico.

Explique o papel do Broker, dos clientes subscribers e dos clientes publishers.

O Broker é um intermediador entre os clientes do protocolo. É ele quem vai receber as informações de um cliente publisher e vai enviar essa informação aos clientes subscribers inscritos no tópico referente àquela informação. O Cliente Publisher é aquele que capta uma informação e a envia ao broker. Um exemplo seria um sensor, que envia os dados captados (como temperatura), ao broker que, por sua vez, enviará esse dado aos clientes subscribers. Cliente Subscriber é o cliente que recebe uma informação do broker. Ele deve se inscrever em tópicos definidos pelo broker, cada um sobre uma certa informação, que por sua vez foi captada por um cliente publisher. Vale dizer que o cliente pode ser, ao mesmo tempo, publisher e subscriber, ou seja, enviar e consumir dados ao/do broker.

Quais são as QoS (qualidade de serviço) disponíveis no protocolo e como são caracterizadas?

São 3 qualidades de serviço. Sendo o QoS=0, envio de mensagem pelo no máximo uma vez, QoS=1,envio de mensagem pelo menos uma vez e QoS=2, envio de mensagem exatamente uma vez.

Qual o tamanho do header fixo do MQTT?

2 bytes

Conclusões

O MQTT se mostra um ótimo protocolo para ser utilizado em serviços que não precisam de muita informação sendo enviada e não precisam de um histórico sendo guardado das modificações. Por ser fácil de implementar e por enviar informações pequenas, se mostra uma ótima opção dentro do mercado de IoT, já que não é necessário muita banda nem muito processamento para que a comunicação ocorra. Dessa forma, conseguimos ter um bom resultado em situações em que precisamos de soluções de baixo custo e em situação com conexões não muito boas. Hoje em dia com Brokers gratuitos e a facilidade de implementar esse tipo de conexão, fica ainda mais fácil de testar esse tipo de serviço e implementar em projetos.

No geral o MQTT mostra uma vantagem clara em relação ao HTTP, porém em algumas situações será encontrando um gargalo em relação ao MQTT. Considerando que a conexão dos clientes ao broker são conexões contínuas, que não são fechadas até o cliente se desconectar, podem haver situações onde temos várias conexões abertas em paralelo no mesmo roteador e devido às limitações desse roteador, podemos observar um congestionamento da rede, algo que não aconteceria com o HTTP já que as conexões são abertas apenas para verificar se houve uma modificação e logo em seguida é fechada, evitando assim que muitas conexões permaneçam abertas simultaneamente.

No geral saber qual é o melhor protocolo a ser usado é uma decisão de projeto que varia para cada situação, cada protocolo tem suas vantagens e desvantagens, assim recomendamos que seja avaliada a situação de acordo com os gargalos que podem ser apresentados utilizando cada tipo de protocolo e os custos referentes a utilização e aquele que obtiver os melhores dados seja escolhido.

Bibliografia

• Conhecendo o MQTT. IBM. Disponível em: https://www.ibm.com/developerworks/br/library/iot-mqtt-why-good-for-iot/index.html . Acesso em: 31 mai. 2019.
• MQTT Essentials: Part 1 – Introducing MQTT. HIVEMQ. Disponível em: https://www.hivemq.com/blog/mqtt-essentials-part-1-introducing-mqtt/ . Acesso em: 08 mai. 2019.
• MQTT Version 3.1.1. OASIS. Disponível em: http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html . Acesso em: 08 mai. 2019.
• MQTT Version 5.0. OASIS. Disponível em: https://docs.oasis-open.org/mqtt/mqtt/v5.0/mqtt-v5.0.html . Acesso em: 08 mai. 2019.
• Publisher-Subscriber pattern. MICROSOFT. Disponível em: https://docs.microsoft.com/en-us/azure/architecture/patterns/publisher-subscriber . Acesso em: 08 mai. 2019.
• Qualidades de serviço fornecidas por um cliente MQTT. IBM. Disponível em: https://www.ibm.com/support/knowledgecenter/pt-br/SSFKSJ_8.0.0/com.ibm.mq.dev.doc/q029090_.htm . Acesso em: 08 mai. 2019.
• MQTT Essentials Part 6: Quality of Service 0, 1 & 2. HIVEMQ. Disponível em: https://www.hivemq.com/blog/mqtt-essentials-part-6-mqtt-quality-of-service-levels/ . Acesso em: 08 mai. 2019.
• The Observer Pattern. O'REILLY. Disponível em: https://www.oreilly.com/library/view/learning-javascript-design/9781449334840/ch09s05.html . Acesso em: 08 mai. 2019.
• Pub/Sub Messaging. Amazon. Disponível em: https://aws.amazon.com/pub-sub-messaging/ . Acesso em: 08 mai. 2019.
• MQTT community. MQTT Community Wiki. Disponível em: https://github.com/mqtt/mqtt.github.io/wiki . Acesso em: 04 jun. 2019.