Wiki du LAMA (UMR 5127) - Contributions [fr]

Rest & Pub-Sub : protocole hybride pour l'IoT

2019-05-20T07:54:44Z

Rakotoanosy : /* Protocole Hybride */

__FORCETOC__L’avènement de l’Internet des Objets (IoT) depuis une dizaine d’années a fait apparaitre des problématiques propres aux protocoles de communications liées à ces objets. En effet, l’échange de données dans ce contexte nécessite de tenir compte (au moins) des paramètres suivants :
<ul>
<li>Autonomie énergétique souvent limitée</li>
<li>Faible puissance des processeurs et taille réduite de la mémoire</li>
<li>Disponibilité « aléatoire » de l’accès aux réseaux de communication</li>
</ul>
De nombreux protocoles cohabitent et la littérature du domaine foisonne d’exemples autour des réseaux dédiés (LORA, Sigfox, etc.) et des protocoles applicatifs (OPC-UA, MQTT, CoaP, XMPP) mais force est de constater que dans la réalité, ces solutions ne répondent pas toujours aux besoins des concepteurs qui leurs préfèrent encore le protocole HTTP. Celui-ci offre l’avantage d’implémenter un protocole applicatif (REST) en même temps qu’un protocole de transport de haut niveau (TCP/IP) permettant de passer les pare-feu. Cependant, la version actuelle d’HTTP ne répond pas vraiment aux critères énoncés précédemment. Depuis quelques années émerge donc l’idée d’enrichir HTTP pour créer un protocole hybride qui mêlerait les avantages de REST avec ceux proposés par les mécanismes de type Publish/Subscribe (MQTT, AMQP, JMS, etc.). En attendant cette éventuelle évolution, peut-on envisager de mettre en place un mécanisme de type Pub/Sub avec le protocole Websocket au-dessus d’HTTP ?

== MQTT ==
MQTT, Message Queuing Telemetry Transport, est un protocole publish/subscribe se basant sur le protocole TCP/IP.
Il a été créé par Andy Stanford-Clark et Arlen Nipper.

De façon concrète, MQTT permet à des appareils de publier des informations sur un sujet donné sur un broker (un serveur qui fonctionne comme un coursier) qui va les retransmettre aux appareils abonnés à ce sujet.

[[Fichier:Fonctionnement broker mqtt.png|600px|thumb|left|illustration d'un échange entre un client 1 "subscriber" et un client 2 "publisher"]]

MQTT gère aussi la qualité de service (d'une qualité 0 à une qualité 2):

Qualité 0 : le client qui publie une donnée ne reçoit aucune information par rapport à la confirmation de son arrivée.

Qualité 1 : le client qui publie reçoit la confirmation ou non que la donnée publiée a été reçue par le broker.

Qualité 2 : le client qui publie reçoit la confirmation ou non que la donnée donnée publiée a été reçue par le broker ainsi qu'un message lui indiquant que le client qui s'abonne a reçu la donnée.
===Mosquitto===
Mosquitto est un broker open-source qui se sert du protocole MQTT. Il permet une fois installé de se familiariser avec MQTT et le "publish/subscribe".

Nous nous en sommes servi ici sur une MachineVirtuel en publiant en localhost:

[[Fichier:Mosquitto exemple.png]]

Sur un premier terminal on s'abonne à un topic "température" et sur un deuxième terminal, on publie ensuite sur ce même topic des nombres (qui s'apparentent à des températures). Au fur et à mesure que nous publions ces informations, nous les recevons sur le premier terminal.
Mosquitto remplit bien ici son rôle de broker.

===Pub/Sub avec Python===

Nous avons ensuite développer un client ''publisher'' et un client ''subscriber'' en python grâce à la librairie paho-mqtt.
Pour plus de simplicité et éviter des problèmes de timing, nous avons tout regrouper en un seul programme :

import paho.mqtt.client as mqtt
import time

broker="test.mosquitto.org"

def envoi_message(client, QoS, message):
print("message reçu :", str(message.payload.decode("utf-8")))

client= mqtt.Client("client_test")
client.on_message=envoi_message

client.connect(broker)
print("connection")
client.loop_start()
client.subscribe("Cafetière/temperature_cafe")
print("Abonnement...")
time.sleep(1)
pub= input("entrez une température (un nombre):")
print("Publication...")
time.sleep(1)
client.publish("Cafetière/temperature_cafe",pub +"°C")
time.sleep(1)
client.disconnect()
print("deconnection")
client.loop_stop()
Comme broker, nous nous sommes servi ici d'un broker mis en libre service par mosquitto.

==REST==
REST (Representational State Transfer) aussi appeler restful est une architecture logicielle inventée par Roy Fielding qui se sert des verbes HTTP comme identifiant des opérations et des réponses HTTP comme représentation des ressources.

Une architecture REST est définie par 5 règles/contraintes :

- '''Client–serveur'''

- '''Sans état'''

- '''Avec mise en cache'''

- '''En couches'''

- '''Interface uniforme :'''

L'interface uniforme est la contrainte fondamentale d'une architecture REST car c'est celle-ci qui permet à chaque composant d'évoluer indépendamment. Elle est définie par 4 contraintes :
<ul>
<li>Identification des ressources dans les requêtes</li>
<li>Manipulation des ressources par des représentations</li>
<li>Messages auto-descriptifs</li>
<li>Hypermédia comme moteur d'état de l'application</li>
</ul>

===Service pub/sub avec REST===
On peut réaliser un équivalent de service pub/sub avec REST à l'aide de GET et de POST qui agissent sur une base de données gérée par un serveur :

[[Fichier:PubSub avec REST.png]]

Cette méthode comprend cependant de nombreux problèmes, notamment le fait que le client 1 ne sait pas si le client 2 a posté une donnée sur le serveur. On ne peut pas vraiment parler ici de service publish/subscribe car il n'y a pas d'abonnement, le client qui devrait s'abonner doit aller récupérer lui-même la donnée sans savoir si elle est bien dans la base de données du serveur.

==Protocole Hybride==

La technologie Pub/Sub et la technologie REST ont toutes deux leurs avantages et leurs inconvénients :

'''Avantages Pub/Sub :'''
<ul>
<li>Transfert rapide des informations</li>
<li>stockage automatique des messages </li>
<li>gestion de la qualité de service</li>
</ul>
'''Inconvénient Pub/Sub :'''
<ul>
<li>On ne peut pas faire d’action directe sur le message, on ne fait un traitement dessus que lorsqu'on l'a reçu.</li>
<li>protocole mqtt, qui est bloqué par certains pare-feu</li>
</ul>
'''Avantages REST :'''
<ul>
<li>protocole http(port 80) passe partout dans le monde</li>
<li>on peut traiter le message directement sur le serveur</li>
</ul>
'''Inconvénient REST :'''
<ul>
<li>On doit installer un serveur web, on doit gérer une base de données (ou XML, Json).</li>
</ul>

L'objectif du protocole hybride est de réaliser un système pub/sub tel que l'on ait :
<ul>
<li>un transfert rapide des informations</li>
<li>un stockage automatique des messages </li>
<li>une gestion de la qualité de service</li>
<li>le protocole http (port 80) de sorte à ce qu'il fonctionne partout dans le monde.</li>
</ul>

Pour cela, nous allons nous servir des Websockets.

===MQTT sur Websocket===

Le protocole Websocket est un protocole qui vise à développer un canal de communication web sur une connexion TCP.

Les objectifs de ce protocole étaient notamment de permettre au serveur l'envoi de données vers le client en mode push (sans que l'utilisateur n'ait à faire une requête).

Pour notre protocole hybride, l'idée serait d'ouvrir un canal de communication Websocket entre le broker et le client.

Lorsque l'on envoie le message mqtt au broker, on le place dans un paquet websocket puis on l'envoie au broker. Lorsque le serveur reçoit le paquet, il l'ouvre et traite le message Mqtt contenu comme il l'aurai fait avec un message mqtt "normal". On fait de même lorsque le broker envoie un message au client qui s'est abonné.

On peut l'illustrer de la façon suivante :

[[Fichier:MQTT sur Websocket.png|500px]]

Ainsi puisque le protocole Websocket se sert du port 80, on conserve les avantages de la technologie pub/sub avec Mqtt tout en évitant le problème des pare-feu que l'on pouvait rencontrer avec le protocole Mqtt.

==Sources==

[https://fr.wikipedia.org/wiki/Publish-subscribe Pub/Sub]

[https://fr.wikipedia.org/wiki/MQTT MQTT]

[https://pypi.org/project/paho-mqtt/ paho-mqtt]

[https://fr.wikipedia.org/wiki/Representational_state_transfer REST]

[https://fr.wikipedia.org/wiki/WebSocket Websocket]

Rest & Pub-Sub : protocole hybride pour l'IoT

2019-05-20T07:53:46Z

Rakotoanosy : /* Protocole Hybride */

__FORCETOC__L’avènement de l’Internet des Objets (IoT) depuis une dizaine d’années a fait apparaitre des problématiques propres aux protocoles de communications liées à ces objets. En effet, l’échange de données dans ce contexte nécessite de tenir compte (au moins) des paramètres suivants :
<ul>
<li>Autonomie énergétique souvent limitée</li>
<li>Faible puissance des processeurs et taille réduite de la mémoire</li>
<li>Disponibilité « aléatoire » de l’accès aux réseaux de communication</li>
</ul>
De nombreux protocoles cohabitent et la littérature du domaine foisonne d’exemples autour des réseaux dédiés (LORA, Sigfox, etc.) et des protocoles applicatifs (OPC-UA, MQTT, CoaP, XMPP) mais force est de constater que dans la réalité, ces solutions ne répondent pas toujours aux besoins des concepteurs qui leurs préfèrent encore le protocole HTTP. Celui-ci offre l’avantage d’implémenter un protocole applicatif (REST) en même temps qu’un protocole de transport de haut niveau (TCP/IP) permettant de passer les pare-feu. Cependant, la version actuelle d’HTTP ne répond pas vraiment aux critères énoncés précédemment. Depuis quelques années émerge donc l’idée d’enrichir HTTP pour créer un protocole hybride qui mêlerait les avantages de REST avec ceux proposés par les mécanismes de type Publish/Subscribe (MQTT, AMQP, JMS, etc.). En attendant cette éventuelle évolution, peut-on envisager de mettre en place un mécanisme de type Pub/Sub avec le protocole Websocket au-dessus d’HTTP ?

== MQTT ==
MQTT, Message Queuing Telemetry Transport, est un protocole publish/subscribe se basant sur le protocole TCP/IP.
Il a été créé par Andy Stanford-Clark et Arlen Nipper.

De façon concrète, MQTT permet à des appareils de publier des informations sur un sujet donné sur un broker (un serveur qui fonctionne comme un coursier) qui va les retransmettre aux appareils abonnés à ce sujet.

[[Fichier:Fonctionnement broker mqtt.png|600px|thumb|left|illustration d'un échange entre un client 1 "subscriber" et un client 2 "publisher"]]

MQTT gère aussi la qualité de service (d'une qualité 0 à une qualité 2):

Qualité 0 : le client qui publie une donnée ne reçoit aucune information par rapport à la confirmation de son arrivée.

Qualité 1 : le client qui publie reçoit la confirmation ou non que la donnée publiée a été reçue par le broker.

Qualité 2 : le client qui publie reçoit la confirmation ou non que la donnée donnée publiée a été reçue par le broker ainsi qu'un message lui indiquant que le client qui s'abonne a reçu la donnée.
===Mosquitto===
Mosquitto est un broker open-source qui se sert du protocole MQTT. Il permet une fois installé de se familiariser avec MQTT et le "publish/subscribe".

Nous nous en sommes servi ici sur une MachineVirtuel en publiant en localhost:

[[Fichier:Mosquitto exemple.png]]

Sur un premier terminal on s'abonne à un topic "température" et sur un deuxième terminal, on publie ensuite sur ce même topic des nombres (qui s'apparentent à des températures). Au fur et à mesure que nous publions ces informations, nous les recevons sur le premier terminal.
Mosquitto remplit bien ici son rôle de broker.

===Pub/Sub avec Python===

Nous avons ensuite développer un client ''publisher'' et un client ''subscriber'' en python grâce à la librairie paho-mqtt.
Pour plus de simplicité et éviter des problèmes de timing, nous avons tout regrouper en un seul programme :

import paho.mqtt.client as mqtt
import time

broker="test.mosquitto.org"

def envoi_message(client, QoS, message):
print("message reçu :", str(message.payload.decode("utf-8")))

client= mqtt.Client("client_test")
client.on_message=envoi_message

client.connect(broker)
print("connection")
client.loop_start()
client.subscribe("Cafetière/temperature_cafe")
print("Abonnement...")
time.sleep(1)
pub= input("entrez une température (un nombre):")
print("Publication...")
time.sleep(1)
client.publish("Cafetière/temperature_cafe",pub +"°C")
time.sleep(1)
client.disconnect()
print("deconnection")
client.loop_stop()
Comme broker, nous nous sommes servi ici d'un broker mis en libre service par mosquitto.

==REST==
REST (Representational State Transfer) aussi appeler restful est une architecture logicielle inventée par Roy Fielding qui se sert des verbes HTTP comme identifiant des opérations et des réponses HTTP comme représentation des ressources.

Une architecture REST est définie par 5 règles/contraintes :

- '''Client–serveur'''

- '''Sans état'''

- '''Avec mise en cache'''

- '''En couches'''

- '''Interface uniforme :'''

L'interface uniforme est la contrainte fondamentale d'une architecture REST car c'est celle-ci qui permet à chaque composant d'évoluer indépendamment. Elle est définie par 4 contraintes :
<ul>
<li>Identification des ressources dans les requêtes</li>
<li>Manipulation des ressources par des représentations</li>
<li>Messages auto-descriptifs</li>
<li>Hypermédia comme moteur d'état de l'application</li>
</ul>

===Service pub/sub avec REST===
On peut réaliser un équivalent de service pub/sub avec REST à l'aide de GET et de POST qui agissent sur une base de données gérée par un serveur :

[[Fichier:PubSub avec REST.png]]

Cette méthode comprend cependant de nombreux problèmes, notamment le fait que le client 1 ne sait pas si le client 2 a posté une donnée sur le serveur. On ne peut pas vraiment parler ici de service publish/subscribe car il n'y a pas d'abonnement, le client qui devrait s'abonner doit aller récupérer lui-même la donnée sans savoir si elle est bien dans la base de données du serveur.

==Protocole Hybride==

La technologie Pub/Sub et la technologie REST ont toutes deux leurs avantages et leurs inconvénients :

'''Avantages Pub/Sub :'''
<ul>
<li>Transfert rapide des informations</li>
<li>stockage automatique des messages </li>
<li>gestion de la qualité de service</li>
</ul>
'''Inconvénient Pub/Sub :'''
<ul>
<li>On ne peut pas faire d’action directe sur le message, on ne fait un traitement dessus que lorsqu'on l'a reçu.</li>
<li>protocole mqtt,qui est bloqué par certains pare-feu</li>
</ul>
'''Avantages REST :'''
<ul>
<li>protocole http(port 80) passe partout dans le monde</li>
<li>on peut traiter le message directement sur le serveur</li>
</ul>
'''Inconvénient REST :'''
<ul>
<li>On doit installer un serveur web, on doit gérer une base de données (ou XML, Json).</li>
</ul>

L'objectif du protocole hybride est de réaliser un système pub/sub tel que l'on ait :
<ul>
<li>un transfert rapide des informations</li>
<li>un stockage automatique des messages </li>
<li>une gestion de la qualité de service</li>
<li>le protocole http (port 80) de sorte à ce qu'il fonctionne partout dans le monde.</li>
</ul>

Pour cela, nous allons nous servir des Websockets.

===MQTT sur Websocket===

Le protocole Websocket est un protocole qui vise à développer un canal de communication web sur une connexion TCP.

Les objectifs de ce protocole étaient notamment de permettre au serveur l'envoi de données vers le client en mode push (sans que l'utilisateur n'ait à faire une requête).

Pour notre protocole hybride, l'idée serait d'ouvrir un canal de communication Websocket entre le broker et le client.

Lorsque l'on envoie le message mqtt au broker, on le place dans un paquet websocket puis on l'envoie au broker. Lorsque le serveur reçoit le paquet, il l'ouvre et traite le message Mqtt contenu comme il l'aurai fait avec un message mqtt "normal". On fait de même lorsque le broker envoie un message au client qui s'est abonné.

On peut l'illustrer de la façon suivante :

[[Fichier:MQTT sur Websocket.png|500px]]

Ainsi puisque le protocole Websocket se sert du port 80, on conserve les avantages de la technologie pub/sub avec Mqtt tout en évitant le problème des pare-feu que l'on pouvait rencontrer avec le protocole Mqtt.

==Sources==

[https://fr.wikipedia.org/wiki/Publish-subscribe Pub/Sub]

[https://fr.wikipedia.org/wiki/MQTT MQTT]

[https://pypi.org/project/paho-mqtt/ paho-mqtt]

[https://fr.wikipedia.org/wiki/Representational_state_transfer REST]

[https://fr.wikipedia.org/wiki/WebSocket Websocket]

Rest & Pub-Sub : protocole hybride pour l'IoT

2019-05-20T07:49:46Z

Rakotoanosy : /* REST */

__FORCETOC__L’avènement de l’Internet des Objets (IoT) depuis une dizaine d’années a fait apparaitre des problématiques propres aux protocoles de communications liées à ces objets. En effet, l’échange de données dans ce contexte nécessite de tenir compte (au moins) des paramètres suivants :
<ul>
<li>Autonomie énergétique souvent limitée</li>
<li>Faible puissance des processeurs et taille réduite de la mémoire</li>
<li>Disponibilité « aléatoire » de l’accès aux réseaux de communication</li>
</ul>
De nombreux protocoles cohabitent et la littérature du domaine foisonne d’exemples autour des réseaux dédiés (LORA, Sigfox, etc.) et des protocoles applicatifs (OPC-UA, MQTT, CoaP, XMPP) mais force est de constater que dans la réalité, ces solutions ne répondent pas toujours aux besoins des concepteurs qui leurs préfèrent encore le protocole HTTP. Celui-ci offre l’avantage d’implémenter un protocole applicatif (REST) en même temps qu’un protocole de transport de haut niveau (TCP/IP) permettant de passer les pare-feu. Cependant, la version actuelle d’HTTP ne répond pas vraiment aux critères énoncés précédemment. Depuis quelques années émerge donc l’idée d’enrichir HTTP pour créer un protocole hybride qui mêlerait les avantages de REST avec ceux proposés par les mécanismes de type Publish/Subscribe (MQTT, AMQP, JMS, etc.). En attendant cette éventuelle évolution, peut-on envisager de mettre en place un mécanisme de type Pub/Sub avec le protocole Websocket au-dessus d’HTTP ?

== MQTT ==
MQTT, Message Queuing Telemetry Transport, est un protocole publish/subscribe se basant sur le protocole TCP/IP.
Il a été créé par Andy Stanford-Clark et Arlen Nipper.

De façon concrète, MQTT permet à des appareils de publier des informations sur un sujet donné sur un broker (un serveur qui fonctionne comme un coursier) qui va les retransmettre aux appareils abonnés à ce sujet.

[[Fichier:Fonctionnement broker mqtt.png|600px|thumb|left|illustration d'un échange entre un client 1 "subscriber" et un client 2 "publisher"]]

MQTT gère aussi la qualité de service (d'une qualité 0 à une qualité 2):

Qualité 0 : le client qui publie une donnée ne reçoit aucune information par rapport à la confirmation de son arrivée.

Qualité 1 : le client qui publie reçoit la confirmation ou non que la donnée publiée a été reçue par le broker.

Qualité 2 : le client qui publie reçoit la confirmation ou non que la donnée donnée publiée a été reçue par le broker ainsi qu'un message lui indiquant que le client qui s'abonne a reçu la donnée.
===Mosquitto===
Mosquitto est un broker open-source qui se sert du protocole MQTT. Il permet une fois installé de se familiariser avec MQTT et le "publish/subscribe".

Nous nous en sommes servi ici sur une MachineVirtuel en publiant en localhost:

[[Fichier:Mosquitto exemple.png]]

Sur un premier terminal on s'abonne à un topic "température" et sur un deuxième terminal, on publie ensuite sur ce même topic des nombres (qui s'apparentent à des températures). Au fur et à mesure que nous publions ces informations, nous les recevons sur le premier terminal.
Mosquitto remplit bien ici son rôle de broker.

===Pub/Sub avec Python===

Nous avons ensuite développer un client ''publisher'' et un client ''subscriber'' en python grâce à la librairie paho-mqtt.
Pour plus de simplicité et éviter des problèmes de timing, nous avons tout regrouper en un seul programme :

import paho.mqtt.client as mqtt
import time

broker="test.mosquitto.org"

def envoi_message(client, QoS, message):
print("message reçu :", str(message.payload.decode("utf-8")))

client= mqtt.Client("client_test")
client.on_message=envoi_message

client.connect(broker)
print("connection")
client.loop_start()
client.subscribe("Cafetière/temperature_cafe")
print("Abonnement...")
time.sleep(1)
pub= input("entrez une température (un nombre):")
print("Publication...")
time.sleep(1)
client.publish("Cafetière/temperature_cafe",pub +"°C")
time.sleep(1)
client.disconnect()
print("deconnection")
client.loop_stop()
Comme broker, nous nous sommes servi ici d'un broker mis en libre service par mosquitto.

==REST==
REST (Representational State Transfer) aussi appeler restful est une architecture logicielle inventée par Roy Fielding qui se sert des verbes HTTP comme identifiant des opérations et des réponses HTTP comme représentation des ressources.

Une architecture REST est définie par 5 règles/contraintes :

- '''Client–serveur'''

- '''Sans état'''

- '''Avec mise en cache'''

- '''En couches'''

- '''Interface uniforme :'''

L'interface uniforme est la contrainte fondamentale d'une architecture REST car c'est celle-ci qui permet à chaque composant d'évoluer indépendamment. Elle est définie par 4 contraintes :
<ul>
<li>Identification des ressources dans les requêtes</li>
<li>Manipulation des ressources par des représentations</li>
<li>Messages auto-descriptifs</li>
<li>Hypermédia comme moteur d'état de l'application</li>
</ul>

===Service pub/sub avec REST===
On peut réaliser un équivalent de service pub/sub avec REST à l'aide de GET et de POST qui agissent sur une base de données gérée par un serveur :

[[Fichier:PubSub avec REST.png]]

Cette méthode comprend cependant de nombreux problèmes, notamment le fait que le client 1 ne sait pas si le client 2 a posté une donnée sur le serveur. On ne peut pas vraiment parler ici de service publish/subscribe car il n'y a pas d'abonnement, le client qui devrait s'abonner doit aller récupérer lui-même la donnée sans savoir si elle est bien dans la base de données du serveur.

==Protocole Hybride==

La technologie Pub/Sub et la technologie REST ont toutes deux leurs avantages et leurs inconvénients:

'''Avantages Pub/Sub :'''
<ul>
<li>Transfère rapide des informations</li>
<li>stockage des messages automatiques</li>
<li>gestion de la qualité de service</li>
</ul>
'''Inconvénient Pub/Sub :'''
<ul>
<li>On ne peut pas faire d’action direct sur le message, on ne fait un traitement dessus que lorsqu'on l'a reçu.</li>
<li>protocole mqtt,qui est bloquer par certain par feu</li>
</ul>
'''Avantages REST :'''
<ul>
<li>protocole http(port 80) passe partout dans le monde</li>
<li>on peut traiter le message directement sur le serveur</li>
</ul>
'''Inconvénient REST :'''
<ul>
<li>On doit installer un serveur web, on doit géré une base de donnée (ou XML, Json).</li>
</ul>

L'objectif du protocole hybride est de réaliser un système pub/sub tel que l'on ai:
<ul>
<li>un transfère rapide des informations</li>
<li>un stockage des messages automatiques</li>
<li>une gestion de la qualité de service</li>
<li>le protocole http (port 80) de sorte à ce qu'il fonctionne partout dans le monde.</li>
</ul>

Pour cela, nous allons nous servir des Websockets.

===MQTT sur Websocket===

Le protocole Websocket est un protocole qui vise à développer un canal de communication web sur une connexion TCP.

Les objectifs de ce protocole étaient notamment de permettre au serveur l'envoi de données vers le client en mode push (sans que l'utilisateur n'ai à faire une requête).

Pour notre protocole hybride, l'idée serai d'ouvrir un canal de communication Websocket entre le broker et le client.

Lorsque l'on envoie le message mqtt au broker, on le place dans un paquet websocket puis on l'envoi au broker. Lorsque le serveur reçoit le paquet, il l'ouvre et traite le message Mqtt contenu comme il l'aurai fait avec un message mqtt "normal". On fait de même lorsque le broker envoie un message au client qui c'est abonner.

On peut l'illustrer de la façon suivante :

[[Fichier:MQTT sur Websocket.png|500px]]

Ainsi puisque le protocole Websocket se sert du port 80, on conserve les avantages de la technologie pub/sub avec Mqtt tout en évitant le problème des par-feu que l'on pouvait rencontrer avec le protocole Mqtt.

==Sources==

[https://fr.wikipedia.org/wiki/Publish-subscribe Pub/Sub]

[https://fr.wikipedia.org/wiki/MQTT MQTT]

[https://pypi.org/project/paho-mqtt/ paho-mqtt]

[https://fr.wikipedia.org/wiki/Representational_state_transfer REST]

[https://fr.wikipedia.org/wiki/WebSocket Websocket]

Rest & Pub-Sub : protocole hybride pour l'IoT

2019-05-20T07:47:52Z

Rakotoanosy : /* MQTT */

__FORCETOC__L’avènement de l’Internet des Objets (IoT) depuis une dizaine d’années a fait apparaitre des problématiques propres aux protocoles de communications liées à ces objets. En effet, l’échange de données dans ce contexte nécessite de tenir compte (au moins) des paramètres suivants :
<ul>
<li>Autonomie énergétique souvent limitée</li>
<li>Faible puissance des processeurs et taille réduite de la mémoire</li>
<li>Disponibilité « aléatoire » de l’accès aux réseaux de communication</li>
</ul>
De nombreux protocoles cohabitent et la littérature du domaine foisonne d’exemples autour des réseaux dédiés (LORA, Sigfox, etc.) et des protocoles applicatifs (OPC-UA, MQTT, CoaP, XMPP) mais force est de constater que dans la réalité, ces solutions ne répondent pas toujours aux besoins des concepteurs qui leurs préfèrent encore le protocole HTTP. Celui-ci offre l’avantage d’implémenter un protocole applicatif (REST) en même temps qu’un protocole de transport de haut niveau (TCP/IP) permettant de passer les pare-feu. Cependant, la version actuelle d’HTTP ne répond pas vraiment aux critères énoncés précédemment. Depuis quelques années émerge donc l’idée d’enrichir HTTP pour créer un protocole hybride qui mêlerait les avantages de REST avec ceux proposés par les mécanismes de type Publish/Subscribe (MQTT, AMQP, JMS, etc.). En attendant cette éventuelle évolution, peut-on envisager de mettre en place un mécanisme de type Pub/Sub avec le protocole Websocket au-dessus d’HTTP ?

== MQTT ==
MQTT, Message Queuing Telemetry Transport, est un protocole publish/subscribe se basant sur le protocole TCP/IP.
Il a été créé par Andy Stanford-Clark et Arlen Nipper.

De façon concrète, MQTT permet à des appareils de publier des informations sur un sujet donné sur un broker (un serveur qui fonctionne comme un coursier) qui va les retransmettre aux appareils abonnés à ce sujet.

[[Fichier:Fonctionnement broker mqtt.png|600px|thumb|left|illustration d'un échange entre un client 1 "subscriber" et un client 2 "publisher"]]

MQTT gère aussi la qualité de service (d'une qualité 0 à une qualité 2):

Qualité 0 : le client qui publie une donnée ne reçoit aucune information par rapport à la confirmation de son arrivée.

Qualité 1 : le client qui publie reçoit la confirmation ou non que la donnée publiée a été reçue par le broker.

Qualité 2 : le client qui publie reçoit la confirmation ou non que la donnée donnée publiée a été reçue par le broker ainsi qu'un message lui indiquant que le client qui s'abonne a reçu la donnée.
===Mosquitto===
Mosquitto est un broker open-source qui se sert du protocole MQTT. Il permet une fois installé de se familiariser avec MQTT et le "publish/subscribe".

Nous nous en sommes servi ici sur une MachineVirtuel en publiant en localhost:

[[Fichier:Mosquitto exemple.png]]

Sur un premier terminal on s'abonne à un topic "température" et sur un deuxième terminal, on publie ensuite sur ce même topic des nombres (qui s'apparentent à des températures). Au fur et à mesure que nous publions ces informations, nous les recevons sur le premier terminal.
Mosquitto remplit bien ici son rôle de broker.

===Pub/Sub avec Python===

Nous avons ensuite développer un client ''publisher'' et un client ''subscriber'' en python grâce à la librairie paho-mqtt.
Pour plus de simplicité et éviter des problèmes de timing, nous avons tout regrouper en un seul programme :

import paho.mqtt.client as mqtt
import time

broker="test.mosquitto.org"

def envoi_message(client, QoS, message):
print("message reçu :", str(message.payload.decode("utf-8")))

client= mqtt.Client("client_test")
client.on_message=envoi_message

client.connect(broker)
print("connection")
client.loop_start()
client.subscribe("Cafetière/temperature_cafe")
print("Abonnement...")
time.sleep(1)
pub= input("entrez une température (un nombre):")
print("Publication...")
time.sleep(1)
client.publish("Cafetière/temperature_cafe",pub +"°C")
time.sleep(1)
client.disconnect()
print("deconnection")
client.loop_stop()
Comme broker, nous nous sommes servi ici d'un broker mis en libre service par mosquitto.

==REST==
REST (Representational State Transfer) aussi appeler restful est une architecture logiciel inventer par Roy Fielding qui se sert des verbes HTTP comme identifiant des opérations et des réponses HTTP comme représentation des ressources.

Une architecture REST est définit par 5 règles/contraintes :

- '''Client–serveur'''

- '''Sans état'''

- '''Avec mise en cache'''

- '''En couches'''

- '''Interface uniforme :'''

L'interface uniforme est la contraintes fondamentale d'une architecture REST car c'est celle-ci qui permet à chaque composant d'évoluer indépendamment. Elle est définit par 4 contraintes :
<ul>
<li>Identification des ressources dans les requêtes</li>
<li>Manipulation des ressources par des représentations</li>
<li>Messages auto-descriptifs</li>
<li>Hypermédia comme moteur d'état de l'application</li>
</ul>

===Service pub/sub avec REST===
On peut réaliser un équivalent de service pub/sub avec REST à l'aide de GET et de POST qui agissent sur une base de données géré par un serveur:

[[Fichier:PubSub avec REST.png]]

Cette méthode comprend cependant de nombreux problèmes, notamment le fait que le client 1 ne sais pas si le client 2 à poster une donnée sur le serveur. On ne peut pas vraiment parler ici de service publish/subscribe car il n'y a pas d'abonnement, le client qui devrait s'abonner doit aller récupérer lui-même la donnée sans savoir si elle est bien dans la base de données du serveur.

==Protocole Hybride==

La technologie Pub/Sub et la technologie REST ont toutes deux leurs avantages et leurs inconvénients:

'''Avantages Pub/Sub :'''
<ul>
<li>Transfère rapide des informations</li>
<li>stockage des messages automatiques</li>
<li>gestion de la qualité de service</li>
</ul>
'''Inconvénient Pub/Sub :'''
<ul>
<li>On ne peut pas faire d’action direct sur le message, on ne fait un traitement dessus que lorsqu'on l'a reçu.</li>
<li>protocole mqtt,qui est bloquer par certain par feu</li>
</ul>
'''Avantages REST :'''
<ul>
<li>protocole http(port 80) passe partout dans le monde</li>
<li>on peut traiter le message directement sur le serveur</li>
</ul>
'''Inconvénient REST :'''
<ul>
<li>On doit installer un serveur web, on doit géré une base de donnée (ou XML, Json).</li>
</ul>

L'objectif du protocole hybride est de réaliser un système pub/sub tel que l'on ai:
<ul>
<li>un transfère rapide des informations</li>
<li>un stockage des messages automatiques</li>
<li>une gestion de la qualité de service</li>
<li>le protocole http (port 80) de sorte à ce qu'il fonctionne partout dans le monde.</li>
</ul>

Pour cela, nous allons nous servir des Websockets.

===MQTT sur Websocket===

Le protocole Websocket est un protocole qui vise à développer un canal de communication web sur une connexion TCP.

Les objectifs de ce protocole étaient notamment de permettre au serveur l'envoi de données vers le client en mode push (sans que l'utilisateur n'ai à faire une requête).

Pour notre protocole hybride, l'idée serai d'ouvrir un canal de communication Websocket entre le broker et le client.

Lorsque l'on envoie le message mqtt au broker, on le place dans un paquet websocket puis on l'envoi au broker. Lorsque le serveur reçoit le paquet, il l'ouvre et traite le message Mqtt contenu comme il l'aurai fait avec un message mqtt "normal". On fait de même lorsque le broker envoie un message au client qui c'est abonner.

On peut l'illustrer de la façon suivante :

[[Fichier:MQTT sur Websocket.png|500px]]

Ainsi puisque le protocole Websocket se sert du port 80, on conserve les avantages de la technologie pub/sub avec Mqtt tout en évitant le problème des par-feu que l'on pouvait rencontrer avec le protocole Mqtt.

==Sources==

[https://fr.wikipedia.org/wiki/Publish-subscribe Pub/Sub]

[https://fr.wikipedia.org/wiki/MQTT MQTT]

[https://pypi.org/project/paho-mqtt/ paho-mqtt]

[https://fr.wikipedia.org/wiki/Representational_state_transfer REST]

[https://fr.wikipedia.org/wiki/WebSocket Websocket]

Rest & Pub-Sub : protocole hybride pour l'IoT

2019-05-20T07:44:01Z

Rakotoanosy :

__FORCETOC__L’avènement de l’Internet des Objets (IoT) depuis une dizaine d’années a fait apparaitre des problématiques propres aux protocoles de communications liées à ces objets. En effet, l’échange de données dans ce contexte nécessite de tenir compte (au moins) des paramètres suivants :
<ul>
<li>Autonomie énergétique souvent limitée</li>
<li>Faible puissance des processeurs et taille réduite de la mémoire</li>
<li>Disponibilité « aléatoire » de l’accès aux réseaux de communication</li>
</ul>
De nombreux protocoles cohabitent et la littérature du domaine foisonne d’exemples autour des réseaux dédiés (LORA, Sigfox, etc.) et des protocoles applicatifs (OPC-UA, MQTT, CoaP, XMPP) mais force est de constater que dans la réalité, ces solutions ne répondent pas toujours aux besoins des concepteurs qui leurs préfèrent encore le protocole HTTP. Celui-ci offre l’avantage d’implémenter un protocole applicatif (REST) en même temps qu’un protocole de transport de haut niveau (TCP/IP) permettant de passer les pare-feu. Cependant, la version actuelle d’HTTP ne répond pas vraiment aux critères énoncés précédemment. Depuis quelques années émerge donc l’idée d’enrichir HTTP pour créer un protocole hybride qui mêlerait les avantages de REST avec ceux proposés par les mécanismes de type Publish/Subscribe (MQTT, AMQP, JMS, etc.). En attendant cette éventuelle évolution, peut-on envisager de mettre en place un mécanisme de type Pub/Sub avec le protocole Websocket au-dessus d’HTTP ?

== MQTT ==
MQTT, Message Queuing Telemetry Transport, est un protocole publish/subscribe se basant sur le protocole TCP/IP.
Il a été créé par Andy Stanford-Clark et Arlen Nipper.

De façon concrète, MQTT permet à des appareils de publier des informations sur un sujet donné sur un broker (un serveur qui fonctionne comme un coursier) qui va les retransmettre aux appareils abonnés à ce sujet.

[[Fichier:Fonctionnement broker mqtt.png|600px|thumb|left|illustration d'un échange entre un client 1 "subscriber" et un client 2 "publisher"]]

MQTT gère aussi la qualité de service (d'une qualité 0 à une qualité 2):

Qualité 0: le client qui publie une donnée ne reçoit aucune information par rapport à la confirmation de son arrivé.

Qualité 1: le client qui publie reçoit la confirmation ou non que la donnée publier à été reçu par le broker.

Qualité 2: le client qui publie reçoit la confirmation ou non que la donnée publier à été reçu par le broker ainsi qu'un message lui indiquant que le client qui s'abonne à reçu la donnée.
===Mosquitto===
Mosquitto est un broker open-source qui se sert du protocole MQTT. Il permet une fois installé de se familiarisé avec MQTT et le "publish/subscribe".

Nous nous en somme servit ici sur une MachineVirtuel en publiant en localhost:

[[Fichier:Mosquitto exemple.png]]

Sur un premier terminal on s'abonne à un topic "température" et sur un deuxième terminal, on publie ensuite sur ce même topic des nombres (qui s'apparentent à des température). Au fur et à mesure que nous publions ces informations, nous les recevons sur le premier terminal.
Mosquitto remplit bien ici son rôle de broker.

===Pub/Sub avec Python===

Nous avons ensuite développer un client ''publisher'' et un client ''subscriber'' en python grâce à la librairie paho-mqtt.
Pour plus de simplicité et éviter des problèmes de timing, nous avons tout regrouper en un seul programme:

import paho.mqtt.client as mqtt
import time

broker="test.mosquitto.org"

def envoi_message(client, QoS, message):
print("message reçu :", str(message.payload.decode("utf-8")))

client= mqtt.Client("client_test")
client.on_message=envoi_message

client.connect(broker)
print("connection")
client.loop_start()
client.subscribe("Cafetière/temperature_cafe")
print("Abonnement...")
time.sleep(1)
pub= input("entrez une température (un nombre):")
print("Publication...")
time.sleep(1)
client.publish("Cafetière/temperature_cafe",pub +"°C")
time.sleep(1)
client.disconnect()
print("deconnection")
client.loop_stop()
Comme broker, nous nous somme servit ici d'un broker mit en libre service par mosquitto.

==REST==
REST (Representational State Transfer) aussi appeler restful est une architecture logiciel inventer par Roy Fielding qui se sert des verbes HTTP comme identifiant des opérations et des réponses HTTP comme représentation des ressources.

Une architecture REST est définit par 5 règles/contraintes :

- '''Client–serveur'''

- '''Sans état'''

- '''Avec mise en cache'''

- '''En couches'''

- '''Interface uniforme :'''

L'interface uniforme est la contraintes fondamentale d'une architecture REST car c'est celle-ci qui permet à chaque composant d'évoluer indépendamment. Elle est définit par 4 contraintes :
<ul>
<li>Identification des ressources dans les requêtes</li>
<li>Manipulation des ressources par des représentations</li>
<li>Messages auto-descriptifs</li>
<li>Hypermédia comme moteur d'état de l'application</li>
</ul>

===Service pub/sub avec REST===
On peut réaliser un équivalent de service pub/sub avec REST à l'aide de GET et de POST qui agissent sur une base de données géré par un serveur:

[[Fichier:PubSub avec REST.png]]

Cette méthode comprend cependant de nombreux problèmes, notamment le fait que le client 1 ne sais pas si le client 2 à poster une donnée sur le serveur. On ne peut pas vraiment parler ici de service publish/subscribe car il n'y a pas d'abonnement, le client qui devrait s'abonner doit aller récupérer lui-même la donnée sans savoir si elle est bien dans la base de données du serveur.

==Protocole Hybride==

La technologie Pub/Sub et la technologie REST ont toutes deux leurs avantages et leurs inconvénients:

'''Avantages Pub/Sub :'''
<ul>
<li>Transfère rapide des informations</li>
<li>stockage des messages automatiques</li>
<li>gestion de la qualité de service</li>
</ul>
'''Inconvénient Pub/Sub :'''
<ul>
<li>On ne peut pas faire d’action direct sur le message, on ne fait un traitement dessus que lorsqu'on l'a reçu.</li>
<li>protocole mqtt,qui est bloquer par certain par feu</li>
</ul>
'''Avantages REST :'''
<ul>
<li>protocole http(port 80) passe partout dans le monde</li>
<li>on peut traiter le message directement sur le serveur</li>
</ul>
'''Inconvénient REST :'''
<ul>
<li>On doit installer un serveur web, on doit géré une base de donnée (ou XML, Json).</li>
</ul>

L'objectif du protocole hybride est de réaliser un système pub/sub tel que l'on ai:
<ul>
<li>un transfère rapide des informations</li>
<li>un stockage des messages automatiques</li>
<li>une gestion de la qualité de service</li>
<li>le protocole http (port 80) de sorte à ce qu'il fonctionne partout dans le monde.</li>
</ul>

Pour cela, nous allons nous servir des Websockets.

===MQTT sur Websocket===

Le protocole Websocket est un protocole qui vise à développer un canal de communication web sur une connexion TCP.

Les objectifs de ce protocole étaient notamment de permettre au serveur l'envoi de données vers le client en mode push (sans que l'utilisateur n'ai à faire une requête).

Pour notre protocole hybride, l'idée serai d'ouvrir un canal de communication Websocket entre le broker et le client.

Lorsque l'on envoie le message mqtt au broker, on le place dans un paquet websocket puis on l'envoi au broker. Lorsque le serveur reçoit le paquet, il l'ouvre et traite le message Mqtt contenu comme il l'aurai fait avec un message mqtt "normal". On fait de même lorsque le broker envoie un message au client qui c'est abonner.

On peut l'illustrer de la façon suivante :

[[Fichier:MQTT sur Websocket.png|500px]]

Ainsi puisque le protocole Websocket se sert du port 80, on conserve les avantages de la technologie pub/sub avec Mqtt tout en évitant le problème des par-feu que l'on pouvait rencontrer avec le protocole Mqtt.

==Sources==

[https://fr.wikipedia.org/wiki/Publish-subscribe Pub/Sub]

[https://fr.wikipedia.org/wiki/MQTT MQTT]

[https://pypi.org/project/paho-mqtt/ paho-mqtt]

[https://fr.wikipedia.org/wiki/Representational_state_transfer REST]

[https://fr.wikipedia.org/wiki/WebSocket Websocket]

Rest & Pub-Sub : protocole hybride pour l'IoT

2019-05-20T07:43:01Z

Rakotoanosy :

__FORCETOC__L’avènement de l’Internet des Objets (IoT) depuis une dizaine d’années a fait apparaitre des problématiques propres aux protocoles de communications liées à ces objets. En effet, l’échange de données dans ce contexte nécessite de tenir compte (au moins) des paramètres suivants :
<ul>
<li>Autonomie énergétique souvent limitée</li>
<li>Faible puissance des processeurs et taille réduite de la mémoire</li>
<li>Disponibilité « aléatoire » de l’accès aux réseaux de communication</li>
</ul>
De nombreux protocoles cohabitent et la littérature du domaine foisonne d’exemples autour des réseaux dédiées (LORA, Sigfox, etc.) et des protocoles applicatifs (OPC-UA, MQTT, CoaP, XMPP) mais force est de constater que dans la réalité, ces solutions ne répondent pas toujours aux besoins des concepteurs qui leurs préfèrent encore le protocole HTTP. Celui-ci offre l’avantage d’implémenter un protocole applicatif (REST) en même temps qu’un protocole de transport de haut niveau (TCP/IP) permettant de passer les pare-feu. Cependant, la version actuelle d’HTTP ne répond pas vraiment aux critères énoncés précédemment. Depuis quelques années émerge donc l’idée d’enrichir HTTP pour créer un protocole hybride qui mêlerait les avantages de REST avec ceux proposés par les mécanismes de type Publish/Subscribe (MQTT, AMQP, JMS, etc.). En attendant cette éventuelle évolution, peut-on envisager de mettre en place un mécanisme de type Pub/Sub avec le protocole Websocket au-dessus d’HTTP ?

== MQTT ==
MQTT, Message Queuing Telemetry Transport, est un protocole publish/subscribe se basant sur le protocole TCP/IP.
Il a été créé par Andy Stanford-Clark et Arlen Nipper.

De façon concrète, MQTT permet à des appareils de publier des informations sur un sujet donné sur un broker (un serveur qui fonctionne comme un coursier) qui va les retransmettre aux appareils abonnés à ce sujet.

[[Fichier:Fonctionnement broker mqtt.png|600px|thumb|left|illustration d'un échange entre un client 1 "subscriber" et un client 2 "publisher"]]

MQTT gère aussi la qualité de service (d'une qualité 0 à une qualité 2):

Qualité 0: le client qui publie une donnée ne reçoit aucune information par rapport à la confirmation de son arrivé.

Qualité 1: le client qui publie reçoit la confirmation ou non que la donnée publier à été reçu par le broker.

Qualité 2: le client qui publie reçoit la confirmation ou non que la donnée publier à été reçu par le broker ainsi qu'un message lui indiquant que le client qui s'abonne à reçu la donnée.
===Mosquitto===
Mosquitto est un broker open-source qui se sert du protocole MQTT. Il permet une fois installé de se familiarisé avec MQTT et le "publish/subscribe".

Nous nous en somme servit ici sur une MachineVirtuel en publiant en localhost:

[[Fichier:Mosquitto exemple.png]]

Sur un premier terminal on s'abonne à un topic "température" et sur un deuxième terminal, on publie ensuite sur ce même topic des nombres (qui s'apparentent à des température). Au fur et à mesure que nous publions ces informations, nous les recevons sur le premier terminal.
Mosquitto remplit bien ici son rôle de broker.

===Pub/Sub avec Python===

Nous avons ensuite développer un client ''publisher'' et un client ''subscriber'' en python grâce à la librairie paho-mqtt.
Pour plus de simplicité et éviter des problèmes de timing, nous avons tout regrouper en un seul programme:

import paho.mqtt.client as mqtt
import time

broker="test.mosquitto.org"

def envoi_message(client, QoS, message):
print("message reçu :", str(message.payload.decode("utf-8")))

client= mqtt.Client("client_test")
client.on_message=envoi_message

client.connect(broker)
print("connection")
client.loop_start()
client.subscribe("Cafetière/temperature_cafe")
print("Abonnement...")
time.sleep(1)
pub= input("entrez une température (un nombre):")
print("Publication...")
time.sleep(1)
client.publish("Cafetière/temperature_cafe",pub +"°C")
time.sleep(1)
client.disconnect()
print("deconnection")
client.loop_stop()
Comme broker, nous nous somme servit ici d'un broker mit en libre service par mosquitto.

==REST==
REST (Representational State Transfer) aussi appeler restful est une architecture logiciel inventer par Roy Fielding qui se sert des verbes HTTP comme identifiant des opérations et des réponses HTTP comme représentation des ressources.

Une architecture REST est définit par 5 règles/contraintes :

- '''Client–serveur'''

- '''Sans état'''

- '''Avec mise en cache'''

- '''En couches'''

- '''Interface uniforme :'''

L'interface uniforme est la contraintes fondamentale d'une architecture REST car c'est celle-ci qui permet à chaque composant d'évoluer indépendamment. Elle est définit par 4 contraintes :
<ul>
<li>Identification des ressources dans les requêtes</li>
<li>Manipulation des ressources par des représentations</li>
<li>Messages auto-descriptifs</li>
<li>Hypermédia comme moteur d'état de l'application</li>
</ul>

===Service pub/sub avec REST===
On peut réaliser un équivalent de service pub/sub avec REST à l'aide de GET et de POST qui agissent sur une base de données géré par un serveur:

[[Fichier:PubSub avec REST.png]]

Cette méthode comprend cependant de nombreux problèmes, notamment le fait que le client 1 ne sais pas si le client 2 à poster une donnée sur le serveur. On ne peut pas vraiment parler ici de service publish/subscribe car il n'y a pas d'abonnement, le client qui devrait s'abonner doit aller récupérer lui-même la donnée sans savoir si elle est bien dans la base de données du serveur.

==Protocole Hybride==

La technologie Pub/Sub et la technologie REST ont toutes deux leurs avantages et leurs inconvénients:

'''Avantages Pub/Sub :'''
<ul>
<li>Transfère rapide des informations</li>
<li>stockage des messages automatiques</li>
<li>gestion de la qualité de service</li>
</ul>
'''Inconvénient Pub/Sub :'''
<ul>
<li>On ne peut pas faire d’action direct sur le message, on ne fait un traitement dessus que lorsqu'on l'a reçu.</li>
<li>protocole mqtt,qui est bloquer par certain par feu</li>
</ul>
'''Avantages REST :'''
<ul>
<li>protocole http(port 80) passe partout dans le monde</li>
<li>on peut traiter le message directement sur le serveur</li>
</ul>
'''Inconvénient REST :'''
<ul>
<li>On doit installer un serveur web, on doit géré une base de donnée (ou XML, Json).</li>
</ul>

L'objectif du protocole hybride est de réaliser un système pub/sub tel que l'on ai:
<ul>
<li>un transfère rapide des informations</li>
<li>un stockage des messages automatiques</li>
<li>une gestion de la qualité de service</li>
<li>le protocole http (port 80) de sorte à ce qu'il fonctionne partout dans le monde.</li>
</ul>

Pour cela, nous allons nous servir des Websockets.

===MQTT sur Websocket===

Le protocole Websocket est un protocole qui vise à développer un canal de communication web sur une connexion TCP.

Les objectifs de ce protocole étaient notamment de permettre au serveur l'envoi de données vers le client en mode push (sans que l'utilisateur n'ai à faire une requête).

Pour notre protocole hybride, l'idée serai d'ouvrir un canal de communication Websocket entre le broker et le client.

Lorsque l'on envoie le message mqtt au broker, on le place dans un paquet websocket puis on l'envoi au broker. Lorsque le serveur reçoit le paquet, il l'ouvre et traite le message Mqtt contenu comme il l'aurai fait avec un message mqtt "normal". On fait de même lorsque le broker envoie un message au client qui c'est abonner.

On peut l'illustrer de la façon suivante :

[[Fichier:MQTT sur Websocket.png|500px]]

Ainsi puisque le protocole Websocket se sert du port 80, on conserve les avantages de la technologie pub/sub avec Mqtt tout en évitant le problème des par-feu que l'on pouvait rencontrer avec le protocole Mqtt.

==Sources==

[https://fr.wikipedia.org/wiki/Publish-subscribe Pub/Sub]

[https://fr.wikipedia.org/wiki/MQTT MQTT]

[https://pypi.org/project/paho-mqtt/ paho-mqtt]

[https://fr.wikipedia.org/wiki/Representational_state_transfer REST]

[https://fr.wikipedia.org/wiki/WebSocket Websocket]

VISI201 CMI : visite de laboratoire

2019-05-20T00:06:10Z

Rakotoanosy : /* Sujets réalisés (2018-2019) */

* Cours du semestre 2 du parcours CMI Informatique (licence INFO).

* Responsable pour 2018--2019: Jacques-Olivier Lachaud
* Responsable pour 2017--2018: Jacques-Olivier Lachaud
* Responsable pour 2016--2017: Jacques-Olivier Lachaud

= Descriptif =

L'objectif du module est de faire découvrir les laboratoires, le monde de la recherche et les enseignants-chercheurs et chercheurs, ainsi que la réflexion scientifique. Cela se fait de deux manières.

D'abord, une partie de ce module consiste à assister à des séminaires dédiés aux étudiants CMI Informatique et Mathématique (1 fois par mois, les jeudi après-midi). [[http://www.lama.univ-savoie.fr/index.php?use=seminaires&&lang=fr&equipe=cmi&annee=1&lang=fr Planning des séminaires CMI]]

Ces séminaires "grand public" portent sur des sujets variées en informatique et mathématiques.

Les étudiants choisissent ensuite d'approfondir un sujet proposé par les enseignants, ou un sujet motivé de leur choix (en accord avec le responsable du module). Ce travail se fait en interaction avec un tuteur académique (5-6 contacts au moins). Ce travail personnel tuteuré donne lieu à la rédaction d'une synthèse sur le sujet sous forme d'une page wiki/web, ainsi que d'un mini-exposé.

= Sujets réalisés (2018-2019) =

* Transport optimal par coupe 1D et transfert de couleurs entre images
* [[Génération et résolution de labyrinthes II]] (Romain THEODET)
* [[Rest & Pub-Sub : protocole hybride pour l'IoT]] (Ewan RAKOTOANOSY)
* [[La suite de Conway et la classification périodique des "éléments"]] (Yohann THEPAUT)
* Initiation à la démonstration sur ordinateur et certification de logiciel
* [[Dilemme du prisonnier]] (Christophe CARMAGNAC)

= Sujets proposés (2018-2019) =

* Transport optimal par coupe 1D et transfert de couleurs entre images
* Génération et résolution de labyrinthes II
* REST + Pub/Sub : protocole hybride pour l’IoT
* La suite de Conway et la classification périodique des "éléments"
* Initiation à la démonstration sur ordinateur et certification de logiciel
* Algorithmes probabilistes/déterministes pour tester la primalité d'un entier
* Dilemme du prisonnier

== Transport optimal par coupe 1D et transfert de couleurs entre images ==

* Tuteur: Jacques-Olivier Lachaud
* Résumé: Le transfert de couleurs de l'image Y vers l'image X consiste à repeindre "au mieux" l'image X avec la palette de couleurs de l'image Y. L'image repeinte X' a alors les mêmes couleurs que l'image Y (mais les pixels ne sont pas répartis pareils). Voir l'exemple de transfert ci-dessous. Il existe plusieurs techniques de transfert de couleurs, mais nous étudierons une technique basée sur le transport optimal. Comme c'est un problème assez difficile dans le cas général, nous verrons une variante dite par coupe 1D, qui simplifiera considérablement le problème de transport.

[[Fichier:Ex-transfert-couleur-OT.png]]

* Objectifs:
*# comprendre ce qu'est une image niveaux couleur, et ce qu'on appelle le transfert de couleurs.
*# comprendre le principe du transport optimal (discret).
*# comprendre et décrire le principe du transport optimal par coupe 1D, et comment se fait le calcul du meilleur transport dans ce cas.
*# Coder un programme de transfert de couleur, qui prend deux images couleurs et réalise le transfert de couleurs.
*# On pourra ensuite réfléchir à quelques améliorations simples (espace couleur YUV, grouper les pixels).
* Liens pour démarrer
** Le vrai "Transport Optimal" est vite très mathématique (ce sont des mesures qui sont transportées), mais on peut l'aborder beaucoup plus simplement dans le cas discret (un nombre fini de valeurs) comme une simple assignation entre deux ensembles.
** [[https://en.wikipedia.org/wiki/Color_mapping Transfert de couleur Wikipedia]]
** [[https://hal.archives-ouvertes.fr/tel-01246096/file/hdr_hal2.pdf Habilitation de N. Papadakis]] (regardez les images plutôt).

== Génération et résolution de labyrinthes II ==

* Tuteur: François Boussion
* Résumé: On veut générer des labyrinthes aussi grands et complexes que possible, avec des murs dans une grille carré voire d'autres domaines. Comment faire pour qu'il y ait toujours un chemin de l'entrée à la sortie ? Comment faire pour qu'il n'y ait qu'un chemin ? Ensuite, comment trouver la sortie quand on est perdu dans le labyrinthe.
* Objectifs:
*# Comprendre comment représenter un labyrinthe avec une structure de données simple
*# Voir le lien avec la théorie des graphes et voir que le problème se résout de la même façon pour des grilles carrées, hexagonales ou autres.
*# Comprendre l'algorithme d'arbre couvrant minimum
*# Comprendre le principe du parcours en profondeur et de la récursivité
* Pour aller plus loin
*# coder la génération d'un labyrinthe et sa visualisation
*# introduire des poids pour varier le labyrinthe
*# comment faire un labyrinthe sur grille hexagonale avec des tableaux.
* Liens pour démarrer
** [[https://fr.wikipedia.org/wiki/Mod%C3%A9lisation_math%C3%A9matique_d%27un_labyrinthe Wikipedia]]
** [[https://en.wikipedia.org/wiki/Maze_generation_algorithm Version anglaise plus complète]]

== REST + Pub/Sub : protocole hybride pour l’IoT ==

* Tuteur: David Télisson
* Résumé: L’avènement de l’Internet des Objets (IoT) depuis une dizaine d’années a fait apparaitre des problématiques propres aux protocoles de communications liées à ces objets. En effet, l’échange de données dans ce contexte nécessite de tenir compte (au moins) des paramètres suivant :
*# Autonomie énergétique souvent limitée
*# Faible puissance des processeurs et taille réduite de la mémoire
*# Disponibilité « aléatoire » de l’accès aux réseaux de communication

De nombreux protocoles cohabitent et la littérature du domaine foisonne d’exemples autour des réseaux dédiées (LORA, Sigfox, etc.) et des protocoles applicatifs (OPC-UA, MQTT, CoaP, XMPP) mais force est de constater que dans la réalité, ces solutions ne répondent pas toujours aux besoins des concepteurs qui leurs préfèrent encore le protocole HTTP. Celui-ci offre l’avantage d’implémenter un protocole applicatif (REST) en même temps qu’un protocole de transport de haut niveau (TCP/IP) permettant de passer les pare-feu. Cependant, la version actuel d’HTTP ne répond pas vraiment aux critères énoncés précédemment.
Depuis quelques années émerge donc l’idée d’enrichir HTTP pour créer un protocole hybride qui mêlerait les avantages de REST avec ceux proposés par les mécanismes de type Publish/Subscribe (MQTT, AMQP, JMS, etc.). En attendant cette éventuelle évolution, peut-on envisager de mettre en place un mécanisme de type Pub/Sub avec le protocole Websocket au-dessus d’HTTP ?

* Objectifs:
*# Etudier et faire une synthèse des deux approches : REST et Pub/Sub
*# Implémentez un PoC (proof of concept) d’une solution hybride qui met en œuvre un mécanisme de Pub/Sub sur Websocket. .
*# Présenter un protocole de test pour valider ou invalider cette solution

* Liens pour démarrer :
** https://nsrc.org/workshops/2018/apricot/iot/presentations/mqttvsrest_v4.pdf
** http://www.tigli.fr/lib/exe/fetch.php?media=cours:tutorial_mqtt_mit_2015_2016.pdf
** https://openclassrooms.com/fr/courses/3449001-utilisez-des-api-rest-dans-vos-projets-web
** http://www.lirmm.fr/~tibermacin/ens/ws/expose.pdf

== La suite de Conway et la classification périodique des "éléments" ==

* Tuteur : Pierre Hyvernat
* La suite de Conway est la suite suivante : 1 ; 11 ; 21 ; 1211 ; 111221 ; ... Chaque terme est obtenu en "lisant" le terme précédent.
** "1" : un "1" -> 11
** "11" : deux "1" -> 21
** "21" : un "2", un "1" -> 1211
** "1211" : un "1", un "2", deux "1" -> 111221
** etc.
Cette suite possède des propriétés étonantes données par le théorème "chimique", le théorème "arithmétique" et le théorème "cosmologique".
* Objectifs :
*# comprendre les énoncés de ces théorèmes, et l'idée de la preuve du premier.
*# programmer la suite de Conway pour retrouver la classification des "atomes"
*# écrire un programme pour calculer expérimentalement une approximation de la constante "lambda" ainsi que des fréquences respectives des différents atomes.
*# écrire un programme pour calculer la suite de Robinson, une variante plus simple de la suite de Conway

* Liens pour commencer
** [[https://fr.wikipedia.org/wiki/Suite_de_Conway suite de Conway]]
** [[https://fr.wikipedia.org/wiki/Suite_de_Robinson suite de Robinson]]

== [[Initiation à la démonstration sur ordinateur et certification de logiciel]] ==

* Tuteur: Tom Hirschowitz
* Résumé: [[https://coq.inria.fr Coq]] est un logiciel de mathématiques sur ordinateur, grâce auquel des programmes élaborés ont pu être certifiés ces dernières années.
* Objectifs:
*# prendre en main le logiciel [[https://coq.inria.fr Coq]] de démonstration sur ordinateur,
*# programmer certaines démonstrations basiques en Coq,
*# suivre le début du cours [[https://www.cis.upenn.edu/~bcpierce/sf Software Foundations]],
* Pour aller plus loin : Software Foundations est un cours assez long et très bien fait, il y aura suffisamment à faire. Eventuellement, selon l'intérêt de l'étudiant, étude des fondements mathématiques de Coq.
* Liens pour démarrer
** [[https://www.cis.upenn.edu/~bcpierce/sf Software Foundations]]
** [[https://coq.inria.fr Coq]]

== Algorithmes probabilistes/déterministes pour tester la primalité d'un entier ==

* Tuteur : Sébastien Tavenas
* Pouvoir tester si un entier est un nombre premier semble être une brique de base si l'on souhaite faire de l'arithmétique sur un ordinateur. Le crible d'Érathostène enseigné dans les petites classes se montre beaucoup trop lent en pratique. L'algorithme probabiliste utilisé le plus rapide est le test de Fermat. Or, si on regarde les algorithmes des librairies "génériques", on peut s'apercevoir que la fonction 'mpz_probab_prime_p' de la librairie 'gmp' sur c++ utilise un test probabiliste de Miller-Rabin, la fonction 'isPrime' de la classe 'Prime' dans java utilise aussi un test de Miller-Rabin mais qui est déterminisé, alors que la fonction 'isprime' de la librairie 'sympy' dans python effectue un test de Miller-Rabin si l'entier est plus petit que 2^64 et un test BPSW fort si l'entier est plus grand. Ainsi, une fonction déjà implémentée de test de primalité peut se tromper ou non, être instantanée ou moins. Que dire alors de l'algorithme polynomial déterministe et toujours correct proposé par AKS?
* Objectifs :
*# Comprendre quelques tests de primalité et comment l'aléatoire est utilisé dans ces algorithmes
*# Comprendre la notion de nombre pseudopremier qui explique, entre autre, quand il vaut mieux utiliser le test de Fermat ou celui de Miller-Rabin
*# Programmer quelques uns des ces tests et les comparer
*# Essayer de dérandomiser ces tests à l'aide de hitting-sets précalculés

* Liens pour commencer
** [[https://en.wikipedia.org/wiki/Primality_test Tests de primalité]]

== Dilemme du prisonnier ==

* Tuteur: Gerald Cavallini
* Résumé: Le dilemme du prisonnier caractérise en théorie des jeux une situation où deux joueurs auraient
intérêt à coopérer, mais où, en l’absence de communication entre les deux joueurs, chacun choisira
de trahir l'autre si le jeu n'est joué qu'une fois.

On peut informatiquement modéliser ce dilemme à l’aide de matrices de gains et conserver la
mémoire des choix de l’adversaire. Ce modèle appliqué à un grand nombre d’individus peut être
utilisé pour comprendre l’émergence de stratégies stables dans l’économie, l’écologie, l’évolution
des espèces ...

On peut visualiser spatialement les interactions entre individus en les représentants par des pixels et
en leurs associant une couleur en fonction de leurs stratégies.

[[Fichier:Dilemme.png]]

* Objectifs
*# Comprendre le dilemme du prisonnier
*# Comprendre la notion de stratégie
*# Penser un modèle spatiale pour « opposer » des individus qui appliquent des stratégies différentes
*# Développer une interface pour visualiser dans le temps l’évolution d’une population d’individus adoptants des stratégies différentes.

* Lien :
*# [https://fr.wikipedia.org/wiki/Dilemme_du_prisonnier Dilemme du prisonnier Wikipedia]
*# [http://cormas.cirad.fr/fr/applica/dps.htm Site spécifique]

= Sujets réalisés (2017-2018) =

* [[VISI201 Analyse syntaxique (Tristan Porteries, 2018)]]
* [[Segmentation d'image par détection de contours et algorithme "ligne de partage des eaux"]] (Nils Ruet, 2018)
* [[Fouille de données textuelles à partir des "Exercices de style" de R. Queneau]] (Rémi Bouvier, 2018)
* [[Transformées en distance, diagramme de Voronoi et applications en geometry processing]] (Robin Wagner, 2018)
* [[Pavages de Penrose]] (Brunelle Cordier-Pierre-Bès, 2018)

= Sujets proposés (2017-2018) =

* Segmentation d'image par détection de contours et algorithme "ligne de partage des eaux"
* Initiation à la démonstration sur ordinateur et certification de logiciel
* Fouille de données textuelles à partir des "Exercices de style" de R. Queneau
* Transformées en distance, diagramme de Voronoi et applications en geometry processing
* Pavages de Penrose

== [[Segmentation d'image par détection de contours et algorithme "ligne de partage des eaux"]] ==

* Tuteur: Jacques-Olivier Lachaud
* Résumé: La segmentation d'image vise à identifier les régions d'intérêt dans une image. Typiquement, une région d'intérêt est une zone de l'image plutôt homogène (les pixels ont des valeurs proches) et le contour entre deux régions d'intérêt est tracé là où les valeurs subissent de fortes variations. La méthode de segmentation proposée ici suit ce principe en enchaînant deux calculs: (1) un premier traitement calcule une image "gradient" et fabrique une image dont les valeurs élevées correspondent à des zones de fortes variations, (2) le deuxième algorithme voit cette image comme un relief 3D et identifie ses bassins hydrographiques. Cette identification des lignes de partage des eaux permet de découper l'image en ses zones d'intérêt.
* Objectifs:
*# comprendre ce qu'est une image niveaux de gris ou couleur, ce qu'est le gradient d'une image et ce qu'on appelle segmentation d'image.
*# décrire un algorithme de calcul du gradient d'une image, e.g. le filtre de Sobel, voire les convolutions par dérivées de Gaussienne.
*# décrire le principe de ligne de partage des eaux ("watershed" en anglais), ses différentes définitions équivalentes, et les différents types d'algorithmes pour la calculer.
*# Coder un programme de segmentation d'image, qui prend une image (niveaux de gris) en entrée, calcule son gradient, et extrait les bassins de sa ligne de partage des eaux.
* Liens pour démarrer
** [[https://en.wikipedia.org/wiki/Watershed_(image_processing) Watershed Wikipedia]]
** Luc Vincent and Pierre Soille. Watersheds in digital spaces: an efficient algorithm based on immersion simulations. In IEEE Transactions on Pattern Analysis and Machine Intelligence, Vol. 13, Num. 6 (1991), pages 583–598 [[https://pdfs.semanticscholar.org/a381/9dda9a5f00dbb8cd3413ca7422e37a0d5794.pdf PDF]]

== [[Initiation à la démonstration sur ordinateur et certification de logiciel]] ==

* Tuteur: Tom Hirschowitz
* Résumé: [[https://coq.inria.fr Coq]] est un logiciel de mathématiques sur ordinateur, grâce auquel des programmes élaborés ont pu être certifiés ces dernières années.
* Objectifs:
*# prendre en main le logiciel [[https://coq.inria.fr Coq]] de démonstration sur ordinateur,
*# programmer certaines démonstrations basiques en Coq,
*# suivre le début du cours [[https://www.cis.upenn.edu/~bcpierce/sf Software Foundations]],
* Pour aller plus loin : Software Foundations est un cours assez long et très bien fait, il y aura suffisamment à faire. Eventuellement, selon l'intérêt de l'étudiant, étude des fondements mathématiques de Coq.
* Liens pour démarrer
** [[https://www.cis.upenn.edu/~bcpierce/sf Software Foundations]]
** [[https://coq.inria.fr Coq]]

== [[Fouille de données textuelles à partir des "Exercices de style" de R. Queneau]] ==

* Tuteur: Laurent Vuillon
* Résumé: L'idée de ce projet est de se familiariser avec les techniques de fouille de données textuelles à partir des "Exercices de style" de R. Queneau (https://fr.wikipedia.org/wiki/Exercices_de_style). On cherchera à comprendre la structure du vocabulaire du corpus de textes, à utiliser les techniques de TF/IDF pour extraire les mots significatifs du corpus puis à tester les techniques de LDA (Allocation de Dirichlet latente) pour extraire automatiquement les thématiques du corpus afin de construire des regroupements par thème. On pourra également proposer des visualisations des résultats afin de rendre accessible visuellement l'analyse de données produite sur le corpus de documents.
* Objectifs: Introduction à la fouille de données au travers d'un cas pratique
* Pour aller plus loin
** http://blogperso.univ-rennes1.fr/stephane.tuffery/
** http://www.editionstechnip.com/en/catalogue-detail/1005/data-mining-et-statistique-decisionnelle.html
* Liens pour démarrer
** https://fr.wikipedia.org/wiki/Exploration_de_donn%C3%A9es
** https://fr.wikipedia.org/wiki/TF-IDF
** "Recherche d'information : applications, modèles et algorithmes; Data mining, décisionnel et big data" de Amini et Gaussier aux éditions Eyrolles.

== [[Transformées en distance, diagramme de Voronoi et applications en geometry processing]] ==

* Tuteur: Jacques-Olivier Lachaud
* Résumé: Les nuages de points constituent une source de données géométriques importantes (cf LIDAR scanner, 3D scanner) et qui permet de construire des modèles géométriques 3D d'objets réels. La difficulté est de transformer ces nuages de points en des surfaces (souvent des surfaces triangulées, c'est-à-dire des triangles collés entre eux). Un outil essentiel dans ce processus est la transformée en distance, le diagramme de Voronoi (et son dual la triangulation de Delaunay). A partir de ces outils, des algorithmes existent pour reconstruire les surfaces, estimer la géométrie du nuage de point (sa normale par exemple), etc.
* Objectifs:
*# Comprendre ce qu'est une distance, une transformée en distance, et un diagramme de Voronoi. Comprendre ce qu'est la stabilité d'une fonction.
*# Identifier les propriétés des diagrammes de Voronoi, de leur dual la triangulation de Delaunay, et comprendre leurs variantes comme les diagrammes de puissance
*# Identifier le lien avec l'axe médian et les squelettes
*# Décrire les principaux algorithmes de calcul des transformées en distance et du diagramme de Voronoi, pour des nuages de point quelconques ou pour des nuages de points à coordonnées entières.
*# Présenter un algorithme de reconstruction de surface utilisant le diagramme de Voronoi
*# Coder un algorithme de calcul du diagramme de Voronoi et, si le temps le permet, un algorithme de reconstruction de surface.

* Liens pour démarrer
** [[https://en.wikipedia.org/wiki/Voronoi_diagram Diagramme de Voronoi Wikipedia]]
** [[https://en.wikipedia.org/wiki/Distance_transform Transformée en distance Wikipedia]]
** [[https://en.wikipedia.org/wiki/Topological_skeleton Squelette Wikipedia]]
** [[http://dgtal.org/doc/nightly/moduleVolumetric.html Transformées discrètes en distance DGtal]]

== [[Pavages de Penrose]] ==

* Tuteur : Pierre Hyvernat
* Résumé : le "cerf-volant" et la "fléchette" de Penrose sont deux tuiles qui permettent de recouvrir le plan, mais uniquement de manière non-périodique. Autrement dit, les pavages correspondants ne sont pas obtenus en répétant un même motif de manière régulière. A cause de ceci, il n'est pas évident de générer un tel pavage.

[[Fichier:P2.png]]

* Objectifs
*# comprendre les notion de pavage périodique, non périodique et apériodique,
*# comprendre la méthode "inflation / déflation" pour générer des pavages de Penrose des différents types,
*# comprendre le lien entre les 2 (ou 3) types de pavage de Penrose
*# écrire un programme permettant de générer de tels pavages : avec la méthode "inflation / déflation" et avec la méthode "grille de de Bruijn"
*# utiliser ces méthodes pour générer d'autres types de pavages apériodique.

* Liens pour démarrer
** [[https://fr.wikipedia.org/wiki/Pavage_de_Penrose pavage de Penrose (wikipedia]]
** [[https://www.maa.org/sites/default/files/pdf/pubs/focus/Gardner_PenroseTilings1-1977.pdf Penrose Tiling (Marting Gardner, en anglais)]]

== [[Algorithmes d'analyse syntaxique]] ==

* Tuteur : Pierre Hyvernat

* Résumé : le code source d'un programme, d'un fichier de configuration d'un serveur de base de données ou le code d'une page web sont des données ''textuelles'' et ''structurées''. Il est possible de définir exactement quelles données sont correctes, et quelle est leur signification. (Cela est beaucoup plus difficile pour des textes en langue naturelle par exemple.) En ce sens, il est possible de lire, d'interpréter ces données à l'aide d'un programme. On parle ''d'analyseur syntaxique'' ou de ''parseur''. Il existe de nombreux outils pour faire ça automatiquement, mais il est parfois important (et toujours intéressant) de comprendre les mécanismes correspondant. C'est ce que ce stage propose de faire.

* Objectifs :
*# étudier la formalisation du problème à travers la notion de ''langage'' et les premiers étages de la hiérachie de Chomsky (langages réguliers et grammaires hors contexte).
*# comprendre le lien entre les langages et les automates (automates finis / automates à pile)
*# implémenter un parseur "from scratch" et le tester sur des petits exemples simples, "à la main", soit en calculant "à la volée" la sémantique d'un langage, soit en produisant des "arbres de syntaxe abstraits", qui pourront être analysés par la suite,
*# comprendre les restrictions souvent imposées sur les grammaires afin d'améliorer l'efficacité du parseur (''LL*(k)'', ''LR'', etc.)
*# à partir de là, de nombreuses pistes sont ouvertes :
*#* essayer d'écrire un petit outils qui puisse lire une grammaire, et générer un parseur pour cette grammaire,
*#* comparer l'approche "automate" avec l'approche "combinateurs" et "parseur récursifs"
*#* améliorer l'efficacité des parseurs produits
*#* ajouter des fonctionnalités,
*#* ...

* Liens pour démarrer :
** [[https://en.wikipedia.org/wiki/Parsing page wikipedia "parsing"]]
** [[https://en.wikipedia.org/wiki/Recursive_descent_parser page wikipedia "recursive descent parser"]]
** Le livre référence sur le parsing est probablement "Compilers: Principles, Techniques, and Tools" de Aho, Sethi et Ullman (le "dragon book")
** [[https://web.stanford.edu/class/archive/cs/cs143/cs143.1128/ exemples de notes cours de compilation]]

= Sujets réalisés (2016-2017) =

* [[Algorithme de rendu de scène 3D par Z-buffer]]
* [[Traitement d'image]]
* [[Nim et la théorie des jeux impartiaux]]
* [[Calculabilité et modèles de calcul]]
* [[Génération et résolution de labyrinthes]]

= Sujets proposés (2016-2017) =

== [[Algorithme de rendu de scène 3D par Z-buffer]] ==

* Tuteur: Jacques-Olivier Lachaud
* Résumé: Le Z-buffer est un algorithme classique de rendu de scène 3D. C'est celui (avec quelques variantes) qui est implémenté dans nos cartes graphiques 3D et qui permet de visualiser des scènes extrêmement complexes en temps réel (typiquement 24 image/s).
* Objectifs:
*# décrire le principe de la projection 3D vers 2D
*# décrire la rastérisation des triangles sur une image en pixel
*# expliquer le principe du Z-buffer qui permet de gérer le fait que certains objets sont cachés par d'autres
*# expliquer comment les couleurs sont calculées par pixel
*# indiquer les qualités et limitations de l'algorithme
* Pour aller plus loin
*# mettre du code démo (WebGL) avec quelques explications sur le pipeline graphique OpenGL
*# expliquer comment on peut utiliser cet algorithme pour calculer des ombres (shadow map)
* Liens pour démarrer
** [[https://fr.wikipedia.org/wiki/Z-buffer Wikipedia]]
** [[https://www.scratchapixel.com/lessons/3d-basic-rendering/rasterization-practical-implementation/overview-rasterization-algorithm Scratch a pixel]]

== [[Traitement d'image]] ==

* Tuteur: Jacques-Olivier Lachaud
* Résumé: Le traitement d'image rassemble tous les algorithmes utilisés pour transformer les images, les améliorer, éliminer certaines perturbations, augmenter ou diminuer le contraste, changer les couleurs vers d'autres couleurs, éliminer le flou ou les yeux rouges, faire du cartooning pour un rendu moins photo-réaliste, etc.
* Objectifs:
*# identifier les grandes familles de traitement: restauration, égalisation, élimination du flou de déplacement, segmentation, etc
*# identifier les grandes familles de techniques: filtrage spatial, filtrage fréquentiel, optimisation, etc
*# comprendre les points communs et différences entre le traitement des images noir et blanc et le traitement des images couleurs.
*# choisir un ou deux algorithmes de traitement et les expliquer en détails
* Pour aller plus loin
*# Coder un algorithme de traitement d'image simple (e.g, un filtrage médian, ou un algo qui transporte les couleurs d'une photo vers une autre photo)

* Liens pour démarrer
** [[https://fr.wikipedia.org/wiki/Traitement_d%27images Wikipedia]]
** [[http://www.ipol.im/ Image Processing on line]] (permet de tester en ligne des algorithmes sur vos images)

== [[Nim et la théorie des jeux impartiaux]] ==

* Tuteur: Pierre Hyvernat

* Étudiant : Luca Chapelle

* Le jeu de Nim (aussi appelé jeu des allumettes) est l'un des premiers jeux ayant été analysé mathématiquement (par Charles Bouton en 1901). Les stratégies gagnantes peuvent être calculées en utilisant le développement en base 2 des nombres, et l'opération d'"addition de Nim" (XOR). La théorie de ce type de jeux (jeux "impartiaux") est assez simple, mais de nombreuses instances de jeux sont encore non résolues.
* Objectifs:
*# comprendre la théorie du jeu de Nim (et la programmer)
*# comprendre le théorème de Sprague Grundy qui montre que tout jeu impartial est équivalent à un jeu de nim
*# regarder quelques autres exemples de tels jeux : jeu de Nim déguisés, ou jeux véritablement différents
*# programmer une version naịve de recherche de stratégie basée sur le théorème de Sprague-Grundy pour quelques jeux

* Liens pour commencer
** [https://fr.wikipedia.org/wiki/Jeux_de_Nim jeu de Nim]
** [https://fr.wikipedia.org/wiki/Th%C3%A9or%C3%A8me_de_Sprague-Grundy théorème de Sprague Grundy]
** [https://fr.wikipedia.org/wiki/Jeu_de_Grundy jeu de Grundy]

== La suite de Conway et la classification périodique des "éléments" ==

* Tuteur : Pierre Hyvernat
* La suite de Conway est la suite suivante : 1 ; 11 ; 21 ; 1211 ; 111221 ; ... Chaque terme est obtenu en "lisant" le terme précédent.
** "1" : un "1" -> 11
** "11" : deux "1" -> 21
** "21" : un "2", un "1" -> 1211
** "1211" : un "1", un "2", deux "1" -> 111221
** etc.
Cette suite possède des propriétés étonantes données par le théorème "chimique", le théorème "arithmétique" et le théorème "cosmologique".
* Objectifs :
*# comprendre les énoncés de ces théorèmes, et l'idée de la preuve du premier.
*# programmer la suite de Conway pour retrouver la classification des "atomes"
*# écrire un programme pour calculer expérimentalement une approximation de la constante "lambda" ainsi que des fréquences respectives des différents atomes.
*# écrire un programme pour calculer la suite de Robinson, une variante plus simple de la suite de Conway

* Liens pour commencer
** [[https://fr.wikipedia.org/wiki/Suite_de_Conway suite de Conway]]
** [[https://fr.wikipedia.org/wiki/Suite_de_Robinson suite de Robinson]]

== Initiation à la démonstration sur ordinateur et certification de logiciel ==

* Tuteur: Tom Hirschowitz
* Résumé: [[https://coq.inria.fr Coq]] est un logiciel de mathématiques sur ordinateur, grâce auquel des programmes élaborés ont pu être certifiés ces dernières années.
* Objectifs:
*# prendre en main le logiciel [[https://coq.inria.fr Coq]] de démonstration sur ordinateur,
*# programmer certaines démonstrations basiques en Coq,
*# suivre le début du cours [[https://www.cis.upenn.edu/~bcpierce/sf Software Foundations]],
* Pour aller plus loin : Software Foundations est un cours assez long et très bien fait, il y aura suffisamment à faire. Eventuellement, selon l'intérêt de l'étudiant, étude des fondements mathématiques de Coq.
* Liens pour démarrer
** [[https://www.cis.upenn.edu/~bcpierce/sf Software Foundations]]
** [[https://coq.inria.fr Coq]]

== [[Calculabilité et modèles de calcul]] ==

* Tuteur: Rodolphe Lepigre
* Résumé: Une fonction f sur l'ensemble des entiers naturels est dite calculable s'il existe une procedure effective (ou un algorithme) qui permet, étant donné un entier n, de calculer f(n) en temps fini. Il existe divers modèles de calcul qui permettent de représenter toutes les fonctions calculables : machines de Turing, λ-calcul, automates cellulaires, ...
* Objectifs:
*# comprendre la notion de fonction calculable,
*# comparer l'ensemble des fonctions à l'ensemble des fonctions calculables,
*# regarder et comparer quelque modèles de calcul,
*# programmer un modèle de calcul et comprendre les limitations pratiques.

* Liens pour commencer:
** https://fr.wikipedia.org/wiki/Calculabilité
** https://fr.wikipedia.org/wiki/Machine_de_Turing
** https://fr.wikipedia.org/wiki/Lambda-calcul
** https://fr.wikipedia.org/wiki/Jeu_de_la_vie

== [[Génération et résolution de labyrinthes]] ==

* Tuteur: <strike>Jacques-Olivier Lachaud</strike> Xavier Provençal
* Résumé: On veut générer des labyrinthes aussi grands et complexes que possible, avec des murs dans une grille carré voire d'autres domaines. Comment faire pour qu'il y ait toujours un chemin de l'entrée à la sortie ? Comment faire pour qu'il n'y ait qu'un chemin ? Ensuite, comment trouver la sortie quand on est perdu dans le labyrinthe.
* Objectifs:
*# Comprendre comment représenter avec une structure de données un labyrinthe
*# Voir le lien avec la théorie des graphes et voir que le problème se résout de la même façon pour des grilles carrées, hexagonales ou autres.
*# Comprendre l'algorithme d'arbre couvrant minimum
*# Comprendre le principe du parcours en profondeur et de la récursivité
* Pour aller plus loin
*# coder la génération d'un labyrinthe et sa visualisation
* Liens pour démarrer
** [[https://fr.wikipedia.org/wiki/Mod%C3%A9lisation_math%C3%A9matique_d%27un_labyrinthe Wikipedia]]
** [[https://en.wikipedia.org/wiki/Maze_generation_algorithm Version anglaise plus complète]]

== Pavages par polyomino ==

* Tuteur: Xavier Provençal
* Résumé : On s'intéresse aux pavages du plan par des tuiles formées de petits carrés collés les uns aux autres, appelé "polyominos". Étant donné une tuile, peut-on paver le plan ? Si oui, avec quelles opérations (translation et/ou rotations et/ou réflexions) Une fois un pavage réalisé, on observe ses propriétés. Quelles symétries ? Le pavage est-il identique du point de vue de chacune des tuiles ? Si ce n'est pas le cas, en combien de classes peut-on diviser ces tuiles ?
On s'intéressera aussi à des propriétés connexes. Au lieu de paver tout le plan, on peut essayer de paver une région finie donnée. Plus localement, peut-on encercler complètement une tuile avec des copies d'elle-même, sans former de trous ? Si oui, peut-on faire de même avec la proto-tuile formée par la tuile de départ et toutes ses copies ? Si oui, combien de fois peut-on répéter l'opération ?
* Objectifs :
*# Comprendre les différentes classes de pavages (isohédral, k-isohédral, anisohédral).
*# Pour chacun des sept types de pavages "isohédraux", comprendre le lien entre les symétries du pavages et la caractérisation des tuiles qui le réalisent.
*# Pour un pavage k-isohédral, identifier les "classes d'équivalences" et le "domaine fondamental".
* Pour aller plus loin :
*# Coder la génération de tuiles capables de paver le plan en fonction pour une classe de pavages donnée.
*# Étudier et implémenter certains algorithmes pour le pavages d'un domaine fini.
* Liens pour démarrer
** [[https://fr.wikipedia.org/wiki/Polyomino Polyomino]]
** [[https://en.wikipedia.org/wiki/Polyomino Polyomino (en)]]
** [[https://fr.wikipedia.org/wiki/Pavage_par_des_polygones_r%C3%A9guliers Pavages]]

VISI201 CMI : visite de laboratoire

2019-05-20T00:04:23Z

Rakotoanosy : /* Sujets réalisés (2018-2019) */

* Cours du semestre 2 du parcours CMI Informatique (licence INFO).

* Responsable pour 2018--2019: Jacques-Olivier Lachaud
* Responsable pour 2017--2018: Jacques-Olivier Lachaud
* Responsable pour 2016--2017: Jacques-Olivier Lachaud

= Descriptif =

L'objectif du module est de faire découvrir les laboratoires, le monde de la recherche et les enseignants-chercheurs et chercheurs, ainsi que la réflexion scientifique. Cela se fait de deux manières.

D'abord, une partie de ce module consiste à assister à des séminaires dédiés aux étudiants CMI Informatique et Mathématique (1 fois par mois, les jeudi après-midi). [[http://www.lama.univ-savoie.fr/index.php?use=seminaires&&lang=fr&equipe=cmi&annee=1&lang=fr Planning des séminaires CMI]]

Ces séminaires "grand public" portent sur des sujets variées en informatique et mathématiques.

Les étudiants choisissent ensuite d'approfondir un sujet proposé par les enseignants, ou un sujet motivé de leur choix (en accord avec le responsable du module). Ce travail se fait en interaction avec un tuteur académique (5-6 contacts au moins). Ce travail personnel tuteuré donne lieu à la rédaction d'une synthèse sur le sujet sous forme d'une page wiki/web, ainsi que d'un mini-exposé.

= Sujets réalisés (2018-2019) =

* Transport optimal par coupe 1D et transfert de couleurs entre images
* [[Génération et résolution de labyrinthes II]] (Romain THEODET)
* [https://www.lama.univ-savoie.fr/mediawiki/index.php/Rest_%26_Pub-Sub_:_protocole_hybride_pour_l%27IoT REST & Pub/Sub : protocole hybride pour l’IoT] (Ewan RAKOTOANOSY)
* [[La suite de Conway et la classification périodique des "éléments"]] (Yohann THEPAUT)
* Initiation à la démonstration sur ordinateur et certification de logiciel
* [[Dilemme du prisonnier]] (Christophe CARMAGNAC)

= Sujets proposés (2018-2019) =

* Transport optimal par coupe 1D et transfert de couleurs entre images
* Génération et résolution de labyrinthes II
* REST + Pub/Sub : protocole hybride pour l’IoT
* La suite de Conway et la classification périodique des "éléments"
* Initiation à la démonstration sur ordinateur et certification de logiciel
* Algorithmes probabilistes/déterministes pour tester la primalité d'un entier
* Dilemme du prisonnier

== Transport optimal par coupe 1D et transfert de couleurs entre images ==

* Tuteur: Jacques-Olivier Lachaud
* Résumé: Le transfert de couleurs de l'image Y vers l'image X consiste à repeindre "au mieux" l'image X avec la palette de couleurs de l'image Y. L'image repeinte X' a alors les mêmes couleurs que l'image Y (mais les pixels ne sont pas répartis pareils). Voir l'exemple de transfert ci-dessous. Il existe plusieurs techniques de transfert de couleurs, mais nous étudierons une technique basée sur le transport optimal. Comme c'est un problème assez difficile dans le cas général, nous verrons une variante dite par coupe 1D, qui simplifiera considérablement le problème de transport.

[[Fichier:Ex-transfert-couleur-OT.png]]

* Objectifs:
*# comprendre ce qu'est une image niveaux couleur, et ce qu'on appelle le transfert de couleurs.
*# comprendre le principe du transport optimal (discret).
*# comprendre et décrire le principe du transport optimal par coupe 1D, et comment se fait le calcul du meilleur transport dans ce cas.
*# Coder un programme de transfert de couleur, qui prend deux images couleurs et réalise le transfert de couleurs.
*# On pourra ensuite réfléchir à quelques améliorations simples (espace couleur YUV, grouper les pixels).
* Liens pour démarrer
** Le vrai "Transport Optimal" est vite très mathématique (ce sont des mesures qui sont transportées), mais on peut l'aborder beaucoup plus simplement dans le cas discret (un nombre fini de valeurs) comme une simple assignation entre deux ensembles.
** [[https://en.wikipedia.org/wiki/Color_mapping Transfert de couleur Wikipedia]]
** [[https://hal.archives-ouvertes.fr/tel-01246096/file/hdr_hal2.pdf Habilitation de N. Papadakis]] (regardez les images plutôt).

== Génération et résolution de labyrinthes II ==

* Tuteur: François Boussion
* Résumé: On veut générer des labyrinthes aussi grands et complexes que possible, avec des murs dans une grille carré voire d'autres domaines. Comment faire pour qu'il y ait toujours un chemin de l'entrée à la sortie ? Comment faire pour qu'il n'y ait qu'un chemin ? Ensuite, comment trouver la sortie quand on est perdu dans le labyrinthe.
* Objectifs:
*# Comprendre comment représenter un labyrinthe avec une structure de données simple
*# Voir le lien avec la théorie des graphes et voir que le problème se résout de la même façon pour des grilles carrées, hexagonales ou autres.
*# Comprendre l'algorithme d'arbre couvrant minimum
*# Comprendre le principe du parcours en profondeur et de la récursivité
* Pour aller plus loin
*# coder la génération d'un labyrinthe et sa visualisation
*# introduire des poids pour varier le labyrinthe
*# comment faire un labyrinthe sur grille hexagonale avec des tableaux.
* Liens pour démarrer
** [[https://fr.wikipedia.org/wiki/Mod%C3%A9lisation_math%C3%A9matique_d%27un_labyrinthe Wikipedia]]
** [[https://en.wikipedia.org/wiki/Maze_generation_algorithm Version anglaise plus complète]]

== REST + Pub/Sub : protocole hybride pour l’IoT ==

* Tuteur: David Télisson
* Résumé: L’avènement de l’Internet des Objets (IoT) depuis une dizaine d’années a fait apparaitre des problématiques propres aux protocoles de communications liées à ces objets. En effet, l’échange de données dans ce contexte nécessite de tenir compte (au moins) des paramètres suivant :
*# Autonomie énergétique souvent limitée
*# Faible puissance des processeurs et taille réduite de la mémoire
*# Disponibilité « aléatoire » de l’accès aux réseaux de communication

De nombreux protocoles cohabitent et la littérature du domaine foisonne d’exemples autour des réseaux dédiées (LORA, Sigfox, etc.) et des protocoles applicatifs (OPC-UA, MQTT, CoaP, XMPP) mais force est de constater que dans la réalité, ces solutions ne répondent pas toujours aux besoins des concepteurs qui leurs préfèrent encore le protocole HTTP. Celui-ci offre l’avantage d’implémenter un protocole applicatif (REST) en même temps qu’un protocole de transport de haut niveau (TCP/IP) permettant de passer les pare-feu. Cependant, la version actuel d’HTTP ne répond pas vraiment aux critères énoncés précédemment.
Depuis quelques années émerge donc l’idée d’enrichir HTTP pour créer un protocole hybride qui mêlerait les avantages de REST avec ceux proposés par les mécanismes de type Publish/Subscribe (MQTT, AMQP, JMS, etc.). En attendant cette éventuelle évolution, peut-on envisager de mettre en place un mécanisme de type Pub/Sub avec le protocole Websocket au-dessus d’HTTP ?

* Objectifs:
*# Etudier et faire une synthèse des deux approches : REST et Pub/Sub
*# Implémentez un PoC (proof of concept) d’une solution hybride qui met en œuvre un mécanisme de Pub/Sub sur Websocket. .
*# Présenter un protocole de test pour valider ou invalider cette solution

* Liens pour démarrer :
** https://nsrc.org/workshops/2018/apricot/iot/presentations/mqttvsrest_v4.pdf
** http://www.tigli.fr/lib/exe/fetch.php?media=cours:tutorial_mqtt_mit_2015_2016.pdf
** https://openclassrooms.com/fr/courses/3449001-utilisez-des-api-rest-dans-vos-projets-web
** http://www.lirmm.fr/~tibermacin/ens/ws/expose.pdf

== La suite de Conway et la classification périodique des "éléments" ==

* Tuteur : Pierre Hyvernat
* La suite de Conway est la suite suivante : 1 ; 11 ; 21 ; 1211 ; 111221 ; ... Chaque terme est obtenu en "lisant" le terme précédent.
** "1" : un "1" -> 11
** "11" : deux "1" -> 21
** "21" : un "2", un "1" -> 1211
** "1211" : un "1", un "2", deux "1" -> 111221
** etc.
Cette suite possède des propriétés étonantes données par le théorème "chimique", le théorème "arithmétique" et le théorème "cosmologique".
* Objectifs :
*# comprendre les énoncés de ces théorèmes, et l'idée de la preuve du premier.
*# programmer la suite de Conway pour retrouver la classification des "atomes"
*# écrire un programme pour calculer expérimentalement une approximation de la constante "lambda" ainsi que des fréquences respectives des différents atomes.
*# écrire un programme pour calculer la suite de Robinson, une variante plus simple de la suite de Conway

* Liens pour commencer
** [[https://fr.wikipedia.org/wiki/Suite_de_Conway suite de Conway]]
** [[https://fr.wikipedia.org/wiki/Suite_de_Robinson suite de Robinson]]

== [[Initiation à la démonstration sur ordinateur et certification de logiciel]] ==

* Tuteur: Tom Hirschowitz
* Résumé: [[https://coq.inria.fr Coq]] est un logiciel de mathématiques sur ordinateur, grâce auquel des programmes élaborés ont pu être certifiés ces dernières années.
* Objectifs:
*# prendre en main le logiciel [[https://coq.inria.fr Coq]] de démonstration sur ordinateur,
*# programmer certaines démonstrations basiques en Coq,
*# suivre le début du cours [[https://www.cis.upenn.edu/~bcpierce/sf Software Foundations]],
* Pour aller plus loin : Software Foundations est un cours assez long et très bien fait, il y aura suffisamment à faire. Eventuellement, selon l'intérêt de l'étudiant, étude des fondements mathématiques de Coq.
* Liens pour démarrer
** [[https://www.cis.upenn.edu/~bcpierce/sf Software Foundations]]
** [[https://coq.inria.fr Coq]]

== Algorithmes probabilistes/déterministes pour tester la primalité d'un entier ==

* Tuteur : Sébastien Tavenas
* Pouvoir tester si un entier est un nombre premier semble être une brique de base si l'on souhaite faire de l'arithmétique sur un ordinateur. Le crible d'Érathostène enseigné dans les petites classes se montre beaucoup trop lent en pratique. L'algorithme probabiliste utilisé le plus rapide est le test de Fermat. Or, si on regarde les algorithmes des librairies "génériques", on peut s'apercevoir que la fonction 'mpz_probab_prime_p' de la librairie 'gmp' sur c++ utilise un test probabiliste de Miller-Rabin, la fonction 'isPrime' de la classe 'Prime' dans java utilise aussi un test de Miller-Rabin mais qui est déterminisé, alors que la fonction 'isprime' de la librairie 'sympy' dans python effectue un test de Miller-Rabin si l'entier est plus petit que 2^64 et un test BPSW fort si l'entier est plus grand. Ainsi, une fonction déjà implémentée de test de primalité peut se tromper ou non, être instantanée ou moins. Que dire alors de l'algorithme polynomial déterministe et toujours correct proposé par AKS?
* Objectifs :
*# Comprendre quelques tests de primalité et comment l'aléatoire est utilisé dans ces algorithmes
*# Comprendre la notion de nombre pseudopremier qui explique, entre autre, quand il vaut mieux utiliser le test de Fermat ou celui de Miller-Rabin
*# Programmer quelques uns des ces tests et les comparer
*# Essayer de dérandomiser ces tests à l'aide de hitting-sets précalculés

* Liens pour commencer
** [[https://en.wikipedia.org/wiki/Primality_test Tests de primalité]]

== Dilemme du prisonnier ==

* Tuteur: Gerald Cavallini
* Résumé: Le dilemme du prisonnier caractérise en théorie des jeux une situation où deux joueurs auraient
intérêt à coopérer, mais où, en l’absence de communication entre les deux joueurs, chacun choisira
de trahir l'autre si le jeu n'est joué qu'une fois.

On peut informatiquement modéliser ce dilemme à l’aide de matrices de gains et conserver la
mémoire des choix de l’adversaire. Ce modèle appliqué à un grand nombre d’individus peut être
utilisé pour comprendre l’émergence de stratégies stables dans l’économie, l’écologie, l’évolution
des espèces ...

On peut visualiser spatialement les interactions entre individus en les représentants par des pixels et
en leurs associant une couleur en fonction de leurs stratégies.

[[Fichier:Dilemme.png]]

* Objectifs
*# Comprendre le dilemme du prisonnier
*# Comprendre la notion de stratégie
*# Penser un modèle spatiale pour « opposer » des individus qui appliquent des stratégies différentes
*# Développer une interface pour visualiser dans le temps l’évolution d’une population d’individus adoptants des stratégies différentes.

* Lien :
*# [https://fr.wikipedia.org/wiki/Dilemme_du_prisonnier Dilemme du prisonnier Wikipedia]
*# [http://cormas.cirad.fr/fr/applica/dps.htm Site spécifique]

= Sujets réalisés (2017-2018) =

* [[VISI201 Analyse syntaxique (Tristan Porteries, 2018)]]
* [[Segmentation d'image par détection de contours et algorithme "ligne de partage des eaux"]] (Nils Ruet, 2018)
* [[Fouille de données textuelles à partir des "Exercices de style" de R. Queneau]] (Rémi Bouvier, 2018)
* [[Transformées en distance, diagramme de Voronoi et applications en geometry processing]] (Robin Wagner, 2018)
* [[Pavages de Penrose]] (Brunelle Cordier-Pierre-Bès, 2018)

= Sujets proposés (2017-2018) =

* Segmentation d'image par détection de contours et algorithme "ligne de partage des eaux"
* Initiation à la démonstration sur ordinateur et certification de logiciel
* Fouille de données textuelles à partir des "Exercices de style" de R. Queneau
* Transformées en distance, diagramme de Voronoi et applications en geometry processing
* Pavages de Penrose

== [[Segmentation d'image par détection de contours et algorithme "ligne de partage des eaux"]] ==

* Tuteur: Jacques-Olivier Lachaud
* Résumé: La segmentation d'image vise à identifier les régions d'intérêt dans une image. Typiquement, une région d'intérêt est une zone de l'image plutôt homogène (les pixels ont des valeurs proches) et le contour entre deux régions d'intérêt est tracé là où les valeurs subissent de fortes variations. La méthode de segmentation proposée ici suit ce principe en enchaînant deux calculs: (1) un premier traitement calcule une image "gradient" et fabrique une image dont les valeurs élevées correspondent à des zones de fortes variations, (2) le deuxième algorithme voit cette image comme un relief 3D et identifie ses bassins hydrographiques. Cette identification des lignes de partage des eaux permet de découper l'image en ses zones d'intérêt.
* Objectifs:
*# comprendre ce qu'est une image niveaux de gris ou couleur, ce qu'est le gradient d'une image et ce qu'on appelle segmentation d'image.
*# décrire un algorithme de calcul du gradient d'une image, e.g. le filtre de Sobel, voire les convolutions par dérivées de Gaussienne.
*# décrire le principe de ligne de partage des eaux ("watershed" en anglais), ses différentes définitions équivalentes, et les différents types d'algorithmes pour la calculer.
*# Coder un programme de segmentation d'image, qui prend une image (niveaux de gris) en entrée, calcule son gradient, et extrait les bassins de sa ligne de partage des eaux.
* Liens pour démarrer
** [[https://en.wikipedia.org/wiki/Watershed_(image_processing) Watershed Wikipedia]]
** Luc Vincent and Pierre Soille. Watersheds in digital spaces: an efficient algorithm based on immersion simulations. In IEEE Transactions on Pattern Analysis and Machine Intelligence, Vol. 13, Num. 6 (1991), pages 583–598 [[https://pdfs.semanticscholar.org/a381/9dda9a5f00dbb8cd3413ca7422e37a0d5794.pdf PDF]]

== [[Initiation à la démonstration sur ordinateur et certification de logiciel]] ==

* Tuteur: Tom Hirschowitz
* Résumé: [[https://coq.inria.fr Coq]] est un logiciel de mathématiques sur ordinateur, grâce auquel des programmes élaborés ont pu être certifiés ces dernières années.
* Objectifs:
*# prendre en main le logiciel [[https://coq.inria.fr Coq]] de démonstration sur ordinateur,
*# programmer certaines démonstrations basiques en Coq,
*# suivre le début du cours [[https://www.cis.upenn.edu/~bcpierce/sf Software Foundations]],
* Pour aller plus loin : Software Foundations est un cours assez long et très bien fait, il y aura suffisamment à faire. Eventuellement, selon l'intérêt de l'étudiant, étude des fondements mathématiques de Coq.
* Liens pour démarrer
** [[https://www.cis.upenn.edu/~bcpierce/sf Software Foundations]]
** [[https://coq.inria.fr Coq]]

== [[Fouille de données textuelles à partir des "Exercices de style" de R. Queneau]] ==

* Tuteur: Laurent Vuillon
* Résumé: L'idée de ce projet est de se familiariser avec les techniques de fouille de données textuelles à partir des "Exercices de style" de R. Queneau (https://fr.wikipedia.org/wiki/Exercices_de_style). On cherchera à comprendre la structure du vocabulaire du corpus de textes, à utiliser les techniques de TF/IDF pour extraire les mots significatifs du corpus puis à tester les techniques de LDA (Allocation de Dirichlet latente) pour extraire automatiquement les thématiques du corpus afin de construire des regroupements par thème. On pourra également proposer des visualisations des résultats afin de rendre accessible visuellement l'analyse de données produite sur le corpus de documents.
* Objectifs: Introduction à la fouille de données au travers d'un cas pratique
* Pour aller plus loin
** http://blogperso.univ-rennes1.fr/stephane.tuffery/
** http://www.editionstechnip.com/en/catalogue-detail/1005/data-mining-et-statistique-decisionnelle.html
* Liens pour démarrer
** https://fr.wikipedia.org/wiki/Exploration_de_donn%C3%A9es
** https://fr.wikipedia.org/wiki/TF-IDF
** "Recherche d'information : applications, modèles et algorithmes; Data mining, décisionnel et big data" de Amini et Gaussier aux éditions Eyrolles.

== [[Transformées en distance, diagramme de Voronoi et applications en geometry processing]] ==

* Tuteur: Jacques-Olivier Lachaud
* Résumé: Les nuages de points constituent une source de données géométriques importantes (cf LIDAR scanner, 3D scanner) et qui permet de construire des modèles géométriques 3D d'objets réels. La difficulté est de transformer ces nuages de points en des surfaces (souvent des surfaces triangulées, c'est-à-dire des triangles collés entre eux). Un outil essentiel dans ce processus est la transformée en distance, le diagramme de Voronoi (et son dual la triangulation de Delaunay). A partir de ces outils, des algorithmes existent pour reconstruire les surfaces, estimer la géométrie du nuage de point (sa normale par exemple), etc.
* Objectifs:
*# Comprendre ce qu'est une distance, une transformée en distance, et un diagramme de Voronoi. Comprendre ce qu'est la stabilité d'une fonction.
*# Identifier les propriétés des diagrammes de Voronoi, de leur dual la triangulation de Delaunay, et comprendre leurs variantes comme les diagrammes de puissance
*# Identifier le lien avec l'axe médian et les squelettes
*# Décrire les principaux algorithmes de calcul des transformées en distance et du diagramme de Voronoi, pour des nuages de point quelconques ou pour des nuages de points à coordonnées entières.
*# Présenter un algorithme de reconstruction de surface utilisant le diagramme de Voronoi
*# Coder un algorithme de calcul du diagramme de Voronoi et, si le temps le permet, un algorithme de reconstruction de surface.

* Liens pour démarrer
** [[https://en.wikipedia.org/wiki/Voronoi_diagram Diagramme de Voronoi Wikipedia]]
** [[https://en.wikipedia.org/wiki/Distance_transform Transformée en distance Wikipedia]]
** [[https://en.wikipedia.org/wiki/Topological_skeleton Squelette Wikipedia]]
** [[http://dgtal.org/doc/nightly/moduleVolumetric.html Transformées discrètes en distance DGtal]]

== [[Pavages de Penrose]] ==

* Tuteur : Pierre Hyvernat
* Résumé : le "cerf-volant" et la "fléchette" de Penrose sont deux tuiles qui permettent de recouvrir le plan, mais uniquement de manière non-périodique. Autrement dit, les pavages correspondants ne sont pas obtenus en répétant un même motif de manière régulière. A cause de ceci, il n'est pas évident de générer un tel pavage.

[[Fichier:P2.png]]

* Objectifs
*# comprendre les notion de pavage périodique, non périodique et apériodique,
*# comprendre la méthode "inflation / déflation" pour générer des pavages de Penrose des différents types,
*# comprendre le lien entre les 2 (ou 3) types de pavage de Penrose
*# écrire un programme permettant de générer de tels pavages : avec la méthode "inflation / déflation" et avec la méthode "grille de de Bruijn"
*# utiliser ces méthodes pour générer d'autres types de pavages apériodique.

* Liens pour démarrer
** [[https://fr.wikipedia.org/wiki/Pavage_de_Penrose pavage de Penrose (wikipedia]]
** [[https://www.maa.org/sites/default/files/pdf/pubs/focus/Gardner_PenroseTilings1-1977.pdf Penrose Tiling (Marting Gardner, en anglais)]]

== [[Algorithmes d'analyse syntaxique]] ==

* Tuteur : Pierre Hyvernat

* Résumé : le code source d'un programme, d'un fichier de configuration d'un serveur de base de données ou le code d'une page web sont des données ''textuelles'' et ''structurées''. Il est possible de définir exactement quelles données sont correctes, et quelle est leur signification. (Cela est beaucoup plus difficile pour des textes en langue naturelle par exemple.) En ce sens, il est possible de lire, d'interpréter ces données à l'aide d'un programme. On parle ''d'analyseur syntaxique'' ou de ''parseur''. Il existe de nombreux outils pour faire ça automatiquement, mais il est parfois important (et toujours intéressant) de comprendre les mécanismes correspondant. C'est ce que ce stage propose de faire.

* Objectifs :
*# étudier la formalisation du problème à travers la notion de ''langage'' et les premiers étages de la hiérachie de Chomsky (langages réguliers et grammaires hors contexte).
*# comprendre le lien entre les langages et les automates (automates finis / automates à pile)
*# implémenter un parseur "from scratch" et le tester sur des petits exemples simples, "à la main", soit en calculant "à la volée" la sémantique d'un langage, soit en produisant des "arbres de syntaxe abstraits", qui pourront être analysés par la suite,
*# comprendre les restrictions souvent imposées sur les grammaires afin d'améliorer l'efficacité du parseur (''LL*(k)'', ''LR'', etc.)
*# à partir de là, de nombreuses pistes sont ouvertes :
*#* essayer d'écrire un petit outils qui puisse lire une grammaire, et générer un parseur pour cette grammaire,
*#* comparer l'approche "automate" avec l'approche "combinateurs" et "parseur récursifs"
*#* améliorer l'efficacité des parseurs produits
*#* ajouter des fonctionnalités,
*#* ...

* Liens pour démarrer :
** [[https://en.wikipedia.org/wiki/Parsing page wikipedia "parsing"]]
** [[https://en.wikipedia.org/wiki/Recursive_descent_parser page wikipedia "recursive descent parser"]]
** Le livre référence sur le parsing est probablement "Compilers: Principles, Techniques, and Tools" de Aho, Sethi et Ullman (le "dragon book")
** [[https://web.stanford.edu/class/archive/cs/cs143/cs143.1128/ exemples de notes cours de compilation]]

= Sujets réalisés (2016-2017) =

* [[Algorithme de rendu de scène 3D par Z-buffer]]
* [[Traitement d'image]]
* [[Nim et la théorie des jeux impartiaux]]
* [[Calculabilité et modèles de calcul]]
* [[Génération et résolution de labyrinthes]]

= Sujets proposés (2016-2017) =

== [[Algorithme de rendu de scène 3D par Z-buffer]] ==

* Tuteur: Jacques-Olivier Lachaud
* Résumé: Le Z-buffer est un algorithme classique de rendu de scène 3D. C'est celui (avec quelques variantes) qui est implémenté dans nos cartes graphiques 3D et qui permet de visualiser des scènes extrêmement complexes en temps réel (typiquement 24 image/s).
* Objectifs:
*# décrire le principe de la projection 3D vers 2D
*# décrire la rastérisation des triangles sur une image en pixel
*# expliquer le principe du Z-buffer qui permet de gérer le fait que certains objets sont cachés par d'autres
*# expliquer comment les couleurs sont calculées par pixel
*# indiquer les qualités et limitations de l'algorithme
* Pour aller plus loin
*# mettre du code démo (WebGL) avec quelques explications sur le pipeline graphique OpenGL
*# expliquer comment on peut utiliser cet algorithme pour calculer des ombres (shadow map)
* Liens pour démarrer
** [[https://fr.wikipedia.org/wiki/Z-buffer Wikipedia]]
** [[https://www.scratchapixel.com/lessons/3d-basic-rendering/rasterization-practical-implementation/overview-rasterization-algorithm Scratch a pixel]]

== [[Traitement d'image]] ==

* Tuteur: Jacques-Olivier Lachaud
* Résumé: Le traitement d'image rassemble tous les algorithmes utilisés pour transformer les images, les améliorer, éliminer certaines perturbations, augmenter ou diminuer le contraste, changer les couleurs vers d'autres couleurs, éliminer le flou ou les yeux rouges, faire du cartooning pour un rendu moins photo-réaliste, etc.
* Objectifs:
*# identifier les grandes familles de traitement: restauration, égalisation, élimination du flou de déplacement, segmentation, etc
*# identifier les grandes familles de techniques: filtrage spatial, filtrage fréquentiel, optimisation, etc
*# comprendre les points communs et différences entre le traitement des images noir et blanc et le traitement des images couleurs.
*# choisir un ou deux algorithmes de traitement et les expliquer en détails
* Pour aller plus loin
*# Coder un algorithme de traitement d'image simple (e.g, un filtrage médian, ou un algo qui transporte les couleurs d'une photo vers une autre photo)

* Liens pour démarrer
** [[https://fr.wikipedia.org/wiki/Traitement_d%27images Wikipedia]]
** [[http://www.ipol.im/ Image Processing on line]] (permet de tester en ligne des algorithmes sur vos images)

== [[Nim et la théorie des jeux impartiaux]] ==

* Tuteur: Pierre Hyvernat

* Étudiant : Luca Chapelle

* Le jeu de Nim (aussi appelé jeu des allumettes) est l'un des premiers jeux ayant été analysé mathématiquement (par Charles Bouton en 1901). Les stratégies gagnantes peuvent être calculées en utilisant le développement en base 2 des nombres, et l'opération d'"addition de Nim" (XOR). La théorie de ce type de jeux (jeux "impartiaux") est assez simple, mais de nombreuses instances de jeux sont encore non résolues.
* Objectifs:
*# comprendre la théorie du jeu de Nim (et la programmer)
*# comprendre le théorème de Sprague Grundy qui montre que tout jeu impartial est équivalent à un jeu de nim
*# regarder quelques autres exemples de tels jeux : jeu de Nim déguisés, ou jeux véritablement différents
*# programmer une version naịve de recherche de stratégie basée sur le théorème de Sprague-Grundy pour quelques jeux

* Liens pour commencer
** [https://fr.wikipedia.org/wiki/Jeux_de_Nim jeu de Nim]
** [https://fr.wikipedia.org/wiki/Th%C3%A9or%C3%A8me_de_Sprague-Grundy théorème de Sprague Grundy]
** [https://fr.wikipedia.org/wiki/Jeu_de_Grundy jeu de Grundy]

== La suite de Conway et la classification périodique des "éléments" ==

* Tuteur : Pierre Hyvernat
* La suite de Conway est la suite suivante : 1 ; 11 ; 21 ; 1211 ; 111221 ; ... Chaque terme est obtenu en "lisant" le terme précédent.
** "1" : un "1" -> 11
** "11" : deux "1" -> 21
** "21" : un "2", un "1" -> 1211
** "1211" : un "1", un "2", deux "1" -> 111221
** etc.
Cette suite possède des propriétés étonantes données par le théorème "chimique", le théorème "arithmétique" et le théorème "cosmologique".
* Objectifs :
*# comprendre les énoncés de ces théorèmes, et l'idée de la preuve du premier.
*# programmer la suite de Conway pour retrouver la classification des "atomes"
*# écrire un programme pour calculer expérimentalement une approximation de la constante "lambda" ainsi que des fréquences respectives des différents atomes.
*# écrire un programme pour calculer la suite de Robinson, une variante plus simple de la suite de Conway

* Liens pour commencer
** [[https://fr.wikipedia.org/wiki/Suite_de_Conway suite de Conway]]
** [[https://fr.wikipedia.org/wiki/Suite_de_Robinson suite de Robinson]]

== Initiation à la démonstration sur ordinateur et certification de logiciel ==

* Tuteur: Tom Hirschowitz
* Résumé: [[https://coq.inria.fr Coq]] est un logiciel de mathématiques sur ordinateur, grâce auquel des programmes élaborés ont pu être certifiés ces dernières années.
* Objectifs:
*# prendre en main le logiciel [[https://coq.inria.fr Coq]] de démonstration sur ordinateur,
*# programmer certaines démonstrations basiques en Coq,
*# suivre le début du cours [[https://www.cis.upenn.edu/~bcpierce/sf Software Foundations]],
* Pour aller plus loin : Software Foundations est un cours assez long et très bien fait, il y aura suffisamment à faire. Eventuellement, selon l'intérêt de l'étudiant, étude des fondements mathématiques de Coq.
* Liens pour démarrer
** [[https://www.cis.upenn.edu/~bcpierce/sf Software Foundations]]
** [[https://coq.inria.fr Coq]]

== [[Calculabilité et modèles de calcul]] ==

* Tuteur: Rodolphe Lepigre
* Résumé: Une fonction f sur l'ensemble des entiers naturels est dite calculable s'il existe une procedure effective (ou un algorithme) qui permet, étant donné un entier n, de calculer f(n) en temps fini. Il existe divers modèles de calcul qui permettent de représenter toutes les fonctions calculables : machines de Turing, λ-calcul, automates cellulaires, ...
* Objectifs:
*# comprendre la notion de fonction calculable,
*# comparer l'ensemble des fonctions à l'ensemble des fonctions calculables,
*# regarder et comparer quelque modèles de calcul,
*# programmer un modèle de calcul et comprendre les limitations pratiques.

* Liens pour commencer:
** https://fr.wikipedia.org/wiki/Calculabilité
** https://fr.wikipedia.org/wiki/Machine_de_Turing
** https://fr.wikipedia.org/wiki/Lambda-calcul
** https://fr.wikipedia.org/wiki/Jeu_de_la_vie

== [[Génération et résolution de labyrinthes]] ==

* Tuteur: <strike>Jacques-Olivier Lachaud</strike> Xavier Provençal
* Résumé: On veut générer des labyrinthes aussi grands et complexes que possible, avec des murs dans une grille carré voire d'autres domaines. Comment faire pour qu'il y ait toujours un chemin de l'entrée à la sortie ? Comment faire pour qu'il n'y ait qu'un chemin ? Ensuite, comment trouver la sortie quand on est perdu dans le labyrinthe.
* Objectifs:
*# Comprendre comment représenter avec une structure de données un labyrinthe
*# Voir le lien avec la théorie des graphes et voir que le problème se résout de la même façon pour des grilles carrées, hexagonales ou autres.
*# Comprendre l'algorithme d'arbre couvrant minimum
*# Comprendre le principe du parcours en profondeur et de la récursivité
* Pour aller plus loin
*# coder la génération d'un labyrinthe et sa visualisation
* Liens pour démarrer
** [[https://fr.wikipedia.org/wiki/Mod%C3%A9lisation_math%C3%A9matique_d%27un_labyrinthe Wikipedia]]
** [[https://en.wikipedia.org/wiki/Maze_generation_algorithm Version anglaise plus complète]]

== Pavages par polyomino ==

* Tuteur: Xavier Provençal
* Résumé : On s'intéresse aux pavages du plan par des tuiles formées de petits carrés collés les uns aux autres, appelé "polyominos". Étant donné une tuile, peut-on paver le plan ? Si oui, avec quelles opérations (translation et/ou rotations et/ou réflexions) Une fois un pavage réalisé, on observe ses propriétés. Quelles symétries ? Le pavage est-il identique du point de vue de chacune des tuiles ? Si ce n'est pas le cas, en combien de classes peut-on diviser ces tuiles ?
On s'intéressera aussi à des propriétés connexes. Au lieu de paver tout le plan, on peut essayer de paver une région finie donnée. Plus localement, peut-on encercler complètement une tuile avec des copies d'elle-même, sans former de trous ? Si oui, peut-on faire de même avec la proto-tuile formée par la tuile de départ et toutes ses copies ? Si oui, combien de fois peut-on répéter l'opération ?
* Objectifs :
*# Comprendre les différentes classes de pavages (isohédral, k-isohédral, anisohédral).
*# Pour chacun des sept types de pavages "isohédraux", comprendre le lien entre les symétries du pavages et la caractérisation des tuiles qui le réalisent.
*# Pour un pavage k-isohédral, identifier les "classes d'équivalences" et le "domaine fondamental".
* Pour aller plus loin :
*# Coder la génération de tuiles capables de paver le plan en fonction pour une classe de pavages donnée.
*# Étudier et implémenter certains algorithmes pour le pavages d'un domaine fini.
* Liens pour démarrer
** [[https://fr.wikipedia.org/wiki/Polyomino Polyomino]]
** [[https://en.wikipedia.org/wiki/Polyomino Polyomino (en)]]
** [[https://fr.wikipedia.org/wiki/Pavage_par_des_polygones_r%C3%A9guliers Pavages]]

VISI201 CMI : visite de laboratoire

2019-05-20T00:03:26Z

Rakotoanosy : /* Sujets réalisés (2018-2019) */

* Cours du semestre 2 du parcours CMI Informatique (licence INFO).

* Responsable pour 2018--2019: Jacques-Olivier Lachaud
* Responsable pour 2017--2018: Jacques-Olivier Lachaud
* Responsable pour 2016--2017: Jacques-Olivier Lachaud

= Descriptif =

L'objectif du module est de faire découvrir les laboratoires, le monde de la recherche et les enseignants-chercheurs et chercheurs, ainsi que la réflexion scientifique. Cela se fait de deux manières.

D'abord, une partie de ce module consiste à assister à des séminaires dédiés aux étudiants CMI Informatique et Mathématique (1 fois par mois, les jeudi après-midi). [[http://www.lama.univ-savoie.fr/index.php?use=seminaires&&lang=fr&equipe=cmi&annee=1&lang=fr Planning des séminaires CMI]]

Ces séminaires "grand public" portent sur des sujets variées en informatique et mathématiques.

Les étudiants choisissent ensuite d'approfondir un sujet proposé par les enseignants, ou un sujet motivé de leur choix (en accord avec le responsable du module). Ce travail se fait en interaction avec un tuteur académique (5-6 contacts au moins). Ce travail personnel tuteuré donne lieu à la rédaction d'une synthèse sur le sujet sous forme d'une page wiki/web, ainsi que d'un mini-exposé.

= Sujets réalisés (2018-2019) =

* Transport optimal par coupe 1D et transfert de couleurs entre images
* [[Génération et résolution de labyrinthes II]] (Romain THEODET)
* [[REST & Pub/Sub : protocole hybride pour l’IoT]] (Ewan RAKOTOANOSY)
* [[La suite de Conway et la classification périodique des "éléments"]] (Yohann THEPAUT)
* Initiation à la démonstration sur ordinateur et certification de logiciel
* [[Dilemme du prisonnier]] (Christophe CARMAGNAC)

= Sujets proposés (2018-2019) =

* Transport optimal par coupe 1D et transfert de couleurs entre images
* Génération et résolution de labyrinthes II
* REST + Pub/Sub : protocole hybride pour l’IoT
* La suite de Conway et la classification périodique des "éléments"
* Initiation à la démonstration sur ordinateur et certification de logiciel
* Algorithmes probabilistes/déterministes pour tester la primalité d'un entier
* Dilemme du prisonnier

== Transport optimal par coupe 1D et transfert de couleurs entre images ==

* Tuteur: Jacques-Olivier Lachaud
* Résumé: Le transfert de couleurs de l'image Y vers l'image X consiste à repeindre "au mieux" l'image X avec la palette de couleurs de l'image Y. L'image repeinte X' a alors les mêmes couleurs que l'image Y (mais les pixels ne sont pas répartis pareils). Voir l'exemple de transfert ci-dessous. Il existe plusieurs techniques de transfert de couleurs, mais nous étudierons une technique basée sur le transport optimal. Comme c'est un problème assez difficile dans le cas général, nous verrons une variante dite par coupe 1D, qui simplifiera considérablement le problème de transport.

[[Fichier:Ex-transfert-couleur-OT.png]]

* Objectifs:
*# comprendre ce qu'est une image niveaux couleur, et ce qu'on appelle le transfert de couleurs.
*# comprendre le principe du transport optimal (discret).
*# comprendre et décrire le principe du transport optimal par coupe 1D, et comment se fait le calcul du meilleur transport dans ce cas.
*# Coder un programme de transfert de couleur, qui prend deux images couleurs et réalise le transfert de couleurs.
*# On pourra ensuite réfléchir à quelques améliorations simples (espace couleur YUV, grouper les pixels).
* Liens pour démarrer
** Le vrai "Transport Optimal" est vite très mathématique (ce sont des mesures qui sont transportées), mais on peut l'aborder beaucoup plus simplement dans le cas discret (un nombre fini de valeurs) comme une simple assignation entre deux ensembles.
** [[https://en.wikipedia.org/wiki/Color_mapping Transfert de couleur Wikipedia]]
** [[https://hal.archives-ouvertes.fr/tel-01246096/file/hdr_hal2.pdf Habilitation de N. Papadakis]] (regardez les images plutôt).

== Génération et résolution de labyrinthes II ==

* Tuteur: François Boussion
* Résumé: On veut générer des labyrinthes aussi grands et complexes que possible, avec des murs dans une grille carré voire d'autres domaines. Comment faire pour qu'il y ait toujours un chemin de l'entrée à la sortie ? Comment faire pour qu'il n'y ait qu'un chemin ? Ensuite, comment trouver la sortie quand on est perdu dans le labyrinthe.
* Objectifs:
*# Comprendre comment représenter un labyrinthe avec une structure de données simple
*# Voir le lien avec la théorie des graphes et voir que le problème se résout de la même façon pour des grilles carrées, hexagonales ou autres.
*# Comprendre l'algorithme d'arbre couvrant minimum
*# Comprendre le principe du parcours en profondeur et de la récursivité
* Pour aller plus loin
*# coder la génération d'un labyrinthe et sa visualisation
*# introduire des poids pour varier le labyrinthe
*# comment faire un labyrinthe sur grille hexagonale avec des tableaux.
* Liens pour démarrer
** [[https://fr.wikipedia.org/wiki/Mod%C3%A9lisation_math%C3%A9matique_d%27un_labyrinthe Wikipedia]]
** [[https://en.wikipedia.org/wiki/Maze_generation_algorithm Version anglaise plus complète]]

== REST + Pub/Sub : protocole hybride pour l’IoT ==

* Tuteur: David Télisson
* Résumé: L’avènement de l’Internet des Objets (IoT) depuis une dizaine d’années a fait apparaitre des problématiques propres aux protocoles de communications liées à ces objets. En effet, l’échange de données dans ce contexte nécessite de tenir compte (au moins) des paramètres suivant :
*# Autonomie énergétique souvent limitée
*# Faible puissance des processeurs et taille réduite de la mémoire
*# Disponibilité « aléatoire » de l’accès aux réseaux de communication

De nombreux protocoles cohabitent et la littérature du domaine foisonne d’exemples autour des réseaux dédiées (LORA, Sigfox, etc.) et des protocoles applicatifs (OPC-UA, MQTT, CoaP, XMPP) mais force est de constater que dans la réalité, ces solutions ne répondent pas toujours aux besoins des concepteurs qui leurs préfèrent encore le protocole HTTP. Celui-ci offre l’avantage d’implémenter un protocole applicatif (REST) en même temps qu’un protocole de transport de haut niveau (TCP/IP) permettant de passer les pare-feu. Cependant, la version actuel d’HTTP ne répond pas vraiment aux critères énoncés précédemment.
Depuis quelques années émerge donc l’idée d’enrichir HTTP pour créer un protocole hybride qui mêlerait les avantages de REST avec ceux proposés par les mécanismes de type Publish/Subscribe (MQTT, AMQP, JMS, etc.). En attendant cette éventuelle évolution, peut-on envisager de mettre en place un mécanisme de type Pub/Sub avec le protocole Websocket au-dessus d’HTTP ?

* Objectifs:
*# Etudier et faire une synthèse des deux approches : REST et Pub/Sub
*# Implémentez un PoC (proof of concept) d’une solution hybride qui met en œuvre un mécanisme de Pub/Sub sur Websocket. .
*# Présenter un protocole de test pour valider ou invalider cette solution

* Liens pour démarrer :
** https://nsrc.org/workshops/2018/apricot/iot/presentations/mqttvsrest_v4.pdf
** http://www.tigli.fr/lib/exe/fetch.php?media=cours:tutorial_mqtt_mit_2015_2016.pdf
** https://openclassrooms.com/fr/courses/3449001-utilisez-des-api-rest-dans-vos-projets-web
** http://www.lirmm.fr/~tibermacin/ens/ws/expose.pdf

== La suite de Conway et la classification périodique des "éléments" ==

* Tuteur : Pierre Hyvernat
* La suite de Conway est la suite suivante : 1 ; 11 ; 21 ; 1211 ; 111221 ; ... Chaque terme est obtenu en "lisant" le terme précédent.
** "1" : un "1" -> 11
** "11" : deux "1" -> 21
** "21" : un "2", un "1" -> 1211
** "1211" : un "1", un "2", deux "1" -> 111221
** etc.
Cette suite possède des propriétés étonantes données par le théorème "chimique", le théorème "arithmétique" et le théorème "cosmologique".
* Objectifs :
*# comprendre les énoncés de ces théorèmes, et l'idée de la preuve du premier.
*# programmer la suite de Conway pour retrouver la classification des "atomes"
*# écrire un programme pour calculer expérimentalement une approximation de la constante "lambda" ainsi que des fréquences respectives des différents atomes.
*# écrire un programme pour calculer la suite de Robinson, une variante plus simple de la suite de Conway

* Liens pour commencer
** [[https://fr.wikipedia.org/wiki/Suite_de_Conway suite de Conway]]
** [[https://fr.wikipedia.org/wiki/Suite_de_Robinson suite de Robinson]]

== [[Initiation à la démonstration sur ordinateur et certification de logiciel]] ==

* Tuteur: Tom Hirschowitz
* Résumé: [[https://coq.inria.fr Coq]] est un logiciel de mathématiques sur ordinateur, grâce auquel des programmes élaborés ont pu être certifiés ces dernières années.
* Objectifs:
*# prendre en main le logiciel [[https://coq.inria.fr Coq]] de démonstration sur ordinateur,
*# programmer certaines démonstrations basiques en Coq,
*# suivre le début du cours [[https://www.cis.upenn.edu/~bcpierce/sf Software Foundations]],
* Pour aller plus loin : Software Foundations est un cours assez long et très bien fait, il y aura suffisamment à faire. Eventuellement, selon l'intérêt de l'étudiant, étude des fondements mathématiques de Coq.
* Liens pour démarrer
** [[https://www.cis.upenn.edu/~bcpierce/sf Software Foundations]]
** [[https://coq.inria.fr Coq]]

== Algorithmes probabilistes/déterministes pour tester la primalité d'un entier ==

* Tuteur : Sébastien Tavenas
* Pouvoir tester si un entier est un nombre premier semble être une brique de base si l'on souhaite faire de l'arithmétique sur un ordinateur. Le crible d'Érathostène enseigné dans les petites classes se montre beaucoup trop lent en pratique. L'algorithme probabiliste utilisé le plus rapide est le test de Fermat. Or, si on regarde les algorithmes des librairies "génériques", on peut s'apercevoir que la fonction 'mpz_probab_prime_p' de la librairie 'gmp' sur c++ utilise un test probabiliste de Miller-Rabin, la fonction 'isPrime' de la classe 'Prime' dans java utilise aussi un test de Miller-Rabin mais qui est déterminisé, alors que la fonction 'isprime' de la librairie 'sympy' dans python effectue un test de Miller-Rabin si l'entier est plus petit que 2^64 et un test BPSW fort si l'entier est plus grand. Ainsi, une fonction déjà implémentée de test de primalité peut se tromper ou non, être instantanée ou moins. Que dire alors de l'algorithme polynomial déterministe et toujours correct proposé par AKS?
* Objectifs :
*# Comprendre quelques tests de primalité et comment l'aléatoire est utilisé dans ces algorithmes
*# Comprendre la notion de nombre pseudopremier qui explique, entre autre, quand il vaut mieux utiliser le test de Fermat ou celui de Miller-Rabin
*# Programmer quelques uns des ces tests et les comparer
*# Essayer de dérandomiser ces tests à l'aide de hitting-sets précalculés

* Liens pour commencer
** [[https://en.wikipedia.org/wiki/Primality_test Tests de primalité]]

== Dilemme du prisonnier ==

* Tuteur: Gerald Cavallini
* Résumé: Le dilemme du prisonnier caractérise en théorie des jeux une situation où deux joueurs auraient
intérêt à coopérer, mais où, en l’absence de communication entre les deux joueurs, chacun choisira
de trahir l'autre si le jeu n'est joué qu'une fois.

On peut informatiquement modéliser ce dilemme à l’aide de matrices de gains et conserver la
mémoire des choix de l’adversaire. Ce modèle appliqué à un grand nombre d’individus peut être
utilisé pour comprendre l’émergence de stratégies stables dans l’économie, l’écologie, l’évolution
des espèces ...

On peut visualiser spatialement les interactions entre individus en les représentants par des pixels et
en leurs associant une couleur en fonction de leurs stratégies.

[[Fichier:Dilemme.png]]

* Objectifs
*# Comprendre le dilemme du prisonnier
*# Comprendre la notion de stratégie
*# Penser un modèle spatiale pour « opposer » des individus qui appliquent des stratégies différentes
*# Développer une interface pour visualiser dans le temps l’évolution d’une population d’individus adoptants des stratégies différentes.

* Lien :
*# [https://fr.wikipedia.org/wiki/Dilemme_du_prisonnier Dilemme du prisonnier Wikipedia]
*# [http://cormas.cirad.fr/fr/applica/dps.htm Site spécifique]

= Sujets réalisés (2017-2018) =

* [[VISI201 Analyse syntaxique (Tristan Porteries, 2018)]]
* [[Segmentation d'image par détection de contours et algorithme "ligne de partage des eaux"]] (Nils Ruet, 2018)
* [[Fouille de données textuelles à partir des "Exercices de style" de R. Queneau]] (Rémi Bouvier, 2018)
* [[Transformées en distance, diagramme de Voronoi et applications en geometry processing]] (Robin Wagner, 2018)
* [[Pavages de Penrose]] (Brunelle Cordier-Pierre-Bès, 2018)

= Sujets proposés (2017-2018) =

* Segmentation d'image par détection de contours et algorithme "ligne de partage des eaux"
* Initiation à la démonstration sur ordinateur et certification de logiciel
* Fouille de données textuelles à partir des "Exercices de style" de R. Queneau
* Transformées en distance, diagramme de Voronoi et applications en geometry processing
* Pavages de Penrose

== [[Segmentation d'image par détection de contours et algorithme "ligne de partage des eaux"]] ==

* Tuteur: Jacques-Olivier Lachaud
* Résumé: La segmentation d'image vise à identifier les régions d'intérêt dans une image. Typiquement, une région d'intérêt est une zone de l'image plutôt homogène (les pixels ont des valeurs proches) et le contour entre deux régions d'intérêt est tracé là où les valeurs subissent de fortes variations. La méthode de segmentation proposée ici suit ce principe en enchaînant deux calculs: (1) un premier traitement calcule une image "gradient" et fabrique une image dont les valeurs élevées correspondent à des zones de fortes variations, (2) le deuxième algorithme voit cette image comme un relief 3D et identifie ses bassins hydrographiques. Cette identification des lignes de partage des eaux permet de découper l'image en ses zones d'intérêt.
* Objectifs:
*# comprendre ce qu'est une image niveaux de gris ou couleur, ce qu'est le gradient d'une image et ce qu'on appelle segmentation d'image.
*# décrire un algorithme de calcul du gradient d'une image, e.g. le filtre de Sobel, voire les convolutions par dérivées de Gaussienne.
*# décrire le principe de ligne de partage des eaux ("watershed" en anglais), ses différentes définitions équivalentes, et les différents types d'algorithmes pour la calculer.
*# Coder un programme de segmentation d'image, qui prend une image (niveaux de gris) en entrée, calcule son gradient, et extrait les bassins de sa ligne de partage des eaux.
* Liens pour démarrer
** [[https://en.wikipedia.org/wiki/Watershed_(image_processing) Watershed Wikipedia]]
** Luc Vincent and Pierre Soille. Watersheds in digital spaces: an efficient algorithm based on immersion simulations. In IEEE Transactions on Pattern Analysis and Machine Intelligence, Vol. 13, Num. 6 (1991), pages 583–598 [[https://pdfs.semanticscholar.org/a381/9dda9a5f00dbb8cd3413ca7422e37a0d5794.pdf PDF]]

== [[Initiation à la démonstration sur ordinateur et certification de logiciel]] ==

* Tuteur: Tom Hirschowitz
* Résumé: [[https://coq.inria.fr Coq]] est un logiciel de mathématiques sur ordinateur, grâce auquel des programmes élaborés ont pu être certifiés ces dernières années.
* Objectifs:
*# prendre en main le logiciel [[https://coq.inria.fr Coq]] de démonstration sur ordinateur,
*# programmer certaines démonstrations basiques en Coq,
*# suivre le début du cours [[https://www.cis.upenn.edu/~bcpierce/sf Software Foundations]],
* Pour aller plus loin : Software Foundations est un cours assez long et très bien fait, il y aura suffisamment à faire. Eventuellement, selon l'intérêt de l'étudiant, étude des fondements mathématiques de Coq.
* Liens pour démarrer
** [[https://www.cis.upenn.edu/~bcpierce/sf Software Foundations]]
** [[https://coq.inria.fr Coq]]

== [[Fouille de données textuelles à partir des "Exercices de style" de R. Queneau]] ==

* Tuteur: Laurent Vuillon
* Résumé: L'idée de ce projet est de se familiariser avec les techniques de fouille de données textuelles à partir des "Exercices de style" de R. Queneau (https://fr.wikipedia.org/wiki/Exercices_de_style). On cherchera à comprendre la structure du vocabulaire du corpus de textes, à utiliser les techniques de TF/IDF pour extraire les mots significatifs du corpus puis à tester les techniques de LDA (Allocation de Dirichlet latente) pour extraire automatiquement les thématiques du corpus afin de construire des regroupements par thème. On pourra également proposer des visualisations des résultats afin de rendre accessible visuellement l'analyse de données produite sur le corpus de documents.
* Objectifs: Introduction à la fouille de données au travers d'un cas pratique
* Pour aller plus loin
** http://blogperso.univ-rennes1.fr/stephane.tuffery/
** http://www.editionstechnip.com/en/catalogue-detail/1005/data-mining-et-statistique-decisionnelle.html
* Liens pour démarrer
** https://fr.wikipedia.org/wiki/Exploration_de_donn%C3%A9es
** https://fr.wikipedia.org/wiki/TF-IDF
** "Recherche d'information : applications, modèles et algorithmes; Data mining, décisionnel et big data" de Amini et Gaussier aux éditions Eyrolles.

== [[Transformées en distance, diagramme de Voronoi et applications en geometry processing]] ==

* Tuteur: Jacques-Olivier Lachaud
* Résumé: Les nuages de points constituent une source de données géométriques importantes (cf LIDAR scanner, 3D scanner) et qui permet de construire des modèles géométriques 3D d'objets réels. La difficulté est de transformer ces nuages de points en des surfaces (souvent des surfaces triangulées, c'est-à-dire des triangles collés entre eux). Un outil essentiel dans ce processus est la transformée en distance, le diagramme de Voronoi (et son dual la triangulation de Delaunay). A partir de ces outils, des algorithmes existent pour reconstruire les surfaces, estimer la géométrie du nuage de point (sa normale par exemple), etc.
* Objectifs:
*# Comprendre ce qu'est une distance, une transformée en distance, et un diagramme de Voronoi. Comprendre ce qu'est la stabilité d'une fonction.
*# Identifier les propriétés des diagrammes de Voronoi, de leur dual la triangulation de Delaunay, et comprendre leurs variantes comme les diagrammes de puissance
*# Identifier le lien avec l'axe médian et les squelettes
*# Décrire les principaux algorithmes de calcul des transformées en distance et du diagramme de Voronoi, pour des nuages de point quelconques ou pour des nuages de points à coordonnées entières.
*# Présenter un algorithme de reconstruction de surface utilisant le diagramme de Voronoi
*# Coder un algorithme de calcul du diagramme de Voronoi et, si le temps le permet, un algorithme de reconstruction de surface.

* Liens pour démarrer
** [[https://en.wikipedia.org/wiki/Voronoi_diagram Diagramme de Voronoi Wikipedia]]
** [[https://en.wikipedia.org/wiki/Distance_transform Transformée en distance Wikipedia]]
** [[https://en.wikipedia.org/wiki/Topological_skeleton Squelette Wikipedia]]
** [[http://dgtal.org/doc/nightly/moduleVolumetric.html Transformées discrètes en distance DGtal]]

== [[Pavages de Penrose]] ==

* Tuteur : Pierre Hyvernat
* Résumé : le "cerf-volant" et la "fléchette" de Penrose sont deux tuiles qui permettent de recouvrir le plan, mais uniquement de manière non-périodique. Autrement dit, les pavages correspondants ne sont pas obtenus en répétant un même motif de manière régulière. A cause de ceci, il n'est pas évident de générer un tel pavage.

[[Fichier:P2.png]]

* Objectifs
*# comprendre les notion de pavage périodique, non périodique et apériodique,
*# comprendre la méthode "inflation / déflation" pour générer des pavages de Penrose des différents types,
*# comprendre le lien entre les 2 (ou 3) types de pavage de Penrose
*# écrire un programme permettant de générer de tels pavages : avec la méthode "inflation / déflation" et avec la méthode "grille de de Bruijn"
*# utiliser ces méthodes pour générer d'autres types de pavages apériodique.

* Liens pour démarrer
** [[https://fr.wikipedia.org/wiki/Pavage_de_Penrose pavage de Penrose (wikipedia]]
** [[https://www.maa.org/sites/default/files/pdf/pubs/focus/Gardner_PenroseTilings1-1977.pdf Penrose Tiling (Marting Gardner, en anglais)]]

== [[Algorithmes d'analyse syntaxique]] ==

* Tuteur : Pierre Hyvernat

* Résumé : le code source d'un programme, d'un fichier de configuration d'un serveur de base de données ou le code d'une page web sont des données ''textuelles'' et ''structurées''. Il est possible de définir exactement quelles données sont correctes, et quelle est leur signification. (Cela est beaucoup plus difficile pour des textes en langue naturelle par exemple.) En ce sens, il est possible de lire, d'interpréter ces données à l'aide d'un programme. On parle ''d'analyseur syntaxique'' ou de ''parseur''. Il existe de nombreux outils pour faire ça automatiquement, mais il est parfois important (et toujours intéressant) de comprendre les mécanismes correspondant. C'est ce que ce stage propose de faire.

* Objectifs :
*# étudier la formalisation du problème à travers la notion de ''langage'' et les premiers étages de la hiérachie de Chomsky (langages réguliers et grammaires hors contexte).
*# comprendre le lien entre les langages et les automates (automates finis / automates à pile)
*# implémenter un parseur "from scratch" et le tester sur des petits exemples simples, "à la main", soit en calculant "à la volée" la sémantique d'un langage, soit en produisant des "arbres de syntaxe abstraits", qui pourront être analysés par la suite,
*# comprendre les restrictions souvent imposées sur les grammaires afin d'améliorer l'efficacité du parseur (''LL*(k)'', ''LR'', etc.)
*# à partir de là, de nombreuses pistes sont ouvertes :
*#* essayer d'écrire un petit outils qui puisse lire une grammaire, et générer un parseur pour cette grammaire,
*#* comparer l'approche "automate" avec l'approche "combinateurs" et "parseur récursifs"
*#* améliorer l'efficacité des parseurs produits
*#* ajouter des fonctionnalités,
*#* ...

* Liens pour démarrer :
** [[https://en.wikipedia.org/wiki/Parsing page wikipedia "parsing"]]
** [[https://en.wikipedia.org/wiki/Recursive_descent_parser page wikipedia "recursive descent parser"]]
** Le livre référence sur le parsing est probablement "Compilers: Principles, Techniques, and Tools" de Aho, Sethi et Ullman (le "dragon book")
** [[https://web.stanford.edu/class/archive/cs/cs143/cs143.1128/ exemples de notes cours de compilation]]

= Sujets réalisés (2016-2017) =

* [[Algorithme de rendu de scène 3D par Z-buffer]]
* [[Traitement d'image]]
* [[Nim et la théorie des jeux impartiaux]]
* [[Calculabilité et modèles de calcul]]
* [[Génération et résolution de labyrinthes]]

= Sujets proposés (2016-2017) =

== [[Algorithme de rendu de scène 3D par Z-buffer]] ==

* Tuteur: Jacques-Olivier Lachaud
* Résumé: Le Z-buffer est un algorithme classique de rendu de scène 3D. C'est celui (avec quelques variantes) qui est implémenté dans nos cartes graphiques 3D et qui permet de visualiser des scènes extrêmement complexes en temps réel (typiquement 24 image/s).
* Objectifs:
*# décrire le principe de la projection 3D vers 2D
*# décrire la rastérisation des triangles sur une image en pixel
*# expliquer le principe du Z-buffer qui permet de gérer le fait que certains objets sont cachés par d'autres
*# expliquer comment les couleurs sont calculées par pixel
*# indiquer les qualités et limitations de l'algorithme
* Pour aller plus loin
*# mettre du code démo (WebGL) avec quelques explications sur le pipeline graphique OpenGL
*# expliquer comment on peut utiliser cet algorithme pour calculer des ombres (shadow map)
* Liens pour démarrer
** [[https://fr.wikipedia.org/wiki/Z-buffer Wikipedia]]
** [[https://www.scratchapixel.com/lessons/3d-basic-rendering/rasterization-practical-implementation/overview-rasterization-algorithm Scratch a pixel]]

== [[Traitement d'image]] ==

* Tuteur: Jacques-Olivier Lachaud
* Résumé: Le traitement d'image rassemble tous les algorithmes utilisés pour transformer les images, les améliorer, éliminer certaines perturbations, augmenter ou diminuer le contraste, changer les couleurs vers d'autres couleurs, éliminer le flou ou les yeux rouges, faire du cartooning pour un rendu moins photo-réaliste, etc.
* Objectifs:
*# identifier les grandes familles de traitement: restauration, égalisation, élimination du flou de déplacement, segmentation, etc
*# identifier les grandes familles de techniques: filtrage spatial, filtrage fréquentiel, optimisation, etc
*# comprendre les points communs et différences entre le traitement des images noir et blanc et le traitement des images couleurs.
*# choisir un ou deux algorithmes de traitement et les expliquer en détails
* Pour aller plus loin
*# Coder un algorithme de traitement d'image simple (e.g, un filtrage médian, ou un algo qui transporte les couleurs d'une photo vers une autre photo)

* Liens pour démarrer
** [[https://fr.wikipedia.org/wiki/Traitement_d%27images Wikipedia]]
** [[http://www.ipol.im/ Image Processing on line]] (permet de tester en ligne des algorithmes sur vos images)

== [[Nim et la théorie des jeux impartiaux]] ==

* Tuteur: Pierre Hyvernat

* Étudiant : Luca Chapelle

* Le jeu de Nim (aussi appelé jeu des allumettes) est l'un des premiers jeux ayant été analysé mathématiquement (par Charles Bouton en 1901). Les stratégies gagnantes peuvent être calculées en utilisant le développement en base 2 des nombres, et l'opération d'"addition de Nim" (XOR). La théorie de ce type de jeux (jeux "impartiaux") est assez simple, mais de nombreuses instances de jeux sont encore non résolues.
* Objectifs:
*# comprendre la théorie du jeu de Nim (et la programmer)
*# comprendre le théorème de Sprague Grundy qui montre que tout jeu impartial est équivalent à un jeu de nim
*# regarder quelques autres exemples de tels jeux : jeu de Nim déguisés, ou jeux véritablement différents
*# programmer une version naịve de recherche de stratégie basée sur le théorème de Sprague-Grundy pour quelques jeux

* Liens pour commencer
** [https://fr.wikipedia.org/wiki/Jeux_de_Nim jeu de Nim]
** [https://fr.wikipedia.org/wiki/Th%C3%A9or%C3%A8me_de_Sprague-Grundy théorème de Sprague Grundy]
** [https://fr.wikipedia.org/wiki/Jeu_de_Grundy jeu de Grundy]

== La suite de Conway et la classification périodique des "éléments" ==

* Tuteur : Pierre Hyvernat
* La suite de Conway est la suite suivante : 1 ; 11 ; 21 ; 1211 ; 111221 ; ... Chaque terme est obtenu en "lisant" le terme précédent.
** "1" : un "1" -> 11
** "11" : deux "1" -> 21
** "21" : un "2", un "1" -> 1211
** "1211" : un "1", un "2", deux "1" -> 111221
** etc.
Cette suite possède des propriétés étonantes données par le théorème "chimique", le théorème "arithmétique" et le théorème "cosmologique".
* Objectifs :
*# comprendre les énoncés de ces théorèmes, et l'idée de la preuve du premier.
*# programmer la suite de Conway pour retrouver la classification des "atomes"
*# écrire un programme pour calculer expérimentalement une approximation de la constante "lambda" ainsi que des fréquences respectives des différents atomes.
*# écrire un programme pour calculer la suite de Robinson, une variante plus simple de la suite de Conway

* Liens pour commencer
** [[https://fr.wikipedia.org/wiki/Suite_de_Conway suite de Conway]]
** [[https://fr.wikipedia.org/wiki/Suite_de_Robinson suite de Robinson]]

== Initiation à la démonstration sur ordinateur et certification de logiciel ==

* Tuteur: Tom Hirschowitz
* Résumé: [[https://coq.inria.fr Coq]] est un logiciel de mathématiques sur ordinateur, grâce auquel des programmes élaborés ont pu être certifiés ces dernières années.
* Objectifs:
*# prendre en main le logiciel [[https://coq.inria.fr Coq]] de démonstration sur ordinateur,
*# programmer certaines démonstrations basiques en Coq,
*# suivre le début du cours [[https://www.cis.upenn.edu/~bcpierce/sf Software Foundations]],
* Pour aller plus loin : Software Foundations est un cours assez long et très bien fait, il y aura suffisamment à faire. Eventuellement, selon l'intérêt de l'étudiant, étude des fondements mathématiques de Coq.
* Liens pour démarrer
** [[https://www.cis.upenn.edu/~bcpierce/sf Software Foundations]]
** [[https://coq.inria.fr Coq]]

== [[Calculabilité et modèles de calcul]] ==

* Tuteur: Rodolphe Lepigre
* Résumé: Une fonction f sur l'ensemble des entiers naturels est dite calculable s'il existe une procedure effective (ou un algorithme) qui permet, étant donné un entier n, de calculer f(n) en temps fini. Il existe divers modèles de calcul qui permettent de représenter toutes les fonctions calculables : machines de Turing, λ-calcul, automates cellulaires, ...
* Objectifs:
*# comprendre la notion de fonction calculable,
*# comparer l'ensemble des fonctions à l'ensemble des fonctions calculables,
*# regarder et comparer quelque modèles de calcul,
*# programmer un modèle de calcul et comprendre les limitations pratiques.

* Liens pour commencer:
** https://fr.wikipedia.org/wiki/Calculabilité
** https://fr.wikipedia.org/wiki/Machine_de_Turing
** https://fr.wikipedia.org/wiki/Lambda-calcul
** https://fr.wikipedia.org/wiki/Jeu_de_la_vie

== [[Génération et résolution de labyrinthes]] ==

* Tuteur: <strike>Jacques-Olivier Lachaud</strike> Xavier Provençal
* Résumé: On veut générer des labyrinthes aussi grands et complexes que possible, avec des murs dans une grille carré voire d'autres domaines. Comment faire pour qu'il y ait toujours un chemin de l'entrée à la sortie ? Comment faire pour qu'il n'y ait qu'un chemin ? Ensuite, comment trouver la sortie quand on est perdu dans le labyrinthe.
* Objectifs:
*# Comprendre comment représenter avec une structure de données un labyrinthe
*# Voir le lien avec la théorie des graphes et voir que le problème se résout de la même façon pour des grilles carrées, hexagonales ou autres.
*# Comprendre l'algorithme d'arbre couvrant minimum
*# Comprendre le principe du parcours en profondeur et de la récursivité
* Pour aller plus loin
*# coder la génération d'un labyrinthe et sa visualisation
* Liens pour démarrer
** [[https://fr.wikipedia.org/wiki/Mod%C3%A9lisation_math%C3%A9matique_d%27un_labyrinthe Wikipedia]]
** [[https://en.wikipedia.org/wiki/Maze_generation_algorithm Version anglaise plus complète]]

== Pavages par polyomino ==

* Tuteur: Xavier Provençal
* Résumé : On s'intéresse aux pavages du plan par des tuiles formées de petits carrés collés les uns aux autres, appelé "polyominos". Étant donné une tuile, peut-on paver le plan ? Si oui, avec quelles opérations (translation et/ou rotations et/ou réflexions) Une fois un pavage réalisé, on observe ses propriétés. Quelles symétries ? Le pavage est-il identique du point de vue de chacune des tuiles ? Si ce n'est pas le cas, en combien de classes peut-on diviser ces tuiles ?
On s'intéressera aussi à des propriétés connexes. Au lieu de paver tout le plan, on peut essayer de paver une région finie donnée. Plus localement, peut-on encercler complètement une tuile avec des copies d'elle-même, sans former de trous ? Si oui, peut-on faire de même avec la proto-tuile formée par la tuile de départ et toutes ses copies ? Si oui, combien de fois peut-on répéter l'opération ?
* Objectifs :
*# Comprendre les différentes classes de pavages (isohédral, k-isohédral, anisohédral).
*# Pour chacun des sept types de pavages "isohédraux", comprendre le lien entre les symétries du pavages et la caractérisation des tuiles qui le réalisent.
*# Pour un pavage k-isohédral, identifier les "classes d'équivalences" et le "domaine fondamental".
* Pour aller plus loin :
*# Coder la génération de tuiles capables de paver le plan en fonction pour une classe de pavages donnée.
*# Étudier et implémenter certains algorithmes pour le pavages d'un domaine fini.
* Liens pour démarrer
** [[https://fr.wikipedia.org/wiki/Polyomino Polyomino]]
** [[https://en.wikipedia.org/wiki/Polyomino Polyomino (en)]]
** [[https://fr.wikipedia.org/wiki/Pavage_par_des_polygones_r%C3%A9guliers Pavages]]

Rest & Pub-Sub : protocole hybride pour l'IoT

2019-05-19T23:51:46Z

Rakotoanosy :

__FORCETOC__L’avènement de l’Internet des Objets (IoT) depuis une dizaine d’années a fait apparaitre des problématiques propres aux protocoles de communications liées à ces objets. En effet, l’échange de données dans ce contexte nécessite de tenir compte (au moins) des paramètres suivant :
<ul>
<li>Autonomie énergétique souvent limitée</li>
<li>Faible puissance des processeurs et taille réduite de la mémoire</li>
<li>Disponibilité « aléatoire » de l’accès aux réseaux de communication</li>
</ul>
De nombreux protocoles cohabitent et la littérature du domaine foisonne d’exemples autour des réseaux dédiées (LORA, Sigfox, etc.) et des protocoles applicatifs (OPC-UA, MQTT, CoaP, XMPP) mais force est de constater que dans la réalité, ces solutions ne répondent pas toujours aux besoins des concepteurs qui leurs préfèrent encore le protocole HTTP. Celui-ci offre l’avantage d’implémenter un protocole applicatif (REST) en même temps qu’un protocole de transport de haut niveau (TCP/IP) permettant de passer les pare-feu. Cependant, la version actuel d’HTTP ne répond pas vraiment aux critères énoncés précédemment. Depuis quelques années émerge donc l’idée d’enrichir HTTP pour créer un protocole hybride qui mêlerait les avantages de REST avec ceux proposés par les mécanismes de type Publish/Subscribe (MQTT, AMQP, JMS, etc.). En attendant cette éventuelle évolution, peut-on envisager de mettre en place un mécanisme de type Pub/Sub avec le protocole Websocket au-dessus d’HTTP ?

== MQTT ==
MQTT, Message Queuing Telemetry Transport, est un protocole publish/subscribe se basant sur le protocole TCP/IP.
Il a été créé par Andy Stanford-Clark et Arlen Nipper.

De façon concrète, MQTT permet à des appareils de publier des informations sur un sujet donné sur un broker (un serveur qui fonctionne comme un coursier) qui va les retransmettre aux appareils abonnés à ce sujet.

[[Fichier:Fonctionnement broker mqtt.png|600px|thumb|left|illustration d'un échange entre un client 1 "subscriber" et un client 2 "publisher"]]

MQTT gère aussi la qualité de service (d'une qualité 0 à une qualité 2):

Qualité 0: le client qui publie une donnée ne reçoit aucune information par rapport à la confirmation de son arrivé.

Qualité 1: le client qui publie reçoit la confirmation ou non que la donnée publier à été reçu par le broker.

Qualité 2: le client qui publie reçoit la confirmation ou non que la donnée publier à été reçu par le broker ainsi qu'un message lui indiquant que le client qui s'abonne à reçu la donnée.
===Mosquitto===
Mosquitto est un broker open-source qui se sert du protocole MQTT. Il permet une fois installé de se familiarisé avec MQTT et le "publish/subscribe".

Nous nous en somme servit ici sur une MachineVirtuel en publiant en localhost:

[[Fichier:Mosquitto exemple.png]]

Sur un premier terminal on s'abonne à un topic "température" et sur un deuxième terminal, on publie ensuite sur ce même topic des nombres (qui s'apparentent à des température). Au fur et à mesure que nous publions ces informations, nous les recevons sur le premier terminal.
Mosquitto remplit bien ici son rôle de broker.

===Pub/Sub avec Python===

Nous avons ensuite développer un client ''publisher'' et un client ''subscriber'' en python grâce à la librairie paho-mqtt.
Pour plus de simplicité et éviter des problèmes de timing, nous avons tout regrouper en un seul programme:

import paho.mqtt.client as mqtt
import time

broker="test.mosquitto.org"

def envoi_message(client, QoS, message):
print("message reçu :", str(message.payload.decode("utf-8")))

client= mqtt.Client("client_test")
client.on_message=envoi_message

client.connect(broker)
print("connection")
client.loop_start()
client.subscribe("Cafetière/temperature_cafe")
print("Abonnement...")
time.sleep(1)
pub= input("entrez une température (un nombre):")
print("Publication...")
time.sleep(1)
client.publish("Cafetière/temperature_cafe",pub +"°C")
time.sleep(1)
client.disconnect()
print("deconnection")
client.loop_stop()
Comme broker, nous nous somme servit ici d'un broker mit en libre service par mosquitto.

==REST==
REST (Representational State Transfer) aussi appeler restful est une architecture logiciel inventer par Roy Fielding qui se sert des verbes HTTP comme identifiant des opérations et des réponses HTTP comme représentation des ressources.

Une architecture REST est définit par 5 règles/contraintes :

- '''Client–serveur'''

- '''Sans état'''

- '''Avec mise en cache'''

- '''En couches'''

- '''Interface uniforme :'''

L'interface uniforme est la contraintes fondamentale d'une architecture REST car c'est celle-ci qui permet à chaque composant d'évoluer indépendamment. Elle est définit par 4 contraintes :
<ul>
<li>Identification des ressources dans les requêtes</li>
<li>Manipulation des ressources par des représentations</li>
<li>Messages auto-descriptifs</li>
<li>Hypermédia comme moteur d'état de l'application</li>
</ul>

===Service pub/sub avec REST===
On peut réaliser un équivalent de service pub/sub avec REST à l'aide de GET et de POST qui agissent sur une base de données géré par un serveur:

[[Fichier:PubSub avec REST.png]]

Cette méthode comprend cependant de nombreux problèmes, notamment le fait que le client 1 ne sais pas si le client 2 à poster une donnée sur le serveur. On ne peut pas vraiment parler ici de service publish/subscribe car il n'y a pas d'abonnement, le client qui devrait s'abonner doit aller récupérer lui-même la donnée sans savoir si elle est bien dans la base de données du serveur.

==Protocole Hybride==

La technologie Pub/Sub et la technologie REST ont toutes deux leurs avantages et leurs inconvénients:

'''Avantages Pub/Sub :'''
<ul>
<li>Transfère rapide des informations</li>
<li>stockage des messages automatiques</li>
<li>gestion de la qualité de service</li>
</ul>
'''Inconvénient Pub/Sub :'''
<ul>
<li>On ne peut pas faire d’action direct sur le message, on ne fait un traitement dessus que lorsqu'on l'a reçu.</li>
<li>protocole mqtt,qui est bloquer par certain par feu</li>
</ul>
'''Avantages REST :'''
<ul>
<li>protocole http(port 80) passe partout dans le monde</li>
<li>on peut traiter le message directement sur le serveur</li>
</ul>
'''Inconvénient REST :'''
<ul>
<li>On doit installer un serveur web, on doit géré une base de donnée (ou XML, Json).</li>
</ul>

L'objectif du protocole hybride est de réaliser un système pub/sub tel que l'on ai:
<ul>
<li>un transfère rapide des informations</li>
<li>un stockage des messages automatiques</li>
<li>une gestion de la qualité de service</li>
<li>le protocole http (port 80) de sorte à ce qu'il fonctionne partout dans le monde.</li>
</ul>

Pour cela, nous allons nous servir des Websockets.

===MQTT sur Websocket===

Le protocole Websocket est un protocole qui vise à développer un canal de communication web sur une connexion TCP.

Les objectifs de ce protocole étaient notamment de permettre au serveur l'envoi de données vers le client en mode push (sans que l'utilisateur n'ai à faire une requête).

Pour notre protocole hybride, l'idée serai d'ouvrir un canal de communication Websocket entre le broker et le client.

Lorsque l'on envoie le message mqtt au broker, on le place dans un paquet websocket puis on l'envoi au broker. Lorsque le serveur reçoit le paquet, il l'ouvre et traite le message Mqtt contenu comme il l'aurai fait avec un message mqtt "normal". On fait de même lorsque le broker envoie un message au client qui c'est abonner.

On peut l'illustrer de la façon suivante :

[[Fichier:MQTT sur Websocket.png|500px]]

Ainsi puisque le protocole Websocket se sert du port 80, on conserve les avantages de la technologie pub/sub avec Mqtt tout en évitant le problème des par-feu que l'on pouvait rencontrer avec le protocole Mqtt.

==Sources==

[https://fr.wikipedia.org/wiki/Publish-subscribe Pub/Sub]

[https://fr.wikipedia.org/wiki/MQTT MQTT]

[https://pypi.org/project/paho-mqtt/ paho-mqtt]

[https://fr.wikipedia.org/wiki/Representational_state_transfer REST]

[https://fr.wikipedia.org/wiki/WebSocket Websocket]

Rest & Pub-Sub : protocole hybride pour l'IoT

2019-05-19T23:51:30Z

Rakotoanosy :

__FORCETOC__L’avènement de l’Internet des Objets (IoT) depuis une dizaine d’années a fait apparaitre des problématiques propres aux protocoles de communications liées à ces objets. En effet, l’échange de données dans ce contexte nécessite de tenir compte (au moins) des paramètres suivant :
<ul>
<li>Autonomie énergétique souvent limitée<li>
<li>Faible puissance des processeurs et taille réduite de la mémoire<li>
<li>Disponibilité « aléatoire » de l’accès aux réseaux de communication<li>
</ul>
De nombreux protocoles cohabitent et la littérature du domaine foisonne d’exemples autour des réseaux dédiées (LORA, Sigfox, etc.) et des protocoles applicatifs (OPC-UA, MQTT, CoaP, XMPP) mais force est de constater que dans la réalité, ces solutions ne répondent pas toujours aux besoins des concepteurs qui leurs préfèrent encore le protocole HTTP. Celui-ci offre l’avantage d’implémenter un protocole applicatif (REST) en même temps qu’un protocole de transport de haut niveau (TCP/IP) permettant de passer les pare-feu. Cependant, la version actuel d’HTTP ne répond pas vraiment aux critères énoncés précédemment. Depuis quelques années émerge donc l’idée d’enrichir HTTP pour créer un protocole hybride qui mêlerait les avantages de REST avec ceux proposés par les mécanismes de type Publish/Subscribe (MQTT, AMQP, JMS, etc.). En attendant cette éventuelle évolution, peut-on envisager de mettre en place un mécanisme de type Pub/Sub avec le protocole Websocket au-dessus d’HTTP ?

== MQTT ==
MQTT, Message Queuing Telemetry Transport, est un protocole publish/subscribe se basant sur le protocole TCP/IP.
Il a été créé par Andy Stanford-Clark et Arlen Nipper.

De façon concrète, MQTT permet à des appareils de publier des informations sur un sujet donné sur un broker (un serveur qui fonctionne comme un coursier) qui va les retransmettre aux appareils abonnés à ce sujet.

[[Fichier:Fonctionnement broker mqtt.png|600px|thumb|left|illustration d'un échange entre un client 1 "subscriber" et un client 2 "publisher"]]

MQTT gère aussi la qualité de service (d'une qualité 0 à une qualité 2):

Qualité 0: le client qui publie une donnée ne reçoit aucune information par rapport à la confirmation de son arrivé.

Qualité 1: le client qui publie reçoit la confirmation ou non que la donnée publier à été reçu par le broker.

Qualité 2: le client qui publie reçoit la confirmation ou non que la donnée publier à été reçu par le broker ainsi qu'un message lui indiquant que le client qui s'abonne à reçu la donnée.
===Mosquitto===
Mosquitto est un broker open-source qui se sert du protocole MQTT. Il permet une fois installé de se familiarisé avec MQTT et le "publish/subscribe".

Nous nous en somme servit ici sur une MachineVirtuel en publiant en localhost:

[[Fichier:Mosquitto exemple.png]]

Sur un premier terminal on s'abonne à un topic "température" et sur un deuxième terminal, on publie ensuite sur ce même topic des nombres (qui s'apparentent à des température). Au fur et à mesure que nous publions ces informations, nous les recevons sur le premier terminal.
Mosquitto remplit bien ici son rôle de broker.

===Pub/Sub avec Python===

Nous avons ensuite développer un client ''publisher'' et un client ''subscriber'' en python grâce à la librairie paho-mqtt.
Pour plus de simplicité et éviter des problèmes de timing, nous avons tout regrouper en un seul programme:

import paho.mqtt.client as mqtt
import time

broker="test.mosquitto.org"

def envoi_message(client, QoS, message):
print("message reçu :", str(message.payload.decode("utf-8")))

client= mqtt.Client("client_test")
client.on_message=envoi_message

client.connect(broker)
print("connection")
client.loop_start()
client.subscribe("Cafetière/temperature_cafe")
print("Abonnement...")
time.sleep(1)
pub= input("entrez une température (un nombre):")
print("Publication...")
time.sleep(1)
client.publish("Cafetière/temperature_cafe",pub +"°C")
time.sleep(1)
client.disconnect()
print("deconnection")
client.loop_stop()
Comme broker, nous nous somme servit ici d'un broker mit en libre service par mosquitto.

==REST==
REST (Representational State Transfer) aussi appeler restful est une architecture logiciel inventer par Roy Fielding qui se sert des verbes HTTP comme identifiant des opérations et des réponses HTTP comme représentation des ressources.

Une architecture REST est définit par 5 règles/contraintes :

- '''Client–serveur'''

- '''Sans état'''

- '''Avec mise en cache'''

- '''En couches'''

- '''Interface uniforme :'''

L'interface uniforme est la contraintes fondamentale d'une architecture REST car c'est celle-ci qui permet à chaque composant d'évoluer indépendamment. Elle est définit par 4 contraintes :
<ul>
<li>Identification des ressources dans les requêtes</li>
<li>Manipulation des ressources par des représentations</li>
<li>Messages auto-descriptifs</li>
<li>Hypermédia comme moteur d'état de l'application</li>
</ul>

===Service pub/sub avec REST===
On peut réaliser un équivalent de service pub/sub avec REST à l'aide de GET et de POST qui agissent sur une base de données géré par un serveur:

[[Fichier:PubSub avec REST.png]]

Cette méthode comprend cependant de nombreux problèmes, notamment le fait que le client 1 ne sais pas si le client 2 à poster une donnée sur le serveur. On ne peut pas vraiment parler ici de service publish/subscribe car il n'y a pas d'abonnement, le client qui devrait s'abonner doit aller récupérer lui-même la donnée sans savoir si elle est bien dans la base de données du serveur.

==Protocole Hybride==

La technologie Pub/Sub et la technologie REST ont toutes deux leurs avantages et leurs inconvénients:

'''Avantages Pub/Sub :'''
<ul>
<li>Transfère rapide des informations</li>
<li>stockage des messages automatiques</li>
<li>gestion de la qualité de service</li>
</ul>
'''Inconvénient Pub/Sub :'''
<ul>
<li>On ne peut pas faire d’action direct sur le message, on ne fait un traitement dessus que lorsqu'on l'a reçu.</li>
<li>protocole mqtt,qui est bloquer par certain par feu</li>
</ul>
'''Avantages REST :'''
<ul>
<li>protocole http(port 80) passe partout dans le monde</li>
<li>on peut traiter le message directement sur le serveur</li>
</ul>
'''Inconvénient REST :'''
<ul>
<li>On doit installer un serveur web, on doit géré une base de donnée (ou XML, Json).</li>
</ul>

L'objectif du protocole hybride est de réaliser un système pub/sub tel que l'on ai:
<ul>
<li>un transfère rapide des informations</li>
<li>un stockage des messages automatiques</li>
<li>une gestion de la qualité de service</li>
<li>le protocole http (port 80) de sorte à ce qu'il fonctionne partout dans le monde.</li>
</ul>

Pour cela, nous allons nous servir des Websockets.

===MQTT sur Websocket===

Le protocole Websocket est un protocole qui vise à développer un canal de communication web sur une connexion TCP.

Les objectifs de ce protocole étaient notamment de permettre au serveur l'envoi de données vers le client en mode push (sans que l'utilisateur n'ai à faire une requête).

Pour notre protocole hybride, l'idée serai d'ouvrir un canal de communication Websocket entre le broker et le client.

Lorsque l'on envoie le message mqtt au broker, on le place dans un paquet websocket puis on l'envoi au broker. Lorsque le serveur reçoit le paquet, il l'ouvre et traite le message Mqtt contenu comme il l'aurai fait avec un message mqtt "normal". On fait de même lorsque le broker envoie un message au client qui c'est abonner.

On peut l'illustrer de la façon suivante :

[[Fichier:MQTT sur Websocket.png|500px]]

Ainsi puisque le protocole Websocket se sert du port 80, on conserve les avantages de la technologie pub/sub avec Mqtt tout en évitant le problème des par-feu que l'on pouvait rencontrer avec le protocole Mqtt.

==Sources==

[https://fr.wikipedia.org/wiki/Publish-subscribe Pub/Sub]

[https://fr.wikipedia.org/wiki/MQTT MQTT]

[https://pypi.org/project/paho-mqtt/ paho-mqtt]

[https://fr.wikipedia.org/wiki/Representational_state_transfer REST]

[https://fr.wikipedia.org/wiki/WebSocket Websocket]

Génération et résolution de labyrinthes II

2019-05-19T23:49:36Z

Rakotoanosy :

__FORCETOC__[[Fichier:labyrinthe_photo.png|vignette|300px|Labyrinthe généré avec Kruskal et résolu avec le parcours en profondeur. En route foncé, l'entrée. En vert, la sortie. En bleu, le chemin. En rouge clair, les cellules visitées lors de la résolution.|alt="Labyrinthe"]]

On veut générer des labyrinthes aussi grands et complexes que possible, avec des murs dans une grille carré. Comment faire pour qu'il y ait toujours un chemin de l'entrée à la sortie ? Comment faire pour qu'il n'y ait qu'un chemin ? Et comment trouver la sortie quand on est perdu dans le labyrinthe ?

== Représentation ==

=== Propriétés ===

Un labyrinthe est une grille de cellules reliées, ou non, entre elles.

Deux cellules sont reliées entre elles par une '''porte''', ou séparées par un '''mur'''.

Tout labyrinthe a '''une entrée''' et '''une sortie''', et quelle que soit l'entrée ou la sortie, le chemin entre ces deux cellules est '''unique'''.

=== Modélisation en graphe ===

En théorie des graphes, un graphe est un ensemble de '''points''' (ou nœuds ou sommets) reliés ensemble par des '''lignes''' (ou liens ou arêtes).

[[Fichier:graphe_cyclique.png|vignette|left|300px|Exemple de graphe connexe cyclique non orienté|alt=Graphe cyclique]]

Un graphe peut être '''connexe''' (en un seul morceau) ou '''non connexe''' (en plusieurs morceaux).

Un graphe peut aussi être '''cyclique''' si les points sont reliés en formant une boucle ou '''acyclique'''.

Enfin, un graphe peut être '''orienté''' (si les arêtes sont à sens unique) ou '''non orienté'''.

[[Fichier:Arbre.PNG|vignette|left|300px|Exemple d'arbre|alt=Arbre]]

Un '''arbre''' est un graphe connexe, acyclique et non orienté.

En plaçant un point sur chaque cellule de notre labyrinthe, et en reliant deux cellules séparées par une porte, on peut dessiner un arbre à partir de n'importe quel labyrinthe.

[[Fichier:labyrinthe_avec_arbre.png|vignette|centre|300px|Exemple de labyrinthe avec son arbre. Pour plus de simplicité, on attribue à chaque nœud une position.|alt=Labyrinthe avec arbre]]

== Génération ==

Un labyrinthe rectangulaire de largeur <math> L </math> et de hauteur <math> H </math> contient exactement <math>L \times H - 1</math> portes.

Du point de vue du graphe, il y a donc <math>L \times H - 1</math> arêtes.

Maintenant, comment répartir toutes ces portes de façon à ce que toutes les cellules soient accessibles et qu'il n'existe qu'un unique chemin entre l'entrée et la sortie ?

De nombreux algorithmes existent, dont le parcours en profondeur et l'algorithme de Kruskal.
Chaque algorithme est différent et produit des labyrinthes visuellement différents.

En effet, si nous comparons un labyrinthe généré avec l'algorithme du parcours en profondeur à un labyrinthe généré avec l'algorithme de Kruskal, bien qu'ils aient tous les deux une solution unique, ils apparaissent néanmoins différents visuellement.

[[Fichier:recursive_backtracker_comparaison.png|vignette|left|500px|Parcours en profondeur. On remarque des chemins proprement dessinés.|alt=Parcours en profondeur]]
[[Fichier:kruskal_comparaison.png|vignette|right|500px|Algorithme de Kruskal. On remarque des murs de 1 de longueur çà et là.|alt=Kruskal]]

=== Parcours en profondeur ===

[[Fichier:recursive_backtracker.gif|vignette|left|500px|Illustration du parcours en profondeur|alt=Parcours en profondeur]]

Dans l'algorithme du parcours en profondeur ("recursive backtracker" en anglais), on commence sur une cellule aléatoire dans le labyrinthe.

On se dirige dans une direction aléatoire et on casse le mur en face, tout en marquant la cellule précédente comme visitée.

Lorsque aucune direction n'est disponible, on remonte à la position précédente.

[[Fichier:pile.png|vignette|300px|Représentation d'une pile de positions|alt=Pile]]

Pour sauvegarder l'historique des positions, on peut utiliser une '''pile'''.

Une pile est une liste dans laquelle seul le dernier élément peut être récupéré.

Une pile contient 2 méthodes :
* push(elem) : ajoute elem à la pile
* pop() -> elem : retourne le dernier élément de la pile (elem dans notre cas)

Dans mon implémentation de la pile, une erreur est levée si l'on appelle la méthode pop sur une pile vide.

=== Kruskal ===

[[Fichier:kruskal.gif|vignette|left|500px|Illustration de l'algorithme de Kruskal.|alt=Kruskal]]

Alors que pour le parcours en profondeur on partait des cellules, l'algorithme de Kruskal s'applique sur des murs.

On attribue à chaque cellule un identifiant unique.

On choisit un mur aléatoire. Si les cellules séparées par ce mur ont des identifiants différents, on leur associe le même identifiant et on casse le mur.

Sinon, on passe à un autre mur.

[[Fichier:union_find.png|vignette|300px|Représentation d'une structure Union-Find avec find(a,b) et find(b,c).|alt=Union-Find]]

Pour mettre en œuvre cet algorithme, on utilise une structure de données appelée '''Union-Find''', qui permet de mettre en relation des éléments partageant un même représentant (ou un même identifiant).

Il existe plusieurs variantes d'Union-Find, dont notamment la compression de chemin, qui permet de n'avoir qu'un ou deux éléments à parcourir pour obtenir le représentant d'un élément.

Union-Find fonctionne comme un arbre. <math>a</math> a un représentant <math>A</math>, etc..., qui lui même a un représentant <math>\alpha</math>, qui est son propre représentant.

Union-Find est composé de deux méthodes :
* union(a, b) : associe à <math>a</math> et <math>b</math> le même représentant, par exemple <math>A</math> le représentant de <math>a</math>
* find(a) -> <math>\alpha</math> : tant que l'élément n'est pas son propre représentant, on applique find au représentant de l'élément. On commence donc par find(a), puis find(A) (si <math>A</math> est le représentant de <math>a</math>), etc... La méthode de la compression de chemin permet d'éviter trop de récursivité en écrivant : représentant de <math>a</math> := <math>\alpha</math>

=== Labyrinthes cycliques ===

Il est possible, en retirant un certain pourcentage de murs, de créer des labyrinthes cycliques à partir des labyrinthes acycliques générés auparavant.

Cependant, certains algorithmes de résolution n'adopteront pas le même comportement.

== Résolution ==

Il existe là encore de nombreux algorithmes de résolution de labyrinthes, plus ou moins efficaces, et surtout ne fonctionnant pas tous dans les mêmes conditions.

=== Parcours en profondeur ===

Cet algorithme est quasiment identique à celui du parcours en profondeur pour la génération.

Il est très efficace et trouvera une solution en minimisant le nombre de cases visitées.

Il s'adapte aux labyrinthes cycliques. En cas de boucle, il ne fera pas la boucle vu que l'intersection a déjà été visitées, il reviendra sur ses pas.

Il s'adapte aux labyrinthes sans solution. En effet, s'il n'y a pas de sortie, il va revenir à sa position de départ sans position précédente (pile vide) et en ayant parcouru toutes les cases.

=== Mur droit ===

Cet algorithme va suivre de la main droite le mur de droite.

Il est relativement inefficace, et va visiter un grand nombre de cases.

Il s'adapte assez mal aux labyrinthes cycliques. En effet, si la sortie n'est pas dans la même boucle que l'entrée, il ne la trouvera jamais.

Il ne s'adapte pas aux labyrinthes sans solution, et fera le tour de la grille à l'infini.

[[Fichier:labyrinthe_exp_exhaust.png|vignette|left|500px|Labyrinthe résolu en utilisant le parcours en profondeur. 660 cellules visitées, 1179 déplacements, chemin de 142 cellules.|alt=Parcours en profondeur]]
[[Fichier:labyrinthe_right_hand.png|vignette|right|500px|Labyrinthe résolu en utilisant le mur droit. 1068 cellules visitées, 1995 déplacements, chemin de 142 cellules.|alt=Mur droit]]

== Code source ==

Mon projet total contenant plusieurs milliers de lignes de code réparties dans une dizaine de fichiers, je ne peux évidemment pas l'insérer directement dans cette page.

Le code source est disponible sur Github à [https://github.com/Rominos111/Labyrinthe_VISI201 cette adresse]

Il suffit d'avoir installé Python 3 et tkinter.

== Sources ==

Génération
<ul>
<li> [https://fr.wikipedia.org/wiki/Mod%C3%A9lisation_math%C3%A9matique_de_labyrinthe#Fusion_al%C3%A9atoire_de_chemins Kruskal (fr)] </li>
<li> [https://en.wikipedia.org/wiki/Maze_generation_algorithm#Randomized_Kruskal's_algorithm Kruskal (en)] </li>
<li> [https://fr.wikipedia.org/wiki/Mod%C3%A9lisation_math%C3%A9matique_de_labyrinthe#Exploration_exhaustive Parcours en profondeur (fr)] </li>
<li> [https://en.wikipedia.org/wiki/Maze_generation_algorithm#Randomized_Depth-First_Search Parcours en profondeur (en)] </li>
</ul>

Résolution
<ul>
<li> [https://fr.wikipedia.org/wiki/Mod%C3%A9lisation_math%C3%A9matique_de_labyrinthe#R%C3%A9solution Résolution générale (fr)] </li>
<li> [https://en.wikipedia.org/wiki/Maze_solving_algorithm#Wall_follower Mur droit (en)] </li>
</ul>

Structures de données
<ul>
<li> [https://fr.wikipedia.org/wiki/Union-find Union-Find / Disjoint-Set (fr)] </li>
<li> [https://en.wikipedia.org/wiki/Stack_(abstract_data_type) Pile / Stack (en)] </li>
<li> [https://en.wikipedia.org/wiki/Queue_(abstract_data_type) File / Queue (en)] </li>
</ul>

Python
<ul>
<li> [https://docs.python.org/3.6/reference/datamodel.html Classes et types de variables personnalisés (en)] </li>
<li> [http://effbot.org/tkinterbook/canvas.htm Canvas Tkinter (en)] </li>
</ul>

Génération et résolution de labyrinthes II

2019-05-19T23:48:27Z

Rakotoanosy : Annulation des modifications 11819 de Rakotoanosy (discussion)

__FORCETOC__ L’avènement de l’Internet des Objets (IoT) depuis une dizaine d’années a fait apparaitre des problématiques propres aux protocoles de communications liées à ces objets. En effet, l’échange de données dans ce contexte nécessite de tenir compte (au moins) des paramètres suivant :
Autonomie énergétique souvent limitée
Faible puissance des processeurs et taille réduite de la mémoire
Disponibilité « aléatoire » de l’accès aux réseaux de communication

De nombreux protocoles cohabitent et la littérature du domaine foisonne d’exemples autour des réseaux dédiées (LORA, Sigfox, etc.) et des protocoles applicatifs (OPC-UA, MQTT, CoaP, XMPP) mais force est de constater que dans la réalité, ces solutions ne répondent pas toujours aux besoins des concepteurs qui leurs préfèrent encore le protocole HTTP. Celui-ci offre l’avantage d’implémenter un protocole applicatif (REST) en même temps qu’un protocole de transport de haut niveau (TCP/IP) permettant de passer les pare-feu. Cependant, la version actuel d’HTTP ne répond pas vraiment aux critères énoncés précédemment. Depuis quelques années émerge donc l’idée d’enrichir HTTP pour créer un protocole hybride qui mêlerait les avantages de REST avec ceux proposés par les mécanismes de type Publish/Subscribe (MQTT, AMQP, JMS, etc.). En attendant cette éventuelle évolution, peut-on envisager de mettre en place un mécanisme de type Pub/Sub avec le protocole Websocket au-dessus d’HTTP ?

== Représentation ==

=== Propriétés ===

Un labyrinthe est une grille de cellules reliées, ou non, entre elles.

Deux cellules sont reliées entre elles par une '''porte''', ou séparées par un '''mur'''.

Tout labyrinthe a '''une entrée''' et '''une sortie''', et quelle que soit l'entrée ou la sortie, le chemin entre ces deux cellules est '''unique'''.

=== Modélisation en graphe ===

En théorie des graphes, un graphe est un ensemble de '''points''' (ou nœuds ou sommets) reliés ensemble par des '''lignes''' (ou liens ou arêtes).

[[Fichier:graphe_cyclique.png|vignette|left|300px|Exemple de graphe connexe cyclique non orienté|alt=Graphe cyclique]]

Un graphe peut être '''connexe''' (en un seul morceau) ou '''non connexe''' (en plusieurs morceaux).

Un graphe peut aussi être '''cyclique''' si les points sont reliés en formant une boucle ou '''acyclique'''.

Enfin, un graphe peut être '''orienté''' (si les arêtes sont à sens unique) ou '''non orienté'''.

[[Fichier:Arbre.PNG|vignette|left|300px|Exemple d'arbre|alt=Arbre]]

Un '''arbre''' est un graphe connexe, acyclique et non orienté.

En plaçant un point sur chaque cellule de notre labyrinthe, et en reliant deux cellules séparées par une porte, on peut dessiner un arbre à partir de n'importe quel labyrinthe.

[[Fichier:labyrinthe_avec_arbre.png|vignette|centre|300px|Exemple de labyrinthe avec son arbre. Pour plus de simplicité, on attribue à chaque nœud une position.|alt=Labyrinthe avec arbre]]

== Génération ==

Un labyrinthe rectangulaire de largeur <math> L </math> et de hauteur <math> H </math> contient exactement <math>L \times H - 1</math> portes.

Du point de vue du graphe, il y a donc <math>L \times H - 1</math> arêtes.

Maintenant, comment répartir toutes ces portes de façon à ce que toutes les cellules soient accessibles et qu'il n'existe qu'un unique chemin entre l'entrée et la sortie ?

De nombreux algorithmes existent, dont le parcours en profondeur et l'algorithme de Kruskal.
Chaque algorithme est différent et produit des labyrinthes visuellement différents.

En effet, si nous comparons un labyrinthe généré avec l'algorithme du parcours en profondeur à un labyrinthe généré avec l'algorithme de Kruskal, bien qu'ils aient tous les deux une solution unique, ils apparaissent néanmoins différents visuellement.

[[Fichier:recursive_backtracker_comparaison.png|vignette|left|500px|Parcours en profondeur. On remarque des chemins proprement dessinés.|alt=Parcours en profondeur]]
[[Fichier:kruskal_comparaison.png|vignette|right|500px|Algorithme de Kruskal. On remarque des murs de 1 de longueur çà et là.|alt=Kruskal]]

=== Parcours en profondeur ===

[[Fichier:recursive_backtracker.gif|vignette|left|500px|Illustration du parcours en profondeur|alt=Parcours en profondeur]]

Dans l'algorithme du parcours en profondeur ("recursive backtracker" en anglais), on commence sur une cellule aléatoire dans le labyrinthe.

On se dirige dans une direction aléatoire et on casse le mur en face, tout en marquant la cellule précédente comme visitée.

Lorsque aucune direction n'est disponible, on remonte à la position précédente.

[[Fichier:pile.png|vignette|300px|Représentation d'une pile de positions|alt=Pile]]

Pour sauvegarder l'historique des positions, on peut utiliser une '''pile'''.

Une pile est une liste dans laquelle seul le dernier élément peut être récupéré.

Une pile contient 2 méthodes :
* push(elem) : ajoute elem à la pile
* pop() -> elem : retourne le dernier élément de la pile (elem dans notre cas)

Dans mon implémentation de la pile, une erreur est levée si l'on appelle la méthode pop sur une pile vide.

=== Kruskal ===

[[Fichier:kruskal.gif|vignette|left|500px|Illustration de l'algorithme de Kruskal.|alt=Kruskal]]

Alors que pour le parcours en profondeur on partait des cellules, l'algorithme de Kruskal s'applique sur des murs.

On attribue à chaque cellule un identifiant unique.

On choisit un mur aléatoire. Si les cellules séparées par ce mur ont des identifiants différents, on leur associe le même identifiant et on casse le mur.

Sinon, on passe à un autre mur.

[[Fichier:union_find.png|vignette|300px|Représentation d'une structure Union-Find avec find(a,b) et find(b,c).|alt=Union-Find]]

Pour mettre en œuvre cet algorithme, on utilise une structure de données appelée '''Union-Find''', qui permet de mettre en relation des éléments partageant un même représentant (ou un même identifiant).

Il existe plusieurs variantes d'Union-Find, dont notamment la compression de chemin, qui permet de n'avoir qu'un ou deux éléments à parcourir pour obtenir le représentant d'un élément.

Union-Find fonctionne comme un arbre. <math>a</math> a un représentant <math>A</math>, etc..., qui lui même a un représentant <math>\alpha</math>, qui est son propre représentant.

Union-Find est composé de deux méthodes :
* union(a, b) : associe à <math>a</math> et <math>b</math> le même représentant, par exemple <math>A</math> le représentant de <math>a</math>
* find(a) -> <math>\alpha</math> : tant que l'élément n'est pas son propre représentant, on applique find au représentant de l'élément. On commence donc par find(a), puis find(A) (si <math>A</math> est le représentant de <math>a</math>), etc... La méthode de la compression de chemin permet d'éviter trop de récursivité en écrivant : représentant de <math>a</math> := <math>\alpha</math>

=== Labyrinthes cycliques ===

Il est possible, en retirant un certain pourcentage de murs, de créer des labyrinthes cycliques à partir des labyrinthes acycliques générés auparavant.

Cependant, certains algorithmes de résolution n'adopteront pas le même comportement.

== Résolution ==

Il existe là encore de nombreux algorithmes de résolution de labyrinthes, plus ou moins efficaces, et surtout ne fonctionnant pas tous dans les mêmes conditions.

=== Parcours en profondeur ===

Cet algorithme est quasiment identique à celui du parcours en profondeur pour la génération.

Il est très efficace et trouvera une solution en minimisant le nombre de cases visitées.

Il s'adapte aux labyrinthes cycliques. En cas de boucle, il ne fera pas la boucle vu que l'intersection a déjà été visitées, il reviendra sur ses pas.

Il s'adapte aux labyrinthes sans solution. En effet, s'il n'y a pas de sortie, il va revenir à sa position de départ sans position précédente (pile vide) et en ayant parcouru toutes les cases.

=== Mur droit ===

Cet algorithme va suivre de la main droite le mur de droite.

Il est relativement inefficace, et va visiter un grand nombre de cases.

Il s'adapte assez mal aux labyrinthes cycliques. En effet, si la sortie n'est pas dans la même boucle que l'entrée, il ne la trouvera jamais.

Il ne s'adapte pas aux labyrinthes sans solution, et fera le tour de la grille à l'infini.

[[Fichier:labyrinthe_exp_exhaust.png|vignette|left|500px|Labyrinthe résolu en utilisant le parcours en profondeur. 660 cellules visitées, 1179 déplacements, chemin de 142 cellules.|alt=Parcours en profondeur]]
[[Fichier:labyrinthe_right_hand.png|vignette|right|500px|Labyrinthe résolu en utilisant le mur droit. 1068 cellules visitées, 1995 déplacements, chemin de 142 cellules.|alt=Mur droit]]

== Code source ==

Mon projet total contenant plusieurs milliers de lignes de code réparties dans une dizaine de fichiers, je ne peux évidemment pas l'insérer directement dans cette page.

Le code source est disponible sur Github à [https://github.com/Rominos111/Labyrinthe_VISI201 cette adresse]

Il suffit d'avoir installé Python 3 et tkinter.

== Sources ==

Génération
<ul>
<li> [https://fr.wikipedia.org/wiki/Mod%C3%A9lisation_math%C3%A9matique_de_labyrinthe#Fusion_al%C3%A9atoire_de_chemins Kruskal (fr)] </li>
<li> [https://en.wikipedia.org/wiki/Maze_generation_algorithm#Randomized_Kruskal's_algorithm Kruskal (en)] </li>
<li> [https://fr.wikipedia.org/wiki/Mod%C3%A9lisation_math%C3%A9matique_de_labyrinthe#Exploration_exhaustive Parcours en profondeur (fr)] </li>
<li> [https://en.wikipedia.org/wiki/Maze_generation_algorithm#Randomized_Depth-First_Search Parcours en profondeur (en)] </li>
</ul>

Résolution
<ul>
<li> [https://fr.wikipedia.org/wiki/Mod%C3%A9lisation_math%C3%A9matique_de_labyrinthe#R%C3%A9solution Résolution générale (fr)] </li>
<li> [https://en.wikipedia.org/wiki/Maze_solving_algorithm#Wall_follower Mur droit (en)] </li>
</ul>

Structures de données
<ul>
<li> [https://fr.wikipedia.org/wiki/Union-find Union-Find / Disjoint-Set (fr)] </li>
<li> [https://en.wikipedia.org/wiki/Stack_(abstract_data_type) Pile / Stack (en)] </li>
<li> [https://en.wikipedia.org/wiki/Queue_(abstract_data_type) File / Queue (en)] </li>
</ul>

Python
<ul>
<li> [https://docs.python.org/3.6/reference/datamodel.html Classes et types de variables personnalisés (en)] </li>
<li> [http://effbot.org/tkinterbook/canvas.htm Canvas Tkinter (en)] </li>
</ul>

Génération et résolution de labyrinthes II

2019-05-19T23:47:40Z

Rakotoanosy :

__FORCETOC__L’avènement de l’Internet des Objets (IoT) depuis une dizaine d’années a fait apparaitre des problématiques propres aux protocoles de communications liées à ces objets. En effet, l’échange de données dans ce contexte nécessite de tenir compte (au moins) des paramètres suivant :
<ul>
<li>Autonomie énergétique souvent limitée</li>
<li>Faible puissance des processeurs et taille réduite de la mémoire</li>
<li>Disponibilité « aléatoire » de l’accès aux réseaux de communication</li>
</ul>
De nombreux protocoles cohabitent et la littérature du domaine foisonne d’exemples autour des réseaux dédiées (LORA, Sigfox, etc.) et des protocoles applicatifs (OPC-UA, MQTT, CoaP, XMPP) mais force est de constater que dans la réalité, ces solutions ne répondent pas toujours aux besoins des concepteurs qui leurs préfèrent encore le protocole HTTP. Celui-ci offre l’avantage d’implémenter un protocole applicatif (REST) en même temps qu’un protocole de transport de haut niveau (TCP/IP) permettant de passer les pare-feu. Cependant, la version actuel d’HTTP ne répond pas vraiment aux critères énoncés précédemment. Depuis quelques années émerge donc l’idée d’enrichir HTTP pour créer un protocole hybride qui mêlerait les avantages de REST avec ceux proposés par les mécanismes de type Publish/Subscribe (MQTT, AMQP, JMS, etc.). En attendant cette éventuelle évolution, peut-on envisager de mettre en place un mécanisme de type Pub/Sub avec le protocole Websocket au-dessus d’HTTP ?

== Représentation ==

=== Propriétés ===

Un labyrinthe est une grille de cellules reliées, ou non, entre elles.

Deux cellules sont reliées entre elles par une '''porte''', ou séparées par un '''mur'''.

Tout labyrinthe a '''une entrée''' et '''une sortie''', et quelle que soit l'entrée ou la sortie, le chemin entre ces deux cellules est '''unique'''.

=== Modélisation en graphe ===

En théorie des graphes, un graphe est un ensemble de '''points''' (ou nœuds ou sommets) reliés ensemble par des '''lignes''' (ou liens ou arêtes).

[[Fichier:graphe_cyclique.png|vignette|left|300px|Exemple de graphe connexe cyclique non orienté|alt=Graphe cyclique]]

Un graphe peut être '''connexe''' (en un seul morceau) ou '''non connexe''' (en plusieurs morceaux).

Un graphe peut aussi être '''cyclique''' si les points sont reliés en formant une boucle ou '''acyclique'''.

Enfin, un graphe peut être '''orienté''' (si les arêtes sont à sens unique) ou '''non orienté'''.

[[Fichier:Arbre.PNG|vignette|left|300px|Exemple d'arbre|alt=Arbre]]

Un '''arbre''' est un graphe connexe, acyclique et non orienté.

En plaçant un point sur chaque cellule de notre labyrinthe, et en reliant deux cellules séparées par une porte, on peut dessiner un arbre à partir de n'importe quel labyrinthe.

[[Fichier:labyrinthe_avec_arbre.png|vignette|centre|300px|Exemple de labyrinthe avec son arbre. Pour plus de simplicité, on attribue à chaque nœud une position.|alt=Labyrinthe avec arbre]]

== Génération ==

Un labyrinthe rectangulaire de largeur <math> L </math> et de hauteur <math> H </math> contient exactement <math>L \times H - 1</math> portes.

Du point de vue du graphe, il y a donc <math>L \times H - 1</math> arêtes.

Maintenant, comment répartir toutes ces portes de façon à ce que toutes les cellules soient accessibles et qu'il n'existe qu'un unique chemin entre l'entrée et la sortie ?

De nombreux algorithmes existent, dont le parcours en profondeur et l'algorithme de Kruskal.
Chaque algorithme est différent et produit des labyrinthes visuellement différents.

En effet, si nous comparons un labyrinthe généré avec l'algorithme du parcours en profondeur à un labyrinthe généré avec l'algorithme de Kruskal, bien qu'ils aient tous les deux une solution unique, ils apparaissent néanmoins différents visuellement.

[[Fichier:recursive_backtracker_comparaison.png|vignette|left|500px|Parcours en profondeur. On remarque des chemins proprement dessinés.|alt=Parcours en profondeur]]
[[Fichier:kruskal_comparaison.png|vignette|right|500px|Algorithme de Kruskal. On remarque des murs de 1 de longueur çà et là.|alt=Kruskal]]

=== Parcours en profondeur ===

[[Fichier:recursive_backtracker.gif|vignette|left|500px|Illustration du parcours en profondeur|alt=Parcours en profondeur]]

Dans l'algorithme du parcours en profondeur ("recursive backtracker" en anglais), on commence sur une cellule aléatoire dans le labyrinthe.

On se dirige dans une direction aléatoire et on casse le mur en face, tout en marquant la cellule précédente comme visitée.

Lorsque aucune direction n'est disponible, on remonte à la position précédente.

[[Fichier:pile.png|vignette|300px|Représentation d'une pile de positions|alt=Pile]]

Pour sauvegarder l'historique des positions, on peut utiliser une '''pile'''.

Une pile est une liste dans laquelle seul le dernier élément peut être récupéré.

Une pile contient 2 méthodes :
* push(elem) : ajoute elem à la pile
* pop() -> elem : retourne le dernier élément de la pile (elem dans notre cas)

Dans mon implémentation de la pile, une erreur est levée si l'on appelle la méthode pop sur une pile vide.

=== Kruskal ===

[[Fichier:kruskal.gif|vignette|left|500px|Illustration de l'algorithme de Kruskal.|alt=Kruskal]]

Alors que pour le parcours en profondeur on partait des cellules, l'algorithme de Kruskal s'applique sur des murs.

On attribue à chaque cellule un identifiant unique.

On choisit un mur aléatoire. Si les cellules séparées par ce mur ont des identifiants différents, on leur associe le même identifiant et on casse le mur.

Sinon, on passe à un autre mur.

[[Fichier:union_find.png|vignette|300px|Représentation d'une structure Union-Find avec find(a,b) et find(b,c).|alt=Union-Find]]

Pour mettre en œuvre cet algorithme, on utilise une structure de données appelée '''Union-Find''', qui permet de mettre en relation des éléments partageant un même représentant (ou un même identifiant).

Il existe plusieurs variantes d'Union-Find, dont notamment la compression de chemin, qui permet de n'avoir qu'un ou deux éléments à parcourir pour obtenir le représentant d'un élément.

Union-Find fonctionne comme un arbre. <math>a</math> a un représentant <math>A</math>, etc..., qui lui même a un représentant <math>\alpha</math>, qui est son propre représentant.

Union-Find est composé de deux méthodes :
* union(a, b) : associe à <math>a</math> et <math>b</math> le même représentant, par exemple <math>A</math> le représentant de <math>a</math>
* find(a) -> <math>\alpha</math> : tant que l'élément n'est pas son propre représentant, on applique find au représentant de l'élément. On commence donc par find(a), puis find(A) (si <math>A</math> est le représentant de <math>a</math>), etc... La méthode de la compression de chemin permet d'éviter trop de récursivité en écrivant : représentant de <math>a</math> := <math>\alpha</math>

=== Labyrinthes cycliques ===

Il est possible, en retirant un certain pourcentage de murs, de créer des labyrinthes cycliques à partir des labyrinthes acycliques générés auparavant.

Cependant, certains algorithmes de résolution n'adopteront pas le même comportement.

== Résolution ==

Il existe là encore de nombreux algorithmes de résolution de labyrinthes, plus ou moins efficaces, et surtout ne fonctionnant pas tous dans les mêmes conditions.

=== Parcours en profondeur ===

Cet algorithme est quasiment identique à celui du parcours en profondeur pour la génération.

Il est très efficace et trouvera une solution en minimisant le nombre de cases visitées.

Il s'adapte aux labyrinthes cycliques. En cas de boucle, il ne fera pas la boucle vu que l'intersection a déjà été visitées, il reviendra sur ses pas.

Il s'adapte aux labyrinthes sans solution. En effet, s'il n'y a pas de sortie, il va revenir à sa position de départ sans position précédente (pile vide) et en ayant parcouru toutes les cases.

=== Mur droit ===

Cet algorithme va suivre de la main droite le mur de droite.

Il est relativement inefficace, et va visiter un grand nombre de cases.

Il s'adapte assez mal aux labyrinthes cycliques. En effet, si la sortie n'est pas dans la même boucle que l'entrée, il ne la trouvera jamais.

Il ne s'adapte pas aux labyrinthes sans solution, et fera le tour de la grille à l'infini.

[[Fichier:labyrinthe_exp_exhaust.png|vignette|left|500px|Labyrinthe résolu en utilisant le parcours en profondeur. 660 cellules visitées, 1179 déplacements, chemin de 142 cellules.|alt=Parcours en profondeur]]
[[Fichier:labyrinthe_right_hand.png|vignette|right|500px|Labyrinthe résolu en utilisant le mur droit. 1068 cellules visitées, 1995 déplacements, chemin de 142 cellules.|alt=Mur droit]]

== Code source ==

Mon projet total contenant plusieurs milliers de lignes de code réparties dans une dizaine de fichiers, je ne peux évidemment pas l'insérer directement dans cette page.

Le code source est disponible sur Github à [https://github.com/Rominos111/Labyrinthe_VISI201 cette adresse]

Il suffit d'avoir installé Python 3 et tkinter.

== Sources ==

Génération
<ul>
<li> [https://fr.wikipedia.org/wiki/Mod%C3%A9lisation_math%C3%A9matique_de_labyrinthe#Fusion_al%C3%A9atoire_de_chemins Kruskal (fr)] </li>
<li> [https://en.wikipedia.org/wiki/Maze_generation_algorithm#Randomized_Kruskal's_algorithm Kruskal (en)] </li>
<li> [https://fr.wikipedia.org/wiki/Mod%C3%A9lisation_math%C3%A9matique_de_labyrinthe#Exploration_exhaustive Parcours en profondeur (fr)] </li>
<li> [https://en.wikipedia.org/wiki/Maze_generation_algorithm#Randomized_Depth-First_Search Parcours en profondeur (en)] </li>
</ul>

Résolution
<ul>
<li> [https://fr.wikipedia.org/wiki/Mod%C3%A9lisation_math%C3%A9matique_de_labyrinthe#R%C3%A9solution Résolution générale (fr)] </li>
<li> [https://en.wikipedia.org/wiki/Maze_solving_algorithm#Wall_follower Mur droit (en)] </li>
</ul>

Structures de données
<ul>
<li> [https://fr.wikipedia.org/wiki/Union-find Union-Find / Disjoint-Set (fr)] </li>
<li> [https://en.wikipedia.org/wiki/Stack_(abstract_data_type) Pile / Stack (en)] </li>
<li> [https://en.wikipedia.org/wiki/Queue_(abstract_data_type) File / Queue (en)] </li>
</ul>

Python
<ul>
<li> [https://docs.python.org/3.6/reference/datamodel.html Classes et types de variables personnalisés (en)] </li>
<li> [http://effbot.org/tkinterbook/canvas.htm Canvas Tkinter (en)] </li>
</ul>

Génération et résolution de labyrinthes II

2019-05-19T23:46:50Z

Rakotoanosy :

__FORCETOC__ L’avènement de l’Internet des Objets (IoT) depuis une dizaine d’années a fait apparaitre des problématiques propres aux protocoles de communications liées à ces objets. En effet, l’échange de données dans ce contexte nécessite de tenir compte (au moins) des paramètres suivant :
Autonomie énergétique souvent limitée
Faible puissance des processeurs et taille réduite de la mémoire
Disponibilité « aléatoire » de l’accès aux réseaux de communication

De nombreux protocoles cohabitent et la littérature du domaine foisonne d’exemples autour des réseaux dédiées (LORA, Sigfox, etc.) et des protocoles applicatifs (OPC-UA, MQTT, CoaP, XMPP) mais force est de constater que dans la réalité, ces solutions ne répondent pas toujours aux besoins des concepteurs qui leurs préfèrent encore le protocole HTTP. Celui-ci offre l’avantage d’implémenter un protocole applicatif (REST) en même temps qu’un protocole de transport de haut niveau (TCP/IP) permettant de passer les pare-feu. Cependant, la version actuel d’HTTP ne répond pas vraiment aux critères énoncés précédemment. Depuis quelques années émerge donc l’idée d’enrichir HTTP pour créer un protocole hybride qui mêlerait les avantages de REST avec ceux proposés par les mécanismes de type Publish/Subscribe (MQTT, AMQP, JMS, etc.). En attendant cette éventuelle évolution, peut-on envisager de mettre en place un mécanisme de type Pub/Sub avec le protocole Websocket au-dessus d’HTTP ?

== Représentation ==

=== Propriétés ===

Un labyrinthe est une grille de cellules reliées, ou non, entre elles.

Deux cellules sont reliées entre elles par une '''porte''', ou séparées par un '''mur'''.

Tout labyrinthe a '''une entrée''' et '''une sortie''', et quelle que soit l'entrée ou la sortie, le chemin entre ces deux cellules est '''unique'''.

=== Modélisation en graphe ===

En théorie des graphes, un graphe est un ensemble de '''points''' (ou nœuds ou sommets) reliés ensemble par des '''lignes''' (ou liens ou arêtes).

[[Fichier:graphe_cyclique.png|vignette|left|300px|Exemple de graphe connexe cyclique non orienté|alt=Graphe cyclique]]

Un graphe peut être '''connexe''' (en un seul morceau) ou '''non connexe''' (en plusieurs morceaux).

Un graphe peut aussi être '''cyclique''' si les points sont reliés en formant une boucle ou '''acyclique'''.

Enfin, un graphe peut être '''orienté''' (si les arêtes sont à sens unique) ou '''non orienté'''.

[[Fichier:Arbre.PNG|vignette|left|300px|Exemple d'arbre|alt=Arbre]]

Un '''arbre''' est un graphe connexe, acyclique et non orienté.

En plaçant un point sur chaque cellule de notre labyrinthe, et en reliant deux cellules séparées par une porte, on peut dessiner un arbre à partir de n'importe quel labyrinthe.

[[Fichier:labyrinthe_avec_arbre.png|vignette|centre|300px|Exemple de labyrinthe avec son arbre. Pour plus de simplicité, on attribue à chaque nœud une position.|alt=Labyrinthe avec arbre]]

== Génération ==

Un labyrinthe rectangulaire de largeur <math> L </math> et de hauteur <math> H </math> contient exactement <math>L \times H - 1</math> portes.

Du point de vue du graphe, il y a donc <math>L \times H - 1</math> arêtes.

Maintenant, comment répartir toutes ces portes de façon à ce que toutes les cellules soient accessibles et qu'il n'existe qu'un unique chemin entre l'entrée et la sortie ?

De nombreux algorithmes existent, dont le parcours en profondeur et l'algorithme de Kruskal.
Chaque algorithme est différent et produit des labyrinthes visuellement différents.

En effet, si nous comparons un labyrinthe généré avec l'algorithme du parcours en profondeur à un labyrinthe généré avec l'algorithme de Kruskal, bien qu'ils aient tous les deux une solution unique, ils apparaissent néanmoins différents visuellement.

[[Fichier:recursive_backtracker_comparaison.png|vignette|left|500px|Parcours en profondeur. On remarque des chemins proprement dessinés.|alt=Parcours en profondeur]]
[[Fichier:kruskal_comparaison.png|vignette|right|500px|Algorithme de Kruskal. On remarque des murs de 1 de longueur çà et là.|alt=Kruskal]]

=== Parcours en profondeur ===

[[Fichier:recursive_backtracker.gif|vignette|left|500px|Illustration du parcours en profondeur|alt=Parcours en profondeur]]

Dans l'algorithme du parcours en profondeur ("recursive backtracker" en anglais), on commence sur une cellule aléatoire dans le labyrinthe.

On se dirige dans une direction aléatoire et on casse le mur en face, tout en marquant la cellule précédente comme visitée.

Lorsque aucune direction n'est disponible, on remonte à la position précédente.

[[Fichier:pile.png|vignette|300px|Représentation d'une pile de positions|alt=Pile]]

Pour sauvegarder l'historique des positions, on peut utiliser une '''pile'''.

Une pile est une liste dans laquelle seul le dernier élément peut être récupéré.

Une pile contient 2 méthodes :
* push(elem) : ajoute elem à la pile
* pop() -> elem : retourne le dernier élément de la pile (elem dans notre cas)

Dans mon implémentation de la pile, une erreur est levée si l'on appelle la méthode pop sur une pile vide.

=== Kruskal ===

[[Fichier:kruskal.gif|vignette|left|500px|Illustration de l'algorithme de Kruskal.|alt=Kruskal]]

Alors que pour le parcours en profondeur on partait des cellules, l'algorithme de Kruskal s'applique sur des murs.

On attribue à chaque cellule un identifiant unique.

On choisit un mur aléatoire. Si les cellules séparées par ce mur ont des identifiants différents, on leur associe le même identifiant et on casse le mur.

Sinon, on passe à un autre mur.

[[Fichier:union_find.png|vignette|300px|Représentation d'une structure Union-Find avec find(a,b) et find(b,c).|alt=Union-Find]]

Pour mettre en œuvre cet algorithme, on utilise une structure de données appelée '''Union-Find''', qui permet de mettre en relation des éléments partageant un même représentant (ou un même identifiant).

Il existe plusieurs variantes d'Union-Find, dont notamment la compression de chemin, qui permet de n'avoir qu'un ou deux éléments à parcourir pour obtenir le représentant d'un élément.

Union-Find fonctionne comme un arbre. <math>a</math> a un représentant <math>A</math>, etc..., qui lui même a un représentant <math>\alpha</math>, qui est son propre représentant.

Union-Find est composé de deux méthodes :
* union(a, b) : associe à <math>a</math> et <math>b</math> le même représentant, par exemple <math>A</math> le représentant de <math>a</math>
* find(a) -> <math>\alpha</math> : tant que l'élément n'est pas son propre représentant, on applique find au représentant de l'élément. On commence donc par find(a), puis find(A) (si <math>A</math> est le représentant de <math>a</math>), etc... La méthode de la compression de chemin permet d'éviter trop de récursivité en écrivant : représentant de <math>a</math> := <math>\alpha</math>

=== Labyrinthes cycliques ===

Il est possible, en retirant un certain pourcentage de murs, de créer des labyrinthes cycliques à partir des labyrinthes acycliques générés auparavant.

Cependant, certains algorithmes de résolution n'adopteront pas le même comportement.

== Résolution ==

Il existe là encore de nombreux algorithmes de résolution de labyrinthes, plus ou moins efficaces, et surtout ne fonctionnant pas tous dans les mêmes conditions.

=== Parcours en profondeur ===

Cet algorithme est quasiment identique à celui du parcours en profondeur pour la génération.

Il est très efficace et trouvera une solution en minimisant le nombre de cases visitées.

Il s'adapte aux labyrinthes cycliques. En cas de boucle, il ne fera pas la boucle vu que l'intersection a déjà été visitées, il reviendra sur ses pas.

Il s'adapte aux labyrinthes sans solution. En effet, s'il n'y a pas de sortie, il va revenir à sa position de départ sans position précédente (pile vide) et en ayant parcouru toutes les cases.

=== Mur droit ===

Cet algorithme va suivre de la main droite le mur de droite.

Il est relativement inefficace, et va visiter un grand nombre de cases.

Il s'adapte assez mal aux labyrinthes cycliques. En effet, si la sortie n'est pas dans la même boucle que l'entrée, il ne la trouvera jamais.

Il ne s'adapte pas aux labyrinthes sans solution, et fera le tour de la grille à l'infini.

[[Fichier:labyrinthe_exp_exhaust.png|vignette|left|500px|Labyrinthe résolu en utilisant le parcours en profondeur. 660 cellules visitées, 1179 déplacements, chemin de 142 cellules.|alt=Parcours en profondeur]]
[[Fichier:labyrinthe_right_hand.png|vignette|right|500px|Labyrinthe résolu en utilisant le mur droit. 1068 cellules visitées, 1995 déplacements, chemin de 142 cellules.|alt=Mur droit]]

== Code source ==

Mon projet total contenant plusieurs milliers de lignes de code réparties dans une dizaine de fichiers, je ne peux évidemment pas l'insérer directement dans cette page.

Le code source est disponible sur Github à [https://github.com/Rominos111/Labyrinthe_VISI201 cette adresse]

Il suffit d'avoir installé Python 3 et tkinter.

== Sources ==

Génération
<ul>
<li> [https://fr.wikipedia.org/wiki/Mod%C3%A9lisation_math%C3%A9matique_de_labyrinthe#Fusion_al%C3%A9atoire_de_chemins Kruskal (fr)] </li>
<li> [https://en.wikipedia.org/wiki/Maze_generation_algorithm#Randomized_Kruskal's_algorithm Kruskal (en)] </li>
<li> [https://fr.wikipedia.org/wiki/Mod%C3%A9lisation_math%C3%A9matique_de_labyrinthe#Exploration_exhaustive Parcours en profondeur (fr)] </li>
<li> [https://en.wikipedia.org/wiki/Maze_generation_algorithm#Randomized_Depth-First_Search Parcours en profondeur (en)] </li>
</ul>

Résolution
<ul>
<li> [https://fr.wikipedia.org/wiki/Mod%C3%A9lisation_math%C3%A9matique_de_labyrinthe#R%C3%A9solution Résolution générale (fr)] </li>
<li> [https://en.wikipedia.org/wiki/Maze_solving_algorithm#Wall_follower Mur droit (en)] </li>
</ul>

Structures de données
<ul>
<li> [https://fr.wikipedia.org/wiki/Union-find Union-Find / Disjoint-Set (fr)] </li>
<li> [https://en.wikipedia.org/wiki/Stack_(abstract_data_type) Pile / Stack (en)] </li>
<li> [https://en.wikipedia.org/wiki/Queue_(abstract_data_type) File / Queue (en)] </li>
</ul>

Python
<ul>
<li> [https://docs.python.org/3.6/reference/datamodel.html Classes et types de variables personnalisés (en)] </li>
<li> [http://effbot.org/tkinterbook/canvas.htm Canvas Tkinter (en)] </li>
</ul>

Rest & Pub-Sub : protocole hybride pour l'IoT

2019-05-19T23:45:12Z

Rakotoanosy :

== MQTT ==
MQTT, Message Queuing Telemetry Transport, est un protocole publish/subscribe se basant sur le protocole TCP/IP.
Il a été créé par Andy Stanford-Clark et Arlen Nipper.

De façon concrète, MQTT permet à des appareils de publier des informations sur un sujet donné sur un broker (un serveur qui fonctionne comme un coursier) qui va les retransmettre aux appareils abonnés à ce sujet.

[[Fichier:Fonctionnement broker mqtt.png|600px|thumb|left|illustration d'un échange entre un client 1 "subscriber" et un client 2 "publisher"]]

MQTT gère aussi la qualité de service (d'une qualité 0 à une qualité 2):

Qualité 0: le client qui publie une donnée ne reçoit aucune information par rapport à la confirmation de son arrivé.

Qualité 1: le client qui publie reçoit la confirmation ou non que la donnée publier à été reçu par le broker.

Qualité 2: le client qui publie reçoit la confirmation ou non que la donnée publier à été reçu par le broker ainsi qu'un message lui indiquant que le client qui s'abonne à reçu la donnée.
===Mosquitto===
Mosquitto est un broker open-source qui se sert du protocole MQTT. Il permet une fois installé de se familiarisé avec MQTT et le "publish/subscribe".

Nous nous en somme servit ici sur une MachineVirtuel en publiant en localhost:

[[Fichier:Mosquitto exemple.png]]

Sur un premier terminal on s'abonne à un topic "température" et sur un deuxième terminal, on publie ensuite sur ce même topic des nombres (qui s'apparentent à des température). Au fur et à mesure que nous publions ces informations, nous les recevons sur le premier terminal.
Mosquitto remplit bien ici son rôle de broker.

===Pub/Sub avec Python===

Nous avons ensuite développer un client ''publisher'' et un client ''subscriber'' en python grâce à la librairie paho-mqtt.
Pour plus de simplicité et éviter des problèmes de timing, nous avons tout regrouper en un seul programme:

import paho.mqtt.client as mqtt
import time

broker="test.mosquitto.org"

def envoi_message(client, QoS, message):
print("message reçu :", str(message.payload.decode("utf-8")))

client= mqtt.Client("client_test")
client.on_message=envoi_message

client.connect(broker)
print("connection")
client.loop_start()
client.subscribe("Cafetière/temperature_cafe")
print("Abonnement...")
time.sleep(1)
pub= input("entrez une température (un nombre):")
print("Publication...")
time.sleep(1)
client.publish("Cafetière/temperature_cafe",pub +"°C")
time.sleep(1)
client.disconnect()
print("deconnection")
client.loop_stop()
Comme broker, nous nous somme servit ici d'un broker mit en libre service par mosquitto.

==REST==
REST (Representational State Transfer) aussi appeler restful est une architecture logiciel inventer par Roy Fielding qui se sert des verbes HTTP comme identifiant des opérations et des réponses HTTP comme représentation des ressources.

Une architecture REST est définit par 5 règles/contraintes :

- '''Client–serveur'''

- '''Sans état'''

- '''Avec mise en cache'''

- '''En couches'''

- '''Interface uniforme :'''

L'interface uniforme est la contraintes fondamentale d'une architecture REST car c'est celle-ci qui permet à chaque composant d'évoluer indépendamment. Elle est définit par 4 contraintes :
<ul>
<li>Identification des ressources dans les requêtes</li>
<li>Manipulation des ressources par des représentations</li>
<li>Messages auto-descriptifs</li>
<li>Hypermédia comme moteur d'état de l'application</li>
</ul>

===Service pub/sub avec REST===
On peut réaliser un équivalent de service pub/sub avec REST à l'aide de GET et de POST qui agissent sur une base de données géré par un serveur:

[[Fichier:PubSub avec REST.png]]

Cette méthode comprend cependant de nombreux problèmes, notamment le fait que le client 1 ne sais pas si le client 2 à poster une donnée sur le serveur. On ne peut pas vraiment parler ici de service publish/subscribe car il n'y a pas d'abonnement, le client qui devrait s'abonner doit aller récupérer lui-même la donnée sans savoir si elle est bien dans la base de données du serveur.

==Protocole Hybride==

La technologie Pub/Sub et la technologie REST ont toutes deux leurs avantages et leurs inconvénients:

'''Avantages Pub/Sub :'''
<ul>
<li>Transfère rapide des informations</li>
<li>stockage des messages automatiques</li>
<li>gestion de la qualité de service</li>
</ul>
'''Inconvénient Pub/Sub :'''
<ul>
<li>On ne peut pas faire d’action direct sur le message, on ne fait un traitement dessus que lorsqu'on l'a reçu.</li>
<li>protocole mqtt,qui est bloquer par certain par feu</li>
</ul>
'''Avantages REST :'''
<ul>
<li>protocole http(port 80) passe partout dans le monde</li>
<li>on peut traiter le message directement sur le serveur</li>
</ul>
'''Inconvénient REST :'''
<ul>
<li>On doit installer un serveur web, on doit géré une base de donnée (ou XML, Json).</li>
</ul>

L'objectif du protocole hybride est de réaliser un système pub/sub tel que l'on ai:
<ul>
<li>un transfère rapide des informations</li>
<li>un stockage des messages automatiques</li>
<li>une gestion de la qualité de service</li>
<li>le protocole http (port 80) de sorte à ce qu'il fonctionne partout dans le monde.</li>
</ul>

Pour cela, nous allons nous servir des Websockets.

===MQTT sur Websocket===

Le protocole Websocket est un protocole qui vise à développer un canal de communication web sur une connexion TCP.

Les objectifs de ce protocole étaient notamment de permettre au serveur l'envoi de données vers le client en mode push (sans que l'utilisateur n'ai à faire une requête).

Pour notre protocole hybride, l'idée serai d'ouvrir un canal de communication Websocket entre le broker et le client.

Lorsque l'on envoie le message mqtt au broker, on le place dans un paquet websocket puis on l'envoi au broker. Lorsque le serveur reçoit le paquet, il l'ouvre et traite le message Mqtt contenu comme il l'aurai fait avec un message mqtt "normal". On fait de même lorsque le broker envoie un message au client qui c'est abonner.

On peut l'illustrer de la façon suivante :

[[Fichier:MQTT sur Websocket.png|500px]]

Ainsi puisque le protocole Websocket se sert du port 80, on conserve les avantages de la technologie pub/sub avec Mqtt tout en évitant le problème des par-feu que l'on pouvait rencontrer avec le protocole Mqtt.

==Sources==

[https://fr.wikipedia.org/wiki/Publish-subscribe Pub/Sub]

[https://fr.wikipedia.org/wiki/MQTT MQTT]

[https://pypi.org/project/paho-mqtt/ paho-mqtt]

[https://fr.wikipedia.org/wiki/Representational_state_transfer REST]

[https://fr.wikipedia.org/wiki/WebSocket Websocket]

Rest & Pub-Sub : protocole hybride pour l'IoT

2019-05-19T23:43:34Z

Rakotoanosy : /* MQTT sur Websocket */

== Introduction ==

== MQTT ==
MQTT, Message Queuing Telemetry Transport, est un protocole publish/subscribe se basant sur le protocole TCP/IP.
Il a été créé par Andy Stanford-Clark et Arlen Nipper.

De façon concrète, MQTT permet à des appareils de publier des informations sur un sujet donné sur un broker (un serveur qui fonctionne comme un coursier) qui va les retransmettre aux appareils abonnés à ce sujet.

[[Fichier:Fonctionnement broker mqtt.png|600px|thumb|left|illustration d'un échange entre un client 1 "subscriber" et un client 2 "publisher"]]

MQTT gère aussi la qualité de service (d'une qualité 0 à une qualité 2):

Qualité 0: le client qui publie une donnée ne reçoit aucune information par rapport à la confirmation de son arrivé.

Qualité 1: le client qui publie reçoit la confirmation ou non que la donnée publier à été reçu par le broker.

Qualité 2: le client qui publie reçoit la confirmation ou non que la donnée publier à été reçu par le broker ainsi qu'un message lui indiquant que le client qui s'abonne à reçu la donnée.
===Mosquitto===
Mosquitto est un broker open-source qui se sert du protocole MQTT. Il permet une fois installé de se familiarisé avec MQTT et le "publish/subscribe".

Nous nous en somme servit ici sur une MachineVirtuel en publiant en localhost:

[[Fichier:Mosquitto exemple.png]]

Sur un premier terminal on s'abonne à un topic "température" et sur un deuxième terminal, on publie ensuite sur ce même topic des nombres (qui s'apparentent à des température). Au fur et à mesure que nous publions ces informations, nous les recevons sur le premier terminal.
Mosquitto remplit bien ici son rôle de broker.

===Pub/Sub avec Python===

Nous avons ensuite développer un client ''publisher'' et un client ''subscriber'' en python grâce à la librairie paho-mqtt.
Pour plus de simplicité et éviter des problèmes de timing, nous avons tout regrouper en un seul programme:

import paho.mqtt.client as mqtt
import time

broker="test.mosquitto.org"

def envoi_message(client, QoS, message):
print("message reçu :", str(message.payload.decode("utf-8")))

client= mqtt.Client("client_test")
client.on_message=envoi_message

client.connect(broker)
print("connection")
client.loop_start()
client.subscribe("Cafetière/temperature_cafe")
print("Abonnement...")
time.sleep(1)
pub= input("entrez une température (un nombre):")
print("Publication...")
time.sleep(1)
client.publish("Cafetière/temperature_cafe",pub +"°C")
time.sleep(1)
client.disconnect()
print("deconnection")
client.loop_stop()
Comme broker, nous nous somme servit ici d'un broker mit en libre service par mosquitto.

==REST==
REST (Representational State Transfer) aussi appeler restful est une architecture logiciel inventer par Roy Fielding qui se sert des verbes HTTP comme identifiant des opérations et des réponses HTTP comme représentation des ressources.

Une architecture REST est définit par 5 règles/contraintes :

- '''Client–serveur'''

- '''Sans état'''

- '''Avec mise en cache'''

- '''En couches'''

- '''Interface uniforme :'''

L'interface uniforme est la contraintes fondamentale d'une architecture REST car c'est celle-ci qui permet à chaque composant d'évoluer indépendamment. Elle est définit par 4 contraintes :
<ul>
<li>Identification des ressources dans les requêtes</li>
<li>Manipulation des ressources par des représentations</li>
<li>Messages auto-descriptifs</li>
<li>Hypermédia comme moteur d'état de l'application</li>
</ul>

===Service pub/sub avec REST===
On peut réaliser un équivalent de service pub/sub avec REST à l'aide de GET et de POST qui agissent sur une base de données géré par un serveur:

[[Fichier:PubSub avec REST.png]]

Cette méthode comprend cependant de nombreux problèmes, notamment le fait que le client 1 ne sais pas si le client 2 à poster une donnée sur le serveur. On ne peut pas vraiment parler ici de service publish/subscribe car il n'y a pas d'abonnement, le client qui devrait s'abonner doit aller récupérer lui-même la donnée sans savoir si elle est bien dans la base de données du serveur.

==Protocole Hybride==

La technologie Pub/Sub et la technologie REST ont toutes deux leurs avantages et leurs inconvénients:

'''Avantages Pub/Sub :'''
<ul>
<li>Transfère rapide des informations</li>
<li>stockage des messages automatiques</li>
<li>gestion de la qualité de service</li>
</ul>
'''Inconvénient Pub/Sub :'''
<ul>
<li>On ne peut pas faire d’action direct sur le message, on ne fait un traitement dessus que lorsqu'on l'a reçu.</li>
<li>protocole mqtt,qui est bloquer par certain par feu</li>
</ul>
'''Avantages REST :'''
<ul>
<li>protocole http(port 80) passe partout dans le monde</li>
<li>on peut traiter le message directement sur le serveur</li>
</ul>
'''Inconvénient REST :'''
<ul>
<li>On doit installer un serveur web, on doit géré une base de donnée (ou XML, Json).</li>
</ul>

L'objectif du protocole hybride est de réaliser un système pub/sub tel que l'on ai:
<ul>
<li>un transfère rapide des informations</li>
<li>un stockage des messages automatiques</li>
<li>une gestion de la qualité de service</li>
<li>le protocole http (port 80) de sorte à ce qu'il fonctionne partout dans le monde.</li>
</ul>

Pour cela, nous allons nous servir des Websockets.

===MQTT sur Websocket===

Le protocole Websocket est un protocole qui vise à développer un canal de communication web sur une connexion TCP.

Les objectifs de ce protocole étaient notamment de permettre au serveur l'envoi de données vers le client en mode push (sans que l'utilisateur n'ai à faire une requête).

Pour notre protocole hybride, l'idée serai d'ouvrir un canal de communication Websocket entre le broker et le client.

Lorsque l'on envoie le message mqtt au broker, on le place dans un paquet websocket puis on l'envoi au broker. Lorsque le serveur reçoit le paquet, il l'ouvre et traite le message Mqtt contenu comme il l'aurai fait avec un message mqtt "normal". On fait de même lorsque le broker envoie un message au client qui c'est abonner.

On peut l'illustrer de la façon suivante :

[[Fichier:MQTT sur Websocket.png|500px]]

Ainsi puisque le protocole Websocket se sert du port 80, on conserve les avantages de la technologie pub/sub avec Mqtt tout en évitant le problème des par-feu que l'on pouvait rencontrer avec le protocole Mqtt.

==Sources==

[https://fr.wikipedia.org/wiki/Publish-subscribe Pub/Sub]

[https://fr.wikipedia.org/wiki/MQTT MQTT]

[https://pypi.org/project/paho-mqtt/ paho-mqtt]

[https://fr.wikipedia.org/wiki/Representational_state_transfer REST]

[https://fr.wikipedia.org/wiki/WebSocket Websocket]

Rest & Pub-Sub : protocole hybride pour l'IoT

2019-05-19T23:43:20Z

Rakotoanosy : /* MQTT sur Websocket */

== Introduction ==

== MQTT ==
MQTT, Message Queuing Telemetry Transport, est un protocole publish/subscribe se basant sur le protocole TCP/IP.
Il a été créé par Andy Stanford-Clark et Arlen Nipper.

De façon concrète, MQTT permet à des appareils de publier des informations sur un sujet donné sur un broker (un serveur qui fonctionne comme un coursier) qui va les retransmettre aux appareils abonnés à ce sujet.

[[Fichier:Fonctionnement broker mqtt.png|600px|thumb|left|illustration d'un échange entre un client 1 "subscriber" et un client 2 "publisher"]]

MQTT gère aussi la qualité de service (d'une qualité 0 à une qualité 2):

Qualité 0: le client qui publie une donnée ne reçoit aucune information par rapport à la confirmation de son arrivé.

Qualité 1: le client qui publie reçoit la confirmation ou non que la donnée publier à été reçu par le broker.

Qualité 2: le client qui publie reçoit la confirmation ou non que la donnée publier à été reçu par le broker ainsi qu'un message lui indiquant que le client qui s'abonne à reçu la donnée.
===Mosquitto===
Mosquitto est un broker open-source qui se sert du protocole MQTT. Il permet une fois installé de se familiarisé avec MQTT et le "publish/subscribe".

Nous nous en somme servit ici sur une MachineVirtuel en publiant en localhost:

[[Fichier:Mosquitto exemple.png]]

Sur un premier terminal on s'abonne à un topic "température" et sur un deuxième terminal, on publie ensuite sur ce même topic des nombres (qui s'apparentent à des température). Au fur et à mesure que nous publions ces informations, nous les recevons sur le premier terminal.
Mosquitto remplit bien ici son rôle de broker.

===Pub/Sub avec Python===

Nous avons ensuite développer un client ''publisher'' et un client ''subscriber'' en python grâce à la librairie paho-mqtt.
Pour plus de simplicité et éviter des problèmes de timing, nous avons tout regrouper en un seul programme:

import paho.mqtt.client as mqtt
import time

broker="test.mosquitto.org"

def envoi_message(client, QoS, message):
print("message reçu :", str(message.payload.decode("utf-8")))

client= mqtt.Client("client_test")
client.on_message=envoi_message

client.connect(broker)
print("connection")
client.loop_start()
client.subscribe("Cafetière/temperature_cafe")
print("Abonnement...")
time.sleep(1)
pub= input("entrez une température (un nombre):")
print("Publication...")
time.sleep(1)
client.publish("Cafetière/temperature_cafe",pub +"°C")
time.sleep(1)
client.disconnect()
print("deconnection")
client.loop_stop()
Comme broker, nous nous somme servit ici d'un broker mit en libre service par mosquitto.

==REST==
REST (Representational State Transfer) aussi appeler restful est une architecture logiciel inventer par Roy Fielding qui se sert des verbes HTTP comme identifiant des opérations et des réponses HTTP comme représentation des ressources.

Une architecture REST est définit par 5 règles/contraintes :

- '''Client–serveur'''

- '''Sans état'''

- '''Avec mise en cache'''

- '''En couches'''

- '''Interface uniforme :'''

L'interface uniforme est la contraintes fondamentale d'une architecture REST car c'est celle-ci qui permet à chaque composant d'évoluer indépendamment. Elle est définit par 4 contraintes :
<ul>
<li>Identification des ressources dans les requêtes</li>
<li>Manipulation des ressources par des représentations</li>
<li>Messages auto-descriptifs</li>
<li>Hypermédia comme moteur d'état de l'application</li>
</ul>

===Service pub/sub avec REST===
On peut réaliser un équivalent de service pub/sub avec REST à l'aide de GET et de POST qui agissent sur une base de données géré par un serveur:

[[Fichier:PubSub avec REST.png]]

Cette méthode comprend cependant de nombreux problèmes, notamment le fait que le client 1 ne sais pas si le client 2 à poster une donnée sur le serveur. On ne peut pas vraiment parler ici de service publish/subscribe car il n'y a pas d'abonnement, le client qui devrait s'abonner doit aller récupérer lui-même la donnée sans savoir si elle est bien dans la base de données du serveur.

==Protocole Hybride==

La technologie Pub/Sub et la technologie REST ont toutes deux leurs avantages et leurs inconvénients:

'''Avantages Pub/Sub :'''
<ul>
<li>Transfère rapide des informations</li>
<li>stockage des messages automatiques</li>
<li>gestion de la qualité de service</li>
</ul>
'''Inconvénient Pub/Sub :'''
<ul>
<li>On ne peut pas faire d’action direct sur le message, on ne fait un traitement dessus que lorsqu'on l'a reçu.</li>
<li>protocole mqtt,qui est bloquer par certain par feu</li>
</ul>
'''Avantages REST :'''
<ul>
<li>protocole http(port 80) passe partout dans le monde</li>
<li>on peut traiter le message directement sur le serveur</li>
</ul>
'''Inconvénient REST :'''
<ul>
<li>On doit installer un serveur web, on doit géré une base de donnée (ou XML, Json).</li>
</ul>

L'objectif du protocole hybride est de réaliser un système pub/sub tel que l'on ai:
<ul>
<li>un transfère rapide des informations</li>
<li>un stockage des messages automatiques</li>
<li>une gestion de la qualité de service</li>
<li>le protocole http (port 80) de sorte à ce qu'il fonctionne partout dans le monde.</li>
</ul>

Pour cela, nous allons nous servir des Websockets.

===MQTT sur Websocket===

Le protocole Websocket est un protocole qui vise à développer un canal de communication web sur une connexion TCP.

Les objectifs de ce protocole étaient notamment de permettre au serveur l'envoi de données vers le client en mode push (sans que l'utilisateur n'ai à faire une requête).

Pour notre protocole hybride, l'idée serai d'ouvrir un canal de communication Websocket entre le broker et le client.

Lorsque l'on envoie le message mqtt au broker, on le place dans un paquet websocket puis on l'envoi au broker. Lorsque le serveur reçoit le paquet, il l'ouvre et traite le message Mqtt contenu comme il l'aurai fait avec un message mqtt "normal". On fait de même lorsque le broker envoie un message au client qui c'est abonner.

On peut l'illustrer de la façon suivante :

[[Fichier:MQTT sur Websocket.png|500px]]

Ainsi puisque le protocole Websocket se sert du port 80, on conserve les avantages de la technologie pub/sub avec Mqtt tout en évitant le problème des par-feu que l'on pouvait rencontrer avec Mqtt.

==Sources==

[https://fr.wikipedia.org/wiki/Publish-subscribe Pub/Sub]

[https://fr.wikipedia.org/wiki/MQTT MQTT]

[https://pypi.org/project/paho-mqtt/ paho-mqtt]

[https://fr.wikipedia.org/wiki/Representational_state_transfer REST]

[https://fr.wikipedia.org/wiki/WebSocket Websocket]

Rest & Pub-Sub : protocole hybride pour l'IoT

2019-05-19T23:42:04Z

Rakotoanosy : /* Protocole Hybride */

== Introduction ==

== MQTT ==
MQTT, Message Queuing Telemetry Transport, est un protocole publish/subscribe se basant sur le protocole TCP/IP.
Il a été créé par Andy Stanford-Clark et Arlen Nipper.

De façon concrète, MQTT permet à des appareils de publier des informations sur un sujet donné sur un broker (un serveur qui fonctionne comme un coursier) qui va les retransmettre aux appareils abonnés à ce sujet.

[[Fichier:Fonctionnement broker mqtt.png|600px|thumb|left|illustration d'un échange entre un client 1 "subscriber" et un client 2 "publisher"]]

MQTT gère aussi la qualité de service (d'une qualité 0 à une qualité 2):

Qualité 0: le client qui publie une donnée ne reçoit aucune information par rapport à la confirmation de son arrivé.

Qualité 1: le client qui publie reçoit la confirmation ou non que la donnée publier à été reçu par le broker.

Qualité 2: le client qui publie reçoit la confirmation ou non que la donnée publier à été reçu par le broker ainsi qu'un message lui indiquant que le client qui s'abonne à reçu la donnée.
===Mosquitto===
Mosquitto est un broker open-source qui se sert du protocole MQTT. Il permet une fois installé de se familiarisé avec MQTT et le "publish/subscribe".

Nous nous en somme servit ici sur une MachineVirtuel en publiant en localhost:

[[Fichier:Mosquitto exemple.png]]

Sur un premier terminal on s'abonne à un topic "température" et sur un deuxième terminal, on publie ensuite sur ce même topic des nombres (qui s'apparentent à des température). Au fur et à mesure que nous publions ces informations, nous les recevons sur le premier terminal.
Mosquitto remplit bien ici son rôle de broker.

===Pub/Sub avec Python===

Nous avons ensuite développer un client ''publisher'' et un client ''subscriber'' en python grâce à la librairie paho-mqtt.
Pour plus de simplicité et éviter des problèmes de timing, nous avons tout regrouper en un seul programme:

import paho.mqtt.client as mqtt
import time

broker="test.mosquitto.org"

def envoi_message(client, QoS, message):
print("message reçu :", str(message.payload.decode("utf-8")))

client= mqtt.Client("client_test")
client.on_message=envoi_message

client.connect(broker)
print("connection")
client.loop_start()
client.subscribe("Cafetière/temperature_cafe")
print("Abonnement...")
time.sleep(1)
pub= input("entrez une température (un nombre):")
print("Publication...")
time.sleep(1)
client.publish("Cafetière/temperature_cafe",pub +"°C")
time.sleep(1)
client.disconnect()
print("deconnection")
client.loop_stop()
Comme broker, nous nous somme servit ici d'un broker mit en libre service par mosquitto.

==REST==
REST (Representational State Transfer) aussi appeler restful est une architecture logiciel inventer par Roy Fielding qui se sert des verbes HTTP comme identifiant des opérations et des réponses HTTP comme représentation des ressources.

Une architecture REST est définit par 5 règles/contraintes :

- '''Client–serveur'''

- '''Sans état'''

- '''Avec mise en cache'''

- '''En couches'''

- '''Interface uniforme :'''

L'interface uniforme est la contraintes fondamentale d'une architecture REST car c'est celle-ci qui permet à chaque composant d'évoluer indépendamment. Elle est définit par 4 contraintes :
<ul>
<li>Identification des ressources dans les requêtes</li>
<li>Manipulation des ressources par des représentations</li>
<li>Messages auto-descriptifs</li>
<li>Hypermédia comme moteur d'état de l'application</li>
</ul>

===Service pub/sub avec REST===
On peut réaliser un équivalent de service pub/sub avec REST à l'aide de GET et de POST qui agissent sur une base de données géré par un serveur:

[[Fichier:PubSub avec REST.png]]

Cette méthode comprend cependant de nombreux problèmes, notamment le fait que le client 1 ne sais pas si le client 2 à poster une donnée sur le serveur. On ne peut pas vraiment parler ici de service publish/subscribe car il n'y a pas d'abonnement, le client qui devrait s'abonner doit aller récupérer lui-même la donnée sans savoir si elle est bien dans la base de données du serveur.

==Protocole Hybride==

La technologie Pub/Sub et la technologie REST ont toutes deux leurs avantages et leurs inconvénients:

'''Avantages Pub/Sub :'''
<ul>
<li>Transfère rapide des informations</li>
<li>stockage des messages automatiques</li>
<li>gestion de la qualité de service</li>
</ul>
'''Inconvénient Pub/Sub :'''
<ul>
<li>On ne peut pas faire d’action direct sur le message, on ne fait un traitement dessus que lorsqu'on l'a reçu.</li>
<li>protocole mqtt,qui est bloquer par certain par feu</li>
</ul>
'''Avantages REST :'''
<ul>
<li>protocole http(port 80) passe partout dans le monde</li>
<li>on peut traiter le message directement sur le serveur</li>
</ul>
'''Inconvénient REST :'''
<ul>
<li>On doit installer un serveur web, on doit géré une base de donnée (ou XML, Json).</li>
</ul>

L'objectif du protocole hybride est de réaliser un système pub/sub tel que l'on ai:
<ul>
<li>un transfère rapide des informations</li>
<li>un stockage des messages automatiques</li>
<li>une gestion de la qualité de service</li>
<li>le protocole http (port 80) de sorte à ce qu'il fonctionne partout dans le monde.</li>
</ul>

Pour cela, nous allons nous servir des Websockets.

===MQTT sur Websocket===

Le protocole Websocket est un protocole qui vise à développer un canal de communication web sur une connexion TCP.

Les objectifs de ce protocole étaient notamment de permettre au serveur l'envoi de données vers le client en mode push (sans que l'utilisateur n'ai à faire une requête).

Pour notre protocole hybride, l'idée serai d'ouvrir un canal de communication Websocket entre le broker et le client.

Lorsque l'on envoie le message mqtt au broker, on le place dans un paquet websocket puis on l'envoi au broker. Lorsque le serveur reçoit le paquet, il l'ouvre et traite le message Mqtt contenu comme il l'aurai fait avec un message mqtt "normal". On fait de même lorsque le broker envoie un message au client qui c'est abonner.

On peut l'illustrer de la façon suivante :

[[Fichier:MQTT sur Websocket.png|500px]]

Ainsi puisque le protocole Websocket se sert du port 80, l'on conserve les avantages de la technologie pub/sub avec Mqtt et notre protocole fonctionne partout dans le monde.

==Sources==

[https://fr.wikipedia.org/wiki/Publish-subscribe Pub/Sub]

[https://fr.wikipedia.org/wiki/MQTT MQTT]

[https://pypi.org/project/paho-mqtt/ paho-mqtt]

[https://fr.wikipedia.org/wiki/Representational_state_transfer REST]

[https://fr.wikipedia.org/wiki/WebSocket Websocket]

Rest & Pub-Sub : protocole hybride pour l'IoT

2019-05-19T23:39:59Z

Rakotoanosy : /* MQTT sur Websocket */

== Introduction ==

== MQTT ==
MQTT, Message Queuing Telemetry Transport, est un protocole publish/subscribe se basant sur le protocole TCP/IP.
Il a été créé par Andy Stanford-Clark et Arlen Nipper.

De façon concrète, MQTT permet à des appareils de publier des informations sur un sujet donné sur un broker (un serveur qui fonctionne comme un coursier) qui va les retransmettre aux appareils abonnés à ce sujet.

[[Fichier:Fonctionnement broker mqtt.png|600px|thumb|left|illustration d'un échange entre un client 1 "subscriber" et un client 2 "publisher"]]

MQTT gère aussi la qualité de service (d'une qualité 0 à une qualité 2):

Qualité 0: le client qui publie une donnée ne reçoit aucune information par rapport à la confirmation de son arrivé.

Qualité 1: le client qui publie reçoit la confirmation ou non que la donnée publier à été reçu par le broker.

Qualité 2: le client qui publie reçoit la confirmation ou non que la donnée publier à été reçu par le broker ainsi qu'un message lui indiquant que le client qui s'abonne à reçu la donnée.
===Mosquitto===
Mosquitto est un broker open-source qui se sert du protocole MQTT. Il permet une fois installé de se familiarisé avec MQTT et le "publish/subscribe".

Nous nous en somme servit ici sur une MachineVirtuel en publiant en localhost:

[[Fichier:Mosquitto exemple.png]]

Sur un premier terminal on s'abonne à un topic "température" et sur un deuxième terminal, on publie ensuite sur ce même topic des nombres (qui s'apparentent à des température). Au fur et à mesure que nous publions ces informations, nous les recevons sur le premier terminal.
Mosquitto remplit bien ici son rôle de broker.

===Pub/Sub avec Python===

Nous avons ensuite développer un client ''publisher'' et un client ''subscriber'' en python grâce à la librairie paho-mqtt.
Pour plus de simplicité et éviter des problèmes de timing, nous avons tout regrouper en un seul programme:

import paho.mqtt.client as mqtt
import time

broker="test.mosquitto.org"

def envoi_message(client, QoS, message):
print("message reçu :", str(message.payload.decode("utf-8")))

client= mqtt.Client("client_test")
client.on_message=envoi_message

client.connect(broker)
print("connection")
client.loop_start()
client.subscribe("Cafetière/temperature_cafe")
print("Abonnement...")
time.sleep(1)
pub= input("entrez une température (un nombre):")
print("Publication...")
time.sleep(1)
client.publish("Cafetière/temperature_cafe",pub +"°C")
time.sleep(1)
client.disconnect()
print("deconnection")
client.loop_stop()
Comme broker, nous nous somme servit ici d'un broker mit en libre service par mosquitto.

==REST==
REST (Representational State Transfer) aussi appeler restful est une architecture logiciel inventer par Roy Fielding qui se sert des verbes HTTP comme identifiant des opérations et des réponses HTTP comme représentation des ressources.

Une architecture REST est définit par 5 règles/contraintes :

- '''Client–serveur'''

- '''Sans état'''

- '''Avec mise en cache'''

- '''En couches'''

- '''Interface uniforme :'''

L'interface uniforme est la contraintes fondamentale d'une architecture REST car c'est celle-ci qui permet à chaque composant d'évoluer indépendamment. Elle est définit par 4 contraintes :
<ul>
<li>Identification des ressources dans les requêtes</li>
<li>Manipulation des ressources par des représentations</li>
<li>Messages auto-descriptifs</li>
<li>Hypermédia comme moteur d'état de l'application</li>
</ul>

===Service pub/sub avec REST===
On peut réaliser un équivalent de service pub/sub avec REST à l'aide de GET et de POST qui agissent sur une base de données géré par un serveur:

[[Fichier:PubSub avec REST.png]]

Cette méthode comprend cependant de nombreux problèmes, notamment le fait que le client 1 ne sais pas si le client 2 à poster une donnée sur le serveur. On ne peut pas vraiment parler ici de service publish/subscribe car il n'y a pas d'abonnement, le client qui devrait s'abonner doit aller récupérer lui-même la donnée sans savoir si elle est bien dans la base de données du serveur.

==Protocole Hybride==

La technologie Pub/Sub et la technologie REST ont toutes deux leurs avantages et leurs inconvénients:

'''Avantages Pub/Sub :'''
<ul>
<li>Transfère rapide des informations</li>
<li>stockage des messages automatiques</li>
<li>gestion de la qualité de service</li>
</ul>
'''Inconvénient Pub/Sub :'''
<ul>
<li>On ne peut pas faire d’action direct sur le message, on ne fait un traitement dessus que lorsqu'on l'a reçu.</li>
<li>protocole mqtt,qui bloquer par certain par feu</li>
</ul>
'''Avantages REST :'''
<ul>
<li>protocole http(port 80) passe partout dans le monde</li>
<li>on peut traiter le message directement sur le serveur</li>
</ul>
'''Inconvénient REST :'''
<ul>
<li>On doit installer un serveur web, on doit géré une base de donnée (ou XML, Json).</li>
</ul>

L'objectif du protocole hybride est de réaliser un système pub/sub tel que l'on ai:
<ul>
<li>un transfère rapide des informations</li>
<li>un stockage des messages automatiques</li>
<li>une gestion de la qualité de service</li>
<li>le protocole http (port 80) de sorte à ce qu'il fonctionne partout dans le monde.</li>
</ul>

Pour cela, nous allons nous servir des Websockets.

===MQTT sur Websocket===

Le protocole Websocket est un protocole qui vise à développer un canal de communication web sur une connexion TCP.

Les objectifs de ce protocole étaient notamment de permettre au serveur l'envoi de données vers le client en mode push (sans que l'utilisateur n'ai à faire une requête).

Pour notre protocole hybride, l'idée serai d'ouvrir un canal de communication Websocket entre le broker et le client.

Lorsque l'on envoie le message mqtt au broker, on le place dans un paquet websocket puis on l'envoi au broker. Lorsque le serveur reçoit le paquet, il l'ouvre et traite le message Mqtt contenu comme il l'aurai fait avec un message mqtt "normal". On fait de même lorsque le broker envoie un message au client qui c'est abonner.

On peut l'illustrer de la façon suivante :

[[Fichier:MQTT sur Websocket.png|500px]]

Ainsi puisque le protocole Websocket se sert du port 80, l'on conserve les avantages de la technologie pub/sub avec Mqtt et notre protocole fonctionne partout dans le monde.

==Sources==

[https://fr.wikipedia.org/wiki/Publish-subscribe Pub/Sub]

[https://fr.wikipedia.org/wiki/MQTT MQTT]

[https://pypi.org/project/paho-mqtt/ paho-mqtt]

[https://fr.wikipedia.org/wiki/Representational_state_transfer REST]

[https://fr.wikipedia.org/wiki/WebSocket Websocket]

Rest & Pub-Sub : protocole hybride pour l'IoT

2019-05-19T23:39:34Z

Rakotoanosy : /* MQTT sur Websocket */

== Introduction ==

== MQTT ==
MQTT, Message Queuing Telemetry Transport, est un protocole publish/subscribe se basant sur le protocole TCP/IP.
Il a été créé par Andy Stanford-Clark et Arlen Nipper.

De façon concrète, MQTT permet à des appareils de publier des informations sur un sujet donné sur un broker (un serveur qui fonctionne comme un coursier) qui va les retransmettre aux appareils abonnés à ce sujet.

[[Fichier:Fonctionnement broker mqtt.png|600px|thumb|left|illustration d'un échange entre un client 1 "subscriber" et un client 2 "publisher"]]

MQTT gère aussi la qualité de service (d'une qualité 0 à une qualité 2):

Qualité 0: le client qui publie une donnée ne reçoit aucune information par rapport à la confirmation de son arrivé.

Qualité 1: le client qui publie reçoit la confirmation ou non que la donnée publier à été reçu par le broker.

Qualité 2: le client qui publie reçoit la confirmation ou non que la donnée publier à été reçu par le broker ainsi qu'un message lui indiquant que le client qui s'abonne à reçu la donnée.
===Mosquitto===
Mosquitto est un broker open-source qui se sert du protocole MQTT. Il permet une fois installé de se familiarisé avec MQTT et le "publish/subscribe".

Nous nous en somme servit ici sur une MachineVirtuel en publiant en localhost:

[[Fichier:Mosquitto exemple.png]]

Sur un premier terminal on s'abonne à un topic "température" et sur un deuxième terminal, on publie ensuite sur ce même topic des nombres (qui s'apparentent à des température). Au fur et à mesure que nous publions ces informations, nous les recevons sur le premier terminal.
Mosquitto remplit bien ici son rôle de broker.

===Pub/Sub avec Python===

Nous avons ensuite développer un client ''publisher'' et un client ''subscriber'' en python grâce à la librairie paho-mqtt.
Pour plus de simplicité et éviter des problèmes de timing, nous avons tout regrouper en un seul programme:

import paho.mqtt.client as mqtt
import time

broker="test.mosquitto.org"

def envoi_message(client, QoS, message):
print("message reçu :", str(message.payload.decode("utf-8")))

client= mqtt.Client("client_test")
client.on_message=envoi_message

client.connect(broker)
print("connection")
client.loop_start()
client.subscribe("Cafetière/temperature_cafe")
print("Abonnement...")
time.sleep(1)
pub= input("entrez une température (un nombre):")
print("Publication...")
time.sleep(1)
client.publish("Cafetière/temperature_cafe",pub +"°C")
time.sleep(1)
client.disconnect()
print("deconnection")
client.loop_stop()
Comme broker, nous nous somme servit ici d'un broker mit en libre service par mosquitto.

==REST==
REST (Representational State Transfer) aussi appeler restful est une architecture logiciel inventer par Roy Fielding qui se sert des verbes HTTP comme identifiant des opérations et des réponses HTTP comme représentation des ressources.

Une architecture REST est définit par 5 règles/contraintes :

- '''Client–serveur'''

- '''Sans état'''

- '''Avec mise en cache'''

- '''En couches'''

- '''Interface uniforme :'''

L'interface uniforme est la contraintes fondamentale d'une architecture REST car c'est celle-ci qui permet à chaque composant d'évoluer indépendamment. Elle est définit par 4 contraintes :
<ul>
<li>Identification des ressources dans les requêtes</li>
<li>Manipulation des ressources par des représentations</li>
<li>Messages auto-descriptifs</li>
<li>Hypermédia comme moteur d'état de l'application</li>
</ul>

===Service pub/sub avec REST===
On peut réaliser un équivalent de service pub/sub avec REST à l'aide de GET et de POST qui agissent sur une base de données géré par un serveur:

[[Fichier:PubSub avec REST.png]]

Cette méthode comprend cependant de nombreux problèmes, notamment le fait que le client 1 ne sais pas si le client 2 à poster une donnée sur le serveur. On ne peut pas vraiment parler ici de service publish/subscribe car il n'y a pas d'abonnement, le client qui devrait s'abonner doit aller récupérer lui-même la donnée sans savoir si elle est bien dans la base de données du serveur.

==Protocole Hybride==

La technologie Pub/Sub et la technologie REST ont toutes deux leurs avantages et leurs inconvénients:

'''Avantages Pub/Sub :'''
<ul>
<li>Transfère rapide des informations</li>
<li>stockage des messages automatiques</li>
<li>gestion de la qualité de service</li>
</ul>
'''Inconvénient Pub/Sub :'''
<ul>
<li>On ne peut pas faire d’action direct sur le message, on ne fait un traitement dessus que lorsqu'on l'a reçu.</li>
<li>protocole mqtt,qui bloquer par certain par feu</li>
</ul>
'''Avantages REST :'''
<ul>
<li>protocole http(port 80) passe partout dans le monde</li>
<li>on peut traiter le message directement sur le serveur</li>
</ul>
'''Inconvénient REST :'''
<ul>
<li>On doit installer un serveur web, on doit géré une base de donnée (ou XML, Json).</li>
</ul>

L'objectif du protocole hybride est de réaliser un système pub/sub tel que l'on ai:
<ul>
<li>un transfère rapide des informations</li>
<li>un stockage des messages automatiques</li>
<li>une gestion de la qualité de service</li>
<li>le protocole http (port 80) de sorte à ce qu'il fonctionne partout dans le monde.</li>
</ul>

Pour cela, nous allons nous servir des Websockets.

===MQTT sur Websocket===

Le protocole Websocket est un protocole qui vise à développer un canal de communication web sur une connexion TCP.

Les objectifs de ce protocole étaient notamment de permettre au serveur l'envoi de données vers le client en mode push (sans que l'utilisateur n'ai à faire une requête).

Pour notre protocole hybride, l'idée serai d'ouvrir un canal de communication Websocket entre le broker et le client.

Lorsque l'on envoie le message mqtt au broker, on le place dans un paquet websocket puis on l'envoi au broker. Lorsque le serveur reçoit le paquet, il l'ouvre et traite le message Mqtt contenu comme il l'aurai fait avec un message mqtt "normal". On fait de même lorsque le broker envoie un message au client qui c'est abonner.

On peut l'illustrer de la façon suivante :

[[Fichier:MQTT sur Websocket.png]]

Ainsi puisque le protocole Websocket se sert du port 80, l'on conserve les avantages de la technologie pub/sub avec Mqtt et notre protocole fonctionne partout dans le monde.

==Sources==

[https://fr.wikipedia.org/wiki/Publish-subscribe Pub/Sub]

[https://fr.wikipedia.org/wiki/MQTT MQTT]

[https://pypi.org/project/paho-mqtt/ paho-mqtt]

[https://fr.wikipedia.org/wiki/Representational_state_transfer REST]

[https://fr.wikipedia.org/wiki/WebSocket Websocket]

Fichier:MQTT sur Websocket.png

2019-05-19T23:39:19Z

Rakotoanosy :

Rest & Pub-Sub : protocole hybride pour l'IoT

2019-05-19T23:34:55Z

Rakotoanosy : /* MQTT sur Websocket */

== Introduction ==

== MQTT ==
MQTT, Message Queuing Telemetry Transport, est un protocole publish/subscribe se basant sur le protocole TCP/IP.
Il a été créé par Andy Stanford-Clark et Arlen Nipper.

De façon concrète, MQTT permet à des appareils de publier des informations sur un sujet donné sur un broker (un serveur qui fonctionne comme un coursier) qui va les retransmettre aux appareils abonnés à ce sujet.

[[Fichier:Fonctionnement broker mqtt.png|600px|thumb|left|illustration d'un échange entre un client 1 "subscriber" et un client 2 "publisher"]]

MQTT gère aussi la qualité de service (d'une qualité 0 à une qualité 2):

Qualité 0: le client qui publie une donnée ne reçoit aucune information par rapport à la confirmation de son arrivé.

Qualité 1: le client qui publie reçoit la confirmation ou non que la donnée publier à été reçu par le broker.

Qualité 2: le client qui publie reçoit la confirmation ou non que la donnée publier à été reçu par le broker ainsi qu'un message lui indiquant que le client qui s'abonne à reçu la donnée.
===Mosquitto===
Mosquitto est un broker open-source qui se sert du protocole MQTT. Il permet une fois installé de se familiarisé avec MQTT et le "publish/subscribe".

Nous nous en somme servit ici sur une MachineVirtuel en publiant en localhost:

[[Fichier:Mosquitto exemple.png]]

Sur un premier terminal on s'abonne à un topic "température" et sur un deuxième terminal, on publie ensuite sur ce même topic des nombres (qui s'apparentent à des température). Au fur et à mesure que nous publions ces informations, nous les recevons sur le premier terminal.
Mosquitto remplit bien ici son rôle de broker.

===Pub/Sub avec Python===

Nous avons ensuite développer un client ''publisher'' et un client ''subscriber'' en python grâce à la librairie paho-mqtt.
Pour plus de simplicité et éviter des problèmes de timing, nous avons tout regrouper en un seul programme:

import paho.mqtt.client as mqtt
import time

broker="test.mosquitto.org"

def envoi_message(client, QoS, message):
print("message reçu :", str(message.payload.decode("utf-8")))

client= mqtt.Client("client_test")
client.on_message=envoi_message

client.connect(broker)
print("connection")
client.loop_start()
client.subscribe("Cafetière/temperature_cafe")
print("Abonnement...")
time.sleep(1)
pub= input("entrez une température (un nombre):")
print("Publication...")
time.sleep(1)
client.publish("Cafetière/temperature_cafe",pub +"°C")
time.sleep(1)
client.disconnect()
print("deconnection")
client.loop_stop()
Comme broker, nous nous somme servit ici d'un broker mit en libre service par mosquitto.

==REST==
REST (Representational State Transfer) aussi appeler restful est une architecture logiciel inventer par Roy Fielding qui se sert des verbes HTTP comme identifiant des opérations et des réponses HTTP comme représentation des ressources.

Une architecture REST est définit par 5 règles/contraintes :

- '''Client–serveur'''

- '''Sans état'''

- '''Avec mise en cache'''

- '''En couches'''

- '''Interface uniforme :'''

L'interface uniforme est la contraintes fondamentale d'une architecture REST car c'est celle-ci qui permet à chaque composant d'évoluer indépendamment. Elle est définit par 4 contraintes :
<ul>
<li>Identification des ressources dans les requêtes</li>
<li>Manipulation des ressources par des représentations</li>
<li>Messages auto-descriptifs</li>
<li>Hypermédia comme moteur d'état de l'application</li>
</ul>

===Service pub/sub avec REST===
On peut réaliser un équivalent de service pub/sub avec REST à l'aide de GET et de POST qui agissent sur une base de données géré par un serveur:

[[Fichier:PubSub avec REST.png]]

Cette méthode comprend cependant de nombreux problèmes, notamment le fait que le client 1 ne sais pas si le client 2 à poster une donnée sur le serveur. On ne peut pas vraiment parler ici de service publish/subscribe car il n'y a pas d'abonnement, le client qui devrait s'abonner doit aller récupérer lui-même la donnée sans savoir si elle est bien dans la base de données du serveur.

==Protocole Hybride==

La technologie Pub/Sub et la technologie REST ont toutes deux leurs avantages et leurs inconvénients:

'''Avantages Pub/Sub :'''
<ul>
<li>Transfère rapide des informations</li>
<li>stockage des messages automatiques</li>
<li>gestion de la qualité de service</li>
</ul>
'''Inconvénient Pub/Sub :'''
<ul>
<li>On ne peut pas faire d’action direct sur le message, on ne fait un traitement dessus que lorsqu'on l'a reçu.</li>
<li>protocole mqtt,qui bloquer par certain par feu</li>
</ul>
'''Avantages REST :'''
<ul>
<li>protocole http(port 80) passe partout dans le monde</li>
<li>on peut traiter le message directement sur le serveur</li>
</ul>
'''Inconvénient REST :'''
<ul>
<li>On doit installer un serveur web, on doit géré une base de donnée (ou XML, Json).</li>
</ul>

L'objectif du protocole hybride est de réaliser un système pub/sub tel que l'on ai:
<ul>
<li>un transfère rapide des informations</li>
<li>un stockage des messages automatiques</li>
<li>une gestion de la qualité de service</li>
<li>le protocole http (port 80) de sorte à ce qu'il fonctionne partout dans le monde.</li>
</ul>

Pour cela, nous allons nous servir des Websockets.

===MQTT sur Websocket===

Le protocole Websocket est un protocole qui vise à développer un canal de communication web sur une connexion TCP.

Les objectifs de ce protocole étaient notamment de permettre au serveur l'envoi de données vers le client en mode push (sans que l'utilisateur n'ai à faire une requête).

Pour notre protocole hybride, l'idée serai d'ouvrir un canal de communication Websocket entre le broker et le client.

Lorsque l'on envoie le message mqtt au broker, on le place dans un paquet websocket puis on l'envoi au broker. Lorsque le serveur reçoit le paquet, il l'ouvre et traite le message Mqtt contenu comme il l'aurai fait avec un message mqtt "normal". On fait de même lorsque le broker envoie un message au client qui c'est abonner.

On peut l'illustrer de la façon suivante :

Ainsi puisque le protocole Websocket se sert du port 80, l'on conserve les avantages de la technologie pub/sub avec Mqtt et notre protocole fonctionne partout dans le monde.

==Sources==

[https://fr.wikipedia.org/wiki/Publish-subscribe Pub/Sub]

[https://fr.wikipedia.org/wiki/MQTT MQTT]

[https://pypi.org/project/paho-mqtt/ paho-mqtt]

[https://fr.wikipedia.org/wiki/Representational_state_transfer REST]

[https://fr.wikipedia.org/wiki/WebSocket Websocket]

Rest & Pub-Sub : protocole hybride pour l'IoT

2019-05-19T23:07:07Z

Rakotoanosy : /* MQTT sur Websocket */

== Introduction ==

== MQTT ==
MQTT, Message Queuing Telemetry Transport, est un protocole publish/subscribe se basant sur le protocole TCP/IP.
Il a été créé par Andy Stanford-Clark et Arlen Nipper.

De façon concrète, MQTT permet à des appareils de publier des informations sur un sujet donné sur un broker (un serveur qui fonctionne comme un coursier) qui va les retransmettre aux appareils abonnés à ce sujet.

[[Fichier:Fonctionnement broker mqtt.png|600px|thumb|left|illustration d'un échange entre un client 1 "subscriber" et un client 2 "publisher"]]

MQTT gère aussi la qualité de service (d'une qualité 0 à une qualité 2):

Qualité 0: le client qui publie une donnée ne reçoit aucune information par rapport à la confirmation de son arrivé.

Qualité 1: le client qui publie reçoit la confirmation ou non que la donnée publier à été reçu par le broker.

Qualité 2: le client qui publie reçoit la confirmation ou non que la donnée publier à été reçu par le broker ainsi qu'un message lui indiquant que le client qui s'abonne à reçu la donnée.
===Mosquitto===
Mosquitto est un broker open-source qui se sert du protocole MQTT. Il permet une fois installé de se familiarisé avec MQTT et le "publish/subscribe".

Nous nous en somme servit ici sur une MachineVirtuel en publiant en localhost:

[[Fichier:Mosquitto exemple.png]]

Sur un premier terminal on s'abonne à un topic "température" et sur un deuxième terminal, on publie ensuite sur ce même topic des nombres (qui s'apparentent à des température). Au fur et à mesure que nous publions ces informations, nous les recevons sur le premier terminal.
Mosquitto remplit bien ici son rôle de broker.

===Pub/Sub avec Python===

Nous avons ensuite développer un client ''publisher'' et un client ''subscriber'' en python grâce à la librairie paho-mqtt.
Pour plus de simplicité et éviter des problèmes de timing, nous avons tout regrouper en un seul programme:

import paho.mqtt.client as mqtt
import time

broker="test.mosquitto.org"

def envoi_message(client, QoS, message):
print("message reçu :", str(message.payload.decode("utf-8")))

client= mqtt.Client("client_test")
client.on_message=envoi_message

client.connect(broker)
print("connection")
client.loop_start()
client.subscribe("Cafetière/temperature_cafe")
print("Abonnement...")
time.sleep(1)
pub= input("entrez une température (un nombre):")
print("Publication...")
time.sleep(1)
client.publish("Cafetière/temperature_cafe",pub +"°C")
time.sleep(1)
client.disconnect()
print("deconnection")
client.loop_stop()
Comme broker, nous nous somme servit ici d'un broker mit en libre service par mosquitto.

==REST==
REST (Representational State Transfer) aussi appeler restful est une architecture logiciel inventer par Roy Fielding qui se sert des verbes HTTP comme identifiant des opérations et des réponses HTTP comme représentation des ressources.

Une architecture REST est définit par 5 règles/contraintes :

- '''Client–serveur'''

- '''Sans état'''

- '''Avec mise en cache'''

- '''En couches'''

- '''Interface uniforme :'''

L'interface uniforme est la contraintes fondamentale d'une architecture REST car c'est celle-ci qui permet à chaque composant d'évoluer indépendamment. Elle est définit par 4 contraintes :
<ul>
<li>Identification des ressources dans les requêtes</li>
<li>Manipulation des ressources par des représentations</li>
<li>Messages auto-descriptifs</li>
<li>Hypermédia comme moteur d'état de l'application</li>
</ul>

===Service pub/sub avec REST===
On peut réaliser un équivalent de service pub/sub avec REST à l'aide de GET et de POST qui agissent sur une base de données géré par un serveur:

[[Fichier:PubSub avec REST.png]]

Cette méthode comprend cependant de nombreux problèmes, notamment le fait que le client 1 ne sais pas si le client 2 à poster une donnée sur le serveur. On ne peut pas vraiment parler ici de service publish/subscribe car il n'y a pas d'abonnement, le client qui devrait s'abonner doit aller récupérer lui-même la donnée sans savoir si elle est bien dans la base de données du serveur.

==Protocole Hybride==

La technologie Pub/Sub et la technologie REST ont toutes deux leurs avantages et leurs inconvénients:

'''Avantages Pub/Sub :'''
<ul>
<li>Transfère rapide des informations</li>
<li>stockage des messages automatiques</li>
<li>gestion de la qualité de service</li>
</ul>
'''Inconvénient Pub/Sub :'''
<ul>
<li>On ne peut pas faire d’action direct sur le message, on ne fait un traitement dessus que lorsqu'on l'a reçu.</li>
<li>protocole mqtt,qui bloquer par certain par feu</li>
</ul>
'''Avantages REST :'''
<ul>
<li>protocole http(port 80) passe partout dans le monde</li>
<li>on peut traiter le message directement sur le serveur</li>
</ul>
'''Inconvénient REST :'''
<ul>
<li>On doit installer un serveur web, on doit géré une base de donnée (ou XML, Json).</li>
</ul>

L'objectif du protocole hybride est de réaliser un système pub/sub tel que l'on ai:
<ul>
<li>un transfère rapide des informations</li>
<li>un stockage des messages automatiques</li>
<li>une gestion de la qualité de service</li>
<li>le protocole http (port 80) de sorte à ce qu'il fonctionne partout dans le monde.</li>
</ul>

Pour cela, nous allons nous servir des Websockets.

===MQTT sur Websocket===

Le protocole Websocket est un protocole qui vise à développer un canal de communication web sur une connexion TCP.

Les objectifs de ce protocole étaientt notamment de permettre au serveur l'envoi de données vers le client en mode push (sans que l'utilisateur n'ai à faire une requête).

==Sources==

[https://fr.wikipedia.org/wiki/Publish-subscribe Pub/Sub]

[https://fr.wikipedia.org/wiki/MQTT MQTT]

[https://pypi.org/project/paho-mqtt/ paho-mqtt]

[https://fr.wikipedia.org/wiki/Representational_state_transfer REST]

[https://fr.wikipedia.org/wiki/WebSocket Websocket]

Rest & Pub-Sub : protocole hybride pour l'IoT

2019-05-19T23:06:35Z

Rakotoanosy : /* REST */

== Introduction ==

== MQTT ==
MQTT, Message Queuing Telemetry Transport, est un protocole publish/subscribe se basant sur le protocole TCP/IP.
Il a été créé par Andy Stanford-Clark et Arlen Nipper.

De façon concrète, MQTT permet à des appareils de publier des informations sur un sujet donné sur un broker (un serveur qui fonctionne comme un coursier) qui va les retransmettre aux appareils abonnés à ce sujet.

[[Fichier:Fonctionnement broker mqtt.png|600px|thumb|left|illustration d'un échange entre un client 1 "subscriber" et un client 2 "publisher"]]

MQTT gère aussi la qualité de service (d'une qualité 0 à une qualité 2):

Qualité 0: le client qui publie une donnée ne reçoit aucune information par rapport à la confirmation de son arrivé.

Qualité 1: le client qui publie reçoit la confirmation ou non que la donnée publier à été reçu par le broker.

Qualité 2: le client qui publie reçoit la confirmation ou non que la donnée publier à été reçu par le broker ainsi qu'un message lui indiquant que le client qui s'abonne à reçu la donnée.
===Mosquitto===
Mosquitto est un broker open-source qui se sert du protocole MQTT. Il permet une fois installé de se familiarisé avec MQTT et le "publish/subscribe".

Nous nous en somme servit ici sur une MachineVirtuel en publiant en localhost:

[[Fichier:Mosquitto exemple.png]]

Sur un premier terminal on s'abonne à un topic "température" et sur un deuxième terminal, on publie ensuite sur ce même topic des nombres (qui s'apparentent à des température). Au fur et à mesure que nous publions ces informations, nous les recevons sur le premier terminal.
Mosquitto remplit bien ici son rôle de broker.

===Pub/Sub avec Python===

Nous avons ensuite développer un client ''publisher'' et un client ''subscriber'' en python grâce à la librairie paho-mqtt.
Pour plus de simplicité et éviter des problèmes de timing, nous avons tout regrouper en un seul programme:

import paho.mqtt.client as mqtt
import time

broker="test.mosquitto.org"

def envoi_message(client, QoS, message):
print("message reçu :", str(message.payload.decode("utf-8")))

client= mqtt.Client("client_test")
client.on_message=envoi_message

client.connect(broker)
print("connection")
client.loop_start()
client.subscribe("Cafetière/temperature_cafe")
print("Abonnement...")
time.sleep(1)
pub= input("entrez une température (un nombre):")
print("Publication...")
time.sleep(1)
client.publish("Cafetière/temperature_cafe",pub +"°C")
time.sleep(1)
client.disconnect()
print("deconnection")
client.loop_stop()
Comme broker, nous nous somme servit ici d'un broker mit en libre service par mosquitto.

==REST==
REST (Representational State Transfer) aussi appeler restful est une architecture logiciel inventer par Roy Fielding qui se sert des verbes HTTP comme identifiant des opérations et des réponses HTTP comme représentation des ressources.

Une architecture REST est définit par 5 règles/contraintes :

- '''Client–serveur'''

- '''Sans état'''

- '''Avec mise en cache'''

- '''En couches'''

- '''Interface uniforme :'''

L'interface uniforme est la contraintes fondamentale d'une architecture REST car c'est celle-ci qui permet à chaque composant d'évoluer indépendamment. Elle est définit par 4 contraintes :
<ul>
<li>Identification des ressources dans les requêtes</li>
<li>Manipulation des ressources par des représentations</li>
<li>Messages auto-descriptifs</li>
<li>Hypermédia comme moteur d'état de l'application</li>
</ul>

===Service pub/sub avec REST===
On peut réaliser un équivalent de service pub/sub avec REST à l'aide de GET et de POST qui agissent sur une base de données géré par un serveur:

[[Fichier:PubSub avec REST.png]]

Cette méthode comprend cependant de nombreux problèmes, notamment le fait que le client 1 ne sais pas si le client 2 à poster une donnée sur le serveur. On ne peut pas vraiment parler ici de service publish/subscribe car il n'y a pas d'abonnement, le client qui devrait s'abonner doit aller récupérer lui-même la donnée sans savoir si elle est bien dans la base de données du serveur.

==Protocole Hybride==

La technologie Pub/Sub et la technologie REST ont toutes deux leurs avantages et leurs inconvénients:

'''Avantages Pub/Sub :'''
<ul>
<li>Transfère rapide des informations</li>
<li>stockage des messages automatiques</li>
<li>gestion de la qualité de service</li>
</ul>
'''Inconvénient Pub/Sub :'''
<ul>
<li>On ne peut pas faire d’action direct sur le message, on ne fait un traitement dessus que lorsqu'on l'a reçu.</li>
<li>protocole mqtt,qui bloquer par certain par feu</li>
</ul>
'''Avantages REST :'''
<ul>
<li>protocole http(port 80) passe partout dans le monde</li>
<li>on peut traiter le message directement sur le serveur</li>
</ul>
'''Inconvénient REST :'''
<ul>
<li>On doit installer un serveur web, on doit géré une base de donnée (ou XML, Json).</li>
</ul>

L'objectif du protocole hybride est de réaliser un système pub/sub tel que l'on ai:
<ul>
<li>un transfère rapide des informations</li>
<li>un stockage des messages automatiques</li>
<li>une gestion de la qualité de service</li>
<li>le protocole http (port 80) de sorte à ce qu'il fonctionne partout dans le monde.</li>
</ul>

Pour cela, nous allons nous servir des Websockets.

===MQTT sur Websocket===

Le protocole Websocket est un protocole qui vise à développer un canal de communication web sur une connexion TCP.

Les objectifs de ce protocole était notamment de permettre au serveur l'envoi de données vers le client en mode push (sans que l'utilisateur n'ai à faire une requête).

==Sources==

[https://fr.wikipedia.org/wiki/Publish-subscribe Pub/Sub]

[https://fr.wikipedia.org/wiki/MQTT MQTT]

[https://pypi.org/project/paho-mqtt/ paho-mqtt]

[https://fr.wikipedia.org/wiki/Representational_state_transfer REST]

[https://fr.wikipedia.org/wiki/WebSocket Websocket]

Rest & Pub-Sub : protocole hybride pour l'IoT

2019-05-19T23:04:26Z

Rakotoanosy : /* REST */

== Introduction ==

== MQTT ==
MQTT, Message Queuing Telemetry Transport, est un protocole publish/subscribe se basant sur le protocole TCP/IP.
Il a été créé par Andy Stanford-Clark et Arlen Nipper.

De façon concrète, MQTT permet à des appareils de publier des informations sur un sujet donné sur un broker (un serveur qui fonctionne comme un coursier) qui va les retransmettre aux appareils abonnés à ce sujet.

[[Fichier:Fonctionnement broker mqtt.png|600px|thumb|left|illustration d'un échange entre un client 1 "subscriber" et un client 2 "publisher"]]

MQTT gère aussi la qualité de service (d'une qualité 0 à une qualité 2):

Qualité 0: le client qui publie une donnée ne reçoit aucune information par rapport à la confirmation de son arrivé.

Qualité 1: le client qui publie reçoit la confirmation ou non que la donnée publier à été reçu par le broker.

Qualité 2: le client qui publie reçoit la confirmation ou non que la donnée publier à été reçu par le broker ainsi qu'un message lui indiquant que le client qui s'abonne à reçu la donnée.
===Mosquitto===
Mosquitto est un broker open-source qui se sert du protocole MQTT. Il permet une fois installé de se familiarisé avec MQTT et le "publish/subscribe".

Nous nous en somme servit ici sur une MachineVirtuel en publiant en localhost:

[[Fichier:Mosquitto exemple.png]]

Sur un premier terminal on s'abonne à un topic "température" et sur un deuxième terminal, on publie ensuite sur ce même topic des nombres (qui s'apparentent à des température). Au fur et à mesure que nous publions ces informations, nous les recevons sur le premier terminal.
Mosquitto remplit bien ici son rôle de broker.

===Pub/Sub avec Python===

Nous avons ensuite développer un client ''publisher'' et un client ''subscriber'' en python grâce à la librairie paho-mqtt.
Pour plus de simplicité et éviter des problèmes de timing, nous avons tout regrouper en un seul programme:

import paho.mqtt.client as mqtt
import time

broker="test.mosquitto.org"

def envoi_message(client, QoS, message):
print("message reçu :", str(message.payload.decode("utf-8")))

client= mqtt.Client("client_test")
client.on_message=envoi_message

client.connect(broker)
print("connection")
client.loop_start()
client.subscribe("Cafetière/temperature_cafe")
print("Abonnement...")
time.sleep(1)
pub= input("entrez une température (un nombre):")
print("Publication...")
time.sleep(1)
client.publish("Cafetière/temperature_cafe",pub +"°C")
time.sleep(1)
client.disconnect()
print("deconnection")
client.loop_stop()
Comme broker, nous nous somme servit ici d'un broker mit en libre service par mosquitto.

==REST==
REST (Representational State Transfer) aussi appeler restful est une architecture logiciel inventer par Roy Fielding qui se sert des verbes HTTP comme identifiant des opérations et des réponses HTTP comme représentation des ressources.

Une architecture REST est définit par 5 règles/contraintes :

- '''Client–serveur'''

- '''Sans état'''

- '''Avec mise en cache'''

- '''En couches'''

- '''Interface uniforme'''

L'interface uniforme est la contraintes fondamentale d'une architecture REST car c'est celle-ci qui permet à chaque composant d'évoluer indépendamment. Elle est définit par 4 contraintes :
<ul>
<li>Identification des ressources dans les requêtes</li>
<li>Manipulation des ressources par des représentations</li>
<li>Messages auto-descriptifs</li>
<li>Hypermédia comme moteur d'état de l'application</li>
</ul>

===Service pub/sub avec REST===
On peut réaliser un équivalent de service pub/sub avec REST à l'aide de GET et de POST qui agissent sur une base de données géré par un serveur:

[[Fichier:PubSub avec REST.png]]

Cette méthode comprend cependant de nombreux problèmes, notamment le fait que le client 1 ne sais pas si le client 2 à poster une donnée sur le serveur. On ne peut pas vraiment parler ici de service publish/subscribe car il n'y a pas d'abonnement, le client qui devrait s'abonner doit aller récupérer lui-même la donnée sans savoir si elle est bien dans la base de données du serveur.

==Protocole Hybride==

La technologie Pub/Sub et la technologie REST ont toutes deux leurs avantages et leurs inconvénients:

'''Avantages Pub/Sub :'''
<ul>
<li>Transfère rapide des informations</li>
<li>stockage des messages automatiques</li>
<li>gestion de la qualité de service</li>
</ul>
'''Inconvénient Pub/Sub :'''
<ul>
<li>On ne peut pas faire d’action direct sur le message, on ne fait un traitement dessus que lorsqu'on l'a reçu.</li>
<li>protocole mqtt,qui bloquer par certain par feu</li>
</ul>
'''Avantages REST :'''
<ul>
<li>protocole http(port 80) passe partout dans le monde</li>
<li>on peut traiter le message directement sur le serveur</li>
</ul>
'''Inconvénient REST :'''
<ul>
<li>On doit installer un serveur web, on doit géré une base de donnée (ou XML, Json).</li>
</ul>

L'objectif du protocole hybride est de réaliser un système pub/sub tel que l'on ai:
<ul>
<li>un transfère rapide des informations</li>
<li>un stockage des messages automatiques</li>
<li>une gestion de la qualité de service</li>
<li>le protocole http (port 80) de sorte à ce qu'il fonctionne partout dans le monde.</li>
</ul>

Pour cela, nous allons nous servir des Websockets.

===MQTT sur Websocket===

Le protocole Websocket est un protocole qui vise à développer un canal de communication web sur une connexion TCP.

Les objectifs de ce protocole était notamment de permettre au serveur l'envoi de données vers le client en mode push (sans que l'utilisateur n'ai à faire une requête).

==Sources==

[https://fr.wikipedia.org/wiki/Publish-subscribe Pub/Sub]

[https://fr.wikipedia.org/wiki/MQTT MQTT]

[https://pypi.org/project/paho-mqtt/ paho-mqtt]

[https://fr.wikipedia.org/wiki/Representational_state_transfer REST]

[https://fr.wikipedia.org/wiki/WebSocket Websocket]

Rest & Pub-Sub : protocole hybride pour l'IoT

2019-05-19T23:04:08Z

Rakotoanosy : /* REST */

== Introduction ==

== MQTT ==
MQTT, Message Queuing Telemetry Transport, est un protocole publish/subscribe se basant sur le protocole TCP/IP.
Il a été créé par Andy Stanford-Clark et Arlen Nipper.

De façon concrète, MQTT permet à des appareils de publier des informations sur un sujet donné sur un broker (un serveur qui fonctionne comme un coursier) qui va les retransmettre aux appareils abonnés à ce sujet.

[[Fichier:Fonctionnement broker mqtt.png|600px|thumb|left|illustration d'un échange entre un client 1 "subscriber" et un client 2 "publisher"]]

MQTT gère aussi la qualité de service (d'une qualité 0 à une qualité 2):

Qualité 0: le client qui publie une donnée ne reçoit aucune information par rapport à la confirmation de son arrivé.

Qualité 1: le client qui publie reçoit la confirmation ou non que la donnée publier à été reçu par le broker.

Qualité 2: le client qui publie reçoit la confirmation ou non que la donnée publier à été reçu par le broker ainsi qu'un message lui indiquant que le client qui s'abonne à reçu la donnée.
===Mosquitto===
Mosquitto est un broker open-source qui se sert du protocole MQTT. Il permet une fois installé de se familiarisé avec MQTT et le "publish/subscribe".

Nous nous en somme servit ici sur une MachineVirtuel en publiant en localhost:

[[Fichier:Mosquitto exemple.png]]

Sur un premier terminal on s'abonne à un topic "température" et sur un deuxième terminal, on publie ensuite sur ce même topic des nombres (qui s'apparentent à des température). Au fur et à mesure que nous publions ces informations, nous les recevons sur le premier terminal.
Mosquitto remplit bien ici son rôle de broker.

===Pub/Sub avec Python===

Nous avons ensuite développer un client ''publisher'' et un client ''subscriber'' en python grâce à la librairie paho-mqtt.
Pour plus de simplicité et éviter des problèmes de timing, nous avons tout regrouper en un seul programme:

import paho.mqtt.client as mqtt
import time

broker="test.mosquitto.org"

def envoi_message(client, QoS, message):
print("message reçu :", str(message.payload.decode("utf-8")))

client= mqtt.Client("client_test")
client.on_message=envoi_message

client.connect(broker)
print("connection")
client.loop_start()
client.subscribe("Cafetière/temperature_cafe")
print("Abonnement...")
time.sleep(1)
pub= input("entrez une température (un nombre):")
print("Publication...")
time.sleep(1)
client.publish("Cafetière/temperature_cafe",pub +"°C")
time.sleep(1)
client.disconnect()
print("deconnection")
client.loop_stop()
Comme broker, nous nous somme servit ici d'un broker mit en libre service par mosquitto.

==REST==
REST (Representational State Transfer) aussi appeler restful est une architecture logiciel inventer par Roy Fielding qui se sert des verbes HTTP comme identifiant des opérations et des réponses HTTP comme représentation des ressources.

Une architecture REST est définit par 5 règles/contraintes :

- '''Client–serveur'''

- '''Sans état'''

- '''Avec mise en cache'''

- '''En couches'''

- '''Interface uniforme'''
L'interface uniforme est la contraintes fondamentale d'une architecture REST car c'est celle-ci qui permet à chaque composant d'évoluer indépendamment. Elle est définit par 4 contraintes :
<ul>
<li>Identification des ressources dans les requêtes</li>
<li>Manipulation des ressources par des représentations</li>
<li>Messages auto-descriptifs</li>
<li>Hypermédia comme moteur d'état de l'application</li>
</ul>

===Service pub/sub avec REST===
On peut réaliser un équivalent de service pub/sub avec REST à l'aide de GET et de POST qui agissent sur une base de données géré par un serveur:

[[Fichier:PubSub avec REST.png]]

Cette méthode comprend cependant de nombreux problèmes, notamment le fait que le client 1 ne sais pas si le client 2 à poster une donnée sur le serveur. On ne peut pas vraiment parler ici de service publish/subscribe car il n'y a pas d'abonnement, le client qui devrait s'abonner doit aller récupérer lui-même la donnée sans savoir si elle est bien dans la base de données du serveur.

==Protocole Hybride==

La technologie Pub/Sub et la technologie REST ont toutes deux leurs avantages et leurs inconvénients:

'''Avantages Pub/Sub :'''
<ul>
<li>Transfère rapide des informations</li>
<li>stockage des messages automatiques</li>
<li>gestion de la qualité de service</li>
</ul>
'''Inconvénient Pub/Sub :'''
<ul>
<li>On ne peut pas faire d’action direct sur le message, on ne fait un traitement dessus que lorsqu'on l'a reçu.</li>
<li>protocole mqtt,qui bloquer par certain par feu</li>
</ul>
'''Avantages REST :'''
<ul>
<li>protocole http(port 80) passe partout dans le monde</li>
<li>on peut traiter le message directement sur le serveur</li>
</ul>
'''Inconvénient REST :'''
<ul>
<li>On doit installer un serveur web, on doit géré une base de donnée (ou XML, Json).</li>
</ul>

L'objectif du protocole hybride est de réaliser un système pub/sub tel que l'on ai:
<ul>
<li>un transfère rapide des informations</li>
<li>un stockage des messages automatiques</li>
<li>une gestion de la qualité de service</li>
<li>le protocole http (port 80) de sorte à ce qu'il fonctionne partout dans le monde.</li>
</ul>

Pour cela, nous allons nous servir des Websockets.

===MQTT sur Websocket===

Le protocole Websocket est un protocole qui vise à développer un canal de communication web sur une connexion TCP.

Les objectifs de ce protocole était notamment de permettre au serveur l'envoi de données vers le client en mode push (sans que l'utilisateur n'ai à faire une requête).

==Sources==

[https://fr.wikipedia.org/wiki/Publish-subscribe Pub/Sub]

[https://fr.wikipedia.org/wiki/MQTT MQTT]

[https://pypi.org/project/paho-mqtt/ paho-mqtt]

[https://fr.wikipedia.org/wiki/Representational_state_transfer REST]

[https://fr.wikipedia.org/wiki/WebSocket Websocket]

Rest & Pub-Sub : protocole hybride pour l'IoT

2019-05-19T22:50:36Z

Rakotoanosy : /* Protocole Hybride */

== Introduction ==

== MQTT ==
MQTT, Message Queuing Telemetry Transport, est un protocole publish/subscribe se basant sur le protocole TCP/IP.
Il a été créé par Andy Stanford-Clark et Arlen Nipper.

De façon concrète, MQTT permet à des appareils de publier des informations sur un sujet donné sur un broker (un serveur qui fonctionne comme un coursier) qui va les retransmettre aux appareils abonnés à ce sujet.

[[Fichier:Fonctionnement broker mqtt.png|600px|thumb|left|illustration d'un échange entre un client 1 "subscriber" et un client 2 "publisher"]]

MQTT gère aussi la qualité de service (d'une qualité 0 à une qualité 2):

Qualité 0: le client qui publie une donnée ne reçoit aucune information par rapport à la confirmation de son arrivé.

Qualité 1: le client qui publie reçoit la confirmation ou non que la donnée publier à été reçu par le broker.

Qualité 2: le client qui publie reçoit la confirmation ou non que la donnée publier à été reçu par le broker ainsi qu'un message lui indiquant que le client qui s'abonne à reçu la donnée.
===Mosquitto===
Mosquitto est un broker open-source qui se sert du protocole MQTT. Il permet une fois installé de se familiarisé avec MQTT et le "publish/subscribe".

Nous nous en somme servit ici sur une MachineVirtuel en publiant en localhost:

[[Fichier:Mosquitto exemple.png]]

Sur un premier terminal on s'abonne à un topic "température" et sur un deuxième terminal, on publie ensuite sur ce même topic des nombres (qui s'apparentent à des température). Au fur et à mesure que nous publions ces informations, nous les recevons sur le premier terminal.
Mosquitto remplit bien ici son rôle de broker.

===Pub/Sub avec Python===

Nous avons ensuite développer un client ''publisher'' et un client ''subscriber'' en python grâce à la librairie paho-mqtt.
Pour plus de simplicité et éviter des problèmes de timing, nous avons tout regrouper en un seul programme:

import paho.mqtt.client as mqtt
import time

broker="test.mosquitto.org"

def envoi_message(client, QoS, message):
print("message reçu :", str(message.payload.decode("utf-8")))

client= mqtt.Client("client_test")
client.on_message=envoi_message

client.connect(broker)
print("connection")
client.loop_start()
client.subscribe("Cafetière/temperature_cafe")
print("Abonnement...")
time.sleep(1)
pub= input("entrez une température (un nombre):")
print("Publication...")
time.sleep(1)
client.publish("Cafetière/temperature_cafe",pub +"°C")
time.sleep(1)
client.disconnect()
print("deconnection")
client.loop_stop()
Comme broker, nous nous somme servit ici d'un broker mit en libre service par mosquitto.

==REST==
REST (Representational State Transfer) aussi appeler restful est une architecture logiciel inventer par Roy Fielding qui se sert des verbes HTTP comme identifiant des opérations et des réponses HTTP comme représentation des ressources.

Une architecture REST est définit par 5 règles/contraintes :

- Client–serveur

- Sans état

- Avec mise en cache

- En couches

- Interface uniforme

===Service pub/sub avec REST===
On peut réaliser un équivalent de service pub/sub avec REST à l'aide de GET et de POST qui agissent sur une base de données géré par un serveur:

[[Fichier:PubSub avec REST.png]]

Cette méthode comprend cependant de nombreux problèmes, notamment le fait que le client 1 ne sais pas si le client 2 à poster une donnée sur le serveur. On ne peut pas vraiment parler ici de service publish/subscribe car il n'y a pas d'abonnement, le client qui devrait s'abonner doit aller récupérer lui-même la donnée sans savoir si elle est bien dans la base de données du serveur.

==Protocole Hybride==

La technologie Pub/Sub et la technologie REST ont toutes deux leurs avantages et leurs inconvénients:

'''Avantages Pub/Sub :'''
<ul>
<li>Transfère rapide des informations</li>
<li>stockage des messages automatiques</li>
<li>gestion de la qualité de service</li>
</ul>
'''Inconvénient Pub/Sub :'''
<ul>
<li>On ne peut pas faire d’action direct sur le message, on ne fait un traitement dessus que lorsqu'on l'a reçu.</li>
<li>protocole mqtt,qui bloquer par certain par feu</li>
</ul>
'''Avantages REST :'''
<ul>
<li>protocole http(port 80) passe partout dans le monde</li>
<li>on peut traiter le message directement sur le serveur</li>
</ul>
'''Inconvénient REST :'''
<ul>
<li>On doit installer un serveur web, on doit géré une base de donnée (ou XML, Json).</li>
</ul>

L'objectif du protocole hybride est de réaliser un système pub/sub tel que l'on ai:
<ul>
<li>un transfère rapide des informations</li>
<li>un stockage des messages automatiques</li>
<li>une gestion de la qualité de service</li>
<li>le protocole http (port 80) de sorte à ce qu'il fonctionne partout dans le monde.</li>
</ul>

Pour cela, nous allons nous servir des Websockets.

===MQTT sur Websocket===

Le protocole Websocket est un protocole qui vise à développer un canal de communication web sur une connexion TCP.

Les objectifs de ce protocole était notamment de permettre au serveur l'envoi de données vers le client en mode push (sans que l'utilisateur n'ai à faire une requête).

==Sources==

[https://fr.wikipedia.org/wiki/Publish-subscribe Pub/Sub]

[https://fr.wikipedia.org/wiki/MQTT MQTT]

[https://pypi.org/project/paho-mqtt/ paho-mqtt]

[https://fr.wikipedia.org/wiki/Representational_state_transfer REST]

[https://fr.wikipedia.org/wiki/WebSocket Websocket]

Rest & Pub-Sub : protocole hybride pour l'IoT

2019-05-19T22:50:19Z

Rakotoanosy : /* Protocole Hybride */

== Introduction ==

== MQTT ==
MQTT, Message Queuing Telemetry Transport, est un protocole publish/subscribe se basant sur le protocole TCP/IP.
Il a été créé par Andy Stanford-Clark et Arlen Nipper.

De façon concrète, MQTT permet à des appareils de publier des informations sur un sujet donné sur un broker (un serveur qui fonctionne comme un coursier) qui va les retransmettre aux appareils abonnés à ce sujet.

[[Fichier:Fonctionnement broker mqtt.png|600px|thumb|left|illustration d'un échange entre un client 1 "subscriber" et un client 2 "publisher"]]

MQTT gère aussi la qualité de service (d'une qualité 0 à une qualité 2):

Qualité 0: le client qui publie une donnée ne reçoit aucune information par rapport à la confirmation de son arrivé.

Qualité 1: le client qui publie reçoit la confirmation ou non que la donnée publier à été reçu par le broker.

Qualité 2: le client qui publie reçoit la confirmation ou non que la donnée publier à été reçu par le broker ainsi qu'un message lui indiquant que le client qui s'abonne à reçu la donnée.
===Mosquitto===
Mosquitto est un broker open-source qui se sert du protocole MQTT. Il permet une fois installé de se familiarisé avec MQTT et le "publish/subscribe".

Nous nous en somme servit ici sur une MachineVirtuel en publiant en localhost:

[[Fichier:Mosquitto exemple.png]]

Sur un premier terminal on s'abonne à un topic "température" et sur un deuxième terminal, on publie ensuite sur ce même topic des nombres (qui s'apparentent à des température). Au fur et à mesure que nous publions ces informations, nous les recevons sur le premier terminal.
Mosquitto remplit bien ici son rôle de broker.

===Pub/Sub avec Python===

Nous avons ensuite développer un client ''publisher'' et un client ''subscriber'' en python grâce à la librairie paho-mqtt.
Pour plus de simplicité et éviter des problèmes de timing, nous avons tout regrouper en un seul programme:

import paho.mqtt.client as mqtt
import time

broker="test.mosquitto.org"

def envoi_message(client, QoS, message):
print("message reçu :", str(message.payload.decode("utf-8")))

client= mqtt.Client("client_test")
client.on_message=envoi_message

client.connect(broker)
print("connection")
client.loop_start()
client.subscribe("Cafetière/temperature_cafe")
print("Abonnement...")
time.sleep(1)
pub= input("entrez une température (un nombre):")
print("Publication...")
time.sleep(1)
client.publish("Cafetière/temperature_cafe",pub +"°C")
time.sleep(1)
client.disconnect()
print("deconnection")
client.loop_stop()
Comme broker, nous nous somme servit ici d'un broker mit en libre service par mosquitto.

==REST==
REST (Representational State Transfer) aussi appeler restful est une architecture logiciel inventer par Roy Fielding qui se sert des verbes HTTP comme identifiant des opérations et des réponses HTTP comme représentation des ressources.

Une architecture REST est définit par 5 règles/contraintes :

- Client–serveur

- Sans état

- Avec mise en cache

- En couches

- Interface uniforme

===Service pub/sub avec REST===
On peut réaliser un équivalent de service pub/sub avec REST à l'aide de GET et de POST qui agissent sur une base de données géré par un serveur:

[[Fichier:PubSub avec REST.png]]

Cette méthode comprend cependant de nombreux problèmes, notamment le fait que le client 1 ne sais pas si le client 2 à poster une donnée sur le serveur. On ne peut pas vraiment parler ici de service publish/subscribe car il n'y a pas d'abonnement, le client qui devrait s'abonner doit aller récupérer lui-même la donnée sans savoir si elle est bien dans la base de données du serveur.

==Protocole Hybride==

La technologie Pub/Sub et la technologie REST ont toutes deux leurs avantages et leurs inconvénients:

'''Avantages Pub/Sub :'''
<ul>
<li>Transfère rapide des informations</li>
<li>stockage des messages automatiques</li>
<li>gestion de la qualité de service</li>
</ul>
'''Inconvénient Pub/Sub:'''
<ul>
<li>On ne peut pas faire d’action direct sur le message, on ne fait un traitement dessus que lorsqu'on l'a reçu.</li>
<li>protocole mqtt,qui bloquer par certain par feu</li>
</ul>
'''Avantages REST:'''
<ul>
<li>protocole http(port 80) passe partout dans le monde</li>
<li>on peut traiter le message directement sur le serveur</li>
</ul>
'''Inconvénient REST:'''
<ul>
<li>On doit installer un serveur web, on doit géré une base de donnée (ou XML, Json).</li>
</ul>

L'objectif du protocole hybride est de réaliser un système pub/sub tel que l'on ai:
<ul>
<li>un transfère rapide des informations</li>
<li>un stockage des messages automatiques</li>
<li>une gestion de la qualité de service</li>
<li>le protocole http (port 80) de sorte à ce qu'il fonctionne partout dans le monde.</li>
</ul>

Pour cela, nous allons nous servir des Websockets.

===MQTT sur Websocket===

Le protocole Websocket est un protocole qui vise à développer un canal de communication web sur une connexion TCP.

Les objectifs de ce protocole était notamment de permettre au serveur l'envoi de données vers le client en mode push (sans que l'utilisateur n'ai à faire une requête).

==Sources==

[https://fr.wikipedia.org/wiki/Publish-subscribe Pub/Sub]

[https://fr.wikipedia.org/wiki/MQTT MQTT]

[https://pypi.org/project/paho-mqtt/ paho-mqtt]

[https://fr.wikipedia.org/wiki/Representational_state_transfer REST]

[https://fr.wikipedia.org/wiki/WebSocket Websocket]

Rest & Pub-Sub : protocole hybride pour l'IoT

2019-05-19T22:49:41Z

Rakotoanosy : /* Service pub/sub avec REST */

== Introduction ==

== MQTT ==
MQTT, Message Queuing Telemetry Transport, est un protocole publish/subscribe se basant sur le protocole TCP/IP.
Il a été créé par Andy Stanford-Clark et Arlen Nipper.

De façon concrète, MQTT permet à des appareils de publier des informations sur un sujet donné sur un broker (un serveur qui fonctionne comme un coursier) qui va les retransmettre aux appareils abonnés à ce sujet.

[[Fichier:Fonctionnement broker mqtt.png|600px|thumb|left|illustration d'un échange entre un client 1 "subscriber" et un client 2 "publisher"]]

MQTT gère aussi la qualité de service (d'une qualité 0 à une qualité 2):

Qualité 0: le client qui publie une donnée ne reçoit aucune information par rapport à la confirmation de son arrivé.

Qualité 1: le client qui publie reçoit la confirmation ou non que la donnée publier à été reçu par le broker.

Qualité 2: le client qui publie reçoit la confirmation ou non que la donnée publier à été reçu par le broker ainsi qu'un message lui indiquant que le client qui s'abonne à reçu la donnée.
===Mosquitto===
Mosquitto est un broker open-source qui se sert du protocole MQTT. Il permet une fois installé de se familiarisé avec MQTT et le "publish/subscribe".

Nous nous en somme servit ici sur une MachineVirtuel en publiant en localhost:

[[Fichier:Mosquitto exemple.png]]

Sur un premier terminal on s'abonne à un topic "température" et sur un deuxième terminal, on publie ensuite sur ce même topic des nombres (qui s'apparentent à des température). Au fur et à mesure que nous publions ces informations, nous les recevons sur le premier terminal.
Mosquitto remplit bien ici son rôle de broker.

===Pub/Sub avec Python===

Nous avons ensuite développer un client ''publisher'' et un client ''subscriber'' en python grâce à la librairie paho-mqtt.
Pour plus de simplicité et éviter des problèmes de timing, nous avons tout regrouper en un seul programme:

import paho.mqtt.client as mqtt
import time

broker="test.mosquitto.org"

def envoi_message(client, QoS, message):
print("message reçu :", str(message.payload.decode("utf-8")))

client= mqtt.Client("client_test")
client.on_message=envoi_message

client.connect(broker)
print("connection")
client.loop_start()
client.subscribe("Cafetière/temperature_cafe")
print("Abonnement...")
time.sleep(1)
pub= input("entrez une température (un nombre):")
print("Publication...")
time.sleep(1)
client.publish("Cafetière/temperature_cafe",pub +"°C")
time.sleep(1)
client.disconnect()
print("deconnection")
client.loop_stop()
Comme broker, nous nous somme servit ici d'un broker mit en libre service par mosquitto.

==REST==
REST (Representational State Transfer) aussi appeler restful est une architecture logiciel inventer par Roy Fielding qui se sert des verbes HTTP comme identifiant des opérations et des réponses HTTP comme représentation des ressources.

Une architecture REST est définit par 5 règles/contraintes :

- Client–serveur

- Sans état

- Avec mise en cache

- En couches

- Interface uniforme

===Service pub/sub avec REST===
On peut réaliser un équivalent de service pub/sub avec REST à l'aide de GET et de POST qui agissent sur une base de données géré par un serveur:

[[Fichier:PubSub avec REST.png]]

Cette méthode comprend cependant de nombreux problèmes, notamment le fait que le client 1 ne sais pas si le client 2 à poster une donnée sur le serveur. On ne peut pas vraiment parler ici de service publish/subscribe car il n'y a pas d'abonnement, le client qui devrait s'abonner doit aller récupérer lui-même la donnée sans savoir si elle est bien dans la base de données du serveur.

==Protocole Hybride==

La technologie Pub/Sub et la technologie REST ont toutes deux leurs avantages et leurs inconvénients:

'''Avantages Pub/Sub :'''
<ul>
<li>Transfère rapide des informations</li>
<li>stockage des messages automatiques</li>
<li>gestion de la qualité de service</li>
</ul>
'''Inconvénient Pub/Sub:'''
<ul>
<li>On ne peut pas faire d’action direct sur le message, on ne fait un traitement dessus que lorsqu'on l'a reçu.</li>
<li>protocole mqtt,qui bloquer par certain par feu</li>
</ul>
'''
Avantages REST:'''
<ul>
<li>protocole http(port 80) passe partout dans le monde</li>
<li>on peut traiter le message directement sur le serveur</li>
</ul>
'''
Inconvénient REST:'''
<ul>
<li>On doit installer un serveur web, on doit géré une base de donnée (ou XML, Json).</li>
</ul>

L'objectif du protocole hybride est de réaliser un système pub/sub tel que l'on ai:
<ul>
<li>un transfère rapide des informations</li>
<li>un stockage des messages automatiques</li>
<li>une gestion de la qualité de service</li>
<li>le protocole http (port 80) de sorte à ce qu'il fonctionne partout dans le monde.</li>
</ul>

Pour cela, nous allons nous servir des Websockets.

===MQTT sur Websocket===

Le protocole Websocket est un protocole qui vise à développer un canal de communication web sur une connexion TCP.

Les objectifs de ce protocole était notamment de permettre au serveur l'envoi de données vers le client en mode push (sans que l'utilisateur n'ai à faire une requête).

==Sources==

[https://fr.wikipedia.org/wiki/Publish-subscribe Pub/Sub]

[https://fr.wikipedia.org/wiki/MQTT MQTT]

[https://pypi.org/project/paho-mqtt/ paho-mqtt]

[https://fr.wikipedia.org/wiki/Representational_state_transfer REST]

[https://fr.wikipedia.org/wiki/WebSocket Websocket]

Rest & Pub-Sub : protocole hybride pour l'IoT

2019-05-19T22:34:40Z

Rakotoanosy : /* MQTT sur des Websocket */

== Introduction ==

== MQTT ==
MQTT, Message Queuing Telemetry Transport, est un protocole publish/subscribe se basant sur le protocole TCP/IP.
Il a été créé par Andy Stanford-Clark et Arlen Nipper.

De façon concrète, MQTT permet à des appareils de publier des informations sur un sujet donné sur un broker (un serveur qui fonctionne comme un coursier) qui va les retransmettre aux appareils abonnés à ce sujet.

[[Fichier:Fonctionnement broker mqtt.png|600px|thumb|left|illustration d'un échange entre un client 1 "subscriber" et un client 2 "publisher"]]

MQTT gère aussi la qualité de service (d'une qualité 0 à une qualité 2):

Qualité 0: le client qui publie une donnée ne reçoit aucune information par rapport à la confirmation de son arrivé.

Qualité 1: le client qui publie reçoit la confirmation ou non que la donnée publier à été reçu par le broker.

Qualité 2: le client qui publie reçoit la confirmation ou non que la donnée publier à été reçu par le broker ainsi qu'un message lui indiquant que le client qui s'abonne à reçu la donnée.
===Mosquitto===
Mosquitto est un broker open-source qui se sert du protocole MQTT. Il permet une fois installé de se familiarisé avec MQTT et le "publish/subscribe".

Nous nous en somme servit ici sur une MachineVirtuel en publiant en localhost:

[[Fichier:Mosquitto exemple.png]]

Sur un premier terminal on s'abonne à un topic "température" et sur un deuxième terminal, on publie ensuite sur ce même topic des nombres (qui s'apparentent à des température). Au fur et à mesure que nous publions ces informations, nous les recevons sur le premier terminal.
Mosquitto remplit bien ici son rôle de broker.

===Pub/Sub avec Python===

Nous avons ensuite développer un client ''publisher'' et un client ''subscriber'' en python grâce à la librairie paho-mqtt.
Pour plus de simplicité et éviter des problèmes de timing, nous avons tout regrouper en un seul programme:

import paho.mqtt.client as mqtt
import time

broker="test.mosquitto.org"

def envoi_message(client, QoS, message):
print("message reçu :", str(message.payload.decode("utf-8")))

client= mqtt.Client("client_test")
client.on_message=envoi_message

client.connect(broker)
print("connection")
client.loop_start()
client.subscribe("Cafetière/temperature_cafe")
print("Abonnement...")
time.sleep(1)
pub= input("entrez une température (un nombre):")
print("Publication...")
time.sleep(1)
client.publish("Cafetière/temperature_cafe",pub +"°C")
time.sleep(1)
client.disconnect()
print("deconnection")
client.loop_stop()
Comme broker, nous nous somme servit ici d'un broker mit en libre service par mosquitto.

==REST==
REST (Representational State Transfer) aussi appeler restful est une architecture logiciel inventer par Roy Fielding qui se sert des verbes HTTP comme identifiant des opérations et des réponses HTTP comme représentation des ressources.

Une architecture REST est définit par 5 règles/contraintes :

- Client–serveur

- Sans état

- Avec mise en cache

- En couches

- Interface uniforme

===Service pub/sub avec REST===
On peut réaliser un équivalent de service pub/sub avec REST à l'aide de GET et de POST qui agissent sur une base de données géré par un serveur:

[[Fichier:PubSub avec REST.png]]

Cette méthode comprend cependant de nombreux problèmes, notamment le fait que le client 1 ne sais pas si le client 2 à poster une donnée sur le serveur. On ne peut pas vraiment parler ici de service publish/subscribe car il n'y a pas d'abonnement, le client qui devrait s'abonner doit aller récupérer lui-même la donnée sans savoir si elle est bien situer sur le serveur.

==Protocole Hybride==

La technologie Pub/Sub et la technologie REST ont toutes deux leurs avantages et leurs inconvénients:

'''Avantages Pub/Sub :'''
<ul>
<li>Transfère rapide des informations</li>
<li>stockage des messages automatiques</li>
<li>gestion de la qualité de service</li>
</ul>
'''Inconvénient Pub/Sub:'''
<ul>
<li>On ne peut pas faire d’action direct sur le message, on ne fait un traitement dessus que lorsqu'on l'a reçu.</li>
<li>protocole mqtt,qui bloquer par certain par feu</li>
</ul>
'''
Avantages REST:'''
<ul>
<li>protocole http(port 80) passe partout dans le monde</li>
<li>on peut traiter le message directement sur le serveur</li>
</ul>
'''
Inconvénient REST:'''
<ul>
<li>On doit installer un serveur web, on doit géré une base de donnée (ou XML, Json).</li>
</ul>

L'objectif du protocole hybride est de réaliser un système pub/sub tel que l'on ai:
<ul>
<li>un transfère rapide des informations</li>
<li>un stockage des messages automatiques</li>
<li>une gestion de la qualité de service</li>
<li>le protocole http (port 80) de sorte à ce qu'il fonctionne partout dans le monde.</li>
</ul>

Pour cela, nous allons nous servir des Websockets.

===MQTT sur Websocket===

Le protocole Websocket est un protocole qui vise à développer un canal de communication web sur une connexion TCP.

Les objectifs de ce protocole était notamment de permettre au serveur l'envoi de données vers le client en mode push (sans que l'utilisateur n'ai à faire une requête).

==Sources==

[https://fr.wikipedia.org/wiki/Publish-subscribe Pub/Sub]

[https://fr.wikipedia.org/wiki/MQTT MQTT]

[https://pypi.org/project/paho-mqtt/ paho-mqtt]

[https://fr.wikipedia.org/wiki/Representational_state_transfer REST]

[https://fr.wikipedia.org/wiki/WebSocket Websocket]

Rest & Pub-Sub : protocole hybride pour l'IoT

2019-05-19T21:37:58Z

Rakotoanosy : /* Protocole Hybride */

== Introduction ==

== MQTT ==
MQTT, Message Queuing Telemetry Transport, est un protocole publish/subscribe se basant sur le protocole TCP/IP.
Il a été créé par Andy Stanford-Clark et Arlen Nipper.

De façon concrète, MQTT permet à des appareils de publier des informations sur un sujet donné sur un broker (un serveur qui fonctionne comme un coursier) qui va les retransmettre aux appareils abonnés à ce sujet.

[[Fichier:Fonctionnement broker mqtt.png|600px|thumb|left|illustration d'un échange entre un client 1 "subscriber" et un client 2 "publisher"]]

MQTT gère aussi la qualité de service (d'une qualité 0 à une qualité 2):

Qualité 0: le client qui publie une donnée ne reçoit aucune information par rapport à la confirmation de son arrivé.

Qualité 1: le client qui publie reçoit la confirmation ou non que la donnée publier à été reçu par le broker.

Qualité 2: le client qui publie reçoit la confirmation ou non que la donnée publier à été reçu par le broker ainsi qu'un message lui indiquant que le client qui s'abonne à reçu la donnée.
===Mosquitto===
Mosquitto est un broker open-source qui se sert du protocole MQTT. Il permet une fois installé de se familiarisé avec MQTT et le "publish/subscribe".

Nous nous en somme servit ici sur une MachineVirtuel en publiant en localhost:

[[Fichier:Mosquitto exemple.png]]

Sur un premier terminal on s'abonne à un topic "température" et sur un deuxième terminal, on publie ensuite sur ce même topic des nombres (qui s'apparentent à des température). Au fur et à mesure que nous publions ces informations, nous les recevons sur le premier terminal.
Mosquitto remplit bien ici son rôle de broker.

===Pub/Sub avec Python===

Nous avons ensuite développer un client ''publisher'' et un client ''subscriber'' en python grâce à la librairie paho-mqtt.
Pour plus de simplicité et éviter des problèmes de timing, nous avons tout regrouper en un seul programme:

import paho.mqtt.client as mqtt
import time

broker="test.mosquitto.org"

def envoi_message(client, QoS, message):
print("message reçu :", str(message.payload.decode("utf-8")))

client= mqtt.Client("client_test")
client.on_message=envoi_message

client.connect(broker)
print("connection")
client.loop_start()
client.subscribe("Cafetière/temperature_cafe")
print("Abonnement...")
time.sleep(1)
pub= input("entrez une température (un nombre):")
print("Publication...")
time.sleep(1)
client.publish("Cafetière/temperature_cafe",pub +"°C")
time.sleep(1)
client.disconnect()
print("deconnection")
client.loop_stop()
Comme broker, nous nous somme servit ici d'un broker mit en libre service par mosquitto.

==REST==
REST (Representational State Transfer) aussi appeler restful est une architecture logiciel inventer par Roy Fielding qui se sert des verbes HTTP comme identifiant des opérations et des réponses HTTP comme représentation des ressources.

Une architecture REST est définit par 5 règles/contraintes :

- Client–serveur

- Sans état

- Avec mise en cache

- En couches

- Interface uniforme

===Service pub/sub avec REST===
On peut réaliser un équivalent de service pub/sub avec REST à l'aide de GET et de POST qui agissent sur une base de données géré par un serveur:

[[Fichier:PubSub avec REST.png]]

Cette méthode comprend cependant de nombreux problèmes, notamment le fait que le client 1 ne sais pas si le client 2 à poster une donnée sur le serveur. On ne peut pas vraiment parler ici de service publish/subscribe car il n'y a pas d'abonnement, le client qui devrait s'abonner doit aller récupérer lui-même la donnée sans savoir si elle est bien situer sur le serveur.

==Protocole Hybride==

La technologie Pub/Sub et la technologie REST ont toutes deux leurs avantages et leurs inconvénients:

'''Avantages Pub/Sub :'''
<ul>
<li>Transfère rapide des informations</li>
<li>stockage des messages automatiques</li>
<li>gestion de la qualité de service</li>
</ul>
'''Inconvénient Pub/Sub:'''
<ul>
<li>On ne peut pas faire d’action direct sur le message, on ne fait un traitement dessus que lorsqu'on l'a reçu.</li>
<li>protocole mqtt,qui bloquer par certain par feu</li>
</ul>
'''
Avantages REST:'''
<ul>
<li>protocole http(port 80) passe partout dans le monde</li>
<li>on peut traiter le message directement sur le serveur</li>
</ul>
'''
Inconvénient REST:'''
<ul>
<li>On doit installer un serveur web, on doit géré une base de donnée (ou XML, Json).</li>
</ul>

L'objectif du protocole hybride est de réaliser un système pub/sub tel que l'on ai:
<ul>
<li>un transfère rapide des informations</li>
<li>un stockage des messages automatiques</li>
<li>une gestion de la qualité de service</li>
<li>le protocole http (port 80) de sorte à ce qu'il fonctionne partout dans le monde.</li>
</ul>

Pour cela, nous allons nous servir des Websockets.

===MQTT sur des Websocket===

==Sources==

[https://fr.wikipedia.org/wiki/Publish-subscribe Pub/Sub]

[https://fr.wikipedia.org/wiki/MQTT MQTT]

[https://pypi.org/project/paho-mqtt/ paho-mqtt]

[https://fr.wikipedia.org/wiki/Representational_state_transfer REST]

[https://fr.wikipedia.org/wiki/WebSocket Websocket]

Rest & Pub-Sub : protocole hybride pour l'IoT

2019-05-19T21:34:47Z

Rakotoanosy : /* Sources */

== Introduction ==

== MQTT ==
MQTT, Message Queuing Telemetry Transport, est un protocole publish/subscribe se basant sur le protocole TCP/IP.
Il a été créé par Andy Stanford-Clark et Arlen Nipper.

De façon concrète, MQTT permet à des appareils de publier des informations sur un sujet donné sur un broker (un serveur qui fonctionne comme un coursier) qui va les retransmettre aux appareils abonnés à ce sujet.

[[Fichier:Fonctionnement broker mqtt.png|600px|thumb|left|illustration d'un échange entre un client 1 "subscriber" et un client 2 "publisher"]]

MQTT gère aussi la qualité de service (d'une qualité 0 à une qualité 2):

Qualité 0: le client qui publie une donnée ne reçoit aucune information par rapport à la confirmation de son arrivé.

Qualité 1: le client qui publie reçoit la confirmation ou non que la donnée publier à été reçu par le broker.

Qualité 2: le client qui publie reçoit la confirmation ou non que la donnée publier à été reçu par le broker ainsi qu'un message lui indiquant que le client qui s'abonne à reçu la donnée.
===Mosquitto===
Mosquitto est un broker open-source qui se sert du protocole MQTT. Il permet une fois installé de se familiarisé avec MQTT et le "publish/subscribe".

Nous nous en somme servit ici sur une MachineVirtuel en publiant en localhost:

[[Fichier:Mosquitto exemple.png]]

Sur un premier terminal on s'abonne à un topic "température" et sur un deuxième terminal, on publie ensuite sur ce même topic des nombres (qui s'apparentent à des température). Au fur et à mesure que nous publions ces informations, nous les recevons sur le premier terminal.
Mosquitto remplit bien ici son rôle de broker.

===Pub/Sub avec Python===

Nous avons ensuite développer un client ''publisher'' et un client ''subscriber'' en python grâce à la librairie paho-mqtt.
Pour plus de simplicité et éviter des problèmes de timing, nous avons tout regrouper en un seul programme:

import paho.mqtt.client as mqtt
import time

broker="test.mosquitto.org"

def envoi_message(client, QoS, message):
print("message reçu :", str(message.payload.decode("utf-8")))

client= mqtt.Client("client_test")
client.on_message=envoi_message

client.connect(broker)
print("connection")
client.loop_start()
client.subscribe("Cafetière/temperature_cafe")
print("Abonnement...")
time.sleep(1)
pub= input("entrez une température (un nombre):")
print("Publication...")
time.sleep(1)
client.publish("Cafetière/temperature_cafe",pub +"°C")
time.sleep(1)
client.disconnect()
print("deconnection")
client.loop_stop()
Comme broker, nous nous somme servit ici d'un broker mit en libre service par mosquitto.

==REST==
REST (Representational State Transfer) aussi appeler restful est une architecture logiciel inventer par Roy Fielding qui se sert des verbes HTTP comme identifiant des opérations et des réponses HTTP comme représentation des ressources.

Une architecture REST est définit par 5 règles/contraintes :

- Client–serveur

- Sans état

- Avec mise en cache

- En couches

- Interface uniforme

===Service pub/sub avec REST===
On peut réaliser un équivalent de service pub/sub avec REST à l'aide de GET et de POST qui agissent sur une base de données géré par un serveur:

[[Fichier:PubSub avec REST.png]]

Cette méthode comprend cependant de nombreux problèmes, notamment le fait que le client 1 ne sais pas si le client 2 à poster une donnée sur le serveur. On ne peut pas vraiment parler ici de service publish/subscribe car il n'y a pas d'abonnement, le client qui devrait s'abonner doit aller récupérer lui-même la donnée sans savoir si elle est bien situer sur le serveur.

==Protocole Hybride==

La technologie Pub/Sub et la technologie REST ont toutes deux leurs avantages et leurs inconvénients:

'''Avantages Pub/Sub :'''

- Transfère rapide des informations

- stockage des messages automatiques

- gestion de la qualité de service

'''Inconvénient Pub/Sub:'''

- On ne peut pas faire d’action direct sur le message, on ne fait un traitement dessus que lorsqu'on l'a reçu.

- protocole mqtt,qui bloquer par certain par feu
'''
Avantages REST:'''

- protocole http(port 80) passe partout dans le monde

- on peut traiter le message directement sur le serveur
'''
Inconvénient REST:'''

- On doit installer un serveur web, on doit géré une base de donnée (ou XML, Json).

L'objectif du protocole hybride est de réaliser un système pub/sub tel que l'on ai:

- un transfère rapide des informations

- un stockage des messages automatiques

- une gestion de la qualité de service

- le protocole http (port 80) de sorte à ce qu'il fonctionne partout dans le monde.

Pour cela, nous allons nous servir des Websockets.

===MQTT sur des Websocket===

==Sources==

[https://fr.wikipedia.org/wiki/Publish-subscribe Pub/Sub]

[https://fr.wikipedia.org/wiki/MQTT MQTT]

[https://pypi.org/project/paho-mqtt/ paho-mqtt]

[https://fr.wikipedia.org/wiki/Representational_state_transfer REST]

[https://fr.wikipedia.org/wiki/WebSocket Websocket]

Rest & Pub-Sub : protocole hybride pour l'IoT

2019-05-19T21:31:18Z

Rakotoanosy : /* MQTT sur des Websocket */

== Introduction ==

== MQTT ==
MQTT, Message Queuing Telemetry Transport, est un protocole publish/subscribe se basant sur le protocole TCP/IP.
Il a été créé par Andy Stanford-Clark et Arlen Nipper.

De façon concrète, MQTT permet à des appareils de publier des informations sur un sujet donné sur un broker (un serveur qui fonctionne comme un coursier) qui va les retransmettre aux appareils abonnés à ce sujet.

[[Fichier:Fonctionnement broker mqtt.png|600px|thumb|left|illustration d'un échange entre un client 1 "subscriber" et un client 2 "publisher"]]

MQTT gère aussi la qualité de service (d'une qualité 0 à une qualité 2):

Qualité 0: le client qui publie une donnée ne reçoit aucune information par rapport à la confirmation de son arrivé.

Qualité 1: le client qui publie reçoit la confirmation ou non que la donnée publier à été reçu par le broker.

Qualité 2: le client qui publie reçoit la confirmation ou non que la donnée publier à été reçu par le broker ainsi qu'un message lui indiquant que le client qui s'abonne à reçu la donnée.
===Mosquitto===
Mosquitto est un broker open-source qui se sert du protocole MQTT. Il permet une fois installé de se familiarisé avec MQTT et le "publish/subscribe".

Nous nous en somme servit ici sur une MachineVirtuel en publiant en localhost:

[[Fichier:Mosquitto exemple.png]]

Sur un premier terminal on s'abonne à un topic "température" et sur un deuxième terminal, on publie ensuite sur ce même topic des nombres (qui s'apparentent à des température). Au fur et à mesure que nous publions ces informations, nous les recevons sur le premier terminal.
Mosquitto remplit bien ici son rôle de broker.

===Pub/Sub avec Python===

Nous avons ensuite développer un client ''publisher'' et un client ''subscriber'' en python grâce à la librairie paho-mqtt.
Pour plus de simplicité et éviter des problèmes de timing, nous avons tout regrouper en un seul programme:

import paho.mqtt.client as mqtt
import time

broker="test.mosquitto.org"

def envoi_message(client, QoS, message):
print("message reçu :", str(message.payload.decode("utf-8")))

client= mqtt.Client("client_test")
client.on_message=envoi_message

client.connect(broker)
print("connection")
client.loop_start()
client.subscribe("Cafetière/temperature_cafe")
print("Abonnement...")
time.sleep(1)
pub= input("entrez une température (un nombre):")
print("Publication...")
time.sleep(1)
client.publish("Cafetière/temperature_cafe",pub +"°C")
time.sleep(1)
client.disconnect()
print("deconnection")
client.loop_stop()
Comme broker, nous nous somme servit ici d'un broker mit en libre service par mosquitto.

==REST==
REST (Representational State Transfer) aussi appeler restful est une architecture logiciel inventer par Roy Fielding qui se sert des verbes HTTP comme identifiant des opérations et des réponses HTTP comme représentation des ressources.

Une architecture REST est définit par 5 règles/contraintes :

- Client–serveur

- Sans état

- Avec mise en cache

- En couches

- Interface uniforme

===Service pub/sub avec REST===
On peut réaliser un équivalent de service pub/sub avec REST à l'aide de GET et de POST qui agissent sur une base de données géré par un serveur:

[[Fichier:PubSub avec REST.png]]

Cette méthode comprend cependant de nombreux problèmes, notamment le fait que le client 1 ne sais pas si le client 2 à poster une donnée sur le serveur. On ne peut pas vraiment parler ici de service publish/subscribe car il n'y a pas d'abonnement, le client qui devrait s'abonner doit aller récupérer lui-même la donnée sans savoir si elle est bien situer sur le serveur.

==Protocole Hybride==

La technologie Pub/Sub et la technologie REST ont toutes deux leurs avantages et leurs inconvénients:

'''Avantages Pub/Sub :'''

- Transfère rapide des informations

- stockage des messages automatiques

- gestion de la qualité de service

'''Inconvénient Pub/Sub:'''

- On ne peut pas faire d’action direct sur le message, on ne fait un traitement dessus que lorsqu'on l'a reçu.

- protocole mqtt,qui bloquer par certain par feu
'''
Avantages REST:'''

- protocole http(port 80) passe partout dans le monde

- on peut traiter le message directement sur le serveur
'''
Inconvénient REST:'''

- On doit installer un serveur web, on doit géré une base de donnée (ou XML, Json).

L'objectif du protocole hybride est de réaliser un système pub/sub tel que l'on ai:

- un transfère rapide des informations

- un stockage des messages automatiques

- une gestion de la qualité de service

- le protocole http (port 80) de sorte à ce qu'il fonctionne partout dans le monde.

Pour cela, nous allons nous servir des Websockets.

===MQTT sur des Websocket===

==Sources==

[https://pypi.org/project/paho-mqtt/ paho-mqtt]

Rest & Pub-Sub : protocole hybride pour l'IoT

2019-05-19T21:28:55Z

Rakotoanosy :

== Introduction ==

== MQTT ==
MQTT, Message Queuing Telemetry Transport, est un protocole publish/subscribe se basant sur le protocole TCP/IP.
Il a été créé par Andy Stanford-Clark et Arlen Nipper.

De façon concrète, MQTT permet à des appareils de publier des informations sur un sujet donné sur un broker (un serveur qui fonctionne comme un coursier) qui va les retransmettre aux appareils abonnés à ce sujet.

[[Fichier:Fonctionnement broker mqtt.png|600px|thumb|left|illustration d'un échange entre un client 1 "subscriber" et un client 2 "publisher"]]

MQTT gère aussi la qualité de service (d'une qualité 0 à une qualité 2):

Qualité 0: le client qui publie une donnée ne reçoit aucune information par rapport à la confirmation de son arrivé.

Qualité 1: le client qui publie reçoit la confirmation ou non que la donnée publier à été reçu par le broker.

Qualité 2: le client qui publie reçoit la confirmation ou non que la donnée publier à été reçu par le broker ainsi qu'un message lui indiquant que le client qui s'abonne à reçu la donnée.
===Mosquitto===
Mosquitto est un broker open-source qui se sert du protocole MQTT. Il permet une fois installé de se familiarisé avec MQTT et le "publish/subscribe".

Nous nous en somme servit ici sur une MachineVirtuel en publiant en localhost:

[[Fichier:Mosquitto exemple.png]]

Sur un premier terminal on s'abonne à un topic "température" et sur un deuxième terminal, on publie ensuite sur ce même topic des nombres (qui s'apparentent à des température). Au fur et à mesure que nous publions ces informations, nous les recevons sur le premier terminal.
Mosquitto remplit bien ici son rôle de broker.

===Pub/Sub avec Python===

Nous avons ensuite développer un client ''publisher'' et un client ''subscriber'' en python grâce à la librairie paho-mqtt.
Pour plus de simplicité et éviter des problèmes de timing, nous avons tout regrouper en un seul programme:

import paho.mqtt.client as mqtt
import time

broker="test.mosquitto.org"

def envoi_message(client, QoS, message):
print("message reçu :", str(message.payload.decode("utf-8")))

client= mqtt.Client("client_test")
client.on_message=envoi_message

client.connect(broker)
print("connection")
client.loop_start()
client.subscribe("Cafetière/temperature_cafe")
print("Abonnement...")
time.sleep(1)
pub= input("entrez une température (un nombre):")
print("Publication...")
time.sleep(1)
client.publish("Cafetière/temperature_cafe",pub +"°C")
time.sleep(1)
client.disconnect()
print("deconnection")
client.loop_stop()
Comme broker, nous nous somme servit ici d'un broker mit en libre service par mosquitto.

==REST==
REST (Representational State Transfer) aussi appeler restful est une architecture logiciel inventer par Roy Fielding qui se sert des verbes HTTP comme identifiant des opérations et des réponses HTTP comme représentation des ressources.

Une architecture REST est définit par 5 règles/contraintes :

- Client–serveur

- Sans état

- Avec mise en cache

- En couches

- Interface uniforme

===Service pub/sub avec REST===
On peut réaliser un équivalent de service pub/sub avec REST à l'aide de GET et de POST qui agissent sur une base de données géré par un serveur:

[[Fichier:PubSub avec REST.png]]

Cette méthode comprend cependant de nombreux problèmes, notamment le fait que le client 1 ne sais pas si le client 2 à poster une donnée sur le serveur. On ne peut pas vraiment parler ici de service publish/subscribe car il n'y a pas d'abonnement, le client qui devrait s'abonner doit aller récupérer lui-même la donnée sans savoir si elle est bien situer sur le serveur.

==Protocole Hybride==

La technologie Pub/Sub et la technologie REST ont toutes deux leurs avantages et leurs inconvénients:

'''Avantages Pub/Sub :'''

- Transfère rapide des informations

- stockage des messages automatiques

- gestion de la qualité de service

'''Inconvénient Pub/Sub:'''

- On ne peut pas faire d’action direct sur le message, on ne fait un traitement dessus que lorsqu'on l'a reçu.

- protocole mqtt,qui bloquer par certain par feu
'''
Avantages REST:'''

- protocole http(port 80) passe partout dans le monde

- on peut traiter le message directement sur le serveur
'''
Inconvénient REST:'''

- On doit installer un serveur web, on doit géré une base de donnée (ou XML, Json).

L'objectif du protocole hybride est de réaliser un système pub/sub tel que l'on ai:

- un transfère rapide des informations

- un stockage des messages automatiques

- une gestion de la qualité de service

- le protocole http (port 80) de sorte à ce qu'il fonctionne partout dans le monde.

Pour cela, nous allons nous servir des Websockets.

===MQTT sur des Websocket===

Rest & Pub-Sub : protocole hybride pour l'IoT

2019-05-19T21:26:51Z

Rakotoanosy : /* Mosquitto */

== Introduction ==

Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.

== MQTT ==
MQTT, Message Queuing Telemetry Transport, est un protocole publish/subscribe se basant sur le protocole TCP/IP.
Il a été créé par Andy Stanford-Clark et Arlen Nipper.

De façon concrète, MQTT permet à des appareils de publier des informations sur un sujet donné sur un broker (un serveur qui fonctionne comme un coursier) qui va les retransmettre aux appareils abonnés à ce sujet.

[[Fichier:Fonctionnement broker mqtt.png|600px|thumb|left|illustration d'un échange entre un client 1 "subscriber" et un client 2 "publisher"]]

MQTT gère aussi la qualité de service (d'une qualité 0 à une qualité 2):

Qualité 0: le client qui publie une donnée ne reçoit aucune information par rapport à la confirmation de son arrivé.

Qualité 1: le client qui publie reçoit la confirmation ou non que la donnée publier à été reçu par le broker.

Qualité 2: le client qui publie reçoit la confirmation ou non que la donnée publier à été reçu par le broker ainsi qu'un message lui indiquant que le client qui s'abonne à reçu la donnée.
===Mosquitto===
Mosquitto est un broker open-source qui se sert du protocole MQTT. Il permet une fois installé de se familiarisé avec MQTT et le "publish/subscribe".

Nous nous en somme servit ici sur une MachineVirtuel en publiant en localhost:

[[Fichier:Mosquitto exemple.png]]

Sur un premier terminal on s'abonne à un topic "température" et sur un deuxième terminal, on publie ensuite sur ce même topic des nombres (qui s'apparentent à des température). Au fur et à mesure que nous publions ces informations, nous les recevons sur le premier terminal.
Mosquitto remplit bien ici son rôle de broker.

===Pub/Sub avec Python===

Nous avons ensuite développer un client ''publisher'' et un client ''subscriber'' en python grâce à la librairie paho-mqtt.
Pour plus de simplicité et éviter des problèmes de timing, nous avons tout regrouper en un seul programme:

import paho.mqtt.client as mqtt
import time

broker="test.mosquitto.org"

def envoi_message(client, QoS, message):
print("message reçu :", str(message.payload.decode("utf-8")))

client= mqtt.Client("client_test")
client.on_message=envoi_message

client.connect(broker)
print("connection")
client.loop_start()
client.subscribe("Cafetière/temperature_cafe")
print("Abonnement...")
time.sleep(1)
pub= input("entrez une température (un nombre):")
print("Publication...")
time.sleep(1)
client.publish("Cafetière/temperature_cafe",pub +"°C")
time.sleep(1)
client.disconnect()
print("deconnection")
client.loop_stop()
Comme broker, nous nous somme servit ici d'un broker mit en libre service par mosquitto.

==REST==
REST (Representational State Transfer) aussi appeler restful est une architecture logiciel inventer par Roy Fielding qui se sert des verbes HTTP comme identifiant des opérations et des réponses HTTP comme représentation des ressources.

Une architecture REST est définit par 5 règles/contraintes :

- Client–serveur

- Sans état

- Avec mise en cache

- En couches

- Interface uniforme

===Service pub/sub avec REST===
On peut réaliser un équivalent de service pub/sub avec REST à l'aide de GET et de POST qui agissent sur une base de données géré par un serveur:

[[Fichier:PubSub avec REST.png]]

Cette méthode comprend cependant de nombreux problèmes, notamment le fait que le client 1 ne sais pas si le client 2 à poster une donnée sur le serveur. On ne peut pas vraiment parler ici de service publish/subscribe car il n'y a pas d'abonnement, le client qui devrait s'abonner doit aller récupérer lui-même la donnée sans savoir si elle est bien situer sur le serveur.

==Protocole Hybride==

La technologie Pub/Sub et la technologie REST ont toutes deux leurs avantages et leurs inconvénients:

'''Avantages Pub/Sub :'''

- Transfère rapide des informations

- stockage des messages automatiques

- gestion de la qualité de service

'''Inconvénient Pub/Sub:'''

- On ne peut pas faire d’action direct sur le message, on ne fait un traitement dessus que lorsqu'on l'a reçu.

- protocole mqtt,qui bloquer par certain par feu
'''
Avantages REST:'''

- protocole http(port 80) passe partout dans le monde

- on peut traiter le message directement sur le serveur
'''
Inconvénient REST:'''

- On doit installer un serveur web, on doit géré une base de donnée (ou XML, Json).

L'objectif du protocole hybride est de réaliser un système pub/sub tel que l'on ai:

- un transfère rapide des informations

- un stockage des messages automatiques

- une gestion de la qualité de service

- le protocole http (port 80) de sorte à ce qu'il fonctionne partout dans le monde.

Pour cela, nous allons nous servir des Websockets.

===MQTT sur des Websocket===

Rest & Pub-Sub : protocole hybride pour l'IoT

2019-05-19T21:26:34Z

Rakotoanosy : /* Mosquitto */

== Introduction ==

Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.

== MQTT ==
MQTT, Message Queuing Telemetry Transport, est un protocole publish/subscribe se basant sur le protocole TCP/IP.
Il a été créé par Andy Stanford-Clark et Arlen Nipper.

De façon concrète, MQTT permet à des appareils de publier des informations sur un sujet donné sur un broker (un serveur qui fonctionne comme un coursier) qui va les retransmettre aux appareils abonnés à ce sujet.

[[Fichier:Fonctionnement broker mqtt.png|600px|thumb|left|illustration d'un échange entre un client 1 "subscriber" et un client 2 "publisher"]]

MQTT gère aussi la qualité de service (d'une qualité 0 à une qualité 2):

Qualité 0: le client qui publie une donnée ne reçoit aucune information par rapport à la confirmation de son arrivé.

Qualité 1: le client qui publie reçoit la confirmation ou non que la donnée publier à été reçu par le broker.

Qualité 2: le client qui publie reçoit la confirmation ou non que la donnée publier à été reçu par le broker ainsi qu'un message lui indiquant que le client qui s'abonne à reçu la donnée.
===Mosquitto===
Mosquitto est un broker open-source qui se sert du protocole MQTT. Il permet une fois installé de se familiarisé avec MQTT et le "publish/subscribe".

Nous nous en somme servit ici sur une MachineVirtuel Ubuntu en publiant en localhost:

[[Fichier:Mosquitto exemple.png]]

Sur un premier terminal on s'abonne à un topic "température" et sur un deuxième terminal, on publie ensuite sur ce même topic des nombres (qui s'apparentent à des température). Au fur et à mesure que nous publions ces informations, nous les recevons sur le premier terminal.
Mosquitto remplit bien ici son rôle de broker.

===Pub/Sub avec Python===

Nous avons ensuite développer un client ''publisher'' et un client ''subscriber'' en python grâce à la librairie paho-mqtt.
Pour plus de simplicité et éviter des problèmes de timing, nous avons tout regrouper en un seul programme:

import paho.mqtt.client as mqtt
import time

broker="test.mosquitto.org"

def envoi_message(client, QoS, message):
print("message reçu :", str(message.payload.decode("utf-8")))

client= mqtt.Client("client_test")
client.on_message=envoi_message

client.connect(broker)
print("connection")
client.loop_start()
client.subscribe("Cafetière/temperature_cafe")
print("Abonnement...")
time.sleep(1)
pub= input("entrez une température (un nombre):")
print("Publication...")
time.sleep(1)
client.publish("Cafetière/temperature_cafe",pub +"°C")
time.sleep(1)
client.disconnect()
print("deconnection")
client.loop_stop()
Comme broker, nous nous somme servit ici d'un broker mit en libre service par mosquitto.

==REST==
REST (Representational State Transfer) aussi appeler restful est une architecture logiciel inventer par Roy Fielding qui se sert des verbes HTTP comme identifiant des opérations et des réponses HTTP comme représentation des ressources.

Une architecture REST est définit par 5 règles/contraintes :

- Client–serveur

- Sans état

- Avec mise en cache

- En couches

- Interface uniforme

===Service pub/sub avec REST===
On peut réaliser un équivalent de service pub/sub avec REST à l'aide de GET et de POST qui agissent sur une base de données géré par un serveur:

[[Fichier:PubSub avec REST.png]]

Cette méthode comprend cependant de nombreux problèmes, notamment le fait que le client 1 ne sais pas si le client 2 à poster une donnée sur le serveur. On ne peut pas vraiment parler ici de service publish/subscribe car il n'y a pas d'abonnement, le client qui devrait s'abonner doit aller récupérer lui-même la donnée sans savoir si elle est bien situer sur le serveur.

==Protocole Hybride==

La technologie Pub/Sub et la technologie REST ont toutes deux leurs avantages et leurs inconvénients:

'''Avantages Pub/Sub :'''

- Transfère rapide des informations

- stockage des messages automatiques

- gestion de la qualité de service

'''Inconvénient Pub/Sub:'''

- On ne peut pas faire d’action direct sur le message, on ne fait un traitement dessus que lorsqu'on l'a reçu.

- protocole mqtt,qui bloquer par certain par feu
'''
Avantages REST:'''

- protocole http(port 80) passe partout dans le monde

- on peut traiter le message directement sur le serveur
'''
Inconvénient REST:'''

- On doit installer un serveur web, on doit géré une base de donnée (ou XML, Json).

L'objectif du protocole hybride est de réaliser un système pub/sub tel que l'on ai:

- un transfère rapide des informations

- un stockage des messages automatiques

- une gestion de la qualité de service

- le protocole http (port 80) de sorte à ce qu'il fonctionne partout dans le monde.

Pour cela, nous allons nous servir des Websockets.

===MQTT sur des Websocket===

Rest & Pub-Sub : protocole hybride pour l'IoT

2019-05-19T21:25:13Z

Rakotoanosy : /* Protocole Hybride */

== Introduction ==

Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.

== MQTT ==
MQTT, Message Queuing Telemetry Transport, est un protocole publish/subscribe se basant sur le protocole TCP/IP.
Il a été créé par Andy Stanford-Clark et Arlen Nipper.

De façon concrète, MQTT permet à des appareils de publier des informations sur un sujet donné sur un broker (un serveur qui fonctionne comme un coursier) qui va les retransmettre aux appareils abonnés à ce sujet.

[[Fichier:Fonctionnement broker mqtt.png|600px|thumb|left|illustration d'un échange entre un client 1 "subscriber" et un client 2 "publisher"]]

MQTT gère aussi la qualité de service (d'une qualité 0 à une qualité 2):

Qualité 0: le client qui publie une donnée ne reçoit aucune information par rapport à la confirmation de son arrivé.

Qualité 1: le client qui publie reçoit la confirmation ou non que la donnée publier à été reçu par le broker.

Qualité 2: le client qui publie reçoit la confirmation ou non que la donnée publier à été reçu par le broker ainsi qu'un message lui indiquant que le client qui s'abonne à reçu la donnée.
===Mosquitto===
Mosquitto est un broker open-source qui se sert du protocole MQTT. Il permet une fois installé de se familiarisé avec MQTT et le "publish/subscribe".

nous nous en somme servit ici en publiant en localhost:

[[Fichier:Mosquitto exemple.png]]

Sur un premier terminal on s'abonne à un topic "température" et sur un deuxième terminal, on publie ensuite sur ce même topic des nombres (qui s'apparentent à des température). Au fur et à mesure que nous publions ces informations, nous les recevons sur le premier terminal.
Mosquitto remplit bien ici son rôle de broker.

===Pub/Sub avec Python===

Nous avons ensuite développer un client ''publisher'' et un client ''subscriber'' en python grâce à la librairie paho-mqtt.
Pour plus de simplicité et éviter des problèmes de timing, nous avons tout regrouper en un seul programme:

import paho.mqtt.client as mqtt
import time

broker="test.mosquitto.org"

def envoi_message(client, QoS, message):
print("message reçu :", str(message.payload.decode("utf-8")))

client= mqtt.Client("client_test")
client.on_message=envoi_message

client.connect(broker)
print("connection")
client.loop_start()
client.subscribe("Cafetière/temperature_cafe")
print("Abonnement...")
time.sleep(1)
pub= input("entrez une température (un nombre):")
print("Publication...")
time.sleep(1)
client.publish("Cafetière/temperature_cafe",pub +"°C")
time.sleep(1)
client.disconnect()
print("deconnection")
client.loop_stop()
Comme broker, nous nous somme servit ici d'un broker mit en libre service par mosquitto.

==REST==
REST (Representational State Transfer) aussi appeler restful est une architecture logiciel inventer par Roy Fielding qui se sert des verbes HTTP comme identifiant des opérations et des réponses HTTP comme représentation des ressources.

Une architecture REST est définit par 5 règles/contraintes :

- Client–serveur

- Sans état

- Avec mise en cache

- En couches

- Interface uniforme

===Service pub/sub avec REST===
On peut réaliser un équivalent de service pub/sub avec REST à l'aide de GET et de POST qui agissent sur une base de données géré par un serveur:

[[Fichier:PubSub avec REST.png]]

Cette méthode comprend cependant de nombreux problèmes, notamment le fait que le client 1 ne sais pas si le client 2 à poster une donnée sur le serveur. On ne peut pas vraiment parler ici de service publish/subscribe car il n'y a pas d'abonnement, le client qui devrait s'abonner doit aller récupérer lui-même la donnée sans savoir si elle est bien situer sur le serveur.

==Protocole Hybride==

La technologie Pub/Sub et la technologie REST ont toutes deux leurs avantages et leurs inconvénients:

'''Avantages Pub/Sub :'''

- Transfère rapide des informations

- stockage des messages automatiques

- gestion de la qualité de service

'''Inconvénient Pub/Sub:'''

- On ne peut pas faire d’action direct sur le message, on ne fait un traitement dessus que lorsqu'on l'a reçu.

- protocole mqtt,qui bloquer par certain par feu
'''
Avantages REST:'''

- protocole http(port 80) passe partout dans le monde

- on peut traiter le message directement sur le serveur
'''
Inconvénient REST:'''

- On doit installer un serveur web, on doit géré une base de donnée (ou XML, Json).

L'objectif du protocole hybride est de réaliser un système pub/sub tel que l'on ai:

- un transfère rapide des informations

- un stockage des messages automatiques

- une gestion de la qualité de service

- le protocole http (port 80) de sorte à ce qu'il fonctionne partout dans le monde.

Pour cela, nous allons nous servir des Websockets.

===MQTT sur des Websocket===

Rest & Pub-Sub : protocole hybride pour l'IoT

2019-05-19T21:23:11Z

Rakotoanosy : /* Protocole Hybride */

== Introduction ==

Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.

== MQTT ==
MQTT, Message Queuing Telemetry Transport, est un protocole publish/subscribe se basant sur le protocole TCP/IP.
Il a été créé par Andy Stanford-Clark et Arlen Nipper.

De façon concrète, MQTT permet à des appareils de publier des informations sur un sujet donné sur un broker (un serveur qui fonctionne comme un coursier) qui va les retransmettre aux appareils abonnés à ce sujet.

[[Fichier:Fonctionnement broker mqtt.png|600px|thumb|left|illustration d'un échange entre un client 1 "subscriber" et un client 2 "publisher"]]

MQTT gère aussi la qualité de service (d'une qualité 0 à une qualité 2):

Qualité 0: le client qui publie une donnée ne reçoit aucune information par rapport à la confirmation de son arrivé.

Qualité 1: le client qui publie reçoit la confirmation ou non que la donnée publier à été reçu par le broker.

Qualité 2: le client qui publie reçoit la confirmation ou non que la donnée publier à été reçu par le broker ainsi qu'un message lui indiquant que le client qui s'abonne à reçu la donnée.
===Mosquitto===
Mosquitto est un broker open-source qui se sert du protocole MQTT. Il permet une fois installé de se familiarisé avec MQTT et le "publish/subscribe".

nous nous en somme servit ici en publiant en localhost:

[[Fichier:Mosquitto exemple.png]]

Sur un premier terminal on s'abonne à un topic "température" et sur un deuxième terminal, on publie ensuite sur ce même topic des nombres (qui s'apparentent à des température). Au fur et à mesure que nous publions ces informations, nous les recevons sur le premier terminal.
Mosquitto remplit bien ici son rôle de broker.

===Pub/Sub avec Python===

Nous avons ensuite développer un client ''publisher'' et un client ''subscriber'' en python grâce à la librairie paho-mqtt.
Pour plus de simplicité et éviter des problèmes de timing, nous avons tout regrouper en un seul programme:

import paho.mqtt.client as mqtt
import time

broker="test.mosquitto.org"

def envoi_message(client, QoS, message):
print("message reçu :", str(message.payload.decode("utf-8")))

client= mqtt.Client("client_test")
client.on_message=envoi_message

client.connect(broker)
print("connection")
client.loop_start()
client.subscribe("Cafetière/temperature_cafe")
print("Abonnement...")
time.sleep(1)
pub= input("entrez une température (un nombre):")
print("Publication...")
time.sleep(1)
client.publish("Cafetière/temperature_cafe",pub +"°C")
time.sleep(1)
client.disconnect()
print("deconnection")
client.loop_stop()
Comme broker, nous nous somme servit ici d'un broker mit en libre service par mosquitto.

==REST==
REST (Representational State Transfer) aussi appeler restful est une architecture logiciel inventer par Roy Fielding qui se sert des verbes HTTP comme identifiant des opérations et des réponses HTTP comme représentation des ressources.

Une architecture REST est définit par 5 règles/contraintes :

- Client–serveur

- Sans état

- Avec mise en cache

- En couches

- Interface uniforme

===Service pub/sub avec REST===
On peut réaliser un équivalent de service pub/sub avec REST à l'aide de GET et de POST qui agissent sur une base de données géré par un serveur:

[[Fichier:PubSub avec REST.png]]

Cette méthode comprend cependant de nombreux problèmes, notamment le fait que le client 1 ne sais pas si le client 2 à poster une donnée sur le serveur. On ne peut pas vraiment parler ici de service publish/subscribe car il n'y a pas d'abonnement, le client qui devrait s'abonner doit aller récupérer lui-même la donnée sans savoir si elle est bien situer sur le serveur.

==Protocole Hybride==

La technologie Pub/Sub et la technologie REST ont toutes deux leurs avantages et leurs inconvénients:

Avantages Pub/Sub :

- Transfère rapide des informations

- stockage des messages automatiques

- gestion de la qualité de service

Inconvénient Pub/Sub:

- On ne peut pas faire d’action direct sur le message, on ne fait un traitement dessus que lorsqu'on l'a reçu.

- protocole mqtt,qui bloquer par certain par feu

Avantages REST:

- protocole http(port 80) passe partout dans le monde

- on peut traiter le message directement sur le serveur

Inconvénient REST:

- On doit installer un serveur web, on doit géré une base de donnée (ou XML, Json).

L'objectif du protocole hybride est de réaliser un système pub/sub tel que l'on ai:

- un transfère rapide des informations

- un stockage des messages automatiques

- une gestion de la qualité de service

- le protocole http (port 80) de sorte à ce qu'il fonctionne partout dans le monde.

Pour cela, nous allons nous servir des Websockets.

===MQTT sur des Websocket===

Rest & Pub-Sub : protocole hybride pour l'IoT

2019-05-19T21:22:11Z

Rakotoanosy : /* Protocole Hybride */

== Introduction ==

Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.

== MQTT ==
MQTT, Message Queuing Telemetry Transport, est un protocole publish/subscribe se basant sur le protocole TCP/IP.
Il a été créé par Andy Stanford-Clark et Arlen Nipper.

De façon concrète, MQTT permet à des appareils de publier des informations sur un sujet donné sur un broker (un serveur qui fonctionne comme un coursier) qui va les retransmettre aux appareils abonnés à ce sujet.

[[Fichier:Fonctionnement broker mqtt.png|600px|thumb|left|illustration d'un échange entre un client 1 "subscriber" et un client 2 "publisher"]]

MQTT gère aussi la qualité de service (d'une qualité 0 à une qualité 2):

Qualité 0: le client qui publie une donnée ne reçoit aucune information par rapport à la confirmation de son arrivé.

Qualité 1: le client qui publie reçoit la confirmation ou non que la donnée publier à été reçu par le broker.

Qualité 2: le client qui publie reçoit la confirmation ou non que la donnée publier à été reçu par le broker ainsi qu'un message lui indiquant que le client qui s'abonne à reçu la donnée.
===Mosquitto===
Mosquitto est un broker open-source qui se sert du protocole MQTT. Il permet une fois installé de se familiarisé avec MQTT et le "publish/subscribe".

nous nous en somme servit ici en publiant en localhost:

[[Fichier:Mosquitto exemple.png]]

Sur un premier terminal on s'abonne à un topic "température" et sur un deuxième terminal, on publie ensuite sur ce même topic des nombres (qui s'apparentent à des température). Au fur et à mesure que nous publions ces informations, nous les recevons sur le premier terminal.
Mosquitto remplit bien ici son rôle de broker.

===Pub/Sub avec Python===

Nous avons ensuite développer un client ''publisher'' et un client ''subscriber'' en python grâce à la librairie paho-mqtt.
Pour plus de simplicité et éviter des problèmes de timing, nous avons tout regrouper en un seul programme:

import paho.mqtt.client as mqtt
import time

broker="test.mosquitto.org"

def envoi_message(client, QoS, message):
print("message reçu :", str(message.payload.decode("utf-8")))

client= mqtt.Client("client_test")
client.on_message=envoi_message

client.connect(broker)
print("connection")
client.loop_start()
client.subscribe("Cafetière/temperature_cafe")
print("Abonnement...")
time.sleep(1)
pub= input("entrez une température (un nombre):")
print("Publication...")
time.sleep(1)
client.publish("Cafetière/temperature_cafe",pub +"°C")
time.sleep(1)
client.disconnect()
print("deconnection")
client.loop_stop()
Comme broker, nous nous somme servit ici d'un broker mit en libre service par mosquitto.

==REST==
REST (Representational State Transfer) aussi appeler restful est une architecture logiciel inventer par Roy Fielding qui se sert des verbes HTTP comme identifiant des opérations et des réponses HTTP comme représentation des ressources.

Une architecture REST est définit par 5 règles/contraintes :

- Client–serveur

- Sans état

- Avec mise en cache

- En couches

- Interface uniforme

===Service pub/sub avec REST===
On peut réaliser un équivalent de service pub/sub avec REST à l'aide de GET et de POST qui agissent sur une base de données géré par un serveur:

[[Fichier:PubSub avec REST.png]]

Cette méthode comprend cependant de nombreux problèmes, notamment le fait que le client 1 ne sais pas si le client 2 à poster une donnée sur le serveur. On ne peut pas vraiment parler ici de service publish/subscribe car il n'y a pas d'abonnement, le client qui devrait s'abonner doit aller récupérer lui-même la donnée sans savoir si elle est bien situer sur le serveur.

==Protocole Hybride==

La technologie Pub/Sub et la technologie REST ont toutes deux leurs avantages et leurs inconvénients:

Avantages Pub/Sub :

- Transfère rapide des informations

- stockage des messages automatiques

- gestion de la qualité de service

Inconvénient Pub/Sub:

- On ne peut pas faire d’action direct sur le message, on ne fait un traitement dessus que lorsqu'on l'a reçu.

- protocole mqtt,qui bloquer par certain par feu

Avantages REST:

- protocole http(port 80) passe partout dans le monde

- on peut traiter le message directement sur le serveur

Inconvénient REST:

- On doit installer un serveur web, on doit géré une base de donnée (ou XML, Json).

L'objectif du protocole hybride est de réaliser un système pub/sub tel que l'on ai:

- un transfère rapide des informations

- un stockage des messages automatiques

- une gestion de la qualité de service

- le protocole http (port 80) de sorte à ce qu'il fonctionne partout dans le monde.

Pour cela, nous allons nous servir des Websockets.

===MQTT sur des Websocket===

Rest & Pub-Sub : protocole hybride pour l'IoT

2019-05-19T21:11:48Z

Rakotoanosy : /* Service pub/sub avec REST */

== Introduction ==

Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.

== MQTT ==
MQTT, Message Queuing Telemetry Transport, est un protocole publish/subscribe se basant sur le protocole TCP/IP.
Il a été créé par Andy Stanford-Clark et Arlen Nipper.

De façon concrète, MQTT permet à des appareils de publier des informations sur un sujet donné sur un broker (un serveur qui fonctionne comme un coursier) qui va les retransmettre aux appareils abonnés à ce sujet.

[[Fichier:Fonctionnement broker mqtt.png|600px|thumb|left|illustration d'un échange entre un client 1 "subscriber" et un client 2 "publisher"]]

MQTT gère aussi la qualité de service (d'une qualité 0 à une qualité 2):

Qualité 0: le client qui publie une donnée ne reçoit aucune information par rapport à la confirmation de son arrivé.

Qualité 1: le client qui publie reçoit la confirmation ou non que la donnée publier à été reçu par le broker.

Qualité 2: le client qui publie reçoit la confirmation ou non que la donnée publier à été reçu par le broker ainsi qu'un message lui indiquant que le client qui s'abonne à reçu la donnée.
===Mosquitto===
Mosquitto est un broker open-source qui se sert du protocole MQTT. Il permet une fois installé de se familiarisé avec MQTT et le "publish/subscribe".

nous nous en somme servit ici en publiant en localhost:

[[Fichier:Mosquitto exemple.png]]

Sur un premier terminal on s'abonne à un topic "température" et sur un deuxième terminal, on publie ensuite sur ce même topic des nombres (qui s'apparentent à des température). Au fur et à mesure que nous publions ces informations, nous les recevons sur le premier terminal.
Mosquitto remplit bien ici son rôle de broker.

===Pub/Sub avec Python===

Nous avons ensuite développer un client ''publisher'' et un client ''subscriber'' en python grâce à la librairie paho-mqtt.
Pour plus de simplicité et éviter des problèmes de timing, nous avons tout regrouper en un seul programme:

import paho.mqtt.client as mqtt
import time

broker="test.mosquitto.org"

def envoi_message(client, QoS, message):
print("message reçu :", str(message.payload.decode("utf-8")))

client= mqtt.Client("client_test")
client.on_message=envoi_message

client.connect(broker)
print("connection")
client.loop_start()
client.subscribe("Cafetière/temperature_cafe")
print("Abonnement...")
time.sleep(1)
pub= input("entrez une température (un nombre):")
print("Publication...")
time.sleep(1)
client.publish("Cafetière/temperature_cafe",pub +"°C")
time.sleep(1)
client.disconnect()
print("deconnection")
client.loop_stop()
Comme broker, nous nous somme servit ici d'un broker mit en libre service par mosquitto.

==REST==
REST (Representational State Transfer) aussi appeler restful est une architecture logiciel inventer par Roy Fielding qui se sert des verbes HTTP comme identifiant des opérations et des réponses HTTP comme représentation des ressources.

Une architecture REST est définit par 5 règles/contraintes :

- Client–serveur

- Sans état

- Avec mise en cache

- En couches

- Interface uniforme

===Service pub/sub avec REST===
On peut réaliser un équivalent de service pub/sub avec REST à l'aide de GET et de POST qui agissent sur une base de données géré par un serveur:

[[Fichier:PubSub avec REST.png]]

Cette méthode comprend cependant de nombreux problèmes, notamment le fait que le client 1 ne sais pas si le client 2 à poster une donnée sur le serveur. On ne peut pas vraiment parler ici de service publish/subscribe car il n'y a pas d'abonnement, le client qui devrait s'abonner doit aller récupérer lui-même la donnée sans savoir si elle est bien situer sur le serveur.

==Protocole Hybride==

La technologie Pub/Sub et la technologie REST ont toutes deux leurs avantages et leurs inconvénients:

Avantages Pub/Sub :

-Transfère rapide des informations

-stockage des messages automatiques

-gestion de la qualité de service

Inconvénient Pub/Sub:

-On ne peut pas faire d’action direct sur le message, on ne fait un traitement dessus que lorsqu'on l'a reçu.

-protocole mqtt,qui bloquer par certain par feu

Avantages REST:

-protocole http(port 80) passe partout dans le monde

-on peut traiter le message directement sur le serveur

Inconvénient REST:

-On doit installer un serveur web, on doit géré une base de donnée (ou XML, Json).

L'objectif du protocole

Rest & Pub-Sub : protocole hybride pour l'IoT

2019-05-19T21:10:43Z

Rakotoanosy : /* Service pub/sub avec REST */

== Introduction ==

Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.

== MQTT ==
MQTT, Message Queuing Telemetry Transport, est un protocole publish/subscribe se basant sur le protocole TCP/IP.
Il a été créé par Andy Stanford-Clark et Arlen Nipper.

De façon concrète, MQTT permet à des appareils de publier des informations sur un sujet donné sur un broker (un serveur qui fonctionne comme un coursier) qui va les retransmettre aux appareils abonnés à ce sujet.

[[Fichier:Fonctionnement broker mqtt.png|600px|thumb|left|illustration d'un échange entre un client 1 "subscriber" et un client 2 "publisher"]]

MQTT gère aussi la qualité de service (d'une qualité 0 à une qualité 2):

Qualité 0: le client qui publie une donnée ne reçoit aucune information par rapport à la confirmation de son arrivé.

Qualité 1: le client qui publie reçoit la confirmation ou non que la donnée publier à été reçu par le broker.

Qualité 2: le client qui publie reçoit la confirmation ou non que la donnée publier à été reçu par le broker ainsi qu'un message lui indiquant que le client qui s'abonne à reçu la donnée.
===Mosquitto===
Mosquitto est un broker open-source qui se sert du protocole MQTT. Il permet une fois installé de se familiarisé avec MQTT et le "publish/subscribe".

nous nous en somme servit ici en publiant en localhost:

[[Fichier:Mosquitto exemple.png]]

Sur un premier terminal on s'abonne à un topic "température" et sur un deuxième terminal, on publie ensuite sur ce même topic des nombres (qui s'apparentent à des température). Au fur et à mesure que nous publions ces informations, nous les recevons sur le premier terminal.
Mosquitto remplit bien ici son rôle de broker.

===Pub/Sub avec Python===

Nous avons ensuite développer un client ''publisher'' et un client ''subscriber'' en python grâce à la librairie paho-mqtt.
Pour plus de simplicité et éviter des problèmes de timing, nous avons tout regrouper en un seul programme:

import paho.mqtt.client as mqtt
import time

broker="test.mosquitto.org"

def envoi_message(client, QoS, message):
print("message reçu :", str(message.payload.decode("utf-8")))

client= mqtt.Client("client_test")
client.on_message=envoi_message

client.connect(broker)
print("connection")
client.loop_start()
client.subscribe("Cafetière/temperature_cafe")
print("Abonnement...")
time.sleep(1)
pub= input("entrez une température (un nombre):")
print("Publication...")
time.sleep(1)
client.publish("Cafetière/temperature_cafe",pub +"°C")
time.sleep(1)
client.disconnect()
print("deconnection")
client.loop_stop()
Comme broker, nous nous somme servit ici d'un broker mit en libre service par mosquitto.

==REST==
REST (Representational State Transfer) aussi appeler restful est une architecture logiciel inventer par Roy Fielding qui se sert des verbes HTTP comme identifiant des opérations et des réponses HTTP comme représentation des ressources.

Une architecture REST est définit par 5 règles/contraintes :

- Client–serveur

- Sans état

- Avec mise en cache

- En couches

- Interface uniforme

===Service pub/sub avec REST===
On peut réaliser un équivalent de service pub/sub avec REST avec des GET et des POST:

[[Fichier:PubSub avec REST.png]]

Cette méthode comprend cependant de nombreux problèmes, notamment le fait que le client 1 ne sais pas si le client 2 à poster une donnée sur le serveur. On ne peut pas vraiment parler ici de service publish/subscribe car il n'y a pas d'abonnement, le client qui devrait s'abonner doit aller récupérer lui-même la donnée sans savoir si elle est bien situer sur le serveur.

==Protocole Hybride==

La technologie Pub/Sub et la technologie REST ont toutes deux leurs avantages et leurs inconvénients:

Avantages Pub/Sub :

-Transfère rapide des informations

-stockage des messages automatiques

-gestion de la qualité de service

Inconvénient Pub/Sub:

-On ne peut pas faire d’action direct sur le message, on ne fait un traitement dessus que lorsqu'on l'a reçu.

-protocole mqtt,qui bloquer par certain par feu

Avantages REST:

-protocole http(port 80) passe partout dans le monde

-on peut traiter le message directement sur le serveur

Inconvénient REST:

-On doit installer un serveur web, on doit géré une base de donnée (ou XML, Json).

L'objectif du protocole

Fichier:PubSub avec REST.png

2019-05-19T21:10:20Z

Rakotoanosy :

Rest & Pub-Sub : protocole hybride pour l'IoT

2019-05-19T21:09:57Z

Rakotoanosy : /* Mosquitto */

== Introduction ==

Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.

== MQTT ==
MQTT, Message Queuing Telemetry Transport, est un protocole publish/subscribe se basant sur le protocole TCP/IP.
Il a été créé par Andy Stanford-Clark et Arlen Nipper.

De façon concrète, MQTT permet à des appareils de publier des informations sur un sujet donné sur un broker (un serveur qui fonctionne comme un coursier) qui va les retransmettre aux appareils abonnés à ce sujet.

[[Fichier:Fonctionnement broker mqtt.png|600px|thumb|left|illustration d'un échange entre un client 1 "subscriber" et un client 2 "publisher"]]

MQTT gère aussi la qualité de service (d'une qualité 0 à une qualité 2):

Qualité 0: le client qui publie une donnée ne reçoit aucune information par rapport à la confirmation de son arrivé.

Qualité 1: le client qui publie reçoit la confirmation ou non que la donnée publier à été reçu par le broker.

Qualité 2: le client qui publie reçoit la confirmation ou non que la donnée publier à été reçu par le broker ainsi qu'un message lui indiquant que le client qui s'abonne à reçu la donnée.
===Mosquitto===
Mosquitto est un broker open-source qui se sert du protocole MQTT. Il permet une fois installé de se familiarisé avec MQTT et le "publish/subscribe".

nous nous en somme servit ici en publiant en localhost:

[[Fichier:Mosquitto exemple.png]]

Sur un premier terminal on s'abonne à un topic "température" et sur un deuxième terminal, on publie ensuite sur ce même topic des nombres (qui s'apparentent à des température). Au fur et à mesure que nous publions ces informations, nous les recevons sur le premier terminal.
Mosquitto remplit bien ici son rôle de broker.

===Pub/Sub avec Python===

Nous avons ensuite développer un client ''publisher'' et un client ''subscriber'' en python grâce à la librairie paho-mqtt.
Pour plus de simplicité et éviter des problèmes de timing, nous avons tout regrouper en un seul programme:

import paho.mqtt.client as mqtt
import time

broker="test.mosquitto.org"

def envoi_message(client, QoS, message):
print("message reçu :", str(message.payload.decode("utf-8")))

client= mqtt.Client("client_test")
client.on_message=envoi_message

client.connect(broker)
print("connection")
client.loop_start()
client.subscribe("Cafetière/temperature_cafe")
print("Abonnement...")
time.sleep(1)
pub= input("entrez une température (un nombre):")
print("Publication...")
time.sleep(1)
client.publish("Cafetière/temperature_cafe",pub +"°C")
time.sleep(1)
client.disconnect()
print("deconnection")
client.loop_stop()
Comme broker, nous nous somme servit ici d'un broker mit en libre service par mosquitto.

==REST==
REST (Representational State Transfer) aussi appeler restful est une architecture logiciel inventer par Roy Fielding qui se sert des verbes HTTP comme identifiant des opérations et des réponses HTTP comme représentation des ressources.

Une architecture REST est définit par 5 règles/contraintes :

- Client–serveur

- Sans état

- Avec mise en cache

- En couches

- Interface uniforme

===Service pub/sub avec REST===
On peut réaliser un équivalent de service pub/sub avec REST avec des GET et des POST:

Cette méthode comprend cependant de nombreux problèmes, notamment le fait que le client 1 ne sais pas si le client 2 à poster une donnée sur le serveur. On ne peut pas vraiment parler ici de service publish/subscribe car il n'y a pas d'abonnement, le client qui devrait s'abonner doit aller récupérer lui-même la donnée sans savoir si elle est bien situer sur le serveur.

==Protocole Hybride==

La technologie Pub/Sub et la technologie REST ont toutes deux leurs avantages et leurs inconvénients:

Avantages Pub/Sub :

-Transfère rapide des informations

-stockage des messages automatiques

-gestion de la qualité de service

Inconvénient Pub/Sub:

-On ne peut pas faire d’action direct sur le message, on ne fait un traitement dessus que lorsqu'on l'a reçu.

-protocole mqtt,qui bloquer par certain par feu

Avantages REST:

-protocole http(port 80) passe partout dans le monde

-on peut traiter le message directement sur le serveur

Inconvénient REST:

-On doit installer un serveur web, on doit géré une base de donnée (ou XML, Json).

L'objectif du protocole

Rest & Pub-Sub : protocole hybride pour l'IoT

2019-05-19T21:09:18Z

Rakotoanosy : /* MQTT */

== Introduction ==

Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.

== MQTT ==
MQTT, Message Queuing Telemetry Transport, est un protocole publish/subscribe se basant sur le protocole TCP/IP.
Il a été créé par Andy Stanford-Clark et Arlen Nipper.

De façon concrète, MQTT permet à des appareils de publier des informations sur un sujet donné sur un broker (un serveur qui fonctionne comme un coursier) qui va les retransmettre aux appareils abonnés à ce sujet.

[[Fichier:Fonctionnement broker mqtt.png|600px|thumb|left|illustration d'un échange entre un client 1 "subscriber" et un client 2 "publisher"]]

MQTT gère aussi la qualité de service (d'une qualité 0 à une qualité 2):

Qualité 0: le client qui publie une donnée ne reçoit aucune information par rapport à la confirmation de son arrivé.

Qualité 1: le client qui publie reçoit la confirmation ou non que la donnée publier à été reçu par le broker.

Qualité 2: le client qui publie reçoit la confirmation ou non que la donnée publier à été reçu par le broker ainsi qu'un message lui indiquant que le client qui s'abonne à reçu la donnée.
===Mosquitto===
Mosquitto est un broker open-source qui se sert du protocole MQTT. Il permet une fois installé de se familiarisé avec MQTT et le "publish/subscribe".

nous nous en somme servit ici en publiant en localhost:

[[Fichier:Mosquitto exemple.png]]

sur un premier terminal on s'abonne à un topic "température" et sur un deuxième terminal, on publie ensuite sur ce même topic des nombres (qui s'apparentent à des température). Au fur et à mesure que nous publions ces informations, nous les recevons sur le premier terminal.
Mosquitto remplit bien ici son rôle de broker.

===Pub/Sub avec Python===

Nous avons ensuite développer un client ''publisher'' et un client ''subscriber'' en python grâce à la librairie paho-mqtt.
Pour plus de simplicité et éviter des problèmes de timing, nous avons tout regrouper en un seul programme:

import paho.mqtt.client as mqtt
import time

broker="test.mosquitto.org"

def envoi_message(client, QoS, message):
print("message reçu :", str(message.payload.decode("utf-8")))

client= mqtt.Client("client_test")
client.on_message=envoi_message

client.connect(broker)
print("connection")
client.loop_start()
client.subscribe("Cafetière/temperature_cafe")
print("Abonnement...")
time.sleep(1)
pub= input("entrez une température (un nombre):")
print("Publication...")
time.sleep(1)
client.publish("Cafetière/temperature_cafe",pub +"°C")
time.sleep(1)
client.disconnect()
print("deconnection")
client.loop_stop()
Comme broker, nous nous somme servit ici d'un broker mit en libre service par mosquitto.

==REST==
REST (Representational State Transfer) aussi appeler restful est une architecture logiciel inventer par Roy Fielding qui se sert des verbes HTTP comme identifiant des opérations et des réponses HTTP comme représentation des ressources.

Une architecture REST est définit par 5 règles/contraintes :

- Client–serveur

- Sans état

- Avec mise en cache

- En couches

- Interface uniforme

===Service pub/sub avec REST===
On peut réaliser un équivalent de service pub/sub avec REST avec des GET et des POST:

Cette méthode comprend cependant de nombreux problèmes, notamment le fait que le client 1 ne sais pas si le client 2 à poster une donnée sur le serveur. On ne peut pas vraiment parler ici de service publish/subscribe car il n'y a pas d'abonnement, le client qui devrait s'abonner doit aller récupérer lui-même la donnée sans savoir si elle est bien situer sur le serveur.

==Protocole Hybride==

La technologie Pub/Sub et la technologie REST ont toutes deux leurs avantages et leurs inconvénients:

Avantages Pub/Sub :

-Transfère rapide des informations

-stockage des messages automatiques

-gestion de la qualité de service

Inconvénient Pub/Sub:

-On ne peut pas faire d’action direct sur le message, on ne fait un traitement dessus que lorsqu'on l'a reçu.

-protocole mqtt,qui bloquer par certain par feu

Avantages REST:

-protocole http(port 80) passe partout dans le monde

-on peut traiter le message directement sur le serveur

Inconvénient REST:

-On doit installer un serveur web, on doit géré une base de donnée (ou XML, Json).

L'objectif du protocole

Rest & Pub-Sub : protocole hybride pour l'IoT

2019-05-19T21:08:58Z

Rakotoanosy : /* MQTT */

== Introduction ==

Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.

== MQTT ==
MQTT, Message Queuing Telemetry Transport, est un protocole publish/subscribe se basant sur le protocole TCP/IP.
Il a été créé par Andy Stanford-Clark et Arlen Nipper.

De façon concrète, MQTT permet à des appareils de publier des informations sur un sujet donné sur un broker (un serveur qui fonctionne comme un coursier) qui va les retransmettre aux appareils abonnés à ce sujet.

[[Fichier:Fonctionnement broker mqtt.png|600px|thumb|left|illustration d'un échange entre un client 1 "subscriber" et un client 2 "publisher"]]

MQTT gère aussi la qualité de service (d'une qualité 0 à une qualité 2):

Qualité 0: le client qui publie une donnée ne reçoit aucune information par rapport à la confirmation de son arrivé.

Qualité 1: le client qui publie reçoit la confirmation ou non que la donnée publier à été reçu par le broker.

Qualité 2: le client qui publie reçoit la confirmation ou non que la donnée publier à été reçu par le broker ainsi qu'un message lui indiquant que le client qui s'abonne à reçu la donnée.
===Mosquitto===
Mosquitto est un broker open-source qui se sert du protocole MQTT. Il permet une fois installé de se familiarisé avec MQTT et le "publish/subscribe".

nous nous en somme servit ici en publiant en localhost:

[[Fichier:Mosquitto exemple.png]]

sur un premier terminal on s'abonne à un topic "température" et sur un deuxième terminal, on publie ensuite sur ce même topic des nombres (qui s'apparentent à des température). Au fur et à mesure que nous publions ces informations, nous les recevons sur le premier terminal.
Mosquitto remplit bien ici son rôle de broker.

===Pub/Sub avec Python===

Nous avons ensuite développer un client ''publisher'' et un client ''subscriber'' en python grâce à la librairie paho-mqtt.
Pour plus de simplicité et éviter des problèmes de timing, nous avons tout regrouper en un seul programme:

import paho.mqtt.client as mqtt
import time

broker="test.mosquitto.org"

def envoi_message(client, QoS, message):
print("message reçu :", str(message.payload.decode("utf-8")))

client= mqtt.Client("client_test")
client.on_message=envoi_message

client.connect(broker)
print("connection")
client.loop_start()
client.subscribe("Cafetière/temperature_cafe")
print("Abonnement...")
time.sleep(1)
pub= input("entrez une température (un nombre):")
print("Publication...")
time.sleep(1)
client.publish("Cafetière/temperature_cafe",pub +"°C")
time.sleep(1)
client.disconnect()
print("deconnection")
client.loop_stop()
Comme broker, nous nous somme servit ici d'un broker mit en libre service par mosquitto.

==REST==
REST (Representational State Transfer) aussi appeler restful est une architecture logiciel inventer par Roy Fielding qui se sert des verbes HTTP comme identifiant des opérations et des réponses HTTP comme représentation des ressources.

Une architecture REST est définit par 5 règles/contraintes :

- Client–serveur

- Sans état

- Avec mise en cache

- En couches

- Interface uniforme

===Service pub/sub avec REST===
On peut réaliser un équivalent de service pub/sub avec REST avec des GET et des POST:

Cette méthode comprend cependant de nombreux problèmes, notamment le fait que le client 1 ne sais pas si le client 2 à poster une donnée sur le serveur. On ne peut pas vraiment parler ici de service publish/subscribe car il n'y a pas d'abonnement, le client qui devrait s'abonner doit aller récupérer lui-même la donnée sans savoir si elle est bien situer sur le serveur.

==Protocole Hybride==

La technologie Pub/Sub et la technologie REST ont toutes deux leurs avantages et leurs inconvénients:

Avantages Pub/Sub :

-Transfère rapide des informations

-stockage des messages automatiques

-gestion de la qualité de service

Inconvénient Pub/Sub:

-On ne peut pas faire d’action direct sur le message, on ne fait un traitement dessus que lorsqu'on l'a reçu.

-protocole mqtt,qui bloquer par certain par feu

Avantages REST:

-protocole http(port 80) passe partout dans le monde

-on peut traiter le message directement sur le serveur

Inconvénient REST:

-On doit installer un serveur web, on doit géré une base de donnée (ou XML, Json).

L'objectif du protocole

Rest & Pub-Sub : protocole hybride pour l'IoT

2019-05-19T21:08:47Z

Rakotoanosy : /* MQTT */

== Introduction ==

Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.

== MQTT ==
MQTT, Message Queuing Telemetry Transport, est un protocole publish/subscribe se basant sur le protocole TCP/IP.
Il a été créé par Andy Stanford-Clark et Arlen Nipper.

De façon concrète, MQTT permet à des appareils de publier des informations sur un sujet donné sur un broker (un serveur qui fonctionne comme un coursier) qui va les retransmettre aux appareils abonnés à ce sujet.

[[Fichier:Fonctionnement broker mqtt.png|600px|thumb|left|illustration d'un échange entre un client 1 "subscriber" et un client 2 "publisher"]]

MQTT gère aussi la qualité de service (d'une qualité 0 à une qualité 2):

Qualité 0: le client qui publie une donnée ne reçoit aucune information par rapport à la confirmation de son arrivé.

Qualité 1: le client qui publie reçoit la confirmation ou non que la donnée publier à été reçu par le broker.

Qualité 2: le client qui publie reçoit la confirmation ou non que la donnée publier à été reçu par le broker ainsi qu'un message lui indiquant que le client qui s'abonne à reçu la donnée.
===Mosquitto===
Mosquitto est un broker open-source qui se sert du protocole MQTT. Il permet une fois installé de se familiarisé avec MQTT et le "publish/subscribe".

nous nous en somme servit ici en publiant en localhost:

[[Fichier:Mosquitto exemple.png]]

sur un premier terminal on s'abonne à un topic "température" et sur un deuxième terminal, on publie ensuite sur ce même topic des nombres (qui s'apparentent à des température). Au fur et à mesure que nous publions ces informations, nous les recevons sur le premier terminal.
Mosquitto remplit bien ici son rôle de broker.

===Pub/Sub avec Python===

Nous avons ensuite développer un client ''publisher'' et un client ''subscriber'' en python grâce à la librairie paho-mqtt.
Pour plus de simplicité et éviter des problèmes de timing, nous avons tout regrouper en un seul programme:

import paho.mqtt.client as mqtt
import time

broker="test.mosquitto.org"

def envoi_message(client, QoS, message):
print("message reçu :", str(message.payload.decode("utf-8")))

client= mqtt.Client("client_test")
client.on_message=envoi_message

client.connect(broker)
print("connection")
client.loop_start()
client.subscribe("Cafetière/temperature_cafe")
print("Abonnement...")
time.sleep(1)
pub= input("entrez une température (un nombre):")
print("Publication...")
time.sleep(1)
client.publish("Cafetière/temperature_cafe",pub +"°C")
time.sleep(1)
client.disconnect()
print("deconnection")
client.loop_stop()
Comme broker, nous nous somme servit ici d'un broker mit en libre service par mosquitto.

==REST==
REST (Representational State Transfer) aussi appeler restful est une architecture logiciel inventer par Roy Fielding qui se sert des verbes HTTP comme identifiant des opérations et des réponses HTTP comme représentation des ressources.

Une architecture REST est définit par 5 règles/contraintes :

- Client–serveur

- Sans état

- Avec mise en cache

- En couches

- Interface uniforme

===Service pub/sub avec REST===
On peut réaliser un équivalent de service pub/sub avec REST avec des GET et des POST:

Cette méthode comprend cependant de nombreux problèmes, notamment le fait que le client 1 ne sais pas si le client 2 à poster une donnée sur le serveur. On ne peut pas vraiment parler ici de service publish/subscribe car il n'y a pas d'abonnement, le client qui devrait s'abonner doit aller récupérer lui-même la donnée sans savoir si elle est bien situer sur le serveur.

==Protocole Hybride==

La technologie Pub/Sub et la technologie REST ont toutes deux leurs avantages et leurs inconvénients:

Avantages Pub/Sub :

-Transfère rapide des informations

-stockage des messages automatiques

-gestion de la qualité de service

Inconvénient Pub/Sub:

-On ne peut pas faire d’action direct sur le message, on ne fait un traitement dessus que lorsqu'on l'a reçu.

-protocole mqtt,qui bloquer par certain par feu

Avantages REST:

-protocole http(port 80) passe partout dans le monde

-on peut traiter le message directement sur le serveur

Inconvénient REST:

-On doit installer un serveur web, on doit géré une base de donnée (ou XML, Json).

L'objectif du protocole

Rest & Pub-Sub : protocole hybride pour l'IoT

2019-05-19T21:08:33Z

Rakotoanosy : /* MQTT */

== Introduction ==

Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.

== MQTT ==
MQTT, Message Queuing Telemetry Transport, est un protocole publish/subscribe se basant sur le protocole TCP/IP.
Il a été créé par Andy Stanford-Clark et Arlen Nipper.

De façon concrète, MQTT permet à des appareils de publier des informations sur un sujet donné sur un broker (un serveur qui fonctionne comme un coursier) qui va les retransmettre aux appareils abonnés à ce sujet.

[[Fichier:Fonctionnement broker mqtt.png|600px|thumb|left|illustration d'un échange entre un client 1 "subscriber" et un client 2 "publisher"]]

MQTT gère aussi la qualité de service (d'une qualité 0 à une qualité 2):

Qualité 0: le client qui publie une donnée ne reçoit aucune information par rapport à la confirmation de son arrivé.

Qualité 1: le client qui publie reçoit la confirmation ou non que la donnée publier à été reçu par le broker.

Qualité 2: le client qui publie reçoit la confirmation ou non que la donnée publier à été reçu par le broker ainsi qu'un message lui indiquant que le client qui s'abonne à reçu la donnée.
===Mosquitto===
Mosquitto est un broker open-source qui se sert du protocole MQTT. Il permet une fois installé de se familiarisé avec MQTT et le "publish/subscribe".

nous nous en somme servit ici en publiant en localhost:

[[Fichier:Mosquitto exemple.png]]

sur un premier terminal on s'abonne à un topic "température" et sur un deuxième terminal, on publie ensuite sur ce même topic des nombres (qui s'apparentent à des température). Au fur et à mesure que nous publions ces informations, nous les recevons sur le premier terminal.
Mosquitto remplit bien ici son rôle de broker.

===Pub/Sub avec Python===

Nous avons ensuite développer un client ''publisher'' et un client ''subscriber'' en python grâce à la librairie paho-mqtt.
Pour plus de simplicité et éviter des problèmes de timing, nous avons tout regrouper en un seul programme:

import paho.mqtt.client as mqtt
import time

broker="test.mosquitto.org"

def envoi_message(client, QoS, message):
print("message reçu :", str(message.payload.decode("utf-8")))

client= mqtt.Client("client_test")
client.on_message=envoi_message

client.connect(broker)
print("connection")
client.loop_start()
client.subscribe("Cafetière/temperature_cafe")
print("Abonnement...")
time.sleep(1)
pub= input("entrez une température (un nombre):")
print("Publication...")
time.sleep(1)
client.publish("Cafetière/temperature_cafe",pub +"°C")
time.sleep(1)
client.disconnect()
print("deconnection")
client.loop_stop()
Comme broker, nous nous somme servit ici d'un broker mit en libre service par mosquitto.

==REST==
REST (Representational State Transfer) aussi appeler restful est une architecture logiciel inventer par Roy Fielding qui se sert des verbes HTTP comme identifiant des opérations et des réponses HTTP comme représentation des ressources.

Une architecture REST est définit par 5 règles/contraintes :

- Client–serveur

- Sans état

- Avec mise en cache

- En couches

- Interface uniforme

===Service pub/sub avec REST===
On peut réaliser un équivalent de service pub/sub avec REST avec des GET et des POST:

Cette méthode comprend cependant de nombreux problèmes, notamment le fait que le client 1 ne sais pas si le client 2 à poster une donnée sur le serveur. On ne peut pas vraiment parler ici de service publish/subscribe car il n'y a pas d'abonnement, le client qui devrait s'abonner doit aller récupérer lui-même la donnée sans savoir si elle est bien situer sur le serveur.

==Protocole Hybride==

La technologie Pub/Sub et la technologie REST ont toutes deux leurs avantages et leurs inconvénients:

Avantages Pub/Sub :

-Transfère rapide des informations

-stockage des messages automatiques

-gestion de la qualité de service

Inconvénient Pub/Sub:

-On ne peut pas faire d’action direct sur le message, on ne fait un traitement dessus que lorsqu'on l'a reçu.

-protocole mqtt,qui bloquer par certain par feu

Avantages REST:

-protocole http(port 80) passe partout dans le monde

-on peut traiter le message directement sur le serveur

Inconvénient REST:

-On doit installer un serveur web, on doit géré une base de donnée (ou XML, Json).

L'objectif du protocole

Rest & Pub-Sub : protocole hybride pour l'IoT

2019-05-19T21:08:15Z

Rakotoanosy :

== Introduction ==

Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.

== MQTT ==
MQTT, Message Queuing Telemetry Transport, est un protocole publish/subscribe se basant sur le protocole TCP/IP.
Il a été créé par Andy Stanford-Clark et Arlen Nipper.

De façon concrète, MQTT permet à des appareils de publier des informations sur un sujet donné sur un broker (un serveur qui fonctionne comme un coursier) qui va les retransmettre aux appareils abonnés à ce sujet.

[[Fichier:Fonctionnement broker mqtt.png|600px|thumb|left|illustration d'un échange entre un client 1 "subscriber" et un client 2 "publisher"]]

MQTT gère aussi la qualité de service (d'une qualité 0 à une qualité 2):

Qualité 0: le client qui publie une donnée ne reçoit aucune information par rapport à la confirmation de son arrivé.

Qualité 1: le client qui publie reçoit la confirmation ou non que la donnée publier à été reçu par le broker.

Qualité 2: le client qui publie reçoit la confirmation ou non que la donnée publier à été reçu par le broker ainsi qu'un message lui indiquant que le client qui s'abonne à reçu la donnée.
===Mosquitto===
Mosquitto est un broker open-source qui se sert du protocole MQTT. Il permet une fois installé de se familiarisé avec MQTT et le "publish/subscribe".

nous nous en somme servit ici en publiant en localhost:

[[Fichier:Mosquitto exemple.png]]

sur un premier terminal on s'abonne à un topic "température" et sur un deuxième terminal, on publie ensuite sur ce même topic des nombres (qui s'apparentent à des température). Au fur et à mesure que nous publions ces informations, nous les recevons sur le premier terminal.
Mosquitto remplit bien ici son rôle de broker.

===Pub/Sub avec Python===

Nous avons ensuite développer un client ''publisher'' et un client ''subscriber'' en python grâce à la librairie paho-mqtt.
Pour plus de simplicité et éviter des problèmes de timing, nous avons tout regrouper en un seul programme:

import paho.mqtt.client as mqtt
import time

broker="test.mosquitto.org"

def envoi_message(client, QoS, message):
print("message reçu :", str(message.payload.decode("utf-8")))

client= mqtt.Client("client_test")
client.on_message=envoi_message

client.connect(broker)
print("connection")
client.loop_start()
client.subscribe("Cafetière/temperature_cafe")
print("Abonnement...")
time.sleep(1)
pub= input("entrez une température (un nombre):")
print("Publication...")
time.sleep(1)
client.publish("Cafetière/temperature_cafe",pub +"°C")
time.sleep(1)
client.disconnect()
print("deconnection")
client.loop_stop()
Comme broker, nous nous somme servit ici d'un broker mit en libre service par mosquitto.

==REST==
REST (Representational State Transfer) aussi appeler restful est une architecture logiciel inventer par Roy Fielding qui se sert des verbes HTTP comme identifiant des opérations et des réponses HTTP comme représentation des ressources.

Une architecture REST est définit par 5 règles/contraintes :

- Client–serveur

- Sans état

- Avec mise en cache

- En couches

- Interface uniforme

===Service pub/sub avec REST===
On peut réaliser un équivalent de service pub/sub avec REST avec des GET et des POST:

Cette méthode comprend cependant de nombreux problèmes, notamment le fait que le client 1 ne sais pas si le client 2 à poster une donnée sur le serveur. On ne peut pas vraiment parler ici de service publish/subscribe car il n'y a pas d'abonnement, le client qui devrait s'abonner doit aller récupérer lui-même la donnée sans savoir si elle est bien situer sur le serveur.

==Protocole Hybride==

La technologie Pub/Sub et la technologie REST ont toutes deux leurs avantages et leurs inconvénients:

Avantages Pub/Sub :

-Transfère rapide des informations

-stockage des messages automatiques

-gestion de la qualité de service

Inconvénient Pub/Sub:

-On ne peut pas faire d’action direct sur le message, on ne fait un traitement dessus que lorsqu'on l'a reçu.

-protocole mqtt,qui bloquer par certain par feu

Avantages REST:

-protocole http(port 80) passe partout dans le monde

-on peut traiter le message directement sur le serveur

Inconvénient REST:

-On doit installer un serveur web, on doit géré une base de donnée (ou XML, Json).

L'objectif du protocole

Rest & Pub-Sub : protocole hybride pour l'IoT

2019-05-19T21:07:34Z

Rakotoanosy :

== Introduction ==

Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.

== MQTT ==
MQTT, Message Queuing Telemetry Transport, est un protocole publish/subscribe se basant sur le protocole TCP/IP.
Il a été créé par Andy Stanford-Clark et Arlen Nipper.

De façon concrète, MQTT permet à des appareils de publier des informations sur un sujet donné sur un broker (un serveur qui fonctionne comme un coursier) qui va les retransmettre aux appareils abonnés à ce sujet.

[[Fichier:Fonctionnement broker mqtt.png|600px|thumb|illustration d'un échange entre un client 1 "subscriber" et un client 2 "publisher"]]

MQTT gère aussi la qualité de service (d'une qualité 0 à une qualité 2):

Qualité 0: le client qui publie une donnée ne reçoit aucune information par rapport à la confirmation de son arrivé.

Qualité 1: le client qui publie reçoit la confirmation ou non que la donnée publier à été reçu par le broker.

Qualité 2: le client qui publie reçoit la confirmation ou non que la donnée publier à été reçu par le broker ainsi qu'un message lui indiquant que le client qui s'abonne à reçu la donnée.
===Mosquitto===
Mosquitto est un broker open-source qui se sert du protocole MQTT. Il permet une fois installé de se familiarisé avec MQTT et le "publish/subscribe".

nous nous en somme servit ici en publiant en localhost:

[[Fichier:Mosquitto exemple.png]]

sur un premier terminal on s'abonne à un topic "température" et sur un deuxième terminal, on publie ensuite sur ce même topic des nombres (qui s'apparentent à des température). Au fur et à mesure que nous publions ces informations, nous les recevons sur le premier terminal.
Mosquitto remplit bien ici son rôle de broker.

===Pub/Sub avec Python===

Nous avons ensuite développer un client ''publisher'' et un client ''subscriber'' en python grâce à la librairie paho-mqtt.
Pour plus de simplicité et éviter des problèmes de timing, nous avons tout regrouper en un seul programme:

import paho.mqtt.client as mqtt
import time

broker="test.mosquitto.org"

def envoi_message(client, QoS, message):
print("message reçu :", str(message.payload.decode("utf-8")))

client= mqtt.Client("client_test")
client.on_message=envoi_message

client.connect(broker)
print("connection")
client.loop_start()
client.subscribe("Cafetière/temperature_cafe")
print("Abonnement...")
time.sleep(1)
pub= input("entrez une température (un nombre):")
print("Publication...")
time.sleep(1)
client.publish("Cafetière/temperature_cafe",pub +"°C")
time.sleep(1)
client.disconnect()
print("deconnection")
client.loop_stop()
Comme broker, nous nous somme servit ici d'un broker mit en libre service par mosquitto.

==REST==
REST (Representational State Transfer) aussi appeler restful est une architecture logiciel inventer par Roy Fielding qui se sert des verbes HTTP comme identifiant des opérations et des réponses HTTP comme représentation des ressources.

Une architecture REST est définit par 5 règles/contraintes :

- Client–serveur

- Sans état

- Avec mise en cache

- En couches

- Interface uniforme

===Service pub/sub avec REST===
On peut réaliser un équivalent de service pub/sub avec REST avec des GET et des POST:

Cette méthode comprend cependant de nombreux problèmes, notamment le fait que le client 1 ne sais pas si le client 2 à poster une donnée sur le serveur. On ne peut pas vraiment parler ici de service publish/subscribe car il n'y a pas d'abonnement, le client qui devrait s'abonner doit aller récupérer lui-même la donnée sans savoir si elle est bien situer sur le serveur.

==Protocole Hybride==

La technologie Pub/Sub et la technologie REST ont toutes deux leurs avantages et leurs inconvénients:

Avantages Pub/Sub :

-Transfère rapide des informations

-stockage des messages automatiques

-gestion de la qualité de service

Inconvénient Pub/Sub:

-On ne peut pas faire d’action direct sur le message, on ne fait un traitement dessus que lorsqu'on l'a reçu.

-protocole mqtt,qui bloquer par certain par feu

Avantages REST:

-protocole http(port 80) passe partout dans le monde

-on peut traiter le message directement sur le serveur

Inconvénient REST:

-On doit installer un serveur web, on doit géré une base de donnée (ou XML, Json).

L'objectif du protocole