Mentre è giusto dire che XML è prolisso, questo dovrebbe essere mitigato dalla consapevolezza che questa verbosità non è tutta "ambientale" in relazione al contenuto poiché incapsula la semantica; è il sovraccarico che è sintomatico di qualsiasi protocollo che enfatizza una struttura dinamica anziché statica. Ad esempio, HTML è in realtà una forma rilassata di XML che trasmette contenuto con una struttura dinamica, struttura che potrebbe essere considerata un aspetto del contenuto. È possibile distinguere il contenuto di una tabella dalla tabella stessa, ma il fatto che il contenuto sia costituito da dati tabulari con relazioni specifiche è parte integrante del contenuto; se prendessi solo ogni cella e le trasmettessi tutte come una lunga stringa, quella struttura e quelle relazioni sarebbero sparite, e quindi avrei perso informazioni e non è quel contenuto?
Consideriamo un messaggio a 8 byte che potrebbe costituire alcuni dati tablari. Se utilizzo un protocollo molto statico, potrei, minimamente, trasmetterlo senza costi aggiuntivi semplicemente definendo un protocollo come questo:
- Ogni messaggio ha esattamente 8 byte, quindi non è necessario indicare la lunghezza o includere una sequenza finale.
- Gli otto byte vengono sempre presi come riferimento a una griglia 2 x 2 in cui ogni cella contiene un valore di 16 bit.
Se tutti i miei messaggi sono esattamente così, usare XML, HTML o XMPP potrebbe essere considerato stupido - sto sprecando larghezza di banda su componenti strutturali che sono sempre uguali e predeterminati, e sto sprecando il tempo di calcolo corrispondente ad entrambe le estremità per crearlo e analizzarlo. Una pagina HTML corretta e minima che contiene solo una tabella 2 x 2 con un paio di caratteri in ogni cella sarà probabilmente di almeno 100 byte per adattarsi al sovraccarico di formattazione e protocollo.
Tuttavia, se non tutti i miei messaggi sono esattamente così, allora specificare quale tipo di messaggio potrebbe non essere una parte letterale del "payload" ma è un componente necessario, dal punto di vista del contenuto. Potrei farlo con solo due byte extra e introdurre molto più dinamismo:
- I messaggi ora hanno una lunghezza variabile, 0-255 byte e il primo byte indica la lunghezza.
- Esistono (fino a) 256 codici per diversi tipi di messaggi predefiniti, uno dei quali è "tabella 2 x 2", ovvero il secondo byte.
Ora i miei 8 byte di contenuto della tabella richiedono 2 byte di sovraccarico, ma esiste una gamma molto più ampia di possibilità in termini di quali tipi di messaggi possono essere inviati con questo protocollo personalizzato.
Non è ancora vicino alle possibilità di una pagina HTML o di una specifica dello spazio dei nomi XML (o di un suo insieme, che è essenzialmente XMPP ).
Quindi, in base a ciò, se principalmente quello che stai facendo è l'invio di semplici messaggi a 8 byte, XMPP è probabilmente eccessivo. Tuttavia, non necessariamente così tanto. L'affermazione secondo cui "un singolo scambio di richieste / risposte per inviare un byte di dati da un IOT CONNECTED DEVICE al server è superiore a 0,5 kB" mi sembra, dando un'occhiata al RFC pertinente , essere una potenziale esagerazione (ma nb, tutto L'ho fatto dare un'occhiata, non ho mai implementato o usato XMPP). Non dubito che potresti costruirne un esempio, ma probabilmente non è un esempio minimo .
Poiché il protocollo è orientato al TCP, la creazione di "un flusso XML qualificato dallo spazio dei nomi" jabber: client "deve essere considerata parte del messaggio solo se stiamo facendo una cosa sola: i dispositivi contatta un server a cui inviare 8 byte, invia i dati, si disconnette. Se la relazione è più persistente, come spesso accadrebbe in un contesto IoT, allora possiamo supporre che il dispositivo abbia già una connessione stabilita con la destinazione. In questo caso, se la destinazione finale del messaggio è il server (al contrario di un altro client a cui passerà il messaggio), l'overhead del protocollo è potenzialmente minimo.
<message><body>8 bytes.</body></message>
Un misero 33 byte di "sovraccarico". Vale la pena sottolineare che XML è testo e quindi se i tuoi messaggi sono spesso binari, diventerà molto meno appropriato, perché quei dati devono essere codificati (ad esempio, su base64 ), che aggiunge ulteriori costi generali e computazionali requisiti.
Quindi, in definitiva:
XMPP ha un grande overhead per i dispositivi IoT che inviano messaggi brevi e frequenti?
Se esiste una connessione persistente e i messaggi sono in gran parte non strutturati, non credo. Tuttavia, se non hai bisogno di ciò che offre (il dinamismo per quanto riguarda la struttura), allora ci sono probabilmente metodologie più appropriate.
Persegui ciò, se abbiamo un contesto in cui un singolo server centrale sta elaborando e / o facendo affidamento sui messaggi tra una varietà di dispositivi, anche se ciò che uno di questi dispositivi sta facendo può essere sempre semplice e diretto, un protocollo che può incapsulare un varietà di messaggi sarebbe comunque utile. Se un dispositivo client ha risorse limitate, possiamo codificare gran parte del protocollo e avvolgere ogni messaggio da quel fine diventa un compito molto semplice; Credo che molti dispositivi IoT che distribuiscono server HTTP lo facciano (che è l'inverso di "client semplici, server complessi"). Questi server non sono in grado di gestire alcun tipo di richiesta HTTP (tranne che per il rifiuto preformattato) e hanno un insieme ben definito e focalizzato di cose che cosa faranno e risposte che invieranno, ma dal momento che funzionano comunque correttamente come server HTTP,