Pokročile témy MQTT

Krok 1: Pokračujeme s MQTT

Aktuálne budeme pokračovať s kódom, ktorý ste mali spraviť v priebehu posledného stretnutia.

Krok 2: Zaručené perzistentné doručenie správ

Client id

Pri pripájaní na MQTT server je potrebné zadávať takzvaný identifikátor klienta (client id), ktorý nám umožňuje jednoznačne označiť každého pripojeného klienta.

Na jeden MQTT broker sa nemôžu naraz pripojiť dvaja klienti s rovnakým client id, lebo starší z nich by bol automatický odpojený. Táto vlastnosť je označovaná ako client take over a je štandardná pre všetky brokery.

Tento jednoznačný identifikátor klienta slúži aj pre účely doručovania správ pri nespoľahlivom a padajúcom spojení. Broker má štandardne za úlohu si uchovať všetky správy, ktoré prišli s QoS 1 alebo 2 pre všetkých klientov, ktorí boli prihlásení na odber správ z daného topicu taktiež pomocou QoS 1 alebo 2.

Dôležité je pri opätovnom pripojení klienta s rovnakým client id použiť vlastnosť cleanSession nastavenú na false ak chceme prijať všetký správy, ktoré ešte nám neboli doručené. Broker si v takomto prípade pamätá aj všetký naše existujúce prihlásenia na odber (subscriptions), teda už nie je nutné sa znova prihlásovať na odber.

Používanie fixného client id je v niektorých prípadoch veľmi uľahčujúce. Ale ak nepotrebujete mať k dispozícii aj správy, ktoré boli poslané v čase, keď Váš klient nebol pripojený, prípadne používate len správy s QoS 0, tak odporúčam stále používať cleanSession nastavené na true (čo je aj prednastavená hodnota) a taktiež aj client id nastavený na dynamický generovanú hodnotu.

Krok 3: Info o stave klienta

Doteraz sme si vyskúšali použitie client id za účelom aby nás broker správne identifikoval pri novom pripojení a obnovil nám všetky nastavenia.

Ako ale zabezpečiť ak chceme informáciu o našom neočakávanom odpojení poslať aj ostatným klientom? Alebo len jednoducho chceme vedieť, ktorý klient je online a ktorý nie.

Last Will

Pre účelý funkcionality poslania správy v prípade nečakáneho odpojenia na vopred definovaný topic a s vopred definovaným obsahom sa v protokole MQTT nachádza funkcionalita Last Will and Testament (v skratke Last Will, teda záveť).

Pri pripájaní je možné zadefinovať viacero vlastnosti a jedná z nich je ja Last Will Message. Konkrétne v JavaScript implementácii Paho MQTT klienta je táto vlastnosť nazvaná willMessage (pozri dokumentáciu).

My si ideme teraz zobraziť stav každého klienta pre kurzory na našej web obrazovke. Vyskúšame pri tom použitie:

• retained typu správy
• Last Will správy

Správnu funkcionalitu si môžeš overiť aj na projektore, ak to mám zobrazené.

<div id="statusData">?statuses?</div>

var statuses = {};
function statusArrived(name,messageText) {
    statuses[name] = messageText;
    var statusHtml = "";
    for(var name in statuses) {
        var color = "red";
        if (statuses[name] === "online") {
            color = "green";
        }
        statusHtml += "<span style='color: transparent; text-shadow: 0 0 0 "+color+";'>&#9899;</span>"+name+"<br/>";
    }
    document.getElementById("statusData").innerHTML = statusHtml;
}

var regex_status = /kpi\/test\/([a-z0-9]+)\/status/i;
var match_status = regex_status.exec(message.destinationName);
if (match_status !== null) {                
    statusArrived(match_status[1],message.payloadString);
} else {
    ... tu pôvodný kód z metódy vložiť ...
}

mqttClient.subscribe("kpi/test/+/status");

Krok 4: Nestabilné spojenie

Pri komunikácii cez TCP môže nastať situácia keď spojenie spadne a druhý účastník nedostane informáciu o tom, že spojenie padlo. Takýto prípad nastane najskôr pri rôznych druhoch nespoľahlivých spojení ako sú aj mobilné siete alebo iné spojenia používané pre pripájanie IoT zariadení.

MQTT protokol má práve pre zaistenie fungovania spojenia funkcionalitu keep-alive. Pri pripájaní má klient zadefinovať svoj interval pre udržanie spojenia. Hodnota môže byť nastavena podľa toho aké kvalitné spojenie má daný klient.

Tento interval je štandardne nastavený na hodnotu 60 sekúnd. To znamená, že ak broker za 60 sekúnd nepríjme žiadnu správu od klienta, tak odpojí klienta a odošle jeho last-will správu (ak bola zadefinovaná). Klient má na starosti odoslať aspoň raz za daný interval nejakú správu. Buď to môže byť klasická správa alebo ak žiadnú takúto správu klient neposiela musí poslať špecifickú správu ping. Taktiež ak nedostane klient odpoveď za daný čas od brokera, tak sa odpojí.

Pre Javascript Paho MQTT klienta je to parameter keepAliveInterval.

Krok 5: Bezpečnosť

Aj v prostredí IoT netreba zabúdať na bezpečnosť, aj keď niekedy sa práve táto časť môže prehliadať aj z dôvodu menšieho výkonu niektorých IoT zariadení.

Základným spôsobom zabezpečenia prenosu je použitie enkrypcie na úrovni transportnej vrstvy. Ide hlavne o použitie bezpečného spojenia vo forme TCP s TLS/SSL alebo WebSocket s TLS/SSL teda cez HTTPS. Často použitie takéhoto spojenia je potrebné špecifický zadať pri pripájaní klienta.

Ďalšia z podstatných vlastnosti podporujúcich bezpečnosť je používanie mena a hesla pri prihlasovaní sa do brokera. Doteraz sme sa pre jednoduchosť prihlásovali bez akéhokoľvek mena a hesla, avšak možnosť meniť všetko nie je stále ideálna. Preto je možné vyžadovať prihlásenie menom a heslom a zároveň broker môže na základe tohto údaja obmedziť prístup pre používateľa len k niektorým topicom. Pričom je možné zadať oprávnenie na čitanie alebo zápis. Používanie mena a hesla takmer stráca svoj význam pri spojení bez TLS/SSL, keďže heslo sa prenáša bez akéhokoľvek zašifrovania kompletne v plain-text formáte.

Poďme si teda vyskúšať pripojenie pomocou TLS/SSL a s využitím mena a hesla.