Funzionalità MQTT supportate dalla funzionalità Broker MQTT di Griglia di eventi di Azure

MQTT è un protocollo di trasporto di messaggistica pubblicazione-sottoscrizione concepito per ambienti vincolati. È efficiente, scalabile e affidabile e ciò lo rende lo standard aureo per la comunicazione negli scenari IoT. Broker MQTT supporta client che pubblicano e sottoscrivono messaggi tramite MQTT v3.1.1, MQTT v3.1.1 tramite WebSockets, MQTT v5 e MQTT v5 tramite WebSockets. Broker MQTT supporta anche la comunicazione incrociata della versione MQTT (MQTT 3.1.1 e MQTT 5).

MQTT v5 ha introdotto molti miglioramenti rispetto a MQTT v3.1.1 per offrire una comunicazione più semplice, trasparente ed efficiente. È stato aggiunto:

• Migliore segnalazione di errori.
• Client di comunicazione più trasparenti tramite funzionalità come le proprietà utente e il tipo di contenuto.
• Maggiore controllo per i client sulla comunicazione tramite funzionalità come la scadenza del messaggio e della sessione.
• Criteri importanti standard come il criterio di richiesta-risposta.

Flusso di connessione:

I client MQTT devono connettersi tramite TLS 1.2 o TLS 1.3, altrimenti si verificheranno errori di connessione.

Durante la connessione al Broker MQTT, usare le porte seguenti durante la comunicazione tramite MQTT:

• MQTT v3.1.1 e MQTT v5 sulla porta TCP 8883
• MQTT v3.1.1 su WebSocket e MQTTv5 su WebSocket sulla porta TCP 443.

Il pacchetto CONNECT deve includere le proprietà seguenti:

• Il campo ClientId è obbligatorio e deve includere il nome della sessione del client. Il nome della sessione deve essere univoco nello spazio dei nomi. È possibile usare il nome di autenticazione client come nome di sessione se ogni client usa una sessione per client. Se un client usa più sessioni, deve usare valori diversi per ClientId per ciascuna sessione.
• Il campo Nome utente è obbligatorio se non è stato selezionato un valore in alternativeAuthenticationNameSources durante la creazione dello spazio dei nomi. In tal caso, è necessario specificare il nome di autenticazione del client nel campo Nome utente. Tale nome deve corrispondere al nome di autenticazione specificato e al valore nel campo del certificato del client specificato durante la creazione della risorsa client.

Altre informazioni sull'autenticazione client.

Supporto multisessione

Il supporto multisessione consente ai client MQTT dell'applicazione di avere un'implementazione più scalabile e affidabile connettendosi al Broker MQTT con più sessioni attive contemporaneamente.

Configurazione dello spazio dei nomi

Prima di usare questa funzionalità, è necessario configurare lo spazio dei nomi per consentire più sessioni per client. Eseguire i passaggi seguenti per configurare più sessioni per client nel portale di Azure:

• Passare allo spazio dei nomi nel portale di Azure.
• In Configurazione modificare il valore del Numero massimo di sessioni client per nome di autenticazione impostando il numero di sessioni desiderate per client.
• Seleziona Applica.

Nota

Per la configurazione dell'interfaccia della riga di comando di Azure, aggiornare la proprietà MaxClientSessionsPerAuthenticationName nel payload dello spazio dei nomi con il valore desiderato.

Flusso di connessione:

I pacchetti CONNECT per ciascuna sessione devono includere le proprietà seguenti:

• Specificare la proprietà Nome utente nel pacchetto CONNECT per indicare il nome di autenticazione client.
• Specificare la proprietà ClientID nel pacchetto CONNECT per indicare il nome della sessione, ad esempio uno o più valori per ClientID per ogni nome utente.

Ad esempio, le combinazioni seguenti di Nome utente e ClientId nel pacchetto CONNECT consentono a "Mgmt-application" del client di connettersi al Broker MQTT su tre sessioni indipendenti:

• Prima sessione:
  • Nome utente: Mgmt-application
  • ClientId: Mgmt-Session1
• Seconda sessione:
  • Nome utente: Mgmt-application
  • ClientId: Mgmt-Session2
• Terza sessione:
  • Nome utente: Mgmt-application
  • ClientId: Mgmt-Session3

Per altre informazioni, vedere Come stabilire più sessioni per un solo client.

Gestione delle sessioni:

• Se un client tenta di assumere la sessione attiva di un altro client presentando il nome della sessione con un nome di autenticazione diverso, la richiesta di connessione viene rifiutata con un errore non autorizzato. Ad esempio, se il client B tenta di connettersi alla sessione 123 assegnata in quel momento al client A, la richiesta di connessione del client B viene rifiutata. Detto questo, se lo stesso client tenta di riconnettersi con gli stessi nomi di sessione e lo stesso nome di autenticazione, è in grado di assumere il controllo della sessione esistente.
• Se una risorsa client viene eliminata senza terminare la sessione, altri client non possono usare il nome della sessione fino alla scadenza della sessione stessa. Ad esempio, se il client B crea una sessione con nome di sessione 123 e poi il client B viene eliminato, il client A non può connettersi alla sessione 123 fino alla scadenza.
• Il limite del numero di sessioni per client si applica alle sessioni online e offline in qualsiasi momento. Si consideri ad esempio uno spazio dei nomi con il numero massimo di sessioni client per nome di autenticazione impostato su 1. Se il client A si connette con una sessione permanente 123 e poi viene disconnesso, il client A non sarà in grado di connettersi con una nuova sessione 456 perché la sessione 123 è ancora attiva anche se è offline. Di conseguenza, è consigliabile riconnettere sempre lo stesso client con gli stessi nomi di sessione statici anziché generare un nuovo nome di sessione a ogni riconnessione.

Funzionalità di MQTT

La funzionalità Broker MQTT di Griglia di eventi di Azure supporta le seguenti funzionalità di MQTT:

Qualità del servizio (QoS)

Broker MQTT supporta QoS 0 e 1, che definiscono la garanzia di recapito dei messaggi nei pacchetti PUBLISH e SUBSCRIBE tra client e Broker MQTT. QoS 0 garantisce la consegna al massimo una volta; i messaggi con QoS 0 non vengono riconosciuti dal sottoscrittore, né vengono ritrasmessi dal server di pubblicazione. QoS 1 garantisce la consegna almeno una volta; i messaggi vengono riconosciuti dal sottoscrittore e vengono ritrasmessi dal server di pubblicazione se non sono stati riconosciuti. QoS 0 consente ai client di controllare l'efficienza e l'affidabilità della comunicazione.

Sessioni persistenti

Broker MQTT supporta sessioni persistenti per MQTT v3.1.1 in modo che il Broker MQTT mantenga le informazioni sulla sessione di un client in caso di disconnessioni, per garantire l'affidabilità della comunicazione. Tali informazioni includono le sottoscrizioni del client e i messaggi QoS 1 non eseguiti/non riconosciuti. I client possono configurare una sessione persistente impostando il flag cleanSession nel pacchetto CONNECT su false.

Avvio pulito e scadenza della sessione

MQTT v5 ha introdotto le funzionalità di avvio pulito e scadenza della sessione come miglioramento rispetto a MQTT v3.1.1 nella gestione della persistenza della sessione. Avvio pulito è una funzionalità che consente a un client di avviare una nuova sessione con il Broker MQTT, rimuovendo eventuali dati di sessione precedenti. La scadenza della sessione consente a un client di informare il Broker MQTT quando una sessione inattiva viene considerata scaduta e viene rimossa automaticamente. Nel pacchetto CONNECT un client può impostare il flag di avvio pulito su true e/o un intervallo di scadenza della sessione breve per motivi di sicurezza o per evitare potenziali conflitti di dati che potrebbero essersi verificati durante la sessione precedente. Un client può anche impostare un avvio pulito su false e/o un intervallo di scadenza della sessione lungo per garantire l'affidabilità e l'efficienza delle sessioni persistenti.

Configurazione dell'intervallo massimo di scadenza della sessione

È possibile configurare l'intervallo massimo di scadenza della sessione consentito per tutti i client che si connettono allo spazio dei nomi Griglia di eventi. Per i client MQTT v3.1.1, il limite configurato viene applicato come intervallo di scadenza della sessione predefinito per tutte le sessioni persistenti. Per i client MQTT v5, il limite configurato viene applicato come valore massimo per la proprietà Intervallo di scadenza sessione nel pacchetto CONNECT; gli eventuali valori che superano il limite vengono modificati. Il valore predefinito per questa proprietà dello spazio dei nomi è di 1 ora e può essere esteso fino a 8 ore. Usare la procedura seguente per configurare l'intervallo massimo di scadenza della sessione nel portale di Azure:

• Passare allo spazio dei nomi nel portale di Azure.
• In Configurazione, modificare il valore di Intervallo massimo di scadenza della sessione in ore nel limite desiderato.
• Selezionare Applica.

Overflow della sessione

Broker MQTT gestisce una coda di messaggi per ogni sessione MQTT attiva non connessa, fino a quando il client non si connette nuovamente con il Broker MQTT per ricevere i messaggi in coda. Se un client non si connette per ricevere i messaggi QOS1 in coda, la coda di sessione inizia ad accumulare i messaggi fino a raggiungere il limite: 100 messaggi o 1 MB. Quando la coda raggiunge il limite durante la sessione, la sessione viene terminata.

Messaggi di Last Will and Testament (LWT, Testamento)

Last Will and Testament (LWT, Testamento) segnala ai client MQTT interruzioni improvvise di altri client MQTT. È possibile usare LWT per garantire un flusso di comunicazione prevedibile e affidabile tra i client MQTT in caso di disconnessioni impreviste, utile per gli scenari in cui le comunicazioni in tempo reale, l'affidabilità del sistema e le azioni coordinate sono fondamentali. I client che collaborano per eseguire attività complesse possono reagire ai messaggi LWT sull'altro client modificandone il comportamento, ridistribuendo le attività o assumendo determinate responsabilità per mantenere le prestazioni e la stabilità del sistema. Per usare LWT, un client può specificare il messaggio, l'argomento e il resto delle proprietà del testamento nel pacchetto CONNECT durante la connessione. Quando il client si disconnette improvvisamente, il Broker MQTT pubblica il messaggio di testamento per tutti i client che hanno sottoscritto l'argomento del testamento. Per ridurre i disagi dovuti alle disconnessioni fluttuanti, il client può impostare l'intervallo di ritardo del testamento su un valore maggiore di zero. In tal caso, se il client si disconnette bruscamente, ma esegue il ripristino della connessione prima della scadenza dell'intervallo di ritardo del testamento, il messaggio non viene pubblicato.

Proprietà utente

Broker MQTT supporta le proprietà utente nei pacchetti MQTT v5 PUBLISH che consentono di aggiungere coppie chiave-valore personalizzate nell'intestazione del messaggio per fornire un contesto più dettagliato sul messaggio. I casi d'uso per le proprietà utente sono versatili. È possibile usare questa funzionalità per includere lo scopo o l'origine del messaggio, in modo che il ricevitore possa gestire il messaggio senza analizzare il payload, risparmiando risorse di calcolo. Ad esempio, un messaggio con una proprietà utente che indica lo scopo di "avviso" potrebbe attivare una logica di gestione diversa da quella con lo scopo di "informazione".

Criterio richiesta-risposta

MQTTv5 ha introdotto i campi nell'intestazione del pacchetto MQTT PUBLISH che forniscono il contesto per il messaggio di risposta nel criterio richiesta-risposta. Questi campi includono un argomento di risposta e un ID di correlazione che il risponditore può usare nella risposta senza previa configurazione. Le informazioni sulla risposta consentono una comunicazione più efficiente per il criterio richiesta-risposta standard usato negli scenari di comando e controllo.

Intervallo di scadenza del messaggio:

In MQTT v5, l'intervallo di scadenza del messaggio consente ai messaggi di avere una durata configurabile. L'intervallo di scadenza del messaggio viene definito come l'intervallo di tempo tra il momento in cui un messaggio viene pubblicato nel Broker MQTT e quello in cui il Broker MQTT deve rimuovere il messaggio non recapitato. Questa funzionalità è utile negli scenari in cui i messaggi sono validi solo per un determinato intervallo di tempo, ad esempio comandi sensibili al tempo, flussi di dati in tempo reale o avvisi di sicurezza. Impostando un intervallo di scadenza del messaggio, il Broker MQTT può rimuovere automaticamente i messaggi obsoleti, assicurandosi che solo le informazioni rilevanti siano disponibili per i sottoscrittori. Se l'intervallo di scadenza di un messaggio è impostato su zero, significa che il messaggio non deve mai scadere.

Alias degli argomenti:

In MQTT v5 gli alias degli argomenti consentono a un client di usare un alias più breve al posto del nome completo dell'argomento nel messaggio pubblicato. Il Broker MQTT gestisce un mapping tra l'alias dell'argomento e il nome effettivo dell'argomento. Questa funzionalità consente di risparmiare larghezza di banda di rete e di ridurre le dimensioni dell'intestazione del messaggio, in particolare per gli argomenti con nomi lunghi. È utile negli scenari in cui lo stesso argomento viene pubblicato ripetutamente in più messaggi, ad esempio nelle reti del sensore. Broker MQTT supporta fino a 10 alias di argomento. Un client può usare un campo Alias di argomento nel pacchetto PUBLISH per sostituire il nome completo dell'argomento con l'alias corrispondente.

Controllo del flusso

In MQTT v5 il controllo del flusso fa riferimento al meccanismo per la gestione della frequenza e delle dimensioni dei messaggi da parte di un client. Il controllo del flusso può essere configurato impostando i parametri Dimensioni massime pacchetto e Ricezione massima nel pacchetto CONNECT. Il parametro Ricezione massima consente al client di limitare il numero di messaggi inviati dal broker al numero di messaggi che il client è in grado di gestire. Il parametro Dimensioni massime pacchetto definisce le dimensioni massime dei pacchetti che il client può ricevere. Broker MQTT ha un limite di dimensioni del messaggio pari a 512 KiB. Questa funzionalità garantisce affidabilità e stabilità della comunicazione per i dispositivi vincolati con velocità di elaborazione o funzionalità di archiviazione limitate.

Riconoscimenti negativi e pacchetto di disconnessione avviato dal server

Per MQTT v5, Broker MQTT è in grado di inviare riconoscimenti negativi (NACK) e pacchetti di disconnessione avviati dal server che forniscono al client ulteriori informazioni sugli errori di recapito o connessione dei messaggi. Queste funzionalità consentono al client di eseguire diagnosi per individuare il motivo di un errore ed eseguire azioni di prevenzione appropriate. Broker MQTT usa i codici motivo definiti nelle Specifiche MQTT v5.

Limitazioni correnti

Il broker MQTT aggiungerà altre funzionalità MQTT v5 e MQTT v3.1.1 in futuro per un maggiore allineamento alle specifiche MQTT. L'elenco seguente illustra in dettaglio le differenze attuali tra le funzionalità supportate dal Broker MQTT e le specifiche MQTT:

Limitazioni correnti di MQTT v5

MQTT v5 attualmente differisce dalle specifiche MQTT v5 su quanto segue:

• Le sottoscrizioni condivise non sono ancora supportate.
• Il flag di conservazione non è ancora supportato.
• L'intervallo massimo di ritardo del testamento è di 300.
• Il valore massimo di QoS è 1.
• La dimensione massima del pacchetto è 512 KiB
• L'ordinamento dei messaggi non è garantito.
• Gli identificatori di sottoscrizione non sono supportati.
• Gli identificatori client assegnati non sono ancora supportati.
• Il valore massimo dell'alias dell'argomento è 10. Al momento il server non assegna alias di argomento per i messaggi in uscita. I client possono assegnare e usare alias di argomento entro il limite impostato.
• CONNACK non restituisce la proprietà Response Information anche se la richiesta CONNECT contiene la proprietà Request Response Information.
• Le proprietà utente nei pacchetti CONNECT, SUBSCRIBE, DISCONNECT, PUBACK e AUTH non vengono usate dal servizio, perciò non sono supportate. Se una di queste richieste include proprietà utente, la richiesta ha esito negativo.
• Se il server riceve un PUBACK da un client con codice di risposta non riuscito, la connessione viene terminata.
• Il keep-alive massimo è di 1.160 secondi.

Limitazioni correnti di MQTT v3.1.1

MQTT v5 attualmente differisce dalle specifiche MQTT v3.1.1. su quanto segue:

• QoS2 e il flag di conservazione non sono ancora supportati. Una richiesta di pubblicazione con un flag di conservazione o con QoS2 ha esito negativo e chiude la connessione.
• L'ordinamento dei messaggi non è garantito.
• Il keep-alive massimo è di 1.160 secondi.

Esempi di codice:

Questo repository contiene esempi di codice C#, C e Python che illustrano come inviare dati di telemetria, inviare comandi e trasmettere avvisi. I certificati creati tramite gli esempi sono adatti per i test, ma non sono adatti per gli ambienti di produzione.

Passaggi successivi:

Altre informazioni su MQTT:

• Specifiche MQTT v3.1.1
• Specifiche MQTT v5

Altre informazioni sul Broker MQTT:

• Autenticazione client
• Come stabilire più sessioni per un solo client