1. Introdução
2. Como surgiu
3.Paradigma Publish-subscribe
4. Como funciona
5. Como usar o protocolo
6. Aplicações MQTT
7. Qualidade de Serviço
8. Vantagens do MQTT
9. Conclusões
10. Bibliografia
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 o tópico 3. Entretanto, dando uma breve explicação, este paradigma é diferente do paradigma Request-Response, e funciona através de “inscrições” realizadas por um dos atores em um certo tópico. Dessa forma, ele recebe os dados referentes a esse tópico, não necessitando dar request sempre que quiser uma informação.
2. 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.
3. Paradigma 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, apenas precisam conhecer o Broker que fará a notificação da mudança de estados para aqueles que tiverem inscritos para receber informação do 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.
4. Como funciona
4.1. Atores do sistema MQTT
Existem 2 atores numa comunicação MQTT:
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.
Sobre o Cliente, ele possui duas áreas de atuação sobre a informação: Postagem e Recebimento, o publish e o 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.
4.2. Relação Cliente x Broker
Mas como funciona esse Broker? Como funciona o recebimento e transmissão de dados pelo servidor? Todas as informações são organizadas em um formato hierárquico, focando nos 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. 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á os dados armazenados no broker referentes à umidade do solo 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 qualquer informação de pra quem esses dados devem ser mandados, já que é um trabalho do Broker.
4.3. 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.
4.4. Tipos de Mensagens
Tenta criar uma conexão com o Broker e espera até que a conexão seja estabelecida, começando a escutar as mensagens publicadas.
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.
Retorna a informação que foi enviada pelo cliente MQTT.
4.5. Casos Específicos
Caso aconteça do Broker receber uma informação referente a um tópico, mas esse tópico não possui nenhum subscriber, essa 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.
(fonte: https://en.wikipedia.org/wiki/MQTT)
5. Como usar o Protocolo
6. Aplicações MQTT
7. Qualidade de Serviço
8. Vantagens do MQTT
Em relação às vantagens duas 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.
9. 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.
10. Bibliografia
