Exercises

18.1	In Section 18.2 we said that the initial sequence number (ISN) normally starts at 1 and is incremented by 64,000 every half-second and every time an active open is performed. This would imply that the low-order three digits of the ISN would always be 001. But in Figure 18.3 these low-order three digits are 521 in each direction. What's going on?
18.2	In Figure 18.15 we typed 12 characters and saw 13 bytes sent by TCP. In Figure 18.16 we typed eight characters but TCP sent 10 bytes. Why was 1 byte added in the first case, but 2 bytes in the second case?
18.3	What's the difference between a half-open connection and a half-closed connection?
18.4	If we start our `sock` program as a server, and then terminate it (without having a client connect to it), we can immediately restart the server. This implies that it doesn't go through the 2MSL wait state. Explain this in terms of the state transition diagram.
18.5	In Section 18.6 we showed that a client cannot reuse the same local port number while that port is part of a connection in the 2MSL wait. But if we run our `sock` program twice in a row as a client, connecting to the daytime server, we can reuse the same local port number. Additionally, we're able to create a new incarnation of a connection that should be in the 2MSL wait. What's going on? sun % sock -v bsdi daytime connected on 140.252.13.33.1163 to 140.252.13.35.13 Wed Jul 7 07:54:51 1993 connection closed by peer sun % sock -v -b1163 bsdi daytime reuse same local port number connected on 140.252.13.33.1163 to 140.252.13.35.13 Wed Jul 7 07:55:01 1993 connection closed by peer
18.6	At the end of Section 18.6 when describing the FIN_WAIT_2 state, we mentioned that many implementations move a connection from this state into the CLOSED state if the application did a complete close (not a half-close) after just over 11 minutes. If the other end (in the CLOSE_WAIT state) waited 12 minutes before issuing its close (i.e., sending its FIN), what would its TCP get in response to the FIN?
18.7	Which end of a telephone conversation does the active open, and which does the passive open? Are simultaneous opens allowed? Are simultaneous closes allowed?
18.8	In Figure 18.6 we don't see an ARP request or an ARP reply. Obviously the hardware address for host `svr4` must be in the ARP cache on `bsdi.` What would change in this figure if this ARP cache entry was not present?
18.9	Explain the following `tcpdump` output. Compare it with Figure 18.13. 1 0.0 solaris.32990 > bsdi.discard: S 40140288:40140288(0) win 8760 <mss 1460> 2 0.003295 (0.0033) bsdi.discard > solaris.32990: S 4208081409:4208081409(0) ack 40140289 win 4096 <mss 1024> 3 0.419991 (0.4167) solaris.32990 > bsdi.discard: P 1:257(256) ack 1 win 9216 4 0.449852 (0.0299) solaris.32990 > bsdi.discard: F 257:257(0) ack 1 win 9216 5 0.451965 (0.0021) bsdi.discard > solaris.32990: . ack 258 win 3840 6 0.464569 (0.0126) bsdi.discard > solaris.32990: F 1:1(0) ack 258 win 4096 7 0.720031 (0.2555) solaris.32990 > bsdi.discard: . ack 2 win 9216
18.10	Why doesn't the server in Figure 18.4 combine the ACK of the client's FIN with its own FIN, reducing the number of segments to three?
18.11	In Figure 18.16 why is the sequence number of the RST 26368002?
18.12	Does TCP's querying the link layer for the MTU violate the spirit of layering?
18.13	Assume in Figure 14.16 that each DNS query is issued using TCP instead of UDP. How many packets are exchanged?
18.14	With an MSL of 120 seconds, what is the maximum at which a system can initiate new connections and then do an active close?
18.15	Read RFC 793 to see what happens when an end point that is in the TIME_WAIT state receives a duplicate of the FIN that placed it into this state.
18.16	Read RFC 793 to see what happens when an end point that is in the TIME_WAIT state receives an RST.
18.17	Read the Host Requirements RFC to obtain the definition of a half-duplex TCP close.
18.18	In Figure 1.8 we said that incoming TCP segments are demultiplexed based on the destination TCP port number. Is that correct?