Différences

Ci-dessous, les différences entre deux révisions de la page.

--- reseaux:internet:pubsub [2022/08/06 08:34] – [2. Client/Serveur versus Publish/Subscribe] phil
+++ reseaux:internet:pubsub [2022/08/06 09:02] (Version actuelle) – [3. Client/Serveur versus Publish/Subscribe] phil
@@ Ligne 3: / Ligne 3: @@
 ===== Publish/Subscribe =====
 {{ :reseaux:internet:pub-sub-receiving-message-300x134.png?nolink|}}
-[Mise à jour le 20/12/2021]
+[Mise à jour le 6/8/2022]
   * **Source** : Mooc Fun "Programmer l'internet des objets"
@@ Ligne 41: / Ligne 41: @@
 **MQTT est très léger et conçu pour les périphériques de faibles puissances**. Il a une très petite empreinte logicielle et est optimisé pour fonctionner dans les environnements à faible bande passante. Cela rend **MQTT idéal pour les applications IoT**. Malgré tout, l’usage de TCP et des très nombreux acquittements peut s’avérer lourds pour les équipements ou les réseaux très contraints. Une version plus légère basée sur UDP existe pour ces cas d’usage, mais elle est peu utilisée.
-<note tip>S'ils se ressemblent, les principes de nommage des topics MQTT et des URI REST sont complètement différents. Par rapport à MQTT, le chemin dans l'URI n'a pas de sémantique. Il a juste vocation à être unique. Il ne peut pas être utilisé pour agréger plusieurs sources d'information. Si deux capteurs publient respectivement sur les topics /sensor/buildingA/temperature et /sensor/buildingB/temperature, un subscriber peut s'abonner au topic /sensor/*/temperature pour recevoir toutes les mesures ; ce qui est impossible avec REST : il faudra autant de requêtes que de capteurs pour récupérer l'ensemble des mesures.</note>
+<callout type="tip" icon="true">S'ils se ressemblent, les principes de nommage des topics MQTT et des URI REST sont complètement différents. Par rapport à MQTT, le chemin dans l'URI n'a pas de sémantique. Il a juste vocation à être unique. Il ne peut pas être utilisé pour agréger plusieurs sources d'information. Si deux capteurs publient respectivement sur les topics /sensor/buildingA/temperature et /sensor/buildingB/temperature, un subscriber peut s'abonner au topic /sensor/*/temperature pour recevoir toutes les mesures ; ce qui est impossible avec REST : il faudra autant de requêtes que de capteurs pour récupérer l'ensemble des mesures.</callout>
-<note warning>Les URI sont simplement uniques au monde par leur construction alors que les topics du MQTT sont spécifiques à une application. Un topic MQTT peut être interprété différemment par deux applications différentes. Cela ne permet pas une interopérabilité sémantique. Les abonnés doivent être construits avec une connaissance des topics utilisés par les publieurs.</note>
+<callout  icon="fa fa-hand-stop-o" color="red" title="IMPORTANT">Les URI sont simplement uniques au monde par leur construction alors que les topics du MQTT sont spécifiques à une application. Un topic MQTT peut être interprété différemment par deux applications différentes. Cela ne permet pas une interopérabilité sémantique. Les abonnés doivent être construits avec une connaissance des topics utilisés par les publieurs.</callout>