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).

Navigazione

Table of contents

Contact

For any info you can write to:
Per qualunque info potete scrivere a:
info[at]maetech[dot]it

Ads

Stampa/Esporta
QR Code
QR Code talks:mqtt (generated for current page)