Java Reference
In-Depth Information
nating site to other servers, which replicate it to still other servers, which eventually
replicate it to clients. Each client connects to the nearest server. This is more efficient
than sending everything to all interested clients via multiple unicasts, but the scheme
is kludgy and beginning to show its age. New sites need to find a place to hook into the
tree manually. The tree does not necessarily reflect the best possible topology at any one
time, and servers still need to maintain many point-to-point connections to their clients,
sending the same data to each one. It would be better to allow the routers in the Internet
to dynamically determine the best possible routes for transmitting distributed infor‐
mation and to replicate data only when absolutely necessary. This is where multicasting
comes in.
For example, if you're multicasting video from New York and 20 people attached to one
LAN are watching the show in Los Angeles, the feed will be sent to that LAN only once.
If 50 more people are watching in San Francisco, the data stream will be duplicated
somewhere (let's say Fresno) and sent to the two cities. If a hundred more people are
watching in Houston, another data stream will be sent there (perhaps from St. Louis);
see
Figure 13-1
. The data has crossed the Internet only three times—not the 170 times
that would be required by point-to-point connections, or the millions of times that
would be required by a true broadcast. Multicasting is halfway between the point-to-
point communication common to the Internet and the broadcast model of television
and it's more efficient than either. When a packet is multicast, it is addressed to a mul‐
ticast group and sent to each host belonging to the group. It does not go to a single host
(as in unicasting), nor does it go to every host (as in broadcasting). Either would be too
inefficient.
