[LinuxFocus-icon]
<--  | Sommaire  | Carte  | Index  | Recherche

Nouvelles | Archives | Liens | A propos
Ce document est disponible en: English  Castellano  Deutsch  Francais  Nederlands  Russian  Turkce  Arabic  

[Photo of the Author]
par Angel Lopez
<alogo /at/ mx2.redestb.es>

L´auteur:

Angel termine ses études d'ingénieur système. Il donne des cours sur Solaris et l'administration réseau chez Sun Microsystems. Il a publié le livre Internet protocols. Design and implementation on Unix systems chez l'éditeur Ra-Ma. Ses centres d'intérêt sont le réseau, la sécurité, la programmation système ou réseau sous Unix, et très récemment, du noyau linux, réduisant ainsi son temps de sommeil ;)



Traduit en Français par:
Iznogood <iznogood /at/ iznogood-factory.org>

Sommaire:

 

Multicast

[Ilustration]

Résumé:

Cet article se veut une introduction aux technologies multicast pour les réseaux TCP/IP. Il traite des concepts théoriques de la communication multicast et détaille l'API Linux que nous utilisons pour programmer les applications multicast. Les fonctions du noyau qui implémentent cette technologie sont aussi présentées pour compléter la vue d'ensemble du support multicast sous Linux. L'article se termine par un exemple de programmation de socket en C, dans lequel la création d'une application multicast est illustrée.


_________________ _________________ _________________

 

Introduction

Lorsque vous tentez de contacter un hôte (interface) dans un réseau, vous pouvez utiliser trois types d'adresses :

Les adresses multicast sont utiles lorsque le destinataire n'est pas qu'un hôte et que nous ne voulons pas produire un broadcast réseau. Ce scénario est typique dans les situations qui nécessitent l'envoi d'informations multimédia (audio ou vidéo temps réel par exemple) vers certains hôtes. En terme de bande passante, l'envoi en unicast vers tous les clients devant recevoir l'émission multimédia n'est pas ce qu'il y a de mieux. Le broadcast offre une meilleure solution, surtout si tous les clients sont localisés hors du sous-réseau qui est à l'origine de l'émission.

 

Adresses Multicast

Comme le sait sûrement le lecteur, l'espace des adresses IP est distribué en trois groupes de classes d'adresses. Les classes d'adresses A, B et C. Il en existe une quatrième (D) réservée pour les adresses multicast. Les adresses IPv$ entre 224.0.0.0 et 239.255.255.255 appartiennent à cette classe.

Les 4 bits les plus significatifs de l'adresse IP autorisent des valeurs comprises entre 224 et 239. Les autres 28 bits, moins significatifs, sont réservés à l'identificateur du groupe multicast, comme montré dans la figure ci-dessous :

Au niveau du réseau, les adresses multicast IPv4 doivent être "mappées" sur des adresses physiques du type de réseau sur lequel nous travaillons. Si nous travaillons avec les adresses unicast du réseau, nous devrions obtenir les adresses physiques associées en utilisant le protocole ARP. Dans le cas des adresses multicast, ARP ne peut pas être utilisé et les adresses physiques doivent être obtenues d'une autre manière. Il existe quelques documents RFC expliquant la manière d'effectuer ce "mappage" :

Dans les réseaux Ethernet les plus étendus, le "mappage" est effectué en fixant les 24 bits les plus significatifs de l'adresse Ethernet à 01:00:5E. Le bit suivant est fixé à 0 et les 23 bits les moins significatifs utilisent les 23 bits les moins significatifs de l'adresse multicast IPv4. Ce processus est montré dans le graphique ci-dessous:

Par exemple, l'adresse multicast IPv4 224.0.0.5 correspondra à l'adresse physique ethernet 01:00:5E:00:00:05.

Il existe quelques adresses multicast IPv4 particulières :

Il existe un nombre important d'adresses multicast allouées, autres que celles mentionnées ci-dessus. La référence complète peut être trouvée dans la dernière version de la RFC "Assigned Numbers".

Le tableau ci-dessous montre le champ complet des adresses multicast avec les noms usuels pour chaque plage d'adresse et leur TTL associé. Avec le multicast IPv4, le TTL a une double signification. Comme le sait probablement le lecteur, il contrôle la durée de vie d'un datagramme dans le réseau pour éviter toute boucle infinie dans le cas de tables de routage mal configurées. En travaillant avec le multicast, la valeur TTL définit aussi le champ d'activité du datagramme, par exemple, jusqu'où circulera-t-il au sein du réseau. Ceci permet une définition de champ d'activité basée sur la catégorie du datagramme.

Champ d'activité (scope) TTL Plage d'adresse Description
Noeud 0   Le datagramme est limité à l'hôte local. Il n'atteindra aucune autre interface du réseau.
Lien 1 224.0.0.0 - 224.0.0.255 Le datagramme sera limité au sous-réseau de l'hôte émetteur et n'ira pas au-delà des routeurs.
Département < 32 239.255.0.0 - 239.255.255.255 Limité à un département de l'organisation.
Organisation < 64 239.192.0.0 - 239.195.255.255 Limité à une organisation spécifique.
Global < 255 224.0.1.0 - 238.255.255.255 Pas de restriction, application globale.

 

Multicast en action

Dans un LAN, l'interface réseau d'un hôte enverra aux couches supérieures tous les paquets qui ont l'hôte comme destination. Ces paquets seront ceux qui auront pour adresse de destination les adresses de l'interface physique ou une adresse broadcast.
Si l'hôte fait partie d'un groupe multicast, l'interface réseau reconnaîtra aussi les paquets destinés à ce groupe : tous ceux avec une adresse de destination correspondant au groupe multicast dont l'hôte est membre.

C'est pourquoi, si une interface d'hôte possède l'adresse physique 80:C0:F6:A0:4A:B1 et fait partie du groupe multicast 224.0.1.10, les paquets qui seront reconnus comme appartenant à l'hôte seront ceux ayant l'une des adresses suivantes :

Pour travailler avec multicast sur un WAN, les routeurs doivent supporter le routage multicast. Lorsqu'un processus actif sur un hôte adhère à un groupe multicast, l'hôte envoie un message IGMP à tous les routeurs multicast du sous-réseau, pour les informer que les messages multicast envoyés au groupe multicast doivent être transmis au sous-réseau local afin de permettre la réception par le processus nouvellement inscrit. Les routeurs informeront tous les autres routeurs multicast, en leur indiquant quels sont les messages multicast qui doivent être routés vers le sous-réseau.

Les routeurs envoient aussi des messages IGMP au groupe 224.0.0.1 demandant à chaque hôte des informations sur les groupes auxquels il adhère. Après avoir reçu ce message, un hôte définit un compteur sur une valeur aléatoire et répondra lorsqu'il sera arrivé à zéro. Ceci permet d'éviter que tous les hôtes répondant en même temps, provoquent une surcharge réseau. Lorsque l'hôte répond, il envoie le message à l'adresse multicast du groupe et tous les autres hôtes membres de ce groupe peuvent voir la réponse sans avoir à répondre eux-mêmes, puisqu'un hôte membre est suffisant au routeur du sous-réseau pour gérer les messages multicast de ce groupe.

Si tous les hôtes inscrits à un groupe se sont retirés, aucun ne répondra et le routeur décidera qu'aucun hôte n'est intéressé par ce groupe et cessera le routage des messages correspondants pour ce sous réseau. Une autre option existe dans IGMPv2 : l'hôte informe de son retrait en envoyant un message à l'adresse 224.0.0.2.

 

L'Interface de Programmation d'Application (API)

Avec des expériences antérieures de programmation de socket, le lecteur ne trouvera que cinq nouvelles opérations de socket pour gérer les options multicast. Les fonctions setsockopt() et getsockopt() seront utilisées pour établir ou lire les valeurs de ces cinq options. Le tableau ci-dessous montre les options disponibles pour multicast avec les types de données gérés et une brève description :

Option IPv4 Type de Donnée Description
IP_ADD_MEMBERSHIP struct ip_mreq Adhérer au groupe multicast.
IP_DROP_MEMBERSHIP struct ip_mreq Se retirer du groupe multicast.
IP_MULTICAST_IF struct ip_mreq Spécifier une interface pour l'envoi de messages multicast.
IP_MULTICAST_TTL u_char Spécifier un TTL pour l'envoi de messages multicast.
IP_MULTICAST_LOOP u_char Activer ou désactiver le loopback des messages multicast.

La structure ip_mreq est définie dans le fichier d'en-tête <linux/in.h> comme décrit ci-dessous :

struct ip_mreq {
   struct in_addr imr_multiaddr; /* IP multicast address of group */
   struct in_addr imr_interface; /* local IP address of interface */
   };
Et les options multicast dans ce fichier sont :
#define IP_MULTICAST_IF  32
#define IP_MULTICAST_TTL 33
#define IP_MULTICAST_LOOP 34
#define IP_ADD_MEMBERSHIP 35
#define IP_DROP_MEMBERSHIP 36

 

IP_ADD_MEMBERSHIP

Un processus peut adhérer à un groupe multicast en envoyant cette option via un socket avec la fonction setsockopt(). Le paramètre est une structure ip_mreq. Le premier champ de la structure, imr_multiaddr, contient l'adresse multicast que nous voulons rejoindre. Le second champ, imr_interface, contient l'adresse IPv4 de l'interface que nous allons utiliser.

 

IP_DROP_MEMBERSHIP

En utilisant cette option, un processus peut se retirer d'un groupe multicast. Les champs de la structure ip_mreq sont utilisés de la même manière que dans le cas précédent.

 

IP_MULTICAST_IF

Cette option définit l'interface de réseau que le socket va utiliser pour envoyer des messages multicast. L'interface sera obtenue à partir d'ip_mreq comme dans les cas précédents.

 

IP_MULTICAST_TTL

Etablit le TTL (Time To Live) pour les datagrammes avec les messages multicast envoyés en utilisant le socket. La valeur par défaut est à 1, signifiant que le datagramme n'ira pas au-delà du sous-réseau local.

 

IP_MULTICAST_LOOP

Lorsqu'un processus envoie un message pour un groupe multicast, il reçoit les messages si son interface adhère au groupe, de la même manière qu'il sera reçu si ses origines se situent ailleurs sur le réseau. Cette option permet d'activer ou désactiver ce comportement.

 

Un exemple pratique

Pour tester les idées présentées dans cet article, nous allons prendre un exemple simple de processus qui envoie des messages à un groupe multicast et de processus associés à ce groupe qui reçoivent les messages, en les affichant à l'écran.

Le programme suivant correspond à un serveur envoyant tout ce qui passe par son entrée standard vers le groupe multicast 224.0.1.1. Comme vous pouvez le voir, il n'y a pas besoin d'action particulière pour envoyer des informations à un groupe multicast. Les adresses du groupe de destination sont suffisantes.
Les options de loopback et de TTL peuvent être changées si leur valeur par défaut n'étaient pas appropriées pour les applications en cours de développement.

 

Serveur

L'entrée standard est envoyée au groupe multicast 224.0.1.1

#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <arpa/inet.h>
#include <string.h>
#include <stdio.h>

#define MAXBUF 256
#define PORT 5000
#define GROUP "224.0.1.1"

int main(void) {
  int s;
  struct sockaddr_in srv;
  char buf[MAXBUF];

  bzero(&srv, sizeof(srv));
  srv.sin_family = AF_INET;
  srv.sin_port = htons(PORT);
  if (inet_aton(GROUP, &srv.sin_addr) < 0) {
   perror("inet_aton");
   return 1;
  }
  if ((s = socket(AF_INET, SOCK_DGRAM, 0)) < 0) {
   perror("socket");
   return 1;
  }

  while (fgets(buf, MAXBUF, stdin)) {
  if (sendto(s, buf, strlen(buf), 0, (struct sockaddr *) \
  						srv, sizeof(srv)) < 0) {
      perror("recvfrom");
    } else {
      fprintf(stdout, "Sent to %s: %s\n", GROUP, buf);
    }
  }
}

 

Client

Le programme ci-dessous est le coté client qui reçoit les informations envoyées au groupe multicast par le serveur. Les messages reçus sont affichés sur sa sortie standard. La seule particularité de ce code est l'établissement de l'option IP_ADD_MEMBERSHIP. Le reste du programme est le code standard pour un processus destiné à recevoir des messages UDP.

#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <arpa/inet.h>
#include <stdio.h>

#define MAXBUF 256
#define PORT 5000
#define GROUP "224.0.1.1"

int main(void) {
  int s, n, r;
  struct sockaddr_in srv, cli;
  struct ip_mreq mreq;
  char buf[MAXBUF];

  bzero(&srv, sizeof(srv));
  srv.sin_family = AF_INET;
  srv.sin_port = htons(PORT);
  if (inet_aton(GROUP, &srv.sin_addr) < 0) {
    perror("inet_aton");
    return 1;
  }

  if ((s = socket(AF_INET, SOCK_DGRAM, 0)) < 0) {
    perror("socket");
    return 1;
  }

  if (bind(s, (struct sockaddr *)&srv, sizeof(srv)) < 0) {
    perror("bind");
    return 1;
  }

  if (inet_aton(GROUP, &mreq.imr_multiaddr) < 0) {
    perror("inet_aton");
    return 1;
  }
  mreq.imr_interface.s_addr = htonl(INADDR_ANY);

  if (setsockopt(s, IPPROTO_IP, IP_ADD_MEMBERSHIP, \
  					mreq, sizeof(mreq)) < 0) {
    perror("setsockopt");
    return 1;
  }

  n = sizeof(cli);
  while (1) {
    if ((r = recvfrom(s, buf, MAXBUF, 0, (struct sockaddr *) \
    								cli, &n)) < 0) {
      perror("recvfrom");
    } else {
      buf[r] = 0;
      fprintf(stdout, "Message from %s: %s\n", \
      					inet_ntoa(cli.sin_addr), buf);
    }
  }
}

 

Noyau et Multicast

Comme nous le montrons ci-dessus, lorsqu'un processus souhaite adhérer à un groupe multicast, il utilise la fonction setsockopt() pour établir l'option IP_ADD_MEMBERSHIP au niveau IP. La manière d'utiliser cette fonction peut être trouvée dans /usr/src/linux/net/ipv4/ip_sockglue.c. Le programme executé dans la fonction pour définir cette option ou celle d'IP_DROP_MEMBERSHIP est :

struct ip_mreqn mreq;

if (optlen < sizeof(struct ip_mreq))
  return -EINVAL;
if (optlen >= sizeof(struct ip_mreqn)) {
  if(copy_from_user(&mreq,optval,sizeof(mreq)))
    return -EFAULT;
} else {
  memset(&mreq, 0, sizeof(mreq));
  if (copy_from_user(&mreq,optval,sizeof(struct ip_mreq)))
    return -EFAULT;
}
if (optname == IP_ADD_MEMBERSHIP)
  return ip_mc_join_group(sk,&mreq);
else
  return ip_mc_leave_group(sk,&mreq);

Les premières lignes de code contrôlent que le paramètre d'entrée, la structure ip_mreq possède la longueur correcte et qu'il est possible de la copier de la partie utilisateur vers la partie noyau. Une fois que nous avons la valeur du paramètre, la fonction ip_mc_join_group() est appelée pour adhérer à un groupe multicast ou ip_mc_leave_group() si nous voulons nous retirer du groupe.

Le programme pour ces fonctions se trouve dans /usr/src/linux/net/ipv4/igmp.c. Pour adhérer à un groupe, le code source est commenté ci-dessous :

int ip_mc_join_group(struct sock *sk , struct ip_mreqn *imr)
{
  int err;
  u32 addr = imr->imr_multiaddr.s_addr;
  struct ip_mc_socklist, *iml, *i;
  struct in_device *in_dev;
  int count = 0;

Le point de départ consiste à vérifier que les adresses du groupe se situent bien dans la plage réservée aux adresses multicast, à l'aide de la macro MULTICAST. Il suffit de vérifier que l'octet le plus significatif de l'adresse IP soit à 224.

  if (!MULTICAST(addr))
    return -EINVAL;

    rtnl_shlock();

Après la vérification, une interface réseau est mise en place pour dialoguer avec le groupe multicast. S'il n'est pas possible d'accéder par index à l'interface, comme ce devrait être le cas avec IPv6, la fonction ip_mc_find_dev() est appelée pour trouver le périphérique associé à une adresse IP spécifique. Nous supposerons pour le reste de cet article que c'est le cas parce que nous travaillons sous IPv4. Si l'adresse était INADDR_ANY, le noyau devrait trouver lui-même l'interface réseau en lisant la table de routage pour choisir la meilleure interface en tenant compte de l'adresse de groupe et de la définition des tables de routage.

  if (!imr->imr_ifindex)
    in_dev = ip_mc_find_dev(imr);
  else
    in_dev = inetdev_by_index(imr->imr_ifindex);

  if (!in_dev) {
    iml = NULL;
    err = -ENODEV;
    goto done;
  }

Nous réservons alors de la mémoire pour une structure ip_mc_socklist. Chaque adresse de groupe et interface associés au socket est comparée. Si d'autre entrées associées précédemment au socket correspondent, nous quittons la fonction puisqu'une double association à un groupe et une interface n'a pas de sens. Si les adresses de l'interface réseau ne sont pas INADDR_ANY, le compteur correspondant est incrémenté avant que la fonction ne se termine.

  iml = (struct ip_mc_socklist *)sock_kmalloc(sk, sizeof(*iml),
    GFP_KERNEL);
  err = -EADDRINUSE;
  for (i=sk->ip_mc_list; i; i=i->next) {
    if (memcmp(&i->multi, imr, sizeof(*imr)) == 0) {
      /* New style additions are reference counted */
      if (imr->imr_address.s_addr == 0) {
        i->count++;
        err = 0;
      }
      goto done;
    }
    count++;
  }
  err = -ENOBUFS;
  if (iml == NULL || count >= sysctl_igmp_max_memberships)
    goto done;

Si nous arrivons à ce point, cela signifie qu'un nouveau socket sera lié à un nouveau groupe pour qu'une nouvelle entrée soit créée et liée à la liste de groupes appartenant au socket. La mémoire a été réservée par avance et nous avons seulement besoin de définir les valeurs correctes pour les différents champs des structures impliquées.

  memcpy(&iml->multi,imr, sizeof(*imr));
  iml->next = sk->ip_mc_list;
  iml->count = 1;
  sk->ip_mc_list = iml;
  ip_mc_inc_group(in_dev,addr);
  iml = NULL;
  err = 0;
done:
  rtnl_shunlock();
  if (iml)
    sock_kfree_s(sk, iml, sizeof(*iml));
  return err;
}

La fonction ip_mc_leave_group() est chargée du retrait d'un groupe multicast et elle est plus simple que les fonctions précédentes. Elle prend les adresses de l'interface et du groupe et les cherche parmi les entrées liées au socket réel. Une fois qu'elles ont été trouvées, le nombre de références est décrémenté puisqu'il y a un processus de moins associé au groupe. Si la nouvelle valeur est zéro, le compteur est effacé.

int ip_mc_leave_group(struct sock *sk, struct ip_mreqn *imr)
{
  struct ip_mc_socklist *iml, **imlp;
  for (imlp=&sk->ip_mc_list;(iml=*imlp)!=NULL; imlp=&iml->next) {
    if (iml->multi.imr_multiaddr.s_addr==imr->imr_multiaddr.s_addr
     && iml->multi.imr_address.s_addr==imr->imr_address.s_addr &&
     (!imr->imr_ifindex || iml->multi.imr_ifindex==imr->imr_ifindex)) {
      struct in_device *in_dev;
      if (--iml->count)
        return 0;

      *imlp = iml->next;
      synchronize_bh();

      in_dev = inetdev_by_index(iml->multi.imr_ifindex);
      if (in_dev)
        ip_mc_dec_group(in_dev, imr->imr_multiaddr.s_addr);
      sock_kfree_s(sk, iml, sizeof(*iml));
      return 0;
    }
  }
  return -EADDRNOTAVAIL;
}

Les autres options multicast que nous avons listées ci-dessus sont très simples car elles définissent simplement des valeurs dans les champs de données de la structure interne qui est associée au socket sur lequel nous travaillons. Ces affectations sont effectuées directement par la fonction ip_setsockopt().

 

Talkback form for this article

Every article has its own talkback page. On this page you can submit a comment or look at comments from other readers:




Site Web maintenu par l´équipe d´édition LinuxFocus
© Angel Lopez
"some rights reserved" see linuxfocus.org/license/
http://www.LinuxFocus.org
Translation information:
es --> -- : Angel Lopez <alogo /at/ mx2.redestb.es>
es --> en: Javier Palacios <javier.pb /at/ linuxfocus.org>
en --> fr: Iznogood <iznogood /at/ iznogood-factory.org>

2005-02-13, generated by lfparser version 2.52

mirror server hosted at Truenetwork, Russian Federation.