Discussion :

[fma38]

Bonjour,

Je suis en train de développer un framework python pour le bus domotique KNX :

http://www.pknyx.org

Lors du fonctionnement normal, la communication entre les devices de ce bus se fait comme suit : l'apui sur un bouton (par exemple) va envoyer une trame multicast (KNX, pas ethernet) qui va comporter une adresse de groupe ; les devices programmés avec cette adresse de groupe, et eux seuls, vont réagir et lire la trame, et éventuellement entreprendre une action (en fonction de la donnée envoyée en même temps). Le bouton, lui, ne sait pas qui a réagit. Le gros avantage, c'est que même si un device ne marche plus, le reste continue de marcher.

Il existe des passerelles pour relier le bus (filaire) à un réseau ethernet.

Côté ethernet, ces trames multicast peuvent être mapées simplement (si la passerelle fait office de routeur) sur des trames ethernet multicast UDP.

Dans mon framework, j'ai donc écrit un socket multicast pour envoyer/recevoir ces trames vers/depuis la passerelle-routeur.

Voici le code de ce socket :

http://www.pknyx.org/browser/trunk/p...icastSocket.py

Il marche très bien en tant que tel.

Ce socket est utilisé dans le framework au niveau du transceiver de la couche 2 de la pile OSI (link layer) :

http://www.pknyx.org/browser/trunk/p...Transceiver.py

(au passage, ma pile est encore très pourrie, vu que 1) je ne connais pas les spécification exactes KNX 2) je découvre les piles OSI).

Comme vous le voyez, j'ai 2 threads reliés à des queues : un pour recevoir, un pour envoyer. Chacun utilisant une instance propre du socket multicast.

Et c'est là que ça coince... Le socket de reception semble 'consommer' les données envoyées par le socket d'émission ! Celles-ci ne parviennent plus à la passerelle-routeur. Bien sûr, je vois localement mes données émises (boucle), mais ça ne me pose pas de problème.

À la limite, je comprend cette histoire de boucle, qui boufferait les données, lesquelles ne seraient alors plus transmises, mais ce qui est moins compréhensible, c'est que si je lance une autre instance de ma pile sur la même machine, elle reçoit bien également ces données ! Mais pas la passerelle-routeur... Je n'ai pas pu faire de tests sur une autre machine locale pour vérifier si les données arrivent ou pas (voir plus bas).

Ce qui me fais rager, c'est que mon code a eu marché, si-si !!! Mais impossible de revenir à la version correcte. Donc soit j'ai vraiment pété un truc dans mon code (et je n'ai pas commité la version qui a marché), soit quelque chose à également changé sur mon système. Je dis ça car je voulais tester sur une autre machine voir si les trames multicast UDP arrivaient jusque là. Mais impossible de lancer la stack. Sur cette machine, j'obtiens :

Code :

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

1
2
self.setsockopt(socket.SOL_IP, socket.IP_MULTICAST_IF, value)
error: [Errno 99] Cannot assign requested address

Là, j'avoue que ça me dépasse. Cette machine n'a pas le même noyau (3.2 contre 3.9 pour l'autre). Est-ce que ça peut venir de là ? Ou y a-t-il des configs spéciales à faire pour que ça tourne ?

Voili. Si un expert dans le domaine multicast pouvais éclairer ma lanterne, je lui en serais reconnaissant !

Merci d'avance.

[fma38]

Et c'est là que ça coince... Le socket de reception semble 'consommer' les données envoyées par le socket d'émission ! Celles-ci ne parviennent plus à la passerelle-routeur.

J'ai omis de préciser un truc important : si je ne lance pas le thread de réception, les données arrivent bien sur la passerelle-routeur... C'est pourquoi je dis que le socket de réception 'consomme' les données localement.

[fma38]

Bon, trouvé : il ne fallait pas spécifier l'adresse dans le bind() !!!

Si quelqu'un peut m'expliquer pourquoi, je suis preneur.

Si vous avez également une réponse concernant le souci avec le noyau 3.2, je suis preneur aussi !