CS 43 Lab 4: Designing a Jukebox Protocol

Due: Thursday, November 2, 11:59 PM

Due: Monday, November 6, 11:59 PM


Handy references:


Lab Audio, day 1
Lab Audio, day 2

For this lab, you'll be designing and implementing a protocol of your own design to build a networked Jukebox. Since the protocol is your own, you'll be developing both a client and a server. Thus far, you've seen and implemented several types of protocols -- now you get to decide how to apply the patterns you've seen to a new scenario.

Note: You do NOT want to split this up such that one person is responsible for the client and the other the server. The server will be much larger than the client (387 vs 113 lines in my solution*), and you'll need to know the details of both when debugging.

* I didn't optimize my solution for size, but feel free to try making yours shorter. For this lab, smaller solutions tend to correlate with those that work better, typically as a result of cleaner / more thought out design.

Requirements

  1. You must use C to implement your server, and it must use select() (rather than threading) to provide concurrency. You may use any language you wish for the client, and you may use threads in the client. I strongly recommend Python for the client, as it makes playing audio much simpler.

  2. After it starts up and begins serving clients, your server should never block on any call other than select(). Blocking on a send(), recv(), or accept() is a bug!

  3. Your client should be interactive and it should know how to handle at least the following commands:
    • list: Retrieve a list of songs that are available on the server, along with their ID numbers.
    • info [song number]: Retrieve information from the server about the song with the specified ID number.
    • play [song number]: Begin playing the song with the specified ID number. If another song is already playing, the client should switch immediately to the new one.
    • stop: Stops playing the current song, if there is one playing.

  4. The client should not cache data. In other words, if the user tells the client to get info for a song, get a song list, or play a song, the two should exchange messages to facilitate this. Don't retrieve an item from the server once and then repeat it back again on subsequent requests. To simplify the file IO, it's fine for the server to keep its data, including the audio files, in memory, but the client should not store data that it isn't actively using.

  5. One of the parameters to your server should be a path to a directory that contains audio files and their corresponding information. Within this directory, you may assume that any file ending in ".mp3" is an mp3 audio file. For each mp3 file, there may be a corresponding information file that is identical to the file name with ".info" tacked on to the end. For example, if there were a file in the directory named "song1.mp3", there may also be a file named "song1.mp3.info" containing human-readable plain text information about that song. This info file is what should be supplied when the client issues an info command. I've made my music directory available at /home/kwebb/music, and I've provided code to read the names of these files. Feel free to use that or your own mp3 files for testing. Please do not submit audio files to GitHub!

  6. I would like to have a brief (~10 minutes) protocol specification and progress meeting with each group on or before October 27th. I'll post a sign up sheet on my door. For this meeting, you should come prepared to discuss the details of your protocol and the per-client state you intend to keep at the server. I would strongly suggest that your server be capable of accepting connections by this point, so that we can also discuss next steps.

  7. For grading, I'll similarly meet briefly with each group for a demo. We'll handle the logistics of signing up for that when it gets closer to that time. You must still submit your code prior to the midnight deadline.

Grading Rubric

This assignment is worth six points.

Tips / FAQ

If you have any questions about the lab requirements or specification, please post on Piazza.

Submitting

Please remove any debugging output prior to submitting.

Please do not submit audio files to GitHub!

To submit your code, simply commit your changes locally using git add and git commit. Then run git push while in your lab directory.