100 lines
5.0 KiB
HTML
100 lines
5.0 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: Introduction. </TITLE>
|
|
<LINK HREF="Multicast-HOWTO-2.html" REL=next>
|
|
|
|
<LINK HREF="Multicast-HOWTO.html#toc1" REL=contents>
|
|
</HEAD>
|
|
<BODY>
|
|
<A HREF="Multicast-HOWTO-2.html">Next</A>
|
|
Previous
|
|
<A HREF="Multicast-HOWTO.html#toc1">Contents</A>
|
|
<HR>
|
|
<H2><A NAME="s1">1. Introduction. </A></H2>
|
|
|
|
<P>I'll try to give here the most wide range, up to date and accurate
|
|
information related to multicasting over TCP/IP networks that I can. Any
|
|
feedback is very welcome. If you find any
|
|
mistakes in this document, have any comments about its contents or an update or
|
|
addition, please send them to me at the address listed at the top of this howto.
|
|
<P>
|
|
<P>
|
|
<H2><A NAME="ss1.1">1.1 What is Multicast.</A>
|
|
</H2>
|
|
|
|
<P>Multicast is... a need. Well, at least in some scenarios. If you
|
|
have information (a <EM>lot</EM> of information, usually) that should be
|
|
transmitted to various (but usually not <EM>all</EM>) hosts over an internet,
|
|
then Multicast is the answer. One common situation in which
|
|
it is used is when distributing real time audio and video to the
|
|
set of hosts which have joined a distributed conference.
|
|
<P>Multicast is much like radio or TV in the sense that only those who
|
|
have tuned their receivers (by selecting a particular frequency
|
|
they are interested on) receive the information. That is:
|
|
you hear the channel you are interested in, but not the others.
|
|
<P>
|
|
<P>
|
|
<H2><A NAME="ss1.2">1.2 The problem with Unicast.</A>
|
|
</H2>
|
|
|
|
<P>Unicast is anything that is not broadcast nor multicast. All right,
|
|
the definition
|
|
is not very bright... When you send a packet and there is only one
|
|
sender process -yours- and one recipient process (the <EM>one</EM> you are
|
|
sending the packet to), then this is unicast. TCP is, by its own nature,
|
|
unicast oriented. UDP supports a lot more paradigms, but if you are
|
|
sending UDP packets and there is only one precess supposed to receive
|
|
them, this is unicast too.
|
|
<P>For years unicast transmissions proved to be enough for the Internet.
|
|
It was not until 1993 when the first implementation of multicast saw
|
|
the light in the 4.4 BSD release. It seems nobody needed it until
|
|
then. Which were those new problems that multicast addressed?
|
|
<P>Needless to say that the Internet has changed a lot since the "early
|
|
days". Particularly, the appearance of the Web strongly transformed
|
|
the situation: people didn't just want connections to remote hosts,
|
|
mail and FTP. First they wanted to see the pictures people placed in
|
|
their home pages, but later they also wanted to <EM>see</EM> and <EM>hear</EM>
|
|
that people.
|
|
<P>With today's technology it is possible to afford the "cost" of making
|
|
a unicast connection with everyone who wants to see your web page.
|
|
However, if you are to send audio and video, which needs a <EM>huge</EM>
|
|
amount of bandwidth compared with web applications, you have -you <EM>had</EM>,
|
|
until multicast came into scene- two options: to establish a separate
|
|
unicast connection with <EM>each</EM> of the recipients, or to use broadcast.
|
|
The first solution is not affordable: if we said that a <EM>single</EM>
|
|
connection sending audio/video consumes a huge bandwidth, imagine
|
|
having to establish hundreds or, may be, thousands of those connections.
|
|
Both the sending computer and your network would collapse.
|
|
<P>Broadcast seems to be <EM>a</EM> solution, but it's not certainly <EM>the</EM> solution.
|
|
If you want all the hosts in your LAN to attend the conference, you
|
|
may use broadcast. Packets will be sent only once and every host will
|
|
receive them as they are sent to the broadcast address. The problem
|
|
is that perhaps only a <EM>few</EM> of the hosts and not <EM>all</EM> are interested
|
|
in those packets. Furthermore: perhaps some hosts are really interested
|
|
in your conference, but they are outside of your LAN, a few routers away.
|
|
And you know that broadcast works fine inside a LAN, but problems arise
|
|
when you want broadcast packets to be routed across different LANs.
|
|
<P>The best solution seems to be one in which you send packets to a certain
|
|
special address (a certain frequency in radio/TV transmissions). Then,
|
|
all hosts which have decided to join the conference will be aware of
|
|
packets with that destination address, read them when they traverse
|
|
the network, and pass them to the IP layer to be demultiplexed. This is
|
|
similar to broadcasting in that you send only one broadcast packet and
|
|
all the hosts in the network recognize and read it; it differs, however,
|
|
in that not all multicast packets are read and processed, but only those
|
|
that were previously registered in the kernel as being "of interest".
|
|
<P>Those special packets are routed at kernel level like any packet because
|
|
they <EM>are</EM> IP packets. The only difference might reside in the routing
|
|
algorithm which tells the kernel where to route or not to route them.
|
|
<P>
|
|
<P>
|
|
<P>
|
|
<HR>
|
|
<A HREF="Multicast-HOWTO-2.html">Next</A>
|
|
Previous
|
|
<A HREF="Multicast-HOWTO.html#toc1">Contents</A>
|
|
</BODY>
|
|
</HTML>
|