retagged by
12,697 views
10 votes
10 votes

A $\text{TCP}$ server application is programmed to listen on port number $P$ on host $S$. A $\text{TCP}$ client is connected to the $\text{TCP}$ server over the network.

Consider that while the $\text{TCP}$ connection was active, the server machine $S$ crashed and rebooted. Assume that the client does not use the $\text{TCP}$ keepalive timer. Which of the following behaviors is/are possible?

  1. If the client was waiting to receive a packet, it may wait indefinitely
  2. The $\text{TCP}$ server application on $S$ can listen on $P$ after reboot
  3. If the client sends a packet after the server reboot, it will receive a $\text{RST}$ segment
  4. If the client sends a packet after the server reboot, it will receive a $\text{FIN}$ segment
retagged by

3 Answers

10 votes
10 votes

Option A is correct, because client doesn’t have a keepalive timer, and the server after a reboot forgets any connection with the client existed.

As for option C and D, option D is wrong because there is no reason for a FIN segment to be sent because there is no established connection which can be closed according to the recently rebooted server.

As for option C, scroll down to read the paragraph from page 35*** of the documentation, which proves that it is in fact correct.

 

Now, for option B, during the exam i reasoned that there is a distinction between a server machine being rebooted, and a tcp application/process being restarted. 

For instance, whenever your computer crashes and reboots when you were browsing on google chrome (this was the case atleast a few years ago), did your computer automatically also restart the google chrome application? Obviously not.

There are some processes which the computer automatically starts on boot, but those are the exceptions and not the norm.

A client or server won’t simply restart its previous processes after a crash and reboot, unless it has been configured to do so, and nowhere in the question do i see that the server was a dedicated server running only the said tcp application.

The question asks what behaviour is possible on reboot. When such wording is used, it is natural to assume that it means what happens after the reboot without any external interference, human or otherwise. Because if we don’t assume this to be true, then a whole lot of things are possible after a system restarts.

Here is some supporting text from the standard tcp documentation which you can access following this: Wikipedia → Transmission Control Protocol → RFC Documents → STD 7 - Transmission Control Protocol, Protocol specification ( https://tools.ietf.org/html/std7 ) → Page 32 → Half-Open Connections and Other Anomalies.

 An established connection is said to be  "half-open" if one of the
 TCPs has closed or aborted the connection at its end without the
 knowledge of the other, or if the two ends of the connection have
 become desynchronized owing to a crash that resulted in loss of
 memory.  Such connections will automatically become reset if an
 attempt is made to send data in either direction.  However, half-open
 connections are expected to be unusual, and the recovery procedure is
 mildly involved.

 If at site A the connection no longer exists, then an attempt by the 
 user at site B to send any data on it will result in the site B TCP
 receiving a reset control message.  Such a message indicates to the
 site B TCP that something is wrong, and it is expected to abort the
 connection.

 Assume that two user processes A and B are communicating with one
 another when a crash occurs causing loss of memory to A's TCP.
 Depending on the operating system supporting A's TCP, it is likely
 that some error recovery mechanism exists.  When the TCP is up again,
 A is likely to start again from the beginning or from a recovery
 point.  As a result, A will probably try to OPEN the connection again
 or try to SEND on the connection it believes open.  In the latter
 case, it receives the error message "connection not open" from the
 local (A's) TCP.  In an attempt to establish the connection, A's TCP
 will send a segment containing SYN.  This scenario leads to the
 example shown in figure 10.

The highlighted words indicate that it isn’t always necessary that the tcp process will restart after a crash, and that it is dependent upon the operating system.

Given that we don’t know what the TCP process is exactly, it could as well be an unimportant process on a non well-known port, which was used for a private connection between the client and the server, which has no specific reason to restart after the server reboots. 

And until and unless the process restarts, it won’t start listening on its configured port number.

 

***Also on Page 35 → 

 Reset Generation

  As a general rule, reset (RST) must be sent whenever a segment arrives
  which apparently is not intended for the current connection.  A reset
  must not be sent if it is not clear that this is the case.
4 votes
4 votes

The Correct option is A,B and C. 

  1. Option A is correct
  2. Option B is correct as once the current session will be terminated(due to reboot) and new connection can take place on the same port.
  3. Option C is also correct as explained in option A.
  4. Option D is false as the FIN is used to close connection.
edited by
0 votes
0 votes
Once server connection is lost, RTO starts and keeps on updating its value ie clients keeps waiting.

Once the server reboots, the old TCP connection is listened and immediately replies clients with RST packet defining to end the previous TCP connection immediately and reconnect with the server again. Hence option A, B and C.
Answer:

Related questions

21 votes
21 votes
6 answers
4