Je suis en train de monter actuellement un "petit" réseau de diffusion
vidéo.
Pour celà, j'ai plusieurs serveurs qui diffusent 15 flux multicast de
5mb/s chacun, des serveurs qui font de la vidéo à la demande (flux de 1
à 2 mb/s) et de la téléphonie IP (SIP). Ces différents seront envoyés
sur 20 postes via un routeur.
Pour ce routeur qui doit faire du multicast (peu importe le protocole),
j'hésite entre une solution "clé en main" ou "faite maison".
Donc, plusieurs solutions s'offrent à moi :
- 1 PC standard sous BSD (solution à éviter car il y'a plus de risques
de problèmes matériel)
- 1 mini-serveur de type Soekris sous BSD
- 1 routeur moyen de gamme (Linksys, Netgear, Bewan, ...)
- 1 routeur plus haut de gamme (Cisco, Netopia, ...)
Ce routeur devra donc supporter plusieurs cas de figures :
- Tout le monde regarde des flux multicast différents : 15 * 5 mb/s = 75
mb/s en entrée et 20 * 5 = 100 mb/s en sortie
- Tout le monde regarde de la VOD : 20 * 2 = 75 mb/s (multicast) + 40
mb/s (vod) en entrée et 40 mb/s en sortie
- Plusieurs types d'utilisations simultanées (10 multicast, 10 VOD) : 75
(multicast) + 20 (VOD) en entrée et 50 (multicast) + 20 (VOD) en sortie.
Voici grossièrement quelques types de fonctionnement.
Pensez-vous que pour ce type d'utilisation, qui me semble assez
intensive, je puisse utiliser un petit Soekris sous BSD ou il faut que
je me tourne vers des solutions plus professionnelles de type Cisco.
On Sat, 19 Feb 2005 01:42:52 +0100, Eric Masson wrote:
Jamais eu l'occasion de mettre en pratique ce que j'ai appris sur le sujet.
Il y a quelques années j'avais eu droit à un peu d'amusement avec de la diffusion multicast par satellite avec un passage par un lien RNIS et quelques LANs ici et là, c'était bien amusant. Sauf qu'évidemment IGMP et consorts qui passent par la voie de retour par modem qui prend un chemin différent ça complique un tantinet les choses!
Ceci dit, je me suis rendu compte tout à l'heure après coup qu'on était quand même vachement HS ici :-)
Jacques. -- Interactive Media Factory Création, développement et hébergement de services interactifs: SMS, SMS+, Audiotel... http://www.imfeurope.com/
On Sat, 19 Feb 2005 01:42:52 +0100, Eric Masson <emss@free.fr> wrote:
Jamais eu l'occasion de mettre en pratique ce que j'ai appris sur le
sujet.
Il y a quelques années j'avais eu droit à un peu d'amusement avec de la
diffusion multicast par satellite avec un passage par un lien RNIS et
quelques LANs ici et là, c'était bien amusant. Sauf qu'évidemment IGMP et
consorts qui passent par la voie de retour par modem qui prend un chemin
différent ça complique un tantinet les choses!
Ceci dit, je me suis rendu compte tout à l'heure après coup qu'on était
quand même vachement HS ici :-)
Jacques.
--
Interactive Media Factory
Création, développement et hébergement
de services interactifs: SMS, SMS+, Audiotel...
http://www.imfeurope.com/
On Sat, 19 Feb 2005 01:42:52 +0100, Eric Masson wrote:
Jamais eu l'occasion de mettre en pratique ce que j'ai appris sur le sujet.
Il y a quelques années j'avais eu droit à un peu d'amusement avec de la diffusion multicast par satellite avec un passage par un lien RNIS et quelques LANs ici et là, c'était bien amusant. Sauf qu'évidemment IGMP et consorts qui passent par la voie de retour par modem qui prend un chemin différent ça complique un tantinet les choses!
Ceci dit, je me suis rendu compte tout à l'heure après coup qu'on était quand même vachement HS ici :-)
Jacques. -- Interactive Media Factory Création, développement et hébergement de services interactifs: SMS, SMS+, Audiotel... http://www.imfeurope.com/
Vincent Derrien
La question est juste de savoir s'il y a plusieurs LANs à desservir, ou des postes distants. S'il n'y a toujours qu'un seul LAN, pas besoin de routeur. Et je ne vois pas non plus pourquoi il faudrait un switch L3. Par contre certaines fonctionnalités un peu évoluées peuvent être utiles, pour que le switch sache "coller" aux besoins multicast (i.e. ne pas envoyer le flux sur tous les ports, uniquement ceux qui en ont besoin), ce qui se fait généralement en écoutant les paquets IGMP (qui est effectivement de niveau 3, mais je pense qu'il y a des switches L2 un peu évolués qui savent faire ça);
Je me suis documenté et effectivement un switch niveau 2 qui fait de l'IGMP Snooping permet de gérer le multicast. L'IGMP snooping donne au switch un niveau 3 afin qu'il examine les paquets pour savoir si ce sont des paquets IGMP afin de rejoindre ou quitter un groupe. De plus, l'IGMP snooping découvre dynamiquement les routeurs et les sources multicast et est compatible avec CGMP (Protocole Cisco). A priori c'est ce qu'il me faut. Certains switchs L2 de Cisco le font, les D-Link aussi, les Netgear non...
Il faudrait donc un switch de niveau 3 pour gérer l'IGMP. Par contre, je ne sais pas si j'aurai besoin des protocoles multicast du type PIM ou DVMRP.
S'il n'y a pas de routage, a priori non.
Effectivement, s'il n'y a qu'un switch, je n'ai pas a "m'embeter" avec les protocoles.
C'est vrai que la partie Wifi du multicast ne sera pas amusante. Le nombre de point d'accès et de clients sont sujets aux résultats des tests que je ferai. J'adapterais le nombre de point d'accès et le nombre de clients par point d'accès en fonction des résultats.
Avant de faire des tests, quelques calculs permettent déjà de savoir ce qui est possible ou pas. Ne pas oublier qu'il n'y a qu'un nombre très limité de canaux qui ne se chevauchent pas...
Pour le Wifi, suite à quelques tests, je me suis aperçu que je pouvais avoir un maximum de 4-5 postes par point d'accès car sinon après le débit n'est pas suffisant pour avoir une bonne QoS. Pour les canaux, on peut avoir 3 point d'accès proche sans chevauchement, donc si je veux en mettre plus il faudra les espacer assez pour éviter les pertubations. Mais si je configure comme ci-dessous ça devrai aller, je pense....(il faut que les 2 PA qui sont sur le canal 1 soit assez éloignés).
AP sur Canal 1 AP sur Canal 7 AP sur Canal 13 AP sur Canal 1
Il faudrait que le serveur arrete la diffusion du flux mais pour l'instant, je ne vois pas comment faire que ce soit avec un switch ou un routeur.
Une solution "simple" consiste à embarquer un routeur multicast sur le serveur. J'avoue que comme ça fait bien longtemps que je n'ai pas touché à tout ça, je ne sais plus si un serveur arrête d'émettre le flux de toutes façons en l'absence de clients multicast (connus via IGMP ou autre), auquel cas il n'y aurait carrément rien à faire, mais dans le pire des cas un mrouted doit arriver à gérer tout ça, non?
Je ne sais pas non plus si le serveur peut arreter d'emettre un flux multicast en l'absence de client mais c'est vrai qu'installer un mrouted sur le serveur pourrait résoudre le problème puisque s'il n'a pas reçu de demande d'abonnement le mrouted bloquerait le flux multicast qui ne "sortirait" pas du serveur. Je pense que je vais tester ça.
La question est juste de savoir s'il y a plusieurs LANs à desservir, ou
des postes distants. S'il n'y a toujours qu'un seul LAN, pas besoin de
routeur. Et je ne vois pas non plus pourquoi il faudrait un switch L3.
Par contre certaines fonctionnalités un peu évoluées peuvent être
utiles, pour que le switch sache "coller" aux besoins multicast (i.e.
ne pas envoyer le flux sur tous les ports, uniquement ceux qui en ont
besoin), ce qui se fait généralement en écoutant les paquets IGMP (qui
est effectivement de niveau 3, mais je pense qu'il y a des switches L2
un peu évolués qui savent faire ça);
Je me suis documenté et effectivement un switch niveau 2 qui fait de
l'IGMP Snooping permet de gérer le multicast. L'IGMP snooping donne au
switch un niveau 3 afin qu'il examine les paquets pour savoir si ce sont
des paquets IGMP afin de rejoindre ou quitter un groupe. De plus, l'IGMP
snooping découvre dynamiquement les routeurs et les sources multicast et
est compatible avec CGMP (Protocole Cisco). A priori c'est ce qu'il me faut.
Certains switchs L2 de Cisco le font, les D-Link aussi, les Netgear non...
Il faudrait donc un switch de niveau 3 pour gérer l'IGMP. Par contre,
je ne sais pas si j'aurai besoin des protocoles multicast du type PIM
ou DVMRP.
S'il n'y a pas de routage, a priori non.
Effectivement, s'il n'y a qu'un switch, je n'ai pas a "m'embeter" avec
les protocoles.
C'est vrai que la partie Wifi du multicast ne sera pas amusante. Le
nombre de point d'accès et de clients sont sujets aux résultats des
tests que je ferai. J'adapterais le nombre de point d'accès et le
nombre de clients par point d'accès en fonction des résultats.
Avant de faire des tests, quelques calculs permettent déjà de savoir ce
qui est possible ou pas. Ne pas oublier qu'il n'y a qu'un nombre très
limité de canaux qui ne se chevauchent pas...
Pour le Wifi, suite à quelques tests, je me suis aperçu que je pouvais
avoir un maximum de 4-5 postes par point d'accès car sinon après le
débit n'est pas suffisant pour avoir une bonne QoS. Pour les canaux, on
peut avoir 3 point d'accès proche sans chevauchement, donc si je veux en
mettre plus il faudra les espacer assez pour éviter les pertubations.
Mais si je configure comme ci-dessous ça devrai aller, je pense....(il
faut que les 2 PA qui sont sur le canal 1 soit assez éloignés).
AP sur Canal 1 AP sur Canal 7 AP sur Canal 13
AP sur Canal 1
Il faudrait que le serveur arrete la diffusion du flux mais pour
l'instant, je ne vois pas comment faire que ce soit avec un switch ou
un routeur.
Une solution "simple" consiste à embarquer un routeur multicast sur le
serveur. J'avoue que comme ça fait bien longtemps que je n'ai pas touché
à tout ça, je ne sais plus si un serveur arrête d'émettre le flux de
toutes façons en l'absence de clients multicast (connus via IGMP ou
autre), auquel cas il n'y aurait carrément rien à faire, mais dans le
pire des cas un mrouted doit arriver à gérer tout ça, non?
Je ne sais pas non plus si le serveur peut arreter d'emettre un flux
multicast en l'absence de client mais c'est vrai qu'installer un mrouted
sur le serveur pourrait résoudre le problème puisque s'il n'a pas reçu
de demande d'abonnement le mrouted bloquerait le flux multicast qui ne
"sortirait" pas du serveur. Je pense que je vais tester ça.
La question est juste de savoir s'il y a plusieurs LANs à desservir, ou des postes distants. S'il n'y a toujours qu'un seul LAN, pas besoin de routeur. Et je ne vois pas non plus pourquoi il faudrait un switch L3. Par contre certaines fonctionnalités un peu évoluées peuvent être utiles, pour que le switch sache "coller" aux besoins multicast (i.e. ne pas envoyer le flux sur tous les ports, uniquement ceux qui en ont besoin), ce qui se fait généralement en écoutant les paquets IGMP (qui est effectivement de niveau 3, mais je pense qu'il y a des switches L2 un peu évolués qui savent faire ça);
Je me suis documenté et effectivement un switch niveau 2 qui fait de l'IGMP Snooping permet de gérer le multicast. L'IGMP snooping donne au switch un niveau 3 afin qu'il examine les paquets pour savoir si ce sont des paquets IGMP afin de rejoindre ou quitter un groupe. De plus, l'IGMP snooping découvre dynamiquement les routeurs et les sources multicast et est compatible avec CGMP (Protocole Cisco). A priori c'est ce qu'il me faut. Certains switchs L2 de Cisco le font, les D-Link aussi, les Netgear non...
Il faudrait donc un switch de niveau 3 pour gérer l'IGMP. Par contre, je ne sais pas si j'aurai besoin des protocoles multicast du type PIM ou DVMRP.
S'il n'y a pas de routage, a priori non.
Effectivement, s'il n'y a qu'un switch, je n'ai pas a "m'embeter" avec les protocoles.
C'est vrai que la partie Wifi du multicast ne sera pas amusante. Le nombre de point d'accès et de clients sont sujets aux résultats des tests que je ferai. J'adapterais le nombre de point d'accès et le nombre de clients par point d'accès en fonction des résultats.
Avant de faire des tests, quelques calculs permettent déjà de savoir ce qui est possible ou pas. Ne pas oublier qu'il n'y a qu'un nombre très limité de canaux qui ne se chevauchent pas...
Pour le Wifi, suite à quelques tests, je me suis aperçu que je pouvais avoir un maximum de 4-5 postes par point d'accès car sinon après le débit n'est pas suffisant pour avoir une bonne QoS. Pour les canaux, on peut avoir 3 point d'accès proche sans chevauchement, donc si je veux en mettre plus il faudra les espacer assez pour éviter les pertubations. Mais si je configure comme ci-dessous ça devrai aller, je pense....(il faut que les 2 PA qui sont sur le canal 1 soit assez éloignés).
AP sur Canal 1 AP sur Canal 7 AP sur Canal 13 AP sur Canal 1
Il faudrait que le serveur arrete la diffusion du flux mais pour l'instant, je ne vois pas comment faire que ce soit avec un switch ou un routeur.
Une solution "simple" consiste à embarquer un routeur multicast sur le serveur. J'avoue que comme ça fait bien longtemps que je n'ai pas touché à tout ça, je ne sais plus si un serveur arrête d'émettre le flux de toutes façons en l'absence de clients multicast (connus via IGMP ou autre), auquel cas il n'y aurait carrément rien à faire, mais dans le pire des cas un mrouted doit arriver à gérer tout ça, non?
Je ne sais pas non plus si le serveur peut arreter d'emettre un flux multicast en l'absence de client mais c'est vrai qu'installer un mrouted sur le serveur pourrait résoudre le problème puisque s'il n'a pas reçu de demande d'abonnement le mrouted bloquerait le flux multicast qui ne "sortirait" pas du serveur. Je pense que je vais tester ça.
Jacques Caron
Salut,
[mostly complètement HS]
On Tue, 22 Feb 2005 17:35:26 +0100, Vincent Derrien wrote:
Pour le Wifi, suite à quelques tests, je me suis aperçu que je pouvais avoir un maximum de 4-5 postes par point d'accès car sinon après le débit n'est pas suffisant pour avoir une bonne QoS.
Avec quoi, du multicast ou de l'unicast? En multicast (à condition que l'AP envoie effectivement les paquets IP multicast sous forme de multicast 802.11, ce qui est à ma connaissance toujours le cas, mais on ne sait jamais...) le nombre de postes ne devrait pas faire de différence. Par contre, il ne faut pas oublier que les trames multicast sont envoyées à un débit potentiellement inférieur au débit max (normalement le plus haut débit du basic rate set), pour être sûr que tout le monde les reçoit. Et si on utilise du chiffrement (WEP, 802.1X, WPA...), il faut bien s'assurer que tout le monde gère correctement les clefs multicast (aka clefs de groupe) qui doivent être distinctes des clefs de session.
Pour les canaux, on peut avoir 3 point d'accès proche sans chevauchement, donc si je veux en mettre plus il faudra les espacer assez pour éviter les pertubations. Mais si je configure comme ci-dessous ça devrai aller, je pense....(il faut que les 2 PA qui sont sur le canal 1 soit assez éloignés).
AP sur Canal 1 AP sur Canal 7 AP sur Canal 13 AP sur Canal 1
Ca c'est bien si tu as une disposition très en longueur... Sinon ça peut être plus délicat. Deux remarques cependant: - en Europe on peut tirer parti de la disponibilité de 13 canaux pour se mettre sur 1, 5, 9 et 13. Il y a un très très léger chevauchement, mais comme le spectre utilisé est en forme de cloche, c'est très faible. C'est en tous cas vrai en 802.11b, en 802.11g c'est différent, ça dépend de la modulation exacte. - en 802.11a il y a plus de canux non-chevauchants disponibles
Je ne sais pas non plus si le serveur peut arreter d'emettre un flux multicast en l'absence de client mais c'est vrai qu'installer un mrouted sur le serveur pourrait résoudre le problème puisque s'il n'a pas reçu de demande d'abonnement le mrouted bloquerait le flux multicast qui ne "sortirait" pas du serveur. Je pense que je vais tester ça.
Ah, on revient en charte :-)
Jacques. -- Interactive Media Factory Création, développement et hébergement de services interactifs: SMS, SMS+, Audiotel... http://www.imfeurope.com/
Salut,
[mostly complètement HS]
On Tue, 22 Feb 2005 17:35:26 +0100, Vincent Derrien <vincent@ahoup.net>
wrote:
Pour le Wifi, suite à quelques tests, je me suis aperçu que je pouvais
avoir un maximum de 4-5 postes par point d'accès car sinon après le
débit n'est pas suffisant pour avoir une bonne QoS.
Avec quoi, du multicast ou de l'unicast? En multicast (à condition que
l'AP envoie effectivement les paquets IP multicast sous forme de multicast
802.11, ce qui est à ma connaissance toujours le cas, mais on ne sait
jamais...) le nombre de postes ne devrait pas faire de différence. Par
contre, il ne faut pas oublier que les trames multicast sont envoyées à un
débit potentiellement inférieur au débit max (normalement le plus haut
débit du basic rate set), pour être sûr que tout le monde les reçoit. Et
si on utilise du chiffrement (WEP, 802.1X, WPA...), il faut bien s'assurer
que tout le monde gère correctement les clefs multicast (aka clefs de
groupe) qui doivent être distinctes des clefs de session.
Pour les canaux, on peut avoir 3 point d'accès proche sans
chevauchement, donc si je veux en mettre plus il faudra les espacer
assez pour éviter les pertubations. Mais si je configure comme
ci-dessous ça devrai aller, je pense....(il faut que les 2 PA qui sont
sur le canal 1 soit assez éloignés).
AP sur Canal 1 AP sur Canal 7 AP sur Canal 13
AP sur Canal 1
Ca c'est bien si tu as une disposition très en longueur... Sinon ça peut
être plus délicat. Deux remarques cependant:
- en Europe on peut tirer parti de la disponibilité de 13 canaux pour se
mettre sur 1, 5, 9 et 13. Il y a un très très léger chevauchement, mais
comme le spectre utilisé est en forme de cloche, c'est très faible. C'est
en tous cas vrai en 802.11b, en 802.11g c'est différent, ça dépend de la
modulation exacte.
- en 802.11a il y a plus de canux non-chevauchants disponibles
Je ne sais pas non plus si le serveur peut arreter d'emettre un flux
multicast en l'absence de client mais c'est vrai qu'installer un mrouted
sur le serveur pourrait résoudre le problème puisque s'il n'a pas reçu
de demande d'abonnement le mrouted bloquerait le flux multicast qui ne
"sortirait" pas du serveur. Je pense que je vais tester ça.
Ah, on revient en charte :-)
Jacques.
--
Interactive Media Factory
Création, développement et hébergement
de services interactifs: SMS, SMS+, Audiotel...
http://www.imfeurope.com/
On Tue, 22 Feb 2005 17:35:26 +0100, Vincent Derrien wrote:
Pour le Wifi, suite à quelques tests, je me suis aperçu que je pouvais avoir un maximum de 4-5 postes par point d'accès car sinon après le débit n'est pas suffisant pour avoir une bonne QoS.
Avec quoi, du multicast ou de l'unicast? En multicast (à condition que l'AP envoie effectivement les paquets IP multicast sous forme de multicast 802.11, ce qui est à ma connaissance toujours le cas, mais on ne sait jamais...) le nombre de postes ne devrait pas faire de différence. Par contre, il ne faut pas oublier que les trames multicast sont envoyées à un débit potentiellement inférieur au débit max (normalement le plus haut débit du basic rate set), pour être sûr que tout le monde les reçoit. Et si on utilise du chiffrement (WEP, 802.1X, WPA...), il faut bien s'assurer que tout le monde gère correctement les clefs multicast (aka clefs de groupe) qui doivent être distinctes des clefs de session.
Pour les canaux, on peut avoir 3 point d'accès proche sans chevauchement, donc si je veux en mettre plus il faudra les espacer assez pour éviter les pertubations. Mais si je configure comme ci-dessous ça devrai aller, je pense....(il faut que les 2 PA qui sont sur le canal 1 soit assez éloignés).
AP sur Canal 1 AP sur Canal 7 AP sur Canal 13 AP sur Canal 1
Ca c'est bien si tu as une disposition très en longueur... Sinon ça peut être plus délicat. Deux remarques cependant: - en Europe on peut tirer parti de la disponibilité de 13 canaux pour se mettre sur 1, 5, 9 et 13. Il y a un très très léger chevauchement, mais comme le spectre utilisé est en forme de cloche, c'est très faible. C'est en tous cas vrai en 802.11b, en 802.11g c'est différent, ça dépend de la modulation exacte. - en 802.11a il y a plus de canux non-chevauchants disponibles
Je ne sais pas non plus si le serveur peut arreter d'emettre un flux multicast en l'absence de client mais c'est vrai qu'installer un mrouted sur le serveur pourrait résoudre le problème puisque s'il n'a pas reçu de demande d'abonnement le mrouted bloquerait le flux multicast qui ne "sortirait" pas du serveur. Je pense que je vais tester ça.
Ah, on revient en charte :-)
Jacques. -- Interactive Media Factory Création, développement et hébergement de services interactifs: SMS, SMS+, Audiotel... http://www.imfeurope.com/
Vincent Derrien
Avec quoi, du multicast ou de l'unicast? En multicast (à condition que l'AP envoie effectivement les paquets IP multicast sous forme de multicast 802.11, ce qui est à ma connaissance toujours le cas, mais on ne sait jamais...) le nombre de postes ne devrait pas faire de différence. Par contre, il ne faut pas oublier que les trames multicast sont envoyées à un débit potentiellement inférieur au débit max (normalement le plus haut débit du basic rate set), pour être sûr que tout le monde les reçoit. Et si on utilise du chiffrement (WEP, 802.1X, WPA...), il faut bien s'assurer que tout le monde gère correctement les clefs multicast (aka clefs de groupe) qui doivent être distinctes des clefs de session.
Oui mais je n'envoie pas que des flux multicast (il peut y'a avoir plusieurs flux différents vers chaque poste), j'envoie de la VOD en unicast et il peut y avoir de la téléphonie IP. Un poste doit pouvoir avoir 5 Mb de débit pour une bonne QoS et comme en Wifi on partage le média, théoriquement je devrai pour avoir 10 machines pour une norme G à 54 Mbit/s mais suite à différents tests je me suis apercu que pour une bonne diffusion 5 postes par AP est le maximum que je peux avoir.
Ca c'est bien si tu as une disposition très en longueur... Sinon ça peut être plus délicat. Deux remarques cependant: - en Europe on peut tirer parti de la disponibilité de 13 canaux pour se mettre sur 1, 5, 9 et 13. Il y a un très très léger chevauchement, mais comme le spectre utilisé est en forme de cloche, c'est très faible. C'est en tous cas vrai en 802.11b, en 802.11g c'est différent, ça dépend de la modulation exacte. - en 802.11a il y a plus de canux non-chevauchants disponibles
J'ai pensé à cette disposition très en longueur puisque l'implantation se fait dans un grand batiment. Je vais utiliser du 802.11g.
Ah, on revient en charte :-)
C'est vrai qu'on est un peu (voir complètement) HS. Pour les prochaines questions je ferai un tour vers fr.reseaux.* je pense ;)
En tout cas, merci beaucoup pour les infos.
Avec quoi, du multicast ou de l'unicast? En multicast (à condition que
l'AP envoie effectivement les paquets IP multicast sous forme de
multicast 802.11, ce qui est à ma connaissance toujours le cas, mais on
ne sait jamais...) le nombre de postes ne devrait pas faire de
différence. Par contre, il ne faut pas oublier que les trames multicast
sont envoyées à un débit potentiellement inférieur au débit max
(normalement le plus haut débit du basic rate set), pour être sûr que
tout le monde les reçoit. Et si on utilise du chiffrement (WEP, 802.1X,
WPA...), il faut bien s'assurer que tout le monde gère correctement les
clefs multicast (aka clefs de groupe) qui doivent être distinctes des
clefs de session.
Oui mais je n'envoie pas que des flux multicast (il peut y'a avoir
plusieurs flux différents vers chaque poste), j'envoie de la VOD en
unicast et il peut y avoir de la téléphonie IP. Un poste doit pouvoir
avoir 5 Mb de débit pour une bonne QoS et comme en Wifi on partage le
média, théoriquement je devrai pour avoir 10 machines pour une norme G à
54 Mbit/s mais suite à différents tests je me suis apercu que pour une
bonne diffusion 5 postes par AP est le maximum que je peux avoir.
Ca c'est bien si tu as une disposition très en longueur... Sinon ça
peut être plus délicat. Deux remarques cependant:
- en Europe on peut tirer parti de la disponibilité de 13 canaux pour
se mettre sur 1, 5, 9 et 13. Il y a un très très léger chevauchement,
mais comme le spectre utilisé est en forme de cloche, c'est très
faible. C'est en tous cas vrai en 802.11b, en 802.11g c'est différent,
ça dépend de la modulation exacte.
- en 802.11a il y a plus de canux non-chevauchants disponibles
J'ai pensé à cette disposition très en longueur puisque l'implantation
se fait dans un grand batiment. Je vais utiliser du 802.11g.
Ah, on revient en charte :-)
C'est vrai qu'on est un peu (voir complètement) HS. Pour les prochaines
questions je ferai un tour vers fr.reseaux.* je pense ;)
Avec quoi, du multicast ou de l'unicast? En multicast (à condition que l'AP envoie effectivement les paquets IP multicast sous forme de multicast 802.11, ce qui est à ma connaissance toujours le cas, mais on ne sait jamais...) le nombre de postes ne devrait pas faire de différence. Par contre, il ne faut pas oublier que les trames multicast sont envoyées à un débit potentiellement inférieur au débit max (normalement le plus haut débit du basic rate set), pour être sûr que tout le monde les reçoit. Et si on utilise du chiffrement (WEP, 802.1X, WPA...), il faut bien s'assurer que tout le monde gère correctement les clefs multicast (aka clefs de groupe) qui doivent être distinctes des clefs de session.
Oui mais je n'envoie pas que des flux multicast (il peut y'a avoir plusieurs flux différents vers chaque poste), j'envoie de la VOD en unicast et il peut y avoir de la téléphonie IP. Un poste doit pouvoir avoir 5 Mb de débit pour une bonne QoS et comme en Wifi on partage le média, théoriquement je devrai pour avoir 10 machines pour une norme G à 54 Mbit/s mais suite à différents tests je me suis apercu que pour une bonne diffusion 5 postes par AP est le maximum que je peux avoir.
Ca c'est bien si tu as une disposition très en longueur... Sinon ça peut être plus délicat. Deux remarques cependant: - en Europe on peut tirer parti de la disponibilité de 13 canaux pour se mettre sur 1, 5, 9 et 13. Il y a un très très léger chevauchement, mais comme le spectre utilisé est en forme de cloche, c'est très faible. C'est en tous cas vrai en 802.11b, en 802.11g c'est différent, ça dépend de la modulation exacte. - en 802.11a il y a plus de canux non-chevauchants disponibles
J'ai pensé à cette disposition très en longueur puisque l'implantation se fait dans un grand batiment. Je vais utiliser du 802.11g.
Ah, on revient en charte :-)
C'est vrai qu'on est un peu (voir complètement) HS. Pour les prochaines questions je ferai un tour vers fr.reseaux.* je pense ;)
