4,106 views

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

Yes indeed no doubt that TCP application won't start on its own. It will take some sequence of actions to get there, but that's not what Option B says. It is asking whether the TCP application CAN listen to the port P again after reboot. Then there is no doubt that yes it can, they have not mentioned anything regarding immediately after reboot or whatever. In my opinion, After a restart, whenever the TCP application starts, it can listen to port P and therefore, Option B is also true.
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
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?
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?

### Subscribe to GO Classes for GATE CSE 2022

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.
by

@rish-18 There is a lot of ambiguity with option B. On one hand, it is perfectly correct that “once the current session will be terminated(due to reboot) and a new connection can take place on the same port.” hence we can consider option B

But on another hand: “that when the server crashes and reboots, there is no specific reason for the TCP application to restart too and start listening on the port (which takes some sequence of actions and doesn't happen on its own I guess).” shows that option B cannot be always true. Due to 2nd reason I have not chosen option B during the exam.

Do we have to consider it? Can we challenge GATE answer key in this case?

We can definitely challenge, but I'm not very hopeful. I feel they'll dismiss our 'interpretation' of the question as wrong, although our reasoning is 100% right
Update : i did challenge this question, but no luck :P

What is the right answer to this question?
a, b and c.

Silly question. The client doesn’t have a keep-alive timer but it may have a timeout timer. So why will the client wait indefinitely?

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.
by
1 2

So what will the correct options here ? A,B and C?
yes has to be A,B,C
There is no mention of keep alive timer concept in Tanenbaum. How to know which topics to study that are not in standard textbooks?
There is no detailed explanation related to this in Tanenbaum. How to know which topics to study that are not in standard textbooks?
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.
by
1