GATE CSE 2008 | Question: 59

Question

A client process P needs to make a TCP connection to a server process S. Consider the following situation: the server process S executes a $\text{socket()}$, a $\text{bind()}$ and a $\text{listen()}$ system call in that order, following which it is preempted. Subsequently, the client process P executes a $\text{socket()}$ system call followed by $\text{connect()}$ system call to connect to the server process S. The server process has not executed any $\text{accept()}$ system call. Which one of the following events could take place?

• A. $\text{connect()}$ system call returns successfully

• B. $\text{connect()}$ system call blocks

• C. $\text{connect()}$ system call returns an error

• D. $\text{connect()}$ system call results in a core dump

Comments

is sockets in gate syllabus, can anyone tell?

---

@Taniii I think they do have sockets under TCP in gate syllabus

---

is OPTION C really correct here?? this above text and many standard resources say kernal handles the three way handshake and accept has nothing to do with it and even if the process is preempted the request will come in NIC and interrupt will happen so itll be done and option A should be true 

Answer 1

First thing to note: All the sockets are by default in BLOCKING mode. What do we mean by blocking ??

Blocking mode means that when we make a system call, it blocks the caller for the time "when call() is made till the job is done OR an error returns ". We can set each socket to Non-blocking explicitly. Setting to Non-Blocking means we are telling the kernel that "If the system call cant be completed without putting process to sleep then DON'T put the process to sleep . Instead return with an ERROR immediately and continue the process" which can be checked for the completion by the caller in between the execution of other tasks.

Now coming to this question:

Suppose connect() is in default blocking mode then calling connect() sends SYN packet to the server. Since server has not executed any accept() call it can not acknowledge the SYN packet. Connect() in blocking mode keep sending SYN packets at fixed intervals(first after 6 sec, second after 24 sec typically until 75 sec latest). This is done until an error ETIMEDOUT is returned by the TCP.(in this case,else there are several other type of errors returned in case No port exists for that connection or server id not listening etc.)

Here, option (B) saying that connect() blocks is not entirely wrong but since we know that accept() call is not made by server, connect() WILL NOT WAIT FOREVER and SO IT CAN NOT BLOCK. It will ultimately return with an ERROR message.

So, option (C) is CORRECT.

Core dump thing I don't know about!

But once connect() returns error that socket can not be reused and must be CLOSED.

And a non-blocking connect() is never blocked and immediately returns with an error if connection is not successful although IT CONTINUES WITH TRYING TO CONNECT .Error here just means that it returns a message saying "I could not connect immediately BUT i am trying AND you can check it in between.

Hope it clears a bit.

Comments

It will ultimately return with an ERROR message.

As the program responsible for the response of connect() of client is pre-empted,

Who will return this error message?

---

jatin khachane 1 can you tell the source of this image?

---

By this logic, no process in any OS should be having tcp socket ipc. But we have many such examples (Xlib in linux opens server and client proc in system can connect to it for sending graphical operations and it works properly). In these cases there is no restriction on OS that both server and client cannot run in same processor (Therefore, it can get preempted)

Answer 2

Simple it is. given that the server process is preempted before client requests anything. It means that calling the connect() system call will try to establish a TCP connection (will send SYN) but since the server at the expected port is not present at the destination, a host unreachable - port unreachable error will be returned by the ICMP.

Comments

Simpley wrong answer 😞

Premption of a process does not clears up its port. That is obviously wrong.

Answer 3

Everything is black.

if you will remember this proverb you will easily understand how a connection can be established in a TCP connection.

S B L A C

S STANDS FOR SOCKET.

B STANDS FOR BIND.

L STANDS FOR LISTEN.

A STANDS FOR ACKNOWLEDGE

C STANDS FOR CONNECT

Connection is always made via this series of steps.

now as you can see in the question it is given that the client process p executes a socket system call followed by directly connect now everyone knows that connect system call require bind and listen which has not occurred so this will return an error that's why this will return an error.

Comments

Thanks for the acronym $\text{SBLAC}$!

---

But bind and listen has occured as given in the question..

---

do connect system calls at client require bind and listen? why ? why does socket,bind and connect does not suffice?

---

@Nebula SBLAC is on server side only. on client side socket() ke baad connect() hota hai

@Amanbadone0 client side pe direct connect use hota hai kyuki client is always active whereas server hamesha active nhi hota isliye SBLAC follow krta hai

Answer 4

The correct answer is A: connect() returns successfully.

The whole confusion happens because people think the server program itself needs to pick up the call. In reality, the moment the server calls listen(), the operating system kernel takes over. When the client calls connect(), the server’s kernel automatically handles the entire three-way handshake in the background and parks the established connection into a waiting queue.

Because the handshake finishes instantly at the kernel level, connect() unblocks with success right away. The server process doesn't even need to be awake, and it doesn't need to call accept() yet, accept() is only used later to pull that already-connected socket out of the queue.