| Figure 1 - Network Heterogeneity |
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.
(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.
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:
Server - reads in a movie file and multicasts it frame by frame on a three multicast channels, each channel representing a different quality level.
Router - receives multicasted frames from the server and unicasts them to a player.
Player - receives unicasted frames from the router and displays them on the screen.
| 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: 239.0.0.1 to 239.255.255.255 at any valid
port.
for each channel use a separate IP address and unique port. For example:
Channel IP Port 1 239.xxx.xxx.1 100 2 239.xxx.xxx.2 101 3 239.xxx.xxx.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) end (picture 2, arbitrarily long) ... stop
For example, the start of the walk.mov file is:
Taking a Walk o | | end o | / \ end o | | end o | / \ end ...
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:
Receive all multicast frames on all channels from the server.
Send via unicast (UDP) frames of a specified quality level to the player.
Accept changes in quality level, up or down, from the player.
Allow configuration from the user (say, as a command line parameter) of available bandwidth and rates for random packet loss (like project 2) so that RLM (subscribing/unsubscribing to channels) in the players may be tested. In a typical router, the loss rate is often a function of the incoming rate. In other words, if the player asks for level 1 the loss rate may be 0%. At level 2, the loss rate may be 3% and at level 3 it may be 15%. Thus, you should allow your loss specification for your router to be done at each level. You can do this instead of having a bandwidth configuration between your player and router.
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:
Upon detection of a lost packet, the player assumes congestion and reduces the quality level.
After waiting for some time, if no more loss is detected the player will increase the quality level.
The amount of time at each level should be adjusted so that the optimal operating level is found despite transient bursts in network loss (See Figure 3 above). Experiment with appropriate parameters to do this.
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:
Spatial scaling is another way to scale video. Would spatial scaling be effective with text-based videos? Why or why not?
Is RLM TCP-Friendly? Explain clearly why or why not.
Briefly explain how you would layer voice-quality audio as used in project 1 and project 2.
You must turn in:
login_name1 last_name1, first_name1
login_name2 last_name2, first_name2
...
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.