search
Log In
1 vote
1.1k views

GATE CSE 2021 Set 1 | Question-19.8

  1. GATE CSE 2021 Set 1 | Question-95
  2. GATE CSE 2021 Set 1 | Question-95
  3. GATE CSE 2021 Set 1 | Question-95
  4. GATE CSE 2021 Set 1 | Question-95

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 $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
recategorized by
1.1k views
0
A and C?
0
Nope, B is also correct, as since after a reboot a TCP server can listen to the same port P. Like for example assume a web server that uses port number 80. After a reboot why the server wouldn't be able to use the same port number? Of course, It will be able to. So the answer should be A, B, C.
0

what you are saying is true @panduranga, but wouldnt you agree 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 doesnt happen on its own i guess). Because the question asks: 

“….consider while the tcp connection is active, S crashed and rebooted….which of the following behaviours is possible?”

I feel that is the keyword, because it is quite obvious that a “server application” when restarted will listen to its configured port, but here the host machine S is being restarted..

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

2 Answers

3 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.
0

@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?

0
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
0 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
This is actually confusing. I thought since there is no keep alive timer, the client might have to wait indefinitely but since it is mentioned in the question that the server reboots, the client should receive a RST segment. What if the client is expecting an acknowledgement and it does send a packet ? Is it possible ? Or will the client definitely send packets at regular intervals of time ?
0
Option A is not incorrect, Because even if on restart server sends RST segment. This RST segment can also get lost. And therefore, The client may wait indefinitely. Because it is not using any keepalive timer. So there is a chance client ends up waiting indefinitely.
0
Even if the first RST segment is lost. Won't the server reply with subsequent RST segment as client will keep sending packets or will the server reply with only one RST segment for the first packet it recieves ? Even if the server subsequently replies with next RST segment, there is a chance that it might get lost. So is that the reason why option a is correct ? This questions is really confusing as the wording say which of the behaviours are possible.
0
Yes, Since they have asked for posible behaviour therefore A is also possible. Just like you said, all the subsequent RST segments can get lost, leading to Client waiting indefinitely. This is network, we don't expect it to cooperate or work in an ideal manner. It may start behaving weirdly with added congestion and other things. Therefore, it is perfectly possible that client ends up waiting indefinitely becauce we are not even using keep alive timer.

Therefore, Options A is also True.
0
Got it. The question is soo deceptive. 😌
0
Why is A correct. I still don't get it.. if the client is waiting for reception of an Ack to a segment, it will simply timeout(this timer is Retransmission timer, not keep alive timer) and retransmit the segment again. When server reboots and receives this segment again, because the server sees that there is no connection established on the port and a segment has been received out of thin air, it will send a RST segment to host(which basically means that host is advised to stop sending on any previous connection that it is sending, and to establish a new connection again). Then host will try to establish a new connection again on the same port with the server(3 handshake etc.etc.) and start sending segments again on the new connection. This is how the sequence of events should be.

Keep alive timer is only to check if the connection is still active.

I see in the comments above that server sends a RST segment on reboot, which is not the case. Rather, it is triggered by reception of an unexpected segment and so the sequence of events , I believe, is as stated above.

TCP has  >1  timer viz. Retransmission timer, keep-alive timer, persistence timer and..... I believe I am missing something.....
0

Can we use the following RFC 793 as reference:

https://tools.ietf.org/html/rfc793

The following extract explains what half open connection in TCP is and it kind of matches option B:

 

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.  After TCP A crashes, the user attempts to
  re-open the connection.  TCP B, in the meantime, thinks the connection
  is open.
0
The thing is you are considering a very idealistic scenario. Let me tell you how the client may end up waiting indefinitely according to your scenario too. When the retransmission timer expires, the client will resend the segment which when received by the server will trigger sending of RST segment. Now, ideally, this RST segment would be received and the connection will be reestablished using a three-way handshake and things would proceed normally as we would expect. But now for the possibility and the “MAY” wait indefinitely statement, Consider this, the server resends RST segment and it is lost. or in the very first place, the retransmission of the segment that that was triggered by retransmission timer timing out got lost. You see, it is a network. Many things can go wrong. The reason that they have mentioned to assume that client doesn’t use a keep-alive timer is if there would have been a keep-alive timer, no matter how many packets would have got lost or any kind of bizarre event. After the keep-alive timer would have timed out that connection would have been closed for good. And in that case, the client wouldn’t have ended up waiting indefinitely.

Therefore, I think it is perfectly possible that if the client was waiting to receive a packet, it may end up waiting indefinitely.
0
@PanduragaVitthal I am convinced about the reasoning for option A. But I am sort of contesting for option B that due to half-open the server S won’t be able to connect to the same port again.
0
Well you are considering a very highly pessimistic case....Its as if the network has failed totally(not just a lossy network but a totally failed network)... In that case C should be wrong too because even  if  host attempts to send the segment, well it receiving RST segment may not happen..if we are considering a totally failed network... Well the point is in such case (network totally down case) the client will stop sending any segment instead of waiting indefinitely. After a few trials the application itself will pop up a timeout dialogue.

Even in TCP some RFC standard specifies a limit of .......15 retries I guess. So waiting indefinitely will not happen even in such a pessimistic scene
0
Well what's wrong with B, we can always can bind the server process with the same port no. even after server boot
0
Well, first of all when we are asked about “possible” isn’t that what we are supposed to do? Like when we are given some synchronization code and we are asked that whether deadlock is possible or not, then don’t we take a pessimistic approach and try to find the very corner case that has the very least possibility of happening and then end up saying that yes this code suffers from deadlock.

Now, back to your doubt, no it doesn’t necessarily have to be a totally failed network for the client to wait indefinitely. You see, in your example, you took the case where the client was waiting for an “ack” from the server. And then you made the retransmission timer time out and then took things back to normal. Now, Assume that client isn’t waiting for ack or anything like that, it is just waiting for a packet that the server has to transmit. The client isn’t running any kind of retransmission timer or anything like that, because it is not something that client has sent waiting for an acknowledgement from the server, but rather it is waiting for a packet from the server-side. In this case, when the server reboots then it won’t even remember any connection that it was using before. And our poor client would end up waiting indefinitely hoping that the server will someday send it the intended packet that it is waiting for. But on the other side server has just totally forgotten about any previous connection.

The thing that could have saved the client from waiting indefinitely is the keep-alive timer. Because with that, the connection would have been terminated after a while, and then later the client would have gone on to re-establish the connection and normal transmission would have started.

So, it doesn’t have to be a totally failed network for the client to wait indefinitely and neither there would be more than 15 attempts after which the limit will be crossed because it may happen that there is not even a single transmission and yet the client is waiting.
0
Yup u r right....it is ur latest post which refutes my argument
0
So what will the correct options here ? A,B and C?
0
yes has to be A,B,C
Answer:

Related questions

3 votes
2 answers
1
756 views
Consider two hosts $P$ and $Q$ connected through a router $R$. The maximum transfer unit $\text{(MTU)}$ value of the link between $P$ and $R$ is $1500$ bytes, and between $R$ and $Q$ is $820$ bytes. A $TCP$ segment of size $1400$ bytes was ... lost, $P$ is required to resend the whole $\text{TCP}$ segment. $\text{TCP}$ destination port can be determined by analysing only the second fragment.
asked Feb 18 in Computer Networks Arjun 756 views
1 vote
2 answers
2
404 views
In the context of operating systems, which of the following statements is/are correct with respect to paging? Paging helps solve the issue of external fragmentation Page size has no impact on internal fragmentation Paging incurs memory overheads Multi-level paging is necessary to support pages of different sizes
asked Feb 18 in Operating System Arjun 404 views
1 vote
3 answers
3
262 views
Let $\langle M \rangle$ denote an encoding of an automaton $M$. Suppose that $\Sigma = \{0,1\}$. Which of the following languages is/are $\text{NOT}$ recursive? $L= \{ \langle M \rangle \mid M$ is a $\text{DFA}$ such that $L(M)=\emptyset \}$ $L= \{ \langle M \rangle \mid M$ is ... $L(M)=\emptyset \}$ $L= \{ \langle M \rangle \mid M$ is a $\text{PDA}$ such that $L(M)=\Sigma ^* \}$
asked Feb 18 in Theory of Computation Arjun 262 views
3 votes
1 answer
4
429 views
Suppose a database system crashes again while recovering from a previous crash. Assume checkpointing is not done by the database either during the transactions or during recovery. Which of the following statements is/are correct? The same undo and redo list ... any further All the transactions that are already undone and redone will not be recovered again The database will become inconsistent
asked Feb 18 in Databases Arjun 429 views
...