add example SDi/IOT_Technologies/MQTT

index.html

@@ -23,10 +23,10 @@
     window.$docsify = {
       name: 'Yggdrasil',
       repo: 'https://github.com/Klagarge/Yggdrasil.git',
-      maxLevel: 3,
+      maxLevel: 5,
       coverpage: 'style/_coverpage.md',
       loadNavbar: true, // Nav bar on top
-      subMaxLevel: 3, // Add table of contents (TOC) in custom sidebar.
+      subMaxLevel: 5, // Add table of contents (TOC) in custom sidebar.
       auto2top: true, // Scrolls to the top of the screen when the route is changed.
       mergeNavbar: true, // Navbar will be merged with the sidebar on smaller screens.
       pagination: {

infotro/SDi/iot_technologies.md

@@ -230,25 +230,25 @@ comme le nom ou l'adresse de courrier électronique d'une personne.
   - Un URI est une chaîne de caractères utilisée pour identifier de manière unique une ressource.
   - Les URI comprennent les URL, les URN, et peuvent être étendus par les IRIs.
 
-  `http://www.example.com.org/index.html#date`
+  `http://www.example.com/index.html#date`
 
 - **URL (Uniform Resource Locator):**
   - Une URL est un type d'URI qui fournit l'adresse spécifique d'une ressource sur le web.
   - Elle inclut le schéma (comme http), le nom du domaine et souvent le chemin d'accès à la ressource.
 
-  `http://www.example.com.org/index.html`
+  `http://www.example.com/index.html`
 
 - **URN (Uniform Resource Name):**
   - Un URN est un sous-type d'URI qui identifie de manière unique une ressource indépendamment de sa localisation.
   - Contrairement aux URL, les URN ne fournissent pas d'adresse spécifique pour accéder à la ressource.
 
-  `//www.example.com.org/index.html#date`
+  `//www.example.com/index.html#date`
 
 - **IRI (Internationalized Resource Identifier):**
   - Un IRI est une extension d'URI qui peut contenir des caractères non ASCII.
   - Il représente de manière unique une ressource sur le web.
 
-  `http://www.example.com.org/😉`
+  `http://www.example.com/😉`
 
 En résumé, les URIs englobent les URL et les URNs, les URNs identifient de manière unique une ressource sans spécifier
 son emplacement, et les URLs fournissent une adresse spécifique pour accéder à une ressource sur le web.
@@ -263,6 +263,13 @@ Les Uniform Resource Locators (URLs) suivent un format générique : `http://<h
 Ils comprennent des éléments tels que le nom du serveur, le port, le chemin local sur le serveur, et éventuellement des
 paramètres de requête.
 
+    | Field | Description |
+    | --- | --- |
+    | host| DNS name of the server hosting the resource |
+    | port | HTTP server port number<br>(default for http: 80; default for https: 443) |
+    | path | Local path on HTTP server |
+    | query | Supplementary information to clarify the resource (GET)<br>or to create / update the resource (PUT / POST)|
+
 - **Format des requêtes et réponses HTTP:**
 Les requêtes et réponses HTTP sont textuelles et structurées.
 Les en-têtes contiennent des paires clé-valeur, définissant divers aspects de la communication.
@@ -273,4 +280,263 @@ Les ressources peuvent avoir différentes représentations, telles que HTML, JSO
 Les clients spécifient les formats acceptables via l'en-tête "Accept", tandis que les serveurs déclarent le format de
 la réponse avec "Content-Type".
 
-### 
+![http_reminder.png](http_reminder.png)
+
+| Satus codes | Description                  |
+| --- |------------------------------|
+| 1xx | Informational                |
+| 2xx | Success                      |
+| 3xx | Redirection to a further URL |
+| 4xx | Client Error                 |
+| 5xx | Server Error                 |
+
+### Méthodes de notification serveur
+![http_notifications.png](http_notifications.png)
+
+#### Long polling
+Le long polling, ou long polling HTTP, est une technique de communication asynchrone utilisée dans le développement web
+pour permettre au serveur d'envoyer des mises à jour au client de manière proactive.
+Contrairement à la méthode traditionnelle où le client interroge régulièrement le serveur pour obtenir des mises à jour
+(polling), le long polling maintient la connexion ouverte jusqu'à ce que de nouvelles informations soient disponibles.
+
+Voici un aperçu de la méthode du long polling :
+
+1. **Requête Bloquante :**
+    - Le client envoie une requête au serveur comme dans une requête normale, mais avec un détail crucial : la connexion
+   reste ouverte pendant un certain temps.
+
+2. **Attente de Mises à Jour :**
+    - Le serveur retient la requête jusqu'à ce qu'il ait des informations à transmettre.
+   Pendant ce temps, la connexion reste ouverte.
+
+3. **Réponse du Serveur :**
+    - Lorsque de nouvelles données sont disponibles ou qu'un événement survient, le serveur répond à la requête avec
+   les mises à jour.
+
+4. **Traitement Côté Client :**
+    - Côté client, le gestionnaire d'événements traite la réponse du serveur et déclenche les actions nécessaires.
+
+5. **Nouvelle Requête :**
+    - Après avoir traité la réponse, le client émet une nouvelle requête pour maintenir la connexion ouverte et recevoir
+   d'autres mises à jour.
+
+Le long polling permet aux applications web d'atteindre une communication quasi en temps réel tout en évitant le besoin
+constant de requêtes fréquentes. Cette technique a été utilisée avant l'avènement de technologies plus modernes comme
+les WebSockets et Server-Sent Events (SSE).
+
+Cependant, il convient de noter que le long polling peut entraîner des latences et une utilisation intensive des
+ressources du serveur, car il peut nécessiter la gestion simultanée de nombreuses connexions ouvertes.
+Les WebSockets et SSE sont souvent préférés pour des performances optimales dans des scénarios de communication en temps réel.
+
+#### Server-Side Events (SSE)
+Les Server-Sent Events (SSE), ou événements envoyés par le serveur, sont une technologie du côté serveur utilisée dans le
+développement web pour permettre à un serveur d'envoyer des mises à jour unidirectionnelles au client sur une connexion HTTP.
+SSE fournit une manière simple et efficace pour les serveurs d'envoyer des informations en temps réel aux navigateurs
+sans que ces derniers aient besoin de constamment interroger le serveur.
+
+Voici comment fonctionnent les Server-Side Events :
+
+1. **Établissement de la Connexion :**
+    - Le client crée une connexion HTTP standard vers le serveur.
+
+2. **Format des Données :**
+    - Le serveur envoie les données au client sous la forme d'événements.
+   Chaque événement est un message texte qui suit un format spécifique défini par le standard SSE.
+
+3. **Flux Continu :**
+    - Une fois la connexion établie, le serveur peut envoyer périodiquement des événements au client sans que ce dernier
+   ait besoin de faire de nouvelles requêtes.
+
+4. **Réception Côté Client :**
+    - Côté client, l'événement est intercepté par un gestionnaire d'événements, permettant aux développeurs
+   de réagir aux mises à jour en temps réel.
+
+5. **Réintégration Automatique :**
+    - SSE prend également en charge la réintégration automatique de la connexion en cas de déconnexion, ce qui garantit
+   une expérience continue même en cas de problèmes de réseau temporaires.
+
+
+***Avantages :***
+- Facilité d'utilisation : La mise en œuvre de SSE est relativement simple du côté du serveur et du côté client.
+- Faible surcharge réseau : SSE minimise la surcharge réseau en maintenant une connexion ouverte, évitant la nécessité
+   de requêtes fréquentes.
+
+***Limitations :***
+- Unidirectionnel : SSE ne prend en charge que la communication du serveur vers le client. Si le client doit envoyer
+   des données au serveur, une autre méthode, comme AJAX, serait nécessaire.
+- Support du Navigateur : Bien que largement pris en charge, SSE peut ne pas être pris en charge par certains
+   navigateurs plus anciens.
+
+En résumé, Server-Sent Events est une technologie qui permet au serveur d'envoyer des mises à jour en temps réel
+au client sur une connexion HTTP persistante, offrant ainsi une solution efficace pour les applications nécessitant une
+communication bidirectionnelle asynchrone.
+
+#### WebSockets
+Les WebSockets sont une technologie de communication bidirectionnelle en temps réel entre un navigateur web et un serveur.
+Contrairement aux approches traditionnelles comme le polling (interrogation régulière du serveur) ou le long polling
+(maintien d'une connexion ouverte jusqu'à l'arrivée de nouvelles données), les WebSockets établissent une connexion
+persistante qui permet un échange de données en temps réel entre le client et le serveur.
+
+Voici une brève explication du fonctionnement des WebSockets :
+
+1. **Établissement de la Connexion :**
+    - Le processus commence par une poignée de main (handshake) entre le client et le serveur, établissant une connexion
+   WebSocket via une requête HTTP mise à niveau.
+
+2. **Communication Bidirectionnelle :**
+    - Une fois la connexion établie, les deux parties (client et serveur) peuvent envoyer des données l'une à l'autre à
+   tout moment, sans avoir besoin d'attendre des requêtes ou des réponses spécifiques.
+
+3. **Basse Latence :**
+    - Les WebSockets offrent une latence réduite par rapport aux techniques de polling ou de long polling, car il n'y a
+   pas de délai d'attente entre les demandes et les réponses.
+
+4. **Protocole Simple :**
+    - Le protocole WebSocket est relativement simple et léger, facilitant la mise en œuvre et la gestion côté serveur.
+
+5. **Applications en Temps Réel :**
+    - Les WebSockets sont largement utilisés dans les applications en temps réel telles que les salons de discussion,
+   les jeux en ligne, les mises à jour en direct, etc.
+
+6. **Réintégration Automatique :**
+    - Les WebSockets peuvent gérer automatiquement la réintégration en cas de déconnexion temporaire, assurant une
+   expérience utilisateur continue.
+
+7. **Formats de Données :**
+    - Les données échangées via les WebSockets peuvent être au format binaire ou texte, offrant une flexibilité pour
+   différents types d'applications.
+
+8. **Fermeture de la Connexion :**
+    - La connexion WebSocket peut être fermée explicitement par le client ou le serveur, ou automatiquement en cas
+   de problème de réseau.
+
+En résumé, les WebSockets sont une technologie de communication en temps réel qui établit une connexion persistante
+entre le client et le serveur, permettant un échange bidirectionnel de données avec une faible latence, ce qui en fait
+un choix privilégié pour les applications nécessitant des mises à jour instantanées.
+
+
+## REST (Representational State Transfer)
+REST (Representational State Transfer) est un style architectural utilisé dans le développement des services web,
+basé sur des principes fondamentaux qui favorisent la simplicité, l'évolutivité, et l'interopérabilité.
+Voici un résumé des principaux concepts de REST :
+
+1. **Ressources :**
+    - Tout est une ressource, identifiable par une URI (Uniform Resource Identifier).
+    - Les ressources représentent des entités ou des concepts du système, comme des données ou des services.
+
+2. **Opérations sur les Ressources :**
+    - Les opérations standard (CRUD) sont appliquées aux ressources :
+        - **GET :** Récupérer une représentation de la ressource.
+        - **POST :** Créer une nouvelle ressource.
+        - **PUT :** Mettre à jour une ressource existante.
+        - **DELETE :** Supprimer une ressource.
+    
+          | Method | Meaning | OO notation |
+          | --- | --- | --- |
+          | GET | Fetch a representation for a resource | {resource}.GET(parameters) |
+          | POST | Modify the resource | {resource}.POST(resource<br>update) |
+          | PUT | Create a resource (the resource URI in the<br>method call refers to a non-existing resource, to<br>be created) | {resource}.PUT(new resource) |
+          | DELETE | Delete a resource | {resource}.DELETE() |
+
+3. **Représentation :**
+    - Les ressources peuvent avoir différentes représentations (XML, JSON, HTML, etc.).
+    - La représentation est ce qui est envoyé ou reçu lors des opérations sur les ressources.
+
+4. **Stateless (Sans État) :**
+    - Chaque requête du client au serveur doit contenir toutes les informations nécessaires à la compréhension et au
+   traitement de la requête.
+    - Le serveur ne garde pas de trace de l'état du client entre les requêtes.
+
+5. **Interaction Client-Serveur :**
+    - La séparation des préoccupations entre client et serveur permet une évolutivité et une maintenabilité accrues.
+    - Le client et le serveur peuvent évoluer indépendamment tant qu'ils respectent le contrat défini par l'interface REST.
+
+6. **Interface Uniforme :**
+    - Une interface uniforme simplifie et standardise les interactions entre le client et le serveur.
+    - Elle comprend des contraintes telles que l'identification des ressources par des URIs, la manipulation des
+   ressources via la représentation, l'auto-descriptivité des messages, etc.
+
+7. **Évolutivité :**
+    - REST favorise l'évolutivité en permettant l'ajout de nouvelles ressources ou fonctionnalités sans perturber les
+   clients existants.
+    - Les clients accèdent aux ressources via des URIs sans avoir besoin de connaître la structure interne du serveur.
+
+8. **État de l'Application (State of the Application) :**
+    - L'état de l'application est représenté et manipulé par les ressources, plutôt que d'être stocké du côté du serveur.
+
+En résumé, REST est un style architectural qui propose une approche simple et standardisée pour la conception de services
+web, en mettant l'accent sur l'utilisation efficace des ressources, la séparation des préoccupations, la simplicité de
+l'interface et l'évolutivité.
+
+
+
+
+## CoAP (Constrained Application Protocol)
+CoAP (Constrained Application Protocol) est un protocole de communication spécialisé pour les appareils à faible puissance
+et à faible bande passante, comme les capteurs, les actionneurs et les microcontrôleurs.
+Il est conçu pour être simple et léger, avec un faible encombrement mémoire et une faible utilisation de la bande passante.
+CoAP est basé sur le protocole UDP et utilise le format de message binaire de HTTP.
+
+![coap_overview.png](coap_overview.png)
+
+![coap_example.png](coap_example.png)
+
+# MQTT
+MQTT (Message Queuing Telemetry Transport) est un protocol de transport de messages léger et ouvert, conçu pour les
+environnements contraints comme l'Internet des Objets (IoT).
+Il est basé sur un modèle de publication/abonnement (pub/sub) où les éditeurs envoient des messages à des sujets, et les
+abonnés reçoivent les messages en fonction de leurs intérêts.
+MQTT est conçu pour être simple, ouvert, facile à mettre en œuvre et facile à étendre.
+
+MQTT est un protocol binaire.
+La version courante est MQTT 3.1.1. qui est basé sur TCP/IPv4.
+MQTT 5.0 est en cours de développement et est basé sur TCP/IPv6.
+
+## Caractéristiques
+- **Modèle Éditeur-Abonné :**
+Utilise un modèle de publication/abonnement où les éditeurs envoient des messages à des sujets, et les abonnés reçoivent
+les messages en fonction de leurs intérêts.
+
+- **Hiérarchie de Sujets :**
+Les sujets MQTT organisent les messages de manière hiérarchique, permettant un acheminement efficace des messages aux
+abonnés pertinents.
+    - Les sujets sont des chaînes de caractères délimitées par des barres obliques (`/`).
+    - Les caractères génériques (`+` et (`#` ou `*`)) peuvent être utilisés pour les abonnements aux sujets.
+    - Les caractères génériques peuvent être utilisés pour les abonnements aux sujets.
+
+- **Caractéristiques Légères :**
+Faible bande passante, faibles exigences en mémoire (RAM) et faible latence, adapté aux dispositifs embarqués avec des
+ressources limitées.
+
+- **Niveaux de Qualité de Service (QoS) :** Propose trois niveaux de QoS, permettant de gérer la fiabilité de la
+livraison des messages en fonction des besoins de l'application.
+    - QoS 0: "At most once" (au plus une fois) : Le message est envoyé une seule fois, sans garantie de livraison.
+    - QoS 1: "At least once" (au moins une fois) : Le message est envoyé au moins une fois, garantissant la livraison,
+    mais permettant les doublons.
+    - QoS 2: "Exactly once" (exactement une fois) : Le message est envoyé exactement une fois, garantissant la livraison,
+    sans doublons.
+  ![qos_mqtt.png](qos_mqtt.png)
+
+- **Sessions Persistantes :** Les sessions persistantes conservent les abonnements et les files d'attente même après
+la déconnexion, assurant la continuité du traitement des messages.
+
+- **Interopérabilité :** MQTT est compatible avec divers protocoles de messagerie. Il peut être utilisé avec RabbitMQ,
+par exemple, pour assurer l'interopérabilité entre différentes technologies de messagerie (AMQP, STOMP).
+
+## Fonctionnalités MQTT
+- **Retained Messages :**
+Les messages MQTT peuvent être conservés par le courtier et envoyés aux nouveaux abonnés.
+Cela permet aux abonnés de recevoir les dernières informations sans avoir besoin d'attendre la prochaine mise à jour.
+
+- **Last Will and Testament (LWT) :**
+Les clients peuvent définir un message LWT qui sera publié par le courtier si le client se déconnecte de manière inattendue.
+Cela permet aux clients de signaler leur état aux autres clients.
+
+- **Keep Alive :**
+Les clients peuvent envoyer des messages de ping au courtier pour maintenir la connexion active.
+Cela permet de détecter les connexions perdues et de les rétablir.
+
+- **Sécurité :**
+MQTT prend en charge le chiffrement TLS pour sécuriser les communications.
+Il prend également en charge l'authentification par nom d'utilisateur et mot de passe.
+