Java Network Programming (3rd ed) [Electronic resources] نسخه متنی

14.1 What Is a Multicast Socket?

Multicasting
is broader than unicast, point-to-point communication but narrower
and more targeted than broadcast communication. Multicasting sends
data from one host to many different hosts, but not to everyone; the
data only goes to clients that have expressed an interest by joining
a particular multicast group. In a way, this is like a public
meeting. People can come and go as they please, leaving when the
discussion no longer interests them. Before they arrive and after
they have left, they don't need to process the
information at all: it just doesn't reach them. On
the Internet, such "public
meetings" are best implemented using a multicast
socket that sends a copy of the data to a location (or a group of
locations) close to the parties that have declared an interest in the
data. In the best case, the data is duplicated only when it reaches
the local network serving the interested clients: the data crosses
the Internet only once. More realistically, several identical copies
of the data traverse the Internet; but, by carefully choosing the
points at which the streams are duplicated, the load on the network
is minimized. The good news is that programmers and network
administrators aren't responsible for choosing the
points where the data is duplicated or even for sending multiple
copies; the Internet's routers handle all that.

IP also supports broadcasting,
but the use of broadcasts is strictly limited. Protocols require
broadcasts only when there is no alternative, and routers limit
broadcasts to the local network or subnet, preventing broadcasts from
reaching the Internet at large. Even a few small global broadcasts
could bring the Internet to its knees. Broadcasting high-bandwidth
data such as audio, video, or even text and still images is out of
the question. A single email spam that goes to millions of addresses
is bad enough. Imagine what would happen if a real-time video feed
were copied to all six hundred million Internet users, whether they
wanted to watch it or not.

However, there's a middle ground between
point-to-point communications and broadcasts to the whole world.
There's no reason to send a video feed to hosts that
aren't interested in it; we need a technology that
sends data to the hosts that want it, without bothering the rest of
the world. One way to do this is to use many unicast streams. If
1,000 clients want to listen to a RealAudio broadcast, the data is
sent a thousand times. This is inefficient, since it duplicates data
needlessly, but it's orders-of-magnitude more
efficient than broadcasting the data to every host on the Internet.
Still, if the number of interested clients is large enough, you will
eventually run out of bandwidth or CPU powerprobably sooner
rather than later.

Another approach to the problem is to create static
connection trees. This is the solution employed by Usenet
news and some conferencing systems (notably CUseeMe). Data is fed
from the originating 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 information 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 14-1. The data has crossed the Internet only
three timesnot 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 multicast
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.

Figure 14-1. Multicast from New York to San Francisco, Los Angeles, and Houston

When people start talking about multicasting, audio and video are the
first applications that come to mind; however, they are only the tip
of the iceberg. Other possibilities include multiplayer games,
distributed filesystems, massively parallel computing, multiperson
conferencing, database replication, 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
Rendezvous
(a.k.a. Zeroconf)
and Sun's
Jini both use IP
multicasting to dynamically discover services on the local network.

Multicasting should also make it easier to implement various kinds of
caching for the Internet, which will be important if the
Net's population continues to grow faster than
available bandwidth. Martin Hamilton has proposed using multicasting
to build a distributed server system for the World Wide Web.
("Evaluating Resource Discovery Applications of IP
Multicast", http://martinh.net/eval/evall, 1995.) For
example, a high-traffic web server could be split across multiple
machines, all of which share a single hostname, mapped to a multicast
address. Suppose one machine chunks out HTML files, another handles
images, and a third processes servlets. When a client makes a request
to the multicast address, the request is sent to each of the three
servers. When a server receives the request, it looks to see whether
the client wants an HTML file, an image, or a servlet response. If
the server can handle the request, it responds. Otherwise, the server
ignores the request and lets the other servers process it. It is easy
to imagine more complex divisions of labor between distributed
servers.

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
fundamentally 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. As far as the application
itself, you need to pay attention to an additional header field in
the datagrams called
the Time-To-Live (TTL) value. The TTL is the maximum number of
routers that the datagram is allowed to cross; when it reaches the
maximum, it is discarded. Multicasting uses the TTL as an ad hoc way
to limit how far a packet can travel. For example, you
don't want packets for a friendly on-campus game of
Dogfight reaching routers on the other side of the world. Figure 14-2 shows how TTLs limit a
packet's spread.

Figure 14-2. Coverage of a packet with a TTL of five

14.1.1 Multicast Addresses and Groups

A multicast
address is the shared address of a group of hosts called a
multicast group. We'll talk
about the address first. Multicast addresses are
IP addresses in the range 224.0.0.0
to 239.255.255.255. All addresses in this range have the binary
digits 1110 as their first four bits. They are called Class D
addresses to distinguish them from the more common Class A, B, and C
addresses. Like any IP address, a multicast address can have a
hostname; for example, the multicast address 224.0.1.1 (the address
of the Network Time Protocol distributed service) is assigned the
name ntp.mcast.net.

A multicast group is a set of Internet hosts that share a multicast
address. Any data sent to the multicast address is relayed to all the
members of the group. Membership in a multicast group is open; hosts
can enter or leave the group at any time. Groups can be either
permanent or transient. Permanent groups have assigned addresses that
remain constant, whether or not there are any members in the group.
However, most multicast groups are transient and exist only as long
as they have members. All you have to do to create a new multicast
group is pick a random address from 225.0.0.0 to 238.255.255.255,
construct an InetAddress object for that address,
and start sending it data.

A number of multicast addresses have been set aside for special
purposes. all-systems.mcast.net, 224.0.0.1, is a
multicast group that includes all systems that support multicasting
on the local subnet. This group is commonly used for local testing,
as is experiment.mcast.net, 224.0.1.20. (There
is no multicast address that sends data to all hosts on the
Internet.) All addresses beginning with 224.0.0 (i.e., addresses from
224.0.0.0 to 224.0.0.255) are reserved for routing protocols and
other low-level activities, such as gateway discovery and group
membership reporting. Multicast routers never forward datagrams with
destinations in this range.

The IANA is responsible
for handing out permanent multicast addresses as needed; so far, a
few hundred have been specifically assigned. Most of these begin with
224.0., 224.1., 224.2., or 239. Table 14-1 lists a
few of these permanent addresses. A few blocks of addresses ranging
in size from a few dozen to a few thousand addresses have also been
reserved for particular purposes. The complete list is available
from
http://www.iana.org/assignments/multicast-addresses. The
remaining 248 million Class D addresses can be used on a temporary
basis by anyone who needs them. Multicast routers
(mrouters for short) are responsible for making
sure that two different systems don't try to use the
same Class D address at the same time.

The MBONE (or Multicast Backbone on the
Internet) is the range of Class D addresses beginning with 224.2.
that are used for audio and video broadcasts over the Internet. The
word MBONE is sometimes used less restrictively (and less accurately)
to mean the portion of the Internet that understands how to route
Class D addressed packets.

14.1.2 Clients and Servers

When a host wants to send data to a
multicast group, it puts that data in multicast datagrams, which are
nothing more than UDP datagrams addressed to a multicast group. Most
multicast data is audio or video or both. These sorts of data tend to
be relatively large and relatively robust against data loss. If a few
pixels or even a whole frame of video is lost in transit, the signal
isn't blurred beyond recognition. Therefore,
multicast data is sent via UDP, which, though unreliable, can be as
much as three times faster than data sent via connection-oriented
TCP. (If you think about it, multicast over TCP would be next to
impossible. TCP requires hosts to acknowledge that they have received
packets; handling acknowledgments in a multicast situation would be a
nightmare.) If you're developing a multicast
application that can't tolerate data loss,
it's your responsibility to determine whether data
was damaged in transit and how to handle missing data. For example,
if you are building a distributed cache system, you might simply
decide to leave any files that don't arrive intact
out of the cache.

Earlier, I said that from an application
programmer's standpoint, the primary difference
between multicasting and using regular
UDP sockets is that you have to worry about the
TTL
value. This is a single byte in the IP header that takes values from
to 255; it is interpreted roughly as the number of routers through
which a packet can pass before it is discarded. Each time the packet
passes through a router, its TTL field is decremented by at least
one; some routers may decrement the TTL by two or more. When the TTL
reaches zero, the packet is discarded. The TTL field was originally
designed to prevent routing loops by guaranteeing that all packets
would eventually be discarded; it prevents misconfigured routers from
sending packets back and forth to each other indefinitely. In IP
multicasting, the TTL limits the multicast geographically. For
example, a TTL value of 16 limits the packet to the local area,
generally one organization or perhaps an organization and its
immediate upstream and downstream neighbors. A TTL of 127, however,
sends the packet around the world. Intermediate values are also
possible. However, there is no precise way to map TTLs to
geographical distance. Generally, the farther away a site is, the
more routers a packet has to pass through before reaching it. Packets
with small TTL values won't travel as far as packets
with large TTL values. Table 14-2 provides some
rough estimates relating TTL values to geographical reach. Packets
addressed to a multicast group from 224.0.0.0 to 224.0.0.255 are
never forwarded beyond the local subnet, regardless of the TTL values
used.

Once the data has been stuffed into one or more datagrams, the
sending host launches the datagrams onto the Internet. This is just
like sending regular (unicast) UDP data. The sending host begins by
transmitting a multicast datagram to the local network. This packet
immediately reaches all members of the multicast group in the same
subnet. If the Time-To-Live field of the packet is greater than 1,
multicast routers on the local network forward the packet to other
networks that have members of the destination group. When the packet
arrives at one of the final destinations, the multicast router on the
foreign network transmits the packet to each host it serves that is a
member of the multicast group. If necessary, the multicast router
also retransmits the packet to the next routers in the paths between
the current router and all its eventual destinations.

When data arrives at a host in a
multicast group, the host receives it as it receives any other UDP
datagrameven though the packet's destination
address doesn't match the receiving host. The host
recognizes that the datagram is intended for it because it belongs to
the multicast group to which the datagram is addressed, much as most
of us accept mail addressed to
"Occupant," even though none of us
are named Mr. or Ms. Occupant. The receiving host must be listening
on the proper port, ready to process the datagram when it arrives.

14.1.3 Routers and Routing

Figure 14-3 shows one of the simplest
possible multicast configurations: a single server sending the same
data to four clients served by the same router. A
multicast socket sends one stream of data
over the Internet to the clients' router; the router
duplicates the stream and sends it to each of the clients. Without
multicast sockets, the server would have to send four separate but
identical streams of data to the router, which would route each
stream to a client. Using the same stream to send the same data to
multiple clients significantly reduces the bandwidth required on the
Internet backbone.

Of course, real-world routes can be much more complex, involving
multiple hierarchies of redundant routers. However, the goal of
multicast sockets is simple: no matter how complex the network, the
same data should never be sent more than once over any given network
segment. Fortunately, you don't need to worry about
routing issues. Just create a MulticastSocket,
have the socket join a multicast group, and stuff the address of the
multicast group in the DatagramPacket you want to
send. The routers and the MulticastSocket class
take care of the rest.

Figure 14-3. With and without multicast sockets

The biggest restriction on multicasting is the availability of
special multicast routers (mrouters). Mrouters are
reconfigured Internet routers or workstations that support the IP
multicast extensions. Many consumer-oriented ISPs quite deliberately
do not enable multicasting in their routers. In 2004, it is still
possible to find hosts between which no multicast route exists (i.e.,
there is no route between the hosts that travels exclusively over
mrouters).

To send and receive multicast data beyond the local subnet, you need
a multicast router. Check with your network administrator to see
whether your routers support multicasting. You can also try pinging
all-routers.mcast.net.
If any router responds, then your network is hooked up to a multicast
router:

% ping all-routers.mcast.net
all-routers.mcast.net is alive

This still may not allow you
to send to or receive from every multicast-capable host on the
Internet. For your packets to reach any given host, there must be a
path of multicast-capable routers between your host and the remote
host. Alternately, some sites may be connected by special multicast
tunnel software that transmits multicast data over unicast UDP that
all routers understand. If you have trouble getting the examples in
this chapter to produce the expected results, check with your local
network administrator or ISP to see whether multicasting is actually
supported by your routers.