Art-Net 3 : De A à Z Chapitre II : Découverte (ArtPoll & ArtPoll Reply)

Nous continuons notre découverte de l’Art-Net et cette fois plus particulièrement sur la stratégie de découverte du réseau. Nous allons définir le paquet Art-Net, sa structure et les mécaniques en place pour réaliser l’étape de négociation et de découverte du réseau. Avant de continuer il est préférable de lire le premier chapitre sur l’Art-Net 3 de A à Z.

La trame Art-Net

Les données qui constituent la trame Art-Net vont donc s’inscrire directement dans le champ des données du paquet UDP (vu au chapitre précédent). Si on prend un peu de recule on peut admettre la structure suivante :

On parlera donc vulgairement de paquets Art-Net pour indiquer que nous regroupons la trame Art-Net encapsulée dans un paquet UDP. Nous allons revenir sur sa structure à la fin du chapitre.

La découverte du réseau

Comme indiqué sur l’amorce du chapitre, une découverte du réseau est nécessaire pour découvrir les éléments le constituant. Les composants Art-Net ne peuvent lire que les paquets UDP, les autres paquets doivent êtres ignorés. Le premier paquet envoyé est un ArtPoll, il ne peut être envoyé que par un contrôleur. Les nodes, medias serveurs et autres contrôleurs vont répondre via un paquet ArtPollReply afin d’indiquer ce qu’ils sont capables de faire comme opérations.

Ce premier paquet est évidement envoyé en broadcast sur l’adresse de broadcast de votre réseau, si le réseau possède un sub-mask 255.0.0.0 alors l’adresse IP de broadcast sera 2.255.255.255 en UDP sur le port 0x1936. L’intérêt de l’envoyer en broadcast est de n’envoyer qu’un paquet à l’ensemble des éléments. Cela évite une saturation du réseau on ne tente pas d’envoyer un paquet de découverte sur chaque adresse IP, surtout en classe A).

Nous utiliserons des schémas pour illustrer cette partie (CTRL = Contrôleur, MS : Media-Server, Node : Node). Au démarrage on retrouve donc un ArtPoll paquet qui est diffusé à l’ensemble des composants :

Le contrôleur qui vient d’envoyer le paquet va attendre un paquet dit “ArtPollReply” en réponse. La réponse doit lui parvenir dans les 3 secondes. Notre contrôleur va lui aussi recevoir le “ArtPoll” paquet car il écoute aussi sur l’adresse de broadcast. Il va donc naturellement lui aussi émettre une réponse “ArtPollReply”. Cela permet de s’assurer que les autres contrôleurs sur le réseau détectent à leur tour notre nouveau contrôleur sans envoyer d’ArtPoll et la prise en compte immédiate. Néanmoins, toutes les 2.5 à 3 secondes les contrôleurs doivent envoyer un “ArtPoll” afin de s’assurer que ceux-ci sont toujours connectés au réseau.

On peut illustrer la réponse avec le schéma suivant :

Inspection du ArtPoll paquet

Nous n’allons rien laisser nous échapper, cette partie peut être un peu plus complexe à comprendre. Elle décrit juste un peu plus en détails ce que nous avons découvert au paragraphe précédent. Voici d’après les spécifications officielles la composition d’un paquet ArtPoll :

Et une description un peu plus française :

1. Un tableau de 8 caractères avec la chaîne ‘Art-Net’ et un bit de terminaison : 0x00.
   C’est cette information qui permet d’identifier une trame Art-Net
2. L’OpCode permet d’indiquer le type de paquet à transmettre, nous en connaissons pour l’instant deux mais il y en aura d’autres : ArtPoll (0x2000), ArtPollReply (0x2100), etc…
3. ProtVerHi indique la version majeure de l’Art-Net que nous utilisons
4. ProtVerLow indiquer la version mineure de l’Art-Net que nous utilisons
5. TalkToMe permet de donner des indications sur la façon de communiquer, il s’agit de 8 bits éclatés :
   • Des bits 7 à 4 : Laisser à zéro, ils ne sont pas utilisés et ignorés.
   • Le bit 3 : Indique le mode de transmission des messages de diagnostiques, nous verrons cette partie plus tard. Si le bit vaut 0 alors les messages de diagnostiques seront diffusés sinon “unicastés”.
   • Le bit 2 : Indique si nous devons recevoir des messages de diagnostiques
   • Le bit 1 : Nous recevons uniquement un ArtPollReply paquet en réponse à un ArtPoll ou ArtAddress paquet. Si il vaut 1 alors le node devra envoyer un ArtPollReply dés que sa condition ou configuration change
   • Le bit 0 indique si le contrôleur est déprécié, j’avoue ne pas encore bien comprendre ce bit
6. Priority : indique la priorité du code de diagnostique, il peut varier de faible (0x10) à critique (0xe0). Nous reviendrons plus tard sur ce point.

Inspection du ArtPollReply paquet

Ce paquet est très complexe car il décrit toutes les capacités du composant. Il est envoyé en réponse du ArtPoll paquet. Il est uniquement envoyé en mode diffusion sur l’adresse de broadcast afin de permettre aux autres composants de pouvoir actualiser l’état du réseau. L’ArtPollReply doit donc être envoyé par l’ensemble des composants du réseau connectés et allumés même si ils ne sont pas utilisés. La table décrivant ce paquet est un peu longue, vous pouvez la consulter sur les spécifications de l’Art-Net. Néanmoins, nous allons voir les principales informations présentes dans ce paquet.

• On retrouve toujours l’en-tête habituelle identifiant le paquet
  
• Les informations d’adressage, à savoir l’adresse IP du composant et le port utilisé qui doit toujours être (0x1936). Je ne sais pas pourquoi il est indiqué si il ne change pas, peut être pour des évolutions à venir ou étendre le réseau. Je ne pense pas que l’ensemble des composants Art-Net du marché permettent ce changement de port. A suivre…
  
• La version du firmware du composant
  
• L’encodage de l’univers, voir chapitre 1 pour plus d’informations sur le fonctionnement des univers
  
• L’identification du constructeur et la version. La version du bios peut aussi être indiquée.
  
• Quelques informations diverses sur la capacité du composant, comme l’état la méthodologie d’adressage, le type de démarrage utilisé (normal ou depuis une ROM), l’utilisation du RDM (le RDM est un protocole permettant de récupérer des informations d’état d’un composant, exemple : un problème matériel sur un projecteur).
  
• Le nom du composant pour les humains, c’est souvent ce qui indiqué sur l’afficheur LCD d’un node, le nom du projecteur, cette information n’est pas “interprétable” par le protocole mais elle sert d’information. N’oublions pas que nous parlons aussi à des humains.
  
• Le nombre de ports et leurs configurations, cela peut permettre de décrire un routeur Art-Net avec les sorties/entrées utilisées et leur fonction (DMX512, MIDI, Avab, Colortran CMX, ADB 62.5, Art-Net). Et oui !! Nous pouvons bien utiliser l’Art-Net pour faire passer d’autres informations. On retrouvera donc aussi les stratégies de merge pour une sortie DMX par exemple (HTP vs LTP).
  
• L’adresse matérielle ou MAC, ainsi que l’adresse IP de binding (un composant Art-Net peut avoir plusieurs adresses IP, c’est en général l’adresse IP principale, celle de l’écran LCD ou celle par défaut : étiquette du node).
  
• On retrouve en fin de trame, une indication si le composant est compatible DHCP (voir chapitre 1) et un grand espace de 26*8 bits non utilisé appelé filler pour les éventuelles évolutions du protocole. On ne retrouvera que des zéros dans cette zone.

Et voilà !

Le chapitre 2 est maintenant terminé, nous savons maintenant assez finement comment se passe la négociation d’un réseau Art-Net. La suite sur les paquets ArtDmx au chapitre 3.