Suporte ao MQTT 5 do Hub IoT (visualização)

  • Artigo

Versão: 2.0 api-versão: 2020-10-01-preview

Este documento define a API do plano de dados do Hub IoT sobre o protocolo MQTT versão 5.0. Consulte Referência da API para obter definições completas nesta API.

Nota

O Hub IoT tem suporte limitado a recursos para MQTT. Se sua solução precisar de suporte a MQTT v3.1.1 ou v5, recomendamos o suporte a MQTT na Grade de Eventos do Azure. Para obter mais informações, consulte Comparar o suporte MQTT no Hub IoT e na Grade de Eventos.

Pré-requisitos

  • Crie um novo hub IoT com o modo de visualização ativado. O MQTT 5 só está disponível no modo de visualização e você não pode alternar um hub IoT existente para o modo de visualização. Para obter mais informações, consulte Ativar modo de visualização
  • Conhecimento prévio da especificação MQTT 5.

Nível de suporte e limitações

O suporte do Hub IoT para MQTT 5 está em pré-visualização e limitado das seguintes maneiras (comunicado ao cliente por meio de CONNACK propriedades, a menos que explicitamente indicado de outra forma):

  • Ainda não há suporte oficial para SDKs de dispositivos IoT do Azure.
  • Não há suporte para identificadores de assinatura.
  • Não há suporte para assinaturas compartilhadas.
  • RETAIN não é suportado.
  • Maximum QoS é 1.
  • Maximum Packet Size é 256 KiB (sujeito a restrições adicionais por operação).
  • Não há suporte para IDs de cliente atribuídas.
  • Keep Alive é limitado a 19 min (atraso máximo para verificação de vivacidade – 28.5 min).
  • Topic Alias Maximum é 10.
  • Response Information não é suportado; CONNACK não retorna Response Information propriedade mesmo se CONNECT contiver Request Response Information propriedade.
  • Receive Maximum (número máximo de pacotes não reconhecidos PUBLISH pendentes permitidos (na direção cliente-servidor) com QoS: 1) é 16.
  • Um único cliente não pode ter mais do que 50 assinaturas. Se um cliente atingir o limite de assinatura, SUBACK retornará 0x97 o código de motivo (Cota excedida) para assinaturas.

Ciclo de vida da conexão

Connection

Para conectar um cliente ao Hub IoT usando essa API, estabeleça conexão de acordo com a especificação MQTT 5. O cliente deve enviar CONNECT o pacote dentro de 30 segundos após o handshake TLS bem-sucedido ou o servidor fecha a conexão. Aqui está um exemplo de CONNECT pacote:

-> CONNECT
    Protocol_Version: 5
    Clean_Start: 0
    Client_Id: D1
    Authentication_Method: SAS
    Authentication_Data: {SAS bytes}
    api-version: 2020-10-10
    host: abc.azure-devices.net
    sas-at: 1600987795320
    sas-expiry: 1600987195320
    client-agent: artisan;Linux
  • Authentication Method é necessária e identifica qual método de autenticação é usado. Para obter mais informações sobre o método de autenticação, consulte Autenticação.
  • Authentication Data O manuseamento da propriedade depende de Authentication Method. Se Authentication Method estiver definido como SAS, então Authentication Data é necessário e deve conter uma assinatura válida. Para obter mais informações sobre dados de autenticação, consulte Autenticação.
  • api-version é necessária e deve ser definida como o valor da versão da API fornecido no cabeçalho desta especificação para que esta especificação seja aplicada.
  • host define o nome do host do locatário. É necessário, a menos que a extensão SNI tenha sido apresentada no registro Hello do cliente durante o handshake TLS
  • sas-at define o tempo de conexão.
  • sas-expiry define o tempo de expiração para o SAS fornecido.
  • client-agent Opcionalmente, comunica informações sobre o cliente que está criando a conexão.

Nota

Authentication Method e outras propriedades ao longo da especificação com nomes em maiúsculas são propriedades de primeira classe no MQTT 5 - elas são descritas em detalhes na especificação MQTT 5. api-version e outras propriedades no caso do traço são propriedades de usuário específicas da API do Hub IoT.

O Hub IoT responde com CONNACK o pacote quando termina com a autenticação e a busca de dados para dar suporte à conexão. Se a conexão for estabelecida com êxito, CONNACK terá a seguinte aparência:

<- CONNACK
    Session_Present: 1
    Reason_Code: 0x00
    Session_Expiry_Interval: 0xFFFFFFFF # included only if CONNECT specified value less than 0xFFFFFFFF and more than 0x00
    Receive_Maximum: 16
    Maximum_QoS: 1
    Retain_Available: 0
    Maximum_Packet_Size: 262144
    Topic_Alias_Maximum: 10
    Subscription_Identifiers_Available: 0
    Shared_Subscriptions_Available: 0
    Server_Keep_Alive: 1140 # included only if client did not specify Keep Alive or if it specified a bigger value

Essas CONNACK propriedades de pacote seguem a especificação MQTT 5. Eles refletem os recursos do Hub IoT.

Autenticação

A Authentication Method propriedade no CONNECT cliente define que tipo de autenticação ele usa para essa conexão:

  • SAS - A Assinatura de Acesso Compartilhado é fornecida na CONNECTpropriedade da Authentication Data ,
  • X509 - O cliente depende da autenticação do certificado do cliente.

A autenticação falhará se o método de autenticação não corresponder ao método configurado do cliente no Hub IoT.

Nota

Esta API requer Authentication Method que a propriedade seja definida no CONNECT pacote. Se Authentication Method a propriedade não for fornecida, a conexão falhará com Bad Request a resposta.

Não há suporte para autenticação de nome de usuário/senha usada em versões anteriores da API.

SAS

Com a autenticação baseada em SAS, um cliente deve fornecer a assinatura do contexto de conexão. A assinatura prova a autenticidade da conexão MQTT. A assinatura deve ser baseada em uma das duas chaves de autenticação na configuração do cliente no Hub IoT. Ou deve ser baseado em uma das duas chaves de acesso compartilhado de uma política de acesso compartilhado.

A cadeia de caracteres para assinar deve ser formada da seguinte forma:

{host name}\n
{Client Id}\n
{sas-policy}\n
{sas-at}\n
{sas-expiry}\n
  • host name é derivado da extensão SNI (apresentada pelo cliente no registro Hello do cliente durante o handshake TLS) ou host da propriedade do usuário no CONNECT pacote.
  • Client Id é o Identificador do Cliente no CONNECT pacote.
  • sas-policy - se presente, define a política de acesso do Hub IoT usada para autenticação. Ele é codificado como propriedade do usuário no CONNECT pacote. Opcional: omiti-lo significa que as configurações de autenticação no registro do dispositivo são usadas em vez disso.
  • sas-at - se presente, especifica a hora da conexão - hora atual. Ele é codificado como propriedade de usuário do time tipo no CONNECT pacote.
  • sas-expiry Define o tempo de expiração para a autenticação. É uma timepropriedade de usuário -typed no CONNECT pacote. Esta propriedade é necessária.

Para parâmetros opcionais, se omitida, a string vazia DEVE ser usada em vez disso na string para assinar.

O HMAC-SHA256 é utilizado para criar um hash da cadeia com base numa das chaves simétricas do dispositivo. Em seguida, o valor hash é definido como valor da propriedade Authentication Data.

X509

Se Authentication Method a propriedade estiver definida como X509, o Hub IoT autenticará a conexão com base no certificado de cliente fornecido.

Reautenticação

Se a autenticação baseada em SAS for usada, recomendamos o uso de tokens de autenticação de curta duração. Para manter a conexão autenticada e evitar a desconexão devido à expiração, o cliente deve autenticar novamente enviando AUTH o pacote com Reason Code: 0x19 (reautenticação):

-> AUTH
    Reason_Code: 0x19
    Authentication_Method: SAS
    Authentication_Data: {SAS bytes}
    sas-at: {current time}
    sas-expiry: {SAS expiry time}

Regras:

  • Authentication Method deve ser o mesmo que o usado para autenticação inicial
  • se a conexão foi originalmente autenticada usando SAS com base na Política de Acesso Compartilhado, a assinatura usada na reautenticação deve ser baseada na mesma política.

Se a reautenticação for bem-sucedida, o Hub IoT enviará AUTH o pacote com Reason Code: 0x00 (êxito). Caso contrário, o Hub IoT envia DISCONNECT o pacote com Reason Code: 0x87 (Não autorizado) e fecha a conexão.

Desconexão

O servidor pode desconectar o cliente por alguns motivos, incluindo:

  • o cliente se comporta mal de uma forma que é impossível de responder com reconhecimento (ou resposta) negativa diretamente,
  • o servidor não consegue manter o estado da conexão atualizado,
  • Outro cliente se conecta com a mesma identidade.

O servidor pode se desconectar com qualquer código de motivo definido na especificação MQTT 5.0. Menções notáveis:

  • 135 (Não autorizado) quando a reautenticação falha, o token SAS atual expira ou as credenciais do dispositivo são alteradas.
  • 142 (Sessão assumida) quando uma nova conexão com a mesma identidade de cliente foi aberta.
  • 159 (Taxa de conexão excedida) quando a taxa de conexão para o hub IoT excede o limite.
  • 131 (Erro específico da implementação) é usado para quaisquer erros personalizados definidos nesta API. status e reason as propriedades são usadas para comunicar mais detalhes sobre a causa da desconexão (consulte Resposta para obter detalhes).

Operações

Todas as funcionalidades desta API são expressas como operações. Aqui está um exemplo da operação de Telemetria de Envio:

-> PUBLISH
    QoS: 1
    Packet_Id: 3
    Topic: $iothub/telemetry
    Payload: Hello

<- PUBACK
    Packet_Id: 3
    Reason_Code: 0

Para obter a especificação completa das operações nesta API, consulte Referência da API MQTT 5 do plano de dados do Hub IoT.

Nota

Todas as amostras nesta especificação são mostradas da perspetiva do cliente. Sinal -> significa cliente enviando pacote, <- - recebendo.

Tópicos de mensagens e subscrições

Os tópicos usados nas mensagens das operações nesta API começam com $iothub/. A semântica do broker MQTT não se aplica a essas operações (consulte "Tópicos começando com $" para obter detalhes). Não há suporte para tópicos que começam com $iothub/ não definidos nesta API:

  • O envio de mensagens para tópicos indefinidos resulta em Not Found resposta (consulte Resposta para obter detalhes),
  • A assinatura de um tópico indefinido resulta em SUBACK ( Reason Code: 0x8F Filtro de tópico inválido).

Os nomes de tópicos e de propriedades diferenciam maiúsculas de minúsculas e devem corresponder exatamente. Por exemplo, $iothub/telemetry/ não é suportado enquanto $iothub/telemetry está.

Nota

Não há suporte para curingas em assinaturas $iothub/.. . Ou seja, um cliente não pode subscrever $iothub/+ ou $iothub/#. A tentativa de fazê-lo resulta em SUBACKReason Code: 0xA2 (Subscrições curinga não suportadas). Somente curingas de segmento único (+) são suportados em vez de parâmetros de caminho no nome do tópico para operações que os possuem.

Tipos de interação

Todas as operações nesta API são baseadas em um dos dois tipos de interação:

  • Mensagem com confirmação opcional (MessageAck)
  • Solicitação-resposta (ReqRep)

As operações também variam de acordo com a direção (determinada pela direção da mensagem inicial em troca):

  • Cliente-para-Servidor (c2s)
  • Servidor para cliente (s2c)

Por exemplo, Enviar Telemetria é uma operação de Cliente para Servidor do tipo "Mensagem com confirmação", enquanto o Método Handle Direct é uma operação de Servidor para Cliente do tipo Solicitação-Resposta.

Interações de confirmação de mensagem

Mensagem com interação opcional de Confirmação (MessageAck) é expressa como uma troca de PUBLISH e PUBACK pacotes em MQTT. A confirmação é opcional e o remetente pode optar por não solicitá-la enviando PUBLISH o pacote com QoS: 0.

Nota

Se as propriedades no pacote precisarem PUBACK ser truncadas devido às Maximum Packet Size declaradas pelo cliente, o Hub IoT reterá tantas propriedades de Usuário quantas couber dentro do limite determinado. As propriedades do usuário listadas primeiro têm maior chance de serem enviadas do que as listadas posteriormente; Reason String propriedade tem a menor prioridade.

Exemplo de interação MessageAck simples

Mensagem:

PUBLISH
    QoS: 1
    Packet_Id: 34
    Topic: $iothub/{request.path}
    Payload: <any>

Agradecimento (sucesso):

PUBACK
    Packet_Id: 34
    Reason_Code: 0

Interações Solicitação-Resposta

Nas interações Request-Response (ReqRep), Request e Response se traduzem em PUBLISH pacotes com QoS: 0.

Correlation Data deve ser definida em ambos e é usada para corresponder o pacote de resposta ao pacote de solicitação.

Essa API usa um único tópico $iothub/responses de resposta para todas as operações ReqRep. Não é necessário subscrever/cancelar a subscrição deste tópico para operações cliente-servidor - o servidor assume que todos os clientes estão inscritos.

Exemplo de interação ReqRep simples

Pedido:

PUBLISH
    QoS: 0
    Topic: $iothub/{request.path}
    Correlation_Data: 0x01 0xFA
    Payload: ...

Resposta (sucesso):

PUBLISH
    QoS: 0
    Topic: $iothub/responses
    Correlation_Data: 0x01 0xFA
    Payload: ...

As interações do ReqRep não suportam PUBLISH pacotes com QoS: 1 mensagens como solicitação ou resposta. O envio de Pedidos PUBLISH resulta em Bad Request resposta.

O comprimento máximo suportado na Correlation Data propriedade é de 16 bytes. Se Correlation Data a propriedade no PUBLISH pacote estiver definida como um valor maior que 16 bytes, o Hub IoT enviará DISCONNECT com Bad Request resultado e fechará a conexão. Esse comportamento só se aplica a pacotes trocados dentro dessa API.

Nota

Dados de correlação são uma sequência de bytes arbitrária, por exemplo, não é garantido que seja uma cadeia de caracteres UTF-8.

ReqRep usar tópicos predefinidos para resposta; A propriedade Response Topic no pacote Request PUBLISH (se definido pelo remetente) é ignorada.

O Hub IoT inscreve automaticamente o cliente para tópicos de resposta para todas as operações ReqRep cliente-servidor. Mesmo que o cliente cancele explicitamente a inscrição do tópico de resposta, o Hub IoT restabelece a assinatura automaticamente. Para interações ReqRep de servidor para cliente, ainda é necessário que o dispositivo se inscreva.

Propriedades da mensagem

As propriedades de operação - definidas pelo sistema ou pelo usuário - são expressas como propriedades de pacote no MQTT 5.

Os nomes de propriedade do usuário diferenciam maiúsculas de minúsculas e devem ser escritos exatamente como definido. Por exemplo, Trace-ID não é suportado enquanto trace-id está.

Solicitações com propriedades de usuário fora da especificação e sem prefixo @ resultam em erro.

As propriedades do sistema são codificadas como propriedades de primeira classe (por exemplo, Content Type) ou como propriedades de usuário. A especificação fornece uma lista exaustiva das propriedades do sistema suportadas. Todas as propriedades de primeira classe são ignoradas, a menos que o suporte para elas seja explicitamente declarado na especificação.

Quando as propriedades definidas pelo usuário são permitidas, seus nomes devem seguir o formato @{property name}. As propriedades definidas pelo usuário suportam apenas valores de cadeia de caracteres UTF-8 válidos. por exemplo, MyProperty1 a propriedade com valor 15 deve ser codificada como propriedade User com nome @MyProperty e valor 15.

Se o Hub IoT não reconhecer a propriedade do Usuário, isso será considerado um erro, e o Hub IoT responderá com PUBACKReason Code: 0x83 (Erro específico da implementação) e status: 0100 (Solicitação incorreta). Se a confirmação não foi solicitada (QoS: 0), DISCONNECT o pacote com o mesmo erro é enviado de volta e a conexão é encerrada.

Esta API define os seguintes tipos de dados além de string:

  • time: número de milissegundos desde 1970-01-01T00:00:00.000Z. por exemplo, 1600987195320 para 2020-09-24T22:39:55.320Z,
  • u32: número inteiro de 32 bits não assinado,
  • u64: número inteiro de 64 bits não assinado,
  • i32: número inteiro de 32 bits assinado.

Response

As interações podem resultar em resultados diferentes: Success, Bad Request, Not Found, e outros. Os resultados são diferenciados entre si pela status propriedade do usuário. Reason Code em PUBACK pacotes (para interações MessageAck) corresponde status em significado sempre que possível.

Nota

Se o cliente especificar Request Problem Information: 0 no pacote CONNECT, nenhuma propriedade de usuário será enviada em PUBACK pacotes para cumprir com a especificação MQTT 5, incluindo status a propriedade. Neste caso, o cliente ainda pode confiar para Reason Code determinar se o reconhecimento é positivo ou negativo.

Toda interação tem um padrão (ou sucesso). Tem Reason Code de 0 e status propriedade de "não definido". Otherwise:

  • Para interações MessageAck, PUBACK obtém Reason Code diferente de 0x0 (Sucesso). status propriedade pode estar presente para esclarecer melhor o resultado.
  • Para interações ReqRep, Response PUBLISH obtém status a propriedade definida.
  • Como não há como responder diretamente às interações do QoS: 0 MessageAck, DISCONNECT o pacote é enviado com informações de resposta, seguido de desconexão.

Exemplos:

Solicitação incorreta (MessageAck):

PUBACK
    Reason_Code: 131
    status: 0100
    reason: Unknown property `test`

Não autorizado (MessageAck):

PUBACK
    Reason_Code: 135
    status: 0101

Não autorizado (ReqRep):

PUBLISH
    QoS: 0
    Topic: $iothub/responses
    Correlation_Data: ...
    status: 0101

Quando necessário, o Hub IoT define as seguintes propriedades de usuário:

  • status - Código estendido do IoT Hub para o status da operação. Este código pode ser usado para diferenciar resultados.
  • trace-id – ID de rastreio da operação; O Hub IoT pode manter mais diagnósticos sobre a operação que poderiam ser usados para investigação interna.
  • reason - Mensagem legível por pessoas com mais informações sobre o motivo pelo qual a operação foi parar em um estado indicado pela status propriedade.

Nota

Se o cliente definir Maximum Packet Size a propriedade no pacote CONNECT para um valor muito pequeno, nem todas as propriedades do usuário podem caber e não apareceriam no pacote.

reason destina-se apenas a pessoas e não deve ser usado na lógica do cliente. Esta API permite que as mensagens sejam alteradas a qualquer momento sem aviso ou mudança de versão.

Se o cliente enviar RequestProblemInformation: 0 o pacote CONNECT, as propriedades do usuário não serão incluídas nas confirmações de acordo com a especificação MQTT 5.

Código de estado

status property carrega o código de status para a operação. É otimizado para eficiência de leitura de máquina. Ele consiste em dois bytes inteiros não assinados codificados como hexadecimal em cadeia de caracteres como 0501. Estrutura do código (mapa de bits):

7 6 5 4 3 2 1 0 | 7 6 5 4 3 2 1 0
0 0 0 0 0 R T T | C C C C C C C C

O primeiro byte é usado para sinalizadores:

  • Os bits 0 e 1 indicam o tipo de resultados:
    • 00 - sucesso
    • 01 - erro do cliente
    • 10 - erro do servidor
  • Bit 2: 1 indica que o erro pode ser repetido
  • Os bits 3 a 7 são reservados e devem ser definidos como 0

O segundo byte contém código de resposta distinto real. Códigos de erro com sinalizadores diferentes podem ter o mesmo valor de segundo byte. Por exemplo, pode haver 0001, 0101, 0201, códigos 0301 de erro com significado distinto.

Por exemplo, Too Many Requests é um cliente, erro retryable com o próprio código de 1. Seu valor é 0000 0101 0000 0001 ou 0x0501.

Os clientes podem usar bits de tipo para identificar se a operação foi concluída com êxito. Os clientes também podem usar bit retryable para decidir se é sensato repetir a operação.

Recomendações

Gestão de sessões

CONNACK packet carrega Session Present a propriedade para indicar se o servidor restaurou a sessão criada anteriormente. Use essa propriedade para descobrir se deseja assinar tópicos ou ignorar a assinatura, já que a assinatura foi feita anteriormente.

Para confiar no Session Present, o cliente deve acompanhar as assinaturas feitas (ou seja, pacote enviado SUBSCRIBE e recebido SUBACK com código de motivo bem-sucedido), ou certificar-se de assinar todos os tópicos em uma única SUBSCRIBE/SUBACK troca. Caso contrário, se o cliente envia dois SUBSCRIBE pacotes e o servidor processa apenas um deles com êxito, o servidor se comunica Session Present: 1 enquanto CONNACK tem apenas parte das assinaturas do cliente aceitas.

Para evitar o caso em que uma versão mais antiga do cliente não se inscreveu em todos os tópicos, é melhor se inscrever incondicionalmente quando o comportamento do cliente muda (por exemplo, como parte da atualização de firmware). Além disso, para garantir que nenhuma assinatura obsoleta seja deixada para trás (tirando do número máximo permitido de assinaturas), cancele explicitamente a assinatura de assinaturas que não estão mais em uso.

Criação de batches

Não há um formato especial para enviar um lote de mensagens. Para reduzir a sobrecarga de operações com uso intensivo de recursos em TLS e rede, agrupe pacotes (PUBLISH, PUBACK, SUBSCRIBE, e assim por diante) juntos antes de entregá-los à pilha TLS/TCP subjacente. Além disso, o cliente pode facilitar o alias de tópico dentro do "lote":

  • Coloque o nome completo do tópico no primeiro PUBLISH pacote para a conexão e associe o alias do tópico a ele,
  • Coloque os seguintes pacotes para o mesmo tópico com nome de tópico vazio e propriedade alias de tópico.

Migração

Esta seção lista as alterações na API em comparação com o suporte MQTT anterior.

  • O protocolo de transporte é MQTT 5. Anteriormente - MQTT 3.1.1.
  • As informações de contexto para a Autenticação SAS estão contidas no pacote diretamente, CONNECT em vez de serem codificadas junto com a assinatura.
  • O Método de Autenticação é usado para indicar o método de autenticação usado.
  • A Assinatura de Acesso Compartilhado é colocada na propriedade Dados de Autenticação. Anteriormente foi utilizado o campo Senha.
  • Os tópicos para operações são diferentes:
    • Telemetria: $iothub/telemetry em vez de devices/{Client Id}/messages/events,
    • Comandos: $iothub/commands em vez de devices/{Client Id}/messages/devicebound,
    • Patch Twin Relatado: $iothub/twin/patch/reported em vez de $iothub/twin/PATCH/properties/reported,
    • Notificar o estado desejado gêmeo alterado: $iothub/twin/patch/desired em vez de $iothub/twin/PATCH/properties/desired.
  • A assinatura do tópico de resposta das operações de solicitação-resposta cliente-servidor não é necessária.
  • As propriedades do usuário são usadas em vez de propriedades de codificação no segmento de nome do tópico.
  • Os nomes de propriedade são escritos na convenção de nomenclatura "dash-case" em vez de abreviaturas com prefixo especial. As propriedades definidas pelo usuário agora exigem prefixo. Por exemplo, $.mid é agora message-id, enquanto myProperty1 se torna @myProperty1.
  • A propriedade Correlation Data é usada para correlacionar mensagens de solicitação e resposta para operações de solicitação-resposta em vez da propriedade codificada $rid no tópico.
  • iothub-connection-auth-method propriedade não é mais estampada em eventos de telemetria.
  • Os comandos C2D não são limpos na ausência de assinatura do dispositivo. Eles permanecem na fila até que o dispositivo se inscreva ou expire.

Exemplos

Enviar telemetria

Mensagem:

-> PUBLISH
    QoS: 1
    Packet_Id: 31
    Topic: $iothub/telemetry
    @myProperty1: My String Value # optional
    creation-time: 1600987195320 # optional
    @ No_Rules-ForUser-PROPERTIES: Any UTF-8 string value # optional
    Payload: <data>

Agradecimento:

<- PUBACK
    Packet_Id: 31
    Reason_Code: 0

Reconhecimento alternativo (acelerado):

<- PUBACK
    Packet_Id: 31
    Reason_Code: 151
    status: 0501

Enviar obter estado do gêmeo

Pedido:

-> PUBLISH
    QoS: 0
    Topic: $iothub/twin/get
    Correlation_Data: 0x01 0xFA
    Payload: <empty>

Resposta (sucesso):

<- PUBLISH
    QoS: 0
    Topic: $iothub/responses
    Correlation_Data: 0x01 0xFA
    Payload: <twin/desired state>

Resposta (não permitida):

<- PUBLISH
    QoS: 0
    Topic: $iothub/responses
    Correlation_Data: 0x01 0xFA
    status: 0102
    reason: Operation not allowed for `B2` SKU
    Payload: <empty>

Manipular chamada de método direto

Pedido:

<- PUBLISH
    QoS: 0
    Topic: $iothub/methods/abc
    Correlation_Data: 0x0A 0x10
    Payload: <data>

Resposta (sucesso):

-> PUBLISH
    QoS: 0
    Topic: $iothub/responses
    Correlation_Data: 0x0A 0x10
    response-code: 200 # user defined response code
    Payload: <data>

Nota

status não está definido - é uma resposta de sucesso.

Resposta indisponível do dispositivo:

-> PUBLISH
    QoS: 0
    Topic: $iothub/responses
    Correlation_Data: 0x0A 0x10
    status: 0603

Erro ao usar QoS 0, parte 1

Pedido:

-> PUBLISH
    QoS: 0
    Topic: $iothub/twin/gett # misspelled topic name - server won't recognize it as Request-Response interaction
    Correlation_Data: 0x0A 0x10
    Payload: <data>

Resposta:

<- DISCONNECT
    Reason_Code: 144
    reason: "Unsupported topic: `$iothub/twin/gett`"

Erro ao usar QoS 0, parte 2

Pedido:

-> PUBLISH # missing Correlation Data
    QoS: 0
    Topic: $iothub/twin/get
    Payload: <data>

Resposta:

<- DISCONNECT
    Reason_Code: 131
    status: 0100
    reason: "`Correlation Data` property is missing"

Próximos passos