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.