Multicast, broadcast... je patauge

"Fabien LE LEZ" <gramster@gramster.com> wrote in message
news:oa4j90p3c4rj9m2anusmmj66sa105e40ce@4ax.com

Je souhaite faire une application dont plusieurs instances, sur
plusieurs PC d'un LAN, doivent communiquer, le tout sans serveur. En
gros, dès qu'une instance est lancée, elle crie à la cantonade "Je
suis là !" et toutes les instances précédemment lancées doivent lui
répondre "Moi aussi je suis là !". Ainsi, chaque instance a en
permanence la liste des adresses IP des autres instances.

Les machines sont-elles sur le même réseau logique ? (même réseau IP ?)
Si oui, dans ce cas le broadcast est tout à fait adapté.
Pour un petit laïus sur le broadcast, tu peux regarder là:

<http://www.lalitte.com/masques03.htm#5.4_-_Adresses_spécifiques_(réseau,_broadcast)>

Le problème, c'est qu'en-dehors de TCP/IP, je ne connais pas
grand-chose. J'ai vaguement entendu parler de broadcast et de
multicast, sans avoir bien saisi la différence.

Elle existe pourtant bien.
Je ne suis pas un spécialiste du multicast. Ce que j'en ai retenu est
d'une part l'apartenance à un groupe de diffusion identifié par une
adresse IP, et d'autre part la gestion des protocoles multicast par
des routeurs intermédiaires.
Ainsi, on crée un groupe multicast. Des machines s'abonnent à ce groupe
et le font savoir au réseau local, sur lequel doit se trouver un
routeur qui pourra leur relayer les messages du groupe. Ainsi, quand
un message est envoyé à l'adresse du groupe multicast, les routeurs
la relaient de réseau en réseau, jusqu'à arriver aux réseaux finaux
sur lesquels se trouvent les clients abonnés qui reçoivent les infos.
Ca permet d'obtenir une sorte de broadcast, mais diffusé de réseaux en
réseaux.

M'enfin, c'est ce que j'en ai compris, ce qui n'est pas une garantie
suffisante ;-)

Mon problème est bien
sûr l'envoi du premier message ("à la cantonade") ; le reste devrait
bien aller car j'ai obtenu une adresse IP.

Si c'est en réseau local, le broadcast est plus adapté à mon avis
vu que tu n'auras qu'une trame envoyée pour une information.

Aussi, si quelqu'un pouvait m'aiguiller sur le nom de la technologie à
employer, voire quelques documentations, je lui en serais infiniment
reconnaissant :-)

Aucune idée là dessus, désolé...


--
Posted via Mailgate.ORG Server - http://www.Mailgate.ORG

salut grosso modo...
en broadcast, toutes les stations de ton LAN vont recevoir le message et en
multicast seules celles qui feront partie du groupe multicast recevront le
message en ayant adhéré au groupe avant...

ça marche ?
par contre comment le programmer , je ne le sais pas...

V.

"Fabien LE LEZ" <gramster@gramster.com> a écrit dans le message de news:
oa4j90p3c4rj9m2anusmmj66sa105e40ce@4ax.com...

Bonjour,

Je souhaite faire une application dont plusieurs instances, sur
plusieurs PC d'un LAN, doivent communiquer, le tout sans serveur. En
gros, dès qu'une instance est lancée, elle crie à la cantonade "Je
suis là !" et toutes les instances précédemment lancées doivent lui
répondre "Moi aussi je suis là !". Ainsi, chaque instance a en
permanence la liste des adresses IP des autres instances.

Le problème, c'est qu'en-dehors de TCP/IP, je ne connais pas
grand-chose. J'ai vaguement entendu parler de broadcast et de
multicast, sans avoir bien saisi la différence. Mon problème est bien
sûr l'envoi du premier message ("à la cantonade") ; le reste devrait
bien aller car j'ai obtenu une adresse IP.

Aussi, si quelqu'un pouvait m'aiguiller sur le nom de la technologie à
employer, voire quelques documentations, je lui en serais infiniment
reconnaissant :-)

Merci d'avance...

--
;-)
FLL, Epagneul Breton

Le problème, c'est qu'en-dehors de TCP/IP, je ne connais pas
grand-chose. J'ai vaguement entendu parler de broadcast et de
multicast, sans avoir bien saisi la différence.

Le multicast c'est presque pareil que le broadcast, sauf qu'on ne pollue pas

les machines non concernées et qu'on peut le faire sur des wan. En gros on
réserve une addresse multicast pour notre appli, au lancement le fait
d'ouvrir une socket multicast sur cette adresse prévient les éléments actifs
du réseau (routeurs, commutateurs) qu'ils devront nous envoyer une copie des
trames circulant sur le réseau et envoyées vers cette adresse. Pour cela il
faut toutefois que les routeurs gèrent le protocole IGMP.
Ainsi quand une autre machine envoie une trame multicast vers cette adresse,
toutes les machines ayant ouvert une socket en écoute sur celle-ci la
recevront, et pas les autres.


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.675 / Virus Database: 437 - Release Date: 02/05/2004

Salut,

On Thu, 06 May 2004 03:14:17 +0200, Fabien LE LEZ <gramster@gramster.com>
wrote:

Je souhaite faire une application dont plusieurs instances, sur
plusieurs PC d'un LAN, doivent communiquer, le tout sans serveur. En
gros, dès qu'une instance est lancée, elle crie à la cantonade "Je
suis là !" et toutes les instances précédemment lancées doivent lui
répondre "Moi aussi je suis là !". Ainsi, chaque instance a en
permanence la liste des adresses IP des autres instances.

C'est un peu sub-optimal comme méthode, mais bon, supposons.

Le problème, c'est qu'en-dehors de TCP/IP, je ne connais pas
grand-chose. J'ai vaguement entendu parler de broadcast et de
multicast, sans avoir bien saisi la différence. Mon problème est bien
sûr l'envoi du premier message ("à la cantonade")

Comme indiqué précédemment, un broadcast est envoyé à toutes les machines
du LAN (en envoyant à l'adresse IP broadcast, qui est l'adresse avec tous
les bits de la partie "machine" à 1, ou à l'adresse MAC broadcast, qui est
à l'adresse avec tous les bits à 1, ou 255.255.255.255 au choix). Un
multicast est envoyé à toutes les machines qui ont souscrit à un groupe
multicast (sur un ou plusieurs LANs, à condition que le routage multicast
soit activé entre ces LANs). Les adresses multicast vont de 224.0.0.0 à
239.255.255.255 si je ne m'abuse, et sont mappées à des adresses MAC
particulières, et il y a quelques protocoles pour gérer tout ça (en
particulier IGMP).

Dans le cadre d'un LAN donné, le broadcast suffit amplement. Le multicast
est utile quand on veut desservir un groupe de machines sur plusieurs
réseaux différents.

le reste devrait bien aller car j'ai obtenu une adresse IP.

Ca dépend si tu as besoin d'envoyer les mêmes données à tout le monde ou
pas. Dans le premier cas, ce serait une bonne idée de continuer à utiliser
(avec parcimonie) des broadcasts, ça fait un seul paquet Ethernet par
update au lieu d'un paquet par destinataire. Dans le second cas, des
paquets unicast sont plus adaptés, bien entendu (le trafic broadcast peut
être un gros problème sur un gros LAN avec plein de switches
interconnectés, donc il ne faut pas en abuser).

Aussi, si quelqu'un pouvait m'aiguiller sur le nom de la technologie à
employer, voire quelques documentations, je lui en serais infiniment
reconnaissant :-)

Pour envoyer à tout le monde il suffit d'envoyer à l'adresse broadcast, et
bien entendu que les destinataires écoutent sur "toutes les adresses" et
pas sur des adresses particulières.

Jacques.
--
Interactive Media Factory
Création, développement et hébergement
de services interactifs: SMS, SMS+, Audiotel...
http://www.imfeurope.com/

On Fri, 07 May 2004 17:25:59 +0200, Jacques Caron <jc@imfeurope.com>
wrote:

Ainsi, chaque instance a en
permanence la liste des adresses IP des autres instances.

C'est un peu sub-optimal comme méthode, mais bon, supposons.

Ben... Si tu connais une meilleure méthode, ça m'intéresse. Merci
d'avance, et merci à tous pour les explications déjà fournies :-)

En gros, le principe c'est d'envoyer un paquet (UDP ?) à l'adresse de
broadcast (le multicast ne s'impose pas dans mon cas : les LAN visés
seront petits [< 100 machines]), c'est bien ça ?
Dernier petit détail : si je veux faire un broadcast sur mon LAN
192.168.0.0/24, l'adresse de broadcast à utiliser est 192.168.0.255 ou
255.255.255.255 ?

--
;-)
FLL, Epagneul Breton

"Fabien LE LEZ" <gramster@gramster.com> wrote in message
news:gien90dmjtqvgoamkm4le7org4pemma98b@4ax.com

En gros, le principe c'est d'envoyer un paquet (UDP ?) à l'adresse de
broadcast (le multicast ne s'impose pas dans mon cas : les LAN visés
seront petits [< 100 machines]), c'est bien ça ?

Yep, tu peux faire le choix de TCP ou UDP selon tes besoins de
suivi de connexion.

Dernier petit détail : si je veux faire un broadcast sur mon LAN
192.168.0.0/24, l'adresse de broadcast à utiliser est 192.168.0.255 ou
255.255.255.255 ?

Les deux reviendront au même si tu ne partages pas le même domaine de
broadcast entre plusieurs réseaux. Sinon, 192.168.0.255 est plus
propre.




--
Posted via Mailgate.ORG Server - http://www.Mailgate.ORG

On Fri, 07 May 2004 18:41:18 +0200, Fabien LE LEZ <gramster@gramster.com>
wrote:

On Fri, 07 May 2004 17:25:59 +0200, Jacques Caron <jc@imfeurope.com>
wrote:

Ainsi, chaque instance a en
permanence la liste des adresses IP des autres instances.

C'est un peu sub-optimal comme méthode, mais bon, supposons.

Ben... Si tu connais une meilleure méthode, ça m'intéresse. Merci
d'avance, et merci à tous pour les explications déjà fournies :-)

La partie sub-optimale c'est que le nouvel arrivant envoie un broadcast,
et que tout le monde lui réponde. Ca veut dire que si on passe de 0 à N
machines en peu de temps, on aura balancé de l'ordre de N^2 paquets, alors
que N auraient suffi.

De plus, tu ne tiens pas compte des machines qui disparaissent...

Plusieurs méthodes possibles:
- chaque machine envoie un broadcast à intervalles réguliers (n secondes),
et maintient une liste des machines qu'elle a entendu dans les 3*n
dernières secondes. Optimisation: il est possible d'éviter le paquet de
présence quand on a émis un paquet "normal" récemment.
- chaque machine envoie un broadcast, et une machine unique (élue d'une
façon ou d'une autre) répond avec la liste des autres. Reste à détecter la
disparition des machines, bien entendu.

Je te conseille un peu de lecture sur IGMP, tu verras comment on gère déjà
ça en multicast...

En gros, le principe c'est d'envoyer un paquet (UDP ?)

UDP, IP ou Ethernet. Bien entendu pas TCP, le paquet ne doit pas avoir
besoin d'un acquittement.

à l'adresse de
broadcast (le multicast ne s'impose pas dans mon cas : les LAN visés
seront petits [< 100 machines]), c'est bien ça ?

Le multicast est surtout utile si on a des machines sur plusieurs LANs
(i.e. des domaines de broadcast différents). Accessoirement, le multicast
peut-être géré très bas dans les clients (voire même en hard), ce qui
limite les interruptions sur les machines non concernées, donc ça peut
améliorer les performances si le trafic broadcast/multicast est important
et la proportion de machines concernées est faible (ou que certaines des
machines non concernées n'ont pas besoin de la charge supplémentaire
induite).

Dernier petit détail : si je veux faire un broadcast sur mon LAN
192.168.0.0/24, l'adresse de broadcast à utiliser est 192.168.0.255 ou
255.255.255.255 ?

Les deux doivent fonctionner, normalement.

Jacques.
--
Interactive Media Factory
Création, développement et hébergement
de services interactifs: SMS, SMS+, Audiotel...
http://www.imfeurope.com/

On Mon, 10 May 2004 18:14:14 +0200, Jacques Caron <jc@imfeurope.com>
wrote:

La partie sub-optimale c'est que le nouvel arrivant envoie un broadcast,
et que tout le monde lui réponde. Ca veut dire que si on passe de 0 à N
machines en peu de temps, on aura balancé de l'ordre de N^2 paquets, alors
que N auraient suffi.

Si on prend l'exemple d'un réseau un peu ancien (mettons quelques
dizaines de machines connectées en Ethernet 10 Mbps avec des hubs), et
des petits paquets UDP (quelques octets de données, plus les headers
UDP et tutti quanti), combien de paquets puis-je envoyer (dans tous
les sens, i.e. plusieurs machines envoient presque en même temps) tout
en restant dans un fonctionnement normal (i.e. sans risquer des
problèmes de perte de paquets à cause de la saturation du réseau ?

De plus, tu ne tiens pas compte des machines qui disparaissent...

Pour les machines sur lesquelles l'application se termine
"normalement", pas de problème : j'envoie un paquet "Au revoir".
Pour les machines qui plantent, ben... tant pis ;-)
Comme c'est un cas assez rare, ne s'en apercevoir qu'à la prochaine
tentative de connexion "utile" (transfert de données) n'est pas une
catastrophe.

Plusieurs méthodes possibles:
- chaque machine envoie un broadcast à intervalles réguliers (n secondes),
et maintient une liste des machines qu'elle a entendu dans les 3*n
dernières secondes.

Problème : l'utilisateur qui lance l'application n'est pas forcément
patient, et aimerait bien avoir immédiatement la liste des machines
connectées.

- chaque machine envoie un broadcast, et une machine unique (élue d'une
façon ou d'une autre) répond avec la liste des autres. Reste à détecter la
disparition des machines, bien entendu.

Ce qui m'inquiète surtout, c'est le problème de la disparition subite
(sans avoir eu le temps de dire "au revoir", plantage par exemple) de
cette machine "élue".

Bon, j'imagine qu'il est possible de tourner la difficulté (par
exemple, la première machine, ne voyant rien venir, envoie un paquet
"Et alors, on me répond pas ?", et on organise à nouveau des
élections), mais j'aimerais autant avoir un système le plus simple
possible -- avoir des milliers de lignes de code pour gérer tous les
cas et sous-cas possibles risque de m'attirer des bugs aléatoires et
difficiles à cerner.


--
;-)
FLL, Epagneul Breton

Salut,

On Tue, 11 May 2004 20:44:12 +0200, Fabien LE LEZ <gramster@gramster.com>
wrote:

Si on prend l'exemple d'un réseau un peu ancien (mettons quelques
dizaines de machines connectées en Ethernet 10 Mbps avec des hubs), et
des petits paquets UDP (quelques octets de données, plus les headers
UDP et tutti quanti), combien de paquets puis-je envoyer (dans tous
les sens, i.e. plusieurs machines envoient presque en même temps) tout
en restant dans un fonctionnement normal (i.e. sans risquer des
problèmes de perte de paquets à cause de la saturation du réseau ?

C'est plus adapté pour fr.comp.reseaux.ethernet comme question, mais je
pense que c'est de l'ordre de quelques petits milliers par seconde au
total dans ce cas de figure (en considérant qu'il n'y a que ce trafic-là).
Mais en fait, à part les problèmes de collisions dans le cas décrit si on
pousse un peu trop, le problème avec beaucoup de trafic broadcast se situe
plutôt dans un environnement switché.

Pour les machines sur lesquelles l'application se termine
"normalement", pas de problème : j'envoie un paquet "Au revoir".

Les paquets se perdent...

Pour les machines qui plantent, ben... tant pis ;-)

Qui plantent, qui sont déconnectées du réseau sans précaution, qui sont
mises en veille (portables qui rentrent à la maison) sans quitter
l'appli...

Comme c'est un cas assez rare, ne s'en apercevoir qu'à la prochaine
tentative de connexion "utile" (transfert de données) n'est pas une
catastrophe.

Sans avoir connaissance du contexte, je ne peux me prononcer :-)

Ce qui m'inquiète surtout, c'est le problème de la disparition subite
(sans avoir eu le temps de dire "au revoir", plantage par exemple) de
cette machine "élue".

Dans ce cas la machine au deuxième rang devrait répondre...

Jacques.
--
Interactive Media Factory
Création, développement et hébergement
de services interactifs: SMS, SMS+, Audiotel...
http://www.imfeurope.com/