Bonjour
 
Je développe un petit appareil réseau et j'ai un outil d'administration qui me permet de le trouver et de le ou les gérer.
Actuellement j’émets toutes les 5s en udp broadcast un cours message de présentation/diag qui permet à l'outil d'identifier les appareils présents sur le réseau. L'outil peut ensuite connecter en TCP les appareils, en plus de la présentation/diag qui continue d'arriver périodiquement en UDP.
 
Je cherche à faire ça mieux pour ne plus polluer le réseau avec les présentations envoyées par tous les appareils en usb broadcast. Ces présentations ne font que quelques 100n d'octets mais sur un réseau conséquent ça peut fuser dans tous les sens... ça n'a pas de sens.
 
bref quelle serait la solution la meilleure pour ça  ?
J'ai pensé a plusieurs solutions :
 
1)Faire du multicast. l'outil de diag s'abonne au groupe et reçoit alors les infos de diag. et mon appareil teste je ne sais pas comment s'il y a quelqu'un ou pas qui écoute. Sur le papier ça me parait fait pour mais je n'arrive pas à l'implémenter (surement faute de compréhension du multicast). J'ai pas bien compris comment les clients peuvent identifier le groupe auquel se connecter, faut il pour cela la détection décrite en 2) ?
 
2) inverser l'origine du broadcast. C'est les outils de diag qui font coucou aux appareils en broadcast. Quand l'appareil reçoit le coucou, il connait l'ip de l'outil de diag et peut ouvrir une connexion TCP ou alors envoyer des infos en UDP à cette IP (tant qu'il perçoit signe de vie)
 
3) what else ?
 
PS : je développe en embarqué sur un µc sous freertos. Je ne suis pas sur une machine de guerre sous linux    
 
Merci par avance pour vos idées et conseils

l'"outil de diag" c'est quoi, un logiciel qui tourne sur un serveur ? pour une utilisation ponctuelle ou sur le long terme ?

Bonjour
 
Aujourd'hui c'est un outil de paramétrage et diagnostic utilisé à l'installation ou ponctuellement quand un réglage ou un dépannage est nécessaire.
A terme cela pourrait être d'autres application de supervision.
 
Mais dans tous les cas ca a la forme d'une application bureau toute simple qui a le même besoin d'identifier sur le reseau le ou les appreils présents.
 
a titre de comparaison, mon besoin (en tous cas sur la partie identification des appareils sur le réseau) est très similaire au logiciel  synology assistant si vous connaissez.

Ah bah en lisant ton post je pensais exactement au syno assitant .
Oui perso j'imaginerai plutôt une appli de bureau qui envoie un paquet en broadcast et les appareils qui écoutent et y répondent qd ils en ont besoin

et apres, si j'ai un truc tres spécifique à un logiciel qui se connecte, j'ouvre une connexion TCP avec l'appareil, des que le logiciel se ferme la connexion se coupe
 
et si j'ai des informations de diagnostique à envoyer à tous les logiciels de supervision présents sur le réseau ça vous parait légitime de faire du multicast plutôt que n (n qui sera jamais supérieur à 4 ou 5 à priori) connexions TCP ?
 
Merci

pour 4 ou 5 je dirais t'emmerde pas et fais de l'unicast classique.
 
une autre technique de découverte qui est pas mal utilisée, c'est d'avoir un noms DNS prédéfini sur lequels les appareils vont tenter de faire une requête. Ils utilisent le suffixe DNS fourni par le DHCP, comme ça le FQDN reste spécifique à l'entreprise. Ca demande juste d'avoir l'enregistrement qui va bien dans ton DNS, qui référence ton outil de management.  
C'est un poil plus lourd à implémenter mais du coup plus besoin de broadcast, et tes équipements et ton manager peuvent aussi être sur des vlans différents.
Pour ton cas tel que décrit j'ai pas l'impression que ce soit le meilleur choix, mai ça te donnera peut-être des idées.

Bonjour
 
Je note cette dernière solution pour apparaitre moins idiot le jour où je verrai ca.
pour le reste je vais limiter le nombre de connexions et faire de l'unicast.
 
donc  
1) l'appareil ecoute un port de presentation
2) le client arrive il balance en broadcast "helloword"
3) l'appareil se connecte au client (qui est donc serveur gnéééé)
4) tout est possible, supervision, envois de diagnostics...
5) si le client se déconnecte alors le socket se ferme et tout va bien
 
Merci

Ouais ou
1) l'appareil ecoute un port de presentation
2) le client arrive il balance en broadcast "ping"
3) l'(les) appareil(s) lui répond(ent) "pong"
4) le client se connecte aux appareils récupérer les infos/faire ses trucs
5) déconnexion

pour le 3) pong, ca se fait avec quel type de connexion du coup ?
 
2) UDP broadcast
3) ?
4) TCP unicast
5) fin "toute simple" du TCP unicast

UDP unicast (vu que ton équipement sait l'ip du client qui a fait le ping)

sur un autre port alors ?
 
2) le client envoi "ping" en UDP broadcast sur le port P1
3) l'appareil répond "pong" sur le port ????? (forcément autre chose que P1, non ?)
4) le client connecte l'appareil en TCP (portP3)
 
Merci

si, p1 si tu veux