CS43 Lab 4: Designing a Jukebox Protocol

Design and implement your own application-layer client-server Jukebox protocol.

Develop both the client and server protocol communication formats.

Develop a persistent server to connect with multiple interactive clients using event-based concurrency.

Write a client that uses producer-consumer threading model to receive song data, and play song data.

A specification for your protocol, including header formats, field sizes, and anything else someone might need to know to implement your protocol.

A list of the states (or actions) you intend to perform as the server and what each state represents.

These documents don’t have to be super long or formatted like RFCs, but they should provide enough detail for you to refer to as you work on your implementation. They also aren’t set in stone — you may have to change the design slightly as you encounter implementation challenges, but my expectation is that that they won’t change too drastically.

Be able to accept clients at the server.

Be able to exchange text (list and info) requests and replies between multiple concurrent clients and the server.

Be able to exchange music with one client, initially, and then multiple clients.

Be able to interleave music and text inputs.

Server side:

Client side:

using text vs. binary formats: CRLFs (or some other delimiter) vs. fixed-sized fields

header information (what information should the client-server exchange to ensure correctness?

header delimiters, format and size of each field

client-state maintained by the server, to handle persistent connections

You must use C to implement your server, and it must use select() (rather than threading) to support multiple concurrent clients.

To simplify the file I/O, 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.

Your server will receive two command line arguments: a port number on which to listen for incoming connections and the name of a directory with music files. For example:

a single thread for all client requests.

we will use select() for event-based concurrency. Using select() the program is only notified when there is space in the socket buffers to send/receive across the list of available clients.

To pack or unpack a single byte you can just index into the array using data[idx].

To pack or unpack more than one byte the byte-ordering functions are as follows. Look up their man pages for more info.

htons() - convert a short (2-byte int) from host byte order to network byte order

ntohs() - convert a short (2-byte int) from network byte order to host byte order

htonl() - convert a long (4-byte int) from host byte order to network byte order

ntohl() - convert a long (4-byte int) from network byte order to host byte order

For example, if you know that you have a short contained in positions 3 and 4 of a character array, you can call ntohs() on it as:

short result = ntohs(*((short *) &buf[3]));

Use send() and recv() in as few places as possible. Never call either one on a socket unless select has told you that it’s safe to do so, otherwise, you’ll block (and potentially deadlock!).

Set your sockets to non-blocking mode for debugging: You can do this by calling set_non_blocking(int sock) in your starter code. This is not required (you should never block regardless because you should never try to send, recv, or accept unless select tells you it’s ok), but it will prevent deadlocking during your testing. Check their return values and errno for EAGAIN/EWOULDBLOCK, which indicate that you made a syscall that you shouldn’t have. That’s send/recv/accept 's way of telling you "I would have blocked on this call had this socket not been set for non-blocking mode."

Client closes a connection just before your server sends data: In this case, by default, two things will happen:

Luckily, we can easily prevent the SIGPIPE signal by using the extra flags parameter in send that we’ve been ignoring thus far. By setting the flags to MSG_NOSIGNAL, the kernel will only do (2), which is a much more convenient way for you to detect and handle a client disconnection.

To simplify the file I/O, 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.

You may assume that the client has infinite buffering capacity for song data. That is, unlike "real" streaming protocols, you don’t have to keep track of how much data the client has processed before sending them more data. Once you start sending song data, just keep sending more until you reach the end (unless the client requests something else in the meantime).

One of the parameters to your server is a path to a directory that contains audio files and their corresponding information.

What happens when a user enters stop at a client? If it immediately stops playing any music data it has buffered, what should happen if new data continues to arrive afterward?

Does your protocol allow for interleaving of messages? For example, if the user asks to play a large song file and then enters list while the file is still transferring, how does your protocol reply with the list response without the user needing to wait for the entire file transfer to complete?

When keeping track of the state of a client at the server, account for the case when you call send and fewer than len bytes were sent (that is, the return value of send indicated that some, but not all of the bytes got sent). The next time you send to the same client, you need to resume sending the old message where you left off rather than generating a new one. What sort of variables do you need to keep track of this case?