Table Of ContentPreface
As new technologies are incorporated into the Internet infrastructure, the once impossible
will become possible. As an example, the World Wide Web (WWW) was once "just" used to
locate and retrieve documents. Now it is a media-rich environment for interacting in a global
online community. To support the as-yet unimagined applications of tomorrow, better, more
sophisticated technology is needed today.
One-to-many communication, called multicast, is one of the first services to improve
on the nearly ageless--in Internet years at least--Internet Protocol (IP). Instead of just best-
effort delivery of packets, multicast provides the ability to send one packet and have it reach
potentially millions of users. Multicast stands poised to revolutionize the kinds of applications
offered on the Internet. Without multicast, one-to-many applications like streaming Internet
radio, Video-on-Demand (VoD), Internet-based video jukeboxes, and videoconferencing are
almost impossible to provide.
In order for Internet users to have the opportunity to experience these new applications,
multicast needs to be incorporated into the infrastructure and into applications. Programmers
must know how to create sockets capable of delivering a single transmitted packet to poten-
tially millions of group members. Fortunately, multicast was designed in such a way that the
Application Programming Interface (API) is not significantly different from the unicast API. De-
tails of the actual mechanisms to accomplish one-to-many delivery are hidden in the network.
And because several books already focus on the intricacies of deploying multicast in a network,
this book focuses on approaching multicast from an application programmer's point of view.
Luckily, because of the power of network abstraction, an application programmer need
not know much about what happens in the network (though, what basic knowledge is useful
is covered in this book). Instead, the real challenge for an application programmer is to get
beyond the basics of multicast socket syntax and to understand the problems and solutions
of using multicast in applications. The differences between using unicast and using multicast
ix
X Preface (cid:12)9
are as significant as the differences between talking in a one-on-one meeting and effectively
lecturing to a room full of people. This book's goal is to create the multicast equivalent of
outstanding public speakers.
Intended Audience
Because multicast is a relatively new technology, this book is intended for anyone who is
interested in experimenting with multicast sockets and applications. As just mentioned, while
there are other books that focus on the network administration side of multicast, this book is
tailored toward the needs of application programmers.
In order to effectively use this book, you need to have sound programming skills, includ-
ing some basic knowledge of sockets. Most any language will do. In fact, this book presents
basic examples in three core languages: ,C Java, and C#. Additional, extended examples are
presented in one of these three languages. As the book's Web site evolves, we expect not only
to include new examples, but to offer them in all three languages.
Approach
This book attempts to balance a basic description of multicast and how it works with coding
examples that teach programmers how to write multicast sockets. As such, there is something
of an ideological conflict: present all the background material and then give code examples
versus using the code examples to drive the explanation. eW have settled on the latter.
Although Chapter 1 contains enough information to get started in writing multicast
sockets, it has barely an overview of the basics of multicast. Much of what a programmer needs
to know is therefore contained in Appendix .A Anyone interested in a better understanding of
how multicast works should read Appendix A before advancing too far into the book.
With Chapters 2 through 4, we jump directly into the code. All three chapters offer the
same basic multicast sender and receiver example but in three different languages. Again, the
choice we had to make was whether to present some key background concepts on multicast
or whether to jump right into the code. Again, full steam ahead on the coding examples! A
discussion on socket-related details with particular importance to multicast like the Time-To-
Live (TTL) field, group addressing, and multicast service models are left for later chapters.
Chapters 5 and 6 go back and give a more in-depth treatment of the role of TTL and
addressing in multicast. Also, Chapter 6 deals with variations on the basic multicast service
model. With the basic syntactical knowledge learned in Chapters 2 through 4, these concepts
make much better sense.
Chapters 7 and 8 introduce more advanced concepts in multicastmtopics that are cre-
ated only when one-to-many communication is used. Here, we adopt the strategy of giving
background on these topics (scalability, reachability, and reflectors) while offering code that
implements basic solutions to these problems.
xi
Acknowledgments
Chapter 9 is the whole of the book boiled down into a few key lessons to be remembered.
Essentially, it is a summary. It is one last chance to drive home some of the things a pro-
grammer will need to know in order to avoid the common mistakes made in multicast socket
programming.
What This Book Is Not
As much as this book is, it cannot be everything to everyone. Therefore, it is important to keep
in mind that this is an introductory text to multicast socket programming. As such, it does not
even attempt to be any of the following:
(cid:12)9 It is not a detailed description of multicast operation. No book that is this short can really
be detailed about anything. What happens on the other side of the socket interface is of
little concern for most application programmers.
(cid:12)9 It is not a reference manual. There is much about multicast programming that is not
included in this book. While this book is a good place to start, there are many advanced
concepts that are not covered (though, we do try to provide relevant references when
good ones exist).
It is not a troubleshooting guide. One of the challenges with multicast is using it in a
(cid:12)9
network environment that does not have robust support for multicast. This means either
that some parts of the network do not support it at all, or that what does exist is somewhat
unstable. Although we wish we could offer troubleshooting tips, the problem is beyond
the scope of this, and quite possibly, any book. Anyone interested should look online for
help.
Acknowledgments
Writing any book requires the efforts of many people. From the outline to the book you
are holding in your hands, a range of people have been involved in offering directions and
corrections.
On the technical side, we received a tremendous amount of constructive criticism on how
to improve the book's organization, the flow of chapters, and especially the correctness of the
code. The technical group includes Jeff Donahoo, Baylor University; Lucy Lynch, University
of Oregon; and Chris Pond, Team345. Perry Stoll from Akamai Technologies reviewed and
provided significant feedback on the code examples. Other draft reviewers who provided input
from Akamai Technologies included Tom O'Hare and Charisma Schlossberg.
Before we got to the point of needing technical review, we had to get the concept off
the ground. Thanks to Jeff Donahoo, serving in his role as the series editor, for entertaining
our proposal and getting it approved. We felt it was quite a coup to have this book added to
this series (see www.mkp.com/practical/for others). Also, many of the technical people were
involved earlier in reviewing and providing suggestions for improving our initial outline. These
xii
Preface (cid:12)9
include Lucy Lynch (again); Bob Quinn; Erick Wagner, Lee EDS; Cottrell, Bradford School; Deb
Agarwal, Lawrence Berkeley Labs; and Marshall Eubanks, Multicast Technologies, Inc.
And finally, on the production side, many thanks have been earned by the Morgan
Kaufmann folks. Led by our editor, Karyn Johnson, there is a whole host of folks who put
the finishing touches on our manuscript and then got it out the door.
Feedback
As any programmer knows, writing code is never done right the first time. Neither is writing a
book, especially one about writing code. In some cases, we made a deliberate trade-
off on the robustness and utility of the code in favor of brevity and clarity. Therefore,
we invite any suggestions or corrections on how to make this book better. Feedback
can be submitted via the book's Web site at ro/tsacitlum/lacitcarp/moc.pkm.www
directly to us via email.
David .B Makofske: [email protected]
Kevin .C Almeroth: [email protected]
~rom the birth of the Internet, the network has had significant advances in technology,
rich new applications, and the evolution of networking protocols. From a network of just a few
nodes, the Internet has evolved into an infrastructure critical to the world economy.
Even though there has been tremendous change, very little of it has been exposed to
the application programmer. In a~sense, this is a good thing. No matter how the network
changes, delivery of packets is still accomplished. This is due in part to the power of network
sockets. This abstract interface between application programmers and the network has been
successful in protecting programmers from the details and underlying complexities of the
network. Through layering and abstraction, application programmers have been able to send
data across the network without worrying about the details of actual delivery of data across
the various network hops. It is only through different types of sockets that different services
are made available to a programmer.
Through transport layer protocols like the Transmission Control Protocol (TCP) and the
User Datagram Protocol (UDP), different delivery services are available. UDP is very simple
and only provides a programmer with port numbers. Port numbers provide multiplexing
and demultiplexing; that is, ports allow different applications to keep their packets separate
even though they use the same underlying delivery infrastructure. TCP is a more feature-rich
protocol than UDP. TCP not only provides multiplexing and demultiplexing but also provides
connection management, in-order delivery of packets, reliability, and congestion control. TCP is
useful for applications like the Web and email, which fundamentally work by reliably delivering
objects or files. UDP is more often used for more delay-sensitive but often more loss-tolerant
applications (e.g., streaming audio and video).
And yet, even with TCP and UDP, there is still a need for more advanced functionality
inside the network. Without advances at the network layer, neither TCP nor UDP can provide
efficient, highly scalable packet delivery to a large group of users. What is needed is the ability
for an application to deliver one copy of a packet to a socket, and then have the host and the
network efficiently deliver that packet to all interested receivers. What is needed is multicast.
2 Chapter :1 Introduction
1.1 Multicast Defined
Multicast communication gives the application programmer the ability to open a UDP socket
and send a packetized chunk of data once. And yet the packet is delivered to potentially many
receivers. Instead of sending N separate but identical packets to each of N receivers, one
multicast packet can be sent that will reach all N receivers, even if N is large.
A special range of PI addresses is used to create a logical group of receivers. Using this
address, the application programmer has the ability to send one or a stream of packets to this
destination address and expect the network to attempt to deliver a copy of the packet to each
receiver in the multicast group.
Multicast communication relies on additional functionality in the network to build a
"multicast forwarding tree" between the sending application and the group of receivers. The
concept of a tree is an accurate one. The source is located at the "root" of the tree. From the
root, a packet stream flows up the trunk to "branches." At each branch in the tree, the network
receives an incoming packet and copies it to each of the outgoing branches. For an example of
a multicast tree, see Figure 1.1.
The functionality necessary to build and maintain multicast trees for a group of receivers
is slowly being deployed throughout the Internet. Deployment means that additional function-
ality, using additional software and/or hardware, is being deployed in Internet switches and
routers as well as in host operating systems and applications. Deployment also means that
there are programmers who are using multicast as an effective technique in building large-scale
distributed applications. For an application programmer, using multicast means understand-
ing the syntactic changes to the socket Application Programming Interface (API) as well as
understanding the implications of using such a powerful communication mechanism.
1.2 Unicast vs. Multicast vs. Broadcast
As a former colleague once stated, "terminology is 85% of the game." This is especially true
when learning a new technology. Even though multicast has been around for a number of
years, many people are unfamiliar with what it is. Therefore, it is important to define what
multicast is.
The terms unicast and multicast make the most sense when also considering the more
common term broadcast. Where broadcast means to send to everyone, for example, radio,
television, satellite, and so on, the other two terms cover a more restrained set of receivers.
Unicast is the opposite of broadcast and means that a transmission is sent to only one user,
hence "uni-" (one) combined with "-cast" (to send). Multicast is therefore the transmission to
"multi-", that is, more than one but not everyone.
In the radio or television world, a broadcast does not truly go to everyone. In most
broadcasts, each station has a "footprint" in which its signal can be received. This footprint
is considered the entire network, and so every user has the potential to receive this signal.
Television uses a combination of satellites, relays, cable plants, and so on to create a broadcast
network. Traditional broadcast networks are designed to efficiently deliver a signal to everyone.
While they can also technically deliver a unicast transmissionmby sending a broadcast signal
