Différences

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

--- reseaux:internet:pubsub [2021/12/20 11:02] – [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 23: / Ligne 23: @@
 Le broker peut alors utiliser des filtres pour envoyer uniquement ces messages aux abonnés du topic concerné. Il existe plusieurs protocoles Publish-Subscribe tels que **MQTT** (**Message Queuing Telemetry Transport**), AMQP (Advanced Message Queuing Protocol), JMS (Java Messaging Service) ou XMPP (Extensible Messaging Protocol et Présence).
+==== 2. Exemple : MQTT ====
 Imaginons par exemple que plusieurs capteurs soient installés dans deux bâtiments A et B. Certains capteurs collectent des informations sur la température et d’autres collectent des informations sur l’humidité. Ces capteurs peuvent envoyer les données régulièrement à un broker central.
 {{ :reseaux:internet:mqtt-publish-subscribe-operations.jpg?nolink |}}
@@ Ligne 30: / Ligne 31: @@
 Certains abonnés peuvent s’abonner aux messages en fonction de leur intérêt. Ainsi, un abonné intéressé uniquement par les données d’humidité du bâtiment B peut s’abonner au sujet /sensor/buildingB/humidity et le broker n’enverra que ces données à cet abonné.
-==== 2. Client/Serveur versus Publish/Subscribe ====
+==== 3. Client/Serveur versus Publish/Subscribe ====
 Les principaux avantages du paradigme publish-subscribe par rapport au paradigme client-serveur, tels qu'inclus en REST, sont les suivants :
@@ Ligne 38: / Ligne 39: @@
 L’absence de couplage entre l’expéditeur et le destinataire se fait en termes d’espace, de temps et de synchronisation. Celui qui publie les données a une tâche simplifiée. Il n'a pas à gérer ou connaître ceux qui les consomment, il n'a qu’à les envoyer au broker.
-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.
+**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.
+<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>
+<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>
-<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>
-<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>