21.7 TCP Implementation Differences

All the differences between UDP and TCP discussed in Section 20.8 factor into the implementation of Internet Radio. The main drawback of the UDP implementation is its unreliability. Messages can be lost or delivered out of order. While the problem of out-of-order receipt of messages can be solved simply by buffering at the receiver end, message loss is more difficult to handle with UDP. TCP handles this automatically.

The case of a single sender and a single receiver is simpler in TCP because TCP already ensures that information will be received in order. Sequence numbers are not needed. Since the receiver can send information to the audio device no faster than 8000 bytes/second on average, the receiver cannot read faster than this rate on average. Because TCP has flow control, the sender's network subsystem automatically forces the sender to slow down if it tries to send too quickly. The sender, therefore, does not have to sleep to limit the rate at which it sends, as in Section 21.3.1. Also, because of the connection-oriented nature of TCP, the sender can close the connection when finished, and the receiver can detect this. The issues discussed in Sections 21.3.2 “21.3.4 are all either irrelevant or are easily handled with TCP, though the receiver may still want to buffer the data to handle variation in network latency.

Multiple programs with a single receiver can be handled in a simple way, as in Section 21.4.2, with the server sending the list of programs to the receiver. However, because TCP provides byte streams rather than messages or datagrams, the receiver may not receive the entire list with a single read, even if the buffer is large enough and the sender sends the list with a single write. The information must contain a well-defined terminator, such as a blank line. The receiver must keep reading until it receives this terminator. Once the sender and receiver agree on an audio file to transmit, the implementation reduces to the single-program case.

With multiple receivers and multiple audio files, the transmissions can be considered independent and can be done by separate processes or threads.

Implementing the capacity to tune in while the transmission is in progress, as in Section 21.5, makes TCP more complicated to use, even with a single program and multiple receivers. With UDP, the sender just sends to all the receivers, one after another. This works because a problem with the network connection to a given receiver does not affect the sender's ability to send to other receivers. With TCP, if a server is sending audio to more than one host, network congestion or a busy receiver can cause write to block, delaying transmission to subsequent receivers. To handle this, use select , multiple processes, or multiple threads. In any of these cases, different receivers might be receiving at a temporarily different rate, and so the audio data must be buffered at the sender. Sender buffering is different from the buffering done by a receiver to account for network latency or out-of-order receipt. The following sections discuss these issues in more detail.

21.7.1 TCP implementation of one program and one receiver

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.

Exercise 21.38

How does TCPRecv behave under Test Case 1 and Test Case 2?

Answer:

If the receiver is suspended , the sender eventually blocks. No data is lost. If the receiver writes the data to a file, the file should be identical to the input audio file. If the network and the disk drive are faster than the audio device (a likely occurrence), transmission to a file completes much more rapidly than transmission to an audio device.

Exercise 21.39

What happens if the parent of TCPSend opens the audio file before forking any children?

Answer:

In this case, all children share the same file descriptor and have the same offset into the file for reading. The children would transmit mutually disjoint pieces of the audio file rather than each transmitting the complete file.

21.7.2 TCP implementation of multiple programs with one receiver

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.

Exercise 21.40

How can you test that TCPRecvProg correctly handles the initial message?

Answer:

Temporarily modify the sender so that it sends the initial message in two pieces with a sleep in between.

21.7.3 TCP implementation of radio broadcasts

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.

Exercise 21.41

What type of synchronization should TCPSendBcast use to protect its buffer?

Answer:

Since audio is time critical, writers should have priority. Each buffer slot should have reader/writer synchronization with strong writer preference .

Exercise 21.42

How can the individual readers keep track of which packets they have already accessed?

Answer:

It is not sufficient to just keep track of which slots have been accessed, since the writer writes new items over existing ones. Each buffer slot keeps the sequence number of the packet it currently holds. Each reader keeps track of the sequence number of the last packet it sent and blocks if the sequence number in the next buffer slot is not greater than this value. TCPSendBcast does not need to send the sequence numbers to remote receivers. TCP handles missing packets and out-of-order delivery on transmission, and the sender controls the rate of play.

Exercise 21.43

Which buffer entry should a new reader thread send when it starts?

Answer:

If the reader thread sends the item with the lowest sequence number, it may have some of the next buffers overwritten before it can access them. If the newly created reader thread starts eight items later, it is guaranteed that the writer will sleep for at least one second before overwriting any of the next buffers. Assuming a buffer size of at least 16, starting halfway through the buffers would be a reasonable choice.

Exercise 21.44

How should you modify TCPRecv to work with TCPSendBcast ?

Answer:

TCPRecv works without modification. Since sequence numbers are not attached to the data, the receiver does not care that it is receiving from the middle of the broadcast.

Exercise 21.45

What is wrong with the following scheme for having a reader thread of the sender protect the buffers?

1. Obtain a read lock for the slot buffer.

2. Copy the data from the appropriate buffer slot to the network.

3. Unlock the buffer slot.

Answer:

With TCP, writing to the network can block if the remote receiver is slow in processing the data. The reader's lock would prevent the writer from accessing the shared buffer.

Exercise 21.46

A correct method for the reader thread to access the shared buffer is as follows .

1. Obtain a read lock for the buffer slot.

2. Copy the data from the appropriate buffer into a local memory.

3. Unlock the buffer slot.

4. Write the data from the local memory to the network.

This implementation ensures that the buffers will only be locked for a short time and that a remote receiver cannot affect access to the buffer by the writer thread.

Exercise 21.47

Suppose each buffer slot holds 1000 bytes and that it takes 10 ns to copy a byte from one memory location to another. Estimate the maximum time that a reader would have the buffer locked for a single transfer.

Answer:

The nominal answer is 10 microseconds plus the time for locking and unlocking. However, since the thread may lose the CPU during the transfer, the actual time may be longer.

Exercise 21.48

How does TCPRecv behave under the four test conditions of Section 21.1?

Answer:

The maximum rate of output is independent of whether the result goes to a file or to the audio device since the rate is controlled by the sender. Suspending a receiver may cause the reader thread for this receiver to skip packets, but the suspension should not affect the other receivers if the synchronization at the sender is correct.