Differenze
Queste sono le differenze tra la revisione selezionata e la versione attuale della pagina.
| Prossima revisione | Revisione precedente | ||
|
talks:mqtt [20/06/2016 23:48] alez created |
talks:mqtt [01/07/2016 10:11] (versione attuale) alez |
||
|---|---|---|---|
| Linea 1: | Linea 1: | ||
| - | giovedì 16 giugno 2016 | + | giovedì 16 giugno 2016; giovedì 30 giugno 2016 |
| + | |||
| + | **__NOTA: questa pagina è solo un abbozzo__** | ||
| ====== MQTT ====== | ====== MQTT ====== | ||
| [[https://en.wikipedia.org/wiki/MQTT]] | [[https://en.wikipedia.org/wiki/MQTT]] | ||
| + | |||
| + | [[http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.pdf]] | ||
| Linea 39: | Linea 43: | ||
| flags byte: flag di clean session, per fanculizzare o recuperare la sessione precedente | flags byte: flag di clean session, per fanculizzare o recuperare la sessione precedente | ||
| will flag: ? | 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). | ||
