Voici quelques protocoles multicast et la raison pour laquelle je les présente :
- MTP parce qu’il est le premier à être apparu et donc la référence des autres protocoles,
- IGMP parce que c'est le plus connu qui permet d’utiliser le multicast sur les réseaux distants (comme Internet),
- LGMP parce que c'est le seul dont j'ai trouvé les sources sur Internet,
- MFTP parce que c’est celui que j'ai eu l'occasion d'implémenter, donc celui que je connais le mieux.
Mis à part MFTP, les autres ne sont décrits que succinctement.
Je donne également quelques adresses pour rechercher des informations supplémentaires sur le multicast : un comparatif des différents protocoles existants et une page de liens, le tout en anglais...
MTP (Multicast Transfert Protocol)
MTP est le premier protocole multicast qui soit apparu. Les autres protocoles multicast s’appuient en grande partie sur celui-ci.
Il est décrit dans la RFC 1301. Les RFC (Request For Comment) sont des documents contenant toutes les spécifications des protocoles réseaux.
Ce protocole n’a pas pour vocation d’être rapide et d’obtenir des taux de transfert exceptionnels. Il est surtout fait pour ne pas saturer le réseau.
Dans MTP, il y a un ordinateur maître qui joue le rôle de chef-d’orchestre. Les autres membres peuvent être tour à tour ceux qui envoient les données et ceux qui les reçoivent. Une personne peut devenir membre à tout moment si sa requête est acceptée par l’ordinateur maître.
Le maître donne la parole à ceux qui la demandent. Il vérifie que toutes les données d’un transfert aient été envoyées et reçues, puis autorise le membre suivant qui le demande à envoyer ses données. Les clients qui ont mal reçu les données font une requête auprès de l’ordinateur maître.
On définit un intervalle de temps appelé « battement de cœur ». C’est un intervalle de temps en millisecondes qui permet au client de se repérer dans la réception des données. Un battement de cœur intervient toutes les 160 - 200 ms, soit toutes les 17 - 20 trames de données (la RFC prévoit une trame toutes les 8.4 ms).
Ce protocole n’est pas d’une grande efficacité, mais comme je le disais au début du paragraphe, les principes de fonctionnement qu’il propose ont été repris pour développer de nouveaux protocoles plus performants.
IGMP (Internet Group Management Protocol)
Ce protocole est défini dans la RFC 1112 (Host Extensions for IP Multicasting). Cette RFC décrit les spécifications qu’un client doit suivre pour pouvoir devenir membre d’un groupe multicast sur un réseau IP.
Il spécifie non seulement la marche à suivre pour rejoindre ou quitter un groupe multicast, mais également comment se déclarer membre multicast auprès du routeur le plus proche pour que les trames multicast parviennent jusqu’à lui.
Tous les routeurs ne supportent pas le multicast, ceux qui le supportent sont appelés routeurs multicast et sont conformes aux spécifications IGMP.
Il n’est pas obligatoire de supporter IGMP et les spécifications de la RFC 1112 pour envoyer des datagrammes en multicast, ni pour les recevoir dans un réseau local. Cependant, s'il y a un routeur entre la source et la destination, les données ne pourront arriver que si le client et le routeur supportent IGMP.
Pour un travail en local, il n’y a donc aucune obligation d’implémenter ce protocole. Cependant, pour des utilisations ultérieures du multicast, ce serait un plus si les clients supportaient IGMP : il n’y aurait dès lors aucune restriction à l’utilisation du multicast sur les réseaux distants et notamment sur Internet.
Il n’y a que deux types de messages IGMP concernant les clients. Le premier est la recherche des membres multicast (« Host Membership Query »), qui est envoyée par le routeur à l’adresse 224.0.0.1 (tous les clients multicast) avec un TTL de 1. Le deuxième est la réponse du membre multicast (« Host Membership Report ») au routeur en lui spécifiant le ou les groupes (adresses) multicast dont il est membre.
Lorsque cette phase est achevée, les membres multicast peuvent recevoir les trames multicast venant de réseaux distants et ayant un TTL (Time To Live) suffisamment important pour arriver jusqu’à eux.
LGMP (Local Group Multicast Protocol)
LGMP est le seul protocole implémenté que j'ai trouvé. C’est également un protocole qui fait beaucoup parler de lui dans le domaine du multicast.
En effet, au cours d’une recherche sur les protocoles multicast, celui-ci était décrit comme conçu pour les réseaux locaux et destiné aux transfert de fichiers et aux flux de données. Autant dire qu’il correspondait exactement à ce que nous cherchions...
Je vous en donne l'adresse si vous êtes intéressé. Celui qui s'occupe de ce développement, Markus Hoffman, est un homme remarquable qui vous informera mieux que moi à son sujet.
Local Group Multicast Protocol - Markus Hoffman - http://www.tascnets.com/mist/doc/LGMP.html
MFTP (Multicast File Transfert Protocol)
MFTP n’est pas décrit dans une RFC classique, mais est décrit dans un document disponible sur Internet (internet-draft) qui donne donc l’état d’avancement d’une recherche. MFTP est soumis à la propriété intellectuelle et appartient à Starburst Communications Corporation.
Adresses privées et adresses publiques
MFTP spécifie deux types d’adresse, les adresses privées et publiques.
Les serveurs annoncent les fichiers qu’ils vont envoyer sur une adresse multicast publique. Ces annonces sont des trames contenant entre autres les informations suivantes : le nom du fichier, l’adresse multicast où le fichier va être envoyée et la taille des données.
Tous les clients écoutent les annonces sur cette adresse. Si un client est intéressé par les données qui vont être envoyées, il fait une requête auprès du serveur pour être autorisé à rejoindre l’adresse multicast privée où les données vont être envoyées.
De cette façon, le serveur sait en permanence qui reçoit quoi. Cela permet en quelque sorte au serveur de faire des statistiques sur les clients. Il a le droit de refuser un client s'il estime qu’il n’a pas les ressources nécessaires pour gérer tous les clients ou s'il est clairement spécifié que tel client n’a pas le droit de recevoir ces données.
Lorsque le serveur a fini la phase d’annonce, lui et les clients qu’il a acceptés se retrouvent sur une autre adresse, l’adresse privée spécifiée dans l’annonce. C’est à cette adresse que le serveur envoie le fichier en suivant un algorithme qui sera décrit ultérieurement.
Ce principe d’annonces est très intéressant non seulement pour le transfert de fichier, mais également pour les flux multimédia. On peut imaginer qu’un même serveur puisse envoyer plusieurs flux audio ou vidéo. Il fait l’annonce sur l’adresse en spécifiant le format des données (par exemple, données d’un fichier wav au format 44100 kHz, 16 bits, Stéréo). Ainsi, le client peut rejoindre quand il le veut le flux multimédia et sait le format des données qu’il reçoit. Le serveur n’a plus qu ‘à envoyer des données « brut » sur l’adresse multicast privée.
Ce principe serait le même qu’une radio avec une fréquence réservée où circuleraient en permanence les informations « France Info : 104.5, RFM : 100.1, etc... ». C’est ce qu’on cherche à faire dans le cadre de l’application « flux multimédia ».
Envoi d’un fichier sur une adresse privée
Le fichier est divisé en blocs qui sont eux même divisés en DTU (Data Transfert Unit). Le nombre de DTU par bloc et le nombre de blocs par fichier n’est pas explicitement donné dans les spécifications.
L’algorithme suivi par le serveur pour envoyer le fichier à l’adresse privée est le suivant. Il est divisé en plusieurs temps, chaque temps est appelé « Pass ».
Pass 1 : Tous les DTU sont envoyés dans l’ordre, soit (Bloc 1, DTU 1), puis (Bloc 1, DTU 2), jusqu’au dernier DTU du dernier bloc.
A la fin de chaque bloc, le serveur demande un rapport de réception aux clients. Ceux qui ont bien reçu les données ne répondent pas à cette requête. Ceux qui ont mal reçu ou pas reçu un DTU envoient un message au serveur en spécifiant le numéro de bloc et le numéro de DTU qu’il doit envoyer à nouveau.
Quand une trame est perdue pour un client, il y a de fortes chances qu’il ne soit pas le seul à l’avoir mal reçue. Pour éviter que tous les clients n’envoient la même réponse de trame perdue au serveur, les clients s’écoutent les uns les autres et seules les trames perdues que personne n’a signalées sont redemandées au serveur.
Cela évite au serveur d’être débordé par les réponses des clients.
Pendant ce temps, le serveur continue d’envoyer la suite du fichier sans s’occuper des réponses des clients. Il les récupère et les garde dans un coin en attendant la fin du « Pass 1 ».
Lorsqu’un client a reçu tout le fichier sans faute, il envoie au serveur un message « Done » et le serveur sait que ce client à tout reçu correctement.
A la fin du Pass 1, l’ensemble du fichier a été envoyé. Le serveur regarde alors les réponses des clients. S’il a des messages « Done » de tous les clients, ceux-ci ont tout reçu correctement. Sinon, commence le « Pass 2 ».
Pass 2 : Le serveur regarde les trames manquantes rapportées par les clients et les réexpédie. A la fin ou au cours de la retransmission des trames manquantes, qui gardent leur numéro de bloc et de DTU d’origine, il demande à nouveau aux clients un rapport de réception. S’il n’obtient que des réponses « Done », cela signifie que le transfert est terminé, sinon, il examine les réponses qui lui reviennent, commence le Pass 3, etc...
La transmission est terminée lorsque tous les clients ont répondu « Done » ou au bout d’un temps défini sans réponse de la part des clients.
Format des trames
MFTP est placé directement au-dessus de UDP, et est séparé en trois parties :
- L’en-tête du message
- Les paramètres du message
- Les données (s'il y en a)
En-tête du message
Elle a une taille fixe de 12 octets et est présente dans toutes les trames MFTP.
Version du protocole : la version étudiée ici est la version 1.
Type de message : il en existe 16 qui sont définis dans les spécifications, je ne citerai que ceux dont on a parlé : le message de données (« Data Transfer » 0x0005), le message d’annonce (« Announce » 0x0004), la demande du rapport de réception (« Status request » 0x0006) et le message de fin de transfert (« Done » 0x000B).
Longueur du message : c’est la longueur du message (y compris l’en-tête MFTP) en octets.
Checksum : normalement, il devrait être identique à celui de UDP, mais il est spécifié que lorsque les messages sont envoyés sur UDP, il est laissé à zéro et n’est pas utilisé. Il est inutile de faire deux fois le même calcul.
Identifiant de transmission : c’est un nombre unique qui identifie la transmission en cours et qui restera le même pendant toute la durée du transfert. Pour chaque fichier, ce nombre doit changer.
Les paramètres du message et les données
Les paramètres sont précisés pour chaque message. Nous verrons ici, à titre d’exemple, les paramètres du message de transmission de données (DTU).
Pour les DTU, il y a 4 paramètres :
- Numéro de Pass (Pass Number)
- Numéro de Bloc (Block Number)
- Numéro de DTU (DTU Number)
- Nombre d’octets du fichier déjà envoyés (Product Data)
Chaque paramètre est codé au moins sur 8 octets et est codé sur un nombre d’octets multiple de 4.
Les 2 premiers octets donnent le type de paramètre, les deux octets suivants donnent sa longueur en octets :
- Numéro de Pass : type 0x0117, longueur 4 octets.
- Numéro de Bloc : type 0x0103, longueur 4 octets.
- Numéro de DTU : type 0x010A, longueur 4 octets.
- Nombre d’octets envoyés : type 0x0119, longueur variable (généralement 8 octets).
Les données suivent directement les paramètres. Ce qui donne par exemple, pour les messages de transfert de données (DTU), le message suivant :
On pose ce message sur une trame UDP et on l’envoie. Le poste client récupère le message et le découpe de la même façon pour retrouver les données et les paramètres.