Mon voyage dans le nuage IoT (2)
Mon article précédent indiquait que l’IdO peut utiliser différents protocoles. Le diagramme ci-contre en montre les couches. Dans le monde de l’IdO, un nœud communique souvent avec un autre nœud par IP. Un nœud doit donc avoir une adresse IP. En théorie, le nombre d’adresses uniques possibles est de 340 milliards de milliards de milliards de milliards.
Mon article précédent indiquait que l’IdO peut utiliser différents protocoles. Le diagramme ci-contre en montre les couches. Dans le monde de l’IdO, un nœud communique souvent avec un autre nœud par IP. Un nœud doit donc avoir une adresse IP (des sous-nœuds dotés de capteurs et d’actionneurs peuvent être connectés à ces nœuds par ZibBee ou autre Bluetooth, mais laissons ces détails de côté pour le moment). En théorie, le nombre d’adresses possibles ne risque pas d’être épuisé avant un moment : la version la plus récente d’IP, IPv6, a un champ d’adresse de 128 bits, soit 340 milliards de milliards de milliards de milliards adresses uniques.
Sous la couche IP se trouvent les canaux de communication tels que WLAN (Wi-Fi), Ethernet et le réseau de téléphonie mobile, qui transfèrent les paquets IP. Le standard 6LoWPAN permet de transmettre et recevoir des paquets IPv6 via des réseaux radio de protocole IEEE 802.15.4. C’est ce standard qu’utilise par exemple le réseau personnel sans fil à protocole ZigBee. Comparé au canal de communication classique qu’est Internet, ZigBee ne requiert que peu de puissance et est donc idéal pour les applications alimentées par piles ou pour des nœuds alimentés par une source externe comme l’énergie solaire.
La plupart des développeurs d’applications ne s’intéressent réellement qu’aux protocoles situés au-dessus de la couche IP. C’est ce qui fait tout l’élégance de cette pile protocolaire : lorsque nous utilisons une couche, nous n’avons pas besoin de connaître tous les détails d’implantation des couches inférieures. Ce qui compte est la fiabilité du transfert des paquets de données IP. Avec un petit microcontrôleur, nous pouvons par exemple utiliser le module réseau préinstallé du micrologiciel. Sur un système/contrôleur plus gros comme le Raspberry Pi, le système d’exploitation possède déjà toutes les fonctions nécessaires. Ces méthodes peuvent être considérées comme matures car elles datent de l’origine des communications Internet classiques.
TCP et UDP sont deux protocoles bien établis que l’on utilise pour établir une connexion et échanger des données via IP. Les transmissions des données d’une page web vers un navigateur, ou encore les transferts de fichiers, utilisent par exemple TCP/IP. Le transfert se fait entre deux clients, aussi appelés extrémités (endpoints) ou sockets (interface de connexion). Chaque socket est identifié par une adresse IP et un numéro de port. Un processus ingénieux de requêtes et d’accusés de réception entre l’émetteur et les sockets destinataires garantit que le canal de communication est établi avant que les paquets de données ne soient envoyés. Le protocole UDP requiert moins « d’emballage » et n’utilise pas de mise en liaison avec accusés de réception, ce qui le rend plus adapté aux applications comme la transmission en continu de flux audio ou vidéo.
En général, le concepteur n’a pas à se frotter à la complexité des protocoles TCP et UDP. Les langages de programmation les plus répandus disposent en effet déjà de bibliothèques de fonctions pour la programmation par socket. Avec ces outils, il est relativement facile de transférer les valeurs d’un capteur ou d’envoyer des commandes par Internet. Nous pouvons sans trop de difficultés élaborer un protocole simple lorsque deux nœuds seulement sont impliqués, nous avons juste besoin d’envoyer via le réseau des informations simples comme une commande ON/OFF, ou encore une valeur numérique contenue dans un message TCP/IP. Vous trouverez deux exemples de telles implantations dans le numéro de janvier/février d’Elektor : WLAN pour microcontrôleurs utilise un smartphone pour envoyer des commandes ON/OFF aux LED d’une carte, et Windows sur la carte RPi (2) montre comment transmettre une valeur par le réseau et l’afficher sur un afficheur à 7 segments relié à un Raspberry Pi.
L’environnement des applications domotiques est différent puisqu’il y a généralement bien plus d’un abonné relié au réseau et que les données proviennent de plusieurs capteurs de différents microcontrôleurs. Comment dans ce cas être certain que les données aboutiront au bon destinataire ? Par quel moyen adresser les capteurs et autres nœuds sans que l’utilisateur ne soit obligé de retenir une liste d’adresses IP ? Comment rendre le réseau peu énergivore et fiable, autrement dit comment faire pour que l’utilisateur ait accès aux messages d’un capteur même lorsque celui-ci est hors-ligne ? Les réponses à ces questions se trouvent heureusement dans d’autres caractéristiques des protocoles TCP et UDP.
J'en parlerai dans le prochain article ! [HM]
Sous la couche IP se trouvent les canaux de communication tels que WLAN (Wi-Fi), Ethernet et le réseau de téléphonie mobile, qui transfèrent les paquets IP. Le standard 6LoWPAN permet de transmettre et recevoir des paquets IPv6 via des réseaux radio de protocole IEEE 802.15.4. C’est ce standard qu’utilise par exemple le réseau personnel sans fil à protocole ZigBee. Comparé au canal de communication classique qu’est Internet, ZigBee ne requiert que peu de puissance et est donc idéal pour les applications alimentées par piles ou pour des nœuds alimentés par une source externe comme l’énergie solaire.
La plupart des développeurs d’applications ne s’intéressent réellement qu’aux protocoles situés au-dessus de la couche IP. C’est ce qui fait tout l’élégance de cette pile protocolaire : lorsque nous utilisons une couche, nous n’avons pas besoin de connaître tous les détails d’implantation des couches inférieures. Ce qui compte est la fiabilité du transfert des paquets de données IP. Avec un petit microcontrôleur, nous pouvons par exemple utiliser le module réseau préinstallé du micrologiciel. Sur un système/contrôleur plus gros comme le Raspberry Pi, le système d’exploitation possède déjà toutes les fonctions nécessaires. Ces méthodes peuvent être considérées comme matures car elles datent de l’origine des communications Internet classiques.
TCP et UDP sont deux protocoles bien établis que l’on utilise pour établir une connexion et échanger des données via IP. Les transmissions des données d’une page web vers un navigateur, ou encore les transferts de fichiers, utilisent par exemple TCP/IP. Le transfert se fait entre deux clients, aussi appelés extrémités (endpoints) ou sockets (interface de connexion). Chaque socket est identifié par une adresse IP et un numéro de port. Un processus ingénieux de requêtes et d’accusés de réception entre l’émetteur et les sockets destinataires garantit que le canal de communication est établi avant que les paquets de données ne soient envoyés. Le protocole UDP requiert moins « d’emballage » et n’utilise pas de mise en liaison avec accusés de réception, ce qui le rend plus adapté aux applications comme la transmission en continu de flux audio ou vidéo.
En général, le concepteur n’a pas à se frotter à la complexité des protocoles TCP et UDP. Les langages de programmation les plus répandus disposent en effet déjà de bibliothèques de fonctions pour la programmation par socket. Avec ces outils, il est relativement facile de transférer les valeurs d’un capteur ou d’envoyer des commandes par Internet. Nous pouvons sans trop de difficultés élaborer un protocole simple lorsque deux nœuds seulement sont impliqués, nous avons juste besoin d’envoyer via le réseau des informations simples comme une commande ON/OFF, ou encore une valeur numérique contenue dans un message TCP/IP. Vous trouverez deux exemples de telles implantations dans le numéro de janvier/février d’Elektor : WLAN pour microcontrôleurs utilise un smartphone pour envoyer des commandes ON/OFF aux LED d’une carte, et Windows sur la carte RPi (2) montre comment transmettre une valeur par le réseau et l’afficher sur un afficheur à 7 segments relié à un Raspberry Pi.
L’environnement des applications domotiques est différent puisqu’il y a généralement bien plus d’un abonné relié au réseau et que les données proviennent de plusieurs capteurs de différents microcontrôleurs. Comment dans ce cas être certain que les données aboutiront au bon destinataire ? Par quel moyen adresser les capteurs et autres nœuds sans que l’utilisateur ne soit obligé de retenir une liste d’adresses IP ? Comment rendre le réseau peu énergivore et fiable, autrement dit comment faire pour que l’utilisateur ait accès aux messages d’un capteur même lorsque celui-ci est hors-ligne ? Les réponses à ces questions se trouvent heureusement dans d’autres caractéristiques des protocoles TCP et UDP.
J'en parlerai dans le prochain article ! [HM]
