Discussion :

[FluidBlow]

Bonjour à tous,

j'ai réaliser un chat en tcp/ip qui s'utilise comme ceci :
On lance le serveur sur une machine "192.168.0.4"
On lance un client sur une machine "192.168.0.10" avec comme paramètre l'adresse du serveur (ici: "-192.168.0.4").

Maintenant j'aimerais qu'on lance le serveur sur une machine (n'importe laquelle du réseau local) et je veux que le client (situé aussi sur une machine quelquonque du réseau local) se connecte à se serveur (et dont il ne connait pas l'ip).

Comment faire pour que le client trouve l'adresse du serveur et s'y connecte ?

Merci de votre aide.

[ram-0000]

Il faut que ton serveur écoute 2 socket, une socket TCP (probablement), c'est celle de ton chat

et une socket UDP de localisation sur un port quelconque (1234 par exemple).

Le client quand il se lance commence par calculer son adresse IP du réseau local puis l'adresse de broadcast du réseau local.

Il émet ensuite un broadcast UDP sur le réseau local sur le port 1234 et attends une réponse.

Le serveur lorsqu'il reçoit ce broadcast UDP répond en donnant son adresse IP.

Le client n'a plus ensuite qu'à se connecter normallement à l'adresse IP donnée par la réponse.

Attention, ceci ne marche que sur un réseau local. Les boradcast UDP ne traversent pas les routeurs (sauf configuration explicite et manuelle).

[FluidBlow]

L'adresse de Broadcast est bien l'adresse de diffusion ? Est-ce pareil que le masque de sous réseau ?
En somme, l'adresse de diffusion est la même pour tout un réseau, non .? Donc si je peux l'obtenir manuellement, je n'aurais pas à la faire chercher par le client ?

[ram-0000]

L'adresse de Broadcast est bien l'adresse de diffusion ?

Oui

Est-ce pareil que le masque de sous réseau ?

Non, pas du tout, regarde ici pour plus d'explication : Introduction aux réseaux TCP IP au paragraphe 3

Il y a 2 adresses de broadcast

• l'adresse de broadcast que j'appelle "broadcast global" dont la valeur est 255.255.255.255
• l'adresse de broadcast que j'appelle "broadcast local" dont la valeur est calculée à partir du réseau local et du masque de réseau (sur un réseau 192.168.10.0/24, le broadcast local est 192.168.10.255 par exemple)

Pour en revenir à ton problème, en y réfléchissant, il est inutile de calculer le broadcast local, tu peux utiliser directement le broadcast global. Il ne passera pas non plus les routeurs et restera donc sur le réseau local.

[bacelar]

Utilisez des technologies d’annuaire type Active Directory ou LDAP sont bien plus pérenne.
Voir UDDI + Web Service + Azure AppFabric(Cloud Computing).

Enfin c'est pour dire, l'UDP broadcast, c'est vraiment du bricolage.

[ram-0000]

Enfin c'est pour dire, l'UDP broadcast, c'est vraiment du bricolage.

Pas tant que cela, c'est utilisé par Netbios, DHCP, BOOTP, RPC réseau...

Utilisez des technologies d’annuaire type Active Directory ou LDAP sont bien plus pérenne.
Voir UDDI + Web Service + Azure AppFabric(Cloud Computing).

Suivant la taille du projet, c'est peut être un peu le rouleau compresseur pour écraser une mouche.

[bacelar]

Pas tant que cela, c'est utilisé par Netbios, DHCP, BOOTP, RPC réseau...

je ne sais pas pour RPC réseau (c'est assez vague, DCOM vous voulez dire?).

Mais pour les autres non, pas d'UDP du tout, mais des protocoles de plus bas niveau de l'OSI, (niveau 2, IP c'est niveau 3 et UDP c'est niveau ~4).
C'est normal, vue, qu'ils sont là pour déterminer ou donner des adresses IP (pour NetBios c'est un peu plus complexe), elles même utilisées par le protocole UDP.

Suivant la taille du projet, c'est peut être un peu le rouleau compresseur pour écraser une mouche.

Tout à fait, mais ce bricolage a des limites très proches du sol (heu, d'une mouche).

[FluidBlow]

Merci mais je souhaite que mon projet reste léger donc pas besoin de rouleau compresseur
La méthode UDP fonctionne quand même non ?

Sinon pour la solution proposée (que mon serveur écoute deux socket et que le client envoie l'ip) c'est possible de l'inverser ?

C'est-a-dire que le client écoute deux socket et que le serveur envoie son ip en UDP pour que le client s'y connecte ? Parceque l'idée est que le client cherche le serveur pour s'y connecter et si il ne le trouve pas, alors il ordonne le lancement du serveur.

Merci de vos aides

[bacelar]

Merci mais je souhaite que mon projet reste léger donc pas besoin de rouleau compresseur

Oui, sauf que vos demandes suivantes commencent à sentir le marteau pilon.

La méthode UDP fonctionne quand même non ?

Oui, si les firewalls sont reconfigurés sur le serveur et les clients, que les éventuels routeurs intermédiaires soient configurés pour laisser passer ces flux UDP, que les bridges filtrant intermédiaires soit coopératifs, etc...

Ca marche sans problème pour une LANparty avec un switch.

Sinon pour la solution proposée (que mon serveur écoute deux socket et que le client envoie l'ip) c'est possible de l'inverser ?

C'est-a-dire que le client écoute deux socket et que le serveur envoie son ip en UDP pour que le client s'y connecte ?

Là, c'est plus du tout la même logique, votre solution sera extrêmement consommatrice en bande passante.

Parceque l'idée est que le client cherche le serveur pour s'y connecter et si il ne le trouve pas, alors il ordonne le lancement du serveur.

Là, ça sent le marteau pilon.
Ce que vous demandez est le genre de fonctionnalités qu’implémentent nativement les infrastructures de Service, qui utilisent des annuaires.

Si vous ne voulez pas réinventer une roue carrée, regardez les solutions clés en mains.

[ram-0000]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Pas tant que cela, c'est utilisé par Netbios, DHCP, BOOTP, RPC réseau...

je ne sais pas pour RPC réseau (c'est assez vague, DCOM vous voulez dire?).

Non, je parlais bien de RPC réseau (mais peut être que DCOM est dans le même panier), c'est utilisé quand on cherche une ressource RPC sur le réseau et que l'on ne sait pas quel serveur héberge ce RPC. On lance une requête RPC en broadcast UDP sur le port 111 UDP en spécifiant l'identifiant du RPC recherché.

Mais pour les autres non, pas d'UDP du tout, mais des protocoles de plus bas niveau de l'OSI, (niveau 2, IP c'est niveau 3 et UDP c'est niveau ~4).
C'est normal, vue, qu'ils sont là pour déterminer ou donner des adresses IP (pour NetBios c'est un peu plus complexe), elles même utilisées par le protocole UDP.

Je ne suis pas sûr que l'on se comprenne mais une requête DHCP part bien en UDP broadcast sur le port 67.

[bacelar]

Non, je parlais bien de RPC réseau (mais peut être que DCOM est dans le même panier), c'est utilisé quand on cherche une ressource RPC sur le réseau et que l'on ne sait pas quel serveur héberge ce RPC. On lance une requête RPC en broadcast UDP sur le port 111 UDP en spécifiant l'identifiant du RPC recherché.

Cela me rappel plutôt DCE-RPC.
DCOM est dans la même ligné, mais on commence à être à un niveau d'infrastructure bien superieur à du brodcast UDP, avec les couches logiciels + les démons + des représentations de données à la ASN1.

Je ne suis pas sûr que l'on se comprenne mais une requête DHCP part bien en UDP broadcast sur le port 67.

C'est une manière de lire les données "transport" des trames mais les en-têtes des supposées protocoles inférieurs ne sont pas valides. Normale, la source n'a pas d'adresse IP (champ obligatoire dans un paquet IP).

[FluidBlow]

Bon j'ai trouvé mon bonheur dans cette source :
http://www.developpez.net/forums/d93...eur-multicast/

Merci à ram-0000 pour l'idée du fonctionnement et son explication et à bacelar .

[bacelar]

Attention, vous êtes bas niveau et vous devrez faire une infrastructure et des protocoles d'arbitrage pour le lancement du ou des servers.
Pour faire ce type d'infrastructure, un temps soit peu robuste, il faut beaucoup de travail, que les infrastructures de type "Services" offrent clé en main.

[FluidBlow]

Je développe sous linux, et les services que vous m'avez proposer n'existent pas sous linux ou ont très très peu de documentation.
Sachant que le lien de la source fonctionne très bien, et que c'est pour la réalisation d'un petit jeu en réseau local avec des amis, je n'ai pas besoin de plus.
Merci quand même pour le conseil !