in Computer Networks retagged by
12,670 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
in Computer Networks retagged by
by
12.7k views

4 Comments

Idk, i still feel my interpretation of the question is better, but yours may be correct :P

is it just me or every now and then gate questions seem like a test of your ability to understand subtle semantic differences in an english sentence rather than targetting concepts :P
1
1
There is no detailed explanation of keep alive timer concept in Tanenbaum. How to know which topics to study that are not in standard textbooks?
0
0
Why didn’t we consider “time out timer” for option A? If the receiver is waiting for a packet from the server, then after a certain time, its time out timer expires, and the receiver will send the packet again. But this time, since the server restarted it won’t remember the sequence number so the server sends RST to the receiver. Hence the receiver will not wait forever to receive the packet from the server.

What is wrong with this argument?
2
2

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 Comments

B can be true if server have only one port, is this correct?
0
0

According to the question, it’s mentioned that the server is programmed to listen on port P, then Option B  is Correct.

0
0

@Aditya_ Yes, your observation is correct. If the TCP server application is programmed to listen on only one port, then it is possible for the application to listen on that port after the server machine reboots. This is because the TCP protocol does not specify any specific behavior for the server in this situation.

In general, when a server machine reboots, all of its active TCP connections are terminated. However, after the reboot, the server machine can listen for new connections on the same port or ports as before. 

If the TCP server application is programmed to listen on a specific port, then it can listen on that port after the server machine reboots. However, if the application was listening on multiple ports, then it may not be able to listen on all of those ports after the reboot, depending on the configuration of the server machine.

1
1
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

4 Comments

yes has to be A,B,C
0
0
There is no mention of keep alive timer concept in Tanenbaum. How to know which topics to study that are not in standard textbooks?
0
0
There is no detailed explanation related to this in Tanenbaum. How to know which topics to study that are not in standard textbooks?
0
0
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