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.