MQTT-protocollen en het Internet of Things
June 8, 2023
Brightest
De oorsprong van MQTT
Het MQTT-protocol is een veelgebruikt protocol voor machine-2-machinecommunicatie. Het werd in 1999 ontwikkeld door Andy Stanford-Clark en Arlen Nipper voor de olie- en gasindustrie. Zij hadden een manier nodig om te communiceren met verschillende systemen die niet direct met elkaar konden communiceren. In die tijd was digitale communicatie en rekenkracht niet goedkoop. De oplossing moest lichtgewicht zijn met een kleine codevoetafdruk en een minimale netwerkbandbreedte. Tegenwoordig hebben we meer dan genoeg vermogen en digitale communicatie is veel betrouwbaarder dan vroeger.
Voorbeeld van het gebruik van het MQTT-protocol
Een van de meest voorkomende voorbeelden van het gebruik van het MQTT-protocol is domotica. De client is een mobiele telefoon die een MQTT-bericht naar een broker stuurt. Meestal is de broker het hart of het brein van het domoticasysteem. Zodra de broker een MQTT-bericht van de client ontvangt, zal hij zijn taak correct uitvoeren, bijvoorbeeld door een licht uit te schakelen. Als een andere client de status van het licht wil weten, zal deze op zijn beurt een ander MQTT bericht sturen om de status van de broker te vragen.
Naast domotica wint MQTT ook aan populariteit in de auto-industrie. HiveMQ, een populair MQTT broker systeem, werkt samen met bedrijven als BMW, Audi en SiriusXM om verbonden auto’s te bouwen. Traditionele HTTP- en SMS-communicatie zijn om vele redenen niet geschikt om een connected car architectuur te bouwen. Kortom, het MQTT protocol wordt erg belangrijk in het IoT landschap en dat maakt het noodzakelijk om dit goed te testen.
MQTT in een notendop
Het MQTT-protocol werkt volgens een publish/subscribe-model. Een MQTT-netwerk bestaat uit clients en een broker. De clients publiceren en abonneren zich op topics en een broker zorgt ervoor dat elk bericht wordt gedistribueerd naar de clients die geabonneerd zijn op de topics. Stel je voor dat je je auto uitleent aan een vriend en je hebt hem gevraagd voorzichtig te rijden. Je installeert een app op je telefoon waarmee je de snelheid kunt volgen. Om de werkelijke snelheid te controleren, moet deze applicatie zich abonneren op het topic ‘Snelheid’. Elke keer dat je auto dan een bericht publiceert naar dit topic, zullen alle clients die geabonneerd zijn op het topic een bericht ontvangen met hoe snel de auto rijdt, inclusief de applicatie. Dit is MQTT in een notendop.
Integratietests bouwen voor je MQTT-toepassing
Er zijn een aantal manieren om een MQTT-applicatie te testen. In het verleden waren er veel geïntegreerde tests, die een publieke broker op ons netwerk gebruikten binnen een testomgeving. Hoewel deze manier van testen zijn voordelen heeft, is het geen flexibele manier om je MQTT-interface te testen tijdens de ontwikkeling. Als er bijvoorbeeld een netwerkprobleem is en de broker niet bereikt kan worden, kan dit zorgen voor foutieve testresultaten. Een ander probleem ontstaat bij het uitvoeren van meerdere tests tegelijk. Test engineers kunnen elkaar storen door verschillende abonnementsconfiguraties te uploaden. Om deze problemen aan te pakken, is het belangrijk om de volgende richtlijnen in gedachten te houden:
- Tests moeten geïsoleerd zijn en niet afhankelijk van externe afhankelijkheden
- Tests moeten slechts één component/module testen
Om deze problemen te beperken, kunnen we Docker en testcontainers gebruiken.
Een voorbeeld
Een goede tutorial hierover (in Java) is te vinden in de documentatie van HiveMQ: https://www.hivemq.com/blog/
In dit voorbeeld gebruiken we een Mosquitto docker image en een dotnet implementatie van een testcontainer library. Beide zijn te vinden op de volgende locaties:
STAP 1
Om te beginnen moeten we Docker downloaden en het image ophalen. Gebruik de Docker-client om dit te doen of gebruik de command regel. Als je de command regel gebruikt, kun je het volgende Docker-commando uitvoeren: docker pull eclipse-mosquitto.
STAP 2
Zodra dit gedaan is, heb je een configuratiebestand nodig.
Maak een map aan op je C-schijf met de naam “mosquitto“ en maak daarin een andere map met de naam “config”.
Klaar? Maak een bestand genaamd “mosquitto.conf” en plaats de volgende 2 regels erin:
- listener 1883
- allow_anonymous true
STAP 3
Hierna kun je de container handmatig starten door het volgende commando uit te voeren:
docker run -it -p 1883:1883 -v C:mosquitto:/mosquitto/ eclipse-mosquitto
Vervolgens wordt de image gestart en kun je in de Docker UI zien dat de image draait:
Je kunt meer configuraties instellen in het mosquitto.conf bestand, en het kan helemaal worden aangepast aan je eigen behoeften. Voor het doel van deze demo volstaan de bovenstaande regels.
STAP 4
Tot nu toe starten we de containers handmatig. Maar we willen dit automatiseren, en een testcontainer library bouwen die dit voor ons regelt. De strategie die we gebruiken is om voor elke test een container te starten. We beginnen dus met een nieuwe broker voor elke test. We kunnen het onderstaande fragment in C# gebruiken om dit te bereiken:
Om te beginnen bouwen we een container met het Mosquitto image en mappen onze poorten. Vervolgens mounten we onze Mosquitto directory naar onze container zodat de configuratie is ingesteld. Zodra de container is gebouwd, kunnen we deze starten en onze MQTT-tests uitvoeren. Door de tests uit te voeren met deze fixture, kunnen we meerdere tests tegelijk uitvoeren. Het enige nadeel is dat we per test een poort moeten specificeren.
Conclusie
Het gebruik van Docker maakt het eenvoudiger om applicaties te testen met MQTT. Niet alleen zijn de tests volledig onafhankelijk van externe afhankelijkheden, die niet in aanmerking zouden moeten komen voor integratietests, het maakt ook de setup eenvoudig en snel. Bovendien kun je meerdere tests parallel uitvoeren, wat niet mogelijk is als je test met de eigenlijke MQTT-broker, omdat meerdere tests elkaar kunnen storen. Daarnaast is het gemakkelijker te onderhouden omdat deze tests tijdens de ontwikkelcyclus kunnen worden ontwikkeld. Dit resulteert in een snellere release en een betere kwaliteit van het softwareproduct.
Houd er wel rekening mee dat deze tests geen volledige vervanging zijn voor E2E-tests. Maar ze zijn een must-have in een goed QA-proces en worden aangevuld door E2E-testen.
Laten we samenwerken