MQTT-funktioner som stöds av Azure Event Grids MQTT-koordinatorfunktion

  • Artikel

MQTT är ett transportprotokoll för meddelanden för publicering och prenumeration som har utformats för begränsade miljöer. Det är effektivt, skalbart och tillförlitligt, vilket gjorde det till guldstandarden för kommunikation i IoT-scenarier. MQTT Broker stöder klienter som publicerar och prenumererar på meddelanden via MQTT v3.1.1, MQTT v3.1.1 över WebSockets, MQTT v5 och MQTT v5 via WebSockets. MQTT Broker stöder även kommunikation mellan MQTT-versioner (MQTT 3.1.1 och MQTT 5).

MQTT v5 introducerade många förbättringar jämfört med MQTT v3.1.1 för att leverera en mer sömlös, transparent och effektiv kommunikation. Den lade till:

  • Bättre felrapportering.
  • Mer transparenta kommunikationsklienter via funktioner som användaregenskaper och innehållstyp.
  • Mer kontroll till klienter över kommunikationen via funktioner som meddelande och sessions förfallodatum.
  • Viktiga standardmönster som mönstret för begäran-svar.

Anslut ionsflöde:

Dina MQTT-klienter måste ansluta via TLS 1.2 eller TLS 1.3. Försök att hoppa över det här steget misslyckas med anslutningen.

När du ansluter till MQTT-asynkron meddelandekö använder du följande portar under kommunikationen via MQTT:

  • MQTT v3.1.1 och MQTT v5 på TCP-port 8883
  • MQTT v3.1.1 över WebSocket och MQTTv5 via WebSocket på TCP-port 443.

CONNECT-paketet bör innehålla följande egenskaper:

  • Fältet ClientId krävs och det bör innehålla sessionsnamnet för klienten. Sessionsnamnet måste vara unikt i namnområdet. Du kan använda namnet på klientautentiseringen som sessionsnamn om varje klient använder en session per klient. Om en klient använder flera sessioner måste den använda olika värden för ClientId för var och en av sina sessioner.
  • Fältet Användarnamn krävs om du inte valde ett värde i alternativeAuthenticationNameSources när namnområdet skapades. I så fall måste du ange klientens autentiseringsnamn i fältet Användarnamn. Det namnet måste matcha det angivna autentiseringsnamnet och värdet i klientens certifikatfält som angavs när klientresursen skapades.

Läs mer om klientautentisering.

Stöd för flera sessioner

Stöd för flera sessioner gör det möjligt för ditt program MQTT-klienter att ha en mer skalbar och tillförlitlig implementering genom att ansluta till MQTT Broker med flera aktiva sessioner samtidigt.

Namnområdeskonfiguration

Innan du använder den här funktionen måste du konfigurera namnområdet så att flera sessioner per klient tillåts. Använd följande steg för att konfigurera flera sessioner per klient i Azure-portalen:

  • Gå till ditt namnområde i Azure-portalen.
  • Under Konfiguration ändrar du värdet för Maximalt antal klientsessioner per autentiseringsnamn till önskat antal sessioner per klient.
  • Välj Använd.

Kommentar

För Azure CLI-konfigurationen uppdaterar du egenskapen MaxClientSessionsPerAuthenticationName i namnområdets nyttolast med önskat värde.

Anslut ionsflöde:

CONNECT-paketen för varje session bör innehålla följande egenskaper:

  • Ange egenskapen Användarnamn i CONNECT-paketet för att ange ditt klientautentiseringsnamn.
  • Ange egenskapen ClientID i CONNECT-paketet för att ange sessionsnamnet, till exempel att det finns ett eller flera värden för ClientID för varje användarnamn.

Följande kombinationer av Användarnamn och ClientIds i CONNECT-paketet gör det till exempel möjligt för klienten "Mgmt-application" att ansluta till MQTT-koordinatorn under tre oberoende sessioner:

  • Första sessionen:
    • Användarnamn: Mgmt-application
    • ClientId: Mgmt-Session1
  • Andra sessionen:
    • Användarnamn: Mgmt-application
    • ClientId: Mgmt-Session2
  • Tredje sessionen:
    • Användarnamn: Mgmt-application
    • ClientId: Mgmt-Session3

Diagram över ett exempel med flera sessioner.

Mer information finns i Så här upprättar du flera sessioner för en enskild klient.

Hanteringssessioner:

  • Om en klient försöker ta över en annan klients aktiva session genom att presentera sitt sessionsnamn med ett annat autentiseringsnamn avvisas anslutningsbegäran med ett obehörigt fel. Om till exempel klient B försöker ansluta till session 123 som är tilldelad vid den tidpunkten för klient A, avvisas klient B:s anslutningsbegäran. Med detta sagt, om samma klient försöker återansluta med samma sessionsnamn och samma autentiseringsnamn, kan den ta över sin befintliga session.
  • Om en klientresurs tas bort utan att sessionen avslutas kan andra klienter inte använda sitt sessionsnamn förrän sessionen upphör att gälla. Om klient B till exempel skapar en session med sessionsnamn 123 tas klient B bort, klient A kan inte ansluta till session 123 förrän den upphör att gälla.
  • Gränsen för antalet sessioner per klient gäller för online- och offlinesessioner när som helst. Anta till exempel att ett namnområde med maximalt antal klientsessioner per autentiseringsnamn är inställt på 1. Om klient A ansluter till en beständig session 123 och sedan kopplas från, kommer klient A inte att kunna ansluta till en ny session 456 eftersom dess session 123 fortfarande är aktiv även om den är offline. Därför rekommenderar vi att samma klient alltid återansluter med samma statiska sessionsnamn i stället för att generera ett nytt sessionsnamn med varje återanslutning.

MQTT-funktioner

Azure Event Grids MQTT-koordinatorfunktion stöder följande MQTT-funktioner:

Tjänstkvalitet (QoS)

MQTT Broker stöder QoS 0 och 1, som definierar garantin för meddelandeleverans på PUBLISH- och SUBSCRIBE-paket mellan klienter och MQTT-asynkron meddelandekö. QoS 0 garanterar högst en gång leverans; meddelanden med QoS 0 bekräftas inte av prenumeranten eller överförs på nytt av utgivaren. QoS 1 garanterar leverans minst en gång. meddelanden bekräftas av prenumeranten och överförs på nytt av utgivaren om de inte bekräftas. Med QoS kan dina klienter kontrollera effektiviteten och tillförlitligheten i kommunikationen.

Beständiga sessioner

MQTT Broker stöder beständiga sessioner för MQTT v3.1.1 så att MQTT-koordinatorn bevarar information om en klients session vid frånkopplingar för att säkerställa kommunikationens tillförlitlighet. Den här informationen omfattar klientens prenumerationer och missade/obemärkta QoS 1-meddelanden. Klienter kan konfigurera en beständig session genom att ange flaggan cleanSession i CONNECT-paketet till false.

Rensa start och sessionen upphör att gälla

MQTT v5 introducerade funktionerna för ren start och sessionsförfallotid som en förbättring jämfört med MQTT v3.1.1 i hanteringen av sessionspersistence. Clean Start är en funktion som gör att en klient kan starta en ny session med MQTT-koordinator och ta bort alla tidigare sessionsdata. Med sessionsförfallodatum kan en klient informera MQTT-asynkron meddelandekö när en inaktiv session anses ha upphört att gälla och tas bort automatiskt. I CONNECT-paketet kan en klient ställa in flaggan Ren start på sant och/eller kort sessions förfallointervall av säkerhetsskäl eller för att undvika eventuella datakonflikter som kan ha inträffat under föregående session. En klient kan också ange en ren start till falskt och/eller långt sessionsintervall för att säkerställa tillförlitligheten och effektiviteten för beständiga sessioner.

Maximal konfiguration av förfallointervall för sessionen

Du kan konfigurera det maximala sessionsintervallet som tillåts för alla klienter som ansluter till Event Grid-namnområdet. För MQTT v3.1.1-klienter tillämpas den konfigurerade gränsen som standardintervall för sessionsförfallodatum för alla beständiga sessioner. För MQTT v5-klienter tillämpas den konfigurerade gränsen som det maximala värdet för egenskapen Sessionsförfallointervall i CONNECT-paketet. alla värden som överskrider gränsen justeras. Standardvärdet för den här namnområdesegenskapen är 1 timme och kan utökas upp till 8 timmar. Använd följande steg för att konfigurera det maximala sessionsintervallet för förfallodatum i Azure-portalen:

  • Gå till ditt namnområde i Azure-portalen.
  • Under Konfiguration ändrar du värdet för maximalt sessionsförfallointervall i timmar till önskad gräns.
  • Välj Använd.

skärmbild för konfiguration av maximalt sessionsintervall för förfallodatum.

Sessionsspill

MQTT Broker underhåller en kö med meddelanden för varje aktiv MQTT-session som inte är ansluten tills klienten ansluter med MQTT-asynkron meddelandekö igen för att ta emot meddelandena i kön. Om en klient inte ansluter för att ta emot de köade QOS1-meddelandena börjar sessionskön ackumulera meddelandena tills den når sin gräns: 100 meddelanden eller 1 MB. När kön når sin gräns under sessionens livslängd avslutas sessionen.

Meddelanden från Last Will och Testamente (LWT) (förhandsversion)

Last Will and Testament (LWT) meddelar dina MQTT-klienter med plötsliga frånkopplingar av andra MQTT-klienter. Du kan använda LWT för att säkerställa förutsägbart och tillförlitligt kommunikationsflöde mellan MQTT-klienter under oväntade frånkopplingar, vilket är värdefullt för scenarier där kommunikation i realtid, systemtillförlitlighet och samordnade åtgärder är viktiga. Klienter som samarbetar för att utföra komplexa uppgifter kan reagera på LWT-meddelanden från varandra genom att justera deras beteende, omdistribuera uppgifter eller ta över vissa ansvarsområden för att upprätthålla systemets prestanda och stabilitet. Om du vill använda LWT kan en klient ange meddelandet will, will och resten av will-egenskaperna i CONNECT-paketet under anslutningen. När klienten plötsligt kopplas från publicerar MQTT-asynkron meddelandemeddelandet till alla klienter som prenumererar på will-ämnet.

Användaregenskaper

MQTT Broker stöder användaregenskaper på MQTT v5 PUBLISH-paket som gör att du kan lägga till anpassade nyckel/värde-par i meddelandehuvudet för att ge mer kontext om meddelandet. Användningsfallen för användaregenskaper är mångsidiga. Du kan använda den här funktionen för att inkludera syftet med eller ursprunget för meddelandet så att mottagaren kan hantera meddelandet utan att parsa nyttolasten och spara databehandlingsresurser. Ett meddelande med en användaregenskap som anger dess syfte som en "varning" kan till exempel utlösa en annan hanteringslogik än ett med syftet "information".

Mönster för begärandesvar

MQTTv5 introducerade fält i MQTT PUBLISH-paketrubriken som ger kontext för svarsmeddelandet i mönstret för begäran-svar. De här fälten innehåller ett svarsämne och ett korrelations-ID som svararen kan använda i svaret utan föregående konfiguration. Svarsinformationen möjliggör effektivare kommunikation för standardmönstret för begäran-svar som används i kommando- och kontrollscenarier.

Diagram över exemplet med mönster för begäran-svar.

Meddelande förfallointervall:

I MQTT v5 tillåter meddelandeförfallointervall att meddelanden har en konfigurerbar livslängd. Förfallointervallet för meddelandet definieras som tidsintervallet mellan den tid då ett meddelande publiceras till MQTT-asynkron meddelandekö och den tid då MQTT-asynkron meddelandekö måste ignorera det olevererade meddelandet. Den här funktionen är användbar i scenarier där meddelanden endast är giltiga under en viss tid, till exempel tidskänsliga kommandon, dataströmning i realtid eller säkerhetsaviseringar. Genom att ange ett intervall för meddelandeförfallodatum kan MQTT-asynkron meddelandekö automatiskt ta bort inaktuella meddelanden, vilket säkerställer att endast relevant information är tillgänglig för prenumeranter. Om ett meddelandes förfallointervall är inställt på noll innebär det att meddelandet aldrig ska upphöra att gälla.

Ämnesalias:

I MQTT v5 tillåter ämnesalias att en klient använder ett kortare alias i stället för det fullständiga ämnesnamnet i det publicerade meddelandet. MQTT Broker upprätthåller en mappning mellan ämnesaliaset och det faktiska ämnesnamnet. Den här funktionen kan spara nätverksbandbredd och minska storleken på meddelanderubriken, särskilt för ämnen med långa namn. Det är användbart i scenarier där samma ämne publiceras upprepade gånger i flera meddelanden, till exempel i sensornätverk. MQTT Broker stöder upp till 10 ämnesalias. En klient kan använda ett ämnesaliasfält i PUBLISH-paketet för att ersätta det fullständiga ämnesnamnet med motsvarande alias.

Diagram över ämnets aliasexempel.

Flödeskontroll

I MQTT v5 refererar flödeskontroll till mekanismen för att hantera hastigheten och storleken på meddelanden som en klient kan hantera. Flödeskontroll kan konfigureras genom att ange parametrarna Maximal paketstorlek och Ta emot maximalt i CONNECT-paketet. Med parametern Ta emot maximalt kan klienten begränsa antalet meddelanden som skickas av asynkron meddelandekö till det antal meddelanden som klienten kan hantera. Parametern Maximal paketstorlek definierar den maximala storleken på paket som klienten kan ta emot. MQTT-asynkron meddelandestorleksgräns är 512 KiB. Den här funktionen garanterar tillförlitlighet och stabilitet i kommunikationen för begränsade enheter med begränsad bearbetningshastighet eller lagringsfunktioner.

Negativa bekräftelser och serverinitierat frånkopplingspaket

För MQTT v5 kan MQTT-koordinatorn skicka negativa bekräftelser (NACK:er) och serverinitierade frånkopplingspaket som ger klienten mer information om fel vid meddelandeleverans eller anslutning. Dessa funktioner hjälper klienten att diagnostisera orsaken bakom ett fel och vidta lämpliga åtgärder för att mildra problemet. MQTT-koordinatorn använder de orsakskoder som definieras i MQTT v5-specifikationen.

Aktuella begränsningar

MQTT Broker lägger till fler MQTT v5- och MQTT v3.1.1-funktioner i framtiden för att anpassa sig mer till MQTT-specifikationerna. I följande lista beskrivs de aktuella skillnaderna mellan funktioner som stöds av MQTT-koordinatorn och MQTT-specifikationerna:

Aktuella begränsningar för MQTTv5

MQTT v5 skiljer sig för närvarande från MQTT v5-specifikationen på följande sätt:

  • Delade prenumerationer stöds inte ännu.
  • Kvarhållningsflaggan stöds inte än.
  • Fördröjningsintervallet stöds inte ännu.
  • Högsta QoS är 1.
  • Maximal paketstorlek är 512 KiB
  • Meddelandeordning är inte garanterad.
  • Prenumerationsidentifierare stöds inte.
  • Tilldelade klientidentifierare stöds inte ännu.
  • Maximalt ämnesalias är 10. Servern tilldelar för närvarande inga ämnesalias för utgående meddelanden. Klienter kan tilldela och använda ämnesalias inom den angivna gränsen.
  • CONNACK returnerar inte egenskapen Svarsinformation även om CONNECT-begäran innehåller egenskapen Begärandesvarsinformation.
  • Användaregenskaper på CONNECT-, SUBSCRIBE-, DISCONNECT-, PUBACK- och AUTH-paket används inte av tjänsten så de stöds inte. Om någon av dessa begäranden innehåller användaregenskaper misslyckas begäran.
  • Om servern tar emot en PUBACK från en klient med svarskod som inte lyckades avslutas anslutningen.
  • Keep Alive Maximum är 1 160 sekunder.

Aktuella begränsningar för MQTTv3.1.1

MQTT v5 skiljer sig för närvarande från MQTT v3.1.1-specifikationen på följande sätt:

  • QoS2- och Retain-flaggan stöds inte ännu. En publiceringsbegäran med en kvarhållningsflagga eller med en QoS2 misslyckas och stänger anslutningen.
  • Meddelandeordning är inte garanterad.
  • Keep Alive Maximum är 1 160 sekunder.

Kodexempel:

Den här lagringsplatsen innehåller C#-, C- och Python-kodexempel som visar hur du skickar telemetri, skickar kommandon och skickar aviseringar. Certifikaten som skapas via exemplen är lämpliga för testning, men de passar inte för produktionsmiljöer.

Nästa steg:

Läs mer om MQTT:

Läs mer om MQTT-koordinator: