4514 Project 3

You're super tired after a long day. Your professors have been even more brutal than normal with the homework, especially your Computer Networks prof. C'mon, can't he cut you some slack? You need to kick back and veg'. Unwind in front of a movie ... yeah, that's the ticket. Where, you ask? Why on the T-Bone, of course!

The MBone (short for Multicast Backbone) can be thought of as a way of broadcasting television and radio over the Internet. Technically, the MBone is a virtual overlay network on top of the Internet. It consists of multicast-capable islands connected by tunnels.

The movie process reads from a ".mov" file and sends the frames out on one multicast "channel." The five valid channels defined for this project are:

	  224.0.0.10
	  224.0.0.11
	  224.0.0.12
	  224.0.0.13
	  224.0.0.14

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

(name of movie)
(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
...

You can download the complete "walk.mov" file from the ~cs4514/proj3 directory.

Movie then multicasts the frames out on one channel, sending 1 frame per second. 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 an alarm(), sleep() or setitimer() system calls. The format for the frames is as follows:

(name of movie)
(frame sequence number)
(picture text)

The player receives frames via a multicast socket. The valid range of multicast addresses to listen are: 224.0.0.15 to 224.0.0.255 or any valid multicast address at a port other than 6000.

There may be several movies on a multicast channel at a time. Rather than displaying all the frame jumbled together, the player should be able to specify a specific movie to play. The name of the movie should be the first line in the frame.

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

The server receives multicasted frames and unicasts them to any interested clients. It is via the server that a movie multicasted on a "channel" is then sent to different island. The client ultimately multicasts the frame to the player.

The server has two duties:

• To accept() connections to other clients. This connection request should include the "channel" to be sent. Any valid port of your choosing can be used to accept connections.

• Upon receiving a multicast packet on any channel, the server should unicast it to any connected clients.

The server does not need to parse the frame at all, instead it merely forwards all packets on a channel to the clients.

The client connects via a TCP connection to the Server. The client should request a channel upon connection. Once connected, the client then receives packets on TCP socket and multicasts them on a UDP socket.

Note, a TCP socket may sometimes return less than a full frame of data. If you find this happening, you may want to have the Server and Client use a common structure to exchange information and use the MSG_WAITALL flag (see the man page for recv() for more information.

There may be a performance aspect of this project (such as measuring delay, lost packets and jitter). At this time, tho, it is unspecified. Pay attention to class announcements and this web page for updates!

Here are a few suggestions for development (not necessarily in any particular order):

1. Start early. Debugging client server code is sometimes difficult. Debugging client server code across separate hosts is even more difficult. This is not to scare you, rather it is to encourage you to start as soon as possible in case you get "stuck."

2. Work on each part separately.

3. Start with the sample code.

4. Get your player to receive from one of the pre-define channel addresses first before putting it on a different multicast address.

5. Start small.

The main information I'd like you to have from the documentation standard is; author, date, project id, language, OS dependencies, description and building information. All this information should appear in a README file that accompanies your program.

Here is a sample of the information you should have:

Author:                         Mark Claypool
Date:                           1/21/00
Project ID:                     Project 2
CS Class:                       CS4514
Programming Language:           C
OS/Hardware dependencies:       None

Problem Description:            This program implements blah, blah, blah

How to build the program:       make