Annoncer au serveur la configuration

Version imprimable

24/02/2010, 12h08
wilval

[Résolu] Annoncer au serveur la configuration

Bonjour,
Je vais essayer d'être clair.
J'ai x hôtes sur un réseau qui ne sont pas encore identifiés.
J'ai 1 client qui doit sélectionner un serveur parmis x-1.
Mon application est niveau client.
Le client connait les adresses IP (fixes) des hôtes-serveurs potentiels (mais pas le nombre).
Le client fait des requêtes ARP pour identifier les hôtes-serveurs potentiels.
Une fois que le client a choisis son serveur, il faudrait que le client dise au serveur d'ouvrir son socket, faire son bind et se mettre en attente client.

1) Est-ce que tout ça paraît logique ?
2) Comment annoncer au serveur choisis d'ouvrir son socket, faire son bind et se mettre en attente client ?

Merci

EDIT : j'ai poser ma question trop tôt. Les données ont (déjà) changé.
24/02/2010, 13h10
Invité(e)

Citation:

Envoyé par wilval

1) Est-ce que tout ça paraît logique ?

Inhabituel plutôt.
En général, quand un serveur se lance, il crée un socket est se met en attente d'un client. Quand un client se connecte, un nouveau thread ou processus est en général lancé.

Citation:

Envoyé par wilval

2) Comment annoncer au serveur choisis d'ouvrir son socket, faire son bind et se mettre en attente client ?

Avec un socket d'écoute ? Mais un socket d'écoute déconnecté (UDP).

Est il envisageable de voir les serveur se mettre en attente à leur lancement ?
24/02/2010, 16h40
wilval

Désolé mabu pour ce premier post.
Je ne peux supprimer ce sujet donc je vais continuer à la suite. C'est sur le même thème. Et je vais commencer par le début.
Problème:
J'ai des hôtes sur un réseau (encore inconnus). Je veux compter le nombre d'hôtes.
Question :
Puis-je faire une seule requête ARP (donc sans indiquer une IP précise) ? Ou dois-je faire autant de requête ARP (avec IP des hôtes connues) que d'hôtes ? Dans ma deuxième solution, j'arréterai de faire des requêtes quand il n'y aura plus de réponses. Je débute la requête ARP avec l'adresse IP par défaut 192.168.0.2 puis 192.168.0.3 etc
En gros, existe-t-il une requête "Qui est sur le réseau ?" ?
Merci
24/02/2010, 17h33
Mac LAK

Citation:

Envoyé par wilval

En gros, existe-t-il une requête "Qui est sur le réseau ?" ?

Pas de façon générale... Par contre, tu peux avoir des machines avec un port UDP ouvert en listen, et tu pourras alors faire un broadcast UDP sur ton réseau, et récupérer les réponses.

Au niveau Ethernet, par contre, rien n'est garanti... Un broadcast Ethernet te garantit que tout le monde le verra, mais rien ne te garantit qu'ils répondront quoi que ce soit ! ;)
25/02/2010, 10h21
wilval

Citation:

Envoyé par Mac LAK

Pas de façon générale... Par contre, tu peux avoir des machines avec un port UDP ouvert en listen, et tu pourras alors faire un broadcast UDP sur ton réseau, et récupérer les réponses.

Tu veux dire la fonction listen qui permet d'attendre des connexions sur une socket (avec une file max) ?

Citation:

Envoyé par Mac LAK

Au niveau Ethernet, par contre, rien n'est garanti... Un broadcast Ethernet te garantit que tout le monde le verra, mais rien ne te garantit qu'ils répondront quoi que ce soit ! ;)

Si j'envoie une requête ARP sur réseau, il se peut que l'hôte conerné ne me réponde pas ? C'est dommage si tel est le cas.

Pour résumé :
Je suis un hôte. Il y a d'autres hôtes sur le réseau mais je ne connais rien d'eux si ce n'est qu'ils sont en UDP listen. 1) Je fais un broadast UDP sur le réseau. En fonction des réponses, j'obtiens le nombre total d'hôtes. 2) ARP request sur chaque hôte du réseau pour connaître leur MAC. 3) Je sélectionne un hôte. Et là il faut que je dise à cet hôte (qui sera serveur) d'ouvrir un socket TCP. 4) Comment faire ? 5) Est-ce que tout ça est possible ?
25/02/2010, 13h01
Mac LAK

Citation:

Envoyé par wilval

Tu veux dire la fonction listen qui permet d'attendre des connexions sur une socket (avec une file max) ?

Oui.

Citation:

Envoyé par wilval

Si j'envoie une requête ARP sur réseau, il se peut que l'hôte conerné ne me réponde pas ? C'est dommage si tel est le cas.

ARP, si, il va répondre (enfin, normalement, il le fait, hors bug / perte de trame).
Mais pour un BC "générique", ne répondront que les machines qui SAVENT gérer ce BC...

Citation:

Envoyé par wilval

1) Je fais un broadast UDP sur le réseau. En fonction des réponses, j'obtiens le nombre total d'hôtes.

Ainsi que leurs adresses IP, n'oublie pas.

Citation:

Envoyé par wilval

2) ARP request sur chaque hôte du réseau pour connaître leur MAC.

Probable que ce soit inutile, et que l'adresse MAC sera déjà dans le cache ARP... Ceci étant dit, via un BC UDP pour énumérer les serveurs, cette étape n'a plus AUCUN intérêt, car tu vas rester au niveau IP : tu n'auras pas besoin de descendre au niveau Ethernet.

Citation:

Envoyé par wilval

3) Je sélectionne un hôte. Et là il faut que je dise à cet hôte (qui sera serveur) d'ouvrir un socket TCP.

Effectivement, c'est bien ça, d'après ta description du problème.

Citation:

Envoyé par wilval

4) Comment faire ? 5) Est-ce que tout ça est possible ?

Via une requête UDP spécifique, sur le même port que celui servant à l'énumération, mais ciblée vers le serveur choisi.
C'est donc suivant le contenu de la trame que tu vas distinguer une sorte de "ping d'énumération" (envoyé en BC), et une demande d'ouverture de port TCP (le datagramme UDP peut contenir des éléments comme le port TCP à utiliser).

En bref, ton socket UDP va te servir de "système de contrôle" de la connexion TCP, pour énumérer les serveurs, ouvrir et fermer la socket TCP. Et c'est parfaitement possible, j'ai même déjà implémenté un système de ce style pour détecter (avec le moins de charge réseau possible) l'intégralité des machines d'un certain type présentes sur un LAN.
25/02/2010, 17h36
wilval

Déjà merci

Citation:

Envoyé par Mac LAK

C'est donc suivant le contenu de la trame que tu vas distinguer une sorte de "ping d'énumération" (envoyé en BC), et une demande d'ouverture de port TCP (le datagramme UDP peut contenir des éléments comme le port TCP à utiliser).

Tu me conseilles un UDP BC au lieu d'un TCP BC. Est-ce bien parce qu'un TCP BC est impossible du fait de la définition même du protocole qui est connecté ?

J'ai des craintes avec l'UDP lors de l'énumération des potenciels serveurs. On dit que l'UDP est un protocole non fiable : le client ne sera donc pas certain que chaque hôte aura reçu l'UDP BC. Et donc l'énumération pourrait être faussée ?

De plus, le client ne connaîtra pas le nombre de réponse et donc je ne vois pas comment il va récupérer ces réponses (en ARP, il n'y a pas besoin d'attendre un message) ?

Citation:

Envoyé par Mac LAK

via un BC UDP pour énumérer les serveurs, cette étape n'a plus AUCUN intérêt, car tu vas rester au niveau IP : tu n'auras pas besoin de descendre au niveau Ethernet.

Tu fais référence au système OSI (ou plutôt au modèle TCP/IP) en disant que la couche transport (avec l'UDP en l'occurence) engloble la couche réseau (avec l'ARP en l'occurence) ?
26/02/2010, 09h23
Mac LAK

Citation:

Envoyé par wilval

Tu me conseilles un UDP BC au lieu d'un TCP BC. Est-ce bien parce qu'un TCP BC est impossible du fait de la définition même du protocole qui est connecté ?

Tout à fait, seul UDP peut permettre ça.

Citation:

Envoyé par wilval

J'ai des craintes avec l'UDP lors de l'énumération des potenciels serveurs. On dit que l'UDP est un protocole non fiable : le client ne sera donc pas certain que chaque hôte aura reçu l'UDP BC. Et donc l'énumération pourrait être faussée ?

Théoriquement, oui. En pratique, sur un LAN, c'est peu probable : au pire, tu envoie deux ou trois trames à une seconde d'intervalle, et tu vérifies que tu as bien le même nombre de réponses à chaque fois.
Sur une communication UDP "normale", bien sûr, on ne redonde pas autant : on passe par un système d'acquittement. Là, tu veux effectuer une sorte de "découverte" du LAN et des machines dessus, ce qui n'est pas une opération faite toutes les dix secondes. Donc, demander deux ou trois fois n'est pas critique, ni en temps d'exécution, ni en charge réseau.

Citation:

Envoyé par wilval

De plus, le client ne connaîtra pas le nombre de réponse et donc je ne vois pas comment il va récupérer ces réponses (en ARP, il n'y a pas besoin d'attendre un message) ?

Si : tu vas récupérer N datagrammes en réponse (il faut les faire envoyer par les serveurs, bien sûr), donc cela veut dire N serveurs. Pour être tranquille, il faut et il suffit de mettre les infos dont tu as besoin (ex : nom du serveur, IP, etc.) dans le datagramme. De toutes façons, la trame finale Ethernet ne peut pas être plus petite que 64 octets, donc autant mettre des infos utiles plutôt que du bourrage automatique ! ;)

Citation:

Envoyé par wilval

Tu fais référence au système OSI (ou plutôt au modèle TCP/IP) en disant que la couche transport (avec l'UDP en l'occurence) engloble la couche réseau (avec l'ARP en l'occurence) ?

Pas exactement. Ce que je te dis, c'est que tu n'as plus AUCUN intérêt à descendre au niveau le plus bas (Ethernet), car tu peux tout régler au niveau UDP+TCP et IP. Donc, un ARP n'a plus d'intérêt, pas plus que la connaissance des adresses MAC de tes serveurs.
01/03/2010, 09h32
wilval

Citation:

Envoyé par Mac LAK

Si : tu vas récupérer N datagrammes en réponse (il faut les faire envoyer par les serveurs, bien sûr), donc cela veut dire N serveurs.

Il me faut donc mettre mon client en attente N fois ? (dans N processus)

Citation:

Envoyé par Mac LAK

Théoriquement, oui. En pratique, sur un LAN, c'est peu probable : au pire, tu envoie deux ou trois trames à une seconde d'intervalle, et tu vérifies que tu as bien le même nombre de réponses à chaque fois.

C'est que je suis dans un environnement où il vaut mieux que le théorie assure à 100%.
1) Donc ce j'ai pensé c'est faire un broadcast ARP pour compter les hôtes. Comme ça je n'ai pas à me mettre en attente sur chaque hôtes-serveurs ni ensuite sur le client N fois pour la réponse.
2) Ensuite, pour sélectionner chaque hôte, je me connecte directement au socket TCP du serveur sélectionne. J'ai son IP et le port est connu avant même la transaction par tout le monde.
01/03/2010, 15h45
Mac LAK

Citation:

Envoyé par wilval

Il me faut donc mettre mon client en attente N fois ? (dans N processus)

Non, tu attends juste sur ta socket de recevoir les datagrammes, tu n'as qu'à prévoir un simple timeout pour décréter que tout le monde a répondu ou pas. Pas besoin de faire N processus, ce serait ridicule et coûteux.

Citation:

Envoyé par wilval

C'est que je suis dans un environnement où il vaut mieux que le théorie assure à 100%.
1) Donc ce j'ai pensé c'est faire un broadcast ARP pour compter les hôtes. Comme ça je n'ai pas à me mettre en attente sur chaque hôtes-serveurs ni ensuite sur le client N fois pour la réponse.
2) Ensuite, pour sélectionner chaque hôte, je me connecte directement au socket TCP du serveur sélectionne. J'ai son IP et le port est connu avant même la transaction par tout le monde.

Comme tu veux, sauf qu'un BC ARP ne te donnera pas plus de "preuves" qu'un serveur existe... Tu peux aussi bien perdre une telle trame ARP qu'un datagramme BC UDP, aucun des deux n'est fiable à 100%.

Cela ne t'indiquera pas non plus que le serveur est opérationnel, mais juste que sa stack est (à peu près) fonctionnelle. Au moins, l'avantage du socket UDP, c'est qu'il te garantit que le processus serveur est actif (et non pas juste la machine "seule", ce qui serait la seule "preuve" fournie par l'ARP), et tu te rends indépendant des adresses MAC et des adresses IP des serveurs... En effet, via le BC UDP, tu vas aussi bien découvrir le nombre de serveurs actifs que leurs IP ! Alors qu'avec l'ARP, tu vas devoir "connaître" la liste des adresses MAC à l'avance.

Faire plusieurs essais de découverte devrait couvrir la plupart des cas d'erreurs que tu rencontreras, sachant que de toutes façons, tu n'auras JAMAIS de système parfait... Sauf à adresser chaque serveur possible de façon individuelle, en mode connecté, pour savoir s'il est OK. Or, cela demande à connaître à l'avance la topologie du réseau, chose que tu ignores, justement...
02/03/2010, 16h43
wilval

Citation:

Envoyé par Mac LAK

l'avantage du socket UDP, c'est qu'il te garantit que le processus serveur est actif (et non pas juste la machine "seule",

Si j'ai bien compris, avec l'ARP, tu ne détectes que la machine physique présente sur le réseau qu'il y ait ou non une communication possible. Alors qu'avec l'UDP, on va jusqu'à déduire que le programme de la machine est bien en route.

Citation:

Envoyé par Mac LAK

tu te rends indépendant des adresses MAC et des adresses IP des serveurs... En effet, via le BC UDP, tu vas aussi bien découvrir le nombre de serveurs actifs que leurs IP ! Alors qu'avec l'ARP, tu vas devoir "connaître" la liste des adresses MAC à l'avance.

ok. Avec l'ARP BC, il est vrai que j'ai besoin de connaîtres les adresses IP. Avec UDP BC, non.

merci de ton aide Mac LAK.
02/03/2010, 17h04
Mac LAK
Citation:

Envoyé par wilval

Si j'ai bien compris, avec l'ARP, tu ne détectes que la machine physique présente sur le réseau qu'il y ait ou non une communication possible. Alors qu'avec l'UDP, on va jusqu'à déduire que le programme de la machine est bien en route.

Tout à fait. Avec l'ARP, tu vas vérifier que le système d'exploitation est actif, et qu'il est correctement connecté au réseau. Pas plus, pas moins. Tu ne sais pas notamment s'il y a un processus serveur dessus... C'est la même chose que pinger un serveur Web : si ça répond, il est actif au niveau IP. Mais ça ne te dit pas si le processus serveur HTTP est actif, seule une connexion sur le port 80 te le dira, et tu confirmeras que c'est bien un serveur Web grâce à un contenu de trame au format HTTP qui devra recevoir une réponse adéquate.

Dans ton cas : avec l'UDP, si tu utilises un port que tu es le seul à utiliser (= pas un port "connu", genre 80 ou 23), tu garantis qu'il y a bien un processus en écoute sur ce port... Normalement, ton logiciel serveur devrait être le seul et unique sur le réseau à l'utiliser, donc tu sais qu'il est actif.

Ensuite, tu confirmes que c'est bien "ton" processus serveur grâce au contenu de ces trames UDP, qui doivent bien sûr être valides suivant le mini-protocole d'énumération que tu as défini : tu élimines ainsi la possibilité d'avoir un processus parasite en écoute sur ce port, qui ferait par exemple un simple echo de la trame reçue.

Un protocole très simple peut être :
- Énumération des serveurs :
  - Trame BC "source" :
    Contient un marqueur de commande "énumération".
    Contient un ID aléatoire unique.
    Contient l'adresse IP de réponse, ainsi que les ports UDP à utiliser pour communiquer.
  - Trame de réponse des serveurs :
    Contient un marqueur de réponse "énumération".
    Contient le même ID que celui de la trame BC.
    Contient l'IP du serveur et ses ports UDP.
- Demande de connexion TCP :
  - Demande de passage en écoute TCP (requête) :
    Contient un marqueur de commande "passage en opérationnel".
    Contient un ID aléatoire unique.
    Contient le port TCP à utiliser.
  - Réponse du serveur :
    Contient un marqueur de réponse "passage en opérationnel".
    Contient le même ID que celui de la trame de requête.
    Contient un acquittement de la bonne ouverture du socket TCP.
Avec ça, tu énumères tes serveurs tranquillement, et tu commandes à ceux qui doivent l'être de passer en écoute TCP. Il faut et il suffit, à la réception d'une trame sur ce port UDP, de vérifier que son format est cohérent avec ce mini-protocole.

Typiquement, la machine servant à énumérer doit rejeter les réponses d'énumération n'ayant pas le bon ID, tandis que les serveurs doivent rejeter les BC incorrects.
Pour la connexion TCP, un serveur doit refuser d'ouvrir le socket TCP s'il n'a pas été énuméré auparavant.

Citation:

Envoyé par wilval

ok. Avec l'ARP BC, il est vrai que j'ai besoin de connaîtres les adresses IP. Avec UDP BC, non.

C'est bien ça.

Citation:

Envoyé par wilval

merci de ton aide Mac LAK.

De rien !