Share via

MQTT-functies die worden ondersteund door de MQTT-brokerfunctie van Azure Event Grid

  • Artikel

MQTT is een berichtentransportprotocol voor publiceren-abonneren dat is ontworpen voor beperkte omgevingen. Het is efficiënt, schaalbaar en betrouwbaar, waardoor het de gouden standaard is voor communicatie in IoT-scenario's. MQTT Broker ondersteunt clients die berichten publiceren en abonneren op berichten via MQTT v3.1.1, MQTT v3.1.1 via WebSockets, MQTT v5 en MQTT v5 via WebSockets. MQTT Broker ondersteunt ook communicatie tussen MQTT-versies (MQTT 3.1.1 en MQTT 5).

MQTT v5 heeft veel verbeteringen geïntroduceerd ten opzichte van MQTT v3.1.1 om een naadloze, transparantere en efficiënte communicatie te bieden. Het is toegevoegd:

  • Betere foutrapportage.
  • Transparantere communicatieclients via functies zoals gebruikerseigenschappen en inhoudstype.
  • Meer controle over de communicatie tussen clients via functies zoals het verlopen van berichten en sessies.
  • Standaard belangrijke patronen, zoals het patroon aanvraagrespons.

Verbinding maken ionstroom:

Uw MQTT-clients moeten verbinding maken via TLS 1.2 of TLS 1.3. Pogingen om deze stap over te slaan, mislukken met verbinding.

Gebruik tijdens het maken van verbinding met MQTT Broker de volgende poorten tijdens de communicatie via MQTT:

  • MQTT v3.1.1 en MQTT v5 op TCP-poort 8883
  • MQTT v3.1.1 via WebSocket en MQTTv5 via WebSocket op TCP-poort 443.

Het CONNECT-pakket moet de volgende eigenschappen bevatten:

  • Het veld ClientId is vereist en moet de sessienaam van de client bevatten. De sessienaam moet uniek zijn in de naamruimte. U kunt de naam van de clientverificatie gebruiken als sessienaam als elke client één sessie per client gebruikt. Als één client meerdere sessies gebruikt, moet deze voor elk van de sessies verschillende waarden voor ClientId gebruiken.
  • Het veld Gebruikersnaam is vereist als u tijdens het maken van de naamruimte geen waarde hebt geselecteerd in de alternativeAuthenticationNameSources. In dat geval moet u de verificatienaam van uw client opgeven in het veld Gebruikersnaam. Deze naam moet overeenkomen met de opgegeven verificatienaam en de waarde in het certificaatveld van de client die is opgegeven tijdens het maken van de clientresource.

Meer informatie over clientverificatie.

Ondersteuning voor meerdere sessies

Dankzij ondersteuning voor meerdere sessies kan uw toepassing MQTT-clients schaalbare en betrouwbare implementaties hebben door verbinding te maken met MQTT-broker met meerdere actieve sessies tegelijk.

Naamruimteconfiguratie

Voordat u deze functie gebruikt, moet u de naamruimte configureren om meerdere sessies per client toe te staan. Gebruik de volgende stappen om meerdere sessies per client te configureren in Azure Portal:

  • Ga naar uw naamruimte in Azure Portal.
  • Wijzig onder Configuratie de waarde voor de maximale clientsessies per verificatienaam in het gewenste aantal sessies per client.
  • Selecteer Toepassen.

Notitie

Werk voor de Azure CLI-configuratie de eigenschap MaxClientSessionsPerAuthenticationName bij in de nettolading van de naamruimte met de gewenste waarde.

Verbinding maken ionstroom:

De CONNECT-pakketten voor elke sessie moeten de volgende eigenschappen bevatten:

  • Geef de eigenschap Gebruikersnaam op in het CONNECT-pakket om de naam van uw clientverificatie aan te geven.
  • Geef de eigenschap ClientID in het CONNECT-pakket op om de naam van de sessie aan te geven, zoals er een of meer waarden zijn voor de ClientID voor elke gebruikersnaam.

Met de volgende combinaties van gebruikersnaam en client-id's in het CONNECT-pakket kan de client 'Mgmt-application' bijvoorbeeld verbinding maken met MQTT-broker via drie onafhankelijke sessies:

  • Eerste sessie:
    • Gebruikersnaam: Mgmt-application
    • ClientId: Mgmt-Session1
  • Tweede sessie:
    • Gebruikersnaam: Mgmt-application
    • ClientId: Mgmt-Session2
  • Derde sessie:
    • Gebruikersnaam: Mgmt-application
    • ClientId: Mgmt-Session3

Diagram van een voorbeeld met meerdere sessies.

Zie Hoe u meerdere sessies tot stand brengt voor één client voor meer informatie .

Sessies verwerken:

  • Als een client probeert de actieve sessie van een andere client over te nemen door de sessienaam met een andere verificatienaam te presenteren, wordt de verbindingsaanvraag geweigerd met een niet-geautoriseerde fout. Als client B bijvoorbeeld verbinding probeert te maken met sessie 123 die op dat moment is toegewezen voor client A, wordt de verbindingsaanvraag van client B geweigerd. Als dezelfde client probeert opnieuw verbinding te maken met dezelfde sessienamen en dezelfde verificatienaam, kan deze de bestaande sessie overnemen.
  • Als een clientresource wordt verwijderd zonder de sessie te beëindigen, kunnen andere clients de sessienaam pas gebruiken als de sessie verloopt. Als client B bijvoorbeeld een sessie met sessienaam 123 maakt, wordt client B verwijderd, kan client A geen verbinding maken met sessie 123 totdat deze verloopt.
  • De limiet voor het aantal sessies per client is op elk gewenst moment van toepassing op online- en offlinesessies. Denk bijvoorbeeld aan een naamruimte met de maximale clientsessies per verificatienaam is ingesteld op 1. Als client A verbinding maakt met een permanente sessie 123 en vervolgens wordt verbroken, kan client A geen verbinding maken met een nieuwe sessie 456 omdat de sessie 123 nog steeds actief is, zelfs als deze offline is. Daarom raden we aan dat dezelfde client altijd opnieuw verbinding maakt met dezelfde statische sessienamen in plaats van een nieuwe sessienaam te genereren bij elke nieuwe verbinding.

MQTT-functies

De MQTT-brokerfunctie van Azure Event Grid ondersteunt de volgende MQTT-functies:

Quality of service (QoS)

MQTT Broker ondersteunt QoS 0 en 1, waarmee de garantie wordt gedefinieerd voor de levering van berichten op PUBLISH- en SUBSCRIBE-pakketten tussen clients en MQTT-broker. QoS 0 garandeert at-most-once levering; berichten met QoS 0 worden niet bevestigd door de abonnee en worden niet opnieuw verzonden door de uitgever. QoS 1 garandeert ten minste één levering; berichten worden bevestigd door de abonnee en worden opnieuw verzonden door de uitgever als ze niet zijn bevestigd. Met QoS kunnen uw klanten de efficiëntie en betrouwbaarheid van de communicatie beheren.

Permanente sessies

MQTT Broker ondersteunt permanente sessies voor MQTT v3.1.1, zodat MQTT-broker informatie over de sessie van een client behoudt in geval van verbroken verbindingen om de betrouwbaarheid van de communicatie te waarborgen. Deze informatie omvat de abonnementen van de client en gemiste/niet-bekende QoS 1-berichten. Clients kunnen een permanente sessie configureren door de vlag cleanSession in het CONNECT-pakket in te stellen op false.

Begin- en sessieverloop opschonen

MQTT v5 heeft de functies voor schone start- en sessieverloop geïntroduceerd als verbetering ten opzichte van MQTT v3.1.1 bij het verwerken van sessiepersistentie. Clean Start is een functie waarmee een client een nieuwe sessie kan starten met MQTT Broker, waarbij eventuele eerdere sessiegegevens worden verwijderd. Met sessieverloop kan een client MQTT-broker informeren wanneer een inactieve sessie als verlopen wordt beschouwd en automatisch wordt verwijderd. In het CONNECT-pakket kan een client de vlag Clean Start instellen op true en/of een kort verloopinterval van de sessie om veiligheidsredenen of om mogelijke gegevensconflicten te voorkomen die zich tijdens de vorige sessie hebben voorgedaan. Een client kan ook een schone start instellen op onwaar en/of een lange sessieverloopinterval om de betrouwbaarheid en efficiëntie van permanente sessies te garanderen.

Maximale configuratie van sessieverloopinterval

U kunt het maximale verloopinterval voor sessies configureren dat is toegestaan voor al uw clients die verbinding maken met de Event Grid-naamruimte. Voor MQTT v3.1.1-clients wordt de geconfigureerde limiet toegepast als het standaardperiodeperiode voor sessieverloop voor alle permanente sessies. Voor MQTT v5-clients wordt de geconfigureerde limiet toegepast als de maximumwaarde voor de eigenschap Sessieverloopinterval in het CONNECT-pakket; elke waarde die de limiet overschrijdt, wordt aangepast. De standaardwaarde voor deze naamruimte-eigenschap is 1 uur en kan worden verlengd tot 8 uur. Gebruik de volgende stappen om het maximale verloopinterval voor sessies in Azure Portal te configureren:

  • Ga naar uw naamruimte in Azure Portal.
  • Wijzig onder Configuratie de waarde voor het maximale verloopinterval van de sessie in uren in de gewenste limiet.
  • Selecteer Toepassen.

schermopname van de configuratie van het maximale verloopinterval van de sessie.

Sessieoverloop

MQTT-broker onderhoudt een wachtrij met berichten voor elke actieve MQTT-sessie die niet is verbonden, totdat de client opnieuw verbinding maakt met MQTT-broker om de berichten in de wachtrij te ontvangen. Als een client geen verbinding maakt om de QOS1-berichten in de wachtrij te ontvangen, wordt de sessiewachtrij gestart met het verzamelen van de berichten totdat de limiet is bereikt: 100 berichten of 1 MB. Zodra de wachtrij de limiet bereikt tijdens de levensduur van de sessie, wordt de sessie beëindigd.

LWT-berichten (Last Will and Testament)

Last Will and Testament (LWT) meldt uw MQTT-clients met de plotselinge verbroken verbindingen van andere MQTT-clients. U kunt LWT gebruiken om een voorspelbare en betrouwbare communicatiestroom tussen MQTT-clients te garanderen tijdens onverwachte verbroken verbindingen, wat waardevol is voor scenario's waarbij realtime communicatie, systeembetrouwbaarheid en gecoördineerde acties essentieel zijn. Clients die samenwerken om complexe taken uit te voeren, kunnen van elkaar reageren op LWT-berichten door hun gedrag aan te passen, taken opnieuw te distribueren of bepaalde verantwoordelijkheden over te nemen om de prestaties en stabiliteit van het systeem te behouden. Als u LWT wilt gebruiken, kan een client het bericht opgeven, onderwerp en de rest van de eigenschappen in het CONNECT-pakket tijdens de verbinding. Wanneer de client plotseling wordt losgekoppeld, publiceert de MQTT-broker het bericht naar alle clients die zijn geabonneerd op het will-onderwerp. De client kan het vertragingsinterval instellen op een waarde die groter is dan nul om de ruis te verminderen van fluctuerende verbroken verbindingen. In dat geval wordt het bericht niet gepubliceerd als de client de verbinding plotseling verbreekt, maar de verbinding weergeeft voordat het interval voor vertraging verloopt.

Gebruikerseigenschappen

MQTT Broker ondersteunt gebruikerseigenschappen op MQTT v5 PUBLISH-pakketten waarmee u aangepaste sleutel-waardeparen in de berichtkop kunt toevoegen om meer context over het bericht te bieden. De gebruiksvoorbeelden voor gebruikerseigenschappen zijn veelzijdig. U kunt deze functie gebruiken om het doel of de oorsprong van het bericht op te nemen, zodat de ontvanger het bericht kan verwerken zonder de nettolading te parseren, waardoor rekenresources worden opgeslagen. Een bericht met een gebruikerseigenschap die het doel aangeeft als een waarschuwing kan bijvoorbeeld verschillende verwerkingslogica activeren dan één met het doel van 'informatie'.

Patroon aanvraag-antwoord

MQTTv5 heeft velden geïntroduceerd in de MQTT PUBLISH-pakketheader die context bieden voor het antwoordbericht in het aanvraag-antwoordpatroon. Deze velden bevatten een antwoordonderwerp en een correlatie-id die de beantwoorder kan gebruiken in het antwoord zonder voorafgaande configuratie. De antwoordinformatie maakt efficiëntere communicatie mogelijk voor het standaardpatroon voor aanvraag-antwoord dat wordt gebruikt in opdracht- en controlescenario's.

Diagram van het voorbeeld van het aanvraagantwoordpatroon.

Verloopinterval van bericht:

In MQTT v5 staat het verloopinterval van berichten toe dat berichten een configureerbare levensduur hebben. Het verloopinterval van het bericht wordt gedefinieerd als het tijdsinterval tussen het tijdstip waarop een bericht wordt gepubliceerd naar MQTT-broker en het tijdstip waarop de MQTT-broker het niet-bezorgde bericht moet negeren. Deze functie is handig in scenario's waarin berichten alleen geldig zijn voor een bepaalde tijd, zoals tijdgevoelige opdrachten, realtime gegevensstreaming of beveiligingswaarschuwingen. Door een verloopinterval voor berichten in te stellen, kan MQTT-broker verouderde berichten automatisch verwijderen, zodat alleen relevante informatie beschikbaar is voor abonnees. Als het verloopinterval van een bericht is ingesteld op nul, betekent dit dat het bericht nooit mag verlopen.

Onderwerpaliassen:

In MQTT v5 kunnen onderwerpaliassen een client een kortere alias gebruiken in plaats van de volledige onderwerpnaam in het gepubliceerde bericht. MQTT Broker onderhoudt een toewijzing tussen de onderwerpalias en de werkelijke onderwerpnaam. Deze functie kan netwerkbandbreedte besparen en de grootte van de berichtkop verkleinen, met name voor onderwerpen met lange namen. Het is handig in scenario's waarin hetzelfde onderwerp herhaaldelijk wordt gepubliceerd in meerdere berichten, zoals in sensornetwerken. MQTT Broker ondersteunt maximaal 10 onderwerpaliassen. Een client kan een veld Onderwerpalias in het PAKKET PUBLICEREN gebruiken om de volledige onderwerpnaam te vervangen door de bijbehorende alias.

Diagram van het voorbeeld van de onderwerpalias.

Stroombeheer

In MQTT v5 verwijst stroombeheer naar het mechanisme voor het beheren van de snelheid en grootte van berichten die een client kan verwerken. Stroombeheer kan worden geconfigureerd door de parameters Maximale pakketgrootte en Maximum ontvangen in het CONNECT-pakket in te stellen. Met de parameter Maximum ontvangen kan de client het aantal berichten dat door de broker wordt verzonden, beperken tot het aantal berichten dat de client kan verwerken. De parameter Maximale pakketgrootte definieert de maximale grootte van pakketten die de client kan ontvangen. MQTT-broker heeft een berichtgroottelimiet van 512 KiB. Deze functie zorgt voor betrouwbaarheid en stabiliteit van de communicatie voor beperkte apparaten met beperkte verwerkingssnelheid of opslagmogelijkheden.

Negatieve bevestigingen en door de server geïnitieerd verbindingspakket

Voor MQTT v5 kan MQTT Broker negatieve bevestigingen (NACK's) en server geïnitieerde verbroken pakketten verzenden die de client meer informatie bieden over fouten voor berichtbezorging of verbinding. Deze functies helpen de client om de reden achter een fout vast te stellen en passende beperkende acties uit te voeren. MQTT-broker gebruikt de redencodes die zijn gedefinieerd in de MQTT v5-specificatie.

Huidige beperkingen

MQTT Broker voegt in de toekomst meer MQTT v5- en MQTT v3.1.1-functies toe om meer af te stemmen op de MQTT-specificaties. De volgende lijst bevat informatie over de huidige verschillen tussen functies die worden ondersteund door de MQTT-broker en de MQTT-specificaties:

Huidige beperkingen voor MQTTv5

MQTT v5 verschilt momenteel op de volgende manieren van de MQTT v5-specificatie :

  • Gedeelde abonnementen worden nog niet ondersteund.
  • Vlag behouden wordt nog niet ondersteund.
  • Het maximale vertragingsinterval is 300.
  • Het maximumaantal QoS is 1.
  • Maximale pakketgrootte is 512 KiB
  • Berichtvolgorde is niet gegarandeerd.
  • Abonnements-id's worden niet ondersteund.
  • Toegewezen client-id's worden nog niet ondersteund.
  • Maximum onderwerpalias is 10. Op dit moment wijst de server geen onderwerpaliassen toe voor uitgaande berichten. Clients kunnen onderwerpaliassen binnen de ingestelde limiet toewijzen en gebruiken.
  • CONNACK retourneert geen eigenschap Antwoordinformatie, zelfs niet als de CONNECT-aanvraag de eigenschap Antwoordgegevens van aanvraag bevat.
  • Gebruikerseigenschappen op CONNECT, SUBSCRIBE, DISCONNECT, PUBACK, AUTH-pakketten worden niet gebruikt door de service, zodat ze niet worden ondersteund. Als een van deze aanvragen gebruikerseigenschappen bevat, mislukt de aanvraag.
  • Als de server een PUBACK ontvangt van een client met antwoordcode die niet is geslaagd, wordt de verbinding beëindigd.
  • Keep Alive Maximum is 1.160 seconden.

Huidige beperkingen voor MQTTv3.1.1

MQTT v5 verschilt momenteel op de volgende manieren van de MQTT v3.1.1-specificatie :

  • QoS2 en Behoudvlag worden nog niet ondersteund. Een publicatieaanvraag met een behoudvlag of met een QoS2 mislukt en sluit de verbinding.
  • Berichtvolgorde is niet gegarandeerd.
  • Keep Alive Maximum is 1.160 seconden.

Codevoorbeelden:

Deze opslagplaats bevat C#-, C- en Python-codevoorbeelden die laten zien hoe u telemetrie verzendt, opdrachten verzendt en waarschuwingen uitzendt. De certificaten die via de voorbeelden zijn gemaakt, zijn geschikt voor tests, maar ze zijn niet geschikt voor productieomgevingen.

Volgende stappen:

Meer informatie over MQTT:

Meer informatie over MQTT-broker: