Pour mes besoins, j’ai du faire deux petits logiciels (coucou et ecoute), le premier envoit sur multicast un message (son adresse IP par exemple) que le deuxième récupère. Cela permet à un serveur d’envoyer son adresse IP et aux machines clients de le réperer et d’adapter leur configuration. J’en ai eu besoin pour faire un VPN regroupant plusieurs salles sur plusieurs étages sans que je ne maitrise quoique ce soit sur les adresses IP. Pensez vous que ça soit interessant d’en faire un petit paquet (il faut que j’adapte un peu le truc mais ça peut se faire)?
Oui sans hésitation. Si de tels paquets existaient ils me serviraient souvent…hier par exemple.
Juste une idée en passant : le premier envoie le message passé en argument et le deuxième lance un script passé en argument.
En l’occurrence, le premier fait
coucou $MON_IP > /dev/null 2>&1 &
et le deuxième fait
IP_DE_LAUTRE=$(ecoute )
C’est tout.
Ou comment se passer de DNS.
Ca peut être pratique.
Un peu dans le même genre d’idée, mais cas d’utilisation différent :
- un démon écoute en permanence sur le serveur
- le client “ping” le serveur en broadcast
- le serveur répond et le client détermine l’adresse à partir du paquet réponse
Si ça intéresse du monde je peux l’extraire et l’adapter pour en faire des outils shell.
Ha ben voui qu’on veut les deux!!! nan mais!!! 
Aller hop!!! au boulot!!! 
Salut,
Tout ça ne fonctionnera que sur du Lan, n’est-ce pas ?
Oui, moi aussi je suis intéressé! 
[quote=“syam”]Un peu dans le même genre d’idée, mais cas d’utilisation différent :
- un démon écoute en permanence sur le serveur
- le client “ping” le serveur en broadcast
- le serveur répond et le client détermine l’adresse à partir du paquet réponse
Si ça intéresse du monde je peux l’extraire et l’adapter pour en faire des outils shell.[/quote]
Ce qu’ils veulent c’est :
- un démon écoute en permanence sur chaque poste
- les clients “ping” en broadcast
- les devices répondent et les clients les listent dans les hosts
Bon paquet coucou sur
deb boisson.homeip.net/debian squeeze divers
coucou -m “message à envoyer” -a 227.0.0.12 -p 1234
envoit aux adresses 227.0.0.12:1234 le message «message à envoyer» (en permanence)
ecoute -a 227.0.0.12 -p 1234
récupère le message (sur la sortie standard)
Je ne voudrais pas être rabasjoie mais quel est la différence entre :
et
?
227.0.0.37 est une adresse multicast, n’importe quelle machine ayant n’importe quelle IP peut écouter sur cette adresse et récupérer le message. En clair c’est comme une chaine précise de télé, il faut se régler dessus. Dans les établissements, les broadcast purs ne sont pas routés et sont souvent loggués (signe d’élèves essayant de jouer en réseau par exemple), les adresses multicast peuvent être relayées (par défaut, elles sont bloquées elles aussi, ce point est à confirmer par Pascal). Par ailleurs tu peux ainsi mélanger plusieurs machines dialoguant avec plusieurs serveurs, l’une sur 227.0.0.37, l’autre sur 227.0.0.25, sans qu’elles interfèrenent. Le multicast est utilisé par udpcast qui permet d’envoyer un fichier à plusieurs machines en même temps (très pratique pour cloner 50 machines en une seule fois). Un netcat n’aurait envoyé le message qu’une seule fois, ici il est répété en permanence. Et enfin
yes "message à envoyer" | nc -b 227.0.0.12 1234
(UNKNOWN) [227.0.0.12] 1234 (?) : Network is unreachable
$
nc sait faire du broadcast, pas du multicast. udpcast aurait été plus approprié mais j’obtiens
echo "Blop" | udp-sender --portbase 1234 --mcast-data-address 227.0.0.12et un seul message envoyé (ça peut s’arranger par une boucle) et
$ udp-receiver --portbase 1234 --mcast-rdv-address 227.0.0.12Udp-receiver 20100130
UDP receiver for (stdout) at 192.168.1.245 on eth0
received message, cap=00000009
Connected as #0 to 192.168.1.245
Press any key to start receiving data!
Sending go signal
Blops= 5 ( 8.00 Mbps)
bytes= 5 ( 0.00 Mbps)
Transfer complete.
francois@totoche:~$
ou bien
$ udp-receiver --portbase 1234 --mcast-rdv-address 227.0.0.12 --nokbd
Udp-receiver 20100130
UDP receiver for (stdout) at 192.168.1.245 on eth0
received message, cap=00000009
Connected as #0 to 192.168.1.245
Blops= 5 ( 10.00 Mbps)
bytes= 5 ( 0.00 Mbps)
Transfer complete.
et il a fallu taper sur une touche sur l’emetteur. Bref, il faut une présence physique ce qui n’était pas envisageable. On peut s’en sortir avec un timeout dans les 35 options des pgms mais à ce stade, j’ai préféré me taper du code, c’est plus simple et ça évitait de filtrer la sortie.
Je me rend compte que je ne connais rien au multicast. Notamment par rapport à cette adresse de broadcast.
C’est pour ça que j’ai utilisé yes. 
[quote=“fran.b”]yes "message à envoyer" | nc -b 227.0.0.12 1234
(UNKNOWN) [227.0.0.12] 1234 (?) : Network is unreachable
$
nc sait faire du broadcast, pas du multicast. udpcast aurait été plus approprié mais j’obtiens[/quote]
Il fait un broadcast car il a l’option -b (je pensais que 227.0.0.12 était une adresse de (sous)réseau).
Après une micro recherche il semble que netcat ne supporte pas le multicast (par contre l’udp n’a pas de problème pour lui).
Merci pour l’explication
Un autre intérêt est qu’on peut router le multicast et l’envoyer sur un réseau spécifique. C’est extrêmement souple en fait.
Pff si je comprends bien va falloir que j’adapte mon code pour faire du multicast quoi, sinon je vais passer pour quoi moi…
François je ne te félicite pas ! 
En fait je me suis énervé sur un broadcast qui ne passait pas une interface pont (eth0 + tap0) (Pascal saurait dire pourquoi je pense), avec le multicast et une bonne vieille règle de routage (sinon ça part vers la passerelle par défaut), ça marche. Comme il y avait urgence, test sur place ce mercredi, j’ai bricolé vite fait ce code. Finalement, ça a été plus facile que la manip sur wine en fait (wine à patcher et système à base de aufs à mettre en place) qui a été plus pénible.
Merci beaucoup fran.b… 
… j’testerai ça un de ces quatre… je mets sous le coude…
[size=50]Bon alors… il fait quoi le syam là… on attend!!![/size] 
Le syam il est occupé à se bouffer du Bacon, Dijkstra, Levanovi, Printezis, j’en passe et des meilleurs (théorie des garbage collectors… 
).
Si t’as un GC précis, concurrent, à la volée (on-the-fly) ET déterministe (sauf pour les cycles bien sûr, je demande pas l’impossible) qui soit pas trop dur à intégrer à LLVM, je prends. Ça me libérera beaucoup de temps pour m’occuper de trucs moins compliqués. Le tout dans un environnement stackless, tant qu’à faire.
Edit : Non mais sans blague c’est un vrai appel à l’aide, cerveau pas fonctionne là ! 
Nan mais c’est bon hein… j’ai l’temps là tout d’suite… 
(bon courage…)
[size=50]Mais bon… quand t’auras le temps… [/size] 