It's a standard rant, and it goes something like this: the Net is not a broadcast medium. It's not like TV, where a few big companies pump out content that millions passively consume. Instead, the Net lets everyone publish. It's for many-to-many communication, not one-to-many.
Which is true. Indeed, it's a philosophy inherent in the protocols and hardware that make up the Internet, designed with point-to-point communication in mind. However, as the Internet grows to support new services beyond email and file transfer, its antipathy to broadcast is starting to seem more like a bug than a feature.
Say, for example, that you run an Internet stock-quote service from New York and want to send complete, hourly price updates to your 300 customers in California. Today, you'd have to send 300 copies of the same message, each winging its way across the country. It would be far more efficient if you could send just one message to California and then have it split off in 300 directions.
The beginnings of such a system have been in place since 1992. Called the MBone - for multicast backbone - it's a sort of TV station for geeks, providing live broadcasts of technical conferences to tens of thousands of computers throughout the world. By means of a few simple algorithms, the MBone can efficiently broadcast video data to supporting sites while still using the standard Internet protocols for transporting the data.
When you send a message on the Internet, it is chopped into pieces - called packets - that are on average about 1,500 bytes long. A packet is like an envelope: inscribed with the addresses of the source and destination computer, it's responsible for safely carrying its piece of data. A packet travels over the network in a series of hops, going from computer to computer until it reaches its destination. If a computer in San Francisco sends a packet to New York, for example, the packet would first travel to Chicago, which would then look at the packet, see that it was destined for New York and forward it down the correct link.
Now imagine instead that SF wants to broadcast a message to all the other nodes on the network. Using standard Internet protocols, one message would travel from SF to LA, one from SF to Chicago, one from SF to Chicago to Dallas and one from SF to Chicago to New York. Those three trips from SF to Chicago are clearly redundant: it would work just as well to send the message to Chicago once, and then have Chicago forward the message to both Dallas and New York. That may not seem like a dramatic saving, but it quickly adds up.
Eliminating such redundant traversals is the goal of any multicast algorithm. One simple technique is to choose a spanning tree for the network - a set of links that connects every node in the network but doesn't contain any loops. In other words, a spanning tree should be able to carry a message from any node to every other node - but not back to itself. Once the spanning tree is chosen, a node forwards multicast messages along each of its links on the tree. The result is that every node receives the message with a minimum of network traffic.
This technique has a few shortcomings, however. First, you don't often want to broadcast to everybody on the network - just those who have chosen to tune in. Second, there needs to be some way for the nodes on the network to decide collaboratively on the spanning tree. Finally, using a single spanning tree concentrates all multicast traffic on just a few links. It would be much better to distribute the load evenly over all the links. The MBone solves these problems with its own protocols, including IGMP, DVMRP and RPF.
The first, the Internet group membership protocol, is a way for users to add and drop themselves from multicast groups. Think of a group as a channel. Each group is represented by one of the 250 million special multicast addresses, such as 224.1.1.1. When some-one wants to broadcast a message, he or she chooses a group address that isn't being used by anyone else. Then hosts that want to be members of the group send IGMP messages to their closest MBone routers asking to join.
These MBone routers, in turn, communicate with each other using the distance vector multicast routing protocol. This is an iterative algorithm that allows each node to build a "map" of the network. Using DVMRP, for example, each city would first announce its presence to its immediate neighbours. So SF would find out that it is neighboured by LA and Chicago. Then, in round two, each city would announce what it learned from the previous round to its neighbours. So NY would learn from Chicago that SF is two hops away. This process continues until each node knows the shortest path to every other node.
Finally, this information is used by a technique called reverse-path forwarding, which handles the actual transmission of multicast packets. The idea behind RPF is simple: when a packet is sent to a multicast address, the node checks whether the packet came in on the shortest path from the sender (which it knows from DVMRP). If so, the node sends it out on all of its other links. If the packet didn't come in on the shortest path, the node ignores it. The result is a near optimal series of messages that quickly reaches each node.
Unfortunately, while these protocols work, they probably won't scale to a network of millions of sites. Indeed, Christian Huitema, chair of the Internet Architecture Board, maintains that "the MBone was an experiment, and it should have remained an experiment." Better protocols have been developed, however, and as the Internet becomes increasingly clogged they will likely be implemented. Let's just hope that the Net can be made to support broadcasting without actually becoming a broadcast medium.
Steve Steinberg (steve@wired.com) is a section editor at Wired US.