[Résolu] HTTP avec Raspberry PI 3

[LinuxKoku]

[quote="Bud Spencer" post_id=28580 time=1527185886 user_id=3080]
Vu que c’est pour une solution pro orienté SOA, tu devrais aussi regarder du côté des technologies .Net Core et ASP.NET Core. Cela permet d’interagir et d’exposer tous les protocoles que tu as cités sans aucun problème sur un PI3, c’est dockable, robuste, performant et pas besoin d’installer un serveur web (qui n’a rien à faire sur un PI) puisque le protocole http peut (et doit) etre embarqué par l’application elle-même. Bon c’est clair que ce sont des solutions très moderne et plutôt à usage pro et il y a peu de chance que tu trouves beaucoup d’aide pour ça sur un forum comme celui-là mais toute la documentation nécessaire est dipso sur le net.
[/quote]

Effectivement mon projet dois suivre une architecture orientée service, j'ai cherché sur (Net Core et ASP.NET Core), mais j'ai rien trouver de concluant pour le raspberry pi, ou alors je sa me paraît juste flou, de ce fait, je vous demande de plus ample explications et si c'est possible des liens qui faut suivre, parce que même si je réussi à configurer tout les protocoles cité, je dois toujours revenir a répondre à la spécification SOA , donc je serais peut être amené a suivre votre solution, donc une perte de temps considérable.

[destroyedlolo]

S'il s'agit de te proposer un truc sans savoir ce qu'on veut faire, ni comment, à ce compte là, je te propose d'installer Apache et de faire un web service REST : y'a meme pas besoin de PHP ou de quoi que ce soit d'autre et ca ne te prendra que 5 minutes (et encore, en faisant une pause café dedans).
Mais je doute que ton maitre de stage soit super content du résultat !

Effectivement mon projet dois suivre une architecture orientée service,

SOA est une méthodologie/architecture, ce que tu veux mais qui ne dépend absolument pas d'une technologie précises. Si Java et .Net sont les plus utilisés pour faire du SOA, ca se fait aussi très bien avec du NodeJS, du C, du PHP, du Lua ou quoi que tu veux : pas besoin d'aller vers des usines a gaz pour lequel tu auras du mal a trouver des tutos (critère important : le temps, j'imagine que ton projet ne dure que le temps de ton stage donc quelques mois n'est-ce pas ?). A toi donc que choisir la solution qui te parait la plus accessible ... mais qui devra ensuite etre maintenu par la boite qui t'emploie.

Mais quoi qu'il en soit, SOA ou pas SOA, tu ne couperas pas aux questions que j'ai posé plus haut : à savoir comment (au sens large) va se faire la communication avec le conducteur, la tour de controle ou quelque autre intervenant que ce soit.

[LinuxKoku]

quelle type de liaison (Wifi, LORA, ethernet, GSM, signaux de fumée ...), et comment ca sera afficher sur l'écran ??? Parce que le choix des possibles reste TRES vastes (simple page web, webservice, bus de message client/serveur ...).

J'utiliserais comme cité, une liaison Ethernet.

Je viens de parler à mon tuteur, pour en savoir plus sur le type de données et que est qu'il attend de ma Raspberry PI, sa réponse est, que le composant de comptage recueille des données qu'ils véhicules avec liaison RS485, et que maintenant la nouvelle norme de transport spécifie de nouveau protocoles et une liaison Ethernet, on dois relier notre composant de comptage avec le Raspberry PI qui lui pourrais communiqué avec ces protocoles la, donc le but du jeu c'est que je réussisse à ce que ma Raspbperry PI prend en charge tout les protocoles cités, et la liaison entre les deux composant, on s'en occupe

Je lui ai posé la question sur l'HTTP, il m'a dis que notre composant opère que dans le bus avec une communication série, je doute de l'utilisation d'un serveur HTTP (Je me suis fais une conclusion : que Ma Raspberry PI dois répondre à la spécification de la norme que par rapport a son utilisation, par exemple: pour un composant qui dois utiliser le web, la on dois utiliser HTTP, mais dans notre cas, l'utilisation du web n'est pas nécessaire, donc pas nécessaire d'utiliser un HTTP)

Mais si on reviens à la norme, celle-ci impose l'utilisation du HTTP non en serveur mais en déclencheur d’événements (ce que je n'ai pas compris ), je vous fait part de ce qui à était spécifié sur la norme:


TCP devrait être utilisé pour l'échange de la plupart des types de données, où le temps n'est pas critique. Il prend en charge les protocoles de couche d'application HTTP, FTP et SSH, qui doivent être utilisés comme indiqué ci-dessous:

5.6.2.2 Protocole de transfert hypertexte (HTTP)
Ce protocole est basé sur TCP. En outre, HTTP définit neuf méthodes (parfois dénommé "verbes") indiquant l'action souhaitée à effectuer sur la ressource identifiée. La description détaillée et les spécifications sont dans le RFC2616.
Le protocole HTTP doit être utilisé pour les données déclenchées par un événement (voir 6.3.1).

6.3.1 Données déclenchées par un événement
Si les données fournies par le service changent en raison d'événements externes ou internes non basés sur le temps,
Un protocole de communication point-point doit être utilisé comme défini en 5.6.2, en relation avec les mécanismes d'abonnement.

[destroyedlolo]

le composant de comptage recueille des données qu'ils véhicules avec liaison RS485, et que maintenant la nouvelle norme de transport spécifie de nouveau protocoles et une liaison Ethernet, on dois relier notre composant de comptage avec le Raspberry PI qui lui pourrais communiqué avec ces protocoles la, donc le but du jeu c'est que je réussisse à ce que ma Raspbperry PI prend en charge tout les protocoles cités, et la liaison entre les deux composant, on s'en occupe
[...]
mais dans notre cas, l'utilisation du web n'est pas nécessaire, donc pas nécessaire d'utiliser un HTTP

Ben là, ta dernière phrase n'est-elle pas le contraire de ce que tu dis juste au dessus ?

Mais si on reviens à la norme, celle-ci impose l'utilisation du HTTP non en serveur mais en déclencheur d’événements (ce que je n'ai pas compris ),

Ben a la lecture de ce que tu as copié ici :

• le 5.6.2.2 décrit simplement HTTP et les différentes méthodes sont décrites par exemple ici.
• pour le 6.3.1 : il s'agit plus ou moins d'alertes que tu émets aux clients qui s'y sont abonnés (genre "incident réseau : ligne trucmuche coupée").

Malheureusement, c'est pas assez précis par rapport à ce qu'ils appellent "abonnement" : comment est-ce que ca se fait ?
Ca peut etre des webservice (dans ce cas, il faut savoir suivant quel protocole - REST, SOAP, ... - quelles API). Mais ca peut etre aussi de simple flux RSS.
Dans ce dernier cas, un serveur web tout simple (Apache, NGX, ...) qui sert un fichier XML généré par ce qui gère les données venant des capteurs est suffisant, sans forcément d'intelligence à son niveau.

Enfin, c'est ce que j'ai compris des infos que tu as donné

Si on revient a ton projet, ce que je comprend de

on dois relier notre composant de comptage avec le Raspberry PI qui lui pourrais communiqué avec ces protocoles la

est que le rPI servirait de passerelle entre les compteurs RS-485 et le réseau éthernet.

J'ai jeté un oeil (très rapide) sur le site de l'itxpt : le but est de faire de l’interopérabilité contre les gestionnaires de transport publique, donc ca me parle plus vu que j'ai baigné dans un truc similaire (mais pas dans le PT) pendant quelques années, Rosettanet en l'occurence . Mais ca semble concerner la liaison avec des acteurs extérieurs (B2B) et non interne (M2M) comme semble l’être ton projet.

[Bud Spencer]

Effectivement mon projet dois suivre une architecture orientée service, j'ai cherché sur (Net Core et ASP.NET Core), mais j'ai rien trouver de concluant pour le raspberry pi

Pourtant il y a des tas de tutos qui expliquent comment installer et déployer des applis .Net Core sur le PI. Le premier lien qui sort de google quand on lui demande ‘.net core raspberry pi ‘ est celui-là :https://github.com/dotnet/core/blob/mas ... uctions.md et la page de recherche en propose 1830000 autres …

Je lui ai posé la question sur l'HTTP, il m'a dis que notre composant opère que dans le bus avec une communication série, je doute de l'utilisation d'un serveur HTTP (Je me suis fais une conclusion : que Ma Raspberry PI dois répondre à la spécification de la norme que par rapport a son utilisation, par exemple: pour un composant qui dois utiliser le web, la on dois utiliser HTTP, mais dans notre cas, l'utilisation du web n'est pas nécessaire, donc pas nécessaire d'utiliser un HTTP)
Mais si on reviens à la norme, celle-ci impose l'utilisation du HTTP non en serveur mais en déclencheur d’événements (ce que je n'ai pas compris …

C’est pourtant simple. Avant vous utilisiez une liaison rs845 pour échanger des données et des ordres avec vos systèmes de comptages. Ton job aujourd’hui c’est juste de mettre en place une interface qui doit permettre de faire l’abstraction de cette liaison pour rendre accessible ces systèmes de comptages aux travers de protocoles standard /IP et notamment pour exposer des services en utilisant le protocole http. Ton projet n’a rien d’exceptionnel et reflète un besoin très actuel. Pour te donner une idée, plus de la moitié des demandes de développements que je reçois en freelance sont des projets similaires et avec l’explosion de l’IoT la demande est de plus en plus forte. C’est justement pour ça que depuis plusieurs années, on voit fleurir, de plus en plus et pour tous les langages, des frameworks capables d’exploiter facilement tous les protocoles /IP (y compris le http) et ca, justement pour s’affranchir de l’utilisation de serveurs de protocoles. Après, à toi de voir si tu veux mettre en place une solution qui utilise des méthodes obsolètes qui datent du siècle dernier ou si tu veux au contraire profiter de toutes ces nouvelles technologies qui sont justement faites pour répondre à ton type de besoin.

Je vais encore te donner une autre suggestion de reflexion. Tu cherches à utiliser un PI pour intégrer un système embarqué et son hardware spécifique dans une architecture SOA ? Pour moi la solution serait toute trouvée puisqu’il existe un OS qui est SPECIALEMENT conçu pour ça. Ca s’appelle Windows 10 IoT Core. Tous les protocoles don tu as besoin y sont déjà implémenté, y compris une API RESTfull que tu peux enrichir pour proposer tes propres services. (Pour faire simple, W10 IoT Core sait déjà nativement envoyer et recevoir des requêtes de services http sans rien installer du tout de spécifique puisqu’il est fait en grande parti pour ca).

Pour résumer, si ta mission est de fournir un PI qui soit capable de dialoguer avec tes systèmes de comptage RS485 et de s’intégrer dans une architecture SOA en utilisant les protocoles /IP que tu as cité, tu as juste à installer W10IoT Core sur un PI et le filer aux développeurs qui n’auront plus qu’à coder la translation rs485<->protocoles/IP.

[LinuxKoku]

Bonjour,

C’est pourtant simple. Avant vous utilisiez une liaison rs845 pour échanger des données et des ordres avec vos systèmes de comptages

La liaison à était déjà faite selon d'autres protocoles, moi ma mission est de réussir a ce que ma Raspberry parle avec avec les protocoles cités, la liaison ayant déjà était réalisé, les développeurs vont refaire la liaison selon les protocoles que j'aurais configurer, en suivant bien-sur, une architecture orienté service.

Après, à toi de voir si tu veux mettre en place une solution qui utilise des méthodes obsolètes qui datent du siècle dernier ou si tu veux au contraire profiter de toutes ces nouvelles technologies qui sont justement faites pour répondre à ton type de besoin.

Je suis entrain de suivre une norme ! donc les protocoles cités sont exigé, en d'autre termes, mon cahier des charges est déjà spécifié sans possibilité de modification.

Je vais encore te donner une autre suggestion de reflexion. Tu cherches à utiliser un PI pour intégrer un système embarqué et son hardware spécifique dans une architecture SOA ? Pour moi la solution serait toute trouvée puisqu’il existe un OS qui est SPECIALEMENT conçu pour ça. Ca s’appelle Windows 10 IoT Core. Tous les protocoles don tu as besoin y sont déjà implémenté, y compris une API RESTfull que tu peux enrichir pour proposer tes propres services. (Pour faire simple, W10 IoT Core sait déjà nativement envoyer et recevoir des requêtes de services http sans rien installer du tout de spécifique puisqu’il est fait en grande parti pour ca).
Pour résumer, si ta mission est de fournir un PI qui soit capable de dialoguer avec tes systèmes de comptage RS485 et de s’intégrer dans une architecture SOA en utilisant les protocoles /IP que tu as cité, tu as juste à installer W10IoT Core sur un PI et le filer aux développeurs qui n’auront plus qu’à coder la translation rs485<->protocoles/IP.

J'ai bien étudié tout ce que vous m'avez conseillé et fait mes recherches, mais, est ce la seule solution pour réaliser une architecture orienté service (SOA) sur mon RPI3? ou je vais continuer ma configuration des protocoles et puis réfléchir a une architecture (SOA)?

Merci beaucoup

[Bud Spencer]

… moi ma mission est de réussir a ce que ma Raspberry parle avec avec les protocoles cités...

Oui, c'est bien ce que j'ai compris et les 3 idées que je t'ais proposées sont parfaitement adaptés pour ca.

Je suis entrain de suivre une norme ! donc les protocoles cités sont exigé, en d'autre termes, mon cahier des charges est déjà spécifié sans possibilité de modification.

Hormis les protocoles /IP que tu as cité, cette norme t'impose t'elle un OS ? un langage de programmation ? un software serveur ou applicatif précis pour chaque protocoles ? Si tu répond oui a une seule de ces questions, c'est que ce n'est pas une norme, mais un dictat qui n'a rien a voir avec SOA et dans ce cas, tu n'as pas de question a te poser et tu n'as qu'a installer et ce que l'on t'impose. Il y a une chose qu'il faut que tu comprennes. SOA n'est ni une norme, ni un protocoles, ni un système, ni une marque, ni un langage ….. C'est un paradigme qui a pour but de faciliter des échanges de données et d'ordres entres applications et systèmes divers en utilisant des protocoles et des méthodes de requête standard. Installer ou configurer un protocole sur un système n'en fait pas un système SOA. Ce sont les applications qui se trouvent au dessus des protocoles qui sont conforme ou pas au paradigme.

... est ce la seule solution pour réaliser une architecture orienté service (SOA) sur mon RPI3? ...

Absolument pas. Des méthodes, il y en a plein et les technologies qui gravitent autour de SOA sont innombrables. Tout ce qui t'as été proposé sur ce fil que ce soit par d'autres ou par moi peut rentrer dans le cadre de ce type d'architecture puisque c'est la notion d'échange qui compte et non pas sur quoi il repose techniquement . C'est le principe meme de SAO. Cela se fout pas mal de savoir ce qui fourni ou consomme des services et avant tout ne veut surtout pas savoir comment il le fait.

[LinuxKoku]

Absolument pas. Des méthodes, il y en a plein et les technologies qui gravitent autour de SOA sont innombrables. Tout ce qui t'as été proposé sur ce fil que ce soit par d'autres ou par moi peut rentrer dans le cadre de ce type d'architecture puisque c'est la notion d'échange qui compte et non pas sur quoi il repose techniquement ...

Comme j'ai commencé il y'a une semaine à configurer tout les protocoles tel proposé et conseillé ici, je me dis de continué sur cette lancée, sachant que j'ai réussi la configuration des protocoles HTTP, FTP, SSH, mDNS, et sa en testant ces derniers en visualisant les trames envoyé par le Wireshark (analyseur de paquets), je voudrais maintenant continué mon cahier des charges en passant maintenant à l'adressage IP, la norme exige un espace d'adressage IPv4 ou IPv6(recommandé), et une affectation automatique en choisissant: Affectation DHCP || auto-affectation (IPv6 ou IPv4) || affectation mixte.

L'affectation mixte étant un peut compliqué d'après mes recherches, je me suis dis d'aller sur la solution DHCP ou IPv6, en sachant qu'il faut répondre à ces contraintes:

Affectation DHCP
- Le protocole DHCP (Dynamic Host Configuration Protocol) permet d'attribuer des adresses IP. Ce serveur est responsable de l'attribution et de la gestion des adresses uniques à chaque module, basé sur RFC2131.
- Le type d'adresse respecte les classes IPv4 et les exigences IPv6 en fonction du nombre d’adresses que le serveur DHCP doit gérer.
- Avec DHCP, la carte d'adressage peut changer dynamiquement. Cela doit être considéré lors de la mise en un environnement avec une affectation DHCP.
- Le serveur DHCP doit fournir une plage d'adresses privées spéciales.
- Un module qui fournit un serveur DHCP doit pouvoir désactiver son serveur DHCP.

Auto-affectation
- Les protocoles IPv4 et IPv6 ont tous deux des techniques standardisées d'auto-affectation des adresses IP.
- Pour IPv4, RFC3927 définit l'allocation dynamique des adresses IP dans la plage 169.254.0.0/16

Mes interrogations:
- La plus part des tutoriels sur une affectation DHCP me propose de faire de mon RPI un serveur DHCP alors que je pense ce n'est pas mon but, moi je veux juste une que ma RPI puisse avoir une adresse IP automatiquement (affectation DHCP!)
- J'ai trouver ce tutoriel qui m'a l'air intéressant ! pour l'adressage (vous en pensez quoi?) IPv6 https://www.inetdoc.net/archives/2015/0 ... index.html

Question aussi qui m'intrigue:
La norme n'ayant pas parlé du protocole ARP qui lui est très important sachant qu'une adresse MAC est une adresse propre a chaque composant, donc comment savoir à quelle adresse MAC correspond telle adresse IP ? La solution à ce problème d'après mes recherches est: il suffit de mémoriser les correspondances entre une IP et une adresse MAC dans une mémoire intégrée au routeur ou au matériel réseau. Cette table de correspondance est appelée la table MAC ou la table ARP suivant le protocole utilisé.
-Est ce que le DHCP peut remplacer le travail du protocole ARP?

[LinuxKoku]

Bonjour à tous,
Je vous remercie pour toutes ces réponses aussi enrichissantes le meilleur forum

Ma raspberry pi dois être un client DHCP, vu qu'elle est un dispositif de comptage, une fois fixé dans un bus/tramway elle recevra une adresse IP par un serveur déjà dans le bus (ce qui fais que je ne dois pas avoir une adresse IP fixe), mais je crois que je le suis par défaut! vu que j'ai reçu une adresse IP à son démarrage !

Autres questions pour conclure ce projet:

Est ce que la configuration que j'ai fais, répond à une architecture orienté service(SOA)? sinon comment puis je l'intégrer a ce projet?