| 7.1 | Write a program that prints the default TCP, UDP, and SCTP send and receive buffer sizes and run it on the systems to which you have access. |
| 7.2 | Modify Figure 1.5 as follows: Before calling connect, call getsockopt to obtain the socket receive buffer size and MSS. Print both values. After connect returns success, fetch these same two socket options and print their values. Have the values changed? Why? Run the program connecting to a server on your local network and also run the program connecting to a server on a remote network. Does the MSS change? Why? You should also run the program on any different hosts to which you have access. |
| 7.3 | Start with our TCP server from Figures 5.2 and 5.3 and our TCP client from Figures 5.4 and 5.5. Modify the client main function to set the SO_LINGER socket option before calling exit, setting l_onoff to 1 and l_linger to 0. Start the server and then start the client. Type in a line or two at the client to verify the operation, and then terminate the client by entering your EOF character. What happens? After you terminate the client, run netstat on the client host and see if the socket goes through the TIME_WAIT state. |
| 7.4 | Assume two TCP clients start at about the same time. Both set the SO_REUSEADDR socket option and then call bind with the same local IP address and the same local port (say 1500). But, one client connects to 198.69.10.2 port 7000 and the second connects to 198.69.10.2 (same peer IP address) but port 8000. Describe the race condition that occurs. |
| 7.5 | Obtain the source code for the examples in this book (see the Preface) and compile the sock program (Section C.3). First, classify your host as (a) no multicast support, (b) multicast support but SO_REUSEPORT not provided, or (c) multicast support and SO_REUSEPORT provided. Try to start multiple instances of the sock program as a TCP server (-s command-line option) on the same port, binding the wildcard address, one of your host's interface addresses, and the loopback address. Do you need to specify the SO_REUSEADDR option (the -A command-line option)? Use netstat to see the listening sockets. |
| 7.6 | Continue the previous example, but start a UDP server (-u command-line option) and try to start two instances, both binding the same local IP address and port. If your implementation supports SO_REUSEPORT, try using it (-T command-line option). |
| 7.7 | Many versions of the ping program have a -d flag to enable the SO_DEBUG socket option. What does this do? |
| 7.8 | Continuing the example at the end of our discussion of the TCP_NODELAY socket option, assume that a client performs two writes: the first of 4 bytes and the second of 396 bytes. Also assume that the server's delayed ACK time is 100 ms, the RTT between the client and server is 100 ms, and the server's processing time for the client's request is 50 ms. Draw a timeline that shows the interaction of the Nagle algorithm with delayed ACKs. |
| 7.9 | Redo the previous exercise, assuming the TCP_NODELAY socket option is set. |
| 7.10 | Redo Exercises 7.8 assuming the process calls writev one time, for both the 4-byte buffer and the 396-byte buffer. |
| 7.11 | Read RFC 1122 [Braden 1989] to determine the recommended interval for delayed ACKs. |
| 7.12 | Where does our server in Figures 5.2 and 5.3 spend most of its time? Assume the server sets the SO_KEEPALIVE socket option, there is no data being exchanged across the connection, and the client host crashes and does not reboot. What happens? |
| 7.13 | Where does our client in Figures 5.4 and 5.5 spend most of its time? Assume the client sets the SO_KEEPALIVE socket option, there is no data being exchanged across the connection, and the server host crashes and does not reboot. What happens? |
| 7.14 | Where does our client in Figures 5.4 and 6.13 spend most of its time? Assume the client sets the SO_KEEPALIVE socket option, there is no data being exchanged across the connection, and the server host crashes and does not reboot. What happens? |
| 7.15 | Assume both a client and server set the SO_KEEPALIVE socket option. Connectivity is maintained between the two peers, but there is no application data exchanged across the connection. When the keep-alive timer expires every two hours, how many TCP segments are exchanged across the connection? |
| 7.16 | Almost all implementations define the constant SO_ACCEPTCONN in the <sys/socket.h> header, but we have not described this option. Read [Lanciani 1996] to find out why this option exists. |
