Guide pratique du multicast sur les réseaux TCP/IP Adaptation française du Multicast over TCP/IP HOWTO Juan-Mariano de Goyeneche Adaptation française: Antoine Duval Relecture de la version française: Fabrice Gadaud Préparation de la publication de la v.f.: Jean-Philippe Guérard Version : 1.0.fr.1.1 14 octobre 2003 +----------------------------------------------------------------+ | Historique des versions | |----------------------------------------------------------------| | Version v1.0.fr.1.1 | 2003-10-14 | JPG | |----------------------------------------------------------------| | Ajout de titres aux renvois inclus dans le texte. Reformatage | | des exemples de code. | |----------------------------------------------------------------| | Version v1.0.fr.1.0 | 2003-09-30 | AD,FG,JPG | |----------------------------------------------------------------| | Première version française. | |----------------------------------------------------------------| | Version v1.0 | 1998-03-20 | JMdG | +----------------------------------------------------------------+ Résumé Ce guide pratique couvre les principaux aspects relatifs au multicast sur les réseaux TCP/IP. De nombreuses informations contenues dans ce document ne sont pas spécifiques à Linux (au cas où vous n'utiliserez pas encore le système Linux/GNU...). Le multicast est encore un domaine de recherche et les standards ne sont encore que des brouillons. Gardez cela à l'esprit à la lecture des lignes qui suivent. ------------------------------------------------------------------- Table des matières 1. Introduction 1.1. Qu'est ce que le multicast ? 1.2. Le problème d'unicast 2. Explications relatives au multicast 2.1. Adresses multicast 2.2. Niveaux de conformité 2.3. Envoyer des datagrammes multicast. 2.4. Recevoir des datagrammes multicast 3. Besoins et configuration du noyau 4. MBone 5. Applications multicast 5.1. Conférences audio 5.2. Conférences vidéo 5.3. Autres utilitaires 5.4. Outils de session 6. Programmation multicast 6.1. IP_MULTICAST_LOOP 6.2. IP_MULTICAST_TTL 6.3. IP_MULTICAST_IF 6.4. IP_ADD_MEMBERSHIP 6.5. IP_DROP_MEMBERSHIP 7. Fonctionnement interne 7.1. IGMP 7.2. Aspects concernant le noyau 8. Politiques de routage et techniques de retransmission 9. Protocoles de transport multicast 10. Bibliographie 10.1. RFCs 10.2. Brouillons Internet (Internet Drafts) 10.3. Pages web 10.4. Livres 11. Licence et mise en garde 1. Introduction Dans ce document, je vais essayer de vous donner des informations les plus à jour possible sur le multicast au travers des réseaux TCP/IP. Tout retour est le bienvenu. Si vous trouvez des erreurs dans ce document, si vous avez des commentaires ou des mises à jour à faire quant à son contenu, n'hésitez pas à m'en faire part à l'adresse que vous trouverez dans l'entête du document. 1.1. Qu'est ce que le multicast ? 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. 1.2. Le problème d'unicast 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. 2. Explications relatives au multicast 2.1. Adresses multicast 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 : +----------------------------------------------------------------+ | Bit -> | 0 | | | | | 31 | Plage d'adresses : | |--------+---+----------------------------+----------------------| | | 0 | Adresses de classe A | 0.0.0.0 - | | | | | 127.255.255.255 | |--------+---+----------------------------+----------------------| | | 1 | 0 | Adresses de classe B | 128.0.0.0 - | | | | | | 191.255.255.255 | |--------+---+---+------------------------+----------------------| | | 1 | 1 | 0 | Adresses de classe | 192.0.0.0 - | | | | | | C | 223.255.255.255 | |--------+---+---+---+--------------------+----------------------| | | 1 | 1 | 1 | 0 | Adresses | 224.0.0.0 - | | | | | | | multicast | 239.255.255.255 | |--------+---+---+---+----+---------------+----------------------| | | 1 | 1 | 1 | 1 | 0 | Réservé | 240.0.0.0 - | | | | | | | | | 247.255.255.255 | +----------------------------------------------------------------+ 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 : 224.0.0.1 est le groupe all-hosts. Si vous pingez ce groupe, tous les hôtes sur le réseau capables d'émettre en multicast répondront, car tout hôte gérant le multicast doit joindre ce groupe au démarrage sur toutes ses interfaces. 224.0.0.2 est le groupe all-routers. Tous les routeurs multicast joignent ce groupe sur toutes leurs interfaces multicast. 224.0.0.4 est le groupe de tous les routeurs DVMRP. 224.0.0.5 est le groupe de tous les routeurs OSPF. 224.0.0.13 est le groupe de tous les routeurs PIM, etc. 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). 2.2. Niveaux de conformité 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. Niveau 0 signifie « qu'aucun support n'est disponible pour l'IP multicast ». Beaucoup d'hôtes et de routeurs sur Internet sont dans cet état, car le support multicast n'est pas exigé pour l'IPv4 (il l'est cependant pour l'IPv6). Ainsi, les hôtes qui sont dans cet état ne peuvent ni émettre, ni recevoir de paquets multicast. Ils ignorent donc les paquets émis par les autres hôtes pouvant émettre en multicast. Niveau 1 signifie « qu'il existe un support pour envoyer mais pas pour recevoir des datagrammes IP multicast ». Dans ce cas, il n'est pas nécessaire de joindre un quelconque groupe multicast pour envoyer des datagrammes. Peu d'ajouts sont nécessaires à un module IP pour passer un hôte du « niveau 0 » au « compatible niveau 1 », comme on pourra le voir dans la section 2.3. Niveau 2 signifie qu'un « support complet est disponible pour l'IP multicast ». Les hôtes de niveau 2 sont aussi bien capables d'émettre, que de recevoir du trafic multicast. Ils savent comment joindre et quitter les groupes multicast, ainsi que propager cette information aux routeurs multicasts. De même, ils incluent une implémentation de IGMP (Internet Group Management Protocol) dans leur pile de protocoles TCP/IP. 2.3. Envoyer des datagrammes multicast. 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. 2.3.1. TTL Le champ TTL (Time To Live, ou temps restant à vivre) de l'entête IP a une double signification pour le multicast. Comme toujours, il contrôle le temps restant à vivre pour un datagramme empêchant ainsi les boucles infinies dues aux erreurs de routage. Chaque routeur décrémente le TTL de tout datagramme le traversant et lorsque cette valeur devient égale à 0 le paquet est détruit. Le TTL dans notre cas (sur IPv4) a aussi une signification de « seuil ». Éclairons son utilisation à l'aide d'un exemple : supposez que vous fassiez une longue conférence vidéo (consommant beaucoup de bande passante) entre tous les hôtes de votre département. Vous désirez que tout ce trafic puisse être supporté par votre réseau local. Peut-être que votre département est suffisamment grand pour avoir différents réseaux locaux. Dans ce cas vous désirerez sûrement que les hôtes appartenant à chacun de vos réseaux locaux puissent suivre la conférence, sans pour autant saturer Internet tout entier avec votre trafic multicast. Il est donc nécessaire de limiter la portée du trafic multicast au travers des routeurs. C'est ce à quoi est destiné le TTL. Chaque routeur a un seuil TTL assigné sur chaque interface, et seuls les datagrammes qui ont un TTL supérieur au seuil de l'interface sont retransmis au travers de ce routeur. Notez que lorsqu'un datagramme traverse un routeur avec une valeur de seuil donnée, le TTL du datagramme n'est pas décrémenté de la valeur de ce seuil. Seule une comparaison est faite. (Comme précedemment, le TTL est décrémenté de 1 à chaque passage au travers d'un routeur). Une liste de seuils TTL et de leur signification suit : +----------------------------------------------------------------+ | TTL | Signification | |------+---------------------------------------------------------| | 0 | Restriction au même hôte. Le paquet ne sera émis sur | | | aucune interface. | |------+---------------------------------------------------------| | 1 | Restriction au même sous réseau. Le paquet ne pourra | | | être routé | |------+---------------------------------------------------------| | <32 | Restriction au même site, organisation ou département. | |------+---------------------------------------------------------| | <64 | Restriction à la même région. | |------+---------------------------------------------------------| | <128 | Restriction au même continent. | |------+---------------------------------------------------------| | <255 | Aucune restriction. Global. | +----------------------------------------------------------------+ Aucune signification exacte n'a été donnée au terme de « site » ou de « région ». Il est à la charge des administrateurs de décider des limites qui s'appliquent. Il est à noter que l'astuce liée au TTL n'est peut être pas toujours assez souple pour correspondre à tous les besoins, et plus spécialement s'il est nécessaire de traiter avec des régions qui se chevauchent et prenent en compte à la fois des limites géographiques, topologiques ou encore liées à une gestion de bande passante. Afin de résoudre ce problème, des régions multicast à caractère administratif ont été établies depuis 1994. (cf D.Meyer's « Administratively Scoped IP Multicast » Internet draft). Ce découpage est basé sur les adresses multicast au lieu des TTL. L'intervalle allant de 239.0.0.0 à 239.255.255.255 est reservé à ce découpage administratif. 2.3.2. Loopback Lorsqu'un hôte est conforme au niveau 2 et qu'il est membre du groupe auquel il envoie des datagrammes, alors une copie des datagrammes lui est retransmise par défaut. Cela ne signifie pas que l'interface lit sa propre transmission depuis le réseau (en reconnaissant les datagrammes comme étant d'un groupe auquel appartient l'interface). Au contraire, c'est la couche IP qui, par défaut, reconnaît le datagramme à envoyer, le copie puis le met sur la file d'entrée IP avant de l'envoyer. Cette fonctionnalité est appréciable dans certains cas, mais pas pour tous. De ce fait il est possible d'activer ou de désactiver ce processus d'envoi selon ses souhaits. 2.3.3. Sélection de l'interface. Les hôtes qui sont reliés à plus d'un réseau doivent pouvoir décider de l'interface réseau à utiliser pour envoyer les informations. Si rien n'est spécifié, alors le noyau en choisit une par défaut. Ce choix est basé sur la configuration faite par l'administrateur. 2.4. Recevoir des datagrammes multicast 2.4.1. Joindre un groupe multicast La diffusion en broadcast est (en comparaison) plus simple à implémenter que la diffusion en multicast. En effet dans le premier cas, il n'est pas nécessaire que les processus donnent au noyau des règles concernant la gestion des paquets diffusés. Le noyau sait ce qu'il doit faire avec tous les paquets : les lire et les délivrer aux applications concernées. En diffusion multicast il est nécessaire d'aviser le noyau des groupes multicast qui nous intéressent. Le noyau « joint » alors ces groupes. Puis selon la nature du matériel sous-jacent, les datagrammes multicast sont filtrés soit par le matériel, soit par la couche IP (et dans certains cas, par les deux). Seuls les datagrammes dont le groupe de destination a précédemment été rejoint sont acceptés. Essentiellement, lorsque l'on joint un groupe, nous disons au noyau « D'accord, je sais que par défaut tu ignores les datagrammes multicast, mais souviens toi que ce groupe multicast m'intéresse. De ce fait, lit et délivre (à tous les processus intéressés, pas seulement moi) tous les datagrammes que tu vois sur ton interface réseau et qui sont adressés au groupe multicast en question ». Quelques remarques : tout d'abord, notez que vous ne faites pas que rejoindre un groupe. Vous joignez un groupe sur une interface réseau particulière. Bien sûr, il est possible de joindre le même groupe sur plusieurs interfaces. Si vous ne spécifiez pas concrètement une interface, alors le noyau en choisira une (selon sa table de routage) lorsqu'il sera nécessaire d'envoyer des datagrammes. Par ailleurs, il est possible que plus d'un processus rejoignent le même groupe multicast par une même interface. Ces processus reçoivent alors tous les datagrammes envoyés à ce groupe au travers de cette interface. Comme dit précédemment, tous les hôtes gérant le multicast joignent le groupe all-hosts au démarrage, de ce fait on peut « pinger » tous les hôtes gérant le multicast au travers de l'adresse 224.0.0.1. Finalement, considérez le fait suivant : pour qu'un processus puisse recevoir des datagrammes multicast, il doit demander au noyau de joindre le groupe désiré, et doit se relier au port par lequel les datagrammes seront envoyés. La couche UDP se base à la fois l'adresse de destination et le numéro de port pour démultipexer les paquets reçus et décider à quelle(s) connection(s) les délivrer. 2.4.2. Quitter un groupe multicast Quand un processus n'est plus intéressé par un groupe multicast, il informe le noyau qu'il désire quitter ce groupe. Il est important de comprendre que cela ne signifie pas que le noyau n'acceptera plus les datagrammes multicast destinés à ce groupe. En effet, il continuera à le faire si d'autres processus restent intéressés par ce groupe. Dans ce cas l'hôte reste membre de ce groupe, et cela jusqu'à ce que tous les processus décident de le quitter. L'explication ici est que joindre un groupe multicast nécessite seulement une adresse IP. C'est la couche de liaison de données qui, après une demande explicite au matériel dans certains cas, accepte les datagrammes multicast destinés à ce groupe. L'appartenance à un groupe ne se fait donc pas par processus, mais par hôte. 2.4.3. Transcrire une adresse IP Multicast dans une adresse Ethernet/FDDI Les trames Ethernet, aussi bien que les trames FDDI, ont une adresse de destination codée sur 48 bits. Dans le but d'éviter une sorte d'ARP multicast translatant les adresses IP multicast en adresses ethernet/FDDI, l'IANA a réservé une plage d'adresses pour le multicast : chaque trame ethernet/FDDI dont l'adresse de destination appartient à l'intervalle allant de 01-00-5e-00-00-00 à 01-00-5e-ff-ff-ff contient des données à destination d'un groupe multicast. Le préfixe 01-00-5e identifie la trame comme étant multicast, le bit suivant étant toujours à 0, il reste donc 23 bits de disponibles pour les adresses multicast. Comme les groupes multicast sont définis sur 28 bits, la translation ne peut pas être une à une. Seuls les 23 bits les moins significatifs du groupe IP multicast sont placés dans la trame. Les 5 bits d'ordre supérieur restant sont ignorés, ce qui a pour résultat que 32 groupes multicast différents peuvent être translatés par une même adresse ethernet/FDDI. Cela signifie que la couche ethernet agit tel un filtre imparfait, et que la couche IP doit décider si elle accepte les datagrammes de la couche de liaison de données qui lui sont donnés. La couche IP agit tel un filtre final parfait. Tous les détails concernant l'IP Multicast au travers de FDDI sont donnés dans le RFC 1390 « Transmission of IP and ARP over FDDI Networks » (transmission IP et ARP au travers de réseaux FDDI). Pour plus d'information concernant la translation d'adresses IP multicast vers ethernet, vous pouvez consulter le draft-ietf-mboned-intro-multicast-03.txt: « Introduction to IP Multicast Routing » (introduction au routage IP multicast). Si vous êtes intéressé par l'IP multicast sur les réseaux locaux Token-Ring, consultez le RFC 1469. 3. Besoins et configuration du noyau Linux est, bien sûr (doutez-vous de cela ?), pleinement compatible avec le multicast niveau 2. Il satisfait toutes les exigences liées à l'envoi, à la réception et au routage (grâce à mrouter) des datagrammes multicast. Si vous désirez émettre et recevoir des paquets IP multicast, vous devez activer l'option « IP: multicasting » lors de la configuration de votre noyau. Si vous désirez aussi que votre Linux agisse tel un routeur multicast, vous aurez alors besoin d'activer le routage multicast du noyau en sélectionnant « IP: forwarding/gatewaying » (transfert/passerelle), « IP: multicast routing » (routage multicast) et « IP: tunneling » (tunnel), cette dernière option est nécessaire car les nouvelles versions de mrouted peuvent aussi retransmettre les paquets au travers de tunnels IP ; les datagrammes IP multicast sont alors encapsulés dans des datagrammes unicast. Il est nécessaire d'établir des tunnels entre des hôtes multicast s'ils sont séparés par un réseau ou par plusieurs routeurs incapables de transférer des datagrammes multicast. (mrouted est un service qui implémente un algorithme de routage multicast -politique de routage- et informe le noyau sur la façon de router les datagrammes multicast. Certaines versions du noyau considèrent le routage multicast comme étant « EXPERIMENTAL », de ce fait vous devez activer l'option « Prompt for development and/or incomplete code/drivers » dans la section « Code maturity level options ». Si, durant l'exécution de mrouted, le trafic généré sur le réseau (où est connectée votre station linux) est correctement transféré aux autres réseaux, mais il vous est impossible de « voir » le trafic des autres réseaux sur votre réseau local, vérifiez alors si vous recevez des messages d'erreur du protocole ICMP. Il s'agit d'une erreur due, le plus fréquemment, à la non activation de l'IP tunneling de votre routeur Linux. C'est le genre d'erreur qui paraît stupide lorsque vous la connaissez mais, croyez moi, cela prend beaucoup de temps pour la détecter quand vous l'ignorez, car il n'y a pas de raison apparente signifant la cause de l'erreur. Un renifleur (ou « sniffeur ») s'avère utile dans ce genre de situation. Vous trouverez plus d'informations dans la section politiques de routage et techniques de retransmission ; mrouted et les tunnels sont aussi expliqués dans la section consacrée à MBone et la section applications multicast. Une fois votre nouveau noyau compilé et installé, vous devez définir une route par défaut pour votre trafic multicast. Ce qui revient à ajouter une route au réseau 224.0.0.0. Le problème auquel le plus de personnes font face à ce stade de la configuration est la valeur du masque à appliquer. Si vous avez lu précédemment l'excellent NET-3-HOWTO de Terry Dawson, il ne vous sera pas difficile de trouver la bonne valeur. Comme expliqué, le masque de sous réseau est un nombre codé sur 32 bits rempli avec des « 1 » sur la partie réseau de votre adresse IP, et avec des « 0 » sur la partie hôte. En référence à la section 2.1 une adresse multicast de classe D n'a pas de division réseau/hôte. À la place, il a un groupe d'identification codé sur 28 bits et un identifiant de classe D codé sur 4 bits. Le masque de sous réseau voulu est donc 11110000000000000000000000000000 ou d'une manière plus facilement lisible : 240.0.0.0. De ce fait la commande complète est : route add 224.0.0.0 netmask 240.0.0.0 dev eth0 Selon la version de votre programme route, il peut être nécessaire d'ajouter l'option -net après l'option add. Dans l'exemple, nous supposons que l'interface eth0 supporte le multicast et, si rien d'autre n'est spécifié, nous voulons que le trafic multicast sorte par cette interface. Si cela n'est pas votre cas, changez alors le paramètre dev de manière appropriée. Le système de fichiers /proc s'avère utile une fois encore : il est possible de vérifier dans le fichier /proc/net/igmp les groupes auxquels votre machine est actuellement connectée. 4. MBone L'utilisation d'une nouvelle technologie apporte son lot d'avantages et d'inconvénients. Les avantages du multicast sont -je le pense- clairs. Le principal inconvénient est qu'actuellement des centaines d'hôtes, et plus spécialement les routeurs, ne supportent pas le multicast. Par conséquent, les personnes qui commencent à travailler avec du multicast, et qui de fait ont acheté de nouveaux équipements et modifié leurs systèmes d'exploitation ; on construit des îlots multicast dans leurs locaux. C'est alors qu'ils ont découvert qu'il leur était difficile de communiquer avec des personnes faisant de même car il suffit d'un routeur ne supportant pas le multicast pour que rien ne fonctionne. La solution est alors apparue comme évidente : ils décidèrent de contruire un réseau multicast virtuel au-dessus d'Internet. De fait : les sites reliés par des routeurs multicasts peuvent communiquer entre-eux directement. Mais les sites joigniables uniquement par le biais de routeurs unicast doivent encapsuler leur trafic multicast dans des paquets unicast pour communiquer avec les autres îlots multicast. Les routeurs traversés ne poserons pas de problèmes car ils savent gérer ce trafic unicast. Finalement, le site de réception désencapsulera le trafic, et le retransmettra à l'îlot selon la méthode multicast originale. Ainsi, les deux extrémités convertissent du multicast vers de l'unicast et à nouveau de l'unicast vers du multicast, définissant ainsi ce qui est appelé un tunnel multicast. Le MBone ou épine dorsale multicast (Multicast BackBone) est un réseau virtuel multicast basé sur l'interconnection d'îlots multicast reliés entre eux par des tunnels multicast. Diverses utilisations sont faites du MBone de nos jours, on peut ainsi remarquer la profusion de téléconférences audio/vidéo en temps réel qui ont lieu au travers d'Internet. Un exemple de ces téléconférences est la retransmission (en direct !) de la conférence de Linus Torvalds qui a été donnée au groupe d'utilisateurs de Linux de la Silicon Valley [ndt : en 1999 ?]. Pour plus d'informations à propos du MBone, consultez : http://www.mediadesign.co.at/newmedia/more/mbone-faq.html 5. Applications multicast La plupart des personnes ayant affaire avec le multicast, décident tôt ou tard de se connecter au MBone, et de ce fait ont tradionnellement besoin de mrouted. Vous aurez sûrement besoin de lui si vous ne possédez pas de routeur capable de faire du multicast et que vous voulez que le travail effectué sur l'un de vos sous réseaux soit « entendu » par un autre réseau. mrouted circonscrit le problème d'envoi de trafic au travers des routeurs unicast -il encapsule les datagrammes multicast dans des datagrammes unicast (IP dans IP)-. Il ne s'agit pas de la seule fonctionnalité de mrouted. La plus importante, est qu'il indique au noyau la façon de router (ou de ne pas router) les datagrammes multicast selon leurs adresses d'origine et de destination. De ce fait, même si vous avez un routeur multicast, mrouted peut être utilisé pour lui dire quoi faire des datagrammes. (notez que j'ai dit quoi, et non comment, mrouted dit « transmet ceci au réseau connecté à cette interface », mais le transfert se fait actuellement par le noyau). Il existe une distinction à faire entre le transfert en lui-même et l'algorithme qui décide de ce qui doit être transféré et de la façon de le faire. Cette distinction est très utile car elle permet d'écrire un code unique permettant le transfert, en l'insérant dans le noyau ; tandis que les algorithmes et les politiques de transfert sont implémentés en tant que service utilisateur, ce qui permet un changement de politique sans recompiler le noyau. Vous pouvez vous procurer une version de mrouted pour Linux depuis : ftp://www.video.ja.net/mice/mrouted/Linux/. Des mirroirs de ce site existent tout autour de la planète. Lisez bien le fichier ftp://www.video.ja.net/mice/README.mirrors pour choisir le mirroir le plus près de chez vous. Vous trouverez ci-dessous une liste des applications qui ont été écrites afin de se connecter au MBone et qui ont été portées sous Linux. Cette liste est issue de la page d'information « Linux Multicast Information » écrite par Michael Esler : http://www.cs.virginia.edu/~mke2e/multicast/. Je vous recommande cette page pour toutes les informations et ressources à propos du multicast et de Linux. 5.1. Conférences audio o NeVoT - Terminal réseau pour la voix http://www.fokus.gmd.de/step/nevot o RAT - UCL outil audio robuste http://www-mice.cs.ucl.ac.uk/mice/rat o vat - LBL outil audio visuel http://www-nrg.ee.lbl.gov/vat/ 5.2. Conférences vidéo o ivs - Système de vidéo conférence de l'Inria http://www.inria.fr/rodeo/ivs.html o nv - Outil réseau pour la vidéo ftp://ftp.parc.xerox.com/pub/net-research/ o nv w/ Meteor - Version de nv w/ pour Matrox Meteor (UVa) ftp://ftp.cs.virginia.edu/pub/gwtts/Linux/nv-meteor.tar.gz o vic - LBL Outil de vidéo conférence http://www-nrg.ee.lbl.gov/vic/ o vic w/ Meteor - Version de vic w/ support pour Matrox Meteor (UVa) ftp://ftp.cs.virginia.edu/pub/gwtts/Linux/vic2.7a38-meteor.tar.gz 5.3. Autres utilitaires o mmphone service téléphonique multimédia http://www.eit.com/software/mmphone/phoneform.html o wb - LBL tableau blanc partagé http://www-nrg.ee.lbl.gov/wb/ o webcast - Application multicast fiable pouvant relier les navigateurs Mosaic http://www.ncsa.uiuc.edu/SDG/Software/XMosaic/CCI/webcast.html 5.4. Outils de session 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. o gwTTS - système de télé-enseignement de Université de Virginie http://www.cs.Virginia.EDU/~gwtts o isc - contrôleur de session intégré http://www.fokus.gmd.de/step/isc o mmcc - contrôle de conférences multimédia ftp://ftp.isi.edu/confctrl/mmcc o sd - outil de référencement de session LBL ftp://ftp.ee.lbl.gov/conferencing/sd o sd-snoop - utilitaire de référencement de sessions du Tenet Group ftp://tenet.berkeley.edu/pub/software o sdr - nouvelle génération de référencement de sessions d'UCL ftp://cs.ucl.ac.uk/mice/sdr 6. Programmation multicast Programmation multicast... ou comment écrire vos propres applications multicast. Diverses extensions de l'API de programmation sont nécessaires pour utiliser le multicast. Ces extensions sont utilisables par le biais de deux appels systèmes : setsockopt() (utilisé pour envoyer des informations au noyau) et getsockopt() (utilisé pour recevoir des informations du voisinage multicast). Cela ne signifie pas que ces 2 nouveaux appels systèmes ont été ajoutés pour le fonctionnement du multicast. La paire setsockopt() / getsockopt() est là depuis des années. Depuis la BSD 4.2 au moins. L'ajout consiste en un nouveau jeu d'options (options multicast) qui est passé à ces appels systèmes et que le noyau doit comprendre. Les deux lignes suivantes donnent le prototypage des fonctions setsockopt() / getsockopt(). int getsockopt(int s, int level, int optname, void* optval, int* optlen); int setsockopt(int s, int level, int optname, const void* optval, int optlen); Le premier paramètre, s, est la prise réseau (socket) à laquelle l'appel système s'applique. Pour le multicast, la prise doit être de la famille AF_INET et peut être de type SOCK_DGRAM ou SOCK_RAW. Le plus courant est l'utilisation d'une prise SOCK_DGRAM, mais si votre but est d'écrire un démon de routage ou d'en modifier un, vous aurez plutôt besoin d'une prise de type SOCK_RAW. Le deuxième paramètre, level, identifie la couche qui capturera l'option, le message, ou la requète, ou tout ce que vous désirez appeler. De fait, SOL_SOCKET est pour la couche de la prise réseau, IPPROTO_IP est pour la couche IP, etc. Pour la programmation multicast, la valeur est toujours IPPROTO_IP. optname identifie l'option que nous passons ou demandons. Sa valeur, soit fournie par le programme, soit retournée par le noyau, est optval. Les valeurs pour optname qui peuvent être invoquées pour la programmation multicast sont les suivantes : +--------------------------------------------------+ | | setsockopt() | getsockopt() | |--------------------+--------------+--------------| | IP_MULTICAST_LOOP | oui | oui | |--------------------+--------------+--------------| | IP_MULTICAST_TTL | oui | oui | |--------------------+--------------+--------------| | IP_MULTICAST_IF | oui | oui | |--------------------+--------------+--------------| | IP_ADD_MEMBERSHIP | oui | non | |--------------------+--------------+--------------| | IP_DROP_MEMBERSHIP | oui | non | +--------------------------------------------------+ optlen transporte la taille de la structure de données à laquelle optval fait référence. Notez que pour getsockopt(), c'est un résultat et non une donnée : le noyau écrit la valeur de optname dans la zone tampon pointée par optval et nous informe de la longueur de la valeur par optlen. Aussi bien setsockopt() que getsockopt() retournent 0 en cas de succès et -1 en cas d'erreur. 6.1. IP_MULTICAST_LOOP 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) 6.2. IP_MULTICAST_TTL 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. 6.3. IP_MULTICAST_IF 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. 6.4. IP_ADD_MEMBERSHIP 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 si vous souhaitez que votre code soit portable. En lieu et place, incluez , qui inclut à son tour . 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. 6.5. IP_DROP_MEMBERSHIP 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é. 7. Fonctionnement interne Ce chapitre délivre des informations, qui ne sont ni nécessaires à la compréhension du fonctionnement du multicast, ni nécessaires à l'écriture de programmes multicast, mais qui deumeurent cependant très intéressantes car elles permettent une compréhension des concepts sur lesquels s'appuient le multicast et ses implémentations. Cela permet ainsi de contourner les erreurs les plus fréquentes et de nombreuses incompréhensions. 7.1. IGMP 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 : +-------------------------------------------------------------------------------------------------------------------------------+ | 0 | | | | | | | | | | 1 | | | | | | | | | | 2 | | | | | | | | | | 3 | | |---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---| | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 0 | 1 | |-------------------------------+-------------------------------+---------------------------------------------------------------| | Type | Temp max. de réponse | contrôle d'intégrité | |-------------------------------------------------------------------------------------------------------------------------------| | Adresse de groupe | +-------------------------------------------------------------------------------------------------------------------------------+ 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. 7.1.1. IGMP version 1 Les routeurs émettent périodiquement des requêtes IGMP sur les souscriptions des hôtes (IGMP Host Membership Queries). Ces requêtes sont faites sur le groupe all-hosts (224.0.0.1) avec un TTL de 1, ceci toutes les 1 ou 2 minutes. Tous les hôtes supportant le multicast entendent cela, mais ne répondent pas immédiatement pour éviter une tempête de réponses. Au lieu de cela, ils déclenchent un compte à rebours pour chaque groupe auquel ils appartiennent, et cela sur l'interface sur laquelle ils ont reçu la demande. Tôt ou tard, le compte à rebours expirera sur un des hôtes, ce dernier envoiera alors un IGMP Host Membership Report (résultat d'appartenance) avec un TTL de 1 à l'adresse multicast du groupe devant être rapporté. Comme le résultat est envoyé au groupe, tous les hôtes qui ont rejoint ce dernier -et qui sont actuellement en train d'attendre que leur propre délai expire- le recoive aussi. Alors, ces hôtes stoppent leur compte à rebours, et ne génèrent pas d'autres rapports. Un seul rapport est généré - par l'hôte ayant le délai le plus court-, et cela est suffisant pour le routeur. Celui-ci doit seulement savoir s'il y a des membres de ce groupe dans le sous réseau, pas qui et combien ils sont. Lorsqu'aucune réponse n'est reçue pour un groupe donné après un certain nombre de requêtes, le routeur déduit qu'il n'y a pas de membre de ce groupe sur ce sous réseau, et de ce fait n'a pas à transmettre le trafic. Notez que pour IGMPv1 il n'y a pas de message de fin d'appartenance de groupe. Lorsqu'un hôte rejoint un nouveau groupe, le noyau envoie un rapport concernant ce groupe, ainsi il n'est pas nécessaire d'attendre une ou deux minutes jusqu'a ce que la demande d'appartenance suivante soit formulée. Comme vous pouvez le constater le paquet IGMP est généré par le noyau comme étant une réponse à la commande IP_ADD_MEMBERSHIP, comme vu dans la section IP_ADD_MEMBERSHIP. Notez l'importance de l'adjectif nouveau : si la commande IP_ADD_MEMBERSHIP est effectuée sur un hôte déjà membre de ce groupe, aucun paquet IGMP n'est envoyé car nous recevons déjà le trafic pour ce groupe ; à la place, un compteur sur le nombre d'utilisateurs de ce groupe est incrémenté. IP_DROP_MEMBERSHIP ne génère aucun datagramme dans IGMPv1. Les requêtes sur les souscriptions des hôtes sont identifiées par le type 0x11, et les rapports d'appartenance par le type 0x12. Aucun rapport n'est envoyé pour le groupe all-hosts. L'appartenance à ce dernier groupe est permanente. 7.1.2. IGMP version 2 L'ajout majeur dans cette version du protocole est l'inclusion de messages de fin d'appartenance de groupe (Leave Group message) noté 0x17. La raison de cet ajout est d'éviter un gaspillage de bande passante entre le moment où le dernier hôte du sous-réseau quitte ses souscriptions et le moment où le routeur s'aperçoit qu'il n'y a plus de membre de ce groupe présent dans ce sous réseau (leave latency). Les messages de fin d'appartenance doivent être adressés au groupe all-routers (224.0.0.2) plus qu'au groupe que l'on vient de quitter, car l'information n'a pas d'utilité pour les autres membres de ce groupe (les versions du noyau ultérieures à 2.0.33 envoyent l'information au groupe ; et bien que cela ne porte pas préjudice aux hôtes, cela constitue une perte de temps car ces messages doivent êtres traités, sans pour autant donner d'information utile). Il est à noter qu'il existe certains détails subtiles à propos du moment où il est approprié ou non d'envoyer des Messages de fin d'appartenance ; si cela vous intéresse, reportez-vous au RFC. Quant un router IGMPv2 reçoit un message de fin d'appartenance de groupe, il envoie une requête « spécifique de groupe » (Group-Specific Queries) au groupe à quitter. Cela contitue un autre ajout. IGMPv1 n'a pas ces requêtes spécifiques de groupes. Toutes ces requêtes sont envoyées au groupe all-hosts. Le champ type de l'entête IGMP n'est pas amené à changer (0x11 comme précédemment), mais le champ « adresse du groupe » est rempli avec l'adresse du groupe multicast à quitter. Le champ Temps Maximum de Réponse, qui dans IGMPv1 était mis à 0 pour la transmission et ignoré à la réception, devient significatif seulement dans les messages de requêtes en appartenance (ou Membership Query). Ce champ informe du temps maximum alloué en 1/10 de secondes avant l'envoi d'un rapport. Il est donc utilisé comme mécanisme d'écoute. IGMPv2 introduit un nouveau type de message : 0x16. Il s'agit d'un « rapport d'appartence IGMPv2 » envoyé par les hôtes IGMPv2 si ceux-ci détectent qu'un routeur IGMPv2 est présent (un hôte IGMPv2 sait qu'un routeur IGMPv1 est présent s'il reçoit une requête avec le champ « Réponse Max » à 0). Lorsque plus d'un routeur se réclame comme agissant en interrogateur, IGMPv2 fournit un mécanisme pour écourter les discussions : le routeur possédant la plus petite adresse IP est désigné comme étant l'interrogateur. Les autres routeurs restent à l'écoute d'éventuels dépassements de temps de réponse. Ainsi, si le routeur ayant la plus petite adresse IP « tombe » ou est éteint, la décision pour connaitre le nouvel interrogateur est prise après que les délais aient expiré. 7.2. Aspects concernant le noyau 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. 8. Politiques de routage et techniques de retransmission Un algorithme trivial pour rendre le trafic multicast disponible partout est de l'envoyer... partout, sans se soucier des besoins des utilisateurs. Comme cela ne semble pas être bien optimisé, plusieurs algorithmes de routage et techniques de retransmission ont été implémentés. DVMRP (Distance Vector Multicast Routing Protocol, ou Protocole de routage multicast basé sur des vecteurs de distances) est, peut-être, le plus utilisé par les routeurs multicast de nos jours. Il s'agit d'un protocole de routage en mode dense, de fait, il convient bien dans les environnements à large bande passante et dont les membres sont densément distribués. Cependant, dans des scénarios moins denses, il souffre de problèmes de changement d'échelles. Il existe d'autres protocoles de routage denses, tels que MOSPF (Extentions multicast à OSPF -Open Shortest Path First) et PIM-DM (Protocol-Independent Multicast Dense Mode). Pour pouvoir faire du routage dans un environnement économe, il existe PIM-SM (Protocol Independent Multicast Sparse Mode) et CBT (Core Based Tree). OSPF version 2 est expliqué dans les RFC 1583, et MOSPF dans le RFC 1584. Les spécifications de PIM-SM et CBT peuvent être trouvées respectivement dans les RFC 2117 et 2201. Tous ces protocoles de routage utilisent différents types de retransmissions multicast, tels que le flooding (technique par indondation), RTB (ou Reverse Path Broadcasting), TRPB (ou Truncated Reverse Path Broadcasting), RPM (ou Reverse Path Multicasting) ou Shared Trees. Il serait trop long d'expliquer toutes ces techniques ici et, comme de courtes descriptions sont publiquement disponibles, je vous recommende la lecture du texte draft-ietf-mboned-in.txt. De même vous pouvez trouver les RFCs correspondants, expliquant en détails toutes les techniques et politiques employées. 9. Protocoles de transport multicast Jusqu'à présent nous avons parlé des transmissions multicast via UDP. Cela est une pratique courante, car il est impossible de faire de même avec TCP. Cependant, une recherche importante a lieu depuis un certain nombre d'années et dont le but est de développer de nouveaux protocoles de transport multicast. Plusieurs de ces protocoles ont été implémentés et testés. Une bonne leçon à tirer est qu'il ne semble pas y avoir de protocoles de transport multicast génériques et suffisament bons pour tous les types d'applications multicast. Si les protocoles de transports sont complexes et difficiles à optimiser, imaginez une façon de gérer les délais, la perte de données, l'ordonnancement, les retransmissions, le contrôle de flux et des congestions, le management des groupes, etc, lorsque le destinataire n'est pas unique, mais peut être constitué de centaines ou de milliers d'hôtes dispersés. Le changement d'échelle est donc un problème. De nouvelles techniques sont à implémenter, tel que ne pas délivrer des accusés de réception à chaque paquet reçu mais, à la place, envoyer des accusés de non-réception (negative acknowledges, ou NACKs) pour les données qui n'ont pas été reçues. Le RFC 1458 donne des propositions relatives aux conditions nécessaires à l'implémentation de tels protocoles multicasts. Donner la description de ces protocoles multicast sort de la portée de cette section. À la place, vous trouverez ci-dessous les noms de certains d'entre eux et quelques sources d'informations complémentaires : RTP, le protocole de transport temps-réel (ou Real-Time Transport Protocole) concerne les conférences multimédia multi-partite, SRM (Scalable Reliable Multicast) est utilisé par wb (l'outil servant de tableau blanc partagé, voyez la section applications multicast), URGC (Uniform Reliable Group Communication Protocol) permet des transactions fiables et ordonnées -ce protocole est basé sur un contrôle centralisé-, Muse a été développé comme un protocole d'application spécifique au transfert de nouvelles (articles) au travers du MBone, le MFTP (Protocole Multicast de Transport de Fichiers, ou Multicast File Transport Protocol) se décrit de lui-même ; les personnes « joignent » un transfert de fichier (précédemment annoncé) de la même façon qu'ils joignent une conférence, LBRM (Log-Based Receiver-reliable Multicast) est un protocole curieux qui permet de garder une trace de tous les paquets envoyés par un serveur « loggant » ces derniers -ce serveur indique à l'émetteur s'il doit retransmettre les données ou s'il peut les supprimer proprement dans le cas où tous les destinataires ont bien reçu les données. Un protocole avec un drôle de nom -spécialement pour un protocole multicast- est STORM (STructure-Oriented Resilient Multicast). De nombreux protocoles multicast peuvent être trouvés en cherchant sur Internet, de même que d'intéressants papiers proposant de nouveaux champs d'applications au Multicast (par exemple, la distribution de pages web en multicast). Une bonne page fournissant des comparaisons entre les différents protocoles multicastes fiables est http://www.tascnets.com/mist/doc/mcpCompare.html. Un très bon site (à jour !), avec des liens intéressants (Internet drafts, RFCs, papiers, liens vers d'autres sites) est : http://research.ivv.nasa.gov/RMP/links.html. http://hill.lut.ac.uk/DS-Archive/MTP.html est aussi une bonne source d'informations sur ce sujet. L'article de Katia Obraczka « Multicast Transport Protocols: A Survey and Taxonomy » donne de courtes descriptions pour chaque protocole et essaye de les classifer selon diverses fonctionnalités. Vous pouvez le lire dans le magazine IEEE Communication, Janvier 1998, vol 36, No 1. 10. Bibliographie 10.1. RFCs o RFC 1112 « Host Extensions for IP Multicasting ». Steve Deering. Août 1989. o RFC 2236 « Internet Group Management Protocol, version 2 ». W. Fenner. Novembre 1997. o RFC 1458 « Requirements for Multicast Protocols ». Braudes, R and Zabele, S. Mai 1993. o RFC 1469 « IP Multicast over Token-Ring Local Area Networks ». T. Pusateri. Juin 1993. o RFC 1390 « Transmission of IP and ARP over FDDI Networks ». D. Katz. Janvier 1993. o RFC 1583 « OSPF Version 2 ». John Moy. Mai 1994. o RFC 1584 « Multicast Extensions to OSPF ». John Moy. Mai 1994. o RFC 1585 « MOSPF: Analysis and Experience ». John Moy. Mai 1994. o RFC 1812 « Requirements for IP version 4 Routers ». Fred Baker, Editor. Juin 1995. o RFC 2117 « Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification ». D. Estrin, D. Farinacci, A. Helmy, D. Thaler; S. Deering, M. Handley, V. Jacobson, C. Liu, P. Sharma, and L. Wei. Juillet 1997. o RFC 2189 « Core Based Trees (CBT version 2) Multicast Routing ». A. Ballardie. Septembre 1997. o RFC 2201 « Core Based Trees (CBT) Multicast Routing Architecture ». A. Ballardie. Septembre 1997. 10.2. Brouillons Internet (Internet Drafts) o « Introduction to IP Multicast Routing ». draft-ietf-mboned-intro-multicast-03.txt. T. Maufer, C. Semeria. Juillet 1997 o « Administratively Scoped IP Multicast ». draft-ietf-mboned-admin-ip-space-03.txt. D. Meyer. 10 Juin 1997. 10.3. Pages web o Page d'accueil du Multicast sous Linux. http://web.archive.org/web/20010209032950/http://www.cs.washington.edu/homes/esler/multicast/ [http://web.archive.org/web/20010209032950/http://www.cs.washington.edu/homes/esler/multicast/] o Foire Aux Questions (FAQ) Multicast sous Linux. http://andrew.triumf.ca/pub/linux/multicast-FAQ [http://andrew.triumf.ca/pub/linux/multicast-FAQ] o Multicast et MBONE sous Linux. http://web.archive.org/web/19990128143933/http://www.teksouth.com/linux/multicast/ [http://web.archive.org/web/19990128143933/http://www.teksouth.com/linux/multicast/] o Liens sur les protocoles multicast fiables http://www.nard.net/~tmont/rm-links.html [http://www.nard.net/~tmont/rm-links.html] o Protocoles de Transport Multicast http://web.archive.org/web/20020124084206/http://hill.lut.ac.uk/DS-Archive/MTP.html [http://web.archive.org/web/20020124084206/http://hill.lut.ac.uk/DS-Archive/MTP.html] 10.4. Livres o « TCP/IP Illustrated: Volume 1 The Protocols ». Stevens, W. Richard. Addison Wesley Publishing Company, Reading MA, 1994 o « TCP/IP Illustrated: Volume 2, The Implementation ». Wright, Gary and W. Richard Stevens. Addison Wesley Publishing Company, Reading MA, 1995 o « UNIX Network Programming Volume 1. Networking APIs: Sockets and XTI ». Stevens, W. Richard. Second Edition, Prentice Hall, Inc. 1998. o « Internetworking with TCP/IP Volume 1 Principles, Protocols, and Architecture ». Comer, Douglas E. Second Edition, Prentice Hall, Inc. Englewood Cliffs, New Jersey, 1991 11. Licence et mise en garde Copyright © 1998 Juan-Mariano de Goyeneche pour la version originale. Copyright © 2003 Antoine Duval & Fabrice Gadaud pour la version française. Ce guide pratique est un document libre ; vous pouvez le redistribuer et le modifier selon les termes de la Licence publique générale GNU (GPL) telle que publiée par la Free Software Foundation, dans sa version 2, ou (a votre souhait) toute version ultérieure. Ce document est distribué dans l'espoir qu'il vous soit utile, mais sans aucune garantie ; sans même la garantie implicite de la valeur marchande ou de l'utilisation dans un but particulier. Consultez la Licence publique générale GNU (GPL) pour plus de détails. Vous pouvez obtenir une copie de cette licence en écrivant à la Free Software Foundation, 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. Si vous publiez ce document sur un CD-ROM ou sous la forme d'une copie physique, une copie complémentaire sera la bienvenue ; envoyez-moi un courrier électronique (en anglais) à l'adresse . N'hesitez pas non plus à faire une donation au Projet de documentation Linux (LDP) ou à la Free Software Foundation pour apporter votre soutien au projet de documentation libre pour Linux/GNU. Contactez le Projet de documentation Linux pour plus d'informations.