Quale tipo di messaggistica può essere utilizzato per i protocolli IoT orientati alla rete cellulare?

Questo è venuto alla mia attenzione di recente quando ho trovato un fantastico video su Youtube di:

Micheal E. Anderson: confronto tra tecniche di messaggistica per l'IoT, OpenIoTSummit, Linux Foundation .

Le slide per i suoi interventi sono disponibili qui

Nelle diapositive 26 e 41 minuti del video sta discutendo di come (lasciami parafrasare):

I gestori di telefonia mobile preferiscono che i loro consumatori IoT utilizzino messaggi di tipo HTML , XML o JSON poiché consumano più dati. Più dati significa che possono addebitare ai consumatori più soldi per il servizio.

Capisco che un sacco di protocolli proprietari vale a dire. SigFox , Wireless HART o Z Wave hanno velocità di trasmissione dati inferiori e l'invio di dati voluminosi su tali supporti può essere un affare costoso.

Domanda

• Esistono altri formati di messaggistica leggeri che vengono utilizzati per l'utilizzo nei protocolli proprietari che li rendono soluzioni convenienti per i consumatori IoT attuali e futuri? (Girato al buio: un formato chiamato XML leggero o HTML o JSON giace da qualche parte?)

• Forse qualcosa come CBOR è o forse viene utilizzato?

Stai chiedendo informazioni sul protocollo o sul formato del messaggio ? Spesso usiamo erroneamente il termine protocollo quando intendiamo il formato dei dati. Lo faccio da solo, spesso perché la distinzione non è chiara a tutti.

I protocolli di messaggistica utilizzati in IoT tendono ad essere abbastanza compatti, almeno più di http e offrono funzionalità significative che sono importanti nella messaggistica (sessioni, controllo del flusso, affidabilità, ecc.). Il formato del messaggio è il dato dei dati nel messaggio che viene inviato. Presumo che questo sia ciò che stai chiedendo.

Il formato del messaggio più compatto è un formato binario arrotolato a mano attentamente considerato. Viene spesso utilizzato in scenari con larghezza di banda ridotta quando si desidera inviare alcuni byte e conoscere esattamente l'aspetto di tali byte. Per messaggi più grandi gli svantaggi sono significativi e, in generale, dovrebbero essere evitati a tutti i costi.

Ho passato una valutazione dettagliata su molte diverse opzioni di serializzazione dei dati. Mi aspettavo che protobuf, messagepack fosse abbastanza compatto, come loro. Tuttavia, il mio secondo problema era trovare librerie che erano mantenute e disponibili su diverse piattaforme, tra cui C sul dispositivo.

Il formato su cui ho optato, sorprendentemente, era JSON compresso con gzip. È facile da implementare e comprendere, funziona ovunque e, con i dati che stavo usando, era più o meno lo stesso di altri metodi.

Inoltre, tieni presente che se disponi di un canale sicuro come TLS, consumerai comunque una parte di dati (> 6 KB) in handshake TLS.

Alcuni anni fa, mi aspettavo un formato come i buffer di protocollo, ma non è successo molto. Probabilmente a causa della facilità con cui json può essere scritto e analizzato (e compresso). Mi piace l'aspetto dei Flatbuffer , ma il vantaggio è più sulla velocità di analisi che sulla compattezza.

Dato che sei in fase di indagine, ti suggerisco di scrivere un po 'di codice su ciascuno, usando i dati tipici della tua situazione, e fare dei confronti. Avere dati concreti all'avvio aiuta a confermare le tue scelte.

Il grande vantaggio di un formato basato sul markup è che mantieni la flessibilità nella scelta dei dati che trasmetti. Ciò è estremamente importante in un ecosistema in evoluzione in cui si prevede che un servizio evolva nel corso di diversi anni di sviluppo.

Sebbene una struttura di dati binari strettamente codificata sia efficiente per la trasmissione, è necessario decidere in anticipo almeno come sarà la struttura. Quando, in seguito, ti rendi conto che anche un campo necessita di espansione, sei bloccato. Anche implementare un aggiornamento del protocollo è difficile, dal momento che non è possibile eliminare una vecchia codifica fino a quando non viene aggiornato ogni endpoint.

Ciò suggerisce che l'approccio ottimale è quello di mescolare pacchetti minimalisti e codifica basata su markup (usando quest'ultimo come fallback). Il valore di questo dipende dai payload di larghezza di banda più elevati. Se stai già trasferendo blocchi di dimensioni video frequenti, è meno utile ottimizzare i dati di controllo poco frequenti. Se hai frequenti piccoli trasferimenti (una temperatura forse), ha senso ridurre al minimo le spese generali nella trasmissione, ma forse solo il raggruppamento dei trasferimenti è altrettanto buono.