Introducing 

Prezi AI.

Your new presentation assistant.

Refine, enhance, and tailor your content, source relevant images, and edit visuals quicker than ever before.

Loading…
Transcript

Protocolo MQTT

Trabalho de Redes Industriais

Danielle Romano

Felipe Compan

Vitor Ardengue

O QUE É?

Protocolo MQTT

MQTT (Message Queuing Telemetry Transport):

  • 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.

  • Seu sistema se baseia na comunicação entre cliente e servidor, em que o cliente pode realizar tanto “postagens” quanto “captação” de informação e o servidor administra os dados a serem recebidos e enviados. Para isso, é utilizado um Paradigma chamado Publish-Subscribe.

  • O protocolo se popularizou pela sua simplicidade, baixo consumo de dados e pela possibilidade comunicação bilateral

  • O MQTT trabalha na camada de aplicação, a sétima camada do modelo OSI, a mesma do HTTP. A maior diferença entre ambos é o tamanho do payload.

Como Surgiu?

  • Criado nos anos 90 pela IBM, surgiu devido à necessidade de um protocolo simples e leve

que fosse capaz de comunicar várias máquinas entre si, utilizando-se microcontroladores para que fosse possível obtenção de dados com uma taxa de transmissão leve para a comunicação entre as máquinas e os sensores.

  • É 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

Publish-subscribe

Comparação com os padrões Request-Response e Observer:

  • 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 clientes, 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 Observer, 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. Por fim, o publisher 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.

Como funciona?

Atores do Sistema:

  • Broker: é o servidor intermediário da informação. Recebe os dados enviados pelos sensores, os trata e passa adiante. Podem existir mais de um broker em um sistema.
  • Cliente: possui duas áreas de atuação sobre a informação: Postagem e Recebimento, "publisher" e "subscriber", respectivamente.

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

3 principais tipos de 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

A mensagem contém um tópico e uma carga útil de dados. Em seguida, o broker encaminha a mensagem a todos os clientes que assinam esse tópico.

Tabela de

Mensagens

Caso Específico

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

Figura 5 - Exemplo de conexão MQTT com QoS-0 e flag de armazenamento da mensagem. Fonte: https://commons.wikimedia.org/wiki File:MQTT_protocol_example_without_QoS.svg

COMO USAR O PROTOCOLO

Como usar o protocolo MQTT

  • 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 obtenção de dados em tempo real.

  • Podemos citar o exemplo apresentado no tópico "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.

Tópicos

  • A identificação das mensagens no MQTT se dá através de tópicos (topics). O tópico lembra o conceito de URL, com níveis separados por barras (“/”). Elementos da rede podem enviar diversos tópicos para o broker e subscritores podem escolher os tópicos que desejam subscrever
  • Exemplo:

Tópicos

  • O valor da temperatura ou umidade faz parte dos dados da mensagem, sendo o formato algo dependente da aplicação, uma vez que o MQTT não impõe restrições sobre isso. Seria possível codificar a mensagem em json, ou mesmo enviar um valor binário de 16 bits para cada variável, entre outras formas.
  • Um subscritor pode receber especificamente um tópico desejado, porém pode ser mais interessante receber essas informações agrupadas, utilizando o “+” com função de aceitando qualquer valor naquele nível do tópico.

  • Existe também uma outra notação utilizando o símbolo “#”, que significa “qualquer coisa abaixo de determinado nível do tópico”.

Qualidade de serviço

Este protocolo possui 3 qualidades de serviço(QoS):

  • "No máximo uma vez"
  • "No mínimo uma vez"
  • "Exatamente uma vez".

Cada conexão com o broker pode especificar qual será utilizada

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.

  • É o modo de transferência 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

  • 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

  • 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

  • Baixo consumo de memória;
  • Baixa necessidade de processamento para o envio de mensagem;
  • 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ários 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 E RESPOSTAS

Perguntas

1. Em qual camada o MQTT trabalha?

2. Explique o paradigma Publish-subscribe.

3. Qual o tamanho do header fixo do MQTT?

4. Quais as QoS (qualidade de serviço) disponível no MQTT?

5. Quais as vantagens do MQTT?

Respostas

4. Quais as QoS (qualidade de serviço) disponível no MQTT?

  • QoS 0 - Envio de mensagem no máximo uma vez
  • QoS 1 - Envio de mensagem pelo menos uma vez
  • QoS 2 - Envio de mensagem exatamente uma vez

5. Quais as vantagens do MQTT?

  • Baixo consumo de memória.
  • Baixa necessidade de processamento para envio de mensagem.
  • Baixo consumo de banda

1. Em qual camada o MQTT trabalha?

  • Na camada de aplicação, a sétima camada do modelo OSI.

2. Explique o paradigma Publish-subscribe.

O paradigma possui três papéis: o broker, o publisher e o subscriber.

  • Publisher: envia mensagens referentes a tópico.
  • Subscriber: assina tópicos para receber mensagens sobre ele.
  • Broker: recebe as mensagens dos publishers e é responsável em enviar as mensagens para os subscribers que tenham interesse nesse assunto específico.

3.Qual o tamanho do header fixo do MQTT?

2 bytes

REFERÊNCIAS

Referências

[1] https://www.gta.ufrj.br/ensino/eel878/redes1-2019-1/vf/mqtt/

[2] https://www.gta.ufrj.br/ensino/eel878/redes1-2018-1/trabalhos-vf/mqtt/

[3] https://www.embarcados.com.br/mqtt-protocolos-para-iot/#Implementacoes-e-exemplos-de-uso

[4] https://www.ibm.com/developerworks/br/library/iot-mqtt-why-good-for-iot/index.html

Learn more about creating dynamic, engaging presentations with Prezi