Guide pratique du multicast sur les réseaux TCP/IP

Le multicast est… un besoin. Ou du moins dans certains cas. Si vous avez des informations (beaucoup d'informations, le plus souvent) qui doivent être transmises à un ensemble de machines (mais le plus souvent pas toutes) au travers d'internet, alors le multicast est une bonne solution. Un cas typique d'utilisation du multicast, est la diffusion audio ou vidéo temps réel à un ensemble de machines donné qui ont précédemment rejoint une conférence distribuée.

Il est à noter que le multicast ressemble à la radio ou à la télévision, en ce sens que seuls les utilisateurs qui ont réglé leur récepteur (en sélectionnant une fréquence particulière) reçoivent l'information. De ce fait, vous n'entendez que le canal qui vous intéresse, pas les autres.

Unicast est tout ce qui n'est ni du broadcast ni du multicast. Bien sûr, cette définition n'est pas vraiment claire… Expliquons nous : lorsque vous envoyez un paquet et qu'il y a seulement un émetteur (vous) et un récepteur (la personne à qui vous envoyez le paquet), alors il s'agit d'un mode de transmission unicast. TCP est par nature orienté unicast. UDP est déclinable selon plus de modèles, mais si vous envoyez des paquets UDP et qu'il n'y a qu'une personne qui est censée les recevoir, alors il s'agit aussi d'une transmission unicast.

Pendant des années les transmissions unicast ont semblé être suffisantes pour Internet. Cela fut le cas jusqu'en 1993 où la première mise en œuvre du multicast vit le jour à l'occasion de la parution de la distribution BSD 4.4. Apparemment personne n'en avait jamais eu besoin avant cette date. Quels sont donc les nouveaux problèmes liés au multicast ?

Il n'est peut-être pas nécessaire de dire ici, qu'internet a beaucoup changé depuis ses « premiers jours ». Particulièrement, l'apparition du web a considérablement transformé la situation : les personnes ne voulaient plus seulement se connecter à des hôtes distants, serveurs de mails ou encore FTP. Ils voulaient maintenant voir les images des personnes qu'ils côtoient sur les pages de leurs sites web personnels, et plus tard les voir et les entendre.

Avec la technologie d'aujourd'hui il est possible de supporter le coût d'établissement d'une connexion avec ceux qui veulent voir votre page web personnelle. Cependant, si vous diffusez de l'audio et de la vidéo, vous aurez besoin d'un volume de bande passante énorme comparé aux applications web. Vous avez alors -ou vous aviez, si vous utilisez déjà le multicast- deux solutions : établir une connexion unicast avec chacun de vos destinataires, ou utiliser le broadcast. La première solution n'est pas envisageable : si nous nous accordons sur le fait qu'une seule connexion audio/vidéo consomme énormément de bande passante, imaginez alors le volume consommé par une centaine ou un millier de ces connections. Aussi bien l'ordinateur, émetteur des données, que le réseau lui étant lié succomberait [ndt : dans une grande souffrance].

Le broadcast, ou envoi par diffusion, semble être une solution, mais pas nécessairement la solution. Si vous souhaitez que toutes les machines de votre réseau écoutent la conférence, vous pouvez utiliser le broadcast. Dans ce cas, les paquets ne sont émis qu'une seule fois et chaque hôte les reçoit sur une adresse de broadcast ; adresse sur laquelle ils pourront, de la même manière, émettre. Cependant, il se peut que seulement peu d'utilisateurs soient intéressés par ces paquets. Plus encore, il se peut que certains utilisateurs soient vraiment intéressés par votre conférence, mais qu'ils se trouvent en dehors de votre réseau local, à seulement quelques routeurs de là. Vous n'êtes pas sans savoir que si le broadcast fonctionne bien à l'intérieur d'un réseau local, des problèmes surviennent lorsque vous désirez diffuser des paquets qui doivent être routés au travers de différents réseaux locaux.

La meilleure solution serait alors d'émettre des paquets à une adresse spéciale, telle une fréquence donnée comme dans le cas d'une transmission radio ou de télévision. Dans ce cas, tous les hôtes qui ont décidé de joindre la conférence seront demandeurs des paquets portant cette adresse de destination ; ils les lisent lorsqu'ils passent sur le réseau et les transmettent à la couche IP pour qu'ils soient démultiplexés. Cette technique est similaire au broadcast en ce sens que vous n'émettez qu'un seul paquet en diffusion et que tous les hôtes du réseau peuvent le reconnaître et le lire ; elle est différente en ce sens que tous les paquets multicast ne sont pas lus et traités, mais seulement ceux qui ont été précédemment enregistrés dans le noyau comme étant intéressants.

Ces paquets spéciaux sont routés au niveau du noyau comme tout autre paquet car il s'agit de paquets IP. L'unique différence réside dans l'algorithme de routage qui indique au noyau qui doit être routé et que faire des paquets à router.

Comme vous le savez probablement, les adresses IP sont divisées en « classes ». Ces classes sont basées sur l'ordre des bits de poids fort de l'adresse IP :

La classe qui nous intéresse est la classe D. Chaque datagramme dont l'adresse de destination (codée sur 32 bits) commence par « 1110 » est un datagramme IP Multicast.

Les 28 autres bits identifient le groupe auquel le datagramme est envoyé. Poursuivant avec la précédente analogie, il est nécessaire de régler sa radio pour entendre un programme qui est retransmis sur une fréquence donnée. Dans notre cas, il convient de procéder de la même façon : vous devez « régler » votre noyau pour qu'il reçoive les paquets qui sont émis à destination d'un groupe multicast donné. Lorsque cette opération est effectuée, il est dit que l'hôte a joint ce groupe ; ceci sur une interface spécifiée : vous trouverez plus d'informations sur ce propos par la suite.

Il existe des groupes multicast spéciaux, dits « groupes multicast bien connus », vous ne devez pas les utiliser pour vos applications, du fait de l'usage bien spécifique auquel ils sont destinés :

Tous ces groupes multicast spéciaux sont régulièrement publiés dans le RFC « Assigned Numbers »

Dans tous les cas, l'intervalle allant de 224.0.0.0 à 224.0.0.255 est reservé pour les contenus locaux (comme des tâches administratives ou de maintenance) et les datagrammes destinés à ces adresses ne sont jamais retransmis par les routeurs multicast. De la même manière, l'intervalle allant de 239.0.0.0 à 239.255.255.255 est reservé pour des raisons d'administration (cf section 2.3.1 pour de plus amples imformations à ce propos).

Il existe trois niveaux de conformité différents, que les hôtes peuvent implémenter, en accord avec la spécification multicast, permettant de gérer les différents services mis en commun.

Il est évident que le trafic multicast doit être encapsulé par une couche transport comme UDP. En effet, TCP fournit des connections point-à-point, ce qui n'est pas envisageable pour du trafic multicast. Il est à noter que des recherches sont effectuées dans ce domaine pour définir et implémenter un nouveau protocole de transport orienté multicast. Consultez la section Protocoles de transport multicast pour plus de détails.

En principe, une application nécessite seulement l'ouverture d'une prise réseau UDP qu'elle remplit de données, qui seront envoyées à destination d'une adresse multicast (classe D). Cependant, certaines opérations doivent être contrôlées lors du processus d'envoi.

Les outils de gestion de sessions ont été placés après les autres, car ils nécessitent quelques explications. Lorsque qu'une conférence a lieu, il est assigné pour chaque service (audio, vidéo, tableau-blanc partagé, etc) un ou plusieurs groupes multicast, eux-mêms associés à un numéro de port. Les conférences qui vont avoir lieu sont périodiquement annoncées sur le MBone. Ces annonces contiennent des informations à propos des groupes multicasts, des numéros de ports et des programmes qui peuvent être utilisés (vic, vat, …). Les outils de gestion de sessions « écoutent » ces informations et vous les annoncent de manière à ce qu'elles soient facilement joignables. Vous pouvez ainsi décider quelle conférence vous intéresse. Ainsi, au lieu de démarrer chaque programme qui sera utilisé et lui indiquer les groupes multicast et les numéros de ports qu'il vous faut joindre, il vous suffit de cliquer sur l'annonce et l'outil de gestion de sessions démarre les bonnes applications, en leur communiquant toutes les informations nécessaires pour joindre la conférence. Les outils de gestion de sessions vous permettent généralement d'annoncer votre propre conférence sur le MBone.

Vous devez décider, en tant que programmeur, si les données que vous voulez émettre doivent être retournées ou non sur votre hôte. Si vous pensez avoir plus d'un processus ou utilisateur en écoute, alors un retour doit être activé. À contrario, si vous émettez des images que votre caméra vidéo produit, vous ne nécessiterez probablement pas de retour, à moins que vous désiriez les voir sur votre écran. Dans ce dernier cas, votre application recevra déjà certainement les images depuis le périphérique connecté à votre ordinateur pour les envoyer à la prise réseau. De ce fait, l'application possède déjà les données, et cela devient improbable que vous vouliez les recevoir de nouveau au travers de la prise réseau.

Il est à noter que le retour est activé par défaut.

Comme optval est un pointeur, vous ne pouvez pas écrire :

setsockopt(socket, IPPROTO_IP, IP_MULTICAST_LOOP, 0, 1);

pour désactiver le loopback vous devez écrire :

u_char loop;
setsockopt(socket, IPPROTO_IP, IP_MULTICAST_LOOP, &loop, sizeof(loop));

et donnez la valeur 1 à loop pour activer le retour et 0 pour le désactiver.

Pour savoir si une prise réseau a activé ou non son retour, utilisez quelque chose comme :

u_char loop;
int size;
getsockopt(socket, IPPROTO_IP, IP_MULTICAST_LOOP, &loop, &size)

Si rien n'est précisé, les datagrammes multicast sont envoyés avec comme valeur par défaut 1, dans le but d'éviter qu'ils soient transférés sur tout le réseau local. Pour changer la valeur du TTL (de 0 à 255), mettez cette valeur dans une variable (ici nommée « ttl ») et écrivez dans votre programme :

u_char ttl;
setsockopt(socket, IPPROTO_IP, IP_MULTICAST_TTL, &ttl, sizeof(ttl));

Le comportement avec getsockopt() est similaire à celui vu avec IP_MULTICAST_LOOP.

Traditionnellement, l'administrateur système indique l'interface multicast par défaut sur laquelle les datagrammes sont envoyés. Le programmeur peut surcharger cela et choisir ainsi à l'aide de cette option une interface de sortie concrête pour une prise réseau donnée.

struct in_addr interface_addr;
setsockopt (socket, IPPROTO_IP, IP_MULTICAST_IF, &interface_addr,
            sizeof(interface_addr));

Ainsi, tout le trafic multicast généré par cette prise réseau sera envoyé sur l'interface choisie. Pour revenir au comportement par défaut et laisser le noyau choisir l'interface de sortie (choix basé sur la configuration de l'administrateur système), il suffit d'appeler setsockopt() avec la même option et INADDR_ANY comme valeur pour l'interface.

Pour connaitre ou sélectionner une interface de sortie, les ioctls suivants peuvent être utililisés : SIOCGIFADDR (pour obtenir les adresses des interfaces), SIOCGIFCONF (pour obtenir la liste de toutes les interfaces) et SIOCGIFFLAGS (pour obtenir les fonctionnalités d'une interface et, de fait, permet de déterminer si l'interface supporte le multicast ou non. Fonction indiquée par l'option IFF_MULTICAST).

Si un hôte a plus d'une interface et que l'option IP_MULTICAST_IF n'est pas mentionnée, alors les transmissions multicast sont émises sur l'interface par défaut, bien que les interfaces restantes puissent être utilisées pour des retransmissions multicast si l'hôte joue le rôle de routeur multicast.

Rappelez vous que vous devez informer le noyau des groupes multicast qui vous intéressent. Si aucun processus n'est intéressé par un groupe donné, les paquets provenant de ce groupe et qui arrivent sur notre hôte sont rejetés. Pour informer le noyau, des groupes qui vous intéressent, et de fait, pour devenir membre de ce groupe, vous devez d'abord remplir une structure ip_mreq qui sera passée plus tard au noyau dans le champ optval avec l'appel système setsockopt().

La structure ip_mreq (provenant de /usr/include/linux/in.h) a les membres suivants :

struct ip_mreq
{
  struct in_addr imr_multiaddr;   /* adresse IP du groupe multicast */
  struct in_addr imr_interface;   /* adresse IP de l'interface locale */
};

Note : la définition « physique » de la structure est contenue dans le fichier spécifié ci-dessus. Vous ne devez en aucun cas inclure <linux/in.h> si vous souhaitez que votre code soit portable. En lieu et place, incluez <netinet/in.h>, qui inclut à son tour <linux/in.h>.

Le premier membre, imr_multiaddr, contient l'adresse du groupe que vous désirez joindre. Souvenez-vous que l'appartenance à un groupe se fait aussi par le biais d'une interface, pas uniquement sur l'adresse du groupe. C'est la raison pour laquelle vous devez fournir une valeur au second membre : imr_interface. De cette façon, si vous êtes sur un hôte ayant plusieurs interfaces multicast, vous pouvez joindre un même groupe par le biais de différentes interfaces. Si vous ne désirez pas indiquer d'interface, vous pouvez toujours remplir ce dernier membre avec un joker (INADDR_ANY), alors le noyau choisira de lui même l'interface.

Une fois la structure remplie (définie en tant que struct ip_mreq mreq;) vous avez juste à appeler setsockopt() de cette manière :

setsockopt (socket, IPPROTO_IP, IP_ADD_MEMBERSHIP, &mreq, sizeof(mreq));

Notez que vous pouvez joindre plusieurs groupes à travers la même prise réseau. Cette limite supérieure est fixée par IP_MAX_MEMBERSHIPS et, a pour la version 2.0.33 du noyau Linux, la valeur de 20.

La procédure nécessaire pour quitter un groupe est semblable à celle nécessaire pour le joindre.

struct ip_mreq mreq;
setsockopt (socket, IPPROTO_IP, IP_DROP_MEMBERSHIP, &mreq, sizeof(mreq));

Où mreq est une structure contenant les mêmes données que celles utilisées lorsque ce groupe fût joint. Si le membre imr_interface contient la valeur INADDR_ANY, alors le premier groupe pouvant correspondre est supprimé.

Si vous avez rejoint un grand nombre de groupes sur une même prise réseau, il n'est pas nécessaire de supprimer toutes les souscriptions pour terminer. Lorsque vous fermez une prise réseau, toutes les souscriptions associées à cette prise sont supprimées par le noyau. Il en est de même si le processus qui a ouvert la prise est tué.

Cependant, gardez à l'esprit que si un processus abandonne la souscription à un groupe, cela n'implique pas forcément l'arrêt de la transmission des datagrammes du groupe en question à l'hôte. En effet, si une autre prise a joint ce groupe avec la même interface avant le IP_DROP_MEMBERSHIP, alors l'hôte continuera à être membre de ce groupe.

ADD_MEMBERSHIP (aussi bien que DROP_MEMBERSHIP) est une opération non-bloquante. Il renvoie un résultat, immédiatement, indiquant s'il a réussi ou échoué.

Lorsque nous avons parlé de IP_ADD_MEMBERSHIP et de IP_DROP_MEMBERSHIP, nous avions dit que l'information délivrée était utilisée par le noyau pour accepter ou refuser les datagrammes multicast. Cela est vrai mais pas complêtement. Une telle simplification impliquerait que les datagrammes multicast de tous les groupes multicast à travers le monde seraient reçus par notre hôte, et alors il vérifierait les souscriptions des processus s'exécutant sur lui et déciderait s'il délivre l'information ou non. Comme vous pouvez l'imaginer, cela serait du gaspillage de bande passante.

De fait actuellement, un hôte informe son routeur des groupes multicasts qui l'intéressent ; alors, ce routeur informe à son tour les routeurs en amont qu'il souhaite recevoir le trafic en question, et ainsi de suite. Les algorithmes employés servant à demander le trafic d'un groupe donné, ou à l'inverse ceux pour terminer une souscription, peuvent varier. Cependant, il y a quelque chose qui ne change jamais : la manière dont cette information est transmisse. IGMP est utilisé pour cela. IGMP signifie Internet Group Management Protocol. C'est un protocole similaire par de nombreux aspects à ICMP. Il porte un numéro de protocole égal à 2 et ses messages sont transportés dans des datagrammes IP. Tous les hôtes compatibles multicast niveau 2 doivent implémenter ce protocole.

Comme dit précédemment, IGMP est utilisé aussi bien par les hôtes pour donner des informations de souscription à ses routeurs, que par les routeurs pour communiquer entre eux. Par la suite, il ne sera question que des relations entre les hôtes et les routeurs, principalement parce que les informations décrivant les communications entre routeurs (autres que celles provenant du source code de mrouted, RFC-1075) et décrivant le protocole de routage multicast « distance-vecteur » sont maintenant obsolètes. mrouted implémente quant à lui une version de ce protocole non encore documentée.

La version 0 d'IGMP est spécifiée dans le RFC-988 qui est maintenant obsolète. Plus personne n'utilise la version 0 de nos jours.

La version 1 d'IGMP est décrite dans le RFC-1112 et, bien qu'elle soit mise-à-jour par le RFC-2236 (IGMP version 2), elle est encore largement utilisée.

Le noyau Linux implémente complètement IGMP version 1 et en partie la version 2.

Vous trouverez ci-dessous une description informelle du protocole. Vous pouvez consulter le RFC-2236 pour une description formelle, avec beaucoup de diagrammes d'états et d'expiration de délais.

Tous les messages IGMP ont la structure suivante :

Dans le cas d'IGMP version 1 (appelé ci-après IGMPv1) le champ « temp maximum de réponse » est marqué comme « inutilisé ». Il est rempli de zéros lors d'une émission et est ignoré à la réception. De plus, cette version d'IGMP coupe le champ « type » en deux sous champs de longueur 4 bits : « version » et « type ». Comme IGMPv1 identifie un message d'interrogation de souscription comme étant 0x11 (version 1, type 1) et IGMPv2 aussi, les 8 bits ont la même signification.

Je pense qu'il est plus instructif de donner d'abord une description d'IGMPv1 et de pointer ensuite les additions faites par IGMPv2.

À la lecture de la description faite ci-dessous, gardez à l'esprit qu'un routeur multicast reçoit tous les datagrammes IP multicast.

Cette sous-section donne le point de départ de l'étude de l'implémentation du multicast dans le noyau Linux. Cela n'explique pas l'implémentation faite. Elle indique juste où trouver les éléments.

L'étude a été menée sur la version 2.0.32, de ce fait il se peut qu'elle soit dépassée au moment où vous allez la lire (le code réseau du noyau semble avoir beaucoup changé dans les versions 2.1.x).

Le code multicast dans les noyaux Linux est toujours entouré par une paire de balises #ifdef CONFIG_IP_MULTICAST / #endif, de cette façon vous pouvez l'inclure ou l'exclure de votre noyau selon vos besoins (cette inclusion/exclusion est faite à l'étape de compilation, comme vous le savez probablement… Les #ifdefs sont interprétés par le pré-processeur. La décision est prise selon les choix que vous avez effectués lors du make config, make menuconfig ou make xconfig).

Vous désirez probablement activer les fonctionnalités multicast, mais si votre machine Linux n'a pas à se comporter comme un routeur multicast, vous n'aurez sûrement pas besoin d'activer le routage multicast du noyau. Le code concernant le routage multicast est contenu entre la paire de balises #ifdef CONFIG_IP_MROUTE / #endif.

Les sources du noyau sont couramment placées dans le répertoire /usr/src/linux. Cependant, l'emplacement peut changer, de ce fait l'emplacement du répertoire de base des sources du noyau sera designé ici comme étant LINUX. De ce fait, LINUX/net/ipv4/udp.c correspond à /usr/src/linux/net/ipv4/udp.c si vous avez extrait les sources du noyau dans le répertoire /usr/src/linux.

Toutes les interfaces multicast désignées dans cette section et dédiées à la programmation d'applications multicast, s'utilisent au travers des appels systèmes setsockopt() / getsockopt().

L'un comme l'autre est implémenté au moyen de fonctions qui effectuent quelques tests pour vérifier les paramètres qui leurs sont passés et qui, à tour de rôle, appellent une autre fonction qui effectue quelques tests complémentaires, démultiplexant l'appel passé dans le paramètre level pour chaque appel système, et appelle alors une autre fonction qui… (si vous êtes intéressé par tous ces sauts, vous pouvez les suivre dans LINUX/net/socket.c (fonctions sys_socketcall() et sys_setsockopt()), LINUX/net/ipv4/af_inet.c (fonction inet_setsockopt()) et LINUX/net/ipv4/ip_sockglue.c (fonction ip_setsockopt())).

Le fichier qui nous intéresse ici est LINUX/net/ipv4/ip_sockglue.c. Nous y trouvons ip_setsockopt() et ip_getsockopt() qui sont essentiellement des switchs (après quelques vérifications d'erreurs) vérifiant chaque valeur possible pour optname. Tout comme les options unicast, les options multicast sont capturées : IP_MULTICAST_TTL, IP_MULTICAST_LOOP, IP_MULTICAST_IF, IP_ADD_MEMBERSHIP et IP_DROP_MEMBERSHIP. Avant le switch, un test est fait pour savoir si les options sont spécifiques au routeur multicast, et dans ce cas, elles sont redirigées vers les fonctions ip_mroute_setsockopt() et ip_mroute_getsockopt() (fichier LINUX/net/ipv4/ipmr.c).

Dans le fichier LINUX/net/ipv4/af_inet.c nous pouvons voir les valeurs par défaut -dont nous parlions dans les sections précédentes (loopback activé, TTL=1)- données à la prise réseau lorsqu'elle est crée (prises depuis la fonction inet_create() de ce fichier) :

#ifdef CONFIG_IP_MULTICAST
  sk->ip_mc_loop=1;
  sk->ip_mc_ttl=1;
 *sk->ip_mc_name=0;
  sk->ip_mc_list=NULL;
#endif

L'assertion stipulant que « la fermeture d'une prise réseau implique que le noyau n'accepte plus les souscriptions faites par cette prise » est corroborée par :

#ifdef CONFIG_IP_MULTICAST
/* Les applications oublient de quitter les groupes avant de partir */
  ip_mc_drop_socket(sk);
#endif

Extrait de la fonction inet_release(), dans le même fichier que précédemment.

Les opérations indépendantes de la couche de liaison et relatives aux périphériques sont gardées dans le fichier LINUX/net/core/dev_mcast.c.

Deux fonctions sont encore manquantes : les fonctions concernant le traîtement des paquets multicast en entrée et en sortie. Comme tous les autres paquets, les paquets entrants sont transmis depuis les pilotes de périphériques à la fonction ip_rcv() (LINUX/net/ipv4/ip_input.c). Cette fonction contient le filtrage parfait appliqué aux paquets multicasts qui ont passé la couche du périphérique (souvenez-vous que les couches les plus basses ne fournissent qu'un filtrage approximatif et ce n'est que la couche IP qui sait à 100% si nous sommes intéressés ou non par ce groupe multicast). Si l'hôte fonctionne comme un routeur multicast, alors la fonction décide aussi si le paquet doit être transmis. Il appelle alors ipmr_forward(). Cette dernière fonction est implémentée dans le fichier LINUX/net/ipv4/ipmr.c.

Le code se chargeant des paquets émis en sortie est contenu dans le fichier LINUX/net/ipv4/ip_output.c. On y trouve l'effet possible de l'option des IP_MULTICAST_LOOP, selon que l'on souhaite ou non faire une boucle locale (fonction ip_queue_xmit()). Ainsi la valeur du TTL du paquet sortant est donné selon qu'il s'agit d'un paquet unicast ou multicast. Dans ce dernier cas, la valeur de l'argument IP_MULTICAST_TTL passé en option est utilisée (fonction ip_build_xmit()).

Durant un travail à l'aide de mrouted (un programme fournissant des informations liées au noyau sur la façon de router des datagrammes multicast), nous avons détecté que les paquets multicast provenant du réseau local sont routés correctement exceptés ceux venant de la machine Linux agissant en tant que routeur multicast ! ip_input.c fonctionne bien, mais il semble que ce n'est pas le cas de ip_output.c. En lisant le code source des fonctions de sorties, nous avons trouvé que les paquets sortant n'étaient pas passés à ipmr_forward(), fonction décidant si les paquets doivent être routés ou non. Les paquets sont sortis sur le réseau local mais, comme les cartes réseaux sont le plus souvent incapables de lire les données transmises, ces datagrammes ne sont alors jamais routés. Nous avons ajouté le code nécessaire à la fonction ip_build_xmit() et le tour était joué. (Disposer du code source du noyau n'est pas un luxe, mais une nécessité !)

ipmr_forward() a déjà été mentionné un certain nombre de fois. C'est une fonction importante car elle permet de résoudre un important problème de compréhension nécessitant d'être plus largement expliqué. En routant du trafic multicast, ce n'est pas mrouted qui fabrique les copies puis les expédie à ses propres destinataires. mrouted reçoit tout le trafic multicast et, basé sur cette information, calcule les tables de routages multicast puis informe le noyau de la manière de router : « les datagrammes pour ce groupe provenant de cette interface doivent être transférés à ces interfaces ». Cette information est transmise au noyau par l'appel de setsockopt() sur la file d'une prise réseau ouverte par le daemon mrouted (le protocole spécifié lors de la création de la file de la prise réseau doit être IPPROTO_IGMP). La prise en compte d'options s'effectue par l'appel à la fonction ip_mroute_setsockopt() de LINUX/net/ipv4/ipmr.c. Cette première option (il est préférable de les appeler commandes plutôt qu'options) provenant de cette prise réseau doit être MRT_INIT. Toutes les autres commandes sont ignorées (retournant -EACCES) si MRT_INIT n'est pas précisé en premier. Seulement une seule instance de mrouted peut être exécutée à la fois sur un même hôte. Pour garder une trace de cela, lorsque le premier MRT_INIT est reçu, une variable importante, struct sock* mroute_socket, est pointée sur la prise réseau ou le MRT_INIT a été reçu. Si mroute_socket n'est pas nul lors de l'attente d'un MRT_INIT cela signifie qu'un autre mrouted est en cours d'exécution, un -EADDRINUSE est alors renvoyé. Toutes les commandes s'appuyant sur le même principe (MRT_DONE, MRT_ADD_VIF, MRT_DEL_VIF, MRT_ADD_MFC, MRT_DEL_MFC et MRT_ASSERT) retournent -EACCES si elles proviennent d'une prise réseau différente de mroute_socket.

Comme les datagrammes multicast routés peuvent être reçus/envoyés au travers d'interfaces physiques ou de tunnels, une abstraction commune a été définie : les VIFs, InterFaces Virtuelles (ou Virtual InterFaces). mrouted communique les structures VIFs au noyau, en indiquant les interfaces physiques ou tunnels pour qu'il les ajoute à sa table de routage. Les entrées de retransmissions multicast indiquent où transmettre les datagrammes.

Les VIFs sont ajoutées à l'aide de MRT_ADD_VIF et supprimées avec MRT_DEL_VIF. L'un comme l'autre passent un struct vifctl au noyau (défini dans /usr/include/linux/mroute.h) avec les informations suivantes :

struct vifctl {
  vifi_t  vifc_vifi;             /* Index du VIF */
  unsigned char vifc_flags;      /* Attributs VIFF_ */
  unsigned char vifc_threshold;  /* Seuil du ttl */
  unsigned int vifc_rate_limit;  /* Valeur de débit limite : non implémenté */
  struct in_addr vifc_lcl_addr;  /* Notre adresse */
  struct in_addr vifc_rmt_addr;  /* Adresse du tunnel IPIP */
};

Avec cette information une structure vif_device est construite :

struct vif_device
{
  struct device   *dev;                   /* le périphérique que nous utilisons */
  struct route    *rt_cache;              /* Tunnel route cache */
  unsigned long   bytes_in,bytes_out;
  unsigned long   pkt_in,pkt_out;         /* Statistiques */
  unsigned long   rate_limit;             /* Forme du trafic ; non implémenté */
  unsigned char   threshold;              /* seuil du TTL */
  unsigned short  flags;                  /* attributs de contrôle */
  unsigned long   local,remote;           /* Adresses(distantes pour les tunnels)*/
};

Notez l'entrée dev dans la structure. La structure device est définie dans le fichier /usr/include/linux/netdevice.h. C'est une grosse structure, mais le champ qui nous intéresse est :

struct ip_mc_list*    ip_mc_list;   /* chaîne des filtres IP multicast */

La structure ip_mc_list -définie dans /usr/include/linux/igmp.h- est comme suit :

struct ip_mc_list
{
  struct device *interface;
  unsigned long multiaddr;
  struct ip_mc_list *next;
  struct timer_list timer;
  short tm_running;
  short reporter;
  int users;
};

Ainsi, le membre ip_mc_list de la structure dev est un pointeur sur une liste chaînée de structures ip_mc_list, chacune contenant une entrée pour chaque groupe multicast pour laquelle l'interface est membre. Ici nous voyons une fois de plus que les appartenances sont associées à des interfaces. LINUX/net/ipv4/ip_input.c parcourt cette liste chaînée pour décider si le datagramme reçu est destiné à un groupe auquel l'interface appartient :

#ifdef CONFIG_IP_MULTICAST
  if(!(dev->flags&IFF_ALLMULTI) && brd==IS_MULTICAST
     && iph->daddr!=IGMP_ALL_HOSTS
     && !(dev->flags&IFF_LOOPBACK))
  {
    /*
     * Verification de l'appartenance à un de nos groupes
     */
     struct ip_mc_list *ip_mc=dev->ip_mc_list;
     do
     {
       if(ip_mc==NULL)
       {
         kfree_skb(skb, FREE_WRITE);
         return 0;
       }
       if(ip_mc->multiaddr==iph->daddr)
         break;
       ip_mc=ip_mc->next;
     }
     while(1);
  }
#endif

Le champ users de la strucuture ip_mc_list est utilisé pour implémenter ce que nous avons dit dans la section IGMP version 1 : si un processus joint un groupe et que l'interface est déjà membre de ce groupe (ie, un autre processus joint le même groupe sur la même interface que précédemment) seul le compteur du nombre de membres (users) est incrémenté. Aucun message IGMP n'est envoyé, comme vous pouvez le voir dans le code suivant (extrait de ip_mc_inc_group(), appelé par ip_mc_join_group(), provenant du fichier LINUX/net/ipv4/igmp.c) :

for(i=dev->ip_mc_list;i!=NULL;i=i->next)
  {
    if(i->multiaddr==addr)
    {
      i->users++;
      return;
    }
  }

À chaque suppression d'une souscription de groupe, le compteur est décrémenté. Des opérations supplémentaires sont appliquées seulement si le compteur est devient égal à 0 (fonction ip_mc_dec_group()).

MRT_ADD_MFC et MRT_DEL_MFC ajoutent ou suppriment des entrées de retransmission dans la table de routage multicast. L'un comme l'autre passent un struct mfcctl au noyau (défini dans /usr/include/linux/mroute.h) avec cette information :

struct mfcctl
{
  struct in_addr mfcc_origin;       /* Origine du mcast      */
  struct in_addr mfcc_mcastgrp;     /* Groupe en question    */
  vifi_t  mfcc_parent;              /* Où cela arrive     */
  unsigned char mfcc_ttls[MAXVIFS]; /* Où cela va t-il    */
};

Avec toute cette information en main, ipmr_forward() parcourt les VIFs, et si une correspondance est trouvée, on duplique le datagramme et on appelle ipmr_queue_xmit() qui, à tour de rôle, utilise le périphérique de sortie indiqué par la table de routage et une adresse de destination propre si le paquet est à envoyer au travers d'un tunnel (il s'agit en fait de l'adresse de destination unicast de l'autre coté du tunnel).

La fonction ip_rt_event() (qui n'est pas directement apparentée à la sortie des datagrammes, mais qui se trouve pourtant dans ip_output.c) reçoit les évènements relatifs aux périphériques réseaux, tel que le branchement du périphérique par exemple. Cette fonction assure que le périphérique joint bien le groupe multicast ALL-HOSTS.

Les fonctions IGMP sont implémentées dans le fichier LINUX/net/ipv4/igmp.c. Les informations importantes concernant ces fonctions se trouvent dans /usr/include/linux/igmp.h et /usr/include/linux/mroute.h. L'entrée IGMP dans le répertoire /proc/net est créée à l'aide de la fonction ip_init() contenue dans le fichier LINUX/net/ipv4/ip_output.c.