| « Folie | Grève des audiences » |
Le réseau selon Microsoft
Je viens de perdre deux jours à essayer de comprendre comment fonctionnait un réseau vu par les ingénieurs de chez Microsoft. C'est assez pathétique. À toutes fins utiles, je vous donne le résultat de mes essais nombreux et variés.
Posons en bon matheux le problème et considérons une caméra infrarouge possédant une résolution de 640 par 480 en 256 niveaux de gris. La caméra toute bête, reliée à un boîtier de conversion PAL/TCPIP. Le débit pour vingt-cinq images par seconde est d'un peu moins de 8 Mo/s et doit passer raisonnablement sur un réseau 100BaseTX. Ce boîtier est capable de causer en multicast sur IPv4 et je pensais naïvement pouvoir installer deux logiciels écoutant ce multicast sur la même machine.
Grave erreur, d'après Microsoft, c'est tellement bizarre comme idée que c'est impossible. Pas d'autre choix donc que de demander à ce boîtier de m'envoyer des paquets en unicast à destination de la machine en question, charge alors à cette machine de relayer en multicast cette fois-ci ce trafic vers un logiciel de calcul sur cette même machine et un poste de visualisation trois cents mètres plus loin. L'idée est intéressante et je dois dire assez jolie pour que je code la fonction de relai ainsi que la fonction de réception.
Je rajoute donc un fil d'exécution dans le programme chargé de recueillir les paquets UDP en provenance du boîtier de la caméra et de les relayer en multicast UDP sur l'adresse 224.16.1.1 et le port 10500. Ça fonctionne, cela fonctionne même bien pour un truc sous Windows, mais lorsque l'outil tourne, le réseau s'écroule. Il est même impossible d'utiliser l'imprimante réseau sur un réseau pourtant gigabit ! Chose amusante, les machines Linux fonctionnent parfaitement et peuvent accéder au réseau comme si de rien n'était.
Je dois dire pour être honnête que le programme est écrit en Visual C++ 2010 et tourne sous Windows 7 Ultimate 64 bits out of the box. Il ne s'agit pas d'une installation bricolée ou d'une quelconque version plus ou moins foireuse du système de Redmond. Bon, installation de Wireshark pour regarder ce qui se passe. Je récupère partout sur le réseau et même sur des machines qui ne se sont pas abonnées mes paquets video qui sont bien envoyés vers la bonne adresse et le bon port. Chose amusante, ces paquets sont marqués comme étant des paquets multicast, mais ils ont le drapeau broadcast activé.
J'ai donc la source du problème. Cette saleté de Windows 7 ne peut pas envoyer un paquet multicast et n'honore pas le protocole IGMP qu'il sait pourtant envoyer. En désespoir de cause, je teste le même exécutable sur un Windows 2008R2. Miracle, ça fonctionne. Seulement trois jours de perdus pour identifier le problème avec en prime un contact au support de Microsoft (niveau 3, vu le prix des licences, j'y ai accès) qui n'a pas su répondre à cette question pourtant simple que beaucoup d'utilisateurs doivent se poser.
Vous me direz que mon installation de Windows 7 doit poser problème. J'avoue avoir essayé sur plusieurs machines installées avec toutes les moutures possibles et imaginables de cette saleté et que tous présentaient le même problème, à savoir la transformation de paquets unicast en multicast dans le dos de l'utilisateur. Imaginez donc que les petits gars de chez Microsoft ont décidé qu'un Windows 7 n'a aucune raison de faire du multicast et que les paquets multicast, finalement, seraient tout aussi bien envoyés en broadcast quitte à ennuyer tout le monde.
Vous voulez faire du multicast, achetez donc une version serveur de notre système d'exploitation fabuleux. Ce n'est pas un bug, c'est une feature !
1 commentaire
Un témoignage (à un autre niveau, car hors du domaine professionnel).
Pour une communication Ethernet entre un PC et une carte de développement avec un uP Motorola MC9S12NE64 j’ai développé quelques applis en C avec winsock en mode Raw IP. Quelle surprise de constater que cela ne fonctionnait plus du tout sous Windows XP et encore moins (sic) sous Windows 7… Renseignements pris, il semble que uSoft ne voit pas pourquoi le possesseur d’un PC sous Windows aurait besoin d’utiliser le mode Raw IP. J’ai dû modifier mon soft (et celui de la carte) pour passer en UDP, et bien sûr toutes les possibilités intéréssantes qu’offre le mode Raw IP se sont envolées.
Entre autres, avant je pouvais voir sur le PC tous les paquets de mon LAN, maintenant je ne peux plus. Du moins, plus de la même façon. Car la carte de développement, elle, ne tournant pas sous Windows, je reste maître du sous-ensemble hardware Ethernet du uP en mode Raw IP qui voit donc passer tous les paquets LAN : cette carte renvoie les données (encapsulés dans de l’UDP) vers le PC qui peut alors les visualiser. J’ai trouvé assez amusant de pouvoir contourner cette limitation (bien que nécéssitant un hardware externe). Ce doit être bien moins amusant quand il s’agit d’une appli chez un client qui attend montre en main.
Pas de conséquence puisque c’est hors du domaine professionnel, mais je trouve pour le moins cavalier que les versions les plus récentes d’un système restreignent ainsi la souplesse d’une machine.
Même remarque en ce qui concerne l’accès aux flux média : il devient de plus en plus difficile pour un programme ‘maison’ d’avoir accès aux E/S audio et vidéo d’un PC ( via Winmm.* ). J’avais développé un oscilloscope + analyseur de spectre (avec FFT) qui visualise les données en provenance de l’entrée audio de la carte son du PC. Cela fonctionne sous Windows XP, mais sous Windows 7 je n’ai accès qu’au microphone mais plus du tout à l’entrée ligne de la carte son.
