Chapter 18

Chapter 18

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?

A:

The ISN is a 32-bit counter that wraps around from 4,294,912,000 to 8,704 approximately 9.5 hours after the system was bootstrapped. After approximately another 9.5 hours it will wrap around to 17,408, then 26,112 after another 9.5 hours, and so on. Since the ISN starts at 1 when the system is bootstrapped, and since the lowest order digit cycles through 4, 8, 2, 6, and 0, the ISN should always be an odd number.

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?

A:

In the first case we used our sock program, and by default it transmits the Unix newline character as itself ”the single ASCII character 012 (octal). In the second case we used the Telnet client and it converts the Unix newline into two ASCII characters ”a carriage return (octal 015) followed by a linefeed (octal 012).

18.3

What's the difference between a half-open connection and a half-closed connection?

A:

On a half-closed connection one end has sent a FIN and is waiting for either data or a FIN from the other end. A half-open connection is when one end crashes, unbeknown to the other end.

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.

A:

The 2MSL wait state is only entered for a connection that has gone through the ESTABLISHED state.

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 
A:

First, the daytime server does the active close of the TCP connection after writing the time and date to the client. This is indicated by the message printed by our sock program: "connection closed by peer." The client's end of the connection goes through the passive close states. This puts the socket pair in the TIME_WAIT state on the server, not the client.

Next, as shown in Section 18.6, most Berkeley-derived implementations allow a new connection request to arrive for a socket pair currently in the TIME_WAIT state, which is exactly what's happening here.

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?

A:

A reset is sent in response to the FIN, because the FIN arrived for a connection that was CLOSED.

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?

A:

The party that dials the number does the active open. The party whose telephone rings does the passive open. Simultaneous opens are not permitted, but a simultaneous close is OK.

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?

A:

We would only see ARP requests, not TCP SYN segments, but the ARP requests would have the same timing as in the figure.

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 
A:

The client is on the host solaris and the server is on the host bsdi. The client's ACK of the server's SYN is combined with the first data segment from the client (line 3). This is perfectly legal under the rules of TCP, although most implementations don't do this. Next, the client sends its FIN (line 4) before waiting for the ACK of its data. This allows the server to acknowledge both the data and the FIN in line 5 .

This exchange (sending one segment of data from the client to the server) requires seven segments. The normal connection establishment and termination (Figure 18.13), along with a single data segment and its acknowledgment, requires nine segments.

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?

A:

First, the server's ACK of the client's FIN is normally not delayed (we discuss delayed ACKs in Section 19.3) but sent as soon as the FIN arrives. It takes the application a while to receive the EOF and tell its TCP to close its end of the connection. Second, the server that receives the FIN does not have to close its end of the connection on receiving the FIN from the client. As we saw in Section 18.5, data can still be sent.

18.11

In Figure 18.16 why is the sequence number of the RST 26368002?

A:

If an arriving segment that generates an RST has an ACK field, the sequence number of the RST is the arriving ACK field. The ACK value of 1 in line 6 is relative to the ISN of 26368001 in line 2.

18.12

Does TCP's querying the link layer for the MTU violate the spirit of layering?

A:

See [Crowcroft et al. 1992] for comments on layering.

18.13

Assume in Figure 14.16 that each DNS query is issued using TCP instead of UDP. How many packets are exchanged?

A:

Five queries are issued. Assume there are three packets to establish the connection, one for the query, one to ACK the query, one for the response, one to ACK the response, and four to terminate the connection. This means 11 packets per query, for a total of 55 packets. Using UDP reduces this to 10 packets.

This can be reduced to 10 packets per query if the ACK of the query is combined with the response (Section 19.3).

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?

A:

The limit is about 268 connections per second: the maximum number of TCP port numbers (65536 “ 1024 = 64512, ignoring the well-known ports) divided by the TIME_WAIT state of 2MSL.

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

A:

The duplicate FIN is acknowledged and the 2MSL timer is restarted.

18.16

Read RFC 793 to see what happens when an end point that is in the TIME_WAIT state receives an RST.

A:

The receipt of an RST while in the TIME_WAIT state causes the state to be prematurely terminated . This is called TIME_WAIT assassination. RFC 1337 [Braden 1992a] discusses this in detail and shows the potential problems. The simple fix proposed by this RFC is to ignore RST segments while in the TIME_WAIT state.

18.17

Read the Host Requirements RFC to obtain the definition of a half-duplex TCP close.

A:

It's when the implementation does not support a half-close. Once the application causes a FIN to be sent, the application can no longer read from the connection.

18.18

In Figure 1.8 we said that incoming TCP segments are demultiplexed based on the destination TCP port number. Is that correct?

A:

No. Incoming data segments are demultiplexed using the source IP address, source port number, destination IP address, and destination port number. For incoming connection requests we saw in Section 18.11 that a TCP server can normally prevent connections from being accepted based on the destination IP address.



TCP.IP Illustrated, Volume 1. The Protocols
TCP/IP Illustrated, Vol. 1: The Protocols (Addison-Wesley Professional Computing Series)
ISBN: 0201633469
EAN: 2147483647
Year: 1993
Pages: 378

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net