Multimedia Computing Project 3

Mini RLM

Due date: April 16th by 11:59pm

(Note, the due date for all students is the same since this project does not require Linux machines.)

Kick back, relax and watch a flick from the comfort of your home. Made possible by the magic of receiver-driven layered multicast, some text-based video, your computer and, of course, some slick programming by you.


Receiver-Driven Layered Multicast

(This section contains a summary of the paper Receiver-driven Layered Multicast by Steven McCanne, Van Jacobsen and Martin Vetterli, in Proceedings of ACM SIGCOMM, Stanford, CA, August 1996.)

Normal IP communication on the Internet is between one sender and one receiver. However, for some applications it is useful for a process to be able to send to a large number of receivers simultaneously. Examples are updating replicated, distributed databases, transmitting stock quotes to multiple brokers and sending video for video-on-demand or teleconferencing.

IP supports multicasting wherein a best-effort attempt is made to deliver a multicast IP packet to all the members of the group addressed. Like in UDP, no guarantees are given as to the packet arrival and some members may not get the packet. Unlike other applications, video can allow some packet loss and still have acceptable quality, so it is a perfect candidate for IP multicast. So, the simplest solution is to distribute a uniform representation of the video to all interested receivers. This simple scheme is suboptimal - low capacity regions of the network suffer congestion while high-capacity regions are underutilized. In UC Berkeley, this theoretical problem was a very real one, as daily seminars transmitted over the campus network would go to LAN users with very high available bandwidth (10 Mbps), the Mbone (128 kbps) and ISDN lines (64 kbps). Figure 1 depicts the heterogeneous network topology at UC Berkeley.

Figure 1 - Network Heterogeneity

Rather than have the sender broadcast at some fixed rate without regard to changing network conditions, the transmission rate is adjusted to match available capacity in the network, ie - to respond to congestion. Adapting to the network capacity means the application must be mapped to the available data rate. With video, this can be done by layering the video signal such that a base layer provides a very coarse picture quality, and subsequent layers can be added, with each picture enhancing the video quality. This layering approach is depicted in Figure 2.

Figure 2 - Layered Video

Having layering video also presents the opportunity for each receiver to adapt the amount of data it receives to it's own bottleneck bandwidth. In a multicast session, the sender sends multiple copies of the same video simultaneously at different rates (resulting in different qualities), allowing the receiver to subscribe to only one group. Each receiver initially subscribes to the lowest layer (the worst quality, and least bandwidth). Each receiver then runs a simple control loop:

Moreover, the length that a receiver spends at each level is exponentially adjusted so that congestion caused by transient bursts in network traffic do not result in unnecessarily changing quality levels. An example of how RLM paths to the receiver is depicted in Figure 3.

Figure 3 - Some Sample Paths in RLM

This allows a receiver to find the optimal level of subscription wherein the maximum picture quality is received without causing network congestion.

Project Description

You are to write a suite of programs that gives you a taste RLM - video on the Internet using multicast and layering. Since we do not have a Wide-Area Network (WAN) here at WPI, our "routers" will all be on the same LAN, but will merely have different multicast addresses.

You are to write 3 separate programs:

Figure 4 depicts the relationship between Server, Router and Player.

Figure 4 - Mini RLM. The blue circle is the server process. It sends three video streams of different quality to three multicast addresses. Each router receives all three video streams. It then unicasts one of the video streams to one client.

The detailed specifications for each program follows this section.


The server process reads from a movie (.mov) file and sends different frames out on three different multicast "channels." The valid range of multicast addresses to listen are: to at any valid port.

for each channel use a separate IP address and unique port. For example:

Channel     IP             Port  
1   100 
2   101 
3   101 

Having the same port will cause any bind you do at the router to fail (note, you can get around this with a setsockopt call allowing binding to the same port but having different ports is easier).

The movie files are human-readable text, with a header, animation frames and a frame separator. The format of a movie file is (note, the parentheses () are not in the file):

(picture 1, arbitrarily long)
(picture 2, arbitrarily long)

For example, the start of the file is:

Taking a Walk
/ \
  / \

The server then multicasts the frames out on each channel as follows: Channel 1 has frames 1, 4, 7 ... Channel 2 has frames 2, 5, 8 ... Channel 3 has frames 3, 6, 9 ... The frame rate on each channel is 1 frame per second. Thus, the layering looks as follows (the numbers represent the frames, sent over time):

   Time -->>

   Channel 1:   1     4     7  

   Channel 2:     2     5     8

   Channel 3:       3     6     9

If the player has enough bandwidth to get channel 1 only, it receives:

   Channel 1:   1     4     7  ...

If it can get more bandwidth it will subscribe to channel 1 and channel 2, getting:

Channels 1-2:   1 2   4 5  7  8 ...

If it can receive all the frames, it will subscribe to all 3 channels and get:

Channels 1-3:   1 2 3 4 5 6 7 8 9 ...

Important!! You must delay for a second between frames. Sending frames as fast as you can will make the system administrators (and other users) very unhappy! You can achieve a 1 second delay by the alarm(), sleep(), usleep() or setitimer() system calls.

Feel free to be creative with the movies. Earlier creative creations include Star Wars, by Christopher Tashjian; Pong (the name says it all) by Dennis "spOOny" Mattoon and Jeff "killer" Cilley; and the Clerks Trailer by Glenn Barnett, Keith Berard, Darren Ranalli. (Note, these movies were created to be played at 1 frame per second. Starwars and Clerks in particular since they have text). If you stick to the movie format given above, others in the class can share your creations.


The router receives multicast video from the server and and unicasts it to a single player. Thus, a router and a player always work in pairs. A router should:

The router does not need to parse the frames at all, instead it merely forwards all packets of an indicated quality channel to the client.


The player "connects" to the router via a UDP socket. It then receives frames at a specific quality level, playing everything it receives on the screen until exiting.

The player employs the basic RLM protocol for quality ranges 1-3:


All routers, clients and the server should shut down gracefully.

There should be an easy way to test the RLM functionality by limiting bandwidth (artificially) at the router and percentage of random packets lost (as in project 2).

The samples section of the course web page has code that may make the assignment easier. Specifically, see multicast.c for an example of how to setup a multicast sender and receiver. See listen-udp.c and talk-udp.c for an example of setting up a udp client and server pair.

In order to clear the screen after each frame, you might use system("clear"). A more ambitious approach would be to try curses.


When you are done with your project, provide brief answers to the following questions:

  1. Spatial scaling is another way to scale video. Would spatial scaling be effective with text-based videos? Why or why not?

  2. Is RLM TCP-Friendly? Explain clearly why or why not.

  3. Briefly explain how you would layer voice-quality audio as used in project 1 and project 2.

Hand In

You must turn in:

Tar up (with gzip) your files, for example:

    mkdir login_name
    cp * login_name  /* copy all your files to submit to proj3 directory */
    tar -czf login_name.tgz login_name

then attach login_name.tgz to an email with "cs525_proj3" as the subject.

Return to the Multimedia Computing Home Page

Send all project questions to Mark Claypool.