Cela est venu à mon attention récemment quand j'ai trouvé une vidéo incroyable sur Youtube par:
Les diapositives de son discours sont disponibles ici
Sur les diapositives 26 et 41 minutes de la vidéo, il explique comment (permettez-moi de paraphraser):
Les opérateurs cellulaires préfèrent que leurs consommateurs IoT utilisent des messages de type HTML , XML ou JSON car ils consomment plus de données. Plus de données signifie qu'ils peuvent facturer aux consommateurs plus d'argent pour le service.
Je comprends que beaucoup de protocoles propriétaires à savoir. SigFox , Wireless HART ou Z Wave ont des débits de données inférieurs et l'envoi de données volumineuses sur de tels opérateurs peut être une affaire coûteuse.
Question
Y a-t-il d'autres formats de messagerie légers qui sont utilisés pour une utilisation dans les protocoles propriétaires, ce qui en fait des solutions rentables pour les consommateurs actuels et futurs de l'IoT? (Tourné dans un noir: un format appelé XML léger ou HTML ou JSON se trouve quelque part?)
Peut-être que quelque chose comme CBOR est ou peut-être utilisé?
la source
Réponses:
Vous demandez le protocole ou le format du message ? Nous utilisons souvent à tort le terme protocole lorsque nous entendons le format des données. Je le fais moi-même, souvent parce que la distinction n'est pas claire pour tout le monde.
Les protocoles de messagerie utilisés dans l'IoT ont tendance à être assez compacts, au moins plus qu'à http et offrent des fonctionnalités importantes qui sont importantes dans la messagerie (sessions, contrôle de flux, fiabilité, etc.). Le format du message est celui des données du message qui sont envoyées. Je suppose que c'est ce que vous demandez.
Le format de message le plus compact est un format binaire soigneusement étudié. Il est fréquemment utilisé dans les scénarios à faible bande passante lorsque vous souhaitez envoyer quelques octets et savoir exactement à quoi ressemblent ces octets. Pour les messages plus volumineux, les inconvénients sont importants et doivent en général être évités à tout prix.
J'ai effectué une évaluation détaillée de nombreuses options de sérialisation de données différentes. Je m'attendais à ce que protobuf, messagepack soit assez compact, ce qu'ils étaient. Cependant, mon deuxième problème était de trouver des bibliothèques qui étaient maintenues et disponibles sur un certain nombre de plates-formes différentes, y compris C sur l'appareil.
Étonnamment, le format sur lequel j'ai opté était JSON compressé par gzip. Il est facile à mettre en œuvre et à comprendre, s'exécute partout et, avec les données que j'utilisais, était à peu près le même, ou plus petit, que les autres méthodes.
Sachez également que si vous disposez d'un canal sécurisé tel que TLS, vous allez quand même consommer un bloc de données (> 6 Ko) dans les poignées de main TLS.
Il y a quelques années, je m'attendais à ce qu'un format comme les tampons de protocole domine, mais il ne s'est pas vraiment passé grand-chose. Probablement à cause de la facilité avec laquelle json peut être écrit et analysé (et compressé). J'aime le look des Flatbuffers , mais l'avantage est plus sur la vitesse d'analyse que sur la compacité.
Puisque vous êtes au stade de l'enquête, je vous suggère d'écrire un peu de code sur chacun, en utilisant des données typiques de votre situation, et de faire des comparaisons. Le fait de disposer de données fiables au démarrage permet de confirmer vos choix.
la source
Le grand avantage d'un format basé sur le balisage est que vous conservez la flexibilité dans le choix des données que vous transmettez. Ceci est extrêmement important dans un écosystème en évolution où vous prévoyez un service évoluant sur plusieurs années de développement.
Bien qu'une structure de données binaires étroitement codée soit efficace à transmettre, vous devez au moins décider à l'avance à quoi ressemblera la structure. Lorsque, plus tard, vous réalisez que même un champ a besoin d'être étendu, vous êtes coincé. Même le déploiement d'une mise à jour du protocole est difficile, car vous ne pouvez pas obsolète un ancien codage jusqu'à ce que chaque point de terminaison soit mis à jour.
Cela suggère que l'approche optimale consiste à mélanger des paquets minimalistes et un codage basé sur le balisage (en utilisant ce dernier comme solution de rechange). La valeur de ceci dépend des charges utiles de bande passante les plus élevées. Si vous transférez déjà des morceaux de taille vidéo fréquents, l'optimisation des données de contrôle peu fréquentes est moins utile. Si vous avez de petits transferts fréquents (une température peut-être), il est logique de minimiser les frais généraux de transmission, mais peut-être que le traitement par lots des transferts est tout aussi bon.
la source