Java Reference
In-Depth Information
Figure 13-1. Multicast from New York to San Francisco, Los Angeles, and Houston
When people talk about multicasting, audio and video are the first applications that
come to mind. Indeed, the BBC has been
running a multicast trial
covering both TV
and radio for several years now, though ISP participation has been regrettably limited.
However, audio and video are only the tip of the iceberg. Other possibilities include
multiplayer games, distributed filesystems, massively parallel computing, multiperson
conferencing, database replication, content delivery networks, and more. Multicasting
can be used to implement name services and directory services that don't require the
client to know a server's address in advance; to look up a name, a host could multicast
its request to some well-known address and wait until a response is received from the
nearest server. Apple's Bonjour (a.k.a. Zeroconf ) and
Apache's River
both use IP mul‐
ticasting to dynamically discover services on the local network.
Multicasting has been designed to fit into the Internet as seamlessly as possible. Most
of the work is done by routers and should be transparent to application programmers.
An application simply sends datagram packets to a multicast address, which isn't fun‐
damentally different from any other IP address. The routers make sure the packet is
delivered to all the hosts in the multicast group. The biggest problem is that multicast
routers are not yet ubiquitous; therefore, you need to know enough about them to find
out whether multicasting is supported on your network. For instance, although the BBC
has been multicasting for several years now, their multicast streams are only accessible
to subscribers of about a dozen relatively small British ISPs. In practice, multicasting is
