Sophie

Sophie

distrib > * > 2010.0 > * > by-pkgid > a412ceb851151854794ced2a242192bb > files > 2414

howto-html-fr-20080722-1mdv2010.0.noarch.rpm

<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<title>9. Protocoles de transport multicast</title>
<link rel="stylesheet" href="style.css" type="text/css">
<meta name="generator" content="DocBook XSL Stylesheets V1.64.1">
<link rel="home" href="index.html" title="Guide pratique du multicast sur les réseaux TCP/IP">
<link rel="up" href="index.html" title="Guide pratique du multicast sur les réseaux TCP/IP">
<link rel="previous" href="ar01s08.html" title="8. Politiques de routage et techniques de retransmission">
<link rel="next" href="ar01s10.html" title="10. Bibliographie">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
<div class="navheader">
<table width="100%" summary="Navigation header">
<tr><th colspan="3" align="center">9. Protocoles de transport multicast</th></tr>
<tr>
<td width="20%" align="left">
<a accesskey="p" href="ar01s08.html">Précédent</a> </td>
<th width="60%" align="center"> </th>
<td width="20%" align="right"> <a accesskey="n" href="ar01s10.html">Suivant</a>
</td>
</tr>
</table>
<hr>
</div>
<div class="sect1" lang="fr">
<div class="titlepage">
<div><div><h2 class="title" style="clear: both">
<a name="Proto-transport-multicast"></a>9. Protocoles de transport multicast</h2></div></div>
<div></div>
</div>
<p>
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.
   </p>
<p>
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.
   </p>
<p>
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.
  </p>
<p>
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
<span class="emphasis"><em>wb</em></span> (l'outil servant de tableau blanc partagé, voyez
la <a href="ar01s05.html">section applications multicast</a>), 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).
  </p>
<p>
Une bonne page fournissant des comparaisons entre les différents protocoles multicastes fiables est http://www.tascnets.com/mist/doc/mcpCompare.html.
  </p>
<p>
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.
  </p>
<p>
http://hill.lut.ac.uk/DS-Archive/MTP.html est aussi une bonne source d'informations sur ce sujet.
  </p>
<p>
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.
  </p>
</div>
<div class="navfooter">
<hr>
<table width="100%" summary="Navigation footer">
<tr>
<td width="40%" align="left">
<a accesskey="p" href="ar01s08.html">Précédent</a> </td>
<td width="20%" align="center"><a accesskey="u" href="index.html">Niveau supérieur</a></td>
<td width="40%" align="right"> <a accesskey="n" href="ar01s10.html">Suivant</a>
</td>
</tr>
<tr>
<td width="40%" align="left" valign="top">8. Politiques de routage et techniques de retransmission </td>
<td width="20%" align="center"><a accesskey="h" href="index.html">Sommaire</a></td>
<td width="40%" align="right" valign="top"> 10. Bibliographie</td>
</tr>
</table>
</div>
</body>
</html>