25 anos do MQTT
(andypiper.co.uk)- MQTT se espalhou ao longo de 25 anos, desde a divulgação inicial da especificação em outubro de 1999, de um protocolo leve para pequenos dispositivos e redes instáveis para uso em toda a indústria, casas e aplicativos
- A estrutura simples de publicação/assinatura, pensada para energia limitada e conexões intermitentes, continuou sendo um ponto forte mesmo depois que os ambientes de rede e de dispositivos de borda mudaram
- O MQTT, usado nos arredores da IBM, começou a ganhar tração na comunidade entre 2009 e 2011, e com Mosquitto e Eclipse Paho se expandiu para um ecossistema de protocolo aberto fora da IBM
- Hoje ele está presente até em lugares que os usuários nem percebem, como processamento de mensagens com Node-RED no Raspberry Pi, purificadores de ar Dyson e seus apps, controle de impressoras 3D, alertas domésticos e chão de fábrica
- No aniversário de 25 anos, a comunidade deixou a antiga conta de projeto no X e migrou para o Mastodon, em @mqtt@fosstodon.org, além de publicar sua primeira mensagem no Fediverse baseado em ActivityPub
Mensageria leve que nasceu em ambientes limitados
- Outubro de 2024 marca o 25º aniversário da publicação do documento que levaria à primeira especificação do MQTT
- O MQTT é um protocolo de rede projetado tendo como base os dispositivos pequenos e limitados do fim dos anos 1990, além de redes leves ou instáveis
- O foco era enviar dados de sensores para sistemas maiores em situações com conexão intermitente e energia limitada, como em dispositivos remotos de monitoramento ambiental
- Esses dispositivos precisam economizar energia, largura de banda e disponibilidade de rede
- O MQTT se encaixa bem na forma de publicar, coletar e receber dados em um formato pequeno, mas útil
- Mesmo com redes mais rápidas e estáveis e com o crescimento de dispositivos de borda, automação residencial e aparelhos portáteis, a simplicidade do protocolo continua sendo a principal força do MQTT
Dos arredores da IBM a um ecossistema aberto
- Depois de entrar na IBM em 2001, ele trabalhou em projetos de clientes relacionados a IBM MQ, integração de negócios, enfileiramento de mensagens, conexão de aplicações e middleware
- O IBM Hursley Lab era a base das atividades de Andy Stanford-Clark, cocriador do MQTT e também ligado à base do MQ, e foi ao redor desse ambiente que os experimentos com MQTT começaram
- Na época, o MQTT já estava aberto externamente como protocolo, mas fora da IBM ele não era muito conhecido nem amplamente implementado
- Por volta de 2009 a 2011, avançaram os esforços para divulgar o MQTT para além do pequeno escopo de implementação da IBM
- Na época, as opções de broker eram o IBM WebSphere Message Broker, voltado ao mercado corporativo e caro, o microbroker de código fechado e o Really Small Message Broker, também de código fechado, mas distribuído gratuitamente
- O Mosquitto, software de código aberto criado por Roger Light, continua sendo uma das implementações gratuitas mais usadas até hoje
- Roger Light criou o Mosquitto depois de assistir, no primeiro OggCamp em 2009, à apresentação de Andy Stanford-Clark sobre casa inteligente conectada, exatamente 10 anos após a criação da especificação
Eclipse Paho e a padronização oficial
- Em 2011, a implementação de MQTT da IBM foi doada à comunidade Eclipse, dando início ao projeto Eclipse Paho
- Mesmo depois de deixar a IBM em 2012, a ligação com o projeto Paho continuou, inclusive com participação durante o período na Cloud Foundry
- Após entrar no Twitter em 2014, ele se afastou do envolvimento formal
- Nesse período, o MQTT passou pelo processo de padronização oficial na OASIS e na ISO/IEC
O MQTT invisível de hoje
- O MQTT ultrapassou as fronteiras da IBM e se tornou um caso de sucesso de protocolo aberto; 25 anos depois, está embutido em vários produtos e ambientes sem que os usuários percebam
- Entre os usos mais representativos estão:
- projetos de hobby e de makers
- purificadores de ar Dyson e seus aplicativos relacionados
- sistemas de controle de impressoras 3D
- sistemas de alertas domésticos
- ambientes industriais e de manufatura
- No espaço de trabalho pessoal, o MQTT também é usado de várias formas
- A impressora 3D Bambu Lab X1C usa MQTT para comunicação interna
- Dispositivos conectados na parede reagem a alertas MQTT para mostrar dados ou acender luzes
- O Node-RED rodando em um Raspberry Pi processa mensagens MQTT
- É bastante provável que pelo menos um dos aplicativos no seu celular também use MQTT em algum ponto da stack
25 anos e a migração da comunidade
- A conta da comunidade MQTT migrou para o Mastodon, substituindo a antiga conta de projeto no X
- A nova conta pode ser seguida em @mqtt@fosstodon.org
- Para marcar os 25 anos, o MQTT publicou sua primeira mensagem no Fediverse via ActivityPub, juntando-se à open social web
- Andy Stanford-Clark participou de um fireside chat com a HiveMQ, e o podcast da HiveMQ, The Unstructured Message, também é apresentado como um lugar para ver mais conteúdo relacionado ao MQTT
1 comentários
Opiniões do Hacker News
O primeiro projeto que ainda está em operação e é usado todos os dias foi transformar um mapa SVG do sistema hidráulico de tubulações/bombas/válvulas de neve artificial e combate a incêndio de uma grande estação de esqui em um site de exibição de status.
Criei um tópico MQTT para cada bomba, válvula e trecho de tubulação, associei estados como direção do fluxo de água, liga/desliga de bombas/válvulas e pressão, e atualizava as cores e preenchimentos do SVG com mqtt.js e jQuery.
Um broker MQTT rodando em contêiner em hospedagem estática está funcionando há quase 10 anos praticamente sem intervenção, e o mqtt.js funciona sobre WebSockets, então, quando o estado muda, isso é refletido automaticamente para todos.
Usei MQTT em um projeto recente, mas não gostei muito.
O protocolo tem muitas opções, e não era fácil entender de imediato o que cada opção faz, por que é importante e em quais combinações devem ser usadas para que tudo funcione como pretendido; a documentação também não explicava isso bem.
Parte disso talvez tenha sido culpa do cliente Python Eclipse Mosquitto que usei: em um sistema lento, surgia uma condição de corrida que fazia assinaturas de tópicos serem silenciosamente ignoradas e quebrava callbacks, e levei dias para descobrir.
Eu tinha seguido a documentação 100%, e mesmo assim foi uma das experiências mais bagunçadas que já tive com um protocolo que nem é tão antigo.
Minha experiência com os clientes Eclipse, por exemplo Paho em Python e C++, foi parecida: pareciam excessivamente complexos, de nível baixo demais, e também tinham alguns bugs por causa da arquitetura.
Talvez isso tenha acontecido com o tempo porque a manutenção é praticamente feita por uma pessoa só. O cliente C++ também teve apenas um contribuidor nos últimos 6 meses, e ninguém contribuiu nos últimos 3 meses.
Um PR simples que corrigia um bug óbvio, algo no nível de trocar uma única palavra, levou 2 anos para ser revisado e mesclado. Não digo isso como crítica pessoal; é mais que parece haver muitas bibliotecas, bugs e trabalho, sendo tratados por poucas pessoas sobrecarregadas.
Ao migrar para outros clientes, a experiência em Python, Rust, C# e C++ ficou muito melhor, e a maioria deles tem uma boa combinação de APIs de alto e baixo nível, então, se você só quer enviar mensagens para um tópico, não precisa se preocupar com ACKs ou retentativas.
Por outro lado, se precisar de controle, você também consegue controlar. Fico preocupado se manter paho e afins vivos no estado atual não acaba sendo mais prejudicial. Se estivessem oficialmente mortos, pelo menos o problema viria à tona à força; do jeito que está, usuários têm essa experiência e desistem do MQTT ou acham que estão fazendo algo errado.
O design da API, a documentação fraca e a forma que parecia não seguir as convenções de Python me incomodaram.
No começo parece fácil, mas a amplitude do protocolo e da implementação vai aos poucos virando um obstáculo. Em certo momento, uma forma confiável de verificar se a conexão com o servidor tinha sido bem-sucedida era assinar o mesmo tópico duas vezes e capturar um código de erro específico na mensagem
on_connect. Na época, esse código aparecia na documentação como código de sucesso.Sei que parece absurdo, mas, mesmo que houvesse uma forma melhor, ela não era fácil de encontrar. Ainda assim, reclamar é fácil, e sou grato às muitas pessoas que criaram essa biblioteca. Sem elas, eu não poderia ter construído o que construí, e respeito quem assume projetos enormes como esse.
Sempre que possível, preferi lidar com o protocolo usando
mosquitto_subemosquitto_pub, lendo e escrevendo apenas pela entrada e saída padrão.Não foi só por causa de bugs; era simplesmente mais fácil deixar o gerenciamento da conexão com o broker para um programa já escrito e testado.
Mas não consegui usar essa abordagem de forma eficaz com mensagens de última vontade, e ela também não serve para microcontroladores que não rodam algo como Linux.
Na prática, ela cria um sistema de pipes *nix em rede e autenticado, com o objetivo de ser a forma mais simples de enviar e receber eventos.
No meu caso de uso, uma fila infinita era importante, mas MQTT não oferecia isso; e, se eu ainda precisasse gerenciar IDs de mensagens para que o MQTT acompanhasse seus próprios IDs de mensagem e os enviasse ao broker, não havia motivo para usá-lo.
Se não for para integrar com um projeto que já foi feito em torno de MQTT, não tenho muita certeza de qual é o melhor caso de uso.
Nos últimos anos, o MQTT tem sido muito mais usado dentro de fábricas para compartilhar dados entre máquinas
Historicamente, ele era usado na área de Oil & Gas para SCADA, trazendo dados de locais remotos de poços
Há mais de 10 anos, adicionei MQTT ao Kepware (servidor OPC) para fazer streaming de valores de tags para a “nuvem”; depois da apresentação, Arlen Nipper, um dos criadores do MQTT, veio até mim e disse que “ficou bom”, o que me deixou humilde
Hoje, em uma nova empresa chamada HighByte, modelamos dados de fábrica na borda e os enviamos para MQTT, SparkplugB (um protocolo sobre MQTT), S3, Azure Blob etc.
Em resumo, o MQTT é uma grande força por trás da Industry 4.0, e é legal vê-lo ainda tão usado depois de tanto tempo
É meio grosseiro e tem mais etapas de processamento do que gostaríamos. Como a Kepware cobra uma licença recorrente anual pelo plugin IoT, agora estamos saindo dessa solução e migrando para que o telegraf leia dados OPC-UA diretamente do Kepware
Fiquei curioso se você trabalhou ou trabalha na Kepware
Eu gostaria que simplesmente usassem Sparkplug B e implementassem por cima uma especificação para semântica
Além disso, o trabalho assíncrono que estão fazendo agora é superengenheirado demais e muito ruim. Participei das reuniões por um tempo, e, embora a especificação do MQTT tenha menos de 50 páginas e seja fácil de ler, eles nunca a tinham lido e nem entendiam para que servem os headers. Por exemplo, queriam colocar no header algo que, na prática, deveria ir no payload
Uma pessoa da Microsoft até se incomodou com a sugestão de primeiro ver o que os concorrentes estavam fazendo com MQTT. Isso porque queriam criar algo novo em vez de copiar
Por minha sugestão, nossa empresa vai lidar com OPC UA apenas bem na borda e mantê-lo o mais isolado possível da nossa tecnologia
Mas hoje também vejo Kafka e RabbitMQ avançando cada vez mais sobre o espaço de mercado do MQTT
Cerca de 15 anos atrás, quando dispositivos IoT que tuitavam ainda não eram comuns, a casa de Andy Stanford Clark chegou a virar notícia
https://www.bbc.co.uk/blogs/technology/2009/06/things_that_t...
O protocolo central foi concebido numa época em que transmitir 1 byte por um link via satélite custava 1 dólar, por isso é incrivelmente eficiente e simples de implementar
Certa vez, no firewall de um cliente, a única porta disponível era a MQTT 1883
Era por ali que eles recebiam dados de sensores e, por mais que pedíssemos, não abriam nenhuma outra porta, então contornamos isso criando um wrapper TCP em tempo real sobre MQTT
Um daemon TCP multithread local escutava requisições de saída em uma porta específica, as encapsulava em MQTT e publicava em um tópico exclusivo; o daemon do servidor detectava esse tópico, desencapsulava e encaminhava para o processo do servidor
Do ponto de vista da máquina cliente, parecia que ela estava estabelecendo uma conexão TCP em tempo real com nosso servidor, mas no meio havia um estranho wrapper MQTT invisível
Depois que funcionou, ficou elegante, mas depurar foi realmente sofrido, e levou meses, passando por vários becos sem saída, até encaixar tudo corretamente
Hoje em dia, chamamos a situação de não poder fazer nada e ficar só mexendo os dedos de “deixar o processo funcionar”
Um fato interessante: a Boost, a biblioteca C++ mais famosa, está avaliando neste momento incluir a implementação
async-mqtt5(https://github.com/mireo/async-mqtt5) como Boost.MQTT: https://lists.boost.org/Archives/boost/2024/10/index.phpAnedoticamente, a maior parte das adoções que vi foi nos anos 2000 e no comecinho dos anos 2010, ou seja, antes de todo mundo exigir C++0x/C++11, e hoje só vejo raramente
boost.org parece uma viagem no tempo. Está exatamente como eu lembrava por volta de 2008, até o “Get Boost” sobreposto no botão de parada de emergência continua igual
MQTT é um pequeno protocolo realmente bom, “pequeno o bastante” para usar em projetos de hobby, mas também escala a ponto de ser usado em coisas como o Facebook Messenger
[1]: https://engineering.fb.com/2011/08/12/android/building-faceb...
Não me convence muito a divulgação de que o MQTT é leve e eficiente
No fim, ele só usa TCP/IP; talvez isso fosse relativamente especial pelos padrões da época, mas nunca vi evidências reais que sustentem essa afirmação além da autopromoção constante
É bom o fato de ser um padrão e, por isso, permitir conexão com dispositivos prontos que o suportam. Ainda assim, acho que há opções melhores para publicação/assinatura ou filas de mensagens, especialmente quando é preciso failover do lado do consumidor
O ponto positivo do MQTT, e algo que quase todas as outras implementações de publicação/assinatura que já vi fazem errado, é que a estrutura de dados central do MQTT não são filas e tópicos, mas sim clientes assinantes
Por isso é possível mapear um espaço de endereços tão grande quanto se quiser para uma árvore de tópicos. A árvore de tópicos pode ter trilhões de endpoints e, se você quiser, mesmo em um servidor embarcado dá para ter um endpoint para cada endereço IPv6
Como a árvore de tópicos é rica, as assinaturas podem ser tão seletivas quanto necessário, e o servidor pode operar rapidamente mesmo com baixo uso de recursos
Tenho usado MQTT em aulas de IoT há alguns anos, e ele se mostrou uma ferramenta muito versátil
Também é conveniente o fato de haver suporte via WebSockets
Em um projeto recente de sistemas embarcados, usei MQTT como sistema de mensageria entre processos, e foi bem interessante
O broker e os clientes rodavam na mesma máquina
Quando era preciso farejar ou depurar algo, bastava conectar o dispositivo à rede e usar o MQTT Explorer para registrar ou injetar mensagens, o que era fácil
Também dava para abrir uma porta para fora da LAN e permitir que um colega em trabalho remoto manipulasse o sistema
Minha maior preocupação ao usá-lo como componente de sistema é a garantia de durabilidade, e não tenho muita confiança de que a implementação do broker não vá perder dados