diff --git a/index.html b/index.html index 8a917d0..c031c03 100644 --- a/index.html +++ b/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: { diff --git a/infotro/SDi/coap_example.png b/infotro/SDi/coap_example.png new file mode 100644 index 0000000..23801b3 Binary files /dev/null and b/infotro/SDi/coap_example.png differ diff --git a/infotro/SDi/coap_overview.png b/infotro/SDi/coap_overview.png new file mode 100644 index 0000000..cfd47f8 Binary files /dev/null and b/infotro/SDi/coap_overview.png differ diff --git a/infotro/SDi/http_notifications.png b/infotro/SDi/http_notifications.png new file mode 100644 index 0000000..2e5821e Binary files /dev/null and b/infotro/SDi/http_notifications.png differ diff --git a/infotro/SDi/http_reminder.png b/infotro/SDi/http_reminder.png new file mode 100644 index 0000000..19a5d1e Binary files /dev/null and b/infotro/SDi/http_reminder.png differ diff --git a/infotro/SDi/iot_technologies.md b/infotro/SDi/iot_technologies.md index cf65f79..4b1747f 100644 --- a/infotro/SDi/iot_technologies.md +++ b/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://(default for http: 80; default for https: 443) | + | path | Local path on HTTP server | + | query | Supplementary information to clarify the resource (GET)
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
update) | + | PUT | Create a resource (the resource URI in the
method call refers to a non-existing resource, to
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. + diff --git a/infotro/SDi/qos_mqtt.png b/infotro/SDi/qos_mqtt.png new file mode 100644 index 0000000..290bab3 Binary files /dev/null and b/infotro/SDi/qos_mqtt.png differ