Copy Program 20.2, (client_udp.c) on page 699 into UDPRecv.c and compile it as UDPRecv. UDPRecv sends a message to a server and reads a response. Modify UDPRecv to receive messages of at most 1000 bytes after sending the initial message. The program should take an optional third command-line argument, the name of a file. If called with three command-line arguments, UDPRecv writes the received information to the specified file. Otherwise, UDPRecv writes the received information to /dev/audio.

Copy Program 20.1 (server_udp) on page 698 into UDPSend.c and compile it as UDPSend. Modify UDPSend to take two command-line arguments: a port number and a file name. The UDPSend listens on the specified port for client requests. When UDPSend receives a request (any message), it opens the file and copies the file contents to the requesting host in 1000-byte messages. Since the Internet Radio application sends 8000 byte/second audio, UDPSend should sleep for one second after sending each eight messages. After sending the entire file, UDPSend waits for another request. For each of these programs remember to change the value of BUFSIZE from 1024 to 1000.

UDPSend 16001 myaudio.au

UDPRecv os1.cs.utsa.edu 16001

Connectionless communication protocols such as UDP do not indicate when the transmission is complete, so the receiver does not know when to terminate. There are several ways to handle the termination problem.

The sender can transmit a special message reporting that it has sent all of the data. The special message must be distinguishable from audio data. Since in most audio formats, any data is possible, the special message might be embedded in the audio data.

Alternatively, the receiver can use the timeout capability of UICI. If it receives no data in a certain length of time, say, 5 seconds, the receiver assumes that the transmission has ended and terminates. Receivers using this approach could terminate prematurely unless they use a very large timeout value.

Another method relies on the atomic nature of UDP messages—a UDP message is either received in its entirety or is not received at all. The receiver assumes that all messages except the last one are exactly 1000 bytes. If the size of the file is not a multiple of 1000 bytes, the last message has fewer than 1000 bytes and the receiver knows that this is the last message. If the file is a multiple of 1000 bytes, the sender transmits a message of length 0 after the last message.

Copy UDPSend.c into UDPSendEnd.c, and copy UDPRecv.c into UDPRecvEnd.c. Modify these programs to transmit a zero-length message to signify the end of the transmission.

One of the problems with streaming audio (or video) is that the transmission time may not be constant. Periods of heavy network traffic cause messages to be delayed or lost. For now we assume that the messages are received in order and never lost, but there may be short periods (equivalent to the time to play a few messages) in which no messages are received. The receiver can compensate for this uneven transmission by allocating buffers and filling many of the buffers before starting to play the first message. The receiver must fill the buffers from incoming network messages concurrently with the emptying and playing of the buffers.

The receiver buffer problem is a standard producer-consumer problem involving two file descriptors that must be monitored concurrently. We discuss three possible solutions to this problem—select, multiple threads and parent-child processes.

In the first solution, the receiver calls select to determine which file descriptor is ready. The receiver has one descriptor for reading and one for writing in contrast to Program 4.12, which monitors two file descriptors for reading.

Copy UDPRecvEnd.c into UDPRecvSelect.c and compile it as UDPRecvSelect. Modify the program to call select to monitor the two file descriptors. Preallocate NUMBUF buffers. Use a value of NUMBUF that corresponds to about 10 seconds of audio, and do not start sending anything to the audio device until at least half the process buffers are filled.

Since only a single process accesses the process buffers, the receiver does not have a critical section in the select implementation. However, the programming is still tricky, since the program can be in one of three states: only reading from the network (initially and when the buffers are empty), only writing to the audio device (when the buffers are full), and using select.

The threaded solution uses a producer thread responsible for reading from the network and a consumer thread responsible for outputting to the audio device. Each thread just blocks when its input or output is not ready. Use Program 16.14 and Program 16.11 as models for your solution. Take care that the producer thread does not obtain exclusive access to the buffer before blocking for network input. Similarly, the consumer thread should not hold exclusive access to the buffer before waiting for audio output to return from its previous write. Copy UDPRecvEnd.c into UDPRecvThread.c and compile it as UDPRecvThread. Modify UDPRecvThread so that it implements the threaded solution.

A third solution uses a child process to output to the audio device while the parent reads from the network. The process buffers can be implemented with shared memory, as described in Section 15.3. As in the threaded implementation, the critical sections that access the shared buffer must be protected. Copy UDPRecvEnd.c into UDPRecvShared.c and compile it as UDPRecvShared. Modify UDPRecvShared so that it implements the parent-child solution. The child process terminates when it has finished reading from the network. The parent terminates when the process buffers are empty and the child has terminated.

The UDP protocol does not force in-order delivery of packets. Out-of-order packets are seldom observed on a LAN in which there is only one path between sender and receiver, but UDP packets are often delivered out of order on the Internet.

The usual way to handle out-of-order transmission is with sequence numbers. Each message starts with a header containing a sequence number that is incremented by the sender for each message sent. For this part of the project, we assume that a 32-bit sequence number is sufficient.

#define BUFSIZE 1000
char buf[BUFSIZE+4];
uint32_t seq;

r_read(filefd, buf+4, BUFSIZE);
*(uint32_t *)buf = htonl(seq++);
u_sendtohost(sendfd, buf, BUFSIZE+4, hostn, port);

uint32_t seqn;
seqn = htonl(seq++);
memcpy(buf, &seqn, 4);

Copy UDPSendEnd.c into UDPSendSeq.c and compile it as UDPSendSeq. Modify UDPSendSeq to send 1004-byte messages with sequence numbers. Copy one of your implementations from Section 21.3.3 into UDPRecvSeq and compile it as UDPRecvSeq. Modify UDPRecvSeq to handle out-of-order delivery of messages. Test these together.

Testing the out-of-order receiver on a LAN is difficult since programs rarely receive out-of-order UDP messages. To test receiver handling of out-of-order messages usually requires that the messages actually be sent out of order. Copy UDPSendSeq.c into UDPSendSeqTest.c and compile it as UDPSendSeqTest.

Modify UDPSendSeqTest to occasionally delay a message for 1, 2 or 3 messages. Use a separate buffer for a delayed message and an integer counter specifying how long to delay. You should also pick a threshold value between 0 and 1. If the threshold is 0, the sender transmits packets in order. For thresholds greater than 0, the sender transmits a greater fraction of the packets out of order. The sender sets the counter to 0 when it starts and checks the counter each time it is ready to send a message. A nonzero counter indicates that a delayed message exists. If the counter is greater than 1, the sender decrements it and sends the current message. If the counter is equal to 1, the sender decrements it and sends the current message followed by the delayed message in the buffer. If the counter is 0, the sender picks a pseudorandom number between 0 and 1. If the value is not below the threshold, the sender transmits the current message. If the value is less than the threshold, the sender places the message in the buffer and sets the counter to 1, 2 or 3 (at random).

Copy UDPSendSeq.c into UDPSendProg.c and compile it as UDPSendProg. Modify UDPSendProg to interpret the filename command-line argument as a program listing of available audio files. Each line of the program listing has the name of an audio file and a description. When the sender receives a request message consisting of a 0 byte, the sender transmits the contents of the program listing file to the receiver as a single message. (Assume that the listing file is small enough to be sent as a single UDP message.) When the sender receives a message containing a single nonzero integer in network byte order, the sender begins to transmit the audio file identified by that integer. A value of 1 represents the first file in the program listing. Any value out of range causes the sender to ignore the request message and resume listening for another request.

Copy UDPRecvSeq.c into UDPRecvProg.c and compile it as UDPRecvProg. UDPRecvProg begins by sending a single 0 byte to the sender and reading the program listing. UDPRecvProg presents the listing to the user and prompts for the user’s selection. UDPRecvProg then sends the request number to the sender and plays the audio file as before.

Copy UDPSendProg.c into UDPSendMult.c and compile it as UDPSendMult. Modify the program to work with multiple copies of the receiver. This modification is similar to changing a serial server into a parallel server.

Copy serverp.c from Program 18.2 on page 623 to TCPSend.c and compile it as TCPSend. Modify TCPSend to take a second command-line argument, the name of an audio file. After the sender accepts a network connection, it forks a child that opens the audio file and transmits its contents to the remote host. Since the child transmits the file and the parent resumes waiting for another request, TCPSend can handle multiple receiver requests for the same file. Note that the original program transfers data from the network to standard output, whereas this program transfers information from a file to the network.

Copy client.c from Program 18.3 on page 624 into TCPRecv.c and compile it as TCPRecv. Modify TCPRecv to take an optional third command-line argument. When called with two command-line arguments, TCPRecv copies data from the network to the audio device. When called with three command-line arguments, TCPRecv copies data from the network to the file named by the third argument. Open the output file as in Exercise 21.2.

TCPSend and TCPRecv can be used together to transfer audio from the sender machine to the receiver machine.

Copy TCPSend.c into TCPSendProg.c and compile it as TCPSendProg. Modify TCPSendProg to send multiple audio files. Now, as in UDPSendProg, the file command-line argument specifies the name of a file containing the program listing. Each line of the program listing has the name of an audio file and a description of the file. When the sender accepts a connection from the receiver, it sends the program listing to the receiver, followed by an empty line. The sender waits for another message from the receiver containing the number of the audio file in network byte order. The value 1 represents the first file. Any value out of range causes the sender to close the connection.

Copy TCPRecv.c into TCPRecvProg.c and compile it as TCPRecevProg. Modify TCPRecvProg to be used with TCPSendProg. After reading the list of audio files from the sender, TCPRecvProg presents the information to the user as a numbered list and prompts the user to make a selection by entering a number. TCPRecvProg sends the user’s selection to the sender and plays the audio file as before. The sender terminates its initial message by an empty line. Do not assume that the receiver can receive the entire list with a single read.

With TCP and a single receiver per process, the sender can rely on TCP flow control to regulate the rate at which it sends data. A receiver that malfunctions and cannot read from the network does not delay the other receivers. Similarly, a receiver that just throws away data rather than writing to the audio device can still receive data at the rate of the network, which may be much faster than the audio devices of other receivers. In this case, too, the faulty receiver does not affect the other receivers because the sending to different receivers is independent.

When broadcasts can be joined in progress, only one process or thread is reading from the audio file and the data must be sent to all receivers. Different receivers may be able to handle the data at slightly different rates, at least over short time intervals. The sender can handle the uneven rates by using a shared buffer that contains blocks of the file. In a threaded implementation, the sender’s writer fills the buffer at the rate of the audio device and the various reader threads access the buffer to transmit audio. If a reader thread reads too quickly, it must wait for the buffer to be filled. If a reader thread reads too slowly, then buffer slots are overwritten before being read by that reader thread.

Copy TCPSend.c into TCPSendBcast.c and compile it as TCPSendBcast. Modify TCPSendBcast to use multiple threads. The main thread starts by creating a writer thread to handle the filling of the buffer. The main thread is responsible for accepting connections. For each connection, the main thread creates a reader thread that is responsible for sending the data from the buffer to a particular remote host. The writer fills the buffer at a rate corresponding to the audio device. Use a timer that generates a signal at a given rate compensated for timer drift (Section 9.6). The simplest implementation has all threads blocking the signal while the writer uses sigwait to wait for the particular signal. No signal handler is necessary for this implementation. If no buffer slots are available, the writer writes over the oldest buffer slot.

Reader threads do not remove items from the buffer since each reader should be able to read all of the data. Each reader thread attempts to send data as fast as possible, blocking only on the write to the network and after it has accessed all items currently in the buffer.

You may have noticed that when you click on certain links, the corresponding file does not appear in your browser window, but rather the browser launches a separate program, called a helper application, to handle the data sent by the server. For example, if you have a Real Audio Player installed on your machine and have set your browser to use this application, clicking on a link for a file with extension ram causes the browser to store the corresponding file as a temporary file on the local machine. The browser then launches the Real Audio Player application, passing the temporary file name to the application as a command-line argument. The file contains the information the Real Audio Player needs to locate the audio program.

Browsers use one of two methods to identify the type of resource being sent and the application that should handle this resource. Some browsers use the file extension to determine the type of resource; others rely on a Content-Type header line in the server response. Browsers that use file extensions store the correspondence between resource types and filename extensions in a file, typically named mime.types. The word MIME is an acronym for Multipurpose Internet Mail Extensions and was originally intended for mail attachments. Applications now interpret mime types more generally to associate an application type with a file extension. Web server responses often include a header line that describes the type of resource being sent.

Content-Type: text/html

Content-Type: audio/x-pn-realaudio

When classifying resources on the basis of file extensions, the browser looks for an entry in its mime.types file corresponding to the ram extension such as the following.

audio/x-pn-realaudio   ram rm

The preceding command specifies that both the ram and rm extensions should be associated with audio applications of type x-pn-realaudio.

Start with one of your receiver programs, say, TCPRecv.c from Section 21.7.1 and copy it into TCPRecvMime.c. Modify TCPRecvMime to take one command-line argument, the name of a file containing the host name and port number of the sender.

scanf("%s %d", hostname, &port);

scanf("%79s %d", hostname, &port);

Test TCPRecvMime with TCPSend by creating a file containing the host and port number. Setting TCPRecvMime to be launched through a browser requires the following three steps that are described in the subsections below.

Setting up your web server to handle a new mime type requires that you have administrative access to the web server. If you do not have administrative access, ask your system administrator to do this step for you. Alternatively, you can use one of the mime types already set up for your browser. We discuss this option in Section 21.8.5.

Depending on your web server, you can set a new server mime type by modifying a file of mime types or by modifying the configuration file. For example, if your web server configuration directory has a file with a name similar to mime.types, add the following line to this file.

application/uspir      uspir

The preceding line allows the web server to associate an application type called application/uspir with the file extension .uspir. Alternatively, you might be able to just add the following line to the web server configuration file, possibly a file called httpd.conf.

AddType application/uspir      uspir

You must restart the web server after changing this file.

You can use the client2 program from Program 18.5 on page 629 to verify that your web server is set correctly for this mime type. Create a small file called test.uspir in a directory accessible to the web server. If the web server is running on host webhost and this file is in the directory mydir relative to the web root directory, start client2 with the following command.

client2 webhost 80

Type the following line terminated by an empty line.

GET /mydir/test.uspir HTTP/1.0

You should see the file after a few header lines. A correct response should have a header line similar to the following.

Content-Type: application/uspir

The method for setting a new mime type for a browser depends on which browser you are using. For Netscape 6 or 7, go to Edit → Preferences → Navigator → Helper Applications. Click on New Type and fill in the information requested. The Description can be any phrase. The File extension should be uspir and the MIME type should be application/uspir. For the application, put the full pathname for your TCPRecvMime program.

Create a file with extension .uspir containing the host name and port number of your TCPSend program. The values should specify a server that is distinct from the web server. Make the file accessible to your web server and create a web link to the file. Start TCPSend. When you click on the link, you should start hearing the audio program.

If you cannot add a new mime type to your web server, you can use one of the predefined types that your browser is not using or does not use often. Some suggested extensions to try are ez, hqx, cpt, oda, smi and mif. You can test these by creating a file with the appropriate extension in a place accessible to your web server and issuing the appropriate GET command from client2. You should get back a Content-Type line giving the corresponding application type.

Set your browser to call your TCPRecvMime program for this application type. Follow the procedure in Section 21.8.3. If the application type is already defined for your web browser, click EDIT and modify the values.