73 lines
4.1 KiB
HTML
73 lines
4.1 KiB
HTML
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
|
|
<HTML>
|
|
<HEAD>
|
|
<META NAME="GENERATOR" CONTENT="SGML-Tools 1.0.9">
|
|
<TITLE>Multicast over TCP/IP HOWTO: Multicast Transport Protocols.</TITLE>
|
|
<LINK HREF="Multicast-HOWTO-10.html" REL=next>
|
|
<LINK HREF="Multicast-HOWTO-8.html" REL=previous>
|
|
<LINK HREF="Multicast-HOWTO.html#toc9" REL=contents>
|
|
</HEAD>
|
|
<BODY>
|
|
<A HREF="Multicast-HOWTO-10.html">Next</A>
|
|
<A HREF="Multicast-HOWTO-8.html">Previous</A>
|
|
<A HREF="Multicast-HOWTO.html#toc9">Contents</A>
|
|
<HR>
|
|
<H2><A NAME="sect-trans-prots"></A> <A NAME="s9">9. Multicast Transport Protocols.</A></H2>
|
|
|
|
<P>So far we have been talking about multicast transmissions using UDP. This
|
|
is the usual practice, as it is impossible to do it with TCP. However,
|
|
intense research is taking place since a couple of years in order to develop
|
|
some new multicast transport protocols.
|
|
<P>Several of these protocols have been implemented and are being tested. A good
|
|
lesson from them is that it seems no multicast transport protocol is general
|
|
and good enough for all types of multicast applications.
|
|
<P>If transport protocols are complex and difficult to tune,
|
|
imagine dealing with delays (in multimedia conferences), data loss, ordering,
|
|
retransmissions, flow and congestion control, group management, etc, when
|
|
the receiver is not one, but perhaps hundreds or thousands of sparse hosts.
|
|
Here scalability is an issue, and new techniches are implemented, such as
|
|
not giving acknowledges for every packet received but, instead, send <EM>negative
|
|
acknowledges</EM> (NACKs) for data not received. RFC 1458 gives the proposed
|
|
requirements for multicast protocols.
|
|
<P>Giving descriptions of those multicast protocols is out of the scope of this
|
|
section. Instead, I'll give you the names of some of them and point you to
|
|
some sources of information: Real-Time Transport Protocol (RTP) is concerned
|
|
with multi-partite multimedia conferences, <B>Scalable Reliable Multicast</B> (SRM) is
|
|
used by the <CODE>wb</CODE> (the distributed White-Board tool, see section
|
|
<A HREF="Multicast-HOWTO-5.html#sect-applications">Multicast applications</A>),
|
|
<B>Uniform Reliable Group Communication Protocol</B> (URGC) enforces reliable and
|
|
ordered transactions based in a centralized control, <B>Muse</B> was developed as an
|
|
application specific protocol: to multicast news articles over the MBone, the
|
|
<B>Multicast File Transfer Protocol</B> (MFTP) is quite descriptive by itself
|
|
and people "join" to file transmission (previously announced) much in the same
|
|
way they would join a conference, <B>Log-Based Receiver-reliable Multicast</B>
|
|
(LBRM) is a curious protocol that keeps track of all packets sent in a logging
|
|
server that tells the sender whether it has to retransmit the data or can
|
|
drop it safely as all receivers got it. One protocol with a funny name
|
|
-especially for a multicast protocol- is STORM (<B>STructure-Oriented
|
|
Resilient Multicast</B>). Lots and lots of multicast protocols can be found
|
|
searching the Web, along with some interesting papers proposing new
|
|
activities for multicast (for instance, www page distribution using multicast).
|
|
<P>A good page providing comparisons between reliable multicast protocols is
|
|
<P>
|
|
<A HREF="http://www.tascnets.com/mist/doc/mcpCompare.html">http://www.tascnets.com/mist/doc/mcpCompare.html</A>.
|
|
<P>A very good and up-to-date site, with lots of interesting links (Internet
|
|
drafts, RFCs, papers, links to other sites) is:
|
|
<P>
|
|
<A HREF="http://research.ivv.nasa.gov/RMP/links.html">http://research.ivv.nasa.gov/RMP/links.html</A>.
|
|
<P>
|
|
<A HREF="http://hill.lut.ac.uk/DS-Archive/MTP.html">http://hill.lut.ac.uk/DS-Archive/MTP.html</A> is also a good source
|
|
of information on the subject.
|
|
<P>Katia Obraczka's "<EM>Multicast Transport Protocols: A Survey and Taxonomy</EM>"
|
|
article gives short descriptions for each protocol and tries to classify them
|
|
according to different features. You can read it in the IEEE Communications
|
|
magazine, January 1998, vol. 36, No. 1.
|
|
<P>
|
|
<P>
|
|
<HR>
|
|
<A HREF="Multicast-HOWTO-10.html">Next</A>
|
|
<A HREF="Multicast-HOWTO-8.html">Previous</A>
|
|
<A HREF="Multicast-HOWTO.html#toc9">Contents</A>
|
|
</BODY>
|
|
</HTML>
|