Bien qu'il soit juste de dire que XML est verbeux, cela devrait être tempéré en sachant que cette verbosité n'est pas entièrement «indirecte» par rapport au contenu car elle encapsule la sémantique; c'est la surcharge qui est symptomatique de tout protocole qui met l'accent sur une structure dynamique par opposition à une structure statique. Par exemple, le HTML est vraiment une forme détendue de XML qui transmet le contenu avec une structure dynamique, structure qui pourrait être considérée comme un aspect du contenu. Vous pouvez distinguer le contenu d'une table de la table elle-même, mais le fait que le contenu soit des données tabulaires avec des relations spécifiques fait partie intégrante du contenu; si je prenais chaque cellule et transmettais le tout comme une longue chaîne, cette structure et ces relations disparaissent, et donc j'ai perdu des informations et n'est-ce pas du contenu?
Prenons un message de 8 octets qui pourrait constituer des données tabulaires. Si j'utilise un protocole très statique, je pourrais, au minimum, le transmettre sans surcharge supplémentaire simplement en définissant un protocole comme celui-ci:
- Chaque message fait exactement 8 octets, nous n'avons donc pas besoin d'indiquer la longueur ni d'inclure de séquence de terminaison.
- Les huit octets sont toujours considérés comme faisant référence à une grille 2 x 2 où chaque cellule contient une valeur de 16 bits.
Si tous mes messages sont exactement comme ça, l'utilisation de XML, HTML ou XMPP peut être considérée comme stupide - je gaspille de la bande passante sur des composants structurels qui sont toujours les mêmes et prédéterminés de toute façon, et je perds le temps de calcul correspondant aux deux extrémités pour le créer et l'analyser. Une page HTML minimale et appropriée qui contient juste un tableau 2 x 2 avec quelques caractères dans chaque cellule va probablement faire au moins 100 octets pour prendre en charge la mise en forme et la surcharge du protocole.
Cependant, si tous mes messages ne sont pas exactement cela, alors spécifier de quel type de message il s'agit peut ne pas être une partie littérale de la "charge utile" mais c'est un composant nécessaire, en termes de contenu. Je pourrais le faire avec seulement deux octets supplémentaires et introduire beaucoup plus de dynamisme:
- Les messages sont désormais de longueur variable, de 0 à 255 octets, et le premier octet indique la longueur.
- Il existe (jusqu'à) 256 codes pour différents types de messages prédéfinis, dont l'un est "tableau 2 x 2", c'est le deuxième octet.
Maintenant, mes 8 octets de contenu de table nécessitent 2 octets de surcharge, mais il existe un éventail beaucoup plus large de possibilités en termes de types de messages pouvant être envoyés avec ce protocole personnalisé.
C'est encore loin des possibilités d'une page HTML ou d' une spécification d' espace de noms XML (ou un ensemble de celles-ci, ce qui est essentiellement XMPP ).
Donc, sur cette base, si la plupart du temps ce que vous faites envoie des messages simples de 8 octets, XMPP est probablement exagéré. Cependant, pas nécessairement tant que ça. L'affirmation selon laquelle "un seul échange de demande / réponse pour envoyer un octet de données d'un DISPOSITIF CONNECTÉ IOT au serveur est supérieur à 0,5 Ko" me semble, en regardant le RFC pertinent , être une exagération potentielle (mais nb, tous Je l'ai regardé, je n'ai jamais implémenté ou utilisé XMPP). Je ne doute pas que vous puissiez en construire un exemple, mais ce n'est probablement pas un exemple minimal .
Étant donné que le protocole est orienté TCP, l'établissement d'un "flux XML qualifié par l'espace de noms 'jabber: client'" ne doit être considéré comme faisant partie du message que si nous faisons une chose - l'appareil contacte un serveur pour envoyer 8 octets à, envoie les données, déconnecte. Si la relation est plus persistante, ce qui serait souvent le cas dans un contexte IoT, nous pouvons supposer que le périphérique dispose déjà d'une connexion établie avec la destination. Dans ce cas, si la destination ultime du message est le serveur (contrairement à un autre client auquel le serveur va transmettre le message), la surcharge du protocole est potentiellement minime.
<message><body>8 bytes.</body></message>
Un maigre 33 octets de "surcharge". Il convient de souligner ici que XML est du texte, et donc si vos messages sont souvent binaires, cela deviendra beaucoup moins approprié, car ces données doivent être codées (par exemple, en base64 ), ce qui ajoute des frais généraux et des calculs supplémentaires. exigences.
Donc, finalement:
XMPP a-t-il une surcharge importante pour les appareils IoT qui envoient des messages courts et fréquents?
S'il y a une connexion persistante et que les messages sont en grande partie non structurés, je ne pense pas. Cependant, si vous n'avez pas besoin de ce qu'elle offre (le dynamisme en matière de structure), alors il y a probablement des méthodologies plus appropriées.
Poursuivez cela, si nous avons un contexte où un seul serveur central traite et / ou utilise des messages entre divers appareils, même si ce que fait l'un de ces appareils peut toujours être simple et direct, un protocole qui peut encapsuler un une variété de messages serait toujours utile. Si un appareil client a des ressources limitées, nous pouvons coder en dur une grande partie du protocole, et encapsuler chaque message à cette fin devient une tâche très simple; Je pense que de nombreux appareils IoT qui déploient des serveurs HTTP font cela (ce qui est l'inverse de "clients simples, serveur complexe"). Ces serveurs ne peuvent pas gérer tout type de requête HTTP (sauf via un rejet préformaté) et ont un ensemble de choses très bien défini et ciblé que les choses feront et les réponses qu'ils enverront, mais puisqu'ils fonctionnent néanmoins correctement comme serveurs HTTP,