giovedì 16 giugno 2016; giovedì 30 giugno 2016 **__NOTA: questa pagina è solo un abbozzo__** ====== MQTT ====== [[https://en.wikipedia.org/wiki/MQTT]] [[http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.pdf]] * message broker (="server") * sottoscrivo l'accesso a una risorsa (canale dati) : autenticazione e permessi (accesso a una sola parte del canale) * se cade il mezzo (TCP/IP) rimane comunque attiva la sessione mqtt in modo da essere recuperata esattamente da dove ero rimasto senza dovermi riauth o altro... se invece voglio chiudere mi desottoscrivo (questo comportamento e' comunque deciso dal message broker) * tutte le comunicazioni sono tra client e messagebroker ; due client non possono parlare tra loro * metodi: connessione, sconnessione, sottoscrizione, desottoscrizione, pubblicazione * non c'è una richiesta-risposta , c'è solo il messaggio pubblicato * open source (royalties??) * queues lato broker * codifica UTF-8 per il testo --domanda: sono obbligato ad attendere l'ack prima di mandare un nuovo messaggio ??? pacchetto di controllo +fixed header +variable header (opzionale) +payload (opzionale) **header fisso** nell'header c'è il comando (metodo visto sopra) e ci sono dei flag, segue la lunghezza della parte seguente di pacchetto (da 1 a 4 byte). alcuni comandi no flag, ma publish ad es ha un paio di bit di QoS. **header variabile** puo' contenere un identificatore di pacchetto (tutti tranne connect/connack/ping/pingack/disconn) il quale e' univoco nell'insieme di ciascuna entita' (quindi server e client potrebbero scambiarsi pacch. con stessi id) (puo' contenere altre cose, come altri flag...) **payload** puo' essere obbligatorio, opzionale o vietato CONNECT flags byte: flag di clean session, per fanculizzare o recuperare la sessione precedente will flag: ? ---- 30 giugno ===== QoS ===== QoS in MQTT è atto a "garantire al mittente la consegna del messaggio". QoS è dato da 2 bit nei flag dell'header (0-3 dove 0-2 usati, 3 riservato per uso futuro) **Nota:** di seguito si parla di client che invia un messaggio al broker. In realtà il protocollo non fa distinzione tra le entità per quanto riguarda l'algoritmo di scambio dei messaggi pertanto lo stesso vale anche al viceversa e per ciascuno scambio di messaggi. Non è MAI preso in considerazione il percorso completo da client a n-client. A costo di ripetermi, la garanzia data da QoS riguarda quindi lo scambio tra un'entità e l'immediato interlocutore (es. broker-client). Pertanto ho la garanzia di consegna del messaggio al mio interlocutore NON ai destinatari finali. ==== QoS = 0 ==== Non vi è riscontro della consegna del messaggio, quindi non c'è alcun tipo di ACK in risposta ai PUBLISH. Non è ammesso il "retry". Il messaggio potrebbe quindi andare perso o essere consegnato una volta. ==== QoS = 1 ==== "Garanzia di almeno una consegna a ciascun receiver". Al pacchetto PUBLISH ottengo ("subito") un PUBACK di risposta. So che il broker ha preso in carico il messaggio e si impegna a garantirne la consegna a tutti i ricevitori. Se perdo il PUBACK, sono quindi tentato a rimandare il messaggio, il broker lo reinoltra e i receiver ricevono più volte il medesimo messaggio: da qui "l'almeno uno". ==== QoS = 2 ==== "Garanzia di una e una sola consegna a ciascun ricevente". "Usato quando non è ammessa la perdita nè la duplicazione del messaggio". Al pacchetto PUBLISH il broker replica con PUBREC (=ricevuto). Il client alla ricezione di PUBREC può considerare il messaggio preso in carico dal broker e deve remplicare con PUBREL (=rilasciato) per confermare al broker che quel messaggio non verrà rimandato. Infine il broker replica con PUBCOMP (=complete) per confermare la fine della transazione al client. Il broker finche' non riceve il PUBREL deve accettare (e rispondere con PUBREC) successivi PUBLISH con lo stesso id messaggio, però non deve creare duplicati (quindi tiene in memoria il messaggio finchè non riceve un PUBREL).