Recursos MQTT suportados pelo recurso de agente MQTT da Grade de Eventos do Azure

O MQTT é um protocolo de transporte de mensagens de publicação-assinatura que foi projetado para ambientes restritos. É eficiente, escalável e confiável, o que o tornou o padrão ouro para comunicação em cenários de IoT. O broker MQTT suporta clientes que publicam e assinam mensagens sobre MQTT v3.1.1, MQTT v3.1.1 sobre WebSockets, MQTT v5 e MQTT v5 sobre WebSockets. O broker MQTT também suporta comunicação entre as versões MQTT (MQTT 3.1.1 e MQTT 5).

O MQTT v5 introduziu muitas melhorias em relação ao MQTT v3.1.1 para oferecer uma comunicação mais perfeita, transparente e eficiente. E acrescentou:

• Melhor relatório de erros.
• Clientes de comunicação mais transparentes por meio de recursos como propriedades do usuário e tipo de conteúdo.
• Mais controlo para os clientes sobre a comunicação através de funcionalidades como a mensagem e a expiração da sessão.
• Padrões importantes padrão, como o padrão solicitação-resposta.

Fluxo de conexão:

Seus clientes MQTT devem se conectar por TLS 1.2 ou TLS 1.3. As tentativas de ignorar esta etapa falham com a conexão.

Ao se conectar ao broker MQTT, use as seguintes portas durante a comunicação pelo MQTT:

• MQTT v3.1.1 e MQTT v5 na porta TCP 8883
• MQTT v3.1.1 sobre WebSocket e MQTTv5 sobre WebSocket na porta TCP 443.

O pacote CONNECT deve incluir as seguintes propriedades:

• O campo ClientId é obrigatório e deve incluir o nome da sessão do cliente. O nome da sessão precisa ser exclusivo em todo o namespace. Você pode usar o nome de autenticação do cliente como o nome da sessão se cada cliente estiver usando uma sessão por cliente. Se um cliente estiver usando várias sessões, ele precisará usar valores diferentes para ClientId para cada uma de suas sessões.
• O campo Username é obrigatório se você não selecionou um valor no alternativeAuthenticationNameSources durante a criação do namespace. Nesse caso, você precisa fornecer o nome de autenticação do cliente no campo Nome de usuário. Esse nome precisa corresponder ao nome de autenticação fornecido e ao valor no campo de certificado do cliente especificado durante a criação do recurso do cliente.

Saiba mais sobre a autenticação de cliente.

Suporte a várias sessões

O suporte a várias sessões permite que seus clientes MQTT de aplicativos tenham uma implementação mais escalável e confiável, conectando-se ao broker MQTT com várias sessões ativas ao mesmo tempo.

Configuração do namespace

Antes de usar esse recurso, você precisa configurar o namespace para permitir várias sessões por cliente. Use as seguintes etapas para configurar várias sessões por cliente no portal do Azure:

• Vá para seu namespace no portal do Azure.
• Em Configuração, altere o valor de Máximo de sessões de cliente por nome de autenticação para o número desejado de sessões por cliente.
• Selecione Aplicar.

Nota

Para a configuração da CLI do Azure, atualize a propriedade MaxClientSessionsPerAuthenticationName na carga útil do namespace com o valor desejado.

Fluxo de conexão:

Os pacotes CONNECT para cada sessão devem incluir as seguintes propriedades:

• Forneça a propriedade Username no pacote CONNECT para indicar o nome de autenticação do cliente.
• Forneça a propriedade ClientID no pacote CONNECT para significar o nome da sessão, como se houver um ou mais valores para o ClientID para cada nome de usuário.

Por exemplo, as seguintes combinações de Username e ClientIds no pacote CONNECT permitem que o cliente "Mgmt-application" se conecte ao broker MQTT ao longo de três sessões independentes:

• Primeira Sessão:
  • Nome de utilizador: Mgmt-application
  • ID do cliente: Mgmt-Session1
• Segunda Sessão:
  • Nome de utilizador: Mgmt-application
  • ID do cliente: Mgmt-Session2
• Terceira Sessão:
  • Nome de utilizador: Mgmt-application
  • ID do cliente: Mgmt-Session3

Para obter mais informações, consulte Como estabelecer várias sessões para um único cliente.

Sessões de manuseamento:

• Se um cliente tentar assumir a sessão ativa de outro cliente apresentando seu nome de sessão com um nome de autenticação diferente, sua solicitação de conexão será rejeitada com um erro não autorizado. Por exemplo, se o Cliente B tentar se conectar à sessão 123 atribuída naquele momento para o Cliente A, a solicitação de conexão do Cliente B será rejeitada. Dito isso, se o mesmo cliente tentar se reconectar com os mesmos nomes de sessão e o mesmo nome de autenticação, ele poderá assumir a sessão existente.
• Se um recurso de cliente for excluído sem encerrar sua sessão, outros clientes não poderão usar seu nome de sessão até que a sessão expire. Por exemplo, se o cliente B criar uma sessão com o nome de sessão 123, o cliente B será excluído, o cliente A não poderá se conectar à sessão 123 até que ela expire.
• O limite para o número de sessões por cliente aplica-se a sessões online e offline em qualquer momento. Por exemplo, considere um namespace com o máximo de sessões de cliente por nome de autenticação definido como 1. Se o cliente A se conectar com uma sessão persistente 123 e, em seguida, for desconectado, o cliente A não poderá se conectar com uma nova sessão 456, pois sua sessão 123 ainda está ativa, mesmo que esteja offline. Assim, recomendamos que o mesmo cliente sempre se reconecte com os mesmos nomes de sessão estática, em vez de gerar um novo nome de sessão a cada reconexão.

Recursos do MQTT

O recurso de agente MQTT da Grade de Eventos do Azure dá suporte aos seguintes recursos MQTT:

Qualidade de serviço (QoS)

O broker MQTT suporta QoS 0 e 1, que definem a garantia de entrega de mensagens em pacotes PUBLISH e SUBSCRIBE entre clientes e corretor MQTT. QoS 0 garante entrega no máximo uma vez; mensagens com QoS 0 não são reconhecidas pelo assinante nem são retransmitidas pelo editor. QoS 1 garante pelo menos uma entrega; As mensagens são reconhecidas pelo assinante e são retransmitidas pelo editor se não forem reconhecidas. A QoS permite que seus clientes controlem a eficiência e a confiabilidade da comunicação.

Sessões persistentes

O broker MQTT suporta sessões persistentes para MQTT v3.1.1 de tal forma que o broker MQTT preserva informações sobre a sessão de um cliente em caso de desconexões para garantir a confiabilidade da comunicação. Estas informações incluem as subscrições do cliente e mensagens QoS 1 perdidas/não reconhecidas. Os clientes podem configurar uma sessão persistente definindo o sinalizador cleanSession no pacote CONNECT como false.

Início limpo e expiração da sessão

O MQTT v5 introduziu os recursos de início limpo e expiração da sessão como uma melhoria em relação ao MQTT v3.1.1 no tratamento da persistência da sessão. Clean Start é um recurso que permite que um cliente inicie uma nova sessão com o broker MQTT, descartando quaisquer dados de sessão anteriores. A Expiração da Sessão permite que um cliente informe o corretor MQTT quando uma sessão inativa for considerada expirada e removida automaticamente. No pacote CONNECT, um cliente pode definir o sinalizador Início Limpo como verdadeiro e/ou curto intervalo de expiração da sessão por motivos de segurança ou para evitar possíveis conflitos de dados que possam ter ocorrido durante a sessão anterior. Um cliente também pode definir um início limpo para falso e/ou intervalo de expiração de sessão longa para garantir a confiabilidade e eficiência de sessões persistentes.

Configuração do intervalo máximo de expiração da sessão

Você pode configurar o intervalo máximo de expiração de sessão permitido para todos os seus clientes que se conectam ao namespace Grade de Eventos. Para clientes MQTT v3.1.1, o limite configurado é aplicado como o intervalo de expiração de sessão padrão para todas as sessões persistentes. Para clientes MQTT v5, o limite configurado é aplicado como o valor máximo para a propriedade Session Expiry Interval no pacote CONNECT; Qualquer valor que exceda o limite é ajustado. O valor padrão para essa propriedade de namespace é 1 hora e pode ser estendido até 8 horas. Use as seguintes etapas para configurar o intervalo máximo de expiração da sessão no portal do Azure:

• Vá para seu namespace no portal do Azure.
• Em Configuração, altere o valor do intervalo máximo de expiração da sessão em horas para o limite desejado.
• Selecione Aplicar.

Estouro de sessão

O broker MQTT mantém uma fila de mensagens para cada sessão MQTT ativa que não está conectada, até que o cliente se conecte com o broker MQTT novamente para receber as mensagens na fila. Se um cliente não se conectar para receber as mensagens QOS1 enfileiradas, a fila de sessões começará a acumular as mensagens até atingir seu limite: 100 mensagens ou 1 MB. Quando a fila atinge seu limite durante a vida útil da sessão, a sessão é encerrada.

Mensagens da Última Vontade e do Testamento (LWT)

O Last Will and Testament (LWT) notifica seus clientes MQTT com as desconexões abruptas de outros clientes MQTT. Você pode usar o LWT para garantir um fluxo previsível e confiável de comunicação entre clientes MQTT durante desconexões inesperadas, o que é valioso para cenários onde a comunicação em tempo real, a confiabilidade do sistema e as ações coordenadas são críticas. Os clientes que colaboram para executar tarefas complexas podem reagir a mensagens LWT uns dos outros, ajustando seu comportamento, redistribuindo tarefas ou assumindo certas responsabilidades para manter o desempenho e a estabilidade do sistema. Para usar o LWT, um cliente pode especificar a mensagem will, o tópico will e o restante das propriedades will no pacote CONNECT durante a conexão. Quando o cliente se desconecta abruptamente, o broker MQTT publica a mensagem de vontade para todos os clientes que se inscreveram no tópico will. Para reduzir o ruído de desconexões flutuantes, o cliente pode definir o intervalo de atraso de vontade para um valor maior que zero. Nesse caso, se o cliente se desconectar abruptamente, mas restaurar a conexão antes que o intervalo de atraso expire, a mensagem de vontade não será publicada.

Propriedades do utilizador

O broker MQTT suporta propriedades de usuário em pacotes MQTT v5 PUBLISH que permitem adicionar pares chave-valor personalizados no cabeçalho da mensagem para fornecer mais contexto sobre a mensagem. Os casos de uso para propriedades de usuário são versáteis. Você pode usar esse recurso para incluir a finalidade ou a origem da mensagem para que o recetor possa lidar com a mensagem sem analisar a carga útil, economizando recursos de computação. Por exemplo, uma mensagem com uma propriedade de usuário indicando sua finalidade como um "aviso" pode acionar uma lógica de manipulação diferente de uma com a finalidade de "informação".

Padrão de solicitação-resposta

O MQTTv5 introduziu campos no cabeçalho do pacote MQTT PUBLISH que fornecem contexto para a mensagem de resposta no padrão solicitação-resposta. Esses campos incluem um tópico de resposta e uma ID de correlação que o respondente pode usar na resposta sem configuração prévia. As informações de resposta permitem uma comunicação mais eficiente para o padrão padrão solicitação-resposta usado em cenários de comando e controle.

Intervalo de expiração da mensagem:

No MQTT v5, o intervalo de expiração das mensagens permite que as mensagens tenham uma vida útil configurável. O intervalo de expiração da mensagem é definido como o intervalo de tempo entre o momento em que uma mensagem é publicada no broker MQTT e o momento em que o broker MQTT precisa descartar a mensagem não entregue. Esse recurso é útil em cenários em que as mensagens são válidas apenas por um determinado período de tempo, como comandos sensíveis ao tempo, streaming de dados em tempo real ou alertas de segurança. Ao definir um intervalo de expiração de mensagens, o corretor MQTT pode remover automaticamente mensagens desatualizadas, garantindo que apenas informações relevantes estejam disponíveis para os assinantes. Se o intervalo de expiração de uma mensagem estiver definido como zero, isso significa que a mensagem nunca deve expirar.

Aliases de tópico:

No MQTT v5, os aliases de tópico permitem que um cliente use um alias mais curto no lugar do nome completo do tópico na mensagem publicada. O broker MQTT mantém um mapeamento entre o alias do tópico e o nome do tópico real. Esse recurso pode economizar largura de banda de rede e reduzir o tamanho do cabeçalho da mensagem, especialmente para tópicos com nomes longos. É útil em cenários em que o mesmo tópico é repetidamente publicado em várias mensagens, como em redes de sensores. O broker MQTT suporta até 10 aliases de tópico. Um cliente pode usar um campo Alias de tópico no pacote PUBLISH para substituir o nome completo do tópico pelo alias correspondente.

Controlo de fluxo

No MQTT v5, controle de fluxo refere-se ao mecanismo para gerenciar a taxa e o tamanho das mensagens que um cliente pode manipular. O controle de fluxo pode ser configurado definindo os parâmetros Tamanho máximo do pacote e Máximo de recebimento no pacote CONNECT. O parâmetro Receive Maximum permite que o cliente limite o número de mensagens enviadas pelo broker ao número de mensagens que o cliente é capaz de manipular. O parâmetro Maximum Packet Size define o tamanho máximo de pacotes que o cliente pode receber. O broker MQTT tem um limite de tamanho de mensagem de 512 KiB. Esse recurso garante confiabilidade e estabilidade da comunicação para dispositivos restritos com velocidade de processamento ou recursos de armazenamento limitados.

Confirmações negativas e pacote de desconexão iniciado pelo servidor

Para MQTT v5, o broker MQTT é capaz de enviar confirmações negativas (NACKs) e pacotes de desconexão iniciados pelo servidor que fornecem ao cliente mais informações sobre falhas para entrega de mensagens ou conexão. Esses recursos ajudam o cliente a diagnosticar o motivo por trás de uma falha e tomar as ações mitigadoras apropriadas. O broker MQTT usa os códigos de motivo definidos na especificação MQTT v5.

Limitações atuais

O corretor MQTT está adicionando mais recursos MQTT v5 e MQTT v3.1.1 no futuro para se alinhar mais com as especificações MQTT. A lista a seguir detalha as diferenças atuais entre os recursos suportados pelo broker MQTT e as especificações MQTT:

Limitações atuais do MQTTv5

O MQTT v5 atualmente difere da especificação MQTT v5 das seguintes maneiras:

• As Subscrições Partilhadas ainda não são suportadas.
• O sinalizador Retain ainda não é suportado.
• O intervalo máximo de atraso é de 300.
• QoS máximo é 1.
• O tamanho máximo do pacote é de 512 KiB
• A encomenda de mensagens não é garantida.
• Não há suporte para identificadores de assinatura.
• Os identificadores de cliente atribuídos ainda não são suportados.
• O tópico Alias Maximum é 10. O servidor não atribui nenhum aliases de tópico para mensagens de saída no momento. Os clientes podem atribuir e usar aliases de tópico dentro do limite definido.
• O CONNACK não retorna a propriedade Informações de Resposta, mesmo que a solicitação CONNECT contenha a propriedade Informações de Resposta de Solicitação.
• As propriedades do usuário nos pacotes CONNECT, SUBSCRIBE, DISCONNECT, PUBACK, AUTH não são usadas pelo serviço, portanto, não são suportadas. Se qualquer uma dessas solicitações incluir propriedades de usuário, a solicitação falhará.
• Se o servidor receber um PUBACK de um cliente com código de resposta sem êxito, a conexão será encerrada.
• O máximo de Keep Alive é de 1.160 segundos.

Limitações atuais do MQTTv3.1.1

O MQTT v5 atualmente difere da especificação MQTT v3.1.1 das seguintes maneiras:

• QoS2 e Retain Flag ainda não são suportados. Uma solicitação de publicação com um sinalizador de retenção ou com uma QoS2 falha e fecha a conexão.
• A encomenda de mensagens não é garantida.
• O máximo de Keep Alive é de 1.160 segundos.

Exemplos de código:

Este repositório contém exemplos de código C#, C e python que mostram como enviar telemetria, enviar comandos e transmitir alertas. Os certificados criados através das amostras são adequados para testes, mas não são adequados para ambientes de produção.

Passos seguintes:

Saiba mais sobre o MQTT:

• Dados técnicos: MQTT v3.1.1
• Especificação MQTT v5

Saiba mais sobre o corretor MQTT:

• Autenticação do cliente
• Como estabelecer várias sessões para um único cliente